ekleog changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html https://r13y.com | 18.09 release managers: vcunat and samueldr | https://logs.nix.samueldr.com/nixos-dev
drakonis has quit [Quit: WeeChat 2.3]
pie___ has joined #nixos-dev
pie__ has quit [Ping timeout: 259 seconds]
orivej has joined #nixos-dev
<thoughtpolice> Finally got my GPG setup working again and now I have that sweet 'verified' badge.
<thoughtpolice> Need to recover and issue revocations for my old keys, now...
<teto> wait nix is not participating to Gsoc :'that's too
<teto> bad I could have helped with the administrative stuff
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined #nixos-dev
<domenkozar> any nix news for weekly? :)
<domenkozar> gchristensen: did you manage to rerun r13y?
<domenkozar> I guess from staging :)
<domenkozar> oh I hope he's sleeping
<domenkozar> :grin:
ivan has quit [Quit: lp0 on fire]
harrow has quit [Quit: Leaving]
ivan has joined #nixos-dev
harrow has joined #nixos-dev
ivan has quit [Quit: lp0 on fire]
harrow has quit [Client Quit]
ivan has joined #nixos-dev
harrow has joined #nixos-dev
v0|d has joined #nixos-dev
<ckauhaus_> sphalerite: I have to go to another meeting this afternoon, so my time slot is only 1330 UTC till 1400 UTC
<ckauhaus_> but I think we should be able to cover the most importants topics during the first half hour
<sphalerite> alright. Ideally we'll be finished by then, failing that you can just jump out :)
e-user has joined #nixos-dev
ckauhaus_ is now known as ckauhaus
v0|d has quit [Remote host closed the connection]
primeos_ has quit [Quit: WeeChat 2.3]
primeos has joined #nixos-dev
init_6 has joined #nixos-dev
init_6 has quit []
init_6 has joined #nixos-dev
<teto> I would like to reduce impurities in the kernel (make the config depend on package requirements). Not sure where and how to store package requirements : meta.requiredKernelConfig ? Looking for some feedback in https://github.com/NixOS/nixpkgs/issues/41103#issuecomment-463119193
init_6 has quit [Ping timeout: 246 seconds]
init_6 has joined #nixos-dev
FRidh has joined #nixos-dev
<gchristensen> domenkozar: nothing spectacular has changed, many of the changes went in to staging-next
<init_6> Hi all! I do not have an account on github so there https://pastebin.com/xH3fkqCf is openmw-0.44.0 ported to Qt5 yep https://github.com/NixOS/nixpkgs/pull/46153 + https://github.com/NixOS/nixpkgs/pull/33239 If anyone is interested in this. Thx.
<{^_^}> #46153 (by hcmensch, 22 weeks ago, open): openmw: 0.43.0 -> 0.44.0
<{^_^}> #33239 (by peterhoeg, 1 year ago, open): Migrate from qt4 to qt5 [WIP]
<tilpner> gchristensen: Nothing fancy, doesn't cover all features: https://gist.github.com/tilpner/1a35da6a80a350ae868d7001b44056bb
<gchristensen> nice!
<tilpner> While it's feasible for the user to adjust the rules for applications with few responsibilities, it would require a lot more structure and coordination to properly wrap any desktop application
<tilpner> And I wrote pbServe myself, so I know exactly what it does (very little), and what to allow
<tilpner> So I wouldn't try this on e.g. Firefox
<tilpner> (And the rlimit arg was probably a bad choice, that should happen in the systemd service, not via apparmor)
<gchristensen> right
<gchristensen> ok the new r13y.com report is up https://r13y.com/ dropping to 97.99% (wavering is to be expected as things which happened to reproduce before don't this time)
<andi-> :+1:
<tilpner> "unfairly closed source software" :o
<qyliss> So how does this meeting thing work?
ciil has quit [Remote host closed the connection]
<gchristensen> sphalerite: ^
<sphalerite> qyliss: see the link on "location" in the calendar thingy
ciil has joined #nixos-dev
<gchristensen> qyliss: you can click the no-video thing if you'd like
orivej has quit [Remote host closed the connection]
<domenkozar> gchristensen: how come the new diffoscope is not in the report? :)
<domenkozar> Generated by diffoscope 99
<domenkozar> :(
<gchristensen> hmmmm
<domenkozar> pinned nixpkgs?
<gchristensen> oops, I used my local nixpkgs instead of nixos-unstable-small :)
<domenkozar> so unpinned :D
<gchristensen> yep
<gchristensen> I'm doing a re-check now, so don't really have any cpu or ram to spare for running diffoscope again
<domenkozar> no worries
<gchristensen> but once it is done (5-6hrs or so) I'll make sure to regenerate with the new one
<sphalerite> gchristensen regenerates? Like the Doctor?
<gchristensen> these RFC meetings leave me feeling invigorated!
<domenkozar> > give strength or energy to.
<{^_^}> error: syntax error, unexpected ')', expecting ID or OR_KW or DOLLAR_CURLY or '"', at (string):219:1
<qyliss^work> init_6: would you consider submitting to https://discourse.nixos.org/c/dev/patches? Means your stuff won't get lost in IRC backlog.
<domenkozar> qyliss^work++
<{^_^}> qyliss^work's karma got increased to 4
<gchristensen> qyliss^work++
<{^_^}> qyliss^work's karma got increased to 5
<qyliss^work> Great, thank you! We don't get many patches this way, so people might not see it, but it's important to me that people don't have to use GitHub so I'll try to make sure this gets through.
<init_6> qyliss^work: there are new release of openmw is almost out https://github.com/OpenMW/openmw/pull/1547#issuecomment-462024047
ckauhaus has quit [Quit: WeeChat 2.2]
<samueldr> uuuuuuh, anyone upgraded to 4.19.21, released yesterday?
<gchristensen> ...whatsup?
<samueldr> I think they backported the commit breaking shebangs
<tilpner> :D
<samueldr> they did for 4.20 according to dtz
<samueldr> and I looked, same commit was backported between 4.19.20...21
<gchristensen> shit
<samueldr> .yes
<samueldr> released 2019-02-12, so it might explain the lack of chatter about it on our channels
<samueldr> but this... this may come up soon
<dtz> oh, is it confirmed? ty haha
<tilpner> We could have shebang-arg-wrappers, to workaround the length limitations
<gchristensen> where is the tracking bug?
<tilpner> But... :/
<qyliss^work> See petrkr's stuff in #nixos earlier
<qyliss^work> It's already come up
<gchristensen> we should revert the upgrade and ping nesquimess
<qyliss^work> On 18.09, no less
<dtz> yo dawg I heard you like shebangs
<samueldr> dtz: not *confirmed*, that's why I'm asking
<samueldr> qyliss^work: came up since yesterday?
<samueldr> or on 5.0-rc*?
<samueldr> out tracking isssue: https://github.com/NixOS/nixpkgs/issues/53672
<{^_^}> #53672 (by eadwu, 5 weeks ago, open): switch-to-configuration not interpreted using perl
<dtz> oh I thought you found the commit, sorry! Don't mean to put words in your mouth. Happened on my laptop and nixops-controlled machine and sure seemed to start happening with 4.20.8 (and not 4.20.7)
<dtz> brb git
<samueldr> dtz: aszlig tracked it down (see the upstream issue)
<samueldr> thanks qyliss^work
drakonis has joined #nixos-dev
<samueldr> (wasn't doubting, just assessing the situation, because it could become a large thorn on our side)
<gchristensen> tilpner: macOS doesn't support scripts as shebangs
<tilpner> gchristensen: So then we compile them? This doesn't get any prettier :(
<samueldr> this is a situation where the kernel is breaking userland, and I'm like 99% sure we shouldn't have to deal with gnarly hacks :/
<gchristensen> 1) revert the upgrade in nixpkgs
<gchristensen> 2) aszlig halp
<dtz> xD <3
<samueldr> oh no! 4.14.y too?
<samueldr> I need to go back to $workthing-which-is-not-nixpkgs-nor-linux-related
<ekleog> we could automatically compile a program that just does `execve` with the right arguments, but… that'd mean requiring `gcc` for writing any shebang :(
<gchristensen> and would cause a significant performance drop
<tilpner> I wonder if it could be done by patching a precompiled binary
<tilpner> But even if that was possible, it's still really ugly and severely hinders debugability
<ekleog> it's one more `execve`, do you think it'd be actually significant?
<tilpner> Which isn't that great to start with
<gchristensen> it isn't 1 more, it is 1 more per exec
<gchristensen> so, 2x :)
<ekleog> indeed
<qyliss^work> Is this a different bug to spaces in shebangs?
<ekleog> tilpner++, was thinking about patching a prebuilt binary
<{^_^}> tilpner's karma got increased to 15
<ekleog> it's potentially non-trivial, though
<ekleog> gchristensen: even 2x for the execve, there'd be for sure a performance drop, but do programs actually `execve` scripts often?
<tilpner> ekleog: It could also be "#!/nix/store/*-exec-wrapper /nix/store/*-exec-wrapper-args-foo", and it would read args-foo and execute them. No patching, and constant shebang length
<ekleog> (and it's still better than the script-in-shebang option, that'd have spin-up and tear-down of a script)
<gchristensen> if this were a voting thing
<ekleog> tilpner: that's too long, though, isn't it?
<gchristensen> I'd vote we not discuss workarounds, and instead brainstorm ways to get appropriate attention on the issue, and work first to get it fixed
<ekleog> hasn't that already failed? I mean, if the patch has even been backported then the breaking change is already done, whatever we can say about it, isn't it?
<samueldr> the kernel never breaks userland
<ekleog> except when it's “fixing a kernel bug”
<samueldr> they probably haven't noticed the bug in the tracker
<samueldr> pretty sure that here it's not a case where they're fine breaking userland
<tilpner> ekleog: Well, it's closer than comfortable
<tilpner> > 2 * builtins.stringLength hello.outPath
<{^_^}> 108
<ekleog> so now the question is “who is ‘they’”?
<tilpner> Which is < 128, which is what my BINPRM_BUF_SIZE is set to
<tilpner> Longer names, and (more importantly) longer storeDir prefixes... and it breaks
<ekleog> tilpner: then it's possible indeed (thought it was set to 64 by default)
<ekleog> maybe we should ask the person who r+'d the backport about our issue
<samueldr> (and note that the workaround assumes /nix/store; if I were to /var/lib/some-businessy-longish-string/nix/store it would fail)
<gchristensen> "If you suspect a maintainer is notresponding to these types of bugs in a timely manner (especially during amerge window), escalate the bug to LKML and Linus Torvalds."
<tilpner> Yes, I mentioned that
<tilpner> It's not a pretty solution at all
<samueldr> (tilpner: yeah, you ninja'd me :))
<gchristensen> who wants to email Linus?
<samueldr> gchristensen: I could do it
<samueldr> let's just agree to not swamp him :)
<gchristensen> +1
<gchristensen> only one
<gchristensen> samueldr: I'd review your email if you author
<samueldr> or swarm, or whichever
drakonis has quit [Quit: WeeChat 2.3]
<gchristensen> samueldr: I emailed oleg, author of the patch
<samueldr> thanks
lewo has quit [Read error: Connection reset by peer]
lewo has joined #nixos-dev
e-user has quit [Remote host closed the connection]
init_6 has quit []
<samueldr> semi-good-news everybody, at least the tests infra fails to advance the channels now that it's part of the tested set
<Taneb> \o.
<Taneb> (half-celebration emoticon thing)
FRidh has quit [Quit: Konversation terminated!]
jtojnar has joined #nixos-dev
<gchristensen> I wonder if we can fix libguestfs's build to not produce a huge (small) sparse file, and then be able to build it in hydra
<samueldr> I don't remember: are the VMs it builds downloaded or do we rebuild them?
<samueldr> because IIRC they can be rebuilt as needed
<samueldr> if we build them, maybe we can minimize the size of the disk images?
<gchristensen> not sure
<gchristensen> but NARs don't support sparse files, causing the sparse file to expand
<gchristensen> maybe it doesn't even do it anymore -- https://github.com/NixOS/nixpkgs/commit/433d30b87728313556d8f4d61728e0b9a51063d4
* ekleog wonders how bad it would be to drop NARs and use tar. We'd have to write a custom executable that would build the tar in a reproducible way, but would that be worse than having a custom executable that builds the NARs?
<ekleog> worst thing would likely be the churn :/
<ekleog> like, how to introduce tar fetching support in nix, and only in years stop building nars and build tars instead
<gchristensen> NARs are pretty cool
<ekleog> the good point would that then we'd be extensible like tar is, ie. we could include support for sparse files without having to patch the fetching side
<ekleog> are they?
<gchristensen> thy support way less than tar
<ekleog> they do, which is exactly the issue in this case (of handling sparsity)
<gchristensen> like I don't think it is really possible for a tar to express a file should exist outside of its destination dir
<gchristensen> using tar, which supports way more, makes it way more risky
<ekleog> it definitely is, but we're already having `builtins.fetchTarball`, I don't see in what way it'd be worse
<gchristensen> fetchTarball doesn't write in to /nix/store
<gchristensen> anyway, yeah
<ekleog> well, fetching a nar could write to someplace else in the sandbox and nix move it afterwards :)
<ekleog> (basically using the same level of sandboxing than fetchTarball & co)
<gchristensen> couldn't hurt
<ekleog> erhm, s/nar/tar/ actually as I was thinking of the “let's switch to tar” 15-year plan, but it could do for nar's too
<tilpner> Could hurt, on small devices with small /tmp
<gchristensen> oh NARs also can't express things like setuid etc.
<ekleog> if the nar download is done in a sandbox, nix's steps in moving it out of the sandbox will erase the setuid bit etc. anyway :)
<ekleog> tilpner: I wonder how nix currently handles nar download… just-in-time decompression?
<gchristensen> actually it'll fail to decompress
<ekleog> right, the seccomp wrapper
<gchristensen> great email, samueldr
<LnL> oh, what's the new limit? a giant shebang like that isn't a good idea on other platforms either
<samueldr> I would tend to agree, but it's not a nice situation to have the userspace break like that
<thoughtpolice> worldofpeace: Thanks for your comment on the Keybase thing, good catch -- see https://github.com/NixOS/nixpkgs/pull/55679#issuecomment-463310601
<LnL> I agree they shouldn't break it on an LTS unless there's a very good reason, but the current limit is over 1mb which is arguably a bit absurd
<ekleog> samueldr++
<{^_^}> samueldr's karma got increased to 55
phreedom has quit [Ping timeout: 256 seconds]
phreedom_ has joined #nixos-dev
<samueldr> non-exhaustive, non-deduplicated, list of >128 bytes shebangs on my system https://gist.github.com/0edbd7801701da0ab17d1e8868ef8b76
<zimbatm> is anyone looking at generating switch-to-configuration without the huuuge shebang?
<tilpner> zimbatm: Could try a buildEnv, instead of passing each dependency individually
* tilpner knows nothing about perl packaging
<samueldr> it's most likely something rooted in the perl infra of nixpkgs, rather than switch-to-configuration specific
<gchristensen> https://r13y.com/ new report is up -- 98.15% after 2 previous unchecked paths were checked (and the diffoscopelinks are improved -- generated with diffoscope 110, domenkozar)
<tilpner> gchristensen: What's the one remaining unchecked path?
<gchristensen> great question
<samueldr> >> Generated at 1970-01-01 from
<samueldr> reproducible reproducibility reports?
<gchristensen> :P
<gchristensen> I told you it isn't 100% feature complete ;)
<gchristensen> tilpner: nasm-2.14.02 fails to rebuild due to a mirror problem I think?
<gchristensen> specifically, nasm-2.14.02.tar.bz2.drv -- the source
<tilpner> Ahh, okay
<gchristensen> todo listing these failed drvs, but I really needed to get another report out and started shedding features like generation date
<gchristensen> the new builder can do a full reproducibility check in 4hrs or so, which is pretty nice
<gchristensen> this is a cool thing, having it verify sources
JosW has joined #nixos-dev
<sphalerite> gchristensen++
<{^_^}> gchristensen's karma got increased to 74
JosW has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
copumpkin has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<tilpner> I looked at the groff manpages, their manpages use @MDATE@
<tilpner> How should this be fixed?
<tilpner> Patch it out in nixpkgs? faketime?
<gchristensen> protip: googling "MDATE" turns up a millionaire dating website.
<gchristensen> what is @MDATE@?
<tilpner> (Tell upstream of the benefits of... not doing this?)
<tilpner> Probably modification date
<tilpner> Which is what causes the current date to appear in the built manpages
<gchristensen> I'd look in the /tmp/nix-build-... dir for its build and see if @MDATE@ is defined in the configure script. if so, fix the configure script. if not, check debian's groff package to see if they have a patch, failing that, use a substitution thing to dejlete it :P
<tilpner> Fix this, and groff.man --checks
<tilpner> -e "s|@MDATE@|$(mdate)|g" \
<tilpner> Ahh, their Makefile does this
<tilpner> But what do we want it to say?
<tilpner> No date? Jan 1 1970?
<gchristensen> perfect, replace with 01 January 1970
<gchristensen> yeah
<gchristensen> tilpner++
<{^_^}> tilpner's karma got increased to 16
<tilpner> .TH roff2dvi 1 "13 February 1969" "Groff Version 1.22.3"
<tilpner> Well, uhh
<gchristensen> closer, fewer unreproducible bytes :P
<tilpner> Why display Jan 1 1970 though, when we could have no date?
<gchristensen> we could try it
<gchristensen> my uninformed opinion is put bogus data in place of unreliable data, just in case something is looking for it
<gchristensen> https://perl5.git.perl.org/perl.git/blob/04db542212fdad3a62f13afe741c99028f4bf799:/toke.c#l5524 <- the filename here reveals the circumstance in which the shebang parsing took place
<gchristensen> samueldr: is this right? --- the important part of the shebang, ie: the executable path, was less than the maximum length, so the remainder would be truncated or not -- whatever -- it makes no difference... but then perl would come along and reread it and find the good stuff. but, now that the kernel doesn't truncate, and fails instead ... well, perl doesn't have the opportunity
drakonis has joined #nixos-dev
catern has joined #nixos-dev
<catern> I'm going to start actually working on https://github.com/NixOS/nix/issues/1734 does anyone have any opinions about how to approach it? I'd like to do option 4, but that requires some non-trivial enhancements to the daemon protocol, so I might just do it totally locally, but then that requires the Nix client to walk the whole build tree itself... which is easy, but inelegant, and maybe unacceptably inefficient?
<{^_^}> nix#1734 (by catern, 1 year ago, open): Add a mechanism for untrusted users to offload builds of fixed-output derivations
<samueldr> gchristensen: I don't know if it's *right*, but I remember hearing this or something along the line
<samueldr> I don't know where
<gchristensen> it feels right
<gchristensen> does volth do IRC?
<srhb> gchristensen: I've never seen them with that name on freenode at least.
<gchristensen> despite their gives-me-creeping-skin avatar, they're our perl person! :)
<zimbatm> so I tried this approach and it doesn't work: https://github.com/zimbatm/nixpkgs/commit/638ae2c62f81fd53292558ad15a575ff74eb8a9d
<zimbatm> according to SO it should be possible to tweak the @INC paths in a BEGIN{} header
<zimbatm> I was trying to avoid building yet another wrapper
<zimbatm> maybe niksnut knows why it doesn't work
<zimbatm> > Can't locate File/Slurp.pm in @INC (you may need to install the File::Slurp module
<{^_^}> error: syntax error, unexpected IN, expecting ')', at (string):218:28
<samueldr> please, if we can avoid wrappers
<LnL> could be too late there?
<zimbatm> it's the same if I move the BEGIN{} block before the first `use`
<LnL> isn't that one of the last remaining perl scripts in a base nixos install
<zimbatm> one of the few
<zimbatm> there was a PR recently to rewrite it in python which was rejected
<gchristensen> zimbatm: do you still have a switch-to-configuration build product using that INC method?
<gchristensen> hmm nice
<zimbatm> you can reproduce the issue without using `sudo`
<LnL> use lib '@foo@/lib/perl5/site_perl'; seems to work
<gchristensen> zimbatm: what if you replaced the push with many lines, one of `use lib '/one/of/your/store/paths';` per site-lib?
<gchristensen> bing@
<gchristensen> bingo!
<LnL> and looks like you can pass it a list
<gchristensen> <3
<zimbatm> one sec, updating the patch
* gchristensen crosses many fingers
<LnL> that adds both @foo@/lib/perl5/site_perl and @foo@/lib/perl5/site_perl/5.28.1 to @INC so maybe that second one is what is needed
<samueldr> might want to make it generic enough and apply it to all things out of the perl infra? https://search.nix.gsc.io/?q=pkgs.perl.libPrefix&i=nope&files=&repos=
<samueldr> and apply the same kind of fix in the perl infra?
<gchristensen> fix one, then the rest? :)
<samueldr> sure :)
<samueldr> just before we see an incomplete fix PR :)
<gchristensen> +1
<LnL> I think so, there's no perlWithPackages at the moment AFAIK
<zimbatm> it's working!
<gchristensen> wow!
<LnL> \o/
<LnL> now let's hope perl's use lib doesn't have a limit :p
<zimbatm> :p
<gchristensen> (nit: commit message is a bit out of date) looks great!
<zimbatm> who wants to take over?
<zimbatm> I need to take a bit of a break
<gchristensen> what a game of hot potato
<gchristensen> "who wants to hack on perl?" _everybody scatters_
<gchristensen> I'll take it, zimbatm ;)
<drakonis> i might pick up perl...
<drakonis> might be fun???
<zimbatm> it's not that bad
<zimbatm> coming from someone who likes bash
<zimbatm> so YMMV
<zimbatm> gchristensen: I'll finish the patch tomorrow otherwise
<samueldr> lazyweb: would it work if it was before all the use, e.g. would it change semantics if it was before use strict and use warnings?
<LnL> hmm, do we have tests for nixos-rebuild itself?
<gchristensen> probably-yes
<gchristensen> ^ samueldr
<tilpner> Should I have sent #55729 against staging?
<{^_^}> https://github.com/NixOS/nixpkgs/pull/55729 (by tilpner, 41 minutes ago, open): groff: Remove indeterminism in manpages
<gchristensen> mega yes :)
<tilpner> With all those rebuilds, nobody will merge it just to fix some indeterminism
<gchristensen> tilpner: do you know how to re-point it to staging?
<gchristensen> beyond need ing to go to staging, the diff lgtm
<tilpner> No, but I'll try anyway
<gchristensen> tilpner: here is how I do it: while on the branch, `git fetch origin; git reset --hard origin/staging; git cherry-pick a23a4b5af7608f615ef6212e106c5cc395665934; git push myfork mybranch --force`
<tilpner> Oh no
<gchristensen> uh oh
<tilpner> I trusted you :/
<gchristensen> what happened
<tilpner> I requested reviews from everyone
<gchristensen> what'd I delete
<gchristensen> oh no worries, we'll fix that shortly
<LnL> that's unavoidable
<LnL> gchristensen: oh?
<tilpner> Oh, you can do that?
<gchristensen> we'll as in, I'll, as in, I just deleted all the requseted reviews and pointed it to staging :P
<tilpner> pSub was a valid reviewer though, added by ofborg
<tilpner> And this is better, thanks :)
<gchristensen> psub will add them back :)
<gchristensen> erm, ofborg will add psub back
<LnL> it's the github codeowners that triggers everybody, maybe we could replace that at some point
<gchristensen> hmm yeah
<gchristensen> samueldr, LnL: so what are we thinking w.r.t. generalizing this solution
<samueldr> thinking I'll be looking at it in details in ~2-2½ hours?
<LnL> I like the withPackages function pattern, but that's usually a wrapper
<gchristensen> yeah
<gchristensen> we could have a little "makeIncludes" function or something
<LnL> buildPerlPackage is a thing so that could find the perl dependencies and update the bin scripts after install
<gchristensen> good thing these perl scripts aren't critical to nixos :)
<gchristensen> LnL: so we'd make a Makefile.PL for the nixos scripts, and would buildPerlPackage "just work"?
<LnL> yeah, something like that
* gchristensen reads up on Makefile.PL
kalbasit has joined #nixos-dev
kalbasit has quit [Quit: WeeChat 2.2]
kalbasit has joined #nixos-dev
kalbasit has quit [Client Quit]
yl has joined #nixos-dev
<gchristensen> that is a thing
<gchristensen> what is it o.o
<LnL> lol
<LnL> the #!$perl/bin/perl -> #!$perl/bin/perl -I $foo/lib/perl5/site_perl
<gchristensen> huh
<LnL> check perlPackages.ack, that's a buildPerlPackage without a wrapper
<LnL> anyway, I could play with it tomorrow if nobody else wants to
<LnL> the darwin shebang limit is based on the entire line not just the binary itself so it fails with "exec format error"
<gchristensen> ack has a megashebang
<LnL> yeah 662 > 512
<gchristensen> we could make a helper, `un-I` convert -I's in to use lib's
yl has quit [Quit: WeeChat 2.2]
<LnL> yes, but I would move it out of buildPerlPackage so it can also be used in other places, like makeWrapper
yl has joined #nixos-dev
<gchristensen> yeah
<gchristensen> crap, I have an obligation in a few minutes
<gchristensen> back in a couple hours
yl has quit [Client Quit]
yl has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.3]
drakonis has joined #nixos-dev
asymmetric has joined #nixos-dev
yl has quit [Ping timeout: 244 seconds]