Re: [Pkg-pascal-devel] Issue with fpc_3.2.2+dfsg-24 in Sid.

[Abou Al Montacir]

Hi All,

Can anyone help with below issue?

On Sat, 2023-12-30 at 09:17 +0100, Abou Al Montacir wrote:
> Hi All,
> 
> I've uploaded a broken version fpc_3.2.2+dfsg-24 unfortunately.
> This prevents building arch independent packages due to a silly mistake.
> This issue does not appear when you build both binaries and arch independent
> packages thus I did not see it before upload.
> 
> Now, the issue is fixed in fpc_3.2.2+dfsg-25, which managed to build on slow
> building architectures, but all major architectures are now broken.
> 
> I see only two possibilities, either upload manually fpc_3.2.2+dfsg-25 for
> each missing architecture, or get fpc_3.2.2+dfsg-24 removed from archive and
> replaced by fpc_3.2.2+dfsg-23 so that fpc_3.2.2+dfsg-25 can be built.
> 
> Can anyone advise on how to proceed?
-- 
Cheers,
Abou Al Montacir


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

Re: [Pkg-pascal-devel] Issue with fpc_3.2.2+dfsg-24 in Sid.

[Andrey Rakhmatullin]

On Sat, Dec 30, 2023 at 10:58:58AM +0100, Abou Al Montacir wrote:
> > I see only two possibilities, either upload manually fpc_3.2.2+dfsg-25 for
> > each missing architecture, or get fpc_3.2.2+dfsg-24 removed from archive and
> > replaced by fpc_3.2.2+dfsg-23 so that fpc_3.2.2+dfsg-25 can be built.
The second option is not possible.

Re: Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3

[Simon Josefsson]

Packaging of SSH3 is available here:

https://salsa.debian.org/go-team/packages/ssh3
https://salsa.debian.org/jas/ssh3/

Thanks to the Salsa CI/CD pipeline there is an aptly repository
available for easy testing, if anyone would like to experiment or help.

Below you can find a snippet how you can test the SSH3 client and server
via Debian packages, for password and public key authentication, in a
safe container using podman.  I have only tested this on my laptop that
runs Trisquel, but should hopefully be portable.

I am delaying upload to Debian for a while to see if upstream reaches a
conclusion around naming.  I think the name 'ssh3' is unfortunate and
distracts from the effort. See:
.

/Simon

sudo apt install podman
podman run -it --hostname myhost.example --rm debian:unstable
cd
apt update
apt dist-upgrade -y
apt install -y ca-certificates
echo "deb [trusted=yes] 
https://salsa.debian.org/jas/ssh3/-/jobs/5094673/artifacts/raw/aptly unstable 
main" | tee /etc/apt/sources.list.d/ssh3.list
apt update
apt install -y ssh3

apt install -y ssl-cert # creates snakeoil key/cert

passwd # set a test password for 'root' e.g. 'foo'

ssh3-server -cert /etc/ssl/certs/ssl-cert-snakeoil.pem -key 
/etc/ssl/private/ssl-cert-snakeoil.key -enable-password-login -url-path /myurl 
-v &

ssh3 -v -insecure -use-password myhost.example/myurl
# type 'foo' at the prompt, and on successful connection type 'exit' to log out

apt install -y openssh-client # for ssh-keygen
ssh-keygen -t ed25519 -P "" -f /root/.ssh/id_ed25519
cat /root/.ssh/id_ed25519.pub > /root/.ssh3/authorized_identities
ssh3 -v -insecure -privkey /root/.ssh/id_ed25519 myhost.example/myurl
# on successful connection type 'exit' to log out


signature.asc
Description: PGP signature

Re: Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3

[Colin Watson]

