Re: Signing RPMs

2009-11-11 Thread Jitesh Shah
..snip..
  
  The sign_unsigned script should eventually do a koji API call to do
  'write-signed-rpm' on the packages you are signing.  That will assemble
   signed RPMs in koji itself, which mash will download and used.
  
  Fedora Rel-Eng doesn't use sign_unsigned anymore because we have a signing
  server setup now.  However, it should still work.
 it still works. EPEL releng still uses it. you need to make sure to add --
 write-rpms to you command. the signed rpms will then get written.

Nice! that was what I was missing! The signed rpms are now being written
in the 'signed' directory. 

Thankyou Dennis and Josh.


 
 Dennis


Jitesh

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list


Re: Signing RPMs

2009-11-11 Thread Jitesh Shah
..snip..
 
 I to have wanted to get this to work.
 
 I expect I have my key definition wrong, traceback below.
 
 I have,
 self.gpg_keys = {
 '89D891FB': { 'name': 'oatrelease',
   'description': 'EGEE SA1 (Operations
 Automation Team) egee3-operations-automation-disc...@cern.ch',
   }}
 
 with
 
 $ gpg --list-keys
 /home/sign/.gnupg/pubring.gpg
 -
 pub   1024D/47EBAC2B 2009-11-11 [expires: 2019-11-09]
 uid  EGEE SA1 (Operations Automation Team)
 egee3-operations-automation-disc...@cern.ch
 sub   2048g/89D891FB 2009-11-11 [expires: 2019-11-09]

Steve, you are using the subkey. You probably want to use the master
signing key i.e. the one listed under pub (47EBAC2B in your case)

Jitesh

 
 
 
 
 Traceback (most recent call last):
   File ./sign_unsigned.py, line 734, in module
 x.run_command()
   File ./sign_unsigned.py, line 285, in run_command
 cmd()
   File ./sign_unsigned.py, line 728, in cmd_default
 self.sign_to_cache(uncached, self.options.level)
   File ./sign_unsigned.py, line 638, in sign_to_cache
 self.do_signing(pkglist, level)
   File ./sign_unsigned.py, line 601, in do_signing
 cmd = self.get_signing_command(level, mypaths[:nlen],
 server=self.options.server)
   File ./sign_unsigned.py, line 587, in get_signing_command
 if self.gpg_keys[keyid]['size'] == 4096:
 KeyError: None
 
 
 
 
 
 
 
  Dennis
 
  --
  Fedora-buildsys-list mailing list
  Fedora-buildsys-list@redhat.com
  https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
 
 
 
 

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list


Signing RPMs

2009-11-10 Thread Jitesh Shah
So, I picked up the sign_unsigned.py script from releng. I replaced the keys in 
there with our keys, tweaked some minor stuff here and there and managed to get 
it running. 
I use it as 
./sign_unsigned.py --level level tag-name
and it runs alright. I can see that the signatures are cached under the 
sigcache directory (but NOT embedded in the rpms themselves, which makes sense 
since the rpm can probably be a part of different tags and might be signed 
differently within each tag)

So, I thought, well, mash would be the one which'll embed the keys in the rpms. 
So, I set strict_keys to True.. added my key to the keys list in my .mash file. 
mash has no problems with the rpms and it can verify the signatures alright. 
But, it still doesn't embed the signatures in the rpm (is it supposed to?). So, 
the created repository still has all rpms unsigned. 

What am I missing here? where to the rpms get signed actually?

Regards,
Jitesh

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list


RE: How can I waite for a new dist-foo-build repo

2009-08-25 Thread Jitesh Shah
Looks like either you don't have kojira running or there is no builder in the 
createrepo channel
Refer: http://fedoraproject.org/wiki/Koji/ServerHowTo

Regards,
Jitesh


From: fedora-buildsys-list-boun...@redhat.com 
[fedora-buildsys-list-boun...@redhat.com] On Behalf Of lixiao-a 
[lixia...@163.com]
Sent: Wednesday, August 26, 2009 7:32 AM
To: fedora-buildsys-list
Subject: How can I waite  for a new dist-foo-build repo

When I build a srpm,it can not waite genarate a new repo,it says.
1076 build (dist-foo, system-config-network-1.3.99-1.src.rpm): free
1076 build (dist-foo, system-config-network-1.3.99-1.src.rpm): free - open 
(kojibuilder)
  1077 waitrepo (3): free
  1077 waitrepo (3): free - open (kojibuilder)
  1077 waitrepo (3): open (kojibuilder) - FAILED: GenericError: Unsuccessfully 
