Some icons never change under xfce

[Barnabás Béres]

Hi Guixers,
I installed papirus-icon-theme as a system package and tried to change the 
default xfce icons but unfortunately some icons didn’t change (for example 
folder icons). Do you have any idea what causes this behavior?

Thanks for your help in advance!

Best Regards
Barnabas Beres

Re: trivial-build-system and which

[Oleg Pykhalov]

Hello,

Stephen Scheck  writes:

> This package definition always fails with #f returned by `(which "bash")`
> ... am I missing something?
>
> (build-system trivial-build-system)
> (arguments
>   `(#:builder
>  (begin
>(use-modules (guix build utils))
>(invoke "make" (string-append "SHELL=" (which "bash")) "..."
> (native-inputs
>   `(("bash" ,bash)
> ("make" ,gnu-make)

Inputs don't add themselves to the PATH environment variable, which is
required for invoke in this case.  So you want to do something like:

  (setenv "PATH"
(string-append
 (assoc-ref %build-inputs "bash") "/bin" ":"
 (getenv "PATH")))

Or you could just invoke in another way:

  (invoke "make" (string-append "SHELL=" (assoc-ref %build-inputs "bash") 
"/bin/bash") "...")


Oleg.


signature.asc
Description: PGP signature

Re: Workflow with mu4e + magit for sending patchsets to guix?

[Kyle Meyer]

zimoun writes:

> On Mon, 16 Nov 2020 at 21:36, Kyle Meyer  wrote:
>
>>>  4. !! send-email --to=guix-patc...@gnu.org -cover-letter.patch
>>>  5. Wait and refresh my inbox
>>>  6. !! send-email --to=12...@gnu.org 000?-*.patch
>>
>> Yeah, 4-6 are tricky and debbugs-specific.  For other projects, it could
>> just be 'send-email *.patch' once sendemail.to is configured to point to
>> the list's address.
>>
>> For 6, using '--no-thread --in-reply-to=...' will retain the same
>> threading you'd see if you weren't using debbugs (i.e didn't have to do
>> the two-step send).
[...]
> To me, today the main annoyance is the selection of the patches at the
> step #6.  For example, avoid to resend unrelated patches, as:
>
>  - 000?-*.patch could resend the -cover-letter.patch
>  - *.patch could resend -cover-letter.patch and 0001-Foo-bar.patch
> if I am currently sending v2-0001-Foo-bar.patch
>  - any previous patchset remaining.

Yeah, I agree about that being the most annoying aspect, but I'd say
that core problem comes from the need for a two-step send.  That's a
quirky enough divergence from the standard workflow that I think any
solution/helper here is unlikely to be in the scope of Magit.  But that
doesn't mean I don't think it'd be nice to come up with a helper.

> Recent example inside my
> guix-artwork checkout: 
> --8<---cut here---start->8---
> -cover-letter.patch
> 0001-website-Add-conference-announcement.patch
[...]
> 0001-website-Update-manifest.patch
> tiny.patch
> v2-0001-website-Add-conference-announcement.patch
[...]
> v4-0001-website-Release-conference-schedule.patch
> --8<---cut here---end--->8---
>
> That’s why time to time I create an output directory and put the series
> in.  But the -cover-letter.patch (or vN--cover-letter.patch) is
> still annoying because it blocks the simple *.patch.  Nothing simpler
> than * could be done, I see you regexp integrist. :-)

Yeah, I'd guess a directory per topic and version is pretty common to
make selecting the patches simply DIR/* (again, assuming a normal
one-step send-email process).

> I am thinking loud.  One option (some setq) could be added to Magit
> format-patch, and do under the hood:
>
>  - create -cover-letter.patch in the root directory
>  - create folder v1 (default), otherwise v2 … vN and put the series
>in.
>
> This would be configurable via Magit variables, say:
>
>   magit-send-email-workflow t
>   magit-format-patch-directory-prefix “v”

As I said, I'm not sold on this being something that fits Magit proper,
but I'll help write a helper :)

> Then, the sequence,
>
>   W C-m l C-m c
>   W C-m v2 c
>   W C-m l C-m v3 c
>
> would produce the final tree:
>
>   +
>   +- .git
>   +- -cover-letter.patch
>   +- v3--cover-letter.patch
>   +- v1
>  +- 0001-Foo-Bar.patch

Here's a command that gets you close to that layout.  It adds an
additional "/" directory on top of the structure you show above.
The name is reads from the caller (with a default completion value of
the current branch name).  It also depends on the caller having an
upstream branch set (which I think is a good thing), but you could
rework it to avoid it.

--8<---cut here---start->8---
(defun my/magit-patch-create-split-directory (name &optional args files)
  "Create patches in a split layout.

Call `git format-patch ARGS -- FILES`, splitting the cover letter
off from the main patches.  A standard format-patch calls creates
a layout like

   -cover-letter.patch
   0001-commit-1-subj.patch
   0002-commit-2-subj.patch
   ...

in the directory specified by `--output-directory=' or the
current directory.

This command expands the structure as

  NAME
  |-- -cover-letter.patch
  `-- vN
  |-- 0001-commit-1-subj.patch
  |-- 0002-commit-1-subj.patch

where NAME is a name for the series and N is the version
specified via `--reroll-count='.  The cover letter will have a
\"vN-\" prefix after the first version.

The motivation for the above layout is to make it easier to send
the cover letter to a Debbugs list and, once a bug number is
assigned, follow up with the remaining patches:

  $ git send-email --to=$debbugs-list NAME/-cover-letter.patch
  $ # [ wait for mail ]
  $ git send-email --to=$bug-address-from-mail \\
--in-reply-to=$cover-letter-message-id --no-thread NAME/vN/*"
  (interactive (cons (read-string "Series name: "
  nil nil (magit-get-current-branch))
 (let ((args (transient-args 'magit-patch-create)))
   (list (seq-filter #'stringp args)
 (cdr (assoc "--" args))
  (let* ((upstream (or (magit-get-upstream-branch)
   (user-error "No upstream branch")))
 (version
  (or (seq-some
   (lambda (arg)
 (and (string-match "\\`--reroll-count=\\(.+\\

trivial-build-system and which

[Stephen Scheck]

This package definition always fails with #f returned by `(which "bash")`
... am I missing something?

(build-system trivial-build-system)
(arguments
  `(#:builder
 (begin
   (use-modules (guix build utils))
   (invoke "make" (string-append "SHELL=" (which "bash")) "..."
(native-inputs
  `(("bash" ,bash)
("make" ,gnu-make)

Emacs, ccls, LSP and C++

[Alexandru-Sergiu Marton]

Hi,

I have some problems setting up a C++ development environment on Guix
System.

I'm using Emacs with lsp-mode and emacs-ccls. This setup works very well
for C projects, but ccls doesn't seem to like anything related to
C++. Take this simple program for example:

--8<---cut here---start->8---
#include 

int
main ()
{
  std::cout << "Hello, World!\n";
  return 0;
}
--8<---cut here---end--->8---

Both lsp-mode and eglot tell me that ccls reports: "no member named
'cout' in namespace 'std'".

I have gcc-toolchain installed and I can compile the project just
fine. I tried using bear to generate a compile_commands.json, from this
simple Makefile:

--8<---cut here---start->8---
all:
g++ main.cpp -o main
--8<---cut here---end--->8---

but ccls still fails to recognize the members of the std
namespace. Irony seems to fail too (same problem), but I haven't tried
playing with it too much, I just tested the default Doom Emacs config.

One more thing: ccls also complains about this, and I don't know what to
make of it:

main.cpp error:20 unknown type name '_GLIBCXX17_DEPRECATED'

Do any of you have experience with setting up a C++ development
environment on Guix System in Emacs? Did you run into similar problems,
and if yes, how did you solve them?

Cheers,
Alexandru-Sergiu Marton

Re: Package building with gcc-10

[zimoun]

Dear,

On Mon, 16 Nov 2020 at 16:18, "Hamzeh Nasajpour"  
wrote:

> I have a cpp Application that should be build with
> `gcc-toolchain-10.2.0`. I could build it in local. But seems that in
> package building the `cmake-build-system` is using the
> `gcc-7.5.0`. How can I set a specific version of gcc for building my
> package definition?

You need Package Transformation, from the command line:

   --with-c-toolchain=package=toolchain

or from the package definition: package-with-c-toolchain


The manual entries about the topic:





Hope that helps,
simon

Re: Workflow with mu4e + magit for sending patchsets to guix?

[Kyle Meyer]

Kyle Meyer writes:

>> C-m l
>
> If you follow the convention of writing a cover letter only for
> multi-patch series, you can drop the 'C-m l' because by default git will
> generate a cover letter when there is more than one commit.

Sorry, I was mistaken: generating a cover letter for a multi-patch
series is _not_ git's default behavior.  That requires setting
format.coverLetter to "auto" in your git configuration.

Re: Workflow with mu4e + magit for sending patchsets to guix?

[zimoun]

Hi Kyle,

Thank you for the detailed explanations and hints.


On Mon, 16 Nov 2020 at 21:36, Kyle Meyer  wrote:

>>  4. !! send-email --to=guix-patc...@gnu.org -cover-letter.patch
>>  5. Wait and refresh my inbox
>>  6. !! send-email --to=12...@gnu.org 000?-*.patch
>
> Yeah, 4-6 are tricky and debbugs-specific.  For other projects, it could
> just be 'send-email *.patch' once sendemail.to is configured to point to
> the list's address.
>
> For 6, using '--no-thread --in-reply-to=...' will retain the same
> threading you'd see if you weren't using debbugs (i.e didn't have to do
> the two-step send).

[...]

> And, sadly I guess, my view is still similar to what I said there:
>
>   send-email has of course come up a number of times before (gh-1756 and
>   gh-1800 are the most relevant, I think), and tackling that requires a
>   vision that I don't really have.  Perhaps due to a lack of
>   imagination, I can't think of an implementation on Magit's side that
>   would improve the simple send-email command that I run.  In terms of
>   sending mail, the most involved thing that I need to do is get the
>   --to/--ccs and --in-reply-to from an existing thread, but in my view
>   that's outside of Magit's scope.
>
> I don't know.  Maybe I should try to think harder about it.
>
> A final note of hope: as a lurker on the notmuch list, I've noticed that
> Jonas has starting doing some patch-based contributions.  So, perhaps
> he'll get an itch and do his amazing Jonas thing.

To me, today the main annoyance is the selection of the patches at the
step #6.  For example, avoid to resend unrelated patches, as:

 - 000?-*.patch could resend the -cover-letter.patch
 - *.patch could resend -cover-letter.patch and 0001-Foo-bar.patch
if I am currently sending v2-0001-Foo-bar.patch
 - any previous patchset remaining.  Recent example inside my
guix-artwork checkout: 

--8<---cut here---start->8---
-cover-letter.patch
0001-website-Add-conference-announcement.patch
0001-website-Add-fetch-methods-to-JSON-sources-and-packag.patch
0001-website-Add-integrity-to-JSON-sources.patch
0001-website-Release-conference-schedule.patch
0001-website-Update-announce-online-Guix-days.patch
0001-website-Update-manifest.patch
tiny.patch
v2-0001-website-Add-conference-announcement.patch
v2-0001-website-Release-conference-schedule.patch
v3-0001-website-Add-conference-announcement.patch
v3-0001-website-Release-conference-schedule.patch
v4-0001-website-Add-conference-announcement.patch
v4-0001-website-Release-conference-schedule.patch
--8<---cut here---end--->8---


That’s why time to time I create an output directory and put the series
in.  But the -cover-letter.patch (or vN--cover-letter.patch) is
still annoying because it blocks the simple *.patch.  Nothing simpler
than * could be done, I see you regexp integrist. :-)


I am thinking loud.  One option (some setq) could be added to Magit
format-patch, and do under the hood:

 - create -cover-letter.patch in the root directory
 - create folder v1 (default), otherwise v2 … vN and put the series
   in.

This would be configurable via Magit variables, say:

  magit-send-email-workflow t
  magit-format-patch-directory-prefix “v”
  
Then, the sequence,

  W C-m l C-m c
  W C-m v2 c
  W C-m l C-m v3 c

would produce the final tree:

  +
  +- .git
  +- -cover-letter.patch
  +- v3--cover-letter.patch
  +- v1
 +- 0001-Foo-Bar.patch
 …
 +- 0042-Yahoga.patch
  +- v2
 +- v2-0001-Foo-Bar.patch
 …
 +- v2-0012-Kikool.patch
  +- v3
 +- v3-0001-Foo-Bar.patch
 …
 +- v3-0021-Rock-and-roll.patch
 
This way, step #6 would become:

  !! send-email --to=12...@debbugs.gnu.org v1/*.patch

(With or without --in-reply-to, another story. :-))


All the best,
simon

Re: Workflow with mu4e + magit for sending patchsets to guix?

[zimoun]

Hi Pierre,

On Tue, 17 Nov 2020 at 08:28, Pierre Neidhardt  wrote:

> Notmuch user here, today I learned about
> notmuch-show-stash-git-send-email!

Some weeks (months?) ago, I also “discovered“ the Notmuch stash stuff.


For example, if I want to refer to your previous message via classic
way, I do:

 1. Open webbrowser and go to the relevant page of archives
 2. Scroll to find the message, click
 3. Stash the URL
 4. Swicth back to Emacs, yank



Maybe instead of webbrowser, I could use eww to avoid the switch.
Anyway.

The issue here is the numbering.  Your message was the 109th message on
help-guix this month but this number is impossible to guess, well one
needs to parse all the mbox archive and count.  Argh!  Each email has an
unique identifier the header Message-ID field.  For example, the one of
your message is: 87pn4ca1c7@ambrevar.xyz.

And  serves the mapping via public-inbox.
Concretely, I do ’cl’ (notmuch-show-stash-mlarchive-link) reading your
message, select the archive and I get:



Select the archive because by default it is linux-kernel related
archives: LKML, MARC, etc. even if I do not know about Gmane.  My config
is:

--8<---cut here---start->8---
  ;; c l stashes a hyperlink using Message-ID instead of numbering, e.g.:
  ;; https://yhetil.org/guix-user/acba4413-a4ca-d7e5-08f7-24ac9839b...@posteo.de
  ;; vs https://lists.gnu.org/archive/html/help-guix/2020-10/msg00177.html
  (mapcar (lambda (what)
(add-to-list 'notmuch-show-stash-mlarchive-link-alist
 `(,what . ,(concat "https://yhetil.org/"; what "/"
  (reverse'("guix-devel"
"guix-user"
"guix-science"
"gwl"
"guix-bugs"
"guix-patches")))
--8<---cut here---end--->8---

(Instead of manually selecting the archive, an helper function could
parse the header fields and do the job but I have not been annoyed
enough yet. :-))

Neat!  Isn’t it? :-)


In this picture, you could be interested by this thread:

  Mummi wishlist: API using Message-ID
  

Note that the project Org-mode switched to a public-inbox instance
recently:




Hope that helps,
simon

Re: Package workspace relocation

[zimoun]

Hi Efraim,

On Tue, 17 Nov 2020 at 09:23, Efraim Flashner  wrote:

> (add-after 'unpack 'move-source
>   (lambda _
> (mkdir-p "foo/bar")
> (rename-file "my-project" "foo/bar/my-project")
>   #t))

Cool!  Thank you for the explanation.

Cheers,
simon