Re: [PATCH] profiles: Generate database file for manpages

[Maxim Cournoyer]

Another thought/experiment:

It could be interesting to use find-files with the  #:fail-on-error?
flag set to #t. When trying it:

modified   guix/profiles.scm
@@ -978,7 +978,7 @@ files for the fonts of the @var{manifest} entries."
 (string-drop manpage-path (+ index (string-length "/share/man/")
 
 (define (populate-manpages-collection-dir entries)
-  (let ((manpages (append-map (cut find-files <> #:stat stat) entries)))
+  (let ((manpages (append-map (cut find-files <> #:stat stat #:fail-on-error? #t) entries)))
 (for-each (lambda (manpage)
 (let* ((dest-file (string-append
manpages-collection-dir "/"

It found a broken link for one of the manpages shipped with our gimp package.

find-files: 
/gnu/store/wh2bryjss0pnrv9ss4jbbkwfbj2ql22i-gimp-2.8.18/share/man/man1/gimp-console.1:
 No such file or directory

file 
/gnu/store/wh2bryjss0pnrv9ss4jbbkwfbj2ql22i-gimp-2.8.18/share/man/man1/gimp-console.1
 
/gnu/store/wh2bryjss0pnrv9ss4jbbkwfbj2ql22i-gimp-2.8.18/share/man/man1/gimp-console.1:
 broken symbolic link to gimp-console-2.8.1.gz

Maxim


signature.asc
Description: PGP signature

Re: Add OggVorbis support to moc

[Mark Meyer]

They're not working for me. Specifically ogg Streaming.

Cheers, Mark

On Tue, Apr 4, 2017, at 16:08, Kei Kebreau wrote:
> Mark Meyer  writes:
> 
> > Hi list,
> > please consider the attached patch, it adds OggVorbis support to moc.
> >
> > Cheers, Mark
> >
> > From 9517f2beea0ab4199ad5d558bfcab82a5df713bd Mon Sep 17 00:00:00 2001
> > From: Mark Meyer 
> > Date: Mon, 3 Apr 2017 21:29:25 +0200
> > Subject: [PATCH] 2017-04-03 Mark Meyer 
> >
> > * gnu/packages/music.scm (moc): Add OggVorbis support.
> > ---
> >  gnu/packages/music.scm | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/gnu/packages/music.scm b/gnu/packages/music.scm
> > index 2f70945c6..8f3c96865 100644
> > --- a/gnu/packages/music.scm
> > +++ b/gnu/packages/music.scm
> > @@ -2236,6 +2236,8 @@ with a number of bugfixes and changes to improve IT 
> > playback.")
> > ("libmodplug" ,libmodplug)
> > ("libmpcdec" ,libmpcdec)
> > ("libmad" ,libmad)
> > +   ("libogg" ,libogg)
> > +   ("libvorbis" ,libvorbis)
> > ("ncurses" ,ncurses)
> > ("openssl" ,openssl)
> > ("sasl" ,cyrus-sasl)
> 
> It seems that Ogg Vorbis support already works in this package, probably
> because of ffmpeg support. Do Ogg Vorbis files not work for you without
> this patch?
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)


-- 
  Mark Meyer
  m...@ofosos.org

Re: [PATCH] profiles: Generate database file for manpages

[Maxim Cournoyer]

Hi Ludovic,

l...@gnu.org (Ludovic Courtès) writes:

> Hi Maxim,
>
> Maxim Cournoyer  skribis:
>
>> Unfortunately I cannot reproduce the problem on my side, although you seem 
>> to be
>> right that this is caused by the `string-contains` not matching
>> "/share/man/" in the manpage-path and returning #f...
>>
>> The only reason I'd suspect this could happen was if the `find-files`
>> method (used io list all the files contained under
>> "$manifest-inputs/share/man/") somehow returned bogus paths (I saw that
>> this function has a "fail-on-error?" argument which is disabled by default).
>>
>> To help further troubleshoot this, could you please use the provided
>> patch instead, where I inserted:
>>
>>  
>>  (define (get-manpage-tail-path manpage-path)
>>(let ((index (string-contains manpage-path "/share/man/")))
>> +(unless index
>> +  (error "Manual path doesn't contain \"/share/man/\":"
>> + manpage-path))
>>  (substring manpage-path (+ index (string-length 
>> "/share/man/")
>>  
>>  (define (populate-manpages-collection-dir entries)
>>
>> to print the unexpectedly formed manpage-path.
>
> The problem happens with 
> "/gnu/store/rn3vri602z3jpwqnha0r5nwxi6v0qpnx-texlive-2016/share/man" (no
> trailing slash):
>
> $ ls -l "/gnu/store/rn3vri602z3jpwqnha0r5nwxi6v0qpnx-texlive-2016/share/man"
> lrwxrwxrwx 2 root root 70 Jan  1  1970 
> /gnu/store/rn3vri602z3jpwqnha0r5nwxi6v0qpnx-texlive-2016/share/man -> 
> /gnu/store/8mhqravbd3pv7x1y2qfjlv0bdjchszn0-texlive-bin-2016/share/man
>
> ‘find-files’ uses ‘lstat’ by default, which means it does not follow
> symlinks, and I guess that’s what’s happening here.  Perhaps
> ‘find-files’ needs to be called with #:stat stat to use ‘stat’ instead
> of ‘lstat’?
>
> Thanks,
> Ludo’.

That's a good idea! Could you please try again with the new included
patch? Here are the latest changes:

@@ -954,7 +954,8 @@ files for the fonts of the @var{manifest} entries."
   (define build
 #~(begin
 (use-modules (guix build utils)
- (srfi srfi-1))
+ (srfi srfi-1)
+ (srfi srfi-26))
 
 (define entries
   (filter-map (lambda (directory)
@@ -977,7 +978,7 @@ files for the fonts of the @var{manifest} entries."
 (string-drop manpage-path (+ index (string-length "/share/man/")
 
 (define (populate-manpages-collection-dir entries)
-  (let ((manpages (append-map find-files entries)))
+  (let ((manpages (append-map (cut find-files <> #:stat stat) entries)))
 (for-each (lambda (manpage)
 (let* ((dest-file (string-append
manpages-collection-dir "/"
@@ -1012,7 +1013,8 @@ files for the fonts of the @var{manifest} entries."
 "-C" "man_db.conf"
 
   (gexp->derivation "manual-database" build
-#:modules '((guix build utils))
+#:modules '((guix build utils)
+(srfi srfi-26))
 #:local-build? #t))
 
 (define %default-profile-hooks

I think we're closing in... :)

Maxim

<<< message/external-body; name="~/src/guix/0001-profiles-Generate-database-file-for-manpages.patch"; access-type=local-file: Unrecognized >>>


signature.asc
Description: PGP signature

Re: packages which are broken after core-updates merge

[Ricardo Wurmus]

Ludovic Courtès  writes:

> ng0  skribis:
>
>> icecat is failing, with new profiles, with old profiles. This can be
>> reproduced in a new profile by selecting 'Preferences > Applications'.
>> It should immediately crash.
>
> I have /gnu/store/pk4sbzk3xh7yjj9ls7hkhzgaj0xha7xp-icecat-45.7.0-gnu1
> (x86_64) and I can reproduce the Preferences → Applications crash.
> However, it does not crash immediately upon startup as Ricardo
> experiences.

I use the very same variant of icecat.  (Having unique names is really
useful for debugging!)

I have a large profile with many tabs.  When icecat starts it restores
the tabs and crashes before I can even see anything.  When I move away
my profile and start in “safe mode” the window appears and Icecat
crashes when it tries to render some URL.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Add OggVorbis support to moc

[Kei Kebreau]

Kei Kebreau  writes:

> Mark Meyer  writes:
>
>> Hi list,
>> please consider the attached patch, it adds OggVorbis support to moc.
>>
>> Cheers, Mark
>>
>> From 9517f2beea0ab4199ad5d558bfcab82a5df713bd Mon Sep 17 00:00:00 2001
>> From: Mark Meyer 
>> Date: Mon, 3 Apr 2017 21:29:25 +0200
>> Subject: [PATCH] 2017-04-03 Mark Meyer 
>>
>> * gnu/packages/music.scm (moc): Add OggVorbis support.
>> ---
>>  gnu/packages/music.scm | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/gnu/packages/music.scm b/gnu/packages/music.scm
>> index 2f70945c6..8f3c96865 100644
>> --- a/gnu/packages/music.scm
>> +++ b/gnu/packages/music.scm
>> @@ -2236,6 +2236,8 @@ with a number of bugfixes and changes to improve IT 
>> playback.")
>> ("libmodplug" ,libmodplug)
>> ("libmpcdec" ,libmpcdec)
>> ("libmad" ,libmad)
>> +   ("libogg" ,libogg)
>> +   ("libvorbis" ,libvorbis)
>> ("ncurses" ,ncurses)
>> ("openssl" ,openssl)
>> ("sasl" ,cyrus-sasl)
>
> It seems that Ogg Vorbis support already works in this package, probably
> because of ffmpeg support. Do Ogg Vorbis files not work for you without
> this patch?

Oh, I see the patch has already been applied. I guess we'll see how this
affects things.


signature.asc
Description: PGP signature

Re: packages which are broken after core-updates merge

[Clément Lassieur]

Ricardo Wurmus  writes:

> Clément Lassieur  writes:
>
>>> Clément Lassieur transcribed 0.2K bytes:
 > icecat is failing, with new profiles, with old profiles. This can be
 > reproduced in a new profile by selecting 'Preferences > Applications'.
 > It should immediately crash.

 It doesn't crash when "--with-system-icu" is removed.
>>>
>>> Can you send a patch for this?
>>
>> Sure, but I'm not sure it is the right solution.  It would be preferable
>> to use system libraries when we can.  What the other think?
>
> This usually indicates that upstream forked the library (or that the
> depend on this particular version of the API).  I think it’s better to
> comment the configure flag with a FIXME and have a version of Icecat
> that is usable than a version of Icecat that immediately crashes when
> you start it.
>
> In any case I think it would be good to file a bug report upstream with
> information about the exact version of ICU that we’re building with.

See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26361.

Re: Add OggVorbis support to moc

[Kei Kebreau]

Mark Meyer  writes:

> Hi list,
> please consider the attached patch, it adds OggVorbis support to moc.
>
> Cheers, Mark
>
> From 9517f2beea0ab4199ad5d558bfcab82a5df713bd Mon Sep 17 00:00:00 2001
> From: Mark Meyer 
> Date: Mon, 3 Apr 2017 21:29:25 +0200
> Subject: [PATCH] 2017-04-03 Mark Meyer 
>
> * gnu/packages/music.scm (moc): Add OggVorbis support.
> ---
>  gnu/packages/music.scm | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/gnu/packages/music.scm b/gnu/packages/music.scm
> index 2f70945c6..8f3c96865 100644
> --- a/gnu/packages/music.scm
> +++ b/gnu/packages/music.scm
> @@ -2236,6 +2236,8 @@ with a number of bugfixes and changes to improve IT 
> playback.")
> ("libmodplug" ,libmodplug)
> ("libmpcdec" ,libmpcdec)
> ("libmad" ,libmad)
> +   ("libogg" ,libogg)
> +   ("libvorbis" ,libvorbis)
> ("ncurses" ,ncurses)
> ("openssl" ,openssl)
> ("sasl" ,cyrus-sasl)

It seems that Ogg Vorbis support already works in this package, probably
because of ffmpeg support. Do Ogg Vorbis files not work for you without
this patch?


signature.asc
Description: PGP signature

Re: [PATCH] guix hash: -g hashes a git repository

[Andy Wingo]

On Tue 04 Apr 2017 14:21, l...@gnu.org (Ludovic Courtès) writes:

>> +For example:
>> +@example
>> +$ git clone http://example.org/foo.git
>> +$ guix hash -g foo
>> +@end example
>
> In this case -g is equivalent to -rx.

My main use case is when I am in a git checkout that has build products
or other stuff.  Then I can "guix hash -g .".  Easier than making a temp
dir, clone, hash, then delete.

>> +Or even:
>> +@example
>> +$ guix hash -g http://example.org/foo.git
>> +@end example
>>  @end table
>
> This one is indeed simpler.  However, one typically needs to get the
> commit id in addition to the hash, so it seems that in practice, most of
> the time, we’d still need to do:
>
>   git clone http://…
>   cd foo
>   git log | head -1
>   guix hash -rx .
>
> so we have both the commit id and the content hash.
>
> WDYT?

Could be!  Or "git rev-parse HEAD".  I'll do that.

Andy

Re: Add OggVorbis support to moc

[Tobias Geerinckx-Rice]

Mark,

On 03/04/17 21:33, Mark Meyer wrote:
> Hi list,

Hi!

Patches like this will (or should) get more attention on
guix-patc...@gnu.org. guix-devel is for more general discussion.

> please consider the attached patch, it adds OggVorbis support to moc.

Applied as 6beaa5a02a516c061c2ff86ce4beb43374015194, with some changes
to the commit message. Please take a look.

Also: your patch had ‘2017-04-03 Mark Meyer ’ as the
commit title. Was this intended?

Thanks!

T G-R



signature.asc
Description: OpenPGP digital signature

Re: packages which are broken after core-updates merge

[Clément Lassieur]

> Clément Lassieur  writes:
>
>>> Clément Lassieur transcribed 0.2K bytes:
 > icecat is failing, with new profiles, with old profiles. This can be
 > reproduced in a new profile by selecting 'Preferences > Applications'.
 > It should immediately crash.

 It doesn't crash when "--with-system-icu" is removed.
>>>
>>> Can you send a patch for this?
>>
>> Sure, but I'm not sure it is the right solution.  It would be preferable
>> to use system libraries when we can.  What the other think?
>
> This usually indicates that upstream forked the library (or that the
> depend on this particular version of the API).  I think it’s better to
> comment the configure flag with a FIXME and have a version of Icecat
> that is usable than a version of Icecat that immediately crashes when
> you start it.
>
> In any case I think it would be good to file a bug report upstream with
> information about the exact version of ICU that we’re building with.

Alright, I'll send a patch then.  Thanks for commenting.

Re: packages which are broken after core-updates merge

[Clément Lassieur]

> ng0  skribis:
>
>> icecat is failing, with new profiles, with old profiles. This can be
>> reproduced in a new profile by selecting 'Preferences > Applications'.
>> It should immediately crash.
>
> I have /gnu/store/pk4sbzk3xh7yjj9ls7hkhzgaj0xha7xp-icecat-45.7.0-gnu1
> (x86_64) and I can reproduce the Preferences → Applications crash.
> However, it does not crash immediately upon startup as Ricardo
> experiences.

It also crashes everytime when browsing "about:support".  Immediate
crash depends on the profile I think.

Re: [PATCH] profiles: Generate database file for manpages

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> Unfortunately I cannot reproduce the problem on my side, although you seem to 
> be
> right that this is caused by the `string-contains` not matching
> "/share/man/" in the manpage-path and returning #f...
>
> The only reason I'd suspect this could happen was if the `find-files`
> method (used io list all the files contained under
> "$manifest-inputs/share/man/") somehow returned bogus paths (I saw that
> this function has a "fail-on-error?" argument which is disabled by default).
>
> To help further troubleshoot this, could you please use the provided
> patch instead, where I inserted:
>
>  
>  (define (get-manpage-tail-path manpage-path)
>(let ((index (string-contains manpage-path "/share/man/")))
> +(unless index
> +  (error "Manual path doesn't contain \"/share/man/\":"
> + manpage-path))
>  (substring manpage-path (+ index (string-length 
> "/share/man/")
>  
>  (define (populate-manpages-collection-dir entries)
>
> to print the unexpectedly formed manpage-path.

The problem happens with 
"/gnu/store/rn3vri602z3jpwqnha0r5nwxi6v0qpnx-texlive-2016/share/man" (no
trailing slash):

--8<---cut here---start->8---
$ ls -l "/gnu/store/rn3vri602z3jpwqnha0r5nwxi6v0qpnx-texlive-2016/share/man"
lrwxrwxrwx 2 root root 70 Jan  1  1970 
/gnu/store/rn3vri602z3jpwqnha0r5nwxi6v0qpnx-texlive-2016/share/man -> 
/gnu/store/8mhqravbd3pv7x1y2qfjlv0bdjchszn0-texlive-bin-2016/share/man
--8<---cut here---end--->8---

‘find-files’ uses ‘lstat’ by default, which means it does not follow
symlinks, and I guess that’s what’s happening here.  Perhaps
‘find-files’ needs to be called with #:stat stat to use ‘stat’ instead
of ‘lstat’?

Thanks,
Ludo’.

Re: [PATCH] guix hash: -g hashes a git repository

[Ludovic Courtès]

Hello!

Andy Wingo  skribis:

> * guix/scripts/hash.scm (show-help, %options): Add -g option.
> (guix-hash): Support hashing of Git URLs.
> * doc/guix.texi (Invoking guix hash): Document guix hash --git.

[...]

> +For example:
> +@example
> +$ git clone http://example.org/foo.git
> +$ guix hash -g foo
> +@end example

In this case -g is equivalent to -rx.

> +Or even:
> +@example
> +$ guix hash -g http://example.org/foo.git
> +@end example
>  @end table

This one is indeed simpler.  However, one typically needs to get the
commit id in addition to the hash, so it seems that in practice, most of
the time, we’d still need to do:

  git clone http://…
  cd foo
  git log | head -1
  guix hash -rx .

so we have both the commit id and the content hash.

WDYT?

Thanks,
Ludo’.

Re: packages which are broken after core-updates merge

[Ludovic Courtès]

ng0  skribis:

> icecat is failing, with new profiles, with old profiles. This can be
> reproduced in a new profile by selecting 'Preferences > Applications'.
> It should immediately crash.

I have /gnu/store/pk4sbzk3xh7yjj9ls7hkhzgaj0xha7xp-icecat-45.7.0-gnu1
(x86_64) and I can reproduce the Preferences → Applications crash.
However, it does not crash immediately upon startup as Ricardo
experiences.

Ludo’.

Re: 'guix build' and garbage collection

[Ludovic Courtès]

Hi!

Chris Marusich  skribis:

> Do you know why the intensional model hasn't been deployed in the 11
> years since the thesis was published?  To learn more, I can think of a
> few places to look (Nix email lists, other Nix-related research papers),
> but if you have specific recommendations, it would be helpful!

The intensional model (content-address item) works well if and only if
packages are 100% bit-reproducible, which they are not (yet!).

Also I’m not sure how substitutes could work with this model since one
cannot refer to the build result until it’s available.

My guesses!

Ludo’.

Re: [PATCH] qjackctl

[Ludovic Courtès]

Mark Meyer  skribis:

> From 22b1c2a835c818d6e9d502260ddfa4de11a8a88a Mon Sep 17 00:00:00 2001
> From: Mark Meyer 
> Date: Mon, 3 Apr 2017 19:58:49 +0200
> Subject: [PATCH] 2017-04-03 Mark Meyer 
>
> * gnu/packages/audio.scm (qjackctl): Add new package.

Perfect!  I adjusted the commit log and applied, thanks!

Ludo’.

Re: "guix potluck", a moveable feast

[Ludovic Courtès]

Hey!

Andy Wingo  skribis:

> On Sun 02 Apr 2017 01:05, l...@gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo  skribis:
>>
>>>   (1) Install Guix as a user.  (This needs to be easier.)
>>>   (2) guix channel add potluck https://gitlab.com/potluck/potluck master
>>>   (3) guix channel enable potluck
>>
>> So users would see the union of independent potluck “dishes”, right?
>
> Yes I think so: a union of all potluck "dishes" with the Guix package
> set as well.
>
> Christopher Webber asks about breakage due to version skew between peer
> channels and channels and Guix itself.  I think I would like to just
> ignore this problem for now: if you add channels and things break
> somehow due to an update in Guix or an update in some channel, then the
> workaround is to disable channels until developers fix things.

OK, that sounds reasonable.

>> The sandbox would have transitive access to a lot of modules; I wonder
>> if this might somehow make it easier to escape the sandbox, by
>> increasing the attack surface.  For instance,
>>
>>   (source-module-closure '((guix packages)) #:select? (const #t))
>
> I think the strategy here would be to avoid making a sandbox binding set
> that is "unsafe".  Having source-module-closure in that binding set
> would seem to make it unsafe.

Sorry, I used ‘source-module-closure’ just to show that (system foreign)
is being pulled, and (system foreign) is “sudo”.  :-)

So I think we’d have to make sure the sandbox cannot access (system
foreign) transitively.

>> I think the server should resolve package specifications when the
>> potluck.scm file is submitted, and insert each package in the Guix
>> package graph of the moment.  Does that make sense?  Maybe that’s what
>> you were describing when you talk about rewriting potluck.scm files
>> so?
>
> Yes I think this is a good idea.
>
> Incidentally I am now thinking that all the potluck stuff should be in a
> potluck dir; you run "guix potluck init" and it makes
>
>   potluck/README.md
>   potluck/mypackage.scm
>
> and the .scm files should evaluate to a single package, like:
>
>   (import-packages ...)
>   (package
>...)
>
> The rewrite would create files like:
>
>   gnu/packages/potluck/gitlab-com-wingo-foo-master/mypackage.scm
>   gnu/packages/potluck/gitlab-com-wingo-foo-master/mypackage2.scm
>
> These files would look like:
>
>   (define-module (gnu packages potluck gitlab-com-wingo-foo-master mypackage)
> #:pure
> ;; The sandbox.  We've already verified that the user code works in
> ;; this sandbox when we rewrite the package, so this allows us to
> ;; provide a stable language for sandbox packages
> #:use-module (guix potluck environment)
> ;; The individual module imports, resolved by channel manager.
> #:use-module ((gnu packages guile) #:select (guile))
> ...
> #:export (mypackage))
>
>   (define mypackage
> (package ))
>
> You can compile files from the channel, so guix startup time will be
> only minimally affected.

Sounds good!

Ludo’.

Re: Planning for the next release

[Ludovic Courtès]

Leo Famulari  skribis:

> On Mon, Apr 03, 2017 at 10:26:54AM +0200, Ludovic Courtès wrote:
>> Leo Famulari  skribis:
>> > I just pushed a tzdata update to a new staging branch. Let's build and
>> > merge this branch before the next release.
>> 
>> We can do that, but should it be a blocker?  Anyway, let’s try and we’ll
>> see.
>> 
>> BTW:
>> 
>> --8<---cut here---start->8---
>> $ ./pre-inst-env guix refresh -l -e '(@@ (gnu packages base) tzdata)'
>> Building the following 239 packages would ensure 442 dependent packages are 
>> rebuilt
>> --8<---cut here---end--->8---
>
> It used to be about ~1400 :)

Right, definitely an improvement!

>> I was expecting to see fewer packages depending on this one since
>> 3ffaec136fab017e6cc094287da207cf30f05974.  Perhaps in the ‘staging’
>> branch we should migrate a few more packages to ‘tzdata-2017a’?
>
> The bulk of it comes through libical, so I'm not sure we can get it
> under 300 rebuilds without removing tzdata from libical.
>
> Having said that, I'm not sure if libical even needs a run-time
> reference to tzdata. At least, we didn't notice that it was missing for
> ~1 year:
>
> 

Heh, indeed.  I guess we can address it at a later stage, whenever is
convenient.

Ludo’.

Re: Planning for the next release

[Ricardo Wurmus]

ng0  writes:

> Leo Famulari transcribed 2.2K bytes:
>> On Fri, Mar 31, 2017 at 04:33:24PM +, ng0 wrote:
>> > Ludovic Courtès transcribed 0.6K bytes:
>> > > > On my side, people will and have asked for the intermediate time how/if
>> > > > the http_proxy of Guix works. If someone has been using it with an
>> > > > SOCKS5 proxy successfully, I'd would like to have this added to
>> > > > documentation as well. My own experiment ended up with a shot in the
>> > > > foot where I had to roll back because Guix was now unable to do 
>> > > > anything
>> > > > at all.
>> > > 
>> > > The guix-service in GuixSD now allows you to specify an HTTP proxy quite
>> > > easily, for substitutes and downloads (commit 93d32da9f8).  I haven’t
>> > > tried it but it Should Work Fine.
[…]
> To put it simple, my use case is tor. I thought it would be enough to
> point to the host:port like I do for socks5 settings of applications.

The commit augments the environment in which guix-daemon is running such
that “http_proxy” is set.  AFAIK “http_proxy” only works with HTTP
proxies, not with SOCKS proxies.  You would have to set up an HTTP proxy
that forwards to Tor’s SOCKS proxy, e.g. with privoxy.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: packages which are broken after core-updates merge

[Ricardo Wurmus]

Clément Lassieur  writes:

>> Clément Lassieur transcribed 0.2K bytes:
>>> > icecat is failing, with new profiles, with old profiles. This can be
>>> > reproduced in a new profile by selecting 'Preferences > Applications'.
>>> > It should immediately crash.
>>>
>>> It doesn't crash when "--with-system-icu" is removed.
>>
>> Can you send a patch for this?
>
> Sure, but I'm not sure it is the right solution.  It would be preferable
> to use system libraries when we can.  What the other think?

This usually indicates that upstream forked the library (or that the
depend on this particular version of the API).  I think it’s better to
comment the configure flag with a FIXME and have a version of Icecat
that is usable than a version of Icecat that immediately crashes when
you start it.

In any case I think it would be good to file a bug report upstream with
information about the exact version of ICU that we’re building with.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: packages which are broken after core-updates merge

[Clément Lassieur]

> Clément Lassieur transcribed 0.2K bytes:
>> > icecat is failing, with new profiles, with old profiles. This can be
>> > reproduced in a new profile by selecting 'Preferences > Applications'.
>> > It should immediately crash.
>> 
>> It doesn't crash when "--with-system-icu" is removed.
>
> Can you send a patch for this?

Sure, but I'm not sure it is the right solution.  It would be preferable
to use system libraries when we can.  What the other think?

Re: packages which are broken after core-updates merge

[ng0]

Clément Lassieur transcribed 0.2K bytes:
> > icecat is failing, with new profiles, with old profiles. This can be
> > reproduced in a new profile by selecting 'Preferences > Applications'.
> > It should immediately crash.
> 
> It doesn't crash when "--with-system-icu" is removed.

Can you send a patch for this?