Re: rust-dbus_0.8.2-3_amd64.changes REJECTED
Bastian, I'm curious why do you think a discussion in progress is a good reason enough to block my work with no actual objections to the package contents? I've waited for this package to pass a review for so long and all I get is a REJECTED? Andrej On Sun, 9 Aug 2020, at 16:10, Bastian Blank wrote: > > REJECT > > #945542 > > > > === > > Please feel free to respond to this email if you don't understand why > your files were rejected, or if you upload new files which address our > concerns. > > -- Cheers
Build-Depends-If-Available
I'm maintaining mlpack. It is able to generate julia bindings, so on architectures in which julia is available I'd like to generate julia bindings, and this requires julia to be installed at build time. I've set up debian/rules to check if julia is installed, and set configuration options appropriately. Similarly, it seems best to build the package using clang if possible, but if clang isn't available it can be built using GCC (assuming you build single threaded and roughly six hundred mysterious GCC space-saving options are set). I thought I could accomplish this with build dependencies like Build-Depends: julia | hello, ..., clang | buthead where hello and buthead are stupid little packages that are available on all architectures but would not otherwise be installed. Ugly, sure, but maybe it would get the job done. Nope! The build daemons just try to install julia and clang and fail if either's not available. I've also seen Build-Depends: julia | dpkg, ..., clang | dpkg but that also doesn't work. I could check which architectures have julia, and which have clang, and list them. Build-Depends: julia [amd64 arm64 i386 ...], clang [amd64 arm64 armel armhf i386 ...] but that makes my skin crawl because it is highly non-future-proof and violates all sorts of software engineering principles. Anybody know if there's a good solution to this problem?
Re: rust-dbus_0.8.2-3_amd64.changes REJECTED
Hi debian-devel, Summary: Team work for the win On Sun, Aug 09, 2020 at 04:16:07PM +0200, Andrej Shadura wrote: > On Sun, 9 Aug 2020, at 16:10, Bastian Blank wrote: > > > > REJECT > > > > #945542 > > > > > > > > === > > > > Please feel free to respond to this email if you don't understand why > > your files were rejected, or if you upload new files which address our > > concerns. > > > > > > Bastian, > > I'm curious why do you think a discussion in progress is a good > reason enough to block my work with no actual objections to the > package contents? > > I've waited for this package to pass a review for so long > and all I get is a REJECTED? > The clue '#945542' and "discussion in progress" is most like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945542#94 It has On Sat 2019-11-30 12:15:55 +0100, Bastian Blank wrote: > This problem is already listed since a long time in > https://ftp-master.debian.org/REJECT-FAQ.html. But reading this page, the closest thing i can find is its description of "Package Split", which reads: >>> You split a package too much or in a broken way. Well, broken or too >>> much is a wide definition, so this is a case-by-case thing, but you >>> should really think about a split before you do it. For example it >>> doesn't make any sense to split a 50k arch:all package from a 250k >>> arch:any one. Or splitting a package for only one file, depending on >>> the main package. Yes, big dependency chains can be a reason. Or big >>> documentation split into one -doc package. The point there is big. Bastian, if you meant something else, please correct me here! Then eight months past. How can we continue with where the november post is about: rust software to work in a well-established way in Debian ? Regards Geert Stappers DD -- Silence is hard to parse
Re: Build-Depends-If-Available
On Sun, Aug 09, 2020 at 03:22:20PM +0100, Barak A. Pearlmutter wrote: > I'm maintaining mlpack. It is able to generate julia bindings, so on > architectures in which julia is available I'd like to generate julia > bindings, and this requires julia to be installed at build time. I've > set up debian/rules to check if julia is installed, and set > configuration options appropriately. Similarly, it seems best to build > the package using clang if possible, but if clang isn't available it > can be built using GCC (assuming you build single threaded and roughly > six hundred mysterious GCC space-saving options are set). > > I thought I could accomplish this with build dependencies like > > Build-Depends: julia | hello, ..., clang | buthead > > where hello and buthead are stupid little packages that are available > on all architectures but would not otherwise be installed. Ugly, sure, > but maybe it would get the job done. Nope! The build daemons just try > to install julia and clang and fail if either's not available. I've > also seen > > Build-Depends: julia | dpkg, ..., clang | dpkg > > but that also doesn't work. > > I could check which architectures have julia, and which have clang, > and list them. > > Build-Depends: julia [amd64 arm64 i386 ...], clang [amd64 arm64 armel > armhf i386 ...] > > but that makes my skin crawl because it is highly non-future-proof and > violates all sorts of software engineering principles. > > Anybody know if there's a good solution to this problem? > A slightly less bad approach might be: Build-Depends: julia [! ! ...], clang [! ! ...] Regards, -Roberto -- Roberto C. Sánchez
Re: Build-Depends-If-Available
On Sun, 09 Aug 2020 at 15:22:20 +0100, Barak A. Pearlmutter wrote: > I could check which architectures have julia, and which have clang, > and list them. > > Build-Depends: julia [amd64 arm64 i386 ...], clang [amd64 arm64 armel > armhf i386 ...] > > but that makes my skin crawl because it is highly non-future-proof and > violates all sorts of software engineering principles. Unfortunately, to the best of my knowledge, this is currently the least bad thing to do. This pattern is also seen in packages that (conditionally) build-depend on valgrind, libseccomp or anything with Rust dependencies, all of which need specific porting to each new architecture. One alternative that occurs to me would be for the maintainers of the package that needs per-architecture porting (let's say src:valgrind) to provide an empty binary package like this: Package: valgrind-if-supported Architecture: any Depends: valgrind [amd64 arm64 i386 ...] which would let dependent packages have "Build-Depends: valgrind-if-supported", and then test for valgrind.pc or /usr/bin/valgrind during their configure/build step. However, that would require src:valgrind to be able to go through the motions of building for all architectures, skipping the real (upstream) build process on architectures to which it has not yet been ported, and that might be difficult to maintain long-term. smcv
Re: Build-Depends-If-Available
On Sun, Aug 09, 2020 at 03:22:20PM +0100, Barak A. Pearlmutter wrote: > I'm maintaining mlpack. It is able to generate julia bindings, so on > architectures in which julia is available I'd like to generate julia > bindings, and this requires julia to be installed at build time. I've > set up debian/rules to check if julia is installed, and set > configuration options appropriately. Similarly, it seems best to build > the package using clang if possible, but if clang isn't available it > can be built using GCC (assuming you build single threaded and roughly > six hundred mysterious GCC space-saving options are set). > > I thought I could accomplish this with build dependencies like > > Build-Depends: julia | hello, ..., clang | buthead > > where hello and buthead are stupid little packages that are available > on all architectures but would not otherwise be installed. Ugly, sure, > but maybe it would get the job done. Nope! The build daemons just try > to install julia and clang and fail if either's not available. I've > also seen > > Build-Depends: julia | dpkg, ..., clang | dpkg > > but that also doesn't work. It is intentional that the buildds consider only the first option of an alternative for dependency resoltion of build dependencies in unstable. If due to some hiccup in unstable julia is temporarily not installable, what do you prefer to happen? a) silently build without julia installed b) package build happens as soon as julia is installable again There are also similar problems that a dependency resolver might opt not to install julia when dpkg is already installed, or when some other dependencies already result in hello being installed. Or when deep inside dependency resolution installing hello produces a "better" solution than installing julia. > I could check which architectures have julia, and which have clang, > and list them. > > Build-Depends: julia [amd64 arm64 i386 ...], clang [amd64 arm64 armel > armhf i386 ...] > > but that makes my skin crawl because it is highly non-future-proof and > violates all sorts of software engineering principles. > > Anybody know if there's a good solution to this problem? For clang all release architectures and all relevant non-release architectures already provide clang, but if you want your package to build everywhere you could write clang [!alpha !hppa !ia64 !m68k !sh4 !x32] julia is actually the first package that would come into my mind for all kinds of If-Available problems: julia | 0.3.2-2 | oldoldstable | source, amd64, i386 julia | 0.4.7-6+b3| oldstable | amd64, arm64, armhf, i386, mips64el, ppc64el julia | 1.0.3+dfsg-4 | stable | source, amd64, arm64, armhf, i386, ppc64el julia | 1.4.1+dfsg-1 | unstable | source, amd64, arm64, i386 The pragmatic solution is to list the 3 architectures where julia currently builds. The software engineering solution would be a dependency package julia-or-nothing that depends depending on the architecture either on julia or nothing. cu Adrian
Re: Build-Depends-If-Available
Hi, Le dim. 9 août 2020 à 18:16, Simon McVittie a écrit : > Unfortunately, to the best of my knowledge, this is currently the least bad > thing to do. > if the current practices/software doesn't give enough leeway, perhaps we should seek to improve the situation. How would that fly if there were a B-dep list for the source package, and optional B-dep lists for binary packages? Cheers, JP >
Bug#968140: ITP: emd -- Enhanced Markdown template processor
Package: wnpp Severity: wishlist Owner: Tong Sun * Package name: emd Version : 1.0.1-1 Upstream Author : mh-cbon * URL : https://github.com/mh-cbon/emd * License : Expat Programming Lang: Go Description : Enhanced Markdown template processor emd is the Enhanced Markdown template processor. It can save people from tedious jobs updating their README.md files by automating all those that can be automated, especially for cli based programs.
Re: Build-Depends-If-Available
On Sun, 9 Aug 2020 at 17:05, Adrian Bunk wrote: > The pragmatic solution is to list the 3 architectures where julia > currently builds. Okay, thanks for the hints, Adrian. That's what I'll do for now. > The software engineering solution would be a dependency package > julia-or-nothing that depends depending on the architecture either > on julia or nothing. This is a recurring problem, and seems slated to grow in severity as Debian tentacles inself into more heterogeneous environments and as software systems become larger and more complicated with more options. Machine learning systems in particular can be built against various sorts of hardware support libraries which phase in and out of fashion with shocking speed. So manually generating julia-if-available, and (thanks to Simon McVittie for the examples) valgrind-if-available, and libseccomp-if-available, etc, seems to scale poorly, and would be a lot of work. I suppose we could generate them automatically, like -dbg packages. Blech! They'd also pollute the archive. So let me step back and try to look at the problem a bit more globally. I understand what you're saying, and indeed trying to encode "Build-Depends-If-Available: foo" as "Build-Depends: foo | something" is a bad idea from the get-go. After all, foo can have three states on an architecture: installable, unavailable, or available-but-uninstallable-for-some-reason. And we want different behaviour in the three cases: build with it, build without it, or delay-building-until-installable. And we can't shoehorn those three things into the binary logic of "foo | something". On the other hand, the maintainer isn't really in the right position to figure out what architectures foo is available or should be installable on. The buildd's are the place where that information is really manifest. (And we might even make a stripped-down build, or a derived distribution without systemd, and want packages to adjust appropriately to that build environment as much as possible.) Making up a whole new control field, like Build-Depends-If-Available:, seems like overkill. But we already have a certain level of abstraction in architectures, e.g., we can say foo [linux] to get foo on systems running the linux kernel. How about we add this kind of thing as an abstract architecture. So one could write perhaps "Build-Depends: julia [has-julia]" to get julia iff a julia package exists. I think that would be pretty easy to implement (no installability check or backtracking; just check if a package by that name exists). It would also give more flexibility than a generic "Build-Depends: julia [IF-IT-EXISTS]" in case there are support packages necessary only if something else is available. Like "Build-Depends: chicken [has-chicken], swig [has-chicken]" to pull in swig if you're generating chicken bindings, which makes sense only if chicken is on that architecture. TLDR: suggest encoding as abstract architecture. Build-Depends: valgrind [has-valgrind], julia [has-julia]
Re: Build-Depends-If-Available
On Sun, Aug 09, 2020 at 06:28:50PM +0100, Barak A. Pearlmutter wrote: >... > "Build-Depends-If-Available: foo" as "Build-Depends: foo | something" > is a bad idea from the get-go. After all, foo can have three states on > an architecture: installable, unavailable, or > available-but-uninstallable-for-some-reason. And we want different > behaviour in the three cases: build with it, build without it, or > delay-building-until-installable. And we can't shoehorn those three > things into the binary logic of "foo | something". >... binary-all packages are available on all architectures, but many are only installable on some architectures. >... > Like "Build-Depends: chicken [has-chicken], swig [has-chicken]" to pull in > swig if you're generating chicken bindings, which makes sense only if > chicken is on that architecture. >... The chicken and chicken-dev binary package were dropped in 2006, only chicken-bin and libchicken-dev are in unstable. Build dependencies broken when transitional packages or provides disappear are easy to find and fix, silent dropping of functionality can cause nasty problems. >... > I think that would be pretty easy to implement >... The number of tools parsing build dependencies or doing dependency resolution is larger than you might expect. cu Adrian
Bug#968146: ITP: golang-github-johanneskaufmann-html-to-markdown -- Convert HTML to Markdown
Package: wnpp Severity: wishlist Owner: Tong Sun * Package name: golang-github-johanneskaufmann-html-to-markdown Version : 1.1.0-1 Upstream Author : Johannes Kaufmann * URL : https://github.com/JohannesKaufmann/html-to-markdown * License : Expat Programming Lang: Go Description : Convert HTML to Markdown html-to-markdown converts HTML into Markdown with Go. It is using an HTML Parser to avoid the use of regexp as much as possible so as to allow it to be used for cases where the input is totally unknown. It even works with entire websites and can be extended through rules. This package is a prerequisite for the upcoming package of html2md.
Re: Build-Depends-If-Available
On Sun, 9 Aug 2020 at 19:01, Adrian Bunk wrote: > The number of tools parsing build dependencies or doing dependency > resolution is larger than you might expect. Yeah, I can only imagine. And they're not all in one great big git repo either! That's one reason I thought pushing it into the architecture field might make sense: code dealing with architectures has at least some abstraction already, because architectures are a moving target, and are also a bit complicated. In this case, you could put a clause into "dpkg-architecture --equal" to make an architecture of "has-foo" just check (using the right API) if "apt policy foo" has a candidate, and catch a significant fraction of the cases. Re the "chicken no longer exists, use chicken-bin" bit-rot issue, lintian could raise a flag for a [has-foo] arch when foo doesn't exist in the target distribution on any architecture. We already have that issue for binary packages with "Recommends:" and "Suggests:".
Bug#968151: ITP: python-xmlschema -- implementation of XML Schema for Python
Package: wnpp Severity: wishlist Owner: Christian Kastner * Package name: python-xmlschema Version : 1.2.2 Upstream Author : SISSA (Scuola Internazionale Superiore di Studi Avanzati) * URL : https://github.com/sissaschool/xmlschema/ * License : MIT Programming Lang: Python Description : implementation of XML Schema for Python This library includes the following features: * Full XSD 1.0 and XSD 1.1 support * Building of XML schema objects from XSD files * Validation of XML instances against XSD schemas * Decoding of XML data into Python data and to JSON * Encoding of Python data and JSON to XML * Data decoding and encoding ruled by converter classes * An XPath based API for finding schema's elements and attributes * Support of XSD validation modes strict/lax/skip * Remote attacks protection by default using an XMLParser that forbids entities This is a dependency of a newer pytest version and will be maintained under the umbrella of the Debian Python Modules Team.
Bug#968152: ITP: python-iniconfig -- brain-dead simple parsing of ini files
Package: wnpp Severity: wishlist Owner: Christian Kastner * Package name: python-iniconfig Version : 1.0.1 Upstream Author : Ronny Pfannschmidt * URL : https://github.com/RonnyPfannschmidt/iniconfig * License : MIT Programming Lang: Python Description : brain-dead simple parsing of ini files iniconfig is a small and simple INI-file parser module having a unique set of features: * tested against Python2.4 across to Python3.2, Jython, PyPy * maintains order of sections and entries * supports multi-line values with or without line-continuations * supports "#" comments everywhere * raises errors with proper line-numbers * no bells and whistles like automatic substitutions * iniconfig raises an Error if two sections have the same name. This is a dependency of a newer pytest version and will be maintained under the umbrella of the Debian Python Modules Team.
