Re: packaging Typst
My current not-yet-working work-in-progress if anyone is interested in contributing. https://codeberg.org/alxsim/local-channel/src/branch/main/typst.scm Alexis On 02/11/2023 13:21, Steve George wrote: Hi Alexis, I've been doing some Rust packaging recently, so maybe this will help you to get started. Here's how I would approach it. Explore the software The first thing I did was explore whether Typst builds in a current Guix environment. If we don't have the right version of Rust, for example, there's little point continuing: - clone it into an appropriate place - start a shell: $ guix shell --container --network rust rust-cargo coreutils openssl nss-certs gcc-toolchain We need 'openssl' and 'nss-certs' so that cargo will work. - build it: [env]$ env CC=gcc cargo build Kept failing on ring v0.17.5 which is looking for 'cc'. It builds with 296 crates, so we might have our hands full here! Eventually outputs a /target/debug/typst command which seems to work. Import using Guix import = Normally, we'd be able to use the `crates` importer. But, the Typst crates are just place-holders with no details. AFAIK the importer only works with crates-io, we can't feed it Cargo.toml file directly. We'll need to manually create a package and check for any dependencies. Manually create a top-level package To manually create the package we have to go through the projects Cargo.toml. - create an intial typst.scm file in some project directory. - create a minimal typst package by looking in Cargo.lock at 'typst' - for each dependency look at what the Cargo.lock used to build it - check whether we have it in Guix - in some cases we will have the crate, but not the right version Import the dependencies = The first crate that I found which we don't have in the Guix archive is 'comemo' [0]. We can import this with: $ guix shell --development guix --container --nesting --network nss-certs [env]$ guix import crate --recursive comemo@0.3.0 > comemo-import.scm Move these package definitions into your main `typst.scm` file. Check them to add any missing development dependencies. The first one in the dependency stack is `rust-comemo-0.3` which we reference at the bottom of the file. We try and build it as the importer has pulled it in: $ guix shell --development guix --container --nesting [env]$ guix build --load-path=./ --file=typst.scm The next one `rust-comemo-macros` which has been set to `skip-build: #t`, we'll try building it that way initially: - add rust-comemo-macros-0.3 to the bottom of the typst.scm file - comment out the rust-comemo-0.3 line - try and build with: guix build --load-path=./ --file=typst.scm - If it builds successfully, change the `skip-build: #t` part of the definition to be #f. - error[E0433]: failed to resolve: use of undeclared crate or module `comemo` - tried adding comemo as a dependency which didn't work - set it to #:tests? #f - for now There's some more things that have to be done to 'contribute' these packages, but for now I would move onto the next dependency. And that's all there is to this part - finding the dependencies and importing them. Building a dependent package that's not a crate === The cargo-build-system expects to build everything from Crates AFAIK. I believe it will take some messing around with the phases to add the typst-lib which seems to be a dependency. It looks like librsvg (in gnome.scm) does a lot of messing with phases, and greetd (in admin.scm) does some as well - these might be good examples to look at. Hopefully this is enough to get you started! Steve [0] https://crates.io/crates/comemo
Re: mesa@23.1.4: missing symbols
Hi Sergio, On Fri, Nov 03, 2023 at 06:05 PM, Sergio Pastor Pérez wrote: > Hi. > > I've noticed that the `mesa' package we provide is missing some > symbols that according to the OpenGL specification should be present on > the `libGL.so.1` library. > I'll put the punchline up top with a few more details below. But the symbol you want is in the libglvnd package: --8<---cut here---start->8--- ❯ nm -gD $(guix build libglvnd)/lib/libGL.so | grep glBindTextureUnit 0004cb60 T glBindTextureUnit 0004cb80 T glBindTextureUnitParameterEXT --8<---cut here---end--->8--- > The following commands demonstrate the issue: > > $ guix build mesa > /gnu/store/ds15k8bzqf1m861w17hshd8i54pffig9-mesa-23.1.4-bin > /gnu/store/hxvp1sp897rnnpbpb0xk887m4822gf77-mesa-23.1.4 > > $ nm -gD > /gnu/store/hxvp1sp897rnnpbpb0xk887m4822gf77-mesa-23.1.4/lib/libGL.so.1 | grep > glBindTextureUnit > > $ glxinfo | grep "OpenGL version" > OpenGL version string: 4.6 (Compatibility Profile) Mesa 23.1.4 > > Indeed, I found this very puzzling as you did. I looked for other symbols defined in the same Mesa headers and it was hit or miss (mostly miss). > As you can see the grep does not match any symbol. In contrast, if we do > the same under an Ubuntu installation, we can see the following output: > > $ nm -gD /usr/lib/x86_64-linux-gnu/libGL.so.1 | grep glBindTextureUnit > 00046b60 T glBindTextureUnit > 00046b80 T glBindTextureUnitParameterEXT > > $ glxinfo | grep "OpenGL version" > OpenGL version string: 4.6 (Compatibility Profile) Mesa > 23.0.4-0ubuntu1~22.04.1 > I have a laptop with Arch on it and I saw the same thing you did on Unbuntu. However, I decided to double check where libGL comes from and it is owned not by the mesa package there but libglvnd! And that's how I found libGL also in our libglvnd package with the symbol you were looking for. Unfortunately 'guix locate' didn't help me find other libGL in this case (I tried that first) since I don't have libglvnd installed in any profile. But a future upgrade or remote database of files in all our packages will make this simpler. > > This symbol is also present on the `libGL.so.1` provided by the > proprietary Nvidia driver: > > $ guix build nvidia-driver > /gnu/store/8xhdq3rf9k80n6vz5cwi7z1dg5wjq002-nvidia-driver-515.76 > > $ nm -gD > /gnu/store/8xhdq3rf9k80n6vz5cwi7z1dg5wjq002-nvidia-driver-515.76/lib/libGL.so.1 > | grep glBindTextureUnit > 000476c0 T glBindTextureUnit > 00047700 T glBindTextureUnitParameterEXT > > $ glxinfo | grep "OpenGL version" > OpenGL version string: 4.5 (Compatibility Profile) Mesa 23.1.4 > Proprietary stuff aside, this comes back to a question raised before for Guix that we haven't tackled, and that's libglvnd and loading other gl drivers (yes, could be proprietary, but also more generally on a foreign distro). Building mesa with libglvnd support is easy enough, but the proper way to set this up to work well on Guix and foreign systems I'm not so sure. It has been a while since I looked at it but happy for someone to bring this up again or propose what we should do to make it all work seamlessly. That's what libglvnd is for after all, to dispatch gl calls to the right driver. (I think the idea is that mesa is a provider of an implementation and the more general top level for these symbols is elsewhere, libglvnd which could dispatch it to mesa?) > I've noticed the problem because I'm packaging a rust up that I wanted to > contribute as an example on how to build applications that use meson to > build rust packages. This app uses `rust-minidl' to load `libGL.so.1` at > runtime. The app tries to use the `glBindTextureUnit` symbol and panics. > > Does anyone know why this symbol could be missing? Could we fix the > `mesa' package? I would like users of the open source drivers to be able > to run the package. > > Thanks, > Sergio. So the first thing is to use libglvnd in your packaging, which will get you the symbol you need. Whether more is needed for this to work properly (mesa input also or something else) I don't know. And if other packages in Guix actually need libglvnd (and mesa) to work I also don't know but I would guess comes up in a bug report if it does happen. Hope that helps! And I'm glad it wasn't some huge oversight in how we build mesa (as far as I can tell) which left me scratching my head at first. John
Re: Meet Guix at Capitole du Libre in Toulouse, nov. 18-19
On Fri, Nov 03, 2023 at 01:39 PM, Ricardo Wurmus wrote:
> Luis Felipe writes:
>
>> El 26/10/23 a las 14:03, Luis Felipe escribió:
>>> El 25/10/23 a las 21:17, Julien Lepiller escribió:
The print service I usually use has a lot of options for flyers,
{10,15,20,30}*{10,15,20,30}, 12*12, 21*29.7 and 30*40 cm. I think
15*20 would be best.
Visit cards would be 3.5*7.5, 5.5*8.5 or 5*9 cm
>>> Thanks, Julien, I'll hopefully have something ready for next
>>> week. I'll let you all know.
>>
>> Here's a visit card in the same style of the kakemono:
>>
>>
>>
>> The source is in
Re: August/November update on qa.guix.gnu.org and related things
On 2023-11-02 16:38:29 +, Suhail wrote: > [..] > -- > Suhail > > This email is not an offer capable of acceptance, does not evidence an > intention to enter into an agreement, has no operative effect until a > definitive agreement is signed in writing by both parties, and that no > party should act in reliance on the email or any representations of the > sender until a definitive agreement is signed in writing by both > parties. I am unsure what is the takeaway from this paragraph. If you, for example, offer do implement something, should people wait for written agreement before being able to assume you will do so? So anything you say here should not be relied upon? > > This email may contain information that is privileged, confidential > and/or exempt from disclosure. No waiver whatsoever is intended by > sending this e-mail which is intended only for the named recipient(s). > Unauthorized use, dissemination or copying is prohibited. If you > receive this email in error, please notify the sender and destroy all > copies of this email. > > I would suggest not sending a privileged, confidential and/or exempt from disclosure information to a public mailing list. Also, I am not sure you cannot prohibit me from distributing the information once I receive it, since I did not sign any NDA or similar document. T. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: packaging Typst
Hi Alexis,
I've been doing some Rust packaging recently, so maybe this will help you to
get started. Here's how I would approach it.
Explore the software
The first thing I did was explore whether Typst builds in a current Guix
environment. If we don't have the right version of Rust, for example, there's
little point continuing:
- clone it into an appropriate place
- start a shell:
$ guix shell --container --network rust rust-cargo coreutils openssl
nss-certs gcc-toolchain
We need 'openssl' and 'nss-certs' so that cargo will work.
- build it:
[env]$ env CC=gcc cargo build
Kept failing on ring v0.17.5 which is looking for 'cc'. It builds with 296
crates, so we might have our hands full here! Eventually outputs a
/target/debug/typst command which seems to work.
Import using Guix import
=
Normally, we'd be able to use the `crates` importer. But, the Typst crates are
just place-holders with no details.
AFAIK the importer only works with crates-io, we can't feed it Cargo.toml file
directly. We'll need to manually create a package and check for any
dependencies.
Manually create a top-level package
To manually create the package we have to go through the projects Cargo.toml.
- create an intial typst.scm file in some project directory.
- create a minimal typst package by looking in Cargo.lock at 'typst'
- for each dependency look at what the Cargo.lock used to build it - check
whether we have it in Guix
- in some cases we will have the crate, but not the right version
Import the dependencies
=
The first crate that I found which we don't have in the Guix archive is
'comemo' [0]. We can import this with:
$ guix shell --development guix --container --nesting --network nss-certs
[env]$ guix import crate --recursive comemo@0.3.0 > comemo-import.scm
Move these package definitions into your main `typst.scm` file. Check them to
add any missing development dependencies.
The first one in the dependency stack is `rust-comemo-0.3` which we reference
at the bottom of the file. We try and build it as the importer has pulled it in:
$ guix shell --development guix --container --nesting
[env]$ guix build --load-path=./ --file=typst.scm
The next one `rust-comemo-macros` which has been set to `skip-build: #t`, we'll
try building it that way initially:
- add rust-comemo-macros-0.3 to the bottom of the typst.scm file
- comment out the rust-comemo-0.3 line
- try and build with: guix build --load-path=./ --file=typst.scm
- If it builds successfully, change the `skip-build: #t` part of the
definition to be #f.
- error[E0433]: failed to resolve: use of undeclared crate or module
`comemo`
- tried adding comemo as a dependency which didn't work
- set it to #:tests? #f - for now
There's some more things that have to be done to 'contribute' these packages,
but for now I would move onto the next dependency. And that's all there is to
this part - finding the dependencies and importing them.
Building a dependent package that's not a crate
===
The cargo-build-system expects to build everything from Crates AFAIK. I believe
it will take some messing around with the phases to add the typst-lib which
seems to be a dependency. It looks like librsvg (in gnome.scm) does a lot of
messing with phases, and greetd (in admin.scm) does some as well - these might
be good examples to look at.
Hopefully this is enough to get you started!
Steve
[0] https://crates.io/crates/comemo
(define-module (typst)
#:use-module ((guix licenses) #:prefix license:)
#:use-module (guix packages)
#:use-module (guix gexp)
#:use-module (guix download)
#:use-module (guix git-download)
#:use-module (guix utils)
#:use-module (guix build-system gnu)
#:use-module (guix build-system cargo)
#:use-module (gnu packages crates-io))
;; guix shell --development guix --container --nesting
;; guix build --load-path=./ --file=typst.scm
; librsvg in gnome.scm mixes build systems
; greetd in admin.scm does some minor changes
(define-public rust-comemo-0.3
(package
(name "rust-comemo")
(version "0.3.0")
(source
(origin
(method url-fetch)
(uri (crate-uri "comemo" version))
(file-name (string-append name "-" version ".tar.gz"))
(sha256
(base32 "14ng6gqklsy8m9wn6radragn8pazsmn5759mywxb1ddf8bqrg818"
(build-system cargo-build-system)
(arguments
`(#:cargo-inputs (("rust-comemo-macros" ,rust-comemo-macros-0.3)
("rust-siphasher" ,rust-siphasher-0.3
(home-page "https://github.com/typst/comemo;)
(synopsis "Incremental computation through constrained memoization.")
(description "Incremental computation through constrained memoization.")
(license (list license:expat
Re: RFI response: Strengthening the Free Software Supply Chain via Guix and GNUnet
Hi, Maxim. This has been an interesting read. I would like to encourage you to keep us updated. Thanks for sharing! Sergio. Maxim Cournoyer writes: > Hello, > > Just for your info, I'm relaying the response I've sent for > consideration to the US government [0] in reply to their RFI (Request > For Information) [1]. It's about adding support for GNUnet for > sharing Guix substitutes. > > I had no prior experience authoring these so it is probably written in a > naive style :-). Reading the other comments, it's interesting to note > how the other submissions cover topics all over the places. It seems a > common theme is 'rewrite the world in Rust' :-). > > [0] https://www.regulations.gov/comment/ONCD-2023-0002-0033 > [1] https://www.regulations.gov/document/ONCD-2023-0002-0001 > > -- > Thanks, > Maxim
mesa@23.1.4: missing symbols
Hi. I've noticed that the `mesa' package we provide is missing some symbols that according to the OpenGL specification should be present on the `libGL.so.1` library. The following commands demonstrate the issue: --8<---cut here---start->8--- $ guix build mesa /gnu/store/ds15k8bzqf1m861w17hshd8i54pffig9-mesa-23.1.4-bin /gnu/store/hxvp1sp897rnnpbpb0xk887m4822gf77-mesa-23.1.4 $ nm -gD /gnu/store/hxvp1sp897rnnpbpb0xk887m4822gf77-mesa-23.1.4/lib/libGL.so.1 | grep glBindTextureUnit $ glxinfo | grep "OpenGL version" OpenGL version string: 4.6 (Compatibility Profile) Mesa 23.1.4 --8<---cut here---end--->8--- As you can see the grep does not match any symbol. In contrast, if we do the same under an Ubuntu installation, we can see the following output: --8<---cut here---start->8--- $ nm -gD /usr/lib/x86_64-linux-gnu/libGL.so.1 | grep glBindTextureUnit 00046b60 T glBindTextureUnit 00046b80 T glBindTextureUnitParameterEXT $ glxinfo | grep "OpenGL version" OpenGL version string: 4.6 (Compatibility Profile) Mesa 23.0.4-0ubuntu1~22.04.1 --8<---cut here---end--->8--- This symbol is also present on the `libGL.so.1` provided by the proprietary Nvidia driver: --8<---cut here---start->8--- $ guix build nvidia-driver /gnu/store/8xhdq3rf9k80n6vz5cwi7z1dg5wjq002-nvidia-driver-515.76 $ nm -gD /gnu/store/8xhdq3rf9k80n6vz5cwi7z1dg5wjq002-nvidia-driver-515.76/lib/libGL.so.1 | grep glBindTextureUnit 000476c0 T glBindTextureUnit 00047700 T glBindTextureUnitParameterEXT $ glxinfo | grep "OpenGL version" OpenGL version string: 4.5 (Compatibility Profile) Mesa 23.1.4 --8<---cut here---end--->8--- I've noticed the problem because I'm packaging a rust up that I wanted to contribute as an example on how to build applications that use meson to build rust packages. This app uses `rust-minidl' to load `libGL.so.1` at runtime. The app tries to use the `glBindTextureUnit` symbol and panics. Does anyone know why this symbol could be missing? Could we fix the `mesa' package? I would like users of the open source drivers to be able to run the package. Thanks, Sergio.
Re: packaging Typst?
Hi, Alexis. `typst` seems to use a structure that relies on multiple smaller crates. There has been some discussions over the IRC on how this could be packaged using the current cargo build system. The discussion where I participated revolved around `pathfinder` (https://github.com/servo/pathfinder). Unfortunately there has not been any consensus on what could be done to package this kind of structure. I'm hoping that someone has some ideas on how to approach the issue. Thanks. Sergio. Alexis Simon writes: > Hi, > > Is anyone looking into packaging Typst (https://github.com/typst/typst)? > > This is a very promising Latex alternative. > > If no one is doing that I could try to investigate packaging it but I > would need some help on where to start. > This is a rust app but not available on crates.io. > > Thanks! > Alexis
Re: August/November update on qa.guix.gnu.org and related things
"Tomas Volf" <~@wolfsden.cz> writes: > On 2023-11-02 16:38:29 +, Suhail wrote: >> [..] >> -- >> Suhail >> >> This email is not an offer capable of acceptance, does not evidence an >> intention to enter into an agreement, has no operative effect until a >> definitive agreement is signed in writing by both parties, and that no >> party should act in reliance on the email or any representations of the >> sender until a definitive agreement is signed in writing by both >> parties. > > I am unsure what is the takeaway from this paragraph. I am not a lawyer, so take my interpretation with sufficient grains of salt. To me, the takeaway is that a message with that signature does not constitute a legally binding contract and thus limits liability. > I would suggest not sending a privileged, confidential and/or exempt > from disclosure information to a public mailing list. You're correct. Thank you for catching that. I've gotten rid of the offending clause. -- Suhail This email is not an offer capable of acceptance, does not evidence an intention to enter into an agreement, has no operative effect until a definitive agreement is signed in writing by both parties, and that no party should act in reliance on the email or any representations of the sender until a definitive agreement is signed in writing by both parties.
G-expressions and chroot environment? (was Re: branch master updated: gnu: Add passff.)
Hi,
On Sat, 28 Oct 2023 at 17:05, Clément Lassieur wrote:
>> ./pre-inst-env guix show passff-host
>> name: passff-host
>> version: 1.2.3
>> outputs:
>> + out: everything
>> systems: x86_64-linux mips64el-linux aarch64-linux powerpc64le-linux
>> riscv64-linux
>> + i686-linux armhf-linux i586-gnu powerpc-linux
>> dependencies:
>
> I imagine it's a bug in `guix show`?
It is not a bug of ’guix show’ because ’guix show’ accesses to the
fields of the package record. And Clément’s patch is an “abuse” of the
G-expressions machinery. :-)
> As doc says:
>
>• Gexps carry information about the packages or derivations they
> refer to, and these dependencies are automatically added as inputs
> to the build processes that use them.
Well, this is correct from my understanding. ;-)
However, there is still something that I am missing. The derivations
tracks all and that’s expected; thanks G-expression machinery. :-)
However, I miss how the builder works with the chrooted environment if
nothing is passed to it.
The derivation reads,
--8<---cut here---start->8---
Derive
([("out","/gnu/store/0amanwyzx3jylyw7bz5nmszpybxll8ww-passff-host-1.2.3","","")]
,[("/gnu/store/070vbkzbs0dn6w9mhz0xw8fi5hfp92rg-make-4.3.drv",["out"])
,("/gnu/store/2i4781y3mmnm2jlx3awa4mwbqam2ar80-python-3.10.7.drv",["out"])
,("/gnu/store/ax7wdlbxhcz7w8nfyrxkb1pqai80niw6-sed-4.8.drv",["out"])
,("/gnu/store/gb247cil5nlnx175dhqmgg67q7ng7n2h-which-2.21.drv",["out"])
,("/gnu/store/ghwl0z5ci5sssbrzixxji8l0x3j9i3dv-bash-minimal-5.1.16.drv",["out"])
,("/gnu/store/mqmnsly3nm0a7hj46apf2hfm7j8wk56h-module-import-compiled.drv",["out"])
,("/gnu/store/raay3plnbzadwqc0yv8yw8pjr929pkqd-coreutils-9.1.drv",["out"])
,("/gnu/store/rnphhzpwkz82zf1il1cg52041myvp3d4-password-store-1.7.4.drv",["out"])
,("/gnu/store/y6871hl8lklcslvw57wj4bnyysxlv2np-passff-host-1.2.3-checkout.drv",["out"])
,("/gnu/store/y9l0jnyxssx1glbyg3cav78js2fm7j50-grep-3.8.drv",["out"])
,("/gnu/store/zraigp7miin3vzr5dcbr4i9rvds0i07r-guile-3.0.9.drv",["out"])]
,["/gnu/store/8nam67byqnpvbfn4anpgg5pb2qrqhs3v-passff-host-1.2.3-builder","/gnu/store/pj751v3199vmv6i6sf0szp185ryzcfdg-module-import"]
,"x86_64-linux","/gnu/store/g8p09w6r78hhkl2rv1747pcp9zbk6fxv-guile-3.0.9/bin/guile",["--no-auto-compile","-L","/gnu/store/pj751v3199vmv6i6sf0szp185ryzcfdg-module-import","-C","/gnu/store/2gbsk55kwag577skxwsxrfy3l4cl03xh-module-import-compiled","/gnu/store/8nam67byqnpvbfn4anpgg5pb2qrqhs3v-passff-host-1.2.3-builder"]
,[("out","/gnu/store/0amanwyzx3jylyw7bz5nmszpybxll8ww-passff-host-1.2.3")])
--8<---cut here---end--->8---
However the builder reads,
--8<---cut here---start->8---
(begin
(define %build-inputs
(quote
(("source" .
"/gnu/store/fjnkcv14qb61623lm16kq1mgb4bsxivl-passff-host-1.2.3-checkout"
(define %outputs
(list
(cons "out"
((@
(guile)
getenv)
"out"
(define %output
(assoc-ref %outputs "out"))
(begin
(use-modules
(guix build utils))
(setenv "PATH"
(string-join
(list
"/gnu/store/yr39rh6wihd1wv6gzf7w4w687dwzf3vb-coreutils-9.1/bin"
"/gnu/store/ixr7c3jadiqg640b8pz3njqhhm5zzmvj-grep-3.8/bin"
"/gnu/store/sj794a2709pxsi4mgvi619qdpi1g32aa-password-store-1.7.4/bin"
"/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/bin"
"/gnu/store/fyy3wkjkix16sb1ginqw2kbji74cwl2b-sed-4.8/bin"
"/gnu/store/6vxk0i5j9w8mik4l6gx3cbw33f9x4l24-which-2.21/bin")
":"))
(copy-recursively
"/gnu/store/fjnkcv14qb61623lm16kq1mgb4bsxivl-passff-host-1.2.3-checkout" ".")
(substitute* "src/install_host_app.sh"
(("#!/usr/bin/env sh")
"/gnu/store/9vw5slrffp27rzy2i2plnw7xfqjyk7m4-bash-minimal-5.1.16/bin/sh")
(("(TARGET_DIR_FIREFOX=).*" all var)
(string-append var
((@
(guile)
getenv)
"out")
"/lib/icecat/native-messaging-hosts")))
(invoke "/gnu/store/vq4g8390wbz2434m678v010mkpnkjb2w-make-4.3/bin/make"
(string-append "VERSION=" "1.2.3")
"install-unix")))
--8<---cut here---end--->8---
and I would have expect that it fails because of the isolated
environment.
How is it possible that the builder script is able to run that?
For another example using the gnu-build system.
--8<---cut here---start->8---
(define-module (appendix)
#:use-module (guix packages)
#:use-module (gnu packages base)
#:use-module (guix utils)
#:use-module (guix gexp)
#:use-module (gnu packages emacs))
(define-public bye
(package
(inherit hello)
(name "bye")
(arguments
(list
#:phases
#~(modify-phases %standard-phases
Re: Meet Guix at Capitole du Libre in Toulouse, nov. 18-19
El 3/11/23 a las 12:39, Ricardo Wurmus escribió:
Luis Felipe writes:
El 26/10/23 a las 14:03, Luis Felipe escribió:
El 25/10/23 a las 21:17, Julien Lepiller escribió:
The print service I usually use has a lot of options for flyers,
{10,15,20,30}*{10,15,20,30}, 12*12, 21*29.7 and 30*40 cm. I think
15*20 would be best.
Visit cards would be 3.5*7.5, 5.5*8.5 or 5*9 cm
Thanks, Julien, I'll hopefully have something ready for next
week. I'll let you all know.
Here's a visit card in the same style of the kakemono:
https://luis-felipe.gitlab.io/downloads/pdf/gnu-guix-visit-card-A01-EN-90x50mm.pdf
The source is in https://codeberg.org/luis-felipe/guix-graphics/
(promotional/cards).
Wonderful work, Luis Felipe! I’d love to have some of these for future
presentations or conferences.
Thanks, Ricardo. Glad you like it :)
OpenPGP_0x0AB0D067012F08C3.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: Meet Guix at Capitole du Libre in Toulouse, nov. 18-19
Hello again,
El 2/11/23 a las 19:48, Luis Felipe escribió:
Hi,
El 26/10/23 a las 14:03, Luis Felipe escribió:
El 25/10/23 a las 21:17, Julien Lepiller escribió:
The print service I usually use has a lot of options for flyers,
{10,15,20,30}*{10,15,20,30}, 12*12, 21*29.7 and 30*40 cm. I think
15*20 would be best.
Visit cards would be 3.5*7.5, 5.5*8.5 or 5*9 cm
Thanks, Julien, I'll hopefully have something ready for next week.
I'll let you all know.
Here's a visit card in the same style of the kakemono:
https://luis-felipe.gitlab.io/downloads/pdf/gnu-guix-visit-card-A01-EN-90x50mm.pdf
The source is in https://codeberg.org/luis-felipe/guix-graphics/
(promotional/cards).
Please note that I haven't printed a sample yet to see if it works
alright. So, if you like it and can't wait to print it, I'd recommend
printing a sample first.
I didn't find a local printer that would run a printing test for a few
cards using the same machines and materials used for printing in bulk,
so I made a really cheap printing test on regular printing paper, and
the design looks good to me: colors are acceptable and text is readable.
Here's a picture:
https://luis-felipe.gitlab.io/media/2023/11/gnu-guix-visit-card-A01-EN-cheap-print-test-02.jpg
If you see white artifacts and worn-out blacks, that's just the cheap
printing showing its natural flaws.
Cheers,
OpenPGP_0x0AB0D067012F08C3.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: Meet Guix at Capitole du Libre in Toulouse, nov. 18-19
Luis Felipe writes:
> El 26/10/23 a las 14:03, Luis Felipe escribió:
>> El 25/10/23 a las 21:17, Julien Lepiller escribió:
>>> The print service I usually use has a lot of options for flyers,
>>> {10,15,20,30}*{10,15,20,30}, 12*12, 21*29.7 and 30*40 cm. I think
>>> 15*20 would be best.
>>>
>>> Visit cards would be 3.5*7.5, 5.5*8.5 or 5*9 cm
>> Thanks, Julien, I'll hopefully have something ready for next
>> week. I'll let you all know.
>
> Here's a visit card in the same style of the kakemono:
>
> https://luis-felipe.gitlab.io/downloads/pdf/gnu-guix-visit-card-A01-EN-90x50mm.pdf
>
> The source is in https://codeberg.org/luis-felipe/guix-graphics/
> (promotional/cards).
Wonderful work, Luis Felipe! I’d love to have some of these for future
presentations or conferences.
--
Ricardo
Re: Reproducible Builds 2023 in Hamburg
Christopher Baines writes: > Hey! > > This event is now finished! Efraim and Julien and I had a discussion > about Guix things relating to Reproducible Builds and there are some > notes available here [1]. > > 1: https://reproducible-builds.org/events/hamburg2023/guix-todo/ > > Maybe the others can mention what things they've been looking at, but > I've been reminded about my previous investigation in to Reproducible > builds and the ACL [2]. I also started working on a QA topic page [3] to > pull together data and issues. > > 2: https://lists.gnu.org/archive/html/guix-devel/2020-06/msg00179.html > 3: https://qa.guix.gnu.org/reproducible-builds Oh, and I forgot to say with the help of Bernhard I added Guix support to [3]. 3: https://ismypackagereproducibleyet.org/ It's probably going to be useful to compare reproducibility status across distros, and this is a start. signature.asc Description: PGP signature
Reproducible Builds 2023 in Hamburg
Hey! This event is now finished! Efraim and Julien and I had a discussion about Guix things relating to Reproducible Builds and there are some notes available here [1]. 1: https://reproducible-builds.org/events/hamburg2023/guix-todo/ Maybe the others can mention what things they've been looking at, but I've been reminded about my previous investigation in to Reproducible builds and the ACL [2]. I also started working on a QA topic page [3] to pull together data and issues. 2: https://lists.gnu.org/archive/html/guix-devel/2020-06/msg00179.html 3: https://qa.guix.gnu.org/reproducible-builds Chris signature.asc Description: PGP signature
Re: August/November update on qa.guix.gnu.org and related things
Suhail writes: > "Christopher Baines" writes: > >> There isn't much documentation for QA > > Understood. > > Is the preferred place to ask questions regd the QA service this mailing > list? Yep. >> I think it's fair to say that these shouldn't be styled the same as >> failed builds, so I've changed the styling now. > > The neutral blue works better; thank you. On a related note, the > specific build status on data.qa.guix.gnu.org for the "now blue" entries > is "Scheduled". Why does that get presented as "Unknown" in QA? IMO, > either "Scheduled" or "Pending" (in case it's important to maintain a > distinction from the build status of individual jobs as on > data.qa.guix.gnu.org) would be clearer than "Unknown". I guess the result of the builds is unknown when they're scheduled. >> I've also added a new issue status for when QA is waiting on builds to >> happen to provide more information. > > This being "Investigate"? Out of curiosity, and in a similar vein as > above, why not simply "Scheduled" or "Pending"? Or is it that it has had > "Scheduled" build jobs for far too long and thus requires someone else > with more privileged access (than myself) to investigate the cause? > > I.e., Investigate is a verb and thus makes me wonder what the object is > (what needs to be investigated) and who the subject is (by whom)? > Shouldn't the QA issue status be an adjective instead? Yeah, this is just me copying and pasting the code for the badge. I've changed the text to pending now. That's not as specific as "QA is waiting on the results of builds" but at least it hints at that. >> There's also some content in the manual that might be useful when >> reviewing patches: >> >> https://guix.gnu.org/en/manual/devel/en/html_node/Packaging-Guidelines.html >> https://guix.gnu.org/en/manual/devel/en/html_node/Submitting-Patches.html > > Perhaps linking to these from the "Mark patches as reviewed" section on > QA would be helpful? Yes, although I think the documentation maybe needs looking at a bit to make it a bit more useful for patch review. >> But there's no pre-requisites to reviewing Guix patches, so the best >> way to learn is to start looking to review things. > > I imagine some of the "common things to check" will get automated in the > near future (e.g. whether or not the changes are adding to the lint > warnings), whereas some others will stay manual (e.g. are things "well > written"). Personally, for such subjective measures (i.e., the latter) I > find having some examples of "what good looks like" readily available > quite helpful. In case the intent is to make it easier for newcomers to > the project (i.e., those who've not yet internalized this knowledge) to > contribute, providing such prototypical examples by linking to commits, > descriptions etc in the existing source tree would help. Yes, and while I think working on the docs is important, maybe QA can link and show various examples. signature.asc Description: PGP signature
