Fading out Tcl/Tk 8.5 from Debian
Hi fellow developers, Since Tcl/Tk 8.5 is currently at its End of Life (see [1]) I would like to start a campaign on removing it from Debian. There's a wiki page [2] with all binary packages which depend on Tcl/Tk 8.5 directly or indirectly, and with all packages which build-depend on tcl8.5-dev or tk8.5-dev. (Not all of them need patching, it's still a rough list) I'm planning to start filing bugs with suggestions on how to switch to Tcl/Tk 8.6 or may be to the currently default Tcl/Tk (which is now 8.6, but 8.7 is coming soon with fewer incompatibilities with respect to 8.6 than for 8.6 against 8.5). As for now the bugs severity will be 'important', but I plan to bump it to 'serious' before the buster's release. If there are comments or suggestions on what should I do before starting filing the bugs, please tell. [1] https://core.tcl.tk/tcl/wiki?name=Index [2] https://wiki.debian.org/Teams/DebianTclTk/TclTk85Removal Cheers! -- Sergei Golovan
Bug#887730: ITP: golang-github-google-jsonapi -- jsonapi.org style payload serializer and deserializer
Package: wnpp Severity: wishlist Owner: Sascha Steinbiss * Package name: golang-github-google-jsonapi Version : 1.0.0+git20171108.e0fc4ee-1 Upstream Author : Google * URL : https://github.com/google/jsonapi * License : MIT Programming Lang: Go Description : jsonapi.org style payload serializer and deserializer Serializer/deserializer for JSON payloads that comply to the JSON API spec in Go. Struct tags are used to annotate the struct fields in an application and then this library reads and writes JSON API output based on the tagged fields.
Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)
> "Adrian" == Adrian Bunk writes: Adrian> For many use flags the only benefit is an unused library Adrian> less on the system when the flag is disabled, and this also Adrian> applies to the proposed nosystemd profile discussed in this Adrian> bug. Agreed. Adrian> Support for nosystemd in only 95% of all libsystemd-using Adrian> packages would still result in libsystemd being installed - Adrian> if just one maintainer would refuse to apply a nosystemd Adrian> patch, the people working on nosystemd in Debian basically Adrian> have to rely on CTTE overruling the maintainer. I disagree with this. First, that's only true if the package in question is essential, or if the user needs to install the package in question. In a world where users never modify, patch or rebuild source you're absolutely right that this only provides utility if you get 100% coverage. users include organizations that are willing to rebuild packages (patching them if necessary) to meet regulatory, security, or other requirements. Users also include downstream distributions and their users who are willing to patch software. In this world, there is siginificant utility to minimizing the number of patches users apply. 95% coverage would be much easier to deal with than no support at all. I feel fairly strongly about this because I have been that downstream. I've been in situations where I was trying to get some feature into Debian or another project. I suspect my future includes a fair number of cases where the future I care about involves being able to build without some feature because doing so makes regulatory accreditation much easier for me. Perhaps it's not worth Debian's time to work with me. However I'm frustrated when you claim that this only has utility to me when Debian gets 100% coverage: minimizing divergence has real value. Does it have enough value to justify some change to Debian? I think we should consider that on a case by case basis like we always do. In the particular case of systemd, I don't have any interest in working to make it easier to build on Linux without libsystemd installed. I'd probably accept patches that did not significantly increase the complexity of my packages if they did that, but would not go write such patches.
Bug#887734: ITP: libqtshadowsocks -- Lightweight and ultra-fast shadowsocks library written in C++/Qt
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: libqtshadowsocks Version : 2.0.1 Upstream Author : Symeon Huang * URL : https://github.com/shadowsocks/libqtshadowsocks * License : LGPL-3+ Programming Lang: C++/Qt Description : Lightweight and ultra-fast shadowsocks library written in C++/Qt libQtShadowsocks provides a lightweight and fast implementation of shadowsocks protocol as described on https://shadowsocks.org . This library is written in C++ using Qt. It is one of the dependencies of the GUI shadowsocks client "shadowsocks-qt5". I intend to co-maintain it in the newly-established Debian Bridges Team on Salsa. Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part.
TTF or OTF, bad behavior on upgraded systems
Hi all, I was looking at the fonts page[1] on the wiki and it mentions: "For most uses, you’ll want TrueType (TTF) and OpenType (OTF) fonts" In fact, is it necessary to install both, or just OTF if the same font is available as both? On a system that has been upgraded from etch through several Debian versions up to stretch, I found Firefox was behaving badly, especially when printing pages containing Helvetica. It is a little chunky on screen but almost unreadable when rendered on the printer. Can anything be done to make this easier for users who have upgraded? Looking on the web page, I used "Inspect Element" to identify the font (Helvetica) and then I checked which font is used: $ fc-match helvetica helvR12-ISO8859-1.pcf.gz: "Helvetica" "Regular" That is a bitmap font in xfonts-100dpi and xfonts-75dpi on my system. I tried installing the OTF and TTF packages (which were missing) with: apt install fonts-freefont-otf fonts-freefont-ttf but that still didn't work. Next I tried adding the MS fonts with apt install ttf-mscorefonts-installer and that didn't resolve it either, next I tried sudo fc-cache -v but it was still using the PCF bitmap font. Finally, I saw the suggestion on the wiki to run: sudo dpkg-reconfigure fontconfig fontconfig-config and that fixed the problem. Can anything be done to make this easier for users who have upgraded? Regards, Daniel 1. https://wiki.debian.org/Fonts
Updating the Maintainer field in preparation for Alioth's shutdown?
According to the schedule [1], incoming mail will be disabled for mailing lists hosted at Alioth in less than 2 weeks. I am still confused about what we are recommending that maintainers and teams do, so I'm asking questions now. :) 1. Are the lists still expected to stop accepting new mail on that date? 2. I assume that efforts to provide a transitional "continuation" email system haven't been successful yet, right? 3. If a team manages to get a lists.debian.org address, it's recommended that they switch the Maintainer fields in their packages from the Alioth list address to that address, right? 4. There may eventually be a tracker.debian.org team contact service that might be a better fit for the Maintainer field than lists.debian.org but that isn't expected before the deadline, right? [1] https://wiki.debian.org/Alioth#News Thanks, Jeremy Bicha
Bug#887800: ITP: libfuture-asyncawait-perl -- deferred subroutine syntax for futures
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libfuture-asyncawait-perl Version : 0.13 Upstream Author : Paul Evans * URL : https://metacpan.org/release/Future-AsyncAwait * License : Artistic or GPL-1+ Programming Lang: Perl Description : deferred subroutine syntax for futures Future::AsyncAwait provides syntax for deferring and resuming subroutines while waiting for Futures to complete. This syntax aims to make code that performs asynchronous operations using futures look neater and more expressive than simply using then chaining and other techniques on the futures themselves. It is also a similar syntax used by a number of other languages; notably C# 5, EcmaScript 6, Python 3, and lately even Rust is considering adding it. The new syntax takes the form of two new keywords, async and await. WARNING: The actual semantics in this module are in an early state of implementation. Some things will randomly break. While it seems stable enough for small-scale development and experimental testing, don't expect to be able to use this module reliably in production yet. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Bug#887801: ITP: libsyntax-keyword-try-perl -- try/catch/finally syntax for perl
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libsyntax-keyword-try-perl Version : 0.09 Upstream Author : Paul Evans * URL : https://metacpan.org/release/Syntax-Keyword-Try * License : Artistic or GPL-1+ Programming Lang: Perl Description : try/catch/finally syntax for perl Syntax::Keyword::Try provides a syntax plugin that implements exception-handling semantics in a form familiar to users of other languages, being built on a block labeled with the try keyword, followed by at least one of a catch or finally block. As well as providing a handy syntax for this useful behaviour, this module also serves to contain a number of code examples for how to implement parser plugins and manipulate optrees to provide new syntax and behaviours for perl code. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
