Re: core-updates freeze

[Timothy Sample]

Hi Marius,

Marius Bakke  writes:

> Timothy Sample  writes:
>
>> From ad931895edae97e2d6d77542fcbe8dc793f193f0 Mon Sep 17 00:00:00 2001
>> From: Timothy Sample 
>> Date: Tue, 16 Jul 2019 10:04:58 -0400
>> Subject: [PATCH] system: Write the timezone to /etc/timezone.
>>
>> * gnu/system.scm (operating-system-etc-service): Write the operating
>> system timezone to /etc/timezone.
>>
>> Fixes .
>> ---
>>  gnu/system.scm | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/gnu/system.scm b/gnu/system.scm
>> index 01be1243fe..75ac0632bb 100644
>> --- a/gnu/system.scm
>> +++ b/gnu/system.scm
>> @@ -716,6 +716,7 @@ fi\n")))
>> ;; to certain networks.  Some discussion at
>> ;; https://lists.gnu.org/archive/html/help-guix/2017-09/msg00037.html
>> ("hostname" ,(plain-file "hostname" (operating-system-host-name os)))
>> +   ("timezone" ,(plain-file "timezone" (operating-system-timezone os)))
>> ("localtime" ,(file-append tzdata "/share/zoneinfo/"
>>(operating-system-timezone os)))
>> ("sudoers" ,(operating-system-sudoers-file os))
>> -- 
>> 2.22.0
>>
>>
>> Thoughts?
>
> Looks good to me.  Perhaps leave a comment that Glib uses this file to
> figure out the current timezone?

Pushed with a comment about GLib that references this discussion.

> Though I notice Debian 10 creates /etc/timezone too, so maybe we just
> missed a FHS update somewhere.

I looked at FHS 3.0, which is the latest one I could find, and it didn’t
say anything.  Searching around, the file has been around for a long
time.  It used to be mentioned in the systemd documentation, but now the
docs talk about /etc/localtime being a symlink instead [1].  According
to a Qt comment [2], Debian used to do what we are doing now until
Jessie, then it made /etc/localtime a symlink (I presume they kept
/etc/timezone for compatibility).  All in all, it looks like a lot of
other projects are moving away from /etc/timezone, so maybe we bet on
the wrong horse, so to speak.  It looks like Flatpack has started using
it recently, though [3].  Either way, it should be easy enough to adapt
if projects drop support for /etc/timezone.

[1] 
https://github.com/systemd/systemd/commit/608da9e9b56be83ac394ea7a19cbdacab94f6642
[2] 
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=110e49c9cecca34dfacad33d19e04612cc2671b2
[3] https://github.com/flatpak/flatpak/issues/2190

-- Tim

Re: We should disable dmesg for unprivileged users by default

[Alex Vong]

Hello,

Ricardo Wurmus writes:

> Ludovic Courtès  writes:
>
>> Hi,
>>
>> Alex Vong  skribis:
>>
>>> I think we should set /proc/sys/kernel/dmesg_restrict to 1 by default to
>>> prevent unprivileged users from reading the kernel ring buffer (since it
>>> could expose sensitive information about the system).
>>
>> We could have a ‘dmesg-restrict’ service that would write to that file
>> as part of system activation, and we’d add it to ‘%base-packages’.
>> WDYT?
>
> This sounds good!

I just find out there are at least 2 other ways to set kernel
parameters. One is to append the line "kernel.dmesg_restrict=1" to the file
"/etc/sysctl.conf". The other way is to run the command
"sudo sysctl -w kernel.dmesg_restrict=1". It appears to me that writing
to "/etc/sysctl.conf" is better (since it is declarative). WDYT? What is
our current way of setting kernel parameters?


signature.asc
Description: PGP signature

Re: Deadline security grant is August 1st.

[Pjotr Prins]

Just a gentle reminder. This is an opportunity to get paid for work on
GNU Guix/Hurd. We can help submit a proposal. If you can state how we
can improve security on the internet and you have some traction in an
existing project it may be possible.

