Re: how to test service changes

[Nicolò Balzarotti]

Hi Martin,

I think you can use ~./pre-inst-env guix system vm config.scm~ and test
the service there.

But maybe somebody else has better advices.

Thanks,
Nicolò

Martin Becze  writes:

> Hi Guix,
>
> I was in the processes of updating geoclue but I ran into a problem. I 
> don't know how to test the updated package on my system. geoclue is 
> installed by (geoclue-service) in my config.scm. How would I  go about 
> making `guix system reconfigure ./config.scm` use my updated package? Or 
> is there another way to replace the current geoclue with the newer one?
>
> Thanks!
> -Martin

how to test service changes

[Martin Becze]

Hi Guix,

I was in the processes of updating geoclue but I ran into a problem. I 
don't know how to test the updated package on my system. geoclue is 
installed by (geoclue-service) in my config.scm. How would I  go about 
making `guix system reconfigure ./config.scm` use my updated package? Or 
is there another way to replace the current geoclue with the newer one?


Thanks!
-Martin

Re: G-Expressions and Scope Preservation

[Chris Marusich]

zimoun  writes:

> the Unison language

Thank you for sharing the link!  I only read the overview, but I can see
why this makes you think of G-Expressions.  It's always interesting to
read about how content addressability can make some problems easier.

> I cannot wait for your presentation at FOSDEM. :-)

I look forward to seeing you there!

-- 
Chris


signature.asc
Description: PGP signature

Re: libmediainfo

[Efraim Flashner]

On January 21, 2020 9:08:55 PM UTC, ssch...@mailbox.org wrote:
>> Efraim Flashner  hat am 20. Januar 2020 08:35 
>> geschrieben:
>>
>> typo above, it should be /lib/libmediainfo.so.o
>> 
>> With that change I got 1 test error, related to it trying to download an
>> mp4 file from the internet.
>
>Thank you very much! Maybe there is another typo, because 
>/lib/libmediainfo.so.0 (zero not o) worked for me?

Definately a typo, I meant .so.0
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: OCaml 4.09

[Julien Lepiller]

Le 20 janvier 2020 19:43:38 GMT-05:00, Julien Lepiller  a 
écrit :
>Ok, I pushed some updates to ocaml packages. I think we can now proceed
>with the switch to ocaml 4.09 by default. There are three phases to the
>switch, and two more to complete it:
>
>- add ocaml4.07-findlib
>- add package-with-ocaml4.07
>- switch the default:
> + switch ocaml
>+ explicitely use ocaml 4.07 on janestreet packages and dependents,
>rename them.
> + use package-with-ocaml4.07 when necessary
>- package janestreet packages again, for 4.09
>- replace dependents with a version for 4.09 whenever possible (only
>bap and earley may not be upgradable)
>
>I'll try to do the first three phases tomorrow, and the other two will
>probably take me another week.

Hi, I fixed some of the mess I made yesterday and added ocaml4.07-findlib as 
well as package-with-ocaml4.07. I haven't switched the default ocaml yet, it 
will take me a bit more time.

Re: Guix minor version update?

[Bengt Richter]

Hi,

On +2020-01-21 12:43:26 -0500, Julien Lepiller wrote:
> Le 21 janvier 2020 08:32:00 GMT-05:00, zimoun  a 
> écrit :
> >Dear,
> >
> >Currently, the proposed Guix to install is v1.0.1. This very version
> >has some "bugs" [1] fixed since then [2]. But it is not convenient
> >when using with Docker [3].
> >
> >Why not update the minor version to v1.1?
> >
> >Then, I propose to update this minor version:
> > - each time core-updates or staging is merged
> > - each time the bootstrapping toolchain is updated
> > - each time major archives (Bioconductor) is updated
> > - each time CLI is improved (time-machine, etc.)
> >
> >
> >Ludo "disagrees" [4], kind of. ;-)
> ><<
> >I guess semver doesn’t apply to Guix taken as a whole, so version
> >numbers should be chosen to suggest how “different” the new release is.
> >That’s pretty subjective, though.
> >>>
> >
> >Let collect some ideas. :-)
> >
> >
> >Even if version is not really meaningful when speaking about Guix
> >because rolling etc. I find useful to bump the minor version more
> >often, IMHO, for 3 reasons:
> >
> >1. Changing the (minor) version attracts interest and increases
> >visibility.
> > 2. It helps people --mainly HPC sysadmins-- to better trust "Guix
> >rocks!" because jumping from version to version fits more what they
> >know.
> >3. It eases to navigate through all the packages and their version
> >update.
> >
> >
> >What people think?
> >
> >All the best,
> >simon
> >
> >
> >[1] https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00540.html
> >[2]
> >https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c20ba18304ee63f01895f092bb51bc2a9ce3303b
> >[3] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39195
> >[4] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39195#25
> 
> I agree releases are too far apart, when we have all of these new things to 
> show off to newcomers :)
> 
> Your proposed release cycle seems too short for me, especially since a 
> release is a huge drain on our resources (we try to freeze the distro, fix 
> packages, make sure we retain substitutes for that version "forever", …).
> 
> We should definitely keep releases far from core-updates merges and co. That 
> would ensure we have time to fix the aftermath.
>

