Nikolaus Rath wrote:
>>> Policy 6.1 says
>>> | Programs called from maintainer scripts should not normally have a
>>> | path prepended to them.
>>>
>>> Ie, programs that are on PATH should be found via the PATH rather than
>>> by hardcoding /usr/bin/foo or whatever. In general, I think we
>>> nor
I heard back from doko today. We can expect a reply tomorrow. We also
talked briefly about the issue.
Realistically, i cannot imagine the TC coming to any final decision on
something like this in under three weeks. That timeline seems fairly
aggressive actually.
However, I think the TC could
>> Policy 6.1 says
>> | Programs called from maintainer scripts should not normally have a
>> | path prepended to them.
>>
>> Ie, programs that are on PATH should be found via the PATH rather than
>> by hardcoding /usr/bin/foo or whatever. In general, I think we
>> normally, at least in software w
I see that I am Wrong On The Internet and my efforts not to distract
the TC have been futile. Sorry. Now I am falling subject to the same
problem but I really cannot let all of this go unchallenged.
Daniel Kahn Gillmor writes ("Re: Bug#850967: Clarify /usr/bin/foo should not be
hardcoded even i
Dear Ian,
while I see where you come from, and can empathize with some of your points, I
think that Daniel's following of upstream practices in using full paths is
both fairly common, and a valid practice in Debian Packages.
Le mercredi, 11 janvier 2017, 17.13:44 h CET Ian Jackson a écrit :
> I
Sam Hartman writes ("Re: Bug#850967: Clarify /usr/bin/foo should not be
hardcoded even in upstream parts"):
> [some stuff]
Please concentrate on the MIPS binutils bug.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a pri
]] Sam Hartman
> So, I'd be much more comfortable if we wanted to help make people more
> aware of the tradeoffs than I would setting policy.
Overall, I agree with Sam here, it's hard to come up with hard rules
about this, and as long as upstream and the Debian maintainer have
thought properly t
I'll note that the practice of hard-coding paths is fairly common.
One common cause for this is programs that don't want to rely on PATH
for calling exec. Systemd is a particularly interesting example.
ExecStart and related arguments in systemd units are required to include
full paths.
I am ver
Daniel Kahn Gillmor writes ("Re: Bug#850967: Clarify /usr/bin/foo should not be
hardcoded even in upstream parts"):
> Ian, in the future please x-debbugs-cc me when you take our discussions
> to the tech-ctte :)
Sorry, I should have thought of that.
Thanks for your reply. There are some things
Hi Ian (and hi tech-ctte!)--
On Wed 2017-01-11 12:13:44 -0500, Ian Jackson
wrote:
> Package: tech-ctte
> Control: block 850657 by -1
Ian, in the future please x-debbugs-cc me when you take our discussions
to the tech-ctte :)
> Policy 6.1 says
> | Programs called from maintainer scripts should
On Tue, Jan 10, 2017 at 16:56:05 -0500, Sam Hartman wrote:
>
> Hi.
> I'd really appreciate comments from debian-release on this issue.
> Would debian-release like us to take this up?
> If so, I have a proposal for how to fast-track this situation, but I am
> only comfortable doing that if the rel
On miércoles, 11 de enero de 2017 10:35:37 ART Sam Hartman wrote:
[snip]
> that was to doko not you.
Usual me I'm afraid. I suscribed to the bug and forgot to see the To field.
> I'd be happy to chat, but you've articulated your position fairly well.
> If there's stuff not in the bug you'd like m
Processing control commands:
> block 850657 by -1
Bug #850657 [gnupg] gnupg: Please find gpg-agent on PATH
850657 was not blocked by any bugs.
850657 was not blocking any bugs.
Added blocking bug(s) of 850657: 850967
--
850657: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850657
850967: http
Package: tech-ctte
Control: block 850657 by -1
Policy 6.1 says
| Programs called from maintainer scripts should not normally have a
| path prepended to them.
Ie, programs that are on PATH should be found via the PATH rather than
by hardcoding /usr/bin/foo or whatever. In general, I think we
norm
> "Lisandro" == Lisandro Damián Nicanor Pérez Meyer
> writes:
Lisandro> On miércoles, 11 de enero de 2017 09:39:25 ART Sam Hartman wrote:
>> Hi.
>>
>> As you are probably aware, the question of what to do about
>> linking on mips and stretch has been referred to the
On miércoles, 11 de enero de 2017 11:49:48 ART Lisandro Damián Nicanor Pérez
Meyer wrote:
[snip]
> I'll be online from 17:30 UTC onwards, nick lisandro on freenode.
And also oftc, of course.
--
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
sign
On miércoles, 11 de enero de 2017 09:39:25 ART Sam Hartman wrote:
> Hi.
>
> As you are probably aware, the question of what to do about linking on
> mips and stretch has been referred to the TC.
> There's a reasonable probability that we're going to want to move very
> quickly on this issue, and I
Hi.
As you are probably aware, the question of what to do about linking on
mips and stretch has been referred to the TC.
There's a reasonable probability that we're going to want to move very
quickly on this issue, and I wanted to reach out to you and see how we
could best work with you to colle
I would like to mention that in my previous mail I forgot another possible fix
for this bug: going back to binutils 2.27. The current uploads are snapshots
of the next version, 2.28, and whereas the bug in question seems to habe been
there all the time it started to affect us since a commit in t
19 matches
Mail list logo