Re: The future of mipsel port

[Aurelien Jarno]

Hi,

On 2023-08-06 13:54, Florian Lohoff wrote:
> 
> Hi,
> 
> On Tue, Jul 18, 2023 at 12:45:51PM +0800, YunQiang Su wrote:
> > Hi, folks,
> > 
> > Welcome to era of Trixie, and let's talk about the future of mipsel.
> 
> > So I consider to suggest drop mipsel support from the list of official 
> > ports.
> > (And let's keep mips64el port).
> 
> I am late to the party but as i mentioned a couple times on debian-mips
> already i'd like to keep mipsel as a debian-port - and i'd like to

From what I have understood from  YunQiang plans, it is currently not
planned to import mipsel on debian-ports. Are you volunteering for
maintaining such a port?

> revert away from mips32r2 back to mips2/mips3 - That change (with
> stretch) basically dropped all of the supported platforms formerly
> supported without a good reason - mips32r2 cpus would have been 

The reason is that many upstream code do not support mips2 anymore,
especially for JIT languages or languages with their own code generator.
Be prepared for a lot of upstream work.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net


signature.asc
Description: PGP signature

Re: The future of mipsel port

[Florian Lohoff]

Hi,

On Mon, Aug 07, 2023 at 10:53:02AM +0200, Aurelien Jarno wrote:
> From what I have understood from  YunQiang plans, it is currently not
> planned to import mipsel on debian-ports. Are you volunteering for
> maintaining such a port?

I am not interested in mips32r2 as i have no hardware for that. So
everything debian-mipsel stretch++ is unusable.

> > revert away from mips32r2 back to mips2/mips3 - That change (with
> > stretch) basically dropped all of the supported platforms formerly
> > supported without a good reason - mips32r2 cpus would have been 
> 
> The reason is that many upstream code do not support mips2 anymore,
> especially for JIT languages or languages with their own code generator.
> Be prepared for a lot of upstream work.

I have already started with that on stretch - have 90% build - the issue
is that a lot of debian patches unconditionally enabled/switched to
mips32r2

Flo
-- 
Florian Lohoff f...@zz.de
  Any sufficiently advanced technology is indistinguishable from magic.


signature.asc
Description: PGP signature

Bug#1043206: ITP: rust-snow -- pure-rust Noise Protocol Framework implementation - Rust source code

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-devel@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-snow
  Version : 0.9.2
  Upstream Contact: Jake McGinty 
* URL : https://github.com/mcginty/snow
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : pure-rust Noise Protocol Framework implementation - Rust 
source code

 The snow crate is a straightforward,
 Hard To Fuck Up™ Noise Protocol implementation.
 .
 The Noise Protocol Framework is a set of crypto protocols
 based on Diffie-Hellman key agreement,
 that each can consist of a single message
 as well as interactive protocols.

This package is needed by safe-network (bug#1008016).
It will be maintained in the collaborative debian section of salsa, at
.

 - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmTQzK0ACgkQLHwxRsGg
ASFu6RAAqV5579Kkcc8SQ4bffdnmgrRfkz+MoRrxeO8EkedUvS89+QpTEyQxJ9I+
0MMsX63kOxVY7YduR8hNzXwINpn7J+T4vyp+To+r+AaE2wn80BhJw3k1HNRnTSpY
/h/US3EUJ5fmBMzwqzwoFck7DLofN/IL+R9VOlpJMNwxQnkDQdbIdTbFdRdq/Arz
kbtsg52Xz1Nu2x4UIz44NOOuN3FBTxrNbMoMuNMUYrlah2disrw5Li439lA7BLcE
VXggUoX+QLq8JQl5vbt3lAitXSn0mxDIFfcclz6kiN90K99KcoDQG3NoaRtfA6eu
KtPMdrdYk/LvXC5LHh7UvaxuHc3/wXH59m458XffcrzMtVk8Uuyep2S8VHXDX5r3
MYVnyVnH50q/6DCcGtaJ0gdDb7bCZt9swtNmaZGKlEtKThw0sts9ezLXYsuro1qr
TvHJ+rGM2Jsi7OyDym3K4zEYLPuxLFYZb2vkXmi759Y93qb6Tn5GVqMs6in72G/O
ko1/76G39db/DU7HpiXPiESeDZFxcb/fupQ7TlPBtJq62YweRnFTINJf6FKNyJTP
pvSRN01CBTPmYTmkzbBi/SIDHgvKbA3uxR91sW5J07SzDXwod+R119cfa+306ZRU
XM7sFr3Sa4FZJ9mdZRV9681iVe6J2+HUwS3r6P+hl1utpeQWSGk=
=LTw/
-END PGP SIGNATURE-

Re: The future of mipsel port

[Adrian Bunk]

On Mon, Aug 07, 2023 at 10:09:40AM +0800, Paul Wise wrote:
> On Sun, 2023-08-06 at 13:54 +0200, Florian Lohoff wrote:
> 
> > I am late to the party but as i mentioned a couple times on debian-mips
> > already i'd like to keep mipsel as a debian-port - and i'd like to
> > revert away from mips32r2 back to mips2/mips3 - That change (with
> > stretch) basically dropped all of the supported platforms formerly
> > supported without a good reason - mips32r2 cpus would have been 
> > able to run mips2 code. The now supported platforms are
> > basically non existent or available for the normal user.
> 
> That sounds like a new port would be needed,
>...

No, that's not required.

We've already had baseline lowering in ports in the past (and could do 
that even for a release architecture) by changing the default in gcc
and then binNMUing all packages.

> bye,
> pabs

cu
Adrian

Bug#1043208: ITP: rust-gix - Pure Rust implementation of Git

[Blair Noctis]

Package: wnpp
Severity: wishlist
Owner: Blair Noctis 
X-Debbugs-Cc: debian-devel@lists.debian.org, n...@sail.ng

* Package name: rust-gix
  Version : 0.51.0
  Upstream Contact: Sebastian Thiel 
* URL : https://crates.io/crates/gitoxide
* License : Apache-2.0 OR MIT
  Programming Lang: Rust
  Description : Pure Rust implementation of Git

The gix crate, with its gix-* subcrates (subpackages), provides a pure Rust
implementation to various primitives of Git. It's used by programs such as
gitoxide (their origin), cargo, starship, etc.

This package will be maintained in the Debian Rust Team. Unlike the usual
process, due to the vast number of subcrates, the team decided to maintain all
of them in its own Git [repository]. This is an umbrella ITP; we won't be filing
ITPs for each and every subcrate.


repository: https://salsa.debian.org/rust-team/gitoxide

-- 
Sdrager,
Blair Noctis

Bug#1043231: ITP: node-quickjs-emscripten -- Javascript/Typescript bindings for QuickJS compiled to WebAssembly

[Israel Galadima]

Package: wnpp
Severity: wishlist
Owner: Israel Galadima 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name    : node-quickjs-emscripten
  Version : 0.15.0
  Upstream Author : Jake Teton-Landis
* URL : https://github.com/justjake/quickjs-emscripten#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Javascript/Typescript bindings for QuickJS compiled 
to WebAssembly


Safely execute untrusted Javascript in your Javascript,
and execute synchronous code that uses async functions.
Create and manipulate values inside the QuickJS runtime.
Expose host functions to the QuickJS runtime.

This package is part of my effort to package corepack for Debian.
Package will be maintained by the Debian JavaScript Team.



OpenPGP_0x3679ECB87B7CEC0C.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

autodep8 test for C/C++ header

[Benjamin Drung]

Hi,

while working a whole week on fixing failing C/C++ header compilations
for armhf time_t [1], I noticed a common pattern: The library -dev
packages was missing one or more dependencies on another -dev package.
Over 200 -dev packages are affected.

I propose to add an autodep8 test for C/C++ header files that tries to
compile the header file. This will catch issues like missing
dependencies and other issues.

Here is a draft for the autopkgtest check script that takes a binary
-dev package as parameter:
https://github.com/bdrung/bdrung-scripts/blob/compile-header-check/compile-header-check

What do you think? Should I proceed developing and packaging this check
script and submit support for it in autodep8?

[1] https://salsa.debian.org/vorlon/armhf-time_t/-/merge_requests/103

-- 
Benjamin Drung
Debian & Ubuntu Developer

Re: autodep8 test for C/C++ header

[Peter Pentchev]

On Mon, Aug 07, 2023 at 06:43:36PM +, Benjamin Drung wrote:
> Hi,
> 
> while working a whole week on fixing failing C/C++ header compilations
> for armhf time_t [1], I noticed a common pattern: The library -dev
> packages was missing one or more dependencies on another -dev package.
> Over 200 -dev packages are affected.
> 
> I propose to add an autodep8 test for C/C++ header files that tries to
> compile the header file. This will catch issues like missing
> dependencies and other issues.
> 
> Here is a draft for the autopkgtest check script that takes a binary
> -dev package as parameter:
> https://github.com/bdrung/bdrung-scripts/blob/compile-header-check/compile-header-check
> 
> What do you think? Should I proceed developing and packaging this check
> script and submit support for it in autodep8?
> 
> [1] https://salsa.debian.org/vorlon/armhf-time_t/-/merge_requests/103

Whlie it does seem an interesting tool at first glance (and thanks for
doing the work and presenting a proof of concept), I can think of
several cases when compilation of the concatenated header files would
fail:

1) The library has a "main" header file that must be included before
   any of the others, and it does not come first in lexicographical
   order. It may define typedefs and structure definitions that
   the other header files can use, it may define preprocessor symbols
   that reflect the availability of this or that system header file or
   type; there are also other ways in which another header file
   distributed by the -dev package may depend on the main one.

