Re: Mummi wishlist: API using Message-ID

[Arun Isaac]

> I just don’t know for sure if Message-Ids may contain characters that
> are not permitted in URLs.

According to RFC5322, Message-IDs can contain any ASCII character in the
(decimal) ranges 33-91, 93-126. And, many of these characters are not
permitted in URLs, but perhaps modern browsers automatically percent
encode if the user enters unpermitted characters in the URL.


signature.asc
Description: PGP signature

Re: Mummi wishlist: API using Message-ID

[Kyle Meyer]

zimoun writes:

> On Thu, 17 Sep 2020 at 12:00, Ricardo Wurmus  wrote:

>> This is an interesting idea!  I don’t know if it’ll work as a plain URL,
>> because not all characters of a message id might be usable in a URL (you
>> may need to URL-encode it and can’t just paste it in the URL bar of your
>> browser), but it would certainly work as a search query.  The only
>> problem is that we’re not currently indexing the message ids.
>
> I do not know but public-inbox is doing such thing, isn't it?
> I mean, the example with emacs-debbugs, my "custom" function and the
> service :
>
[...]
> Is it not enough?
> The URL,  is it not always ready-to-be-pasted?
> The link contains '@' but it works (on my webbrowser at least :-)).

For public-inbox URLs, there is one character that needs to be escaped:
"/" with "%2F" (see ).

However, in its current form, your custom function has a good chance of
being enough.  Here is the number of message IDs known to
yhetil.org/guix-devel:

$ echo 'SELECT COUNT(*) FROM msgmap' | \
sqlite3 -readonly guix-devel-msgmap.sqlite3
55231

And of those, only 11 have "/" in them:

$ echo 'SELECT mid FROM msgmap' | \
sqlite3 -readonly guix-devel-msgmap.sqlite3 | grep -c "/"
11

Re: doc: Channel subsection order?

[zimoun]

Hi Ludo,

I propose something in #43482 .


>   1. Move “Channels” to the top level, with real subsections as nodes.

Patch 2 does that.


>   2. Clearly distinguish between using a channel and developing a
>  channel.  The former should come first.

Patch 3 does that.


>   3. Probably move ‘guix pull’ and ‘guix time-machine’ under that
>  section.

After a couple of read, I do not think they need to move under
channels.  Because they will not be visible from

  


>   4. Add a tutorial-like section on how to work on your own channel.

What do you have in mind?
I only have in mind: test your change locally before pushing?


All the best,
simon

Re: Packaging pd

[Mark H Weaver]

Andreas Enge  writes:
> I knew that three letter software names are bad, but there is worse -
> two letter software names!

It gets even worse: one letter package names.  Of course there's 'r',
but it's obviously very well established, and grandfathered in, so
that's fine.

However, in 2017 an obscure shell named 's' was added to Guix.  I
intervened and got it renamed to 's-shell' in Guix.

More recently, when I wasn't paying attention, a package called 'v' was
added to Guix.  I really wish it hadn't been.  Most of the arguments I
made against 's' apply to 'v' as well:

  https://lists.gnu.org/archive/html/guix-devel/2017-06/msg00066.html

  Mark

Re: [OUTREACHY] Proposal: substitutes over IPFS

[Ludovic Courtès]

Hello!

Gábor Boskovits  skribis:

> I believe it is better if  it's a team.

Agreed.  Looks like we almost have a team for this proposal now,
thanks.  :-)

Ricardo Wurmus  skribis:

> There can be several co-mentors – we also did that for past projects.
> It’s a good idea, but good, regular communication is essential to make
> it work.

+1.  There are two aspects here: one is to have regular and informal
communication between the mentors and the intern so that the intern
feels at ease and dares ask questions or share concerns before it’s too
late, and the second aspect is to have a large part of that happening on
public channels.  I think that helps interns become “first-class
contributors” and since it’s an outreach effort, it also shows to others
following along how we help onboard people from different backgrounds
and origins.

Thanks,
Ludo’.

Re: guile-sqlite3 trace support

[Danny Milosavljevic]

Hi Mathieu,

thanks for telling me.

For some reason I do not get notification E-Mails when someone posts a pull
request there.  I've searched the preferences, but nothing about that anywhere.
My E-Mail address IS set up there (this one, but with +a suffix).  I've now
changed it not to use a plus slgn now.

In any case, I've merged your patch to master.

Let's see how it goes and then I'll make a new release.


pgpF7bHyw6AL6.pgp
Description: OpenPGP digital signature

