Re: Looking for testers: RPM 4.9 alpha
On Tue, 30 Nov 2010, Panu Matilainen wrote: On Mon, 29 Nov 2010, Panu Matilainen wrote: On Mon, 29 Nov 2010, Marcela Mašláňová wrote: Hello, I tried rebuild RPM on F-14. New RPM doesn't find all provides as it should. Example: RPM 4.9.alpha rpm -qp --provides perl-CGI-3.50-1.fc14.noarch.rpm perl-CGI = 3.50-1.fc14 RPM from koji: rpm -qp --provides perl-CGI-3.50-1.fc15.noarch.rpm perl(CGI) perl(CGI::Apache) = 1.01 perl(CGI::Carp) = 3.45 perl(CGI::Cookie) perl(CGI::Fast) perl(CGI::Pretty) = 3.46 perl(CGI::Push) perl(CGI::Switch) = 1.01 perl(CGITempFile) perl(CGI::Util) = 3.48 perl(Fh) perl(MultipartBuffer) perl(utf8) perl-CGI = 3.50-1.fc15 I suppose RPM was looking for all strings 'package' in source code. Could you look at it? As test SRPM you can use: http://mmaslano.fedorapeople.org/review/perl-CGI-3.50-1.fc14.src.rpm Yeah, that seems fairly broken. I'll have a look, thanks for testing and reporting - this is just the kind of stuff I want to find out /before/ this hits rawhide :) To follow up on this one: dependency extraction for perl modules is just plain broken in the alpha due to a dumb thinko/typo kind of thing. Additionally there's an unforeseen interaction with 'rpmdeps' use (which the filtering macros rely on) which causes some further breakage in some cases, including this. Both are easy enough to fix though, I'll push an updated snapshot in a day or two. Okay, there's now an updated snapshot fixing this and some other issues (mono dependency extraction was probably broken too): http://laiskiainen.org/rpm/srpms/rpm-4.8.90-0.git10730.1.src.rpm - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
Panu Matilainen schreef op vr 26-11-2010 om 13:20 [+0200]:
In particular, I'm interested in feedback on the new, pluggable and
enhanced dependency extration system. Documentation is scarce at the
moment but some background and examples can be found here:
http://laiskiainen.org/blog/?p=35
All mingw32 packages in Fedora contain these set of instructions in
the .spec files:
%global _use_internal_dependency_generator 0
%global __find_requires %{_mingw32_findrequires}
%global __find_provides %{_mingw32_findprovides}
Does this new dependency extraction system make these kind of
instructions obsolete?
If I understand your blog entry correctly then we (the Fedora MinGW SIG)
are recommended to use something like this:
%__mingw32_provides %{_mingw32_findprovides}
%__mingw32_requires %{_mingw32_findrequires}
Is this correct or do you recommend something different?
The macros %{_mingw32_findrequires} and %{_mingw32_findprovides} are
mentioned in the file /etc/rpm/macros.mingw32 which is part of the
mingw32-filesystem package. Both refer to a small shell script which
uses the i686-pc-mingw32-objdump tool to extract dependency information.
Kind regards,
Erik van Pienbroek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
On Tue, 30 Nov 2010, Erik van Pienbroek wrote:
Panu Matilainen schreef op vr 26-11-2010 om 13:20 [+0200]:
In particular, I'm interested in feedback on the new, pluggable and
enhanced dependency extration system. Documentation is scarce at the
moment but some background and examples can be found here:
http://laiskiainen.org/blog/?p=35
All mingw32 packages in Fedora contain these set of instructions in
the .spec files:
%global _use_internal_dependency_generator 0
%global __find_requires %{_mingw32_findrequires}
%global __find_provides %{_mingw32_findprovides}
Does this new dependency extraction system make these kind of
instructions obsolete?
The above still works with the new rpm version.
If I understand your blog entry correctly then we (the Fedora MinGW SIG)
are recommended to use something like this:
%__mingw32_provides %{_mingw32_findprovides}
%__mingw32_requires %{_mingw32_findrequires}
Is this correct or do you recommend something different?
That alone wont do anything at all, to create a new file attribute
called mingw32 you'd add a file like this to a suitable package,
mingw32-filesystem probably:
/usr/lib/rpm/fileattrs/mingw32.attr:
%__mingw32_requires /usr/lib/rpm/mingw32-find-requires.sh
%__mingw32_provides /usr/lib/rpm/mingw32-find-provides.sh
%__mingw32_magic^PE32 executable for MS Windows.* 80386 32-bit$
The magic rule is based on what 'file -b file' outputs for mingw32
executables and dll's - the above includes both, but you can make it
tighter to only include DLL's or have different extractors for DLL's and
EXE's by creating two rules instead of just one etc. Or if libmagic
strings aren't good (fakedll binaries from Wine would match the above
rule), path based regexes can be used too. It all depends on what makes
sense in a given scenario.
You could also easily have a mingw32-specific pkg-config dependency
extractor which uses a different namespace than the regular pkgconfig(foo)
and only activates on .pc files from the mingw32 sys-root directory.
And with necessary mingw32-specific .attr files in place through
buildrequires, there's no need for override kludges in each and every
mingw32 spec.
- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
Panu Matilainen schreef op di 30-11-2010 om 22:10 [+0200]:
On Tue, 30 Nov 2010, Erik van Pienbroek wrote:
If I understand your blog entry correctly then we (the Fedora MinGW SIG)
are recommended to use something like this:
%__mingw32_provides %{_mingw32_findprovides}
%__mingw32_requires %{_mingw32_findrequires}
Is this correct or do you recommend something different?
That alone wont do anything at all, to create a new file attribute
called mingw32 you'd add a file like this to a suitable package,
mingw32-filesystem probably:
/usr/lib/rpm/fileattrs/mingw32.attr:
%__mingw32_requires /usr/lib/rpm/mingw32-find-requires.sh
%__mingw32_provides /usr/lib/rpm/mingw32-find-provides.sh
%__mingw32_magic ^PE32 executable for MS Windows.* 80386 32-bit$
The magic rule is based on what 'file -b file' outputs for mingw32
executables and dll's - the above includes both, but you can make it
tighter to only include DLL's or have different extractors for DLL's and
EXE's by creating two rules instead of just one etc. Or if libmagic
strings aren't good (fakedll binaries from Wine would match the above
rule), path based regexes can be used too. It all depends on what makes
sense in a given scenario.
You could also easily have a mingw32-specific pkg-config dependency
extractor which uses a different namespace than the regular pkgconfig(foo)
and only activates on .pc files from the mingw32 sys-root directory.
And with necessary mingw32-specific .attr files in place through
buildrequires, there's no need for override kludges in each and every
mingw32 spec.
Ah yes, thanks for the detailed information. This sure looks interesting
for us! I'll try to play around a bit with this in a mock environment
and see if it's possible to update our packaging guidelines to make use
of it.
Regards,
Erik van Pienbroek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
On Tue, 30 Nov 2010, Erik van Pienbroek wrote:
Panu Matilainen schreef op di 30-11-2010 om 22:10 [+0200]:
On Tue, 30 Nov 2010, Erik van Pienbroek wrote:
If I understand your blog entry correctly then we (the Fedora MinGW SIG)
are recommended to use something like this:
%__mingw32_provides %{_mingw32_findprovides}
%__mingw32_requires %{_mingw32_findrequires}
Is this correct or do you recommend something different?
That alone wont do anything at all, to create a new file attribute
called mingw32 you'd add a file like this to a suitable package,
mingw32-filesystem probably:
/usr/lib/rpm/fileattrs/mingw32.attr:
%__mingw32_requires /usr/lib/rpm/mingw32-find-requires.sh
%__mingw32_provides /usr/lib/rpm/mingw32-find-provides.sh
%__mingw32_magic ^PE32 executable for MS Windows.* 80386 32-bit$
The magic rule is based on what 'file -b file' outputs for mingw32
executables and dll's - the above includes both, but you can make it
tighter to only include DLL's or have different extractors for DLL's and
EXE's by creating two rules instead of just one etc. Or if libmagic
strings aren't good (fakedll binaries from Wine would match the above
rule), path based regexes can be used too. It all depends on what makes
sense in a given scenario.
You could also easily have a mingw32-specific pkg-config dependency
extractor which uses a different namespace than the regular pkgconfig(foo)
and only activates on .pc files from the mingw32 sys-root directory.
And with necessary mingw32-specific .attr files in place through
buildrequires, there's no need for override kludges in each and every
mingw32 spec.
Ah yes, thanks for the detailed information. This sure looks interesting
for us! I'll try to play around a bit with this in a mock environment
and see if it's possible to update our packaging guidelines to make use
of it.
Do play around with it if you can, but I'd suggest leaving the packaging
guideline considerations until the new rpm has actually landed AND gotten
past the final feature acceptance line. The mechanism is likely to grow
some enhancements before that, and also more than just mingw32 guidelines
should be revisited + revised then (and might well be F16 material)
- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
On Mon, 29 Nov 2010, Panu Matilainen wrote: On Mon, 29 Nov 2010, Marcela Mašláňová wrote: Hello, I tried rebuild RPM on F-14. New RPM doesn't find all provides as it should. Example: RPM 4.9.alpha rpm -qp --provides perl-CGI-3.50-1.fc14.noarch.rpm perl-CGI = 3.50-1.fc14 RPM from koji: rpm -qp --provides perl-CGI-3.50-1.fc15.noarch.rpm perl(CGI) perl(CGI::Apache) = 1.01 perl(CGI::Carp) = 3.45 perl(CGI::Cookie) perl(CGI::Fast) perl(CGI::Pretty) = 3.46 perl(CGI::Push) perl(CGI::Switch) = 1.01 perl(CGITempFile) perl(CGI::Util) = 3.48 perl(Fh) perl(MultipartBuffer) perl(utf8) perl-CGI = 3.50-1.fc15 I suppose RPM was looking for all strings 'package' in source code. Could you look at it? As test SRPM you can use: http://mmaslano.fedorapeople.org/review/perl-CGI-3.50-1.fc14.src.rpm Yeah, that seems fairly broken. I'll have a look, thanks for testing and reporting - this is just the kind of stuff I want to find out /before/ this hits rawhide :) To follow up on this one: dependency extraction for perl modules is just plain broken in the alpha due to a dumb thinko/typo kind of thing. Additionally there's an unforeseen interaction with 'rpmdeps' use (which the filtering macros rely on) which causes some further breakage in some cases, including this. Both are easy enough to fix though, I'll push an updated snapshot in a day or two. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
On Sun, 28 Nov 2010, Simo Sorce wrote:
On Sun, 28 Nov 2010 12:15:52 +0200 (EET)
Panu Matilainen pmati...@laiskiainen.org wrote:
On Sun, 28 Nov 2010, Kevin Kofler wrote:
Panu Matilainen wrote:
The draft release notes are at http://rpm.org/wiki/Releases/4.9.0
1. This change:
| Packages with no files can now omit the %files section and still
have | packages generated.
is going to make it a PITA to conditionalize the building of
subpackages, and it's going to break several existing KDE specfiles
very badly (and with no warning!): RPM will silently generate empty
subpackages where none is wanted.
More precisely, when we wanted to conditionalize or comment out the
creation of a subpackage (e.g. in kde-l10n for languages which are
currently not available), what we did so far was to %if out only
the %files section for the subpackage, not %package or things like
%post, and this would reliably omit the subpackage. Now we'll have
to %if out ALL sections referring to the subpackage: %package to
prevent the subpackage from being built, and all other sections
referring to it because they'll error out if the %package is not
there.
This change can be reconsidered.
Wouldn't it be better instead to create a specific directive to disable
unwanted subpackages ?
Something like:
%suppress subpackagename
This would make it clear what the author of the RPMs wants to do w/o
relying on hacks like suppressing the %files section.
Bonus if it checks the suppressed package %files for installed files
that need to be skipped even if not packaged so as to not error out.
Not a bad idea at all, although I'd guess a better syntax would be a
boolean enable/disable tag similar to AutoReq etc. That'd allow nice
integration with build conditionals, such as
%bcond_without foo
...
%package foo
BuildRequires: bar-devel
Summary: ...
BuildPkg: %{with foo}
- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
On 11/26/2010 12:20 PM, Panu Matilainen wrote: It's that time of year again, although there seems to be an off-by-one bug in the calendar system causing some inconsistency in the timing wrt last year :P http://lists.fedoraproject.org/pipermail/devel/2009-November/042339.html Anyway, before going to beta and starting the inevitable Fedora Feature process, we'd like some extra preliminary testing to catch out any major issues early on. The alpha isn't supposed to eat your system alive or anything, but proceed with appropriate cauting, backing up the rpmdb etc, as usual. The draft release notes are at http://rpm.org/wiki/Releases/4.9.0 and Fedora compatible SRPM(s) can be found at http://laiskiainen.org/rpm/srpms/ In particular, I'm interested in feedback on the new, pluggable and enhanced dependency extration system. Documentation is scarce at the moment but some background and examples can be found here: http://laiskiainen.org/blog/?p=35 Note that the current SRPM is missing gstreamer plugin, cups driver and automatic devel-symlink dependency generation, on purpose: the highly application-domain specific gstreamer + cups bits can now be fully moved out of rpm to gstreamer-devel etc, eliminating the need for embedding python inside /bin/sh scripts and such to avoid extra dependencies. The devel-symlink generation will stay in rpm but will probably change somewhat, it can be handled in a more generic fashion now. Please report any oddities found, preferably to rpm.org Trac at http://rpm.org/newticket or rpm-maint list (or here for fedora-specific discussions/suggestions etc). P.S. Pjones, before you ask ;) The much wanted ordering-only feature is not in the alpha, but is likely to make it into beta. The patch itself is fairly trivial and non-intrusive, we're just trying to figure sane spec syntax for it (discussion ongoing on rpm-maint) - Panu - Hello, I tried rebuild RPM on F-14. New RPM doesn't find all provides as it should. Example: RPM 4.9.alpha rpm -qp --provides perl-CGI-3.50-1.fc14.noarch.rpm perl-CGI = 3.50-1.fc14 RPM from koji: rpm -qp --provides perl-CGI-3.50-1.fc15.noarch.rpm perl(CGI) perl(CGI::Apache) = 1.01 perl(CGI::Carp) = 3.45 perl(CGI::Cookie) perl(CGI::Fast) perl(CGI::Pretty) = 3.46 perl(CGI::Push) perl(CGI::Switch) = 1.01 perl(CGITempFile) perl(CGI::Util) = 3.48 perl(Fh) perl(MultipartBuffer) perl(utf8) perl-CGI = 3.50-1.fc15 I suppose RPM was looking for all strings 'package' in source code. Could you look at it? As test SRPM you can use: http://mmaslano.fedorapeople.org/review/perl-CGI-3.50-1.fc14.src.rpm Thank you, Marcela -- Marcela Mašláňová BaseOS team Brno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
PM == Panu Matilainen pmati...@laiskiainen.org writes: PM In particular, I'm interested in feedback on the new, pluggable and PM enhanced dependency extration system. Documentation is scarce at the PM moment but some background and examples can be found here: PM http://laiskiainen.org/blog/?p=35 Unfortunately laiskiainen.org isn't responding for me at the moment, so I can't check the actual packages, but could you comment on whether rpm-builds dependency list will be changing as a result of this? Because if so we'll have to work through a round of build failures as things which used to be in the buildroot purely due to rpm-build might no longer be there. I'm thinking of perl in particular. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
On Mon, 29 Nov 2010 10:15:47 -0600 Jason L Tibbitts III ti...@math.uh.edu wrote: PM == Panu Matilainen pmati...@laiskiainen.org writes: PM In particular, I'm interested in feedback on the new, pluggable PM and enhanced dependency extration system. Documentation is scarce PM at the moment but some background and examples can be found here: PM http://laiskiainen.org/blog/?p=35 Unfortunately laiskiainen.org isn't responding for me at the moment, so I can't check the actual packages, but could you comment on whether rpm-builds dependency list will be changing as a result of this? Because if so we'll have to work through a round of build failures as things which used to be in the buildroot purely due to rpm-build might no longer be there. I'm thinking of perl in particular. It's working now. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
On Mon, 29 Nov 2010, Marcela Mašláňová wrote: On 11/26/2010 12:20 PM, Panu Matilainen wrote: It's that time of year again, although there seems to be an off-by-one bug in the calendar system causing some inconsistency in the timing wrt last year :P http://lists.fedoraproject.org/pipermail/devel/2009-November/042339.html Anyway, before going to beta and starting the inevitable Fedora Feature process, we'd like some extra preliminary testing to catch out any major issues early on. The alpha isn't supposed to eat your system alive or anything, but proceed with appropriate cauting, backing up the rpmdb etc, as usual. The draft release notes are at http://rpm.org/wiki/Releases/4.9.0 and Fedora compatible SRPM(s) can be found at http://laiskiainen.org/rpm/srpms/ In particular, I'm interested in feedback on the new, pluggable and enhanced dependency extration system. Documentation is scarce at the moment but some background and examples can be found here: http://laiskiainen.org/blog/?p=35 Note that the current SRPM is missing gstreamer plugin, cups driver and automatic devel-symlink dependency generation, on purpose: the highly application-domain specific gstreamer + cups bits can now be fully moved out of rpm to gstreamer-devel etc, eliminating the need for embedding python inside /bin/sh scripts and such to avoid extra dependencies. The devel-symlink generation will stay in rpm but will probably change somewhat, it can be handled in a more generic fashion now. Please report any oddities found, preferably to rpm.org Trac at http://rpm.org/newticket or rpm-maint list (or here for fedora-specific discussions/suggestions etc). P.S. Pjones, before you ask ;) The much wanted ordering-only feature is not in the alpha, but is likely to make it into beta. The patch itself is fairly trivial and non-intrusive, we're just trying to figure sane spec syntax for it (discussion ongoing on rpm-maint) - Panu - Hello, I tried rebuild RPM on F-14. New RPM doesn't find all provides as it should. Example: RPM 4.9.alpha rpm -qp --provides perl-CGI-3.50-1.fc14.noarch.rpm perl-CGI = 3.50-1.fc14 RPM from koji: rpm -qp --provides perl-CGI-3.50-1.fc15.noarch.rpm perl(CGI) perl(CGI::Apache) = 1.01 perl(CGI::Carp) = 3.45 perl(CGI::Cookie) perl(CGI::Fast) perl(CGI::Pretty) = 3.46 perl(CGI::Push) perl(CGI::Switch) = 1.01 perl(CGITempFile) perl(CGI::Util) = 3.48 perl(Fh) perl(MultipartBuffer) perl(utf8) perl-CGI = 3.50-1.fc15 I suppose RPM was looking for all strings 'package' in source code. Could you look at it? As test SRPM you can use: http://mmaslano.fedorapeople.org/review/perl-CGI-3.50-1.fc14.src.rpm Yeah, that seems fairly broken. I'll have a look, thanks for testing and reporting - this is just the kind of stuff I want to find out /before/ this hits rawhide :) - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
On Mon, 29 Nov 2010, Jason L Tibbitts III wrote: PM == Panu Matilainen pmati...@laiskiainen.org writes: PM In particular, I'm interested in feedback on the new, pluggable and PM enhanced dependency extration system. Documentation is scarce at the PM moment but some background and examples can be found here: PM http://laiskiainen.org/blog/?p=35 Unfortunately laiskiainen.org isn't responding for me at the moment, so I can't check the actual packages, but could you comment on whether rpm-builds dependency list will be changing as a result of this? Because if so we'll have to work through a round of build failures as things which used to be in the buildroot purely due to rpm-build might no longer be there. I'm thinking of perl in particular. I don't expect changes to rpm-build's dependencies for the time being. The pluggability just makes it /possible/ to add new things without dragging them in as dependencies or jumping through nutty hoops to avoid them. At some point (maybe for F16, I dunno) we might want to look at pushing some of the current dependencies like perl out to perl-related packages etc, but that's not an immediate goal. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
On Sun, 28 Nov 2010, Kevin Kofler wrote: Panu Matilainen wrote: The draft release notes are at http://rpm.org/wiki/Releases/4.9.0 1. This change: | Packages with no files can now omit the %files section and still have | packages generated. is going to make it a PITA to conditionalize the building of subpackages, and it's going to break several existing KDE specfiles very badly (and with no warning!): RPM will silently generate empty subpackages where none is wanted. More precisely, when we wanted to conditionalize or comment out the creation of a subpackage (e.g. in kde-l10n for languages which are currently not available), what we did so far was to %if out only the %files section for the subpackage, not %package or things like %post, and this would reliably omit the subpackage. Now we'll have to %if out ALL sections referring to the subpackage: %package to prevent the subpackage from being built, and all other sections referring to it because they'll error out if the %package is not there. This change can be reconsidered. 2. I presume this: | Unknown dependency qualifiers are now always treated as errors and abort | build also includes Requires(hint), or is that finally used now? The specfiles maintained or comaintained by Rex Dieter (and they're many!) have Requires(hint) in many places. If this is really an error now, then that change is breaking all of KDE and its dependencies and several other packages in Fedora. ...but this I've no sympathy for. You're relying on a stupid, longstanding bug on rpm that makes it accept Requires(randomjunk) in some situations: in older versions Requires(pre,junk) and Requires(junk) falls through silently in older versions but eg Requires(junk,pre) - and Requires(hint,pre) does give an error. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
On Sat, 27 Nov 2010, Rahul Sundaram wrote: On 11/26/2010 04:50 PM, Panu Matilainen wrote: The draft release notes are at http://rpm.org/wiki/Releases/4.9.0 and Fedora compatible SRPM(s) can be found at http://laiskiainen.org/rpm/srpms/ I am using this now on my Fedora 14 box and I haven't noticed any obvious breakages. Good. Beyond that, if you want me to test something, let me know. The new dependency generator is where I suspect some regressions might be lurking - try building packages (for example ones that you maintain), check that all the expected automatic dependencies are there and that it doesn't fall over in other ways. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
On 11/28/2010 04:17 PM, Panu Matilainen wrote: The new dependency generator is where I suspect some regressions might be lurking - try building packages (for example ones that you maintain), check that all the expected automatic dependencies are there and that it doesn't fall over in other ways. aria2 local build failed locally but is successful if build on Koji. I am pretty sure it is the new RPM that is causing it to fail and I screwed up trying to downgrade the package and had to use rpm2cpio to put everything together again. If you want to test the build, grab the srpm from http://koji.fedoraproject.org/koji/buildinfo?buildID=206683 Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
On Sun, 28 Nov 2010, Rahul Sundaram wrote: On 11/28/2010 04:17 PM, Panu Matilainen wrote: The new dependency generator is where I suspect some regressions might be lurking - try building packages (for example ones that you maintain), check that all the expected automatic dependencies are there and that it doesn't fall over in other ways. aria2 local build failed locally but is successful if build on Koji. I am pretty sure it is the new RPM that is causing it to fail and I screwed up trying to downgrade the package and had to use rpm2cpio to put everything together again. If you want to test the build, grab the srpm from http://koji.fedoraproject.org/koji/buildinfo?buildID=206683 Built fine here, dunno. What exactly went wrong with your build? It failed isn't a particularly helpful description. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
On Sun, 28 Nov 2010 12:15:52 +0200 (EET) Panu Matilainen pmati...@laiskiainen.org wrote: On Sun, 28 Nov 2010, Kevin Kofler wrote: Panu Matilainen wrote: The draft release notes are at http://rpm.org/wiki/Releases/4.9.0 1. This change: | Packages with no files can now omit the %files section and still have | packages generated. is going to make it a PITA to conditionalize the building of subpackages, and it's going to break several existing KDE specfiles very badly (and with no warning!): RPM will silently generate empty subpackages where none is wanted. More precisely, when we wanted to conditionalize or comment out the creation of a subpackage (e.g. in kde-l10n for languages which are currently not available), what we did so far was to %if out only the %files section for the subpackage, not %package or things like %post, and this would reliably omit the subpackage. Now we'll have to %if out ALL sections referring to the subpackage: %package to prevent the subpackage from being built, and all other sections referring to it because they'll error out if the %package is not there. This change can be reconsidered. Wouldn't it be better instead to create a specific directive to disable unwanted subpackages ? Something like: %suppress subpackagename This would make it clear what the author of the RPMs wants to do w/o relying on hacks like suppressing the %files section. Bonus if it checks the suppressed package %files for installed files that need to be skipped even if not packaged so as to not error out. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
Le dimanche 28 novembre 2010 à 12:15 +0200, Panu Matilainen a écrit : On Sun, 28 Nov 2010, Kevin Kofler wrote: Panu Matilainen wrote: The draft release notes are at http://rpm.org/wiki/Releases/4.9.0 1. This change: | Packages with no files can now omit the %files section and still have | packages generated. is going to make it a PITA to conditionalize the building of subpackages, and it's going to break several existing KDE specfiles very badly (and with no warning!): RPM will silently generate empty subpackages where none is wanted. More precisely, when we wanted to conditionalize or comment out the creation of a subpackage (e.g. in kde-l10n for languages which are currently not available), what we did so far was to %if out only the %files section for the subpackage, not %package or things like %post, and this would reliably omit the subpackage. Now we'll have to %if out ALL sections referring to the subpackage: %package to prevent the subpackage from being built, and all other sections referring to it because they'll error out if the %package is not there. This change can be reconsidered. I use this bit too though I'd rather have an explcit way to kill a subpackage rather than relying on empty %files -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
Panu Matilainen wrote: The draft release notes are at http://rpm.org/wiki/Releases/4.9.0 1. This change: | Packages with no files can now omit the %files section and still have | packages generated. is going to make it a PITA to conditionalize the building of subpackages, and it's going to break several existing KDE specfiles very badly (and with no warning!): RPM will silently generate empty subpackages where none is wanted. More precisely, when we wanted to conditionalize or comment out the creation of a subpackage (e.g. in kde-l10n for languages which are currently not available), what we did so far was to %if out only the %files section for the subpackage, not %package or things like %post, and this would reliably omit the subpackage. Now we'll have to %if out ALL sections referring to the subpackage: %package to prevent the subpackage from being built, and all other sections referring to it because they'll error out if the %package is not there. 2. I presume this: | Unknown dependency qualifiers are now always treated as errors and abort | build also includes Requires(hint), or is that finally used now? The specfiles maintained or comaintained by Rex Dieter (and they're many!) have Requires(hint) in many places. If this is really an error now, then that change is breaking all of KDE and its dependencies and several other packages in Fedora. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Looking for testers: RPM 4.9 alpha
It's that time of year again, although there seems to be an off-by-one bug in the calendar system causing some inconsistency in the timing wrt last year :P http://lists.fedoraproject.org/pipermail/devel/2009-November/042339.html Anyway, before going to beta and starting the inevitable Fedora Feature process, we'd like some extra preliminary testing to catch out any major issues early on. The alpha isn't supposed to eat your system alive or anything, but proceed with appropriate cauting, backing up the rpmdb etc, as usual. The draft release notes are at http://rpm.org/wiki/Releases/4.9.0 and Fedora compatible SRPM(s) can be found at http://laiskiainen.org/rpm/srpms/ In particular, I'm interested in feedback on the new, pluggable and enhanced dependency extration system. Documentation is scarce at the moment but some background and examples can be found here: http://laiskiainen.org/blog/?p=35 Note that the current SRPM is missing gstreamer plugin, cups driver and automatic devel-symlink dependency generation, on purpose: the highly application-domain specific gstreamer + cups bits can now be fully moved out of rpm to gstreamer-devel etc, eliminating the need for embedding python inside /bin/sh scripts and such to avoid extra dependencies. The devel-symlink generation will stay in rpm but will probably change somewhat, it can be handled in a more generic fashion now. Please report any oddities found, preferably to rpm.org Trac at http://rpm.org/newticket or rpm-maint list (or here for fedora-specific discussions/suggestions etc). P.S. Pjones, before you ask ;) The much wanted ordering-only feature is not in the alpha, but is likely to make it into beta. The patch itself is fairly trivial and non-intrusive, we're just trying to figure sane spec syntax for it (discussion ongoing on rpm-maint) - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
2010/11/26 Panu Matilainen pmati...@laiskiainen.org: the new, pluggable and enhanced dependency extration system. That's really awesome! -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
On 11/26/2010 04:50 PM, Panu Matilainen wrote: The draft release notes are at http://rpm.org/wiki/Releases/4.9.0 and Fedora compatible SRPM(s) can be found at http://laiskiainen.org/rpm/srpms/ I am using this now on my Fedora 14 box and I haven't noticed any obvious breakages. Beyond that, if you want me to test something, let me know. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