On Mon, Jul 08, 2019 at 01:07:29PM -0500, Pjotr Prins wrote:
> Dear all,
> 
> https://nlnet.nl/PET/ has small grants to work on Free and Open Source
> software (up to EUR 50,000).

> You can see the list of approved projects of the previous round here:
> 
> https://nlnet.nl/thema/NGIZeroPET.html
> 
> The application takes a few hours, but read the rules carefully and
> take a cue by reading the approved project proposals. They are looking
> for visible projects that have impact.
 

Re: We need your feedback of the documentation videos!

[pelzflorian (Florian Pelz)]

On Tue, Jul 16, 2019 at 12:11:22PM -0300, Laura Lazzati wrote:
> If you are interested, please, watch them
> https://archive.org/details/guix-videos and give feedback here :)

The videos are amazing.

Please reference these in all related sections of the manual (once
published).  The videos will be very valuable when explaining Guix.

I would be happy if there were many translations for the videos,
however I will not help speak one myself.

When publishing, maybe reference their license and source code (but
not within the video) and how translators/speakers can contribute.

Regards,
Florian

Re: Organizing packages

[zimoun]

Dear,

On Sun, 14 Jul 2019 at 15:54, Ludovic Courtès  wrote:

> > I think this will make searching easier because not everything has an
> > obvious name, and when I `guix search` for a purpose (like drawing) I
> > often get unrelated results.
>
> I don’t think the module hierarchy should be thought of as a tool for
> users to search for packages.

I totally agree. :-)


> So really, ‘guix search’ is the tool that should be improved.  It’s been
> discussed many times, and improving it turns out to be difficult without
> resorting to external sources of information (e.g., list of command
> names, popularity database, etc.)
>
> What we can do is look at specific examples to see if there’s something
> we can improve on the current scoring system (with the understanding
> that sometimes the answer is that we cannot do any better.)
>
> For example, ‘guix search drawing program’ shows Tux Paint as the first
> result, which is good; but ‘guix search drawing’ and ‘guix search
> drawing application’ are much less useful.  In this particular example,
> it’s not clear to me what can be done.
>
> One suggestion that was made before and that might help here is to
> increase the score of leaf packages (applications).

One of the current issue is that the score is not "normalized" somehow.

The current score is built by using the number of occurrences of each
field (name, synopsis, description, etc.) with weights (see
`%package-metrics` in guix/ui.scm).
For instance, `guix search drawing` ranks first `texlive-latex-eepic`
because the word `drawing` appears 4 times in the description, second
`tuxpaint` because of 2 times and third `xfig` (1 time).
What should be expected (IMHO) is that these 3 packages should be
scored at the same value. Therefore, something normalizing seems
missing. But what? :-)
And leaf package should have a higher score than non-leaf package. For
instance, `xfig` should be higher than `libart-lgpl`.

Then the situation with this scoring system cannot be improved so much
for the "only word" search.


Moreover, nothing can help with bad written descriptions.

For example, you need to know that `roguelike` is a `game` when
reading the description of the package `angband`.

  guix package --show=angband | recsel -C -p synopsis,description

synopsis: Dungeon exploration roguelike
description: Angband is a Classic dungeon exploration roguelike.  Explore the
+ depths below Angband, seeking riches, fighting monsters, and preparing to
+ fight Morgoth, the Lord of Darkness.

>From my opinion, the issue is that the description is not good enough
to provide any relevant information usable by a search tool. And again
from my opinion, adding tags or classifying the packages inside
relevant filenames---which is a way to tag---seems a wrong approach.
For example, where VLC should be in? video.scm? But is it closer to
ffmpeg-for-stepmania or to Totem which is in gnome.scm?
IMHO, bikeshedding cannot be an improvement for searching packages. :-)


However, a kind of tf-idf [1] should be used to better self organize
the packages when searching.

[1] https://en.wikipedia.org/wiki/Tf%E2%80%93idf


For example, I have 10146 package definitions:
  guix search ' ' | recsel -P name -C | wc -l
  10146
and 46 contain the word 'drawing'.
So, the Inverse-Document-Frequency is:
 IDF(drawing) = log(10146 / 46)

