<jtojnar>
the longest variant has around 600 files changed
<gchristensen>
what is the motivation for this change?
<jtojnar>
consistency, simplification of update script
<gchristensen>
internal consistency with other gnome packages?
<jtojnar>
yes
<gchristensen>
cool
vcunat has quit [Quit: Leaving.]
<jtojnar>
is it possible to mark the legacy aliases somehow?
<Dezgeg>
I think if your regex used to replace them matched only on word boundaries you'd get rid of all the false positives
orivej has quit [Ping timeout: 240 seconds]
<Dezgeg>
then the remaining problem that I could see in that commit is you modify the autogenerated hackage-packages.nix but not the file that generates it
<jtojnar>
and now I feel bad
goibhniu has joined #nixos-dev
Lisanna has quit [Remote host closed the connection]
mbrgm has quit [Ping timeout: 268 seconds]
mbrgm has joined #nixos-dev
Lisanna has joined #nixos-dev
{^_^} has joined #nixos-dev
jtojnar_ has joined #nixos-dev
jtojnar has quit [Ping timeout: 240 seconds]
jtojnar_ is now known as jtojnar
yegortim1 has joined #nixos-dev
yegortimoshenko has quit [Ping timeout: 255 seconds]
yegortim1 has quit [Remote host closed the connection]
yegortim1 has joined #nixos-dev
<gchristensen>
jtojnar: in the future, the log viewer will identify what machine the logs are from. example: https://logs.nix.ci/?attempt_id=-ofborg-&key=nixos%2Fnixpkgs.35287 -- the "metadata found" bit in the -ofborg- pane. not great for now, samueldr is going to make it nicer later this week :)
<jtojnar>
cool
<gchristensen>
hopefully that'll make it possible to debug weird machine failures next time :(
garbas has quit [Quit: WeeChat 1.9.1]
<simpson>
gchristensen: If I know which packages are likely to need tests with a PR, should/can I ping ofborg for that in the PR body, or does it need to be you in a comment?
yegortim1 has quit [Remote host closed the connection]
yegortim1 has joined #nixos-dev
jtojnar has quit [Ping timeout: 240 seconds]
pie_ has quit [Ping timeout: 240 seconds]
ma27 has joined #nixos-dev
jtojnar has joined #nixos-dev
ma27 has quit [Ping timeout: 265 seconds]
ma27 has joined #nixos-dev
__Sander__ has joined #nixos-dev
ma27 has quit [Ping timeout: 240 seconds]
<Profpatsch>
zimbatm: When I have a proposal for something that could turn into an RFC somehow, where should I put it?
<Profpatsch>
aka is it possible to activate Issues on the rfc repo? :P
pie_ has joined #nixos-dev
pie_ has quit [Ping timeout: 276 seconds]
Nadrieril has quit [Read error: Connection reset by peer]
Nadri has joined #nixos-dev
globin has quit [Ping timeout: 264 seconds]
globin has joined #nixos-dev
_rvl has quit [Ping timeout: 240 seconds]
_rvl has joined #nixos-dev
pie_ has joined #nixos-dev
Nadri has quit [Read error: Connection reset by peer]
orivej has joined #nixos-dev
Nadrieri1 has joined #nixos-dev
pie_ has quit [Ping timeout: 255 seconds]
LnL has quit [Ping timeout: 264 seconds]
joachifm has quit [Ping timeout: 264 seconds]
aszlig has quit [Ping timeout: 264 seconds]
{`-`} has quit [Ping timeout: 264 seconds]
{`-`}_ has joined #nixos-dev
joachifm_ has joined #nixos-dev
LnL7 has joined #nixos-dev
globin_ has joined #nixos-dev
kgz has quit [Ping timeout: 240 seconds]
aszlig_ has joined #nixos-dev
bgamari- has joined #nixos-dev
LnL has quit [Ping timeout: 264 seconds]
joachifm has quit [Ping timeout: 264 seconds]
aszlig has quit [Ping timeout: 264 seconds]
{`-`} has quit [Ping timeout: 264 seconds]
globin has quit [Ping timeout: 264 seconds]
srhb has quit [Ping timeout: 264 seconds]
bgamari has quit [Ping timeout: 264 seconds]
hiberno has quit [Ping timeout: 264 seconds]
srhb has joined #nixos-dev
hiberno has joined #nixos-dev
kgz has joined #nixos-dev
sarah_ has joined #nixos-dev
srhb has quit [Ping timeout: 264 seconds]
<dtz>
Release date for nix 2?? HYPE!!
<gchristensen>
No docs? Slander! :)
<shlevy>
niksnut: Can we increase scheduling shares for the glibc-2.27 jobset? Obviously want to keep it low but at only 1000 it hasn't built anything in days :D
goibhniu1 is now known as goibhniu
<gchristensen>
"just do it" shlevy
<shlevy>
Well someone (I presume him) already decreased them I think :D
pie_ has joined #nixos-dev
<niksnut>
fine with me
pie_ has quit [Ping timeout: 256 seconds]
<shlevy>
Cool, thanks
pie_ has joined #nixos-dev
<gchristensen>
"50000 (0.58% out of 8681027 shares)" ;'D
<niksnut>
share inflation
<shlevy>
Hmm, never mind, it's already half of trunk
<shlevy>
Maybe there's some other reason nothing from the latest eval has been started?
<gchristensen>
released 2.0, almost-defaulting-to-sandboxing, almost-multi-user-by-default, shlevy's PRs merged...!!!
<shlevy>
gchristensen: Can we get ofborg on Nix?
<gchristensen>
what would you like it to do?
<shlevy>
Then we could protect master and ensure it's always relase-ready
<shlevy>
At least build build.x86_64-linux
<shlevy>
And ideally give us a way to add to the list of jobs it should build
<Profpatsch>
Is it normal that evaluating nixos/release-small.nix takes a very long time?
<aminechikhaoui>
isn't hydra.nixos.org building Nix master continuously already
<shlevy>
aminechikhaoui: Yes, but hydra.nixos.org doesn't have the github status integration turned on
<gchristensen>
so right now, no: ofborg is only able to build nixpkgs. however: it is pretty clear to me that ofborg needs to be able to build additional repositories
<shlevy>
So we can't use it to block merges
<Profpatsch>
Running nix-instantiate nixos/release-small.nix locally takes a few minutes
<Profpatsch>
Running it on hydra seems to not even finish.
<gchristensen>
Profpatsch: hmm maybe ofborg should evaluate nixos/release-<...something>.nix by default as well
pie_ has quit [Ping timeout: 255 seconds]
<Profpatsch>
I don’t know, those seem quite expensive.
<gchristensen>
my general point of view is if it is something we care about working, its worth putting checks in place to make sure it keeps working
pie_ has joined #nixos-dev
<shlevy>
=1
<shlevy>
+1
<gchristensen>
:eyes: 100 people in #nixos-dev
ghuntley has quit [Ping timeout: 255 seconds]
<gchristensen>
Profpatsch: then we can also put in tools to keep an eye on impacts to performanc
<gchristensen>
there are some suuuper rude comments there!
pie__ has joined #nixos-dev
pie_ has quit [Ping timeout: 256 seconds]
jtojnar has quit [Quit: jtojnar]
ma27 has quit [Ping timeout: 252 seconds]
<Profpatsch>
sudo npm?
<Profpatsch>
I’d say people who execute that on production servers got it coming.
<aminechikhaoui>
oh wow
<__Sander__>
node2nix ftw :D
<sphalerite>
Oh boy
<gchristensen>
let's not pile on here
<gchristensen>
NixOS is one bad mistake away from a very similar, nasty situation
<LnL>
"This page is taking way too long to load."
<LnL>
to many comments? :D
<gchristensen>
probably, LnL. people are being very nasty about it :(
<shlevy>
I do think it's true that mistakes can happen anywhere and there's no call to be nasty about this, but strong separation of responsibilities and solid foundational principles *do* genuinely differentiate Nix from npm and other lang-specific package managers here
<gchristensen>
shlevy: no doubt! I said NixOS :)
<shlevy>
:D
<gchristensen>
where we have scary things like activation
<shlevy>
Yeah
<shlevy>
Though even there rollback makes things less likely to be fatal :)
<gchristensen>
rm -rf $postgresdbpath/* # whoops, we deleted the world
<gchristensen>
(because $postgresqldbpath is "")
<shlevy>
Yeah
<shlevy>
set -euo pipefail
<gchristensen>
would be a good idea! I'd love to see a project do that
<shlevy>
Hmm actually I wonder if we can make bash when not bashInteractive set that by default :P
<aminechikhaoui>
someone from npm team should lock that issue though, it's getting out of control
<shlevy>
I mean, that'd break a lot at first
<shlevy>
But would be good hygiene
<shlevy>
Actually I guess all we need is a check for it at the top of every script
<shlevy>
Maybe we should have some test suites that replace bash with bash + shellcheck
<gchristensen>
yaaaasssssss
<gchristensen>
let's put shellcheck in to stdenv ƪ(˘⌣˘)ʃ
<gchristensen>
shlevy, niksnut -- looks like 2.0 is tagged without the patch
<__Sander__>
hmm what would be worse? C or the sh language :D
<shlevy>
:(
jtojnar has joined #nixos-dev
<catern>
gchristensen: shlevy: you should also know that this patch is untested, I have not actually deployed it myself (we used a different script to check it)
jtojnar has quit [Ping timeout: 255 seconds]
Sonarpulse has joined #nixos-dev
<gchristensen>
catern, shlevy: ok, we'll get this out in to the next release
<gchristensen>
the patch will need some good testing
<shlevy>
gchristensen: Can we avoid updating theinstaller script until it's tested?
<shlevy>
Ah I misread
<shlevy>
It's not new "(
<shlevy>
:(
<gchristensen>
not sure, that isn't a new bug by any stretch
<gchristensen>
yeah
<shlevy>
I kind of prefer just adding a daemon command to create those dirs
<catern>
(I made those updates to the patch)
<catern>
shlevy: I would definitely like the daemon to handle creating those dirs
<gchristensen>
I ... prefer not doing that ... because it opens up new and exciting possibilities for the nix daemon to be abused
<gchristensen>
whereas these run as user privileges by users
<shlevy>
That requires SO_PEERCRED
<shlevy>
True
<catern>
ah, true
<catern>
(personally in the long run I'd like GC roots to be managed by the daemon anyway, but that's not a solution for this problem)
<gchristensen>
another thing I would prefer the daemon not to do, for the same reason
<shlevy>
Bring back the nix setuid helpers! :P
<shlevy>
But yeah we need much better security audit practices before we open up things like that
<gchristensen>
yeah
<niksnut>
oops, forgot to remove TODO items from the release notes
<gchristensen>
=)
<shlevy>
Time for 2.0.1!
<shlevy>
Release notes: Remove TODO from release notes.
<Sonarpulse>
are we really that close to 2.0.0? :D
<Sonarpulse>
???
<gchristensen>
that close? 2.0.0 is tagged!
<gchristensen>
s/\.0 / /
jtojnar has joined #nixos-dev
<Sonarpulse>
gchristensen: oooo!
<Sonarpulse>
gchristensen: so should it hit nixpkgs-unstable any moment now?
<dtz>
i'd watch the nix-2.0 branch first, it's where changes to supporting nixOS infra are happening
<dtz>
oh, right, that PR :)
<FRidh>
fpletz: is there a release schedule for 18.03? I think it would be good if we write down when we intend to last modify stdenv and such and the major package sets, so we can stabilize the applications afterwards.
<Sonarpulse>
thanks all!
<dtz>
and i'm super glad 2.0 is being cut--so much goodness. And we have more we'll just have to cut 2.0.1 soon ;).
jtojnar has quit [Ping timeout: 264 seconds]
<dtz>
FRidh: dunno but +1 for the question/concern
<dtz>
also hopefully slated for 2.0.1: rpm/deb's for reliable and easy Nix goodness everywhere
<Sonarpulse>
FRidh: which stdenv modification?
<Sonarpulse>
fpletz: relatedly I'd also like to deprecate stdenv.is* this cycle
<Sonarpulse>
but not sure whether there is enough time to gather consensus on that
<Sonarpulse>
I suppose I could write the RFC either way and see if it lands in time
<globin_>
FRidh: also a mail on nix-dev was sent out by the release managers a few days ago :)
<dtz>
and those changes wouldn't cause any rebuilds just a bunch of expression updates to be more specific, right?
<dtz>
(stdenv.isArm -> stdenv.hostPlatform.isArm, or whatever)
<FRidh>
globin_: what mail is that? I have received one from vcunat 16 hours ago.
<FRidh>
Sonarpulse: I don't know if there are any more proposed changes, but I recall with 17.09 there was a lot last-minute
<globin_>
FRidh: ah might've been only then
<Sonarpulse>
FRidh: hehe that was me too
<FRidh>
I just want to know what to expect :)
<globin_>
FRidh: vcunat is the second release manager with fpletz for 18.03
<Sonarpulse>
FRidh: I should have moved on this earlier
<Sonarpulse>
but in practice, such a big refactor is nice to do right before branch
<Sonarpulse>
so it doesn't impede backports
<FRidh>
Sonarpulse: such changes need testing, along with updates in the major package sets we have. Doing those at the same time is...hard. Therefore, I prefer if there was some schedule. E.g., until certain point no refactoring of stdenv or so, and then a week later no more major updates in the package sets.
<gchristensen>
yeah that seems reasonable
<gchristensen>
I think there has been such a schedule in the past?
<FRidh>
I don't think there has been.
<FRidh>
At least, I don't recall it.
<gchristensen>
I guess I'm remembering something like the release managers were aware of the major things trying to be merged in, worked to to set a schedule for those things, and didn't accept new things
<globin_>
yeah we never had a hard schedule except for branch-off and release, see the manual :)
<globin_>
everything else was done by case-by-case decisions
<Sonarpulse>
FRidh: so I was just going to deprecate i.e. add warning
<Sonarpulse>
so no breaking change
<Sonarpulse>
I was then going to refactor nixpkgs to get rid of warning on existing packages
<Sonarpulse>
again no breaking change and easy sed
<Sonarpulse>
maybe later add tests to make sure eval doesn't have warnings
<Sonarpulse>
but that would effectively break code gen like cabal2nix
<sphalerite_>
niksnut: "The command nix-push has been removed as part of the effort to eliminate Nix's dependency on Perl. You can use nix copy instead, e.g. nix copy --to /tmp/my-binary-cache paths…"
<Sonarpulse>
^ that commit is interesting
<sphalerite_>
niksnut: should that be --to file:///tmp/my-binary-cache ?
<niksnut>
sphalerite_: good catch, yes
<Sonarpulse>
viric changing a default that then I changed back 7 years later :D
<niksnut>
fixed
pie___ has joined #nixos-dev
ma27 has quit [Ping timeout: 256 seconds]
Lisanna has quit [Quit: Lisanna]
pie__ has quit [Ping timeout: 240 seconds]
ma27 has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
<gchristensen>
niksnut: I suppose it is too early to try running ofborg tests on https://github.com/NixOS/nixpkgs/pull/34636, for fear of turning it in to a soup of ofborg replies... probably better to let hydra take lead :P
<gchristensen>
shlevy: that job should be dead-or-dying-soon
<niksnut>
what nix version do those packet machines run?
<gchristensen>
hmm good question
<niksnut>
sounds like they don't have the threadpool hang fix (fda7b95cb08c447a7ee4ec18ea3574d76e6264df)
<gchristensen>
ideally, we'd get them managed by your nixops network so they took deploys every time you deployed
pie___ is now known as pie_
<aminechikhaoui>
only if I finished that :(
<gchristensen>
they're already managed by nixops, using the `none` backend
<aminechikhaoui>
ah yeah
ma27 has joined #nixos-dev
__Sander__ has quit [Quit: Konversation terminated!]
goibhniu has quit [Ping timeout: 256 seconds]
<gchristensen>
hold on to your butts, I'm rebooting builder-t2-4. hopefully it comes online okay @_@
<Sonarpulse>
I'm now a big fan of docbook firstterm
<Sonarpulse>
we gotta use that everywhere!
<gchristensen>
what is that?
<Sonarpulse>
gchristensen: used to indicate the first time some vocab would show up
<Sonarpulse>
probably italicized it
<gchristensen>
OH YES! so good!
<Sonarpulse>
:)
yegortim1 has quit [Remote host closed the connection]
yegortim1 has joined #nixos-dev
yegortim1 has quit [Remote host closed the connection]
contrapumpkin has joined #nixos-dev
yegortim1 has joined #nixos-dev
goibhniu has joined #nixos-dev
<gchristensen>
"`stateVersion` is a hack nobody uses. Just sayin'." "just sayin'"
<dtz>
lol what's that from?
<dtz>
and what that's not true... is it?
* dtz
thought it was useful and good idea
<gchristensen>
well people don't really use stateVersion, it is mostly internal to the module system ... but also it is a bit messy to deal with
<dtz>
it's unfortunate that it's needed but it helps deal with practicality of not everything being reliably backwards and future compat
<gchristensen>
yeah
<dtz>
shlevy: hey are you around? I pushed on the RFC but need some help organizing a bit and perhaps developing the ideas themselves
<dtz>
gchristensen: I'm struggling with this "RFC" -> comment thread -> ... updated RFC? process. It's proving very challenging to respect the format while also addressing questions and providing answers or proposed answers xD
<dtz>
I suppose I'll just have to practice with more RFC's lol
<gchristensen>
we all need practice
<shlevy>
dtz: Not able to look right now, but can you send me an email and I'll look later
<dtz>
heh at first I thought you meant about everything but
<dtz>
i think you're right re:practicing this entire process as a community
<dtz>
shlevy: sure! ping me if you're looking and don't have it, I'll see about revising it in the meantime :)
<gchristensen>
dtz: maybe post a comment saying" I think I've answered all the questions, please read my changes"?
<gchristensen>
(if that is true)
<gchristensen>
dtz: the RFC is looking much better!
<gchristensen>
what does it take to indicate a package doesn't support musl?
<gchristensen>
niksnut: any chance I can buy you a beer remotely?
<dtz>
:D +1
<gchristensen>
you too, shlevy
<shlevy>
gchristensen: No dice, gotta be in person ;)
<shlevy>
But I'll have to buy yours, so it's a wash
<cransom>
depends on how expensive your taste in beer is though too.
<gchristensen>
fiiine I'd say let's meet up for dinner (if we left in the next couple hours, we could meet up in the middle and get there on time for supper) but it is snowing with a vengeance outside right now
<gchristensen>
who knew sound was such a controversy >.>
<dtz>
if y'all were anywhere near me I'd love to get some drinks with y'all
<dtz>
haha
<gchristensen>
dtz: we could meet up for ... breakfast?
<samueldr>
anything can be a controversy :/
<samueldr>
^(woah there controversial statement)
<dtz>
lol
goibhniu has quit [Ping timeout: 248 seconds]
<fpletz>
gchristensen: regarding stateVersion, maybe we should make it more clear in the docs. we could write a few more sentences about stateVersion in all forthcoming release notes for instance
<fpletz>
stateVersion is quite important for some services \o/
<dtz>
$20 to someone who makes it so my hydra doesn't have to be an I/O + XZ bottleneck for my builds
<dtz>
lol
<dtz>
I imagine others would like that to, at least if done in a way that could be upstreamed :)
<dtz>
also I'm mostly kidding about the $20 but only because there's an issue about it somewhere discussing how it'd be hard in current design
aminechi1haoui has joined #nixos-dev
aminechikhaoui has quit [Ping timeout: 248 seconds]
<Mic92>
dtz: I suppose you got the big machines at university.
ma27 has quit [Ping timeout: 255 seconds]
<dtz>
lol not really
<dtz>
handful of deprecated desktops at the moment
<dtz>
mostly my hydra machine is probably much too weak lol
aminechi1haoui has quit [Remote host closed the connection]
aminechikhaoui has joined #nixos-dev
ma27 has joined #nixos-dev
<dtz>
my biggest machine is waiting on disk replacements... then I'll have some compute power ^_^
<dtz>
but still pales in comparison to what y'all probably have
<dtz>
:)
<dtz>
lol my hydra is an old dual core :(
<dtz>
it .. has heart
<gchristensen>
none of my machines are very powerful, I've just convinced people to let me borrow fancier ones
orivej has joined #nixos-dev
Lisanna has joined #nixos-dev
kgz has quit [Ping timeout: 260 seconds]
JosW has quit [Quit: Konversation terminated!]
kgz has joined #nixos-dev
<sphalerite_>
gchristensen: good tactic :D
<sphalerite_>
although your laptop is fairly powerful too!
<gchristensen>
heh, maybe I am spoiled ...
<gchristensen>
s/maybe //
<sphalerite_>
Had a chat with a guy today who worked as a sysadmin, is now retired and studying CS at my uni. He's a bit of a collector, and I told him about the vocore (vocore.io) and we compared it with an SGI workstations (also MIPS) that he's trying to revive
<sphalerite_>
it's incredible how powerful and efficient computers have become
<gchristensen>
hot dog look at that
jtojnar has joined #nixos-dev
<sphalerite_>
Sonarpulse: so you said you'd want all the tools to be prefixed with the platform tuple?
<shlevy>
All or none, please :)
<shlevy>
(or, even better, make sane tools that can support multiple targets)
<sphalerite_>
see, in my efforts to get stuff building for armv7 (natively) on an armv7-capable aarch64 machine, I've ended up with funny cases like armv7l-unknown-linux-gnueabihf-i3
<shlevy>
:D
<sphalerite_>
which the wrapper invocation in fixupPhase isn't a fan of (it expects it to be called just i3)
<sphalerite_>
as a user I'm also not a fan of it :p
<sphalerite_>
s/wrapper/makeWrapper/
<Sonarpulse>
sphalerite_: yeah
<Sonarpulse>
there's an issue for that
<Sonarpulse>
sphalerite_: likewise inspecting the build time CPU is super impure
<Sonarpulse>
so passing --build --host is good anyways
<sphalerite_>
yeah just that it'll confuse non-autotools stuff
<Sonarpulse>
that's where configurePlatforms comes in
<Sonarpulse>
configurePlatforms = []; to squash that
<sphalerite_>
I found that you can do essentially the smae thing by setting {build,host}_alias env vars too though
<sphalerite_>
ooh
<Sonarpulse>
shlevy: prefixed everything by 18.09?
<Sonarpulse>
I have tentative plans where just the wrappers are prefixed
<Sonarpulse>
so we don't need to e.g. rebuild llvm
<Sonarpulse>
but most packages' build systems expecting platform to be auto-set work fine
<sphalerite_>
so what do we do about how binary names get prefixed with the system tuple in cases where that's not actually what you want?
<sphalerite_>
Like with i3
<Sonarpulse>
i386?
taktoa has quit [Ping timeout: 260 seconds]
Wizzard has joined #nixos-dev
<gchristensen>
I'm going to close all the wiki issues
<gchristensen>
any opposed?
<sphalerite_>
Sonarpulse: i3 the window manager
<Sonarpulse>
sphalerite_: oh duh
<Sonarpulse>
hmm so only --target affects prefixing ideomatically
<Sonarpulse>
in the gcc case we should pass all three
<sphalerite_>
oh so I need to take out my target setting?
<Sonarpulse>
but i3 with mere cross compiling (I assume its not autotools) gets prefixed?
<sphalerite_>
I think it is autotools
<Sonarpulse>
sphalerite_: yeah unless you are building compilers or other things generated code
<Sonarpulse>
don't pass --target
<sphalerite_>
but I'm passing build, host and target as that
<Sonarpulse>
just pass --build --host
<sphalerite_>
ok good to know
<sphalerite_>
any opinion on passing them as args vs env vars?
<Sonarpulse>
most things just get exactly --build and --host, or the equivalent for their build system
<Sonarpulse>
--target is just given on a need-to-know basis
<Sonarpulse>
(beyond this prefixing annoyance, it would cause pointless rebuilds)
<sphalerite_>
right
<sphalerite_>
oh would you look at the time
<sphalerite_>
it's mass rebuild o'clock!
<Sonarpulse>
sphalerite_: :D
<shlevy>
Sonarpulse: I think you overdo it on avoiding rebuilds
<shlevy>
That's what the staging branch is for :)
<Sonarpulse>
shlevy: which PRs?
<shlevy>
You mentioned avoiding rebuilding llvm above :)
<Sonarpulse>
ohhh
<Sonarpulse>
shlevy: hey well gotta show off llvm's target-agnosticness!
<gchristensen>
lol Eelco low-key releases Nix 2.0 and doesn't even send an email about it :D