Re: non-DD contributors and the debian keyring
On Wed, Aug 20, 2003 at 11:29:52PM +0200, Martin Quinson wrote: > But the point is that without the key, anyone can forge mails which seem to > come from me, and thus abuse the trust my work gained me in the mind of some > DDs. > > I see this point as necessary even if not sufficient. Ok, a valid key gives trust that your work is really made by you. But what this key needs is signatures from trusted people (e.g. from other Debian developers) and for that it doesn't have to be in Debian's keyring at all. Just send the people you work with your public key with its signatures - you don't even have to go via any keyserver at all. Cheers, Peter -- Peter van Rossum, <[EMAIL PROTECTED]> | Universal law of linearity: for all Dept. of Mathematics, New Mexico | f : R -> R and for all x, y in R: State University, Las Cruces, NM, USA. |f(x + y) = f(x) + f(y)
Re: Package removals and the BTS
On Fri, Jul 11, 2003 at 07:34:47PM -0400, Lukas Geyer wrote: [...] > However, for other people browsing the BTS, and for orphaned > packages, it would be much nicer if there was a bug filed against the > package itself, or some remark on bugs.debian.org/package that its > removal is requested. There could be several ways to achieve this. [...] > - The QA pages are made aware of this. This would probably require > some standardized subject line like the bugs against wnpp have. One > possibility would just be RFR (request for removal), maybe with some > tags indicating which distribution would be affected. I like this > solution but one disadvantage is that a request for removal of N > packages would require filing N bugs. This would make things like > #198449 a little more inconvenient. > > Probably there are other possibilities which I might have missed. The > first question is, would other people find this useful? I would find this quite useful and I like the third solution, copied above, best. Just a bug title like RFR: agsatellite -- pointless since audiogallaxy is effectively dead would help. I wouldn't consider tags neccesary - it would be enough if you can easily see on the PTS that some version of the package is threatened with removal and you can then always read the actual bug report. If people want, I'll implement this for the PTS. Peter
Re: plagiarism of reiserfs by Debian
On Mon, 21 Apr 2003, Hans Reiser wrote: > Feel free to make the credits more CPU efficient, reformat them to fit a > screen, animate them, anything that adheres to the academic attribution > spirit of respecting those who contributed years of their lives at the > cost of substantial reductions in their lifetime incomes so that users > (I don't care in the least about distros) could be free to modify the > code, and the poor able to afford the same information infrastructure as > all the rest of us. Just for the record, what is it exactly what it being talked about? Is it about the 21 line long list of sponsors (DARPA, Hans Reiser, SuSE, MP3.com, Bigstorage.com) that the program outputs (Marcelo Magallon posted the list today), or is it about the omission of credits and attributions in some README or AUTHORS file? The first few quotes lines about "CPU efficient, reformat them..." suggest that it is the former, but "spirit of respecting those who contributed year of their lives at the cost..." (and the remainder of your e-mail) suggest the latter (or suggests at least that it is something else than the list of sponsors). > Now, another person has suggested that this was due to an error rather > than deliberate action. I would be happy to apologize if this is the > case. I am not sure it is. I am sure that the output from the program has been deliberatly modified; if some README or AUTHORS file has been omitted from the documentation it was very likely an accident and then there is no reason for this lengthy discussion - the maintainer can just put the omitted file back. Peter van Rossum <[EMAIL PROTECTED]>
gap4 is huge - how to split?
Gap4 is a computer algebra system, specifically designed for working in group theory. The version in Debian is slightly out of date and orphaned; I have posted an ITA earlier today. Gap4 is quite big and I could use some advice on how to split it up. Upstream, gap4 (version 4.3) is distributed in two tar-balls, currently gap4r3.tar.gz (47Mb) and fix4r3n4.tar.gz (1.1Mb). The second one basically contains patches. (There are also contributed packages for gap; I'll see if it is worthwhile to distribute those as well.) In Debian, gap4 (version 4.2) is currently distributed as 6 source packages giving 8 binary packages: gap4 (4.4Mb) (giving binary packages gap4 (3.8Mb), gap4-gac (2.0Mb), gap4-test (0.2Mb)) gap4-doc-dvi (1.1Mb), gap4-doc-html (0.8Mb), gap4-doc-ps (2.1Mb), gap4-gdat (16.7Mb), gap4-tdat (6.8Mb). (As an aside, if you sum the sizes of all the source packages, you only get to 31.9Mb. I don't know yet if gap really grew by 15Mb from version 4.2 to version 4.3 or if something else is going on). The reason for this splitting up is, I think, that whenever there is an upstream bug fix release, the huge tables (in -gdat and -tdat) and the documentation is unlikely to change. However, looking through the bugfixes for version 4.3, this seems to be false. Well, the documentation didn't change, but the tables did. So I'm inclined to simplify packaging by making only a single source package (and still the same binary packages - the tables and the documentation are architecture independent, of course). This would mean superfluous uploads of the documentation binary packages whenever upstream has a bug fix release, but those are relatively small. The tables would have to be renewed anyway, it seems. Can anyone think of a reason why I shouldn't do this? Peter van Rossum <[EMAIL PROTECTED]>
ITA: pingus
Package: wnpp Severity: normal Pingus is a free Lemmings clone. For several years now, the upstream code has not been in very good shape. A new release (0.6.0) is now imminent and is an enormous improvement. It does not have very many levels yet, but is very much playable. Unless someone has objections, I would like to take over maintainance of this package. The previous maintainer of pingus was Martin Butterweck (blendi), who died last year. I think it is appropriate if I remember his work in the README.Debian. Peter van Rossum <[EMAIL PROTECTED]>
