Bug#916325: ITP: rustdoc-stripper -- Strip rustdoc comments from source code
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,pkg-rust-maintain...@alioth-lists.debian.net Package name: rustdoc-stripper Version: 0.1.5 Upstream Author: Guillaume Gomez URL: https://github.com/GuillaumeGomez/rustdoc-stripper License: Apache-2.0 Description: Strip rustdoc comments from source code rustdoc-stripper is a tool used to remove rustdoc comments from your code and save them in a comments.cmts file if you want to regenerate them.
Bug#916321: ITP: plotsauce -- Survex 3d file to XML converter
Package: wnpp Severity: wishlist Owner: Wookey * Package name: plotsauce Version : 0.1 Upstream Author : Philip Schuchardt * URL : https://github.com/vpicaver/plotsauce * License : GPL2 or later Programming Lang: C++ Description : Survex 3d file to XML converter Qt-based utility to convert Survex 3d files into XML. Survex is cave surveying software, and the .3d file is its default output format. This package is used by cavewhere (ITP:836249).
Re: Extension of Built-Using:
Hello, On Wed 12 Dec 2018 at 05:02PM +0100, Ansgar Burchardt wrote: > On Wed, 2018-12-12 at 15:12 +, Alastair McKinstry wrote: >> I've been looking at using the "Built-Using" tag for dh-fortran-mod. > > Why not a > > Fortran-Mod: gfortran-7, gfortran-8, flang-42 > > field or so? > > As another example Python has `Python-Version: 3.6, 3.7` (for packages > where this matters; don't ask me about details, I don't know much). Indeed. Now that Built-Using has been tightened, this is how this sort of thing should be handled. -- Sean Whitton signature.asc Description: PGP signature
Bug#916311: ITP: robin-map -- C++ implementation of a fast hash map and hash set
Package: wnpp Owner: Matteo F. Vescovi Severity: wishlist * Package name: robin-map Version : 0.5.0 Upstream Author : Tessil Thibaut (?) * URL or Web page : https://github.com/Tessil/robin-map/ * License : MIT (Expat) Description : C++ implementation of a fast hash map and hash set The robin-map library is a C++ implementation of a fast hash map and hash set using open-addressing and linear robin hood hashing with backward shift deletion to resolve collisions. Four classes are provided: tsl::robin_map, tsl::robin_set, tsl::robin_pg_map and tsl::robin_pg_set. The first two are faster and use a power of two growth policy, the last two use a prime growth policy instead and are able to cope better with a poor hash function. Use the prime version if there is a chance of repeating patterns in the lower bits of your hash (e.g. you are storing pointers with an identity hash function). == These few header files are only used by OpenImageIO 2.0.x at the moment and, since buildd infrastructure forbids network access, they have to be packaged and used locally. I'll be the main maintainer for this package. -- Matteo F. Vescovi signature.asc Description: PGP signature
Re: Extension of Built-Using:
On Wed, Dec 12, 2018 at 03:12:21PM +, Alastair McKinstry wrote: > The difficulty here is that Policy 7.8 requires that Built-Using: is only > used for source package tracking. This is then enforced on the upload > package checking which rejects such packages (because gfortran-8 is not a > source package; gcc-8 is the source package, but this mostly misses the > point). > > So, can Built-Using: be safely extended to use this case, and the package > checking relaxed ? The policy is pretty clear about the usage of this field. Due to the effects it's usage have on the archive and your packages, it must not be used outside of the definition. Don't miss-use existing fields for new information. Regards, Bastian -- It is a human characteristic to love little animals, especially if they're attractive in some way. -- McCoy, "The Trouble with Tribbles", stardate 4525.6
Re: Extension of Built-Using:
On Wed, 2018-12-12 at 15:12 +, Alastair McKinstry wrote: > I've been looking at using the "Built-Using" tag for dh-fortran-mod. Why not a Fortran-Mod: gfortran-7, gfortran-8, flang-42 field or so? As another example Python has `Python-Version: 3.6, 3.7` (for packages where this matters; don't ask me about details, I don't know much). Ansgar
Extension of Built-Using:
Hi,
I've been looking at using the "Built-Using" tag for dh-fortran-mod.
dh-fortran-mod is a debhelper extension for handling Fortran "mod" files
(based on an original idea from Sebastian Villemont).
These mod files are effectively pre-compiled header files, in C/C++
terms; normally stored in /usr/include, or something like it. I've been
adding a new Fortran compiler ("flang", based on LLVM) which is in the
NEW queue which is part of the driver for this. The trouble is that
"mod" files are compiler-specific, and even version of
compiler-specific. So when we moved from gfortran-7 to gfortran-8, the
'mod' files were incompatible and needed to be rebuilt. Similarly,
flangs mod files are incompatible.
So dh-fortan-mod does two things:
(1)Adds a dependency / track on which compiler was used, to enable
tracking for transitions.
(2) Puts the mod files in $fmoddir where the compiler will get them,
allowing co-installation of incompatible files.
(e.g. $fmoddir = /usr/lib/$multiarch/fortran/$fortran-mod-version, by
default).
(1) Is the issue today. My initial plan was to add eg. 'gfortran-mod-15'
to ${misc:Depends}. The trouble is, this adds a compiler dependency to a
package that is unnecessary - some packages have a Fortran interface
that has marginal numbers of users; most use the C/C++ interfaces. So,
plan B was to use Built-Using, as in:
Built-Using: gfortran-8 (= 8.2.0-6)
The difficulty here is that Policy 7.8 requires that Built-Using: is
only used for source package tracking. This is then enforced on the
upload package checking which rejects such packages (because gfortran-8
is not a source package; gcc-8 is the source package, but this mostly
misses the point).
So, can Built-Using: be safely extended to use this case, and the
package checking relaxed ?
best regards
Alastair
--
Alastair McKinstry, , ,
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.
