Needed for IceCat-102: rust-1.59 and rust-cbindgen-0.23

[Mark H Weaver]

Hello Guix,

In one week (Sept 20) Mozilla is scheduled to release Firefox 102.3 ESR
with another batch of fixes for security flaws that they will publicize
on the same day, but there will be no corresponding fixes for the 91 ESR
branch.

I hope to update our IceCat package to version 102 by then.

I've identified two dependencies that will be needed, but which are not
yet present on our 'master' branch:

* rust-1.59 (currently on the 'staging' branch)
* rust-cbindgen-0.23

Would anyone be willing to work on adding these?

 Regards,
   Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

Re: [RFC] Use LLVM_BUILD_LLVM_DYLIB instead of BUILD_SHARED_LIBS

[Maxim Cournoyer]

Hi Maxime,

Maxime Devos  writes:

> On 20-04-2022 12:56, Zhu Zihao wrote:
>> We may introduce following problems if we apply this solution.
>>
>> 1. Increase the closure size of LLVM.
>>
>> By default, if LLVM_BUILD_LLVM_DYLIB is set true, LLVM still tries to
>> build the static archive. This may increase the closure size of LLVM.
>> And some package linking with LLVM may use the static archive instead of
>> linking to the dynamic library.
>>
>> My opinion: If we're OK with the bigger closure size, that's not a
>> problem. If not, we may consider disable the static archive generation.
>> For LLVM components, we can use `LLVM_LINK_LLVM_DYLIB` to ask these
>> packages to link with the shared version. For package use `llvm-config`
>> directly or indirectly, we can pass `--link-shared` to it.
>
> IIUC, this causes the static libraries to be built, right?

What the DYLIB build option does is to build a single .so which contains
all of the LLVM libraries instead of having a bunch of differently named
.so around.

It's much simpler to use, and the recommended approach for a shared
library LLVM.

Maxim

Re: Request: build package with source tarball

[Maxime Devos]

On 12-09-2022 03:04, Ryan Prior wrote:
Hi there! Lately I've been testing distribution tarballs with a workflow 
like this:


 1. update some software in my source directory
 2. create a distribution tarball
 3. untar to a directory like /tmp/mypkg-src
 4. run: |guix build --with-source=mypkg=/tmp/mypkg-src|​


It would be nice to skip step 3 there and just run: |guix build 
--with-source=mypkg.tar.gz|​
Guix should then untar and use the result as the source directory for 
the build.


I believe you can do that already -- "guix build" accepts not only 
directories, but also regular files.


For example, the following builds the 'hello' package, but with the 
source code of 'sed' instead of 'hello' (doesn't make much sense, but 
just an example):


$ guix build hello "--with-source=hello=$(guix build --source sed)"

(no need to unpack tarballs!)


To soup the process up even further, allow |--with-source|​ to take a 
URL of a tarball, in which case Guix fetches and untars.


That is already supported:

$ guix build hello "--with-source=hello=file://$(guix build --source sed)"
(succeeds)

$ guix build hello "--with-source=hello=http://localhost/hello.tar.gz;
(network errors, because I don't actually have a tarball there.)

Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: 04/07: guix: Add compression module.

[Mathieu Othacehe]

Hey Ludo,

> While I agree this should be factorize, I wonder if this should be
> promoted to (guix compression).  The module name intuitively is a better
> fit for the compression-related things currently in (guix utils).
>
> Not sure, maybe (gnu compression) would make more sense?

Thanks for noticing that. I moved this module to (gnu compression),
checked that make as-derivation is working and updated the wip-image
branch accordingly.

Mathieu