<---
--keep-going-but-for-machines-I-don't-know-what-to-call-this
Anyone have thoughts on this?
Thanks,
Richard Sent
ux-libre.
Posting to guix-devel instead of bug-guix since I'm not entirely sure
this is a bug or working as intended.
[1] https://lists.gnu.org/archive/html/guix-devel/2022-12/msg00310.html
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
Thanks for sharing! The comments section was a nice change of pace from
the tone of Guix discussion in Hacker News.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
nues, but I feel it is an improvement over
the status quo with no negative tradeoffs. I would not support a
solution that obsoletes time-machine or requires regular manual
intervention during upgrades.
Personally as a new contributor I find it gratifying to see my name in
the commit history.
--
Take it eas
27;m not thinking of.
Would UUIDs be valid for the copyright notices at the top of files?
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
Hi Guix,
To my knowledge what I'm asking for can't currently be done, but if it
can feel free to disregard.
I think channels listed in channels.scm files should optionally support
using whatever channel version is already in the user's profile, if
present. This would significantly speed up enteri
le to use https except for git in shell containers.
Power users will still be able to override the normal behavior by
setting the package-specific environment variables. This change would
just change the default state from "nonfunctional" to "working".
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
can depend on. I imagine adding a requirement to the wrong file-system
could easily cause a deadlock.
I know a custom shepherd service could be used to run, say, mount.cifs
from userspace after networking is provisioned, but in my opinion it
would be cleaner to encapsulate within the existing file-system block of
the operating system.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
>8---
(I don't have an NFS system on my LAN to test so no promises)
Hopefully that shows what I'm thinking. If anyone has thoughts I'd love
to hear it, either here or in the patch depending on what's appropriate.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
g00718.html
[2]: https://lists.gnu.org/archive/html/guix-devel/2017-09/msg00098.html
[3]: https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
n question.)
Happy to change to whatever the consensus is!
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
hat optionally takes a revision e.g.
issues.guix.gnu.org/issue/70XXX/patch-set/3.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
pt.scm.drv...
building package cache...
building profile with 1 package...
guix 0edbb93
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 0edbb93130651f29dc59fe4ca546a5065670ac8a
--8<---cut here---end--->8---
I imagine there's a large amount of behind the scenes work that would
need to be done for this to work, but if nothing else it's an
interesting thought experiment!
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
Simon Tournier writes:
> Hi,
>
> On lun., 13 mai 2024 at 17:11, Richard Sent
> wrote:
>
>> Instead of A and B building C directly, A and B download the
>> substitutable Guix package D, then use D to build C. Because D is a
>> reproducible package, it should b
>> - Why is this step not substitutable ? The inputs are known, a hash can
>> be derived, a substitute server could be queried for an output of that
>> hash ? What am I missing ? Does the guix derivation not end up in the
>> store ? What makes it so special that it can't be served by a substitute
>
> I see that build in build-self.scm isn't a derivation, but most of the time
> spent in build is, to my knowledge, while the daemon is building the
> build-program derivation. build-program in build-self.scm returns a
> gexp->script file-like object and I see various /gnu/store
> *-compute-gui
nning the test with old services. I don't believe Guix
has a mechanism yet to say "Yes, this service is new, and I /do/ want
Shepherd to auto-start it, but not on reconfigure". This shouldn't be
too hard to add though.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
to a specific commit.
At present I can think of soft-pinning a list of channels by name being
useful. I can also see an option to only fetch dependencies of a
channel, not the channel itself, being useful. I would definitely
appreciate feedback or use cases! :)
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
Hi Ludo!
FYSA based on https://issues.guix.gnu.org/71238 I suspect the fix
mentioned in that patch might not be applying properly in all cases.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
nitrd fails during startup it will abort into an
interactive Guile REPL. This might hurt GRUB's ability to detect
something went wrong since the kernel would still be running. A similar
case may apply if Shepherd gets stuck during system initialization.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
> i'm afraid that's not the case currently:
>
> %guile-static-stripped crashes with a sigsegv (i.e. the guile used in the
> initrd (?))
> https://issues.guix.gnu.org/71211
Interesting. Is this a recent bug? When I was trying to bring up Guix on the
VisionFive 2 I was being dropped into a Guile
this, but it is an option.
>> I think this is a side effect of time-machine serving dual purposes.
>> One is providing a reproducible environment for result replication,
>> the other is providing a development environment for collections of
>> channels.
[1]: https://lists.gnu.org/archive/html/guix-devel/2024-03/msg00265.html
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
dency trees grow, this'll
become even more annoying. If B is only importing a couple Guix modules
that are unlikely to incompatibly change, it's basically wasted effort.
This is outside the scope of this topic, but I think it could be
interesting if the dependency channels in .guix-channel could specify
minimum commits as well.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
Hi Felix,
Felix Lechner writes:
> Hi Richard,
>
> On Tue, Apr 23 2024, Richard Sent wrote:
>
>> I submitted a patch for what I'm thinking at
>> https://issues.guix.gnu.org/70542.
>
> I believe this stopped working for my NFS setup.
Interesting. It does stil
Hope it happens and I can
make it.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
rements (quote
(fake))) (type "dummy"))
--8<---cut here---end--->8---
That's from me trying to create a file-system record with the
requirements field instead of shepherd-requirements.
[1]: https://issues.guix.gnu.org/70542#19
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
ix.gnu.org/66355#1-lineno28
[4]: https://issues.guix.gnu.org/43078#2
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
g and
> possibly self-contradictory fashion, using the GPL together with
> unacceptable added restrictions that would make those works non-free
> software.
[1]:
https://www.fsf.org/blogs/licensing/protecting-free-software-against-confusing-additional-restrictions
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
b14cf18b13fefb228558
[3]: (standards) Indicating the Part Changed
[4]: (guix) Submitting Patches
[5]: 62881ad61c
[6]: a9ca7998f7
[7]: cd0a8950e4
[8]: 77d949c812
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
correctly there's been discussion of an RFC process in the
past. I don't recall the details but depending on how expansive this
becomes perhaps that's relevant.)
[1]: https://github.com/magit/magit/pull/3928
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
arts on it first feel free! I will appreciate a heads up if
that's the case. :)
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
tication by setting the default
authenticate? value in build-channels to #f. You might be able to get
away with just step 3 depending on what exactly you are changing in your
checkout.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
>> In terms of side-stepping the question, do we have enough x86_64
>> hardware to continue to support i686 without degrading support for
>> x86_64? (I ask this seriously, although I'm pretty certain the answer is
>> we're well covered on that front.)
>
>Support does not just mean dedicating build
n a custom
config, or a 3rd party channel, user-facing functionality will be lost
if we remove them.
Breaking changes are okay, and if we consider this too niche of a use
case or too high of a maintenance burden it should be dropped. I do
believe it should progress into the consideration stage i
-defaults
;; default #t for most fields
(aliases? #f)
;; (source-system? #t)
;; (sane-ssh? #t)
(prompt? #f))
--8<---cut here---end--->8---
This could allow for a more comprehensive and opinionated default bashrc
to be packaged with Guix while still m
eve a blog post is appropriate
given the scope and nature of the changes.)
If a blog post is written, hopefully it's soon. I imagine opinions
posted near the end of the discussion period will have less importance
as everyone else has already informally reached a consensus.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
36 matches
Mail list logo
