multiple install of a package, and alternates
by Patrice Dumas
Hi,
There are 2 things which in my opinion could be explained in the fedora
documents. The first one is how to package when there are good reasons for
2 versions of the same package be present. That's what happens to me with
libnet, for example as there are incompatibilities between the 1.0 and 1.1
series and a package requires the 1.0 version. What should be done in such
cases ?
The second thing is about the alternatives system. I think there could be
guidelines (even if it's just a pointer to documentation) on how to package
alternate software using alternatives. And maybe there could be guidelines on
the available alternatives.
Pat
20 years, 1 month
Self Introduction: Patrice Dumas
by Patrice Dumas
1. Name: Patrice Dumas
2. From: France, Paris
3. Profession: In phd and giving courses
4. Employed by: Universite du Maine
5. My goals: share the packages I use.
Help adding guidelines for packagers.
I want to do QA, but I don't have much time.
I would like to add libnet, pam_ssh, sec_rpc, esmtp, intuitively, texi2html.
6. I have worked on ltsp, sec_rpc. I am currently involved in the texi2html
development.
I know C, perl, shell scripting. I do sysadmin stuff at my lab.
You shouldn't trust me.
7. gpg key:
pub 1024D/36ECC523 2004-02-28 Patrice Dumas (Pertusus) <pertusus(a)free.fr>
Key fingerprint = 9804 BBF5 66E1 98FC A15D 5C21 5EC2 A77F 36EC C523
sub 1024g/D347D174 2004-02-28
Pat
20 years, 1 month
forbidden macros in spec files
by Patrice Dumas
Hi,
On the fedora.us site there is a page about macros in spec files
http://www.fedora.us/wiki/RPMMacros
However there is no list of forbidden macros. I am currently using a Dag
spec file in order to convert it to fedora conventions, and in this file
there are macros which are commonly not used in fedora spec files:
%{__rm}, %{__install}, %{__make}. I think that something should be said
about these macros in the file. Maybe a clear statement could be something
like "other macros are best avoided".
And I believe %{_smp_mflags} should be added in the section
Build flags macros
Pat
20 years, 1 month
Self Introduction: David Allison
by David Allison
1. Full Legal Name: David Stephen Allison
2. Country, City: USA, San Ramon, CA
3. Profession: software engineer
4. Company: I currently work for PathScale Inc.
5. My Goals: I have developed a new language that would make a nice
addition to
the languages supported by Fedora. My initial goal is to get the
language included
into the Fedora extras project and hopefully see it used.
6. Historical Qualifications: I have 16 years experience working in
software engineering.
My previous employers include British Telecom, Digital Equipment
and Sun Microsystems.
While at Sun, I worked in the labs as a team leader on a very large
Verilog simulation
project.
I have been a computer hobbyist for many years, starting out on the
Sinclair ZX80, and
on through the BBC Micro, Acorn Archimedes and RISC PC, and now Mac
OS X
and Linux. I have written and sold C and C++ development systems
for Acorn
machines, the first one being Beebug C for the BBC Micro and after
that I
wrote Easy C/C++ for the Acorn ARM based machines. These were all
written
in assembly language.
My latest pet project was Aikido, an interpreted prototyping and
scripting language
that I developed while as Sun. It is available as open source and
I would like
to see it used. (http://aikido.bkbits.net)
I am familiar with the C family of languages, mainly C++ and
assembly languages
(6502, ARM, SPARC and now x86). I am a keen compiler writer with
many years
of experience in all aspects of compilers and languages.
7. GPG KEYID and fingerprint
[dhcp-166:~] dallison% gpg --fingerprint 6c30eda2
pub 1024D/6C30EDA2 2004-03-19 David Allison (Dave)
<david.allison(a)comcast.net>
Key fingerprint = A910 222E D388 BCBF B12A 4F3C 12C4 5E47 6C30
EDA2
sub 1024g/A64DC009 2004-03-19
Dave
20 years, 1 month
RE: Attract QA'ers (was: Re: k3b fedora.us reviews ornew maintainer wanted!)
by Erik LaBianca
>
> Hello Erik,
>
> > You don't explicitly outline what sort of QA requirements would be
in
> > place for the different tiers, but I'd like to suggest that 2
anonymous
> > reviews or a single "trusted" review be enough to push out a
package,
> > particularly in the case of updates.
>
> Anonymous reviews??
>
"Untrusted" would probably have been a more appropriate choice of words.
--erik
20 years, 1 month
Another up2date mess
by Richard Hally
Here is a different mess from up2date. Anyone have a clue as to what the
probelm is?
different mirror different mess!
[root@old1 root]# up2date
http://fedora.redhat.com/download/up2date-mirrors/fedora-core-rawhide
using mirror:
http://mirror.hiwaay.net/redhat/fedora/linux/core/development/i386/
Traceback (most recent call last):
File "/usr/share/rhn/up2date_client/gui.py", line 1671, in
onPackagePageNext
ret = self.__packagePageDryRun()
File "/usr/share/rhn/up2date_client/gui.py", line 1599, in
__packagePageDryRun self.__refreshCallback)
File "/usr/share/rhn/up2date_client/up2date.py", line 387, in dryRun
ret = depsolve.solvedep()
File "/usr/share/rhn/up2date_client/depSolver.py", line 716, in solvedep
ret = self.process_deps(deps)
File "/usr/share/rhn/up2date_client/depSolver.py", line 683, in
process_deps
changed = self.__dependencies(dependencies)
File "/usr/share/rhn/up2date_client/depSolver.py", line 475, in
__dependencies refreshCallback = self.refreshCallback)
File "/usr/share/rhn/up2date_client/depSolver.py", line 93, in solveDep
ret = source.solveDep(unknowns, availList, refreshCallback)
File "/usr/share/rhn/up2date_client/repoBackends/genericSolveDep.py",
line 40, in solveDep
self.getSolutions(unknowns)
File "/usr/share/rhn/up2date_client/repoBackends/genericSolveDep.py",
line 235, in getSolutions
hdr = self.getHeader(pkg)
File "/usr/share/rhn/up2date_client/repoBackends/genericSolveDep.py",
line 217, in getHeader
progressCallback = progressCallback)
File "/usr/share/rhn/up2date_client/rpcServer.py", line 112, in doCall
ret = apply(method, args, kwargs)
File "/usr/share/rhn/up2date_client/repoDirector.py", line 31, in
getHeader
return self.handlers[channel['type']].getHeader(pkg, msgCallback,
progressCallback)
File "/usr/share/rhn/up2date_client/rpmSource.py", line 210, in getHeader
header = source.getHeader(pkg, progressCallback = progressCallback)
File "/usr/share/rhn/up2date_client/repoBackends/yumRepo.py", line 93,
in getHeader
hdrBuf = fh.read()
File "/usr/lib/python2.3/gzip.py", line 217, in read
self._read(readsize)
File "/usr/lib/python2.3/gzip.py", line 260, in _read
self._read_gzip_header()
File "/usr/lib/python2.3/gzip.py", line 161, in _read_gzip_header
raise IOError, 'Not a gzipped file'
IOError: Not a gzipped file
20 years, 1 month
up2date fubar
by Richard Hally
what is this nastiness with up2date? any help would be appreciated.
[root@old1 root]# rpm -q up2date
up2date-4.3.11-2.1.1
[root@old1 root]# up2date
http://fedora.redhat.com/download/up2date-mirrors/fedora-core-rawhide
using mirror:
http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/
Traceback (most recent call last):
File "/usr/share/rhn/up2date_client/gui.py", line 1671, in
onPackagePageNext
ret = self.__packagePageDryRun()
File "/usr/share/rhn/up2date_client/gui.py", line 1599, in
__packagePageDryRun self.__refreshCallback)
File "/usr/share/rhn/up2date_client/up2date.py", line 387, in dryRun
ret = depsolve.solvedep()
File "/usr/share/rhn/up2date_client/depSolver.py", line 716, in solvedep
ret = self.process_deps(deps)
File "/usr/share/rhn/up2date_client/depSolver.py", line 683, in
process_deps
changed = self.__dependencies(dependencies)
File "/usr/share/rhn/up2date_client/depSolver.py", line 475, in
__dependencies refreshCallback = self.refreshCallback)
File "/usr/share/rhn/up2date_client/depSolver.py", line 93, in solveDep
ret = source.solveDep(unknowns, availList, refreshCallback)
File "/usr/share/rhn/up2date_client/repoBackends/genericSolveDep.py",
line 40, in solveDep
self.getSolutions(unknowns)
File "/usr/share/rhn/up2date_client/repoBackends/genericSolveDep.py",
line 235, in getSolutions
hdr = self.getHeader(pkg)
File "/usr/share/rhn/up2date_client/repoBackends/genericSolveDep.py",
line 217, in getHeader
progressCallback = progressCallback)
File "/usr/share/rhn/up2date_client/rpcServer.py", line 112, in doCall
ret = apply(method, args, kwargs)
File "/usr/share/rhn/up2date_client/repoDirector.py", line 31, in
getHeader
return self.handlers[channel['type']].getHeader(pkg, msgCallback,
progressCallback)
File "/usr/share/rhn/up2date_client/rpmSource.py", line 210, in getHeader
header = source.getHeader(pkg, progressCallback = progressCallback)
File "/usr/share/rhn/up2date_client/repoBackends/yumRepo.py", line 93,
in getHeader
hdrBuf = fh.read()
File "/usr/lib/python2.3/gzip.py", line 217, in read
self._read(readsize)
File "/usr/lib/python2.3/gzip.py", line 272, in _read
self._read_eof()
File "/usr/lib/python2.3/gzip.py", line 308, in _read_eof
raise IOError, "CRC check failed"
IOError: CRC check failed
20 years, 1 month
RE: Attract QA'ers (was: Re: k3b fedora.us reviews or new maintainer wanted!)
by Erik LaBianca
>
> Lowering the bar to one untrusted reviewer would be extremely
dangerous.
> One aspect of the seemingly tough QA process has been to keep out a
> lot of crap software, or crappily packaged software. I would be more
> comfortable with people like you who have tried extremely hard, but
not
> someone brand new to the project and a complete unknown to me.
>
I agree with you 100%. I think that the process as it stands needs some
refinement, and then should be ratified as policy. We also need to
create, complete and / or document the tools needed to make the process
as easy as possible.
At that point, we can go out and heavily recruit QA volunteers. The
process is too complicated as of yet to do this, IMO.
> NOTE: BELOW IS CURRENTLY ONLY WHAT I PERSONALLY HAVE IN MIND RIGHT
NOW.
> PLEASE COMMENT.
>
<MONSTER SNIP>
I like your plan. I like it a lot. I like it enough not to have any
significant objections to it. I like the 4-tier hierarchy, and
especially the exception criteria made for packages languishing in QA
for 2 months. The question that remains is WHEN?! I think fedora extra
would greatly benefit from the shot in the arm provided by the official
redhat integration, and the formalized structure you outlined.
You don't explicitly outline what sort of QA requirements would be in
place for the different tiers, but I'd like to suggest that 2 anonymous
reviews or a single "trusted" review be enough to push out a package,
particularly in the case of updates.
--erik
20 years, 1 month
/etc/ld.so.conf.d
by Roland McGrath
Earlier in the day I was moved by the plight of a developer trying to
figure out exactly how his rpm postinstall/postuninstall scripts should
edit /etc/ld.so.conf for the directories they install libraries in.
I think a good answer is that they shouldn't have to do that.
I just implemented an `include' feature with globbing in ldconfig's
configuration file parsing. (This will be in an unspecified future glibc
rpm coming to you in rawhide in the fullness of time.) I propose that in
future the canonical /etc/ld.so.conf contain just:
include ld.so.conf.d/*.conf
A relative file name in an include is relative to the containing file's
directory, so that means /etc/ld.so.conf.d/*.conf will be taken together as
the effective contents of /etc/ld.so.conf.
/etc/ld.so.conf.d/foobar.conf can then be installed by the foobar package
as a normal file, and its postinstall/postuninstall doesn't need to touch
anything before it runs ldconfig. Note that it doesn't hurt to have the
same directory appear multiple times (ldconfig just ignores the
duplicates), so each package foobar installing foobar.conf containing
(e.g.) /usr/X11R6/lib is ok. OTOH, it would also be possible to have all
such packages install /etc/ld.so.conf.d/X11R6.conf with identical contents
and have the rpm magic take care of it that way. Others know better than I.
Thanks,
Roland
20 years, 1 month
'outdated' packages in rawhide
by Xose Vazquez Perez
package latest rawhide
------- --------- ---------
abiword 2.0.5 2.0.3
dhcp 3.0.1rc13 3.0.1rc12
fetchmail 6.2.5 6.2.0
glade 2.0.1 2.0
groff 1.19 1.18.1
ImageMagick 5.5.7-17 5.5.7-15
lftp 2.6.12 2.6.10
lilo 22.5.8 21.4.4
linux 2.6.4 2.6.3
lvm 1.0.8 1.0.3
modutils 2.4.27 2.4.26
mutt 1.4.2.1 1.4.1
nedit 5.4 5.3
openssh 3.8p1 3.6.1p2
openssl 0.9.7c 0.9.7a
parted 1.6.6 1.6.3
postfix 2.0.18 2.0.16
ppp 2.4.2 2.4.1
screen 4.0.2 4.0.1
sed 4.0.9 4.0.8
tcl 8.4.6 8.4.5
xfce 4.0.4 4.0.3
XFree86 4.4.0 4.3.0
-thanks-
20 years, 1 month