Re: native or not

[Mathieu Othacehe]

Hello Vincent,

> Is there a way to see any benefit from these changes
> (without building a vm or container image each time) ?
>
> Are those changes useful to do on their own ?

Well yes it may reduce the closure size of the package (run `guix size
sudo`) to get it.

It can also fix cross-compilation. Because when cross-compiling, if
groff needs to be run at build-time, it needs to be for the native
architecture and not the target one.

You can check it by running `guix build --target=aarch64-linux-gnu sudo`
for instance.

Thanks,

Mathieu

Re: [GSOC 2020] Final proposal

[Ricardo Wurmus]

Hi Alberto,

> Hello, this is my final proposal for GSoC, there is still time to do
> some changes in case anyone has feedback, otherwise this is it :)

Thank you for this thorough proposal!

For 8.5 it would be good to provide criteria that allow us to evaluate
your progress.  Being able to look at the code is obviously a
precondition, but what we really want to know is what features will have
to have been completed (and to what degree) at the time of the
evaluation.

For some of the deliverables and goals it would be good to see a little
more detail if possible.  You mention systemd.device and systemd.socket
files, but I can’t imagine what your goals with regards to the Shepherd
are — is it to implement a similar feature (what exactly would that
be?), or support for reading these files…?

--
Ricardo

[GSOC 2020] Final proposal

[Alberto EFG]

Hello, this is my final proposal for GSoC, there is still time to do
some changes in case anyone has feedback, otherwise this is it :)



proposal-final.pdf
Description: Adobe PDF document

[URGENT, ACTION REQUIRED] GSoC final proposal submission deadline

[Gábor Boskovits]

To all GSoC applicants:

According to the GSoC 2020 timeline the final deadline for submitting a proposal
is:
March 31 18:00 UTC

You can find further information here:
https://google.github.io/gsocguides/student/writing-a-proposal

Please make sure that your final PDF proposal is submitted on the GSoC site
before the deadline, otherwise we will not be able to select you.

Thank you for all the work done so far.

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

Re: Linphone

[Raghav Gururajan]

Maxim and Ricardo!

>>> Did Ricardo's suggestion help? I'm interested in Linphone on Guix! The
>>> more VoIP options we have on the table in the times we're in, the better
>>> :-). If you have more issues, do reach out, and I'll see if I can lend a
>>> hand.
>> 
>> Danny's idea fixed it. It was a typo inside the source code.
>> 
>> Sure, I will keep you posted. I have started to send my Linphone patches
>> (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=40264). I will ping you if I 
>> gett stuck with
>> something. :-)
>>> I ran into trouble with belle-sip. Would you be able to help with
>>> that? I have attached the package definition of belle-sip, along with
>>> libantlr3c patch, with this email.
>> 
>> You forgot to tell us what the trouble is.
> 
> Sorry about that, I was not sure how to describe what I saw. There was 
> multiple red error messages
> during the build. They were related to some kind of parsing. Here is the 
> build log
> https://bin.disroot.org/?8c6d055dbf3a35fe#CGYyfsJeSVA6NJTsqcVXiTf8jtHdbJhpJmTXwKeKFgTP

I fixed the issue. I had to make antlr3-3.3 variable public and use it. :-)

Regards,
RG.

native or not

[Vincent Legoll]

Hello,

I've been having a first look at guix data service.

And looking at the guix lint page, I saw the "should
probably be native input" warnings, and gave it a
try on sudo, naively thinking it would benefit
something (maybe a container or vm image size).

Is there a way to see any benefit from these changes
(without building a vm or container image each time) ?

Are those changes useful to do on their own ?

For example this:

diff --git {a,b}/gnu/packages/admin.scm
index 2f661f5e81..457dc1e3dc 100644
--- a/gnu/packages/admin.scm
+++ b/gnu/packages/admin.scm
@@ -1268,9 +1268,10 @@ system administrator.")
#:tests? #f))
+(native-inputs
+ `(("groff" ,groff)))
 (inputs
- `(("groff" ,groff)
-   ("linux-pam" ,linux-pam)
+ `(("linux-pam" ,linux-pam)
("zlib" ,zlib)


-- 
Vincent Legoll

Re: Brainstorming features for issues.guix.gnu.org

[Björn Höfling]

Hi Ricardo,

On Thu, 26 Mar 2020 09:49:12 +0100
Ricardo Wurmus  wrote:

> Hello Guix!
> 
> I want issues.guix.gnu.org to become more useful for all of us.  It’s
> easy to get lost in a deluge of bug reports and patch submissions, so
> our tools should allow us to stay afloat.
> 
> Do you use issues.guix.gnu.org?  If you aren’t: what workflow do you
> have to review patch submissions?

I prefer my mailbox, with sometimes looking through the Debbugs web
page. I have to admit, I'm not using it and I think it is not
intuitive. It is as colorful as the bug trackers at github.com, but not
as useable as them.

Here are my suggestions for mumi, some of them already said by others:

* First of all, I find this mixture very confusing: Is this about bugs
or is this about patches? I really don't know, and the start page is
ambigious about it too: 

"Guix /patch/ tracker
This is a web frontend to the Guix /issue/ trackers.
/Issues/ of interest
Priority /bugs/"

I would prefer two trackers: 
https://issues.guix.gnu.org/ for bugs and
httsp://patches.guix.gnu.org/ for patches.

* Is it intentionally that there still is a http site? I would have
expected a redirect onto https.

* http[s]://issues.guix.info/ is also still alive. Shouldn't it redirect
to http[s]://issues.guix.gnu.org/?

* If you search for something, you get away from the homepage and
tips are missing. There should be a "help/tooltip" button near the
search input that explains the query language.

* If you enter a query, that query should be kept in the input field.
Currently, it is discarded. That would make it more easy to update your
query.

* I would expect the home page to present the newest issues first, and
only open ones.

* It is not clear to me how long a closed issue is still visible on the
home-page. Is it still an "Issue of interest" if it is closed? 

* Sorting issues by columns would be cool.

* Mumi has no paging: It only presents one page of issues, but it
doesn't say how many are there in total nor does it page through all
other pages of issues.

* That means: If I search only for open issues, I get one page ranging
from 2013 until 2017, nothing newer:
https://issues.guix.gnu.org/search?query=is%3Aopen
This is unsatisfying.

* In that list, it is not clear what a red/orange colored bug-number
means: A tool-tip would be nice.

* As others mentioned, linking and explaining the tags (like easy)
is missing.

* A long desired feature is having general tags. It took me a very long
time until I realized that Debbugs allows user-tags. What about using a
common email address like "issues AT guix.gnu.org" and add user-tags
for that address, like "python", "core-updates", "release-1.1.x", etc.

* I still don't see that all bugs and patches from the mailing list are
part of the mumi issues list?

* The HTML could be responsive.

* The query syntax examples are only on the home page. Please repeat
them also on the help page.

* Either I don't understand the "date:.." semantics or it
is broken. The range yesterday..today lists no issues after 2015. Not
the "yesterday" I expected...:

https://issues.guix.gnu.org/search?query=date%3Ayesterday..today

With numbers, it gets even more strange:
https://issues.guix.gnu.org/search?query=date%3A2020-03-29..2020-03-30
--> Nothing found.

Some more, but why are these selected?:
https://issues.guix.gnu.org/search?query=date%3A2020-03-29..2020-03-30

* Mdate does not find anything?
https://issues.guix.gnu.org/search?query=mdate%3A2w..12h

Despite all the critics, thanks for caring and improving mumi.

Björn


pgpIapSnhW88Y.pgp
Description: OpenPGP digital signature

March update on data.guix.gnu.org (Guix Data Service)

[Christopher Baines]

Hey,

This follows on from the email I sent back in February [1].

1: https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00268.html

As it turns out, quite a lot has happened over the last month and a bit!
In summary, this email talks about:

 - Providing database dumps, and how this works
 - Loading new revisions should now be much faster
 - A performance issue with the links of the package reproducibility
   page has been fixed
 - Data about builds and substitutes is more up to date
 - The Guix Data Service now runs on Guile 3
 - System test derivations are now computed for multiple systems
 - You can view package history by "output" now, as well as version and
   derivation
 - I'm no longer the only person making code changes!

There's now a page [2] that lists dumps of the database, previously this
was just NGinx's representation of the /var/lib/guix-data-service/dumps
directory. Creating new dumps was a manual process, but there's now a
mcron job on the machine that takes care of this so new data should
appear daily.

2: http://data.guix.gnu.org/dumps/

The Hetzner server on which data.guix.gnu.org is hosted only has 150GB
of disk space for the database and store, with 73GB currently being
taken up by the database. This didn't leave any space to store dumps,
let alone generate the small dumps, which require restoring a copy of
the database so that it can be modified.

I added a 100GB volume to the server, which acts as temporary space for
the dumps to be stored, and the small dumps to be created. For actually
storing the dumps longer term, I'm using a combination of git-annex [3]
and a file storage service called Wasabi [4]. I didn't want to write
backup code that only worked with Wasabi, so the idea of using git-annex
as well is that it deals with the details of how to move the files
around. I picked Wasabi because the storage is quite cheep, and it
doesn't charge for serving the files. Like the server, currently I'm
paying for this.

3: https://git-annex.branchable.com/
4: https://wasabi.com/

This should mean that backups are regularly available, which is
convenient. Also, the small backup has been improved over the last
month, it's now small again (~10GB for 2020-03-13, to 0.7GB for
2020-03-28) and includes data for system tests and channel instances
now.

I didn't test if Guile 3 had any impact on performance, but there have
been some data loading performance improvements over the last month. The
channel instance locking was improved, so more can be done in
parallel. Building on some changes in Guix for the derivation linter,
the Guix Data Service now can pass a store connection in to be used,
which also makes loading new revisions a little faster. I also looking
in to the very slow loading of package metadata [5]. This could take ~30
minutes previously, but I've now seen it happen in as little as 3
seconds!

5: Look for "debug: Finished querying the temp_package_metadata" in the
job output

It's not performance of loading data for new revisions, but I looked in
to why the links on the package reproducibility page ([6] for example)
for a revision would time out. This turned out to be an easy fix, just
add a database index in the right place. While the lack of data about
builds is still a limiting factor, this page [6] should be a bit more
useful and usable.

6: 
http://data.guix.gnu.org/revision/8f83699ba00743d258b497e0e5285989996ee559/package-reproducibility

I also spent some time debugging why the script for querying build
servers would hang or break when run for long periods. I think this was
resolved with some tweaks to http-get-multiple [7], and now I've been
able to leave the script running. This should have two positive effects,
the build and narinfo information on data.guix.gnu.org should be more up
to date than it was previously. Secondly, because the Guix Data Service
is regularly querying to narinfo files, including for new derivations,
this'll prompt guix-publish to bake nar files for these outputs
hopefully soon after the output has been generated.

7: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39873

The Guix Data Service now works with Guile 3, and the Guix package has
been changed to use Guile 3.

System test derivations are now generated for multiple systems [8].

8: 
http://data.guix.gnu.org/revision/8b87d095b39dee91056b88f96b374faa8c3a8891/system-tests

Previously you could view the version, or derivation history for a
package on a branch, but now you can view the "output" history as well
[9]. This is in some ways more useful than the derivations history, as
there you get more entries due to changes in fixed output generations.

9: 
http://data.guix.gnu.org/repository/1/branch/master/package/libreoffice/output-history

I'm also now not the only one to have worked on the Guix Data Service
[10]. This is a positive sign for the "Improve internationalization
support for the Guix Data Service" Outreachy project. Providing there's
a successful applicant, I believe that'll b

Re: Use genimage for disk-image creation.

[Vagrant Cascadian]

On 2020-03-29, Danny Milosavljevic wrote:
> Hi Ludo,
>
> On Sun, 29 Mar 2020 16:44:39 +0200
> Ludovic Courtès  wrote:
>
>> Oh, really?  I’m surprised partitioning causes problems (though I’m
>> not familiar with embedded dev!).
>
> Well, maybe not that bad, but it's pretty bad.
>
> It's because the boot sector for ARM, for some unfathomable reason, is not
> the first sector but has basically a vendor-dependent sector number somewhere
> in the middle of the disk :P
>
> (with the "boot sector" I mean the sector(s) where usually u-boot resides)
>
> So there are all kinds of stupid problems like sometimes you have to reduce
> the size of the GPT partition table (TABLE!) because it would write right over
> the actual boot sector of the platform otherwise.  For that vendor.  Other
> vendors do other silly things.
>
> Parted doesn't really have support for that stuff either, and I while I
> brought it up with them[1], I can't think of a practical way to fix it
> (i.e. automatically keep clear of all possible boot ranges of all ARM
> vendors) or to even find the extent of the problem.  I think it should be
> the vendors' responsibility to standardize on one way to boot that doesn't
> suck :P
>
> It turns partitioning basically from straightforward allocation inside
> one block into allocation with strange hidden mines to avoid.
>
> Embedded usually ignores the problem, finds a partitioning that works
> (with dummy spacer partition if you are lucky--otherwise just random
> gap) and everyone just uses that one.  Sigh...

Someday... but not today. :/

The biggest offset I'm aware of is rockchip platforms, at what I think
is ~16MB:

  http://opensource.rock-chips.com/wiki_Partitions

sunxi/allwinner 64-bit platforms have offsets that conflict with a
standard GPT partition table, though there are rumours of it working
fine as long as you keep the number of partitions below four:

  https://bugs.debian.org/928643

32-bit sunxi/allwinner platforms are generally pretty reasonable, but I
don't recall the issues off the top of my head.

ti/omap/etc platforms tend to fit under 4MB.


I haven't really looked at buildroot at all... but I suspect buildroot
is just a collection of all these criteria applied on a board-by-board
basis, but most of these boards don't actually require specific
partition layout, per se, it's just nice to not clobber the raw offsets
of various parts of the boot process... but creating partitions for each
of those can make installation less error-prone in some cases.

I think the default for most partitioning tools these days is to create
the first partition starting at 2MB, but If the guix partition started
at 16MB and you limited partitions to under four partitions, that should
work for all the platforms I'm aware off of the top of my head... at
least for now...

I seem to also recall an that some disk media (emmc, microSD, maybe some
SSDs) have an erase block granularity of 4MB, and so it'd be ideal if
the first partition started at a multiple of 4MB:

$ lsblk -D

NAMEDISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
mmcblk004M 3.5G 0

Or alternately, detecting this size and making sure the first partition
starts as a multiple of this value.

I really need to sort some of these issues out in Debian as well, so
happy to carry on the conversation!


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Use genimage for disk-image creation.

[Mathieu Othacehe]

Hey!

> I’m completely sold to the idea.  :-)

I'm glad you like it!

> Looking at ‘image-ext2.c’ reveals that genimage actually just shells out
> to mke2fs.  Indeed, I discovered that ‘mke2fs -d /my/root’ copies
> /my/root as the image’s root directory.  Likewise, for ISO, it just
> shells out to ‘genisoimage’.
>
> So I think that we could avoid ‘genimage’ altogether and implement
> similar functionality for ext4/ISO in (gnu build disk-image).

Ok! One useful functionality of genimage seems to be that's its capable
of creating complex partitioning layouts. Of course we can re-implement
it in (gnu build disk-image), but I don't know how complex will it be.

Danny, I found the genimage files for each arm/aarch64 boards inside
Buildroot repository. They are a valuable source of information, but
regardless of the decision we take for (gnu build disk-image), we can
find a way to import them and store them as Guile records. 

I guess I'll start a small implementation to have a clearer view of this
topic.

Thank you all for the feedback,

Mathieu

Re: Mailing lists and debbugs currently not working

[Pierre Neidhardt]

Good news, Leo, your email went through :)

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


signature.asc
Description: PGP signature

Re: core-updates frozen!

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

>> The Core-updates bootstrap (code named "Scheme-only bootstrap") removes
>>
>>   Awk, Bash, the GNU Core Utilities, Grep, Gzip, Sed, and Tar.
>>
>> and replaces them with Gash and Gash-Utils!
>
> That’s worth a second blog post!  :-)

Yes, let's do that when core-updates is merged into master!  "someone"
is still struggling a bit with the documentation anyway.  ;-)

janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Mailing lists and debbugs currently not working

[Leo Famulari]

As reported on help-debbugs and the #guix IRC channel, the mailing lists
and debbugs are currently not working. I'm not sure if this message will
go through.

It seems to manifest as silent failure of mail delivery, and debbugs not
responding to commands.

There are a couple messages here about the problems people are
experiencing:

https://lists.gnu.org/archive/html/help-debbugs/2020-03/threads.html


signature.asc
Description: PGP signature

Re: Grafts, revisited

[Ludovic Courtès]

Hello Guix!

Ludovic Courtès  skribis:

> To address that, I think we need a better way to handle “dynamic
> dependencies”.  The ‘wip-build-accumulator’ branch does that by taking
> advantage of ‘with-build-handler’.  On that branch, grafts no longer use
> substitute info.  Instead, they just build missing store items and get
> their references.  To avoid building things one by one, we install a
> build handler that “accumulates” the list of ‘build-things’ requests;
> eventually, we build all these things at once and resume the
> continuations of the ‘build-things’ calls.  The goal here is to improve
> efficiency and to allow the UI to shows these stages in a meaningful
> way.  Here’s a sample session (slightly edited for clarity)

I went ahead and merged ‘wip-build-accumulator’ in master because it’s
better than the status quo.  This fixes this 3.5-year old bug:

  https://issues.guix.gnu.org/issue/22990

Woohoo!

If anything looks wrong or otherwise “weird”, please report a bug!
If you feel happier with this change, enjoy!  :-)

Ludo’.

Re: Grafting segfault

[Ludovic Courtès]

Hi!

Gábor Boskovits  skribis:

> Pulling from an older guix version yesterday, I have noticed that on
> system reconfigure the grafting sometimes failed with sigsegv.
>
> After several retries, segfaulting always on different packages, the
> system build finished successfully. I do not have a way to reliable
> trigger this problem. It is definitely indeterministic. As it happens
> in the build phase, it does not cause real problem when it is noticed,
> and retried. This is all the information I have on the issue so far.

This is sad, but I’ve reverted to Guile 2.0 for grafts in
033df23680cce1b3ccd9c83b97d8c200176cdb0a.

To anyone reading this: if you experience(d) it, please report as many
details as possible.  In particular, it would be great to have the name
of a derivation that more or less reproducibly crashes.

Thanks,
Ludo’.

Re: Use genimage for disk-image creation.

[Danny Milosavljevic]

Hi Ludo,

On Sun, 29 Mar 2020 16:44:39 +0200
Ludovic Courtès  wrote:

> Oh, really?  I’m surprised partitioning causes problems (though I’m
> not familiar with embedded dev!).

Well, maybe not that bad, but it's pretty bad.

It's because the boot sector for ARM, for some unfathomable reason, is not
the first sector but has basically a vendor-dependent sector number somewhere
in the middle of the disk :P

(with the "boot sector" I mean the sector(s) where usually u-boot resides)

So there are all kinds of stupid problems like sometimes you have to reduce
the size of the GPT partition table (TABLE!) because it would write right over
the actual boot sector of the platform otherwise.  For that vendor.  Other
vendors do other silly things.

Parted doesn't really have support for that stuff either, and I while I
brought it up with them[1], I can't think of a practical way to fix it
(i.e. automatically keep clear of all possible boot ranges of all ARM
vendors) or to even find the extent of the problem.  I think it should be
the vendors' responsibility to standardize on one way to boot that doesn't
suck :P

It turns partitioning basically from straightforward allocation inside
one block into allocation with strange hidden mines to avoid.

Embedded usually ignores the problem, finds a partitioning that works
(with dummy spacer partition if you are lucky--otherwise just random
gap) and everyone just uses that one.  Sigh...

(x86 kinda has standardized a gap at the beginning of the disk until the
second head (seems to be 2048 sectors with 512 Byte/sector nowadays
since the drive doesn't expose valid CHS information anymore), and put
the bootloader there--so that's a 1 MiB gap at the beginning of the
disk)

[1] 
https://alioth-lists.debian.net/pipermail/parted-devel/2017-December/005152.html


pgpE0x1TPzX8z.pgp
Description: OpenPGP digital signature

Re: Proxy settings wrt guix daemon

[Ludovic Courtès]

Hi Vincent,

Vincent Legoll  skribis:

> but as mentionned in [3], this will not fly in the
> case of an intermittently available proxy, as guix
> system-reconfigure will depends on this working
> properly to reset it back to no proxy usage.
>
> There is an issue about the problem [4], but it
> does not looks like it is making progress.
>
> Could something be done from shepherd PoV,
> like easily setting environment vars for specific
> services, in /etc/... config files ? So that can be
> easily modified with a simple text editor in case
> of failure.

In general, /etc on Guix System is meant to be immutable (with the
exception of “state” files like /etc/resolv.conf and /etc/passwd).

So my recommendation would be to fix [4] specifically for ‘guix-daemon’
by adding a ‘set-proxy’ action or something.

> [1] https://lists.gnu.org/archive/html/help-guix/2017-02/msg00090.html
> [2] https://lists.gnu.org/archive/html/help-guix/2019-07/msg00031.html
> [3] https://lists.gnu.org/archive/html/guix-devel/2017-10/msg00206.html
> [4] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25569
>
> Solving this would be awesome for the imminent
> release. I'd like to help as much as I can.

Yup.

Thanks,
Ludo’.

Re: core-updates frozen!

[Ludovic Courtès]

Hi!

Jan Nieuwenhuizen  skribis:

> For the record...it's even better: The GCC, binutils and glibc
> removal mentioned above is already in master; so our next release will
> bootstrap from ~135MB like blog post mentions!
>
> The Core-updates bootstrap (code named "Scheme-only bootstrap") removes
>
>   Awk, Bash, the GNU Core Utilities, Grep, Gzip, Sed, and Tar.
>
> and replaces them with Gash and Gash-Utils!

That’s worth a second blog post!  :-)

Ludo’.

How do I set GUIX_GITHUB_TOKEN correctly?

[sirgazil]

Hi,

I've been packaging software hosted on GitHub without problems for some days, 
but recently, running "guix lint -L . python-commonmark" (a package I'm 
defining on 
https://gitlab.com/sirgazil/guix-channel-x/-/blob/master/sirgazil-x/packages/python.scm#L67)
 failed and a message suggested to create a GitHub token. I created a token 
with all the "Repo" scopes selected, exported the GUIX_GITHUB_TOKEN variable, 
but now I'm getting the following error:

🙠🙢 🙠🙢 🙠🙢 🙠🙢  🙠🙢  🙠🙢  🙠🙢  🙠🙢  🙠🙢  🙠🙢  🙠🙢 
$ guix lint -L . python-commonmark
;;; note: source file ./sirgazil-x/packages/guile.scm
;;;   newer than compiled 
/gnu/store/0z6ccg5hxb64id7pj7ya833amixznwxq-sirgazil-x/lib/guile/3.0/site-ccache/sirgazil-x/packages/guile.go
;;; note: source file ./sirgazil-x/packages/python.scm
;;;   newer than compiled 
/gnu/store/0z6ccg5hxb64id7pj7ya833amixznwxq-sirgazil-x/lib/guile/3.0/site-ccache/sirgazil-x/packages/python.go
Backtrace:ython-commonmark@0.9.1 [refresh]...
   9 (primitive-load "/home/sirgazil/.config/guix/current/bi…")
In guix/ui.scm:
  1894:12  8 (run-guix-command _ . _)
In srfi/srfi-1.scm:
634:9  7 (for-each # …)
In guix/scripts/lint.scm:
 59:4  6 (run-checkers _ _)
In srfi/srfi-1.scm:
634:9  5 (for-each # …)
In guix/scripts/lint.scm:
66:17  4 (_ _)
In guix/lint.scm:
   1063:2  3 (check-for-updates #)
973:2  2 (call-with-networking-fail-safe _ _ _)
In ice-9/boot-9.scm:
  1736:10  1 (with-exception-handler _ _ #:unwind? _ # _)
  1669:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1669:16: In procedure raise-exception:
Error downloading release information through the GitHub
API when using a GitHub token
🙠🙢 🙠🙢 🙠🙢 🙠🙢  🙠🙢  🙠🙢  🙠🙢  🙠🙢  🙠🙢  🙠🙢  🙠🙢 

Then, I created another token with all scopes selected, 

$ export GUIX_GITHUB_TOKEN="new token"
$ guix lint -L . python-commonmark

and got the same error message.

I don't know what I'm missing...


---
https://sirgazil.bitbucket.io/

Re: Experiment in generating multi-layer Docker images with guix pack

[Ludovic Courtès]

Hi Chris,

Christopher Baines  skribis:

[...]

>> I think a layering algorithm like Graham Christensen’s above requires
>> knowledge of the reference graph, meaning that layering can only be
>> computed on the build side, using #:references-graphs.  In that case, it
>> could be that you can’t have a host-side  record.
>
> As I understand it, you only have to do the computation on the build
> side if you're restricted to doing a single set of builds. If you first
> build the store items you want to put in the image, then look at there
> references and compute the derivation for building the image, then you
> could do this kind of computation on the client side.
>
> But yeah, this is important to work out, as how image generation should
> work, and what behaviours we want should define the structure of the
> code.
>
> I went with records to represent layers partially because I'm familiar
> with it, but also because it allows for easier manipulation of layers on
> the client side. Representing different layers as different derivations
> also allows them to potentially be built in parallel, although I'm not
> sure how beneficial this might be.

That’s a good point, it could help.  We could also use a “dynamic
dependency” like for grafts so we can compute things on the host side
anyway (tempting, but we should probably not start using that
everywhere!).

> Related to this, at the moment Docker V1 images can be generated, it
> would be good in the future to also support Docker V2 images and OCI
> images. All three container formats use a layered approach to managing
> the files, but they are all different (as far as I'm aware).

Oh, I thought these formats were all the same.  I suppose it’d be enough
to support OCI, right?

> In my mind there are three architectural approaches:
>
>  - Image generation entirely on the build side
>
>- The layers and the image are constructed through one derivation
>- The code for building images is in a module available at build time
>- Different approaches for layering are implemented in the module
>  available at build time, and parameters are passed in as
>  data/gexpressions
>
>  - Image generation entirely on the client side
>
>- Each layer is a derivation, and the image is an additional
>  derivation that takes the layers as an input
>- The code for building images is inside gexp compilers for the
>  record types representing the images and layers
>- Different approaches for layering manipulate the layer records on
>  the client side
>
>  - Image generation can be done both build and client side
>
>- Depending on the parameters, the layers and image can be a single
>  derivation, or one for each layer, and another for the image
>- The code for building images is in a module available at build
>  time, and this is also used by gexp compilers
>- Different approaches for layering have the option of either being
>  on the build side, or the client side
>
> What are peoples thoughts?

>From a pragmatic standpoint, perhaps we can first integrate what you
propose (option #2), and later adjust the code towards #1 or #3 as we
see fit.

WDYT?

Thanks,
Ludo’.

Re: Cannot build guix from git due to .po file errors

[Ludovic Courtès]

Marius Bakke  skribis:

> Marius Bakke  writes:
>
>> Ludovic Courtès  writes:
>>
>>> Hi Vagrant,
>>>
>>> Vagrant Cascadian  skribis:
>>>
 e...@boldquot.po:4591: format specifications in 'msgstr[0]' are not a
 subset of those in 'msgid_plural'
 /gnu/store/p50cw1g05g566bkbr6ylcibqffhha8w4-profile/bin/msgfmt: found 1
 fatal error
>>>
>>> What’s the message on that line?
>>
>> The message is:
>>
>> msgstr[0] "The following ~*machine will be deployed:~%"
>>
>> ...from (guix scripts deploy).
>
> So this is the same issue as .
>
> I went ahead and applied the same workaround in
> 388b432cea4ae2bb9bf4b044026b7764ab002e1e.

I see, thanks!

Re: Use genimage for disk-image creation.

[Ludovic Courtès]

Hi,

Danny Milosavljevic  skribis:

> from the standpoint of ARM it would be really good to be able to reuse
> genimage config files from buildroot.

Well, we can have a parser.  :-)

>From an engineering viewpoint, it seems weird to add a C parser that
basically shells out to other tools when we could just invoke those
commands directly and hopefully get more control and better error
reporting.

> In fact, partition layout is a major pain in the ass to get right on ARM.
> If we want to support a large number of ARM platforms, that would
> mean the partitioning would be fixed and not user-modifyable anyway.

Oh, really?  I’m surprised partitioning causes problems (though I’m
not familiar with embedded dev!).

Ludo’.

Re: Potential for a race condition with latest-repository-commit

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Christopher Baines  skribis:
>
>> So one of the things that's currently restricted to doing by one job at
>> a time in the Guix Data Service is running latest-repository-commit from
>> the (guix git) module.
>>
>> Previously this was more of a problem for the Guix Data Service, as a
>> large section of the work for loading information about a revision was
>> serialised to avoid the potential for contention over the cached
>> checkout this procedure uses. There's still a lock used now, but I
>> realised when looking in to this further that it's only necessary to
>> lock around this specific call, not the larger section that was
>> restricted previously.
>>
>> I think that add-to-store which this procedure uses isn't atomic for a
>> directory, so there's a risk of weird results if the repository is
>> changed after the required revision is checked out. While it isn't
>> common to run guix pull twice, I think this could happen there if you
>> ran guix pull concurrently for the same repository, but two different
>> profiles. I added a sleep call just prior to the add-to-store call in
>> latest-repository-commit, and tested running guix pull twice at roughly
>> the same time, with different branches and profiles, and I did see both
>> profiles then reflecting a single branch, so one profile was mistakenly
>> referring to the wrong branch.
>
> Yes, we’ve also seen this problem with ‘static-web-site-service’¹,
> whereby if several instances would try to pull from, say,
> guix-artwork.git, we’d get non-deterministic results.  We worked around
> it by using different cache directories…
>
> ¹ 
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/modules/sysadmin/web.scm
>
>> Is this something that is worth guarding against? Maybe
>> latest-repository-commit could double check the Git repo state after
>> add-to-store completes, and raise an error if it's different to what it
>> expects. Or perhaps individual worktrees could be used for each process,
>> which would hopefully avoid the race condition entirely.
>
> It think it’d be worth guarding against it, yes.  What we could do is
> lock the cache directory, with something like ‘with-file-lock’.
>
> WDYT?

That sounds good to me :)


signature.asc
Description: PGP signature

Re: kmscon not working on MacBook

[pelzflorian (Florian Pelz)]

On Thu, Mar 26, 2020 at 05:53:11PM +0100, pelzflorian (Florian Pelz) wrote:
> On Thu, Mar 26, 2020 at 03:26:05AM +0100, Bengt Richter wrote:
> > Are you a member of the video group?
> 
> Indeed the issue was that the gdm user was not a member of the video
> group.  […]  I will push if nobody objects.

I pushed my change adding gdm to the video group in Guix.  I do not
think there is a downside.

Regards,
Florian

Grafting segfault

[Gábor Boskovits]

Hello Guix,

Pulling from an older guix version yesterday, I have noticed that on
system reconfigure the grafting sometimes failed with sigsegv.

After several retries, segfaulting always on different packages, the
system build finished successfully. I do not have a way to reliable
trigger this problem. It is definitely indeterministic. As it happens
in the build phase, it does not cause real problem when it is noticed,
and retried. This is all the information I have on the issue so far.

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