Re: rpm-buildroot-usage
On Fri, 21 Jan 2011 10:54:13 -0800, Brad wrote:
> On 11:59 AM, Michael Schwendt wrote:
> > On Wed, 19 Jan 2011 06:57:09 -0800, Brad wrote:
> >
> >> I am using the compile directive
> >> -I%{buildroot}%{_includedir}
> >> during the test phase of a projects rpm build. This tests the installed
> >> copy of the include files instead of the copy in the distribution (and
> >> hence is a better test of the install).
> >>
> >> The problem is that rpmlint complains with the warning
> >> W: rpm-buildroot-usage.
> >> Is there another rpm macro I should use to specify the path
> >> %{buildroot}%{_includedir} ?
> > Can you upload the spec file to some public place?
> > Without a look at it, it's hard to guess where you use %buildroot.
> >
> I have placed a copy of the current cppad.spec file in
> https://projects.coin-or.org/CppAD/browser/trunk/cppad.spec
>
> One thing I do not understand about
> fedpkg mockbuild
> is why the standard include directories; like
> /usr/include
> are not automatically in the g++ include search path.
That is _very_ unlikely to be true.
> This is the reason
> that I need to use
> g++ -I %{buildroot}%{_includedir}
> during my test (and have to change my makefile.in to do so).
Further above you refer to /usr/include whereas here you refer to
%{buildroot}/usr/include. Obviously, with %buildroot being a temporary
directory only, g++ does not know about it at all. %buildroot expands
to a temporary path somewhere in the rpmbuild tree.
At the time of writing this mail, Firefox did not succeed in downloading
the spec from above https URL. At most it managed to get to the "connected"
status, but no further.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: @core in F14 pulls in libX11
On Sat, Jan 22, 2011 at 6:54 AM, Garrett Holmstrom wrote: > It seems that the "core" yum group pulls in X11 libraries, at the very > least on x86_64, via the following dependency chain: > > policycoreutils > dbus-glib > gobject-introspection > cairo > libX11 > > Does that much seriously need to be in what we consider a bare minimum > Fedora install? I've noticed that as well and I don't think core should have anything X related, the problem is that selinux being a core feature of fedora and something I believe should be in a bare minimum install the question then becomes how the policycoreutils package can be split up to have only a cli in it with all the gui deps moved into the the -gui subpackage that already exists. It might be a simple packaging bug where there's a file that should be in -gui made it into the base package. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: @core in F14 pulls in libX11
Garrett Holmstrom wrote, at 01/22/2011 03:54 PM +9:00: > It seems that the "core" yum group pulls in X11 libraries, at the very > least on x86_64, via the following dependency chain: > > policycoreutils > dbus-glib > gobject-introspection > cairo > libX11 > > Does that much seriously need to be in what we consider a bare minimum > Fedora install? Seems it is fixed in rawhide (ingobject-introspection) http://lists.fedoraproject.org/pipermail/fedora-server-list/2010-September/000185.html Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20110122 changes
Compose started at Sat Jan 22 08:15:21 UTC 2011 Broken deps for x86_64 -- beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0(VER_1)(64bit) beagle-0.3.9-19.fc14.x86_64 requires libwv-1.2.so.3()(64bit) coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(Osetb) = 0:8f21a0a4f771662673604ed92a237d79 coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(Flag) = 0:88862d84db594e5181afc1c5f7aa87fb coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(ANSITerminal) = 0:3d0d1700618d8b3a4e4b2308f28cefb6 coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(Oassocb) = 0:d873c4a1eeb6fa5c5333f8658c49d1db coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(Dumper) = 0:76126ba149caeb2d34f12e11187a9d4e coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(SetPt) = 0:b69c030e8ca717d556d3d9bd2a5d22fd coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(Setb) = 0:93bdb588146a13126bfad4eab6c58206 coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(Mapb) = 0:617c09a110cef9f040335b35078c7234 coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(Sexplib) = 0:a990ea80438337d5407bbc0343c7236a coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(Ograph2way) = 0:7442f647b0a74ed48a5c9361fc42ccc4 coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(Oassoch) = 0:87f7dc2635e5a7ed1ab03b7cd5380ace coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(Oassoc_buffer) = 0:cf6fbee4fcc6644a0a90f07da8eb6c7b coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(Oseti) = 0:a937e7661f510c17bfd21d4372507795 cpm-0.23-0.3.beta.fc12.x86_64 requires libdotconf-1.0.so.0()(64bit) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 dh-make-0.55-2.fc15.noarch requires debhelper eog-plugins-2.30.0-2.fc14.x86_64 requires libgdata.so.7()(64bit) gdcm-2.0.16-8.fc15.i686 requires libopenjpeg.so.2 gdcm-2.0.16-8.fc15.x86_64 requires libopenjpeg.so.2()(64bit) gedit-vala-0.10.2-2.fc15.i686 requires libvala-0.10.so.0 gedit-vala-0.10.2-2.fc15.x86_64 requires libvala-0.10.so.0()(64bit) 1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gnome-gmail-notifier-0.10.1-1.fc14.x86_64 requires libnotify.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevdocument.so.3()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevview.so.3()(64bit) gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-gdl-2.25.3-22.fc15.x86_64 requires libgdl-1.so.3()(64bit) gnome-python2-totem-2.32.0-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(Mono.Data.SqliteClient) = 0:2.0.0.0 gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libgdl-1.so.3()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-gtk-0.6.so.0()(64bit) gshutdown-0.2-6.fc12.x86_64 requires libnotify.so.1()(64bit) gsql-0.2.1-4.fc12.i686 requires libnotify.so.1 gsql-0.2.1-4.fc12.x86_64 requires libnotify.so.1()(64bit) gsql-engine-mysql-0.2.1-4.fc12.x86_64 requires libmysqlclient_r.so.16()(64bit) gsql-engine-mysql-0.2.1-4.fc12.x86_64 requires libmysqlclient_r.so.16(libmysqlclient_16)(64bit) gtranslator-1.9.11-3.fc15.x86_64 requires libgdl-1.so.3()(64bit) gyachi-plugin-libnotify-1.2.10-3.fc14.x86_64 requires libnotify.so.1()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libnotify.so.1()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) intellij-idea-9.0.1.94.399-12.fc15.x86_64 requires commons-collections java-gnome-4.0.16-3.fc14.x86_64 requires libnotify.so.1()(64bit) libextractor-plugins-rpm-0.6.2-1505.fc15.x86_64 requires librpm.so.1()(64bit) libnotifymm-0.6.1-8.fc14.i686 requires libnotify.so.1 libnotifymm-0.6.1-8.fc14.x86_64 requires libnotify.so.1()(64bit) log4net-1.2.10-13.fc13.x86_64 requires mono(System) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Data) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(mscorlib) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Xml) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Web) = 0:1.0.5000.0 1:logjam-4.6.0-1.fc15.x86_64 requires libgtkhtml-3
Re: noexec on /dev/shm
On Fri, Jan 21, 2011 at 05:54:22PM +0100, Lennart Poettering wrote: > The FHS is kinda old these days, and it has been a while since it was > last updated. The LSB added some additional rules on top of it: As long as we keep in mind that we don't follow the LSB at points where it is ridiculous. -- Matthew Miller Senior Systems Architect -- Instructional & Research Computing Services Harvard School of Engineering & Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: rpm-buildroot-usage
The www.coin-or.org server seems to be down, so I have placed a copy of the CppAD spec file at http://www.seanet.com/~bradbell/cppad.spec On 11:59 AM, Michael Schwendt wrote: > On Fri, 21 Jan 2011 10:54:13 -0800, Brad wrote: > ... snip ... >>> Can you upload the spec file to some public place? >>> Without a look at it, it's hard to guess where you use %buildroot. >>> >> I have placed a copy of the current cppad.spec file in >> https://projects.coin-or.org/CppAD/browser/trunk/cppad.spec >> >> ... snip ... > > At the time of writing this mail, Firefox did not succeed in downloading > the spec from above https URL. At most it managed to get to the "connected" > status, but no further. > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20110122 changes
There's just one OCaml package left for the feature, which requires some work upstream: > coccinelle-0.2.5-0.rc1.2.fc15.x86_64 requires ocaml(Osetb) = > 0:8f21a0a4f771662673604ed92a237d79 This package is orphaned: > ocaml-camlimages-3.0.2-2.fc13.x86_64 requires ocaml(Bigarray) = > 0:fc2b6c88ffd318b9f111abe46ba99902 I thought that was all I had to do, but apparently there's something else needed to drop it entirely. That is unless someone wants to take it over: it has some known security issues and upstream is completely unresponsive, so good luck with that. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20110122 changes
> "RWMJ" == Richard W M Jones writes: RWMJ> I thought that was all I had to do, but apparently there's RWMJ> something else needed to drop it entirely. Did you delete all of the files and add a dead.package file? http://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life - J< -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On 01/22/2011 06:22 AM, Matthew Miller wrote: > On Fri, Jan 21, 2011 at 05:54:22PM +0100, Lennart Poettering wrote: >> The FHS is kinda old these days, and it has been a while since it was >> last updated. The LSB added some additional rules on top of it: > > As long as we keep in mind that we don't follow the LSB at points where it > is ridiculous. Give three examples, please. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compiz 0.9 landing in Rawhide
drago01 wrote: > On Thu, Jan 20, 2011 at 1:13 AM, Ben Boeckel wrote: >> In gmane.linux.redhat.fedora.devel Adam Williamson >> wrote: >>> * desktop-effects is deprecated and broken, do not use it: install >>> 'compiz-gnome' and there'll be a 'Classic GNOME with Compiz' choice at >>> the login manager you can use to get a GNOME 2 + Compiz-style desktop >>> (with panel, not Shell) >> >> Hmm. Does this mean that compiz-as-compositor (with, say, xmonad) is no >> longer possible? > > That makes no sense at all, xmonad is a window manager so is compiz > ... you cannot run two at the same time. I saw this[1] a while ago (though it seems comments finally state that it's a patched compiz, so it's probably moot anyway). The xcompmgr tool gets slower on some of my machines as time goes on. Restarting xcompmgr isn't that big of a deal, but it's something I'd like to not have to do. --Ben [1]http://www.youtube.com/watch?v=hxpzNGppcbs -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20110122 changes
On Sat, Jan 22, 2011 at 09:55:34AM -0600, Jason L Tibbitts III wrote: > > "RWMJ" == Richard W M Jones writes: > > RWMJ> I thought that was all I had to do, but apparently there's > RWMJ> something else needed to drop it entirely. > > Did you delete all of the files and add a dead.package file? > > http://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Yes I expect that's it. I'll remove it properly in a little while unless someone picks it up. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm-buildroot-usage
On Sat, 22 Jan 2011 06:42:38 -0800, Brad wrote:
> The www.coin-or.org server seems to be down, so I have placed a copy of
> the CppAD spec file at
> http://www.seanet.com/~bradbell/cppad.spec
Okay, got it. In %prep, you patch the source code to use
includedir=%{buildroot}%{_includedir}
As discussed before in the thread, rpmlint just warns about doing
something with %buildroot prior to the %install section as it may
lead to including broken files in the built packages and may also
break --short-circuit rpmbuilds (see rpmlint's verbose warning
and the rpmbuild manual page). BuildRoot is emptied and recreated
no earlier than in the %install section:
| %install
| rm -rf %{buildroot}
| make install DESTDIR=%{buildroot}
And even if you dropped the "rm -rf ..." there, rpmbuild defaults
to recreating BuildRoot from scratch at the beginning of %install.
You should not use %buildroot earlier than in %install.
If you can verify that the files included in the built noarch package
don't depend on anything related to %buildroot (i.e. neither the path
itself nor any contents deleted prior to %install, you may ignore the
rpmlint warning.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Should I bump cryptopp soname?
Hi, Need help with soname for new libcryptopp build. One of previous cryptopp versions built with disabled SSE2 for x86 because it doesn't built with SSE2. See http://groups.google.com/group/cryptopp-users/browse_thread/thread/d639907b0b1816b9 This was done by adding in config.h line (only for x86) #define CRYPTOPP_DISABLE_SSE2 But negative side of this was conflict when installing both cryptopp-devel i686 x86_64 packages. See bug https://bugzilla.redhat.com/show_bug.cgi?id=645169 config.h is in cryptopp-devel and was used for building other apps (amule and other). Last cryptopp 5.6.1 not needs disabling SSE2 for building on x86 but I can't just build it without patched config.h because amule will crash when using this cryptopp build. If I rebuild amule against new cryptopp build it will not crash. So should I bump libcryptopp soname to .so.7 when building it with enabled SSE2 because of binary incompatibility with .so.6? Soname not set by Crypto++ upstream and was manually added with autotools patch Alexey Kurov -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
/etc/mtab is listed in setup and util-linux
febootstrap doesn't like: febootstrap: error: /etc/mtab is a config file which is listed in two packages (setup-2.8.30-1.fc15.noarch.rpm, util-linux-2.19-0.2.fc15.x86_64.rpm) Is it OK for a %config file to exist in two RPMs? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should I bump cryptopp soname?
No need to bump soname now. Problem fixed by patching config.h both for i686 and x86_64. Thanks Kevin Kofler for patch. Alexey Kurov > Hi, > > Need help with soname for new libcryptopp build. > > One of previous cryptopp versions built with > disabled SSE2 for x86 because it doesn't built with SSE2. > See > http://groups.google.com/group/cryptopp-users/browse_thread/thread/d639907b0b1816b9 > > This was done by adding in config.h line (only for x86) > #define CRYPTOPP_DISABLE_SSE2 > > But negative side of this was conflict when installing > both cryptopp-devel i686 x86_64 packages. > See bug https://bugzilla.redhat.com/show_bug.cgi?id=645169 > > config.h is in cryptopp-devel and was used for building other apps (amule and > other). > > Last cryptopp 5.6.1 not needs disabling SSE2 for building on x86 > but I can't just build it without patched config.h because > amule will crash when using this cryptopp build. > > If I rebuild amule against new cryptopp build it will not crash. > > So should I bump libcryptopp soname to .so.7 when building it > with enabled SSE2 because of binary incompatibility with .so.6? > > Soname not set by Crypto++ upstream and was > manually added with autotools patch > > Alexey Kurov -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updating waf to 1.6
Kevin Fenzi wrote: > On Mon, 17 Jan 2011 09:28:10 +0100 > Thomas Moschny wrote: >> It's not a matter of 'forcing' updates: As I said in my first post, >> waf had, and has incompatible api changes (1.4 -> 1.5 in the bug >> mentioned, and 1.5 -> 1.6 in this thread). Our policies explicitly >> *forbid* to update packages in stable releases of Fedora in such >> cases. > > Yep. Quite right. That's why those new update policies are broken. If such an update is required to build current software, it MUST be pushed, and the other 2 packages using it (it's not like it's half of the distro) patched to build with it if they stopped building. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updating waf to 1.6
Simo Sorce wrote: > As far as I know the waf author himself considers embedding the right > way to go for projetcs. That shows that that upstream is completely wacky and it's idiotic for ANY project to rely on his code! > Samba4 (and soon talloc, tdb tevent, we are building them these days) > do embed their own copyof waf together with project extensions to waf. > > The best thing is to not package waf on and in itself, and let package > embed the right version. At least until waf becomes mature enough that > the rate of change slows down to the point that option 1 becomes > feasible. The best thing is to get those projects to switch to a sane build system (http://www.cmake.org/) which cares about backwards compatibility and doesn't bundle itself nor any generated shell scripts. Failing that, they need to be patched to build with the version of waf we ship, whether it's newer or older than the one upstream uses. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updating waf to 1.6
Toshio Kuratomi wrote: > It's possible that it could be shown to be a copylib: > https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Copylibs That whole CONCEPT of a "copylib" is broken and it's sad that we're making exceptions for those. > But waf does make periodic releases so that might not be the right > exception. If you could draw parallels between the autotools and waf, > that might be a way to look at it. Actually, the right parallel to draw here is to finally start requiring autotools-using projects to run a full autoreconf -i -f in %prep. Generated shell scripts are NOT source code, we should require the stuff to be built from its true source code just as we do for Java JARs, target binaries in cross-compilation tools etc. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compiz 0.9 landing in Rawhide
Adam Williamson wrote: > Configuration from 0.8 does not migrate to 0.9. You'll have to re-do > your configuration. This isn't a consequence of the gconf stuff > mentioned above, it's just an upstream change: for all config storage > backends, there was a clean break from 0.8 to 0.9 and configuration is > not carried over. Ubuntu has some patches which attempt to migrate 0.8 > configs to 0.9, but they're not 100% reliable and add time to each > startup, so they are not likely to be merged upstream, so we won't be > carrying them in Fedora. I'm afraid you'll have to re-do your > configuration with the 0.9 switch, if you have a custom compiz > configuration; sorry about that. I think this is really unhelpful. If Ubuntu has patches to migrate configuration automatically, we should ship them. It's really rude to force users to reconfigure everything when they upgrade to a new Fedora just because upstream couldn't be bothered to migrate settings properly (and I hate upstreams doing that). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Removing -fexceptions from $RPM_OPT_FLAGS
Tom Lane wrote: > Hmm ... so what should I do with mysql? Since approximately forever, > upstream has recommended using -fno-exceptions (and also > -felide-constructors -fno-rtti) in CXXFLAGS. I now realize that it's > a bit silly to do that when the plain-C files (of which there are > plenty) are being built with -fexceptions because of Fedora's standard > RPM_OPT_FLAGS. I also note that the recommendation to do that seems to > have disappeared from their manual as of mysql 5.5 ... although their > own RPM specfile is still doing it. > > Seems like I should either drop the nonstandard CXXFLAGS, or hack CFLAGS > to remove -fexceptions. FWIW, exactly the same thing is happening in all of KDE, and everything building against kdelibs-devel using CMake (unless the package adds the KDE4_ENABLE_EXCEPTIONS macro to its compiler flags). FindKDE4Internal.cmake sets -fno-exceptions for C++, but not for C, so -fexceptions gets set for C files and -fno-exceptions for C++ files. We may want to drop the "-fno-exceptions -DQT_NO_EXCEPTIONS" from the default CMAKE_CXX_FLAGS (or maybe add -fno-exceptions to the CMAKE_C_FLAGS). (Qt is already built with exception support these days because QtWebKit requires it. qt3/kdelibs3 is yet another can of worms, of course.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [dokuwiki/el5/master] - Upgrade to latest upstream - large patches in git
Kevin Fenzi wrote: > Well, according to our guidelines: > > https://fedoraproject.org/wiki/Packaging/Treatment_Of_Bundled_Libraries > > They should just remove the bundled libs in %prep: > > "Bundled libraries (and/or their source code) must be explicitly > deleted during %prep." > > So, could you file a bug against this package and ask them to drop the > patch and instead delete the bundled libs in prep. > > Thanks. Well, a patch may be needed to disable the usage of the bundled code in makefiles and such. But yes, the actual removal of the bundled code should be done by a rm -rf in %prep and not by a patch bundling yet another copy of the huge library with prepended - signs. ;-) The patch should not contain file or directory removals. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