Let consider the 3 first most relevant package (with the current score).
The term `drawing` appears:
   for pkg in $(guix search drawing | recsel -C -P name | head -n3);\
   do\
  echo $pkg ; guix package --show=$pkg | grep -c drawing ;\
   done

FREQ(drawing, texlive-latex-eepic) = 5
FREQ(drawing, tuxpaint) = 2
FREQ(drawing, xfig) = 2

Let normalize by the length of the document:
   for pkg in $(guix search drawing | recsel -C -P name | head -n3);\
   do\
  echo $pkg ; guix package --show=$pkg \
  | recsel -P synopsis,description | wc -w ;\
   done

LEN(texlive-latex-eepic) = 68
LEN(tuxpaint) = 60
LEN(xfig) = 76

Then one definition of the Term-Frequency is:

TF(drawing, texlive-latex-eepic) = 5 / 68
TF(drawing, tuxpaint) = 2 / 60
TF(drawing, xfig) = 2 / 76


The TF-IDF reads:

TF-IDF(drawing, texlive-latex-eepic) = 5/68*log(10146/46) =0.3968
TF-IDF(drawing, tuxpaint) = 2/60*log(10146/46) =0.1799
TF-IDF(drawing, xfig) = 2/76*log(10146/46) =0.1420


This does not change much the current result. But this allows to
better know which words are "good filter".

Let consider the word `program` and the package `tuxpaint`.
The current relevance score is 5 for `program`. The term appears 2
times (note that `software` appears in synopsis which should be
replaced be `program`).
The current relevance score is 7 for `drawing`. The term also appears 2 times.
The difference is just because the weight per field.

However, the TF-IDF is totally different:

TF-IDF(drawing, tuxpaint) = 2/60*log(10146/46) =0.1799
TF-IDF(program, tuxpaint) = 2/60*log(10146/1056) =0.0754

Well, the term `drawing` owns more information than the term 

Re: core-updates freeze

[Marius Bakke]

Timothy Sample  writes:

> Hi,
>
> Kei Kebreau  writes:
>
>> Marius Bakke  writes:
>>
>>> I'm not sure what we should do about it.  Thoughts?
>>>
>>> Kei: Does it work if you 'echo Your/Timezone > /etc/timezone' ?
>>> Alternatively, you could make /etc/localtime a symbolic link to
>>> $tzdata/share/zoneinfo/Your/Timezone, though that will not persist a
>>> reboot.
>>
>> I can confirm that both of these methods work, so crude work-arounds
>> include
>>
>>   1.  Setting the system's configured time zone in /etc/timezone
>
> This is my vote for two reasons.  First, it seems more elegant.  If I
> want to know the timezone name, I should look it up directly, and not
> chase symlinks around looking for some canonical timezone file.  I think
> this is the closest thing to a “standard way to get the name of the
> system timezone”  (here,
> “standard” means “well, I guess at least Gentoo does it”).  Second, it
> is a one-liner for us:
>
> From ad931895edae97e2d6d77542fcbe8dc793f193f0 Mon Sep 17 00:00:00 2001
> From: Timothy Sample 
> Date: Tue, 16 Jul 2019 10:04:58 -0400
> Subject: [PATCH] system: Write the timezone to /etc/timezone.
>
> * gnu/system.scm (operating-system-etc-service): Write the operating
> system timezone to /etc/timezone.
>
> Fixes .
> ---
>  gnu/system.scm | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/gnu/system.scm b/gnu/system.scm
> index 01be1243fe..75ac0632bb 100644
> --- a/gnu/system.scm
> +++ b/gnu/system.scm
> @@ -716,6 +716,7 @@ fi\n")))
> ;; to certain networks.  Some discussion at
> ;; https://lists.gnu.org/archive/html/help-guix/2017-09/msg00037.html
> ("hostname" ,(plain-file "hostname" (operating-system-host-name os)))
> +   ("timezone" ,(plain-file "timezone" (operating-system-timezone os)))
> ("localtime" ,(file-append tzdata "/share/zoneinfo/"
>(operating-system-timezone os)))
> ("sudoers" ,(operating-system-sudoers-file os))
> -- 
> 2.22.0
>
>
> Thoughts?

