Re: Defining user services in Guix.

[Mekeor Melire]

Mathieu Othacehe  writes:

>>> But you can start your own shepherd under your user account and have that 
>>> shepherd manage user services - it's nice.
>
> Thank you Danny for the details procedure. I'll use that for now !
>
>> Surely we could do better, like providing unprivileged users with a tool
>> akin to ‘guix system reconfigure’ but to manage their own services.
>> This came up several times in the past.
>
> Well, I think it's too bad that user services can't be handled as easily
> as the other services in Guix.
>
> I would be eager to participate to some sort of guix system reconfigure
> --user-services that would allow people to write and share their
> unpriviledged services :).

Btw, beside user-specific services, we also already discussed
user-specific aliases for the `guix ...` commands. So now, there are at
least two things a user-specific configuration file could contain. :)

One, the system.scm would contain

 (operating-system
; ...
(services
; ...
))

And secondly, each user could have a user.scm e.g. like

(user-configuration
; ...
(aliases
'(
("sysrec" "system reconfigure")
("pl" "pull")
; ...
))
(services
(emacs-daemon-service)
(dzen-service)
; ...
))

or similar :)

--
mekeor ~ EDD3 DFFA 76F6 11C0 145F 9A99 AC85 BAD8 A2F8 C868

Re: [PATCH] gnu: Add Xfce Notification Daemon.

[Efraim Flashner]

On Mon, Apr 24, 2017 at 08:54:41PM +0200, Petter wrote:
> Hei Marius,
> 
> > > +(native-inputs
> > > + `(("intltool" ,intltool)
> > > +   ("pkg-config" ,pkg-config)))
> > > +(propagated-inputs
> > > + `(("glib:bin" ,glib "bin")))  
> > 
> > Do you know why glib:bin needs to be propagated here? Looking at
> > gnome.scm, it's usually a "native-input". If this program requires
> > some of the executables from that package at runtime, it's better to
> > patch it with the absolute paths.
> 
> I don't know. I just saw it done like this in another package in
> xfce.scm.
> 
> Reading up on inputs I see propagated-inputs "will be installed
> alongside the package they belong to". Yeah, let's see if we can avoid
> that.
> 
> I've adjusted the recipe to test with glib:bin as a native-input,
> it builds fine, and a quick remove and install shows no issues either.
> However, the notification system still worked with it removed, so I'm
> not certain the new one is the one used. I will test this further next
> time I boot my system.
> 
> > Other than that looks great! I'd add an @code{...} wrapper around
> > "org.freedesktop.Notifications" in the description, but that can be
> > fixed up before committing, no need for a new patch.
> 
> I'll make sure to add this if I produce a new patch.
> 
> Thanks for the feedback!
> 
> Best,
> Petter

The collection of inputs makes me wonder if it should be glib-or-gtk
build-system and not "just" gnu-build-system. I don't have a good way to
test if its necessary, but I'd look around.


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


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add Xfce Notification Daemon.

[Petter]

Hei Marius,

> > +(native-inputs
> > + `(("intltool" ,intltool)
> > +   ("pkg-config" ,pkg-config)))
> > +(propagated-inputs
> > + `(("glib:bin" ,glib "bin")))  
> 
> Do you know why glib:bin needs to be propagated here? Looking at
> gnome.scm, it's usually a "native-input". If this program requires
> some of the executables from that package at runtime, it's better to
> patch it with the absolute paths.

I don't know. I just saw it done like this in another package in
xfce.scm.

Reading up on inputs I see propagated-inputs "will be installed
alongside the package they belong to". Yeah, let's see if we can avoid
that.

I've adjusted the recipe to test with glib:bin as a native-input,
it builds fine, and a quick remove and install shows no issues either.
However, the notification system still worked with it removed, so I'm
not certain the new one is the one used. I will test this further next
time I boot my system.

> Other than that looks great! I'd add an @code{...} wrapper around
> "org.freedesktop.Notifications" in the description, but that can be
> fixed up before committing, no need for a new patch.

I'll make sure to add this if I produce a new patch.

Thanks for the feedback!

Best,
Petter


pgpRiM1Od8iDq.pgp
Description: OpenPGP digital signature

Re: [PATCH] gnu: Add Xfce Notification Daemon.

[Marius Bakke]

Hi Petter, thanks a lot for this!

The patch looks good, I only have one question (not very familiar with
gtk packaging either, so please excuse my ignorance).


> * gnu/packages/xfce.scm (xfce4-notifyd): New variable.

[...]

> +(native-inputs
> + `(("intltool" ,intltool)
> +   ("pkg-config" ,pkg-config)))
> +(propagated-inputs
> + `(("glib:bin" ,glib "bin")))

