Package for OpenCV4

[Reza Alizadeh Majd]

Hi,

just started to prepare a packge for `qimgv` [1], but it has a
dependency to OpenCV-4, and current available version of OpenCV in Guix
repository is 3.4.3.

just wanted to know, if there is a plan to upgrade OpenCV to version 4?
since I had a try and it seems that OpenCV-4 needs more tasks than just
upgrading the version number.


[1]: https://github.com/easymodo/qimgv

-- 
Reza Alizadeh Majd
PantherX Team
https://www.pantherx.org/

Re: best practise between git-fetch vs url-fetch?

[Jack Hill]

On May 25, 2020 5:17:02 PM EDT, "Ludovic Courtès"  wrote:
>Hi,
>
>Jack Hill  skribis:
>
>> On Sun, 24 May 2020, Ludovic Courtès wrote:
>>
>> […]
>>
 Another improvement we could make here is improving the message
>about
 Software Heritage in guix lint. Most of the other messages it emits
 are things that the author of a package should consider improving.
>If
 the Software Heritage message is less actionable, let's make that
 clearer so that people don't think there is a problem with their
 package definition.
>>>
>>> What message would you suggest?
>>
>> How about expanding section 7.7 "Invoking Guix Lint" in the manual to
>> include a paragraph of advice in the explanation for each checker.
>For
>> example, the advice could be could be "change the source to use
>> git-fetch" for "source-unstable-tarball", "exercise judgment on the
>> long-term availability of software sources. We think that code hosted
>> on the GNU ftp servers will be around for a long time, but code on
>> people's personal websites may not be. The greater the risk of the
>> software disappearing, the more important is is to use git-fetch in
>> sources so we can trigger archiving at Software Heritage" for
>> "archival", and "double check whether these inputs really should be
>> native [link to appropriate section of the manual]. If they really
>> need to be, leave a comment in the code briefly explaining why to
>help
>> future contributors" for "inputs-should-be-native".
>
>Regarding the ‘archival’ checker, the manual explains what’s at stake
>and what it does:
>
>  https://guix.gnu.org/manual/en/html_node/Invoking-guix-lint.html
>
>I feel like there’s little room for improvement here.

I think you're right. We have made it this far without too much confusion, and 
I agree that the text in that section is good. Let's leave it alone.

Best,
Jack

Re: Should guix track package aliases?

[Josh Marshall]

For gadl, it was that the gal website hosting it went down.  With regards
to pre-commit hooks, just to make sure each commit message conforms to what
is expected and is best practice for PRs and commits for the project.

On Mon, May 25, 2020, 19:15 zimoun  wrote:

> Dear Josh,
>
> On Tue, 26 May 2020 at 00:31, Josh Marshall
>  wrote:
>
> > I could fix up some of the new homepages.  We've already seen some Gnu
> related package losses like gdal.  I think SWH adoption for packages may
> want to be moved from as packages are added to as packages are updated --
> just to have a regular, low overhead, but still slow move to SWH.
>
> What do you mean by "losses like gdal"?
>
> BTW, if the method of package origin is 'git-fetch' then "guix lint"
> should automatically queue the package to SWH.  And I guess that the
> Data Service or CI is linting, whatever the package is added or
> updated.
> The file 'sources.json' is updated every X minutes (or hours) and the
> SWH fetcher should be ready really soon.  And once this 'url-fetch'
> from SWH is on production, a lot of packages will move to SWH.
>
>
> Well, considering SWH, what is missing today IMHO on the Guix side is
> UI, e.g., display using "guix weather" if the package is in SWH or
> not, display a chart on the Data Service to represent which percentage
> is in SWH, maybe move the {package,source}-json-builder from the
> website engine to "guix publish", etc..  Help welcome. :-)
>
>
> All the best,
> simon
>

Re: Should guix track package aliases?

[zimoun]

Dear Josh,

On Tue, 26 May 2020 at 00:31, Josh Marshall
 wrote:

> I could fix up some of the new homepages.  We've already seen some Gnu 
> related package losses like gdal.  I think SWH adoption for packages may want 
> to be moved from as packages are added to as packages are updated -- just to 
> have a regular, low overhead, but still slow move to SWH.

What do you mean by "losses like gdal"?

BTW, if the method of package origin is 'git-fetch' then "guix lint"
should automatically queue the package to SWH.  And I guess that the
Data Service or CI is linting, whatever the package is added or
updated.
The file 'sources.json' is updated every X minutes (or hours) and the
SWH fetcher should be ready really soon.  And once this 'url-fetch'
from SWH is on production, a lot of packages will move to SWH.


Well, considering SWH, what is missing today IMHO on the Guix side is
UI, e.g., display using "guix weather" if the package is in SWH or
not, display a chart on the Data Service to represent which percentage
is in SWH, maybe move the {package,source}-json-builder from the
website engine to "guix publish", etc..  Help welcome. :-)


All the best,
simon

Re: Jami bug investigation #2

[Jan]

Okay, so I fixed the patching problem using "--ignore-whitespace".


Jan Wielkiewicz

Re: Should guix track package aliases?

[Josh Marshall]

I could fix up some of the new homepages.  We've already seen some Gnu
related package losses like gdal.  I think SWH adoption for packages may
want to be moved from as packages are added to as packages are updated --
just to have a regular, low overhead, but still slow move to SWH.

On Mon, May 25, 2020, 17:57 Vincent Legoll  wrote:

> Hello,
>
> On 25/05/2020 16:20, Josh Marshall wrote:
> > Checking out repology.org/repository/gnuguix
> >  , it got picked up and guix
> > looks like it is in much better shape.
>
> Yay, but we're still far from the front page's top repositories...
>
> But, to celebrate our come back into the fray, I've grabbed a few low
> hanging fruits from the outdated and/or potentially vulnerable list.
>
> Series incoming (on guix-patches, issue #41533)...
>
> --
> Vincent Legoll
>

Re: Providing a Guix System images catalog.

[Ludovic Courtès]

Hi,

Jan Nieuwenhuizen  skribis:

> Mathieu Othacehe writes:
>
> Hello Mathieu,
>
>> To build a Guix System image, one needs to pick an operating system file
>> and call "guix system disk-image my-os.scm" to get an image.
>>
>> While this works fine on desktop, this is more tricky for the embedded
>> devices. Which operating system to select in "examples" folder? What's
>> the difference between --system and --target, which one should I use?
>>
>> This attached, wip patch, allows to run (on wip-hurd-vm branch):
>>
>> guix system image hurd-disk-image
>>
>> instead of:
>>
>> guix system disk-image --target=i586-pc-gnu  
>> gnu/system/examples/bare-hurd.tmpl
>
> That's pretty nice!

+1!

> I wonder about how this composes; if I'd want to add say a guix-daemon
> service to the bare-hurd, how would I do that?

How about leaving the ‘operating-system’ field of  to #f or some
default value, and then filling it in with the argument passed to ‘guix
system’?

Or better: at the API level, we’d look for an “image constructor” (or
“image type”), not an image, where an image constructor is a procedure
that takes an  and returns an .  In practice,
you’d wrap that in  with a ‘name’ field so you can still
look them up by name.

Thoughts?

Ludo’.

Re: Updating the “pre-push” Git hook

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

> Ludovic Courtès  writes:
>
>> Could you try:
>>
>>   mv ~/.cache/guix/authentication/channels/guix{,.bak}
>>   time make authenticate
>>   mv ~/.cache/guix/authentication/channels/guix{.bak,}
>>
>> ?
>
> real  0m49.496s
> user  0m43.733s
> sys   0m1.658s

Same timing if you run:

  make guix/{git,openpgp}.go

beforehand?

I get 29s for 16865 commits.

> And then running it again:
>
> $ [env] time make authenticate
> Authenticating Git checkout...
> Authenticating d68de95 to fb1675e (0 commits)...
>
> real  0m2.692s
> user  0m2.877s
> sys   0m0.128s

Oh I see that too.  Roughly half of the time seems to be spent loading
the keyring from the ‘keyring’ branch, and the other half is traversing
the commit graph:

--8<---cut here---start->8---
$ ./pre-inst-env  guile --no-auto-compile -e git-authenticate 
./build-aux/git-authenticate.scm d68de958b60426798ed62797ff7c96c327a672ac $(git 
rev-parse HEAD)
Authenticating d68de95 to a1a3bd5 (0 commits)...
% cumulative   self 
time   seconds seconds  procedure
 37.04  0.73  0.73  anon #x4a44d0
 12.96  0.25  0.25  anon #x49e788
 11.11  0.22  0.22  guix/openpgp.scm:1030:0:crc24
  6.48  0.16  0.13  anon #x4a2810
  4.63  0.09  0.09  ice-9/popen.scm:145:0:reap-pipes
  3.70  0.07  0.07  ice-9/vlist.scm:539:0:vhash-assq
  3.70  0.07  0.07  anon #x497578
  2.78  0.05  0.05  anon #x4a52c0
  2.78  0.05  0.05  anon #x4a27e0
  2.78  0.05  0.05  anon #x49d9e0
  1.85  0.05  0.04  anon #x4a5494
  1.85  0.05  0.04  anon #x497190
  0.93  0.62  0.02  guix/openpgp.scm:1056:0:read-radix-64
  0.93  0.33  0.02  gcrypt/base64.scm:154:2:base64-decode
  0.93  0.04  0.02  anon #x4a2878
  0.93  0.02  0.02  anon #x4a2840
  0.93  0.02  0.02  anon #x49f928
  0.93  0.02  0.02  git/commit.scm:213:0:commit-parents
  0.93  0.02  0.02  anon #x4a1ab8
  0.93  0.02  0.02  anon #x4975a8
  0.93  0.02  0.02  anon #x5f6210
  0.00  1.96  0.00  
/home/ludo/src/guix/build-aux/git-authenticate.scm:430:3
  0.00  1.15  0.00  guix/git.scm:387:0:commit-closure
  0.00  1.15  0.00  guix/git.scm:401:0:commit-difference
  0.00  1.05  0.00  srfi/srfi-1.scm:530:0:unfold
  0.00  0.96  0.00  git/commit.scm:198:4
  0.00  0.82  0.00  srfi/srfi-1.scm:452:2:fold
  0.00  0.82  0.00  
/home/ludo/src/guix/build-aux/git-authenticate.scm:356:0:authenticate-commits
  0.00  0.82  0.00  guix/progress.scm:65:0:call-with-progress-reporter
  0.00  0.73  0.00  git/commit.scm:197:14
  0.00  0.62  0.00  
/home/ludo/src/guix/build-aux/git-authenticate.scm:346:10
  0.00  0.20  0.00  guix/openpgp.scm:987:0:get-openpgp-keyring
  0.00  0.15  0.00  guix/openpgp.scm:610:0:get-signature
  0.00  0.11  0.00  ice-9/format.scm:39:0:format
  0.00  0.09  0.00  anon #x495690
  0.00  0.09  0.00  anon #x497d54
  0.00  0.09  0.00  git/types.scm:83:0
  0.00  0.07  0.00  guix/openpgp.scm:614:2:get-sig
  0.00  0.07  0.00  gcrypt/pk-crypto.scm:103:4
  0.00  0.05  0.00  ice-9/rdelim.scm:193:0:read-line
  0.00  0.05  0.00  guix/openpgp.scm:845:0:get-public-key
  0.00  0.05  0.00  ice-9/format.scm:759:2:format:out-obj-padded
  0.00  0.05  0.00  ice-9/format.scm:113:2:format:format-work
  0.00  0.04  0.00  guix/sets.scm:84:0:set-insert
  0.00  0.02  0.00  git/types.scm:106:0:make-double-pointer
  0.00  0.02  0.00  ice-9/ports.scm:545:0:call-with-output-string
---
Sample count: 108
Total time: 1.963880152 seconds (0.382282758 seconds in GC)
--8<---cut here---end--->8---

We can make that a bit faster by not loading the keyring when there’s
nothing to do, and by storing keys in binary format instead of
ASCII-armored, if needed.

Thanks,
Ludo’.

Re: Should guix track package aliases?

[Vincent Legoll]

Hello,

On 25/05/2020 16:20, Josh Marshall wrote:
Checking out repology.org/repository/gnuguix 
 , it got picked up and guix 
looks like it is in much better shape.


Yay, but we're still far from the front page's top repositories...

But, to celebrate our come back into the fray, I've grabbed a few low
hanging fruits from the outdated and/or potentially vulnerable list.

Series incoming (on guix-patches, issue #41533)...

--
Vincent Legoll

Re: Updating the “pre-push” Git hook

[Ludovic Courtès]

Hi!

Vagrant Cascadian  skribis:

> On 2020-05-24, Ludovic Courtès wrote:
>> Efraim Flashner  skribis:
>>> On Fri, May 22, 2020 at 10:44:48PM +0200, Ludovic Courtès wrote:
 Hello Guix!
 
 I think we should change our pre-push hook as shown below.
 
 Thoughts?
> ...
>>> (ins)efraim@E5400 ~$ type -P make
>>> (ins)efraim@E5400 ~$ command -v make
>>>
>>> I'd need to run 'guix environment --ad-hoc make -- git push'
>>
>> You’d need to run ‘git push’ from a full Guix development environment.
>> Do you think it could be a problem?
>
> Wait a minute... you're saying this is something that needs to be
> configured on each committer's machine(s)?
>
> Shouldn't it be on the server-side recieve hooks instead, otherwise
> someone might accidentally (or intentially) push commits not
> appropriately signed to the repository or validated by this check...
>
> Or is this an optional check for recommended for committers? Have I been
> missing something all along that I was supposed to be doing?

It should be a server-side check so we don’t shoot ourselves in the foot.

However, it’s not done yet (but hey, the code is not even a month old
:-)), so in the meantime, this hook will be very strongly recommended.

Making this a server-side hook on Savannah will be challenging since
“we” don’t have direct access to Savannah.  That makes me wonder if we
should have a push server say on berlin, and make Savannah mirror it or
something.

Help welcome!

> For my own workflow, I usually do not (yet) sign or push commits from a
> machine with guix installed... it's a bit awkward, admittedly, but I
> don't yet have any SSH or OpenPGP keys I trust guix with directly
> (ironically, "make authenticate" is working towards addressing exactly
> that trust issue).

Heh.  :-)

