I'm getting spec files from centos git which is really convenient when the related source is easy to find. But some things - e.g. from a spec file
# How to create the source tarball: # # git clone git://git.fedorahosted.org/git/python-rhsm.git/ # cd client/python-rhsm # tito build --tag python-rhsm-$VERSION-$RELEASE --tgz
Never used tito before, so I install it and try, and rather than giving me the source package I need - it gives me a python traceback complaining that I haven't configured some things properly.
Seems a lot of the software distribution world is getting overly complex with an expectation that the end user who needs to exercise his FLOSS rights has to use git or nodejs or for php composer or whatever just to get what use to be available with no more complexity than choosing tar.gz or tar.bz2 or .zip if the dev was Windows.
Whatever happened to KISS and why can't source tarballs be distributed as source tarballs?
Back when I was a Fedora packager - the packaging guidelines would reject a package of the Source tarball wasn't a URL and if the timestamp on the tarball in the src.rpm didn't match upstream even if the checksum was identical.
Guess those days are gone.
/rant
On Tue, December 13, 2016 4:16 pm, Alice Wonder wrote:
I'm getting spec files from centos git which is really convenient when the related source is easy to find. But some things - e.g. from a spec file
# How to create the source tarball: # # git clone git://git.fedorahosted.org/git/python-rhsm.git/ # cd client/python-rhsm # tito build --tag python-rhsm-$VERSION-$RELEASE --tgz
Never used tito before, so I install it and try, and rather than giving me the source package I need - it gives me a python traceback complaining that I haven't configured some things properly.
Seems a lot of the software distribution world is getting overly complex with an expectation that the end user who needs to exercise his FLOSS rights has to use git or nodejs or for php composer or whatever just to get what use to be available with no more complexity than choosing tar.gz or tar.bz2 or .zip if the dev was Windows.
Whatever happened to KISS and why can't source tarballs be distributed as source tarballs?
Back when I was a Fedora packager - the packaging guidelines would reject a package of the Source tarball wasn't a URL and if the timestamp on the tarball in the src.rpm didn't match upstream even if the checksum was identical.
Guess those days are gone.
<rant> Not exactly. I'm pretty happy with FreeBSD pkg system, and with poudriere whenever I need custom configs different from what package maintainers choice. No unneeded complication crap.
Of course, this is only rant from point of view of mentioning our rival: FreeBSD on our list ;-) </rant>
Valeri
/rant _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Le 13/12/2016 à 23:16, Alice Wonder a écrit :
Seems a lot of the software distribution world is getting overly complex with an expectation that the end user who needs to exercise his FLOSS rights has to use git or nodejs or for php composer or whatever just to get what use to be available with no more complexity than choosing tar.gz or tar.bz2 or .zip if the dev was Windows.
Whatever happened to KISS
<rant>
That's why I'm running Slackware on most of my systems.
</rant>
On 12/13/2016 2:35 PM, Nicolas Kovacs wrote:
That's why I'm running Slackware on most of my systems.
that doesn't solve the issue of various FOSS projects using all kinda whacky build toolkits and requirements.
one tool I wanted to build a few weeks ago depended on common lisp.
another package I wanted to play with required this whole complex python infrastructure which I'd never seen or heard of before (Im not a python dev although I can follow bits of code, and even make minor changes), and the build commands in that infrastructure were pulling in source packages from various servers all over the world, which kinda scared me from a security standpoint.
On Tue, December 13, 2016 5:09 pm, John R Pierce wrote:
On 12/13/2016 2:35 PM, Nicolas Kovacs wrote:
That's why I'm running Slackware on most of my systems.
that doesn't solve the issue of various FOSS projects using all kinda whacky build toolkits and requirements.
one tool I wanted to build a few weeks ago depended on common lisp.
another package I wanted to play with required this whole complex python infrastructure which I'd never seen or heard of before (Im not a python dev although I can follow bits of code, and even make minor changes), and the build commands in that infrastructure were pulling in source packages from various servers all over the world, which kinda scared me from a security standpoint.
That is inevitable: some of the tools/projects to work may require you to bring a huge external infrastructure if you want to use them. This has no way around.
Another thing is: when building of the project (libraries, binaries, etc) requires sophisticated infrastructure that is not necessary after you built it. This and only this is what I meant when mentioned FreeBSD pkg and poudriere for building custom configured packages - you only need that infrastructure when building (on build box in build jail...).
But in general, yes, the world seems to have gone the way "why simple, when you can do it complex way".
I guess I should have added rant tags...
Valeri
-- john r pierce, recycling bits in santa cruz
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On 12/13/2016 03:21 PM, Valeri Galtsev wrote:
Another thing is: when building of the project (libraries, binaries, etc) requires sophisticated infrastructure that is not necessary after you built it.
Yes, that's why I mentioned nodejs. A rather cool JavaScript project didn't do quite what I wanted, but to modify it I had to install some nodejs environment that was used to "build" the JavaScript and had to be re-run for any tweak to the components and always built a rather large JavaScript file even minified.
I ended up just scrapping it any writing my own even though its not as flexible, and I'm still trying to figure out how requiring a node setup is a good idea to require for generating a static file.
But that's the trend.
Hello Valeri,
On Tue, 2016-12-13 at 17:21 -0600, Valeri Galtsev wrote:
That is inevitable: some of the tools/projects to work may require you to bring a huge external infrastructure if you want to use them. This has no way around.
The point is not that one requires (many) tools to build a project, the problem is that tools like f.e. composer make it unclear to the user what exactly is being pulled from where and for what reason and whether the pulled sources are being verified with checksums. Just providing a text with a set of requirements and urls makes it much easier for the user to verify the sources. It's about transparency.
Regards, Leonard.
On Tue, 2016-12-13 at 14:16 -0800, Alice Wonder wrote:
I'm getting spec files from centos git which is really convenient when the related source is easy to find. But some things - e.g. from a spec file
# How to create the source tarball: # # git clone git://git.fedorahosted.org/git/python-rhsm.git/ # cd client/python-rhsm # tito build --tag python-rhsm-$VERSION-$RELEASE --tgz
Never used tito before, so I install it and try, and rather than giving me the source package I need - it gives me a python traceback complaining that I haven't configured some things properly.
Seems a lot of the software distribution world is getting overly complex with an expectation that the end user who needs to exercise his FLOSS rights has to use git or nodejs or for php composer or whatever just to get what use to be available with no more complexity than choosing tar.gz or tar.bz2 or .zip if the dev was Windows.
Whatever happened to KISS and why can't source tarballs be distributed as source tarballs?
Back when I was a Fedora packager - the packaging guidelines would reject a package of the Source tarball wasn't a URL and if the timestamp on the tarball in the src.rpm didn't match upstream even if the checksum was identical.
Guess those days are gone.
/rant
Hi,
Not seen this one before, but don't play with much python. The SPEC really should just refer too a URL too a compressed archive as the packages home site supplies them.
https://github.com/candlepin/python-rhsm/releases
Regards
Phil
On 12/13/2016 03:34 PM, Phil Wyett wrote:
On Tue, 2016-12-13 at 14:16 -0800, Alice Wonder wrote:
I'm getting spec files from centos git which is really convenient when the related source is easy to find. But some things - e.g. from a spec file
# How to create the source tarball: # # git clone git://git.fedorahosted.org/git/python-rhsm.git/ # cd client/python-rhsm # tito build --tag python-rhsm-$VERSION-$RELEASE --tgz
Never used tito before, so I install it and try, and rather than giving me the source package I need - it gives me a python traceback complaining that I haven't configured some things properly.
Seems a lot of the software distribution world is getting overly complex with an expectation that the end user who needs to exercise his FLOSS rights has to use git or nodejs or for php composer or whatever just to get what use to be available with no more complexity than choosing tar.gz or tar.bz2 or .zip if the dev was Windows.
Whatever happened to KISS and why can't source tarballs be distributed as source tarballs?
Back when I was a Fedora packager - the packaging guidelines would reject a package of the Source tarball wasn't a URL and if the timestamp on the tarball in the src.rpm didn't match upstream even if the checksum was identical.
Guess those days are gone.
/rant
Hi,
Not seen this one before, but don't play with much python. The SPEC really should just refer too a URL too a compressed archive as the packages home site supplies them.
https://github.com/candlepin/python-rhsm/releases
Regards
Phil
I went to the github and it doesn't have a packaged release that matches the version. I managed to find it in the build system logs, but its just weird.
If I recall, formerly for a tarball to be different than what was on upstream, it had to have a legal reason (e.g. patents) and a script in the sources that could turn upstream tarball into the version used.
On Tue, 2016-12-13 at 15:39 -0800, Alice Wonder wrote:
On 12/13/2016 03:34 PM, Phil Wyett wrote:
On Tue, 2016-12-13 at 14:16 -0800, Alice Wonder wrote:
I'm getting spec files from centos git which is really convenient when the related source is easy to find. But some things - e.g. from a spec file
# How to create the source tarball: # # git clone git://git.fedorahosted.org/git/python-rhsm.git/ # cd client/python-rhsm # tito build --tag python-rhsm-$VERSION-$RELEASE --tgz
Never used tito before, so I install it and try, and rather than giving me the source package I need - it gives me a python traceback complaining that I haven't configured some things properly.
Seems a lot of the software distribution world is getting overly complex with an expectation that the end user who needs to exercise his FLOSS rights has to use git or nodejs or for php composer or whatever just to get what use to be available with no more complexity than choosing tar.gz or tar.bz2 or .zip if the dev was Windows.
Whatever happened to KISS and why can't source tarballs be distributed as source tarballs?
Back when I was a Fedora packager - the packaging guidelines would reject a package of the Source tarball wasn't a URL and if the timestamp on the tarball in the src.rpm didn't match upstream even if the checksum was identical.
Guess those days are gone.
/rant
Hi,
Not seen this one before, but don't play with much python. The SPEC really should just refer too a URL too a compressed archive as the packages home site supplies them.
https://github.com/candlepin/python-rhsm/releases
Regards
Phil
I went to the github and it doesn't have a packaged release that matches the version. I managed to find it in the build system logs, but its just weird.
If I recall, formerly for a tarball to be different than what was on upstream, it had to have a legal reason (e.g. patents) and a script in the sources that could turn upstream tarball into the version used.
Hi,
Out of interest, which version do you refer to?
Regards
Phil
On 12/13/2016 03:57 PM, Phil Wyett wrote:
On Tue, 2016-12-13 at 15:39 -0800, Alice Wonder wrote:
On 12/13/2016 03:34 PM, Phil Wyett wrote:
On Tue, 2016-12-13 at 14:16 -0800, Alice Wonder wrote:
I'm getting spec files from centos git which is really convenient when the related source is easy to find. But some things - e.g. from a spec file
# How to create the source tarball: # # git clone git://git.fedorahosted.org/git/python-rhsm.git/ # cd client/python-rhsm # tito build --tag python-rhsm-$VERSION-$RELEASE --tgz
Never used tito before, so I install it and try, and rather than giving me the source package I need - it gives me a python traceback complaining that I haven't configured some things properly.
Seems a lot of the software distribution world is getting overly complex with an expectation that the end user who needs to exercise his FLOSS rights has to use git or nodejs or for php composer or whatever just to get what use to be available with no more complexity than choosing tar.gz or tar.bz2 or .zip if the dev was Windows.
Whatever happened to KISS and why can't source tarballs be distributed as source tarballs?
Back when I was a Fedora packager - the packaging guidelines would reject a package of the Source tarball wasn't a URL and if the timestamp on the tarball in the src.rpm didn't match upstream even if the checksum was identical.
Guess those days are gone.
/rant
Hi,
Not seen this one before, but don't play with much python. The SPEC really should just refer too a URL too a compressed archive as the packages home site supplies them.
https://github.com/candlepin/python-rhsm/releases
Regards
Phil
I went to the github and it doesn't have a packaged release that matches the version. I managed to find it in the build system logs, but its just weird.
If I recall, formerly for a tarball to be different than what was on upstream, it had to have a legal reason (e.g. patents) and a script in the sources that could turn upstream tarball into the version used.
Hi,
Out of interest, which version do you refer to?
Regards
Phil
1.17.9 is the version in CentOS 7.3 and what I needed (and found on a build server)
On Tue, 2016-12-13 at 16:14 -0800, Alice Wonder wrote:
On 12/13/2016 03:57 PM, Phil Wyett wrote:
On Tue, 2016-12-13 at 15:39 -0800, Alice Wonder wrote:
On 12/13/2016 03:34 PM, Phil Wyett wrote:
On Tue, 2016-12-13 at 14:16 -0800, Alice Wonder wrote:
I'm getting spec files from centos git which is really convenient when the related source is easy to find. But some things - e.g. from a spec file
# How to create the source tarball: # # git clone git://git.fedorahosted.org/git/python-rhsm.git/ # cd client/python-rhsm # tito build --tag python-rhsm-$VERSION-$RELEASE --tgz
Never used tito before, so I install it and try, and rather than giving me the source package I need - it gives me a python traceback complaining that I haven't configured some things properly.
Seems a lot of the software distribution world is getting overly complex with an expectation that the end user who needs to exercise his FLOSS rights has to use git or nodejs or for php composer or whatever just to get what use to be available with no more complexity than choosing tar.gz or tar.bz2 or .zip if the dev was Windows.
Whatever happened to KISS and why can't source tarballs be distributed as source tarballs?
Back when I was a Fedora packager - the packaging guidelines would reject a package of the Source tarball wasn't a URL and if the timestamp on the tarball in the src.rpm didn't match upstream even if the checksum was identical.
Guess those days are gone.
/rant
Hi,
Not seen this one before, but don't play with much python. The SPEC really should just refer too a URL too a compressed archive as the packages home site supplies them.
https://github.com/candlepin/python-rhsm/releases
Regards
Phil
I went to the github and it doesn't have a packaged release that matches the version. I managed to find it in the build system logs, but its just weird.
If I recall, formerly for a tarball to be different than what was on upstream, it had to have a legal reason (e.g. patents) and a script in the sources that could turn upstream tarball into the version used.
Hi,
Out of interest, which version do you refer to?
Regards
Phil
1.17.9 is the version in CentOS 7.3 and what I needed (and found on a build server)
Hi,
To get source for a package in CentOS, you follow the get_sources.sh' section and 'Example workflow' section in:
https://wiki.centos.org/Sources
For your package...
* Setup 'centos-git-common' i.e. clone it to your system.
* Do the clone and checkout for your package.
git clone https://git.centos.org/summary/rpms!python-rhsm.git cd python-rhsm git checkout c7 sh <location_of_centos_git_common>/get_sources.sh
You should then have the spec, any patches and tarball(s).
Regards
Phil
On Wed, 2016-12-14 at 00:25 +0000, Phil Wyett wrote:
On Tue, 2016-12-13 at 16:14 -0800, Alice Wonder wrote:
On 12/13/2016 03:57 PM, Phil Wyett wrote:
On Tue, 2016-12-13 at 15:39 -0800, Alice Wonder wrote:
On 12/13/2016 03:34 PM, Phil Wyett wrote:
On Tue, 2016-12-13 at 14:16 -0800, Alice Wonder wrote:
I'm getting spec files from centos git which is really convenient when the related source is easy to find. But some things - e.g. from a spec file
# How to create the source tarball: # # git clone git://git.fedorahosted.org/git/python-rhsm.git/ # cd client/python-rhsm # tito build --tag python-rhsm-$VERSION-$RELEASE --tgz
Never used tito before, so I install it and try, and rather than giving me the source package I need - it gives me a python traceback complaining that I haven't configured some things properly.
Seems a lot of the software distribution world is getting overly complex with an expectation that the end user who needs to exercise his FLOSS rights has to use git or nodejs or for php composer or whatever just to get what use to be available with no more complexity than choosing tar.gz or tar.bz2 or .zip if the dev was Windows.
Whatever happened to KISS and why can't source tarballs be distributed as source tarballs?
Back when I was a Fedora packager - the packaging guidelines would reject a package of the Source tarball wasn't a URL and if the timestamp on the tarball in the src.rpm didn't match upstream even if the checksum was identical.
Guess those days are gone.
/rant
Hi,
Not seen this one before, but don't play with much python. The SPEC really should just refer too a URL too a compressed archive as the packages home site supplies them.
https://github.com/candlepin/python-rhsm/releases
Regards
Phil
I went to the github and it doesn't have a packaged release that matches the version. I managed to find it in the build system logs, but its just weird.
If I recall, formerly for a tarball to be different than what was on upstream, it had to have a legal reason (e.g. patents) and a script in the sources that could turn upstream tarball into the version used.
Hi,
Out of interest, which version do you refer to?
Regards
Phil
1.17.9 is the version in CentOS 7.3 and what I needed (and found on a build server)
Hi,
To get source for a package in CentOS, you follow the get_sources.sh' section and 'Example workflow' section in:
https://wiki.centos.org/Sources
For your package...
Setup 'centos-git-common' i.e. clone it to your system.
Do the clone and checkout for your package.
git clone https://git.centos.org/summary/rpms!python-rhsm.git cd python-rhsm git checkout c7 sh <location_of_centos_git_common>/get_sources.sh
You should then have the spec, any patches and tarball(s).
Regards
Phil
Sorry rushed that.
Should be:
git clone https://git.centos.org/git/rpms/python-rhsm.git
Regards
Phil
Hello Alice,
On Tue, 2016-12-13 at 14:16 -0800, Alice Wonder wrote:
I'm getting spec files from centos git which is really convenient when the related source is easy to find. But some things - e.g. from a spec file
# How to create the source tarball: # # git clone git://git.fedorahosted.org/git/python-rhsm.git/ # cd client/python-rhsm # tito build --tag python-rhsm-$VERSION-$RELEASE --tgz
Seems like a valid issue to take upstream. Especially since Red Hat now uses the centos repo to provide their sources to the public.
It is possible to get a free RH developer account (speaking of transparency, it took me a while to find the right banner to click on to actually get that free account ;p ), but the source code is only provided as 2 dvds and it is unclear to me where to find sources for updated packages. Or perhaps you have to download 2 dvds every time they update that image. Ouch.
Regards, Leonard.
On 12/13/2016 04:16 PM, Alice Wonder wrote:
I'm getting spec files from centos git which is really convenient when the related source is easy to find. But some things - e.g. from a spec file
# How to create the source tarball: # # git clone git://git.fedorahosted.org/git/python-rhsm.git/ # cd client/python-rhsm # tito build --tag python-rhsm-$VERSION-$RELEASE --tgz
Never used tito before, so I install it and try, and rather than giving me the source package I need - it gives me a python traceback complaining that I haven't configured some things properly.
Seems a lot of the software distribution world is getting overly complex with an expectation that the end user who needs to exercise his FLOSS rights has to use git or nodejs or for php composer or whatever just to get what use to be available with no more complexity than choosing tar.gz or tar.bz2 or .zip if the dev was Windows.
Whatever happened to KISS and why can't source tarballs be distributed as source tarballs?
Back when I was a Fedora packager - the packaging guidelines would reject a package of the Source tarball wasn't a URL and if the timestamp on the tarball in the src.rpm didn't match upstream even if the checksum was identical.
Guess those days are gone.
/rant
I am not sure what you are trying to accomplish .. but the tools to get an SRPM or the Sources from CentOS are dead simple.
They are located here:
https://git.centos.org/summary/centos-git-common.git
And they are very easy .. and most are bash scripts.
So:
git clone https://git.centos.org/summary/rpms!skopeo
(that just happens to be what I am working on right now)
cd skopeo
git branch -a (so you can see the branches .. optional)
git checkout c7-extras
get_sources.sh
=================
Now you have the full SRPM in the same directory structure as if you had installed the SRPM.
If you would have used 'into_srpm.sh' instead of 'get_sources.sh' .. you would have the SRPM generated as well as the full tree. There are switches for the tools (-c for get_sources.sh to check the crc info for already downloaded files .. -d for into_srpm.sh for changing the dist tag of a generated SRPM, etc.)
I use these tools for every package built for CentOS and they are very easy to use.
Now, obviously that does not include development inside an extracted SRPM. But I normally just use diff (or git) to track changes and generate patches, etc.
Thanks, Johnny Hughes
Hello Johnny,
On Wed, 2016-12-14 at 06:58 -0600, Johnny Hughes wrote:
So:
Apart from the syntax error because the exclamation mark is not escaped this leads nowhere.
So I tried:
$ git clone https://git.centos.org/git/rpms/skopeo.git
(that just happens to be what I am working on right now)
cd skopeo
git branch -a (so you can see the branches .. optional)
git checkout c7-extras
So far so good. We now got a spec file. Doing the same for bc: a spec file and patches. Still no source.
get_sources.sh
The name suggests this is what we need (or do we??) If only I could find that script anywhere...
So lets dig around a bit:
skopeo]$ cat .gitignore SOURCES/skopeo-1f655f3.tar.gz
bc]$ cat .gitignore SOURCES/bc-1.06.95.tar.bz2
python-rhsm]$ cat .gitignore SOURCES/python-rhsm-1.17.9.tar.gz
I think this solves Alice's issue once the .gitignore file is fixed.
For some reason the tarballs seem to be ignored. Something I need to fix in my git config or is it at your end?
Regards, Leonard.
On Wed, Dec 14, 2016 at 07:29:19PM +0100, Leonard den Ottolander wrote:
get_sources.sh
The name suggests this is what we need (or do we??) If only I could find that script anywhere...
Johnny said it at the beginning of his email. I'll paste it again so you don't have to go re-read it:
On Wed, Dec 14, 2016 at 06:58:02AM -0600, Johnny Hughes wrote:
I am not sure what you are trying to accomplish .. but the tools to get an SRPM or the Sources from CentOS are dead simple.
They are located here:
https://git.centos.org/summary/centos-git-common.git
And they are very easy .. and most are bash scripts.
Hello Jonathan,
On Wed, 2016-12-14 at 15:03 -0500, Jonathan Billings wrote:
On Wed, Dec 14, 2016 at 07:29:19PM +0100, Leonard den Ottolander wrote:
get_sources.sh
The name suggests this is what we need (or do we??) If only I could find that script anywhere...
Johnny said it at the beginning of his email. I'll paste it again so you don't have to go re-read it:
On Wed, Dec 14, 2016 at 06:58:02AM -0600, Johnny Hughes wrote:
They are located here:
Thanks for pointing out my oversight.
However, cloning that repo does not work...
$ git clone https://git.centos.org/summary/centos-git-common.git Initialized empty Git repository in /data/leonard/srcothers/centos/centos-git-common/.git/ warning: remote HEAD refers to nonexistent ref, unable to checkout.
What am I missing?
And then there remains the question: git checkout for a package gathers the spec file and patches, so why do we need a script to get the source tarball when all that is stopping it from getting checked out is an entry in .gitignore? A whole script to undo that one entry in .gitignore? What's the idea behind this?
Regards, Leonard.
On Wed, 2016-12-14 at 21:38 +0100, Leonard den Ottolander wrote:
Hello Jonathan,
On Wed, 2016-12-14 at 15:03 -0500, Jonathan Billings wrote:
On Wed, Dec 14, 2016 at 07:29:19PM +0100, Leonard den Ottolander wrote:
get_sources.sh
The name suggests this is what we need (or do we??) If only I could find that script anywhere...
Johnny said it at the beginning of his email. I'll paste it again so you don't have to go re-read it:
On Wed, Dec 14, 2016 at 06:58:02AM -0600, Johnny Hughes wrote:
They are located here:
Thanks for pointing out my oversight.
However, cloning that repo does not work...
$ git clone https://git.centos.org/summary/centos-git-common.git Initialized empty Git repository in /data/leonard/srcothers/centos/centos-git-common/.git/ warning: remote HEAD refers to nonexistent ref, unable to checkout.
What am I missing?
Hi,
The path to the repo is wrong.
git clone https://git.centos.org/git/centos-git-common.git
The one you are trying is the web interface address.
Regards
Phil
Hello Phil,
On Wed, 2016-12-14 at 20:57 +0000, Phil Wyett wrote:
The path to the repo is wrong.
Too late to boost my brain with more coffee for today. Not as sharp as I would like to be ;) .
Still leaves me with the question why a script to download the source tarballs is needed when just not adding a .gitignore entry for them to the repos would fix the issue. Could someone involved care to explain the rationale behind this or point me to a thread where this has been discussed/explained?
Cheers, Leonard.
On Wed, 2016-12-14 at 22:32 +0100, Leonard den Ottolander wrote:
Hello Phil,
On Wed, 2016-12-14 at 20:57 +0000, Phil Wyett wrote:
The path to the repo is wrong.
Too late to boost my brain with more coffee for today. Not as sharp as I would like to be ;) .
Still leaves me with the question why a script to download the source tarballs is needed when just not adding a .gitignore entry for them to the repos would fix the issue. Could someone involved care to explain the rationale behind this or point me to a thread where this has been discussed/explained?
Cheers, Leonard.
Hi,
Read: https://wiki.centos.org/Sources
This doc explains structure of text and non text sources/overall structure of the server.
Regards
Phil
On 12/14/2016 03:32 PM, Leonard den Ottolander wrote:
Hello Phil,
On Wed, 2016-12-14 at 20:57 +0000, Phil Wyett wrote:
The path to the repo is wrong.
Too late to boost my brain with more coffee for today. Not as sharp as I would like to be ;) .
Still leaves me with the question why a script to download the source tarballs is needed when just not adding a .gitignore entry for them to the repos would fix the issue. Could someone involved care to explain the rationale behind this or point me to a thread where this has been discussed/explained?
Not sure what you are asking.
You don't want to put large GZ tarballs in git .. we only put text file in git. All binary files are put in a look-aside cache.
So, when you do git clone you get all the text sources .. when you do get_sources.sh (or into_srpm.sh) you get all the binary sources (tarballs, etc.). You need both to be able to build the SRPM.
Hello Johnny,
On Wed, 2016-12-14 at 23:21 -0600, Johnny Hughes wrote:
Not sure what you are asking.
You don't want to put large GZ tarballs in git .. we only put text file in git. All binary files are put in a look-aside cache.
Alright. That is exactly the answer I was looking for :) . Thanks.
Regards, Leonard.
-
Alice Wonder -
John R Pierce -
Johnny Hughes -
Jonathan Billings -
Leonard den Ottolander -
Nicolas Kovacs -
Phil Wyett -
Valeri Galtsev