Re: Bug#1073496: ITP: requests-mock -- Python module to stub HTTP requests in testing code

[Thomas Goirand]

On 6/16/24 20:48, Julian Gilbey wrote:

On Sun, Jun 16, 2024 at 05:20:37PM +0200, Bastian Blank wrote:

On Sun, Jun 16, 2024 at 03:43:38PM +0100, Julian Gilbey wrote:

* Package name: requests-mock
   Version : 1.12.1
   Upstream Author : Jamie Lennox
* URL : https://github.com/jamielennox/requests-mock
* License : Apache-2.0
   Programming Lang: Python
   Description : Python module to stub HTTP requests in testing code
  This module creates a custom adapter that allows one to predefine responses
  when certain URIs are called when using the `requests` module.


Is this something different then the already exising
python-requests-mock?


Oh, oops - I somehow missed that.

Closing this ITP then.

Julian


Hi,

I always welcome co-maintainer! :)

Cheers,

Thomas Goirand (zigo)

Bug#1073786: ITP: rdfsx -- CLI tool to process RDF with ShEx, SHACL or DCTAP

[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: rdfsx
  Version : 0.0.12
  Upstream Contact: Jose Emilio Labra Gayo 
* URL : https://www.weso.es/shapes-rs/
* License : Apache-2,0 or Expat
  Programming Lang: Rust
  Description : CLI tool to process RDF with ShEx, SHACL or DCTAP

 rdfsx is a command-line tool
 to inspect and validate RDF data
 using ShEx, SHACL or DCTAP.
 .
 Resource Description Framework (RDF) is a standard model
 for data interchange on the Web.
 .
 Shape Expressions (ShEx) is a data modelling language
 for defining schemas for RDF graphs.
 .
 Shapes Constraint Language (SHACL) is a data modelling language
 for describing constraints for RDF graphs.
 SHACL is a W3C standard.
 .
 Dublin Core Tabular Application Profiles (DCTAP) is a simple model
 for defining an application profile -
 i.e. metadata usage for a specific application.

This package will be maintained in the collaborative debian section of
Salsa, at .

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmZxYn4ACgkQLHwxRsGg
ASH7Bw/7BsNSIMe6UnlhdHd0eFUZp32Zkw1RpKY0LD2HPEUDnMGHoq+kZyNbLAwL
/QnY3rXhVHhfmiZw6xSB7sPbMr52nwNLn8oonfGonyeRoBU88/x75juob7fjh40Z
00bVoFy3G3GGqCV7TVHxxSCkpjs6D8onilNU3ICRHeCx0jkbzUCNtssC0zc58h75
WFtFP9Wa4IAyMDUcBm1ey07YInA9J94PjmhVscWhQ8fCLxtfiRZZU1Bkf9OZhZsT
d9DRYSQSZQVnW/2J8vOh4iBDrQxdkZAqpDsLTg1wyHxyuAswfRk/tChoPp1R1swv
a8xF3NGx+YzOAyBTvpHg0j17syiw4E1B0Yjj3m/HaEfMJW9jEVY+mDyzN14UWv3f
nWT/XYUPXLcIkwe4aHyRt5t3Zuv2AJ/u5QyiPG8oleY0LC8b3Y5SrEgd12epjw9/
nLVKeNwQDguYUsogCqx70B/ew/arYsvhuZY1Jg6t2BWj49mqTxLz7fuPKyShkrvi
mI9oHvaLyPGRrJCt8PwKaRzNtNhaOXzyWYd8OBCUqJcKP0tR5OdCJUPz6KAGa1ap
tOrmV8Vbd6OMSkopMAjG0651XTSXQl9iyZb08nBxno7U4Fv3LPlMGIinge9gp/ed
HvNfdLVpp8fl3G0XQ0KbdHYSyP/sjatdTUhythSA1Tax39iPpWY=
=xwcY
-END PGP SIGNATURE-

Complex Cameras Micro-conference in LPC and Debian

[Ricardo Ribalda Delgado]

Hi

I am Ricardo, a newbie DD, and a kernel camera developer. Last year I
made a presentation about complex cameras in the Cambridge MiniDebconf
[1]:

There is a big number of cameras that are not supported by Debian and
that number grows everyday [2][3]. In phones it is almost impossible to
find a phone with a working camera upstream.

The current camera situation mirrors the graphics card from a decade
ago: vendors and upstream efforts are disconnected, leaving distros
and users struggling.

I am co-organizing a conference during Linux Plumbers to address this
issue [4]:  The plan is that vendors, distros, media maintainers and
DRM maintainers sit on the same table and collaborate.

I strongly believe Debian's participation in this conference is
crucial. We need to make sure that whatever solution is implemented by
the vendors can also be used by our users.

I was wondering how many people are interested in this topic (I guess
the kernel team?), and what is needed for someone in the project to
talk on behalf of the project.

I can share my point of view as DD and what I understand are the
licensing requirements for a package to exist in our distro... but
there is probably a better person to represent Debian than me. Plus I
am already representing another distro, ChromeOS (my employer).

Best regards!

[1] https://wiki.debian.org/DebianEvents/gb/2023/MiniDebConfCambridge/Ribalda
[2] https://wiki.ubuntu.com/IntelMIPICamera
[3] https://kernel-recipes.org/en/2023/schedule/the-arm-laptop-project/
[4] https://lpc.events/event/18/contributions/1679/

---
Ricardo


signature.asc
Description: PGP signature

Re: Seeking consensus on file conflict between python3-proto-plus and nanopb

[GCS]

Control: forwarded -1 https://github.com/nanopb/nanopb/issues/977

Hi,

On Mon, Jun 17, 2024 at 7:28 AM László Böszörményi (GCS)  
wrote:
>  Thanks for your patience. I'm here just running back and forth. Going
> to note nanopb upstream this afternoon.
 As promised, I reported it to upstream yesterday. Turns out it was my
bad. Corrected package version will be uploaded soon.

Regards,
Laszlo/GCS

Bug#1073797: ITP: python-graphene-federation -- federation implementation for graphene

[Ananthu C V]

Package: wnpp
Severity: wishlist
Owner: Ananthu C V 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: python-graphene-federation
  Version : 3.2.0
  Upstream Contact: Igor Kasianov 
* URL : https://github.com/graphql-python/graphene-federation
* License : Expat
  Programming Lang: python
  Description : federation implementation for graphene

 Federation support for Graphene, following the Apollo
 federation specifications.

 This is a dependency needed for python-graphene-mongo v0.4.4 update.

Bug#1073802: ITP: oras -- OCI registry client - managing content like artifacts, images, packages

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: oras
  Version : 1.2.0-1
  Upstream Author : OCI Registry As Storage (ORAS)
* URL : https://github.com/oras-project/oras
* License : Apache-2.0
  Programming Lang: Go
  Description : OCI registry cli tool managing content like artifacts, 
images, packages
 ORAS works similarly to tools you may already be familiar with, such as
 docker. It allows you to push (upload) and pull (download) things to and
 from an OCI Registry, and also handles login (authentication) and token
 flow (authorization). What ORAS does differently is shift the focus from
 container images to other types of artifacts.
 .
 ORAS is the de facto tool for working with OCI Artifacts. It treats
 media types as a critical piece of the puzzle. Container images are
 never assumed to be the artifact in question.

Re: Complex Cameras Micro-conference in LPC and Debian

[Ben Hutchings]

On Tue, 2024-06-18 at 15:06 +0200, Ricardo Ribalda Delgado wrote:

[...]
> I am co-organizing a conference during Linux Plumbers to address this
> issue [4]:  The plan is that vendors, distros, media maintainers and
> DRM maintainers sit on the same table and collaborate.
[...]

> I was wondering how many people are interested in this topic (I guess
> the kernel team?), and what is needed for someone in the project to
> talk on behalf of the project.
[...]

I will be attending Plumbers remotely but haven't had a specific
interest in this topic.  What kind of input do you think will be needed
from us?

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.



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

Bug#1073803: ITP: zellij -- terminal workspace with batteries included

[Ananthu C V]

Package: wnpp
Severity: wishlist
Owner: Ananthu C V 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-r...@lists.debian.org

* Package name: zellij
  Version : 0.40.1
  Upstream Contact: Aram Drevekenin 
* URL : https://github.com/zellij-org/zellij
* License : Expat
  Programming Lang: rust
  Description : terminal workspace with batteries included

 Zellij is a workspace aimed at developers, ops-oriented people
 and anyone who loves the terminal. Similar programs are sometimes
 called "Terminal Multiplexers".

 Zellij is designed around the philosophy that one must not sacrifice
 simplicity for power, taking pride in its great experience out of the
 box as well as the advanced features it places at its users' fingertips.

Packaging zellij requires packaging over a hundred crates in its dependency
tree and this number could only grow when it comes to packaging each of the
crates. I am not a DD, which means I need quite active sponsorship to make
packaging this possible. I have been on this effort for sometime now and
have ~50 crates packaged, of which about 20+ are uploaded and the rest are
awaiting upload with RFS. I am a DM, and I could take care of the packages
once they are uploaded to NEW and accepted. And I intend to maintain this
under the rust team umbrella.

Bug#1073804: ITP: rust-leb128 -- read and write DWARF's little endian base 128 variable length integer encoding

[Ananthu C V]

Package: wnpp
Severity: wishlist
Owner: Ananthu C V 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-r...@lists.debian.org

* Package name: rust-leb128
  Version : 0.2.5
  Upstream Contact: Nick Fitzgerald 
* URL : https://github.com/gimli-rs/leb128
* License : Apache-2.0/MIT
  Programming Lang: rust
  Description : read and write DWARF's little endian base 128 variable 
length integer encoding

 Read and write DWARF's "Little Endian Base 128" (LEB128) variable length 
integer encoding.

 The implementation is a direct translation of the pseudocode in the DWARF 4 
standard's appendix C.

One of the many dependencies in the zellij (#1073803) dependencyu tree.

Re: Seeking consensus on file conflict between python3-proto-plus and nanopb

[Yogeswaran Umasankar]

Hi Laszlo,

Thank you so much for your efforts in resolving the conflict.

Best,
Yogeswaran.

On Tue, Jun 18, 2024 at 05:46:55PM +0200, László Böszörményi (GCS) wrote:

Control: forwarded -1 https://github.com/nanopb/nanopb/issues/977

Hi,

On Mon, Jun 17, 2024 at 7:28 AM László Böszörményi (GCS)  
wrote:

 Thanks for your patience. I'm here just running back and forth. Going
to note nanopb upstream this afternoon.

As promised, I reported it to upstream yesterday. Turns out it was my
bad. Corrected package version will be uploaded soon.

Regards,
Laszlo/GCS

Bug#1073810: ITP: golang-github-cloudflare-backoff -- Backoff timer shared between several projects.

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-cloudflare-backoff
  Version : 0.0~git20161212.647f3cd-1
  Upstream Author : Cloudflare
* URL : https://github.com/cloudflare/backoff
* License : BSD-2-clause
  Programming Lang: Go
  Description : Backoff timer shared between several projects.

 Go implementation of "Exponential Backoff And Jitter"
 .
 This package implements the backoff strategy described in the AWS
 Architecture Blog article "Exponential Backoff And Jitter"
 (http://www.awsarchitectureblog.com/2015/03/backoff.html). Essentially,
 the backoff has an interval time.Duration; the *nth* call to backoff
 will return an a time.Duration that is *2 n *interval*. If jitter is
 enabled (which is the default behaviour), the duration is a random value
 between 0 and *2 n * interval*. The backoff is configured with a maximum
 duration that will not be exceeded; e.g., by default, the longest
 duration returned is backoff.DefaultMaxDuration.