On Fr Juni 22 2007, Axel Thimm wrote:
> Looks like the login timeouts are insanely short and trac has no
> recovery mechanism for that.
I experienced some problems login in to hosted.fedoraprojects and bodhi or
koji around the same time, maybe this was the cause. Iirc, the login on
hosted.fedor
On Fr Juli 6 2007, Michael E Brown wrote:
> +++ b/etc/defaults.cfg
> +config_opts['chroot_setup_cmd'] = 'groupinstall buildsys-build'
>
> This could be problematic for F7, F6, EPEL4/5 and others.
When you call the group "build" instead of "buildsys-build" , F7 may use the
group definition that i
Aloas,
the attached patch changes the URL in Makefile.common for Koji client setup
from
http://fedoraproject.org/wiki/BuildSystemClientSetup
to
http://fedoraproject.org/wiki/PackageMaintainers/BuildSystemClientSetup
The first URL is a redirection to the second one.
If this is not the correct pl
Aloas,
the attached patch adds support for scratch builds to Makefile.common:
scratch-build Request scratch build of "fcgi-2_4_0-2_fc8" for dist-f8
scratch-build- Request scratch build of "fcgi-2_4_0-2_fc8" for
dist-f8 and archs
examples: make scratch-build-i386,ppc64
On Mi Juli 11 2007, Dennis Gilmore wrote:
> Rather than have a check for koji's existence in each target, i would
> perfer a target to check for koji and have the makefile call that. Then if
> the location to get information changes or we switch out koji and go to
> something else we only need to
On Mi Juli 11 2007, Till Maas wrote:
> @$(BUILD_CLIENT) build $(BUILD_FLAGS) $(TARGET) '$(CVS_URL)'
> @$(BUILD_CLIENT) build --scratch $(BUILD_FLAGS) $(TARGET) '$(CVS_URL)'
> @$(BUILD_CLIENT) build --scratch --arch-override=$* $(BUILD_FLAGS)
> $(TARGET) &#x
Hiyas,
Makefile.common uses CVS_EXTRAS_RC to define the variable of the user config
file and uses a complex structure to only include it, when it is a file.
According to "info make", there is a much easier way:
| If you want `make' to simply ignore a makefile which does not exist
| and cannot b
Aloa,
the attached patch makes sure, that "all" ist the default goal, even when
there are other targets in .cvspkgsrc. This allows to define other targets in
this configuration file without changing the default goal. When one wants to
change the default goal, this is still possible with setting
Hiyas,
now that the groups repo is not used anymore in mock, imho the gpgcheck option
can be enabled by default and only be disabled for the local repo. It will
only need the required gpg-keys be included in the mock rpm and some more
lines in the config files. I will write a patch for this if
Hiyas,
I noticed that there is a typo in the scratch-build-% target in
Makefile.common, which breaks the target. The attached patch fixes this.
Regards,
Till
cvs diff: Diffing .
Index: Makefile.common
===
RCS file: /cvs/pkgs/common/
On Monday 19 November 2007 09:01:59 Michael E Brown wrote:
> On Sun, Nov 18, 2007 at 11:01:40PM +0100, Till Maas wrote:
> > now that the groups repo is not used anymore in mock, imho the gpgcheck
> > option can be enabled by default and only be disabled for the local repo.
> &
On Saturday 15 December 2007 16:34:44 Jesse Keating wrote:
> Couldn't the repo configs just point to the online version of it, and
> have yum download the key when needed? (or if it's already on the file
> system use it?)
It is possible afaik, but it is less secure, because yum can not check,
w
On Do Januar 3 2008, Michael E Brown wrote:
> It looks to me like the goal of adding gpg key support is to add some
> stricter security guarantees around mock builds. It would be nice if you
> could codify exactly what you think the security guarantee should look
> like, and what are the possible
On Do Januar 3 2008, seth vidal wrote:
> it uses urlgrabber which uses urllib[2] underneath. ssl connections
> specific ca to focus on.
>
> but what does this have to do with gpg certs? gpg certs aren't ssl
> certs.
When yum (rpm?) verifies ssl certificates for https urls to acquire gpgkeys,
it
Hiyas,
The scratch build target does not respect the BUILD_FLAGS variable,
that is repected for make build. This patch changes this and makes it possible
to use, e.g.:
make scratch-build BUILD_FLAGS=--nowait
Regards,
Till
The scratch build target does not respect the BUILD_FLAGS variable,
that is
On Sun January 6 2008, Jesse Keating wrote:
> KOJI_FLAGS="--nowait" make scratch-build
This does not work and also needs my patch to work:
$ KOJI_FLAGS="--nowait" make scratch-build
Created task: 328830
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=328830
Watching tasks (this may b
Aloas,
On Sun January 6 2008, Till Maas wrote:
> The scratch build target does not respect the BUILD_FLAGS variable,
> that is repected for make build. This patch changes this and makes it
> possible to use, e.g.:
> make scratch-build BUILD_FLAGS=--nowait
do you manage the patches i
On Tue January 15 2008, Dennis Gilmore wrote:
> the attached patch makes it configurable to send email to the owner of a
> package and person submitting the job. This is needed for secondary arches
> so that you dont get 6 emails per build.
My 2 cents: The name of the variable is could be better.
On Fri January 25 2008, Dennis Gilmore wrote:
> here is the updated patch. if its too late thats ok
There was a missing "i" in line 40, here is this fixed.
Regards,
Till
From 61b4c4f156378d8feee9ff7af86c8d123f17725b Mon Sep 17 00:00:00 2001
From: Dennis Gilmore <[EMAIL PROTECTED]>
Date: Mon, 14
On Tue December 16 2008, Mike McGrath wrote:
> The problem is time and coordination. So on a whim I thought I'd send
> this email out. Do we have any contributors out there who are both
> members of Fedora and SuSE who would be willing to lead this charge, find
> similarities and places for coor
20 matches
Mail list logo
