OpenMPI 5.0 to be 32-bit only ?
Hi I've been pinged by the upstream maintainer of OpenMPI Jefff Squyres as to our opinions on maintaining 32-bit support. See a thread here: https://github.com/open-mpi/ompi/pull/11282 Until now I've asked for OMPI to hold off going to 64-bit only; saying we can help with the maintenance burden with our testing infrastructure. But we're not well suited to run multi-node test jobs. If 32-bit support is dropped in OMPI we can switch to MPICH as the default on those archs instead, but the core problem remains: how much can we support and test on 32-bit? (Note: We're at OpenMPI 4.1.4 now for Bookworm; no change planned) Comments please, Alastair McKinstry -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 e: mckins...@debian.org, im: @sceal.ie:mckinstry
Bug#1030756: ITP: python-test-stages -- Run Tox, Nox, etc. tests in groups, stopping on errors
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-devel@lists.debian.org, team+pyt...@tracker.debian.org, r...@debian.org * Package name: python-test-stages Version : 0.1.1 Upstream Contact: Peter Pentchev * URL : https://gitlab.com/ppentchev/test-stages * License : BSD-2-clause Programming Lang: Python Description : Run Tox, Nox, etc. tests in groups, stopping on errors The `test-stages` library provides command-line tools that wrap Python test environment runners such as Tox or Nox, invoking them so as the various tests are run in parallel, in groups, as specified on the command line. This allows the fastest tests to be run first, and the slower ones to only be started if it makes sense (e.g. if tools like [ruff] or [flake8] did not uncover any trivial syntax errors). The `tox-stages` tool runs Tox with the specified groups of test environments, stopping if any of the tests in a group should fail. This allows quick static check tools like e.g. `ruff` to stop the testing process early, and also allows scenarios like running all the static check tools before the package's unit or functional tests to avoid unnecessary failures on simple errors. The syntax for grouping the test environments to be run is described in the `parse-stages` library's documentation. This package will be maintained as part of the Debian Python Team. signature.asc Description: PGP signature
Bug#1030757: ITP: python-parse-stages -- Parse a mini-language for selecting objects by tag or name
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-devel@lists.debian.org, team+pyt...@tracker.debian.org, r...@debian.org * Package name: python-parse-stages Version : 0.1.1 Upstream Contact: Peter Pentchev * URL : https://gitlab.com/ppentchev/parse-stages * License : BSD-2-clause Programming Lang: Python Description : Parse a mini-language for selecting objects by tag or name This library is mostly useful for command-line parsing by other tools like `tox-stages` and `nox-stages`. It may be used to parse e.g. a command-line specification like `@check and not pylint` or `@tests or ruff` and then match it against a list of objects that have names and lists of tags. This package will be maintained as part of the Debian Python Team. signature.asc Description: PGP signature
Re: OpenMPI 5.0 to be 32-bit only ?
On 2023-02-07 10:54, Alastair McKinstry wrote: Hi I've been pinged by the upstream maintainer of OpenMPI Jefff Squyres as to our opinions on maintaining 32-bit support. See a thread here: https://github.com/open-mpi/ompi/pull/11282 Until now I've asked for OMPI to hold off going to 64-bit only; saying we can help with the maintenance burden with our testing infrastructure. But we're not well suited to run multi-node test jobs. If Lucas Nussbaum thinks it's appropriate, one thing we could consider is setting up multinode tests on the Grid'5000 [1] infrastructure. It would take a bit of effort to set up, but once set up it should be able to run multinode tests routinely. Although, true, it would only allow for 64-bit testing, i.e. amd64 (plus also arm64 and ppc64el), so it might not help with the question of 32-bit support unless 32-bit chroots can be set up. [1] https://www.grid5000.fr If 32-bit support is dropped in OMPI we can switch to MPICH as the default on those archs instead, but the core problem remains: how much can we support and test on 32-bit? Switching to mpich would in any case be supported by a lot of our upstream developers. In various different projects we hear them recommending mpich and occasionally expressing discontent with bugs in openmpi. To make it simpler for ourselves, we could also consider just switching to mpich altogether as default. Are there reasons to prefer 64-bit OMPI over MPICH? Drew
Bug#1030768: ITP: repro-apk -- scripts to make android apks reproducible
Package: wnpp Severity: wishlist Owner: FC Stegerman X-Debbugs-Cc: debian-devel@lists.debian.org, f...@obfusk.net * Package name: repro-apk Version : 0.2.2 Upstream Contact: FC Stegerman * URL : https://github.com/obfusk/reproducible-apk-tools * License : GPLv3+ Programming Lang: Python Description : scripts to make android apks reproducible reproducible-apk-tools is a collection of scripts (available as subcommands of the repro-apk command) to help make APKs reproducible (e.g. by changing line endings from LF to CRLF), or find out why they are not (e.g. by comparing ZIP file metadata, or dumping baseline.prof files). repro-apk is used by e.g. F-Droid and also a proposed new optional dependency for diffoscope [1], allowing it to compare e.g. baseline.prof/baseline.profm files found in APKs. I am the upstream author and want to package and maintain it for Debian as well (like I already do with apksigcopier). - FC [1] https://salsa.debian.org/reproducible-builds/diffoscope/-/merge_requests/118
Bug#1030776: ITP: quickjs -- small and embeddable Javascript engine
Package: wnpp Severity: wishlist Owner: Sebastian Humenda X-Debbugs-Cc: debian-devel@lists.debian.org, pkg-a11y-de...@alioth-lists.debian.net, shume...@gmx.de * Package name: quickjs Version : 2021.03.27 Upstream Contact: Fabrice Bellard, Charlie Gordon * URL : https://bellard.org/quickjs/ * License : MIT Programming Lang: C Description : small and embeddable Javascript engine QuickJS is a small and embeddable Javascript engine. It supports the ES2020 specification, including modules, asynchronous generators, proxies and BigInt. . It supports mathematical extensions such as big decimal float float numbers (BigDecimal), big binary floating point numbers (BigFloat), and operator overloading. This package is required as a dependency of Edbrowse. It has no further dependencies. Bye, Joost - on behalf of Sebastian Humenda
Bug#1030780: Maintainers wanted for softether-vpn
Package: wnpp Severity: normal X-Debbugs-Cc: debian-devel@lists.debian.org Hi all, I packaged SoftEther VPN back in 2020 when people in Belarus protested against decades of dictatorship, and they needed a safe way to communicate with the outside world and with each other, circumventing the state censorship. Since then, due to a massive crackdown on protests and repressions against anyone remotely involved, most of my friends have moved abroad, and I, personally, don't know a single user of this VPN right now. Packaging is not hard, but not super trivial either, and requires some work to package subsequent releases. Not using this software myself, I'm really not in position to continue being the maintainer, and if nobody takes it over, I will have to orphan it eventually. Please let me know if you can help. -- Cheers, Andrej
Bug#1030794: ITP: libcatmandu-oai-perl -- modules for working with OAI repositories within the Catmandu framework
Package: wnpp Owner: Mason James Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libcatmandu-oai-perl Version : 0.19 Upstream Author : Nicolas Steenlant * URL : https://metacpan.org/release/Catmandu-OAI * License : Artistic or GPL-1+ Programming Lang: Perl Description : modules for working with OAI repositories within the Catmandu framework Catmandu::OAI contains modules for working with OAI repositories. Provides modules: Catmandu::Importer::OAI Catmandu::Store::OAI Catmandu::Importer::OAI is an Catmandu importer to harvest metadata records from an OAI-PMH endpoint. See also: http://www.openarchives.org/pmh/tools/ http://www.openarchives.org/OAI/openarchivesprotocol.html Catmandu provides a suite of Perl modules to ease the import, storage, retrieval, export and transformation of metadata records. 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.
Bug#1030800: ITP: liblido-xml-perl -- Lido XML parser and writer
Package: wnpp Owner: Mason James Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: liblido-xml-perl Version : 0.07 Upstream Author : Patrick Hochstenbach * URL : https://metacpan.org/release/Lido-XML * License : Artistic or GPL-1+ Programming Lang: Perl Description : Lido XML parser and writer LIDO is an XML Schema for Contributing Content to Cultural Heritage Repositories. The Lido::XML parser is a software tool that understands the Lido Schema and can parse the content of Lido XML files into a Perl hash and back. 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.
-ffile-prefix-map option and reproducibility
Hi, When building packages, a -ffile-prefix-map option is automatically injected into CFLAGS. Where does it come from? Since when? I suspect this was added to improve reproducibility. Ironically, it makes packages that capture this variable non reproducible, since the build path seems to be randomized (has it always been the case? since when?). It is the case of OCaml (see #1030785), and seemingly of R as well (found by grepping in my /etc). I wouldn't be surprised other packages are affected as well. Is there a way to not get this option? More elegant than explicitly filtering it out of CFLAGS in debian/rules... Cheers, -- Stéphane
Bug#1030803: ITP: mdns-reflector -- lightweight and performant multicast DNS (mDNS) reflector
Package: wnpp Severity: wishlist Owner: Mike Gabriel X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: mdns-reflector Version : 0.0.1+ Upstream Author : Yuxiang Zhu * URL : https://github.com/vfreex/mdns-reflector * License : GPL-3+ Programming Lang: C Description : lightweight and performant multicast DNS (mDNS) reflector mDNS Reflector (mdns-reflector) is a lightweight and performant multicast DNS (mDNS) reflector with a modern design. It reflects mDNS queries and responses among multiple LANs, which allows you to run untrusted IoT devices in a separate LAN but those devices can still be discovered in other LANs. . Supports zone based reflection and IPv6. . This package will be maintained under the umbrella of the Debian Edu Packaging Team and will very likely be used in Debian Edu Router.
Re: -ffile-prefix-map option and reproducibility
Hi, Quoting Stéphane Glondu (2023-02-07 16:41:47) > When building packages, a -ffile-prefix-map option is automatically injected > into CFLAGS. Where does it come from? Since when? probably due to https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/commit/?id=b60c243ba99b8483202a6f6a814476275204fdff which references: https://lists.debian.org/debian-devel/2020/10/msg00222.html https://bugs.debian.org/974087 > I suspect this was added to improve reproducibility. Ironically, it makes > packages that capture this variable non reproducible, since the build path > seems to be randomized (has it always been the case? since when?). It is the > case of OCaml (see #1030785), and seemingly of R as well (found by grepping > in my /etc). I wouldn't be surprised other packages are affected as well. > > Is there a way to not get this option? More elegant than explicitly > filtering it out of CFLAGS in debian/rules... See the man page of dpkg-buildflags -- this might do what you want: export DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath Thanks! cheers, josch
Re: -ffile-prefix-map option and reproducibility
Hi! On Tue, 2023-02-07 at 16:41:47 +0100, Stéphane Glondu wrote: > When building packages, a -ffile-prefix-map option is automatically injected > into CFLAGS. Where does it come from? Since when? This is coming from dpkg-buildflags (in this case probably indirectly via debhelper). AFAICS it was added in dpkg 1.19.1 disabled by default, and then switched to enabled by default in dpkg 1.20.6 (see #974087). > I suspect this was added to improve reproducibility. Ironically, it makes > packages that capture this variable non reproducible, since the build path > seems to be randomized (has it always been the case? since when?). It is the > case of OCaml (see #1030785), and seemingly of R as well (found by grepping > in my /etc). I wouldn't be surprised other packages are affected as well. AFAIR this was considered at the time, yes. If the flag is effectively not fixing anything for the set of packages involved, and is in fact actually making them unreproducible when they would not then, you can disable the fixfilepath feature in the reproducible build flags area, via DEB_BUILD_MAINT_OPTIONS. Perhaps even "globally" from a language specific packaging helper or similar? > Is there a way to not get this option? More elegant than explicitly > filtering it out of CFLAGS in debian/rules... See above. I just noticed that several of these build flag features do not have information in the man page about when they got first introduced, so I'll be adding that in dpkg 1.22.x, once development opens up again. Thanks, Guillem
Re: -ffile-prefix-map option and reproducibility
On Tue, Feb 07, 2023 at 04:41:47PM +0100, Stéphane Glondu wrote:
> When building packages, a -ffile-prefix-map option is automatically injected
> into CFLAGS. Where does it come from? Since when?
>
> I suspect this was added to improve reproducibility. Ironically, it makes
> packages that capture this variable non reproducible, since the build path
> seems to be randomized (has it always been the case? since when?).
The build path has always been randomized since, or at least it has been
for as long as I've been involved in Debian.
> It is the
> case of OCaml (see #1030785), and seemingly of R as well (found by grepping
> in my /etc). I wouldn't be surprised other packages are affected as well.
>
> Is there a way to not get this option? More elegant than explicitly
> filtering it out of CFLAGS in debian/rules...
Besides doing
DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath
I actually propose to you to filter out the whole option from being
saved. I've seen a similar pattern in other packages in the past, and
all of those packages already had a filtering function in place to
remove other gcc flags that make no sense being saved (just looking at:
- 8: const("camlConfig__8"="-O2 -fno-strict-aliasing -fwrapv -pthread
-fPIC -g -O2 -ffile-prefix-map=/build/ocaml-Vq2uKK/ocaml-4.13.1=.
-fstack-protector-strong -Wformat -Werror=format-security");
+ 8: const("camlConfig__8"="-O2 -fno-strict-aliasing -fwrapv -pthread
-fPIC -g -O2 -ffile-prefix-map=/build/ocaml-xz3WL7/ocaml-4.13.1=.
-fstack-protector-strong -Wformat -Werror=format-security");
makes me believe that many options have been stripped out…)
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: -ffile-prefix-map option and reproducibility
On 2023-02-07 17:50 +0100, Guillem Jover wrote: > On Tue, 2023-02-07 at 16:41:47 +0100, Stéphane Glondu wrote: >> When building packages, a -ffile-prefix-map option is automatically injected >> into CFLAGS. Where does it come from? Since when? > > This is coming from dpkg-buildflags (in this case probably indirectly > via debhelper). AFAICS it was added in dpkg 1.19.1 disabled by default, > and then switched to enabled by default in dpkg 1.20.6 (see #974087). > >> I suspect this was added to improve reproducibility. Ironically, it makes >> packages that capture this variable non reproducible, since the build path >> seems to be randomized (has it always been the case? since when?). It is the >> case of OCaml (see #1030785), and seemingly of R as well (found by grepping >> in my /etc). I wouldn't be surprised other packages are affected as well. > > AFAIR this was considered at the time, yes. If the flag is effectively > not fixing anything for the set of packages involved, and is in fact > actually making them unreproducible when they would not then, you can > disable the fixfilepath feature in the reproducible build flags area, > via DEB_BUILD_MAINT_OPTIONS. This does not help for packages which capture all build flags and store them in some file in the package (as is the case here). With DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath, dpkg-buildflags falls back to "-fdebug-prefix-map==.", and you have the same problem. If you disable that as well via DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath,-fixdebugpath, the -dbgsym packages will most likely end up unreproducible. Cheers, Sven
Security (Was: OpenMPI 5.0 to be 32-bit only ?)
Hi Alastair, Thanks for relaying OpenMPI's upstream maintainer's interest in our opinions on maintaining 32 bit support. My humble comments are 1.) 32 bit hardware can be more secure because it's so old it predates back doors known as Intel's Management Engine[1] and AMD's Platform Secure Processor[2] 2.) and I'm OK with reporting bugs. Thanks again, Kingsley [1] https://en.wikipedia.org/wiki/Intel_Management_Engine#Security_vulnerabilities [2] https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor#Reported_vulnerabilities On 02/07/2023 09:54, Alastair McKinstry wrote: > Hi > > I've been pinged by the upstream maintainer of OpenMPI Jefff Squyres as > to our opinions on maintaining 32-bit support. > > See a thread here: https://github.com/open-mpi/ompi/pull/11282 > > Until now I've asked for OMPI to hold off going to 64-bit only; saying we > can help with the maintenance burden with our testing infrastructure. > > But we're not well suited to run multi-node test jobs. > > If 32-bit support is dropped in OMPI we can switch to MPICH as the default > on those archs instead, but the core problem remains: how much can we > support and test on 32-bit? > > (Note: We're at OpenMPI 4.1.4 now for Bookworm; no change planned) > > Comments please, > > > Alastair McKinstry > > -- > Alastair McKinstry, > GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 > e: mckins...@debian.org, im: @sceal.ie:mckinstry > -- Time is the fire in which we all burn.
Bug#1030835: ITP: ruff -- linter for Python, written in Rust
Package: wnpp Severity: wishlist Owner: James Addison X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: ruff Version : 0.0.243 Upstream Contact: Charlie Marsh * URL : https://github.com/charliermarsh/ruff/ * License : MIT Programming Lang: Rust Description : linter for Python, written in Rust Ruff is a linter for Python that includes implementations of many common checks implemented by flake8, flake8 plugins, and pylint.
