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

[Pierre Neidhardt]

Kyle Meyer  writes:

> Also, not helpful for mu4e users, but since I know simon uses notmuch...
> notmuch has a really handy notmuch-show-stash-git-send-email.

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

Thanks for the tip!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: GDM blank for anyone else with guix system vm?

[Efraim Flashner]

On Mon, Nov 16, 2020 at 06:42:09PM -0500, Christopher Lemmer Webber wrote:
> Not sure why but when testing:
> 
>   ./pre-inst-env guix system vm gnu/system/examples/lightweight-desktop.tmpl
> 
> (and also the normal non-lightweight desktop) I'm getting a blank screen
> once gdm is supposed to start up, but the mouse can still move.  I'm
> also running the intel graphics card here.
> 
> Just curious, is anyone else having this problem?

How much memory are you giving it? There might not be enough for GDM to
actually start. IIRC that command spits out a shell script in the store,
so you can run './gnu/store/really-long-path.sh -m 2G' to switch to using
2GB of RAM.

-- 
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: Package workspace relocation

[Efraim Flashner]

On Tue, Nov 17, 2020 at 12:09:35AM +0100, zimoun wrote:
> Dear,
> 
> On Mon, 16 Nov 2020 at 16:56, Stephen Scheck  wrote:
> 
> > `/my-project` to become `/foo/bar/my-project`. It sounds like what you
> 
> [...]
> 
> >> > This results in a path like `/my-package-0.0.1` but
> >> `/foo/bar/my-package-0.0.1`.
> 
> What do you want?  Append a suffix /tmp/guix-xyz/foo/bar/your-pkg or a
> prefix /tmp/foo/bar/guix-xyz/your-pkg?
> 
> Change the prefix means changing the TMPDIR environment variable of
> guix-daemon (priviliged user).
> 
> At first look, I do not know how to add something between guix-xyz-drv-0/
> and your-pkg/.  Curious to know how. :-)
> 

I think I'd go with
(add-after 'unpack 'move-source
  (lambda _
(mkdir-p "foo/bar")
(rename-file "my-project" "foo/bar/my-project")
  #t))

With that you'll be in  and you can chdir into whatever
directory you want. Or you could change the source so it doesn't expect
the source to be deep in a directory structure.

-- 
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: Workflow with mu4e + magit for sending patchsets to guix?

[Kyle Meyer]

zimoun writes:

> Hi Chris
>
> +CC Kyle since they probably knows the status [1].

Sorry, I have no good news for you :/

> On Mon, 16 Nov 2020 at 15:28, Christopher Lemmer Webber 
>  wrote:
>
>> I've been making patchset series of emails to guix-patches manually.
>> I'm sure this is the wrong thing to do.  I use mu4e + magit and know
>> others have a similar setup.
>>
>> What do you all do?
>
> I am sending really few patches so my workflow is probably not
> optimized.  What I do is from magit-status:
>
>  1. Select the commits

I'd suggest always setting an upstream for topic branches.  Then the
range you're interested in is almost always "@{upstream}.." (which can
be shortened to "@{u}..").  Or you can add something like this to
Magit's popup [1]:

  ;; 
https://git.kyleam.com/emacs.d/tree/lisp/km-magit.el?id=928629a9ccd8b439d0e98d9976b75c4cf5f048f9#n836

  (defun km/magit-patch-create-from-upstream ( args)
(interactive (list (transient-args 'magit-patch-create)))
(if-let ((upstream (magit-get-upstream-branch)))
(apply #'magit-run-git "format-patch" upstream args)
  (user-error "No upstream branch")))

  (transient-append-suffix 'magit-patch-create "c"
'("u" "@{upstream}.." km/magit-patch-create-from-upstream))

Most of my magit customizations never find their way upstream (they tend
to be very tailored to me), but something like the command above would
probably be good to add.

>  2. W c
> C-m b origin/master RET

Yay, base commit :)  Note that with the upstream set, you can select
"auto" here.  Or you can configure format.useAutoBase to "whenAble" and
not bother setting the option for each invocation.

> 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.

> c
>  3. Edit the cover letter
>  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).

Also, not helpful for mu4e users, but since I know simon uses notmuch...
notmuch has a really handy notmuch-show-stash-git-send-email.  I have a
variant for step 5 above.  If you call it visiting the acknowledgment
message, it will copy

  --to="nn...@debbugs.gnu.org"  --in-reply-to="message-id"

to your kill ring.

  
https://git.kyleam.com/emacs.d/tree/lisp/km-mail.el?id=928629a9ccd8b439d0e98d9976b75c4cf5f048f9#n225

> AFAIK, there is no ’send-email’ support with Magit.  [...]
>
> What I have understood is that Magit-forge should implement ’send-email’
> as a backend (forge) but it has not happened yet.  Or I missed the
> news. :-)

Right, there's no send-email support in Magit (or any of the extensions
under its organization).  I of course can't speak for Jonas, but I'm not
aware of any movement or concrete plans on that front.  I think the most
recent thread to touch on this is actually the one you opened early this
year about extending format-patch options:
.

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.

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

[zimoun]

Hi Chris

+CC Kyle since they probably knows the status [1].

On Mon, 16 Nov 2020 at 15:28, Christopher Lemmer Webber 
 wrote:

> I've been making patchset series of emails to guix-patches manually.
> I'm sure this is the wrong thing to do.  I use mu4e + magit and know
> others have a similar setup.
>
> What do you all do?

I am sending really few patches so my workflow is probably not
optimized.  What I do is from magit-status:

 1. Select the commits
 2. W c
C-m b origin/master RET
C-m l
c
 3. Edit the cover letter
 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

Be careful if other patches remain in your current worktree.

Note base-commit which provides the information against which commit the
series applies.  It is really helpful for applying; especially if the
series falls in the crack *or* for the “new” tool b4 and the Emacs
front-end piem [2].  See thread here [3]. :-)


AFAIK, there is no ’send-email’ support with Magit.  I have never check
the built-in vc-mode.

What I have understood is that Magit-forge should implement ’send-email’
as a backend (forge) but it has not happened yet.  Or I missed the
news. :-)

