Re: Bug#354831: ITP: bfc -- Brainfuck compiler
(I'm not on -devel, so I constructed this reply by hand.) > And given the reaction to porn-get and bitchx and > whatever-the-stripping-cpu-monitor-was-called , I tend to assume[2] that > the true intent of such an ITP is to instigate yet another 500 post > flame war between the "but what about the children" crew and the "you > can't censor me!" crew. It's all just so damn tiresome. I only saw the last one of the flame wars you mention, and it didn't even cross my mind that this ITP would gather similar attention. I've had this software packaged for many years, but I'm not a DD, and the ITP was only to follow the protocol of finding sponsors for the package. Besides, brainfuck is already present in the archive to a varying degree, so I didn't think this package would be somehow special. Note that the package name does not have any controversial words. Besides: if it's tiresome to argue about indecent words, is the solution, then, not to use them, or not to complain about using them? Or not to complain about the arguments? (I know this is flamebait, sorry, but these things just seem to be impossible to reach an agreement upon.) Panu -- personal contact: [EMAIL PROTECTED], +35841 5323835 technical contact: [EMAIL PROTECTED], http://www.iki.fi/atehwa/ PGP fingerprint:0EA5 9D33 6590 FFD4 921C 5A5F BE85 08F1 3169 70EC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354952: ITP: sokoedit -- A curses-based Sokoban level editor
Package: wnpp Severity: wishlist Owner: Panu Kalliokoski <[EMAIL PROTECTED]> * Package name: sokoedit Version : 1 Upstream Author : Panu Kalliokoski <[EMAIL PROTECTED]> * URL : http://sange.fi/~atehwa/sokoedit/ * License : BSD-like Description : A curses-based Sokoban level editor sokoedit is a curses-based editor for Sokoban levels, written in Python. Sokoban is a traditional Unix game that requires wits and good pattern recognition abilities. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354950: ITP: gauche-readline -- A readline-like library for the Gauche Scheme implementation
Package: wnpp Severity: wishlist Owner: Panu Kalliokoski <[EMAIL PROTECTED]> * Package name: gauche-readline Version : 0.1 Upstream Author : Julian Fondren, Shiro Kawai * URL : http://www.shiro.dreamhost.com/scheme/gauche/packages.html * License : public domain Description : A readline-like library for the Gauche Scheme implementation This is a pure Scheme library that provides functionality similar to GNU readline for the Scheme implementation Gauche. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354840: ITP: b5 -- A macro processor and functional language
Package: wnpp Severity: wishlist Owner: Panu Kalliokoski <[EMAIL PROTECTED]> * Package name: b5 Version : x.y.z Upstream Author : Panu Kalliokoski <[EMAIL PROTECTED]> * URL : http://sange.fi/~atehwa/b5/ * License : BSD-like Description : A macro processor and functional language b5 is a simple programming language and macro processor featuring referential transparency, lazy evaluation and rearrangeable output. b5 can be used as a (semi-)practical text generation tool, a text-oriented programming language, or as a teaching vehicle for understanding lambda calculus from a practical point of view. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354835: ITP: python-selecting -- An object-oriented wrapper library around the system call select()
Package: wnpp Severity: wishlist Owner: Panu Kalliokoski <[EMAIL PROTECTED]> * Package name: python-selecting Version : 0.92 Upstream Author : Panu Kalliokoski <[EMAIL PROTECTED]> * URL : http://sange.fi/~atehwa/selecting/ * License : BSD-like Description : An object-oriented wrapper library around the system call select() -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354832: ITP: cgames -- A collection of curses-based puzzle games
Package: wnpp Severity: wishlist Owner: Panu Kalliokoski <[EMAIL PROTECTED]> * Package name: cgames Version : 2.2 Upstream Author : Panu Kalliokoski <[EMAIL PROTECTED]> * URL : http://www.muppetlabs.com/~breadbox/software/cgames.html * License : GPL Description : A collection of curses-based puzzle games This package contains the following games: * cblocks (block-sliding game) * cmines (minesweeper) * csokoban (traditional puzzle game) csokoban is the best sokoban implementation I know of. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354831: ITP: bfc -- Brainfuck compiler
Package: wnpp Severity: wishlist Owner: Panu Kalliokoski <[EMAIL PROTECTED]> * Package name: bfc Version : 1.0 Upstream Author : Panu Kalliokoski <[EMAIL PROTECTED]> * URL : http://sange.fi/~atehwa/bf/ * License : BSD-like Description : Brainfuck compiler -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354803: ITP: stx2any -- A converter from structured plaintext to multiple formats
Package: wnpp Severity: wishlist Owner: Panu Kalliokoski <[EMAIL PROTECTED]> * Package name: stx2any Version : 1.53 Upstream Author : Panu Kalliokoski <[EMAIL PROTECTED]> * URL : http://sange.fi/~atehwa/Stx/README.html * License : BSD-like Description : A converter from structured plaintext to multiple formats -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is there some guideline saying that native packages should be avoided?
On Tue, Feb 28, 2006 at 08:57:07PM +0200, Lars Wirzenius wrote: > > I would like to ask whether there really is such a guideline, and if so, > > which are the technical / political reasons that lead to it. > a) If there is a bug in the packaging, it can be fixed without uploading > a new upstream source tarball. Assuming upstream version is 1.2, the > first Debian version would be 1.2-1, and the fixed one would be 1.2-2. > The .orig.tar.gz file would be the same for 1.2-1 and 1.2-2. What benefit does this have in addition to bandwidth savings? > b) Keeping upstream and packaging separate makes things easier when they > no longer are maintained by the same person. Upstream doesn't have to > maintain debian/* anymore, and the Debian package maintainer doesn't > need to feed his changes to upstream and wait for them to be > incorporated in a new release. This seems good grounds only to go non-native _when_ the author and maintainer become different people. > c) Often, though obviously not always, the upstream developer isn't > following Debian packaging policies and practicies to the extent a > dedicated Debian developer would. Thus, if the package gets uploaded to > Debian, its Debian packaging will differ from upstreams, leading to > confusing and .diff.gz files that are hard to read, since they don't > contain all the Debian packaging. This only seems to apply to a situation where the upstream is not a DD. However, I'm trying to get to be one. > d) It doesn't really make it harder to keep packaging files separate. It > may require a step or two extra to the script that builds a release, but > it should be easy enough to do that. That's true, making packages non-native doesn't have much to be said against, however, it doesn't have much to be said for. Maybe the whole thing is just arguing about painting the bikeshed; but I'm concerned that a technical recommendation has been formed that does not really have any technical argument to support it. Panu -- personal contact: [EMAIL PROTECTED], +35841 5323835 technical contact: [EMAIL PROTECTED], http://www.iki.fi/atehwa/ PGP fingerprint:0EA5 9D33 6590 FFD4 921C 5A5F BE85 08F1 3169 70EC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Is there some guideline saying that native packages should be avoided?
Hello, I'm a long-time debian user that aspires to be a DD someday. I recently posted many RFS's on debian-mentors, some of which were software that I'm both the upstream author and packager of. These packages are native Debian packages, i.e. their source distribution is only one .tar.gz. It was pointed to me that packages should be preferably non-native, even if no source release without the debian/ subdir has ever existed. I would like to ask whether there really is such a guideline, and if so, which are the technical / political reasons that lead to it. I have been informed about one technical detail, which is that when you only make changes to packaging, you only need to change the .diff.gz. However, I don't understand the benefit of this, and I've been maintaining my software as debian-native projects for many years, without any observable problems. Panu Kalliokoski ps. please cc me, because I'm not subscribing to -devel. -- personal contact: [EMAIL PROTECTED], +35841 5323835 technical contact: [EMAIL PROTECTED], http://www.iki.fi/atehwa/ PGP fingerprint:0EA5 9D33 6590 FFD4 921C 5A5F BE85 08F1 3169 70EC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#198158: architecture i386 isn't i386 anymore
On Sun, Jun 22, 2003 at 02:46:12PM +0100, Andrew Suffield wrote: > > Apparently you are much better off on a Pentium or Athlon with > > i386 optimized code than i486 optimized one. > I vaguely recall something similar about the i586. FWIK, almost everything that can be done in two ways on ix86, like loop / dec jnz and frame / sub ebp blah, is faster one way on i586 and the other on i686. Moreover, i586 gets most performance boost from keeping everything in registers, while i686 gets most from using registers and memory evenly (!) - I don't know whether compilers support these optimisations, though. So if there will be a split, it should IMO be to i386 and i686. Of course, if C++ progs are going to be broken anyway, dropping i386 might be viable - in that case we'll get i486 and i686. Just my two cents... -- personal contact: [EMAIL PROTECTED], +35841 5323835 work contact: [EMAIL PROTECTED], +35850 3678003 kotisivu (henkkoht):http://www.iki.fi/atehwa/ homepage (technical): http://sange.fi/~atehwa/
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 01:38:42PM -0500, Steve Langasek wrote: > On Sat, Aug 17, 2002 at 08:00:02PM +0300, Panu Kalliokoski wrote: > > I'll throw in my views on the subject: > > > (1) If I understand correctly, SONAMEs are not meant to provide any > > other metadata than a reference to the *library's* ABI. Using SONAMEs for > > anything else, like which compiler the library was built with, will most > > probably result in very broken behavior, because the upstream authors > > have little way to ensure that their library with SONAME n will always > > be built with compiler x but their library with SONAME m will always be > > built with compiler y. > > But in a very real sense, the compiler used *IS* part of the library's > ABI; if you recompile a C++ library with gcc 3.2 instead of gcc 2.95, > the name of pratically *every* *single* *symbol* will change. That > rather soundly eliminates any question of compatible ABIs between the two > libraries. You're right; I'm just more worried about the more practical point that if a library, when being built, cannot know which SONAME it should install itself under (it would involve checking the version of compiler used, right?), changing SONAMES will be a real pain. Another possibility that didn't occur to me was having gcc somehow set the SONAME itself - but this seems to me somehow very ugly. > Of course, you may still be right that it's better to code this > information somewhere other than in the soname itself. The problem is > that currently, the transition plan doesn't allow for it to be stored > anywhere other than in the package system. I, at least, hope that the ...c versions can coëxist with the old versions. (i.e. not the packages, nor the libraries, should conflict in any way.) Panu
Re: GCC 3.2 transition
(first-time poster, beware of possible stupidity) I'll throw in my views on the subject: (1) If I understand correctly, SONAMEs are not meant to provide any other metadata than a reference to the *library's* ABI. Using SONAMEs for anything else, like which compiler the library was built with, will most probably result in very broken behavior, because the upstream authors have little way to ensure that their library with SONAME n will always be built with compiler x but their library with SONAME m will always be built with compiler y. (2) If (binary) programs from outside the distribution are to work with debian's libraries at all, the metadata about the compiler has to go somewhere. I'm not worried about the transition within debian (which can be some pain, too) but numerous third-party binaries that will probably break even though compatibility for them could have been retained. This rules out just replacing the old libraries with new ones compiled with the new compiler. (3) The easiest way to have metadata about the compiler version is using a separate directory. (4) If the libraries are linked against by their SONAMEs (making them indistinguishable), but the compiler version used in compiling the program is deducible, hacking the linker seems a plausible solution (akin to having two linkers in libc transition). Just my twopenny Panu
