Re: Bug#850789: Patch upload not showing up in deferred queue

2017-01-10 Thread Gianfranco Costamagna
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 
(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!


Re: Bug#830417: RFS: django-setuptest/0.2.1-1 [ITP]

2016-07-27 Thread Gianfranco Costamagna

>I have now checked the package into the python-modules Alioth repository:

it looked good to me, uploaded.


Re: Bug#831994: RFS: python-prompt-toolkit/1.0.3-1 (ITP)

2016-07-21 Thread Gianfranco Costamagna




all are 404...

Please reopen once you get something to work on!


Re: Bug#813096: ITP: logdata-anomaly-miner -- lightweight tool for log checking, log analysis

2016-06-09 Thread Gianfranco Costamagna

(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, 
breaking stuff, this is why some dependencies are not too relaxed, to avoid 
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 

I can't say, I don't see the package installing stuff in usr/lib/python* on 

>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 

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?

>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 

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?
>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!


Re: Packaging pythonpy

2016-03-25 Thread Gianfranco Costamagna
>I really appreciate your effort in trying to package it yourself, but

>you didn't solved the main problem, which is the

indeed, control file line two.

it is an application, so choose some Section from there

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.

>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?

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)



Re: Packaging pythonpy

2016-03-25 Thread Gianfranco Costamagna
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 might help
egg path:pyremove$



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).



Tiago "Myhro" Ilieve
Montes Claros - MG, Brasil

Re: Bug#753590: ITP: python-pyqtgraph -- Scientific Graphics and GUI Library for Python

2014-07-06 Thread Gianfranco Costamagna

 Il Sabato 5 Luglio 2014 17:26, Andreas Tille 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 
 Since I think that the package clearly fits into Deban Science Blend I'm 
 if you would use Sponsering of Blends:
(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 )
-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 
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,

 Kind regards

To UNSUBSCRIBE, email to
with a subject of unsubscribe. Trouble? Contact