Re: Copyright file granularity

On Fri, Nov 13, 2015 at 08:34:11PM +0100, Stephen Kitt wrote: > On Fri, 13 Nov 2015 10:51:11 -0800, Steve Langasek wrote: > > On Fri, Nov 13, 2015 at 04:10:14PM +, Wookey wrote: > [...] > > And we should have better tools to generate debian/copyright files - this > > shouldn't be an intensive

Bug#805054: ITP: teckit -- Encoding conversion tools for plain text files

Package: wnpp Severity: wishlist Owner: w...@debian.org X-Debbugs-CC: debian-devel@lists.debian.org Package name: teckit Version : 2.5.4~svn140 Upstream Author : Jonathan Kew URL : https:// scripts.sil.org/TECkit Licen

Re: Copyright file granularity

+++ Steve Langasek [2015-11-13 10:51 -0800]: > On Fri, Nov 13, 2015 at 04:10:14PM +, Wookey wrote: > > I've been helping package a load of stuff recently for Robot OS and in > > checking the copyright files I've come up aginst the question of exactly > > how much segmentation there should be in

Re: Copyright file granularity

Steve Langasek writes: > shouldn't be an intensive manual process. Unfortunately the only tool I'm > aware of that does this is coupled to cdbs. I wrote http://lindi.iki.fi/lindi/git/git-copyright-scan.git/ to update debian/copyright based on upstream git history. There's no documentation and it

Re: Copyright file granularity

Excerpts from Steve Langasek's message of 2015-11-13 10:51:11 -0800: > On Fri, Nov 13, 2015 at 04:10:14PM +, Wookey wrote: > > I've been helping package a load of stuff recently for Robot OS and in > > checking the copyright files I've come up aginst the question of exactly > > how much segment

Re: Copyright file granularity

On Fri, 13 Nov 2015 10:51:11 -0800, Steve Langasek wrote: > On Fri, Nov 13, 2015 at 04:10:14PM +, Wookey wrote: [...] > And we should have better tools to generate debian/copyright files - this > shouldn't be an intensive manual process. Unfortunately the only tool I'm > aware of that does th

Re: Copyright file granularity

On Fri, Nov 13, 2015 at 04:10:14PM +, Wookey wrote: > I've been helping package a load of stuff recently for Robot OS and in > checking the copyright files I've come up aginst the question of exactly > how much segmentation there should be in copyright files, and the answer > to that depends on

Re: Copyright file granularity

On 13/11/15 17:10, Wookey wrote: > The criteria that makes most sense to me is 'by licence'. +1 > I just uploaded rosdistro > (https://tracker.debian.org/pkg/ros-rosdistro) and got a comment from > the reviewing ftpmaster that combining the two different copyright holders > for BSD-3-clause file

Re: Ideas to improve dpkg/ucf with hooks [was: Putting default config files in /usr]

Hi, Adding in his or callbacks would be easy enough. Do you have an idea of what you would need for your use case? Manoj On November 13, 2015 9:22:45 AM PST, Vincent Danjean wrote: >Le 13/11/2015 17:47, Marc Haber a écrit : >> Actually, I don't quite see why ucf would need hooks since it

Re: Copyright file granularity

Hi, On 13-11-15 17:10, Wookey wrote: > The criteria that makes most sense to me is 'by licence'. The machine readable copyright file definition says this: """The Copyright field collects all relevant copyright notices for the files of this paragraph. Not all copyright notices may apply to every i

Re: Ideas to improve dpkg/ucf with hooks [was: Putting default config files in /usr]

Le 13/11/2015 17:47, Marc Haber a écrit : > Actually, I don't quite see why ucf would need hooks since it is > called from the maintainer scripts, giving the local admin full power > of creativity anyway. Chances are that ucf is already the right tool > to maintain systemd and friends the Debian wa

Re: Ideas to improve dpkg/ucf with hooks [was: Putting default config files in /usr]

On Wed, 11 Nov 2015 15:36:09 +0100, Vincent Danjean wrote: > What I would really prefer is a work on a way to add hooks in >dpkg/ucf so that: >- original provided configuration files can be recorded (before > admin modification/merge) >- other merge strategies (dpkg only provides use old or new,

Re: Putting default config files in /usr [was; (newbie) Disruptive LIRC package update.]

On Thu, 12 Nov 2015 10:24:48 -0800, Nikolaus Rath wrote: >On Nov 11 2015, Marc Haber wrote: >> Once and for all we're doing _SOMETHING_ right, let's keep it that >> way. > >I think what Debian is doing right is that it tracks and notifies about >changes in configuration files. But that doesn't me

Copyright file granularity

I've been helping package a load of stuff recently for Robot OS and in checking the copyright files I've come up aginst the question of exactly how much segmentation there should be in copyright files, and the answer to that depends on what it is they are actually for? Is it sufficient to specify

Bug#805035: ITP: pidgin-gpg -- OpenPGP plugin for Pidgin

Package: wnpp Severity: wishlist Owner: "Paulo Roberto Alves de Oliveira (aka kretcheu)" * Package name: pidgin-gpg Version : 0.9 Upstream Author : Alexander.Murauer. * URL : https://github.com/segler-alex/Pidgin-GPG * License : GPL-3 Programming Lang: C De

Re: Fwd: [Patch] Shall we update CUDA to 7.0.28 ? (#783770)

Hi, On Fri, 2015-11-13 at 15:21 +0100, Samuel Thibault wrote: > Thanks for your contribution that will hopefully help getting cuda 7.0 > or 7.5 packages out faster. I do hope so. :-) > > FYI: As far as I know, in my experiments, > > a Tesla K20C GPU works 5+ times faster than an Intel Xeon W3690

Re: Fwd: [Patch] Shall we update CUDA to 7.0.28 ? (#783770)

Hello, My few cents about it: lumin, on Fri 13 Nov 2015 13:55:52 +, wrote: > Debian's CUDA/experimental is QUITE OUT OF DATE so that > it fails to work with GCC-5. It's cuda 6.5. Cuda 7.0 is not *that* new. AIUI, it was officially released by Nvidia in March 2015. Yes, the push to gcc-5 p

Fwd: [Patch] Shall we update CUDA to 7.0.28 ? (#783770)

Hi all, (d-devel blocks my mail, which contains many patches, for the original mail please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783770 ) Summary === In short I'm trying to update the CUDA package for Debian, and patches are provided as attachments. My work is based on the s

Bug#804995: ITP: proteinortho -- Detection of (Co-)orthologs in large-scale protein analysis

Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: proteinortho Version : 5.11 Upstream Author : Marcus Lechner * URL : https://www.bioinf.uni-leipzig.de/Software/proteinortho/ * License : GPL Programming Lang: C++, Perl, Python Descript