I am curious to know how others Emacsers fellows do.


Hope that helps,
simon

1: 
2: 
3: 
4: 

GDM blank for anyone else with guix system vm?

[Christopher Lemmer Webber]

Not sure why but when testing:

  ./pre-inst-env guix system vm gnu/system/examples/lightweight-desktop.tmpl

(and also the normal non-lightweight desktop) I'm getting a blank screen
once gdm is supposed to start up, but the mouse can still move.  I'm
also running the intel graphics card here.

Just curious, is anyone else having this problem?

Re: Package workspace relocation

[zimoun]

Dear,

On Mon, 16 Nov 2020 at 16:56, Stephen Scheck  wrote:

> `/my-project` to become `/foo/bar/my-project`. It sounds like what you

[...]

>> > This results in a path like `/my-package-0.0.1` but
>> `/foo/bar/my-package-0.0.1`.

What do you want?  Append a suffix /tmp/guix-xyz/foo/bar/your-pkg or a
prefix /tmp/foo/bar/guix-xyz/your-pkg?

Change the prefix means changing the TMPDIR environment variable of
guix-daemon (priviliged user).

At first look, I do not know how to add something between guix-xyz-drv-0/
and your-pkg/.  Curious to know how. :-)


Hope that helps,
simon

Re: Package workspace relocation

[Stephen Scheck]

I just need to add a prefix to the directory in which the Git source is
cloned, because its build system requires that. I don't care which TMP
directory Guix daemon uses for its build root. I just need for
`/my-project` to become `/foo/bar/my-project`. It sounds like what you
suggested will do the trick, if I understand it correctly.

Thanks.


On Mon, Nov 16, 2020 at 3:56 PM Leo Famulari  wrote:

> On Mon, Nov 16, 2020 at 03:15:46PM -0500, Stephen Scheck wrote:
> > Is there a way to relocate the package build workspace for a Git clone
> > source, e.g.:
> >
> > (package
> >   (name "my-package")
> >   (version "0.0.1")
> >   (source (origin
> >   (method git-fetch)
> >   (uri (git-reference
> >  (url "https://github.com/my-package;)))
> >  (file-name (git-file-name name version))
> >
> > This results in a path like `/my-package-0.0.1` but
> > because of idiosyncrasies in the project's build system, I need for it to
> > be relocated to something like
> `/foo/bar/my-package-0.0.1`.
> >
> > How can I do this?
>
> I'm not sure that I fully understand what you are asking.
>
> However, the location of the build directory is controlled by the TMPDIR
> variable, which is set in the environment of the guix-daemon. You can
> set it to any location that you want.
>
> An alternative per-package approach is to add a build phase before the
> 'unpack' phase and do something like `mkdir -p foo/bar && chdir
> foo/bar`.
>

Re: Package workspace relocation

[Leo Famulari]

On Mon, Nov 16, 2020 at 03:15:46PM -0500, Stephen Scheck wrote:
> Is there a way to relocate the package build workspace for a Git clone
> source, e.g.:
> 
> (package
>   (name "my-package")
>   (version "0.0.1")
>   (source (origin
>   (method git-fetch)
>   (uri (git-reference
>  (url "https://github.com/my-package;)))
>  (file-name (git-file-name name version))
> 
> This results in a path like `/my-package-0.0.1` but
> because of idiosyncrasies in the project's build system, I need for it to
> be relocated to something like `/foo/bar/my-package-0.0.1`.
> 
> How can I do this?

I'm not sure that I fully understand what you are asking.

However, the location of the build directory is controlled by the TMPDIR
variable, which is set in the environment of the guix-daemon. You can
set it to any location that you want.

An alternative per-package approach is to add a build phase before the
'unpack' phase and do something like `mkdir -p foo/bar && chdir
foo/bar`.

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

[Christopher Baines]

Christopher Lemmer Webber  writes:

> I've been making patchset series of emails to guix-patches manually.
> I'm sure this is the wrong thing to do.  I use mu4e + magit and know
> others have a similar setup.

I think git send-email on the command line does the right thing.

For a single patch, I just git send-email --to=guix-patc...@gnu.org
HEAD^

For a series of patches, it's more drawn out. First I run git
format-patch --cover-letter ... then copy the cover letter in to an
email, and then send to guix-patc...@gnu.org. Then I wait for the
reply, and then git send-email --to=num...@debbugs.gnu.org
--in-reply-to=MESSAGE ID FROM THE FIRST EMAIL.

I'm not sure if the --in-reply-to bit is useful.

I do use mu4e and magit myself, but I'm not sure I know a way of sending
patches more quickly or more easily than this.


signature.asc
Description: PGP signature

Workflow with mu4e + magit for sending patchsets to guix?

[Christopher Lemmer Webber]

I've been making patchset series of emails to guix-patches manually.
I'm sure this is the wrong thing to do.  I use mu4e + magit and know
others have a similar setup.

What do you all do?
 - Chris

Package workspace relocation

[Stephen Scheck]

Is there a way to relocate the package build workspace for a Git clone
source, e.g.:

(package
  (name "my-package")
  (version "0.0.1")
  (source (origin
  (method git-fetch)
  (uri (git-reference
 (url "https://github.com/my-package;)))
 (file-name (git-file-name name version))

This results in a path like `/my-package-0.0.1` but
because of idiosyncrasies in the project's build system, I need for it to
be relocated to something like `/foo/bar/my-package-0.0.1`.

How can I do this?

Thanks.

Package building with gcc-10

[Hamzeh Nasajpour]

Hi guys.
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? 


```
...
/tmp/guix-build-my-cpp-app-0.1.1.drv-0/my-cpp-app/src/GUI/FileDownloader.h:27:10:
 fatal error: filesystem: No such file or directory
 #include 
  ^~~~
compilation terminated.
make[2]: *** [CMakeFiles/my-cpp-app.dir/build.make:121: 
CMakeFiles/my-cpp-app.dir/src/GUI/ContentList.cpp.o] Error 1
make[2]: Leaving directory '/tmp/guix-build-my-cpp-app-0.1.1.drv-0/build'
make[1]: *** [CMakeFiles/Makefile2:208: CMakeFiles/my-cpp-app.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
[ 69%] Linking CXX executable test_DataAccessLayer
/gnu/store/89rj5fqcg48afgk99639ds602pgf92k4-cmake-minimal-3.16.5/bin/cmake -E 
cmake_link_script CMakeFiles/test_DataAccessLayer.dir/link.txt --verbose=1
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/bin/c++   -Wall -O2 -g 
-DNDEBUG  -rdynamic 
CMakeFiles/test_DataAccessLayer.dir/test_DataAccessLayer_autogen/mocs_compilation.cpp.o
 CMakeFiles/test_DataAccessLayer.dir/tests/TestDataAccessLayer.cpp.o  -o 
test_DataAccessLayer  
/gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/libQt5Test.so.5.14.2
 lib_my-cpp-app.a 
/gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/libQt5Widgets.so.5.14.2
 
/gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/libQt5Gui.so.5.14.2
 
/gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/libQt5Network.so.5.14.2
 
/gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/libQt5Sql.so.5.14.2
 
/gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/libQt5DBus.so.5.14.2
 
/gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/libQt5Core.so.5.14.2
 -lrec 
[ 70%] Linking CXX executable test_AsyncTaskRunner
/gnu/store/89rj5fqcg48afgk99639ds602pgf92k4-cmake-minimal-3.16.5/bin/cmake -E 
cmake_link_script CMakeFiles/test_AsyncTaskRunner.dir/link.txt --verbose=1
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/bin/c++   -Wall -O2 -g 
-DNDEBUG  -rdynamic 
CMakeFiles/test_AsyncTaskRunner.dir/test_AsyncTaskRunner_autogen/mocs_compilation.cpp.o
 CMakeFiles/test_AsyncTaskRunner.dir/tests/TestAsyncTaskRunner.cpp.o  -o 
test_AsyncTaskRunner  
/gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/libQt5Test.so.5.14.2
 lib_my-cpp-app.a 
/gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/libQt5Widgets.so.5.14.2
 
/gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/libQt5Gui.so.5.14.2
 
/gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/libQt5Network.so.5.14.2
 
/gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/libQt5Sql.so.5.14.2
 
/gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/libQt5DBus.so.5.14.2
 
/gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/libQt5Core.so.5.14.2
 -lrec 
[ 72%] Linking CXX executable test_RecDB
/gnu/store/89rj5fqcg48afgk99639ds602pgf92k4-cmake-minimal-3.16.5/bin/cmake -E 
cmake_link_script CMakeFiles/test_RecDB.dir/link.txt --verbose=1
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/bin/c++   -Wall -O2 -g 
-DNDEBUG  -rdynamic 
CMakeFiles/test_RecDB.dir/test_RecDB_autogen/mocs_compilation.cpp.o 
CMakeFiles/test_RecDB.dir/tests/TestRecDB.cpp.o  -o test_RecDB  
/gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/libQt5Test.so.5.14.2
 lib_my-cpp-app.a 
/gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/libQt5Widgets.so.5.14.2
 
/gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/libQt5Gui.so.5.14.2
 
/gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/libQt5Network.so.5.14.2
 
/gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/libQt5Sql.so.5.14.2
 
/gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/libQt5DBus.so.5.14.2
 
/gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/libQt5Core.so.5.14.2
 -lrec 
make[2]: Leaving directory '/tmp/guix-build-my-cpp-app-0.1.1.drv-0/build'
[ 72%] Built target test_DataAccessLayer
make[2]: Leaving directory '/tmp/guix-build-my-cpp-app-0.1.1.drv-0/build'
[ 72%] Built target test_AsyncTaskRunner
make[2]: Leaving directory '/tmp/guix-build-my-cpp-app-0.1.1.drv-0/build'
[ 72%] Built target test_RecDB
[ 74%] Linking CXX executable test_PackageManager
/gnu/store/89rj5fqcg48afgk99639ds602pgf92k4-cmake-minimal-3.16.5/bin/cmake -E 
cmake_link_script CMakeFiles/test_PackageManager.dir/link.txt --verbose=1
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/bin/c++   -Wall -O2 -g 
-DNDEBUG  -rdynamic 
CMakeFiles/test_PackageManager.dir/test_PackageManager_autogen/mocs_compilation.cpp.o
 CMakeFiles/test_PackageManager.dir/tests/TestPackageManager.cpp.o  -o 
test_PackageManager  
/gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/libQt5Test.so.5.14.2
 lib_my-cpp-app.a