Bug#1019961: ITP: fast-float -- Implementation of the C++ from_chars functions for float and double types

[Fukui Daichi]

Package: wnpp
Severity: wishlist
Owner: Fukui Daichi 
X-Debbugs-Cc: debian-devel@lists.debian.org, a.dog.will.t...@akane.waseda.jp

* Package name: fast-float
  Version : 3.5.1
  Upstream Author : Daniel Lemire 
* URL : https://github.com/fastfloat/fast_float
* License : MIT or Apache
  Programming Lang: C++
  Description : Implementation of the C++ from_chars functions for float 
and double types

Reason for ITP:
c4core depends on fast-float [0].
rapidyaml [1] depends on c4core.
Moreover, jsonnet [2] depends on rapidyaml.

[0] https://github.com/biojppm/c4core/blob/v0.1.9/.gitmodules
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003397
[2] https://tracker.debian.org/pkg/jsonnet

Maintenance plan:
Because I am a novice in debian packaging, I would like to
ask for someone who can review my upload. I need a sponsor too.

Bug#1019967: ITP: caps2esc -- Filter for dual function Ctrl and Esc key at CapsLock

[Osamu Aoki]

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

* Package name: caps2esc
  Version : 0.3.2
  Upstream Author : Francisco Lopes 
* URL : https://gitlab.com/interception/linux/plugins/caps2esc
* License : MIT
  Programming Lang: C
  Description : Filter for dual function Ctrl and Esc key at CapsLock

Using caps2esc with interception-tools offers the optimal keyboard
experience for vi/Vim/NeoVim aficionados under Wayland/X/Linux console.

 * Dual function Ctrl and Esc key at CapsLock key location
 * CapsLock function key at Esc key location

Background:

This is one of the simplest but hugely useful companion filter program
to mangle evdev data with interception-tools.  Basically, xmodmap-like
functionality is realized at the kernel level in this way.

This recommends interception-tools which was just accepted to Debian
unstable.

R³ by default: not for bookworm

[Adam Borowski]

Hi!
A few months ago I ran a test rebuild of packages that lack
Rules-Requires-Root settings.  Alas, I've forgotten to post the
results, doing so now.

A few packages had a value of R³ other than "no" / "binary-targets",
these are deprecated now; bugs filed.

This leaves three states: "no", "binary-targets", unset.

The process of adding/changing a field in "control" differs between the
three source formats we have.

Of these, the most involved format is 1.0 -- you need to repack the
whole source.  And quite a bunch of packages fail that step, not even
letting me to modify anything.  I guess FTBS bugs need to be enforced...
Almost any format 1.0 package with R³ unset does so not because of an
actual need for fakeroot, but because of an ancient build system and a
decade or two of neglect.
Verdict: outside of the X Strike Force, these packages need their
debian/rules nuked from the orbit, and not for R³ reasons.


Format "3.0 (native)":
The complete list of packages that FTBFS if you set them to R³:no is:

apt-xapian-index
base-files
bombardier
bootcd
cvs-buildpackage
debdelta
debian-installer-netboot-images
debian-policy
dict-gcide
ethstatus
extrepo
gcc-10-cross-mipsen
gcc-10-cross
gcc-11-cross-mipsen
gcc-11-cross-ports
gcc-11-cross
gcc-12-cross-mipsen
gcc-12-cross
gopher
gup
hpsockd
latex-cjk-chinese-arphic
mailcap
menu
molly-guard
moonshot-trust-router
murrine-themes
nagios-plugins-contrib
palo
shellia
shim-helpers-amd64-signed
simplesnap
sleepd
statnews
synaptic
ucf
umegaya
witalian
wspanish
wzip

fwupd-{arm64,armhf,i386}-signed, partman-prep, pmon-update, s390-*,
shim-helpers-{arm64,i386}-signed, zipl-installer are !amd64 -- skipped.


Format "3.0 (quilt)":
In a pile of build logs that looks incomplete:

408 Status: attempted
  6 Status: failed
 32 Status: given-back
 15 Status: skipped
  12387 Status: successful

This doesn't look low enough to warrant a MBF.

Thus: let's revisit R³ being required after Bookworm.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Bestest pickup line:
⢿⡄⠘⠷⠚⠋⠀ "Cutie, your name must be Suicide, cuz I think of you every day."
⠈⠳⣄

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

[Adam Borowski]

On Sat, Sep 17, 2022 at 02:30:45AM +0100, Luca Boccassi wrote:
> Unless any new issue pops up, I'll upload i-s-h to unstable to start
> the transition tomorrow evening.

... and you ignored anything you don't like, and uploaded ANYWAY.

Despite even the GR talk, which you folks _explicitely requested_.

Not amussed.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄

Re: R³ by default: not for bookworm

[Guillem Jover]

Hi!

On Sun, 2022-09-18 at 03:39:43 +0200, Adam Borowski wrote:
> A few packages had a value of R³ other than "no" / "binary-targets",
> these are deprecated now; bugs filed.

Deprecated by who or what?

> The process of adding/changing a field in "control" differs between the
> three source formats we have.

Hmm, I'm not sure I understand this statement.

> Of these, the most involved format is 1.0 -- you need to repack the
> whole source. And quite a bunch of packages fail that step, not even
> letting me to modify anything.  I guess FTBS bugs need to be enforced...

Nor this one. Could you give more details?

> Almost any format 1.0 package with R³ unset does so not because of an
> actual need for fakeroot, but because of an ancient build system and a
> decade or two of neglect.

Lack of debhelper/dh usage certainly makes adding the field more
challenging, yes.

> Format "3.0 (native)":
> The complete list of packages that FTBFS if you set them to R³:no is:
[…]

> Format "3.0 (quilt)":
> In a pile of build logs that looks incomplete:
> 
> 408 Status: attempted
>   6 Status: failed
>  32 Status: given-back
>  15 Status: skipped
>   12387 Status: successful

Thanks for these checks! But in addition to checking whether these failed,
did you check that they ended up with the same user:group and perms (such
as SUID), as before setting the field?

> Thus: let's revisit R³ being required after Bookworm.

My current thinking though, has been to change the default via something
like:

  

Thanks,
Guillem

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

[Luca Boccassi]

On Sun, 2022-09-18 at 03:46 +0200, Adam Borowski wrote:
> On Sat, Sep 17, 2022 at 02:30:45AM +0100, Luca Boccassi wrote:
> > Unless any new issue pops up, I'll upload i-s-h to unstable to
> > start
> > the transition tomorrow evening.
> 
> ... and you ignored anything you don't like, and uploaded ANYWAY.
> 
> Despite even the GR talk, which you folks _explicitely requested_.
> 
> Not amussed.

Nothing was ignored. I have no idea what you mean by "you folks", but I
certainly did not request nor talk about any GR, and it was never
mentioned in any of the long threads on the subject in the past few
months. The agreed plan was executed exactly as discussed and
communicated in the past ~3 months, as demonstrated plainly and openly
by the links contained in the mail to d-d-announce, and it will go
ahead as decided.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1020070: ITP: ruby-traces -- Application instrumentation and tracing

[Hideki Yamane]

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

* Package name: ruby-traces
  Version : 0.7.0
  Upstream Author : Samuel G. D. Williams (http://www.codeotaku.com/)
* URL : https://github.com/socketry/traces
* License : MIT
  Programming Lang: Ruby
  Description : Application instrumentation and tracing

 Traces captures nested traces during code execution in a vendor agnostic way.

 This package is needed by another ruby package (ruby-async-http) update.