guile-sqlite3 trace support

[Mathieu Othacehe]

Hello Danny,

Any chance you could have a look to
https://notabug.org/guile-sqlite3/guile-sqlite3/pulls/16.

I'd like to use it log all Cuirass SQL queries.

Thanks,

Mathieu
-- 
https://othacehe.org

Re: Packaging pd

[Andreas Enge]

Thanks for your replies, Ludovic and Ricardo!

On Mon, Sep 07, 2020 at 12:22:45PM +0200, Ricardo Wurmus wrote:
> > Now there already is a "pd" in Guix; are there any precedents on how to
> > name a second pd? "pd-polytope"? "primal-dual"? "pd-primal-dual"?
> “pd” in Guix is “Pure Data”, the visual data flow language that’s often
> used for music.  It is an option to rename it to “pure-data”.

I opted for "primal-dual" and put it into guix-past. So there is no
particular reason to rename the "pd" that already made it into guix
master.

Andreas

GNOME: Suggesting ‘guix gc’ upon low disk space

[Ludovic Courtès]

Hello Guix!

GNOME (actually ‘gnome-settings-daemon’) pops up a notification upon low
disk space that looks like this:

Low Disk Space on “filesystem root”

[ Empty Trash ][ Examine ]

The “Examine” button spawns the Disk Space Analyzer (aka Baobab) and the
“Empty Trash” button does its thing.

The untested patch below adds a ‘guix gc’ button, which is probably more
important than the other two on Guix System.

I’m not sure whether implementing it is as simple as this: is it OK to
block during GC or should it be done in a separate process?

If someone here has more insight or would like to give it a try, please
let me know!

Ludo’.

diff --git a/plugins/housekeeping/gsd-disk-space.c b/plugins/housekeeping/gsd-disk-space.c
index bd3437e..870430b 100644
--- a/plugins/housekeeping/gsd-disk-space.c
+++ b/plugins/housekeeping/gsd-disk-space.c
@@ -546,6 +546,20 @@ empty_trash_callback (NotifyNotification *n,
 notify_notification_close (n, NULL);
 }
 
+static void
+guix_gc_callback (NotifyNotification *n,
+  const char *action)
+{
+GDateTime *old;
+
+g_assert (action != NULL);
+g_assert (strcmp (action, "run-guix-gc") == 0);
+
+system ("guix gc");
+
+notify_notification_close (n, NULL);
+}
+
 static void
 on_notification_closed (NotifyNotification *n)
 {
@@ -591,6 +605,13 @@ ldsm_notify (const char *summary,
 g_free);
 }
 