BF: How about generating a minimal "guix-maint" release as a binary-installable
guix (guix-maint-install.sh ?) which would install a minimal /gnu/store
like guix-install.sh if no existing /gnu/store, _but either way_ would install
guix-maint as a new generation of guix-maint in its own profile.

The idea is to be able to load a safe minimal and quality-controlled-up-to-date
seed environment (mes-derived?) which can be invoked as a base
for first-time install or later for maintenance or experimentation.

Maybe it could be a safe-mode boot option from grub, to run as something
selected from minimal profile alternatives?

HTH trigger some useful ideas,
even if this is ignorant newbie rambling :)

-- 
Regards,
Bengt Richter

Re: libmediainfo

[sschott]

> Efraim Flashner  hat am 20. Januar 2020 08:35 
> geschrieben:
>
> typo above, it should be /lib/libmediainfo.so.o
> 
> With that change I got 1 test error, related to it trying to download an
> mp4 file from the internet.

Thank you very much! Maybe there is another typo, because 
/lib/libmediainfo.so.0 (zero not o) worked for me?

Re: Parameterized packages

[zimoun]

On Tue, 21 Jan 2020 at 14:13, Pierre Neidhardt  wrote:
>
> zimoun  writes:
>
> >> > --8<---cut here---start->8---
> >> > (define (make-me-a-package option1 option2)
> >> > (package
> >> >   …))
> >> > --8<---cut here---end--->8---
> >>
> >> The ellipsis is a bit vague here.  What is this trying to do?
> >
> > What you wrote below. :-)
>
> ?

--8<---cut here---start->8---
(define (make-me-a-package VIDEO-PLAYER PYTHON-VERSION WITH-FFMPEG)
   (package
[all your "messy" code using stuff]
  ))