2) As a variation of the above, the -dev package may distribute
   the full set of header files included in the library, and some of
   them may only be included if certain preprocessor symbols are
   defined. Since their use is guarded by conditionals, they are
   allowed to unconditionally include system-specific header files
   that are only available on e.g. Windows or NetBSD or Darwin, etc.
   Unconditionally compiling the contents of those files would fail.

3) The -dev package may distribute the full set of header files
   included in the library, and some of them may be mutually exclusive
   and impossible to combine. For example, a header file may include
   either this or that other header file based on preprocessor
   defintions (OS type, features enabled, etc), and the included
   files may both define a function with the same name, but different
   contents.

4) Some of the library's header files may not be supposed to be
   included in all cases; the library's -dev package may suggest
   (but not depend on or recommend) another -dev package as
   an optional dependency, and a library's header file may
   unconditionally include some header file from the latter package.

All of these cases are things I've seen in complex libraries with
many header files; maybe not all of them can be found in Debian
right now.

So... yeah. Thanks for your work, I know you mean well and you are
trying to make the life of Debian developers better, but this
particular approach will likely fail on a non-trivial set of
Debian -dev packages.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Re: autodep8 test for C/C++ header

[Benjamin Drung]

On Mon, 2023-08-07 at 22:52 +0300, Peter Pentchev wrote:
> On Mon, Aug 07, 2023 at 06:43:36PM +, Benjamin Drung wrote:
> > Hi,
> > 
> > while working a whole week on fixing failing C/C++ header compilations
> > for armhf time_t [1], I noticed a common pattern: The library -dev
> > packages was missing one or more dependencies on another -dev package.
> > Over 200 -dev packages are affected.
> > 
> > I propose to add an autodep8 test for C/C++ header files that tries to
> > compile the header file. This will catch issues like missing
> > dependencies and other issues.
> > 
> > Here is a draft for the autopkgtest check script that takes a binary
> > -dev package as parameter:
> > https://github.com/bdrung/bdrung-scripts/blob/compile-header-check/compile-header-check
> > 
> > What do you think? Should I proceed developing and packaging this check
> > script and submit support for it in autodep8?
> > 
> > [1] https://salsa.debian.org/vorlon/armhf-time_t/-/merge_requests/103
> 
> Whlie it does seem an interesting tool at first glance (and thanks for
> doing the work and presenting a proof of concept), I can think of
> several cases when compilation of the concatenated header files would
> fail:

Yes, I expect that several packages would fail to compile and the check
script would need several knobs to tweak (skip certain headers, add or
exclude certain include directories, define a specific C/C++ standand
version, use only C and not C++, etc). A set of common approaches to
solve such failures should be added to the documentation of the check
script (probably including skipping the whole check).

> 1) The library has a "main" header file that must be included before
>any of the others, and it does not come first in lexicographical
>order. It may define typedefs and structure definitions that
>the other header files can use, it may define preprocessor symbols
>that reflect the availability of this or that system header file or
>type; there are also other ways in which another header file
>distributed by the -dev package may depend on the main one.

In this case the non-"main" header could just include the "main" header
as first step. Alternatively, an option to specify headers that should
be included first could be added to the check script.

> 2) As a variation of the above, the -dev package may distribute
>the full set of header files included in the library, and some of
>them may only be included if certain preprocessor symbols are
>defined. Since their use is guarded by conditionals, they are
>allowed to unconditionally include system-specific header files
>that are only available on e.g. Windows or NetBSD or Darwin, etc.
>Unconditionally compiling the contents of those files would fail.

The -dev packages could drop shipping unneeded headers (e.g. Windows or
BSD specific ones), some headers could be excluded by a parameter to the
check script, and/or the check script could allow defining some names
(pass -D name=definition to gcc).

