Bug 175237

Good:

      - MUST: rpmlint output:

E: bzr non-executable-script
/usr/lib/python2.4/site-packages/bzrlib/store/weave.py 0644
E: bzr non-executable-script /usr/lib/python2.4/site-packages/bzrlib/revfile.py 0644
E: bzr non-executable-script
/usr/lib/python2.4/site-packages/bzrlib/selftest/test_weave.py 0644
E: bzr non-executable-script /usr/lib/python2.4/site-packages/bzrlib/xml4.py 0644
E: bzr non-executable-script /usr/lib/python2.4/site-packages/bzrlib/xml5.py 0644
E: bzr non-executable-script /usr/lib/python2.4/site-packages/bzrlib/upgrade.py 0644
E: bzr non-executable-script /usr/lib/python2.4/site-packages/bzrlib/xml.py
0644E: bzr non-executable-script
/usr/lib/python2.4/site-packages/bzrlib/weave.py 0644

which I think can be ignored

      - MUST: The package is named according to the PackageNamingGuidelines.
      - MUST: The spec file name matches the base package %{name}, in the format
%{name}.spec
      - MUST: The package meets the PackagingGuidelines.
      - MUST: Bzr has a GPL license.
      - MUST: The License field in the package spec file matches the actual license.
      - MUST: The source package does not have a copy of the license, so it
isn't in %doc
      - MUST: The spec file is written in American English.
      - MUST: The spec file for the package is legible.
      - MUST: The sources used to build the package match the upstream source,
as provided in the spec URL.
      - MUST: The package successfully compiles and builds on i386/devel.
      - MUST: A package must not contain any BuildRequires that are listed in
the exceptions section of PackagingGuidelines.
      - MUST: All other Build dependencies must be listed in BuildRequires.
      - MUST: The spec file MUST handle locales properly. This is done by using
the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.
      - MUST: The package does not contain shared libraries.
      - MUST: The package is not designed to be relocatable.
      - MUST: The package owns all of the directories that it cretes.
      - MUST: Package does not contain any duplicate files in the %files listing.
      - MUST: Permissions on files are set properly. %files section includes a
%defattr(...) line.
      - MUST: Package has a %clean section, which contains rm -rf $RPM_BUILD_ROOT.
      - MUST: Each package must consistently use macros, as described in the
macros section of PackagingGuidelines.
      - MUST: The package contains code.
      - MUST: Large documentation files should go in a -docs subpackage. (The
definition of large is left up to the packager's best judgement, but is not
restricted to size. Large can refer to either size or quantity)
      - MUST: If a package includes something as %doc, it must not affect the
runtime of the application. To summarize: If it is in %doc, the program must run
properly if it is not present.
      - MUST: Header files or static libraries must be in a -devel package.
      - MUST: Files used by pkgconfig (.pc files) must be in a -devel package.
      - MUST: If a package contains library files with a suffix (e.g.
libfoo.so.1.1), then library files that end in .so (without suffix) must go in a
-devel package.
      - MUST: In the vast majority of cases, devel packages must require the
base package using a fully versioned dependency.
      - MUST: Packages does not contain any .la libtool archives, these should
be removed in the spec.
      - MUST: Package does not include a GUI app.
      - MUST: Package does not own files or directories already owned by other
packages.
      - SHOULD: Builds in mock on devel/i386, devel/x86_64, FC4/x86_64
      - SHOULD: No scriptlets are used.
      - SHOULD: There are no subpackages.

Would be nice:

      - SHOULD: If the source package does not include license text(s) as a
separate file from upstream, the packager SHOULD query upstream to include it.
      - SHOULD: The description and summary sections in the package spec file
should contain translations for supported Non-English languages, if available.

Bad:

      - SHOULD: The reviewer should test that the package functions as
described. A package should not segfault instead of running, for example.

Every command results in the following error:

[jeff@max1 ~]$ bzr help init
bzr: ERROR: No module named configobj.configobj
  command: '/usr/bin/bzr' 'help' 'init'
      pwd: u'/home/jeff'
    error: exceptions.ImportError
  at /usr/lib/python2.4/site-packages/bzrlib/config.py line 62, in ?()
  see ~/.bzr.log for debug information

NEEDSWORK

The errors are the result of an issue with the system library patch and the fact
that I had configobj installed locally.  Ideally, I'd package python-configobj
and just depend on that; but for now, I just use the one upstream bundles.
I can add a copy of the GPL to the package if it's really necessary, but cannot
do much about a non-English summary or description.

There will be updated files fixing the configobj problem shortly:
Spec Url: http://shahms.mesd.k12.or.us/yum/packages/bzr.spec 
SRPM URL: http://shahms.mesd.k12.or.us/yum/packages/bzr-0.6.2-2.src.rpm

Thanks for looking at the package.

The -2 package builds and works for me now (at least for a quick test), thanks!
 Getting a copy of the GPL into the tarball was just a suggestion to bring to
the upstream developers, as was the non-English description.

APPROVED

Shahms, I noticed that version 0.7 is out, are you going to update/get this into FE?

Yeah, getting bzr into FE is high on my TODO list, but I've been swamped with
work and school, leaving little time for much else.  Barring unforeseen events,
I should have it updated and into FE by this weekend.

bzr 0.8 is out and much improved.
it also likely to be very stable and used for a long time as it
is the version most likely to be included with ubuntu's 'long
term support' linux release.

Is 0.8 expected to make it into extras soon?

bzr 0.8 is out and much improved.
it also likely to be very stable and used for a long time as it
is the version most likely to be included with ubuntu's 'long
term support' linux release.

Is 0.8 expected to make it into extras soon?

Packages compiled yesterday should be in today's push.

Could we get an update to bzr 1.18 or 2.0.4?

2.0.4 is a major update that changes the default repository format. 1.18 can *read* that format, but it doesn't perform very well myself.