On Sat, Dec 30, 2023 at 12:13:28AM +0100, Philipp Kern wrote:
> On 29.12.23 11:30, Simon Josefsson wrote:
> > SSH3 is a complete revisit of the SSH protocol, mapping its semantics on
> > top of the HTTP mechanisms. In a nutshell, SSH3 uses QUIC+TLS1.3 for
> > secure channel establishment and the HTTP Authorization mechanisms for
> > user authentication. Among others, SSH3 allows the following
> > improvements:
> 
> I feel like SSH3 is an unfortunate name. The program claims "SSH3 stands for
> the concatenation of SSH and H3." - well sure, but you're also reusing the
> name of an existing protocol and bump its version. ssh-h3?

I agree - as the Debian OpenSSH maintainer, I'm concerned that this will
cause a new source of user confusion because people will think "ah,
ssh3, that must be better than ssh" (which indeed seems to have been a
deliberate marketing choice by this project) and not realize that it's a
largely incompatible thing.  Not to mention the way that it parses
OpenSSH configuration files, which may work today but I doubt OpenSSH
offers any guarantees that it won't make changes that will break this
independent parser in future.

I also feel that something security-critical like this that's labelled
by upstream as "still experimental" probably shouldn't be in a Debian
release.  Maybe it should be kept in Debian experimental for the time
being?

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Re: [Pkg-pascal-devel] Issue with fpc_3.2.2+dfsg-24 in Sid.

[Otto Kekäläinen]

Hi Abou!

I can't help with the issue at hand, but as general advice for the
future: if you had Salsa-CI enabled at
https://salsa.debian.org/pascal-team/fpc/-/pipelines the build-all and
build-any jobs would have probably caught this before upload.

Just open https://salsa.debian.org/pascal-team/fpc/-/settings/ci_cd
and under "General pipelines" in box "CI/CD configuration file" put
"recipes/debian.yml@salsa-ci-team/pipeline" to activate it. It is
super easy.

More at https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/README.md

Hopefully more and more DDs adopt Salsa-CI, it is such a time saver! :)

Re: [Pkg-pascal-devel] Issue with fpc_3.2.2+dfsg-24 in Sid.

[Abou Al Montacir]

On Sat, 2023-12-30 at 16:05 +, Otto Kekäläinen wrote:
> Hi Abou!
> 
> I can't help with the issue at hand, but as general advice for the
> future: if you had Salsa-CI enabled at
> https://salsa.debian.org/pascal-team/fpc/-/pipelines the build-all and
> build-any jobs would have probably caught this before upload.
> 
> Just open https://salsa.debian.org/pascal-team/fpc/-/settings/ci_cd
> and under "General pipelines" in box "CI/CD configuration file" put
> "recipes/debian.yml@salsa-ci-team/pipeline" to activate it. It is
> super easy.
> 
> More at
> https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/README.md
> 
> Hopefully more and more DDs adopt Salsa-CI, it is such a time saver! :)
Thank you Otto fo this advice.
Sure I should setup this CI/CD on salsa.
I'll come back to you if I need help.
-- 
Cheers,
Abou Al Montacir


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

Re: Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3

[Simon Josefsson]

Colin Watson  writes:

> On Sat, Dec 30, 2023 at 12:13:28AM +0100, Philipp Kern wrote:
>> On 29.12.23 11:30, Simon Josefsson wrote:
>> > SSH3 is a complete revisit of the SSH protocol, mapping its semantics on
>> > top of the HTTP mechanisms. In a nutshell, SSH3 uses QUIC+TLS1.3 for
>> > secure channel establishment and the HTTP Authorization mechanisms for
>> > user authentication. Among others, SSH3 allows the following
>> > improvements:
>> 
>> I feel like SSH3 is an unfortunate name. The program claims "SSH3 stands for
>> the concatenation of SSH and H3." - well sure, but you're also reusing the
>> name of an existing protocol and bump its version. ssh-h3?
>
> I agree - as the Debian OpenSSH maintainer, I'm concerned that this will
> cause a new source of user confusion because people will think "ah,
> ssh3, that must be better than ssh" (which indeed seems to have been a
> deliberate marketing choice by this project) and not realize that it's a
> largely incompatible thing.  Not to mention the way that it parses
> OpenSSH configuration files, which may work today but I doubt OpenSSH
> offers any guarantees that it won't make changes that will break this
> independent parser in future.

