Re: Is it time to remove sun-java6?
Hi, On Fri, Oct 9, 2009 at 10:33 PM, Florian Weimer wrote: > * Gabor Gombas: > >> - start advertising that openjdk/icedtea is now supposed to be usable, > > Note that the non-applet stuff has been quite usable for a while. > Even the openjdk-6 in lenny is not too bad (it's certainly possible to > run various production loads on it). Last I checked (whatever ubuntu 9.04 used) there were still some major holes in the main class library. Problems where the behaviour of the API just wasn't right. I figured at the time openjdk was just still trailing in functionality and this wasn't supposed to be a full fledged java release. I guess I was wrong and should've bothered to report bugs, but it's definitely not a given that lack of reported bugs == release quality. Couldn't more be done to get users testing it first? regards, Wim -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550723: ITP: gjs -- Mozilla-based javascript bindings for the GNOME platform
Package: wnpp Severity: wishlist Owner: Gustavo Noronha Silva * Package name: gjs Version : 0.2 Upstream Author : Litl * URL : http://live.gnome.org/Gjs * License : MIT, with parts triple licensed under: GPL2+, LGPL2+, MPL1.1 Programming Lang: C Description : Mozilla-based javascript bindings for the GNOME platform Gjs is a Javascript binding for GNOME, that allows you to use all of GNOME's platform libraries using the Javascript language. It's mainly based on the Mozilla javascript engine and the GObject introspection framework. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#550542: ITP: jhdf -- Java HDF5 Object Package
On Mon, Oct 12, 2009 at 01:53:21PM +0900, Charles Plessy wrote: > Le Sun, Oct 11, 2009 at 12:08:35AM +0200, Sylvestre Ledru a écrit : > > > > 4. All publications or advertising materials mentioning features or use of > > this software must acknowledge that it was developed by the National > > Center for Supercomputing Applications at the University of Illinois, > > and > > credit the Contributors. > > Hi Sylvestre, > > note the potential danger of infringement of this clause, for instance if one > makes flyers for Debian Science live CDs that mention capacity to work with > the > HDF5 format. > > In the past, I managed to convince academic upstream authors of a program I > package to remove a similar clause, by referring to the following essay on the > FSF website: http://www.fsf.org/licensing/essays/bsd.html. Maybe you can give > it a try? > > Have a nice day, > Note that in hdf5tools (from the same source, HDF Group) the advertising clause is not mandatory. It could be something that would require an update on their side. Did you try to contact HDF group? -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processed: user needs help
Processing commands for cont...@bugs.debian.org: > reassign 544590 general Bug #544590 [powermanagement] Screen On Off Issue Warning: Unknown package 'powermanagement' Bug reassigned from package 'powermanagement' to 'general'. > -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550753: ITP: libinnate-ruby -- core web-framework part of Ramaze
Package: wnpp Severity: wishlist Owner: Sebastien Delafond * Package name: libinnate-ruby Version : 2009.07 Upstream Author : Michael Fellinger , Tadahiko Uehara , Pistos , Ryan Grove , Andreas Karlsson , TJ Vanderpoel , Sam Carr * URL : http://rubyforge.org/projects/innate * License : Ruby license Programming Lang: Ruby Description : core web-framework part of Ramaze Innate is the core web-framework part of Ramaze and can be used standalone, it features a small and concise code-base, extensive docs and specs, and full integration with Rack. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550754: ITP: obus -- pure OCaml implementation of DBus
Package: wnpp Severity: wishlist Owner: "Stéphane Glondu" * Package name: obus Version : 1.0~rc1 Upstream Author : Jérémie Dimino * URL : http://obus.forge.ocamlcore.org/ * License : BSD Programming Lang: OCaml Description : pure OCaml implementation of DBus OBus is a pure OCaml implementation of DBus. It aims to provide a clean and easy way for OCaml programmers to access and provide DBus services. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ITP: stockfish -- strong chess engine, to play chess against
> Package: wnpp > Owner: Oliver Korff > Severity: wishlist > * Package name: stockfish Hello Oliver, you are supposed to use X-Debbugs-CC and not CC so that the mail come with its bug number. This way I would be able to reply to the bug... > # snip > Why another chess engine? -- Why another editor? > Playing serious chess means also to analyze your own moves with the strongest > computer program currently available. Strength here is a relative > impression of the user. We give him various possibilitys. I do not mind another chess engine, especially if it is a good one. However, packaging of UCI chess engines should be improved with respect to polyglot so that merely doing 'polyglot stockfish' work. The chess engine would install a correct stockfish.ini file in /usr/share/polyglot/engines/ and polyglot would be configured to look there by default. In lenny (I did not try sid), you have to look in /usr/share/doc/foo for a foo.ini file which is often not compatible with current polyglot and need to be fixed... Using xboard or scid with a chess engine should be simple, not hard. Cheers, Bill. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550772: ITP: libmoosex-compiletime-traits-perl -- Perl module to allow role application at compile-time
Package: wnpp Owner: Jonathan Yu Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libmoosex-compiletime-traits-perl Version : 0.092801 Upstream Author : Nicholas Perez * URL : http://search.cpan.org/dist/MooseX-CompileTime-Traits/ * License : Artistic | GPL-1+ Programming Lang: Perl Description : Perl module to allow role application at compile-time MooseX::CompileTime::Traits is a Perl module that allows role application at compile time via use statements. What this class does is provide an import method that will apply each of the roles (along with any arguments for parameterized roles). NOTE: This module is needed for the new version of POEx::Role::SessionInstantiation -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Permissions of /var/mail/$USER
Russell Coker coker.com.au> writes: > > On Sunday 11 October 2009 23:49:22 Nicolas François wrote: > > IIRC, it was a problem for the support of shared mailboxes. > > Index files are created whose permissions mimic the mailbox' permissions. > > The 'mail' group ownership would require dovecot to be in the mail group. > > Why? > > For Dovecot to access files mode 0600 owned by various users it must run as > root (at least initially), in that case it can access all files. > > The only reason why mode 0660 would be a problem is if Dovecot changes to the > GID and UID of the user before such access and can't be configured to use the > GID of mail instead. This seems to be a bug (or at least a missing feature) > in Dovecot. > > I'm all in favor of making access control more strict, so I support mode 0600 > mail files. > > But what you are saying about Dovecot is not a valid reason IMHO. > > Also as an aside I think it's a bad idea for a program like Dovecot to create > index files in /var/mail. I believe it should be in /var/lib/dovecot or > similar. /var/mail is used by many programs and I believe that it should not > have any files other than the mboxes. If you are using mboxes, the index files will be in /var/mail/.imap/ by default. For maildirs, ~/Maildir/.imap I think these are reasonable defaults for the package but if it is needed you can change the location via the mail_location setting in /etc/dovecot/dovecot.conf (see /usr/share/doc/dovecotcommon/wiki/MailLocation.txt.gz for details.) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Experimental queue?
The package MLton is a Standard ML compiler which is itself written in Standard ML. To bootstrap the package building process on a new architecture requires an initial by-hand cross-compile step (and occasionally some source-level patching). Thus, the first upload for a new architecture must be a manual upload of a built-by-hand package. Thereafter I need to confirm that the autobuilders can build subsequent uploads themselves. I intend to bootstrap a few more architectures for this package and wanted to know if this would be an appropriate use for the experimental upload queue. The intermediate packages are probably more unstable than what one expects even from the unstable queue. I was hoping I could get some information about the experimental upload queue as I have never used it: * Do the autobuilders build packages uploaded as experimental? (eg: to confirm a successful port) * Is making an unstable upload really as easy as setting the changes file to experimental? * Can a package uploaded to experimental be migrated to unstable? * I definitely don't want this happen automatically * At some point I probably want to push the newest versions from experimental to unstable (to facilitate building the new architectures) and then upload a new 'final' version that gets autobuilt for all the new targets, landing in unstable. Finally, how can I determine which debian autobuilders have >1GB of RAM (required for a successful build). Advice greatly appreciated.
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#550804: ITP: libdbix-class-cursor-cached-perl -- cursor object with built-in caching support
Package: wnpp Owner: Jonathan Yu Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libdbix-class-cursor-cached-perl Version : 1.0.1 Upstream Author : Matt S Trout * URL : http://search.cpan.org/dist/DBIx-Class-Cursor-Cached/ * License : Artistic | GPL-1+ Programming Lang: Perl Description : cursor object with built-in caching support DBIx::Class::Cursor::Cached is a Perl module providing a cursor class with built-in caching support. It allows for traversal of an arbitrary result set using "next", retrieving all results with "all" and resetting the cursor with "reset." Moreover, it caches your results to increase speed. NOTE: this is needed for updating catalyst-modules, as Catalyst-Model-DBI needs it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
