Bug#1020762: ITP: mastodon.el -- Emacs client for the Mastodon and Pleroma social networks
Package: wnpp Owner: Martin Severity: wishlist * Package name: mastodon.el Version : 1.0.0 Upstream Author : Marty Hiatt and others * URL or Web page : https://codeberg.org/martianh/mastodon.el * License : GPL-3+ Description : Emacs client for the Mastodon and Pleroma social networks mastodon.el is an Emacs client for the Mastodon and Pleroma social networks. For info see https://joinmastodon.org/. Type M-x mastodon to start.
Bug#1020766: ITP: pygubu -- A simple GUI builder for the python tkinter module
Package: wnpp Severity: wishlist Owner: Bo YU X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: pygubu Version : v0.25.1 Upstream Author : Alejandro Autalán * URL : https://github.com/alejandroautalan/pygubu * License : MIT Programming Lang: Python Description : A simple GUI builder for the python tkinter module Pygubu is a RAD tool to enable quick and easy development of user interfaces for the Python's tkinter module. The user interfaces designed are saved as XML files, and, by using the pygubu builder, these can be loaded by applications dynamically as needed. Pygubu is inspired by Glade. This packages is a dependency package of funing[0] and it will be maintained by Debian Python team. [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018175 -- Regards, -- Bo YU signature.asc Description: PGP signature
Fixing CI bugs for a package on the REJECT list
Hallo all, A few of the tests for gscan2pdf seem to be flaky (although I can't reproduce this locally): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012250 When I wrote the reply on the above bug, I evidently waited too long for help, as now the log files cited have been purged, as have all the others: https://ci.debian.net/packages/g/gscan2pdf/testing/amd64/ If I try to retry a run, I get: Package gscan2pdf is in the REJECT list and cannot be retried Short of closing #1012250, how do I get CI pipeline to pick up gscan2pdf again to debug the flaky tests? I'd appreciate any pointers. Regards Jeff OpenPGP_signature Description: OpenPGP digital signature
Bug#1020772: ITP: trexio -- TREX I/O library and data format to exchange the quantum chemistry data.
Package: wnpp Severity: wishlist Owner: Evgeny * Package name: trexio Version : 2.2.0 Upstream Author : Evgeny Posenitskiy * URL : https://github.com/TREX-CoE/trexio * License : (BSD) Programming Lang: (C, C++, Fortran, Python) Description : TREX I/O library and data format to exchange the quantum chemistry data. The TREXIO library is an open-source software for the quantum chemistry community. It allows to efficiently write and read data in a common format using the default back end which relied on the HDF5 library. TREXIO has been developed within the TREX-CoE project and it is now a hard dependency of several scientific codes including Quantum Package, QMC=Chem, CHAMP, GammCor, QMCkl etc. Moreover, TREXIO has bindings in the OCaml programming language and having a Debian package for it would simplify the installation experience for OCaml users. For now, it would be nice to package at least the C library with the Fortran binding as these are the most commonly used ones. Having a C library installed via Debian will simplify a lot development of binding with languages like Rust, OCaml and Julia. The build system relies on Autotools to build and install the shared C library `libtrexio`. It provides additional `m4` macros to detect the HDF5 library and some other dependencies. We can already produce debian package on the user machine and I wrote a short README about it here: https://github.com/TREX-CoE/trexio/blob/master/debian/README.md. It requires only the Autotools-generated distribution tarball. TREXIO default dependencies are (when building from the distribution tarball, not from the GitHub repository clone): - libc - C compiler (gcc/icc/clang) - Autotools (autoconf >= 2.69, automake >= 1.11, libtool >= 2.2) or CMake (>= 3.16) - Fortran compiler (gfortran/ifort) [can be disabled at the `configure` time] - HDF5 library (>= 1.8) for high-performance I/O [can be disabled at the `configure` time] This package can be particularly interesting for the Debichem team (https://wiki.debian.org/Debichem) and, in particular, for the *Input prepataion and output processing* subsection: https://blends.debian.org/debichem/tasks/input-generation-output-processing To the best of our knowledge, TREXIO is the first package that attemps to unify data exchange. However, there are some Python packages like `cclib` that can parse the output of some chemistry programs and convert them into other formats. However, they do not provide a uniform API that can be used within the chemistry programs to *a priori* write/read data in a common format. As this is my first packaging attempt, I do not know about the best practices and would appreciate any piece of advice.
Bug#1020774: ITP: rust-serde-fmt -- write any serde::Serialize using standard formatting APIs
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-serde-fmt Version : 1.0.1 Upstream Author : Ashley Mannix * URL : https://github.com/kodraus/serde_fmt * License : Apache-2.0 or Expat Programming Lang: Rust Description : write any serde::Serialize using standard formatting APIs This library lets you take any `Serialize` and format it as if it's `Debug`. The format produced is the same as if the type derived `Debug`, and any formatting flags will be preserved. This package is needed transitively by rust-femme and rust-async-std (see bug#1020726). It will be maintained in the collaborative Debian section of Salsa, at https://salsa.debian.org/debian/rust-serde-fmt - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmMxuIwACgkQLHwxRsGg ASEqHw//f9NCKDgkIwAv+IQRaazc9itQ0ow/b53DZW7pUWt8m7mreEpgGYQs238s i/j5avdTuVplI388qtKEbH9sNnPZXYBxZdCGyxViJxTnKE+it9y9jFY7jc7Ukw84 +/6M0d2RsHmyGBercB2x9zBNFLJRj+y6w8UXYuguIULLMSP4eFh8L3VNLEOPRKS6 wjk3zZMFR41fhe3bPONL8pYIfzacUE0miVT9kIt6lPPbQPlweZz+yGSqVt29AGRE ZdrsDl8JFwE/w4GB7eLGOVnkvLMylB/0Tw/XKxi0OcbVtsFbzHCca1QnBe4cRTw7 wHN1znBBnJHZHG3568gt+VnRlQ5HHYvb5bYKCw3YndlySbrikmERHwvAcYCWAsek DYpbwlk6W79unFkfkKgUt3P+n1EhOS64GNO62O/SK6t7f8Xjjo08HW6K2akWmRam xBe2HGHscfAylPf6UPU2nO7rEoMCNGkHaYGWelcqe8jryYY10jZBSkEPJJWqSDV7 biEtxqWVqRjgBPoUirGmillP48WSnP80Szc6zXqtEnVo+p6t9hy5+hZF2vhGGmvw 9garDJ2JGsuPK5XMERTLgonkOON3911GYtRDTWE9SEYctA+gTB2gVAxOUeJtcOGl 6MBg6axerAx1f/tVPLdVx4Olml7EwL6UcUGbQ1QAOgWJOb/fQqA= =nEsd -END PGP SIGNATURE-
Bug#1020785: ITP: golang-github-gonvenience-ytbx -- convenience functions to load and process YAML files
Package: wnpp Severity: wishlist Owner: ChangZhuo Chen (陳昌倬) X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-gonvenience-ytbx Version : 1.4.4 Upstream Author : Matthias Diester * URL : https://github.com/gonvenience/ytbx * License : Expat Programming Lang: Golang Description : convenience functions to load and process YAML files This package will be maintained under Debian Go Packaging Team. This is dependencies of dyff (https://bugs.debian.org/1013751). -- ChangZhuo Chen (陳昌倬) czchen@.org http://czchen.info/ Key fingerprint = BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B signature.asc Description: PGP signature
Re: Fixing CI bugs for a package on the REJECT list
Hi Jeff, On 26-09-2022 12:53, Jeff wrote: Short of closing #1012250, how do I get CI pipeline to pick up gscan2pdf again to debug the flaky tests? I'd appreciate any pointers. The bug has a user specified for the usertag and explicitly mentions: """ Don't hesitate to reach out if you need help [...] """ So, either using debian...@lists.debian.org or the submitter's address (mine) seems appropriate. In this case: we can trigger the test from the backside, such that you can get a fresh log, but I prefer to only do that coordinated and after you give it a try to enable more diagnostic logging, because apparently in the original logs there wasn't enough information for you. I also offer to run the test (once or twice) manually and get information out of the testbed, if you tell me the exact commands you want me to run in the testbed. Paul PS: I propose we drop debian-devel from the replies and continue our discussion in the bug, but please keep me in CC as I'm not subscribed to the bug. Be reminded that the BTS doesn't send e-mail to the submitter unless asked explicitly or unless the bug is closed. OpenPGP_signature Description: OpenPGP digital signature
Re: Bug email is not getting to me
On Sun, Sep 25, 2022 at 07:00:38PM -0700, Russ Allbery wrote: > Steven Robbins writes: > > On Sunday, September 25, 2022 4:57:19 P.M. CDT Russ Allbery wrote: > > >> If someone sends mail from a domain that says all mail from that domain > >> will always have good DKIM signatures, and if the signature isn't > >> present or doesn't validate the mail should be rejected, and that > >> message is forwarded through bugs.debian.org to someone whose mail > >> server honors DMARC settings, the mail will be rejected. That's > >> because the process of modifying the message in the way that > >> bugs.debian.org needs to do (adding the bug number to the Subject > >> header, for instance) usually breaks the signature. > > > So are you effectively confirming this is indeed the DMARC bug [1] filed > > in 2014? > > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754809 > > Yeah, that's my guess. It's a very common problem. > > The right solution is probably for bugs.debian.org to rewrite all incoming > mail to change the From header to a debian.org address (probably the bug > address) and add a Reply-To header pointing to the original sender. This > is the fix that Mailman mostly uses, and it seems to work (I've had this > problem with multiple mailing lists I run and turning on this message > mangling has fixed it). But of course someone has to find time to > implement this. Yeah, what would be nice is if it massaged the From header to something like this: From: Theodore Tso Reply-to: Theodore Tso That makes things a bit friendlier for various mail user agents, while bypassing the DKIM signature problem. But as Russ said, the trick is finding someone with time to implement the change in the Debian BTS... - Ted
Bug#903999: ITP: php-doc -- Documentation for PHP
Control: retitle -1 ITP: php-doc -- Documentation for PHP
Control: owner -1 !
X-Debbugs-CC: debian-devel@lists.debian.org, ond...@debian.org,
taf...@debian.org, kap...@debian.org
* Package name: php-doc
Version : 20220919~git.2aee619
Upstream Author : The PHP Documentation Group
* URL : http://docs.php.net/manual/en/
* License : CC-BY-3.0 and Expat and BSD-2-Clause and PHP-3.01 and
PHP-3.0
Description : Documentation for PHP
I have prepared an initial update at https://salsa.debian.org/athos/php-doc
The idea here would be to maintain the package under the PHP team
umbrella.
As mentioned in the original report (RFP), this package was originally
removed from the archive due to Bug #821695, when it was not updated
during the PHP 7 transition.
Since then a few lincesing discussions happened regarding the PHP
license.
Some of these discussions were around the feasibility of shipping
software licensed under the PHP license, which resulted in the following
lintian warning:
https://lintian.debian.org/tags/license-problem-php-license,
and the following notice:
https://ftp-master.debian.org/php-license.html
Note that while the first mentions PHP-3.0 ("exactly"), the latter only
mentions PHP-3.01. Here, it seems that the first is just outdated and
should be updated to day PHP-3.01.
Now, I wonder if it is feasible to introduce this specific package back
in Debian, given its source includes PHP-3.0 licensed files.
In a quick search through the archive, I could only find 2 packages
including the PHP-3.0 license, php itself and civicrm.
Do we refrain from shipping PHP-3.0 licensed software other than PHP
itself due to the working of the PHP-3.0 license? If so, should that
also apply for the php documentation as well?
Regarding the lintian warning (license-problem-php-license), I am
overriding it ATM. While the sources come from github, they are clearly
from the PHP Group itself and links to the sources are available at
php.net ATM. Thoughs?
Finally, I filed https://github.com/php/doc-base/issues/69 to verify
the feasibility of re-licensing such scripts upstream.
I am Ccing Ondrej and David since they most likely have opinions and
more context in the matter.
--
Athos Ribeiro
Re: packages expected to fail on some archs
On Wed, Sep 14, 2022 at 01:38:01PM +0200, Guillem Jover wrote: >... > [ Mostly to summarize the status re dpkg. ] >... > * Lack of bits/endianness arch "aliases" (#962848). The main problem > with this one is that we cannot simply add such aliases, as then > those would silently be considered as regular arches, and they do > not map into the current naming convention at all. These would need > to be added with a breaking syntax (say with some non-accepted > char, such as % or whatever) so that they do not introduce silent > breakage. This would then need to be supported by anything > handling arch restrictions (field and dependencies) which can be a > rather large surface. Then there is the problem that architectures > are evaluated as ORed lists, and the bits/endianness might require > to be treated as ANDed lists some times (of course the latter > could be handled by combining them into single aliases, but meh). If we limit the problem to avoiding build failures in cases that upstream does not support, there would be the trivial solution of having a package ship Provides like: - architecture-is-64bit - architecture-is-32bit - architecture-is-little-endian - architecture-is-big-endian - architecture-has-64bit-timet -... Build-Depends: architecture-is-64bit, architecture-is-little-endian,... would be a package that only supports 64bit little endian architectures, and that would never be attempted to build on 32bit or big endian architectures. The buildd page would then show for i386: mypackage build-depends on missing: - architecture-is-64bit Not building a source package on one specific architecture could already today be achieved with: Build-Depends: package-is-broken-on-ppc64el [ppc64el],... This might not be the most elegant solution, but it should be sufficient to solve the problem in this thread and it does not require any tool changes. > Thanks, > Guillem cu Adrian
Re: packages expected to fail on some archs
Hi Le lun. 26 sept. 2022 à 23:42, Adrian Bunk a écrit : > > If we limit the problem to avoiding build failures in cases that > upstream does not support, there would be the trivial solution of > having a package ship Provides like: > - architecture-is-64bit > - architecture-is-32bit > - architecture-is-little-endian > - architecture-is-big-endian > - architecture-has-64bit-timet > -... > > Build-Depends: architecture-is-64bit, architecture-is-little-endian,... > would be a package that only supports 64bit little endian architectures, > and that would never be attempted to build on 32bit or big endian > architectures. > > The buildd page would then show for i386: > mypackage build-depends on missing: > - architecture-is-64bit > > Not building a source package on one specific architecture could already > today be achieved with: > Build-Depends: package-is-broken-on-ppc64el [ppc64el],... > > This might not be the most elegant solution, but it should be sufficient > to solve the problem in this thread and it does not require any tool > changes. > I find it both simple and elegant -- and it's probably pretty efficient too. Perhaps there should be a conventional naming scheme for such virtual packages ; say deb-missing-feature, deb-unsupported-architecture or some such? J.Puydt >
Debian Med video conference on Wednesday 2022-09-28 18:00 UTC
Hi, this is the call for the next video conference of the Debian Med team that are an established means to organise the tasks inside our team. Due to time constraints we do not meet at 2nd October as usually but tomorrow (28th September). Usually it takes us only 15-20min depending what we are talking about and how many people are joining. The next meeting is tomorrow 18:00 UTC https://www.timeanddate.com/worldclock/fixedtime.html?iso=20220928T18 The meeting is on the Debian Social channel https://jitsi.debian.social/DebianMedCovid19 These video meetings were started in the Debian Med Biohackathon. The topic is what contributors have done in the past period and to coordinate the work until the next meeting. For those who are interested in hot topics we want to tackle, here are some items: Preparation of next release by - Pushing latest versions of our software - RC bugs Newcomers are always welcome. Lets keep on the great work and see you tomorrow Andreas. -- http://fam-tille.de
