Re: Bug#781952: RFS:complexity/1.2-1 [ITP] -- tool for analyzing the complexity of C program functions
* 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#787223: marked as done (RFS: vbam/1.8.0.1507-1 [ITP] -- Gameboy Advance emulator)
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 ---
Bug#808101: RFS: nfft/3.3.0-4 [experimental]
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#808092: RFS: osm-gps-map/1.1.0-1
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#807995: postnews sponsorship
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
Bug#807995: marked as done (RFS: postnews/0.6.1-1)
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 ---
Re: On providing a separate source package for the CUDA build of a library.
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: postnews sponsorship
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
Bug#807971: marked as done (RFS: libjsoncpp/1.6.5-1)
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&Signed&Uploaded! 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
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.
Re: On providing a separate source package for the CUDA build of a library.
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: On providing a separate source package for the CUDA build of a library.
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 , 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
On providing a separate source package for the CUDA build of a library.
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)
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