+notify_notification_add_action (notification,
+"run-guix-gc",
+_("Collect Unused Guix Items"),
+(NotifyActionCallback) guix_gc_callback,
+NULL,
+NULL);
+
 has_trash = ldsm_mount_has_trash (mount_path);
 
 if (has_trash) {

Re: [OUTREACHY] toward a proposal?

[Gábor Boskovits]

Helllo,

zimoun  ezt írta (időpont: 2020. szept. 17.,
Cs, 13:26):
>
> On Thu, 17 Sep 2020 at 13:16, Gábor Boskovits  wrote:
>
> > > Do you know if the past submissions have been publicly archived somewhere?
> >
> > I am not sure if these are available publicly, but you should be able
> > to see this for example:
> > https://www.outreachy.org/outreachy-may-2020-internship-round/communities/gnu-guix/create-netlink-bindings-in-guile/cfp/
>
> Seeing nothing, just the title.

Even when you are logged in to outreachy?
That is strange

I will copy it then to somewhere in maintenance later...

>
> Cheers,
> simon


Regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: Mummi wishlist: API using Message-ID

[Ricardo Wurmus]

zimoun  writes:

> (Sorry for the misspelling of Mumi in the Subject thread.)
>
> (For the record, reading [1], I discovered [2,3] with similar goals
> than Mumi and that the Org-mode community uses public-inbox [4].)
>
> [1] https://bzg.fr/en/org-mode-9.4-is-out-can-you-help.html/
> [2] https://updates.orgmode.org/
> [3] https://github.com/bzg/woof
> [4] https://orgmode.org/list/87r1vd92eg@bzg.fr/
>
> On Thu, 17 Sep 2020 at 12:00, Ricardo Wurmus  wrote:
>> zimoun  writes:
>
>> > Instead, it is easy to get the Message-ID.  (Using emacs-notmuch, only
>> > hit the key ’ci’) Therefore, it could be nice to be able to provide
>> > e.g., the URL:
>> >
>> > 
>> >
>> > redirecting to .
>>
>> This is an interesting idea!  I don’t know if it’ll work as a plain URL,
>> because not all characters of a message id might be usable in a URL (you
>> may need to URL-encode it and can’t just paste it in the URL bar of your
>> browser), but it would certainly work as a search query.  The only
>> problem is that we’re not currently indexing the message ids.
>
> I do not know but public-inbox is doing such thing, isn't it?
> I mean, the example with emacs-debbugs, my "custom" function and the
> service : […]

It might be fine.  I just don’t know for sure if Message-Ids may contain
characters that are not permitted in URLs.

>> > And maybe the
>> > current webpage could provide the Message-ID, easy to copy and then
>> > paste in my email reader.
>>
>> It’s already there but hidden!  Every message is rendered in a
>> div.message.  Inside of that is div.card > div.card-header > div.details
>> (hidden) > div.message-id.
>>
>> With custom CSS you could unhide div.details, and with a custom JS you
>> could grab the contents of div.message-id on the click of a button.
>> Most browsers make it a little hard to augment the CSS and/or JS of a
>> served page, but with a little hacking I’m sure you can extract what you
>> want.
>
> Okish... CSS/JS is not really my cup of tea.  I will try to rehash
> your words when giving a look at Mumi source.

You can give this a try:

* in Icecat hit F12
* select the Inspector (if it isn’t selected yet)
* in the right column (next to :hov and .cls) there’s a plus icon with
  hover text “Add new rule”; click it
* edit the text to say: “.details { display: block !important }”

This should show you all message ids.  It’s possible to make this
permanent but it’s rather tedious with Icecat/Firefox.

If you just need this for scripting, though, you can parse the HTML and
filter the “div” tag with the “message-id” class.  If scripting is
desired I could probably also offer a JSON endpoint that provides all
information in a format that is easily processed.

-- 
Ricardo

Re: [OUTREACHY] toward a proposal?

[zimoun]

On Thu, 17 Sep 2020 at 13:16, Gábor Boskovits  wrote:

> > Do you know if the past submissions have been publicly archived somewhere?
>
> I am not sure if these are available publicly, but you should be able
> to see this for example:
> https://www.outreachy.org/outreachy-may-2020-internship-round/communities/gnu-guix/create-netlink-bindings-in-guile/cfp/

Seeing nothing, just the title.

Cheers,
simon

Re: [OUTREACHY] toward a proposal?

[Gábor Boskovits]

Hello,

zimoun  ezt írta (időpont: 2020. szept. 17.,
Cs, 12:01):
>
> Hi Gábor,
>
> On Thu, 17 Sep 2020 at 10:12, Gábor Boskovits  wrote:
>
> > I have read the proposal. All in all it looks good to me. One section
> > that could be
> > improved is the requirement on the setup. We usually state having guix
> > installed as
> > a requirement, even maybe a development setup. As initial contribution
> > we usually
> > ask for packaging something simple. We should also have a look at the 
> > community
> > details, like the communication channels, and try to uniformize them
> > across the proposals.
> > I will check how it was phrased in the past, see if there is any new
> > info now, and try to
> > come up with something.
>
> Thank you.
> Do you know if the past submissions have been publicly archived somewhere?

I am not sure if these are available publicly, but you should be able
to see this for example:
https://www.outreachy.org/outreachy-may-2020-internship-round/communities/gnu-guix/create-netlink-bindings-in-guile/cfp/
>
>
> Cheers,
> simon

Best regards,
g_bor


-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: Mummi wishlist: API using Message-ID

[zimoun]

(Sorry for the misspelling of Mumi in the Subject thread.)

(For the record, reading [1], I discovered [2,3] with similar goals
than Mumi and that the Org-mode community uses public-inbox [4].)

[1] https://bzg.fr/en/org-mode-9.4-is-out-can-you-help.html/
[2] https://updates.orgmode.org/
[3] https://github.com/bzg/woof
[4] https://orgmode.org/list/87r1vd92eg@bzg.fr/

On Thu, 17 Sep 2020 at 12:00, Ricardo Wurmus  wrote:
> zimoun  writes:

> > Instead, it is easy to get the Message-ID.  (Using emacs-notmuch, only
> > hit the key ’ci’) Therefore, it could be nice to be able to provide
> > e.g., the URL:
> >
> > 
> >
> > redirecting to .
>
> This is an interesting idea!  I don’t know if it’ll work as a plain URL,
> because not all characters of a message id might be usable in a URL (you
> may need to URL-encode it and can’t just paste it in the URL bar of your
> browser), but it would certainly work as a search query.  The only
> problem is that we’re not currently indexing the message ids.

I do not know but public-inbox is doing such thing, isn't it?
I mean, the example with emacs-debbugs, my "custom" function and the
service :

> > Another (Emacs related) example is emacs-debbugs.
> >   C-u M-x debbugs-gnu RET guix RET n y
> >   M-x debbugs-gnu-bugs RET 33899 RET RET
> >   Read messages
> >
> > Well, in the relevant message, I run “M-x debbugs->url” and get the
> > ready-to-be-pasted URL:
> >
> > 
> >
> > with the naive Emacs function:
> >
> > --8<---cut here---start->8---
> > (defun debbugs->url ()
> >   (interactive)
> >   (let ((url "https://yhetil.org/guix-bugs/";)
> > mid)
> > (with-current-buffer gnus-article-buffer
> >   (gnus-summary-toggle-header 1)
> >   (setq mid (message-fetch-field "Message-ID"))
> >   (gnus-summary-toggle-header -1))
> > (while (string-match "[<>]" mid)
> >   (setq mid (replace-match "" t t mid)))
> > (kill-new (concat url mid))
> > (message mid)))
> > --8<---cut here---end--->8---

Is it not enough?
The URL,  is it not always ready-to-be-pasted?
The link contains '@' but it works (on my webbrowser at least :-)).


