Bug#1068868: ITP: python3-pyzmq -- Python bindings for 0MQ
On Fri, 12 Apr 2024 at 14:39, Cody Scott wrote: > > Package: wnpp > Severity: wishlist > Owner: Cody Scott > X-Debbugs-Cc: debian-de...@lists.debian.org, cody.sc...@giatec.ca > > * Package name: python3-pyzmq > Version : 25.1.2 > Upstream Contact: ZeroMQ > * URL : https://pyzmq.readthedocs.io/en/latest/ > * License : BSD > Programming Lang: Python > Description : Python bindings for 0MQ > > > This will be used by Python applications that use ZeroMQ. > > There doesn't appear to be any other Python bindings for ZeroMQ. > > I plan to maintain it and I'm looking for a sponsor. This is already in Debian: https://tracker.debian.org/pkg/pyzmq
Bug#1055987: ITP: virt-firmware -- Tools for manipulating edk2 (ovmf/qemu-efi) firmware images
On Sun, 17 Dec 2023, 17:45 dann frazier, wrote: > On Thu, Dec 07, 2023 at 08:58:23PM +0000, Luca Boccassi wrote: > > On Wed, 15 Nov 2023 05:54:23 -0700 dann frazier > > wrote: > > > Package: wnpp > > > Severity: wishlist > > > Owner: dann frazier > > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > > > * Package name: virt-firmware > > > Version : 23.10 > > > Upstream Contact: Gerd Hoffmann > > > * URL : https://gitlab.com/kraxel/virt-firmware > > > * License : GPL-2+ > > > Programming Lang: Python > > > Description : Tools for manipulating edk2 (ovmf/qemu-efi) > > firmware images > > > > > > This is a collection of tools for edk2 firmware images. They support > > > decoding and printing the content of firmware volumes. Variable > > stores > > > (e.g. OVMF_VARS.fd) can be modified, for example to enroll secure > > boot > > > certificates. Tools included: > > > > > > virt-fw-dump - Decodes and prints the content of firmware volumes. > > > > > > virt-fw-vars - Print and edit variable store volumes. Currently > > focused on > > > enrolling certificates and enabling secure boot. > > > > > > virt-fw-sigdb - Print and edit EFI signature database files. > > > > > > host-efi-vars - Read efi variables from linux efivarfs and > > decode/print them. > > > > > > kernel-bootcfg - Manage efi boot configuration for UKIs (unified > > kernel > > > images) when using direct boot (without boot loader > > like > > > grub or systemd-boot). > > > > > > pe-dumpinfo - Information dump for pe (the format used by EFI) > > binaries. > > > > > > pe-listsigs - List signatures and certificate chain for pe binaries. > > Can also > > >extract certificates & signatures. > > > > > > > > > My immediate motivation for packaging this is that, as the maintainer > > of > > > the edk2 package, I need to remove some deprecated image types - > > specifically > > > the OVMF 2M images. These utilities can help users migrate their VMs > > to > > > supported types by dumping/loading the variable stores. > > > > > > In the future, I expect edk2 packaging to evolve into using these > > tools > > > to modify images out-of-band, instead of launching QEMU instances to > > > modify them in-band as part of the build. > > > > > > > Hello Dann, > > > > I find myself in need of this package for some CI usage as well, are > > you planning to work on this soon? Do you need any help? > > Hi Luca, > > Apologies for the delayed response. I believe I have completed the > packaging and am prepared to upload: > > https://salsa.debian.org/dannf/virt-firmware > > Feel free to review and let me know if you have any feedback. > > -dann > Looks good to me, thanks. Ship it! >
Bug#1055987: ITP: virt-firmware -- Tools for manipulating edk2 (ovmf/qemu-efi) firmware images
On Wed, 15 Nov 2023 05:54:23 -0700 dann frazier wrote: > Package: wnpp > Severity: wishlist > Owner: dann frazier > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name : virt-firmware > Version : 23.10 > Upstream Contact: Gerd Hoffmann > * URL : https://gitlab.com/kraxel/virt-firmware > * License : GPL-2+ > Programming Lang: Python > Description : Tools for manipulating edk2 (ovmf/qemu-efi) firmware images > > This is a collection of tools for edk2 firmware images. They support > decoding and printing the content of firmware volumes. Variable stores > (e.g. OVMF_VARS.fd) can be modified, for example to enroll secure boot > certificates. Tools included: > > virt-fw-dump - Decodes and prints the content of firmware volumes. > > virt-fw-vars - Print and edit variable store volumes. Currently focused on > enrolling certificates and enabling secure boot. > > virt-fw-sigdb - Print and edit EFI signature database files. > > host-efi-vars - Read efi variables from linux efivarfs and decode/print them. > > kernel-bootcfg - Manage efi boot configuration for UKIs (unified kernel > images) when using direct boot (without boot loader like > grub or systemd-boot). > > pe-dumpinfo - Information dump for pe (the format used by EFI) binaries. > > pe-listsigs - List signatures and certificate chain for pe binaries. Can also > extract certificates & signatures. > > > My immediate motivation for packaging this is that, as the maintainer of > the edk2 package, I need to remove some deprecated image types - specifically > the OVMF 2M images. These utilities can help users migrate their VMs to > supported types by dumping/loading the variable stores. > > In the future, I expect edk2 packaging to evolve into using these tools > to modify images out-of-band, instead of launching QEMU instances to > modify them in-band as part of the build. > Hello Dann, I find myself in need of this package for some CI usage as well, are you planning to work on this soon? Do you need any help? Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1055424: ITP: python-sdbus -- modern Python D-Bus library
On Tue, 7 Nov 2023 at 11:48, Alexandre Detiste wrote: > > Would the long quest for the perfect python<->DBUS library be over ;-) > > This one looks nice. > > From the readme: > >i686, ppc64le and s390x can be supported if there is a demand. > >Please open an issue if you are interested in those platforms. > > Yes please I need i386, I guess it only applies to PyPi packaging. Yes that's about pypi, the debian package has been built for all linux architectures including i386.
Bug#1055424: ITP: python-sdbus -- modern Python D-Bus library
Package: wnpp Severity: wishlist Owner: Luca Boccassi X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-sdbus Version : 0.11.1 Upstream Author : various * URL : https://github.com/python-sdbus/python-sdbus * License : LGPL-2.1-or-later Programming Lang: python Description : python D-Bus library that aim to use the modern features of python. It is based on libsystemd's sd-bus. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1053818: ITP: pkcs11-provider -- OpenSSL 3 provider for PKCS11
Package: wnpp Severity: wishlist Owner: Luca Boccassi X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: pkcs11-provider Version : 0.2 Upstream Contact: Red Hat * URL : https://github.com/latchset/pkcs11-provider * License : Apache-2.0 Programming Lang: C Description : OpenSSL 3 provider for PKCS11 With this provider for OpenSSL you can use the OpenSSL library (version 3) and command line tools with any PKCS11 implementation as backend for the crypto operations. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1053185: ITP: python-varlink -- Python implementation of the Varlink protocol
Package: wnpp Severity: wishlist Owner: Luca Boccassi X-Debbugs-Cc: debian-de...@lists.debian.org * Package name : python-varlink Version : 31.0.0 Upstream Author : various * URL : https://github.com/varlink/python * License : Apache-2.0 Programming Lang: python Description: Python implementation of the Varlink protocol with client/server capabilities
Bug#1015880: ITP: xdp-tools -- Library and utilities for use with XDP
Package: wnpp Severity: wishlist Owner: Luca Boccassi X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: xdp-tools Version : 1.2.5 Upstream Author : various * URL : https://github.com/xdp-project/xdp-tools * License : BSD-2-Clause, GPL-2.0, LGPL-2.1 Programming Lang: C Description : library for working with the eXpress Data Path facility of the Linux kernel, and a collection of utilities and example code that uses the library. For more information about XDP, see: https://docs.kernel.org/networking/af_xdp.html -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1004491: ITP: tpm2-openssl -- OpenSSL 3 engine for tpm2-tss
On Sat, 29 Jan 2022 at 01:44, Adrian Bunk wrote: > > On Sat, Jan 29, 2022 at 01:32:44AM +, Luca Boccassi wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Luca Boccassi > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > * Package name: tpm2-openssl > > Version : 1.0.1 > > Upstream Author : Fraunhofer SIT, Intel, Wind River and others > >... > > You already packaged that last year: > https://tracker.debian.org/pkg/tpm2-tss-engine > > cu > Adrian Hi, I copy-pasted the wrong link, this is a different upstream (that was forked from the old one) for the openssl v3 APIs: https://github.com/tpm2-software/tpm2-openssl Kind regards, Luca Boccassi
Bug#1004491: ITP: tpm2-openssl -- OpenSSL 3 engine for tpm2-tss
Package: wnpp Severity: wishlist Owner: Luca Boccassi X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: tpm2-openssl Version : 1.0.1 Upstream Author : Fraunhofer SIT, Intel, Wind River and others * URL : https://github.com/tpm2-software/tpm2-tss-engine * License : BSD-3-clause Programming Lang: C Description : OpenSSL 3 engine for tpm2-tss Uses the tpm2-tss stack (maintainers CC'ed) to provide an OpenSSL 3.0 engine backend that uses the TPM2. Uses the new OpenSSL APIs and is not compatible with version 1.x.x. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1004357: ITP: package-notes -- Tools to add packaging metadata to ELF files
Package: wnpp Severity: wishlist Owner: "Luca Boccassi" X-Debbugs-CC: debian-de...@lists.debian.org * Package name: package-notes Version : 0.4 Upstream Author : various * URL : https://github.com/systemd/package-notes * License : CC0-1.0 * Programming Lang: Shell and Python * Description : Tools to add packaging metadata to ELF files Tools to generate a linker script to add package metadata to the ELF binaries being built. See: https://systemd.io/COREDUMP_PACKAGE_METADATA/ -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1001130: ITP: dasbus -- DBus library is written in Python 3, based on GLib and inspired by pydbus
Package: wnpp Severity: wishlist Owner: "Luca Boccassi" X-Debbugs-CC: debian-de...@lists.debian.org * Package name : dasbus Version : 1.6 Upstream Author : RedHat * URL : https://github.com/rhinstaller/dasbus * License : LGPL-2.1-or-later * Programming Lang: Python * Description : DBus library is written in Python 3, based on GLib and inspired by pydbus. dasbus provides a pythonic interface to the D-Bus message bus system. dasbus can be used to access remote objects and also for object publication. It is inspired by pydbus, and it's intended to replace it, since upstream development has stalled. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#993993: ITP: tpm2-tss-engine -- OpenSSL engine for tpm2-tss
Package: wnpp Severity: wishlist Owner: Luca Boccassi X-Debbugs-Cc: debian-de...@lists.debian.org, cypher...@ubuntu.com, paul...@debian.org, ivan...@ubuntu.com, supe...@gmail.com * Package name: tpm2-tss-engine Version : 1.1.0 Upstream Author : Fraunhofer SIT, Intel, Wind River and others * URL : https://github.com/tpm2-software/tpm2-tss-engine * License : BSD-3-clause Programming Lang: C Description : OpenSSL engine for tpm2-tss Uses the tpm2-tss stack (maintainers CC'ed) to provide an OpenSSL engine backend that uses the TPM2. Happy for group/team maintainership if the tpm2-tss maintainers are interested. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#892001: ITP: dbus-broker -- Linux D-Bus Message Broker
On Wed, 2021-01-13 at 15:31 +0100, Alex ARNAUD wrote: > Le 12/01/2021 à 16:50, Luca Boccassi a écrit : > > I understand the point of view, but given the release is 6+ months > > away, there's all the time in the world to have it tested. And if > > we > > find something that for whatever reason is completely broken in > > Debian > > but works completely fine in Fedora/Yocto/etc then we can simply > > remove > > it from testing. Nothing depends on it, so unless I'm missing > > something, there's no extra cost involved as far as I can see. > Indeed, it makes sense to me. Uploaded with urgency=low to unstable. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#892001: ITP: dbus-broker -- Linux D-Bus Message Broker
On Tue, 2021-01-12 at 16:23 +0100, Alex ARNAUD wrote: > Le 10/01/2021 à 21:05, Luca Boccassi a écrit : > > > What deadlines did you have in mind? Are you intending to offer this as a > > > "first-class citizen" option in bullseye? When dbus-broker has only been > > > in the archive for two days, that doesn't seem like very much testing > > > to have confidence that it will be suitable to provide important system > > > services through the 3 year lifetime of bullseye. > > > > I think it's fine as an optional package that users have to opt-in > > for. Nothing depends on it, so it won't be installed by default > > anywhere. Also there's no config to do to switch - install or > > uninstall. > > > > Also there's no difference to what Fedora shipped for a couple of > > years now - we got no patches, special build flags or anything. So > > it's good enough to be in bullseye in my view. > I'm not a Debian developer nor a Debian maintainer but I think I see what > Simon said. People trust us to provide working packages for which we had > enough testing. > > A possible compromise would be to have it landed to Sid/Unstable, blocking > testing migration, not shipping it for Debian 11, trying it in testing after > Debian 11 release then upload it to bullseye-backports after 3 months in > testing if the results are successful. Hi, I understand the point of view, but given the release is 6+ months away, there's all the time in the world to have it tested. And if we find something that for whatever reason is completely broken in Debian but works completely fine in Fedora/Yocto/etc then we can simply remove it from testing. Nothing depends on it, so unless I'm missing something, there's no extra cost involved as far as I can see. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#892001: ITP: dbus-broker -- Linux D-Bus Message Broker
On Sun, 10 Jan 2021 at 19:43, Simon McVittie wrote: > > On Fri, 08 Jan 2021 at 16:30:08 +, Luca Boccassi wrote: > > Gentle ping reg. > > https://salsa.debian.org/utopia-team/dbus/-/merge_requests/8 as > > deadlines are fast approaching - dbus-broker has cleared NEW, so I'd > > like to sort out the details regarding repository and team > > maintainership and make it available in unstable/testing. > > Reviewing, testing and uploading that is on my list, but it isn't a > short list and contains other things that are time-sensitive, so dbus > has had to wait. I had hoped to have a dbus 1.14.x stable-branch by now, > but at this point bullseye is going to be on 1.12.x. No problem at all, thanks for your work on dbus! > What deadlines did you have in mind? Are you intending to offer this as a > "first-class citizen" option in bullseye? When dbus-broker has only been > in the archive for two days, that doesn't seem like very much testing > to have confidence that it will be suitable to provide important system > services through the 3 year lifetime of bullseye. I think it's fine as an optional package that users have to opt-in for. Nothing depends on it, so it won't be installed by default anywhere. Also there's no config to do to switch - install or uninstall. Also there's no difference to what Fedora shipped for a couple of years now - we got no patches, special build flags or anything. So it's good enough to be in bullseye in my view. The only thing to sort out is maintainership - you mentioned you wished to have it in the team, and I'm perfectly fine with it - if that's still what you want to do, and you could please invite to the Salsa section, I can do the rest. Thanks! Kind regards, Luca Boccassi
Bug#892001: ITP: dbus-broker -- Linux D-Bus Message Broker
On Sat, 9 Jan 2021 at 06:21, Alex ARNAUD wrote: > > Le 08/01/2021 à 17:30, Luca Boccassi a écrit : > > Gentle ping reg. > https://salsa.debian.org/utopia-team/dbus/-/merge_requests/8 as > deadlines are fast approaching - dbus-broker has cleared NEW, so I'd > like to sort out the details regarding repository and team > maintainership and make it available in unstable/testing. As a recap, > I'm totally on board with having it as part of the same team area as > dbus and with the same maintainers/uploaders. > We don't need to sort out the package split immediately or even for > bullseye, as it's made to be co-installable out of the box. > > Thanks! > > Hello Luca and thanks again for working on this, > > I don't know if my request / question is too early in the process: do you > plan to wrote a wiki page explaining how to enable it and replace gdbus with > dbus-broker? > > I'm pretty sure in the Debian a11y team we'll have some early adopter able to > verify if everything works as Orca relies exclusively on dbus to work. > > Best regards and happy new year all. Hello and happy new year! There's actually no need for a wiki or a guide, I think - all you need to do is install the dbus-broker package. On reboot, you'll be using dbus-broker. If you remove the dbus-broker package and reboot again, you'll be back to dbus-daemon. Given it's in experimental now it should be pretty simple to test it out - I've been using it on my desktop from the repo since yesterday, everything seems fine, both system and user sessions. Please let me know if you find any issues. Kind regards, Luca Boccassi
Bug#892001: ITP: dbus-broker -- Linux D-Bus Message Broker
On Wed, 16 Dec 2020 at 17:36, Luca Boccassi wrote: > > On Wed, 2020-12-16 at 14:48 +0100, Daniele Nicolodi wrote: > > Hi Luca, > > > > On 13/12/2020 23:33, Luca Boccassi wrote: > > > Hi, > > > > > > I have updated the package and done several changes, and unless there > > > are objections I intend to upload to experimental/NEW in a couple of > > > days. I'll start by grabbing the ITP. Repository: > > > > > > https://salsa.debian.org/bluca/dbus-broker > > > > > > I've also done some work on src:dbus to split out config and tools, > > > like it's done in Fedora/RHEL and Yocto. MR on Salsa: > > > > > > https://salsa.debian.org/utopia-team/dbus/-/merge_requests/8 > > > > > > Thanks for starting the work on this! I'm of course very happy to work > > > together and be both uploaders if you'd like to work on this as well > > > going forward. Just let me know and I'll list you and add you to the > > > shared repository once it's created. > > > > Thank you for picking this up. I don't think I'll have much to > > contribute to the package in the future. Feel free to take full > > ownership of it. > > > > Just a note: the Vcs- fields in debian/control point to a repository in > > the debian team that not yet exist and the discussion on the dbus MR > > seems to suggest that the repository for the dbus-broker package should > > live in the utopia-team group anyway. > > > > Cheers, > > Dan > > Yeah was waiting for a conclusion before changing and uploading. > > Simon, would you like this in utopia-team then? If so, could you please > create a dbus-broker repo and give me push access? > > I'd like to upload to experimental before the end of the week, so that > it can go through NEW. Will not upload to unstable until we are all > happy, and possibly the dbus package split is agreed if not uploaded. > But the current status should be good enough for experimental. Hello Simon, Gentle ping reg. https://salsa.debian.org/utopia-team/dbus/-/merge_requests/8 as deadlines are fast approaching - dbus-broker has cleared NEW, so I'd like to sort out the details regarding repository and team maintainership and make it available in unstable/testing. As a recap, I'm totally on board with having it as part of the same team area as dbus and with the same maintainers/uploaders. We don't need to sort out the package split immediately or even for bullseye, as it's made to be co-installable out of the box. Thanks! Kind regards, Luca Boccassi
Bug#892001: ITP: dbus-broker -- Linux D-Bus Message Broker
On Wed, 2020-12-16 at 14:48 +0100, Daniele Nicolodi wrote: > Hi Luca, > > On 13/12/2020 23:33, Luca Boccassi wrote: > > Hi, > > > > I have updated the package and done several changes, and unless there > > are objections I intend to upload to experimental/NEW in a couple of > > days. I'll start by grabbing the ITP. Repository: > > > > https://salsa.debian.org/bluca/dbus-broker > > > > I've also done some work on src:dbus to split out config and tools, > > like it's done in Fedora/RHEL and Yocto. MR on Salsa: > > > > https://salsa.debian.org/utopia-team/dbus/-/merge_requests/8 > > > > Thanks for starting the work on this! I'm of course very happy to work > > together and be both uploaders if you'd like to work on this as well > > going forward. Just let me know and I'll list you and add you to the > > shared repository once it's created. > > Thank you for picking this up. I don't think I'll have much to > contribute to the package in the future. Feel free to take full > ownership of it. > > Just a note: the Vcs- fields in debian/control point to a repository in > the debian team that not yet exist and the discussion on the dbus MR > seems to suggest that the repository for the dbus-broker package should > live in the utopia-team group anyway. > > Cheers, > Dan Yeah was waiting for a conclusion before changing and uploading. Simon, would you like this in utopia-team then? If so, could you please create a dbus-broker repo and give me push access? I'd like to upload to experimental before the end of the week, so that it can go through NEW. Will not upload to unstable until we are all happy, and possibly the dbus package split is agreed if not uploaded. But the current status should be good enough for experimental. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#892001: ITP: dbus-broker -- Linux D-Bus Message Broker
On Mon, 2020-12-14 at 09:07 +, Simon McVittie wrote: > On Sun, 13 Dec 2020 at 22:33:28 +0000, Luca Boccassi wrote: > > CC'ing Simon for the src:dbus bits. > > Have you reviewed dbus-broker for its compatibility with the reference > dbus-daemon? I still haven't been able to review it in detail myself > (when I get some time to work on dbus, maintaining the reference > implementation takes it all!) but one point I'm concerned about is whether > its systemd-based implementation of traditional activation works correctly > for services that (unnecessarily) double-fork/daemonize. > > smcv I have not done a detailed low-level review like that no - that would require way more time than I have :-) I have however used it for over a year now, in production, without any major issues or incompatibilities. Some minor bug fixes here and there, that were contributed upstream (mostly SELinux related). But I do not believe I have double-fork services - do you have a particular one in mind? I could do some quick testing. More importantly, I think it has been the default for Fedora since last year. That ought to be enough battle-testing for us to provide it as a option :-) -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#892001: ITP: dbus-broker -- Linux D-Bus Message Broker
Control: owner -1 Luca Boccassi On Mon, 28 Oct 2019 10:17:36 + Luca Boccassi wrote: > On Sun, 2019-10-27 at 19:49 -0600, Daniele Nicolodi wrote: > > On 25/10/2019 14:31, Luca Boccassi wrote: > > > Any update on dbus-broker? If you are looking for a sponsor, I am > > > willing to help. > > > > Hello Luca, > > > > my work on dbus-broker stalled a while ago. The package is functional > > but there was consensus that adding it to the archive required major > > restructuring of how systemd user instance services are activated, > > requiring patches for init-system-helpers and debhelper. > > Unfortunately > > it took me 4 months to have those patches reviewed. After that I > > didn't > > have time to dedicate to this little project. > > > > To bring dbus-broker into the archive it is at least necessary to > > update > > the package to the latest upstream release, update the package to > > make > > use of the added functionality in debhelper (dh_installsystemduser). > > That's probably not very difficult to do. > > > > In the long run, it would probably be necessary to coordinate with > > the > > dbus maintainers on the best way forward for splitting the dbus > > package > > into smaller pieces so that dbus-broker would not have to > > (transitively) > > depend on dbus-deamon. > > > > I am still interested in working on this but I don't have much free > > time > > at the moment and I prefer to work on more rewarding things. Seeing > > that > > there is some interest in seeing dbus-broker in Debian may be enough > > of > > an incentive to work again on this, but I cannot promise anything. > > > > The current status of the package is here: > > > > https://salsa.debian.org/dnn-guest/dbus-broker > > > > > > Cheers, > > Dan > > Thank you for your work on this! > > Is it supported to have the system bus handled by -broker and sessions > buses handled by -daemon? If it is, we could start with what's already > working, and only upload to ustable (blocking migration to bullseye) > with system bus support, and dependency on -daemon for the tools. And > then iterate from there. > What do you think? Hi, I have updated the package and done several changes, and unless there are objections I intend to upload to experimental/NEW in a couple of days. I'll start by grabbing the ITP. Repository: https://salsa.debian.org/bluca/dbus-broker I've also done some work on src:dbus to split out config and tools, like it's done in Fedora/RHEL and Yocto. MR on Salsa: https://salsa.debian.org/utopia-team/dbus/-/merge_requests/8 Thanks for starting the work on this! I'm of course very happy to work together and be both uploaders if you'd like to work on this as well going forward. Just let me know and I'll list you and add you to the shared repository once it's created. CC'ing Simon for the src:dbus bits. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#974216: ITP: dpdk-kmods -- Microsoft Azure Kusto (Azure Data Explorer) SDK for Python
Package: wnpp Severity: wishlist Owner: "Luca Boccassi" X-Debbugs-CC: debian-de...@lists.debian.org pkg-dpdk-de...@lists.alioth.debian.org * Package name: dpdk-kmods Version : 0~2020+git Upstream Author : Intel plus various authors * URL : https://git.dpdk.org/dpdk-kmods * License : GPL-2 and BSD-3-clause * Programming Lang: C * Description : Data Plane Development Kit (igb uio dkms) DPDK is a set of libraries for fast packet processing. Applications run in user-space and communicate directly with dedicated network interfaces. This package contains the source code for the igb_uio kernel module. This was originally part of src:dpdk, but from version 20.11 upstream split it out to a separate repository, without a version. We are going to maintain it in parallel with src:dpdk. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#968921: ITP: dotnet-core-3.1 -- Microsoft .NET Core SDK 3.0.100
On Sun, 2020-08-23 at 18:06 -0500, Alistair Young wrote: > Package: wnpp > Severity: wishlist > Owner: Alistair Young > X-Debbugs-Cc: debian-de...@lists.debian.org, ava...@arkane-systems.net > > * Package name: dotnet-core-3.1 > Version : 3.0.100 > Upstream Author : Microsoft > * URL : https://dotnet.microsoft.com/ > * License : MIT > Programming Lang: C++, C#, F# > Description : Microsoft .NET Core SDK 3.0.100 > > .NET Core is a development platform that you can use to build > command-line applications, microservices and modern websites. It > is open source, cross-platform and is supported by Microsoft. > > Relevant information: > > This package is built from the Microsoft-provided source-build > repository, which provides a source tarball for .NET Core > specifically intended to meet "common Linux distribution guidelines". > > As Microsoft themselves point out, packaging this for main is > useful because it lowers the barrier to use of .NET Core to one > equivalent to other in-distro languages without requiring the > use of third-party repositories, especially when the runtime is > needed as a dependency of another package. (This latter is > among my personal motivations for doing this, insofar as another > package I have in process, systemd-genie, requires this.) > > I anticipate maintaining this package myself; this should be > quite simple given the dotnet/source-build repository which > provides all necessary components to be packaged in the proper > form, and will become even simpler once bootstrapping is > no longer necessary. > > I will, however, need a sponsor. Hi, I'd be happy to sponsor uploads for this, let me know once the work is done and I'll review. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#960526: ITP: azure-kusto-python -- Microsoft Azure Kusto (Azure Data Explorer) SDK for Python
Package: wnpp Severity: wishlist Owner: "Luca Boccassi" X-Debbugs-CC: debian-de...@lists.debian.org * Package name: azure-kusto-python Version : 0.0.45 Upstream Author : Microsoft * URL : https://github.com/Azure/azure-kusto-python * License : MIT * Programming Lang: Python * Description : Microsoft Azure Kusto (Azure Data Explorer) SDK for Python Client library in Python that makes it easy to interface with Azure Kusto databases. Initially I will only enable azure-kusto-data, a Python module which allows to write scripts to extract data from Kusto. The other module in this source, azure-kusto-ingest, allows to upload data and has additional dependencies. I might enable it in the near future. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#956922: ITP: fsverity -- Userspace utilities for fs-verity
On Thu, 2020-04-16 at 21:15 +0200, Romain Perier wrote: > Package: wnpp > Severity: wishlist > Owner: Romain Perier > > * Package name: fsverity > Version : 1.0 > Upstream Author : Eric Biggers > * URL : > https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/fsverity-utils.git > * License : GPL > Programming Lang: C > Description : Userspace utilities for fs-verity > > This is fsverity, a userspace utility for fs-verity. fs-verity is a Linux > kernel > feature that does transparent on-demand integrity/authenticity verification of > the contents of read-only files, using a hidden Merkle tree (hash tree) > associated > with the file. The mechanism is similar to dm-verity, but implemented at the > file > level rather than at the block device level. The fsverity utility allows you > to > set up fs-verity protected files. > > This package will be helpful for handling the fsverity feature on a file from > userspace. > > I want to maintain this package. As DM, I need someone for the initial upload. > Packaging is currently hosted here > https://salsa.debian.org/rperier-guest/fsverity, > and will be developed at https://salsa.debian.org/debian/fsverity Hi, I can sponsor your initial upload, if you haven't found anyone else yet. A few things I noticed that would be good to fix beforehand: 1) Given you set compat 12, you can delete debian/compat and change the build-dep from debhelper (>= 12) to debhelper-compat (= 12) 2) The upstream repository is called fsverity-utils, but the source package and the salsa repository are called fsverity. It would be better if they matched. The binary package name can stay as fsverity. 3) Standards-Version is outdated 4) Rules-Requires-Root: no is not set, even though I don't see anything that would make it not work 5) The license in debian/copyright should be "GPL-2+ with OpenSSL exception" since the author explicitly added it. Copy the exception from upstream's README into a paragraph at the bottom of the license body in d/copyright. Then, remove the lintian-override for possible- gpl-code-linked-with-openssl 6) Given it's a linux-specific feature, the Architecture should probably be linux-any instead of any 7) The upstream makefile hard-codes -lcrypto instead of using pkg- config to get linker and compiler flags. This should be fixed. 8) The upstream makefile does not append to CFLAGS and CPPFLAGS, but overrides them, so the hardening flags are lost and the build fails since debhelper's -g is lost and dh_dwz fails as there are no symbols to strip. This should be fixed as well. signature.asc Description: This is a digitally signed message part
Bug#953022: ITP: javaproperties -- Python library for reading & writing Java .properties files
Package: wnpp Severity: wishlist Owner: "Luca Boccassi" X-Debbugs-CC: debian-de...@lists.debian.org * Package name: javaproperties Version : 0.6.0 Upstream Author : John Thorvald Wodder II * URL : https://github.com/Azure/azure-uamqp-python * License : MIT * Programming Lang: Python * Description : Python library for reading & writing Java .properties files javaproperties provides support for reading & writing Java .properties files (both the simple line-oriented format and XML) with a simple API based on the json module — though, for recovering Java addicts, it also includes a Properties class intended to match the behavior of Java 8's java.util.Properties as much as is Pythonically possible. Required by some modules of azure-cli. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#951788: ITP: azure-devops-cli-extension -- Azure DevOps Extension for Azure CLI
Package: wnpp Severity: wishlist Owner: "Luca Boccassi" X-Debbugs-CC: debian-de...@lists.debian.org Control: block -1 by 930413 * Package name: azure-devops-cli-extension Version : 0.17.0 Upstream Author : Microsoft Corporation * URL : https://github.com/Azure/azure-devops-cli-extension * License : MIT * Programming Lang: Python * Description : Azure DevOps Extension for Azure CLI The Azure DevOps Extension for Azure CLI adds Pipelines, Boards, Repos, Artifacts and DevOps commands to the Azure CLI 2.0. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#951738: ITP: azure-functions-devops-build -- Azure Devops Build Manager For Azure Functions
Package: wnpp Severity: wishlist Owner: "Luca Boccassi" X-Debbugs-CC: debian-de...@lists.debian.org Control: block 930413 by -1 * Package name: azure-functions-devops-build Version : 0.0.22 Upstream Author : Microsoft Corporation * URL : https://github.com/Azure/azure-functions-devops-build * License : MIT * Programming Lang: Python * Description : Azure Devops Build Manager For Azure Functions This project provides the class AzureDevopsBuildManager and supporting classes. This manager class allows the caller to manage Azure Devops pipelines that are maintained within an Azure Devops account. This project was created to be able to support command line tooling for the AZ Cli. It is required as a dependency of azure-cli. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#951731: ITP: azure-multiapi-storage-python -- Azure Storage Data Plane SDK supporting multiple API versions
Package: wnpp Severity: wishlist Owner: "Luca Boccassi" X-Debbugs-CC: debian-de...@lists.debian.org Control: block 930413 by -1 * Package name: azure-multiapi-storage-python Version : 0.2.4 Upstream Author : Microsoft Corporation * URL : https://github.com/Azure/azure-multiapi-storage-python * License : MIT * Programming Lang: Python * Description : Azure Storage Data Plane SDK supporting multiple API versions Handles multi-API versions of Azure Storage Data Plane as provided by python3-azure-storage and python3-azure-cosmos. It is required as a dependency of azure-cli. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#951710: ITP: microsoft-authentication-extensions-for-python -- Microsoft Authentication extensions for MSAL for Python
On Thu, 2020-02-20 at 08:48 -0500, Sam Hartman wrote: > The description should describe what MSAL is. The extension depends on the actual MSAL package so I left it out, but sure here's v2: Description: Microsoft Authentication extensions for MSAL for Python The Microsoft Authentication Library (MSAL) for Python enables applications to integrate with the Microsoft identity platform. The Microsoft Authentication extensions for MSAL for Python provides cross-platform utilities for interacting with MSAL, including a shared cache for token that is safe to use concurrently among multiple processes. It is intended to be used with python3-msal. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#951710: ITP: microsoft-authentication-extensions-for-python -- Microsoft Authentication extensions for MSAL for Python
Package: wnpp Severity: wishlist Owner: "Luca Boccassi" X-Debbugs-CC: debian-de...@lists.debian.org Control: block 949763 by -1 * Package name: microsoft-authentication-extensions-for-python Version : 0.1.3 Upstream Author : Microsoft Corporation * URL : https://github.com/AzureAD/microsoft-authentication-extensions-for-python * License : MIT * Programming Lang: Python * Description : Microsoft Authentication extensions for MSAL for Python The Microsoft Authentication extensions for MSAL for Python enables provide cross-platform utilities for interacting with MSAL, including a shared cache for token that is safe to use concurrently among multiple processes. It is required as a new dependency of the new version of python-azure. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#951670: ITP: azure-uamqp-python -- AMQP 1.0 client library for Python
Package: wnpp Severity: wishlist Owner: "Luca Boccassi" X-Debbugs-CC: debian-de...@lists.debian.org Control: block 949763 by -1 * Package name: azure-uamqp-python Version : 1.2.6 Upstream Author : Microsoft Corporation * URL : https://github.com/Azure/azure-uamqp-python * License : MIT * Programming Lang: Python * Description : AMQP 1.0 client library for Python A cython client library for the AMQP 1.0 protocol, implemented using the Azure uAMQP library for C. It is required as a new dependency of the new version of python-azure. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#951609: ITP: azure-data-lake-store-python -- Azure Data Lake Store Filesystem Library for Python
Package: wnpp Severity: wishlist Owner: "Luca Boccassi" X-Debbugs-CC: debian-de...@lists.debian.org Control: block 949763 by -1 * Package name: azure-data-lake-store-python Version : 0.0.48 Upstream Author : Microsoft Corporation * URL : https://github.com/Azure/azure-data-lake-store-python * License : MIT * Programming Lang: Python * Description : Azure Data Lake Store Filesystem Library for Python A pure-python interface to the Azure Data-lake Storage system, providing pythonic file-system and file objects, seamless transition between Windows and POSIX remote paths, high-performance up- and down- loader. It is required as a new dependency of the new version of python-azure. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#951126: ITP: microsoft-authentication-library-for-python -- Microsoft Authentication Library (MSAL) for Python
Package: wnpp Severity: wishlist Owner: "Luca Boccassi" X-Debbugs-CC: debian-de...@lists.debian.org Control: block 949763 by -1 * Package name: microsoft-authentication-library-for-python Version : 1.1.0 Upstream Author : Microsoft Corporation * URL : https://github.com/AzureAD/microsoft-authentication-library-for-python * License : MIT * Programming Lang: Python * Description : Microsoft Authentication Library (MSAL) for Python The Microsoft Authentication Library for Python enables applications to integrate with the Microsoft identity platform. It allows you to sign in users or apps with Microsoft identities (Azure AD, Microsoft Accounts and Azure AD B2C accounts) and obtain tokens to call Microsoft APIs such as Microsoft Graph or your own APIs registered with the Microsoft identity platform. It is built using industry standard OAuth2 and OpenID Connect protocols It is required as a new dependency of the new version of python-azure. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#950800: ITP: azure-cosmos-table-python -- Azure Cosmos DB services Python SDK
Package: wnpp Severity: wishlist Owner: "Luca Boccassi" X-Debbugs-CC: debian-de...@lists.debian.org Control: block 949763 by -1 * Package name: azure-cosmos-python Version : 1.0.5+git20191025 Upstream Author : Microsoft Corporation * URL : https://github.com/Azure/azure-cosmos-table-python * License : MIT * Programming Lang: Python * Description : Azure Cosmos DB services Python SDK This project provides a client library in Python that makes it easy to consume Microsoft Azure CosmosDB services. It is required as a new dependency of the new version of python-azure. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#892001: ITP: dbus-broker -- Linux D-Bus Message Broker
On Sun, 2019-10-27 at 19:49 -0600, Daniele Nicolodi wrote: > On 25/10/2019 14:31, Luca Boccassi wrote: > > Any update on dbus-broker? If you are looking for a sponsor, I am > > willing to help. > > Hello Luca, > > my work on dbus-broker stalled a while ago. The package is functional > but there was consensus that adding it to the archive required major > restructuring of how systemd user instance services are activated, > requiring patches for init-system-helpers and debhelper. > Unfortunately > it took me 4 months to have those patches reviewed. After that I > didn't > have time to dedicate to this little project. > > To bring dbus-broker into the archive it is at least necessary to > update > the package to the latest upstream release, update the package to > make > use of the added functionality in debhelper (dh_installsystemduser). > That's probably not very difficult to do. > > In the long run, it would probably be necessary to coordinate with > the > dbus maintainers on the best way forward for splitting the dbus > package > into smaller pieces so that dbus-broker would not have to > (transitively) > depend on dbus-deamon. > > I am still interested in working on this but I don't have much free > time > at the moment and I prefer to work on more rewarding things. Seeing > that > there is some interest in seeing dbus-broker in Debian may be enough > of > an incentive to work again on this, but I cannot promise anything. > > The current status of the package is here: > > https://salsa.debian.org/dnn-guest/dbus-broker > > > Cheers, > Dan Thank you for your work on this! Is it supported to have the system bus handled by -broker and sessions buses handled by -daemon? If it is, we could start with what's already working, and only upload to ustable (blocking migration to bullseye) with system bus support, and dependency on -daemon for the tools. And then iterate from there. What do you think? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#892001: ITP: dbus-broker -- Linux D-Bus Message Broker
On Sat, 03 Mar 2018 17:49:02 -0700 Daniele Nicolodi < daniele+deb...@grinta.net > wrote: > Package: wnpp > Severity: wishlist > Owner: Daniele Nicolodi < daniele+deb...@grinta.net > > > * Package name: dbus-broker > Version : 11 > Upstream Author : David Herrmann < dh.herrm...@gmail.com >, Tom Gundersen < t...@jklm.no >, et al. > * URL : https://github.com/bus1/dbus-broker/ > * License : Apache-2.0 > Programming Lang: C > Description : Linux D-Bus Message Broker > > The dbus-broker project is an implementation of a message bus as > defined by the D-Bus specification. Its aim is to provide high > performance and reliability, while keeping compatibility to the D-Bus > reference implementation. It is exclusively written for Linux > systems, and makes use of many modern features provided by recent > Linux kernel releases. > > I'll contact the dbus maintainers for advice, to offer to co-maintain > the package, and for sponsoring the upload. Others interested in the > package are welcome to participate. Hi, Any update on dbus-broker? If you are looking for a sponsor, I am willing to help. Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#940631: ITP: primus-vk -- Vulkan layer for GPU offloading
On Wed, 18 Sep 2019 08:09:43 +0200 =?utf-8?q?Felix_D=C3=B6rre?= < deb...@felixdoerre.de > wrote: > Package: wnpp > Severity: wishlist > Owner: Felix Dörre < deb...@felixdoerre.de > > > * Package name: primus-vk > Version : 1.2.z > Upstream Author : Felix Dörre < deb...@felixdoerre.de > > * URL : https://github.com/felixdoerre/primus_vk > * License : BSD-2-clause > Programming Lang: C++ > Description : Vulkan layer for GPU offloading > > Typically you want to display an image rendered on a more powerful > GPU on a display managed by an internal GPU. The layer in this package will > direct rendering commands to a dedicated, more powerful GPU an when such an > image is displayed it will be copied to the integrated CPU for displaying. > > This software seems already fit for several people's needs and handles most > games/applications perfectly. Hello Andreas, This can be useful for older cards that will not get native support for optimus in the 435 series and up, so I intend to sponsor it. Is it OK for you if I put this in the nvidia-team section on Salsa and so on? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#930416: ITP: azure-cosmos-python -- Azure Cosmos DB Python SDK
Package: wnpp Severity: wishlist Owner: "Luca Boccassi" X-Debbugs-CC: debian-de...@lists.debian.org Control: block 930413 by -1 * Package name: azure-cosmos-python Version : 2.3.3 Upstream Author : Microsoft Corporation * URL : https://github.com/Azure/azure-cosmos-python * License : MIT * Programming Lang: Python * Description : Azure Cosmos DB Python SDK This project implements Python classes for interacting with Azure Cosmos SQL DB, and is a dependency of azure-cli. Version 2.3.3 will be uploaded rather than the latest 3.x, as that's what azure-cli needs. Once azure-cli moves to the latest series (there was a backward-incompatible namespace change), I will update it. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#930415: ITP: vsts-cd-manager -- Visual Studio Team Services Continuous Delivery Manager
Package: wnpp Severity: wishlist Owner: "Luca Boccassi" X-Debbugs-CC: debian-de...@lists.debian.org Control: block 930413 by -1 * Package name: vsts-cd-manager Version : g2649d23 Upstream Author : Microsoft Corporation * URL : https://github.com/microsoft/vsts-cd-manager * License : MIT * Programming Lang: Python * Description : Visual Studio Team Services Continuous Delivery Manager This project provides the class ContinuousDeliveryManager and supporting classes for Azure. This CD manager class allows the caller to manage Azure Continuous Delivery pipelines that are maintained within a VSTS account. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#930414: ITP: python-applicationinsights -- Application Insights API for Python
Package: wnpp Severity: wishlist Owner: "Luca Boccassi" X-Debbugs-CC: debian-de...@lists.debian.org Control: block 930413 by -1 * Package name: python-applicationinsights Version : 0.11.9 Upstream Author : Microsoft Corporation * URL : https://github.com/Microsoft/ApplicationInsights-Python * License : MIT * Programming Lang: Python * Description : Application Insights API for Python This project extends the Application Insights API surface to support Python. Application Insights is a service that allows developers to keep their application available, performing and succeeding. This Python module will allow you to send telemetry of various kinds (event, trace, exception, etc.) to the Application Insights service where they can be visualized in the Azure Portal. This package was previously uploaded by Iain R. Learmonth via #838717, but subsequently removed via #918546 due to lack of time. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#930413: ITP: azure-cli -- Command-line tools for Microsoft Azure
Package: wnpp Severity: wishlist Owner: "Luca Boccassi" * Package name: azure-cli Version : 2.0.66 Upstream Author : Microsoft Corporation * URL : https://github.com/Azure/azure-cli * License : MIT Programming Lang: Python Description : Command-line tools for Microsoft Azure Next generation multi-platform command line experience for Azure. This package was previously uploaded by Iain R. Learmonth via #838708, but subsequently removed via #889081 due to lack of time. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#925094: ITP: knack -- A Python command line interface framework
Package: wnpp Severity: wishlist Owner: Luca Boccassi * Package name: knack Version : 0.5.3 Upstream Author : Microsoft Corporation * URL : https://github.com/Microsoft/knack * License : MIT Programming Lang: python Description : A Python command line interface framework Also available via pip: https://pypi.org/project/knack/ Knack is a dependency of many open-source Azure command line tools like azure-cli, vsts-cli and storage-fabric-cli. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#908482: ITP: libgoogle-protocolbuffers-perl -- simple Perl interface to Google Protocol Buffers
Package: wnpp Severity: wishlist Owner: Luca Boccassi * Package name: libgoogle-protocolbuffers-perl Version : 0.12 Upstream Author : CSIRT Gadgets Foundation * URL : https://metacpan.org/release/Google-ProtocolBuffers * License : GPL-1+ or Artistic Programming Lang: perl Description : simple Perl interface to Google Protocol Buffers Upstream description: "Google Protocol Buffers is a data serialization format. It is binary (and hence compact and fast for serialization) and as extendable as ML; its nearest analogues are Thrift and ASN.1. There are official mappings for C++, Java and Python languages; this library is a mapping for Perl." There are many libraries for protobuf in Debian for many languages, but none for Perl. Need it in $dowstream as well, so unless there are objections I'll upload sometimes later this week. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#902701: ITP: python-ipfix -- IPFIX implementation for Python
Package: wnpp Severity: wishlist Owner: Luca Boccassi * Package name: python-ipfix Version : 0.9.7 Upstream Author : Brian Trammell * URL : https://github.com/britram/python-ipfix * License : LGPL-3.0 Programming Lang: python Description : IPFIX implementation for Python Upstream description: "This module provides a Python interface to IPFIX message streams, and provides tools for building IPFIX Exporting and Collecting Processes. It handles message framing and deframing, encoding and decoding IPFIX data records using templates, and a bridge between IPFIX ADTs and appropriate Python data types." This module allows applications to programmatically parse IPFIX streams. Need it in $dowstream, so unless there are objections I'll upload sometimes next week. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#901812: ITP: jitterentropy-rngd -- Jitter RNG Daemon
Package: wnpp Severity: wishlist Owner: Luca Boccassi * Package name: jitterentropy-rngd Version : 1.0.8 Upstream Author : Stephan Mueller * URL : http://www.chronox.de/jent.html * License : BSD-3-Clause OR GPL-2 Programming Lang: C Description : Jitter RNG Daemon Upstream description: "Using the Jitter RNG core, the rngd provides an entropy source that feeds into the Linux /dev/random device if its entropy runs low. It updates the /dev/random entropy estimator such that the newly provided entropy unblocks /dev/random. The seeding of /dev/random also ensures that /dev/urandom benefits from entropy. Especially during boot time, when the entropy of Linux is low, the Jitter RNGd provides a source of sufficient entropy." Upstream repository: https://github.com/smuellerDD/jitterentropy-rngd Unless there are strong objections, I will upload this later this week. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#901465: ITP: driverctl -- device driver control utility for Linux
Package: wnpp Severity: wishlist Owner: Luca Boccassi * Package name: driverctl Version : 0.95 Upstream Author : Panu Matilainen * URL : https://gitlab.com/driverctl/driverctl * License : LGPL-2.1 Programming Lang: bash Description : device driver control utility for Linux Upstream description: "driverctl is a tool for manipulating and inspecting the system device driver choices. Devices are normally assigned to their sole designated kernel driver by default. However in some situations it may be desireable to override that default, for example to try an older driver to work around a regression in a driver or to try an experimental alternative driver. Another common use-case is pass-through drivers and driver stubs to allow userspace to drive the device, such as in case of virtualization. driverctl integrates with udev to support overriding driver selection for both cold- and hotplugged devices from the moment of discovery, but can also change already assigned drivers, assuming they are not in use by the system. The driver overrides created by driverctl are persistent across system reboots by default." This tool is being chosen as a preferred utility to manage drivers by a few projects. In the case I care about, by DPDK - so it's useful to have it alongside it and it might even become a dependency in the next releases. Unless there are strong objections, I plan to upload sometimes next week. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#560088: ITP: python-portio -- low level port I/O for Linux
On Tue, 08 Dec 2009 20:23:15 + Dmitrijs Ledkovs wrote: > Package: wnpp > Severity: wishlist > Owner: Dmitrijs Ledkovs > > * Package name: python-portio > Version : 0.4 > Upstream Author : Fabrizio Pollastri > * URL : http://portio.inrim.it/ > * License : GPL-3+ > Programming Lang: Python, C > Description : low level port I/O for Linux > > Wrapper for the port I/O macros like outb, inb and other provided by the C > library on Linux x86 platforms. Hi, Turns out we'll need this at $work, so I'm reopening and reassigning to myself. I'll upload it sometimes next week if there are no strong objections. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#888077: RFA: diamond – smart data producer for Graphite graphing package
On Wed, 2018-03-21 at 16:56 +, David Stapleton wrote: > Hi Sandro, > > I've been using diamond internally for a while now and have a good > understanding of how it hangs together. I've also been making > contributions > to the code on the Github project. > > Also, as far as I can see, a Subversion source repository is being > used, > but I believe this will have to be converted to git very soon as > Alioth is > being deprecated (based on details at > https://wiki.debian.org/Alioth#Deprecation_of_Alioth). This is > something > that I'm interested in doing. > > So in summary, I'd be happy to adopt this package. > > I should also mention that bl...@debian.org is willing to sponsor the > uploads. > > If there are any further details you need from me, let me know. > > Thanks, > David I work with David, I'd be happy to help him and sponsor the uploads. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#869421: RFP: stlink -- STM32 stlink programmer tools
Control: retitle -1 ITP: stlink -- STM32 stlink programmer tools Control: owner -1 bl...@debian.org On Sun, 23 Jul 2017 14:19:23 +0200 cedric wrote: > Package: wnpp > Severity: wishlist > > * Package name: stlink > Version : 1.4.0 > Upstream Author : Jerry Jacobs > * URL : https://github.com/texane/stlink > * License : BSD > Programming Lang: C > Description : STM32 stlink programmer tools > > Open source version of the STMicroelectronics Stlink Tools, > can be used to program and debug STM32 MCU boards > > There is no similar tools in debian packages right now. > Building and debian package generation works fine. > I use it often. > Maybe it can be maintained by pkg-electronics team. > I am not a debian developper but I can help if needed. > > Cedric Hi, I intend to upload stlink in the next couple of days. I've sent a few packaging fixes on Github: https://github.com/texane/stlink/pull/683 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#892642: ITP: stlink -- OpenSource ST-Link tools replacement
Package: wnpp Severity: wishlist Owner: Luca Boccassi * Package name: stlink Version : 1.5.0 Upstream Author : Andrew 'Necromant' Andrianov * URL : https://github.com/texane/stlink * License : BSD-3-clause and GPL-2+ Programming Lang: C Description : OpenSource ST-Link tools replacement Open source version of the STMicroelectronics Stlink JTAG/SWD flashing and debugging tools for STM32VL and STM32L. The transport layers STLINKv1 and STLINKv2 are supported. A shared library for developers, a command line and a GUI (GTK) tool are provided in separate packages. Most of the codebase is BSD-3-clause licensed C code, with some external components (two flashloaders) licensed under GPL-2+. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#888891: ITP: odp -- OpenDataPlane reference implementation library
On Wed, 2018-01-31 at 19:04 +0300, Dmitry Eremin-Solenikov wrote: > Hello, > > 2018-01-31 17:37 GMT+03:00 Luca Boccassi : > > On Wed, 2018-01-31 at 00:05 +0300, Dmitry Eremin-Solenikov wrote: > > > Package: wnpp > > > Severity: wishlist > > > Owner: Dmitry Eremin-Solenikov > > > > > > * Package name: odp > > > Version : 1.17.0.0 > > > Upstream Author : Linaro > > > * URL : http://www.opendataplane.org/ > > > * License : BSD 3-clause > > > Programming Lang: C > > > Description : OpenDataPlane reference implementation > > > library > > > > > > OpenDataPlane (ODP) project is an open-source, cross-platform set > > > of > > > application programming interfaces (APIs) for the networking > > > software > > > defined data plane. > > > > > > ODP embraces and extends existing proprietary, optimized vendor- > > > specific > > > hardware blocks and software libraries to provide > > > interoperability > > > with > > > minimal overhead. > > > > > > I'm one of contributors to the ODP project, so packaging will be > > > maintained closely with package upstream. Wartan Hachaturov > > > agreed to > > > be > > > a sponsor for this package. > > > > Hello Dmitry, > > > > AFAIK ODP supports DPDK - are you going to enable it? > > Yes, we are going to have DPDK enabled. Great! > > We have been shipping DPDK in Debian since Stretch, tracking > > upstream > > LTS releases. We also provide a pkg-config file (libdpdk.pc) so > > it's a > > bit easier than vanilla support for rdepends. > > Unfortunately other distributions don't ship pkg-config file. We'll > probably stick > to traditional way of handling DPDK. It is regularly tested in > Travis, so there > should be no issues there. Ok fair enough, but note that it was added upstream with the new meson- based build system that will debut in 18.02 - I made sure it was compatible with what we have been shipping in Ubuntu and Debian so in the future it will be usable universally. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#888891: ITP: odp -- OpenDataPlane reference implementation library
On Wed, 2018-01-31 at 00:05 +0300, Dmitry Eremin-Solenikov wrote: > Package: wnpp > Severity: wishlist > Owner: Dmitry Eremin-Solenikov > > * Package name: odp > Version : 1.17.0.0 > Upstream Author : Linaro > * URL : http://www.opendataplane.org/ > * License : BSD 3-clause > Programming Lang: C > Description : OpenDataPlane reference implementation library > > OpenDataPlane (ODP) project is an open-source, cross-platform set of > application programming interfaces (APIs) for the networking software > defined data plane. > > ODP embraces and extends existing proprietary, optimized vendor- > specific > hardware blocks and software libraries to provide interoperability > with > minimal overhead. > > I'm one of contributors to the ODP project, so packaging will be > maintained closely with package upstream. Wartan Hachaturov agreed to > be > a sponsor for this package. Hello Dmitry, AFAIK ODP supports DPDK - are you going to enable it? We have been shipping DPDK in Debian since Stretch, tracking upstream LTS releases. We also provide a pkg-config file (libdpdk.pc) so it's a bit easier than vanilla support for rdepends. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#587987: RFP: Razer device configuration tool -- Razer configuration interface & background daemon for low level hardware access.
Control: owner -1 bl...@debian.org Control: retitle -1 ITP: razercfg -- Razer configuration interface & background daemon for low level hardware access On Sat, 3 Jul 2010 15:42:06 + (UTC) initrd@comcast.net wrote: > Package: wnpp > Severity: wishlist > URL: http://bu3sch.de/joomla/index.php/razer-nextgen-config-tool > License: GNU GPL Hi, I intend to upload this shortly. Upstream ships a debian/ directory, to which I already contributed some fixes earlier this year. The orig tarball will be +ds repacked to remove it. Since this bug was filed a custom icon artwork was added upstream, licensed under the CC-BY-4.0 which is DFSG compatible. Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#878821: ITP: norm -- NACK-Oriented Reliable Multicast (NORM) library
Package: wnpp Severity: wishlist Owner: Luca Boccassi * Package name: norm Version : 1.5r6 Upstream Author : Naval Research Laboratory (NRL) * URL : https://www.nrl.navy.mil/itd/ncs/products/norm * License : NSL (BSD-2-clause lookalike) Programming Lang: C++ Description : NACK-Oriented Reliable Multicast (NORM) library The NORM protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. libnorm provides a shared library and an API to use such protocol. The NSL releases it under a license that is very similar to BSD-2- clause. This license is already used in Debian by another software from the NSL, mgen: https://packages.debian.org/source/sid/mgen The upstream tarball unfortunately uses WAF, which means it comes with a waf binary. So it is dfsg repacked to extract it as suggested by http s://wiki.debian.org/UnpackWaf - a get-orig-source rule to integrate it with uscan is provided. Care has been taken into making sure the repacking is reproducible using the appropriate tar options including clamping the time to SOURCE_DATE_EPOCH if needed. The library is at ABI revision 1 - there will also be a -dev package with the public header, the symlink and a pkg-config file, and a -doc file with the upstream documentation package with doc-base and some examples. After libnorm is in the archive some software, like zeromq3, can be rebuilt to use it and provide additional multicast-based features. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#874426: ITP: generator-scripting-language -- code generation and construction tool
On Wed, 06 Sep 2017 00:48:52 +0100 Luca Boccassi wrote: > Package: wnpp > Severity: wishlist > Owner: Luca Boccassi > > * Package name: generator-scripting-language > Version : 4.1.4 > Upstream Author : iMatix and ZeroMQ development community > * URL : https://github.com/zeromq/gsl > * License : GPL-3+ > Programming Lang: C > Description : code generation and construction tool > > Upstream's description: > > GSL/4.1 is a code construction tool. It will generate code in all > languages and for all purposes. If this sounds too good to be true, > welcome to 1996, when we invented these techniques. Magic is simply > technology that is twenty years ahead of its time. In addition to > code construction, GSL has been used to generate database schema > definitions, user interfaces, reports, system administration tools > and much more. > > As example of a use case, GSL is one of the main tools used by ZMQ > developers to automatically generated bindings for many languages > including Java and Python via the zproject templates [1]. > It can also be used to generate network protocols code over ZMQ from a > high level ABNF or XML description via the zproto templates [2]. > > Writing templates is quick and easy, and plenty of examples (packaged > separately in -examples) and documentation are included. > > Unfortunately the name clashes with the GNU Scientific Library, so I've > used the long form rather than the acronym for the package name. > > The license is GPL-3+ for the program, with a version header and 2 > makefiles under BSD-3-Clause, and a series of code examples for > developers under MPL-2.0. > > The only dependency is libpcre3. > > I've pushed a branch with the packaging to Github [3]. > > -- > Kind regards, > Luca Boccassi > > [1] https://github.com/zeromq/zproject > [2] https://github.com/zeromq/zproto > [3] https://github.com/bluca/gsl/tree/debian Looks like I had a typo in the X-Debbugs-CC header, so replying with debian-devel CC'ed. Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#874426: ITP: generator-scripting-language -- code generation and construction tool
Package: wnpp Severity: wishlist Owner: Luca Boccassi * Package name: generator-scripting-language Version : 4.1.4 Upstream Author : iMatix and ZeroMQ development community * URL : https://github.com/zeromq/gsl * License : GPL-3+ Programming Lang: C Description : code generation and construction tool Upstream's description: GSL/4.1 is a code construction tool. It will generate code in all languages and for all purposes. If this sounds too good to be true, welcome to 1996, when we invented these techniques. Magic is simply technology that is twenty years ahead of its time. In addition to code construction, GSL has been used to generate database schema definitions, user interfaces, reports, system administration tools and much more. As example of a use case, GSL is one of the main tools used by ZMQ developers to automatically generated bindings for many languages including Java and Python via the zproject templates [1]. It can also be used to generate network protocols code over ZMQ from a high level ABNF or XML description via the zproto templates [2]. Writing templates is quick and easy, and plenty of examples (packaged separately in -examples) and documentation are included. Unfortunately the name clashes with the GNU Scientific Library, so I've used the long form rather than the acronym for the package name. The license is GPL-3+ for the program, with a version header and 2 makefiles under BSD-3-Clause, and a series of code examples for developers under MPL-2.0. The only dependency is libpcre3. I've pushed a branch with the packaging to Github [3]. -- Kind regards, Luca Boccassi [1] https://github.com/zeromq/zproject [2] https://github.com/zeromq/zproto [3] https://github.com/bluca/gsl/tree/debian signature.asc Description: This is a digitally signed message part
Bug#820050: Monolithic grub for signing (grub2-signed/secure-boot)
On Thu, 20 Oct 2016 17:32:53 -0200 Helen Koike wrote: > Hi, > > To be able to create grub2-signed package we need a monolithic version > of grub available, as grub doesn't know how verify the signatures of its > modules loaded from the disk, so we need a monolithic version containing > grub and all it's modules into a single image to be signed. Then > grub2-signed package can depend on the signature and on monolithic grub > package to be used when secure boot is enabled. > > So I was wondering it is would be ok to change the packages > grub-efi-deb to create a monolithic version of grub or if it will be > preferable to create a grub-efi-monolithicdeb, or do you have any > other idea? > > Thanks > Helen Koike Hi, In case any of this could be of use: a small patch to build additional monolithic EFI grub packages for amd64/arm64 can be found here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851994 and here's a grub2-signed source package that I derived from linux-signed: https://github.com/bluca/grub2-signed I've been successfully using these changes internally in our downstream rebuild at work. The other secure boot related grub patches are necessary as well (to enable the build in grub on platforms other than Ubuntu listed on #836140). I know on Debian DAK will do the signing from a tarball with the unsigned binaries rather than a package, but just in case a user or another downstream wants to self-sign I wanted to leave these here for reference. Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#812530: ITP: libglvnd -- Vendor-neutral OpenGL dispatch layer
On Thu, 2016-12-01 at 21:25 +0200, Timo Aaltonen wrote: > On 01.12.2016 15:32, Luca Boccassi wrote: > > On Sun, 07 Feb 2016 17:33:44 +0000 Luca Boccassi > > wrote: > >> Control: owner -1 tjaal...@debian.org > >> > >> On Mon, 2016-01-25 at 09:46 +0200, Timo Aaltonen wrote: > >>> 24.01.2016, 20:34, Luca Boccassi kirjoitti: > >>>> * Package name: libglvnd > >>>> Version : 0~20160122 > >>>> Upstream Author : NVIDIA Corporation > >>>> * URL : https://github.com/NVIDIA/libglvnd > >>>> * License : MIT > >>>> Programming Lang: C > >>>> Description : Vendor-neutral OpenGL dispatch layer > >>>> > >>>> libglvnd is a Vendor-neutral dispatch layer for arbitrating OpenGL API > >>>> calls between multiple vendors on a per-screen basis. > >>>> Currently, only the GLX window-system API and OpenGL are supported, but > >>>> in the future this library may support EGL and OpenGL ES as well. > >>>> > >>>> > >>>> I am one of the pkg-nvidia maintainers, and we would like to use this > >>>> ITP to start a discussion about packaging libglvnd with the maintainers > >>>> of Mesa, X and fglrx. > >>>> > >>>> As you might have read news about, NVIDIA has been working on an open > >>>> source (MIT-like license) vendor-neutral dispatch layer for OpenGL. They > >>>> have now declared it stable, and their proprietary graphics driver > >>>> started using it in version 361 [1]. > >>>> > >>>> It has been reported that AMD is interested in supporting this library > >>>> too [2]. > >>>> > >>>> Finally, following a discussion on the upstream Mesa mailing list [3], > >>>> it has been reported that work is in progress in Mesa too to support > >>>> this library [4]. > >>>> > >>>> Our proposal would be to wait to upload this package until a version of > >>>> Mesa that can make use of it is released. Then, as a a possible example, > >>>> we could upload both to Debian experimental, and at the same time switch > >>>> the proprietary Nvidia drivers to use it, and see how it works. When > >>>> fglrx gets there too, we should then be able to stop using > >>>> glx-alternatives-* packages. > >>>> > >>>> My proposal for the packaging itself can be found on pkg-nvidia's git > >>>> [5]. Given upstream doesn't seem to do release tagging, I'm using the > >>>> 0~ format. I split each .so in an individual binary > >>>> and -dbg package, called *-glvnd[-dbg], plus a common libglvnd-dev. > >>>> Figuring out precisely the licensing was the fun part, as the code is a > >>>> mixture of Expat, MIT-like, BSD 1-clause and 3-clause, GPL3 and > >>>> GNU-permissive :-) > >>>> > >>>> Comments? Opinions? ACKs/NACKs? > >>> > >>> packaging available at > >>> > >>> git://git.debian.org/pkg-xorg/lib/libglvnd.git > >>> > >>> but since it hasn't been of any use there was no ITP filed, so thanks > >>> for that :) > >>> > >>> it's not final of course, tests fail and there are probably other issues > >>> too.. > > > > Hi Timo, > > > > Any news on uploading this to Stretch? > > > > I think upstream Mesa has some initial support merged: > > > > https://lists.freedesktop.org/archives/mesa-dev/2016-May/116346.html > > https://cgit.freedesktop.org/mesa/mesa/tree/src/glx/glxglvnd.c > > Yes, libglvnd had some packaging issues which I think are now solved in > git. I'll probably upload it to experimental soon. Great news, thank you for taking care of it! Once it's up in experimental we'll work on it from the nvidia-driver side. Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#812530: ITP: libglvnd -- Vendor-neutral OpenGL dispatch layer
On Sun, 07 Feb 2016 17:33:44 + Luca Boccassi wrote: > Control: owner -1 tjaal...@debian.org > > On Mon, 2016-01-25 at 09:46 +0200, Timo Aaltonen wrote: > > 24.01.2016, 20:34, Luca Boccassi kirjoitti: > > > * Package name: libglvnd > > > Version : 0~20160122 > > > Upstream Author : NVIDIA Corporation > > > * URL : https://github.com/NVIDIA/libglvnd > > > * License : MIT > > > Programming Lang: C > > > Description : Vendor-neutral OpenGL dispatch layer > > > > > > libglvnd is a Vendor-neutral dispatch layer for arbitrating OpenGL API > > > calls between multiple vendors on a per-screen basis. > > > Currently, only the GLX window-system API and OpenGL are supported, but > > > in the future this library may support EGL and OpenGL ES as well. > > > > > > > > > I am one of the pkg-nvidia maintainers, and we would like to use this > > > ITP to start a discussion about packaging libglvnd with the maintainers > > > of Mesa, X and fglrx. > > > > > > As you might have read news about, NVIDIA has been working on an open > > > source (MIT-like license) vendor-neutral dispatch layer for OpenGL. They > > > have now declared it stable, and their proprietary graphics driver > > > started using it in version 361 [1]. > > > > > > It has been reported that AMD is interested in supporting this library > > > too [2]. > > > > > > Finally, following a discussion on the upstream Mesa mailing list [3], > > > it has been reported that work is in progress in Mesa too to support > > > this library [4]. > > > > > > Our proposal would be to wait to upload this package until a version of > > > Mesa that can make use of it is released. Then, as a a possible example, > > > we could upload both to Debian experimental, and at the same time switch > > > the proprietary Nvidia drivers to use it, and see how it works. When > > > fglrx gets there too, we should then be able to stop using > > > glx-alternatives-* packages. > > > > > > My proposal for the packaging itself can be found on pkg-nvidia's git > > > [5]. Given upstream doesn't seem to do release tagging, I'm using the > > > 0~ format. I split each .so in an individual binary > > > and -dbg package, called *-glvnd[-dbg], plus a common libglvnd-dev. > > > Figuring out precisely the licensing was the fun part, as the code is a > > > mixture of Expat, MIT-like, BSD 1-clause and 3-clause, GPL3 and > > > GNU-permissive :-) > > > > > > Comments? Opinions? ACKs/NACKs? > > > > packaging available at > > > > git://git.debian.org/pkg-xorg/lib/libglvnd.git > > > > but since it hasn't been of any use there was no ITP filed, so thanks > > for that :) > > > > it's not final of course, tests fail and there are probably other issues > > too.. Hi Timo, Any news on uploading this to Stretch? I think upstream Mesa has some initial support merged: https://lists.freedesktop.org/archives/mesa-dev/2016-May/116346.html https://cgit.freedesktop.org/mesa/mesa/tree/src/glx/glxglvnd.c Thanks! Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#815760: dpdk debian packaging
On Sep 16, 2016 08:53, "santiag...@riseup.net" wrote: > > El 15/09/16 a las 09:04, Christian Ehrhardt escribió: > > > > On Wed, Sep 14, 2016 at 6:28 PM, Luca Boccassi wrote: > > > > Christian has sent patches upstream a couple weeks back: > > > > http://dpdk.org/dev/patchwork/patch/15553/ > > Great! > > > And we carry the former version of that submission as a patch for now to fix > > packaging as-is for now. > > Once accepted upstream that delta will be rebased for 16.07 topic branch to > > match the accepted version. > > For 16.11 I expect them to be upstream so on that topic branch we can drop the > > delta then. > > So would you like to include it in debian/patches for now? > > > Attached you can find other three patches to fix minor issues, and make > lintian happier. > What else would be needed to upload to debian? > > Cheers, and thanks a lot for your work! > > Santiago Hi, Thanks again, but could you please add the signoff to your patches? We cannot apply them as-is otherwise. Thanks! Kind regards, Luca Boccassi
Bug#815760: dpdk debian packaging
On Wed, 2016-09-14 at 17:45 +0200, santiag...@riseup.net wrote: > Hi, > > So sorry for this time to answer. > > El 26/07/16 a las 14:56, Luca Boccassi escribió: > > On Tue, 2016-07-19 at 17:08 +0200, santiag...@riseup.net wrote: > > > Hi, > > > > > > El 06/07/16 a las 10:27, Luca Boccassi escribió: > > > > On Mon, 4 Jul 2016 13:57:33 +0200 Christian Ehrhardt > > > > wrote: > > > > > On Sun, Jul 3, 2016 at 8:52 PM, Santiago Ruano Rincón > > > > > > > > > > wrote: > > > > > > > > > > > Hi all, > > > > > > > > > > > > On Thu, 14 Apr 2016 21:34:11 +0100 Luca Boccassi > > > > > > wrote: > > > > > > > On Wed, 30 Mar 2016 08:38:58 +0200 Christian Ehrhardt > > > > > > > wrote: > > > > > > > > On Wed, Mar 30, 2016 at 7:41 AM, C.J. Collier > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > On Wed, 24 Feb 2016 11:51:20 +0100 Christian Ehrhardt > > > > > > > > > > > > > > > > > > wrote: > > […] > > > > However, lintian is not happy, as you can see in the attached report. > > > Some of the points to highlight from it that, IMHO could block uploading > > > are: > > > > > > 1. W: libdpdk-librte-pmd-xenvirt1: package-name-doesnt-match-sonames > > > librte-pmd-xenvirt1 and related: > > >Any reason to add the libdpdk- name prefix to the librte-* libraries? > > >Usually, the name of a binary library package follows its SONAME, and > > >thus just librte-* would be more accurate. > > > > Some time ago the libraries were renamed and no longer have the libdpdk- > > prefix: > > > > https://gerrit.fd.io/r/gitweb?p=deb_dpdk.git;a=blob;f=debian/control;h=37a64437bf1d566082477923d91618c1b9016725;hb=refs/heads/deb_dpdk_16.07 > > Humm, I was following the master branch instead. Any reason to don't > merge this deb_dpdk_16.07 into master? > > I am starting to work over this branch now, so I will have to do part of > the job again. For the moment, the rest of the mail is a quick answer. We will soon have a 16.11 branch I think. We didn't discuss in details but I don't know if we'll be using the master branch again or just stay on the topic branches. > > > 2. Hardening: it seems that build flags need to be fixed. E.g: > > >W: libdpdk-librte-eal2: hardening-no-relro > > > usr/lib/x86_64-linux-gnu/librte_eal.so.2 > > > > Some were fixed, but yes indeed there's a few more to deal with, will do as > > soon as I have time. But given the possible performance implications it > > might be good to consult with upstream. > > Indeed, seems to be fixed. Thanks! With the latest version as of today all the hardening and the other lintian errors are fixed, the manpages are what's missing but there's a patch upstream for that. > > > 3. I am not sure the licensing (and then debian/copyright) is not as > > >simple as a dual GPL-2/BSD for core stuff and GPL for kernel > > > components, > > >as README states. I will check carefully this, since no accurate > > >debian/copyright, no upload possible. > > > > I'm pretty sure that's what upstream advertises and a quick run of > > licensecheck seems to confirm that, but if you find otherwise please do > > flag that both with us and upstream > > Actually, my wording was not accurate either, since README doesn't claim > *dual* licensing but different licenses for different components. BSD > (3-clause) for the core and GPLv2 for kernel-related. > > Anyway, licensecheck outputs files under other licenses. E.g.: > > […] > ./drivers/crypto/qat/qat_adf/icp_qat_fw.h: BSD (3 clause) GPL (v2) > ./drivers/crypto/qat/qat_adf/icp_qat_fw_la.h: BSD (3 clause) GPL (v2) > ./drivers/crypto/qat/qat_adf/adf_transport_access_macros.h: BSD (3 clause) > GPL (v2) > ./drivers/crypto/qat/qat_adf/qat_algs_build_desc.c: BSD (3 clause) GPL (v2) > […] > ./lib/librte_compat/rte_compat.h: BSD (2 clause) > […] > > Attached you can find a patch for debian/copyright, that I think it's > accurate with the current source. FTR, it is based on (and thanks to): > > licensecheck --copyright -r `find * -type f` | \ > /usr/lib/cdbs/licensecheck2dep5 > debian/copyright.auto > > Also, AFAICS there are a couple of files in lib/librte_net/ that need > some cleaning by upstream. Thanks for the patch, I'll have a look and apply it! > > > 4. It would be great to have manpages for these binaries: > > > > > >W: dpdk: binary-without-manpage sbin/dpdk_nic_bind > > >W: dpdk: binary-without-manpage usr/bin/dpdk_proc_info > > >W: dpdk: binary-without-manpage usr/bin/testpmd > > > > Yes absolutely, patches are welcome :-) > > Unless somebody else beats me, I will try do them at some point. Christian has sent patches upstream a couple weeks back: http://dpdk.org/dev/patchwork/patch/15553/ Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#815760: dpdk debian packaging
On Tue, 2016-07-19 at 17:08 +0200, santiag...@riseup.net wrote: > Hi, > > El 06/07/16 a las 10:27, Luca Boccassi escribió: > > On Mon, 4 Jul 2016 13:57:33 +0200 Christian Ehrhardt > > wrote: > > > On Sun, Jul 3, 2016 at 8:52 PM, Santiago Ruano Rincón > > > > > > wrote: > > > > > > > Hi all, > > > > > > > > On Thu, 14 Apr 2016 21:34:11 +0100 Luca Boccassi > > > > wrote: > > > > > On Wed, 30 Mar 2016 08:38:58 +0200 Christian Ehrhardt > > > > > wrote: > > > > > > On Wed, Mar 30, 2016 at 7:41 AM, C.J. Collier > > > > > > > > > > > > wrote: > > > > > > > > > > > > > On Wed, 24 Feb 2016 11:51:20 +0100 Christian Ehrhardt > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > [...] > > > > > > [...] > > > > Hi Santiago, > > > so far Luca was planned to maintain it, but I'd assume he is no objecting > > > to a co-maintainer. > > > Especially if the co-maintainer can help with the initial upload. > > > It might be good to know about a lot of details in advance out of the > > > scope > > > of actually uploading it. > > > We would be happy if you join us in our work even before the initial > > > upload > > > takes place. > > > > No objections at all, more help is always welcome :-) > > Thanks :) > > The current dpdk from the fi.io git repo builds ok on a stable > environment and I am able to make a basic use. Thanks for your work! > > However, lintian is not happy, as you can see in the attached report. > Some of the points to highlight from it that, IMHO could block uploading > are: > > 1. W: libdpdk-librte-pmd-xenvirt1: package-name-doesnt-match-sonames > librte-pmd-xenvirt1 and related: >Any reason to add the libdpdk- name prefix to the librte-* libraries? >Usually, the name of a binary library package follows its SONAME, and >thus just librte-* would be more accurate. Some time ago the libraries were renamed and no longer have the libdpdk- prefix: https://gerrit.fd.io/r/gitweb?p=deb_dpdk.git;a=blob;f=debian/control;h=37a64437bf1d566082477923d91618c1b9016725;hb=refs/heads/deb_dpdk_16.07 > 2. Hardening: it seems that build flags need to be fixed. E.g: >W: libdpdk-librte-eal2: hardening-no-relro > usr/lib/x86_64-linux-gnu/librte_eal.so.2 Some were fixed, but yes indeed there's a few more to deal with, will do as soon as I have time. But given the possible performance implications it might be good to consult with upstream. > 3. I am not sure the licensing (and then debian/copyright) is not as >simple as a dual GPL-2/BSD for core stuff and GPL for kernel components, >as README states. I will check carefully this, since no accurate >debian/copyright, no upload possible. I'm pretty sure that's what upstream advertises and a quick run of licensecheck seems to confirm that, but if you find otherwise please do flag that both with us and upstream > 4. It would be great to have manpages for these binaries: > >W: dpdk: binary-without-manpage sbin/dpdk_nic_bind >W: dpdk: binary-without-manpage usr/bin/dpdk_proc_info >W: dpdk: binary-without-manpage usr/bin/testpmd Yes absolutely, patches are welcome :-) > What do you think? > > Cheers, > > Santiago Thanks for the feedback! Keep it coming :-) Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#815760:
On Mon, 4 Jul 2016 13:57:33 +0200 Christian Ehrhardt wrote: > On Sun, Jul 3, 2016 at 8:52 PM, Santiago Ruano Rincón > wrote: > > > Hi all, > > > > On Thu, 14 Apr 2016 21:34:11 +0100 Luca Boccassi > > wrote: > > > On Wed, 30 Mar 2016 08:38:58 +0200 Christian Ehrhardt > > > wrote: > > > > On Wed, Mar 30, 2016 at 7:41 AM, C.J. Collier > > > > > > > > wrote: > > > > > > > > > On Wed, 24 Feb 2016 11:51:20 +0100 Christian Ehrhardt > > > > > > > > > > wrote: > > > > > > > > > > > > > [...] > > > > > > > > I'm also no DD, so sponsors will be needed. > > > > > > > > > > I'm interested in co-maintaining this package, and I've been a > > > > > Debian user > > > > > for a couple of decades now. I've even been an uploader, years > > > > > ago. > > > > > > > > > > > > > Hi C.J., > > > > great to hear that you want to help as well - I'm sure it will get > > > > great. > > > > We are Currently three people: > > > > - Luca Boccassi - DM, already applied for package upload permissions > > > > - Martin Thiago - Experienced in experimenting with > > > > DPDK/Debian/Ubuntu, > > > > giving us a broad testing&usage range > > > > - Myself - Packaging DPDK for Ubuntu, Testing DPDK with integrated > > > > tests > > > > and Openvswitch-DPDK > > > > > > > > You would be a great addition to our group - more Debian experience > > > > will > > > > surely help. > > > > > > > > > > > > > I've submitted an ITP for the FD.io group of packages: > > > > > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819516 > > > > > > > > > > These depend on DPDK, so I've got an interest in making sure the > > > > > DPDK > > > > > packages are good. > > > > > > > > > > > > > From what I learned with packaging DPDK 2.2 for Ubuntu 16.04 there > > > > are a > > > > lot of things that can fail with DPDK. > > > > It is a great, but also fast moving and bleeding edge project. > > > > So testing and patching is needed - more packages "Consuming" the > > > > library > > > > and thereby more diverse test exposure help exactly with that. > > > > > > > > The three of us kind of agreed on the following rough schedule: > > > > - (Now / Luca) Requesting upload permissions for DPDK > > > > - (Now / Me) Completing testing and fixing DPDK packaging in ubuntu > > > > - (11th of May / All of us) start a kick off for packaging DPDK in > > > > Debian > > > > > > > > It would be great to have DPDK on Debian. I can upload the packages, and > > maybe co-maintain. > > > Hi Santiago, > so far Luca was planned to maintain it, but I'd assume he is no objecting > to a co-maintainer. > Especially if the co-maintainer can help with the initial upload. > It might be good to know about a lot of details in advance out of the scope > of actually uploading it. > We would be happy if you join us in our work even before the initial upload > takes place. No objections at all, more help is always welcome :-) -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#815760:
On Wed, 30 Mar 2016 08:38:58 +0200 Christian Ehrhardt wrote: > On Wed, Mar 30, 2016 at 7:41 AM, C.J. Collier > wrote: > > > On Wed, 24 Feb 2016 11:51:20 +0100 Christian Ehrhardt > > wrote: > > > > [...] > > > > > But I'm not a Debian developer, so I'd like to have a more Debian centric > > > co-maintainer for a proper Debian expertise and opinion in all the work. > > > I'm also no DD, so sponsors will be needed. > > > > I'm interested in co-maintaining this package, and I've been a Debian user > > for a couple of decades now. I've even been an uploader, years ago. > > > > Hi C.J., > great to hear that you want to help as well - I'm sure it will get great. > We are Currently three people: > - Luca Boccassi - DM, already applied for package upload permissions > - Martin Thiago - Experienced in experimenting with DPDK/Debian/Ubuntu, > giving us a broad testing&usage range > - Myself - Packaging DPDK for Ubuntu, Testing DPDK with integrated tests > and Openvswitch-DPDK > > You would be a great addition to our group - more Debian experience will > surely help. > > > > I've submitted an ITP for the FD.io group of packages: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819516 > > > > These depend on DPDK, so I've got an interest in making sure the DPDK > > packages are good. > > > > From what I learned with packaging DPDK 2.2 for Ubuntu 16.04 there are a > lot of things that can fail with DPDK. > It is a great, but also fast moving and bleeding edge project. > So testing and patching is needed - more packages "Consuming" the library > and thereby more diverse test exposure help exactly with that. > > The three of us kind of agreed on the following rough schedule: > - (Now / Luca) Requesting upload permissions for DPDK > - (Now / Me) Completing testing and fixing DPDK packaging in ubuntu > - (11th of May / All of us) start a kick off for packaging DPDK in Debian > > The next DPDK release changes a lot regarding the build system and the > shared library handling, so on one hand IMHO it would avoid a lot of > restructuring if we start with 16.04 release. > But OTOH consuming packages might need older DPDK API / shared library > handling versions that might no more be supported. > But among many other things - that is one of the bigger topics we want to > discuss and agree on the kick-off. > > I hope that schedule works for you and it would be great to add you to the > kick-off and our later work. Hi, Some good news: Andreas Beckmann [CC'ed] has kindly agreed to whitelist me for DPDK uploads. Unfortunately one cannot be whitelisted for a package that is not uploaded yet (since it is unknown to the system), but he proposed to do the very first upload to the NEW queue, and then whitelist my PGP key so that I can take over afterwards. Thanks again for the help Andreas! Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#815760: Your mail
On Wed, 2016-03-23 at 08:00 +0100, Christian Ehrhardt wrote: > On Tue, Mar 22, 2016 at 8:54 PM, Luca Boccassi wrote: > > > On Wed, 24 Feb 2016 11:51:20 +0100 Christian Ehrhardt > > wrote: > > > [...] > > > > > It'd be great to have this packaged in Debian too, so that we can share > > the > > > work. I am looking for co-maintainers to help me with this. > > > > > > But I'm not a Debian developer, so I'd like to have a more Debian centric > > > co-maintainer for a proper Debian expertise and opinion in all the work. > > > I'm also no DD, so sponsors will be needed. > > > > Hello Christian, > > > > Thanks for doing the packaging work, it looks great! > > > > I work at Brocade, and we maintain a dpdk package internally too. I'd be > > happy to try and help as best as I can with the packaging, and with > > sponsoring the uploads! > > > > Hi Luca, > great that you would like to join us. > Martin also offered to help and he is already working with the Ubuntu > package of DPDK as of now. > I think we would be enough of a group to have discussions, test, assist and > review for each other and so on. Perfect! Is the packaging in git somewhere? > > The only small issue is that I am a DM, not a DD, so I would need a DD > > to do the one-time whitelist of my pgp key for this package on the ftp > > first, and then I'd be able to sponsor all the uploads. > > > > That really sounds like a plan. > I'm currently heads down on testing and flushing out various issues with > DPDK towards the release of Ubuntu 16.04. > And there I find & fix issues all the time right now. > Therefore I'd suggest we wait until it reached some kind of stability and > then work together to transfer on that base to Debian. > > In terms of timing I'd suggest the following > 1. You request being whitelisted for that package > 2. I'll finish up the DPDK-2.2 packaging and test/fix phase for Ubuntu 16.04 > 3. In early May we would then do a kick of with the three of us (and > whoever else wants to join) > There we can assert the current state of DPDK (constraints to libs, new > dpdk 16.04 build changes, ...) and its packaging, and make a plan on > who/how exactly what to do. > > I hope that would work for you, but I really see no reason to hurry now > just to upload patches every other day. > If that works for you let me know and I'd invite you two to a kick-of > session in a hangout around that time. Sounds great for me :-) A few of my colleagues work on the internal dpdk, I'll ask if they would like to help as well. I'll ask to be whitelisted and report back once I have news. -- Kind regards, Luca Boccassi Brocade Communications Systems signature.asc Description: This is a digitally signed message part
Bug#815760: Your mail
On Wed, 24 Feb 2016 11:51:20 +0100 Christian Ehrhardt wrote: > Subject: ITP: dpdk -- Data Plane Development Kit > Package: wnpp > Owner: Christian Ehrhardt > Severity: wishlist > > * Package name: dpdk > Version : 2.2 > Upstream Author : Thomas Monjalon > * URL : http://dpdk.org/ > * License : BSD (core libs), GPLv2 (kernel components) > Programming Lang: C > Description : Data Plane Development Kit > > 1. What is DPDK useful for > DPDK is a set of libraries and drivers for fast packet processing. It > was designed to run on any processors. The first supported CPU was Intel > x86 and it is now extended to IBM Power 8, EZchip TILE-Gx and ARM. It > runs mostly in Linux userland. A FreeBSD port is available for a subset > of DPDK features. > > Main libraries > - multicore framework > - huge page memory > - ring buffers > - poll-mode drivers > > Usage > These libraries can be used to: > - receive and send packets within the minimum number of CPU cycles > (usually less than 80 cycles) > - develop fast packet capture algorithms (tcpdump-like) > - run third-party fast path stacks > Some packet processing functions have been benchmarked up to hundreds > million frames per second, using 64-byte packets with a PCIe NIC. > > > 2. Maintenance Plan > I'm currently maintaining dpdk for ubuntu (launchpad.net/ubuntu/+source/dpdk) > and the existing packaging should be suitable for Debian also. > > It'd be great to have this packaged in Debian too, so that we can share the > work. I am looking for co-maintainers to help me with this. > > But I'm not a Debian developer, so I'd like to have a more Debian centric > co-maintainer for a proper Debian expertise and opinion in all the work. > I'm also no DD, so sponsors will be needed. Hello Christian, Thanks for doing the packaging work, it looks great! I work at Brocade, and we maintain a dpdk package internally too. I'd be happy to try and help as best as I can with the packaging, and with sponsoring the uploads! The only small issue is that I am a DM, not a DD, so I would need a DD to do the one-time whitelist of my pgp key for this package on the ftp first, and then I'd be able to sponsor all the uploads. If you would like to accept my help, I will ask for whitelisting. Let me know :-) -- Kind regards, Luca Boccassi Brocade Communications Systems signature.asc Description: This is a digitally signed message part
Bug#812530: ITP: libglvnd -- Vendor-neutral OpenGL dispatch layer
Control: owner -1 tjaal...@debian.org On Mon, 2016-01-25 at 09:46 +0200, Timo Aaltonen wrote: > 24.01.2016, 20:34, Luca Boccassi kirjoitti: > > * Package name: libglvnd > > Version : 0~20160122 > > Upstream Author : NVIDIA Corporation > > * URL : https://github.com/NVIDIA/libglvnd > > * License : MIT > > Programming Lang: C > > Description : Vendor-neutral OpenGL dispatch layer > > > > libglvnd is a Vendor-neutral dispatch layer for arbitrating OpenGL API > > calls between multiple vendors on a per-screen basis. > > Currently, only the GLX window-system API and OpenGL are supported, but > > in the future this library may support EGL and OpenGL ES as well. > > > > > > I am one of the pkg-nvidia maintainers, and we would like to use this > > ITP to start a discussion about packaging libglvnd with the maintainers > > of Mesa, X and fglrx. > > > > As you might have read news about, NVIDIA has been working on an open > > source (MIT-like license) vendor-neutral dispatch layer for OpenGL. They > > have now declared it stable, and their proprietary graphics driver > > started using it in version 361 [1]. > > > > It has been reported that AMD is interested in supporting this library > > too [2]. > > > > Finally, following a discussion on the upstream Mesa mailing list [3], > > it has been reported that work is in progress in Mesa too to support > > this library [4]. > > > > Our proposal would be to wait to upload this package until a version of > > Mesa that can make use of it is released. Then, as a a possible example, > > we could upload both to Debian experimental, and at the same time switch > > the proprietary Nvidia drivers to use it, and see how it works. When > > fglrx gets there too, we should then be able to stop using > > glx-alternatives-* packages. > > > > My proposal for the packaging itself can be found on pkg-nvidia's git > > [5]. Given upstream doesn't seem to do release tagging, I'm using the > > 0~ format. I split each .so in an individual binary > > and -dbg package, called *-glvnd[-dbg], plus a common libglvnd-dev. > > Figuring out precisely the licensing was the fun part, as the code is a > > mixture of Expat, MIT-like, BSD 1-clause and 3-clause, GPL3 and > > GNU-permissive :-) > > > > Comments? Opinions? ACKs/NACKs? > > packaging available at > > git://git.debian.org/pkg-xorg/lib/libglvnd.git > > but since it hasn't been of any use there was no ITP filed, so thanks > for that :) > > it's not final of course, tests fail and there are probably other issues > too.. Hi Timo, Sorry I forgot to do that before, but I've now passed the ball to you for the ITP :-) Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#812530: ITP: libglvnd -- Vendor-neutral OpenGL dispatch layer
Package: wnpp Severity: wishlist Owner: Luca Boccassi * Package name: libglvnd Version : 0~20160122 Upstream Author : NVIDIA Corporation * URL : https://github.com/NVIDIA/libglvnd * License : MIT Programming Lang: C Description : Vendor-neutral OpenGL dispatch layer libglvnd is a Vendor-neutral dispatch layer for arbitrating OpenGL API calls between multiple vendors on a per-screen basis. Currently, only the GLX window-system API and OpenGL are supported, but in the future this library may support EGL and OpenGL ES as well. I am one of the pkg-nvidia maintainers, and we would like to use this ITP to start a discussion about packaging libglvnd with the maintainers of Mesa, X and fglrx. As you might have read news about, NVIDIA has been working on an open source (MIT-like license) vendor-neutral dispatch layer for OpenGL. They have now declared it stable, and their proprietary graphics driver started using it in version 361 [1]. It has been reported that AMD is interested in supporting this library too [2]. Finally, following a discussion on the upstream Mesa mailing list [3], it has been reported that work is in progress in Mesa too to support this library [4]. Our proposal would be to wait to upload this package until a version of Mesa that can make use of it is released. Then, as a a possible example, we could upload both to Debian experimental, and at the same time switch the proprietary Nvidia drivers to use it, and see how it works. When fglrx gets there too, we should then be able to stop using glx-alternatives-* packages. My proposal for the packaging itself can be found on pkg-nvidia's git [5]. Given upstream doesn't seem to do release tagging, I'm using the 0~ format. I split each .so in an individual binary and -dbg package, called *-glvnd[-dbg], plus a common libglvnd-dev. Figuring out precisely the licensing was the fun part, as the code is a mixture of Expat, MIT-like, BSD 1-clause and 3-clause, GPL3 and GNU-permissive :-) Comments? Opinions? ACKs/NACKs? Kind regards, Luca Boccassi [1] https://devtalk.nvidia.com/default/topic/908423 [2] http://www.phoronix.com/scan.php?page=news_item&px=AMD-Looking-At-GLVND [3] http://lists.freedesktop.org/archives/mesa-dev/2015-September/095856.html [4] http://www.phoronix.com/scan.php?page=news_item&px=Mesa-Will-Do-GLVND [5] https://anonscm.debian.org/cgit/pkg-nvidia/libglvnd.git signature.asc Description: This is a digitally signed message part
Bug#630761: RFP: libczmq -- High-level C binding for ZeroMQ
On Fri, 2015-07-31 at 11:20 +0200, Alessandro Ghedini wrote: > So, now the package looks good. Please set the target distribution to > "unstable" > in the changelog and I'll upload. Just read the notification that the package is now in the New Queue [1], thank you very much for taking care of it! Kind regards, Luca Boccassi Brocade Communications Systems [1] https://ftp-master.debian.org/new/czmq_3.0.2-1.html signature.asc Description: This is a digitally signed message part
Bug#630761: RFP: libczmq -- High-level C binding for ZeroMQ
On Fri, 2015-07-31 at 11:20 +0200, Alessandro Ghedini wrote: > On Thu, Jul 30, 2015 at 08:24:34PM +0100, Luca Boccassi wrote: > > On Thu, 2015-07-30 at 16:58 +0200, Alessandro Ghedini wrote: > > > * The -dev package should just be named libczmq-dev (i.e. without > > > the version), > > > this way next time the project bumps the SONAME it'll be easier > > > to do the > > > transition (you won't have to update all the reverse build > > > dependencies). > > > > > > * Same goes for -dbg, but it's less important in that case. > > > > Reasoning for this choice was to follow what libzmq does, since the > > maintainer is making both libzmq1 and libzmq3 (and libzmq5 in > > experimental) available at the same time, and I thought in the > > future > > I'd do the same for libczmq. > > FWIW, being the one who originally packaged the zeromq and zeromq3 > packages, > the reason why I kept them separate was that some of the reverse > dependencies > of libzmq-dev did not build with the newer version, so both had to be > kept in > the archive. Otherwise I would have just renamed libzmq1 to libzmq3 > and kept > the same -dev, -dbg and source package names. Ah I see, makes sense. Thanks for the explanation. > > > * The README.source doesn't really provide any useful > > > information, so it can > > > be removed (also, since the dh-autoreconf plugin is used, the > > > tarball > > > generated from GitHub would probably work as well). > > > > I added it since there is a discrepancy between the tarballs on the > > official website and Github, and to explain it. > > > > If it is all right with you, I would rather keep using the tarball > > from > > the website > > Yeah, that's fine. My point was that you don't really need to justify > why you > used one tarball instead of the other, so the README.source file is > useless > (the debian/watch file already tells people where the tarball comes > from). Ok, makes sense, removed. > > > * No need to override the debian-watch-may-check-gpg-signature > > > lintian warning > > > (but it's not a problem if you want to do it anyway...). > > > > It was giving a warning on the Mentors upload page, so I added it. > > I'd > > like to keep it overridden if you don't mind :-) > > Sure, no problem. > > So, now the package looks good. Please set the target distribution to > "unstable" > in the changelog and I'll upload. Changed to unstable and added you in the Uploaders field, tagged and pushed. Thank you very much, I really appreciate your help! Kind regards, Luca Boccassi Brocade Communications Systems -- 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/1438336119.21726.2.ca...@gmail.com
Bug#630761: RFP: libczmq -- High-level C binding for ZeroMQ
On Thu, 2015-07-30 at 16:58 +0200, Alessandro Ghedini wrote: > On Thu, Jul 23, 2015 at 03:58:55AM +0100, Luca Boccassi wrote: > > owner 630761 luca.bocca...@gmail.com > > thanks > > Note that you need to CC cont...@bugs.debian.org for this to work, or you can > use the "Control" pseudo-header. Silly me, thought I CC'ed it and didn't go back to check. Thanks for the reminder! > So, I had a look at the package and here are a few notes: > > * The changelog entries should be merged into a single one since it would be > the first upload for the package. There's no need to list all the changes > there either, the "Initial release" message with the closed bug is enough. Done. I kept only 2 entries, one for each patch, as I think it's useful information for a Changelog, if it's all right with you. > * The -dev package should just be named libczmq-dev (i.e. without the > version), > this way next time the project bumps the SONAME it'll be easier to do the > transition (you won't have to update all the reverse build dependencies). > > * Same goes for -dbg, but it's less important in that case. Reasoning for this choice was to follow what libzmq does, since the maintainer is making both libzmq1 and libzmq3 (and libzmq5 in experimental) available at the same time, and I thought in the future I'd do the same for libczmq. But thinking about it, the key difference is that upstream still maintains older versions of libzmq, but there is only one branch in libczmq, older versions did not get bugfix releases in the past so probably it won't happen in the future. So, done as you suggested :-) > * The Conflicts field is not needed either way since the libczmq-dev package > doesn't exist (and if you do rename the -dev package the Provides field is > not needed either). Done. > * The README.source doesn't really provide any useful information, so it can > be removed (also, since the dh-autoreconf plugin is used, the tarball > generated from GitHub would probably work as well). I added it since there is a discrepancy between the tarballs on the official website and Github, and to explain it. If it is all right with you, I would rather keep using the tarball from the website, for 2 reasons: 1) The package is smaller, and the autotools chain is already generated, which means less maintenance and faster build times for us (autoreconf is temporary, my patch has been merged so I will drop it eventually, when they do a new release). 2) At the moment, the Github tarball ships with an object file (src/foreign/sha1/sha1.o) (I sent a patch to remove it and it has been merged upstream), which means I would have to re-package it and mark it as ds, since it is against policy as far as I understand. The tarball on the website is sanitised and does not have this problem, so unintended files are less likely to fall in now or in the future. > * No need to use both autotools-dev and dh-autoreconf. autoreconf is enough. Done. But please note that, as I wrote above, once a new release happens I plan to drop autoreconf, since my patch has been merged and re-generating the autotools chain will no longer be necessary. This will be an advantage because the build system will be closer as upstream intends to, and also means faster build times and less maintenance for us. > * No need to override the debian-watch-may-check-gpg-signature lintian warning > (but it's not a problem if you want to do it anyway...). It was giving a warning on the Mentors upload page, so I added it. I'd like to keep it overridden if you don't mind :-) > * Generally it's better to license the debian/* files under the same license > of the project, in this case MPL-2.0. It seems that when the project was > relicensed from the LGPL-3+, Arnaud decided to put the debian files under > GPL-3 (without my consent...) which IMO doesn't make a lot of sense. Moved debian/* to MPL-2.0. > * You can safely remove Gergely and myself from the Uploaders list. I think > it's also safe to remove Arnaud as well since he's been inactive for a while > (he can always be added back if needed). Done. > * You might want to update the page at http://zeromq.org/distro:debian with > your name. Done. > I think that's all, though I might have missed something. Thank you very much for your feedback, it's very welcome! I also dropped libpgm-dev from the build-dep, as it is actually not needed (it's a dependency of libzmq-dev, and it pulls it in itself). I pushed all changes to the repo [1]. > So, anyway, I'm open to sponsoring the package if needed, since Arnaud seems > to > be inactive. Once you've fixed the above just ping me and I'll have another > look > (no need to upload the
Bug#630761: RFP: libczmq -- High-level C binding for ZeroMQ
owner 630761 luca.bocca...@gmail.com thanks On Thu, 9 Oct 2014 22:20:49 +0200 Arnaud Quette wrote: > retitle 630761 ITP: libczmq -- High-level C binding for ZeroMQ > owner 630761 aque...@debian.org > thanks > > Hi, > > I'm intending to take over the packaging of libczmq. > > I'll start by pushing the last stable (2.2.0) to collab-maint [0] (ready to > push). Packages are ready for upload too. > But please note that since I'm not (yet) a user of czmq, I may be missing > something. > So, any help, info, hint, test, ... will be welcome. > > For further steps, I'll need to talk with the upstream (Pieter Hintjens, > cc'ed, is the upstream leader), to get visibility on the 3.0.0 timelines > and general roadmap. > > Thanks to those of you cc'ed, for having paved the road! > > cheers, > Arno Hello, I took the liberty of upgrading the repository on Alioth [1] to CZMQ 3.0.2, and uploaded the resulting packages to Mentors [2]. I added 2 backported patches, fixed some warnings and other changes. If it is all right with you, I will take over maintenance of this package and try to find a sponsor to finally upload it to Debian. The RFP is now 4 years old! :-) I already am the maintainer of the internal build of CZMQ at Brocade, so I am already doing this job for the company. Might as well do it for the community too! Thank you very much for your work on this package. Kind regards, Luca Boccassi Brocade Communications Systems [1] http://git.debian.org/?p=collab-maint/czmq.git [2] https://mentors.debian.net/package/czmq signature.asc Description: This is a digitally signed message part