(define-public you-get-vlc
(make-me-a-package 'vlc 'python #t))
--8<---cut here---start->8---



> > And my opinion is that you described is already possible (more or
> > less) using 'inherit'. Except the modification of the compiling
> > options (build-system).
>
> The crucial difference is the current approach with inherit /does not
> compose/.  This is where USE flags stand strong because you can tell
> what happens when both flags X and Y are set, e.g.

I do not understand what you do mean by "does not compose".


To me, a package is:
"./configure && make && make check && make install"
so I understand why tweak the flags used by "./configure", for example
change "--with-vlc=" from the default 0 to the tuned 1. Or use another
compiling toolchain.
I understand also these flags could require different inputs.

And again from my understanding, this is more or less cover by
'inherit'. Or some macrology should be improved in 'package/inherit'
or in 'records.scm', i.e., something more fine grained when
inheriting.


--8<---cut here---start->8---
(define (make-you-get VIDEO-PLAYER PYTHON-VERSION WITH-FFMPEG)
  (package
 (inherit you-get
#:add-inputs
 `(("PLAYER" ,VIDEO-PLAYER))
   ,@(IF WITH-FFMPEG)
 ;; FOR MULTI-PART AND >=1080P VIDEOS
 `("FFMPEG" ,FFMPEG)
#:replace-arguments ...
   #:add-phase ...
 '(

(define-public you-get-vlc (make-you-get 'vlc))
--8<---cut here---end--->8---


Something like that. And everything is more controlled, i.e., no mess
with global parameters.

What you want to do is: add/remove/replace inputs/arguments so
#:add-inputs, #:remove-native-inputs, etc.

And this composes in the same way function composes. And yes, it
composes explicitly which can be annoying, But implicit composition
will end up to the Gentoo USE flag mess, IMHO.



> >> - To let the user choose which video player to use.  This is a popular
> >>   USE flag on Gentoo (maybe with a different name).
> >
> > What I do not understand is: people who used Gentoo and especially USE
> > flag are saying that it ends with a big mess with broken packages.
> > Therefore, why does Guix want to reproduce the mess?
>
> Because it is extremely powerful: in a simple declaration like "no-X +
> pulseaudio + python3 + gtk2" you can build /your entire system/,
> according to the flags you've set, in just one command.

Hum? but months later your system is broken... so I am not convinced
it is powerful. :-)

It is broken because composing complex system is an hard task. Typing
helps a bit to detect error at compile time (in this case at building
package time) but run-time errors will still remain and it will be
hard time to find them.

Cheers,
simon

Rust bootstrapping TODO

[Danny Milosavljevic]

Hi,

here a list of things we could still do in order to improve the Rust
bootstrapping process.

(1) For all Mozilla Rusts except the latest one, pass
"--disable-docs --disable-compilerdocs" in order to disable building (and
especially TESTING) the docs.  Testing the docs takes a very long time
and no one will ever read the docs of the compilers used for bootstrapping.

For that, we have to find out where these options can be passed.
We use a "./x.py" bootstrapping method so I don't think that the GNU-style
"./configure" ever gets called (or does it?).

(2) Bootstrap rust 1.29.0 directly via mrustc 0.9.
See https://github.com/thepowersgang/mrustc/issues/140 for why that is
currently not working.

(3) Parallelize things again.  In the past I've disabled parts of the
parallel build because of bugs and/or memory constraints, but after (2) we
could check whether they are working now.

(4) Factor out the mrustc bootstrapper into a mrustc-bootstrapped-package
procedure which changes a package in order to use mrustc, including the
phases.  That way, we can easily choose which of the Mozilla Rusts we want
to bootstrap.
Currently, we also have to change the package definition of unrelated packages
(to remove the bootstrapping phases there and replace them by regular phases)
which is not so nice.  That would mean that there are multiple different
mrustc packages at runtime, like mrustc-1.19.0@0.9 and mrustc-1.29.0@0.9--not
sure about the naming.


pgpTddpNFakFU.pgp
Description: OpenPGP digital signature

Re: Build systems and implicit inputs

[zimoun]

Hi Pierre,

On Tue, 21 Jan 2020 at 14:07, Pierre Neidhardt  wrote:
> zimoun  writes:
> > On Tue, 21 Jan 2020 at 11:56, Ludovic Courtès  wrote:

> >> > The solution to your problem in my opinion is simply to expose just the
> >> > right amount of options through #:arguments for all build systems.
> >> > Would that be satisfactory to you?
> >>
> >> I think the issue of tweaking the build system and its implicit inputs
> >> must be addressed separately.  We first need a good API to do that.
> >> When we have it, it’ll be nice and easy to drive it via package
> >> parameters.  :-)
> >
> > Now I have a better understanding about "package parameters", I agree
> > that it is 2 separate stories.
>
> Hmm... but does it have to?  It seems to me that we would gain a lot in
> keeping those parameters general enough and not separate the handling of
> the build system from the rest.  It would be simpler and more powerful.

I do not have a strong opinion. From my understanding, how to pass
arguments to the build system is a story and how to pass arguments to
packages is another one. Roughly speaking, they do not refer to the
same record, to the same functions that digest them, etc.. And I am
not a fan of adding global variables here and there.

Well, I am almost sure that treat them together will end with a big mess. :-)

Cheers,
simon

Re: Guix minor version update?

[Julien Lepiller]

Le 21 janvier 2020 08:32:00 GMT-05:00, zimoun  a 
écrit :
>Dear,
>
>Currently, the proposed Guix to install is v1.0.1. This very version
>has some "bugs" [1] fixed since then [2]. But it is not convenient
>when using with Docker [3].
>
>Why not update the minor version to v1.1?
>
>Then, I propose to update this minor version:
> - each time core-updates or staging is merged
> - each time the bootstrapping toolchain is updated
> - each time major archives (Bioconductor) is updated
> - each time CLI is improved (time-machine, etc.)
>
>
>Ludo "disagrees" [4], kind of. ;-)
><<
>I guess semver doesn’t apply to Guix taken as a whole, so version
>numbers should be chosen to suggest how “different” the new release is.
>That’s pretty subjective, though.
>>>
>
>Let collect some ideas. :-)
>
>
>Even if version is not really meaningful when speaking about Guix
>because rolling etc. I find useful to bump the minor version more
>often, IMHO, for 3 reasons:
>
>1. Changing the (minor) version attracts interest and increases
>visibility.
> 2. It helps people --mainly HPC sysadmins-- to better trust "Guix
>rocks!" because jumping from version to version fits more what they
>know.
>3. It eases to navigate through all the packages and their version
>update.
>
>
>What people think?
>
>All the best,
>simon
>
>
>[1] https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00540.html
>[2]
>https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c20ba18304ee63f01895f092bb51bc2a9ce3303b
>[3] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39195
>[4] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39195#25

I agree releases are too far apart, when we have all of these new things to 
show off to newcomers :)

Your proposed release cycle seems too short for me, especially since a release 
is a huge drain on our resources (we try to freeze the distro, fix packages, 
make sure we retain substitutes for that version "forever", …).

We should definitely keep releases far from core-updates merges and co. That 
would ensure we have time to fix the aftermath.

Re: Rust packaging coordination

[John Soo]

Hi all,

Thanks to Efraim, tokei is in master.

John

Re: G-Expressions and Scope Preservation

[zimoun]

Hi Chris,

My comment is not related at all, just for reference and/or curiosity. :-)
Yesterday night, I "discovered" the Unison language [1] which seems
presenting similar ideas than G-expression. Well, even I am not sure
to understand the both.
And Nix guys seems floating around [2]. ;-)

