Re: Introducing myself

[Timothy Sample]

Hi Jakob,

Welcome!

"Jakob L. Kreuze"  writes:

> Hello, guix-devel!
>
> My name is Jakob L. Kreuze, and I was accepted into Google's Summer of
> Code program this year to work on "guix deploy," the deployment
> automation tool for GuixSD that's been discussed in [1] and [2]. I just
> wanted to briefly introduce myself to the list, as you'll likely be
> seeing postings from me about "guix deploy" on a regular basis.

Woohoo!  I’m looking forward to it.

> Officially, my work doesn't start until the 27th of this month; the next
> few days will be spent ensuring that I have a working development
> environment and familiarizing myself with both the code and the
> development practices of Guix.
>
> I look forward to working with all of you.

I hope you have loads of fun working on Guix.


-- Tim

Re: Introducing myself

[Tobias Geerinckx-Rice]

Jakob,

Welcome aboard!  I like both parts of your e-mail address already.

Jakob L. Kreuze wrote:
My name is Jakob L. Kreuze, and I was accepted into Google's 
Summer of

Code program this year to work on "guix deploy," the deployment
automation tool for GuixSD that's been discussed in [1] and [2].


That's rad.

Kind regards,

T G-R

[1]: 
https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00145.html
[2]: 
https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00114.html




signature.asc
Description: PGP signature

Re: Introducing myself

[Laura Lazzati]

Hi Jakob!

I didn't want to be the first one, but welcome and congratulations :)

I am a former Outreachy intern, and my experience with Guix folks was great,.
I'm sure you will learn and enjoy a lot your internship.

Regards :)
Laura

Re: Video narration

[sirgazil]

 On Fri, 10 May 2019 16:57:11 -0500 Laura Lazzati 
 wrote 

 > Hi Gábor :) 
 >  
 > > I will ask on Monday. 
 > Thank you :) 

For what is worth, they could also be uploaded to https://archive.org/

Re: Video narration

[Laura Lazzati]

Hi!

> Yes.  I think that the total duration of each cli session is now good.
> However, there may be improvements in a few places to further
> synchronize the narration with the screen output.
>
> For example, if a particular output is displayed slightly ahead of the
> narration one could add some extra sleep before the section and remove
> the same amount after.
>
> That way the total duration, of each session, will stay the same.
Great! It was what I understood but wanted to check it :)


Regards :)
Laura

Re: Video narration

[Paul Garlick]

Hi Laura,

> Could you re-build the other videos and check the internal timings?
> This is the fine adjustment that synchronizes the audio with the
> command line output.
> By this, do you  mean checking that the audio matches the video,
> taking into account that if I have to add some silence in between I
> have to remove the same amount of time somewhere else?

Yes.  I think that the total duration of each cli session is now good. 
However, there may be improvements in a few places to further
synchronize the narration with the screen output.  

For example, if a particular output is displayed slightly ahead of the
narration one could add some extra sleep before the section and remove
the same amount after.

That way the total duration, of each session, will stay the same.

Best regards,

Paul.

Introducing myself

[Jakob L. Kreuze]

Hello, guix-devel!

My name is Jakob L. Kreuze, and I was accepted into Google's Summer of
Code program this year to work on "guix deploy," the deployment
automation tool for GuixSD that's been discussed in [1] and [2]. I just
wanted to briefly introduce myself to the list, as you'll likely be
seeing postings from me about "guix deploy" on a regular basis.

Officially, my work doesn't start until the 27th of this month; the next
few days will be spent ensuring that I have a working development
environment and familiarizing myself with both the code and the
development practices of Guix.

I look forward to working with all of you.

Jakob

[1]: https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00145.html
[2]: https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00114.html


signature.asc
Description: Digital signature

Re: 01/01: guix: Simplify and robustify lzread!.

[Ludovic Courtès]

Heya,

Pierre Neidhardt  skribis:

> guix: Simplify and robustify lzread!.
   ^
 Should be lzlib.