Do you know why glib:bin needs to be propagated here? Looking at
gnome.scm, it's usually a "native-input". If this program requires some
of the executables from that package at runtime, it's better to patch it
with the absolute paths.

Other than that looks great! I'd add an @code{...} wrapper around
"org.freedesktop.Notifications" in the description, but that can be
fixed up before committing, no need for a new patch.

> +(inputs
> + `(("gtk+" ,gtk+)
> +   ("libxfce4util" ,libxfce4util)
> +   ("libxfce4ui" ,libxfce4ui)
> +   ("xfconf" ,xfconf)
> +   ("libnotify" ,libnotify)))
> +(home-page 
> "https://goodies.xfce.org/projects/applications/xfce4-notifyd;)
> +(synopsis "Show notification bubbles on Xfce")
> +(description
> + "The Xfce Notify Daemon (xfce4-notifyd for short) is a smallish program
> +that implements the “server-side” portion of the Freedesktop desktop
> +notifications specification.  Applications that wish to pop up a notification
> +bubble in a standard way can implicitly make use of xfce4-notifyd to do so by
> +sending standard messages over D-Bus using the org.freedesktop.Notifications
> +interface.")
> +(license gpl2)))

It is indeed version 2 only..


signature.asc
Description: PGP signature

Re: Suggest A debian-style menu system for guix

[Hartmut Goebel]

Am 24.04.2017 um 14:48 schrieb Feng Shu:
> All I want to say is that:  we *must* add menu info in "package define"
> if users of this package *real need* a menu instead of waiting upstream
> to write a .desktop.

Well, if there is no desktop file, wouldn't it be sufficient to add one?

-- 
▶︎Digitalcourage e.V., Hartmut Goebel, Marktstr. 18, D-33602 Bielefeld
Tel: +49-521-1639 1639 | Fax: 0521-61172 | m...@digitalcourage.de
https://digitalcourage.de | http://bigbrotherawards.de |
--
Für Bürgerrechte, Datenschutz und eine lebenswerte digitale Welt
-
Online spenden: https://digitalcourage.de/spende/

Vorratsdatenspeicherung? Nicht schon wieder! Unterstützen Sie
unsere Verfassungsbeschwerde: https://digitalcourage.de/weg-mit-vds

Re: [PATCH] gnu: Add Xfce Notification Daemon.

[Petter]

Hi again,

Forgot previously to run `guix lint` on this; added a space between
sentences now.

Also rewrote the synopsis.

Best,
Petter


From 2a31bcfa1b39c9403fb2dab3ab073def3ab8e140 Mon Sep 17 00:00:00 2001
From: Petter 
Date: Fri, 21 Apr 2017 15:33:22 +0200
Subject: [PATCH] gnu: Add Xfce Notification Daemon.

* gnu/packages/xfce.scm (xfce4-notifyd): New variable.
---
 gnu/packages/xfce.scm | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/gnu/packages/xfce.scm b/gnu/packages/xfce.scm
index fce47d93c..00d958cc8 100644
--- a/gnu/packages/xfce.scm
+++ b/gnu/packages/xfce.scm
@@ -5,6 +5,7 @@
 ;;; Copyright © 2016 Florian Paul Schmidt 
 ;;; Copyright © 2016 Kei Kebreau 
 ;;; Copyright © 2017 Ricardo Wurmus 
+;;; Copyright © 2017 Petter 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -850,3 +851,41 @@ calendar applications.  It also includes a panel clock 
plugin and an
 international clock application capable of simultaneously showing clocks from
 several different time zones.")
 (license gpl2+)))
+
+(define-public xfce4-notifyd
+  (package
+(name "xfce4-notifyd")
+(version "0.3.6")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "http://archive.xfce.org/src/apps/;
+  name "/" (version-major+minor version) "/"
+  name "-" version ".tar.bz2"))
+  (sha256
+   (base32
+"1ybcfqfynr33g5hp2lgq17s8qyx7rq6fd2iwrpwcvm6kml6prjpl"
+(build-system gnu-build-system)
+(arguments
+ `(#:configure-flags
+   (list (string-append "--prefix=" %output
+(native-inputs
+ `(("intltool" ,intltool)
+   ("pkg-config" ,pkg-config)))
+(propagated-inputs
+ `(("glib:bin" ,glib "bin")))
+(inputs
+ `(("gtk+" ,gtk+)
+   ("libxfce4util" ,libxfce4util)
+   ("libxfce4ui" ,libxfce4ui)
+   ("xfconf" ,xfconf)
+   ("libnotify" ,libnotify)))
+(home-page "https://goodies.xfce.org/projects/applications/xfce4-notifyd;)
+(synopsis "Show notification bubbles on Xfce")
+(description
+ "The Xfce Notify Daemon (xfce4-notifyd for short) is a smallish program
+that implements the “server-side” portion of the Freedesktop desktop
+notifications specification.  Applications that wish to pop up a notification
+bubble in a standard way can implicitly make use of xfce4-notifyd to do so by
+sending standard messages over D-Bus using the org.freedesktop.Notifications
+interface.")
+(license gpl2)))
-- 
2.12.2



On Fri, 21 Apr 2017 15:37:45 +0200
Petter  wrote:

> Hi Guix,
> 
> Be extra critical while reviewing this patch, I'm not good at this.
> 
> (Today I learned that a provided DBus service file first takes effect
> after installing. I wasn't having any luck testing directly from
> store. Thanks again wingo!)
> 
> Best,
> Petter

From 2a31bcfa1b39c9403fb2dab3ab073def3ab8e140 Mon Sep 17 00:00:00 2001
From: Petter 
Date: Fri, 21 Apr 2017 15:33:22 +0200
Subject: [PATCH] gnu: Add Xfce Notification Daemon.

* gnu/packages/xfce.scm (xfce4-notifyd): New variable.
---
 gnu/packages/xfce.scm | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/gnu/packages/xfce.scm b/gnu/packages/xfce.scm
index fce47d93c..00d958cc8 100644
--- a/gnu/packages/xfce.scm
+++ b/gnu/packages/xfce.scm
@@ -5,6 +5,7 @@
 ;;; Copyright © 2016 Florian Paul Schmidt 
 ;;; Copyright © 2016 Kei Kebreau 
 ;;; Copyright © 2017 Ricardo Wurmus 
+;;; Copyright © 2017 Petter 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -850,3 +851,41 @@ calendar applications.  It also includes a panel clock plugin and an
 international clock application capable of simultaneously showing clocks from
 several different time zones.")
 (license gpl2+)))
+
+(define-public xfce4-notifyd
+  (package
+(name "xfce4-notifyd")
+(version "0.3.6")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "http://archive.xfce.org/src/apps/;
+  name "/" (version-major+minor version) "/"
+  name "-" version ".tar.bz2"))
+  (sha256
+   (base32
+"1ybcfqfynr33g5hp2lgq17s8qyx7rq6fd2iwrpwcvm6kml6prjpl"
+(build-system gnu-build-system)
+(arguments
+ `(#:configure-flags
+   (list (string-append "--prefix=" %output
+(native-inputs
+ `(("intltool" ,intltool)
+   ("pkg-config" ,pkg-config)))
+(propagated-inputs
+ `(("glib:bin" ,glib "bin")))
+(inputs
+ `(("gtk+" ,gtk+)
+   ("libxfce4util" ,libxfce4util)
+   ("libxfce4ui" ,libxfce4ui)
+   ("xfconf" ,xfconf)
+   ("libnotify" ,libnotify)))
+

Trust and reproducible build (was: Help needed from Java developer to finish maven)

[Hartmut Goebel]

Am 24.04.2017 um 03:20 schrieb Hilco Wijbenga:
> First, if it's about trust ("am I really running a stock,
> unmanipulated Maven") then there are the checksums and signatures on
> the download page which exist for exactly that purpose.

While  signatures are very useful in many cases, in this case they are
not. A signature on a JAR file only proofs that the JAR file was build
by some person or organization. It does not proof that the content of
the JAR file is exactly what was produced when compiling the source.

> If you feel
> you cannot rely on those then why trust the SCM that holds the Maven
> code? 

The source can be reviews, the JAR-file content not. (One could
disassemble and reverse engineer it, but for this you need to trust
another tool: the disassembler. And then you still have to review the code.)

> Second, as an end user this makes it even harder to trust the end
> result. I now have to trust both the Maven devs *and* the Guix devs
> who worked on the packages.

Now this is where reproducible build steps in: You don't need to trust
the guix developers. Package descriptions are quite easy to review for
code manipulations (even ugly and long ones like the one for java and
the one for maven). So you can get the maven source-code from some
different source, easily verify the one you have is unchanged and build
it. And you will get the same checksums as anybody else building maven
via guix (on the same platform an guix version). Yes, you still have to
trust the guix developers to use a valif version of the C-compiler (and
a few other tools), but this is *much* less to trust compared a other
operation system distributions (Redhat, Fedora, Debian, Windows, OS X,
Solaris), where you have no chance to verify the code.

> (By the way, I run Gentoo GNU/Linux so I am very familiar with
> building from source. For me (and Gentoo) it's more about control and
> performance than anything else, though.)

Soi your aim is different than Guix's aim :-)

> But, still, building such a JAR from source (once Maven is
> available) takes little effort and so is worth it.

You are absolutely right. But "once Maven is available" is the key to
all of this.

> :-) Well, no, of course not. Maven isn't at the pre alpha state
> anymore. So in the spirit of "eat your own dogfood", Maven builds with
> Maven. 

Umm, well,,  It would help a lot if there would be some "minimal
maven" which could be used for bootstrapping. But even a "minimal Maven"
need tons of other packages

> Right, that makes perfect sense except for the part where you jump
> through hoops and make unexpected changes to Maven just to be able to
> build it in a highly unorthodox way. ;-) :-)

Be ensured that I have no plan at all to change maven. in any way. I'm
not going to make changes to Maven. I simply try bootstrapping it from
source. If there would be some "official" way, I would use it. What I'm
doing is simply adption the build.xml in guix. (Hmm, thinking on this,
maybe I can trip down my description to manipulate the build.xml. But I
don't think this is of much use since I most probably could only reuse
two simple tasks.)

Please keep in mind that Maven is not a compiler. its just a build tool.
So its easy to compare the build results from the guix package
description with whatever Maven builds when it is bootstrapping itself.
And I'm confident that as soon as I make maven to bootstrap itself from
source, it will be correct.

> According to msg00536 you patched Maven to use different JARs and
> versions. Obviously, that creates a problem so don't do that. Stick
> with the JARs/versions that Maven was built with and all will be well.

Please try to reproduce what I've done. The error message I posted is in
now way related to any version change, since when using the tar-ball I
could change the version and still bootstrap maven.As opposed to the
guix description, where maven fails to run quite early.

> But you would be much better off if you dropped this whole approach as
> I mentioned above. Even if you somehow made it work, it would be
> unreliable.

It would be much better if you'd help finding the cause of the error
message instead of spending time arguing about the way :-) No offence
meant, but adding precompiled JARS from maven central is not an option.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Suggest A debian-style menu system for guix

[William Seddon]

On 24 April 2017 at 11:28, Feng Shu  wrote:
> #+BEGIN_COMMENT
>  Before the advent of update-menus, when the sysadmin installed a package 
> onto a Debian system, they would need to edit various window manager config 
> files to make the new program show up on, for example, fvwm's menus. The 
> menus could easily become out of sync with what programs were actually 
> available, with some menu items that didn't work, and other programs that 
> lacked a menu entry. update-menus and Debian's menu package aim to solve this 
> problem.
>
> update-menus automatically generates menus of installed programs for window 
> managers and other menu programs. It should be run whenever a menu file or 
> menu-method file is changed. update-menus will be ran automatically when 
> Debian packages that contain menu files are installed or removed from the 
> system. Users themselves can add/delete menu items, and should then run 
> update-menus as that user, thus creating window-manager startup files that 
> are used in preference to the systemwide files.
> #+END_COMMENT
>

Don't most/all WMs use .desktop files for this sort of thing?
The .desktop files are, if I recall correctly, also used to build menus.
If this is the case then I don't fully understand the point of
Debian's update-menu, shouldn't the XDG standard be used?

There is an extra spec used for extending .desktop files for menu use:
https://specifications.freedesktop.org/menu-spec/menu-spec-latest.html

Re: Guile bindings of GnuTLS are missing (was: Help needed from Java developer to finish maven)

[Catonano]

2017-04-24 14:58 GMT+02:00 Hartmut Goebel :

>
> Yes, this is one of the issues bugging me to quite often.


I'm not sure I understand. This doesn't happen with the guix checkout that
I usually build

>
> Within the
> environment you'll also need to run:
>
> export SSL_CERT_DIR="$GUIX_ENVIRONMENT/etc/ssl/certs"
> export SSL_CERT_FILE="$GUIX_ENVIRONMENT/etc/ssl/certs/ca-certificates.crt"
> export GIT_SSL_CAINFO="$SSL_CERT_FILE"
>
> (This is why I wrote myself a script for setting up a guix environment.)


Good to know
Should the guile-gnutls issue be overcome, I will try this too
Thanks

Re: Suggest A debian-style menu system for guix

[Feng Shu]

ng0  writes:

> Feng Shu transcribed 1.5K bytes:
>> ng0  writes:
>> 
>> > tumashu transcribed 1.0K bytes:
>> >> Debian menu system 
>> >> (https://www.debian.org/doc/packaging-manuals/menu.html/ch3.html) is a 
>> >> very useful tool,
>> >> is it possible develop a similar tool for guix?
>> >
>> > Could you explain what this exactly does?
>> >
>> > The manual page only documents the insides, not the description.
>> 
>> The below comment is from debian menu introduction.  if a package have a
>> debian menu file,  all window-manager's menu in debian will show this
>> package menu.
>> 
>> #+BEGIN_COMMENT
>>  Before the advent of update-menus, when the sysadmin installed a
>> package onto a Debian system, they would need to edit various window
>> manager config files to make the new program show up on, for
>> example, fvwm's menus. The menus could easily become out of sync
>> with what programs were actually available, with some menu items
>> that didn't work, and other programs that lacked a menu
>> entry. update-menus and Debian's menu package aim to solve this
>> problem.
>> 
>> update-menus automatically generates menus of installed programs for
>> window managers and other menu programs. It should be run whenever a
>> menu file or menu-method file is changed. update-menus will be ran
>> automatically when Debian packages that contain menu files are
>> installed or removed from the system. Users themselves can
>> add/delete menu items, and should then run update-menus as that
>> user, thus creating window-manager startup files that are used in
>> preference to the systemwide files.
>> #+END_COMMENT
>> 
>> -- 
>> 
>> 
> Thanks.
>
> So what's the difference to existing menu-generators specific to many
> or only a subset of window-managers, such as obconf?
>
> Option 1: we could do this in scheme somehow, associated to Guix.
> Option 2: we make this a choice (opt-in, run it on your own), not
> an opt-out as coming up with a way where user menus are touched
> is from my perspective a no-go.
> I would not want some automatic generator to touch my menus which
> are slightly different from just generated ones.

All I want to say is that:  we *must* add menu info in "package define"
if users of this package *real need* a menu instead of waiting upstream
to write a .desktop.


-- 

Guile bindings of GnuTLS are missing (was: Help needed from Java developer to finish maven)

[Hartmut Goebel]

Am 24.04.2017 um 14:41 schrieb Catonano:
> I tried to build your branch just out of curiosity and the configure
> of Guix fails because
>
> configure: error: The Guile bindings of GnuTLS are missing; please
> install them.
>
> I'm running this inside a
>
> guix environment guix
>
> so I assume all the deps should be available

Yes, this is one of the issues bugging me to quite often. Within the
environment you'll also need to run:

export SSL_CERT_DIR="$GUIX_ENVIRONMENT/etc/ssl/certs"
export SSL_CERT_FILE="$GUIX_ENVIRONMENT/etc/ssl/certs/ca-certificates.crt"
export GIT_SSL_CAINFO="$SSL_CERT_FILE"

(This is why I wrote myself a script for setting up a guix environment.)

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Help needed from Java developer to finish maven

[Catonano]

2017-04-23 14:36 GMT+02:00 Hartmut Goebel :

> Hi Björn,
>
> I'm looking forward to your findings!
>
> > 1. Is this already the output of "mvn -X" and/or "mvn -e"?
>
> Yes, this is the output of mvn -X (basically, in fact I'm running "java
> … org.apache.maven.cli.MavenCli -X").
>
> > 3. Do you have a WIP branch and instructions on how to reproduce this?
>
> You can find the branch "WIP-maven" at
> https://gitlab.com/htgoebel/guix.git. To reproduce simply run
>
> git clone https://gitlab.com/htgoebel/guix.git
> cd guix
> git checkout WIP-maven
> ./pre-inst-env guix build maven-for-bootstrap
>

I tried to build your branch just out of curiosity and the configure of
Guix fails because

configure: error: The Guile bindings of GnuTLS are missing; please install
them.

I'm running this inside a

guix environment guix

so I assume all the deps should be available

I probably won't be able to help you anyway, I was just curious to see the
error you're running into.

Thanks in advance

Re: [PATCH] gnu: Add cool-retro-term.

[Petter]

Hi Chris,

> 
> By the way, the output of 'guix lint' points out the following:

Oh lint, I had forgotten about that.

> --8<---cut here---start->8---
> [0] marusich@garuda:~/guix
> $ ./pre-inst-env guix lint cool-retro-term
> gnu/packages/terminals.scm:493:5: cool-retro-term@1.0.0-1.e4871
> 9f: sentences in description should be followed by two spaces; 
> possible infraction at 117
> checking cool-retro-term@1.0.0-1.e48719f [inputs-should-be-nati
> checking cool-retro-term@1.0.0-1.e48719f [inputs-should-not-be-
> gnu/packages/terminals.scm:490:14: cool-retro-term@1.0.0-1.e487
> 19f: synopsis should be less than 80 characters long  
> [0] marusich@garuda:~/guix
> $
> --8<---cut here---end--->8---
> 
> Think you could submit one more patch to tidy up those?  Anyway, I
> can't commit your patch (I don't have commit access), but somebody
> else probably can.

I sure can. Thanks for helping out!

I lowercased the Cool-retro-term abbreviation, (crt). I think it's a
little better, but no strong feelings.

What do you think of adding `crt` as an alternative name
for the binary? I see it's been briefly discussed here,
https://github.com/Swordfish90/cool-retro-term/issues/258

> Love this contribution, by the way.  I'm sending an email from within
> CRT right now...!  :-)

Glad you enjoy it! I'm fond of it too, it makes the whole terminal
experience more engaging/alive or something :)

Unfortunately it has the capasity to introduce lag in my entire system.
F.ex. scrolling and changing tabs in Icecat would take noticeable time
with the default effects settings. I've adjusted them a bit, and
got the lag under control. Is this the case for you as well? I'm on an
x200.

Best,
Petter


From 553902e8a736f356bdc5c7a5bf28e339f9f5cde6 Mon Sep 17 00:00:00 2001
From: Petter 
Date: Sun, 23 Apr 2017 13:46:41 +0200
Subject: [PATCH] gnu: Add cool-retro-term.

* gnu/packages/terminals.scm (cool-retro-term): New variable.
---
 gnu/packages/terminals.scm | 62
  ++ 1 file changed, 62
  insertions(+)

diff --git a/gnu/packages/terminals.scm b/gnu/packages/terminals.scm
index 979278a53..e53062b16 100644
--- a/gnu/packages/terminals.scm
+++ b/gnu/packages/terminals.scm
@@ -7,6 +7,7 @@
 ;;; Copyright © 2016, 2017 José Miguel Sánchez García
 ;;; Copyright © 2017 Tobias Geerinckx-Rice
 ;;; Copyright © 2017 Ricardo Wurmus 
+;;; Copyright © 2017 Petter 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -49,6 +50,7 @@
   #:use-module (gnu packages xdisorg)
   #:use-module (gnu packages xml)
   #:use-module (gnu packages docbook)
+  #:use-module (gnu packages qt)
   #:use-module (srfi srfi-26))
 
 (define-public tilda
@@ -433,3 +435,63 @@ its embedding program should provide it to draw on
its behalf.  It avoids calling @code{malloc} during normal running
state, allowing it to be used in embedded kernel situations.")
 (license license:expat)))
+
+(define-public cool-retro-term
+  (let ((commit "e48719fa44e5307df71dbd0fad234f8a6a53f863")
+(revision "1"))
+  (package
+(name "cool-retro-term")
+(version (string-append "1.0.0-" revision "." (string-take commit
7)))
+(source (origin
+  (method git-fetch)
+  (modules '((guix build utils)))
+  (file-name (string-append name "-" version "-checkout"))
+  (uri (git-reference
+(url (string-append
"https://github.com/Swordfish90/; name))
+(commit commit)
+(recursive? #t)))
+  (sha256
+   (base32
"1sgqbirninkvgwchr35zgn5vzqvsmrf3cp7lqady1xgrawb8lsz3"
+(build-system gnu-build-system)
+(inputs
+ `(("qt" ,qt)))
+(arguments
+ `(#:phases
+   (modify-phases %standard-phases
+ (replace 'configure
+  (lambda* (#:key outputs #:allow-other-keys)
+(let ((out (assoc-ref outputs "out")))
+  (substitute* '("qmltermwidget/qmltermwidget.pro")
+(("INSTALL_DIR = \\$\\$\\[QT_INSTALL_QML\\]")
+ (string-append "INSTALL_DIR = " out "/qml")))
+  (substitute* '("app/app.pro")
+(("target.path \\+= /usr")
+ (string-append "target.path += " out))
+(("icon32.path = /usr/share")
+ (string-append "icon32.path = " out "/share"))
+(("icon64.path = /usr/share")
+ (string-append "icon64.path = " out "/share"))
+(("icon128.path = /usr/share")
+ (string-append "icon128.path = " out
"/share"))
+(("icon256.path = /usr/share")
+ (string-append 

Re: Suggest A debian-style menu system for guix

[ng0]

Feng Shu transcribed 1.5K bytes:
> ng0  writes:
> 
> > tumashu transcribed 1.0K bytes:
> >> Debian menu system 
> >> (https://www.debian.org/doc/packaging-manuals/menu.html/ch3.html) is a 
> >> very useful tool,
> >> is it possible develop a similar tool for guix?
> >
> > Could you explain what this exactly does?
> >
> > The manual page only documents the insides, not the description.
> 
> The below comment is from debian menu introduction.  if a package have a
> debian menu file,  all window-manager's menu in debian will show this
> package menu.
> 
> #+BEGIN_COMMENT
>  Before the advent of update-menus, when the sysadmin installed a package 
> onto a Debian system, they would need to edit various window manager config 
> files to make the new program show up on, for example, fvwm's menus. The 
> menus could easily become out of sync with what programs were actually 
> available, with some menu items that didn't work, and other programs that 
> lacked a menu entry. update-menus and Debian's menu package aim to solve this 
> problem.
> 
> update-menus automatically generates menus of installed programs for window 
> managers and other menu programs. It should be run whenever a menu file or 
> menu-method file is changed. update-menus will be ran automatically when 
> Debian packages that contain menu files are installed or removed from the 
> system. Users themselves can add/delete menu items, and should then run 
> update-menus as that user, thus creating window-manager startup files that 
> are used in preference to the systemwide files. 
> #+END_COMMENT
> 
> -- 
> 
> 
Thanks.

So what's the difference to existing menu-generators specific to many
or only a subset of window-managers, such as obconf?

Option 1: we could do this in scheme somehow, associated to Guix.
Option 2: we make this a choice (opt-in, run it on your own), not
an opt-out as coming up with a way where user menus are touched
is from my perspective a no-go.
I would not want some automatic generator to touch my menus which
are slightly different from just generated ones.
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: Suggest A debian-style menu system for guix

[Feng Shu]

ng0  writes:

> tumashu transcribed 1.0K bytes:
>> Debian menu system 
>> (https://www.debian.org/doc/packaging-manuals/menu.html/ch3.html) is a very 
>> useful tool,
>> is it possible develop a similar tool for guix?
>
> Could you explain what this exactly does?
>
> The manual page only documents the insides, not the description.

The below comment is from debian menu introduction.  if a package have a
debian menu file,  all window-manager's menu in debian will show this
package menu.

#+BEGIN_COMMENT
 Before the advent of update-menus, when the sysadmin installed a package onto 
a Debian system, they would need to edit various window manager config files to 
make the new program show up on, for example, fvwm's menus. The menus could 
easily become out of sync with what programs were actually available, with some 
menu items that didn't work, and other programs that lacked a menu entry. 
update-menus and Debian's menu package aim to solve this problem.

update-menus automatically generates menus of installed programs for window 
managers and other menu programs. It should be run whenever a menu file or 
menu-method file is changed. update-menus will be ran automatically when Debian 
packages that contain menu files are installed or removed from the system. 
Users themselves can add/delete menu items, and should then run update-menus as 
that user, thus creating window-manager startup files that are used in 
preference to the systemwide files. 
#+END_COMMENT

-- 

Suggest A debian-style menu system for guix

[tumashu]

Debian menu system 
(https://www.debian.org/doc/packaging-manuals/menu.html/ch3.html) is a very 
useful tool,
is it possible develop a similar tool for guix?

Re: Guile 2.2 .go files are larger

[Andy Wingo]

On Mon 24 Apr 2017 10:24, Andy Wingo  writes:

> On Sat 22 Apr 2017 15:19, l...@gnu.org (Ludovic Courtès) writes:
>
>> The closure of Guix built with 2.0 is 193.8 MiB; when built with 2.2,
>> it’s 311.8 MiB.  Guix itself goes from 66 to 150 MiB:
>>
>> $ du -ms 
>> /gnu/store/jh07pwbyf5dbpdd5q0nvgagqkgmh76nh-guix-0.12.0-9.25a4/lib/guile/2.2
>> 101  
>> /gnu/store/jh07pwbyf5dbpdd5q0nvgagqkgmh76nh-guix-0.12.0-9.25a4/lib/guile/2.2
>> $ du -ms 
>> /gnu/store/rnpz1svz4aw75kibb5qb02hhccy2m4y0-guix-0.12.0-7.aabe/lib/guile/2.0
>> 24   
>> /gnu/store/rnpz1svz4aw75kibb5qb02hhccy2m4y0-guix-0.12.0-7.aabe/lib/guile/2.0
>
> Before we begin, some general notes.  My understanding is that the heap
> usage corresponding to an individual Guix process will be lower, both
 ^
  lower than Guix-on-Guile-2.0, I mean

> due to allocation of read-only data in read-only, shareable sections of
> the .go ELF files, allocation of read-write data in packed sections
> known to the GC but not managed by GC, and various optimizations that
> can eliminate or simplify some heap allocations (closure optimization
> among them).  In short my understanding is that Guile 2.2 (and systems
> built on it) should have a smaller run-time footprint than Guile 2.2.

Er, than smaller footprint than Guile 2.0.

Sorry for the confusion :)

Re: XPATH queries and manipulation in guile?

[Andy Wingo]

On Sun 23 Apr 2017 19:10, Hartmut Goebel  writes:

> Yes, I've seen SXPath [4], but IMHO this usign this would *not* be a
> good choice: It would require packages to learn yet another path
> language, while when using XPath, the packagers could simply copy
> expressions from some fedora .spec-file. Additionally I find the
> documentation of SXpath hard to understand - for be frank: I did not get
> it at all.

The documentation is indeed terrible.  This library is used by other
Schemes; we should see if we can steal their docs, if they are better.

However it's possible to use SXPath with the string syntax.  I seem to
recall there's code out there to do that.  We could incorporate into
Guile to just support the standard syntax.  I think the way forward here
is to improve Guile's sxpath documentation, fixing whatever interfaces
are needed, and adding the xpath->selector function.

Andy

Re: Guile 2.2 .go files are larger

[Andy Wingo]

On Sat 22 Apr 2017 15:19, l...@gnu.org (Ludovic Courtès) writes:

> The closure of Guix built with 2.0 is 193.8 MiB; when built with 2.2,
> it’s 311.8 MiB.  Guix itself goes from 66 to 150 MiB:
>
> $ du -ms 
> /gnu/store/jh07pwbyf5dbpdd5q0nvgagqkgmh76nh-guix-0.12.0-9.25a4/lib/guile/2.2
> 101   
> /gnu/store/jh07pwbyf5dbpdd5q0nvgagqkgmh76nh-guix-0.12.0-9.25a4/lib/guile/2.2
> $ du -ms 
> /gnu/store/rnpz1svz4aw75kibb5qb02hhccy2m4y0-guix-0.12.0-7.aabe/lib/guile/2.0
> 24
> /gnu/store/rnpz1svz4aw75kibb5qb02hhccy2m4y0-guix-0.12.0-7.aabe/lib/guile/2.0

Before we begin, some general notes.  My understanding is that the heap
usage corresponding to an individual Guix process will be lower, both
due to allocation of read-only data in read-only, shareable sections of
the .go ELF files, allocation of read-write data in packed sections
known to the GC but not managed by GC, and various optimizations that
can eliminate or simplify some heap allocations (closure optimization
among them).  In short my understanding is that Guile 2.2 (and systems
built on it) should have a smaller run-time footprint than Guile 2.2.

> Would you have any suggestions to shrink the ELF files a bit?

Why?  Have you compared gzipped or lzipped sizes?  I don't want to put
effort in here that's not worth it :)

Part of it is that our page alignment is 64 kB and so average wasteage
per .go is 32kB, and there are a lot of .go files.  These are just zero
bytes though.

If you look at an individual file, you can use readelf to see things, or
that old ELF visualizer I wrote:

  https://wingolog.org/elf-mapper/

Here's a map of gnu/packages/curl.go:

  https://wingolog.org/pub/elf/elf-JWXYrI.png

I think stripping the .debug_* stuff won't get you much of anywhere.

Stripping arities info could reduce size by 10%.  We could figure out a
different way to represent arities that takes less space.

Compiling all the .go files together (requires Guile hacking) could
remove that per-go 64kB alignment overhead.  Alternately we could do
what GNU tools / ld.so do which maps the linear sequence of bytes in the
file to aligned segments in memory.

Honestly though I would punt.  It's not a run-time issue.  I don't think
it's a transport issue.  It's only a disk space issue.  I personally
don't plan to spend time on it but am happy to point out possibilities
to people that will do so.

Andy

Re: Debugging info unavailability

[Tomas Cech]

On Sun, 23 Apr 2017 02:02:06 +0200,
Danny Milosavljevic wrote:
> 
> Hi,
> 
> just now I had to debug a doxygen Segmentation Fault.  I tried to install 
> doxygen:debug but that wasn't available.
> 
> I think it would be nice if these outputs were available by default (but not 
> installed by default).
> 
> If we wanted to do that, we could just adapt guix/build-system/cmake.scm, 
> guix/build-system/gnu.scm and guix/build-system/glib-or-gtk.scm outputs 
> default to say '("out" "debug") instead of '("out").

This is the feature I wish for years, I'd really appreciate such feature as 
well.

Best regards,

S_W

Re: server and client in one package -> security issue

[Maxim Cournoyer]

Apologies for digging up a 2 months old message, but I felt compelled to :)

Hartmut Goebel  writes:

> Am 14.02.2017 um 10:16 schrieb Danny Milosavljevic:
>> I don't think Guix should do that, though. 
>
> I think guix should provide the tools for doing so. Guix has the big
> advantage of providing trustworthy packages, but kicks itself out of the
> race if hardening is so much complicated.
>
>> IMO locking down everything for users is basically the antithesis of the FSF.
>
> The "user" is the company, the employees work on behalf of the company.
> So the software freedom has to be available toe the company not to the
> individual employee.
>

>From what I've read and understand, freedom is for any and all
individuals running the software. The employees of your company also
deserve freedom. Freedom doesn't necessarily goes against good
security. I believe Guix and Hurd are steps in the right direction in
achieving freedom of users in a shared/corporate environment.

> As a company I'm expecting the user to *not* install software on their
> computers (not talking about developers here). Otherwise its like
> allowing workers to bring their own hammer to the building site or their
> own machines into the factory building. If the hammer is inappropriate
> and is deforming all nails, or the machine is producing scrap, the
> company the the one bear the consequences.

I believe one of GNU's goal is to bridge (remove the gap between)
developers and users. The system should empower the users to
experiment/study/learn/share the software if they want to and removing
barriers to the tools.

My 2 cents,

Maxim