Bug#820900: RFS: [ITP] python-hashids/1.1.0-1
On Thu, Apr 14, 2016 at 12:30 AM, Tiago Ilieve wrote: > Nice job! A simple and properly packaged Python library. I have > absolutely nothing to ask to be changed. check-all-the-things and lintian print a number of things that could be polished. > P.s.: I see that you have an "@debian.org" address in your DDPO page. > Aren't you a DD anymore? Seems he became MIA and got removed. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#818184: marked as done (RFS: hal-flash/0.3.3-1 [ITP])
Your message dated Thu, 14 Apr 2016 10:59:58 +0900 with message-id <20160414015958.ga10...@lilith.infoblue.home> and subject line Re: Bug#818184: RFS: hal-flash/0.3.3-1 [ITP] has caused the Debian Bug report #818184, regarding RFS: hal-flash/0.3.3-1 [ITP] 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.) -- 818184: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818184 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal [wishlist] Dear mentors, I am looking for a sponsor for my package "hal-flash" * Package name: hal-flash * Version : 0.3.3-1 * Upstream Author : Christopher Horler * URL : https://github.com/cshorler/hal-flash * License : GPL-2+ or AFL-2.1 * Section : libs It builds those binary packages: libhal1-flash - Compatibility library to allow playback of Flash DRM content To access further information about this package, please visit the following URL: http://mentors.debian.net/package/hal-flash Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/h/hal-flash/hal-flash_0.3.3-1.dsc More information about hello can be obtained from https://github.com/cshorler/hal-flash Changes since the last upload: hal-flash (0.3.3-1) unstable; urgency=medium * Initial upload to unstable (Closes: #818167) * debian/source/format - Use quilt format. * debian/control - Update standards-version to 3.9.7 - Use hal-flash as a source package name * debian/watch - Add watch file * debian/rules - Apply hardening=+all * debian/libhal1-flash.lintian-overrides - Suppress pedantic lintian reports * debian/source.lintian-overrides - Suppress pedantic gpg signature lintian report * debian/libhal1-flash.symbols - Add symbols control file Regards, --- End Message --- --- Begin Message --- uploaded. thank you for your patience. -- Regards, dai GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E signature.asc Description: PGP signature --- End Message ---
Re: Bug#820879: How to avoid version restrictions for JS libraries (Was: Bug#820879: r-cran-shiny: uninstallable in sid: Depends: libjs-jquery (< 1.11.3+dfsg.0~) but 1.12.3-1 is to be installed)
On Wed, Apr 13, 2016 at 09:37:00PM +0200, Andreas Tille wrote:
> On Wed, Apr 13, 2016 at 03:38:16PM +0200, Raphael Hertzog wrote:
> > On Wed, 13 Apr 2016, Andreas Tille wrote:
> > > Could you advise for the proper option to get a less strict dependency?
> >
> > Please read its manual page, it's all documented:
> >
> > | The "replace" action is like "deduplicate" except that it does
> > | replace existing files even if their content is different from the
> > content of
> > | the source files. It generates a weak dependency ("at least the current
> > | upstream version") on the basis that you already assume that both version
> > are
> > | compatible, otherwise you would have used "deduplicate" or "embed".
>
> The thing is I used "replace" in the first place instead of embed but
> it resulted in
>
> dh_linktree
> dpkg-query: error: --search needs at least one file name pattern argument
>
> Use --help for help about querying packages.
> dh_linktree: error: dpkg --search -- gave error exit status 2
>
>
> when replacing whole directories. Is there any chance to do a "replace
> directory"?
To underline why this makes sense:
/usr/share/twitter-bootstrap/files/js/locales
contains currently 38 different translation files. If a new package
twitter-bootstrap might be released there could be more translations.
So it makes absolutely sense to just symlink to the directory instead of
single files which would exclude new translations for no good reason.
Kind regards
Andreas.
--
http://fam-tille.de
Re: How to avoid version restrictions for JS libraries (Was: Bug#820879: r-cran-shiny: uninstallable in sid: Depends: libjs-jquery (< 1.11.3+dfsg.0~) but 1.12.3-1 is to be installed)
On Wed, Apr 13, 2016 at 03:38:16PM +0200, Raphael Hertzog wrote:
> On Wed, 13 Apr 2016, Andreas Tille wrote:
> > Could you advise for the proper option to get a less strict dependency?
>
> Please read its manual page, it's all documented:
>
> | The "replace" action is like "deduplicate" except that it does
> | replace existing files even if their content is different from the content
> of
> | the source files. It generates a weak dependency ("at least the current
> | upstream version") on the basis that you already assume that both version
> are
> | compatible, otherwise you would have used "deduplicate" or "embed".
The thing is I used "replace" in the first place instead of embed but
it resulted in
dh_linktree
dpkg-query: error: --search needs at least one file name pattern argument
Use --help for help about querying packages.
dh_linktree: error: dpkg --search -- gave error exit status 2
when replacing whole directories. Is there any chance to do a "replace
directory"?
Kind regards
Andreas.
--
http://fam-tille.de
Bug#820940: RFS: node-clone/1.0.2-1 [RFP #805907]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "node-clone" * Package name: node-clone Version : 1.0.2-1 Upstream Author : Paul Vorbach * URL : htps://github.com/pvorb/node-clone * License : Expat Section : web It builds those binary packages: node-clone - deep cloning of objects and arrays To access further information about this package, please visit the following URL: http://mentors.debian.net/package/node-clone Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/n/node-clone/node-clone_1.0.2-1.dsc It is a dependance of node-webpack, which is needed for node-source-map, which is needed to fix the RC bug for node-recast (#817774). Regards, Snark on #debian-js
Bug#820938: RFS: complexity/1.9+dfsg-1 ITP
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "complexity" * Package name: complexity Version : 1.9+dfsg-1 Upstream Author : Bruce Korb * Url : https://gnu.org/software/complexity * Licenses: GPL-3+, GFLD-1.2+ Section : devel It builds those binary packages: complexity -- tool for analyzing the complexity of C program functions complexity-doc -- tool for analyzing the complexity of C program (documentation) To access futher information about this package, visit the following URL: http://mentors.debian.net/package/complexity Alternatively, one can download the package with dget using this command: http://mentors.debian.net/debian/pool/main/c/complexity/complexity_1.9+dfsg-1.dsc Alternatively, you can access package debian/ directory via git from URL: https://anonscm.debian.org/cgit/users/kaction-guest/complexity.git More information about complexity can be obtained from https://gnu.org/software/complexity Changes since last upload: * New upstream release * Change insecure git:// uri into secure https:// in Vcs-Git field Regards, Dmitry Bogatov
Bug#818921: RFS: python-neovim-gui/0.1.1-1 [ITP]
On Wed, Apr 13, 2016 at 03:06:21PM +, Gianfranco Costamagna wrote: > Hi Victor and James! > > > >Upstream released python-neovim-gui_0.1.2. > > >That depends on python-neovim >= 0.1.6, which I already have packaged > >and not uploaded, since python-neovim depends on neovim >= 0.1.3, > >currently unreleased git master branch, which is changing. > > > >We could send the tagged python-neovim-gui_0.1.1 to NEW, as it works > >with Debian's neovim_0.1.2 and python-neovim_0.1.2, but this version > >has some quirks that I would like to be fixed prior to shipping it. [1] > > > James, do you have any showstoppers for neovim 0.1.3? in experimental? Nothing other than currently being on vacation. ☺ I'll take a look at it when I get back next week. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy
Bug#820543: RFS: python-django-feincms [NMU] [RC]
control: owner -1 ! control: tags -1 moreinfo Hi Chris >I am looking for a sponsor to update the python-django-feincms package. >The package has 3 RC bugs, the earliest dating back to June 2014 (nearly >a year). > before uploading I have some issues to raise. first python-django-tagging needs to be fixed. I see the fix is already on git (you did the import), so with this mail I'm contacting both maintainers to see if they want to upload it. Well, there is also a new changelog entry about fixing VCS fields, you should really merge in the previous one, since it never hit unstable. that said, please fix before the tagging package, and then we will look at this one https://launchpadlibrarian.net/165738145/python-django-feincms_1.7.4-1_1.7.4-1ubuntu1.diff.gz what about this patch? please note: I didn't do a full review, lets wait some time for maintainers to react, and then I'll be happy to sponsor the packages in the correct order (-tagging and then -feincms). cheers, Gianfranco
Bug#818184: RFS: hal-flash/0.3.3-1 [ITP]
On Sat, 9 Apr 2016 02:09:35 +0900 d...@debian.org wrote: > Please restart ITP process and re-upload this with removal of overriding > for pedantic tags. I've removed pedantic tags and uploaded again. http://mentors.debian.net/debian/pool/main/h/hal-flash/hal-flash_0.3.3-1.dsc
Bug#820900: RFS: [ITP] python-hashids/1.1.0-1
Hi Edward, Nice job! A simple and properly packaged Python library. I have absolutely nothing to ask to be changed. I'd upload it if I had upload rights... :-) P.s.: I see that you have an "@debian.org" address in your DDPO page. Aren't you a DD anymore? Regards, Tiago. -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Bug#820915: marked as done (RFS: arrayfire/3.3.1+dfsg1-2)
Your message dated Wed, 13 Apr 2016 16:23:20 + (UTC) with message-id <1933889216.3925984.1460564600634.javamail.ya...@mail.yahoo.com> and subject line Re: Bug#820915: RFS: arrayfire/3.3.1+dfsg1-2 has caused the Debian Bug report #820915, regarding RFS: arrayfire/3.3.1+dfsg1-2 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.) -- 820915: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820915 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 "arrayfire" * Package name: arrayfire Version : 3.3.1+dfsg1-2 Upstream Author : ArrayFire Development Group * URL : http://arrayfire.com/ * License : BSD Section : science It builds those binary packages: libarrayfire-cpu-dev - Development files for ArrayFire (CPU backend) libarrayfire-cpu3 - High performance library for parallel computing (CPU backend) libarrayfire-dev - Common development files for ArrayFire libarrayfire-doc - Common documentation and examples for ArrayFire libarrayfire-opencl-dev - Development files for ArrayFire (OpenCL backend) libarrayfire-opencl3 - High performance library for parallel computing (OpenCL backend) libarrayfire-unified-dev - Development files for ArrayFire (unified backend) libarrayfire-unified3 - High performance library for parallel computing (unified backend) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/arrayfire Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/a/arrayfire/arrayfire_3.3.1+dfsg1-2.dsc Successful build on debomatic: [amd64] http://debomatic-amd64.debian.net/distribution#unstable/arrayfire/3.3.1+dfsg1-2/buildlog Changes since the last upload: * Refresh Fix-LAPACKE-detection.patch. * Add patch fixing FTBFS on hurd-i386. * d/rules: improve and simplify dh_auto_test override: - Replace explicit calls to ctest with dh_auto_test. - Enable running the testsuite in parallel. - Drop usage of explicit build directory. * Drop -dbg packages in favour of autogenerated -dbgsym. Regards, Ghislain Vaillant --- End Message --- --- Begin Message --- Hi, signed and uploaded! cheers, G. Il Mercoledì 13 Aprile 2016 18:06, Ghislain Vaillant ha scritto: Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "arrayfire" * Package name: arrayfire Version : 3.3.1+dfsg1-2 Upstream Author : ArrayFire Development Group * URL : http://arrayfire.com/ * License : BSD Section : science It builds those binary packages: libarrayfire-cpu-dev - Development files for ArrayFire (CPU backend) libarrayfire-cpu3 - High performance library for parallel computing (CPU backend) libarrayfire-dev - Common development files for ArrayFire libarrayfire-doc - Common documentation and examples for ArrayFire libarrayfire-opencl-dev - Development files for ArrayFire (OpenCL backend) libarrayfire-opencl3 - High performance library for parallel computing (OpenCL backend) libarrayfire-unified-dev - Development files for ArrayFire (unified backend) libarrayfire-unified3 - High performance library for parallel computing (unified backend) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/arrayfire Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/a/arrayfire/arrayfire_3.3.1+dfsg1-2.dsc Successful build on debomatic: [amd64] http://debomatic-amd64.debian.net/distribution#unstable/arrayfire/3.3.1+dfsg1-2/buildlog Changes since the last upload: * Refresh Fix-LAPACKE-detection.patch. * Add patch fixing FTBFS on hurd-i386. * d/rules: improve and simplify dh_auto_test override: - Replace explicit calls to ctest with dh_auto_test. - Enable running the testsuite in parallel. - Drop usage of explicit build directory. * Drop -dbg packages in favour of autogenerated -dbgsym. Regards, Ghislain Vaillant--- End Message ---
Bug#820915: RFS: arrayfire/3.3.1+dfsg1-2
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "arrayfire" * Package name: arrayfire Version : 3.3.1+dfsg1-2 Upstream Author : ArrayFire Development Group * URL : http://arrayfire.com/ * License : BSD Section : science It builds those binary packages: libarrayfire-cpu-dev - Development files for ArrayFire (CPU backend) libarrayfire-cpu3 - High performance library for parallel computing (CPU backend) libarrayfire-dev - Common development files for ArrayFire libarrayfire-doc - Common documentation and examples for ArrayFire libarrayfire-opencl-dev - Development files for ArrayFire (OpenCL backend) libarrayfire-opencl3 - High performance library for parallel computing (OpenCL backend) libarrayfire-unified-dev - Development files for ArrayFire (unified backend) libarrayfire-unified3 - High performance library for parallel computing (unified backend) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/arrayfire Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/a/arrayfire/arrayfire_3.3.1+dfsg1-2.dsc Successful build on debomatic: [amd64] http://debomatic-amd64.debian.net/distribution#unstable/arrayfire/3.3.1+dfsg1-2/buildlog Changes since the last upload: * Refresh Fix-LAPACKE-detection.patch. * Add patch fixing FTBFS on hurd-i386. * d/rules: improve and simplify dh_auto_test override: - Replace explicit calls to ctest with dh_auto_test. - Enable running the testsuite in parallel. - Drop usage of explicit build directory. * Drop -dbg packages in favour of autogenerated -dbgsym. Regards, Ghislain Vaillant
Bug#818921: RFS: python-neovim-gui/0.1.1-1 [ITP]
Hi Victor and James! >Upstream released python-neovim-gui_0.1.2. >That depends on python-neovim >= 0.1.6, which I already have packaged >and not uploaded, since python-neovim depends on neovim >= 0.1.3, >currently unreleased git master branch, which is changing. > >We could send the tagged python-neovim-gui_0.1.1 to NEW, as it works >with Debian's neovim_0.1.2 and python-neovim_0.1.2, but this version >has some quirks that I would like to be fixed prior to shipping it. [1] James, do you have any showstoppers for neovim 0.1.3? in experimental? I would like to avoid an old python-neovim-gui just because 0.1.3 isn't packaged yet. It has been released 6 days ago, so we can wait a little more if James agrees! >Therefore, I have imported the new upstream version 0.1.2, which fixes >some of the problems on the review, but we can't ship until we have >neovim_0.1.3. as said before, new queue is pretty fast nowadays, and python packages are easy to review... we can wait I think >> please add them as build-dependencies and check that python3:Depends do its >> job > >Fixed. >* Added neovim check. >* python3-click is only present on testing and unstable as 6.2, I have > added the check but it could be dropped. >* pygobject is provided by python3-gi-cairo, python3-cairo, > gir1.2-gtk-3.0 as jpleau and I tracked down [2][3]. no. You need to add them to build-dependencies, remove them from runtime-dependencies and verify python3:Depends is actually adding them. (by opening the built deb file and checking the debian/control inside). install_requires is parsed during build, and information is extracted and converted in needed runtime Debian packages. (feel free to keep them in both build-dependencies and runtime-dependencies if the version is not correctly parsed) (see borgbackup git history of debian/control file) >Already upstreamed on 0.1.2. >I haven't added the install inside setup.py since I wasn't sure it of >the best way to make it work on all downstreams. ok >New version now ships a neovim_gui/screen.c. After a conversation at >#debian-mentors and #python, Debian side I concur that we shouldn't >be shipping it and that upstream should include the cythonize on the >build, yet python docs say "distribute both .c and .py, don't build" >[6]. I will leave the .c there for now. ok >Documented it on the commit message, please tell me if it's enough [4]. ok >Reported upstream, where I will tackle it [5]. ok >X: python3-neovim-gui: library-package-name-for-application usr/bin/pynvim > >Should we rename the package as `pynvim` and move it to DPAT instead of >DPMT, even if it is provided by PyPi's module `neovim-gui`? is it more a module or an application? I guess an application, so maybe the applications team is more appropriate you cant do something like python3 import neovim-gui, right? pynvim Traceback (most recent call last): File "/usr/bin/pynvim", line 5, in from pkg_resources import load_entry_point ImportError: No module named 'pkg_resources' ^^ another issue, you need pkg_resources too. lets wait for neovim, in the meanwhile can you please fix the above points? Gianfranco
Bug#820900: marked as done (RFS: [ITP] python-hashids/1.1.0-1)
Your message dated Wed, 13 Apr 2016 14:19:41 + (UTC) with message-id <1438127128.3794136.1460557181902.javamail.ya...@mail.yahoo.com> and subject line Re: Bug#820900: RFS: [ITP] python-hashids/1.1.0-1 has caused the Debian Bug report #820900, regarding RFS: [ITP] python-hashids/1.1.0-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.) -- 820900: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820900 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 "python-hashids" * Package name: python-hashids Version : 1.1.0-1 Upstream Author : David Aurelio * URL : https://github.com/davidaurelio/hashids-python * License : MIT Section : python It builds those binary packages: python-hashids - Python implementation of hashids python3-hashids - Python implementation of hashids (Python 3 version) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/python-hashids Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/python-hashids/python-hashids_1.1.0-1.dsc -- Edward. --- End Message --- --- Begin Message --- Hi, sponsored. maybe next time use "Expat" as license, it should be the best one. g. Il Mercoledì 13 Aprile 2016 16:00, Edward Betts ha scritto: Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "python-hashids" * Package name: python-hashids Version : 1.1.0-1 Upstream Author : David Aurelio * URL : https://github.com/davidaurelio/hashids-python * License : MIT Section : python It builds those binary packages: python-hashids - Python implementation of hashids python3-hashids - Python implementation of hashids (Python 3 version) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/python-hashids Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/python-hashids/python-hashids_1.1.0-1.dsc -- Edward.--- End Message ---
Bug#820900: RFS: [ITP] python-hashids/1.1.0-1
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "python-hashids" * Package name: python-hashids Version : 1.1.0-1 Upstream Author : David Aurelio * URL : https://github.com/davidaurelio/hashids-python * License : MIT Section : python It builds those binary packages: python-hashids - Python implementation of hashids python3-hashids - Python implementation of hashids (Python 3 version) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/python-hashids Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/python-hashids/python-hashids_1.1.0-1.dsc -- Edward.
Re: Bug#814852: RFS: openfst/1.5.1-1 -- weighted finite-state transducers library
Hi Jakub, upstream released a new version of openfst. On 15/03/2016 11:33, Giulio Paci wrote: > On 11/03/2016 16:34, Jakub Wilk wrote: >> * Giulio Paci , 2016-03-08, 22:24: we do seem to have an s390x buildd with only 3GB of RAM: https://db.debian.org/machines.cgi?host=zemlinsky >>> >>> So we may have a failure there. :-/ >> >> Perhaps. But with the current limits, the package would be built with -j1 >> there, so reducing parallelism further wouldn't help. Let's not worry about >> zemlinsky for now. :) >> >> Comments in src/extensions/python/*.cc say that the files were generated by >> Cython, but I don't see their Cython sources in the tarball. :-\ > > You are right. I did not notice as I have disabled that extension (it is > available also in pypi, so that one can be packaged if anybody is interested). > I asked upstream and they agreed to release the .pyx file in the next openfst > release. > > Essentially we are waiting: > 1) .pyx file release; This issue has been addressed. > 2) openfst patch for Kaldi review. This issue has not been addressed. As far as I know no progress at all has been made. If you agree as this patch is a prerequisite for having Kaldi in Debian (which is one of my goals), I would include this patch without having it approved by upstream. I am confident that they will approve it once they will find time to evaluate it, but I am not confident they will evaluate it very soon. Bests, Giulio
Re: How to avoid version restrictions for JS libraries (Was: Bug#820879: r-cran-shiny: uninstallable in sid: Depends: libjs-jquery (< 1.11.3+dfsg.0~) but 1.12.3-1 is to be installed)
On Wed, 13 Apr 2016, Andreas Tille wrote:
> Could you advise for the proper option to get a less strict dependency?
Please read its manual page, it's all documented:
| The "replace" action is like "deduplicate" except that it does
| replace existing files even if their content is different from the content of
| the source files. It generates a weak dependency ("at least the current
| upstream version") on the basis that you already assume that both version are
| compatible, otherwise you would have used "deduplicate" or "embed".
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/
Re: How to avoid version restrictions for JS libraries (Was: Bug#820879: r-cran-shiny: uninstallable in sid: Depends: libjs-jquery (< 1.11.3+dfsg.0~) but 1.12.3-1 is to be installed)
Hi Raphael, On Wed, Apr 13, 2016 at 02:41:52PM +0200, Raphael Hertzog wrote: > > It really depends... you're trading one problem for another. In general, > it's best if you can just rely on the packaged javascript without having > to replace any embedded copy. > > But if you have to replace an embedded copy, then dh_linktree is better > as it lets you easily switch from embedded to non-embedded (without having > to deal with symlink_to_dir and dir_to_symlink transitions). There are also > multiple "actions" that result in different dependencies... by default > you get a strong dependency like said here but if you're confident that > newer upstream releases will not introduce new files, then you can use > something less strict. Could you advise for the proper option to get a less strict dependency? Kind regards Andreas. -- http://fam-tille.de
Re: How to avoid version restrictions for JS libraries (Was: Bug#820879: r-cran-shiny: uninstallable in sid: Depends: libjs-jquery (< 1.11.3+dfsg.0~) but 1.12.3-1 is to be installed)
On Wed, 13 Apr 2016, Andreas Tille wrote: > Ahhh, good hint. So the solution to my problem would rather be to > drop dh_linktree? (Raphael in CC whether I might have missed something). It really depends... you're trading one problem for another. In general, it's best if you can just rely on the packaged javascript without having to replace any embedded copy. But if you have to replace an embedded copy, then dh_linktree is better as it lets you easily switch from embedded to non-embedded (without having to deal with symlink_to_dir and dir_to_symlink transitions). There are also multiple "actions" that result in different dependencies... by default you get a strong dependency like said here but if you're confident that newer upstream releases will not introduce new files, then you can use something less strict. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: How to avoid version restrictions for JS libraries (Was: Bug#820879: r-cran-shiny: uninstallable in sid: Depends: libjs-jquery (< 1.11.3+dfsg.0~) but 1.12.3-1 is to be installed)
Hi James,
On Wed, Apr 13, 2016 at 12:28:58PM +0100, James Cowgill wrote:
> On Wed, 2016-04-13 at 13:13 +0200, Andreas Tille wrote:
> > via this bug I learned (the hard way) that a
> >
> > Depends: ${js:Depends}
> >
> > will be resolved into
> >
> > libjs-jquery (<< 1.11.3+dfsg.0~), libjs-jquery (>= 1.11.3+dfsg)
> >
> > (for instance) in the final package. I have no reason to assume that
> > the actual version that was available at package build time is the
> > only
> > valid dependency for my package. So it seems unadvisable to use
> > ${js:Depends} depends at all to avoid continuous uploading of the
> > package (depending from 9 different libjs-* packages) if any of its
> > libjs-* was uploaded with a new version.
> >
> > I wonder what the idea behind this resulution of the ${js:Depends}
> > would be since I have the feeling that this is not sensible in the
> > most practical cases.
> >
> > Am I missing something?
>
> I think those dependencies come from dh_linktree and are placed in
> ${misc:Depends}, not ${js:Depends}.
>
> dh_linktree(1) contains this:
>
> Since symlink trees are created statically at build-time, they are not
> very future-proof and have a risk to miss some files introduced by a
> newer version of the package providing the file tree which is
> duplicated. That's why the generated dependencies generally ensure that
> the same upstream version be used at run-time than at build-time.
Ahhh, good hint. So the solution to my problem would rather be to
drop dh_linktree? (Raphael in CC whether I might have missed something).
Kind regards
Andreas.
--
http://fam-tille.de
Re: How to avoid version restrictions for JS libraries (Was: Bug#820879: r-cran-shiny: uninstallable in sid: Depends: libjs-jquery (< 1.11.3+dfsg.0~) but 1.12.3-1 is to be installed)
Hi,
On Wed, 2016-04-13 at 13:13 +0200, Andreas Tille wrote:
> via this bug I learned (the hard way) that a
>
> Depends: ${js:Depends}
>
> will be resolved into
>
> libjs-jquery (<< 1.11.3+dfsg.0~), libjs-jquery (>= 1.11.3+dfsg)
>
> (for instance) in the final package. I have no reason to assume that
> the actual version that was available at package build time is the
> only
> valid dependency for my package. So it seems unadvisable to use
> ${js:Depends} depends at all to avoid continuous uploading of the
> package (depending from 9 different libjs-* packages) if any of its
> libjs-* was uploaded with a new version.
>
> I wonder what the idea behind this resulution of the ${js:Depends}
> would be since I have the feeling that this is not sensible in the
> most practical cases.
>
> Am I missing something?
I think those dependencies come from dh_linktree and are placed in
${misc:Depends}, not ${js:Depends}.
dh_linktree(1) contains this:
Since symlink trees are created statically at build-time, they are not
very future-proof and have a risk to miss some files introduced by a
newer version of the package providing the file tree which is
duplicated. That's why the generated dependencies generally ensure that
the same upstream version be used at run-time than at build-time.
James
signature.asc
Description: This is a digitally signed message part
How to avoid version restrictions for JS libraries (Was: Bug#820879: r-cran-shiny: uninstallable in sid: Depends: libjs-jquery (< 1.11.3+dfsg.0~) but 1.12.3-1 is to be installed)
Hi,
via this bug I learned (the hard way) that a
Depends: ${js:Depends}
will be resolved into
libjs-jquery (<< 1.11.3+dfsg.0~), libjs-jquery (>= 1.11.3+dfsg)
(for instance) in the final package. I have no reason to assume that
the actual version that was available at package build time is the only
valid dependency for my package. So it seems unadvisable to use
${js:Depends} depends at all to avoid continuous uploading of the
package (depending from 9 different libjs-* packages) if any of its
libjs-* was uploaded with a new version.
I wonder what the idea behind this resulution of the ${js:Depends}
would be since I have the feeling that this is not sensible in the
most practical cases.
Am I missing something?
Kind regards
Andreas.
On Wed, Apr 13, 2016 at 12:33:41PM +0200, Andreas Beckmann wrote:
> Package: r-cran-shiny
> Version: 0.13.1+dfsg-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package is no longer
> installable in sid:
>
> 1m45.1s DEBUG: Starting command: ['chroot', '/tmp/piupartss/tmpmbw__d',
> 'apt-get', '-y', 'install', 'r-cran-shiny']
> 1m45.6s DUMP:
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
>r-cran-shiny : Depends: libjs-jquery (< 1.11.3+dfsg.0~) but 1.12.3-1 is to
> be installed
> E: Unable to correct problems, you have held broken packages.
>
>
> Cheers,
>
> Andreas
>
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
>
--
http://fam-tille.de
Bug#820733: Guidelines for sensible package synopsis (was: Bug#820733: RFS: Series/1.0 [ITP] -- Keep track of your favourite TV series)
Hi again,
stuff to do:
fix lintian, make a real copyright file, fix flags, fix useless files, convert
the format to quilt...
come back if you don't know how to fix issues, when you have a larger userbase,
and when you learn how
to tag release, remove useless stuff and *not* commit binaries on git :)
and the package has to build on a clean pbuilder/sbuild environment
there is a lot of work to do here!
(I suggest you to go on irc oftc and ask on -mentors, or click on the link on
mentors website, each
lintian warning has an explanation that helps in fixing it)
cheers,
G.
Il Martedì 12 Aprile 2016 20:57, Giorgio Sartore ha
scritto:
Hi Gianfranco,
thank you for your answer. I've uploaded the package to
https://mentors.debian.net/package/series
I'm almost sure I made a few mistakes, so please tell me what to do to fix them.
Best regards
Giorgio
Il 12/apr/2016 14:28, "Gianfranco Costamagna" ha
scritto:
Hi Giorgio
>
>
>http://mentors.debian.net/intro-maintainers
>
>this should help.
>
>
>cheers,
>
>G.
>
>
>Il Martedì 12 Aprile 2016 13:36, Giorgio Sartore ha
>scritto:
>
>
>
>Hi all,
>thank you for your hints. I'll update the synopsis as soon as possibile.
>I know that I've uploaded the source code yesterday, but I'm working on it
>since about a month, in my free time. The project started as a personal
>program, recently I thought that it could be useful to other people. So, I'd
>like to share it with all Debian users.
>Anyway, can you please guide me through this process? It's my first time. May
>I have some chances to get it published?
>Thank you very much.
>Regards,
>Giorgio
>Il 12/apr/2016 07:30, "Ben Finney" ha scritto:
>
>Tiago Ilieve writes:
>>
>>> Hi Sartore,
>>>
>>> On 11 April 2016 at 16:36, Sartore Giorgio (Mani)
>>> wrote:
>>> > series - keep track of your favourite TV series
>>>
>>> […] I would like to ask you to close this bug and open a new one when
>>> the package is more mature and have a few more users.
>>
>>When starting that Debian package, please follow the guidelines for the
>>package description.
>>
>>For example:
>>
>>frobnicator of grellicules
>>
>>The test to apply is detailed in the Developer's Reference §6.2.2:
>>
>>Technically this is a noun phrase minus articles, as opposed to a
>>verb phrase. A good heuristic is that it should be possible to
>>substitute the package name and synopsis into this formula:
>>
>>The package ‘name’ provides {a,an,the,some} synopsis.
>>
>>So, the synopsis “keep track of your favourite TV series” makes that
>>sentence:
>>
>>The package ‘series’ provides a keep track of your favourite TV series.
>>
>>This doesn't make sense, and so the synopsis should be re-written to be
>>a noun phrase.
>>
>>--
>> \ “It is a part of probability that many improbable things will |
>> `\ happen.” —Aristotle, _Poetics XXV_, 335 BCE |
>>_o__) |
>>Ben Finney
>>
>
Bug#820717: marked as done (RFS: mercurial-extension-utils/1.2.0-1 [ITP])
Your message dated Wed, 13 Apr 2016 09:21:43 + (UTC) with message-id <212860291.3370885.1460539303391.javamail.ya...@mail.yahoo.com> and subject line Re: Bug#820717: RFS: mercurial-extension-utils/1.2.0-1 [ITP] has caused the Debian Bug report #820717, regarding RFS: mercurial-extension-utils/1.2.0-1 [ITP] 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.) -- 820717: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820717 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 "mercurial-extension-utils" * Package name: mercurial-extension-utils Version : 1.2.0-1 Upstream Author : Marcin Kasperski * URL : http://pypi.python.org/pypi/mercurial_extension_utils * License : BSD-3-clause Section : python It builds those binary packages: mercurial-extension-utils - Contains functions for writing Mercurial extensions. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/mercurial-extension-utils Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/mercurial-extension-utils/mercurial-extension-utils_1.2.0-1.dsc More information about mercurial-extension-utils can be obtained from http://pypi.python.org/pypi/mercurial_extension_utils Changes since the last upload: * Initial release. (Closes: #820217) Regards, Christoph Mathys --- End Message --- --- Begin Message --- Hi, sponsoring soon! thanks for your contribution to Debian! G. Il Lunedì 11 Aprile 2016 18:48, Christoph Mathys ha scritto: Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "mercurial-extension-utils" * Package name: mercurial-extension-utils Version : 1.2.0-1 Upstream Author : Marcin Kasperski * URL : http://pypi.python.org/pypi/mercurial_extension_utils * License : BSD-3-clause Section : python It builds those binary packages: mercurial-extension-utils - Contains functions for writing Mercurial extensions. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/mercurial-extension-utils Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/mercurial-extension-utils/mercurial-extension-utils_1.2.0-1.dsc More information about mercurial-extension-utils can be obtained from http://pypi.python.org/pypi/mercurial_extension_utils Changes since the last upload: * Initial release. (Closes: #820217) Regards, Christoph Mathys--- End Message ---
Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]
control: block -1 by 819016 Hello Giafranco, > FWIW adding "u" to the strings indeed fixed the issue > e.g. 'string' becomes u'string' (IIRC forcing unicode) thanks, it's been confirmed by upstream and promptly fixed on the upstream repository [1]. > BTW, the Python policy is something like > "python-foo" means "import foo" works. > Adding str migth deviate from the policy, you might want to ask #-python > about this specific issue (and quote the conversation here) thanks for letting me know about the potential Policy issue with the package name. After discussing it at #debian-python [2], it seems that the deviation would be acceptable, however it was suggested that the conflicts as a whole would be better solved by renaming the *existing* package: there are 2 reported installations of python3-jellyfish on popcon - I'd rename the other python3-jellyfish now (module and binary package) and a then upload yours with python3-jellyfish name > thanks, I'll wait for your action, I have commented on #819016 in the hopes of discussing the new approach with the maintainer of the existing jellyfish package, and I'll ping you back once the situation is sorted out. Again, thanks a lot, [1] https://github.com/jamesturk/jellyfish/issues/51 [2] http://paste.debian.net/432489 -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
