On Sun, Jan 14, 2024 at 04:24:57PM +0100, Simon Josefsson wrote:
> Isn't that what the text refers to? Vendoring and static linking are
> two examples of the same problem that the security team may encounter.
We accept vendoring of autoconf/automake/gnulib distro wide. Please
show practical prob
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
* Package name: golang-github-veraison-go-cose
Version : 1.2.1-1
Upstream Author : Veraison
* URL : https://github.com/veraison/go-cose
* License : MPL-2.0
Programming Lang: Go
Description : go lib
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
* Package name: golang-github-cavaliergopher-rpm
Version : 1.2.0-1
Upstream Author : Ryan Armstrong, et al
* URL : https://github.com/cavaliergopher/rpm
* License : BSD-3-clause
Programming Lang: Go
De
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
* Package name: golang-github-adamkorcz-go-fuzz-headers-1
Version : 0.0~git20230919.8b5d3ce-1
Upstream Author : Adam Korcz
* URL : https://github.com/AdamKorcz/go-fuzz-headers-1
* License : Apache-2.0
P
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
* Package name: golang-k8s-sigs-release-utils
Version : 0.7.7-1
Upstream Author : Kubernetes SIGs
* URL : https://github.com/kubernetes-sigs/release-utils
* License : Apache-2.0
Programming Lang: Go
De
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
* Package name: golang-github-transparency-dev-merkle
Version : 0.0.2-1
Upstream Author : Pavel Kalinnikov, Al Cutter, Martin Hutchinson, M Hickford,
et al
* URL : https://github.com/transparency-dev/merkle
* Lic
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
* Package name: trillian
Version : 1.6.0-1
Upstream Author : Google
* URL : https://github.com/google/trillian
* License : Apache-2.0
Programming Lang: Go
Description : A transparent, highly scalab
On Mon, Jan 08, 2024 at 11:18:09AM +, Simon McVittie wrote:
> On Mon, 08 Jan 2024 at 08:21:08 -, Sune Vuorela wrote:
> > Maybe the question is also a bit .. "it depends".
> ...
> > So that users actually likely get a system that works?
>
> I think the fact that we argue about this every fe
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
* Package name: golang-bitbucket-creachadair-shell
Version : 0.0.8-1
Upstream Author : Michael J. Fromberger
* URL : https://bitbucket.org/creachadair/shell/
* License : BSD-3-Clause
Programming Lang: Go
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
* Package name: golang-github-sigstore-protobuf-specs
Version : 0.2.1-1
Upstream Author : sigstore
* URL : https://github.com/sigstore/protobuf-specs
* License : Apache-2.0
Programming Lang: Go
Descrip
"Theodore Ts'o" writes:
> I'll argue that best practice is that upstream show make the shared
> library useful *without* the daemon, but if the daemon is present,
> perhaps the shared library can do a better job.
Eh, I think this too depends on precisely what the shared library is for.
The obvio
On 15/01/24 18:58, Russ Allbery wrote:
When you have the case of an application that optionally wants to do foo,
a shared library that acts as a client, and a daemon that does foo, there
are three options:
From the point of view a Debian package there are four options:
Depends:, Recommends:, S
On Mon, 15 Jan 2024 at 09:58:46 -0800, Russ Allbery wrote:
> "Theodore Ts'o" writes:
> > I'll argue that best practice is that upstream [should] make the shared
> > library useful *without* the daemon
Is the argument here that any design that separates into clients and a
non-optional server (for
Hi,
Quoting Ansgar (2024-01-07 20:39:57)
> I would like to extend Debian Policy on libraries depending on services
> (daemons) that they can speak to.
>
> Let me bring to examples, one made up,, one for which I filed a bug
> recently. But as far as I can tell this question comes up from time to
>
On Mon, 15 Jan 2024 at 19:59:22 +0100, Johannes Schauer Marin Rodrigues wrote:
> Just today I had a case where I was building something innocent and suddenly I
> had an init system installed because:
>
> libgtk-3-dev -> libgtk-3-common -> dconf-gsettings-backend -> dconf-service \
> -> dbus-sess
On 15/01/2024 18:00, Russ Allbery wrote:
> When you have the case of an application that optionally wants to do foo,
> a shared library that acts as a client, and a daemon that does foo, there
> are three options:
>
> 1. Always install the shared library and daemon even though it's an
>optiona
Roger Lynn writes:
> On 15/01/2024 18:00, Russ Allbery wrote:
>> When you have the case of an application that optionally wants to do foo,
>> a shared library that acts as a client, and a daemon that does foo, there
>> are three options:
>>
>> 1. Always install the shared library and daemon even
Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva
X-Debbugs-Cc: debian-devel@lists.debian.org, nilsonfsi...@hotmail.com
* Package name: altdns
Version : 1.0.2
Upstream Contact: Shubham Shah
* URL : https://github.com/infosec-au/altdns
* License
On Mon, 2024-01-15 at 10:17 +0100, Bastian Blank wrote:
> I asked for practical solutions, not theoretical ones. We don't have a
> suitable way to rebuild all packages just because right now.
There are some ideas on the static linking wiki page:
https://wiki.debian.org/StaticLinking
Probably t
Is rebuilding really the biggest problem? Even if Debian had enough
capacity to rebuild everything after the change of a build dependency,
I do not see how this solves the work of tracking Rust dependencies in
the first place.
I use a handful of Rust applications which I am building myself on
Debi
20 matches
Mail list logo
