On jueves, 16 de noviembre de 2017 13:22:00 -03 Ximin Luo wrote:
[snip]
> I pointed to the various C standards documents, as well as documentation
> from multiple compilers, stating that __FILE__ is the "name of the source
> file" and in no way guarantees that the expansion can later be re-used as
Lisandro Damián Nicanor Pérez Meyer:
> By the way: is there a macro or combination of macros which *default* value
> can be replaced in the use of __FILE__ without caussing regressions?
>
> Because if that's the case it's easier to convince upstream people that
> changing the usage goes in favor
Lisandro Damián Nicanor Pérez Meyer:
> [..]
>
> Yes, we do understand that your workaround solves the issue, but we do also
> understand that we should not be using this workaround in the first place.
>
> Guillem: the thread is long, but be sure that we Qt/KDE maintainers consider
> that this c
By the way: is there a macro or combination of macros which *default* value
can be replaced in the use of __FILE__ without caussing regressions?
Because if that's the case it's easier to convince upstream people that
changing the usage goes in favor of reproducibility without using strange up-
t
Explicitely CCing Guillem for this one.
On miércoles, 15 de noviembre de 2017 23:01:00 -03 Ximin Luo wrote:
[sip]
> The GCC patch (neither the previous nor the planned version) does not change
> the default behaviour of __FILE__, and was never intended to. Instead, it
> gives users the ability to
Lisandro Damián Nicanor Pérez Meyer:
> On miércoles, 15 de noviembre de 2017 20:35:00 -03 Ximin Luo wrote:
>> Lisandro Damián Nicanor Pérez Meyer:
>>> I was wanting to write this on a keyboard, but let me try on the phone and
>>> see if we can all agree in one point.
>>>
>>> There is one *excellent
On miércoles, 15 de noviembre de 2017 20:35:00 -03 Ximin Luo wrote:
> Lisandro Damián Nicanor Pérez Meyer:
> > I was wanting to write this on a keyboard, but let me try on the phone and
> > see if we can all agree in one point.
> >
> > There is one *excellent* method to settle this once and foreve
El 15 nov. 2017 5:35 p.m., "Mattia Rizzolo" escribió:
On Wed, Nov 15, 2017 at 05:28:06PM -0300, Lisandro Damián Nicanor Pérez
Meyer wrote:
> There is one *excellent* method to settle this once and forever: submit
the
> __FILE__ patch to GCC devs. If it gets accepted then Qt and whatever
> project
On Wed, Nov 15, 2017 at 05:28:06PM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> There is one *excellent* method to settle this once and forever: submit the
> __FILE__ patch to GCC devs. If it gets accepted then Qt and whatever
> project is affected should change it.
It's forwarded, and it
Lisandro Damián Nicanor Pérez Meyer:
> I was wanting to write this on a keyboard, but let me try on the phone and
> see if we can all agree in one point.
>
> There is one *excellent* method to settle this once and forever: submit the
> __FILE__ patch to GCC devs. If it gets accepted then Qt and wh
I was wanting to write this on a keyboard, but let me try on the phone and
see if we can all agree in one point.
There is one *excellent* method to settle this once and forever: submit the
__FILE__ patch to GCC devs. If it gets accepted then Qt and whatever
project is affected should change it.
I
In data mercoledì 15 novembre 2017 20:14:00 CET, Ximin Luo ha scritto:
> Pino Toscano:
> > Loose meanings do not imply neither the other way around, that you are
> > free to break because people cannot do anything with it. Also,
> > considering the very same behaviour (short of the different wordi
Pino Toscano:
> Loose meanings do not imply neither the other way around, that you are
> free to break because people cannot do anything with it. Also,
> considering the very same behaviour (short of the different wording in
> documentations) that is established for decades, this is a "de facto"
>
In data mercoledì 15 novembre 2017 19:29:00 CET, Ximin Luo ha scritto:
> Pino Toscano:
> > [..]
> >
> >> In summary: in no document or standard, does it guarantee or imply
> >> that __FILE__ can be taken to represent a real filesystem path.
> >> Applications relying on this behaviour are broken an
Pino Toscano:
> [..]
>
>> In summary: in no document or standard, does it guarantee or imply
>> that __FILE__ can be taken to represent a real filesystem path.
>> Applications relying on this behaviour are broken and should not be
>> upset when things don't work. As documented in multiple places,
In data mercoledì 15 novembre 2017 12:09:00 CET, Ximin Luo ha scritto:
> Lisandro Damián Nicanor Pérez Meyer:
> > [..]
> >
> > Xi: you also mentioned that having to file hundreds of patchs seems
> > impossible. Well, it seems so, but it is actually not that necessary.
> > Please
> > allow me to
In data mercoledì 15 novembre 2017 10:57:00 CET, Ximin Luo ha scritto:
> Pino Toscano:
> > In data martedì 14 novembre 2017 11:14:00 CET, Ximin Luo ha scritto:
> >> You're using __FILE__ inappropriately, none of the documentation
> >> guarantees or implies that you can access __FILE__ as a real
> >
El 15 nov. 2017 8:00 a.m., "Ximin Luo" escribió:
Pino Toscano:
> In data martedì 14 novembre 2017 11:14:00 CET, Ximin Luo ha scritto:
>> You're using __FILE__ inappropriately, none of the documentation
>> guarantees or implies that you can access __FILE__ as a real
>> filesystem path. "Surely for
Lisandro Damián Nicanor Pérez Meyer:
> [..]
>
> Xi: you also mentioned that having to file hundreds of patchs seems
> impossible. Well, it seems so, but it is actually not that necessary. Please
> allow me to explain the idea.
>
Thanks for being less inflammatory than Pino.
I agree that event
Pino Toscano:
> In data martedì 14 novembre 2017 11:14:00 CET, Ximin Luo ha scritto:
>> You're using __FILE__ inappropriately, none of the documentation
>> guarantees or implies that you can access __FILE__ as a real
>> filesystem path. "Surely for relative paths" is your justification
>> for your
In data martedì 14 novembre 2017 13:47:56 CET, Holger Levsen ha scritto:
> On Tue, Nov 14, 2017 at 07:22:07AM +0100, Pino Toscano wrote:
> > > There are quite a lot of packages that use __FILE__ so forgive me for
> > > not checking every single use-case of it.
> >
> > This. When something is used
In data martedì 14 novembre 2017 11:14:00 CET, Ximin Luo ha scritto:
> You're using __FILE__ inappropriately, none of the documentation
> guarantees or implies that you can access __FILE__ as a real
> filesystem path. "Surely for relative paths" is your justification
> for your own broken behaviour
On martes, 14 de noviembre de 2017 13:45:37 -03 Holger Levsen wrote:
> On Tue, Nov 14, 2017 at 11:34:00AM +, Ximin Luo wrote:
> > > Sorry, it is not realistic to force us to have a delta from upstream for
> > > no
> > > direct gain.
> >
> > None of the solutions I suggested involve patching up
On martes, 14 de noviembre de 2017 11:34:00 -03 Ximin Luo wrote:
> Lisandro Damián Nicanor Pérez Meyer:
> > [..]
> >
> > Sorry, it is not realistic to force us to have a delta from upstream for
> > no
> > direct gain.
>
> None of the solutions I suggested involve patching upstream, they would be
On Tue, Nov 14, 2017 at 07:22:07AM +0100, Pino Toscano wrote:
> > There are quite a lot of packages that use __FILE__ so forgive me for
> > not checking every single use-case of it.
>
> This. When something is used so widely, then changing its behaviour
> blindly is simply a no-no.
I tend to agr
On Tue, Nov 14, 2017 at 11:34:00AM +, Ximin Luo wrote:
> > Sorry, it is not realistic to force us to have a delta from upstream for no
> > direct gain.
> None of the solutions I suggested involve patching upstream, they would be
> done in d/rules.
"we do not only care about Debian but free s
Lisandro Damián Nicanor Pérez Meyer:
> [..]
>
> Sorry, it is not realistic to force us to have a delta from upstream for no
> direct gain.
>
None of the solutions I suggested involve patching upstream, they would be done
in d/rules.
X
--
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5F
Pino Toscano:
> [..]
>
>> Well let's take a look at the standards:
>> [...]
>
> Even with different wordings, both describe basically the same
> behaviour. And yes, none of them says that __FILE__ is a full path,
> but surely for relative paths the combination of $srcdir + __FILE__
> will give m
In data lunedì 13 novembre 2017 23:44:00 CET, Ximin Luo ha scritto:
> Pino Toscano:
> > [..]
> >
> > This is not an annoyance, it is the crux of the problem! __FILE__ is
> > something standard, with a very well defined behaviour, upon which
> > people rely on: you cannot trash it from one day to
On lunes, 13 de noviembre de 2017 23:44:00 -03 Ximin Luo wrote:
> Pino Toscano:
> > [..]
> >
> > This is not an annoyance, it is the crux of the problem! __FILE__ is
> > something standard, with a very well defined behaviour, upon which
> > people rely on: you cannot trash it from one day to anot
Pino Toscano:
> [..]
>
> This is not an annoyance, it is the crux of the problem! __FILE__ is
> something standard, with a very well defined behaviour, upon which
> people rely on: you cannot trash it from one day to another like this,
> saying "too bad" to all its users, even those using it appr
On lunes, 13 de noviembre de 2017 20:03:00 -03 Ximin Luo wrote:
[snip]
> > This is clearly a misuse, and thus it must be fixed. OTOH, the
> > comparison with __FILE__ is not appropriate.
>
> Why's it not appropriate?
Because it changes well defined macro.
> If you ever want to write tests to be
In data lunedì 13 novembre 2017 20:20:00 CET, Ximin Luo ha scritto:
> Pino Toscano:
> > [..]
> >
> > A better approach here is to work on removing the invalid & abusing
> > usages of __FILE__ from packages, just like it was done for __DATE__.
> >
>
> We in fact did not do the latter because it w
In data lunedì 13 novembre 2017 20:03:00 CET, Ximin Luo ha scritto:
> Pino Toscano:
> > [..]
> >
> > No, the solution is:
> > a) *not* break what __FILE__ means
> > b) remove the misuses of __FILE__ in packages (not the case of
> >QFINDTESTDATA)
> >
> >> I am not "blaming the user", but point
Pino Toscano:
> [..]
>
> A better approach here is to work on removing the invalid & abusing
> usages of __FILE__ from packages, just like it was done for __DATE__.
>
We in fact did not do the latter because it was easier to implement
SOURCE_DATE_EPOCH to fix the expansion of __DATE__, rather t
Pino Toscano:
> [..]
>
> No, the solution is:
> a) *not* break what __FILE__ means
> b) remove the misuses of __FILE__ in packages (not the case of
>QFINDTESTDATA)
>
>> I am not "blaming the user", but pointing to the fact that __FILE__
>> is being used in a surprising way here, which is not
On lunes, 13 de noviembre de 2017 19:15:44 -03 Pino Toscano wrote:
[snip]
> What I see it is happening here is: you (= people working on
> reproducible builds) see __FILE__, and the problems that arise from its
> abuse; to overcome this issue, you use the sledgehammer solution,
> basically changin
control: severity -1 wishlist
On Mon, Nov 13, 2017 at 07:15:44PM +0100, Pino Toscano wrote:
> Exactly, this is the source of the problem. OTOH, the problem was
> created by changing __FILE__: it has a well-defined meaning:
> https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html
> cha
In data lunedì 13 novembre 2017 17:35:00 CET, Ximin Luo ha scritto:
> Adrian Bunk:
> > Control: reassign -1 qtbase5-dev
> > Control: reassign 876917 qtbase5-dev
> > Control: reassign 876933 qtbase5-dev
> > Control: forcemerge -1 876917 876933
> > Control: retitle -1 QFINDTESTDATA uses __FILE__
> >
On Mon, Nov 13, 2017 at 05:35:00PM +, Ximin Luo wrote:
> Our patched dpkg tells GCC to map $PWD to "$srcpkg-$version" when expanding
> __FILE__. That is the source of the problem, because this path doesn't exist
> at test-time. You have the following options:
>
> 1. Unset BUILD_PATH_PREFIX_M
Ximin Luo:
> Ximin Luo:
>> [..]
>>
>> (maybe there are other options)
>>
>
> If all the test files reside underneath the same directory, like tests/, you
> could:
>
> 4. export BUILD_PATH_PREFIX_MAP="$BUILD_PATH_PREFIX_MAP=tests=$BASEDIR/tests".
>
Argh, I mean of course:
4. export BUILD_PATH_
Ximin Luo:
> [..]
>
> (maybe there are other options)
>
If all the test files reside underneath the same directory, like tests/, you
could:
4. export BUILD_PATH_PREFIX_MAP="$BUILD_PATH_PREFIX_MAP=tests=$BASEDIR/tests".
This should make the tests pass, whilst keeping our "$srcpkg-$version" map
Adrian Bunk:
> Control: reassign -1 qtbase5-dev
> Control: reassign 876917 qtbase5-dev
> Control: reassign 876933 qtbase5-dev
> Control: forcemerge -1 876917 876933
> Control: retitle -1 QFINDTESTDATA uses __FILE__
> Control: severity -1 normal
> Control: affects -1 src:karchive src:ki18n src:kcode
Control: reassign -1 qtbase5-dev
Control: reassign 876917 qtbase5-dev
Control: reassign 876933 qtbase5-dev
Control: forcemerge -1 876917 876933
Control: retitle -1 QFINDTESTDATA uses __FILE__
Control: severity -1 normal
Control: affects -1 src:karchive src:ki18n src:kcodecs src:kparts
thanks
The p
44 matches
Mail list logo