waited 120:58 for a new dist-foo-build repo
  0 free  1 open  0 done  1 failed
1076 build (dist-foo, system-config-network-1.3.99-1.src.rpm): open 
(kojibuilder) - FAILED: GenericError: Unsuccessfully waited 120:58 for a new 
dist-foo-build repo
  0 free  0 open  0 done  2 failed
1076 build (dist-foo, system-config-network-1.3.99-1.src.rpm) failed

the /var/log/kojid.log shows
Traceback (most recent call last):
  File /usr/sbin/kojid, line 1275, in runTask
response = (handler.run(),)
  File /usr/sbin/kojid, line 1351, in run
return self.handler(*self.params,**self.opts)
  File /usr/sbin/kojid, line 2517, in handler
results = self.wait(subtasks.values(), all=True, failany=True)
  File /usr/sbin/kojid, line 1428, in wait
raise task_error
Fault: Fault 1: 'Traceback (most recent call last):
  File /usr/sbin/kojid, line 1275, in runTask
response = (handler.run(),)
  File /usr/sbin/kojid, line 1351, in run
return self.handler(*self.params,**self.opts)
  File /usr/sbin/kojid, line 2560, in handler
for f in os.listdir(self.datadir):
OSError: [Errno 2] No such file or directory: 
\'/tmp/koji/tasks/227/227/repo/repodata\'.
Please help me.Thanks.



没有广告的终身免费邮箱,www.yeah.nethttp://www.yeah.net/?from=footer

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list


Re: Delete a build from a tag, How to do ?

2009-06-19 Thread Jitesh Shah
Hi,


On Thu, 2009-06-18 at 20:54 -0700, Jian Lee wrote:
 Hello, everyone
 
 I want to delete a build from a tag, How should I do ?
 
 example, the tag tms2.0 have following build:
 
 -
 b43-fwcutter-011-5.tms2  michaelw  2009-06-19  09:52:18  complete
 =
 
 I first try to delete the build from tms2.0 tag by following cmd:
 
 
 # koji call deleteBuild b43-fwcutter-011-5.tms2 tms2.0
 GenericError: Cannot delete build, tagged: [{'id': 10, 'name': 'tms2.0'}]
 ==
 
 Did a use a wrong api ? or did I can delete a build from a tag use
 kojihub api ? Must to direct do on postgresql ?

deleteBuild will still keep some data in the database. If the reason for
deleting the build is so that you can build/import it again, then try
using resetBuild. It will remove all the files and rpm data and mark
the build as cancelled. 

(Although a quick looks suggests that it removes entries from buildroot
too. So, use with care)

Do correct me if I am wrong.

Regards,
Jitesh

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list


How is average calculated?

2009-06-17 Thread Jitesh Shah
Hi,
I was wondering how the average load on a builder is calculated?
I have a builder which is simply refuses to take tasks (not even one)

[jit...@fedora-arm ~]$ koji list-tasks | grep armbuilder39
NIL OUTPUT
(and there are about 9 tasks still queued. The other builders are busy,
so they are in the FREE state)

which means the builder isn't processing any task, right?

now, here is kojid tail of that builder..
2009-06-17 08:54:07,628 [INFO] koji.build.TaskManager: Not ready for task
2009-06-17 08:54:28,466 [INFO] koji.build.TaskManager: Load average 6.09  4.00
2009-06-17 08:54:30,365 [INFO] koji.build.TaskManager: Not ready for task
2009-06-17 08:54:50,136 [INFO] koji.build.TaskManager: Load average 6.00  4.00
2009-06-17 08:54:51,268 [INFO] koji.build.TaskManager: Not ready for task
2009-06-17 08:55:11,708 [INFO] koji.build.TaskManager: Load average 5.75  4.00
2009-06-17 08:55:13,622 [INFO] koji.build.TaskManager: Not ready for task
2009-06-17 08:55:34,318 [INFO] koji.build.TaskManager: Load average 5.85  4.00
2009-06-17 08:55:36,339 [INFO] koji.build.TaskManager: Not ready for task
2009-06-17 08:55:56,769 [INFO] koji.build.TaskManager: Load average 5.68  4.00
2009-06-17 08:55:58,507 [INFO] koji.build.TaskManager: Not ready for task

How does it end up calculating 5.5+ load average when it is not even
executing a single task?

Regards,
Jitesh

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list


RE: mergerepos issue

2009-06-06 Thread Jitesh Shah
aah... may be.. I just assumed it was unicode because it wasn't ASCII ... 
ignorance :)

Regards,
Jitesh

PS: Mailing from a crappy mail client. Please ignore any formatting issues. 

