(current-filename) behaves differently in environment|build

[wldhx]

Hi guix,

Discovered following behaviour while setting up GNUnet CI:

Given

./gnu/packages/a.scm:
   ...
   (source (local-file (dirname (current-filename
   ...

export GUIX_PACKAGE_PATH=$PWD

`(current-filename)` returns `#f` when evaluated via `guix environment`,
while `guix build` does fine. Is this expected? Am I doing something wrong?

The usecase is like
https://lists.gnu.org/archive/html/help-guix/2017-04/msg00097.html.

Re: Naming, hacking, and policies

[Tobias Geerinckx-Rice]

Ludo',

Ludovic Courtès wrote:

sirgazil  skribis:
Oh yeah, I'm not suggesting to translate "system names", but 
have both

"system names" and "pretty names", and only the latter would be
internationalized :)


But even that is not really feasible: often there’s no “pretty 
name”,
sometimes there’s one that’s not translatable (“GNU grep”? 
“Scribus”?).


Translation doesn't *mandate* mangling.  The French name for GNU 
grep is presumably just GNU grep, not la greppe GNU.


And if an upstream name isn't ‘pretty’ (which is why I don't like 
this subjective term and prefer DISPLAY-NAME or what even ever), 
we can just omit it & display its NAME everywhere, no?


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: Naming, hacking, and policies

[sirgazil]

El 31/03/19 a las 3:31 p. m., Ludovic Courtès escribió:

sirgazil  skribis:


El 31/03/19 a las 11:37 a. m., Ludovic Courtès escribió:

Hi sirgazil,

sirgazil  skribis:


I don't know exactly what should be done in Guix, though, but I think
having a "system name" and a "pretty name" that is translatable could
help a little bit.


It’s a tricky topic indeed (and not specific to Guix).

There are i18n and accessibility (a11n) issues, I agree.  The problem is
that those “system names” are essentially identifiers, pretty much like
Unix command names.  Sometimes they’re abbreviations of common English
names, sometimes they’re proper names, etc.  So not all of them are
subject to translation.  I think they should really be treated like
identifiers in programming languages or command names.



Oh yeah, I'm not suggesting to translate "system names", but have both
"system names" and "pretty names", and only the latter would be
internationalized :)


But even that is not really feasible: often there’s no “pretty name”,
sometimes there’s one that’s not translatable (“GNU grep”?  “Scribus”?).



Hmm, true.

--
Luis Felipe López Acevedo
http://sirgazil.bitbucket.io/

‘staging’ and GNOME updates

[Ludovic Courtès]

Hi!

Ricardo Wurmus  skribis:

> Ludovic Courtès  writes:
>
>>> I don't think we should release 1.0 until at least
>>>  and  are
>>> fixed.  Trying a new distribution only to find your favourite programs
>>> are crashing would be a _terrible_ first impression.
>>
>> Do we have any leads on this IceCat issue?  I use IceCat daily and never
>> have any problems of this sort, FWIW.
>
> I’ve seen something like this before, but *only* on i686 machines.  I
> never managed to figure out why.

It looks like Mark fixed this in
bc91562939ee002e84c95d13c907482b6d1e9339.  \o/

> One of the GNOME update branches (for 2.28?) has already been merged
> into staging.  There are rumours of crashes, though, so this will
> require testing by more people.

OK, so I guess we should first focus on getting ‘staging’ tested and
merged.

x86_64 substitutes on ci.guix.info cover 60% of the packages right now.
The main issue is that libdrm has one test failure (see
):

--8<---cut here---start->8---
starting phase `check'
[0/1] Running all tests.
 1/16 kms-symbol-checkOK   0.12 s 
 2/16 gen4-3d.batch   OK   0.04 s 
 3/16 gen45-3d.batch  OK   0.04 s 
 4/16 gen5-3d.batch   OK   0.04 s 
 5/16 gen6-3d.batch   OK   0.04 s 
 6/16 gen7-3d.batch   OK   0.04 s 
 7/16 gen7-2d-copy.batch  OK   0.02 s 
 8/16 intel-symbol-check  OK   0.67 s 
 9/16 nouveau-symbol-checkOK   0.32 s 
10/16 radeon-symbol-check OK   0.37 s 
11/16 amdgpu-symbol-check OK   0.52 s 
12/16 threadedSKIP 0.01 s 
13/16 random  TIMEOUT 240.01 s 
14/16 hashOK   0.02 s 
15/16 drmsl   OK   1.23 s 
16/16 drmdevice   SKIP 0.01 s 

Ok:   13
Expected Fail: 0
Fail:  1
Unexpected Pass:   0
Skipped:   2
Timeout:   1


The output from the failed tests:

13/16 random  TIMEOUT 240.01 s 
--8<---cut here---end--->8---

> The other GNOME upgrade that I worked on months ago still awaits a
> rebase onto staging.  I’ll try to get it into good shape to have the
> build farm build it out, so that more people can test it and provide
> fixes where needed.

Perhaps we can first merge ‘staging’ in its current form, then make this
branch the new ‘staging’ and aim for a merge as is (with only fixes
committed there.)  How does that sound?

Ludo’.

Re: Naming, hacking, and policies

[Ludovic Courtès]

sirgazil  skribis:

> El 31/03/19 a las 11:37 a. m., Ludovic Courtès escribió:
>> Hi sirgazil,
>>
>> sirgazil  skribis:
>>
>>> I don't know exactly what should be done in Guix, though, but I think
>>> having a "system name" and a "pretty name" that is translatable could
>>> help a little bit.
>>
>> It’s a tricky topic indeed (and not specific to Guix).
>>
>> There are i18n and accessibility (a11n) issues, I agree.  The problem is
>> that those “system names” are essentially identifiers, pretty much like
>> Unix command names.  Sometimes they’re abbreviations of common English
>> names, sometimes they’re proper names, etc.  So not all of them are
>> subject to translation.  I think they should really be treated like
>> identifiers in programming languages or command names.
>
>
> Oh yeah, I'm not suggesting to translate "system names", but have both
> "system names" and "pretty names", and only the latter would be
> internationalized :)

But even that is not really feasible: often there’s no “pretty name”,
sometimes there’s one that’s not translatable (“GNU grep”?  “Scribus”?).

Ludo’.

Re: Naming, hacking, and policies

[sirgazil]

El 31/03/19 a las 11:37 a. m., Ludovic Courtès escribió:

Hi sirgazil,

sirgazil  skribis:


I don't know exactly what should be done in Guix, though, but I think
having a "system name" and a "pretty name" that is translatable could
help a little bit.


It’s a tricky topic indeed (and not specific to Guix).

There are i18n and accessibility (a11n) issues, I agree.  The problem is
that those “system names” are essentially identifiers, pretty much like
Unix command names.  Sometimes they’re abbreviations of common English
names, sometimes they’re proper names, etc.  So not all of them are
subject to translation.  I think they should really be treated like
identifiers in programming languages or command names.



Oh yeah, I'm not suggesting to translate "system names", but have both 
"system names" and "pretty names", and only the latter would be 
internationalized :)




Now, having synopses and descriptions that are actual text subject to
translation certainly helps.  Maybe we could do better, but I wouldn’t
know how!

Thanks,
Ludo’.



--
Luis Felipe López Acevedo
http://sirgazil.bitbucket.io/

Re: Naming, hacking, and policies

[Ludovic Courtès]

Hi sirgazil,

sirgazil  skribis:

> I don't know exactly what should be done in Guix, though, but I think
> having a "system name" and a "pretty name" that is translatable could
> help a little bit.

It’s a tricky topic indeed (and not specific to Guix).

There are i18n and accessibility (a11n) issues, I agree.  The problem is
that those “system names” are essentially identifiers, pretty much like
Unix command names.  Sometimes they’re abbreviations of common English
names, sometimes they’re proper names, etc.  So not all of them are
subject to translation.  I think they should really be treated like
identifiers in programming languages or command names.

Now, having synopses and descriptions that are actual text subject to
translation certainly helps.  Maybe we could do better, but I wouldn’t
know how!

Thanks,
Ludo’.

Re: Naming, hacking, and policies

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> Ludovic Courtès  writes:
>
>> Andreas Enge  skribis:
>>
>>> On Fri, Mar 29, 2019 at 03:02:00PM +0100, Tobias Geerinckx-Rice wrote:
 I still think this change should be reverted
>>>
>>> I also think so.
>>
>> I’d also be in favor of reverting.
>
> I’m also in favour.  A pure revert would not be enough, though, would
> it?  The new names would need to remain as deprecated names (I know of
> at least one person who installed some of these games under the long
> names).

Indeed.  So I reverted one in commit
e23f2ff1836e982fc2289093aab0994e0c0cf2d2 (this particular rename broke a
unit test.)  As you can see in this commit, it’s mostly a matter of
swapping the package names between the deprecated and the non-deprecated
variant.

Any takers?  Thoughts?

Thanks,
Ludo’.

Re: Software Heritage & Guix

[Ludovic Courtès]

Hi,

mikadoZero  skribis:

> From reading the post I found it unclear what this Software Heritage
> group is and what it's relation to Guix is.

Software Heritage is a non-profit currently hosted by Inria (I work for
Inria, but I’m not affiliated with Software Heritage.)  I know the
people who work on Software Heritage and I’m sympathetic to their goals,
but other than that there’s no connection between them and Guix.  Their
web site explains their mission and goals better than I do.

The archive they maintain is centralized (although it has mirrors).
Long-term archival is something that cannot be left to peer-to-peer
networks: it’s something where you want availability guarantee, whereas
peer-to-peer storage networks usually replicate content that’s popular,
while unpopular content disappears.

Ludo’.

Re: Software Heritage & Guix

[Ludovic Courtès]

swedebugia  skribis:

> Thanks Ludo, I liked the article.
> Maybe this could be spread in more places like slashdot, reddit,
> wikinews etc. to reach a wider audience.

Sure, go ahead.  :-)

It reached LWN, which is nice!  .

> Is it ok if I request for an interview in Wikinews with you Ludo?
> https://en.wikinews.org/wiki/Wikinews:Request_an_interview

I’m not sure what that entails but we could schedule that if you want.

Thanks for your interest,
Ludo’.

Re: Software Heritage & Guix

[Ludovic Courtès]

Hi znavko,

 skribis:

> I've translated into Russian here https://www.opennet.ru/tips/info/3100.shtml

Much appreciated, thank you!

Ludo’.

Re: Guix on a microkernel

[Pjotr Prins]

On Sat, Mar 30, 2019 at 08:05:40PM -0400, mikadoZero wrote:
> * I am curious what others think of microkernels.

Microkernels are of great interest from a security point of view. I
think they will become popular once there is a usable alternative. We
need free software, free software and proper isolation at the OS
level to improve security.

> ### Why Hurd?
> 
> Why the focus on Hurd given other microkernel options?  I ask this
> question out of curiosity and a lack of practical experience with
> microkernels.

Call it an accident of history ;). Being a GNU project we have a stake
in getting the Hurd to a usable level and get people to start using
it for daily work. 

I attended a talk at FOSDEM this year which gave an overview

https://fosdem.org/2019/schedule/event/roadmap_for_the_hurd/attachments/slides/3270/export/events/attachments/roadmap_for_the_hurd/slides/3270/2019_02_01_fosdem_roadmap.pdf

It looks like not a fat lot is needed to make this usable for many
people. Most free software will actually run on Hurd today.

Pj.