Re: proposed MBF: packages still using source format 1.0
Hi, On Tue, Mar 15, 2022 at 3:46 AM Ian Jackson wrote: > > Debian is not upstream, so it has a Debian revision. The package is > maintained in git, and the source package is very small and it is not > uploaded frequently. So we use a native source format. This means > that we must use format 1.0 because dpkg hates 3.0 native with debian > revision. I do not understand the word "must" in that sentence, nor do I agree with the word "hate". I'll reiterate my call for a compromise: Let's deprecate source format 1.0 in exchange for relaxed version strings. It will streamline our tooling and reduce the cognitive load on new maintainers. > Yes. People complain about the Debian packaging toolchain being too > complex or too confusing. This is one of such cases. As has been stated > countless times, this subverts the semantics of both the source and > version formats. At least we only have one case remaining, the even > more senseless 1.0 non-native source with native version was turned > into an error with dpkg 1.20.1. Recall that dpkg-source currently needs > to use heuristics to decide whether to use an orig tarball + diff or not > for format 1.0. :( I'll buy both you, Ian and Guillem, a beer next time I see you. The dispute has been going on for too long. Or, is it a battle over the soul of Dpkg between the current maintainer and its inventor? For good measure, Lucas is invited, too. I think a negotiated peace is superior to yet another unhappy interaction with the Technical Committee. Why do we have to put them into such a difficult position every time? Kind regards, Felix Lechner
Re: proposed MBF: packages still using source format 1.0
Hi, > I think we can all agree upon bumping the lintian severity to > warning. I am not sure there is unanimous support. Instead, I would like to propose the following compromise (as I have before). > 1.0 native is sometimes better than 3.0 (native) because dpkg-source > refuses to build a 3.0 native package with a Debian revision in its > version number. > 1.0-with-diff has the following advantage over 3.0 (quilt): > The extracted source tree does not contain a diff. The inclusion of > the diff *inside* the source tree (which happens with "3.0 (quilt)" > whether or not single-debian-patch is specified) causes all manner of > problems: it means that only certain states of the extracted tree are > valid. Ian and Guillem: How about we deprecate source format 1.0 in exchange for relaxing the version strings? In the new source format, nativeness is explicit [1] so the version acrobatics are no longer needed. > yes, we should convert all native packages in our archive, > the idea of a native package has been obsoleted for long. As someone who co-maintains several Debian-internal tools, I am not quite sure yet. Maybe let's take one step at a time? Thanks! Kind regards Felix Lechner [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953554#25
Re: Seeking consensus for some changes in adduser
Hi, On Fri, Mar 11, 2022 at 1:16 PM Marc Haber wrote: > > wishlist bug for a lintian check. Implemented in Lintian, and pending for the next release: https://salsa.debian.org/lintian/lintian/-/commit/66ea726de5f34cf693b7d01a297f495abf650588 Thank you, everyone, for your comments! Kind regards Felix Lechner
Re: lintian groff-message warning "can't set the locale"
Hi Nick, On Sun, Oct 25, 2020 at 6:23 PM Nick Black wrote: > > My Salsa CI pipeline is blowing up in the lintian step, with > lots of warnings of the form: Following an upgrade of the Salsa runners to bullseye [1] the bug you reported here originally was closed. [2] Thank you for using Lintian! Kind regards, Felix Lechner [1] https://salsa.debian.org/salsa/support/-/issues/277#note_299577 [2] https://bugs.debian.org/973313
Re: Proposed mass bug filing: packages without support for build-arch and build-indep
Hi, On Fri, Nov 5, 2021 at 1:23 PM Lucas Nussbaum wrote: > > Unfortunately this is only a warning in lintian, which might explain > why so many packages are still affected. After a reasonably broad and balanced discussion on Libera#debian-devel, those targets are now required. [1] The Archive team still runs an older Lintian version (and may for a while) so there should be plenty of time for uploads without auto-rejection. > in that case let's wait At the time of writing, 264 sources were still affected [2] which was down from 421 in November. It worked out more or less to the monthly decline of 85 sources originally predicted by N. Thykier in 2013. [3] Lintian's tag description was amended with the simplest possible fix, which has two-lines. [4] They are reasonable addition to sources that do not receive a lot of attention. > file these bugs with severity "important" and then raise the severity a > month later The bugs were already serious, and therefore release-critical, when I found them. Thank you, everyone, for making the best operating system the world has ever seen. Let's keep it together! Kind regards Felix Lechner [1] https://salsa.debian.org/lintian/lintian/-/commit/23f836f91c03b78df76743fc002a105403a5bc14 [2] Scroll down, https://lintian.debian.org/tags/debian-rules-missing-recommended-target [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657390#45 [4] https://lintian.debian.org/tags/debian-rules-missing-required-target
Re: d/watch for Gitea's new dynamic pages
Hi Yadd, On Sun, Nov 7, 2021 at 1:08 PM Yadd wrote: > > Yes, but USCAN_SYMLINK is a local parameter I wondered about that, but in the interest of progress implemented the experimental and pedantic tag 'prefer-uscan-symlink'. [1] The description includes the disclaimer: "Please check with your team before making changes to sources you maintain together. There are circumstances when the 'filenamemangle' option is better." Will you and mapreri please hash it out, and instruct the Lintian maintainers? The compromise may be a better tag description. Alternatively, would it be better to set USCAN_SYMLINK in d/watch (instead of ~/.devscripts)? Thank you! Kind regards Felix Lechner [1] https://salsa.debian.org/lintian/lintian/-/commit/d336b6f732fb0059a522f19dbd1e322864c821a9
Re: d/watch for Gitea's new dynamic pages
Hi
On Thu, Nov 4, 2021 at 12:48 PM Johannes Schauer Marin Rodrigues
wrote:
>
> > filenamemangle=s/.+\/tag\/(\d\S+)$/foot-$1\.tar\.gz/ \
> filenamemangle=s{.*/(.*)}{@PACKAGE@-$1.tar.gz} \
mapreri pointed out that 'USCAN_SYMLINK=rename' is superior to
'filenamemangle' in both of our cases.
Lintian will also suggest it very soon (more generally).
Kind regards
Felix Lechner
Re: Lintian and Dpkg's :any multiarch qualifier
Hi Johannes, On Thu, Nov 4, 2021 at 2:35 AM Johannes Schauer Marin Rodrigues wrote: > it seems the only tool that calls :any an "acceptor" is lintian I think the multiarch spec is confusing because of its terminology. It's been a hurdle for many people. > still wasn't sure what you are exactly asking No worries! You were not affected. Thanks for writing! Kind regards Felix Lechner
d/watch for Gitea's new dynamic pages
Hi, For anyone having issues with Gitea's new dynamic download links [1] here is a debian/watch file that works. Kind regards Felix Lechner [1] https://github.com/go-gitea/gitea/issues/16354 * * * version=4 opts=\ downloadurlmangle=s/\/releases\/tag\/(\d\S+)$/\/archive\/$1\.tar\.gz/,\ filenamemangle=s/.+\/tag\/(\d\S+)$/foot-$1\.tar\.gz/ \ https://codeberg.org/dnkl/foot/releases .*/releases/tag/(\d\S+)
Lintian and Dpkg's :any multiarch acceptor
Hi, For a brief time between October 1 and October 15, Lintian gave potentially confusing advice on some build prerequisites. [1] The :any multiarch acceptor—a rarely used feature some other tools call the "muliarch qualifier"—was originally not implemented at all [2] and then implemented incorrectly. [3] Many people do not even know about the feature. To my knowledge it works now. Here are two questions: 1. Did anyone find the latest Lintian versions (2.109.0 and up) confusing as to whether the :any should be included? The material you would have encountered includes both the context offered by Lintian (the extra information after the tag) and any relevant tag descriptions. 2. Should Lintian issue any advice when it sees the :any multiarch acceptor? If so, for which packages? It might allow maintainers to undo erroneous advice they may have been given, although many folks use the feature legitimately, as well. Thank you! Kind regards Felix Lechner [1] The affected versions were 2.107.0 and 2.108.0. [2] https://bugs.debian.org/994902 [3] https://bugs.debian.org/995981
Re: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system
Hi, On Thu, Aug 19, 2021 at 2:57 AM Luca Boccassi wrote: > > updating Lintian would be the best outcome. The corresponding bug in Lintian [1] will be resolved by changing the expected prefix for service files to /usr/lib once a backport of debhelper is available in bullseye, as described here. [2] Kind regards Felix Lechner [1] https://bugs.debian.org/992465 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992711#5
Re: About lintian
Hi Norbert, On Sun, Jan 17, 2021 at 5:02 AM Norbert Preining wrote: > > As part of this rework and the ongoing development, you said you have plans > to set up a test version of the Lintian web application on non-Debian > infrastructure. How is that going, Felix? With the kind help of the good folks at DSA [1] Lintian's experimental web application—still labeled "beta"—is now the official web presence. [2] Please bear with us as we optimize the deployment and implement additional features for you. I personally do not follow mailing lists often. For further discussion or suggestions, please open an issue on Salsa [3] or write to the Lintian maintainers. [4] Thanks to everyone who contributed to the redeployment of Lintian's web presence! It was a project-wide effort. The current maintainers owe an especially profound debt of gratitude to all past maintainers, on whose dedication and brilliant work all present and future contributions are based. Thank you! Please stay healthy, and keep washing your hands! Kind regards Felix Lechner [1] https://dsa.debian.org/ [2] https://lintian.debian.org [3] https://salsa.debian.org/lintian/detagtive/-/issues [4] https://lists.debian.org/debian-lint-maint/
Re: About lintian
Dear Norbert, On Sun, Jan 17, 2021 at 5:02 AM Norbert Preining wrote: > > you said you have plans to set up a test version of the Lintian web > application on non-Debian infrastructure. How is that going, Felix? A beta version of Lintian's new service is now live at lintian.debian.*net*. [1] The Node-based web app is backed by 90 GB of PostgreSQL data. I used connection pools, but the site will load slowly until I get more memory. Please be patient—I hope it is worth your while. The pages are superior to what we had previously because they show your override comments. The code base can also be expanded more easily. For any issues or suggestions please find instructions in the page footers. I am still adding features, however, and only replied because of the upcoming release. Please star(*) our repository [2] on Salsa if you like it. Thanks! Please have a good weekend! Kind regards Felix Lechner [1] https://lintian.debian.net/ [2] https://salsa.debian.org/lintian/detagtive
Bug#983467: ITP: wolftpm -- Portable TPM 2.0 Library
Package: wnpp Severity: wishlist Owner: Felix Lechner X-Debbugs-CC: debian-devel@lists.debian.org * Package name: wolftpm Version : 2.0.0 Upstream Author : David Garske * URL : https://www.wolfssl.com/products/wolftpm/ * License : GPL-2+ Programming Lang: C Description : Portable TPM 2.0 Library wolfTPM is a portable, open-source TPM 2.0 stack with backward API compatibility, designed for embedded use. It is highly portable, and has native support for Linux. RTOS and bare metal environments can take advantage of a single IO callback for SPI hardware interface, no external dependencies, and compact code size with low resource usage. wolfTPM offers API wrappers to help with complex TPM operations like attestation and examples to help with complex cryptographic processes like the generation of Certificate Signing Request (CSR) using a TPM. - Provides all TPM 2.0 API’s in compliance with the specification. - Backward API compatibility. - Includes wrappers for the most common use cases, like Key Generation, NV memory, RSA encrypt/decrypt, ECC sign/verify, ECDH, and others. - Provides examples for the advanced use cases, like Attestation (TPM 2.0 Quote), Certificate Signing Request (CSR), generation of signed timestamp (TPM 2.0 GetTime), and others. wolfSSL has support for chipsets including ARM, Intel, Motorola, mbed, NXP/Freescale, Microchip (PIC32)/Atmel, STMicroelectronics (STM32F2/F4), Analog Devices, Texas Instruments, and more. I will maintain this package going forward. Kind regards Felix Lechner
Bug#983450: ITP: wolfmqtt -- Lightweight client library for the MQTT protocol
Package: wnpp Severity: wishlist Owner: Felix Lechner X-Debbugs-CC: debian-devel@lists.debian.org * Package name: wolfmqtt Version : 1.8.0 Upstream Author : David Garske * URL : https://www.wolfssl.com/products/wolfmqtt/ * License : GPL-2+ Programming Lang: C Description : Lightweight client library for the MQTT protocol MQTT (Message Queuing Telemetry Transport) is a lightweight open messaging protocol that was developed for constrained environments such as M2M (Machine to Machine) and IoT (Internet of Things), where a small code footprint is required. MQTT is based on the Pub/Sub messaging principle of publishing messages and subscribing to topics. The protocol efficiently packs messages to minimize overhead. The wolfMQTT library is a client implementation of the MQTT written in C. It supports all Packet Types, all Quality of Service (QoS) levels 0-2 and supports SSL/TLS. This implementation provides support for MQTT v5.0 and is based on MQTT v3.1.1. Additionally, there is also client support for MQTT-SN (Sensor Network). - Supports MQTT specifications v3.1.1 and v5.0 - Support for MQTT-SN - Supports all client side packet types and protocol options - QoS Levels 0-2 (guaranteed delivery) - Message integrity, security are still available - Single threaded model and single message callback - Written in Native C89 with portability/compatibility in mind - Space conscience design (Compiled size is about 3.6kB) - User manual with build instructions, example overview, and API documentation - Example MQTT client implementations - Network interface is abstracted via callbacks for extensibility - Packet parsing encoding/decoding structured for custom use - Minimal external dependencies (strlen, memcpy, memset) - Detailed error checking/handling - Doxygen style inline documentation - Fewer than 1200 lines of well structured C code - Tested on multiple variants of MQTT broker servers, QoS levels 0-2 with/without TLS - FreeRTOS+TCP support wolfSSL has support for chipsets including ARM, Intel, Motorola, mbed, NXP/Freescale, Microchip (PIC32)/Atmel, STMicroelectronics (STM32F2/F4), Analog Devices, Texas Instruments, and more. I will maintain this package going forward. Kind regards Felix Lechner
Bug#983449: ITP: wolfssh -- Lightweight SSH Library
Package: wnpp Severity: wishlist Owner: Felix Lechner X-Debbugs-CC: debian-devel@lists.debian.org * Package name: wolfssh Version : 1.4.6 Upstream Author : John Safranek * URL : https://www.wolfssl.com/products/wolfssh/ * License : GPL-3+ Programming Lang: C Description : Lightweight SSH Library The wolfSSH library is a lightweight SSHv2 client and server library written in ANSI C and targeted for embedded, RTOS, and resource-constrained environments—primarily because of its small size, speed, and feature set. It is also often used in standard operating environments. Features: - SSH v2.0 (client and server) - Minimum footprint size of 33kB - Runtime memory usage between 1.4 and 2kB, not including a configurable receive buffer - Multiple Hashing Functions: SHA-1, SHA-2 (SHA-256, SHA-384, SHA-512), BLAKE2b - Block, Stream, and Authenticated Ciphers: AES (CBC, CTR, GCM, CCM), Camellia - Public Key Options: RSA, DH, EDH, NTRU - ECC Support (ECDH and ECDSA with curves: NISTP256, NISTP384, NISTP521 - Curve25519 and Ed25519 - Client authentication support (RSA key, password) - SCP support - SFTP support - Port forwarding support (client-side) - Simple API - PEM and DER certificate support - Hardware Cryptography Support: Intel AES-NI support, Intel AVX1/2, RDRAND, RDSEED, Cavium NITROX support, STM32F2/F4 hardware crypto support, Freescale CAU / mmCAU / SEC, Microchip PIC32MZ, support for MPLAB Harmony on PIC32 - Echoserver functionality - Interop Tested Against: OpenSSH, Tera term, PuTTY, Dropbear, Firezilla, BitVise wolfSSH is built for maximum portability and is generally very easy to compile on new platforms. wolfSSH has support for chipsets including ARM, Intel, Motorola, mbed, NXP/Freescale, Microchip (PIC32)/Atmel, STMicroelectronics (STM32F2/F4), Analog Devices, Texas Instruments, and more. I will maintain this package going forward. Kind regards Felix Lechner
Re: About lintian
Hi Antonio, On Tue, Jan 19, 2021 at 4:43 AM Antonio Terceiro wrote: > > My hope is that this, and other use cases, could be enabled by > collaborating on existing infrastructure, instead of creating yet > another one. I totally agree with you. I would like to spend some time looking at your code, if you have time to point me in the right direction. Perhaps planned improvements to the Lintian runner are better implemented in your code base. Thanks! Kind regards Felix Lechner
Re: About lintian
Hi Raphaël, On Tue, Jan 19, 2021 at 3:27 AM Raphael Hertzog wrote: > > From my (relatively remote) point of view, ci.debian.net seems really > very basic in terms of features related to scheduling of jobs. Inspired by an early peek into your own ideas of a codenamed piece of vaporware I wrote what I think is a generalized runner. I do not know how it compares to the CI infrastructure, although it is probably even simpler. Kind regards Felix Lechner
Re: About lintian
Hi Pierre-Elliott, On Mon, Jan 18, 2021 at 5:00 AM Pierre-Elliott Bécue wrote: > > As I said on that time, I'd be glad to provide help and > support should Felix feel the need for some. I do not recall our most recent exchanges as quite so positive, but I would be happy to read you into some of the new software (off-list, please). Kind regards Felix Lechner
Re: About lintian
Hi Lucas, On Mon, Jan 18, 2021 at 2:31 AM Lucas Nussbaum wrote: > > I agree that a service that provides an overview of the status regarding > lintian for the whole archive would be useful (for example, to identify > packages that need some area of work inside a team). This functionality is not going away. I had to address a series of issues to make the runners stable. Lintian itself no longer crashes or stalls for any package in unstable or experimental. (I did not try other "releases".) The runners, which allocate and manage resources while tags are generated, also no longer crash and can now operate without blacklists (although some packages like Firefox with 300,000 source files consume extraordinary resources to generate tags that are unlikely to be fixed). For tag reporting, I had to address a series of encoding issues. Lintian now emits JSON. The website is actually relatively simple when it comes to replacing the old lintian.d.o. The use of dynamic Javascript backed by a database, however, opens up the use of many more features than the old website, which used Perl to generate static HTML for about 40,000 pages. The new website also deals automatically with incremental changes in the database, which I think is a huge advantage. > If there's a lack of interest/motivation to redesign lintian.d.o as a > standalone service, maybe a simpler architecture to explore would be to > build it on top of UDD Having just designed a Postgres database for this purpose, I do not believe UDD has the proper table layout but you are welcome to try. Kind regards Felix Lechner
Re: About lintian
Hi Norbert, First of all, please accept my apologies for responding late. I subscribe to d-d but filter lists for later perusal. Thanks to Lucas Nussbaum for pointing me here! Due to the number of messages already posted in this thread, I will respond—with the best of ability—to each message separately. Thank you also for being cautious about people's emotions. I endure a fair amount of abuse for working on Lintian and am likewise reluctant to discuss it in such a broad forum, but here we are. David Bremner once said that people should remember Lintian isn't their boss. (David, please correct me if I fumbled that.) My goal is for Lintian to provide friendly packaging advice for the benefit of maintainers. Nothing more and nothing less. On Sun, Jan 17, 2021 at 5:02 AM Norbert Preining wrote: > > In the past year, many changes in lintian tag names occurred, along with some > tag removals. While we often change tag names (or combine tags etc.), the majority of the renames people talk about seems to stem from two bug reports by third parties asking that we make tag names more consistent (bug numbers are available, if needed). As I remember, I studied the related checks—some of which were quite dense or antique—for ten days before settling on new names. Alas, that effort earned mostly anger and, in one case, even disapproval from a bug filer. > While it seems quite normal for lintian as a tool to evolve a > lot, with the upcoming freeze, do you see a reasonable time frame during which > these kind of changes could be postponed to help people having lintian-clean > packages remain lintian-clean till after release? I am totally open to suggestions, although I think that being "Lintian-clean" is overrated. My goal is not to point out faults like a heavenly prosecutor but to help people avoid common problems. Tag names do not make a difference in that regard. I am also not sure that a tag rename by itself could ever trigger new tags, i.e taint a package that was previously "Lintian-clean". > On the infrastructure side, you mentioned on #debian-qa that in your > opinion, lintian is best run in a CI pipeline instead of on the > lintian.d.o service. While this is certainly true, do you plan to keep > the functionality on your rework of lintian.d.o? Yes, in fact the goal for the new lintian.d.o is much broader (and hopefully not too ambitious). The website should ultimately allow detailed research into which packages trigger particular tags (including various filtering functions and automatic notifications). The website should also offer ways to flag ineffective tags, i.e. those with a high proportion of false positives based on the prevalence of overrides. With tongue in cheek, I may one day add a voting system for the funniest, or perhaps the most bogus, override comment. People should also be able to flag false positives with a few clicks (perhaps triggering a bug report) or generate overrides for their packages for download. My remark about Salsa CI probably applied more to maintainers of single packages, and less to people concerned with quality assurance of large package families such as yourself. In any event, the Lintian job on Salsa broke when the (privileged) runners were upgraded to Debian 10. Something in Lintian triggers apparmor. Despite the prominence of the failures I have been reluctant to explore them. I am not sure that the Salsa and the Salsa CI teams, at whose juncture the apparmor process resides, have the best relationship. On top of that, my principal collaborator on Salsa CI, Iñaki Malerba, is busy with a new job. > As part of this rework and the ongoing development, you said you have plans > to set up a test version of the Lintian web application on non-Debian > infrastructure. I have a Node.js version that almost replaces the old lintian.d.o. My primary challenge is the amount of data Lintian now generates. Uploading results to Postgres via bulk JSON takes several hours. The domain lintian.debian.net resolves to a non-Debian server with my experimental version, but it's a work-in-progress and the data is not current. I could probably finish it in a week if I had the time. > The > intention of this mail is to understand the current Lintian's maintainers POV > on what Lintian is and should be I do not think I answered that question except for my favorite tagline: "Lintian provides friendly packaging advice for the benefit of maintainers." Thank you for your interest in Lintian! Kind regards, Felix Lechner
Re: lintian groff-message warning "can't set the locale"
Hi, There is now Bug#973313. Please comment there going forward. Thanks! * * * On Mon, Oct 26, 2020 at 1:53 PM Colin Watson wrote: > > If all else fails then setting MAN_NO_LOCALE_WARNING=1 may be a viable > workaround. Colin, thanks for the workaround. We will spend a few more days trying to find the bug first. Kind regards Felix Lechner
Re: lintian groff-message warning "can't set the locale"
Hi Nick, On Mon, Oct 26, 2020 at 5:11 AM Nick Black wrote: > > C.UTF-8 sounds like the right way to go. As noted in the issue tracker [1], Lintian already sets LC_ALL to C.UTF-8 [2] in a sanitized environment, but we do not currently set LANG. That would have been my next step, except these issues do not occur in a clean chroot for unstable and are therefore more likely related to Salsa or Salsa CI. Kind regards Felix Lechner [1] https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/182 [2] https://salsa.debian.org/lintian/lintian/-/blob/master/checks/documentation/manual.pm#L281
Re: lintian groff-message warning "can't set the locale"
Hi Nick, On Sun, Oct 25, 2020 at 6:23 PM Nick Black wrote: > > Is this due to having supra-ascii UTF8 characters in my man > pages? It's not a problem with your package. Lintian's own pipeline is likewise affected, even though our test suite completes fine in an unstable chroot. The issue is being tracked here: https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/182 Kind regards Felix Lechner
Condorcet Internet Voting Service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 No one should hold a grievance for a year. The survey's author is welcome to send me an email with details. I would be happy to take up the issue with relevant parts of Debian without revealing the sender's identity. Kind regards Felix Lechner -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEE8E0cIgLi+g0BiFTarFipTxFhjuAFAl4SlQtfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEYw NEQxQzIyMDJFMkZBMEQwMTg4NTREQUFDNThBOTRGMTE2MThFRTAACgkQrFipTxFh juBWYA//XeJGBEH8O7dLzZa6OKSkgzKYN40tE2aAw+UX/YwASjCv99JHMW9PFQFo 8h8R/lj3X+X8rdOMdM+J26FKIFQ6PawInkej+0l7G+n0HPtUlHH3Reyt5xbNDmdq Osnsw37SmkvkwSA7vb6RQZOnoCdAycW3c0kv8ivOERasFIsrjcjmdPHqpqKXeLFX 8eLLUuf1qBzDxLe/3qa8xqpmHXUJNHyheHe6ZxInjG1ECwzrJH7RlSWRywE8e7xC /ahkYavvSHHjUFG8plCl+sg11+YGRwm2CuEzL4YWK7exzuRUNPtug1vjFqoZLjgZ 75KpmcxwCJ2TwCmjcWGq3ubBZRPY8a3oY57WIusMRkOFnXirTw07GYEbzNhySh/s K+Z1KOkvKBYT0vbAF0UT/RQsqJCnDrTI6KsmJ5nOdwQJUP1rpzAqxX7rK74Vdafm OtRPKfK1L1zRUWhCJvoFEaPWBeI9rAtJvxXLrRV+q3nzim7t1EZxInoJOE7c2nsN IOgDUEyVd8J46E2fyYgiALFWuz72eVrYSfGV2PtbckkuQsARAfEc6nzKNajXhV1V TPSNWwqGU4Lrc+u7X94GXOru74tuxY2k/D3ge+OkGktt/FnUsQhtCeulInHnOfzt jFA7ZXJlCDxm9DzvYNydWVUg+uK7THEBb3ZmEa1yQGZsCzwbE5Y= =1vEV -END PGP SIGNATURE-
RFP: lintian-sort -- reproducibly sort the Lintian tool's output
Hi, > The lintian-sort tool reorders the messages reported by the lintian(1) > Debian package analysis tool so that they are kept in the same order > between successive builds. > Wouldn't it be much better to apply this change to lintian itself? Lintian now orders tags before printing. That resolves the most relevant feature requested here. The output was already deterministic, but depended on the order in which checks that had been sorted were run: https://bugs.debian.org/944807 This is the Lintian commit message: https://salsa.debian.org/lintian/lintian/commit/e0f76bdd6bf57d84ba2e7b478973ddc8b84df950 Besides the bug in Lintian, this message also closes an RFP bug that had been cloned. Please re-open the RFP bug if we still need a second tool. To help make Lintian better, please file merge requests on Salsa. Thanks! Kind regards, Felix Lechner
Bug#945407: ITP: golang-github-sabhiram-go-gitignore -- A gitignore parser for go
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-sabhiram-go-gitignore Version : 1.0.2-1 Upstream Author : Shaba Abhiram * URL : https://github.com/sabhiram/go-gitignore * License : MIT Programming Lang: Go Description : A gitignore parser for go go-gitignore Build Status (https://travis-ci.org/sabhiram/go-gitignore) Coverage Status (https://coveralls.io/github/sabhiram/go-gitignore?branch=master) . A gitignore parser for Go Install shell go get github.com/sabhiram/go-gitignore . Usage For a quick sample of how to use this library, check out the tests under ignore_test.go. Required prerequisite for Gocryptfs starting with version 1.7.1, which is currently unpackaged.
Namespaces for Lintian Tags
Hi, The Lintian team has been working hard to make Lintian better. Some call it a policy enforcer, but from our perspective Lintian just provides friendly packaging advice for the benefit of maintainers. A pending change may affect anyone who looks at Lintian's output. We would like to get your thoughts before taking the next step. I am about to introduce private namespaces for tags. Many tags already point to the check that issued them. (For those who don't know, a 'check' in Lintian is a module that issues a tag.) Namespaces would formalize the relationship. For example, the tag 'debian-copyright-file-uses-obsolete-national-encoding' might become 'national-encoding@debian/copyright'. There are many motivations: 1. Shortens tag names. 2. Points to the code that issued the tag. 3. Frees up name space (good tags are rare). 4. Multiple checks can use the same tag in different contexts (i.e. 'spelling'). 5. Preempts name conflicts in case some check-writing is delegated to expert teams. 6. Quicker to split large checks when components reuse tag names. 7. Brings consistency between Lintian and custom profile users, such pkg-perl-tools and pkg-js-tools, who already have private namespaces. The change is technically easy. (Lintian even has a way to track renamed tags for overrides.) On an optical level, however, the change will affect a lot of people. It could even cause headaches for some users, for example in derivatives. We would like to solicit your input. Please provide your thoughts, perspectives and suggestions by amending the bug report at #943525. Thank you! Kind regards, Felix Lechner P.S. If you run Lintian in a GNOME terminal, you should now see some hyperlinks.
Bug#906986: ITP: golang-github-xanzy-go-gitlab -- Simple and uniform GitLab API for Go
Package: wnpp Severity: wishlist Owner: Felix Lechner * Package name: golang-github-xanzy-go-gitlab Version : 0.10.8 Upstream Author : Sander van Harmelen * URL : https://github.com/xanzy/go-github/ * License : Apache-2.0 Programming Lang: Go Description : Simple and uniform GitLab API for Go This package provides a GitLab API that enables Go programs to interact with GitLab in a simple and uniform way. It covers most of the existing Gitlab API calls and is updated regularly to add new or missing endpoints. A golang library, it is a prerequisite for git-lab (#898246). The package will be maintained as part of the go-team on Salsa. Thank you!
Bug#786574: ITP: msx264 -- Mediastreamer plugin for the H.264 video codec
Package: wnpp Severity: wishlist Owner: Felix Lechner * Package name: msx264 Version : 1.5.1 Upstream Author : Simon Morlat * URL : http://www.linphone.org * License : GPL-2+ Programming Lang: C Description : Mediastreamer plugin for the H.264 video codec This dynamically loaded codec wrapper is part of Linphone. It will be maintained in the Debian VOIP Team. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150522233203.23915.57096.report...@lechner-server.us-core.com
Bug#785480: ITP: bcg729 -- ITU G.729 Annex A compatible audio codec
Package: wnpp Severity: wishlist Owner: Felix Lechner * Package name: bcg729 Version : 1.0.0 Upstream Author : Felix Lechner * URL : http://www.linphone.org/technical-corner/bcg729/overview * License : GPL-2+, BSD-2-clause Programming Lang: C Description : ITU G.729 Annex A compatible audio codec Bcg729 is an open source implementation of the ITU G729 Annex A speech codec. Written in C 99, the library is fully portable. It runs on many platforms, including ARM and x86. . Bcg729 supports concurrent channels encoding/decoding for multi call application such as conferencing. . The project was developed as part of mediastreamer2, Linphone's media processing engine. It also contains the glue forintegration into Linphone/mediastreamer2. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150516210126.21572.61996.report...@lechner-server.us-core.com
Bug#785461: ITP: bzrtp -- Library for the ZRTP key exchange protocol
Package: wnpp Severity: wishlist Owner: Felix Lechner * Package name: bzrtp Version : 1.0.2 Upstream Author : Simon Morlat * URL : http://www.linphone.org/ * License : GPL-2+ Programming Lang: C Description : Library for the ZRTP key exchange protocol This package is part of Linphone, but is packaged separately. Like Linphone it will be maintained by the Debian VOIP Team. This new library enables certain encrypted communications in Linphone. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150516154753.14249.34307.report...@lechner-server.us-core.com
Bug#744082: ITP: wolfssl-jni -- Java interface for CyaSSL
Package: wnpp Severity: wishlist Owner: Felix Lechner * Package name: wolfssl-jni Version : 1.0 Upstream Author : Chris Conlon * URL : http://www.wolfssl.com/ * License : GPL-2+ Programming Lang: Java, C Description : Java interface for CyaSSL The wolfSSL JNI package provides a Java interface to the wolfSSL SSL/TLS library, providing Java applications with SSL/TLS support up to the current TLS 1.2 and DTLS 1.2 standards. In addition to the interface, the package provides an example client and server, written in Java, which utilize the interface to make an SSL/TLS connection. The interface is provided through the use of JNI and standard Java practices. CyaSSL is an SSL library offering a compatibility layer for OpenSSL. It is popular with developers of embedded systems. 'cyassl' is a prerequisite for this JNI package. The two packages are released separately. I plan to maintain both of them. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140409222535.22642.35421.report...@lechner-server.us-core.com
Bug#737830: ITP: belle-sip -- SIP stack from the Linphone team
Package: wnpp Severity: wishlist Owner: Felix Lechner * Package name: belle-sip Version : 1.2.4 Upstream Author : Jehan Monnier * URL : http://www.linphone.org/ * License : GPL2+, GPL3+, BSD, MIT, zlib Programming Lang: C and ANTLR Description : SIP stack from the Linphone team Belle-Sip is a new SIP stack (RFC3261) developed by the Linphone team. Belle-Sip supports multiple transports at the same time, has a dual IPv6 and IPv4 stack, is fully asynchronous and implements the +sip.instance and alias parameters. It also handles network disconnections better, offers a privacy API and supports rich presence. SIP/TLS is handled by the lightweight polarssl library (as opposed to openssl). Relevance: This library is required to build the latest Linphone beta version 3.6.99. It will probably replace libosip and libeXosip, a more mature SIP stack, in future Linphone releases. Maintenance: I plan to submit the package to the Debian VOIP Team and hope to contribute to maintenance going forward. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140206110008.11252.99011.reportbug@wu-desktop
Bug#733060: ITP: svxlink -- voice services system for ham radio use
Package: wnpp
Severity: wishlist
Owner: Felix Lechner
Package name: svxlink
Version : 13.12
Upstream Author : Tobias Blomberg
URL : http://sourceforge.net/projects/svxlink/
License : GPLv2 dated June 1991, except as noted below
Programming Lang: C++
Description : voice services system for ham radio use
The svxLINK server provides access to a ham radio transceiver via the
EchoLink® protocol. A graphical client, Qtel, is included.
EchoLink® allows licensed amateur radio operators to communicate over the
Internet, including remote access to station equipment. The server can act as a
repeater controller or operate on a simplex channel. Based on a modular design,
the server can be configured to provide voice mail and other services.
Copyright and license details:
Most of the software is released under the GNU General Public License.
Exceptions are:
(1) WOL (Wide Open License, please see below):
async/audio/AudioDecimator.*
async/audio/AudioInterpolator.*
(2) Custom license (Aladdin Enterprises, please see below):
echolib/md5.{c,h}
(1) Original code by by Grant R. Griffin modified by Tobias Blomberg / SM0SVX.
Provided by Iowegian's "dspGuru" service (http://www.dspguru.com). Copyright
2001, Iowegian International Corporation (http://www.iowegian.com)
The Wide Open License (WOL)
Permission to use, copy, modify, distribute and sell this software and its
documentation for any purpose is hereby granted without fee, provided that the
above copyright notice and this license appear in all source copies. THIS
SOFTWARE IS PROVIDED "AS IS" WITHOUT EXPRESS OR IMPLIED WARRANTY OF ANY KIND.
See http://www.dspguru.com/wol.htm for more information.
(2) Copyright (C) 1999, 2000, 2002 Aladdin Enterprises. All rights reserved.
This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.
Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software
in a product, an acknowledgment in the product documentation would be
appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.
L. Peter Deutsch
gh...@aladdin.com
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20131224203141.12424.14294.reportbug@lechner-server
