Bug#1055234: ITP: python-zombie-imp -- copy of the `imp` module that was removed in Python 3.12

[Gianfranco Costamagna]

Package: wnpp
Severity: wishlist
Owner: Gianfranco Costamagna 

* Package name: zombie-imp
  Version : 0.0.2
  Upstream Author :  1991 - 1995, Stichting Mathematisch Centrum Amsterdam
* URL : https://github.com/encukou/zombie-imp
* License : Python-license
  Programming Lang: Python
  Description : copy of the `imp` module that was removed in Python 3.12

Binary package names: python3-zombie-imp

 # zombie-imp
 .
 ~~A particularly mischevious act of necromancy. That is,~~
 A copy of the `imp` module that was removed in Python 3.12.
 .
 Don't use this, it'll probably trick and bite you.
 .
 .
 # Usage
 .
 Can be summoned by `import zombie_imp`.
 .
 On Python versions where `imp` was banished, reanimate it using `import imp`.
 It promises (with a sneer) to be the same as before.
 .
 Some functionality that was severed from `pkgutil` is interred
 in `zombie_imp.pkgutil`, ready for reattachment:
 .
 - `ImpImporter`
 - `ImpLoader`
 .
 .


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1034559: ITP: sphinx-favicon -- Sphinx Extension adding support for custom favicons

[Gianfranco Costamagna]

Package: wnpp
Severity: wishlist
Owner: Gianfranco Costamagna 

* Package name: sphinx-favicon
  Version : 1.0.1
  Upstream Author :  >
* URL :
* License : MIT
  Programming Lang: Python
  Description : Sphinx Extension adding support for custom favicons

Binary package names: python3-sphinx-favicon


 A Sphinx extension to add custom favicons
 .
 With Sphinx Favicon, you can add custom favicons to your Sphinx html
 documentation quickly and easily.
 .
 You can define favicons directly in your `conf.py`, with different `rel`
 attributes such as [`"icon"`]
 or [`"apple-touch-icon"`] and any favicon size.
 .
 The Sphinx Favicon extension gives you more flexibility than the standard
 `favicon.ico` supported by Sphinx. It provides a quick and easy way to add
 the most important favicon formats for different browsers and devices.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032949: ITP: sphinxext-rediraffe -- Sphinx Extension to redirect files

[Gianfranco Costamagna]

Package: wnpp
Severity: wishlist
Owner: Gianfranco Costamagna 


* Package name: sphinxcontrib-images
   Version : 0.2.7
   Upstream Author : 2020 Vasista Vovveti 
* URL : https://github.com/wpilibsuite/sphinxext-rediraffe
* License : MIT
   Programming Lang: Python
   Description : Sphinx Extension to redirect files

Binary package names: python3-sphinxext-rediraffe
 This sphinx extension redirects non-existent pages to working pages.
 Rediraffe can also check that deleted/renamed files in your git repo
 are redirected.
 .
 Rediraffe creates a graph of all specified redirects and traverses it
 to point all internal urls to leaf urls.
 This means that chained redirects will be resolved.
 For example, if a config has 6 chained redirects,
 all 6 links will redirect directly to the final link.
 The end user will never experience more than 1 redirection.
 .
 Note: Rediraffe supports the html and dirhtml builders.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032946: ITP: sphinxcontrib-images -- Easy thumbnails in Sphinx documentation (focused on HTML).

[Gianfranco Costamagna]

Package: wnpp
Severity: wishlist
Owner: Gianfranco Costamagna 

* Package name: sphinxcontrib-images
  Version : 0.9.4
  Upstream Author : Tomasz Czyż 
* URL : https://github.com/sphinx-contrib/images
* License : Apache-2.0
  Programming Lang: Python
  Description : Easy thumbnails in Sphinx documentation (focused on HTML).

Binary package names: python3-sphinxcontrib.images

 Features
 .
  Show thumbnails instead of full size images inside documentation (HTML).
  Ability to zoom/enlarge picture using LightBox2 (HTML).
  Ability to group pictures
  Download remote pictures and keep it in cache (if requested)
  Support for other formats (latex, epub, ... - fallback to image directive)
  Easy to extend (add own backend in only few lines of code)
  - Add other HTML "preview" solution than LightBox2
  - Add better support to non-HTML outputs
  - Preprocess images


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031139: ITP: arsenic -- Asynchronous WebDriver client

[Gianfranco Costamagna]

Package: wnpp
Severity: wishlist
Owner: Gianfranco Costamagna 

* Package name: arsenic
  Version : 21.8
  Upstream Author : Jonas Obrist 
* URL : https://github.com/HDE/arsenic
* License : Apache-2.0
  Programming Lang: Python
  Description : Asynchronous WebDriver client

Binary package names: python3-arsenic
 Asynchronous webdriver client built on asyncio.
 .
 Let's run a local Firefox instance.
 .
 from arsenic import get_session
 from arsenic.browsers import Firefox
 from arsenic.services import Geckodriver
 .
 .
 async def example():
 # Runs geckodriver and starts a firefox session
 async with get_session(Geckodriver(), Firefox()) as session:
   # go to example.com
   await session.get('http://example.com')
   # wait up to 5 seconds to get the h1 element from the page
   h1 = await session.wait_for_element(5, 'h1')
   # print the text of the h1 element
   print(await h1.get_text())



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031127: ITP: aiocache -- multi backend asyncio cache

[Gianfranco Costamagna]

Package: wnpp
Severity: wishlist
Owner: Gianfranco Costamagna 

* Package name: aiocache
  Version : 0.12.0
  Upstream Author : Manuel Miranda 
* URL : https://github.com/aio-libs/aiocache
* License : BSD-3-clause
  Programming Lang: Python
  Description : multi backend asyncio cache

Binary package names: python3-aiocache

 Asyncio cache supporting multiple backends (memory, redis and memcached).
 This library aims for simplicity over specialization.
 All caches contain the same minimum interface which consists on the following
 functions:
 .
 - ``add``: Only adds key/value if key does not exist.
 - ``get``: Retrieve value identified by key.
 - ``set``: Sets key/value.
 - ``multi_get``: Retrieves multiple key/values.
 - ``multi_set``: Sets multiple key/values.
 - ``exists``: Returns True if key exists False otherwise.
 - ``increment``: Increment the value stored in the given key.
 - ``delete``: Deletes key and returns number of deleted items.
 - ``clear``: Clears the items stored.
 - ``raw``: Executes the specified command using the underlying client.
 .
  .. role:: python(code)
   :language: python
 .
  .. contents::
 .
  .. section-numbering:
 .
 Usage
 =
 .
 Using a cache is as simple as
 .
  .. code-block:: python
 .
 >>> import asyncio
 >>> from aiocache import Cache
 >>> cache = Cache(Cache.MEMORY) # Here you can also use Cache.REDIS and 
Cache.MEMCACHED, default is Cache.MEMORY
 >>> with asyncio.Runner() as runner:
 >>> runner.run(cache.set('key', 'value'))
 True
 >>> runner.run(cache.get('key'))
 'value'
 .
 Or as a decorator
 .
  .. code-block:: python
 .
 import asyncio
 .
 from collections import namedtuple
 .
 from aiocache import cached, Cache
 from aiocache.serializers import PickleSerializer
 # With this we can store python objects in backends like Redis!
 .
 Result = namedtuple('Result', "content, status")
 .
 .
 @cached(
 ttl=10, cache=Cache.REDIS, key="key", serializer=PickleSerializer(), port=6379, 
namespace="main")
 async def cached_call():
 print("Sleeping for three seconds .")
 await asyncio.sleep(3)
 return Result("content", 200)
 .
 .
 async def run():
 await cached_call()
 await cached_call()
 await cached_call()
 cache = Cache(Cache.REDIS, endpoint="127.0.0.1", port=6379, 
namespace="main")
 await cache.delete("key")
 .
 if __name__ == "__main__":
 asyncio.run(run())
 .
 The recommended approach to instantiate a new cache is using the `Cache` 
constructor.
 However you can also instantiate directly using `aiocache.RedisCache`,
 `aiocache.SimpleMemoryCache` or `aiocache.MemcachedCache`.
 .
 .
 You can also setup cache aliases so its easy to reuse configurations
 .
  .. code-block:: python
 .
   import asyncio
 .
   from aiocache import caches
 .
   # You can use either classes or strings for referencing classes
   caches.set_config({
   'default': {
   'cache': "aiocache.SimpleMemoryCache",
   'serializer': {
   'class': "aiocache.serializers.StringSerializer"
   }
   },
   'redis_alt': {
   'cache': "aiocache.RedisCache",
   'endpoint': "127.0.0.1",
   'port': 6379,
   'timeout': 1,
   'serializer': {
   'class': "aiocache.serializers.PickleSerializer"
   },
   'plugins': [
   {'class': "aiocache.plugins.HitMissRatioPlugin"},
   {'class': "aiocache.plugins.TimingPlugin"}
   ]
   }
   })
 .
 .
   async def default_cache():
   cache = caches.get('default')   # This always returns the SAME instance
   await cache.set("key", "value")
   assert await cache.get("key") == "value"
 .
 .
   async def alt_cache():
   cache = caches.create('redis_alt')   # This creates a NEW instance on 
every call
   await cache.set("key", "value")
   assert await cache.get("key") == "value"
 .
 .
   async def test_alias():
   await default_cache()
   await alt_cache()
 .
   await caches.get("redis_alt").delete("key")
 .
 .
   if __name__ == "__main__":
   asyncio.run(test_alias())


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031126: ITP: aiomcache -- Minimal pure python memcached client

[Gianfranco Costamagna]

Package: wnpp
Severity: wishlist
Owner: Gianfranco Costamagna 

* Package name: aiomcache
  Version : 0.8.1
  Upstream Author : Nikolay Kim 
* URL : https://github.com/aio-libs/aiomcache/
* License : BSD-2-Clause
  Programming Lang: Python
  Description : Minimal pure python memcached client

Binary package names: python3-aiomcache
 memcached client for asyncio
 The API looks very similar to the other memcache clients:
 .
  .. code:: python
 .
 import asyncio
 import aiomcache
 .
 async def hello_aiomcache():
 mc = aiomcache.Client("127.0.0.1", 11211)
 await mc.set(b"some_key", b"Some value")
 value = await mc.get(b"some_key")
 print(value)
 values = await mc.multi_get(b"some_key", b"other_key")
 print(values)
 await mc.delete(b"another_key")
 .
 asyncio.run(hello_aiomcache())
 .
 .
 Version 0.8 introduces `FlagClient` which allows registering callbacks to
 set or process flags.  See `examples/simple_with_flag_handler.py`



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1029355: ITP: censys -- easy-to-use and lightweight API wrapper for Censys APIs (censys.io)

[Gianfranco Costamagna]

Package: wnpp
Severity: wishlist
Owner: Gianfranco Costamagna 

* Package name: censys
  Version : 2.1.9
  Upstream Author : Censys, Inc. 
* URL : https://github.com/censys/censys-python
* License : Apache-2.0
  Programming Lang: Python
  Description : easy-to-use and lightweight API wrapper for Censys APIs 
(censys.io)

Binary package names: python3-censys
easy-to-use and lightweight API wrapper for Censys APIs (censys.io)
 An easy-to-use and lightweight API wrapper for Censys APIs (censys.io).
 Python 3.7+ is currently supported.
 Notice: The Censys Search v1 endpoints are deprecated as of Nov. 30, 2021.
 Please begin using v2 endpoints to query hosts and certificates and check
 out our support center for resources.
 .


Needed for newer knockpy.

G.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021003: ITP: sphinx-qt-documentation -- Plugin for proper resolve intersphinx references for Qt elements

[Gianfranco Costamagna]

Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Gianfranco Costamagna 
Severity: wishlist

* Package name: sphinx-qt-documentation
  Version : 0.4.0
  Upstream Author : Grzegorz Bokota 
* URL : https://github.com/Czaki/sphinx-qt-documentation
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Plugin for proper resolve intersphinx references for Qt 
elements

 This is plugin to add cross-link to qt documentation for python code created 
with PyQt5 or PySide2.
 Currently, it supports qtpy, Qt.py wrappers and PyQt5, PySide2, PyQt6 and 
PySide6.
 This extension provides one configuration option:
 qt_documentation with possible values:
 .
  * PyQt5
  * Qt5
  * PySide2
  * PyQt6
  * Qt6
  * PySide6

I need it for the new python-pyqtgraph version

Bug#963924: libdc1394-22 -- RoQA; Superseeded by libdc1394

[Gianfranco Costamagna]

control: reassign -1 ftp.debian.org
control: retitle -1 libdc1394-22 -- RoQA; Superseeded by libdc1394

Hello,
looks like the new libdc1394 took over the libdc1394-22-dev as transitional 
packages, and rebuilds have been performed
for reverse-dependencies to move to the new version.

Can you please just remove the old one from the archive?

thanks

G.

Bug#940121: ITP: sphinxcontrib-svg2pdfconverter -- Sphinx SVG to PDF Converter Extension

[Gianfranco Costamagna]

Package: wnpp
Owner: Gianfranco Costamagna 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: sphinxcontrib-svg2pdfconverter
  Version : 0.1.0
  Upstream Author : 2018-2019 by Missing Link Electronics, 2018-2019 by Stefan 
Wiehler
* URL : https://github.com/sephalon/sphinxcontrib-svg2pdfconverter/
* License : BSD-2
  Programming Lang: Python
  Description : Sphinx SVG to PDF Converter Extension

 This extension converts SVG images to PDF in case the builder
 does not support SVG images natively (e.g. LaTeX).
 .
 Internally, either Inkscape or rsvg-convert from libRSVG as a more
 lightweight alternative is used to convert images.
 .
 This package contains the Python 3.x module.


I need this package to fix nbsphinx RC bug #939492 due to new pandoc currently 
in unstable.

Cheers,

Gianfranco

Bug#924368: I'll take it

[Gianfranco Costamagna]

On Tue, 12 Mar 2019 16:09:35 +0100 Adam Borowski  wrote:
> Control: retitle -1 ITA: btrfs-progs -- Checksumming Copy on Write Filesystem 
> utilities
> Control: owner -1 !
> 
> As a long-time user ("thou shalt have no other filesystems before btrfs")
> and an occassional contributor, I can take it.
> 

Thanks Adam for taking care of it!
Just a side note: I think I sponsored a lot of backports for Nicholas in the 
past,
he is a good contributor, and he sends patches upstream and to Debian packaging 
(dated 2017).

Maybe you can both work on the package, he is a DM so he might even upload by 
himself if you
feel comfortable with his work (Nicholas please tell us if you are still 
interested in btrfs!)

In any case, two is better than one, specially when one is an upstream 
contributor and Debian maintainer :)

I hope to see Nicholas back in the team :)

G.

Bug#902429: ITP: haskell-bindings-uname -- Low-level binding to POSIX uname(3)

[Gianfranco Costamagna]

Package: wnpp
Severity: wishlist

* Package name: haskell-bindings-uname
  Version : 0.1
  Upstream Author : PHO 
* URL : http://hackage.haskell.org/package/bindings-uname
* License : public-domain
  Programming Lang: Haskell
  Description : This is a low-level binding to POSIX uname(3)


I'm packaging this as a dependency of haskell-stack.

I intend to maintain it as part of the Haskell team.

Gianfranco

Bug#902415: ITP: haskell-servant-client-core -- library for writing clients for servant webservices

[Gianfranco Costamagna]

Package: wnpp
Severity: wishlist

* Package name: haskell-servant-client-core
  Version : 0.13.0.1
  Upstream Author : Servant Contributors 

* URL : http://haskell-servant.readthedocs.io/en/stable/
* License : BSD-3-clause
  Programming Lang: Haskell
  Description : library for writing clients for servant webservices

I'm packaging this as a dependency of servant-client.

I intend to maintain it as part of the Haskell team.

Bug#867251: ITP: vim-bitbake -- Vim plugin to interact with Yocto bitbake-based recipes

[Gianfranco Costamagna]

Package: wnpp
Owner: Gianfranco Costamagna <locutusofb...@debian.org>
X-Debbugs-CC: debian-de...@lists.debian.org
Severity: wishlist

* Package name: vim-bitbake
* Version : 0~git20170705-1
* Upstream Author : Chris Larson <kerg...@handhelds.org>
* URL : https://github.com/kergoth/vim-bitbake
* License : MIT/Expat
* Description : Vim plugin to interact with Yocto bitbake-based recipes

This set of scripts helps in creating new yocto recipes from scratch,
and adds highlighting on the already written ones.

Gianfranco



signature.asc
Description: OpenPGP digital signature

Bug#834145: ITP: wafw00f -- Identify and fingerprint Web Application Firewall (WAF)

[Gianfranco Costamagna]

Hello,


>" We kindly ask you to only use these themes in an unmodified manner just
> for Flask and Flask-related products, not for unrelated projects.  If you 
> like the visual style and want to use it for your own projects, please
> consider making some larger changes to the themes (such as changing
> font faces, sizes, colors or margins)."


I would ask ftpmasters or debian-legal, but since words used are "kindly ask"
"please consider" I guess this is acceptable.