> Per bug we index the bug id, the submitter, the authors, the subject(s),
> the owner, the severity, the tags, the status, the file name of the
> original Debbugs “.log” file (I forgot why!), and all the message
> bodies.  All of these map to the very same “document” (in Xapian
> parlance), which is a particular “issue”.

Thank you for explaining.


> I think we could also index the message id (and expose it to the
> search), map that to the “issue”, and then find the corresponding anchor
> in the HTML later.  We wouldn’t be able to *directly* map the message id
> to the actual message in the thread, because the search does not operate
> on the concept of messages but only whole bug discussions.  But I think
> this would get us very close to what you propose.

Yes.
If the Message-ID is also indexed, the map is almost there.


> > And maybe the
> > current webpage could provide the Message-ID, easy to copy and then
> > paste in my email reader.
>
> It’s already there but hidden!  Every message is rendered in a
> div.message.  Inside of that is div.card > div.card-header > div.details
> (hidden) > div.message-id.
>
> With custom CSS you could unhide div.details, and with a custom JS you
> could grab the contents of div.message-id on the click of a button.
> Most browsers make it a little hard to augment the CSS and/or JS of a
> served page, but with a little hacking I’m sure you can extract what you
> want.

Okish... CSS/JS is not really my cup of tea.  I will try to rehash
your words when giving a look at Mumi source.


> > Last and off-topic to the Subject :-), the tool ’public-inbox’ exposes
> > such API and then it seems easier to refer to relevant message than
> > going by hand on e.g. 
> > to find it.
>
> I don’t quite understand how this differs from this:
>
> https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=%3C86sgbhz3fe.fsf%40gmail.com%3E&submit=Search%21&idxname=guix-devel

Because I did not know. :-)


All the best,
simon

Re: [OUTREACHY] toward a proposal?

[zimoun]

Hi Gábor,

On Thu, 17 Sep 2020 at 10:12, Gábor Boskovits  wrote:

> I have read the proposal. All in all it looks good to me. One section
> that could be
> improved is the requirement on the setup. We usually state having guix
> installed as
> a requirement, even maybe a development setup. As initial contribution
> we usually
> ask for packaging something simple. We should also have a look at the 
> community
> details, like the communication channels, and try to uniformize them
> across the proposals.
> I will check how it was phrased in the past, see if there is any new
> info now, and try to
> come up with something.

Thank you.
Do you know if the past submissions have been publicly archived somewhere?


Cheers,
simon

Re: Mummi wishlist: API using Message-ID

[Ricardo Wurmus]

zimoun  writes:

> For example .  The number #16 is
> really difficult to guess. :-)

Yes, it comes from the number of messages we got from Debbugs.

> Instead, it is easy to get the Message-ID.  (Using emacs-notmuch, only
> hit the key ’ci’) Therefore, it could be nice to be able to provide
> e.g., the URL:
>
> 
>
> redirecting to .

