Re: Vanilla Firefox recipe?

[Carlo Zancanaro]

Hey Chris,

On Wed, May 27 2020, Christopher Lemmer Webber wrote:
> However, I wonder if, with a matter of just two patches, this could be
> resolved:
>
>  - Patch out the automatic download of Cisco's h.264 plugin.
>  - Add a warning banner *above* the extensions page, or simply switch it
>to the same one that Icecat already uses.
>
> Is that all that's necessary, then, to get "vanilla Firefox" in Guix?
> It strikes me that with those two changes, the criteria would be met.

We would need to watch out for Mozilla's requirements to use the "Firefox" 
trademark[1]. Of particular note is the section titled "Modified Versions 
Require Prior Written Permission":

  The open source nature of Firefox and other Mozilla software allows you to 
freely download and modify the source code. However, if you make any changes to 
Firefox or other Mozilla software, you may not redistribute that product using 
any Mozilla trademark without Mozilla’s prior written consent and, typically, a 
distribution agreement with Mozilla. For example, you may not distribute a 
modified form of Firefox and continue to call it Firefox.

  Changes requiring Mozilla’s prior written permission include (but are not 
limited to):
   - Changing the default home page or adding bookmarks,
   - Adding, modifying, or deleting source files,
   - Adding, modifying, or deleting content from installer files,
   - File location changes,
   - Adding extensions, add-ons or plugins, or
   - Installing themes other than those available in the most recent stable 
version of Firefox available at Mozilla.org.

  If you wish to distribute a modified version of Firefox or other Mozilla 
software with Mozilla trademarks please contact us with your request at 
trademark-permissi...@mozilla.com.

Carlo

[1]: https://www.mozilla.org/en-US/foundation/trademarks/distribution-policy/

Re: Heads-up: hard reset of the 'staging' branch

[Marius Bakke]

Marius Bakke  writes:

> Marius Bakke  writes:
>
>> I have pushed a 'staging2' branch where I did the following:
>>
>>  1) git rebase -i --rebase-merges 8229ce3116c1f522c7157ab2dcd50dc2d765686a~
>>
>>  2) Moved 8229ce3116c1f522c7157ab2dcd50dc2d765686a after
>> f00270d35a6ca814903a9392caedc29d44959088 (the first merge that includes
>> .guix-authorizations) -- it was "one step down" in Magits interactive
>> rebase menu.
>>
>>  3) "solved" three merge conflicts (actually git rerere remembered the
>> resolutions, and I could have used git rebase --rerere-autoupdate to
>> make the process entirely automatic).
>>
>> I intend to move the current 'staging' branch to 'staging-old', and
>> rename 'staging2' to 'staging' once I'm fully confident in the result
>> and resolution.
>
> Of course I sent this before actually testing the branch!  'git rerere'
> had forgotten a very important merge resolution from
> 354880e7209a2aec0360dfe5b08b1873c084e2dd: the "tzdata-for-tests" package
> needs to be kept on version 2019c during that merge to prevent a
> full rebuild via "python".
>
> I will do a new rebase tomorrow and make sure each of the merges are
> correct.

So the three merges that needed rebasing were:

  f00270d35a6ca814903a9392caedc29d44959088
  1ffd7a7e514072039a1bc92eb1a09b8119b06c91
  34d8640b1a85198fa060a6ddbdbf10ad6e2415ea

During the first, apart from the _actual_ (git style) conflict,
tzdata-for-tests needed manual merging as mentioned earlier.

I solved it by "git checkout f00270d35 -- gnu/packages/base.scm" during
the merge.

For 1ffd7a7e there was another "hidden" (not detected by git) conflict
in gnu/packages/cups.scm, though not as grave (only a leftover
variable).  Solved by "git checkout 1ffd7a7e --
gnu/packages/cups.scm".

34d8640b1 did not have any surprise conflicts.

The new rebased merges are:

  9edb3f66fd807b096b48283debdcddccfea34bad
  aa13c5657d4f8b5dd52beda88a9a8ccc59ebca86
  8a7a5dc7805f4628e60f90af6b2416f951d0c034

They should be identical to the previous merges, with one difference:
the first merge no longer has a conflict in linux.scm because it was
moved to the rebased ddcfc467968d8367e62cb24cbc9e89bb5af0fe6d.

The new 'staging' branch have these rebased merges and is identical to
the previous 'staging' (excluding .git).  The previous branch is
available as 'staging-old' for the time being in case anyone wants to
verify.

In the future I'll be annotating such "hidden" merge conflicts in the
commit message somehow (perhaps using the regular ChangeLog style).  I
hope we don't need to perform branch surgery again, but there are
legitimate cases for making similar merges to different branches.

