Bug#1063440: ITP: onedriver -- native Linux filesystem for Microsoft OneDrive

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: onedriver
  Version : 0.14.1
  Upstream Authors: Jeff Stafford 
  URL : https://github.com/jstaf/onedriver
* License : GPL-3-or-later
  Description : native Linux filesystem for Microsoft OneDrive
 This is a native Linux filesystem for Microsoft Onedrive Onedriver is a 
native
 Linux filesystem for Microsoft Onedrive. Files and metadata are 
downloaded

 on-demand instead of requiring you to sync your entire account to disk.

Bug#1063442: ITP: tracy -- Real time, nanosecond resolution, remote telemetry, hybrid frame and sampling profiler for games and other applications

[Alan M Varghese]

Package: wnpp
Severity: wishlist
Owner: Alan M Varghese 
X-Debbugs-Cc: debian-devel@lists.debian.org, a...@digistorm.in

* Package name: tracy
  Version : 0.10.0
  Upstream Contact: Bartosz Taudul 
* URL : https://github.com/wolfpld/tracy
* License : BSD-3-Clause
  Programming Lang: C++, C
  Description : Real time, nanosecond resolution, remote telemetry, hybrid 
frame and sampling profiler for games and other applications

Tracy is a real time, nanosecond resolution, remote telemetry,
hybrid frame and sampling profiler for games and other applications.
Tracy supports profiling CPU (Direct support is provided for C, C++, and Lua 
integration. At the same time, third-party bindings to many other languages 
exist on the internet, such as Rust, Zig, C#, OCaml, Odin, etc.), GPU (All 
major graphic APIs: OpenGL, Vulkan, Direct3D 11/12, OpenCL.), memory 
allocations, locks, context switches, automatically attribute screenshots 
to captured frames, and much more.

Tracy is a "debug build" dependency for Hyprland[1] and is included in
the upstream tarball for that project. I am attempting to package it
separately to meet the requirements and guidelines of the Debian
project[2].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040971
[2] https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies

Re: Bug#1063329: libselinux1t64: breaks system in upgrade from unstable

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:

Helmut> pam seems difficult: | extern time_t
Helmut> pam_misc_conv_warn_time; /* time that we should warn user */
Helmut> | extern time_t pam_misc_conv_die_time; /* cut-off time for
Helmut> input */

Helmut> We cannot symbol-version these in a reasonable way. All we
Helmut> could do is ask upstream for a real soname bump. We have a
Helmut> slight advantage here: On little endian (such as armhf), we
Helmut> can extend this to 64bit and 32bit accesses will continue to
Helmut> work for small values. However, doing this to m68k would
Helmut> break horribly. I also couldn't find any in-Debian users of
Helmut> these symbols (super merely vendors pam source), so just
Helmut> bumping it and accepting breakage (Guillems option 1) might
Helmut> be worth a go?

Steve and I are unaware of usage in Debian either.

--Sam


signature.asc
Description: PGP signature

Re: 64-bit time_t transition in progress

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Fri, 2 Feb 2024 at 13:22, Steve Langasek  wrote:
>
> Dear developers,
>
> A number of you will have noticed already that the 64-bit time_t transition
> is now in progress in Debian experimental.
[snip]

>qt6-virtualkeyboard
>qt-qml-models

For all Qt packages, be it Qt 5 or 6, you only need to modify
libqtXcoreX. The rest of the packages will just follow suite,
**nothing** in Qt does not depends upon libQtCoreX. In fact I would
say that by doing that you get even the whole KDE stack in.


-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Re: 64-bit time_t transition in progress

[Lisandro Damián Nicanor Pérez Meyer]

On Thu, 8 Feb 2024 at 13:06, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> Hi!
>
> On Fri, 2 Feb 2024 at 13:22, Steve Langasek  wrote:
> >
> > Dear developers,
> >
> > A number of you will have noticed already that the 64-bit time_t transition
> > is now in progress in Debian experimental.
> [snip]
>
> >qt6-virtualkeyboard
> >qt-qml-models
>
> For all Qt packages, be it Qt 5 or 6, you only need to modify
> libqtXcoreX. The rest of the packages will just follow suite,
> **nothing** in Qt does not depends upon libQtCoreX. In fact I would
> say that by doing that you get even the whole KDE stack in.

And any other thing using Qt, be it libraries or not.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Re: 64-bit time_t transition in progress

[Ansgar]

Hi,

On Fri, 2024-02-02 at 08:21 -0800, Steve Langasek wrote:
> Once all of these packages have built in experimental and we have identified
> and addressed all adverse interactions with the usrmerge transition, the
> plan is:
> 
>  - dpkg uploaded to unstable with abi=time64 enabled by default[5]

How does this work when a user builds their own software using any
library build with abi=time64? They will still get a 32bit time_t &
others unless they use dpkg-buildflags as well, won't they?

If we already change ABI, why not change this in the toolchain (glibc,
gcc) so also user-build packages use the correct ABI? That was what
happened for other ABI changes like the C++ ABI change as far as I
remember.

