Re: Linux-Libre-LTS

[Raghav Gururajan]

Hello Tobias!

It is!  Would you like to try your hand at a patch?  It should be easy 
if unexciting work.  (If you want excitment you can suggest making it 
the default.)


Sure! Yeah, making it default was the next thing in my mind.

We should use upstream[0] release names, though, not roll our own (+less 
clear) ones.  So ‘-longterm’ instead of ‘-lts’.


By upstream you mean linux-libre or linux? The linux-libre uses the name 
'lts'.


Regards,
RG.


OpenPGP_0x5F5816647F8BE551.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: Linux-Libre-LTS

[Raghav Gururajan]

Hi Efraim!


I was waiting for the kernel code reorganization before adding it as a
variable. The trick is to add also linux-libre-lts-source and all the
others, and in a useful location. Now it's just taking the time to add
it in somewhere.

Do you want to take a stab at it? I'm not sure when I'll get around to
it.


Cool! I'll give it a shot.

Regards,
RG.


OpenPGP_0x5F5816647F8BE551.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: Use development sources more

[Leo Famulari]

On Sun, Nov 01, 2020 at 02:35:50PM -0500, Morgan Smith wrote:
> I would like to propose that we move towards using sources that resemble
> the development sources as closely as possible.
> 
> I like to work on Emacs and Emacs packages in my spare time. The Guix
> package transformations are gold for this. My workflow is the clone the
> source repo, make some changes and commit them, and then use the
> --with-git-url package transformation to build and test.
> 
> The problem I tend to run into in my workflow, are that packages don't
> tend to build from the development source. This is the reason I readded
> emacs-next.

So, in this case, the salient difference between the 'emacs' and
'emacs-next' packages is that emacs-next's source is their Git repo,
whereas emacs uses the release tarball? 

We do base packages on Git repos very often, largely because it
increases the number of packages whose sources are "backed up" by
Software Heritage, and because lots of projects don't offer "real"
tarballs anymore — they may not even have "versions".

Guix is a lot of things but it's primarily a software distribution with
operating system. I think it's important that we distribute the things
that upstream developers intend to be distributed.

Re: Etymology of derivation

[Arun Isaac]

>> Actually I don't understand what "message" would mean in "build-message".
>> I'm more confused than with "derivation" :p
>
> It is the minimal build information that the build-daemon requires. A
> message to the build daemon in a way.

Perhaps "build request" is a slightly better term. Just as HTTP requests
are to a HTTP daemon, build requests are to the Guix build
daemon.

Besides, I wouldn't translate "build message/request" literally to
Tamil. I might have to very subtly alter the meaning so that it sits
well with common comprehension of the language. There is some degree of
choice in the translation.

Cheers!


signature.asc
Description: PGP signature

RFC: subcommand to pause/resume builds

[John Soo]

Hi Guix!

I was looking to pause a long build today and asked on IRC how to
accomplish pause/resume.  It seems this is possible already with the
following:

kill --signal SIGSTOP|SIGCONT {pids-of-build-process-tree}

There is already a command to list the processes associated to guix
commands: guix processes.  Perhaps pause/resume can be a subcommand or
set of flags to guix processes. The following is the first thing that
comes to mind:

guix processes --pause package-name ... --resume package-name ...

What do you think?

Thanks!

- John

Bioconductior upgrades to 3.12

[zimoun]

Hi,

I am updating to the last Bioconductor release v3.12.  Please fetch the
branch ’wip-r’ from:

https://github.com/zimoun/guix

There is remaining work to do.  See below.


Here, I am describing the workflow.  Maybe it could help as basis for
future updates.  Ricardo provided helpful tips:

   

First, I create a local branch name ’wip-r’ with the convention that
’wip’ means “could be rewritten and/or rebased”.  Then I update to
"3.12":

--8<---cut here---start->8---
modified   guix/import/cran.scm
@@ -143,7 +143,7 @@ package definition."

 ;; The latest Bioconductor release is 3.11.  Bioconductor packages should be
 ;; updated together.
-(define %bioconductor-version "3.11")
+(define %bioconductor-version "3.12")
--8<---cut here---end--->8---

and run “./pre-inst-env guix refresh -t bioconductor -u” inside an Emacs
shell and then save the buffer.  Depending on the network, it takes some
time.  Then the previous change to 3.12 is stashed.  Now let commit all
the changes –– thank you so much Ricardo for having written the
tool. :-)

  ./etc/committer.scm

and done.  The next step is to check.  Using the saved output buffer, I
use some Emacs tricks. :-)

 1. M-x keep-lines ^r-
 2. Macro with 2 buffers: the one of #1 and “git-rebase-todo” doing:
  C-x ( C-a C-SPC C-s : RET M-w C-x o M-< C-s C-y RET e C-x o C-n C-x )
  C-x C-e eee…

Warning, Magit will be slow.


Second, I review each of these ’edit’ changes.  Some are skipped,
because of missing dependencies or because I am not sure (for instance
’zlib’ removal).  Below what I did.

The commit messages are not always accurate because some item as:

[propagate-inputs]: Remove ’foo’.
[propagate-inputs]: Adding ’bar’.

are missing.


All the best,
simon
--
$ ./pre-inst-env guix refresh -t bioconductor -u

# NOT DONE
r-bamsignals: consider removing this input: zlib

# NOT DONE
r-rsamtools: consider removing this input: zlib
r-rsamtools: consider adding this propagated input: r-zlibbioc

# NOT DONE
r-methylkit: consider removing this input: zlib