From: fedora-buildsys-list-boun...@redhat.com 
[fedora-buildsys-list-boun...@redhat.com] On Behalf Of Seth Vidal 
[skvi...@fedoraproject.org]
Sent: Friday, June 05, 2009 8:46 PM
To: Discussion of Fedora build system
Subject: Re: mergerepos issue

On Fri, 5 Jun 2009, Jitesh Shah wrote:

 Aaah .. some RPMs have unicode in their 'provides' tag which causes this
 problem. Temporarily, I have removed those from the external repo and it
 works fine :)

I bet the provides did not have unicode but had random other encoding.

-sv

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list


mergerepos issue

2009-06-05 Thread Jitesh Shah
Hi all,
I have attached an external repo to one of my build tags. After
attaching the repo, I issued a koji regen-repo tag. This is what I
get:

1348/2199 - kde-l10n-Walloon-4.2.2-1.fc11.noarch
1349/2199 - kde-l10n-Lithuanian-4.2.2-1.fc11.noarch
1350/2199 - 1:perl-Error-0.17015-2.fc11.noarch
Traceback (most recent call last):
  File /usr/libexec/kojid/mergerepos, line 241, in module
main(sys.argv[1:])
  File /usr/libexec/kojid/mergerepos, line 236, in main
merge.write_metadata()
  File /usr/libexec/kojid/mergerepos, line 216, in write_metadata
mdgen.doPkgMetadata()
  File /usr/lib/python2.5/site-packages/createrepo/__init__.py, line 364, in 
doPkgMetadata
self.writeMetadataDocs(packages)
  File /usr/lib/python2.5/site-packages/createrepo/__init__.py, line 527, in 
writeMetadataDocs
self.primaryfile.write(po.xml_dump_primary_metadata())
  File /usr/lib/python2.5/site-packages/yum/packages.py, line 1015, in 
xml_dump_primary_metadata
msg += misc.to_unicode(self._dump_format_items())
  File /usr/lib/python2.5/site-packages/yum/packages.py, line 894, in 
_dump_format_items
msg += self._dump_pco('provides')
  File /usr/lib/python2.5/site-packages/yum/packages.py, line 919, in 
_dump_pco
msg += pcostring
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 28: 
ordinal not in range(128)

Unicode error?
I don't get it!
Any pointers?

Regards,
Jitesh

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list


Re: mergerepos issue

2009-06-05 Thread Jitesh Shah
Aaah .. some RPMs have unicode in their 'provides' tag which causes this
problem. Temporarily, I have removed those from the external repo and it
works fine :)

Jitesh


On Fri, 2009-06-05 at 06:46 -0700, Jitesh Shah wrote:
 Hi all,
 I have attached an external repo to one of my build tags. After
 attaching the repo, I issued a koji regen-repo tag. This is what I
 get:
 
 1348/2199 - kde-l10n-Walloon-4.2.2-1.fc11.noarch
 1349/2199 - kde-l10n-Lithuanian-4.2.2-1.fc11.noarch
 1350/2199 - 1:perl-Error-0.17015-2.fc11.noarch
 Traceback (most recent call last):
   File /usr/libexec/kojid/mergerepos, line 241, in module
 main(sys.argv[1:])
   File /usr/libexec/kojid/mergerepos, line 236, in main
 merge.write_metadata()
   File /usr/libexec/kojid/mergerepos, line 216, in write_metadata
 mdgen.doPkgMetadata()
   File /usr/lib/python2.5/site-packages/createrepo/__init__.py, line 364, 
 in doPkgMetadata
 self.writeMetadataDocs(packages)
   File /usr/lib/python2.5/site-packages/createrepo/__init__.py, line 527, 
 in writeMetadataDocs
 self.primaryfile.write(po.xml_dump_primary_metadata())
   File /usr/lib/python2.5/site-packages/yum/packages.py, line 1015, in 
 xml_dump_primary_metadata
 msg += misc.to_unicode(self._dump_format_items())
   File /usr/lib/python2.5/site-packages/yum/packages.py, line 894, in 
 _dump_format_items
 msg += self._dump_pco('provides')
   File /usr/lib/python2.5/site-packages/yum/packages.py, line 919, in 
 _dump_pco
 msg += pcostring
 UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 28: 
 ordinal not in range(128)
 
 Unicode error?
 I don't get it!
 Any pointers?
 
 Regards,
 Jitesh
 
 --
 Fedora-buildsys-list mailing list
 Fedora-buildsys-list@redhat.com
 https://www.redhat.com/mailman/listinfo/fedora-buildsys-list

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list


