sphalerite changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 19.09 now in beta! https://discourse.nixos.org/t/nixos-19-09-feature-freeze/3707 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 19.09 RMs: disasm, sphalerite | https://logs.nix.samueldr.com/nixos-dev
drakonis has joined #nixos-dev
<infinisil> jtojnar: You mean like, per-user ,<commands> that are synced with your github replies?
<jtojnar> infinisil: I do not need per-user, the bot's list would be enough for me
<infinisil> Ah, so sync from bot -> github
<jtojnar> yup
<infinisil> The commands are available through https://nixbot.infinisil.com/global/commands/commands/ at least, but it doesn't look like the github api allows you to control saved replies
evanjs- has quit [Ping timeout: 276 seconds]
ris has quit [Ping timeout: 276 seconds]
drakonis has quit [Ping timeout: 265 seconds]
init_6 has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 245 seconds]
<jtojnar> gchristensen: what do you think about https://github.com/NixOS/nixpkgs/pull/68181?
<{^_^}> #68181 (by jtojnar, 1 week ago, open): doc: Disable wrapping source
drakonis1 has joined #nixos-dev
bgamari has quit [Ping timeout: 246 seconds]
bgamari has joined #nixos-dev
layus has quit [Quit: ZNC 1.7.3 - https://znc.in]
layus has joined #nixos-dev
drakonis1 has quit [Quit: WeeChat 2.4]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 264 seconds]
init_6 has quit []
cdepillabout has joined #nixos-dev
cdepillabout has quit [Quit: Leaving]
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
Synthetica has joined #nixos-dev
orivej has quit [Ping timeout: 268 seconds]
Jackneill has joined #nixos-dev
<teto> qyliss: the function is part of a rehaul to better integrate the kernel in nixos. (for instance I have code to build a kernel config from software requirements, e.g., enabling bpf enables CONFIG_BPF etc. ). I am tryingto clean this up and iteratively upstream it. Just to focus on that peculiar function, even if we only use structured config, the generated config might not respect that. The current
<teto> requiredKernelConfig is almost useless as it is, so my plan is to make it effective first, than proceed on with the rest
init_6 has joined #nixos-dev
<fpletz> teto++
<{^_^}> teto's karma got increased to 3
johanot has joined #nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]
init_6 has quit [Ping timeout: 268 seconds]
__monty__ has joined #nixos-dev
orivej has joined #nixos-dev
Shados has quit [Quit: Shados]
orivej has quit [Ping timeout: 245 seconds]
johanot has quit [Quit: WeeChat 2.4]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 268 seconds]
<Taneb> What's with all the aborted builds on the 19.09 jobset evals?
<Taneb> Looks like one of the builders is inaccessible?
orivej has joined #nixos-dev
davidtwco has quit []
davidtwco has joined #nixos-dev
<hyperfekt> Is there any best practice for update scripts? Just looking through nixpkgs I see at least 5 different ways they're done...
<emily> oh yeah... I dreamt that I set up update scripts for all my packages, but that was just a dream. I still have to actually do it :(
<clever> emily: i once discovered that a bug i had "fixed", wasnt fixed, and there was zero trace of the fix on any machine i was using
<clever> and i was able to re-type the entire fix by memory
<clever> still no clue how the fix undid itself, did i `git checkout|reset` by mistake? did i fix it in my dreams?
<hyperfekt> Do I use update-source-version? Or is that legacy stuff?
<emily> I think that's new stuff?
<emily> jtojnar had some pointers when I asked in here and update-source-version was one of them
<emily> the other was something in maintainers/
<jtojnar> hyperfekt, emily: update-source-version is a low level tool for updating the expression
<jtojnar> you can call it manually, or write a passthru.updateScript that finds a latest version and calls update-source-version with it
<jtojnar> and then update all your packages with `nix-shell maintainers/scripts/update.nix`
<hyperfekt> Alright, thanks. I guess if what I'm doing is not right review will tell me (hopefully). :)
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
evanjs- has joined #nixos-dev
<gchristensen> jtojnar: it is the age old question, isn't it
orivej has quit [Ping timeout: 245 seconds]
evanjs- has quit [Quit: ZNC 1.7.4 - https://znc.in]
evanjs- has joined #nixos-dev
orivej has joined #nixos-dev
psyanticy has joined #nixos-dev
<sphalerite> ,avoid-the-review-spam If you're retargetting a pull request and want to avoid notifying the code owners of everything that was changed between current master and current staging, first rebase it against the merge base of master and staging, e.g. `git rebase --onto $(git merge-base origin/master origin/staging) master` if changing from master to staging.
<sphalerite> ,avoid-the-review-spam = If you're retargetting a pull request and want to avoid notifying the code owners of everything that was changed between current master and current staging, first rebase it against the merge base of master and staging, e.g. `git rebase --onto $(git merge-base origin/master origin/staging) master` if changing from master to staging.
<{^_^}> avoid-the-review-spam defined
<sphalerite> ,avoid-the-review-spam = If you're retargetting a pull request and want to avoid notifying the code owners for all the unrelated changes, first rebase it against the merge base of master and staging, e.g. `git rebase --onto $(git merge-base origin/master origin/staging) master` if changing from master to staging.
<{^_^}> avoid-the-review-spam redefined, was defined as If you're retargetting a pull request and want to avoid notifying the code owners of everything that was changed between current master and current staging, first rebase it against the merge base of master and staging, e.g. `git rebase --onto $(git merge-base origin/master origin/staging) master` if changing from master to staging.
<gchristensen> maybe ofborg could learn how to retarget
<averell> why does that work?
<sphalerite> averell: because the merge base for the two branches is the last common commit, and that way the new branch will only have one commit that's new to both master and staging
<sphalerite> (or n commits, but the commits you're actually interested in)
<averell> i still don't get it. if i rebase from a PR against release-x directly onto master for example, it should only have one extra commit on top of master too?
<sphalerite> averell: yes, but between force-pushing the branch and retargetting the PR on github, there'll be a massive diff and github will oh-so-smartly request reviews from all the people owning code that's in that diff
orivej has quit [Ping timeout: 240 seconds]
<averell> ah. i guess that's another reason why staging/master are merged into each other. so for release, i'd have to rebase backwards onto the branch-off point and hope for no conflicts?
<gchristensen> for release, you have to cherry-pick
<sphalerite> averell: ideally, yes, you'd rebase on the branch-off points and have no conflicts.
<sphalerite> gchristensen: that still has the notification spam issue
<gchristensen> it does?
<averell> makes sense if it comes from the "retargeting-diff" rather than the PR "net-diff", so to speak :)
<sphalerite> gchristensen: yes — because between the force push and the retarget, you'll be merging the release branch plus your work into master, or master plus your work into the release branch.
<gchristensen> I was referring to the merge-base and targeting staging
<gchristensen> ie: implementing the instructions you added to a factoid
<sphalerite> gchristensen: alternatively, the rebase and the retarget could be done atomically, but I don't know of a facility for that in github
<sphalerite> gchristensen: oh, I interpreted this as averell talking about a release branch as another alternative to staging in this case.
<averell> yes i was, because it's the same problem (but worse, because you're going backward)
<sphalerite> for backports, yeah, cherry-pick (or git rebase --onto release-xx.yy master) and a new PR
<averell> specifically i had a PR against 19.09 but had to retarget master. in the future, that would only be possible if a rebase onto the merge-base is conflict-less.
orivej has joined #nixos-dev
<gchristensen> infinisil: I think the znapzend module should expose both the src_plan and dest_plan options: I want to keep more snapshots on my backup device than I do on the source device, for example
<sphalerite> gchristensen: huh? doesn't it already?
<sphalerite> at least, I have that setup. Hang on
<sphalerite> gchristensen: set a more retainy plan on the destination than on the source, and it will delete the snapshots on the source after sending them to the destination (and not delete them from the destination)
<gchristensen> how do you do that?
<gchristensen> I have only configured znapzend on the sending side
<sphalerite> gchristensen: same. Hang on
<sphalerite> gchristensen: my config looks like this https://gist.github.com/lheckemann/12ae46e1e3d952b91a9a3090fc520645
<gchristensen> oh wow
<gchristensen> I completely missed the second "plan" definition when reading the source and when reading the docs.
<sphalerite> aah :)
orivej has quit [Ping timeout: 240 seconds]
<gchristensen> also if I may be so bold, the "duration=>frequency" syntax drives me nuts :P
<sphalerite> +1
<gchristensen> services.znapzend.pure should also probably default to true
<jtojnar> gchristensen: I could not really find any good arguments against it other than GitHub reviews having line based scope
<infinisil> gchristensen: However, unfortunately plans that have fewer snapshot on remotes don't work well.. https://github.com/oetiker/znapzend/issues/396
<{^_^}> oetiker/znapzend#396 (by rcproam, 43 weeks ago, open): Documentation not clear on how SRC and DST plans relate to send/receive schedule
<infinisil> Well they work, but they send the snapshots to the remote whenever a snapshot is taken
<gchristensen> infinisil: they eventually get pruned, right? it just means that all remotes have all the newest ones always, until they are considered old?
<infinisil> Yeah
<gchristensen> I think I can handle that
orivej has joined #nixos-dev
<worldofpeace> jtojnar: So I'm thinking of integrating #68492 today but I noticed something weird on a system that I upgraded to it with
<{^_^}> https://github.com/NixOS/nixpkgs/pull/68492 (by worldofpeace, 1 week ago, open): Introduce environment.profileRelativeSessionVariables
<worldofpeace> jtojnar: somehow https://github.com/NixOS/nixpkgs/pull/68492/commits/486eb9196d2dc3e8cf1e622fc7d0ee3323f76a58 did weird stuff to the cursor in the session
<worldofpeace> jtojnar: like hovering over certain windows there'd suddenly be no cursor. Couldn't reproduce in a VM
<jtojnar> worldofpeace: Xwayland?
<worldofpeace> jtojnar: hmm, that sound about right
<worldofpeace> i'm going to double check further, since I gave really vague info :P
<jtojnar> worldofpeace: https://www.x.org/releases/current/doc/man/man3/Xcursor.3.xhtml no mention of XDG_DATA_DIRS, but the man page can also be outdated, or it might not even be the correct component
<worldofpeace> jtojnar: guess archwiki says gdm ignores XCURSOR_PATH https://wiki.archlinux.org/index.php/GDM#Changing_the_cursor_theme
<jtojnar> default theme was renamed to hicolor ages ago
<disasm> need a review: https://github.com/NixOS/nixpkgs/pull/69005 this got it to build locally for me.
<{^_^}> #69005 (by disassembler, 11 hours ago, open): linuxPackages.ply: add rsync to native build inputs
{^_^} has quit [Remote host closed the connection]
<jtojnar> lol, arch wiki asking me to enter the output of `pacman -V|base32|head -1` into captcha
<jtojnar> good thing we have pacman in nixpkgs
<gchristensen> :D
<worldofpeace> those archers and their arch specific captchas
{^_^} has joined #nixos-dev
<worldofpeace> huh tried it out on yet another machine, couldn't reproduce. I'm going to assume it's just an outlier jtojnar.
<Taneb> jtojnar: I remember back when I was on Ubuntu I tried to do "apt install pacman"... and got an arcade game
<jtojnar> worldofpeace: 👍️
<jtojnar> we have issue tracker for that
orivej has quit [Ping timeout: 265 seconds]
<worldofpeace> jtojnar: I'll be sure to check again after we're ready to integrate 3.34
<jtojnar> worldofpeace: yeah, GTK uses Xcursor on X11: https://gitlab.gnome.org/GNOME/gtk/blob/3.24.11/gdk/x11/gdkcursor-x11.c#L475
<jtojnar> worldofpeace: or just make it follow the spec properly
Shados has joined #nixos-dev
orivej has joined #nixos-dev
<averell> seems the disk is full again on some builders: https://hydra.nixos.org/build/101422172 but maybe it's already known/fixed.
<gchristensen> ack
<gchristensen> I'll take a look shortly
qyliss has quit [Quit: bye]
qyliss has joined #nixos-dev
ixxie has joined #nixos-dev
<worldofpeace> jtojnar: did #69031
<{^_^}> https://github.com/NixOS/nixpkgs/pull/69031 (by worldofpeace, 4 minutes ago, open): nixos/xdg/icons: match XCURSOR_PATH spec
__monty_2 has joined #nixos-dev
__monty_1 has joined #nixos-dev
__monty_1 has quit [Client Quit]
__monty_2 has quit [Client Quit]
justanotheruser has quit [Ping timeout: 240 seconds]
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 268 seconds]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 276 seconds]
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 276 seconds]
janneke has quit [Quit: janneke quits Mes'sing]
janneke has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
<hyperfekt> jtojnar: Did you manage to solve the Arch captcha? It's not accepting mine, might have the wrong pacman version...
orivej has quit [Ping timeout: 276 seconds]
<jtojnar> hyperfekt: pacman -V appears to be an empty line
<jtojnar> the first line of output of
<jtojnar> $ nix run -f 'channel:nixos-unstable' pacman -c pacman -V|base32|head -1
<jtojnar> BIQC4LJNFYQCAIBAEAQCAIBAEAQCAIBAEAQCAICQMFRW2YLOEB3DKLRRFYZSALJANRUWEYLMOBWS
<hyperfekt> I get the same thing but it won't accept that as a captcha...
<jtojnar> weird, it accepted it for me
<hyperfekt> I don't know how or why but now it worked. Strange.
<drakonis> what are you folks trying to do with pacman?
<hyperfekt> drakonis: register on the premier Linux wiki
<drakonis> hrm, sounds like fun
<drakonis> have you tried bootstrapping a arch container just to do that?
<drakonis> seems like a safer bet
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 240 seconds]
<jtojnar> worldofpeace: I would write it but with semester just having started, I do not have enough patience to manipulate strings in pure C
<jtojnar> And I won’t even say RIIR since with Xorg not having a future, it is probably not a good use of anyone's time.
<worldofpeace> lol jtojnar agree 100%, I wouldn't wish anyone to manipulate strings in pure C. especially for Xorg :D
<simpson> jtojnar: Joke's gonna be on you when you say the same thing in 2030~
<gchristensen> ~~what is Xorg?~~
<andi-> Legacy technology. Only greybeards are using it.
<drakonis_> andi-, we're stuck with xorg until we can move everyone into wayland
<gchristensen> how long will we wait to do that after redhat stops maintaining xorg?
<drakonis_> there's roughly two years left in red hat maintaining xorg for the public
<drakonis_> then it will be maintained exclusively for rhel
<drakonis_> actually, the rhel8 cycle goes until 2024
<drakonis_> ughh, its 2029, i read the wrong number
<drakonis_> a decade until red hat ends xorg's life forever
<samueldr> moving everyone to wayland is going to be hard; the software they use will need to move... for "leafy" software, like applications, I guess Xwayland will do, but that still leaves DEs and WMs
Jackneill has quit [Remote host closed the connection]
<drakonis_> the DEs are already moving to wayland
<samueldr> and there's what some would call "big hacks" kind of software, but that is sometimes central to some people's use that is going to stick rea;;y hard
<samueldr> stuff like synergy / barrier
<simpson> Hopefully we'll have an entirely new stack of everything by then. Could you *imagine* having to use software as bad as the stuff we've got right now on the desktop, in a decade?
<emily> gnome is already pretty far ahead on the wayland train, both applications and DE
<drakonis_> the stack is already under way
<emily> fedora defaults to wayland for it
<drakonis_> kde has wayland as its primary focus now
<emily> given how common gnome is on the linux desktop, I'd say that's a pretty big milestone
<drakonis_> mir is a wayland compositor and it is used by mate
<emily> I run sway and it's rough around the edges, but i3 is very popular too and it makes a decent implementation of that model.
<samueldr> a good chunk of it is in a good state
<drakonis_> there's a few wayland backends for WMs
<drakonis_> someone's writing compiz for wayland
<drakonis_> there's wlroots
<emily> overall I'd say Wayland is doing well, just a few years later than I'd have liked
<drakonis_> wayland has pipewire and that one thing that lets you pass it over the wire
<drakonis_> for the folks that like using x over ssh
* emily wants xpra for wayland
<samueldr> I want synergy/barrier for wayland :/
<drakonis_> they already wrote that
<samueldr> drakonis_: wrote "that" what?
<drakonis_> xpra
<drakonis_> waypipe
<niksnut> x11 -> wayland transition will probably take longer than python2 -> python3
<emily> to qualify as xpra you also need intelligent compression, simple end-user experience, etc.
<samueldr> that's mostly what I think too, that X will stick for way long (pun intended)
<samueldr> (and note that I don't mean "I want X to stay", but that I observe it's likely to stick)
<drakonis_> X will slowly get replaced due to bitrot
<drakonis_> because support will slowly decrease over time
<drakonis_> python 2 still works because its a language runtime, you can still get it to work with anything
ris has joined #nixos-dev
<drakonis_> X will stop functioning with newer hardware over time and bugs will pop up
drakonis_ is now known as drakonis
<niksnut> well, first wayland will have to work on current hardware
<niksnut> like nvidia
<drakonis> red hat was working on that
<drakonis> nvidia is a pain.
<drakonis> i wish they'd just do like amd and upstream drivers
<drakonis> keep your cuda stack private or whatever, but just write drivers that arent wrappers around windows drivers
<niksnut> yeah
<drakonis> they're already writing drivers for their arm devices
<drakonis> which is so strange, if you're already going through the effort of doing this, why not release drivers for the regular hardware?
<drakonis> why are they so afraid of hardware passthrough?
<jtojnar> niksnut: what do you think about stopping hard wrapping the docs source?
<{^_^}> #68181 (by jtojnar, 1 week ago, open): doc: Disable wrapping source
<gchristensen> I don't love that massively long lines tend to appear in documentation when there is no limit. what if there was a longer limit, 120 for example? will that cause everything to be rewrapped?
<infinisil> gchristensen: Which docs?
<samueldr> all of them
<samueldr> (it's the linked PR)
<infinisil> Ahh
ixxie has quit [Ping timeout: 265 seconds]
<jtojnar> gchristensen: well does not everything already support soft-wrapping? even nano does
<jtojnar> gchristensen: and yes, everything will be rewrapped, but it is better when it will be rewrapped once than every time the docs are edited
<jtojnar> I have edited gnome.xml countless times in last two weeks and each time every section I touched was re-flowed completely
<gchristensen> that isn't nice
<gchristensen> by deleting the line wrap option, does it cause a reflow?
<jtojnar> gchristensen: yes
<gchristensen> can you add a commit doing that?
<jtojnar> okay
<jtojnar> I was waiting for some consensus
<gchristensen> I'm +1
<gchristensen> but I'd like to see what it does first
<jtojnar> gchristensen: will do once pandoc rebuilds
<gchristensen> joy :)
<jtojnar> but it will basically rewrite every text node so that there are no \n or repeated whitespace characters
drakonis has quit [Read error: Connection reset by peer]
<gchristensen> on all text elements except for ones with the expectation of verbatim processing
drakonis has joined #nixos-dev
<jtojnar> yup
<gchristensen> back in like 45min :)
<worldofpeace> jtojnar: two of the todo's were done for #68552, didn't have much more time to check. Think we should merge to avoid conflicts?
<{^_^}> https://github.com/NixOS/nixpkgs/pull/68552 (by jtojnar, 6 days ago, open): gtk3.setupHook: clear icon-theme.cache in preFixup
justanotheruser has joined #nixos-dev
<jtojnar> worldofpeace: will work on the docs now
<worldofpeace> jtojnar: fantastic
jtojnar2 has joined #nixos-dev
<jtojnar2> worldofpeace: I am surprised it does not conflict with the formatting changes from meson vars PR
<drakonis> ah, how have i not noticed the flakes pr on nixpkgs
<worldofpeace> jtojnar2: :D total accident that one. had to rewrite the commit to backport
evanjs| has joined #nixos-dev
Cale has quit [Ping timeout: 252 seconds]
evanjs| has quit [Client Quit]
evanjs| has joined #nixos-dev
<jtojnar> I am thinking about building markdown docs using cmark instead of pandoc and then using XSLT to transform the produced XML AST
evanjs| has quit [Quit: ZNC 1.7.4 - https://znc.in]
justanotheruser has quit [Read error: Connection reset by peer]
Cale has joined #nixos-dev
justanotheruser has joined #nixos-dev
evanjs| has joined #nixos-dev
psyanticy has quit [Quit: Connection closed for inactivity]
evanjs| has quit [Quit: ZNC 1.7.4 - https://znc.in]
<gchristensen> jtojnar: sounds nice
<jtojnar> gchristensen: pushed the formated files
evanjs- has quit [Quit: ZNC 1.7.4 - https://znc.in]
justanotheruser has quit [Read error: Connection reset by peer]
<gchristensen> jtojnar: what do you think about the result?
<jtojnar> gchristensen: looks good to me https://i.imgur.com/9QSeWBa.png
<gchristensen> cool
<gchristensen> let's merge right away, backport 641f6356d387ef493812de23f75114effc0cc398, reformat both doc sets on 19.09, and send that PR
<jtojnar> on it
<gchristensen> thank you :) good cohice
<gchristensen> okay, going to mow the lawn for maybe the last time of the season. go ahead and merge the backport/reformat when its good
<jtojnar> have a good mow
justanotheruser has joined #nixos-dev
justanotheruser has quit [Read error: Connection reset by peer]
qyliss has quit [Quit: bye]
qyliss has joined #nixos-dev
justanotheruser has joined #nixos-dev
qyliss has quit [Quit: bye]
justanotheruser has quit [Read error: Connection reset by peer]
<jtojnar> worldofpeace: I think the icon-theme.cache might be better suited to the planned `xdg.xml`
<worldofpeace> jtojnar: the setup hook is in gtk though
<jtojnar> yeah, I will add a small note to that
<jtojnar> gchristensen: do we have olinkDB working for nixpkgs → nixos?
<gchristensen> jtojnar: ie: referring to nixpkgs from nixos?
<jtojnar> the other way around
<gchristensen> hmm not sure
<gchristensen> in the new stuff I'm building, I think we could do that without much trouble
<gchristensen> let me look in to it. I have other bugs to fix in olinkdb in that PR
<jtojnar> even better would be linking to nix doc but that probably will not be possible when they are in different repos
<gchristensen> I think we can make that work, too, but ... let's see.
justanotheruser has joined #nixos-dev
justanotheruser has quit [Read error: Connection reset by peer]
Jackneill has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
<ajs124> If I do builtins.fetchGit { url = <bla>; } and <bla> points to a symlink, the outPath is that symlink. Is that expected behaviour?
drakonis has quit [Quit: Leaving]
justanotheruser has joined #nixos-dev
justanotheruser has quit [Client Quit]
<gchristensen> seems surprising to me, ajs124
<worldofpeace> ajs124: that's more of a #nixos question
<gchristensen> might be a bug
drakonis has joined #nixos-dev
<ajs124> gchristensen: a look at the bugtracker seems to point to fetchGit on local paths being "interesing" anyways -.-
<{^_^}> nix#2936 (by nomeata, 14 weeks ago, open): Document builtins.fetchGit when used on a local path
<gchristensen> how curious
<gchristensen> but also seems really weird to be using fetchGit against a local path which isn't a bare repo
<ajs124> why?
<gchristensen> I didn't know git supported such a thing
<ajs124> it most definitely does
<gchristensen> I believe you
<ajs124> I want my config repo to be included in ISOs that I build
<ajs124> Which works fine on my hydra, but not so much for regular builds
<ajs124> I'm not sure if it ever worked, tbh
<gchristensen> do you need to fetchGit the config repo, or can you simply refer to itself by path?
<ajs124> The idea behind the fetchGit was that I'd get what's in git, instead of the unclean worktree
<ajs124> Which, as it turns out, is apparently not how this works.
<gchristensen> that is strange indeed :)
<ajs124> I guess I can refer to is by path and "build" it in the derivation with git >.<
<gchristensen> however, it seems risky to build from one set of configs (unclean work tree) and have contained in the result another set of configs (clean work tree)
<gchristensen> I wonder why fetchGit works so strangely.
<ajs124> I can live with that risk^^
<ajs124> I've read the fetchGit code, so I _should_ know
<ajs124> but it's been a few months
<ajs124> hm. I don't see how symlinks would factor into this.
<gchristensen> yeah, this just explains the unclean bit
drakonis has quit [Ping timeout: 258 seconds]
<gchristensen> what does `stat ./your-fetchgit-urls-source` say?
<clever> ajs124: it tests if the given path is a directory
drakonis has joined #nixos-dev
<gchristensen> hrm
<ajs124> wait. even if I do src = ./.., I get a symlink. I... I think I'm going to bed.
<clever> ajs124: what turns into a symlink?
<clever> or was the entity always a symlink?
<ajs124> clever: it's always been a symlink. I guess for some reason I expected it to be "resolved". I guess that expectation was wrong.
<clever> yeah, nix will just copy symlinks as-is
<clever> if they are absolute, or .. too far up, bad things happen
<ajs124> so err, is there any way I can make it not do that? as in, can I somehow force it to "follow" the link?
<clever> nope
orivej has joined #nixos-dev
<ajs124> then I'm actually just going to go sleep now >.<
<jtojnar> worldofpeace: I wonder if icon-theme.cache could contain absolute paths so that we could share a single one for multiple profiles
__monty__ has quit [Quit: leaving]
<jtojnar> but not sure who would generate them then
<jtojnar> or maybe I just need to clean up XDG_DATA_DIRS
<jtojnar> I also wonder how many packages have icons other than their own
<jtojnar> s/own/app icon/
<jtojnar> (as a part of XDG compatible icon theme)
<jtojnar> then icon-theme.cache could be helpful for them to be picked up by wrapGAppsHook
<jtojnar> hmm over 50000 ENOENTs just when starting Totem
<jtojnar> stracing gnome-mahjongg wrapper with its own datadir commented shows no icon lookup
<jtojnar> without it commented out, the icon dir is probed and I see several getdents calls but the icon is looked up only in the correct directory, as far as I can tell
<worldofpeace> You're running totem with strace trying to inspect icon lookup right jtojnar ?
<jtojnar> worldofpeace: yup
<jtojnar> switched to mahjongg for simplicity
<worldofpeace> You're expecting commenting out it's own datadir in the wrapper to see icon lookup in the system profiles right?
<jtojnar> worldofpeace: yup
<jtojnar> thinking about the icon-theme.cache file in the icon theme packages, is not the only use case adding themes to apps' inputs?
<jtojnar> so we are against that, while still promoting a practice that supports it
orivej has quit [Ping timeout: 265 seconds]
<jtojnar> wait, if the gtk.iconCache uses environment.extraSetup, does it apply to nix-env?
<worldofpeace> jtojnar: no, I actually don't think any of those caches or databases are there for nix-env
<worldofpeace> I recall finding this out when trying to generate a desktop file cache for bamf
<jtojnar> worldofpeace: I thought the xdg modules & co. applied to all profile generation for some reason
<jtojnar> not sure how I came to that conclusion
<worldofpeace> I'm not sure what should be done for nix-env, probably end it :P
<worldofpeace> merge #69050 to gnome-3.34 jtojnar?
<{^_^}> https://github.com/NixOS/nixpkgs/pull/69050 (by dtzWill, 1 hour ago, open): gtk3: 3.24.10 -> 3.24.11
<jtojnar> worldofpeace: +1
orivej has joined #nixos-dev
<worldofpeace> and rebuild all over again :D
<dtz> Ty, wasn't sure. But good to rebuild together. Does that branch have glib and glibmm 2.62.0 also? Haha the rebuilds, all the rebuilds! But I'd guess those are in, just mentioning while ya rebuilding anyway :)
<worldofpeace> glibmm, hmm
<gchristensen> oh fiddlesticks, we're on docbook-xsl 1.79.2, and upstream has a 2.3.16!
<gchristensen> oh. no big deal. different development line.
<dtz> Yeah glibmm was today :).
<worldofpeace> you're so up to date dtz do you have a script, or are you just part bot like gchristensen is now?
<dtz> Beep boop boop...
<dtz> ... meow
<dtz> Script for compulsively updating git trees of projects I use. Slowly that grows and now I'm addicted to the update.
drakonis has quit [Ping timeout: 268 seconds]
<worldofpeace> But it's one of those addictions everyone can benefit from dtz thanks
drakonis has joined #nixos-dev