(so much border line licensing I would say)

G.

Bug#832508: O: systemd-shim -- SysVinit shim for systemd

[Gianfranco Costamagna]

Hi,

On Thu, 1 Sep 2016 13:45:09 -0400 Ab B  wrote:
> I'd be interested in becoming the sponsored maintainer of this
> package.  It seems like it would require a fairly low level of
> attention.  It looks like it's used by ~14,000 installations, so it
> does seem like it should be maintained.  I suppose I'd need a DD as
> sponsor?  I've asked the systemd mailing list and asked to join the
> systemd project on alioth.

the best way to find a sponsor is by forking the git repo somewhere else,
show your packaging skills by fixing bugs and refactoring the packaging
(or whatever is needed), and then ask to adopt it.

We can't blindly sponsor stuff just because of somebody is interested, an
unmaintained package is better than a badly maintained one :)

I can't see your name/surname/ddpo page, so I can assume you don't maintain
any debian stuff right now?

Gianfranco



signature.asc
Description: OpenPGP digital signature

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

[Gianfranco Costamagna]

Hi,

>Changed the Build-Depends, binary depends  are now generated by dh_python2.



wonderful
>Ah, I see. I assumed that the patch editor would cut the lower part in same 
>fashion as git/svn would do. Fixed.


nack

.
logdata-anomaly-miner (0.0.2-1) unstable; urgency=low
.
* Initial inclusion of logdata-anomaly-miner to Debian
(Closes: #813096)
Author: Roman Fiedler 
Bug-Debian: https://bugs.debian.org/813096


this seems useless ^^^
you need to close a specific bug, not the itp one
(or just delete the lines if there isn't a debian bug corresponding
to the patch)

>Done.


correct

>I will check, if the above link contains more useful fix when back home from 
>travelling, here this is somehow problematic.


I looked at it, you did almost the same changes, no need to check anymore

>Package with fixes for changes mentioned above uploaded to mentors, should be 
>visible in some minutes hopefully.


I guess we are mostly ok!

G.

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

[Gianfranco Costamagna]

Hi,

new issues:

please change python-dev to python-all (you have an arch:all package here)


patches have useless description, please make a real one (bonus if you rename 
patches to end with .patch)

rules: useless the dk_link stuff (you already have a file.link).

you can grab some of the above fixes from here, please do the remaining stuff
http://debomatic-amd64.debian.net/debomatic/unstable/pool/logdata-anomaly-miner_0.0.2-1/logdata-anomaly-miner_0.0.2-1_sourceupload.changes
(debdiff is a good friend, to show them)

G.

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

[Gianfranco Costamagna]

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.

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

[Gianfranco Costamagna]

Hi


>I had already added it already to
>* control
>Depends: ${python:Depends}, python-tz, ${misc:Depends}

>which was mangled (with warning) to:

maybe you are installing the files in usr/lib/foo, instead of usr/lib/python*/
and then dh_python2 is not acting correctly?
I don't think installing python stuff outside that directory is a good idea...


>@@ -1,4 +1,4 @@
>-#!/usr/bin/python2 -BEsSt
>+#!/usr/bin/python2.7 -BEsSt


this should be also handled by dh_python2 AFAIK

>Everything seems to work without it also and the same package could have been
>used for python2.6 and python2.7 systems but lintian does not understand that.


well, installing into usr/lib/python* should fix that issue


I would prefer you to ask on debian-python about this issue, because I'm 
wondering
about something bad that is just hidden and will be spot when the package 
enters the
archive.

having an ack for a more python-savvy person would be great
(I could even sponsor the package as-is, but I'm not too confident with that)

>I hope this fixed all the review comments for regarding the packaging. I would 
>like to keep the deeper restructuring of upstream code + Debian packaging 
>scripts for upstream/Debian release V0.0.3. Is that OK from Debian side?


it is ok to have new uploads, don't worry about that, I just would like to have 
a feedback
from another DD before uploading/finish the review.


is it possible for you?
otherwise let me know and I'll finish the review and do the final checks+upload.

G.

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

[Gianfranco Costamagna]

Hi

> I still don't see "python" in build-dependencies.



>I tried that already, but somehow it did not work out (that's why the manual 
>"python2.6 | python2.7" is kept).

the reason should be the missing python dependency and the missing dh_python2 
call

>I'll stay on that one (see todos), at the moment I am trying to figure out 
>with strace what the rule
>
>/usr/share/dh-python/dh_python2 -p logdata-anomaly-miner 
>usr/lib/aminer/AMiner usr/lib/aminer/AMinerRemoteControl
>
>is doing and why it does not detect the correct version to pass it on to 
>dpkg-gencontrol.


don't know, dh --python2 should do the job.
not sure why you override that



>You are good! Funny, how dumb one can be ... Just used the stubs from previous 
>packages without thinking ...


:)

IIRC I did the same mistake some years ago :D


>Would that split of old postinst solve all problems without provoking new 
>ones?


I guess so
>a) new preinst: the user/creation (with #DEBHELPER#)
>b) postinst: chmod/chown, .. changes to files (WITHOUT the #DEBHELPER#)


with DEBHELPER too.

preinst <-- user creation
postinst <-- systemd start (automatically)


prerm <-- systemd stop (automatically)
postrm <-- user del and whatever

I'm not completely sure, just try, test and look at the policy
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
>OK, I have deleted for now. What about the suggestion with the CHANGELOG?
>
>Currently debian/changelog is the "packaging changelog". But the software has 
>also a "feature/version changelog". Where should that be kept best? Options:


dh_installchangelogs is your friend :)
(but files that has similar names are added automatically I guess, just check if
it is added or not

>I have removed that part, both unused options and the error handling.


it should already be handled in the DEBHELPER macro, right?
>Thanks for the pointer to quilt. Seems to make sense, is on the todo list.

ok

>Understood, quilt will do here also.

yes
>OK, I will change. There is only one question open at the moment: what is the 
>Debian policy for versioning of those Debian-specific build files? Could they 
>be hosted just anywhere, e.g. adding them to the same upstream repository, 
>used to build the source.tar.gz or should the go to a separate repository, 
>perhaps even under control of Debian folks like the "Debian collab platform"? 
>Would https://wiki.debian.org/Alioth/PackagingProject make sense?


whenever you want, a "debian" branch in upstream packaging, a directory on your 
pc
whenever is convenient for you (also alioth, collab-maint, github)

having a different branch on git will make the packaging of new releases easy as
git checkout debian
git merge vVERSION-tag
dch
and so on
(YMMW)

>Thank you very much for your answers and patience, I will do a clean package 
>build after doing some more reading/testing.

keep your time :)

>Todos:
>* Fix: " dh --with=systemd,python2" somehow fails to substitute 
>dependencies/version in control
>* Check transition to "pybuild" and possible side effects (see mails 
>~2016-06-02) after solving the dependency problem
>* Enable quilt mode to patch upstream Launchpad source.tar.gz after deciding 
>about versioning of Debian-specific patches.


irc/OFTC and #debian-python/#debian-mentors channels might be your friends,
as well as manpages :)
(or the debian-mentors mail list)
G.

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

[Gianfranco Costamagna]

Hi

>Strange, the debian-mentors did not show those and also running "lintian 
>logdata-anomaly-miner_0.0.2_all.deb" locally does not yield all of those. 
>Trying to fix >anyway:


mentors is about source uploads, lintian on binaries can't run there

> E: logdata-anomaly-miner: python-script-but-no-python-dep
>Tried to follow the guidelines, seems that everything works but lintian is 
>still complaining. Changes recommended from various forums:

>Any ideas would be appreciated. Otherwise I'll just add a workaround to get 
>rid of the lintian error.

I still don't see "python" in build-dependencies.

BTW your rules hack is wrong, please just call dh --with=systemd,python2

BTW "python2.6 | python2.7" <-- please remove dh_python2 should handle them too

> W: logdata-anomaly-miner: maintainer-script-calls-systemctl prerm:30
> W: logdata-anomaly-miner: maintainer-script-calls-systemctl prerm:31

Gone by following changes  (BUT read below):

>CAVEAT: Although lintian is happy, there are two issues with that change, that 
>may/are problematic:
>
>a) I moved the DEBHELPER in prerm BEFORE my code to delete the users. Is the 
>DEBHELPER code really intended to be run before or may this cause other issues?


what about a "postrm" script?

>b) In postinst DEBHELPER will automatically activate the systemd unit. But 
>this was not done INTENTIONALLY! Therefore documentation included a section, 
>what to >check/do before activating the service to avoid any risks. Are there 
>means to get to that state also with the dh-systemd components?


preinst?

>Thanks for the hint. If I understand correctly, pybuild will only care about 
>maintaining the dependencies to the python packages and which interpreter to 
>use but it >will NOT require the software to load from site-packages or to 
>create/use pyc files, which is currently avoided due to security reasons?


I'm not sure :( sorry

>According to Debian manual, this should be used to automatically include files 
>from uppermost directory of the unpacked source. Currently there are no useful 
>files >at this location, all documentation is included directly from 
>source/root/usr/share/doc/aminer/. Would following files be sufficient?


an empty file can be deleted, if you have no documentation, but having an empty 
file should be avoided
(I don't like them, they overcomplicate packaging and are just useless)

>This was a workaround for a problem (build error), which seems to be fixed by 
>restructuring of the build anyway. Removed.


yes, the reason for asking you is: "please create directory at build time, 
don't ask Debian to create them, because the problem is general, not Debian 
specific)

>Current content is "root/* ." There is no compiling involved, so this copies 
>just the plain files into the package. Is there something else to be used for 
>this >purpose?


not sure, does dh_systemd correctly handle the service file?


>How should that work? In generated DEBHELPER code I do not see any commands 
>that would create the users? If you mean the length of " 
>>abort->upgrade|abort->remove|abort-deconfigure": this is from dh-make, should 
>that be changed?


yes, just override what you need, don't put default stuff there
(and open a built-deb file, you will see the #DEBHELPER# macro substituted


>This was not really planned. The idea behind the package structure was to have 
>only one repository to maintain to build the packages for both Debian/Ubuntu. 
>Will >the Debian/Ubuntu requirements be that different in the end, that 
>maintaining a single code base for building is not possible anyway? In such 
>scenario are those >changes the best?


create an upstream tarball, and switch to quilt mode, the code doesn't change 
for Debian, or Ubuntu, and makes easier for other linux
distros to use it.

>* Move the debian/ stuff in the upstream repository to debian-templates/ (not 
>packaged)


not requested.

>* Create a downstream repository, e.g. at the "Debian collab platform", where 
>the upstream source.tgz is loaded automatically and only the debian/ stuff is 
>stored

>Does that make sense?


you can also just remove the debian from the orig tarball, and add it on top of 
your changes after unpacking the orig tarball.


(I hope I answered to everything)

G.

Bug#800771: Bug#809623: telegram-purple package has been removed from Mentors

[Gianfranco Costamagna]

Hi, feel free to reopen whenever you want :)

G.





Il Giovedì 2 Giugno 2016 12:36, Ben Wiederhake  ha 
scritto:
Control: close -1
Control: thanks

Am 02.06.2016 um 05:25 schrieb mentors.debian.net:
> Your package telegram-purple all versions has been removed from 
> mentors.debian.net for the following reason:
>
> Your package found no sponsor for 20 weeks
>
> Thanks,

As there is no upstream activity (partly my fault, sorry), I'm closing 
this ITP and RFS.

Regards,
a somewhat sad Ben

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

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

Hi, lets review:


1) one single changelog entry and close the ITP bug

2) lintian
W: logdata-anomaly-miner: readme-debian-contains-debmake-template
E: logdata-anomaly-miner: description-starts-with-package-name
W: logdata-anomaly-miner: description-starts-with-leading-spaces
W: logdata-anomaly-miner: extended-description-line-too-long
W: logdata-anomaly-miner: spelling-error-in-description-synopsis allows to 
allows one to
I: logdata-anomaly-miner: spelling-error-in-manpage 
usr/share/man/man1/AMinerRemoteControl.1.gz allows to allows one to
E: logdata-anomaly-miner: python-script-but-no-python-dep usr/lib/aminer/AMiner
E: logdata-anomaly-miner: python-script-but-no-python-dep 
usr/lib/aminer/AMinerRemoteControl
W: logdata-anomaly-miner: maintainer-script-calls-systemctl prerm:30
W: logdata-anomaly-miner: maintainer-script-calls-systemctl prerm:31

3) a pybuild system might make the packaging easier to maintain

4) d/docs <-- empty

5) debian/logdata-anomaly-miner.dirs
debian/logdata-anomaly-miner.install

why?

6) watch: please ask on debian-mentors mail list or irc (OFTC/#debian-mentors)

7) std-version is 3.9.8 now

8) postinst has too much stuff
abort-upgrade|abort-remove|abort-deconfigure)
;;

*)
echo "postinst called with unknown argument \`$1'" >&2
exit 1
;;


##DEBHELPER##
should take care of that part


9) prerm too, I think systemd already know to stop services during removal.

10) debian/source/format -> quilt, not native

why do you have a native package? seems not something Debian specific


apt-get install check-all-the-things -t experimental

$ check-all-the-things

$ codespell --quiet-level=3

$ find \( -name .git -o -name .svn -o -name .bzr -o -name CVS -o -name .hg -o 
-name _darcs -o -name _FOSSIL_ -o -name .sgdrawer \) -prune -o -empty -print

$ fdupes -q -r . | grep -vE 
'/(\.(git|svn|bzr|hg|sgdrawer)|_(darcs|FOSSIL_)|CVS)(/|$)' | cat -s

$ pep8 --ignore W191 .

$ pyflakes .

$ pyflakes3 .

# Users of binary packages do not need install instructions.
$ find -type f -iname '*README*' -a ! \( -iname README.md -o -iname 
README.install \) -exec grep --ignore-case --fixed-strings --with-filename 
install {} +
./root/usr/share/doc/aminer/Readme.txt:Installation Requirements:

$ grep -riE 'fixme|todo|hack|xxx' .


out of time right now, if you can fix the above I'll do another trip.

cheers,

G.



Il Lunedì 18 Aprile 2016 20:15, Fiedler Roman  ha 
scritto:
Hi,

I tried to address the issues from the first review for V0.0.0 at
http://mentors.debian.net/package/logdata-anomaly-miner, the changes are now
in the V0.0.2~pre0 package uploaded.

But still there are some points not completely clear to me:

Issues from  https://www.debian.org/doc/debian-policy/

* I tried to follow this one, but seem to have overlooked some points. Could
someone please give me a pointer?

Issues from https://www.debian.org/doc/packaging-manuals/python-policy/

* Python3: As this software especially targets production use, currently
Python 2.6 is attempted to allow use over a broad range of OS. If community
is sufficiently large to support a parallel Python2/3 development, Python 3
support is definitely a goal.
* Python2 reference from package: Changed from
  #!/usr/bin/python -BEsSt
  to
  #!/usr/bin/python2 -BEsSt
  Is this sufficient to address the issues from the review?
* Python package dependency: Not sure how to handle that in suitable way:
there is no abstract "python2" package, so add a control file for to source
tree for each distro to build for having the correct "python2.X" dependency
in it? Or would that be better:
  "Depends: python2.6 | python2.7, python-tz, ${misc:Depends}"
  As second solution seems simpler, I prefer that.
* Arch-dependency: Currently the code calls directly into libc as Python is
missing quite all syscalls for secure filesystem interaction.
  Apart from that, no use of arch-dependent .pyc files is made: the tool is
long-running, so the overhead acceptable and all the .pyc-related attack
surface can be skipped for the uid=0 part of the program.
  Considering that, is there a change of package structure needed and if
yes, which?

Issues from https://packaging.python.org/en/latest/distributing/:

* Does this really apply? Currently the components are packaged as
application, use as a module was not attempted/tested yet. Perhaps split the
application from the module later on? Current layout should be compliant
with
https://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html,
depending how the libc link for different CPU-archs is treated as mentioned
above.

@Native package:

* Currently this mode chosen, as there is only a single source code
repository for open-source upstream development also holding the Debian
packaging stuff. What would be right way to split that? Remove Debian-part
from upstream and instead add it to debian collab platform? Or keep both
mixed but split build process into 

Bug#817777: ITP: dask -- Dask is a simple task scheduling system that uses directed acyclic graphs (DAGs) of tasks to break up large computations into many small ones.

[Gianfranco Costamagna]

Hi, what is the status of this one? is it a blocker for scikit-image,
or do you want to upload scikit now and comment the dask patch when this one
enters the archive?

cheers,
G.

Bug#816509: RFA: nltk -- Python Natural Language Toolkit

[Gianfranco Costamagna]

Hi Daniel, Himadri, Saurav,

> if somebody wants to take over the maintenance of Nltk that's all right with 
> me. It's a very
> important and popular Python library (Pypi downloads last month: 133k).

I did prepare an update of nltk a few seconds ago, and pushed on git and 
deferred/5

snip of the changelog:

  * Team upload.
  * Fix watch file (now in https mode)
  * Bump std-version to 3.9.8, no changes required.
  * New upstream release, patch refresh.
  * Drop fix-sfs-address.diff: upstream
  * Update copyright years.
  * Fix insecure VCS fields.
  * Remove source/local-options file


