Re: Video narration

[sirgazil]

El 25/03/19 a las 5:49 p. m., Laura Lazzati escribió:

[...]


The question about flickering could take some investigation.  Do we
know yet whether this is consistent across all players? or are there
examples where flickering does not happen?

With VLC and mpv they are fine. Please, try them ant let us know :)


If others could test with their own players that may give us a clue.

Sure, as many players, the better.


I haven't checked the flickering problem yet, but I'd like to add again 
that the resulting videos don't play in the browser because there seems 
to be a corruption issue. Maybe the flickering could be related to this 
corruption?


So, maybe it would be better to investigate the cause of the corruption 
first? And then one could think of possible ways to add transitions 
between the slides and CLI videos if the flickering is caused by 
something else.


I think :)


[...]

--
Luis Felipe López Acevedo
http://sirgazil.bitbucket.io/

Re: create a symlink

[Danny Milosavljevic]

On Wed, 13 Mar 2019 15:52:36 +0100
Ludovic Courtès  wrote:

> Hello,
> 
> Rene  skribis:
> 
> > How I can change "/hurd/" by "/gnu/store/abc..-hurd-0.9/hurd/" in
> >  through Guix?  
> 
> I think /hurd is hard to avoid; it’s akin to /bin/sh, which is also
> hard-coded in libc (for the ‘system’ function).  As you found out, you’d
> need to change macros in libc headers, which means that libc could only
> talk to a specific instance of the Hurd servers.  Furthermore, /hurd
> needs to be writable.
> 
> So I would recommend keeping /hurd, at least as a first approach.

In that case, /hurd could be handled like we handle /run/booted-system .

Rene could use service extension like

  (service-extension boot-service-type hurd-boot-gexp)

in order to create the "/hurd" symlink (in hurd-boot-gexp).

That is, if the Hurd can boot that far (until the root filesystem is mounted).

In fact, as a hack, we could create a dummy service that does the service
extension and use it for the Hurd.


pgp17J4TQvkPJ.pgp
Description: OpenPGP digital signature

Re: Video narration

[Laura Lazzati]

Hi :)
Sorry for my late response today, have just arrived home.


> Yes, sounds a good plan.  I will aim to work through the videos to
> build each one, then listen to the playback and then edit the
> transcript at a rate of one-per-day this week.  That should mean
> finishing them all by the end of this week.
>
> If you can do the cli sessions as well that would fit in perfectly.  I
> have put back the recording session to next Tuesday 2nd April so that
> there is a little more time to get everything finished.
SGTM, hope I can have all the cli sessions with sound, like I said,
they take much longer and sometimes it is mixing, arranging cli file,
mixing again, arranging and so on.
>
> The question about flickering could take some investigation.  Do we
> know yet whether this is consistent across all players? or are there
> examples where flickering does not happen?
With VLC and mpv they are fine. Please, try them ant let us know :)
>
> If others could test with their own players that may give us a clue.
Sure, as many players, the better.
>
> One other suggestion was to check the codecs.  Do the slides and the
> cli sessions use the same codec?
I don't want to give wrong information, I don't remember now  :/ I'd
rather do the recordings this week (at least me).

Regards :)
Laura

Re: Zotero Packaging Request

[Raghav Gururajan]

Hi Pierre!

Thank you very much for your consideration.

Regards,
RG.

March 25, 2019 7:21 PM, "Pierre Neidhardt"  wrote:

> Hi!
> 
> This does not seem too hard. Anyone?
> If no one gets to it within a week, I'll do it.
> Please ping me.
> 
> -- 
> Pierre Neidhardt
> https://ambrevar.xyz

Re: Zotero Packaging Request

[Pierre Neidhardt]

Hi!

This does not seem too hard.  Anyone?
If no one gets to it within a week, I'll do it.
Please ping me.

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


signature.asc
Description: PGP signature

Re: Nano: disable hard wrapping by default

[Leo Famulari]

On Tue, Nov 06, 2018 at 07:43:21PM +0100, swedebugia wrote:
> I stumpled on this hard-wrapping default behavior when editing .bash_profile
> on GuixSD

This issue should be fixed with commit
cdfb69b46abbdaa2ac0a80b5f92172cd1290a782, which upgrades our nano
package to nano 4.0.

This release changes the default wrapping behavour to not wrap at all.


signature.asc
Description: PGP signature

Zotero Packaging Request

[Raghav Gururajan]

Hello Guix!