[1] https://www.unisonweb.org/docs/tour/
[2] https://www.unisonweb.org/docs/faq


I cannot wait for your presentation at FOSDEM. :-)


Cheers,
simon

Guix minor version update?

[zimoun]

Dear,

Currently, the proposed Guix to install is v1.0.1. This very version
has some "bugs" [1] fixed since then [2]. But it is not convenient
when using with Docker [3].

Why not update the minor version to v1.1?

Then, I propose to update this minor version:
 - each time core-updates or staging is merged
 - each time the bootstrapping toolchain is updated
 - each time major archives (Bioconductor) is updated
 - each time CLI is improved (time-machine, etc.)


Ludo "disagrees" [4], kind of. ;-)
<<
I guess semver doesn’t apply to Guix taken as a whole, so version
numbers should be chosen to suggest how “different” the new release is.
That’s pretty subjective, though.
>>

Let collect some ideas. :-)


Even if version is not really meaningful when speaking about Guix
because rolling etc. I find useful to bump the minor version more
often, IMHO, for 3 reasons:

 1. Changing the (minor) version attracts interest and increases visibility.
 2. It helps people --mainly HPC sysadmins-- to better trust "Guix
rocks!" because jumping from version to version fits more what they
know.
 3. It eases to navigate through all the packages and their version update.


What people think?

All the best,
simon


[1] https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00540.html
[2] 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c20ba18304ee63f01895f092bb51bc2a9ce3303b
[3] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39195
[4] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39195#25

Re: Parameterized packages

[Pierre Neidhardt]

zimoun  writes:

>> > --8<---cut here---start->8---
>> > (define (make-me-a-package option1 option2)
>> > (package
>> >   …))
>> > --8<---cut here---end--->8---
>>
>> The ellipsis is a bit vague here.  What is this trying to do?
>
> What you wrote below. :-)

?

> And my opinion is that you described is already possible (more or
> less) using 'inherit'. Except the modification of the compiling
> options (build-system).

The crucial difference is the current approach with inherit /does not
compose/.  This is where USE flags stand strong because you can tell
what happens when both flags X and Y are set, e.g.

--8<---cut here---start->8---
  (if (and X Y)
 ; Do something when we have both X and Y activated.
 ; Else maybe just X, or just Y, or none.
 )
--8<---cut here---end--->8---

>> The point of declaring the parameters in advance is that it allows the
>> user to list all parameters used by a given package.
>
> I bet that the number of broken packages will increase.

Probably.  But if we keep the same standard for the default values of
the parameters, we would keep the same level of quality.  It should be OK.

>> - To let the user choose which video player to use.  This is a popular
>>   USE flag on Gentoo (maybe with a different name).
>
> What I do not understand is: people who used Gentoo and especially USE
> flag are saying that it ends with a big mess with broken packages.
> Therefore, why does Guix want to reproduce the mess?

