Re: Drop testing
On Mon, Oct 25, 2004 at 02:47:49PM +0200, Wouter Verhelst wrote: I have a simple question for you: have you actually talked to those currently managing our releases before drafting this GR? For comparison, when drafting the proposal for package pools and testing, the folks actually managing the release and the archive didn't really get involved or contribute 'til after a proposal was drawn up, to the best of my recollection. OTOH, they did get cc'ed on the discussion, and their advice was actively sought out. The benefit of conducting Debian as openly as possible is that you don't have to get particular people's advice to come up with good solutions -- you can just troll through the archives for all the data you need. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ Don't assume I speak for anyone but myself. GPG signed mail preferred. ``[S]exual orgies eliminate social tensions and ought to be encouraged.'' -- US Supreme Court Justice Antonin Scalia (http://tinyurl.com/3kwod) signature.asc Description: Digital signature
Debian installer and non-official drivers
Hiho! Just one question. Lets say I'd put some extra driver modules for hardware not officially supported by the debian installer on a floppy disk (in form of an a .udeb) and let the installer load this file during the installation in order to detect the additional hardware. Would this udeb get installed into my target system later on? If this additional driver is needed for i.e. disk access, it should be placed in the initrd when the target kernel gets installed. Any comments? Greetings, Cajus
Re: Drop testing
On Mon, Oct 25, 2004 at 01:05:51PM -0700, Thomas Bushnell BSG wrote: Anthony Towns aj@azure.humbug.org.au writes: * One of Testing's goals was to be 95% releasable at all times. * It hasn't been. * Why not? (a) RC bugs (b) Can't install it (c) Security vulnerabilities This is the crux of the problem, I think, but I'm a little confused. How does (a) contribute to this? The assumption behind an RC bug is we can't release with this bug unfixed. But the problem is that, of course, we *do*, and we *have*, because many RC bugs are in things we have already released. To paraphrase: The problem is that, of course, this is not a problem. Releasing with a hundred known security problems in the kernel is worse than releasing with a dozen unknown security problems in Priority: extra packages. We can, and indeed have to, accept the possibility of the latter; we shouldn't accept the former. The existance of various RC bugs in woody, now or when it was released, and the number of RC bugs still present in testing sit somewhere on that scale between those two extremes. Where we chose to make a cut off point and release is likewise somewhere between those two points. (a) is about failing to make sure we're on the correct side of that cut off point. So the RC bugs should not be blocking release unless they are *new* RC bugs which don't already exist. That's not really the case. Though, even if it were, sarge would still fail to be releasable. As for (b), the solution, if there is one, is to have the installer folks spend time targeting testing all the time. In my experience, claims of the form The only possible solution to this problem is foo are almost invariably wrong, or at least need to be heavily qualified. The drawback is that targeting testing for development work is usually a losing proposition -- there's a deliberate delay in putting stuff into testing, and any delay is a nuisance when you're waiting on a fix before you can do more development. Even targeting unstable has proven cumbersome for the d-i folks. As for (c), the solution in my opinion is to allow security fixes to migrate into testing without having to wait for the normal delay. That already happens, just set urgency=critical in the changelog. If you forget, reupload, or contact a release manager. It's not enough, because security bugs aren't always fixed in a timely manner in unstable; see [0] eg. It's also not enough, because uploads to unstable can easily be unsuitable for testing, even through no fault of the package's maintainer. Is it coincidence that all your proposed resolutions involve situations where you couldn't be expected to contribute? (RC bugs don't matter! Installer team needs to refocus! Security stuff is already handled, just needs code changes!) Cheers, aj [0] http://lists.debian.org/debian-release/2004/08/msg00174.html -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ Don't assume I speak for anyone but myself. GPG signed mail preferred. ``[S]exual orgies eliminate social tensions and ought to be encouraged.'' -- US Supreme Court Justice Antonin Scalia (http://tinyurl.com/3kwod) signature.asc Description: Digital signature
Re: software updates file in /usr -- policy bug?
On Mon, Oct 25, 2004 at 07:44:19PM +0200, Santiago Vila wrote: Even if the file is updated only by the postinst, it is useful to know that you can recover a broken system from scratch by having: * A backup copy of /etc, /var, /home, /usr/local, etc. (but not /usr). * The list of installed packages. ... which can, anyway, got back from files in /var Mike
Re: Location of Type 1 fonts
On Mon, 2004-10-25 at 16:16 -0400, Jaldhar H. Vyas wrote: I'm confused as to where to place Type 1 fonts. Should they go into /usr/X11R6/lib/X11/fonts/Type1 or /usr/share/fonts/type1? Why do some TeX packages have their fonts under /usr/share/texmf/fonts/type1? Isn't /usr/X11R6/lib/X11/fonts/Type1 just a bunch of symlinks into /usr/share/fonts/type1/gsfonts /usr/share/fonts/type1/t1-xfree86-nonfree And doesn't Tex manage it's own fonts? -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B Oh, great altar of passive entertainment, bestow upon me thy discordant images at such speed as to render linear thought impossible Calvin, regarding TV signature.asc Description: This is a digitally signed message part
Debian installer and non-official drivers
Hiho! Just one question. Lets say I'd put some extra driver modules for hardware not officially supported by the debian installer on a floppy disk (in form of an a .udeb) and let the installer load this file during the installation in order to detect the additional hardware. Would this udeb get installed into my target system later on? If this additional driver is needed for i.e. disk access, it should be placed in the initrd when the target kernel gets installed. Any comments? Greetings, Cajus
Re: A localisation success: French po-debconf translations briefly reached a full virtual 100%
[please remember Debian list policy: no cc:s unless requested] On Wednesday 27 October 2004 17.54, Christian Perrier wrote: But does anything warn me (linda/lintian?) when I update debconf templates and/or package descriptions and forget to post to debian-i18n? (which would be: it should always warn, unless you build the AI to detect when I have posted to the mailing list :-) But how will this magic too detect that you indeed modified something in your templates? I thought about simple checks: file modification date of the english template newer than of the translations? Wouldn't be reliable, but could often work. Another possibility would be the translation project somewhere store versions of the relevant files and do diffs at package upload. It would be a bit of work, but it's not a task needing serious AI :-) I just wondered if something like this is already in place. greetings -- vbi -- Oops pgpjATgqsSRIi.pgp Description: PGP signature
Re: Bug#278027: RFP: ibm-acpi -- Driver for IBM laptops to extend ACPI support
On Tue, 2004-10-26 at 09:22 +0200, David Schweikert wrote: On Sun, Oct 24, 2004 at 13:07:34 +0100, Matthew Garrett wrote: * Package name: ibm-acpi This has been integrated into the acpi.sf.net patch, so is fairly likely to end up in the mainstream kernel before too long. Even if it gets integrated in the kernel (which I am not 100% sure about), having a package would make it work on older kernels. Also, an init script is needed to configure what events you are interested in and the package can provide example configuration files in /etc/acpi. Shouldn't it be integrated to package acpid then? Cheers David -- Jerome Warnier [EMAIL PROTECTED] BeezNest s.a r.l.
Re: software updates file in /usr -- policy bug?
also sprach Frank Küster [EMAIL PROTECTED] [2004.10.26.2057 +0200]: You should probably tell us non-chatters what The software is... I believe the original post had the reference: apt-spy, pciutils, usbutils, possibly others. Note that usbutils and apt-spy are already fixed. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Debian installer and non-official drivers
Cajus Pollmeier wrote: Just one question. Lets say I'd put some extra driver modules for hardware not officially supported by the debian installer on a floppy disk (in form of an a .udeb) and let the installer load this file during the installation in order to detect the additional hardware. Would this udeb get installed into my target system later on? If this additional driver is needed for i.e. disk access, it should be placed in the initrd when the target kernel gets installed. It would not. You can however include a udeb on your floppy that installs a prebaseconfig hook script which would run after the base system is installed, or a base-installer hook script which would run just before base is installed (or perhaps both), and at that point do one of these things, in approximate order of difficulty and inverse order of cleanliness and desirability: a. copy the module into /target from the d-i system b. install a .deb of the module into /target from the floppy c. add something to sources.list for the apt repository you should have that contains the .deb, and then use apt-install to get it installed -- see shy jo signature.asc Description: Digital signature
Re: Several X applications refuse to start
'ello Debian On Wed, Oct 27, 2004 at 08:40:30PM +0200, Andreas Tille wrote: asking Google for this problem just leaded to hints of some broken X resources but I have no real clue what might have caused the failure of at least three important applications which I'm running on a laptop with an up to date testing. I never faced similar problems with three other machines running more or less the same stuff. $ emacs X protocol error: BadValue (integer parameter out of range for operation) on protocol request 45 Fatal error (6). [..] The problem is that this Laptop is the machine I installed most recently and I want to share this obervations with other developers just to prevent that something goes really wrong in Sarge ... So the question is, which information do I have to provide to track down this problem. Is this a Transmeta Crusoe based laptop? Have you seen bug 216933? I get this bug periodically. Apparently running the debugging server or recompiling to turn off optimisation in the X server may help. Though I guess your symptoms are a little different. -- --( 'blitz huggie: je sais je suis nulle...mais )-- --( je suis très tetue alors ça compense :)' )-- Simon ( #parinux ) Nomis Htag.pl 0.0.22
Re: RFS: kmenc15 - An advanced Qt/KDE MEncoder frontend.
On Thursday 28 October 2004 01:57, Shaun Jackman wrote: A package in main must not depend on any software outside of main, and must be DFSG-free; A package in contrib must be DFSG-free; A package in non-free must be legally distributable by Debian. There are no further restrictions than the above. Perhaps that's true -- I must do a little reading. However, if you upload a package to contrib that build-depends on a package not in contrib or non-free, you'll get a FTBFS RC bug filed against you before you blink. To me, a package in contrib with an unfixable RC bug should not be in the archive. My package build depends are all in main. As far as I can tell, yes, my program belongs and has no problem being in contrib. Which brings me still back to my original question which no one has yet to answer. What can I do to find a sponsor?... I have almost given up hope... - ods15
Re: Why sysklog uses its own logrotate and not logrotate script
* Clemens Schwaighofer [Wed, 27 Oct 2004 23:02:44 +0900]: Hi, I would like to know why sysklog package uses its own logrotation scripts and not logrotate. albeit both are Priority: important, sysklogd is Section: base. and, iiuc, base should be self-contained (that is, packages in base must not depend on packages outside it). -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Old men are fond of giving good advice to console themselves for their inability to set a bad example. -- La Rochefoucauld, Maxims
Re: Subversion / swig1.3
* John Lenz [Tue, 26 Oct 2004 23:02:43 +]: On 10/26/04 16:35:35, Frank Lichtenheld wrote: On Tue, Oct 26, 2004 at 01:39:15PM +0200, Philipp Hug wrote: subversion depends on swig = 1.3.22-2 which is in unstable. but it's not in testing yet because swig cannot be put into testing because it would break subversion 1.0.6-2 ;-) did I miss something or is this just a bug in the testing script and needs manual hinting? Yes, it needs manual hinting and we're aware of this. But it needs to wait for libhid anyway (two days), so there is no hurry to install the necessary hint. I am a swig developer lurking on this list. Building the SWIG runtime library (which is what causes subversion to depend on SWIG) has been depreciated since 1.3.20, which was released almost a year ago. About a week ago, I removed the ability to build the runtime libraries in SWIG CVS, and so in the next version (1.3.23) you will not be able to build them at all. We are planning for a release in a week or two. I am forwarding this information to the subversion maintainer(s), just to make sure it doesn't get lost. I am not sure how this will impact debian, but I would seriously encourage you to build the python swig wrappers and every other package that depends on libswigruntime so they don't require the runtime library, and then remove that library. The runtime library leads to several bugs and problems, and if those get reported after sarge is released... I am actually surprised to learn people are still using runtime libraries. You can completly remove libswig*.so and not lose any functionality, and avoid a whole bunch of potential bugs. John -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Arguing with an engineer is like wrestling with a pig in mud: after a while, you realize the pig is enjoying it.
Re: Bug#278075: ITP: libical0 -- An implementation of basic iCal
Brent has already a packaged libical here: http://people.debian.org/~bfulgham/gnustep/ yours, Gürkan
Re: RFS: kmenc15 - An advanced Qt/KDE MEncoder frontend.
* Erik Schanze [Wed, 27 Oct 2004 18:31:35 +0200]: If your program depends on MPlayer, it must go into non-free. If your program depends on a program in non-free, it must go into contrib. But MPlayer isn't even in non-free. not exactly. packages in contrib can depend on packages not available in Debian. see §2.2.2 of the Policy. -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 The difference between literature and journalism is that journalism is unreadable and literature is not read. -- Oscar Wilde
Bug#278620: ITP: tecnoballz -- A breaking blocks game ported from Amiga
Package: wnpp Severity: wishlist * Package name: tecnoballz Version : 0.90.6 Upstream Author : TLK Games http://linux.tlk.fr * URL : http://linux.tlk.fr/games/TecnoballZ/ * License : GPL Description : A breaking blocks game ported from Amiga This is a Breakout or Arkanoid like game with a lot of bonus stage. You can buy weapons and bonus between stages. Sometimes you have to defeat a guardian. This game is written in C++ and use the SDL library. The debian package respects the Debian Policy Manual (it's lintian valid). Debian packge can be grabbed from my repo : deb http://www.sukria.net/debian ./ apt-get install tecnoballz It has been tested under unstable and testing with success on several i386 boxes. I really want to maintain this package and am a friend of the upstream author. There should not be too much uploads as the game is really stable and finished. If someone is interested in sponsoring me, feel free to contact me. Alexis. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-686 Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Re: Drop testing
Thomas Bushnell writes: So the RC bugs should not be blocking release unless they are *new* RC bugs which don't already exist. I'd word that a bit differently: the definition of an RC bug should *never* allow a bug still present in stable now (+ security.stable) to reach the level of RC. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: Comparing FHS 2.3 and 2.1
On Wed, 2004-10-27 at 19:53 -0400, Joey Hess wrote: paddy wrote: On Wed, Oct 27, 2004 at 11:28:14AM +0200, Wouter Verhelst wrote: On Tue, Oct 26, 2004 at 03:02:02PM -0500, Manoj Srivastava wrote: 5)== User specific configuration files for applications are stored in the user's home directory in a file that starts with the '.' character (a dot file). If an application needs to create more than one dot file then they should be placed in a subdirectory with a name starting with a '.' character, (a dot directory). In this case the configuration files should not start with the '.' character. I have no idea if we comply, but this is a new requirement. I think we do. This is common sense anyway, most applications I've seen do it that way. what about ~/Desktop and friends? I don't know if Desktop falls under the heading of being a configuration file or directorty. Not that I much like that directory, but like Maildir, it seems out of the scope of this FHS requirement. Is ~/Desktop a User specific configuration files for applications? Doesn't seem like it to me. It and ~/Maildir are data directories. -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B The United States is not a nation to which peace is a necessity. Grover Cleveland signature.asc Description: This is a digitally signed message part
Re: Comparing FHS 2.3 and 2.1
On Tue, Oct 26, 2004 at 03:02:02PM -0500, Manoj Srivastava wrote: User specific configuration files for applications are stored in the user's home directory in a file that starts with the '.' character (a dot file). If Speaking of which: there used to be some proposed addition to FHS about re-locating all dot-files into ~/etc or some directory like that. Does anybody know what happened to that? I'm aware of the problems (sharing $HOME over several different machines etc.), but but I'll be glad if the mess were out of $HOME. -- Nikolai Prokoschenko [EMAIL PROTECTED] / Jabber: [EMAIL PROTECTED]
Re: Debian installer and non-official drivers
Am Donnerstag, 28. Oktober 2004 10:38 schrieb Joey Hess: Cajus Pollmeier wrote: Just one question. Lets say I'd put some extra driver modules for hardware not officially supported by the debian installer on a floppy disk (in form of an a .udeb) and let the installer load this file during the installation in order to detect the additional hardware. Would this udeb get installed into my target system later on? If this additional driver is needed for i.e. disk access, it should be placed in the initrd when the target kernel gets installed. It would not. You can however include a udeb on your floppy that installs a prebaseconfig hook script which would run after the base system is installed, or a base-installer hook script which would run just before base is installed (or perhaps both), and at that point do one of these things, in approximate order of difficulty and inverse order of cleanliness and desirability: a. copy the module into /target from the d-i system b. install a .deb of the module into /target from the floppy c. add something to sources.list for the apt repository you should have that contains the .deb, and then use apt-install to get it installed Ok. Will try (b) to use the apoximated intersection between cleanliness and difficulty ;-) Cheers, Cajus PS: Sorry for mailing multiple times, but it took about three hours to see the mail coming up in the list.
Re: Bug#278027: RFP: ibm-acpi -- Driver for IBM laptops to extend ACPI support
On Thu, Oct 28, 2004 at 09:44:18 +0200, Jerome Warnier wrote: Even if it gets integrated in the kernel (which I am not 100% sure about), having a package would make it work on older kernels. Also, an init script is needed to configure what events you are interested in and the package can provide example configuration files in /etc/acpi. Shouldn't it be integrated to package acpid then? Yes, if the patch gets integrated, that would be the best solution. I am not saying that the package can't be obsoleted in the future. It can be however of use right now. I don't know, but maybe it could even make it to sarge... Cheers David -- David Schweikert| phone: +41 44 632 7019 System manager ISG.EE | walk: ETH Zentrum, ETL F24.1 ETH Zurich, Switzerland | web: http://people.ee.ethz.ch/dws
Bug#278246: 278246 -- does not reproduce for me.
In both KDE (e.g. Konqueror, Kmail) and GNOME (e.g. gedit) applications Cyrillic letters are displayed as double-width. Ah, that was a long time ago that I had that problem. (But for me mozilla used to have the problem too, not any more though) I just tried again with gedit, and I cannot reproduce it. When I run LANG=bg_BG.UTF-8 gedit I see a lovely gedit with Bulgarian (cyrillic) menu's. When I run normally (With LANG=en_IN.UTF-8), but start typing Bulgarian (cyrillic) text, the letters appear normally in the edit-window. Maybe you want to specify what versions of (possibly) affected packages you are running? I'm running: $ dpkg -l gedit xserv\* xlibs konqueror|grep ^i ii gedit 2.6.2-1light-weight text editor ii xserver-common 4.3.0.dfsg.1-4 files and utilities common to all X servers ii xserver-xfree8 4.3.0.dfsg.1-4 the XFree86 X server ii xlibs 4.3.0.dfsg.1-8 X Window System client libraries metapackage ii konqueror 3.2.2-1KDE's advanced File Manager, Web Browser and Also, when I use konqueror to vizit for http://www.news.bg, the is displayed OK. -- Groetjes joostje 8b534037349343140df39156acbede5c-de402678bcb40866dc0b29def3543aaa06193eef
Bug#278627: ITP: childsplay-base -- base package for childsplay, a suite of educational games for children.
Package: wnpp Severity: wishlist * Package name: childsplay-base Version : 0.80 Upstream Author : Stas Zytkieiwcz [EMAIL PROTECTED] * URL : http://childsplay.sf.net * License : GPL Description : base package for childsplay, a suite of educational games for children. Childsplay is a 'suite' of educational games for young children. It's written in Python and uses the SDL-libraries to make it more games-like then, for instance, gcompris. The aim is to be educational and at the same time be fun to play. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Bug#278630: ITP: childsplay-games -- collection of games for childsplay-base.
Package: wnpp Severity: wishlist * Package name: childsplay-games Version : 0.80 Upstream Author : Stas Zytkiewicz [EMAIL PROTECTED] * URL : http://childsplay.sf.net * License : GPL Description : collection of games for childsplay-base. This package provides additional games for childsplay-base. It currently contains the next games: Numbers - Put the correct operator between two numbers. SoundNpic - A toy for young children with pictures and sounds. Packid - A pac-man game, try to catch the letters. Soundmemory - The classic memory game, with sounds. Fallingletters - Type them before the reach the ground. Findsound - Listen to a sound and find the image to which it belongs. Findsound2 - The same as findsound, now with numbers and letters. Pong - The classic game, play alone,against the computer or against another child. Billiards - Try to get the balls in the hole. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: RFS: kmenc15 - An advanced Qt/KDE MEncoder frontend.
However, if you upload a package to contrib that build-depends on a package not in contrib or non-free, you'll get a FTBFS RC bug filed against you before you blink. Hmm, I didn't, back in the days when regina-normal built against java2 (which wasn't in the archive at the time). Though thankfully those days are gone. b.
Re: Several X applications refuse to start
On Thu, 28 Oct 2004, Simon Huggins wrote: Is this a Transmeta Crusoe based laptop? No. It is centrono based and I guess this is rather a problem of some pure X applications, because Gnome and KDE applications and also Mozilla are behaving fine. The only thing is that sometimes fonts are not rendered nicely (for instance the fonts in the menu of xmms look ugly and do not seem to use TrueType fonts. Have you seen bug 216933? I get this bug periodically. Apparently running the debugging server or recompiling to turn off optimisation in the X server may help. Though I guess your symptoms are a little different. Definitely. Kind regards Andreas.
Bug#278633: ITP: childsplay-games -- games for childsplay, a collection of games for young children.
Package: wnpp Severity: wishlist * Package name: childsplay-games Version : 0.80 Upstream Author : Stas Zytkiewicz [EMAIL PROTECTED] * URL : http://childsplay.sf.net * License : GPL Description : Additional games for childsplay, a collection of games for young children. It consists of the following games: Numbers - Put the correct operator between two numbers. SoundNpic - A toy for young children with pictures and sounds. Packid - A pac-man game, try to catch the letters. Soundmemory - The classic memory game, with sounds. Fallingletter - Type them before the reach the ground. Findsound - Listen to a sound and find the image to which it belongs Findsound2 - The same as findsound, now with numbers and letters. Pong - The classic game, play alone,against the computer or against another child. Billiards - Try to shoot the balls into the hole. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Bug#278631: ITP: childsplay-base -- base package for childsplay, a collection of educational games for children.
Package: wnpp Severity: wishlist * Package name: childsplay-base Version : 0.80 Upstream Author : Stas Zytkiewicz [EMAIL PROTECTED] * URL : http://childsplay.sf.net * License : GPL Description : base package for childsplay, a collection of educational games for children. Childsplay is a 'suite' of educational games for young children. It's written in Python and uses the SDL-libraries to make it more games-like then, for instance, gcompris. The aim is to be educational and at the same time be fun to play. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Bug#278634: ITP: libdigest-crc-perl -- Generic CRC functions for Perl
Package: wnpp Severity: wishlist * Package name: libdigest-crc-perl Version : 0.09 Upstream Author : Oliver Maul * URL : http://search.cpan.org/~olimaul/Digest-CRC-0.09/lib/Digest/CRC.pm * License : public domain Description : Generic CRC functions for Perl The Digest::CRC module calculates CRC sums of all sorts. It contains wrapper functions with the correct parameters for CRC-CCITT, CRC-16 and CRC-32. The module acts similar to libstring-crc32-perl, but implements the Digest interface. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.27-i686 Locale: LANG=C, LC_CTYPE=C
Re: Comparing FHS 2.3 and 2.1
Manoj Srivastava [EMAIL PROTECTED] wrote: User specific configuration files [...] If an application needs to create more than one dot file then they should be placed in a subdirectory with a name starting with a '.' ... I have no idea if we comply, but this is a new requirement. Slrn, at least, litters $HOME with .jnewsrc-* files. Then there is the various shells, of course... Stig
Re: Release-critical Bugreport for October 22, 2004
On Wed, Oct 27, 2004 at 05:41:42PM +0400, Nikita V. Youshchenko wrote: Could the script that generates the RC bug list be modified to show two additional numbers for each bug: first, how old it is (in days), and second, how old (in days) is the last message posted to the bug? This will allow to see easilly (i.e. without looking inside all reports), which bugs are not being worked on, and which bugs seem to have trouble. Maybe what bug hunters (and developers) really need is some tips on how to use the LDAP BTS to retrieve this information. Are there any scripts (probably using bts2ldap [1]) out there? (I can't find any useful scripts for RC analysis in devscripts...) Regards Javier [1] http://people.debian.org/~aba/bts2ldap/ signature.asc Description: Digital signature
NMU on sysklogd
Hello guys, I'm having a problem with sysklogd on Sarge: everytime it rotates logs, it fails to log in the new file, it continues in the previous, renamed one. I introduced bug #275111 about that. It is really annoying since every log analysis tool is failing on this every week at least? By log analysis tool I mean anything relying on files in /var/log to do something. I notice that that package has a huge number of bugs, with many having a patch attached, but many bugs are really old. Could someone go through the list and NMU this? I'm willing to help, if necessary. Thanks -- Jerome Warnier [EMAIL PROTECTED] BeezNest s.a r.l.
Re: Comparing FHS 2.3 and 2.1
On Thursday 28 October 2004 01.53, Joey Hess wrote: paddy wrote: what about ~/Desktop and friends? I don't know if Desktop falls under the heading of being a configuration file or directorty. Not that I much like that directory, but like Maildir, it seems out of the scope of this FHS requirement. Ok, this is obviously off-topic here, but I think it's well within the FHS's competence to get rid of these... +--- | Applications MUST NOT require or create any files and directories in the | users' home directories except | (i) data files explicitely requested by the user | (ii) temporary backup and lock files which belong to a file as described | in (i) and are in the same directory as the data file, and start with | a dot. | (iii) configuration files, a.k.a dotfiles. +-- Or something like that. I really think my $HOME is my castle, and nobody should mess with that. dotfiles I can accept, but ~/Mail and ~/Desktop are annoying (and, in the case of ~/Mail, totally useless if I use a remote IMAP mail server but my mailclient still insists on it :-( :-( :-( greetings -- vbi -- Oops pgpeeVGMg9JWj.pgp Description: PGP signature
Re: apt-proxy v2 and rsync
On Tuesday 26 October 2004 09.20, Ian Bruce wrote: Can anyone explain why rsync is no longer considered an appropriate method for fetching Packages files? IIRC the problem is that rsync is quite CPU-heavy on the servers, so while the mirrors have the (network) resources to feed downloads to 100s of users, they don't have the (CPU) resources for a few dozen rsyncs. regards -- vbi -- Oops pgp3ZmFWdUFgo.pgp Description: PGP signature
Versioned bugs in the BTS (was: Drop testing)
Matthias Urlichs [EMAIL PROTECTED] wrote: Besides, we'll have a bug database which tracks version numbers. This in turn means that we have a nice distinction between bugs that are actually RC in the fix this if we'd want to release Etch tomorrow sense, and bugs that are RC in the keep this out of testing sense. This sounds great, and I heard that it has been promised for after the sarge release, sounding as if it was implemented yet. Is the counterpart also implemented, namely testing scripts that take this information into account? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Drop testing
* Jan Nieuwenhuizen ([EMAIL PROTECTED]) [041028 14:05]: Thomas Bushnell writes: So the RC bugs should not be blocking release unless they are *new* RC bugs which don't already exist. I'd word that a bit differently: the definition of an RC bug should *never* allow a bug still present in stable now (+ security.stable) to reach the level of RC. We _have_ RC-bugs in woody - even RC-bugs we won't fix. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Location of Type 1 fonts
Jaldhar H. Vyas asks, I'm confused as to where to place Type 1 fonts. Should they go into /usr/X11R6/lib/X11/fonts/Type1 or /usr/share/fonts/type1? Why do some TeX packages have their fonts under /usr/share/texmf/fonts/type1? I do not pretend to have the full answer to the question, but I see no full answer yet on the list, and this may interest you. The listed Debian packages appear to deal in Type 1 fonts yet seem to have nothing particularly to do with X. Source: debram, ramification [1718 Fonts], standing separately from [1823 X Fonts] for precisely the kind of issue your question raises. Further info at [http://debtags.alioth.debian.org]. 1718 FONTS (39) CM Connelly opt mminstance Multiple-master font utilities for creating AFM or PFB files CM Connelly opt t1utils A collection of simple Type 1 font manipulation programs AR Czechowski opt libt1-5 Type 1 font rasterizer library - runtime AR Czechowski opt libt1-dev Type 1 font rasterizer library - development AR Czechowski opt libt1-doc Type 1 font rasterizer library - developers documentation AR Czechowski opt t1lib-bin Type 1 font rasterizer library - user binaries AR Czechowski opt t1lib-dev Type 1 font rasterizer library - development AR Czechowski opt t1lib1 Type 1 font rasterizer library - runtime A. Fokopt ttf2pt1 A TrueType to PostScript Type 1 Font Converter A. Lees opt defoma Debian Font Manager -- automatic font configuration framework A. Lees opt defoma-doc Debian Font Manager documentation A. Lees opt psfontmgr PostScript font manager -- part of Defoma, Debian Font Manager J. Mouetteopt fontconfig generic font configuration library J. Mouetteopt libfontconfig1 generic font configuration library (shared library) J. Mouetteext libfontconfig1-dbg generic font configuration library (debugging symbols) J. Mouetteopt libfontconfig1-dev generic font configuration library (development headers) C. Silpa-Anan opt fontforge Font Editor for PS, TrueType and OpenType fonts C. Silpa-Anan opt fontforge-doc Font Editor for PS, TrueType and OpenType fonts C. Silpa-Anan opt pfaedit A migration package for FontForge C. Silpa-Anan opt type1inst Install Adobe Type 1 fonts into X11 and Ghostscript -- Thaddeus H. Black 508 Nellie's Cave Road Blacksburg, Virginia 24060, USA +1 540 961 0920, [EMAIL PROTECTED] pgpvYzi6VUFfp.pgp Description: PGP signature
Re: apt-proxy v2 and rsync
On Oct 26, Ian Bruce [EMAIL PROTECTED] wrote: Can anyone explain why rsync is no longer considered an appropriate method for fetching Packages files? It's the only mechanism I'm aware of Because it's hard on servers, for a start. -- ciao, | Marco | [8782 diFcw3LT7Erlw] signature.asc Description: Digital signature
Re: Location of Type 1 fonts
Jaldhar H. Vyas [EMAIL PROTECTED] schrieb: I'm confused as to where to place Type 1 fonts. Should they go into /usr/X11R6/lib/X11/fonts/Type1 or /usr/share/fonts/type1? Why do some TeX packages have their fonts under /usr/share/texmf/fonts/type1? If the fonts are meant to be used by TeX applications, they must reside within the TEXMFMAIN tree, that is /usr/share/texmf/. This only makes sense, however, if the TeX Font Metric files (*.tfm) are also available. Though not strictly necessary to function AFAIK, the font filenames in TEXMFMAIN should follow the Berry scheme. The lmodern package is an example for making fonts available both to TeX applications and to defoma/X11. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: software updates file in /usr -- policy bug?
martin f krafft [EMAIL PROTECTED] schrieb: also sprach Frank Küster [EMAIL PROTECTED] [2004.10.26.2057 +0200]: You should probably tell us non-chatters what The software is... I believe the original post had the reference: apt-spy, pciutils, usbutils, possibly others. The original post reached my inbox just a couple of minutes ago, together with some answers. I hope it's not an ext3 problem again... Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Package name eMail or not?
There was some discussion [1] about an ITP I filed last year for a package called email [2], which suffered from an inappropriate license and name problems. The upstream has since released a newer version under the GPL and has indicated to me a willingness to have the package called eMail. My question is if this change of capitalization acceptable to Debian, or would it still insist on a different package name? It has been recently accepted into Cygwin with the email name [3] and upstream is, for that reason, not too keen to radically alter it. If eMail is not reasonable name, can anyone suggest one that is? Thanks, Millis [1] http://lists.debian.org/debian-devel/2003/06/msg01651.html [2] http://email.cleancode.org/ [3] http://sources.redhat.com/ml/cygwin-apps/2004-10/msg00385.html -- Open WebMail Project (http://openwebmail.org) Debian Project (http://www.debian.org)
Bug#278648: ITP: kkbswitch -- keyboard layout indicator for KDE3
Package: wnpp Severity: wishlist * Package name: kkbswitch Version : 1.4.1 Upstream Author : Leonid Zeitlin [EMAIL PROTECTED] * URL : http://kkbswitch.sourceforge.net/ * License : GPL Description : keyboard layout indicator for KDE3 KKBSwitch is useful when you have configured the XKeyboard extension of your X Server to have more than one keyboard group (layout). KKBSwitch displays an icon in the system tray that indicates which layout is currently active and enables you to switch layouts by clicking the icon or by selecting from the menu. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.6 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Re: Preparation of the next stable Debian GNU/Linux update [Oct 24]
Am 2004-10-26 09:27:22, schrieb Martin Schulze: Michelle Konzack wrote: Hello Martin and *, Am 2004-10-24 11:24:26, schrieb Martin Schulze: Preparation of the next stable Debian GNU/Linux update == You should first check whether they exist no the original security server. If they do, you'll have to contact the ftp.de mirror maintainer. Every time I have tried to connect toftp://security.debian.org/ I have goten a Connection refused. So I was looking for an oter Mirror... And I used http I had to wait a day for downloading stuff. Have checked the ftp for some seconds before I had begun this mail... Now it works ? :-) Sorry for the reclamation... Last time I have used security.debian.org was for 18 month or something like this Regards, Joey Sorry for the reclamation... Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
aide 0.8-2 moved /etc/aide/aide.conf to /usr/local/etc/aide.conf
Hello, I've just installed aide for woody but it was required to move /etc/aide/aide.conf to /usr/local/etc/aide.conf. Can someone reproduce this if it's a bug or not ? -- Best Regards, Mark
Re: Bug#278075: ITP: libical0 -- An implementation of basic iCal
On Thu, 28 Oct 2004 11:04:51 +0200 Gürkan Sengün [EMAIL PROTECTED] wrote: Brent has already a packaged libical here: http://people.debian.org/~bfulgham/gnustep/ Yeah, but that's not in the archive :) And even having that one it wouldn't serve, as vcalendar plugin needs specifically the 0.23 (stable) version (that RC modifies the API). regards, -- Ricardo Mones Lastra - [EMAIL PROTECTED] Centro de Inteligencia Artificial, Universidad de Oviedo en Gijon 33271 Asturias, SPAIN. - http://www.aic.uniovi.es/mones
Re: Location of Type 1 fonts
Le lundi 25 octobre 2004 16:16 -0400, Jaldhar H. Vyas a crit : I'm confused as to where to place Type 1 fonts. Should they go into /usr/X11R6/lib/X11/fonts/Type1 or /usr/share/fonts/type1? Why do some TeX packages have their fonts under /usr/share/texmf/fonts/type1? Generally, fonts should be placed under /usr/share/fonts. If not, it's better if they are registered with defoma. This way they'll be available to most applications through fontconfig. TeX does its own stuff with fonts, and it's not enough to drop a font in the TeX directory to make it available to TeX documents. It would be possible, but quite complicated, using defoma. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: Bug#278255: ITP: rdflib -- A python library for working with RDF
Le mercredi 27 octobre 2004 20:12 +0200, Alberto Rodriguez Galdo a
crit :
deb http://www.igaelica.com/debian ./
It's name is python2.3-rdflib as it depends on python 2.2
Please, don't do that. You should name it python-rdflib and use
${python:Depends} to generate the python dependency. Build-depending on
python (= 2.3) will ensure older versions of python won't be used to
build the package.
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Debian GNU/Linux -- The power of freedom
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
d-i using kexec
Has anybody ever considered the possibility of a 0-reboot installation? It seems that this should be possible with (or without?) kexec. I think the reason the installer presently reboots is to load the *real* kernel (which will be used during normal runtime) rather than the installer kernel. Rebooting also allows the boot process as a whole to get tested (Did the MBR get written correctly?). Are there other reasons? Justin signature.asc Description: Digital signature
Re: software updates file in /usr -- policy bug?
On Wed, Oct 27, 2004 at 08:28:26AM +0200, martin f krafft wrote: also sprach paddy [EMAIL PROTECTED] [2004.10.26.2114 +0200]: What software writes to /usr ? As noted in the OP, apt-spy, pciutils, and probably others. My apologies, I only just got that post today! I dived in a little early, but I've read that and #277816, so I may as well throw in my twopenneth: IMHO, The FHS is a little fuzzy on /usr/share: Any program or package which contains or requires data that doesn't need to be modified should store that data in /usr/share In any case, I imagine wanting to support the degenerate case of /usr/share on a /usr filesystem mounted ro. I have sympathy with 'the administrator does it'. And I believe in supplying the best possible tools for the administrator. By default, data which might otherwise live under /usr, but is moved out because it is variable, would go to /var somewhere (or a better place if one exists). So the question must be: What use is served by keeping this data in /usr/share? I'd also question whether this data is truly 'not host specific'. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
An important lesson
Developers, do not allow http://www.google.com/search?q=inurl%3Asecring.gpg to happen to you. -- Matthew Garrett | [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Preparation of the next stable Debian GNU/Linux update [Oct 24]
Hello Joey, You should first check whether they exist no the original security server. If they do, you'll have to contact the ftp.de mirror maintainer. OK, checked... I have changed the Server to ftp://security.debian.org and gotten the same problem: ( 'stdin' )___ / | 2004-10-28 15:56:57 : Reading tddebmirror | 2004-10-28 15:56:57 : Reading values for Server 1 | 2004-10-28 15:56:57 : 1 : ftp://security.debian.org/debian-security | 2004-10-28 15:56:57 : 1 : = Downloading Packages.gz | 2004-10-28 15:57:03 : 1 : Creating file list | 2004-10-28 15:57:05 : 1 : Get target directories. | 2004-10-28 15:57:05 : 1 : Create target directories. | : 1 : Erase old files. | : 1 : Create download list. | 2004-10-28 15:57:25 : 1 : Downloading packages. | 2004-10-28 15:57:25 : 1 : 15054 : cabextract_0.2-2b_i386.deb | 2004-10-28 15:57:26 : 1 : 66898 : catdoc_0.91.5-1.woody3_i386.deb | 2004-10-28 15:57:29 : 1 : Downloading finished. | 2004-10-28 15:57:29 : 1 : Create Packages.gz. | 2004-10-28 16:00:31 : 1 : = Downloading Sources.gz | 2004-10-28 16:00:33 : 1 : Get source directories. | 2004-10-28 16:00:33 : 1 : Make target directories. | 2004-10-28 16:00:33 : 1 : Create download list. | 2004-10-28 16:00:43 : 1 : Erase old files. | : 1 : Create download list. | 2004-10-28 16:01:03 : 1 : Downloading sources. | 2004-10-28 16:01:03 : 1 : missing : bind9_9.2.1.orig.tar.gz | 2004-10-28 16:01:04 : 1 : 2314 : cabextract_0.2-2b.diff.gz | 2004-10-28 16:01:06 : 1 : 568 : cabextract_0.2-2b.dsc | 2004-10-28 16:01:07 : 1 : 66136 : cabextract_0.2.orig.tar.gz | 2004-10-28 16:01:10 : 1 : 14289 : catdoc_0.91.5-1.woody3.diff.gz | 2004-10-28 16:01:12 : 1 : 571 : catdoc_0.91.5-1.woody3.dsc | 2004-10-28 16:01:14 : 1 :123460 : catdoc_0.91.5.orig.tar.gz | 2004-10-28 16:01:18 : 1 : missing : kdegames_2.2.2.orig.tar.gz | 2004-10-28 16:01:20 : 1 : missing : lv_4.49.4.orig.tar.gz | 2004-10-28 16:01:21 : 1 : missing : lynx_2.8.4.1b.orig.tar.gz | 2004-10-28 16:01:22 : 1 : missing : osh_1.7.orig.tar.gz | 2004-10-28 16:01:23 : 1 : Downloading finished. | 2004-10-28 16:01:23 : 1 : Create Sources.gz. | 2004-10-28 16:01:30 : 1 : = Create dists/woody/updates/Release | : 1 : = with md5sum | 2004-10-28 16:01:30 : 1 : = Finished. \__ The five missing files are not on ftp://security.debian.org/ but the diff.gz and dsc are still there. ftp://security.debian.org/debian-security/pool/updates/main/b/bind9/bind9_9.2.1.orig.tar.gz ftp://security.debian.org/debian-security/pool/updates/main/k/kdegames/kdegames_2.2.2.orig.tar.gz ftp://security.debian.org/debian-security/pool/updates/main/l/lv/lv_4.49.4.orig.tar.gz ftp://security.debian.org/debian-security/pool/updates/main/l/lynx/lynx_2.8.4.1b.orig.tar.gz ftp://security.debian.org/debian-security/pool/updates/main/o/osh/osh_1.7.orig.tar.gz Should I fill a Bugreport ? And if yes, against what ? Regards, Joey Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Versioned bugs in the BTS (was: Drop testing)
* Frank Küster ([EMAIL PROTECTED]) [041028 17:00]: Matthias Urlichs [EMAIL PROTECTED] wrote: Besides, we'll have a bug database which tracks version numbers. This in turn means that we have a nice distinction between bugs that are actually RC in the fix this if we'd want to release Etch tomorrow sense, and bugs that are RC in the keep this out of testing sense. This sounds great, and I heard that it has been promised for after the sarge release, sounding as if it was implemented yet. Is the counterpart also implemented, namely testing scripts that take this information into account? The implementation of version in the BTS is done so that the second is not _so_ hard to implement (speaking as someone who has seen lots of parts of britney). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: RFS: kmenc15 - An advanced Qt/KDE MEncoder frontend.
Shaun Jackman [EMAIL PROTECTED] wrote: Perhaps that's true -- I must do a little reading. However, if you upload a package to contrib that build-depends on a package not in contrib or non-free, you'll get a FTBFS RC bug filed against you before you blink. Are there any (inofficial) buildds for contrib? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
special request - no spam - seriously!
Hi I know that this is for sure an usual request posted on this list. Sorry for that. But I am desperately looking for Debian hacker which are also engaged in Linux. I know that Linux is not far from Debian. Anyway. For my final thesis dealing with coordination mechanism and coordination success at Linux I am looking for volunteers reserving some time for an e-mail or telephone interview. If you may want to support me on that just let me know. Kind regards, Falko Klein PS. I am student of business administration at University of Eichstaett-Ingolstadt, Germany. Also see www.wfi.edu -- Falko Klein Münzbergstrasse 9 85049 Ingolstadt Tel +49- 841- 931 8852 Fax +49- 841- 931 8852 Mobil +49- 172- 5158651 e-Mail [EMAIL PROTECTED] NEU +++ DSL Komplett von GMX +++ http://www.gmx.net/de/go/dsl GMX DSL-Netzanschluss + Tarif zum supergünstigen Komplett-Preis!
Re: Comparing FHS 2.3 and 2.1
Ron Johnson wrote: On Wed, 2004-10-27 at 19:53 -0400, Joey Hess wrote: paddy wrote: On Wed, Oct 27, 2004 at 11:28:14AM +0200, Wouter Verhelst wrote: On Tue, Oct 26, 2004 at 03:02:02PM -0500, Manoj Srivastava wrote: 5)== User specific configuration files for applications are stored in the user's home directory in a file that starts with the '.' character (a dot file). If an application needs to create more than one dot file then they should be placed in a subdirectory with a name starting with a '.' character, (a dot directory). In this case the configuration files should not start with the '.' character. I have no idea if we comply, but this is a new requirement. I think we do. This is common sense anyway, most applications I've seen do it that way. what about ~/Desktop and friends? I don't know if Desktop falls under the heading of being a configuration file or directorty. Not that I much like that directory, but like Maildir, it seems out of the scope of this FHS requirement. Is ~/Desktop a User specific configuration files for applications? Doesn't seem like it to me. It and ~/Maildir are data directories. [EMAIL PROTECTED]:~$ ll Desktop lrwxrwxrwx 1 pretzalz pretzalz 29 Dec 30 2003 Desktop - /home/pretzalz/.gnome-desktop Seems an almost implicit admission that Desktop is wrong. If I really wanted that symlink I could make it myself. And I don't use it but I thought .gnome-desktop/Desktop is where you configure via symlinks what you want to show up on your desktop. signature.asc Description: OpenPGP digital signature
Re: An important lesson
On Thu, Oct 28, 2004 at 03:40:48PM +0100, Matthew Garrett wrote: Developers, do not allow http://www.google.com/search?q=inurl%3Asecring.gpg to happen to you. And it's better to repeat it three times: http://debian-amd64.alioth.debian.org/pure64/wanna-build/secring.gpg http://ftp.belnet.be/linux/debian-amd64/wanna-build/secring.gpg http://ftp.belnet.be/pub/mirror/debian-amd64.alioth.debian.org/wanna-build/secring.gpg Mike
Re: Bug#262507: ITP: resmgr -- resource manager library
On Wed, Oct 27, 2004 at 05:03:43PM +0200, Julien BLACHE wrote: For those of you interested, I've uploaded resmgr 1.0-1 to experimental (must go through NEW, etc.). I'll upload a version of sane-backends built with resmgr support to experimental when sane-backends 1.0.15 will be released (end of next week, IIRC). I plan to have SANE built with resmgr support for Etch, and I hope other applications will support resmgr too. It can make life a lot easier, and changes to the code are really minimal. It is, however, a security hole; it's functionally equivalent to pam_console (which we declined to ship in the past) and has the same problems. As such it's not really an improvement in security over making devices group- or world-accessible. resmgr must not be enabled by default and should carry a big warning; you can only use it in scenarios where you would be willing to use pam_console. (Why somebody bothered to implement resmgr instead of simply enhancing pam_console is beyond me; probably NIH) -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: An important lesson
Matthew Garrett wrote: Developers, do not allow http://www.google.com/search?q=inurl%3Asecring.gpg to happen to you. I haven't checked lately, but at least some of those used to be: (a) secret keys used in regression tests, (b) honeypots and (c) findable via google but not downloadable cheers stuart -- Stuart Yeates[EMAIL PROTECTED] OSS Watch http://www.oss-watch.ac.uk/ Oxford Text Archive http://ota.ahds.ac.uk/ Humbul Humanities Hub http://www.humbul.ac.uk/
Re: An important lesson
On Thursday 28 October 2004 16.40, Matthew Garrett wrote: Warning: The signature is bad. I guess this was unavoidable in a posting about a security related issue with GnuPG... greetings -- vbi -- Oops pgpsZSnPddRmR.pgp Description: PGP signature
Re: USE flags ??
On Thursday 28 October 2004 07:18, Jon Dowland wrote: i still like them both and still run both on servers, You run gentoo on *SERVERS*!?!?! I guess someone would have to define servers in this context. A news server for downloading special avi files is not really a server in the sense of legitimacy, and/or 24/7 uptime...Someone who brags about inane Gentoo things (not that Gentoo isn't a great technology demonstration) strikes me as the type who would be running a server with such a loose definition of the word and bragging about it. Try replicating that setup with Gentoo. Good luck to him. *flame suit on* B
Re: d-i using kexec
Justin Pryzby wrote: Has anybody ever considered the possibility of a 0-reboot installation? It seems that this should be possible with (or without?) kexec. I think the reason the installer presently reboots is to load the *real* kernel (which will be used during normal runtime) rather than the installer kernel. That and so if it *doesn't* boot, you don't find yourself 3 hours (or 3 days) into installing Debian only to have to start over because of some problem with the boot loader. Note that in some installation methods in expert mode, there is a menu item down near the bottom that lets you run the second stage if installation without rebooting, although this is not well tested. -- see shy jo signature.asc Description: Digital signature
Re: aide 0.8-2 moved /etc/aide/aide.conf to /usr/local/etc/aide.conf
[EMAIL PROTECTED] wrote: Hello, I've just installed aide for woody but it was required to move /etc/aide/aide.conf to /usr/local/etc/aide.conf. Can someone reproduce this if it's a bug or not ? # apt-cache policy aide aide: Installed: 0.8-2 Candidate: 0.8-2 Version Table: *** 0.8-2 0 No problems here. Aide conf file is in /etc/aide as it is suppose to be. - Adam -- Building your applications one byte at a time http://www.galacticasoftware.com
deletion of xpackman dir
hi, today i checked my local debian mirror and i saw that var/www/debian/pool/non-free/x/xpacman/ is an empty directory. can someone delete it? regards nico -- Nico Golde - [EMAIL PROTECTED] [EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.ngolde.de GPG: FF46 E565 5CC1 E2E5 3F69 C739 1D87 E549 7364 7CFF Is there life after /sbin/halt -p? signature.asc Description: Digital signature
AMD64 Archive Key compromised!
Matthew Garrett wrote: Developers, do not allow http://www.google.com/search?q=inurl%3Asecring.gpg to happen to you. Yeah. debian-amd64.alioth.debian.org/pure64/wanna-build/secring.gpg http://debian-amd64.alioth.debian.org/pure64/wanna-build/secring.gpg is Forbidden, but ftp.belnet.be/linux/debian-amd64/wanna-build/secring.gpg http://ftp.belnet.be/linux/debian-amd64/wanna-build/secring.gpg ftp.belnet.be/pub/mirror/debian-amd64.alioth.debian.org/wanna-build/secring.gpg http://ftp.belnet.be/pub/mirror/debian-amd64.alioth.debian.org/wanna-build/secring.gpg are wide open. So, with no further delay, here's the revocation certificate for the AMD64 archive key! Man, people had secret keys on broken in machines and those were removed from the archive. But to have a secring.gpg on Google? I also took the liberty to send this revocation certificate to keyring.debian.org -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.2.5 (GNU/Linux) Comment: A revocation certificate should follow iGYEIBECACYFAkGBKG4fHQJzZWNyaW5nLmdwZyBmb3VuZCBvbiBHb29nbGUhIQAK CRCVXxufOIK6/GbFAJ4yTldjZzm015upfsAcKwNoFf5y8wCdHRGITdO2XRWnbZy+ 3q7JMAf9CI4= =rMmn -END PGP PUBLIC KEY BLOCK- -- Building your applications one byte at a time http://www.galacticasoftware.com
Re: Bug#278255: ITP: rdflib -- A python library for working with RDF
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
El Jueves, 28 de Octubre de 2004 16:24, Josselin Mouette escribió:
Le mercredi 27 octobre 2004 à 20:12 +0200, Alberto Rodriguez Galdo a
écrit :
deb http://www.igaelica.com/debian ./
It's name is python2.3-rdflib as it depends on python 2.2
Please, don't do that. You should name it python-rdflib and use
${python:Depends} to generate the python dependency. Build-depending on
python (= 2.3) will ensure older versions of python won't be used to
build the package.
Done, thanks
- --
Alberto Rodriguez Galdo
GPG 747A7479
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBgSnMwlFDGnR6dHkRArfeAJ9q4oMM3mambdPzabm07eUZJ9NmzQCgysxV
PIbfu1h04Vcnowa0Bf9DPnQ=
=xs35
-END PGP SIGNATURE-
Re: SourceForge.net PR-Web Upgrade Notice.
Luke Kenneth Casson Leighton wrote: i'm forwarding this to debian devel for people's attention because it would appear that debian has lost a quite large opportunity - by not having selinux available. PR choices, not much else. It is also entirely possible the last of the Debian faithful have left VA / SF.net. For the record, the slow release times were welcomed (mostly) by the admin staff. They were used to things like Solaris or AIX which took a while to put out the next version. I keep using the past tense because my hunch is this decision is being made by new admins for new reasons.
Re: Several X applications refuse to start
Andreas Tille wrote: On Thu, 28 Oct 2004, Simon Huggins wrote: Is this a Transmeta Crusoe based laptop? No. It is centrono based and I guess this is rather a problem of some pure X applications, because Gnome and KDE applications and also Mozilla are behaving fine. The only thing is that sometimes fonts are not rendered nicely (for instance the fonts in the menu of xmms look ugly and do not seem to use TrueType fonts. 1) what locale? try C. 2) this looks like a font issue (as you mentioned) try forcing the app to load 'fixed' as its font.
Re: An important lesson
On Thu, 2004-10-28 at 18:08 +0200, Adrian 'Dagurashibanipal' von Bidder wrote: On Thursday 28 October 2004 16.40, Matthew Garrett wrote: Warning: The signature is bad. I guess this was unavoidable in a posting about a security related issue with GnuPG... Verifies fine here. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: Why sysklog uses its own logrotate and not logrotate script
and before anybody asks, I already but all the things into logrotate. I just curious why its not there from beginning. With current default configuration, if I add some more log files info /etc/syslog.conf (e.g. to catch localN facilities), they get rotation automatically. Can the same be achieved with logrotate same (without having to add new files to logrotate configuration manually - it's always bad to duplicate configuration)?
Re: Comparing FHS 2.3 and 2.1
Speaking of which: there used to be some proposed addition to FHS about re-locating all dot-files into ~/etc or some directory like that. Does anybody know what happened to that? I'm aware of the problems (sharing $HOME over several different machines etc.), but but I'll be glad if the mess were out of $HOME. I think there is little hope here. There are too many apps out that treat home directory as a wastebasket, and probably Linux/Unix itself will be obsoleted faster than all those.
Re: Bug#262507: ITP: resmgr -- resource manager library
Andrew Suffield [EMAIL PROTECTED] wrote: Hi, I plan to have SANE built with resmgr support for Etch, and I hope other applications will support resmgr too. It can make life a lot easier, and changes to the code are really minimal. It is, however, a security hole; it's functionally equivalent to pam_console (which we declined to ship in the past) and has the same It's a bit better than pam_console, however, which has a lot of issues. I uploaded to experimental to get some feedback on the possible security issues/implications; I'm still trying to determine whether there are holes (read: bigger holes than those which can exist with other solutions) or not. Could you point out the security issues you see in resmgr ? I note that SuSE ships resmgr and has a couple of resmgr-enabled applications. Of course, RedHat ships pam_console, so that's not a point (and they're having a whole lot of problems with it, again). problems. As such it's not really an improvement in security over making devices group- or world-accessible. It doesn't claim to be a more secure solution than fiddling with ownership and permissions, only to be more convenient (and I tend to think that it is). resmgr must not be enabled by default and should carry a big warning; you can only use it in scenarios where you would be willing to use pam_console. As it is currently : - rsm_open_device() will fall back to a call to open() if resmgrd isn't available, so resmgr-enabled applications do not depend on resmgrd being up running; - resmgrd isn't installed by default, you need to explicitly install it (no dependencies, only a Recommends that could be downgraded to a Suggests to avoid side-effects with some frontends to apt); - resmgrd won't be started until configured (no default config is shipped in the package, only an example config file); - you need to add pam_resmgr to your PAM config files by hand. I will add the big blinking warning if/when it goes into unstable (if there's a consensus against resmgr, I'll withdraw the ITP) if needed. (Why somebody bothered to implement resmgr instead of simply enhancing pam_console is beyond me; probably NIH) If you haven't already, you might want to read http://rechner.lst.de/~okir/resmgr/description.html I'm still reviewing resmgr and I probably won't be done with it for some more months (being low on free time). I won't upload to unstable unless I'm sure it cannot harm and it isn't a gapping security hole. The idea is to provide a tool to sysadmins who might want to use it, and not something that works out of the box, with a half-broken default config. Thanks for your feedback, JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
Re: d-i using kexec
I demand that Justin Pryzby may or may not have written... Has anybody ever considered the possibility of a 0-reboot installation? It seems that this should be possible with (or without?) kexec. I think the reason the installer presently reboots is to load the *real* kernel (which will be used during normal runtime) rather than the installer kernel. Rebooting also allows the boot process as a whole to get tested (Did the MBR get written correctly?). Are there other reasons? WRT Acorn and compatible hardware... In the absence of r/w support for ADFS (is it absent in the install kernel for ARM? I've not checked), it'd be needed to allow the installed kernel to be copied into the boot partition and to give the admin a chance to edit the loader script. In the presence of said r/w support, you'll _definitely_ want /dev/hda1 to be mounted as /boot if you want to do this from Linux. In the MBR, there's no loader program to worry about ;-) -- | Darren Salt | linux (or ds) at | nr. Ashington, | woody, sarge, | youmustbejoking | Northumberland | RISC OS | demon co uk | Toon Army | URL:http://www.youmustbejoking.demon.co.uk/progs.linux.html Do not speak about Time until you have spoken to him.
Re: Drop testing
On Mon, Oct 25, 2004 at 02:03:31AM +1000, Anthony Towns wrote: Trivial analysis: () The release managers have been putting some effort into (a)(1) over the past year, and there's four of them now instead of just one. How much effort has the project been putting into the other factors? I think there has been a lot of effort put in (a)(2), and (b)(1), throughout the year, it's just that we have more software (and bugs) than people willing (or with sufficient time or capabilities) to fix them. We should either have more people or less software. I think there's only one reasonable answer to that dilemma. The fact that a lof of effort goes into (a)(2) but does not result into a release in the time-frame we planned also makes people abandon their effort due to desesperation. No matter how many RC bugs we fix in the distribution there are always new ones on the road ahead. Also note that there are _many_ patches in the BTS for RC (and many other bugs). But RC bugs do not get fixed in time [0] this also shows that a number of packages are not being properly maintained and we maybe could maybe think a way to force the maintainer to give over maintainership if he is overloaded with other work and he cannot fix the package in time. Probably there are non-technical problems with the uncoming release. But there are technical problems also, yes? Why not eliminate those? If instead of each mail in this thread a single RC bug that affects sarge was fixed, probably there could be *zero* such bugs now. Why not do both? Every time you post a mail to a thread like this, fix an RC bug. This is the ObBug: rule. ObBug: 277099 Regards Javier [0] For obvious reasons this usually happens with popular software or important parts of the system. Take a look at the (non-RC bugs) open against sysklogd, just to pick one which I've been looking today (not necessarily the worst one). signature.asc Description: Digital signature
Re: Waiting for unfinished jobs....
El Martes, 26 de Octubre de 2004 02:06, Anibal Monsalve Salazar escribió: Package harbour is FTBFS on alpha, s390, m68k, powerpc and mips, as you can see at: http://buildd.debian.org/build.php?pkg=harbour Could someone shed some light on this problem? Hi Anibal. I'm the maintainer of Harbour. Recent commits of Przemyslaw Czerpak in harbour's cvs makes harbour code more arch-independant, and also enables compilation in AMD64. I'll package a cvs snapshot a.s.a.p. -- .''`. Proudly running (again) Debian GNU/Linux Sid (Kernel 2.6.8) : :' : http://www.linuxadicto.org http://mayoral.blogalia.com `. `' GnuPG KeyID: 8C9DA2A4 JID: [EMAIL PROTECTED] `- Listening to: Prince The New Power Generation - Gett off pgppDFasxUKdq.pgp Description: PGP signature
Re: Bug#262507: ITP: resmgr -- resource manager library
On Thu, Oct 28, 2004 at 08:46:18PM +0200, Julien BLACHE wrote: I plan to have SANE built with resmgr support for Etch, and I hope other applications will support resmgr too. It can make life a lot easier, and changes to the code are really minimal. It is, however, a security hole; it's functionally equivalent to pam_console (which we declined to ship in the past) and has the same It's a bit better than pam_console, however, which has a lot of issues. I uploaded to experimental to get some feedback on the possible security issues/implications; I'm still trying to determine whether there are holes (read: bigger holes than those which can exist with other solutions) or not. Could you point out the security issues you see in resmgr ? The primary one is the same as pam_console: once you have an fd open, you can keep it open for as long as you like. So all the fancy restrictions on when you can open a device don't actually do anything; if you can open it at any time, you have effective access, reducing it to the same level of security as group permissions. (Doing something about this would require either a genuine userspace *proxy*, or kernel support; there's a few proposals floating around about how pam_console could have done it right). While it may make sense on some public terminals or demonstration systems, you do not want it on hosts where device security is important. [Also, it's a liability to have a process running as root which opens devices and then hands fds over to non-root processes; it could form part of a privilege escalation attack. So you don't want it running without a good reason]. I note that SuSE ships resmgr and has a couple of resmgr-enabled applications. Of course, RedHat ships pam_console, so that's not a point (and they're having a whole lot of problems with it, again). Yes, they just don't care. Secure-by-default isn't really a priority for them. If you run a server on suse then resmgr is one of those things you have to go through and rip out, like pam_console on redhat. - resmgrd isn't installed by default, you need to explicitly install it (no dependencies, only a Recommends that could be downgraded to a Suggests to avoid side-effects with some frontends to apt); I'd say that's the really important one; we need to keep it that way. - resmgrd won't be started until configured (no default config is shipped in the package, only an example config file); And that's probably a good idea too (along with documentation that clearly states what it does and does *not* do). (Why somebody bothered to implement resmgr instead of simply enhancing pam_console is beyond me; probably NIH) If you haven't already, you might want to read http://rechner.lst.de/~okir/resmgr/description.html Yeah, they gave up on the puzzle of how to fix pam_console without really trying. It's not as hard as they made it look; mostly you just have to add hotplug support, and have pam_console itself record the current user in a file or process someplace. Quite ironically, the solutions to the problems they cite for pam_console are exactly the same as the solutions they implemented for resmgr. Hence I figure it was probably NIH. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Drop testing
* Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]) [041028 22:00]: Also note that there are _many_ patches in the BTS for RC (and many other bugs). But RC bugs do not get fixed in time [0] this also shows that a number of packages are not being properly maintained and we maybe could maybe think a way to force the maintainer to give over maintainership if he is overloaded with other work and he cannot fix the package in time. I plan to go through the packages that are not released with sarge, and propose to orphan / delete some / most of them. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: RFS: kmenc15 - An advanced Qt/KDE MEncoder frontend.
On Thursday 28 October 2004 15:15, Thaddeus H. Black wrote: Hello Oded. snip Again, good luck. If and when you find an appropriate sponsor, let me know the good news. Wow, honestly, that was some damn great advice... And it does sound very accurate and I do understand it. I don't know if I will follow through with it or not. I recently quit my job (good thing. fast food...), so I have plenty of time on my hands, so I might, on the other hand, I start army in less than 2 months (mandatory). I understand Debian's interest in wanting people this serious and hard working, and putting these trials for them... But I must admit, it almost sounds not worth it for my project... :/ I simply developed kmenc15 myself for fun, put it up on some sites, and thought, why not have it also up on my favorite distro, and I never thought it would be something this complicated. My package requires relatively very small amount of maintaining (grand total of 100k including 90k of images :), and I have the obvious advantage of being both the author and maintainer... :) For this reason I find the trials almost pointless, as even a non-serious programmer can handle it. Even though, for the pure cause of boredom, I might follow up on your very great advice, I'd like to think of myself as someone serious enough to do these things. I have no plan of becoming a DD though. I would only be very proud to see my favorite program in my favorite GNU/Linux distro An honest Thankyou. - ods15
Re: Drop testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/28/2004 01:43 AM, Christoffer Sawicki wrote: The Debian Desktop Distribution will be something like this. I believe more details will be available soon. Until then, http://debiandesktop.org/ has a concept paper. Is this a fork from the main debian distribution? lg, clemens -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBgXGzjBz/yQjBxz8RAmYoAKDhEcoRBhsv4lil50ARdAQjlSsE9gCgyHxN goA9JmMB0E0T01W1ubktOWI= =ZLA7 -END PGP SIGNATURE-
Re: NMU on sysklogd
[Jerome Warnier] Could someone go through the list and NMU this? I'm willing to help, if necessary. The maintainer of sysklogd have a problematic relationship with NMUs. Have a look at bug #225895 for an ironic view on this. :)
Re: NMU on sysklogd
On Fri, 2004-10-29 at 00:46 +0200, Petter Reinholdtsen wrote: [Jerome Warnier] Could someone go through the list and NMU this? I'm willing to help, if necessary. The maintainer of sysklogd have a problematic relationship with NMUs. Have a look at bug #225895 for an ironic view on this. :) So what? Am I stuck with my problem like so many people are already? And a friendly takeover of the package? I already have to problem on at least 4 machines, with things as POP-before-SMTP and log analysers, packaged in Debian. -- Jerome Warnier [EMAIL PROTECTED] BeezNest s.a r.l.
Re: RFS: kmenc15 - An advanced Qt/KDE MEncoder frontend.
On Thu, Oct 28, 2004 at 05:10:04PM +0200, Frank Küster wrote: Shaun Jackman [EMAIL PROTECTED] wrote: Perhaps that's true -- I must do a little reading. However, if you upload a package to contrib that build-depends on a package not in contrib or non-free, you'll get a FTBFS RC bug filed against you before you blink. Are there any (inofficial) buildds for contrib? None that I am aware of, at least. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: Waiting for unfinished jobs....
On Tue, Oct 26, 2004 at 10:06:48AM +1000, Anibal Monsalve Salazar wrote: Hello, Package harbour is FTBFS on alpha, s390, m68k, powerpc and mips, as you can see at: http://buildd.debian.org/build.php?pkg=harbour Could someone shed some light on this problem? A build log extract follows. [...] gcc -I. -I../../../../include -Wall -g -c ../../hbmlang.c -ohbmlang.o ../../../../source/compiler/linux/gcc/harbour ../../hbmake.prg -n -q0 -w -es2 -gc0 -I../../ -I../../../../include make[4]: *** wait: No child processes. Stop. make[4]: *** Waiting for unfinished jobs make[4]: *** wait: No child processes. Stop. make[3]: *** [descend] Error 2 make[1]: *** [first] Terminated make[2]: *** [first] Terminated make: *** [build-stamp] Terminated Build killed with signal 15 after 150 minutes of inactivity [...] This is usually an internal buildd issue, and shouldn't be your problem. In an attempt to prevent builds from using up too much buildd resources, sbuild (the program in the buildd suite which does the actual building) keeps an internal timer for every build that is running; if no output arrives in the log file within that time, the build is killed for fear of a loop. The default time which is allocated to a build is 150 minutes; the messages you see originate from make receiving SIGTERM. If it is indeed expected behaviour that the harbour build is silent for more than 150 minutes in a row, then the timeout will have to be increased (this can be done on a per-package, per-buildd basis), and the build retried, but this is part of the routine maintenance of a buildd. If your package is not in either 'building' of 'needs-build' on an architectur after having been built with such a result, then please contact the buildd admins of the architecture involved; they'll be able to tell you why this was done. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: An important lesson
On Thu, 28 Oct 2004, Scott James Remnant wrote: On Thu, 2004-10-28 at 18:08 +0200, Adrian 'Dagurashibanipal' von Bidder wrote: On Thursday 28 October 2004 16.40, Matthew Garrett wrote: Warning: The signature is bad. I guess this was unavoidable in a posting about a security related issue with GnuPG... Verifies fine here. If you ignore the: gpg: WARNING: This key has been revoked by its owner! gpg: This could mean that the signature is forgery. gpg: reason for revocation: Key has been compromised gpg: revocation comment: Compromised on the uid/gid remapping on alioth perhaps. Don Armstrong -- Quite the contrary; they *love* collateral damage. If they can make you miserable enough, maybe you'll stop using email entirely. Once enough people do that, then there'll be no legitimate reason left for anyone to run an SMTP server, and the spam problem will be solved. Craig Dickson [EMAIL PROTECTED] http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Comparing FHS 2.3 and 2.1
On Tue, Oct 26, 2004 at 03:02:02PM -0500, Manoj Srivastava wrote: 5)== User specific configuration files for applications are stored in the user's home directory in a file that starts with the '.' character (a dot file). If an application needs to create more than one dot file then they should be placed in a subdirectory with a name starting with a '.' character, (a dot directory). In this case the configuration files should not start with the '.' character. I have no idea if we comply, but this is a new requirement. Holy... and that's the area of FHS... how? First, does every single package have to comply with this? Off the top of my head: * aspell stores user's dictionaries in ~/, and it store several files per languaje. * bash reads and writes a number of files in ~/ (.bash_profile, .bashrc, .bash_history) * there are several directories related to GNOME (at least ~/.gnome2 and ~/.gnome2_private) * vim has ~/.vimrc, ~/.viminfo (configure IIRC), ~/.vim/ * Window Maker stores its configuration across several files and directories under ~/GNUstep (configurable) (and no, I won't change the default because it's configurable via an environment variable) So, we have a few minor things to tweak (/media, /srv, and the XF86Config stuff, and then we should be OK to move to FHS 2.3 in Etch. Isn't the configuration file used by the X.org server called something else? (It's rather silly to hardcode the name of a configuration file used by a specific vendor) Marcelo
Re: apt-proxy v2 and rsync
On Thu, Oct 28, 2004 at 01:54:54PM +0200, Adrian 'Dagurashibanipal' von Bidder wrote: IIRC the problem is that rsync is quite CPU-heavy on the servers, so while the mirrors have the (network) resources to feed downloads to 100s of users, they don't have the (CPU) resources for a few dozen rsyncs. And shouldn't this be left as a decision for the mirror administrators? It's not like setting up a mirror _automatically_ allows rsync access to it, isn't it? Marcelo
Bug#278741: ITP: unalz -- The unalz tool is the utility used for decompressing alzip format file.
Package: wnpp Severity: wishlist * Package name: unalz Version : 0.21 Upstream Author : hardkoder [EMAIL PROTECTED] * URL : http://www.kipple.pe.kr/win/unalz/ * License : BSD Description : The utility used for decompressing alzip format file. The unalz tool is the utility used for decompressing alzip format file. It mainly operates on files with names ending in '.alz'. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.26 Locale: LANG=ko_KR.eucKR, LC_CTYPE=ko_KR.eucKR (charmap=EUC-KR) (ignored: LC_ALL set to ko_KR.eucKR)
Re: apt-proxy v2 and rsync
On Tue, Oct 26, 2004 at 12:20:19AM -0700, Ian Bruce said Now that gzip has the --rsyncable option, wouldn't it be feasible to rsync against compressed Packages files rather than having to keep the uncompressed ones around for this purpose? You have to explicitly enable this option, which is not currently done. -rob -- Words of the day: strategic jihad argus airframe Sears Tower BLU-114/B
Accepted midentd 2.3.1-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 28 Oct 2004 09:21:47 +0200 Source: midentd Binary: midentd Architecture: source i386 Version: 2.3.1-3 Distribution: unstable Urgency: low Maintainer: Turbo Fredriksson [EMAIL PROTECTED] Changed-By: Turbo Fredriksson [EMAIL PROTECTED] Description: midentd- An ident replacement with masquerading support. Closes: 242411 Changes: midentd (2.3.1-3) unstable; urgency=low . * Before trying to remove an override, see if there IS one. Closes: #242411 Files: b2b188dbaa4196182886a2ac2ec77e41 595 net extra midentd_2.3.1-3.dsc 423973c93ae77139408cba4359d493f1 4341 net extra midentd_2.3.1-3.diff.gz 8caa4043e415efb4f935d7ea45af67d0 12384 net extra midentd_2.3.1-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFBgJ5MmlWzPKccHgARAlerAJwJDgZoVFYMnkQVylTLRtDRo9b2HQCdEj9i Dx9lTlyX3UFfzR3tRRZnrwk= =xHq3 -END PGP SIGNATURE- Accepted: midentd_2.3.1-3.diff.gz to pool/main/m/midentd/midentd_2.3.1-3.diff.gz midentd_2.3.1-3.dsc to pool/main/m/midentd/midentd_2.3.1-3.dsc midentd_2.3.1-3_i386.deb to pool/main/m/midentd/midentd_2.3.1-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted roxen-fonts-iso8859-1 0-7 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 28 Oct 2004 09:32:19 +0200 Source: roxen-fonts-iso8859-1 Binary: roxen-fonts-iso8859-1 Architecture: source all Version: 0-7 Distribution: unstable Urgency: low Maintainer: Turbo Fredriksson [EMAIL PROTECTED] Changed-By: Turbo Fredriksson [EMAIL PROTECTED] Description: roxen-fonts-iso8859-1 - Extra fonts for roxen Closes: 269696 Changes: roxen-fonts-iso8859-1 (0-7) unstable; urgency=low . * Don't depend on 'roxen' (have been removed). Instead depend on either 'roxen2', 'roxen3' or 'caudium'. Closes: #269696 Files: 1a37e0bca1664389e7d36d087b75cbbb 641 web optional roxen-fonts-iso8859-1_0-7.dsc e6913c56a27129f54e0700d24a76dd60 3001 web optional roxen-fonts-iso8859-1_0-7.diff.gz 91d87a3447fe252eb5c43e1f357c0ce9 3672544 web optional roxen-fonts-iso8859-1_0-7_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFBgKJnmlWzPKccHgARAjJjAJ9JaB0YZHRQGS9PdupFgXx3NptCZwCePsBj mykQl30hqZLSYP7MeGnWmbg= =14Qk -END PGP SIGNATURE- Accepted: roxen-fonts-iso8859-1_0-7.diff.gz to pool/main/r/roxen-fonts-iso8859-1/roxen-fonts-iso8859-1_0-7.diff.gz roxen-fonts-iso8859-1_0-7.dsc to pool/main/r/roxen-fonts-iso8859-1/roxen-fonts-iso8859-1_0-7.dsc roxen-fonts-iso8859-1_0-7_all.deb to pool/main/r/roxen-fonts-iso8859-1/roxen-fonts-iso8859-1_0-7_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted roxen-fonts-iso8859-2 0-7 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 28 Oct 2004 09:41:42 +0200 Source: roxen-fonts-iso8859-2 Binary: roxen-fonts-iso8859-2 Architecture: source all Version: 0-7 Distribution: unstable Urgency: low Maintainer: Turbo Fredriksson [EMAIL PROTECTED] Changed-By: Turbo Fredriksson [EMAIL PROTECTED] Description: roxen-fonts-iso8859-2 - Extra fonts for roxen Closes: 269697 Changes: roxen-fonts-iso8859-2 (0-7) unstable; urgency=low . * Don't depend on 'roxen' (have been removed). Instead depend on either 'roxen2', 'roxen3' or 'caudium'. Closes: #269697 Files: 39a49323f899b96bbafbb362d93cb470 640 web optional roxen-fonts-iso8859-2_0-7.dsc 4e09297ab7abd8a35d500f2f9087ed85 3064 web optional roxen-fonts-iso8859-2_0-7.diff.gz 694dfc937e5a1bd01c559bfabfeb937f 821348 web optional roxen-fonts-iso8859-2_0-7_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFBgKN4mlWzPKccHgARAm3mAJ9qpY8uC1jmBBcQaZFK3R0n7kJJ7ACfZKHs 0n0obnvvW/wWNl/hrB2mOiU= =e3Lt -END PGP SIGNATURE- Accepted: roxen-fonts-iso8859-2_0-7.diff.gz to pool/main/r/roxen-fonts-iso8859-2/roxen-fonts-iso8859-2_0-7.diff.gz roxen-fonts-iso8859-2_0-7.dsc to pool/main/r/roxen-fonts-iso8859-2/roxen-fonts-iso8859-2_0-7.dsc roxen-fonts-iso8859-2_0-7_all.deb to pool/main/r/roxen-fonts-iso8859-2/roxen-fonts-iso8859-2_0-7_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libroxen-disclaimer 1.0-9 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 28 Oct 2004 09:57:55 +0200 Source: libroxen-disclaimer Binary: libroxen-disclaimer Architecture: source all Version: 1.0-9 Distribution: unstable Urgency: low Maintainer: Turbo Fredriksson [EMAIL PROTECTED] Changed-By: Turbo Fredriksson [EMAIL PROTECTED] Description: libroxen-disclaimer - Disclaimer module for the Roxen Challenger web server Closes: 209597 Changes: libroxen-disclaimer (1.0-9) unstable; urgency=low . * Improve description. Closes: #209597 * Remove dependency on 'roxen'. Files: d7ea0d7e34bd7a89c9a8d90dfa2ffbc5 636 web optional libroxen-disclaimer_1.0-9.dsc 7d3a8f503966bc2c34ea1798cf882686 1784 web optional libroxen-disclaimer_1.0-9.diff.gz 2bb5fa215c66d103b65fbd88714605ac 4078 web optional libroxen-disclaimer_1.0-9_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFBgKddmlWzPKccHgARAgKxAJ9HV34ziiikfeohdJuYPqMtRQRfpwCfWVxC wwOcF/Fn5ZPpOQ182Wu5Qo8= =Nhg0 -END PGP SIGNATURE- Accepted: libroxen-disclaimer_1.0-9.diff.gz to pool/main/libr/libroxen-disclaimer/libroxen-disclaimer_1.0-9.diff.gz libroxen-disclaimer_1.0-9.dsc to pool/main/libr/libroxen-disclaimer/libroxen-disclaimer_1.0-9.dsc libroxen-disclaimer_1.0-9_all.deb to pool/main/libr/libroxen-disclaimer/libroxen-disclaimer_1.0-9_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted python-libgmail 0.0.8-3 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 27 Oct 2004 20:30:03 +0200 Source: python-libgmail Binary: python-libgmail Architecture: source all Version: 0.0.8-3 Distribution: unstable Urgency: low Maintainer: martin f. krafft [EMAIL PROTECTED] Changed-By: martin f. krafft [EMAIL PROTECTED] Description: python-libgmail - Python bindings to access Gmail accounts Changes: python-libgmail (0.0.8-3) unstable; urgency=low . * Added threadinfo patch by Pasi Savolainen [EMAIL PROTECTED]. See README.Debian for details. The patch has been submitted to upstream, but has not yet been acknowledged. Files: 862424e8fb73c5fbb7c80b771c9c1380 638 python extra python-libgmail_0.0.8-3.dsc 523a3148168006552180f95d745ee7ca 3764 python extra python-libgmail_0.0.8-3.diff.gz 03545969f79a8a6d315e8234e2104199 18756 python extra python-libgmail_0.0.8-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iEYEARECAAYFAkF/62AACgkQIgvIgzMMSnWvagCeM5KPYXtlVeyhlJFTXIselS5m oJAAoOuu7BNdy24XlrsOKQiqs8v72H9k =j/yD -END PGP SIGNATURE- Accepted: python-libgmail_0.0.8-3.diff.gz to pool/main/p/python-libgmail/python-libgmail_0.0.8-3.diff.gz python-libgmail_0.0.8-3.dsc to pool/main/p/python-libgmail/python-libgmail_0.0.8-3.dsc python-libgmail_0.0.8-3_all.deb to pool/main/p/python-libgmail/python-libgmail_0.0.8-3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted radiusclient 0.3.2-7 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 28 Oct 2004 10:35:55 +0200 Source: radiusclient Binary: libradius1-dev libradius1 radiusclient1 Architecture: source i386 Version: 0.3.2-7 Distribution: unstable Urgency: low Maintainer: Turbo Fredriksson [EMAIL PROTECTED] Changed-By: Turbo Fredriksson [EMAIL PROTECTED] Description: libradius1 - /bin/login replacement with RADIUS. Shared lib to used by program libradius1-dev - /bin/login replacement with RADIUS. Header file and link lib. radiusclient1 - /bin/login replacement which uses the RADIUS protocol for authent Closes: 215916 239165 Changes: radiusclient (0.3.2-7) unstable; urgency=low . * Check to see if the configuration value isn't null in addition to the option != NULL. Patch by Craig Small. Closes: #215916 * Allow rc_conf_str() to be called with a constant. Patch by Russell Coker. Closes: #239165 Files: 9bb8f85eb61454f41bd8bd2b359e7172 655 admin extra radiusclient_0.3.2-7.dsc 9e92a1a82f2c28c47059194ab64dc21e 42355 admin extra radiusclient_0.3.2-7.diff.gz a4ffbbc27da13ecde8312e7cdd63e9ab 32848 admin extra radiusclient1_0.3.2-7_i386.deb 68ef6eedbf958c25b28cf3aa40d88a71 28482 devel extra libradius1-dev_0.3.2-7_i386.deb 037ba9102bdfe120bff8a84cd6174fd5 31382 libs extra libradius1_0.3.2-7_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFBgLCvmlWzPKccHgARAi1gAJ9vlU25UhcVgK1euSnWf7KeItHsIgCfSWQL jmiF1KEQstQXbj5UIaA1+ag= =8HzL -END PGP SIGNATURE- Accepted: libradius1-dev_0.3.2-7_i386.deb to pool/main/r/radiusclient/libradius1-dev_0.3.2-7_i386.deb libradius1_0.3.2-7_i386.deb to pool/main/r/radiusclient/libradius1_0.3.2-7_i386.deb radiusclient1_0.3.2-7_i386.deb to pool/main/r/radiusclient/radiusclient1_0.3.2-7_i386.deb radiusclient_0.3.2-7.diff.gz to pool/main/r/radiusclient/radiusclient_0.3.2-7.diff.gz radiusclient_0.3.2-7.dsc to pool/main/r/radiusclient/radiusclient_0.3.2-7.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted nagat 1.0a2-4 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 28 Oct 2004 11:17:25 +0200 Source: nagat Binary: nagat Architecture: source all Version: 1.0a2-4 Distribution: unstable Urgency: low Maintainer: Turbo Fredriksson [EMAIL PROTECTED] Changed-By: Turbo Fredriksson [EMAIL PROTECTED] Description: nagat - Nagios Administration Tool Closes: 257024 Changes: nagat (1.0a2-4) unstable; urgency=low . * Include missing nagat.css. Closes: #257024 Files: 1902945266a159665f30a774ea186884 598 web extra nagat_1.0a2-4.dsc a2a1613ef3afb85eed72e96c2ada0041 3788 web extra nagat_1.0a2-4.diff.gz 98d0714365e0416ecbbbfd31cb61c778 30208 web extra nagat_1.0a2-4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFBgLl6mlWzPKccHgARAvw8AJ4jpbZh/tM7lGSgIDtlCAefV3c5CACfYC+w geIVPzF+7i+ykWSOr6X5W/w= =8n4U -END PGP SIGNATURE- Accepted: nagat_1.0a2-4.diff.gz to pool/main/n/nagat/nagat_1.0a2-4.diff.gz nagat_1.0a2-4.dsc to pool/main/n/nagat/nagat_1.0a2-4.dsc nagat_1.0a2-4_all.deb to pool/main/n/nagat/nagat_1.0a2-4_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libdbix-searchbuilder-perl 1.12-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Oct 2004 12:07:04 +0100 Source: libdbix-searchbuilder-perl Binary: libdbix-searchbuilder-perl Architecture: source all Version: 1.12-1 Distribution: unstable Urgency: low Maintainer: Stephen Quinney [EMAIL PROTECTED] Changed-By: Stephen Quinney [EMAIL PROTECTED] Description: libdbix-searchbuilder-perl - Perl extension for easy SQL SELECT statement generation Changes: libdbix-searchbuilder-perl (1.12-1) unstable; urgency=low . * New upstream release * debian/watch - Added file. * debian/rules: * Use dh_installman instead of dh_installmanpages * Commented out a few unused dh_* commands * Also do 'make test' * Only attempt to 'make distclean' if there is a Makefile Files: b1ea5ae5109c4d97d392b5c4b09159ce 823 perl optional libdbix-searchbuilder-perl_1.12-1.dsc 9d8206147d8f4123bdf41bc44884fd33 40497 perl optional libdbix-searchbuilder-perl_1.12.orig.tar.gz 1e518170a20c1914c385428dca585108 2831 perl optional libdbix-searchbuilder-perl_1.12-1.diff.gz d7b126ac14fdb459475655ab34c849e4 71866 perl optional libdbix-searchbuilder-perl_1.12-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBgLa/ITGblEwaW+URAqsBAKCR6ns93otbEs/yQO8NG6ZQVgrLOACdFfS0 8E6+N6V8EEnE+Q4dvkqIdkM= =xoFB -END PGP SIGNATURE- Accepted: libdbix-searchbuilder-perl_1.12-1.diff.gz to pool/main/libd/libdbix-searchbuilder-perl/libdbix-searchbuilder-perl_1.12-1.diff.gz libdbix-searchbuilder-perl_1.12-1.dsc to pool/main/libd/libdbix-searchbuilder-perl/libdbix-searchbuilder-perl_1.12-1.dsc libdbix-searchbuilder-perl_1.12-1_all.deb to pool/main/libd/libdbix-searchbuilder-perl/libdbix-searchbuilder-perl_1.12-1_all.deb libdbix-searchbuilder-perl_1.12.orig.tar.gz to pool/main/libd/libdbix-searchbuilder-perl/libdbix-searchbuilder-perl_1.12.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted php4-idn 1.0-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 28 Oct 2004 11:33:12 +0200 Source: php4-idn Binary: php4-idn Architecture: source i386 Version: 1.0-3 Distribution: unstable Urgency: low Maintainer: Turbo Fredriksson [EMAIL PROTECTED] Changed-By: Turbo Fredriksson [EMAIL PROTECTED] Description: php4-idn - PHP api for the IDNA library Closes: 274593 Changes: php4-idn (1.0-3) unstable; urgency=low . * Add 'cli' to the list of php4 'modules' to add/remove the IDN extension to. Closes: #274593 Files: b625e9eb871519257ad55fbd26271efb 565 web optional php4-idn_1.0-3.dsc 758810d69f8d04c3f47f694872cd8fff 25891 web optional php4-idn_1.0-3.tar.gz ae5f1056911f972da1b7671cc306cffe 9740 web optional php4-idn_1.0-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBgL1QmlWzPKccHgARAjEYAJ4s2w1VhM2OAawXDoRZlFLXahmKgACfbJqU /m3CYJUwlv7Ay8/kojl81AQ= =auIQ -END PGP SIGNATURE- Accepted: php4-idn_1.0-3.dsc to pool/main/p/php4-idn/php4-idn_1.0-3.dsc php4-idn_1.0-3.tar.gz to pool/main/p/php4-idn/php4-idn_1.0-3.tar.gz php4-idn_1.0-3_i386.deb to pool/main/p/php4-idn/php4-idn_1.0-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted brltty 3.4.1-4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 28 Oct 2004 11:21:03 +0200 Source: brltty Binary: brltty-udeb libbrlapi-dev libbrlapi brltty Architecture: source i386 Version: 3.4.1-4 Distribution: unstable Urgency: low Maintainer: Mario Lang [EMAIL PROTECTED] Changed-By: Mario Lang [EMAIL PROTECTED] Description: brltty - Access software for a blind person using a soft braille terminal brltty-udeb - Access software for a blind person using a soft braille terminal (udeb) libbrlapi - braille display access via BRLTTY - shared library libbrlapi-dev - Library for communication with BRLTTY - static libs and headers Changes: brltty (3.4.1-4) unstable; urgency=low . * Fix stupid typo in prebaseconfig script ($file not $flie). Files: 4b7ee62d559b7f8475dc944d676d4d2e 634 admin extra brltty_3.4.1-4.dsc d3fb7608a8117c2375613ca8b8f48c8e 29837 admin extra brltty_3.4.1-4.diff.gz 92972d35aec11be6f7937f92f0534dd4 543320 admin extra brltty_3.4.1-4_i386.deb 687ebd015983e44e94b510520beb1e52 31486 libs extra libbrlapi_3.4.1-4_i386.deb c66574770bb07d6658e1734e227a1bb0 126780 libdevel extra libbrlapi-dev_3.4.1-4_i386.deb 0f2cb9723d411609fbeaf43aa9864edb 89116 debian-installer extra brltty-udeb_3.4.1-4_i386.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBgLso3/wCKmsRPkQRAmgCAJ9Lwy+mLm2Vmsl/T3rafHxcAJmQGQCeJJmn hhspFbBuLRleuhiCvXquC+I= =bgZR -END PGP SIGNATURE- Accepted: brltty-udeb_3.4.1-4_i386.udeb to pool/main/b/brltty/brltty-udeb_3.4.1-4_i386.udeb brltty_3.4.1-4.diff.gz to pool/main/b/brltty/brltty_3.4.1-4.diff.gz brltty_3.4.1-4.dsc to pool/main/b/brltty/brltty_3.4.1-4.dsc brltty_3.4.1-4_i386.deb to pool/main/b/brltty/brltty_3.4.1-4_i386.deb libbrlapi-dev_3.4.1-4_i386.deb to pool/main/b/brltty/libbrlapi-dev_3.4.1-4_i386.deb libbrlapi_3.4.1-4_i386.deb to pool/main/b/brltty/libbrlapi_3.4.1-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kinoplus 0.3.2-5 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 28 Oct 2004 13:30:36 +0200 Source: kinoplus Binary: kinoplus Architecture: source i386 Version: 0.3.2-5 Distribution: unstable Urgency: low Maintainer: Roland Mas [EMAIL PROTECTED] Changed-By: Roland Mas [EMAIL PROTECTED] Description: kinoplus - effect plug-ins for kino Changes: kinoplus (0.3.2-5) unstable; urgency=low . * New maintainer, no changes. Thanks, Jens! Files: 2cf871e7a20b7922b48a437245d3e612 619 graphics extra kinoplus_0.3.2-5.dsc 64077a6e1b2c03ea0baa5fde8ddefd7b 3083 graphics extra kinoplus_0.3.2-5.diff.gz df56eb4e3520e4eff542d973814ed79f 85970 graphics extra kinoplus_0.3.2-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBgNlnDqdWtRRIQ/URAkImAJ0egp9K55GqLFmu0zfPgdVBWc+bwQCdGmxe Tr8Oh517bLDTSBbOZss52QI= =+LRC -END PGP SIGNATURE- Accepted: kinoplus_0.3.2-5.diff.gz to pool/main/k/kinoplus/kinoplus_0.3.2-5.diff.gz kinoplus_0.3.2-5.dsc to pool/main/k/kinoplus/kinoplus_0.3.2-5.dsc kinoplus_0.3.2-5_i386.deb to pool/main/k/kinoplus/kinoplus_0.3.2-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dvtitler 0.1.1-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 28 Oct 2004 13:26:14 +0200 Source: dvtitler Binary: kino-dvtitler Architecture: source i386 Version: 0.1.1-2 Distribution: unstable Urgency: low Maintainer: Roland Mas [EMAIL PROTECTED] Changed-By: Roland Mas [EMAIL PROTECTED] Description: kino-dvtitler - title generator for use with kino Changes: dvtitler (0.1.1-2) unstable; urgency=low . * New maintainer, no changes. Thanks, Jens! Files: 5000a5083f4dcad6f27ff0ab89a1252c 612 graphics optional dvtitler_0.1.1-2.dsc 4e391cdf33094fdfbc2d40e7b89e534d 1962 graphics optional dvtitler_0.1.1-2.diff.gz 226c13e9477046a018f3101ece2a76a6 19960 graphics optional kino-dvtitler_0.1.1-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBgNk3DqdWtRRIQ/URAthPAKCerR4wZ73DcjNi3YVqQOtUdDCZRQCfUL+0 rmVRZl6qE2Y5AmzJJezuMWA= =z7Rn -END PGP SIGNATURE- Accepted: dvtitler_0.1.1-2.diff.gz to pool/main/d/dvtitler/dvtitler_0.1.1-2.diff.gz dvtitler_0.1.1-2.dsc to pool/main/d/dvtitler/dvtitler_0.1.1-2.dsc kino-dvtitler_0.1.1-2_i386.deb to pool/main/d/dvtitler/kino-dvtitler_0.1.1-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
