Re: How to M-x debbugs-gnu with new guix-patches

[Ludovic Courtès]

Hi!

Catonano  skribis:

> In asking for directions I was referring to the workflow in using the 
> debbugs-emacs thing, how to save a patch locally when receiving it on the 
> mailing list, how to apply it 

I just pipe the message (with ‘|’ in Gnus) to “git am -s” and voilà.

> The way I found is a tiny button in the toolbar that saves a patch locally.
>
> But is there anymore to know ? or example, does the debbugs-emacs thing offer 
> a way to apply a patch to a branch ?

No, nothing more than what I described above.

HTH!

Ludo’.

Another cli interface for guix/sd

[Amirouche Boubekki]

Héllo,

This is a reply to a previous conversation that was started last year
http://lists.gnu.org/archive/html/guix-devel/2016-04/msg00724.html

To help you avoid the need to read the above long thread here is
summary:

a) We need to do something regarding guix cli
b) We need to move commands inside "guix package"
b prime) we do not need to move commands inside "guix package" because it's
more to type.
c) We need to turn "guix package" options into separate sub-commands
d) We need to handle the fact that some commands operate on store items,
derivations, etc.
e) We need to avoid having 20 or something commands in the first level (*)
f) We need separate commands/cli for user and devs
f bis) We need a single "guix" full featured guix command
g) We need a "guix install" alias
h) Do we need to keep the ability add/remove packages in a single txn (* to
this I reply we should improve the profile generation manipulation with for
instance something like git rebase -i)
i) we must use flags/options/switches to nuance how a given command should
be executed
k) we should empower the user aka. one must understand how things works via
the cli

So I summed things in the following cli mockup:

xote container attach NAME
xote container init NAME SPEC
xote container start NAME

xote helper download URL
xote helper hash FILE

xote package archive export [-r] PACKAGE
xote package archive import
xote package build PACKAGE
xote package challenge PACKAGE
xote package edit PACKAGE
xote package graph PACKAGE
xote package import IMPORTER ARGS
xote package lint PACKAGE
xote package pack PACKAGE
xote package size PACKAGE
xote package search PACKAGE

xote profile delete-generations
xote profile enter
xote profile init
xote profile install
xote profile leave
xote profile list-generations
xote profile list-installed
xote profile manifest
xote profile rebase
xote profile refresh
xote profile remove
xote profile rollback
xote profile switch-generations

xote publish

xote pull

xote store gc

xote system build
xote system container
xote system disk-image
xote system extension-graph
xote system init
xote system reconfigure
xote system refresh
xote system rollback
xote system shepherd-graph
xote system switch-generation
xote system vm
xote system vm-image

In particular:

- guix environement is gone, because it can be replaced with guix profile
- I think the cli should reflect the underlying inner working but also the
usage. For instance, one might argue that containers are just systems (or
profiles) but for the user it makes a great difference to have the commands
spread as several multiple commands instead of a single command that does
everything required.
- There is surely missing commands in the "store" section, input welcome!
- There is two single commands without subcommands called "pull" and
"publish". I am not sure where to put them.

Also, I did not look into it too much, but when I try to import guix inside
a guile REPL I can't. So my current work is in a fork of guix repository.
Is it possible to create a guix project without it being in the guix
repository?

Feedback welcome!

PS: the "xote" name comes from quixote.

Re: [PATCH 01/26] gnu: Add perl-file-pushd.

[Alex Sassmannshausen]

Heya,

Thank you all for your advice!

I can confirm that the builds were successful locally.

On the back of this I will push to master later this evening.

Cheers,

Alex

Kei Kebreau writes:

> Alex Sassmannshausen  writes:
>
>> Hi Ben,
>>
>> Ben Woodcroft writes:
>>
>>> Hi,
>>>
>>>
>>> On 24/03/17 18:13, Alex Sassmannshausen wrote:
 Hi Kei,

 Kei Kebreau writes:

