Wouter Verhelst writes:
> How can it do so, though, if the build system hardcodes paths to
> binaries[1]? Isn't it better (and easier) to have non-usr-merged buildd
> chroots as long as we still support such systems?
> [1] Yes, I know policy says you shouldn't do that, but if there's a
> 3000-li
On 27 November 2018 at 08:04, Kurt Hornik wrote:
| The new r-base-core (3.5.1-2+b1) also seems fine on i386. Thanks!
Great news, thanks for reporting back!
All systems green, and Chris (was usual) right along :)
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> | Dirk Eddelbuettel writes ("Our build system may be broken: /bin vs
> > /usr/bin"):
> > | > tl;dr: We may be messing up /bin and /usr/bin on some platforms
> > |
> > | This is the result of the change of the buildds to have `usrmerge', ie
> > |
> Dirk Eddelbuettel writes:
> On 20 November 2018 at 02:35, Chris Lamb wrote:
> | Hi Dirk,
> |
> | > | > … Simon McVittie has actually patched our testing framework to vary
> | > | > this and this is now live.
> | > | >
> | > | > https://bugs.debian.org/901473#33
> | […]
> | > Are we sure t
On Tue, Nov 20, 2018 at 04:12:01PM +, Simon McVittie wrote:
> Please use debootstrap --no-merged-usr explicitly if you want to be able
> to exercise the "not merged /usr" code path. I attach an untested patch.
thanks, merged and deployed/. (Plus recreation of 200 pbuilder base.tgz's
triggered
On Tue, 20 Nov 2018 at 12:16:06 +, Holger Levsen wrote:
> from irc:
>
> < mapreri> I haven't checked, but I think the merged-usr variation is now
> broken already. Now that debootstrap in stretch-backports (which is the
> version we use) defaults to merged-usr installing that special package
[pruning CC]
Dirk,
> Other than forcing builds through the system is there another way for me to
> check in, say, a week or two?
Not entirely sure what you mean here. You can certainly reschedule
builds at will, but in terms of "checking-in" a fortnight from now…
set a date in your calendar? ;)
On Tue, Nov 20, 2018 at 02:35:56AM -0500, Chris Lamb wrote:
> > | > … Simon McVittie has actually patched our testing framework to vary
> > | > this and this is now live.
> > | > https://bugs.debian.org/901473#33
> > Are we sure this is fixed?
I think it's broken...
from irc:
< mapreri> I hav
On 20 November 2018 at 02:35, Chris Lamb wrote:
| Hi Dirk,
|
| > | > … Simon McVittie has actually patched our testing framework to vary
| > | > this and this is now live.
| > | >
| > | > https://bugs.debian.org/901473#33
| […]
| > Are we sure this is fixed?
|
| It might have taken a while fo
Hi Dirk,
> | > … Simon McVittie has actually patched our testing framework to vary
> | > this and this is now live.
> | >
> | > https://bugs.debian.org/901473#33
[…]
> Are we sure this is fixed?
It might have taken a while for various build chroots to update so
I would be wary of inferring too
On 19 November 2018 at 17:32, Sean Whitton wrote:
| Hello,
|
| On Mon 19 Nov 2018 at 01:15PM -0500, Chris Lamb wrote:
|
| > Hi Dimitri,
| >
| >> […] e.g. using reproducible builds infra to do "build in
| >> --no-merged-usr, rebuild in --merged-usr, result should be the same"
| >> either as a on
Hello,
On Mon 19 Nov 2018 at 01:15PM -0500, Chris Lamb wrote:
> Hi Dimitri,
>
>> […] e.g. using reproducible builds infra to do "build in
>> --no-merged-usr, rebuild in --merged-usr, result should be the same"
>> either as a one-off, or on the ongoing basis.
>
> So, as mentioned on:
>
> https:/
Hi Dimitri,
> […] e.g. using reproducible builds infra to do "build in
> --no-merged-usr, rebuild in --merged-usr, result should be the same"
> either as a one-off, or on the ongoing basis.
So, as mentioned on:
https://reproducible-builds.org/blog/posts/185/
… Simon McVittie has actually patc
Michael Biebl writes:
>
> Most packages which are affected by this issue I've seen so far search
> for the binaries in $PATH and encode the full path of the first find.
> Since PATH is typically set to something like
>
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
Am 19.11.18 um 15:55 schrieb Dirk Eddelbuettel:
>
>
> tl;dr: We may be messing up /bin and /usr/bin on some platforms
>
>
> Sorry for the alarming headline but #913982 was filed, indepedently
> corrobated and simultaneously discovered by upstream.
>
> GNU R has long been relying on sed, tar,
Ian Jackson writes:
> Russ Allbery writes ("Re: Our build system may be broken: /bin vs /usr/bin"):
>> Marco d'Itri writes:
>>> Actually this is the root problem: policy says that packages should
>>> use the $PATH to search for commands, but your pack
Russ Allbery writes ("Re: Our build system may be broken: /bin vs /usr/bin"):
> Marco d'Itri writes:
> > Actually this is the root problem: policy says that packages should use
> > the $PATH to search for commands, but your package (like many others)
> > ha
Matthias Klumpp writes ("Re: Our build system may be broken: /bin vs /usr/bin"):
> Ideally the build system would correctly detect an usr-merged system
> and set paths accordingly.
I don't know how that would be possible. If it's determined to
hardcode a path, th
Marco d'Itri writes:
> On Nov 19, Dirk Eddelbuettel wrote:
>> GNU R has long been relying on sed, tar, bzip2, ... and many more base
>> tools. No issues there. Generally looked for in /bin and found there.
> Actually this is the root problem: policy says that packages should use
> the $PATH to
❦ 19 novembre 2018 09:51 -0600, Dirk Eddelbuettel :
> | Dirk Eddelbuettel writes ("Our build system may be broken: /bin vs
> /usr/bin"):
> | > tl;dr: We may be messing up /bin and /usr/bin on some platforms
> |
> | This is the result of the change of the bu
On 19 November 2018 at 16:59, Matthias Klumpp wrote:
| Am Mo., 19. Nov. 2018 um 16:52 Uhr schrieb Dirk Eddelbuettel
:
| >
| >
| > Hi Ian,
| >
| > Thanks for the follow-up.
| >
| > On 19 November 2018 at 15:45, Ian Jackson wrote:
| > | Dirk Eddelbuettel writes ("O
On Nov 19, Matthias Klumpp wrote:
> I wonder how this was handled on other distributions when they made
> the change - even if the change was applied on all systems, there must
> have been at least one release where both modes were supported.
No, Fedora and RHEL just switched overnight.
On Nov 1
On Mon, 19 Nov 2018 at 15:02, Dirk Eddelbuettel wrote:
>
>
>
> tl;dr: We may be messing up /bin and /usr/bin on some platforms
>
>
> Sorry for the alarming headline but #913982 was filed, indepedently
> corrobated and simultaneously discovered by upstream.
>
> GNU R has long been relying on sed,
On Nov 19, Dirk Eddelbuettel wrote:
> GNU R has long been relying on sed, tar, bzip2, ... and many more base
> tools. No issues there. Generally looked for in /bin and found there.
Actually this is the root problem: policy says that packages should use
the $PATH to search for commands, but your
Dirk Eddelbuettel writes ("Re: Our build system may be broken: /bin vs
/usr/bin"):
> That was very much my gut feel but I am a little removed from the more core
> moving and shaking and I didn't know what changed recently.
This usrmerge change has been discussed here on -de
Am Mo., 19. Nov. 2018 um 16:52 Uhr schrieb Dirk Eddelbuettel :
>
>
> Hi Ian,
>
> Thanks for the follow-up.
>
> On 19 November 2018 at 15:45, Ian Jackson wrote:
> | Dirk Eddelbuettel writes ("Our build system may be broken: /bin vs
> /usr/bin"):
> | > tl;
Hi Ian,
Thanks for the follow-up.
On 19 November 2018 at 15:45, Ian Jackson wrote:
| Dirk Eddelbuettel writes ("Our build system may be broken: /bin vs /usr/bin"):
| > tl;dr: We may be messing up /bin and /usr/bin on some platforms
|
| This is the result of the change of the bu
Dirk Eddelbuettel writes ("Our build system may be broken: /bin vs /usr/bin"):
> tl;dr: We may be messing up /bin and /usr/bin on some platforms
This is the result of the change of the buildds to have `usrmerge', ie
merged /bin and /usr/bin. I think this shows that this chang
tl;dr: We may be messing up /bin and /usr/bin on some platforms
Sorry for the alarming headline but #913982 was filed, indepedently
corrobated and simultaneously discovered by upstream.
GNU R has long been relying on sed, tar, bzip2, ... and many more base
tools. No issues there. Generally l
29 matches
Mail list logo