Which RPM does mergerepo prefer?

2009-05-28 Thread Jitesh Shah
Hi,
I have attached an external repo to a build tag (Just trying out some
hand-built RPMs). Now, if an RPM is present *both* in the build tag as
well as the external repo, which one does mergerepos pick?

Is the decision based on version comparison (the greater version wins),
or does the one in the build tag always get preference over the external
repo (irrespective of the version)?

If it is the latter, how do I tell mergerepos to prefer external repo
over the build tag? (or atleast use version comparisons rather than
preferring build tag)

Jitesh


--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list


RE: Is koji the right build tool for me? and some newbie questions

2009-02-24 Thread Jitesh Shah
Hi Zubin, 
 
 
 The problem here is python 2.5 since my build machine runs on RedHat
 Enterprise Linux 4 (ES) which uses an older version of python and I
 can’t seem to find a python 2.5 RPM that will install on this OS.

Well, take the git head of koji and run a make rpm in your
environment. I am running a koji's version on python 2.4 (and it is
working fine).


  
 
 Also what is python(abi)? Do I have to install a full python 2.5 RPM
 to satisfy this dependency?

You can do a --nodeps as soon as your dependency reduces to only
python(abi). It is provided on fedora's python RPMs. 

 
  
 
 Zubin
 

Jitesh



--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list

Re: Koji: ServerOffline

2009-01-22 Thread Jitesh Shah
Hi,
So, I had koji running and building packages for me for nearly a
fortnight. And it worked like a charm!

I double-checked all the configuration and it is intact. There is the
and entry in pg_hba.conf that trusts koji.

I run psql command from the koji user on the same machine where
koji-hub is running. So, psql uses the default values for DBName and
DBUser. (which are koji and koji respectively) (And I don't use the
host option). Also, I've checked that DBName and DBUser configuration
are OK in the kojihub.conf

On a different note, how does one debug a script which uses rpc calls
and the error is on the server side? i.e. the debugger will run on the
caller side, so, how do we debug the script that is executed on the
server? (Except inserting write-to-file commands in the server script)
Also, does koji maintain a logfile?... I wasn't able find it anywhere. 

Jitesh