>>>
>>> Oops!
>>> I must confess that I never really understood the whole logic behind
>>> GNU-style commit message :p
>>
>> It’s really Guix-specific here, but the idea is that the word before
>> colon indicates the part of the code being modified, to provide a bit of
>> context.
>
> That makes sense.  Where it makes less sense to me is when we prefix
> with "gnu:" for packages.  Why GNU?  Why not "packages:"?

Historical reasons.  :-)  Once upon a time that was “distro:”…

> No bug on an actual use case.  I kept discussing with Antonio and he
> pointed out the potential issue.  The solution occurred to me on a fresh
> sunny morning :D

Good.  :-)

>> (I’m super cautious here but that’s because I spent countless hours
>> debugging code that used zlib and libbz2 and lzo in the past.  :-))
>
> Yup, tell me about it...  Took me weeks just to figure out basic
> (de)compression ;)
>
> But now that I have a better understanding of the library, I'm much more
> confident about the robustness and debugability of the bindings.  Once
> things start adding up in your head, it's much more straightforward to
> see what goes wrong and how to fix it.  (Stating the obvious here, but
> that's only true with good libraries, and lzlib is a good one.)

Alright, sounds good!

Thank you,
Ludo’.

Re: X/GDM fails on linux 5.0.7 AMD Radeon RX 580 after system reconfigure

[ison]

On Fri, May 10, 2019 at 02:11:48PM +0200, Marius Bakke wrote:
> Can you try to delete "$HOME/.cache/mesa_shader_cache/" and see if see
> if it makes a difference?

That did it! At least for the user installed applications I was testing with it 
seems to have resolved the issue.
I also deleted the other cache you mentioned, at: 
/var/lib/gdm/.cache/mesa_shader_cache
and will now try to do a full system upgrade and see if everything is working.

Thanks for the help.

Re: Video narration

[Gábor Boskovits]

Hello!

Laura Lazzati  ezt írta (időpont: 2019. máj.
9., Cs, 16:58):

> Hi Paul!
>
> On Wed, May 8, 2019 at 8:14 PM Paul Garlick
>  wrote:
> >
> > Hi Laura,
> >
> > > Now I am generating all the videos and will be pushing the changes
> > > asap.
> >
> > Great stuff.
> >
> > I have made a start, setting the durations for the first three videos.
> > If you pull the changes you can check the inner timings as well.  The
> > sum of the sleep commands should now be correct for these videos.
> >
> > I plan to finish the coarse level sleep settings for the remaining
> > videos in the next few days.
> Oh, I was working on the timing of the cli session files too, after
> pulling I see the only one that needs to be finished is 04-packaging3.
> Would you like me to adjust it? I will be also testing the previous
> ones to check everything is fine :)
>
> Gábor, is your client still offering their storage to upload the
> videos there so that the community can see them, give their opinion
> and so on without having to spend time generating them?
>
> I will ask on Monday.


> Regards :)
> Laura
>

Best regards,
g_bor

Re: pypi URL 404

[Jack Hill]

Thanks for your reply

On Fri, 10 May 2019, Marius Bakke wrote:


It seems no proper source tarball is available on PyPI, only a "wheel":



The importer uses those to extract requirements.txt, and apparently
returns the wheel hash when it fails to find a proper source.  That is
probably a bug.


I've opened #35673 about that: https://issues.guix.gnu.org/issue/35673


In this case it is probably easiest to download the source from the
upstream repository, or ask the maintainer to upload a tarball.


I'll adjust the source location. I've also asked upstream to upload a 
tarball: http://projectmallard.org/pipermail/mallard-list/2019-May/000287.html


Best,
Jack

Re: pypi URL 404

[Marius Bakke]

Jack Hill  writes:

> Hi Guix,
>
> I've created the following package definition using the pypi importer. 
> However, when I try to build it with guix build -f … the build fails 
> because it cannot download the source. The downloader gets redirected to a 
> url that returns 404. However, the pypi importer was able download the 
> source.

It seems no proper source tarball is available on PyPI, only a "wheel":



