QA at Fedora asleep? Many i386 packages in x86_64 FC2 updates
by Bob Deblier
There's a whole list of i386 packages in the core/updates/2/x86_64
directory (on download.fedora.redhat.com and ftp.belnet.be - please
check other mirrors):
-rw-r--r-- 103151 Jun 3 16:52 cups-libs-1.1.20-11.1.i386.rpm
-rw-r--r-- 103405 Sep 28 16:34 cups-libs-1.1.20-11.3.i386.rpm
-rw-r--r-- 103504 Oct 5 17:10 cups-libs-1.1.20-11.4.i386.rpm
-rw-r--r-- 487384 Oct 19 15:44 glib2-2.4.7-1.1.i386.rpm
-rw-r--r-- 4571957 Oct 19 15:45 gtk2-2.4.13-2.1.i386.rpm
-rw-r--r-- 4416526 Sep 15 17:52 gtk2-2.4.7-2.4.i386.rpm
-rw-r--r-- 4415614 Sep 16 06:51 gtk2-2.4.7-2.5.i386.rpm
-rw-r--r-- 4415644 Sep 23 18:16 gtk2-2.4.7-2.6.i386.rpm
-rw-r--r-- 494316 Jun 4 20:50 krb5-libs-1.3.3-7.i386.rpm
-rw-r--r-- 495462 Aug 31 20:11 krb5-libs-1.3.4-6.i386.rpm
-rw-r--r-- 152706 Jun 18 16:05 libpng-1.2.5-5.i386.rpm
-rw-r--r-- 153140 Aug 4 17:38 libpng-1.2.5-8.i386.rpm
-rw-r--r-- 197502 Oct 14 18:48 libtiff-3.5.7-20.2.i386.rpm
-rw-r--r-- 9416513 Aug 6 00:15 mozilla-1.7.2-0.2.0.i386.rpm
-rw-r--r-- 9417523 Sep 22 22:52 mozilla-1.7.3-0.2.0.i386.rpm
-rw-r--r-- 168779 Aug 6 00:15
mozilla-chat-1.7.2-0.2.0.i386.rpm
-rw-r--r-- 168855 Sep 22 22:52
mozilla-chat-1.7.3-0.2.0.i386.rpm
-rw-r--r-- 3430668 Aug 6 00:15
mozilla-devel-1.7.2-0.2.0.i386.rpm
-rw-r--r-- 3431150 Sep 22 22:52
mozilla-devel-1.7.3-0.2.0.i386.rpm
-rw-r--r-- 129375 Aug 6 00:15
mozilla-dom-inspector-1.7.2-0.2.0.i386.rpm
-rw-r--r-- 129476 Sep 22 22:52
mozilla-dom-inspector-1.7.3-0.2.0.i386.rpm
-rw-r--r-- 216249 Aug 6 00:15
mozilla-js-debugger-1.7.2-0.2.0.i386.rpm
-rw-r--r-- 216304 Sep 22 22:52
mozilla-js-debugger-1.7.3-0.2.0.i386.rpm
-rw-r--r-- 1837821 Aug 6 00:15
mozilla-mail-1.7.2-0.2.0.i386.rpm
-rw-r--r-- 1837765 Sep 22 22:52
mozilla-mail-1.7.3-0.2.0.i386.rpm
-rw-r--r-- 105703 Aug 6 00:15
mozilla-nspr-1.7.2-0.2.0.i386.rpm
-rw-r--r-- 105804 Sep 22 22:52
mozilla-nspr-1.7.3-0.2.0.i386.rpm
-rw-r--r-- 182713 Aug 6 00:15
mozilla-nspr-devel-1.7.2-0.2.0.i386.rpm-rw-r--r-- 182832 Sep 22
22:52 mozilla-nspr-devel-1.7.3-0.2.0.i386.rpm-rw-r--r-- 642446
Aug 6 00:15 mozilla-nss-1.7.2-0.2.0.i386.rpm
-rw-r--r-- 642551 Sep 22 22:52
mozilla-nss-1.7.3-0.2.0.i386.rpm
-rw-r--r-- 426276 Aug 6 00:15
mozilla-nss-devel-1.7.2-0.2.0.i386.rpm
-rw-r--r-- 426427 Sep 22 22:52
mozilla-nss-devel-1.7.3-0.2.0.i386.rpm
-rw-r--r-- 45384012 Oct 21 16:20
openoffice.org-1.1.2-10.fc2.i386.rpm
-rw-r--r-- 116156909 Oct 21 16:22
openoffice.org-i18n-1.1.2-10.fc2.i386.rpm
-rw-r--r-- 40707893 Oct 21 16:22
openoffice.org-libs-1.1.2-10.fc2.i386.rpm
-rw-r--r-- 260729 Oct 7 20:14 pango-1.4.1-1.i386.rpm
-rw-r--r-- 4653801 May 7 00:56 redhat-artwork-0.96-1.i386.rpm
-rw-r--r-- 14116065 Sep 13 22:16 samba-3.0.7-2.FC2.i386.rpm
-rw-r--r-- 5372296 Jul 6 18:42 xorg-x11-devel-6.7.0-5.i386.rpm
-rw-r--r-- 5380547 Sep 29 02:16 xorg-x11-devel-6.7.0-9.i386.rpm
-rw-r--r-- 2452335 Jul 6 18:42 xorg-x11-libs-6.7.0-5.i386.rpm
-rw-r--r-- 2458616 Sep 29 02:16 xorg-x11-libs-6.7.0-9.i386.rpm
-rw-r--r-- 338313 Jul 6 18:42
xorg-x11-Mesa-libGL-6.7.0-5.i386.rpm
-rw-r--r-- 344304 Sep 29 02:16
xorg-x11-Mesa-libGL-6.7.0-9.i386.rpm
-rw-r--r-- 409220 Jul 6 18:42
xorg-x11-Mesa-libGLU-6.7.0-5.i386.rpm
-rw-r--r-- 415215 Sep 29 02:16
xorg-x11-Mesa-libGLU-6.7.0-9.i386.rpm
This wouldn't be a critical problem, but the corresponding x86_64
versions seem to be missing.
What gives? Should I report this on BugZilla - if yes, under what
component?
Bob Deblier
19 years, 6 months
Packaging question time
by Gianluca Sforna
Hi all,
I am trying to package my first rpm.
After the appearance of Inventor in fedora.us my "natural" choice is
OpenMOIV (http://www.tecn.upf.es/openMOIV/) since it is a 3D molecular
visualization library used by several products of my company and it is
based on Inventor.
Of course, I read most documents about packaging at fedora.us and
rpm.org, and studied some other spec files, but I still have some
questions.
In particular my biggest doubt is about BuildRequires: for
compilation, the upstream authors provides either a cmake file (but
AFAIK we do not have a cmake package) or a qmake .pro file, so I guess
I have three options.
1. lobbying for inclusion of cmake
2. use qmake then make in the %build section
3. Include a pre-generated Makefile
now 1 does not seems to be a short term solution (besides, did anyone
ever propose cmake as a new package??)
2 seems to me the most obvious option but this raises another
question: what should I put in BuildRequires?? qmake, qt-devel or
what?
3 would make sense but I guess it will be detrimental to the package
configurability (my chosen options will be hardcoded in the Makefile).
Moreover, how would I deal with the additional file in the .spec??
Of course I guess I will have more questions in the future, but maybe
this is enough for now...
Thanks in advance
Gianluca
19 years, 6 months
Rawhide on PPC
by Ralf Ertzinger
Hi.
I installed the current fedora devel tree on my iBook2 this weekend,
and all in all things are working amazingly well. There are a few nags
on my list which will dutifully end up in bugzilla.
There is one question I'd like to ask here, though:
xorg on ppc seems to come without DRI modules. Why is that?
--
For the purpose of copyright in this country, software is regarded as a
work of art. -- Acorn application note 058
19 years, 6 months
Lock screen does not work for root in gnome
by Paul Ionescu
Hi,
I discovered that xscreensaver and lock screen does not work in gnome if
the current user is "root".
Is this a bug or a "feature" ?
And another question, is there an options to change the unlock prompt from
xscreensaver ? The default one is UGLY, and does not fit in Gnome desktop.
Thanks,
19 years, 6 months
rawhide signing and other such things
by seth vidal
I've been reading the thread of complaints about rawhide being unsigned.
The problem is, of course, a feasibility of getting the pkgs signed in a
semi-secure format.
What if we did the following:
we added functions to anything that reads repomd.xml to check for a gpg
signature in a detached file.
Then we could verify that the repomd.xml file is the original one.
That lets us know that the sha1 or md5 checksums in the repomd.xml file
pointing to the primary, filelists, other and groups metadata are valid.
if the metadata.xml files match the checksum from the signed and
verified repomd.xml then we know those files are valid.
Now Each package entry contains a package id in the metadata.
that id is either and md5sum or a sha1sum of the package file itself.
So now, if we download that file and the md5sum or sha1sum matches what
is in the metadata xml files then we know it is valid too.
This at least gets us to a point where we can reasonably trust the
packages from the repository based on a single signature for the
repomd.xml file.
What do y'all think? Would that be workable?
-sv
19 years, 6 months
Re: warning to list
by Paul Iadonisi
On Tue, 2004-10-26 at 00:53, Gregory G Carter wrote:
[snip]
> Not something many would like to hear, but I think security in general
> has not improved in computing because we have all of these not required
> methods that make us THINK the code is safe (i.e. Oooo...the package is
> digitally signed so its OK....), but in reality do not address the
> primary issues of why executables are a risk....lack of source code.
[snip]
Interesting. How about this idea for a start.
First, please note that I've added fedora-devel-list as I think this
sub-thread, of sorts, is more on-topic for that list. Please send
followups there. (Dang it! Why doesn't Evolution allow me to add
custom headers?! Argh! Don't answer that...or if you do, please start
a new thread. This one has morphed quite enough, already. :-))
How about this:
1) Build source package.
2) Sign source package.
3) Build binary package.
4) Embed SHA1 hash of signed source package in header of binary package.
(Should be automatically built into the 'rpmbuild --rebuild' command
and equivalents.)
5) Sign binary package.
This would at least help ensure that a particular binary rpm did
indeed come from a particular source package. As it stands, the
SOURCERPM name is stored in the header, but that's not verification,
it's only FYI type info that has no other src.rpm info in it (that I
know of). Of course, with my luck, I'll find it write after hitting
Send for this message.
--
-Paul Iadonisi
Senior System Administrator
Red Hat Certified Engineer / Local Linux Lobbyist
Ever see a penguin fly? -- Try Linux.
GPL all the way: Sell services, don't lease secrets
19 years, 6 months
Self-Introduction: Nigel Wetters Gourlay
by Nigel Gourlay
Nigel Wetters Gourlay
Witley, Surrey, UK
Professional programmer, currently taking a career break to raise a child.
Looking to package my Perl modules from CPAN. Most particularly, I
would like to see perl-ip-country in fedora core, so that SpamAssassin
3 can use country data of relays for filtering.
Most of my programming work has been commercial, non-free software. I
worked on the UK's worst-managed digital terrestrial TV provider (ITV
Digital), until they went bankrupt. Before that, I built
content-management systems for some of London's shortest-lived
dot-coms. My most popular free software is the javainetlocator project
on sourceforge. I have a lots of code on sourceforge and CPAN that is
'proof of concept' - i.e. looks interesting, but doesn't work well
enough to be useful to many people - Apache::Emulator and the type 2
jdbc driver for MySQL fall into this category. I also have some code
that works well, but is so obscure that it's unlikely to be used by
many people (e.g. Class::Decorator, Geo::Approx, and GSLWrap). And I
have a few projects on sourceforge that have a great name but little
else.
I don't have a lot of spare time at the moment, but I wouldn't mind
helping out on other projects that look interesting. I'm fluent in C
and C++, but my strengths are in Perl and Java. Many otherwise sane
people are using my IP geolocation code in production, which might be
a reason to trust me.
--nigel
pub 1024D/18BDD00E 2004-10-25 Nigel Wetters Gourlay (CPAN ID:
NWETTERS) <nwetters(a)cpan.org>
Key fingerprint = 43D3 E205 B568 4F13 2DE4 243C DB33 7BA7 18BD D00E
sub 1024g/1C9949A4 2004-10-25 [expires: 2006-10-25]
19 years, 6 months
cron: fixfiles.cron: daily message
by Dario Lesca
The /etc/cron.daily/fixfiles.cron send a message on stdout:
logging to /dev/null
Null message body; hope that's ok
then this message is send to root from cron every day ...
Perhaps it would be better to avoid useless messages with a:
/sbin/fixfiles -l /dev/null -o $OUTFILE $CRONTYPE >/dev/null
or modify the /sbin/fixfiles script.
Thanks
--
Dario Lesca <d.lesca(a)solinos.it>
19 years, 6 months