On Thu, 2009-01-22 at 08:45 +0100, Oliver Falk wrote:
 Jitesh Shah wrote:
  So, this morning I moved to a newer version of koji. Reconfigured
  everything (restarted apache after re-configuring koji-hub) and quite
  surprisingly, I still get the same error!
  
  So, if reinitialising both, postgresql and koji, doesn't do the trick, I
  wonder what might have gone wrong.
  (Just as a matter of curiosity, I even checked with ipcs that there are
  no dangling shared memory segments. There aren't any.)
 
 The settings in /etc/httpd/conf.d/kojihub.conf are correct I guess?
 Esp. DBName, DBUser, DBHost? And your /var/lib/pgsql/data/pg_hba.conf is 
 also OK?
 
 And you can connect via command line? psql -U DBUser -h DBHost DBName?
 
 The error is quite clear. kojihub is not able to connect to the 
 database, so something is wrong with the config... :-(
 
 -of
 
 --
 Fedora-buildsys-list mailing list
 Fedora-buildsys-list@redhat.com
 https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list

Re: Koji: ServerOffline

2009-01-22 Thread Jitesh Shah
Hi,
Yes, I can successfully connect to the psql database using tcp sockets
too. Here is the snippet of the interaction in the terminal.

[k...@linux-dev ~]$ psql -U koji -h localhost -d koji
Welcome to psql 8.2.11, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
   \h for help with SQL commands
   \? for help with psql commands
   \g or terminate with semicolon to execute query
   \q to quit

koji= 


I can view all the tables with \d. So, it is connected all-right. Btw,
I also checked in the users permissions and user_perms tables to
verify that koji user is indeed the admin and has all the required
privileges.

Jitesh

On Thu, 2009-01-22 at 02:18 -0800, Toshio Kuratomi wrote:
 Jitesh Shah wrote:
  Hi,
  So, I had koji running and building packages for me for nearly a
  fortnight. And it worked like a charm!
  
  I double-checked all the configuration and it is intact. There is the
  and entry in pg_hba.conf that trusts koji.
  
  I run psql command from the koji user on the same machine where
  koji-hub is running. So, psql uses the default values for DBName and
  DBUser. (which are koji and koji respectively) (And I don't use the
  host option). Also, I've checked that DBName and DBUser configuration
  are OK in the kojihub.conf
  
 It sounds like you're running the koji db on the same machine as the
 kojihub?  Just to be sure you're testing the same thing with psql as
 koji is going to run, try  psql with the -h HOST option.  The reason is
 that psql without the -h will try to use unix sockets to connect on the
 local machine.  koji, though, is going to use a tcp connection, not a
 socket.
 
 -Toshio
 
 --
 Fedora-buildsys-list mailing list
 Fedora-buildsys-list@redhat.com
 https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list

Re: Koji: ServerOffline

2009-01-22 Thread Jitesh Shah

On Thu, 2009-01-22 at 17:17 +0100, Oliver Falk wrote:
 Mike McLean wrote:

 I wonder if it would log this error in a way you know what's going on :-)
 
 Jitesh, can you check the logs as suggested by Mike, although it's fixed 
 now, I'd like to know if you see the error there...


I checked the logs. There is just a python traceback and the actual
error ServerOffline: Database Outage' (This is with KojiDebug off)

With KojiDebug turned on, it additionally shows the queries executed and
the time taken for each.

Nothing that would point to an incorrect configuration or a failure in
database connection. 

Jitesh

 
 [ ... ]
 
 -of
 
 --
 Fedora-buildsys-list mailing list
 Fedora-buildsys-list@redhat.com
 https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list

Koji: ServerOffline

2009-01-21 Thread Jitesh Shah
Hi,
I've been running a local koji instance at my workplace. It worked
absolutely fine for a fortnight. But, since Monday, I am getting this
error : ServerOffline: database outage for any CLI command that I try
to execute. 

I initially suspected that it might be because koji cannot connect to
the database. But, I checked that I can login to the database through
command-line. 
 psql

Also, I wrote a small script in python which mimics koji's method of
connecting to the database (with reference
to /usr/lib/python2.5/site-packages/koji/db.py) and it works fine!

Just to make sure, I restarted postgresql service in vain.
Re-initialised the database (Remove /var/lib/pgsql and run service
postgresql initdb and all the other steps) to no avail.

I started seeing this problem after a run of the koji-shadow script. It
exited abnormally giving this very error. Since then, I cannot even
access koji-cli.. neither koji-web.

I have been tracing through the koji scripts and I see that the SSL
login succeeds and then the very first rpc call: getAPIVersion fails.
Wireshark shows that the koji-hub replies with Connection: close to
the getAPIVersion call.

Any idea as to what is going wrong?
Any pointers?

Jitesh
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list

Re: Koji: ServerOffline

2009-01-21 Thread Jitesh Shah
Hi,
Thank you for the quick reply Oliver. 

So, this morning I moved to a newer version of koji. Reconfigured
everything (restarted apache after re-configuring koji-hub) and quite
surprisingly, I still get the same error!

So, if reinitialising both, postgresql and koji, doesn't do the trick, I
wonder what might have gone wrong.
(Just as a matter of curiosity, I even checked with ipcs that there are
no dangling shared memory segments. There aren't any.)

Jitesh

On Thu, 2009-01-22 at 08:16 +0100, Oliver Falk wrote:
 Hi Jitesh!
 
 Jitesh Shah wrote:
  Hi,
  I've been running a local koji instance at my workplace. It worked
  absolutely fine for a fortnight. But, since Monday, I am getting this
  error : ServerOffline: database outage for any CLI command that I try
  to execute.
  
  I initially suspected that it might be because koji cannot connect to
  the database. But, I checked that I can login to the database through
  command-line.
psql
  
  Also, I wrote a small script in python which mimics koji's method of
  connecting to the database (with reference
  to /usr/lib/python2.5/site-packages/koji/db.py) and it works fine!
  
  Just to make sure, I restarted postgresql service in vain.
  Re-initialised the database (Remove /var/lib/pgsql and run service
  postgresql initdb and all the other steps) to no avail.
  
  I started seeing this problem after a run of the koji-shadow script. It
  exited abnormally giving this very error. Since then, I cannot even
  access koji-cli.. neither koji-web.
  
  I have been tracing through the koji scripts and I see that the SSL
  login succeeds and then the very first rpc call: getAPIVersion fails.
  Wireshark shows that the koji-hub replies with Connection: close to
  the getAPIVersion call.
  
  Any idea as to what is going wrong?
  Any pointers?
 
 You have not written if you have tried to restart Apache. koji(hub) has 
 no auto-reconnect if it looses connection to the database. So if for 
 whatever reason it lost the connection to PostgreSQL, it will never 
 reconnect. You have to manually restart Apache!
 
 -of
 
 --
 Fedora-buildsys-list mailing list
 Fedora-buildsys-list@redhat.com
 https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list