On Tue, 19 Jan 2021 at 05:02:29 +0100, Guillem Jover wrote:
> On Mon, 2021-01-11 at 00:48:42 +1100, Stuart Prescott wrote:
> > SOURCE_BASE_DIR has a delightful symmetry to SOURCE_DATE_EPOCH and the
> > algorithm for use is similar: if it is in the environment then use it, if
> > not,
> > fall
Hi!
On Mon, 2021-01-11 at 00:48:42 +1100, Stuart Prescott wrote:
> Sune Stolborg Vuorela wrote:
> > Can you provide some kind of hook in the environment so we at least can work
> > around it in the users, so that the internal functions (where the output of
> > __FILE__ is forwarded to) can glue
On Mon, 11 Jan 2021 at 00:48:42 +1100, Stuart Prescott wrote:
> Looking to the future, tests using SOURCE_BASE_DIR to locate test data would
> allow build-time tests to be repurposed as autopkgtest tests too, as the
> autopkgtest could tell the tests where the test input data is to be found.
Sune Stolborg Vuorela wrote:
> Can you provide some kind of hook in the environment so we at least can work
> around it in the users, so that the internal functions (where the output of
> __FILE__ is forwarded to) can glue e.g. the content of an environment
> variable in front of the usage of the
On Saturday, January 9, 2021 12:49:50 AM CET Guillem Jover wrote:
> Disabling this option in these few places gives you room to possibly
> look for a fix, or not, w/o the pressure of the freeze, while not
> affecting the other packages.
Hi Guillem
Can you provide some kind of hook in the
On 2021-01-09, Lisandro Damián Nicanor Pérez Meyer wrote:
> Note: in case we do not agree on this topic this will be the text I'll
> send to the
> tech-ctte.
Thanks for taking the time to draft some text. If we can come closer to
agreement on the proposed text, that would probably take a bit of
Hi (again)!
On Sat, 9 Jan 2021 at 17:53, Vagrant Cascadian
wrote:
>
> On 2021-01-09, Lisandro Damián Nicanor Pérez Meyer wrote:
> > Oh, I have sadly forgotten to mention another thing.
> >
> > On Sat, 9 Jan 2021 at 15:53, Lisandro Damián Nicanor Pérez Meyer
> > wrote:
> >> # __FILE__ is a
On 2021-01-09, Lisandro Damián Nicanor Pérez Meyer wrote:
> Oh, I have sadly forgotten to mention another thing.
>
> On Sat, 9 Jan 2021 at 15:53, Lisandro Damián Nicanor Pérez Meyer
> wrote:
>> # __FILE__ is a public, well defined API
>
> According to:
> Adrian Bunks mentions it in
>
Hi!
On Sat, 9 Jan 2021 at 16:39, Samuel Thibault wrote:
>
> Lisandro Damián Nicanor Pérez Meyer, le sam. 09 janv. 2021 15:53:41 -0300, a
> ecrit:
> > # __FILE__ is a public, well defined API
>
> ? My copy of C11 says
>
> “
> __FILE__ The presumed name of the current source file (a character
Hi!
On Sat, 9 Jan 2021 at 16:52, Mattia Rizzolo wrote:
>
> On Sat, Jan 09, 2021 at 08:37:48PM +0100, Samuel Thibault wrote:
> > Lisandro Damián Nicanor Pérez Meyer, le sam. 09 janv. 2021 15:53:41 -0300,
> > a ecrit:
> > > # __FILE__ is a public, well defined API
> >
> > ? My copy of C11 says
>
On Sat, Jan 09, 2021 at 08:37:48PM +0100, Samuel Thibault wrote:
> Lisandro Damián Nicanor Pérez Meyer, le sam. 09 janv. 2021 15:53:41 -0300, a
> ecrit:
> > # __FILE__ is a public, well defined API
>
> ? My copy of C11 says
>
> “
> __FILE__ The presumed name of the current source file (a
Lisandro Damián Nicanor Pérez Meyer, le sam. 09 janv. 2021 15:53:41 -0300, a
ecrit:
> # __FILE__ is a public, well defined API
? My copy of C11 says
“
__FILE__ The presumed name of the current source file (a character string
literal)
”
that's not so well-defined. I would not expect it to
Oh, I have sadly forgotten to mention another thing.
On Sat, 9 Jan 2021 at 15:53, Lisandro Damián Nicanor Pérez Meyer
wrote:
> # __FILE__ is a public, well defined API
According to:
Adrian Bunks mentions it in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876901#10
Holger Levsen in
Note: in case we do not agree on this topic this will be the text I'll
send to the
tech-ctte.
Let me start by noting that I have nothing against reproducibility. In fact
quite the opposite: I love the idea... as long as it's properly implemented.
The problem here is that __FILE__ is a public,
On 2021-01-08, Lisandro Damián Nicanor Pérez Meyer wrote:
> On Fri, 8 Jan 2021 at 21:15, Lisandro Damián Nicanor Pérez Meyer
> wrote:
> In fact most of those packages would not be unreproducible if the
> environment would be the same as the original build. That includes the
> build path.
True,
On Fri, 8 Jan 2021 at 21:15, Lisandro Damián Nicanor Pérez Meyer
wrote:
>
> Hi! Explicitely CCing my bug, since it seems it missed my previous reply.
>
> On Fri, 8 Jan 2021 at 20:49, Guillem Jover wrote:
> >
> > On Fri, 2021-01-08 at 19:23:13 -0300, Lisandro Damián Nicanor Pérez Meyer
> >
Hi! Explicitely CCing my bug, since it seems it missed my previous reply.
On Fri, 8 Jan 2021 at 20:49, Guillem Jover wrote:
>
> On Fri, 2021-01-08 at 19:23:13 -0300, Lisandro Damián Nicanor Pérez Meyer
> wrote:
> > [snip]
> > > We did a full archive rebuild testing this change, and I provided
>
On Fri, 2021-01-08 at 19:23:13 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> [snip]
> > We did a full archive rebuild testing this change, and I provided
> > patches to all known affected packages several months ago. It is a
> > one-line change in debian/rules in most cases:
> >
> >
> >
The code that relies on __FILE__ can be found at
https://sources.debian.org/src/qtbase-opensource-src/5.15.2+dfsg-2/src/testlib/qtestcase.h/#L216
So maybe we can try and get a fix there and push this change in the
next stable release, after appropriately tested.
--
Lisandro Damián Nicanor
Hi!
[snip]
>
> We did a full archive rebuild testing this change, and I provided
> patches to all known affected packages several months ago. It is a
> one-line change in debian/rules in most cases:
>
>
>
On 2021-01-08, Lisandro Damián Nicanor Pérez Meyer wrote:
> On Fri, 13 Nov 2020 at 17:40, Vagrant Cascadian
> wrote:
>>
>> On 2020-11-13, Sune Vuorela wrote:
>> > On 2020-10-27, Vagrant Cascadian wrote:
>> >> Though, of course, identifying the exact reproducibility problem would
>> >> be
On Fri, 8 Jan 2021 at 10:29, Lisandro Damián Nicanor Pérez Meyer
wrote:
>
> Hi! Sorry for this late reply, but it just came into my view.
>
> On Fri, 13 Nov 2020 at 17:40, Vagrant Cascadian
> wrote:
> >
> > On 2020-11-13, Sune Vuorela wrote:
> > > On 2020-10-27, Vagrant Cascadian wrote:
> > >>
Hi! Sorry for this late reply, but it just came into my view.
On Fri, 13 Nov 2020 at 17:40, Vagrant Cascadian
wrote:
>
> On 2020-11-13, Sune Vuorela wrote:
> > On 2020-10-27, Vagrant Cascadian wrote:
> >> Though, of course, identifying the exact reproducibility problem would
> >> be preferable.
Hi!
On Mon, 2020-11-16 at 02:33:53 +0100, Guillem Jover wrote:
> On Sat, 2020-11-14 at 11:15:03 -0800, Vagrant Cascadian wrote:
> > > Adding more hurdles does not help.
> > > I think this is a hurdle we do not need.
> >
> > To me, a one-line change in packaging seems like a quite small hurdle
On Sat, 2020-11-14 at 11:15:03 -0800, Vagrant Cascadian wrote:
> On 2020-11-14, Sune Vuorela wrote:
> > Unfortunately, only like 10% of the relevant packages have test suites
> > enabled and run, because gettings things to work reliable is sometimes
> > hard.
> So, based on your estimate and the
On 2020-11-14, Sune Vuorela wrote:
> On 2020-11-13, Vagrant Cascadian wrote:
>> If it could be fixed at the core for QFINDTESTDATA, that would be nicer
>> than fixing 20-30 packages individually, though we're not there right
>> now.
>
> Unfortunately, only like 10% of the relevant packages have
On 2020-11-13, Sune Vuorela wrote:
> On 2020-10-27, Vagrant Cascadian wrote:
>> Though, of course, identifying the exact reproducibility problem would
>> be preferable. One of the common issues is test suites relying on the
>> behavior of __FILE__ returning a full path to find fixtures or other
On 2020-10-27, Vagrant Cascadian wrote:
> Though, of course, identifying the exact reproducibility problem would
> be preferable. One of the common issues is test suites relying on the
> behavior of __FILE__ returning a full path to find fixtures or other
> test data.
has QFIND_TESTDATA been
Hi
On Mon, 9 Nov 2020 at 22:06, Vagrant Cascadian
wrote:
> Given no objections or concerns of any kind raised in the last two
> weeks, I've submitted a bug against dpkg:
>
> https://bugs.debian.org/974087
There was a query from one of our upstreams in #972294 to which I have
not seen a
On 2020-10-27, Vagrant Cascadian wrote:
> The dpkg-buildflags feature reproducible=+fixfilepath was added to dpkg
> in 2018.
...
> The result of enabling this feature by default will be to make several
> hundred packages reproducible with varying build-path and reduce the
> differences in many
The dpkg-buildflags feature reproducible=+fixfilepath was added to dpkg
in 2018.
## What does this feature do exactly?
From the dpkg-buildflags(1) manpage:
fixfilepath
This setting (disabled by default) adds
-ffile-prefix-map=BUILDPATH=. to CFLAGS, CXXFLAGS, OBJCFLAGS,
31 matches
Mail list logo
