how to handle source code from github

[Globe Trotter]

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!

[Christopher]

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/%{version}/jquery-%{version}.tar.gz

This will work for any GitHub project which tags released versions:
https://github.com/<user-or-group>/<repo>/archive/<tag-com...
<https://github.com/<user-or-group>/<repo>/archive/<tagName...

For yours:
https://github.com/maitra/thaali/archive/master/<preferred-file-name&g...

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/7452ae99fe01e7cea6b70881c486775c...

Some projects do something like:
%global commit 7452ae99fe01e7cea6b70881c486775cd1b32186
%global shortcommit %(c=%{commit}; echo ${c:0:7})
...
Source0:
https://github.com/maitra/thaali/archive/%{commit}/%{name}-%{commit}.tar.gz
...
%prep
%setup -qn %{name}-%{commit}
...

Hope that helps.

On Sun, Apr 23, 2017 at 11:38 AM Globe Trotter <itsme_410(a)yahoo.com&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>

[Rafal Luzynski]

23.04.2017 19:23 Christopher <ctubbsii(a)fedoraproject.org&gt; 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/%{version}/jquery-%{version}.tar.gz
>  
>   This will work for any GitHub project which tags released versions:
>  
>
> https://github.com/<user-or-group>/<repo>/archive/<tag-com...
>  [...] 
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(a)yahoo.com
>  mailto:[e-mail] > 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

[Christopher]

On Mon, Apr 24, 2017 at 7:47 PM Rafal Luzynski <
digitalfreak(a)lingonborough.com&gt; wrote:

>  23.04.2017 19:23 Christopher <ctubbsii(a)fedoraproject.org&gt;
> 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/%{version}/jquery-%{version}.tar.gz
>  >
>  >  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?
>
>  
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.)

[Nico Kadel-Garcia]

On Mon, Apr 24, 2017 at 7:39 PM, Rafal Luzynski
<digitalfreak(a)lingonborough.com&gt; wrote:
>  23.04.2017 19:23 Christopher <ctubbsii(a)fedoraproject.org&gt;
> 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/%{version}/jquery-%{version}.tar.gz
> >
> >  This will work for any GitHub project which tags released versions:
> >
> >
> https://github.com/<user-or-group>/<repo>/archive/<tag-com...
> > [...]
>
>  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(a)yahoo.com
> > mailto:[e-mail] > 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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

[Globe Trotter]

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.

[Rafal Luzynski]

25.04.2017 02:47 Nico Kadel-Garcia <nkadel(a)gmail.com&gt; wrote:
>  On Mon, Apr 24, 2017 at 7:39 PM, Rafal Luzynski
>  <digitalfreak(a)lingonborough.com&gt; wrote:
>  > 23.04.2017 19:23 Christopher <ctubbsii(a)fedoraproject.org&gt; 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/%{version}/jquery-%{version}.tar.gz
>  >>
>  >> This will work for any GitHub project which tags released versions:
>  >>
>  >>
> https://github.com/<user-or-group>/<repo>/archive/<tag-com...
>  >> [...]
>  >
>  > 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

[Rafal Luzynski]

25.04.2017 06:16 Globe Trotter <itsme_410(a)yahoo.com&gt; 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-impor...

* 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

[Christopher]

On Tue, Apr 25, 2017 at 12:21 AM Globe Trotter <itsme_410(a)yahoo.com&gt; 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

[Rafal Luzynski]

Thank you for your tips, Christopher. This is probably the most
complete guide that can be included in a short post.

Regards,

Rafal

[Kevin Kofler]

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

[Alexander Ploumistos]

On Sun, Apr 23, 2017 at 8:23 PM, Christopher <ctubbsii(a)fedoraproject.org&gt; 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/%{version}/jquery-%{version}.tar.gz
>
>  This will work for any GitHub project which tags released versions:
>
> https://github.com/<user-or-group>/<repo>/archive/<tag-com...
>
>  For yours:
>  https://github.com/maitra/thaali/archive/master/<preferred-file-name&g...
>
>  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/7452ae99fe01e7cea6b70881c486775c...
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/%{name}/archive/%{commit0}.tar.gz#/%{name}-%{sho...
https://github.com/OWNER/%{name}/archive/%{commit0}/%{name}-%{shortcommit...
https://github.com/OWNER/%{name}/archive/%{shortcommit0}/%{name}-%{shortc...

and even:
https://github.com/OWNER/%{name}/archive/%{commit0}/foo.tar.gz

but I always end up with a %{name}-%{commit0}.tar.gz tarball.

[Rémi Verschelde]

2017-06-28 20:54 GMT+02:00 Alexander Ploumistos <alex.ploumistos(a)gmail.com&gt;:
>  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/%{name}/archive/%{commit0}.tar.gz#/%{name}-%{sho...
>  https://github.com/OWNER/%{name}/archive/%{commit0}/%{name}-%{shortcommit...
>  https://github.com/OWNER/%{name}/archive/%{shortcommit0}/%{name}-%{shortc...
>
>  and even:
>  https://github.com/OWNER/%{name}/archive/%{commit0}/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

[Alexander Ploumistos]

On Wed, Jun 28, 2017 at 10:22 PM, Rémi Verschelde <rverschelde(a)gmail.com&gt; 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!