Help: Package upgrade blues.

Dear list, I cannot get my first package into shape - the upgrade paths fail. The sad story: New packages: liblirc0, liblirc-dev, lirc, lirc-x, lirc-doc Old packages lirc, lirc-x, liblircclient0, liblircclient-dev. New packages 'lirc' and 'liblirc0' together obsoletes old 'lirc'.

Bug#804100: RFS: rhythmbox-plugin-alternative-toolbar/0.14.0-1~debian [ITP]

Package: sponsorship-requests Severity: wishlist Dear Mentors, I am looking for a sponsor for my package "rhythmbox-plugin-alternative-toolbar" * Package name: rhythmbox-plugin-alternative-toolbar Version : 0.14.0-1~debian Upstream Author : fossfreedom *

Re: [cmake][multipackaging] best practices

My experience with upstream CMake projects is that a lot are using CPack to provide a ubiquitous packaging solution. However what upstream "thinks" as a reasonable binary package decomposition may not agree with the Debian policy. For instance, upstream may decide to put the documentation in

Re: BSD-2-clause with header

Looks like it. In doubt just give it another name, like "BSD-SANDIA" Ghis On 04/11/15 09:13, Nico Schlömer wrote: Hi everyone, I'm packaging a software which includes the following license statement: ``` Under the terms of Contract DE-AC04-94AL85000 with Sandia Corporation, the U.S.

Re: BSD-2-clause with header

Hi, maybe I would call it BSD-2-clause-sandia, because the base license is BSD-2-clause. but this might be not an problem at all, IANAL cheers, G. Il Mercoledì 4 Novembre 2015 12:40, Ghislain Vaillant ha scritto: Looks like it. In doubt just give it another name,

Re: [cmake][multipackaging] best practices

+++ Raffi Enficiaud [2015-11-02 11:04 +0100]: > Hi, > > I am now able to package my project properly in Launchpad, without > going through any install step. My source code produces several .deb > files, and all of them is managed by cmake directly because I want > the split of the project be done

Bug#781952: RFS:complexity/1.2-1 [ITP] -- tool for analyzing the complexity of C program functions

Hi, according to [1] [2] [3] FDL with the "no invariant" section is not considered DFSG. So the package won't pass the new queue. there is no problem in backporting it, but we prior need to make it dfsg and pass the new queue. When the package will enter testing, a backport will be possible

Bug#803993: marked as done (RFS: netmask/2.4.3-1 - helps determine network masks)

Your message dated Wed, 4 Nov 2015 09:00:15 + (UTC) with message-id <957088714.2952103.1446627615316.javamail.ya...@mail.yahoo.com> and subject line Re: Bug#803993: RFS: netmask/2.4.3-1 - helps determine network masks has caused the Debian Bug report #803993, regarding RFS: netmask/2.4.3-1 -

Bug#802848: RFS: gnome-twitch/0.1.0-1 [ITP]

On Sat, Oct 31, 2015 at 11:26 PM, Tim Dengel wrote: > The second issue is, as you said, the use of git. But adding git to the > build dependencies would not solve this, since the .git directory is not > contained in the original tarball, so git couldn't extract the version > from it anyways. > >

BSD-2-clause with header

Hi everyone, I'm packaging a software which includes the following license statement: ``` Under the terms of Contract DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains certain rights in this software. . Redistribution and use in source and binary forms, with or without

Re: [cmake][multipackaging] best practices

Le 04/11/15 09:50, Gianfranco Costamagna a écrit : Hi, generating debian files from cmake is not trivial, and I'm not sure I can answer here. Hi, Thank you for your reply! Would you please tell me what are the difficulties? I have more the developer hat, and not the packager one, and to me

Re: [cmake][multipackaging] best practices

Hi, generating debian files from cmake is not trivial, and I'm not sure I can answer here. Furthermore, in Debian we don't have this need, and generating them (autogenerating) is source of problems with official packages. So I'm afraid (while I like the opportunity), nobody will be interested

Re: [cmake][multipackaging] best practices

Le 02/11/15 11:04, Raffi Enficiaud a écrit : Hi, Recently I pushed a couple of changes to the cmake project that allow cmake to run on Launchpad. Those changes were targeted at making cmake able to create Debian packages directly (before that, it was unable to create Debian packages in

Re: [cmake][multipackaging] best practices

Hi, I guess your answers are in man dh_python2 man dh_makeshlibs man dh_shlibdeps and so on the first tries to evaluate the runtime dependencies of a python application the others does almost the same for the built libraries. they are needed to know which runtime dependencies the package

Re: [cmake][multipackaging] best practices

On 04/11/15 10:28, Raffi Enficiaud wrote: > Le 04/11/15 09:50, Gianfranco Costamagna a écrit : >> Hi, generating debian files from cmake is not trivial, and I'm not >> sure I can answer here. > > Hi, > > Thank you for your reply! Would you please tell me what are the > difficulties? I have more

Bug#803979: marked as done (RFS: node-string-decoder/0.10.25-1 [ITP])

Your message dated Wed, 4 Nov 2015 11:08:13 + (UTC) with message-id <2085037274.3168355.1446635293884.javamail.ya...@mail.yahoo.com> and subject line Re: Bug#803979: RFS: node-string-decoder/0.10.25-1 [ITP] has caused the Debian Bug report #803979, regarding RFS: node-string-decoder/0.10.25-1