Can anyone package Zotero (https://www.zotero.org/) into Guix? It is a powerful 
reference management software that is being used in academia, literature and 
journalism. This packaging will be useful for many users. Kindly consider.

Please and Thank you!

Regards,
RG.

Re: Automated linting before master branch commit

[Ricardo Wurmus]

Danny Milosavljevic  writes:

>> Estimated number of packages with autogenerated tarball:
>> 
>> 389
>
> Yeah, those should be updated.  With that many packages, writing a script
> to do it would be less annoying.

Most of these packages were added before we realized that these
generated tarballs are not stable.  There has been an effort to remove
them.  Linting would not have prevented this.

-- 
Ricardo

Re: Feature requests

[Joshua Marshall]

Thank you!  I have ~500 pages of other stuff to read this week, but I'll
get to this as soon as I can.

On Mon, Mar 25, 2019 at 5:40 AM Giovanni Biscuolo  wrote:

> Hi Joshua,
>
> Joshua Marshall  writes:
>
> [...]
>
> > I'd like to see it take on
> > the ability to have a per-installation target cgroup, network namespace,
> > and filesystem chroot settings set with defaults which are overridable at
> > invocation.
>
> me too and the only missing point above (AFAIU) is network isolation for
> Guix containers, I mean one created via `guix environment` or `guix
> system container`)
>
> having that, the "last mile" in *obsoleting* tools like Docker &
> Co. (e.g. kubernetes, even openstack probably) is to have a declarative
> way to setup containers, something like `containers.` from NixOS
> [1]
>
> ...and a set of Guix services to declaratively `scale out` an
> infrastrtucture: a layer 4+7 proxy (e.g. haproxy, missing in Guix),
> Software Defined Network (openvswitch, got it!), Software Defined
> Storage (ceph: we have the pachage but missing the service AFAIU)
>
> anyway: containers are here to solve infrastructural problems, not
> development environments problems :-)
>
> [1] https://nixos.org/nixos/manual/index.html#sec-declarative-containers
>
> > In this way, a user could install and use packages with
> > mutually incompatible dependencies (I talked about this with a few people
> > on IRC) like what happens with python.  If this kind of functionality
> were
> > added, it would largely supplant Docker,
>
> you cited Docker so I guess you are using containers as a mean to
> isolate *development environment* each other and from the *production
> environment*, not to build an insfrastructure of isolated set of
> processes (including networking layer) - let's call them nodes -
> possibly distributed on several hosts
>
> in this thread Julien already explained how to achieve this with `guix
> environment`: with Guix (and Nix, the *only* other sofware natively
> permitting this) you don't need to install a container to have
> *isolated* development environments
>
> AFAIU in *many*, many, many use cases containers (Docker, LXC and so on)
> are _not_ used as an infrastructural component but as a development
> tool: Guix obsoletes this thanks to its native isolated environments
> (made possible by The Store)
>
> I hope more and more developers will realize this since this is
> _for_sure_ a big win for the entire free software community (no more
> python virtualenv clones, *please*)
>
> > virtualenv, pip, poetry, apk,
> > pacman, and probably a few other tools at my company which are there just
> > to handle this kind of frailness.
>
> `guix environment` and the package definition programming interface [2]
> (it's really easy to learn, believe me :-) ) are your best friends here
>
> you can even `guix pack` sofware bundles (e.g. in Docker format) and
> distribute it to your internal/external customers who are still not able
> to use Guix to install them
>
> [2]
> https://www.gnu.org/software/guix/manual/en/html_node/Defining-Packages.html#Defining-Packages
>
> [...]
>
> HTH to better explain how development works in a Guix environment :-)
>
> Gio
>
> --
> Giovanni Biscuolo
>
> Xelera IT Infrastructures
>

-- 



Please be advised that this email may contain confidential information. 
If you are not the intended recipient, please notify us by email by 
replying to the sender and delete this message. The sender disclaims that 
the content of this email constitutes an offer to enter into, or the 
acceptance of, any agreement; provided that the foregoing does not 
invalidate the binding effect of any digital or other electronic 
reproduction of a manual signature that is included in any attachment.


 
   
   

Re: Automated linting before master branch commit

[Danny Milosavljevic]

Hi,

> What do people think about automating package linting?  This would be to
> make sure a package is linted before it is committed to the Guix
> repository master branch?

A linter by its nature will in some cases flag things which are not wrong,
otherwise one could just check the stuff while compiling in the first place.

