Bug#681751: ITP: situs -- Modeling of atomic resolution structures into low-resolution density maps
Package: wnpp Severity: wishlist Owner: "Mickaël Canévet" * Package name: situs Version : 2.7.2 Upstream Author : Willy Wriggers * URL : http://situs.biomachina.org/ * License : GPL Programming Lang: C, C++ Description : Modeling of atomic resolution structures into low- resolution density maps -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120716073147.14415.30565.report...@pc437.embl.fr
Re: Multilicense `debian/copyright` file
On 14/07/12 07:25, Craig Small wrote: > Have a look at src/dataset/unsigned.Set.cc: > > [...] you can redistribute it and/or modify it under the terms of > the GNU Library General Public License [...] > > I have no idea why they have parts of the C library in the source code. The extra permissions given by the LGPL aren't directly relevant to non-libraries, but it's sometimes still useful to release non-library source under LGPL, because if you do, it's possible to copy it into an LGPL library later without getting permission from every copyright holder to change the license. The Telepathy project releases some applications under the LGPL, so that we can prototype future library modules in the first application that will use them, then copy them into our C library (also LGPL) after their API/ABI becomes stable. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50044c86.4080...@debian.org
Re: Using FreeDesktop MIME entries directly in mime-support (Re: Fixing the mime horror ini Debian).
Charles Plessy (16/07/2012): > If nobody else volunteers, I propose to start a maintenance group for > the mime-support package, that I would store in a Git repository on > Alioth's collab-maint group. I think that's a perfect use case for collab-maint. László, do you really need a dedicated group for that? Mraw, KiBi. signature.asc Description: Digital signature
Re: Using FreeDesktop MIME entries directly in mime-support (Re: Fixing the mime horror ini Debian).
Laszlo Boszormenyi (GCS) (16/07/2012): > > I think that's a perfect use case for collab-maint. László, do you > > really need a dedicated group for that? > My intention was to limit people who can commit to mime-support. It > seems there are multiple viewpoints for example about > application/x-httpd-* types. One may do more harm with a commit if not > consulted by a group of more advanced people. But I'm fine with normal > collab-maint as well if you and Charles would like that. As someone processing alioth-related requests, I would find it nice to use collab-maint for such projects; but I'm willing to hear about arguments against that. As a random developer, I would really hate to see people fight through commits. In case that would happen, I think that can be fixed, IIRC collab-maint has some abuse clauses or something similar. (IOW: I'm not convinced you need a dedicated group; quite the contrary.) Mraw, KiBi. signature.asc Description: Digital signature
Re: Using FreeDesktop MIME entries directly in mime-support (Re: Fixing the mime horror ini Debian).
Hi Cyril, On Mon, 2012-07-16 at 22:49 +0200, Cyril Brulebois wrote: > Charles Plessy (16/07/2012): > > If nobody else volunteers, I propose to start a maintenance group for > > the mime-support package, that I would store in a Git repository on > > Alioth's collab-maint group. Just for the record, Charles has an advanced knowledge regarding MIME in general. Hope we can work together. > I think that's a perfect use case for collab-maint. > László, do you really need a dedicated group for that? My intention was to limit people who can commit to mime-support. It seems there are multiple viewpoints for example about application/x-httpd-* types. One may do more harm with a commit if not consulted by a group of more advanced people. But I'm fine with normal collab-maint as well if you and Charles would like that. Cheers, Laszlo/GCS signature.asc Description: This is a digitally signed message part
Re: Using FreeDesktop MIME entries directly in mime-support (Re: Fixing the mime horror ini Debian).
On Mon, 2012-07-16 at 23:35 +0200, Cyril Brulebois wrote: > Laszlo Boszormenyi (GCS) (16/07/2012): > > My intention was to limit people who can commit to mime-support. It > > seems there are multiple viewpoints for example about > > application/x-httpd-* types. One may do more harm with a commit if not > > consulted by a group of more advanced people. But I'm fine with normal > > collab-maint as well if you and Charles would like that. > > As someone processing alioth-related requests, I would find it nice to > use collab-maint for such projects; but I'm willing to hear about > arguments against that. > > As a random developer, I would really hate to see people fight through > commits. In case that would happen, I think that can be fixed, IIRC > collab-maint has some abuse clauses or something similar. > > (IOW: I'm not convinced you need a dedicated group; quite the contrary.) I already wrote my reason and that a normal collab-maint place is fine with me. So I just need to login to git.debian.org and create a repository under /git/collab-maint/ right? Charles, I would add myself as Maintainer and you as an uploader or the vica-versa whichever suits you better. Is this OK with you? Regards, Laszlo/GCS signature.asc Description: This is a digitally signed message part
Collaborative maintenance of mime-support (was Re: Using FreeDesktop MIME entries directly in mime-support).
Le Mon, Jul 16, 2012 at 09:48:47PM +, Laszlo Boszormenyi (GCS) a écrit : > On Mon, 2012-07-16 at 23:35 +0200, Cyril Brulebois wrote: > > Laszlo Boszormenyi (GCS) (16/07/2012): > > > My intention was to limit people who can commit to mime-support. It > > > seems there are multiple viewpoints for example about > > > application/x-httpd-* types. One may do more harm with a commit if not > > > consulted by a group of more advanced people. But I'm fine with normal > > > collab-maint as well if you and Charles would like that. > > > > As someone processing alioth-related requests, I would find it nice to > > use collab-maint for such projects; but I'm willing to hear about > > arguments against that. > > > > As a random developer, I would really hate to see people fight through > > commits. In case that would happen, I think that can be fixed, IIRC > > collab-maint has some abuse clauses or something similar. > > > > (IOW: I'm not convinced you need a dedicated group; quite the contrary.) > I already wrote my reason and that a normal collab-maint place is fine > with me. So I just need to login to git.debian.org and create a > repository under /git/collab-maint/ right? > > Charles, I would add myself as Maintainer and you as an uploader or the > vica-versa whichever suits you better. Is this OK with you? Hi Laszlo and Brian, how about the following (inspired by http://dep.debian.net/deps/dep2/) Maintainer: mime-supp...@packages.debian.org Uploaders: Laszlo Boszormenyi (GCS) , Charles Plessy , I propose the following action plan. 0) We subscribe to the PTS (done for me). 1) Upload to experimental an adopted package with the updated maintainer and uploaders list, the VCS fields updated, and the patch for #497779 applied. 2) Install in Alioth's collab-maint a git repository made with the --debsnap option of git-import-dscs, unless we try to go deeper in time ? Set up commits emails to go to the PTS. 3) Make crystal clear in the source package's READMEs that uncoordinated commits are an abuse of the collab-maint Alioth group. But perhaps we can allow developers to create topic branches related to bugs in the BTS if they like ? 4) Postpone any other change on the main branch until either #681687 (tech. comittee) is solved or Wheezy released. Lastly, I would like to thank Brian for his impressively 16-years long work on mime-support. Brian, feel free to stay among the uploaders ! Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120717002659.ga2...@falafel.plessy.net
Re: NEWS.Debian entries intended for developers - backwards-incompatible changes in Perl HTML::Tree (Fwd: apt-listchanges news for vinci)
Hi Henrique, On 2012-07-15 20:29, Henrique de Moraes Holschuh wrote: On Sun, 15 Jul 2012, Filipus Klutiero wrote: Perl HTML::Tree 5 has backwards-incompatible interface changes. Version 5.00-1 added a NEWS.Debian entry to warn about that. As the ... migrated to testing and I upgraded my system. The operation was interrupted with a prompt which requested my intervention (I use apt-listchanges). I simply use Gnucash, and find this warning ... package. The proportion of people with libhtml-tree-perl using the package for development must be very small, and I don't think this entry is worth the noise. On the other hand, it's not completely worthless. Do we have guidance on NEWS.Debian usage, giving advice for such situations? If something that depends on libhtml-tree-perl starts malfunctioning right after the upgrade, you will know what to blame. So, it is marginally useful even for users. Yes, as I said, although the entry is not worded towards mere users. Anyway, you use apt-listchanges, so IMHO you should expect to see a NEWS item that doesn't interest you every now and then. I expect to see NEWS items which do not concern me. In fact, most items do not, and I still took the decision of installing apt-listchanges, so that I notice the few items that do concern me. The time saved with relevant items can make up for the time wasted on those irrelevant. What I do not expect is to get more irrelevant news just because something was modularized. Modularity is great, but it shouldn't reduce usability. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5004d2d6.2090...@gmail.com
Re: NEWS.Debian entries intended for developers - backwards-incompatible changes in Perl HTML::Tree (Fwd: apt-listchanges news for vinci)
On Sun, 15 Jul 2012, Henrique de Moraes Holschuh wrote: > If something that depends on libhtml-tree-perl starts malfunctioning > right after the upgrade, you will know what to blame. So, it is > marginally useful even for users. I, for one, appreciate NEWS.Debian entries like these. Thanks gregor, for bothering to spend the time to document these changes. Don Armstrong -- Taxes are not levied for the benefit of the taxed. -- Robert Heinlein _Time Enough For Love_ p250 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120717032526.gp9...@teltox.donarmstrong.com
Re: cross-build-essential
On Thu, 28 Jun 2012 12:47:48 +0100, Wookey wrote: > +++ Svante Signell [2012-06-28 11:43 +0200]: > > The situation is even more complicated if compiling for different OSes: > > Like as host (build) Linux:i386 and guest (target) kFreeBSD:amd64 or > > Hurd:i386. Any plans to support such combinations with > > cross-build-essential? > > Multiarch should support this and dpkg-architecture already does. So > if someone wants to maintain toolchains to do this then adding an > entry to cross-build-essential is easy. (We didn't put everything > possible supported by dpkg in, because that would be 271 packages :-) > Does it actually need a conventional cross-toolchain or is it like the > amd64/i386 case where a chroot and a personality is all that is needed? > > I admit that I haven't thought about the issues for this particular > case in any detail. Is there actually a demand for being able to do > this? Perhaps for MinGW-w64... Regards, Stephen signature.asc Description: PGP signature
Re: Collaborative maintenance of mime-support (was Re: Using FreeDesktop MIME entries directly in mime-support).
On Tue, 2012-07-17 at 09:27 +0900, Charles Plessy wrote: > how about the following (inspired by http://dep.debian.net/deps/dep2/) > > Maintainer: mime-supp...@packages.debian.org > Uploaders: > Laszlo Boszormenyi (GCS) , > Charles Plessy , Hope Brian will also join. May we add you? > I propose the following action plan. > > 0) We subscribe to the PTS (done for me). For me as well, I assume Brian is also subscribed. > 1) Upload to experimental an adopted package with the updated maintainer and >uploaders list, the VCS fields updated, and the patch for #497779 applied. +1 > 2) Install in Alioth's collab-maint a git repository made with the --debsnap >option of git-import-dscs, unless we try to go deeper in time ? Set up >commits emails to go to the PTS. I've created an empty git collab-maint repository on Alioth, still not visible over the web interface. As I know, it just need some time. Made the config to send commits to the PTS. So, how deep should be the package import? The full history from snapshot.debian.org or just the last upload is enough? We will have the file history, but not the comment why happened and what. > 3) Make crystal clear in the source package's READMEs that uncoordinated >commits are an abuse of the collab-maint Alioth group. But perhaps >we can allow developers to create topic branches related to bugs in the BTS >if they like ? +1 , but I assume you know that others may create free and public git trees elsewhere, for example on GitHub. They may send a merge request when their work is done. The tree is still visible, separated and can be merged if needed. > 4) Postpone any other change on the main branch until either #681687 (tech. >comittee) is solved or Wheezy released. +1 > Lastly, I would like to thank Brian for his impressively 16-years long work on > mime-support. Brian, feel free to stay among the uploaders ! I join as well. Thanks Brian for your previous work! Hope you will be still close to the package and the recent events don't turn you down. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1342503504.8460.88.camel@julia
