QtTextToSpeech

[Matt]

I'm trying to get Text-To-Speech included within the python-pyqt package.

It looks like the definition is simply missing a declaration for qtspeech 
(patch attached).  I updated the definition, the package builds, and I'm now 
able to import the QtTextToSpeech module.  However, I'm not able to find an 
engine, so I can't verify that it's working 100%.

To validate the new pyqt functionality, I'm trying to get TTS working using the 
python-pyside-2 package.  That definition already has qtspeech included and I 
assume it works.  Unfortunately, I can't get that to work either.

I've installed speech-dispatcher, espeak, espeak-ng, and festival.  I'm able to 
get TTS from the command-line (i.e. spd-say, speak, etc.).  However, no voices 
or engine are found by PyQt or PySide.  I've verified that the same program 
works on a separate Debian machine.  Is there some setup for speech-dispatcher 
that I'm missing?

import sys
from PySide2 import QtCore, QtWidgets, QtTextToSpeech


class MainWindow(QtWidgets.QMainWindow):

def __init__(self):
super().__init__()

self.engine = None
self.engine_name = None

text ='''Every effort has been made to replicate this text as 
faithfully as
possible, including inconsistencies in spelling and hyphenation.  Some
corrections of spelling and punctuation have been made. They are
listed at the end of the text.'''

self.text_edit = QtWidgets.QTextEdit()
self.text_edit.setText(text)

self.speak_button = QtWidgets.QPushButton('Speak once')
self.speak_button.clicked.connect(self.on_speak_button_clicked)

# Central widget
layout = QtWidgets.QVBoxLayout()
layout.addWidget(self.text_edit)
layout.addWidget(self.speak_button)

centralWidget = QtWidgets.QWidget()
centralWidget.setLayout(layout)
self.setCentralWidget(centralWidget)

engineNames = QtTextToSpeech.QTextToSpeech.availableEngines()

if len(engineNames) > 0:
self.engine_name = engineNames[0]
self.engine = QtTextToSpeech.QTextToSpeech(self.engine_name)

voice = self.engine.availableVoices()[0]
self.engine.setVoice(voice)
else:
self.speak_button.setEnabled(False)

def on_speak_button_clicked(self):
text = self.text_edit.toPlainText()
self.engine.say(text)



if __name__ == '__main__':
app = QtWidgets.QApplication(sys.argv)
mainWin = MainWindow()
mainWin.show()
sys.exit(app.exec_())


0001-Add-qtspeech-to-python-pyqt.patch
Description: Binary data

RFC: libgit2 is slow/inefficient; switch to git command?

[Maxim Cournoyer]

Hi,

While attempting to bisect against the Linux kernel tree, the
performance of libgit2 quickly became problematic, to the point where
simply cloning the repo became a multiple hours affair, using upward to
3 GiB of RAM for the clone and indexing of the objects (!)

Given that:

* the git CLI doesn't suffer from such poor performance;
* This kind of performance problem has been known for years in libgit2
  [0] with no fix in sight;
* other projects such as Cargo support using the git CLI and that
  projects are using it for that reason [1];

Would it make sense to switch to use the git command directly instead of
calling into this libgit2 C library that ends up being slower?  It would
provide a hefty speed-up when using 'guix refresh' or building new
packages fetched from git without substitutes, or using 'git-checkout',
etc.

What do you think?

[0] https://github.com/libgit2/libgit2/issues/4674
[1] https://github.com/artichoke/playground/pull/700

-- 
Thanks,
Maxim

Re: bringing npm packages to Guix

[zamfofex]

Hello! Thanks for responding.

The premise of the idea I’m proposing is that it wouldn’t be necessary to 
traverse into (most of) the ‘devDependencies’ if you build the packages ad‐hoc 
using esbuild. So, the idea is to sidestep the build process that the package 
has, and just invoke esbuild on the appropriate files of the package. My hope 
is that this is sufficient to bring most (or at least a lot of) useful packages 
from npm to Guix without the need of a binary importer.

I set up a package for sucrase as a proof of concept, since sucrase is a CLI 
tool that can be run and tried out easily (as opposed to jQuery, which is a 
library meant to be used in browsers). However, note that following my proposed 
approach, packaging jQuery becomes entirely trivial — it is a matter of simply 
running esbuild on jQuery’s input files. For the sake of example, I have 
included a Guix package I created for jQuery in the GitHub Gist I sent above. 
(And I can anecdotally verify that it works when tring it on a browser.) 


I will admit that I cheated a bit, since I used the currently unreleased 4.0.0 
version, as opposed to the latest released 3.x versions, since the realeased 
3.x versions use the old and outdated AMD format (“asynchronous module 
definition”) for representing dependencies between files in a project. (See 
) However, most packages nowadays 
have already moved away from AMD (and jQuery is getting there), so this 
shouldn’t be an issue in practice.

Re: Layout of ‘define-configuration’ records

[Maxim Cournoyer]

Hi,

Ludovic Courtès  writes:

> Hi Maxim,
>
> Maxim Cournoyer  skribis:
>
>> Ludovic Courtès  writes:
>
> [...]
>
 +   (%location #,(id #'stem #'stem #'-location)
 +  (default (and=> (current-source-location)
 +  source-properties->location))
 +  (innate)))
>>>
>>> Moving the field last is problematic as we’ve seen for any user that
>>> uses ‘match’ on records—something that’s not recommended but still used
>>> a lot.
>>
>> Yep.  I had that on mind when I made the change, though I still missed a
>> few occurrences.
>
> [...]
>
>> I wanted match on define-configuration'd fields to be
>> backward-compatible with fields migrated from define-record-type*, so
>> that they such change can be made without worrying breakages.
>
> That had the opposite effect: it introduced breakage precisely because
> existing uses of ‘match’ on records need to be verified manually, one by
> one.

Yes.  C.f. "I missed a few occurrences" above :-).

