I am trying to package the following from github for fedora. (Actually, I have been using my own RPM for years so it is hopefully not a major task).
https://github.com/maitra/thaali
Anyway, I wanted to ask how I should put the Source code from there The source is at: https://github.com/maitra/thaali/archive/master.zip
but that does not give me the version, etc number to build from the spec file.
So, what should I do? Thanks again!
You can set the name of the file via the GitHub API when you download it.
For jQuery (packaged as js-jquery), I use: https://github.com/jquery/jquery/archive/%%7Bversion%7D/jquery-%%7Bversion%7...
This will work for any GitHub project which tags released versions: https://github.com/<user-or-group>/<repo>/archive/<tag-commit-or-branch>/<preferred-file-name>.tar.gz <https://github.com/<user-or-group>/<repo>/archive/<tagName>/<preferred-file-name>.tar.gz>
For yours: https://github.com/maitra/thaali/archive/master/<preferred-file-name>.tar.gz
But, you shouldn't use "master". You should be more specific about which commit you are using, for reproducibility: https://github.com/maitra/thaali/archive/7452ae99fe01e7cea6b70881c486775cd1b...<preferred-file-name>.tar.gz
Some projects do something like: %global commit 7452ae99fe01e7cea6b70881c486775cd1b32186 %global shortcommit %(c=%{commit}; echo ${c:0:7}) ... Source0: https://github.com/maitra/thaali/archive/%%7Bcommit%7D/%%7Bname%7D-%%7Bcommi... ... %prep %setup -qn %{name}-%{commit} ...
Hope that helps.
On Sun, Apr 23, 2017 at 11:38 AM Globe Trotter itsme_410@yahoo.com wrote:
I am trying to package the following from github for fedora. (Actually, I have been using my own RPM for years so it is hopefully not a major task).
https://github.com/maitra/thaali
Anyway, I wanted to ask how I should put the Source code from there
The source is at: https://github.com/maitra/thaali/archive/master.zip
but that does not give me the version, etc number to build from the spec file.
So, what should I do?
Thanks again! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
23.04.2017 19:23 Christopher ctubbsii@fedoraproject.org wrote:
You can set the name of the file via the GitHub API when you download it.
For jQuery (packaged as js-jquery), I use: https://github.com/jquery/jquery/archive/%%7Bversion%7D/jquery-%%7Bversion%7...
This will work for any GitHub project which tags released versions:
https://github.com/<user-or-group>/<repo>/archive/<tag-commit-or-branch>/<preferred-file-name>.tar.gz [...]
I'm afraid this will not work because (according to the GitHub repo) this project has 0 release tags. Also the archive has been created only 23 days ago. Isn't it too early to package a project which has not yet ever been released upstream?
Also:
[...] On Sun, Apr 23, 2017 at 11:38 AM Globe Trotter <itsme_410@yahoo.com mailto:itsme_410@yahoo.com > wrote:
I am trying to package the following from github for fedora. (Actually, I have been using my own RPM for years so it is hopefully not a major task).
If you say you have been using your own RPM file for this project for years then maybe the project is not as young as this GitHub repo suggests? Maybe it's just been imported incorrectly, without the full history and tags, maybe it has another proper source repo which should be used instead?
Regards,
Rafal
On Mon, Apr 24, 2017 at 7:47 PM Rafal Luzynski < digitalfreak@lingonborough.com> wrote:
23.04.2017 19:23 Christopher ctubbsii@fedoraproject.org wrote:
You can set the name of the file via the GitHub API when you download
it.
For jQuery (packaged as js-jquery), I use:
https://github.com/jquery/jquery/archive/%%7Bversion%7D/jquery-%%7Bversion%7...
This will work for any GitHub project which tags released versions:
<user-or-group>/<repo>/archive/<tag-commit-or-branch>/<preferred-file-name>.tar.gz
[...]
I'm afraid this will not work because (according to the GitHub repo) this project has 0 release tags. Also the archive has been created only 23 days ago. Isn't it too early to package a project which has not yet ever been released upstream?
This also works for branch names, and commits, not just tags, as my later examples showed.
Whether or not it's too early to package... that probably depends on the nature of the software. Some projects work well with continuous delivery, but others (for example, those with well-defined, evolving APIs), it's probably better to wait on a release. You may be able to encourage the upstream project to create releases, if they know there's a downstream demand for them.
There's probably a wiki somewhere which explains how to do versioning in Fedora for continuous delivery projects, but I can't find it right now. It's probably something like: Version: %{oneUpCounter}-%{shortcommit} where oneUpCounter is incremented every time you update the package to a newer commit. An alternative might be date-based: Version: 20170424-%{shortcommit} I'm not sure which would be preferred in Fedora. Hopefully somebody can link to some Wiki guidance. (Of course, in either case, you'll probably end up having to bump the epoch if the project ever does start doing versioned releases.)
On Mon, Apr 24, 2017 at 7:39 PM, Rafal Luzynski digitalfreak@lingonborough.com wrote:
23.04.2017 19:23 Christopher ctubbsii@fedoraproject.org wrote:
You can set the name of the file via the GitHub API when you download it.
For jQuery (packaged as js-jquery), I use: https://github.com/jquery/jquery/archive/%%7Bversion%7D/jquery-%%7Bversion%7...
This will work for any GitHub project which tags released versions:
https://github.com/<user-or-group>/<repo>/archive/<tag-commit-or-branch>/<preferred-file-name>.tar.gz [...]
I'm afraid this will not work because (according to the GitHub repo) this project has 0 release tags. Also the archive has been created only 23 days ago. Isn't it too early to package a project which has not yet ever been released upstream?
Been there, done that. It assumes that other people are following your own model of how source control or product releases work.
Also:
[...] On Sun, Apr 23, 2017 at 11:38 AM Globe Trotter <itsme_410@yahoo.com mailto:itsme_410@yahoo.com > wrote:
I am trying to package the following from github for fedora. (Actually, I have been using my own RPM for years so it is hopefully not a major task).
If you say you have been using your own RPM file for this project for years then maybe the project is not as young as this GitHub repo suggests? Maybe it's just been imported incorrectly, without the full history and tags, maybe it has another proper source repo which should be used instead?
I could believe there's another repo for source code. I personally run into this all the time with python and various small perl and java tools.
I'll note that it is not "incorrect" to import a project without full history and logs. True, it discards history. But when the history has been in a source control system that does not allow discarding *anything*, much like Subversion tries, it's quite common to create a new git repo with an export and import operation and discard confusing or even copyright violating or internal security burdened content wholesale. And if the link to the old repository is deliberately broke, it massively reduces the risks of accidentally re-importing bulky or inappropriate old material to the new repository.
Again, been there, done that.
Regards,
Rafal _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Hi,
I'm afraid this will not work because (according to the GitHub repo) this project has 0 release tags. Also the archive has been created only 23 days ago. Isn't it too early to package a project which has not yet ever been released upstream?
I am also upstream. I have been using the software and my own rpm for at least five years and there has not been a crash. I have also got the software itself checked with valgrind so I am quite confident about the stability of the software. Of course, one could always have enhancements which Is why I put the software up.
However, if there is going to be an issue with getting it accepted in Fedora because it has not been around for a while and because it is likely hardly used by people (because it is at best for WM environments), then I don't know if I should even proceed.
Ideally, of course, it appears that the best course would be to version the software in github itself. I have to figure out how to do this, and would appreciate any pointers in this regard. I only know very basic commands in git. Thank you again!Best wishes.
25.04.2017 06:16 Globe Trotter itsme_410@yahoo.com wrote:
[...] However, if there is going to be an issue with getting it accepted in Fedora because it has not been around for a while and because it is likely hardly used by people (because it is at best for WM environments), then I don't know if I should even proceed.
No, I misunderstood the history of the project because the GitHub repo says it's been created 23 days ago and has no releases so far. Having read your more explanations I think it's probably only a matter of some technical rework.
The project may not be accepted in Fedora because of the legal reasons. Otherwise I may be wrong but I don't think there is any threshold of minimum days since being started, minimum number of users etc.
Ideally, of course, it appears that the best course would be to version the software in github itself. I have to figure out how to do this, and would appreciate any pointers in this regard. I only know very basic commands in git.
You should choose what is your preferred releasing model and your spec file must be adapted to the source repo. It's easier for you because you work on both sides.
I also consider myself as the beginner in git but here are some links I think may be useful:
* If you'd like to import your project to GitHub again, now with whole history:
https://help.github.com/articles/importing-a-repository-with-github-importer...
* About releases in GitHub:
https://help.github.com/articles/about-releases/
Also click in this page: Working With Tags and Creating Releases
* Linking to releases - this will be useful when you will access your release source code from the spec file:
https://help.github.com/articles/linking-to-releases/
* I also recommend reading About branches. When making a release you should create a release branch which will not be updated unless you find a bug in an old release and want to make a bugfix release. Normally your current work should be pushed to master:
https://help.github.com/articles/about-branches/
I hope this helps.
Regards,
Rafal
On Tue, Apr 25, 2017 at 12:21 AM Globe Trotter itsme_410@yahoo.com wrote:
Ideally, of course, it appears that the best course would be to version the software in github itself. I have to figure out how to do this, and would appreciate any pointers in this regard. I only know very basic commands in git.
Here's some git tips for creating release tags to help you get started:
# list current (local) tags git tag # create a tag with a message git tag mySoftware-1.0.0 origin/master -m "Official release of mySoftware 1.0.0" # list tags and see newest tag git tag # view tag's message git show mySoftware-1.0.0 # delete tag git tag -d mySoftware-1.0.0 # notice tag was deleted git tag # see what would happen if you tried to push your tags to the remote git push --tags origin --dry-run # see more information in the docs git help tag
Consider always using `-m` to provide a message describing what the tag is for.
Consider always using the `-s` option to GPG sign your tags, and upload your public key to GitHub profile so others know the tag was created by you (GitHub will show a nice green "Verified" button next to GPG-signed releases meeting certain criteria).
Once you've created your tag to your liking (notice --dry-run was omitted this time): git push --tags origin
Just keep in mind that the tags listed locally can be different than what's in your remotes, and git is kinda terrible at showing these differences. git assumes tags are always treated immutably, and globally unique across all remotes, which are bad assumptions IMO, but it is what it is. This is why GPG-signing your tags might be helpful. It's also why I regularly delete all my local tags and resync them from my remotes: git tag -d $(git tag) && git remote update That way I don't accidentally push temporary tags I may have created locally up to a remote, unless I'm really sure I want to.
Another suggestion, consider adopting a rigorous naming convention for all your release tags, so they can be easily identified. Keep in mind that the forward-slash character is a valid character in a tag name. So, you may wish to name your tags something like this: release/myProject-x.y.z
If you're still deciding how often to bump the version numbers, consider following something like: http://semver.org/spec/v2.0.0.html
Thank you for your tips, Christopher. This is probably the most complete guide that can be included in a short post.
Regards,
Rafal
Christopher wrote:
If you're still deciding how often to bump the version numbers, consider following something like: http://semver.org/spec/v2.0.0.html
And if you don't use release branches and really don't want to bother trying to decide at each release on whether to go from 1.0.0 to 1.0.1, 1.1.0 or 2.0.0, then consider just using udev/systemd-style versioning: a single integer release number (so after version 1, there is obviously version 2). The drawback is that it does not deliver to your users the kind of information semantic versioning carries (e.g., it is not obvious which systemd releases carry the biggest changes).
Kevin Kofler
25.04.2017 02:47 Nico Kadel-Garcia nkadel@gmail.com wrote:
On Mon, Apr 24, 2017 at 7:39 PM, Rafal Luzynski digitalfreak@lingonborough.com wrote:
23.04.2017 19:23 Christopher ctubbsii@fedoraproject.org wrote:
You can set the name of the file via the GitHub API when you download it.
For jQuery (packaged as js-jquery), I use: https://github.com/jquery/jquery/archive/%%7Bversion%7D/jquery-%%7Bversion%7...
This will work for any GitHub project which tags released versions:
https://github.com/<user-or-group>/<repo>/archive/<tag-commit-or-branch>/<preferred-file-name>.tar.gz [...]
I'm afraid this will not work because (according to the GitHub repo) this project has 0 release tags. Also the archive has been created only 23 days ago. Isn't it too early to package a project which has not yet ever been released upstream?
Been there, done that. It assumes that other people are following your own model of how source control or product releases work.
Of course, there are multiple ways to manage product releases. The spec file must be adapted to the way the source repo is managed.
Globe Trotter has already explained in another post that he is also upstream so he is able to rework both sides and choose the most comfortable way.
[...] I'll note that it is not "incorrect" to import a project without full history and logs. True, it discards history. [...]
I meant that a "correct" way to import is the way according to what the maintainer wanted. History, at least partial, and tags help maintaining the releases. Again, there are multiple ways to achieve the result but I guess that release tags are what Globe Trotter would like.
Regards,
Rafal
On Sun, Apr 23, 2017 at 8:23 PM, Christopher ctubbsii@fedoraproject.org wrote:
You can set the name of the file via the GitHub API when you download it.
For jQuery (packaged as js-jquery), I use: https://github.com/jquery/jquery/archive/%%7Bversion%7D/jquery-%%7Bversion%7...
This will work for any GitHub project which tags released versions: https://github.com/<user-or-group>/<repo>/archive/<tag-commit-or-branch>/<preferred-file-name>.tar.gz
For yours: https://github.com/maitra/thaali/archive/master/<preferred-file-name>.tar.gz
But, you shouldn't use "master". You should be more specific about which commit you are using, for reproducibility: https://github.com/maitra/thaali/archive/7452ae99fe01e7cea6b70881c486775cd1b...<preferred-file-name>.tar.gz
Hello and sorry for reviving an old thread, but it was relevant.
Has github removed the capability to name the tarball whatever I choose, or could I be doing something wrong?
I have tried downloading tarballs from 4 unrelated repositories using: https://github.com/OWNER/%%7Bname%7D/archive/%%7Bcommit0%7D.tar.gz#/%%7Bname... https://github.com/OWNER/%%7Bname%7D/archive/%%7Bcommit0%7D/%%7Bname%7D-%%7B... https://github.com/OWNER/%%7Bname%7D/archive/%%7Bshortcommit0%7D/%%7Bname%7D...
and even: https://github.com/OWNER/%%7Bname%7D/archive/%%7Bcommit0%7D/foo.tar.gz
but I always end up with a %{name}-%{commit0}.tar.gz tarball.
2017-06-28 20:54 GMT+02:00 Alexander Ploumistos alex.ploumistos@gmail.com:
Hello and sorry for reviving an old thread, but it was relevant.
Has github removed the capability to name the tarball whatever I choose, or could I be doing something wrong?
I have tried downloading tarballs from 4 unrelated repositories using: https://github.com/OWNER/%%7Bname%7D/archive/%%7Bcommit0%7D.tar.gz#/%%7Bname... https://github.com/OWNER/%%7Bname%7D/archive/%%7Bcommit0%7D/%%7Bname%7D-%%7B... https://github.com/OWNER/%%7Bname%7D/archive/%%7Bshortcommit0%7D/%%7Bname%7D...
and even: https://github.com/OWNER/%%7Bname%7D/archive/%%7Bcommit0%7D/foo.tar.gz
but I always end up with a %{name}-%{commit0}.tar.gz tarball.
How are you using those links to download the tarball? As far as I know if you download through a browser, it will always rename the tarball to %{name}-%{commit0}, but if you download with wget or curl [0], you should get the tarball name you chose. Note however that the folder name within the tarball will always be %{name}-%{commit0}, so the interest of naming the tarball itself differently is limited.
[0] e.g.: wget https://github.com/godotengine/godot/archive/9e54e1f/godot-9e54e1f.tar.gz
On Wed, Jun 28, 2017 at 10:22 PM, Rémi Verschelde rverschelde@gmail.com wrote:
How are you using those links to download the tarball? As far as I know if you download through a browser, it will always rename the tarball to %{name}-%{commit0}, but if you download with wget or curl [0], you should get the tarball name you chose. Note however that the folder name within the tarball will always be %{name}-%{commit0}, so the interest of naming the tarball itself differently is limited.
[0] e.g.: wget https://github.com/godotengine/godot/archive/9e54e1f/godot-9e54e1f.tar.gz
OK, I am an idiot. I had completely forgotten about that, so yes, while I was trying to figure which URL to feed to wget, I was using a browser…
Thanks!
-
Alexander Ploumistos -
Christopher -
Globe Trotter -
Kevin Kofler -
Nico Kadel-Garcia -
Rafal Luzynski -
Rémi Verschelde