Looks good to me.  Perhaps leave a comment that Glib uses this file to
figure out the current timezone?

Though I notice Debian 10 creates /etc/timezone too, so maybe we just
missed a FHS update somewhere.


signature.asc
Description: PGP signature

Re: “Towards Guix for DevOps”

[Jakob L. Kreuze]

Hi Zimoun,

zimoun  writes:

> Dear,
>
> The link to the manual seems broken.
> http://guix.gnu.org/manual/en/html_node/Invoking-guix-deploy.html#Invoking-guix-deploy
> Because the manual online is the one of the version 1.0.1 and not the
> one of master, right?

Yes, that's right. What's unusual is that the link worked when I sent
this off for feedback.

Anyway, should we remove the link? Perhaps the mention of the manual is
enough.

Regards,
Jakob


signature.asc
Description: PGP signature

We need your feedback of the documentation videos!

[Laura Lazzati]

Hi Guix!

We are about to publish the existing documentation videos and we need your
help!
If you are interested, please, watch them
https://archive.org/details/guix-videos and give feedback here :)
We will appreciate it very much, and the idea is to collect the feedback up
to next Tuesday (July 23rd)

Kind regards!
Laura

Re: core-updates freeze

[Timothy Sample]

Hi,

Kei Kebreau  writes:

> Marius Bakke  writes:
>
>> I'm not sure what we should do about it.  Thoughts?
>>
>> Kei: Does it work if you 'echo Your/Timezone > /etc/timezone' ?
>> Alternatively, you could make /etc/localtime a symbolic link to
>> $tzdata/share/zoneinfo/Your/Timezone, though that will not persist a
>> reboot.
>
> I can confirm that both of these methods work, so crude work-arounds
> include
>
>   1.  Setting the system's configured time zone in /etc/timezone

This is my vote for two reasons.  First, it seems more elegant.  If I
want to know the timezone name, I should look it up directly, and not
chase symlinks around looking for some canonical timezone file.  I think
this is the closest thing to a “standard way to get the name of the
system timezone”  (here,
“standard” means “well, I guess at least Gentoo does it”).  Second, it
is a one-liner for us:

>From ad931895edae97e2d6d77542fcbe8dc793f193f0 Mon Sep 17 00:00:00 2001
From: Timothy Sample 
Date: Tue, 16 Jul 2019 10:04:58 -0400
Subject: [PATCH] system: Write the timezone to /etc/timezone.

* gnu/system.scm (operating-system-etc-service): Write the operating
system timezone to /etc/timezone.

Fixes .
---
 gnu/system.scm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gnu/system.scm b/gnu/system.scm
index 01be1243fe..75ac0632bb 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -716,6 +716,7 @@ fi\n")))
;; to certain networks.  Some discussion at
;; https://lists.gnu.org/archive/html/help-guix/2017-09/msg00037.html
("hostname" ,(plain-file "hostname" (operating-system-host-name os)))
+   ("timezone" ,(plain-file "timezone" (operating-system-timezone os)))
("localtime" ,(file-append tzdata "/share/zoneinfo/"
   (operating-system-timezone os)))
("sudoers" ,(operating-system-sudoers-file os))
-- 
2.22.0


Thoughts?


-- Tim

Re: Fixing evolution-data-server on core-updates

[Timothy Sample]

Hello,

Kei Kebreau  writes:

> Ludovic Courtès  writes:
>
>> Hello Timothy,
>>
>> Timothy Sample  skribis:
>>
>>> From bcd753f777687c52bba6b9bf4184879e69990118 Mon Sep 17 00:00:00 2001
>>> From: Timothy Sample 
>>> Date: Sun, 14 Jul 2019 23:47:44 -0400
>>> Subject: [PATCH] gnu: evolution-data-server: Fix locale issue.
>>>
>>> * gnu/packages/gnome.scm (evolution-data-server)[arguments]: Add a phase
>>> that patches the source code to fix a locale issue.
>>> ---
>>> [...]
>>
>> LGTM, thanks for fixing it!
>>
>> Ludo’.
>
> Just FYI, I can confirm that this patch allows me to re-enable tests
> that previously failed on core-updates!  I've re-enabled the relevant
> failing tests on my own core-updates branch in anticipation of this
> patch.  Thanks from me, too!
>
> Kei

