Re: Help needed packaging rust-cbindgen, a dependency of IceCat 68

[John Soo]

Hi Mark,

I have it - but not with all the correct licenses. What version do you need?

John

Re: Help needed packaging rust-cbindgen, a dependency of IceCat 68

[Mark H Weaver]

Hi John,

John Soo  writes:
> I have it - but not with all the correct licenses.
> What version do you need?

According to Debian any version >= 0.8.7 should work.  Thank you!

  Mark

Re: Help needed packaging rust-cbindgen, a dependency of IceCat 68

[Jonathan Brielmaier]

On 22.10.19 08:23, Mark H Weaver wrote:
> Hello fellow Guix,
>
> I have good news and bad news.  The good news is that thanks to the
> heroic efforts of Amin Bandali , a recently appointed
> co-maintainer of GNU IceCat, there now exists a preliminary version of
> IceCat 68 that builds successfully and works on Trisquel.
>
> The bad news is that IceCat 68 has a new dependency: rust-cbindgen,
> which itself depends on *245* other Rust libraries that are not yet
> packaged for Guix.
>
> I'm very glad for "guix import crate -r", which was able to enumerate
> this list of dependencies for me, and to auto-generate ~267 kilobytes of
> new package definitions, but unfortunately it was only able to deduce
> the license for about half of those.  131 out of 245 of these new
> package definitions have (license #f).  I'm not sure what's up with
> that, but it might be necessary to manually determine the licenses of
> these.
>
> Mozilla is scheduled to release Firefox 68.2 ESR today, along with a
> security advisory describing flaws in previous versions of Firefox which
> are fixed in 68.2.  Many of these security flaws will affect IceCat 60,
> but the 60 ESR branch is no longer supported upstream.  This means that
> we need to get IceCat 68 packaged ASAP.
>
> There are other urgent matters demanding my attention right now, so I
> cannot afford to do all of this work myself.  I can take care of
> upgrading and debugging the IceCat 68 package itself -- I already have a
> preliminary patch capable of generating the source tarball -- but I need
> help packaging rust-cbindgen and its 245 dependencies.
>
> Who's willing to help?  To get started: "guix import crate -r cbindgen".

Efraim made a proposal to overhaul the cargo-build-system. I think this
could be pretty interesting for cbindgen.
https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00180.html

I'm interested in a proper solution here, as Thunderbird needs also
cbindgen to build. Reminds me that I should share the state of my
Thunderbird "package"...

Re: How to keep biber working

[Efraim Flashner]

On Tue, Oct 22, 2019 at 10:04:26AM +0200, Pierre Neidhardt wrote:
> Ricardo Wurmus  writes:
> 
> > This does not contradict what I wrote.  *Building* the packages differs
> > from just copying the generated files to their expected locations.  I
> > doubt Nix actually generates all these files from source.
> 
> Indeed.  We discussed this some time back: we can come up with a build
> system / importer that tries to generate the file the best it can, and
> if it fails to produce the expected output, we can fallback on copying
> the SVN files.  Not ideal, but better than what we have now ;)
> 

TeX is like black magic to me. The only thing I have to add is that
Debian "compiles" (or however it works) as a post-install hook, and they
have a DD who also works on TeX itself. However, as a binary
distribution, they have no incentive to break it up into smaller pieces.
Gentoo might be better with that, but I have no idea.


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Help needed packaging rust-cbindgen, a dependency of IceCat 68

[Mark H Weaver]

Mark H Weaver  writes:

> John Soo  writes:
>> I have it - but not with all the correct licenses.
>> What version do you need?
>
> According to Debian any version >= 0.8.7 should work.  Thank you!

Actually, I have it now too.  Within a few minutes of seeing your
message and responding to it, my efforts to build it finally succeeded,
although I had to upgrade a few other rust-* packages, and I wonder if I
broke anything else by doing so.