This is an interesting idea!  I don’t know if it’ll work as a plain URL,
because not all characters of a message id might be usable in a URL (you
may need to URL-encode it and can’t just paste it in the URL bar of your
browser), but it would certainly work as a search query.  The only
problem is that we’re not currently indexing the message ids.

Per bug we index the bug id, the submitter, the authors, the subject(s),
the owner, the severity, the tags, the status, the file name of the
original Debbugs “.log” file (I forgot why!), and all the message
bodies.  All of these map to the very same “document” (in Xapian
parlance), which is a particular “issue”.

I think we could also index the message id (and expose it to the
search), map that to the “issue”, and then find the corresponding anchor
in the HTML later.  We wouldn’t be able to *directly* map the message id
to the actual message in the thread, because the search does not operate
on the concept of messages but only whole bug discussions.  But I think
this would get us very close to what you propose.

> And maybe the
> current webpage could provide the Message-ID, easy to copy and then
> paste in my email reader.

It’s already there but hidden!  Every message is rendered in a
div.message.  Inside of that is div.card > div.card-header > div.details
(hidden) > div.message-id.

With custom CSS you could unhide div.details, and with a custom JS you
could grab the contents of div.message-id on the click of a button.
Most browsers make it a little hard to augment the CSS and/or JS of a
served page, but with a little hacking I’m sure you can extract what you
want.

>
> Another (Emacs related) example is emacs-debbugs.
>   C-u M-x debbugs-gnu RET guix RET n y
>   M-x debbugs-gnu-bugs RET 33899 RET RET
>   Read messages
>
> Well, in the relevant message, I run “M-x debbugs->url” and get the
> ready-to-be-pasted URL:
>
> 
>
> with the naive Emacs function:
>
> --8<---cut here---start->8---
> (defun debbugs->url ()
>   (interactive)
>   (let ((url "https://yhetil.org/guix-bugs/";)
> mid)
> (with-current-buffer gnus-article-buffer
>   (gnus-summary-toggle-header 1)
>   (setq mid (message-fetch-field "Message-ID"))
>   (gnus-summary-toggle-header -1))
> (while (string-match "[<>]" mid)
>   (setq mid (replace-match "" t t mid)))
> (kill-new (concat url mid))
> (message mid)))
> --8<---cut here---end--->8---
>
>
>
> Last and off-topic to the Subject :-), the tool ’public-inbox’ exposes
> such API and then it seems easier to refer to relevant message than
> going by hand on e.g. 
> to find it.

I don’t quite understand how this differs from this:

https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=%3C86sgbhz3fe.fsf%40gmail.com%3E&submit=Search%21&idxname=guix-devel

Here I search for the id of your message (the one I’m responding to);
that’s the (URL-encoded) value of “query”, “idxname” is for the mailing
list to be searched.

It gives you a list of results, not one message directly, but I think
it’s pretty close. 

-- 
Ricardo

Re: [OUTREACHY] toward a proposal?

[Gábor Boskovits]

Hello,

Ricardo Wurmus  ezt írta (időpont: 2020. szept.
16., Sze, 20:44):
>
>
> zimoun  writes:
>
> > On Wed, 16 Sep 2020 at 19:21, Ricardo Wurmus  wrote:
> >
> >> Yes.  The idea is that there will be a large number of proposals but
> >> only enough funding for one or two interns.  IIRC internship candidates
> >> then pick a project they’d like to work on and eventually we decide
> >> together with the mentors whom to accept for the internships.  So it
> >> could be that there will only be one suitable internship candidate who
> >> picked another project — in that case the IPFS project would not go
> >> forward as an Outreachy internship.  If we’re lucky, though, we’ll get
> >> enough suitable candidates so that all proposed projects can go forward.
> >
> > I committed something.

I have read the proposal. All in all it looks good to me. One section
that could be
improved is the requirement on the setup. We usually state having guix
installed as
a requirement, even maybe a development setup. As initial contribution
we usually
ask for packaging something simple. We should also have a look at the community
details, like the communication channels, and try to uniformize them
across the proposals.
I will check how it was phrased in the past, see if there is any new
info now, and try to
come up with something.

>
> Thank you, I’ll try to read it tomorrow.
>
> > Well, the GNU Guix has one intern founded for this round, if I read
> > correctly.  Obviously, I can withdraw the proposal if it can help IPFS
> > to reach master.
>
> There is the possibility to get extra funding from Outreachy when there
> are more suitable candidates than funded projects.  It’s an exceptional
> case, but you won’t have to withdraw proposals.  In the worst case we
> can carry the proposal to the next round of internships.
>
> --
> Ricardo

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21