Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
* John Goerzen ([EMAIL PROTECTED]) wrote: > On Thu, Dec 02, 2004 at 12:28:20PM -0200, Fernanda Giroleti Weiden wrote: > > "It is also the type of discussion that deterred me > > from becoming involved in Debian for some time." > > > > http://lists.debian.org/debian-women/2004/12/msg00011.html > > If our goal is to advance the cause of a Free operating system, then why > should we be including, in our OPERATING SYSTEM, images that serve no > useful purpose, and instead alienate millions or billions of people > worldwide? How does this advance our stated priorities: our users and > Free Software? Does anyone seriously think that we are being a > disservice to users because we don't have porn integrated into the > operating system? Does anyone seriously think that including these > particular images would be such an overwhelming benefit? I agree with this and is why I was suggesting that someone draft up some language which outlines, for the benefit of our users, things they're not likely to find in Debian. I suppose that might end up being too difficult but I think it'd be good to have some criteria for packages to pass in order to be accepted which includes issues like these and is clear enough that our users understand it. Stephen signature.asc Description: Digital signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
* Manoj Srivastava ([EMAIL PROTECTED]) wrote: > a) legal to distribute Where, and to who? You can't distribute something without being somewhere and distributing it to someone. > b) meets the dfsg > c) scratches an itch you feel, and something you are willing to sign > up to maintain and keep bug free. Where do we specify these requirements for a package to be in Debian? The Social Contract says Debian will not include software that has a set of legal restrictions on it and the DFSG says the license can't restrict distribution but neither seems to talk about the legality of distribution beyond licenses. When you're talking about 'controlled' things (cryptography, pornography, probably other stuff) there's more to it than just the license, at least in some places. Additionally, personally I wouldn't be adverse to there being some additional requirements such that we remain focused on providing a good operating system as opposted to a general data distribution system for anything people want to distribute. In fact, it seems likely to me that there *are* certain additional requirements beyond those above which are enforced by the archive maintainers through general good sense, they're just not *documented* anywhere and so our users don't actually know what they are (or other developers, for that matter). Stephen signature.asc Description: Digital signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
* Manoj Srivastava ([EMAIL PROTECTED]) wrote: > On Thu, 2 Dec 2004 12:41:34 -0500, Stephen Frost <[EMAIL PROTECTED]> said: > > Where do we specify these requirements for a package to be in > > Debian? > > Umm, does everything need to come on a piece of paper > properly daubed with penguin pee? It would be useful for our users to know the policies of acceptance of a package to Debian, whatever they are. > > The Social Contract says Debian will not include software > > that has a set of legal restrictions on it and the DFSG says the > > license can't restrict distribution but neither seems to talk about > > the legality of distribution beyond licenses > > And that is indeed the limit of restrictions on packages. Except it's not- we won't distribute things which are illegal to distribute, apparently with regard to the laws of the US and wherever non-us lives these days. > > When you're talking about 'controlled' things (cryptography, > > pornography, probably other stuff) there's more to it than just the > > license, at least in some places. > > I think it is kinda assumed that we are not scofflaws, > breaking the laws of te land in which master and non-us live. Until > now, I had not imagined that such things had to be pointed out to > people. 1) There are mirrors in our distribution network throughout the world, let's hope that the mirror maintainers are willing to deal with the authorities in their country. 2) Where do we point out to our users that the laws which govern what we'll distribute are those of the US and finland (or wherever) and that the laws in their country may forbid distribution? Especially if they're downloading from a mirror that's in their country, they may not be aware of this. Stephen signature.asc Description: Digital signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
* Manoj Srivastava ([EMAIL PROTECTED]) wrote: > On Fri, 03 Dec 2004 09:02:24 +1100, Brian May <[EMAIL PROTECTED]> said: > > (However, the material in question on this thread may or may not be > > illegal). > > Quite. And if material objectionable to children is under > discussion, there is alot of language in the linux kernel like what > caused Stern to be fined millions of dollars. It is certainly not > PG-13, and you can't just hjand stuff containing such language to > underage children. Stern, from my understanding, was broadcasting such language on the public airwaves. Do you have an example of a company being prosecuted for distributing CDs, or providing access over the internet which contains such content, to minors? I have to admit that I wasn't very successful finding examples of website owners being prosecuted for distributing pornogrophy. I'm guessing I wasn't looking in the right places or perhaps they just tend to be threatened since I know there have been changes in that industry (click-through age statements and whatnot) over the past couple years. Stephen signature.asc Description: Digital signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
* Manoj Srivastava ([EMAIL PROTECTED]) wrote: > On Thu, 2 Dec 2004 19:43:19 -0500, Stephen Frost <[EMAIL PROTECTED]> said: > > Stern, from my understanding, was broadcasting such language on the > > public airwaves. Do you have an example of a company being > > prosecuted for distributing CDs, or providing access over the > > internet which contains such content, to minors? > > No, but I have no such data for companies giving out CD's with > programs like hot-babe either. In my eyes, one is as likely as the > other, they are both offensive material unsuited for minors. In my view, hot-babe is more likely than the Linux kernel but I do feel it's a borderline case. Perhaps it doesn't justify modifying our SC or what-have-you but I don't particularly like the idea of waiting till someone wants to package goatse.cx or child pornogrophy or something which would cause us problems to clarify our position on it. > > I have to admit that I wasn't very successful finding examples of > > website owners being prosecuted for distributing pornogrophy. I'm > > It is big business, from all reports. Sure, though I'm not sure what that has to do w/ this. > > guessing I wasn't looking in the right places or perhaps they just > > tend to be threatened since I know there have been changes in that > > industry (click-through age statements and whatnot) over the past > > couple years. > > But there are quite a lot of unsuitable material even before > asking for credit cards for proof of age or even a simple click > through (what 13 year old would be stopped by that? I sure as heck > would not have when I was younger) I suspect the issue isn't if an unsupervised 13 year old would be stopped by it or not, otherwise I don't think we'd see the proliferation of those click-through's that we (or at least, I) do. The other question is if those servers are hosted in the US or not, since that's where master is. Even so though, what we need to make a decision is a few example cases where those sites have been prosecuted, not examples of where they havn't (since, after all, the FBI or whomever could be working to go after those soon or whatever). Though, the cases should be reasonably recent too, of course.. Stephen signature.asc Description: Digital signature
Re: package rejection
* Henrique de Moraes Holschuh ([EMAIL PROTECTED]) wrote: > The only other real condition is: > > 2) is acceptable to one of the ftp-masters. > > So ask one of them directly. Agreed, and I think they've done a good job of it thusfar. That answer seems, to me anyway, to be an insufficient answer to give our users though. I'd like to think we could do better, as was done w/ the NM process eventually. Stephen signature.asc Description: Digital signature
Re: Linux Core Consortium
* Bruce Perens ([EMAIL PROTECTED]) wrote: > Henrique answered your question. There has been some divergence between > various distributions regarding the naming and especially the versioning > of these libraries. We would heal that fork to increase compatibility. > Doing that means that some names and version tags are going to change > for some people. Of course we want to see everyone involved bearing some > of that load, rather than Debian bearing the lion's share of it. You can start w/ OpenLDAP, please. They need to be shown and convinced of why caring about one's ABI (opposted to just the API) is necessary... Good luck. Stephen signature.asc Description: Digital signature
Re: MTA in base system installation
* Philipp Hug ([EMAIL PROTECTED]) wrote: > Is it really necessary to have a full blown MTA in the base installation? > Wouldn't it make more sense to just install a simple store-and-forward proxy > (e.g nullmailer)? > Or are there other alternatives that just provide a sendmail wrapper? Well, would you like cron to *work* on a base installation? I would, not that I'm exactly happy about exim being the choice, but whatever. Stephen signature.asc Description: Digital signature
Re: Vancouver meeting - clarifications
* Andreas Barth ([EMAIL PROTECTED]) wrote: > (And, BTW, newraff is a quite mature box. Of course, there is always > more and better hardware available, but newraff is already a very good > machine. And, we want to give the testing migration script more tasks, > like handling of the udebs, which puts load off from human being and on > into a script. But that increases the ressources the script uses.) These are technical problems, something Debian is very good at dealing with in general. I don't think we need more hardware resources. We need to use them better which probably means working on a better system that's able to handle the load and that will scale better. Things like ditching dbm in favor of Postgres or similar, connection cacheing or perhaps ssh port-forwarding and then connecting to a Postgres instance over that port-forward would probably help alot... Stephen signature.asc Description: Digital signature
Re: Vancouver meeting - clarifications
* Peter 'p2' De Schrijver ([EMAIL PROTECTED]) wrote: > > I hope you can agree that we need to say that "almost all" packages that > > should be build are build. And I consider 97.5% to be a reasonable > > level. Also, if we exclude too much, we might start to ask the question > > why we should do a stable release for an arch that builds only a very > > minor part of the archive. But the "excluding architecture-specific > > packages" gives of course some possibilities which packages count and > > which not. > > I think we should distinguish between what's really necessary to have a > useable release and what is nice to have. It's obviously nice to compile > almost everything for all archs. But if upstream is too broken for this > to be possible, it might make more sense to leave the broken bits out > then to delay everything. This is not a terrible thought really, imv. There are packages which it doesn't make sense to have on a given architecture. This would reduce the buildd load for that architecture and may reduce the load on the security team to support those architectures, etc. For the initial package set I'd think it'd be up to the porters but after that there could be wishlist bugs against an *architecture* for packages to be added/removed which users need or which don't work so hot. It's an idea that has some merit and should at least be considered. Stephen signature.asc Description: Digital signature
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
* Ben Collins ([EMAIL PROTECTED]) wrote: > Also, this will make two ultrasparc machines available for some of our new > sparc developers. I can't pay to ship them, but if Debian foots the bill, > I'll get them to the right ppl. I'd be willing to help with the shipping bill, and possibly with the hosting as well. Additionally, I may be able to make some other sparc systems available. Stephen signature.asc Description: Digital signature
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
* Martin Michlmayr - Debian Project Leader ([EMAIL PROTECTED]) wrote: > * Stephen Frost <[EMAIL PROTECTED]> [2005-03-15 11:04]: > > > Also, this will make two ultrasparc machines available for some of our new > > > sparc developers. I can't pay to ship them, but if Debian foots the bill, > > > I'll get them to the right ppl. > > > > I'd be willing to help with the shipping bill, and possibly with the > > Debian has enough resources to pay for shipping expenses. > > > hosting as well. Additionally, I may be able to make some other sparc > > systems available. > > Are any of them 64 bit? Joshua Kwan might benefit from having a 64 > bit SPARC system (at least he would've benefited in the past; I'm not > sure how much spare time he has at the moment or in the near future). Yeah, currently I've got access to 2 64bit ultrasparcs. The 'may be able to' bit above comes from the question of how much access I'd be able to give others. I'll need to investigate that, though a SunFire V100 isn't exactly terribly expensive - $995 w/ 256M and an 80G disk. Stephen signature.asc Description: Digital signature
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
* Ben Collins ([EMAIL PROTECTED]) wrote: > On Tue, Mar 15, 2005 at 11:17:54AM -0500, Stephen Frost wrote: > > * Martin Michlmayr - Debian Project Leader ([EMAIL PROTECTED]) wrote: > > > * Stephen Frost <[EMAIL PROTECTED]> [2005-03-15 11:04]: > > > > > Also, this will make two ultrasparc machines available for some of > > > > > our new > > > > > sparc developers. I can't pay to ship them, but if Debian foots the > > > > > bill, > > > > > I'll get them to the right ppl. > > > > > > > > I'd be willing to help with the shipping bill, and possibly with the > > > > > > Debian has enough resources to pay for shipping expenses. > > > > > > > hosting as well. Additionally, I may be able to make some other sparc > > > > systems available. > > > > > > Are any of them 64 bit? Joshua Kwan might benefit from having a 64 > > > bit SPARC system (at least he would've benefited in the past; I'm not > > > sure how much spare time he has at the moment or in the near future). > > > > Yeah, currently I've got access to 2 64bit ultrasparcs. The 'may be > > able to' bit above comes from the question of how much access I'd be > > able to give others. I'll need to investigate that, though a SunFire > > V100 isn't exactly terribly expensive - $995 w/ 256M and an 80G disk. > > No need to give access to them. I want to give them out for personal > development use (builds, test installs, whatever). Right, sure, I was referring to what I've personally got access to (through work mainly) that I'd be able to do some Debian stuffs on. The only sparc I've got at home atm is a sparc2, which is likely to be junked before too much longer unless someone's interested in it. Having a sparc at home would let me host it for others to use but it sounds like that's covered w/ the E3500 etc. If necessary I can test installs and kernels on the boxes at work though having one at home might be a little easier. I don't profess to have lots of time though, so if there's someone else who's got more time and inclination it'd be better to go to them first. Stephen signature.asc Description: Digital signature
Re: Alternative: Source-Centric Approach [w/code]
* Marc Singer ([EMAIL PROTECTED]) wrote: > On Tue, Mar 15, 2005 at 11:25:23AM -0600, John Goerzen wrote: > > So, what do you think? Could this work? > > I like the idea a lot. What I'd like to see is a way to do a > cross-platform build for the small system targets. I do a lot of ARM > work: low-performance, resource limited targets. > > Frankly, this is something I'm actively working on. I agree that the > Debian infrastructure shouldn't be required to do all of the building. > It would be helpful, though, if there was support for other arch's to > be built efficiently by the users of those arches. I'm not particularly fond of the idea actually, mostly because of the strain it'd put on our users. An alternative: - Mirror only the popular archs. - Support buildds for stable-enough archs that run them. - Try to include everything in a release, but drop archs more quickly than has been done in the past if there's a lack of resources, but do outline what people need to do if they want the arch included. - For archs that weren't able to make the cut, provide .debs for the packages which don't have RC bugs. Don't provide .debs for the packages which have RC bugs on that architecture. Attempt to include the archs in security updates, but if it's not built fast enough or whatever then drop the .deb for that package and provide the source update. A fixed .deb can be done later by whomever. I dunno, just some thoughts. I don't like becoming a mostly source-only distro for less common archs. If someone wants to build the debs and upload them, let them. Stephen signature.asc Description: Digital signature
Re: Bits (Nybbles?) from the Vancouver release team meeting
* Stephen Gran ([EMAIL PROTECTED]) wrote: > This one time, at band camp, Henning Makholm said: > > The point is still that some architectures are going to be left out in > > the dark. That's the purpose of the whole plan. > > Only if those architectures don't have sufficient community support. I > really cannot see the problem with that - you want to release > architectures that aren't well supported as 'Debian stable'? I don't. > Under the terms of the proposal as laid out, all 11 architectures > shipping with sarge _could_ ship with etch (although they might not be > mirrored so widely). It is just up to the porters to make sure this > happens. I don't believe this is accurate, and is in fact a big problem that I have with this proposal. Things like "N may not be more than 2" and "architecture must be available for purchase new" are not things which the Debian community is likely to be able to fix. Supplying more than 2 machines, and the manpower to admin them, is something the community could do and if that happens and someone offers to join the security, RM, etc teams to handle post-release support I think the arch should be released as stable. Stephen signature.asc Description: Digital signature
Re: Bits (Nybbles?) from the Vancouver release team meeting
* Stephen Gran ([EMAIL PROTECTED]) wrote: > This one time, at band camp, Stephen Frost said: > > I don't believe this is accurate, and is in fact a big problem that I > > have with this proposal. Things like "N may not be more than 2" and > > "architecture must be available for purchase new" are not things which > > the Debian community is likely to be able to fix. Supplying more than > > 2 machines, and the manpower to admin them, is something the community > > could do and if that happens and someone offers to join the security, > > RM, etc teams to handle post-release support I think the arch should > > be released as stable. > > There was a later clarification (from Andreas Barth? - I can't remember, > it's something like 1000 messages ago now :) that addressed those > statements in a better way. There were concerns that they were > attempting to address, namely - the inability of the buildd setup to > continue should a machine fail, and the long time it takes important > fixes to be built from source on some architectures. Yes, Andreas actually did what I had asked Steve to do- give us the reasons behind the rules. > The clarification made it fairly clear to me that if this is achieved by > the porter team running clusters with distcc and magic smoke, and has a > back bedroom full of spare parts, that should satisfy the criteria. The > point was that Debian's core infrastructure shouldn't be responsible for > limping along a dead architecture that is essentially unavailable, and > that security fixes and the like have to be done in a more timely > manner. Ah, now here's a new one that I'm going to have to ask you to clarify: What is "Debian's core infrastructure"? Is that wanna-build access? Is that all the buildds? Only buildds for some archs, what archs, why those archs? I think wanna-build access and the ability to upload packages are important things an arch needs to be able to do. I think having testing and stable is important too. I can understand *some* criteria for getting access to these resources (5 DDs willing to sign off on the arch, at least 2 buildds, whatever) but not those outlined above... > I see no reason why a team of interested individuals can't make this > happen - magic smoke is cheap, after all :) It's still not entirely clear that distcc is the solution to the problem here. Additionally, I'd rather have DSAs for things as they become available than forcing us to wait till all archs are done to make a DSA, in general. If that takes care of the N <= 2 requirement, then great. Stephen signature.asc Description: Digital signature
Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting
* Brian Nelson ([EMAIL PROTECTED]) wrote: > I agree. It's become quite evident that Debian is barely able to make > releases at all with the status quo. And, given a choice between having > no stable releases at all and having stable releases of a significantly > reduced number of arches, I'd gladly choose the latter. > > What baffles me is why so many seem to miss this point and instead have > decided to turn it into a religious flame war. I'm not sure that we've entirely missed the point as much as we like to think there's a better solution than dropping all but 4 archs. We're then frustrated that instead of being given reasons for the change we were given rules. It's difficult to come up with a solution to a rule. Stephen signature.asc Description: Digital signature
Re: Back to basic (was: Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting
* Thijs Kinkhorst ([EMAIL PROTECTED]) wrote: > Example minimal quality standards: > - it should have a large part of the packages built > - there should be enough buildds to keep up with security and new uploads > within reasonable time. > - there should be some minimal team to support this architecture > Any arch / porting team that satisfies our demands can be included. > > I honestly think that we (almost) all agree that putting these kind of > demands in place is not too much to ask. What exactly the thresholds > should be, that's a point of discussion. Let's first start to see whether > we agree that putting these demands on an arch this is neccessary to > remain our overall quality. we could then, if we do, start working on > drafting up the exact demands and parameters. These don't seem bad. It doesn't solve some of the problems I believe the proposal was intended to solve though: The release team doesn't think it can handle any more than X archs where X seems to be 4 or 5. I also understand it to be the case that the release team doesn't think additional people (or anything?) would help. Personally I can understand this in some regards, toolchain problems, d-i issues, etc that can't really be parallelized. I'm not convinced that this is the real driving factor with some of these requirements though and that this would be impossible to improve. As far as I can tell, without any actual word from them, I believe the ftpmasters/DSA feel that there's a certain number of machines (including things like buildds and whatnot) that they can support. In this case it doesn't seem like adding people could *not* help so I'm guessing the concern there is that there aren't enough trusted people willing to join ftpmasters/DSA to increase the number of machines capable of being maintained much. As I understand it, there wasn't anyone who's active on the security team who was at the meeting to help draw up the proposal but I believe it's been said that they also have an idea as to the max number of architectures they can support. It's not clear if that's got anything to do w/ the number of people or just the general quality of buildds and in some cases maintainers (kernel at least?). Personally I tend to think it's probably some of both- manpower and buildd infrastructure stability. There are some other technical issues having to do with the way wanna-build works and that having testing for all architectures will overload a very nice system with ssh connections. There is work being done to fix this already by using ssh connection cacheing. I'd hope for a more in-depth look and possible rewrite/rearchitecting of wanna-build, this limitation is somewhat concerning. Another technical issue is mirror space but I think that's handled just fine by only mirroring certain architectures, as I understand the plan is, and I think there will still be some mirrors who will mirror everything so I think that'll be alright in general. These are just my speculations and guesses, I'd love for those involved to step up and correct me. If I'm right it'd be nice to get some validation. Stephen signature.asc Description: Digital signature
Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting
* Anthony Towns (aj@azure.humbug.org.au) wrote:
> 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.
>
> >>- 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.
These two conflict to some extent I think. Is there a reason to
disallow the possibility of having a DD who is part of DSA only to admin
a specific box and has no access on any others? Perhaps 'DSA' wouldn't
be the appropriate term for that and the entry bar would be a bit lower.
I think there might be more willingness by otherwise busy people to help
out in this regard if they just have to worry about *their* machine. I
think there'd be an increased sense of committment there too.
Stephen
signature.asc
Description: Digital signature
Re: s390 not currently projected releasable (was: Re: Dropping from mirror network vs dropping from tier-1)
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote: > Blars Blarson <[EMAIL PROTECTED]> writes: > > Another architecure that isn't keeping up to the 98% mark has a buildd > > mainainter who insists (to the point of threating) that I don't build > > and upload packages to help the build with its backlog and lack of > > requeueing. > > So? A buildd maintainer doesn't have a veto over other people > uploading binary builds of packages. W-b and buildd's do not have a Well, that's not *necessairly* true. If the buildd maintainer is also part of DSA/ftpmasters (as seems to often be the case, and might even be required by some unwritten law) then it'd be possible for them to disable the account doing the uploading. I don't know if that's what the threat was and I've never heard of this being done to a DD but it's certainly in the realm of possibility. > monopoly over binary NMUs; the procedures are well documented in the > Developer's Reference. Seems to me that either the package maintainer > or the porting team should be consulted, but given that, the buildd > has no special status or authority. It's a nice thing, but it's not > the only way to upload binary NMUs. It's not quite that simple, buildds have to coordinate to avoid duplicating work or attempting to build things that can't be built, etc. Starting up a buildd that doesn't coordinate with the others could disrupt things and cause alot of duplicated work and possibly other problems, as I understand it. Apparently this coordination is less than stellar at scaling which may have been the reason for denying buildd addition in the past. Stephen signature.asc Description: Digital signature
Re: Bits (Nybbles?) from the Vancouver release team meeting
* Steve Langasek ([EMAIL PROTECTED]) wrote: > On Mon, Mar 14, 2005 at 11:41:59AM +, Steve McIntyre wrote: > > 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 reasons are technical problems that I'd like to think the Debian community would be happy to step up and try to help with. I'm personally interested in this and I know others have even worked on a complete rewrite of wanna-build. I understand the security concerns but I don't agree with them. If you want some statistics about trojans consider the size of our developer base, the fact that anyone can upload binary packages for any architecture and that there's no check that an uploaded source matches the uploaded binary. In general I think buildd maintainers and local admins should be vetted and trusted, either by having them be DDs themselves or through some other process. It would be possible to reduce the abilities of a buildd too- a simple example would be that buildds can only upload binary packages for the architecture they're understood to be building for, and none of them can upload arch all packages. This should at least reduce the number of people affected by a buildd upload being trojaned dramatically through the simple fact that most uploads are i386 by DDs and most users are using i386. > 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. I'm not a big fan of waiting around to see if a stop-gap measure helps. I'll certainly be happy if it means that ftp-master can support (3 buildds x 3 dists x 11 archs) 99 buildds but I'm afraid in the end it's not going to be enough to allow more than 3 buildds per arch and as many archs we have now and as many as would like to join. Stephen signature.asc Description: Digital signature
Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting
* David Schmitt ([EMAIL PROTECTED]) wrote: > Another factor might be security support: > > At least one buildd (plus hot-standby) must be available [under strict > DSA/Security administration] which is fast enough to build security updates > without infringing on vendor-sec embargoes. I'm not 100% sure that's quite right... As I understand it, the people maintaining buildds need to be trusted and perhaps to sign an NDA or something saying they won't go blab to the world about a package going through their testing queue. I don't believe that's quite the same as requiring that the buildd be under DSA, unless DSA is expanded to include what I describe above... Stephen signature.asc Description: Digital signature
Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting
* 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.. Stephen signature.asc Description: Digital signature
Re: master's mail backlog and upgrade time
* Ian Jackson ([EMAIL PROTECTED]) wrote:
> Steve Langasek writes ("Re: master's mail backlog and upgrade time"):
> > So accept it and auto-discard it instead, if you prefer; but don't throw it
> > back at master after telling master to send it to you.
>
> I'm strange in that I like my mail to be reliable.
>
> In particular, I want people who try to mail me, and fail, to be told
> about it. This is unpopular in these days of dumbed-down, and even
> hidden, error messages. But I still think it's right.
Then bounce it locally. Duh. No reason to force master to deal with
the bounce messages you feel are 'right' to send.
Stephen
signature.asc
Description: Digital signature
Re: master's mail backlog and upgrade time
* Ian Jackson ([EMAIL PROTECTED]) wrote:
> Stephen Frost writes ("Re: master's mail backlog and upgrade time"):
> > Then bounce it locally. Duh. No reason to force master to deal with
> > the bounce messages you feel are 'right' to send.
>
> I don't bounce it. I reject it at SMTP time with a 4xx or 5xx code.
Congradulations! You've found the problem!
Thanks,
Stephen
signature.asc
Description: Digital signature
Re: master's mail backlog and upgrade time
* Andy Smith ([EMAIL PROTECTED]) wrote: > You would prefer that Ian: > > a) inflict bounce spam scatter on the forged from addresses in the >malware and spam he doesn't want to accept delivery for; or That is what he's said he wants to do. What I want him to do is have *his* servers do it, not make master do it. > b) silently discards such mails resulting in the possibility of >legitimate mail being lost; or > > c) just accepts the spam/malware? > > I'm guessing (b), with the reasoning that if he chooses to reject > mail that his system thinks is bad then it's his problem to deal > with any false positives. It's his choice to do either (a) or (b) or (c). I couldn't care less which he does provided *he* does it. I do *not* want him to make master do (a) for him. > However in this day and age of the unwanted ratio of email being > greater than the wanted ratio, any system which accepts a lot of > unwanted email and then fails to deal with the refusal to accept by > systems further down the line is in real trouble. I do pretty much > the same as what Ian does, as I have explained, and so do many > others. It's the best way to deal with such mail: don't accept > what you're not prepared to deal with. Don't do this to servers which are forwarding mail to you (upon request). It's inconsiderate, at best. > Instead of either side in this debate saying "Not my problem, you > should do this..." how about reaching some compromise? It sounds > like in the short term, Ian needs to discard some mail instead of > rejecting, and in the long term master needs to be able to cope with > this sort of thing. The absolute worst thing to do is to start > generating bounces to these forged addresses however. Erm, that's *exactly* what's happening today though, it's just that Ian's making master do it instead of doing it himself. Stephen signature.asc Description: Digital signature
Re: master's mail backlog and upgrade time
* Henrique de Moraes Holschuh ([EMAIL PROTECTED]) wrote: > Since we are talking about it, it is not always trivial to special-case an > incoming connection for a local bounce instead of a SMTP-level bounce, > though. At least not with all MTAs. Using an MTA with the capabilities you need should be a prerequisite to running an MTA. > I can do so with postfix because I have a two-layer setup anyway (mail gets > twice through the system, for content filtering with extremely high input > rate. I just tell the first instance to let master through, and the second > one to reject -- this causes a *local* bounce, as mail is already queued and > accepted). I am not even sure if it can be done [in postfix] in a single > layer setup (smtpd->queues->MDA). Anyone would know how to do it? I expect you could do it though I havn't tried myself because I'm not a big fan of smtp-level rejects exactly for these reasons. I just accept and then discard (at least for known userids, but I don't expect many people to be setting up forwards for non-existant userids). I would have thought that at the least you could accept it, detemine it's SPAM and then have a procmail bounce-creating rule without all that much difficulty. Enjoy, Stephen signature.asc Description: Digital signature
Re: master's mail backlog and upgrade time
* Steinar H. Gunderson ([EMAIL PROTECTED]) wrote: > On Fri, Nov 18, 2005 at 02:11:43PM -0500, Stephen Frost wrote: > > I expect you could do it though I havn't tried myself because I'm not a > > big fan of smtp-level rejects exactly for these reasons. I just accept > > and then discard (at least for known userids, but I don't expect many > > people to be setting up forwards for non-existant userids). > > What do you do when you encounter a false positive? Not everybody has the > luxury of affording to have their legitimate mail eaten silently. This is rather orthogonal to the issue at hand, but since you asked, I don't do anything about false positives. If I learn about it then I'll adjust my rules. I don't think it makes sense to create a bounce for every spam that comes my way though. Thanks, Stephen signature.asc Description: Digital signature
Re: master's mail backlog and upgrade time
* Ian Jackson ([EMAIL PROTECTED]) wrote:
> Stephen Frost writes ("Re: master's mail backlog and upgrade time"):
> > * Andy Smith ([EMAIL PROTECTED]) wrote:
> > > a) inflict bounce spam scatter on the forged from addresses in the
> > >malware and spam he doesn't want to accept delivery for; or
> ...
> > It's his choice to do either (a) or (b) or (c). I couldn't care less
> > which he does provided *he* does it. I do *not* want him to make master
> > do (a) for him.
>
> The problem with no-one sending bounces is that _legitimate_ mail
> which is _mistakenly_ tagged as spam just vanishes.
Life's a beach. I don't think creating huge numbers of bounces
is better than this. Make no mistake, that's what you're doing, even
though you're making other systems do it for you it's your fault they're
happening.
> So if I have my system say `250' to a piece of mail, I'm guaranteeing
> that either I'll bounce it (and get a `250' on the bounce), or that
> some human (me or someone else I know) will read it.
Sure, so say '250' and then bounce it if you want to later. That's
basically the *point* here. master's forwarding the mail for you, you
should accept it and then you can decide to either read it yourself or
bounce it. You do *not* need master to bounce it for you!
> The only practical solution to this problem in the modern environment
> is to never accept mail that you don't want. Unfortunately master's
> policies make it impossible for me to arrange to do that. I can do
> what I can, though, and try to push the problem closer to the place
> where it can be solved.
Blacklisting obviously has its own problems. It's your choice to do it
but don't do it to hosts who are forwarding mail to you. If you can't
figure out which hosts are forwarding to you and which aren't then
either don't blacklist or don't run a mail server.
Thanks,
Stephen
signature.asc
Description: Digital signature
Re: master's mail backlog and upgrade time
* Wouter Verhelst ([EMAIL PROTECTED]) wrote: > I don't want to accept any random crap that a forwarding host might send > me just because I asked it to forward mail for me; my resources (in the > form of bandwidth, processing time, and disk space) are limited, and if Then don't run a mail server. Thanks, Stephen signature.asc Description: Digital signature
Re: master's mail backlog and upgrade time
* Brian May ([EMAIL PROTECTED]) wrote: > Are you saying you should bounce SPAM mail??? *I* don't bounce much of anything. Talk to Ian about wanting to generate bounces, it wasn't my idea. What I want is for him to bounce it himself if he feels it needs to be bounced, not make master do it. No, I don't think trying to enforce his policies on master is an option either, sorry. The real point here is that, for mail coming from master, it's *going* to get bounced one way or another, unless Ian decides to try to classify the message himself as 'deserving a bounce' or not. > Yes, in this case the mail would bounce anyway, but I think the > solution is to improve the SPAM checking on master, and not accept the > mail in the first place. Even with better SPAM checking on master it's very unlikely that master's policy will ever agree completely with Ian's (and everyone else's, whose policies are probably different from Ian's..) and so this kind of setup is unlikely to ever actually work (where you're depending on your forwarding hosts to implement the same policy you have). > Yes, you could probably make mail from master.debian.org bypass SMTP > level SPAM controls, but taken to the extreme, you would have to also > do this to every server that forwards you email (perhaps even every > mailing list server?). That would be the point, yes. Taken a bit further, you'd have to clasify the mail as SPAM or not yourself and generate a bounce or not as appropriate. It's honestly not all that difficult. Thanks, Stephen signature.asc Description: Digital signature
Re: Stephen Frost MIA?
* Jos? Luis Tall?n ([EMAIL PROTECTED]) wrote: > Having sent you e-mails with my last answers to the Tasks&Skills > stage of the NM process on 2005/10/05, and having received receipt > confirmation from you on 2005/10/18, i still have no answer from you. > Moreover, i have ping'd you on 2005/10/07, 10/12, 10/15 and 21/11; > No answer so far either. Err, I replied to one of your pings on 10/17. I don't think I really need to reply to each and every one individually. Did you not get the reply I sent? Thanks, Stephen signature.asc Description: Digital signature
Re: Any volunteers for ploticus in Debian?
* Simon Huggins ([EMAIL PROTECTED]) wrote: > Does anyone want to adopt/help with the ploticus packages in Debian? I'm only slightly better than MIA (and some might dispute even that), but I'd really like to see ploticus in Debian updated/improved. I don't use it much myself but it's one of the packages we considered doing some of our web graphs in and I think is certainly something we'll probably use in the future. I can try and help. Thanks, Stephen signature.asc Description: Digital signature
Re: For those who care about their packages in Ubuntu
* Matt Zimmerman ([EMAIL PROTECTED]) wrote: > > * for unmodified debs (including ones that have been rebuilt, possibly > >with different versions of libraries), keep the Maintainer: field the > >same > > Joey Hess and others in this thread have said that this is not acceptable to > them. What I need from Debian is either a clear consensus resulting from > discussion among developers, or an official decision from a position of > authority. Otherwise, we'd just be chasing our tail trying to please > individuals with conflicting opinions. Maybe I missed something, but has someone actually said they'd be unhappy if the Maintainer: field was an appropriate Ubuntu person? Some might be alright with leaving Maintainer alone if the package hasn't been changed, some might be alright with leaving it the same even if the package has been changed and some might always want it changed, I don't expect you'll get a concensus on that. I'd be suprised if someone was actually unhappy with the Maintainer field changing though. Of course, don't submit a patch back to Debian which includes changing the Maintainer field. > > * for maintainers who want to keep their name in the maintainer field, even > >when modified by Ubuntu, invite them to join Ubuntu in the usual manner > > I don't see how this would help. If we were to institute a policy (or more > likely, an automated process) to change the maintainer field, inviting the > maintainer to become an Ubuntu developer wouldn't have any obvious effect on > the process. What did you have in mind here? It's similar to my comment above- set the maintainer to an appropriate Ubuntu person, which would naturally be the Ubuntu package maintainer, who might also be the Debian package maintainer. Really, though, this isn't a Debian concern or problem- if the Ubuntu developers are complaining about an automated Maintainer-changing script then that's an issue Ubuntu needs to deal with and figure a way around, or just ignore. It's certainly not an excuse to leave the Maintainer field alone. Thanks, Stephen signature.asc Description: Digital signature
Re: Debian derivatives and the Maintainer: field (again)
* Matt Zimmerman ([EMAIL PROTECTED]) wrote: > I would very much appreciate if folks would review > http://lists.debian.org/debian-devel/2005/05/msg00260.html and consider the > points that I raise there. I put some effort into collating the issues > which came up the last time and presenting them. > > It is important, in particular, to account for the fact that Ubuntu is not > the only Debian derivative, and that proposals like yours would amount to > Debian derivatives being obliged to fork *every source package in Debian* > for the sake of changing a few lines of text. You're already rebuilding the package, which I expect entails possible Depends: line changes and other things which would pretty clearly 'normally' entail different Debian package revision numbers; changing the Maintainer field at the same time is just not that hard, *especially* when you're rebuilding the package. You're implying that this is alot of work and it's just not. It's also not 'forking' in any real sense of the word. You don't even have to change the version number if you don't want to. When done in Debian, it's also not even a new source package (in general anyway) as the thing which has the Maintainer field is actually the patch. As I've pointed out before, this also just plain isn't Debian's problem. You keep asking for Debian to tell you what 'should' be in the Maintainer field but then you're ignoring the answer because you think it's hard. It's pretty clear what 'Debian' thinks *should* be in the field, or at least what most people would agree with; sorry that it's not the simple answer you want but you asked. Thanks, Stephen signature.asc Description: Digital signature
Re: Debian derivatives and the Maintainer: field (again)
* Matt Zimmerman ([EMAIL PROTECTED]) wrote: > On Tue, Jan 17, 2006 at 03:07:25PM -0500, Stephen Frost wrote: > > You're already rebuilding the package, which I expect entails possible > > Depends: line changes and other things which would pretty clearly > > 'normally' entail different Debian package revision numbers; changing > > the Maintainer field at the same time is just not that hard, > > *especially* when you're rebuilding the package. > > > > You're implying that this is alot of work and it's just not. It's also > > not 'forking' in any real sense of the word. You don't even have to > > change the version number if you don't want to. When done in Debian, > > it's also not even a new source package (in general anyway) as the thing > > which has the Maintainer field is actually the patch. > > You quite obviously haven't read > http://lists.debian.org/debian-devel/2005/05/msg00260.html yet, where I > wrote (among other important things), "it would be fairly straightforward > for Ubuntu to override the Maintainer field in binary packages". I > explained exactly what is and isn't difficult and for whom. Wow, is this ever silly. Of course I read it and I appreciate your position that it's more work than not doing anything different from what you're doing now but I simply disagree about it and it seems like a pretty straight-forward solution to implement. I also understand that not all Debian derivatives are changing the Maintainer field and that Debian's not specifically chastising them for it. There are reasons for each though. Other Debian derivatives aren't (or at least, don't seem) as popular so it's less of an issue; other derivatives don't come across as pulling resources away from Debian (which Ubuntu seems to be doing, reality aside, that's the perception); other derivatives didn't ask and sometimes that's just the burden you have to bear when you're actively trying to do the right thing; other derivatives (some portion of them anyway, I expect) don't recompile packages (which makes leaving the Maintainer field alone somewhat less of an offense to some). > If you're going to attack me, please do it on the basis of what I've > actually said. Honestly, I expected better from you, give that you've acted > like a human being toward me on IRC on several occasions in the past. Funny, I didn't think I was attacking you at all. Rereading what you quoted above I really don't see how that's an attack and I'm afraid perhaps you've gotten a little sensitive on this. I'm happy enough to excuse that as I'm sure you've gotten a fair number of poor reactions from others. Looking through my other emails on the subject it seems perhaps unkind of me to say you're ignoring the answer but, well, that's how it's coming across. :/ Thanks, Stephen signature.asc Description: Digital signature
Re: Debian derivatives and the Maintainer: field (again)
* Matt Zimmerman ([EMAIL PROTECTED]) wrote: > On Wed, Jan 18, 2006 at 12:34:33AM +0100, Florian Weimer wrote: > > FWIW, I think your implied assumption that all Debian derivatives should > > be treated the same is flawed. Ubuntu is just not like any other > > derivative, it's a significant operation on its own. Its commercial > > backer is apparently able to pay quite a few Debian developers, several of > > them among the core team. There is a significant user base, and so on. > > Like it or not, Ubuntu is a bit special. > > I can't accept this; if there is no principle here which should be applied > consistently, then it's entirely unfair to attack Ubuntu. Certainly, there > are things about Ubuntu which are unique, but none of them change the issues > at hand. Personally I think the principle *should* be applied consistently but as a volunteer and with generally not much time I'm not going to hunt down every Debian derivative out there, see what they do and complain at them if they're not doing it the right way. I doubt it'd have any effect in the majority of the cases anyway. Ubuntu, by trying to do the right thing (which many of us appreciate) and by asking the question of what *should* be done has put themselves in a position where if they don't do what 'should' be done, regardless of what others do, they're going to seem like bad guys. Also, I'm afraid, given Ubuntu's popularity and the impression (unfounded or not) that Ubuntu is taking resources away from Debian is going to mean Ubuntu will be held to a higher standard than other derivatives. I think many of us would like to see Ubuntu be the best derivative and always do the right thing and that's why there's more pressure on Ubuntu than other derivatives. > Seriously, it's entirely unreasonable to single out Ubuntu on this issue. Perhaps so, but then Ubuntu's just another derivative and not the derivative many of us would like to see it be, and I expect the derivative that Ubuntu itself would like to be from a PR standpoint. Thanks, Stephen signature.asc Description: Digital signature
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
* Ben Collins ([EMAIL PROTECTED]) wrote: > The guidelines are aimed at the wrong thing is my point. I agree with this. I also think that this is one of the reasons why there's been so much uproar about them. Stephen signature.asc Description: Digital signature
Re: Emulated buildds (for SCC architectures)?
* Gunnar Wolf ([EMAIL PROTECTED]) wrote: > Most (although not all) of the architectures facing being downgraded > are older, slower hardware, and cannot be readily found. Their build > speed is my main argument against John Goerzen's proposal [1]. Now, I > understand that up to now we have had the requirement of the builds > running in the real hardware. Chances are this wouldn't change for 'official' buildds. While not speaking on behalf of the ftpmaster team the impression I've gotten from Anthony at least is that emulated buildds begs the question of the architecture being useful and aren't exactly likely to be met with open arms. Apparently the feeling wrt distcc is somewhat different and is likely to be a more generally accepted solution to the slow-at-compiling issue. Stephen signature.asc Description: Digital signature
Re: Buildd redundancy (was Re: Bits (Nybbles?) from the Vancouver...)
* Andreas Barth ([EMAIL PROTECTED]) wrote: > * Steve Langasek ([EMAIL PROTECTED]) [050319 12:35]: > > On Wed, Mar 16, 2005 at 12:20:34AM -0800, Blars Blarson wrote: > > > - at least two buildd administrators > > > > > This allows the buildd administrator to take vacations, etc. > > > This is at odds with what I've heard from some buildd maintainers that > > having multiple buildd maintainers makes it hard to avoid stepping on one > > another's feet, so I wouldn't want to set a requirement like this without > > further discussion. > > Actually, there was some discussion about that in Vancouver :) > > It boils down to more or less having at least two people to be able to > maintain any of the buildds, so that if the primary buildd admin goes on > vacation / is ill / ..., that doesn't put this buildd completly off-line. > In fact, this has already happened in the past, without anybody except > the buildd admins noticing it. It strikes me as rather silly that Debian can't come up with a way for two people to be able to work with a single buildd, either at the same time or not. It would probably require *some* talking/coordination between them but tools could be written to help with that a great deal. Stephen signature.asc Description: Digital signature
Re: my thoughts on the Vancouver Prospectus
* Peter 'p2' De Schrijver ([EMAIL PROTECTED]) wrote: > On Sun, Mar 20, 2005 at 09:27:26AM +0100, Matthias Urlichs wrote: > > Hi, Peter 'p2' De Schrijver wrote: > > > > > This is obviously unacceptable. Why would a small number of people be > > > allowed to veto inclusion of other people's work ? > > > > Why not? (Assuming they do have a valid reason. For instance, I probably > > wouldn't allow an MMIX port into the archive even if it sat up and begged.) > > Because it's not fair ? I would allow an MMIX port if it would exist and > work. Nor is it fair to lump a ton of additional work on volunteers who aren't interested in doing it.Were a veto to be used it'd probably be discussed a fair bit and I imagine there'd be an opportunity for someone to stand up and take up the release work for the about-to-be-veto'd arch. The problem is getting someone to actually do it. Stephen signature.asc Description: Digital signature
Re: my thoughts on the Vancouver Prospectus
* Anthony Towns (aj@azure.humbug.org.au) wrote: > >If this is the case, I think that needs to be made clearer to avoid > >situations where people work to meet the criteria but are vetoed by the > >release team because there are already too many architectures. > > The main issue is the port needs to be on top of problems quickly and > effectively; in many cases we won't know what those problems are 'til > they happen (and thus can't say "your port mustn't have such-n-such a > problem"), the criteria listed are meant to be reasonably objective ways > a port team can demonstrate that they're able to handle problems that arise. Sometimes I worry that these issues aren't brought up to the attention of those who would be most likely to care about it. A call for help on -devel or -release about $arch needing xyz, or worse having the problem be outlined only in some deep thread or discussed on irc, seems less likely to generate a useful response as a mail to -$arch. I don't currently follow all of the -$arch lists (mainly just -mips) but I don't recall having seen much there about these issues. Stephen signature.asc Description: Digital signature
Re: Emulated buildds (for SCC architectures)?
* Anthony Towns (aj@azure.humbug.org.au) wrote: > >Apparently the feeling wrt distcc is somewhat different and is likely to > >be a more generally accepted solution to the slow-at-compiling issue. > > I like distcc -- heck I went to high school with the author -- and I > think it's cool. I don't know that it'd be enough to get ports like m68k > working quickly enough to meet the 1 or 2 buildds requirement, and it > doesn't solve the other issues that arise at all. But hey, I wouldn't > have a problem with an m68k+distcc/i386 pairing as a buildd, if all the > other requirements were also being dealt with properly. That's also more > a DSA/buildd issue though, neither of which are hats of mine. Alright, perhaps I misunderstood the responsibilities a bit. buildds are run by DSA (Which I'm guessing is the 'System Administration' group on w.d.o/intro/organization)? Is access to wanna-build also managed by that group? That's mainly what I was driving at really- will an emulated/distcc buildd be allowed to access wanna-build & co. and be acceptable to meet the release criteria? I thought the general feeling was 'emulated - no, distcc - perhaps' but now I've got no idea since it seems the appropriate people havn't commented. Speaking of which, if DSA are the appropriate people, who in that group are active in that role, esp. wrt the buildds? That group has 5 people but I only know of two (James Troup & Ryan Murray) who have been active wrt buildds. I'm still a bit confused though since I really thought the buildds fell more under the perview of ftpmasters for whatever reason... Stephen signature.asc Description: Digital signature
Re: unixODBC vs. iODBC
* Brian Nelson ([EMAIL PROTECTED]) wrote: > Qt in Debian must build against libiodbc2-dev because otherwise it would > have a circular build-dependency with unixodbc. Circular build-deps aren't necessairly a real problem. There's a fair amount of other stuff which have them and in general I think mostly it's just a bootstrapping issue. Doesn't seem like a good enough reason to keep around something no one seems to want... Stephen signature.asc Description: Digital signature
Re: Bug#305287: ITP: slony1 -- Slony-I is a "master to multiple slaves" replication system with cascading and failover.
* Tim Goodaire ([EMAIL PROTECTED]) wrote: > I haven't been able to find an ITP for this. I've found an RFP for it > though (278810). Is this what you're referring to? Yes. > Also, my ITP bug (305287) has already been closed on me. Apparently I Yes, I closed it since it was a duplicate WNPP bug. > was supposed to change the title of the RFP bug to ITP, but I've been > unable to find anything in the Debian maintainer's documentation that > would indicate that this is what you're supposed to do. Is this just > common practice or something? This is my first attempt at packaging > something for Debian. The developer's reference (http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-newpackage) would lead you to http://www.debian.org/devel/wnpp/ which outlines how to use WNPP, specifically under "Removing entries" there's: RFP If you are going to package this, retitle the bug report to replace .RFP. with .ITP., in order for other people to know the program is already being packaged, and set yourself as the owner of the bug. Then package the software, upload it and close this bug once the package has been installed. Of course, it'd be good to *read* the RFP bug before retitling it, etc, which would have provided you with the information I wrote about in my prior email- specifically that there's a number of other people working on slony packaging already and there's specific and good reasons why it hasn't already been uploaded to the archive. I don't particularly care who ends up maintaining the package but it's more than a little annoying to have someone not read the documentation, prior bug reports, or apparently even look for prior bugs and then be bitched out by what I'm guessing was your boss on IRC for pointing out to you the existing bug report and why it hadn't been uploaded yet. As an additional tidbit- it'd probably be best to wait till the 8.0 debs are in Debian before putting the slony packages in to avoid what will probably be a great deal of ugliness in the transistion from one packaging methodology to another in the main Postgres packaging. The 8.0 debs are already in experimental, they're mainly waiting for sarge to be released before going into sid because of the libpq SONAME bump. Thanks, Stephen signature.asc Description: Digital signature
Re: [HELP] libldap2 2.1.30 breakage?, guru for ld.so needed
* Simon Richter ([EMAIL PROTECTED]) wrote: > Torsten Landschoff schrieb: > > > Suggestions how to fix that for real before getting sarge out of the > > door with this risk that I don't feel I can estimate? > > Build a dumy libldap.so.2 with the same SONAME that consists of a NEEDED > entry for libldap_r.so.2 only. Completely breaks dlopen()'ings of libldap2. Don't know if there are any in sarge but don't see any reason to break them if there are. Stephen signature.asc Description: Digital signature
Re: [HELP] libldap2 2.1.30 breakage?, guru for ld.so needed
* Nigel Jones ([EMAIL PROTECTED]) wrote: > Unless there is a related RC bug there, I don't think it's gonna > matter when the change is to get it in sarge (i personally have not > seen any RC bugs though...) There's RC bugs all over this. Stephen signature.asc Description: Digital signature
Re: [HELP] libldap2 2.1.30 breakage?, guru for ld.so needed
* Torsten Landschoff ([EMAIL PROTECTED]) wrote: > At first sight this looked (for me) like making sense and having no > negative implications. Of course reality was different - ldconfig had > problems setting the right symbolic links. setting the right symbolic links? It's not being used to set the symbolic links any different than it was before, it's just at the end we twiddle them a bit because having both libraries was a serious problem. > Today I found out the reason. It was not that it just removes symbolic > links it can't make sense of. Rather the problem is that the SONAME of > that library now does not match the name anymore. Well, no, but the linker can handle that. > libldap.so.2 used to have the SONAME libldap.so.2 as you would expect :) > Now the libldap.so.2 is a symlink to libldap_r.so.2 which has SONAME > libldap_r.so.2. > > I wonder which implications that could have when applications are > linking to libldap.so.2 (as the SONAME is no longer found). Nothing should care except for the runtime linker, which should handle the situation correctly. > Therefore I thought it might be a good idea to relink libldap_r.so.2 > using libtool and create libldap.so.2 with matching soname. Now I wonder > what will happen if some program decides he wants to link both > libldap.so.2 and libldap_r.so.2. All hell breaks loose, that's what caused the various RC bugs I closed with the message above. You end up randomly getting one set of symbols that expects to do threading and locking and another set that doesn't. > Suggestions how to fix that for real before getting sarge out of the > door with this risk that I don't feel I can estimate? Have you actually got a specific problem with the changes I did, or really, the results of them? There were a couple problems where people had old libldap2's hanging around (which is a rather serious mistake anyway...) but I havn't seen any other problems with that change yet... Thanks, Stephen signature.asc Description: Digital signature
Re: [HELP] libldap2 2.1.30 breakage?, guru for ld.so needed
* Simon Richter ([EMAIL PROTECTED]) wrote: > Stephen Frost schrieb: > > Completely breaks dlopen()'ings of libldap2. Don't know if there are > > any in sarge but don't see any reason to break them if there are. > > dlopen() should handle dependency libs just fine, I think. If dlsym() > fails because the symbol is actually in another lib, maybe DT_FILTER > might help. More ugliness, and it sounds like it's not even clear it'd actually work in the dlopen()/dlsym() case.. Perhaps if there was actually a problem with the symlinks, but I havn't heard of one really with them yet.. Stephen signature.asc Description: Digital signature
Re: Canonical and Debian
* Steve Langasek ([EMAIL PROTECTED]) wrote: > Clone yourself and make yourself a slave to the buildds for 7 or 8 > architectures, so that the release team doesn't have to. Neither the Whoah, whoah, whoah, is this actually an option? Last I checked that answer was 'no'. Hell, that's most of the *problem* here. The limited set of people running the buildds don't want to spend more time but being allowed to be a buildd maintainer seems to be limited to a rather small set of folks. There seems to be a few different reasons for this, but one of the big ones is wanna-build access, I believe. This is because of limitations of the current wanna-build framework, which may have now been resolved? Having the porters run the buildds sounds like a great idea to me, and if you can't get anyone to run/maintain a buildd for an architecture, then too bad for that architecture; but don't come out and say we need more people maintaining buildds but then also say we can't have any more buildds due to architecture limitations and say that the current buildds have maintainers or that we can't let anyone else maintain them because of security concerns or whatever. Thanks, Stephen signature.asc Description: Digital signature
Re: Canonical and Debian
* Colin Watson ([EMAIL PROTECTED]) wrote: > On Mon, Jun 06, 2005 at 02:12:00PM -0400, Stephen Frost wrote: > > * Steve Langasek ([EMAIL PROTECTED]) wrote: > > > Clone yourself and make yourself a slave to the buildds for 7 or 8 > > > architectures, so that the release team doesn't have to. Neither the > > > > Whoah, whoah, whoah, is this actually an option? Last I checked that > > answer was 'no'. Hell, that's most of the *problem* here. The limited > > set of people running the buildds don't want to spend more time but > > being allowed to be a buildd maintainer seems to be limited to a rather > > small set of folks. There seems to be a few different reasons for this, > > but one of the big ones is wanna-build access, I believe. This is > > because of limitations of the current wanna-build framework, which may > > have now been resolved? > > I don't think Steve was talking about needing more buildd maintainers; > he was talking about the task of chasing up issues involved in trying to > get required package uploads built everywhere, which currently ends up > being a very significant time drain on the release team (since that's > the set of people who know which uploads have the highest priority). Perhaps that issue needs to be brought up more directly with the porters then, if possible. ie: Put a request out there for porters to check over what packages havn't been built for their architecture? I'm not entirely sure if that could really be easily extracted out seperately from what a buildd admin does (which would imply that we *do* need more buildd admins if only to help with this not-directly-answering-buildd- emails issue). Also, doesn't 'get required package uploads built everywhere' imply 'ask the buildd admins what the story wrt a current package is', at least in some cases? It would seem that if it's possible to decrease the turn-around time on that it'd be of some benefit... Thanks, Stephen signature.asc Description: Digital signature
Re: libselinux1 - required
* Luke Kenneth Casson Leighton ([EMAIL PROTECTED]) wrote: > any progress on making libselinux1 a "Required" package? > > the possibility of having debian/selinux is totally dependent > on this one thing happening. > > no libselinux1="Required", no debian/selinux [all dependent packages > e.g. coreutils will be "policy violations"]. Uhhh, it's the other way around. Get coreutils to Depend on libselinux1 and it'll be brought up to Required. You don't get the library "Required" first, having a library be "Required" but nothing "Required" actually depending on it is senseless. Stephen signature.asc Description: Digital signature
Re: Canonical and Debian
* Steve Langasek ([EMAIL PROTECTED]) wrote: > On Mon, Jun 06, 2005 at 02:12:00PM -0400, Stephen Frost wrote: > > * Steve Langasek ([EMAIL PROTECTED]) wrote: > > > Clone yourself and make yourself a slave to the buildds for 7 or 8 > > > architectures, so that the release team doesn't have to. Neither the > > > Whoah, whoah, whoah, is this actually an option? Last I checked that > > answer was 'no'. > > Well, I think there's still a moratorium on human cloning in the US, isn't > there? Eh, we're working on fixing that. > > There seems to be a few different reasons for this, but one of the big > > ones is wanna-build access, I believe. This is because of limitations of > > the current wanna-build framework, which may have now been resolved? > > I wasn't necessarily referring to being buildd admins. The biggest time > sink, AIUI, is keeping machines of reasonable power up and running, which > ought to be the responsibility of the local admin (porters, presumably); > it's not lack of w-b access which causes buildd starvation for those > architectures that have that problem. > > Yes, I imagine the w-b infrastructure's lack of scalability was probably a > factor in being choosy about what machines to accept as buildds, but there > are certainly going to be other factors that scale linearly with the number > of buildds, so I don't foresee the w-b admins ceasing to concern themselves > with getting the most bang per buildd. But while everyone's fretting over > whether the w-b admins will allow m68k buildd #15 to connect, we have the > following architecture problems right now, in no particular order: Getting the most bang per buildd is great; limiting the number of buildds because wanna-build doesn't scale sucks. What are the "other factors that scale linearly"? As has been told to me of late, better to ask for something than assume it's not available. Additionally, we need to make sure to place the resource drain on the right thing- there's some part of the buildd admin that depends on how many packages are uploaded to unstable and how frequently; the number of buildds which do the building of those packages is an orthogonal issue to that. > - alpha: one buildd, able to keep up with current package volume; no spare > buildd due to the principal candidate being inexplicably unbootable now > (oh yeah, btw, the primary failed and was off-line for a day, a week > before release); no porter machine available. Ok, we need more alpha machines then. If nothing else then at *least* one for porters. Let's ask the debian-alpha list or debian-devel if someone's got a spare alpha they don't mind parting with. I can probably arrange hosting for it, if necessary (one way or another). > - hppa: one buildd, keeps up with package volume, but no backup buildd and > gdb seems to kill its kernel (yay); one porter machine. Well, at least we've got a porter machine, could that be turned into a buildd on relatively short notice if necessary? The gdb issue is something I certainly hope is being looked into or at least has been brought up to the LKML and debian-hppa folks. > - sparc: one buildd which is not consistently able to keep up with the > volume of incoming packages; no backup buildd, no additional porter > machine. Alright, we need more sparc systems, I'm working on getting arrangements for hosting at least one, I've got access to a few others as well. It sounded like there wasn't an issue getting sparc machines donated, so is this just a hosting problem? > - s390: one buildd, which consistently cannot build gtk+2.0 because it only > has 2GB of space available for builds and gtk+2.0's requirements have > recently exceeded this; a second possible buildd is not yet hooked into > w-b because of what appear to be administrative details. (two porter > machines available, though.) > - powerpc: one buildd that's getting long in the tooth; one porter machine. > (obviously a readily available architecture, but that doesn't really help > much if the only configured buildd is down and it takes a week to > designate & configure a new one.) Then let's get another one up and running, do we need to go out and ask for donations? If we get donations, will they be turned down? That's been a historic problem that I'd really hate to see happen again. > I have a really hard time believing that these architectures are blocked > from adding a second buildd due to security or scalability concerns alone > when at the same time we have roughly a dozen m68k buildds... Got me on what the specific problem is, that's kind of what I'm trying to figure out... If we need mor
Re: package building problems (was Re: Canonical and Debian)
* Blars Blarson ([EMAIL PROTECTED]) wrote: > I've been watching the sparc buildd queues for the past 9 months or > so, filing most of the ftbfs bugs for sparc, and prodding the buildd > maintainer when a package needs a simple build requeue or the sbuild > chroot is broken. Great! What mechanisms have you been using to do that, and what could we do to make it easier for other people to do that? Is there a way to get the sparc buildd queues and associated information to be more pro-actively sent to people? I know that, at least for myself, I'm much more inclined to do things or at least try to help with things when an email about a problem shows up in my email client than if I have to periodically check a website, etc. > >4) buildd software issues(pbuild,sbuild,wanna-build,etc) > > occasionally. sbuild is vulnerable to broken packages breaking it's > chroot, sometimes in ways that only effect a few packages and may not > be quickly noticed. > > wanna-build has scalability issues, but it can be bypassed for unstable > if the buildd maintainer doesn't interfere. (Just build and upload > all the new packages.) > > It looks like this software could use some redesign to put less work > on the buildd maintainers and scale better to more buildds. Do you have some specific insights into this? This certainly sounds like a good area for us to work on.. Thanks, Stephen signature.asc Description: Digital signature
Re: Canonical and Debian
* Robert Lemmen ([EMAIL PROTECTED]) wrote: > On Tue, Jun 07, 2005 at 02:12:04AM -0700, Steve Langasek wrote: > > - sparc: one buildd which is not consistently able to keep up with the > > volume of incoming packages; no backup buildd, no additional porter > > machine. > > how powerfull would a machine need to be to be of any help here? would > an ultra 10 or a netra x1 be sufficient? Personally, I'd think it could probably help.. Though at the same time, we should probably consider all the options which are made available in case there's something that wouldn't require much additional effort to maintain but would have more room for growth. Thanks, Stephen signature.asc Description: Digital signature
Re: libselinux1 - required
* Luke Kenneth Casson Leighton ([EMAIL PROTECTED]) wrote: > last time i spoke to him [name forgotten] the maintainer > of coreutils would not accept the coreutils patches - > already completed and demonstrated as working and sitting on > http://selinux.lemuria.org/newselinux - because libselinux1 > is not a "Required" package, and could not be made a "Required" > package because of the sarge freeze. If it was related to sarge being frozen then that issue is out of the way and it should be brought up again if you're interested in it, with the coreutils maintainer, not on d-d. Thanks, Stephen signature.asc Description: Digital signature
Re: libselinux1 - required
* Thijs Kinkhorst ([EMAIL PROTECTED]) wrote: > On Wed, June 8, 2005 12:50, Petter Reinholdtsen wrote: > > In RedHat, using selinux is a run time option. If one don't want to use > it, > > all one need to do is update a config file and reboot. I'm sure can get > > something similar working in Debian. > > If it's not necessary for basic operation of the package, but only for an > optional feature, then a Recommends on libselinux1 would be in order, and > those who don't want it installed can easily not do so. That only works if the package will dlopen() it if it's available and operate normally if it's not. I don't expect that's likely to be the case in this situation. Stephen signature.asc Description: Digital signature
Re: ftp-master, ftp and db .debian.org moving - hosting sought
* Thijs Kinkhorst ([EMAIL PROTECTED]) wrote: > On Wed, June 22, 2005 11:36, Thomas Bushnell BSG wrote: > > I think the point is that we ask for a donation before we spend money > > on it. > > Sure, but the statement quoted above rules it out entirely. "can't pay" is > pretty definitive. I'm wondering why it's that certain that we can't pay > for it. Based on the requirements it seems unlikely Debian would be able to afford to pay for hosting very long with our current donation income amounts. Gigabit network connections and associated rack space is cheaper than it used to be but aiui Debian hasn't got all that much cash. From a bit of googleing what I've seen is around $3k/month for unmetered 100Mb/s, and $10k/month for unmetered 1Gb/s and I'm not sure those would meet the other requirements so the actual price of something meeting all the requirements would probably be higher. > Furthermore, actually paying for it does not create a problem like now > where the hosting gets cancelled suddenly. Not necessairly. Generally you'd hope so but of course if we go with the cheapest place we can find or get a 'deal' from some place for being a non-profit or what-have-you then it becomes much the same situation. What I'd really like to see, personally, would be some place like ibiblio or ISC hosting the servers. Some other thoughts would be places like MIT or CMU or places which currently host primary mirrors. It might make sense to approach some of these places to see if they'd be interested since it's certainly possible they don't follow d-d-a. Of course, this may end up on /. in the end anyway. I do think that if not much is heard before too long we should probably post the call to d-a at least. I'm kind of curious what happened w/ Above.Net since it seemed rather sudden (perhaps it wasn't and it just seemed that way to me but there didn't seem to be any clue what happened, so.. I'm curious :). Thanks, Stephen signature.asc Description: Digital signature
Re: Shared library versioning
* Alexis Papadopoulos ([EMAIL PROTECTED]) wrote: > >It's a single headache for the one library developer/packager, as > >opposed to headaches for _every user_ of the library. > > > Yes indeed, but it's still a headache for one person ;). If that one person isn't willing to deal with it then that person shouldn't be writing libraries. :) > I will take a look into debian-mentors, but I've just talked to the > upstream author and can now explain the reason of his choice. Unfortunately that doesn't make his reasoning right. :) > The thing is that the library is written in C++ and makes heavily use of > templates which means that even a small change in the code, that doesn't > change the ABI, might lead to incompatibility. There's no 'might' about it... Either it changes the ABI or it doesn't. ABI does mean more than just symbols though and so, yes, you do have to be careful and realize when you make an ABI change. > We therefore checked the existant libraries coded in C++, using > templates and present in the debian distribution. We only used two > examples, libginac and libboost-python. We looked both of the shared > libraries present : > libginac-1.3.so.0.0.0 with SONAME libginac-1.3.so.0 : the version is > contained in the SONAME which means that if a program is linked against > libginac-1.3 and only libginac-1.4 is present on the system, it will fail. Generally this is done when there's an API change (which also implies an ABI change) that is pretty significant such that programs written to work with the old API will have to be updated/significantly modified. The expectation is that there would be, in the above case, point releases such as '1.3.1' which would be API-compatible, and if ABI-compatible then the SONAME wouldn't change, and if not ABI-compatible then it would change. Thanks, Stephen signature.asc Description: Digital signature
Re: Shared library versioning
* Alexis Papadopoulos ([EMAIL PROTECTED]) wrote: > >>The thing is that the library is written in C++ and makes heavily use of > >>templates which means that even a small change in the code, that doesn't > >>change the ABI, might lead to incompatibility. > > > >There's no 'might' about it... Either it changes the ABI or it doesn't. > >ABI does mean more than just symbols though and so, yes, you do have to > >be careful and realize when you make an ABI change. > > > The thing is that every change in a template class or function in the > shared library will lead to an ABI change (except some rare cases). > Since the majority of the modifications are made in this section of the > library I don't find absurd to modify the SONAME on each new compilation > of the library (only of course if modification has been made since last > compilation). You're sure the ABI for template classes is that sensitive? If it is then they probably shouldn't be in a library to begin with.. > This goal of all this is to make the update of SONAME as far as I can > automatically. That's almost certainly a terrible idea. > The idea now is to keep two records, one with the sources version and > one with the current soname. On each modification (and CVS commit) of > the sources, if changes have been made to the library's source files, > SONAME is increased, sources version is always incremented. The SONAME > will be (as inspired from libginac) in the following form : > lib*-X.Y.so.0.0.0 (the ending 0.0.0 because of libtool's usage) > or maybe lib*.so.XY (format that is used today by the upstream author) The SONAME needs to match across distributions so it really needs to be managed (and managed correctly) by upstream. If every change to the library requires an SONAME change then it almost certainly should not *be* a library. It would be rather disappointing if what you're saying about C++ template classes is really accurate. Personally, I suspect it's not. Thanks, Stephen signature.asc Description: Digital signature
Re: Shared library versioning
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> > That's almost certainly a terrible idea.
>
> I somehow expected that might come up. I didn't fell to comfortable with this
> idea, but I think there must be another solution than simply doing it "by
> hand",
> a more "elegant" way.
You can't really automate ABI checking... You can compare symbols and
whatnot, but that's not enough.
> That's what the upstream author explained me, and that's what I want to find
> out. Two possibilities, either the upstream author has missed something, or
> there is a proper way of dealing with this kind of situation.
>
> One example that might fail :
> let's say we have a shared library with 2 source files : g.cc and g.h
>
> g.h :
> template
> void g (T x);
>
> g.cc :
> template
> void g (T x) {
>cout << x;
> }
>
> The .h file has to include the .cc one in order for the compilation to work.
Errr... Wait a minute, how's this supposted to work, exactly? I think
we may need to see some real code here. If the .h is including the .cc
then the library doesn't actually need to be linked against anyway...
Let's see a real example where a template class is used and actually
works in a library and then we can talk about it a bit better.
Thanks,
Stephen
signature.asc
Description: Digital signature
Re: Shared library versioning
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: > Well I did say that : "The .h file has to include the .cc one in order for the > compilation to work." > Now if you decide to leave the code that I put into g.cc only the .h file, it > works too... The template class has to actually be included, and so really becomes part of the API... I'd be curious if it'd be possible to change the template class itself in such a way as to make it not be ABI-compatible with the actual .so... > > Yes, so the ABI doesn't change in this case. > > It doesn't, and the modification isn't very important so it isn't a problem. > But > that was only an example, but the body of g can be modified in a way where it > could lead to a failure (because of the use of templates), therefore the > SONAME > muste be changed so as to force usage of the new library. Alright, how about you provide an example of this...? Thanks, Stephen signature.asc Description: Digital signature
Re: Status of inetd for etch
* Marco d'Itri ([EMAIL PROTECTED]) wrote: > On Aug 11, Adam Borowski <[EMAIL PROTECTED]> wrote: > > Why, for the love of Cthulhu, does netbase depend on inetd in the first > > place? Let's see: > Historical reasons. Not good enough. Not even close. > > It would be good to get rid of inetd from the basic install at all. Those > No, it would not. UNIX systems are supposed to have an inetd installed. meh, if the default install has all of the inetd services disabled then it's idiotic to have an inetd installed (and just fucking insane to actually have an inetd *running*). Things which need inetd *should* be required to Depend on it (or some virtual package which provides it). Packages which can run both with and without inetd could 'Suggest' the virtual inetd package. Thanks, Stephen signature.asc Description: Digital signature
Re: ca-certificates symlinks out of /etc
* martin f krafft ([EMAIL PROTECTED]) wrote: > Since #350282 is still being discussed, I ended up doing > > cat /etc/ssl/certs/cacert-class3.pem >> /etc/ssl/certs/cacert.pem > > on systems that needed access to all of CACert's certificates. cat /my/favorite/editor >> /etc/alternatives/vi cat /the/best/dictionary >> /etc/dictionaries-common/words So much for my "configuration". Thanks, Stephen signature.asc Description: Digital signature
Re: ca-certificates symlinks out of /etc
* martin f krafft ([EMAIL PROTECTED]) wrote: > also sprach Stephen Frost <[EMAIL PROTECTED]> [2006.10.31.1948 +0100]: > > cat /my/favorite/editor >> /etc/alternatives/vi > > alternatives are surely an exception, don't you think? > > > cat /the/best/dictionary >> /etc/dictionaries-common/words > > I don't see the reason why /etc/dictionaries-common/words should be > a symlink either. The right way to solve this would be to use > alternatives and provide a second file to which a user can add > additional words. I'm truely unimpressed with the "users can't handle symlinks" argument. There are other cases where symlinks in /etc have been used to capture information (sendmail and/or SASL being another I've dealt with in the past, also vservers) and in general I don't think there's anything wrong with it. In all of these cases the files pointed to are not intended to be modified but what file is used can be configured. I believe the certificates are exactly this way (and, really, are quite close to the alternatives setup). Enjoy, Stephen signature.asc Description: Digital signature
Re: ca-certificates symlinks out of /etc
* martin f krafft ([EMAIL PROTECTED]) wrote: > also sprach Stephen Frost <[EMAIL PROTECTED]> [2006.10.31.2016 +0100]: > > In all of these cases the files pointed to are not intended to be > > modified but what file is used can be configured. > > How are certificate files not intended to be modified? If they > expire? If they are incomplete? If they expire then they should be updated by the package. One does not generally modify issued certificates. If the package isn't handling certificate expiration then the point of having them packaged at all pretty much goes away. Incomplete certificates would be a bug in the package (by incomplete I expect you mean that somehow it's a partial file, if you mean that some certificates are missing, then you're certainly free to add those into that directory as regular files, or to ask for inclusion of them in the package). Thanks, Stephen signature.asc Description: Digital signature
Re: ca-certificates symlinks out of /etc
* martin f krafft ([EMAIL PROTECTED]) wrote: > also sprach Stephen Frost <[EMAIL PROTECTED]> [2006.10.31.2103 +0100]: > > > How are certificate files not intended to be modified? If they > > > expire? If they are incomplete? > > > > If they expire then they should be updated by the package. > > The problem with ca-certificate is that it follows policies which > I don't fully agree with. CAcert's level 3 certificate is not > included because CAcert has not been audited -- that process by > itself just smells commercial to me. I don't see this as relevant to the debate about using symlinks in /etc. > The package allows the user to cherry-pick the certificates to > enable anyway; why preselect? Because it's much more common for users to want at least some set of certificates enabled on installation. > > file, if you mean that some certificates are missing, then you're > > certainly free to add those into that directory as regular files, > > or to ask for inclusion of them in the package). > > I don't want to maintain local certificates across the dozens of > machines on which I need them. And the package maintainer doesn't > seem too cooperative. See e.g. #352248 which has not received a note > yet. What certificates are included and why sounds like an issue which would be more appropriate for the technical committee to comment on, given there's some disagreement regarding it. I don't believe this is any reason to claim that using symlinks as configuration is an RC bug. As an aside, I'd probably side with the maintainer on this one (not that I'm on the TC anyway). I don't really see being audited as being 'commercial' in some kind of bad way. Third-party audits are very common and required by some governments (like the US) when working with sensitive information. There's not exactly *fun* but having an external conflict-free entity performing an audit is generally something I consider a good thing. > Would you edit the files in /etc/alternatives with an editor? No, but you certainly might use 'cp' to overwrite them if you're don't realize they're symlinks. > I see your point. However, /etc/alternatives deserves a special > treatment as it is unique in what it does and integrates with the > whole system. I really don't see how you can argue that it's acceptable for alternatives but not for ca-certificates. I don't see that alternatives being unique in what it does overall (as most packages are...) as meaning that things which it does (symlinks as configuration) are only acceptable for it to use. Either symlinks as configuration is bad and should be done away with entirely, or they're acceptable and any package is free to use them. Thanks, Stephen signature.asc Description: Digital signature
Re: Which architectures are 64-bit?
* Shaun Jackman ([EMAIL PROTECTED]) wrote: > 64-bit: alpha amd64 ia64 mips/mipsel, sparc, s390 and powerpc can all come in a 64-bit flavors, iirc. Thanks, Stephen signature.asc Description: Digital signature
Re: Which architectures are 64-bit?
* Steve Langasek ([EMAIL PROTECTED]) wrote: > On Tue, Nov 28, 2006 at 02:41:13PM -0700, Shaun Jackman wrote: > > 64-bit: alpha amd64 ia64 > > The rest are 32-bit. > > > Am I missing any? > > Nope. *smirk > > Perhaps this is a suitable feature for dpkg-architecture. > > You could just as well do a build-time test of the system. :) Or dpkg-architecture could. Thanks, Stephen signature.asc Description: Digital signature
Re: Intent to hijack Bacula
* Roberto Lumbreras ([EMAIL PROTECTED]) wrote: > I don't agree, all those things are not in my opinion enough for the > hijacking. Thankfully, you're wrong. > The package has bugs, lots of them, and for that reason has been removed > from testing, well done, unstable it is here for that. It's *not* ok for the package to have been removed from testing. It also had no real hope getting back into testing at the rate with which the bugs were being resolved by Jose. > The lots of bugs had not been solved, and several upstream versions had > delayed again and again the uploads Jose Luis has been working on. A lot of > work have to be done to package a new version, and a new upstream version > when the last one is not yet finished doesn't help to get the things done. That's not an excuse. At all. > Ok, the maintainer has not fixed the bugs, has not packaged the last > version of it in time, etc, but he has done a great job anyway, and I > still don't see the point of hijacking the package. He *hasn't* done a great job.. That would be basically the *point*. > If the maintainer still wants to maintain it, help him, do NMUs, whatever, > but I'm still looking for one reason you can take over the package against > the maintainer opinion. He wants to have his name on the package w/o doing the work (apparently). That's not maintaining it, regardless of what he'd like to claim. > rover, Jose Luis's sponsor and uploader of many of his packages including > bacula, you can blame me also if you want We do. Enjoy, Stephen signature.asc Description: Digital signature
Re: Intent to hijack Bacula
* Roberto Lumbreras ([EMAIL PROTECTED]) wrote: > Speaking about your mail, I think it's your opinion, mine is different. Sure, but you're looking through some very rosy glasses. > Jose Luis doesn't want just his name in some place, he has worked a lot > in bacula in the past, and I don't know why he can't remain as > maintainer or co-maitainer if he is going to work on it again. You don't get to rest on your laurels in Debian. Especially when it's been over a year. > Obviuosly if he is unable to maitain it or work on it, it should orphan > the package, but it seems that things are different. That would be exactly the problem- he wants to remain as maintainer or co-maintainer yet has shown nothing to indicate that he's going to work on it again. Not only that but he's trying to refuse work done by others (John) which is clearly in the best interest of Debian and its users (like, I dunno, getting bacula into a state where it can get back into testing...). Besides, Jose Luis will still be able to help with bacula, if he really wants to, by doing bug triage, submitting patches, etc. I fully agree with John's statement though- based on the state which bacula was in and the things which were done in it that were *clearly* policy violations, Jose Luis' contributions need to be checked before being committed. This is something that anyone sponsoring anyone's packages *should* have been doing already. Unfortunately, that part seems to have been forgotten by some. Enjoy, Stephen signature.asc Description: Digital signature
Re: Intent to hijack Bacula
* Jos? Luis Tall?n ([EMAIL PROTECTED]) wrote: > Steve Langasek wrote: > > Actually, we've heard in this thread that Stephen (his AM) *did* offer to > > sponsor bacula uploads, and José Luis did not avail himself of this. > When the offer did come, I wasn't able to prepare the upload anyway. > I suspected that Stephen, given the state of things, would be in excess > picky with my packaging. I certainly would have been picky, as any DD *should* be. It's unfortunate that you've been able to slide by without someone picking through your package. > Moreover, I couldn't trust that he would upload in a timely manner... Uh-huh, this argument really only flies if you'd actually *tried* it and been unsuccessful. Saying "I couldn't upload fixes because someone offered but I'm not sure if he'd actually have time so I didn't bother to ask" doesn't really cut it. I *had* asked you for packages which fixed the issues I found and those never appeared either. > It does happen to be the same time when I am finally home (just returned > from Sweden, where I have been for almost 21 months) and had the > opportunity to work effectively on my packages again. > Unfortunate coincidence, I must admit. Rather unfortunate, especially when you were telling me in February that you were going to have fixed packages soon after a harddrive failure or some such, iirc... > However, regular practice for this is to offer help or co-maintainership > (which others did before) and not hijacking the package. No, regular practice is to hijack it. It's just that in general the 'maintainer' is MIA entirely instead of only-in-practice. > Even when I explicitly denied being willing to give up the package, John > has attempted (and almost succeeded already) hijacking my package. This > is what I don't accept. Erm, he's already 'succeeded'.. There really isn't any question about it, he's just cleaning up more of the mess before uploading the new version. Feel free to take a look at darcs... > I have in the past always accepted patches and included them as soon as > I could. > How is it different this time? You don't seem to understand that some of what your package was doing was unacceptable and seemed uninclined to accept patches for it. Not to mention that you havn't done an upload in ages and seem to feel unstable is a place for dumping broken garbage.. > Why shouldn't I be able to fix my packages in a reasonable period of > time (say, before the end of May) now that I am back home? Assuming I > failed, this "super-duper developer", John Goerzen, has proved to be > able to "fix everything" to your liking in a very short amount of time, > and so would be able to have Bacula in Etch in no time. Unfortunately, it's just plain too late, and your attitude regarding it doesn't work. Take a break from it for a couple of days, let John upload the packages when he's done with them and then review & critque them, if you're still interested in working on bacula packaging. I'm very sure John would be happy to look at patches or suggestions you might have. > If grave personal issues are not a valid excuse for not devoting Debian > as much time as I would have liked to in the past months, then most of > the people in this thread shall step out of it and shut up. Past year, and the 'grave personal issue' excuse has been played a number of times.. It may be that it's time for you to accept that you don't really have time to commit to a package such as bacula and that John does. > If that is indeed the case, state it clearly so that all people > approaching Debian will be warned beforehand. I'm pretty sure people who are approaching Debian to be maintainers realize that letting packages with RC bugs for over a year sit around with nothing done on them isn't appropriate. > I will also consider whether I am interested in contributing any work to > Debian in that case, too... as will probably most other people. I doubt many people have the misconception that they can ignore their Debian packages for over a year with outstanding RC bugs against them. > However, I am amazed about how much attention Bacula has attracted as of > lately... when I first packaged it and began maintaining it almost three > years ago, nobody cared a bit about it. Now that the worst is over and > Bacula is becoming famous, all sorts of people want to have their names > attached to it... I can't hardly be surprised by this. No, the only thing attracting attention here is your steadfast insistance on trying to continue to be the maintainer of bacula when it's pretty clear that you've done a poor job to date and John can clean it up and get something our users can use into unstable quickly. > Note, however, that I have accepted co-maintainership (as long as it is > done on fair terms to me) and have even created an Alioth project for this. It's pretty clear that any changes you'd like to make to the packaging need to be reviewed before being applied. Enjoy,
Re: Intent to hijack Bacula
* Jos? Luis Tall?n ([EMAIL PROTECTED]) wrote: > Stephen Frost wrote: > >> If the maintainer still wants to maintain it, help him, do NMUs, whatever, > >> but I'm still looking for one reason you can take over the package against > >> the maintainer's opinion. > > > > He wants to have his name on the package w/o doing the work > > (apparently). > What if I prove you wrong? Afraid of that? > You might as well not be right on this... Afraid? Not hardly, I'd love to be proven wrong. If this incites you to prove me wrong, all the better. Doesn't change my opinion that your changes and packages in general probably need fairly close inspection before being applied/uploaded to Debian. Enjoy, Stephen signature.asc Description: Digital signature
Re: Intent to hijack Bacula
* Riku Voipio ([EMAIL PROTECTED]) wrote: > On Thu, May 11, 2006 at 03:05:17PM +0300, Riku Voipio wrote: > > On Thu, May 11, 2006 at 01:09:11PM +0200, Roberto Lumbreras wrote: > > > The package has bugs, lots of them, and for that reason has been removed > > > from testing, well done, unstable it is here for that. > > > > Uh no. I find it scary that you share this same idea as the original > > bacula maintainer. Unstable is NOT a graveyard for packages with RC > > bugs years old! > > Uh, I owe Jose a apology. The oldest RC bug was not RC for over a year, > it was promoted to RC just recently. It's not like the bug changed... It was RC before just initially mis-filed... Enjoy, Stephen signature.asc Description: Digital signature
Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)
* Turbo Fredriksson ([EMAIL PROTECTED]) wrote: > But regarding the build system, I REALLY object to any major changes! Fixes > yes, > but not REPLACEMENT!! Uhh, or, not... Sorry, but the build system was terrible and is certainly something which should not be encouraged. I'd encourage you to look at John's packaging and try building it and see how it goes. If you still have complaints about the speed of the build then bring them up with some timing information. Honestly, though, I'm much more concerned about maintainability than speed of the build. There's a reason we build debs and don't just ship source- so our users don't have to deal with the build time. Thanks, Stephen signature.asc Description: Digital signature
Re: Bug#367962: Please don't ship a /lib64 symlink in the package on amd64
* Aurelien Jarno ([EMAIL PROTECTED]) wrote: > The FHS is actually not very clear, as it says 64-bit libraries should > be in (/usr)/lib64, whereas system libraries should be in (/usr)/lib. > This is a contradiction for a pure 64-bit system. The FHS is very clear about the path to the 64bit linker, and that goes through /lib64, getting rid of that isn't an option. > - I am not sure that creating the link in postinst will work. Creating > it in preinst looks safer to me. I'd be a little nervous about creating it in postinst too, honestly. > - If you can install files in (/usr)/lib64, the files will end up in > (/usr)/lib. And dpkg won't know anything about them. dpkg -S and other > tools won't work correctly. Yeah, I'm not sure it really makes sense to need to install into both... It would have been much more useful for you to include the *reasoning* behind Goswin's request rather than just your reasons for not wanting to do what he's asking. > - If you have two packages providing the same files in (/usr)/lib and > (/usr)/lib64, then the files will be overwritten without warning. This > is IMHO not acceptable. My guess is that his intent was actually to allow *seperate* packages to install into either /lib or /lib64 on a package-by-package basis. This might resolve some bugs in packages which, when they detect they're being compiled for amd64, default to installing into /lib64 instead of /lib. Personally I think that's something that just needs to be dealt with and those packages should be fixed but that's my guess as to where the question came from. It's also possible a given package wants to install some things in /lib64 (say, actual libraries) and other things in /lib (say, helper programs, ala blah-config). > Could you please give me your opinion on that, so that I can take a > decision? The link itself certainly can't go away. I'd be more inclined to say "progams on a pure 64bit platform shouldn't install into /lib64" than to have some things installing into /lib and others into /lib64. Part of this comes from the concern that this will bring out other bugs in packages where having this distinction might cause overlaps as mentioned above. Thanks, Stephen signature.asc Description: Digital signature
Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)
* Turbo Fredriksson ([EMAIL PROTECTED]) wrote: > Quoting Stephen Frost <[EMAIL PROTECTED]>: > > * Turbo Fredriksson ([EMAIL PROTECTED]) wrote: > >> But regarding the build system, I REALLY object to any major changes! > >> Fixes yes, > >> but not REPLACEMENT!! > > > > Uhh, or, not... Sorry, but the build system was terrible and is > > certainly something which should not be encouraged. > > Rubish! There is nothing (major) wrong with it as it is now. Yes, hardcoding > isn't good, but neither is 'an-hour-build'. Which you'd get if you do three > full builds after each other... There was quite a bit majorly wrong with it. > > Honestly, though, I'm much more concerned about maintainability than speed > > of the > > build. > > It's not especially problematic to maintain as it is now, and I ask you > to recognize the fact that we don't only ship amd64 or (fast) i386... > Some of the arch's isn't that fast. Don't know how the m68k port is going > or if it's still alive, but that would be a major point in getting speed > increases in the build. I DO know that _I_ have been 'slapped around' for > doing to extensive builds... Sorry, but software is only going to continue to get larger and take longer to compile. Either the architectures need to find a way to handle that (more buildds, distributed builds, whatever) or the architecture it going to have to give up the ghost. My understanding is that the m68k folks have figured out some ways to improve things for themselves such that they can handle larger builds, which makes me even less inclined to hack up an unnecessairly complex build system. No, "we have slow archs" is *not* an excuse for an overly complicated and fragile build system. Thanks, Stephen signature.asc Description: Digital signature
Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)
* Turbo Fredriksson ([EMAIL PROTECTED]) wrote: > You keep saying that, without showing the problems. From what I can see, > all you say is "it's wrong", "it's very wrong" and "there's major problems > with it". John pointed out the issues to it earlier in this thread, which you said you had followed so I expected you to be familiar with his complaints already.. I also asked you to *look* at the new build system he's using instead of making assumptions about it. > I (and more) have stated that the previos (and now yours?) build system was > WAY to expensive. Improving things, for whatever reason, is a good thing. It's certainly not too expensive for our users. It's not even too expensive for our buildds. > You on the other hand, went the OTHER way, you WORSENED the build. I wish I could take credit for it, but John is the one doing all the improvements to bacula. > And throwing CPU time out the window with the excuse "if you can't keep up, > get out" is in _MY_ opinion STUPID. That's nice, but maintainability is more important that the speed of the build. The prior build system wasn't maintainable and was clearly rather fragile. > The ONLY problem with the current (partial) build system is that part of (!!) > the build is hardcoded. Where libs are, and the name of the MySQL/PgSQL libs > will rarely (if ever) change so this is not a PROBLEM, it's only a > 'nitpicking'. Which makes it fragile and much more difficult to maintain than it has any need or right to be. This also makes it more difficult on anyone else having to use or deal with the packaging including porters, the secruity team, and others. That's not acceptable when all it does is speed things up a bit. Please, go look at John's build system and *try it* before complaining that it's too slow. It's also certainly not out of the question to work with upstream to improve the speed of building for multiple subsystems *without* having to resort to hard-codeing things into the build system. Work *with* the upstream build system, don't try to hack around it. Thanks, Stephen signature.asc Description: Digital signature
Re: Sun Java available from non-free
* Steve Langasek ([EMAIL PROTECTED]) wrote: > On Thu, May 18, 2006 at 10:09:28AM +0200, Frans Pop wrote: > > If you really have urgent reasons to get a package into new, the best > > action is probably to send a mail to debian-release and to present these > > reasons. > > Please don't abuse the release team's relationship with the ftpmasters for > NEW processing that isn't release-critical. I expect the implication was that if it's an urgent reason it's probably release-critical... Stephen signature.asc Description: Digital signature
Re: Sun Java available from non-free
* Wouter Verhelst ([EMAIL PROTECTED]) wrote: > On Mon, May 22, 2006 at 08:01:34AM +0200, Juergen A. Erhard wrote: > > On Sun, May 21, 2006 at 03:55:53PM -0700, Steve Langasek wrote: > > > [...] They didn't ask you because Debian is not a democracy and random > > > opinions on this decision *don't* matter. > > > > Wow, thanks for telling us. I thought the Debian developers elected a DPL > > every year. > > The presence of elections do not necessarily turn an organization into a > democracy. Steve is right; Debian is not a democracy, and random > opinions on this decision are of no relevance to it. Sure, it's not a democracy, and true the final decision is made by the select few, but it's rude and insulting to basically say "I don't care that you were interested enough to look into this license more carefully and had some concern about it, it's good enough and I don't think you should care." Perhaps it's not as bad as all that, but when someone is willing to take the time to critique a decision or process or way something was done it's not necessairly a bad thing, even if they don't actually have a say in the final decision. Thanks, Stephen signature.asc Description: Digital signature
Re: Changing the default syslogd (again...)
* Florian Weimer ([EMAIL PROTECTED]) wrote:
> * Nathanael Nerode:
> > (2) Upstream status.
> > There hasn't been a new upstream for sysklogd since 2001.
> > All of the others are active upstream.
>
> Have you checked if SuSE's syslog-ng is heavily patched? If it's
> mostly alright, it's probably a good indicator that syslog-ng is the
> way to go (and I assume that it can log to files larger than 2GB
> nowadays 8-).
Yeah, sure, except when the maintainer uploads a version of syslog-ng
that ends up puking all over itself in a most unpleasent way that causes
anything that logs to block. That version was also in unstable for
quite a while. I realize it's unstable but there are quite a few people
who use that and for whom it'd probably be less clear what had happened.
("Debian sucks, every morning I have to reboot because I can't log in!")
The version we currently have in unstable is 1.9.9 (which is a
development version), 2.0 hasn't been released yet and I'd be hesitant
to recommend 2.0 for the default right away. It's possible we could
consider 2.0 for etch (assuming it comes out by then) but I really feel
it's not a good move to make that decision before it actually arrives
and gets quite a bit of testing.
Thanks,
Stephen
signature.asc
Description: Digital signature
Re: Sun Java available from non-free
* Anthony Towns (aj@azure.humbug.org.au) wrote: > On Sun, May 21, 2006 at 06:14:51PM +0200, Michael Meskes wrote: > > On Sat, May 20, 2006 at 04:18:44PM -0500, Anthony Towns wrote: > > > Anyway, the background is that James Troup, Jeroen van Wolffelaar and > > > myself examined the license before accepting it into non-free (which is > > > three times the usual examination, and was done given the inability to > > > examine the license in public), and both James and Jeroen had extensive > > > contact with Sun to ensure that the tricky clauses were actually okay. Some of this might have been avoided had one or two of the debian-legal regulars been asked to look into it. Changing the license beforehand certainly would have been better than ending up in this situation. > > You won't expect Sun to say they are not, would you? :-) > > The questions asked weren't "Is this okay for non-free?" it's "Did you > mean or when you wrote ?". The answers to those latter > questions are, ttbomk, all included in the FAQ, which is why ignoring > it just wastes everyone's time. Unfortunately, neither the FAQ nor emails from Sun are actually legally binding so while this is a nice exercise to help identify places where Sun should change the license to make it more clear it doesn't actually improve the license by itself. I'd like to think that this would have been pointed out by most any debian-legal regular who might have reviewed it. Thanks, Stephen signature.asc Description: Digital signature
Re: [Debconf-discuss] Re: Please revoke your signatures from Martin Kraff's keys
* Manoj Srivastava ([EMAIL PROTECTED]) wrote: > Explanation? What we have here is an act of bad faith, in the > guise of demonstrating a weakness. In my experience, one act of bad > faith often leads to others. pffft. This is taking it to an extreme. He wasn't trying to fake who he was, it just wasn't an ID issued by a generally recognized government (or perhaps not a government at all, but whatever). This is not unlike, say, the ID of a private university (or possibly a public university since the university itself isn't really a government institution but rather receives gov't funding, heh, I think). And, as he points out, it's not like all gov'ts are all that trustworthy or do much in the way of checking before issueing an ID. It's unfortunate but it's not something we're likely going to be able to fix (the gov't part of it anyway). One thing to consider might be having a select set of people who are already highly trusted and are knowledgeable about the appropriate way to handle key generation, key signing, distribution, etc, create essentially a Debian Certificate Authority. Now, this doesn't *have* to be done using X.509 certs and openssl, it could be done inside the framework of the gpg system and would just mean that there's a specific set of people who are "uploader-key-signers" or some such. These people would also have the additional task of educating newcomers on the importance of careful key management, etc. Obvious initial candidates for this might include: ftpmasters, DAMs, AMs, debian-keyring maintainer. Thanks, Stephen signature.asc Description: Digital signature
Re: [Debconf-discuss] Re: Please revoke your signatures from Martin Kraff's keys
* Manoj Srivastava ([EMAIL PROTECTED]) wrote: > On 25 May 2006, Stephen Frost verbalised: > > * Manoj Srivastava ([EMAIL PROTECTED]) wrote: > >> Explanation? What we have here is an act of bad faith, in the guise > >> of demonstrating a weakness. In my experience, one act of bad faith > >> often leads to others. > > > > pffft. This is taking it to an extreme. He wasn't trying to fake > > who he was, it just wasn't an ID issued by a generally recognized > > government (or perhaps not a government at all, but whatever). > > If you think an ID from a place that issue you any ID when you > pay for it is valid, I probably will not trust a key signed by you, > and I would also suggest other people do not. I wasn't making any claim as to the general validity of IDs which are purchased and I'm rather annoyed that you attempted to extrapolate it out to such. What I said is that he wasn't trying to fake who he was, as the information (according to his blog anyway, which he might be lieing on but I tend to doubt it) on the ID was, in fact, accurate. If you're upset about this because you had planned to sign it and now feel 'duped' then I suggest you get past that emotional hurdle and come back to reality. No one 'crack'ed anything here (that we know of anyway) and while not signing his key because of this is reasonable, or even revoking a signature which had been based on this ID, the constant inflammatory claims of Martin being a 'cracker' and how this could lead to other 'cracks' is extreme, insulting, and childish. Thanks, Stephen signature.asc Description: Digital signature
Re: [Debconf-discuss] Re: Please revoke your signatures from Martin Kraff's keys
* Manoj Srivastava ([EMAIL PROTECTED]) wrote: > On 25 May 2006, Stephen Frost spake thusly: > > I wasn't making any claim as to the general validity of IDs which > > are purchased and I'm rather annoyed that you attempted to > > extrapolate it out to such. What I said is that he wasn't trying to > > fake who he was, as the information (according to his blog anyway, > > which he might be lieing on but I tend to doubt it) on the ID was, > > in fact, accurate. > > He has already bragged about how he cracked the KSP by > presenting an unofficial ID which he bought -- an action designed to > show the weakness of signing parties. So, this was a bad faith act, > since the action was not to show an valid, official ID to extend the > web of trust, but to see how many people could be duped into signing > his key. Pffft. Again, I call foul. That was as much 'bragging' as any scientist reporting on a study. It *wasn't* done in bad faith, as the information on the ID (now independtly confirmed even) *was* accurate. > Given that he is acknowledges trying to dupe people, why do > you think he is not lying about the contents of the ID? He didn't try to dupe people and this claim is getting rather old. Duping people would have actually been putting false information on the ID and generating a fake key and trying to get someone to sign off on the fake key based on completely false information. The contents of the ID were accurate, as was his key, there was no duping or lying. Whineing that he showed a non-government ID at a KSP and saying that's "duping" someone is more than a bit of a stretch, after all, I've got IDs issued by my company, my university, my state, my federal gov't, etc. Would I be 'duping' people if I showed them my company ID? What about my university ID? Would it have garnered this reaction? I doubt it. > > If you're upset about this because you had planned to sign it and > > now feel 'duped' then I suggest you get past that emotional hurdle > > and come back to reality. > > Rubbish. The reality I am concerned about is someone cracking > the KSP and duping people into signing his hey when they had been > fooled into thinking they were looking at an unfamiliar official ID. The reality is that you're turning this into something much, much larger than it actually is. If you're actually concerned about someone cracking the KSP then what you *should* be doing is attempting to educate people on the dangers of KSPs in general, not going after someone who happened to point out that not everyone checks IDs very carefully (an unsuprising reality but one which now has a good measure of proof behind it to base change upon). 'Cracking' the KSP, such as one could, would be coming up with a fake identity entirely and trying to get people to sign off on it. Even that isn't actually all that *dangerous* until someone grants some privilege based on that signature. That *isn't* what happened here, and, indeed, being rather well known (it seems) there would have made it more difficult for him to pull off than, say, someone off the street. > > No one 'crack'ed anything here (that we know of anyway) and while > > not signing his key because of this is reasonable, or even revoking > > a signature which had been based on this ID, the constant > > inflammatory claims of Martin being a 'cracker' and how this could > > lead to other 'cracks' is extreme, insulting, and childish. > > And I think your attitude is naive, optimistic, and > dangerous. This was a subversion of the KSP. Admittedly, KSP's are > fragile, and people get tired, and glassy eyed from looking at too > many unfamiliar official looking documents. It takes little social > engineering to fool people into signing based on fake documents. Again, there was no subversion, the information on his ID was accurate. I'm tired of you blowing things way out of proportion, this being just the last in a trend you seem to have towards sensationalizing things. :/ > Admittedly, in the world of cracking this is the equivalent of > running off with the handbag of an old lady on crutches, which is why > one speculates about where the next crack is headed for. I disagree with the analogy entirely, but even more so doubt that anyone but you is speculating about "where the next crack is headed for". How you made the leap from presenting a non-gov't ID at a KSP to dangerous cracker is far beyond me. Thanks, Stephen signature.asc Description: Digital signature
Re: Poor quality of multipath-tools
* John Goerzen ([EMAIL PROTECTED]) wrote: > On Thu, Jul 06, 2006 at 02:39:16PM +0300, Pasi Kärkkäinen wrote: > > Not always true. Both paths can be active at the same time.. if supported by > > the SAN array. Then you do also load balancing between the paths.. > > Quite true, though my impression is that this is much more rare. Our > controller (HP MSA1500cs) seems to have added active/active controllers > as a recent option. Just another 'me too', I've got a nice IBM SAN at work (DS4300) and we use the multipath tools also. They could certainly use some improvement. My main beef has been with multipathd... I've never actually seen it work correctly. > I'm not really sure if multipath-tools supports active/active > controllers, though. Do you know? I havn't got full active/active controllers, but my controllers each have two ports, which go to each of my fibre switches, and then I've got both controllers in the host hooked up to each switch, so in the end there's 4 paths, 2 through each controller, so I load-balance across the two paths through the same controller and that has worked fine in general (once I could convince multipath to set the paths up correctly in the kernel, that is). Thanks, Stephen signature.asc Description: Digital signature
Re: soname number in name of dev-package?
* Henning Makholm ([EMAIL PROTECTED]) wrote: > In summary: Yes, one could probably work around the lack of versions > in the -dev packages name, but the result would be (in my view) > significantly less elegant than having it there. Trying to support unsupported versions of libraries is decidely worse. If the API changes in an incompatible way then *fix* the things which use the library to use the new API. Users aren't affected- the old, already compiled package, works fine against the lib it depends on, the new package will fail when trying to build against the new API and the maintainer will notice this and (I'd imagine) not upload until it's been fixed. We're not aiming to support every API ever developed; APIs generally change for a reason. Stephen signature.asc Description: Digital signature
Re: soname number in name of dev-package?
* Henning Makholm ([EMAIL PROTECTED]) wrote: > Scripsit Stephen Frost > > If the API changes in an incompatible way then *fix* the things which > > use the library to use the new API. Users aren't affected- the old, > > already compiled package, works fine against the lib it depends on, the > > new package will fail when trying to build against the new API > > Exactly. Ensuring that the new API is not available under the old one's > name will make sure that the new package does fail (because of a > missing build-dependency) rather than trying silently to build against > the new API as if it was the old, and possibly producing bad binaries. bad binaries which, one would hope, would be tested and found out to be bad. Of course, the other thing is that it'd be better for the depended-upon library maintainer to just notify people when the API changes in a silent-but-deadly way, or when the API changes in a non-backwards-compatible way at all. Also, the build-depend wouldn't be missing necessairly, aiui it requires a bit of manual intervention, and it'd still be available on people's machines. Stephen signature.asc Description: Digital signature
Re: Stephen Frost: MIA ?
* Jos? Luis Tall?n ([EMAIL PROTECTED]) wrote: >I would like to know if Stephen Frost is alright and if he is still > active in any way. He is my Application Manager and i have known nothing > from him since 19th July. He has not even answered my pings on 21st > October, 8&19th November and 29th December, even though i promptly > answered him on 20th July. "I'm not quite dead yet. I think I'm feeling better..." Guess you don't follow debian-newmaint, oh well. I'm usually better about answering pings (in fact, I thought I had at least one of those times...) >I have been in the NM queue since November 2003 and have not yet > received the questions for the "Task & Skills" part :-S > I understand that Stephen must be very busy, but i'm sure i can be of > some help if i was a DD myself (as opposed to having to bug some poor > fellow Developer to sponsor my uploads). As has been mentioned many times before (and I expect you know...), there's lots you can do w/o being a DD. Not excusing myself, I've been very bad about things of late, and I'm sorry. :) Of course, you should have contacted the front desk as opposted to debian-devel (which quite a few developers don't follow these days anyway, you're just lucky I skim the subjects every once in a while). > Sorry for the noise, but i need some feedback on my NM process after so > much time has passed. Really, contacting the front desk is the best thing to do if your AM isn't being responsive. You can be confident the front desk will bug the AM about it and the front desk can actually *do* something about it (ie: reassign you to a different AM). Stephen signature.asc Description: Digital signature
Re: Packages: an average 66321 bytes per line of description
* Dan Jacobson ([EMAIL PROTECTED]) wrote: > For instance, the prestigious emacs21 needs only one line, as > everybody who is anybody is supposed to know what it is all about. Yup. Don't see any problem with that either. Have a day. Stephen pgpQddrICotFS.pgp Description: PGP signature
Re: Packages: an average 66321 bytes per line of description
* Dan Jacobson ([EMAIL PROTECTED]) wrote: > I was hoping large package developers would write longer descriptions. Too bad. The two are not, should not, and should never be related. Stephen pgpiYTdDuqfg2.pgp Description: PGP signature
Re: Packages: an average 66321 bytes per line of description
* Dan Jacobson ([EMAIL PROTECTED]) wrote: > I was hoping that maintainers of multi-megabyte packages would do the > package justice by giving an adequate description. The description is adequate. The size of the package has nothing to do with it. > The Packages file could very well be the source for decisions on what > gets chosen or not for ones system. It probably is. Stephen pgpTFR8fC313L.pgp Description: PGP signature
Re: coreutils with acl support
* Michael Stone ([EMAIL PROTECTED]) wrote: > to optional, but that would probably break something.) Thus, I am > soliciting input about whether this is something people would like to > see. The advantage is better support for acl's in debian (which will be I'd definitely like to see it. I think this is definitely functionality we should have. I assume these core utils will work with 2.2.x, 2.4.x, etc cleanly? Perhaps that's more a question about the libacl packages but I'm not really worried just want to be very sure this won't break anything. :) > Another possibility would be an optional coreutils-acl package or > somesuch, but I don't particularly like the idea of diversions or > alternatives or complex dependency structures for ls et al. I really don't like this idea. Just invites trouble imv. Stephen pgpxq86d0dqbe.pgp Description: PGP signature
Re: May packages rm -rf subdirectories of /etc/ ?
* Thomas Hood ([EMAIL PROTECTED]) wrote: > In a discussion that followed from this thread off-list, some > people agreed that the administrator should be asked what > he or she wants to do with an obsolete conffile. The conffile > should not be deleted silently because other packages may be > using the file. I see this as totally bogus. Either the conffile is shared or it isn't. If it's shared then the packages involved know this, if it's not, ditto. If it's not shared then it should be removed and the user doesn't really need to be asked unless removing it would affect their configuration (not likely if it hasn't been modified and has now been obsoleted). I have exactly this situation with slapd and plan to be adding things to deal with it. Basically if the file (/etc/ldap/schema/krb5kdc.schema iirc) hasn't been modified and isn't referenced from slapd.conf I'll nuke it. If it's been modified or is referenced in slapd.conf I think I'll probably leave it alone but inform the user about it being obsolete. Stephen pgpUyxmKa1Mga.pgp Description: PGP signature
Re: May packages rm -rf subdirectories of /etc/ ?
* Thomas Hood ([EMAIL PROTECTED]) wrote: > On Thu, 2003-07-24 at 13:46, Stephen Frost wrote: > > I see this as totally bogus. Either the conffile is shared or it isn't. > > If it's shared then the packages involved know this > > Package foo which eliminates /etc/foo.conf doesn't "know" > that there is not some other package, bar, which Depends > on foo and uses /etc/foo.conf . That's the problem. See > #108587 for additional discussion. The maintainer should really know. The maintainer is more likely to know than the user in many cases. I think it would be worthwhile for policy to be modified to require notification when a sharing of this kind happens. I know that I'd expect someone to tell me if they're using a conffile from my package. Stephen pgpF5Ii6qsNzG.pgp Description: PGP signature
Re: Data loss: suggestions for handling
* Matthew Palmer ([EMAIL PROTECTED]) wrote: > - dump the old software tables and store the dump somewhere, giving > pointers to the dump in all sorts of useful places. But if I put it > somewhere temporary (/tmp), it might disappear before the admin > realises, and somewhere permanent will chew disk space. /var/backups. Tell the admin, if they want to clean it up they can. Stephen pgpIQ1XH72vze.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
* Matt Zimmerman ([EMAIL PROTECTED]) wrote: > On Thu, Jul 31, 2003 at 12:55:28PM -0400, Joey Hess wrote: > > I also think it would be a good idea for policy to require all setuid/gid > > bit grants to go through this or another list for peer review, much as > > pre-depends are supposed to. > > I absolutely support this idea. All set[ug]id setups should be reviewed > before they go in the archive, and I volunteer to do the review (though I > hope that others will help). Does this need a proposal to go into policy > with the same force as the existing pre-depends verbiage? It probably should. I'd be willing to say we might want a seperate list for this too. I'm willing to help with the review but I tend to skim d-d.. Stephen pgpYXXeHWnI5U.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
* Joey Hess ([EMAIL PROTECTED]) wrote: > --- policy.sgml.orig 2003-08-01 13:40:51.0 -0400 > +++ policy.sgml 2003-08-01 13:45:24.0 -0400 > @@ -7104,6 +7104,14 @@ > execute them. > > > + > + Since setuid and setgid programs are often a security rick, 'risk' might be a bit better. :) > + you should not add any new setuid or setgid programs to > + the distribution before this has been discussed on the until it has been discussed .. ? > + debian-security mailing list and a consensus about > + doing that has been reached. and a consensus reached which approves of the application and it's needs. ? Stephen pgp0zhMViopSR.pgp Description: PGP signature
Re: creating official Contributors (was Re: About NM and Next Release)
* Adrian 'Dagurashibanipal' von Bidder ([EMAIL PROTECTED]) wrote: > How about moving from the one-step application (one is non-dd or dd) two a > two > stage process: introduce the 'Debian Contributor' brand with very easy entry > level, and only DC's (older than a month or something like that - > fast-forwarding of course possible when there's a reason) would qualify to > apply for maintainership. This idea seems interesting. It adds a bit more than what exists already though not that much. Many of these things can be grabbed from existing pages (bugs.debian.org/email, packages.qa.debian.org, etc). Perhaps on the nm.debian.org page there could be links for each NM to stuff they've submitted to the BTS, packages they're maintainer or in the uploaders list for, etc. The only problem with this is that there isn't a tag for 'ContributionsFrom:' or something that could then also be checked. Perhaps a method could be defined in the changelog to list where some contributions came from and a page could be set up which tracks this for people. By then going to nm.debian.org and clicking on a user you'd get links and perhaps a summary of their BTS entries, packages they help maintain explicitly and packages they've contributed to (along with what those contributions were). Thoughts? Stephen pgp6GlE9THLVz.pgp Description: PGP signature
Re: non-DD contributors and the debian keyring
* Martin Quinson ([EMAIL PROTECTED]) wrote: > $ LC_ALL=C gpg --keyserver keyring.debian.org --recv-keys E145F334 > gpg: no valid OpenPGP data found. > gpg: Total number processed: 0 > > This is the ID of my key, available from www.keyserver.net and signed by 2 > DD. Did I mess something up ? keyring.debian.org has only DDs in it. I think people were suggesting using the public keyservers. keyring.debian.org isn't a part of the public key servers. > Shouldn't Debian make sure that work submition from non-DD contributor are > signed, just like it does for the work submition from DD ? Interesting question. While it's not a bad idea I don't see it as entirely necessary either. At least when sponsoring a package the DD performing the sponsor must check everything regardless of if it was sent to them signed or not. They have to check that the tarball given matches that on the official site (or verify that it's clean and correct some other way), they have to very carefully look through the diff, they have to build the package themselves, they should compare the diff to the prior versions diff if there was one, etc, etc. It' s not as much work as doing the packaging themselves but it still is a fair bit of work. Once complete the sponsor should be completely confident with the package. DD's are expected to do this work for themselves too but there's no one who's going to double-check it before it's put into the system so there has to be a way to verify that it's been done- that's why DD's sign their packages before uploading (at least one reason anyway). DD's are trusted to have checked over their packages and whatnot and signing the packages basically says "I've checked over it and it should be included." Since, at least at one point not sure if it's still true, packages could be uploaded via anonymous ftp so long as it was signed. I don't know much about the translation work. I would expect that this work is checked by some DD before being incorporated too, even if it's just to ensure the package builds correctly with it since we don't all know every language.. The same is kind of true for patches which change code the DD's might not be extremely familiar with, though there at least they could consult with upstream if they were unsure. I'm not sure what kind of double-check could be done on the translation work that's submitted, for example, via the BTS. I'm also not sure it's entirely necessary, I would find it pretty unlikely for someone to mount an attack by submitting patches which translate debconf questions to ask other things or something.. Stephen pgpocKWMMln0k.pgp Description: PGP signature