Ansgar

Re: 64-bit time_t transition in progress

[Matthias Klose]

On 08.02.24 20:07, Ansgar wrote:

Hi,

On Fri, 2024-02-02 at 08:21 -0800, Steve Langasek wrote:

Once all of these packages have built in experimental and we have identified
and addressed all adverse interactions with the usrmerge transition, the
plan is:

  - dpkg uploaded to unstable with abi=time64 enabled by default[5]


How does this work when a user builds their own software using any
library build with abi=time64? They will still get a 32bit time_t &
others unless they use dpkg-buildflags as well, won't they?

If we already change ABI, why not change this in the toolchain (glibc,
gcc) so also user-build packages use the correct ABI? That was what
happened for other ABI changes like the C++ ABI change as far as I
remember.


for the GCC 5 changes (std::string ABI), libstdc++ provided the ABI for 
both the old and the new ABI, defaulting to the new ABI.


We can define that macro in GCC, however at the moment I'm unsure how to 
turn it off when passing explicitly -U.  When doing that in GCC, it also 
should be done in other compilers like clang.


And there should be an explicit document/wiki page, which architectures 
(including ports) will have this turned on.  For now I only know that it 
will be turned on for armhf, and not for i386.


Matthias

Bug#1063486: ITP: rust-librsvg -- library to render SVG images to Cairo surfaces

[Matthias Geiger]

Package: wnpp
Severity: wishlist
Owner: Matthias Geiger 
X-Debbugs-Cc: debian-devel@lists.debian.org, jbi...@debian.org, 
werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-librsvg
  Version : 2.57.1
  Upstream Contact: Federico Mena
* URL : https://gitlab.gnome.org/GNOME/librsvg/
* License : LGPL-2.1+
  Programming Lang: Rust
  Description : library to render SVG images to Cairo surfaces

This is needed to enable svg support in loupe. Note that this ITP does
only cover the rust library; the "regular" library is already built
from src:librsvg. Since src:librsvg currently builds vendored it can't
provide rust-librsvg, thus my ITP.

best,

werdahias

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmXFP3UVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1yrIQALd/qlbJvTQcb560v5vXdOyaKcko
QIvkBR+vUZGEc/XMzAV+yuGlDScCaFfuFmQ2VZrBZJEUmDA48cWILqoclTIhk8/Q
9WURLXHj2vQlK/jlG/BxdTyAWMsnERYD8E2PnQ/MxhZ7ZwZ4md3CkuAzjQuulcfq
9r3/Q5a3LN7eP5VnJKZd9Ajq+HmeE75mljx+2zlCEEKpi2zaKw7zPqd2v7pi0tZl
boxqZQnq0k8fsmiY+HAM4QHc2DQCO/GLZ79mVNpF6dibwEJl783mDXIdO7oqfOko
xskB87lM7OBGHD0+jgk1SJi2GgMuVvdk79eCs9aWdrweNHSID8yqIO+QC/JW4FYV
shLpHqH71t30PuaVd0J9VHk/7TwZSmsJpPAx93pPYXgtr5kVpORpNiiaPU2VRnUz
EzXDIVjYr1vfjd4eVSRNZ5HXDUwvHxZAymCZAhxFnsBqrKrq64tCx740mVx+75tU
KVNQrq/Zz1CvL+13hYaNNgDQ4OCuRQN2s7462prt1enCsov2CVkHRvPVLa4b8Vwy
FphZcH/cFmvpwkSfcABG0M8Gl8OtwN+o7F0EeJQCYTAlvpGLiDNpaum+mwCe92qH
M8xnj1kcmYRFgJP+NhjcNgooHIOvdVs85evOymfJiQ5RIt63zm0rh2obdSbLFU9p
tV4U2ZNipxeURG3P
=pCNR
-END PGP SIGNATURE-

Bug#1063489: ITP: golang-github-rluisr-mysqlrouter-exporter -- Prometheus exporter for MySQL router

[Lena Voytek]

Package: wnpp
Severity: wishlist
Owner: Lena Voytek 
X-Debbugs-Cc: debian-devel@lists.debian.org, l...@voytek.dev

* Package name: golang-github-rluisr-mysqlrouter-exporter
  Version : 5.0.0
  Upstream Author : Hasegawa Takuya 
* URL : https://github.com/rluisr/mysqlrouter_exporter
* License : Apache
  Programming Lang: Go
  Description : Prometheus exporter for MySQL router

mysqlrouter-exporter extracts data and metrics from the mysql
router for monitoring using Prometheus tools. It provides a
useful connection between MySQL databases and the Prometheus
ecosystem. For more information on Prometheus exporters see
https://prometheus.io/docs/instrumenting/exporters/

I intend to actively maintain this package within the Debian Go
Packaging team.

Bug#1063496: ITP: golang-github-rluisr-mysqlrouter-go -- Go client for MySQL router

[Lena Voytek]

Package: wnpp
Severity: wishlist
Owner: Lena Voytek 
X-Debbugs-Cc: debian-devel@lists.debian.org, l...@voytek.dev

