Bug#807995: postnews sponsorship

[Robert James Clay]

On 05/16/2013 10:48 +0200, John Paul Adrian Glaubitz wrote:
>On 05/16/2013 10:26 AM, RJ Clay wrote:
>> Are those really necessary now?  I will be packaging postnews v0.6
>> later on this year and planned to look at bumping the debhelper version
>> then. (And note that I am part of upstream now and there will be v0.6
>> release...)
>> (...)
>> Yes, I knew about those and already plan to resolve them with the
>> postnews v0.6 packaging.  
>Fair enough, I'm taking your word on this!
>Please ping me back once you have 0.6 ready, 

  I have resolved the issues you raised then but while a version 0.6 of 
'postnews' was released in September of 2013, I did not have a chance to work 
on updating the packaging of it. (New job at the time, then there was the 
Jessie freeze...)  There has now been a v0.6.1 release which I packaged  and 
which is now available as one of the packages I have at the mentors site, 
where it is available (for instance) as follows:

dget -x 
http://mentors.debian.net/debian/pool/main/p/postnews/postnews_0.6.1-1.dsc


  If you would still be willing to sponsor my updated 'postnews'  package, I 
would greatly appreciate it. (Note also that I am now a Debian Maintainer.)



Robert James Clay
j...@rocasa.us

Re: On providing a separate source package for the CUDA build of a library.

[Graham Inggs]

Hi Ghis

On 15 December 2015 at 13:55, Ghislain Vaillant  wrote:
> Upstream kindly asked whether the CUDA backend could be packaged as well,
> and I wanted to confirm with you guys what my options are. I thought about
> providing an additional source package with the same upstream sources, but
> which would be responsible for building the CUDA backend only. I believe
> this source package (arrayfire-cuda) would have to be in contrib since it is
> open-source licensed but build-depends on non-free components (CUDA).
>
> Is this the right way to go? Are there any tips to handle the
> synchronization between the arrayfire and arrayfire-cuda packages? Any other
> examples of a set-up like this in the archive?

Have a look at starpu [1] and starpu-contrib [2].

Regards
Graham


[1] https://packages.qa.debian.org/s/starpu.html
[2] https://packages.qa.debian.org/s/starpu-contrib.html

Bug#807995: marked as done (RFS: postnews/0.6.1-1)

[Debian Bug Tracking System]

Your message dated Tue, 15 Dec 2015 18:59:24 +0100
with message-id <20151215175924.gp13...@jadzia.comodo.priv.at>
and subject line Re: Bug#807995: RFS: postnews/0.6.1-1
has caused the Debian Bug report #807995,
regarding RFS: postnews/0.6.1-1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
807995: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807995
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: normal 

Dear mentors,

I am looking for a sponsor for my package "postnews".

* Package name: postnews
  Version : 0.6.1-1
  Upstream Author : Michael Waschbüsch 
* URL : https://sourceforge.net/p/postnews
* License : GPL2+
  Section : net

It builds those binary packages:

postnews   - Post Usenet articles via NNTP from the command line

To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/postnews


Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/p/postnews/postnews_0.6.1-1.dsc

More information about 'postnews' can be obtained from 
http://sourceforge.net/p/postnews/wiki/Home/.

Changes since the last upload:

* New upstream release.
* Rewrite long description in debian/control.
* Update j...@rocasa.us copyright years in debian/copyright.
* Update debian/rules to reflect upstream script name change.
* Add the new file 'debian/clean' to help with debian/rules change.
* Update 'Correct_shabang_line.patch' for new upstream v0.6.1 version.
* Removed comments and unneeded blank lines from the debian/watch file.
* Set Standards-Version to 3.9.6 in debian/control, no changes required--- End Message ---

Bug#807995: postnews sponsorship

[gregor herrmann]

On Tue, 15 Dec 2015 11:32:22 -0500, Robert James Clay wrote:

> On 05/16/2013 10:48 +0200, John Paul Adrian Glaubitz wrote:
> >Please ping me back once you have 0.6 ready, 
>   If you would still be willing to sponsor my updated 'postnews'  package, I 
> would greatly appreciate it. (Note also that I am now a Debian Maintainer.)

Oops, I saw this mail too late, I hope I didn't cause any duplicate
work due to my upload.


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Bruce Springsteen: Born in the U.S.A.


signature.asc
Description: Digital Signature

Re: On providing a separate source package for the CUDA build of a library.

[Ghislain Vaillant]

Thanks Gianfranco,

In my case, CUDA is definitely a build dependency, so I am guessing 
there is no way around shipping a separate arrayfire-cuda package if 
arrayfire should remain in main.



On 15/12/15 12:03, Gianfranco Costamagna wrote:

Hi,

I did the following on a package I maintain
https://sources.debian.net/src/boinc/7.6.17%2Bdfsg-1/debian/control.in/


