Re: Bug#850789: Patch upload not showing up in deferred queue
control: tags -1 patch >It's not useful for me to spare the maintainer(s) the work? I figured if I >could do the footwork and let the maintainer just review and approve the >patch, they >would be happy. you already opened a bug, provided a patch and I'm tagging this bug accordingly. The maintainer will probably upload the package with some more changes in some days (uploading a src:python3 package with just a change in watch file is an overkill, people will upgrade their pc with MB of stuff, just because of a "useless to them" packaging change). Moreover the Debian Maintainer is also upstream developer, so he knows when a new version is out :) thanks for the patch, I'm sure it will be eventually added! G.
Re: Bug#830417: RFS: django-setuptest/0.2.1-1 [ITP]
>I have now checked the package into the python-modules Alioth repository: it looked good to me, uploaded. G.
Re: Bug#831994: RFS: python-prompt-toolkit/1.0.3-1 (ITP)
Hi, > https://mentors.debian.net/package/python-prompt-toolkit 404 >https://mentors.debian.net/debian/pool/main/p/python-prompt-toolkit/python-prompt-toolkit_1.0.3-1.dsc >https://anonscm.debian.org/git/python-modules/packages/python-prompt-toolkit.git >https://anonscm.debian.org/cgit/python-modules/packages/python-prompt-toolkit.git all are 404... Please reopen once you get something to work on! Gianfranco
Re: Bug#813096: ITP: logdata-anomaly-miner -- lightweight tool for log checking, log analysis
Hi, (answering where I can!) >Moving the code to "/usr/lib/python2.7/dist-packages/aminer" in fact allows >dh_python2 to extract the version information: > >Depends: python:any (<< 2.8), python:any (>= 2.7.5-5~), python-tz, >init-system-helpers (>= 1.18~) > >(Remark: Is there any reason to restrict the versions to >=2.7.5? The tools >should have compatibility with >=2.6 and I would expect the "Depends" section >to somehow reflect that reality. Is DEBPYTHON_SUPPORTED and DEBPYTHON_DEFAULT >intended to be used to fix that?) that stuff is built for unstable/testing, so the variables are filled with the current python situation (2.6 is only on old-stable, and Stretch has 2.7.11 already). Probably if you try to build it with a jessie chroot, you get different values, and this is correct. (you can't in general install deb built against stretch into wheezy/jessie, without breaking stuff, this is why some dependencies are not too relaxed, to avoid people doing that, but instead upgrading the minimal set of packages to make sure things will work after the apt-pinning). I don't foresee any issue here, because even in case of a backport, the package will need to be rebuilt on top of that. >But doing the move, lintian will not like the produced package any more: > >E: logdata-anomaly-miner: python-script-but-no-python-dep >usr/lib/aminer/AMiner I can't say, I don't see the package installing stuff in usr/lib/python* on mentors >The rationale behind not putting aminer into dist-packages (and removing >dist-packages from python-path) was: > >a) require the aminer-admin to "link" in each dist-packages module separately, >thus reminding it, that it is no good idea to include large amounts of third >party libraries in security-critical code. Code volume is also bugs and >attack-surface. I didn't get completely this, but I leave other people to answer >b) prepare against possible future risks due to accidental loading (call to >__init__) of other packages residing in dist-packages, that may give rise to >privilege escalation (like the GNU-TLS CVE from this/last week) mmm you want to avoid people importing your library? ok >Of course, it should be possible to move the code to >/usr/lib/python2.7/dist-packages/aminer and perform the "link" operation, but >this could make it more "sexy" for an admin to include whole dist-packages in >python path again. >In that light, should the code be moved? leaving to other folks the answer >Apart from that, this will also make it harder to use the same codebase for >both python2.6/python2.7, but that should be fixable by providing more >patches. you can't use python2.6 on Stretch, so no issue here. >> >-#!/usr/bin/python2 -BEsSt >> >+#!/usr/bin/python2.7 -BEsSt >> >> this should be also handled by dh_python2 AFAIK > >Even with move dh_python2 does not touch the files. The only difference is, >that lintian does not like the files any more. can you please double check with the documentation? https://wiki.debian.org/Python/LibraryStyleGuide >So it would be OK to place the files in usr/lib/python2.7/dist-packages and >add a symlink to usr/lib/python2.6/dist-packages? no, python2.6 is dead, no need to add it here. >I would not like to push for that. Let's take the time and learn. Also this >package might be the template for other security-tool packages, so better have >it clean before cloning. thanks for understanding! >Understood. It might be, that this is all not a big issue for the python-dev >>pros, might be sorted out quickly. I hope so, I understand the package is doing some non-standard things, so trying to make it python-library style might be even a bad idea in general, this is why I would prefer to have some double/triple checks here ;) thanks for the nice email! G.
Re: Packaging pythonpy
Hi,
>I really appreciate your effort in trying to package it yourself, but
>you didn't solved the main problem, which is the
>"python-script-but-no-python-dep".
indeed, control file line two.
it is an application, so choose some Section from there
https://qa.debian.org/developer.php?login=python-apps-team%40lists.alioth.debian.org
Section: python is for libraries (e.g. called python-foo or python3-foo)
>The "dh_auto_install" override is used to place it in>"/usr/share/pythonpy"
>which is the proper place for Python
>*applications*[1]. Without it, it goes to the place where *libraries*
>should be located.
ok
>The "remove_entry_points_scripts.patch" avoids the creation of
>py{2,2.7} binaries that aren't needed. Without it and removing the
>override for "dh_fixperms", the package becomes useless. There's no
>way to call the "py" command, as its main script doesn't have
>execution permissions.
ok, but why some of them have the +x set?
http://debomatic-amd64.debian.net/distribution#unstable/pythonpy/0.4.4-1/contents
I wouls suggest patching the setup file to perform correctly instead of
overriding stuff.
>Looks like it would be way easier to fix the entry point scripts to
>created a binary named "py", avoiding just the other ones. We can also
>ignore the override that changes the target folder, but doing this
>feels wrong, is like we are ignoring the best practices for packaging
>Python applications. That's why I'm wrecking my head with this issue,
>removing every file that would be useless, instead of following the
>easiest path.
up to your sponsor :)
>About the lintian output:
>* "unused-file-paragraph-in-dep5-copyright": this info doesn't appear
>even when I run lintian with the same arguments on my machine. This is
>strange, as I'm running "v2.5.42.1" from sid and debomatic-amd64.d.n
>is using "v2.5.42.1~bpo8+1", which should be the same version. Do you
>know how can I do this?
swap Files: debian/*
and Files: *
first the more comprehensive and later the less.
(lintian might be more specific)
>* "debian-watch-file-is-missing": this is right. I've asked[2]>upstream to tag
>every release on GitHub, so we can fetch information
>about new versions from there.
>* "application-in-library-section": fixed[3].
>* "no-upstream-changelog": the upstream added a changelog file in the
>last version (0.4.9, which I have packaged this afternoon), but it
>doesn't comes with the tarball available in PyPI. This will be solved
>when the releases are tagged and we grab them from GitHub.
>* "package-installs-into-obsolete-dir": fixed using dh_bash-completion[4].
>
>I've uploaded the last (0.4.9-1) package version to mentors.d.n[5].
I did fix the python apps in blah section with section "utils", and uploaded on
debomatic again.
Now that lintian warning is not there anymore.
(I won't download the package, I think I already answered the points)
cheers,
G.
Re: Packaging pythonpy
Hi Tiago, >* How to fix the "python-script-but-no-python-dep" lintian error? I've >tried with and without pybuild and the error still persists. adding python to the dependencies? do you have python to build dependencies, dh-python and python:Depends on the binary package? >* How to get rid of the ".egg-info/" folder that is being packaged?>Looks like >"debian/clean" rules aren't working. it is generated *during/after* the build, so the clean target won't work. a "package.pyremove" file might help, not sure codesearch.debian.net might help egg path:pyremove$ https://codesearch.debian.net/results/egg%20path%3Apyremove%24/page_0 cheers, G. There's a GitHub repository for the package[1]. I have intention on asking for a repository on collab-maint when the package is ready (I have write permissions to it). Regards, Tiago. [1]: https://github.com/myhro/deb-pythonpy -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Re: Bug#753590: ITP: python-pyqtgraph -- Scientific Graphics and GUI Library for Python
Il Sabato 5 Luglio 2014 17:26, Andreas Tille andr...@an3as.eu ha scritto: Hi Gianfranco, On Sat, Jul 05, 2014 at 10:41:09AM +0100, Gianfranco Costamagna wrote: Hi Andreas, thanks for doing this! I propose also to change the maintainer if you think is better, don't know ;) IMHO the maintainer should be a team (either Debian Science or Debian Python) and it seems reasonable to put the team in charge which is owning the VCS where the package is maintained. Since the package technically fits into Python and from content into Science there is no clear rule to decide. The Blends framework can be used in any case. It is no requirement to maintain a package in a certain team. Anyway I'm looking for a sponsor (I already have a busy one in debian-science), Since I think that the package clearly fits into Deban Science Blend I'm fine if you would use Sponsering of Blends: https://wiki.debian.org/DebianPureBlends/SoB (I changed from python to science for a really good reason: python uses svn and science uses git, and I'm a really a git user and supporter :p ) Wonderful, I added a line on that list. Just some questions: -I did not create the git on debian-science (I'm not yet accepted by the team), but I put the url as it will be if accepted (in the meanwhile the git is also here https://github.com/LocutusOfBorg/pyqtgraph ) -I'm not sure about the field Link to Web sentinel... One drawback of using Debian Python VCS is that it is not (yet) scanned for new packages and thus the package does not yet show up on the Science viewing page. Since I'm aware about this I would not mind about this requirement of SoB. and BTW the KGB bots in debian-science are broken (mdtx tried many times to unsuccessfully contact you, so I'm taking the opportunity to make you aware of the problem) I was contacted at least twice by somebody (may be mdtx - whoever this might be) and I answered in publich to the Debian Med maintainer list (I was contacted about Debian Med KGB) that I have no idea what needs to be done and I also have currently no time to make up my mind. I personally do not use KGB features and I expect somebody else in the team to do the necessary means to fix this. If this is considered unsuccessfully contact than yes, this was unsuccessful. But I have no idea why it should be me who should fix each and any piece of infrastructure. B-) So please in cases like this contact the team or use the BTS to report the problem. Sorry, I was not so clear, I wrote unsuccessfully because the irc user asked me many times about your mail, because he wasn't sure he ad the right mail address. For this problem please forget about it, as soon as I'll be accepted on the science team (I cannot see the kgb configuration file since I'm not in the science group) I'll take care of it. I have already setup this on pkg-boinc, so I have little knowledge about the troubleshooting of this stuff. I would like just ask you if you can forward to me the kgb mail you received, just to have a starting point about the problem. Have a nice sunday, Gianfranco Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1404645456.90757.yahoomail...@web171801.mail.ir2.yahoo.com
