Re: The move to git!
On 08/05/2010 10:56 PM, Cristian Gafton wrote: > Congratulations guys, this is awesome work. I know it has been painful > and I have a rough idea about the level of effort involved. Looking > over the transition, this is truly solid work, and I am confident it > will carry (and exceed) the packager's needs for at least another 13 > releases or so... :-) > > Oh, yeah, and Jesse - thank you, for now people can finally stop > mumbling blames my way. ;) No!!! That doesn't stop. The crazy Romanian is to blame for everything! -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
Congratulations guys, this is awesome work. I know it has been painful and I have a rough idea about the level of effort involved. Looking over the transition, this is truly solid work, and I am confident it will carry (and exceed) the packager's needs for at least another 13 releases or so... :-) Oh, yeah, and Jesse - thank you, for now people can finally stop mumbling blames my way. ;) Cristian Gafton On Thu, Jul 29, 2010 at 8:55 PM, Jesse Keating wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > This evening we opened up dist-git for business. Dist-git is our git > based replacement for dist-cvs, the source control system we were using > for our package specs, patches, and source files. This has been a long > time coming and a massive effort. I want to take a little time here to > outline what we've done and where we are going. > > First a brief outline of how our CVS system worked. CVS is a daemon of > sorts, and all repos typically live within a single CVSROOT. Within > this CVSROOT we had an 'avail' system to make use of, that we could > populate with data from Fedora Account System and dump into this file. > Avail worked on path names, relative to the CVSROOT. Since we used > directories for each Fedora release as pseudo branches we could set > avail info on each release "branch". CVS also used some filesystem > symlink tricks to create a "common" subdir for every package module, and > this is where we stuffed common scripts and Makefile content. Pretty > clever on one hand, we can make updates to the make system without > touching every single package, but it is pretty hackish and we had > constant issues where somebody would attempt an action using old common > content and stuff would fall over. > > Now we look at git. Git is for the most part a daemonless system. Each > repository is completely stand alone and generally does not require any > other infrastructure to be useful. You can interact with a repository > directly on the filesystem using /usr/bin/git or you can interact with > it through say ssh, again using /usr/bin/git (your local /usr/bin/git > will call a remote /usr/bin/git). Generally there is no running daemon > to connect to and authenticate with. Basic authentication of who can > check out what and commit where with git happens at the filesystem > permissions level. One twist with this is that with git, we wanted to > use real branches within a package repo to reflect the different > Fedora/EPEL releases. In repo branches are not reflected with path > names that we could set filesystem ACLs upon, so this posed a problem > for our conversion. > > Enter gitolite. Gitolite ( http://github.com/sitaramc/gitolite )is an > addon system to git that provides ACL functionality including different > rights for different branches within a given repository, and more! By > using gitolite as a replacement for /usr/bin/git when a user connects to > our git server we can again utilize the information we have within the > Fedora Package Database and properly allow / restrict changes on > specific branches for specific developers. The gitolite upstream ( > Sitaram Chamarty, sita...@atc.tcs.com ) has been fantastically > responsive to our needs, which are admittedly a little unique. We have > a very large set of repositories (over 10.5K) and a largish number of > contributors (1050). The combination of the two leads to a very very > large and complex ACL structure that at first broke the system quite > badly. Upstream was very quick to create a "bigconfig" method of > compiling the ACLs without crashing the box. Our other unique needs > involve having individual accounts for each committer instead of a > shared account with a large list of allowed SSH keys. Add to that some > of our accounts need to be able to ssh shell into the git server for > administrative duties. Throughout our trials and testing with gitolite > every time we've ran into some issue that just didn't fit the mold, > Sitaram has been there with a smile and a fix. At this point our > production server is a whopping one line different from current gitolite > upstream. This is a fantastic win for us, for our sustainability, and > for the next large group that wants to make use of gitolite. > > Once we had a plan for ACLs and for branches, we had to decide if we > were going to replace the Make system and with what. I had never been a > fan of Make, it was entirely too difficult to modify and innovate with. > Since I was the one pushing this transition forward, I decided to write > a new tool in my favorite language, python. The fedpkg tool was born > and took off. fedpkg was born around January 4th, 2010 and has since > grown into 1,523 (via sloccount) lines of code. While far from > complete, it is a great start (if I do say so myself!) at replacing the > make system. Because it is written in python (or maybe just !Make) it > seems to be easier to contribute to, and I've already gotten
Re: Integrity protection of fetches (Re: The move to git!)
On Wed, 2010-08-04 at 01:33 -0700, Matt McCutchen wrote: > On Tue, 2010-08-03 at 22:09 +, Ben Boeckel wrote: > > Matt McCutchen wrote: > > > No. If the attacker MITMs the entire connection, they can lie about the > > > values of the remote refs too, so there is no need to find a hash > > > collision. > > > > And how would you then be allowed to push? The git server would see that > > your history doesn't match the history it has and will refuse the > > commits. > > When the maintainer fetches, the attacker adds malicious commits on top > of the real remote ref value, and then the maintainer pushes those > commits as if he committed them himself. But IMNSHO, malicious > alteration of a fetch is something maintainers shouldn't have to deal > with, regardless of what the consequences might or might not be. > > (I should have changed the subject two round trips ago. Oh well...) I suspect it might short-circuit the 'ahhh, but what about...' 'oooh, but then I can...' nature of the conversation if you just put together a proof-of-concept attack and document it somewhere. I suspect the git maintainers might be interested at that point as well. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
Hi. On Wed, 04 Aug 2010 09:30:41 -0700, Adam Williamson wrote > Clearly Linus stood out even in his youth =) He is a bit obsessed with the number 5, though. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On Tue, 2010-08-03 at 11:29 -0400, Martin Langhoff wrote:
> On Tue, Aug 3, 2010 at 11:16 AM, Matt McCutchen
> wrote:
> > don't want malware landing on my machine because someone did a MITM
> > attack on a Fedora maintainer's unencrypted "git fetch" and inserted
> > some extra patches to get pushed back to the real repository later.
>
> The git protocol makes it extremely hard to inject malware
> successfully. It would have to match sha1, _and_ match resulting
> filesize _and_ be meaningful code, all without the benefits of
> preimaging.
>
> Even for crypto hashes that have been "broken" for a while, doing the
> above is a huge challenge.
>
> If you do consider this a real risk, here's someone who wants to want
> to play with you, and build a bunker, 5 miles underground...
> http://marc.info/?l=git&m=111375923219555&w=2
I have to say I was tickled by Linus' imagination of how five year olds
behave:
"That's not engineering. That's five-year-olds discussing building their
imaginary forts ("I want gun-turrets and a mechanical horse one mile
high, and my command center is 5 miles under-ground and totally encased
in 5 meters of lead")."
Clearly Linus stood out even in his youth =)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Integrity protection of fetches (Re: The move to git!)
On Tue, 2010-08-03 at 22:09 +, Ben Boeckel wrote: > Matt McCutchen wrote: > > No. If the attacker MITMs the entire connection, they can lie about the > > values of the remote refs too, so there is no need to find a hash > > collision. > > And how would you then be allowed to push? The git server would see that > your history doesn't match the history it has and will refuse the > commits. When the maintainer fetches, the attacker adds malicious commits on top of the real remote ref value, and then the maintainer pushes those commits as if he committed them himself. But IMNSHO, malicious alteration of a fetch is something maintainers shouldn't have to deal with, regardless of what the consequences might or might not be. (I should have changed the subject two round trips ago. Oh well...) -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
Matt McCutchen wrote: > No. If the attacker MITMs the entire connection, they can lie about the > values of the remote refs too, so there is no need to find a hash > collision. And how would you then be allowed to push? The git server would see that your history doesn't match the history it has and will refuse the commits. If they MITM your SSH push connection, I believe you have bigger fish to fry. --Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On Tue, 2010-08-03 at 11:29 -0400, Martin Langhoff wrote: > On Tue, Aug 3, 2010 at 11:16 AM, Matt McCutchen > wrote: > > don't want malware landing on my machine because someone did a MITM > > attack on a Fedora maintainer's unencrypted "git fetch" and inserted > > some extra patches to get pushed back to the real repository later. > > The git protocol makes it extremely hard to inject malware > successfully. It would have to match sha1, _and_ match resulting > filesize _and_ be meaningful code, all without the benefits of > preimaging. No. If the attacker MITMs the entire connection, they can lie about the values of the remote refs too, so there is no need to find a hash collision. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On Tue, Aug 3, 2010 at 11:16 AM, Matt McCutchen wrote: > don't want malware landing on my machine because someone did a MITM > attack on a Fedora maintainer's unencrypted "git fetch" and inserted > some extra patches to get pushed back to the real repository later. The git protocol makes it extremely hard to inject malware successfully. It would have to match sha1, _and_ match resulting filesize _and_ be meaningful code, all without the benefits of preimaging. Even for crypto hashes that have been "broken" for a while, doing the above is a huge challenge. If you do consider this a real risk, here's someone who wants to want to play with you, and build a bunker, 5 miles underground... http://marc.info/?l=git&m=111375923219555&w=2 :-) martin (formerly, a git hacker) -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On Fri, 2010-07-30 at 09:14 -0700, Josh Stone wrote: > A git trick I'd like fedpkg to learn is to use separate url/pushurl, > e.g. in .git/config: > > [remote "origin"] > fetch = +refs/heads/*:refs/remotes/origin/* > url = git://pkgs.fedoraproject.org/foo > pushurl = ssh://u...@pkgs.fedoraproject.org/foo > > This way it will fetch over the faster git protocol and still push over > ssh. I expect that will lessen the load on Fedora infrastructure too. The ssh:// URL does use the git protocol over ssh, so the git:// URL is only faster by the lack of encryption, which is hardly a good thing. I don't want malware landing on my machine because someone did a MITM attack on a Fedora maintainer's unencrypted "git fetch" and inserted some extra patches to get pushed back to the real repository later. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On Fri, Jul 30, 2010 at 2:17 PM, Matěj Cepl wrote: > Everybody was bitching about CVS for years, I'm pretty sure I wasn't. But I'll still pile on with a +1 for the switch over to git -jef"getting git to compile on qnx is no fun"spaleta -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On 08/02/2010 07:02 PM, Harald Hoyer wrote:
On 07/30/2010 08:13 PM, Jesse Keating wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/30/2010 08:52 AM, Daniel J Walsh wrote:
fedpkg build
fedpkg build
Traceback (most recent call last):
File "/usr/bin/fedpkg", line 959, in
args.command(args)
File "/usr/bin/fedpkg", line 297, in build
mymodule.init_koji(args.user, kojiconfig)
File "/usr/lib/python2.7/site-packages/pyfedpkg/__init__.py", line
1102, in init_koji
defaults['serverca'])
File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1628,
in ssl_login
sinfo = self.callMethod('sslLogin', proxyuser)
File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1673,
in callMethod
return self._callMethod(name, args, opts)
File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1698,
in _callMethod
return proxy.__getattr__(name)(*args)
File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
return self.__send(self.__name, args)
File "/usr/lib64/python2.7/xmlrpclib.py", line 1570, in __request
verbose=self.__verbose
File "/usr/lib64/python2.7/xmlrpclib.py", line 1264, in request
return self.single_request(host, handler, request_body, verbose)
File "/usr/lib64/python2.7/xmlrpclib.py", line 1294, in single_request
response = h.getresponse(buffering=True)
AttributeError: PlgHTTPS instance has no attribute 'getresponse'
[Exit 1]
Seems to be broken in Rawhide.
rpm -q fedora-packager
fedora-packager-0.5.1.0-1.fc14.noarch
Yeah, this is unfortunate, but something is broken in the xmlrpc stuff
in or around koji.
Any workaround, fix for that?
Here is one attached
diff -urN /usr/lib/python2.7/site-packages/koji/ssl/SSLConnection.py
/usr/lib/python2.7/site-packages/koji-bak/ssl/SSLConnection.py
--- /usr/lib/python2.7/site-packages/koji/ssl/SSLConnection.py 2010-07-09
04:04:26.0 +0200
+++ /usr/lib/python2.7/site-packages/koji-bak/ssl/SSLConnection.py
2010-08-02 19:39:00.0 +0200
@@ -63,7 +63,7 @@
c, a = self.__dict__["conn"].accept()
return (SSLConnection(c), a)
-def makefile(self, mode, bufsize):
+def makefile(self, mode='r', bufsize=-1):
"""
We need to use socket._fileobject Because SSL.Connection
doesn't have a 'dup'. Not exactly sure WHY this is, but
diff -urN /usr/lib/python2.7/site-packages/koji/ssl/XMLRPCServerProxy.py
/usr/lib/python2.7/site-packages/koji-bak/ssl/XMLRPCServerProxy.py
--- /usr/lib/python2.7/site-packages/koji/ssl/XMLRPCServerProxy.py
2010-07-09 04:04:26.0 +0200
+++ /usr/lib/python2.7/site-packages/koji-bak/ssl/XMLRPCServerProxy.py
2010-08-02 19:35:04.0 +0200
@@ -41,7 +41,7 @@
# Yay for Python 2.2
pass
_host, _port = urllib.splitport(host)
-self._https = SSLCommon.PlgHTTPS(_host, (_port and int(_port) or 443),
ssl_context=self.ssl_ctx, timeout=self._timeout)
+self._https = SSLCommon.PlgHTTPSConnection(_host, (_port and
int(_port) or 443), ssl_context=self.ssl_ctx, timeout=self._timeout)
return self._https
def close(self):
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On 07/30/2010 08:13 PM, Jesse Keating wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/30/2010 08:52 AM, Daniel J Walsh wrote:
>>
>> fedpkg build
>> fedpkg build
>> Traceback (most recent call last):
>>File "/usr/bin/fedpkg", line 959, in
>> args.command(args)
>>File "/usr/bin/fedpkg", line 297, in build
>> mymodule.init_koji(args.user, kojiconfig)
>>File "/usr/lib/python2.7/site-packages/pyfedpkg/__init__.py", line
>> 1102, in init_koji
>> defaults['serverca'])
>>File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1628,
>> in ssl_login
>> sinfo = self.callMethod('sslLogin', proxyuser)
>>File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1673,
>> in callMethod
>> return self._callMethod(name, args, opts)
>>File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1698,
>> in _callMethod
>> return proxy.__getattr__(name)(*args)
>>File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
>> return self.__send(self.__name, args)
>>File "/usr/lib64/python2.7/xmlrpclib.py", line 1570, in __request
>> verbose=self.__verbose
>>File "/usr/lib64/python2.7/xmlrpclib.py", line 1264, in request
>> return self.single_request(host, handler, request_body, verbose)
>>File "/usr/lib64/python2.7/xmlrpclib.py", line 1294, in single_request
>> response = h.getresponse(buffering=True)
>> AttributeError: PlgHTTPS instance has no attribute 'getresponse'
>> [Exit 1]
>>
>> Seems to be broken in Rawhide.
>>
>> rpm -q fedora-packager
>> fedora-packager-0.5.1.0-1.fc14.noarch
>
> Yeah, this is unfortunate, but something is broken in the xmlrpc stuff
> in or around koji.
>
Any workaround, fix for that?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On Fri, Jul 30, 2010 at 11:08:37AM +0100, pbrobin...@gmail.com wrote: > I think you need to get the latest package from koji so it points to > the live git repos and not the test ones. yes, the old version (which is still in F-12) uses pkgs.stg.fedoraproject.org, but the right URL is pkgs.fedoraproject.org (see "git config remote.origin.url" for more details). > I had similar issues when I > tested it first up but fedora-packager-0.5.1.0-1 seems to have fixed > it. yes Karel -- Karel Zak http://karelzak.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
Josh Stone writes: > A git trick I'd like fedpkg to learn is to use separate url/pushurl, > e.g. in .git/config: > > [remote "origin"] > fetch = +refs/heads/*:refs/remotes/origin/* > url = git://pkgs.fedoraproject.org/foo > pushurl = ssh://u...@pkgs.fedoraproject.org/foo Or more general: [url "ssh://pkgs.fedoraproject.org/"] pushinsteadof = git://pkgs.fedoraproject.org/ Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On Sun, Aug 1, 2010 at 1:12 PM, Andrea Musuruane wrote: > On Sun, Aug 1, 2010 at 1:05 PM, Dominic Hopf wrote: >> I just yesterday had similar problems and then found out my >> ~/.fedora.cert was out of date since five days ago. Maybe it's the same >> for you, did you already had a look there? :) > > Yes. It will be valid until Dec 7, 2010. It was the client side certificate. Although it was in its validity period it was no longer valid. Regards, Andrea. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On Sun, Aug 1, 2010 at 1:05 PM, Dominic Hopf wrote: > I just yesterday had similar problems and then found out my > ~/.fedora.cert was out of date since five days ago. Maybe it's the same > for you, did you already had a look there? :) Yes. It will be valid until Dec 7, 2010. Bye, Andrea. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
Am Sonntag, den 01.08.2010, 11:42 +0200 schrieb Andrea Musuruane: > On Sat, Jul 31, 2010 at 11:56 AM, Andrea Musuruane wrote: > > OK. I deleted the current repo and started again. I do have > > fedora-packager 0.5.1. > > > > Now fedora-packager crashes when uploading new sources. > > > > $ fedpkg clone zaz > > Cloning into zaz... > > [..] > > Resolving deltas: 100% (11/11), done. > > $ cd zaz/ > > $ cp -a ~/rpmbuild/SOURCES/zaz-0.8.0.tar.bz2 . > > $ cp -a ~/rpmbuild/SPECS/zaz.spec . > > $ fedpkg new-sources zaz-0.8.0.tar.bz2 > > Uploading: 6a63f986a80b4f4e1852ecf9871e9735 zaz-0.8.0.tar.bz2 > > Traceback (most recent call last): > > File "/usr/bin/fedpkg", line 959, in > >args.command(args) > > File "/usr/bin/fedpkg", line 540, in new_sources > >mymodule.upload(args.files, replace=args.replace) > > File "/usr/lib/python2.6/site-packages/pyfedpkg/__init__.py", line > > 1278, in upload > >if lookaside.file_exists(self.module, file_basename, file_hash): > > File "/usr/lib/python2.6/site-packages/pyfedpkg/__init__.py", line > > 580, in file_exists > >curl.perform() > > pycurl.error: (35, 'SSL connect error') > > [and...@panoramix zaz]$ > > I still have this error. Help is appreciated. I just yesterday had similar problems and then found out my ~/.fedora.cert was out of date since five days ago. Maybe it's the same for you, did you already had a look there? :) Best Regards, Dominic -- Dominic Hopf http://dominichopf.de/ Key Fingerprint: A7DF C4FC 07AE 4DDC 5CA0 BD93 AAB0 6019 CA7D 868D signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On Sat, Jul 31, 2010 at 11:56 AM, Andrea Musuruane wrote: > OK. I deleted the current repo and started again. I do have > fedora-packager 0.5.1. > > Now fedora-packager crashes when uploading new sources. > > $ fedpkg clone zaz > Cloning into zaz... > [..] > Resolving deltas: 100% (11/11), done. > $ cd zaz/ > $ cp -a ~/rpmbuild/SOURCES/zaz-0.8.0.tar.bz2 . > $ cp -a ~/rpmbuild/SPECS/zaz.spec . > $ fedpkg new-sources zaz-0.8.0.tar.bz2 > Uploading: 6a63f986a80b4f4e1852ecf9871e9735 zaz-0.8.0.tar.bz2 > Traceback (most recent call last): > File "/usr/bin/fedpkg", line 959, in > args.command(args) > File "/usr/bin/fedpkg", line 540, in new_sources > mymodule.upload(args.files, replace=args.replace) > File "/usr/lib/python2.6/site-packages/pyfedpkg/__init__.py", line > 1278, in upload > if lookaside.file_exists(self.module, file_basename, file_hash): > File "/usr/lib/python2.6/site-packages/pyfedpkg/__init__.py", line > 580, in file_exists > curl.perform() > pycurl.error: (35, 'SSL connect error') > [and...@panoramix zaz]$ I still have this error. Help is appreciated. Thanks. Andrea. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On Sat, Jul 31, 2010 at 11:50 AM, Rahul Sundaram wrote:
> On 07/31/2010 03:19 PM, Andrea Musuruane wrote:
>> l return(int(fedoras[-1].strip('f')) + 1)
>> IndexError: list index out of range
>>
>> Help is really appreciated.
>>
>> Thanks!
>
> make sure you update fedora-packager to 0.5.1, remove and clone the repo
> again and follow the same steps. It will work.
OK. I deleted the current repo and started again. I do have
fedora-packager 0.5.1.
Now fedora-packager crashes when uploading new sources.
$ fedpkg clone zaz
Cloning into zaz...
[..]
Resolving deltas: 100% (11/11), done.
$ cd zaz/
$ cp -a ~/rpmbuild/SOURCES/zaz-0.8.0.tar.bz2 .
$ cp -a ~/rpmbuild/SPECS/zaz.spec .
$ fedpkg new-sources zaz-0.8.0.tar.bz2
Uploading: 6a63f986a80b4f4e1852ecf9871e9735 zaz-0.8.0.tar.bz2
Traceback (most recent call last):
File "/usr/bin/fedpkg", line 959, in
args.command(args)
File "/usr/bin/fedpkg", line 540, in new_sources
mymodule.upload(args.files, replace=args.replace)
File "/usr/lib/python2.6/site-packages/pyfedpkg/__init__.py", line
1278, in upload
if lookaside.file_exists(self.module, file_basename, file_hash):
File "/usr/lib/python2.6/site-packages/pyfedpkg/__init__.py", line
580, in file_exists
curl.perform()
pycurl.error: (35, 'SSL connect error')
[and...@panoramix zaz]$
Regards,
Andrea.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On 07/31/2010 03:19 PM, Andrea Musuruane wrote:
> lreturn(int(fedoras[-1].strip('f')) + 1)
> IndexError: list index out of range
>
> Help is really appreciated.
>
> Thanks!
make sure you update fedora-packager to 0.5.1, remove and clone the repo
again and follow the same steps. It will work.
Rahul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
Hi all,
I do not know anything about GIT and I tried to follow this thread
and the Using_Fedora_GIT in the wiki to make my first commit
The workflow was more or less the following:
$ fedpkg clone zaz
$ cd zaz/
$ cp -a ~/rpmbuild/SOURCES/zaz-0.8.0.tar.bz2 .
$ cp -a ~/rpmbuild/SPECS/zaz.spec .
$ fedpkg new-sources zaz-0.8.0.tar.bz2
$ git diff
$ git config --global --add push.default tracking
$ fedpkg clog
$ fedpkg commit -F clog -p
I tried to use federa-packager available from updates. "fedpkg commit
-F clog -p" did not succeed.
Then I installed the latest federa-packager from updates-testing and
"fedpkg commit -F clog -p" now crashes. It even crashes with "fedpkg
clog". The error is the same.
$ fedpkg clog
Traceback (most recent call last):
File "/usr/bin/fedpkg", line 959, in
args.command(args)
File "/usr/bin/fedpkg", line 390, in clog
mymodule = pyfedpkg.PackageModule(args.path)
File "/usr/lib/python2.6/site-packages/pyfedpkg/__init__.py", line
744, in __init__
self.distval = self._findmasterbranch()
File "/usr/lib/python2.6/site-packages/pyfedpkg/__init__.py", line
694, in _findmasterbranch
return(int(fedoras[-1].strip('f')) + 1)
IndexError: list index out of range
Help is really appreciated.
Thanks!
Andrea.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
Dne 30.7.2010 09:48, Phil Knirsch napsal(a): > I only have 2 words for you and everyone who has put so insanely much > work into this effort for such a long time: > >T H A N K Y O U ! Everybody was bitching about CVS for years, so now we all should say to this +1000 Thank you -- There is no reason to suppose that most human beings are engaged in maximizing anything unless it be unhappiness, and even this with incomplete success. -- Ronald Coase Introduction to ``The Firm, the Market, and the Law'' -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On 07/30/2010 03:02 PM, Jon Ciesla wrote: > On 7/29/2010 10:55 PM, Jesse Keating wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> This evening we opened up dist-git for business. Dist-git is our git >> based replacement for dist-cvs, the source control system we were using >> for our package specs, patches, and source files. This has been a long >> time coming and a massive effort. I want to take a little time here to >> outline what we've done and where we are going. >> >> First a brief outline of how our CVS system worked. CVS is a daemon of >> sorts, and all repos typically live within a single CVSROOT. Within >> this CVSROOT we had an 'avail' system to make use of, that we could >> populate with data from Fedora Account System and dump into this file. >> Avail worked on path names, relative to the CVSROOT. Since we used >> directories for each Fedora release as pseudo branches we could set >> avail info on each release "branch". CVS also used some filesystem >> symlink tricks to create a "common" subdir for every package module, and >> this is where we stuffed common scripts and Makefile content. Pretty >> clever on one hand, we can make updates to the make system without >> touching every single package, but it is pretty hackish and we had >> constant issues where somebody would attempt an action using old common >> content and stuff would fall over. >> >> Now we look at git. Git is for the most part a daemonless system. Each >> repository is completely stand alone and generally does not require any >> other infrastructure to be useful. You can interact with a repository >> directly on the filesystem using /usr/bin/git or you can interact with >> it through say ssh, again using /usr/bin/git (your local /usr/bin/git >> will call a remote /usr/bin/git). Generally there is no running daemon >> to connect to and authenticate with. Basic authentication of who can >> check out what and commit where with git happens at the filesystem >> permissions level. One twist with this is that with git, we wanted to >> use real branches within a package repo to reflect the different >> Fedora/EPEL releases. In repo branches are not reflected with path >> names that we could set filesystem ACLs upon, so this posed a problem >> for our conversion. >> >> Enter gitolite. Gitolite ( http://github.com/sitaramc/gitolite )is an >> addon system to git that provides ACL functionality including different >> rights for different branches within a given repository, and more! By >> using gitolite as a replacement for /usr/bin/git when a user connects to >> our git server we can again utilize the information we have within the >> Fedora Package Database and properly allow / restrict changes on >> specific branches for specific developers. The gitolite upstream ( >> Sitaram Chamarty, sita...@atc.tcs.com ) has been fantastically >> responsive to our needs, which are admittedly a little unique. We have >> a very large set of repositories (over 10.5K) and a largish number of >> contributors (1050). The combination of the two leads to a very very >> large and complex ACL structure that at first broke the system quite >> badly. Upstream was very quick to create a "bigconfig" method of >> compiling the ACLs without crashing the box. Our other unique needs >> involve having individual accounts for each committer instead of a >> shared account with a large list of allowed SSH keys. Add to that some >> of our accounts need to be able to ssh shell into the git server for >> administrative duties. Throughout our trials and testing with gitolite >> every time we've ran into some issue that just didn't fit the mold, >> Sitaram has been there with a smile and a fix. At this point our >> production server is a whopping one line different from current gitolite >> upstream. This is a fantastic win for us, for our sustainability, and >> for the next large group that wants to make use of gitolite. >> >> Once we had a plan for ACLs and for branches, we had to decide if we >> were going to replace the Make system and with what. I had never been a >> fan of Make, it was entirely too difficult to modify and innovate with. >>Since I was the one pushing this transition forward, I decided to write >> a new tool in my favorite language, python. The fedpkg tool was born >> and took off. fedpkg was born around January 4th, 2010 and has since >> grown into 1,523 (via sloccount) lines of code. While far from >> complete, it is a great start (if I do say so myself!) at replacing the >> make system. Because it is written in python (or maybe just !Make) it >> seems to be easier to contribute to, and I've already gotten a number of >> contributions. More will come as it starts to be more widely used. The >> biggest challenge with fedpkg is removing the need to update something >> on the end user's system every single time we added a new Fedora release >> and changed what happens when you build for rawhide. I'll sp
Re: The move to git!
On 7/29/2010 10:55 PM, Jesse Keating wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > This evening we opened up dist-git for business. Dist-git is our git > based replacement for dist-cvs, the source control system we were using > for our package specs, patches, and source files. This has been a long > time coming and a massive effort. I want to take a little time here to > outline what we've done and where we are going. > > First a brief outline of how our CVS system worked. CVS is a daemon of > sorts, and all repos typically live within a single CVSROOT. Within > this CVSROOT we had an 'avail' system to make use of, that we could > populate with data from Fedora Account System and dump into this file. > Avail worked on path names, relative to the CVSROOT. Since we used > directories for each Fedora release as pseudo branches we could set > avail info on each release "branch". CVS also used some filesystem > symlink tricks to create a "common" subdir for every package module, and > this is where we stuffed common scripts and Makefile content. Pretty > clever on one hand, we can make updates to the make system without > touching every single package, but it is pretty hackish and we had > constant issues where somebody would attempt an action using old common > content and stuff would fall over. > > Now we look at git. Git is for the most part a daemonless system. Each > repository is completely stand alone and generally does not require any > other infrastructure to be useful. You can interact with a repository > directly on the filesystem using /usr/bin/git or you can interact with > it through say ssh, again using /usr/bin/git (your local /usr/bin/git > will call a remote /usr/bin/git). Generally there is no running daemon > to connect to and authenticate with. Basic authentication of who can > check out what and commit where with git happens at the filesystem > permissions level. One twist with this is that with git, we wanted to > use real branches within a package repo to reflect the different > Fedora/EPEL releases. In repo branches are not reflected with path > names that we could set filesystem ACLs upon, so this posed a problem > for our conversion. > > Enter gitolite. Gitolite ( http://github.com/sitaramc/gitolite )is an > addon system to git that provides ACL functionality including different > rights for different branches within a given repository, and more! By > using gitolite as a replacement for /usr/bin/git when a user connects to > our git server we can again utilize the information we have within the > Fedora Package Database and properly allow / restrict changes on > specific branches for specific developers. The gitolite upstream ( > Sitaram Chamarty, sita...@atc.tcs.com ) has been fantastically > responsive to our needs, which are admittedly a little unique. We have > a very large set of repositories (over 10.5K) and a largish number of > contributors (1050). The combination of the two leads to a very very > large and complex ACL structure that at first broke the system quite > badly. Upstream was very quick to create a "bigconfig" method of > compiling the ACLs without crashing the box. Our other unique needs > involve having individual accounts for each committer instead of a > shared account with a large list of allowed SSH keys. Add to that some > of our accounts need to be able to ssh shell into the git server for > administrative duties. Throughout our trials and testing with gitolite > every time we've ran into some issue that just didn't fit the mold, > Sitaram has been there with a smile and a fix. At this point our > production server is a whopping one line different from current gitolite > upstream. This is a fantastic win for us, for our sustainability, and > for the next large group that wants to make use of gitolite. > > Once we had a plan for ACLs and for branches, we had to decide if we > were going to replace the Make system and with what. I had never been a > fan of Make, it was entirely too difficult to modify and innovate with. > Since I was the one pushing this transition forward, I decided to write > a new tool in my favorite language, python. The fedpkg tool was born > and took off. fedpkg was born around January 4th, 2010 and has since > grown into 1,523 (via sloccount) lines of code. While far from > complete, it is a great start (if I do say so myself!) at replacing the > make system. Because it is written in python (or maybe just !Make) it > seems to be easier to contribute to, and I've already gotten a number of > contributions. More will come as it starts to be more widely used. The > biggest challenge with fedpkg is removing the need to update something > on the end user's system every single time we added a new Fedora release > and changed what happens when you build for rawhide. I'll spare you the > details but I'm fairly happy with what we have. The end result should > be far fewer misfires and end user
Re: The move to git!
On Fri, 2010-07-30 at 10:42 -0700, Jesse Keating wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/30/2010 02:13 AM, Martin Sourada wrote: > > Ok, so trying to update a package (libass) I've noticed a tiny problem: > > the fedpkg switch-branch does not seem to set up proper tracking of > > remote branches which then results in (uhm, I'm using git commit -a and > > git push, so you maybe handle this in fedpkg commit -p): > > > > pyfedpkg.FedpkgError: There are unpushed changes in your repo > > > > fedora-packager-0.5.0.1-3.fc12.noarch > > This is my fault, I did all my design and testing with a git setting of > "push.default tracking" which instructs git to "push" to whatever branch > I'm tracking (which makes perfect sense to me, why isn't it a defaut?). This is probably for historical reasons. Apparently (from what I've quickly googled up) the only behaviour in older git was to push *all* matching branches (not sure how it decides it's matching, but probably it's 'merge' in branch config + same name), but newer git has more options[1]: 'nothing' : Do not push anything 'matching' : Push all matching branches (default) 'tracking' : Push the current branch to whatever it is tracking 'current' : Push the current branch while defaulting (as hinted above) to the old behaviour. Martin References: [1] http://pivotallabs.com/users/alex/blog/articles/883-git-config-push-default-matching signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On 07/30/2010 11:36 AM, Hans Ulrich Niedermann wrote: > On Fri, 2010-07-30 at 11:15 -0700, Jesse Keating wrote: >> On 07/30/2010 09:14 AM, Josh Stone wrote: >>> A git trick I'd like fedpkg to learn is to use separate url/pushurl, >>> e.g. in .git/config: >>> >>> [remote "origin"] >>> fetch = +refs/heads/*:refs/remotes/origin/* >>> url = git://pkgs.fedoraproject.org/foo >>> pushurl = ssh://u...@pkgs.fedoraproject.org/foo >>> >>> This way it will fetch over the faster git protocol and still push over >>> ssh. I expect that will lessen the load on Fedora infrastructure too. > >> Hrm, not sure this is something we should do by default, are there any >> drawbacks? > > You need two network protocols to do work on the package. That might be > difficult in some restricted networks. Good point, I didn't think of that. > For everyone with actual proper internet access, this looks like it > could work quite well. It's quite an improvement for me on other projects. For now I've made that change manually in my fedpkg checkout. If we don't make this by default, perhaps it could still be a command-line option or a ~/.fedpkgrc entry. Josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On Fri, 2010-07-30 at 11:15 -0700, Jesse Keating wrote: > On 07/30/2010 09:14 AM, Josh Stone wrote: > > A git trick I'd like fedpkg to learn is to use separate url/pushurl, > > e.g. in .git/config: > > > > [remote "origin"] > > fetch = +refs/heads/*:refs/remotes/origin/* > > url = git://pkgs.fedoraproject.org/foo > > pushurl = ssh://u...@pkgs.fedoraproject.org/foo > > > > This way it will fetch over the faster git protocol and still push over > > ssh. I expect that will lessen the load on Fedora infrastructure too. > Hrm, not sure this is something we should do by default, are there any > drawbacks? You need two network protocols to do work on the package. That might be difficult in some restricted networks. For everyone with actual proper internet access, this looks like it could work quite well. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/30/2010 01:49 AM, pbrobin...@gmail.com wrote: > One thing I've never got around to working out how to do in git which > is different from previous is dealing with branches. Where previously > it was as simple as changing directories to deal with the various > fedora releases obviously with real branches now we need to do > something a little differnet. Could someone update the docs with > details how to do this? I retried "fedpkg switch-branch f-13" (and > various other possible branch names) and using a "git branch" didn't > give me any branches other than master. Could we also add some extra > branch related commands to indicate things like listing the current > branch, a list of all branches, and how we would commit a new spec to > more than one branch. https://fedoraproject.org/wiki/Using_Fedora_GIT#Merging is a good start for this, and eventually we'll have tooling in fedpkg to facilitate things like this. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxTDqkACgkQ4v2HLvE71NUESgCeKZ05rd4GWbes5FlBixhxej+Q oTkAn1wjRrIQqJcRK7x/JPvnsQLP0XII =YOf1 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/30/2010 10:53 AM, Konstantin Ryabitsev wrote: > On Fri, Jul 30, 2010 at 1:35 PM, Konstantin Ryabitsev > wrote: >> Hmm... Doesn't seem to be working at all for me. >> >> $ fedpkg co verbiste >> Traceback (most recent call last): >> File "/usr/bin/fedpkg", line 959, in >>args.command(args) >> File "/usr/bin/fedpkg", line 409, in clone >>pyfedpkg.clone(args.module[0], args.user, args.path, args.branch) >> File "/usr/lib/python2.6/site-packages/pyfedpkg/__init__.py", line >> 302, in clone >>_run_command(cmd) >> File "/usr/lib/python2.6/site-packages/pyfedpkg/__init__.py", line >> 115, in _run_command >>stderr=sys.stderr, shell=shell) >> File "/usr/lib64/python2.6/subprocess.py", line 483, in check_call >>retcode = call(*popenargs, **kwargs) >> File "/usr/lib64/python2.6/subprocess.py", line 470, in call >>return Popen(*popenargs, **kwargs).wait() >> File "/usr/lib64/python2.6/subprocess.py", line 621, in __init__ >>errread, errwrite) >> File "/usr/lib64/python2.6/subprocess.py", line 1126, in _execute_child >>raise child_exception >> OSError: [Errno 2] No such file or directory >> $ rpm -q fedora-packager >> fedora-packager-0.5.1.0-1.fc13.noarch > > Ah, as silly as it was, I didn't actually check whether git was > installed -- I rather assumed it would be as a dependency. Everything > works after actually installing git (though it's still a bug in > fedora-packager deps). > > Regards, Hrm, this is actually a bug in GitPython. It needs to depend on /usr/bin/git. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxTFvoACgkQ4v2HLvE71NVW9wCgpA0QFI/ta3ErcOIwVWP9AOAr efkAnjf0tGG4mAadskt5wl0sTidW =HQ90 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/30/2010 09:14 AM, Josh Stone wrote: > Thanks for dist-git -- one step closer to banishing CVS from my life! :) > > A git trick I'd like fedpkg to learn is to use separate url/pushurl, > e.g. in .git/config: > > [remote "origin"] > fetch = +refs/heads/*:refs/remotes/origin/* > url = git://pkgs.fedoraproject.org/foo > pushurl = ssh://u...@pkgs.fedoraproject.org/foo > > This way it will fetch over the faster git protocol and still push over > ssh. I expect that will lessen the load on Fedora infrastructure too. > > Thanks! > > Josh Hrm, not sure this is something we should do by default, are there any drawbacks? - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxTFroACgkQ4v2HLvE71NXnlgCfQc2y0CIS5Y2F8AWFYZFXBv1+ DwsAn23WIs7v95bup6yEVABogZtUpOsW =YAoa -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
Am 30.07.10 10:02, schrieb Michal Hlavinka: > Thanks for your hard work! Could you describe this in more > details: > OLD CVS | NEW GIT | Notes > make tag | N/A | Explicitly tagging > source states for package builds is no longer necessary. > > how this exactly Each commit has an unique number in git. If you submit an build to koji, this unique number wil be transmitted to koji. So you can be sure, that koji use your personally HEAD even another people has done a push to mein repository. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/30/2010 08:52 AM, Daniel J Walsh wrote:
>
> fedpkg build
> fedpkg build
> Traceback (most recent call last):
> File "/usr/bin/fedpkg", line 959, in
> args.command(args)
> File "/usr/bin/fedpkg", line 297, in build
> mymodule.init_koji(args.user, kojiconfig)
> File "/usr/lib/python2.7/site-packages/pyfedpkg/__init__.py", line
> 1102, in init_koji
> defaults['serverca'])
> File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1628,
> in ssl_login
> sinfo = self.callMethod('sslLogin', proxyuser)
> File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1673,
> in callMethod
> return self._callMethod(name, args, opts)
> File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1698,
> in _callMethod
> return proxy.__getattr__(name)(*args)
> File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
> return self.__send(self.__name, args)
> File "/usr/lib64/python2.7/xmlrpclib.py", line 1570, in __request
> verbose=self.__verbose
> File "/usr/lib64/python2.7/xmlrpclib.py", line 1264, in request
> return self.single_request(host, handler, request_body, verbose)
> File "/usr/lib64/python2.7/xmlrpclib.py", line 1294, in single_request
> response = h.getresponse(buffering=True)
> AttributeError: PlgHTTPS instance has no attribute 'getresponse'
> [Exit 1]
>
> Seems to be broken in Rawhide.
>
> rpm -q fedora-packager
> fedora-packager-0.5.1.0-1.fc14.noarch
Yeah, this is unfortunate, but something is broken in the xmlrpc stuff
in or around koji.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxTFj0ACgkQ4v2HLvE71NVI8wCeP1Dlv4oVg6fM6lCsKwIiS6+z
cLcAoJ1ArFu/cICQzh9uxzCZIJcT/yV0
=St51
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/30/2010 01:02 AM, Michal Hlavinka wrote: > On Friday 30 of July 2010 05:55:09 Jesse Keating wrote: >> ... Wiki >> pages > will get filled out as knowledge of how to interact with dist-git >> starts > to spread ( https://fedoraproject.org/wiki/Using_Fedora_GIT is a >> good > start ). > > Thanks for your hard work! Could you describe this in more > details: > OLD CVS | NEW GIT | Notes > make tag | N/A | Explicitly tagging > source states for package builds is no longer necessary. > > how this exactly > works? What will happen in following cases? : > 1) commit some changes with > release number change, commit another changes, build The build attempt will use the latest content you pushed. If you've previously built something with that n-v-r the buildsystem will reject the build, otherwise it'll continue. > > 2) commit some changes > with release number change, scratch build, commit rest of the changes, > build See above, the build would happen. > > 3) commit some changes with release number change, someone else > starts build, commit rest of the changes, build The buildsystem will reject the build because one with the same n-v-r is either in progress or completed successfully. > > 4) commit some changes with > release number change, build - fails because of typo/missing updated > sources, commit fix, build Build will go through because there are no successful builds with that n-v-r > > Michal - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxTDI0ACgkQ4v2HLvE71NW+iACgkE2cIycWxBxbhVWia1ynIrKT 5xAAoKfpYdgxwlF3P3yx62SVccAMNVgW =E9/3 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On Thu, Jul 29, 2010 at 11:55 PM, Jesse Keating wrote: > Once again I want to thank everybody who helped out and for all the > (continued) patience! I'll be available via email and IRC as much as > possible the next few days to help anybody with dist-git issues. Look > for Oxf13 on freenode. Happy gitting! Hmm... Doesn't seem to be working at all for me. $ fedpkg co verbiste Traceback (most recent call last): File "/usr/bin/fedpkg", line 959, in args.command(args) File "/usr/bin/fedpkg", line 409, in clone pyfedpkg.clone(args.module[0], args.user, args.path, args.branch) File "/usr/lib/python2.6/site-packages/pyfedpkg/__init__.py", line 302, in clone _run_command(cmd) File "/usr/lib/python2.6/site-packages/pyfedpkg/__init__.py", line 115, in _run_command stderr=sys.stderr, shell=shell) File "/usr/lib64/python2.6/subprocess.py", line 483, in check_call retcode = call(*popenargs, **kwargs) File "/usr/lib64/python2.6/subprocess.py", line 470, in call return Popen(*popenargs, **kwargs).wait() File "/usr/lib64/python2.6/subprocess.py", line 621, in __init__ errread, errwrite) File "/usr/lib64/python2.6/subprocess.py", line 1126, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory $ rpm -q fedora-packager fedora-packager-0.5.1.0-1.fc13.noarch Do I need to run anything before I can use fedpkg? I couldn't find anything about configuration files on the Using_Fedora_GIT wiki page. I filed it as https://bugzilla.redhat.com/show_bug.cgi?id=619763 Regards, -- McGill University IT Security Konstantin "Kay" Ryabitsev Montréal, Québec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/30/2010 02:13 AM, Martin Sourada wrote: > Ok, so trying to update a package (libass) I've noticed a tiny problem: > the fedpkg switch-branch does not seem to set up proper tracking of > remote branches which then results in (uhm, I'm using git commit -a and > git push, so you maybe handle this in fedpkg commit -p): > > pyfedpkg.FedpkgError: There are unpushed changes in your repo > > fedora-packager-0.5.0.1-3.fc12.noarch This is my fault, I did all my design and testing with a git setting of "push.default tracking" which instructs git to "push" to whatever branch I'm tracking (which makes perfect sense to me, why isn't it a defaut?). Until fedpkg takes this into account, it's easiest to just do: git config --global --add push.default tracking Then you can easily push (and pull) from fedpkg switch-branch setups. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxTDxwACgkQ4v2HLvE71NUAiACcCK8OsJWHs2y43ikmiIwMrEt3 vJcAoKYqDJz9MeEDB1ocPPl8aG7X9Lvy =xKCB -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/30/2010 05:43 AM, Miroslav Suchý wrote: > On 07/30/2010 05:55 AM, Jesse Keating wrote: >> starts to spread ( https://fedoraproject.org/wiki/Using_Fedora_GIT is a >> good start ). > > I made: > > fedpkg clone python-debian > cd python-debian > fedpkg switch-branch f14 > edit spec file > fedpkg commit -m 'edit changelog entry' -p > fedpkg push > > And the last thep did not updated that remote branch. > I had to manualy run: > > git push origin f14:f14/master > > which done what I really wanted. This is bug or I done something wrong? One part bug, one part user configuration. If you do "git config --add --global push.default tracking" then fedpkg push would do as you expect. I need to make fedpkg push work regardless of that local setting. > > Additionaly: how the new tags in git are going to appear. Is is supposed > to create fedpkg? Or should I manually create it using "git tag" and > "git push --tags"? You don't need tags to build anymore, so fedpkg doesn't do anything with them at this point. > > > And btw: Thx. Big thx. Now I can really see what I did, which was in cvs > impossible (at least with my level of laziness). > - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxTEj4ACgkQ4v2HLvE71NVMOwCfUdU/WInufz8ocXbWp/AL6ROf H9cAnioqaFCKemfCIrBljDFJAWq/8rrS =dd7q -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On Fri, Jul 30, 2010 at 1:35 PM, Konstantin Ryabitsev wrote: > Hmm... Doesn't seem to be working at all for me. > > $ fedpkg co verbiste > Traceback (most recent call last): > File "/usr/bin/fedpkg", line 959, in > args.command(args) > File "/usr/bin/fedpkg", line 409, in clone > pyfedpkg.clone(args.module[0], args.user, args.path, args.branch) > File "/usr/lib/python2.6/site-packages/pyfedpkg/__init__.py", line > 302, in clone > _run_command(cmd) > File "/usr/lib/python2.6/site-packages/pyfedpkg/__init__.py", line > 115, in _run_command > stderr=sys.stderr, shell=shell) > File "/usr/lib64/python2.6/subprocess.py", line 483, in check_call > retcode = call(*popenargs, **kwargs) > File "/usr/lib64/python2.6/subprocess.py", line 470, in call > return Popen(*popenargs, **kwargs).wait() > File "/usr/lib64/python2.6/subprocess.py", line 621, in __init__ > errread, errwrite) > File "/usr/lib64/python2.6/subprocess.py", line 1126, in _execute_child > raise child_exception > OSError: [Errno 2] No such file or directory > $ rpm -q fedora-packager > fedora-packager-0.5.1.0-1.fc13.noarch Ah, as silly as it was, I didn't actually check whether git was installed -- I rather assumed it would be as a dependency. Everything works after actually installing git (though it's still a bug in fedora-packager deps). Regards, -- McGill University IT Security Konstantin "Kay" Ryabitsev Montréal, Québec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/30/2010 03:06 AM, Peter Lemenkov wrote: > Great news! > > Few questions still remains unanswered for me: > > * Should I use git now? Yes. > * May I still use cvs? read-only > * If I'll add some changes right now using git/cvs will they be > available in cvs/git respectively? You won't be able to add anything to cvs, so use git. > * I just noticed that some freshly cloned git repositories are about > one month old (namely, couchdb) - do I need to wait until final > synchronization before using git for them? > You need a newer fedora-packager. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxTEU8ACgkQ4v2HLvE71NVKPgCfUqH0hUwZfc7mjG3yppgKkA/M 1z0An3nuPXO2LM1chg6QvNxQLOX9xPKU =dDbT -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
Thanks for dist-git -- one step closer to banishing CVS from my life! :) A git trick I'd like fedpkg to learn is to use separate url/pushurl, e.g. in .git/config: [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = git://pkgs.fedoraproject.org/foo pushurl = ssh://u...@pkgs.fedoraproject.org/foo This way it will fetch over the faster git protocol and still push over ssh. I expect that will lessen the load on Fedora infrastructure too. Thanks! Josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
fedpkg build
fedpkg build
Traceback (most recent call last):
File "/usr/bin/fedpkg", line 959, in
args.command(args)
File "/usr/bin/fedpkg", line 297, in build
mymodule.init_koji(args.user, kojiconfig)
File "/usr/lib/python2.7/site-packages/pyfedpkg/__init__.py", line
1102, in init_koji
defaults['serverca'])
File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1628,
in ssl_login
sinfo = self.callMethod('sslLogin', proxyuser)
File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1673,
in callMethod
return self._callMethod(name, args, opts)
File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1698,
in _callMethod
return proxy.__getattr__(name)(*args)
File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
return self.__send(self.__name, args)
File "/usr/lib64/python2.7/xmlrpclib.py", line 1570, in __request
verbose=self.__verbose
File "/usr/lib64/python2.7/xmlrpclib.py", line 1264, in request
return self.single_request(host, handler, request_body, verbose)
File "/usr/lib64/python2.7/xmlrpclib.py", line 1294, in single_request
response = h.getresponse(buffering=True)
AttributeError: PlgHTTPS instance has no attribute 'getresponse'
[Exit 1]
Seems to be broken in Rawhide.
rpm -q fedora-packager
fedora-packager-0.5.1.0-1.fc14.noarch
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxS9VUACgkQrlYvE4MpobPWaACfSyntisid01Rt8hiTwyqaisCp
QB0Anj0/s6nZsU8P7lFCWziAXvbz2f5S
=fUJe
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On Fri, Jul 30, 2010 at 16:18, Stanislav Ochotnicky wrote: > Excerpts from Christof Damian's message of Fri Jul 30 16:10:44 +0200 2010: >> I am trying to update one of my packages with git for the first time. >> Works good, but "fedpkg build" fails for me. >> >> It complains that it can't retrieve the sources: >> http://koji.stg.fedoraproject.org/koji/getfile?taskID=2239266&name=root.log&offset=-4000 > > Your fedora-packager package is too old. Install version 0.5.x (from > koji, but should be available in the repos now too I believe) That did the trick. I got fedora-packager-0.5.1.0-1.fc13.noarch from updates testing. Cheers, Christof -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
Rahul Sundaram wrote: > FYI, git-svn is for users who want to continue to use Subversion on > the server but interact using Git from clients. It is not a tool > for conversion. It is a common mistake. Not so much. Many folks use git-svn to convert from svn to git. Once you have cloned an svn repo with git-svn, you can simply publish the git repo and use it as your new upstream repo. I converted the upstream libgpod and gtkpod repositories this way. -- ToddOpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ An optimist believes we live in the best of all possible worlds. A pessimist is sure of it! pgpHrSdxtJR6f.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
Excerpts from Christof Damian's message of Fri Jul 30 16:10:44 +0200 2010: > I am trying to update one of my packages with git for the first time. > Works good, but "fedpkg build" fails for me. > > It complains that it can't retrieve the sources: > http://koji.stg.fedoraproject.org/koji/getfile?taskID=2239266&name=root.log&offset=-4000 Your fedora-packager package is too old. Install version 0.5.x (from koji, but should be available in the repos now too I believe) -- Stanislav Ochotnicky Associate Software Engineer - Base Operating Systems Brno PGP: 71A1677C Red Hat Inc. http://cz.redhat.com signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
Many thanks! -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
I am trying to update one of my packages with git for the first time. Works good, but "fedpkg build" fails for me. It complains that it can't retrieve the sources: http://koji.stg.fedoraproject.org/koji/getfile?taskID=2239266&name=root.log&offset=-4000 When I open the URL open with firefox/curl they work and the file is the correct one. Is there any reason why the build system can't access http://cvs.fedoraproject.org/repo/pkgs/php-pdepend-PHP-Depend/PHP_Depend-0.9.17.tgz/12c96a8d86b446e9005e7cb6b1145960/PHP_Depend-0.9.17.tgz ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On 07/30/2010 02:43 PM, Miroslav Suchý wrote: > On 07/30/2010 05:55 AM, Jesse Keating wrote: >> starts to spread ( https://fedoraproject.org/wiki/Using_Fedora_GIT is a >> good start ). > > I made: > > fedpkg clone python-debian > cd python-debian > fedpkg switch-branch f14 >edit spec file > fedpkg commit -m 'edit changelog entry' -p > fedpkg push > > And the last thep did not updated that remote branch. > I had to manualy run: > > git push origin f14:f14/master > or if you have tracking branch `git push origin HEAD' > which done what I really wanted. This is bug or I done something wrong? > > Additionaly: how the new tags in git are going to appear. Is is supposed > to create fedpkg? Or should I manually create it using "git tag" and > "git push --tags"? > > > And btw: Thx. Big thx. Now I can really see what I did, which was in cvs > impossible (at least with my level of laziness). > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On 07/30/2010 05:55 AM, Jesse Keating wrote: > starts to spread ( https://fedoraproject.org/wiki/Using_Fedora_GIT is a > good start ). I made: fedpkg clone python-debian cd python-debian fedpkg switch-branch f14 edit spec file fedpkg commit -m 'edit changelog entry' -p fedpkg push And the last thep did not updated that remote branch. I had to manualy run: git push origin f14:f14/master which done what I really wanted. This is bug or I done something wrong? Additionaly: how the new tags in git are going to appear. Is is supposed to create fedpkg? Or should I manually create it using "git tag" and "git push --tags"? And btw: Thx. Big thx. Now I can really see what I did, which was in cvs impossible (at least with my level of laziness). -- Miroslav Suchy Red Hat Satellite Engineering -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On Fri, Jul 30, 2010 at 11:18, Rahul Sundaram wrote: > On 07/30/2010 02:44 PM, Christof Damian wrote: >> Thank you for all the work. >> >> I am currently in the process of convincing my employer to change from >> svn to git and know how much work this is. Running git-svn clone alone >> takes a few weeks for us. > > FYI, git-svn is for users who want to continue to use Subversion on the > server but interact using Git from clients. It is not a tool for > conversion. It is a common mistake. I know, I have used different tools too. But git-svn deals best with our set-up and it allows incremental syncs which I need at the moment. The others are usually for one-off conversions. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On Fri, Jul 30, 2010 at 11:06 AM, Peter Lemenkov wrote: > Great news! > > Few questions still remains unanswered for me: > > * Should I use git now? > * May I still use cvs? > * If I'll add some changes right now using git/cvs will they be > available in cvs/git respectively? > * I just noticed that some freshly cloned git repositories are about > one month old (namely, couchdb) - do I need to wait until final > synchronization before using git for them? I think you need to get the latest package from koji so it points to the live git repos and not the test ones. I had similar issues when I tested it first up but fedora-packager-0.5.1.0-1 seems to have fixed it. I believe its all git now and cvs is read only. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
Great news! Few questions still remains unanswered for me: * Should I use git now? * May I still use cvs? * If I'll add some changes right now using git/cvs will they be available in cvs/git respectively? * I just noticed that some freshly cloned git repositories are about one month old (namely, couchdb) - do I need to wait until final synchronization before using git for them? -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
2010/7/30 Martin Sourada : > On Fri, 2010-07-30 at 09:49 +0100, pbrobin...@gmail.com wrote: >> Excellent news! Thanks for all the work. >> >> One thing I've never got around to working out how to do in git which >> is different from previous is dealing with branches. Where previously >> it was as simple as changing directories to deal with the various >> fedora releases obviously with real branches now we need to do >> something a little differnet. Could someone update the docs with >> details how to do this? I retried "fedpkg switch-branch f-13" (and >> various other possible branch names) and using a "git branch" didn't >> give me any branches other than master. Could we also add some extra >> branch related commands to indicate things like listing the current >> branch, a list of all branches, and how we would commit a new spec to >> more than one branch. >> > I'm not sure how it works if you do "fedpkg clone -B libfoo", but > probably similar to the CVS setup. If you do just "fedpkg clone" the > branches are managed in git only so the "fedpkg switch-branch f13" > indeed switches you to f13 branch even though it looks like master ;-) > > Personally I use "git merge " to sync the branches > (if I have same spec for more than one branch). > I think using git merge or git cherry-pick will be better than coping files from other branch like cvs, git is much smarter than cvs. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On Fri, 2010-07-30 at 09:49 +0100, pbrobin...@gmail.com wrote: > Excellent news! Thanks for all the work. > > One thing I've never got around to working out how to do in git which > is different from previous is dealing with branches. Where previously > it was as simple as changing directories to deal with the various > fedora releases obviously with real branches now we need to do > something a little differnet. Could someone update the docs with > details how to do this? I retried "fedpkg switch-branch f-13" (and > various other possible branch names) and using a "git branch" didn't > give me any branches other than master. Could we also add some extra > branch related commands to indicate things like listing the current > branch, a list of all branches, and how we would commit a new spec to > more than one branch. > I'm not sure how it works if you do "fedpkg clone -B libfoo", but probably similar to the CVS setup. If you do just "fedpkg clone" the branches are managed in git only so the "fedpkg switch-branch f13" indeed switches you to f13 branch even though it looks like master ;-) Personally I use "git merge " to sync the branches (if I have same spec for more than one branch). Martin signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On Fri, 2010-07-30 at 11:20 +0200, Martin Sourada wrote: > On Fri, 2010-07-30 at 17:17 +0800, Chen Lei wrote: > > 2010/7/30 Martin Sourada : > > > On Thu, 2010-07-29 at 20:55 -0700, Jesse Keating wrote: > > > > > >> Without the help of many others, this project would never have gotten > > >> done. Folks helped out with Koji modifications, with fedpkg > > >> contributions, with repeated testing of attempted conversions, with > > >> logic checking of my plans, of helping me understand more of git > > >> internals and deciphering error output, and most of all with being > > >> patient while we worked through the transition and very positive along > > >> the way. Things will be bumpy over the next few weeks as we really > > >> start putting distgit to the test. No amount of staging and testing can > > >> really replace production use. There will be many more updates to > > >> fedpkg as bugs are found and fixed and features are contributed. Wiki > > >> pages will get filled out as knowledge of how to interact with dist-git > > >> starts to spread ( https://fedoraproject.org/wiki/Using_Fedora_GIT is a > > >> good start ). > > > > > > Ok, so trying to update a package (libass) I've noticed a tiny problem: > > > the fedpkg switch-branch does not seem to set up proper tracking of > > > remote branches which then results in (uhm, I'm using git commit -a and > > > git push, so you maybe handle this in fedpkg commit -p): > > > > > > pyfedpkg.FedpkgError: There are unpushed changes in your repo > > > > > > fedora-packager-0.5.0.1-3.fc12.noarch > > > > > > Martin > > > > > > -- > > I now use 'git checkout -t origin/f14/master' instead of 'fedpkg > > switch-branch f14' temporarily. > I've just find a core of the problem. Looking through the git config > files I noticed nothing wrong, so I wondered why the push isn't working. > So I tried pushing from git gui which threw some error, which lead me to > try renaming the branch to f12/master. And lo! git push now works! > Ugh, I forgot to quote the error: Pushing to ssh://m...@pkgs.fedoraproject.org/libass error: there are still refs under 'refs/heads/f14' remote: error: failed to lock refs/heads/f14[K To ssh://m...@pkgs.fedoraproject.org/libass ! [remote rejected] f14 -> f14 (failed to lock) error: failed to push some refs to 'ssh://m...@pkgs.fedoraproject.org/libass' signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On Fri, 2010-07-30 at 17:17 +0800, Chen Lei wrote: > 2010/7/30 Martin Sourada : > > On Thu, 2010-07-29 at 20:55 -0700, Jesse Keating wrote: > > > >> Without the help of many others, this project would never have gotten > >> done. Folks helped out with Koji modifications, with fedpkg > >> contributions, with repeated testing of attempted conversions, with > >> logic checking of my plans, of helping me understand more of git > >> internals and deciphering error output, and most of all with being > >> patient while we worked through the transition and very positive along > >> the way. Things will be bumpy over the next few weeks as we really > >> start putting distgit to the test. No amount of staging and testing can > >> really replace production use. There will be many more updates to > >> fedpkg as bugs are found and fixed and features are contributed. Wiki > >> pages will get filled out as knowledge of how to interact with dist-git > >> starts to spread ( https://fedoraproject.org/wiki/Using_Fedora_GIT is a > >> good start ). > > > > Ok, so trying to update a package (libass) I've noticed a tiny problem: > > the fedpkg switch-branch does not seem to set up proper tracking of > > remote branches which then results in (uhm, I'm using git commit -a and > > git push, so you maybe handle this in fedpkg commit -p): > > > > pyfedpkg.FedpkgError: There are unpushed changes in your repo > > > > fedora-packager-0.5.0.1-3.fc12.noarch > > > > Martin > > > > -- > I now use 'git checkout -t origin/f14/master' instead of 'fedpkg > switch-branch f14' temporarily. I've just find a core of the problem. Looking through the git config files I noticed nothing wrong, so I wondered why the push isn't working. So I tried pushing from git gui which threw some error, which lead me to try renaming the branch to f12/master. And lo! git push now works! Martin signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On 07/30/2010 02:44 PM, Christof Damian wrote: > Thank you for all the work. > > I am currently in the process of convincing my employer to change from > svn to git and know how much work this is. Running git-svn clone alone > takes a few weeks for us. FYI, git-svn is for users who want to continue to use Subversion on the server but interact using Git from clients. It is not a tool for conversion. It is a common mistake. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
2010/7/30 Martin Sourada : > On Thu, 2010-07-29 at 20:55 -0700, Jesse Keating wrote: > >> Without the help of many others, this project would never have gotten >> done. Folks helped out with Koji modifications, with fedpkg >> contributions, with repeated testing of attempted conversions, with >> logic checking of my plans, of helping me understand more of git >> internals and deciphering error output, and most of all with being >> patient while we worked through the transition and very positive along >> the way. Things will be bumpy over the next few weeks as we really >> start putting distgit to the test. No amount of staging and testing can >> really replace production use. There will be many more updates to >> fedpkg as bugs are found and fixed and features are contributed. Wiki >> pages will get filled out as knowledge of how to interact with dist-git >> starts to spread ( https://fedoraproject.org/wiki/Using_Fedora_GIT is a >> good start ). > > Ok, so trying to update a package (libass) I've noticed a tiny problem: > the fedpkg switch-branch does not seem to set up proper tracking of > remote branches which then results in (uhm, I'm using git commit -a and > git push, so you maybe handle this in fedpkg commit -p): > > pyfedpkg.FedpkgError: There are unpushed changes in your repo > > fedora-packager-0.5.0.1-3.fc12.noarch > > Martin > > -- I now use 'git checkout -t origin/f14/master' instead of 'fedpkg switch-branch f14' temporarily. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
Thank you for all the work. I am currently in the process of convincing my employer to change from svn to git and know how much work this is. Running git-svn clone alone takes a few weeks for us. I will check out all my packages on the weekend. Happy Branching! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On Thu, 2010-07-29 at 20:55 -0700, Jesse Keating wrote: > Without the help of many others, this project would never have gotten > done. Folks helped out with Koji modifications, with fedpkg > contributions, with repeated testing of attempted conversions, with > logic checking of my plans, of helping me understand more of git > internals and deciphering error output, and most of all with being > patient while we worked through the transition and very positive along > the way. Things will be bumpy over the next few weeks as we really > start putting distgit to the test. No amount of staging and testing can > really replace production use. There will be many more updates to > fedpkg as bugs are found and fixed and features are contributed. Wiki > pages will get filled out as knowledge of how to interact with dist-git > starts to spread ( https://fedoraproject.org/wiki/Using_Fedora_GIT is a > good start ). Ok, so trying to update a package (libass) I've noticed a tiny problem: the fedpkg switch-branch does not seem to set up proper tracking of remote branches which then results in (uhm, I'm using git commit -a and git push, so you maybe handle this in fedpkg commit -p): pyfedpkg.FedpkgError: There are unpushed changes in your repo fedora-packager-0.5.0.1-3.fc12.noarch Martin signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On Fri, Jul 30, 2010 at 4:55 AM, Jesse Keating wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > This evening we opened up dist-git for business. Dist-git is our git > based replacement for dist-cvs, the source control system we were using > for our package specs, patches, and source files. This has been a long > time coming and a massive effort. I want to take a little time here to > outline what we've done and where we are going. > > First a brief outline of how our CVS system worked. CVS is a daemon of > sorts, and all repos typically live within a single CVSROOT. Within > this CVSROOT we had an 'avail' system to make use of, that we could > populate with data from Fedora Account System and dump into this file. > Avail worked on path names, relative to the CVSROOT. Since we used > directories for each Fedora release as pseudo branches we could set > avail info on each release "branch". CVS also used some filesystem > symlink tricks to create a "common" subdir for every package module, and > this is where we stuffed common scripts and Makefile content. Pretty > clever on one hand, we can make updates to the make system without > touching every single package, but it is pretty hackish and we had > constant issues where somebody would attempt an action using old common > content and stuff would fall over. > > Now we look at git. Git is for the most part a daemonless system. Each > repository is completely stand alone and generally does not require any > other infrastructure to be useful. You can interact with a repository > directly on the filesystem using /usr/bin/git or you can interact with > it through say ssh, again using /usr/bin/git (your local /usr/bin/git > will call a remote /usr/bin/git). Generally there is no running daemon > to connect to and authenticate with. Basic authentication of who can > check out what and commit where with git happens at the filesystem > permissions level. One twist with this is that with git, we wanted to > use real branches within a package repo to reflect the different > Fedora/EPEL releases. In repo branches are not reflected with path > names that we could set filesystem ACLs upon, so this posed a problem > for our conversion. > > Enter gitolite. Gitolite ( http://github.com/sitaramc/gitolite )is an > addon system to git that provides ACL functionality including different > rights for different branches within a given repository, and more! By > using gitolite as a replacement for /usr/bin/git when a user connects to > our git server we can again utilize the information we have within the > Fedora Package Database and properly allow / restrict changes on > specific branches for specific developers. The gitolite upstream ( > Sitaram Chamarty, sita...@atc.tcs.com ) has been fantastically > responsive to our needs, which are admittedly a little unique. We have > a very large set of repositories (over 10.5K) and a largish number of > contributors (1050). The combination of the two leads to a very very > large and complex ACL structure that at first broke the system quite > badly. Upstream was very quick to create a "bigconfig" method of > compiling the ACLs without crashing the box. Our other unique needs > involve having individual accounts for each committer instead of a > shared account with a large list of allowed SSH keys. Add to that some > of our accounts need to be able to ssh shell into the git server for > administrative duties. Throughout our trials and testing with gitolite > every time we've ran into some issue that just didn't fit the mold, > Sitaram has been there with a smile and a fix. At this point our > production server is a whopping one line different from current gitolite > upstream. This is a fantastic win for us, for our sustainability, and > for the next large group that wants to make use of gitolite. > > Once we had a plan for ACLs and for branches, we had to decide if we > were going to replace the Make system and with what. I had never been a > fan of Make, it was entirely too difficult to modify and innovate with. > Since I was the one pushing this transition forward, I decided to write > a new tool in my favorite language, python. The fedpkg tool was born > and took off. fedpkg was born around January 4th, 2010 and has since > grown into 1,523 (via sloccount) lines of code. While far from > complete, it is a great start (if I do say so myself!) at replacing the > make system. Because it is written in python (or maybe just !Make) it > seems to be easier to contribute to, and I've already gotten a number of > contributions. More will come as it starts to be more widely used. The > biggest challenge with fedpkg is removing the need to update something > on the end user's system every single time we added a new Fedora release > and changed what happens when you build for rawhide. I'll spare you the > details but I'm fairly happy with what we have. The end result should > be far fewer misfires and
Re: The move to git!
On Friday 30 of July 2010 05:55:09 Jesse Keating wrote: > ... Wiki > pages will get filled out as knowledge of how to interact with dist-git > starts to spread ( https://fedoraproject.org/wiki/Using_Fedora_GIT is a > good start ). Thanks for your hard work! Could you describe this in more details: OLD CVS | NEW GIT | Notes make tag | N/A | Explicitly tagging source states for package builds is no longer necessary. how this exactly works? What will happen in following cases? : 1) commit some changes with release number change, commit another changes, build 2) commit some changes with release number change, scratch build, commit rest of the changes, build 3) commit some changes with release number change, someone else starts build, commit rest of the changes, build 4) commit some changes with release number change, build - fails because of typo/missing updated sources, commit fix, build Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On 07/30/2010 05:55 AM, Jesse Keating wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > This evening we opened up dist-git for business. Dist-git is our git > based replacement for dist-cvs, the source control system we were using > for our package specs, patches, and source files. This has been a long > time coming and a massive effort. I want to take a little time here to > outline what we've done and where we are going. > > First a brief outline of how our CVS system worked. CVS is a daemon of > sorts, and all repos typically live within a single CVSROOT. Within > this CVSROOT we had an 'avail' system to make use of, that we could > populate with data from Fedora Account System and dump into this file. > Avail worked on path names, relative to the CVSROOT. Since we used > directories for each Fedora release as pseudo branches we could set > avail info on each release "branch". CVS also used some filesystem > symlink tricks to create a "common" subdir for every package module, and > this is where we stuffed common scripts and Makefile content. Pretty > clever on one hand, we can make updates to the make system without > touching every single package, but it is pretty hackish and we had > constant issues where somebody would attempt an action using old common > content and stuff would fall over. > > Now we look at git. Git is for the most part a daemonless system. Each > repository is completely stand alone and generally does not require any > other infrastructure to be useful. You can interact with a repository > directly on the filesystem using /usr/bin/git or you can interact with > it through say ssh, again using /usr/bin/git (your local /usr/bin/git > will call a remote /usr/bin/git). Generally there is no running daemon > to connect to and authenticate with. Basic authentication of who can > check out what and commit where with git happens at the filesystem > permissions level. One twist with this is that with git, we wanted to > use real branches within a package repo to reflect the different > Fedora/EPEL releases. In repo branches are not reflected with path > names that we could set filesystem ACLs upon, so this posed a problem > for our conversion. > > Enter gitolite. Gitolite ( http://github.com/sitaramc/gitolite )is an > addon system to git that provides ACL functionality including different > rights for different branches within a given repository, and more! By > using gitolite as a replacement for /usr/bin/git when a user connects to > our git server we can again utilize the information we have within the > Fedora Package Database and properly allow / restrict changes on > specific branches for specific developers. The gitolite upstream ( > Sitaram Chamarty, sita...@atc.tcs.com ) has been fantastically > responsive to our needs, which are admittedly a little unique. We have > a very large set of repositories (over 10.5K) and a largish number of > contributors (1050). The combination of the two leads to a very very > large and complex ACL structure that at first broke the system quite > badly. Upstream was very quick to create a "bigconfig" method of > compiling the ACLs without crashing the box. Our other unique needs > involve having individual accounts for each committer instead of a > shared account with a large list of allowed SSH keys. Add to that some > of our accounts need to be able to ssh shell into the git server for > administrative duties. Throughout our trials and testing with gitolite > every time we've ran into some issue that just didn't fit the mold, > Sitaram has been there with a smile and a fix. At this point our > production server is a whopping one line different from current gitolite > upstream. This is a fantastic win for us, for our sustainability, and > for the next large group that wants to make use of gitolite. > > Once we had a plan for ACLs and for branches, we had to decide if we > were going to replace the Make system and with what. I had never been a > fan of Make, it was entirely too difficult to modify and innovate with. > Since I was the one pushing this transition forward, I decided to write > a new tool in my favorite language, python. The fedpkg tool was born > and took off. fedpkg was born around January 4th, 2010 and has since > grown into 1,523 (via sloccount) lines of code. While far from > complete, it is a great start (if I do say so myself!) at replacing the > make system. Because it is written in python (or maybe just !Make) it > seems to be easier to contribute to, and I've already gotten a number of > contributions. More will come as it starts to be more widely used. The > biggest challenge with fedpkg is removing the need to update something > on the end user's system every single time we added a new Fedora release > and changed what happens when you build for rawhide. I'll spare you the > details but I'm fairly happy with what we have. The end result should > be far fewer misfires and end user
The move to git!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This evening we opened up dist-git for business. Dist-git is our git based replacement for dist-cvs, the source control system we were using for our package specs, patches, and source files. This has been a long time coming and a massive effort. I want to take a little time here to outline what we've done and where we are going. First a brief outline of how our CVS system worked. CVS is a daemon of sorts, and all repos typically live within a single CVSROOT. Within this CVSROOT we had an 'avail' system to make use of, that we could populate with data from Fedora Account System and dump into this file. Avail worked on path names, relative to the CVSROOT. Since we used directories for each Fedora release as pseudo branches we could set avail info on each release "branch". CVS also used some filesystem symlink tricks to create a "common" subdir for every package module, and this is where we stuffed common scripts and Makefile content. Pretty clever on one hand, we can make updates to the make system without touching every single package, but it is pretty hackish and we had constant issues where somebody would attempt an action using old common content and stuff would fall over. Now we look at git. Git is for the most part a daemonless system. Each repository is completely stand alone and generally does not require any other infrastructure to be useful. You can interact with a repository directly on the filesystem using /usr/bin/git or you can interact with it through say ssh, again using /usr/bin/git (your local /usr/bin/git will call a remote /usr/bin/git). Generally there is no running daemon to connect to and authenticate with. Basic authentication of who can check out what and commit where with git happens at the filesystem permissions level. One twist with this is that with git, we wanted to use real branches within a package repo to reflect the different Fedora/EPEL releases. In repo branches are not reflected with path names that we could set filesystem ACLs upon, so this posed a problem for our conversion. Enter gitolite. Gitolite ( http://github.com/sitaramc/gitolite )is an addon system to git that provides ACL functionality including different rights for different branches within a given repository, and more! By using gitolite as a replacement for /usr/bin/git when a user connects to our git server we can again utilize the information we have within the Fedora Package Database and properly allow / restrict changes on specific branches for specific developers. The gitolite upstream ( Sitaram Chamarty, sita...@atc.tcs.com ) has been fantastically responsive to our needs, which are admittedly a little unique. We have a very large set of repositories (over 10.5K) and a largish number of contributors (1050). The combination of the two leads to a very very large and complex ACL structure that at first broke the system quite badly. Upstream was very quick to create a "bigconfig" method of compiling the ACLs without crashing the box. Our other unique needs involve having individual accounts for each committer instead of a shared account with a large list of allowed SSH keys. Add to that some of our accounts need to be able to ssh shell into the git server for administrative duties. Throughout our trials and testing with gitolite every time we've ran into some issue that just didn't fit the mold, Sitaram has been there with a smile and a fix. At this point our production server is a whopping one line different from current gitolite upstream. This is a fantastic win for us, for our sustainability, and for the next large group that wants to make use of gitolite. Once we had a plan for ACLs and for branches, we had to decide if we were going to replace the Make system and with what. I had never been a fan of Make, it was entirely too difficult to modify and innovate with. Since I was the one pushing this transition forward, I decided to write a new tool in my favorite language, python. The fedpkg tool was born and took off. fedpkg was born around January 4th, 2010 and has since grown into 1,523 (via sloccount) lines of code. While far from complete, it is a great start (if I do say so myself!) at replacing the make system. Because it is written in python (or maybe just !Make) it seems to be easier to contribute to, and I've already gotten a number of contributions. More will come as it starts to be more widely used. The biggest challenge with fedpkg is removing the need to update something on the end user's system every single time we added a new Fedora release and changed what happens when you build for rawhide. I'll spare you the details but I'm fairly happy with what we have. The end result should be far fewer misfires and end user confusion. The last major piece of the puzzle was how to actually convert the existing CVS repositories, including the fun pseudo branches, into git repositories. I tried a number of options o