> That led me to improve ‘match-record’, to recommend it in the manual,
> and do “convert” some uses of ‘match’ to ‘match-record’:
>
>   https://issues.guix.gnu.org/59390
>
> That’s a good outcome, but I’d prefer not feeling this kind of pressure.

Neat (not the under pressure part)!  Perhaps srfi-worthy?

>> I initially got tricked by that discrepancy and it took me quite some
>> time hunting down a cryptic backtrace when authoring the new mcron
>> configuration records.
>
> I see.  However, this is a wide-ranging change, so I think this should
> have been discussed separately from the mcron changes.  I find it
> important to take time for review and discussion for such changes.
>
>>> One last thing: placing ‘%location’ first can let us implement:
>>>
>>>   (define (configuration-location config)
>>> (struct-ref config 0))
>>
>> Would this have worked?
>>
>> scheme@(gnu services mcron)> (define config (mcron-configuration))
>> scheme@(gnu services mcron)> (struct-ref 0 config)
>
> You got the order wrong.  :-)

Ah!  Thanks for pointing my silly mistake.  Then the argument would
become... if it's good for define-configuration, it should have been
good for define-record-type* the same (why the discrepancy?).

After your new documentation in place to guide users to DTRT with
regards to matching records, if you think %location should be the first
field, then we should make it so in both instances, perhaps?

>> All in all, I think that's a rather small change that got our internal
>> implementation of both type of records in sync between
>> define-configuration and define-record-type*, that should pave the way
>> for migrating more of the later to the former without risking breaking
>> something, going forward.
>
> Fundamentally, the layout of record types should not be visible to
> users.  That it is visible via ‘match’ is the problem, and the solution
> is not to tweak record type layout but instead tp make sure ‘match’ uses
> on records vanish.
>
> I hope that makes sense!

Yes, and I agree.

>> scheme@(gnu services mcron)> ,use (oop goops)
>
> Speaking of which: there was a conscious decision to not use GOOPS in
> Guix from day one.  Perhaps some day we’ll want to collectively question
> that, but let’s make sure we don’t add that dependency on a whim.
>
> For example:
>
>   class-of -> struct-vtable
>   class-name -> record-type-name
>
> See commit 50c17ddd9e2983d71c125d89b422fd20fca476e1 for an example.

Oops!  Another point to add to our future coding style guidelines :-).
Thanks for showing the simple workaround to goops.

-- 
Thanks,
Maxim

Re: Layout of ‘define-configuration’ records

[Maxim Cournoyer]

Hi Katherine,

Katherine Cox-Buday  writes:

> Maxim Cournoyer  writes:
>
>> Apologies for causing grief!
>
> No worries at all, Maxim! The good you do far outweighs any grief, and
> even if that weren't the case, we're only human :)
>
>> I'm taking yours and Ludovic's feedback into account for the future
>> and will reach out to guix-devel with heads-up when introducing
>> breaking changes to Guix APIs.
>
> This seems like the logical place to me, but it's also a bit busy for
> announcements! I'm sure I'm not alone, but sometimes I'm very busy and
> distracted and I need a very loud signal to let me know I need to take
> action :) That's why I suggested info-guix. Its description reads:
>
> #+begin_quote
> Subscribe to the info-guix low-traffic mailing list to receive important
> announcements sent by the project maintainers (in English).
> #+end_quote

That sounds very appropriate indeed.  I guess we could send
announcements on API breaking changes to both places.  I suppose not
many people are registered to 'info-guix' (I wasn't myself until
recently ^^').

> Would it make sense to publish there? I don't think we break APIs very often?
>
> Also, do we need any kind of formalization around lead-time for these
> announcements?

I guess that's a question of how disruptive the API change is, but it'd
be convenient if it was 2 weeks to match the time the change might
appear on guix-patches un-reviewed.

I'll try to do this in the future (better yet, try to not affect APIs at
all); if it works well for everybody, we could formalize that in our
contributing section.

-- 
Thanks,
Maxim

Re: [Guix Website] A Search Page for Packages

[Julien Lepiller]

I believe the website used both: an unprefixed url will serve the page fsom the 
prefixed directory based on accept-language, but you can also switch language 
easily by using the prefixed path.

Not translating URLs is fine and allows to easily switch language while staying 
on the same page.

Le 21 novembre 2022 20:00:29 GMT+01:00, Luis Felipe 
 a écrit :
>On Monday, November 21st, 2022 at 12:57, Ludovic Courtès  wrote:
>
>> Hi again,
>> 
>
>> Luis Felipe luis.felipe...@protonmail.com skribis:
>> 
>
>> > > > On Wednesday, November 9th, 2022 at 16:43, Luis Felipe 
>> > > > luis.felipe...@protonmail.com wrote:
>> > 
>
>> > > > > I have a working package browser now and will be styling it
>> > > > > next. I'll link to a public repository later.
>> > 
>
>> > > > Here is the source code, by the way:
>> > > > https://codeberg.org/luis-felipe/guix-packages-website
>> > 
>
>> > > Maybe some kind of alpha/beta/in development banner or message would be
>> > > good, just to set expectations that this is a new thing that's being
>> > > worked on.
>> > 
>
>> > I added that and some other things that were missing and realeased version 
>> > 0.1.0 of the package browser.
>> 
>
>> 
>
>> One thing I noticed is that i18n support seems to be missing.
>> 
>
>> It’s OK to keep that for later, but how about making sure URLs are
>> prepared to handle that, by adding /en in the path?
>> 
>
>> That is, from:
>> https://packages.guix.gnu.org/packages/ecl-cl-unicode/0.1.6/
>> to:
>> https://packages.guix.gnu.org/en/packages/ecl-cl-unicode/0.1.6/
>
>Yeah, I left i18n for later, and was actually considering getting rid of the 
>language prefix in URL paths in favor of using HTTP Request's Accept-Language 
>header to detect the user's preferred language and serve the localized 
>resources in that language if available (similar to what happens with apps on 
>the desktop). That looked like less work to me than [also] internationalizing 
>the URLs, but maybe it is not a good practice? In any case, I'm planning to 
>add i18n for version 0.2.0 and was hoping to ask Julien and Florian for advise 
>about that...

