Bug#1083032: ITP: borgstore -- A simple key/value store implementation in Python
Package: wnpp Severity: wishlist Owner: Gianfranco Costamagna * Package name: borgstore Version : 0.0.4 Upstream Author : Thomas Waldmann * URL : https://github.com/borgbackup/borgstore * License : BSD-3-Clause Programming Lang: Python Description : A simple key/value store implementation in Python Binary package names: python3-borgstore A key/value store implementation in Python, supporting multiple backends, data redundancy and distribution. . Keys . A key (str) can look like: . - 0123456789abcdef... (usually a long, hex-encoded hash value) - Any other pure ASCII string without "/" or ".." or " ". . . Namespaces -- . To keep stuff apart, keys should get prefixed with a namespace, like: . - config/settings - meta/0123456789abcdef... - data/0123456789abcdef... . Please note: . 1. you should always use namespaces. 2. nested namespaces like namespace1/namespace2/key are not supported. 3. the code could work without a namespace (namespace ""), but then you can't add another namespace later, because then you would have created nested namespaces. . Values -- . Values can be any arbitrary binary data (bytes). . Store Operations . The high-level Store API implementation transparently deals with nesting and soft deletion, so the caller doesn't have to care much for that and the Backend API can be much simpler: . - create/destroy: initialize or remove the whole store. - list: flat list of the items in the given namespace, with or without soft deleted items. - store: write a new item into the store (giving its key/value pair) - load: read a value from the store (giving its key), partial loads giving offset and/or size are supported. - info: get information about an item via its key (exists? size? ...) - delete: immediately remove an item from the store (giving its key) - move: implements rename, soft delete / undelete, move to current nesting level - stats: api call counters, time spent in api methods, data volume/throughput - latency/bandwidth emulator: can emulate higher latency (via BORGSTORE_LATENCY [us]) and lower bandwidth (via BORGSTORE_BANDWIDTH [bit/s]) than what is actually provided by the backend. . Automatic Nesting - . For the Store user, items have names like e.g.: . namespace/0123456789abcdef... namespace/abcdef0123456789... . If there are very many items in the namespace, this could lead to scalability issues in the backend, thus the Store implementation offers transparent nesting, so that internally the Backend API will be called with names like e.g.: . namespace/01/23/56/0123456789abcdef... namespace/ab/cd/ef/abcdef0123456789... . The nesting depth can be configured from 0 (= no nesting) to N levels and there can be different nesting configurations depending on the namespace. . The Store supports operating at different nesting levels in the same namespace at the same time. . Soft deletion - . To soft delete an item (so its value could be still read or it could be undeleted), the store just renames the item, appending ".del" to its name. . Undelete reverses this by removing the ".del" suffix from the name. . Some store operations have a boolean flag "deleted" to choose whether they shall consider soft deleted items. . Backends . The backend API is rather simple, one only needs to provide some very basic operations. . Currently, these storage backends are implemented: . - POSIX filesystems (namespaces: directories, values: in key-named files) - SFTP (access a server via sftp, namespaces: directories, values: in key-named files) - Rclone - access any of the 100s of cloud providers [rclone](https://rclone.org/) supports - (more might come in future) . MStore -- . API of MStore is very similar to Store, but instead of directly using one backend only (like Store does), it uses multiple Stores internally to implement: . - redundancy (keep same data at multiple places) - distribution (keep different data at multiple places) . Scalability --- . - Count of key/value pairs stored in a namespace: automatic nesting is provided for keys to address common scalability issues. - Key size: there are no special provisions for extremely long keys (like: more than backend limitations). Usually this is not a problem though. - Value size: there are no special provisions for dealing with large value sizes (like: more than free memory, more than backend storage limitations, etc.). If one deals with very large values, one usually cuts them into chunks before storing them into the store. - Partial loads improve performance by avoiding a full load if only a part of the value is needed (e.g. a header with metadata). . Want a demo? . Run this to
Bug#1021460: ITA: elpa-rust-mode -- Major Emacs mode for editing Rust source code
happily sponsored thanks! G. On Sat, 02 Mar 2024 04:50:56 -0800 Xiyue Deng wrote: Control: retitle -1 ITA: elpa-rust-mode -- Major Emacs mode for editing Rust source code Control: tags -1 pending I'd like to adopt this package. I have prepared the updated package on mentors[1] and have filed a separate RFS bug[2]. [1] https://mentors.debian.net/package/elpa-rust-mode/ [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065302 -- Xiyue Deng OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055234: ITP: python-zombie-imp -- copy of the `imp` module that was removed in Python 3.12
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
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
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).
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
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
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
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)
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
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
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
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
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)
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
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
Package: wnpp Owner: Gianfranco Costamagna X-Debbugs-CC: debian-de...@lists.debian.org Severity: wishlist * Package name: vim-bitbake * Version : 0~git20170705-1 * Upstream Author : Chris Larson * 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)
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
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
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
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
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
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
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
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
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
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 "BuildTgz" and "BuildDebPackage"
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.
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
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
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
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
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.
(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
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
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
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
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
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 )
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
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
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
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
> 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
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
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
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#801253: O: wicd -- wired and wireless network manager
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&exclude=tags%3Apending&pend-exc=done&repeatmerged=no&src=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#808962: ITP: python-keyutils: Python bindings for keyutils
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
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
-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
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
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 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.
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.
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.
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.
-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
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
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 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 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
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
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
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#798529: ITP: python-xkcd
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
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#772823: R: kimchi: looking for a mentor
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#772823: Looking for a mentor for a couple of projects
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 >./plugins/sample/po/Makefile.in.in:# Copyright (C) 1995-1997, 2000-2007, >2009-2010 by Ulrich Drepper >./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#792096: borg packaging
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#787491: Looking for a mentor for a couple of projects
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 )" 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
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 )" 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
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 ha scritto: On Wed, Aug 05, 2015 at 04:10:56PM +0000, 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
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
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
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
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
Package: wnpp Owner: costamagnagianfra...@yahoo.it Severity: wishlist * Package name: libserial Version: 0.6.0~rc1 Upstream Author : Manish P. Pagey Crayzee Wulf Jay Sachdev Jan Wedekind * 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
Package: wnpp Severity: wishlist Owner: Gianfranco Costamagna * Package name: python-darts-lib-utils-lru Version: 0.5~git20140220-1 Upstream Author : 2011 Dirk Esser 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
Package: wnpp Owner: michele.mart...@uniroma2.it Severity: wishlist * Package name: fim Version : 0.4~rc3-1 Upstream Author : Michele Martone * 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
Package: wnpp Severity: wishlist Owner: Gianfranco Costamagna * 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 . 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
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 ha scritto: Hi Raphael, hi Gianfranco, Original-Nachricht Betreff: R: Bug#773656: ITP: daps -- DocBook Authoring and Publishing Suite Von: Gianfranco Costamagna 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
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
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#737050: patch for build with wx3.0-doc package
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 . 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#279422: (no subject)
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#722275: casablanca package
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#764177: ITP: websocketpp -- C++ only header library that implements RFC6455, The WebSocket Protocol.
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 RFP?
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?
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 doxygen problem
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#722275: casablanca package RFP?
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%20Linux&referringTitle=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#749815: Package updated
>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
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
> Il Mercoledì 10 Settembre 2014 9:00, Тимирханов Тимур > 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
Hi again, Il Martedì 9 Settembre 2014 15:12, Gianfranco Costamagna 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#749815: Package updated
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#700556: I intend to adopt the package
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
Hi olly, > Il Lunedì 1 Settembre 2014 18:36, Olly Betts 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
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 Sat, 19 Jul 2014 13:02:56 +0900 + -- Sugimoto Norimitsu 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 -Build-Depends: debhelper (>= 9) +Priority: optional +Build-Depends: debhelper (>=9), dh-linktree, libjs-jquery +Maintainer: wxWidgets Maintainers +Uploaders: Olly Betts , + Sugimoto Norimitsu , + Gianfranco Costamagna 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 on -Sun, 13 Feb 2000 18:40:00 +1030. +This package was debianized by Gianfranco Costamagna +and Sugimoto Norimitsu , 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 - -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 - and Clark Cooper -Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006 Expat maintainers. - -Permission is hereby granted, free of charge, to any person obtaining -a copy of t
Bug#657499: #657499: ITP: pootle -- Web-based translation and translation management tool
> Il Lunedì 28 Luglio 2014 17:33, Stuart Prescott 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#657499: #657499: ITP: pootle -- Web-based translation and translation management tool
> Il Lunedì 28 Luglio 2014 17:10, Stuart Prescott 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
> Il Giovedì 6 Giugno 2013 15:03, Stuart Prescott 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#754472: (no subject)
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