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 > > 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
> 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 -e"s/.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
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: 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 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 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 13:07 -0500, Chris Adams wrote: > Once upon a time, Josh Boyer 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
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 -e"s/.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: GNU libc confusion with symbols undefined.
On Fri, 2009-09-18 at 09:21 -0500, Brown, Rodrick wrote:
> I'm trying to understand the following here
>
> I have a simple test program that calls memcpy/malloc/printf
>
> int
> main(int argc, char **argv)
> {
> char * p = malloc(10);
> memcpy(p,"Hello",6);
> printf("%s\n", p);
> }
>
> When looking at the symbol list why are the following routines undefined? And
> why is it referncing GLIBC_2.2.5?
>
> $ nm /tmp/f |grep ' U '
> U __libc_start_main@@GLIBC_2.2.5
> U malloc@@GLIBC_2.2.5
> U memcpy@@GLIBC_2.2.5
> U printf@@GLIBC_2.2.5
>
> $ rpm -qa |grep -i glibc
> glibc-2.3.4-2.41
> glibc-common-2.3.4-2.41
> glibc-2.3.4-2.41
>
> I really can't find an explination for this and was wondering if someone
> could clear it up.
libc has "versioned symbols", and you're linking against the default
implementations of each of the three symbols, as defined in the version
of libc you built against (the "@@" notation means the default version
of a versioned symbol).
For detailed information on this, see:
http://people.redhat.com/drepper/dsohowto.pdf
and for the most detail, see:
http://people.redhat.com/drepper/symbol-versioning
Hope this helps
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 14:14 -0400, Seth Vidal wrote: > > On Thu, 17 Sep 2009, David Malcolm wrote: > > > 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. > > > > maybe a bit more thourough but I wouldn't call it superior - it takes > forever to complete b/c you have to look at all those headers :( > > Magic alternatives welcome. Well, define "forever"... my script takes about 30 seconds (and ~1GB RAM) on my workstation; if that's a bit improvement over your runtimes, perhaps you could try a hybrid approach of walking the filelist.xml.gz to quickly find possible conflicts, then only opening the rpm headers as needed to reject the false conflicts? Dunno [snip content-addressed storage/hashing ideas] 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
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
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: 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