I heard back from upstream, and the fix will be included from version
3.33.5.  In the meantime, I spruced up the comment and pushed this as
d619686250d8bb15bf67031f8ac80f9cfb400a26.  When we update to GNOME 3.34,
we can remove it again (I’m hoping the comment will be a sufficient
reminder).

Thanks for looking it over!


-- Tim

Re: “Towards Guix for DevOps”

[zimoun]

Dear,

The link to the manual seems broken.
http://guix.gnu.org/manual/en/html_node/Invoking-guix-deploy.html#Invoking-guix-deploy
Because the manual online is the one of the version 1.0.1 and not the
one of master, right?

Thank you for this interesting work.


All the best,
simon

Re: qt4 packages

[Tobias Geerinckx-Rice]

Efraim,

Efraim Flashner 写道：
Seeing as Debian aparently still supports (most of) qt-4 it may 
be

worth looking at how they do that.


Quite the opposite, actually: https://wiki.debian.org/Qt4Removal

Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: Fixing evolution-data-server on core-updates

[Jonathan Brielmaier]

So am I right in the assumption to use the patch proposed at:
https://gitlab.gnome.org/GNOME/evolution-data-server/issues/137

Could you then prepare this patch for core-updates?

On 7/15/19 6:09 AM, Timothy Sample wrote:
> Hi all,
>
> While testing core-updates I found that evolution-data-server does not
> build due to test failures.  The tests fail because
> evolution-data-server does not accommodate newer versions of ICU.
> Here’s the upstream bug report [1].  I’ve attached a patch that uses
> “substitute*” to work around the problem (it’s rather simple).  I think
> we should wait to hear from upstream, and if they don’t get to it in a
> few days, use the patch.
>
> [1] https://gitlab.gnome.org/GNOME/evolution-data-server/issues/137
>
>
> -- Tim
>

Re: Testing changes on Berlin before pushing changes?

[Chris Marusich]

Hi Marius,

Marius Bakke  writes:

> Chris Marusich  writes:
>
>> Hi Marius,
>>
>> Thank you for your work on Mariadb in bug 35521.  You are a hero!  Well,
>> my hero at least, since this was blocking me from upgrading things.  :-)
>
> Glad it worked for you :-)

Well, it did seem to work, but it has unmasked two other problems that
still prevent me from upgrading using core-updates:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36685
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36686

I'll try to look into them also, when I have time.

-- 
Chris


signature.asc
Description: PGP signature

Re: qt4 packages

[Efraim Flashner]

On Mon, Jul 15, 2019 at 09:48:36PM +0200, Andreas Enge wrote:
> On Mon, Jul 15, 2019 at 09:17:02PM +0300, Efraim Flashner wrote:
> > texmacs Debian dropped 2(?) versions ago
> 
> I just added it during the Guile/Guix days at Strasbourg, please do not
> drop it... Also, it is a GNU project. It may have been removed from Debian
> because it depends on guile-1.8; but there is hope they will eventually
> move to a more recent version.
> 

Sorry, this is my bad. On IRC yestday it was mentioned that
javascriptcore in qt-4 wasn't building on core-updates and the
suggestion was made to drop it. I should've mentioned it in my original
post. Seeing as Debian aparently still supports (most of) qt-4 it may be
worth looking at how they do that.

-- 
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: qt4 packages

[Hartmut Goebel]

Am 15.07.19 um 20:54 schrieb Tobias Geerinckx-Rice:
> Efraim, Guix,
>
> Efraim Flashner 写道：
>> tipp10 Debian continues to build with qt-4
>
> In cases like this one (where the software has been unmaintained for
> years), is the plan simply to remove them altogether? 


Why drop a package which is still okay, just because it it unmaintained?


-- 
Regards
Hartmut Goebel

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