Re: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec]
On Tue, Jul 10, 2012 at 06:31:22PM +0200, Marcin Krol wrote: > >When we were using CVS it was possible to resend tagged package to builders > >using package:auto-th-... syntax. > >Something changed or some builder functions were not updated for > >auto/th/ prefix? > Following change is needed to get it working with git: > http://git.tld-linux.org/?p=pld-builder.new.git;a=commitdiff;h=023f7f27e38074e64d78d0d4e97df0df36045bec Unfortunately that is not sufficient fix. The problem is that in git setup there is no longer translation of '.' and '@' when name of auto tags are generated. And when -tt option is omitted for ready build it can lead to a problem when old style auto tag exist and new style auto tag is requested for different commit that still represents the same version-release of the package. So I think the proper way is to always use -tt option for ready builds, and builder script shouldn't exit with error when the tag already exists but points to the same commit as the requested one. You can find relevant commits on tag_checking branch in PLD rpm-build-tools packages. -- Kacper ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec]
On Tue, Jul 10, 2012 at 08:16:59PM +0200, Kacper Kornet wrote:
> On Tue, Jul 10, 2012 at 07:54:11PM +0200, Marcin Krol wrote:
> > >What do you mean by shouldn't fell. Script builder will fail if you run
> > >like: builder -bs -Tp auto/th/ -tt .
> > >and the auto tag generated from required revision already exist. It was
> > >the case in CVS, it is the case in git.
> > It will fail on git, it wasn't failing on CVS due to difference in
> > return codes I've mentioned before. At least thats how it behave
> > when I was setting up TLD git. On CVS ready builds using auto tags
> > worked fine (without using -cf) and thats how they should work on
> > git as well. Developers must be able to do:
> > ./make-request.sh -d th -r some.spec:auto/th/some-1.2
> > and get their packages built.
> Propably I don't understand something. So sorry for still bothering you
> but I just tried:
> ./builder -bs -Tp auto/th/ -tt -r auto/th/git-core-slug-0.13.2-1 \
> git-core-slug.spec
> in using script builder for CVS and it fails with:
> Searching for tag auto-th-git-core-1_7_11_1-1...
> Tag auto-th-git-core-1_7_11_1-1 already exists (spec release: 1.283).
> What am I missing. How did you exactly send the request to rebuild the
> old tag previously in CVS?
Ok. Now I understand. I have missed the second condition in:
if ("test-build" in r.flags) or b.branch and
b.branch.startswith(config.tag_prefixes[0]):
I'm sorry for being slow.
--
Kacper
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec]
On Tue, Jul 10, 2012 at 07:54:11PM +0200, Marcin Krol wrote: > >What do you mean by shouldn't fell. Script builder will fail if you run > >like: builder -bs -Tp auto/th/ -tt . > >and the auto tag generated from required revision already exist. It was > >the case in CVS, it is the case in git. > It will fail on git, it wasn't failing on CVS due to difference in > return codes I've mentioned before. At least thats how it behave > when I was setting up TLD git. On CVS ready builds using auto tags > worked fine (without using -cf) and thats how they should work on > git as well. Developers must be able to do: > ./make-request.sh -d th -r some.spec:auto/th/some-1.2 > and get their packages built. Propably I don't understand something. So sorry for still bothering you but I just tried: ./builder -bs -Tp auto/th/ -tt -r auto/th/git-core-slug-0.13.2-1 \ git-core-slug.spec in using script builder for CVS and it fails with: Searching for tag auto-th-git-core-1_7_11_1-1... Tag auto-th-git-core-1_7_11_1-1 already exists (spec release: 1.283). What am I missing. How did you exactly send the request to rebuild the old tag previously in CVS? -- Kacper ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec]
On Tue, Jul 10, 2012 at 07:59:30PM +0200, Marcin Krol wrote:
> >Better, but still not the same as previously.
> Thats make-request.sh thing and has nothing to do with change we are
> talking about right now (added -cf to builder script call to allow
> ready builds with auto tags to succeed).
I'm sorry. I got confused between differen links to commits in gitweb.
My fault. So in our case:
@@ -126,7 +126,7 @@ def build_srpm(r, b):
if res == 0 and not "test-build" in r.flags:
for pref in config.tag_prefixes:
util.append_to(b.logfile, "Tagging with prefix: %s" % pref)
-res = chroot.run("cd rpm/packages; ./builder -r %s -Tp %s
-Tv %s" % \
+res = chroot.run("cd rpm/packages; ./builder -cf -r %s -Tp
%s -Tv %s" % \
(b.branch, pref, b.spec), logfile = b.logfile)
if res == 0:
transfer_file(r, b
is not sufficent as option builder -cf does not disable checking if the
tag already exists. But I'm still confused about it. So maybe first
finish the second subthread.
--
Kacper
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec]
Better, but still not the same as previously. Thats make-request.sh thing and has nothing to do with change we are talking about right now (added -cf to builder script call to allow ready builds with auto tags to succeed). M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec]
What do you mean by shouldn't fell. Script builder will fail if you run like: builder -bs -Tp auto/th/ -tt . and the auto tag generated from required revision already exist. It was the case in CVS, it is the case in git. It will fail on git, it wasn't failing on CVS due to difference in return codes I've mentioned before. At least thats how it behave when I was setting up TLD git. On CVS ready builds using auto tags worked fine (without using -cf) and thats how they should work on git as well. Developers must be able to do: ./make-request.sh -d th -r some.spec:auto/th/some-1.2 and get their packages built. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec]
On Tue, Jul 10, 2012 at 07:25:45PM +0200, Marcin Krol wrote: > >I have the same fix, but I have not pushed it as I am not 100% > >happy with it. It changes the send request send with "path/spec:tag" > Can you explain? I pretty you mean something different than what I'm > thinking about. My assumption is that request looks like: git-core.spec auto/th/cos If I send the old style tag with old version of make_request.sh like: ./make-request.sh -r -d th dir/git-core.spec:auto-th- I will get: git-core.spec auto-th- With new tag style and old script and argument: dir/git-core.spec:auto/th/cos I get: cos cos Wit your patch and argument dir/git-core.spec:auto/th/cos I get dir/git-core.spec auto/th/cos Better, but still not the same as previously. I have an idea for proper fix and I'm working on it right now. -- Kacper ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec]
On Tue, Jul 10, 2012 at 07:19:39PM +0200, Marcin Krol wrote: > >Hawk has given the solution to the problem. But my question is the > >purpose of resending the build from the same tag? I'm assume that it > >would a test build, as the ready one would fail due to preexisting tag. > No. Ready build with auto tag shouldn't fail. What do you mean by shouldn't fell. Script builder will fail if you run like: builder -bs -Tp auto/th/ -tt . and the auto tag generated from required revision already exist. It was the case in CVS, it is the case in git. -- Kacper ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec]
I have the same fix, but I have not pushed it as I am not 100% happy with it. It changes the send request send with "path/spec:tag" Can you explain? I pretty you mean something different than what I'm thinking about. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec]
On Tue, Jul 10, 2012 at 07:05:14PM +0200, Kacper Kornet wrote: > Hawk has given the solution to the problem. But my question is > the purpose of resending the build from the same tag? I'm > assume that it would a test build, as the ready one would fail > due to preexisting tag. Just in case, test-only builds proved to be immensely useful at ALT -- especially when the build task is pretty complex (a bunch of packages some of which are popular dependencies). Doing an unmets check in a new combined repo helps it too. Those reading Russian might be interested in this whitepaper: http://ftp.linux.kiev.ua/pub/conference/peers/protva/2008/book-thesis-Protva-2008-5.pdf (p. 47) by Alexey Tourbin. -- WBR, Michael Shigorin -- Linux.Kiev http://www.linux.kiev.ua/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec]
Hawk has given the solution to the problem. But my question is the purpose of resending the build from the same tag? I'm assume that it would a test build, as the ready one would fail due to preexisting tag. No. Ready build with auto tag shouldn't fail. Lets say someone sends 10 packages as ready build. They all got auto tagged, but 3rd of them fails to build. So now we have 7 packages tagged wich must be sent again to builder after fixing package number 3. Without possibility to send using auto tag one would have to bump release on those 7 packages. There are few other situations when ready build using auto tag must be performed. Mostly due to human mistakes, wrong/missing BRs/Rs etc. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec]
On Tue, Jul 10, 2012 at 06:31:22PM +0200, Marcin Krol wrote: > >When we were using CVS it was possible to resend tagged package to builders > >using package:auto-th-... syntax. > >Something changed or some builder functions were not updated for > >auto/th/ prefix? > Following change is needed to get it working with git: > http://git.tld-linux.org/?p=pld-builder.new.git;a=commitdiff;h=023f7f27e38074e64d78d0d4e97df0df36045bec I have the same fix, but I have not pushed it as I am not 100% happy with it. It changes the send request send with "path/spec:tag" -- Kacper ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec]
On Tue, Jul 10, 2012 at 06:17:53PM +0200, Jakub Bogusz wrote: > On Tue, Jul 10, 2012 at 03:20:52PM +, PLD th-src builder wrote: > > sblim-cmpi-base.spec (auto/th/sblim-cmpi-base-1.6.1-1): FAILED > > --- sblim-cmpi-base.spec:auto/th/sblim-cmpi-base-1.6.1-1: > > Build-Time: user:2.17s sys:0.89s real:4.63s (faults io:0 non-io:118415) > > *** buildlog for sblim-cmpi-base.spec > > request from: qboosh > > started at: Tue Jul 10 17:20:47 2012 > > building SRPM using: cd rpm/packages; nice -n 0 ./builder -nu -nm --nodeps > > --http -bs -r auto/th/sblim-cmpi-base-1.6.1-1 sblim-cmpi-base.spec 2>&1 > > Cloning into 'sblim-cmpi-base'... > [...] > > Tagging with prefix: auto/th/ > > Version: 1.6.1 > > Release: 1 > > tag: auto/th/sblim-cmpi-base-1.6.1-1 > > fatal: tag 'auto/th/sblim-cmpi-base-1.6.1-1' already exists > > On detached HEAD. Use -r BRANCHNAME to override > > error: Macro %_builddir has empty body > > error: Macro %_builddir has empty body > [...] > When we were using CVS it was possible to resend tagged package to builders > using package:auto-th-... syntax. > Something changed or some builder functions were not updated for > auto/th/ prefix? Hawk has given the solution to the problem. But my question is the purpose of resending the build from the same tag? I'm assume that it would a test build, as the ready one would fail due to preexisting tag. -- Kacper ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec]
Doesn't that make builder do forced retagging (which is not desired here) ? Yes. It replaces current tag with same name (note: not by delete tag, re-add tag), but otherwise build will fail because git tag command will return failure if given tag already exists while cvs was returning "ok" and just displaying warning AFAIR. Personally I didn't found any drawbacks and I'm using this fix with TLD for over a year now. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec]
On Tuesday 10 of July 2012, Marcin Krol wrote: > > When we were using CVS it was possible to resend tagged package to > > builders using package:auto-th-... syntax. > > > > Something changed or some builder functions were not updated for > > auto/th/ prefix? > > Following change is needed to get it working with git: > > http://git.tld-linux.org/?p=pld-builder.new.git;a=commitdiff;h=023f7f27e380 > 74e64d78d0d4e97df0df36045bec Doesn't that make builder do forced retagging (which is not desired here) ? > M. -- Arkadiusz Miśkiewicz, arekm / maven.pl ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec]
When we were using CVS it was possible to resend tagged package to builders using package:auto-th-... syntax. Something changed or some builder functions were not updated for auto/th/ prefix? Following change is needed to get it working with git: http://git.tld-linux.org/?p=pld-builder.new.git;a=commitdiff;h=023f7f27e38074e64d78d0d4e97df0df36045bec M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec]
On Tue, Jul 10, 2012 at 03:20:52PM +, PLD th-src builder wrote: > sblim-cmpi-base.spec (auto/th/sblim-cmpi-base-1.6.1-1): FAILED > > --- sblim-cmpi-base.spec:auto/th/sblim-cmpi-base-1.6.1-1: > Build-Time: user:2.17s sys:0.89s real:4.63s (faults io:0 non-io:118415) > > > > *** buildlog for sblim-cmpi-base.spec > request from: qboosh > started at: Tue Jul 10 17:20:47 2012 > building SRPM using: cd rpm/packages; nice -n 0 ./builder -nu -nm --nodeps > --http -bs -r auto/th/sblim-cmpi-base-1.6.1-1 sblim-cmpi-base.spec 2>&1 > > Cloning into 'sblim-cmpi-base'... [...] > Tagging with prefix: auto/th/ > Version: 1.6.1 > Release: 1 > tag: auto/th/sblim-cmpi-base-1.6.1-1 > fatal: tag 'auto/th/sblim-cmpi-base-1.6.1-1' already exists > On detached HEAD. Use -r BRANCHNAME to override > error: Macro %_builddir has empty body > error: Macro %_builddir has empty body [...] When we were using CVS it was possible to resend tagged package to builders using package:auto-th-... syntax. Something changed or some builder functions were not updated for auto/th/ prefix? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/Mesa] - provide OpenGL-GLES, OpenGL-GLES-devel in libGLES, libGLES-devel (required by newest KDE)
On Tue, Jul 10, 2012 at 05:27:35PM +0200, Marcin Krol wrote: > >OpenGL-GLES, OpenGL-ES or OpenGLES? > >The standard's name is "OpenGL(R) ES"... > >(see http://www.khronos.org/opengles/ for more information) > > I followed naming scheme already used in other specs, ie. OpenGL-GL > instead of just OpenGL. Actually libGL uses just "OpenGL" Provides. There are OpenGL-GLU and OpenGL-GLX, both of which are parts of OpenGL specification (OpenGL Utility Library, OpenGL extension to the X Window System). OpenGL ES is a separate standard, so maybe separate namespace would be better (OpenGLES, OpenGLESv1/OpenGLESv2). > >Also, these packages provide two libraries conforming to different > >specifications, OpenGL ES 1.x and OpenGL ES 2.x. > > > >So I'd use P: OpenGL-ESv1 = 1.1, OpenGL-ESv2 = 2.0 > >(or equivalent using OpenGL-GLESvX or OpenGLESvX scheme) > > Fine by me, but I'd left generic P: OpenGL-GLES as well. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/Mesa] - provide OpenGL-GLES, OpenGL-GLES-devel in libGLES, libGLES-devel (required by newest KDE)
OpenGL-GLES, OpenGL-ES or OpenGLES? The standard's name is "OpenGL(R) ES"... (see http://www.khronos.org/opengles/ for more information) I followed naming scheme already used in other specs, ie. OpenGL-GL instead of just OpenGL. Also, these packages provide two libraries conforming to different specifications, OpenGL ES 1.x and OpenGL ES 2.x. So I'd use P: OpenGL-ESv1 = 1.1, OpenGL-ESv2 = 2.0 (or equivalent using OpenGL-GLESvX or OpenGLESvX scheme) Fine by me, but I'd left generic P: OpenGL-GLES as well. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Git in PLD - basic HOWTO
On 10.07.2012 16:26, Caleb Maclennan wrote: 2) Is there a way to set git's user.email config variable without doing it globally? I use git for other things where my pld nick is not my email. However with each package being a separate repository, setting it in the repository config file instead of the global one means having to set it in a couple thousand places. assuming you don't clone manually, but either with slug.py or builder why not add to both of them that they configure user based on some default into the new repos? i.e after checkout the tool would do: $ git config user.email=whatever -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/Mesa] - provide OpenGL-GLES, OpenGL-GLES-devel in libGLES, libGLES-devel (required by newest KDE)
On Tue, Jul 10, 2012 at 12:50:44PM +0200, hawk wrote: > commit 57d6b81de30e78ec0686fd2f684f836f4c59cf84 > Author: Marcin Krol > Date: Tue Jul 10 10:53:10 2012 + > > - provide OpenGL-GLES, OpenGL-GLES-devel in libGLES, libGLES-devel > (required by newest KDE) OpenGL-GLES, OpenGL-ES or OpenGLES? The standard's name is "OpenGL(R) ES"... (see http://www.khronos.org/opengles/ for more information) Also, these packages provide two libraries conforming to different specifications, OpenGL ES 1.x and OpenGL ES 2.x. So I'd use P: OpenGL-ESv1 = 1.1, OpenGL-ESv2 = 2.0 (or equivalent using OpenGL-GLESvX or OpenGLESvX scheme) -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Git in PLD - basic HOWTO
2012/7/10 Kacper Kornet :
> The solution that I know is to define a wrapper around git, that calls
> call "git -c user.email=whatever", where whatever depends on the current
> path. It's cumbersome, but maybe better then nothing.
Here's my current hack as function for my zsh shell:
function git () {
case "$PWD"; in
$HOME/rpm/*)
command git -c user.email=$u...@pld-linux.org "$@"
;;
*)
command git "$@"
;;
esac
}
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Git in PLD - basic HOWTO
On Tue, Jul 10, 2012 at 05:06:57PM +0300, Caleb Maclennan wrote: > 2012/7/10 Mariusz Mazur : > > Or one can alias the 'git' command to a simple script that checks for > > .git/config, check if remote origin is git.pld-linux.org and if so, uses a > > different user.email. > > Hm, I could use that. Wonder if anyone already wrote it. > I thought of that too and could code it up, but as I thought about it, > it seemed like something somebody else would already have done long > ago. I just couldn't figure out what to search for to find a canonical > solution. There was a suggestion to add run-time conditional sections to configuration files, but it was rejected because that part of code is heavily used: http://thread.gmane.org/gmane.comp.version-control.git/181998/focus=182204 -- Kacper ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Git in PLD - basic HOWTO
2012/7/10 Mariusz Mazur : > Or one can alias the 'git' command to a simple script that checks for > .git/config, check if remote origin is git.pld-linux.org and if so, uses a > different user.email. > > Hm, I could use that. Wonder if anyone already wrote it. I thought of that too and could code it up, but as I thought about it, it seemed like something somebody else would already have done long ago. I just couldn't figure out what to search for to find a canonical solution. Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Git in PLD - basic HOWTO
2012/7/10 Jakub Bogusz : > On Tue, Jul 10, 2012 at 03:40:58PM +0200, Kacper Kornet wrote: >> On Tue, Jul 10, 2012 at 04:26:00PM +0300, Caleb Maclennan wrote: >> > 2) Is there a way to set git's user.email config variable without >> > doing it globally? I use git for other things where my pld nick is not >> > my email. However with each package being a separate repository, >> > setting it in the repository config file instead of the global one >> > means having to set it in a couple thousand places. Is there a way to >> > match the git origin server or some other way of marking that >> > everything under rpm/packages gets a certain set of configuration >> > values? >> >> The solution that I know is to define a wrapper around git, that calls >> call "git -c user.email=whatever", where whatever depends on the current >> path. It's cumbersome, but maybe better then nothing. > > Is it possible to include user.* setting in per-package .git/config? > > If so, slug.py or builder could set it based on some PLD-specific config > file or environment variable. Yes it is possible. It would look like this as a separate section: [user] email = ca...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Git in PLD - basic HOWTO
On Tue, Jul 10, 2012 at 04:04:01PM +0200, Jakub Bogusz wrote: > On Tue, Jul 10, 2012 at 03:40:58PM +0200, Kacper Kornet wrote: > > On Tue, Jul 10, 2012 at 04:26:00PM +0300, Caleb Maclennan wrote: > > > 2) Is there a way to set git's user.email config variable without > > > doing it globally? I use git for other things where my pld nick is not > > > my email. However with each package being a separate repository, > > > setting it in the repository config file instead of the global one > > > means having to set it in a couple thousand places. Is there a way to > > > match the git origin server or some other way of marking that > > > everything under rpm/packages gets a certain set of configuration > > > values? > > The solution that I know is to define a wrapper around git, that calls > > call "git -c user.email=whatever", where whatever depends on the current > > path. It's cumbersome, but maybe better then nothing. > Is it possible to include user.* setting in per-package .git/config? Yes there is. > If so, slug.py or builder could set it based on some PLD-specific config > file or environment variable. It is already implemented in git-init, which is used during initialization of repositories. Just set proper GIT_TEMPLATE_DIR. See section "TEMPLATE DIRECTORY" in man git-init. -- Kacper ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Git in PLD - basic HOWTO
On Tue, Jul 10, 2012 at 03:40:58PM +0200, Kacper Kornet wrote: > On Tue, Jul 10, 2012 at 04:26:00PM +0300, Caleb Maclennan wrote: > > 2) Is there a way to set git's user.email config variable without > > doing it globally? I use git for other things where my pld nick is not > > my email. However with each package being a separate repository, > > setting it in the repository config file instead of the global one > > means having to set it in a couple thousand places. Is there a way to > > match the git origin server or some other way of marking that > > everything under rpm/packages gets a certain set of configuration > > values? > > The solution that I know is to define a wrapper around git, that calls > call "git -c user.email=whatever", where whatever depends on the current > path. It's cumbersome, but maybe better then nothing. Is it possible to include user.* setting in per-package .git/config? If so, slug.py or builder could set it based on some PLD-specific config file or environment variable. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Git in PLD - basic HOWTO
On Tue of July 10 2012, Kacper Kornet wrote: > The solution that I know is to define a wrapper around git, that calls > call "git -c user.email=whatever", where whatever depends on the current > path. It's cumbersome, but maybe better then nothing. Or one can alias the 'git' command to a simple script that checks for .git/config, check if remote origin is git.pld-linux.org and if so, uses a different user.email. Hm, I could use that. Wonder if anyone already wrote it. --mmazur ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Git in PLD - basic HOWTO
On Tue, Jul 10, 2012 at 04:26:00PM +0300, Caleb Maclennan wrote: > 2) Is there a way to set git's user.email config variable without > doing it globally? I use git for other things where my pld nick is not > my email. However with each package being a separate repository, > setting it in the repository config file instead of the global one > means having to set it in a couple thousand places. Is there a way to > match the git origin server or some other way of marking that > everything under rpm/packages gets a certain set of configuration > values? The solution that I know is to define a wrapper around git, that calls call "git -c user.email=whatever", where whatever depends on the current path. It's cumbersome, but maybe better then nothing. -- Kacper ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Git in PLD - basic HOWTO
2012/7/9 Kacper Kornet : > * Some documentation > > > For some basic introduction to git and how to use it to work with PLD > repositories please see: > > http://www.pld-linux.org/dokuwiki/howto-git Two simple questions: 1) I haven't seen any notes in the docs about comment formatting. Are we still prefixing all changelog entries with "- "? This isn't a very usual thing to do with git and seems like a hack we've dragged in from processing cvs output. 2) Is there a way to set git's user.email config variable without doing it globally? I use git for other things where my pld nick is not my email. However with each package being a separate repository, setting it in the repository config file instead of the global one means having to set it in a couple thousand places. Is there a way to match the git origin server or some other way of marking that everything under rpm/packages gets a certain set of configuration values? Thanks, Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
