jtojnar has quit [Read error: Connection reset by peer]
jtojnar__ is now known as jtojnar
jtojnar_ has quit [Ping timeout: 260 seconds]
<dtz>
Also I'm like 95% sure I chased down gc things before haha-- and IIRC discussion was that gc-or-no shouldn't leak out of the evaluator, which makes sense.
<pstn>
Whoever gets teamviewer 13 working on nixos will have my eternal gratitude. Trying it right now but they seemed to have switched frameworks now and so many things changed...
__Sander__ has quit [Quit: Konversation terminated!]
<NinjaTrappeur>
LnL, thanks. I have some trouble understanding this page. Where can I find the derivations used to produce those test cases? Is this somewhere in the nix git repository?
<Dezgeg>
what's our guarantee for stable APIs for packages outside nixpkgs? surely it cannot be just that 8 year old APIs get renamed like this: https://github.com/NixOS/nixpkgs/pull/37401
<drakonis>
plugins plugins plugins
<drakonis>
ah hold on, i'm conflating nix with nixpkgs right now
<drakonis>
are there any stats for off tree repositories?
<drakonis>
can isArm be aliased to isAarch32?
<drakonis>
actually, i don't think there's anything using the isArm api other than nixpkgs itself
<Dezgeg>
I use it
<drakonis>
ah i see
<drakonis>
well then
<drakonis>
don't mind me
<drakonis>
to be honest, there wasn't aarch64 until 2011
<drakonis>
the first chip using it was in 2012
<samueldr>
ls
<samueldr>
wrong computer
<drakonis>
i'd say to update it in order to keep the naming scheme consistent and unambiguous
<Sonarpulse>
Dezgeg: that very change ended up being relented on by niksnut
<Sonarpulse>
and NIX_CC/.../dynamic-linker was kept around for back-compat
<Sonarpulse>
$NIX_CC/nix-support/dynamic-linker
<drakonis>
release management with a sliced up tree and let nixpkgs be free to do crazy crazy things
<Dezgeg>
exacly, the point was that this pointless $NIX_CC/nix-support/dynamic-linker -> $NIX_BINUTILS/nix-support/dynamic-linker mass rename was rejected
<Sonarpulse>
Dezgeg: $NIX_BINUTILS/nix-support/dynamic-linker was kept
<Dezgeg>
there is no single instance in nixpkgs referring to that
<drakonis>
i assume those renames are one of those "what if we want to swap stdenv components?" situations
<drakonis>
replace gcc and gnu binutils with llvm and llvm binutils
<Sonarpulse>
drakonis: the idea was that for a bunch of things in cross we need a binutils wrapper
<drakonis>
ah i see
<Sonarpulse>
especially so that when building C compilers
<Sonarpulse>
we don't need to hand-roll everything the wrapper would do
<Sonarpulse>
Dezgeg: so back to the big picture
<Sonarpulse>
on the MUSL pr
<Sonarpulse>
eelco was worried about lots of conditionals and other stuff
<Dezgeg>
where?
<Sonarpulse>
rfc
<Sonarpulse>
not pr
<Sonarpulse>
sorry
<Sonarpulse>
well with all the work that we did, we can now compile in far more ways without crazy conditional soup
<Sonarpulse>
the work that went into changing core components like cc-wrapper
<Sonarpulse>
*directly* led to the obviation of such hacks
<Sonarpulse>
that niksnut was worried about accumulating
<Dezgeg>
I don't know what you mean
<Sonarpulse>
for example creating bintools-wrapper
<Sonarpulse>
meant that gcc build could be simplified a lot
<Dezgeg>
if a package needs a patch to compile with musl how do you avoid those 'if musl then patch' things?
<Sonarpulse>
often times it wasn't that the package needed it
<Sonarpulse>
but like the way were doing things was insufficiently generic
<Sonarpulse>
the duplication between cc-wrapper and gcc
<dtz>
I like using an attr (stdenv.cc.bintools.dynamicLinker) better than echo $(cat $NIX_CC/asdf) just because it's cleaner
<Sonarpulse>
and the former getting more attention
<Sonarpulse>
meant that the gcc code was stale
<Sonarpulse>
then the gcc code shrunk
<Sonarpulse>
mingw was made to keep on working
<Sonarpulse>
and corect me if I'm wrong, dtz, but gcc didn't need too many hacks for musl?
<Sonarpulse>
(there's still more crap to remove from GCC btw)
<Dezgeg>
I still don't get what you mean
<drakonis>
he's talking about keeping it clean
<Sonarpulse>
Dezgeg: granted isArm <-> isAarch32
<Sonarpulse>
is *not* a complexity reducer
<Sonarpulse>
so it's not like $NIX_BINUTILS
<Sonarpulse>
in terms of there's an actual change beyond renaming
<dtz>
errr not really? most have been upstreamed. Mostly needed to extend our NixOS-specific hacks to cover musl too
<Sonarpulse>
(two wrappers not one)
<Sonarpulse>
dtz: well i mean had you done musl like 3 years ago in nixpkgs, it might have been a lot nastier :)
<dtz>
but re:patches and whatnot it's my experience that generally they're fixes we want anyway, and honestly I've been pleasantly surprised to find patches I have in my tree from year or two ago are often no longer needed
<Sonarpulse>
^ hehe exactly
<dtz>
as compilers, and glibc/gcc, and musl proponents probably... all clean things up
<dtz>
O:)
<Sonarpulse>
Dezgeg: isArm <-> isAarch32 I still think is good for regular people, say who hadn't used ARM before
<Sonarpulse>
don't know what gnu-config is
<Sonarpulse>
never saw the llvm triple parser C++
<dtz>
but the truth is we're still seeing how things would work to some extent, which is a big part I think of why that RFC stalled :)
<dtz>
well and because that's our RFC process :D :D
<Sonarpulse>
^ :D
<Dezgeg>
if they haven't used ARM before why do they need to know about it then?
<Sonarpulse>
because they are trying it out for the first time
<dtz>
Sonarpulse: yes. Yes it would, and was AFAICT.
<Sonarpulse>
I'm trying to reduce the deluge of gotchas one has to wade through
<Dezgeg>
and then they will find out that their arm box produces 'armv7l' in uname -a
<dtz>
renaming an attribute ... honestly I just like it because I've gotten it wrong sometimes
<Dezgeg>
and that their cross compiler is named arm-none-eabi-gcc
<Sonarpulse>
Aarch32 is to me a clear win because it's not ambiguous vs plan arm
<dtz>
but maybe that's just my bad :P. I don't know what best answer is.
<Sonarpulse>
dtz: I've hit it too
<Sonarpulse>
dtz: I've just committed to gnu-config, so maybe we can accept aarch32v7 too
<dtz>
so I imagine we can easily manage to change it all in one go in-tree
<Sonarpulse>
indeed
<Sonarpulse>
that is what the PR did
<dtz>
maybe a bit of sync across branches, and --hmm minor pain backkporting occasionally
<dtz>
the biggest reason not to is how badly it'd break out-of-tree or forks, I'd think?
<Dezgeg>
how do you know gnu-config will accept this aarch32v7?
<dtz>
I have no idea what everyone calls them and try not to have too many opinions on what they should be called
<Dezgeg>
it's easy, everyone calls them arm 8)
<dtz>
just that we all try to use same names-- not because they're right but so we can argue about things that matter not the name of the things that matter :D
<Dezgeg>
i.e. literally %ifarch %{arm} in rpm
<Sonarpulse>
Dezgeg: I don't know that
<dtz>
haha
<Sonarpulse>
Dezgeg: I don't mine armv7 as much
<dtz>
yeah someone (probably on that issue/PR) mentioned that ARM made an announcement clarifying what was and wasn't arm
<Sonarpulse>
because the v7 is a hint we're talking about a moment in time
<Sonarpulse>
not "arm the ongoing concept"
<Sonarpulse>
I don't really like raw "arm-"
<Sonarpulse>
eventually there will probably be aarch64v9
<Dezgeg>
but that's what other distros call it
<Sonarpulse>
or something like that
<dtz>
and i'm like yeah okay and treat that the same as I do when some company rebrands the local stadium to McDonalds-Is-Great Stadium
<dtz>
lol
<dtz>
:P
<Sonarpulse>
Dezgeg: note the trailing dash, arm- as a concrete config as opposed to a predicate
<Dezgeg>
the name 'arm' isn't going away from target triplets or what 'uname -r' returns
<Sonarpulse>
we can give no one reason to ever use arm-* in nixpkgs
<Dezgeg>
arm-none-eabi-gcc is literally what an usual cross compiler is called
<Sonarpulse>
and then you need to pass -march flags
<Sonarpulse>
which sucks in nixpkgs today
<Dezgeg>
that is literally what people call these things
<dtz>
lol every arm project I've worked on (well, years ago) basically had a set of -march and such flags for each supported platform xD xD
<Sonarpulse>
the whole point of -target in llvm was to get rid of the -march soup
<Sonarpulse>
using an ambiguous config defeats the point
<Sonarpulse>
I need to get back to work, I don't think I'm very swayable at this point so let's just all vote everything
<Sonarpulse>
if people side with dezgeg I'll gladly drop it
<dtz>
lol or patch llvm to conform
<dtz>
:P :P
<Sonarpulse>
dtz: with aarch32?
<Sonarpulse>
yeah I like patching upstream
<Sonarpulse>
gnu-config is a lot more exotic than llvm haha
<dtz>
isMadeByARM
<dtz>
lol
<Sonarpulse>
hahaha
<dtz>
well they might reject, ARM employees will shut it down :P
<dtz>
mayb
<dtz>
*maybe
<dtz>
we really need to patch clang to just understand our damn OS
<dtz>
lol
<dtz>
because it tries so hard to find proof it's any of a number of other things
<dtz>
lol
<dtz>
bah
<dtz>
I'd do it if I had a clear idea of what the heck we wanted it to do
<Sonarpulse>
dtz: nixos?
<Sonarpulse>
hmm?
<MichaelRaskin>
is _designed_ by ARM, though
<dtz>
we kinda want our compilers to be useless by themselves, unless they're wrapped
<MichaelRaskin>
(And even that is only up to the first approximation)
<dtz>
yeah, nixos
<dtz>
is_licensed_by_ARM
<dtz>
ARM_would_be_mad_if_you_called_this_ARM
<dtz>
o_O
<Sonarpulse>
:D
<dtz>
Sonarpulse: is this related to, or do we have any thoughts/plans for, starting to always set build/host/target?
<dtz>
or at least two of fthem
<Sonarpulse>
dtz: oh you mean like --build --host --target?
<dtz>
...why can't the world just conform to our ideals already
<dtz>
plskthx
<Sonarpulse>
haha
<Sonarpulse>
I haven't thought about that in a while
<Sonarpulse>
well sphalerite
<Sonarpulse>
had the idea to use env vars
<Sonarpulse>
so non gnu configure wouldn't be screwed uo
<Sonarpulse>
only build and host would be set, fwiw
<Sonarpulse>
target is opt in so we don't rebuild the world
<Sonarpulse>
(/ --target is a legacy concept just for shitty compilers)
<Dezgeg>
does setting both build + host trigger this 'cannot run test program while cross compiler' thing or is it something else?
<Dezgeg>
or do they need to be set to different values?
<drakonis>
minimizing gotchas you said earlier, does it include minimizing the libgl gotchas?
<Dezgeg>
that still remains
<Sonarpulse>
Dezgeg: that is another fear of mine i forgot about
<Sonarpulse>
great point
<Dezgeg>
maybe setting just --build avoids that?
<Sonarpulse>
Dezgeg: if they are the same?
<Sonarpulse>
yeah maybe
<Sonarpulse>
(or I think we'd want to do just --host_
<MichaelRaskin>
Sonarpulse: target is not for shitty compilers, it is for compilers from the era when building a compiler for all targets was a meaningful storage problem.
<shlevy>
checkPhase should always be a separate drv on the runtime system
* shlevy
ducks
<shlevy>
I'm going to go further and say that multi-target is *still* worse than single-target in many cases
<shlevy>
We shouldn't settle for either, though, we should have generic core packages and composable target-specific bits on top
<Sonarpulse>
MichaelRaskin: I'm guessing that was just the case because the compilers came with all the librarires
<MichaelRaskin>
Even without libraries compilers are large
<Sonarpulse>
if they came with no libraries I doubt the raw binary size would have been so prohibitive an issue
<Sonarpulse>
MichaelRaskin: gnu bfd was multi-target for a long time
<shlevy>
Sonarpulse: llvm on modern hardware is stupidly slow to compile multi-target...
<MichaelRaskin>
First you make decisions on a 20 MiB HDD system, then you kind carry them with your for 20 years
<Sonarpulse>
fair enough
<Sonarpulse>
stupid in 2018 compilers :D
<Sonarpulse>
--target*s* is not so bad
<Sonarpulse>
--targets='' only make portable llvm bitocde!
<Dezgeg>
isn't the llvm bitcode quite unportable?
<Sonarpulse>
Dezgeg: depends how it is produced I think, I assume over time they generate more target-specific bitcode
<Sonarpulse>
without anyone caring one way or another
<Dezgeg>
well, you need to resolve say, sizeof(void*) in the C frontend itself
<Dezgeg>
so I doubt it will ever happen
<Sonarpulse>
I mean i was being a bit tongue in cheek
<Sonarpulse>
--targets='' maybe for a non-C compile :)
<Sonarpulse>
--targets='' maybe for a non-C compiler :)
<Sonarpulse>
or it doesn't allow sizeof(void*) for parametric portability
<shlevy>
Sadly there's no native pointer type in llvm
<shlevy>
Only specific bit widths
<dtz>
as someone who literally works on "let's create an OS where everything is in LLVM IR"... no it's not portable at all. Or at least you're going to have a bad time if you ever assume it is :)
* dtz
points to PNACL, they did the best they could
<dtz>
lo
<dtz>
oh
<dtz>
you said unportable
<dtz>
LOL
<dtz>
:D
jtojnar has quit [Quit: jtojnar]
jtojnar_ has joined #nixos-dev
<drakonis>
there was a mozilla guy that had a brother that worked on llvm ir that said llvm ir isn't a panaea for portability
<drakonis>
are you that guy?
ma27 has quit [Ping timeout: 255 seconds]
<Sonarpulse>
bgamari: I tried again
<Sonarpulse>
on latest master
<Sonarpulse>
err damn
<Sonarpulse>
ok that was my branch
<Sonarpulse>
let me go build master again
<bgamari>
yep
* bgamari
wishes that `nix build` supported -K and -k
<clever>
i often find myself re-running the build under nix-build, because i need the last 20 lines of output, not the last 10
<bgamari>
yeah
<bgamari>
there are still quite a few papercuts
<clever>
haskell errors are fairly verbose, and the start is more important
<dtz>
drakonis: I am not! but I probably know at least one of them! although don't know a set of brothers offhand....
<drakonis>
i remember some blog post talking about it
<Sonarpulse>
bgamari: this will break cross though
<Sonarpulse>
can you make it conditional?
<Sonarpulse>
or is perl actually needed then?
<bgamari>
will it?
<bgamari>
oh
<Sonarpulse>
yeah because that is runtime perl
<bgamari>
that should be buildPackages
<bgamari>
good catch
* bgamari
should test this on cross
<Sonarpulse>
+1
<dtz>
+1
<dtz>
(LGTM)
* bgamari
has a cross build running
<dtz>
aww doesn't fix merge w/staging
<dtz>
could you take a look at what that's about? otherwise it'll be someone else's problem when they try to merge and have no idea re:git/these changes
<dtz>
lol
<dtz>
we can try to draft author of the other changes instead
<bgamari>
dtz, here
<bgamari>
sure rather
<bgamari>
right after this build
<dtz>
yay tyvm
<bgamari>
dtz, should I merge master into staging or the other way around?
<dtz>
well I think merging master into staging should always be "okay"
<dtz>
where's that RFC when you need it
<dtz>
if that RFC gets accepted can we get a github tool or browser plugin with buttons enforcing/encouraging how we do things? :P
<MichaelRaskin>
You want to submit patches for ofborg with support for some more commands?
<dtz>
! didn't even think of that haha
ma27 has quit [Ping timeout: 256 seconds]
<MichaelRaskin>
… or is pre-conditioning on something happening with RFC the way you express negation nowadays?
<dtz>
MichaelRaskin: I'm sorry :(. I love that RFC, and the effort put into it. For the same reasons I'd like "bumpers" to ensure I do the right thing:
<LnL>
I merged master -> staging a couple of hours ago
<bgamari>
dtz, indeed you need to revert shlevy's perl-cross patch
<dtz>
proper process is important and requires careful thinking / big picture reflectiton that each of us (at least me :P) might not keep in mind at all times despite our intentions
<bgamari>
dtz, perl currently doesn't cross-compile
<dtz>
anyway certainly not my way of being negative :(
<bgamari>
which is part of the motivation for the earlier patches
<bgamari>
(git patches, that is)
<dtz>
o___O
<dtz>
who broke it?! whaattt
<Sonarpulse>
what's this RFC?
<Sonarpulse>
what's with git?
<bgamari>
well, shea's change is in principle an improvement
<dtz>
i stop building master for a few weeks or so and QQ
<dtz>
okay
<Sonarpulse>
can we merge that PR cause at least master works now?
<dtz>
haha
<bgamari>
since previously perl would only cross-compile with some binfmt-misc support
<bgamari>
now it truly cross-compiles
<dtz>
oh, yes! sorry.
<dtz>
i mean it only makes master better (unbroken)
<dtz>
o____O
<bgamari>
unfortunately, some perl packages are essentially impossible to truly cross compile
<dtz>
what that's not true, I had it cross-compiling (with perl-cross) a while ago
<bgamari>
Sonarpulse, I think so
<dtz>
oh you mean the packages
<dtz>
yeah taht was .. oh
<bgamari>
right
<dtz>
right, that's what you mean re:shlevy's patch
* dtz
remembers
<dtz>
xD xD
<dtz>
ooooh okay
<dtz>
:D
<dtz>
:3
* bgamari
recently rediscovered all of this as well
<bgamari>
dtz: (if stdenv.hostPlatform.isMusl then "NO_SYS_POLL_H=1 NO_GETTEXT=YesPlease" else "")
* bgamari
doesn't know why his clipboard seems to be so unpredictable with firefox
<dtz>
haha
<ekleog>
… when do we get to write pkg.description in markdown? looks like there's already doc/languages-frameworks/haskell.section.md :(
orivej_ has quit [Ping timeout: 248 seconds]
orivej has joined #nixos-dev
Sonarpulse has quit [Ping timeout: 264 seconds]
orivej has quit [Ping timeout: 240 seconds]
<bgamari>
dtz, alright, I've pushed my merge to my fork's staging branch
<bgamari>
I'll admit I'm not entirely certain about the all-packages resolution
<bgamari>
but the git resolution should be fine
<ekleog>
can someone have a look at this usual please-don't-put-passwords-in-the-nix-store PR? https://github.com/NixOS/nixpkgs/pull/39455 (and potentially backport to 18.03, as it's a security fix)
<ekleog>
(the huge diff is caused in large part by the removal of this useless mkMerge)
<ekleog>
(well, “huge”… -26+24, so it's not that huge, but compared with the actual value-added changes it's big)