Because it is extremely powerful: in a simple declaration like "no-X +
pulseaudio + python3 + gtk2" you can build /your entire system/,
according to the flags you've set, in just one command.

Cheers!

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


signature.asc
Description: PGP signature

Re: Build systems and implicit inputs

[zimoun]

Hi Ludo,

On Tue, 21 Jan 2020 at 11:56, Ludovic Courtès  wrote:

> > The solution to your problem in my opinion is simply to expose just the
> > right amount of options through #:arguments for all build systems.
> > Would that be satisfactory to you?
>
> I think the issue of tweaking the build system and its implicit inputs
> must be addressed separately.  We first need a good API to do that.
> When we have it, it’ll be nice and easy to drive it via package
> parameters.  :-)

Now I have a better understanding about "package parameters", I agree
that it is 2 separate stories.


> Currently each build system has ad-hoc keyword parameters to customize
> its implicit inputs: #:python for ‘python-build-system’, #:cmake for
> ‘cmake-build-system’, #:implicit-inputs? for ‘gnu-build-system’, etc.
>
> For each of them, it would be quite easy to provide a procedure that
> takes a list of implicit inputs and returns a .  It may
> not be all that convenient, and perhaps a bit too ad-hoc still.

I was inclined for this option. :-)


> Another option would be to make implicit inputs a field of
> .

Not sure to understand...

> Needs more thought!

...so yes! :-)


Cheers,
simon

Re: Parameterized packages

[zimoun]

Hi,

Thank you for the explanations.

On Mon, 20 Jan 2020 at 19:57, Pierre Neidhardt  wrote:

> > The solution of 2. and 3. seems to write, as Ludo mentioned:
> >
> > --8<---cut here---start->8---
> > (define (make-me-a-package option1 option2)
> > (package
> >   …))
> > --8<---cut here---end--->8---
>
> The ellipsis is a bit vague here.  What is this trying to do?

What you wrote below. :-)