Another key takeaway is that 'git rerere' does not remember any
"manual" merge resolutions: it only saves resolutions for things that
would introduce the regular git conflict markers.

If you read this far, I'm sorry!  Happy to say the situation is under
control and the staging branch will continue its normal operation
shortly.  :-)


signature.asc
Description: PGP signature

Re: Kernel module configuration service

[Danny Milosavljevic]

Could also have modprobe-config-directory-service and extra KMCS service and
load them at different times in the boot process, I guess.


pgprPG9vf0IBS.pgp
Description: OpenPGP digital signature

Re: Kernel module configuration service

[Danny Milosavljevic]

Hi Brice,

On Fri, 15 May 2020 19:31:51 +
Brice Waegeneire  wrote:

> (1) Generate a config directory for modrope to use
> (2) Load loadable kernel module by extending 'kernel-module-loader-service'
[...]
> ATM I need help with point number 1 in regard to putting in place the
> config directory for modprobe. To do so I need to change
> '%modprobe-wrapper' into a procedure to take the configuration directory 
> as
> an argument, since the directory will now come from '/gnu/store/' 
> instead
> of '/etc/'. The problem is that the wrapper is currently put in place by
> '%linux-bare-metal-service' which is an essential service, so it seems 
> that
> KMCS will have to become one too.

I think that essential services are just services that aren't randomly
restarted or removed by Guix while the system is running.

Also, a user shouldn't need to touch (swap out) essential services.

I envision that mostly other services would extend the KMCS--so it
shouldn't matter that user can't touch the KMCS essential service.

That said, maybe still good to have a field in the  record
that lets the user specify manual kernel module configuration amendments.

The kernel module configuration directory should be there as early as possible
in the boot process since the kernel can invoke modprobe whenever it wants.

Definitely don't wait for shepherd (or even more stuff) to start up.

> service
> most of them are straight forward and don't extend services like
> 'kernel-module-loader-service-type'

> (which itself extend
> 'shepherd-root-service-type').

Oops.

> What are the guidelines to add a service to the essential-services? Can
> KMCS become an essential-service? Any other remarks/idea?

If necessary one can always not do (2)--although it would be nice to do it.
But if it means waiting for shepherd, nope.


pgp6dASgz4KdO.pgp
Description: OpenPGP digital signature

Re: Vanilla Firefox recipe?

[Leo Famulari]

On Tue, May 26, 2020 at 01:27:40PM -0400, Christopher Lemmer Webber wrote:
> So this page explains the problem:
> 
>   
> https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines
> 
> "Problem: Recommends non-free addons and plugins; automatically downloads 
> cisco's binary h.264 codecs"
> 
> I agree the latter is a problem.  The former is kind of maybe a problem,
> but mostly because it isn't clear that it's happening to the user.
> 
> However, I wonder if, with a matter of just two patches, this could be
> resolved:
> 
>  - Patch out the automatic download of Cisco's h.264 plugin.
>  - Add a warning banner *above* the extensions page, or simply switch it
>to the same one that Icecat already uses.
> 
> Is that all that's necessary, then, to get "vanilla Firefox" in Guix?
> It strikes me that with those two changes, the criteria would be met.

I agree, it would be a good addition.


signature.asc
Description: PGP signature

Re: Vanilla Firefox recipe?

[Christopher Lemmer Webber]

(An obvious win from this also being that we will be able to have more
Guix users running, on average, a more up-to-date on security browser
more often.)

Christopher Lemmer Webber writes:

> [moving from help-guix to guix-devel]
>
> On help-guix this exchange occured when discussing trying to install
> Vanilla Firefox... two things struck me:
>
>  - Firefox's source code is itself free, but it doesn't follow the FSDG
>(An assertion was made that Firefox was itself nonfree software,
>but this seems like an inaccurate characterization.  I agree it
>doesn't follow the FSDG, however.)
>  - It is probably possible, with minimal changes, to resolve that.
>
> So this page explains the problem:
>
>   
> https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines
>
> "Problem: Recommends non-free addons and plugins; automatically downloads 
> cisco's binary h.264 codecs"
>
> I agree the latter is a problem.  The former is kind of maybe a problem,
> but mostly because it isn't clear that it's happening to the user.
>
> However, I wonder if, with a matter of just two patches, this could be
> resolved:
>
>  - Patch out the automatic download of Cisco's h.264 plugin.
>  - Add a warning banner *above* the extensions page, or simply switch it
>to the same one that Icecat already uses.
>
> Is that all that's necessary, then, to get "vanilla Firefox" in Guix?
> It strikes me that with those two changes, the criteria would be met.
>
> (Yes, I know that IceCat also provides LibreJS and some other plugins,
> and that's nice to have, but Guix already ships several other browsers
> that do not have those plugins, so this does not seem to be a strict
> impediment and I don't think it should be either.  We could change the
> default Firefox homepage to point at one that recommends installing some
> of these plugins, if that would be helpful.)
>
>  - Chris
>
>
> Christopher Lemmer Webber writes:
>
>> I'm not sure it's really accurate to categorize asking for a vanilla
>> copy of firefox, which might not comply with the FSDG, as nonfree
>> software.  The primary issue with Firefox that makes it qualify as
>> "nonfree" is that the add-ons tool brings you to something that might
>> guide a user towards nonfree software right?  Thus I think this isn't
>> exactly correct framing, since firefox itself isn't nonfree?  There is a
>> difference if I, as a user, install Firefox as free software, and I am
>> aware of the issue with the default extensions kit, and end up
>> installing no nonfree software on my computer, right?
>>
>> Am I missing something?  What makes Firefox itself nonfree (which I
>> think is not quite the same thing as not compliant with the FSDG)?
>>
>>
>> Adonay Felipe Nogueira via writes:
>>
>>> I came late to this issue, but I think this should have been posted on
>>> development mailing list. It's not good if we use the general help list
>>> to foster non-free software like Firefox or those which are third-party
>>> package managers with no default repository explicitly commited to
>>> following the GNU FSDG.
>>>
>>> Furthermore, to ease the sides of both the thread starter and the
>>> community, I'm taking a simplification in that I'm considering the use
>>> of such non-free software for purpose of developing or improving a free
>>> replacement. That means I'm not discussing the merit of whether the
>>> question should or shouldn't have been answered the way it was.
>>>
>>> One must be remind though, that the GNU FSDG isn't only about the
>>> packages distributed (software, documentation, text fonts, etc), but
>>> also about the community, and this is one of the things that keep Debian
>>> out of the list of free system distributions.
>>>
>>> Em 12/05/2020 16:23, Efraim Flashner escreveu:
 On Mon, May 11, 2020 at 10:31:02PM +0200, Guillaume Le Vaillant wrote:
>
> Christopher Lemmer Webber  skribis:
>
>> Anyone have a package definition (or channel) for a recent vanilla
>> firefox?
>>
>> I understand the decision to prefer distributing Icecat instead in Guix
>> proper, but I need a more recent version of things... I suspect others
>> sometimes do too.  I have a feeling at least someone in the community
>> has written such a definition... would you mind sharing?
>>
>> Thanks!
>>  - Chris
>
> Hi,
>
> There is a channel at
> https://forge.monarch-pass.net/warrah/warrah-nonfsdg with a package
> definition for Firefox 74.0.1. I haven't tested it though.

 Other options include using the now official flatpak copy of firefox. If
 you do go that route make sure to use the '--user' flag for flatpak so
 it doesn't segfault while trying to write to /var/lib/flatpak.

Re: Vanilla Firefox recipe?

[Christopher Lemmer Webber]

[moving from help-guix to guix-devel]

On help-guix this exchange occured when discussing trying to install
Vanilla Firefox... two things struck me:

 - Firefox's source code is itself free, but it doesn't follow the FSDG
   (An assertion was made that Firefox was itself nonfree software,
   but this seems like an inaccurate characterization.  I agree it
   doesn't follow the FSDG, however.)
 - It is probably possible, with minimal changes, to resolve that.

So this page explains the problem:

  
https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines

"Problem: Recommends non-free addons and plugins; automatically downloads 
cisco's binary h.264 codecs"

I agree the latter is a problem.  The former is kind of maybe a problem,
but mostly because it isn't clear that it's happening to the user.

However, I wonder if, with a matter of just two patches, this could be
resolved:

 - Patch out the automatic download of Cisco's h.264 plugin.
 - Add a warning banner *above* the extensions page, or simply switch it
   to the same one that Icecat already uses.

Is that all that's necessary, then, to get "vanilla Firefox" in Guix?
It strikes me that with those two changes, the criteria would be met.

(Yes, I know that IceCat also provides LibreJS and some other plugins,
and that's nice to have, but Guix already ships several other browsers
that do not have those plugins, so this does not seem to be a strict
impediment and I don't think it should be either.  We could change the
default Firefox homepage to point at one that recommends installing some
of these plugins, if that would be helpful.)

 - Chris


Christopher Lemmer Webber writes:

> I'm not sure it's really accurate to categorize asking for a vanilla
> copy of firefox, which might not comply with the FSDG, as nonfree
> software.  The primary issue with Firefox that makes it qualify as
> "nonfree" is that the add-ons tool brings you to something that might
> guide a user towards nonfree software right?  Thus I think this isn't
> exactly correct framing, since firefox itself isn't nonfree?  There is a
> difference if I, as a user, install Firefox as free software, and I am
> aware of the issue with the default extensions kit, and end up
> installing no nonfree software on my computer, right?
>
> Am I missing something?  What makes Firefox itself nonfree (which I
> think is not quite the same thing as not compliant with the FSDG)?
>
>
> Adonay Felipe Nogueira via writes:
>
>> I came late to this issue, but I think this should have been posted on
>> development mailing list. It's not good if we use the general help list
>> to foster non-free software like Firefox or those which are third-party
>> package managers with no default repository explicitly commited to
>> following the GNU FSDG.
>>
>> Furthermore, to ease the sides of both the thread starter and the
>> community, I'm taking a simplification in that I'm considering the use
>> of such non-free software for purpose of developing or improving a free
>> replacement. That means I'm not discussing the merit of whether the
>> question should or shouldn't have been answered the way it was.
>>
>> One must be remind though, that the GNU FSDG isn't only about the
>> packages distributed (software, documentation, text fonts, etc), but
>> also about the community, and this is one of the things that keep Debian
>> out of the list of free system distributions.
>>
>> Em 12/05/2020 16:23, Efraim Flashner escreveu:
>>> On Mon, May 11, 2020 at 10:31:02PM +0200, Guillaume Le Vaillant wrote:

 Christopher Lemmer Webber  skribis:

> Anyone have a package definition (or channel) for a recent vanilla
> firefox?
>
> I understand the decision to prefer distributing Icecat instead in Guix
> proper, but I need a more recent version of things... I suspect others
> sometimes do too.  I have a feeling at least someone in the community
> has written such a definition... would you mind sharing?
>
> Thanks!
>  - Chris

 Hi,

 There is a channel at
 https://forge.monarch-pass.net/warrah/warrah-nonfsdg with a package
 definition for Firefox 74.0.1. I haven't tested it though.
>>>
>>> Other options include using the now official flatpak copy of firefox. If
>>> you do go that route make sure to use the '--user' flag for flatpak so
>>> it doesn't segfault while trying to write to /var/lib/flatpak.
>>>

Re: Updating the “pre-push” Git hook

[Leo Famulari]

On Mon, May 25, 2020 at 01:13:16PM -0700, Vagrant Cascadian wrote:
> Wait a minute... you're saying this is something that needs to be
> configured on each committer's machine(s)?

Yes, it was recommended in HACKING and then, after we removed that file,
in the Commit Access section of the manual. We try to remind new
committers to read these files but maybe we forgot for you.

However, the security model does not depend on either it or on a
post-receive server hook. It's simply to prevent mistakes.

There are commits in the repo that are unsigned when they should have
been signed, and even one commit that is signed but that fails the
signature check :/

A simple pre-push hook would have caught that.


signature.asc
Description: PGP signature

Re: [PATCH] Add Tor client only package definition

[Andre Batista]

Hi Ludo,

dom 24 mai 2020 às 22:51:16 (1590371476), l...@gnu.org enviou:
> Hi Andre,
> 
> What difference does it make, for instance in terms of the total size
> returned by “guix size tor-client” vs. “guix size tor”?

Considering only the total size, the difference doesn't appear to be
significant: 90.6 MiB vs 91.0 MiB. However, since most of it is relared
to gcc and glibc, I also thought it would be more accurate to compare
the difference between the binaries. Comparing those, there is a 8.5%
reduction on it's size - from 4120K to 3768K on my i686 machine[1].
On x86_64, it goes from 97.0MiB to 96.7MiB total size or 3840K to
3532K, which equals a reduction of 8.0% on the bin[2].

I did not try to emulate other architectures, but I can do it, if you
think the idea is worth.

> Are there other considerations, such as a reduced attack surface?

Other considerations were: not loading code which is not meant to be
used into memory, reducing the compilation and check time as well as
avoiding running relays by mistake (miunderstanding on ORPort or
copy+pasting old configs or config files found on the web).

AFAIUI, this could also mean a reduced attack surface, but I couldn't
think of a way of exploiting the relay module without relying on a
prior exploit. Maybe if the user is running a onion service or
through the SocksPort. I dont know.

> It looks good to me overall!  Some nitpicking:

I see you've been kind to me. Thank you.

> We’d rather use ‘substitute-keyword-arguments’ to augment
> #:configure-flags without touching the other keyword arguments (there
> are several examples in the source).

I've overlooked the warning on section 14.5.3 of guix manual
regarding Lispers tendency to overuse car, cdr cadr and co.

> We generally avoid concatenating text like this, for the reasons
> explained at:
> 
>   https://guix.gnu.org/manual/en/html_node/Synopses-and-Descriptions.html

And I've also overlooked this section.

> Regarding the format of patches, you can take a look at this:
> 
>   https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html

This I had read, but I thought I could skip some of it since it was
not a new package, just a new flag through inheritance. But I
suppose I was just passing the burden onto others.

I'll send a new patch taking your warnings into account.

---

Notes:

1:
user@local ~$ guix size tor tor-client
store item   totalself
/gnu/store/z4li262il798hbl0l1h1k3a5g7r6bffa-glibc-2.31  37.7
36.0  34.6%
/gnu/store/1527570cy2g7ld4wppmh3skvi27kvm43-gcc-7.5.0-lib   65.0
27.4  26.3%
/gnu/store/4c26h0fvk65ilqhq43gmyjwh9mkiwmwc-tor-0.4.3.5 91.0
13.5  13.0%
/gnu/store/9vrkzx403v1rzmgqiv2z8596b1fljl8h-tor-client-0.4.3.5  90.6
13.1  12.6%
/gnu/store/9p15ivj0lc5sd5ivizn8lnzh781lbbgr-openssl-1.1.1f  71.5 
6.4   6.2%
/gnu/store/m21nvi8k4jqhdfxgra87zdri1xpdi8hy-libevent-2.1.11 67.2 
2.2   2.1%
/gnu/store/izqg5ia1ci2xijfw6l1qmw4sylc4p9x9-bash-static-5.0.16   1.6 
1.6   1.6%
/gnu/store/v1g7f3p4f0851mywrla8qmr9hb8jgfjr-bash-minimal-5.0.16 38.8 
1.1   1.0%
/gnu/store/4zsgsg1x32nmwgm6dr5fbb9akkydkclz-zstd-1.4.4-lib  66.0 
1.0   1.0%
/gnu/store/fwyjnzl9z55d9byzsn8nq8g0vlbxxmgn-xz-5.2.467.0 
0.9   0.9%
/gnu/store/3ai13wmy7d8civi5xpvl9x0bm9qjfszx-libseccomp-2.4.365.6 
0.6   0.6%
/gnu/store/pqyqxd5mbvlb22ifxzp4q2skjfq1p8yj-zlib-1.2.11 65.3 
0.2   0.2%
total: 104.1 MiB
user@local ~$ ls -s 
/gnu/store/4c26h0fvk65ilqhq43gmyjwh9mkiwmwc-tor-0.4.3.5/bin/tor
4120 /gnu/store/4c26h0fvk65ilqhq43gmyjwh9mkiwmwc-tor-0.4.3.5/bin/tor
user@local ~$ ls -s 
/gnu/store/9vrkzx403v1rzmgqiv2z8596b1fljl8h-tor-client-0.4.3.5/bin/tor
3768 /gnu/store/9vrkzx403v1rzmgqiv2z8596b1fljl8h-tor-client-0.4.3.5/bin/tor

2:
store item   totalself
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31  38.4
36.7  33.4%
/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib   71.0
32.6  29.7%
/gnu/store/qjk52ii1gc05s1m89lrwrgnh4k1cl95b-tor-0.4.3.5 97.0
13.2  12.0%
/gnu/store/i5i84nxqrvqpv6gzi71iyjgsagv50543-tor-client-0.4.3.5  96.7
12.9  11.7%
/gnu/store/dkzivzn17qilmqdfpyps62b395wxhshh-openssl-1.1.1f  77.4 
6.4   5.9%
/gnu/store/c7wscymmk379v16invi8m68f6v5c8gsv-libevent-2.1.11 73.3 
2.3   2.1%
/gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16   1.6 
1.6   1.5%
/gnu/store/v04z33qas38iiv5ndasf4cw80kqyyr1r-zstd-1.4.4-lib  72.1 
1.1   1.0%
/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16 39.4 
1.0   0.9%
/gnu/store/r7k859hmcnkazf492fasqvk25jflnfk6-xz-5.2.473.0 
0.9   0.8%
/gnu/store/5gc93y4n3f9p5sivp0i4f7ixqmqz3zpv-libseccomp-2.4.371.9 
0.9   0.8%
/gnu/store/rykm237xkmq7rl1p0nwass01p090p88x-zlib-1.2.11 71.2  

Re: What is guix-package-cache ?

[Edouard Klein]

Hi Tobias,


Tobias Geerinckx-Rice writes:

> Afternoon Edouard,
>
> Edouard Klein 写道：
>> I don't understand why guix feels the need to try to build it.
>
> So Guix isn't trying to build any packages (yet), just complaining that you're
> still using python2-prompt-toolkit-1 somewhere.  I'm inclined to believe it:
>
>> The log says:
>> (repl-version 0 1 1)
>> Generating package cache for
>> '/gnu/store/zdv0j5x5dfwr4b6bh8jc9vp818lvd38g-profile'...
>> (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value
>> (python2-prompt-toolkit-1)) (value #f))
>
> Does ‘find -name \*.scm -exec grep python2-prompt-toolkit-1 {} +’ in your
> channel's directory return anything useful?
>

It does, it turns out that two packages are still using
python2-prompt-toolkit-1. I was certain that I grepped that to make sure
but I obviously messed up somehow.

Thank you very much for your help, and my apologies for the noise.


> Are there any uncommitted changes to your channel(s) that ‘guix pull’ can't 
> see
> yet?
>
>> I grepped for 'guix-package-cache' and tried to read the code in
>> guix/channels.scm, but I don't understand.
>
> It's a simple cache of package metadata from your channel(s) to speed up 
> future
> Guix operations.  I doubt it's related to your problem; it's just what 
> happened
> to fail first.
>
> Kind regards,
>
> T G-R

Re: What is guix-package-cache ?

[Tobias Geerinckx-Rice]

Afternoon Edouard,

Edouard Klein 写道：

I don't understand why guix feels the need to try to build it.


So Guix isn't trying to build any packages (yet), just complaining 
that you're still using python2-prompt-toolkit-1 somewhere.  I'm 
inclined to believe it:



The log says:
(repl-version 0 1 1)
Generating package cache for 
'/gnu/store/zdv0j5x5dfwr4b6bh8jc9vp818lvd38g-profile'...
(exception unbound-variable (value #f) (value "Unbound variable: 
~S") (value (python2-prompt-toolkit-1)) (value #f))


Does ‘find -name \*.scm -exec grep python2-prompt-toolkit-1 {} +’ 
in your channel's directory return anything useful?


Are there any uncommitted changes to your channel(s) that ‘guix 
pull’ can't see yet?



I grepped for 'guix-package-cache' and tried to read the code in
guix/channels.scm, but I don't understand.


It's a simple cache of package metadata from your channel(s) to 
speed up future Guix operations.  I doubt it's related to your 
problem; it's just what happened to fail first.


Kind regards,

T G-R


signature.asc
Description: PGP signature

What is guix-package-cache ?

[Edouard Klein]

Hi all !

I'm working on packaging some software. Because I'm not done submitting
my patches to the official guix, but I still need to use my new packages
I've created a git repo where I push my edits.

I've created a channel to use this git repo instead of the official guix
repo.

When I tried to run git pull, I got:


The following derivation will be built:
   /gnu/store/saxml7kzw0ndy0s76483gwxhsxm27ybh-profile.drv
The following profile hook will be built:
   /gnu/store/ggkmzkjw6bj75kq45k7p9bv33si8k66f-guix-package-cache.drv
building package cache...
/builder for 
`/gnu/store/ggkmzkjw6bj75kq45k7p9bv33si8k66f-guix-package-cache.drv' failed to 
produce output path 
`/gnu/store/ljadsvwvqfq7hv6kxr02d3fihgzi8wr6-guix-package-cache'
build of /gnu/store/ggkmzkjw6bj75kq45k7p9bv33si8k66f-guix-package-cache.drv 
failed
View build log at 
'/var/log/guix/drvs/gg/kmzkjw6bj75kq45k7p9bv33si8k66f-guix-package-cache.drv.bz2'.
cannot build derivation 
`/gnu/store/saxml7kzw0ndy0s76483gwxhsxm27ybh-profile.drv': 1 dependencies 
couldn't be built
guix pull: error: build of 
`/gnu/store/saxml7kzw0ndy0s76483gwxhsxm27ybh-profile.drv' failed


The log says:
(repl-version 0 1 1)
Generating package cache for 
'/gnu/store/zdv0j5x5dfwr4b6bh8jc9vp818lvd38g-profile'...
(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value 
(python2-prompt-toolkit-1)) (value #f))


python2-prompt-toolkit-1 is a package I removed in the last push in my
channel because no other package
uses it. I did not install it, nor anything that depend on it (because
nothing depends on it).

I don't understand why guix feels the need to try to build it.

I grepped for 'guix-package-cache' and tried to read the code in
guix/channels.scm, but I don't understand.

Does anybody have any pointers ?

Cheers,

Edouard.

Re: best practise between git-fetch vs url-fetch?

[zimoun]

Dear all,

On Thu, 14 May 2020 at 18:16, Jack Hill  wrote:

> Heh, I'll take the bait. I also really appreciate how easy we make it for
> people to exercise their software freedom and run modified software. How
> best to make that possible and balance it with other usability constraints
> (e.g. mirror:// urls should be more robust) may vary by package, so I
> agree with Leo that some discretion is needed. However, that's not to say
> that I wouldn't appreciate some guidance as to our default preference when
> there is no package-specific reason to prefer one way over the other.

I second these words. :-)


On Wed, 13 May 2020 at 19:13, Leo Famulari  wrote:

> Do we need a consensus? Sometimes it's enough for the reviewer to 1)
> bite their tongue or 2) fix before pushing. Often it's a matter of taste
> and it is beneficial to not second-guess the patch author too much, to
> not hurt their confidence.

>From my point of view, it should not be a matter of taste.  To me, it
should ideally be uniform per file.  For example, bioconductor.scm
uses mainly 'url-fetch' and emacs-xyz.scm mainly 'git-fetch'.
However, some are mixed which does no appear to me right; for example
bioinformatics.scm.

--8<---cut here---start->8---
for f in $(ls -1 gnu/packages/*.scm);
do
echo $f
grep "\-fetch" $f \
| sed -e 's/^[[:space:]]*//' \
| sort | uniq -c | sort -n
echo ""
done | less
--8<---cut here---end--->8---


> I think we should try to avoid a situation where we have to bootstrap
> Git. We do have git-minimal, which works for now. Libgit2 recently
> started releasing tarballs, so that could be an option, too.

But, is Git bootstrapped anyway?  Somehow, Guix bootstraps Git, isn't it?
Your point is remove 'git' to the implicit dependency graph, right?


> Another point for url-fetch is that Git's transition from SHA1 to SHA256
> identifiers may be easy for us, or it may not be. We don't know yet.

Tempus narrabo. :-)


On Wed, 13 May 2020 at 10:24, Brice Waegeneire  wrote:

> An other argument in recommending the 'git-fetch' method is that it
> facilitate the use of “guix build --with-commit”:

+1 for some packages! :-)
-1 for some other ones; for example the ones coming from big
collection as BioConductor released like a whole.


> It does, it avoid having to discuss it with each new contributor
> and avoid noise in patches about changing the source's method based
> on each developer preference (I'm personally guilty of that).

Especially when there is no committer attached to some specific set of packages.


On Wed, 13 May 2020 at 20:07, Tobias Geerinckx-Rice  wrote:

> That's only tautologically true if we limit ourselves to using raw
> commit hashes instead of the more common (because far more
> practical) named tags.  I obviously don't think we should do that.

Why?  If there is a good motivation.
We could imagine a transition: recommanding and encouraging
'git-fetch' with raw commit for any addition/update.
However, it is not clear that there is a strong value for such transition. :-)


> For the sake of argument¹, though, so is --with-source= released and supported upstream tarball dot tar>.

Well, in my workflow I never used '--with-source' because there is an
extra step that '--with-commit' does not have.  But it is a minor
detail.  The real issue is what Jack described with the autotools (or
any other pre-built X generated files).

For a concrete example, let consider 'htop':

--8<---cut here---start->8---
git clone https://github.com/hishamhm/htop /tmp/htop
git -C /tmp/htop checkout 2.2.0
guix build htop --with-source=/tmp/htop
[...]
running './autogen.sh'
patch-shebang: ./autogen.sh: changing `/bin/sh' to
`/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/sh'
./autogen.sh: line 3: autoreconf: command not found
--8<---cut here---end--->8---

In my scientific workflow, I find easier to do, e.g.,

guix build bamm --with-commit=bamm=X

to test new features or reproduce something based on a paper using one
specific commit.  Well, it is easier to hack on some packages and it
saves time by collectively maintain the burden.


What annoys me is that I cannot predict* for which package it works.
That's why a recommendation per file seems right to me.

*obviously, we could add the method of origin in "guix show"; even it
would help, it is not really the point, IMHO.


> Somehow erasing that hard distinction is the real winning move.

To me, today 'git-fetch' provides more flexibility / hackability than
'url-fetch'.


On Sun, 24 May 2020 at 22:30, Ludovic Courtès  wrote:

> Probably we should aim towards not using pre-built Autotools generated
> files and, by extension, probably not using pre-built tarballs when VCS
> checkouts are available.

This would help to reduce the "hard distinction".  Well, what could be
a working plan?

Re: MIPS support

[Christopher Baines]

Vincent Legoll  writes:

> To Christopher Baines
>> At least the main blocker for me is the lack of substitutes for the
>> things that fail to build with QEMU. So maybe one or a few machines
>> which were able to build those specific things would be sufficient to
>> provide some substitutes.
>
> I still not have tried mips (arm*, powerpc* and even there I still do not have
> gone very far, but only tried cross-compilation which has it own set
> of problems).
>
> Can you elaborate a bit, compilation through qemu should be slow but
> mostly work,
> at least I hope. We should have a look at debian's arches MLs, there
> are a lot of
> efforts made to fix and upstream things, being done there.

I forget if I've replied, but I tried building hello using QEMU, and
this was the failure:

qemu: uncaught target signal 11 (Segmentation fault) - core dumped
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [Makefile:1099: c-family/c-common.o] Error 4
make[2]: *** Waiting for unfinished jobs
config.status: creating Makefile
config.status: creating cc1plugin-config.h
config.status: executing depfiles commands
config.status: executing libtool commands
/gnu/store/48y1i9jxilgvg4n0r0mwsvzgac9yvr20-bootstrap-binaries-0/bin/bash 
../../gcc-7.5.0/gcc/../move-if-change tmp-automata.c insn-automata.c
echo timestamp > s-automata
make[2]: Leaving directory 
'/tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/build/gcc'
make[1]: *** [Makefile:4215: all-gcc] Error 2
make[1]: Leaving directory '/tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/build'
make: *** [Makefile:881: all] Error 2
command "make" "-j" "12" 
"LDFLAGS=-Wl,-rpath=/gnu/store/nlw1v60wfzvf8hccfiyxaa7qq76cpxfh-glibc-bootstrap-0/lib
 -Wl,-dynamic-linker 
-Wl,/gnu/store/nlw1v60wfzvf8hccfiyxaa7qq76cpxfh-glibc-bootstrap-0/lib/ld.so.1" 
failed with status 2
builder for 
`/gnu/store/bfsginlm0wbkwxzy5a39j6kin562ay34-gcc-cross-boot0-7.5.0.drv' failed 
with exit code 1
build of /gnu/store/bfsginlm0wbkwxzy5a39j6kin562ay34-gcc-cross-boot0-7.5.0.drv 
failed


signature.asc
Description: PGP signature

Re: Can we increase the print width/column in daemon backtraces

[Pierre Neidhardt]

Marius Bakke  writes:

> The daemon is a C++ program, so I'm not sure that would work ...

Hahaha, completely forgot :D

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: Can we increase the print width/column in daemon backtraces

[Marius Bakke]

Pierre Neidhardt  writes:

> Marius Bakke  writes:
>
>> You can run it directly from a shell, and/or attach a debugger.
>
> Thanks for the tip.
>
> Any idea how to attach Geiser to it?

The daemon is a C++ program, so I'm not sure that would work ...

If you are trying to increase the trace width within a build expression,
you probably just need to (setenv "COLUMNS" "200") in the builder.


signature.asc
Description: PGP signature

Re: Providing a Guix System images catalog.

[Mathieu Othacehe]

Hey,

>> That's pretty nice!
>
> +1!

Thanks to both of you for your quick feedback!

>> I wonder about how this composes; if I'd want to add say a guix-daemon
>> service to the bare-hurd, how would I do that?
>
> How about leaving the ‘operating-system’ field of  to #f or some
> default value, and then filling it in with the argument passed to ‘guix
> system’?
>
> Or better: at the API level, we’d look for an “image constructor” (or
> “image type”), not an image, where an image constructor is a procedure
> that takes an  and returns an .  In practice,
> you’d wrap that in  with a ‘name’ field so you can still
> look them up by name.

This sounds fair. However, I would still like that:

* The operating-systems are stored elsewhere than in an "examples"
directory.
  
* The "image" command could use a default operating-system that we are
  building with the CI, and making available on Guix website.

What about having a:

--8<---cut here---start->8---
gnu/system/images/hurd
├── hurd-bare-bones-os.scm
└── hurd.scm
--8<---cut here---end--->8---

hurd-bare-bones-os.scm would contain an operating-system with the
"image-type" set to the image contained in hurd.scm.

Conversely, the image in hurd.scm would point to the default
operating-system, that could be the one in hurd-bare-bones-os.scm.

Then, the user could type:

--8<---cut here---start->8---
guix system image hurd-disk-image
guix system disk-image hurd-bare-bones-os.scm
--8<---cut here---end--->8---

and have the same result.

We could also allow:

--8<---cut here---start->8---
guix system image hurd-disk-image --with-os hurd-bare-bones-os.scm
--8<---cut here---end--->8---

to override the default operating-system.

WDYT?

Thanks,

Mathieu