<gchristensen>
bgamari: I've been needing to do some pretty high-prio here in my home, and I'm hoping I'll be around here in like an hour or so ... but then again, this disposal project was supposed to be 1h and not like 3h
<{^_^}>
#82827 (by danderson, 4 days ago, open): tailscale: init at 0.97-0 [20.03 backport]
<colemickens>
why "0.97-0" ?
<colemickens>
and why not the tagged git rev in fetchFromGitHub?
<danderson>
0.97-0 because that's Tailscale's versioning scheme (based on `git describe`
<danderson>
and specific rev because the versioning scheme is currently brokenly based on the `git describe` output of our corp (non-OSS) repo, which has the OSS repo as a submodule.
<danderson>
so that rev is "the rev that the corp repo had as a submodule when we tagged 0.97-0"
<danderson>
High on my todo is "redo all our versioning crap so that this isn't necessary any more", but yay young company with infinite todo lists :/
<Profpatsch>
danderson: sounds like you want to have this outside of nixpkgs as long as nobody is using it?
<danderson>
that sounds like circular reasoning. Nobody's using it because it's not in nixpkgs, and it's not in nixpkgs because nobody is using it.
<danderson>
I'm not packaging it for fun, I want to deploy it to prod, along with others :)
<Profpatsch>
Well, that does not mean it has to be in nixpkgs first
<Profpatsch>
Or backported to 20.03
__monty__ has quit [Quit: leaving]
<danderson>
That doesn't scan. Not being in nixpkgs, given the current state of the nix world, means it doesn't exist.
<danderson>
if it were less difficult to combine 3p channels, I might agree. But what you're saying is "I don't want this in nix"
<Profpatsch>
danderson: there’s a v0.97 release in the repo
<Profpatsch>
danderson: Well, I don’t know if *I* want it, but it sounds like you just want it because you need to deploy stuff from some company-specific branch.
<Profpatsch>
If you use the git release tag instead I don’t think anybody has anything against tailscale being in nixpkgs.
<danderson>
no. I want it so I can install it on my personal servers. Indirectly I also want to get tailscale-the-company running nixos in prod, for which this is a hard prereq
<danderson>
but my current motivation is "I want to use tailscale personally, and I can't right now"
<Profpatsch>
danderson: Why not submit the nix file to the tailscale repo then?
<danderson>
okay, sure. It happens that the current tags produce the same answer
<danderson>
because that doesn't let me document that tailscale works on nixos. It lets me document that I use it on nixos, and you're welcome to hack up your own distro to make it work as well. Feels as if I said "we support Debian! Here's a source tarball, build and install it yourself."
<Profpatsch>
But it doesn’t hinder you to use it personally.
<danderson>
so what's the point of nixpkgs then? Everyone can just write their own derivations for everything. nixpkgs is a waste of storage and compute, right?
<colemickens>
I don't know that I'd use it, but as a potential user, I want tailscale in nixpkgs too...
<Profpatsch>
danderson: I guess what I’m trying to say is: it’s fine if you use the official release tag.
<Profpatsch>
Other than that the package looks fine.
<danderson>
sure, I'll update it then. It's a no-op except for changing a bunch of hashes, but if that's what it takes, sure.
<colemickens>
You shouldn't need to change hashes though
<danderson>
fetchFromGithub's hash depends on its inputs as well, no?
<Profpatsch>
danderson: Usually it’s totally fine if it’s an official release, but your answer to colemickens’ question sounded strange and you got pretty aggressive, which is usually a bad sign.
* colemickens
didn't take it as aggressive
Cale has quit [Remote host closed the connection]
* colemickens
also didn't fully grok the answer, but accepted it as "reasons, it will get better with time"
<danderson>
Sorry. I'm getting frustrated that what feels like a very straightforward task has taken a week so far.
<Profpatsch>
danderson: you mean that the PR is 5 days old?
<danderson>
Especially when any change results in an extra 2-3 days minimum of turnaround. It frankly makes me want to stop bothering with nixpkgs at all.
<danderson>
but, I shall enhance my calm, and continue.
<Profpatsch>
danderson: It shouldn’t be a blocker, because you can always use the branch with the patch, no?
<danderson>
Profpatsch: well, that and that if I hadn't poked here, I expected another week or two of inactivity at least.
<danderson>
which leaves me with either "be rude and poke IRC for my pet projects", or "carry a bag of open PRs for weeks at a time"
Cale has joined #nixos-dev
<Profpatsch>
A bit of poking is usually required, because people only have so much time.
<danderson>
(or "give up on nix and go use something else", which gets tempting in dark moments, admittedly.)
<{^_^}>
#79705 (by Profpatsch, 5 weeks ago, open): skawarePackages: support static builds via pkgsStatic
<simpson>
danderson: nixpkgs is an *upstream*. It is a destination for derivations. It is a place where code is shared. It is a commons. Carrying a bag of open PRs is the way this sort of thing goes; you'd have to maintain private packages and descriptions on Debian or Fedora or etc., I think, too.
<Profpatsch>
But that’s not a problem, because it’s going to go in eventually.
<cole-h>
Maybe it's just me, but I don't see poking on IRC as rude, unless you're pinging specific people completely unrelated to that PR
<danderson>
simpson: the difference, from where I'm sitting, is that those other distros have healthy mechanisms in place for 3rd party sources. I don't personally see nix on that level. I'm told it's a WIP though.
<simpson>
I *still* have dozens of patches that aren't upstream. I haven't even PR'd some of them.
<Profpatsch>
Since nix give you the ability to continue working with your changes even if upstream hasn’t added them yet, I’m not fazed by it
<colemickens>
I left and came back when I realized carrying patches was better than going back to... I don't even know what. But my needs are different and I don't try to use stable nixpkgs.
<colemickens>
:( As a maintainer of an overlay, I'd like to think it's not too hard for users to use the packages I package there.
<Profpatsch>
When we work with GHC at work and need a new feature, the scope is usually 2 releases, which is half a year until we can depend on these changes in the wild.
<simpson>
The Cachix service demonstrates that PPA-like delivery options are viable. There is the "flakes" feature, which continues to be developed but IIUC isn't yet production-ready. It really depends on who you're delivering to.
<Profpatsch>
But there’s enough work queued up usually that it doesn’t matter
bhipple has quit [Ping timeout: 250 seconds]
<danderson>
Seems like we're disagreeing on how easy it should be to use NixOS. The bar you're setting is "become proficient in Nix, maintain your own forks of nigpkgs in perpetuity, and that's fine".
<Profpatsch>
danderson: well, using overlays is not what I’d consider a very advanced topic.
<danderson>
I agree that once flakes et al. become more widespread, that makes it easier to carry things outside of nixpkgs long-term.
<samueldr>
but I started using NixOS as it was a new feature
<Profpatsch>
Doesn’t depend on flakes tho
<samueldr>
it wasn't trivial to get started
<samueldr>
(my main issue at that time was with lack of example usage, and being a general nix novice)
<simpson>
I disagree that this is mere "use". This is the bar for contributors, and it's *lower* IMO than for Debian or Gentoo, which both require proficiency, forks, *and* other stuff.
<abathur>
hmm
<simpson>
I understand the frustrations here. It's sensible to be irritated. Heck, the bot even says "sorry" as its first bit of its PR advice spiel.
<danderson>
simpson: how do you arrive at that? I'm trying to get to the point where I can document on tailscale's website that "yes, you can use tailscale on NixOS".
<danderson>
I'm willing to put up with some pain and slowness to get to that point. What's jarring to me is that I'm hearing "no, you should just make those people use overlays"
<danderson>
which will work fine for veteran NixOS users, but will just result in "WTF" questions from most people
<Profpatsch>
danderson: On Debian you need a trustee to act a guarantor if you want to add a new package. I don’t think we are quite on the same level of bar.
<gchristensen>
personally, I'd like to see that merge
<simpson>
Well, how does your packaging effort go with other distros? Do you have a Debian Developer on staff, for example?
<danderson>
Agreed. On the other hand, shipping tailscale in Arch took me 30 minutes to build and push an AUR package.
<Profpatsch>
Plus I’m pretty sure you wouldn’t be able to backport *any* new package
<danderson>
simpson: on .deb and .rpm based distros, we ship a third-party repo. There are well-supported mechanisms in the distro to enable that, and it's a well-understood pattern by the consumers of the distro
<Profpatsch>
Nix has NIR for that
<Profpatsch>
*NUR
Cale has quit [Remote host closed the connection]
<Profpatsch>
simpson: cachix is only a caching layer, not comparable to AUR imho
<gchristensen>
I would like to see this merge because I think it would be very good for NixOS to be on TailScale's website, especially since neither the package nor module is complicated
<danderson>
look at the installation instructions for NUR. If I tell a customer to set that up, they'll laugh at me.
<Profpatsch>
danderson: in .nix based distros, we ship overlays. There are well-supported mechanisms in the distro to enable that and it is a well-understood pattern. Sorry
<danderson>
I think that's where flakes would help a bunch
<colemickens>
I don't think overlays are well documented and there are too many gotchas when using them due to {everything that flakes tries to address}
<colemickens>
I've been using them, I maintain one, and I still had a case pointed out to me last night where I could introduce accidental variance into my builds due to how I'd configured my system overlays vs user overlays that hadn't explicitly occured to me previously.
<colemickens>
"I dont' think overlays are well documented [for end users]"
<Profpatsch>
danderson: So the use-case is customers?
<simpson>
Profpatsch: Customers who enable AUR by default~!
<simpson>
(I *do* agree with every point made, FWIW. I just have zero power to actually move this PR along, although I wish I could.)
<danderson>
for Arch, the target is desktop end-users. I'm okay requiring them to use AUR.
<Profpatsch>
simpson: hm, you don’t have merge capabilities?
<danderson>
For NixOS, the target is production use. I want to push the narrative that NixOS is a good way for smaller outfits to manage production than other options out there (e.g. ubuntu + chef)
<Profpatsch>
ftr, I think apart from the version ref this PR is perfectly fine.
<simpson>
Profpatsch: I don't have any powers, and that's probably for the best. I can read a bunch of languages, if folks have PRs that need non-trivial review.
<danderson>
part of how I want to push that narrative, is by getting tailscale-the-company onto NixOS in prod. And then making it easy to use our product in the same way.
<danderson>
For "getting us onto NixOS in prod", I can absolutely hack stuff up privately and beat it into shape. For the second part, I need something more polished so I can say "you should use NixOS in prod" with a straight face
<danderson>
And, it being capitalism on all that, we're not going to tell our customers to use an OS where it's hard to use our product :)
<Profpatsch>
danderson: It sounds like in that case you want to have an existing nixpkgs maintainer with merge capabilities as a steward, so that future updates of the package can be merged in a reasonable timeframe.
<danderson>
so, that's my long-term goal. Short-term, I want to install tailscale on my personal NixOS servers, and wanted to do it "right" by improving nixpkgs, rather than carry a private fork.
<gchristensen>
at least, until the package maintainer authority PR merges
<Profpatsch>
Maybe colemickens is interested in helping out there.
<danderson>
(similar to how I'm also trying to comb through the security bug backlog, because I don't want to have to explain to my boss why there's a bunch of open CVE bugs)
* colemickens
has no authority/permissions either; likely appropriately so
<cole-h>
gchristensen: First I'm hearing of that (which shouldn't be shocking considering I'm new by ~3 weeks). Got a link?
<gchristensen>
danderson: I'd be your steward :P
<danderson>
Profpatsch: so, my problem there is, there's no guidance on any of this. I'd certainly like a merge buddy to move things along (and not just for tailscale - I have a nixpkgs contrib todolist that's 2 pages long at this point)
<gchristensen>
+1
<danderson>
gchristensen: well, I'm certainly sold :). How does this work then? Do I cc and pester you on PRs?
<danderson>
because that sounds like a raw deal for you.
<gchristensen>
let's chat after I eat dinner :P
<aanderse>
danderson: any time nix gets better we all have a good deal, don't feel bad for gchristensen ;-)
<Profpatsch>
gchristensen: It sounds like we should have a team that people can @ if they are new and don’t have any contacts or maintainers they can ping?
<Profpatsch>
@mentors?
<aanderse>
Profpatsch: i love when new people annoy anyone they can until they get stuff merged :-) but the problem is who to annoy. so yes... good idea with @mentors!
<samueldr>
I learned recently that maybe teams cannot be pinged without being part of the orga
<samueldr>
if so, we're back at square one :/
<cole-h>
More features for ofborg
<cole-h>
Ping @mentors when somebody submits their first PR
<MichaelRaskin>
Just when ofborg stopped commenting
<cole-h>
:D
<danderson>
I hate pinging people without a known process for doing so, fwiw. Because I see 1800+ open PRs, and I'm sure people have other things to do.
<danderson>
so having a way for committers to volunteer "yes, please ping me for stuff" would be good.
<MichaelRaskin>
Re: process — there is an attempt to establish a cleaner process for deciding when to give people commit rights… and this attempt is still a mess
v0|d has joined #nixos-dev
<aanderse>
danderson: ping until they get annoyed and tell you to stop ;-)
Cale has joined #nixos-dev
justanotheruser has quit [Ping timeout: 250 seconds]
aszlig has quit [Quit: Kerneling down for reboot NOW.]
<bhipple>
There are threads on discourse for PRs needing review/approval/merge/etc. that you can use as well