The main remaining issue at this point is having to check the licenses
of 131 packages, but it sounds like you might also have a similar number
of (license #f) fields in your tree.  Is that right?

In any case, thanks for the response!

  Mark

Re: How to keep biber working

[Pierre Neidhardt]

I know that OpenSuse also breaks TeXlive into the 2000+ individual packages.

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


signature.asc
Description: PGP signature

Re: Help needed packaging rust-cbindgen, a dependency of IceCat 68

[Efraim Flashner]

On Tue, Oct 22, 2019 at 11:19:18AM +0200, Jonathan Brielmaier wrote:
> On 22.10.19 08:23, Mark H Weaver wrote:
> > Hello fellow Guix,
> >
> > I have good news and bad news.  The good news is that thanks to the
> > heroic efforts of Amin Bandali , a recently appointed
> > co-maintainer of GNU IceCat, there now exists a preliminary version of
> > IceCat 68 that builds successfully and works on Trisquel.
> >
> > The bad news is that IceCat 68 has a new dependency: rust-cbindgen,
> > which itself depends on *245* other Rust libraries that are not yet
> > packaged for Guix.
> >
> > I'm very glad for "guix import crate -r", which was able to enumerate
> > this list of dependencies for me, and to auto-generate ~267 kilobytes of
> > new package definitions, but unfortunately it was only able to deduce
> > the license for about half of those.  131 out of 245 of these new
> > package definitions have (license #f).  I'm not sure what's up with
> > that, but it might be necessary to manually determine the licenses of
> > these.
> >
> > Mozilla is scheduled to release Firefox 68.2 ESR today, along with a
> > security advisory describing flaws in previous versions of Firefox which
> > are fixed in 68.2.  Many of these security flaws will affect IceCat 60,
> > but the 60 ESR branch is no longer supported upstream.  This means that
> > we need to get IceCat 68 packaged ASAP.
> >
> > There are other urgent matters demanding my attention right now, so I
> > cannot afford to do all of this work myself.  I can take care of
> > upgrading and debugging the IceCat 68 package itself -- I already have a
> > preliminary patch capable of generating the source tarball -- but I need
> > help packaging rust-cbindgen and its 245 dependencies.
> >
> > Who's willing to help?  To get started: "guix import crate -r cbindgen".
> 
> Efraim made a proposal to overhaul the cargo-build-system. I think this
> could be pretty interesting for cbindgen.
> https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00180.html
> 
> I'm interested in a proper solution here, as Thunderbird needs also
> cbindgen to build. Reminds me that I should share the state of my
> Thunderbird "package"...

Indeed. The short version is to basically treat each of the crates more
like the test data, something that gets downloaded but not built
independently. Then throw everything into the build system similar to
now, but with more manual dependency resolution, and work with it that
way. I have one that I tested successfully that I can make shorter but
can't share. Throwing together something quickly for this should
probably only take an hour or two.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Towards reproducibly Jupyter notebooks with Guix-Jupyter

[Ludovic Courtès]

Hi,

Konrad Hinsen  skribis:

 At the API level, there’s ‘inferior-for-channels’ which does that +
 registers a GC root + maintains a cache so that the second time you use
 a given instance of Guix it’s immediately available.
>>>
>>> Just what I need...
>>
>> Awesome, let us know how it goes!
>
> Not so well...

Did you define an environment along the lines of the example at
?

If so, this should behave in exactly the same way as a “regular” ‘guix
environment’, so I’m not sure where the issues regarding access to the
tty come from?

Depending on the use case, another option is to not use inferiors at all
and simply do:

  guix pull --commit=XYZ -p ./my-old-guix
  ./my-old-guix/bin/guix environment --ad-hoc whatevern

But maybe I’m missing something, let me know.  :-)

Thanks,
Ludo’.

Re: Towards reproducibly Jupyter notebooks with Guix-Jupyter

[Konrad Hinsen]

Hi Ludo,

> Did you define an environment along the lines of the example at
> ?

No. I did look at this approach briefly, but it looks difficult at
least, if not impossible.

The situation I need to address is re-creating an environment from
- a channel file (from "guix describe")
- a manifest file (typically hand written)

This should not require editing the manifest file, and it should work
for any manifest file, even if it included package transformations or
literal package definitions (yes, I do that, shame on me, I ought to set
up my own channel instead).

A manifest definition using only lookups by package name and version
would be easy to translate into a manifest containing instances of
inferior-package, but I don't see how to deal with the more exotic
cases. I'd have to construct corresponding instances of inferior-package
myself, which is perhaps possible, but not obvious.

> Depending on the use case, another option is to not use inferiors at all
> and simply do:
>
>   guix pull --commit=XYZ -p ./my-old-guix
>   ./my-old-guix/bin/guix environment --ad-hoc whatevern
>
> But maybe I’m missing something, let me know.  :-)

That was my starting point. It's OK for manual execution, but if I want
an Org-Mode file to this automatically, I need to generate a temporary
file in place of ./my-old-guix with all the associated hassles: check
that it doesn't exist before, and clean up in the end even in the case
of errors. Maybe I'd even have to worry about two processes accessing
the same temporary file and do some locking.

Moreover, I may end up having a performance problem with "guix pull"
being run again for every little script in my Org-Mode file. The big
difference between Jupyter and Org-Mode is that Jupyter has only one
kernel process per notebook, whereas Org-Mode by default has one process
per code block.

My dream would be to have something like

  guix environment -C channels.scm -m manifest.scm

with reasonable caching of the pulled channels. That's in fact what I
was trying to implement.

Cheers,
  Konrad.

Re: Stackage LTS 14 (was: Adding Purescript)

[Ricardo Wurmus]

Hi Timothy,

> One of the things I want to do this time is to do the upgrade in one
> mega commit.  I’m pretty sure that some of the commits last time had
> inconsistent package sets, which is not ideal.  I’m not sure how to
> avoid that upgrading one package at a time.  Hence, my rough plan is to
> start by setting GHC 8.6 as the compiler for the build system, and then
> run the refresh script with Stackage LTS 14.  After that, I will push
> the results to wip-haskell-updates and see how it goes.
>
> Ricardo, what do you think?  Are we okay to take over
> wip-haskell-updates?  Does a mega commit make sense or do you think
> that’s a bad idea?

Yes, you can take over wip-haskell-updates.

A single big commit is not a good idea, but you don’t really need it as
you’d merge the branch in one go, so Cuirass would not end up evaluating
any of the intermediate commits anyway.  It’s still good to have smaller
commits to better undo individual changes and more easily understand
related changes.

--
Ricardo

Re: Loading modules built using linux-module-build-system

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic  skribis:

> A patch to guix master which
>
> * Puts the kernel modules (including any other packages that have 
> "lib/modules"
> inside their derivation) into /run/booted-system/profile/lib/modules
> * Ensures that depmod is invoked on that
> * Makes the modprobe wrapper use it
>
> is provided below.

Nice!

I’m wondering if we could avoid clobbering the global profile with the
kernel and module packages, though (as is currently the case.)

> --- a/gnu/system.scm
> +++ b/gnu/system.scm
> @@ -887,9 +887,11 @@ we're running in the final root."
>  (define* (operating-system-profile os)
>"Return a derivation that builds the system profile of OS."
>(mlet* %store-monad
> -  ((services -> (operating-system-services os))
> -   (profile (fold-services services
> -   #:target-type profile-service-type)))
> +  ((kernel -> (operating-system-kernel os))
> +   (services -> (operating-system-services os))
> +   (profile (cons kernel (fold-services services
> +#:target-type
> +profile-service-type
>  (match profile
>(("profile" profile)
> (return profile)

The value of ‘profile’ above can never match this pattern, or am I
missing something?

> +(define (linux-module-database manifest)
> +  (mlet %store-monad
> +((kmod (manifest-lookup-package manifest "kmod")))
> +(define build
> +  (with-imported-modules '((guix build utils)
> +   (guix build union))
> +   #~(begin
> +  (use-modules (srfi srfi-26)
> +   (guix build utils)
> +   (guix build union)
> +   (ice-9 match))
> +  (let ((destdir (string-append #$output "/lib/modules"))
> +(dirs (filter file-exists?
> +  (map (cut string-append <>
> +"/lib/modules")
> +   '#$(manifest-inputs manifest
> +(System.maps (filter file-exists?
> +  (map (cut string-append <> "/System.map")
> +   '#$(manifest-inputs manifest
> +(Module.symvers (filter file-exists?
> +  (map (cut string-append <> "/Module.symvers")
> +   '#$(manifest-inputs manifest)
> +  (mkdir-p (string-append #$output "/lib"))
> +  (union-build destdir dirs #:create-all-directories? #t)
> +  (exit (zero? (system* (string-append #$kmod "/bin/depmod")
> +"-e" ; Report symbols that aren't supplied
> +"-w" ; Warn on duplicates
> +"-b" destdir
> +"-F" (match System.maps ((x) x))
> +"-E" (match Module.symvers ((x) x)
> +(gexp->derivation "linux-module-database" build
> +  #:local-build? #t
> +  #:substitutable? #f
> +  #:properties
> +  `((type . profile-hook)
> +(hook . linux-module-database)

Note that this fails if ‘kmod’ is no in the profile.

Besides, I wonder how much is missing from (gnu build linux-modules) to
do this without resorting to kmod.  :-)

>  (define (xdg-desktop-database manifest)
>"Return a derivation that builds the @file{mimeinfo.cache} database from
>  desktop files.  It's used to query what applications can handle a given
> @@ -1425,7 +1463,8 @@ MANIFEST."
>  gtk-im-modules
>  texlive-configuration
>  xdg-desktop-database
> -xdg-mime-database))
> +xdg-mime-database
> +linux-module-database))

Maybe we should not add this hook by default, to avoid overhead for a
very unusual use case.  The caller of ‘profile-derivation’ could add it
when needed.

Thinking more about it, what about handling the union/profile thing in
‘operating-system-directory-base-entries’?  We could still use
‘profile-derivation’ with the hook you wrote, but we’d be able to keep
that here instead of adding it to (guix profiles).

Also, if we take that route, we would probably need a
‘linux-module-packages’ field in .

WDYT?

Thanks,
Ludo’.

Re: SLiM graphical login manager and keyboard layout

[Ludovic Courtès]

Hello Tanguy,

Tanguy Le Carrour  skribis:

> Le 10/18, Diego Nicola Barbato a écrit :
>> Tanguy Le Carrour  writes:
>> >(service slim-service-type
>> >  (slim-configuration
>> >   (xorg-configuration
>> >(xorg-configuration
>> > (keyboard-layout keyboard-layout))
>> >
>> >
>> > I don't understand the "double" `xorg-configuration`, though! ^_^'
>> 
>> The outer 'xorg-configuration' is a field of the 'slim-configuration'
>> data type.  The inner 'xorg-configuration' is itself a data type
>> representing the Xorg configuration (with its 'keyboard-layout' field
>> set to the value of 'keyboard-layout').
>
> Thanks for the clarification!
> All of this LISP/Scheme/Guile is still a bit magical to me! How does one makes
> the difference between field assignment and data type "instanciation"? ^_^'
> How does the interpreter know that the same "word" means two different
> things?!

There are several rules.  The most important one is lexical scope: when
you see an identifier, it always refers to the binding in its lexical
scope.  So there are no bad surprises:

  (let ((* +) (x 42))  ;here ‘+’ is a “free variable”—i.e., not in scope
(let ((x 7))
  (* x x)))
  => 14

Then there are “special forms” (macros) that can introduce new bindings
like ‘let’.  Macros are always* “referentially transparent” (or
“hygienic”), which means notably that they only introduce bindings that
you explicitly typed in, and they cannot capture bindings that you did
not explicitly provide them as an argument:

  (let ((x 3))
;; Here ‘x’ is defined.
…)

  (operating-system
(keyboard-layout …)
;; Here ‘keyboard-layout’ is defined, because ‘operating-system’
;; expands to something like:
;;
;;  (let* ((keyboard-layout …) (next-field …) …) …)
)

The rules are unambiguous.  I understand it takes some getting used to
it, but the general idea is that scoping behaves “like you’d expect.”

HTH!

Ludo’.

* It’s possible to write so-called “unhygienic” macros that would, for
  instance, forcefully create bindings that don’t appear in the source,
  but that’s considered bad practice and we don’t do that in the Guix
  code base.

Re: Stateful system directories

[Ludovic Courtès]

Howdy!

Efraim Flashner  skribis:

> On Sat, Oct 19, 2019 at 11:08:57PM +0200, Ludovic Courtès wrote:
>> Hello Efraim,
>> 
>> Efraim Flashner  skribis:
>> 
>> > Ignoring the directories in users' home directories, /var/lib/gdm has
>> > been a source of pain on GNOME upgrades, and we still have some problems
>> > with /var/cache/fontconfig and I believe there is something else with
>> > permissions if you switch between ntp and openntpd. I actually have the
>> > following snippet in my OS-config:
>> >
>> > ;; This directory shouldn't exist
>> > (file-system
>> >   (device "none")
>> >   (mount-point "/var/cache/fontconfig")
>> >   (type "tmpfs")
>> >   (flags '(read-only))
>> >   (check? #f))
>> 
>> I think that would work, or we could even make it a writable tmpfs?
>
> I got angry with it and wanted to see if I could generate any error
> messages. :) So far nothing. Of course there isn't a compelling reason
> to really make it read-only if we recreate it each time, and it should
> cut down on bugs for other directories.

Yup, let’s do that.

>> (Somehow, I do have /var/cache/fontconfig, but never hard any problems
>> with it.  It hasn’t been written to in months, and it’s only writable by
>> root anyway.  Does that mean that people run into problem when they run
>> GUIs as root?)
>
> I have it too, not sure from what. I'm guessing some of the packages
> which have fontconfig as an input get a dbus-something to create the
> directory if it's missing.

Heh, these dbus things doing stuff behind our back.  :-)

>> > While we work on fixing these does it make sense to modify some of these
>> > services to unconditionally recreate their home directories on
>> > boot/activation?
>> 
>> Like /var/lib/gdm?  Maybe.  Or maybe ‘gdm-service-type’ could extend
>> ‘file-system-service-type’ with a tmpfs for /var/lib/gdm?
>> 
>
> Sounds like a good idea. Would that also cause the directory to be
> removed if gdm is removed? It should create a tmpfs and mount it over an
> existing /var/lib/gdm, right?

Yes.  So the directory won’t be removed if gdm is removed, but that’s
fine, it’ll just be an empty directory sitting there.

>> I suppose that might increase startup time a bit since it’d be
>> rebuilding its cache every time.  Perhaps we’d also lose bits of state,
>> no?
>
> The increase in startup time should be negligible, and according to
> rekado, who seems to run into GDM issues the most, removing /var/lib/gdm
> is one of the first steps when upgrading gnome or debugging gdm issues.

Yeah, it’s a tradeoff, but we should try it on the bare metal to get a
feel.  There’s quite a bit of data in there that we’d be recreating at
each boot:

--8<---cut here---start->8---
$ sudo ls -l /var/lib/gdm/.cache
totalo 16
drwxr-xr-x  2 gdm gdm 4096 Sep 19 08:45 fontconfig
drwxr-xr-x  3 gdm gdm 4096 Apr 11  2019 ibus
drwx--  2 gdm gdm 4096 Apr  1  2019 libgweather
drwxr-xr-x 97 gdm gdm 4096 Sep 19 08:45 mesa_shader_cache
--8<---cut here---end--->8---

If you give it a spin, let us know how it goes!

Ludo’.

The cookbook is on-line!

[Ludovic Courtès]

Hello Guix!

A few weeks ago Ricardo started writing a Guix Cookbook⁰ based on
material previously published elsewhere, notably on the blog.  The
cookbook made it in to the repo¹, and you’re all welcome to propose new
sections based on your experience with Guix!

The news is that the Cookbook is now on-line and automatically updated
from ‘master’:

  https://guix.gnu.org/cookbook/en/

(The page says “Reference Manual” but it’s a mistake that I’ll fix.)

So I guess we can go ahead and fill in that cookbook!  :-)
Please share what you’d like to see or to write about as a Guix user!


For the record, here are the changes to the config of
berlin.guix.gnu.org to publish the cookbook:

  
https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=8897e7bc35cbcd0d6cf60c4a57063cd2dceb7bbe

and the changes to ‘doc/build.scm’:

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=cacb5576cc517cba45f69f1fb1551348714d85d0

Ludo’.

⁰ https://lists.gnu.org/archive/html/guix-devel/2019-09/msg00098.html
¹ https://git.savannah.gnu.org/cgit/guix.git/tree/doc/guix-cookbook.texi


signature.asc
Description: PGP signature

Re: Help needed packaging rust-cbindgen, a dependency of IceCat 68

[Ludovic Courtès]

Hi Mark,

Mark H Weaver  skribis:

> I have good news and bad news.  The good news is that thanks to the
> heroic efforts of Amin Bandali , a recently appointed
> co-maintainer of GNU IceCat, there now exists a preliminary version of
> IceCat 68 that builds successfully and works on Trisquel.
>
> The bad news is that IceCat 68 has a new dependency: rust-cbindgen,
> which itself depends on *245* other Rust libraries that are not yet
> packaged for Guix.

I don’t think I said it publicly yet, so: welcome back!  It’s good to
see your energy back here on these essential and tricky topics.

Ludo’.

Re: Help wanted for mumi (issues.guix.gnu.org)

[Ludovic Courtès]

Hi Ricardo!

Ricardo Wurmus  skribis:

> So I decided to switch away from using the Debbugs API and instead
> operate on a *local* copy of all messages that reach Debbugs.  Debbugs
> operates on email messages, and luckily it allows us to download these
> original messages.  Whenever someone visits an issue page, all related
> messages are downloaded by mumi, so it amasses a sizeable stash of
> emails over time.

That sounds like a great improvement!

> Unfortunately, that’s as far as I got before life intervened.  The next
> step is really close, but getting there requires more contiguous
> segments of time than I can free at the moment.  We really only need to
> do the following things next:
>
> 1) keep updating the mu database as new messages are stored
> 2) using the mu Guile bindings to search messages via mu instead of
> using the slow Debbugs API.
>
> While working on 2 we may find that more properties should be stored in
> the mu database, and that’s fine.  Our variant of mu is easily patched
> to accomodate our needs.
>
> Does anyone here have an interest in playing with and improving mumi?
> It’s a very simple code base and it’s very easy to get started.
>
> The code is here:
>
> https://git.elephly.net/software/mumi.git

I’m not offering to work on it right now, but it sounds like a nice
rewarding project someone™ should take!  :-)

Thanks for all your work on this, issues.guix.gnu.org has already been
very helpful!

Ludo’.

Re: The cookbook is on-line!

[Ricardo Wurmus]

Pierre Neidhardt  writes:

> I just noticed that about half the packaging tutorial is missing (the
> part after the Scheme crash course).
>
> Shouldn't be added?  Maybe Ricardo had a plan in mind.

>From the sources:

@c TODO: Continue the tutorial

So yeah, the plan was to add the rest :) I just don’t have the time to
do this myself.  More important to me was to put *something* out there
that others can more easily edit.

--
Ricardo

Re: Help needed packaging rust-cbindgen, a dependency of IceCat 68

[Efraim Flashner]

Here's what I have for rust-cbindgen based more-or-less on my
re-imagining of the cargo-build-system and the rust inputs.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
;;; Copyright © 2019 Efraim Flashner 
;;;
;;; This file is an addendum to GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see .

(define-module (cbindgen)
  #:use-module ((guix licenses) #:prefix license:)
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix build-system cargo))

(define-public rust-cbindgen
  (package
(name "rust-cbindgen")
(version "0.9.1")
(source
  (origin
(method url-fetch)
(uri (crate-uri "cbindgen" version))
(file-name (string-append name "-" version ".tar.gz"))
(sha256
 (base32
  "1zgamxahlxmg4warzivaa8m1f8d6b45mhznm7n6d7p5l18acdblx"
(build-system cargo-build-system)
(arguments
 `(#:cargo-inputs
   (("clap" ,rust-clap-2)
("log" ,rust-log-0.4)
("proc-macro2" ,rust-proc-macro2-1.0)
("quote" ,rust-quote-1.0)
("serde" ,rust-serde-1.0)
("serde-json" ,rust-serde-json-1.0)
("syn" ,rust-syn-1.0)
("tempfile" ,rust-tempfile-3.0)
("toml" ,rust-toml-0.5))
   #:cargo-development-inputs
   (("ansi-term" ,rust-ansi-term-0.11)
("atty" ,rust-atty-0.2)
("autocfg" ,rust-autocfg-0.1)
("bitflags" ,rust-bitflags-1.1)
("cfg-if" ,rust-cfg-if-0.1)
("cloudabi" ,rust-cloudabi-0.0)
("fuchsia-cprng" ,rust-fuchsia-cprng-0.1)
("itoa" ,rust-itoa-0.4)
("libc" ,rust-libc-0.2)
("numtoa" ,rust-numtoa-0.1)
("rand" ,rust-rand-0.6)
("rand-chacha" ,rust-rand-chacha-0.1)
("rand-core-0.4" ,rust-rand-core-0.4)
("rand-core-0.3" ,rust-rand-core-0.3)
("rand-hc" ,rust-rand-hc-0.1)
("rand-isaac" ,rust-rand-isaac-0.1)
("rand-jitter" ,rust-rand-jitter-0.1)
("rand-os" ,rust-rand-os-0.1)
("rand-pcg" ,rust-rand-pcg-0.1)
("rand-xorshift" ,rust-rand-xorshift-0.1)
("rdrand" ,rust-rdrand-0.4)
("redox-syscall" ,rust-redox-syscall-0.1)
("redox-termios" ,rust-redox-termios-0.1)
("remove-dir-all" ,rust-remove-dir-all-0.5)
("ryu" ,rust-ryu-1.0)
("serde-derive" ,rust-serde-derive-1.0)
("strsim" ,rust-strsim-0.8)
("termion" ,rust-termion-1.5)
("textwrap" ,rust-textwrap-0.11)
("unicode-width" ,rust-unicode-width-0.1)
("unicode-xid" ,rust-unicode-xid-0.2)
("vec-map" ,rust-vec-map-0.8)
("winapi" ,rust-winapi-0.3)
("winapi-i686-pc-windows-gnu" ,rust-winapi-i686-pc-windows-gnu-0.4)
("winapi-x86-64-pc-windows-gnu" 
,rust-winapi-x86-64-pc-windows-gnu-0.4
(home-page "https://github.com/eqrion/cbindgen/";)
(synopsis "Tool for generating C bindings to Rust code")
(description
 "This package provides a tool for generating C bindings to Rust code.")
(license license:mpl2.0)))

;;;
;;; ^L
;;;

(define-public rust-ansi-term-0.11
  (package
(name "rust-ansi-term")
(version "0.11.0")
(source
  (origin
(method url-fetch)
(uri (crate-uri "ansi_term" version))
(file-name (string-append name "-" version ".tar.gz"))
(sha256
 (base32
  "16wpvrghvd0353584i1idnsgm0r3vchg8fyrm0x8ayv1rgvbljgf"
(build-system cargo-build-system)
(home-page "https://github.com/ogham/rust-ansi-term";)
(synopsis "Library for ANSI terminal colours and styles")
(description
 "This is a library for controlling colours and formatting, such as red bold
text or blue underlined text, on ANSI terminals.")
(properties '((hidden? . #t)))
(license license:expat)))

(define-public rust-atty-0.2
  (package
(name "rust-atty")
(version "0.2.13")
(source
  (origin
(method url-fetch)
(uri (crate-uri "atty" version))
(file-name (string-append name "-" version ".tar.gz"))
(sha256
 (base32
  "140sswp1bwqwc4zk80bxkbnfb3g936hgrb77g9g0k1zcld3wc0qq"
(build-system cargo-build-system)
(home-page "https://github.com/softprops/atty";)
(synopsis "A simple interface for querying atty")

Re: We need your feedback of the documentation videos!

[pelzflorian (Florian Pelz)]

On Tue, Oct 22, 2019 at 11:25:27AM -0500, sirgazil wrote:
> I think that these changes and a blog post about the availability of these 
> videos would work well to get the videos to the public as soon as possible.
>

:)


> The only thing I'd recommend against would be the yellow headers in the 
> videos page because they don't satisfy the WCAG 2.0 level AA contrast 
> requirements (one of my goals with the website design was to follow level AA 
> guidelines at least).
> 
> Now, personally, if I had the time, I would have designed the videos page in 
> a similar way to the blog page, and also done something like this:
> 
> * Add a "media" menu to the navbar with "screenshots" and "videos" items.
> * Add a "media" app that would hold the definitions for videos and 
> screenshots (the latter would move from the base app).
> * Add a "tracks" field to the "video" record and a corresponding "track" 
> record type for future subtitles.
> * Add three video previews to the home page, below the screenshot previews, 
> maybe using a heading like "Instructional videos".
> * Add a new entry to the Help page, next to "GNU Guix Manual", with the same 
> "Instructional videos" title.
> 
> 

Thank you for your review.  I will resend tomorrow with these changes.


>  > Putting the video files in the guix-artwork git repository may be 
>  > wrong, so the patch does not do that yet, instead still referencing 
>  > archive.org which seems wrong too. 
> 
> Is there any ethical issue with using archive.org that I'm not aware of? I 
> suggested Laura to upload videos there...
> 

I believe there is no ethical issue.  I like archive.org.  My only
reason is what you write here:


> In any case, since it is already possible, it would be great to use Guix own 
> hosting resources.

Regards,
Florian

Re: Any interest in using HTML for locally-installed Texinfo documentation?

[Gavin Smith]

On Sat, Oct 19, 2019 at 9:31 PM Ludovic Courtès  wrote:
> > I started another line of development, using the WebKitGTK engine.
> > http://git.savannah.gnu.org/cgit/texinfo.git/log/?h=webkitgtk-info
>
> [...]
>
> > I may be able to get an initial prototype that other people could try
> > ready in a few days. As ever, if anyone is interested in helping
> > with/taking over this project, please let me know.
>
> Thanks for the update, it looks promising.  Let us know when you’d like
> people to give it a try!

The work is available on the webkitgit-info branch of the texinfo git
repository. I think it is developed to a point where it shows that a
browser for locally installed HTML documentation is clearly possible
with WebKitGTK. There are some notes in the README file on how to
build manuals for use with the browser.

I tried to upload a demo video to
https://goblinrefuge.com/mediagoblin/u/gavin/ but it hasn't appeared
yet.

Re: Help needed packaging rust-cbindgen, a dependency of IceCat 68

[Mark H Weaver]

Ludovic Courtès  writes:
> I don’t think I said it publicly yet, so: welcome back!  It’s good to
> see your energy back here on these essential and tricky topics.

Thank you, Ludovic.  I'm grateful for your words, and for the wonderful
Guix system that you gave birth to and ably nurtured for long years into
maturity.  At this point, I can't imagine using anything else :)

   Mark

Re: Help needed packaging rust-cbindgen, a dependency of IceCat 68

[Mark H Weaver]

Hi Efraim,

Efraim Flashner  writes:
> Here's what I have for rust-cbindgen based more-or-less on my
> re-imagining of the cargo-build-system and the rust inputs.

Thank you very much for this!  Notably, I see that every package in your
source has a proper 'license' field, and that there are *far* fewer
dependencies here than 'guix import crate -r cbindgen' pulled in.

What's the feasibility of turning this file into a set of commits that
could be applied to 'master' in the next day or two?  If that could be
done, it would be tremendously helpful.  I think it's okay if these
"re-imagined" Rust packages are all 'hidden' for now and put in a
separate module, to avoid breaking anything else or interfering with the
packages in crates.io.

Would you like to do it?

If it won't be done within a couple of days, then we may need to
consider other options.

Thank you!
   Mark

Re: Stateful system directories

[Jack Hill]

Today I had an occasion to create a file in gdm's home directory that 
should persist across reboots. I needed to set a dconf setting to 
prevent gdm from putting the computer to sleep. Full details on guix-help 
[0]. Unfortunately, I don't believe there is yet a way to handle these 
setting in a declarative way.


[0] https://lists.gnu.org/archive/html/help-guix/2019-10/msg00213.html

Best,
Jack

Re: Help needed packaging rust-cbindgen, a dependency of IceCat 68

[Mark H Weaver]

Hi Efraim,

Mark H Weaver  writes:

> Efraim Flashner  writes:
>> Here's what I have for rust-cbindgen based more-or-less on my
>> re-imagining of the cargo-build-system and the rust inputs.
>
> Thank you very much for this!  Notably, I see that every package in your
> source has a proper 'license' field, and that there are *far* fewer
> dependencies here than 'guix import crate -r cbindgen' pulled in.
>
> What's the feasibility of turning this file into a set of commits that
> could be applied to 'master' in the next day or two?  If that could be
> done, it would be tremendously helpful.  I think it's okay if these
> "re-imagined" Rust packages are all 'hidden' for now and put in a
> separate module, to avoid breaking anything else or interfering with the
> packages in crates.io.
>
> Would you like to do it?

I looked again, and I see that you _already_ marked all of the packages
'hidden' except for 'rust-cbindgen' itself.  Perfect!  Somehow I managed
to miss that on my first perusal of the code.

The only additional suggestion I'd make is to change 'define-public' to
'define' for all of these packages except for 'rust-cbindgen', to avoid
possible conflicts in modules that import both 'cbindgen.scm' and
'crates-io.scm'.

How about simply putting this file in (gnu packages rust-cbindgen) for
now, with the file header comment changed to match other files in Guix,
and with the trailing 'rust-cbindgen' at the bottom removed.

Would you like to do this?  If not, I could do it.

Thanks again!  This is a great help and an enormous relief to me.

 Mark

Re: Help needed packaging rust-cbindgen, a dependency of IceCat 68

[Efraim Flashner]

On Tue, Oct 22, 2019 at 03:56:42PM -0400, Mark H Weaver wrote:
> Hi Efraim,
> 
> Mark H Weaver  writes:
> 
> > Efraim Flashner  writes:
> >> Here's what I have for rust-cbindgen based more-or-less on my
> >> re-imagining of the cargo-build-system and the rust inputs.
> >
> > Thank you very much for this!  Notably, I see that every package in your
> > source has a proper 'license' field, and that there are *far* fewer
> > dependencies here than 'guix import crate -r cbindgen' pulled in.

I actually got the list from cbindgen's Cargo.lock file. I figured we
were building far more than necessary, since we were throwing almost all
the results.

> >
> > What's the feasibility of turning this file into a set of commits that
> > could be applied to 'master' in the next day or two?  If that could be
> > done, it would be tremendously helpful.  I think it's okay if these
> > "re-imagined" Rust packages are all 'hidden' for now and put in a
> > separate module, to avoid breaking anything else or interfering with the
> > packages in crates.io.
> >
> > Would you like to do it?

I wouldn't mind doing it. It'll have to wait until tomorrow though, it's
getting late here.

The motivation behind the 'hidden' part was so they could be public, so
we could keep a list of rust sources in crates-io rather than spread
around, but not visible, since I don't think any of them would build in
their current form.

> 
> I looked again, and I see that you _already_ marked all of the packages
> 'hidden' except for 'rust-cbindgen' itself.  Perfect!  Somehow I managed
> to miss that on my first perusal of the code.
> 
> The only additional suggestion I'd make is to change 'define-public' to
> 'define' for all of these packages except for 'rust-cbindgen', to avoid
> possible conflicts in modules that import both 'cbindgen.scm' and
> 'crates-io.scm'.

Not a problem, we can always go back and change them around again later.

> 
> How about simply putting this file in (gnu packages rust-cbindgen) for
> now, with the file header comment changed to match other files in Guix,
> and with the trailing 'rust-cbindgen' at the bottom removed.
> 
> Would you like to do this?  If not, I could do it.

Sounds good. I can toss it in.

> 
> Thanks again!  This is a great help and an enormous relief to me.
> 
>  Mark

I knew all the hours I spent banging my head against rust would come in
handy :)

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: 06/06: gnu: Add weasyprint.

[Ludovic Courtès]

Hi Hartmut,

guix-comm...@gnu.org skribis:

> +  (package
> +(name "weasyprint")
> +(version "50")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (pypi-uri "WeasyPrint" version))
> +   (sha256
> +(base32 "0invs96zvmcr6wh5klj52jrcnr9qg150v9wpmbhcsf3vv1d1hbcw"))
> +   (patches (search-patches "weasyprint-library-paths.patch"

You forgot to push the patch.  Could you add it?

Thanks,
Ludo’.

Re: Any interest in using HTML for locally-installed Texinfo documentation?

[Gavin Smith]

On Tue, Oct 22, 2019 at 8:00 PM Gavin Smith  wrote:
> I tried to upload a demo video to
> https://goblinrefuge.com/mediagoblin/u/gavin/ but it hasn't appeared
> yet.

That doesn't seem to be working, so I've uploaded the video to
https://www.gnu.org/software/texinfo/video/demo.webm.

Re: 06/06: gnu: Add weasyprint.

[Tobias Geerinckx-Rice]

Hartmut, Ludo',

Ludovic Courtès 写道：
+   (patches (search-patches 
"weasyprint-library-paths.patch"


You forgot to push the patch.  Could you add it?


I've reverted this patch for now to keep master relatively happy.

Good night!

T G-R


signature.asc
Description: PGP signature

Re: We need your feedback of the documentation videos!

[sirgazil]

Hi, Florian :)


 On Tue, 22 Oct 2019 07:05:04 -0500 pelzflorian (Florian Pelz) 
 wrote 

 > OAOn Sat, Oct 19, 2019 at 11:00:34PM +0200, pelzflorian (Florian Pelz) 
 > wrote: 
 > > On Sat, Oct 19, 2019 at 10:13:59PM +0200, Ludovic Courtès wrote: 
 > > > […] if you wanted to integrate them on 
 > > > the web site, I think that’d be great. 
 > > > 
 > > 
 > > I suppose the “Discover Guix” section on the homepage should advertise 
 > > Guix System and the videos, maybe in buttons next to the ALL PACKAGES 
 > > button.  I will look at making a proposal next week.  I am nowhere 
 > > near as creative as the website’s authors, so maybe others will think 
 > > of better designs. 
 > > 
 > > 
 >  
 > Do you have in mind something like the attached patch?  It does not 
 > yet add all of the videos; this is more proof of concept-like. 


I think that these changes and a blog post about the availability of these 
videos would work well to get the videos to the public as soon as possible.

The only thing I'd recommend against would be the yellow headers in the videos 
page because they don't satisfy the WCAG 2.0 level AA contrast requirements 
(one of my goals with the website design was to follow level AA guidelines at 
least).

Now, personally, if I had the time, I would have designed the videos page in a 
similar way to the blog page, and also done something like this:

* Add a "media" menu to the navbar with "screenshots" and "videos" items.
* Add a "media" app that would hold the definitions for videos and screenshots 
(the latter would move from the base app).
* Add a "tracks" field to the "video" record and a corresponding "track" record 
type for future subtitles.
* Add three video previews to the home page, below the screenshot previews, 
maybe using a heading like "Instructional videos".
* Add a new entry to the Help page, next to "GNU Guix Manual", with the same 
"Instructional videos" title.


 > > > Especially since we now host the web site by ourselves, we could also 
 > > > host the videos there, so that can be pretty easy to do. 
 > > > 
 > > > WDYT? 
 > > > 
 > > > Ludo’. 
 > > 
 > > I cannot judge whether audio-video.gnu.org is better or worse than 
 > > berlin. 
 > > 
 >  
 > Putting the video files in the guix-artwork git repository may be 
 > wrong, so the patch does not do that yet, instead still referencing 
 > archive.org which seems wrong too. 

Is there any ethical issue with using archive.org that I'm not aware of? I 
suggested Laura to upload videos there...

In any case, since it is already possible, it would be great to use Guix own 
hosting resources.

Re: 'core-updates' Q4 2019

[Timothy Sample]

Hi again,

Timothy Sample  writes:

> I’ll report back if I have good luck with fsck and am able to do more
> testing.  :)

I was able to build everything and start testing.  To use “guix system
vm” I had to disable tests in QEMU due to a failure.  I did not
investigate it.

This turned up in the logs [1]:

(.gnome-shell-real:317): GLib-GIO-ERROR **: 03:50:44.482:
Settings schema 'org.gnome.mutter' is not installed.

It was followed by a warning that “org.gnome.Shell.desktop” was killed.
This is the same message mentioned in the comment explaining disabled
tests in the “mutter” package.

There’s a “glib-or-gtk?” flag for the Meson build system.  Setting it to
“#t” in the “mutter” package makes GDM and GNOME work in a VM.  It
compiles the schemas and wraps Mutter so that it knows where they are.
It does nothing for the tests, though.  However, from the log of an
older Mutter build [2], it looks like the tests were not being run
correctly under Autotools anyway (it looks like not a single test is
actually run).

Hope that helps!


-- Tim

[1] It’s not obvious, but if you edit the GDM configuration file
generation code in “gnu/services/xorg.scm”, you can enable debug output
for GDM.  The debug output is usually extremely helpful!

[2] https://ci.guix.gnu.org/log/q0gkbynj35qp522bi8sf98kzwrsyy037-mutter-3.30.2