I don't plan to add myself as comaintainer, since there are already two offers 
in this bug.
but I'll take care of it if nobody steps up, because it will show up under my 
ddpo now :)

Himadri, Saurav, feel free to join the debian-science team and update/fix bugs 
if you have something to do, or
feel free to send patches to me and I'll apply them (and eventually add you as 
comaintainer if I like your packaging skills :p

thanks you all for the offers!

(I admit I wouldn't have done the work if I had found this bug before :p )

Gianfranco



signature.asc
Description: OpenPGP digital signature

Bug#754472: I'd love to help

[Gianfranco Costamagna]

Hi Luis and Marcus

On Wed, 22 Oct 2014 17:37:13 +0200 Marcus Hufvudsson  
wrote:
> Hi! I also volunteer to adopt this package. Get back to me if no one
> adopted this (last reply in July)

I/We did a lot of work recently to bring all the required dependencies on 
Debian.

now we should have all of them, and a git snapshot ready to be uploaded soon(TM)

you both expressed your willingness to contribute, and this is so much 
appreciated now
that the package is becoming usable again.

there are some/many lintian issues that should be fixed/discussed/checked.
e.g. some privacy issues, embedded libraries and so on.
we need to understand if we use them, and in case to strip from the tarball or 
patch
them.

the repo is on collab-maint/w3af.git, how do you feel about helping us in 
fixing lintian stuff?
there is even a debian/TODO file, explaining what needs to be done!

thanks in advance for your help!

Gianfranco



signature.asc
Description: OpenPGP digital signature

Bug#794109: ITP: python-pypandoc -- Python wrapper for pandoc

[Gianfranco Costamagna]

Hi Elena, what is the status of this ITP?
do you have some work done, or do you need a sponsor?

thanks

Gianfranco



signature.asc
Description: OpenPGP digital signature

Bug#821210: Ready for review: firefox-branding-iceweasel

[Gianfranco Costamagna]

Hi, some general nitpicks.


You really should team-maintain it
https://qa.debian.org/developer.php?login=pkg-mozext-maintain...@lists.alioth.debian.org
should be the right place.

licenses in debian/copyright needs to be verbose, not links

you have to open an ITP bug, then upload on mentors.debian.org
and ask an RFS bug.

somebody from pkg-mozext might give you a review of the package after that :)

(ccing Sean, who is doing a great job on pkg-mozext :p )

thanks for the work!

Gianfranco




Il Sabato 16 Aprile 2016 20:25, nord-stream  ha 
scritto:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I've just created a native package firefox-branding-iceweasel, which
can be built off the git repository at
https://notabug.org/desktopd/iceweasel-branding

This is installed as a Firefox extension. I hope that this will be
available when Iceweasel disappears from stable. Mozilla Extension
Packaging Team may be relevant.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXEoHWAAoJELLXhgqJeBA2vGcQAIzZKXVFoGOWwux0gzahplU/
pkVfIvY9Oa/GbcftQ8IeTX4Im8dd53uK/t5siB5hCGI6dRKcmaeMb6zka4REUDiX
IjTC3S4zgwS9MW/gZe97JJ4kit3ITeBvT8+f1Srv0qsUE3dTLxjyYCn7kYhCQhbG
fHrkD8XCBNAevLXE70wSBxTPS1TILedTHp1fF0vtBOconSbqL+uxkUyyyxJutzZ9
zDrVLMfpNf/8s4S/FSoYVAv3sNwSgfY8i0Q4jBEwxCBpl9MzrBeVySUSJvtvFDDV
1xxiOcuUwNg95U0gEqQMGAmKfMOEWZT2PkrgI/O9MmNU9ZKPoIsChP/1zvpLOJIQ
J+xqpKNropb+HOvQyv9i/Ecw5qRIdaC9aCO0BazJHJKCTOGnMOnniP8rYaCXVoH/
IB1QHKmYWkZ0YxjUT9as+jiGvKO+RAmzjULEsWN72rdVSfDT68SAHcmBNakeVyw7
HotSFYh0xQ6gwN+sevYFkXhg5FH3SK341Sv0Hk/cVc0WB5+nFZr7CbF6jb4jD7pw
6CEGJ5vYTicQ1rsE/U/SMgU4pQNCDRCdLv7IU8IpsKJzqr1HGd6vVnjtZ13ALKiF
DFQxK1uEzalCHydmQh1CEwUC2bXAZQVuwAKUvwyj9YY28ZtvP3aWzc7udF3m4J2l
TVRjg7owglh5GS+zerK+
=d7dw
-END PGP SIGNATURE-

Bug#697821: ITP: ppsspp -- ppsspp: A portable PSP emulator.

[Gianfranco Costamagna]

