sphalerite changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 19.03 released! https://discourse.nixos.org/t/nixos-19-03-release/2652 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html https://r13y.com | 19.03 RMs: samueldr,sphalerite | https://logs.nix.samueldr.com/nixos-dev
<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
<edef> yes, this
<qyliss> (I know you're not a fan, but https://drewdevault.com/2019/05/24/What-is-a-fork.html makes a very good point IMO)
<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.
<edef> yeah
<infinisil> qyliss: https://github.com/NixOS/nixpkgs/pull/59990 probably
<{^_^}> #59990 (by basvandijk, 19 weeks ago, open): Support patching nixpkgs
<edef> but we have that for nixpkgs, right
<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]
phreedom has joined #nixos-dev
<infinisil> Well here it is: https://github.com/NixOS/nix/pull/3080
<{^_^}> nix#3080 (by Infinisil, 14 seconds ago, open): docs: Note that tryEval doesn't do deep evaluation
ixxie has joined #nixos-dev
Jackneill has joined #nixos-dev
<niksnut> infinisil: shrug, I don't think it's unreasonable to expect people to check that changes are correct, just like any other change
Jackneill has quit [Ping timeout: 245 seconds]
Jackneill has joined #nixos-dev
abbradar is now known as abbradar[m]
drakonis1 has quit [Ping timeout: 264 seconds]
drakonis has joined #nixos-dev
__monty__ has joined #nixos-dev
noonien has joined #nixos-dev
johanot has joined #nixos-dev
<qyliss> Do we have a guideline for how many rebuilds to staging instead of master?
<qyliss> There are a couple of PRs to Ruby I want to merge. One has ~2000 rebuilds, one has ~500. Should both of these go to staging?
ky0ko has quit [Ping timeout: 264 seconds]
<etu> disasm, infinisil, Mic92: you got requested to look at this: https://github.com/NixOS/nixpkgs/pull/55510
<{^_^}> #55510 (by florianjacob, 29 weeks ago, open): nixos/printers: declarative configuration
<andi-> qyliss: We had that discussion some time ago and someone came up with ~2500 as a "limit"
<andi-> not sure who that was or if that is the final number but I've been trying to stick with it
<teto> I would like to submit my fork of https://github.com/NixOS/nixops/pull/1191, having https://github.com/NixOS/nixops/pull/1191 in would be nice though
<{^_^}> nixops#1191 (by teto, 1 week ago, open): doc: fix paths
<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
jtojnar has quit [Quit: jtojnar]
<gchristensen> yea, so there is this: https://nixos.org/nix/manual/#chap-hacking and I don't know if `make` has a standard way of listing build targets
<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
<Profpatsch> Because aherrmann’s query didn’t do anything here but we are both listed as “Member” https://github.com/NixOS/nixpkgs/pull/66723#issuecomment-527435472
<gchristensen> it never listed for members, only known-users and trusted-users in the ofborg repo
<Profpatsch> Ah, I remember
<worldofpeace> jtojnar: https://github.com/NixOS/nixpkgs/pull/67957#issuecomment-527279639 should glib-pacrunner be wrapped?
<jtojnar> worldofpeace: not sure, let me check the source
<worldofpeace> can someone with access to the nix repo move #67945 to its tracker?
<{^_^}> https://github.com/NixOS/nixpkgs/issues/67945 (by volth, 1 day ago, open): `__structuredAttrs = true;` breaks `preferLocalBuild` and `allowSubstitutes`
<worldofpeace> thanks gchristensen ✌️
drakonis has quit [Quit: WeeChat 2.4]
<gchristensen> :)
ixxie has quit [Ping timeout: 244 seconds]
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 258 seconds]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 252 seconds]
<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]
phreedom has joined #nixos-dev
ixxie has joined #nixos-dev
orivej has joined #nixos-dev
<worldofpeace> jtojnar: good, that should stop the "attack" it can have on the PR queue. oh how many we had to close that one time :P
drakonis has joined #nixos-dev
drakonis1 has joined #nixos-dev
drakonis_ has quit [Ping timeout: 245 seconds]
drakonis has quit [Ping timeout: 252 seconds]
drakonis1 has quit [Ping timeout: 252 seconds]
Jackneill has quit [Ping timeout: 245 seconds]
Jackneill has joined #nixos-dev
evanjs| has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
evanjs| has joined #nixos-dev
psyanticy has joined #nixos-dev
evanjs| has quit [Quit: ZNC 1.7.4 - https://znc.in]
evanjs| has joined #nixos-dev
evanjs| has quit [Client Quit]
evanjs| has joined #nixos-dev
<gchristensen> my last PR before vacation is in https://github.com/NixOS/nixpkgs/pull/68020
<{^_^}> #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 [Ping timeout: 244 seconds]
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
ris has quit [Ping timeout: 246 seconds]
jtojnar has quit [Quit: jtojnar]
jtojnar_ has joined #nixos-dev
drakonis has quit [Ping timeout: 258 seconds]
evanjs| has joined #nixos-dev
<worldofpeace> they do use clearenv()