Thanks,
Ludo’.

Re: Updating the “pre-push” Git hook

[Ludovic Courtès]

Efraim Flashner  skribis:

> I'd probably run 'guix environment guix -- git push origin master' and
> view it as an additional safe guard to not push to the wrong branch or
> something, similar to how I view the password on the key. I bet there's
> an option to create a repo-specific alias in .git/config so that 'git
> push' will run inside 'guix environment guix'.

OK.

> I'm not convinced that my case is unique or that it should hold back the
> change. How does it work if 'make authenticate' fails?

‘git push’ fails, just like with the current pre-push hook.

Ludo’.

Re: Can we increase the print width/column in daemon backtraces

[Ludovic Courtès]

Hi,

Pierre Neidhardt  skribis:

> The COLUMN environment option (set in root's .bash_profile) does not
> extend the print width of backtraces when running `guix build`.

I understand, but which backtraces are we talking about?

COLUMNS only helps if you wish to debug ‘guix build’ itself.  It cannot
influence Guile processes launched by the daemon, such as those that
build derivations and the helper processes (‘guix substitute’, etc.).

In most cases, we’re interested in backtraces coming from Guile
processes that build derivations.  For that, we need to set COLUMNS in
the #:env-vars argument of ‘gexp->derivation’ or similar.

HTH!

Ludo’.

Re: “guix --help” should point to https://guix.gnu.org/help/

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Sun, 24 May 2020 at 23:10, Ludovic Courtès  wrote:
>
>> This is harsh, maybe unnecessarily so, but still a very valid criticism
>> of that page.  I guess that page was created with good intentions, but
>> it’s pretty much useless indeed.  :-/
>
> I am sorry if I have been harsh and if I have hurt someone.  I was
> *not* my intention.  Otherwise, I would not spend 5 minutes to follow
> all the links and check how to reach help for the GNU Guix project
> from this webpage. :-)

Yup, no problem; like I wrote, your time led to useful criticism.

Ludo’.

Re: MIPS support

[Ludovic Courtès]

Hi,

Efraim Flashner  skribis:

> Here's a first draft at removing mips64el-linux support from the
> documentation. I've left it as a supported system in (gnu ci), in (guix
> packages) and in the tests. I changed the text where we mention that we
> support mips64el-linux as an architecture, and elsewhere in the manual
> I've either removed mention of it when it was listed as a supported
> target or changed the references to aarch64.

The patch LGTM!

(gnu ci) refers to the cross-compilation target, which is fine, we can
keep it.

However, I think you can remove “mips64el-linux” from
‘%supported-systems’ in (guix packages), especially given the comment
above it, and you can adjust ‘%hydra-supported-systems’ accordingly.

Thanks,
Ludo’.

Re: best practise between git-fetch vs url-fetch?

[Ludovic Courtès]

Hi,

Jack Hill  skribis:

> On Sun, 24 May 2020, Ludovic Courtès wrote:
>
> […]
>
>>> Another improvement we could make here is improving the message about
>>> Software Heritage in guix lint. Most of the other messages it emits
>>> are things that the author of a package should consider improving. If
>>> the Software Heritage message is less actionable, let's make that
>>> clearer so that people don't think there is a problem with their
>>> package definition.
>>
>> What message would you suggest?
>
> How about expanding section 7.7 "Invoking Guix Lint" in the manual to
> include a paragraph of advice in the explanation for each checker. For
> example, the advice could be could be "change the source to use
> git-fetch" for "source-unstable-tarball", "exercise judgment on the
> long-term availability of software sources. We think that code hosted
> on the GNU ftp servers will be around for a long time, but code on
> people's personal websites may not be. The greater the risk of the
> software disappearing, the more important is is to use git-fetch in
> sources so we can trigger archiving at Software Heritage" for
> "archival", and "double check whether these inputs really should be
> native [link to appropriate section of the manual]. If they really
> need to be, leave a comment in the code briefly explaining why to help
> future contributors" for "inputs-should-be-native".

Regarding the ‘archival’ checker, the manual explains what’s at stake
and what it does:

  https://guix.gnu.org/manual/en/html_node/Invoking-guix-lint.html

I feel like there’s little room for improvement here.

Ludo’.

Re: Providing a Guix System images catalog.

[Jan Nieuwenhuizen]

Mathieu Othacehe writes:

Hello Mathieu,

> To build a Guix System image, one needs to pick an operating system file
> and call "guix system disk-image my-os.scm" to get an image.
>
> While this works fine on desktop, this is more tricky for the embedded
> devices. Which operating system to select in "examples" folder? What's
> the difference between --system and --target, which one should I use?
>
> This attached, wip patch, allows to run (on wip-hurd-vm branch):
>
> guix system image hurd-disk-image
>
> instead of:
>
> guix system disk-image --target=i586-pc-gnu  
> gnu/system/examples/bare-hurd.tmpl

That's pretty nice!  I wonder about how this composes; if I'd want to
add say a guix-daemon service to the bare-hurd, how would I do that?

What I also like about "gnu/system/examples/bare-hurd.tmpl" is that it's
easy to imagine where to make such a change.

Greetings,
Janneke

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

Re: Updating the “pre-push” Git hook

[Vagrant Cascadian]

On 2020-05-24, Ludovic Courtès wrote:
> Efraim Flashner  skribis:
>> On Fri, May 22, 2020 at 10:44:48PM +0200, Ludovic Courtès wrote:
>>> Hello Guix!
>>> 
>>> I think we should change our pre-push hook as shown below.
>>> 
>>> Thoughts?
...
>> (ins)efraim@E5400 ~$ type -P make
>> (ins)efraim@E5400 ~$ command -v make
>>
>> I'd need to run 'guix environment --ad-hoc make -- git push'
>
> You’d need to run ‘git push’ from a full Guix development environment.
> Do you think it could be a problem?

Wait a minute... you're saying this is something that needs to be
configured on each committer's machine(s)?