> I am not familiar with what Guix uses for continuous integration /
> deployment.

We can manually make cuirass and/or Hydra evaluate custom branches--but it's
not automated.

Christopher Baines is working on making patch review better--see thread
"Patchwork + automated checking and testing of patches".

> Estimated number of packages with autogenerated tarball:
> 
> 389

Yeah, those should be updated.  With that many packages, writing a script
to do it would be less annoying.


pgpAHtAiVoyUM.pgp
Description: OpenPGP digital signature

Automated linting before master branch commit

[mikadoZero]

# Automated linting

What do people think about automating package linting?  This would be to
make sure a package is linted before it is committed to the Guix
repository master branch?

I am not familiar with what Guix uses for continuous integration /
deployment.

I do not know if automated linting is already in place.  The packages
on the master branch that have linting issues could have been committed
before automated linting was in place.

# Acknowledgment

It was brought to my attention by Tobias Geerinckx-Rice:

"... tarballs aren't guaranteed to be stable over time (GitHub can
regenerate them, changing the metadata and hence the hash, and has done
so in the past). 

They must not be used.  ..."

https://lists.gnu.org/archive/html/help-guix/2019-03/msg00096.html

# Guix master branch

There are package in the Guix repository master branch that use an
autogenerated tarball and have this lint output:

"the source URI should not be an autogenerated tarball"

# Number of packages

Estimated number of packages with autogenerated tarball:

389

This is a low estimate as it is only counts GitHub autogenerated
tarballs.

This estimate is from this command run in the Guix repository.

`grep github.*archive gnu/packages/*scm | wc -l`

Re: Feature requests

[Giovanni Biscuolo]

Hi Joshua,

Joshua Marshall  writes:

[...]

> I'd like to see it take on
> the ability to have a per-installation target cgroup, network namespace,
> and filesystem chroot settings set with defaults which are overridable at
> invocation.

me too and the only missing point above (AFAIU) is network isolation for
Guix containers, I mean one created via `guix environment` or `guix
system container`)

having that, the "last mile" in *obsoleting* tools like Docker &
Co. (e.g. kubernetes, even openstack probably) is to have a declarative
way to setup containers, something like `containers.` from NixOS
[1]

...and a set of Guix services to declaratively `scale out` an
infrastrtucture: a layer 4+7 proxy (e.g. haproxy, missing in Guix),
Software Defined Network (openvswitch, got it!), Software Defined
Storage (ceph: we have the pachage but missing the service AFAIU)

anyway: containers are here to solve infrastructural problems, not
development environments problems :-)

[1] https://nixos.org/nixos/manual/index.html#sec-declarative-containers

> In this way, a user could install and use packages with
> mutually incompatible dependencies (I talked about this with a few people
> on IRC) like what happens with python.  If this kind of functionality were
> added, it would largely supplant Docker,

you cited Docker so I guess you are using containers as a mean to
isolate *development environment* each other and from the *production
environment*, not to build an insfrastructure of isolated set of
processes (including networking layer) - let's call them nodes -
possibly distributed on several hosts

in this thread Julien already explained how to achieve this with `guix
environment`: with Guix (and Nix, the *only* other sofware natively
permitting this) you don't need to install a container to have
*isolated* development environments

AFAIU in *many*, many, many use cases containers (Docker, LXC and so on)
are _not_ used as an infrastructural component but as a development
tool: Guix obsoletes this thanks to its native isolated environments
(made possible by The Store)

I hope more and more developers will realize this since this is
_for_sure_ a big win for the entire free software community (no more
python virtualenv clones, *please*)

> virtualenv, pip, poetry, apk,
> pacman, and probably a few other tools at my company which are there just
> to handle this kind of frailness.

`guix environment` and the package definition programming interface [2]
(it's really easy to learn, believe me :-) ) are your best friends here

you can even `guix pack` sofware bundles (e.g. in Docker format) and
distribute it to your internal/external customers who are still not able
to use Guix to install them

[2] 
https://www.gnu.org/software/guix/manual/en/html_node/Defining-Packages.html#Defining-Packages

[...]

HTH to better explain how development works in a Guix environment :-)

Gio

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: Include Proot-static with binary releases

[Ludovic Courtès]

Hi!

Danny Milosavljevic  skribis:

> On Tue, 23 Jan 2018 15:49:26 +0100
> ludovic.cour...@inria.fr (Ludovic Courtès) wrote:
>
>> > Currently proot only build successfully on x86_64 and i686, so that is
>> > something we would need to fix first.  
>
> Are you sure that is not just a limitation of the qemu transparent emulation?

Oh, I hadn’t thought about that.

> I examined the test failures in proot-static and it's clear that qemu will 
> have
> some trouble finding out what one wants to happen:
>
>>#include  /* execve(2), */
>>#include  /* exit(3), */
>>#include  /* strcmp(3), */
>>
>>int main(int argc, char *argv[])
>>{
>>if (argc == 0)
>>exit(EXIT_SUCCESS);
>>
>>execve("/proc/self/exe", NULL, NULL);
>>exit(EXIT_FAILURE);
>>}
>
> Now, qemu transparent emulation still picks up, but then the missing
> argv[0] will be a problem.
>
> And indeed,
>
> $ guix environment -s armhf-linux proot-static
> [...]
> [env]$ ./test-25069c12
> qemu: no user program specified

Are you saying that /proc/self/exe is incorrect when using binfmt_misc?
D’oh!

--8<---cut here---start->8---
$ uname -m
x86_64
$ guix environment --ad-hoc coreutils -s armhf-linux
[env]$ uname -m
armv7l
[env]$ sleep 100 &
[1] 2410
[env]$ ls -l /proc/2410/exe 
lrwxrwxrwx 1 ludo users 0 Mar 25 09:55 /proc/2410/exe -> 
/gnu/store/6ar48khay4zd435cvkv4bgf1jih7jimq-qemu-3.1.0/bin/qemu-arm
--8<---cut here---end--->8---

So that could well be a problem (potentially in other packages as well;
I didn’t expect /proc/self/exe to be “wrong”.)

We’ll have to check what happens on berlin though, because there we
build on the bare metal.

Thanks,
Ludo’.

Re: Package file indexing

[Pierre Neidhardt]

Hi!

Thanks for the details, Ludo!

Ludovic Courtès  writes:
> An index could look like, say, a list of store item/file pairs.  It
> would grow very quickly, which may not be very practical.

I think we might need some form of rotation and discard the old indexes
to avoid growing up indefinitely.  Well, we will see once we've started
using it!

> ‘guix publish’ could update that list every time it “bakes” a nar.
>
> The daemon could have a special RPC: you give it a file name and it
> returns a store item (or package+version?) or #f.

I think you meant "store itemS" (plural), no?

> Internally it’d call ‘guix substitute’ to fetch the file index from
> the substitute server, check its signature, cache it locally, and then
> look up the file.
>
> You should look at how NixOS does it for its ‘command-not-found’ support
> (I think it’s part of NixOS, not Nix).  IIRC they distribute an SQLite
> database, but it’s a pretty ad-hoc mechanism without authentication.

I could work on this, but that seems like a lot of work, especially for
me who knows nothing about the daemon (but hey, it's a great opportunity
to learn!).

Would anyone  else like to pick this up?

Otherwise I'll keep this on my todo list.

Cheers!

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


signature.asc
Description: PGP signature

Building custom kernel modules (e.g. VHBA for CDEmu)

[Pierre Neidhardt]

Hi!

The question of building custom Linux kernel modules was recently
brought up in bug #35758 (packaging CDEmu).

I'll summarize: a typical Makefile to build a kernel module looks like
this:

 --8<---cut here---start->8---
 VHBA_VERSION := 20170610

 KERNELRELEASE ?= $(shell uname -r)
 KDIR ?= /lib/modules/$(KERNELRELEASE)/build
 PWD ?= $(shell pwd)

 obj-m := vhba.o
 ccflags-y := -DVHBA_VERSION=\"$(VHBA_VERSION)\" -Werror

 default: modules
 install: modules_install

 modules modules_install clean:
 $(MAKE) -C $(KDIR) M=$(PWD) $@
 --8<---cut here---end--->8---

The only thing we need, beside a C compiler, is this KDIR, which on Guix
_could_ be found at

  /gnu/store/…-linux-libre-5.0.1/lib/modules/5.0.1/build

Sadly, for us it's a dangling link to
/tmp/guix-build-linux-libre-5.0.1.drv-0/linux-5.0.1.

I presume that the answer is simple: replace the link with the folder.
But that would eat up significantly more disk space.  So we could
replace the link with a link to a new "build" output of the linux-libre
package, which would contain this "build" folder.

Thoughts?

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


signature.asc
Description: PGP signature