note: this package is using cuda and opencl by "dlopen", so there is no
way to detect it at build time.

does this helps you?
(not a clean solution I know)


Il Martedì 15 Dicembre 2015 12:56, Ghislain Vaillant  ha 
scritto:



Dear all,

I am the maintainer of ArrayFire, a library which offers different
implementations of the same API as computational backends. So far, I
have packaged the CPU and OpenCL ones to keep the package in main, but a
CUDA backend also exists.

Upstream kindly asked whether the CUDA backend could be packaged as
well, and I wanted to confirm with you guys what my options are. I
thought about providing an additional source package with the same
upstream sources, but which would be responsible for building the CUDA
backend only. I believe this source package (arrayfire-cuda) would have
to be in contrib since it is open-source licensed but build-depends on
non-free components (CUDA).

Is this the right way to go? Are there any tips to handle the
synchronization between the arrayfire and arrayfire-cuda packages? Any
other examples of a set-up like this in the archive?

Thanks for your advice,
Ghis

Re: f.el dependency loop (was: Re: Cask & dependencies)

[Paul Wise]

On Tue, Dec 15, 2015 at 6:09 AM, Sean Whitton wrote:

> 1) Use the nocheck build profile to build and upload f-el without
>running its tests.  Then build and upload shut-up and undercover.
>Then build and upload a full version of f-el.
>
> 2) Use the nocheck build profile to build and upload shut-up without
>running its tests.  Then build and upload f-el and undercover.
>Then build and upload a full version of shut-up.

I don't think you can upload binary packages using non-default build
profiles to the archive?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

On providing a separate source package for the CUDA build of a library.

[Ghislain Vaillant]

Dear all,

I am the maintainer of ArrayFire, a library which offers different 
implementations of the same API as computational backends. So far, I 
have packaged the CPU and OpenCL ones to keep the package in main, but a 
CUDA backend also exists.


Upstream kindly asked whether the CUDA backend could be packaged as 
well, and I wanted to confirm with you guys what my options are. I 
thought about providing an additional source package with the same 
upstream sources, but which would be responsible for building the CUDA 
backend only. I believe this source package (arrayfire-cuda) would have 
to be in contrib since it is open-source licensed but build-depends on 
non-free components (CUDA).


Is this the right way to go? Are there any tips to handle the 
synchronization between the arrayfire and arrayfire-cuda packages? Any 
other examples of a set-up like this in the archive?


Thanks for your advice,
Ghis

Re: f.el dependency loop (was: Re: Cask & dependencies)

[Jakub Wilk]

* Paul Wise , 2015-12-15, 18:43:

On Tue, Dec 15, 2015 at 6:09 AM, Sean Whitton wrote:

1) Use the nocheck build profile to build and upload f-el without 
running its tests.  Then build and upload shut-up and undercover. Then 
build and upload a full version of f-el.


2) Use the nocheck build profile to build and upload shut-up without 
running its tests.  Then build and upload f-el and undercover. Then 
build and upload a full version of shut-up.


I don't think you can upload binary packages using non-default build 
profiles to the archive?


You shouldn't upload them, but AFAICS dak wouldn't reject such an 
upload.


Perhaps we should add Lintian check for the Built-For-Profiles field, 
and ask ftp-masters to add the tag to the auto-reject list.


That said, the nocheck profile is supposed to have no effect on 
resulting binary packages, so probably uploading packages built with 
this profile activated wouldn't be a big deal...


--
Jakub Wilk

Re: On providing a separate source package for the CUDA build of a library.

[Gianfranco Costamagna]

Hi,

I did the following on a package I maintain
https://sources.debian.net/src/boinc/7.6.17%2Bdfsg-1/debian/control.in/


note: this package is using cuda and opencl by "dlopen", so there is no 
way to detect it at build time.

does this helps you?
(not a clean solution I know)


Il Martedì 15 Dicembre 2015 12:56, Ghislain Vaillant  ha 
scritto:



Dear all,

I am the maintainer of ArrayFire, a library which offers different 
implementations of the same API as computational backends. So far, I 
have packaged the CPU and OpenCL ones to keep the package in main, but a 
CUDA backend also exists.

Upstream kindly asked whether the CUDA backend could be packaged as 
well, and I wanted to confirm with you guys what my options are. I 
thought about providing an additional source package with the same 
upstream sources, but which would be responsible for building the CUDA 
backend only. I believe this source package (arrayfire-cuda) would have 
to be in contrib since it is open-source licensed but build-depends on 
non-free components (CUDA).

Is this the right way to go? Are there any tips to handle the 
synchronization between the arrayfire and arrayfire-cuda packages? Any 
other examples of a set-up like this in the archive?

Thanks for your advice,
Ghis

