Re: Request for help maintaining packages while away.
On Wed, 2009-12-09 at 19:39 -0500, Paul W. Frields wrote: On Wed, Dec 09, 2009 at 12:38:11PM -0900, Jeff Spaleta wrote: On Wed, Dec 9, 2009 at 12:26 PM, Paul W. Frields sticks...@gmail.com wrote: Jef, I'll help with istanbul. If anyone else out there is considering doing so, please feel free to team up with me. Other than revelation(which essentially has a dead upstream)...Istanbul is probably the most in need of more development love. Upstream seems to be inactive with no release activity in quite a while. There's a lot of deprecation warnings for some pygtk calls that I would love to clean up in time for F13. And there are a couple of abrt crash tickets being spawned by istanbul.. which maybe traced back to gdk libraries calls if I'm reading the crash dumps correctly. Dave Malcolm was looking at an underlying GTK (or maybe GDK?) bug this weekend at FUDCon if memory serves. I'll also do what I can for existing bugs in my Copious Spare Time(tm). I spent some time trying to figure out bug 543278 but got stumped; need a GTK maintainer's help with this one; pygtk appears to be correctly passing the --sync flag on to GTK fwiw [snip] -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: brp-python-bytecompile
On Fri, 2009-11-20 at 09:53 -0700, Jerry James wrote: I'm looking into the build failures Matt identified. With my shiny new Rawhide VM, I'm seeing this output on a local build of a package with no python sources: [ ... successful build messages ...] + /usr/lib/rpm/brp-python-bytecompile Bytecompiling .py files below [BUILDROOT]/usr/lib*/python*/ using /usr/bin/python* Usage: /usr/bin/python-config [--prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--help] Usage: /usr/bin/python-config [--prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--help] + /usr/lib/rpm/redhat/brp-python-hardlink [ ... successful build messages ...] The rpm build is completing, so I'm not worried about this particular package. Is this going to cause problems with packages that do have python sources, or is this just because nothing matches /usr/lib*/python*/ in the build root? It looks like python_binary = /usr/bin/python*, which can match any of these: /usr/bin/python /usr/bin/python-config /usr/bin/python2 /usr/bin/python2.6 /usr/bin/python2.6-config Sorry; looks like my fault. I updated /usr/lib/rpm/brp-python-bytecompile to better cope with the python 2 vs python 3 split; this was in: https://bugzilla.redhat.com/show_bug.cgi?id=531117 From my reading, what's happening is that I coded it with the (incorrect) assumption that files exist which match $RPM_BUILD_ROOT/usr/lib*/python*/ When at least one such file exists, I believe the shell expands the glob and thus we iterate over the library subdirectories, byte-compiling all .py files in them with the appropriate version of python. When no such directory exists, the shell fails to expand it, and retains it as the text string: your_build_root/usr/lib*/python*/ and thus one iteration of that loop happens, and we get the two error messages. So I believe this is harmless but messy. Filed as https://bugzilla.redhat.com/show_bug.cgi?id=539635 Sorry for any confusion. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: help debugging segfault with alienarena 7.32
On Tue, 2009-11-03 at 11:45 -0500, Tom spot Callaway wrote: I need to rebuild alienarena for all targets due to a security issue, so I decided to update to 7.32, but unfortunately, the 7.32 build segfaults immediately on Fedora 12 (x86_64), and gdb isn't much help (gdb output is at the bottom). FWIW, it looks like the backtrace is within the C++ start-up code that runs all non-empty constructors for global C++ variables, which gets called before main starts for a C++ program. Does (gdb) break call_init before (gdb) run give you a working breakpoint? [snip] Hope this is helpful Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Sat, 2009-10-03 at 22:09 +0200, yersinia wrote:
On Thu, Oct 1, 2009 at 7:15 PM, David Malcolm dmalc...@redhat.com
wrote:
[snip]
$ rpm -qf /usr/lib/python2.*/site-packages/* | grep -v is not
owned |
SIA, this is off of topic , i am sure. BUT, it is very strange that
could be exists, perhaps, some file or directory not owned by
someone. Isn't it ?
FWIW I've done a lot of packaging experimentation on that system, and
brute-force copying of .py files into place, so there's a fair amount of
cruft lurking about on my system. That's why I had that in the shell
pipeline I gave. (But yes, this is heading off-topic)
sort | uniq | xargs rpm -q --qf %{NAME}-%{VERSION}-%{RELEASE}
%{SOURCERPM}\n | sed -es/.src.rpm// | squeal -f table col0,
col1 from
- where col0 != col1
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, 2009-10-01 at 13:15 -0400, David Malcolm wrote: [snip] (replying to self, with some archive links) An earlier proposal about python 3 in Fedora is here: https://www.redhat.com/archives/fedora-devel-list/2008-May/msg02417.html ...which was the Let's make a plan for python3.0 in Fedora 10+ thread. FWIW, looking back in the logs there was also: python-2.6 and python-3.x ( https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00085.html ) and further back: The looming Python 3(000) monster https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00379.html [snip] -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Python 2.6.3 for Fedora 13?
Python 2.6.3 was just released [1]. I think we'll want this in F13
(seems far too late to me for F12).
I tried rebuilding our devel branch with the 2.6.3 tarball, and it
built with no changes to the existing patches. I haven't gone through
the upstream changes in detail though. Caveat: this was on an F11 box,
not in Koji.
I'm running with 2.6.3 rpms on my F11 box, I'll see if anything
unexpected happens. yum seems to still work.
Attached is a patch to the devel branch FWIW.
I've just requested watchbugzilla watchcommits and commit rights
for python's devel and F12 branches. Is there a process I need to go
through for this, e.g. to establish trustworthiness?
Hope this is helpful
Dave
PS I'm about to be unreachable electronically, until October 12th
(vacation). I plan to start running rawhide when I'm back.
[1] http://www.python.org/download/releases/2.6.3/
? .build-2.6.2-2.fc12.log
? .build-2.6.3-1.fc13.log
? bump-python-devel-to-2.6.3.patch
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/python/devel/.cvsignore,v
retrieving revision 1.20
diff -u -p -r1.20 .cvsignore
--- .cvsignore 30 Jul 2009 20:57:27 - 1.20
+++ .cvsignore 2 Oct 2009 21:00:23 -
@@ -1 +1,2 @@
Python-2.6.2.tar.bz2
+Python-2.6.3.tar.bz2
Index: python.spec
===
RCS file: /cvs/pkgs/rpms/python/devel/python.spec,v
retrieving revision 1.152
diff -u -p -r1.152 python.spec
--- python.spec 21 Aug 2009 15:34:49 - 1.152
+++ python.spec 2 Oct 2009 21:00:23 -
@@ -21,8 +21,8 @@
Summary: An interpreted, interactive, object-oriented programming language
Name: %{python}
-Version: 2.6.2
-Release: 2%{?dist}
+Version: 2.6.3
+Release: 1%{?dist}
License: Python
Group: Development/Languages
Provides: python-abi = %{pybasever}
@@ -538,6 +538,9 @@ rm -fr $RPM_BUILD_ROOT
%{_libdir}/python%{pybasever}/lib-dynload/_testcapimodule.so
%changelog
+* Fri Oct 2 2009 David Malcolm dmalc...@redhat.com - 2.6.3-1
+- Update to 2.6.3
+
* Fri Aug 21 2009 Tomas Mraz tm...@redhat.com - 2.6.2-2
- rebuilt with new openssl
Index: sources
===
RCS file: /cvs/pkgs/rpms/python/devel/sources,v
retrieving revision 1.20
diff -u -p -r1.20 sources
--- sources 30 Jul 2009 20:57:27 - 1.20
+++ sources 2 Oct 2009 21:00:23 -
@@ -1 +1,2 @@
245db9f1e0f09ab7e0faaa0cf7301011 Python-2.6.2.tar.bz2
+8755fc03075b1701ca3f13932e6ade9f Python-2.6.3.tar.bz2
___
Fedora-python-devel-list mailing list
Fedora-python-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-python-devel-list
Re: Python 2.6.3 for Fedora 13?
On Fri, 2009-10-02 at 17:17 -0400, David Malcolm wrote: Python 2.6.3 was just released [1]. I think we'll want this in F13 (seems far too late to me for F12). I tried rebuilding our devel branch with the 2.6.3 tarball, and it built with no changes to the existing patches. I haven't gone through the upstream changes in detail though. Caveat: this was on an F11 box, not in Koji. Scratch build here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1725285 [snip] ___ Fedora-python-devel-list mailing list Fedora-python-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-python-devel-list
Proposal: Python 3 in Fedora 13
Proposal: Python 3 in Fedora 13
Evolutionary, not revolutionary: build a python 3 stack
parallel-installable with the python 2 stack.
= High-level summary =
- Python 3.0 was released almost 10 months ago, on 2008-12-03, and the
latest release of the 3.* branch is 3.1.1, released on 2009-08-17.
- Other distros have python 3, though not necessarily with anything
on top resembling the full python 2 stack.
- We have a working, valuable python 2 stack, which is used by
critical system components (yum and anaconda): we must not destabilize
the python 2 stack.
- Python 3 is sufficiently different from python 2 that we need them
to be independent software stacks.
- I plan to spend a large chunk of my $DAYJOB over the next few months
trying to build a useful Python 3 stack for Fedora 13, for some
definition of useful (help will be appreciated!)
- I don't want to add extra work for package maintainers: if you
maintain an SRPM of a python 2 module that's working for you, you
shouldn't feel obligated to own a separate SRPM for python 3. If
someone has a need for the module on python 3, they can take on that
work.
= Background =
Python 3 is intended by upstream to be the future of Python, but we have
many critical components that use Python 2. Python 2 and Python 3 are
sufficiently different that we need both (try writing print in each).
Python 2 will be around for a long time.
An interesting summary of Python 3 adoption can be seen here:
http://renesd.blogspot.com/2009/09/py3kpython3-more-than-one-year-on-096.html
An earlier proposal about python 3 in Fedora is here:
https://www.redhat.com/archives/fedora-devel-list/2008-May/msg02417.html
Going forward, I will have plenty of time to spend, as part of my
dayjob, on Python in Fedora [1]
= Proposal =
I want to get python 3 into Fedora, but I don't want to break yum or
anaconda (or anything else, for that matter!)
How to do this? I propose that Fedora shall have separate,
parallel-installable Python 2 and Python 3 stacks. I believe we can get
things to the point where on a Fedora box you'd be able to install both
stacks, and have some processes running python 2 code, and some running
python 3, simultaneously.
Where I would draw the line is on having both python 2 and python 3
running within the same _process_: the two libraries share most of their
symbol names, but with differing implementations, and the result of
trying to dynamically link the two into the same address space would be
highly unstable.
As an example, you'd be able to install both mod_python and mod_python3
rpms, but you wouldn't be able to (sanely) configure httpd to have both
running simultaneously (I guess we should add a run-time warning for
this case)
Scoping:
- this work would target Fedora 13. I'd avoid pushing it into F12
until it's proven safe to do so
- the proposal is for python 2 vs python 3. It could be extended to
support having multiple minor-versions of Python as well, but that's a
big extension of the work involved and not something I'm planning to
work on myself.
= Details =
We should split python 2 and python 3 at the source RPM level, where
possible.
The easy case is when upstream release separate tarballs for the python
2 and python 3 versions of code. For example, given package
python-foo in packaging CVS, there would be a separate python3-foo
for the python 3 version. There would be no expectation that the two
would need to upgrade in lock-step. (The two SRPMS could have different
maintainers within Fedora: the packager of a python 2 module might not
yet have any interest in python 3)
The more difficult case is when the python module is emitted as part of
the build of a larger module. Some examples:
- the build of rpm itself emits an rpm-python subpackage.
- Another example is the postgres srpm, which emits a
postgresql-python subpackage.
In a quick attempt at seeing other examples, on my laptop (F11), here
are the packages installed that provide python modules where the package
name differs from the srpm name:
$ rpm -qf /usr/lib/python2.*/site-packages/* | grep -v is not owned |
sort | uniq | xargs rpm -q --qf %{NAME}-%{VERSION}-%{RELEASE}
%{SOURCERPM}\n | sed -es/.src.rpm// | squeal -f table col0, col1 from
- where col0 != col1
col0| col1|
+--+
at-spi-python-1.26.0-1.fc11| at-spi-1.26.0-1.fc11|
audit-libs-python-1.7.13-1.fc11| audit-1.7.13-1.fc11|
cracklib-python-2.8.13-4| cracklib-2.8.13-4|
gamin-python-0.1.10-4.fc11| gamin-0.1.10-4.fc11|
hplip-libs-3.9.8-12.fc11| hplip-3.9.8-12.fc11|
libproxy-python-0.2.3-10.fc11|libproxy-0.2.3-10.fc11|
libselinux-python-2.0.80-1.fc11| libselinux-2.0.80-1.fc11|
Re: Proposal: Python 3 in Fedora 13
On Thu, 2009-10-01 at 13:07 -0500, Chris Adams wrote: Once upon a time, Josh Boyer jwbo...@gmail.com said: On Thu, Oct 01, 2009 at 01:15:09PM -0400, David Malcolm wrote: Scoping: - this work would target Fedora 13. I'd avoid pushing it into F12 until it's proven safe to do so I'm going to think on the overall proposal more, but I very very very much wish this sentence said I will not push this into F12 at all. Yeah, we seem to have too much churn going with some things as it is during a release. What possible reason would there be to push a major new component into an existing release? Agreed. This part of my post was clumsy. I think what I meant to say was that I'd want to veto anyone wanting to push it into F12, that they'd have a significant burden of proof of safety before such an action could occur. I don't have any interest in such a backport. Sorry Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, 2009-10-01 at 11:23 -0700, Toshio Kuratomi wrote: On 10/01/2009 11:11 AM, Jesse Keating wrote: On Oct 1, 2009, at 10:59, Josh Boyer jwbo...@gmail.com wrote: On Thu, Oct 01, 2009 at 01:15:09PM -0400, David Malcolm wrote: Scoping: - this work would target Fedora 13. I'd avoid pushing it into F12 until it's proven safe to do so I'm going to think on the overall proposal more, but I very very very much wish this sentence said I will not push this into F12 at all. josh Ditto. This is not something you would push as an update to a released product. I disagree. The proposal is really treating python3 as a new language. We can and do push such things into a released Fedora. Treating it as a new language is the intent, and I'll make every effort to keep them separated. In theory there wouldn't be any problems. However if I screw up and somehow cross the streams, I run the risk of breaking _lots_ of things; yum is the most obvious victim in the critical path. Obviously I don't want to do that. I'm not volunteering to put it into F12. I think that anyone wanting to push it into F12 needs to sign up for a lot of testing (brainstorming some testcases: can you still compile and build external modules with both 2 and 3 -devel subpackages installed? does every configure script pick up the correct version? etc) Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, 2009-10-01 at 12:17 -0700, Toshio Kuratomi wrote: On 10/01/2009 10:15 AM, David Malcolm wrote: Proposal: Python 3 in Fedora 13 Evolutionary, not revolutionary: build a python 3 stack parallel-installable with the python 2 stack. First: Overall +1. Note: liberally snipped, throughout. [likewise snipped lots of stuff] Naming convention proposal: How does this sound: - an rpm with a python- prefix means a python 2 rpm, of the default python 2 minor version (for Fedora this will be the most recent stable upstream minor release, for EPEL it will be the minor release of 2 that came with the distro, so 2.4 for EPEL5) - an rpm with a python3- prefix means a python 3 rpm, of the default python 3 minor version (for Fedora this will be the most recent stable upstream release) What about packages without a python- prefix? Proposal: If upstream has a naming convention for python2 vs python3, use it. Otherwise, add a python3- prefix to make things clear. I'm not sure about the details here. Examples? +1 to the basics. There are a lot of details to work out: [snip the details] Thanks. Given that, I went ahead and created a Feature page for this: https://fedoraproject.org/wiki/Features/Python3F13 So far it's mostly just a restatement of my post, though I've started fleshing out some sections e.g. how to test. I've assumed the naming convention from my post python3 for the srpm, and for the symlink to the binary. Feel free to dive in and edit. I marked myself as owner of the feature as I know I'm going to be able to devote a big chunk of time to this. Hope that's OK. We now have 3 competing srpms for Python 3: (i) the one from ivazquez: http://ivazquez.fedorapeople.org/packages/python3000/ (python3000) (ii) the one by Andrew McNabb: https://bugzilla.redhat.com/show_bug.cgi?id=526126 (named python3) (iii) and the one I did, also named python3: http://people.redhat.com/dmalcolm/python3/python3.spec and an SRPM here: http://people.redhat.com/dmalcolm/python3/python3-3.1.1-1.fc13.src.rpm I was just going to suggest you contact ivazquez :-) he's done a lot of work, both to get a python3 package working and on the update from python2.5 to python2.6. I'm assuming ivazquez is seeing these emails (I _think_ he said he'd seen it on IRC earlier today), and I added a link to my email to the review bug above so hopefully Andrew is seeing this. I hope to have a look at the commonality/differences between the 3 efforts tomorrow. I think python3 is a better name (if nothing else, it's shorter to type!). I'd like it if the eventually python 3 specfile could resemble the python 2 specfile so that we can meaningfully look at the textual diffs between them (but it may be necessary to clean up the python specfile to achieve this! I'll try to have a look at the merge-review) Thanks for the feedback; hope this all sounds sane Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, 2009-10-01 at 19:12 -0400, Ben Boeckel wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David Malcolm wrote:
Naming convention proposal:
How does this sound:
- an rpm with a python- prefix means a python 2 rpm, of
the
default python 2 minor version (for Fedora this will be the
most
recent stable upstream minor release, for EPEL it will be the
minor
release of 2 that came with the distro, so 2.4 for EPEL5)
- an rpm with a python3- prefix means a python 3 rpm, of
the
default python 3 minor version (for Fedora this will be the
most
recent stable upstream release)
(we could extend this to have specific minor-releases (e.g.
use
python24- for a python 2.4 stack, in case some brave soul
wants to get
zope/plone running. But may be better to try to fix the
zope/2.6
incompatibility at that point (caveat: haven't looked at the
details of
the issue). I don't intend to work on such versions))
What about packages without a python- prefix? Proposal: If
upstream
has a naming convention for python2 vs python3, use it.
Otherwise, add
a python3- prefix to make things clear. I'm not sure about
the
details here. Examples?
There have been various discussions upstream about what to
call the
python 3 binary. My favorite quote on the subject is from
Guido,
http://mail.python.org/pipermail/python-3000/2008-
March/012421.html :
During the next 3 years or so, installing Py3k as the default
python
will be a deed of utter irresponsibility and is likely to
break your
system in subtle ways (both OSX and Linux these days use
Python for
certain system tasks). If you *really* want to shoot yourself
in the
foot this way, go ahead and explicitly use make altinstall
bininstall or link it yourself.
I propose that for Fedora we have /usr/bin/python3 for the
system/default version of python 3 and /usr/bin/python for
the
system/default version of python 2. Both would be symlinks to
a binary
with the minor-release embedded in the name
(/usr/bin/python3.1 and
/usr/bin/python/2.6).
As I understand things, this should make us broadly in
agreement with
upstream; see e.g.:
http://mail.python.org/pipermail/python-dev/2009-
April/088862.html
http://mail.python.org/pipermail/python-dev/2009-
April/04.html
Could we do something similar to what qt and kdelibs packages
have done? While qt3 was default, the 'qt' package points to qt3
and qt4 is an entirely separate package. When qt4 became
default, qt3 was the one with the explicit version on it (and
qt4 still exists, but the default 'qt' is qt4 now). This would
mean that python2 packages grow 'Provides: python2-foo =
%{version}-%{release}'. When python3 is the default, then have
python point to python3 (and we can drop the Provides/Obsoletes
for python3- prefixed packages later if wanted).
My thought process is that I would not like, after python3 is
the default, to still have to put the explicit 3 on there
because python is still python2. Just thinking ahead here.
Thanks! If I'm correctly reading your mail, this approach is one I did
think of, but I'm not fond of it.
I think that anyone dealing with Python is going to have to be thinking
is this python 2 or python 3 for some years to come, so having an
explicit python3- prefix is probably not too painful.
What I think would be painful in your suggestion is the flag day where
we'd change the meaning of python- in RPM names. Currently in Fedora
and EPEL, python- implies the system-supplied minor release of python
2, be it in Fedora (2.6), or in EPEL (2.4). I worry that changing it to
imply the system-supplied minor release of Python 3 (3.1, or 3.2/3.3? by
that point) would be thoroughly confusing, since we'd have to update
everything all at once. It wouldn't fly within EPEL, since the
pre-existing Enterprise downstreams of Fedora aren't going to change
(far too disruptive).
One middle ground might be to start using python2- explicitly for
_new_ packages. That wouldn't break anything, but could easily be
confusing as well. I think I prefer keeping things consistent.
Perhaps at some point we could cut over /usr/bin/python from being
Python 2 to Python 3, but I refer you again to this quote from Guido:
http://mail.python.org/pipermail/python-3000/2008-March/012421.html
(The other fun thing to do might be to package Unladen Swallow. Not at
all sure what to call _that_ though!)
Dave
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Script to detect conflicting files in PATH within a yum repo (was Re: conflict between libotf and openmpi)
On Thu, 2009-09-17 at 09:57 -0400, Seth Vidal wrote: On Wed, 16 Sep 2009, David Malcolm wrote: On Wed, 2009-09-16 at 18:45 -0400, Neal Becker wrote: Which makes me wonder, how could this conflict have been avoided? Is there a tool that would check any new package to see if any object* in it would conflict with any existing package? If not, sounds like a good thing to have. * Here, object means filesystem object. I'm not sure if there are any other types of objects to worry about. Brainstorming: a script that walks the yum repo's filelist.tar.gz, and figures out a list of filename collisions, filtering by directories in the default PATH Attached is a first pass at a python script that does this. Output from the script when run upon [1] is below. Caveat: the script probably has bugs. Does this look useful? David, Yes it does look useful. I wrote something similar: http://skvidal.fedorapeople.org/misc/potential_conflict.py which is what I believe autoqa is starting from for their file conflict checker. Aha! Your approach looks superior, as you're leveraging all that extra info from the RPM headers about file hashes etc. Thanks. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Script to detect conflicting files in PATH within a yum repo (was Re: conflict between libotf and openmpi)
On Wed, 2009-09-16 at 18:45 -0400, Neal Becker wrote: Which makes me wonder, how could this conflict have been avoided? Is there a tool that would check any new package to see if any object* in it would conflict with any existing package? If not, sounds like a good thing to have. * Here, object means filesystem object. I'm not sure if there are any other types of objects to worry about. Brainstorming: a script that walks the yum repo's filelist.tar.gz, and figures out a list of filename collisions, filtering by directories in the default PATH Attached is a first pass at a python script that does this. Output from the script when run upon [1] is below. Caveat: the script probably has bugs. Does this look useful? ulockmgr_server /bin/ulockmgr_server from fuse /usr/bin/ulockmgr_server from fuse telnet /usr/bin/telnet from telnet /usr/kerberos/bin/telnet from krb5-workstation-clients gzip /bin/gzip from gzip /usr/bin/gzip from gzip fusermount /bin/fusermount from fuse /usr/bin/fusermount from fuse stap-env /usr/bin/stap-env from systemtap-client /usr/bin/stap-env from systemtap /usr/bin/stap-env from systemtap-server winemaker /usr/bin/winemaker from wine-devel /usr/bin/winemaker from wine-common ftp /usr/bin/ftp from ftp /usr/kerberos/bin/ftp from krb5-workstation-clients pinentry /usr/bin/pinentry from pinentry /usr/bin/pinentry from pinentry-gtk /usr/bin/pinentry from pinentry-qt kadmin /usr/kerberos/bin/kadmin from krb5-workstation-servers /usr/kerberos/bin/kadmin from krb5-workstation lzcmp /usr/bin/lzcmp from xz-lzma-compat /usr/bin/lzcmp from lzma lzgrep /usr/bin/lzgrep from xz-lzma-compat /usr/bin/lzgrep from lzma lzdiff /usr/bin/lzdiff from xz-lzma-compat /usr/bin/lzdiff from lzma lzcat /usr/bin/lzcat from xz-lzma-compat /usr/bin/lzcat from lzma lzmainfo /usr/bin/lzmainfo from xz-lzma-compat /usr/bin/lzmainfo from lzma lzfgrep /usr/bin/lzfgrep from xz-lzma-compat /usr/bin/lzfgrep from lzma plymouth /bin/plymouth from plymouth /usr/bin/plymouth from plymouth gawk /bin/gawk from gawk /usr/bin/gawk from gawk ex /bin/ex from vim-minimal /usr/bin/ex from vim-enhanced ircd /usr/bin/ircd from ircd-ratbox /usr/bin/ircd from ircd-hybrid cut /bin/cut from coreutils /usr/bin/cut from coreutils towhee-mpi /usr/bin/towhee-mpi from towhee-mpi /usr/bin/towhee-mpi from towhee pscp /usr/bin/pscp from putty /usr/bin/pscp from pssh links /usr/bin/links from links /usr/bin/links from elinks rsh /usr/kerberos/bin/rsh from krb5-workstation-clients /usr/bin/rsh from rsh awk /bin/awk from gawk /usr/bin/awk from gawk tmda-ofmipd /usr/bin/tmda-ofmipd from tmda-ofmipd /usr/bin/tmda-ofmipd from tmda kvno /usr/kerberos/bin/kvno from krb5-workstation-servers /usr/kerberos/bin/kvno from krb5-workstation sclient /usr/kerberos/bin/sclient from krb5-devel /usr/kerberos/bin/sclient from krb5-server unlzma /usr/bin/unlzma from xz-lzma-compat /usr/bin/unlzma from lzma ktutil /usr/kerberos/bin/ktutil from krb5-workstation-servers /usr/kerberos/bin/ktutil from krb5-workstation lzegrep /usr/bin/lzegrep from xz-lzma-compat /usr/bin/lzegrep from lzma ntfs-3g /bin/ntfs-3g from ntfs-3g /usr/bin/ntfs-3g from ntfs-3g k5srvutil /usr/kerberos/bin/k5srvutil from krb5-workstation-servers /usr/kerberos/bin/k5srvutil from krb5-workstation rlogin /usr/kerberos/bin/rlogin from krb5-workstation-clients /usr/bin/rlogin from rsh stap-find-servers /usr/bin/stap-find-servers from systemtap-client /usr/bin/stap-find-servers from systemtap-server lzma /usr/bin/lzma from xz-lzma-compat /usr/bin/lzma from lzma kde4-doxygen.sh /usr/bin/kde4-doxygen.sh from kdelibs-devel /usr/bin/kde4-doxygen.sh from kdelibs find /bin/find from findutils /usr/bin/find from findutils jasper5-setclasspath.sh /usr/bin/jasper5-setclasspath.sh from tomcat5 /usr/bin/jasper5-setclasspath.sh from tomcat5-jasper translate /usr/bin/translate from libtranslate /usr/bin/translate from surfraw stap-gen-cert /usr/bin/stap-gen-cert from systemtap /usr/bin/stap-gen-cert from systemtap-server stap-authorize-cert /usr/bin/stap-authorize-cert from systemtap /usr/bin/stap-authorize-cert from systemtap-server rcp /usr/kerberos/bin/rcp from krb5-workstation-clients /usr/kerberos/bin/rcp from krb5-workstation-servers /usr/bin/rcp from rsh env /bin/env from coreutils /usr/bin/env from coreutils jspc5.sh /usr/bin/jspc5.sh from tomcat5 /usr/bin/jspc5.sh from tomcat5-jasper synergyc /usr/bin/synergyc from synergy /usr/bin/synergyc from synergy-plus synergys /usr/bin/synergys from synergy /usr/bin/synergys from synergy-plus xemacs /usr/bin/xemacs from xemacs-nox /usr/bin/xemacs from xemacs kill /bin/kill from util-linux-ng /usr/bin/kill from util-linux-ng gettext /bin/gettext from gettext /usr/bin/gettext from gettext winedump
Re: Script to detect conflicting files in PATH within a yum repo (was Re: conflict between libotf and openmpi)
On Wed, 2009-09-16 at 20:08 -0400, Neal Becker wrote: Why not report all conflicts, instead of only those on your PATH? This is acting at the level of individual filenames (dropping the directory component from the path), and doesn't have any knowledge about a file beyond its full installation path. The PATH filtering allows it to avoid lots of false-positives from all of the various COPYING, README etc files we drop into various places in the filesystem. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Thu, 2009-08-13 at 21:27 -0400, Steve Grubb wrote: On Thursday 13 August 2009 05:53:37 pm John Poelstra wrote: Can you update the feature page to reflect the reduced scope of the feature and its completion percentage? All I see since FESCo met was the change to the detailed description related to the permissions. That *is* the reduction in scope - other than what I have time to actually work on. If I can fix dhcp, that is a major win. That is the item that stands out as the biggest problem when running netcap. Steve: With my paranoid/QA hat on, I think the How to Test section needs some more items. It covers testing that each specific change being made works as expected, but it doesn't also cover testing that there weren't unexpected side effects. I added some questions to this end to the discussion page: https://fedoraproject.org/wiki/Talk:Features/LowerProcessCapabilities Hope this is helpful Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Can anyone volunteer to help with a Python 2.5 / Python 2.4 code issue?
On Fri, 2009-05-01 at 12:11 -0700, Adam Williamson wrote: Hi, guys. I've been working with a Bugzappers group community member, Brennan Ashton, who has written a great tool in Python for generating a range of graphical metrics of Bugzilla information, which would be very useful to us. The tool is basically written and we have space provided by Infrastructure to host it on a permanent basis, but unfortunately, Infrastructure's servers all run RHEL and so have Python 2.4, while the tool has a small but important section of code which relies on a Python 2.5-only function to work. Brennan's very busy at present and might not have time to port the code to Python 2.4 for a while, so - as we want to have it up and running ASAP - I thought I'd ask this list if anyone would be kind enough to help out in tweaking the code to work on Python 2.4. The code is all up in the Bugzappers git repository: http://git.fedoraproject.org/git/triage.git it's the 'triageweb' subdirectory, and some things in 'scripts' as well I believe. If anyone would be kind enough to help, Brennan (in CC) can point out the relevant bit of code that needs changing - I don't have the reference myself, I'm afraid. Thanks, all! [dmalc...@radiator triage]$ find -name \*.py ./scripts/createTriageDB.py ./scripts/triagestatus.py ./scripts/bzTriageReport.py ./scripts/saveReport.py ./scripts/test.py ./scripts/bzReviewReport.py ./triageweb/createdb.py ./triageweb/fedoratriage/json.py ./triageweb/fedoratriage/model.py ./triageweb/fedoratriage/release.py ./triageweb/fedoratriage/commands.py ./triageweb/fedoratriage/templates/__init__.py ./triageweb/fedoratriage/config/__init__.py ./triageweb/fedoratriage/controllers.py ./triageweb/fedoratriage/tests/test_controllers.py ./triageweb/fedoratriage/tests/test_model.py ./triageweb/fedoratriage/tests/__init__.py ./triageweb/fedoratriage/__init__.py ./triageweb/updateGroups.py ./triageweb/start-fedoratriage.py ./triageweb/setup.py ./triageweb/bzTriageReport.py ./triageweb/bzTriageReportHistory.py ./triageweb/bzTriageTotalReport.py ./triageweb/test.py So where's the 2.5-only code? triagedb uses sqlalchemy, and that API changed a bit between 0.3 and 0.4. EPEL5 contains 0.3, and I see SQLAlchemy=0.3.10 in the ./triageweb/setup.py. However most of the Fedora Infrastructure uses 0.4 on EL5 IIRC (please correct me if I'm wrong). It's TurboGears, so run the app by invoking start-fedoratriage.py. One gotcha that confused me for a while, dev.cfg has: server.webpath = /triageweb/ so the URL you have to browse to is http://0.0.0.0:8080/triageweb , not http://0.0.0.0:8080/ as prompt from start-fedoratriage.py suggests (the latter gives a 404) Hope this helps Dave ___ Fedora-python-devel-list mailing list Fedora-python-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-python-devel-list
mod_wsgi issue: solved
I've been trying to deploy rpmgrok (a Turbogears 1 app [1]) behind mod_wsgi, and finally figured out why mod_wsgi stopped working when I added a WSGIProcessGroup directive (which avoids having to start a new process per http request) I know bpeck has had similar issues with his beaker code [2] It was working on publictest14.fp.org, but not on my local workstation (both RHEL-5 running mod_wsgi from EPEL). Attempts to browse led to no response coming from httpd, and no log. It turned out, I had mod_python installed on the box. Upon disabling LoadModule python_module modules/mod_python.so from /etc/httpd/conf.d/python.conf it worked. Known issue? http://code.google.com/p/modwsgi/wiki/InstallationIssues describes another mod_wsgi/mod_python incompatibility, but the symptoms seem different [3] Hope this helps Dave [1] https://fedorahosted.org/rpmgrok/ [2] https://fedorahosted.org/beaker/ [3] debugging attempts led me to find stuck httpd threads waiting forever for the global interpreter lock, presumably acquired by mod_python elsewhere in the process: (gdb) bt #0 0x005bf402 in __kernel_vsyscall () #1 0x0018331e in sem_w...@glibc_2.0 () from /lib/i686/nosegneg/libpthread.so.0 #2 0x01d97f3b in PyThread_acquire_lock () from /usr/lib/libpython2.4.so.1.0 #3 0x01d74d57 in PyEval_RestoreThread () from /usr/lib/libpython2.4.so.1.0 #4 0x01d9104f in PyGILState_Ensure () from /usr/lib/libpython2.4.so.1.0 #5 0x00c65785 in wsgi_start_process (p=0x918a550, daemon=0x92b91a8) at mod_wsgi.c:8706 #6 0x00c661b3 in wsgi_hook_init (pconf=0x918a550, ptemp=0x91b8608, plog=0x91bc618, s=0x918c3f0) at mod_wsgi.c:8919 #7 0x00c27783 in ap_run_post_config (pconf=0x918a550, plog=0x91b8608, ptemp=0x91bc618, s=0x918c3f0) at /usr/src/debug/httpd-2.2.3/server/config.c:91 #8 0x00c1311d in main (argc=152602056, argv=0x9281448) at /usr/src/debug/httpd-2.2.3/server/main.c:706 and: grep /proc/$PID/maps mod_ showed mod_python to be loaded. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Request for xen guest for a Testopia proof-of-concept
Testopia (http://www.mozilla.org/projects/testopia/) is an extension of Bugzilla (http://www.bugzilla.org/) that adds test-case management, allowing test plans and result reporting to be integrated into the Bugzilla web UI. I'm looking to set up a proof of concept deployment of Testopia for Fedora. The idea is to experiment with managing installation testing via this, to see if it works better than using the wiki. There are various XML-RPC hooks it supports that might help with automating some of our testing. It patches the core of Bugzilla, and hence has to be built as part of the core package, rather than a separate srpm. I've submitted a testopia package for review as bug 450013. We wouldn't be using the bug-tracking capabilities of it; instead treat the bz nature of it as simply the libraries/modules that form the run-time environment. For now I'd like a virtual machine as a playground for setting this up. RHEL5.2 OS, 1 gig memory, and 10 gig of disk space would probably be adequate for now. I have no idea what the resource constraints are like for Fedora, so if this is unreasonable then please say so. Hope this makes sense; how does this sound? Dave ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Fedora Core 3 Update: libgnomeui-2.8.0-2
- Fedora Update Notification FEDORA-2005-937 2005-10-27 - Product : Fedora Core 3 Name: libgnomeui Version : 2.8.0 Release : 2 Summary : GNOME base GUI library Description : GNOME (GNU Network Object Model Environment) is a user-friendly set of GUI applications and desktop tools to be used in conjunction with a window manager for the X Window System. The libgnomeui package includes GUI-related libraries that are needed to run GNOME. (The libgnome package includes the library features that don\'t use the X Window System.) - Update Information: This update backports a fix to GnomeDruid, allowing accessibility tools to see its buttons (Cancel, Back, Forward, Next, etc) - * Tue Sep 27 2005 David Malcolm [EMAIL PROTECTED] - 2.8.0-2 - added patch to make GnomeDruid buttons accessible, taken from gnome bug 157936 (#169134) - This update can be downloaded from: http://download.fedora.redhat.com/pub/fedora/linux/core/updates/3/ 7fb658dd96c66aaa445e2370a22384e9 SRPMS/libgnomeui-2.8.0-2.src.rpm c023640227288c3e3cab28dfae57936c x86_64/libgnomeui-2.8.0-2.x86_64.rpm 25c75e49b36b48df6fccdadd5b9983d1 x86_64/libgnomeui-devel-2.8.0-2.x86_64.rpm e4ca833023e86a43f0e4013c1c4d9618 x86_64/debug/libgnomeui-debuginfo-2.8.0-2.x86_64.rpm 982d9f6e296feb6d80b93bbfc871913c x86_64/libgnomeui-2.8.0-2.i386.rpm 982d9f6e296feb6d80b93bbfc871913c i386/libgnomeui-2.8.0-2.i386.rpm 601ca887561c7ad577a7209541f8e499 i386/libgnomeui-devel-2.8.0-2.i386.rpm b650691c1a64dd2186b138c82a53fbfa i386/debug/libgnomeui-debuginfo-2.8.0-2.i386.rpm This update can also be installed with the Update Agent; you can launch the Update Agent with the 'up2date' command. - -- fedora-announce-list mailing list fedora-announce-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list
Re: Fedora Core 4 Update: evolution-data-server-1.2.3-3.fc4
On Mon, 2005-09-12 at 13:02 -0400, David Malcolm wrote: - Fedora Update Notification FEDORA-2005-829 2005-09-12 - Product : Fedora Core 4 Name: evolution-data-server Version : 1.2.3 Release : 3.fc4 Summary : Backend data server for evolution Description : The evolution-data-server package provides a unified backend for programs that work with contacts, tasks, and calendar information. It was originally developed for Evolution (hence the name), but is now used by other packages. - * Tue Aug 30 2005 David Malcolm [EMAIL PROTECTED] - 1.2.3-3.fc4 - Add -Werror-implicit-function-declaration to CFLAGS during make (but not during configure), to avoid 64-bit issues and add patch to fix these where they occur, also patching libdb Makefile.in to avoid this breaking the build (all of this is patch 103) This should fix a crash with Reply in Evolution on x86_64 (bug 160913) [snip] -- fedora-announce-list mailing list fedora-announce-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-announce-list
Fedora Core 3 Update: evolution-connector-2.0.4-2
- Fedora Update Notification FEDORA-2005-818 2005-08-26 - Product : Fedora Core 3 Name: evolution-connector Version : 2.0.4 Release : 2 Summary : Evolution plugin to interact with MS Exchange Server Description : The connector enables added functionality to Evolution when used with a Microsoft Exchange Server. - * Wed May 11 2005 David Malcolm [EMAIL PROTECTED] - 2.0.4-2 - added Aaron Gaudio's patch for PDA synchronization (#139393) - This update can be downloaded from: http://download.fedora.redhat.com/pub/fedora/linux/core/updates/3/ 81a05b48be0b5521cead2335ccb0f67b SRPMS/evolution-connector-2.0.4-2.src.rpm 3642d3845eb8f6c9bd06e59a3a7d1c98 x86_64/evolution-connector-2.0.4-2.x86_64.rpm c778cf69892cd75923e4ceeffc3926ff x86_64/debug/evolution-connector-debuginfo-2.0.4-2.x86_64.rpm 14644eedc24c9c744d2c119ebd99798d i386/evolution-connector-2.0.4-2.i386.rpm 3cb7a34c5b0c61330c925df195c64379 i386/debug/evolution-connector-debuginfo-2.0.4-2.i386.rpm This update can also be installed with the Update Agent; you can launch the Update Agent with the 'up2date' command. - -- fedora-announce-list mailing list fedora-announce-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-announce-list
Fedora Core 4 Update: evolution-data-server-1.2.3-2.fc4
- Fedora Update Notification FEDORA-2005-719 2005-08-11 - Product : Fedora Core 4 Name: evolution-data-server Version : 1.2.3 Release : 2.fc4 Summary : Backend data server for evolution Description : The evolution-data-server package provides a unified backend for programs that work with contacts, tasks, and calendar information. It was originally developed for Evolution (hence the name), but is now used by other packages. This update fixes a crash when editing contacts in an LDAP addressbook. - * Mon Aug 8 2005 David Malcolm [EMAIL PROTECTED] - 1.2.3-2.fc4 - Fix crash in the LDAP backend (#165269, upstream bug 311684, patch 102) * Wed Jun 29 2005 David Malcolm [EMAIL PROTECTED] - 1.2.3-1.fc4 - 1.2.3 * Mon Jun 27 2005 David Malcolm [EMAIL PROTECTED] - 1.2.2-4.fc4 - Added leak fixes for GNOME bug 309079 provided by Mark G. Adams - This update can be downloaded from: http://download.fedora.redhat.com/pub/fedora/linux/core/updates/4/ 79138ca5fb9569acceefb488e7782b9d SRPMS/evolution-data-server-1.2.3-2.fc4.src.rpm 110f17ff63ffd2eb115efceffdbe3266 ppc/evolution-data-server-1.2.3-2.fc4.ppc.rpm cbfcf213693bf321dcd596fe0a17a5ac ppc/evolution-data-server-devel-1.2.3-2.fc4.ppc.rpm d1b7832f5b14741da67c898fc9d36612 ppc/debug/evolution-data-server-debuginfo-1.2.3-2.fc4.ppc.rpm a7f5f009469bd8de74654a8265bb1eac x86_64/evolution-data-server-1.2.3-2.fc4.x86_64.rpm 172e355bd4ae9d65dd05ae82a4a40db2 x86_64/evolution-data-server-devel-1.2.3-2.fc4.x86_64.rpm fe83866b5f023a1e874e8e5308fa77d4 x86_64/debug/evolution-data-server-debuginfo-1.2.3-2.fc4.x86_64.rpm 708a8776bf4a55bd68230e69be351572 i386/evolution-data-server-1.2.3-2.fc4.i386.rpm 12b38578d852e46785660a78d1baaf0b i386/evolution-data-server-devel-1.2.3-2.fc4.i386.rpm 156ae99e89b723c845b68c87e070b9b7 i386/debug/evolution-data-server-debuginfo-1.2.3-2.fc4.i386.rpm This update can also be installed with the Update Agent; you can launch the Update Agent with the 'up2date' command. - -- fedora-announce-list mailing list fedora-announce-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-announce-list
