Bug 529548 (mingw32-libogg)

Koji scratch build here, looks OK: http://koji.fedoraproject.org/koji/taskinfo?taskID=1752861

Wasn't able to figure out how to run make check in mock. The tests complete successfully in ~/rpmbuild, but since they generate Wiin32-PE .exe files the mock run croaks due to the missing Wine binary loader, and I'd really, really want to avoid having a mingw package BR Wine.

Package looks sane, but any reason why you want to keep
the static library?

(In reply to comment #1)
> Wasn't able to figure out how to run make check in mock. The tests complete
> successfully in ~/rpmbuild, but since they generate Wiin32-PE .exe files the
> mock run croaks due to the missing Wine binary loader, and I'd really, really
> want to avoid having a mingw package BR Wine.  

That's simply not supported.  Koji might happen to run on (eg) x86-64
or PPC builder, where Wine either can't be installed or couldn't run even
if it could be installed.  Don't worry about it.

(In reply to comment #2)
> Package looks sane, but any reason why you want to keep
> the static library?

Not really, no - I just aped the behavior of some other mingw32-* library packages. Can be dropped any time (from the other dependent packages as well.)

> That's simply not supported.  Koji might happen to run on (eg) x86-64
> or PPC builder, where Wine either can't be installed or couldn't run even
> if it could be installed.  Don't worry about it.  

Thanks, I thought I was missing something. I'm still running all tests I can manually - e.g., working on mingw32-xz now, and some edge case tests fail depending on the MINGW32_CFLAGS you pick, which would seem to point to some compiler problems, so properly passing all tests should be a priority.

(In reply to comment #3)
> > That's simply not supported.  Koji might happen to run on (eg) x86-64
> > or PPC builder, where Wine either can't be installed or couldn't run even
> > if it could be installed.  Don't worry about it.  

I should explain that there are three related issues here which
stop us from running Wine.  Two are bugs (IMHO) in RPM
or Koji.  One is a bug (IMHO) in Wine itself.

(1) RPM/Koji doesn't understand cross-compilation at all.  Our
target packages are all noarch which is (sort of) correct within
the bounds of RPM[*].  Because the package is noarch, Koji decides
that it can be built on any machine, so it can choose a PPC
builder for example.  On PPC, the cross-compiler works, but Wine
could never run.  But there is no way to say to Koji that a
package is noarch, but should be built anyway on i386.

[*] If you prefer you can think of wine as an interpreter,
interpreting Win32 PE executables, something like:

 foo.pl   is interpreted by /usr/bin/perl
 foo.exe  is interpreted by /usr/bin/wine

(2) Koji won't install Wine on x86-64, because Wine is an i386
package.  Koji doesn't understand multilib (probably a good
thing, because multilib is crack).

(3) Wine after installation doesn't "just work".  You have to
fiddle with a difficult configuration file:

http://fedoraproject.org/wiki/MinGW/Configure_wine

which is difficult to automate.  Wine used to have an
environment variable (WINE_PATH or something?) but they
removed it(!)

> Thanks, I thought I was missing something. I'm still running all tests I can
> manually - e.g., working on mingw32-xz now, and some edge case tests fail
> depending on the MINGW32_CFLAGS you pick, which would seem to point to some
> compiler problems, so properly passing all tests should be a priority.  

As long as you're testing it, that's good.  It doesn't look like
we'll ever get the Koji issues fixed.

Thanks for the advice, Richard.

Improved package, bumped revision. New URLs:

Spec URL: http://rpms.limbasan.ro/fedora/11/SPECS/mingw32-libogg.spec
SRPM URL: http://rpms.limbasan.ro/fedora/11/SRPMS/mingw32-libogg-1.1.4-3.fc11.src.rpm

Changes as follows:

- Removed -static package.
- Added explicit Requirement on mingw32-filesystem.
- aclocal and pkgconfig directories under _mingw32_libdir are
  no longer installed, mingw32-filesystem already provides them.
- Removed redundant BuildRequire mingw32-binutils which is
  already Required by mingw32-gcc.
- Moved checks to the proper build stage.
- Corrected aclocal invocation.
- Cosmetic cleanup.

rpmlint says:

[mimock@home mingw32-libogg]$ rpmlint -v *rpm
mingw32-libogg.noarch: I: checking
mingw32-libogg.src: I: checking
2 packages and 0 specfiles checked; 0 errors, 0 warnings.

Koji scratch build:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1755213

(In reply to comment #4)

> But there is no way to say to Koji that a
> package is noarch, but should be built anyway on i386.

Few months ago koji and/or rpm were upgraded, so we can specify builder for the noarch subpackages!

See this specs as a starting point:

http://cvs.fedoraproject.org/viewvc/rpms/openbios/devel/openbios.spec?view=markup

I'll review it.

+ rpmlint is silent

[petro@Sulaco SPECS]$ rpmlint ../RPMS/noarch/mingw32-libogg-1.1.4-3.fc12.noarch.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
[petro@Sulaco SPECS]$ 

+ The package is named according to the Package Naming Guidelines.
+ The spec file name matches the base package %{name}, in the format %{name}.spec.

+/- The package meets the Packaging Guidelines, except I don't see any reasons for uysing %defattr(0644,roor,root,0755) instead of %defattr(-,roor,root,-). Could you, please, comment this?

+ The package is licensed with a Fedora approved license and meets the Licensing Guidelines.
+ The License field in the package spec file matches the actual license.
+ The file, containing the text of the license(s) for the package, is included in %doc.
+ The spec file is written in American English.
+ The spec file for the package is legible.
+ The sources used to build the package, match the upstream source, as provided in the spec URL.

[petro@Sulaco SOURCES]$ sha256sum libogg-1.1.4.tar.gz*
9354c183fd88417c2860778b60b7896c9487d8f6e58b9fec3fdbf971142ce103  libogg-1.1.4.tar.gz
9354c183fd88417c2860778b60b7896c9487d8f6e58b9fec3fdbf971142ce103  libogg-1.1.4.tar.gz.1
[petro@Sulaco SOURCES]$ 

+ The package successfully compiles and builds into binary rpms on at least one primary architecture (ppc).
+ All build dependencies are listed in BuildRequires.
0 No need to handle locales.
0 No need to run ldconfig for mingw32 libraries.
+ The package does NOT bundle copies of system libraries.
+ The package is not designed to be relocatable.
+ The package owns all directories that it creates.
+ The package does not list a file more than once in the spec file's %files listings.
+ Permissions on files are set properly.
+ The package has a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
+ The package consistently uses macros.
+ The package contains code, or permissible content.
0 No extremely large documentation files.
+ Anything, the package includes as %doc, does not affect the runtime of the application.
0 No need to separate header files from main package for mingw32-related package.
0 No static libraries.
0 No need to specifically handle pkgconfig(.pc) files for mingw32 (mingw32-filesystem already contains %{_mingw32_libdir}/pkgconfig directory).
0 The package doesn't contain library files with a suffix (e.g. libfoo.so.1.1).
0 No devel sub-package for mingw32 packages, since they are intended for devel entirely.
0 The mingw32 package may contain necessary .la libtool archives. This is not a blocker.
0 Not a GUI application.
+ The package does not own files or directories already owned by other packages.
+ At the beginning of %install, the package runs rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
+ All filenames in rpm packages are valid UTF-8.

Please, comment/correct %defattr and I'll continue.

Ping, Mihai!

Needinfo has been set for over a month now; if there's no response in a week, this and the other submitted review tickets will be closed.

I'm really interested in getting the mingw32 versions of libogg and libvorbis packaged up.  What can I do to help this process, seeing as Mihai's apparently AWOL?

See:
http://fedoraproject.org/wiki/PackageMaintainers/Join

Alternatively, I'd be happy to maintain this package as well. I don't have a clue how that works though. Should I just post a cvs admin request, with my name as the maintainer? Or should I open a new review request?

Thanks,
Stefan

(In reply to comment #13)
> Alternatively, I'd be happy to maintain this package as well. I don't have a
> clue how that works though. Should I just post a cvs admin request, with my
> name as the maintainer? Or should I open a new review request?

Well the review isn't finished yet.  Peter had some questions
in comment 8 which require you to post a fixed package, and
for Peter (once he is happy with it) to approve it.

I assume you have a FAS account and are a packager?  If not
you'll also need sponsorship.

This is all explained in the link I posted in comment 12.

Alright, please find an updated package here:
http://www.riemens.org/fs/temp/mingw32-libogg.spec
http://www.riemens.org/fs/temp/mingw32-libogg-1.1.4-4.fc12.src.rpm

rpmlint output:
rpmlint /home/makerpm/rpmbuild/SRPMS/mingw32-libogg-1.1.4-4.fc12.src.rpm /home/makerpm/rpmbuild/RPMS/noarch/mingw32-libogg-1.1.4-4.fc12.noarch.rpm /home/makerpm/rpmbuild/RPMS/noarch/mingw32-libogg-debuginfo-1.1.4-4.fc12.noarch.rpm
mingw32-libogg-debuginfo.noarch: E: empty-debuginfo-package
3 packages and 0 specfiles checked; 1 errors, 0 warnings.

Koji scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=1958859

Thanks,
Stefan

PS, I'm already sponsored by Peter.

Changelog entry: (forgot to add it, sorry)
* Tue Feb 2 2010 Stefan Riemens <fgfs.stefan> - 1.1.4-4
- Fix %%defattr line
- Automatically create a debuginfo package

Great! I don't see other issues with Stefan's srpm, so this package is

APPROVED.


Stefan, will you continue with packaging the rest of the Xiph's stack? If not, then, I believe, Josh could step in.

I have a few late comments.

The -debuginfo subpackage is empty. This is caused by a missing define:
%define __debug_install_post %{_mingw32_debug_install_post}

You have this:
# Automatically create a debuginfo package
%{_mingw32_debug_package}

Instead of using %{_mingw32_debug_package}, it's better to use %{?_mingw32_debug_package} (notice the question mark) to work around a problem with macros showing up unexpanded in description in Koji. See [1] for an explanation of this issue.
Can you do a new Koji scratch build to be sure that debuginfo issues are fixed?

Now that the binaries are stripped automatically, you can kill those two lines:
# Uncomment and unescape to strip the debug symbols from the resulting artifacts
#%%{_mingw32_strip} --strip-unneeded %%{buildroot}%%{_mingw32_bindir}/libogg-0.dll

Requires: pkgconfig is unneccessary in Fedora (but needed if you plan to build for EPEL). RPM in current Fedora releases is capable of extracting pkgconfig deps automatically. See [2] for updated guidlines. You don't neccessarily have to change anything here, just pointing it out.

[1] http://lists.fedoraproject.org/pipermail/devel/2010-February/130357.html
[2] https://fedoraproject.org/wiki/Packaging/Guidelines#Pkgconfig_Files

Sorry for the MIA - real life issues prevented me from being able to focus on anything Fedora- or personal life related.

I'll try to get back on this after F13 is released, targeting F12, F13 and Rawhide.

Apologies for any waste of time I may have caused.

*** This bug has been marked as a duplicate of bug 613697 ***