0.drv.bz2
if that's of any help.
> I'm unsure how to proceed. Can someone please help me independently
> verify these binaries?
Yeah, I don't know...Do I dare to suggest you give it a retry? I built
it on a x86_64 dell xps-13 9350. Your X200 is also 64bits right?
Greetings, a puzzled janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
rap";
"ftp://alpha.gnu.org/gnu/guix/bootstrap";
"http://www.fdn.fr/~lcourtes/software/guix/packages";
--8<---cut here---end--->8---
and running
./pre-inst-env guix build --system=i686-linux -e '(@@ (gnu packages
c
. I'll have a look into this.
If we could find how you can reproduce the current flawed hash-containing
bootstrap binaries that we have on core-updates, that would be nice...I'm
hoping for Ludo' to step in and say something insightful about the
differences you found :)
janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Jan Nieuwenhuizen writes:
> Hmm, I'm not sure how much work it would be. If we're lucky then the
> recipes from gnu/packages/bootstrap.scm
*gnu/packages/make-bootstrap.scm
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.co
Jan Nieuwenhuizen writes:
>> What I need is a way to build the new bootstrap tarballs without using
>> the existing 'core-updates' branch. I need a way to build them from a
>> branch that's based upon the much older bootstrap binaries that we've
>>
61d14ae15f2f.
They give the same md5sum for me as the wip-binaries branch that
branched off of master; so mine are at
http://lilypond.org/janneke/guix/20190722/
After this commit should come the update-commit, using them in
bootstrap.scm.
HTH,
janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://l
nd building on Debian ootb.
There's no real reason to update bootstrap tarballs for those versions
and I cannot promise a release date yet.
Further work on mes-0.21 should bring the Reduced Binary Seed bootstrap
to ARM (lots of work still) and replace the `static-binaries' w
Mark H Weaver writes:
> It seems to me that the best way to accomplish this is to backport the
> new '%bootstrap-tarballs' from 'wip-cu-binaries' to the 'master' branch.
I called that `wip-binaries', @master from three weeks ago.
--
Jan Nieuwenh
t; and 0.5.2-0.bb062b0, and what was the rationale for updating to bb062b0?
Good catch. We probably can, we might try that.
I think the need for updating to bb062b0 has been removed during the
review of the integration of the reduced binary seed bootstrap into
core-updates by Ludovic.
For historica
rg/cgit/guix.git/commit/?h=core-updates-next&id=659a2d0f4fff889dff902e32b569e4ca0ae5384a
Greetings,
janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
er branch like core-updates-next is usually done by
working on a clone of the Guix Git archive. See `14.1 Building from
Git' (https://guix.gnu.org/manual/en/html_node/Building-from-Git.html).
Greetings,
janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance
uot;vt7")))
(set-xorg-configuration (xorg-configuration
(keyboard-layout keyboard-layout))
slim-service-type)
PS tried sending this message to
https://issues.guix.gnu.org/issue/26234
but it got lost. Is it an accident, or is sending messages to closed
issues impossible?
---
Jan Wielkiewicz
ore/0npakqh7q9kfik8y0cc0vjqqpvnyv2h1-module-import/guix/build/utils.scm:616:6:
In procedure invoke:
Throw to key `srfi-34' with args `(#)'.
---
Jan Wielkiewicz
nnot seem to find anything that resembles
this build problem or a fix.
Greetings,
janneke
>From 4966d8dc9e079a5fb776f456dfb3f0918bcfa1b9 Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen
Date: Tue, 24 Sep 2019 20:23:31 +0200
Subject: [PATCH] gnu: gcc: Fix mingw cross compiler.
* gnu/packages
Jan Nieuwenhuizen writes:
I sent it as when it worked and then found it could be cleaned up; attached.
janneke
>From 051e4a62cbc6d48015f0f2f807141ad92ac73cf2 Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen
Date: Tue, 24 Sep 2019 20:23:31 +0200
Subject: [PATCH] gnu: gcc: Fix mingw cr
(keyboard-layout
> (keyboard-layout "pl,cz" "legacy,ucw"
>
> #:options
> '("compose:menu,grp:caps_switch"))) ;; skipped content
> ))
>
> WŻ
Jan Wielkiewicz
dates as 308eb5c11a885768f81fb6136fd4d30b4639fe04
Greetings,
janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
sn't work with slim though, would be nice if
someone fixed it and the fact (keyboard-layout (keyboard-layout "pl,cz"
"legacy,ucw")) works on your machine, but not on mine is strange.
Jan Wielkiewicz
19,
MesCC-Tools schould be fixed on 0.5.2 and I just found that building
bootstrap-bash also breaks due to an update to bash-5.
Greetings,
jannneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
627684d3 Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen
Date: Sun, 29 Sep 2019 13:08:01 +0200
Subject: [PATCH] gnu: gcc: Fix i686-linux cross compiler.
This resurrects
./pre-inst-env guix build --target=i686-unknown-linux-gnu hello
* gnu/packages/cross-base.scm (cross-gcc-arguments): Do n
Jan Nieuwenhuizen writes:
> Bengt Richter writes:
>> I tried
>> guix build bootstrap-tarballs
>
> Yes, sadly that's not supported on current master. It should work on
> core-updates. So I tried that and found it fails in similar ways.
The attached patc
Marius Bakke writes:
> Jan Nieuwenhuizen writes:
>> I stumbled upon this while working to fix #37549. Where should this
>> patch land?
>
> This patch should be safe for 'core-updates'. Please double check that
> it does not rebuild the world, though. :-)
I
Jan Nieuwenhuizen writes:
> Jan Nieuwenhuizen writes:
>
>> Bengt Richter writes:
>>> I tried
>>> guix build bootstrap-tarballs
>>
>> Yes, sadly that's not supported on current master. It should work on
>> core-updates. So I tried that
d be more clear if the manual or the cookbook contained a
step-by-step list like this:
Quick setting up the environment:
1. git clone ...
2. ./bootstrap
3. ./configure --localstatedir=/var/
4. make check
5. setting certificates to be able to update a package
etc.
Jan Wielkiewicz
, but
now I'm able to run "guix refresh", so the issue can be closed.
Thank you all for suggestions.
Jan Wielkiewicz
'/tmp/guix-build-mate-applets-1.22.0.drv-0/mate-applets-1.22.0' make:
*** [Makefile:486: all] Error 2 command "make" "-j" "2"
"gtk_update_icon_cache=true" failed with status 2
This time it doesn't seem to be caused by my underpowered laptop,
because I haven't encountered any freeze and the package doesn't seem
to be anything serious.
Jan Wielkiewicz
brvizic3qv469j8fd…" …) …)
In guix/progress.scm:
219:14 0 (display-download-progress "google-brotli-@" #f # _ # _ …)
guix/progress.scm:219:14: In procedure display-download-progress:
In procedure =: Wrong type: #f
Jan Wielkiewicz
Dnia 2019-11-06, o godz. 10:35:25
Ludovic Courtès napisał(a):
> Hi Jan,
>
>
> Could you send the log returned by:
>
> guix build --log-file
> /gnu/store/brvizic3qv469j8fd2xgsgx9p8s5s1j7-google-brotli-1.0.7-checkout
>
> ?
https://ci.guix.gnu.org/log/brvizic3qv46
)
guix/progress.scm:219:14: In procedure display-download-progress:
In procedure =: Wrong type: #f
> Thanks,
> Ludo’.
Jan Wielkiewicz
jami-wip-09-11-2019.tar.bz2
Description: application/bzip
row to key `bad-response' with args `("Bad Response-Line:
~s" (""))'. guix pull: error:
`/gnu/store/v0wg5qvf88jhyrdzyphafwmvbj7lzra6-guix-1.0.1-10.41b4b71/bin/guix
substitute' died unexpectedly
Jan Wielkiewicz
king well now!
This sort-of works for me, i.e., typing "guix TAB" in an emacs shell
buffer no longer gives this error...but there also are no completions.
My ~/.emacs/init_bash.sh is empty and I seem to remember having
something there?
Greetings,
Janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Jan Nieuwenhuizen writes:
Hello!
> Mathieu Othacehe writes:
[..]
>> lib/linux/stat.c should be modified this way:
>>
>> #if __i386__
>> #define STAT_SYSCALL SYS_stat64
>> #else
>> #define STAT_SYSCALL SYS_stat
>> #endif
>
> Ah...the stat64 sy
ade it in version 1.1.0, fixes
> the segfault:
>
> commit e633669dfdf16f503a7d740b9058e343536533b4
> Author: nimaje
> Date: Thu Oct 15 19:12:18 2020 -0400
>
> Fix ELF headers to be more well behaved
[..]
> Should we upgrade instead? If we do, what’s the pot
Ludovic Courtès writes:
Hi Ludo!
> Jan Nieuwenhuizen skribis:
>
>>> Should we upgrade instead? If we do, what’s the potential for breakage?
>>> Should ‘mes-rb5’ be kept on an older version?
>>
>> We could try that, I really can't tell if upgrading t
dure open-file: No such file or directory:
"/run/user/1003/on-first-login-executed"
17:37:33 janneke@dundal:~
$ ssh guix@localhost -p
guix@localhost's password:
Last login: Fri Oct 1 17:23:35 2021 from 127.0.0.1
guix@dundal ~$
home-minimal.scm
Description: Binary data
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Ricardo Wurmus writes:
> This is now fixed in mumi. I tested the change in eww and in icecat.
Lovely, thank you!
Greetings,
Janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
shtwzrd writes:
> I've noticed that guix pull has started to hang consistently when
> building guix-system.drv, 55% of the way through.
Ah; I'm seeing this too -- for me current master consistently hangs at
54%
janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
F
zz)[source](sha256): Update.
--8<---cut here---end--->8---
shows. Thoughts?
Greetings,
janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Ludovic Courtès writes:
> Hi,
>
> zimoun skribis:
>
>> On Thu, 13 Feb 2020 at 22:34, Ludovic Courtès wrote:
>>>
>>> Hi,
>>>
>>> Jan Nieuwenhuizen skribis:
>>>
>>> > building
>>> > /gnu/store/cjim33x0q1b
Ludovic Courtès writes:
> Jan Nieuwenhuizen skribis:
>
>> building
>> /gnu/store/cjim33x0q1bv1ppkv3qijvr1pvsn4y0q-harfbuzz-2.4.0.tar.bz2.drv...
>> downloading from
>> https://www.freedesktop.org/software/harfbuzz/release/harfbuzz-2.4.0.tar.bz2...
>>
zimoun writes:
Hi Simon,
> On Fri, 14 Feb 2020 at 14:24, Jan Nieuwenhuizen wrote:
>
> This command
>
>> >> $ guix download -o /tmp/harfbuzz-old.tar.bz2 \
>> >>
>> >> https://ci.guix.gnu.org/file/harfbuzz-2.4.0.tar.bz2/sha256/1mpah6kwqid1kxsj4r
ae7ec 100644
--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -11,6 +11,7 @@
;;; Copyright © 2019 Tobias Geerinckx-Rice
;;; Copyright © 2019 John Soo
;;; Copyright © 2019 Jan (janneke) Nieuwenhuizen
+;;; Copyright © 2020 Florian Pelz
;;;
;;; This file is part of
am. Timothy?
How about applying attached patch that implements 1. and revert it once
we get to 2. or 3.
janneke
>From 06bc492cdc1f476f0caa558546290ceafde357b1 Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen
Date: Fri, 21 Feb 2020 07:46:16 +0100
Subject: [PATCH] gnu: commencement: boota
itionally for
> now since it could be error-prone to have different features depending
> on the platform.
>
> WDYT?
Yes, I removed it. Hoping that's okay. We just decided above it's
adding an unnecessary "if".
@Timothy: if you want to change this in bootar itself and r
itionally for
> now since it could be error-prone to have different features depending
> on the platform.
>
> WDYT?
Yes, I removed it. Hoping that's okay. We just decided above it's
adding an unnecessary "if".
@Timothy: if you want to change this in bootar itself and r
bnqlz4ppj0bgckksn7r25p385qawy-ffmpeg-4.2.2.drv.bz2
Description: Binary data
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
eption:
In procedure dynamic-pointer: Symbol not found: prctl
Makefile:2070: recipe for target 'modules/shepherd.go' failed
--8<---cut here---end--->8---
Find patch attached.
Greetings,
janneke
>From ac06193300aea17d6e6d1ad784585542815af94b
sing and re-evaluating on latest core-updates.
Greetings,
janneke
*) Everything from Manolis' old wip-hurd since been merged or ported to
the new wip-hurd.
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
onditional avoided in these files is a win
> in the not-so-long term. That’d be my guideline as we merge it. :-)
>
> Anyhow, thumbs up! I’m looking forward to merging it and having it
> built on CI (we could offload to a Debian VM!)!
Yes, that would be awesome!
janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Ludovic Courtès writes:
Hello!
> Jan Nieuwenhuizen skribis:
>
>>>> +#if !__GNU__
>>>> int status = pid.wait(true);
>>>> if (status != 0)
>>>> throw Error(format("cannot kill processes for uid `%1%': %2%") %
Ludovic Courtès writes:
> Jan Nieuwenhuizen skribis:
>
>> commit 7653827b8919ad85d025ba1a701ba38ab7d2e388
>> Author: Jan Nieuwenhuizen
>> Date: Sat Mar 7 03:53:38 2020 -0500
>>
>> gnu: coreutils: Remove libcap dependency for the Hurd.
>>
Jan Nieuwenhuizen writes:
>> For the sake of reducing complexity and keeping supported systems as
>> close to one another as possible, would it be an option to keep using
>> 2.0 for GNU/Hurd, like on the other systems?
...
>> That would entail changing make-bootstrap.scm t
Jan Nieuwenhuizen writes:
> Hello Guix'y supporters of the Hurd,
`wip-hurd' is now pushed to core-updates as
3a1c3642d4d611c5516a8ba5b6bc7e39bdc1c9ae
As discussed on IRC yesterday, we did it in two stages: we first
merged all work necessary to build sensible bootstrap bin
s a whole other stage of effort, I'm tempted to close this bug
>> and open a new one (or two?) for that. WYDT?
>
> There's bootstrap binaries now existing, I'd say that counts as merging
> in Hurd support.
>
> Congrats!
Thank you => closing.
janneke
-
Jan Nieuwenhuizen writes:
> That looks like an upstream problem
>
> https://gitlab.gnome.org/GNOME/gnome-shell/issues/64
Sorry, this is not helping.
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
, try to do some activity in the VM, and
> check in top whether ‘gnome-shell’ is growing.
That looks like an upstream problem
https://gitlab.gnome.org/GNOME/gnome-shell/issues/64
are we going to investigate backporting a fix?
janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
result: FAIL
Last week, when core-updates was at
1808e64de0 gnu: coreutils: Typo: Use libcap only when supported.
it worked correctly.
This is unfortunate, as wip-hurd-vm (freshly rebased) depends on a guix
update.
Greetings,
janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
ght away because we had that commit
locally.
I have just reset wip-hurm-vm, it should work now.
Thanks!
janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
ds.scm
+ (lambda _
+(substitute* "guix/records.scm"
+ ((" most-positive-fixnum")
+ " 536870911"))
+#t)))
+ '())
(add-before 'check 'copy-bootstrap-guile
(lambda* (#:key system inputs #:allow-other-keys)
;; Copy the bootstrap guile tarball in the store used
--8<---cut here---end--->8---
Greetings,
janneke
ncsp53ws1vg4kpbgzl3q99n442ixz8-guix-1.0.1-16.0c53d35.drv.bz2
Description: Binary data
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
ed.
This now makes me wonder whether upstream Hurd could use a patch for
${bindir} and ${libexecdir}. Possibly even for `/hurd'.
What do you all think?
Greetings,
janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
find.
So, I'm hoping to get `hello' built tonight, happy to hear any results
you may get!
Greetings,
jannneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
tup -> rc -> shepherd
if that's possible.
Greetings,
janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
e=geert.img,cache=writeback -m 2G -device rtl8139,netdev=net0 -netdev
user,id=net0,hostfwd=tcp:127.0.0.1:10022-10.0.2.15:,hostfwd=tcp::27528-:17528
There's some more (partially outdated) info here
https://git.savannah.gnu.org/cgit/guix.git/tree/THE-HURD?h=wip-hurd
HTH
janneke
--
J
d VGA screen blinks, and the wonky behavior starts.
This should be fixed in latest/todays wip-hurd-vm by this commit
http://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-hurd-vm&id=ccdf7336dfbb16bfc7a08b297ad9cabbe2663f55
janneke
--
Jan Nieuwenhuizen | GNU LilyPond http:
0i-shepherd-host-name.go
/gnu/store/dbmj8ls2bwn0vbwi6qzng56rgrza3z0i-shepherd-host-name.go: ELF 64-bit
LSB shared object no machine, version 1 (embedded), dynamically linked, with
debug_info, not stripped
--8<---cut here---end--->8---
Greetings,
janneke
--
Jan Nieuwenh
try it first anyway. So, what are you
seeing here, when would this not be OK? Any other ideas of how to
address this further?
Greetings,
janneke
>From cc9259a87c46cfa0dc2c59dc425b3656c9eecb13 Mon Sep 17 00:00:00 2001
From: "Jan (janneke) Nieuwenhuizen"
Date: Sat, 25 Apr 2020 15:20:04
to address it.
Oh! Yes, I guess we need that as soon as we unify the hurd VM with the
guix system build?
> Jan Nieuwenhuizen skribis:
>
>> + (let ((target (%current-target-system)))
>> +(with-extensions (list shepherd)
>> + (computed-file (string
t!
I am currently still looking to consolidate all the cross build fixes,
and how to migrate the Shepherd and services hacks into the regular
framework. I'm guessing that's all stuff that wip-disk-image does not
touch/change.
Greetings,
janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
about the branch name in combination with its
functionality: can/will/could "wip-disk-image" also be used for
guix system init/reconfigure (we don't have qemu on the Hurd)?
Greetings,
janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
oes not support cross builds
This could be mostly harmless...still building a full (non-tiny/minimal)
qemu or grub maybe?
Greetings
janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
ould replicate the glibc behavior.
Beautiful, thanks for getting to the bottom of this. Now that you
already have gone this far, would you like to whip-up a full patch for
GNU Mes?
To test it we may have to provide a tarball as we don't want to use XZ
and we don't have patch
cumentation says that "when a module
is autoloaded, all symbols become available"?
http://git.savannah.gnu.org/cgit/guile.git/tree/doc/ref/api-modules.texi#n298
So...what's going on here?
janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
extended to reflect these
addition
--8<---cut here---end--->8---
Greetings,
janneke
PS: I'm starting the VMs like so
guix environment --ad-hoc qemu -- qemu-system-i386 -enable-kvm -m 512\
-device rtl8139,netdev=net0 -netdev
user
rtition->config partition)
until the point where it lacks the "/hurd" symlink from the directives.
So, apart from removing the IF above in a nice way, we (you?) could try
to find a nice way to insert extra-directives
> @@ -168,6 +170,9 @@ of the directory of the 'system' derivation."
>(populate-root-file-system system-directory root)
^ here
I guess...and then we'd be done.
I'm not sure as to what extent the extra-directives is/was a kludge?
Janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
s://git.savannah.gnu.org/git/guix.git'...
guile: warning: failed to install locale
Hello, world!
--8<---cut here---end--->8---
Janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
dd patch for <https://bugs.gnu.org/41214>.
> 9db8836916 channels: 'build-from-source' restores '%guile-for-build'.
>
> This is fixed by 36640207c9543e48cd6daa92930f023f80065a5d, which also
> fixes the “incompatible bytecode” warnings.
Beautiful, thank you!
w.
This adds besides 'multiboot-kernel' and 'multiboot-modules' now also
'multiboot-arguments' to . The temptation to rename 'linux'
and 'linux-arguments' to 'kernel' and 'kernel-arguments' increases, but
I didn't!
I'm p
e, /hurd is symlink to /gnu/store/*-hurd-0.9/hurd/ and runsystem*
now is a very minimal bash script, doing
exec /libexec/rc "$@"
and /libexecc is currently being substituted with the store file name,
which gives us a hurd package that does this
/hurd/startup
e...but IME /hurd isn't easy to get rid of. The
Hurd code uses it "everywhere" and I seem to remember that a simple
substitute* on the Hurd archive was not enough...sadly I do not remember
the details, so maybe...
Greetings,
Janneke
>From e11e59cbcd9165e3b885c1019e19aaab471f5498 Mon
Ludovic Courtès writes:
Hello!
> Jan Nieuwenhuizen skribis:
>
>>> Having an RC argument passed directly by the bootloader seems like a
>>> good way to proceed for me. This is somehow remotely similar to what we
>>> are doing with the "initrd" on Lin
Ludovic Courtès writes:
>> From 37c2a57d72f5678ec21a48ed4a3b733a20b71ab1 Mon Sep 17 00:00:00 2001
>> From: "Jan (janneke) Nieuwenhuizen"
>> Date: Thu, 30 Apr 2020 15:40:07 +0200
>> Subject: [PATCH v2] gnu: services: Add %hurd-startup-service.
>>
>&g
hurd: Update to upstream Hurd-reserved xattr index.
>> [L] 68a8a26a57 gnu: guile-static: Disable JIT on ARMv7.
>> [L] 220243a2c6 vm: Shared-store script runs that native QEMU and Bash.
>> [L] e3b6c5dce2 vm: compiler honors system and target.
>> [L] d4342
Ludovic Courtès writes:
Hello!
> Jan Nieuwenhuizen skribis:
>
>> --- a/gnu/packages/hurd.scm
>> +++ b/gnu/packages/hurd.scm
[...]
>> + (substitute* "hurd/paths.h"
>> + (("_HURD_STARTUP\t")
>> +
Ludovic Courtès writes:
> Jan Nieuwenhuizen skribis:
>
>> So, after digesting your message here I took the next step: grep for
>> _HURD_STARTUP and change it there, like so
>>
>> diff --git a/gnu/packages/hurd.scm b/gnu/packages/hurd.scm
>> index 421783
Mathieu Othacehe writes:
> Hey Jan,
>
>> +Using GNU@tie{}mach in combination with a @code{hurd} is experimental
>> +and only available when building a vm-image.}.
>
> Maybe replace "vm-image" by "virtual machine disk image"?
Okay.
>> +
>>
are only building virtual
machine images. Changed to this
(let ((root-index 1)) ; XXX EFI will need root-index 2
Thanks, Janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
are doing a great job here, many thanks!
Thank you! -- luckily I get some help ;)
Janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Hurd VM hookup-up in bayfront
and really start building a Hurd system, mabye we'll see some more
people join in. I think that should be (almost?) possible after
merging, right?
Greetings, Janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
here---end------->8---
the error goes away.
Greetings,
Janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
:23:25 janneke@dundal:~/src/guix/master
git log --pretty=oneline | grep 36640207c9543e48cd6daa92930f023f80065a5d
36640207c9543e48cd6daa92930f023f80065a5d quirks: Build
'compute-guix-derivation' modules with 2.2 when needed.
--8<---cut here-------end--->8---
Am I missing so
-cut here---start->8---
./pre-inst-env guix build --system=i686-linux --target=i686-linux-gnu
grub-minimal
--8<---cut here---end--->8---
I am not sure if and how to report this upstream. Ideas for a bug
description?
Ludovic Courtès writes:
Hello,
> Jan Nieuwenhuizen skribis:
>
>> Attempting to reconfigure a i686-linux guix system to a Hurd system, I
>> found that the Grub(-minimal) cross build fails like this
>>
>> i586-pc-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -Wall -W
>> -D
it support this?
(FWIW, this is not specific for the Hurd, cross compiling from
i686-linux-gnu to i686-linux-gnu show the same error. The use case for
that may be a bit thin to warrant a bug report.)
Ideas welcome!
Greetings,
Janneke
>From 270667540146f8ef9ea7a44258a71b3837a7af4a Mon Sep
at) the push was successful.
A new attempt: pushed to master as d613991a8ebe5d4b3a7706f8f0dd52f16fc1c50a
And closing (forgot that too).
Greetings,
Janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Ludovic Courtès writes:
Hey Ludo',
> "Jan (janneke) Nieuwenhuizen" skribis:
>
>> This is a follow-up to commit b904b59ce592c89dfb4675a8c06757afed6738a0.
>>
>> * gnu/system/images/hurd.scm (hurd-disk-image): Add file-system-options to
>> create an
Ludovic Courtès writes:
Hello,
A new day!
> "Jan (janneke) Nieuwenhuizen" skribis:
>
>> * guix/store/roots.scm (proc-environ-roots): Handle EIO, for the Hurd.
>> * gnu/build/hurd-boot.scm (set-hurd-device-translators): Mount /proc. Add
>> symlink to /et
(oid=? (git-authentication-error-commit c)
+ (commit-id commit1
+(authenticate-commits
+ repository
+ (list commit1 commit2)
+ #:keyring-reference
+ "master")
+
Jan Nieuwenhuizen writes:
Hello,
>> Nitpick: I see 3 mostly unrelated patches: (1) fix duplicate called to
>> ‘scope’, (2) mount /proc, and (3) handle EIO. I think it’s clearer to
>> view them separately.
> Yes, I agree. I will split into 3 patches.
I have split and pu
I hoped anyway. I tried following the backtrace and looking for
search-patch instances for a bit...but it wasn't obvious.
Greetings,
Janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Jan (janneke) Nieuwenhuizen writes:
> Maybe we're missing some file_lock patch that Debian has? Where to look,
> glibc, hurd, ...? Ideas?
So...I found a way to reproduce the feature/bug: run "pragma synchronous =
normal;"
in two instances.
I created a db.sqlite using
101 - 200 of 255 matches
Mail list logo
