Bug#1059161: RFA: pypdf -- Pure-Python library built as a PDF toolkit (Python 3)
Package: wnpp Control: affects -1 + src:pypdf X-Debbugs-Cc: py...@packages.debian.org X-Debbugs-Cc: Daniel Kahn Gillmor Severity: normal I request an adopter for the pypdf package. The package description is: A Pure-Python library built as a PDF toolkit. It is capable of: - extracting document information (title, author, ...), - splitting documents page by page, - merging documents page by page, - cropping pages, - merging multiple pages into a single page, - encrypting and decrypting PDF files. . By being Pure-Python, it should run on any Python platform without any dependencies on external libraries. It can also work entirely on StringIO objects rather than file streams, allowing for PDF manipulation in memory. It is therefore a useful tool for websites that manage or manipulate PDFs. . This is the Python 3 version of the package.
Bug#1059160: RFA: pypdf2 -- Pure-Python library built as a PDF toolkit (Python 3)
Package: wnpp Control: affects -1 + src:pypdf2 X-Debbugs-Cc: pyp...@packages.debian.org X-Debbugs-Cc: Daniel Kahn Gillmor Severity: normal I request an adopter for the pypdf2 package. The package description is: A Pure-Python library built as a PDF toolkit. It is capable of: - extracting document information (title, author, ...), - splitting documents page by page, - merging documents page by page, - cropping pages, - merging multiple pages into a single page, - encrypting and decrypting PDF files. . By being Pure-Python, it should run on any Python platform without any dependencies on external libraries. It can also work entirely on StringIO objects rather than file streams, allowing for PDF manipulation in memory. It is therefore a useful tool for websites that manage or manipulate PDFs. . This is the Python 3 version of the package.
Bug#1055762: ITP: botan3 -- multiplatform crypto library (3.x version)
Package: wnpp Severity: wishlist Owner: Laszlo Boszormenyi (GCS) * Package name: botan Version : 3.2.0 Upstream Author : The Botan Authors * URL : https://botan.randombit.net/ * License : BSD-2-clause Programming Lang: C++ Description : multiplatform crypto library (3.x version) Botan is a C++ library which provides support for many common cryptographic operations, including encryption, authentication, and X.509v3 certificates and CRLs. A wide variety of algorithms is supported, including RSA, DSA, DES, AES, MD5, and SHA-1.
Bug#1029032: ITP: python-google-api-core -- Google API client core library
Package: wnpp Severity: wishlist Owner: Laszlo Boszormenyi (GCS) * Package name: python-google-api-core Version : 1.34.0 Upstream Author : 2014- Google Inc. * URL : https://github.com/googleapis/python-api-core * License : Apache-2.0 Programming Lang: Python Description : Google API client core library This library is not meant to be stand-alone. Instead it defines common helpers used by all Google API clients.
Bug#1001962: RFA: cdw -- tool for burning CD's - console version
Package: wnpp Severity: normal Hi, I request an adopter for cdw. While the packaging is in somewhat good condition, it has other problems. Its upstream is dead for more than five years, no more development is happening. Then it still uses genisoimage and wodim, built from cdrkit. These tools will not be part of our next stable release [1], meaning cdw needs a new upstream developer as well who make the changes for xorriso and libburnia. If no one adopts this package in some months, I will ask for its removal from the archives. Regards, Laszlo/GCS [1] https://bugs.debian.org/98
Bug#1001182: ITP: cbmconvert -- create and convert Commodore 8-bit binary file archives
Package: wnpp Severity: wishlist Owner: Laszlo Boszormenyi (GCS) * Package name: cbmconvert Version : 2.1.4 Upstream Author : Marko Mäkelä * URL : https://github.com/dr-m/cbmconvert/ * License : GPL-2+ Programming Lang: C Description : create and convert Commodore 8-bit binary file archives Extracts files from most known archive file formats that are used on 8-bit Commodore computer platforms and writes them to several different formats, including some formats used by some emulators. Package is basically ready, going to upload it in a day or two. Regards, Laszlo/GCS
Bug#996250: ITP: libcgif -- fast and lightweight GIF encoding library
Control: owner -1 ! Control: retitle -1 ITP: libcgif -- fast and lightweight GIF encoding library Package is ready and will be uploaded immediately.
Bug#981792: ITP: cc1541 -- tool for creating Commodore Floppy disk images in D64, G64, D71 or D81 format
Package: wnpp Severity: wishlist Owner: Laszlo Boszormenyi (GCS) * Package name: cc1541 Version : 3.2 Upstream Author : 2017- Claus, * URL : https://bitbucket.org/PTV_Claus/cc1541/ * License : MIT Programming Lang: C Description : tool for creating Commodore Floppy disk images in D64, G64, D71 or D81 format Tool for creating Commodore 1541 Floppy disk images in D64, D71 or D81 format with custom sector interleaving etc. Also supports extended tracks 35-40 using either SPEED DOS or DOLPHIN DOS BAM-formatting. It's an improved alternative of the c1541 tool present in VICE.
Bug#980308: ITP: open-roms -- ROM files for retro computers
Hi Reiner, On Sun, Jan 17, 2021 at 5:21 PM Reiner Herrmann wrote: > * Package name: open-roms [...] > With these ROM files in main, this would also allow vice (maintainer CC'ed) > to move from contrib to main, as it can then be used meaningfully with only > free software. Good point! I don't know when they can finish with C64 kernal and basic ROMs, but I guess it will take time. :( Ping me if you have anything to share. Thanks, Laszlo/GCS
Bug#977256: ITP: liquidctl -- Cross-platform CLI and Python drivers for AIO liquid coolers and other devices
Control: owner -1 ! Control: retitle -1 ITP: liquidctl -- Cross-platform CLI and Python drivers for AIO liquid coolers and other devices Packaged and going to upload it soon.
Bug#905068: ITP: dqlite -- High-availability SQLite with Raft consensus
Control: owner 905068 ! Make it right.
Bug#905068: ITP: dqlite -- High-availability SQLite with Raft consensus
Control: retitle 905068 ITP: dqlite -- High-availability SQLite with Raft consensus Control: owner 905068 ! Going to upload it soon and plan to maintain it in the long run. Clément acknowledged the ITP takeover.
Bug#970521: ITP: raft -- Raft Consensus protocol implementation
Package: wnpp Severity: wishlist Owner: Laszlo Boszormenyi (GCS) * Package name: raft Version : 0.9.25 Upstream Author : 2019- Canonical Ltd. * URL : https://github.com/canonical/raft * License : LGPL-3 with linking exception Programming Lang: C Description : Raft Consensus protocol implementation Fully asynchronous C implementation of the Raft consensus protocol. The library has modular design: its core part implements only the core Raft algorithm logic, in a fully platform independent way. On top of that, a pluggable interface defines the I/O implementation for networking (send/receive RPC messages) and disk persistence (store log entries and snapshots).
Bug#968477: ITP: revelation -- GNOME3 Password manager
Package: wnpp Severity: wishlist * Package name: revelation Version : 0.5.0 Upstream Author : Mikel Olasagasti Uranga * URL : https://revelation.olasagasti.info/ * License : GPL-2+ Programming Lang: Python 3 Description : GNOME3 Password manager Revelation is a password manager for the GNOME 3 desktop. It organizes accounts in a tree structure, and stores them as AES-encrypted XML. It's actually a reintroduce of the same named package. It was removed from the archives for being Python 2 only. Recently upstream ported it to GTK 3 and Python 3.
Bug#888705: Bug#965217: libgrpc++1: ServerBuilder::BuildAndStart hangs
Hi, On Fri, Jul 17, 2020 at 8:15 PM Michael R. Crusoe wrote: > Hello! As part of creating the new bazel-bootstrap we have run into a > bug fixed upstream in 1.30 https://github.com/grpc/grpc/issues/21213 but > we woudl like to not have to wait for abseil to pass the NEW queue. Tried not to bark into abseil packaging anymore, but I think we should move forward. It was already checked by FTP Masters and got rejected. Benjamin fixed that issue and uploaded it. Then again weeks passed. :( Please FTP Masters re-check abseil and accept it to the archives if everything is in order this time. Thanks, Laszlo/GCS
Bug#888705: abseil-cpp packaging
On Sat, May 23, 2020 at 2:39 PM Benjamin Barenblat wrote: > This is now in the NEW queue. Not anymore and not in the archives. What happened? Can I help? Cheers, Laszlo/GCS
Bug#888705: abseil-cpp packaging
On Wed, May 20, 2020 at 5:56 PM Benjamin Barenblat wrote: > On Tuesday, May 19, 2020, at 8:59 PM +0200, László Böszörményi (GCS) wrote: > > Doesn't build with GCC 10 due to symbol changes. > > Good point. Is there an established way to deal with this? Or should I > just upload this as-is to unstable and then upload a GCC-10-compatible > version to experimental? You don't have to - but please be prepared that when GCC 10 will be the default in Sid, Abseil will FTBFS. > On Wednesday, May 20, 2020, at 12:03 PM +0200, László Böszörményi (GCS) wrote: > > Please do build static libraries with the following patch. > > This is great – thanks! I’m still unfamiliar with CMake; I really > appreciate you figuring out the incantations to get it to build both. > > As written, this patch builds shared libraries first and then archives, > which causes abslTargets.cmake to prefer archives over shared objects > when linking against Abseil. I’d like to modify it to go in the other > order, thus preferring shared libraries over archives. Requiring an > explicit opt-in before using Abseil archives would make it more > difficult to accidentally violate the One Definition Rule by > accidentally double-linking an Abseil archive. Furthermore, it would > create less work for packagers trying to use the shared Abseil > libraries, which I expect will be the usual case inside Debian. Does > that sound reasonable? Yup, please do so. Thanks go to you for packaging it and hopefully uploaded soon. Laszlo/GCS
Bug#888705: abseil-cpp packaging
On Tue, May 19, 2020 at 6:28 PM Benjamin Barenblat wrote: > Okay, we’re all set. I’ve pushed my work to > https://salsa.debian.org/debian/abseil, and both command-line linking > and CMake integration work. Comments and suggestions are welcome – if I > don’t hear anything in the next day or two, I’ll go ahead and upload to > NEW. Please do build static libraries with the following patch. Even Google projects link with static Abseil libraries and the project itself also allow it[1]: "ALLOWED: Distribute a static library built with an LTS branch of Abseil. Because LTS branches use inline namespaces for all absl:: symbols, collisions between potential Abseil “versions” should not occur, though your library may incur code bloat." I do not want to push it without being a co-maintainer or without discussion, but please do it yourself. Thanks, Laszlo/GCS [1] https://abseil.io/about/releases diff -Nru abseil-0~20200225.2/debian/libabsl-dev.install abseil-0~20200225.2/debian/libabsl-dev.install --- abseil-0~20200225.2/debian/libabsl-dev.install 2020-05-12 22:16:31.0 + +++ abseil-0~20200225.2/debian/libabsl-dev.install 2020-05-20 09:43:24.0 + @@ -13,5 +13,6 @@ # the License. usr/include/absl +usr/lib/*/*.a usr/lib/*/*.so usr/lib/*/cmake diff -Nru abseil-0~20200225.2/debian/rules abseil-0~20200225.2/debian/rules --- abseil-0~20200225.2/debian/rules 2020-05-12 22:16:31.0 + +++ abseil-0~20200225.2/debian/rules 2020-05-20 09:43:24.0 + @@ -15,12 +15,24 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow -%: - dh $@ +override_dh_auto_clean: + $(RM) -r $(CURDIR)/shared + $(RM) -r $(CURDIR)/static override_dh_auto_configure: - dh_auto_configure -- -DCMAKE_CXX_STANDARD=14 -DBUILD_SHARED_LIBS=ON + dh_auto_configure -Bshared \ + -- -DCMAKE_CXX_STANDARD=14 -DBUILD_SHARED_LIBS=ON + dh_auto_configure -Bstatic \ + -- -DCMAKE_CXX_STANDARD=14 -DBUILD_SHARED_LIBS=OFF + +override_dh_auto_build: + dh_auto_build -Bshared + dh_auto_build -Bstatic override_dh_auto_install: - dh_auto_install + dh_auto_install -Bshared + dh_auto_install -Bstatic find debian/tmp -type d -empty -delete + +%: + dh $@
Bug#888705: abseil-cpp packaging
On Tue, May 19, 2020 at 6:28 PM Benjamin Barenblat wrote: > Okay, we’re all set. I’ve pushed my work to > https://salsa.debian.org/debian/abseil, and both command-line linking > and CMake integration work. Comments and suggestions are welcome – if I > don’t hear anything in the next day or two, I’ll go ahead and upload to > NEW. Just some points that come to mind. Backport to oldstable will not be easily possible, but not a problem for me. File 'control' might be better autogenerated with the ABI string easily changeable, but well 'sed s///' works as well. Doesn't build with GCC 10 due to symbol changes. How do you plan Git tagging? Might be better to prefix current tags with 'upstream/' and have Debian releases under 'debian/'. Rules-Requires-Root might be set to 'no' I guess, but that's nitpicking. Very well done packaging otherwise. Thanks, Laszlo/GCS
Bug#888705: abseil-cpp packaging
On Wed, May 13, 2020 at 12:17 AM Benjamin Barenblat wrote: > If it’s all right with you, I’d prefer to stick with src:abseil. That > more closely matches the way the terminology is used within Google – > “Abseil” is unambiguously the C++ project, and “Abseil Python” is its > Python counterpart. It's OK. You can do the following in your repository: git remote add origin https://salsa.debian.org/debian/abseil git push --force origin master That should be it. Regards, Laszlo/GCS
Bug#888705: abseil-cpp packaging
On Thu, May 7, 2020 at 5:57 PM Benjamin Barenblat wrote: > I’m getting very close to an Abseil upload. The CMake integration > doesn’t work yet, but I can install the binary packages and build > software that links Abseil. Good news. > I’m going to keep working on CMake support, but I’d love to upload what > I have to Salsa. Would somebody be willing to reset the > https://salsa.debian.org/debian/abseil repository to a pristine state so > I can push to it without any of the old history in that repo? I’d do it > myself, but Google has some weird rules about creating new repositories; > it would be much easier for me if someone else could create the repo and > give me push access. All Debian Developers have push access under /debian but only admins can delete / create repositories there. If I understand correctly, you retained src:abseil. If not and using src:abseil-cpp then you need a new repository named after that. Which way should I go? Cheers, Laszlo/GCS
Bug#888705: Bug#959675: libgrpc++1: endless looping with default settings
On Sun, May 3, 2020 at 10:21 PM Benjamin Barenblat wrote: > On Sunday, May 3, 2020, at 8:16 PM +0200, László Böszörményi (GCS) wrote: > > Benjamin, do you want to package and maintain [Abseil] instead? Indeed, I meant packaging _Abseil_. > I’ve been working on packaging it for the last few weeks, and I’m making > good progress. Would an upload this week fit your timetable? On 30th of May several important packages (GitLab, OpenStack) will be autoremoved from Bullseye due to this RC bug. It would be good if Abseil packaged, uploaded and accepted to the archives until then - calculating one or two extra days for me to package gRPC 1.28.1 depending on Abseil and have the five days to migrate to testing. If you agree, package it as src:abseil-cpp and I can double check your packaging if you would like. Thanks in advance, Laszlo/GCS
Bug#888705: Bug#959675: libgrpc++1: endless looping with default settings
Control: block 959675 by 888705 Hi Eduard and Anton, On Sun, May 3, 2020 at 7:15 PM Eduard Bloch wrote: > Package: libgrpc++1 > Version: 1.26.0-3 > Severity: serious [...] > Tried to setup a basic POC using gRPC. Used the example source code for > Cpp from this source package, and dev package and protoc from regular > Debian Sid. [...] > Nothing works. All sample programs get stuck in the beginning before > opening or connecting TCP ports and inf-loop on a CPU core. > > Backtrace check indicates that this is a variant of > https://github.com/grpc/grpc/issues/21280 . [...] > Bugs like this never to arrive in Debian and not remain there for months. > The Sid version is 3 months behind upstream. Newer gRPC releases need a new dependency, abseil-cpp. Anton is in the process of packaging it - still for two years he couldn't finish it. :( Anton, please finish packaging in the next few days or I plan to take over it. Benjamin, do you want to package and maintain instead? Regards, Laszlo/GCS
Bug#888705: abseil-cpp packaging
On Thu, Feb 27, 2020 at 9:51 AM Olaf van der Spek
wrote:
> Op do 27 feb. 2020 om 06:54 schreef László Böszörményi :
> > Are you going to rename it to abseil-cpp (as Google has abseil-python
> > as well, make a disparity between the two)?
>
> Python libraries use a "python3-" prefix while C/C++ libraries use a
> "lib" prefix, so I don't think it makes sense to change the name.
Libraries use lib, python packages use python{,3}- as prefix, yes.
But I mean src:abseil should be src:abseil-cpp to be the same upstream
uses[1].
Laszlo/GCS
[1] https://github.com/abseil/abseil-cpp
Bug#955810: ITP: upb -- small protobuf implementation in C
Package: wnpp Severity: wishlist * Package name: upb Version : 0.0.0 (git) Upstream Author : Google Inc. * URL : https://github.com/protocolbuffers/upb/wiki * License : BSD-3-Clause Programming Lang: C Description : small protobuf implementation written in C upb generates a C API for creating, parsing, and serializing messages as declared in .proto files. upb is heavily arena-based: all messages always live in an arena (note: the arena can live in stack or static memory if desired).
Bug#888705: abseil-cpp packaging
On Wed, Feb 26, 2020 at 10:28 PM Benjamin Barenblat wrote: > https://github.com/abseil/abseil-cpp/pull/628 will let you test against > the gtest in Debian simply by passing `-DABSL_RUN_TESTS=ON > -DABSL_USE_GOOGLETEST_HEAD=OFF` to CMake. It looks like I just missed > the LTS release of a few hours ago, but just patching this in should be > fine. That's very nice of you. > I’ll try to have a look at the packaging in Salsa before the end of this > week. Are you going to rename it to abseil-cpp (as Google has abseil-python as well, make a disparity between the two)? @Anton: No one would like to step on your toes - definitely not me - still your last visible activity was two years ago. Please push your changes if you may any ready. Thanks, Laszlo/GCS
Bug#888705: abseil-cpp packaging
On Tue, Feb 18, 2020 at 2:31 AM Benjamin Barenblat wrote: > On Sunday, February 16, 2020, at 10:48 PM +0100, László Böszörményi (GCS) > wrote: > > In my reading abseil is _not_ guaranteed to have ABI compatibility at > > all times. That's why it meant to be a static library collection only. > > Forcing it to build shared libraries and have other packages than > > libabseil-cpp-dev is no sense I think. > > Abseil does reserve the right to break ABI at any time, and I can’t > speak to their future plans. But I think ABI breakages are unlikely to > occur in practice within an LTS release. If we wait and then package an > LTS release, I it’ll be completely reasonable to ship .so’s and .a’s. There's a compatibility page[1] what Abseil is and isn't. It states the following things. "We do not promise any ABI compatibility — we intend for Abseil to be built from source, hopefully from head. The internal layout of our types may change at any point, without notice." As I read waiting for LTS releases might be late (its head commit version advised to be used). I guess other Google applications other libraries commonly wants newer Abseil releases than LTS ones. "Not all Abseil libraries are suitable for dynamic loading. Some libraries have startup/initialization requirements and may not be suitable for dynamic loading. We will try to be clear about which libraries are OK for dynamic loading. However we don’t generally deploy code in this fashion, mistakes are possible, [...]". That is, even shared libraries can be built, those are not guaranteed to work. "We will not break API compatibility. If we must, we will ship a tool to automate the upgrade to a preferred API." Seems to suggest using the head (latest commit) freely and link with the static libraries of the applications. > Relatedly, I think we should only package LTS Abseil for Debian. If > someone finds a CVE in Abseil, the Abseil team are going to want to > backport the fix to LTS releases; they’re not going to want to backport > it everywhere else. I think there should be a compatibility matrix or test if the latest LTS release is enough for most Google applications or those need newer versions (no new API added for recent application development). Even if I agree that LTS releases are better for long time use cases and from security point of view. > > @Benjamin: may you ask its developers to use the system gtest libraries > > if only ABSL_RUN_TESTS set to ON? > > Absolutely. I’ll bring it up with them at work tomorrow (today was a US > holiday). Thanks. Please keep us posted how it goes. Regards, Laszlo/GCS [1] https://abseil.io/about/compatibility
Bug#774005: ITP: photoflow -- fully non-destructive photo retouching program
Hi Gürkan, On Mon, Feb 17, 2020 at 7:50 AM Gürkan Myczko wrote: > Pity you're not on IRC, there's the upstream channel at #pixls.us, > your dget URL didn't work for me today, however I couldn't find yours > on salsa.d.* so I didn't know. Are you going to upload it? Maybe > we can be co-maintainers among the multimedia team (unless you suggest > another team), The machine got stolen. I still have the packaging on my local disk, but no intention to upload at the moment. I already have enough packages to take care of. > here's my work so far (also on salsa): > http://phd-sid.ethz.ch/debian/photoflow/test/ Looks promising. For the first look the copyright file needs more work like you mentioned. The CC-BY-4.0 license text is missing for example. I need to check the correct CC0-1.0 license type. Other than that it's quite OK. Ping me when you are done and I can sponsor the upload for you. Regards, Laszlo/GCS
Bug#888705: abseil-cpp packaging
Hi Anton, Benjamin, On Sun, Feb 16, 2020 at 9:53 PM Anton Gladky wrote: > feel free to check the package on salsa > and prepare merge request. I don't send a merge request as while it's a very little package we do it very differently. In my reading abseil is _not_ guaranteed to have ABI compatibility at all times. That's why it meant to be a static library collection only. Forcing it to build shared libraries and have other packages than libabseil-cpp-dev is no sense I think. Benjamin may or may not confute this, let's hear him. Then the self-testing can be disabled now, no need to comment that out. Pass the following to dh_auto_configure: -DABSL_RUN_TESTS=OFF \ -DABSL_USE_GOOGLETEST_HEAD=OFF Of course it would be encouraged to have package testing. But it works only with both options set to ON and have internet access to git clone google test to the source tree. @Benjamin: may you ask its developers to use the system gtest libraries if only ABSL_RUN_TESTS set to ON? Regards, Laszlo/GCS
Bug#888705: abseil-cpp packaging
Hi Anton, Benjamin, I also need abseil, to be precise abseil-cpp (as there's abseil-py as well). Even contacted by some Google employee if I have time to package it. Done it and ready to be uploaded. Do you allow me to take over (and rename the package to abseil-cpp)? Feel free to do it yourself, but please then do it in the next few days - or let me do it. Regards, Laszlo/GCS
Bug#949309: ITP: 64tass -- cross (turbo) assembler targeting the MOS 65xx series of micro processors
Package: wnpp Severity: wishlist Owner: Laszlo Boszormenyi (GCS) * Package name: 64tass Version : 1.54.1900 Upstream Author : Zsolt Kajtar * URL : http://tass64.sourceforge.net/ * License : GPL-2+ Programming Lang: C Description : cross (turbo) assembler targeting the MOS 65xx series of micro processors Multi pass optimizing macro assembler for the 65xx series of processors. Key features: - Familiar syntax to Omicron TASS and TASM - Supports 6502, 65C02, R65C02, W65C02, 65CE02, 65816, DTV, 65EL02, 4510 - Arbitrary-precision integers and bit strings, double precision floating point numbers - Character and byte strings, array arithmetic - Handles UTF-8, UTF-16 and 8 bit RAW encoded source files, Unicode character strings - Supports Unicode identifiers with compatibility normalization and optional case insensitivity - Built-in `linker' with section support - Various memory models, binary targets and text output formats (also Hex/ S-record) - Assembly and label listings available for debugging or exporting - Conditional compilation, macros, structures, unions, scopes
Bug#948362: ITP: nng -- nanomsg next generation
Package: wnpp Severity: wishlist Owner: Laszlo Boszormenyi (GCS) * Package name: nng Version : 1.2.3 Upstream Author : Copyright 2018 Staysail Systems, Inc. , Copyright 2018 Capitar IT Group BV * URL : https://github.com/nanomsg/nng/ * License : MIT Programming Lang: C Description : Lightweight Messaging Library NNG, like its predecessors nanomsg (and to some extent ZeroMQ), is a lightweight, broker-less library, offering a simple API to solve common recurring messaging problems, such as publish/subscribe, RPC-style request/reply, or service discovery. The API frees the programmer from worrying about details like connection management, retries, and other common considerations, so that they can focus on the application instead of the plumbing.
Bug#932971: ITP: squashfs-tools-ng -- A new set of tools for working with SquashFS images
Control: close 932971 0.7-1 On Thu, Jul 25, 2019 at 11:51 AM László Böszörményi (GCS) wrote: > * Package name: squashfs-tools-ng > Version : 0.4.2 > Upstream Author : David Oberhollenzer > * URL : https://github.com/AgentD/squashfs-tools-ng > * License : GPL-3+ > Programming Lang: C > Description : A new set of tools for working with SquashFS images This has been packaged, uploaded and accepted to the archives. Due to bad changelog generation on my side this ITP was not closed automatically.
Bug#932971: ITP: squashfs-tools-ng -- A new set of tools for working with SquashFS images
On Wed, Oct 23, 2019 at 10:13 AM David Oberhollenzer wrote: > On 10/22/19 9:15 PM, László Böszörményi (GCS) wrote: > > You can get the updated, 0.7-1 release[1], but please note that its > > self-testing is constantly failing: > > FAIL: test_fstree_init > > == > > > > test_fstree_init: tests/fstree_init.c:32: main: Assertion > > `fs.defaults.st_mtime == 0' failed. > > FAIL test_fstree_init (exit status: 134) > > > > Can you check it David? I've tried it on three machines. Two of these > > are running on amd64 and one is on i386 architecture. > > Do you have the "SOURCE_DATE_EPOCH" environment variable set? Indeed, for some time now our build system set it. > The default was to initialize mtime to 0. Later this got patched to use > the value of SOURCE_DATE_EPOCH and only default to 0 if the environment > variable wasn't set. > > I could reproduce the behavior that way and pushed a fix. Backported and I do confirm that now the tests are passing. Package split is done as you have separate libraries now. Updated on the previously mentioned location and just going to upload it. Thanks, Laszlo/GCS
Bug#932971: ITP: squashfs-tools-ng -- A new set of tools for working with SquashFS images
On Wed, Oct 16, 2019 at 9:45 PM Johannes Schauer wrote: > On Thu, 25 Jul 2019 11:51:00 +0200 László Böszörményi (GCS) > wrote: > > * Package name: squashfs-tools-ng > I see the package is still waiting in NEW. > > Where did you put the packaging VCS? I'd like to play around with it before > ftp > master manages to approve it. :) You can get the updated, 0.7-1 release[1], but please note that its self-testing is constantly failing: FAIL: test_fstree_init == test_fstree_init: tests/fstree_init.c:32: main: Assertion `fs.defaults.st_mtime == 0' failed. FAIL test_fstree_init (exit status: 134) Can you check it David? I've tried it on three machines. Two of these are running on amd64 and one is on i386 architecture. Regards, Laszlo/GCS [1] http://www.barcikacomp.hu/gcs/squashfs-tools-ng_0.7-1.dsc
Bug#932971: ITP: squashfs-tools-ng -- A new set of tools for working with SquashFS images
Hi Johannes, On Wed, Oct 16, 2019 at 9:41 PM Johannes Schauer wrote: > On Thu, 25 Jul 2019 11:51:00 +0200 László Böszörményi (GCS) > wrote: > > * Package name: squashfs-tools-ng > > Version : 0.4.2 > I see the package is still waiting in NEW. Indeed. FTP Masters have enough things to do. :-/ > Where did you put the packaging VCS? I'd like to play around with it before > ftp > master manages to approve it. :) I don't use a VCS. The package needs updating anyway. As I'm abroad, please hold on until next Tuesday. Cheers, Laszlo/GCS
Bug#935155: Acknowledgement (ITP: plyverl -- fast and feature-rich Python interface to LevelDB)
Control: retitle -1 ITP: plyvel -- fast and feature-rich Python interface to LevelDB Fix typo of source package name. :-/
Bug#935155: ITP: plyverl -- fast and feature-rich Python interface to LevelDB
Package: wnpp Severity: wishlist * Package name: plyvel Version : 1.1.0 Upstream Author : Wouter Bolsterlee * URL : https://plyvel.readthedocs.io/en/latest/ * License : BSD-3-Clause Programming Lang: Python Description : fast and feature-rich Python interface to LevelDB Wraps most of the LevelDB C++ API and adds some features of its own. In addition to basic features like getting, putting and deleting data, Plyvel allows you to use write batches, database snapshots, very flexible iterators, prefixed databases, bloom filters, custom cache sizes, custom comparators, and other goodness LevelDB has to offer. As python-leveldb is Python 2 only and abandoned long time ago, I'd like to package a new LevelDB bindings with Python 3 support.
Bug#932971: ITP: squashfs-tools-ng -- A new set of tools for working with SquashFS images
Package: wnpp Severity: wishlist Owner: Laszlo Boszormenyi (GCS) * Package name: squashfs-tools-ng Version : 0.4.2 Upstream Author : David Oberhollenzer * URL : https://github.com/AgentD/squashfs-tools-ng * License : GPL-3+ Programming Lang: C Description : A new set of tools for working with SquashFS images Squashfs is a highly compressed read-only filesystem for Linux. It uses zlib compression to compress both files, inodes and directories. Inodes in the system are very small and all blocks are packed to minimise data overhead. Block sizes greater than 4K are supported up to a maximum of 64K. Squashfs is intended for general read-only filesystem use, for archival use (i.e. in cases where a .tar.gz file may be used), and in constrained block device/memory systems (e.g. embedded systems) where low overhead is needed. As the name suggests, this is not the original user space tooling for SquashFS. Here are some of the features that primarily distinguish this package from the original: - reproducible SquashFS images, i.e. deterministic packing without any local time stamps, - Linux `gen_init_cpio` like file listing for micro managing the file system contents, permissions, and ownership without having to replicate the file system (and especially permissions) locally, - support for SELinux contexts file (see selabel_file(5)) to generate SELinux labels.
Bug#904216: ITP: fuse3 -- Filesystem in Userspace (3.x version)
Package: wnpp Severity: wishlist Owner: Laszlo Boszormenyi (GCS) * Package name: fuse3 Version : 3.2.4 Upstream Author : Nikolaus Rath * URL : https://github.com/libfuse/libfuse/wiki * License : GPL-2, LGPL-2.1 Programming Lang: C Description : Filesystem in Userspace (3.x version) Filesystem in Userspace (FUSE) is a simple interface for userspace programs to export a virtual filesystem to the Linux kernel. It also aims to provide a secure method for non privileged users to create and mount their own filesystem implementations.
Bug#863782: ITA: google-perftools -- libraries for CPU and heap analysis, plus an efficient thread-caching malloc' from 'O: google-perftools -- libraries for CPU and heap analysis, plus an efficient t
Control: owner -1 ! I'll take care of this package.
Bug#884130: Botan2 update?
Hi Adam, On Thu, Feb 8, 2018 at 10:13 AM, Adam Majer <ad...@zombino.com> wrote: > Thank you for your interest to package Botan2 in Debian. Is there an update > on this? QtCreator needs this library packaged sooner rather than later. It's already packaged[1] and uploaded. Every new package (source or binary) needs FTP Master approval first. It needs their time, I don't know when it will happen. Hopefully soon, I'm waiting for a month already. Regards, Laszlo/GCS [1] https://ftp-master.debian.org/new/botan_2.4.0-1.html
Bug#884130: ITP: botan -- multiplatform crypto library (2.x version)
Package: wnpp Severity: wishlist Owner: Laszlo Boszormenyi (GCS) <g...@debian.org> * Package name: botan Version : 2.3.0 Upstream Author : The Botan Authors * URL : https://botan.randombit.net/ * License : BSD-2-clause Programming Lang: C++ Description : multiplatform crypto library (2.x version) Botan is a C++ library which provides support for many common cryptographic operations, including encryption, authentication, and X.509v3 certificates and CRLs. A wide variety of algorithms is supported, including RSA, DSA, DES, AES, MD5, and SHA-1.
Bug#880740: ITP: icu-le-hb -- ICU Layout Engine API on top of HarfBuzz shaping library
Package: wnpp Severity: wishlist * Package name: icu-le-hb Version : 1.0.3 Upstream Author : Google Inc. * URL : https://github.com/behdad/icu-le-hb * License : MIT Programming Lang: C++ Description : ICU Layout Engine API on top of HarfBuzz shaping library A library implementing the ICU Layout Engine (icu-le) API using external HarfBuzz library for implementation. This is useful as a compatibility layer to make applications using ICU Layout Engine to use HarfBuzz without porting them to use the HarfBuzz API.
Bug#255572: ITP: cc65 -- Cross development suite for 65xxx processors, necesary for nesicide env
On Fri, Oct 6, 2017 at 10:26 PM, Michael Stapelberg <stapelb...@debian.org> wrote: > Thanks for sharing! The Debian package builds fine. However, when > trying to use cc65 to compile a project of mine, compilation fails > with “include/general.h(4): Error: Include file `peekpoke.h' not > found”. Please fetch and build again. Should be fixed. Laszlo/GCS
Bug#255572: ITP: cc65 -- Cross development suite for 65xxx processors, necesary for nesicide env
On Fri, Oct 6, 2017 at 11:00 AM, Michael Stapelberg <stapelb...@debian.org> wrote: > Great! Thanks for letting us know, please keep us posted on the progress. OK, you can download[1] and build the package for testing. Regards, Laszlo/GCS [1] dget -x http://www.barcikacomp.hu/gcs/cc65_2.16-1.dsc
Bug#255572: ITP: cc65 -- Cross development suite for 65xxx processors, necesary for nesicide env
On Fri, Oct 6, 2017 at 7:39 AM, Michael Stapelberg <stapelb...@debian.org> wrote: > László, did you see my message? Any word on this? I’m still interested :) Yup, sorry for the slow reaction. > On Thu, Nov 3, 2016 at 9:06 AM, Michael Stapelberg > <stapelb...@debian.org> wrote: >> "László Böszörményi (GCS)" <g...@debian.org> writes: >>> [1] https://ftp-master.debian.org/new/cc65_0~20160105-1.html >> >> Thanks for your upload. Can you tell us what happened with it? I think it was rejected, but don't see its reason. :( I should have the (old) package on my HDD, will refresh it and check the updated license of cc65. Then I plan to do the upload this weekend. Cheers, Laszlo/GCS
Bug#863946: ITA: snappy -- fast compression/decompression library
retitle 863946 ITA: snappy -- fast compression/decompression library owner 863946 ! thanks I would like to maintain it as my package, leveldb build depends on it.
Bug#729207: ITA: qpid-python -- Python bindings for qpid/mlib
retitle 729207 ITA: qpid-python -- Python bindings for qpid/mlib owner 729207 ! thanks As maintainer of other Qpid packages, I would like to update the whole stack and keep that up-to-date.
Bug#854122: ITP: selectors34 -- backport of the selectors module from Python 3.4
Package: wnpp Severity: wishlist Owner: Laszlo Boszormenyi (GCS) <g...@debian.org> * Package name: selectors34 Version : 1.1.0 Upstream Author : Berker Peksag <berker.pek...@gmail.com> * URL : https://github.com/berkerpeksag/selectors34 * License : PSFL-2 Programming Lang: Python Description : backport of the selectors module from Python 3.4 This module allows high-level and efficient I/O multiplexing, built upon the `select` module primitives.
Bug#842942: ITA: python-leveldb -- Python wrapper for LevelDB
retitle 842942 ITA: python-leveldb -- Python wrapper for LevelDB owner 842942 ! thanks As one of the LevelDB maintainers, I would like to keep this package updated for Stretch.
Bug#849917: ITA: ivykis -- Asynchronous I/O readiness notification library
retitle 849917 ITA: ivykis -- Asynchronous I/O readiness notification library
owner 849917 !
thanks
I would like to maintain it, as my packages syslog-ng{,-incubator}
depends on this.
Bug#848537: angular-route packaging
On Fri, Dec 30, 2016 at 1:48 PM, Daniel Pocock <dan...@pocock.pro> wrote: > On 30/12/16 13:30, László Böszörményi (GCS) wrote: >> Anything wrong with AngularJS packaging[1]? As angular-route is part >> of it, it's already packaged, see the file list[2] for >> angular-route.js . > I was looking through the dependencies for homer-ui and I had the > impression that this was a standalone dependency. > > I just had a look at the source tree[1] again and I couldn't see where > it is referred to so maybe this RFP can be closed. You might just mixed up two different projects. After my checking, it seems you wanted to RFP the UI-Router[1] project as that's shipped under lib/angular-third [2] - even if a two years old one. Using old JavaScript libraries seem to be common in that project. Like AngularJS version 1.4.8 [3] while the latest is the 1.6.1 [4] version. I've doubts that Homer-UI will work correctly with the recent releases. Regards, Laszlo/GCS [1] https://ui-router.github.io/ [2] https://github.com/sipcapture/homer-ui/tree/master/lib/angular-third [3] https://github.com/sipcapture/homer-ui/tree/master/lib/angular [4] https://github.com/angular/angular.js/releases
Bug#848537: angular-route packaging
Hi Daniel, Anything wrong with AngularJS packaging[1]? As angular-route is part of it, it's already packaged, see the file list[2] for angular-route.js . Cheers, Laszlo/GCS [1] https://packages.qa.debian.org/a/angular.js.html [2] https://packages.debian.org/sid/all/libjs-angularjs/filelist
Bug#840110: ITA: jfsutils -- utilities for managing the JFS filesystem
retitle 840110 ITA: jfsutils -- utilities for managing the JFS filesystem owner 840110 ! thanks I still have JFS filesystems around and would like to keep it maintained in Stretch.
Bug#831684: ITP: nsntrace -- perform network trace of a single process
retitle 831684 ITP: nsntrace -- perform network trace of a single process owner 831684 ! thanks Package is ready, uploading soon.
Bug#745615: dcraw maintenance
Hi Filip, On Wed, Jun 8, 2016 at 3:42 PM, Filip Hroch <hr...@physics.muni.cz> wrote: > thank you for your worry about dcraw. I've prepared > dcraw update (Jasper is removed from dependencies, > upstream version is updated, CI suite is included, > autotools improved,..) some time ago. Sounds good! > Unfortunately, > it is out of my capabilities to push the changes to > > collab-maint/dcraw.git > > on Alioth, because I am not a member of collab-maint > yet. I issued of membership request a week ago > via web form on Alioth (confirmed by Mr.Streicher). > Now, I'm waiting for acceptation. > > If the request will not be accepted in a near future, > Plan B is prepared: Mr.Fros will update dcraw repository > by Mike's patch (solving the Jasper stigma). Plan C: you push your Git tree to a public place where I can review it; then I merge your changes to collab-maint and sponsor the upload. What do you think? Regards, Laszlo/GCS
Bug#745615: dcraw maintenance
Hi, I do _not_ want to step on anyone's toe, but how dcraw packaging goes? There's a new upstream release for three weeks, probably fixing the open vulnerability, CVE-2015-8366. Also it prevents removing Jasper which transitively causing other package removals. As it's a small package, updating it is easy and shouldn't take more than a hour or so. May you do it Filip or should I take it instead? Thanks in advance, Laszlo/GCS
Bug#823548: linux-user-chroot deprecation
Control: owner -1 ! On Mon, May 9, 2016 at 7:10 PM, Simon McVittie <s...@debian.org> wrote: > On Mon, 09 May 2016 at 19:01:15 +0200, László Böszörményi (GCS) wrote: >> I plan to package bubblewrap, then ask for removal of linux-user-chroot. OK, packaged and going to upload it soon. > May I co-maintain, preferably in collab-maint git? xdg-app (now called > Flatpak, apparently) is going to depend on it soon; for now it's a git > submodule, but when a system copy is supported I suspect I'll need to keep > it somewhat in sync with xdg-app. Do you think it will be tightly coupled? We may co-maintain the packages vica-versa, will talk about it. Regards, Laszlo/GCS
Bug#823548: linux-user-chroot deprecation
On Mon, May 9, 2016 at 6:47 PM, Simon McVittie <s...@debian.org> wrote: > [added linux-user-chroot maintainer/subscribers to Cc, quoting full text > for their benefit] > > On Mon, 09 May 2016 at 09:13:42 -0400, Colin Walters wrote: >> l-u-c post: >> https://mail.gnome.org/archives/ostree-list/2016-May/msg0.html >> >> FWIW if any transition scripts are written I'd be happy to have them in >> l-u-c upstream. >> I'm as yet unsure whether it's worth doing so, or pushing for dependent >> consumers >> to do a hard port. I'm doing the latter with my l-u-c consumers >> (gnome-continuous, my >> bashrc). >> >> Are there any l-u-c dependencies in the Debian archive? > > There don't seem to be any reverse-dependencies, so perhaps linux-user-chroot > should just disappear. I second this, there's no reverse dependencies. I plan to package bubblewrap, then ask for removal of linux-user-chroot. After that, bubblewrap can provide a transitional package - I need to see what version numbering bubblewrap will use. Thanks for the heads-up, Laszlo/GCS
Bug#819986: ITP: resolv-wrapper -- A wrapper for DNS name resolving or DNS faking
retitle 819986 ITP: resolv-wrapper -- A wrapper for DNS name resolving or DNS faking owner 819986 ! thanks Package is ready, uploading soon.
Bug#819891: ITP: C3.js -- D3-based reusable chart library
Package: wnpp Severity: wishlist Owner: Laszlo Boszormenyi (GCS) <g...@debian.org> * Package name: libjs-c3 Version : 0.4.10 Upstream Author : Masayuki Tanaka <masayuki0...@mac.com> * URL : https://github.com/masayuki0812/c3 * License : Expat Programming Lang: JavaScript Description : D3-based reusable chart library C3 is a D3-based reusable chart library that enables deeper integration of charts into web applications.
Bug#811155: ITP: paxctld -- Daemon to automatically set appropriate PaX flags
Package: wnpp Severity: wishlist * Package name: paxctld Version : 1.0 Upstream Author : Brad Spengler * URL : http://grsecurity.net/ * License : GPL-2 Programming Lang: C Description : Daemon to automatically set appropriate PaX flags paxctld automatically sets appropriate PaX flags on binaries on the system using user extended attributes. The flags are maintained across any updates made to the binaries listed in the paxctld configuration file.
Bug#255572: ITP: cc65 -- Cross development suite for 65xxx processors, necesary for nesicide env
Control: owner -1 ! On Sat, Jan 16, 2016 at 3:19 PM, PICCORO McKAY Lenz <mckaygerh...@gmail.com> wrote: > hey i refer that i firts search here: > https://www.debian.org/devel/wnpp/prospective > and due the bug related are linked so i take it! > > and of course, get back the owership! the itp progress are avanced and > there's no sense of my firts intentions, now i must collaborate in the > common work OK, going to upload it in minutes. Laszlo/GCS
Bug#255572: ITP: cc65 -- Cross development suite for 65xxx processors, necesary for nesicide env
On Sun, Jan 17, 2016 at 2:37 AM, PICCORO McKAY Lenz <mckaygerh...@gmail.com> wrote: > upload the made of only two or one that provided one package for each > cc compiler? I'm not sure I always read your English right. But if you mean how the packages are split, then I don't think it worths to create separate packages for every compiler. The binary is one and half megabytes this way. The debug symbols use the link-doc feature. Laszlo/GCS [1] https://ftp-master.debian.org/new/cc65_0~20160105-1.html
Bug#255572: ITP: cc65 -- Cross development suite for 65xxx processors, necesary for nesicide env
Hi, On Fri, Jan 15, 2016 at 12:18 AM, PICCORO McKAY Lenz <mckaygerh...@gmail.com> wrote: > retitle 255572 ITP: cc65 -- Cross development suite for 65xxx processors > owner 255572 ! I would have appreciate a ping mail at least before you just take over this ITP without asking. Do you have experience with Debian packaging? Regards, Laszlo/GCS
Bug#255572: ITP: cc65 -- Cross development suite for 65xxx processors, necesary for nesicide env
On Fri, Jan 15, 2016 at 1:29 AM, PICCORO McKAY Lenz <mckaygerh...@gmail.com> wrote: > sorry but the merged #714058 issue are not reflected in the > https://www.debian.org/devel/wnpp/prospective page, only the itp and > the original issue are not active inmany times... Yes, I've a long queue and in the process of shrinking it. > are u see the other mail? I got email only of your takeover and this one. Which one do you refer? Laszlo/GCS
Bug#801184: ITA: git-flow -- Git extension to provide a high-level branching model
retitle 801184 RFA: git-flow -- Git extension to provide a high-level branching model owner 801184 ! thanks I've good connection with the previous maintainer. I'm going to use this package heavily. Thanks for all the fish Gergely!
Bug#801184: ITA: git-flow -- Git extension to provide a high-level branching model
retitle 801184 ITA: git-flow -- Git extension to provide a high-level branching model owner 801184 ! thanks I should sleep more... Still would like to adopt this package this time with a correct ITA mail.
Bug#776850: still interested?
Hi Edwin, On Thu, Oct 22, 2015 at 3:19 PM, Török Edwin <ed...@skylable.com> wrote: > Laszlo, are you still interested in being the maintainer of this package? Sure, I'm. I was a tester of an other cryptography software behind the curtains in the past one (+ a bit more) months. It's Crypto++ [1] and blame me for v5.6.3 is still not released. Found some problems (just to name a few[2][3) which needed fixing. Still, I've the SX package ready[4] but I think I've found bugs in your software as well. Going to contact you in private for further information on these. Cheers, Laszlo/GCS [1] http://cryptopp.com/ [2] https://github.com/weidai11/cryptopp/issues/31 [3] https://github.com/weidai11/cryptopp/issues/47 [4] dget -x http://www.barcikacomp.hu/gcs/sx_1.2-1.dsc
Bug#801707: ITA: shadow -- system login tools
retitle 801707 ITA: shadow -- system login tools owner 801707 ! thanks Hi Christian, What's up with the team behind the maintenance of shadow? Does it still exists / active? I would like to adopt it, but under control for the first some months if you don't mind. First I'd like to package the new upstream release and do some cleanup. Does it sound right with you, do you accept me as the future maintainer? I'm a Security Team trainee and have some cryptographic background, but this package is vital to the system. Regards, Laszlo/GCS
Bug#800750: ITA: fetchmail -- SSL enabled POP3, APOP, IMAP mail gatherer/forwarder
retitle 800750 ITA: fetchmail -- SSL enabled POP3, APOP, IMAP mail gatherer/forwarder owner 800750 ! thanks I'm going to take it. So long, and thanks for all the fish Nico!
Bug#798695: libbson packaging
Hi Jesse, Thanks for bringing this up. I'm the maintainer of MongoDB in Debian. Always wanted to package libbson and other libraries / utilities around it. Now took my time and it's about 90% ready. I need to remove the yayl library from the source tree and build with the system provided one. My question is, do you want to do it alone or either let me do it or do it together? Regards, Laszlo/GCS
Bug#797688: ITA: seccure -- tools for using algorithms based on elliptic curve cryptography (ECC)
On Wed, Sep 2, 2015 at 9:53 AM, Tomasz Buchert <tom...@debian.org> wrote: > On 02/09/15 09:38, László Böszörményi (GCS) wrote: >> I'll take it. So long, and thanks for all the fish James! > > first! :) But seriously, what about comaintaining it? > I also ITA'ed , would you like to comantain it too? Hmmm, none of them seem to be a big package nor actively maintained by upstream. If you really need a co-maintainer, then I'm fine with it. Cheers, Laszlo/GCS
Bug#797737: ITP: python-cram -- simple testing framework for command line applications
retitle 797737 ITP: python-cram -- simple testing framework for command line applications owner 797737 ! thanks I also need this, going to package it.
Bug#797688: ITA: seccure -- tools for using algorithms based on elliptic curve cryptography (ECC)
retitle 797688 ITA: seccure -- tools for using algorithms based on elliptic curve cryptography (ECC) owner 797688 ! thanks I'll take it. So long, and thanks for all the fish James!
Bug#793491: ITP: rocksdb -- A persistent key-value store for fast storage environments
retitle 793491 ITP: rocksdb -- A persistent key-value store for fast storage environments owner 793491 ! thanks The package is ready, quick local testing shows it's working. But its self test fails: [ RUN ] ColumnFamilyTest.ReadDroppedColumnFamily db/column_family_test.cc:1101: Failure Value of: kKeysNum * ((i == 2) ? 1 : 2) Actual: 1 Expected: count Which is: 9231 terminate called after throwing an instance of 'testing::internal::GoogleTestFailureException' what(): db/column_family_test.cc:1101: Failure Value of: kKeysNum * ((i == 2) ? 1 : 2) Actual: 1 Expected: count Which is: 9231 Aborted -- 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/1437904071.7082.2.ca...@debian.org
Bug#792097: ITP: thrift -- software framework, for scalable cross-language services development
Package: wnpp Severity: wishlist * Package name: thrift Version : 0.9.2 Upstream Author : The Apache Software Foundation * URL : https://thrift.apache.org/ * License : Apache-2.0 Programming Lang: C++, Java, Python, PHP and others Description : software framework, for scalable cross-language services development The Apache Thrift software framework, for scalable cross-language services development, combines a software stack with a code generation engine to build services that work efficiently and seamlessly between C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, OCaml and Delphi and other languages. Thrift is already in the archive, but in a sliced, separate packages version. I'm in the process to use the vanilla upstream source and build everything from it. This is just a tracking / heads-up ITP. -- 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/1436606943.18984.9.ca...@debian.org
Bug#788644: ITP: libjs-riot -- UI library with custom tags and virtual DOM
retitle 788644 ITP: libjs-riot -- UI library with custom tags and virtual DOM owner 788644 ! thanks This looks interesting and much easier to learn than React itself or AngularJS. Can be a help of users for small projects. -- 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/cakjshr1cs_gpcyj3kkr48nwahln0hyst80xtmw_4tp3b8rq...@mail.gmail.com
Bug#770374: ITA: socket-wrapper -- socket wrapper library
Control: retitle -1 ITA: socket-wrapper -- socket wrapper library Control: owner -1 ! After some discussion with Jakub, I take over this package. Thanks for all the fish! -- 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/1433479763.11638.67.ca...@debian.org
Bug#787237: ITA: cxxtest -- lightweight xUnit-like framework for C/C++ applications
Control: retitle -1 ITA: cxxtest -- lightweight xUnit-like framework for C/C++ applications Control: owner -1 ! As discussed with Simone in a private email, I'm intend to continue with cxxtest maintenance. -- 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/cakjshr27r+psvkpqu3_dpgpboz+chsbldcg-o_zc807dmdv...@mail.gmail.com
Bug#786375: about gRPC packaging
Hi Andrew, On Thu, May 21, 2015 at 1:20 PM, Andrew Pollock apoll...@debian.org wrote: I don't mind you joining in. I'm doing the work on Github, as I'm trying to help the gRPC guys maintain it themselves to some degree (I work for Google). OK, good plan. I assume you don't work at the same place where gRPC is being developed. It means the packaging will be refreshed in their tree from time to time, right? https://github.com/grpc/grpc/pull/1696 is what I've done so far. If you can help get protobuf3 into experimental, I can flesh the package out more there. As I see, it was merged. As such, I add my changes over yours. In my next pull request, I can add you as an Uploader. Thanks. How to go on from now? May I get commit access to your tree or just send pull requests? Just done the latter. Cheers, Laszlo/GCS -- 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/cakjshr25dfc+dhklpwbsv6oxduuxa_4ytd4fen8uefrx7ab...@mail.gmail.com
Bug#786769: ITP: libodb-mysql -- ODB Runtime Library for MySQL
Package: wnpp Severity: wishlist * Package name: libodb-mysql Version : 2.4.0 Upstream Author : Code Synthesis * URL : http://www.codesynthesis.com/products/odb/ * License : GPL-2 Programming Lang: C++ Description : ODB Runtime Library for MySQL ODB is an object-relational mapping (ORM) system for C++. It provides tools, APIs, and library support that allow you to persist C++ objects to a relational database (RDBMS) without having to deal with tables, columns, or SQL and without manually writing any of the mapping code. This package contains the MySQL ODB runtime library. Every application that includes code generated for the MySQL database will need to link to this library. -- 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/1432555204.22854.5.ca...@debian.org
Bug#786770: ITP: libodb-pgsql -- ODB Runtime Library for PostgreSQL
Package: wnpp Severity: wishlist * Package name: libodb-pgsql Version : 2.4.0 Upstream Author : Code Synthesis * URL : http://www.codesynthesis.com/products/odb/ * License : GPL-2 Programming Lang: C++ Description : ODB Runtime Library for PostgreSQL ODB is an object-relational mapping (ORM) system for C++. It provides tools, APIs, and library support that allow you to persist C++ objects to a relational database (RDBMS) without having to deal with tables, columns, or SQL and without manually writing any of the mapping code. This package contains the PostgreSQL ODB runtime library. Every application that includes code generated for the PostgreSQL database will need to link to this library. -- 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/1432555213.22854.6.ca...@debian.org
Bug#786820: ITP: libodb-boost -- Boost ODB runtime library
Package: wnpp Severity: wishlist Owner: Laszlo Boszormenyi (GCS) g...@debian.org * Package name: libodb-boost Version : 2.4.0 Upstream Author : Code Synthesis * URL : http://www.codesynthesis.com/products/odb/ * License : GPL-2 Programming Lang: C++ Description : ODB Runtime Library for PostgreSQL ODB is an object-relational mapping (ORM) system for C++. It provides tools, APIs, and library support that allow you to persist C++ objects to a relational database (RDBMS) without having to deal with tables, columns, or SQL and without manually writing any of the mapping code. This package contains the Boost ODB profile library. The Boost profile provides support for persisting Boost smart pointers, containers, and value types with the ODB system. -- 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/1432584871.22854.13.ca...@debian.org
Bug#786821: ITP: libodb-qt -- Qt ODB runtime library
Package: wnpp Severity: wishlist Owner: Laszlo Boszormenyi (GCS) g...@debian.org * Package name: libodb-qt Version : 2.4.0 Upstream Author : Code Synthesis * URL : http://www.codesynthesis.com/products/odb/ * License : GPL-2 Programming Lang: C++ Description : ODB Runtime Library for PostgreSQL ODB is an object-relational mapping (ORM) system for C++. It provides tools, APIs, and library support that allow you to persist C++ objects to a relational database (RDBMS) without having to deal with tables, columns, or SQL and without manually writing any of the mapping code. This package contains the Qt profile library. The Qt profile provides support for persisting Qt smart pointers, containers, and value types with the ODB system. -- 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/1432584894.22854.14.ca...@debian.org
Bug#786696: ITP: libodb -- Common ODB Runtime Library
Package: wnpp Severity: wishlist * Package name: libodb Version : 2.4.0 Upstream Author : Code Synthesis * URL : http://www.codesynthesis.com/products/odb/ * License : GPL-2 Programming Lang: C++ Description : Common ODB Runtime Library ODB is an object-relational mapping (ORM) system for C++. It provides tools, APIs, and library support that allow you to persist C++ object to a relational database (RDBMS) without having to deal with tables, columns, or SQL and without manually writing any of the mapping code. This package contains the common ODB runtime library. Every application that includes code generated by the ODB compiler will need to link to this library. -- 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/1432475490.7008.13.ca...@debian.org
Bug#786697: ITP: libodb-sqlite -- ODB Runtime Library for SQLite
Package: wnpp Severity: wishlist * Package name: libodb-sqlite Version : 2.4.0 Upstream Author : Code Synthesis * URL : http://www.codesynthesis.com/products/odb/ * License : GPL-2 Programming Lang: C++ Description : ODB Runtime Library for SQLite ODB is an object-relational mapping (ORM) system for C++. It provides tools, APIs, and library support that allow you to persist C++ objects to a relational database (RDBMS) without having to deal with tables, columns, or SQL and without manually writing any of the mapping code. This package contains the SQLite ODB runtime library. Every application that includes code generated for the SQLite database will need to link to this library. -- 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/1432475504.7008.14.ca...@debian.org
Bug#786375: about gRPC packaging
Hi Andrew, I already have packages (for 0.5.0), I was just slow to send the ITP. May I still join? But of course, I trust you if you would like to do it alone. Regards, Laszlo/GCS -- 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/CAKjSHr3okOH4irCjHeoqc3=Kk_-=ccsmdh60f_yuqzum0ty...@mail.gmail.com
Bug#714058: Draft for debian/copyright file
On Mon, May 11, 2015 at 12:54 AM, John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de wrote: According to John, his active years were 1990-1993, thus: Files: * Copyright: 1990-1993 John R Dunning j...@jrd.org and contributors 1998-2015 Ullrich von Bassewitz u...@musoftware.de and contributors 2004-2015 Oliver Schmidt ol...@web.de and contributors License: Zlib Natural question. What's happened between 1993 and 1998? There was at least one more German(?) developer[1], Bastian Schick as I see. Cheers, Laszlo/GCS [1] https://github.com/cc65/cc65/blob/master/libsrc/lynx/eeprom86.s#L16 -- 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/cakjshr2ib4ykdzoqsqnw07phh9krqfvbcuky9+tx_ku9_wm...@mail.gmail.com
Bug#714058: Draft for debian/copyright file
On Sun, May 10, 2015 at 1:56 PM, John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de wrote: Just a quick follow up. I talked to Ullrich and for him the correct years would be 1998-2013. I have also sent a message to John with the same question now. I think Ullrich has copyright to date. Please see target.c [1]. Oliver, what range for the years would be valid for you? For me it seems he started contributing on 2004, 8th of March[2]. Cheers, Laszlo/GCS [1] https://github.com/cc65/cc65/blob/master/src/common/target.c#L9 [2] https://github.com/cc65/cc65/blob/master/libsrc/apple2/dosdetect.s#L2 -- 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/cakjshr1ss9bbnacjckeuu17kdtduqcctne4ovvdxzm4yveb...@mail.gmail.com
Bug#714058: cc65 packaging
Hi, On Tue, May 5, 2015 at 1:26 PM, Oliver Schmidt ol...@web.de wrote: The man pages could be generated with help2man, or they could point to the GNU info files. It seems that linuxdoc -B txt --man ... groff -man ... might be another option. Will check this once I get home. On the other hand, Oliver promised me to add something like a consecutive number if I really need it for packaging purposes. I can confirm this. Please do it then to confirm which commit should be considered a stable release. If possible update the file LICENSE as well to be zlib and GPL-2 as you previously noted. Thanks, Laszlo/GCS -- 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/cakjshr22fsnzs4dhgqsrqsf0c4nhowa_vmo59pdx7f0muyq...@mail.gmail.com
Bug#714058: cc65 packaging
Hi Oliver, On Tue, May 5, 2015 at 2:17 PM, Oliver Schmidt ol...@web.de wrote: Iff everything else is settled regarding packaging (incl. licensing) I'll reach out to the list members and ask for last-minute contribtions. If that phase is over I'll add a tag to the Git repo. OK, sounds good. If possible update the file LICENSE as well to be zlib and GPL-2 as you previously noted. There must be a misunderstanding! I made a statement about _my_ contributions to cc65. I don't know who else has contributed to cc65 before I started to maintain the upstream repo. In fact I personally don't see how an exhaustive list of contributors can be archived. And without acknowledgement from _all_ contributors I don't see me changing _anything_ regarding the file LICENSE. Then the first step is to ask everyone you (we?) know to allow the relicensing of the whole cc65. This means all contributors of the code who ever changed something in it, even a single character. Do others like John R. Dunning or Ullrich von Bassewitz may have a full commit history and/or list of the contributors over the years? I'm _not_ a lawyer, but do we really need to reach everyone? Would it be enough to ask only people who added their copyright messages in the top of the files? I don't know if others can be counted as they left the copyright to the actual source maintainer or not. At least I don't see any sign that they claim any copyright of their contributions. The LICENSE file states only the previous two coders have the copyright. Not a single sentence mentions others who may have contributed to the source. Until this license issue is not solved, cc65 remains non-free from the Debian point of view. :( Regards, Laszlo/GCS -- 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/CAKjSHr28vXC=gtfxaptv6tiuhezq6uzkwtmt1srsga83bai...@mail.gmail.com
Bug#714058: cc65 packaging
On Tue, May 5, 2015 at 3:27 PM, John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de wrote: On 05/05/2015 03:08 PM, László Böszörményi (GCS) wrote: Then the first step is to ask everyone you (we?) know to allow the relicensing of the whole cc65. This means all contributors of the code who ever changed something in it, even a single character. Do others like John R. Dunning or Ullrich von Bassewitz may have a full commit history and/or list of the contributors over the years? You can get a list: $ git clone g...@github.com:cc65/cc65.git $ cd cc65 $ git log --all --format='%aN %cE' | sort -u This is not authoritative. For example someone could sent an email to Ullrich with his/her patch. As it was not commited by the contributor but Ullrich, the person's identity is lost. But well, the commit log can be a good starting point. May you Oliver handle this? Regards, Laszlo/GCS -- 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/CAKjSHr1zmFpXc=XM0NEGjSkMugQJDiM=ja8wclh8cnintw9...@mail.gmail.com
Bug#714058: cc65 packaging
Hi Spiro, On Mon, May 4, 2015 at 8:45 PM, Spiro Trikaliotis ml-cc65-git...@spiro.trikaliotis.net wrote: * On Mon, May 04, 2015 at 06:35:11PM +0200 László Böszörményi (GCS) wrote: To be honest, I've already packaged it. Me too. ;) Took a quick check with a browser into your packaging. It's old style, but looks promising. Me too. If you want to package it yourself, it's ok for me. If you want us to work together, it's ok, too. From my point of view, our cooperation in the past for VICE has worked good. Yup, I consider you a friend of mine. We can work together on this package and you or others may check my version[1] until the license issue is settled. Cheers, Laszlo/GCS [1] dget -x http://www.barcikacomp.hu/gcs/cc65_0~20150503-1.dsc -- 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/cakjshr3jj8y2osfogsedrkg1g4w+rorb4ggwzdlrkd7xmcb...@mail.gmail.com
Bug#714058: cc65 packaging
On Tue, May 5, 2015 at 9:06 PM, John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de wrote: On 05/05/2015 08:18 PM, László Böszörményi (GCS) wrote: Yup, I consider you a friend of mine. We can work together on this package and you or others may check my version[1] until the license issue is settled. Ah, that's great. I'll have a look right away :). Feel free to report any issue you may found. What I know is that I should credit John R. Dunning as well in the copyright. Then ask Spiro which email address of his should be used in the package. Thanks, Laszlo/GCS -- 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/cakjshr0m60zxvlaqpj4hyzjwmzm4jaouxyby_i-vjv_hca0...@mail.gmail.com
Bug#714058: cc65 packaging
Hi all related people, To be honest, I've already packaged it. I've two problems above the license issue. None of the tools have neither a manpage nor a HTML documentation. Then there's no tag or any version number in the GitHub repository. Anyway, I'd like to have it in Debian as I already have several Commodore (64) related tools in the archive. These include VICE, sidplayfp and crasm. Regards, Laszlo/GCS -- 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/CAKjSHr0bBmSCDVb_Q_rUHx=YvtR1iidt=-zuue4-fwhy5ww...@mail.gmail.com
Bug#597899: ITP: yii-framework -- High-performance component-based PHP framework
On Tue, Apr 28, 2015 at 10:03 AM, Dmitry Smirnov only...@debian.org wrote: On Tue, 28 Apr 2015 09:43:44 László Böszörményi wrote: First of all, do you intend to visit DebConf this year? No... I'd like to visit DebConf one day but probably not this year... Arrgh, too bad. You have a big jug of beer of your choice from me when we meet again. Would you like to (co-)maintain it? You tidied it, but didn't add yourself to the Uploaders field. Do you use it somewhere? I do not want to co-maintain it because I do not use it. I needed Yii to evaluate prospective software that I was considering to package. Which is that software, if its name is public? There are way too many PHP frameworks to take care. Like Kohana[1] that I had plans to use. Interesting. :) There is also CakePHP (which we already have) but don't you have a feeling that the whole PHP thing is an evolutionary dead-end? ;) Well, I've mixed feelings. Sure, PHP is not the most structured nor a modern computer language. Read about the glitches[1][2]. Then read about how many developers and sites use it for web pages; statistics reveal it has a 82% percent domination[3][4]. Facebook told to run on PHP, of course with their engine that was open sourced[5]. Then the original developers of PHP is refactoring the whole code base under PHPNG[6]. As such, it's a moving target and still has some potential. We will see that the upcoming languages like Rust[7] holds for us. Cheers, Laszlo/GCS [1] http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ [2] http://whydoesitsuck.com/why-does-php-suck/ [3] http://w3techs.com/technologies/overview/programming_language/all [4] http://news.netcraft.com/archives/2013/01/31/php-just-grows-grows.html [5] http://hhvm.com/ [6] https://wiki.php.net/phpng [7] http://www.rust-lang.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/ca+ppj6cn9c11zhvrwz_hrnceamyx90t-ghi84xjgquo_syb...@mail.gmail.com
Bug#597899: ITP: yii-framework -- High-performance component-based PHP framework
Hi Dmitry, First of all, do you intend to visit DebConf this year? On Tue, Apr 28, 2015 at 5:16 AM, Dmitry Smirnov only...@debian.org wrote: Thank you for your initial packaging of Yii. No problem, but as you saw, it was rusty as it was mostly done in 2012. I reckon we could benefit from organising our efforts around public repository. I took the liberty of making one [1] and I've added some minor improvements. I hope this will help us to move things forward. Would you like to (co-)maintain it? You tidied it, but didn't add yourself to the Uploaders field. Do you use it somewhere? There are way too many PHP frameworks to take care. Like Kohana[1] that I had plans to use. Cheers, Laszlo/GCS [1] http://kohanaframework.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/ca+ppj6c4ndhv2dgndoh8hn7ozfqckltw7hzfgyq_kf+nnvp...@mail.gmail.com
Bug#782470: ITP: wiredtiger -- high performance, scalable, NoSQL, extensible platform for data management
Package: wnpp Severity: wishlist Owner: Laszlo Boszormenyi (GCS) g...@debian.org * Package name: WiredTiger Version : 2.5.2 Upstream Author : MongoDB, Inc. * URL : http://www.wiredtiger.com/ * License : GPL-2+ Programming Lang: C, Java, Python Description : high performance, scalable, NoSQL, extensible platform for data management Supports row-oriented storage (where all columns of a row are stored together), column-oriented storage (where columns are stored in groups, allowing for more efficient access and storage of column subsets) and log-structured merge trees (LSM), for sustained throughput under random insert workloads. . Includes ACID transactions with standard isolation levels and durability at both checkpoint and fine-grained granularity. . Can be used as a simple key/value store, but also has a complete schema layer, including indices and projections. -- 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/1428861941.6739.10.ca...@debian.org