(disclaimer to Adrian, I don't want to steal that package to you :) )



Hi Serio, Adrian,


>Yes, I'm aware of that. I was busy fixing the fallout of the libpng1.6 
>transition and there is lots of packages that we need to fix.


FYI, we are currently tracking problems here, feel free to contribute or check 
here if we already have fixes (or schedule give-backs)

https://titanpad.com/SjTUuZTd01
>Well, I'm not quite sure why you care about that. The package has to be 
>reviewed by a Debian Developer anyway. So, you don't have to do that.


I'm stepping in just because I would like to see if the package builds, to spot 
libpng1.6 issues.

Just some stuff I saw in my quick trip.
fonts-droid is a virtual package, either choose fonts-droid-fallback or 
whatever else
lintian overrides are wrong:
paragraph at line 101 (override comment: lintian false positives)

this is because the copyright has to list from the generic to the specific files

so, swapping e.g.
Files: Common/Crypto/*
Files: Common/Crypto/sha256.*
Files: Common/*

to
Files: Common/*
Files: Common/Crypto/*
Files: Common/Crypto/sha256.*

should fix the issue.

Hope this helps,

another "nitpick"/issue
+find_path(PNG_PNG_INCLUDE_DIR NAMES "libpng16/png.h")


please please please use libpng/png.h instead, I don't want another ton of NMUs
for the next png transition
(also all the includes are wrong #include is completely legit and 
ok)


I leave the other stuff to your sponsor, I tried to keep the review png-related 
only


thanks to you both,


Gianfranco

Bug#697821: libpng-dev in experimental has now the real package

[Gianfranco Costamagna]

Hi,


>Sounds great, thanks for all your efforts in the libpng transition!


I did very little, most effort was by Tobias :)

>like to help you with Retroarch which you have uploaded to mentors.
>
>A friend of mine is interested in having Retroarch in Debian and
>he asked me to step in.


wonderful! as a starting point, can you please consider having a look to my
first review steps?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811214

don't hesitate to set yourself as owner :p
>Well, I'm not member on the official buildd team (yet), I'm just
>controlling ports, so you'd have to ask them for such binNMUs.


ok
>Yeah, I agree. We should definitely ask for binNMUs.


well, I don't remember exactly what was uninstallable, but I tried an
apt-get install libfreetype6 libpng-dev and it worked.

it dragged the old libpng12-dev and the new libpng-dev, so in some way both 
libpng have
been successfully installed.

So, it might even work without binNMUs if we are enough lucky :)


>No worries, some things take time!

I hope to see it fixed in less than one month, we are still fighting with 
multiarch
stuff [1] (an hint is appreciated!)


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650601#908


I think a non-multiarch libpng would be a mess in Debian

thanks!

Gianfranco

Bug#697821: libpng-dev in experimental has now the real package

[Gianfranco Costamagna]

Hi, FYI I uploaded yesterday a libpng-dev pointing to libpng16-16 package.
In the next few days everything uploaded in experimental will start building 
against
this, and I hope to have a transition inplace in the next few days/weeks.


So, ppsspp might have some better chances now to go in Debian.

Adrian, do you think you can ask some experimental binNMUs against the new 
libpng
to make stuff installable?
that way you will be able to test the package if I remember correctly the 
situation
we have left some months ago.

thanks and sorry for the delay,

G.

Bug#799268: ITP missing for package python-ck with RFS 799268 with ITP in title

[Gianfranco Costamagna]

Hi, I fixed a lot of stuff, e.g. https links, arch: any to arch: all,
retitled to ITP, fixed duplicate short description, fixed changelog
date, std-version to 3.9.7, removed the conflict on python3-all (wrong),
and something more, signed and uploaded a few seconds ago.

(sorry for the long wait)

thanks for the contribution to Debian!
I'm attaching the uploaded packaging to this email.

cheers, and thanks for the packaging,

G.


python-ck_1.6.14-1.debian.tar.xz
Description: application/xz


signature.asc
Description: OpenPGP digital signature

Bug#801253: O: wicd -- wired and wireless network manager

[Gianfranco Costamagna]

Hi

>i won't adopt the maintainership for wicd, mainly because of upstream's 

>inactivity. Basically, it seems that Tom van Braeckel is the only 
>contributer currently, who doesn't have the time and priority to 
>actively develop wicd. Therefore i don't see in wicd a future.


wicd has been picked and abandoned from upstream a lot of times
(I happen to know the original creator of the tool).
Open Source works this way, people starts projects, leaves them,
somebody picks them up again.

Until the package gets broken again you won't probably notice upstream
activity, but until users will care about the tool, I'm pretty sure somebody
will patch it and make it work again.

So, dead upstream is not true, unless nobody cares about it.

>  I'm really interested in the technology, as well as debian packaging 
>Hence, I'll ask in other debian teams/packages for contributing.


we will be there :)

>I'd like to thank you all for the great support and the very kind 
>explanations, it is really a wonderful and very constructive environment 

>to work in.

you did a good job!
the package is in a nice shape now, don't forget to contribute if you find 
issues :)

cheers,

Gianfranco

Bug#815763: ITP: libfilezilla -- build high-performing platform-independent programs

[Gianfranco Costamagna]

Package: wnpp
Severity: wishlist

* Package name : libfilezilla
Version : 0.4.0.1
Upstream Author : Tim Kosse 
* URL : https://lib.filezilla-project.org/
* License : GPL-2+
Description: build high-performing platform-independent programs (development)
Free, open source C++ library, offering some basic functionality to build
high-performing, platform-independent programs. Some of the highlights include:
.
- A typesafe, multi-threaded event system that's very simple to use yet
extremely efficient
- Timers for periodic events
- A datetime class that not only tracks timestamp but also their accuracy,
which simplifies dealing with timestamps originating from different sources
- Simple process handling for spawning child processes with redirected I/O
.
This package contains the development files for the library.

Bug#801253: reason not to upload new versions as fast as possible to unstable? (expect attempt to migrate to testing )

[Gianfranco Costamagna]

Hi,



>the wicd package currently has version 1.7.3 in unstable and testing, 
>but 1.7.4 is already imported. Generally speaking it seems to me very 
>reasonable to try to upload versions as fast as possible into unstable 
>and testing, so I'm just asking for clarification:
>
>Apart from wanting to migrate a version from unstable to testing, is 
>there any reason not to upload new upstream versions as fast as possible?


there shouldn't be any reason, but I'm pretty sure Axel will take care in the 
next few days.

cheers,

Gianfranco

Bug#801253: O: wicd -- wired and wireless network manager

[Gianfranco Costamagna]

Hi,

>generally speaking, what can i do in maintaining the wicd package, exept 
>fixing bugs (e.g. also the todo bug listed in the changelog) and 
>uploading new upstream versions?


fixing bugs and keeping the package up-to-date, is so far the best
thing you can do with the package (as maintainer) :)

cheers,
Gianfranco

Bug#801253: O: wicd -- wired and wireless network manager

[Gianfranco Costamagna]

Hi,

>my first commit:
>https://github.com/toogley/pkg-wicd/commit/4ade5ad71c1c50be9cd3748742042ff34a428fb1

>why do you say the "main development" is done in master, and not in 
>stretch, as stretch is merged into stable after a while?


no, master is usually what is uploaded in unstable.
After some days in unstable, if nothing breaks, the package reaches "testing"
that now is called "stretch", and becomes candidate for the next Debian stable 
release.

Once Stretch is released, testing will be called in another way (Buster) and 
the packages
will become flowing from unstable in Buster
(and the testing at this particular day will be called "Stretch")

>==> we would then merge sth unstable/without any testing into the stable 
>branch, which doesn't make sense to me.
>
>Or did you just said that because i was trying to build from jessie?


you need to build from sid, and to test changes on sid.
you can't upload to jessie since it is already released (well, you might make 
some patches
as proposed-update, but no new releases, and not in the normal development, 
when first you need
to fix a bug in sid, let it go in testing, and then you can cherry-pick a fix 
for jessie/wheezy and so on)


after opening a bug against release.debian.org metapackage
>
>Sry. i didn't realize that the files generated by the git buildpackage 
>are just build artifacts. I thought of them as regular config files, so 
>i wondered why you hadn't added them.


exactly.


Your commit is partly correct.

The new po file is added correctly, but the changes in debian/patches are 
useless/wrong.

debian/patches are used for patching the *source* tree, not the debian 
directory.
this way the orig tarball is always the same, and we apply/unapply patches 
during build.

since you changed something in debian directory, you can just commit and live 
happy.

BTW to see if you need to create a patch, try to change something in the source 
tree (don't commit please!)
"dpkg-source --commit"
will compare the source tree with the orig tarball, and extract patches in the 
debian directory automagically.
(quilt will also help you in managing them, and also add-patch tool).

BTW, now you need to provide a log, and to check the built binaries, to really 
be sure that file entered in
the build directory.

I'm not sure the po file needs some other changes to be correct.

other issues: you need also to create a new changelog entry
"fix blah/foo/bar: closes: #759884" or similar.

and specially, since you committed something handled by debconf (translation of 
debian specific strings),
you might also want to run debconf-updatepo to update the strings.
(look e.g. to virtualbox-ext-package source package, where I run 
debconf-updatepo in clean target, just to
avoid such situations :) )

cheers!

Gianfranco

Bug#801253: O: wicd -- wired and wireless network manager

[Gianfranco Costamagna]

> orig tarball doesn't have the same source anymore,


Could you please explain that?


the source tree has the same content has the orig.tar.gz tarball.
if you commit a change outside the debian directory), the content changes
simple as this.

So, you can commit only changes in debian directories, while the other changes
can be done on new upstream releases.
(google has many manuals about debian and quilt format)

>> (look e.g. to virtualbox-ext-package source package, where I run 
>> debconf-updatepo in clean target, just to
>> avoid such situations :) )
>What file/commit/whatever are you referring to? I couldn't found sth
>related in your git logs.

I mean adding debconf-updatepo in override_dh_clean: (rules file)

cheers,

G.

Bug#801253: O: wicd -- wired and wireless network manager

[Gianfranco Costamagna]

Hi,


>oh, i've just overlooked that part of your explanation regarding the 
>master/sid branch...


lol wonderful!

> What do you mean by that? I mean, if i revert/correct my changes with
> another commit, doesn't that lead to a confusing git history, as my
> commit was not correct?


everybody does mistakes, this is why "git revert" exists in first place.

But your changes in the debian directory (I mean the git history) is not
uploaded in unstable in any way, so it will just be part of the packaging 
history.

The main issue is when you commit something in the source directory, then the
orig tarball doesn't have the same source anymore, and you have 
dpkg-buildpackage
fail because of modified source.

this is an issue, while everything you commit inside the debian directory isn't
(I mean, the commit itself isn't an issue, the changed stuff it might be :p )

cheers,

G.

Bug#801253: O: wicd -- wired and wireless network manager

[Gianfranco Costamagna]

Hi
>But i haven't commited in the source directory, just in the debian one?


true!

cheers,

G.

Bug#801253: O: wicd -- wired and wireless network manager

[Gianfranco Costamagna]

Hi



>Can you please explain why you used dh_clean and not dh_build or sth 
>similar? i mean, is there a specific reason?


acually the updatepo is something that needs to be done and committed on git.
during in dh-clean ensures you will run it from time to time (at least to create
a source.changes to upload).

Doing in dh_build might not be enough, because most developers will build it in 
a
clean chroot, so they won't be able to commit the changes files.

>Additionally,
>
>running "git buildpackage --git-debian-branch=master" in the branch 
>master results in "gbp:error: upstream/1.7.3 is not a valid treeish" 
>which doesn't make sense to me, as we obviously have a debian dir in the 
>master branch. (I'm refering to 
>http://unix.stackexchange.com/a/167565/117978)
>Di you have an idea i could try?


it means somebody didn't push the tag :s
you can avoid this issue by launching "origtargz" command, that tries to 
recreate the orig
tarball with various different techniques

>What about those two commits?
>https://github.com/toogley/pkg-wicd/commit/4c930acc59031a10647d68310020d893258313b6
>
>https://github.com/toogley/pkg-wicd/commit/5fdf48ce5f55ea70047e7e1e790e893070ef4593
>

+1 for me :)

cheers,

G.

Bug#801253: O: wicd -- wired and wireless network manager

[Gianfranco Costamagna]

Hi,

>I'd like to maintain the wicd package, especially because it's a kind of 
>popular package. That would offer me a great challenge to master. But i 
>assume, I'll certainly make errors and certainly be very slow at the 
>beginning in comparison with an experienced maintainer.
>
>I can't estimate if that's a critical problem or if I'm suitable for 
>maintaining such a popular package. Of course I'll do my best.
>
>==> So, what do you guys think about that?


being a new maintainer doesn't stop you from trying to adopt a package, 
specially because you need a sponsor
to see your changes propagated, so don't worry, somebody will double check your 
work!

In this case, I'll be *very* happy to see you maybe fork the git repository here
http://anonscm.debian.org/cgit/collab-maint/wicd.git

(maybe on a github repository? just to avoid initial messing of the repo).

you might want to make the packaged 1.7.3 version uploaded on Debian (it is 
already on the master branch)


I cc'd Emanuele and Axel, the last sponsors of the package.

The new release is already imported in git, so it might just be a matter of 
rebasing patches, check the patches
in the BTS if they still apply/they are sane/they work, include them in the 
packaging
https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=tags%3Apatch=tags%3Apending=done=no=wicd
and check if everything works.

(fix the TODO in changelog and and find a sponsor).

I'm pretty sure somebody will check your work, and please ask if something is 
not clear enough.

BTW "upstream" branch should contain 1.7.3 version, but seems that Ritesh 
forgot to push the tags :)


cheers!

Gianfranco

Bug#801253: O: wicd -- wired and wireless network manager

[Gianfranco Costamagna]

Hi Axel!

>The main reason why I haven't uploaded it as QA upload already is that
>wicd-curses is slightly broken since 1.7.3. This likely requires
>patching upstream code to get it fixed. See the TODO at
>http://anonscm.debian.org/cgit/collab-maint/wicd.git/tree/debian/changelog#n3


yes, I thought I mentioned that, but thanks!


>> The new release is already imported in git, so it might just be a
>> matter of rebasing patches,>That's already done.



I was talking about the patches in the BTS (bugs tagged "patch").
I think they should be checked and untagged/ or fixed if possible

cheers!

Gianfranco

Bug#808962: ITP: python-keyutils: Python bindings for keyutils

[Gianfranco Costamagna]

Package: wnpp
X-Debbugs-CC: debian-de...@lists.debian.org
Owner: locutusofb...@debian.org
Severity: wishlist

* Package name: keyutils
* Version: 0.3.0
* Upstream Author : Mihai Ibanescu 
* URL: github.com/sassoftware/python-keyutils
* License: Apache-2.0
* Programming Lang: Python
* Description: 
Python bindings for keyutils
python-keyutils is a set of Python bindings for keyutils (available from
http://people.redhat.com/~dhowells/keyutils), a key management suite that
leverages the infrastructure provided by the Linux kernel for safely storing
and retrieving sensitive information in your programs.

Bug#808680: ITP: python-knockpy: python tool designed to enumerate subdomains on a target domain through a wordlist

[Gianfranco Costamagna]

Package: wnpp
X-Debbugs-CC: debian-de...@lists.debian.org
Owner: locutusofb...@debian.org
Severity: wishlist

* Package name: knock
* Version: 3.0.0
* Upstream Author : Gianni Amato 
* URL: https://github.com/guelfoweb/knock
* License: GPL-3+
* Programming Lang: Python
* Description: Knockpy is a python tool designed to enumerate subdomains
on a target domain through a wordlist.

Bug#726262: Accepted m2crypto 0.21.1-4 (source amd64) into unstable

[Gianfranco Costamagna]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Charles,

> thank you for formally relieving me from the maintenance of
> m2crypto. In #726262, where I ophaned it, a few people offered
> their help, but did not follow up.  Have you considered
> re-contacting them or the Debian Python Applications or Modules
> Teams, that maintain some packages depending on m2crypto ?
> 
> The reason I ask is that, as the name indicates, m2crypto might be
> involved in security issues anytime, and it would obviously better
> if we found a person or a team knowledgeable in at least python or
> cryptography, to increase Debian's chances of reacting quickly.
> One painful alternative is to remove m2crypto, and therefore its
> dependency chain, given the concerns of not being able to deal with
> potential problems in the future.
> 
> Anyway, thanks for your intervention, and have a nice day,
> 

seems that people offers their help and disappear soon after the first
mail.

For this reason I sponsored to Daniel the new release, with some bug
fixes in this package, specially the RC bugs.

This O bug was two years old, it was time to react :)

Daniel finished the nm process a few days ago, and he will have full
upload rights in a few weeks, I'm sure he will do a good work with
this package, and I guess if somebody from a Python team asks... he
will put the package again in a collaborative maintenance fashion :)

cheers, and thanks to you for the great work on this package!


Gianfranco, sponsor of the updated version
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWTak5AAoJEPNPCXROn13ZVrsQALrL83vfcI2LDMoICq7lXYSi
4YSPTXrZh+a1470hGWXvMbQRwCq1GupugNGqL/quFz/qy1EvH6DBlmx8CYRxN4Tt
feGjgU6N9HaEQouC/GC+yUas+hG6Uif8asXEsO+/PgSHNYBp3Kc2jr8UXJR1qo/z
sv8ESB9+vC3tD5VULy0iqESiwIhgLrPK/5ZBD4vLVI/4doJteQJwGUyLxf4rkD3R
c4dKQUipuKVaqIGbS1DmMyyqnmzAlhw0wF4iWwF+zvLVncIxDhxGPdfRuxodsEIK
3hrF3AoObFZmE9RXO2YTs6Unm7IyBdPU3J2v6gb76nRUs0KD4HvhQQ2dcOQmU9Gp
70hakCygK5bRhFCUg/U++ONkvTULQwu/8RPmHHXRHAXDaCoaIycsVhI4UI6c7AmU
5CF76icd7dnZWBKrwWn4TybRs5tHaYB3g4r5d+9frqAyYqSxeeeWHx8hWz89Il27
FJmXo+0bANtsBtkLuihirP0MKtHx4+maCn2jKHUXbnl8PWRD5kVK2iROHLMrKM8N
Narl6Nv7BC2zHUtnE+eDmbPZWiVSdK2rKAQad19a+vMlxQoZEIXc/4p8h1GKc43H
tDHQu5tC5g8FU2hGejRM8QLzq9YdHCQ7NpYC/Y0XV/elESxmciEz5WO5ZF0G6y8Q
YjFUL+OyMEiDuh8UdNH4
=P3o0
-END PGP SIGNATURE-

Bug#636272: restund in debian

[Gianfranco Costamagna]

Hi, please open an RFS bug if you want to find a sponsor.

Anyway, I looked at the package.

the packaging rules file is really hacky, but looks good!

I would appreciate a more sane upstream packaging system, but your workaround
looks really nice ;)

do you mind opening an RFS bug?

cheers,

G.





Il Martedì 27 Ottobre 2015 0:54, Simon Josefsson  ha 
scritto:
I have prepared a Debian package for the latest 0.4.14 release of
"libre", and have uploaded it to Debian Mentors:

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

For reference, upstream homepage and ITP bug links:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636272
  http://www.creytiv.com/re.html

Please review the package, I want it to be in perfect condition!
Anything that appears sub-optimal is something I want to learn about.

As you can see, the build system is ad-hoc, which is always a challenge
for shared libraries.  I'm not certain the way the soname, symbol list,
and everything around the shared library part is kosher.

A temporary git repository for the packaging exists.  I plan to move
this to alioth before proper upload to Debian, hoping to make this a
pkg-voip team maintained package.

  https://github.com/jas4711/libre-dpkg

/Simon

Bug#792096: borg packaging

[Gianfranco Costamagna]

Hi Marc!

the problem is the metadata :)

you can see the thread here
https://github.com/borgbackup/borg/pull/290

HTH

G.


Il Giovedì 22 Ottobre 2015 17:57, Marc Haber <mh+debian-packa...@zugschlus.de> 
ha scritto:
On Tue, Oct 06, 2015 at 01:13:55AM -0400, Antoine Beaupré wrote:
> On 2015-10-06 00:12:19, Gianfranco Costamagna wrote:
> > Hi, Danny has finally got accepted in collab-maint
> > (I forgot that a signed mail was needed for the join).
> >
> > In the next few days I had many other Debian activities that kept
> > myself away from this bug, but I guess we will close it soon.
> 
> Happy to hear that! Keep us in the loop here. :)

There seems to be code for 0.27 in alioth collab-maint, but that one
doesn't even survive a debian/rules clean in a minimal sid chroot:

[17/516]mh@salida[debian_chroot sid64]:~/packages/borgbackup/borgbackup$ 
fakeroot debian/rules clean
rm -f borg/chunker.c borg/compress.c borg/crypto.c borg/hashindex.c 
borg/platform_darwin.c borg/platform_freebsd.c borg/platform_linux.c
dh clean --with python3,sphinxdoc --buildsystem=pybuild
   dh_testdir -O--buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:170: python3.4 setup.py clean
Traceback (most recent call last):
  File "setup.py", line 170, in 
install_requires=install_requires,
  File "/usr/lib/python3.4/distutils/core.py", line 108, in setup
_setup_distribution = dist = klass(attrs)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 272, in 
__init__
_Distribution.__init__(self,attrs)
  File "/usr/lib/python3.4/distutils/dist.py", line 280, in __init__
self.finalize_options()
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 327, in 
finalize_options
ep.load()(self, ep.name, value)
  File "/usr/lib/python3/dist-packages/setuptools_scm/integration.py", line 19, 
in version_keyword
dist.metadata.version = get_version(**value)
  File "/usr/lib/python3/dist-packages/setuptools_scm/__init__.py", line 67, in 
get_version
version = version_from_scm(root)
  File "/usr/lib/python3/dist-packages/setuptools_scm/__init__.py", line 29, in 
version_from_scm
return ep.load()(root)
  File "/usr/lib/python3/dist-packages/setuptools_scm/git.py", line 34, in parse
return meta(tag, distance=number, node=node, dirty=dirty)
  File "/usr/lib/python3/dist-packages/setuptools_scm/version.py", line 85, in 
meta
assert tag is not None, 'cant parse version %s' % tag
AssertionError: cant parse version None
E: pybuild pybuild:262: clean: plugin distutils failed with: exit code=1: 
python3.4 setup.py clean
dh_auto_clean: pybuild --clean -i python{version} -p 3.4 --dir . returned exit 
code 13
debian/rules:23: recipe for target 'clean' failed
make: *** [clean] Error 25
[18/517]mh@salida[debian_chroot sid64]:~/packages/borgbackup/borgbackup$

This only happens once in a while, being persistent with it sometimes
gives success. I don't understand what's going on here.

Greetings
Marc


-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421


-- 
To unsubscribe, send mail to 792096-unsubscr...@bugs.debian.org.

Bug#697821: ITP: ppsspp -- ppsspp: A portable PSP emulator.

[Gianfranco Costamagna]

Hi,


>Haha, that's a good one. You haven't been around here long enough, no?


well, I am, but I was giving a fact, not saying I would sponsor such hack, just 
mentioning
that $somebody else is already doing that on debian.

(if you look to my -mentors sponsoring activities you can see I don't even like 
shipping a static library,
so I really care about security).


Look e.g.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650601#354

personally I would like to see the transition start, but with the libstdc++5 
ongoing one
I don't think -release will ever give an ack for it
(modulo somebody working on it)

>No, it isn't. Could you please stop giving me hints which assume I'm
>an idiot? I have been doing packaging for a while now.


I was trying to give my help, not to make you feel an idiot.
sorry if I didn't make my intentions clear.

Of course the package is now in a no-go state :(

cheers,

G.

Bug#697821: ITP: ppsspp -- ppsspp: A portable PSP emulator.

[Gianfranco Costamagna]

Hi,

>I don't even see libpng16-dev in Ubuntu, even in wily, the current
>development release. libpng is a core library, you can't just brutally
>upgrade that to a new upstream version without risking breaking
>anything. You'll risk breaking tons of packages. Something as important
>as libpng needs a proper transition.


bug #650601 is still sleeping :)
>> I fixed it in the dirty way: I installed manually the headers and
>> pkgconfig of 1.6 in the system :)
>
>Then we're out of luck. There is no way you can upload the package
>that way to Debian, sorry.


well, there is at least two more solutions:
1) target the upload to experimental, where the libpng16 is available
2) embed libpng16 inside the source
(well, it is not a suggestion, just a matter of facts)

>Then we'll have to wait until the libpng16 transition has happened.


this will still be needed for an unstable upload, while experimental should be
good.


cheers,

G.

Bug#697821: ITP: ppsspp -- ppsspp: A portable PSP emulator.

[Gianfranco Costamagna]

Hi Adrian!



>Adrian, not John.


(my deep apologies for this mistake)
>Why should we switch over to the RFS bug report? What would that change
>and why would there be any double work? I have been in contact with
>Benjamin for a while now and we are just discussing the issues in
>public so that others can follow the progress. I don't really expect
>anyone else to get involved with the package.


well, it is a common practice to set yourself as RFS bug owner, to avoid people
double looking at the same package.

I saw the RFS bug, and not the ITP one, and I was going to review it.

When I review a package sometimes I start by looking at the ITP, sometimes
else I start by looking at the copyright, or the packaging and then the ITP.


I could have started looking at it by mistake e.g. because I didn't follow the 
"look
at the ITP first" procedure.

>Don't worry, I will take care of the sponsoring. I do regular sponsoring
>as you can see from the sponsor stats.


thanks a lot for the effort :)

so, can I please set yourself as owner of the RFS bug? this way I won't bother 
you anymore :)
(I didn't find any good way to "look at RFS bugs only where nobody is looking 
at them", if not
by setting yourself as owner, as described in [1])

[1] http://mentors.debian.net/sponsor/rfs-howto
"If you intend to take care of the sponsoring request until the package is 
ready for upload, please consider setting yourself as the owner of the bug and 
tag the bug pending:

$ bts owner nnn m...@example.com
$ bts tag nnn +pending "

cheers, and sorry again for the noise!

happy hacking!

Gianfranco

Bug#697821: ITP: ppsspp -- ppsspp: A portable PSP emulator.

[Gianfranco Costamagna]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi John and Sérgio,

thanks for your precious work on this package!

However, I would like to ask you considering switching the discussion
in bug #801262, and set yourself as owner of that bug, this way we can
avoid double work on the same packages.

If you don't intend sponsor the package let me know :)

cheers,

Gianfranco

On Fri, 9 Oct 2015 07:01:29 +0200 John Paul Adrian Glaubitz
 wrote:
> On Fri, Oct 09, 2015 at 12:45:33AM -0300, Sérgio Benjamim wrote:
>>> There are several lintian errors and warnings that you should
>>> get rid of. Most notably, lintian complains about an embedded
>>> libpng:
>>> 
>>> E: ppsspp-sdl: embedded-library usr/games/ppsspp-sdl: libpng
>> 
>> It needs libpng >= 1.6, and it's only in the Experimental :/
> 
> Then ppsspp should rather go into experimental than unstable.
> 
>> Are there any ETA to see it in the Testing repo?
> 
> libpng16 will be in testing once the libpng16 transition in
> unstable has been finished or has reached an acceptable state
> without breaking everything. However, since this transition hasn't
> even been announced yet, I can't really say when this is going to
> happen.
> 
> You should ask the release team or the libpng maintainer(s) for a 
> date.
> 
>> Only the SDL port has the libpng embedded, the Qt only uses it to
>> compile the fonts (*.zim files), so I can disable for now the
>> SDL.
> 
> Or just use experimental. I wouldn't really rush it. If you are 
> pushing it now, you are risking additional work and problems with
> the package. Once the transition starts, we will just upload the
> package to unstable which will be accepted instantly since it has
> already been accepted into experimental by then.
> 
>> They are false positive I guess. The files are there, I don't
>> know why it complains.
> 
> Then you should add lintian overrides for these. But you should
> check the copyright file in case it's not 100% compliant to the
> Debian copyright file format which might have triggered the lintian
> warning.
> 
> Adrian
> 
> -- .''`.  John Paul Adrian Glaubitz : :' :  Debian Developer -
> glaub...@debian.org `. `'   Freie Universitaet Berlin -
> glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546
> 0006 7426 3B37 F5B5 F913
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWHTrbAAoJEPNPCXROn13Zkz0P/RAYN7r5afGVMlGAyxRtc6+p
PpWxt6tq/8G+gRbqPtw2tCzlG8KrInJZen7K96Obyn4zmZANsaMkNyPv8iaeiW3U
pd08EmHJsc4wT9PSSg7K7l5ZP3JhpkBwor/14ipv1YBs7f4NkT+cmPIZZSgFK+px
UFdg+z/ksfD6mtsW+ioJf8Uc0v+YI1CJf9KbHKiTnUPWQsbEk+KQvEp5C/PR2Fmo
n/pRdkKwed6DyrHWj+L5CsVvexxVPU+L10afqLrRvrOlOGY/2/8S14s3SO3he5FZ
G5NV0L+drdcxlLRw455GJLxTZD8aa8UZ2hXAgV/aDR3NAfs/HclvpCjepwRF2vrt
C/AtnQXEz6NZm4N7T7DeuUlO7s9r1RnO92BSdzvNgLBxK+2tgFI5kyHfeIW4l1rw
88R63HDdXoIvjEkdJOVOw/0wjdTFPjEFrSAtz9srEE7tWpphbwrHjuAThXMqQA0b
eeMci99DieAcBTCQN+dk4y3pFUOwkGl6SJYcFqdUX8EyvVX36QA1XPwj5UMflK82
izm71pYPkZoR+ZMffPYM+ft/ggGF7/1GsWu/nq9UEkBcuIx6m+DrrgkLuGvqHn2T
kXkLM83wc72KH4zoyMPsOw/YssOrz9s6vp3DM7Tgi6HeyaF/LNteSc7f7dMilwpy
EI1akE/JD9m/Pdd0lr9c
=vhdk
-END PGP SIGNATURE-

Bug#792096: borg packaging

[Gianfranco Costamagna]

Hi, Danny has finally got accepted in collab-maint
(I forgot that a signed mail was needed for the join).

In the next few days I had many other Debian activities that kept
myself away from this bug, but I guess we will close it soon.

cheers!

G.




Il Martedì 6 Ottobre 2015 2:06, anarcat  ha scritto:
Hi folks,

So what's holding up the package now?

I understand Mark's position, and I don't think the team's efforts
should be distracted at this stage. :)

Please keep going! The msgpack package was updated, so I am not sure why
this is not pushed ahead now!

Cheers,


A.

Bug#772823: kimchi: another packaging and another version

[Gianfranco Costamagna]

Hi Frederic

can you please upload the package (if you think it is good for review/upload) 
on mentors.d.o
http://mentors.debian.net/intro-maintainers

and open an RFS bug then?
(when the package is uploaded you should be able to open an RFS bug starting 
from this template)
https://mentors.debian.net/sponsors/rfs-howto/kimchi

ITP bugs are not ideal for discussing packaging issues/review, while RFS are.


cheers,

Gianfranco




Il Venerdì 2 Ottobre 2015 17:46, Frederic Bonnard <frede...@fr.ibm.com> ha 
scritto:
Hi,

Here is a new packaging especially to fix most of the previous points and for
the new version 1.5.1 of kimchi.
Also :
- added a patch to fix the 404 error for the novnc popup (this patch won't be
  pushed upstream as is as upstream reorganize the code)
- documented more things in README.Debian (user configuration, possible errors) 
and README.source
- updated copyright (and a fix from Ubuntu, thanks Robie)

Note :
- kimchi source is being restructured, so package may have several changes in
  the next version
- kimchi license is going to change, back to LGPL v2

F.

On Fri, 28 Aug 2015 18:31:31 +0100, Gianfranco Costamagna 
<costamagnagianfra...@yahoo.it> wrote:
> 
> Hi,
> 
> >then, how should I specify the "License:" field if it's not a "named" 
> >license ?
> >
> 
> I guess it might fall into LGPL or whatever (just check the directories)
> 
> >> and please tell somewhere the package name, because I forgot it
> >> (and I'm too lazy to check)
> >
> >It's in the subject now ; we won't lose it easily, eventually.
> 
> thanks!
> 
> G.
>

Bug#792096: borg packaging

[Gianfranco Costamagna]

Hi Marc,



first, sorry for have messed up your repository, I tried to fix it, but you 
forgot to push
the pristine tar branch and my branch was different (different hash because of 
different commit id and timestamp)

please assume good faith, I tried to fix, but I failed because of wrong 
permissions.

Actually seems that this is fixed.

So the question is: can I rebase your repository and fix it?
(note: this might lead to an history rewrite, sorry in advance)

>I have neve had such issues when maintaining Debian packages.


sure, because your local repository had the pristine-tar branch and the 
upstream one, maybe :)
>I think that the code that builds a Debian package should be on Debian
>infrastructure. And I think that we should use the pristine tarballs
>released by upstream to have the possibility to compare the tarballs
>by checksum.


ok, let me explain.

I sponsored several packages for Danny, and he told me he wanted to be more 
involved in Debian.

Actually he wasn't a member of collab-maint (not sure if the situation has 
changed in the meanwhile)

and since he lost his home partition I took the possibility to show him a 
package needing a comaintainer,
to see his python packaging skills.

the reason for the github repository is not any kind of "new Debian style of 
doing things", but the *only*
reason was his inability to work on collab-maint.

For sure once we *all* agree, the repo will move on collab-maint and live here 
:)


as Debian wiki says
https://wiki.debian.org/PackagingWithGit

there are two good workflows with upstream git repositories, one with upstream 
tarballs, and the other
with upstream git branches

the first has a pristine-tar with the hash, the second is also trivial to use 
because you just need to compare with
the upstream git tag.

but this isn't a real problem, I guess Danny's approach can change, or he can 
have a separate branch to track upstream master branch
(that would be useful to cherry-pick upstream commits easily).

For python packages bisecting doesn't work well, because usually being 
interpreted means that you can just debug it while running it.

>Currently, it looks like a working team has formed to work on the
>package. That means than I am out. One less cook to spoil the fun, and
>one less old fart to insist on old fashioned package keeping.
>
>If you settle on maintaining borgbackup on github, please make sure to
>kill the repositories on alioth.



After saying I'm sorry for messing up things, I can just only ask you:
can you please rethink your decision and accept my apologies?

(note: I'm not a native english speaker)

please check the borgbackup-new.git collab-maint repository, and let me know if 
it fits your needs.

If yes, I can just add some patches from Danny's repository on github 
(rebuilding cython files during builds and so on), and then
we can fix the borgbackup.git repository.

Sorry again, I hope we can cooperate to a common workflow if you still want to 
help us :)

I updated the borgbackup-new.git repository to 0.25.0 and added some of the 
fixes from Danny's github repo.

Let me know if the workflow is ok for you

I usually build with dpkg-buildpackage, but for creating the upstream tarball I 
use git-buildpackage
or origtargz 

pristine-tar: successfully generated ../borgbackup_0.25.0.orig.tar.gz

(I see many different workflows in Debian, I would be happy to know your if it 
differs from mine :) )

cheers!

G.

Bug#792096: borg packaging

[Gianfranco Costamagna]

Hi Marc,

I'm afraid having a different upstream/pristine-tar messed up things.

even if the tarball is the same, git fails to see a common history.



I did create a new repository
http://anonscm.debian.org/cgit/collab-maint/borgbackup-new.git

(for some reasons your repo has the wrong permission bit set)



But I honestly prefer Danny's repository, 
https://github.com/dannyedel/pkg-borgbackup

because he fixed a lot of stuff, including regeneration of built file at build 
time.
what do you think?

cheers,

G.

Bug#798529: ITP: python-xkcd

[Gianfranco Costamagna]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name : xkcd
* Version : 2.3.1
* Upstream Author : Ben Rosser
* URL : https://pythonhosted.org/xkcd/
* License : MIT
Description : Python2 library for accessing xkcd.com.

This is a Python library for accessing and retrieving links to comics from the
xkcd webcomic by Randall Munroe. It is NOT endorsed or made by him, it’s an
entirely independent project.
.
It makes use of the JSON interface to Randall’s site to retrieve comic data.
.
One can create comic objects manually using Comic(number), or can use the helper
functions provided- getLatestComic(), getRandomComic(), and getComic()- to do
this. Once you have a Comic object, you can access data from it using various
provided methods.
.

Bug#798529: ITP: python-xkcd

[Gianfranco Costamagna]

Hi Alexandre


>I was ready to complain that at this point a new python2 only shouldn't be
>packaged anymore; but this library already  works with python3 too ;-)
>
>Why not make this a future-proof Python3-only package ?


of course I build both python2 and python3, this is a case when I opened a ITP
after doing the packaging, so I did copy from control file (lazy me)


>by the way, provided URL never link to the source 
>location:>https://pypi.python.org/pypi/xkcd/
>
>Greets,


it is correct in the copyright file :)

cheers,

G.

Bug#798529: ITP: python-xkcd

[Gianfranco Costamagna]

Hi Ben!


>Why is this useful to do programmatically?


having access to the website by code is useful to know when some new images are 
available, moreover
is nice to have for the "alt" stuff, not visible from Android (e.g.) and from 
some older browsers.

the API has some *nice* additions, I thought it was worth a packaging


>Then, isn't its name a trademark infringement?


well, IANAL, but on the xkcd website there is no trademark mentioning, and all 
the work is CC licensed.
(not that we should care about the images, since they are not packaged in any 
way)

cheers,

G.

Bug#792096: borg packaging

[Gianfranco Costamagna]

Hi,





Sure you can join! Do you have access to collab-maint?
https://wiki.debian.org/Alioth/PackagingProject


I'm a uploading-DD, so yes :)



I offered a debdiff for msgpack package, and tweak a little bit borgbackup 
package.

I pushed pristine-tar and upstream branches, for the updated 0.24.0 release, and
I pushed my debian packaging into master-new.

looks good to me now.

cheers,


G.

Bug#772823: Looking for a mentor for a couple of projects

[Gianfranco Costamagna]

Hi,






I did all that was doable in a reasonable time. As said before, for what need 
more
time and/or help from upstream, I've kept track of it in README.source


ok

done, thanks


ok
Yes, we'll try to do something with upstream, but I couldn't do that in
a trivial way. As explained tests create VMs.
This is tracked in README.source though.


that might be an issue :)
Actually I based the licensing of that file on that same file :
http://sources.debian.net/src/spice-html5/0.1.4-1/debian/copyright/?hl=13#L13
I can ask the maintainer there if he knows more.


if other packages have the same license might be fine then, but please double 
check :)

I guess upstream didn't update the files. I'll sent a mail to them to ask.


thanks


./m4/*.m4:dnl Copyright (C) 1996-2003, 2009-2010 Free Software Foundation,
./po/Makefile.in.in:# Copyright (C) 1995-1997, 2000-2007, 2009-2010 by Ulrich 
Drepper drep...@gnu.ai.mit.edu
./plugins/sample/po/Makefile.in.in:# Copyright (C) 1995-1997, 2000-2007, 
2009-2010 by Ulrich Drepper drep...@gnu.ai.mit.edu
./config.rpath:#   Copyright 1996-2010 Free Software Foundation, Inc.
./INSTALL:Copyright (C) 1994-1996, 1999-2002, 2004-2011 Free Software 
Foundation,
./INSTALL:are permitted in any medium without royalty provided the copyright
./build-aux/config.rpath:#   Copyright 1996-2010 Free Software Foundation, Inc.
./build-aux/pkg-version:# Copyright 2008-2012 Red Hat, Inc.

not sure how to deal with those : they specify a copyright but no license
except things like unlimited permission to copy and/or distribute it, with or
without modifications, as long as this notice is preserved.
So, does this means that they will fall under the license of the project
(LGPL-3) or are those small notices considered as a license by itself?


yes, fine for them :)

COPYING specifies LGPL-3 ; do you mean people generally use LGPL-3+ and that
upstream may have done a typo ? I'll ask.


yes please, I usually see LGPL-3+, and it is a little bit more permissive (not
right now, but it might become in a future version)
will do


thanks

Indeed! good suggestion given the number of python deps pulled and it seems to
change quite often.
I will ask for this too.



thanks, unfortunately you still need to have them in build-dependencies, but not
in runtime-dependencies
(please check the DEBIAN/control in the binary package if everything went good)


and please tell somewhere the package name, because I forgot it
(and I'm too lazy to check)

cheers,

G.

Bug#772823: R: kimchi: looking for a mentor

[Gianfranco Costamagna]

Hi,

then, how should I specify the License: field if it's not a named license ?


I guess it might fall into LGPL or whatever (just check the directories)

 and please tell somewhere the package name, because I forgot it
 (and I'm too lazy to check)

It's in the subject now ; we won't lose it easily, eventually.

thanks!

G.

Bug#787491: Looking for a mentor for a couple of projects

[Gianfranco Costamagna]

sphde:


d/changelog: please set to unstable the target series

d/control: what about having the doxygen documentation in a -doc package
arch=all with doxygen moved to build-depends-indep?

look e.g.
https://sources.debian.net/src/websocketpp/0.6.0-1/debian/control/
and the rules file
(note, you might need to run dh_auto_configure again in the dh_auto_build-indep:
target)



d/*.install
usr/share/man/man1/sasutil.1

this should belong to dh_installmanpages

d/control:
the package seems multiarch? well, set multiarch in the control file then :)

d/*dev.install

are you sure you want to ship a static library?

d/p/*LDFLAGS:

the patch seems to have some autogenerated output inside.

all the patches have the changelog quote, please remove it.


some lintian stuff

– Package uploaded for the unreleased distribution
– Package has lintian errors
sphde source

P debian-watch-may-check-gpg-signature

libsphde0

E binary-from-other-architecture
usr/bin/sasutil
usr/lib/powerpc64le-linux-gnu/libsphde.so.0.0.1
I hyphen-used-as-minus-sign
usr/share/man/man1/sasutil.1.gz:9
usr/share/man/man1/sasutil.1.gz:79
X shlib-calls-exit
usr/lib/powerpc64le-linux-gnu/libsphde.so.0.0.1


please fix :)


let me know when you have done with the above, and I'll look to do a build ;)

cheers,

Gianfranco

Il Mercoledì 19 Agosto 2015 17:37, Thierry Fauck ( thierry @ 
linux.vnet.ibm.com ) thie...@linux.vnet.ibm.com ha scritto:



Dear mentors, We are looking for a sponsor for a couple of packages submited by 
Frederic Bonnard kimchi (bug #772823) sphde  (bug # 787491)
see: https://mentors.debian.net/packages/uploader/frediz%40linux.vnet.ibm.com 
Feel free to contact me at the conf or Frederic by mail.

Thanks



-- 
THF - Thierry Fauck (thie...@linux.vnet.ibm.com)
Debian Contributor

Bug#772823: Looking for a mentor for a couple of projects

[Gianfranco Costamagna]

Kimiki review:

please fix all the above (message #72 of bug 772823)



d/changelog: no need to put your name into []
when you are the only one who worked on the package (and the signature
is your)

d/rules: as said skipping tests is usually bad, please enable them if possible

d/copyright: multiple-licenses looks bad to me.

Is something like you can choose your favourite one?

so please say something like LGPL-3 or MIT or XFree86

I don't think the same file can be licensed under the tree licenses without 
breaking
the law. (but IANAL)



tests/* seems to be under LGPL-2.1+
(and also something under plugins and somewhere else, looking by a grep of the 
License keyword

e.g.
./plugins/sample/i18n.py:# version 2.1 of the License, or (at your option) any 
later version.
./plugins/sample/ui/Makefile.am:# version 2.1 of the License, or (at your 
option) any later version.
./plugins/sample/ui/config/Makefile.am:# version 2.1 of the License, or (at 
your option) any later version.
./plugins/sample/ui/pages/Makefile.am:# version 2.1 of the License, or (at your 
option) any later version.
./plugins/sample/ui/js/Makefile.am:# version 2.1 of the License, or (at your 
option) any later version.
./plugins/sample/__init__.py:# version 2.1 of the License, or (at your option) 
any later version.


also grepping by copyright makes some result appear not listed in copyright 
file.


please check if the license is really LGPL-3 and not LGPL-3+

patches needs a Description: field (and they are not dep-3)


the other stuff looks good, please ping when you have done the above,
and I'll do some testing on a built package.

(btw would be nice to have a setup.py and install_requires, do let
python:Depends pick up the python dependencies automagically)

cheers,

Gianfranco

Il Mercoledì 19 Agosto 2015 17:37, Thierry Fauck ( thierry @ 
linux.vnet.ibm.com ) thie...@linux.vnet.ibm.com ha scritto:



Dear mentors, We are looking for a sponsor for a couple of packages submited by 
Frederic Bonnard kimchi (bug #772823) sphde  (bug # 787491)
see: https://mentors.debian.net/packages/uploader/frediz%40linux.vnet.ibm.com 
Feel free to contact me at the conf or Frederic by mail.

Thanks



-- 
THF - Thierry Fauck (thie...@linux.vnet.ibm.com)
Debian Contributor

Bug#792096: Bug#794678: msgpack-python: please update to the latest upstream version

[Gianfranco Costamagna]

Hi Marc,


I'm not sure I can help with the packaging of borgbackup,

but if the borg community needs a new borg member...

well, I guess I'm the only borg in Debian ATM..

So consider me in!

(and push your upstream branch, tags and if you have the pristine-tar)


BTW d/control: line 17
python3-msgpack (= 0.1.10)

this is handled automatically by python3:Depends, since setup.py contains:
install_requires=['msgpack-python=0.4.6']

d/watch seems that this points to an old package:

I would use this instead:
http://pypi.debian.net/borgbackup/watch

(and then update to 0.24)


I did a basic testing, the packaging is really nice :)

Am I in?

cheers,


LocutusOfBorg


Il Mercoledì 12 Agosto 2015 23:17, Marc Haber mh+debian-packa...@zugschlus.de 
ha scritto:
On Wed, Aug 05, 2015 at 04:10:56PM +, Gianfranco Costamagna wrote:

 Hi, in order to have the latest w3af in Debian, a new msgpack-python = 0.4.4
 is needed, can you please update it?

Current version is 0.4.6, which is needed by borgbackup. Please update
;-)

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things.Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#795073: ITP: python-ruamel.ordereddict -- Implementation of an ordered dictionary with Key Insertion Order

[Gianfranco Costamagna]

Hi Raphael,


Kali already has the latest w3af and all those dependencies. You might

want to base your work on the packages we prepared:
http://git.kali.org/gitweb/?p=packages/ruamel.ordereddict.git;a=summary
http://git.kali.org/gitweb/?p=packages/python-vulndb.git;a=summary

Or the corresponding .dsc:
http://http.kali.org/pool/main/p/python-vulndb/python-vulndb_0.0.17-0kali1.dsc
http://http.kali.org/pool/main/r/ruamel.ordereddict/ruamel.ordereddict_0.4.8-0kali2.dsc



actually this is where I started from :)

If you could also keep the same source package names, it would be great.
:-)


I don't think this is a problem, and I guess my packaging will allow your 
packages to disappear from the archive.

The only thing to be sure it is the binary package name, and I didn't change 
that.

(they are both in NEW queue right now, so I can't change it anymore, unless by 
bothering ftpmasters)


Don't hesitate to lookup packages on http://pkg.kali.org



thanks!

If you want you can look at my Debian / w3af packaging workflow here
https://github.com/andresriancho/w3af/issues/10538


cheers,

Gianfranco


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1655798062.3064672.1439323020689.javamail.ya...@mail.yahoo.com

Bug#795074: ITP: python-vulndb -- Provides access to the vulndb information

[Gianfranco Costamagna]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name : vulndb
* Version : 0.0.19
* Upstream Author : Andres Riancho
* URL : https://github.com/vulndb/python-sdk/
* License : BSD-3-clause

Description : Providing access to the vulndb information

python-vulndb is an python SDK that might be used to provide
access to the vulndb information system available at
https://github.com/vulndb/data


this is a dependency of the new w3af package.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/664361896.1974321.1439203520592.javamail.ya...@mail.yahoo.com

Bug#795073: ITP: python-ruamel.ordereddict -- Implementation of an ordered dictionary with Key Insertion Order

[Gianfranco Costamagna]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org
* Package name : ruamel.ordereddict
* Version : 0.4.8
* Upstream Author : Anthon van der Neut
* URL : https://bitbucket.org/ruamel/ordereddict
* License : MIT/Python-2.0
Description : Implementation of an ordered dictionary with Key Insertion Order

(KIO: updates of values do not affect the position of the key),
Key Value Insertion Order (KVIO, an existing key's position is removed and put 
at the back).
Sorted dictionaries are also provided. Currently only with Key Sorted Order
(KSO, no sorting function can be specified, but you can specify a transform to 
apply
on the key before comparison (e.g. string.lower)).

this is a dependency of the new w3af package.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1734400065.1998734.1439203151917.javamail.ya...@mail.yahoo.com

Bug#674916: ITP

[Gianfranco Costamagna]

Hi Mikhail, Matt et all.

I would like to adopt s3cmd.

I have updated the package to the latest upstream release and fixed many 
packaging issues starting from Matt's version.

I put Matt and myself as Uploaders, and PAPT as maintainer.


I also opened an RFS (#780584) in case you are too busy to review it :)

cheers,

Gianfranco


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1648963263.338592.1426503536602.javamail.ya...@mail.yahoo.com

Bug#780269: ITP: libserial: Serial port programming in C++ under POSIX operating system

[Gianfranco Costamagna]

Package: wnpp
Owner: costamagnagianfra...@yahoo.it
Severity: wishlist

* Package name: libserial
Version: 0.6.0~rc1
Upstream Author : 
Manish P. Pagey pa...@san.rr.com
Crayzee Wulf crayzeew...@users.sourceforge.net
Jay Sachdev jsach...@users.sourceforge.net
Jan Wedekind wedes...@users.sourceforge.net* URL: 
libserial.sourceforge.net
* License: GPLv2
* Programming Lang: C++
Description: Serial port programming in C++ under POSIX operating system

A collection of C++ classes which allow the serial port on POSIX systems to be
accessed like an iostream object. Special functions are provided for setting
various parameters of the serial port such as the baud rate, character size,
flow control and other.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1178180228.705897.1426079876227.javamail.ya...@mail.yahoo.com

Bug#778837: ITP: python-darts-lib-utils-lru: Simple dictionary with LRU behaviour

[Gianfranco Costamagna]

Package: wnpp
Severity: wishlist
Owner: Gianfranco Costamagna costamagnagianfra...@yahoo.it

* Package name: python-darts-lib-utils-lru
Version: 0.5~git20140220-1
Upstream Author : 2011 Dirk Esser cont...@deterministic-arts.de
* URL: https://code.google.com/p/cld2/
* License: MIT
Programming Lang: Python
Description: Simple dictionary with LRU behaviour


An LRUDict is basically a simple dictionary, which has a defined maximum
capacity, that may be supplied at construction time, or modified at run-time
via the capacity property.
The class SynchronizedLRUDict, which exposes the same interface as plain
LRUDict, but fully thread-safe.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1008420767.4683965.1424439991434.javamail.ya...@mail.yahoo.com

Bug#778319: ITP: fim -- scriptable frame buffer and ascii art image viewer

[Gianfranco Costamagna]

Package: wnpp
Owner: michele.mart...@uniroma2.it
Severity: wishlist

* Package name: fim
Version : 0.4~rc3-1
Upstream Author : Michele Martone michele.mart...@uniroma2.it
* URL : http://www.nongnu.org/fbi-improved/
* License : GPLv2+
* Programming Lang: C++
Description : scriptable frame buffer and ascii art image viewer
   FIM is a highly customizable and scriptable image viewer targeted at the
   users who are comfortable with software like the Vim text editor or the Mutt
   mail user agent (it aims to be a Swiss Army knife for viewing images).
   It derives from the Fbi image viewer (by Gerd Hoffmann), and in addition to 
   the Linux framebuffer console it can use X (via the SDL library) and offer
   ascii art output (via the aalib library).
   It provides: regular expressions based vim-like autocommands; GNU readline
   based command line autocompletion and history; completely customizable key
   bindings; external/internal (if-while based) scriptability (through return
   codes, standard input/output, and commands given at invocation time) an
   initialization file; filename-based image search; and much more.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/155161228.4383429.1423838300332.javamail.ya...@mail.yahoo.com

Bug#777588: ITP: cld2 -- Compact Language Detector 2

[Gianfranco Costamagna]

Package: wnpp
Severity: wishlist
Owner: Gianfranco Costamagna costamagnagianfra...@yahoo.it

* Package name: cld2
Version : 0.0.0~svn193
Upstream Author : Dick Sites dsi...@google.com 
* URL : https://code.google.com/p/cld2/
* License : Apache-2.0
Programming Lang: C++
Description : Compact Language Detector 2

CLD2 probabilistically detects over 80 languages in Unicode UTF-8 text, either 
plain text or HTML/XML.
Legacy encodings must be converted to valid UTF-8 by the caller. For 
mixed-language input,
CLD2 returns the top three languages found and their approximate percentages of 
the total
text bytes (e.g. 80% English and 20% French out of 1000 bytes of text means 
about 800 bytes
of English and 200 bytes of French). Optionally, it also returns a vector of 
text spans with
the language of each identified. This may be useful for applying different 
spelling-correction
dictionaries or different machine translation requests to each span. The design 
target is web
pages of at least 200 characters (about two sentences); CLD2 is not designed to 
do well on very
short text, lists of proper names, part numbers, etc.

CLD2 is a Naïve Bayesian classifier, using one of three different token 
algorithms. For Unicode
scripts such as Greek and Thai that map one-to-one to detected languages, the 
script defines
the result. For the 80,000+ character Han script and its CJK combination with 
Hiragana,
Katakana, and Hangul scripts, single letters (unigrams) are scored. For all 
other scripts,
sequences of four letters (quadgrams) are scored.

Scoring is done exclusively on lowercased Unicode letters and marks, after 
expanding HTML
entities xyz; and after deleting digits, punctuation, and tags. Quadgram 
word beginnings
and endings (indicated here by underscore) are explicitly used, so the word 
_look_ scores
differently from the word-beginning _look or the mid-word look. Quadgram 
single-letter
words are completely ignored. For each letter sequence, the scoring uses the 
3-6 most
likely languages and their quantized log probabilities. The training corpus is 
manually
constructed from chosen web pages for each language, then augmented by careful 
automated
scraping of over 100M additional web pages.

Several embellishments improve the basic algorithm: additional scoring of some 
sequences
of two CJK letters or eight other letters; scoring some words and word pairs 
that are
distinctive within sets of statistically-close languages such as {Malay, 
Indonesian}
or {Spanish, Portuguese, Galician}; removing repetitive sequences/words that 
would
otherwise skew the scoring, such as “jpg” in “foo.jpg bar.jpg baz.jpg”; removing
web-specific words that convey almost no language information such as page, 
link,
click, td, tr, copyright, wikipedia, http.

Several hints can be supplied. Because these can be inaccurate on web pages, 
they
are just hints -- they add a bias but do not force a specific language to be the
detection result. The hints include expected language, original document 
encoding,
document URL top-level domain name, and embedded …lang=xx … language tags.

The table-driven extraction of letter sequences and table-driven scoring is 
highly optimized
for both space and speed, running about 10x faster than other detectors and 
covering over 70
languages in 1.8MB of x86 code and tables. The main quadgram lookup table 
consists of 256K
four-byte entries, covering about 50 languages. Detection over the average web 
page of 30KB
(half tags/digits/punctuation, half letters) takes roughly 1 msec on a current 
x86 processor.

CLD2 is an update of the prior CLD, adding more languages, updating to Unicode 
6.2 characters,
improving scoring, and adding the optional output vector of labelled language 
spans.

These 83 languages are detected: Afrikaans Albanian Arabic Armenian Azerbaijani 
Basque Belarusian
Bengali Bihari Bulgarian Catalan Cebuano Cherokee Croatian Czech Chinese 
Chinese_T Danish Dhivehi
Dutch English Estonian Finnish French Galician Ganda Georgian German Greek 
Gujarati Haitian_Creole
Hebrew Hindi Hmong Hungarian Icelandic Indonesian Inuktitut Irish Italian 
Javanese Japanese Kannada
Khmer Kinyarwanda Korean Laothian Latvian Limbu Lithuanian Macedonian Malay 
Malayalam Maltese
Marathi Nepali Norwegian Oriya Persian Polish Portuguese Punjabi Romanian 
Russian Scots_Gaelic
Serbian Sinhalese Slovak Slovenian Spanish Swahili Swedish Syriac Tagalog Tamil 
Telugu Thai
Turkish Ukrainian Urdu Vietnamese Welsh Yiddish.


Useful for the upcoming poedit 1.8 release.


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/791546596.2444306.1423560498635.javamail.ya...@mail.yahoo.com

Bug#773656: R: Bug#773656: ITP: daps -- DocBook Authoring and Publishing Suite

[Gianfranco Costamagna]

Hi *

Well, so if no objections, I'll help Sascha into fixing the last (almost 
nitpicks) packaging issues and I'll try
to ask my sponsor to get the package into debian.

Cheers,

Gianfranco



Il Lunedì 22 Dicembre 2014 20:09, Sascha Manns sascha.ma...@bdvb.de ha 
scritto:



Hi Raphael, hi Gianfranco,


 Original-Nachricht 
Betreff: R: Bug#773656: ITP: daps -- DocBook Authoring and Publishing Suite
Von: Gianfranco Costamagna costamagnagianfra...@yahoo.it
An: sascha.ma...@bdvb.de, 773...@bugs.debian.org, hert...@debian.org
Datum: 22.12.2014 15:57

is this package a duplicate then? I'm trying to mentor Sascha into the debian 
guidelines, if you think the package is not useful please let me know, I just 
told him that using the package in debian might be useful for the community, 
but if a similar tool makes daps useless we can think about not packaging it at 
all (Sascha, do you have an opinion about the topic? Debian tends to avoid 
duplicated effort of similar tools :-) ) cheers, Gianfranco 
From my POV daps is easier to learn for bloody beginners than publicer. But 
this is just my view. To have different tools to do the same people can decide 
what are better for them. 
In my company we're using daps doc-team-wide so it would be great if
we can providing a package for it :-)

Greetings

Sascha

-- 
Yours sincerly
Sascha Manns Maifeldstraße 10
56727 Mayen
Phone: +49-1573-9242730
Email: sascha.ma...@bdvb.de Web: http://saigkill.ddns.net/wordpress


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1224417256.513321.1419322330243.javamail.ya...@jws11171.mail.ir2.yahoo.com

Bug#773656: R: Bug#773656: ITP: daps -- DocBook Authoring and Publishing Suite

[Gianfranco Costamagna]

Hi Raphael,


--
Il lun 22 dic 2014 14:05 CET, Sascha Manns ha scritto:

Hello Raphael,

Am 22.12.2014 13:50, schrieb Raphael Hertzog:
 Hello,
 
 On Mon, 22 Dec 2014, Andrei POPESCU wrote:
 On Du, 21 dec 14, 17:35:39, Sascha Manns wrote:
  Package: daps
  Severity: wishlist
 
  URL: http://daps.sourceforge.net/
  SVN: http://sourceforge.net/p/daps/svn/HEAD/tree/
 
 The bug is title ITP. Does that mean that you want to package this
 software? If you want someone else to package it, then it should be a RFP
 (Request for Package).
Yes i want to package it by myself. I also have prepared the stuff for Debian.

 In any case, I wanted to point out that Debian already contains publican
 which is RedHat's version of a similar tool. It also supports translation
 with PO files. I'm its Debian maintainer.


is this package a duplicate then?

I'm trying to mentor Sascha into the debian guidelines, if you think the 
package is not useful please let me know, I just told him that using the 
package in debian might be useful for the community, but if a similar tool 
makes daps useless we can think about not packaging it at all

(Sascha, do you have an opinion about the topic? Debian tends to avoid 
duplicated effort of similar tools :-) )

cheers,

Gianfranco
Oh it's a cool tool. Maybe we can make daps available too. :-)

-- Yours sincerly

Sascha Manns

-- To unsubscribe, send mail to 773656-unsubscr...@bugs.debian.org.


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1419260254.11539.bpmail_high_carr...@web171801.mail.ir2.yahoo.com

Bug#737050: patch for build with wx3.0-doc package

[Gianfranco Costamagna]

Hi Norimitsu,


First of all, thanks for the work you did!

(note: I did not try to build the package)

However I have some questions:

If the doxygen was already in the wx3.0 source tree, why drop it? Why upstream 
start releasing it separately? I'm wondering if they are actually the same 
stuff.

Let's go to the diff


+  * build with wx3.0-doc package. (Closes: #737050)
+- get helped by Gianfranco Costamagna costamagnagianfra...@yahoo.it.


not needed, but thanks, it is always appreciated :)


- libnotify-dev
+ libnotify-dev, doxygen, fonts-freefont-ttf


that freefont wasn't needed, right? :)


+Depends: ${misc:Depends}, libjs-jquery


if you don't override the jquery symlink you probably don't need to depend on 
libjs-jquery, since you already have the embedded copy (the same applies to 
control.in file)

please note that I cannot upload the package, and Olly is the boss here :)

I'm just trying to give some hints!


for the doxygen symlink yes, we should avoid it, but since I have already three 
or four packages with that link I'm going to ask on debian-devel soon what is 
the best option for this.


cheers,

Gianfranco


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/395436513.798265.1414310535507.javamail.ya...@jws11108.mail.ir2.yahoo.com

Bug#737050: patch for build with wx3.0-doc package

[Gianfranco Costamagna]

Hi again,



Sorry, I don't know too.


this is something that Olly might clarify, because he dropped the doc package :)


When build documents, exec wxwidgets3.0-3.0.2/docs/doxygen/regen.sh html.
doxygen builds html and png image and so on.

Below log is a part of wxwidgets3.0_3.0.2-2_amd64.build
excepted fonts-freefont-ttf.
If it is nothing font package, document build process(doxygen?)
occur Segmentation fault.


Ok, seems needed, than the question is:
please propagate the change also to control.in file, because otherwise it will 
be lost :)
(sorry if I didn't mean this clear in the previous mail, actually they were two 
questions :))


I think wx3.0-doc works without libjs-jquery too.

I set libjs-jquery in debian control file Build-depend to make sure
because output warning please use libjs-jquery in linlian log.

W: wx3.0-doc: embedded-javascript-library 
usr/share/doc/wx3.0-doc/html/jquery.js
please use libjs-jquery



it *must* work without the libjs-jquery one, I don't think it can be possible 
in the index.html file to see an inclusion of jquery such as 
/usr/share/javascript/jquery and so on.

This is a difficult situation, but you can either choose:
1) use lintian from libjs and copy-paste it
2) make a symlink with dh_linktree or dh_link or similar
3) use the doxygen jquery one.

you seem to have choosen 3), so in my honest opinion jquery isn't a dependency, 
and if lintian complains about a missing dependency (I don't think it complains 
because of this, but because of #736360), lintian is then wrong.


Seems that this is one case when lintian shouldn't be overridden, but fixed :)

cheers,

Gianfranco


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1210595562.1067299.1414356356108.javamail.ya...@jws11103.mail.ir2.yahoo.com

Bug#279422: (no subject)

[Gianfranco Costamagna]

ping again.


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1412759989.77669.yahoomail...@web171804.mail.ir2.yahoo.com

Bug#764177: ITP: websocketpp -- C++ only header library that implements RFC6455, The WebSocket Protocol.

[Gianfranco Costamagna]

Package: wnpp
Version: 0.3.0
Severity: wishlist

* Package name : websocketpp
Version : 0.3.0
Upstream Author : Peter Thorson.
* URL : https://github.com/zaphoyd/websocketpp
* License : BSD-3-clause
Description :
 WebSocket++ is a header only C++ library that implements RFC6455 The WebSocket
 Protocol. It allows integrating WebSocket client and server functionality into
 C++ programs. It uses interchangeable network transport modules including one
 based on C++ iostreams and one based on Boost Asio.
 .
 Major Features:
  * Full support for RFC6455
  * Partial support for Hixie 76 / Hybi 00, 07-17 draft specs (server only)
  * Message/event based interface
  * Supports secure WebSockets (TLS), IPv6, and explicit proxies.
  * Flexible dependency management (C++11 Standard Library or Boost)
  * Interchangeable network transport modules (iostream and Boost Asio)
  * Portable/cross platform (Posix/Windows, 32/64bit, Intel/ARM/PPC)
  * Thread-safe


this package is a dependency of casablanca aka bug #722275



--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1412580716.5678.yahoomail...@web171804.mail.ir2.yahoo.com

Bug#722275: casablanca package

[Gianfranco Costamagna]

Hi Mathieu,

After the last upload I got some feedbacks from upstream, and I packaged 
(separately) the websocketpp library.
It is used just for tests, and now it is in NEW queue.
https://ftp-master.debian.org/new/websocketpp_0.3.0-1.html
(also on collab-maint).

So now we should be good with casablanca, I don't plan to look at the package, 
since I don't think there is much left to do.


have many thanks,

Gianfranco  



--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1412601900.15299.yahoomail...@web171805.mail.ir2.yahoo.com

Bug#722275: casablanca package RFP?

[Gianfranco Costamagna]

I fixed all the lintian warning/errors, and tweaked a patch a little bit 
(following upstream git snapshot change).

Everything should be fine now, attaching the debian directory for people who 
wants to give it a shot.

cheers,

Gianfranco


debian.tar.xz
Description: application/xz

Bug#722275: casablanca package RFP?

[Gianfranco Costamagna]

Oh, after talking with upstream [1] I got the list of files and directories to 
be installed.
(all in standard locations)
I prepared the package and uploaded on mentors, with the doxygen documentation.


I'll stop here, waiting for review.

Some points I have are listed in issue 289 (e.g. there are also other 
libraries, and other headers files that I don't know if they needs to be ship 
or not)
another issue is the doxygen one, for now I create it and override with the 
system jquery, waiting for the bug to be fixed in some way.

[1] https://casablanca.codeplex.com/workitem/289


cheers,


Gianfranco



--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1412095840.42560.yahoomail...@web171805.mail.ir2.yahoo.com

Bug#722275: casablanca package RFP?

[Gianfranco Costamagna]

Hi Malat,


I have finally had some time to look at casablanca package, and I'm attaching 
the debian directory to this mail

Points to share:
-copyright file should be comprehensive of all the copyrights in the package
-I fixed two problems in build package (two patches, one fixing a FTBFS, the 
other disabling tests requiring internet connection)

-there is only one casablanca package in control file, we need to think how to 
split the package.
-there is *no* install target, this makes really difficult to understand where 
the package should be installed
-there is no upstream documentation about this, just a wiki page [1]

Since I don't use directly the software (it might be needed for next poedit 
releases, but there is no code at this moment), I stop here my work, waiting 
for suggestions.


[1] 
https://casablanca.codeplex.com/wikipage?title=Setup%20and%20Build%20on%20LinuxreferringTitle=Documentation


Files created by the build
ls obj-x86_64-linux-gnu/Binaries/ 
alloc_not_supported.txtlibcommon_utilities.so
ReadSingleChar_bumpc1.txt set_response_stream_small.txt
BasicTest1.txt   libcpprest.soReadSingleChar_bumpc2.txt 
SpaceWithNumber.txt
BasicTest2.txt   libcpprest.so.2.2ReadSingleChar_bumpc3.txt 
stream_partial_from_middle.txt
BingRequest   libhttpclient_test.soReadSingleChar_getc1.txt 
stream_partial_from_start.txt
blackjackclient   libhttplistener_test.so
ReadSingleChar_getc2.txt sync_on_async_fextract_1.txt
blackjackserver   libhttptest_utilities.so
ReadSingleChar_nextc.txt sync_on_async_fget_1.txt
CloseExceptionTest.txt   libjson_test.so
ReadSingleChar_ungetc.txt tell_bug.txt
file_size.txt   libpplx_test.so
response_stream_file_stream_close_early.txt  test_runner
file.txt   libstreams_test.so
response_stream_large_file_stream.txt with_content_length_1.txt
fstream_read_1.txt   libunittestpp.soresponse_stream.txt
 without_content_length_1.txt
fstream_read_2.txt   liburi_test.sorun_tests.sh 
without_content_length_2.txt
fstream_read_4.txt   libutils_test.soSearchFile 
WriteBufferAndSyncStrTest1.txt
fstream_read_5.txt   libwebsocketclient_test.soSeekEnd1.txt 
WriteBufferAndSyncTest1.txt
fstream_readline_1.txt   libwebsockettest_utilities.so
seek_read_regression_test.txt WriteBufferStrTest1.txt
fstream_readline_2.txt   oauth1client
send_multiple_text_msges_fstream.txt WriteBufferTest1.txt
fstream_read_to_end_1.txt  oauth2clientSequentialReadWrite.txt  
   WriteFileSequential.txt
fstream_read_to_end_2.txt  OpenCloseTest1.txtset_body_stream_1.txt  
   WriteSingleCharStrTest1.txt
fstream_read_to_end_3.txt  read_acquire_not_supported1.txt  
set_body_stream_2.txt WriteSingleCharTest1.txt
implied_out_mode.txt   read_acquire_not_supported2.txt  
set_response_stream_chunked.txt xfer_chunked_multiple_chunks.txt
inout_regression_test.txt  ReadBuffer1.txt
set_response_stream_large.txt
IsEOFTest.txt   ReadBuffer2.txt
set_response_stream_partial.txt


removing text files (test based) returns this
BingRequest
blackjackclient
blackjackserver
libcommon_utilities.so
libcpprest.so
libcpprest.so.2.2
libhttpclient_test.so
libhttplistener_test.so
libhttptest_utilities.so
libjson_test.so
libpplx_test.so
libstreams_test.so
libunittestpp.so
liburi_test.so
libutils_test.so
libwebsocketclient_test.so
libwebsockettest_utilities.so
oauth1client
oauth2client
run_tests.sh
SearchFile
test_runner


cheers,


Gianfranco


debian.tar.xz
Description: application/xz

Bug#722275: casablanca doxygen problem

[Gianfranco Costamagna]

Hi again,

BTW building casablanca with doxygen will make us hit #736360, and I don't want 
to make any doxygen documentation until the bug is fixed.

(there is a lucene++ in new queue with a jquery replaced with the libjquery-js 
package, but this is a wrong solution, that I'll address in some ways as soon 
as the package is cleared from NEW)

cheers,

Gianfranco

Sent from Yahoo Mail on Android, please escuse brevity, typos and top-posting.

Bug#749815: Package updated

[Gianfranco Costamagna]

Hmm, I am getting unsure - it seems like they don't want you to create

an alioth project if you are only maintaining one package - see

https://wiki.debian.org/Alioth/PackagingProject
and
https://wiki.debian.org/Alioth/FAQ#Will_you_accept_my_project_.3F
https://wiki.debian.org/Alioth/FAQ#Do_I_need_an_Alioth_project_.3F

- I have asked on the alioth IRC-channel, let's see what they say.

I read the IRC answer and set the maintainer to l10 team, seems appropriate.

 
 BTW upstream changed the name in 1.6.9-oss, while I imported it as
 1.6.9, do you think we should change the name accordingly (I mean
 debian/changelog)?

Yeah, that sound like a good idea.



Correcting myself, it seems not, seems that oss is the version with all the 
deps, while there is a stripped versionin /releases.

I corrected watch file, copyright, and reimported the corrected version.
Unfortunately I needed to override the upstream/1.6.9 tag, otherwise 
git-buildpackage would have complained in recreating the upstream tarball.

Sorry for the noise.
I also added a .gitignore and removed the built files from the source tree.

cheers,

Gianfranco

-- Andreas Rönnquist
gus...@gusnan.se

--
To unsubscribe, send mail to 749815-unsubscr...@bugs.debian.org.


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1410518103.16932.yahoomail...@web171801.mail.ir2.yahoo.com

Bug#749815: Package updated

[Gianfranco Costamagna]

 Il Mercoledì 10 Settembre 2014 9:00, Тимирханов Тимур 
 timur.timirkha...@gmail.com ha scritto:
  Hi, Gianfranco,

Hi,

 
 Brilliant work.
 I   am  a  novice  in packaging for Debian, so I am not sure how can I
 help in continuing this effort.
 

The best help I think might be to install poedit from unstable/testing, build 
lucene++ build the new one and install it.

The upgrade path should be smoothless, and moreover testing the new release is 
so appreciated (I'm using it, but would be nice to have some more eyes)


thanks,

Gianfranco
 
  Hi Andreas and Timur,
 
 
  As you might have noticed the new poedit releases uses lucene++
  library, this is why in the last few weeks I focused in packaging it.
 
  I finally (with great help from Tobi) achieved this goal, and the
  library is waiting in ftp NEW queue [1]
 
  Unfortunately this morning while I was working in packaging poedit,
  I noticed that a git branch was already available on collab-maint,
  and I did the whole work again, because the git was missing some
  debian/unstable releases, with important fixes, and it never got any 
 upload.
 
 
  I'm attaching the lucene++ debian directory, the source can be
  found here [2], and I'm pushing on collab-maint the changes I did (and 
 the merge).
 
  The new releases are huge in size terms, so I removed the 
 deps
  directory from the source tarball prior to the import (don't know
  why upstream bundles lucene/wx/boost/... making the source something like 
 700MB (uncompressed).
 
  The debian/copyright still needs to be updated, but I'm pushing the
  changes to let you know the progresses I did and collaborate on the same 
 repository.
 
  Please don't spare your work and your time, let's follow up on the 
 same repository [3]:)
 
  [1] https://ftp-master.debian.org/new/lucene++_3.0.6-1.html
 
  [2] https://github.com/luceneplusplus/LucenePlusPlus
 
  [3] http://anonscm.debian.org/cgit/collab-maint/poedit.git
 
  thanks,
 
 
  Gianfranco
 
 
 
 -- 
 С уважением,
 Тимирханов  mailto:timur.timirkha...@gmail.com
 
 --
 To unsubscribe, send mail to 749815-unsubscr...@bugs.debian.org.



--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1410343391.12299.yahoomail...@web171803.mail.ir2.yahoo.com

Bug#749815: Package updated

[Gianfranco Costamagna]

Hi Andreas,

I have two initial comments (Without having done an in-depth review):

We could create an alioth project including a mailinglist, and use
that mailinglist as maintainer, and put us all as uploaders. It might
ease collaboration, if we just need one email to remember for
maintenance questions. What do you think? (Also, I'd like to use my
@debian.org email for package maintenance).

I changed your mail address, however I'm not sure how to create an alioth 
group, 
maybe I need to be a DD for this?

Feel free to do it, of course I prefer a lot this way :D
(also for team uploads is better)

You have removed a whole lot that has no use in the package such as
embedded libraries (Which is good) - but you could have made an
Files-Excluded-entry in the copyright for this. This would make those
files be removed when using something like git-importorig --uscan
also, automating the entire importing process and removing the need to
remove files by hand. This also adds the benefit that you just need
to add the files that are to be removed once, and simply update the
list for each upstream release, if more unwanted files are added to the
upstream tarball that we need to remove.
See https://wiki.debian.org/UscanEnhancements
for information on this. The wikipage mentions Problematic copyright,
but this is of course useful in our case too.

yes thanks, I was already aware of this, but I didn't use because I though 
I was the only one caring about poedit :)
Now that we are at least three I changed it, however I think the correct string 
is
git-import-orig --pristine-tar --uscan :)

I tried to import again the package and git whatchanged didn't even show the 
entry,
so I presume it is working correctly :)

BTW upstream changed the name in 1.6.9-oss, while I imported it as 1.6.9, do 
you think we should
change the name accordingly (I mean debian/changelog)?

many thanks for the feedbacks,

Gianfranco

-- Andreas Rönnquist
gus...@gusnan.se

--
To unsubscribe, send mail to 749815-unsubscr...@bugs.debian.org.


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1410359692.1614.yahoomail...@web171806.mail.ir2.yahoo.com

Bug#749815: Package updated

[Gianfranco Costamagna]

Hi Andreas and Timur,


As you might have noticed the new poedit releases uses lucene++ library, this 
is why in the last few weeks I focused in packaging it.

I finally (with great help from Tobi) achieved this goal, and the library is 
waiting in ftp NEW queue [1]

Unfortunately this morning while I was working in packaging poedit, I noticed 
that a git branch was already available on collab-maint, and I did the whole 
work again, because the git was missing some debian/unstable releases, with 
important fixes, and it never got any upload.


I'm attaching the lucene++ debian directory, the source can be found here [2], 
and I'm pushing on collab-maint the changes I did (and the merge).

The new releases are huge in size terms, so I removed the deps directory 
from the source tarball prior to the import (don't know why upstream bundles 
lucene/wx/boost/... making the source something like 700MB (uncompressed).

The debian/copyright still needs to be updated, but I'm pushing the changes to 
let you know the progresses I did and collaborate on the same repository.

Please don't spare your work and your time, let's follow up on the same 
repository [3]:)

[1] https://ftp-master.debian.org/new/lucene++_3.0.6-1.html

[2] https://github.com/luceneplusplus/LucenePlusPlus

[3] http://anonscm.debian.org/cgit/collab-maint/poedit.git

thanks,


Gianfranco

lucene++_3.0.6-1.debian.tar.gz
Description: GNU Zip compressed data

Bug#749815: Package updated

[Gianfranco Costamagna]

Hi again,



Il Martedì 9 Settembre 2014 15:12, Gianfranco Costamagna 
costamagnagianfra...@yahoo.it ha scritto:




Hi Andreas and Timur,


As you might have noticed the new poedit releases uses lucene++ library, this 
is why in the last few weeks I focused in packaging it.

I finally (with great help from Tobi) achieved this goal, and the library is 
waiting in ftp NEW queue [1]

Unfortunately this morning while I was working in packaging poedit, I noticed 
that a git branch was already available on collab-maint, and I did the whole 
work again, because the git was missing some debian/unstable releases, with 
important fixes, and it never got any upload.


I'm attaching the lucene++ debian directory, the source can be found here [2], 
and I'm pushing on collab-maint the changes I did (and the merge).

The new releases are huge in size terms, so I removed the deps directory 
from the source tarball prior to the import (don't know why upstream bundles 
lucene/wx/boost/... making the source something like 700MB (uncompressed).

The debian/copyright still needs to be updated, but I'm pushing the changes to 
let you know the progresses I did and collaborate on the same repository.

the copyright is up-to-date now.

I also switched to autoreconf,

waiting for a review :)

thanks


G. 



--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1410270835.42798.yahoomail...@web171802.mail.ir2.yahoo.com

Bug#700556: I intend to adopt the package

[Gianfranco Costamagna]

Hi,

Since nobody stepped up for adopting it I did some work.

I updated it to the latest upstream release, updated the debian packaging, 
fixed some lintian warnings and took care of the build system.

The copyright file should be now up-to-date, and I uploaded the new package on 
mentors
http://mentors.debian.net/package/wapiti

have many thanks,



Gianfranco


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1409820264.35870.yahoomail...@web171805.mail.ir2.yahoo.com

Bug#737050: Some corrections to the package

[Gianfranco Costamagna]

Hi olly,




 Il Lunedì 1 Settembre 2014 18:36, Olly Betts o...@survex.com ha scritto:
  On Mon, Sep 01, 2014 at 02:52:43PM +0100, Gianfranco Costamagna wrote:
  Hi, I packaged wx3.0 doc, and after that I discovered this ITP and the
  package on mentors...
 
 I'm happy someone's packaging it, but slightly surprised that nobody
 thought to mention it to the wx maintainers.
 
  For the maintainer I think freewx-maint is the best choice... But I
  don't have a strong opinion and I have no upload possibilities 
 
 It seems sensible to me for it to be under the team umbrella, since
 we maintain the package it is the documentation for, and coordinating
 uploads of new versions would be helpful to users.  I'm certainly happy
 for more people to join the team.
 
  diff -Nru wx3.0-doc-3.0.1/debian/wx3.0-doc.linktrees 
 wx3.0-doc-3.0.1/debian/wx3.0-doc.linktrees
  --- wx3.0-doc-3.0.1/debian/wx3.0-doc.linktrees1970-01-01 
 01:00:00.0 +0100
  +++ wx3.0-doc-3.0.1/debian/wx3.0-doc.linktrees2014-09-01 
 15:34:21.0 +0200
  @@ -0,0 +1 @@
  +replace usr/share/javascript/jquery/jquery.js 
 usr/share/doc/wx3.0-doc/jquery.js
 
 My understanding is that doxygen uses a patched version of jquery, so
 this replacement isn't correct.  I'm not sure what the recommended way
 to fix this is though.  There's some information here:
 
 https://bugs.debian.org/736360
 

I looked carefully at them, however I don't agree my solution is wrong.

Please look at the jquery 1.7.1 code
http://code.jquery.com/jquery-1.7.1.min.js
and meld with the jquery.js code inside

aside from 3 \r\n in the upstream minified code, it is the same file, no 
patches at all.

So I presume the debian jquery 1.7.2 will be just fine (I little tested it and 
it was fine aside from some little render bug, but I don't think it was jquery 
specific)

Your referred bug is when we _build_ the doxygen documentation, here we have 
the already built one, so we just need to copy-paste it.

Would be nice to force upstream to give the source doxygen documentation, but 
at least I think my solution is the best one (for the moment).


Please also look here [1]. If upstream starts providing doxygen documentation 
we will likely need to override the bug and fix doxygen instead.

[1] https://lists.debian.org/debian-mentors/2012/11/msg00313.html

Cheers,


Gianfranco
 Cheers,
 
 Olly
 
 -- 
 To unsubscribe, send mail to 737050-unsubscr...@bugs.debian.org.



--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1409653959.75300.yahoomail...@web171802.mail.ir2.yahoo.com

Bug#737050: Some corrections to the package

[Gianfranco Costamagna]

Hi, I packaged wx3.0 doc, and after that I discovered this ITP and the package 
on mentors...

For this reason I'm sending to you my debdiff against the version on mentors, 
really similar but with the jquery lintian error fixed.

Also the copyright file in my opinion was outdated, so I changed it, removing 
the wx3.0 code specific copyrights.

BTW feel free to change and remove me from uploaders, I thought nobody was 
caring so I took the possibility, but if you care feel free to go on ;)

For the maintainer I think freewx-maint is the best choice... But I don't have 
a strong opinion and I have no upload possibilities 


diff -Nru wx3.0-doc-3.0.1/debian/changelog wx3.0-doc-3.0.1/debian/changelog
--- wx3.0-doc-3.0.1/debian/changelog2014-08-24 07:33:42.0 +0200
+++ wx3.0-doc-3.0.1/debian/changelog2014-09-01 15:38:56.0 +0200
@@ -2,4 +2,4 @@
 
   * Initial release (Closes: #737050)
 
- -- SUGIMOTO Norimitsu dict...@live.jp  Sat, 19 Jul 2014 13:02:56 +0900
+ -- Sugimoto Norimitsu dict...@live.jp  Sat, 19 Jul 2014 13:02:56 +0900
diff -Nru wx3.0-doc-3.0.1/debian/control wx3.0-doc-3.0.1/debian/control
--- wx3.0-doc-3.0.1/debian/control2014-07-24 15:20:05.0 +0200
+++ wx3.0-doc-3.0.1/debian/control2014-09-01 15:40:58.0 +0200
@@ -1,21 +1,30 @@
 Source: wx3.0-doc
 Section: doc
-Maintainer: SUGIMOTO Norimitsu dict...@live.jp
-Build-Depends: debhelper (= 9)
+Priority: optional
+Build-Depends: debhelper (=9), dh-linktree, libjs-jquery
+Maintainer: wxWidgets Maintainers freewx-ma...@lists.alioth.debian.org
+Uploaders: Olly Betts o...@survex.com,
+ Sugimoto Norimitsu dict...@live.jp,
+ Gianfranco Costamagna costamagnagianfra...@yahoo.it
 Standards-Version: 3.9.5
+Vcs-Git: git://anonscm.debian.org/freewx/wx.git -b wx3.0-doc
+Vcs-Browser: 
https://anonscm.debian.org/gitweb/?p=freewx/wx.git;a=shortlog;h=refs/heads/wx3.0-doc
 Homepage: http://www.wxwidgets.org/
-#Vcs-Git: git://anonscm.debian.org/collab-maint/wx3.0-doc.git
-#Vcs-Browser: http://anonscm.debian.org/?p=collab-maint/wx3.0-doc.git;a=summary
 
 Package: wx3.0-doc
 Section: doc
 Architecture: all
-Provides: wx-doc
+Provides: wx3.0-doc
 Suggests: doc-base, www-browser
 Depends: ${misc:Depends}
 Description: wxWidgets Cross-platform C++ GUI toolkit (documentation)
- wxWidgets (formerly known as wxWindows) is a class library for C++ providing
- GUI components and other facilities on several popular platforms (and some
- unpopular ones as well).
+ wxBase is a collection of C++ classes providing basic data structures
+ (strings, lists, arrays), powerful wxDateTime class for date manipulations,
+ portable wrappers around many OS-specific functions allowing the same
+ program to work for all supported platforms, wxThread class for writing
+ multithreaded programs, and much more.
+ .
+ wxBase currently supports the following platforms: Generic Unix (Linux,
+ FreeBSD, Solaris, HP-UX, ...), Microsoft Windows, and Mac OS X.
  .
  This package provides a HTML version of the wxWidgets reference manual.
diff -Nru wx3.0-doc-3.0.1/debian/copyright wx3.0-doc-3.0.1/debian/copyright
--- wx3.0-doc-3.0.1/debian/copyright2014-07-24 15:20:05.0 +0200
+++ wx3.0-doc-3.0.1/debian/copyright2014-09-01 15:41:19.0 +0200
@@ -1,5 +1,5 @@
-This package was debianized by Ron Lee r...@debian.org on
-Sun, 13 Feb 2000 18:40:00 +1030.
+This package was debianized by Gianfranco Costamagna 
costamagnagianfra...@yahoo.it
+and Sugimoto Norimitsu dict...@live.jp, on Tue, 26 Aug 2014 18:00:06 +0200.
 
 More information about wxWidgets, as well as the source these debs
 are produced from can be found at http://www.wxwidgets.org/
@@ -192,295 +192,3 @@
   OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
 
 -
-
-src/stc/scintilla is licensed as follows:
-
-License for Scintilla and SciTE
-
-Copyright 1998-2003 by Neil Hodgson ne...@scintilla.org
-
-All Rights Reserved 
-
-Permission to use, copy, modify, and distribute this software and its 
-documentation for any purpose and without fee is hereby granted, 
-provided that the above copyright notice appear in all copies and that 
-both that copyright notice and this permission notice appear in 
-supporting documentation. 
-
-NEIL HODGSON DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS 
-SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY 
-AND FITNESS, IN NO EVENT SHALL NEIL HODGSON BE LIABLE FOR ANY 
-SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES 
-WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, 
-WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER 
-TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE 
-OR PERFORMANCE OF THIS SOFTWARE. 
-
--
-
-src/expat (unused in the debian binary packages) is licensed as follows:
-
-Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd

Bug#657499: #657499: ITP: pootle -- Web-based translation and translation management tool

[Gianfranco Costamagna]

 Il Giovedì 6 Giugno 2013 15:03, Stuart Prescott stu...@debian.org ha 
 scritto:
  Hi Gianfranco,
 

Hi Stuart,
sorry for the loong delay, I was waiting for the django upload and I completely 
forgot about this mail

 
 On Thursday 06 June 2013 20:04:28 you wrote:
  I would like to contribute in pootle packaging if needed.
  Now Translate Toolkit is in unstable.
 
 thanks for your offer -- packaging pootle is currently stalled on its django 
 support. Pootle 2.5 doesn't work with django 1.5 which is what we have in 
 unstable now. A release of pootle that works with django 1.5 might be some 
 time off given the release schedule outlined by pootle's developers [1].
 
 [1]  
 http://docs.translatehouse.org/projects/pootle/en/latest/developers/release.html
 
 Pootle also needs a newer version of python-django-south than what is in sid, 
 although the maintainer of that package is planning to upload it soon.
 
 For now, I think it's worth trying to get whatever packaging we can done, 
 relying on an older version of django from snapshot.debian.org until the 
 newer 
 version of pootle is released.
 
 I've started the conversion of of the old pootle svn to git and will copy 
 that 
 over to alioth when I get a chance -- if you'd like to help out, please join 
 

I think now we have both django and python-django-south ready in testing, can 
we try again with pootle?

 #debian-i18n on irc.oftc.net (irc.debian.org) to coordinate.

already there, also requested the alioth add to l10n group.


cheers,

Gianfranco

 
 cheers
 Stuart
 
 -- 
 Stuart Prescott    http://www.nanonanonano.net/   stu...@nanonanonano.net
 Debian Developer  http://www.debian.org/         stu...@debian.org
 GPG fingerprint    BE65 FD1E F4EA 08F3 23D4 3C6D 9FE8 B8CD 71C5 D1A8
 GPG fingerprint    90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
 
 -- 
 To unsubscribe, send mail to 657499-unsubscr...@bugs.debian.org.



--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1406556595.40082.yahoomail...@web171801.mail.ir2.yahoo.com

Bug#657499: #657499: ITP: pootle -- Web-based translation and translation management tool

[Gianfranco Costamagna]

 Il Lunedì 28 Luglio 2014 17:10, Stuart Prescott stu...@debian.org ha 
 scritto:
  Hi Gianfranco,
 
  I think now we have both django and python-django-south ready in testing,
  can we try again with pootle?
 
 The current release of pootle is not compatible with the version of django 
 that is in sid. This is an on-going problem with django and short of 
 introducing multiple django packages into debian, I don't know how we are 
 going to solve it. The cadence of deprecation of APIs within django is simply 
 faster than the pootle developers seem to be able to keep pace with and the 
 eagerness of the django maintainers to track new upstream releases leaves us 
 in a very difficult position.
 

Oh... so seems that the django version is not too old to be useless, but too 
new, right?

I missed that part, it is somewhat strange this kind of API handling, and 
furthermore the deprecation of stuff in new releases is somewhat difficult to 
track for other projects to follow :(

I see two (both ugly) solutions:
- Ask to django developers to provide a more stable API (what is the benefit of 
providing a such unstable API?)
but I'm sure they have their *strong* arguments for doing it
-ask pootle people to embed django in their source code (I know debian disallow 
this kind of embedded libraries, unless there is a *good* reason to do it, and 
this one might be a good reason, or not?)

just giving my two cents,

sorry for thinking that an *upper* version was good

cheers!

Gianfranco

 
 cheers
 Stuart
 
 
 -- 
 Stuart Prescott    http://www.nanonanonano.net/   stu...@nanonanonano.net
 Debian Developer  http://www.debian.org/         stu...@debian.org
 GPG fingerprint    90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7



--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1406560750.27861.yahoomail...@web171803.mail.ir2.yahoo.com

Bug#657499: #657499: ITP: pootle -- Web-based translation and translation management tool

[Gianfranco Costamagna]

 Il Lunedì 28 Luglio 2014 17:33, Stuart Prescott stu...@debian.org ha 
 scritto:
  Hi Gianfranco,
 
  Oh... so seems that the django version is not too old to be useless, but
  too new, right?
 
 that's correct
 
 The django people have a pretty rigorous deprecation schedule where they mark 
 parts of the API as deprecated for a period of time prior to actual removal. 
 The intention of this is to give users of this code time to adjust. The 
 problem is that the scale and speed of the changes is still mismatched to 
 what 
 upstreams like pootle can manage.
 
 I don't think an embedded copy of django is something we want to deal with 
 so 
 I'm not even entertaining this thought just yet.
 
 thanks for prodding again on this... we might yet come up with a solution to 
 the problem some how!
 

agreed this is why I said ugly :)

BTW just FYI

https://github.com/translate/pootle/blob/2727b7d9a813d0266e3da84058f4f232ea40e29c/requirements/base.txt

seems that the latest git can be fine with debian/unstable and debian/testing
Django=1.5.8,1.7

not with debian experimental, but this might be trivial to solve :)

maybe we can cherry-pick something or just wait for the release
http://docs.translatehouse.org/projects/pootle/en/latest/developers/roadmap.html
Estimated release April 2014  
Move to Django 1.5/1.6 – remove anything keeping us on Django 1.4.



cheers,

Gianfranco
 
 cheers
 Stuart
 
 
 -- 
 Stuart Prescott    http://www.nanonanonano.net/   stu...@nanonanonano.net
 Debian Developer  http://www.debian.org/         stu...@debian.org
 GPG fingerprint    90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
 
 -- 
 To unsubscribe, send mail to 657499-unsubscr...@bugs.debian.org.



--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1406561998.95651.yahoomail...@web171804.mail.ir2.yahoo.com

Bug#754472: (no subject)

[Gianfranco Costamagna]

Hi (again) Luciano!

I propose myself as comaintainer for this useful package!

 

cheers,



Gianfranco


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1405440336.35126.yahoomail...@web171806.mail.ir2.yahoo.com

Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters

[Gianfranco Costamagna]

 Il Domenica 6 Luglio 2014 15:51, Charles Plessy ple...@debian.org ha 
 scritto:
  Le Sun, Jul 06, 2014 at 10:33:35AM +0200, Andreas Tille a écrit :
 
  On Sat, Jul 05, 2014 at 04:37:16PM +0200, Ralf Treinen wrote:

This violates the Policy's section 10.1, but it is still my 
 favorite solution
for the reason that you explained above.
   
   I don't agree, packages should not be in conflict when it can be 
 easily avoided
   by renaming files.
 
  +1
 
 Hi Andreas,
 
 Feel free to rename yourself, but do not forget to remove me from the 
 uploaders
 list.
 
 On my side I find these renamings harmful and illogical.  The probability that
 people want to use both amaps on the same machine is close to zero, and the
 probability that users of both amaps will be annoyed by the rename is close to
 one.  I think that these renamings are applied dogmatically in a way that 
 makes
 Debian inferior.  I do not want to participate to this.
 

Hi Charles,

I really don't think there is any reason to rename your package.
I renamed my amap into amap-thc, and this should be fully 10.1 compliant now.
Since my package is a new one there is no reason to avoid such a rename, and I 
can work with new packages depending on it to patch them in the right way.

The package also creates a link into amap6, so really *nobody* should *ever* 
use directly amap (for my case).
If they do this, yes, I call it a bug.

So please don't touch your package and I'm uploading a new version of mine with 
all your really nice suggestions ;)

Cheers!

Gianfranco

 Cheers,
 
 -- 
 Charles Plessy
 Debian Med packaging team,
 http://www.debian.org/devel/debian-med
 Tsurumi, Kanagawa, Japan



--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1404658137.56179.yahoomail...@web171805.mail.ir2.yahoo.com

Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters

[Gianfranco Costamagna]

Hi Jonas,




 Il Sabato 5 Luglio 2014 14:27, Jonas Smedegaard d...@jones.dk ha scritto:
  Quoting Gianfranco Costamagna (2014-07-04 15:20:12)
 
  Package: wnpp
  Severity: wishlist
  Owner: Gianfranco Costamagna costamagnagianfra...@yahoo.it
 
  * Package name    : amap
    Version : 5.4
    Upstream Author : Van Hauser v...@thc.org
  * URL : http://www.thc.org/thc-amap/
  * License : GPL-2+
    Programming Lang: C
    Description : Next-generation scanning tool for pentesters
 
   AMAP stands for Application MAPper. It is a next-generation scanning
   tool for pentesters. It attempts to identify applications even if they
   are running on a different port than normal.
   .
   It also identifies non-ascii based applications. This is achieved by
   sending trigger packets, and looking up the responses in a list of
   response strings.
 
  I would like to reintroduce this useful package in debian, since bug 
  #381185 no longer applies and this tool is useful and used in 
  penetration testing and security (I took the Raphael package from kali 
  linux git).
 
 I suggest to mention the terms penetration testing and 
 security in 
 the long description, both to ease searching and to help those (like me) 
 puzzled what pentesters mean (I honestly guessed it might have 
 something to do with USB sticks, until I saw your comment at the end).
 
 Perhaps additional terms could be mentioned too, to ease searching (try 
 compare with related packages already in Debian, if any).
 
 

I did the changes and uploaded on mentors.

Description: Next-generation scanning tool for security pentesters
 AMAP stands for Application MAPper. It is a next-generation scanning
 tool for security penetration testers. It attempts to identify
 applications even if they are running on a different port than normal.
 .
 It also identifies non-ascii based applications. This is achieved by
 sending trigger packets, and looking up the responses in a list of
 response strings.


Thanks for the feedback, it was really appreciated!

cheers,

Gianfranco

 - Jonas
 
 -- 
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 
 [x] quote me freely  [ ] ask before reusing  [ ] keep private



--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1404658506.23501.yahoomail...@web171801.mail.ir2.yahoo.com