I share these concerns, so I'll delay the upload for now.  I'm hoping
upstream will rename the project to something less confusing.

> I also feel that something security-critical like this that's labelled
> by upstream as "still experimental" probably shouldn't be in a Debian
> release.  Maybe it should be kept in Debian experimental for the time
> being?

Sounds good if nothing happens on the naming front in the next
weeks/months.  Let's wait and see a bit.

One alternative that was suggested was to call the package something
else in Debian.  'golang-ssh3'?  'go-ssh3'?  Still somewhat problematic
as long as the 'ssh3' name is in there.

/Simon


signature.asc
Description: PGP signature

Re: Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3

[Emmanuel Arias]

[snip]


I agree - as the Debian OpenSSH maintainer, I'm concerned that this will
cause a new source of user confusion because people will think "ah,
ssh3, that must be better than ssh" (which indeed seems to have been a

This was my first think

[snip]

--
cheers,
Emmanuel Arias

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  eam...@debian.org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: 13796755BBC72BB8ABE2AEB5 FA9DEC5DE11C63F1
 ⠈⠳⣄

Re: Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3

[Marvin Renich]

* Simon Josefsson  [231230 11:54]:
> One alternative that was suggested was to call the package something
> else in Debian.  'golang-ssh3'?  'go-ssh3'?  Still somewhat problematic
> as long as the 'ssh3' name is in there.

There is no reason the package (source and binary) can't be named ssh-h3
even if the binary is not renamed.  I would not keep the "ssh3" part in
the package name.

...Marvin

Re: Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3

[Jonathan Kamens]

I think even "ssh-h3" is a confusing and frankly impudent name. The creator of 
this new package appears to be intentionally trying to use the ubiquity of the 
ssh "brand" to their benefit. This brand confusion can only harm end users and 
I do not think Debian should facilitate it.

Even something as simple as naming it h3sh would have avoided the brand 
confusion while communicating the purpose of the package. This does not appear 
to be a case of "unknowing infringement." It appears to be intentional.

Regardless of whether or not that's so, it is harmful and should be fixed.

Jik

On December 30, 2023 2:02:56 PM EST, Marvin Renich  wrote:
>* Simon Josefsson  [231230 11:54]:
>> One alternative that was suggested was to call the package something
>> else in Debian.  'golang-ssh3'?  'go-ssh3'?  Still somewhat problematic
>> as long as the 'ssh3' name is in there.
>
>There is no reason the package (source and binary) can't be named ssh-h3
>even if the binary is not renamed.  I would not keep the "ssh3" part in
>the package name.
>
>...Marvin
>

-- 
Sent from my phone. Please excuse brevity and autocorrect errors.

Re: Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3

[rhys]

Based on this:  https://news.ycombinator.com/item?id=38664729

I would say that others have come to the same conclusion.  Even the post title 
literally says it's not really "SSHv3" but rather SSHv2 using a different 
transport mechanism.

