<domenkozar[m]>
is musl considered a supported package set?
<domenkozar[m]>
we are blocking patchelf update on it
<simpson>
People are trying to make it supported, but it's not yet supported, AFAIK. Is patchelf likely to gain a fix, or is this a permanent blocker for musl?
__monty__ has joined #nixos-dev
orivej has joined #nixos-dev
<adisbladis>
worldofpeace: I had it happen on the gnome live media the other day.
<yorick>
why are a lot of haskell packages set as broken?
vaibhavsagar has quit [Write error: Broken pipe]
nh2[m] has quit [Write error: Connection reset by peer]
matthewbauer has quit [Write error: Connection reset by peer]
domenkozar[m] has quit [Write error: Connection reset by peer]
codyopel has quit [Write error: Connection reset by peer]
dtz has quit [Remote host closed the connection]
yegortimoshenko has quit [Write error: Connection reset by peer]
bennofs[m] has quit [Write error: Connection reset by peer]
layus[m] has quit [Write error: Connection reset by peer]
alienpirate5 has quit [Write error: Connection reset by peer]
worldofpeace has quit [Remote host closed the connection]
nocent has quit [Remote host closed the connection]
thefloweringash has quit [Write error: Connection reset by peer]
Ericson2314 has quit [Write error: Connection reset by peer]
timokau[m] has quit [Remote host closed the connection]
ma27[m] has quit [Remote host closed the connection]
abbradar has quit [Write error: Broken pipe]
roberth has quit [Write error: Broken pipe]
rycee has quit [Write error: Broken pipe]
Ericson2314 has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
<disasm>
globin: think we can wrap up the GCC8 branch getting merged this week? cc: sphalerite
<Profpatsch>
yorick: I think they are semi-automatically set that way if they don’t build.
<Profpatsch>
Because otherwise hydra has to try to build them for every nixpkgs commit.
<Profpatsch>
Which leads to a lot of wasted computation
<yorick>
I see
<yorick>
not having amazonka is a shame
<Profpatsch>
yorick: If you need it, maybe you can spend some effort fixing it?
<yorick>
they just need to push it to hackage
<Profpatsch>
Maybe we can add them manually?
<Profpatsch>
I assume maintaining them on hackage is a lot of overhead they are not prepared to invest
<yorick>
we can override the source to be github
<yorick>
no, amazonka is on github, just not the commit that has the fixes
<Profpatsch>
yorick: Ah, you can add an override that patches the release.
<{^_^}>
brendanhay/amazonka#532 (by DanBurton, 12 weeks ago, open): Release versions of amazonka-* that can build with http-client-0.6.*
<globin>
disasm: fpletz is working on it
dtz has joined #nixos-dev
domenkozar[m] has joined #nixos-dev
thefloweringash has joined #nixos-dev
alienpirate5 has joined #nixos-dev
abbradar has joined #nixos-dev
bennofs[m] has joined #nixos-dev
worldofpeace has joined #nixos-dev
codyopel has joined #nixos-dev
yegortimoshenko has joined #nixos-dev
nocent has joined #nixos-dev
vaibhavsagar has joined #nixos-dev
ma27[m] has joined #nixos-dev
layus[m] has joined #nixos-dev
timokau[m] has joined #nixos-dev
rycee has joined #nixos-dev
nh2[m] has joined #nixos-dev
roberth has joined #nixos-dev
matthewbauer has joined #nixos-dev
<fpletz>
disasm: imho we should definitely merge it before the branchoff, only less commonly used packages are failing now (except for llvm_4 but I already found a patch for that)
<{^_^}>
haskell-servant/servant-auth#113 (by domenkozar, 1 year ago, closed): servant-auth-client test failure on macOS
<domenkozar[m]>
yorick: I don't think so, but I have verified
<yorick>
okay. currently working through the configuration-common overrides
<disasm>
fpletz: sounds good to me :)
<disasm>
fpletz: since it has it's own hydra jobset, it can go straight to master (not staging) right?
<disasm>
My suggestion would be we rebase and fix merge conflicts, we get the llvm_4 patch in, and then we merge it and the less commonly used packages can be updated against master (and cherry-picked to 19.03 if they're fixed in master after cut-off)
<disasm>
thoughts sphalerite fpletz?
psyanticy has joined #nixos-dev
bgamari has quit [Ping timeout: 250 seconds]
cjpbirkbeck has joined #nixos-dev
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-dev
ciil has quit [Quit: Lost terminal]
ciil has joined #nixos-dev
bgamari has joined #nixos-dev
<fpletz>
disasm: sounds good to me, give me a few hours to fix some more builds and llvm and let's see where we are tomorrow :)
johanot has quit [Quit: WeeChat 2.4]
drakonis1 has joined #nixos-dev
Guest95592 has quit [Changing host]
Guest95592 has joined #nixos-dev
Guest95592 is now known as LnL
cjpbirkbeck has quit [Quit: Quitting now.]
cjpbirkbeck has joined #nixos-dev
orivej has quit [Ping timeout: 245 seconds]
<disasm>
fpletz++
<{^_^}>
fpletz's karma got increased to 2
drakonis1 has quit [Quit: WeeChat 2.4]
ixxie has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 252 seconds]
drakonis_ has quit [Ping timeout: 250 seconds]
orivej has joined #nixos-dev
<ashkitten>
btw i noticed clang+musl wasn't on the list for rfc 46, is that just a completely unsupported configuration? seems weird to me as both clang+glibc and gcc+musl are on there
bgamari has quit [Ping timeout: 245 seconds]
bgamari has joined #nixos-dev
<averell>
would that be likely to have any significant amount of edge cases?
<ashkitten>
gf says usually it'll work but causes issues on powerpc due to floating point quirks that are handled separately by both clang and musl but don't work well together
<ashkitten>
so as long as we don't care about clang+musl on powerpc, it's probably fine (tho i'd recommend adding it to the list of supported platforms regardless)
<ashkitten>
er, recommend adding x86_64 clang+musl
<qyliss>
Yeah musl+clang is a pretty popular combination
<qyliss>
Especially for folks who just don't like GNU stuff
<qyliss>
And there are distributions (Alpine, Adélie, etc) that are built around this combo
<ashkitten>
(my gf is working on an entirely gnu-free distro)
<qyliss>
fwiw
<qyliss>
is it adélie or a different one?
<ashkitten>
froebel
<qyliss>
oh I've seen that
<ashkitten>
you have? nice
<qyliss>
Yeah my gf starred it
<ashkitten>
oh cool
Jackneill has quit [Remote host closed the connection]
<ashkitten>
tfw you both know each other by your linux distros but not your names
<qyliss>
lmao yes
<qyliss>
It would be interesting to ask the Adélie people about it, since IIRC they do most of their development on PowerPC
<ashkitten>
they use clang+musl?
<qyliss>
apparently I got it wrong and they use gcc+musl
<ashkitten>
yeah so the issue is only with clang+musl on ppc
multi has joined #nixos-dev
<qyliss>
Yeah, I thought that was what they used
<qyliss>
multi (who just joined) is my Adélie friend and may know things
<multi>
o/
<ashkitten>
ahah hi multi
<multi>
hello
Melkor333 has joined #nixos-dev
<multi>
so, wrt clang/musl on ppc, adelie has working firefox 68 esr (bar some endianness bugs in the gfx) working on ppc64
smaeul has joined #nixos-dev
<multi>
which, as a pre-requisite needs llvm, clang and rust, all of which work well enough to make firefox work
<multi>
don't yet have firefox working on ppc32, though iirc that's a rust issue
<qyliss>
idk what the current state of ppc in nixpkgs is, but I will be doing ppc64 and x86_64 builds for Spectrum since PPC is much more trustworthy, so do have an interest in good Nixpkgs support for it
<multi>
as far as i know, the clang/musl floating point things on ppc are related to the fact that there are multiple ABI specs for powerpc (possibly just ppc64), and musl supports a specific ABI version and a specific floating point ABI
<multi>
(though any more details will have to come from someone more knowledgable than i)
jtojnar has joined #nixos-dev
ris has joined #nixos-dev
ky0ko has joined #nixos-dev
<ashkitten>
ky0ko is my froebel dev gf
<ky0ko>
hi
<multi>
ky0ko: oh hi, i believe we might have met elsenet
<ky0ko>
multi! i do believe so
<FireFly>
heh
<ky0ko>
i think as goshfuckingdarnit
<multi>
yep, that's it
<multi>
i think i also have a shell account on one of your netbsd boxen
<qyliss>
am enjoying the channel flood of presumably Power-interested people?
<ashkitten>
we requested backup :)
<multi>
haha
<qyliss>
ky0ko: am curious what the floating point quirks ashkitten referred to are
ky0ko has quit [Disconnected by services]
ky0ko has joined #nixos-dev
<ky0ko>
whoops, connection dropped
<ky0ko>
anyway, so, my understanding of the issue is that the power spec defines an abi for power with a long double fla
<ky0ko>
floating point implementation
<ky0ko>
that is not compatible with ieee. musl says, no, we will support only ieee. gcc supports both. clang follows the power spec.
<multi>
huh, interesting
<multi>
ky0ko: before you /joined, i noted that adelie has working firefox 68 (and therefore llvm, clang and rust) on big endian ppc64 agains musl, so i don't know where that figures with the fp abi stuff
<multi>
though iirc for ppc64 at least there are multiple ELF abi versions
<ky0ko>
i know there are ways to work around the issue but none that have allowed me to build musl with clang
<multi>
that sounds like a question for #musl
<ky0ko>
yeah, ill probably end up poking around in there when i attempt froebel on ppc again
<ashkitten>
ky0ko: btw there's nothing addressing ppc in the musl faq
<ky0ko>
i swear there was when i worked on this before
<ashkitten>
it lists it with other supported architectures but that's the only mention
<smaeul>
the fp ABI requirement is noted in musl's INSTALL file
<clever>
ive also wanted better cross options available on nixpkgs
<smaeul>
ky0ko: the elfv2 ABI defines ABIs for both IBM double-double and IEEE binary128 as long double
<clever>
for example, there are x86 32/64bit muslc options, (called musl32 and musl64)
<clever>
and there is an arm musl, called muslpi
<clever>
but there is no aarch64 muslc option
<clever>
and its not clear if muslpi is v6 or v7
<smaeul>
ky0ko: as of clang 9 it will have the same CLI options as gcc for choosing the ABI: -mlong-double-{64,128} -mabi={ibm,ieee}longdouble
<ky0ko>
oooh good, i have been eagerly awaiting llvm/clang9 and that is another reason to want it
evanjs| has quit [Ping timeout: 245 seconds]
evanjs| has joined #nixos-dev
Melkor333 has quit [Ping timeout: 264 seconds]
evanjs has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
evanjs has joined #nixos-dev
v has joined #nixos-dev
infinisi1 has joined #nixos-dev
infinisil has quit [Read error: Connection reset by peer]
andi- has quit [Ping timeout: 264 seconds]
jtojnar has quit [Read error: Connection reset by peer]
andi- has joined #nixos-dev
jtojnar_ has joined #nixos-dev
infinisi1 is now known as infinisil
psyanticy has quit [Quit: Connection closed for inactivity]
<thoughtpolice>
emily: I have less time to do FPGA work these days so having someone else keep them so up to date is nice! Please feel free to submit plenty
<emily>
my guess as to why it broke on 10.14 is Apple deprecating OpenGL took it out of the default header include path
<emily>
it seems to be able to link fine, just can't find the GL headers without a prod
<gchristensen>
I didn't expect aarch64 to be easier to support compared to macos, but here we are
<thoughtpolice>
Well it's been a long fight. aarch64 has most of the bugs rattled out at this point, but more importantly we can finally get fast hardware. If it didn't cost a trillion dollars to buy macOS builders it would be in a lot better shape I think.
<emily>
one of the reasons I abandoned macOS was the increasing amount of pain to get bog-standard free software tooling working, so I can't say I'm too surprised :/
<gchristensen>
tell me about it
<thoughtpolice>
Truthfully I think most Linux based archs would in general be easier to support, providing we could get fast hardware. Once a bunch of core packages work a lot of others come "for free". ppc64 has quite mature Linux support, for instance.
<qyliss>
I'm going to be running NixOS on ppc64 shortly
<qyliss>
(like, in a few months)
<gchristensen>
oh?
<gchristensen>
le?
<thoughtpolice>
Yeah, le is really the main supported variant these days, and others are even dropping ppc64be support.
<thoughtpolice>
All POWER9 support for distros is -le, AFAIK, though some still offer -be.
<qyliss>
I want Spectrum to have first-class ppc64 support, so there's an option to use actually trustworthy hardware
<gchristensen>
qyliss: what ppc64 hw are you getting?
<qyliss>
(ie, with free auditable software down to the microcode)
<qyliss>
A Talos II
<gchristensen>
nice
<thoughtpolice>
The Talos II if you want free firmware.
<thoughtpolice>
Yeah. I've been thinking about a Blackbird myself.
<qyliss>
I was forward thinking enough to put a hardware budget into my grant proposal without knowing at the time what I would spend it on ;)
<qyliss>
I plan on building all my x86_64 packages on it too, so they're built trustworthily even if the endpoints aren't.
<thoughtpolice>
qyliss: Technically I think the HiFive unleashed (the only "real" Linux RISC-V hardware you can get), from what I can tell, is roughly on par with the Talos now. But not as powerful. They released the blob source code of their bootloaders late last year (and people even proved the provided code matched the images). Though, you can't reflash the bootroms. I think that's all that was missing.
<thoughtpolice>
You can skip those bootloaders though with the right settings and boot in theory to coreboot/Linux directly. The hardware is not as robust, though.
<thoughtpolice>
Maybe the ethernet controller has a blob. I'm not sure. I know people are working on reversing the Talos ethernet blobs, though.
<qyliss>
thoughtpolice: yeah, but way more expensive for what you get
<qyliss>
And I can't afford both, so POWER9 seems like the practical choice
<thoughtpolice>
I'd agree.
<qyliss>
I'll gladly take somebody's money if they badly want RISC-V though :P
Jackneill has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
evanjs| has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
evanjs| has joined #nixos-dev
__monty__ has quit [Quit: leaving]
joepie91___ has joined #nixos-dev
joepie91___ has joined #nixos-dev
joepie91___ has quit [Changing host]
joepie91___ has quit [Remote host closed the connection]
not-joepie91 has quit [Ping timeout: 252 seconds]
jtojnar_ has quit [Remote host closed the connection]
evanjs has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
evanjs has joined #nixos-dev
{^_^} has quit [Remote host closed the connection]
{^_^} has joined #nixos-dev
evanjs has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
evanjs has joined #nixos-dev
<qyliss>
infinisil: is there a reason services.znc.useLegacyConfig is true?
<infinisil>
qyliss: Backwards compatibility
<qyliss>
presumably we should default it to false at some point?
<qyliss>
else it'll never be used
<infinisil>
Well people can disable it when they see it, but yeah might be nice to default it to false in the future
<infinisil>
Maybe with a migration path through no default (and forcing the user to set it)
<qyliss>
I think it's generally considered reasonable to break people's configs on new release series?
<qyliss>
(Assuming good release notes, and stuff)
<infinisil>
Hm I'm not a fan of silent breaking changes
<qyliss>
You could use system.stateVersion if you _really_ wanted to
<qyliss>
But that's not really what it's for and I think it would be overkill
<qyliss>
I think people doing major upgrades expect changes
<infinisil>
I think stateVersion is only meant to be used for stateful stuff on disk, not the configuration
<qyliss>
Otherwise, like, what's the point?
<infinisil>
The migration path through no default would at least give users an error that they need to either set useLegacyConfig = true; or migrate their config to services.znc.config
<qyliss>
I don't think it would be a silent failure
<infinisil>
People want to see options in the manual
<infinisil>
But if only a .config/.settings option is provided, that's not the case
<qyliss>
we can't be a single manual for every packaged service, surely?
<gchristensen>
I feel the opinionated options in the manual are so valuable and is a big part of what makes nixos successful
<infinisil>
Yeah we can't, but like the most popular/useful options would be nice
<qyliss>
hmm
<qyliss>
yeah, I can see the argument
<gchristensen>
if they want something super tuned and well specified, then write your own module (effectively what the .settings / .config options give you)
<infinisil>
Yeah, .settings for advanced/special needs
<emily>
so um, checkPhase defaults to VERBOSE=y and even checkFlags = [] doesn't work because that evaluates to empty in bash. this breaks things for the package I'm trying to enable tests for, but also... why is this behaviour a thing? it seems like a pretty weird default
<infinisil>
But .enable + the modules options (without .settings) should be all what you need to get started
<infinisil>
(ideally only .enable)
<emily>
I'm currently trying with checkFlags = [" "] and kind of hating myself for it. I can just override checkPhase, but...
<emily>
(it breaks because it recurses down into a makefile that does $(VERBOSE)gcc, so you get exciting errors about ygcc not existing.)
<emily>
from grepping this breaks at least one other package (bitlbee)
<qyliss>
I'm sceptical of the "opinionated options" thing, but could probably be convinced. Let me give an example:
<qyliss>
The NetworkManager module provides a way to randomize your MAC address
<qyliss>
But I disagree with the way it does it. It randomises the whole thing, which makes you really easy to fingerprint because you're that one person with the non-sensical MAC addresses
<qyliss>
So I instead just write my own extraConfig that randomises only the device identifier, not the manufacturer
<gchristensen>
yeah I think that is a reasonable disagreement to have
<gchristensen>
that seems perfect!
<qyliss>
But, I've never tried to upstream this
<gchristensen>
this feels like a total win to the module system
<qyliss>
Because my preferences are not those of whoever added that option
<qyliss>
And it's not clear to me where this ends
<gchristensen>
as far as I read it, your example is so clearly in favor of what we have
<infinisil>
qyliss: You mean the `wifi.scan-rand-mac-address=${if cfg.wifi.scanRandMacAddress then "yes" else "no"}` thing?
<qyliss>
no, the one that randomises in all cases, not just scanning
<gchristensen>
(a) an option exists demonstrating something is possible, (b) you don't like it (c) you can trivially implement it yourself without editing the core code
<infinisil>
macAddressOpt = "random"?
<qyliss>
right, but if I hadn't read the docs/source, I wouldn't know it was doing something I didn't like
<qyliss>
And, I had to write raw config, rather than nice nix modules
<infinisil>
So you're arguing for having an extraConfig option of type string?
<qyliss>
No I'm arguing against that
<gchristensen>
yeah, but if the nix code becomes the equivalent of raw options, nix becomes a bad abstraction :)
<infinisil>
Ah
<qyliss>
It should be structured
<infinisil>
Yeah got it, with structured you could overwrite the hardcoded default
<infinisil>
(well hardcoded to the option)
<gchristensen>
you can only structure the world so much before you're at a severe impedence mismatch
<qyliss>
well, look at znc
<qyliss>
we moved to a structured config, and reimplemented our specific options on top of that
<qyliss>
That's not possible in all cases, but in this one it works great
<qyliss>
I think what I would like is a clear separation of NixOS config options and upstream config options.
<qyliss>
Because, like, if NetworkManager had a "randomize mac address" option, I'd instinctively trust that a lot more than if it was implemented in NixOS.
<gchristensen>
sure
<infinisil>
qyliss: Wait can you link to the randomization implemented in NixOS?
<infinisil>
I'm not sure I'm getting what you're talking about
<qyliss>
maybe it changed
<qyliss>
let me see
<gchristensen>
yeah so it sounds like the random mac example is a bug which should be fixed
<gchristensen>
and lucky us we have an expert who knows better :P
<qyliss>
Really? As "expert" I am hesitant to make the suggestion
<qyliss>
Especially since it would redefine "random"
<qyliss>
The current behaviour is certainly more random
<infinisil>
Changes from "A completely random MAC address" to "A completely random realistic MAC address"
<infinisil>
Which sounds like a more reasonable random
<qyliss>
sure, but then do we introduce a "reasonable-random" option?
<qyliss>
(probably not, but this kind of question makes me uncomfortable)
<qyliss>
(I'm trying to actually find what code I'm actually talking about, btw. I'm starting to wonder if I dreamed it lol.)
<qyliss>
I suppose what I should have done is added whatever the functionality was to the core module
<qyliss>
But that's sort of going against what gchristensen said as the spirit of the thing
<gchristensen>
I think it is reasonable that advanced use cases end up implementing their own modules
<gchristensen>
that seems like a good thing: nixos' defaults provide good defaults for the 80%, and the 20% is done elsewhere
<qyliss>
yeah...
<qyliss>
although I think it's good to address the remaining 20% when we can
<gchristensen>
yeah, sure
<qyliss>
like, in this case, I should have just added an option for the one line I presumably needed
<gchristensen>
though not at the expense of contorting the code or the 80% users
<qyliss>
Sure
<infinisil>
gchristensen: Huh, you mean people should copy the huge nginx modules if they want to modify something more special?
<gchristensen>
well they may not need the complexity of the nginx module at all for their special case
<qyliss>
Structured config is nice, though, because it means I can, for example, set things in multiple modules
<qyliss>
And it's difficult to predict when that would be useful
<infinisil>
I think it's very useful for providing defaults/changing them
<qyliss>
Yeah.
<qyliss>
types.lines is very useful too
<infinisil>
Explain? This messes with .settings options!
<qyliss>
types.lines is great when you just need a list of something, composed in multiple modules
<qyliss>
I don't have a good example. A list of users allowed to do something, maybe.
<infinisil>
Then I'd use `types.listOf ...`
<qyliss>
Can multiple modules append to that?
<qyliss>
If so then sure, that's fine too.
<infinisil>
Yeah
<qyliss>
types.lines is just what I think of when I think of multiple modules
<edef>
qyliss: i think it's the "locally generated" bit
<infinisil>
Actually list options are kind of annoying in that you can't modify elements, you can only add new ones
<infinisil>
Contrary to `attrsOf` where you can address each element by their attribute name
<qyliss>
Also true
<infinisil>
I've thought of having a type like `types.indexedListOf` where you can do `{ "12" = "foo"; }`
<qyliss>
I think this conversation has made me realise that, despite knowing I have strong opinions on this topic, I haven't actually got a clue what those opinions are.
<infinisil>
And the resulting list would be sorted by indices you provided
<qyliss>
Why not just use an attrsOf for that?
<infinisil>
Hm
<infinisil>
Yeah that maybe makes more sense
<infinisil>
If you need a list in the end you can just do attrValues
<infinisil>
Maybe we should deprecate types.listOf :P
<hyperfekt>
I started patching modules just so I could implement advanced options but not have to copy a module cause I want to keep getting upstream changes. I tried extending options via Nix first but it was a terrible experience.
<edef>
qyliss and i just use git subtrees
<edef>
so we can patch nixpkgs with reckless abandon
<infinisil>
edef: Huh never heard about subtrees, so you have all of nixpkgs commit in your history?
<infinisil>
s/commit/commits
<hyperfekt>
Yeah, most people seem to do that. I didn't want to maintain a repo so I get my nixpkgs from an IFD that applies the patches. Makes it easy to not include them if the module isn't used.
<hyperfekt>
(where 'that' = some form of nixpkgs fork, be it submodules or else)
<qyliss>
I like that the subtree means I can seamlessly modify Nixpkgs
<edef>
infinisil: yep
<infinisil>
edef: Okay so I'll probably stick with git submodules, even though they're a bit of a pain
<infinisil>
My commit history won't be messed up like that :)
<hyperfekt>
That sounds neater than generating and vendoring or fetching patchfiles like I do. But I would guess you do lose some oversight since it's not immediately apparent which patches are where and why?
<edef>
this is true
<edef>
i can diff with upstream fairly easily tohugh