[BUG] Koji and Lustre
by Thomas Guthmann
Hey guys,
We found a bug(?) in listTaskOutput (/usr/share/koji-hub/kojihub.py)
when used with a Lustre filesystem. This function parses all attributes
of every file of a build and is used when you want to display
build.log/root.log through the web interface. Everything returned by
listTaskOutput is returned through XML-RPC and as a result we had this :
An error has occurred while processing your request.
Fault: <Fault 1: 'exceptions.OverflowError: long int exceeds XML-RPC
limits'>
Traceback (most recent call last):
File "/usr/share/koji-web/lib/kojiweb/publisher.py", line 16, in
publish_object
return old_publish_object(req, object)
File "/usr/lib64/python2.4/site-packages/mod_python/publisher.py",
line 412, in publish_object
return publish_object(req,util.apply_fs_data(object, req.form,
req=req))
File "/usr/lib64/python2.4/site-packages/mod_python/util.py", line
439, in apply_fs_data
return object(**args)
File "/usr/share/koji-web/scripts/index.py", line 649, in getfile
output = server.listTaskOutput(taskID, stat=True)
File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1468,
in __call__
return self.__func(self.__name,args,opts)
File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1718,
in _callMethod
raise err
Fault: <Fault 1: 'exceptions.OverflowError: long int exceeds XML-RPC
limits'>
The issue comes from the st_dev value gathered by getStat (stat). In
Lustre this value can be very high and that's why it complains. To fix
that, we used the same condition than st_size, we cast the value as a
string. See attached patch.
Example (see 'Device:' the value after the '/'):
# stat build.log
File: `build.log'
Size: 106021 Blocks: 208 IO Block: 2097152 regular file
Device: e04ae70eh/3763005198d Inode: 721664 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 48/ apache) Gid: ( 48/ apache)
Access: 2010-07-13 10:44:40.000000000 +1000
Modify: 2010-07-12 12:54:15.000000000 +1000
Change: 2010-07-12 12:54:52.000000000 +1000
# That's what is read by listTaskOutput
relfilename=build.log ATTR=st_atime GETATTR=1278981616
relfilename=build.log ATTR=st_blksize GETATTR=2097152
relfilename=build.log ATTR=st_blocks GETATTR=208
relfilename=build.log ATTR=st_ctime GETATTR=1278903292
relfilename=build.log ATTR=st_dev GETATTR=3763005198 <----- /!\
relfilename=build.log ATTR=st_gid GETATTR=48
relfilename=build.log ATTR=st_ino GETATTR=721664
relfilename=build.log ATTR=st_mode GETATTR=33188
relfilename=build.log ATTR=st_mtime GETATTR=1278903255
relfilename=build.log ATTR=st_nlink GETATTR=1
relfilename=build.log ATTR=st_rdev GETATTR=0
relfilename=build.log ATTR=st_size GETATTR=106021
relfilename=build.log ATTR=st_uid GETATTR=48
Hope it helps, lost a good amount of time on that one :)
Cheers,
Thomas
12 years
Strange mock build failure due to typo
by Paul Howarth
Hi,
today I have been preparing an update to perl-Math-Pari and came across
a very strange build failure whilst doing a local mock build on a Fedora
13 x86_64 host. My package built successfully on x86_64 but when I tried
to build for i386, the build failed during %setup but without any
diagnostics. The SRPM was installed but no attempt to install its build
requirements was made. The root.log showed an exit status of 0 for all
commands that had been run.
After much experimentation bisecting the changes I had made, I
discovered that a typo in the changelog entry was the culprit: I had set
the year to 2100 instead of 2010. So it would appear that somewhere in
the mock/yum/rpm stack there may be a year 2038 problem waiting to bite
us (though I suspect there may not be too many 32-bit builds happening
by then).
Seriously though, it would be nice to have better diagnostics for this
and perhaps an rpmlint check for changelog entries in the future?
Paul.
12 years, 8 months
email notifications
by Florian La Roche
Hallo,
With koji-1.4 running on RHEL6-beta2, some email notifications
are not sent out correctly:
Traceback (most recent call last):
File "/usr/sbin/kojid", line 1437, in runTask
response = (handler.run(),)
File "/usr/sbin/kojid", line 1513, in run
return self.handler(*self.params,**self.opts)
File "/usr/sbin/kojid", line 3649, in handler
message = message.encode('utf-8')
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 546: ordinal not in range(128)
Thie seems to happen e.g. on dejavu-fonts, ctags, crontabs,
cronie, amanda, akonadi.
regards,
Florian La Roche
12 years, 12 months
New Yum release might have broken Pungi on f13.
by William F. Acker WB2FLW +1 303 722 7209
Hi all,
After the latest round of updates, when trying to make a new spin, I
get the following.
Warning: Reusing existing destination directory.
Traceback (most recent call last):
File "/usr/bin/pungi", line 216, in <module>
main()
File "/usr/bin/pungi", line 86, in main
mypungi._inityum() # initialize the yum object for things that need it
File "/usr/lib/python2.6/site-packages/pypungi/__init__.py", line 165, in _inityum
self.ayum.repos.setCacheDir(self.ayum.conf.cachedir)
File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 814, in <lambda>
repos = property(fget=lambda self: self._getRepos(),
File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 539, in _getRepos
self.getReposFromConfig()
File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 418, in getReposFromConfig
repo_config_age = self.conf.config_file_age
AttributeError: 'YumConf' object has no attribute 'config_file_age'
Thanks.
--
Bill in Denver
13 years, 1 month
Subtle change in default behaviour or did I miss something in the docs?
by Bryce
It's been a while since I played with the koji buildsystem so since I've
a spare box in the backroom doing nothing and I'm between projects, I
thought I'd have a shot at getting a standalone system up and running
using a clean minimal fc13 image.
koji-1.4.0-2.fc13.noarch
postgresql-8.4.4-1.fc13.x86_64
httpd-2.2.16-1.fc13.x86_64
mock-1.1.3-1.fc13.noarch
I've a fairly large chain of scripts that automatically sets up the
initial system, ie the users, the postgresql schema's (and upgrades),
the ssl configs, certificate files, the config file changes, firewall
changes, preloading the repo's and other tweaks so that I can easily
trash the system and rebuild it from scratch without getting mired in
the lengthy set-up procedure and that has worked fine for fc11/fc12
In fc13, when koji starts creating the FS structures for the chroot
under /var/lib/mock, it will attempt to create a
/var/cache/mock/<tag-X-Y>/filesystems file which it can't do since
/var/cache/mock/<tag-X-Y> was never created. The cheap way out of that
is to set config_opts['cache_topdir'] = '/var/lib/mock' instead of
/var/cache/mock. That option didn't need fiddling with in fc12 so I'm
unsure if this was a change in koji's code base or something unrelated.
The following is the product of being unable to email a notification
because it can't connect to the mail host... I can think of dozens of
reasons why this could occur but it may be better to stick in an
exception to queue them up internally for retry or at least spit out
'Hey! I can't talk to your mailhost!" and fail the BuildNotify task
Traceback (most recent call last):
File "/usr/sbin/kojid", line 1437, in runTask
response = (handler.run(),)
File "/usr/sbin/kojid", line 1513, in run
return self.handler(*self.params,**self.opts)
File "/usr/sbin/kojid", line 3651, in handler
*server = smtplib.SMTP(options.smtphost)*
File "/usr/lib64/python2.6/smtplib.py", line 239, in __init__
(code, msg) = self.connect(host, port)
File "/usr/lib64/python2.6/smtplib.py", line 295, in connect
self.sock = self._get_socket(host, port, self.timeout)
File "/usr/lib64/python2.6/smtplib.py", line 273, in _get_socket
return socket.create_connection((port, host), timeout)
File "/usr/lib64/python2.6/socket.py", line 514, in create_connection
raise error, msg
error: [Errno 111] Connection refused
The main problem I keep hitting, is mainly with noarch packages.
BuildError: error building package (arch noarch), mock exited with
status 1; see build.log for more information
however when I go to look all I see in the log is the single line
Mock Version: 1.1.3
The root.log doesn't show anything interesting either
however if I manually poke the rpm through with mock, it works.
ie
[root@whitebishop ~]# mock -r koji/el5-ga-build-9-44 --rebuild
~/buildsys-macros-5-2.ovs.src.rpm
[root@whitebishop ~]# ls -l /var/lib/mock/el5-ga-build-9-44/result
total 48
-rw-rw-r--. 1 root mock 2593 Aug 19 11:57 build.log
-rw-r--r--. 1 root mock 2283 Aug 19 11:57
buildsys-macros-5-2.ovs.noarch.rpm
-rw-r--r--. 1 root mock 2147 Aug 19 11:57 buildsys-macros-5-2.ovs.src.rpm
-rw-rw-r--. 1 root mock 32152 Aug 19 11:57 root.log
-rw-rw-r--. 1 root mock 193 Aug 19 11:57 state.log
[root@whitebishop ~]# cat
/var/lib/mock/el5-ga-build-9-44/result/build.log
Mock Version: 1.1.3
ENTER do(['bash', '--login', '-c', 'rpmbuild -bs --target i386
--nodeps builddir/build/SPECS/buildsys-macros.spec'], False,
'/var/lib/mock/el5-ga-build-9-44/root/', None, 86400, True, 0, 0, 484,
None, logger=<mock.trace_decorator.getLog object at 0x1f2abd0>)
Executing command: ['bash', '--login', '-c', 'rpmbuild -bs --target
i386 --nodeps builddir/build/SPECS/buildsys-macros.spec']
warning: Could not canonicalize hostname: whitebishop
Building target platforms: i386
Building for target i386
Wrote: /builddir/build/SRPMS/buildsys-macros-5-2.ovs.src.rpm
Child returncode was: 0
LEAVE do -->
I can't reason out why there would be any difference unless it's passing
--arch noarch.. in which case
[root@whitebishop ~]# mock -r koji/el5-ga-build-9-44 --arch noarch
--rebuild ~/buildsys-macros-5-2.ovs.src.rpm
ERROR: Cannot build target noarch on arch x86_64
But then I'd expect to have the error line in the build.log which I
don't... so I'm a bit flummoxed if this is what has happened or not.
Ideas?
Phil
=--=
13 years, 1 month
error reading package header
by Paul B Schroeder
I've been happily building my new distro packages in koji for the last
couple of months. And still can seem to build any package without
issue. With one exception. I've recently run into an issue when I
tried to build anaconda for the first time.
kojid is not reading the header of source RPM that gets created for
whatever reason. When I go into the /mnt/koji/work/tasks directory and
find the source RPM that was created from the buildSRPMFromSCM task, I
can run command line rpm commands against it without any problem. So it
seems that the issue isn't with the RPM iself, but with kojid reading it.
Again, I do not have this issue with no other package that I build in
koji. Any ideas as to what may be going on?
Here is the error output I get from running koji build on the command line:
Created task: 1010
Task info: http://koji.aus.vbridges.com/koji/taskinfo?taskID=1010
Watching tasks (this may be safely interrupted)...
1010 build (LEAF-1.3.0,
/svn/cM4yhIeeur34JreJe5aVNr/LEAF:LEAF-1.3.0/anaconda:HEAD): free
1010 build (LEAF-1.3.0,
/svn/cM4yhIeeur34JreJe5aVNr/LEAF:LEAF-1.3.0/anaconda:HEAD): free -> open
(kojibuilder2)
1011 buildSRPMFromSCM
(/svn/cM4yhIeeur34JreJe5aVNr/LEAF:LEAF-1.3.0/anaconda:HEAD): free
1011 buildSRPMFromSCM
(/svn/cM4yhIeeur34JreJe5aVNr/LEAF:LEAF-1.3.0/anaconda:HEAD): free ->
open (kojibuilder2)
1011 buildSRPMFromSCM
(/svn/cM4yhIeeur34JreJe5aVNr/LEAF:LEAF-1.3.0/anaconda:HEAD): open
(kojibuilder2) -> closed
0 free 1 open 1 done 0 failed
1010 build (LEAF-1.3.0,
/svn/cM4yhIeeur34JreJe5aVNr/LEAF:LEAF-1.3.0/anaconda:HEAD): open
(kojibuilder2) -> FAILED: Fault: <Fault 1: 'Traceback (most recent call
last):\n File "/usr/sbin/kojid", line 1285, in runTask\n response =
(handler.run(),)\n File "/usr/sbin/kojid", line 1361, in run\n
return self.handler(*self.params,**self.opts)\n File "/usr/sbin/kojid",
line 1822, in handler\n h = self.readSRPMHeader(srpm)\n File
"/usr/sbin/kojid", line 1895, in readSRPMHeader\n h =
koji.get_rpm_header(fo)\n File
"/usr/lib/python2.6/site-packages/koji/__init__.py", line 770, in
get_rpm_header\n hdr = ts.hdrFromFdno(fo.fileno())\n File
"/usr/lib64/python2.6/site-packages/rpm/transaction.py", line 154, in
hdrFromFdno\n raise rpm.error("error reading package header")\nerror:
error reading package header\n'>
0 free 0 open 1 done 1 failed
1010 build (LEAF-1.3.0,
/svn/cM4yhIeeur34JreJe5aVNr/LEAF:LEAF-1.3.0/anaconda:HEAD) failed
make: *** [scratch-build] Error 1
And some package versions:
[root@kojibuilder2 ~]# rpm -q koji-builder
koji-builder-1.3.2-1.fc13.noarch
[root@kojibuilder2 ~]# rpm -q rpm
rpm-4.8.1-2.fc13.x86_64
Thanks in advance... Paul...
--
---
Paul B Schroeder
<paulbsch "at" vbridges "dot" com>
13 years, 1 month
First impressions of mock 1.1.3
by Paul Howarth
Good:
I no longer need my selinux workaround:
config_opts['files']['selinux/enforce'] = "0"
Bad:
New option max_fs_size for tmpfs plugin doesn't seem to have a default
value; at least I get a traceback if I use my old config, which had
just:
config_opts['plugin_conf']['tmpfs_enable'] = True
config_opts['plugin_conf']['tmpfs_opts']['required_ram_mb'] = 2048
Root cache is huge because of cache files getting copied to the cache.
The following change restored sanity:
--- /usr/lib/python2.6/site-packages/mock/plugins/root_cache.py.orig 2010-08-03 22:04:48.000000000 +0100
+++ /usr/lib/python2.6/site-packages/mock/plugins/root_cache.py 2010-08-08 18:10:42.175478756 +0100
@@ -118,6 +118,8 @@
"--exclude=./proc",
"--exclude=./sys",
"--exclude=./dev",
+ "--exclude=./tmp",
+ "--exclude=./var/cache/yum",
"."],
shell=False
)
Mock always exits with non-zero exit code due to problems uumounting
filesystems, leading my build scripts to declare the builds as duds:
DEBUG backend.py:520: Copying packages to result dir
DEBUG backend.py:639: umount -n /var/lib/mock/city-fan-rawhide-i686/root/proc
DEBUG util.py:289: Executing command: umount -n /var/lib/mock/city-fan-rawhide-i686/root/proc
DEBUG util.py:255: umount: /var/lib/mock/city-fan-rawhide-i686/root/proc: device is busy.
DEBUG util.py:255: (In some cases useful info about processes that use
DEBUG util.py:255: the device is found by lsof(8) or fuser(1))
DEBUG util.py:328: Child returncode was: 1
DEBUG backend.py:639: umount -n /var/lib/mock/city-fan-rawhide-i686/root/sys
DEBUG util.py:289: Executing command: umount -n /var/lib/mock/city-fan-rawhide-i686/root/sys
DEBUG util.py:328: Child returncode was: 0
DEBUG backend.py:639: umount -n /var/lib/mock/city-fan-rawhide-i686/root/var/cache/yum
DEBUG util.py:289: Executing command: umount -n /var/lib/mock/city-fan-rawhide-i686/root/var/cache/yum
DEBUG util.py:328: Child returncode was: 0
DEBUG backend.py:639: umount -n /var/lib/mock/city-fan-rawhide-i686/root/tmp/ccache
DEBUG util.py:289: Executing command: umount -n /var/lib/mock/city-fan-rawhide-i686/root/tmp/ccache
DEBUG util.py:328: Child returncode was: 0
DEBUG backend.py:639: umount -n /var/lib/mock/city-fan-rawhide-i686/root/proc/filesystems
DEBUG util.py:289: Executing command: umount -n /var/lib/mock/city-fan-rawhide-i686/root/proc/filesystems
DEBUG util.py:328: Child returncode was: 0
DEBUG backend.py:639: umount -n /var/lib/mock/city-fan-rawhide-i686/root/dev/pts
DEBUG util.py:289: Executing command: umount -n /var/lib/mock/city-fan-rawhide-i686/root/dev/pts
DEBUG util.py:328: Child returncode was: 0
DEBUG backend.py:639: umount -n /var/lib/mock/city-fan-rawhide-i686/root/dev/shm
DEBUG util.py:289: Executing command: umount -n /var/lib/mock/city-fan-rawhide-i686/root/dev/shm
DEBUG util.py:328: Child returncode was: 0
DEBUG util.py:289: Executing command: ['umount', '-n', '/var/lib/mock/city-fan-rawhide-i686/root/']
DEBUG util.py:255: umount: /var/lib/mock/city-fan-rawhide-i686/root/: device is busy.
DEBUG util.py:255: (In some cases useful info about processes that use
DEBUG util.py:255: the device is found by lsof(8) or fuser(1))
DEBUG util.py:328: Child returncode was: 1
DEBUG util.py:97: kill orphans
I'll have to get my script to ignore mock's exit status for now
and check for built packages in the result directory I think.
Paul.
13 years, 1 month
[PATCH] _umountall unmounts everything
by Alan Franzoni
Hello,
I had already submitted that to the bug tracker and I though it was
approved, but I think it didn't get applied:
http://fedorahosted.org/mock/ticket/4
I've got it updated to work with the current master and to solve an
issue with tmpfs as well. I'm attaching it as well.
this should address Paul Howarth patch 2/5 as well; it seems pointless
to me to reverse a structure and then reverse it again after using it,
it's better to have a copy of it reversed "on the fly" when using it.
BTW, Paul, how many times is _umountall() called in your code? I thought
it ought to be called just once!
--
Alan Franzoni
contact me at public(a)[mysurname].eu
13 years, 1 month
fedpkg upstream
by Roland McGrath
I talked a bit with Jesse on IRC about this during mayhem week, and said
I'd post here about it at some point.
Some of us were using the old Makefile.common feature for tracking upstream
sources. It was a dismal idiosyncratic kludge like everything else there,
but it was handy. I'll briefly explain how it works as background, which
is not to suggest that we shouldn't solve the same problem for package
maintainers in an entirely different way now.
In the old scheme, you'd set up these things in your package module:
* a "mirrors" file containing a list of URLs
* a list of upstream file names, either in an "upstream" file
or in the Makefile variable UPSTREAM
* an "upstream-key.gpg" file
* set the UPSTREAM_CHECKS variable in Makefile
Those things are stored in the pkgs CVS. For example, the kernel uses an
"upstream" file that gets editted and committed when the base version
changes; whereas elfutils just has in Makefile:
UPSTREAM_FILES = $(NAME)-$(VERSION).tar.bz2
upstream:;
Then you get new make targets:
* make download
This downloads the files in upstream file list if they don't exist
locally, and then checks their signatures against the local .sig or .sign
or whatever files (as UPSTREAM_CHECKS is set).
* make rebase
This does 'make download' and then 'make upload FILES=...' with the
upstream files list. It then does 'cvs add' on all the signature files
just downloaded/checked.
* make new-base
Same, but does new-sources instead of upload, i.e. wipe the old sources
file first.
So, for example, my procedure with elfutils, say when going from 0.147 to
0.148, is:
# edit elfutils.spec, change Version to 0.148
make new-base
cvs rm -f elfutils-0.147.tar.bz2.sig
cvs commit -m'Update to 0.148'
et voila. For the kernel, we have some scripts that edit the "upstream"
file automagically, so it's similarly seamless. (For me in elfutils,
that "cvs rm" is the only real seam.)
The "mirrors" file gives numerous URLs of containing directories where
downloads of the files in the list are attempted. For elfutils, I just
have a list of one. For the kernel, we have a list that is just several
subdirectories of http://ftp.kernel.org/pub/linux/kernel/v2.6 and just so
that we don't have to keep track of which tarballs and patch files get
stashed where up there. Frankly, I think we could just make the
kernel.spec URLs for files just be exactly correct with some more care and
macro/script magic. I am not aware of any case where someone really needs
to look at multiple mirrors to refresh their upstream files.
So, what about that makes any sense?
I see the use in upstream-key.gpg being kept in the repo along with the
settings of upstream URLs and such. That makes it easy for a new
maintainer to pick things up cold and not need to intuit whose key to go
fetch from a keyserver.
I don't see any benefit to keeping detached signature files in the package
repo. Once you've checked the signatures and decided that your local files
are what you want, then you commit the sources file with their md5sums. So
anyone later wanting to make sure they have the right thing can just do
'md5sum -c sources' and know what files were meant when the pkgs commit was
made. It doesn't really matter if there is some upstream authority's
signature that says they are kosher too, they are the files Fedora is using.
So, that's all background. Here is what I think would be nice to have in
the new world order:
* AFAICT current rpm handles URLs in PatchN: lines as well as SourceN:
lines. We can just put proper URLs for every upstream file in our .spec
files. For most of bothering to do this, upstream is pretty sensible, so
this is really easy with %{version} macros, and mostly we already have
these URLs in there.
I don't see any need for an alternate URL list off hand (no "mirrors"
file). It might be worthwhile to take a survey via grep on the final
/cvs/pkgs state for all the pkgs with upstream-key.gpg files, upstream
files, UPSTREAM_{FILES,CHECKS} variable settings in Makefile, mirrors
files. We can see how much this is actually used, and if anybody
actually has a mirrors file listing multiple alternate download sites for
the same file.
* rpmdev-download script
This could be a fedpkg subcommand, but it's just the local portion and
actually doesn't really have anything to do with Fedora specifically.
I'm suspicious that there must already be something that makes use of the
URLs in Source/Patch .spec headers in some useful fashion, but I can't
really find anything off hand that does.
This would look at the (macro-expanded) .spec file and list all the files
that are given with a URL rather than just a local file name. For each
of those files, it tries to download it from the URL. If there is a
local upstream-key.pgp file (or with a switch, or whatever), then it also
tries to download a URL.{sig,sign,asc} file and verify that the file just
downloaded matches its signature and that's signed by a public key in the
upstream-key.pgp keyring--if not, it removes the download and fails. If
there is no upstream-key.pgp file, it can look for a URL.md5 file and
check it against itself. (The old Makefile.common supports .md5 files,
though I actually only know of uses with .sign and .sig files.) If all
is downloaded and verified, then it emits an md5sum/name list of all the
files that had URLs in the .spec file, on stdout or perhaps directly
writing "sources".
A 'fedpkg new-base' subcommand could run "rpmdev-download foo.spec > sources".
* pre-update hook on pkgs.fedoraproject.org repos
(The gitolite "custom hooks" documentation suggests it is easy to write a
script and make all existing/new repos point to it to run after the ACL
enforcement hook succeeds.)
This can start out independent of the upstream-download stuff.
Firstly, it checks each new head to validate its tree's "sources" file.
If the format is invalid, or any md5sum+name is not already present in
the lookaside cache, refuse the push.
Second, it can macro-expand and parse the .spec file (I assume there is
some python for this already), with appropriate dist macros for the
branch. This is the same step rpmdev-download does, but here we get the
complete list of Source and Patch files, both those with URLs and those
without. Check that the tree contains the file if it's a local file name,
and that the sources file contains the file name if it's a URL.
Of course, we may want to consider various other .spec checks at some
point that would go here too. But that's beside the point here.
* Auto-downuploading!
Automating the process of downloading big tarballs from well-connected
servers to my humble home workstation and then uploading them to other
well-connected servers was not what I actually wanted to do. (I used to
usually log into a machine in an RH office to do this step so as not to
suffer the slow upload delay from home, but between current Fedora
infrastructure's separate location and slightly better ISP service at
home, I tend to use the easy stuff at home and just sit and wait a little
while.) When I'm downloading from fedorahosted.org to upload, it's
especially ironic, because I'm pretty sure the two servers are in the
same rack, if not the same machine!
What that pre-update hook should really do after it gets the list of
files named by URLs in .spec and verifies they are listed in the sources
file, is check if each one is already in the lookaside cache, and if it's
not, go get it. You have the upstream URL from .spec and you have the
md5sum from sources. You can fetch the file and verify it's what the
committer meant. Just do it!
This could be structured so the download from upstream is done on the
lookaside cache server itself, which is obviously optimal. Since they
are all closely colocated, I assume it isn't really any worse overall to
have the git server machine or some other worker (a koji job?) do the
download and upload via the existing lookaside server mechanism. I don't
care about the implementation details.
To avoid dangers either from abuse or from strange errors, there could be
an administrative list of acceptable upstream URL patterns. (The dangers
would be provoking strange CGI hits on the web from Fedora servers, and
that sort of thing.) This can include all fedorahosted.org and
kernel.org and whatever the normal sourceforge download URL schema is
this week, etc. It's probably sufficient to hand-adminster this URL
filter list and let package maintainers use rel-eng tickets for
additions. If there turns out to be an actual need that the "mirrors"
file was serving, then this pattern list could instead be a table to
rewrite a canonical URL to a list of alternate URLs to try downloading
from (with rewrite-to-self on matching fedorahosted.org and the like,
and error on no match).
All that seems like it shouldn't be all that much work (for someone else ;-).
And it would be not merely a restoration of what we've been used to, but
both much cleaner and much better!
Thanks,
Roland
13 years, 1 month