A package name that reflects THAT might be appropriate - like 
'golang-ssh2-tunnel' or some such thing (long but descriptive package names 
don't bother me) - but I absolutely agree that calling it "ssh3" is misleading 
and inappropriate.

--J

> On Dec 30, 2023, at 13:31, Jonathan Kamens  wrote:
> 
> I think even "ssh-h3" is a confusing and frankly impudent name. The creator 
> of this new package appears to be intentionally trying to use the ubiquity of 
> the ssh "brand" to their benefit. This brand confusion can only harm end 
> users and I do not think Debian should facilitate it.
> 
> Even something as simple as naming it h3sh would have avoided the brand 
> confusion while communicating the purpose of the package. This does not 
> appear to be a case of "unknowing infringement." It appears to be intentional.
> 
> Regardless of whether or not that's so, it is harmful and should be fixed.
> 
> Jik
> 
> 
> On December 30, 2023 2:02:56 PM EST, Marvin Renich  wrote:
>> * Simon Josefsson  [231230 11:54]:
>>> One alternative that was suggested was to call the package something
>>> else in Debian.  'golang-ssh3'?  'go-ssh3'?  Still somewhat problematic
>>> as long as the 'ssh3' name is in there.
>> 
>> There is no reason the package (source and binary) can't be named ssh-h3
>> even if the binary is not renamed.  I would not keep the "ssh3" part in
>> the package name.
>> 
>> ...Marvin
>> 
> 
> -- 
> Sent from my phone. Please excuse brevity and autocorrect errors.

Re: Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3

[Marvin Renich]

* Jonathan Kamens  [231230 14:39]:
> I think even "ssh-h3" is a confusing and frankly impudent name. The
> creator of this new package appears to be intentionally trying to use
> the ubiquity of the ssh "brand" to their benefit. This brand confusion
> can only harm end users and I do not think Debian should facilitate
> it.
> 
> Even something as simple as naming it h3sh would have avoided the
> brand confusion while communicating the purpose of the package. This
> does not appear to be a case of "unknowing infringement." It appears
> to be intentional.
> 
> Regardless of whether or not that's so, it is harmful and should be fixed.

No argument from me there.  The point was that if upstream does not
rename the project or executable, the package name does not need to
match the executable or even the upstream project name.

...Marvin

Bug#1059733: ITP: golang-k8s-client-go -- Go client for Kubernetes

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: Jérémy Lal 
X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Go Packaging Team 


* Package name: golang-k8s-client-go
  Version : 0.29.0
  Upstream Contact: https://github.com/kubernetes/client-go/issues
* URL : https://github.com/kubernetes/client-go
* License : Apache-2.0
  Programming Lang: Golang
  Description : Go client for Kubernetes

 Go clients for talking to a kubernetes cluster.
  * The kubernetes package contains the clientset to access Kubernetes
API.
  * The discovery package is used to discover APIs supported by a
Kubernetes API server.
  * The dynamic package contains a dynamic client that can perform
generic operations on arbitrary Kubernetes API objects.
  * The plugin/pkg/client/auth packages contain optional authentication
plugins for obtaining credentials from external sources.
  * The transport package is used to set up auth and start a connection.
  * The tools/cache package is useful for writing controllers.

This package will be published in go-team.

It is needed by kubernetes, and other projects like receptor, which is a 
controller for awx.

Bug#1059736: ITP: golang-github-theckman-yacspin -- easy to use and customizable terminal spinners

[Maytham Alsudany]

Package: wnpp
Severity: wishlist
Owner: Maytham Alsudany 
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org
Control: block 1059406 by -1

* Package name: golang-github-theckman-yacspin
  Version : 0.13.12
  Upstream Contact: https://github.com/theckman/yacspin/issues
* URL : https://github.com/theckman/yacspin
* License : Apache-2.0
  Programming Lang: Go
  Description : easy to use and customizable terminal spinners

 This package provides yet another CLI spinner for Go, taking inspiration
 (and some utility code) from the https://github.com/briandowns/spinner project.
 Specifically `yacspin` borrows the default character sets, and color mappings
 to github.com/fatih/color colors, from that project.
 .
 yacspin features over 90 spinners, can handle dynamic text width of certain
 animations, success and failure results, configurable positioning,
 concurrency, live updates, pausing for updates, support for non-TTY outputs,
 and manually stepping the animation.

Dependency of github.com/darkhz/invidtui.

This package will be maintained within the Go team, and I will need a sponsor.

--
Kind regards,
Maytham Alsudany



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