AlwaysLivid has quit [Remote host closed the connection]
rajivr has joined #nixos-dev
AlwaysLivid has joined #nixos-dev
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-dev
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-dev
<davidak[m]>
i can report that i'm merging PRs now for 2 days since supersandro2000 gave me an introduction. i have merged 22 PRs now! i'm already pretty comfortable doing it, especially when i know how to test it myself. i'm very happy to be able to contribute in this impactful way now \o/
<davidak[m]>
if you notice something i can improve, i'm open for all feedback
tilpner has quit [Remote host closed the connection]
tilpner_ has joined #nixos-dev
tilpner_ is now known as tilpner
<rmcgibbo[m]>
Any chance I could get 112951 reviewed and/or merged? (It's a prerequisite for some new r-rmcgibbo features on my TODO list.)
tilpner has quit [Remote host closed the connection]
<puck>
i should see if i can rebase my changes on top of that
<puck>
i'm still running a derivative of it on my local system, but plucking out the changes is difficult
cole-h has joined #nixos-dev
<worldofpeace>
puck: that would be nyawesome! I currently have to patch plymouth because some nonsense, but I don't think the diff will change in the module
<worldofpeace>
rnhmjoj: yeah, I read ur entire story on that change 😀 I could test it, I'm pretty much always traversing gdm stuff
<ScottHDev5>
Hello, how could I override a nixos module to change the ExecStart of the service in the config attribute
<sterni>
config.systemd.services.<service name>.serviceConfig.ExecStart = lib.mkForce <new value>; should work, I think
<sterni>
usually configuration options specified in multiple modules, i. e. the module your using and your configuration.nix get merged
<sterni>
with lib.mkForce you can merge by discarding all other values
<infinisil>
Or rather, discard all definitions with lower priority than mkForce
<infinisil>
All mkForce's are still merged together
<infinisil>
(unless there's a higher priority than mkForce)
<ScottHDev5>
I get : error: Module `:anon-1080' has an unsupported attribute `environment'. This is caused by introducing a top-level `config' or `options' attribute. Add configuration attributes immediately on the top level instead, or move all of them (namely: environment services) into the explicit `config' attribute.
FRidh has quit [Ping timeout: 260 seconds]
FRidh has joined #nixos-dev
<sterni>
ScottHDev5: try removing the config. beginning if it's your configuraton.nix
<ScottHDev5>
I getIt worked thanks !
<ScottHDev5>
s/I get//g
<philipp[m]1>
Since I didn't get any reaction to my backport helper bot idea here: What would be the right channel to propose a bot? A github issue in nixpkgs?
<catern>
"nix copy" allows adding signed paths to the store, but its interface is unstable and changing in 2.4; is there any other way to add a signed path to the store?
<catern>
as far as I can tell, the only way to pass valid signatures to addToStore is to 1. link against Nix, 2. speak the Nix protocol, or 3. use "nix copy" which is unstable
<catern>
that can't be right, can it?
FRidh has quit [Quit: Konversation terminated!]
<sterni>
catern: sounds exactly right tbh with the state of nix rn
<sterni>
same with sri hashes which have no stable interface to deal with them atm, but are relatively widely used
pbb has joined #nixos-dev
<sterni>
also of course nix-copy-closure(1) and nix3-copy(1) are both extremely vague so you can't really gauge their differences
pbb has quit [Client Quit]
pbb has joined #nixos-dev
<catern>
hm, how stable is the library interface for Nix?
<catern>
I guess it doesn't matter, I want to be able to do this thing without shipping a new binary linked against libnix everywhere that I want to do it
<sterni>
indeed
red[evilred] has joined #nixos-dev
<red[evilred]>
,locate libstdc++.a
<{^_^}>
Found in packages: libgccjit, gcc-unwrapped, gcc-arm-embedded, gcc-arm-embedded-6, gcc-arm-embedded-7, gcc-arm-embedded-8
<red[evilred]>
interesting... not what I expected
<red[evilred]>
hmmm
<ekleog>
red[evilred]: you can directly DM the {^_^} bot with these questions, no need to come ask on #nixos-dev ;)
<red[evilred]>
oh, thanks you
<red[evilred]>
didn't know that :-)
<ekleog>
np :)
<red[evilred]>
but I confess being confused
<red[evilred]>
how am I meant to get a copy of libstdc++.a during a compile with clang, if gcc are the only packages to have it
<ekleog>
oh. this question. I remember searching about it like twice, either finding out or giving up twice, but I have no recollection of whether I managed to figure it out or how, sorry :/
<catern>
sterni: maybe I'll write a simple Nix protocol client in bash :) (which can perform opAddNarToStore and nothing else)
<symphorien[m]>
<catern "hm, how stable is the library in"> nix-du uses like 3 functions and supports nix 2.2 and 2.3 and there are already 2 ifdefs in the binding
<symphorien[m]>
And I suspect 2.4 changes some types
<sterni>
most likely even less regard for stability than for the cli :p
<sterni>
catern: I think your best bet is two write a wrapper around the stable clis until they get removed
<sterni>
I really dread the moment when the current clis get removed I can feel it coming
<catern>
sterni: the stable clis? but that's my point, there's no way to do this with the existing nix-foo CLIs, it's only possible with the unstable "nix copy"
<catern>
symphorien[m]: lol fair enough
<sterni>
catern: I thought there may be a way using nix-store manually? maybe???
<sterni>
just an idea though
<catern>
at least the Nix daemon protocol is stable
<catern>
sterni: I've been reading through the source and I can't see any way
<sterni>
:///
<catern>
I might be missing something though, I'm mainly just looking at addToStore
<catern>
There might be another store-api.hh function which basically does the same thing
<catern>
(I mean there's importPaths but that doesn't check/support signatures)
<red[evilred]>
So, interesting
<red[evilred]>
clang apparently has libc++
<red[evilred]>
instead of libstdc++
<red[evilred]>
so I need to pull gcc into the scope of my build without it accidentally polluting the rest of my build process
<red[evilred]>
that should be interesting to achieve
<dottedmag>
red[evilred]: Do you specifically need libstdc++ or "a standard C++ library" will do?
<{^_^}>
grahamc/hydra#2 (by grahamc, 8 minutes ago, open): Per test db
<dottedmag>
I'm trying to figure out how to disable deprecated libcrypt from glibc and build ABI-compatible libxcrypt. Everything is fine except that gcc with address sanitizer wants to know the size of struct crypt_data. Now, how do I break this loop? I need a gcc to build libxcrypt, and I need libxcrypt to build gcc.
<dottedmag>
Maybe libxcrypt can depend on non-final, bootstrap gcc? Is there a way to declare that?
<dottedmag>
Or should I just patch gcc with a known size of this struct for all supported platforms to stop it from caring about libxcrypt?
<red[evilred]>
dottedmag (IRC): good question - unsure. upstream is changing how the build and pull the dep in via a find /usr/lib -name libstdc++.a
<red[evilred]>
dottedmag (IRC): Do you think I should just try it with libc++.a ?
<red[evilred]>
or do you have another suggestion?
<dottedmag>
red[evilred]: It might just work
<dottedmag>
And yes, if they are looking it up in such a way, then probably it just didn't occur to them that there are other standard C++ libraries out there.
<red[evilred]>
I should see how their OSX port works
<red[evilred]>
whether they ported libstdc++ or use libc++
<red[evilred]>
dottedmag (IRC): yup - on Darwin they use libc++(!)
<samueldr>
rnhmjoj: "Hope you enjoy long commit messages." -- verily, yes