On Jo, 03 feb 22, 18:55:44, Scott Kitterman wrote:
> On Thursday, February 3, 2022 2:40:08 PM EST Phil Morrell wrote:
> >
> > That is not the challenge being made here. I don't believe anyone is
> > arguing that licensing documentation bugs would be anything other than
> > RC bugs according to pol
Scott Kitterman writes:
...
> My impression is that people are tired of waiting on New, but no one
> really seems to be interested in doing any work on any alternative
> other than more bugs.
Part of the problem is that New processing is a bit of a black box, so
it's not clear to those of us out
On Fri, 04 Feb 2022 at 02:23:54 +, Seth Arnold wrote:
> does this represent a security problem?
"It depends". (This answer is not specific to CMake, it's equally valid
for any build system.)
If the RPATH or RUNPATH points to a trusted directory where write access
would require root-equivalent
On Fri, 04 Feb 2022 at 13:07:53 +0800, Paul Wise wrote:
> Vagrant Cascadian wrote:
> > Over the last several months, I and others have found quite a few
> > packages that embed build paths via rpath when building with cmake.
>
> This seems like the sort of thing that will be an ongoing problem, so
Package: wnpp
Severity: wishlist
Owner: Neil Williams
X-Debbugs-Cc: debian-devel@lists.debian.org, codeh...@debian.org
* Package name: xraydb
Version : 4.4.7
Upstream Author : Matthew Newville
* URL : https://github.com/xraypy/XrayDB
* License : Public domain
Package: wnpp
Severity: wishlist
Owner: Ole Streicher
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org,
debian-as...@lists.debian.org, debian-scie...@lists.debian.org
* Package name: cmyt
Version : 1.0.4
Upstream Author : Clement Robert
* URL
On 04/02/2022 11:58, Simon McVittie wrote:
For packages where the RPATH or RUNPATH is temporarily set during build
(to be able to run unit tests without setting LD_LIBRARY_PATH) but then
removed before installation with `chrpath -d` or equivalent code in CMake,
I don't think this is going to be d
Hi,
I got an RC bug on python-anyio, because its testsuite fails when run
on an IPv6-only host [1].
I pushed the issue upstream, and upstream has a patch proposal [2].
Now comes the question: how do I test this patch?
Cheers,
J.Puydt
[1] https://bugs.debian.org/1004461
[2] https://github.com/
On 2022-02-03 17:58:24, M. Zhou wrote:
> @dod: It looks that we have to change the Architecture: of raku-*
> packages into any (instead of "all") because there is no binnmu
> for Arch:all package. Then upon each time we bump the rakudo API
> version, we just need to file a regular transition bug to
On Thu, 03 Feb 2022 16:41:21 -0800,
Vagrant Cascadian wrote:
>
>I've attached a list of the maintainers of affected packages produced
>with dd-list, getting the list of packages from the above-mentioned
>reproducible builds issue and diff.dcsr.txt from archive rebuild.
>
>If you're on the list, wou
Hi,
Le 04/02/2022 à 08:58, Andreas Ronnquist a écrit :
On Thu, 03 Feb 2022 16:41:21 -0800,
Vagrant Cascadian wrote:
If you're on the list, would love if you could check if your package
still builds correctly when passing only
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON. For a few of the packages, ther
On 2022-02-04 at 04:00, Philip Hands wrote:
> Scott Kitterman writes:
>
> ...
>> My impression is that people are tired of waiting on New, but no
>> one really seems to be interested in doing any work on any
>> alternative other than more bugs.
>
> Part of the problem is that New processing is
On Friday, February 4, 2022 4:00:44 AM EST Philip Hands wrote:
> Scott Kitterman writes:
>
> ...
>
> > My impression is that people are tired of waiting on New, but no one
> > really seems to be interested in doing any work on any alternative
> > other than more bugs.
>
> Part of the problem is
* Julien Puydt , 2022-02-04, 12:34:
I got an RC bug on python-anyio, because its testsuite fails when run
on an IPv6-only host [1].
I'm pretty sure "IPv6-only" means "the only non-loopback addresses this
host has are IPv6", rather than "it doesn't have any IPv4, not even
127.0.0.1."
This pr
Package: wnpp
Severity: wishlist
Owner: "Paulo Roberto Alves de Oliveira (aka kretcheu)"
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: commandlines
Version : 0.4.1
Upstream Author : Christopher Simpkins
* URL : https://github.com/chrissimpkins/commandlin
On Sat, 1 Jan 2022 at 22:34, Reuben Thomas wrote:
> On Sat, 1 Jan 2022 at 20:43, Pierre-Elliott Bécue wrote:
> >
> > I suggest this path:
> >
> > Send bug reports with your debdiff proposals for each package. If 8 days
> > after you get no reply from the maintainer, file an ITS against the
> > p
On Fri, 04 Feb 2022 at 15:38:12 +0100, Jakub Wilk wrote:
> * Julien Puydt , 2022-02-04, 12:34:
> > I got an RC bug on python-anyio, because its testsuite fails when run on
> > an IPv6-only host [1].
>
> I'm pretty sure "IPv6-only" means "the only non-loopback addresses this host
> has are IPv6", r
Hi Sebastian,
Building the files upon installation is exactly the original
behavior. The problem is that compilation speed is too slow.
Three raku packages could take more than 2 minutes every
time when there is a raku upgrade to any version.
On Fri, 2022-02-04 at 13:55 +0100, Sebastian Ramacher
* Jakub Wilk , 2022-02-04, 15:38:
unshare -c -r --keep-caps
Oops, I meant "unshare -n -r --keep-caps".
$ python3 -c 'from socket import *; getaddrinfo("127.0.0.1", port=1,
flags=AI_ADDRCONFIG)'
Note that the above does not fail when only loopback is configured, so
it seems to be something
On 2022-02-04, Paul Wise wrote:
> Vagrant Cascadian wrote:
>
>> Over the last several months, I and others have found quite a few
>> packages that embed build paths via rpath when building with cmake.
>
> This seems like the sort of thing that will be an ongoing problem, so
> if it is detectable st
The Wanderer writes:
> What I read Scott as having been suggesting, by contrast, is that people
> instead do copyright review for packages already in Debian, which may
> well have had changes that did not have to pass through NEW and that
> might not have been able to pass the NEW copyright revie
On 2022-02-04, Seth Arnold wrote:
> On Thu, Feb 03, 2022 at 04:41:21PM -0800, Vagrant Cascadian wrote:
>> Over the last several months, I and others have found quite a few
>> packages that embed build paths via rpath when building with cmake. I
>> found myself slowly edging into a mass bug filing,
On Friday, February 4, 2022 12:39:09 PM EST Russ Allbery wrote:
> The Wanderer writes:
> > What I read Scott as having been suggesting, by contrast, is that people
> > instead do copyright review for packages already in Debian, which may
> > well have had changes that did not have to pass through
Scott Kitterman writes:
> Since we're doing strawman arguments in this thread: I disagree with the
> notion that it's not a problem to put crap packages in the archive and
> fix them later if anyone happens to notice.
No, that's fine, that's not a strawman argument. That is, in fact, my
argumen
On Friday, February 4, 2022 2:48:50 PM EST Russ Allbery wrote:
> Scott Kitterman writes:
> > Since we're doing strawman arguments in this thread: I disagree with the
> > notion that it's not a problem to put crap packages in the archive and
> > fix them later if anyone happens to notice.
>
> No,
* Russ Allbery [2022-02-04 11:48]:
No, that's fine, that's not a strawman argument. That is, in fact, my
argument: I think it should be okay to put crap packages in the unstable
archive and fix them later, and I would rather put more effort into the
"noticing" part than in the pre-review part.
Timo Röhling writes:
> The FTP team review should focus on these types of mistakes, and not
> only with new packages: any "suspicious" upload should be rerouted to a
> POLICY queue for additional verification. There is some prior art with
> the auto-REJECT on Lintian errors, which could be exten
On 2022-02-04 18:39, Russ Allbery wrote:
> In other words, this thread is once again drifting into a discussion of
> how to do copyright review *better*, when my original point is that we
> should seriously consider not doing the current type of incredibly tedious
> and nit-picky copyright review *
Scott Kitterman writes:
...
> Currently the only answer is join the FTP Team as a trainee when there
> is a call for volunteers. I totally get the frustration.
People could always just send additional data points to the relevant ITP
bug, like this:
https://bugs.debian.org/cgi-bin/bugreport.cg
On Friday, February 4, 2022 6:24:56 PM EST Philip Hands wrote:
> Scott Kitterman writes:
>
> ...
>
> > Currently the only answer is join the FTP Team as a trainee when there
> > is a call for volunteers. I totally get the frustration.
>
> People could always just send additional data points to
Scott Kitterman writes:
> On Friday, February 4, 2022 6:24:56 PM EST Philip Hands wrote:
>> Scott Kitterman writes:
>>
>> ...
>>
>> > Currently the only answer is join the FTP Team as a trainee when there
>> > is a call for volunteers. I totally get the frustration.
>>
>> People could always
Package: wnpp
Severity: wishlist
Owner: "Paulo Roberto Alves de Oliveira (aka kretcheu)"
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: glyphtools
Version : 0.8.0
Upstream Author : Simon.Cozens.
* URL : https://github.com/simoncozens/glyphtools
* License
On Fri, Feb 04, 2022 at 10:49:43AM +, Simon McVittie wrote:
> CMake removes the RUNPATH
> just before installation, so it doesn't become a security problem,
> but that's too late to stop it from affecting the build-ID - and the
> *length* of the build directory can also affect the contents of t
33 matches
Mail list logo
