<samueldr>
hmm, you're right that release-18.09 tested's latest-finished is not the current channel
<samueldr>
it seems it isn't uploaded to s3 (afaict, mangling the URL)
<samueldr>
so it wouldn't be only the scipt not updating the channels link
<samueldr>
they're all independent timers, so maybe a change is only affecting part of the branches
worldofpeace has quit [Quit: worldofpeace]
<andi->
things that went through there are in the binary cache.. So I do not think the actual content is missing from S3. It might be only the upload of the CD iso etc..?
<samueldr>
yeah, I was talking about the release S3
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
q6AA4FD has quit [Ping timeout: 250 seconds]
q6AA4FD has joined #nixos-dev
init_6 has joined #nixos-dev
q6AA4FD has quit [Ping timeout: 268 seconds]
orivej_ has quit [Ping timeout: 250 seconds]
q6AA4FD has joined #nixos-dev
tilpner has joined #nixos-dev
init_6 has quit []
orivej has joined #nixos-dev
drakonis has joined #nixos-dev
orivej has quit [Ping timeout: 250 seconds]
q6AA4FD has quit [Ping timeout: 250 seconds]
jtojnar has quit [Read error: Connection reset by peer]
<thoughtpolice>
dtz: Curious Q -- let's say I have an expression that I use pkgsMusl to compile to a very small closure. Now, normally of course using pkgsMusl implies building lots of stuff yourself, including the stdenv bootstrap tools since there's no cache.
<thoughtpolice>
dtz: How can I get the bootstrap-tools derivation for pkgsMusl? I would like to upload it to a cache, so that people who hack on my project don't have to recompile the bootstrapping tools themselves
<thoughtpolice>
(I only ask you since you may know about this being the musl person! Honestly I don't know my way around the stdenv setup as good as I should)
<thoughtpolice>
e.g. if they try to run it themselves they get a cache miss for things like 'bootstrap-stage1-gcc-wrapper.drv', but I'm having a surprisingly hard time figuring out where that's coming from!
<thoughtpolice>
I mean, I can always just copy-paste the paths I guess based on what nix-build can't find, but there *should* be like, an actual robust way to do this with Nix code? Right?
<tilpner>
thoughtpolice: You can get the build-time closure by running nix-store -qR on the derivation, and push each path to a cache
<clever>
of note, hydra does the build-time closure for you
<thoughtpolice>
Hmmm that might have done it, though it didn't look like it uploaded the relevant things (e.g. bootstrap-stage1-gcc). Suspicious...
<thoughtpolice>
There are a number of non-suspicious explanations, of course. Either way! I'll see how that works.
<thoughtpolice>
It's also relatively easy for me to manually check this step at update time, since my nixpkgs version is pinned anyway, so expensive cache artifacts like gcc/bootstrapping tools are only going to change when I do bumps.
<tilpner>
thoughtpolice: When I print the build-time closure of pkgsMusl.hello, there are multiple boostrap-stage*-gcc-wrappers
<tilpner>
And a bunch of gccs
<tilpner>
Including /nix/store/narp8d0ndwiq896yamhkjjbh65dbyvxc-bootstrap-stage1-gcc-wrapper.drv
<thoughtpolice>
That's what I mean, it's possible for example only top-level paths I asked to upload were printed, not the deps in the closure that were missing and got pushed, etc. I could have just misread something.
<thoughtpolice>
But it does seem to work
<tilpner>
Maybe you need an --include-outputs
<tilpner>
Don't know, haven't really done that yet
Taneb has joined #nixos-dev
<thoughtpolice>
Nice! Thanks tilpner -- that takes a cold start build down to just a minute or two, almost entirely to download everything
<thoughtpolice>
I can probably look into making a layered docker image containing the deps later (which would be nicer than hitting the cache every time) but this is a good start
<Mic92>
domenkozar: same hangouts as last time?
<domenkozar>
the one in calendar link
orivej has joined #nixos-dev
Mic92 has quit [Quit: WeeChat 2.3]
Mic92 has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
q6AA4FD has joined #nixos-dev
Synthetica has joined #nixos-dev
jtojnar has joined #nixos-dev
orivej has joined #nixos-dev
<dtz>
thoughtpolice: not sure if your question was answered, but FWIW the bootstrap bits are in `pkgs/stdenv/linux/bootstrap-files/*-musl.nix` -- that's where it starts. And for the rest yeah I'd do some nix-store invocation to grab build closure and push (that's an operation I do regularly, for this reason!)
<dtz>
multiple gcc's are probably just wrappers
<dtz>
well, LMK if there's an outstanding question/problem :). When manually computing build closures I find `--include-outputs` sometimes useful?
<dtz>
depending how you're copying the "closure" path list, you may find the difference critical. But yeah mostly I need to get a hydra instance running again xD
<dtz>
depending how you're copying the "closure" path list, you may find the difference critical. But yeah mostly I need to get a hydra instance running again xD
<{^_^}>
#51185 (by matthewbauer, 9 weeks ago, open): Get rid of bootstrap-tools for compatible architectures
<matthewbauer[m]>
I was wondering if you thought that was a good idea?
<gchristensen>
nixos-generate-config should emit a "system = ..." line probably
<gchristensen>
related, I think our method of install is brilliantly simple and wonderful
<clever>
gchristensen: i recently helped somebody enable ssh on the pre-build hydra image
<clever>
but we ran into a number of problems
<clever>
main one, was a missing configuration.nix, had to run nixos-generate-config on the wrong arch, and fix it up
<gchristensen>
I remember that
<clever>
then it was just a matter of getting qemu-user online, mounting the binfmt wrappers into /mnt/, and playing with chroot and nix-env
<clever>
NIX_REMOTE=local?root=/mnt/img/ nix-env --profile /mnt/img/nix/var/nix/profiles/system --set -f '<nixpkgs/nixos>' -A system -I nixos-config=/mnt/img/etc/nixos/configuration.nix --option system aarch64-linux
<clever>
Raw
<clever>
that was the most complex part of it
<clever>
related, i often see OSX users running `--option system x86_64-linux` incorrectly, when they want to do linux builds
<clever>
and it "just works" if they have a linux build slave (it prefers remote over local)
<clever>
but fails horribly when they dont
<clever>
because that flag, changes both the default arch (as seen by builtins.currentSystem), and what nix thinks the current arch is (so it believes it can run linux binaries)
<gchristensen>
it is out of this world that I can make & mount a couple partitions, run two commands, reboot, and have nixos on some niche arm hardware I didn't even know existed until this morning (qualcomm centriq)
<matthewbauer[m]>
ah ok
<matthewbauer[m]>
do you really need qemu-wrap.c? I thought binfmt should work with qemu-user out of the box
<clever>
matthewbauer[m]: i dont remember exactly what its doing, but it was fixing something to do with argv[0]
<clever>
matthewbauer[m]: another important factor, is a static qemu-user
<clever>
ldd simply sets some magic vars, that cause ld.so to print debug
<matthewbauer[m]>
you don't need static, at least with nix
<matthewbauer[m]>
i guess i wasn't using binfmt though
<clever>
so when nix runs `ldd ./arm-binary`, the qemu-user's x86 ld.so spits out qemu's deps!
<clever>
then you wind up with x86 libraries in your arm initrd
<clever>
the only way to avoid that, is to
<clever>
a: not use ldd in the guest at all
<clever>
b: patch the ld.so qemu uses, to obey different magic vars
<clever>
c: static qemu
<matthewbauer[m]>
ok that clears things up for me
<matthewbauer[m]>
but that makese sense. how often is ldd used btw?
<clever>
the main place i see it used, is when building the initrd, to query what the deps of a binary are, and then copy just the libs
<clever>
so the closure is massively shrunk, but still dynamic
<clever>
it will also re-patchelf everything after copying libs
<gchristensen>
there are 3k jobs but maybe they're waiting for part of the tree to finish
<gchristensen>
I also sort of suspect our scheduler can't handle all the hardware we can throw at it ...
<clever>
gchristensen: ive lately been dealing with a release.nix that takes 300+ seconds to eval on hydra
<gchristensen>
yes, that is another problem
<clever>
gchristensen: one issue ive noticed, is that hydra resets itself every time the heap goes over 1gig, but the constituent job depends on everything, and spikes the heap to 9gig, and re-compiles the entire jobset
<gchristensen>
a big part of all this is cross and what-not
<clever>
the jobset ive been profiling, does linux, darwin, and linux->windows cross
<gchristensen>
not _using_ cross, just having cross, has made eval time much longer
<gchristensen>
*hem* armijn7hWe are proud to announce that NixOS Foundation is participating in the European Union’s Next Generation Initiative (NGI) as part of the “NGI Zero” consortium. “NGI Zero” consists of a world class coalition of not-for-profit organizations that will support the researchers and developers with their expertise on security and code quality, accessibility (making technology available to
<gchristensen>
everyone, including peoplewith disabilities), localisation/internationalisation (to increase language diversity on the internet), packaging and reproducible builds, documentation, responsible disclosure, diversity, community building and more. “NGI Zero” is led by NLnet Foundation, a Dutch non-profit that has been supporting building a free and open Internet for over 20 years and funding development of
<gchristensen>
core Internet technologies.Between now and 2021 grants will be given to independent researchers and open source developers, with a total of 11.2 million Euro. These projects will be selected through bi-monthly calls (with the next callstarting at February 1 2019). The themes for these calls are “privacy enhancing technologies” and “search and discovery”. Anyone with a good idea fitting one or both
<gchristensen>
of these themes is encouraged to send in a proposal via the “NGI Zero” website. We are certain that the NixOS community can come up with creative ideas. Please note that a proposal does not have to be related to Nix or NixOS (although we would certainly not mind). What is important is that it fits the themes.In addition, it is a goal of NGI Zero that software created by accepted projects can be used as
<gchristensen>
widely as possible. Concretely, this means that they should be buildable via Nix. Therefore NGI Zero provides asubstantial budget to the NixOS project to build and package accepted projects. If you are interested, please contact us at foundation@nixos.orgFor more information about NGI Zero and sending in proposals pleasevisit NLnet’s website at the following
<gchristensen>
URLs:https://nlnet.nl/news/2018/20181201-NGIZero.html 11https://nlnet.nl/PET/ 7https://nlnet.nl/discovery/ 3For those of you going to FOSDEM: NLnet Foundation and people from the European Commission will be at FOSDEM. Eelco will also be at FOSDEM.created7hlast
<clever>
gchristensen: whats more fun, is when the linux selection buffer has a rollback when you open xterm
<clever>
and you wind up pasting the wrong thing, even if you dont get clipboard and selection mixed up
<gchristensen>
paste behavior is why I don't use xterm :P
<clever>
i use selection buffer almost exclusively
<clever>
gchristensen: and ive discovered a few websites that dont handle selection buffr well
<clever>
aws route53, refuses to let you paste with middle click
<clever>
other sites, only trigger the actions onkeyup, not onchange, so middleclick doesnt register the field as having changed
<gchristensen>
before we get far off topic, I'd like to revisit the *hem* -> the contents of that link, and its relevance
<clever>
some stupid sides dont use the placeholder, and instead set the value to "search"
<clever>
gchristensen: that link reminds me of a story i heard from a blind friend i met online
<clever>
she worked at a call center, and had screenreading software installed on the work PC
<clever>
then she discovered one day, she can hear peoples passwords
<clever>
the password edit box in the software, was pulling the plaintext pw out of a database, and just masking it at UI render time
<clever>
but the screenreader didnt care, and read the pw outloud!
<clever>
and one day, the software broke, and company IT couldnt fix it
<clever>
but legally, they cant fire her over the disability
<clever>
so they paid her to just sit there, and do nothing, all day
ghuntley has joined #nixos-dev
<Synthetica>
That's either the best job ever, or the worst job ever, depending on who you ask
<clever>
yeah, they probably wanted her to quit from bordom
<clever>
loopholes
<clever>
and i believe she was using pirated copies of the screenreading software, because the supply is limited and pricing is robery
<clever>
would be interesting to get a nixos module for that kind of software
<samueldr>
so uh, gchristensen relevancy :)
<clever>
i can also see it being of use for wearable computing, just jam a netbook into a bookbag (or even a full sized laptop), enable the screen-reader, and pop in some headphones
<ghuntley>
- dotnet-runtime
<ghuntley>
- dotnet-sdk
<ghuntley>
There will be two packages:
<ghuntley>
hey folks, need to pick your brains. I'm building expressions that are soon to be contributed back up stream.
<ghuntley>
Both packages install a binary called `dotnet`
<ghuntley>
I know there's an option in the manual to tell nix that `dotnet-sdk implements everything of dotnet-runtime so no need to install dotnet-runtime if the sdk is installed`. What's it called?
<clever>
then you need some limited-mobility style inputs, like controlling it with 1 button
<symphorien>
ghuntley: meta.priority maybe ?
<samueldr>
I was going to reply on the discourse post this evening, but there's not a bunch of time to come up with proposals fitting the theme if it's by Feb 1st (tomorrow for some)
<ghuntley>
bingo, that's the word that I couldn't articulate. Thank-you.
<samueldr>
proposals are, I guess, some wordly documents and not just one sentence?
<samueldr>
(need to read about it before asking, but eh, lazy #nixos-dev help me :))