<{^_^}>
rfcs#29 (by samueldr, open): [RFC 0029] Backports team
drakonis has quit [Ping timeout: 240 seconds]
drakonis has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
pie_ has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
phreedom has quit [Ping timeout: 250 seconds]
phreedom has joined #nixos-dev
phreedom has quit [Ping timeout: 250 seconds]
phreedom has joined #nixos-dev
pie_ has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-dev
<ekleog>
Hey! Anyone as already packaged a 32-bit closed-source executable? I'm using stdenv_32bit and `patchelf --set-interpreter "$(cat "$NIX_CC/nix-support/dynamic-linker")" bin/cref`, but somehow still get “zsh: accessing a corrupted shared library: ./result/bin/cref”, `ldd` telling me it's not a dynamic executable and `file` telling it *is* a dynamic executable (with the patched interpreter)
<ekleog>
+h
<clever>
ekleog: you want to use the 32bit pkgs and patchelf
<clever>
ekleog: pkgsi686Linux.callPackage
<ekleog>
Oooh, stdenv_32bit is not enough? will try this, thanks!
<clever>
then all the deps your given will be 32bit only
<clever>
its probably using a 64bit patchelf
<ekleog>
clever: Thanks! it worked \o/
<ekleog>
So if someone tried to review https://github.com/NixOS/nixpkgs/pull/44148 before and was put off by my comment mentioning I had forgotten to check all executables, now the last non-working executable appears to execute correctly :D (even though I haven't yet come to actually using all the executables, as I'm in the process of discovering the SDK, so I don't know if everythings works as expected, just that
<{^_^}>
#44148 (by Ekleog, open): javacard-devkit: init at 2.2.2
<ekleog>
it appears to run)
sir_guy_carleton has quit [Quit: WeeChat 2.0]
<aszlig>
ekleog: don't these executables have shared library dependencies?
aszlig has quit [Quit: Kerneling down for reboot NOW.]
aszlig has joined #nixos-dev
<clever>
ekleog: the default unpackPhase will unpack the zip for you, so you can delete lines 23 and 26-28
orivej has joined #nixos-dev
<aszlig>
clever: mhm, but the zipfile also looks like a tarbomb
<clever>
aszlig: i think it only has one level, but i havent checked the zip directly
<makefu>
ekleog: you are doing something with the javacard devkit? i was looking for some way to upload a java applet to a smartcard `just yesterday`
FRidh has quit [Read error: Connection reset by peer]
<aszlig>
clever: and yeah, it was a tarbomb and it also contained zip files within the main zip file
<aszlig>
clever: so the main zip file had Legal/ and java_card_kit-2_2_2/, the latter being the directory where a few other zip files were located
orivej has quit [Ping timeout: 256 seconds]
goibhniu has joined #nixos-dev
jtojnar_ has joined #nixos-dev
jtojnar has quit [Read error: Connection reset by peer]
jtojnar_ is now known as jtojnar
orivej has joined #nixos-dev
vcunat has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
<pierron>
Good news, I found a way to solve properly and in a way which works nicely with overlay, the problem of package sets for python, hackell, emacs, <insert your interpreter here>, …
<pierron>
I will make a pull request soon.
<pierron>
By nicely, I mean no need for extra fix-point, nor having any custom syntax for overriding.
<pierron>
Once fixed, the following should be a valid overlay which behaves as expected \o/ self: super: { python27Packages = super.python27Packages // { pyramid = super.python27Packages.pyramid.override { ... }; }; }
garbas has quit [Ping timeout: 256 seconds]
<pierron>
domenkozar: ^ ;)
garbas has joined #nixos-dev
jtojnar has quit [Remote host closed the connection]
jtojnar has joined #nixos-dev
<pierron>
https://git.io/fN2vv => Status of Haskell/Packages-set fix-points: soon dead \o/
<ekleog>
<aszlig> ekleog: don't these executables have shared library dependencies? <-- Looks like not, at least it seems to output the help message with just patchelf (the other scripts just call into java afaict, and I've gone up to the phase “go from .java to .cap” with them) -- will look at your proposed suggestions tomorrow, thanks! :)
<ekleog>
<clever> ekleog: the default unpackPhase will unpack the zip for you, so you can delete lines 23 and 26-28 <-- The problem I had hit was that the .zip had multiple top-level directories, which appeared to mess with the default unpack phase -iirc, an error message like “unpacking produced multiple directories”) -- I didn't know of zipPrefix / unpackCmd aszlig pointed me too yet :)
<aszlig>
ekleog: zipPrefix isn't something special, just to avoid having too long lines and deduplicate the java_card_kit-blahblah stuff
<aszlig>
ekleog: and i found that there is a shared library dependency, libpcsclite.so, so i added autoPatchelfHook
<ekleog>
makefu: Nice! I'm currently in the phase of trying to write a hello world javacard applet and upload it, passed the .java -> .cap step, next step appears to look like it'll be https://github.com/martinpaljak/GlobalPlatformPro ; I expect to look at packaging / using this tomorrow too:)
<ekleog>
aszlig: oh, it's the unpackCmd, then, indeed, hadn't yet looked in detail into how it worked, thanks :)
<ekleog>
(though I'm not sure I really get this `| jar x` step -- is it an equivalent of `unzip /dev/fd/1`?)
<aszlig>
ekleog: yes, it is, because unzip /dev/fd/1 doesn't work
<ekleog>
'k thanks! :)
<aszlig>
ekleog: and even if you mean fd 0, it still doesn't work because unzip expects the file to be seekable
<ekleog>
… ugh wat? I had checked with `cat /dev/fd/1` that it was the correct fd number, but `cat /dev/fd/0` and `cat /dev/fd/2` work just as well
<ekleog>
What's this dark magic?
<ekleog>
(anyway, thanks, I was just trying to understand why `jar` for doing an unzip, but it's just the same underlying representation :))
<simpson>
Yeah, a JAR is a ZIP with some extra metadata which happens to be represented as extra files in the ZIP manifest.
<aszlig>
... followed by an error
<aszlig>
ekleog: well, i more or less abused jar there because the package already pulls in jdk and unzip doesn't allow reading from stdin, but jar does =)
<ekleog>
aszlig: yeah indeed, got it now, thanks :) (though I still don't understand how `cat /dev/fd/1` works x))
<ekleog>
Maybe something based on “if you try to open stdout in reading then linux is “nice” and gives you stdin in reading instead”? O.o
<ekleog>
(and, like, the strace appears to confirm it's not just cat “auto-correcting my mistake”)
<aszlig>
ekleog: the reason this works is because you type stuff with echo on, so you get that stuff in stdout from the currently running program
<aszlig>
ekleog: compare this to "echo foo | cat /dev/fd/1"
<ekleog>
aszlig: Yeah, but then… why does this work with `cat /dev/fd/2`? even with echo on it shouldn't echo onto stderr, should it?
<ekleog>
(btw, hadn't thought of the echo possibility, thanks!)
<aszlig>
ekleog: i'd *guess* that's because the terminal itself only knows about *one* output
<aminechikhaoui>
vcunat: wrt to your question about nixos-unstable-small not advancing, it's seems it's failing since generate-programs-index is throwing an error
<aminechikhaoui>
error: in package ‘checkpolicy’: this derivation has bad 'meta.outputsToInstall'
<LnL>
so why do I need to use foo.out for ~100 packages
<Dezgeg>
to accomplish what?
<LnL>
for example gnutls doesn't have a lib output
<LnL>
so if I want to reference libraries I need to do ${gnutls.out}/lib
<Dezgeg>
you can do e.g. LD_LIBRARY_PATH=${lib.makeLibraryPath [ foo bar baz ]}
<LnL>
no, that looks in the lib output
<Dezgeg>
try it :P
<LnL>
huh
<Dezgeg>
and usually when compiling, you'd just do buildInputs = [ gnutls ]; anyway
<LnL>
I thought that didn't work either, since it's not named correctly
<Dezgeg>
but yes, for those rare cases where you really need the lib path it gets complicated... you can do "-L${lib.getLib gnutls}/lib"
<domenkozar>
pierron: nice
goibhniu has joined #nixos-dev
vcunat has quit [Quit: Leaving.]
<ekleog>
<aszlig> but that does: <aszlig> /dev/fd/2: symbolic link to /dev/pts/30 <aszlig> /dev/fd/1: symbolic link to /dev/pts/30 <-- Ooooh indeed, thanks! :D
sir_guy_carleton has joined #nixos-dev
<ekleog>
makefu: I'll let you know as soon as I manage to upload & test a .cap, then :) (on #nixos-chat, I guess)