FWIW, I support moving forward with #6.
/Simon
You wrote:
> My gut reaction was that #5 or #6 are the best option (leaning to
> #6). However I guess I don't understand what making something a
> system library effects the license?
>
> Andreas Metzler wrote:
> >Hello,
> >
> >Debian ist still rel
Package: wnpp
Severity: wishlist
* Package name: libykneomgr
Version : 0.1.2-1
Upstream Author : Simon Josefsson
* URL : http://opensource.yubico.com/libykneomgr/
* License : LGPLv3+
Section : utils
This is a C library to interact with the
If there are any packages that uses SSLv2 by default you might want to
file a security bug to get them fixed. I believe SSLv2 is really that
bad, it just gives a false sense of security.
/Simon
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". T
Roger Leigh writes:
> On Wed, Apr 27, 2011 at 09:30:05AM -0700, Russ Allbery wrote:
>> Bastien ROUCARIES writes:
>>
>> >> Patches to WebAuth to support NSS are welcome, but I'm sure not going to
>> >> bother. Seems like a waste of time to me. If I were going to port to any
>> >> other crypto
m...@linux.it (Marco d'Itri) writes:
> On Apr 27, Bastian Blank wrote:
>
>> On Tue, Apr 26, 2011 at 07:20:55PM +0200, Marco d'Itri wrote:
>> > The reason is that the kind of entities which require FIPS 140 probably
>> > also tend to require corporate vendor support, which we do not provide.
>> Wh
Roger Leigh writes:
> This is the root cause, I think. libgcrypt was developed as part of
> gnutls, and although it's a separate library, it's insufficiently
> generalised. It's implicitly doing things the way gnutls wanted them
> doing, and rather than making the library completely general and
Enrico Weigelt writes:
> * Henrique de Moraes Holschuh schrieb:
>
>> > I'm (as upstream) using serval macros in their own .m4 files (eg.
>> > in ./m4/, maybe even sorted into subdirs). Can autoreconf figure
>> > out the required search pathes all on its own ?
>>
>> The problem is that autorecon
Niko Tyni writes:
> On Wed, May 20, 2015 at 04:46:44PM +1000, Ben Finney wrote:
>
>> Files: libquux/*
>> Copyright: […]
>> License: GPL-2 or CC-BY-SA-3
>> You may modify and/or redistribute this work under the terms of
>> either the GPL version 2 or later, or the Cre
I believe the blog post below has relevance to Debian's stance on
including minified JavaScript in packages:
https://zyan.scripts.mit.edu/blog/backdooring-js/
To me the problem suggests that it is important from a security and
accountability perspective to 1) include the human-readable source cod
Vincent Bernat writes:
> ❦ 25 août 2015 22:46 +0100, Steve McIntyre :
>
>>>Notably, one of the tool is Grunt and its myriad of plugins. Even if
>>>Grunt was in Debian, we would also need Gulp, then Broccoli, because in
>>>Javascript, there is always someone thinking that it should be possible
>
Dmitry Smirnov writes:
> On Monday 24 August 2015 13:54:21 Simon Josefsson wrote:
>> I believe the blog post below has relevance to Debian's stance on
>> including minified JavaScript in packages:
>>
>> https://zyan.scripts.mit.edu/blog/backdooring-js/
>
>
Raphael Hertzog writes:
> In both cases, I worked around the problem by shipping the upstream
> sources in debian/missing-sources/ but I did not support doing changes
> there and did not rebuild the embedded libraries.
>
> In some cases, I do replace the embedded library with a symlink to the
> p
Raphael Hertzog writes:
> On Mon, 31 Aug 2015, Simon Josefsson wrote:
>> How would someone rebuild the minified javascript files from the
>> missing-sources files?
>
> They would not?
>
> The modified non-minified files are perfectly usable even if they are a
> bit
Samuel Thibault writes:
> I however agree that it seems poor practice to duplicate these build
> modules in every packages. But if the required versions are different,
> there is no real other way.
There is another solution: put several different versions of the same
source code into some Debian
Hi.
Is there any reason (other than lack of manpower) that GNU IceCat is not
packaged in Debian?
I understand Debian has IceWeasel to (primarily?) fix the Firefox
trademark issue and to have a mechanism to deal with security backports.
IceCat has diverged from Firefox/Iceweasel and has a differe
Riley Baird writes:
>> Is there any reason (other than lack of manpower) that GNU IceCat is not
>> packaged in Debian?
>>
>> I understand Debian has IceWeasel to (primarily?) fix the Firefox
>> trademark issue and to have a mechanism to deal with security backports.
>>
>> IceCat has diverged fro
Riley Baird
writes:
> On Tue, 08 Sep 2015 08:58:46 +0200
> Simon Josefsson wrote:
>
>> Riley Baird writes:
>>
>> >> Is there any reason (other than lack of manpower) that GNU IceCat is not
>> >> packaged in Debian?
>> >>
>> >&
Marco d'Itri <[EMAIL PROTECTED]> writes:
> >Is there a workaround, so that I can continue to use these libraries?
>
> Write a small shared library providing _xstat and preload it.
I wrote this to do that, unfortunely it wasn't enough for my program
(a program compiled with the Portland Groups' f
Package: wnpp
Severity: wishlist
Hi! I am planning to package priv-wrapper:
https://cwrap.org/priv_wrapper.html
priv_wrapper aims to help running processes which are dropping
privileges or are restricting resources in test environments. A
disabled call always succeeds (i.e. returns
Salvo Tomaselli writes:
>> hi, on "no public key" list there are my uploads, I'm debian maintainer
>> (https://nm.debian.org/person/fantu/), I signed with my key and I have
>> DM upload right for them
>> (https://qa.debian.org/developer.php?login=fantonifabio%40tiscali.it)
>
> I think he just
Judit Foglszinger writes:
> Hi,
>
>> > Dmitri, could you re-run the numbers with the debian-maintainer keyring?
>>
>> That is correct. I have updated the results now.
>> The 2,455 no public key has now become 1,238
>
> Another is the DN keyring.
> Also I'd expect many keys to be found in older v
Jonathan McDowell writes:
> On Mon, Dec 04, 2023 at 11:07:38AM +0100, Simon Josefsson wrote:
>> Judit Foglszinger writes:
>> >> > Dmitri, could you re-run the numbers with the debian-maintainer
>> >> > keyring?
>> >>
>> >>
Package: wnpp
Severity: wishlist
Owner: si...@josefsson.org
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: apt-verify
Version : 2.0
Upstream Contact: Simon Josefsson
* URL : https://gitlab.com/debdistutils/apt-verify
* License : AGPLv3
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org
* Package name: ssh3
Version : 0.1.4
Upstream Contact: François Michel
* URL : https://github.com/francoismichel/ssh3
* License : Apache-2.0
Programming La
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org
* Package name: golang-github-golang-jwt-jwt-v5
Version : 5.2.0-1
Upstream Author : golang-jwt maintainers, Dave Grijalva
* URL : https
Philipp Kern writes:
> On 29.12.23 11:30, Simon Josefsson wrote:
>> Package: wnpp
>> Severity: wishlist
>> X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org
>> * Package name: ssh3
>>Version : 0.1.4
>>Ups
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
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
Stephan Verbücheln writes:
> On Sat, 30 Dec 2023 12:47:48 + Colin Watson
> wrote:
>> 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.
>
> It is written in Go. The problem of Go library
Bastian Blank writes:
> On Fri, Dec 29, 2023 at 11:30:14AM +0100, Simon Josefsson wrote:
>> * Package name: ssh3
>
> This package name is clearly not acceptable. SSH is a well known name
> and this project is completely unrelated to it.
Agreed. Packagers have settled
Bastian Blank writes:
> Hi Simon
>
> On Sun, Jan 14, 2024 at 10:47:18AM +0100, Simon Josefsson wrote:
>> As an analogy, consider the ./configure scripts that is generated by
>> autoconf during build of many packages. The script typically generate
>> code that is put
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
* Package name: golang-github-sassoftware-go-rpmutils
Version : 0.2.0-1
Upstream Author : SAS Institute, Inc.
* URL : https://github.com/sassoftware/go-rpmutils
* License : Apache-2.0
Programming Lang
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
* Package name: golang-github-qur-ar
Version : 0.0~git20130629.282534b-1
Upstream Author : Blake Smith, Julian Phillips
* URL : https://github.com/qur/ar
* License : Expat
Programming Lang: Go
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
* Package name: relic
Version : 7.6.1-1
Upstream Author : SAS Institute, Inc.
* URL : https://github.com/sassoftware/relic
* License : Apache-2.0
Programming Lang: Go
Description : digitally sign
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
* Package name: golang-github-shibumi-go-pathspec
Version : 1.3.0-1
Upstream Author : Sander van Harmelen, Christian Rebischke
* URL : https://github.com/shibumi/go-pathspec
* License : Apache-2.0
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
* Package name: golang-github-spiffe-go-spiffe
Version : 2.1.6-1
Upstream Author : Agustín Martínez Fayó, Andrew Harding, et al
* URL : https://github.com/spiffe/go-spiffe
* License : Apache-2.0
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
* Package name: in-toto-golang
Version : 0.9.0-1
Upstream Author : Aditya Sirish, Christian Rebischke, Lukas Pühringer, et al
* URL : https://github.com/in-toto/in-toto-golang
* License : Apache-2.0
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
* Package name: golang-github-zeebo-errs
Version : 1.3.0-1
Upstream Author : Jeff Wendling
* URL : https://github.com/zeebo/errs
* License : Expat
Programming Lang: Go
Description : errs is a Go
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
* Package name: golang-github-cyberphone-json-canonicalization
Version : 0.0~git20220623.57a0ce2-1
Upstream Author : Anders Rundgren
* URL : https://github.com/cyberphone/json-canonicalization
* License
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
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
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
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
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
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
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
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
Paul Wise writes:
> 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.debia
tis 2024-01-16 klockan 11:22 +0100 skrev Jérémy Lal:
>
>
> Le mar. 16 janv. 2024 à 11:00, Simon Josefsson
> a écrit :
> > Paul Wise writes:
> >
> > > On Mon, 2024-01-15 at 10:17 +0100, Bastian Blank wrote:
> > >
> > > > I asked for practi
"IOhannes m zmölnig (Debian GNU|Linux)" writes:
> On 1/16/24 13:56, Jérémy Lal wrote:
>>>
>>> As Built-Using is for license compliance only, no?
>>>
>>> See
>>>
>>> https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using
>> In
Bastian Blank writes:
> On Tue, Jan 16, 2024 at 10:59:30AM +0100, Simon Josefsson wrote:
>> Rebuilding a bit more than what is strictly needed sounds fine as a
>> first solution to me.
>
> Building maybe. But how do you want to publish them? The security
> archive is
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
* Package name: golang-github-common-nighthawk-go-figure
Version : 0.0~git20210622.734e95f-1
Upstream Author : Daniel Deutsch
* URL : https://github.com/common-nighthawk/go-figure
* License : Expat
Adam Borowski writes:
> On Mon, Jan 15, 2024 at 10:17:17AM +0100, Bastian Blank wrote:
>> 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 pr
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
* Package name: sigsum-go
Version : 1.7.1-1
Upstream Author : The Sigsum Project Authors
* URL : https://git.glasklar.is/sigsum/core/sigsum-go
* License : BSD-2-Clause
Programming Lang: Go
Description
Simon Josefsson writes:
>> > My naive approach on how to fix a security problem in package X
>> > which is
>> > statically embedded into other packages A, B, C, ... would be to
>> > rebuild
>> > the transitive closure of all packages that Build-Depend
Luca Boccassi writes:
>> Having reflected a bit, and learned through my own experience and
>> others' insights [1] that Go Build-Depends are not transitive, I'd like
>> to update my proposal on how to handle a security bug in any Go/Rust/etc
>> package and the resulting package rebuilds:
>
> Ther
Luca Boccassi writes:
> On Wed, 24 Jan 2024 at 13:34, Simon Josefsson wrote:
>>
>> Luca Boccassi writes:
>>
>> >> Having reflected a bit, and learned through my own experience and
>> >> others' insights [1] that Go Build-Depends are not trans
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson
* Package name: cosign
Version : 2.2.2-1
Upstream Author : The Sigstore Authors
* URL : https://github.com/sigstore/cosign
* License : Apache-2.0
Programming Lang: Go
Description : Code signing
Hi
I'm exploring how to defend against an attacker who can create valid
signatures for cryptographic private keys (e.g., PGP) that users need to
trust when using an operating system such as Debian. A signature like
that can be used in a targetted attacks against one victim.
For example, apt does
Bill Allombert writes:
> Le Thu, Feb 01, 2024 at 10:38:03AM +0100, Simon Josefsson a écrit :
>> Hi
>>
>> I'm exploring how to defend against an attacker who can create valid
>> signatures for cryptographic private keys (e.g., PGP) that users need to
>> tru
Hans-Christoph Steiner writes:
> Thanks for digging in here, its very important work! I'd be happy to
> contribute where I can. I'm a DD and a core contributor to F-Droid,
> where we wrestle with basically the same issues. So we've thought a
> lot about these kinds of things, but definitely do
Bill Allombert writes:
> On Mon, Feb 05, 2024 at 08:49:09AM +0100, Simon Josefsson wrote:
>> Bill Allombert writes:
>>
>> > Le Thu, Feb 01, 2024 at 10:38:03AM +0100, Simon Josefsson a écrit :
>> >> Hi
>> >>
>> >> I'm
Stephan Verbücheln writes:
> II. Typical Debian case
>
> 1. Debian developer signs source tarballs and upload them
> 2. The signature only has to be secure until the code lands in the FTP
> 3. Debian builds the binary packages
> 4. Debian creates Release files with hashes of the packages
> 5. The
tis 2024-02-06 klockan 16:50 +0100 skrev Hans-Christoph Steiner:
>
>
> Simon Josefsson:
> > Hans-Christoph Steiner writes:
> >
> > > Thanks for digging in here, its very important work! I'd be
> > > happy to
> > > contribute where I ca
> > I've looked at Sigstore, it looks nice. It seems to be architected
> > for use
> > cases that assume highly reliable and unblocked single domains.
> > That's a
> > showstopper for us. Also, the official client app is 100% JVM code
> > right now
> > (Java+Kotlin), so integrating Go binarie
Hans-Christoph Steiner writes:
>> 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 a
Antonio Russo writes:
> 1. Move towards allowing, and then favoring, git-tags over source tarballs
Some people have suggested this before -- and I have considered adopting
that approach myself, but one thing that is often overlooked is that
building from git usually increase the Build-Depends qu
Gioele Barabucci writes:
> Just as an example, bootstrapping coreutils currently requires
> bootstrapping at least 68 other packages, including libx11-6 [1]. If
> coreutils supported [2], the transitive closure of its
> Build-Depends would be reduced to 20 packages, most of which in
> build-es
Sean Whitton writes:
> Hello,
>
> On Sat 30 Mar 2024 at 12:19pm +01, Simon Josefsson wrote:
>
>> Relying on signed git tags is not reliable because git is primarily
>> SHA1-based which in 2019 cost $45K to do a collission attack for.
>
> We did some analysis o
Jonathan Carter writes:
> On 2024/03/30 11:05, Simon Josefsson wrote:
>>> 1. Move towards allowing, and then favoring, git-tags over source tarballs
>>
>> Some people have suggested this before -- and I have considered adopting
>> that approach myself, but one thi
Russ Allbery writes:
> Simon Josefsson writes:
>> Sean Whitton writes:
>
>>> We did some analysis on the SHA1 vulnerabilities and determined that
>>> they did not meaningfully affect dgit & tag2upload's design.
>
>> Can you share that analysis?
Bastian Blank writes:
> On Sun, Mar 31, 2024 at 12:05:54PM +0500, Andrey Rakhmatullin wrote:
>> On Sat, Mar 30, 2024 at 11:22:33PM -0300, Santiago Ruano Rincón wrote:
>> > As others have said, the best solution is to relay on HSW for handling
>> > the cryptographic material.
>> Aren't these answe
Gioele Barabucci writes:
> But pulling a successful collision attack is not a trivial task. For
> instance, the xz attacker did not have all that was required to carry
> it out (for example they had no direct access to the git
> servers... yet).
Is that necessary? It seems that if you have push
"G. Branden Robinson" writes:
> At 2024-03-31T22:32:49+, Stefano Rivera wrote:
>> Upstreams would probably prefer that we used git repositories
>> *directly* as source artifacts, but that comes with a whole other can
>> of worms...
>
> Speaking from my upstream groff perspective, I wouldn't _
Colin Watson writes:
> On Mon, Apr 01, 2024 at 11:33:06AM +0200, Simon Josefsson wrote:
>> Running ./bootstrap in a tarball may lead to different results than the
>> maintainer running ./bootstrap in pristine git. It is the same problem
>> as running 'autoreconf -
Jonas Smedegaard writes:
> That said, you are welcome to try nudge me if some concrete task
> emerges where you image I might be of help.
Thanks -- I'm moving this out of 921954@bugs and cc'ing debian-devel to
allow others to help and to allow you from not having to feel a need to
reply at all :
Sebastian Ramacher writes:
> Hi,
>
> as the progress on the t64 transition is slowing down, I want to give an
> overview of some of the remaining blockers that we need to tackle to get
> it unstuck. I tried to identify some clusters of issues, but there might
> be other classes of issues.
Thanks
Jonas Smedegaard writes:
> Quoting Simon Josefsson (2024-04-18 09:34:26)
>> Jonas Smedegaard writes:
>>
>> > That said, you are welcome to try nudge me if some concrete task
>> > emerges where you image I might be of help.
>>
>> Thanks -- I'
Marco d'Itri writes:
> On Apr 21, Mathias Gibbens wrote:
>
>> While that might work for them, it obviously doesn't at a higher
>> packaging level. Per Policy Section 10.1, I'm bringing this to d-devel
>> for any comments or suggestions on my plan for packaging the MinIO
>> Client. Following wh
Philip Hands writes:
> Mathias Gibbens writes:
>
>> On Sun, 2024-04-21 at 18:47 +0200, Simon Josefsson wrote:
> ...
>>> /usr/libexec/minio-client/bin/mc -> /usr/bin/mcli
>
> Might I suggest that the link goes the other way, so that the symlink
> lives in /usr
Hi
According to the mirror list
https://www.debian.org/distrib/archive
it should be possible to reach archive.debian.org via rsync, however
this fails for me. Is this intentional, or can this be fixed?
Further it seems mirrors are out of sync. I noticed that several
mirrors lack buster. Acco
/rules to build everything from source code.
For libntlm the essential diff between version 1.7-1, that used upstream
tarball with pre-generated content and gnulib code, and latest version
1.8-3 that builds from a minimal source-only tarball is small:
--- a/debian/control
+++ b/debian
Bruno Haible writes:
> Simon Josefsson wrote:
>> Finally, while this is somewhat gnulib specific, I think the practice
>> goes beyond gnulib
>
> Yes, gnulib-tool for modules written in C is similar to
>
> * 'npm install' for JavaScript source code packa
"Theodore Ts'o" writes:
>> 1) Use upstream's PGP signed git-archive tarball.
>
> Here's how I do it in e2fsprogs which (a) makes the git-archive
> tarball be bit-for-bit reproducible given a particular git commit ID,
> and (b) minimizes the size of the tarball when stored using
> pristine-tar:
>
"Theodore Ts'o" writes:
> On Sun, May 12, 2024 at 04:27:06PM +0200, Simon Josefsson wrote:
>> Going into detail, you use 'gzip -9n' but I use git-archive defaults
>> which is the same as -n aka --no-name. I agree adding -9 aka --best is
>> an improv
onal package.
+- Drop references to libidn9 and libidn9-dev, last seen in 2003
+ and didn't reach testing according to the tracker.
+ * For libidn11, drop confusing 'Replaces: libidn11-dev'.
+
+ -- Simon Josefsson Sun, 16 May 2021 00:08:06 +0200
+
libidn (1.33-3) unstable; u
mån 2021-05-24 klockan 20:45 +0200 skrev Timo Röhling:
> Hi Simon!
>
> * Simon Josefsson [2021-05-24 19:34]:
> > I want to upload a new upstream libidn release into Debian, but
> > upstream
> > has done a shared library transition.
> You should probably read the
Andreas Metzler writes:
> On 2021-05-24 Simon Josefsson wrote:
>> Hi! This is for post-bullseye, but I appreciate guidance if anyone has
>> time. Shared library version transitions trigger uncertainty in me.
>
>> I want to upload a new upstream libidn release into Deb
Andreas Metzler writes:
> On 2021-05-26 Guillem Jover wrote:
>> On Tue, 2021-05-25 at 19:43:21 +0200, Andreas Metzler wrote:
> [...]
>> I'd probably instead make this a versioned Provides, so that the
>> transitional package can be removed right away from systems, it does
>> not interfere with t
Simon McVittie writes:
> On Wed, 26 May 2021 at 19:18:24 +0200, Simon Josefsson wrote:
>> Andreas Metzler writes:
>> > Why not use a versioned Provides *instead* of the dummy package?
>>
>> Yeah, I never understand exactly when these dummy packages are needed.
>
Hi! I'm now resuming work on the libidn shared library transition, and
I'm ready for the upload to experimental. I wanted to ping back here to
get more review. I'm following Andreas Metzler's outline, but included
some tweaks suggested by Simon McVittie. I decided to do some more
changes that a
Paul Wise writes:
> Hi all,
>
> I noticed that sometimes Debian's choice of upstream source for
> packaging can be suboptimal. This is especially apparent for the
> different per-language upstream packaging ecosystems[1], where the
> upstream packaging differs from the upstream VCS in some signif
Michael Biebl writes:
> Hi,
>
> we are early in the bookworm release cycle, so I guess it's the
> perfect time to bring up this topic.
Sorry for hijacking the thread, but perhaps now is a good time to stop
using the legacy syslog time format and use the standardized RFC 5424
format? It is the d
Hi all,
I have searched for non-free licensed IETF RFCs in the archive and found
the files below in the stretch suite. Compare earlier work here [1].
I know this is late in the release cycle, but I believe these are real
RC bugs so it appears to me that bug reports should be filed. I post
this
Sebastiaan Couwenberg writes:
> On 03/04/2017 10:13 AM, Simon Josefsson wrote:
>> I have searched for non-free licensed IETF RFCs in the archive and found
>> the files below in the stretch suite. Compare earlier work here [1].
>
> Instead of trying to get standards documen
Moritz Mühlenhoff writes:
> Russ Allbery schrieb:
>> Simon Josefsson writes:
>>
>>> Is there any reason (other than lack of manpower) that GNU IceCat is not
>>> packaged in Debian?
>>
>> I suspect it's mostly just resources, but it's an im
> Hi Simon,
>
> > Perhaps the situation would be easier for the security team if a
> > IceCat package in Debian was based on the same ESR release as
> > Iceweasel?
>
> I believe the situation would be easier if the actual changes in
> IceCat could be identified and isolated and then brought up fo
Ian Jackson writes:
> Simon Josefsson writes ("Re: GNU IceCat?"):
>> What's a good way to do that efficiently? People have submitted bugs
>> against Iceweasel to do some of the things that IceCat does by default,
>> for example https://bugs.debian.org/cgi-b
"Iain R. Learmonth" writes:
> Hi,
>
> On Thu, Nov 12, 2015 at 01:49:37PM +0100, Wouter Verhelst wrote:
>> How does one use the damn XMPP service?
>
> Set an RTC password using db.debian.org.
>
> Your account username is wou...@debian.org. (Replace wouter with your LDAP
> username if you're not wo
Raphael Hertzog writes:
> For package subscribers
> ---
>
> In theory, as a package subscriber you have nothing to do, in practice,
> depending on your mail filtering rules, you might have to adjust them.
> Each forwarded mail now has headers like this:
>
> X-Loop: dispa..
101 - 200 of 427 matches
Mail list logo