> --8<---cut here---start->8---
> (define-public you-get
>   (package
> (name "you-get")
> (version "0.4.1355")
> (PARAMETERS VIDEO-PLAYER PYTHON-VERSION WITH-FFMPEG)
> (source (origin
>   (method git-fetch)
>   (uri (git-reference
> (url "https://github.com/soimort/you-get.git;)
> (commit (string-append "v" version
>   (file-name (git-file-name name version))
>   (sha256
>(base32
> "0xq7z04hvw3b3npiahlpzhbxsjvam9n9dynplyrkn84dx6k9ajbj"
> (build-system python-build-system)
> (inputs
>  `(("PLAYER" ,(DEREF-PARAM VIDEO-PLAYER))
>,@(IF (DEREF-PARAM WITH-FFMPEG)
>  ;; FOR MULTI-PART AND >=1080P VIDEOS
>  `("FFMPEG" ,FFMPEG)
>  '(
> (arguments
>  `(#:PYTHON ,(DEREF-PARAM PYTHON-VERSION)
>#:phases
>(modify-phases %standard-phases
>  ,(WHEN (DEREF-PARAM WITH-FFMPEG)
> (add-after 'unpack 'qualify-input-references
>   ;; Explicitly invoke the input ffmpeg, instead of whichever one
>   ;; happens to be in the user's $PATH at run time.
>   (lambda* (#:key inputs #:allow-other-keys)
> (let ((ffmpeg (string-append (assoc-ref inputs "ffmpeg")
>  "/bin/ffmpeg")))
>   (substitute* "src/you_get/processor/ffmpeg.py"
> ;; Don't blindly replace all occurrences of ‘'ffmpeg'’: 
> the
> ;; same string is also used when sniffing ffmpeg's output.
> (("(FFMPEG == |\\()'ffmpeg'" _ prefix)
>  (string-append prefix "'" ffmpeg "'")))
>   #t
>  (ADD-AFTER 'UNPACK 'TWEAK-PLAYER-SETTINGS
>(LAMBDA* (#:KEY INPUTS #:ALLOW-OTHER-KEYS)
>  (MATCH ,(DEREF-PARAM VIDEO-PLAYER)
>(VLC
> ;; DO SOMETHING WITH VLC.
> )
>(MPV
> ;; DO SOMETHING WITH MPV.
> )
>(_
> ;; ERROR OUT?
> )
>#:tests? #f)); XXX some tests need Internet access
> (synopsis "Download videos, audio, or images from Web sites")
> (description
>  "You-Get is a command-line utility to download media contents (videos,
> audio, images) from the Web.  It can use either mpv or vlc for playback.")
> (home-page "https://you-get.org/;)
> (license license:expat)))
> --8<---cut here---end--->8---
>
> In the above I've highlighted the changes in uppercase.

Welcome in a big and unmaintainable mess! :-)


And my opinion is that you described is already possible (more or
less) using 'inherit'. Except the modification of the compiling
options (build-system).


> On line (PARAMETERS ...) I've declared which parameters I'm going to use
> in my package declaration.  Those parameters must be defined globally
> somewhere in Guix.

This will end up with a big and unmaintainable mess, IMHO.


> The point of declaring the parameters in advance is that it allows the
> user to list all parameters used by a given package.

I bet that the number of broken packages will increase.



> - To let the user choose which video player to use.  This is a popular
>   USE flag on Gentoo (maybe with a different name).

What I do not understand is: people who used Gentoo and especially USE
flag are saying that it ends with a big mess with broken packages.
Therefore, why does Guix want to reproduce the mess?


All the best,
simon

Build systems and implicit inputs

[Ludovic Courtès]

Hi!

Pierre Neidhardt  skribis:

> But as I understand it, all the "configurable part" of the builder is
> expose through the #:arguments field.  A simple example of this is
> python: the python-build-system has an argument which allows the package
> to specify whether we use python-2 or python-3.
>
> In this case, it's trivial to use parameters to influence which compiler
> the build system will use.
>
> For gnu-build-system (with gcc, clang, etc.) we can probably do similar
> things already by setting CC.
>
> The solution to your problem in my opinion is simply to expose just the
> right amount of options through #:arguments for all build systems.
> Would that be satisfactory to you?

I think the issue of tweaking the build system and its implicit inputs
must be addressed separately.  We first need a good API to do that.
When we have it, it’ll be nice and easy to drive it via package
parameters.  :-)

Currently each build system has ad-hoc keyword parameters to customize
its implicit inputs: #:python for ‘python-build-system’, #:cmake for
‘cmake-build-system’, #:implicit-inputs? for ‘gnu-build-system’, etc.

For each of them, it would be quite easy to provide a procedure that
takes a list of implicit inputs and returns a .  It may
not be all that convenient, and perhaps a bit too ad-hoc still.

Another option would be to make implicit inputs a field of
.

Needs more thought!

Ludo’.

Re: Parameterized packages

[Ludovic Courtès]

Hi,

ison  skribis:

> Just a thought, but could this be achieved using Guile's parameterization
> feature?
> https://www.gnu.org/software/guile/manual/html_node/Parameters.html

I don’t think so: these “parameters” (I like to write “SRFI-39
parameters” to avoid confusion, which refers to
) have little to do with
the kind of parameters discussed here.

Ludo’.

Re: Inverted index to accelerate guix package search

[Ludovic Courtès]

Hello!

Arun Isaac  skribis:

>> What is not clear to me right now in both implementations are.
>>
>> 1.
>> How to update the index.
>> Give a look at the "pull" code and the ~/.cache/guix folder.
>
> We don't "update" the index. At every guix pull we create it
> anew. Currently, generate-package-cache in gnu/packages.scm does
> this. generate-package-cache is called by package-cache-file in
> guix/channels.scm. package-cache-file is a channel profile hook listed
> under %channel-profile-hooks.

Indeed.

To build the search index, you could add another hook in there.  But
note that it would have to be either fast or substitutable (the latter
is tricky because people can have arbitrary sets of channels).

> Now, what I am unclear about is how to test my sqlite index building
> code without actually pushing to master and running a guix pull. I will
> go through the various tests in Guix and see if I can figure something
> out, but any pointers would be much appreciated.

You could write a hook similar to ‘generate-package-cache’ and commit it
locally.  Then you can run:

  ./pre-inst-env guix pull --url=$PWD --branch=the-right-branch -p /tmp/test

(You need ./pre-inst-env so that the hook actually runs.)

Thanks to both of you for working on it!

Ludo’.

Re: TeX Live 2019 wanted

[Marco van Hulten]

On 17 Jan 09:53 Ricardo Wurmus wrote:
> Mikhail Kryshen  writes:
> 
> > - font files are missing from texlive-latex-lh (shouldn't it be
> > called texlive-lh?).  
> 
> Thank you, that’s a good one.  Generally, the texlive-latex-* packages
> are of the old type that may very well be incomplete.  I’ll replace
> this one with texlive-lh which will include all the source files as it
> should.

TeX Live is a full TeX distribution that includes TeX and variants as
well as the macro packages LaTeX and ConTeXt.  lh is LaTeX-specific, I
think.

It could be fine if any CTAN package is included in TeX Live as
"texlive-PACKAGENAME"; just wondering if this is done consistently and
with good reason.

—Marco

Re: Maintaining Jami #3

[Pierre Neidhardt]

Jan  writes:

> I didn't really answer your questions earlier, sorry.
>
> On Sun, 19 Jan 2020 10:20:51 +0100
> Pierre Neidhardt  wrote:
>
>> Hi Jan,
>> 
>> I tested the Jami package we have in upstream Guix:
>> 
>> - It fails to start on my desktop, it only works on my laptop.
> What do you mean by desktop, is it even a difference for the OS and the
> application?

I have a desktop computer and a laptop.  Both running a mostly identical
Guix system.
The hardware is different; in particular, the desktop does not have a
mic or a camera, if that matters.

>> - The client kept disconnecting.  I could send a few text messages
>> here and there, but most of them didn't go through.
> For me it works, I test it in my local network though. The problem
> begins when you try communicating with someone behind a strong NAT,
> firewall or a badly configured network. Based on my previous experience
> I think that's normal - it have never worked well enough, because ISPs
> don't want you to have control over your networking - client-server
> applications work well, but p2p are broken. Often router firmware is
> buggy, outdated and malicious as nonfree software is.

I've tried between my laptop and an Android.  Both were on the local network.

>> - I can receive calls, but when I click on the "pick up" button, Jami
>>   crashes.
> Maybe its something hardware specific or depends on the client you call
> with - I have no problem answering calls made from Android.
>> In general, Jami crashed _a lot_.  I wonder if it's upstream or if we
>> have something wrong with our package.
>> 
>> Did you have a similar experience?
>> Does your work fix any of those issues?
>> 
>
> I tested 20200115 version now, and it pretty much works the same.
> Anyway I fixed my private branch and can continue working, but see no
> point in waiting.
>
> What DE are you using? I could try it on my machine.

I run EXWM.

> If you run it on top of Wayland, then you should know Jami is
> currently broken on Wayland, they work on fixing it. Aaaand even if
> client-gnome will continue being broken like this, they're working on
> porting client-windows(Qt) to GNU/Linux and there's a possibility it
> won't be broken as well.

That'd be interesting.

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


signature.asc
Description: PGP signature

Re: Parameterized packages

[Pierre Neidhardt]

ison  writes:

> Just a thought, but could this be achieved using Guile's parameterization
> feature?
> https://www.gnu.org/software/guile/manual/html_node/Parameters.html
>
> Not sure which method will be best overall, but its something to consider
> and might avoid the need to define a bunch of extra functions. So basically
> all standard parameters could be defined globally using make-parameter, then
> in the parameters field of the package it lists the parameters they want
> which will pick up the default values, or be overridden by parameterization.
>
> Although I wonder if maybe it's better to not use global defaults for the
> parameters and just let packages set their own defaults?

Actually I don't know.  An important feature of package parameters / USE
flags is typing.  But Guile does not have much support for typing as far
as know.  So if we need to implement some sort of typing in Guile, what
we could do is create a Guile record with the following fields:

- value
- predicate

The value should not be accessible directly, instead we need some
function that will reference the value by first applying the predicate
on it and throw an error if it returns #f.  This way we can enforce some
run-time typing.  Not ideal but that could work.  Any better option?

Typed/Racket would be great here :)

Otherwise, we can ditch the typing and use Guile parameters as you suggested.

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


signature.asc
Description: PGP signature

Re: [bug#39028] [PATCH 5/7] gnu: python-cryptography: Update to 2.8

[Lars-Dominik Braun]

Hi,

> Hello Braun, I have pushed the previous 4 patches into master, thank you!
thanks.

> This is not a small change for me, as 'guix refresh -l python-cryptography' 
> says:
>   Building the following 167 packages would ensure 367 dependent packages are 
> rebuilt...
True, I did not check that, my bad. Would it be acceptable to package an older
version of asyncssh compatible with python-cryptography 2.7?

> And I'm not sure about disable tests in python-pyopenssl (in the next
> patch), maybe we should update it to 19.1.0.
Nope, does not fix these three testcases for me.

Lars