Re: removal of svenl from the project
On Tue, Mar 14, 2006, Andres Salomon wrote: > Hi, Hi! > I am going through the expulsion process to have Sven Luther removed > from the project. Hahaha oh wow. You got it the wrong way, you should only do that _after_ someone posts http://zoy.org/~sam/ftwcal.jpeg to d-d-a. Now I have no other choice but to report you to the mailing-list behavioural police. Sorry. Sam. -- DUMBLEDORE DIES IN THE NEW HARRY POTTER BOOK SEVERUS SNAPE IS THE HALF BLOOD PRINCE BILL WEASLEY MARRIES FLEUR DELACOUR AND HIS FACE IS MUTILATED (attention : spoilers) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Media players in Debian (was: new mplayer)
On Fri, Sep 22, 2006, Bartosz Fenski aka fEnIo wrote: > Mplayer comes with his friend mencoder. I doubt that koffeine, totem, xine, > vlc have something to offer in that regard. You seem rather mistaken. VLC has more encoding and streaming features than mencoder. http://www.videolan.org/streaming-features.html -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: local copies of libs
On Thu, Oct 05, 2006, Frank Küster wrote: > If there's ever been a security update for the library, or it's likely > that a buffer overflow or similar would have security implications, then > I think it's definitely more than just wishlist. For example, it's a > pain to patch all those (subtly different) versions of xpdf code > dispersed throughout Debian on every security update of xpdf. For the record, there has already been at least one security update of libavcodec. -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Orphan party
On Sun, Oct 15, 2006, Josselin Mouette wrote: > * libpng - nightmare of the security team. Upstream developers > seem to have recently understood some packaging issues, but with > their erratic behavior and stupid things libpng-using > applications do, it is likely to break at each new upstream > release. Anyone sane should consider reimplementing it from > scratch instead of packaging it. I'm taking this one until you come back :-) > * sdl-mixer1.2 The SDL team is taking this one. -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Orphan party, relax...
On Sun, Oct 15, 2006, Miguel Gea Milvaques wrote: > > But now, I can stop! There will be people doing my work! And they will > win money! They will do my translations on debian installation manual, > on the debconf templates, they are going to close my RC bugs and other > non important bugs. You are mistaken. Only RC bugs are important. > -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can someone explain : " wmaker (0.92.0-6) is newer than that in Debian!"
On Sun, Oct 15, 2006, Fabrice Lorrain wrote: > Checking for newer versions at packages.debian.org... > Your version of wmaker (0.92.0-6) is newer than that in Debian! Do you > still want to file a report [y|N|q|?]? Just packages.debian.org that's not up to date. -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: restricted sourceless ARM uploads
On Wed, Dec 20, 2006, Bill Gatliff wrote: > For the faster arches, i.e. the ARM9 machines and above, I'm thinking > that we should stick with real hardware so there's no question that the > binaries will run properly. Pardon me sir, but can that claim that binaries built on so-called "real hardware" will unquestionably run (as opposed to, if I understand correcly, binaries built on an emulated platform) be backed up by any facts, examples, experimentation results or scientific publication? Kindest regards, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: restricted sourceless ARM uploads
On Thu, Dec 21, 2006, Wouter Verhelst wrote: > >Pardon me sir, but can that claim that binaries built on so-called > > "real hardware" will unquestionably run (as opposed to, if I understand > > correcly, binaries built on an emulated platform) be backed up by any > > facts, examples, experimentation results or scientific publication? > > Binaries built on real hardware are built on a machine that uses the > binaries built on same real hardware. This is not true. We have different ARM machines that use different CPUs and hardware. Given the versatility of the ARM platform, if the argument "building the binaries on the same machine that uses the binaries" was valid whatsoever, it would in fact be an argument in favour of only using a standardised emulated platform. > I.e., if it works, at least you're sure it doesn't work because the > compiler and the emulator are bug-compatible. But you're sure that it's not because the compiler and the CPU are bug-compatible? Regards, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make -j in Debian packages
On Sun, Jun 25, 2006, Lars Wirzenius wrote: > Sure, even on a single CPU -jX (X > 1) can be faster, but it depends on > various factors, such as available memory, and other load on the > machine. Using -j is not something that should be on by default, but it > would be *really* nice if it were easy to turn on, for any package. Same > with other compilation options, as it happens. Maybe through USE flags? (*ducks*) -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does doc packages need to contain gzipped files?
On Mon, Jun 26, 2006, Preben Randhol wrote: > > Do you think users with small machines shouldn't be able to install > > docs, too? It's just a one line script to gunzip all pdfs in > > /usr/share/doc. > > I don't find this a good argument as it is equally a one line script > to bzip2 all pdfs in /usr/share/doc in small computers. A one-liner that can take hours, whereas gunzipping is quite cheap. -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian conference in the US?
On Sun, May 25, 2003, Andreas Schuldei wrote: > > What are other developers' feelings on the matter these days? > > I would rather not come. Neither would I. Given what happened to Sklyarov, I don't fancy going to the USA at all. And like many others, I won't object, I merely won't attend. Sam. -- Sam Hocevar <[EMAIL PROTECTED]> <http://sam.zoy.org/>
Bug#195490: ITP: raptor -- a vertical shoot'em-up similar to Raptor: Call of the Shadows
Package: wnpp Version: unavailable; reported 2003-05-30 Severity: wishlist * Package name: raptor Version : 1.0.0 Upstream Author : Jon Rafkind <[EMAIL PROTECTED]> * URL : http://raptorv2.sourceforge.net/ * License : probably GPL, see below Description : a vertical shoot'em-up similar to Raptor: Call of the Shadows Raptor is a clone of Raptor: Call of the Shadows, a classic shoot'em-up game. . You have a bird's eye view of the playing field, which is an alien world, and your job is to destroy the enemies that are flying towards you shooting bullets. The score lets you buy life, shield, better weapons or even new spaceships. . Raptor features three spaceships, more than twenty weapons, colourful graphics with transparency effects, music and sound. I have contacted the author and he is all for having Raptor included in Debian. I asked him about the license (the game is shipped with source but without a proper license) and he told me it will probably be GPL. I will upload packages when he has made up his mind. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux c18 2.4.21-rc5 #2 Wed May 28 22:10:14 CEST 2003 i686 Locale: LANG=C, LC_CTYPE=fr_FR
Bug#195489: ITP: hellcarrier -- a 2D shooter in topdown view
Package: wnpp
Version: unavailable; reported 2003-05-30
Severity: wishlist
* Package name: hellcarrier
Version : 0
Upstream Author : Johan Peitz
* URL : http://hellcarrier.sourceforge.net/
* License : GPL, but see below
Description : a 2D shooter in topdown view
Hellcarrier is a 2D shooter seen in topdown view where the world rotates
around you. The player takes the role of a successful helicopter pilot,
active in a near future. You will have to complete various missions, from
simple troops carrying to dangerous rescue or seek-and-destroy missions.
The license accompanying the game is the GPL, but readme.txt contains
a problematic additional sentence ("This code may not be used commercially
in any way without the written consent of the author"). I have contacted
the author and asked for his exact intentions. If he deliberately added
this restriction to the redistribution terms and does not want to resign
it, I will retract the ITP. It would be still suitable for non-free, so
I'll provide the .diff (lintian-clean, with a manpage and a menu icon) to
whomever wants to maintain it.
Also, the game uses the JGMOD library which is non-free (well, it's
almost free, but almost free is still non-free), so I disabled support
for this music library. I am currently discussing the issue with the
JGMOD author but haven't gone very far yet.
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux c18 2.4.21-rc5 #2 Wed May 28 22:10:14 CEST 2003 i686
Locale: LANG=C, LC_CTYPE=fr_FR
Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e")
On Sun, Jun 01, 2003, Marcelo E. Magallon wrote: > Is this a new sport in #d-d or something like that? I read that entry > as "the new upstream version fixes the problem reported in #193497", > and looking at the BTS that is exactly its meaning. The point being made is that "#193497 has been fixed" tells you absolutely nothing. People who know what #194397 is about can only be droids with too much time in their hands. Now maybe public humiliation and eternal ridiculation on debian-devel is not necessary, anyone reading the list should be aware of the issue now. But I think it can be still useful to send the authors of such changelogs a courteous private request to read the Developer's Reference, section 6.3.3, which will certainly improve the overall quality of Debian, with the additional benefit of not annoying this mailing-list. Regards, -- Sam.
Re: Bug#195490: ITP: raptor -- a vertical shoot'em-up similar to Raptor: Call of the Shadows
On Sat, May 31, 2003, Neil McGovern wrote: > > Raptor is a clone of Raptor: Call of the Shadows, a classic shoot'em-up > > game. > > Calling the package Raptor, for a clone of Raptor: Call of the Shadows > could get confusing. True. I talked to upstream about it and he agreed to change the name to "Rafkill" (no hits on Google). -- Sam.
Re: buildd failure
On Tue, Jun 03, 2003, Matt Zimmerman wrote: > > # out of date on hppa: libzorpll, libzorpll-dev (from 2.0.5.2-1) > > Go to buildd.debian.org, read the log and find out what happened. But the buildd didn't even try to build 2.0.26.4-1. Attila, if I were you I'd just try to upload a new release. Do not forget to run lintian and linda on your packages (and .dsc file), they give a lot of useful information. Regards, -- Sam.
Re: buildd failure
On Tue, Jun 03, 2003, Colin Watson wrote: > >Attila, if I were you I'd just try to upload a new release. > > I wouldn't, that just means you get another 10-day delay before the > package gets into testing. Yup, but you missed the subliminal message in my "try lintian" hint :-) Regards, -- Sam.
Re: Bug#197907: ITP: quark -- an audio player, for geeks, by geeks.
On Wed, Jun 18, 2003, Sven Luther wrote: > Yep, i took the one from the Quark 3.0 announce, which i suppose was the > one of a previous version and should have been replaced by the one from > the web site. Also, you could remove the leading "an" from the short description, as recommended by the developer's reference. -- Sam.
Re: Bug#197907: ITP: quark -- an audio player, for geeks, by geeks.
On Wed, Jun 18, 2003, Steve Langasek wrote:
> Ugh. Since when does the developer's reference recommend this? The
> article most definitely belongs...
It is in 6.2.2:
Since the synopsis is a clause, rather than a
full sentence, we recommend that it neither start with a capital nor
end with a full stop (period). It should also not begin with an
article, either definite ("the") or indefinite ("a" or "an").
It might help to imagine that the synopsis is combined with the
package name in the following way:
is a .
Cheers,
--
Sam.
Re: Bug#198158: architecture i386 isn't i386 anymore
On Fri, Jun 20, 2003, Sebastian Kapfer wrote: > > Also P MMX seems meaningless to me. MMX was, I think, introduced in > > Pentium Pro (which is still a i586 according to uname) > > Really? Seems wrong to me. Indeed. MMX and PPro are orthogonal features. -- Sam.
Bug#198445: ITP: matroska -- extensible audio/video container format
Package: wnpp Version: unavailable; reported 2003-06-23 Severity: wishlist * Package name : matroska Version : CVS Upstream Authors : Ludovic "Blacksun" Vialle Christian HJ Wiesner Steve "robUx4" Lhomme * URL : http://www.matroska.org/ * License : dual GPL/QPL Description : extensible audio/video container format Matroska is a cross-platform multimedia container format for audio and video data, and aims to become the standard of multimedia container formats. It has support for menus (like DVDs), subtitles, seeking, error recovery and streaming (over the Internet or on a LAN). Note: the Matroska software is still under development, and only provides a demuxer library. I am packaging this because some media players can already be compiled with support for Matroska files. The binary package will be called libmatroska-dev and will contain .a and _pic.a libraries, because upstream foresees many API/ABI changes before a shared library can be released. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux c18 2.4.21-rc5 #2 Wed May 28 22:10:14 CEST 2003 i686 Locale: LANG=C, LC_CTYPE=fr_FR
Bug#198706: ITP: libebml -- Extensible Binary Meta Language access library
Package: wnpp Version: unavailable; reported 2003-06-25 Severity: wishlist * Package name: libebml Version : CVS Upstream Author : Steve Lhomme <[EMAIL PROTECTED]> * URL : http://www.matroska.org/ * License : dual GPL/QPL Description : Extensible Binary Meta Language access library The libebml library allows to read and write files using the Extensible Binary Meta Language, a binary pendant to XML. Using libebml makes it easier to extend a file format without breaking support in older parsers. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux c18 2.4.21-rc5 #2 Wed May 28 22:10:14 CEST 2003 i686 Locale: LANG=C, LC_CTYPE=fr_FR
Bug#199266: ITP: ffmpeg -- multimedia streaming system
Package: wnpp Version: unavailable; reported 2003-06-29 Severity: wishlist Since the ffmpeg ITP (#157719) was closed almost one year ago, I assume no one is interested anymore, thus this ITP. I use ffmpeg daily and I am not satisfied with the reasons given for closing the ITP. If anyone disagrees I'll gladly elaborate. * Package name: ffmpeg Version : upcoming 0.4.7, probably latest CVS snapshot Upstream Author : Fabrice Bellard et al. * URL : http://ffmpeg.sf.net/ * License : GPL (but see notes below) Description : multimedia streaming system Package: ffmpeg Description: converter for audio and video formats FFmpeg is a very fast video and audio converter. It can work on files but also grab from a live audio/video source. . FFmpeg can convert from any sample rate to any other, and resize video on the fly with a high quality polyphase filter. Package: ffserver Description: multimedia streaming server FFserver is a streaming server for both audio and video. It supports several live feeds, streaming from files and time shifting on live feeds (you can seek to positions in the past on each live feed). Package: libavcodec-dev Description: FFmpeg's audio/video codec library FFmpeg is a complete solution to record, convert and stream audio and video. This package includes libavcodec, the leading audio/video codec library. Notes: There will be no ffserver package at first because it is slightly broken at the moment. Also, libavcodec optionally links with GPL libraries. I will build with support for those libraries that are already in Debian (hence the License: GPL), but will also provide _lgpl variants (à la libart-dev). And since the API is not stable, PIC libs will be static (_pic.a) instead of shared. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux c18 2.4.21-rc5 #2 Wed May 28 22:10:14 CEST 2003 i686 Locale: LANG=C, LC_CTYPE=fr_FR
Re: but I want the GNU versions of packages
On Sat, Jun 28, 2003, Dan Jacobson wrote: > Do I look in Packages.gz for Conflicts:, and then look in Description: > for "this is the GNU version of..."? No need for such a fastidious search. Use this instead: apt-get install `apt-cache search gnu | sed 's/ .*//'` Cheers, -- Sam.
Re: S390 and libXinerama
On Mon, Jun 30, 2003, Julien LEMOINE wrote: > gcc -o osd_clock osd_clock.o -L. -L/usr/X11R6/lib -lX11 -lXext -lpthread -lXt > -lXinerama -lxosd > /usr/lib/gcc-lib/s390-linux/3.3/../../../../lib/libxosd.so: undefined > reference to `XineramaIsActive' Did you try to put -lXinerama after -lxosd? -- Sam.
Re: Close old RFP/ITPs?
On Sat, Jul 05, 2003, Andreas Barth wrote: > is it usefull/ok to close old RFP/ITP-entrys? "old" means for me more > than year since the last mail for ITP, and 2 years for RFP. Of course > I would write mail first whether the package is still wanted I do not think old RFPs should be closed, at least on the sole basis that they are old. Even if the submitter is no longer interested, other people may be, and there is no way to know how many they are. A clean-up is probably needed though, for instance #186174 (xyzzy) is a rather silly RFP, it should at most be a wishlist bug for whatever console games package we have. Regards, -- Sam.
Re: [solved] failing to compile a KDE package
On Sat, Jul 05, 2003, martin f krafft wrote: > ./configure: line 1: g++: command not found > configure:21244: $? = 127 > > This is, IMHO, a problem with autoconf, as it should really check > for g++ first. Uh, this is not a problem with autoconf. It is a problem with upstream calling AC_CHECK_COMPILERS (which checks for all compilers) and ignoring the results thereof. Cheers, -- Sam.
Re: Bug#200355: ITP: csound -- incredibly powerful and versatile software synthesis program
On Mon, Jul 07, 2003, Hans Fugal wrote: > Description : incredibly powerful and versatile software synthesis > program Mmmh, you really should get rid of the "incredibly powerful and versatile" part. Every program is incredibly powerful and versatile. How about this: (taken from your long description) Description: sound and music synthesis system Says it all. Regards, -- Sam.
Re: Work-needing packages report for Jul 11, 2003
On Fri, Jul 11, 2003, Marcelo E. Magallon wrote: > >g5 (#165500), orphaned 264 days ago > > Description: gtk-based 5-in-a-row game > > Not an attractive one? It's still gtk1 and uses O and X characters to display the pieces, so "not attractive" is probably the correct description. The AI seems OK though. I ported it to gtk2 and will send patches to the BTS when I have some time. > >gtk-engines-cleanice (#162410), orphaned 287 days ago > > Description: CleanIce theme for GTK+ 1.2 > > And I thought this was one of thise 37337 engines that are on the > must-install-in-all-boxes list. I use it. If no one show interest in it, I'll adopt the package and maintain it until gtk1 is no longer used (as if). > >svgalib (#173471), orphaned 205 days ago > > (...) > > Of all those people, someone surely has an interest in this. Or > perhaps it's time to just drop this crash-inducing security-scary > package? Is anyone working on this? svgalib is x86 only, doesn't work with most cards and needs root, but it is very fast. And upstream is not very active these days, but the pre-2 releases looked promising. I would like to help in any effort done on the svgalib packages, but I do not feel like adopting it since I only have two different video cards. In the other hand, porting an svgalib program so that it uses SDL instead is not extremely difficult (I did it for gravitywars), and SDL has an svgalib backend so almost no features are lost. -- Sam.
Re: db.debian.org
On Tue, Jul 22, 2003, Glenn McGrath wrote: > Is there a list of developer accessible machines anywhere ? > > A mirror of http://db.debian.org/machines.cgi would have been handy I don't have a mirror, but http://zoy.org/~sam/machines.txt has a list of machines I could log into and their $(ARCH). -- Sam.
Re: mplayer 0.90, was Re: why mplayer not in Debian
On Wed, Jul 23, 2003, Andrea Mennucc wrote:
> we asked for someone on debian-legal to scrutinize it and say if the
> work we did is enough to let this package in Debian
The MPlayer tree contains an almost verbatim copy of libdvdcss
("statically linked for performance reasons", rotfl) and a copy of
ffmpeg's libavcodec library (you may want to have a look at the ffmpeg
ITP to see issues raised by libavcodec). What amount of these libraries
is still in your pristine sources? What amount is compiled? If you get
legal advice about the packaging of these libraries, please tell me, as
I would be very pleased to have them in Debian.
--
Sam.
Re: unicode
On Wed, Oct 30, 2002, Sergey V. Spiridonov wrote: > For example, grep is not able to search unicode strings. Yes it is. Are you sure you are using a unicode locale? See for instance: $ export LC_ALL=fr_FR $ echo "skål" | iconv -f iso8859-1 -t utf8 | grep -q "sk.l" && echo OK $ export LC_ALL=fr_FR.UTF8 $ echo "skål" | iconv -f iso8859-1 -t utf8 | grep -q "sk.l" && echo OK OK $ > So, should I file a bug with "important" severity for grep? No. -- Sam.
Re: Bug#203498: ITP: decss -- utility for stripping CSS tags from an HTML page.
On Wed, Jul 30, 2003, Keith Dunwoody wrote: > >>* Package name: decss > > > >Like that won't be a confusing package name. ;-p > > If you read the website, that was the point ;) And what is the point of confusing our users and cluttering the package/ executable namespace with a useless program that could be replaced with a sed one-liner? I object to this ITP. Not very strongly, but I still object. -- Sam.
Re: Bug#203498: ITP: decss -- utility for stripping CSS tags from an HTML page.
On Wed, Jul 30, 2003, Emile van Bergen wrote: > >And what is the point of confusing our users and cluttering the package/ > > executable namespace with a useless program that could be replaced with > > a sed one-liner? > > If it's so easy to type in, I'd have expected it in your response. Well, I expected someone to ask me this. But I fail to see how showing off my l33t s3d sk1llz would strenghten my point. The only effect it will have is people nitpicking at possible caveats for strange HTML syntax examples, and forgetting the real point which is: that decss program is utterly useless. I expect anyone with minor common sense and minor sed/ awk/perl/whatever practice to understand the triviality of that program. > >I object to this ITP. Not very strongly, but I still object. > > I think it's a wonderful idea to have a decss package in Debian. If > Debian cannot distribute the decss that allows Debian users to view DVD > movies (yet), then distributing this one is a good alternative, I'd say. This is really no different from the RIAA uploading broken MP3s to P2P networks so that users think they are real music. (Disclaimer: I am really not a music piracy advocate, but I strongly believe that such behaviour has the sole effect of confusing users) If the DVD decss cannot be distributed and someone wants to fight this, the solution is to distribute it anyway until it becomes so widespread that no one can make it disappear. Regards, -- Sam.
Re: Bug#203498: ITP: decss -- utility for stripping CSS tags from an HTML page.
On Wed, Jul 30, 2003, Tollef Fog Heen wrote: > |And what is the point of confusing our users and cluttering the package/ > | executable namespace with a useless program that could be replaced with > | a sed one-liner? > > oh? what sed one-liner would that be? That trivial one, for instance: > sed -e > 's%\(]*rel="stylesheet"[^>]*>\|.*\|\(style\|class\|id\)="[^"]*"\)%%g' It can be made better, of course. But honestly, the original DeCSS Perl version is an utter piece of crap, too. I now additionally object to the ITP on the grounds of poor software quality. For instance it fails to remove this construct: And it wrongly removes style="blah" in this one: Hello, this paragraph is about the famous style="blah" phrase! Without a correct HTML parser, such a DeCSS program cannot be reliable. Cheers, -- Sam.
Re: Bug#203498: ITP: decss -- utility for stripping CSS tags from an HTML page.
On Thu, Jul 31, 2003, Tollef Fog Heen wrote: > | I expect anyone with minor common sense and minor sed/ > | awk/perl/whatever practice to understand the triviality of that program. > > It's not possible to parse all valid SGML using regexes, iirc. And HTML makes it even harder since very few pages are valid, but that DeCSS utility uses only regexes anyway. -- Sam.
Re: Bug#203498: ITP: decss -- utility for stripping CSS tags from an HTML page.
On Thu, Jul 31, 2003, Tollef Fog Heen wrote: > | > sed -e > 's%\(]*rel="stylesheet"[^>]*>\|.*\|\(style\|class\|id\)="[^"]*"\)%%g' > > it doesn't handle
Re: #206298 spip: prerm script blindly removes directories
On Wed, Aug 20, 2003, Gaetan Ryckeboer wrote: > >/var/cache/spip > >/usr/share/spip/ecrire/upload > >/usr/share/spip/ecrire/data > > All right. I understand the problem. But the directories removed by the > postrm/purge are normaly only used : > - by user, to upload datas related to his spip installation, > - by spip himself, to store cache informations, > - by spip himself, for log or backups. Please use directories in /var for all this. /usr should only contain sharable, read-only data. As for the removal of whole directories, even in /var, see the various arguments in the previous debian-devel discussion about dosemu. Cheers, -- Sam.
Re: Does anyone use barrendero, or know of an equivalent?
On Wed, Aug 20, 2003, Steve Langasek wrote: > But descriptions can be deceiving. Does anyone use this package who > could comment on its reliability? Does the lack of other bugs indicate > that the software is mature and stable, or unused? I am trying barrendero but don't trust it enough yet for production use. I had worked on an NMU that fixes all bugs and makes the package a bit more polished, I just reviewed it and uploaded it here: http://zoy.org/~sam/debian/barrendero_1.0-1.1.diff.gz I haven't contacted the maintainer yet because I was working on other bugs, but if he is MIA as you seem to be suggesting, I'll probably upload that NMU to DELAYED quite soon. > Does anyone know of another package that provides similar functionality? mail-expire is very close to it. Cheers, -- Sam.
Re: Does anyone use barrendero, or know of an equivalent?
On Thu, Aug 21, 2003, Steve Langasek wrote: > > http://zoy.org/~sam/debian/barrendero_1.0-1.1.diff.gz > > >I haven't contacted the maintainer yet because I was working on other > > bugs, but if he is MIA as you seem to be suggesting, I'll probably > > upload that NMU to DELAYED quite soon. > > Ok, thanks for the info. Can you estimate when you think you'll NMU? Given the package state (only one upload more than 3 years ago, trivial RC bugs, dormant upstream/maintainer) I think I'll NMU tonight (CEST) with a few additional fixes. If anyone objects, please speak up. Cheers, -- Sam.
Re: User Based Init
On Mon, Aug 25, 2003, Jerry Haltom wrote: > [per-user init scripts] > > (yes I realize fetchmail could be started from cron, which notably also > has a similar per user idea) And it also has a similar "at startup" idea, see crontab(5). -- Sam.
Bug#208446: ITP: guile-db -- Berkeley DB module for Guile
Package: wnpp Version: unavailable; reported 2003-09-02 Severity: wishlist * Package name: guile-db Version : 0.1 Upstream Author : C. Ray C. <[EMAIL PROTECTED]> * URL : http://www.pyro.net/~crayc/ * License : GPL Description : Berkeley DB module for Guile The Berkeley DB module for Guile is a set of Guile Scheme functions to facilitate database handling from within Scheme scripts. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux c18 2.4.21-rc5 #2 Wed May 28 22:10:14 CEST 2003 i686 Locale: LANG=C, LC_CTYPE=fr_FR
Re: installer for non-free packages in contrib
On Tue, Sep 09, 2003, Colin Watson wrote: > > It could be something like debian/track where 'track' is a list of files > > to be tracked by this package as if they were contained within it when > > it was built (even though they are actually downloaded during the package's > > postinst or by another script) > > Sounds like the old dpkg-registerfile idea (or whatever it was called), > and it would be useful for other purposes as well. I concur. I am fed up with all those .pyc files that dpkg -S does not know about. -- Sam.
Re: Standardizing ~/.cache/ and similar things.
On Mon, Sep 19, 2005, Sylvain LE GALL wrote: > I like your idea. But i think that i think it should be better > to follow base-dir specification from freedesktop.org. It gives exactly > the same kind of dirname, but in a more standardized way. > > Take a look at: > http://www.freedesktop.org/wiki/Standards_2fbasedir_2dspec What about http://www.brynosaurus.com/cachedir/ also? -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcing an intention to produce an armeb port of Debian
On Mon, Sep 19, 2005, Christoph Hellwig wrote: > > Just a completely uninformed question: Wasn't the -el (endian > > little) in mipsel a pun on the "wrong" endianess? If so, > > shouldn't it be armBE, because it's the "right" endianess? > > What gets you the impression there's a "wrong" endianess? Wrong is endian little that knows everyone but. Sam. -- DUMBLEDORE KILLS SNAPE: spoilers, attention -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Standardizing ~/.cache/ and similar things.
On Mon, Sep 19, 2005, Alastair McKinstry wrote: > Interesting, but very specific to the caching example. There are other > useful parts of the proposal, too: e.g. if libraries are in ~/lib then > its easy to have $LD_LIBRARY_PATH=$HOME/lib work on multiple > applications; also > for an installer to install an application into a users directory. For this > reason I prefer $HOME/var , $HOME/lib, etc. to .lib, .cache, .bin, etc. That comes with its own set of problems, too: it becomes difficult to install several different versions of the same software, to uninstall a particular piece of software, or simply to backup/migrate everything related to application $foo. > >It's not like it's an Herculean task to add a couple of directories to > >the exclude list of your backup program... > > This is the wrong way round, IMHO: rather than having to examine every > new application I use to see what config files and caches it creates > (and never be sure of that: what files in .evolution can I safely remove as > caches, and what ones are essential config? is it safe to remove / not > backup $HOME/.evolution/IMAP/* ? ), and add them to my backup > program excludes list, I can just add /home/var/cache/* to my excludes > list and change applications to use it. No need to keep a list of > cache directories up-to-date. Or you could trust the application for knowing exactly what is a cache dir and what isn't, and have it implement the CACHEDIR.TAG proposal. -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329321: ITP: yasm -- modular assembler with multiple syntaxes support
Package: wnpp Severity: wishlist Owner: Sam Hocevar <[EMAIL PROTECTED]> * Package name : yasm Version : 0.4.0 Upstream Authors : Peter Johnson <[EMAIL PROTECTED]> Michael Urman <[EMAIL PROTECTED]> * URL : http://www.tortall.net/projects/yasm/ * License : some parts are 2-clause BSD, some are GPL+LGPL Description : modular assembler with multiple syntaxes support Yasm is a complete rewrite of the NASM assembler. It supports multiple assembler syntaxes (eg, NASM, TASM, GAS, etc.) in addition to multiple output object formats (binary objects, COFF, Win32, ELF32, ELF64) and even multiple instruction sets (including AMD64). It also has an optimiser module. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (50, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13-mm1 Locale: LANG=en_US.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329323: ITP: monsterz -- arcade puzzle game
Package: wnpp Severity: wishlist Owner: Sam Hocevar <[EMAIL PROTECTED]> * Package name: monsterz Version : 0.6.0 Upstream Author : Sam Hocevar <[EMAIL PROTECTED]> * URL : http://sam.zoy.org/monsterz/ * License : WTFPL (BSD-like) Description : arcade puzzle game Monsterz is an arcade puzzle game, similar to the Bejeweled, Zookeeper or Zooo games. The goal is to swap adjacent tiles to create alignments, and cause chain reactions to earn more points. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (50, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13-mm1 Locale: LANG=en_US.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#331072: ITP: cinelerra-cvs -- non-linear video editor and compositor for Linux.
On Sat, Oct 01, 2005, Riccardo Setti wrote: > Cinelerra, the first Linux based real-time editing and special effects > system is a revolutionary Open Source HD media editing system. > It has a number of effects built into the system including > numerous telecine effects, video special effects including compositing, > and a complete audio effects system. > This is a branched version of Cinelerra sometimes called > Cinelerra-CVS Be careful, more than 1000 Cinelerra source files do not have a proper license, a dozen are copyrighted by the MPEG group, another dozen are under the old ugly OpenDivX license, and you have many additional strange licensing terms in some files (such as free to copy and modify, but not to redistribute). Are you in touch with Holger Levsen <[EMAIL PROTECTED]>? We talked about Cinelerra at the QA miniconf and I sent him a list of problematic source files I had gathered. He is in touch with other people interested in packaging Cinelerra. -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mirror of archive maintenance scripts
On Sun, Jan 28, 2007, Marc 'HE' Brockschmidt wrote: > [EMAIL PROTECTED]:~$ diff -x *.bzr* -x *pyc -x *~ -x *.o -x *.so -wru > /org/ftp.debian.org/dak/ debian-archive-kit/ | diffstat > [...] > 24 files changed, 146 insertions(+), 362 deletions(-) Do you have any idea whether there are reasons other than protecting the security of the Debian infrastructure for these changes not to be publicly available? -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For Those Who Care About: Switzerland/Liechtenstein
On Fri, Feb 02, 2007, martin f krafft wrote: > PS: Almost all... as first official act, I herewith announce the > nomination of Mark J. Ray as an honorary member of debian.ch. > Honorary members have no rights and no obligations, but they also > cannot quit. Is that legal? -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
bugs.d.o down (was: wiki.debian.org disk problems resolved)
On Wed, Feb 14, 2007, Ryan Murray wrote: > wiki.debian.org has been moved to a new host with lots of available > disk space, so updates should be fine now. For the first 90 minutes > after the move exim wasn't running, so updates during this period > would have failed to send notifications. > > If any problems are found with the move, please contact debian-admin > with details. Hi! There must have been a problem with the move because bugs.d.o and wiki.d.o have been down the whole day while no maintenance was planned (or there's a problem with -devel-anounce, too, I don't know). Cheers, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bugs.d.o down (was: wiki.debian.org disk problems resolved)
On Thu, Feb 22, 2007, Greg Folkert wrote: > ;; ANSWER SECTION: > bugs.debian.org.186 IN A 140.211.166.43 > > Hope this helps. It sure did! Thanks! Cheers, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Work-needing packages report for Feb 23, 2007
On Fri, Feb 23, 2007, [EMAIL PROTECTED] wrote: > The following packages have been orphaned: > >s48-refman (#411423), orphaned 4 days ago > Description: An unofficial reference manual for Scheme48 > Installations reported by Popcon: 18 > >scheme48 (#411425), orphaned 4 days ago > Description: A simple, modular, and lightweight Scheme >implementation > Reverse Depends: cmuscheme48-el > Installations reported by Popcon: 64 Anyone interested in a pkg-scheme team / alioth project? I'd hate to see scheme48 disappear, but I have too many packages to adopt these ones. My elk package is bugless but could use some love from such a team, too. Regards, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Sun, Feb 25, 2007, Steinar H. Gunderson wrote: > On Sun, Feb 25, 2007 at 11:26:45PM +0300, Nikita V. Youshchenko wrote: > > What do people look on the following idea: not allow packages to migrate > > from sid to testing if they have unanswered bug reports with severity >= > > normal? > > Honestly, this would kill almost any larger package. You sound like it would not make the maintainers care more about their bugs and start answering them. > The problem is that way too often, maintainers don't really care about > packages migrating to testing. If they did, we wouldn't have 398 RC bugs on > packages that are not in testing... I don't think this is /the/ problem. It's /another/ problem. -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Plug applications into browsers
On Mon, Feb 26, 2007, Howard Young wrote: > I have never heard of Web2.0 before? I will go and find out what this is. Now you are some lucky person. You may also want to look at XSwallow: http://www.skynet.ie/~caolan/Packages/XSwallow.html -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Wed, Feb 28, 2007, Eduard Bloch wrote: > But it seems like you maintain only few simple packages. Did you really just say that to Loïc Minier? Amazed, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Huge cache dirs in $HOME
On Wed, Mar 14, 2007, Pierre THIERRY wrote: > I just discovered today that some packages can store pretty huge cache > data in my $HOME, and found that rather problematic. When I backup my > home, I don't want to waste backup space or time to do it, because I > have to check what eats space and tell if it's cache data. > > Couldn't such packages, like beagle and tracker, just use the standard > directory for that purpose, like specified in XDG's basedir? FYI, There was a (underused and rather clumsy) freedesktop proposal to tell backup utilities not to backup cache files: http://lists.freedesktop.org/archives/xdg/2004-August/004306.html -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attempted summary and thoughts (was Re: On maintainers not responding to bugs)
On Tue, Mar 27, 2007, Mike Hommey wrote: > > I like doing bug triage as well. I guess it is because I am a neat > > freak and anal about organization. > > Would you still like it if the bug count for one package would number in > hundreds ? It's easy to have a huge backlog. I believe a more appropriate metric to estimate whether triaging is realistic for a given package would be the number of new bugs per day. -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Slow package database
On Fri, Mar 30, 2007, Adam Borowski wrote: > On Fri, Mar 30, 2007 at 08:57:03PM +0200, Loïc Minier wrote: > > Indeed it accounts for some part of the problem; after I cloned and > > replaced my /var/lib/dpkg/info tree with the copy, the figure dropped > > from 22 seconds to 15 seconds. > > It's not that. It's /var/lib/dpkg/available. Which is totally unnecessary in most cases. See #397121, unanswered for months and with a patch. (If anyone addresses that bug, please also have a look at #395140). Cheers, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?
tag 410474 +patch thanks On Thu, Apr 05, 2007, Florian Weimer wrote: > Document it in the release notes, please. It's not worth risking > stability for the majority of users for this kind of bug. > > Anyway, is there any particular reason why upstream (or you) don't use > the Intel-recommended way for detection of CPUID support? A library > twiddling with SIGILL isn't a terribly good idea. Here's a patch that uses the recommended method. Cheers, -- Sam. --- ./extra/yassl/taocrypt/src/misc.cpp.orig 2007-04-06 00:02:10 +0200 +++ ./extra/yassl/taocrypt/src/misc.cpp 2007-04-06 00:04:49 +0200 @@ -192,27 +192,29 @@ bool HaveCpuId() } return true; #else -typedef void (*SigHandler)(int); +word32 eax, ebx; -SigHandler oldHandler = signal(SIGILL, SigIllHandler); -if (oldHandler == SIG_ERR) -return false; +__asm__ __volatile +( +"pushf\n\t" +"pushf\n\t" +"pop %0\n\t" +"movl %0,%1\n\t" +"xorl $0x20,%0\n\t" +"push %0\n\t" +"popf\n\t" +"pushf\n\t" +"pop %0\n\t" +"popf" +: "=r" (eax), "=r" (ebx) +: +: "cc" +); -bool result = true; -if (setjmp(s_env)) -result = false; -else -__asm__ __volatile -( -// save ebx in case -fPIC is being used -"push %%ebx; mov $0, %%eax; cpuid; pop %%ebx" -: -: -: "%eax", "%ecx", "%edx" -); +if (eax == ebx) +return false; -signal(SIGILL, oldHandler); -return result; +return true; #endif }
Re: Mandatory -dbg packages for libraries?
On Sun, Apr 22, 2007, Neil Williams wrote: > > 2. Why a seperate -doc? API docs should be part of the -dev package. > > In practice, such attitudes are commonly expressed as RTSL. (Read The > Source, Luke). That does NOT encourage upstream usage of Debian as a > distro. > > Is man (3) really so hard for a DD to provide? The idea is to provide man(3) *in* the -dev package if it's not big enough to justify a package split. -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL
[moving to -project as I should have done with my original message] On Fri, Apr 27, 2007, Andreas Schuldei wrote: > >Matt Taggart proposed that dpkg developers meet in person during a > > dpkg summit[9] to talk about future dpkg development. The meeting would > > be sponsored at least by Debian and HP. I suggested inviting people from > > the Fink and ipkg projects as well as other distributions, too. > > when planning that event with taggart we thought it best to > let first the people we hope to attend confirm their attendence > and then open up the event for other people. Of course. Given the short timeframe until the currently suggested date, it's good that everyone is at least aware of its existence, though. > do you think the overlap with the other projects is significant? > i just dont know. I thought ipkg was interesting because it is a full rewrite that addresses issues the embedded world has (such as the huge and functionally unnecessary /usr/share/doc and /usr/share/man). Fink is just a port of dpkg and does not have any link with Debian AFAIK but its developers might be interested in both requesting/contributing new features and learning about the dpkg developers' future plans. Cheers, Sam. -- echo "creationism" | tr -d "holy godly goal" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFA: jpegtoavi, RFH: pkg-multimedia
Hello. I recently packaged jpegtoavi for my personal use, and I am looking for someone willing to maintain it in Debian. The package is available at svn://svn.debian.org/pkg-multimedia/unstable/jpegtoavi (http://svn.debian.org/wsvn/pkg-multimedia/unstable/jpegtoavi/). Additionally, I'd be happy to see more people help co-maintain the Alioth pkg-multimedia packages (mainly ffmpeg and vlc require attention). Full list of packages is here: http://qa.debian.org/[EMAIL PROTECTED] Regards, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
discussion with the FSF: GPLv3, GFDL, Nexenta
[Cc:ing -legal, but please try to follow-up on only one list] I am having a chat tonight with people from the FSF. Despite the inevitable disagreements between Debian and the FSF, I am willing to cooperate in a constructive manner on as many topic as possible. Here are the topics we'll be discussing so far: 1. The GPLv3: the latest draft did not raise major objections from -legal and despite its concerns with the strategies developed in some sections, Debian does consider it DFSG-free. Debian will however not push for its adoption, mainly because we still have much software that is GPLv2-only in the distribution. We will discuss what role Debian could play in the official launch of the licence. 2. The GFDL: the Debian project does not consider the GFDL a free software licence as long as the work includes invariant sections. We decided (through a GR) that it was otherwise free, mainly because we expected the FSF to fix the (in our opinion) badly worded DRM clause. It is also not a licence we are willing to actively promote and we recommend double-licensing GFDL works under an additional free software licence such as the GPL. 3. Nexenta: Despite their incompatibility, Debian accepts both the CDDL and GPLv2 as valid free software licences and would welcome any solution to the distribution of a Debian system based on OpenSolaris. I have summarised Debian's concerns about the legality of distributing a system containing a CDDL libc and GPLv2 software such as Nexenta, and the FSF legal team is working on the issue and is going to answer us (it will take several weeks, though). The timeframe is short but if you have additional topics to suggest I'll gladly bring them up. Also please correct me if what I have gathered does not seem to reflect the project's opinion. Regards, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Tue, May 22, 2007, Lars Wirzenius wrote: > On ti, 2007-05-22 at 13:30 +0200, Sam Hocevar wrote: > > 1. The GPLv3: the latest draft did not raise major objections from > > -legal and despite its concerns with the strategies developed in some > > sections, Debian does consider it DFSG-free. Debian will however not > > push for its adoption, mainly because we still have much software that > > is GPLv2-only in the distribution. > > Why it that a valid, or even relevant reason to avoid pushing GPLv3? Because software under the GPLv3 is incompatible with GPLv2-only software, while "GPLv2 or above" software is compatible with both. Developing or promoting GPLv3 software deliberately creates incompati- bilities (and I'm not only referring to linking with libraries, but also reusing code). > What does pushing mean in this context? Recommending its use. I prefer to be cautious until we have proper figures about how much software we have under each of the various GPL licensing options, and how the different parts depend on each other. Regards, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Wed, May 23, 2007, Kevin Mark wrote: > >Because software under the GPLv3 is incompatible with GPLv2-only > > software, while "GPLv2 or above" software is compatible with both. > Could someone make a page with GPLv2-only software, I'd be curious what > would be affected. Maybe the easiest way would be to dump and format a > page on the Wiki so that it could be commented upon? I have started working on such a page, based on /usr/share/doc copyright files rather than source code. There is simply too much software for now to do anything else than semi-automatic skimming: http://people.zoy.org/~sam/gpl/ Regards, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why not move Apt to a relational database
On Sun, Jun 03, 2007, Josselin Mouette wrote: > Le dimanche 03 juin 2007 à 10:55 +0100, Justin Emmanuel a écrit : > > So what do you think? Is this the correct mailing list to send this > > idea to? > > I'm so happy that people who send such posts to this mailing list are > not the ones developing our core software. I'm not, nor is anyone using an embedded platform. Given how much useless memory dpkg uses, no suggestion to fix it is worthy of such dismissal without explanation. Regards, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#229357: Can we require build-arch/indep targets for lenny?
On Tue, Jul 03, 2007, Steve Langasek wrote: > > So, an idea: what about checking "make -f /dev/null blah 2>/dev/null" first, > > for some portability? > > What 'blah' are you planning to use that's guaranteed to not have broken > side-effects in some cases on Debian packages? How about: "blah$((uptime;ps aux) | sha1sum | cut -f1 -d-)" Cheers, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
On Sun, Jul 15, 2007, Steve Langasek wrote: > On Sun, Jul 15, 2007 at 09:56:42PM +0200, Josselin Mouette wrote: > > The way Debian works is that developers have the final word on what > > happens in their packages. > > No, the way Debian works is that we have this little thing called Policy > that's intended to ensure consistency between packages in the distribution > so that the system works as a cohesive whole instead of being fragmented > as a result of pigheadedness on the part of individual developers who think > they know better than everybody else, and this other little thing called the > Technical Committee to enforce Policy. Sorry to interrupt, but the way Debian works is that we have this other thing called the Social Contract that says we do what our users want. Not directed at you, Steve, but it looks like most of this thread is slowly losing track of it. Cheers, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Josselin Mouette and Planet Debian
On Fri, Dec 19, 2008, Russell Coker wrote: > The expression "broomstick in their arse" is also common in Australian > culture. It is even sometimes used without the intent to make an accusation > of homosexuality. > > However Josselin made it quite clear that he was not using the term as a > collaquialism, but that he was directly referring to sodomy by his link to > the French web page in question. > > http://np237.livejournal.com/21451.html > > The creation of a fake picture of Manoj wearing leather makes it clear that > Joss was intending to make an insinuation of homosexuality in order to > offend. Oh then it's all right you know, because it's latex, not leather. Also, in the world I live in, anal sex and homosexuality are orthogonal concepts and people can have or not have any of each. I don't understand why you are now adding homosexuality to the discussion unless you wish to cause even more drama. Cheers, -- Sam. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: needs=vc as menu field useful and needed?
On Thu, Aug 02, 2007, Nico Golde wrote: > > A lintian test for needs=vc programs that are not linked with svgalib > > or directfb would be nice. > > Oh that is a good idea. I will file a wishlist bug. Note that there are also framebuffer-only programs that directly use the /dev/fbX device. At least fbi (which is not in your list and would probably need needs=vc) and dvifb do so. -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
making debian/copyright machine-interpretable
Hello, I would like to gather comments about a proposal I have been thinking about during the GPLv2/v3 and GPLv2/CDDL discussions. I have finally written down what I have in mind here, and refined it with the help of many people on IRC: http://wiki.debian.org/Proposals/CopyrightFormat I'll simply repeat the rationale here, so that you know why I feel this is important. The diversity of free software licences means that Debian does not only need to care about the freeness of a given work, but also its licence's compatibility with the other parts of Debian it uses. The arrival of the GPL version 3, its incompatibility with version 2, and our inability to spot the software where the incompatibility might be problematic is the most recent occurrence of this limitation. And there is more to come. The GPL version 3 is compatible with the CDDL, but the GPL version 2 isn’t. Which means that in the near future, GPLv2-only software cannot be distributed as part of a CDDL operating system such as Nexenta. We have no way to know how much of Debian should be stripped from such a system. I therefore would like your opinions about this proposal, its shortcomings, and a strategy to implement it quickly and as widely as possible. Cheers, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making debian/copyright machine-interpretable
On Sat, Aug 04, 2007, Russ Allbery wrote: > It overall seems reasonable to me, although it surfaces other issues that > we've been somewhat ignoring. For example, with a format for clearly > expressing copyrights that vary per file, it raises the question if we > should be noting such things. Most packages that use Autoconf and friends > have files in the distribution (the generated configure and the like) > covered by a different license and copyright than the rest of the > distribution, and for the most part people are not noting this in > debian/copyright. > > I'd like to see a field added to explain any repackaging of the upstream > source that was done, or an explicit statement that this should go into > the second and subsequent lines of the Source field, since I think > debian/copyright is the appropriate location for such information. This is an issue I've been rather happy to ignore so far, because it's really a lot of work for files that no one will probably ever look at. However, if it must really be noted which files were changed and how, I am not sure a new field needs to be added. Actually I think the information fits nicely in the licensing terms without changing the format: Files: Makefile.in autotools/* configure Copyright: (c) 1992-2006 Free Software Foundation, Inc. (c) 200X The Upstream Author (c) 200Y The Debian Maintainer License: $LicenseOfUpstreamSoftware, other-BSD These files were regenerated from The Upstream Author's Makefile.am and configure.ac by The Debian Maintainer using autoconf 2.61 and automake 1.9. . The Free Software Foundation gives unlimited permission to copy, distribute and modify the resulting files. It is probably questionable whether the Debian maintainer is entitled to a copyright on these files, but it is sometimes so difficult to rebootstrap a source tree that I wouldn't be surprised one would argue so. Anyway, it could also be removed. Regards, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making debian/copyright machine-interpretable
On Sat, Aug 04, 2007, Florian Weimer wrote: > It's probably better to use a separate file. If there's a syntax > error, you can't be sure if the file is in the old format, or if its a > genuine error. But the information must be in debian/copyright. Duplicating it is not an option. > Copyright statements with year numbers need to be updated once per > year, complicating merging from upstream. Is this really worth the > effort? Copyright holder information is probably not very valuable > without unique identifiers per copyright holder anyway. This information is required for debian/copyright, too. The proposal just puts it in a header. Citing copyright years is not useful, but it's probably required by law. Have you had one of your packages out of NEW lately? :-) > In order to automatically detect licensing violations, the files in > the binary package would need annotations. Annotating the source > files is not sufficient. That's right, we don't know the licensing terms of binary files. But if we stop at the "it's not sufficient" argument, we'll never get anywhere, because it is impossible for a source package to determine the exact licensing terms of its binary packages. I'll leave that to another proposal. Cheers, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making debian/copyright machine-interpretable
On Sat, Aug 04, 2007, Stefano Zacchiroli wrote: > A comment about file patterns. For possible future needs I would go for > specifying clearly the semantic of file patterns, for example whether if > the first matching pattern apply to a file (as it seems in your example > on the wikipage) or whether if the last does (as I would recommend, > since usually, for the sake of human communication, you first want to > specify the most "common" license of a source package, then the > exceptions). I don't feel strongly about either, but what I don't like in your recommendation is that information you read from it can be superseded by the following lines, forcing it to read it all (or from the end) in order to be sure of what it says. I guess it all comes to whether you look at the file asking "what are the licenses in the package?" in which case you may prefer to see most common licenses first, or "what license is file XXX?" in which case you read the file until one of the patterns matches, and you know that's your licensing terms. > Similarly, it might be useful to have Vim-like '**'-patterns to match > arbitrarily deep subdirectories, thought not really required. Right. Maybe I could formalise that into saying "pattern is what `find -wholename */' will match". Regards, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making debian/copyright machine-interpretable
On Sat, Aug 04, 2007, Adam Borowski wrote: > What about providing a way to programmatically cathegorize licenses, > something that would work for licenses other than different versions of GPL. > > I mean: > * BSD4 (or "BSD4-like") for stuff with the advertising clause > * BSD-like (as you used yourself in the 2nd example) for MIT, old X11, etc > * rename-clause (where modified versions need a different name) > * ... > > Just putting random acronyms in the license field won't make it usable for > anything more than distinguishing between GPLv2 and GPLv3; there are too > many licenses for an exhaustive list. What I'm suggesting is to define an > authoritative list of license types, and to have that list small. Something > just to tell the difference between no-problems-no-copyleft, > no-copyleft-but-with-issues, copyleft-but-GPL-compatible, > copyleft-but-not-GPL-compatible and the GPLs. The latter would get > cathegories on their own because of the GPL's prominence. All this information (GPL-compatibility, having issues etc.) is external and should IMHO stay external. Otherwise if and when a GPLv4 is out, we'll need to change all the debian/copyright files to say whether their license is GPLv4-compatible or not. Also the DFSGs can change. I prefer to have license interpretation completely outside debian/copyright. Cheers, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making debian/copyright machine-interpretable
On Sat, Aug 04, 2007, Faidon Liambotis wrote: > Some initial comments: > - Even though the GPL/OpenSSL is mentioned explicitely in the rationale, > the rest of the document doesn't mention a good way to handle it. That has been mentioned to me several times already. I don't know yet what the best way to express it is, but I think it'll be something like "GPLv2+ | other" (or the appropriate GPL version). There are probably ways to express the OpenSSL exception but I don't want to make it too complicated for the maintainer. The license's not in the list? Just put "other". > - It would be nice (but may be overcomplicated, not sure) to have a > field for compatible licenses, probably only in the "other" license > case. E.g. monsterz could have a Compatible-License: GPL or a > Compatible-License: BSD. That would mostly solve the "other-bsd"/"BSD-like". Can't we assume that "other-bsd" licenses are compatible with each other and also with every other license? Because if a BSD-like license is not compatible with another BSD license, for instance because it has an additional minor clause, then it's not BSD, is it? It's "other". Anyway, let's not spend too much time worrying about special cases. A massive 80% of all free software (be it in Debian or on Freshmeat) is under a version of the GPL or of the LGPL. Which means that we'll be able to ignore around 14,000 source packages when looking for issues. > - I'm not sure if "License: GPL, BSD" for a file makes any sense (it's > GPL for all intents and purposes) and I'm afraid it will be (ab)used on > a "Files: *" to mean "some files under the BSD, others under the GPL". And you know what? I'd be perfectly happy if someone abused that and put "Files: *" and "License: GPL, BSD" because they are too lazy to split the file list. Because 1. such packages would be easily detectable, and 2. in the end, we essentially care about GPL-compatibility anyway, so we have the most important information. Cheers, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making debian/copyright machine-interpretable
On Sat, Aug 04, 2007, Joey Hess wrote: > * Others have mentioned the ordering problem that puts the main license > last. Seems that Packaging-Copyright at the top is another case of > this problem (see you've now removed that special case name, but the > debian/* data would still go there). "Most specific matching glob wins"[1] > might be a better approach. Then the licenses could be ordered with the > main one first, or in whatever order that makes sense to humans, and > if someone wanted to write a tool to extract a given file's license, > that could be done too. ACK. I edited the wiki to reflect your and Zack's view which seems to be the preferred way. For the sake of simplicity, I interpreted "most specific" as "matches the fewer files". It has the drawback of possibly changing with the contents of the source tree, but I fear that any other interpretation is going to be ambiguous in some annoying cornercases. > * Having to munge the license text to fit it in the 822 format is one of > the uglier bits of this proposal, especially since we don't require > that license texts be DFSG free.. Any idea on how to fix that? I tend to reformat license texts with leading "|"s quite often so this didn't really strike me as particularly ugly. 822 seemed like a safe way to escape a license text; if the dots are really an issue, one can use U+00A0 NO-BREAK SPACE or U+FEFF ZERO WIDTH NO-BREAK SPACE or anything crazy like that. > * It's a shame that the boilerplate about where to find the full text of > the GPL is still needed at the end of the file. One way to avoid this > might be to use: > > License: /usr/share/common-licenses/GPL-2 > > The info about which versions apply would need to be expressed some > other way though. ACK. How about parentheses?: License: GPLv2+ (/usr/share/common-licenses/GPL-2) | MPL | LGPLv2.1 (/usr/share/common-licenses/LGPL-2.1) The drawback is that the lines can now become very long, and wrapping them means it's no longer possible to say "first line is license list, the rest is freeform text". But we can live with long lines, I guess. > * I don't see much benefit in putting freeform text at the top of the > file. Keeping it all at the bottom would simplify parsing/validating. I tend to agree with you. The first version used to be like this, and I got many suggestions for adding freeform text at the beginning in order to keep the file human-readable so I switched to allowing it everywhere. I'll wait for more comments on why it may be useful, but the paragraph below about tarball origin seems already a valid use case. > * Makes even more clear that debian/copyright is not the best place for > Source URLs. They rather stick out from the other data, and this would > be a great time to go ahead and move them to the control file. > Dropping them entirely in favour of watch files -- not so good: It's > good to know where a package came from even if a tarball can't be > auto-extracted from there by uscan. But we need freeform text to express how we got the source. When a URL is available, it's all right. But you cannot express "tarball done from branch *** of SVN repository ***, stripped from non-free GFDL files *** and from patented algorithm in file ***, then bootstrapped using automake version *** " with a URL. Which doesn't mean we shouldn't have a link to the URL in debian/control if applicable, of course. Just that it can be done in a separate process and doesn't necessarily involve removing it from debian/copyright. -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#422085: Better terminal emulator patch
On Tue, Dec 18, 2007, Bastian Venthur wrote: > 1. I *personally* hated that some packages sent a *huge* amount of > 2. I *personally* was very annoyed by packages with very long presubj > 3. I'm definitely opposed to a feature which will pop up a *terminal* > 4. I was *personally* very annoyed by some of the reactions on this Luckily our priorities are Our Users and Free Software, not Bastian Venthur. Applying David's patch *immediately* means that maintainers get more useful bug reports that help them fix bugs, and in the end our users get a better support. I hope you realise that reportbug-ng being non-functional with a handful of packages means that users will have to use reportbug to report a bug on these packages. So they will see the ugly terminal anyway. I don't think anyone is opposed to rethink the way bug scripts are handled (even in reportbug) so that they integrate better with the reportbug-ng interface. But that should not prevent improvements from happening first. So I suggest you do that right now, or let someone else NMU reportbug-ng. > And please, don't use abusive language or even insults when contacting > me about this issue. My rng-time is currently very limited and my > motivation to work especially on this issue is already very low. We're > speaking here about a fully optional feature. Providing the output of > some scripts or having to read a presubj is helpful, but *not* mandatory > when reporting a bug. So please, Be nice! Yes, please be nice to your fellow developers. I am sorry you got insulted, but if you only got insults and no offer to help, that may indicate something to rethink about your attitude. Best regards, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#568905: ITP: neercs -- experimental screen clone with improvements
Package: wnpp Severity: wishlist Owner: Sam Hocevar * Package name: neercs Version : 0.0 (SVN snapshot) Upstream Author : Sam Hocevar Jean-Yves Lamoureux Pascal Terjan * URL : http://caca.zoy.org/wiki/neercs * License : WTFPL Programming Lang: C Description : experimental screen clone with improvements NOTE: this package is ONLY for experimental. It's a long way before it is usable in a production environment. The neercs project aims to gather the best of screen, splitvt, dtach, expect, and many terminal managers into one textmode application. It features attaching and detaching from a terminal, locking, remote process grabbing, 3D transitions, and a screensaver with ASCII flying toasters. -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (999, 'stable'), (30, 'unstable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#215058: ITP: libdvb -- library to tune and command DVB cards
Package: wnpp Severity: wishlist * Package name: libdvb Version : 0.5.0 Upstream Author : Marcus Metzler <[EMAIL PROTECTED]> * URL : http://www.metzlerbros.org/dvb/index.html * License : GPL Description : library to tune and command DVB cards This library offers an abstraction layer over the Linux DVB kernel drivers to tune and command DVB cards. Common uses include scanning transponders, selecting channels and retrieving TS data. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux c18 2.4.21-rc5 #2 Wed May 28 22:10:14 CEST 2003 i686 Locale: LANG=C, LC_CTYPE=fr_FR
Bug#215089: ITP: gtklookat -- VRML viewer for GTK+
Package: wnpp Severity: wishlist * Package name: gtklookat Version : 0.13.0 Upstream Author : Erik Andersen <[EMAIL PROTECTED]> * URL : http://www.openvrml.org/ * License : GPL Description : VRML viewer for GTK+ VRML (Virtual Reality Modeling Language) is a scene description language that describes the geometry and behavior of a 3D scene or "world". It is used for 3D multimedia and shared virtual worlds on the Internet. . This package contains gtklookat, a VRML viewer for GTK+ that uses openvrml. Note: though the original author is a DD, he is no longer maintaining gtklookat upstream and has no objection to my packaging it. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux c18 2.4.21-rc5 #2 Wed May 28 22:10:14 CEST 2003 i686 Locale: LANG=C, LC_CTYPE=fr_FR
Re: Bug#215058: ITP: libdvb -- library to tune and command DVB cards
On Fri, Oct 10, 2003, Keegan Quinn wrote: > What is 'DVB?' Some type of radio interface? It would be nice if the > final description said something about that. FYI, here is the final description. Thanks to all who helped. Description: library to tune and command Digital Video Broadcasting cards The DVB standard (Digital Video Broadcasting) is an integrated package of standards for the distribution of terrestrial (DVB-T), satellite (DVB-S) and cable (DVB-C) digital television. . This library offers an abstraction layer over the Linux DVB kernel drivers to tune and command DVB cards that are connected to the system. Common uses include scanning transponders, selecting channels and retrieving raw MPEG-2 transport streams (MPEG-2 TS). -- Sam.
Help needed: builds eating all memory
My openvrml packages have been failing to build on arm [1], mips [2] and mipsel [3] for some time. From the build logs, it looks like g++ is eating all the memory and the OOM killer kills it. What can I do? Ask the buildd admins to add more swap? I would be happy to cross-compile the packages (they don't require any arch-specific bootstrapping) but I don't have enough hard drive space to build a cross- compiler. [1] http://buildd.debian.org/build.php?pkg=openvrml&arch=arm [2] http://buildd.debian.org/build.php?pkg=openvrml&arch=mips [3] http://buildd.debian.org/build.php?pkg=openvrml&arch=mipsel -- Sam.
Re: Bug#215089: ITP: gtklookat -- VRML viewer for GTK+
On Fri, Oct 10, 2003, Joe Drew wrote: > > Description : VRML viewer for GTK+ > > Short description shouldn't mention the toolkit. I usually don't mention it, but in this case it is the only way to differenciate from openvrml-lookat which is the plain X11 version. -- Sam.
Re: Help needed: builds eating all memory
On Sat, Oct 11, 2003, Adam Majer wrote: > >What can I do? Ask the buildd admins to add more swap? I would be > > happy to cross-compile the packages (they don't require any arch-specific > > bootstrapping) but I don't have enough hard drive space to build a cross- > > compiler. > > Whatabout removing the -O2 switch? It can save some compilation time and > memory for very large files.. Okay, I'll try that. If it works, I'll have at least these packages in testing and I'll be able to investigate a bit more. > How much RAM are we talking about here anyway? What is the memory usage > on your machine and on the machines in question? On my x86 g++ eats about 200 MB. I didn't have access to the other architectures to check, but my feeling is that the memory usage is proportional to the number of registers, and MIPS have 32 registers (OK, only 18 to 24 are really usable) while x86 only has 8, which can indicate that g++'s memory usage will be even higher on MIPS. -- Sam.
Re: The sense of automake (Was: Processed: better make that 1.7.8... :-()
On Wed, Oct 15, 2003, Andreas Tille wrote: > I would love to do so but it happened to me that the files I created seem > to depend from automake. I do not call any automake script - just > the usual >configure; make; make install > but I had to add a build-dependency from automake according to #171869. You may use the AM_MAINTAINER mode, or fix the timestamps of the various auto* files before calling configure. Use something like this: (order is important) touch configure.ac \ (or configure.in) && touch aclocal.m4 \ && touch configure \ && touch config.h.in \ (or whatever is in AM_CONFIG_HEADER) && touch `find . -name Makefile.in` (and other *.in files) ./configure $(FLAGS)... See also /usr/share/doc/autotools-dev/README.Debian.gz Regards, -- Sam.
Re: [debian-devel] Re: which policy checker?
On Wed, Oct 15, 2003, Colin Watson wrote: > People in general seem to get unnecessarily het up about Lintian > warnings. They're intended as advice to be read and understood by > humans, not as things you should be blindly counting. Just for an example where it annoys me: I use lintian.d.o as a summary of my lintian warnings because it gives me a nice overview of what needs to be done, and I always need to manually filter out newer-standards- version warnings. -- Sam.
Bug#215945: ITP: etw -- arcade-style soccer game
Package: wnpp Severity: wishlist * Package name: etw Version : CVS Upstream Author : Gabriele Greco <[EMAIL PROTECTED]> * URL : http://etw.sourceforge.net/ * License : GPL Description : arcade-style soccer game Eat The Whistle is an arcade soccer game similar to famous Amiga titles such as Kick Off or Sensible Soccer. It features several game modes where you can play either as the whole team or as a single player, and you can also manage teams that take part in cups and leagues. There is even an arcade mode with powerups and bonuses, like in the game SpeedBall 2. . Eat The Whistle features 30 different field types and numerous sound effects. The game is viewed from the side and can be controlled with either a joystick or the keyboard. . Most in-game settings are configurable, such as the pitch, weather and game daytime, which will impact on the gameplay. There is a replay mode that lets you load and save best moments, a game tactics editor, and teams from the game Sensible World of Soccer can be directly imported. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux c18 2.4.21-rc5 #2 Wed May 28 22:10:14 CEST 2003 i686 Locale: LANG=C, LC_CTYPE=fr_FR
Re: Bug#215945: ITP: etw -- arcade-style soccer game
On Wed, Oct 15, 2003, Sam Hocevar wrote: > * Package name: etw > > Eat The Whistle is an arcade soccer game similar to famous Amiga titles such > as Kick Off or Sensible Soccer. It features several game modes where you can > play either as the whole team or as a single player, and you can also manage > teams that take part in cups and leagues. There is even an arcade mode with > powerups and bonuses, like in the game SpeedBall 2. The game is really great, but has still many bugs. I don't want to upload it in unstable until I have improved the overall stability, but in the meantime you can find my preliminary packages here: deb http://sam.zoy.org/projects/debian sid main deb-src http://sam.zoy.org/projects/debian sid main (The data package is 11 MB, be warned) Regards, -- Sam.
Bug#219447: Networking/PCMCIA startup issues (sarge)
On Thu, Nov 06, 2003, Max Cohan wrote: > The pcmcia-cs init script runs AFTER networking. If your primary network card > is on a pcmcia card (as with a laptop) this requires you to run 'networking > start' > after boot. I suggest you read /usr/share/doc/pcmcia-cs/FAQ.Debian.gz: oThe PCMCIA network interface is established too late in the boot procedure for my DHCP client. Shouldn't the PCMCIA daemon be started earlier in the boot process? In short, no. (see the file for more information) -- Sam.
Re: Anyone know anything about 3dwm?
On Sat, Nov 15, 2003, Andrew Pollock wrote: > I'm trying to prepare a QA upload of the 3dwm source package, and close a > few of the trivial bugs assigned to it (mainly binary package descriptions > being shite). Yes, they all suck pretty much. Here are my suggestions: Package: libcelsius Description: operating system abstraction library for 3Dwm 3Dwm is the Three-Dimensional Workspace Manager. It defines a full user environment with support for three-dimensional user interfaces using a 3D widget kit. It also provides some backwards compatiility with all the major existing windowing systems using VNC. . This is libcelcius, 3Dwm's low-level interface library. It provides an abstraction layer for details of the underlying operating system such as threads management, mutex handling, synchronization, shared memory and dynamically linked libraries. . This package provides the runtime shared library for libcelcius. Package: libgarbo Description: windowing systems compatibility library for 3Dwm 3Dwm is the Three-Dimensional Workspace Manager. It defines a full user environment with support for three-dimensional user interfaces using a 3D widget kit. It also provides some backwards compatiility with all the major existing windowing systems using VNC. . This is libgarbo, 3Dwm's backwards compatibility library for existing windowing systems. It provides an abstraction layer for conventional systems such as X11, Windows and Mac OS, as long as they are capable of running locally on the same machine. . This package provides the runtime shared library for libgarbo. Package: libnobel Description: 3Dwm client library 3Dwm is the Three-Dimensional Workspace Manager. It defines a full user environment with support for three-dimensional user interfaces using a 3D widget kit. It also provides some backwards compatiility with all the major existing windowing systems using VNC. . This is libnobel, the 3Dwm client library upon which all 3Dwm applications depend. It is a set of CORBA IDL interfaces that describe how to speak with 3Dwm, thus allowing any language with CORBA bindings to be used to build 3Dwm applications. . This package provides the runtime shared library for libnobel. Package: libpolhem Description: 3Dwm interface library to Nobel 3Dwm is the Three-Dimensional Workspace Manager. It defines a full user environment with support for three-dimensional user interfaces using a 3D widget kit. It also provides some backwards compatiility with all the major existing windowing systems using VNC. . This is libpolhem, the Nobel client programming interface. It manages the 3Dwm display and input hardware and acts as an extensible framework for pluggable modules that add functionalities to the system. . This package provides the runtime shared library for libpolhem. Package: libzorn Description: interface library to painting functions 3Dwm is the Three-Dimensional Workspace Manager. It defines a full user environment with support for three-dimensional user interfaces using a 3D widget kit. It also provides some backwards compatiility with all the major existing windowing systems using VNC. . This is libzorn, the core of 3Dwm's graphic output functions. It provides basic painting functionalities as well as 3D widgets. . This package provides the runtime shared library for libzorn. Package: libsolid Description: solids trace library 3Dwm is the Three-Dimensional Workspace Manager. It defines a full user environment with support for three-dimensional user interfaces using a 3D widget kit. It also provides some backwards compatiility with all the major existing windowing systems using VNC. . This is libsolid, a core 3Dwm library that provides structured data trees for the trace system. . This package provides the runtime shared library for libsolid. Package: 3dwm-server Description: 3Dwm display server 3Dwm is the Three-Dimensional Workspace Manager. It defines a full user environment with support for three-dimensional user interfaces using a 3D widget kit. It also provides some backwards compatiility with all the major existing windowing systems using VNC. . This package contains the 3Dwm display server daemon. Package: 3dwm-geoclient Description: 3Dwm geometry client example 3Dwm is the Three-Dimensional Workspace Manager. It defines a full user environment with support for three-dimensional user interfaces using a 3D widget kit. It also provides some backwards compatiility with all the major existing windowing systems using VNC. . This is a very simple 3Dwm client that connects to the exported GeometryKit in the server, creates a Geometry, loads a 3D file from the local system and passes it to the 3Dwm server. . The 3Dwm server will happily render any geometry that is created, so running geoclient several times will add more geometries to the graphical output. Please note that you may need to zoom out (using the 'X' key) to see graphic
Re: RFA: A lot of packages
On Mon, Nov 17, 2003, Andreas Tille wrote: > > - pingus > If I followed the discussion this one remains. I definitely have no time for > this but I hope some people grab the hat for this very nice game ... If no one else wants it, I'm willing to take care of it. I know the codebase a bit because I (unsuccessfully yet) tracked #145424 and other endianness bugs. Sam. -- Sam Hocevar <[EMAIL PROTECTED]> <http://sam.zoy.org/>
Bug#222753: ITP: libcaca -- text mode graphics library
Package: wnpp Severity: wishlist * Package name: libcaca Version : 0.2 Upstream Author : Sam Hocevar <[EMAIL PROTECTED]> * URL : http://sam.zoy.org/projects/libcaca/ * License : LGPL Description : text mode graphics library Package: libcaca-dev Section: libdevel Description: text mode graphics library libcaca is the Colour AsCii Art library. It provides high level functions for colour text drawing, simple primitives for line, polygon and ellipse drawing, as well as powerful image to text conversion routines. . This package contains the header files and static libraries needed to compile applications or shared objects that use libcaca. Package: caca-utils Section: utils Description: text mode graphics utilities This package contains utilities and demonstration programs for libcaca, the Colour AsCii Art library. . cacaview is a simple image viewer for the terminal. It opens most image formats such as JPEG, PNG, GIF etc. and renders them on the terminal using ASCII art. The user can zoom and scroll the image and set the dithering method. . cacademo is a simple application that shows the libcaca rendering features such as line and ellipses drawing, triangle filling, and sprite blitting. . caca-spritedit is a simple sprite viewer for libcaca. As usual, preliminary packages are available here: deb http://sam.zoy.org/projects/debian woody main deb-src http://sam.zoy.org/projects/debian woody main deb http://sam.zoy.org/projects/debian sid main deb-src http://sam.zoy.org/projects/debian sid main -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux c18 2.4.21-rc5 #2 Wed May 28 22:10:14 CEST 2003 i686 Locale: LANG=C, LC_CTYPE=fr_FR
Re: Bug#276472: ITP: vco-plugins -- Anti-aliased oscillators
On Thu, Oct 14, 2004, Free Ekanayaka wrote: > * Package name: vco-plugins > Description : Anti-aliased oscillators > > This plugin contains three anti-aliased oscillators, all based on the concept > of using pre-computed band-limited Dirac pulses to construct the classical > waveforms. They are both memory and CPU efficient. The first one produces > a flat spectrum (impulses) and the second generates a sawtooth waveform. > The third one (new in 0.3.0), provides a variable width rectangular > waveform. What are these plugins for? It looks like they are LADSPA plugins; please briefly mention what LADSPA is in the descriptions, and what it's useful for (see tap-plugins and swh-plugins, though I don't believe they give enough information either). Also, the package is called "vco-plugins" but the long description says "This plugin". -- Sam.
Bug#188885: ITP: kxl -- a multimedia library for game development
Package: wnpp Version: unavailable; reported 2003-04-13 Severity: wishlist * Package name: kxl Version : 1.1.7 Upstream Author : Katsuyoshi Sato <[EMAIL PROTECTED]> * URL : http://kxl.hn.org/kxl1xx.php * License : LGPL Description : a multimedia library for game development KXL (Kacchan X Windows System Library) is a library targeted at game development that provides functions for simple image and sound output as well as higher level functions for text drawing, timer and events handling and image manipulation. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux c18 2.5.53 #1 Fri Jan 3 19:04:02 CET 2003 i686 Locale: LANG=C, LC_CTYPE=fr_FR
Bug#188890: ITP: geki3 -- a horizontal shoot'em-up
Package: wnpp Version: unavailable; reported 2003-04-13 Severity: wishlist * Package name: geki3 Version : 1.0.3 Upstream Author : Katsuyoshi Sato <[EMAIL PROTECTED]> * URL : http://kxl.hn.org/games.php * License : GPL Description : a horizontal shoot'em-up Geki 3 is a horizontal shoot'em-up game similar to classic arcade games such as R-Type or Zero "All Your Base Are Belong To Us" Wing. It features four levels and various weapons. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux c18 2.5.53 #1 Fri Jan 3 19:04:02 CET 2003 i686 Locale: LANG=C, LC_CTYPE=fr_FR
Bug#188891: ITP: grande -- a vertical shoot'em-up
Package: wnpp Version: unavailable; reported 2003-04-13 Severity: wishlist * Package name: grande Version : 0.6 Upstream Author : Katsuyoshi Sato <[EMAIL PROTECTED]> * URL : http://kxl.hn.org/games.php * License : GPL Description : a vertical shoot'em-up Grande is a vertical shoot'em-up game similar to classic arcade games such as Xenon, Target Renegade or Gunhed. It features four levels and five types of special weapons. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux c18 2.5.53 #1 Fri Jan 3 19:04:02 CET 2003 i686 Locale: LANG=C, LC_CTYPE=fr_FR
Bug#188892: ITP: geki2 -- a vertical shoot'em-up
Package: wnpp Version: unavailable; reported 2003-04-13 Severity: wishlist * Package name: geki2 Version : 2.0.3 Upstream Author : Katsuyoshi Sato <[EMAIL PROTECTED]> * URL : http://kxl.hn.org/games.php * License : GPL Description : a vertical shoot'em-up Geki 2 is a vertical shoot'em-up game similar to classic arcade games such as Xenon, Target Renegade or Gunhed. It features 6 levels and 2 different weapons. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux c18 2.5.53 #1 Fri Jan 3 19:04:02 CET 2003 i686 Locale: LANG=C, LC_CTYPE=fr_FR
