bug#30768: Gettext : test-copy-file-1.sh fail if --with-store-dir=/var/tmp/xxxxx/gnu/store

[YOANN P]

Hi Ludo,

>Hi Yoann,
>
>YOANN P  skribis:
>
>>> We won’t apply this patch because in general there’s no reason for build
>>> processes to require /var/tmp (we’ve never encountered that.)
>>
>> There's always a first time. Since i didn't encounter this behavior with 
>> other 
>> custom directories than i've tested, looking at the code of the test who 
>> failed,
>> i suppose than the store dir is mounted inside the build chroot as itself 
>> and is
>> the reason why "/var/tmp" exist during the build with a store dir starting 
>> by 
>> "/var/tmp".
>>
>> Despite the fact that generally there’s no reason for build processes to 
>> require
>> /var/tmp, is there any risk to add it to the chroot dirs ? If yes (or didn't 
>> want to
>> add it), maybe a warning about the fact than we should never use a directory 
>> inside "/var/tmp" as store should maybe be add (it will had saving me many 
>> hours banging my head) because i've never read somewhere that there was 
>> some forbidden directories to use as store and it seems there is some 
>> regarding the bug i encounter.
>
>In general we’re very cautious about changing what goes into the build
>environment.  The daemon provides isolated build environments, and
>things will behave differently if we start adding/removing directories
>or files; even simple changes like this can easily hinder
>reproducibility.
>

Indeed.
If I keep to persist with my patch applied inside my test env, we'll see if 
i hit some bug, but i'm pretty sure that your continuous deployment already 
test if this kind of patch have an impact on the builds.

>>> That said, are you sure you want to use 
>>> --with-store-dir=/var/tmp/x/gnu/store?
>>
>> Yeah, i'm pretty sure i did want to use this kind of path even if it sounds 
>> weird or the reasons are not good. The purpose of my tests was to 
>> configure the store with a symlink /var/tmp/guix-[short-hash] who is 
>> pointing to a directory where i have the rights. This way, i could use 
>> my environment with user X on server A or user Y on server B only by 
>> adapting my symlink.
>>
>> This way, i could achieve a unprivileged portable environment because 
>> /var/tmp seems present and writable on all major distribution, plus it 
>> seems to work even if /var/tmp is mount with noexec.
>
>OK, I see.  That’s a worthy goal and a neat hack (I don’t think it’s
>been tried before.)
>

Maybe if it hasn't test before, there was a good reason ;)
Like the fact I wasn't aware of this kind of patch who seems to prevent the 
daemon to access directly the store via a direct symlink but require to symlink 
the upper directory.
https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Symlink_Protection

>>> You probably got a ‘configure’ warning already that certain things may
>>> not work, for instance that the shebang max length may be exceeded.
>>
>> Regarding the warning , i just checked my ./configure log, and there is 
>> no warning about the limit length for the store path due to the limit of 
>> shebang length, only a warning regarding the substitutes.
>>
>> Even if i was aware of it after reading Pjotrp notes, i've never found a 
>> clear limit after my readings on the web. If Guix Team has an idea of 
>> the store path limit lenght, it could be a great idea to add it to the docs 
>> or did i missed it ?
>
>From m4/guix.m4:
>
>--8<---cut here---start->8---
>dnl 'BINPRM_BUF_SIZE' constant in Linux (we leave room for the trailing zero.)
>dnl The Hurd has a limit of about a page (see exec/hashexec.c.)
>m4_define([LINUX_HASH_BANG_LIMIT], 127)
>
>dnl Hardcoded 'sun_path' length in .
>m4_define([SOCKET_FILE_NAME_LIMIT], 108)
>--8<---cut here---end--->8---
>

Hum, i'm not sure this part of code answer my question :)
Are we agreed than LINUX_HASH_BANG_LIMIT is the max number of char for a 
shebang and SOCKET_FILE_NAME_LIMIT is only the limit for the socket file name ?

What i was asking is the maximum lenght for the store path regarding the fact 
(if i am not wrong) than a shebang inside guix is compose like this :

[store_path]/[build_hash]-[program_name]-[program_version]/bin/[program_name]

- is there a convention who defined the maximum lenght of a program version 
string ? 
(1.1.1, 1.1.1-rc1, 1.1.1-beta)

- is there a convention who defined the maximum lenght of a program name ? 

I think than if there is no limit for those two strings inside the store, we 
can't exactly know 
the maximum lenght for the store path but maybe you have a quick way to lookup 
at 
the maximum lenght for thoses two strings in all guix builds ?