Shouldn't it be on the server-side recieve hooks instead, otherwise
someone might accidentally (or intentially) push commits not
appropriately signed to the repository or validated by this check...

Or is this an optional check for recommended for committers? Have I been
missing something all along that I was supposed to be doing?

For my own workflow, I usually do not (yet) sign or push commits from a
machine with guix installed... it's a bit awkward, admittedly, but I
don't yet have any SSH or OpenPGP keys I trust guix with directly
(ironically, "make authenticate" is working towards addressing exactly
that trust issue).


live well,
  vagrant


signature.asc
Description: PGP signature

Re: [OUTREACHY]: Integration of desktop environments into GNU Guix

[Danny Milosavljevic]

Also, gnome-photos doesn't set PYTHONPATH, so it won't be able to use pygobject,
right?

Pushed both gnome-music and gnome-photos to wip-desktop regardless.


pgpPafT_gCICy.pgp
Description: OpenPGP digital signature

Re: [OUTREACHY]: Integration of desktop environments into GNU Guix

[Danny Milosavljevic]

Pushed all those to wip-desktop branch.


pgpsopO9SnwLe.pgp
Description: OpenPGP digital signature

Re: [OUTREACHY]: Integration of desktop environments into GNU Guix

[Danny Milosavljevic]

Hi Raghav,

in malcontent, please don't do 

+ (substitute* "libmalcontent/tests/app-filter.c"
+   (((string-append "g_test_add_func \\(\"/app-filter/appinfo\","
+" test_app_filter_appinfo\\);")) ""))

Rather do it without string-append.  If the line is too long, that's too bad, 
just have it too long instead of that crazy opaque stuff.

Also, don't stick the "" back there--better in a new line.

I've pushed it to wip-desktop with those changes.

If there are multiple licenses in a package, please elaborate which parts are
under which licenses and whether it's the user that can choose one of those
licenses or whether all of them apply.


pgp73HfKHmBAm.pgp
Description: OpenPGP digital signature

Re: Heads-up: hard reset of the 'staging' branch

[Marius Bakke]

Marius Bakke  writes:

> I have pushed a 'staging2' branch where I did the following:
>
>  1) git rebase -i --rebase-merges 8229ce3116c1f522c7157ab2dcd50dc2d765686a~
>
>  2) Moved 8229ce3116c1f522c7157ab2dcd50dc2d765686a after
> f00270d35a6ca814903a9392caedc29d44959088 (the first merge that includes
> .guix-authorizations) -- it was "one step down" in Magits interactive
> rebase menu.
>
>  3) "solved" three merge conflicts (actually git rerere remembered the
> resolutions, and I could have used git rebase --rerere-autoupdate to
> make the process entirely automatic).
>
> I intend to move the current 'staging' branch to 'staging-old', and
> rename 'staging2' to 'staging' once I'm fully confident in the result
> and resolution.

Of course I sent this before actually testing the branch!  'git rerere'
had forgotten a very important merge resolution from
354880e7209a2aec0360dfe5b08b1873c084e2dd: the "tzdata-for-tests" package
needs to be kept on version 2019c during that merge to prevent a
full rebuild via "python".

I will do a new rebase tomorrow and make sure each of the merges are
correct.

Meanwhile, do not pull 'staging2' unless you are freezing and the 
computer is your main heat source.


signature.asc
Description: PGP signature

Heads-up: hard reset of the 'staging' branch

[Marius Bakke]

Guix,

I have good news and bad news.  The good news is that the new commit
verification infrastructure works great.  'make authenticate' will
verify that all commits were signed by a key that was authorized by
.guix-authorizations at that point in time.

The bad news is that we need to ensure .guix-authorizations has been
updated on any branches that new committers/keys will be pushing to.
Currently the 'staging' branch has one commit
(8229ce3116c1f522c7157ab2dcd50dc2d765686a) signed by a
not-yet-authorized key (it had been authorized on 'master' by
d074f73aacc5a39aed0202d6e45721f53f34a8c0, but that was not yet merged to
'staging' at the time).

To fix it properly without leaving a gap where 'make authenticate' will
fail, we actually need to rewrite the history.  Luckily git supports
rebasing merges(!), and the merge we need was the next commit on that
branch.

I have pushed a 'staging2' branch where I did the following:

 1) git rebase -i --rebase-merges 8229ce3116c1f522c7157ab2dcd50dc2d765686a~

 2) Moved 8229ce3116c1f522c7157ab2dcd50dc2d765686a after
f00270d35a6ca814903a9392caedc29d44959088 (the first merge that includes
.guix-authorizations) -- it was "one step down" in Magits interactive
rebase menu.

 3) "solved" three merge conflicts (actually git rerere remembered the
resolutions, and I could have used git rebase --rerere-autoupdate to
make the process entirely automatic).

I intend to move the current 'staging' branch to 'staging-old', and
rename 'staging2' to 'staging' once I'm fully confident in the result
and resolution.

In the mean time, comments or replications of the experiment welcome.

In other good news, the new pre-push hook proposed by Ludovic in

will eliminate this issue as long as people remember to activate it.
For total confidence we should perform it on the server side though.

Sorry for the inconvenience!


signature.asc
Description: PGP signature

Re: Can we increase the print width/column in daemon backtraces

[Marius Bakke]

Pierre Neidhardt  writes:

> Ludovic Courtès  writes:
>
>> Users are not supposed to see backtraces coming from the daemon or its
>> helpers (‘guix substitute’, ‘guix offload’, etc.).
>
> How are we supposed to debug Guix daemon errors?

You can run it directly from a shell, and/or attach a debugger.

I agree that if a failure happens on the daemon level, Guix should print
an actionable error message instead of a confusing back trace.


signature.asc
Description: PGP signature

Providing a Guix System images catalog.

[Mathieu Othacehe]

Hello,

To build a Guix System image, one needs to pick an operating system file
and call "guix system disk-image my-os.scm" to get an image.

While this works fine on desktop, this is more tricky for the embedded
devices. Which operating system to select in "examples" folder? What's
the difference between --system and --target, which one should I use?

My idea is to provide a catalog of images, that we would maintain (at
least adding them to the CI). The image definition would select a
default operating-system, an image type and a system/target to
build/cross-build the image.

This attached, wip patch, allows to run (on wip-hurd-vm branch):

--8<---cut here---start->8---
guix system image hurd-disk-image
--8<---cut here---end--->8---

instead of:

--8<---cut here---start->8---
guix system disk-image --target=i586-pc-gnu  gnu/system/examples/bare-hurd.tmpl
--8<---cut here---end--->8---

and

--8<---cut here---start->8---
guix system --list-images
--8<---cut here---end--->8---

that for now reports:

--8<---cut here---start->8---
The available images are:

  - hurd-disk-image
--8<---cut here---end--->8---

