Bug#926444: ITP: golang-github-minio-blake2b-simd -- Fast hashing using pure Go implementation of BLAKE2b with SIMD instructions
Package: wnpp Severity: wishlist Owner: Andrius Merkys X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name : golang-github-minio-blake2b-simd Version : 0.0~git20160723.3f5f724-1 Upstream Author : Object Storage for AI * URL : https://github.com/minio/blake2b-simd * License : Apache-2.0 Programming Lang: Go Description : Fast hashing using pure Go implementation of BLAKE2b with SIMD instructions BLAKE2b-SIMD Pure Go implementation of BLAKE2b using SIMD optimizations. Introduction This package was initially based on the pure go BLAKE2b (https://github.com/dchest/blake2b) implementation of Dmitry Chestnykh and merged with the (cgo dependent) AVX optimized BLAKE2 (https://github.com/codahale/blake2) implementation (which in turn is based on the official implementation (https://github.com/BLAKE2/BLAKE2). It does so by using Go's Assembler (https://golang.org/doc/asm) for amd64 architectures with a golang only fallback for other architectures. golang-github-minio-blake2b-simd is a dependency of go-ipfs, which is to be packaged [1] [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779893 -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Re: duplicate popularity-contest ID
On 2019-08-05 15:29, Bill Allombert wrote: > However, the popularity-constest server <https://popcon.debian.org> > receives a lot of submissions with identical popcon ID, which cause them > to be treated as a single submission. I would suspect cloned VMs to have identical popcon IDs. In this case the collation of identical IDs would be a desirable property, IMO. Best, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Re: watch files and .gitattributes export-ignore
Hi Jean-Michel, On 2019-12-12 10:48, Jean-Michel Vourgère wrote: > Ideally, I'd like to generate the orig.tar from a "git clone". But uscan > don't > support that. Do you mean uscan's 'mode=git' does honor .gitattributes? I wasn't aware of that. Best, Andrius signature.asc Description: OpenPGP digital signature
Re: Lintian status reporting on packages overview broken?
Hi,
On 2020-06-18 10:21, Gard Spreemann wrote:
> It seems to me that the "Lintian E+W" column on the QA packages overview
> page currently incorrectly shows a checkmark even when there are Lintian
> warnings for a package. Is this a known bug?
In addition to that, "Watch" column displays dashes ("-") only.
Best,
Andrius
Re: Lintian status reporting on packages overview broken?
On 2020-06-18 11:18, Sebastiaan Couwenberg wrote:
> On 6/18/20 10:15 AM, mer...@debian.org wrote:
>> In addition to that, "Watch" column displays dashes ("-") only.
> That's due to #932296
Thanks a lot for the explanation!
Best,
Andrius
Bug#1053782: RFP: node-vite -- Next Generation Frontend Tooling
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org Control: block 1042095 by -1 * Package name: node-vite Version : 4.4.11 Upstream Author : Evan You * URL : https://github.com/vitejs/vite * License : Expat Programming Lang: JavaScript Description : Next Generation Frontend Tooling Vite is a frontend build tool, including development server and build command bundling code with Rollup, pre-configured to output optimized static assets for production. Vite is needed to produce CSS and JS files for sphinx-press-theme. An estimate of work needed to package Vite: $ npm2deb depends vite Dependencies: NPM Debian vite (4.4.11) None ├─ esbuild (^0.18.10) None ├─ fsevents (~2.3.2) None ├─ postcss (^8.4.27) node-postcss (8.4.20+~cs8.0.23-1) └─ rollup (^3.27.1) node-rollup (3.28.0-2) Build dependencies: NPM Debian @ampproject/remapping (^2.2.1) node-ampproject-remapping (2.2.0+~cs5.15.37-1) @babel/parser (^7.22.7) None @babel/types (^7.22.5)node-babel (6.26.0+repack-3~bpo10+1) @jridgewell/trace-mapping (^0.3.18) None @rollup/plugin-alias (^4.0.4) node-rollup-plugin-alias (5.0.0~ds-1) @rollup/plugin-commonjs (^25.0.3) node-rollup-plugin-commonjs (25.0.4+ds1-1) @rollup/plugin-dynamic-import-vars (^2.0.4) None @rollup/plugin-json (^6.0.0) node-rollup-plugin-json (6.0.0+ds1-2) @rollup/plugin-node-resolve (15.1.0) node-rollup-plugin-node-resolve (15.1.0+ds-1) @rollup/plugin-typescript (^11.1.2) node-rollup-plugin-typescript (11.1.2~ds+~1.0.1-1) @rollup/pluginutils (^5.0.2) node-rollup-pluginutils (5.0.2~ds+~2.8.2-1) @types/escape-html (^1.0.2) None @types/pnpapi (^0.0.2)None acorn (^8.10.0) acorn (8.8.1+ds+~cs25.17.7-2) acorn-walk (^8.2.0) None cac (^6.7.14) None chokidar (^3.5.3) node-chokidar (3.5.3-2) connect (^3.7.0) node-connect (3.7.0+~3.4.35-1) connect-history-api-fallback (^2.0.0) None convert-source-map (^2.0.0) node-convert-source-map (1.9.0+~1.5.2-1) cors (^2.8.5) node-cors (2.8.5-1) cross-spawn (^7.0.3) node-cross-spawn (5.1.0-2) debug (^4.3.4)node-debug (4.3.4+~cs4.1.7-1) dep-types (link:./src/types) None dotenv (^16.3.1) None dotenv-expand (^9.0.0)None es-module-lexer (^1.3.0) node-es-module-lexer (1.1.0+dfsg-2) escape-html (^1.0.3) node-escape-html (1.0.3+~1.0.2-2) estree-walker (^3.0.3)node-estree-walker (2.0.2-5) etag (^1.8.1) node-etag (1.8.1-3) fast-glob (^3.3.1)None http-proxy (^1.18.1) node-http-proxy (1.18.1-8) json-stable-stringify (^1.0.2) node-json-stable-stringify (1.0.2+repack1+~cs1.0.34-2) launch-editor-middleware (^2.6.0) None lightningcss (^1.21.5)None magic-string (^0.30.2)node-magic-string (0.30.1-1) micromatch (^4.0.5) node-micromatch (4.0.5+~4.0.2-1) mlly (^1.4.0) None mrmime (^1.0.1) None okie (^1.0.1) None open (^8.4.2) node-open (8.4.0-6) parse5 (^7.1.2) node-parse5 (7.1.2+dfsg-2) periscopic (^3.1.0) None picocolors (^1.0.0) node-picocolors (1.0.0-4) picomatch (^2.3.1)node-anymatch (3.1.3+~cs4.6.1-2) postcss-import (^15.1.0) None postcss-load-config (^4.0.1) node-postcss-load-config (2.1.2+~cs6.0.0-1) postcss-modules (^6.0.0) node-postcss-modules (6.0.0+~cs5.1.3-2) resolve.exports (^2.0.2) None rollup-plugin-license (^3.0.1)None sirv (^2.0.3) None source-map-support (^0.5.21) node-source-map-support (0.5.21+ds+~0.5.4-1) strip-ansi (^7.1.0) node-strip-ansi (6.0.1-2) strip-literal (^1.3.0)None tsconfck (^2.1.2) None tslib (^2.6.1)node-tslib (2.4.1-1) types (link:./types)
Re: Bug#1053782: RFP: node-vite -- Next Generation Frontend Tooling
Hi, On 2023-10-11 09:44, Simon Richter wrote: On 10/11/23 15:30, Andrius Merkys wrote: Description : Next Generation Frontend Tooling Yes, but what does it do? Why would I pick this out of a package list if I didn't know the name of the package already? The following line in the RFP says: Vite is a frontend build tool, including development server and build command bundling code with Rollup, pre-configured to output optimized static assets for production. Andrius
Re: Bug#1053782: RFP: node-vite -- Next Generation Frontend Tooling
Hi, On 2023-10-11 10:18, Simon Richter wrote: On 10/11/23 16:00, Andrius Merkys wrote: Yes, but what does it do? Why would I pick this out of a package list if I didn't know the name of the package already? The following line in the RFP says: Vite is a frontend build tool, including development server and build command bundling code with Rollup, pre-configured to output optimized static assets for production. That is the long description. I have to view the details for a package to access the long description, and it still does not tell me anything about the package that would help me make a decision whether I want to install it. The most information is contained in the package name, which suggests that this belongs to the NodeJS ecosystem, and this is obvious to me only because I know that ecosystem exists and uses this naming convention within Debian. I have no idea how it fits into that system, and which specific problems it solves, so even if I were a NodeJS user, I still could not use this to decide whether I want to install it. The target audience for descriptions is "users who do not know the software yet." You are right, I could have written a clearer description. I will rewrite it to better explain the purpose of the package. Thanks, Andrius
Re: DebGPT: how LLM can help debian development? demo available.
Hi, On 2024-01-03 00:07, M. Zhou wrote: Following what has been discussed in d-project in an offtopic subthread, I prepared some demo on imagined use cases to leverage LLMs to help debian development. https://salsa.debian.org/deeplearning-team/debgpt I find this pretty impressive. Thanks a lot for working on it. [...] You can also tell me more ideas on how we can interact with LLM for debian-specific tasks. It is generally not difficult to implement. The difficulty stems from the hardware capacity, and hence the context length. Thus, the client program has to fetch the most-relevant information regarding the task. To me the most time consuming task in Debian recently is the Python transitions. I wonder whether DebGPT could help with them. Maybe there are other, non-Debian-specific GPTs for this task, but I would prefer a Debian one. Andrius
Re: DebGPT: how LLM can help debian development? demo available.
On 2024-01-03 11:12, Andrey Rakhmatullin wrote: On Wed, Jan 03, 2024 at 09:58:33AM +0200, Andrius Merkys wrote: To me the most time consuming task in Debian recently is the Python transitions. I wonder whether DebGPT could help with them. Maybe there are other, non-Debian-specific GPTs for this task, but I would prefer a Debian one. As "transitions" is too broad, can you list actual problems you spend time on for them? Mostly failing tests, and mostly due to API changes between subsequent Python 3.x versions. Best, Andrius
Re: 64-bit time_t transition in progress
Hello, On 2024-02-02 19:46, Steve Langasek wrote: If there is no new version in experimental, or there is a new version BUT the patch against unstable applies cleanly to the version in experimental (no fuzz), we upload to experimental. Otherwise, patches are sent to the BTS but we skip uploading to experimental and will NMU directly to unstable at the next stage (handling binary NEW there). Given libfoo1 in unstable and libfoo2 in experimental, I assume libfoo1t64 will be NMU'd directly to unstable. After that happens, will it be OK to upload libfoo2 to unstable (as part of libfoo transition), or will it have to carry t64 suffix, i.e., libfoo2t64? Best, Andrius
Re: 64-bit time_t transition in progress
Hi, On 2024-02-05 09:05, Steve Langasek wrote: On Mon, Feb 05, 2024 at 08:57:50AM +0200, Andrius Merkys wrote: Given libfoo1 in unstable and libfoo2 in experimental, I assume libfoo1t64 will be NMU'd directly to unstable. After that happens, will it be OK to upload libfoo2 to unstable (as part of libfoo transition), or will it have to carry t64 suffix, i.e., libfoo2t64? In my view, it's fine then to upload libfoo2 to unstable without the t64 suffix as ABI compatibility with experimental is not really required. In fact, none of the t64 binaries currently being uploaded to experimental have the final ABI either, we're just using experimental to clear binary NEW. Got it, thanks for clarification. Best, Andrius
Re: Any volunteers for lintian co-maintenance?
Hello, On 2024-05-10 17:35, Nilesh Patra wrote: On Fri, May 10, 2024 at 04:06:15PM +0200, Andreas Tille wrote: Lintian is important for me. For the past few months, I have been reviewing and merging MRs and pushing small fixes of my own. I am not a proficient perl programmer and hence I am not the best person to be doing so. But then, nobody else was doing it and I decided to do at least a little bit. Lintian is important to me likewise. It taught me a lot when I was learning to package, and today it is still an indispensable tool for me, helping to avoid rookie mistakes, typos and other mistakes. If someone would like to dedicatedly contribute sometime there, it'd be really great. The package is not in a very good shape right now. Do you mean bugs on bugs.d.o, or are there other issues? I personally feel motivated to implement new features in lintian or go after low hanging fruits, but I am somewhat driven away by the need to understand lintian's internals. Is there a documentation on the data/control flow, or class diagrams? This would help me a lot. Best, Andrius
Re: Any volunteers for lintian co-maintenance?
Hi Nilesh, On 2024-05-10 21:04, Nilesh Patra wrote: On Fri, May 10, 2024 at 05:58:24PM +0300, Andrius Merkys wrote: Do you mean bugs on bugs.d.o, or are there other issues? As you may have seen in the other emails, there are performance issues. Other than that, there are 2 open RC bugs right now (fixed in salsa but not uploaded I don't make uploads for lintian). A pile of MRs are pending for reviews at many points in time. Thanks for the explanation. I personally feel motivated to implement new features in lintian or go after low hanging fruits, but I am somewhat driven away by the need to understand lintian's internals. Is there a documentation on the data/control flow, or class diagrams? This would help me a lot. Not that I know of, I suppose Axel/Bastian may be able answer this. I see. I believe the documentation would help attracting more volunteers. AFAIK, lintian's code is clearly written and nicely organised, and that is enough for fixing localised issues or introducing new features similar to already existing ones. However, before making larger changes one has to familiarise themself with the code, and that takes time, especially for people not well-versed in Perl. Best wishes, Andrius
Re: MBF: Building packages in the (not so distant) future
Hello, On 2024-05-26 20:35, Santiago Vila wrote: After we make a stable release, there is usually a constant flow of packages which start to FTBFS due to "time bombs", i.e. expired SSL certificates used in tests and other similar reasons. Just FYI, there is a suggestion to implement lintian hint for expired SSL certificates (#1036769) with an ongoing implementation [1]. Now the hint is raised for SSL certificates which are outdated at the moment of running lintian, but it could as well check for some time in future. [1] https://salsa.debian.org/lintian/lintian/-/merge_requests/511#note_495288 Best, Andrius
Bug#1072515: general: Repeating cracking sound in headphones when nothing is playing.
Hi Christian, On 2024-06-03 11:38, Christian Böck wrote: when using headphones with my laptop (Thinkpad W550s) I get a repeating cracking (~1sec intervalls) when nothing is playing. I have a similar issue on a workstation with Ubuntu 22.04. What is your operating system version? I believe the issue started manifesting once I installed Jack. Do you have Jack on your machine? Andrius
Re: deduplicating jquery/
On 2020-12-01 11:00, PICCA Frederic-Emmanuel wrote: > What about doing something similar to sphinx. > Create a package with the doxygen jquery and link to files of this package > for all documentations generated via doxygen. > provide a dh_doxygen to do this link like dh_sphinxdoc +1 In addition, with every new release of doxygen and its jquery, all -doc packages built with dh_doxygen would need rebuilding. Best, Andrius
Re: Network and KDE lost after testing upgrade
Hi Xavier, On Sun, 10 Jan 2021, 14:56 Xavier, wrote: > After a testing update and a reboot, I lost (at least) network and KDE > sessions. Is there a known issue? > This week I had network-manager removed by an upgrade on unstable, might be related. I don't know about the issue, but installing network-manager from .deb fixed it. Andrius >
Re: Added hundreds of media types to /etc/mime.types
On 2021-01-09 01:22, Charles Plessy wrote: > In the latest CI log of lighttpd on amd64, there is: > > defconfigFAIL stderr: Duplicate mimetype: '.sdf' => > 'application/vnd.stardivision.math' (already have 'application/vnd.Kinar'), > merging to 'application/octet-stream' > > Unfortunately, `sdf` is a legitimate extension for both media types. I > see that /usr/share/lighttpd/create-mime.conf.pl already has a section > for resolving such conflicts, so I think that the best solution is > to implement a choice in this script. In /etc/mime.types, 'sdf' is also mentioned as an extension for 'chemical/x-mdl-sdfile'. I wonder why this is not reported as a conflict? Andrius
Re: Using release-monitoring.org [was: uscan roadmap]
On 2021-12-03 00:51, Paul Wise wrote: > The one issue I can think of with using release-monitoring.org is that > Debian becomes more reliant on an external service, while currently we > are completely independent of other distros for version checking. > > Converting the release-monitoring.org check to a watch file might be an > alternative to using it directly that maintains our independence. +1 Best, Andrius
Bug#1002470: RFP: opensearch -- search engine, fork of Elasticsearch
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org Control: block -1 by 926714 * Package name: opensearch Version : 1.1.0 Upstream Author : Amazon Web Services * URL : https://www.opensearch.org * License : Apache-2.0 Programming Lang: Java Description : F/LOSS search and analytics suite Starting with v7.11, Elasticsearch is dual-licensed under SSPL and Elastic License, neither of them are DFSG-compatible. Amazon Web Services forked the Apache-2.0 Elasticsearch source and released OpenSearch as F/LOSS fork of it. Since there is some initial compatibility with Elasticsearch promised, OpenSearch might serve as drop-in replacement for the former. Thus some F/LOSS software which depended on Elasticsearch (RDF4J, for example) could be made to rely on OpenSearch instead. The biggest blocker for now is gradle (see #926714). Build system requires at least v6.6. Andrius
Re: maven doc
Hi Yadd, On 2022-05-30 14:50, Yadd wrote: > I'd like to package a Java software built with maven. Is there an up-to-date > documentation on how to use maven in Debian packages ? Not sure how about the most extensive and up-to-date documentation, but Wiki page for maven-debian-helper [1] looks good to me. I personally learnt to use it from examples abundant in Java Team. [1] https://wiki.debian.org/Java/MavenDebianHelper Hope this helps, Andrius
Re: debian/watch: Ignoring pre-release on GittHub
On 2022-12-08 12:59, Kentaro Hayashi wrote: 2022年12月5日(月) 16:41 Stephan Lachnit : You can try to take a look at the GitHub API, e.g. [1]. Inside is an `prerelease` entry. Not sure how easy this is to implement in uscan though. Cheers, Stephan [1]: https://api.github.com/repos/lutris/lutris/releases?per_page=100 Thanks, Instead of writing complicated rules, it may be better to support such an API in uscan internals. I believe redirectors are more appropriate for that. Internals of uscan are relatively uncomplicated and do not know any site-specific APIs. Andrius
Re: dh_auto_test fails and I do not understand why
Hello, On 2022-12-15 11:20, Filippo Rusconi wrote: I have uploaded a package yesterday. That package does not have any dh_auto_test target in d/rules. The builds all fail, as described here: https://buildd.debian.org/status/package.php?p=minexpert2 and I do not understand why. Any soul to help me with this question? I have just stumbled on the same while building a new package with javahelper: install: cannot change owner and permissions of ‘debian/_jh_build.lucene9-9.4.2’: Operation not permitted jh_build: error: install -m0755 -o 0 -g 0 -d debian/_jh_build.lucene9-9.4.2 returned exit code 1 However, I have no idea why '-o 0 -g 0' options are used. They do not seem to be used before. Andrius
Re: dh_auto_test fails and I do not understand why
On 2022-12-15 11:44, Sebastiaan Couwenberg wrote: On 12/15/22 10:34, Andrius Merkys wrote: However, I have no idea why '-o 0 -g 0' options are used. They do not seem to be used before. Recent changes in debhelper, see: https://salsa.debian.org/debian/debhelper/-/commit/ca66cf4bc74fe31b3d5c8131788e7fdd8731 https://salsa.debian.org/debian/debhelper/-/commit/e41b7d15c4b005def732cb9f82ed14171499689d Thanks for prompt response. Thus the issue is resolved in debhelper 13.11.3. Best, Andrius
Re: dh_auto_test fails and I do not understand why
Hi Niels, Thanks for the explanation (snipped here). On 2022-12-15 11:59, Niels Thykier wrote: Your options include: * Migrate to "Rules-Requires-Root: no" if you can Great, this indeed gets around the issue. Best wishes, Andrius
Re: Packaging text licenses
Hi Baptiste, On Sat, 14 Dec 2019, 13:04 Baptiste BEAUPLAT, wrote: > I had to dig up to CreativeCommons's github repository to find the text > version. (I didn't want to copy/paste the HTML version on their website). > It's https://creativecommons.org/licenses/by/4.0/legalcode.txt. One just has to add .txt suffix to legal code link URL. Andrius
Re: Debian for dummies and the elderly
On 2020-08-24 12:47, Holger Levsen wrote: > On Sat, Aug 22, 2020 at 04:58:18PM +0200, guillaume philippe wrote: >> It could be interesting to fork this os to make a simple computer and >> a debian for dummies and the elderly. > I find this slightly offensive. "Debian for dummies and women". "Debian > for dummies and French people". etc. > > Your intentions are good, but please think about different phrasing. +1 Best, Andrius
Re: Bug#515856: Debian Policy 4.1.4.0 released
Hi, On 07/03/2018 01:20 PM, Bill Allombert wrote: > How many packages are using Files-Excluded ? 1781 Using codesearch.d.o [1] to look through the debian/copyright files, then running curl -s https://codesearch.debian.net/results/2d02749753b89563/packages.json | jq -r '.Packages[]' | wc -l gets the list of the source packages. Best, Andrius [1] https://codesearch.debian.net/search?q=path%3Adebian%2Fcopyright+Files-Excluded&perpkg=1 -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#864355: ITP: cod-tools -- tools for manipulation of Crystallographic Information Format v1.1 and v2.0 files
Package: wnpp Severity: wishlist Owner: Andrius Merkys * Package name: cod-tools Version : 2.0 Upstream Author : Saulius Gražulis , Andrius Merkys , Antanas Vaitkus * URL : http://wiki.crystallography.net/cod-tools * License : GPL 2.0 Programming Lang: C, Perl, Python, Shell Description : tools for manipulation of Crystallographic Information Format v1.1 and v2.0 files The package contains Crystallographic Information Format (CIF) v1.1 and v2.0 parser (parser of CIF v1.1 is compared to other parsers in Merkys et al. 2016, doi:10.1107/S1600576715022396) and scripts for manipulating CIF files. Package includes CIF parser bindings for C, Perl and Python. Tools from the package are used in the development and maintenance of the Crystallography Open Database (http://www.crystallography.net/cod/, usage described in Gražulis et al. 2009, doi:10.1107/S0021889809016690 and Gražulis et al. 2015, doi:10.1107/S1600576714025904). The tools follow the same filter-like usage pattern as Netpbm. As I am an upstream author, I plan to maintain the package myself. As this is my first submission, I will need a sponsor.
Bug#878422: ITP: voronota -- Voronoi diagram-based tool to find atom contacts
Package: wnpp Severity: wishlist Owner: Andrius Merkys * Package name: voronota Version : 1.18.1877 Upstream Author : Kliment Olechnovič * URL : https://bitbucket.org/kliment/voronota * License : MIT Programming Lang: C++ Description : Voronoi diagram-based tool to find atom contacts The analysis of macromolecular structures often requires a comprehensive definition of atomic neighborhoods. Such a definition can be based on the Voronoi diagram of balls, where each ball represents an atom of some van der Waals radius. Voronota is a software tool for finding all the vertices of the Voronoi diagram of balls. Such vertices correspond to the centers of the empty tangent spheres defined by quadruples of balls. Voronota is especially suitable for processing three-dimensional structures of biological macromolecules such as proteins and RNA. Voronota is directed at generating Voronoi diagrams for atoms, however, it could be directly applied to other fields of interest as a generic algorithm. Voronota was compared to QTFier and awVoronoi and it was shown to perfom better than these two tools with any number of atoms (Olechnovič et al. 2014, doi:10.1002/jcc.23538). I plan to team-maintain the package in Debian Science. I will need a sponsor to upload the package once it is ready.
Bug#882399: ITP: spglib -- C library for crystal symmetry determination
Package: wnpp Severity: wishlist Owner: Andrius Merkys * Package name: spglib Version : 1.10.1 Upstream Author : Atsushi Togo * URL : https://atztogo.github.io/spglib/ * License : BSD-3-Clause Programming Lang: C Description : C library for crystal symmetry determination Spglib is a C library for crystal symmetry determination. Symmetry operations, space groups and other data can be obtained using this symmetry finder. Features include: * Identify space-group type * Find symmetry operations * Find a primitive cell * Search irreducible k-points * Refine crystal structure * Wyckoff position assignment The package implements symmetry determination algorithms by Grosse-Kunstleve (Acta Cryst., A55, 383-395 (1999)) and Grosse-Kunstleve and Adams (Acta Cryst., A58, 60-65 (2002)). There are language bindings for Python, Fortran and Ruby. Packaging of spglib was previously requested in RFPs #602113 and #674135 (merged). I plan to team-maintain the package in Debian Science. I will need a sponsor to upload the package once it is ready.
Bug#884866: ITP: libspreadsheet-readsxc-perl -- Extract OpenOffice 1.x spreadsheet data
Package: wnpp Severity: wishlist Owner: Andrius Merkys * Package name: libspreadsheet-readsxc-perl Version : 0.20 Upstream Author : Christoph Terhechte * URL : https://metacpan.org/release/Spreadsheet-ReadSXC * License : Perl Programming Lang: Perl Description : Extract OpenOffice 1.x spreadsheet data The module parses OpenOffice 1.x spreadsheet files (.sxc) and returns Perl data structure to access its values. The package is a dependency of libspreadsheet-read-perl, but is silently ignored if not used. I plan to team-maintain the package in Debian Perl Group. I will need a sponsor to upload the package once it is ready.
Re: Strategy advice
Hello, On 2024-11-22 22:24, Mo Zhou wrote: It involves more social issues than technical issues that relies on experience, on a per-upstream basis, which is never something that can be effectively documented. I totally agree and could only repeat what Mo has written in this email. I've personally encountered upstreams super happy to hear the bits about inclusion in Debian, as well as improvement suggestions -- cooperative and friendly upstreams exist. There are many good aspects but here I'll mainly discuss the other side. Right, such upstreams are really pleasant to work with. I've personally also encountered ignorant, or even very hostile upstreams that immediately start to attack Debian and its developers once they hear things like that. Here are some reasons I observed: Same. Such interactions drain my energy to the point where I am often reluctant to contact a new upstream to forward patches etc. 1. Upstream moves at a completely different pace. They may feel bad when receiving bug reports from the users about an ancient version provided in Debian stable. 2. Upstream is sensitive on build flags. They may get super confused when receiving bug reports that only happens when using Debian's different build flags. 3. Upstream holds an objection on Debian's value behind DFSG. This world is diverse. There are people who understand why Debian is so strict on those things. And, there is surely people who do not understand and not willing to understand it at all. For instance, some upstreams may go mad with the +dfsg source stripping which breaks the intended full functionality of the upstream tarball. 4. Upstream disagrees with Debian's technical solution, like binary package splits. Just to give some more examples: un-embedding dependencies, requiring soversions, push to update to new releases of dependencies. Best, Andrius
Re: criteria for acceptable languages for central QA tools in Debian
On 2024-12-12 20:51, Marco d'Itri wrote: On Dec 12, Jonathan Dowland wrote: The "Perl Problem" is a wider issue we should explore in much more depth. We would first need to determine that there is an actual problem. Perl is quite healthy as a language and has aged much better than many other younger languages: e.g. there is no need to update all code every few years because backward compatibility is preserved basically forever at this point. +1, advantages of Perl should not be ignored. Andrius
Re: Packages with a history of security issues and whose packaged version is not up to date
On 2025-02-20 15:37, Raphael Hertzog wrote: So provided that we don't spam maintainers with "new upstream release" bug reports hours after the upstream release, and that we don't open new bug reports for as long as the former one has not been closed (but instead update the existing bug with the new information), then I would be pretty much in favor of automating the creation of such bug reports. +1. More documentation on why a package has not been updated would be nice to have. Personally, I file bugs on my packages myself to document reasons/progress. Andrius