> This series of packages builds and lints fine for me. There are over 200
> dependent packages that would have to be rebuilt though, and
> core-updates is frozen to my knowledge. We can save this for the next
> core-updates cycle, though!
>
> Other Guix users, please correct me if I'm wrong.
>>> According to the established guidelines, this should be OK for master
>>> since it affects <300 packages, so if all dependent packages build then
>>> I don't see why we shouldn't do that.
>>>
>>> https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html
>>
>> Cheers for your comments, very enlightening!  I'm afraid I'm out of my
>> depth making this decision here.  I'm happy to let my computer rebuild
>> those 200 packages to see whether the dependent packages build — but
>> I'm not sure how I would go about testing that.  See below for a theory…?
>>
 Thanks for the review!

 What command do you use to check the number of packages that would have
 to be rebuilt?  I'm asking, because if they are mainly perl libraries
 then that figure of 200 really isn't that big of a deal: most perl libs
 build super fast.
>>> To check the number of packages use "guix refresh -l"
>>
>> Interesting… so to establish the packages to be rebuilt as a result of
>> my patch series, would that be:
>>
>> guix refresh -l perl-scalar-list-utils perl-parse-cpan-meta  \
>> perl-cpan-meta-requirements perl-yaml perl-variable-magic\
>> perl-time-duration-parse perl-test-warnings perl-test-simple \
>> perl-test-exception perl-test-cleannamespaces perl-sub-name  \
>> perl-params-validate perl-package-deprecationmanager perl-moose  \
>> perl-module-runtime-conflicts perl-devel-partialdump \
>> perl-devel-overloadinfo perl-cpan-meta-check perl-common-sense   \
>> perl-clone perl-class-load perl-capture-tiny perl-b-hooks-endofscope
>>
>> Building the following 24 packages would ensure 248 dependent packages
>> are rebuilt: edirect-4.10 perl-modern-perl-1.20150127
>> perl-text-neattemplate-0.1101 perl-encode-detect-1.01
>> perl-list-someutils-0.52 perl-db-file-1.838 pam-krb5-4.7
>> perl-test-trailingspace-0.0300 sslh-1.18 perl-mail-spf-v2.9.0
>> gerbv-2.6.1 netsurf-3.6 perl-config-ini-0.025 perl-anyevent-i3-0.16
>> tophat-2.1.0 perl-test-class-most-0.08 gnucash-2.6.15 surfraw-2.2.9
>> biber-2.5 biber-next-2.6 stow-2.2.2 perl-x11-xcb-0.16 roary-3.7.0
>> hydra-20151030.1ff48da
>>
>> Does this mean, that in order to test this I would now simply try to
>> rebuild the 24 listed packages?
>
> Yes. Just make sure you use `./pre-inst-env guix build` so that you're
> testing the updated perl packages. Thanks!
>
>>
>> Cheers,
>>
>> Alex

Re: How to M-x debbugs-gnu with new guix-patches

[Catonano]

2017-02-26 20:02 GMT+01:00 Christopher Allan Webber 
:

> Pjotr Prins writes:
>
> > I submitted my first patch on debbugs. It is a fairly trivial one for
> > speedtest-cli which I need because I move around so much ;)
>

Yes, this writeup is way cool

A great reference !

Thank you Pjotr !

BUT ! ;-)

In asking for directions I was referring to the workflow in using the
debbugs-emacs thing, how to save a patch locally when receiving it on the
mailing list, how to apply it

The way I found is a tiny button in the toolbar that saves a patch locally.

But is there anymore to know ? or example, does the debbugs-emacs thing
offer a way to apply a patch to a branch ?

Thanks again !

Re: Advice about GuixSD on Serveraptor?

[Chris Marusich]

ng0  writes:

> Chris Marusich transcribed 2.4K bytes:
>> ng0  writes:
>> 
>> > If IN-Berlin uses (or needs) nothing special for the consoleserver to
>> > make use of the virtual servers within IN-Berlin infrastructure, I think
>> > it would be best if we (as Guix) could provide an extended bare image
>> > for servers which would include ssh-daemon on default port with password
>> > login enabled, where the password is not empty. That's a workaround I
>> > can imagine to be generic enough for all use cases.
>> > For the one of IN-Berlin and maybe similar hosters who use ssh pubkeys,
>> > it would be great to document for them how to recreate this image in
>> > easy steps and insert the clients ssh pubkey for the root account (or an
>> > named user) on the system.
>> >
>> > What do you think about this?
>> 
>> Instead of providing a pre-built image of a specific system with
>> pre-built credentials, wouldn't it be better to add a feature that, in
>> the spirit of a command like 'guix disk-image', builds an entire system
>> that can then be imported as-is into IN-Berlin?
>> 
>> In general, such a feature would be useful.  One can imagine leveraging
>> a feature like this to import custom GuixSD systems into various hosting
>> services - Amazon EC2, Rackspace, wherever.  Instead of starting with a
>> pre-built image that might be hard to reproduce or verify, and then
>> mutating that system to suit your needs, you could just import the exact
>> system that you want to deploy.  Wouldn't that be better?
>> 
>> -- 
>> Chris
>
> Their system works in the way that you provide the key and they give you
> access via ssh to the new server. My suggestion was a work-around.

I think your proposed solution is a good one.  It sounds like that's a
good way to get a GuixSD server running on IN-Berlin at this time.

> Beyond that, can you please explain what exactly you mean? I don't want
> to read between the lines as there are multiple ways I could interpret
> this message.

Sure, let me see if I can clarify what I was thinking.

For example, the Amazon EC2 service provides web APIs that one can call
to import an existing VM image into the service.  One can then launch
EC2 instances (virtual machines) from that image.  I'm sure that some
other services have similar APIs.  With Guix, we can declaratively
configure the entire operating system (including the pre-installation of
SSH credentials to enable remote access) and build an image (or a VM) of
that system.  In theory, it should be possible to create a tool (e.g.,
"guix deploy") which not only creates the precise system image you want
from an operating system configuration file, but also imports it into a
hosting service, like Amazon EC2, and provisions a virtual (or physical)
machine from that image.

The same principle could apply even for providers that don't currently
support programmatic importation of system images (like IN-Berlin,
maybe?).  For example, if a company offers to accept a bootable disk
image and provide you with a physical server that runs that image, you
could also "import" a system into that service by building the image and
then providing it (manually) to them.  If instead of a disk image they
require a bootable ISO-9669 file system image (i.e., a bootable CD-ROM
image) or a special VM format like OVF, then that's just an
implementation detail.  In theory it's still possible to "import" an
entire system by building an entire system in the format that they need,
and then (manually) providing it to them.

Based on your description, it sounds like IN-Berlin's process requires
manual touch points, so I think it's a fine solution to provide
IN-Berlin with your public SSH key (or a temporary password) along with
instructions for how to build the GuixSD system you want, wait for them
to provision the server, and then log in remotely to further customize
the system.  However, I think it would be really cool if you could just
specify the final, customized system (SSH keys and all) in an operating
system configuration file and then invoke a tool like "guix
deploy-to-ec2 my-system-config.scm" to build the system described by
my-system-config.scm, import it into EC2 (or some other service or
provider), and run it on there.  It would be really cool because your
system wouldn't start in a possibly stale or difficult-to-reproduce base
system, and you wouldn't need to perform additional customization after
the system starts up.  All customizations (to the extent that they are
managed by Guix - things like the contents of user home directories and
the state contained in databases running on the system are not managed
by Guix) would be declared in the operating system configuration file.

Currently, I don't think Guix has the features necessary to support this
kind of programmatic importation of GuixSD systems into service
providers like Amazon EC2.  But the potential is there, and it's good to
think big.

--