On 05/08/23 at 21:29 +0200, Andrey Rakhmatullin wrote:
> On Sat, Aug 05, 2023 at 07:20:19PM +0300, Adrian Bunk wrote:
> > What packages are failing, and why?
> >
> > I would expect some debhelper machinery being responsible for most of
> > these, e.g. perhaps some dh-whatever helper might be crea
On Sat, Aug 05, 2023 at 07:40:36PM +0200, Andrey Rakhmatullin wrote:
> On Sat, Aug 05, 2023 at 08:10:35PM +0300, Adrian Bunk wrote:
> > Debian maintainers with proper git workflows are already exporting all
> > their changes from git to debian/patches/ as one file - currently the
> > preferred fo
On Sat, Aug 05, 2023 at 08:55:03PM +0200, Lucas Nussbaum wrote:
> On 05/08/23 at 19:20 +0300, Adrian Bunk wrote:
> > On Sat, Aug 05, 2023 at 05:06:27PM +0200, Lucas Nussbaum wrote:
> > >...
> > > Packages tested: 29883 (I filtered out those that take a very long time
> > > to build)
> > > .. build
I second this idea, and also the salsa pipeline should check this also.
- Le 5 Aoû 23, à 21:07, Timo Röhling roehl...@debian.org a écrit :
> Hi Lucas,
>
> * Lucas Nussbaum [2023-08-05 17:06]:
>>An example sbuild invocation to reproduce failures is:
> [omitted the command line equivalent of
On Sat, Aug 05, 2023 at 07:20:19PM +0300, Adrian Bunk wrote:
> What packages are failing, and why?
>
> I would expect some debhelper machinery being responsible for most of
> these, e.g. perhaps some dh-whatever helper might be creating this
> issue for all 1k packages in some language ecosystem
On August 5, 2023 7:07:34 PM UTC, "Timo Röhling" wrote:
>Hi Lucas,
>
>* Lucas Nussbaum [2023-08-05 17:06]:
>> An example sbuild invocation to reproduce failures is:
>[omitted the command line equivalent of Tolstoy's War and Peace]
>
>If we decide that this issue is important enough that people
Hi Lucas,
* Lucas Nussbaum [2023-08-05 17:06]:
An example sbuild invocation to reproduce failures is:
[omitted the command line equivalent of Tolstoy's War and Peace]
If we decide that this issue is important enough that people should
care and mass bugs be filed, sbuild will need a more conci
On 2023-08-05 19:31 +0100, Wookey wrote:
> On 2023-08-05 17:06 +0200, Lucas Nussbaum wrote:
>>
>> I wonder what we should do, because 5000+ failing packages is a lot...
>>
>> Should we give up on requiring a 'clean' target that works? After all,
>> when 17% of packages are failing, it means that m
On 05/08/23 at 19:20 +0300, Adrian Bunk wrote:
> On Sat, Aug 05, 2023 at 05:06:27PM +0200, Lucas Nussbaum wrote:
> >...
> > Packages tested: 29883 (I filtered out those that take a very long time to
> > build)
> > .. building OK all times: 24835 (83%)
> > .. failing somehow: 5048 (17%)
> >...
> >
On 2023-08-05 17:06 +0200, Lucas Nussbaum wrote:
>
> I wonder what we should do, because 5000+ failing packages is a lot...
>
> Should we give up on requiring a 'clean' target that works? After all,
> when 17% of packages are failing, it means that many maintainers don't
> depend on it in their w
On August 5, 2023 5:40:36 PM UTC, Andrey Rakhmatullin wrote:
>On Sat, Aug 05, 2023 at 08:10:35PM +0300, Adrian Bunk wrote:
>> Debian maintainers with proper git workflows are already exporting all
>> their changes from git to debian/patches/ as one file - currently the
>> preferred form of mo
On Saturday, August 5, 2023 11:06:27 AM EDT Lucas Nussbaum wrote:
> Hi,
>
> Debian Policy section 4.9 says:
> clean (required)
> This must undo any effects that the build and binary targets may
> have had, except that it should leave alone any output files
> created in the parent
On Sat, Aug 05, 2023 at 08:10:35PM +0300, Adrian Bunk wrote:
> Debian maintainers with proper git workflows are already exporting all
> their changes from git to debian/patches/ as one file - currently the
> preferred form of modification of a Debian package has to be in salsa
> and not in our a
On Sat, Aug 05, 2023 at 05:29:34PM +0100, Simon McVittie wrote:
>...
> One way to streamline dealing with these generated files would be
> to normalize repacking of upstream source releases to exclude them,
> and make it easier to have source packages that genuinely only contain
> what we consider
On Wed, Jul 26, 2023 at 06:24:49PM +0200, Aurelien Jarno wrote:
> Hi,
>
> On 2023-07-24 23:07, Adrian Bunk wrote:
> > On Sun, Jul 23, 2023 at 08:36:53PM +0100, Mark Hymers wrote:
> > > On Sun, 23, Jul, 2023 at 08:36:15PM +0200, Paul Gevers spoke thus..
> > > > Speaking as a member of the Release T
On Sat, Aug 05, 2023 at 05:06:27PM +0200, Lucas Nussbaum wrote:
>...
> Packages tested: 29883 (I filtered out those that take a very long time to
> build)
> .. building OK all times: 24835 (83%)
> .. failing somehow: 5048 (17%)
>...
> I wonder what we should do, because 5000+ failing packages is a
On Sat, 05 Aug 2023 at 17:06:27 +0200, Lucas Nussbaum wrote:
> Should we give up on requiring a 'clean' target that works? After all,
> when 17% of packages are failing, it means that many maintainers don't
> depend on it in their workflow.
I think it's somewhat inevitable that code paths that are
On 2023-08-05 17:06, Lucas Nussbaum wrote:
Should we give up on requiring a 'clean' target that works? After all,
when 17% of packages are failing, it means that many maintainers don't
depend on it in their workflow.
Yes, please, this does not make sense anymore to enforce such a rule
when it
Hi,
Debian Policy section 4.9 says:
clean (required)
This must undo any effects that the build and binary targets may
have had, except that it should leave alone any output files
created in the parent directory by a run of a binary target.
I looked at what happens when doing 'dpk
19 matches
Mail list logo