Re: trasferimento di debian.it
In data martedì 30 giugno 2009 09:48:48, Marco Bertorello ha scritto: Il giorno 30 giugno 2009 04.50, Luca Brivioluca...@infinito.it ha scritto: - un qualche elemento grafico che faccia capire che si tratta di una pagina specifica per l'Italia; abbiamo il logo italiano (es. http://bertorello.ns0.it/favicon.ico sicuramente se ne trovano versioni migliori) In realtà credo che sia meglio usare il logo solito (quello ufficiale di libero utilizzo) per rimanere all'interno del progetto Debian, comunque è un'idea, come ce ne possono essere altre... -- Luca -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-devel-italian-requ...@lists.debian.org con oggetto unsubscribe. Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-devel-italian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: 18 Giugno - Milano - Scienze politiche
In data lunedì 27 aprile 2009 12:42:11, giskard ha scritto: Il 18 giugno alla facolta' di scienze politiche alcuni partecipanti di hackmeeting in collaborazione con il professor Adam Ardvisson vorrebbero organizzare alcune presentazioni sul tema p2p economies. Con questo incontro si vorrebbe permettere ad alcune esperienze comunitarie come Debian di proporre il proprio modello organizzativo e di produzione. Per questa ragione vorrei sapere se c'e' qualcuno in lista interessato a presentare il modello comunitario di Debian in modo da offrire un esempio a chi partecipera' all'incontro. Ciao giskard, al limite lo potrei fare io, però è meglio se vieni anche tu o qualche altro DD, di certe cose non posso avere esperienza diretta. -- Luca -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-devel-italian-requ...@lists.debian.org con oggetto unsubscribe. Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-devel-italian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: mass ITPs
Alle 19:48, sab 1 marzo 2008, Christian Perrier ha scritto: 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. Just some thoughts: - ITPing doesn't of course mean being packaging. One can have low priority on an ITP, and even when, once started, one finds that software isn't worth it, she can decide not to package it anymore... - Helping with packages almost always requires more skills than packaging simple new ones, which OTOH is good for learning. - Yeah, at least one should package use- and featureful stuff! Anyway I don't see *that* much ITPs for actually “unuseful” software, relative to how much software enters Debian... - There's no big evidence about where exactly help is needed! -- Luca
(user)tagging wnpp bugs
Hello folks, following a short discussion with Erich Schubert on the debtags-devel list[1], I decided to come with a simple proposal (are DEPs already active and useful?). In order to have wnpp bugs better categorized (and, as such, searched, shown, and managed), it seems a viable option to use (abuse?) faceted usertags, like somebody from the Debian Science subproject already does[2][3]. These tags could be collected using wiki pages, and should IMHO mostly match debtags' ones (that would enable using them when entering debtags). Of course, using just one ‘login’ for categorizing wnpp tags looks way more useful than having several teams each using a different one. Any comments? What ‘user’ should we use? If nothing against comes up, I'm going to use such usertags as [EMAIL PROTECTED] and report (lots of) RFPs (and possibly some ITP!) for fields I am interested in. [1] http://lists.alioth.debian.org/pipermail/debtags-devel/2008-February/001764.html [2] http://wiki.debian.org/DebianScience/Usertags [3] http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED] Cheers, -- Luca
Re: (user)tagging wnpp bugs
Thank you for your feedback... Alle 21:41, sab 1 marzo 2008, Don Armstrong ha scritto: If nothing against comes up, I'm going to use such usertags as [EMAIL PROTECTED] and report (lots of) RFPs (and possibly some ITP!) for fields I am interested in. I'd suggest just picking a reasonable subset of the tags I shall see, didn't even quickly screened for applicable tags, anyway I guess they will be a subset of debtags + a few wnpp-specific tags. We haven't yet created a wiki page. and using the [EMAIL PROTECTED] user so the tags are visible by default. I wasn't aware of this. It's fine to me. [Well, after testing using your own user, of course.] or maybe using [EMAIL PROTECTED] again. ;-) Cheers, -- Luca -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#465660: ITP: extreme-tuxracer -- Arcade game featuring tux the penguin, snow ice and fishes
Alle 11:34, gio 14 febbraio 2008, Alexander Schmehl ha scritto: * Christian Perrier [EMAIL PROTECTED] [080214 06:54]: Description : Arcade game featuring tux the penguin, snow ice and fishes At least uncapitalize Arcade. At least? You have further improvements? Sounds 3D racing game featuring Tux, the Linux penguin better for you? Maybe e.g. make Tux the penguin slide down mountains and collect fishes? (Tags: game::arcade, interface::3d, and perhaps game::sport:racing should apply, among others.) -- Luca -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DOAP files
mer 26 dicembre 2007, Stefano Zacchiroli ha scritto: I see two ways of serving it that seem to me much more useful: provide a centralized, archive-wide place, where we serve all the DOAPs of Debian packages. The more obvious places to me seem packages.d.o and/or the PTS. BTW, I don't know what's with the Collaborative Repository of Meta-Informations[1]. Maybe Raphael can provide some useful insights to the debate. [1] http://wiki.debian.org/CRMI Cheers, -- Luca -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
DOAP files
Hi developers, While I'm packaging morla[1], I've found in the tarball tree a little XML file named doap.rdf, which turned out to be a DOAP[2][3] file. An apt-file query (on 'sid', i386) showed me that there are at least three packages which install such files: flumotion: usr/share/doc/flumotion/flumotion.doap.gz mach: usr/share/doc/mach/mach.doap.gz python-gst0.10: usr/share/doc/python-gst0.10/gst-python.doap I haven't be found any quick way to search the Debian source archive for file names, but Google Code Search provided[4] me with a rough estimate of how many DOAP files are around there, in tarballs and VCSs. There are several dozens; what's most noteworthy, some of them belong to non-aforementioned softwares included in Debian. Sadly enough, they appear to have very loose conventions about naming (with respect to contents, at least a validator[5] exists, although currently only for any «pure DOAP, not DOAP in an RDF container»). Now, DOAP is of course an interesting thing from the semantic web. The Apache Software Foundation supports[6] it. An ITP bug[7] has been filed for moap[8], a project maintenance tool using DOAP files. There are DOAP generators[9], maybe some converters, and so on. Info in these files are kind of like those which one may find on e.g. Freshmeat about projects. doapspace.org[10] collects DOAP entries, mostly generated from Sourceforge updates... So, I don't know how these files might be useful (as sources for information on upstream projects, I guess). Anyway, I have some questions I'd like to see answered, so I may do a better job (as a prospective maintainer). 1) Should we include DOAP files from upstream in packages? (always?) 2) If so, where? (usr/share/doc sounds OK if they are only provided for sake of completeness, while IMVHO if we want them to be globally parsed and/or indexed it would be good to have an ad-hoc hierarchy under e.g. usr/share/doap) 3) (related to the above question) Should they have uniform names? If so, in what form? Should we distinguish between pure DOAP and «DOAP in an RDF container»? I know you will enlighten me. :-) Thanks. [1] http://www.morlardf.net [2] http://usefulinc.com/doap/ [3] http://en.wikipedia.org/wiki/DOAP [4] http://www.google.com/codesearch?q=file%3A%28doap.rdf%7Cdoap.xml%7Cdoap%24%29 [5] http://doapspace.org/validate_form [6] http://projects.apache.org/doap.html [7] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422660 [8] https://thomas.apestaart.org/moap/trac [9] http://crschmidt.net/semweb/doapamatic/ [10] http://doapspace.org Regards, -- Luca
Software italiani non internazionalizzati, con sito web solo in italiano, etc.
Salve gente. Ieri ho creato una pagina [1] sul wiki di Debian per un elenco di software libero il cui sito web o la cui documentazione e/o interfaccia è in tutto o in parte disponibile soltanto in italiano (o comunque non in inglese), suddiviso per sezione. L'intento è molteplice: - fare venire più persone a conoscenza di software interessante; - coadiuvare la pacchettizzazione di software «non internazionalizzato»; - espandere in qualche caso la fruibilità di software che allo stato attuale è utile solo o precipuamente per chi sta in Italia o capisce l'italiano. - (eventualmente) contribuire alla creazione di un repository per software utile solo in Italia, magari «ingombrante» per l'archivio, per cui sarebbe uno sforzo inutile l'internazionalizzazione... - etc. Editare il wiki è molto semplice, invito chiunque conosca del software (possibilmente libero, eventualmente anche freeware se particolarmente interessante) del tipo che ho citato ad inserirlo nella pagina, eventualmente creando nuove sezioni. Dato che spesso non è disponibile una descrizione «lunga» in inglese, invito chi ha la capacità e il tempo per farlo a creare (magari semplicemente traducendo qualcosa di già esistente) e linkare una pagina del tipo http://wiki.debian.org/PkgItalianOnly/$NOME_SOFTWARE. Ovviamente accetto anche obiezioni e critiche, purché commisurate alla modesta portata del mio lavoro. ;-) [1] http://wiki.debian.org/PkgItalianOnly/ -- Luca
Bug#452422: RFP: yacy -- distributed web crawler and search engine
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: yacy Version : 0.55 Upstream Author : Michael Christen [EMAIL PROTECTED] * URL : http://yacy.net * License : GPL Programming Lang: Java Description : distributed web crawler and search engine YaCy is a scalable personal web crawler and web search engine. One YaCy installation can organize more than 10 million documents, but YaCy can operate search clusters of unlimited size. YaCy has a peer-to-peer web index exchange interface and it does not need a central server. Web crawls can be done collaborative with all other YaCy peers. Resulting indexes are organized in a distributed hash table, and search requests are pointed efficiently to specific, index-hosting peers. YaCy can not only index texts from various file formats but also from different media contents. A search result shows interesting text, image, audio and video content with direct links to OGG, MP3, and video files. Because YaCy is fully distributed, search results cannot be completely censored, only filtered by single peer owners. However, in a privatly operated search network the software provides a strong functionality to control the content of the search cluster. In a public search network, a user is anonymous because there is no central point where all search requests can be stored. YaCy has a large number of users running their own peer to create a independent and open search engine. The standard YaCy release is configured in such a way that the software joins this public network. The software has a number of community function like a co-operative bookmark system, a news, blog and built-in wiki system. -- Luca Brivio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deb-ice -- violating the GPL since 2007-08-14
Hi, ven 31 agosto 2007, Robert Edmonds ha scritto: [...] The aggregator needs to either immediately stop distributing this ISO or provide source code for the components that require source code and clarify that the entire work is not under a single GPL license. I believe -legal and perhaps -project to be the right mailing lists for this. -- Luca -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Debian Packaging Handbook project mailing list
Hi all, A few days ago Davide Truffa and I opened a mailing list[1] on Alioth, which will be used for the purpose of coordinating the writing and proofreading (hence Cc:ing the l10n-english list) of the packaging handbook[2]. I'd invite anybody which may be interested to subscribe. I'm also looking for a way to have all feeds for changes in the wiki pages sent through the list[3]. There has not been a lot of activity in the past weeks, but the TODO list is getting longer and we're going to put down several points and maybe have an IRC booth too, so stay tuned! [1] [EMAIL PROTECTED] (http://lists.alioth.debian.org/mailman/listinfo/packaging-handbook-project) [2] http://wiki.debian.org/DebianPackagingHandbook [3] see http://lists.debian.org/debian-www/2007/08/msg00145.html and thread (please answer there if you can provide any idea or support!) Cheers, -- Luca -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Packaging Handbook project
Alle mer 15 agosto 2007, martin f krafft ha scritto: also sprach Manoj Srivastava [EMAIL PROTECTED] [2007.08.10.1746 +0200]: Martin Krafft and I jointly gave a talk at Debconf about use of distributed version control systems for Debian packages (this is the quilt/dpatch/other dimension); I would be happy to help documenting that aspect. And I would be happy to contribute to any Debian Packaging Handbook effort, though I can't really write much these days. But I am always up for a chat, live, on IRC, via Email, or on the phone. Manoj and Martin, thank you. :-) I also can't write much by myself, just because my knowledge is so little, but I'm willing to contribute by now in several ways to such efforts (ATM, in my little spare time). Manoj, please don't hesitate to edit that wiki page (and, at your choice, create new pages!). BTW, does anybody have any concerns about the licensing? -- Luca Brivio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Packaging Handbook project
Alle mer 8 agosto 2007, Manoj Srivastava ha scritto: The goal is from my POV to produce something much more complete and with a different scope: while the NMG etc. are (roughly) tutorials targeted to people who want to make their first packages etc., the DPH would be a rich manual for all those who maintain packages. All of us who maintain packages? Now, this is interesting, since there are several styles of package build systems out there (cdbs, yada, debhelper,plain); and even withing these are sub-genres (dpatch, quilt,integration/feature-branches). Is the goal then to include all possible manuals for all the styles extant? Or are you going to go for one preferred style (or a few preferred styles) and stick to that? Thanks for pointing at this. :) Indeed, it looks at me that one of most exciting and challenging goals would be to outline (and hence describe in a detailed manner) all of the different existing styles and compare them after several points of view, so that one can choose her/his preferred style based upon which she/he believe to better fit to her/his needs, rather than just the first they suggested her/him or that with the best documentation available or something alike. I think this would be also useful for mentoring. -- Luca Brivio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Packaging Handbook project
Alle mer 8 agosto 2007, Luca Capello ha scritto: Hello! On Wed, 08 Aug 2007 07:27:14 +0200, Lars Wirzenius wrote: One step might be to convert the New Maintainer's Guide into the wiki format, then importing any missing information from the Debian Developers' Reference to it. Putting it all in the wiki is good, so that it is more easily editable by everone, thereby hopefully keeping things up to date at all times. I'd still like to have something downloadable, because when I need to check the documentation I'm not always online. This probably means that the wiki pages should be included in the existing maint-guide. I agree with you. AFAIK, MoinMoin allow to export into DocBook, so it should be not too hard to make snaphots and include them in that package, after some checks. -- Luca Brivio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Packaging Handbook project
Alle mer 8 agosto 2007, Lars Wirzenius ha scritto: On ke, 2007-08-08 at 14:12 +1000, Ben Finney wrote: Without that structure, and a strict policy of being *only* an index to existing documents, I don't see how this project would avoid creating yet-another-document to read, compounding the problem you initially described. I think it makes sense to start with an annotated link list, since that's a good way to make it quite useful very quickly, and then to expand it over time with original content, with the intent of replacing most other documents. As I see it, the wiki-based Handbook plus the Policy Manual (including sub-policies) should be enough. This make sense to me. These two documents should be enough. Sub-policies that don't fit the Policy Manual should be included (at least at a first stage) in the wiki-based handbook. Furthermore, the New Maintainers' Guide should remain as a simple tutorial, yet the official one. -- Luca Brivio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Packaging Handbook project
Alle mer 8 agosto 2007, Ben Finney ha scritto: Thanks for taking the initiative to do this work. Thanks for your attention. At this moment, we have the New Maintainers' Guide and a bunch of other more or less good tutorials, anyway when one wants to make an even simple package she/he often have to look at dozens of guides, tutorials, manpages, manuals etc. and not infrequently this will not be enough. Is the goal to replace those documents, or make them unnecessary for the developer to read? Or, rather, is it meant to be an index to the documentation that does exist? The goal is from my POV to produce something much more complete and with a different scope: while the NMG etc. are (roughly) tutorials targeted to people who want to make their first packages etc., the DPH would be a rich manual for all those who maintain packages. What I can see being valuable is a document with the clearly stated purpose of pointing thhe reader to *other* documents, so that it doesn't take on the task of duplicating existing documents. That way, if someone starts to document some aspect of the procedure, it would clearly necessitate the creation of a new document for that, or the inclusion of that material into some other existing document. Without that structure, and a strict policy of being *only* an index to existing documents, I don't see how this project would avoid creating yet-another-document to read, compounding the problem you initially described. One of the biggest problems we experienced is that the existing documentation, albeit useful and rather rich, is not coherent. I think we need something more homogeneous, backed by an overall design. This would not be yet-another-document to read, instead would substitute many other small (often out-of-date or contradictory) documents about major and minor topics. The idea is that one might maintain packages without having a lot of documents around all the time, just with a big manual which links to other documents only for reference. It seems likely that most of this manual already exists, and could be put together, edited, expanded and integrated with the permissions of its authors, or thanks to its licensing. One of main goals is to have a truly organic documentation. I don't know if such a project deserves to be official, however I wish to try to make it work, and see how it might work. -- Luca Brivio -- Per REVOCARE l'iscrizione alla lista, inviare un email a [EMAIL PROTECTED] con oggetto unsubscribe. Per problemi inviare un email in INGLESE a [EMAIL PROTECTED] To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Packaging Handbook project
Alle mer 8 agosto 2007, Ben Finney ha scritto: Thanks for taking the initiative to do this work. Thanks for your attention. At this moment, we have the New Maintainers' Guide and a bunch of other more or less good tutorials, anyway when one wants to make an even simple package she/he often have to look at dozens of guides, tutorials, manpages, manuals etc. and not infrequently this will not be enough. Is the goal to replace those documents, or make them unnecessary for the developer to read? Or, rather, is it meant to be an index to the documentation that does exist? The goal is from my POV to produce something much more complete and with a different scope: while the NMG etc. are (roughly) tutorials targeted to people who want to make their first packages etc., the DPH would be a rich manual for all those who maintain packages. What I can see being valuable is a document with the clearly stated purpose of pointing thhe reader to *other* documents, so that it doesn't take on the task of duplicating existing documents. That way, if someone starts to document some aspect of the procedure, it would clearly necessitate the creation of a new document for that, or the inclusion of that material into some other existing document. Without that structure, and a strict policy of being *only* an index to existing documents, I don't see how this project would avoid creating yet-another-document to read, compounding the problem you initially described. One of the biggest problems we experienced is that the existing documentation, albeit useful and rather rich, is not coherent. I think we need something more homogeneous, backed by an overall design. This would not be yet-another-document to read, instead would substitute many other small (often out-of-date or contradictory) documents about major and minor topics. The idea is that one might maintain packages without having a lot of documents around all the time, just with a big manual which links to other documents only for reference. It seems likely that most of this manual already exists, and could be put together, edited, expanded and integrated with the permissions of its authors, or thanks to its licensing. One of main goals is to have a truly organic documentation. I don't know if such a project deserves to be official, however I wish to try to make it work, and see how it might work. -- Luca Brivio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434029: ITP: qfsm -- A graphical tool for designing finite state machines
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- * Package name: qfsm Version : 0.44 Upstream Author : Stefan Duffner [EMAIL PROTECTED] * URL : http://qfsm.sourceforge.net * License : GPL Description : A graphical tool for designing finite state machines Qfsm is a graphical editor for finite state machines written in C++ using Qt. Finite state machines are a model to describe complex objects or systems in terms of the states they may be in. In practice they can used to design integrated circuits or to create regular expressions, scanners or other program code. Current features of Qfsm are: - Drawing, editing and printing of diagrams - Binary, ASCII and free text condition codes - Multiple windows - Integrity check - Interactive simulation - AHDL/VHDL/Verilog HDL/KISS export - State table export in Latex, HTML and plain text format - Ragel file export (used for C/C++, Java or Ruby code generation) -- Luca Brivio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431824: ITP: morla -- GTK+ RDF editor
Package: wnpp Severity: wishlist Owner: Luca Brivio [EMAIL PROTECTED] * Package name: morla Version : 0.12 Upstream Author : Andrea Marchesini [EMAIL PROTECTED] * URL : http://www.morlardf.net/ * License : GPL v2 Programming Lang: C Description : GTK+ RDF editor Morla is a multiplatform editor of RDF documents. It is based on libnxml and librdf libraries. With Morla you can manage more RDF documents simultaneously, visualize graphs, use templates for quick writing and exec SPARQL/RDQL queries. With Morla you can import RDFS documents and use their content to write new RDF triples. Templates are also RDF documents, and they make Morla easily customizable and expandable. You can use Javascript code into your templates so so you can validate and change user inputs. Morla is also a modular software so you can add functionality about the save, open and view procedures. You can also use Morla as an RDF navigator, wandering among the net knots of the RDF documents present on internet exactly as we are used to do with web browsers. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED] Package
Alle venerdì 22 giugno 2007, Zachary Palmer ha scritto: Hello, all. It has been my understanding that the reason that the [EMAIL PROTECTED] distributed computing software has not been made a Debian package is that the license under which it is released does not allow it to be free. No, it's that the license does not allow it to be re-distributed: Distribution of this software is prohibited. It may only be obtained by downloading from Stanford's web site (http://folding.stanford.edu and pages linked therein). while often other pieces of software that allow to be distributed (and thereon packaged) do enter the non-free section. This software package has pretty much the best reason for being closed source that I've encountered; they want to prevent falsified results from damaging the research. Anyway this might likely not be enough for their purpose. :-( Am I wrong, right? BTW, I would encourage them to (co-)maintain an unofficial Debian package with that software inside. And will people use it if I bother? Less than 0.02% seems to have kfolding installed [1]. But I think a lot more people have (and run) the [EMAIL PROTECTED] client, and even more would do if such a package were provided. Thanks! Thank you. [1] source: http://popcon.debian.org/ -- Luca
Re: Bug#428198: ITP: gabedit -- graphical interface to Ab Initio packages
Daniel Leidert wrote: Gabedit is a graphical user interface to computational chemistry packages, like: - GAMESS-US - Gaussian - Molcas - Molpro - MPQC - Q-Chem Maybe the fact that MPQC is the only one which is free and already in Debian (so that this package will go in the main section) could be worth some highlighting (e.g. Gabedit is a graphical user interface to MPQC and to following proprietary/commercial software: [...], maybe also append like MPQC to the short description and make it Recommends: the latter). After all, Debian is about software freedom. :-) -- Luca Brivio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#425952: ITP: emacs-rails -- Emacs minor-mode for developing RubyOnRails applications
Alle venerdì 25 maggio 2007, Jan Michael Alonzo wrote: Package: wnpp Severity: wishlist Owner: Jan Michael Alonzo [EMAIL PROTECTED] * Package name: emacs-rails Version : 0.5.99.5 Upstream Author : Emacs Rails Team * URL : http://rubyforge.org/projects/emacs-rails/ * License : GPL Programming Lang: Ruby Description : Emacs minor-mode for developing RubyOnRails applications I think this should be merged with #418558 (RFP: rails-el -- minor mode for editing RubyOnRails code in Emacs). Thanks. -- Luca Brivio
Re: Bug#419951: ITP: jexcelapi -- Java API to read, write and modify Excel spreadsheets
Alle 01:37, giovedì 19 aprile 2007, Torsten Werner ha scritto: Description : Java API to read, write and modify Excel spreadsheets The Java Excel API is an open source Java API which allows Java developers to read Excel spreadsheets and to generate Excel spreadsheets dynamically. (Sorry if this is boring) I think that at least in the long description it would be wise to fully qualify Excel spreadsheets, because there's no actual standard about them (Microsoft's as I guess? If so, either .xls or ECMA's OpenXML? Which version?). Thanks, -- Luca Brivio
Re: hunting for Linux developer
Alle 14:05, sabato 7 aprile 2007, [EMAIL PROTECTED] ha scritto: Hi everyone, *Wanted* Linux Developer I guess debian-jobs@lists.debian.org is more appropriate for this. Thanks. -- Luca Brivio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian rocks!
Il giorno Mon, 05 Feb 2007 10:34:10 -0200 Bruno Buys [EMAIL PROTECTED] ha scritto: skipped tasksel completely That's bad! No idea about related efforts, but I guess one day tasksel will not be for unexperienced users only. So, for now I can only thank the project for such a solid system. In the future, when I will be wealthier, I hope to donate regularly. Good work is being done, I must thank all developers. -- Luca Brivio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On Sun, 18 Dec 2005 15:02:55 +0100 Steinar H. Gunderson [EMAIL PROTECTED] wrote: Not to mention that a DVD-R can fit about three million times as much data as a floppy disk, which was the dominant way of distributing software at the time. We can continue keep playing these number games, but I don't really see the point :-) Anyway, ~ 3 000 times, not ~ 3 000 000 times, sadly! -- Luca Brivio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: un pensiero sul libro di Martin Kraft
On Wed, 20 Jul 2005 10:24:32 +0200 Samuele Giovanni Tonon [EMAIL PROTECTED] wrote: Io non condivido la tua opinione, ma sono pronto a dare la vita perchè tu possa esprimerla Il tizio sarebbe Voltaire, che però non era sempre tanto coerente... Comunque non ho avuto la stessa impressione di Mauro. Tra l'altro si parlava di scelte fatte in base alle leggi vigenti e non di leggi da fare... -- Luca Brivio Web:http://icebrook.altervista.org Jabber: [EMAIL PROTECTED] pgptaD82UaJ5Y.pgp Description: PGP signature
Re: notizie su Il giovane hacker e la piccola strega di Luigi e Filippo Calcerano (Principato)
On Tue, 5 Jul 2005 17:06:24 +0200 Luigi Calcerano [EMAIL PROTECTED] wrote: Si trasmette l'unito file con una recensione GIA' PUBBLICATA come notizia sul libro per ragazzi in oggetto che contamina fantasciena e fantasy L.C. Magari l'hai fatto in buona fede, ma c'è chi potrebbeimbufalirsi per un messaggio del genere... 1. Non si mandano messaggi *pubblicitari* su una lista per sviluppatori! Al massimo la potevi mandare su debian-italian, specificando comunque nell'oggetto OT. Ci sono comunque decine e decine di mailing list più adatte e con molta partecipazione (vedi quelle dei LUG, ad esempio) dove non sarebbe sgradito un piccolo messaggio anche di questo tipo. 2. Che poi non è affatto un piccolo messaggio! In 32 KB ci potrebbe stare un capitolo di libro. A parte la risposta di Filippo http://lists.debian.org/debian-devel-italian/2005/07/msg6.html che ti vuole fare notare come sia pressoché sempre inopportuno mandare allegati in Word, ti faccio notare che i file DOC sono molto grossi... 3. ...e molto più grossi del necessario sono messaggi in HTML come il tuo, che per chi utilizza client testuali potrebbero peraltro risultare illeggibili. Dato che non ti serve alcun tipo di formattazione HTML per messaggi come questo, imposta almeno il tuo outlook perché mandi per default messaggi in solo testo. Grazie per la lettura, e scusa se sembriamo secchi ma queste sono liste dove ci si vuole capire al volo senza scrivere troppo. -- Luca Brivio Web:http://icebrook.altervista.org Jabber: [EMAIL PROTECTED] Diciamo no ai brevetti software in Europa! Perché? http://www.nosoftwarepatents.com/it/m/intro/index.html No software patents in EU! Why? http://www.nosoftwarepatents.com/ pgp6fwdDE6ZQQ.pgp Description: PGP signature
Re: notizie su Il giovane hacker e la piccola strega di Luigi e Filippo Calcerano (Principato)
On Tue, 5 Jul 2005 18:26:01 +0200 Marco Bertorello [EMAIL PROTECTED] wrote: Al massimo la potevi mandare su debian-italian, No, grazie... di spazzatura ne arriva già a sufficenza :-) Eheh hai anche ragione, ma se proprio lui e il figlio sono così affezionati agli utenti Debian... ;-)) -- Luca Brivio Web:http://icebrook.altervista.org Jabber: [EMAIL PROTECTED] Diciamo no ai brevetti software in Europa! Perché? http://www.nosoftwarepatents.com/it/m/intro/index.html No software patents in EU! Why? http://www.nosoftwarepatents.com/
Re: un pensiero sul libro di Martin Kraft
On Wed, 29 Jun 2005 18:34:09 +0200 [EMAIL PROTECTED] (Marco d'Itri) wrote: On Jun 29, Marco Bertorello [EMAIL PROTECTED] wrote: Non sindacavo su questo aspetto, semplicemente anche a me risultava che tutti i diritti riservati escludesse il prestito. E sbagliate tutti e due. Infatti. Tutti i diritti riservati credo significhi semplicemente che nella misura del lecito l'autore e/o editore si riserva di stabilire in un qualsiasi dato momento quali diritti concedere a terzi sul libro. Mi sbaglio? E comunque non mi risulta che si possa proibire il prestito a titolo gratuito. Sarebbe come se l'azienda produttrice di un cuscino mi potesse proibire di lasciarlo usare a chi mi dorme a fianco... Egualmente assurdo. O no? -- Luca Brivio Web:http://icebrook.altervista.org Jabber: [EMAIL PROTECTED] Diciamo no ai brevetti software in Europa! Perché? http://www.nosoftwarepatents.com/it/m/intro/index.html No software patents in EU! Why? http://www.nosoftwarepatents.com/ pgpakZEQIib2C.pgp Description: PGP signature