# NOT DONE
r-variantannotation: consider removing this input: zlib
r-variantannotation: consider adding this propagated input: r-matrixgenerics

# NOt DONE
r-rhdf5: consider removing this input: zlib
r-rhdf5: consider adding this propagated input: r-rhdf5filters

# NOT DONE
r-gdsfmt: consider removing this input: lz4
r-gdsfmt: consider removing this input: xz
r-gdsfmt: consider removing this input: zlib

# NOT DONE
r-rbowtie2: consider removing this input: zlib

# NOT DONE
r-seqbias: consider removing this input: zlib

# NOT DONE
r-cytolib: consider removing this input: zlib
r-cytolib: consider adding this native input: pkg-config

# NOT DONE
r-ncdfflow: consider removing this input: zlib
r-hdf5array: consider removing this input: zlib

# DEP but added (my bad)
r-annaffy: consider adding this propagated input: r-kegg-db

# DEP
r-flowworkspace: consider adding this propagated input: r-aws-s3
r-flowworkspace: consider adding this propagated input: r-aws-signature
r-flowworkspace: consider removing this propagated input: r-stringr

# DEP
r-scater: consider adding this propagated input: r-gridextra
r-scater: consider adding this propagated input: r-scuttle
r-scater: consider removing this propagated input: r-beachmat
r-scater: consider removing this propagated input: r-rcpp

# DEP
r-biocset: consider adding this propagated input: r-biocio
r-biocset: consider adding this propagated input: r-ontologyindex
r-biocset: consider adding this propagated input: r-s4vectors
r-biocset: consider adding this propagated input: r-tidyr
r-biocset: consider removing this propagated input: r-rtracklayer

# DEP
r-scran: consider adding this propagated input: r-bluster
r-scran: consider adding this propagated input: r-scuttle
r-scran: consider removing this propagated input: r-iranges
r-scran: consider removing this propagated input: r-scater

# DEP
r-xcms: consider adding this propagated input: r-mscoreutils

# DEP
r-webbioc: consider adding this input: unix

# DEP
r-biocpkgtools: consider adding this input: mailsend-go

# DEP
r-enrichplot: consider adding this propagated input: r-shadowtext
r-enrichplot: consider removing this propagated input: r-annotationdbi
r-enrichplot: consider removing this propagated input: r-europepmc
r-enrichplot: consider removing this propagated input: r-ggplotify
r-enrichplot: consider removing this propagated input: r-ggridges
r-enrichplot: consider removing this propagated input: r-gridextra

# DEP
r-delayedarray: consider adding this propagated input: r-matrixgenerics
r-delayedarray: consider removing this propagated input: r-matrixstats

# DEP
r-genomicfiles: consider adding this propagated input: r-matrixgenerics

# DEP
r-diffbind: consider removing this input: zlib
r-diffbind: consider adding this propagated input: r-apeglm
r-diffbind: consider adding this propagated 

Re: Branching for v1.2?

[pelzflorian (Florian Pelz)]

On Mon, Nov 02, 2020 at 10:00:38AM -0500, Julien Lepiller wrote:
> Le 2 novembre 2020 08:20:34 GMT-05:00, "Miguel Ángel Arruga Vivas" 
>  a écrit :
> >With my translator hat on: a new tarball for TP has to be generated
> >before or after creating the branch (1.2.0-pre3).  If done tomorrow, I
> >think the translations could need a bit later than Friday to catch up;
> >Florian and Julien, what do you think?
> 
> I think I can manage the deadline on the 6th if there aren't too
> many changes, and we generate the tarball today or tomorrow. […]

That would be OK for me.

Regards,
Florian

Lint checker for Stackage/LTSHaskell package versions?

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

