On Sun, Jun 23, 2024 at 02:06:04PM +0200, Magnus Holmgren wrote:
> I'm very late to the party, but after reading the entire thread, I'd like to
> discuss a more specific, but perhaps not uncommon, situation with regard to
> cleaning and building again:
>
> We have a [still fairly] typical upstre
Hi,
I'm very late to the party, but after reading the entire thread, I'd like to
discuss a more specific, but perhaps not uncommon, situation with regard to
cleaning and building again:
We have a [still fairly] typical upstream package using Autotools. The tarball
includes some built files (e.
Le dimanche 26 novembre 2023 à 16:34 +0100, Matthijs Kooijman a écrit :
> Hi,
>
> I've also gotten a bunch of bug reports from this MBF. Some were easy
> to
> fix, but there is one subtype of this issue where I think the
> commonly
> given advice and policy currently contradict.
>
> This concerns
Hi,
I've also gotten a bunch of bug reports from this MBF. Some were easy to
fix, but there is one subtype of this issue where I think the commonly
given advice and policy currently contradict.
This concerns files that:
- are shipped in the upstream tarball
- are regenerated (with slightly diff
On Wed, Aug 16, 2023 at 11:42:32AM +0800, Paul Wise wrote:
> On Tue, 2023-08-15 at 09:21 -0400, Boyuan Yang wrote:
> > --- ibus-array-0.2.2.orig/po/zh_TW.po
> > +++ ibus-array-0.2.2/po/zh_TW.po
> > @@ -6,7 +6,7 @@ msgid ""
> > msgstr ""
> > "Project-Id-Version: ibus-array 0.2.2\n"
> > "Report-Ms
El martes, 15 de agosto de 2023 13:47:56 -03 Sam Hartman escribió:
> > "Lucas" == Lucas Nussbaum writes:
>
> Lucas> But unless we go further than that and decide that we don't
> Lucas> care at all about 'source builds after successful builds',
> Lucas> the bugs (which where filed
On 2023-08-16 11:45:43 +0800 (+0800), Paul Wise wrote:
> On Sun, 2023-08-13 at 21:18 +, Jeremy Stanley wrote:
>
> > Similarly, I got one for __pycache__/*.cpython-311.pyc file
> > overwrites... is that something dh_python should clean?
>
> Probably just send upstream a change removing them?
On Wed, 16 Aug 2023 at 09:43, Konstantin Demin wrote:
>
> I'd recommend to add in d/rules following variable:
>
> ```make
> export PYTHONDONTWRITEBYTECODE=1
> ```
>
> Optionally add this too:
>
> ```make
> export PYTHONUNBUFFERED=1
> ```
>
> Extra thing:
>
> ```make
> define remove_pycache
>
> : #
On 2023-08-15 09:38:32 +0200, Lucas Nussbaum wrote:
> On 15/08/23 at 01:29 -0400, Michael Stone wrote:
> > we don't know, since the test was "regenerate source"--a thing very few
> > people care about--rather than "build twice" which is the thing people do
> > seem to care about. It seems likely th
I'd recommend to add in d/rules following variable:
```make
export PYTHONDONTWRITEBYTECODE=1
```
Optionally add this too:
```make
export PYTHONUNBUFFERED=1
```
Extra thing:
```make
define remove_pycache
: # $(strip $(1)): remove Python cache
find $(strip $(1))/ -name __pycache__ -type d -exec
On Sun, 2023-08-13 at 22:59 +0200, Timo Röhling wrote:
> There's talk on #d-python if pybuild could/should deal with it; I'd
> give it a few days and see if that pans out.
https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/46
seems to be the one to watch.
Ian.
Am 16.08.23 um 06:02 schrieb Paul Wise:
On Mon, 2023-08-14 at 22:09 +0200, Michael Biebl wrote:
I received a couple of bug reports against packages I (co) maintain
regarding this issue and having a quick look, quite a few fail due to
python scripts being run during the build and creating a __py
On Mon, 2023-08-14 at 22:09 +0200, Michael Biebl wrote:
> I received a couple of bug reports against packages I (co) maintain
> regarding this issue and having a quick look, quite a few fail due to
> python scripts being run during the build and creating a __pycache__
> directory.
I recommend a
On Sun, 2023-08-13 at 22:28 +0200, Johannes Schauer Marin Rodrigues wrote:
> > dpkg-source: info: local changes detected, the modified files are:
> > plakativ-0.5.1/plakativ.egg-info/SOURCES.txt
>
> since this issue seems to be affecting a few more packages than plakativ, I
> wanted to ask here
On Sun, 2023-08-13 at 21:18 +, Jeremy Stanley wrote:
> Similarly, I got one for __pycache__/*.cpython-311.pyc file
> overwrites... is that something dh_python should clean?
Probably just send upstream a change removing them?
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Des
On Tue, 2023-08-15 at 09:21 -0400, Boyuan Yang wrote:
> --- ibus-array-0.2.2.orig/po/zh_TW.po
> +++ ibus-array-0.2.2/po/zh_TW.po
> @@ -6,7 +6,7 @@ msgid ""
> msgstr ""
> "Project-Id-Version: ibus-array 0.2.2\n"
> "Report-Msgid-Bugs-To: https://github.com/lexical/ibus-array/issues\n";
> -"POT-Cr
On Tue, 15 Aug 2023 at 09:21:22 -0400, Boyuan Yang wrote:
> I am looking for advice in handling these MBF reports against packages that do
> irreversible changes to the source files during build every time (such as
> updating timestamp). A broad category would be packages using Gettext + PO
> combi
> "Lucas" == Lucas Nussbaum writes:
Lucas> But unless we go further than that and decide that we don't
Lucas> care at all about 'source builds after successful builds',
Lucas> the bugs (which where filed severity:minor) remain valid.
FWIW in terms of building toward a consensus.
On Aug 15, Jonas Smedegaard wrote:
> The proper approach is IMO one of these:
Or else, if you know that they do not actually need to be rebuilt: just
disable in the makefile the target which causes them to be rebuilt.
This is what I do in my packages.
--
ciao,
Marco
signature.asc
Description
Quoting Jonas Smedegaard (2023-08-15 17:26:13)
> Quoting Boyuan Yang (2023-08-15 16:28:19)
> > Hi,
> >
> > 在 2023-08-15星期二的 16:16 +0200，Jonas Smedegaard写道：
> > > Quoting Boyuan Yang (2023-08-15 15:21:22)
> > > > I am looking for advice in handling these MBF reports against packages
> > > > that do
Quoting Boyuan Yang (2023-08-15 16:28:19)
> Hi,
>
> 在 2023-08-15星期二的 16:16 +0200，Jonas Smedegaard写道：
> > Quoting Boyuan Yang (2023-08-15 15:21:22)
> > > I am looking for advice in handling these MBF reports against packages
> > > that do
> > > irreversible changes to the source files during build
On 2023-08-15 Boyuan Yang wrote:
[...]
> where .po file that contains translation is updated every time, causing dpkg-
> source to complain the diff and quit when building twoce in a row.
> Take https://tracker.debian.org/pkg/ibus-array as an example. The upstream
> project does not include .pot
Hi,
在 2023-08-15星期二的 16:16 +0200，Jonas Smedegaard写道：
> Quoting Boyuan Yang (2023-08-15 15:21:22)
> > I am looking for advice in handling these MBF reports against packages
> > that do
> > irreversible changes to the source files during build every time (such as
> > updating timestamp). A broad cat
Quoting Boyuan Yang (2023-08-15 15:21:22)
> I am looking for advice in handling these MBF reports against packages that do
> irreversible changes to the source files during build every time (such as
> updating timestamp). A broad category would be packages using Gettext + PO
> combination with /usr
Hi all,
(Sorry for losing all contexts -- I deleted all previous mails in the thread
sent to my mailbox, and could not find a way to re-download mailing list email
from https://lists.debian.org/debian-devel/ . It is possible in bug reports on
https://bugs.debian.org though. Now replying with empty
How would one implement this in the common Salsa CI pipeline?
There is an old issue for this [0], but unless someone provides an MR
its unlikely to get implemented.
Occasional rebuild campaigns like this don't catch regression in a
timely manner. Having a build-twice job in the Salsa CI pipel
On 15/08/23 at 01:29 -0400, Michael Stone wrote:
> On Mon, Aug 14, 2023 at 09:40:52PM +0100, Wookey wrote:
> > Yes. You are right. I (and most of the others who expressed an
> > interest in having this working) mostly care about doing a binary
> > build repeatedly. But doesn't this amount to much t
On 14/08/23 at 22:09 +0200, Michael Biebl wrote:
> Could maybe dh_clean automatically clean up such __pycache__ directories or
> do we really expect that each individual package does such a clean up
> manually?
> Or is there maybe a way to avoid the creation of the __pycache__ directories
> altoget
On Mon, Aug 14, 2023 at 09:40:52PM +0100, Wookey wrote:
On 2023-08-14 10:19 -0400, Michael Stone wrote:
On Thu, Aug 10, 2023 at 02:38:17PM +0200, Lucas Nussbaum wrote:
> On 08/08/23 at 10:26 +0200, Helmut Grohne wrote:
> > Are we ready to call for consensus on dropping the requirement that
> > `
On 2023-08-14 10:19 -0400, Michael Stone wrote:
> On Thu, Aug 10, 2023 at 02:38:17PM +0200, Lucas Nussbaum wrote:
> > On 08/08/23 at 10:26 +0200, Helmut Grohne wrote:
> > > Are we ready to call for consensus on dropping the requirement that
> > > `debian/rules clean; dpkg-source -b` shall work or i
On 2023-08-13 22:48 +0200, Vincent Bernat wrote:
> On 2023-08-10 14:38, Lucas Nussbaum wrote:
> >
> > My reading of the discussion is that there's sufficient interest for
> > ensuring that building-source-after-successful-binary-build works.
>
> There is a bias asking d-devel@. You'll get people
Hi,
I received a couple of bug reports against packages I (co) maintain
regarding this issue and having a quick look, quite a few fail due to
python scripts being run during the build and creating a __pycache__
directory.
Examples:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1048444
htt
On Mon, Aug 14, 2023 at 08:28:15AM +0200, Johannes Schauer Marin Rodrigues
wrote:
> Quoting John Goerzen (2023-08-13 23:32:03)
> > On Sat, Aug 05 2023, Lucas Nussbaum wrote:
> > > I wonder what we should do, because 5000+ failing packages is a lot...
> > Let's think about the level of trouble we
On Thu, Aug 10, 2023 at 02:38:17PM +0200, Lucas Nussbaum wrote:
On 08/08/23 at 10:26 +0200, Helmut Grohne wrote:
Are we ready to call for consensus on dropping the requirement that
`debian/rules clean; dpkg-source -b` shall work or is anyone interested
in sending lots of patches for this?
My r
On Sat, 5 Aug 2023 at 17:44, Vincent Bernat wrote:
> 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
El lunes, 14 de agosto de 2023 03:28:15 -03 Johannes Schauer Marin Rodrigues
escribió:
> Hi,
>
> Quoting John Goerzen (2023-08-13 23:32:03)
> > On Sat, Aug 05 2023, Lucas Nussbaum wrote:
> > > I wonder what we should do, because 5000+ failing packages is a lot...
> > Let's think about the level o
Hi,
Quoting John Goerzen (2023-08-13 23:32:03)
> On Sat, Aug 05 2023, Lucas Nussbaum wrote:
> > I wonder what we should do, because 5000+ failing packages is a lot...
> Let's think about the level of trouble we cause trying to tackle something
> that has clearly not bothered anyone for years.
thi
On 2023-08-13 16:32:03 -0500, John Goerzen wrote:
> - Upstream wants to ship things that may get modified during build. Ie,
> autoconf/automake replaces files they ship because they want it to
> work "out of the box" in some fashion. Another example is
> documentation; upstream may ship bui
On Sat, Aug 05 2023, Lucas Nussbaum wrote:
> I wonder what we should do, because 5000+ failing packages is a lot...
Let's think about the level of trouble we cause trying to tackle
something that has clearly not bothered anyone for years.
>From the packaging side, there are many reasons that pro
* Jeremy Stanley [2023-08-13 21:18]:
Similarly, I got one for __pycache__/*.cpython-311.pyc file
overwrites... is that something dh_python should clean?
As a matter of fact, I also have one like that, ironically it is not
even a Python package, it just happens to run Sphinx for its
documentati
On Sat, Aug 05 2023, 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 modification of a D
On 2023-08-13 22:59:53 +0200 (+0200), Timo Röhling wrote:
[...]
> There's talk on #d-python if pybuild could/should deal with it; I'd
> give it a few days and see if that pans out.
>
> If not, extend-diff-ignore as Scott suggested or simply removing the
> egg-info folders with a *.egg-info/ line i
Hi,
* Johannes Schauer Marin Rodrigues [2023-08-13 22:28]:
since this issue seems to be affecting a few more packages than plakativ, I
wanted to ask here what the canonical way is to fix this issue?
There's talk on #d-python if pybuild could/should deal with it; I'd
give it a few days and see
On 2023-08-10 14:38, Lucas Nussbaum wrote:
On 08/08/23 at 10:26 +0200, Helmut Grohne wrote:
Are we ready to call for consensus on dropping the requirement that
`debian/rules clean; dpkg-source -b` shall work or is anyone interested
in sending lots of patches for this?
My reading of the discuss
On August 13, 2023 8:28:08 PM UTC, Johannes Schauer Marin Rodrigues
wrote:
>Hi,
>
>Quoting Simon McVittie (2023-08-06 12:27:04)
>> On Sat, 05 Aug 2023 at 21:29:08 +0200, Andrey Rakhmatullin wrote:
>> > I expect all Python packages that ship
>> > $name.egg-info and don't remove it in clean and
Hi,
Quoting Simon McVittie (2023-08-06 12:27:04)
> On Sat, 05 Aug 2023 at 21:29:08 +0200, Andrey Rakhmatullin wrote:
> > I expect all Python packages that ship
> > $name.egg-info and don't remove it in clean and don't exclude it via
> > extend-diff-ignore (all of which is unneeded busywork even if
On sábado, 12 de agosto de 2023 20:26:09 -03 Lisandro Damian Nicanor Perez
Meyer wrote:
> On sábado, 5 de agosto de 2023 12:06:27 -03 Lucas Nussbaum wrote:
> > Hi,
> >
> > Debian Policy section 4.9 says:
> > clean (required)
> >
> > This must undo any effects that the build and binary t
On sábado, 5 de agosto de 2023 12:06:27 -03 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 10/08/23 at 14:38 +0200, Lucas Nussbaum wrote:
> On 08/08/23 at 10:26 +0200, Helmut Grohne wrote:
> > Are we ready to call for consensus on dropping the requirement that
> > `debian/rules clean; dpkg-source -b` shall work or is anyone interested
> > in sending lots of patches for this?
>
> My r
On Wed, 2023-08-09 at 22:10:51 +0200, Johannes Schauer Marin Rodrigues wrote:
> Quoting Guillem Jover (2023-08-09 20:55:17)
> > I think I've mentioned this before, but dpkg-source is supposed to be
> > generating reproducible source packages since around the time dpkg-deb
> > has been generating re
On Thu, Aug 10, 2023 at 02:22:30PM +0200, Lucas Nussbaum wrote:
> > It might be worth to consider changing your workflow a bit and work with
> > a git repository. It does not have to be a clone of the repository (if
> > any) where the package is maintained, you can start with a fresh import,
> > e.
On 08/08/23 at 10:26 +0200, Helmut Grohne wrote:
> Are we ready to call for consensus on dropping the requirement that
> `debian/rules clean; dpkg-source -b` shall work or is anyone interested
> in sending lots of patches for this?
My reading of the discussion is that there's sufficient interest f
Hi,
On 05/08/23 at 21:01 +0200, Sven Joachim wrote:
> 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 wor
* Jonas Smedegaard [2023-08-10 12:32]:
Example: An organisation has examines licensing of Chromium as installed
ontheir Android and Linux systems, expressed as SPDX datasets with SHA1
checksums for upstream tarballs. They need to do a full analysis for
each upstream release, but would prefer to
Quoting Timo Röhling (2023-08-10 11:56:42)
> Hi,
>
> * Helmut Grohne [2023-08-10 06:43]:
> >When repacking, the upstream signature becomes useless and external
> >parties can no longer verify it at ease. Including that upstream
> >signature increases trust in the source shipped by Debian being
>
Hi,
* Helmut Grohne [2023-08-10 06:43]:
When repacking, the upstream signature becomes useless and external
parties can no longer verify it at ease. Including that upstream
signature increases trust in the source shipped by Debian being
good.
I don't think that problem is very relevant in prac
Hi Wookey,
On Wed, Aug 09, 2023 at 02:30:43PM +0100, Wookey wrote:
> I have never tried Helmut's suggestion of removing this stuff in the
> clean target. It does seem to me that removing it from the tarball
> makes a lot more sense than cleaning it later.
I do see all the advantages of repacking
On 2023-08-09 22:10 +0200, Johannes Schauer Marin Rodrigues wrote:
> it has been a long time since I've analyzed this so things might've changed
> indeed since then. But what I remember is that, depending on the source
> package, running sbuild with --source would produce a different source packag
Hi,
Quoting Guillem Jover (2023-08-09 20:55:17)
> On Wed, 2023-08-09 at 19:55:41 +0200, Johannes Schauer Marin Rodrigues wrote:
> > I would only consider switching the default if at the same time, some checks
> > were done that made sure that the result is bit-by-bit identical to the
> > original.
Hi!
On Wed, 2023-08-09 at 19:55:41 +0200, Johannes Schauer Marin Rodrigues wrote:
> I would only consider switching the default if at the same time, some checks
> were done that made sure that the result is bit-by-bit identical to the
> original.
>
> The source package is the *input* to sbuild no
On August 9, 2023 5:55:41 PM UTC, Johannes Schauer Marin Rodrigues
wrote:
>Hi,
>
>Quoting Stefano Rivera (2023-08-09 14:38:56)
>> Personally, I have my sbuild configured to build a source package after the
>> build, so that I can be sure that I don't regress my own packages' clean
>> target. I
Hi,
Quoting Stefano Rivera (2023-08-09 14:38:56)
> Personally, I have my sbuild configured to build a source package after the
> build, so that I can be sure that I don't regress my own packages' clean
> target. It would be nice if this was a default feature in sbuild, for most
> packages this is
On Tue, Aug 08, 2023 at 10:26:09AM +0200, Helmut Grohne wrote:
> As a minor data point, I also do not rely on `debian/rules clean` to
> work for reproducing the original source tree, because too many packages
> fail it.
>
> Let me point out though that moving to git-based packaging is not the
> pr
On 2023-08-09 10:56 +0100, Simon McVittie wrote:
> On Tue, 08 Aug 2023 at 10:26:09 +0200, Helmut Grohne wrote:
> > With this you touch another purpose of `debian/rules clean`: Removing
> > generated files. Since we currently discourage repackaging and
> > `dpkg-source -b` is vaguely happy about del
Hi Sven (2023.08.05_19:01:19_+)
> It might be worth to consider changing your workflow a bit and work with
> a git repository. It does not have to be a clone of the repository (if
> any) where the package is maintained, you can start with a fresh import,
> e.g. with "gbp import-dsc".
>
> Then
On Tue, 08 Aug 2023 at 10:26:09 +0200, Helmut Grohne wrote:
> With this you touch another purpose of `debian/rules clean`: Removing
> generated files. Since we currently discourage repackaging and
> `dpkg-source -b` is vaguely happy about deleted files, a common
> technique for dealing with generat
On Sat, 2023-08-05 at 17:29 +0100, Simon McVittie wrote:
> Devref §6.8.8.2 also says that "it is common for Debian users who
> need to build software for non-Debian platforms to fetch the source
> from a Debian mirror rather than trying to locate a canonical upstream
> distribution point", but I'm
On Sat, 2023-08-05 at 17:06 +0200, Lucas Nussbaum wrote:
> I wonder what we should do, because 5000+ failing packages is a lot...
Add a message about this on tracker.debian.org for affected packages?
> Should we give up on requiring a 'clean' target that works? After all,
> when 17% of packages
On Sat, Aug 05, 2023 at 05:29:34PM +0100, Simon McVittie wrote:
> I think it's somewhat inevitable that code paths that aren't frequently
> exercised don't work. If a majority of maintainers are doing all of
> their builds with git-buildpackage, or dgit --clean=git, or something
> basically equival
Quoting Timo Röhling (2023-08-05 21:07:34)
> * 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 bu
On Sat, 05 Aug 2023 at 21:29:08 +0200, Andrey Rakhmatullin wrote:
> I expect all Python packages that ship
> $name.egg-info and don't remove it in clean and don't exclude it via
> extend-diff-ignore (all of which is unneeded busywork even if recommended)
> to behave the same.
Python packages that
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 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
89 matches
Mail list logo
