goldr267 was kicked from #nixos-dev by fpletz [(goldr267)]
<cbarrett>
anyone know an ircop?
<cbarrett>
should be able to instaban that phone number or URL
<fpletz>
anyone else wants op here? quite the coincidence that I was looking into weechat :)
<phreedom>
do spambots ping ops?
<phreedom>
if they don't, we should give an op to everyone :)
<contrapumpkin>
there's an ircop in ##hott looking into it now
<fpletz>
they ping everyone but messages in irc have a length limit
<contrapumpkin>
we need to distribute the ops responsibilities in #nixos better
<contrapumpkin>
a 700-member channel is an attractive target
<andi->
you can always set +S or +r to mitigate the bots.. this is happening everywhere
<fpletz>
we also have the same problem in a smaller ircnet we're running, that stuff is mostly automated and very hard to block
<contrapumpkin>
yup
<andi->
on hackint we are seeing a high amount of dnsbl hits and not so much spam so far... but yeah hard to block. freenode staff offers Sygn a spam detection bot that is opt in
<andi->
it work pretty well if you use it...
<gchristensen>
andi-: they don't like to put sygn in channels unless spam is a very regular problem
<andi->
for good reasons
<gchristensen>
indeeed, I'd be +1 on making this chan +r, I don't think they'd put sygn in a small channel like this one
<andi->
S is less intrusive unless there is a point for letting registered non-ssl people in
<fpletz>
enforcing registration with freenode to join is not nice imho
<andi->
yep
<fpletz>
and ssl is really nod needed for this channel… :/
<gchristensen>
interesting how we have the exact opposite opinion :P
<gchristensen>
that is fine, though, and spam really isn't much of an issue here usually
<fpletz>
does +s help? then the channel shouldn't be in /list
<gchristensen>
oh fancy
<andi->
I am a strong proponent of having SSL everywhere.. doesnt cost much an gives you at least transport security
<andi->
yes s should help
<fpletz>
andi-: ack, same here, but some might disagree :)
* fpletz
is running a tls-only ircnet :>
<andi->
+s is the default on ircnet for many years now... they almost never have issues with spam ;)
<fpletz>
hm, according to freenode docs +s only hides the channel from /who and /whois
jtojnar has quit [(Quit: jtojnar)]
<gchristensen>
is it possible to see the user mode of other users?
jtojnar has joined joined #nixos-dev
<andi->
fpletz: This channel will not appear on channel lists or WHO or WHOIS output unless you are on it.
<fpletz>
oops :)
<andi->
thats what the doc says for +s
<andi->
you meant 'p'?
<fpletz>
no, I meant s but overlooked 'channel lists' :)
<fpletz>
expected LIST
<andi->
k
<fpletz>
lol
<fpletz>
You have been invited to #fpletzisanigger54 by goldr267
<disasm>
I didn't get an invite to a channel, I just was given a phone number to call into and youtube live feed, lol
<contrapumpkin>
yeah I've had a bunch of those
<contrapumpkin>
maybe you get them for banning them?
<fpletz>
I haven't got anything else from them and only after the ban
<fpletz>
took them 15min though o/
<yegortimoshenko>
i should probably repost my merge access request, given the situation...
<gchristensen>
yegortimoshenko: try again in a better business-hour time for CET
<andi->
having umode +R is almost mandatory on freenode :/
<gchristensen>
classic late-90's early-2000s GNAA spam. (sighs, not out of nostalgia)
<andi->
will any of you be at 34c3?
<gchristensen>
I wish, my company only covers conferences in the US :(
<andi->
hrhr, my current employer never covered any conferences...
<gchristensen>
yeah but it costs a lot more for me to get to 34c3 than it would you :)
<andi->
yep
<andi->
i bought a train ticket for about 100 euro, both ways
Teren892 has joined joined #nixos-dev
olda313 has joined joined #nixos-dev
stqism has left #nixos-dev []
olda313 was kicked from #nixos-dev by fpletz [(Teren892)]
Teren892 was kicked from #nixos-dev by fpletz [(Teren892)]
<andi->
mlock ftw
* samueldr
sighs
<samueldr>
does freenods support blocking messages by content?
<samueldr>
→ ▄▄▄
<gchristensen>
yes
<gchristensen>
well no... it can strip color
<gchristensen>
how quick can we make a bot to detect "IS LIVE" and other key words and auto-ban
<samueldr>
depends
* gchristensen
eyes {^_^}
<andi->
gchristensen: rather easy jut teh false positives are bad... since freenode is also using atheme services having chanserv in guard mode might already do the trick since it ha some basic circular buffer spam protection
<gchristensen>
I can't turn that on
* andi-
heads to bed shocked by the advanced time...
<gchristensen>
:) good night
<fpletz>
andi-: interesting, let's try that :)
<fpletz>
gchristensen: why not?
<gchristensen>
fpletz: I don't have privs with chanserv
ChanServ has joined joined #nixos-dev
<gchristensen>
(talking #nixos)
<fpletz>
oh, okay
<fpletz>
you should have founder access here
<gchristensen>
ahh great!
<fpletz>
so let's just add more people, currently the only other people with op/founder here are globin and me :)
<samueldr>
off-topic, was there any attempt in getting botbot in other nixos-related channels?
<fpletz>
samueldr: iirc globin tried a while back
<samueldr>
if not, and I'm allowed, (in another more formal way), I could setup another irc logger bot
<jtojnar>
and now the spam is crashing my irc client
<disasm>
jtojnar: yeah, I might have to temporarily disable pushover notifications on my phone...
<disasm>
or just leave my tmux irc session open all night so it doesn't page
<disasm>
the irony of it all is I setup prometheus notifications using pushover last night. Normally I'd just ignore the pushover ring tone, but I made it something really loud and annoying to get my attention if any of my servers or router goes down
LnL has quit [(Quit: exit 1)]
LnL has joined joined #nixos-dev
<andi->
Weechat android ftw ;)
the has joined joined #nixos-dev
<gchristensen>
ok I wrote a small bot to ban if it receives _very specific_ triggere words
<samueldr>
what are those, gchristensen?
<gchristensen>
how about I pm them to you, I say, cleverly avoiding the ban words
<flokli>
yegortimoshenko: thanks for your work :-) out of interest, als you also already took a look at source-building electron: how much pain will it be to build electron-using applications from source, too?
<flokli>
thinking about signal-desktop here
<flokli>
atom editor too maybe
<yegortimoshenko>
flokli: depends on case-to-case basis. the largest problem is that many electron projects use custom build systems that have assumptions about the build context (network access, FHS). at first glance, signal-desktop looks easy, atom-editor looks bad. you might want to check rambox, it's an electron app, i've made it build from source a while ago: https://github.com/NixOS/nixpkgs/pull/31137
<flokli>
yegortimoshenko: wow, rambox seems to be a beast. but it looks like electron already gets built inside rambox-bare, right?
<yegortimoshenko>
flokli: (let's move this to #nixos, i want domenkozar to see my request above when he logs in :-)
<flokli>
yegortimoshenko: sure
__Sander__ has joined joined #nixos-dev
<domenkozar>
yegortimoshenko: hey
<domenkozar>
I'm not following nixos much atm sadly, will wait for +1 from other code members :)
<Mic92>
there maybe something like 20 packages that need to be migrated away so I can list the attributes manually, but would need something to generate the markdown.
<Mic92>
*there are
<Dezgeg>
I use 'sed'
<domenkozar>
[job spam] We're hiring again at IOHK. Would you like to work with me in 4 SRE team using Nix / AWS / Haskell and challenging growth? Remote position, preferably in EU timezones. Everything we do is open source. https://iohk.io/careers/#op-144226-devops-engineer
<Mic92>
sphalerite: ^
<sphalerite>
domenkozar: will that offer still be around in 2018Q3? :)
<domenkozar>
sphalerite: most probably :)
<yegortimoshenko>
Mic92, vcunat: if you feel like vouching for me receiving merge rights...
<vcunat>
yegortimoshenko: yes, I do think so, if you use it with care
<vcunat>
(but I don't have rights to add rights)
goibhniu has quit [(Remote host closed the connection)]
<yegortimoshenko>
vcunat: sure, it's for domenkozar. i should get approval from current members to receive merge rights.
<vcunat>
right, I just wanted to be explicit
<yegortimoshenko>
(i don't plan to write something non-trivial and merge it myself: no one does that. i've initially asked for merge rights to be able to assign myself to issues)
goibhniu has joined joined #nixos-dev
<gchristensen>
yegortimoshenko: looks like I got `the` working just in time for Freenode to finish blocking the attack
the has quit [(Remote host closed the connection)]
<gchristensen>
domenkozar: it looks like several people have vouched for yegortimoshenko now ( fpletz, vcunat )
<vcunat>
the 18.03 pair :-)
<fpletz>
:>
<gchristensen>
(... 2 doesn't make several but ...)
<fpletz>
vcunat: btw. we should go over the tickets for 18.03 soon :)
<fpletz>
and retarget most auf the 17.09 to 18.03
<yegortimoshenko>
gchristensen: also you! in that irc post above
<fpletz>
and maybe defer some to 18.09
<vcunat>
hmm, now it's about 10 weeks before branching?
<gchristensen>
omg the releases happen so fast when you're part of the team making the sausage.
<domenkozar>
gchristensen: ack
<domenkozar>
yegortimoshenko: what's your github username?
<yegortimoshenko>
domenkozar: yegortimoshenko
<domenkozar>
yegortimoshenko: invited. Please handle write access with care. And most importantly, thank you for all previous and upcoming contributions :)
<yegortimoshenko>
domenkozar: thanks!!
ma27 has quit [(Ping timeout: 240 seconds)]
<yegortimoshenko>
and thanks to everyone who has vouched for me: gchristensen, fpletz, vcunat :-)
ma27 has joined joined #nixos-dev
<gchristensen>
thank you, really, for all your work
<vcunat>
:-)
<vcunat>
(going back a little) theoretically we could make the release cycle longer or change some other aspects. I don't have much idea about such preferences in our community.
<vcunat>
I suppose they would often like a longer time of support, but might be noticeably more work.
<vcunat>
And there's the thing about dropping support for RHEL/CentOS 6 with dropping 17.09...
<vcunat>
(a bit unfortunate)
<gchristensen>
yes, I agree, but 6 is going to get support until 2020 and it'd take a miracle for us to realistically support 17.09 that long
<gchristensen>
I feel the 6mo releases are good. nixpkgs master evolves and improves quickly, and I think "most" users like being pretty up to date, but skipping the tumultuous parts of unstable
<domenkozar>
vcunat: thanks for testing multiple outputs branch!
<vcunat>
:-) I did very little for now
<gchristensen>
shlevy: ping
<gchristensen>
vcunat: my guess is that only Corps are on 6, and if Corps need Nix maybe they can step up and provide funding so we can support 17.09 longer
<vcunat>
yes, it would probably be more like making 17.09 a longterm branch and otherwise continuing the same
<gchristensen>
right
<vcunat>
or reconsider the glibc upgrade and postpone it for yet another release
<Dezgeg>
or maybe fund someone to have new glibc support old kernels
<gchristensen>
Dezgeg: do you have an idea on what that'd take?
<Dezgeg>
maybe the guix people would be interested as well
<vcunat>
or keep supporting older kernels in newer glibc :-)
<vcunat>
I have no idea which path is easier.
<Dezgeg>
not really, but I suppose most of it is just going through glibc commit logs and see what they dropped and revert those commits
<vcunat>
well, I assume they had a reason they dropped the support
<gchristensen>
I asked them, let me find the logs
<Dezgeg>
because 2.6.x dropped official kernel.org support, I think
<vcunat>
and someone not working on glibc normally might just miss an interaction between commits
<Dezgeg>
yes, that is true
<gchristensen>
azanella: gchristensen, it thinks it is doable, although it would require some work and the work is mostly 'reverting' stuff
<vcunat>
oh, I see, upstream kernel support also starts at 3.2, so it's synchronized
<Dezgeg>
also the rhel kernel might have some of the needed stuff backported from newer kernels, who knows
<vcunat>
Some users already hit it non-working.
<Dezgeg>
that's just glibc bailing out immediately after checking the kernel version
<vcunat>
Well, the easiest way should certainly be to keep nixpkgs on older glibc, as long as upstream glibc maintains those branches. The only downside would be missing some latest iprovements, though I'm not sure how bad that is ATM.
<vcunat>
Or we could make RHEL/CentOS users rebuild everything :-)
<gchristensen>
we should pay attention to which glibc's are supported and receive security patches
<gchristensen>
also since I'm affected by this, I'm biased here, so remember that when I like an idea :)
<vcunat>
I've seen no claims about guarantees there
<vcunat>
they just do maintain some of them now
<vcunat>
because they have to anyway for some distros IIRC
<vcunat>
glibc should be very good with ABI compatibility. It might be worthwhile to build against older glibc and replace it to newer during runtime (if desired). I'm only afraid to complicate stuff around patchelfing, cross-compiling, etc.
<vcunat>
On the whole, there are many possible approaches, but I can't see any "clear winner".
<gchristensen>
re build-and-swap ... I wouldn't put that in nixpkgs, that seems crazy complicated just to support a 17 year old distro
yegortimoshenko has quit [(Remote host closed the connection)]
orivej has joined joined #nixos-dev
goibhniu has quit [(Ping timeout: 252 seconds)]
goibhniu has joined joined #nixos-dev
orivej has quit [(Ping timeout: 256 seconds)]
orivej has joined joined #nixos-dev
<vcunat>
it "only" seven, not -teen (November 10, 2010)
<vcunat>
(but I must say way gladly dropped support for it at work nevertheless)
* __Sander__
did not know these glibc guys were so helpful :)
<__Sander__>
I'm more used to "you don't pay me" answers :)
<vcunat>
:-) a different approach to "open-source"
<vcunat>
I've heard that the RHEL kernels don't really have much in common with the original upstream kernel :-)
<gchristensen>
how do I do the verify step?
<vcunat>
verify those files exist
<vcunat>
I believe it's about adding them as an interface to userspace.
<gchristensen>
ah
<gchristensen>
"verify /proc/$pid/task/$tid/comm on a running instance" that exists where pid == pid
<gchristensen>
"verify /proc/$pid/task/$tid/comm on a running instance" that exists where pid == tid
ma27 has quit [(Ping timeout: 272 seconds)]
<domenkozar>
niksnut: would you be opposed of adding unzip (0.5MB) to nix closure?
<domenkozar>
to support nix-prefetch-url --unpack
<gchristensen>
it seems semi-reasonable to expect people to add unzip as needed
<domenkozar>
gchristensen: to optimise for 0.5MB or for some other reason?
<gchristensen>
something something slippery slope I guess :P
<niksnut>
software gets bloated 0.5 MB at a time
<domenkozar>
I helped remove 50MB of perl, so that I can add 0.5MB :P
<niksnut>
hehe
<domenkozar>
well I get your point :)
<niksnut>
we need all that space for when we add git as a dependency :p
<Dezgeg>
git brings perl back :P
<domenkozar>
aaa
* gchristensen
facepalms
<niksnut>
doh
<domenkozar>
so maybe we should just fix runProgram function in Nix
<domenkozar>
to instruct what attribute to use if program is missing
<shlevy>
gchristensen: pong
<niksnut>
domenkozar: hm, that might not actually be a bad idea for builtins
<shlevy>
domenkozar: +1million
<shlevy>
Or the builtins in question could just take an extra argument, defaulting to the builtin programs but with a nice error when they're not available
<contrapumpkin>
niksnut: you see that issue I linked to earlier? I think you closed it prematurely
<copumpkin>
--numeric-owner now affects private headers too.
<copumpkin>
that's the one I care about, since without it I can't make deterministic tarballs of nixpkgs :)
<copumpkin>
I'm doing an ugly local gnutar patch for my builder
<copumpkin>
but it's awkward
<copumpkin>
anyway, I'm fine if you all don't think it's worth it
<copumpkin>
but I figured I'd ask
<orivej>
I'd prefer the next staging rebuild to be relatively small to be merged to master possibly tomorrow
<copumpkin>
we need a staging-staging!
<copumpkin>
:P
<copumpkin>
anyway, it sounds like y'all aren't very enthusiastic :) I can just make a PR against staging and you can merge it when you feel comfortable
<gchristensen>
copumpkin: or some sort of automatic tendering of staging, say bors or whatever
<copumpkin>
yeah that'd be nice :)
<copumpkin>
we don't always have to merge head of staging to master
infinisil has quit [(Ping timeout: 264 seconds)]
<orivej>
yes, but we need additional fixes in staging before it could be merged to master
yegortimoshenko has joined joined #nixos-dev
<copumpkin>
I'm just going to make a PR to staging
<copumpkin>
we can decide when I submit it when to merge and whether 17.09 should get it
__Sander__ has quit [(Quit: Konversation terminated!)]
infinisil has joined joined #nixos-dev
infinisil has quit [(Client Quit)]
infinisil has joined joined #nixos-dev
goibhniu has quit [(Ping timeout: 248 seconds)]
<yegortimoshenko>
what is the deadline for getting changes into 17.09?
<peti>
yegortimoshenko: Sep 30th, 2017.
<yegortimoshenko>
peti: oh, i'm sorry. i meant the upcoming release, 18.03.
ma27 has quit [(Ping timeout: 265 seconds)]
<vcunat>
Sonarpulse: (staging merge) yes, I wanted to merge this morning, but saw that PR... otherwise I'll merge
ma27 has joined joined #nixos-dev
<Sonarpulse>
vcunat: the copumpkin one you mean?
<gchristensen>
yegortimoshenko: please get PRs in as soon as possible, there is a big crunch in the 2-3 weeks leading up to a release of PRs and it becomes hard to manage them. if you can get PRs in early, it makes the release managers happier :0
<vcunat>
> (04:47:21 PM) Sonarpulse: anyone have a rough idea when staging will next be merged?
<yegortimoshenko>
vcunat: that glibc linking issue is highly untrivial... (NIX_LD_LIBRARY_PATH)
<Sonarpulse>
vcunat: i mean the pr in "but saw that PR..."
<yegortimoshenko>
gchristensen: i'll try!
<Sonarpulse>
but saw my pr, so didn't merge yet? saw copumpkin's just-opened PR?
<Sonarpulse>
also, is the 18.03 fork/feature freeze date set?
<vcunat>
Sonarpulse: the libva PR
<Sonarpulse>
oh right, that one
<vcunat>
that's one regression I saw
<vcunat>
the remaining couple of failures seemed random/unimportant
<vcunat>
I plan to just merge the PR and staging to master tomorrow
<vcunat>
(wanted just to give a bit time for reaction around the PR)
<vcunat>
yegortimoshenko: yes, the whole non-NixOS and other impurities are problematic
<vcunat>
for libGL I hope for libcapsule+glvnd
<yegortimoshenko>
also, does anyone mind if i add 6.topic: xfce label? there are quite a few xfce issues in the backlog and searching for them manually is getting out of hand
<yegortimoshenko>
vcunat: i don't understand why just libglvnd doesn't solve the issue
<vcunat>
but there are also other kinds of wrappers than libGL, and they propagate to spawned processes...
<vcunat>
yegortimoshenko: I think it does resolve the part that would be handled by NIX_LD_LIBRARY_PATH
<vcunat>
but there are other parts
<yegortimoshenko>
it is supposed to dynamically dispatch gl calls to actual drivers at runtime
<vcunat>
like some libGL implementations depend on libstdc++, libwayland, etc.
<vcunat>
and they are impure
<vcunat>
so you actually attempt to load two different versions of libs at once into the same namespace
<vcunat>
(in some configurations)
<vcunat>
one of them wins and overrides the other use cases
<vcunat>
libcapsule might be a way of putting _both_ inside, due to having libGL in a different link namespace (kind of)
<yegortimoshenko>
libglvnd allows to use two libGLs from different vendors at the same time, provided they don't share one X screen
<yegortimoshenko>
libGL implementation might just be part of system profile, while apps link to libglvnd
<vcunat>
yes... but it won't allow a new libGL (using a new libwayland) to be used in older binary that was built against a newer libwayland
<vcunat>
(if the two libwayland versions differ significantly enough, you may get loader errors)
<yegortimoshenko>
i see.
pie_ has quit [(Remote host closed the connection)]
pie_ has joined joined #nixos-dev
<Sonarpulse>
vcunat: that's for the info
<copumpkin>
anyone have thoughts on my gnutar PR?
<copumpkin>
:) :) :)
<vcunat>
yegortimoshenko: thinking of 18.03 feature plans - if libcapsule is unlikely to make it (maybe Dezgeg has an idea if it is), and adding yet another patch with new env-var into glibc is controversial, we might just try to have libglvnd resolve the part of requiring LD_LIBRARY_PATH for libGL - and significantly reducing that part of the problem. (Without affecting problems with clashes of different versions.)
<vcunat>
but I'm surely missing some things
<vcunat>
actually for binary packages (e.g. steam) this won't help and we do need a way to override libGL anyway, right?
<yegortimoshenko>
vcunat: i think new env-var would have to be merged anyway
<yegortimoshenko>
or at least, users complain daily about certain games not running w/o patching
<vcunat>
well, but the binary games... they won't react to NIX_LD_LIBRARY_PATH, will they?
<yegortimoshenko>
they will, they have to go through ld.so anyway
<vcunat>
ah, I see
<vcunat>
I'm not thinking clearly today anymore.
infinisil has quit [(Quit: ZNC 1.6.5 - http://znc.in)]
<bgamari>
Sonarpulse, I think either there is a bug in the handling of nativeBuildInputs or I'm misunderstanding something
<Sonarpulse>
bgamari: hmm
<bgamari>
Sonarpulse, I'm having trouble building texinfo
<bgamari>
ncurses is in nativeBuildInputs
<Sonarpulse>
ok
<yegortimoshenko>
i'm not sure why NIX_LD_LIBRARY_PATH is controversial: it is not public API so we can drop it at any point
<bgamari>
yet the configure script is not finding the library
<yegortimoshenko>
it's practical :-)
<Sonarpulse>
bgamari: that makes sense to me?
<Sonarpulse>
or is this just used at compile time?
<bgamari>
it's used at compile-time
<Sonarpulse>
and it should be looking for the library with CC_FOR_BUILD?
<bgamari>
it's using CC_FOR_BUILD
<Sonarpulse>
hmm
<Sonarpulse>
did $CC_FOR_BUILD -lncurses or whatever work in shell?
<Sonarpulse>
hopefully the configure script isn't broken and doesn't know how to search for libraries with CC_FOR_BUILD
<bgamari>
/nix/store/5nynvl9br902rqi2wkzvy7m62xz5b4pp-binutils-2.28.1/bin/ld: skipping incompatible /nix/store/8z1rrvr9i0sjxbby4yhm7jh4myirqycp-ncurses-6.0-20171125-armv7l-unknown-linux-gnueabihf/lib/libncurses.so when searching for -lncurses
<bgamari>
/nix/store/5nynvl9br902rqi2wkzvy7m62xz5b4pp-binutils-2.28.1/bin/ld: skipping incompatible /nix/store/8z1rrvr9i0sjxbby4yhm7jh4myirqycp-ncurses-6.0-20171125-armv7l-unknown-linux-gnueabihf/lib/libncurses.so when searching for -lncurses
<gchristensen>
copumpkin: hmm merge 17.09 in to staging and call eval again
<gchristensen>
(in to staging-17.09)
<gchristensen>
copumpkin: also could you open an issue on ofborg to continue checking even if the target branch is broken? that way we can tell if a PR fixes a broken target branch
goibhniu has quit [(Ping timeout: 256 seconds)]
infinisil has quit [(Ping timeout: 248 seconds)]
<pbogdan>
gchristensen: copumpkin: is there even a hydra jobset for staging-17.09?
infinisil has joined joined #nixos-dev
<vcunat>
I don't think we've used 17.09-staging since we finished Zero-Hydra-Failures for 17.09
vcunat has quit [(Quit: Leaving.)]
<copumpkin>
ah
<copumpkin>
maybe I should just use release-17.09 then?
<orivej>
copumpkin: yes
<orivej>
it is going to be merged, and I don't expect anything bad from merging it to release-17.09 before staging, but I also don't want to break the rule that changes to release should go through master
<orivej>
and congratulations for upstreaming a patch to tar!
<copumpkin>
hah I didn't actually submit the patch :) I just reported the bug
<copumpkin>
turned out wkennington had fixed it in triton a few months earlier but hadn't reported upstream
<copumpkin>
anyway, I'll switch the base branch
<copumpkin>
fixed :) thanks
<copumpkin>
also quite excited to get this into 17.09, since that'll supposedly be the base of the upcoming Nix 1.12 release and I want Mac builds of a recent gnutar by default
<copumpkin>
(for selfish reasons)
<Sonarpulse>
ah triton
<Sonarpulse>
I am reminded I opened a cross issue there
<Sonarpulse>
on some sort of dialogue
<orivej>
yeah, they did not respond
<Sonarpulse>
i'd think running your own nixpkgs with ~2 people would suck
<Sonarpulse>
but *shrug8
<Sonarpulse>
if they like the work
<copumpkin>
they're more active than we are :D
<copumpkin>
at some point I'd expect them to get tired of it though
<orivej>
did they ever announce or explain the split from nixpkgs?
<Sonarpulse>
there's an old document there
<Sonarpulse>
but nixpkgs is increasingly well run
* Sonarpulse
thanks you all
pie_ has quit [(Ping timeout: 248 seconds)]
infinisil has quit [(Quit: ZNC 1.6.5 - http://znc.in)]
infinisil has joined joined #nixos-dev
<orivej>
BTW I tried using Nix 1.12 on the weekend, switched my computer and all build machines to 1.12 so that none would be on 1.11. After the switch I was getting "Unexpected EOF reading a line" building some packages and not others. I could not formulate the conditions of such errors, and opened only one issue: https://github.com/NixOS/nix/issues/1740 . It is tangential to the main inconvenience, but at least it's definite.
<Sonarpulse>
orivej: bummer
<bgamari>
How are packages like w3m which want to write to ~/ supposed to be used in a builder?
<orivej>
export HOME=$TMPDIR
<bgamari>
I see
jtojnar has quit [(Read error: Connection reset by peer)]
jtojnar has joined joined #nixos-dev
<orivej>
Sonarpulse: could you fix building perlPackages.EncodeDetect on staging? it is related to gcc changes (the error is "cannot find -lstdc++")
<orivej>
(it is a dependency of spamassassin)
<Sonarpulse>
orivej: sure
<Sonarpulse>
sorry I didn't figure out the other CL one yet
<orivej>
in the worst case we could fix CL after the merge to master