>> +(define-public ghc-tabular
>> +  (package
>> +(name "ghc-tabular")
>> +(version "0.2.2.8")
>
> LTSHaskell has this at 0.2.2.7.

How hard would it be to add a ‘lint’ checker for that?  After all we
already have the updater code.  That’d be very helpful!

Ludo’.

Re: Branching for v1.2?

[Ludovic Courtès]

Miguel Ángel Arruga Vivas  skribis:

> Ludovic Courtès  writes:
> [...]
>> There are a couple of pending issues, notably regarding locales in GRUB,
>> but nothing big hopefully, and nothing that changes the manual and
>> strings I believe.
>
> I've already pushed the changes for grub.  The only missing bit I've
> noticed today during some tests is that some strings in
> gnu/installer/parted.scm:user-partition-description still need some i18n
> work: format and G_.

Done in commit 8f71305e8f87bf15d158fb2726c4a46cdf36eaf5.

Ludo’.

New French PO file for 'guix-manual' (version 1.2.0-pre2)

[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 French team of translators.  The file is available at:

https://translationproject.org/latest/guix-manual/fr.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: Etymology of derivation

[Pjotr Prins]

On Mon, Nov 02, 2020 at 04:43:14PM +0100, Pierre Neidhardt wrote:
> Hi Arun!
> 
> Actually I don't understand what "message" would mean in "build-message".
> I'm more confused than with "derivation" :p

It is the minimal build information that the build-daemon requires. A
message to the build daemon in a way.

Pj.

New French PO file for 'guix-manual' (version 1.2.0-pre2)

[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 French team of translators.  The file is available at:

https://translationproject.org/latest/guix-manual/fr.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: Branching for v1.2?

[Julien Lepiller]

Le 2 novembre 2020 08:20:34 GMT-05:00, "Miguel Ángel Arruga Vivas" 
 a écrit :
>Hi simon,
>
>zimoun  writes:
>> Hi,
>>
>> On Sat, 31 Oct 2020 at 23:28, Ludovic Courtès  wrote:
>>
>>> Having pushed the (guix transformations) patch¹, which also updates
>the
>>> manual and thus requires yet some more translation work, I think I
>don’t
>>> have any serious changes to make and I’d be happy to branch now. 
>WDYT?
>>
>> I think it would be good to branch.
>>
>>
>>> There are a couple of pending issues, notably regarding locales in
>GRUB,
>>> but nothing big hopefully, and nothing that changes the manual and
>>> strings I believe.
>>
>> Does it break the system?
>> Miguel seems to say no.
>
>Only Ludo knows about which exact issues was thinking, I can speak only
>for myself. :-)
>
>Messages displayed by GRUB should be localized as declared on the
>operating-system with current master; menu items aren't translated yet
>because I have to work more on that implementation and I couldn't reach
>this release with something good, sorry. :-(
>
>> Does it downgrade the first impression that the user has?
>
>As far as my testing goes, all the bits that could lead to that are
>already solved on master too.
>
>>> Tuesday 6th is approaching very fast and probably we’re be a bit
>behind
>>> schedule, we’ll see.
>>
>> I think this Fri. Nov. 6th will be hard; but it is still doable if we
>> branch really soon.  Tomorrow?
>
>With my translator hat on: a new tarball for TP has to be generated
>before or after creating the branch (1.2.0-pre3).  If done tomorrow, I
>think the translations could need a bit later than Friday to catch up;
>Florian and Julien, what do you think?

I think I can manage the deadline on the 6th if there aren't too many changes, 
and we generate the tarball today or tomorrow. If we generate it later, we'll 
need to postpone the deadline to after the weekend I think.

>
>Happy hacking!
>Miguel

Re: Etymology of derivation

[Arun Isaac]

Thank you all for your inputs!

The original Nix publication was helpful. On page 22 of the full thesis,
it says:
--8<---cut here---start->8---
Derivation is Nix-speak for a component build action, which derives
the component from its inputs.
--8<---cut here---end--->8---

Direct loan words similar to "derivasyon" are possible. But, they would
be a last resort. வழித்தோன்றல் is surprisingly good, but I think I'll
construct a calque along the lines of "build-message". That seems to be
the most meaningful approach.

It's probably too much trouble now, but even in English, it would help
to have something more descriptive than "derivation". I remember
struggling with the term when first introduced to Guix. "build-message"
would have been much more self-descriptive.

Cheers!


signature.asc
Description: PGP signature

Re: bug#44053: ‘xdg-mime-database’ profile hook is slow

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Ludovic Courtès  skribis:
>
>> Apart from LibreOffice, I found that ‘share/mime/packages’ is provided
>> by at least: hugin, gcr, fontforge.  Most GUI packages don’t have it.
>> So in practice, we’re often rebuilding the exact same database.
>
> On closer inspection, the time-consuming bit is processing
> ‘share/mime/packages/freedesktop.org.xml’ (from ‘shared-mime-info’),
> which is quite large and leads to the creation of hundreds of file.  We
> end up re-processing it every time.  This is particularly wasteful
> because the ‘shared-mime-info’ package already contains the result of
> applying ‘update-mime-database’ to itself.

Based on these observations, I added a fast path to the
‘xdg-mime-database’ hook:

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

It’s down to 0s in the common case where the profile doesn’t contain any
packages providing ‘share/mime/packages’.

Ludo’.

Re: Hunspell dictionaries

[Bengt Richter]

Hi,

On +2020-11-01 10:41:23 +0100, Jonathan Brielmaier wrote:
> On 31.10.20 21:03, paul wrote:> Dear Guixers,
> > 
> > I was packaging an Italian dictionary for Hunspell, when I found this
> > link listing all the Hunspell dictionaries supported by Libreoffice [0].
> > 
> > This lead me to think about a function for defining dictionary packages
> > (very much based on aspell-dictionary from (gnu packages aspell)).
> 
> Hi Paul, that is nice. I think it's absolutly worth it making support of
> more languages easier :)
> 
> I worked back then on the hunspell-dict-de and we discussed that we
> should move the hunspell dicts out of libreoffice.scm as they are used
> by other programs as well.
> 
> So when you make a patch you could save that stuff in
> gnu/packages/hunspell.scm...
> 

Please forgive jumping in, but the the topic is dictionaries, soo...

For the heck of it, I blindly egrepped all the texi files of my clone
of the guix repo (for acronyms, I was guessing :)
My clone is in ~/wb/guix, currently about a week old.
--8<---cut here---start->8---
(cd ~/wb/guix;git log|head) =->
commit d22d129da903cf6c3382cff5226d81a881fed2aa
Author: Leo Prikler 
Date:   Tue Oct 27 13:55:53 2020 +0100

gnu: Add guile-filesystem.

* gnu/packages/guile-xyz.scm (guile-filesystem): New variable.
(guile2.0-filesystem guile2.2-filesystem): New variable.

Signed-off-by: Ludovic Courtès 
--8<---cut here---end--->8---
egrepping was for sequences of upper case Alpha chars at least 2 long.

I think it would be nice if this raw source could be turned into
a guix glossary/acronym dictionary with easy UI alongside
manual web and/or info pages ;)

--8<---cut here---start->8---
egrep -oh '([A-Z]{2,})' $(find ~/wb/guix -name '*texi')|sort|uniq -c|sort 
-h|sed -E 's/([0-9]+)[ \t]([A-Z]+)/\1:\2/g'|blockjust -w=64 > texi-nyms.txt

1:ABCDEFGHIJKLMNOPQRSTUVWXYZ 1:ABOUT 1:ACLOCAL 1:ACPI 1:ACTION
1:AD 1:ADDENDUM 1:ADH 1:AEBB 1:AF 1:AGGREGATION 1:AHCI 1:ALPM
1:AM 1:ANONYMOUS 1:ANOVA 1:ANY 1:APPLICABILITY 1:ATTR 1:AUTH
1:AUTO 1:AZERTY 1:BALLOON 1:BCM 1:BN 1:BREAK 1:BTHL 1:CABBA
1:CAML 1:CAPABILITY 1:CE 1:CET 1:CGIT 1:CH 1:CHANGED 1:CIFS
1:CIPHER 1:CLI 1:CLIENTCONFIG 1:CLOCAL 1:CM 1:CMD 1:CODE
1:COLLATE 1:COLLECTIONS 1:COMBINING 1:CONDUCT 1:CONNECT 1:CPATH
1:CRLF 1:CTEST 1:CTS 1:DATA 1:DBD 1:DBP 1:DBUS 1:DEFINITIONS
1:DEV 1:DEVPTS 1:DH 1:DIRS 1:DNSKEY 1:DOING 1:DOMAIN 1:DOMAINS
1:DPMS 1:DS 1:DSS 1:EA 1:EEO 1:EABI 1:ED 1:EDITION 1:EDITOR
1:ELS 1:EMACSLOADPATH 1:ENABLE 1:EUC 1:EXISTS 1:EXPORT 1:EXWM
1:FAILURE 1:FATAL 1:FB 1:FDC 1:FFF 1:FORMAT 1:FPM 1:FUTURE
1:GECOS 1:GHC 1:GOBJECT 1:GPT 1:GS 1:GSSD 1:GUID 1:HACKING 1:HAS
1:HC 1:HOST 1:HP 1:HTTPT 1:IANA 1:ICMP 1:IDENTIFICATION 1:IEEE
1:IMPORTANT 1:IMPURITIES 1:INDEPENDENT 1:INDEX 1:INSTANCES 1:IO
1:IPA 1:IT 1:ITIL 1:JDK 1:JFS 1:JLY 1:JPG 1:JULIA 1:KPI 1:KQ
1:LABEL 1:LIBRESSL 1:LICENSE 1:LINEAGE 1:LIRC 1:LOGINDISABLED
1:LOW 1:LSUB 1:LU 1:LV 1:LXDE 1:LXQT 1:MDA 1:ME 1:MIME 1:MMIO
1:MODIFICATIONS 1:MP 1:MTU 1:MUC 1:MULTIPLE 1:MX 1:MY 1:MZ
1:NASTY 1:NAT 1:NEON 1:NIC 1:NID 1:NIST 1:NMI 1:NOOP 1:NTFS
1:NTLM 1:OASIS 1:OE 1:OPEN 1:OPENSSL 1:OSX 1:PETS 1:PHC 1:PI
1:PKCS 1:PLATFORM 1:PO 1:POSSIBLE 1:PREAMBLE 1:PRIVATE 1:PS
1:PXE 1:QAAAQEA 1:QML 1:QMP 1:QP 1:QPA 1:QT 1:QUANTITY 1:QWERTY
 1:RADIUS 1:RCPT 1:READ 1:READERS 1:RECENT 1:RELICENSING 1:REST
1:REVISIONS 1:ROM 1:RP 1:RTS 1:RUN 1:SAM 1:SANE 1:SECRET
1:SESSION 1:SFTP 1:SHELL 1:SIGHUP 1:SIL 1:SITE 1:SLA 1:SOMEONE
1:SOMETHING 1:SONAME 1:SPECIAL 1:SPKI 1:SPNEGO 1:SRP 1:SSD
1:STARTTLS 1:STRENGTH 1:SUBSYSTEM 1:TERM 1:TERMINATION
1:TEXINPUTS 1:THAT 1:THIS 1:TRANSLATION 1:UPDATED 1:URLAUTH
1:UTC 1:UW 1:VALIDATION 1:VDAGENT 1:VERBATIM 1:VGA 1:VISUAL
1:VNC 1:VSZ 1:WARNINGS 1:WEB 1:WITH 1:WORKS 1:WRAPPER 1:WRITERS
1:WRS 1:WWAN 1:XA 1:XBAR 1:XCF 1:XEP 1:XFOO 1:XLFD 1:XPV 1:YAS
2:B 2:ACME 2:AE 2:ALLOW 2:AND 2:ARGRX 2:AT 2:BBB 2:BIND
2:BLK 2:BSD 2:BUNDLE 2:BY 2:CAINFO 2:CBC 2:CEA 2:CI 2:CIDR
2:COLORTERM 2:COPYING 2:CORES 2:CPE 2:CR 2:CURL 2:DATE 2:DDF
2:DE 2:DES 2:DESCRIPTION 2:DF 2:DIGEST 2:DISPLAY 2:DN
2:DOCUMENTS 2:DPI 2:DPM 2:DRIVER 2:DTD 2:DUSE 2:EDU 2:EF
2:ENGINE 2:EPOCH 2:EXAMINE 2:EXCL 2:EXECUTION 2:FA 2:FAT 2:FDE
2:FLAGS 2:FORWARD 2:FUSE 2:GITHUB 2:GPL 2:HDA 2:HMAC 2:HPC 2:IA
2:IMAPSSLR 2:INIT 2:INSTALL 2:IS 2:ISC 2:KB 2:KEYRING 2:LADSPA
2:LAN 2:LAYOUT 2:LC 2:LD 2:LDA 2:LEGU 2:LF 2:LGPL 2:LIBRARY
2:LIBS 2:LOGIN 2:LXQ 2:MAC 2:MAINTENANCE 2:MELPA 2:MIPS 2:MIT
2:MODULES 2:NAME 2:NAMESPACE 2:NDK 2:NOPASSWD 2:NORMAL 2:NOTE
2:NSEC 2:NULL 2:OL 2:OPAM 2:PATCH 2:PCSPKR 2:PKG 2:PNG 2:POSIX
2:PSK 2:PULSE 2:PWD 2:PYTHONPATH 2:QCOW 2:QWERTZ 2:RAPI 2:REJECT
2:REMOTE 2:RENEWED 2:RR 2:SA 2:SATA 2:SCHEME 2:SCM 2:SDL
2:SELECT 2:SGML 2:SLURM 2:SOCKS 2:SVN 

GNOME in Guix

[Leo Prikler]

Hi Danny,

Am Montag, den 02.11.2020, 11:17 +0100 schrieb Danny Milosavljevic:
> Hi,
> 
> On Mon, 02 Nov 2020 08:44:29 +0100
> Pierre Neidhardt  wrote:
> 
> > Danny Milosavljevic  writes:
> > > Not much more works yet because I've hit this (design) bug in
> Guix and/or 
> > > GNOME:
> > >
> > > * https://github.com/spk121/guile-gi/issues/96  
> > 
> > Have you tried g-golf?  The Nomad browser uses it, it may not
> suffer
> > from the aforementioned issue.
> > Thoughts on that?
> 
> It really depends on what you mean.  If it also uses gobject-
> introspection, it
> will have the same problem.
As much as I rant about nomad in IRC now and then, it is still a rather
sophisticated program, and as a user I have not yet encountered any
problem similar in effect to what is described here.  
The bugs I do encounter whenever I try it out for my own amusement are
much rather due to g-golf and emacsy being in rather early stages of
development and therefore not feature-complete.

I am not sure, whether the Nomad devs have encountered a problem
similar to Guile-GI#96 (I myself am not one), but the Guile-GI devs
speculate, that the problem is somewhat specific to their
implementation.
They also mention, that you should still be able to prototype your
application by using "--no-grafts" for the development environment.  Do
you still encounter Guile-GI#96 after packaging?  If so, you might want
to explain your situation upstream, so that they can better help you.

> Even gobject-introspection links to glib internally, then registers a
> class in
> that, THEN opens (potentially another) glib at runtime using dlopen
> in the same
> address same.
> I'm pretty sure that GNOME is not designed for that.  If you then use
> the
> dlopened glib to use the first-mentioned class, good luck with that.
> 
> The only reason it didn't fall onto the head of users of other
> distributions
> is because those don't support internal dependencies of packages at
> all--so
> you always have to update all in lockstep.  So the following can only
> happen
> in Guix:
> 
> If a library A has an input Q, and library B has the same input Q,
> and you
> use A and B in your program, and then you (guix-) update just B to
> use Q'
> (for example a newer version of Q) and recompile your program, then
> you have
> both Q and Q' in your process address space!
> 
> Q is an internal dependency of A, and by coincidence it's an internal
> dependency of B, too. Just because the internal dependency of B
> changed
> shouldn't change the internal depenency of A--that's what "internal"
> means.
Sure, but that's only if either of them ends up using a different
version.  That should not be the case for Guix' GNOME stack apart from
some bootstrap shenanigans, that don't really matter at the point of
application packages.

In order to make use of any GI in Guix, you need
- the GI bindings (one of python-gobject, g-golf, guile-gi, gjs, etc.),
- *and* the packages of the libraries themselves
as inputs to your package.  So the resulting graph for your package
will always be complete and should only contain one relevant package
per library.

And yes, you can totally do that on other distros as well.  (One way to
do so would be to use Guix on them ;D)  It's just that users typically
shy away from installing conflicting versions of the same package,
whereas Guix will happily allow them to coexist and go out of its way
to deal with potential issues arising from that.

> I think that the gobject type registry does not consider that it can
> happen
> to have to classes with the same class name, registered in respective
> internal dependencies.  The objects of the internal dependency
> shouldn't
> be available to the outside program in the first place.

Yes it does, or at least you can check, whether a type of that name is
already registered and bail.  You could even do so in Guile-GI as you
are instantiating the types, but I doubt upstream devs want to bail
when they encounter a reserved type.

> That means actually we should propagate a lot of GNOME inputs, which
> means
> in practice what a regular user has in his profile will be very much
> like
> in other distributions, and internal dependencies will become a weird
> corner
> feature nobody uses.

No, it does not.  It perhaps means, that we might want to take care of
GI_TYPELIB_PATH in glib-or-gtk-build-system.  It at least would make
sense to add logic dealing with gobject-introspection to glib-or-gtk-
wrap, which could then be reused in other build systems as well.

Packages, be they GNOME or not, should be dynamically linked, so that
Guix can correctly graft them.  Assuming correct grafting, the library
loaded from GI_TYPELIB_PATH should be the same as the library loaded
internally with the build setup I discussed earlier. 

> Does anyone know how to make dlopen fail on duplicate global
> variables?
No, but I don't think that is too relevant here.  See my earlier point
on how it *is* possible to handle this with the 

Re: Branching for v1.2?

[Miguel Ángel Arruga Vivas]

Hi simon,

zimoun  writes:
> Hi,
>
> On Sat, 31 Oct 2020 at 23:28, Ludovic Courtès  wrote:
>
>> Having pushed the (guix transformations) patch¹, which also updates the
>> manual and thus requires yet some more translation work, I think I don’t
>> have any serious changes to make and I’d be happy to branch now.  WDYT?
>
> I think it would be good to branch.
>
>
>> There are a couple of pending issues, notably regarding locales in GRUB,
>> but nothing big hopefully, and nothing that changes the manual and
>> strings I believe.
>
> Does it break the system?
> Miguel seems to say no.

Only Ludo knows about which exact issues was thinking, I can speak only
for myself. :-)

Messages displayed by GRUB should be localized as declared on the
operating-system with current master; menu items aren't translated yet
because I have to work more on that implementation and I couldn't reach
this release with something good, sorry. :-(

> Does it downgrade the first impression that the user has?

As far as my testing goes, all the bits that could lead to that are
already solved on master too.

>> Tuesday 6th is approaching very fast and probably we’re be a bit behind
>> schedule, we’ll see.
>
> I think this Fri. Nov. 6th will be hard; but it is still doable if we
> branch really soon.  Tomorrow?

With my translator hat on: a new tarball for TP has to be generated
before or after creating the branch (1.2.0-pre3).  If done tomorrow, I
think the translations could need a bit later than Friday to catch up;
Florian and Julien, what do you think?

Happy hacking!
Miguel


signature.asc
Description: PGP signature

Re: bug#44053: ‘xdg-mime-database’ profile hook is slow

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Apart from LibreOffice, I found that ‘share/mime/packages’ is provided
> by at least: hugin, gcr, fontforge.  Most GUI packages don’t have it.
> So in practice, we’re often rebuilding the exact same database.

On closer inspection, the time-consuming bit is processing
‘share/mime/packages/freedesktop.org.xml’ (from ‘shared-mime-info’),
which is quite large and leads to the creation of hundreds of file.  We
end up re-processing it every time.  This is particularly wasteful
because the ‘shared-mime-info’ package already contains the result of
applying ‘update-mime-database’ to itself.

Unfortunately, AIUI,

  update-mime-database(X ∪ Y) ≠ update-mime-database(X) ∪ 
update-mime-database(Y)

(For example, the files
‘share/mime/{globs,magic,XMLnamespaces,subclasses,aliases,types,generic-icons,icons,treemagic,mime.cache}’
concatenate info from X and Y.)

So it would seem we cannot simply used the pre-built database from
‘shared-mime-info’ and merge it with that of the other packages, at
least not without changing ‘update-mime-database’ or re-implementing
parts of it on our side.

Ludo’.

Re: Haskell package versions (was bug#44174: [PATCH v2 00/15] Add hledger and its dependencies.)

[zimoun]

Hi,

On Sun, 1 Nov 2020 at 21:27, Ricardo Wurmus  wrote:

> The documentation should be updated to warn against upgrading to
> arbitrary versions.

Does it make sense to add a check in the linter?  Or in refresh?

All the best,
simon

Re: bug#43879: Problem with graphical installer

[Miguel Ángel Arruga Vivas]

Hi Mathieu,

Mathieu Othacehe  writes:
> "All its data will be lost" refers to the hard drive. Maybe we should
> say "Their data will be lost", referring to the partitions?

Thanks for the review, I overlooked that.

> Otherwise, looks nice.

Pushed as bc9e66f0feb25c77898222cfe5f3ef484dcee95e with the message
changed as suggested.

Happy hacking!
Miguel


signature.asc
Description: PGP signature

Re: bug#44053: ‘xdg-mime-database’ profile hook is slow

[Ludovic Courtès]

Hi,

Joshua Branson  skribis:

> The "XDG MIME database" takes a while.
>
> #+BEGIN_SRC sh :results output :exports both
> time guix build --check $(guix gc -R $(guix gc --derivers $(readlink -f 
> ~/.guix-profile)) |grep xdg-mime-database.drv)
> #+END_SRC
>
>
> #+RESULTS:
> : The following profile hook will be built:
> :/gnu/store/lmhklgdscbfp5c6gl81skyz0azfg156m-xdg-mime-database.drv
> : building XDG MIME database...
> : successfully built 
> /gnu/store/lmhklgdscbfp5c6gl81skyz0azfg156m-xdg-mime-database.drv
> : successfully built 
> /gnu/store/lmhklgdscbfp5c6gl81skyz0azfg156m-xdg-mime-database.drv
> : /gnu/store/x8q8g9l0jhrpmjjm3xsh3ib1z8l79cyx-xdg-mime-database
> :
> : real0m43.716s
> : user0m3.626s
> : sys 0m0.258s

I found that the MIME database is computed only over the subset of the
packages in your profile that provide ‘share/mime/packages’, plus
‘shared-mime-info’.

In my profile, only LibreOffice provides that directory, so the union is
made over these two directories and that’s what ‘update-mime-database’
works on.

Apart from LibreOffice, I found that ‘share/mime/packages’ is provided
by at least: hugin, gcr, fontforge.  Most GUI packages don’t have it.
So in practice, we’re often rebuilding the exact same database.

Here’s the time taken by ‘update-mime-database’ alone:

--8<---cut here---start->8---
ludo@ribbon ~$ mkdir -p /tmp/mime/share/mime/packages
ludo@ribbon ~$ cd /tmp/mime/share/mime/packages
ludo@ribbon /tmp/mime/share/mime/packages$ for i in $(guix build libreoffice ^C
ludo@ribbon /tmp/mime/share/mime/packages$ for i in 
~/.guix-profile/share/mime/packages/* ; do ln -s $i ; done
ludo@ribbon /tmp/mime/share/mime/packages$ ls -l
totalo 8
lrwxrwxrwx 1 ludo users 64 Nov  2 11:46 freedesktop.org.xml -> 
/home/ludo/.guix-profile/share/mime/packages/freedesktop.org.xml
lrwxrwxrwx 1 ludo users 60 Nov  2 11:46 libreoffice.xml -> 
/home/ludo/.guix-profile/share/mime/packages/libreoffice.xml
ludo@ribbon /tmp/mime/share/mime/packages$ cd /tmp/mime/
ludo@ribbon /tmp/mime$ time update-mime-database -V /tmp/mime/share/mime
Updating MIME database in /tmp/mime/share/mime...

Parsing source file /tmp/mime/share/mime/packages/freedesktop.org.xml...
Parsing source file /tmp/mime/share/mime/packages/libreoffice.xml...
Wrote 1124 strings at 2c - 6310
Wrote aliases at 6310 - 6be4
Wrote parents at 6be4 - 8468
Wrote literal globs at 8468 - 855c
Wrote suffix globs at 855c - 13514
Wrote full globs at 13514 - 13554
Wrote magic at 13554 - 2065c
Wrote namespace list at 2065c - 20798
Wrote icons list at 20798 - 2079c
Wrote generic icons list at 2079c - 213b8
Wrote types list at 213b8 - 22020

Note that '/tmp/mime/share' is not in the search path
set by the XDG_DATA_HOME and XDG_DATA_DIRS
environment variables, so applications may not
be able to find it until you set them. The
directories currently searched are:

- /home/ludo/.local/share
- /home/ludo/.guix-profile/share
- /run/current-system/profile/share
- /home/ludo/.guix-profile/share
- /run/current-system/profile/share


real0m2.166s
user0m0.278s
sys 0m0.056s
--8<---cut here---end--->8---

To be compared with:

--8<---cut here---start->8---
$ drv="$(guix gc -R $(guix gc --derivers $(readlink -f ~/.guix-profile)) |grep 
xdg-mime-database.drv)"
$ time guix build --check $drv
The following profile hook will be built:
   /gnu/store/jrmwsxpz3wmq37zx29lvb0r9nvcmdviz-xdg-mime-database.drv
building XDG MIME database...
successfully built 
/gnu/store/jrmwsxpz3wmq37zx29lvb0r9nvcmdviz-xdg-mime-database.drv
/gnu/store/npvj2sr9kxx48znh7zc8zmzwzs6brc90-xdg-mime-database

real0m3.670s
user0m1.428s
sys 0m0.029s
--8<---cut here---end--->8---

Thus, the build time itself is entirely taken by ‘update-mime-database’
(the 1.4s above is “overhead” in ‘guix build’ it would seem).

Ludo’.

Re: Porting Guix to RISCV

[Jan Nieuwenhuizen]

Vagrant Cascadian writes:

Hey!

> On 2020-10-31, Pjotr Prins wrote:
>> Anyone interested in porting GNU Mes and GNU Guix to RISCV?

...trying not to get noticed, /me looks at their full plate (cough Mes +
ARM) and then slowly looks over shoulder...

>> We can try
>> and purchase the hardware. We have a Polarfire running
>>
>>   https://www.crowdsupply.com/microchip/polarfire-soc-icicle-kit
>>
>> and there are more options coming. I am happy to support such an
>> initiative and buy the hardware.
>
> I added a few RISC-V related packages to guix already:
>
>   u-boot-qemu-riscv64
>   u-boot-qemu-riscv64-smode
>   u-boot-sifive-fu540
>   opensbi-sifive-fu540
>   opensbi-qemu-sifive-u
>   linux-libre-riscv64-generic
>
> Got as far as booting a kernel in qemu, at least. So the basic boot
> infrastructure is at least partly there...
>
> So, I guess you could count me as interested. :)

Great!  Anyway, runing RISC-V on Guix (can I dream "the Hurd"?) is an
amazing perspective, so count me in!  Did anyone try building bootstrap
binaries for RISC-V?

Greetings,
Janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Gtk via the web

[Danny Milosavljevic]

Hi Ludo,

On Sun, 01 Nov 2020 22:53:26 +0100
Ludovic Courtès  wrote:

> Lars-Dominik Braun  skribis:
> 
> Long ago Dave Thompson wrote guix-web, which allowed you to install
> packages (you’d run it as your user):
> 
>   
> https://archive.softwareheritage.org/browse/origin/directory/?origin_url=https://gitorious.org/guix-web/guix-web.git
> 
> It’s an interesting approach with several advantages (in particular it
> can be quickly developed), though I must say I remain unenthusiastic
> about using web browsers for local GUIs.

You can use Gtk applications in the web using Broadway.  That's why I enabled
Broadway in our gtk+ package a long time ago.

Try it:

broadwayd :1 &
GDK_BACKEND=broadway BROADWAY_DISPLAY=:1 gedit &
icecat http://localhost:8081/

(broadwayd is in gtk+'s "bin" output)

Not saying we have to do that--but it's possible.


pgpyuMpivDzvt.pgp
Description: OpenPGP digital signature

Re: Guix Front End (GUI) and making it more mainstream, popular in scientific community.

[Taylan Kammer]

On 01.11.2020 22:53, Ludovic Courtès wrote:

Hi,

Lars-Dominik Braun  skribis:


[…] from my point of view, the good direction would be a “web-app frontend”,
similarly to git-annex-assistant [1].  This design is more flexible because
it could be used locally *and* could also be the front-end of some servers
(e.g., build farms).

I have something like this on my todo list as well. It would probably be more
of a manifest file editor though, since we use manifest files for
reproducibility.


Long ago Dave Thompson wrote guix-web, which allowed you to install
packages (you’d run it as your user):

   
https://archive.softwareheritage.org/browse/origin/directory/?origin_url=https://gitorious.org/guix-web/guix-web.git

It’s an interesting approach with several advantages (in particular it
can be quickly developed), though I must say I remain unenthusiastic
about using web browsers for local GUIs.

Thanks,
Ludo’.



While I empathize with concerns about web browsers, I have to admit that 
I'm absolutely blown away by Vue.js + BootstrapVue.  (Using node & npm.)


My other GUI development experiences include iOS, Android, and C#.NET. 
I found Vue.js with Bootstrap to be on a completely different level.



Just wanted to throw this out there, even though I know it's heresy!

- Taylan

GNOME in Guix

[Danny Milosavljevic]

Hi,

On Mon, 02 Nov 2020 08:44:29 +0100
Pierre Neidhardt  wrote:

> Danny Milosavljevic  writes:
> > Not much more works yet because I've hit this (design) bug in Guix and/or 
> > GNOME:
> >
> > * https://github.com/spk121/guile-gi/issues/96  
> 
> Have you tried g-golf?  The Nomad browser uses it, it may not suffer
> from the aforementioned issue.
> Thoughts on that?

It really depends on what you mean.  If it also uses gobject-introspection, it
will have the same problem.

Even gobject-introspection links to glib internally, then registers a class in
that, THEN opens (potentially another) glib at runtime using dlopen in the same
address same.
I'm pretty sure that GNOME is not designed for that.  If you then use the
dlopened glib to use the first-mentioned class, good luck with that.

The only reason it didn't fall onto the head of users of other distributions
is because those don't support internal dependencies of packages at all--so
you always have to update all in lockstep.  So the following can only happen
in Guix:

If a library A has an input Q, and library B has the same input Q, and you
use A and B in your program, and then you (guix-) update just B to use Q'
(for example a newer version of Q) and recompile your program, then you have
both Q and Q' in your process address space!

Q is an internal dependency of A, and by coincidence it's an internal
dependency of B, too. Just because the internal dependency of B changed
shouldn't change the internal depenency of A--that's what "internal"
means.

Otherwise the modules aren't really modular (because they then don't isolate
from each other).

I think that the gobject type registry does not consider that it can happen
to have to classes with the same class name, registered in respective
internal dependencies.  The objects of the internal dependency shouldn't
be available to the outside program in the first place.

That means actually we should propagate a lot of GNOME inputs, which means
in practice what a regular user has in his profile will be very much like
in other distributions, and internal dependencies will become a weird corner
feature nobody uses.

Does anyone know how to make dlopen fail on duplicate global variables?

I tried to make it fail but I can't get it to work:

I tried:

File d1.c contains:
int x;

File d2.c contains:
int x;

File a.c contains:

#include 
#include 

// 
https://stackoverflow.com/questions/43582165/handling-global-variables-in-shared-object

int main() {
if (!dlopen("./d1.so", RTLD_NOW | RTLD_GLOBAL /*| RTLD_DEEPBIND*/)) {
fprintf(stderr, "dlerror: %s\n", dlerror());
return 1;
}
if (!dlopen("./d2.so", RTLD_NOW | RTLD_GLOBAL /*| RTLD_DEEPBIND*/)) {
fprintf(stderr, "dlerror: %s\n", dlerror());
return 2;
}
return 0;
}

Then I do:

$ gcc -fPIC -shared -Wl,--export-dynamic -o d1.so d1.c
$ gcc -fPIC -shared -Wl,--export-dynamic -o d2.so d2.c
$ gcc a.c -ldl
$ ./a.out
$ echo $?
0


pgprGMw9IB3hY.pgp
Description: OpenPGP digital signature

Re: Branching for v1.2?

[zimoun]

Hi,

On Sat, 31 Oct 2020 at 23:28, Ludovic Courtès  wrote:

> Having pushed the (guix transformations) patch¹, which also updates the
> manual and thus requires yet some more translation work, I think I don’t
> have any serious changes to make and I’d be happy to branch now.  WDYT?

I think it would be good to branch.


> There are a couple of pending issues, notably regarding locales in GRUB,
> but nothing big hopefully, and nothing that changes the manual and
> strings I believe.

Does it break the system?
Miguel seems to say no.

Does it downgrade the first impression that the user has?


> Tuesday 6th is approaching very fast and probably we’re be a bit behind
> schedule, we’ll see.

I think this Fri. Nov. 6th will be hard; but it is still doable if we
branch really soon.  Tomorrow?


All the best,
simon

Re: Guix Front End (GUI) and making it more mainstream, popular in scientific community.

[Jan Nieuwenhuizen]

Pierre Neidhardt writes:

> Ludovic Courtès  writes:
>
>> This reminds me of Janneke’s Guimax:
>>
>>   https://gitlab.com/janneke/guimax
>>
>> It’s rather about providing a Guile UI, but perhaps it could also serve
>> as the basis of a Guix GUI?
>
> I haven't heard about this, thanks for the hint, I'll look into it!

It's possibly more worthwile to look at Nomad; the interesting theme of
both is: fully guile-based gui with emacsy integration.  So, a
self-documenting gui program in Guile.

Janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com