On Thu, Apr 28, 2022 at 02:32:49PM +0100, Simon McVittie wrote:
> On Thu, 28 Apr 2022 at 14:02:46 +0100, Julian Gilbey wrote:
> > On Thu, Apr 28, 2022 at 10:16:30AM +0100, Simon McVittie wrote:
> > > According to the autopkgtest spec[1],
> > >
> > > Tests can expect that the $HOME environment
On Thu, Apr 28, 2022 at 02:32:49PM +0100, Simon McVittie wrote:
> > That's interesting; I don't find any code that sets HOME in
> > autopkgtest.
>
> The purpose of autopkgtest is to run the tests in a realistic environment
> that resembles a real Debian desktop or server, but it doesn't know much
On Fri, 29 Apr 2022 at 10:43:40 +0800, Paul Wise wrote:
> Does that mean that autopkgtests that directly or indirectly use the
> dbus-run-session tool to setup a temporary D-Bus session are buggy?
There's no single answer to that. For unit-test-style testing, it's
often more convenient to start a
On Fri, 29 Apr 2022 at 08:34:48 +0100, Julian Gilbey wrote:
> So can I suggest that
> sbuild-setup(7) explains this a bit more and discusses setting up a
> meaningful HOME directory?
I'm sure patches are accepted, but the problem with this is that what you
want for sbuild does not match what you w
Quoting Simon McVittie (2022-04-29 10:58:34)
> On Fri, 29 Apr 2022 at 08:34:48 +0100, Julian Gilbey wrote:
> > So can I suggest that
> > sbuild-setup(7) explains this a bit more and discusses setting up a
> > meaningful HOME directory?
>
> I'm sure patches are accepted, but the problem with this i
Paul Wise wrote:
>
>During the discussions about NEW on debian-devel in recent times, I had
>the idea that instead of the current mechanism of sending REJECT mails,
>Debian could switch to using the BTS for most feedback on NEW packages.
>
>This means that most discussion about NEW packages would b
On 2022-04-29 at 08:36, Steve McIntyre wrote:
> Paul Wise wrote:
>
>> During the discussions about NEW on debian-devel in recent times, I
>> had the idea that instead of the current mechanism of sending
>> REJECT mails, Debian could switch to using the BTS for most
>> feedback on NEW packages.
>>
Following Simon's suggestion, I decided to try setting up lxc to use
autopkgtest-lxc, mimicking the ci.debian.org setup. I haven't managed
to do so yet, and have run into lots of problems. I'd really
appreciate some advice on what to try, and them we can record advice
somewhere on the Debian wiki
On Wednesday, April 27, 2022 8:54:05 PM EDT Paul Wise wrote:
> Hi all,
>
> During the discussions about NEW on debian-devel in recent times, I had
> the idea that instead of the current mechanism of sending REJECT mails,
> Debian could switch to using the BTS for most feedback on NEW packages.
>
Hi Scott,
thanks a lot for becoming involved into this discussion.
Am Fri, Apr 29, 2022 at 11:26:33AM -0400 schrieb Scott Kitterman:
> 2. Not rejecting packages with serious defects:
>
> I'm not sure I understand what it proposed:
>
> > The ftpmasters could simply file severity serious bug rep
On Friday, April 29, 2022 12:08:21 PM EDT Andreas Tille wrote:
> Hi Scott,
>
> thanks a lot for becoming involved into this discussion.
>
> Am Fri, Apr 29, 2022 at 11:26:33AM -0400 schrieb Scott Kitterman:
> > 2. Not rejecting packages with serious defects:
> >
> > I'm not sure I understand wha
On Fri, 2022-04-29 at 13:36 +0100, Steve McIntyre wrote:
> Just to clarify: is this suggesting that packages from NEW would end
> up in the archive even with serious bugs? If not, what's the point of
> the "eventual removal" above? I'm not following you here...
No, the bugs I propose to be filed
On Fri, 2022-04-29 at 11:26 -0400, Scott Kitterman wrote:
> 1. Making reject/prod emails more public:
>
> There are actually two different types of messages we can send while
> reviewing
> packages in DAK:
>
> a. Reject: As indicated by the name, this is an email that accompanies the
> pack
On April 29, 2022 11:04:57 PM UTC, Paul Wise wrote:
>On Fri, 2022-04-29 at 13:36 +0100, Steve McIntyre wrote:
>
>> Just to clarify: is this suggesting that packages from NEW would end
>> up in the archive even with serious bugs? If not, what's the point of
>> the "eventual removal" above? I'm n
On Fri, 2022-04-29 at 18:08 +0200, Andreas Tille wrote:
> To give some actual examples that IMHO are candidates for accept + bug
> report:
Packages with incomplete or incorrect debian/copyright information
currently would recieve a REJECT rather than acceptance. The proposal
would not change that
On Fri, 2022-04-29 at 23:32 +, Scott Kitterman wrote:
> I don't understand why this is any better than just rejecting the
> package? Once it's been determined that the upload won't be
> accepted, I don't see a benefit to having it remain in New.
The initial upload might not get an ACCEPT, bu
On April 29, 2022 11:44:54 PM UTC, Paul Wise wrote:
>On Fri, 2022-04-29 at 23:32 +, Scott Kitterman wrote:
>
>> I don't understand why this is any better than just rejecting the
>> package? Once it's been determined that the upload won't be
>> accepted, I don't see a benefit to having it r
On Sat, 2022-04-30 at 00:13 +, Scott Kitterman wrote:
> I'm still not understanding how any of that needs to have a package
> we've decided not to accept sitting in New?
My thinking is that debbugs would require a package (imported from
new.822) to exist for maintainer addresses. If you file
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: mkdocstrings-python-legacy
Version : 0.2.2
Upstream Author : Timothée Mazzucotelli
* URL : https://github.com/mkdocstrings/python-legacy
* License
19 matches
Mail list logo