* Package name: golang-github-rluisr-mysqlrouter-go
  Version : 1.2.0
  Upstream Author : Hasegawa Takuya 
* URL : https://github.com/rluisr/mysqlrouter-go
* License : Apache
  Programming Lang: Go
  Description : Go client for MySQL router

mysqlrouter-go acts as a client for MySQL Router using its
rest API. It provides a useful way to interact with MySQL
databases in Go.

I intend to actively maintain this package within the Debian Go
Packaging team.

Re: Transparency into private keys of Debian

[Hans-Christoph Steiner]

> In business, such things are confirmed (often badly) by independent
> audit. For a volunteer-driven community effort, we have to rely on
> everyone to exercise their best judgement in these sorts of matters.

Debian could also get independent, professional audits.  I think it would be a 
good use of the Debian pot of money, for example.  Or someone could submit a 
proposal to get Debian audited.  I'll be either Open Tech Fund or NLnet would do it:


https://www.opentech.fund/labs/red-team-lab/

Open Tech Fund already funds Tails, which is based on Debian.

.hc

Re: Transparency into private keys of Debian

[Jeremy Stanley]

On 2024-02-08 23:44:21 +0100 (+0100), Hans-Christoph Steiner wrote:
> > In business, such things are confirmed (often badly) by independent
> > audit. For a volunteer-driven community effort, we have to rely on
> > everyone to exercise their best judgement in these sorts of matters.
> 
> Debian could also get independent, professional audits.
[...]

Perhaps of a sort, but not the kind I'm accustomed to being
performed in the corporate world. Having auditors visit every DD's
home to watch them upload packages and confirm they're following the
claimed secure workflows seems entirely intractable. Sure you could
ask every DD to fill out a questionnaire, but if you don't trust
them to all follow documented practices then why would you trust
them to accurately answer survey questions either?
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Bug#1063508: ITP: node-long -- Class for representing 64-bit two's-complement integer value

[Marco Trevisan]

Package: wnpp
Severity: wishlist
Owner: Marco Trevisan (Treviño) 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-long
  Version : 5.2.3
  Upstream Author : Daniel Wirtz 
* URL : https://github.com/dcodeIO/long.js#readme
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : Class for representing 64-bit two's-complement
integer value

 A Long class for representing a 64 bit two's-complement integer value
 derived from the Closure Library for stand-alone use and extended with
 unsigned support.
 .
 This is a class used by various modules that does not use newer bigint.
 .
 Node.js is an event-based server-side JavaScript engine.

This is a tiny module that is needed for protobufjs (bug #977564),
although being widely used according to npm stats, I feel it's better to
package it as standalone and not as grouped package.

Salsa repository is at:
 https://salsa.debian.org/3v1n0-guest/node-esm2umd/-/tree/debian/latest

Please mark the debian/latest as default branch since I can't change it myself.

The package had a dependency on a very tiny project (esm2umd) that was
just basically a tiny wrapper to babel. I've also prepared the packaging
for it [1], but given that such project has not a clear license (I
mailed the maintainer meanwhile), I preferred to avoid using it, also
because it's really just a script using babel and I have been able to
easily re-implement it, making the build process slightly bigger

The package needs sponsor, since I'm only a maintainer, but I'll be
happy keeping the maintenance of it.

I've given access to the js salsa team.

[1] https://salsa.debian.org/3v1n0-guest/node-esm2umd/

Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)

[Guillem Jover]

Hi!

On Fri, 2024-02-02 at 08:21:57 -0800, Steve Langasek wrote:
> Once all of these packages have built in experimental and we have identified
> and addressed all adverse interactions with the usrmerge transition, the
> plan is:
> 
>  - dpkg uploaded to unstable with abi=time64 enabled by default[5]

> [5] https://bugs.debian.org/1037136

I just realized recently that I think it'd be better to change a bit
the semantics of the abi time64 feature on i386, where by default it
will not include the time64 flags (as before), but if the maintainer
has requested it explicitly via DEB_BUILD_OPTIONS=abi=+time64, then
it should enable it also on i386 (changed behavior).

The reason is that this does not now break ABI for any package (in Debian
or out of Debian) that might have already opted-in to that feature, it
does not require adding all the necessary flags manually if one wants
to opt-in on i386, and makes it possible to selectively enable time64
on packages where the binary backwards compatibility make no sense
(such as dpkg itself, where this has already been requested and where
I mentioned in the libselinux report that I'd like to do that, and
where otherwise the port might be unable to install stuff at all).
Otherwise the majority of packages should have no need to explicitly
declare abi=+time64 as that's going to be the default (except for i386).

I've queued these updated semantics, including manual page updates and
unit tests into the next/time64 branch

(the previous semantics and incomplete commits are still in the
next/time64-default branch), which I'd be merging into main close to
the release, once there's agreement on the dpkg upload date.

If someone has issue with this, let me know and we can discuss the
merits of going some other way.

Thanks,
Guillem