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
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
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
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:
...
> 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 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 *
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
* 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.
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,
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 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
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,
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, 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
* 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
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
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
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
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
* 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
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
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
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 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
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
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 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
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
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
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
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
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 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
33 matches
Mail list logo
