Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use normalizedName as the default appUser for Linux Packages #144

Merged
merged 1 commit into from
Feb 1, 2014

Conversation

aparkinson
Copy link
Contributor

No description provided.

@jsuereth
Copy link
Member

jsuereth commented Feb 1, 2014

Nice! Looks good to me.

jsuereth added a commit that referenced this pull request Feb 1, 2014
Use normalizedName as the default appUser for Linux Packages
@jsuereth jsuereth merged commit 20e5aed into sbt:master Feb 1, 2014
@aparkinson aparkinson deleted the default-appUser branch February 1, 2014 20:31
@aparkinson
Copy link
Contributor Author

Great

@jsuereth and @muuki88 What is left todo for the next release?

@jsuereth
Copy link
Member

jsuereth commented Feb 1, 2014

I think just checking the server stuff against RPM practices....

@muuki88
Copy link
Contributor

muuki88 commented Feb 1, 2014

I'm trying to close some of the minor tickets (documentation stuff, error logging, etc.)
On which systems do you test RPM @jsuereth ? I may have some time to help you there.

Most of the open tickets are for rpm. I think the only critical one is #76
If we can at least specify a minimum rpm version in the docs, then we would be fine.

@jsuereth
Copy link
Member

jsuereth commented Feb 1, 2014

I usually try to make sure Latest Fedora + Latest CentOS available on EC2 work. Work beyond that can be contributed by those who use the systems and understand how to do the compatibility/fixes better than those of us who aren't users :).

If you do any work here, just remember to update the compatibility matrix :)

@muuki88
Copy link
Contributor

muuki88 commented Feb 1, 2014

Should we create a milestone on github an gather the last few tickets?

@jsuereth
Copy link
Member

jsuereth commented Feb 1, 2014

Sounds like a good plan!

Note: I'm explicitly ignoring windows server support for now. I think that'll require a full rev, and quite a bit of hackery, so let's leave that out of the next major release milestone issues.

@aparkinson
Copy link
Contributor Author

A milestone sounds like a good idea.

Perhaps cut another milestone release this week for the Debian changes?

@jsuereth
Copy link
Member

jsuereth commented Feb 1, 2014

I'll cut one right now. Should help testing the RPM support.

@muuki88
Copy link
Contributor

muuki88 commented Feb 1, 2014

Awesome. Are the docs also visible?

  • about windows: this will be really tough. Is there a way to test in server editions, if you dont have one?
  • RPM support is okay for 0.7, we should be able to do this

@jsuereth would you be able to pull some data about OS distributions of play/akka systems? May help to set the right focus.

@jsuereth
Copy link
Member

jsuereth commented Feb 1, 2014

No, haven't pushed 0.7 docs, would you like me to?

Here's the milestone for next release: https://github.com/sbt/sbt-native-packager/issues?milestone=1&state=open

  • For windows, once I have a chance to get the sbt automation up and running, we'll have something using the sbt-native-packager to create MSIs for sbt distributions. While that infrastructure may be private (to hide access to publishing credentials), I might be able to swing some kind of PR-validation hook.
  • For rpm support - it seems quite close. The only thing I want to check is how far the diff is between CentOS/Fedora/Debian in terms of supported utilities we use in SystemV. Hoping it's minimal.

I'll see if I can get us some idea of OS distributions in production. The reality is that Typesafe mostly hears from customers, which is just a fraction of the total users out there. Maybe we could push a survey to see what comes.

@aparkinson
Copy link
Contributor Author

Off the top of my head I know CentOS doesn't support start-stop-daemon but provides a daemon function as an alternate.

@jsuereth
Copy link
Member

jsuereth commented Feb 1, 2014

Oh, forgot to mention, 0.7.0-M2 should be live.

Also, we'll have to figure out how to handle the different templates for CentOS vs. Debian then...

@muuki88
Copy link
Contributor

muuki88 commented Feb 2, 2014

Docs live would be great, too :)

@aparkinson
Copy link
Contributor Author

@jsuereth Where did 0.7.0-M2 get published to? I'm having trouble locating it

@jsuereth
Copy link
Member

jsuereth commented Feb 3, 2014

SO am I. I think we have a publishing issue on bintray I need to resolve.

@aparkinson
Copy link
Contributor Author

Anything I can help with?

@muuki88
Copy link
Contributor

muuki88 commented Feb 4, 2014

Should we publish to maven-central for redundancy, too?

@jsuereth
Copy link
Member

jsuereth commented Feb 4, 2014

No. sbt plugin break maven conventions enough, that we've already had complaints. Bintray should be fine, I've raised the issue.

What we should do is open a ticket to publish to bintray directly. That way everyone would have credentials. @muuki88 @aparkinson Why don't you guys make bintray credentials now?

@jsuereth
Copy link
Member

jsuereth commented Feb 4, 2014

Also, forgot to mention we use bintray so we have a stable/friendly location for RPMs/DEBs/MSIs/ZIPs of sbt itself. Not sure you've seen this (our first client): https://github.com/sbt/sbt-launcher-package/blob/master/project/packaging.scala

includes the mechanism to directly publish to bintray

@aparkinson
Copy link
Contributor Author

I've created a bintray account, same user name as GitHub

Nice example!

@muuki88
Copy link
Contributor

muuki88 commented Feb 4, 2014

Me, too. https://bintray.com/muuki88
Oh, didnt no that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants