<edef>
if i have a tonne of patches it's generally a sign i should start preparing patches for upstream to make life easier
<qyliss>
Yeah, diffing is easy
<edef>
i don't actually have in my head how to diff it exactly
<qyliss>
And you can ask for commits that are in your tree but not in upstream
<edef>
but i suspect it would take me like, minutes to figure out
<qyliss>
edef: I think git diff HEAD:nixpkgs channels/nixos-unstable ?
<hyperfekt>
See, if I was any good at git I might be doing it your way. :b
<infinisil>
edef: I often only apply patches to my nixpkgs if I already made the PR
<edef>
i try to push out patches i've used for a bit, generally
<qyliss>
note: it is not good for motivating me to actually upstream things
<edef>
it is devilishly convenient to just have floated stuff, yeah
<qyliss>
but for a while I had so many open PRs I couldn't keep track of them all and upstreaming more stuff wasn't happening anyway
<hyperfekt>
This is all just to say currently trying to use modules beyond the exact way that they were intended in nixpkgs is kind of a pain unless you've built yourself a workflow.
<edef>
yeah
<qyliss>
yeah, definitely
<edef>
we definitely have an architectural problem there
<infinisil>
I feel bad for having so many open PR's to nixpkgs damnit, I'm just adding to the PR pile!
<edef>
i'm just really unsure what the better model is
<edef>
i'm kind of excite about having instantiated things more often
<qyliss>
I've low-key considered trying to encourage people to use big git monorepos and using git subtree pull as a channel replacement
<edef>
the current model where every module can look at every other module's privates makes stuff brittle
<qyliss>
I'm sort of romantically attached to the idea of everybody having their own trees and pulling from each other as needed
<edef>
mood
<qyliss>
But it's probably not a good workflow for non-power-users
<edef>
i think the intermediate workflow is okay
<edef>
like, we try to maintain a common thing for stuff most people tend to agree on
<edef>
if say 50% of repos have a certain thing, then we might as well have it in a shared upstream
<hyperfekt>
To be clear, this is not the way to do it (warning, my config is very ugly and this is by far the ugliest part of it): https://git.io/fjpQR
<edef>
in the current world stuff goes in upstream Just Because, essentially
<edef>
"well there has to be Something to do $thing"
<hyperfekt>
But if we could create a good experience to do something similar in nixlang++ it'd be kinda cool
<qyliss>
I try not to push these things to much because I figure I probably don't have sufficient empathy with people who do not want to maintain their own nixpkgs tree.
smaeul has left #nixos-dev ["bye"]
<edef>
instead of seeing like, how n people use it and then thinking about architecture
<edef>
qyliss: yeah, that's fair
<qyliss>
because, like, in my opinion it's the best thing since sliced bread
<qyliss>
but when I mention it to people who aren't edef they back away like homer through that hedge
<edef>
:D:
<edef>
i think it feels natural to me in part because i understand git's data model very precisely
<qyliss>
(and then in some cases time passes and they end up inventing exactly the same system for themselves...)
<edef>
and this defines most of the differences between how i use git and others do
<qyliss>
I think this is a bit of a problem really
<qyliss>
I strongly suspect most people use Nix in a different way to me that I don't entirely understand
<edef>
yeah
<qyliss>
But, I don't actually understand what that workflow even looks like
<qyliss>
I know that I tried to use channels early on and very quickly thought "wait... why am I not just using git"
<edef>
i'm about as alienated from the average nix user in that respect as from the average debian user for system administration in general, i think
<edef>
i've used channels directly ~never, my old setup was to just git pull --rebase into ~/src/local/nixpkgs
<qyliss>
Now, the nice thing about a big ball of mud git repo is that it encourages hacking
<qyliss>
And I think that's an understated benefit
<edef>
yeah
<qyliss>
Hacking on an npm package three layers of dependencies deep is too annoying to be worth it
<hyperfekt>
I think I didn't want to have to create a branch of every combination of patches I want to use, otherwise I would've seriously considered something similar to your workflow.
<gchristensen>
it is so good
<edef>
hyperfekt: hmm, why branch?
<qyliss>
I think we should be very careful with flakes to keep that hackability.
<edef>
yep
<edef>
in general i want to fork every piece of software i use
<qyliss>
I think it's not a bad thing that you have to basically have to write packages to be able to use NixOS
<infinisil>
I really like overriding packages with src = /home/infinisil/src/my-cloned-repo, and do a rebuild switch, then just watch it compile everything and figure out all it needs to do to get the changes running :)
<qyliss>
Because, like, how many Debian users would even know where to start contributing?
<qyliss>
gchristensen: what was that in reference to, exactly?
<qyliss>
conversation moving fast :)
<edef>
anything that puts more friction into forking software i use is worrying
<edef>
like, i think i would plausibly just use flakes by vendoring stuff?
<qyliss>
edef: I think that even thinking of that as a fork creates a barrier to hacking
<hyperfekt>
edef: I probably wouldn't have to create a branch each but I would have to collect patches from different branches if I want to disable some and not throw them away for some amount of time. There's probably some git magic to remove only an intersection of patches but I wasn't gonna start fucking around with that
<edef>
hyperfekt: i don't think i understand the thing you are trying to do
<qyliss>
fwiw, I very much like using Nix to patch everything that isn't Nixpkgs
<qyliss>
It's a very convenient way to do patch management
<edef>
hyperfekt: if i need a patch that i toggle between machines, i make an option for it
<qyliss>
It would be nice if Nixpkgs itself was similarly patchable
<qyliss>
I think I've seen a proposal for something like that
<edef>
hyperfekt: i just get to target "all edef's machines" rather than "all nixpkgs users"
<edef>
qyliss: i end up using git to produce patches though
<qyliss>
In general, I like the idea of anything that takes away from the idea that nixpkgs (or any software) is a done deal, handed down by god, and you either take it or leave it
<edef>
qyliss: heck, my bsd_finger patches were produced from git, despite that codebase probably living in CVS
<edef>
or RCS
<qyliss>
edef: I do that too, but that's my developent copy, which is very distinct in my mind from the code actually running on my system
<edef>
with cargo, i often end up using the workspaces feature to pull deps into my repo when i want to patch them
<qyliss>
For example, when a package updates, I still want the updates. I just want it to still apply my patches.
<qyliss>
I don't want to have to monitor every program I watch for updates
<edef>
like, we merge upstream nixpkgs into our tree
<hyperfekt>
edef: I'm not entirely sure either, which is a common theme for me :b
<hyperfekt>
My patches are less 'write and done' things and more me trying out some stuff I think, so it happens regularly that I have different combinations of them active. And I don't think I want to do the work of hiding every patches effects behind an option
<qyliss>
edef: right, but that's one as opposed to many
<qyliss>
infinisil: that's the one
<edef>
qyliss: if we were to, say, embed every package's source into nixpkgs
<edef>
qyliss: (this is not an actual proposal)
<edef>
qyliss: it would Just Work the same way, and conflict in the right ways, etc
<qyliss>
yes
<qyliss>
I've noticed when I write little programs it's much easier to just embed them into my nixlib tree
<edef>
ie that it is impractical to work this way is a tool deficiency, but it could be a pretty good workflow
<qyliss>
I would very much like it if you could do a PhD or something on this
<qyliss>
Because I think there's a lot to be explored here that would solve a lot of probles
<edef>
i think i need to be an undergrad already to do a PhD
<edef>
and, well, you know the tale of edef and formal education
<qyliss>
But requires a lot of just _thinking_, before doing an impl
<qyliss>
well, a year ago somebody told me I should do a PhD on Spectrum and now here I am doing something Not Dissimilar
<edef>
git is almost there tbh
<hyperfekt>
There'd not be a meaningful UX difference between tooling to update a hash and tooling to update a subtree except that you get patch collisions at update time instead of build time (which you would do after a an update anyways), right?
<edef>
like, submodules are just having a commit object in your tree (and a metadata file to tell you were to get it)
<edef>
which is not dissimilar from fetchgit
<qyliss>
anyway, gn
<hyperfekt>
gn! o/
<infinisil>
We need a VCS abstraction so this doesn't only work for git :P
<edef>
git is a dumb content tracker, any filesystem tree is fine
<edef>
but unfortunately it does not have weak tree pointers
<edef>
(submodules are weak commit pointers)
<edef>
qyliss: i think most of my Take here boils down to "separating VCS and PLs was a bad move"
<edef>
qyliss: and i have a rant around it that involves image-based programming systems and how we fucked up by discarding them entirely
<edef>
but i'm too tired and besieged by mosquitos to really lay out my thesis for that properly
<hyperfekt>
edef: You've probably already read about Unison, right?
matthewbauer has quit [Remote host closed the connection]
vaibhavsagar has quit [Write error: Connection reset by peer]
Ericson2314 has quit [Remote host closed the connection]
worldofpeace has quit [Write error: Connection reset by peer]
dtz has quit [Read error: Connection reset by peer]
alienpirate5 has quit [Read error: Connection reset by peer]
nh2[m] has quit [Remote host closed the connection]
yegortimoshenko has quit [Read error: Connection reset by peer]
layus[m] has quit [Remote host closed the connection]
ma27[m] has quit [Write error: Connection reset by peer]
nocent has quit [Write error: Connection reset by peer]
roberth has quit [Remote host closed the connection]
codyopel has quit [Remote host closed the connection]
thefloweringash has quit [Write error: Connection reset by peer]
rycee has quit [Write error: Connection reset by peer]
bennofs[m] has quit [Write error: Connection reset by peer]
<gchristensen>
RIP Matrix
<edef>
i assume not the rsync replacement
<edef>
hmm, have i
abbradar has quit [Remote host closed the connection]
timokau[m] has quit [Remote host closed the connection]
domenkozar[m] has quit [Remote host closed the connection]
<edef>
[trailer voice] this september, the matrix doesn't have you,
<edef>
christ that's genuinely two decades ago now
<edef>
hyperfekt: ooh, this is extremely my jam
<edef>
hyperfekt: i have this weird Arrow DSL in haskell that tries to do similar things with Haskell
<hyperfekt>
edef: no, the programming language. code is referenced by the hash of its normal form iirc
<hyperfekt>
and if you change a signature you refactor progressively larger subtrees to use the new signature and thus the new hash, no inconsistencies, ever
<edef>
that's cute
<edef>
qyliss: yeah, drew devault is spot-on there
Ericson2314 has joined #nixos-dev
<qyliss>
I feel like that’s the second mass matrix disconnect I’ve seen in the past 24 hours
orivej_ has joined #nixos-dev
drakonis has joined #nixos-dev
orivej has quit [Ping timeout: 245 seconds]
drakonis_ has quit [Ping timeout: 264 seconds]
ris has quit [Ping timeout: 264 seconds]
drakonis_ has joined #nixos-dev
ekleog has quit [Quit: WeeChat 2.4]
ekleog has joined #nixos-dev
drakonis has quit [Ping timeout: 276 seconds]
bennofs[m] has joined #nixos-dev
abbradar has joined #nixos-dev
alienpirate5 has joined #nixos-dev
domenkozar[m] has joined #nixos-dev
thefloweringash has joined #nixos-dev
dtz has joined #nixos-dev
worldofpeace has joined #nixos-dev
ma27[m] has joined #nixos-dev
nocent has joined #nixos-dev
timokau[m] has joined #nixos-dev
vaibhavsagar has joined #nixos-dev
yegortimoshenko has joined #nixos-dev
codyopel has joined #nixos-dev
layus[m] has joined #nixos-dev
nh2[m] has joined #nixos-dev
rycee has joined #nixos-dev
roberth has joined #nixos-dev
matthewbauer has joined #nixos-dev
drakonis has joined #nixos-dev
<worldofpeace>
adisbladis: we don't have a gnome live media yet :D With lightdm or GDM? I think that's the known bug that we have with upstream sessions
<drakonis>
gnome works best with gdm mind you
<worldofpeace>
jtojnar: that is weird, perhaps they didn't expect it be used in combination with those functions?
<worldofpeace>
can reproduce the test case
<jtojnar>
worldofpeace: the function definition sets backend, schema-id and path properties
<jtojnar>
just like g_settings_new_with_backend_and_path
<jtojnar>
whereas g_settings_new_full sets settings-schema, backend and path
<jtojnar>
I think the option needs to check what properties are set in the GSettings GObject and set the properties on the new object accordingly
orivej_ has quit [Ping timeout: 252 seconds]
<jtojnar>
s/option/function/
phreedom has quit [Quit: No Ping reply in 180 seconds.]
phreedom has joined #nixos-dev
cjpbirkbeck has quit [Quit: Quitting now.]
drakonis has quit [Ping timeout: 250 seconds]
drakonis has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
drakonis1 has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis1 has quit [Read error: Connection reset by peer]
drakonis1 has joined #nixos-dev
drakonis has quit [Ping timeout: 250 seconds]
drakonis_ has quit [Ping timeout: 276 seconds]
<infinisil>
Um, how do I build the nix manual?
<infinisil>
Without having to build all of Nix preferably
<infinisil>
Seems like `nix-build release.nix -A tarball` is the only way :/
<infinisil>
Oh god and this wants to build aws-sdk-cpp, which I know takes forever
<ekleog>
infinisil: nix-build nixos/release.nix -A manual.x86_64-linux
<infinisil>
That's the NixOS manual
<ekleog>
oh wait the nix manual, misread
<ekleog>
sorry
<infinisil>
The friction for contributing to docs couldn't be bigger..
phreedom has quit [Remote host closed the connection]
<Mic92>
etu: not sure, if I can test this until Friday. I currently ownly have printers at my workplace.
<Mic92>
etu: since it mainly new options I am not too worried about potential breakages.
<Mic92>
*it adds
orivej has joined #nixos-dev
multi has quit [Quit: reorganising parallel universes]
Synthetica has joined #nixos-dev
drakonis has quit [Ping timeout: 250 seconds]
drakonis has joined #nixos-dev
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 276 seconds]
<infinisil>
niksnut: Yeah but still, I don't want to make my machine build all kinds of unrelated things just to build the docs. Would be much better if there was a `nix-build release.nix -A manual` like nixpkgs has
<gchristensen>
you don't need to, you can run `make ./doc/manual/manual.html`
<infinisil>
Oh rly
<infinisil>
Would be nice for this to be documented, or be put into a nix-build
<clever>
gchristensen: not really, since they can be dynamically generated
<gchristensen>
of course
<infinisil>
gchristensen: Oh and also, I need to enter nix-shell first to be able to run that make
<infinisil>
But nix-shell builds aws-sdk-cpp
<clever>
`%.o: %.c` will let you build any .o file from a .c of the same name and it only knows the name once you give it to make, or something else depends on it
<gchristensen>
aye, as documented
jtojnar has joined #nixos-dev
<gchristensen>
it'd be cool to have that s3 lib built by hydra in nixpkgs. not sure why it isn't
<infinisil>
At least I don't think it takes as long as I thought it would. Yesterday I stopped it when it was download the source of it, which is apparently pretty big
<infinisil>
gchristensen: /bin/sh: /nix/store/vywwsqjz3gpdrqc3hpilw8s043xzmmwc-libxml2-2.9.7-bin/bin/xmllint: No such file or directory
<infinisil>
Can't make even in a nix-shell
<gchristensen>
did you follow the `hacking` phase?
<globin>
infinisil: the build of aws-sdk-cpp used as dep in nix is just a subset (just s3 stuff)
<gchristensen>
./bootstrap.sh; configurePhase
<infinisil>
gchristensen: Nope
<gchristensen>
by "hacking phase" I mean the "hacking docs"
<infinisil>
Okay that worked
<gchristensen>
good :)
<infinisil>
I kind of assumed a /nix/store path would be installed by a nix command
johanot has quit [Quit: WeeChat 2.4]
<niksnut>
it would be nice to move the S3 store into a plugin
<niksnut>
we were discussing this in the context of GCS support
<samueldr>
gchristensen: maybe it has a way to list build targets; bash-completion completes build targets
drakonis has joined #nixos-dev
<Profpatsch>
Is ofborg only listening to a subset of Members now? cc gchristensen
<qyliss>
Idea: ofborg should suggest rebasing on staging (and include a step by step of how to do it without spamming CODEOWNERS) if somebody proposes rebuilding the world on master
<qyliss>
Actually, I guess this is the wrong channel for that
evanjs has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
evanjs has joined #nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]
evanjs| has joined #nixos-dev
orivej has quit [Ping timeout: 244 seconds]
phreedom has quit [Remote host closed the connection]
<{^_^}>
#68020 (by grahamc, 2 minutes ago, open): Vacation PR: multi-paged, styled, searchable docs with wrapper tooling and epubs for NixOS and Nixpkgs
ky1ko has joined #nixos-dev
<srhb>
gchristensen++ looks very pretty :)
<{^_^}>
gchristensen's karma got increased to 150
<gchristensen>
thanks :)
gchristensen is now known as gchrholiday
Jackneill has quit [Remote host closed the connection]
ky1ko has quit [Read error: Connection reset by peer]
<disasm>
fpletz: any update on gcc8?
<globin>
disasm: he's sitting next to me hacking away on it ;)
<disasm>
globin: awesome :)
evanjs| has quit [Ping timeout: 258 seconds]
johanot has joined #nixos-dev
<lassulus>
so many hard working people in the nixos community
<lassulus>
fpletz++
<{^_^}>
fpletz's karma got increased to 3
<disasm>
fpletz++
<{^_^}>
fpletz's karma got increased to 4
alp has quit [Ping timeout: 246 seconds]
alp has joined #nixos-dev
ixxie has quit [Ping timeout: 245 seconds]
<fpletz>
disasm: pushed, had to deal with some ocaml stuff that depended on old llvm versions
drakonis has joined #nixos-dev
johanot has quit [Quit: WeeChat 2.4]
<disasm>
fpletz++
<{^_^}>
fpletz's karma got increased to 5
jtojnar has quit [Ping timeout: 245 seconds]
<disasm>
fpletz: so now we wait on the hydra jobset?
<fpletz>
disasm: yeah, and see if we can merge it in that state
<fpletz>
merged master once more and triggered an eval 8min ago
<disasm>
fpletz: awesome, ping me when it's ready :)
<disasm>
fpletz: so if hydra has already built it, does it still need to go to staging first? or just target master?
drakonis1 has joined #nixos-dev
<globin>
direct to master
<fpletz>
yup, we can and imho should
<fpletz>
target master that is :)
drakonis has left #nixos-dev ["Leaving"]
drakonis has joined #nixos-dev
<disasm>
so, eval running for 12 mins. I'm guessing this needs to bootstrap everything just to eval it?
psyanticy has quit [Quit: Connection closed for inactivity]
<fpletz>
yeah, master apparently had a mass rebuild
jtojnar has joined #nixos-dev
drakonis has quit [Ping timeout: 245 seconds]
ky0ko has joined #nixos-dev
<jtojnar>
worldofpeace: working on the gtk+ renaming, do you think we should rename GTK+2 too?
<clever>
jtojnar: one thing that bothers me about gtk and glib stuff, is that the headers are in $out/include/foo/
<clever>
and you need to manually add that to -I, usually with pkgconfig
<clever>
the whole point of that, was to support conflicting versions co-existing in /usr/include/ and you just -I/usr/include/gtk-2 to select gtk 2
<clever>
but its pointless with nix, and just makes things even harder to automate
<jtojnar>
clever: should not all projects depending on them already do that?
<clever>
jtojnar: newcomers, that havent used gtk or nix before, and cant find any headers
<clever>
jtojnar: it would simplify everything if the headers where simply moved to $out/include (and the .pc file updated, so pkgconfig still works)
<jtojnar>
clever: well, you need to do the same on FHS systems
<jtojnar>
or use -I with hardcoded path
<clever>
on FHS systems, its a predictable -I/usr/include/gtk-2
<clever>
so a lot of guides just tell you to do that, and dont bother explaining pkgconfig
<clever>
i once spent 2 days trying to explain how to use pkgconfig to a guy in #nixos :P
<jtojnar>
well that is not very portable
ris has joined #nixos-dev
<jtojnar>
do we want to support use case that is not correct?
<clever>
hmmm, yeah
evanjs| has joined #nixos-dev
<worldofpeace>
jtojnar: great, we could rename GTK+2 as well, but really I think it was GTK 4 that was renamed to just "GTK"
<jtojnar>
worldofpeace: I think GTK 3 too
<jtojnar>
but not internally for BC reasons
<worldofpeace>
Yeah that would be a pain internally jtojnar hmm we should get a GTK 4 expression one fo these days
<jtojnar>
worldofpeace: another thing I want to do is get rid og Gtk#
pie_ has joined #nixos-dev
<worldofpeace>
jtojnar: ahh, so internally mentioning gtk with its major version?
<jtojnar>
worldofpeace: I meant the C#/Mono bindings
<jtojnar>
only like two apps use it and it is extremely outdated
<hyperfekt>
--add-root creates sequentially numbered symlinks if there a multiple results - is there a good reason for this? Could they be in a folder instead? Or a single root pointing to a text file in the store referencing all the results?
<worldofpeace>
Oh Gtk Sharp, we even have things that use this? :D
<worldofpeace>
hmm doesn't tomboy use Gtk#?
<jtojnar>
worldofpeace: yeah, though the new version switched to FreePascal 😵️
drakonis has joined #nixos-dev
<emily>
haha, what?
<emily>
not, like, Vala even?
<worldofpeace>
jtojnar: huh, maybe because of windows? I haven't checked in a while how things are doing there (mostly because I lack the cares for it)
evanjs- has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
evanjs- has joined #nixos-dev
<thoughtpolice>
Lazarus with Free Pascal is honestly crazy good, though. No exaggeration.
Jackneill has joined #nixos-dev
<thoughtpolice>
In terms of ease of use and hitting the big three major platforms without having to ship complex dependencies and small footprint, it's pretty much unrivaled. A portable note taking app seems like a very good fit for those needs.
<disasm>
only 67k more things to build. Not sure I'm allowed to complain about IOHK mass rebuilds anymore, lol
Jackneill has quit [Remote host closed the connection]
__monty__ has quit [Quit: leaving]
<worldofpeace>
jtojnar: __NIXOS_SET_ENVIRONMENT_DONE being set means that the set-environment script ran right? I'm looking at https://github.com/NixOS/nixpkgs/issues/48255#issuecomment-429750590 and I noticing in pantheon's greeter that the variable isn't set if I fudge the main function with Environment.list_variables.
<worldofpeace>
And dumping get_system_data_dirs doesn't have the directories to the profiles.
<jtojnar>
worldofpeace: sorry, no idea that was more of a hednng's thing
<jtojnar>
are you sure it is not stripped by lightdm?
<worldofpeace>
That's what I'm thinking. Almost all lightdm greeters seem to have an issue with themes, and I think it'd work as expected if XDG_DATA_DIRS had /run/current-system/sw/share etc.
<worldofpeace>
I'm seeing if there's similar code to what's in gdm for reset-environment.patch
<jtojnar>
I would expect it to be in lightdm itself