<steveeJ>
still debugging this network issue here. what could the reason for `systemd[1]: Timed out waiting for device sys-subsystem-net-devices-eth0.device.` be? The device is actually working partially. Could networking in initird be related?
c0bw3b_ has quit [Remote host closed the connection]
<ottidmes>
steveeJ: I had problems with my network when I started in initrd to enable SSH to unlock my encrypted drives, but in my case it was a matter of explicitly mapping eth0 to a ethernet controllers MAC via an udev rule
<steveeJ>
ottidmes: oh that sounds really fiddly. I'm currently preparing to take the network down again in `boot.initrd.postMountCommands`
<ottidmes>
steveeJ: tried that too, but it did not work for me
<lunik1>
aha, I have my mtp device mouting as root, but it fails as my user with "libusb_open() failed!: Permission denied". do I need to put myself in some group?
<steveeJ>
ottidmes: what exactly did you try?
<ottidmes>
steveeJ: its been a while, but what I remember was after unlocking succesfully, to try and clear the network connection
<steveeJ>
ottidmes: and were/are you using the predictable interface names?
Rusty1 has joined #nixos
<steveeJ>
ottidmes: it also seems that udev wants to rename eth0 to something and can't on the system
justanotheruser has joined #nixos
<steveeJ>
`systemd-udevd[710]: Error changing net interface name 'eth0' to 'ens18': Device or resource busy`
<ottidmes>
steveeJ: yeah, those kind of problems sound familiar
<ottidmes>
steveeJ: I actually like eth0, and its as safe as persistent names due to mapping it directly to the MAC
<steveeJ>
ottidmes: did you try to disable networking.usePredictableInterfaceNames?
<ottidmes>
steveeJ: in my initrd-ssh.nix I have networking.usePredictableInterfaceNames = false; so yeah
<ottidmes>
steveeJ: and I have this snippet (making a gist)
ng0 has quit [Quit: Alexa, when is the end of world?]
<steveeJ>
it throws an error about an unsupported command, likely the delete one
<steveeJ>
but now in stage2 it was renamed to ens18
<ottidmes>
steveeJ: I just did not like having to deal with all those different names on different machines, I like persistent consistent naming ;)
<steveeJ>
ottidmes: agreed. I'm turning the predictable names off now
<steveeJ>
ottidmes: that udev workaround seems undesired too though
<steveeJ>
I wonder if you need it if you teardown the network
<{^_^}>
[nixpkgs] @matthewbauer merged pull request #50556 → curl: move option defaults from `all-packages.nix` to the derivation itself → https://git.io/fpcCE
<{^_^}>
[nixpkgs] @matthewbauer pushed 2 commits to master: https://git.io/fpcdE
<ottidmes>
steveeJ: you do, I asked the same at the time, I was told something along the lines of, persistent names were introduces for a reason, you cannot actually be sure that what is eth0 now, will always be so, so its safer to actually be explicit about it
<steveeJ>
ottidmes: so you need the MAC address of each NIC at buildtime
<steveeJ>
I think in case of VMs it's more deterministic without the predictable names
<ottidmes>
steveeJ: just like you need the UUID of a hard drive? I do not see the problem?
equalunique has quit [Read error: Connection reset by peer]
boogiewoogie has quit [Quit: Leaving]
equalunique has joined #nixos
<steveeJ>
it's not a problem per-se. I don't think you actually need it in case a VM has only one NIC
<ottidmes>
steveeJ: could be, its not a big deal for me to fill in the MAC just once, but I can see that it would be annoying if you scale things
<steveeJ>
I just confirmed it. I don't need the udev rule on the VM
<steveeJ>
ottidmes: thanks a lot for your pointers
slyfox_ has quit [Ping timeout: 272 seconds]
lunik1 has quit [Read error: Connection reset by peer]
romanofskiWork has quit [Ping timeout: 268 seconds]
hdeshev has quit [Quit: Leaving.]
thc202 has quit [Ping timeout: 240 seconds]
drakonis has joined #nixos
mayhewluke has quit [Ping timeout: 245 seconds]
mayhewluke has joined #nixos
<steveeJ>
ottidmes: have you thought much about automating the unlocking process?
Rusty1 has joined #nixos
<steveeJ>
ottidmes: I'm thinking about having the initrd knock somewhere which then in turn connects via ssh and unlocks the disk. the issue is to verify the identity of the booting machine
<steveeJ>
I think that's what's TPM is for but the VM doesn't have that of course
<{^_^}>
[nixpkgs] @matthewbauer pushed 2 commits to staging-next: https://git.io/fpcFI
Rusty1 has quit [Quit: Konversation terminated!]
<ottidmes>
steveeJ: thought about it, but how is that going to work, what then is the point of locking? How do you make that approach safe, who vouches for the one accessing it?
<steveeJ>
ottidmes: I haven't come up with a safe solution for it
<lunik1>
anybody around who knows much about udev?
<infinisil>
,ask lunik1
<{^_^}>
lunik1: Just ask your question. It's the best way to know if anybody can help.
<lunik1>
fair enough!
ajs124 has quit [Quit: Gateway shutdown]
<{^_^}>
[nixpkgs] @jerith666 opened pull request #50653 → elm: extract makeDotElm and fetchElmDeps → https://git.io/fpcFE
hedning has quit [Quit: hedning]
hedning has joined #nixos
<lunik1>
I'm trying to connect to my android device with mtp as a non-root user. When I try I get the error "libusb_open() failed!: Permission denied", so I've tried to add a udev rule to give my user the required permissions.
<lunik1>
I used services.udev.extraRules and the rule appears in /etc/udev/rules.d/99-local.rules, but it doesn't seem to have had any effect
<ottidmes>
lunik1: you might also try the sudoers config file instead of udev
Ariakenom_ has quit [Read error: Connection reset by peer]
<{^_^}>
[nixpkgs] @matthewbauer pushed 155 commits to staging: https://git.io/fpcFQ
<{^_^}>
[nixpkgs] @matthewbauer pushed commit from @exarkun to staging « 50629.cross compile libksba (#50649) »: https://git.io/fpcFx
erictapen has quit [Ping timeout: 276 seconds]
<lunik1>
ottidmes: I can sudo, but because of mtp weirdness I can't seem to give my user access to the device if I mount it with sudo
ajs124 has joined #nixos
romanofskiWork has quit [Ping timeout: 240 seconds]
Rusty1 has joined #nixos
<neonfuz>
mtp sucks
<elvishjerricco>
$ nix run -f channel:nixpkgs-unstable hello
<elvishjerricco>
error: unexpected end-of-file
<elvishjerricco>
Uh
<elvishjerricco>
That's bad.
<elvishjerricco>
It downloads it correctly, and if I use a local checkout of nixpkgs-unstable, I get the same error
<elvishjerricco>
But if I use an 18.09 checkout, no such error
<elvishjerricco>
This is on Darwin (Mojave)
phreedom has joined #nixos
<elvishjerricco>
to clarify, it downloads the channel source correctly. It makes now attempt to download the package because the failure is at eval time
<{^_^}>
[nixpkgs] @matthewbauer closed pull request #38624 → [wip] codesigning on Darwin → https://git.io/vx7kW
<elvishjerricco>
Ok yea, it works for any derivations that I have already built. But anything that needs building / substituting does not work.
romanofskiWork has joined #nixos
<{^_^}>
[nixpkgs] @CMCDragonkai opened pull request #50655 → python-mnist: init at 0.6 → https://git.io/fpcbR
<exarkun22>
Can I tell nixops I don't want polkit by default in my logical config?
<{^_^}>
[nixpkgs] @peti pushed to haskell-updates « hackage-packages.nix: automatic Haskell package set update »: https://git.io/fpcb9
lassulus_ has joined #nixos
qyliss^work has quit [Quit: bye]
qyliss has quit [Quit: bye]
alex`` has quit [Ping timeout: 268 seconds]
justanotheruser has quit [Ping timeout: 252 seconds]
Lisanna_ has quit [Remote host closed the connection]
lassulus has quit [Ping timeout: 272 seconds]
lassulus_ is now known as lassulus
<aminechikhaoui>
exarkun22 maybe you can get something from `nix why-depends /run/current-system/ nixpkgs.polkit` on the target machine
<aminechikhaoui>
or the store path of polkit instead of nixpkgs.polkit
Chiliparrot has joined #nixos
<exarkun22>
unfortunately I don't have a working system so why-depends doesn't help. but... I think I know what is dragging in polkit, but I have no idea where the definition of that thing is.
<exarkun22>
one of the things `nixops deploy ...` creates/uses/whatever is /nix/store/p5is7d7kdkqhyvckzn39aa3pchyn5pws-nixos-system-rpi-18.09.1228.a4c4cbb613c-armv7l-unknown-linux-gnueabihf.drv
<exarkun22>
`nix show-derivation` shows me that drags in a bunch of random stuff, including polkit
worldofpeace has joined #nixos
<exarkun22>
but I have no idea where the expression for that derivation is
<exarkun22>
that's what I said just a fewmessages above right?
jperras has quit [Quit: WeeChat 2.2]
<exarkun22>
cool, didn't know about show-option either, thanks
<exarkun22>
I tweaked the setting and started a new deploy so now it shows `false`, not sure what it said before
<aminechikhaoui>
ah right didn't see all your previous messages, yeah nixops doesn't add much options, it's mostly NixOS options that you set in the machine config
<worldofpeace>
I'm looking to help document this. So can breaking changes go to staging? Currently we're saying "non-breaking mass-rebuild commits" but it happens anyway :)
<colemickens>
Before I dive down this rabbithole... is it easy to use the ccache infra in nixpkgs?
<colemickens>
for something like chromium?
lsyoyom has joined #nixos
ekleog has joined #nixos
fusion809 has quit [Remote host closed the connection]
lsyoyom has quit [Ping timeout: 268 seconds]
c0ffee152 has quit [Quit: Lost terminal]
<worldofpeace>
Ralith_: If you pass an `overlays` argument to the nixpkgs function it will be used. So like `with import <nixpkgs> { overlays = [ (import ./overlay.nix) ]; };`
drakonis1 has quit [Quit: WeeChat 2.2]
reinhardt has joined #nixos
drakonis has joined #nixos
<jackdk>
worldofpeace: I was playing with overlays on the weekend. Even with overlay.nix being `self: super: {}`, neglecting the parens around the import would trigger infinite recursion. Do you know why?
<mdash>
jackdk: gotta put parens around stuff in lists because spaces separate list elements.
<jackdk>
right, but why does [ import ./overlay.nix ] (say) even parse?
<jackdk>
as in, what is its parse and how does that trigger infinite recursion?
<Ralith_>
worldofpeace: "in addition to the environment's" was an important part of the question
<Ralith_>
doing that clobbers the environment's overlays
<worldofpeace>
yeah it will completely ignore the environments overlays
<{^_^}>
[nixpkgs] @mredaelli opened pull request #50699 → pymssql: init at 2.1.4 → https://git.io/fpCYt
ottidmes has joined #nixos
<srhb>
teto: Yes, you can.
<tobiasBora>
manveru: something like that, but I think to remember that on debian for example I can install it system-wide instead of asking to all the users to install this
hedning has quit [Ping timeout: 250 seconds]
<manveru>
tobiasBora: i don't think there's support for that yet
<hyper_ch2>
Mic92: assuming I have two zfs pool, both encrypted, one acts as root "/" and has the key for the second pool in "/root/zfs.key" - how would I auto-import the second pool and have the key supplied?
<Mic92>
hyper_ch2: this is not possible with our current module. You would need to write your own mount unit that has a `RequiresMountsFor=` dependency
<{^_^}>
[nixpkgs] @orivej opened pull request #50702 → eigen: replace with eigen3_3: 3.2.10 -> 3.3.5 → https://git.io/fpCOm
<hyper_ch2>
Mic92: hmmm, also the pool import would need to be done with -l option
<hyper_ch2>
Mic92: how would one go about writing such a module?
<tobiasBora>
manveru: Hum... I tried to "nix search firefox-bin", and I've zero result. For now, I setup "i18n.defaultLocale = "fr_FR.UTF-8";" as well as "environment.systemPackages = [... firefox ]"
<manveru>
any process you start from the shell inherits those vars :)
<teozkr>
yeah.. I wanted to import Python dependencies directly when running in a `nix-shell`
<teozkr>
so that I could run `nix build` and it'd go through all the normal nice build isolation and testing, or run `nix-shell` and get cross-project live reloading
<teozkr>
but it's way too messy to be practical anyway
<ottidmes>
I am trying to get a nix-shell environment to debug my derivation, since I have one big script, I opted to use the builder option, how do I access this from nix shell? I have defined multiple functions similar to the phases, like unpackPhase, but they are not defined, so clearly the builder script has not yet been run, how do access that?
__monty__ has joined #nixos
<symphorien>
Maybe source $builder
crmlt has joined #nixos
layus has joined #nixos
<ottidmes>
symphorien: I tried that, but when I echo $builder, it returns: /nix/store/czx8vkrb9jdgjyz8qfksh10vrnqa723l-bash-4.4-p23/bin/bash
<layus>
Mic92, what is all that fuss about adding `runHook preInstall` in buildPhase ?
<ottidmes>
while it is defined in my derivation as: builder = ./builder.sh;
crmlt has quit [Client Quit]
crmlt has joined #nixos
<Mic92>
layus: just for people who wants to use those hooks in their overrides
<Mic92>
oh, preCheck is not correct in installCheckPhase
<tobiasBora>
manveru: ok I'll try it then. What's the difference between firefox and firefox-bin?
<ottidmes>
And when I just source it directly myself, I get: bash: pkgBuildAccumVars: readonly variable
<Mic92>
tobiasBora: firefox-bin is precompiled binaries from mozilla
<Mic92>
*are
<tobiasBora>
ok thanks. I'll try then, thank you!
crmlt_ has joined #nixos
<{^_^}>
[nixpkgs] @Mic92 pushed to master « jflex: run correct hooks in installCheckPhase »: https://git.io/fpCGt
ninjin has quit [Quit: WeeChat 2.2]
<ottidmes>
I will just rewrite it not to use a builder script but the normal phases
vmandela has joined #nixos
<ottidmes>
I am going to install my new PSU now, bye
<zemm>
is there a nix rpm available somewhere? i see there's a spec file in nixos/nix , and the manual has line "If you install from RPM packages...", but can't find such
<zduch4c>
hello, is the default NixOS Emacs package compiled with ImageMagick support?
<etu>
zduch4c: Should be, from reading the source.
joehh has joined #nixos
<etu>
As long you pick the one that isn't noX
alex`` has quit [Ping timeout: 240 seconds]
<zduch4c>
hm… emacs keeps crying i need ImageMagick support when using image-mode,
<zduch4c>
for example
<zduch4c>
maybe I need some additional library installed?
<Mic92>
zemm: to be honest I never used the rpm archives. This was presumly only tested by Dezgeg. However the way it was build should make this type of packages resilient.
Lisanna has joined #nixos
iyzsong has joined #nixos
zduch4c has left #nixos ["ERC (IRC client for Emacs 26.1)"]
<{^_^}>
#48378 (by bgamari, 5 weeks ago, closed): [WIP] Port switch-to-configuration script to Python
boogiewoogie has joined #nixos
<gchristensen>
Git requires perl though, ...
<exarkun22>
according to nix-store --query --tree this perl dependency comes from /nix/store/b6l2q43n6mfld9hck373ysqq9ak6zisy-nixos-system-rpi-18.09.git.c23e564-armv7l-unknown-linux-gnueabihf.drv, that's all I really know
<exarkun22>
well, actually, I suppose I can guess that since nixos-system-rpi also depends on /nix/store/1hkp2n6hz3ybf2rvkjkwrzgbjkrrakzl-update-users-groups.pl it has something to do with that.
alex`` has quit [Ping timeout: 245 seconds]
<symphorien>
nixos-rebuild and al depend on perl scripts
<tilpner>
exarkun22 - "It's technically possible, but completely unpractical" or "It's doable, but can be hard"?
<exarkun22>
tilpner: the former I _think_
<tilpner>
Hmm, then I wonder what software rendering actually is
<tilpner>
I just want a very slow desktop :/
<exarkun22>
tilpner: maybe I missed some context.
<exarkun22>
tilpner: and I don't know what "sway" is
<tilpner>
sway is a wayland compositor
<exarkun22>
oh
<exarkun22>
can you use a non-compositing wm instead?
<exarkun22>
I think compositing w/o hardware support isn't "slow" it's "die of boredom"
<tilpner>
I would like to, but X doesn't start because "open /dev/dri/card0: No such file or directory"
jperras has joined #nixos
<exarkun22>
okay. I'll amend my guess to "doable but hard" if the goal is just non-hw-accelerated desktop. I've never used nixos with a desktop though, never configured X with it, etc, so not sure how much help I can be in practice.
<tilpner>
Heh, doing servers gets you out of most driver problems. Thanks anyway :)
<exarkun22>
I can't use why-depends because the derivations don't all build
<gchristensen>
doesn't why-depends work on .drv's too?
<symphorien>
it first starts to build the drv
<gchristensen>
o
<avn>
drvs written on instantiation phase, isn't it?
<gchristensen>
yeah
<exarkun22>
I guess maybe I could ask it about the x86_64 versions... they probably maybe could have the same dep tree as the armv7 cross-compiled tree...
<gchristensen>
what about nix-store -qR --tree /nix/store/b6l2q43n6mfld9hck373ysqq9ak6zisy-nixos-system-rpi-18.09.git.c23e564-armv7l-unknown-linux-gnueabihf.drv and lok for libwww-perl
<{^_^}>
[nixos-org-configurations] @edolstra pushed 3 commits to master: https://git.io/fpC2e
m0rphism has quit [Quit: WeeChat 2.2]
<exarkun22>
gchristensen: that's what I did, but the tree is huge and tracking the right lines up and down dozens of pages makes my eyeballs hurt. I tried it and best I can figure, libwww-perl is a dependency of perl5.28.0-XML-Parser-2.44 is a dependency of nixos-system-rpi-18.09.git.c23e564 (which is pretty much the top)
iyzsong has quit [Ping timeout: 252 seconds]
<exarkun22>
iow, it seems to me whatever it is a dependency of must appear as a sibling of it in the tree instead of a parent. which sounds like a bug in nixops to me but that doesn't help much.
emilis has quit [Quit: Leaving]
<exarkun22>
(the fact that an XML parser library has an http client as a dependency is a huuuuuuuuuge red flag but I can't even see that red flag under the even huger red flag of perl itself.)
m0rphism has joined #nixos
m0rphism has quit [Client Quit]
<samueldr>
how else would it load the DTDs and such?
* exarkun22
teardrop.
<gchristensen>
exarkun22: yeah, having a client is basically a requiremnet for an xml parser :')
<exarkun22>
wait are you guys serious
<gchristensen>
lol yes
<exarkun22>
actually loading DTDs in an XML parser is basically a guarantee of getting owned
ng0 has quit [Remote host closed the connection]
<exarkun22>
if you care about validation, you ship all of the DTDs with the application and load them from local disk when necessary
<gchristensen>
Nix doesn't care what features you use. it is possible, it is a dependency, it is shipped
<exarkun22>
sure sure, it's not Nix's fault
<exarkun22>
It's Perl's fault
<gchristensen>
well, XML's probably
<exarkun22>
yea you could make that case, though the Perl XML library author could have refused to implement something so insecure
<exarkun22>
(although I guess I could say the same thing about Nix's Perl packager :smile:)
<gchristensen>
under the assumption it is part of the spec: then it wouldn't be a valid implementation
<exarkun22>
gchristensen: we could talk about who programmers have a greater ethical obligation to: specification authors or end users :)
<gchristensen>
the end users, who are expecting implementations to follow the spec, since the end users are also end users of the spec
<samueldr>
in 1998 things sure were different
<exarkun22>
Sure, if the spec is beneficial to the end user. It's only interesting when the spec and the end user are in conflict.
<exarkun22>
samueldr: indeed.
<gchristensen>
make your own eXMLarkun22 spec without the bad stuff and publish it as a conforming implementatino? :)
<exarkun22>
Okay so I only find uses of Perl's XML parser in nixos and I don't even find any uses of it in any of the perl scripts that are dependencies of this particular derivation. I wonder if the xml parser is just installed regardless on the assumption that most nixos systems will need it?
<exarkun22>
gchristensen: there are actual real-world xml parser implementations that don't open arbitrary network connections when they encounter a DTD, you know.
<exarkun22>
I thought everyone made up their mind this was a Good Thing about 10 years ago
<gchristensen>
that particular XML parsing package is used by more than just nixos, yeah
<exarkun22>
Actually, for all I know, Perl's XML parser doesn't load DTDs from the network by default. Maybe it requires some whitelist or an explicit flag to enable it. It would still end up with a LWP dependency in those cases.
<exarkun22>
gchristensen: Yea, I get that - but I'm not actually installing any software except for nixos yet. So it's not an application dragging it in, either.
<exarkun22>
It's just some part of nixos or nixops that I can't find.
<exarkun22>
so you can move files around without breaking those links... so you could bucket them by number of links and move them around when number of links changes.
<avn>
looks like expression in nixpkgs/nixos/modules/system/activation/top-level.nix not use propagation, only directly listed dependencies
<exarkun22>
then garbage collection is "delete everything in /nix/store/has-one-link/"
endformationage has joined #nixos
<exarkun22>
(not that I know anything about designing GCs)
<gchristensen>
that would be extremely expensive upon every build, I think
<symphorien>
you only move the need to stat everything sooner
<exarkun22>
maybe. I think you'd want to measure, for sure.
<symphorien>
also it does not work if the user also creates hard link to the store oustide of nix
<exarkun22>
yea, well, freedom is slavery
<avn>
I still believe that leveling can decrease stat'ing bottleneck
<gchristensen>
yes, leveling would probably be smart
<{^_^}>
[nixos-org-configurations] @zimbatm pushed to document-all-the-things « document the terraform workflow »: https://git.io/fpCw7
<exarkun22>
you can't actually change anything about how nix/store is implemented because "what if the user ..." right?
<gchristensen>
see also the birthday problem domenkozar hit with this
<{^_^}>
[nixos-org-configurations] @zimbatm pushed 0 commits to document-all-the-things: https://git.io/fpCwd
<gchristensen>
exarkun22: the .links isn't a public API so I don't see why we couldn't change it
<symphorien>
otherwise you could say: only stat all the files the gcc actually deleted in the store, and check if nlink=2 before removing
<{^_^}>
[nixos-org-configurations] @zimbatm opened pull request #63 → document the terraform workflow → https://git.io/fpCwN
<symphorien>
s/gcc/gc/
<exarkun22>
how is the nix store public API defined?
<symphorien>
there is a store-api.h exported by nix
<exarkun22>
woah.
<gchristensen>
exarkun22: things in the /nix/store are expected be called by users, and only things anchored by a GC root are in use I think
<avn>
gchristensen: I probably can implement leveling here, but I doubt about upgrade path then
<{^_^}>
[nixos-org-configurations] @zimbatm opened pull request #64 → README: add file with basic structure → https://git.io/fpCrv
<exarkun22>
are there existing benchmarks for store operations?
<symphorien>
avn: if you do this, can you ping me ? I'd have to update nix-du accordingly
<gchristensen>
avn: it would not be so tough, I think, since GC happens with a big lock
<exarkun22>
(how do you know what leveling speeds up and slows down?)
<gchristensen>
I doubt leveling would slow anything down?
<exarkun22>
How about implementing a background lockless GC? :)
<avn>
gchristensen: just link/unlink each file which not a dir on top level?
<exarkun22>
deeper directory hierarchy also means more stats on some operations
<gchristensen>
every call in to the .links would be known ahead of time, so no directory exploration
<exarkun22>
larger filesystem hierarchy means larger filesystem cache
<gchristensen>
ah
vmandela has quit [Ping timeout: 246 seconds]
<exarkun22>
but unlink("foo/bar/baz") is still more expensive than unlink("foo-bar-baz") - some part of the system is turning strings into directory entries
<avn>
exarkun22: .links crawled only during GC, all other using of files there are via hardlinks
<avn>
gchristensen: looks like at least current code can be optimized by using statat/unlinkat (probably ifdef'ed to discriminate darwin ppl)
<symphorien>
avn: you do you say about: when removing files in /nix/store/.trash, stat them and if nlink=2 and this file has a link in .links then also remove it in .links ?
<avn>
symphorien: nope, I chat exclusively about .links walking, and zapping files with linkno == 1
<symphorien>
sorry I meant "what do you say about*"
dbmikus__ has joined #nixos
<avn>
symphorien: you can't find file in .links without whole .links traversal, or file hashing
<symphorien>
hum right sorry
<symphorien>
it's a tredoff
<symphorien>
*tradeoff
<symphorien>
for very small amount of removed things, and huge .links, it might be better
<avn>
and same way replace lstat() with fstatat(dir, name)
<gchristensen>
"qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in """ I thought this wasn't a problem if you didn't nix-env stuff, but I'm having this problem with lots of software now, hrm
<samueldr>
gchristensen: hmm, updates and nix-env or nix-shell would count there too
<avn>
symphorien: and I think, unlinkat give bit more as well
<symphorien>
makes sens
<symphorien>
+e
<gchristensen>
samueldr: I only have one channel: root's nixos channel, and nothing installed via nix-env in any users' profile
mmercier has joined #nixos
<samueldr>
:o then it's weird
<samueldr>
updated and not rebooted since?
<gchristensen>
nope, I did an nixos-rebuild boot --upgrade, then rebooted
<avn>
;)
<avn>
I do rebuild/switch in range from daily to weekly, but reboot few times in year only
<gchristensen>
your poor kernel! :)
<samueldr>
gchristensen: other than qt4 results, anything with: (IFS=: ; for p in $PATH; do echo $p; done | grep -i qt) ; (IFS=: ; for p in $QT_PLUGIN_PATH; do echo $p; done | grep -i qt)
<gchristensen>
$ (IFS=: ; for p in $PATH; do echo $p; done | grep -i qt) ; (IFS=: ; for p in $QT_PLUGIN_PATH; do echo $p; done | grep -i qt)
<gchristensen>
what is the "best" imap sync tool these days?
orivej has joined #nixos
<v0|d>
exarkun22: ping
julm has quit [Ping timeout: 268 seconds]
<exarkun22>
v0|d: hello
<gchristensen>
mbsync / isync is cramping my style since moving messages between directories seems to require stripping out UIDs from filenames and other strange thnigs
<v0|d>
exarkun22: hello, where to go next?
<v0|d>
I see lwp & nspr
<exarkun22>
v0|d: I got to "perl is a nightmare to cross compile and also an inextricable nixos dependency" and I'm kinda stumped now.
<v0|d>
nspr solvd?
<exarkun22>
yea I think so
<exarkun22>
I also added these two things to my logical expr:
<exarkun22>
which I think removed the need to build nspr at all
erictapen has joined #nixos
<exarkun22>
but I also cherry-picked the nspr build fix just in case
<gchristensen>
exarkun22: I suppose you've already decided against compiling locally on the remote machine
<v0|d>
see, let me catch up w/ the latest.
<exarkun22>
oh, I guess that's not cherry-picked it's just hand-applied
<exarkun22>
from the diff in the comment on the issue
<v0|d>
saw the patch.
<exarkun22>
gchristensen: I didn't decide against that, in fact it seems like the only realistic course forward
<gchristensen>
short of rewriting the .pl to .rs
<v0|d>
gchristensen: welcome to nixos cross compiling festival
<exarkun22>
gchristensen: but it also seems like a pretty big pain and I don't know exactly how to do it yet, and also I have $WORK to do :) so letting it stew for a bit.
Chiliparrot has quit [Ping timeout: 260 seconds]
<exarkun22>
"don't know exactly how to do it yet" as in I want a repeatable build/deploy without manual steps like "ssh in to a correctly configured nixos machine and run these commands and then copy the closure to your build machine"
<exarkun22>
something about different-platform substituters and a qemu-arm instance? I don't know.
<exarkun22>
(another option might be to check the existing armv7 binary caches and see if there's a perl build I can use, if I just pick the right nixpkgs git rev)
<gchristensen>
the community machine is armv7l capable
<exarkun22>
ah, interesting. maybe helpful, though I think I do have a system that can build the packages, too.
<avn>
gchristensen: rewrite .pl to .rs is "officially approved" decision?
<exarkun22>
What does Rust cross compilation support look like in Nix? Is it actually good?
<gchristensen>
exarkun22: no idea
<exarkun22>
I had some nasty fights with Rust regular compilation :/ Granted, I know basically nothing about Rust. Still. It was harder than the C stuff.
<gchristensen>
avn: I think it has the best chances of success, but I wouldn't embark upon it yet without further buy-in
<avn>
btw, does nixpkgs still related on buildenv.pl, or it finally deprecated?
<v0|d>
matthewbauer: around?
<exarkun22>
(not that I'd want to rewrite this in C)
dmc has quit [Ping timeout: 240 seconds]
<yorick>
zimbatm: did that terraform nixos provider ever work out well?
polyzen has joined #nixos
<exarkun22>
seems like a functional language would be a better fit with nix in many ways
<exarkun22>
but I already tried cross-compiling ghc with nix and failed :)
<avn>
then we need small (scripting) functional language for various one-file crap
<v0|d>
ppl use lua
<avn>
v0|d: try build few lua extensions with cross ;)
<exarkun22>
they do, it's true.
hyper_ch2 has quit [Quit: Page closed]
<v0|d>
avn: im not the perpetrator here:p
<exarkun22>
realistically, Rust is probably an alright choice. I wish there were a better choice, though.
<exarkun22>
I guess nobody suggested shell yet. in some ways that would be the smallest step away from perl. does not exactly fit the "rewrite as few times as possible" criterion though.
Ariakenom_ has joined #nixos
<gchristensen>
exarkun22: oh dear
<avn>
I once do tail-recurion in shell via `exec $0 $@` (but it was sort of joke of course)
<v0|d>
how do you terminate?
<gchristensen>
the point isn't to take a small step away from perl, but to take the safest step away from perl in a way that will be nice to maintain long-term
<exarkun22>
pretty sure shell is the only realistic competitor to C for "how close to impossible is it to write a safe and correct program" though so that should probably also disqualify it 🙂
<__monty__>
Tbf, php makes it pretty hard.
<exarkun22>
okay, true, it's bad news left and right.
Ariakenom has quit [Ping timeout: 252 seconds]
<avn>
v0|d: it was script which was compare dotted versions, so only one execution branch lead to recursion ;)
<v0|d>
avn: fork bomb:)
drakonis has quit [Quit: WeeChat 2.2]
<{^_^}>
[nixpkgs] @fare opened pull request #50741 → Update gambit and gerbil to new upstream releases → https://git.io/fpCyI
<v0|d>
exarkun22: Still I feel optimistic about cross compiling perl
<avn>
v0|d: nope, it was well tested (even property tested against debian's `dpkg --compare-versions`. Also we haven't more than 3-4 dots in our versions ;))
erasmas has joined #nixos
<exarkun22>
you could switch to python and require this abandonware for easy native & cross-compilation: https://github.com/dropbox/pyston
<gchristensen>
__monty__: not sure if I'd prefer PHP or Bash, if I had to pick one :)
<avn>
pyston was dropped?
<avn>
boo
<exarkun22>
v0|d: I'll definitely cheerlead for you. :)
saltsa has joined #nixos
<v0|d>
no please, im too old for that.
<exarkun22>
avn: looks like they used up their budget of 5000 commits and the team broke up and moved on to other projects.
<exarkun22>
almost 2 years since last commit
<exarkun22>
(it was a dumb idea, come on)
<avn>
5k commits rule?
peacememories has joined #nixos
<v0|d>
OK, back to wrk.
<exarkun22>
avn: yea that's how corporates work, right?
<exarkun22>
avn: you got your budget, you spend it, you're done
<avn>
exarkun22: yes, but based on counter on commits...
<exarkun22>
just one of the many "we'll tackle this super hard problem of speeding up python runtime with no understanding of the difficulty of the task or any past efforts oops this is hard we give up nevermind" projects out there
<exarkun22>
avn: okay maybe I'm being slightly facetious. :)
<avn>
;)
<avn>
I heard google pushed some efforts on python-to-go compiler
<avn>
(although python2rust can bring more fun ;))
<{^_^}>
[nixpkgs] @peti pushed to haskell-updates « all-cabal-hashes: update to Hackage at 2018-11-19T08:07:53Z »: https://git.io/fpCSf
<exarkun22>
pypy is clearly the best possible improvement for python. cpython should be abandoned and future effort should just go there.
<exarkun22>
but just as clearly, python-the-language has a lot of drawbacks and there are other interesting languages out there without those drawbacks ;)
<avn>
exarkun22: I checked pypy last time probably 6-7 years ago, does it support incremental compilation btw?
<exarkun22>
avn: incremental compilation _of the toolchain_? I don't think so.
<exarkun22>
avn: That doesn't really matter for 99% of folks though.
asymmetric has quit [Ping timeout: 260 seconds]
<exarkun22>
v0|d: I started looking at the perl-cross with the notion of making the perl expression conditionally use either that or the regular upstream perl source
hotfuzz_ has joined #nixos
<exarkun22>
v0|d: but perl-cross docs list a lot of caveats. it sounds like you might get a perl build but basically everything still sucks (eg you can't build any _new_ modules for it unless you use also perl-cross).
<exarkun22>
so. seems like a pretty screwed up situation with no good options for a solution.
<v0|d>
exarkun22: checkout buildroot
<v0|d>
maybe they've got something useful
ottidmes has joined #nixos
hotfuzz has quit [Ping timeout: 246 seconds]
<exarkun22>
oh boy.
<v0|d>
ppl are doing it already, I mean perl is so old, I recall using it on SCO Unix.
<v0|d>
prob buildroot have patches that might be useful not sure i'm working on a PR, brb
<ottidmes>
I have a buildPhase that is not using make, if I run it in nix-shell is skips it because of the lacking Makefile, can I still use buildPhase without make somehow, or do I need to do e.g. preBuild, to workaround it, what is the idiomatic way?
<dmj`>
I'm currently installing nixos, have setup hard drive encryption with luks, when I attempt to mount the disk for installation mount /dev/disk/nixos /mnt I get: mount: /mnt: special device /dev/disk/nixos does not exist (a path prefix is not a directory)
<avn>
Just curious, if rewrite all small stuff like switch-to-conf, update-users-groups, etc to rust and/or haskell, just put all of them in to single repo?
<ninjin>
dmj`: Have you run `cryptsetup luksOpen`?
<avn>
(i feel, it be a good haskell practive for me)
<gchristensen>
avn: are you looking to have them replace the current ones, or purely for an experiment which would ot be adopted?
<gchristensen>
would not be adopted*
<avn>
gchristensen: I prefer to do something, that would be adopted, if it works ofc
<gchristensen>
avn: I would recommend sticking to C++ or Rust for that, then. and: yes, sticking it in a single repo would be fine
<ninjin>
dmj`: I installed with fulldisk encryption recently and simply followed the instructions under “zimbatm’s…” from here: https://nixos.wiki/wiki/Full_Disk_Encryption Note the mount-by-label part.
<avn>
I personally prefer to earn some more haskell skills, but meet with rust would be also interesting.
peacememories has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jpdoyle has joined #nixos
<gchristensen>
avn: yeah, I would suggest choosing Haskell would put it firmly in to a personal-only-experiment territory
<jpdoyle>
I have a slightly old nixos machine that I recently booted up
Tucky has quit [Quit: WeeChat 2.2]
<jpdoyle>
and its certificates have all expired, so I can't run nix-channel --update
<jpdoyle>
is there any standard way to fix that?
__Sander__ has quit [Quit: Konversation terminated!]
<ninjin>
dmj`: Sure, but according to your first message you are not mounting by label.
<gchristensen>
how old is slightly old, jpdoyle ?: )
<jpdoyle>
most recently updated with 17.10, lemme bring up more specific info
<avn>
gchristensen: I am ok with rust ;) Vendoring still be common practice to bring libraries in?
<jpdoyle>
17.09.2964.3e349a2b98b
<gchristensen>
avn: don't think so, just cargo
<dmj`>
ninjin: ah, so I did not call mkfs.ext4 -L nixos /dev/mapper/crypted
<dmj`>
ninjin: then I can call mount /dev/disk/by-label/nixos /mnt
<dmj`>
ninjin: mkdir /mnt/boot
<ninjin>
dmj`: Yep, `-L` controls the label as expected.
<avn>
gchristensen: then some tool like cargo2nix to lift on package level?
nschoe has quit [Ping timeout: 252 seconds]
<gchristensen>
carnix yeah
<avn>
gchristensen: any existing examples in nixpkgs?
<ninjin>
dmj`: The doc is a bit spotty here, but once I had wrapped my head around the rest of the installation procedure it was easy to lift in the full-disk encryption.
<ottidmes>
gchristensen: are you sure about Haskell vs Rust? Are there already standard tools written in Rust? I have a few Nix tools that are not official, in both Rust and Haskell, and I believe none of the official ones are Rust? So what makes Rust better in that regard?
<jpdoyle>
although I've had a decent experience rewriting some complicated shell scripting in Haskell using turtle
<gchristensen>
jpdoyle: it is down right miserable on 96 cores
<hodapp>
gchristensen: what sort of unique problems does it have with that many cores?
<dmj`>
ninjin: did you need to create a boot partition as well
<ottidmes>
dmj`: All my machines are either LUKS or sedutil, and for LUKS I always check out the Arch Linux wiki, has always worked for me :) (that bit is completely distribution independent anyway)
<gchristensen>
hodapp: afaik it performs worse with 96 than at say, 48
<jpdoyle>
@hodapp: The GC locks are all spinlocks with periodic `sched_yield()` calls, so you get a lot of negative effects there
<jpdoyle>
and it can look like you're getting "more performance" but you're actually just burning more cycles on a spinlock
<Mic92>
gchristensen: the aarch64 builder should also reduce its cores for builds like go.
<dmj`>
ninjin: on UEFI systems it seems I need to call "# mount /dev/disk/by-label/boot /mnt/boot"
<Mic92>
it is running into thread creation ulimits
<gchristensen>
Mic92: should we up the ulimit?
<dmj`>
ninjin: after I call, "mkfs.fat -F 32 -n boot /dev/sda3"
<dmj`>
ninjin: except I don't know what to name the boot partition
<Mic92>
gchristensen: that should also work, also I have to figure out what limits we would need.
<Mic92>
building something like kubernetes or docker should do it.
<ottidmes>
dmj`: lblk is a useful tool
<ottidmes>
dmj`: lsblk I mean
<hodapp>
gchristensen: interesting. looks like the exact thing that Erlang's GC was designed to not do
<gchristensen>
hodapp: oh?
<ninjin>
dmj`: These are my notes from my installation, I don’t think I encrypted boot: https://pastebin.com/kDZJHxXX
<jpdoyle>
@gchristensen on the topic of certificate problems, is there a reasonable way to either disable certificate checking for a single run of nixos-rebuild, or to publish all necessary packages as a cache from another nixos machine on the lan?
<ninjin>
dmj`: When installing on UEFI, those three commands and not formatting root were my only deviations from the standard instructions.
<dmj`>
ninjin: yea what do you do after that last command
<hodapp>
gchristensen: in the BEAM VM, IIRC, GC is never done system-wide but is done sort of at random on a per-green-thread basis so that instead of the entire system locking up to do GC of everything, there are tiny slowdowns distributed in an uncorrelated way throughout the system
<dmj`>
ninjin: since I'm on a UEFI system, it's saying I need a boot partition
<gchristensen>
hodapp: ah! cool! (I wasn't sure if you were saying erlang does handle this well, or does not handle this well :))
civodul has quit [Quit: ERC (IRC client for Emacs 26.1)]
<ninjin>
dmj`: I don’t think you generally encrypt `/boot` – how would you then have a kernel etc. to start decrypting? Someone, do correct me if I am wrong.
<gchristensen>
jpdoyle: sure, you can use nix-serve to create a local binary cache
<gchristensen>
jpdoyle: I'm quite tired and unable to type much more for the next hour or so, so I can't help further -- sorry
<ottidmes>
ninjin: It is possible to also encrypt boot I believe, but its quite involved, either way, it does not really win you much security wise, I believe, a USB stick can act as a custom /boot just the same
<{^_^}>
[nixpkgs] @coreyoconnor opened pull request #50747 → Add traverso: init at 0.49.5 → https://git.io/fpCQ5
<dmj`>
ninjin: yea I just don't know where to create boot
<ninjin>
ottidmes: Yeah, the USB hack makes sense there. It should give some added security, but once an adversary has physical access you are right that all bets are off.
kitlangton has joined #nixos
<dmj`>
ninjin: do I even need it to make a boot partition? I'm telling nixos which disk to boot into
<ottidmes>
ninjin: That, and if someone can write to your /boot, all bets are off as well
kitlangton has quit [Remote host closed the connection]
<ninjin>
Which you don’t need, unless you want to do full disk encryption.
vasarmilan has joined #nixos
<vasarmilan>
hi
<ottidmes>
dmj`: Depends on your disks, if you have just the one, partition it in a small (at least 1G but better to make it at least 2G for NixOS) boot partition and the rest for your normal disk (if you use swap, I normally have boot and LUKS (LVM (swap, nixos)))
* ninjin
wishes the installation instructions covered encrypted swap, “it is 2018 people!”
<exarkun22>
Haskell seems like a better choice than Rust to me because you don't really need the kind of low-level control Rust gives you for these things. On the contrary, I suspect there are zero valid reasons to spend one second thinking about memory management in any of these tiny Nix utilities - which you might have to do in Rust.
ng0 has joined #nixos
<exarkun22>
But an argument against Haskell will probably be the size of executables you get.
gspia has quit [Quit: Leaving]
<exarkun22>
It would be nice to have a language with some more of the runtime characteristics of Rust and the programmer-safety features of Haskell. I don't know of one though.
hlolli has joined #nixos
<ninjin>
dmj`: Looks like UEFI to me, but I can sadly not be much help for MBR since I have not installed Linux by manually partitioning and formatting on MBR since 2005.
<exarkun22>
Hmm. OCaml, maybe.
<sphalerite>
exarkun22: also aarch64 support in ghc is still rather iffy
<exarkun22>
sphalerite: True enough.
<ottidmes>
exarkun22: Nim maybe? Not sure how good its type system / safety is though
<gchristensen>
let's write it in assembly
<exarkun22>
gchristensen: Yea that will make cross-compiling a breeze. :)
<exarkun22>
ottidmes: I think it's safe but not very good beyond that.
Izorkin has joined #nixos
<exarkun22>
but never written anything with it
<{^_^}>
[nixpkgs] @Mic92 opened pull request #50752 → buildGoPackage: remove build-time dependency on parallel (and perl) → https://git.io/fpC5h
m0rphism has joined #nixos
Izorkin has quit [Client Quit]
<exarkun22>
sphalerite: Maybe ghc -> llvm -> aarch64 though
Izorkin has joined #nixos
<dmj`>
ninjin: if I didn't use LVM, would the boot partition get wiped assuming everything was on a single disk
<dmj`>
when using cryptsetup
<sphalerite>
exarkun22: working support for that seems like a bigger project than a rewrite of nixos-rebuild and friends
cyounkins has joined #nixos
<ottidmes>
dmj`: cryptsetup works per partition
<exarkun22>
sphalerite: there's already _some_ support for that. but maybe "working" is the key word. :) dunno. anyhow, I suspect Haskell is a non-starter for a number of other reasons.
<ottidmes>
dmj`: so you should cryptsetup only the partition you actually want to encrypt, and keep your boot partition as-is
<exarkun22>
I do think OCaml could be an interesting option though.
<v0|d>
exarkun22: does ocaml got a multi-thread gc?
chimay has quit [Ping timeout: 245 seconds]
<exarkun22>
though it looks like cross-compilation is troubling there too
<avn>
yup, ocaml can be also bytecompiled in case of cross compilations, or missed native compiler
<exarkun22>
v0|d: it has a synchronous gc
<exarkun22>
but it is overall a pretty modern and high-performance gc (which probably doesn't matter in any way to the tools nix needs; just turn off the gc entirely and let the os free memory on exit).
<ashkitten>
i was thinking more of like... having it clean up after itself?
<ashkitten>
i don't want that stuff *anywhere*
<v0|d>
ashkitten: nix-collect-gc?
<ashkitten>
doesn't help
<v0|d>
ashkitten: nix-collect-gc -d?
<ashkitten>
no
<gchristensen>
anyway, I'm quite sure that if a there were a high quality PR rewriting the nixos scripts from perl to Rust or C++, it would be accepted
<averell>
one PR for everything, or incremental with promises of more?
<ashkitten>
/run/user/1000 is still completely full of nix-shell-* directories
<gchristensen>
one at a time would be acceptable I'm sure
drakonis_ has joined #nixos
<avn>
exarkun22: I like ocaml. Year ago I found js_of_ocaml, and tried write simple game. And I remember almost everything about caml. So it very good language
<exarkun22>
yea I think it has a lot going for it.
<exarkun22>
"widespread acceptance" maybe not being one of those things.
<ottidmes>
exarkun22: yet I dont have any program that I know of written in it
gspia has joined #nixos
drakonis has quit [Ping timeout: 252 seconds]
Drakonis__ has joined #nixos
<exarkun22>
There's a pretty good backup/file sync tool, unison, written in it
kitlangton has joined #nixos
<exarkun22>
And there's a billion dollar blockchain written in it
drakonis_ has quit [Read error: Connection reset by peer]
<exarkun22>
and I think eDonkey was written in it?
<exarkun22>
(raise your hand if you remember eDonkey)
<v0|d>
so what does the number 501 in 10. rebuild-linux: 501+ means?
<v0|d>
like needs to rebuild 501+ packages?
<gchristensen>
yeah
<cyounkins>
Speaking of that backup/file sync tool... I'm trying to update the unison package and could use an assist. The build partially fails due to this build target: https://github.com/bcpierce00/unison/blob/master/src/Makefile#L333 (which: command not found) What's the best way to handle this?
<dmj`>
ottidmes: where on nvme0 is the boot partition created by parted?
<cyounkins>
I guess building the tags should be an option, but for now I think it's fine not building it. I'm not very familiar with make and can't figure out how to specify to not build it.
<avn>
exarkun22: mldonkey. Original edonkey was probably on c++ and win only
<exarkun22>
so if I do a native build of perl etc on armv7l ... how do I convince my x86_64 host to use those built packages instead of trying to do a cross compile?
<ottidmes>
dmj`: I told you not to encrypt your whole disk, then you also encrypt your boot
<dmj`>
ottidmes: yea, I did this before joining the channel
<ottidmes>
dmj`: Just follow that Arch Linux wiki page, it contains all you need if you want unencrypted boot + encrypted swap and nixos
<v0|d>
exarkun22: maybe you can put that in depsBuildBuild = []
<v0|d>
err or buildInputs
<hark>
hee, so is it possible to crosscompile nixos images to run on arm?
<v0|d>
hark: join the club, nixos cross compilation festival
<v0|d>
exarkun22: I might be wrong but if the derivation is same hash will be same
<v0|d>
exarkun22: so you can basically have the derivation and it will point to the same location.
<exarkun22>
v0|d: That seems like it should be true. Maybe I just don't understand what you're suggesting.
<exarkun22>
My x86_64 machine already wants to build this derivation because it's already a dependency of something higher up
<v0|d>
I mean you can build a drv somewhere else copy it to your store, when you instantiate that derivation it will automatically use that.
<exarkun22>
How do I convince nix-build that it's already built? It sounds like the answer following from your point immediately about would be to copy stuff out of the armv7l's /nix/store onto the x86_64's /nix/store
<exarkun22>
Okay, gotcha
<exarkun22>
is this what nix-copy-closure is for? or is this just a job for scp?
<ottidmes>
dmj`: that is basically the same as the Arch Linux wiki I pointed to, except for the NixOS config bit of course, so it seems OK by me, I did something similar
<v0|d>
gchristensen: nix-* stuff is replcd by nix * right
<{^_^}>
[nixpkgs] @7c6f434c pushed 2 commits to release-18.09: https://git.io/fpCAJ
<v0|d>
had no problems yet.
sanscoeur has joined #nixos
<gchristensen>
good :) its interface may change
<v0|d>
kudos to eelco
fendor has joined #nixos
samrose has joined #nixos
<v0|d>
gchristensen: how does staging merge into master?
<v0|d>
is it by borg or manual?
<exarkun22>
What about the fact that on my armv7l, store filenames don't reflect the arch and on my x86_64, store filenames for things cross-compiled for armv7l do? eg ...-perl5.28.0-XML-Twig-3.52-armv7l-unknown-linux-gnueabihf.drv vs ...-perl5.28.0-XML-Twig-3.52.drv
<exarkun22>
is that going to confuse things?
<gchristensen>
v0|d: manual
<v0|d>
exarkun22: :(
<gchristensen>
exarkun22: they won't be confused, but also if you compile the package "foobar" natively on ARM and then try to use "foobar" when cross-compiling , it won't use the natively compiled one
cyounkins has quit [Remote host closed the connection]
<exarkun22>
darn, coz that's just what I wanted it to do.
<gchristensen>
right. Nix doesn't know that a cross-compiled thing and a normally-compiled thing are interchangable -- to Nix, it is different just like the linux kernel is different from the `hello` package
<v0|d>
cos there will be no suffix of cross-compilation
<gchristensen>
Nix will not be confused, no
<{^_^}>
[nixpkgs] @Assassinkin opened pull request #50763 → amazon-image: amazon-init script checks for nix expressions in userdata correctly → https://git.io/fpCAX
<v0|d>
sure? if thats the case we should be able to do the above now
<exarkun22>
v0|d: It sounds like Nix will just ignore the packages you copied in because they aren't the packages it cares about
<gchristensen>
but if you try to subsequently install new packages, it will need to be able to fetch or build all the dependencies for the packages, even though it may already have local builds which would have worked if they hadn't been cross compiled
<exarkun22>
They're just some extra packages you added that don't appear to relate to anything
<v0|d>
wow, thats pretty bad.
<gchristensen>
is it? not sure
Ariakenom_ has quit [Ping timeout: 240 seconds]
<v0|d>
gchristensen: I rlly dont want to build anything on a pi.
<gchristensen>
inconvenient, for sure, but not sure it is bad. it would be bad if Nix actually got confused
<exarkun22>
it would certainly be more convenient if nix could recognize the cross-compiled packages as being the "same" as the native compiled versions
equalunique has quit [Ping timeout: 268 seconds]
<gchristensen>
it would be more convenient, but it would also break an invariant of the nix store
<v0|d>
I think what we need is a rewriter.
<exarkun22>
or if there were a way to say "I depend on any kind of build of X you can find" in the packages that depend on those, instead of saying "I depend on exactly a native build of X" or "I depend exactly on a cross compiled build of X"
<v0|d>
there are two nix stores so no it wont break.
<gchristensen>
that would be interesting too
<gchristensen>
huh?
equalunique has joined #nixos
<v0|d>
gchristensen: you can have suffixes on the build system, all we need is to map those derivations to a new nix store on the rootfs
<v0|d>
w/o the suffixs
<v0|d>
so that it wont break
boogiewoogie has quit [Quit: Leaving]
<v0|d>
not sure if the above makes sense:p
<exarkun22>
Why does the native package look different from the cross package to Nix? Because they use different nixpkgs (because `crossSystem` is an input to the function that returns nixpkgs for you)?
<samueldr>
the suffixes aren't really an issue, the dependencies don't match, so the hashes won't match
<gchristensen>
exarkun22: because the build instructions are differenst
reardencode has joined #nixos
johnw_ is now known as johnw
<exarkun22>
Was I at least close? Are the build instructions different because the nixpkgs were different in a way which produced different build instructions (because that's what the `crossSystem` argument is for)? Or am I way off base
<v0|d>
yet we still have that information, I mean the map btw them.
<gchristensen>
exarkun22: yeah, quite similar
<exarkun22>
okay, I guess I can sort of understand that
<gchristensen>
exarkun22: it is saying use <this> gcc instead of <that> gcc, and use <this> linker flag instead of <that> linker flag
<v0|d>
this will obviously make `nix` to include stuff from the cross building mechanism, I mean the knowledge of cross compiling in nixpkgs.
<exarkun22>
All of the elegant high-level logic of a cross-compile has been smashed into a disgusting shell pancake by the time you get to a derivation
<dmj`>
ottidmes: oh that's the boot partition, unencrypted
<{^_^}>
[nixpkgs] @robinp opened pull request #50765 → Add awk as a default tool for Bazel shell commands. → https://git.io/fpCps
<v0|d>
exarkun22: pancake+ package = pankage?
<v0|d>
:p
* exarkun22
smirks
<v0|d>
so OK, how does any cross compiled stuff is usable anyways?
<gchristensen>
lots of cross users use it to produce artifacts which are not mutable systems
<exarkun22>
that's pretty much what I want to do
<exarkun22>
maybe I should be looking at ways to get the rest of the non-cross-compilable stuff out of the system instead of trying to fix cross compile for it
<dmj`>
ottidmes: I think its the uuid of the whole disk...
<gchristensen>
exarkun22: or pre-populate the environment with what you need possibly5
<exarkun22>
do people put together nix-based systems w/o e.g. switch-to-configuration and update-users-groups?
<exarkun22>
those seemed like pretty basic parts of the system that would be hard to remove, but idk
<exarkun22>
oh, well. I guess it also depends on exactly what "not mutable systems" means.
<{^_^}>
#48378 (by bgamari, 5 weeks ago, closed): [WIP] Port switch-to-configuration script to Python
<exarkun22>
I kinda meant "I will only manage it with nixops" but maybe you meant something more like "burn a master image to media and then insert media into device"
<exarkun22>
Mic92: yep. looks dead-ish, right? we had a long discussion earlier about what language _would_ be acceptable for rewriting that stuff. shockingly, did not produce any usable software by the end. ;)
<Mic92>
exarkun22: yep.
<Mic92>
perfect is the evil of good
<Mic92>
a long night + rust + nix crate could solve this
<gchristensen>
assuming Rust cross-compiles -- do you know if it does?
<gchristensen>
I'm trying, but first I have to bootstrap the world :P
<Mic92>
gchristensen: rust can, but I doubt our rust infrastructure does.
<{^_^}>
rust-lang/rust#36963 (by brson, 2 years ago, closed): Switch the default global allocator to System, remove alloc_jemalloc, use jemallocator in rustc
<Yaniel>
v0|d: I mean are you interested in the absolute minimum binary or more in a general *useful* one
<Yaniel>
and how much are you ready to go out of your way to get it
<v0|d>
Yaniel: barlow already did it with monit as systemd etc.
<Mic92>
Yaniel: the rust 2018 edition will have it.
<v0|d>
Im just lookin ways to preserve his doings.
<Mic92>
Should be released in the next month or so
cyounkins has joined #nixos
<Mic92>
I get with system malloc the following hello-world binary: 261K target/release/foo
<v0|d>
Mic92: boehm?
<Mic92>
420408 bytes
<Mic92>
v0|d: no this is a garbage collection
<Mic92>
I mean malloc() from glibc
drakonis has joined #nixos
cyounkin_ has joined #nixos
<Yaniel>
Mic92: that is still with stdlib and string formatting I assume
<v0|d>
Yaniel: wrts have 4mb+ spis.
<Mic92>
v0|d: are you targeting linux or bare metal?
<Mic92>
and what architecture
<v0|d>
Mic92: mips (bigel)
<exarkun22>
gchristensen: so ... aarch64-build-box ... how does it build armv7l? Just put that in for `system` instead of aarch64?
<sphalerite>
unimplemented instruction failures tend to happen at the end of the build of libraries which use specialised instructions, during the check phase
<exarkun22>
neato.
<exarkun22>
well probably doesn't hurt anything to start it up again.
<sphalerite>
unless it fails and destroys all your happiness.
<gchristensen>
sphalerite: <3
<djahandarie>
Is there a "standard solution" or other example of doing multiple processes with systemd and NixOS?
<exarkun22>
what happiness
<djahandarie>
I imagine you could create multiple systemd units with nix expressions, or you could try to use instantiated services in systemd or something
c0bw3b_ has joined #nixos
<sphalerite>
djahandarie: other solution — phpfpm iirc
<djahandarie>
Ooh, indeed, this looks very relevant, thanks.
<sphalerite>
djahandarie: note however that there's already networking.supplicant for multiple wpa_supplicant instances
<djahandarie>
lol, well then
<hlolli>
Has someone installed nixos on armv7, I'm 20 hours in, I guess it's installing the kernel and gcc from sources. Looks fine, but time, wow.
<exarkun22>
hlolli: Heh heh. Heh.
<hlolli>
(I did add that finnish cache)
<exarkun22>
hlolli: I started on Wednesday.
equalunique has quit [Read error: Connection reset by peer]
<exarkun22>
hlolli: How are you installing?
equalunique has joined #nixos
<hlolli>
ha?!! exarkun22, you started 5 days ago??
<exarkun22>
First thing I did was download the armv7l image to a flash drive and boot with that. That produces something relatively quickly.
<v0|d>
5days to flash an SD?
<hlolli>
true I did that too, changed the config, removed the import image thingy, typed the config according to the manual
<exarkun22>
hlolli: Okay. Are you on a rpi?
<hlolli>
rpi3+
<exarkun22>
v0|d: no, that part was 20 minutes
<exarkun22>
v0|d: going from "the install-oriented setup" to "something useful" is the other 4 days 23 hours 40 minutes
<hlolli>
I'm planing to use it for public performance on Friday, if this takes so many days, I will set some other distro on differnet SD card and do this later
<exarkun22>
hlolli: okay. yea. that's probably days of building on the pi itself.
<v0|d>
exarkun22: I enjoyed it mate, take care.
<gchristensen>
hlolli: join #nixos-aarch64 and ask dezgeg what version they've most recently built and published
<Mic92>
rpi3+, well if you have an rpi3+ you can also use aarch64
<exarkun22>
v0|d: hah. you too. :p
<exarkun22>
hlolli: it's definitely >1 day building on qemu-arm on 4 core i7-6600U
<exarkun22>
hlolli: what features do you need from the pi?
freeman42x]NixOS has joined #nixos
<hlolli>
I need it to play some shaders or play video, most importantly I need it to be my wireless ssh access point to multiplex my tmux session
<exarkun22>
wifi works fine on aarch64
<exarkun22>
so does hdmi output
<hlolli>
hmm there must be some tradeoff right?
<exarkun22>
gpio doesn't work and probably neither does hardware accelerated mpeg-2 decoding
kyren has quit [Ping timeout: 268 seconds]
<hlolli>
what device are you using exarkun22 ?
srl295 has joined #nixos
<exarkun22>
3b+
<hlolli>
I also have rasperry 1, well, I'll digest it. Feel so bad turning it off now at this stage, 1 day, is 1 day less of total 5 days :D
<exarkun22>
I had a working aarch64 system in less than a day for sure
<hlolli>
ok!
<exarkun22>
just not working well enough since gpio was the point :p
<hlolli>
I see
<nschoe>
Hey all, I have a CMakeLists.txt file that has `find_package(Qt5Widgets REQUIRED)`, I'm in an nix-shell env with `qt5.full` as buildInputs and when running `catkin_make` it fails with "The imported target "Qt5::Gui" references the file
<hlolli>
can't we contribute to the cache somehow after we install this?
<nschoe>
I think there's smth special with Qt and nixOS, but this exact same shell.nix file has been working for months. today I ran some `nix-collect-garbage` though, and wonder if this was all working thanks to some miracle.
<exarkun22>
hlolli: seems like that might be nice but I dunno. would you accept binary packages from someone you don't know to host in a cache you run for other people?
<c0bw3b_>
Is the "doc" output installed by default now? I seem to remember a change about that but not sure..
<nschoe>
infinisil, the shell.nix file? Or the full output error?
<hlolli>
no not sure, I'm a newb when it comes to build caches, but I did add nixos-arm.dezgeg.me with the public key, but I guess there's not much there for what it's building (currently at glibc)
<gchristensen>
hlolli: the cache contains a loto f stuff, but at a different version of nixpkgs than you're (evidently) at
<nschoe>
infinisil, note that this error rings a bell, I had opened a Discourse post on this (no answer:/). At the time I had messed around a lot with qt5.full, qt5Full, qt5.foo/bar etc until one day it miraculously worked.
<exarkun22>
the armv7l image self-reports `19.03.git.ca2ba44cab4` but when I switched to nixpkgs@ca2ba44cab4 I don't think I saw any better cache usage
<nschoe>
And I've looked: inside `/nix/store/c4d9qgyyx6p2gydbbh5wpp4mxvwgc64n-qtbase-5.11.1-bin/lib/qt-5.11/plugins/imageformats/` there's only "libqgif.so* libqico.so* libqjpeg.so*", no "libqicns.so" (which is why it fails)
<infinisil>
nschoe: Did you update that nixpkgs fork since it worked?
<infinisil>
Because that's the only thing that could have changed
<{^_^}>
[nixpkgs] @timor closed pull request #29128 → perlPackages: undefine LD per default in builder → https://git.io/v5KaS
<sphalerite>
Dezgeg: is the NFS bork maybe happening again? Your cache doesn't seem to have been updated in over a month
<sphalerite>
hlolli: there are sometimes problems with the infra that hosts Dezgeg's cache, which might be leading to your issues ^
<jackjennings>
Not sure if this is a known issue — it seems as though all of my node packages installed with node2nix are removed after collecting garbage…? Not sure where to start, but it seems unintended to me
<dmj`>
ottidmes: the monitor literally shuts off with "no signal"
<dmj`>
ottidmes: still black
<ottidmes>
dmj`: did you already have NixOS installed once before on the same hardware without encryption?
<ottidmes>
dmj`: I doubt it has to do with encryption, it shouldnt at least
<ottidmes>
dmj`: probably related to your video driver / kernel version
<dmj`>
ottidmes: brand new machine
<dmj`>
ottidmes: is there a way I can edit configuration.nix w/o specifying the password...
<dmj`>
ottidmes: probably not right
<dmj`>
ottidmes: yea, probably video drivers
<ottidmes>
dmj`: you obviously cannot access your configuration.nix without decrypting your drive, but you can always boot into the install ISO again, and manually mount everything to /mnt again, and then edit it and rebuilding it
<ottidmes>
dmj`: what hardware do you have? is it a laptop? if its a desktop, can you specify the processor and graphics card?
<ottidmes>
dmj`: what will? using the latest kernel?
fendor has joined #nixos
<dmj`>
ottidmes: yea
<ottidmes>
dmj`: Maybe at first, you could try the latest kernel with the config I just showed, and use the fallback video driver that is sure to work: boot.kernelPackages = mkForce pkgs.linuxPackages_latest;
<jackjennings>
For some reason today nixops has decided to recompile libxml2 (libxml2-2.9.8-dev), which hangs indefinitely (or takes longer than I have patience for; killed at ~1hr). Can anyone shed light on what might have happened that would have caused this to happen in the first place, or how I can figure out what is depending on this? No idea how to debug this and about ready to toss my computer out the window.
<ottidmes>
jackjennings: maybe something with your connection?
ninjin has quit [Quit: WeeChat 2.2]
<Neo-->
anyone here using dunst for their notification manager? For some reason I can't get it to read .config/dunst/dunstrc and I get a "org.freedesktop.Notifications: no dunstrc found -> skipping message" - anyone had similar issues?
drakonis_ has quit [Ping timeout: 252 seconds]
<jackjennings>
ottidmes: nixops is running on a server — I can see that it's doing something… just no output other than the gcc command it's running…
<{^_^}>
[nixpkgs] @matthewbauer opened pull request #50776 → Remove lib functions from all-packages.nix attrs → https://git.io/fpWLD
<slabity>
Neo--: I use dunst. How are you calling it?
<Neo-->
I don't - it gets started automatically if I send notify-send
<slabity>
Also, `home-manager` has a dunst service wrapped in a service to integrate into nix
<ottidmes>
Hmm, the patch generated by Meld (a diff tool), fails when I apply it to the original file, and when I try to make the patch with `diff`, I get error code 1
cyounkins has quit [Remote host closed the connection]
cyounkins has joined #nixos
<dmj`>
ottidmes: It works, but now I can't login :) did useradd, and set the password, but not applying
<dmj`>
ottidmes: how can I get a root shell from gdm
<ottidmes>
dmj`: you should do user management through the configuration.nix (not per se, but its what most commonly is done)
<ottidmes>
Since the patch is almost as big as the end result, for now I just copy over the new file as is, but I would really like to know why it fails
<MasseR>
Can I add some extra files to a haskell derivation? We have subprojects with hpack files (yaml) which include common hpack configuration options from the root directory. These files from root aren't copied to the nix build because they aren't inside the referenced build directory
<ottidmes>
dmj`: no problem, glad it all works now!
<ottidmes>
dmj`: and declarative config of your system :) Thinking about e.g. the trouble I went through to setup my perfect mail server on Arch Linux, only to lose it, that is much less of an issue with NixOS
<{^_^}>
[nixpkgs] @c0bw3b pushed commit from @r-ryantm to master « jdupes: 1.11 -> 1.11.1 »: https://git.io/fpWOX
<ottidmes>
infinisil: cool, thanks for the tip! I see a lot of things I remember setting up, have to check some old notes to see if anything is missing, but it should be great start
<ottidmes>
infinisil: on NixOS I have only used networking.defaultMailServer to mail with a Gmail account
<hyper_ch>
infinisil: just pushed a little update to my easysnap tool
<infinisil>
ottidmes: I see. I actually still haven't set up mail properly on my computers, still just using my phone to check them haha (I don't write a lot of mails anyways)
<infinisil>
hyper_ch: Cool, but I don't use it :P
Peaker has joined #nixos
<hyper_ch>
cron didn't like "head -1" while bash shell had no issue with it... needed to fix it to "head -n 1"
<ottidmes>
infinisil: at first I made my scripts somewhat general for zsh/bash and the like, but now I just gave up, and just explicitly use bash for all my scripts
sanscoeu_ has joined #nixos
<infinisil>
ottidmes: I'm trying to give up on bash and use haskell for whatever i can :)
nDuff has joined #nixos
<ottidmes>
infinisil: I like Haskell, but that sounds painful
<exarkun22>
all great art requires suffering
<infinisil>
ottidmes: Once your script would grow over 100 lines, you'd be grateful for not having used bash
<infinisil>
Probably :P
Neo-- has quit [Ping timeout: 252 seconds]
<ottidmes>
infinisil: depends on the script, but sure
<infinisil>
(there are a lot of scripts that would never get to that size though, so it's a bit of a guessing game)
<Peaker>
exarkun22, hey, are you exarkun from #twisted years ago?
<infinisil>
It developed into an actually usable thing
<exarkun22>
Peaker: It so happens. Hello. I take it you are Peaker from #twisted years ago. ;)
<Peaker>
exarkun22, Hi! :-)
<ottidmes>
infinisil: but Haskell is not really a good "scripting language", is it really what you use when you need a proper language for a really small thing? I mean I dislike python, but I still use it for those things if I really have to
<exarkun22>
Peaker: Small world, huh.
<Peaker>
exarkun22, indeed :)
<infinisil>
ottidmes: You have a point yeah, I still use bash a lot for simple stuff. Only if I have a feeling "oh boy, I'll regret it if I continue trying to use bash for this later", I'll give haskell a go
<exarkun22>
ottidmes: I am pretty much trying the same thing as infinisil. To me, it's not obviously a win in all cases, but I am counting on it being a win in _enough_ cases to make it worthwhile overall. Also, it's good Haskell practice.
<infinisil>
ottidmes: Also, ghci is really convenient for processing stuff
<infinisil>
(I guess this discussion should be in #nixos-chat though)
<nDuff>
Howdy -- I've had a PR sitting in limbo for a few months now. Since it's adding a new package, there's no preexisting maintainer to ping; other than rebasing/retesting/making sure it's still merge-eligible, is there anything I can do to get it reviewed for merge?
<nDuff>
Heh. The PR in question is https://github.com/NixOS/nixpkgs/pull/48423 (that said, my IRC client is acting up, so I'm currently reading responses only via online web-based logs; back shortly).
sanscoeur has quit [Remote host closed the connection]
ninjin has joined #nixos
goibhniu has joined #nixos
<infinisil>
worldofpeace: Yeah, any new push to it is a trigger
random_yanek has quit [Ping timeout: 268 seconds]
<nDuff>
...okay, got it building again (conflict between a btrfs header and libstdc++, fixed upstream in 0.6.1); going to want to deploy that to my local systems and make sure everything works in practice.
<ninjin>
Has anyone had any luck running Singularity? I can build things correctly, but once I try to instantiate a shell I get `ERROR : Could not create /dev/loop8: Permission denied`.
romanofskiWork has joined #nixos
acarrico has joined #nixos
<infinisil>
nDuff: I left some review on your PR :2
<ottidmes>
ninjin: shouldnt you just run it as root then?
<nDuff>
Thanks; I'll try to address those items as well.
<{^_^}>
[nixpkgs] @jtojnar pushed 159 commits to gnome-3.30: https://git.io/fpWZa
<ninjin>
ottidmes: Fair point, that does work. But what dark magic has the university sysop pulled off to allow me to run it as user once I am on their cluster?
<{^_^}>
[nixpkgs] @c0bw3b pushed commit from @colemickens to master « fmtlib: add pkgconfig »: https://git.io/fpWc8
rihardsk has joined #nixos
<{^_^}>
[nixpkgs] @matthewbauer pushed to staging-next « bc: flex is also a runtime dep »: https://git.io/fpWcb
goibhniu has joined #nixos
<jackjennings>
Can someone PLEASE help me figure out how to debug my failing nixops deployment? Everything gets stuck on this python package, that seems to be compiling forever. I know that this is not nixos' fault but I don't know where to start digging to find the solution. Here's the output for this package: https://gist.github.com/jackjennings/c838f13038ad157f88c21f4cacd2012a
peacememories has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jackjennings>
Nothing ever happens after this point… this wasn't a problem before today and I don't understand what could have introduced this issue. The deployment runs on its own server, running nixos
<Peaker>
when is /nix used vs $HOME/nix.store? the instructions I read assumed the latter, but it seems nix now uses the former?
jasongrossman has quit [Ping timeout: 264 seconds]
<gchristensen>
I've never heard of $HOME/nix.store
<tilpner>
What instructions did you read, Peaker?
<Peaker>
oh, it seems they use "nix copy" to generate $HOME/nix.store, and add substituters for https://cache.nixos.org/ and $HOME/nix.store to /etc/nix/nix.conf -- yet that all seems to fail to preserve caching. I wonder if just telling travis to cache /nix will work
<tilpner>
How do I allowUnsupportedSystem for just one package?
<tilpner>
.overrideAttrs to add the current system to meta.platforms didn't work
WilliamHamilton[ has quit [Ping timeout: 264 seconds]
<ottidmes>
What is generally better, if you have a symlink to some .so file, to use just the name in the symlink (i.e. relative), or to use the absolute path? The package I am fixing uses both styles. I guess I will change them all to be absolute, any reason not to?
<{^_^}>
[nixpkgs] @eburimu opened pull request #50804 → fix: use buildPackages.xsltProc in case of cross compilation → https://git.io/fpWBK
random_yanek has quit [Ping timeout: 245 seconds]
erictapen has joined #nixos
<jackdk>
I would imagine if you're writing nix expressions for it you'd want absolute store paths?
<ottidmes>
jackdk: its for aliases in the same $out/lib folder, but there should be no harm from absolute paths, I guess (except metadata space requirements, but that should be neglitable)
Rusty1 has quit [Quit: Konversation terminated!]
MinceR has quit [Ping timeout: 244 seconds]
<exarkun22>
man, btrfs-progs? fuse? libXt? libXmu? I have some feelings about this. :p;
MinceR has joined #nixos
sanscoeur has quit [Remote host closed the connection]