>>> Also using a store other than /gnu/store means you won’t be able to use
>>> substitutes, nor to compare build results with other machines.
>>
>> I'm pretty aware of that, but having a portable environment who could be 
>> used even under unprivileged user without the needing of "proot" / 
>> "usernamespace" come with some 

bug#30785: Man pages truncated, repeated

[Tobias Geerinckx-Rice]

Ludo',

On 2018-03-13 22:34, l...@gnu.org wrote:

However, even longer man pages such as bash(1) render without fail, so
there might be something special about the two examples above that
triggers this behaviour.


I suspect something wrong with ‘knot.conf.5.gz’, but I don’t have
tangible evidence.


Yup, that's about as far as I got before giving up and submitting to the 
wisdom of the crowd. We need someone who knows something — anything — 
about man pages, or someone who can reproduce this on another distro. I 
had no luck searching for similar bug reports.


...or do you mean with the knot.conf page *specifically*, as opposed to 
the rofi one? Is your suspicion based on something you saw in there?


It's not the .gz part: opening the uncompressed page with man directly 
has the same result.


--

For the record: apparently this doesn't happen on Debian, according to 
some fellow on IRC named ‘civodul’. There goes my brief hope that this 
was an (exclusively) upstream problem after all.


Kind regards,

T G-R

Sent from a Web browser. Excuse or enjoy my brevity.

bug#30808: [feature-request] improve integration of proxies in guix

[ng0]

Currently we have the http_proxy env var which can be set in the
environment if guix-daemon and is honored by downloads of
substitutes.

As discussed a couple of days ago on IRC, adding the ability
to use proxies for all parts of guix that are concerned with
data retrieved via network would be very good for deplyoment
of Guix in environments we usually do not consider (corporate
firewalls, places with high censorship, people who generally
do want to use proxies or have to use proxies, the list of
reasons and possibilities is longer than I want to type.

bug#30282: package julia build error

[Andreas Enge]

Hello,

On Tue, Mar 13, 2018 at 06:02:07PM +0100, Ludovic Courtès wrote:
> I tried the patch below (README.md in Julia 0.6.0 says that plain LLVM
> 3.9 without patches is OK), but that didn’t solve the
> distributed.jl-related test failures.

there is a 0.6.2 version already. I do not expect it to solve test failures,
but it might make sense to try an update first.

Andreas

bug#30282: package julia build error

[Ludovic Courtès]

Hi Pjotr,

Pjotr Prins  skribis:

> One immediate problem is that Julia comes with patches for LLVM 3.9
> only:
>
>   https://github.com/JuliaLang/julia#llvm
>
> it downloads, patches and compiles a specific LLVM. We actually need
> this even though the failing tests are possibly not related (I suspect
> the math libraries are not showing the same results as the built-in
> ones).

Oh, indeed.

For arpack-ng using the right version did help.  It might be similar for
other dependencies.

I tried the patch below (README.md in Julia 0.6.0 says that plain LLVM
3.9 without patches is OK), but that didn’t solve the
distributed.jl-related test failures.

> I think we need to follow the recommended build steps for Julia first.
> Then the tests should pass. Next perhaps link out components and send
> bug reports upstream.

Yeah, though we’d rather extract these bundled pieces somehow.

Thanks,
Ludo’.

diff --git a/gnu/packages/julia.scm b/gnu/packages/julia.scm
index 41bbc66dd..8e5e81314 100644
--- a/gnu/packages/julia.scm
+++ b/gnu/packages/julia.scm
@@ -314,7 +314,7 @@
 "USE_SYSTEM_LIBGIT2=1"
 "USE_SYSTEM_OPENSPECFUN=1")))
 (inputs
- `(("llvm" ,llvm)
+ `(("llvm" ,llvm-3.9.1)
("arpack-ng" ,arpack-ng)
("coreutils" ,coreutils) ;for bindings to "mkdir" and the like
("lapack" ,lapack)

bug#30282: package julia build error

[Pjotr Prins]

One immediate problem is that Julia comes with patches for LLVM 3.9
only:

  https://github.com/JuliaLang/julia#llvm

it downloads, patches and compiles a specific LLVM. We actually need
this even though the failing tests are possibly not related (I suspect
the math libraries are not showing the same results as the built-in
ones).

I think we need to follow the recommended build steps for Julia first.
Then the tests should pass. Next perhaps link out components and send
bug reports upstream.

Pj.

bug#30282: package julia build error

[Pjotr Prins]

> Help welcome!

I'll take a look.

Pj.
--