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
<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
<{^_^}>
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
<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
<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?
<{^_^}>
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>
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?
<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 :)