Re: [Guix Website] A Search Page for Packages

[John Kehayias]

Hi Chris

On Sat, Nov 19, 2022 at 04:13 PM, Christopher Baines wrote:
> The search functionality is being provided by the Guix Data Service,
> which in turn is searching through records in a PostgreSQL database.
>
> The relevant code is here [1], and it's the plainto_tsquery bit that
> starts the transformation from a string to what PostgreSQL is using for
> the search.
>
> 1:
> 
>

I see. My knowledge of PostgreSQL is limited to emergency measures for when 
something happens with the home server :)

> So yeah, I don't think the way it's implemented currently supports * as
> a wildcard, although maybe that could be supported by changing the way
> the query works.

A low priority, but it would be nice on the list of things for future versions 
to improve the search. I think basic substring/partial matches would go a long 
way. Probably very easy for the PostgreSQL-ers. Or maybe make it match as best 
it can the result lists from "guix search" as a nice parallel.

Anyway, thanks again for this, great to see it live!

John

Re: ci.guix.gnu.org and associated services downtime

[Maxim Cournoyer]

Hi,

zimoun  writes:

> Hi Maxim,
>
> I am replying a bit late…
>
> On Thu, 10 Nov 2022 at 16:42, Maxim Cournoyer  
> wrote:
>
>> There is currently an outage with Berlin, which hosts the build farm,
>> the web site, the issue tracker and a host of other Guix services.
>
> …but thanks for the notification.  I read it on time and it avoid me
> some annoyance. :-)

Glad it was useful.

>> Simply rebooting the machine doesn't fix it and it seems it may has to
>> do with the disk controller or the disk itself, so sadly it seem it'll
>> take some before it can be brought back up and running.
>
> I hope all is now fixed.

It is!  There was a failure with a backing device of the large SAN
array.

-- 
Thanks,
Maxim

Re: Layout of ‘define-configuration’ records

[Maxim Cournoyer]

Hi,

Ludovic Courtès  writes:

> Maxim Cournoyer  skribis:
>
>> A side-note, it seems that Ludovic has been
>> working toward eliminating the use of match patterns matching the fields
>> directly, instead encouraging the use of 'match-record', see
>> https://issues.guix.gnu.org/59390.  I haven't checked if this is
>> compatible with define-configuration records though.
>
> It is: ‘define-configuration’ builds on ‘define-record-type*’, which
> builds on SRFI-9, which builds on Guile “records”, which builds on Guile
> “structs”.  :-)

Excellent!  Thanks for having confirmed that.

-- 
Maxim

Re: [Guix Website] A Search Page for Packages

[zimoun]

Hi Chris,

On Mon, 21 Nov 2022 at 08:57, Christopher Baines  wrote:
> zimoun  writes:
>
>> On Sat, 19 Nov 2022 at 10:51, Christopher Baines  wrote:
>>
>>> It's really nice to have multiple things now (packages.guix.gnu.org,
>>> qa.guix.gnu.org, bordeaux.guix.gnu.org, ...) that are made possible by
>>> the Guix Data Service!
>>
>> Chris, what do you mean by «that are made possible by the Guix Data
>> Service»?
>
> Only that the things I mention are making use of the Guix Data Service
> to provide and query data.

Just to be sure, by Guix Data Service, do you mean the code
https://git.savannah.gnu.org/git/guix/data-service.git?  Or do you mean
a generic name for all the services as qa.guix, bordeaux.guix,
packages.guix or even issues.guix, logs.guix?


Cheers,
simon

Re: ci.guix.gnu.org and associated services downtime

[zimoun]

Hi Maxim,

I am replying a bit late…

On Thu, 10 Nov 2022 at 16:42, Maxim Cournoyer  wrote:

> There is currently an outage with Berlin, which hosts the build farm,
> the web site, the issue tracker and a host of other Guix services.

…but thanks for the notification.  I read it on time and it avoid me
some annoyance. :-)


> Simply rebooting the machine doesn't fix it and it seems it may has to
> do with the disk controller or the disk itself, so sadly it seem it'll
> take some before it can be brought back up and running.

I hope all is now fixed.


Cheers,
simon

Re: (M)ELPA package metadata accuracy

[zimoun]

Hi Ludo,

On Mon, 21 Nov 2022 at 11:00, Ludovic Courtès  wrote:

> So that’d be 72% accurate package metadata for (M)ELPA, not too bad!

IMHO, one could extrapolate that if someone applies a similar approach
as Lars for CRAN, then 70-75% of (M)ELPA should build out-of-the box.

BTW, unrelated to the topic but note that I engaged a discussion [1]
with Org folk about using Guix as a brick for quality assurance of Emacs
packages – starting with Org. ;-)  Well, the GNU project should reuse
its own components instead of relying on other distros. :-)

1: 


> I tried to estimate repository package data accuracy for my PackagingCon
> talk last year in a sophisticated way (perhaps too sophisticated):
>
>   
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/plain/talks/packaging-con-2021/grail/talk.2020.pdf
>   (slide 53)
>
>   https://lists.gnu.org/archive/html/guix-devel/2021-10/msg00297.html

IIRC, you mainly investigated the accuracy of the importers…

> I think we should identify common sources of inaccuracy in package
> metadata

…and indeed maybe a systematic analysis of the modifications of the
default emacs-build-system could help in 2 directions:

 1. maybe draw some heuristics to improve the importer accuracy,

>  talk with repo maintainers to improve on that.

and 2. report upstream if some patterns appear.


Well, for packages using ’emacs-build-system’, only comparing ’keyword’
arguments, it reads:

emacs: 1234 = 1234 = 878  + 356
("phases" . 213)
("tests?" . 144)
("test-command" . 127)
("include" . 87)
("emacs" . 25)
("exclude" . 20)
("modules" . 7)
("imported-modules" . 4)
("parallel-tests?" . 1) 

Considering this 356 packages, 144 modifies the keyword #:tests?.  Note
that ’#:tests? #t’ is counted in these 144 and it reads,

$ ag 'tests\? #t' gnu/packages/emacs-xyz.scm | wc -l
117

Ah!  It requires some investigations. :-)

Indeed, it could be worth to identify common sources of the extra
modifications we are doing compared to the default emacs-build-system.


Cheers,
simon

(use-modules (guix)
 (gnu)
 (srfi srfi-1)
 (ice-9 match))


(define %table (make-hash-table))

(define (keyword-as-string arg)
  (map (compose symbol->string keyword->symbol)
   (filter keyword? arg)))

(define (count-items lst)
  (if (null? lst)
  '()
  (let ((sorted (sort lst string<=?)))
(sort
 (fold (lambda (keyword result)
 (match result
   ((head tail ...)
(match head
  ((k . v)
   (if (string= k keyword)
   (cons `(,k . ,(+ 1 v)) tail)
   (cons `(,keyword . 1) result)))
  (_ (format #t "Error:"
   (_ (format #t "Error:"
   (list `(,(car sorted) . 1))
   (cdr sorted))
 (lambda (x1 x2)
   (match x1
 ((k1 . v1)
  (match x2
((k2 . v2)
 (> v1 v2))


(fold-packages (lambda (package result)
 (let ((bs  (build-system-name
 (package-build-system package)))
   (arg (package-arguments package)))
   (match (hash-ref result bs)
 ((tot wo wi args)
  (if (null? arg)
  (hash-set! result bs (list
(1+ tot)
(1+ wo)
wi args))
  (hash-set! result bs (list
(1+ tot)
wo
(1+ wi)
(append (keyword-as-string arg)
args)
 (#f (if (null? arg)
 (hash-set! result bs (list 1 1 0 '()))
 (hash-set! result bs (list 1 0 1 
(keyword-as-string arg)
 (_ (format #t "Error: ~s~%" (package-name package
   result))
  %table)


(define fmt "~13s: ~4s = ~4s = ~4s + ~4s  ~{ ~s ~}~%")
(format #t fmt
'key 'tot 'tot 'no-arguments 'arguments (list 'pattern?))
(hash-for-each-handle (lambda (kv)
(match kv
  ((key . value)
   (match value
 ((tot wo wi args)
  (format #t fmt
  key
  (+ wo wi)
 

Re: [Guix Website] A Search Page for Packages

[Luis Felipe]

On Monday, November 21st, 2022 at 13:21, Christopher Baines  
wrote:

> Ludovic Courtès l...@gnu.org writes:
> 

> > One thing I noticed is that i18n support seems to be missing.
> > 

> > It’s OK to keep that for later, but how about making sure URLs are
> > prepared to handle that, by adding /en in the path?
> > 

> > That is, from:
> > https://packages.guix.gnu.org/packages/ecl-cl-unicode/0.1.6/
> > to:
> > https://packages.guix.gnu.org/en/packages/ecl-cl-unicode/0.1.6/
> 

> 

> On a similar subject, would it be sensible to remove the packages/ bit
> from the URL, e.g. this?
> 

> https://packages.guix.gnu.org/en/ecl-cl-unicode/0.1.6/

About that, the "packages" part looks redundant for sure, but the reason I 
added it was that I started thinking that the whole Guix website could be 
copy-pasted to this Artanis project and have the whole website again served on 
guix.gnu.org at some point, where the "packages" part would not be redundant 
anymore, but actually necessary. But if this doesn't sound right, I can 
simplify the URL path then :)

publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: [Guix Website] A Search Page for Packages

[Luis Felipe]

On Monday, November 21st, 2022 at 12:57, Ludovic Courtès  wrote:

> Hi again,
> 

> Luis Felipe luis.felipe...@protonmail.com skribis:
> 

> > > > On Wednesday, November 9th, 2022 at 16:43, Luis Felipe 
> > > > luis.felipe...@protonmail.com wrote:
> > 

> > > > > I have a working package browser now and will be styling it
> > > > > next. I'll link to a public repository later.
> > 

> > > > Here is the source code, by the way:
> > > > https://codeberg.org/luis-felipe/guix-packages-website
> > 

> > > Maybe some kind of alpha/beta/in development banner or message would be
> > > good, just to set expectations that this is a new thing that's being
> > > worked on.
> > 

> > I added that and some other things that were missing and realeased version 
> > 0.1.0 of the package browser.
> 

> 

> One thing I noticed is that i18n support seems to be missing.
> 

> It’s OK to keep that for later, but how about making sure URLs are
> prepared to handle that, by adding /en in the path?
> 

> That is, from:
> https://packages.guix.gnu.org/packages/ecl-cl-unicode/0.1.6/
> to:
> https://packages.guix.gnu.org/en/packages/ecl-cl-unicode/0.1.6/

Yeah, I left i18n for later, and was actually considering getting rid of the 
language prefix in URL paths in favor of using HTTP Request's Accept-Language 
header to detect the user's preferred language and serve the localized 
resources in that language if available (similar to what happens with apps on 
the desktop). That looked like less work to me than [also] internationalizing 
the URLs, but maybe it is not a good practice? In any case, I'm planning to add 
i18n for version 0.2.0 and was hoping to ask Julien and Florian for advise 
about that...

publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Layout of ‘define-configuration’ records

[Katherine Cox-Buday]

Maxim Cournoyer  writes:

> Apologies for causing grief!

No worries at all, Maxim! The good you do far outweighs any grief, and
even if that weren't the case, we're only human :)

> I'm taking yours and Ludovic's feedback into account for the future
> and will reach out to guix-devel with heads-up when introducing
> breaking changes to Guix APIs.

This seems like the logical place to me, but it's also a bit busy for
announcements! I'm sure I'm not alone, but sometimes I'm very busy and
distracted and I need a very loud signal to let me know I need to take
action :) That's why I suggested info-guix. Its description reads:

#+begin_quote
Subscribe to the info-guix low-traffic mailing list to receive important
announcements sent by the project maintainers (in English).
#+end_quote

Would it make sense to publish there? I don't think we break APIs very often?

Also, do we need any kind of formalization around lead-time for these
announcements?

> A side-note, it seems that Ludovic has been working toward eliminating
> the use of match patterns matching the fields directly, instead
> encouraging the use of 'match-record', see
> https://issues.guix.gnu.org/59390. I haven't checked if this is
> compatible with define-configuration records though.

Thanks, I'll have a look!

-- 
Katherine

[PATCH WIP] gnu: audio: Add mympd-service-type.

[mirai]

From: Bruno Victal 

Hi, I've been working on this service definition for some time, while it works 
and passes
a rudimentary test suite, some polish is required before it is ready for merging
with guix. I'd like to request some comments on the current state of it and 
suggestions
on how to address the remaining issues.

Depends on 'mympd' package which at the time of writing is not in guix upstream
but has been submitted at 'https://issues.guix.gnu.org/59437'.

Upstream pages for reference: 
https://jcorporation.github.io/myMPD/configuration/


Regards,
Bruno

Bruno Victal (1):
  gnu: audio: Add mympd-service-type.

 doc/guix.texi  |  79 +++
 gnu/services/audio.scm | 174 -
 gnu/tests/audio.scm|  54 -
 3 files changed, 305 insertions(+), 2 deletions(-)

-- 
2.38.1

Re: foreign-distro?

[Jake Shilling]

I've experimented with the distinction in my config, because I wanted to
be able to add home-services conditionally (e.g. I wanted my GuixSD to
install a destop envrionment, but my work laptop to only setup emacs and
its dependencies).

My approache was to just parse the `/etc/os-release` file if it exists:
```
(define (os-release)
  (guard (_
  (else #f))
(call-with-input-file "/etc/os-release"
  (lambda (port)
(let loop ((line (read-line port))
   (result '()))
  (if (eof-object? line)
  (reverse result)
  (begin
(let* ((split (string-split line #\=))
   (key (string->symbol (car split)))
   (val (if (string-match "\".*\"" (cadr split))
(substring (cadr split) 1 (- (string-length 
(cadr split)) 1))
(string->symbol (cadr split
   (d (cons key val)))
  (loop (read-line port)
(cons d result))
```

Then I define a couple wrappers:

```
(define (linux-distro-id)
  (if (linux?)
  (assq-ref (os-release) 'ID)
  #f))

(define (guix-system?)
  (eq? (linux-distro-id) 'guix))
```

The config was never really fleshed out because I ended up just using my
GuixSD computer for work instead.

On 2022-11-20 23:08, Julien Lepiller wrote:

> Le Sun, 20 Nov 2022 14:54:40 -0600,
> jgart  a écrit :
>
>> Does Guix have a declarative Guix API way of knowing if it is
>> installing a package into foreign distro versus Guix System?
>> 
>> I'm thinking of a function like `foreign-distro?`:
>> 
>> ```
>> (define-public peek
>>   (package
>>(name "peek")
>>...
>> (inputs 
>>   `(,@(if (foreign-distro?) `(("ffmpeg" ,ffmpeg)) '(
>> ```
>> 
>> The above includes ffmpeg in the inputs only if installing peek on a
>> foreign distro. It could additionally patch the ffmpeg executable in
>> a peek package phases if foreign-distro? returns #t.
>> 
>> WDYT
>> 
>
>
> Guix doesn't have a notion of foreign distro, it's all in your head,
> and there's no difference between Guix System and other distros in the
> Guix package manager's point of view :)
>
> To be more specific, Guix only knows what you current system is (that's
> captured by %current-system). It's probably x86_64-linux right know. As
> you can see, there's no place in there to tell it whether you're on a
> foreign distro or not.
>
> Lastly, I don't think I would want to differentiate the two cases,
> especially since it would mean that somehow Guix packages depend on
> something external. There's this idea that Guix packages should somehow
> be self-sufficient.
>

-- 
Best regards,
Jake Shilling


signature.asc
Description: PGP signature

[PATCH 1/1] gnu: audio: Add mympd-service-type.

[mirai]

From: Bruno Victal 

---
Potential issues:
  * The use 'define-maybe' [string | comma-separated-string] might interfere 
with other
  service definitions that are added over time.
  * Should 'log-file' used in 'shepherd-service' be a configuration parameter?
  * Service configuration is not in the 'store'. To understand this, myMPD uses 
a directory
  it calls 'working-directory' to store/read both the configuration and mutable 
data. So if it uses
  '/var/lib/mympd' as its "working-directory", it must read the configuration 
from a 'config'
  subdirectory ('/var/lib/mympd/config/'). When it comes to configuration, each 
directive corresponds to
  a file under this '/config' directory. How it sets/reads the values, myMPD 
provides two ways to do so:
   1. It can read from the environment-variables iff the "config" directory 
within its
   'working-directory' is empty. In this case, they are read and written to 
the corresponding file.
   Subsequent runs will ignore the environment variable values, even if 
they differ (with the exception of
   'MYMPD_LOGLEVEL' which is always used).
   2. Read directly from the files present within 'config' subdirectory. 
This is essentially what happens
   after the first launch described above.
The current approach used erases this 'config' directory on every 'guix 
system reconfigure'. Downsides is that
it is prone to overdelete things depending on further upstream developments 
and the expectation that every
parameter is adjustable via environment variables (at the moment, there's 
one that can't be set but its of
a peculiar nature that I'm not sure if it should be added to the store. 
It's an optional sha256 password hash.
(https://jcorporation.github.io/myMPD/configuration/)
  * A warning that the default group used (nogroup) is duplicated. I reasoned 
that there's little point in
  creating a specific group that might end up unused yet allow for a custom 
group to be used if necessary.
  * 'comma-separated-string-list' code duplication. This function was lifted 
from 'gnu/services/mail.scm' but
  its already duplicated at 'gnu/services/cups.scm'. It doesn't seem to be an 
uncommon pattern used in configuration,
  maybe this could be added to 'gnu/services/configuration.scm' as a 
readily-available type for convenience?

 doc/guix.texi  |  79 +++
 gnu/services/audio.scm | 174 -
 gnu/tests/audio.scm|  54 -
 3 files changed, 305 insertions(+), 2 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index eaecfd0daa..10727d5196 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -109,6 +109,7 @@ Copyright @copyright{} 2022 Reily Siegel@*
 Copyright @copyright{} 2022 Simon Streit@*
 Copyright @copyright{} 2022 (@*
 Copyright @copyright{} 2022 John Kehayias@*
+Copyright @copyright{} 2022 Bruno Victal@*
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.3 or
@@ -32889,6 +32890,84 @@ an HTTP audio streaming output.
 (port. "8080"
 @end lisp
 
+@subsubheading myMPD
+
+@cindex MPD, web interface
+@cindex myMPD service
+
+@uref{https://jcorporation.github.io/myMPD/, myMPD} is a service that provides 
a
+mobile friendly web client for MPD.
+
+The following example shows a myMPD instance listening on port 80, with album 
cover caching disabled.
+
+@lisp
+(service mympd-service-configuration
+ (mympd-configuration
+  (port 80)
+  (covercache-ttl 0)))
+@end lisp
+
+@c auto-generated with (configuration->documentation)
+@deftp {Data Type} mympd-configuration
+Available @code{mympd-configuration} fields are:
+
+@table @asis
+@item @code{package} (default: @code{mympd}) (type: file-like)
+The package object of the myMPD server.
+
+@item @code{user} (default: @code{"mympd"}) (type: string)
+Owner of the @code{mympd} process.
+
+@item @code{group} (default: @code{"nogroup"}) (type: string)
+Owner's group of the @code{mympd} process.
+
+@item @code{work-directory} (default: @code{"/var/lib/mympd"}) (type: string)
+Where myMPD will store its data.
+
+@item @code{cache-directory} (default: @code{"/var/cache/mympd"}) (type: 
string)
+Where myMPD will store its cache.
+
+@item @code{acl} (type: maybe-comma-separated-string-list)
+ACL to access the myMPD webserver.  See
+@uref{https://jcorporation.github.io/myMPD/configuration/acl,myMPD ACL}
+for syntax.
+
+@item @code{covercache-ttl} (default: @code{31}) (type: number)
+How long to keep cached covers.  Setting to @code{0} disables caching.
+
+@item @code{host} (default: @code{"[::]"}) (type: string)
+Host name to listen on.
+
+@item @code{port} (default: @code{80}) (type: number)
+Port to listen on.
+
+@item @code{loglevel} (default: @code{5}) (type: number)
+Log level to output logs, possible values: @code{0} to @code{7}.
+
+@item @code{lualibs} (default: @code{"all"}) (t

Re: guix open

[John Kehayias]

On Mon, Nov 21, 2022 at 08:43 AM, jgart wrote:

> On Mon, 21 Nov 2022 12:07:32 +0100 Ludovic Courtès  wrote:
>> ‘guix show’ prints the home page URL, which is clickable in recent
>> terminal emulators.  Do we need something more?
>
> Hi Ludo, what terminal emulator are using, kitty or alakitty?

I am not Ludo (last I checked), but I use kitty and can click on links to open 
them in a browser. Even the "location" field will work, opening it from the 
store. I'm not sure what is set by default, perhaps ctrl+left click as that's 
what I have on one computer. While another I definitely changed it so it is 
just a regular left click.

Re: guix open

[jgart]

On Mon, 21 Nov 2022 12:07:32 +0100 Ludovic Courtès  wrote:
> ‘guix show’ prints the home page URL, which is clickable in recent
> terminal emulators.  Do we need something more?

Hi Ludo, what terminal emulator are using, kitty or alakitty?

Re: [Guix Website] A Search Page for Packages

[Christopher Baines]

Ludovic Courtès  writes:

> One thing I noticed is that i18n support seems to be missing.
>
> It’s OK to keep that for later, but how about making sure URLs are
> prepared to handle that, by adding /en in the path?
>
> That is, from:
> https://packages.guix.gnu.org/packages/ecl-cl-unicode/0.1.6/
> to:
> https://packages.guix.gnu.org/en/packages/ecl-cl-unicode/0.1.6/

On a similar subject, would it be sensible to remove the packages/ bit
from the URL, e.g. this?

  https://packages.guix.gnu.org/en/ecl-cl-unicode/0.1.6/

> Sysadmin-wise, we’ll need a proper service in (sysadmin web), Chris.
> :-)  (I can help with that if needed.)

I should be able to get to it at some point as well, I need to write a
service for the qa-frontpage, so hopefully I can do some copy and
pasting.

Chris


signature.asc
Description: PGP signature

Re: [Guix Website] A Search Page for Packages

[Ludovic Courtès]

Hi again,

Luis Felipe  skribis:

>> > On Wednesday, November 9th, 2022 at 16:43, Luis Felipe 
>> > luis.felipe...@protonmail.com wrote:
>> > 
>
>> > > I have a working package browser now and will be styling it
>> > > next. I'll link to a public repository later.
>> > 
>
>> > Here is the source code, by the way:
>> > https://codeberg.org/luis-felipe/guix-packages-website
>> 
>
>> Maybe some kind of alpha/beta/in development banner or message would be
>> good, just to set expectations that this is a new thing that's being
>> worked on.
>
> I added that and some other things that were missing and realeased version 
> 0.1.0 of the package browser.

One thing I noticed is that i18n support seems to be missing.

It’s OK to keep that for later, but how about making sure URLs are
prepared to handle that, by adding /en in the path?

That is, from:
https://packages.guix.gnu.org/packages/ecl-cl-unicode/0.1.6/
to:
https://packages.guix.gnu.org/en/packages/ecl-cl-unicode/0.1.6/


Sysadmin-wise, we’ll need a proper service in (sysadmin web), Chris.
:-)  (I can help with that if needed.)

Thanks,
Ludo’.

Re: Guix Shows Us The Executable Binaries

[zimoun]

Hi,

On Mon, 21 Nov 2022 at 08:56, Christopher Baines  wrote:
> jgart  writes:
>
>> wdyt if we show the bin folder in `guix show` output like in fedora?
>
> How would you implement that? Would the guix show command build the
> package if it isn't in the store?

In addition to Chris’s comment, please give a look at the “guix
filesearch” old proposal [1].  Be able to list the executable binary
files by “guix show” requires to get the list from the substitute
servers, so they need to somehow expose new features.

1: 

Cheers,
simon

Re: Guix Shows Us The Executable Binaries

[Ludovic Courtès]

Hi,

jgart  skribis:

> wdyt if we show the bin folder in `guix show` output like in fedora?

It’s not possible because the list of binaries is not known until the
package has been built.

However, a worthy avenue is a tool and/or service to search for packages
that provide a given file or program:

  https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00354.html

Ludo’.

Re: bringing npm packages to Guix

[Ludovic Courtès]

Hi,

zamfofex  skribis:

> A few months ago, I picked up the work towards importing npm packages to Guix 
> by Jelle et al. in the hopes of continuing it, and I felt disheartened when I 
> concluded that it does indeed seem like a very large part of npm is necessary 
> to build even a simple package like jQuery.

Christine had that great summary of the npm mess at the time:

  https://dustycloud.org/blog/javascript-packaging-dystopia/

With all its shortcomings, I think it would still be useful to merge
Jelle’s npm importer (the “binary” importer), as discussed last year:

  https://lists.gnu.org/archive/html/guix-devel/2021-09/msg00245.html

Thumbs up to whoever submits it for inclusion!  :-)

(I won’t answer on ‘devDependencies’ issues because JS is outside my
area of expertise.)

Thanks,
Ludo’.

Re: 01/03: gnu: lld-as-ld-wrapper: Add version 15.

[Ludovic Courtès]

Hi,

Marius Bakke  skribis:

> I think using the LLD version is sensible.  I made this change in
> cd9161372aa3ec9b8902385d5937d04e1868495c and also inherited the
> home-page and license fields.

Thanks!

I’d like to point out that duplicate packages (same name and same
version) lead to the failure of the test called "fold-available-packages
with/without cache" in ‘tests/packages.scm’, so that also fixed that.
:-)

Ludo’.

Re: guix open

[Ludovic Courtès]

Tobias Geerinckx-Rice  skribis:

> jgart 写道：
>> what do you think of having a `guix open` command that opens the
>> projects
>> home-page in your $BROWSER? 
>
> […]
>
>> bloat? 
>
> Yes — as ‘guix open’ — but it would make a nice addition to ‘guix
> show’.

‘guix show’ prints the home page URL, which is clickable in recent
terminal emulators.  Do we need something more?

Ludo’.

Re: [Guix Website] A Search Page for Packages

[Ludovic Courtès]

Hi Luis,

Luis Felipe  skribis:

> On Saturday, November 19th, 2022 at 12:03, Luis Felipe 
>  wrote:
>
>> I'll send a patch to link to it from the static website's "Package" menu.
>
> Done: https://issues.guix.gnu.org/59385.

You’re a hero, thank you!!

Ludo’.

Re: Layout of ‘define-configuration’ records

[Ludovic Courtès]

Maxim Cournoyer  skribis:

> A side-note, it seems that Ludovic has been
> working toward eliminating the use of match patterns matching the fields
> directly, instead encouraging the use of 'match-record', see
> https://issues.guix.gnu.org/59390.  I haven't checked if this is
> compatible with define-configuration records though.

It is: ‘define-configuration’ builds on ‘define-record-type*’, which
builds on SRFI-9, which builds on Guile “records”, which builds on Guile
“structs”.  :-)

--8<---cut here---start->8---
scheme@(guile-user)> ,m (gnu home services desktop)
scheme@(gnu home services desktop)> (home-redshift-configuration)
$1 = #< redshift: # location-provider: geoclue2 
adjustment-method: randr daytime-temperature: 6500 nighttime-temperature: 4500 
daytime-brightness: %unset-marker% nighttime-brightness: %unset-marker% 
latitude: %unset-marker% longitude: %unset-marker% dawn-time: %unset-marker% 
dusk-time: %unset-marker% extra-content: "" %location: #f>
scheme@(gnu home services desktop)> (match-record $1 
 (adjustment-method nighttime-temperature)
... (list nighttime-temperature adjustment-method))
$2 = (4500 randr)
--8<---cut here---end--->8---

Ludo’.

Re: Layout of ‘define-configuration’ records

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:

[...]

>>> +   (%location #,(id #'stem #'stem #'-location)
>>> +  (default (and=> (current-source-location)
>>> +  source-properties->location))
>>> +  (innate)))
>>
>> Moving the field last is problematic as we’ve seen for any user that
>> uses ‘match’ on records—something that’s not recommended but still used
>> a lot.
>
> Yep.  I had that on mind when I made the change, though I still missed a
> few occurrences.

[...]

> I wanted match on define-configuration'd fields to be
> backward-compatible with fields migrated from define-record-type*, so
> that they such change can be made without worrying breakages.

That had the opposite effect: it introduced breakage precisely because
existing uses of ‘match’ on records need to be verified manually, one by
one.

That led me to improve ‘match-record’, to recommend it in the manual,
and do “convert” some uses of ‘match’ to ‘match-record’:

  https://issues.guix.gnu.org/59390

That’s a good outcome, but I’d prefer not feeling this kind of pressure.

> I initially got tricked by that discrepancy and it took me quite some
> time hunting down a cryptic backtrace when authoring the new mcron
> configuration records.

I see.  However, this is a wide-ranging change, so I think this should
have been discussed separately from the mcron changes.  I find it
important to take time for review and discussion for such changes.

>> One last thing: placing ‘%location’ first can let us implement:
>>
>>   (define (configuration-location config)
>> (struct-ref config 0))
>
> Would this have worked?
>
> scheme@(gnu services mcron)> (define config (mcron-configuration))
> scheme@(gnu services mcron)> (struct-ref 0 config)

You got the order wrong.  :-)

> All in all, I think that's a rather small change that got our internal
> implementation of both type of records in sync between
> define-configuration and define-record-type*, that should pave the way
> for migrating more of the later to the former without risking breaking
> something, going forward.

Fundamentally, the layout of record types should not be visible to
users.  That it is visible via ‘match’ is the problem, and the solution
is not to tweak record type layout but instead tp make sure ‘match’ uses
on records vanish.

I hope that makes sense!

> scheme@(gnu services mcron)> ,use (oop goops)

Speaking of which: there was a conscious decision to not use GOOPS in
Guix from day one.  Perhaps some day we’ll want to collectively question
that, but let’s make sure we don’t add that dependency on a whim.

For example:

  class-of -> struct-vtable
  class-name -> record-type-name

See commit 50c17ddd9e2983d71c125d89b422fd20fca476e1 for an example.

Thanks,
Ludo’.

Re: Release progress, week 6

[Ludovic Courtès]

Hi,

Efraim Flashner  skribis:

> On Thu, Nov 17, 2022 at 05:04:43PM +0100, Ludovic Courtès wrote:

[...]

>>  - i586-gnu: as proposed last week, I’ll drop i586-gnu from
>>‘etc/release-manifest.scm’.
>> 
>>  - armhf-linux: Mathieu re-queued a number of armhf-linux builds
>>since last week but that hasn’t had a visible effect so far.
>> 
>>  - aarch64-linux: Little progress: Emacs is now available on ci.guix
>>but it’s not clear while the others aren’t showing up, even after
>>restarting them in the Cuirass interface.
>> 
>>It would seem that a lot of aarch64 builds are queued but not
>>getting processed.  Any idea how to investigate that, Mathieu?
>> 
>>  - powerpc64le-linux: No progress.
>
> Can we bypass cuirass building the packages and from Berlin ask for the
> packages to be built? Then it'll offload to the appropriate machine and
> should show up faster for make assert-binaries-available.

Yes, I shamelessly ended up doing that: running “guix build” on berlin
to fill in the gaps.  :-)

Ludo’.

Re: Release progress, week 6

[Ludovic Courtès]

Hi!

Mathieu Othacehe  skribis:

> Hello,
>
>>It would seem that a lot of aarch64 builds are queued but not
>>getting processed.  Any idea how to investigate that, Mathieu?
>
> That would be because we only had a single ARM machine available till
> this week (kreuzberg). It seems that overdrive1 and grunewald are back
> though!
>
> I also noticed that my recent remote worker fix was not working as
> expected. The workers are not blocked anymore after a remote server
> disconnection but some builds are flagged as submitted even though they
> are not received by the worker.

OK, that would explain it.

>>  Should we send out a call for testing the installer?  Looks like
>>  we’re ready, no?
>
> Sure, I'll take care of that on Monday.

I’m thinking we might as well do a proper RC1, produced by “make
release”.  Maybe not today, but tomorrow we may have everything ready?

Thanks,
Ludo’.

(M)ELPA package metadata accuracy

[Ludovic Courtès]

Hi!

zimoun  skribis:

> For example, let count the number of packages that are tweaking their
> ’arguments’ fields (from ’#:tests? #f’ to complex phases modifications).
> This is far from being a perfect metrics but it is a rough indication
> about upstream quality: if they provide clean package respecting their
> build system or if the package requires Guix adjustments.
>
> Well, I get:
>
>   r: 2093 = 2093 = 1991 + 102 
>
> which is good (only ~5% require ’arguments’ tweaks), but
>
>   python   : 2630 = 2630 = 803  + 1827
>
> is bad (only ~31% do not require an ’arguments’ tweak).
>
> About Emacs, it reads,
>
>   emacs: 1222 = 1222 = 874  + 348 


So that’d be 72% accurate package metadata for (M)ELPA, not too bad!

I tried to estimate repository package data accuracy for my PackagingCon
talk last year in a sophisticated way (perhaps too sophisticated):

  
https://git.savannah.gnu.org/cgit/guix/maintenance.git/plain/talks/packaging-con-2021/grail/talk.2020.pdf
  (slide 53)

  https://lists.gnu.org/archive/html/guix-devel/2021-10/msg00297.html

I think we should identify common sources of inaccuracy in package
metadata and talk with repo maintainers to improve on that.  For MELPA,
it shouldn’t be hard to get in touch so there’s a real opportunity here.

Thanks,
Ludo’.

Re: Guix Shows Us The Executable Binaries

[Christopher Baines]

jgart  writes:

> wdyt if we show the bin folder in `guix show` output like in fedora?

How would you implement that? Would the guix show command build the
package if it isn't in the store?


signature.asc
Description: PGP signature

Re: [Guix Website] A Search Page for Packages

[Christopher Baines]

zimoun  writes:

> On Sat, 19 Nov 2022 at 10:51, Christopher Baines  wrote:
>
>> It's really nice to have multiple things now (packages.guix.gnu.org,
>> qa.guix.gnu.org, bordeaux.guix.gnu.org, ...) that are made possible by
>> the Guix Data Service!
>
> Chris, what do you mean by «that are made possible by the Guix Data
> Service»?

Only that the things I mention are making use of the Guix Data Service
to provide and query data.


signature.asc
Description: PGP signature