We could extend it to other boards that we've been hacking on
(beaglebone-black, pinebook-pro ...).

Please tell me what do you think!

Thanks,

Mathieu
>From 0eefcc0bef8fb950611ec5801a9f4d2e256b6b59 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe 
Date: Mon, 25 May 2020 17:18:23 +0200
Subject: [PATCH] wip: system: Add "--image " support.

This allows to run:

guix system --list-images

to get a list of available system images, and

guix system --image hurd-system-image

to build one of them.
---
 gnu/image.scm  |  9 +
 gnu/local.mk   |  2 ++
 gnu/system/image.scm   | 59 
 gnu/system/images/hurd.scm | 70 ++
 guix/scripts/system.scm| 56 +-
 5 files changed, 166 insertions(+), 30 deletions(-)
 create mode 100644 gnu/system/images/hurd.scm

diff --git a/gnu/image.scm b/gnu/image.scm
index 3a02692950..3a0b8d858b 100644
--- a/gnu/image.scm
+++ b/gnu/image.scm
@@ -30,8 +30,11 @@
 partition-initializer
 
 image
+image?
 image-name
 image-format
+image-system
+image-target
 image-size
 image-operating-system
 image-partitions
@@ -63,7 +66,13 @@
 (define-record-type* 
   image make-image
   image?
+  (name   image-name ;symbol
+  (default #f))
   (format image-format) ;symbol
+  (system image-system
+  (default #f))
+  (target image-target
+  (default #f))
   (size   image-size  ;size in bytes as integer
   (default 'guess))
   (operating-system   image-operating-system  ;
diff --git a/gnu/local.mk b/gnu/local.mk
index ad740ade82..b72ebede7f 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -627,6 +627,8 @@ GNU_SYSTEM_MODULES =\
   %D%/system/uuid.scm\
   %D%/system/vm.scm\
 		\
+  %D%/system/images/hurd.scm			\
+		\
   %D%/machine.scm\
   %D%/machine/digital-ocean.scm			\
   %D%/machine/ssh.scm\
diff --git a/gnu/system/image.scm b/gnu/system/image.scm
index 328dfe9d2f..0b1708747a 100644
--- a/gnu/system/image.scm
+++ b/gnu/system/image.scm
@@ -17,6 +17,7 @@
 ;;; along with GNU Guix.  If not, see .
 
 (define-module (gnu system image)
+  #:use-module (guix discovery)
   #:use-module (guix gexp)
   #:use-module (guix modules)
   #:use-module (guix monads)
@@ -52,15 +53,20 @@
   #:use-module (srfi srfi-35)
   #:use-module (rnrs bytevectors)
   #:use-module (ice-9 match)
-  #:export (esp-partition
+  #:export (root-offset
+root-label
+
+esp-partition
 root-partition
 
-hurd-disk-image
 efi-disk-image
 iso9660-image
 
+system-image
+
 find-image
-system-image))
+%images
+lookup-image-by-name))
 

 ;;;
@@ -89,18 +95,6 @@
(flags '(boot))
(initializer (gexp initialize-root-partition
 
-(define hurd-disk-image
-  (image
-   (format 'disk-image)
-   (partitions
-(list (partition
-   (size 'guess)
-   (offset root-offset)
-   (label root-label)
-   (file-system "ext2")
-   (flags '(boot))
-   (initializer (gexp initialize-root-partition)))
-
 (define efi-disk-image
   (image
(format 'disk-image)
@@ -556,6 +550,11 @@ image, depending on IMAGE format."
  

[PATCH] Begin tuning db-get-builds for performance

[Christopher Baines]

Now that I actually have some experience using SQLite from writing the Guix
Build Coordinator, I can actually see potential ways to improve bits of
Cuirass.

The intention here is to start to address the performance of db-get-builds,
which I think can be quite slow.

This commit does several things, the big change is to try and construct a
simpler query for SQLite. I'm not confident that SQLite's query planner can
look past handling the NULL parameters, so I think it could be helpful to try
and create a simpler query, both to avoid that problem if it exists, but also
move the complexity in to Guile code, which I think is a bit more manageable.

The way ordering is handled is also changed. Order is one of the filters,
although it's not a filter, and some of the other filters also influenced the
order. I think there are things still to fix/improve with the handling of
ordering, but at least this commit just has the ordering happen once in the
query.

If this direction sounds OK, I think the next things to do is do a bit more
testing, both to check uses of this query still work as intended, but also to
take those specific queries generated by db-get-builds, and check what SQLite
says when running them with EXPLAIN QUERY PLAN, as that should inform further
improvements, and what indexes to create.
---
 src/cuirass/database.scm | 138 +++
 1 file changed, 81 insertions(+), 57 deletions(-)

diff --git a/src/cuirass/database.scm b/src/cuirass/database.scm
index f80585e..cf2008d 100644
--- a/src/cuirass/database.scm
+++ b/src/cuirass/database.scm
@@ -612,19 +612,6 @@ WHERE derivation =" derivation ";"))
(cons `(,name . ((#:path . ,path)))
  outputs)))
 
-(define (filters->order filters)
-  (match (assq 'order filters)
-(('order . 'build-id) "rowid ASC")
-(('order . 'decreasing-build-id) "rowid DESC")
-(('order . 'finish-time) "stoptime DESC")
-(('order . 'finish-time+build-id) "stoptime DESC, rowid DESC")
-(('order . 'start-time) "starttime DESC")
-(('order . 'submission-time) "timestamp DESC")
-;; With this order, builds in 'running' state (-1) appear
-;; before those in 'scheduled' state (-2).
-(('order . 'status+submission-time) "status DESC, timestamp DESC")
-(_ "rowid DESC")))
-
 (define (query->bind-arguments query-string)
   "Return a list of keys to query strings by parsing QUERY-STRING."
   (define status-values
@@ -729,57 +716,94 @@ ORDER BY rowid DESC;"))
   "Retrieve all builds in the database which are matched by given FILTERS.
 FILTERS is an assoc list whose possible keys are 'derivation | 'id | 'jobset |
 'job | 'system | 'nr | 'order | 'status | 'evaluation."
+
+  (define (filters->order filters)
+(match (assq 'order filters)
+  (('order . 'build-id) "Builds.id ASC")
+  (('order . 'decreasing-build-id) "Builds.id DESC")
+  (('order . 'finish-time) "stoptime DESC")
+  (('order . 'finish-time+build-id) "stoptime DESC, Builds.id DESC")
+  (('order . 'start-time) "starttime DESC")
+  (('order . 'submission-time) "timestamp DESC")
+  ;; With this order, builds in 'running' state (-1) appear
+  ;; before those in 'scheduled' state (-2).
+  (('order . 'status+submission-time)
+   "status DESC, timestamp DESC, Builds.id ASC")
+  (_ "Builds.id DESC")))
+
+  (define (where-conditions filters)
+(define filter-name->sql
+  `((id  . "Builds.id = :id")
+(jobset  . "Specifications.name = :jobset")
+(derivation  . "Builds.derivation = :derivation")
+(job . "Builds.job_name = :job")
+(system  . "Builds.system = :system")
+(evaluation  . "Builds.evaluation = :evaluation")
+(status  . ,(match (assq-ref filters 'status)
+  (#f #f)
+  ('done  "Builds.status >= 0")
+  ('pending   "Builds.status < 0")
+  ('succeeded "Builds.status = 0")
+  ('failed"Builds.status > 0")))
+(border-low-time  . "Builds.stoptime > :borderlowtime")
+(border-high-time . "Builds.stoptime < :borderhightime")
+(border-low-id. "Builds.id > :borderlowid")
+(border-high-id   . "Builds.id < :borderhighid")))
+
+(filter
+ string?
+ (fold
+  (lambda (filter-name where-condition-parts)
+(if (assq-ref filters filter-name)
+(cons (assq-ref filter-name->sql filter-name)
+  where-condition-parts)
+where-condition-parts))
+  '()
+  (map car filters
+
   (with-db-worker-thread db
 (let* ((order (filters->order filters))
-   (stmt-text (format #f "SELECT * FROM (
+   (where (match (where-conditions filters)
+(() "")
+((condition)
+ (string-append 

Re: Should guix track package aliases?

[Josh Marshall]

Checking out repology.org/repository/gnuguix , it got picked up and guix
looks like it is in much better shape.

On Mon, May 25, 2020, 08:04 Nicolò Balzarotti  wrote:

>
> Hello everybody,
> It has been fixed today
> https://issues.guix.gnu.org/issue/37207
>
> Repology data is now updated
>
> Nicolò
>
> Josh Marshall  writes:
>
> > Hi Zimoun,
> >
> > The HTTP headers of the page indicate that the file hasn't changed since
> > 1970.  This is a bug.  That incorrect date breaks repology.org trying to
> > track guix packages.
> >
> > On Mon, May 25, 2020, 06:42 zimoun  wrote:
> >
> >> Dear Josh,
> >>
> >> On Sun, 24 May 2020 at 21:26, Josh Marshall
> >>  wrote:
> >> >
> >> > Checking http://guix.gnu.org/packages.json again, it seems like the
> >> > server changes to not misrepresent dates have not been applied yet.
> >> > Can someone get in and do that?
> >>
> >> I am not sure to understand what you mean and what you are asking for.
> >>
> >> Well, http://guix.gnu.org/packages.json is generated every X minutes
> >> (or hour) by [1].
> >>
> >> [1]
> >>
> http://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/apps/packages/builder.scm#n128
> >>
> >> HTH,
> >> simon
> >>
>

Re: [PATCH] cuirass: Perform some database "optimization" at startup.

[Christopher Baines]

Danny Milosavljevic  writes:

> the docs at https://www.sqlite.org/pragma.html#pragma_optimize suggest to run
> "PRAGMA optimize" at the end of the connection, or periodically--not at the
> beginning.
>
> That makes sense since it has to be able to see which queries are emitted
> in order to know what to optimize.
>
> Also, docs say:
>
>> The query planner used sqlite_stat1-style statistics for one or more indexes
>> of the table at some point during the lifetime of the current connection.
>
> That probably means one would have had to run ANALYZE at some point in the 
> past.

Thanks Danny, this is interesting.

From my reading of the docs, I think the only thing the optimize pragma
is going to do is run ANALYZE on some tables. There's something about
the current connection referenced in "Determination Of When To Run
Analyze", but it's not the only thing that triggers this.

There is some stuff mentioned about recent queries, but it seems to be
prefixed with "(Not yet implemented)".

I'm not sure where this would fit in the Cuirass code when connections
are closed, as I'm not sure where the connections are closed! In terms
of running this regularly, I'm up for trying to work that in, maybe it
could happen after new data has been added, or something like that.

Although I don't have any evidence to support this, I'm hoping running
the optimize pragma at startup will help in some cases, like when
migrations add new indexes, as I think the docs say SQLite will analyze
a table if an index hasn't been analyzed yet.

> Replaying the WAL sounds like a good idea at the beginning, though.  Most
> journalling filesystems do that too.

Cool :)


signature.asc
Description: PGP signature

Re: Should guix track package aliases?

[Nicolò Balzarotti]

Hello everybody,
It has been fixed today
https://issues.guix.gnu.org/issue/37207

Repology data is now updated

Nicolò

Josh Marshall  writes:

> Hi Zimoun,
>
> The HTTP headers of the page indicate that the file hasn't changed since
> 1970.  This is a bug.  That incorrect date breaks repology.org trying to
> track guix packages.
>
> On Mon, May 25, 2020, 06:42 zimoun  wrote:
>
>> Dear Josh,
>>
>> On Sun, 24 May 2020 at 21:26, Josh Marshall
>>  wrote:
>> >
>> > Checking http://guix.gnu.org/packages.json again, it seems like the
>> > server changes to not misrepresent dates have not been applied yet.
>> > Can someone get in and do that?
>>
>> I am not sure to understand what you mean and what you are asking for.
>>
>> Well, http://guix.gnu.org/packages.json is generated every X minutes
>> (or hour) by [1].
>>
>> [1]
>> http://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/apps/packages/builder.scm#n128
>>
>> HTH,
>> simon
>>

Re: Should guix track package aliases?

[Josh Marshall]

Hi Zimoun,

The HTTP headers of the page indicate that the file hasn't changed since
1970.  This is a bug.  That incorrect date breaks repology.org trying to
track guix packages.

On Mon, May 25, 2020, 06:42 zimoun  wrote:

> Dear Josh,
>
> On Sun, 24 May 2020 at 21:26, Josh Marshall
>  wrote:
> >
> > Checking http://guix.gnu.org/packages.json again, it seems like the
> > server changes to not misrepresent dates have not been applied yet.
> > Can someone get in and do that?
>
> I am not sure to understand what you mean and what you are asking for.
>
> Well, http://guix.gnu.org/packages.json is generated every X minutes
> (or hour) by [1].
>
> [1]
> http://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/apps/packages/builder.scm#n128
>
> HTH,
> simon
>

Re: Can we increase the print width/column in daemon backtraces

[Pierre Neidhardt]

Ludovic Courtès  writes:

> Users are not supposed to see backtraces coming from the daemon or its
> helpers (‘guix substitute’, ‘guix offload’, etc.).

How are we supposed to debug Guix daemon errors?

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


signature.asc
Description: PGP signature

Re: Can we increase the print width/column in daemon backtraces

[Pierre Neidhardt]

Tobias Geerinckx-Rice  writes:

> Nor should it[0].  What you describe sounds like a convenient bug 
> being fixed(?).  Was this on Guix System or a foreign 
> distribution?

Guix System.

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


signature.asc
Description: PGP signature

Re: [PATCH] cuirass: Perform some database "optimization" at startup.

[Danny Milosavljevic]

Hi Chris,

the docs at https://www.sqlite.org/pragma.html#pragma_optimize suggest to run
"PRAGMA optimize" at the end of the connection, or periodically--not at the
beginning.

That makes sense since it has to be able to see which queries are emitted
in order to know what to optimize.

Also, docs say:

> The query planner used sqlite_stat1-style statistics for one or more indexes
> of the table at some point during the lifetime of the current connection. 

That probably means one would have had to run ANALYZE at some point in the past.


Replaying the WAL sounds like a good idea at the beginning, though.  Most
journalling filesystems do that too.



pgp1BoslHFePM.pgp
Description: OpenPGP digital signature

Re: Should guix track package aliases?

[zimoun]

Dear Josh,

On Sun, 24 May 2020 at 21:26, Josh Marshall
 wrote:
>
> Checking http://guix.gnu.org/packages.json again, it seems like the
> server changes to not misrepresent dates have not been applied yet.
> Can someone get in and do that?

I am not sure to understand what you mean and what you are asking for.

Well, http://guix.gnu.org/packages.json is generated every X minutes
(or hour) by [1].

[1] 
http://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/apps/packages/builder.scm#n128

HTH,
simon

[PATCH] cuirass: Perform some database "optimization" at startup.

[Christopher Baines]

Add a "optimize" step that occurs when starting up the main Curiass
process. Currently this does two things, but could be extended to do more.

The "PRAGMA optimize;" command prompts SQLite to ANALYZE tables where that
might help. The "PRAGMA wal_checkpoint(TRUNCATE);" command has SQLite process
any unprocessed changes from the WAL file, then truncate it to 0 bytes. I've
got no data to suggest this helps with performance, but I'm hoping that going
from a large WAL file to a small one occasionally might be useful.

* src/cuirass/database.scm (db-optimize): New procedure.
* bin/cuirass.in (main): Run it.
---
 bin/cuirass.in   | 4 
 src/cuirass/database.scm | 8 
 2 files changed, 12 insertions(+)

diff --git a/bin/cuirass.in b/bin/cuirass.in
index fbc7c3c..7a2d5ae 100644
--- a/bin/cuirass.in
+++ b/bin/cuirass.in
@@ -124,6 +124,10 @@ exec ${GUILE:-@GUILE@} --no-auto-compile -e main -s "$0" 
"$@"
  (min (current-processor-count) 4
   (prepare-git)
 
+  (unless (option-ref opts 'web #f)
+(log-message "performing database optimizations")
+(db-optimize))
+
   (log-message "running Fibers on ~a kernel threads" threads)
   (run-fibers
(lambda ()
diff --git a/src/cuirass/database.scm b/src/cuirass/database.scm
index f80585e..e81ead0 100644
--- a/src/cuirass/database.scm
+++ b/src/cuirass/database.scm
@@ -38,6 +38,7 @@
 db-init
 db-open
 db-close
+db-optimize
 db-add-specification
 db-remove-specification
 db-get-specifications
@@ -277,6 +278,13 @@ database object."
   "Close database object DB."
   (sqlite-close db))
 
+(define* (db-optimize #:optional (db-file (%package-database)))
+  "Open the database and perform optimizations."
+  (let ((db (db-open db-file)))
+(sqlite-exec db "PRAGMA optimize;")
+(sqlite-exec db "PRAGMA wal_checkpoint(TRUNCATE);")
+(db-close db)))
+
 (define (last-insert-rowid db)
   (vector-ref (car (sqlite-exec db "SELECT last_insert_rowid();"))
   0))
-- 
2.26.2

Re: Exact same 'call-with-temporary-directory' defined twice?

[zimoun]

Hi Ludo,

On Sun, 24 May 2020 at 22:59, Ludovic Courtès  wrote:

> Regarding (1): a statically-linked Guile cannot call ‘dynamic-link’ to
> access libc symbols, so it cannot use FFI bindings to libc such as those
> in (guix build syscalls).

Thank you for the explanations.  It helps. :-)


Cheers,
simon

Re: Can we increase the print width/column in daemon backtraces

[Tobias Geerinckx-Rice]

Hullo,

Ludovic Courtès 写道：
Users are not supposed to see backtraces coming from the daemon 
or its

helpers (‘guix substitute’, ‘guix offload’, etc.).


Put that in the EULA then, because those naughty users insist on 
doing so regularly :-)  It's not clear what you're arguing for.


Pierre Neidhardt 写道：
The COLUMN environment option (set in root's .bash_profile) does 
not

extend the print width of backtraces when running `guix build`.


Nor should it[0].  What you describe sounds like a convenient bug 
being fixed(?).  Was this on Guix System or a foreign 
distribution?


Yours in curiosity and frustration,

T G-R

[0]: 
https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html#Bash-Startup-Files


signature.asc
Description: PGP signature

Re: Updating the “pre-push” Git hook

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Could you try:
>
>   mv ~/.cache/guix/authentication/channels/guix{,.bak}
>   time make authenticate
>   mv ~/.cache/guix/authentication/channels/guix{.bak,}
>
> ?

real0m49.496s
user0m43.733s
sys 0m1.658s

And then running it again:

--8<---cut here---start->8---
$ [env] time make authenticate
Authenticating Git checkout...
Authenticating d68de95 to fb1675e (0 commits)...

real0m2.692s
user0m2.877s
sys 0m0.128s
$ [env] time make authenticate
Authenticating Git checkout...
Authenticating d68de95 to fb1675e (0 commits)...

real0m2.754s
user0m2.939s
sys 0m0.111s
--8<---cut here---end--->8---


-- 
Ricardo

Re: MIPS support

[Efraim Flashner]

Here's a first draft at removing mips64el-linux support from the
documentation. I've left it as a supported system in (gnu ci), in (guix
packages) and in the tests. I changed the text where we mention that we
support mips64el-linux as an architecture, and elsewhere in the manual
I've either removed mention of it when it was listed as a supported
target or changed the references to aarch64.


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
From ebaef27fd08c29883a8e4bb091ccbd2bef9b2747 Mon Sep 17 00:00:00 2001
From: Efraim Flashner 
Date: Mon, 25 May 2020 12:29:55 +0300
Subject: [PATCH] doc: Remove explicit support for mips64el-linux.

It's been a good run, but no one is maintaining the architecture.
So long, and thanks for all the fish.

* doc/guix.texi (GNU Distribution): Change text for mips64el-linux
to denote it is deprecated.
(Daemon Offload Setup): Change occurrences of mips64el-linux to
aarch64-linux and adjust local code snippets.
(Guix Environment)[cross-compilation]: Change mips64el-linux-gnu to
aarch64-linux-gnu.
(GNU Build System)(package-cross-derivation]: Same.
(G-Expressions)[cross compilation]: Same.
(Additional Build Options)[cross-compilation, build logs]: Same.
(qemu-binfmt-service-type): Remove mips64el.
* doc/contributing.texi (Submitting Patches): Same.
* m4/guix.m4: (GUIX_ASSERT_SUPPORTED_SYSTEM): Remove mips64el-linux.
---
 doc/contributing.texi |  3 +--
 doc/guix.texi | 25 +
 m4/guix.m4|  2 +-
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/doc/contributing.texi b/doc/contributing.texi
index 7b1f7e7c94..7496db5aaa 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -938,7 +938,7 @@ your @code{operating-system} configuration:
 @lisp
 (service qemu-binfmt-service-type
  (qemu-binfmt-configuration
-   (platforms (lookup-qemu-platforms "arm" "aarch64" "mips64el"))
+   (platforms (lookup-qemu-platforms "arm" "aarch64"))
(guix-support? #t)))
 @end lisp
 
@@ -951,7 +951,6 @@ commands, respectively:
 @example
 guix build --system=armhf-linux --rounds=2 hello
 guix build --system=aarch64-linux --rounds=2 hello
-guix build --system=mips64el-linux --rounds=2 hello
 @end example
 
 @item
diff --git a/doc/guix.texi b/doc/guix.texi
index 3d1b097447..50472e0adb 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -464,11 +464,12 @@ and Linux-Libre kernel.
 @item aarch64-linux
 little-endian 64-bit ARMv8-A processors, Linux-Libre kernel.
 
-@item mips64el-linux
+@item mips64el-linux (deprecated)
 little-endian 64-bit MIPS processors, specifically the Loongson series,
 n32 ABI, and Linux-Libre kernel.  This configuration is no longer fully
-supported; in particular, the project's build farms no longer provide
-substitutes for this architecture.
+supported; in particular, there is no ongoing work to ensure that this
+architecture still works. Should someone decide they wish to revive this
+architecture then the code is still available.
 
 @end table
 
@@ -1059,8 +1060,8 @@ The @file{/etc/guix/machines.scm} file typically looks 
like this:
 (speed 2.)) ;incredibly fast!
 
   (build-machine
-(name "meeps.example.org")
-(system "mips64el-linux")
+(name "armeight.example.org")
+(system "aarch64-linux")
 (host-key "ssh-rsa B3Nza@dots{}")
 (user "alice")
 (private-key
@@ -1070,7 +1071,7 @@ The @file{/etc/guix/machines.scm} file typically looks 
like this:
 
 @noindent
 In the example above we specify a list of two build machines, one for
-the @code{x86_64} architecture and one for the @code{mips64el}
+the @code{x86_64} architecture and one for the @code{aarch64}
 architecture.
 
 In fact, this file is---not surprisingly!---a Scheme file that is
@@ -5329,7 +5330,7 @@ the system type of the build host.
 @item --target=@var{triplet}
 @cindex cross-compilation
 Cross-build for @var{triplet}, which must be a valid GNU triplet, such
-as @code{"mips64el-linux-gnu"} (@pxref{Specifying target triplets, GNU
+as @code{"aarch64-linux-gnu"} (@pxref{Specifying target triplets, GNU
 configuration triplets,, autoconf, Autoconf}).
 
 @item --compression=@var{tool}
@@ -5718,7 +5719,7 @@ Return the @code{} object of @var{package} 
cross-built from
 @var{system} to @var{target}.
 
 @var{target} must be a valid GNU triplet denoting the target hardware
-and operating system, such as @code{"mips64el-linux-gnu"}
+and operating system, such as @code{"aarch64-linux-gnu"}
 (@pxref{Specifying Target Triplets,,, autoconf, Autoconf}).
 @end deffn
 
@@ -7719,7 +7720,7 @@ native package build:
 "-s"
 (string-append #$emacs "/bin/emacs")
 (string-append #$output "/bin/vi")))
-   #:target "mips64el-linux-gnu")
+   #:target "aarch64-linux-gnu")
 @end lisp
 
 @noindent
@@ -8839,7 +8840,7 @@ also be offloaded to a remote 

Re: “guix --help” should point to https://guix.gnu.org/help/

[zimoun]

Hi Ludo,

On Sun, 24 May 2020 at 23:10, Ludovic Courtès  wrote:

> This is harsh, maybe unnecessarily so, but still a very valid criticism
> of that page.  I guess that page was created with good intentions, but
> it’s pretty much useless indeed.  :-/

I am sorry if I have been harsh and if I have hurt someone.  I was
*not* my intention.  Otherwise, I would not spend 5 minutes to follow
all the links and check how to reach help for the GNU Guix project
from this webpage. :-)


> Probably we should work on the GNU side to make that page more useful,
> but we should also definitely print the relevant Guix URL.

Yes, we should.  However, to be honest, reading GNU related mailing
lists over the last past months and especially the recent emacs-devel
threads, I do not personally have enough energy to potentially argue
the obvious on bikeshed.


Cheers,
simon

Re: “guix --help” should point to https://guix.gnu.org/help/

[Efraim Flashner]

On Sun, May 24, 2020 at 11:10:36PM +0200, Ludovic Courtès wrote:
> Hi,
> 
> zimoun  skribis:
> 
> > On Fri, 15 May 2020 at 12:20, Ricardo Wurmus  wrote:
> >
> >>   General help using GNU software: 
> >
> > I have never read this.  It is not welcoming for newcomers, IMHO.
> >
> > First sentence: "The Free Software Foundation does not provide
> > technical support." I give up.
> > Second paragraph: RTFM! Well, click, click again, I give up.
> > Third: Lengthy explanations... about bug report. I give up.
> > Fourth: After scrolling, click, click again, I give up.
> > Or click to IRC, #guix is not mentioned, I give up.
> >
> > If someone reaches the help they needs by this mean, they is my hero! :-)
> 
> This is harsh, maybe unnecessarily so, but still a very valid criticism
> of that page.  I guess that page was created with good intentions, but
> it’s pretty much useless indeed.  :-/
> 
> Probably we should work on the GNU side to make that page more useful,
> but we should also definitely print the relevant Guix URL.
> 
> Ludo’.
> 

(ins)efraim@E5400 ~$ cat /etc/os-release
NAME="Guix System"
PRETTY_NAME="Guix System"
VERSION="1.1.0-4.bdc801e"
VERSION_ID="1.1"
ID=guix
HOME_URL="https://www.gnu.org/software/guix/;
SUPPORT_URL="https://www.gnu.org/software/guix/help/;
BUG_REPORT_URL="mailto:bug-g...@gnu.org;

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