Bug#808092: RFS: osm-gps-map/1.1.0-1

[Ross Gammon]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "osm-gps-map"

* Package name: osm-gps-map
  Version : 1.1.0-1
  Upstream Author : John Stowers 
* URL : https://github.com/nzjrs/osm-gps-map
* License : GPL-2
  Section : science

It builds these binary packages:

gir1.2-osmgpsmap-1.0 - GTK+ library to embed OpenStreetMap maps - Python
bindings
libosmgpsmap-1.0-1 - GTK+ library to embed OpenStreetMap maps
libosmgpsmap-1.0-dbg - GTK+ library to embed OpenStreetMap maps - debugging
symbols
libosmgpsmap-1.0-dev - GTK+ library to embed OpenStreetMap maps - development
files

To access further information about this package, please visit the following
URL:

  http://mentors.debian.net/package/osm-gps-map


Alternatively, one can download the package with dget using this command:

dget -x http://mentors.debian.net/debian/pool/main/o/osm-gps-map/osm-gps-
map_1.1.0-1.dsc

The Debian packaging is available here:
http://anonscm.debian.org/cgit/pkg-grass/osm-gps-map.git

Changes since the last upload:

  [ Ross Gammon ]
  * New upstream release (LP: #1507381)
  * Refresh patch
  * Update copyright file
  * Drop lintian override as it is no longer required
  * Rename -dev & -dbg packages
  * Add Conflict and Replace for renamed packages
  * Switch to dh_autoreconf
  * Update debian/clean file
  * Reinstate d-shlibmove & add option for unversioned -dev package
  * Install built docs instead of source ones
  * Enable parallel builds
  * Drop README.source as quilt is now well known

  [ Bas Couwenberg ]
  * Update library & package name in symbols file for SONAME bump.
  * Use symbol version without debian revision.
  * Update symbols for version 1.1.0.
  * Update Vcs-Browser URL to use HTTPS.


Regards,
Ross Gammon



-- System Information:
Debian Release: jessie/sid
  APT prefers wily-updates
  APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
(100, 'wily-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-19-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#808101: RFS: nfft/3.3.0-4 [experimental]

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "nfft"

* Package name: nfft
  Version : 3.3.0-4
  Upstream Author : Prof. Dr. Daniel Potts 


* URL :http://www-user.tu-chemnitz.de/~potts/nfft/
* License : GPL version 2
  Section : science

It builds those binary packages:

  libnfft3-2 - library for computing non-uniform Fourier transforms
  libnfft3-dbg - debugging symbols for the NFFT library
  libnfft3-dev - development files for the NFFT library
  libnfft3-doc - documentation for the NFFT library
  libnfft3-double2 - library for computing non-uniform Fourier 
transforms (double precision)
  libnfft3-long2 - library for computing non-uniform Fourier transforms 
(long-double precision)
  libnfft3-single2 - library for computing non-uniform Fourier 
transforms (single precision)


To access further information about this package, please visit the
following URL:

http://mentors.debian.net/package/nfft

Alternatively, one can download the package with dget using this
command:

  dget 
-xhttp://mentors.debian.net/debian/pool/main/n/nfft/nfft_3.3.0-4.dsc


Changes since the last upload:

  * Disable testing for single and long-double precisions.
  * Add patch disabling slow tests.
File: Disable-slow-tests.patch
  * Revert inhibition of tests for architectures which may timeout.

Best regards,
Ghislain Vaillant

Bug#787223: marked as done (RFS: vbam/1.8.0.1507-1 [ITP] -- Gameboy Advance emulator)

[Debian Bug Tracking System]

Your message dated Wed, 16 Dec 2015 04:40:22 +
with message-id 
and subject line closing RFS: vbam/1.8.0.1507-1 [ITP] -- Gameboy Advance 
emulator
has caused the Debian Bug report #787223,
regarding RFS: vbam/1.8.0.1507-1 [ITP] -- Gameboy Advance emulator
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
787223: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787223
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests

Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "vbam"


* Package name: vbam
Version : 1.8.0.1498-1
Upstream Author : VBA-M development team
* URL :https://sourceforge.net/projects/vbam/ 

* License : GPL-2+
Section : otherosfs
It builds those binary packages:


vbam-common - Common files for VBA-M
vbam-gtk   - Nintendo Game Boy Advance emulator (GTK+ frontend)
vbam-sdl   - Nintendo Game Boy Advance emulator
vbam-wx- Nintendo Game Boy Advance emulator (wxWidgets frontend)

To access further information about this package, please visit the following 
URL:

http://mentors.debian.net/package/vbam


Alternatively, one can download the package with dget using this command:

dget -x http://mentors.debian.net/debian/pool/main/v/vbam/vbam_1.8.0.1498-1.dsc


Regards,
Sérgio Benjamim
--- End Message ---
--- Begin Message ---
Package vbam has been removed from mentors.--- End Message ---

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

[Dmitry Bogatov]

* Dmitry Bogatov  [2015-12-07 23:03:23+0300]
> > >I remember, there was another mail, stating opposite opinion. As far as
> > >I know, GNU Make documentation lacks of invariant sections, but it is
> > >still in non-free. But,
> > >
> > >Paul, if you are sure that keeping everything in main is okay and
> > >willing to sponsor, I will gladly revert.
> 
> Okay. I reverted in complexity repository. To me, sbuild is happy.

Ping.



-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: sinsekvu.github.io


signature.asc
Description: Digital signature

Bug#807971: marked as done (RFS: libjsoncpp/1.6.5-1)

[Debian Bug Tracking System]

Your message dated Tue, 15 Dec 2015 15:40:07 + (UTC)
with message-id <781138933.2539034.1450194007740.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#807971: RFS: libjsoncpp/1.6.5-1
has caused the Debian Bug report #807971,
regarding RFS: libjsoncpp/1.6.5-1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
807971: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807971
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "libjsoncpp". I am a DM but
need sponsorship because it has new binary packages (due to an ABI
transition).

 * Package name: libjsoncpp
   Version : 1.6.5-1
   Upstream Author : Cristopher Dunn
 * URL : https://github.com/open-source-parsers/jsoncpp
 * License : MIT
   Section : libs

  It builds those binary packages:

libjsoncpp-dev - library for reading and writing JSON for C++ (devel
files)
 libjsoncpp-doc - API documentation for libjsoncpp-dev
 libjsoncpp1 - library for reading and writing JSON for C++
 libjsoncpp1-dbg - debugging symbols for libjsoncpp1

  To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/libjsoncpp


  Alternatively, one can download the package with dget using this command:

dget -x
http://mentors.debian.net/debian/pool/main/libj/libjsoncpp/libjsoncpp_1.6.5-1.dsc

  More information about hello can be obtained from http://www.example.com.

  Changes since the last upload:

  libjsoncpp (1.6.5-1) experimental; urgency=medium

  * Imported Upstream version 1.6.5
  * d/watch: updated to also receive 1.x releases
  * d/control: updated libjsoncpp0v5* -> libjsoncpp1*
  * d/rules: updated libjsoncpp0v5* -> libjsoncpp1*

 -- Peter Spiess-Knafl   Mon, 14 Dec 2015 22:40:42 +0100


  Regards,
   Peter Spiess-Knafl
--- End Message ---
--- Begin Message ---
Hi,

happily Built!

thanks for your contribution to Debian!
(I fully trusty your followup when the package is accepted for a smooth 
transition)

cheers,

G.





Il Lunedì 14 Dicembre 2015 23:35, Peter Spiess-Knafl  ha 
scritto:
Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "libjsoncpp". I am a DM but
need sponsorship because it has new binary packages (due to an ABI
transition).

* Package name: libjsoncpp
   Version : 1.6.5-1
   Upstream Author : Cristopher Dunn
* URL : https://github.com/open-source-parsers/jsoncpp
* License : MIT
   Section : libs

  It builds those binary packages:

libjsoncpp-dev - library for reading and writing JSON for C++ (devel
files)
libjsoncpp-doc - API documentation for libjsoncpp-dev
libjsoncpp1 - library for reading and writing JSON for C++
libjsoncpp1-dbg - debugging symbols for libjsoncpp1

  To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/libjsoncpp


  Alternatively, one can download the package with dget using this command:

dget -x
http://mentors.debian.net/debian/pool/main/libj/libjsoncpp/libjsoncpp_1.6.5-1.dsc

  More information about hello can be obtained from http://www.example.com.

  Changes since the last upload:

  libjsoncpp (1.6.5-1) experimental; urgency=medium

  * Imported Upstream version 1.6.5
  * d/watch: updated to also receive 1.x releases
  * d/control: updated libjsoncpp0v5* -> libjsoncpp1*
  * d/rules: updated libjsoncpp0v5* -> libjsoncpp1*

-- Peter Spiess-Knafl   Mon, 14 Dec 2015 22:40:42 +0100


  Regards,
   Peter Spiess-Knafl--- End Message ---

Bug#807995: RFS: postnews/0.6.1-1

[Robert James Clay]

On Tuesday, December 15, 2015 12:53:06 AM Robert James Clay wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "postnews".
> 
> * Package name: postnews
>   Version : 0.6.1-1
>   Upstream Author : Michael Waschbüsch 
> * URL : https://sourceforge.net/p/postnews
> * License : GPL2+
>   Section : net


Also;  I am now a Debian Maintainer and I would appreciate having DM upload 
permissions added for my 'postnews' package after this new version is 
uploaded.