The importer uses those to extract requirements.txt, and apparently
returns the wheel hash when it fails to find a proper source.  That is
probably a bug.

In this case it is probably easiest to download the source from the
upstream repository, or ask the maintainer to upload a tarball.


signature.asc
Description: PGP signature

Re: Help with match

[swedebugia]

On 2019-05-10 15:53, Timothy Sample wrote:
> My guess is that you don’t mean to have that “dependencies” symbol
> in the input.
> 
> I was just about to send this, but there’s another issue!  The
> “synopsis-line” form has five elements, but the pattern “(_ val)” will
> only match a two-element list.  Should the “An async HTTP client” part
> should be a string?
> 
> Hope that helps and good luck with the importer!

Thanks a lot for looking at this. 

After writing this email I realized I need to change the peg-patterns to
1) output a string for multiple output
2) match the structure metadata-ref procedure in opam.scm so I dont have
to fiddle with the matcher.

The parsing of asd-files has proven to be a big challenge because of the
diversity of the files (tabs, spaces, different prefix, etc.)
-- 
Cheers Swedebugia



signature.asc
Description: OpenPGP digital signature

pypi URL 404

[Jack Hill]

Hi Guix,

I've created the following package definition using the pypi importer. 
However, when I try to build it with guix build -f … the build fails 
because it cannot download the source. The downloader gets redirected to a 
url that returns 404. However, the pypi importer was able download the 
source.


Package definition produced by the importer:

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

