Bug#295728: ITP: peercast -- P2P audio and video streaming server
Package: wnpp Severity: wishlist Owner: Romain Beauxis <[EMAIL PROTECTED]> * Package name: peercast Version : 0.1211+svn Upstream Author : PeerCast Team <[EMAIL PROTECTED]> * URL : http://www.peercast.org * License : GPL Description : P2P audio and video streaming server PeerCast is a fresh new P2P streaming server It can stream music and video from a broad variety of formats. . Many audio players can listen to peercast streams, as it's been built to remain compatible with Nullsoft Shoutcast For more info, visit http://www.peercast.org. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-mrv Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt PARALLELISM
Le Mardi 6 Décembre 2005 02:50, Joe Smith a écrit : > Now it is useless for users where the bottleneck is on their end. Well, it can also be usefull in case of a broken mirror can't it? Romain -- Not even the dog That piss against the wall of Babylon, Shall escape his judgement
Re: The klik project and Debian
Le Jeudi 19 Janvier 2006 08:48, Peter Samuelson a écrit : > For those following along at home, it seems klik is some sort of > gateway to install Debian packages on various non-Debian distributions. > I imagine it's an ftp frontend to alien. Well.. In fact, it is a scripted version of apt that can install package in a temp directory. The aim of it is to allow normal user to install app without write acess to /usr etc.. One application for it is to test a beta release without the need to have it definitly installed. My own feeling about it is that the author is not very honnest with the debian packaging work. No where in his web page is written that in fact klik is a refactoring of actual debian packages. Instead, it is at least implcitly told that it's all the author's work... I feel it as being not honnest so I don't see why I should really care.. > Do they solve any of these problems better than Debian does? Would > Debian users derive any value from klik? How? Hum... It allows non permanent installation which can be seen as good thing, but, even if I'm not deeply aware of it, I can imagine that it needs to install libraries and other things, and has the risk of puting a real mess in your system... Furthermore, the instalation script is not documented, and I had to go through the source to know what it was doing.. > If not, I fail to see why Debian should care. We've got enough to > worry about just making packages suitable for Debian - why go out of > our way to help people who refuse to use Debian? And to people who refuse to mention their use of debian's work... Romain -- There is a land far, far away Where there's no night, there's only day Look into the book of life and you will see That there's a land far, far away
Re: The klik project and Debian
Le Jeudi 19 Janvier 2006 09:57, Romain Beauxis a écrit : > No where in his web page is written that in fact klik is a refactoring of > actual debian packages. Ok I was wrong it is written in small at the end: "Thanks to debian for the software compilation and packaging." Romain -- Satan is an evilous man, But him can't chocks it on I-man So when I check him my lassing hand And if him slip, I gaan with him hand
Bug#351184: ITP: php-getid3 -- PHP4 script that extracts useful information from MP3s & other multimedia file formats
Package: wnpp Severity: wishlist Owner: Romain Beauxis <[EMAIL PROTECTED]> * Package name: php-getid3 Version : 1.7.5 Upstream Author : James Heinrich <[EMAIL PROTECTED]> * URL : http://www.getid3.org/ * License : GPL Description : PHP4 script that extracts useful information from MP3s & other multimedia file formats getid3 is a set of usefull php scripts for reading/writing various type of informations from multimédia files. It can handle id3v1, id3v2, ogg, and many more formats. See webpage for a complete list. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-powerpc Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Re: helix player package for debian?
Le Mercredi 8 Février 2006 22:14, Daniel Baumann a écrit : > I'm working on the rest of the helix-tools and real-player too. I'm in > contact with Real to fix the helix-player license and to get an > acceptable license for real-player for its inclusion into non-free. > Unfortunately, such things take a very, very long time.. PLEASE, try to get more arch, like powerpc too, I know there is a beta for powerpc somewhere... Romain -- Why do they fight against the poor youth of today? 'Cause without these youths, they would be gone - All gone astray
Bug#355578: ITP: geekast -- GNOME interface to peercast
Package: wnpp Severity: wishlist Owner: Romain Beauxis <[EMAIL PROTECTED]> * Package name: geekast Version : 0.1 Upstream Author : Frédéric Logier <[EMAIL PROTECTED]> * URL : http://gna.org/projects/geekast/ * License : GPL Description : GNOME interface to peercast Geekast is an alternative to the Web interface. Currenly, it can perform audio (Ogg and MP3) or video (OGM) streaming through an external player like totem, or an internal player based on the Gstreamer multimedia framework. In the future, it should be possible to encode a Webcam or any input stream over the peercast network. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-powerpc Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Bug#305843: ITP: kshutdown -- An advanced shut down utility for Linux/KDE
Package: wnpp Severity: wishlist Owner: Romain Beauxis <[EMAIL PROTECTED]> * Package name: kshutdown Version : 0.6.0 Upstream Author : Konrad Twardowski <[EMAIL PROTECTED]> * URL : http://kshutdown.sourceforge.net/ * License : GPL Description : An advanced shut down utility for Linux/KDE KShutDown is an advanced shutdown utility for KDE that trigger a clean KDE shutdown timer and many other cool features. The package is ready, lintian and linda clean, and compiles with pbuilder under sarge. You can find the sources at this place: deb-src http://www.cti.ecp.fr/~beauxir5/debian/ source/ -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.11.7-igrec Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308364: ITP: waste -- Software product and protocol that enables secure distributed communication for small trusted groups of users.
Package: wnpp Severity: wishlist Owner: Romain Beauxis <[EMAIL PROTECTED]> * Package name: waste Version : 1.5b3 Upstream Author : Waste Team <[EMAIL PROTECTED]> * URL : http://waste.sourceforge.net/ * License : GPL Description : Software product and protocol that enables secure distributed communication for small trusted groups of users. WASTE is designed to enable small companies and small teams within larger companies to easily communicate and collaborate in a secure and efficient fashion, independent of physical network topology. . The package would be in two parts: server - with small dependances and client - wxWidgets dependant. This seems an instresting package as it is trendy those days.. But maybe it can be discussed, I'm waiting for comment. I'm begining the package now.. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.11.8-1stday Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#308364: ITP: waste -- Software product and protocol that enables secure distributed communication for small trusted groups of users.
Le Vendredi 13 Mai 2005 12:18, vous avez écrit : > I took a quick look at the code and found it may require DFSG actions. > > http://cvs.sourceforge.net/viewcvs.py/waste/waste/license.cpp?rev=1.1&view= >auto that arrays are either the GPL license itself, backdoor code (who > knows, I didn't try to decode it) or some hashes of something. > > To me it seems it violates the GPL, the source code is not in a > changeable form. > > It is also a good place to hide backdoors when crackers get access the > the source code repository... Yep, when I see that: WASTE - license.cpp Copyright (C) 2003 Nullsoft, Inc. Copyright (C) 2004 WASTE Development Team Then that: //ADDED Md5Chap - THIS PART IS GPL LICENSE!!! TOUCH AND DIE! Followed by a full binary only array, I feel it like you: it might be a good place for a backdoor, given that TOUCH AND DIE seems very strange refering to GPL licence... I'm shouting an email to the public mailing list, CCed the bug adress. Romain -- If you are the big tree, We are the small axe, Ready to cut you down, Sharpen to cut you down pgppLNhao5MLa.pgp Description: PGP signature
Questions about waste licence and code.
Hi all! I'm on the way of making a debian package for Waste, and I would have the folowing two questions about your software: Does the licence really reflect GPL? This arise because of this: http://cvs.sourceforge.net/viewcvs.py/waste/waste/license.cpp?rev=1.1&view=auto "WASTE - license.cpp Copyright (C) 2003 Nullsoft, Inc. Copyright (C) 2004 WASTE Development Team" -> What does Nullsoft have to do with Waste? And also this: "//ADDED Md5Chap - THIS PART IS GPL LICENSE!!! TOUCH AND DIE!" Followed by a full binary array. If you will to produce your code upon the GPL licence, according to claim number 3 - http://www.gnu.org/copyleft/gpl.html -, "3 - You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)" So, this is clear that you have to publish the full source in order to follow the GPL claims. Furthermore, there comes the second question: Is the soft safe? Because those binary arrays are not human readable, I cannot assure that it is not a backdoor or else. Given that, I cannot intent to include it into the debian distribution. I'm looking forward for your answers, Romain Beauxis -- If you are the big tree, We are the small axe, Ready to cut you down, Sharpen to cut you down pgpWVhwlGWmb9.pgp Description: PGP signature
Re: Questions about waste licence and code.
> If it where used I would suggest replacing it with > #include "/usr/share/common-licenses/GPL" (or a file inside the source) > and patch to make it use plain text instead of crypted data. Yep in fact it was used as it said, by using the -L switch for both wastesrv and the admin command wastesrv_admin. I thought about doing so, but it seemed better to simply remove the -L switch for the following means: -- The licence is already shipped within the package, and simply for _debian package users_ it is obvious to check it. -- This way it is harmless with regards to the original code source: my patch is only putting parts of the code in comment. BTW the different patches are at debian/patches so you can have a look on it and tell me what you think of it.. Then, still it is unclear if the licence is really GPL or not.. I've not heard from the original author, nor managed to find a main copyright holder or an emai.. only I got the user ml.. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#294397: I am willing to make this package
Package: wnpp Followup-For: Bug #294397 Owner: Romain Beauxis <[EMAIL PROTECTED]> Hi! I had already tried to package it few mounths ago, for my first try... So that was not that clean.. ;) Now I'm restarting from scratch, and I will do the following packages: -- mediabox404-web: package with all the PHP interface files -- mediabox404-streamer: package with the streaming client -- mediabox404-daemon: package with the scheduler daemon. The main issue remaining would be to compile the streamer WITHOUT the mp3 encoding support in order to have it compliant with debian policy. Romain -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11.8-1stday Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311348: ITP: ptunnel -- Send TCP traffic over ICMP
Package: wnpp Severity: wishlist Owner: Romain Beauxis <[EMAIL PROTECTED]> * Package name: ptunnel Version : 0.61 Upstream Author : Daniel Stoedle <[EMAIL PROTECTED]> * URL : http://www.cs.uit.no/~daniels/PingTunnel/ * License : BSD like Description : Send TCP traffic over ICMP Ptunnel is an application that allows you to reliably tunnel TCP connections to a remote host using ICMP echo request and reply packets, commonly known as ping requests and replies. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11.8-romidaboss Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#396689: ITP: mediawiki-extensions -- set of extensions for MediaWiki
Package: wnpp Severity: wishlist Owner: Romain Beauxis <[EMAIL PROTECTED]> * Package name: mediawiki-extensions Version : 0.1 Upstream Author : collection of extensions from the net * URL : http://www.example.org/ * License : GPL, public domain and "Anyone is allowed to use this code for any purpose." Programming Lang: PHP Description : set of extensions for MediaWiki This package provides a set of useful extensions for MediaWiki: * Cite -- add tags for citation purpose * GeSHi-- add tags for syntax highlighting * Inputbox -- add predefined HTML forms to wiki pages * NewestPages -- show the last pages added to the wiki * Poem -- add tags for poems * SpecialLastUserLogin -- special page to see a user last logins . These extensions are only set together for Debian packages of MediaWiki (>= 1.7). -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-amd64 Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#396868: ITP: jbidwatcher -- bidding, sniping and monitoring software for eBay
Package: wnpp Severity: wishlist Owner: Romain Beauxis <[EMAIL PROTECTED]> * Package name: jbidwatcher Version : 1.0 Upstream Author : Morgan Schweers, CyberFOX <[EMAIL PROTECTED]> * URL : http://www.jbidwatcher.com/ * License : LGPL Description : bidding, sniping and monitoring software for eBay A Java-based application allowing you to monitor auctions you're not part of, submit bids, snipe (bid at the last moment), and otherwise track your auction-site experience. It includes adult-auction management, MANY currencies (pound, dollar (US, Canada, Australian, and New Taiwanese) and euro, presently), drag-and-drop of auction URLs, an original, unique and powerful 'multisniping' feature, and a relatively nice UI. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.16-2-686 Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400588: ITP: ov519 -- ov519 webcam driver
Package: wnpp Severity: wishlist Owner: Romain Beauxis <[EMAIL PROTECTED]> * Package name: ov519 Version : 1.0.0 Upstream Author : Romain Beauxis <[EMAIL PROTECTED]> * URL : http://www.rastageeks.org/ov51x-jpeg * License : GPL Description : ov519 webcam driver This driver works with webcams that use an ov519 chip. This includes the Eye Toy, the Hercules Webcam Classic, some SpaceCam 320 and many others. I have ready to be checked packages at this point: http://www.rastageeks.org/downloads/debian/ I don't know if asking for an upload now is not already to late for next stable, but this driver can be usefull for some users. Romain -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.16-2-686 Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping GStreamer 0.8 for etch
On Thursday 07 December 2006 11:06, Sebastian Dröge wrote: > > The number of packages which are still using the 0.8 series of > > GStreamer has dropped significantly. Remain as libgstreamer0.8-0 > > rdeps: Seems that you do not include some other packages not directly depending on this lib. For instance mine is built with ruby's bindings... If you were to choose to remove it before etch, you better prospect for dependances on gstreamer0.8-foo packages, and as I fear, fill bugs quiclky since they may be more than this list.. Anyway, I'm gonne prepare a new release of my package using 0.10. Romain
Re: SUMMARY: Re: Dropping GStreamer 0.8 for etch
On Thursday 07 December 2006 12:03, Loïc Minier wrote: > Initially missing from the list: geekast-binary. The maintainer > commented that he is now working on porting this package to GStreamer > 0.10. Ok, it seems that the issue is more complicated than that. Indeed, the while ruby-gnome2 bindings pack is built upon gstreamer2, see: http://packages.debian.org/unstable/libs/ruby-gnome2 and http://packages.debian.org/unstable/libs/libgstreamer0.8-ruby Now the big question now is: is it only a matter of recompiling against or is there some restriction for using gstreamer0.10 for ruby-gnome2. I CCed the maintainer to have his point on this. Also, again, it seems important to indicate more precisely which packages depends on gstreamer2 since libgstreamer0.8-ruby was not on your list whereas it depends on libgstreamer0.8-0 (>= 0.8.11) When ruby-gnome2 uses 0.10 changing my package will only be a matter of changing the dependencies I hope. Romain
Re: SUMMARY: Re: Dropping GStreamer 0.8 for etch
Le jeudi 7 décembre 2006 16:33, Sjoerd Simons a écrit : > ruby-gnome2 only contains bindings for gstreamer 0.8. To use gstreamer 0.10 > you need the libgstreamer0.10-ruby1.8 package. Which works perfectly with > the rest of ruby-gnome2 :) Thanks forthis point, I did not knew it ! > > When ruby-gnome2 uses 0.10 changing my package will only be a matter of > > changing the dependencies I hope. > > Note that your application will need some porting to gstreamer 0.10. At > least the current source in debian doesn't seem to support gstreamer 0.10 Hum.. Is the API different ? Romain
Bug#403558: ITP: lastfmproxy -- proxy server for the last.fm radio streams
Package: wnpp Severity: wishlist Owner: Romain Beauxis <[EMAIL PROTECTED]> * Package name: lastfmproxy Version : 1.1 Upstream Author : Vidar Madsen <[EMAIL PROTECTED]> * URL : http://vidar.gimp.org/lastfmproxy/ * License : GPL Programming Lang: Python Description : proxy server for the last.fm radio streams LastFMProxy is a proxy server for the last.fm radio streams. It allows you to use your regular old audio player to listen to the last.fm streams. It does this by acting as a player itself, connecting to the server on your behalf, but instead of playing the stream, it simply relays it to whichever other application connecting to it. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-amd64 Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Easy way to incorporate Ubuntu improvements back into Debian?
On Friday 05 May 2006 11:24, Daniel Stone wrote: > > It seems to me that Ubuntu is getting alot more out of their friendship > > with Debian, than Debian gets out of Ubuntu. Anyone have comments on > > this? Please correct me if I'm wrong, and examples would be great. > > Does Debian get lots of benefits from Ubuntu (in the software) that I'm > > unaware of? > > ... GNOME, Xorg, et al. Hi all! I just wanted to ask if there is any plans to package Xgl in debian soon? I have tryed building current package found in ubuntu but it failed... Compiz was building ok BTW... Romain
Re: multiarch status update
Hi all! On Monday 15 May 2006 14:15, Olaf van der Spek wrote: > > this is a dream. This also need that the application is able to deal > > with the fact that it has configuration for the 32 and 64 bits version > > coexisting cleanly. > > True. Did I say that it would be trivial? > Or even a short-term solution? So why would you introduce a change that may triger a lot of new complications and incompatibilities? I have a multiarch on my amd64 system only because I want to use applications that I can't use or does not have the same functionalities with amd64 (mostly firefox, ooo and mplayer then...). But I'll be happy to have a full amd64 system if only they could provide the same with it. So, as for Pierre, a binary package per multiarch system seems obviously the solution, since a user needs only a given functionalities. Why would you see many binaries installed from the user point of view? Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On Tuesday 16 May 2006 17:53, Gabor Gombas wrote: > However, you can take this idea further: provided you have multiarched > binaries, you could create a small file system using FUSE that generates > such a wrapper on-the-fly based on the requested file name, and you > could mount this file system as /usr/bin. Voila. Hum, mounting FUSE file system at /usr/bin seems a bit weak to me. I love using FUSE as an additional file system, but using it as a core file system seems a bit exagerated for me. Few things that I see: -- FUSE goes throught userland <-> kernel <-> Userland so it: ** May be an overhead for all /usr/bin calls. ** May be a potential security leak, like using LD_PRELOAD for a given user and use a custom fuse library for this user, with *any* /usr/bin filesystem you like -- FUSE module is not loaded by default, and some server maintainer would like te reFUSE using it... :-) -- Furthermore, what to do during bootstrap of the root file system? Because this should also be needed for /bin, so again overhead, security and loading at en early stage is not a solution for me... Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
Hi! Le Dimanche 21 Mai 2006 19:34, Raphael Hertzog a écrit : > PS: Yeah I'm a bit pissed of that we only have people criticizing when we > do great things. I know I shouldn't, but I was really upset by your answer. I'm happy that people speak up and claim their fear with this licence, and no, I won't hide my personal reponsability behind the ftp masters' decision: my concern is not a fear for myself but a fear for the project. To all the questions and fears raised consciously and with arguments, you answer them to shut up and respect the others decisions, that is not the way I would work in this project as for sure. Romain -- mama say son, you've got to stay home today there's a hole in the roof you've got to make it waterproof
Re: Sun Java available from non-free
Hi! On Monday 22 May 2006 13:35, you wrote: > They won't sue us for distributing Java. If they do, all we have to do > is point the Judge to the press coverage of this change of license, and > to the fact that Debian was mentioned as one of the distributors asked > to please distribute Java. They won't have a case. > > Try as I might, and considering how lawyers and judges are human beings > and not automatons, I can't see any realistic scenario in which we could > be sued and lose a case in relation to this license. Do you? While I understand your argument about Sun asking for this, and even found it serious, please do not argue the judges are human being after all... Judges aply law, and that what they are meant for. If there is a law which could be used against the project, then the judge has to apply it, no matter how 'human' he is... Now come the strong point about your argument: appart from quoting from the press, do you have an offical request from Sun to please distribute Java in debian? If yes, then it is true that it would be very difficult to argue against the project in a court. But I fear that press cover is not enough, since it does not have an offical mean, and you might even find articles that would claim false things.. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#320278: ITP: dotclear -- simple and powerfull blog webapp
Package: wnpp Severity: wishlist Owner: Romain Beauxis <[EMAIL PROTECTED]> * Package name: dotclear Version : 1.2.1 Upstream Author : Olivier Meunier <[EMAIL PROTECTED]> * URL : http://www.dotclear.net/ * License : GPL Description : simple and powerfull blog webapp DotClear is a blog webapp designed for simplicity. You will be able to install and post you first message very easily . It is written in PHP and uses MySQL for its database. The package is ready and available here: deb http://www.cti.ecp.fr/~beauxir5/debian binary/ deb-src http://www.cti.ecp.fr/~beauxir5/debian source/ As it is a webapp, it may need some corrections, expecialy on how links are made between directories, and the dbconfig-common inclusion, but hey, it's a working here(tm) package, and I think is is really needed in debian. I've read things about the fact that is it not aimed a a multiuser application, and that it should not be packaged as any user on the box would need its own dotclear. This issue is really not important to me, as the user stuff is only reduced to a conf file and a database somewhere.. So, it should be easilly resolved using a proper - ~/public_html/blog for instance - directory, with only index.php - with a proper $app_path variable - and a config/ directory.. Romain -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.2-gcc-4.0 Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: i386-uclibc debian
Le Jeudi 29 Septembre 2005 01:20, Steve Langasek a écrit :
> Can libstdc++ be built against uclibc? You're going to have a hard time
> basing a Debian port on uclibc without it.
Hi all!
It may be a stupid question, but I'm wondering if it would be usefull to use
uclibc++[1] instead of libstdc++.
Or else, why this shouldn't...
Romain
[1]: http://cxx.uclibc.org/
--
while ( love & passion ) {
for( fight = 0 ; rights < freedom ; rights++ )
fight = standup( rights );
free( babylon );
}
pgpHzjeo7c9iO.pgp
Description: PGP signature
Re: i386-uclibc debian
Le Jeudi 29 Septembre 2005 19:41, vous avez écrit : > I saw this library today... I'm not so sure if it will solve the > question, as it's still alpha... Did anybody used it in a production > environment? Well, I knew the existence of this library from the openwrt[1] distribution. Maybe you can ask them how god it works. Romain [1]: http://www.openwrt.org -- They seh when you have nuff money You got a whole heap o' friend But when your money done dem just don't know you again When your dollars gone dem nah see you again And when your money done dem nah want see you again Money money money money is the root of all evil And you see it pgpQz3p9w4QFu.pgp Description: PGP signature
Bug#463500: ITP: ocaml-magic -- Ocaml interface to libmagic
Package: wnpp Severity: wishlist Owner: Romain Beauxis <[EMAIL PROTECTED]> * Package name: ocaml-magic Version : 0.6 Upstream Author : Christophe Troestler <[EMAIL PROTECTED]> * URL : http://sourceforge.net/projects/ocaml-magic/ * License : LGPL+Link exception Programming Lang: OCaml Description : Ocaml interface to libmagic libmabic can be used to classify files according to magic number tests. This package provides an OCaml interface to use this library in OCaml programs. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-rc7-mactel (SMP w/2 CPU cores; PREEMPT) Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Idea of Debian mascot
Le Monday 25 February 2008 15:58:16 nic, vous avez écrit : > hi together, > > I'm not quite sure how to properly use this debian-list (I should have > read before, I know...). > > I spontaneously thought of an ant: It works hard, it's tough, well, and > with a fat grin on its face. just a first idea: the 'debiant'. Just > playing with words. I tried some rough sketches, but didn't like them. Humm And why not a marmot ?? It's a nice beautifull little animal, and, according to WP, "Marmots typically live in burrows, and hibernate there through the winter. Most marmots are highly social, and use loud whistles to communicate with one another, especially when alarmed." And, the most important, it is sleeping half of the time ! :-P http://upload.wikimedia.org/wikipedia/commons/3/3b/Marmot-edit1.jpg Romain
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
Le Tuesday 26 February 2008 14:41:41 Nico Golde, vous avez écrit : > > Fine. I have other arguments: it would make it "yet another FOSS > > project with an animal mascot". > > I strongly agree, also because we already have a logo it > would be nice if the new fancy logo would be related to the > existing ones. I really like the genie in > http://www.openpuppets.com/fondos/8c.png :) Well, you still can put a logo on the animal's belly.. Now that I think about it, I think that a "care bear" with a debian logo on it's belly would even be better than a marmot :-D We could say that we all identifies to it, couldn't we ? :-P http://en.wikipedia.org/wiki/Care_Bears http://www.rastageeks.org/~toots/debian/bisounours-debian.jpg Romain
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
Le Friday 29 February 2008 11:16:04 Thijs Kinkhorst, vous avez écrit : > There are several costs associated with having yet another package doing > the same thing: > * For the project in general, it costs archive and Packages file space, > build time, QA efforts just to name a few; You're mixing different things.. Storage is one, but I don't think a light package is an issue here, QA is another. For the QA effort, I'd rather prefer yet another package that is well maintained, for which the maintainer cares about RC issues, security fixes etc.. to a massively popular package unmaintained, and I have example on this topic... > * Especially true for network facing services: the security team needs to > support every package in stable; Again, the maintainer has a role to play, and can often help seciruty fixes quite well.. > * For the administrator: having a choice between a few webservers is good, > having to choose between a dozen that are hardly different just troubles > their view. You can have too much choice. Do you really believe in such an argument ? Well, administrators are wise people. In particular with http servers, first most of them will install apache without thinking of anything else, and I don't think the remainers will cry a river because apt-cache search httpd returns too many results. But, yes, the description needs to be relevant. Now, for the fundamental, since it seems no one returned to it, I found the webpage of the project well done, the code is hosted in a git repo, maintenance seems to be done. So, unless legal issues, if the proposed maintainer has a package well done and is willing to maintain it, I don't see what we're discussing here. Romain
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
Le Saturday 01 March 2008 16:43:56 Ron Johnson, vous avez écrit : > > I wish we had some more of this sort of thinking in our own project and a > > little less of yours. Maybe then we'd have fewer bugs in the packages > > people actually care about and use. > > I say we drop every WM & DE except GNOME, because that will simplify > the distro, and lead to *much* fewer bugs!!! > > > Obviously, what I just wrote is nonsense, and should never happen. > Because FLOSS *is* about choice. > > However... it is perfectly reasonable for a distro to say, "We can > not be all things to all people, so some limits have to be set, and > some users/DDs will be disappointed." Sure. The fact is, I don't think we have bugs because we have too much choice, but because we don't have enough manpower. So, previous mail was pointing a real issue, "lack of manpower and (hence) too many bugs", but giving a false anwser, "less/limited choice". Basically, a package has bugs because the maintainer or upstream is not reponsive/available/..., not because there are too much *choice*. It is also pointed out that there are central places, like security fixes, where having too many packages leads to too much work. Sure, but again, it's not related to choice, but to the overall size of the distribution. Here again, the solution is not "less choice", but "more people". I think too that we should care about how many different similar software we include, but it's important to point out the real issues. Now, if you really want to see how choice is already one aspect of the system, just search through apt-get for "yet another" you'll be suprised to see how many packages are presented initially as "yet another foo-bar"... Romain
Re: Bug#468183: ITP: monkey -- small webserver based on the?HTTP/1.1 protocol
Le Saturday 01 March 2008 17:37:40 David Nusinow, vous avez écrit : > > Basically, a package has bugs because the maintainer or upstream is not > > reponsive/available/..., not because there are too much *choice*. > > Um. No. We have lots of people. We also have lots of software. If we lose > some of the redundant software and keep the same number of people then we > have more people to work on the software that requires attention. It's > pretty simple. So, we basically *agree* that a lot of software makes more bugs. Whoa, that's *a* point. Now, unless we decide to, Debian is not meant to refuse any *new* package. Which means that the distribution will always grow, even without redundant software. All in all, yes sure, reducing choice will give a breath and reduce load, but clearly, it's only postponing the issue, and giving false answers to real issues. > This is, not coincidentally, one of the many reasons why so many people > flock to Ubuntu rather than Debian. Are you meaning to disqualify yourself with this kinds of trolls ? Ubuntu clearly concentrate on a core set of packages, and pulls out of debian the others. So I'd be delighted to see how ubuntu would handle this diversity, and have so many users without *our* diversity. Romain
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
Le Saturday 01 March 2008 17:44:01 Thijs Kinkhorst, vous avez écrit : > On Saturday 1 March 2008 17:20, Romain Beauxis wrote: > > It is also pointed out that there are central places, like security > > fixes, where having too many packages leads to too much work. Sure, but > > again, it's not related to choice, but to the overall size of the > > distribution. Here again, the solution is not "less choice", but "more > > people". > > It's unclear to me while the first solution is disqualified out of hand. > > I don't have a reason to believe that we will suddenly get lots more people > out of nowhere (even besides ignoring the lower marginal benefit that every > extra person adds). Hey, seems you're confusing the original issue. Indeed, here we have a potential maintainer proposing a new package, so it's exactly the converse: the package follows the new guy. So, yes sure, if we start crying about his very first package that's sure we won't "get lots more people out of nowhere"... Romain
Re: mass ITPs
Le Saturday 01 March 2008 19:48:50 Christian Perrier, vous avez écrit : > If someone cares to listen: when you think about ITPing each and every > piece of FLOSS that pops around: think about *helping* people who > maintain existing packages instead of adding even more noise to our > noisy bunch of various crap^W software. Hey, reading you I figured out that all newcomers are required to have contributions in Debian, which means *new packages*. So, yes I understand your point, but perhaps it's also the symptom of a more important issue: initial contributions to Debian often mean preparing new packages. Shouldn't we think about other alternatives in order to enforce contributions besides creating packages ? Romain
Re: dpkg semi-hijack - an announcement (also, triggers)
Le Thursday 13 March 2008 15:32:18 John Goerzen, vous avez écrit : > > Right. But currently, this has a good chance to keep Triggers out of > > lenny, which is a bloody shame. > > I understand, which is my point. People need to get a sense of > perspective. What is the more important goal: triggers in lenny or a > pretty git history? I think I didn't see it on this discussion, but there is also the risk of a factual fork of dpkg between Ubuntu and Debian, and that would even be worse.. To both.. Romain -- We are reincarnated souls from that time, Living on earth, heat, air and water in dis ya time.
Bug#471053: ITP: ocaml-duppy -- event scheduler for ocaml
Package: wnpp Severity: wishlist Owner: Romain Beauxis <[EMAIL PROTECTED]> * Package name: ocaml-duppy Version : 0.1.0 Upstream Author : The Savonet Team <[EMAIL PROTECTED]> * URL : http://savonet.sf.net * License : LGPL Programming Lang: OCaml Description : event scheduler for ocaml ocaml-duppy is an event scheduler written for ocaml. It allows the user to executes tasks according to events on unix sockets, or a given delay. Several threaded queues can proceed tasks in parallel. Tasks are processed according to an abstract notion of priority. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-rc7-mactel (SMP w/2 CPU cores; PREEMPT) Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-fglrx-devel] I am confused about configuration files
Le Thursday 20 March 2008 18:58:00 Artur R. Czechowski, vous avez écrit : > So what should be the proper way to allow switching between ATI and Debian > debs with drivers? The packages are never to be compatible or upgradable. To be more clear, we should even renamed them at some point. The proper way to switch, I believe, is to apt-get remove --purge one and install the other one. Now, sorry, I missed the train, what's the big deal with the remaining conffile ? Romain -- mama say son, today look like a rainy day but the food I ain't got enough rain a fall but dutty tough
Re: Bug#472048: libmtp7 shouldn't depend on udev
Le Sunday 23 March 2008 10:27:00 Rafael Laboissiere, vous avez écrit : > [I am moving this discussion into debian-devel, in order to get advise from > the other developers. Please, respect the M-F-T header.] > > The discussion below is about Bug#472048. I would like to know from people > using libmtp and its main reverse-dependencies (gnomad2, amarok, and > rhythmbox) whether it would be okay to change the Depends on udev to > Suggests, as proposed by the bug submitter. Recommends seems much better to me, unless you have a general reason for using Suggests. If the submitter wants to install without udev, then Recommends gives him this possibility, while most users will still have a full install. Romain -- We should really love each other In peace and harmony Instead, instead, we're fussing and fighting Like we ain't supposed to be, tell me why
Re: A suggestion
Le Wednesday 26 March 2008 16:35:51 Mike Bird, vous avez écrit : > The next DPL should have a solid plan for reversing Debian's decline. > If this means that some architectures fall by the wayside for lack of > interest then so be it. Better to lose several 0.1% architectures > than for Debian as a whole to continue the slide towards irrelevance. It seems that you are mixing two issues. One is the popularity of the system, the other is its quality and relevance. So, yes debian "loses" users in the way that they go to Ubuntu, and then claim that it fits better than Debian. Most of them are newbies that like the "plug and play" ubuntu way of designing the system. Fine, I'm even agruing in favour of Ubuntu for my friends that don't know much about Linux. But I didn't choose to use Debian because it was more easy to install or because it had the latest 3D desktop fancy effects ready to use. At the time I first tried Debian, the installer would ask you to choose your network card kernel module, and for a true beginer, this was really not easy ;-) I came to Debian because it is a general system, and because the community is able to choose for quality and technical things instead of meeting a deadline, or being the most appealing. I'm sorry to say it like that, but I really don't care that Debian be the most used distribution on the universe. Really. Instead, I rather prefer a general system, even with old piece of software, but for which we all focus on quality, or software licences etc.. For instance, with all its releases, and backports in every directions, I don't really see how Ubuntu can be reliable in security. Being the maintainer of some webapps, for which security issues hapen often, I am sure that they didn't fixed each of them, simply because they have a different version in each release, and no security backports for each. Now, about the social aspects, I also believe that Ubuntu plays a completly complementary role with Debian. In particular, the career of a linux user would be to start with Ubuntu. Easy to install, easy to use. Then, if the user wants to get to know more the system, at some point it will have to get to know Debian, since it's the backbone of Ubuntu. So, instead of "loosing" users, Debian simply attract less beginers, but will likely get experimented users that want to contribute and get to know the system. If, for instance, you look on the overall quality of users documentation and comments in Ubuntu forums, I'm often very thankfull we don't have such. Then, it's very important for this to work well that we don't fork with Ubuntu. In particular, packaging or system standards should remain common, or at least very similar. Also, Ubuntu wouldn't have so many package if they couldn't backports ours, so this is also important for them. Romain -- If you are the big tree, We are the small axe, Ready to cut you down, Sharpen to cut you down...
Re: dpkg triggers, dpkg hijack
Le Thursday 27 March 2008 21:54:24 Julien BLACHE, vous avez écrit : > Faidon Liambotis <[EMAIL PROTECTED]> wrote: > > In your position, I'd probably be afraid of receiving the "Joerg > > Schilling award". > > The "Sven Luther award" may be more appropriate; time will tell. Can you stop posting such irrelevant and provocative mails ? Romain -- The rich man's wealth is his strong city: the destruction of the poor is their poverty. - Proverbs 10:15 The rich man's wealth is in the city Vexation of the soul is vanity Destruction of the poor is their poverty - Peter Tosh, Fools Die
Re: Should -dev packages providing .pc files depend on pkg-config?
Le Sunday 06 April 2008 00:08:43 Roger Leigh, vous avez écrit : > > The foo package's build dependencies are only relevant when building the > > foo package. For someone who develops software based on libbar, it is > > not obvious that foo's build dependencies are required. > > As an upstream, I include a .pc file for the convenience of people who > want to link with my libraries. However, using pkg-config or > PKG_CHECK_MODULES is entirely optional, and so really a Suggests or > Recommends is more appropriate. If the user decides to use > pkg-config, then it's really their responsibility to have pkg-config > in their Build-Depends, not that of the library packager. Just to add my two bits to this, we recently had a FTBFS with ocaml-mad exactly related to this: the library checked by the configure script had changed its dependency, hence pkg-config was no more available. Clearly, as others pointed out, it's the .pc user's responsability to build-dep on pkg-config: we didn't notice the missing build-dep precisely because it was pulled by the library. Hence, not only do I advocate for the optional depency, but it is good if pulling libfoo-dev don't pull pkg-config during an automatic build, so that you are sure that any ./configure needing pkg-config has it as a build-dep. Romain -- Marcus Garvey told us That freedom is a must. He told us that the Black Star Liners Are coming one day for us.
Bug#476296: ITP: ocaml-faad -- OCaml bindings for the freeware Advanced Audio Decoder library
Package: wnpp Severity: wishlist Owner: Romain Beauxis <[EMAIL PROTECTED]> * Package name: ocaml-faad Version : 0.1.1 Upstream Author : The Savonet Team <[EMAIL PROTECTED]> * URL : http://savonet.sf.net/ * License : LGPL Programming Lang: OCaml Description : OCaml bindings for the freeware Advanced Audio Decoder library This package will provide the bindings for the libfadd library (and a more detailled description) :-) It will maintained by the Debian Ocaml Maintainers team. Romain -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-rc7-mactel (SMP w/2 CPU cores; PREEMPT) Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Should DMs be allowed to upload to NEW
Le Wednesday 16 April 2008 15:44:56 Neil Williams, vous avez écrit : > An upload of a new application is nowhere near as complex as the upload > to start a library SONAME transition. Even uploading a new library never > seen in Debian before is easier than starting a SONAME transition for a > library that already exists. I'm sorry, merely by equating those two you > have lost all credibility in my eyes. Why should he have to gain any credibility in your eyes ? Were you about to help him dealing with this ? > It's not just about trust, it is about coordination, planning and > ability. If you think that a SONAME transition is no more disruptive > than a new application then I have cause to worry about your ability to > maintain a library in Debian in the first place. It doesn't give me any > confidence in you or in DMs in general. Well, ok SONAME is a dangerous thing, warning, warning !! In the mean time, it's still possible for a DM to upload a different soname in the same binary package, which would result in an even worse mess, right ? I don't like your tone, it's pedantic, because somehow it's legitimate to ask this kind of questions regarding the potential harm he already has the right to do with the DM upload rights. And I believe you didn't even look at his package (neither did I by the way...) Romain -- How can a man Discover a land That already populated with Indians?
Bug#480438: ITP: ocaml-bjack -- OCaml blocking API to jack audio connection kit
Package: wnpp Severity: wishlist Owner: Romain Beauxis <[EMAIL PROTECTED]> * Package name: ocaml-bjack Version : 0.1.0 Upstream Author : The Savonet Team <[EMAIL PROTECTED]> * URL : http://savonet.sf.net/ * License : LGPL + link exception Programming Lang: OCaml and C Description : OCaml blocking API to the jack audio connection kit ocaml-bjack provides a blocking API to the jack audio connection kit. Using this API, you can create a jack device and read/write from it much like with ALSA or OSS. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-rc7-mactel (SMP w/2 CPU cores; PREEMPT) Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#483856: ITP: oss4 -- Next generation of the Open Sound System
Package: wnpp Severity: wishlist Owner: Romain Beauxis <[EMAIL PROTECTED]> * Package name : oss4 Version : 4.0 Upstream Author : 4Front Technologies * URL : http://www.4front-tech.com/developer/sources/stable/gpl/ * License : GPL Programming Lang: C Description : Next generation of the open sound system OSS4 is the branch of the original open source system that became temporary closed source some times ago. This is now over, and the code is GPLed for linux systems. Many developers claim that OSS4 is now far supperior to ALSA in many domains, in particular documentation and API. I personally tend to agree with them, and since the code is GPL, I don't see any reasons why we shouldn't provide this alternatives to our users. I was not able to find a similar ITP or packaging effort, so I hope this is not redundant. I'll be, of course, accepting other interested packagers for this package. For more details, you can read this blog post: http://insanecoding.blogspot.com/2007/05/sorry-state-of-sound-in-linux.html and: http://4front-tech.com/hannublog/?p=5 Of course, they may be biased, but that doesn't mean we can't provide these drivers and let the user choose. Romain -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.22-3-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Inconsistent archive
Hi ! Le Tuesday 03 June 2008 08:53:59 Klaus Ethgen, vous avez écrit : > By the way I would like it too to see oss4 in debian as alsa is not > usable at all. (Please feel free to have flame me about by private mail; > this is just my experience/opinion.) No problem to join the packaging effort ! Currently, I can't reach alioth, but I will open a project soon. For the moment, I have started a dicussion upstream, which seems very responsive. In particular, the current build system is not usable at all for a proper package. They also advised to wait for the next 4.1 release for an initial packaging.. See: http://mailman.opensound.com/pipermail/oss-devel/2008-June/000449.html Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
Le Monday 16 June 2008 07:31:49 William Pitcock, vous avez écrit : > With grub being stable and grub2 approaching stability itself, do we > really need lilo anymore? It's not even installed by default anymore, > and the only systems I have that are still on lilo are installations of > Debian I have had since Woody. I have lilo for the systems where I want /boot to be on LVM. What would you do for those installs ? Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
Le Monday 16 June 2008 12:03:09 Michael Banck, vous avez écrit : > > On some of my boxes all filesystems are on LVMs and the Debian installer > > used lilo to boot the systems. It would be nice if these systems can > > still be used with future Debian versions. Please remove lilo only if > > there's a full replacement available. > > Lilo is already removed from testing and will not be in lenny until > somebody steps up and cares for it. Really that is not serious. The RC bug is a side effect as explained before, and just for that the package is removed while it is still part of the installer and very important to *many* users, without even communicating about it. I'm really disapointed of such a irresponsive behaviour. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#488389: ITP: libv4l -- Transparent conversion layer for V4L devices
Package: wnpp Severity: wishlist Owner: Romain Beauxis <[EMAIL PROTECTED]> * Package name: libv4l Version : 0.2 Upstream Author : Hans de Goede <[EMAIL PROTECTED]> * URL : http://people.atrpms.net/~hdegoede/ * License : LGPL Programming Lang: C Description : Transparent conversion layer for V4L devices Libv4l is a collection of libraries which adds a thin abstraction layer on top of video4linux2 devices. The purpose of this (thin) layer is to make it easy for application writers to support a wide variety of devices without having to write seperate code for different devices in the same class. libv4l1 and libv4l2 provide alternatives for all v4l-related operations. It offers functions like v4l2_open, v4l2_ioctl, etc. which can by used to quickly make v4l2 applications work with v4l2 devices with weird formats. Also, libv4l provides an userspace v4l1 emulation: It offers functions like v4l1_open, v4l1_ioctl, etc. which can by used to quickly make v4l1 applications work with v4l2 devices. It also includes a wrapper library that allows to use it without the need to modify an existing application, using the LD_PRELOAD environment variable. Romain -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian packaging license (was: Re: RFC: DEP-3: Patch Tagging Guidelines).
Le lundi 10 août 2009 09:58:04, Jonathan Yu a écrit : > On Mon, Aug 10, 2009 at 1:13 AM, Charles Plessy wrote: > > Le Tue, Jun 16, 2009 at 11:33:58AM +0800, Paul Wise a écrit : > >> On Tue, Jun 16, 2009 at 7:20 AM, Charles Plessy wrote: > >> > The dh_make template for debian/copyright induces many developers to > >> > put their packaging work under the GPL, and I have already seen > >> > packages whose license is otherwise BSD-ish with such patches. If the > >> > maintainer suddenly goes MIA and the patch is non-trivial, then in > >> > theory if we want to respect what is written, we are stuck with a > >> > GPL'ed patch. Therefore, we have an optional License field to make > >> > things crystal clear if necessary. > >> > >> Sounds like dh_make needs a bug report about the default packagaging > >> license, could you file one? > > > > Dear all, > > > > we just had a case in the Debian Med packaging team where the upstream > > author of software licensed under terms similar to the BSD license got > > upset to see the Debian packaging licenced under the GPL, and posted a > > reminder that GPLed contributions to his software will not be accepted. > > Yes, this is precisely why the pkg-perl team usually goes with "same > terms as Perl itself" (Artistic | GPL) and whatever the upstream > licensing terms are (usually Artistic | GPL but sometimes BSD). > > So for example if upstream is BSD-licensed, then I'd personally put > something like: > Artistic | GPL | BSD > for the debian/* files > > My reasoning is that the upstream can get stuff like patches back into > their software (the BSD) provision but also allows anyone that can use > Perl to use the patch (Artistic | GPL). Further, if upstream decides > later to change to the "same as Perl" license (it is probably the most > popular license on CPAN), it is okay for them to do so (with our > patches). > > In the case of Debian-Med (being an outsider and not knowing what the > team works with), I'd say explicitly licensing your debian/* files > under the same license as upstream would be appropriate, or perhaps a > combination of upstream | GPL licensing. This is clearly a discussion > we all need to have within teams/package groups/etc -- namely, what do > we want our debian/* files to be licensed under. And also what exactly is covered by the license claim. For instance, in the case of patches contained in debian/, I have some doubts about the license that applies. Usually, when one wants to propose a patch to a project, it has to do it under the original licence. That's particularly the case if the patch consists, for instance, of the diff of a commit from the current developpement code of the same upstream project... Hence, are patches in debian/ covered by the license claimed for the project upstream, or for the debian packaging ? Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
Le mercredi 12 août 2009 04:59:09, Josselin Mouette a écrit : > AIUI, this header is here to indicate which version of the policy the > package is supposed to conform to. This way, we have a way to enforce > which policy versions are supported, e.g. in a stable release, by > forbidding the too old versions. Cleartly, that this field is not quite used at the moment. Clearly also, the packaging workflow nowadays tends to be driven by lintian checks. You do the update, you pass through the automated tests. Some people remarked that, unfortunately, not all policy requirements can be automated, hence there is a difference between being lintian clean and conforming to the policy. Some other remarked that it is a very time-consuming task to do all the checklist for every policy change, which is quite true. But there could be another use of this field, which would fit into the test- driven workflow. What about a tool that displays the changes in the policy based on the declared supported version and the latest version ? This could display a simple checklist that the maintainer could check easily. This would also include only the relevant changes since the latest check, while we only have diff from one version to another. Eventually, after going through the list, you could safetly update this field knowing and also save time. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
Le mercredi 12 août 2009 23:22:45, Russ Allbery a écrit :
> Romain Beauxis writes:
> > But there could be another use of this field, which would fit into the
> > test- driven workflow. What about a tool that displays the changes in
> > the policy based on the declared supported version and the latest
> > version ?
>
> Like:
>
> zcat /usr/share/doc/debian-policy/upgrading-checklist.txt.gz \
> | sed /`grep Standards-Version debian/control | awk '{ print $2
> }'`/Q
>
> ? I just use zless on that file and stop reading when I get to the
> current Standards-Version of the package, but that would automate it.
>
> This is, indeed, exactly the use of the Standards-Version field that both
> Manoj and I are advocating.
Is it foolish to propose this as a lintian check ? "Hey, standards version is
outdated, here are the changes that ought to be done"
Even more, this could include only the changes that cannot be automated..
Romain
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
Le jeudi 13 août 2009 00:09:09, Cyril Brulebois a écrit : > Romain Beauxis (12/08/2009): > > Is it foolish to propose this as a lintian check ? "Hey, standards > > version is outdated, here are the changes that ought to be done" > > checks/standards-version.desc Please, pretty please, try to make sentences. I hardly understand your comment, which makes it ambigous. Here is the output of a lintian warning currently in the case of an outdated standards-version: W: foo: ancient-standards-version 3.7.0 (current is 3.8.2) N: N:The source package refers to a Standards-Version that has been obsolete N:for more than two years. Please update your package to latest Policy and N:set this control field appropriately. N: N:If the package is already compliant with the current standards, you N:don't have to re-upload the package just to adjust the Standards-Version N:control field. However, please remember to update this field next time N:you upload the package. N: N:See /usr/share/doc/debian-policy/upgrading-checklist.txt.gz in the N:debian-policy package for a summary of changes in newer versions of N:Policy. N: N:Severity: normal, Certainty: certain What I mean is that we can use the information contained in the standards- version tag and display at this place the list of changes that were done since 3.7.0 That makes a difference in the sense that it helps to improve the workflow by putting as much information as possible in the same place. Even more, if, as I suggested, it lists only changes that couldn't be automatised, that would make lintian a consistent tool for checking a package against the current policy. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
Le jeudi 13 août 2009 00:31:40, Paul Wise a écrit : > Please file a bug (and patch) against lintian, I doubt the lintian > maintainers would have a problem with this as long as it is > implemented sanely. Ok. Are the .desc files processed in any way ? I looked at lintian's source and could find any substitution there.. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
Le jeudi 13 août 2009 01:13:44, Romain Beauxis a écrit : > Le jeudi 13 août 2009 00:31:40, Paul Wise a écrit : > > Please file a bug (and patch) against lintian, I doubt the lintian > > maintainers would have a problem with this as long as it is > > implemented sanely. > > Ok. Are the .desc files processed in any way ? > I looked at lintian's source and could find any substitution there.. That was meant to be private, sorry for noise.. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: What’s the use for Standards-Version?
Le jeudi 13 août 2009 00:48:13, Manoj Srivastava a écrit : > > That makes a difference in the sense that it helps to improve the > > workflow by putting as much information as possible in the same place. > > Oh, for Pete's sake, just run zless on the file lintian already > reports for you. If people are too lazy to run zless , I kinda > doubt they are actually going to the effort of actually doing a good > job on their packages. You realize you still have to read the sections > mentioned in the policy document, right? Treating people to be lazy will not lead to a better quality of their packages. Simplifying their work, however, will. > > Even more, if, as I suggested, it lists only changes that couldn't be > > automatised, that would make lintian a consistent tool for checking a > > package against the current policy. > > ANd how is lintian supposed to know this? Or are you saying we > have a new version of lintian every time that policy is updated, and it > hard codes the line in the upgrading checklist to report, and only > reports sections that have changes not fully checked by lintian -- and > for what? so that someone does not have to type zless ? I realize this is not easy to implement. I will, however propose something showing the whole list of changes. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: What criteria does ftpmaster use for the ‘copyright’ file of a package?
Le samedi 29 août 2009 09:29:30, Ben Finney a écrit : > If the governing interpretation is that “all copyright notices and > distribution license” need to be duplicated into the file, how many > packages in Debian are violating policy by this reading? More to the > point, does this interpretation actually match the consensus of the > project? I agree with you. As for myself, I list all licenses, but I would add only the main copyright holder(s), and, from now on, add a sentence along those lines: "This is the copyright of the main project maintainers. For other copyright, please check the corresponding source files." Also, to make things more sensitive, I would link the issue to the Debian Free Software Guidelines. My belief is that we *all* agree on those guidelines, and that the subsequent requirements in the policy about debian/copyright are here just to put these general ideas into words and directives. In this context, the minor copyright notices have nothing to do with the DFSG, but the licenses do. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550803: ITP: ocaml-cry -- Low-level OCaml implementation of the Shout protocol
Package: wnpp Severity: wishlist Owner: Romain Beauxis * Package name: ocaml-cry Version : 0.1.0 Upstream Author : The Savonet Team * URL : http://savonet.sf.net/ * License : GPL-2 Programming Lang: OCaml Description : Low-level OCaml implementation of the Shout protocol ocaml-cry implements the protocols used to connect and send source data to icecast2 and shoutcast servers. It is a low-level implementation, so it only does the minimal source connection. In particular, it does not handle synchronisation. Hence, the task of sending audio data to the streaming server at real time rate is up to the programmer, contrary to the main implementation, libshout. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#407468: ITP: cwiid -- Linux interface to the Wiimote
Package: wnpp Severity: wishlist Owner: Romain Beauxis <[EMAIL PROTECTED]> * Package name: cwiid Version : 0.3.51 Upstream Author : L. Donnie Smith <[EMAIL PROTECTED]> * URL : http://www.wiili.org/index.php/CWiid * License : GPL Programming Lang: C Description : Linux interface to the Wiimote CWiid is a Linux interface to the Wiimote written in C. The goal of this project is to develop a working userspace driver along with various applications implementing event drivers, multiple wiimote connectivity, gesture recognition, and other Wiimote-based functionality. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18.5-mactel Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#407468: ITP: cwiid -- Linux interface to the Wiimote
Le jeudi 18 janvier 2007 19:21, Julien Cristau a écrit : > Hi, Hi ! > On Thu, Jan 18, 2007 at 18:57:41 +0100, Romain Beauxis wrote: > > CWiid is a Linux interface to the Wiimote written in C. > > is there any reason this needs to be mentioned in the package > description? I'd think most users don't care, and those who do can use > debtags to find out. No at all, simply I was too lazy to change the website description, but I'll do it for the package obviously ! Romain -- 'mama say son, I ain't got no food today tit for tat, butter for fish there's a little porridge in the dish
Re: Bug#411209: ITP: libwiimote -- Simple Wiimote Library for Linux
Le samedi 17 février 2007 05:42, Kobayashi Noritada a écrit : > * Package name : libwiimote > Version : 0.3 > Upstream Author : Joel Andersson > Chad Phillips > * URL : http://sourceforge.net/projects/libwiimote/ > * License : GPL > Description : Simple Wiimote Library for Linux > > Libwiimote is a simple C library for communicating with the Nintendo Wii > Remote on a Linux system. Even though the API strives to be minimal, it > provides complete control over most features of the wiimote and nunchuk > controllers. Please, use the name "libcwiimote" as changed upstream. This avoid any colision with libwiimote as provided by cwiid that I am actually packaging... Romain
Bug#412235: ITP: transfermii -- mii transfer program
Package: wnpp Severity: wishlist Owner: Romain Beauxis <[EMAIL PROTECTED]> * Package name: transfermii Version : 0.3.1 Upstream Author : Arnaud Ysmal <[EMAIL PROTECTED]> * URL : http://www.stacktic.org/ * License : GPL Programming Lang: C Description : mii transfer program transfermii allows you to transfer your miis from and to your wiimotes. I uses cwiid as a backend. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20-mactel-mactel Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412704: ITP: ocaml-ao -- OCaml bindings for libao
Package: wnpp Severity: wishlist Owner: Samuel Mimram <[EMAIL PROTECTED]> * Package name: ocaml-ao Version : 0.1.6 Upstream Author : the Savonet Team <[EMAIL PROTECTED]> * URL : http://savonet.sf.net/ * License : GPL Programming Lang: OCaml Description : OCaml bindings for libao OCaml bindings for the cross platform audio output library. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20-mactel-mactel Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: video codecs in HTML 5
Le vendredi 23 mars 2007 14:11, Maik Merten a écrit : > > Fortunately not. We have free MPEG-4 decoders, thanks. > > I don't consider this to be true. > > Can you give a source supporting your theory? Well, check for mpeg4 decoders in main archive.. I think you are missunderstanding his point, because a patent is not directly related to the freeness of the code. If we were to remove all software that is subject ot patent threats, we would remove most of our archive I fear... Romain
Re: video codecs in HTML 5
Le vendredi 23 mars 2007 14:46, Maik Merten a écrit : > Romain Beauxis schrieb: > > Well, check for mpeg4 decoders in main archive.. > > I think you are missunderstanding his point, because a patent is not > > directly related to the freeness of the code. > > If we were to remove all software that is subject ot patent threats, we > > would remove most of our archive I fear... > > To legally use MPEG4 you have to pay fees. Not only is MPEG4 encumbered > by patents, they're enforced, too. Same for MP3. To my knowledge no MPEG > patents are installed by default on Debian - for good reasons. This always the same story.. Patents are registered 'a priori', and owning a patent does not implies that it is justified in any ways. Patents must be treated as a threat, not a legal binding that will enforced by the law. There is plenty of archive on this subject in and out of the debian project, so I don't think this debate worth to be continued here.. Romain http://minilien.com/?Nz1w2Xc6Ri -- Preacherman, don't tell me, Heaven is under the earth. I know you don't know What life is really worth. It's not all that glitters is gold; 'Alf the story has never been told: So now you see the light, eh! Stand up for your rights. Come on!
Re: video codecs in HTML 5
Le vendredi 23 mars 2007 16:10, Maik Merten a écrit : > If somehow possible the WHATWG should adopt a free format and I think > it's in the best interest of Debian to bringing this to the WHATWG's > attention. I don't agree, you'll always have the threat of an abusing patent that claims that some algorithm you designed were "owned" by it.. Have you ever looked at the JPEG processing for example ? It is simply a fourier transform followed by an huffman compression... All well known, but still "owned" by an abusing patent.. Patents have to be beaten at their roots, or you won't run away from them.. Romain -- Everyday is just a holiday, I don't care what the crowd may say. I live the life I love with you, Having fun while they are feeling blue.
Re: many rejects (Re: Second call for votes for the debian project leader election 2007)
Le mercredi 28 mars 2007 09:31, Michal Čihař a écrit : > Same here, tried encrypted first, it failed (see bellow), then > unencrypted and it worked fine. Precisly the same issue here. It has been reported to work on mutt, and it failed here with kmail. Is the crypt+sign mail format standard ? Romain
Re: Second call for votes for the debian project leader election 2007
Le mercredi 28 mars 2007 15:16, Andreas Tille a écrit : > I'm obviousely hit by two broken MUAs (pine, mailx) and not > willing to spend more then 10 minutes just to send my vote. Plus kmail I think. Romain
Bug#426069: ITP: spip -- website engine for publishing
Package: wnpp Severity: wishlist Owner: Romain Beauxis <[EMAIL PROTECTED]> * Package name: spip Version : 1.9.2b Upstream Author : SPIP Development Team <[EMAIL PROTECTED]> * URL : http://www.spip.net/ and http://trac.rezo.net/trac/spip/ * License : Mainly GPL and other open source licences Programming Lang: PHP with some JS Description : website engine for publishing SPIP's benefit consists in: . * managing a magazine type site i.e. made up mainly of articles and news items inserted in an arborescence of sections nested in each others. * completely separating and distributing three kinds of tasks over various players: the graphic design, the site editorial input through the submission of articles and news items and the site editorial management. * spare the webmaster and all the participants to the life of the site, a number of tedious aspects of web publishing as well as the need to learn lengthy technical skills. SPIP allows you to start creating your sections and articles straight away. . Homepage: http://www.spip.net/ Other contributions on this package are welcome. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.20-1-amd64 (SMP w/1 CPU core) Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#426069: ITP: spip -- website engine for publishing
Hi ! Le Saturday 26 May 2007 13:03:09 Moritz Muehlenhoff, vous avez écrit : > This was already in the archive and has been removed mostly for > it's poor security track record. Re-introducing it is a very > bad idea. I've been trought the previous spip bugs, and it seems that missing security support was mostly because of MIA maintainer that anything else. As for what I've seen from SPIP devel activities, they seem very active and responsive, and they provide a track system for bug report and etc.. However, I'll contact them and ask for their commitment to solving seciruty issues, but I'm quite sure that the main issue remains in the hand of the maintainer, to be able to update the package as soon as they fix anything.. Romain -- The lips of the righteous feed many: but fools die for want of wisdom. - Proverbs 10:21 The lips of the righteous teaches many But fools die for want of wisdom - Peter Tosh, Fools Die
Re: Bug#426069: ITP: spip -- website engine for publishing
Le Tuesday 29 May 2007 23:12:53 Moritz Muehlenhoff, vous avez écrit : > Romain Beauxis wrote: > > However, I'll contact them and ask for their commitment to solving > > seciruty issues, but I'm quite sure that the main issue remains in the > > hand of the maintainer, to be able to update the package as soon as they > > fix anything.. > > It had too many security problems in 2006. We already have far too many > buggy packages in the archive, security updates are not an infinite > ressource. I recommend to upload to experimental and re-evaluate it's > security history four months prior to Lenny freeze. I'll of course make initial upload into experimental. However, one of upstream's developpers has join the packaging effort, so I don't see anything preventing a good security support for this package. Romain -- Police and thieves in the street Oh yeah! Fighting the nation with their guns and ammunition
Bug#493105: ITP: json-wheel -- Ocaml API to JSON data format
Package: wnpp Severity: wishlist Owner: Romain Beauxis <[EMAIL PROTECTED]> * Package name: json-wheel Version : 1.0.4 Upstream Author : Martin Jambon <[EMAIL PROTECTED]> * URL : http://martin.jambon.free.fr/json-wheel.html * License : BSD Programming Lang: OCaml Description : Ocaml API to JSON data format json-wheel provides a convenient API to generate and parse JSON data from an ocaml program. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.22-3-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493109: ITP: json-static -- JSON validator and converter for OCaml
Package: wnpp Severity: wishlist Owner: Romain Beauxis <[EMAIL PROTECTED]> * Package name: json-static Version : 0.9.6 Upstream Author : Martin Jambon <[EMAIL PROTECTED]> * URL : http://martin.jambon.free.fr/json-static.html * License : BSD Programming Lang: OCaml Description : JSON validator and converter for OCaml json-static is a tool for converting parsed JSON data with an unchecked structure into specialized OCaml types and vice-versa. It is a complement to the json-wheel library which provides a parser and a (pretty-) printer. By reading a type definition, the preprocessor inserts code that converts between OCaml types (lists, arrays, tuples, objects, polymorphic variants, ...) and untyped JSON data. Those type definitions are written in a syntax which is very close to regular OCaml type definitions. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.22-3-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#502959: general: raff.debian.org uses non-free software
Le Tuesday 21 October 2008 13:10:28 Peter Clifton, vous avez écrit : > Having no source-code for firmware is hardly that different to having a > completely open-source driver which does un-told magic by poking > un-documented registers in a complex chip. Think Intel graphics before > they released documentation for (some of) their chips. Agreed, though it does not restrain us from asking for free firmware. If I recall well, one of the origin of the GNU fondation was the fact that having free drivers alowed one to actually *fix* issues he may have with his *own* hardware. Then, the very same reasoning can apply to binary firmware. So, yes this is a brand new issue, that comes from the new way of designing hardware. But that doesn't mean we should give up and remain behind the line that was drawn 20 (or so) years ago. We now should also ask for open source firmware for the very same reason that this huge effort toward free drivers was done. If we did it for drivers, there's no reason we can't suceed for firmwares. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#502959: general: raff.debian.org uses non-free software
Le Tuesday 21 October 2008 22:28:31 Lennart Sorensen, vous avez écrit : > > If I recall well, one of the origin of the GNU fondation was the fact > > that having free drivers alowed one to actually *fix* issues he may have > > with his *own* hardware. Then, the very same reasoning can apply to > > binary firmware. > > Having driver source code lets you fix the drivers and port htem to > other operating systems and architectures. Having firmware source makes > no difference to that problem as long as the firmware is working. If it > isn't working, you would probably know soon enough and return the > defective hardware. Firmware updates also happen to fix bugs.. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
Le Saturday 25 October 2008 10:56:56 Kalle Kivimaa, vous avez écrit : > Steve Langasek <[EMAIL PROTECTED]> writes: > > Could you please elaborate here? The DFSG does not require us to have or > > ship source code for non-program works, and if documentation is being > > rejected on the basis of a *source* requirement (as distinct from a > > licensing issue), then I think we have a problem. > > Well, we ftpmasters and assistants routinely REJECT packages > containing binary components without source, eg. PDF documentation. We > base this policy on the DFSG as explained in > http://www.debian.org/vote/2006/vote_001 which very clearly states > that documentation needs to comply with the DFSG. The resolution states that GFDL licence does not fit for main, mainly because it has invariant sections, which are not *modifiable*. Extending a resolution beyond its original scope does sound broken an dangerous to me. Furthermore, request to have the source is a subjective thing. How would you provide the source of a (free) WAV file then ? Since the licence comming with the pdf was, up to what I read and understand, compatible with DFSG, in particular right to reproduce, distribute and *modify*, I completely fails to see the motivations for such a decision. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
Le Saturday 25 October 2008 18:36:33 Kalle Kivimaa, vous avez écrit : > Romain Beauxis <[EMAIL PROTECTED]> writes: > > Since the licence comming with the pdf was, up to what I read and > > understand, compatible with DFSG, in particular right to reproduce, > > distribute and *modify*, I completely fails to see the motivations > > for such a decision. > > Let me quote the GR text: > > "In practice, then, documentation simply isn't different enough to > warrant different standards: we still wish to provide source code in > the same manner as for programs, we still wish to be able to modify > and reuse documentation in other documentation and programs as > conveniently as possible, and we wish to be able to provide our users > with exactly the documentation they want, without extraneous > materials. " > > As we don't accept program object code without source, we are not > accepting document binaries without source, either. For the motivation > behind the GR, read the various lists for that time, this was > discussed extensively back then. Do you claim a PDF file is a binary file, or a program object ? Even if PDF was a programming language, as proposed in another anwser, it would fall into the script category, where the executed object is also the source. Furthermore, requirement to provide source code is a consequence of the requirement to be able to modify the program. Again, if I provide a manual for blind people consisting in a wav (or a ogg/vorbis) file, what kind of source would you ask for then ? Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: URGENT: Please remove my email from your web-page
Le Wednesday 29 October 2008 11:17:57 Norbert Preining, vous avez écrit : > Anyone with a decent intelligent approach would ask the list masters, > admins, whoever, and NOT post again on debian-devel. I think that Charles meant that, even though someone makes a naive request for which you -- and I -- believe is ridiculous, it doesn't give you the right to give a rude answer, or worse, insult him. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what about a unofficial public community repo? (was: Re: qmail and related packages in NEW)
Le Friday 28 November 2008 23:57:09 Holger Levsen, vous avez écrit : > On Friday 28 November 2008 22:42, William Pitcock wrote: > > I think issues like these call for an unsupported repository outside of > > Debian, but publicized within the community as an unofficial repository > > for things like qmail, packages unwanted in Debian proper for the time > > being, etc. > > debian-unofficial.org Or, why not apt-get.org ? Or mentors.debian.net ? Honnestly, I fail to see clearly the benefit of it, apart from more confusion and new issues.. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#507412: ITP: liq-contrib -- contributed scripts for liquidsoap
Package: wnpp Severity: wishlist Owner: Romain Beauxis <[EMAIL PROTECTED]> * Package name: liq-contrib Version : 08.11 Upstream Author : The Savonet Team <[EMAIL PROTECTED]> * URL : http://savonet.sf.net/ * License : GPL v2+ Programming Lang: liquidsoap Description : contributed scripts for liquidsoap liq-contrib contains various scripts implemented using the liquidsoap audio streaming language. . Currently, it contains: o liq123: a command line audio player o streamliqueur: an audio stream ripper o simpleliq: a program to create and test simple streaming examples using the liquidsoap language. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW processing
Le Wednesday 03 December 2008 09:55:24 Kalle Kivimaa, vous avez écrit : > "Steve M. Robbins" <[EMAIL PROTECTED]> writes: > > Is the NEW queue going to get processed any time soon? There's a load > > of packages that are 3 weeks or more old. > > The NEW queue is constantly being processed. Unfortunately it seems > that in the normal case more packages enter NEW than are processed, so > the queue grows. Then at some point the ftpmasters get too annoyed > with it and have a weekend NEW cleaning session, bringing it down to a > more manageable size (50-60 packages). I've always wondered why it is not possible to add meta information to an upload. While I totally understand a delay for new packages, as for Daniel, I sometimes upload package which go to NEW but for reasons that should take a minute to check, like new binary packages. In these cases, it would be nice to add an annotation to give hints about the complexity of the task to the ftp-masters.. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW processing
Le Wednesday 03 December 2008 12:07:51 Cyril Brulebois, vous avez écrit : > Romain Beauxis <[EMAIL PROTECTED]> (03/12/2008): > > I've always wondered why it is not possible to add meta information to > > an upload. > > […] > > In these cases, it would be nice to add an annotation to give hints > > about the complexity of the task to the ftp-masters.. > > You want debian/changelog? I depends how the workflow for ftp-masters. Apparently these packages stay in NEW for the same time as the others, although the changelog is documented. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW processing
Le Wednesday 03 December 2008 13:34:06 Lucas Nussbaum, vous avez écrit : > That's not true. We imposed that reviewing step to ourselves, and, if > it's doing more harm (by slowing down development and annoying > contributors) than good (by detecting mistakes and improving Debian's > overall quality), we could simply decide to drop it. (or to drop it > partially, for some categories of uploads). > > It's funny how in Debian, we always prefer to add more checks (which > always let some things get thought while they shouldn't) rather than > trusting developers to do the right thing. It's similar to what happened > to the NM process. Although it adds some lag, I strongly believe it detects a lot of mistakes and it still has its interest. The mistakes they detected from my packages really needed to be fixed. I thank the ftp-masters for detecting them. And wait for the delay. Yes, sometimes their decisions are questionable, but the overall interest of the NEW queue shouldn't be an issue. And I don't think I am really worse than the average packaging quality Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW processing
Le Wednesday 03 December 2008 14:36:39 Miriam Ruiz, vous avez écrit : > > If people feel that a reviewing service is needed, we could split > > that out of NEW processing and have a separate service (or just use > > debian-mentors@ and http://mentors.debian.net). > > Yup, I agree with you. I think that makes sense. Humm.. I must mitigate my previous mail. I, too, believe the copyright check is the core of the role of the NEW queue. Quality checks could be done later and this would ease the whole process while keeping a focus where it is important. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW processing
Le Wednesday 03 December 2008 16:33:15 Martin Wuertele, vous avez écrit : > > Quality checks could be done later and this would ease the whole process > > while keeping a focus where it is important. > > I completely disagree. It's a welcome benefit if packages of inferior > quality are prevented from entering the archive in the first place imo. > If you want to test packages not yet ready for debian you can upload > them to universe. Quality checks can and should be done on a community basis. As said elsewhere, in any way, after the NEW checks you are free to break whatever you want. That's what trust between DDs is about, after all. I really don't see why it should be needed to have those checks at the initial upload, while I see it clearly for legal and archive issues. They even lead to quality issues since they block potential fixes for other bugs and add lag to fixes involving several packages going through NEW. That's particularly true for packages that introduce only a new binary package. The hold is necessary for archive issues, but the delay isn't. One good idea could be to have public checkboxes about what needs to be checked, where packages with only binary changes should be processed much faster. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW processing
Le Wednesday 03 December 2008 22:15:50 Joerg Jaspert, vous avez écrit : > Packages that only add new binary components are already sorted above > packages that have completly new source, to decrease their time in the > queue, as their checks are much faster done than a complete source > review. But even those have a little review from us, enough people > manage to even get those done wrong. Love empty packages? soname changes > like to do that to people, for example. Thanks for this answer. I would like to see these particular uploads be accepted faster. Could it be possible to make them more automatic when lintian checks are implemented in dak ? I guess that archive consistency and empty package, if they are the main issues, could be catched more automatically... Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First call for votes for the Lenny release GR
Le Sunday 14 December 2008 21:19:35 Andreas Barth, vous avez écrit : > > FD will be a mess, but as I've previously posted, I believe that means > > that we fail to override a delegate decision and hence the release of > > lenny proceeds. > > Though I agree with that, voting for option 4 is even more explicit (and > nobody can disagree what *that* one means), so voting for option 4 as > preferred option, and further discussion below (and option 1 as least > desirable) is a more certain way to achive that. 4 or then FD is definitely my vote. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The firmware GR
Le Monday 15 December 2008 10:36:50 Robert Millan, vous avez écrit : > > With these hopefully solid plans in place for the release, we feel the > > need to acknowledge that there is an ongoing vote whose outcome could > > potentially disrupt them. > > Luk is referring to 11 bugs in linux-2.6 which all have a 'patch' tag, and > which the maintainers have been ignoring so far. Option 1 wouldn't cause > any "disruption" to the release process, other than moving support for > these chips to non-free when the patches are applied. Any other delay is > self-imposed. Unfortunately you forgot to also mention this bug for instance: http://bugs.debian.org/494120 Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
Le Monday 15 December 2008 23:19:55 Bastian Venthur, vous avez écrit : > > Note that forking+stable'izing Sid is what Ubuntu does every six months. > > Is that important? Unstable is frozen for nearly 1/2 year now, that's a > problem we should try to solve if we don't want to degrade ourselves to > a server-only distribution. You can't get both recent *and* stabilized software. For a solid release to be done, one needs to hold new improvements for a while. I am proud that we can take this time freely from any commercial constraints. The main problem is that this needs to be explained to users. Most likely, people want both recent versions and stability, which is just impossible. (and yes, these sort of issues happen in Ubuntu). Besides, I don't see the polemic with this "upload to unstable or experimental" issue. I get the impression that some developpers confuse their own comfort with the interest of the distribution somehow. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
Le Tuesday 16 December 2008 00:29:21 Didier Raboud, vous avez écrit : > > You can't get both recent *and* stabilized software. For a solid release > > to be done, one needs to hold new improvements for a while. > > Yes. But there is a bunch of non-DD people that strongly want to use Debian > and prefer the recent software over the stabilized one. With the new > laptops coming out every two weeks, having the latest kernel, Xorg or hal > is no caprice, it's needed… That is what I mean by comfort. We can't get everyone happy, and these days we're focused on getting the folks that use the stable distribution happy. Besides, most of these geek users should be likely to be able to sort out these issues themselves, not the opposite. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
Le Tuesday 16 December 2008 16:50:52 Adeodato Simó, vous avez écrit : > > Where did Steve shorten the discussion period? He did so for the *other* > > vote, but I haven't seen a thread where he did for this one. (I may have > > just missed it.) > > http://lists.debian.org/debian-vote/2008/11/msg00046.html, no? I don't read "shorten" in this link, only "start". Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
Le Tuesday 16 December 2008 16:52:55 Romain Beauxis, vous avez écrit : > > http://lists.debian.org/debian-vote/2008/11/msg00046.html, no? > > I don't read "shorten" in this link, only "start". Woops, sorry I misread "discussion" with "vote". The problem with this quote is that it was used to justify the shortening of the *voting* period too. This was already raised by Cyril. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
Le Tuesday 16 December 2008 14:55:29 Didier Raboud, vous avez écrit : > > I think that the three existing flavours of debian already provide more > > than is needed to offer comfort for both users with stability needs and > > users with desire for new software. > > Actually, I would agree if you consider the 4th flavour: experimental. > > Just to name some important ones which are only there: OpenOffice.org, > amarok, openjdk, vlc, wine, samba. The list is ever-growing (during the > freeze). > > Having the latest OO.o is more than confort… Honnestly, this discussion takes place at every freeze. First of all, you probably should propose such thing *after* the release, not now. Secondly, I'm still wondering what new arguments were brought here. For instance, if you want to do a serious proposal, you probably could come up with links to previous discussions on the topic, and explain how that changed and how your point differs from the point already mentioned in the previous discussions. Until then, I don't really see the point in discussing this... Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
Le Tuesday 16 December 2008 20:30:22 Thomas Viehmann, vous avez écrit : > But while you bring it up: I want a Debian where every Developer can > cough up a minimal commitment to help with releasing. That is what "Have > you fixed an RC bug today is about?". If all developers had fixed one RC > bug in the months that we have been frozen, we would have run out. > > The other way round works, too: Removing people who don't have that > minimal commitment from the project and their packages from the archive > would also allow us to release (a lot less) in a timely fashion. I think you completely forgot about the fact that this project is run by people who aren't payed for that. And, yes I didn't fix any RC bug today, nor yesterday. I even have now 3 on mediawiki for which I won't be able to take much time. And I won't explain my reasons, it is private for me. However the packages are open for any contribution. Maybe yours ? > Bastian's contributions have a theme of telling other people how to do > work that he does not want to do: What information they should want in > their bug reports, how to release, how negligent the assistant secretary > is and why he is even doing the secretary's, and now what to do with > unstable in the meantime (as other's have pointed out, not a new idea, > so the contribution is rehasing of the idea). To be honest, I'd prefer > if Bastian applied his skills to helping a project I'm not a member of. I don't agree with Bastian on his proposal but I would never express myself in that way. I won't fall into the easy agressive answer, but your attitude is clearly inapropriate. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Josselin Mouette and Planet Debian
Le Thursday 18 December 2008 13:04:24 Russell Coker, vous avez écrit : > The above article concerns the damage that Josselin's actions cause to the > Debian project. D-d-a is not that different from other parts of Debian, > bad behaviour in other forums also hurts the project. I have that feeling that you are using the project to express personal disagrement. Why don't you rephrase this using "I" instead of "the project" ? I had some strong discussions with Joss, but I would never support such proposition. By the way, this is yet another recursive trolling subject. I can probably start the discussion on "COPYING files are not DFSG" now :-) Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Josselin Mouette and Planet Debian
Le Thursday 18 December 2008 15:45:05 Michael Banck, vous avez écrit : > > I'd argue about that "official" thing that people have been using to > > qualify d-d-a. It's an announce list for developers, by > > developers. > > Wrong. While in /theory/ it might be for developers, in /practise/, > d-d-a is consumed by the public as a prime source of important > information regarding Debian besides debian-announce and debian-news. > The fact that Debian Developers are supposed ot read it does not mean > others do not, and there is not much we can do about this at this point. With this kind of sloppy argument, everything that anyone interested in Debian may read should be considered as "official", including the planet. I somehow don't really believe you are being right :) Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Josselin Mouette and Planet Debian
Le Thursday 18 December 2008 16:37:38 Johannes Wiedersich, vous avez écrit : > Julien BLACHE wrote: > > I'd argue about that "official" thing that people have been using to > > qualify d-d-a. It's an announce list for developers, by > > developers. I'm not sure what's official in there. I'd tend to say > > anything "official" is project communication, that effectively goes to > > debian-announce. > > d-d-a has 5700 subscribers [1] and is archived/mirrored around the > world. Non-developers by far outnumber developers in subscribing that > list. It doesn't really matter, if it's an 'officially endorsed' message > from the project or not, the point is it was an 'announcement' and it > was perceived as inappropriate (not only OT) by many. I fully disagree. If I say "I eat kittens at breakfast"(*) here or in planet.debian.org, how is it relevant to the project ? Even though it could be read by many and reproduced in a lot of places, the project never said it supports having kitten for breakfast, even though *some* developpers might actually say it. The question is not about what is said but about the scope of the communication. "official" has a meaning which is clear. It is the composition of an official position *and* an official communication channel. Any argument that blurs this distinction will only make the project less reliable and reduce the various opinions of people in the project, which means free speech. I *do* like when people express various points, including one that I do not agree with. And we don't want DDs to have all the same ideas, right ? Romain (*) The true answer to this question remains private :-P -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
