sphalerite changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 19.03 released! https://discourse.nixos.org/t/nixos-19-03-release/2652 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html https://r13y.com | 19.03 RMs: samueldr,sphalerite | https://logs.nix.samueldr.com/nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]
drakonis1 has joined #nixos-dev
aminechikhaoui has quit [Quit: The Lounge - https://thelounge.github.io]
aminechikhaoui has joined #nixos-dev
orivej has quit [Ping timeout: 246 seconds]
drakonis1 has quit [Quit: WeeChat 2.4]
drakonis_ has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
drakonis1 has joined #nixos-dev
drakonis1 has quit [Quit: WeeChat 2.4]
drakonis has quit [Ping timeout: 258 seconds]
drakonis has joined #nixos-dev
Synthetica has joined #nixos-dev
init_6 has joined #nixos-dev
init_6 has quit [Ping timeout: 246 seconds]
init_6 has joined #nixos-dev
justanotheruser has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 245 seconds]
<manveru> i really wish errors in nix-shell shebangs would actually tell me something useful :P
<manveru> atm it's `error: syntax error, unexpected $undefined, at (string):1:94`, no matter what i write
<manveru> the line doesn't even have 94 characters...
<clever> manveru: toss in some -vvvvv ?
<manveru> that doesn't help much unfortunately
<manveru> only output from the -vvvvv is `evaluating file '/nix/store/vi1ial7iswah07whvl9hkbsq26pqg8a2-nix-2.2.2/share/nix/corepkgs/derivation.nix'`
<manveru> character 94 of that file is a normal space (32)
<manveru> wait
<manveru> since when is /**/ valid for nix comments?
<infinisil> Has been for a while!
<manveru> TIL :)
<infinisil> But I actually wondered exactly the same at some point
<manveru> then i just don't know what's going on :|
<manveru> oh!
<manveru> you have to use `-p "..."` instead of `-p '...'`
<manveru> goddamnit
<dtz> LOL omg wow
<dtz> :/
<dtz> .... well, I'm glad you found the problem ._.
<manveru> i think that might be a bug?
<manveru> actually figured it out by stracing and triggering this bug: https://github.com/NixOS/nix/commit/7c6391ddc730519a632cc0ee526c94a04812d871
<manveru> there's a bug open for it since last year: https://github.com/NixOS/nix/issues/2356
<{^_^}> nix#2356 (by cumber, 38 weeks ago, open): nix-shell in second #! line only accepts double quotes for package expressions
<qyliss^work> gets me every time
init_6 has quit []
dhess has joined #nixos-dev
<dhess> I have some questinos about how NixOS EC2 images are created, is this the place to ask? Or should I ask this in #nixos?
<gchristensen> this is fine
<dhess> hi gchristensen :)
orivej has joined #nixos-dev
<gchristensen> hey :)
<dhess> ok so I'm trying to build my own AMIs. I basically just cribbed the config.system.build.amazonImage bit from nixos/maintainers/scripts/ec2/amazon-image.nix
<dhess> and I can produce a .vhd file
<dhess> just minor changes from the NixOS image at this point, mostly just a user for me with my ssh key and a password
<dhess> couple of config defaults.
<dhess> anyway I tried to use packer to upload the vhd to EC2, since that looks like it'll handle all the various phases
<dhess> I basically skip the packer build phase so it just makes a copy of the vhd, doesn't modify it in any way
<dhess> and then use the post-processors phase to upload the vhd
<dhess> it gets to S3 just fine. When the vmimport phase starts, it fails with this status message: "StatusMessage": "ClientError: Unable to find an etc directory with fstab.",
<dhess> now I thought the vhd file was a working NixOS image so it should have /etc/fstab etc. No?
<gchristensen> I would think so
<dhess> the NixOS create-amis.sh script uses the old ec2-* AWS SDK, or rather it looks like it uses a mix of aws-cli and ec2-*
<dhess> any idea why?
<gchristensen> hmm I wonder if those commansd did something magic
<dhess> I've used a hacked-up version of that script before but I'm trying to make something that's a bit more automatable
<dhess> gchristensen: yeah it appears there are some subtle differences in how EC2's official VM import process works and the way that ec2-* SDK works
<dhess> I used to have some notes on this back when I uploaded my own AMI last summer, but I can't find them now
<gchristensen> I lost some hours to madness trying to "clean up" that script
<dhess> yeah no doubt
<dhess> iohk has a simplified version of it, but it's not clear to me that it works anymore. They appear to have removed support for building AMIs from their iohk-ops tool
<gchristensen> hmm
<dhess> so as far as I can tell, nothing in their iohk-ops tree actually uses it anymore.
<gchristensen> (relatedly, I used to want to teach nixops how to make AMIs)
<dhess> do they have an irc channel somewhere?
<dhess> oh please do
<dhess> oh "used to"
<dhess> yeah hehehe
<gchristensen> dhess: (I mean, I Still do, but I no longer have delusions of it being on my to-do list :))
<dhess> hehe
<gchristensen> tbh let's ping clever and he can probabl yhelp
<dhess> huh weird. I finally got guestmount to work and it says there's no OS on the vhd image
<gchristensen> O.o
<dhess> well it's wrong. that was the inspector saying that
<dhess> I just mounted it
<dhess> ok so /etc/fstab is a symlink to /etc/static/fstab which is a symlink to /nix/store/....fstab
<dhess> so there is an fstab, but it's a series of symlinks. I guess that's confusing EC2's vmimport?
<gchristensen> :/
<dhess> I wonder if maybe the old ec2-* SDK doesn't use vmimport and it doesn't have this problem
<gchristensen> I suspect that might be true
<dhess> sigh
<dhess> This is why we don't use proprietary tools, isn't it? :)
<gchristensen> I was just thinking how close minded are they thinking you need an fstab at all :)
<dhess> hehehe
<dhess> I wonder if there's a way to tell vmimport just to skip all the checks and just assume that the image works
<gchristensen> doens't the old stuff just directly make a ebs vol?
<dhess> yes it does!
<dhess> ok so I created the stock NixOS EC2 image. Its fstab has the exact same store hash as my image's.
<dhess> so there doesn't appear to be any issue with the way I'm creating the image
<dhess> this just looks like something that's not compatible with vmimport
<gchristensen> nice
<gchristensen> do you mind doing osme research?
<dhess> I'll try to use packer to import the stock image just to be sure. But I expect it to fail the same way.
<gchristensen> for example, trying it where /etc/fstab is a one-hop symlin?
<dhess> I don't mind at all, I would love to make this work
<gchristensen> one of NixOS's users pays AWS a lot of money, we might be able to have them run it up the chain
<dhess> even better could we just copy /nix/store/...fstab to /etc/fstab?
<gchristensen> that would be a good test
<dhess> it's only temporary until the next rebuild after all
<gchristensen> :P
<dhess> so is there any easy way to do that when the image is created?
<gchristensen> ehhh not sure
<dhess> or I guess I could just make a copy of the image and modify it using guestfs
<dhess> right?
<gchristensen> for this type of experimenting, personally, I would just hand-jam it
<dhess> "hand-jam" that's a new one to me :)
<dhess> ok let me see
<gchristensen> ah hehe I picked that up at Tumblr I guess
pie_ has quit [Remote host closed the connection]
<Shados> finagle it :)
<gchristensen> ok, back in about 15min
pie_ has joined #nixos-dev
<dhess> ok I hacked /etc/fstab in the vhd image so that it's a real file now
<dhess> I'll try uploading this again
<dhess> oh my, I *think* it made it past the point where it broke last time
<gchristensen> nice
<dhess> the snapshot status is "complete" and now it's "updating"
<gchristensen> what change did you make?
orivej has quit [Ping timeout: 245 seconds]
<dhess> only to make /etc/fstab a real file
<dhess> soooooo sloooooooowwwwwwww
<dhess> it seems stuck at 41% "progress" but it hasn't died yet :)
<dhess> ugh, still stuck at 41%. Can't help thinking something is broken.
drakonis1 has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 248 seconds]
kgz has quit [Quit: WeeChat 2.3]
kragniz has joined #nixos-dev
kragniz is now known as kgz
<dhess> clever: around?
orivej has joined #nixos-dev
drakonis1 has quit [Quit: WeeChat 2.4]
JosW has joined #nixos-dev
JosW has quit [Client Quit]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 246 seconds]
drakonis_ has quit [Ping timeout: 252 seconds]
<dhess> ugh, do the ec2-* utilities not work with IAM roles?
<dhess> oh looks like you need to specify the STS token explicitly in that case
<dhess> so that Packer image import is still stuck on 41% and has been for about 4 hours. Looks like that's a dead end for now.
MichaelRaskin has joined #nixos-dev
<MichaelRaskin> Another week, another iteration of marking package-specific user notes in Nixpkgs as a separate thing from package development notes
drakonis has joined #nixos-dev
<gchristensen> MichaelRaskin: say more?
<MichaelRaskin> #60682
<{^_^}> https://github.com/NixOS/nixpkgs/pull/60682 (by 7c6f434c, 1 week ago, open): [RFC] manual: rename to users and contributors manual, add some user notes …
<Synthetica> grahamc: Would it possible to add a crosscompile job in ofborg/hydra? In my brief time using cross-compiled software, there seem to be a lot of broken packages that fly under the radar because they aren't systematically checked (or should I open an issue about that?)
<gchristensen> Synthetica: in what direction would cross compilation be wanted?
<gchristensen> like, what target system?
<Synthetica> gchristensen: in my case, pkgsCross.raspberryPi, but I think if one crosscompile "leg" works, you can at least be fairly certain the rest would also be okay
<gchristensen> interesting
<gchristensen> how does it typically fail? at build time, or at evaluation time?
<Synthetica> Mostly at build time, for example when things that should be in `nativeBuildInputs` are in `buildInputs`
<samueldr> aarch64 to x86_64, for sanity checks might uncover a bunch of issues too I suppose
<Synthetica> gchristensen: For example: #61245
<{^_^}> https://github.com/NixOS/nixpkgs/pull/61245 (by Synthetica9, 46 minutes ago, open): openexr: fix cross-compilation
<gchristensen> I've heard hydra is building some cross stuff. anyone know what exactly?
<MichaelRaskin> release-cross.nix I would assume
<dhess> Synthetica: are you building OpenEXR for rpi?
<Synthetica> Yes, it was a dependency for opencv
<dhess> oh I see
<dhess> (I created the OpenEXR open source project)
<dhess> just wondered if you were doing something really funky with it on the rpi
<gchristensen> I guess my question is what does hydra build, because we need it to have built most of the stuff for ofborg to reasonably build much
<samueldr> looks like "not much", but what's needed to get started? https://hydra.nixos.org/jobset/nixpkgs/cross-trunk/jobs-tab?filter=%
<gchristensen> not sure exactly :)
* gchristensen wishes he could take a month off and work on secret projects
<Synthetica> gchristensen: Don't we all
<samueldr> though, other than added load, adding a more encompassing jobset to hydra might be a good first step; no CI on ofborg builds, but at least failures could be identified I guess?
<samueldr> (thinking out loud mainly)
<gchristensen> yeah, I think a strategic decision on _what_ we build is in order
<gchristensen> what is the highest value host/target platform to pick
<MichaelRaskin> Hm, maybe this deserves an RFC. Or an edit suggestion to an RFC currently under discussion…
<gchristensen> I think yes
<gchristensen> it is extremely related to the supported platform RFC
* Synthetica looks up that RFC
<samueldr> egoistically speaking, there is always a background noise with armv6 and armv7 going on due to them being relatively popular cheap platforms; it would help with regards to bootstrapping them
<samueldr> I'm willing to bet a good chunk of builds not targetting the same CPU families are for arm 32 bit
<samueldr> (though I'm sure alternative libc and other compilers are big targets too)
<MichaelRaskin> Other compilers maybe not
<samueldr> well, I meant "what's popular to use in the cross-compiler infra"
<gchristensen> for the record though I'm too tired from waking up very early, and meeting whiplash to make decisions today
<MichaelRaskin> 32-bit ARM, in addition to cheap platforms, also has midrange phones
<MichaelRaskin> I am not sure builds for different compilers or different libc behave quite like cross-build
<gchristensen> last night I half implemented r13y's reporting code to be a nix config file's diff-hook program ... tobo: finish
<samueldr> MichaelRaskin: which is why I was egoistically speaking :), mobile-nixos would benefit greatly in a greater ease of use for those "now useless" phones
<MichaelRaskin> Hey what do you mean now useless, the only problem with my Huawei Y6 (~100€ at the time of purchase) is that its battery life is only almost acceptable, and buying another one didn't help much
<MichaelRaskin> I mean, the phones have completely stagnated five years ago anyway.
<gchristensen> so did desktops ...
<gchristensen> samueldr: I feel the mobile-nixos project does change the equation a bit
<samueldr> MichaelRaskin: those quotes around "now useless" were se heavy the fibers sagged under their weight :)
<samueldr> MichaelRaskin: because the "now useless" part is mostly (imo) about how software support isn't there from OEMs, but they are still wholly useful and working!
<samueldr> and your Y6 should be aarch64 from what I can see
<MichaelRaskin> Next you will tell me software support from OEM is useful
<samueldr> in an ideal world it would
<MichaelRaskin> samueldr: you understand nothing in Y6's!
<samueldr> (though some OEMs do ship 32 bits android userlands/kernels on 64 bits cpus... thinking about motorola here)
<MichaelRaskin> There is at least Y6, Y6 II, and Y6 2016 (I think)
<samueldr> yeah, just saw when you said "understand nothing"
<MichaelRaskin> Y6 2016 obviously is marketed as Y6 nowadays
<samueldr> makes it easy to find information /s
<MichaelRaskin> I have an old Y6
<MichaelRaskin> Well, it was back from the days when unlocking Huawei bootloader was just waiting a couple of days for their laggy site to send an emai;
<samueldr> oof yeah, snapdragon 210, Cortex-A7; that needs some 32 bit :)
<samueldr> right, huawei sits in the corner of shame; with North American LGs, and some other OEMs
<MichaelRaskin> I think that corner of shame currently contains approximately all the vendors? I guess the largest ones _not_ in the corner of shame are Asus and Xiaomi?
<samueldr> Google still ship unlockable; I'm not entirely sure what's up with Samsung
<samueldr> Xiaomi does have that 15 days wait period though
<samueldr> Asus will void your warranty by pinging with the mothership
<samueldr> (though it legally cannot void warranties in most regions)
<MichaelRaskin> Exactly
<samueldr> though, unlocking with Asus also removes you from the pool for updates
<samueldr> you will need to download and update manually
<samueldr> which... might not be a bad thing
<MichaelRaskin> Exactly
* samueldr had to type faster than you
<samueldr> IIRC motorola is mostly fine, at least with the hands-me-down I just had it went swminingly
<MichaelRaskin> In the ideal world support from OEM _is_ useless because mainline drivers sort of work well enough
<MichaelRaskin> Motorola is just Lenovo now, right?
<samueldr> not sure if they'Re "just" lenovo, at one point they were still independent for smarphones things
<samueldr> though, I would put a big warning mark on any OEM requiring server interactions, so that leaves... only Google :/
<samueldr> (unsure about Samsung)
<samueldr> because, eh, what happens if/when the server either just bugs out, or they remove support for older devices, or the business folds?
<MichaelRaskin> Well, as what I care about is Lineage from day <30, and I believe Asus to keep the course for the next 60 days more than I believe Google not to change something on 24h notice…
<MichaelRaskin> Bootloader unlock is one-time thing
<samueldr> yeah, though in a _project_ like mobile-nixos, targetting those that can still be unlocked in an unknown future is better
<samueldr> but you're right, once unlocked it becomes a non-issue for that user
<samueldr> and yeah, I also hold a great opinion of Asus for that; they also are relatively timely with source release
<gchristensen> does mobile nixos have a channel yetL
<gchristensen> ?
<samueldr> nope
<MichaelRaskin> If Asus folds you can as well give up on computing
<samueldr> (though I see how we're intruding on mostly off-topic in -dev :))
<gchristensen> that was not a prod
<samueldr> though Asus could decide to close off their smartphone brand, including removing those unlock servers :/
<gchristensen> that was an opportunity for you to pitch a channel for future involvement :P I'm sure I'm not the only one excited to mainline NixOS in to their
<gchristensen> phones
<samueldr> right now I want to peruse the existing channels, mostly because e.g. aarch64 things are #nixos-aarch64 relevant, and others should be relatively relevant to nixos development; going away in a channel with only a few individuals wouldn't be as useful *at this moment* :)
<gchristensen> +1
<samueldr> MichaelRaskin: I gather you handle the lineageos porting yourself to what you buy? if so, neat
<MichaelRaskin> Nope, I just research what has acceptable unofficial ports
<MichaelRaskin> I am no good at debugging drivers for undocumented peripherals
<MichaelRaskin> Well, having a small quiet channel early is sometimes useful
<MichaelRaskin> I wonder how much of NixOS can function on a system with only root account
<MichaelRaskin> I also wonder what is the easiest non-systemd-bound container system to run NixOS containers
<MichaelRaskin> (These are related questions — the real question is whether it is feasible to run single-machine NixOS tests inside Nix builds in containers)
<gchristensen> interesting
<MichaelRaskin> It looks like lxc wants to do a lot of things at once. runC?
<gchristensen> I don't suppose we can't trick systemd to run in a build
<MichaelRaskin> Well, we can unshare and make it PID1 inside and we don't need root for that (using NixOS kernel with user namespaces)
v0|d has joined #nixos-dev
pxc has joined #nixos-dev
callahad has quit [Quit: Ping timeout (120 seconds)]
callahad has joined #nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]
drakonis has quit [Ping timeout: 255 seconds]
justanotheruser has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis_ has joined #nixos-dev
<worldofpeace> :( somehow I'm not a "Great contributor" on discourse. what gives 😅
<samueldr> clicking on the badge explains how it works https://discourse.nixos.org/badges/103/great-contributor
<samueldr> but uh, lol did you login into discourse using your github account?
<worldofpeace> yeah, ain't nobody got time for that
<samueldr> no idea then weird!
<worldofpeace> i call shade on discourse here, where's the admins 🤣
<drakonis> discourse is no bueno my friends
pxc has quit [Ping timeout: 246 seconds]
drakonis has quit [Quit: Leaving]
drakonis_ has quit [Ping timeout: 258 seconds]