> 3) The -dev package may distribute the full set of header files
>included in the library, and some of them may be mutually exclusive
>and impossible to combine. For example, a header file may include
>either this or that other header file based on preprocessor
>defintions (OS type, features enabled, etc), and the included
>files may both define a function with the same name, but different
>contents.

That one is trickier to reflect in the check script.

> 4) Some of the library's header files may not be supposed to be
>included in all cases; the library's -dev package may suggest
>(but not depend on or recommend) another -dev package as
>an optional dependency, and a library's header file may
>unconditionally include some header file from the latter package.

Either exclude the header from the check script or not ship this header
file in the -dev package.

> All of these cases are things I've seen in complex libraries with
> many header files; maybe not all of them can be found in Debian
> right now.

When you look at check-armhf-time_t [2] you will find all those
mentioned cases and some more.

> So... yeah. Thanks for your work, I know you mean well and you are
> trying to make the life of Debian developers better, but this
> particular approach will likely fail on a non-trivial set of
> Debian -dev packages.

I expect this approach to work for most packages, fail for several
packages due to bugs in the package (missing dependencies and a bunch of
other issues like missing double include protection) and some will fail
with the reasons above.

According to [3] there are 5360 C/C++ -dev package and only 1900 -dev
packages (35%) did not compile out of the box [4]. The majority of those
1900 -dev packages do not compile due to bugs in the package (judging
from the workaround that we apply in [2]).

IMO having this check for 90% of the packages to catch bugs and
disabling it for 10% is bette

Issues in the Patch Tagging Guidelines

[Guillem Jover]

Hi!

Lately I've been updating metadata in patches in packages I maintain and
noticed several issues with the Patch Tagging Guidelines, and after Lucas
created the new great patches UDD service [P] and we discussed some
other issues there, it looked like the guidelines could do with some
fixes and updates.

  [P]  also part of DMD.

The following list are some of the issues or things that might deserve
to be clarified, fixed or updated (for reference the current guidelines
can be found at ):

* dpatch complicates parsing, it is deprecated, probably worth dropping
  support for it.

* Although the guidelines seem to intend for git formatted patches to be
  supported, the actual specification of the format is not very clear
  on its usage and a strict reading does not really allow it.

  - There is a requirement for the first field to appear on the first
line, but git formatted patches start with «From ».
  - You cannot easily add custom Patch Guideline patches into the first
git stanza, those need to go into the git trailers in the commit
message, separated by whatever text is found in the description,
which does not follow the deb822 format.
  - Having to store the patch guideline fields in git commit trailer
fields might mean these pollute the patch which might need to be
removed before submitting upstream.

* Forwarded does not support recording it being sent to an email address.
  Not all upstreams have a public mailing list or web site to file reports
  or send comments to, and it might be worth allowing a mailto: reference,
  or simply an email address.