(package
  (name "python-mallard-ducktype")
  (version "1.0.1")
  (source
(origin
  (method url-fetch)
  (uri (pypi-uri "mallard-ducktype" version))
  (sha256
(base32
  "04mjj8apzm0cb4vk73vydgfiw8cyznfy3zrb99xs9d2k8x7cxc99"
  (build-system python-build-system)
  (home-page "")
  (synopsis
"Parse Ducktype files and convert them to Mallard.")
  (description
"Parse Ducktype files and convert them to Mallard.")
  (license license:expat))


guix build -f ducktype.scm output:

substituting 
/gnu/store/wc83b7yhng8kd937y9z3nq5xlyibshiv-module-import-compiled...
downloading from 
https://ci.guix.gnu.org/nar/gzip/wc83b7yhng8kd937y9z3nq5xlyibshiv-module-import-compiled...
 module-import-compiled  258KiB 
  4.8MiB/s 00:00 [##] 100.0%

building 
/gnu/store/6yn25vcf1kym9l22gfx404rd5grq0pm5-mallard-ducktype-1.0.1.tar.gz.drv...

Starting download of 
/gnu/store/mmppbk4y3y38zabg295c89ifdxx7lfgs-mallard-ducktype-1.0.1.tar.gz

From 
https://pypi.org/packages/source/m/mallard-ducktype/mallard-ducktype-1.0.1.tar.gz...

following redirection to 
`https://files.pythonhosted.org/packages/source/m/mallard-ducktype/mallard-ducktype-1.0.1.tar.gz'...
download failed 
"https://files.pythonhosted.org/packages/source/m/mallard-ducktype/mallard-ducktype-1.0.1.tar.gz;
 404 "Not Found"

Starting download of 
/gnu/store/mmppbk4y3y38zabg295c89ifdxx7lfgs-mallard-ducktype-1.0.1.tar.gz

From 
https://mirror.hydra.gnu.org/file/mallard-ducktype-1.0.1.tar.gz/sha256/04mjj8apzm0cb4vk73vydgfiw8cyznfy3zrb99xs9d2k8x7cxc99...

download failed 
"https://mirror.hydra.gnu.org/file/mallard-ducktype-1.0.1.tar.gz/sha256/04mjj8apzm0cb4vk73vydgfiw8cyznfy3zrb99xs9d2k8x7cxc99;
 404 "Not Found"

Starting download of 
/gnu/store/mmppbk4y3y38zabg295c89ifdxx7lfgs-mallard-ducktype-1.0.1.tar.gz

From 
https://berlin.guixsd.org/file/mallard-ducktype-1.0.1.tar.gz/sha256/04mjj8apzm0cb4vk73vydgfiw8cyznfy3zrb99xs9d2k8x7cxc99...

download failed 
"https://berlin.guixsd.org/file/mallard-ducktype-1.0.1.tar.gz/sha256/04mjj8apzm0cb4vk73vydgfiw8cyznfy3zrb99xs9d2k8x7cxc99;
 404 "Not Found"

Starting download of 
/gnu/store/mmppbk4y3y38zabg295c89ifdxx7lfgs-mallard-ducktype-1.0.1.tar.gz

From 
https://tarballs.nixos.org/sha256/04mjj8apzm0cb4vk73vydgfiw8cyznfy3zrb99xs9d2k8x7cxc99...

download failed 
"https://tarballs.nixos.org/sha256/04mjj8apzm0cb4vk73vydgfiw8cyznfy3zrb99xs9d2k8x7cxc99; 
404 "Not Found"

Starting download of 
/gnu/store/mmppbk4y3y38zabg295c89ifdxx7lfgs-mallard-ducktype-1.0.1.tar.gz

From 
https://archive.softwareheritage.org/api/1/content/sha256:29b1ce4e4753b4a47b4a2bffe19dfd9e211edd6b7e8f3337590cd47f1592b212/raw/...

download failed 
"https://archive.softwareheritage.org/api/1/content/sha256:29b1ce4e4753b4a47b4a2bffe19dfd9e211edd6b7e8f3337590cd47f1592b212/raw/;
 404 "Not Found"
failed to download 
"/gnu/store/mmppbk4y3y38zabg295c89ifdxx7lfgs-mallard-ducktype-1.0.1.tar.gz" from 
"https://pypi.org/packages/source/m/mallard-ducktype/mallard-ducktype-1.0.1.tar.gz;
builder for 
`/gnu/store/6yn25vcf1kym9l22gfx404rd5grq0pm5-mallard-ducktype-1.0.1.tar.gz.drv' 
failed to produce output path 
`/gnu/store/mmppbk4y3y38zabg295c89ifdxx7lfgs-mallard-ducktype-1.0.1.tar.gz'
build of 
/gnu/store/6yn25vcf1kym9l22gfx404rd5grq0pm5-mallard-ducktype-1.0.1.tar.gz.drv 
failed
View build log at 
'/var/log/guix/drvs/6y/n25vcf1kym9l22gfx404rd5grq0pm5-mallard-ducktype-1.0.1.tar.gz.drv.bz2'.
cannot build derivation 
`/gnu/store/84i5773gkrmkbynzm51nn655iy9j2n67-python-mallard-ducktype-1.0.1.drv':
 1 dependencies couldn't be built
guix build: error: build of 
`/gnu/store/84i5773gkrmkbynzm51nn655iy9j2n67-python-mallard-ducktype-1.0.1.drv' 
failed


Best,
Jack

New Spanish PO file for 'guix-manual' (version 1.0.0-pre3)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix-manual' has been submitted
by the Spanish team of translators.  The file is available at:

https://translationproject.org/latest/guix-manual/es.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/guix-manual/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/guix-manual.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

[PATCH] download: Support 'https_proxy'.

[宋文武]

Hello, this patch add 'https_proxy' to 'guix download' (and guix-daemon
if we update guix?):

>From 424da6e43ba9c928403e3fd9b42e75d0fe90fc23 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Fri, 10 May 2019 21:27:40 +0800
Subject: [PATCH] download: Support 'https_proxy'.

* guix/build/download.scm (setup-http-tunnel): New procedure.
(open-connection-for-uri): Honor the 'https_proxy' environment variable.
---
 guix/build/download.scm | 28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/guix/build/download.scm b/guix/build/download.scm
index a64e0f0bd3..92cef76dff 100644
--- a/guix/build/download.scm
+++ b/guix/build/download.scm
@@ -380,6 +380,20 @@ ETIMEDOUT error is raised."
   (apply throw args)
   (loop (cdr addresses
 
+(define (setup-http-tunnel port uri)
+  "Establish a tunnel to the destination server of URI."
+  (define target
+(string-append (uri-host uri) ":"
+   (number->string
+(or (uri-port uri)
+(match (uri-scheme uri)
+  ('http 80)
+  ('https 443))
+  (format port "CONNECT ~a HTTP/1.1\r\n" target)
+  (format port "Host: ~a\r\n\r\n" target)
+  (force-output port)
+  (read-response port))
+
 (define* (open-connection-for-uri uri
   #:key
   timeout
@@ -393,21 +407,20 @@ VERIFY-CERTIFICATE? is true, verify HTTPS server certificates."
   (define https?
 (eq? 'https (uri-scheme uri)))
 
+  (define https-proxy (let ((proxy (getenv "https_proxy")))
+(and (not (equal? proxy ""))
+ proxy)))
+
   (let-syntax ((with-https-proxy
 (syntax-rules ()
   ((_ exp)
;; For HTTPS URIs, honor 'https_proxy', not 'http_proxy'.
-   ;; FIXME: Proxying is not supported for https.
(let ((thunk (lambda () exp)))
  (if (and https?
   (module-variable
(resolve-interface '(web client))
'current-http-proxy))
- (parameterize ((current-http-proxy #f))
-   (when (and=> (getenv "https_proxy")
-(negate string-null?))
- (format (current-error-port)
- "warning: 'https_proxy' is ignored~%"))
+ (parameterize ((current-http-proxy https-proxy))
(thunk))
  (thunk)))
 (with-https-proxy
@@ -415,6 +428,9 @@ VERIFY-CERTIFICATE? is true, verify HTTPS server certificates."
;; Buffer input and output on this port.
(setvbuf s 'block %http-receive-buffer-size)
 
+   (when https-proxy
+ (setup-http-tunnel s uri))
+
(if https?
(tls-wrap s (uri-host uri)
  #:verify-certificate? verify-certificate?)
-- 
2.19.2



Some problems and questions:

- It assumes ‘https_proxy’ is ‘http://PROXY-SERVER:PORT’, if the scheme
  part is missing, it fail.

- It fails some servers (eg: www.google.com) for me while curl works...

- I think this should go into guile’s ‘(web client)’ module?

New Russian PO file for 'guix-manual' (version 1.0.0-pre3)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix-manual' has been submitted
by the Russian team of translators.  The file is available at:

https://translationproject.org/latest/guix-manual/ru.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/guix-manual/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/guix-manual.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: Help with match

[Timothy Sample]

Hi swedebugia,

swedebugia  writes:

> Hi
>
> I am almost finished with the quicklisp importer but I'm stuck with not
> being able to match what I want with the pattern matcher.
>
> I (still) don't understand the documentation for this matcher and I
> can't get it to do what I want it seems :/

Here’s your input form:

'(asd-record
  (license-line (text-until-dq MIT))
  (synopsis-line (text-until-dq An async HTTP client))
  dependencies
  (dependencies (text alexandria))
  (dependencies (text babel))
  (dependencies (text fast-io))
  (dependencies (text cl-async))
  (dependencies (text blackbird))
  (dependencies (text quri))
  (dependencies (text fast-http))
  (dependencies (text fast-io))
  (dependencies (text cl-async-ssl))
  (dependencies (text cl-cookie))
  (dependencies (text file)))

The pattern you use is “('asd-record (who (_ val)) ...)”.  The reason it
doesn’t match is because not all elements after the symbol “asd-record”
have the form “(who (_ val))” (the failing element is the one that is
just the symbol “dependencies”).  The ellipsis means that all of the
remaining elements have to match the previous pattern.

My guess is that you don’t mean to have that “dependencies” symbol
in the input.

I was just about to send this, but there’s another issue!  The
“synopsis-line” form has five elements, but the pattern “(_ val)” will
only match a two-element list.  Should the “An async HTTP client” part
should be a string?

Hope that helps and good luck with the importer!


-- Tim

Re: X/GDM fails on linux 5.0.7 AMD Radeon RX 580 after system reconfigure

[Pierre Neidhardt]

OK, thanks for the tip!  Will do when I'm back on Tuesday.

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


signature.asc
Description: PGP signature

Re: X/GDM fails on linux 5.0.7 AMD Radeon RX 580 after system reconfigure

[Marius Bakke]

Pierre Neidhardt  writes:

> Hmm, not sure it's related to user data since GDM fails to display.

Also try to `rm -rf /var/lib/gdm/.cache/mesa_shader_cache`.


signature.asc
Description: PGP signature

Re: X/GDM fails on linux 5.0.7 AMD Radeon RX 580 after system reconfigure

[Marius Bakke]

ison  writes:

> Sorry I neglected to mention that I actually tried upgrading mesa earlier and 
> it
> didn't resolve the problem. Neither upgrading mesa (I tried 18.3.6 and some 
> 19.*
> version) nor downgrading (back to 18.3.1) would fix it, all rebuilds still
> resulted in artifacts. I suppose it's because the dependency on llvm 7 
> remained
> fixed during all the rebuilds.
>
> I also just tried llvm 8.0.0 and it still had the same issue.

Can you try to delete "$HOME/.cache/mesa_shader_cache/" and see if see
if it makes a difference?


signature.asc
Description: PGP signature

Re: X/GDM fails on linux 5.0.7 AMD Radeon RX 580 after system reconfigure

[Boris A. Dekshteyn]

Pierre Neidhardt  writes:

> Hi,
>
> My last system reconfigure dates back to April 17th and works
> flawlessly.
> Yesterday I ran a new one and X / GDM don't start up properly:
>
> - I can guess bits and pieces of the GDM interface but the screen is
>   torn asunder by the most epic artifacts (green / purple flashing tiles).
>
> - In a TTY, I see that GDM is restarting in an infinite loop.
>
> - dmesg reports some "corruption" at the level of the video card (AMD
>   Radeon RX 580).
>
> The weird thing is that I'm still using Linux 5.0.7 like I was on April
> 17th and everything worked well.
>
> I've tried both with linux-libre and a custom kernel.
>
> Have we changed anything to the boot parameters maybe?
>
>
> Side question: how do we know which Guix commit was used for a specific
> system generation?  For now the only way I can think of is
>
> /var/guix/profiles/system-17-link/profile/bin/guix --version
>
> Anything more convenient?  From Emacs Guix?

See bug#35575. If you have the same symptoms, the problem is most likely
that mesa does not check its shader cache. Working solution - clear
$HOME/.cache/mesa_shader_cache/

-- 
WBR, Boris Dekshteyn

Help with match

[swedebugia]

Hi

I am almost finished with the quicklisp importer but I'm stuck with not
being able to match what I want with the pattern matcher.

I (still) don't understand the documentation for this matcher and I
can't get it to do what I want it seems :/

-- 
Cheers Swedebugia
scheme@(guile-user) [8]> (let ((l '(asd-record (license-line (text-until-dq 
MIT)) (synopsis-line (text-until-dq An async HTTP client)) dependencies 
(dependencies (text alexandria)) (dependencies (text babel)) (dependencies 
(text fast-io)) (dependencies (text cl-async)) (dependencies (text blackbird)) 
(dependencies (text quri)) (dependencies (text fast-http)) (dependencies (text 
fast-io)) (dependencies (text cl-async-ssl)) (dependencies (text cl-cookie)) 
(dependencies (text file)
   (match l   ;; <- the input object
 (('asd-record (who (_ val)) ...)  ;; <- the pattern
  who)))  ;; <- the expression evaluated upon matching
:170:23: Throw to key `match-error' with args `("match" "no 
matching pattern" (asd-record (license-line (text-until-dq MIT)) (synopsis-line 
(text-until-dq An async HTTP client)) dependencies (dependencies (text 
alexandria)) (dependencies (text babel)) (dependencies (text fast-io)) 
(dependencies (text cl-async)) (dependencies (text blackbird)) (dependencies 
(text quri)) (dependencies (text fast-http)) (dependencies (text fast-io)) 
(dependencies (text cl-async-ssl)) (dependencies (text cl-cookie)) 
(dependencies (text file'.

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [9]> (let ((l '(asd-record (license-line (text-until-dq 
MIT)
   (match l   ;; <- the input object
 (('asd-record (who (_ val)) ...)  ;; <- the pattern
  who)))  ;; <- the expression evaluated upon matching
$5 = (license-line)


signature.asc
Description: OpenPGP digital signature

Re: X/GDM fails on linux 5.0.7 AMD Radeon RX 580 after system reconfigure

[Pierre Neidhardt]

Thanks for investigating this!

So does anyone know if there is a good reason to keep llvm 7 for Mesa?
Was it just updated for the sake of updating?  (Which is usually a good
reason, admittedly :p)

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


signature.asc
Description: PGP signature

Re: Linting, and how to get the information in to the Guix Data Serivce

[Christopher Baines]

Ludovic Courtès  writes:

> Hello!
>
> Christopher Baines  skribis:
>
>> Christopher Baines  writes:
>>
>>> I've never worked with this part of Guix before, and some of it is quite
>>> complex, so I've started by attempting to do the first bit, storing
>>> warnings as data before outputting them. I've attached a patch.
>
> Providing more structure sounds like a good idea to me (though in the
> end it’s still just text; not sure if that’s good enough for what you
> had in mind?).

Great, I'm also not entirely sure what would be best, but I think having
the package and location as the record values, along with the message is
a good start.

> From a UI viewpoint, it’s important that ‘guix lint’ prints warning as
> they come, rather than eat CPU for some time and eventually spit out
> everything at once.

So, currently this does change the behaviour, but I'm hoping it's still
ok. The warnings will be printed after running each checker. So if there
are checkers that take a long time, and possibly report multiple
warnings, then that could be an issue, but I don't believe this is the
case.

>> From cd16443893afdacf9f3e4d8256cc943a5928aed4 Mon Sep 17 00:00:00 2001
>> From: Christopher Baines 
>> Date: Mon, 6 May 2019 19:00:58 +0100
>> Subject: [PATCH] scripts: lint: Handle warnings with a record type.
>>
>> Rather than emiting warnings directly to a port, have the checkers return the
>> warning or warnings.
>>
>> This makes it easier to use the warnings in different ways, for example,
>> loading the data in to a database, as you can work with the 
>> records directly, rather than having to parse the output to determine the
>> package and location.
>
> [...]
>
>> +(define-record-type* 
>> +  lint-warning make-lint-warning
>> +  lint-warning?
>> +  (package  lint-warning-package)
>> +  (message  lint-warning-message)
>> +  (location lint-warning-field
>> +(default #f)))
>
> It could be useful to have a ‘checker’ field linking to the checker that
> produced the warning.

Good point. Any suggestions on how to do this? At the moment, the
checker values don't really have names, they're just in a list. I could
move the definitions out of the list, and define them at the top level
like packages. Another option I was possibly considering is populating
the checker field after the warnings are returned from the checker
function... any thoughts?

>>(define (check-not-empty description)
>>  (when (string-null? description)
>> -  (emit-warning package
>> +  (make-warning package
>>  (G_ "description should not be empty")
>> -'description)))
>> +#:field 'description)))
>
> This procedure returns either a warning or the unspecified value, which
> is probably not intended?  I suppose a lot of the code is currently
> written with ‘emit-warning’ in effect position, which will have to be
> changed.

So, it's important that all the generated warnings are returned, so I
changed some checkers to return lists. Also, I added a append-warnings
function which takes 1 or more arguments, and will sort the warnings in
to a neat list. I did consider changing all the checkers to return a
neat list of warnings, but that would require more changes. What do you
think?

> I suppose tests/lint.scm needs to be converted to the new API?

Ah, yep. I've made a start on this now. I think returning
 will make writing the tests easier, which is nice.

Thanks,

Chris


signature.asc
Description: PGP signature