* Forwarded lists "yes" as a valid implicit value, but does not make it
  clear whether an explicit one should be supported. If a mailto: or
  email is accepted then this is probably less of an issue. I've also
  used this value when I have sent the patch upstream and it has been
  applied before I have gotten around to updating the patch metadata,
  but I guess at that point not providing the field would also be
  fine.

* Forwarded fuzzy specification means parsing its values is rather hard,
  see UDD .
  It would be better to be strict here. In general choosing to be
  fuzzy about the whole specification with the intent to help humans,
  I think means that programs have a hard time (see UDD above, and
  lintian, where both disagree on semantics) and even humans can get
  more confused when crafting or parsing them.

* It is not clear, but I think «Origin: vendor» should be clarified to
  state that the actual vendor name should be included if there is no
  other reference (such as an URL) as in say «Origin: vendor, Debian»?
  Otherwise an undefined vendor is not really distinguishable from the
  «other» value as it could be any vendor. Also because if a «vendor»
  maintainer has created the patch then there might be no URL to point
  to except for the VCS it is kept in (if any at all).

* For Applied-Upstream it is not easy to predict what will be the
  future upstream version that the patch will be included in. I've opted
  for stuff like «3.2.1+, commit:» when 3.2.1 is the last release,
  but that does not seem optimal.

* The git Date field could somehow be used in place of Last-Update (even
  though the Committer Date instead of the Author Date is what matches
  here more closely, but which is not available from «git format-patch»).

* Add new metadata to track single-debian-patch autogenerated patches,
  perhaps a new «Autogenerated: yes» or perhaps better something like
  «Origin: autogenerated, by:dpkg-source» (or similar descriptive thing)?
  These should in general not be warned as needing to be forwarded
  upstream, at least not as-is (dpkg-source in 1.22.0 will add a
  «Forwarded: not-needed» for these though).

* The language could use some clarification and standardize on the field
  and stanza naming used in other parts of the deb822 ecosystem instead
  of headers and sets of headers and similar.


This is my current list, Lucas (CCed) probably has other stuff.

Thanks,
Guillem

Re: autodep8 test for C/C++ header

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Benjamin Drung (2023-08-07 20:43:36)
> while working a whole week on fixing failing C/C++ header compilations for
> armhf time_t [1], I noticed a common pattern: The library -dev packages was
> missing one or more dependencies on another -dev package.  Over 200 -dev
> packages are affected.
> 
> I propose to add an autodep8 test for C/C++ header files that tries to
> compile the header file. This will catch issues like missing
> dependencies and other issues.
> 
> Here is a draft for the autopkgtest check script that takes a binary
> -dev package as parameter:
> https://github.com/bdrung/bdrung-scripts/blob/compile-header-check/compile-header-check
> 
> What do you think? Should I proceed developing and packaging this check
> script and submit support for it in autodep8?

yes please!

I've manually written similar scripts for my own packages in the past with the
same reason: find missing dependencies of -dev packages. Here is an example of
what I wrote for ros-* packages:

https://sources.debian.org/src/ros-image-pipeline/1.17.0-1/debian/tests/compilation/

Thanks!

cheers, josch

signature.asc
Description: signature

Re: autodep8 test for C/C++ header

[Sune Vuorela]

On 2023-08-07, Benjamin Drung  wrote:
> while working a whole week on fixing failing C/C++ header compilations
> for armhf time_t [1], I noticed a common pattern: The library -dev
> packages was missing one or more dependencies on another -dev package.
> Over 200 -dev packages are affected.

I don't think this is a important problem that some headers might have
special conditions for use. I'd rather have our developers spend time
fixing other issues than satisfying this script.

Is it a problem that Qt -dev packages also ships windows, mac or android
specific addons headers? I don't think so. Rather the opposite. When
doing cross platform work, it is nice that grepping across the includes,
I also see some of the platformspecific functions in separate files.

Is it a problem that a header file is also shipped that provides
integration with other-big-thing but 99% of developres/downstream users
don't care about and no Depends is in place? I don't think that's a
problem. I'd rather have the header available for the 1% than having to
create an extra -dev package just for that.

Debian development resources is a finite resource, so let's not waste
it.

/Sune