Re: Heads-Up: Beware of xmlCleanupParser() when your package links against libxml2
On 01/13/2010 09:07 AM, Tom Lane wrote: > Lennart Poettering writes: >> if you have code that links against libxml2 and calls >> xmlCleanupParser() please verify that your project does that at the >> appropriate place (i.e. immediately before exiting, and only once). > > Why exactly is this a misuse, and not libxml2's bug to fix? There's > certainly nothing in their documentation suggesting that there's > such a requirement. libxml2 also doesn't use pthreads Thread Specific Keys correctly either which can lead to segv if the library is unloaded prior to the threaded application exiting. Ian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-Up: Beware of xmlCleanupParser() when your package links against libxml2
On Wed, 2010-01-13 at 03:54 +0100, Lennart Poettering wrote: > Oh, and we definitely need a source code indexer for fedora too! It's coming. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
> I have problems to understand the xmlrpc-c build failure > > | /usr/bin/ld.bfd: xml-rpc-api2cpp.5842.test: undefined reference to symbol > 'pthread_cancel@@GLIBC_2.2.5' > > pthread_cancel() is not used by the program. I see it in the .plt section > only but not where it is referenced. > > I would like to avoid blind '-lpthread' flags without knowing why they > are required. You are right to ask and not do blind changes! Thanks for checking this. You should not add any -lpthread if you don't really use pthread_cancel yourself. This is biting libstdc++ users and we think it's an ld bug, so we'll try to get that fixed. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
> 78 of those seem to be caused by separated libtinfo. In default > ncurses configuration libtinfo is included in libncurses, so I don't > think the upstreams will be very happy about adding support for > non-standard configurations. > > Petr Machata suggested we could work around it by replacing > libncurses.so and libncursesw.so symlinks with linker scripts > including both libraries. > > Is that acceptable? Yes, that's the right thing to do in this sort of case. If as the maintainer of the -devel package providing -lncurses, you are saying you want -lncurses to go along with an API that is actually provided in more than one DSO, then that is your choice. You've decided that you want your API to map to an ABI in a non-default way, which is fine when you think it makes sense for your case. The way you implement this is to make libncurses.so a plain text file that looks like (modulo indentation): # Your comment here. AS_NEEDED ( libncurses.so.5 libtinfo.so.5 ) Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
> According to notting and the experimentation that I did after the FESCo > meeting, the shared libraries bring in any libraries that they depend on. > However, if the application linking to the shared library also requires the > third shared library but doesn't explicitly link it then the link will fail. That's right. > ie: > > Given: > libfoo requires libbar. > This is used to link: gcc -o libfoo.so -lbar foo.o > libfoo.so contains the dependency on libbar. > > Scenario 1: > /usr/bin/baz depends on symbols in libfoo but not libbar. > This can be used to link: gcc -o baz -lfoo baz.o > The link succeeds and the resulting /usr/bin/baz links to both libfoo.so and > libbar.so as expected. > > Scenario 2: > /usr/bin/baz depends on symbols in both libfoo and llibbar > This fails to link because of missing libbar: gcc -o baz -lfoo baz.o > This succeeds: gcc -o baz -lfoo -lbar baz.o > > Roland, can you clarify that this is indeed how things are supposed to work? Yes, that's correct. A common example seems to be -lm. If you use 'pow' (or whatever), then you should pass -lm. If some other library you use happens to use -lm at the moment, that doesn't mean you shouldn't pass -lm when you are using some API symbols from -lm. > Also... it took me quite a while to come up with the command line flags on > F12 that would allow me to test this (I think I had to get gcc to show me > the linker invokation it used and then run those linker lines with my > modifications), can you tell us what command line flags let us test out the > differences in behaviour on F12? You can always pass extra linker flags through gcc with -Wl,--foo. You can give as many of these as you like, and -Wl,a,b is the same as -Wl,a -Wl,b (both mean to pass "a" and "b" arguments on to ld). On F12 (or F11) you can use 'gcc -Wl,--no-add-needed' to get the new linking semantics. e.g., .../configure LDFLAGS=-Wl,--no-add-needed probably works on many packages if you want to try a manual build of something this way. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-Up: Beware of xmlCleanupParser() when your package links against libxml2
On Wed, 13.01.10 00:21, Lennart Poettering (mzerq...@0pointer.de) wrote: > Heya! > > if you have code that links against libxml2 and calls > xmlCleanupParser() please verify that your project does that at the > appropriate place (i.e. immediately before exiting, and only once). > > That function might delete TLS fields that belong to other libraries > (such as PA's client libs) if called twice. To the effect that PA > might look bad. And I don't like that. > > So, please: if you have a library linking against libxml2, verify that > xmlCleanupParser() is called at the appropriate places and only once. > > For now at least Empathy and Abiword are calling this function where > they shouldn't, but a google code search reveals that at least > inkscape and dia do it too. I stopped looking after that, > extrapolating that this means "everyone is doing this worng". Hence > this mail. The Debian folks have their entire source tree indexed and have this search engine for symbols: http://source.debian.net/source/search?n=25&start=0&q=xmlCleanupParser I figure our package set is not that different from theirs, so you might want to have a look on the list of packages that uses that function call. Already on the first page of that output there's fwbuilder, a PAM module and more misusing that function. Oh, and we definitely need a source code indexer for fedora too! Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-Up: Beware of xmlCleanupParser() when your package links against libxml2
On Tue, 12.01.10 20:07, Tom Lane (t...@redhat.com) wrote: > > Lennart Poettering writes: > > if you have code that links against libxml2 and calls > > xmlCleanupParser() please verify that your project does that at the > > appropriate place (i.e. immediately before exiting, and only once). > > Why exactly is this a misuse, and not libxml2's bug to fix? There's > certainly nothing in their documentation suggesting that there's > such a requirement. http://xmlsoft.org/html/libxml-parser.html#xmlCleanupParser Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Outage Notification - 2010-01-13 22:00 UTC
There will be an outage starting at 2010-01-13 22:00 UTC, which will last approximately 4 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2010-01-13 22:00 UTC' Affected Services: Fedora Hosted Unaffected Services: Buildsystem CVS / Source Control Database DNS Fedora People Fedora Talk Mail Mirror System Torrent Translation Services Websites Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/1926 Reason for Outage: hosted1.fedoraproject.org (the primary fedorahosted host) has been throwing memory errors so we have a ticket open to fix it. There is a 4 hour window for them to work on it though it's not likely to be down that whole time so the actual outage should be much smaller. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-Up: Beware of xmlCleanupParser() when your package links against libxml2
Le 13/01/2010 02:07, Tom Lane a écrit : > > Why exactly is this a misuse, and not libxml2's bug to fix? There's > certainly nothing in their documentation suggesting that there's > such a requirement. > > regards, tom lane Afaik it does, i agree with Lennart that a warning from libxml2 would be welcome. => extracted from xmlCleanupParser() documentation WARNING: if your application is multithreaded or has plugin support calling this may crash the application if another thread or a plugin is still using libxml2. It's sometimes very hard to guess if libxml2 is in use in the application, some libraries or plugins may use it without notice. In case of doubt abstain from calling this function or do it just before calling exit() to avoid leak reports from valgrind H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-Up: Beware of xmlCleanupParser() when your package links against libxml2
Lennart Poettering writes: > if you have code that links against libxml2 and calls > xmlCleanupParser() please verify that your project does that at the > appropriate place (i.e. immediately before exiting, and only once). Why exactly is this a misuse, and not libxml2's bug to fix? There's certainly nothing in their documentation suggesting that there's such a requirement. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
On Wed, 2010-01-13 at 00:06 +, Adam Williamson wrote: > > if so, Mandriva has been enforcing the fixing of this type of error for > a couple of years now (by having --as-needed and --no-undefined in the > default ld flags). This has a few implications: --as-needed is actually kinda the opposite. It counteracts careless overlinking. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: Allow modrdn to move subtree and rename non-leaf node
Allow modrdn to move subtree and rename non-leaf node This patch includes - replacing the entrydn index with the entryrdn index - replacing a full DN in each entry in the DB with an RDN - extending Slapi_Entry, entry2str, and str2entry to absorb the changes made on the entry - adding DN/RDN helper functions - adding DN cache - adding a utility and a migration script to convert the DN format database to the RDN format - extending a database dump utility dbscan to support the entryrdn In addition to the above, compile warnings and memory leaks found in testing the new feature are fixed. For more details, see the feature design document at: http://directory.fedoraproject.org/wiki/Subtree_Rename The patch is too big to attach to the email. It is located here: http://nhosoi.fedorapeople.org/0001-Allow-modrdn-to-move-subtree-and-rename-non-leaf-nod.patch Thanks, --noriko smime.p7s Description: S/MIME Cryptographic Signature -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Change to DSO-linking semantics of the compiler
On Wednesday 13 January 2010, Adam Williamson wrote: > On Tue, 2010-01-12 at 01:59 +0100, Milos Jakubicek wrote: > > Also I have really doubts what concerns upstreamability of the necessary > > changes in packages. Especially if other distributions will (???) > > continue shipping ld with the traditional semantics, this means hours of > > headache discussions with upstream not willing to accept the patch. > > I may be misunderstanding, but I believe this is the same thing Mandriva > refers to as underlinking: > > http://wiki.mandriva.com/en/Underlinking No, it's not the same thing: Consider an executable a, a library libb.so and a library libc.so, and a is linked against -lb: * underlinking is if libb.so uses symbols from libc.so, but does not link against -lc. Then you have to link a explicitly against -lb -lc even if it only uses symbols from libb.so. This is a bug in libb.so. * what is being discussed here is if libb.so DOES link libc.so, but now executable a uses symbols from libc.so without also using -lc. If libb shipped a libb.la file which did -lb -lc (which .la files tend to do), then a will link file everywhere else, just not on Fedora because we delete .la files. The old semantics made this case work without the .la file, the new semantics lead to programs failing to link in Fedora, making Fedora incompatible with upstream (unless we start to ship .la files again). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
On Wed, 2010-01-13 at 01:52 +0100, Kevin Kofler wrote: > On Wednesday 13 January 2010, Adam Williamson wrote: > > On Tue, 2010-01-12 at 01:59 +0100, Milos Jakubicek wrote: > > > Also I have really doubts what concerns upstreamability of the necessary > > > changes in packages. Especially if other distributions will (???) > > > continue shipping ld with the traditional semantics, this means hours of > > > headache discussions with upstream not willing to accept the patch. > > > > I may be misunderstanding, but I believe this is the same thing Mandriva > > refers to as underlinking: > > > > http://wiki.mandriva.com/en/Underlinking > > No, it's not the same thing: Consider an executable a, a library libb.so and > a > library libc.so, and a is linked against -lb: > * underlinking is if libb.so uses symbols from libc.so, but does not link > against -lc. Then you have to link a explicitly against -lb -lc even if it > only uses symbols from libb.so. This is a bug in libb.so. > * what is being discussed here is if libb.so DOES link libc.so, but now > executable a uses symbols from libc.so without also using -lc. If libb > shipped > a libb.la file which did -lb -lc (which .la files tend to do), then a will > link > file everywhere else, just not on Fedora because we delete .la files. The old > semantics made this case work without the .la file, the new semantics lead to > programs failing to link in Fedora, making Fedora incompatible with upstream > (unless we start to ship .la files again). .pc files handle this just fine. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
On Wednesday 13 January 2010, Adam Williamson wrote: > On Tue, 2010-01-12 at 01:59 +0100, Milos Jakubicek wrote: > > Also I have really doubts what concerns upstreamability of the necessary > > changes in packages. Especially if other distributions will (???) > > continue shipping ld with the traditional semantics, this means hours of > > headache discussions with upstream not willing to accept the patch. > > I may be misunderstanding, but I believe this is the same thing Mandriva > refers to as underlinking: > > http://wiki.mandriva.com/en/Underlinking No, it's not the same thing: Consider an executable a, a library libb.so and a library libc.so, and a is linked against -lb: * underlinking is if libb.so uses symbols from libc.so, but does not link against -lc. Then you have to link a explicitly against -lb -lc even if it only uses symbols from libb.so. This is a bug in libb.so. * what is being discussed here is if libb.so DOES link libc.so, but now executable a uses symbols from libc.so without also using -lc. If libb shipped a libb.la file which did -lb -lc (which .la files tend to do), then a will link file everywhere else, just not on Fedora because we delete .la files. The old semantics made this case work without the .la file, the new semantics lead to programs failing to link in Fedora, making Fedora incompatible with upstream (unless we start to ship .la files again). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
On Tue, 2010-01-12 at 01:59 +0100, Milos Jakubicek wrote: > Also I have really doubts what concerns upstreamability of the necessary > changes in packages. Especially if other distributions will (???) > continue shipping ld with the traditional semantics, this means hours of > headache discussions with upstream not willing to accept the patch. I may be misunderstanding, but I believe this is the same thing Mandriva refers to as underlinking: http://wiki.mandriva.com/en/Underlinking if so, Mandriva has been enforcing the fixing of this type of error for a couple of years now (by having --as-needed and --no-undefined in the default ld flags). This has a few implications: a) yes, it clearly is practical to maintain a distro this way b) in many cases where a Fedora package has this problem, it'll be possible to take a patch from Mandriva c) some upstreams will be used to dealing with this, since it's been brought up by Mandriva I did upstream several underlinking patches I wrote while maintaining Mandriva packages; I didn't have any problems getting upstreams to accept them. If they weren't already aware of why it was a good idea to fix underlinking issues, they always understood after being pointed to the Mandriva Wiki page. I believe Debian's checking scripts also note underlinking issues as a 'warning'-type thing (i.e. they notify the packager and suggest it should be fixed, but don't fail the build). IMBW on that one, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bugzilla borked right now (2010-01-12)?
James Ralston writes: > 1. Is Bugzilla having problems right now? Seems to be working for me ... regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Heads-Up: Beware of xmlCleanupParser() when your package links against libxml2
Heya! if you have code that links against libxml2 and calls xmlCleanupParser() please verify that your project does that at the appropriate place (i.e. immediately before exiting, and only once). That function might delete TLS fields that belong to other libraries (such as PA's client libs) if called twice. To the effect that PA might look bad. And I don't like that. So, please: if you have a library linking against libxml2, verify that xmlCleanupParser() is called at the appropriate places and only once. For now at least Empathy and Abiword are calling this function where they shouldn't, but a google code search reveals that at least inkscape and dia do it too. I stopped looking after that, extrapolating that this means "everyone is doing this worng". Hence this mail. For more information see: https://bugzilla.redhat.com/show_bug.cgi?id=554903 http://git.gnome.org/browse/libxml2/tree/parser.c#n14002 I also asked that libxml2 warns directly about this misuse: https://bugzilla.redhat.com/show_bug.cgi?id=554903 Thanks to Michal Schmidt for tracking this down. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpms/seabios/F-12 seabios-0.5.1-669c991.tar.gz, NONE, 1.1 seabios.spec, NONE, 1.1
On Tue, Jan 12, 2010 at 10:18:53AM -0700, Kevin Fenzi wrote: > > Please don't check tar.gz files into CVS. :) > > you will need to: > > cvs rm -f seabios-0.5.1-669c991.tar.gz > cvs commit > make new-sources FILES="seabios-0.5.1-669c991.tar.gz" > bump release/add changelog to spec > cvs commit sources .cvsignore seabios.spec > > See: > https://fedoraproject.org/wiki/Package_update_HOWTO > https://fedoraproject.org/wiki/Using_CVS_FAQ_for_package_maintainers > https://fedoraproject.org/wiki/Package_update_guidelines > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Import_Your_Package Sorry about that, I was under the impression that was only for URLed tarballs, and included it because this was a git snapshot. I will move it to the lookaside and drop it from CVS on the next update. Justin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Bugzilla borked right now (2010-01-12)?
At around 2010-01-12T12:45-0500, I attempted to login with my correct username/password, and was told my username/password was incorrect. I changed my password using the "forgot password" link. Bugzilla won't take the new password, either. I tried to search for Bugzilla admin contact information in the Red Hat Bugzilla User's Guide, linked from the main page: https://bugzilla.redhat.com/docs/en/html/using.html The User's Guide returns a 403 HTTP/1.x 403 Forbidden error. Wait, check that: it only returns 403 Forbidden about 50% of the time. My questions: 1. Is Bugzilla having problems right now? 2. If so, is anyone working on it? 3. Other than posting here, what mechanisms are available for reporting problems with Bugzilla if you can't actually login to Bugzilla? If there is a preferred mechanism, what is it? Thanks... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 'make lint' bug with noarch package
On Tue, 2010-01-12 at 15:58 +, Richard W.M. Jones wrote: > $ make lint > rpmlint mingw32-freetype-2.3.11-1.fc13.src.rpm > x86_64/*-2.3.11-1.fc13.x86_64.rpm > (none): E: error while reading x86_64/*-2.3.11-1.fc13.x86_64.rpm: > 'x86_64/*-2.3.11-1.fc13.x86_64.rpm' > 1 packages and 0 specfiles checked; 0 errors, 0 warnings. > > This package is noarch, so it shouldn't be looking in the x86_64 > directory. > > Rich. I noticed this bug when I ported it over to fedpkg. Make lint also still assumes that a package will only have one arch output, instead of the possible arch + noarch sets. I've fixed these two problems in fedpkg, but I'm not really putting time into Makefile.common. I was surprised nobody had found this yet, I assumed it was a little used target. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpms/seabios/F-12 seabios-0.5.1-669c991.tar.gz, NONE, 1.1 seabios.spec, NONE, 1.1
On Tue, 12 Jan 2010 06:50:16 + (UTC) "Justin M. Forbes" wrote: > Author: jforbes > > Update of /cvs/pkgs/rpms/seabios/F-12 > In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv15649 > > Added Files: > seabios-0.5.1-669c991.tar.gz seabios.spec > Log Message: > Created initial package > > > --- NEW FILE seabios-0.5.1-669c991.tar.gz --- > ÙÿmÈQ¯Kío~ > æQ2£lݸÏõÿ/½¢ÿÉèxôõq ½ôz·þ÷¬þ`oô¿×Û³¾!½¯OJýú®ÿÓ9¹ 'Äc$¡É*ì4y Please don't check tar.gz files into CVS. :) you will need to: cvs rm -f seabios-0.5.1-669c991.tar.gz cvs commit make new-sources FILES="seabios-0.5.1-669c991.tar.gz" bump release/add changelog to spec cvs commit sources .cvsignore seabios.spec See: https://fedoraproject.org/wiki/Package_update_HOWTO https://fedoraproject.org/wiki/Using_CVS_FAQ_for_package_maintainers https://fedoraproject.org/wiki/Package_update_guidelines https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Import_Your_Package signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Sources file audit - 2010-01-06
On Tue, Jan 12, 2010 at 04:21:08PM +, Richard W.M. Jones wrote:
> On Sun, Jan 10, 2010 at 12:06:11AM -0700, Kevin Fenzi wrote:
> > rjones:BADURL:expat-2.0.1.tar.gz:mingw32-expat
> > rjones:BADURL:mingwrt-3.15.2-mingw32-src.tar.gz:mingw32-runtime
> > rjones:BADURL:PDCurses-3.4.tar.gz:mingw32-pdcurses
> > rjones:BADURL:w32api-3.13-mingw32-src.tar.gz:mingw32-w32api
> > rjones:BADURL:watchdog-5.5.tar.gz:watchdog
>
> Sourceforge seems to have changed the format of their download URLs
> once again. The source url for the first one is:
>
> http://download.sourceforge.net/expat/expat-%{version}.tar.gz
^- here is an "s" missing.
>
> which corresponds with the advice given here (and obviously this
> worked previously).
>
> https://fedoraproject.org/wiki/Packaging:SourceURL
>
> But the above link no longer works, and the new URL is this:
>
> http://downloads.sourceforge.net/project/expat/expat/2.0.1/expat-2.0.1.tar.gz
>
> What's the current thinking on SF URLs? Perhaps we should have an RPM
> macro/feature to hide this hideousness?
The recommended and still working URL is this:
http://downloads.sourceforge.net/expat/expat-2.0.1.tar.gz
^
You used the wrong hostname previously. Maybe an admonition should be
added to the SourceURL guidelines to emphasize that there hostname
contains an extra "s".
Regards
Till
pgp7s3Op3Wn5T.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Sources file audit - 2010-01-06
On Sun, Jan 10, 2010 at 12:06:11AM -0700, Kevin Fenzi wrote:
> rjones:BADURL:expat-2.0.1.tar.gz:mingw32-expat
> rjones:BADURL:mingwrt-3.15.2-mingw32-src.tar.gz:mingw32-runtime
> rjones:BADURL:PDCurses-3.4.tar.gz:mingw32-pdcurses
> rjones:BADURL:w32api-3.13-mingw32-src.tar.gz:mingw32-w32api
> rjones:BADURL:watchdog-5.5.tar.gz:watchdog
Sourceforge seems to have changed the format of their download URLs
once again. The source url for the first one is:
http://download.sourceforge.net/expat/expat-%{version}.tar.gz
which corresponds with the advice given here (and obviously this
worked previously).
https://fedoraproject.org/wiki/Packaging:SourceURL
But the above link no longer works, and the new URL is this:
http://downloads.sourceforge.net/project/expat/expat/2.0.1/expat-2.0.1.tar.gz
What's the current thinking on SF URLs? Perhaps we should have an RPM
macro/feature to hide this hideousness?
> rjones:BADURL:camlimages-3.0.1.tar.gz:ocaml-camlimages
Fixed by rebasing to new upstream version 3.0.2.
> rjones:BADURL:coccinelle-0.1.10.tgz:coccinelle
Fixed by rebasing to new upstream version 0.2.0rc1.
> rjones:BADURL:freetype-2.3.8.tar.bz2:mingw32-freetype
> rjones:BADURL:freetype-doc-2.3.8.tar.bz2:mingw32-freetype
Upstream moved. Fixed by rebasing to 2.3.11.
> rjones:BADURL:libpng-1.2.40.tar.bz2:mingw32-libpng
Annoyingly tricky to fix. Anyone in fedora-mingw SIG want to help?
> rjones:BADURL:ocaml-autoconf-1.1.tar.gz:ocaml-autoconf
This seems OK to me, but it's an HTTPS URL with a self-signed
certificate, and I seem to remember those caused problems for spectool
in the past.
> rjones:BADURL:ocamlp3l-2.03.tgz:ocaml-p3l
Fixed.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Pulseaudio update issue... [ UPDATE 2 ]
On Tue, Jan 12, 2010 at 10:07:37AM +0100, Nicolas Mailhot wrote: > > > Le Mar 12 janvier 2010 09:29, Richard Zidlicky a écrit : > > > > On Mon, Jan 11, 2010 at 04:10:54PM -0800, Wes Hardaker wrote: > > > >> I didn't see anything in that message, however, that lead me to any new > >> thoughts on what I should test. I don't have any kernel circular > >> looping reports like the one shown in the message above. > > > > this needs to be enabled at kernel compile time, not sure if it is done > > in the stock kernel.. somewhere under kernel debugging. > > I had the warning for months (if not years) and reported it both in kernel.org > bugzilla and fedora pulseaudio bugzilla. > > I've not seen any activity trying to fix this bug. > > Is this a case were everyone is waiting for someone else to investigate ? it seems even investigated to some degree, just not taken very seriously. http://lkml.org/lkml/2009/12/7/524 http://lkml.org/lkml/2009/12/8/124 But maybe it is more serious than that? My suspicion is that it crashed compiz and hanged a few other apps, can anyone else confirm that such things are directly related to this bug? Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
KDE-SIG weekly report (2/2010)
This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. -- = Weekly KDE Summary = Week: 2/2010 Time: 2010-01-12 14:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-01-12 Meeting minutes: http://meetbot.fedoraproject.org/fedora- meeting/2010-01-12/kde-sig.2010-01-12-14.02.html Meeting log: http://meetbot.fedoraproject.org/fedora-meeting/2010-01-12/kde- sig.2010-01-12-14.02.log.html -- = Participants = * Jaroslav Reznik * Kevin Kofler * Lukas Tinkl * Rex Dieter * Sebastian Vahl * Steven Parrish * Than Ngo * Thomas Janssen * Mary Ellen Foster -- = Agenda = * kde-l10n srpm split * plasma-netbook tracker * re-test enabling qt/webkit jit * recent bugs: o #554713: Only "Internal audio analog stereo" present after login [1] = Summary = kde-l10n srpm split * Than proposed %subject% - split current one big srpm to many packages * pros/cons o pros are more flexible and smaller updates, build of current srpm is time consuming in case of buggy kde-l10n package o cons - koji/bodhi overhead/more packages, has to be scripted * Rex Dieter is going to revive/work on his script/template * FKDESCo agreed on this conditionally o automation script is ready and usable plasma-netbook * jreznik, svahl and mefoster are willing to lead Plasma Netbook effort * step #1 - create a separate comps group for kde-netbook, then probably spin * intelligent cherry picking of packages to be on (and needs split/reorganization) o kdeplasma-addons needed, problem due to kdeedu-marble * tracker [2] qtwebkit JIT [3] * SELinux issue, currently off o reported for both 4.5 & 4.6 o i386 only (JIT is not enabled for x86_64) o we need retesting, poke upstream recent bugs Only "Internal audio analog stereo" present after login * more info needed -- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-01-19 -- = Links = [1] https://bugzilla.redhat.com/show_bug.cgi?id=554713 [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=549746 [3] https://bugzilla.redhat.com/show_bug.cgi?id=549994 = Comment = Sorry for missing last meeting summary, my fault ;-) Jaroslav -- Jaroslav Řezník Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
'make lint' bug with noarch package
$ make lint rpmlint mingw32-freetype-2.3.11-1.fc13.src.rpm x86_64/*-2.3.11-1.fc13.x86_64.rpm (none): E: error while reading x86_64/*-2.3.11-1.fc13.x86_64.rpm: 'x86_64/*-2.3.11-1.fc13.x86_64.rpm' 1 packages and 0 specfiles checked; 0 errors, 0 warnings. This package is noarch, so it shouldn't be looking in the x86_64 directory. 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: Change to DSO-linking semantics of the compiler
>> SystemTap is failing on pthread_cancel, which is odd since we have no >> mention of pthread in our own sources. It seems to be pulled in by some >> headers in the STL. >> $ nm -C string.o >> w pthread_cancel >> So it seems that now I have to know what my dependent libraries are >> linking to, which I thought was exactly what we were trying to eliminate >> with these new linking semantics. > The weak undefined reference does need to be associated with the real > definition to some degree, in that it uses that symbol version assocation. No, a weak reference that is undefined (within the module that contains the reference) must not be associated with any symbol version at all. An undefined weak reference says "I am satisfied with whatever any other module supplies, else 0 (NULL)." This willingness to tolerate uncertainty, and to delay resolution, must extend all the way to runtime. As a matter of historical interest, then static linking (/usr/bin/ld) might record a symbol version for an undefined weak reference. The history is, "this is how it could have been resolved at static linking." But any recorded symbol version for an undefined weak reference must be ignored by dynamic linking, precisely to enable the independent interchanging of other modules (DSO) at runtime. > But clearly the mere presence of a weak reference should never trigger any > kind of "undefined reference" error. > >> 75 of the failed packages have an undefined reference to pthread_cancel, >> probably for the same reason as above. > > We'll fix the toolchain and/or libstdc++ as needed for this. > Those packages should not need a change just because of this issue. Right. binutils and glibc/rtld have been poorly prepared for this change. The mass rebuild and discussion of the impact of weak undefined references should have been six weeks ago at the start of development for Fedora 13. If not fixed before January 20, one week before alpha, then the change should be removed from Fedora 13. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100112 changes
Compose started at Tue Jan 12 08:15:06 UTC 2010 Broken deps for i386 -- DeviceKit-disks-009-3.fc12.i686 requires libparted-1.9.so.0 PyKDE-3.16.6-1.fc13.i686 requires sip-api(6) >= 0:6.0 anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 cduce-0.5.3-3.fc13.i686 requires ocaml(runtime) = 0:3.11.1 cduce-0.5.3-3.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 cduce-0.5.3-3.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 cduce-0.5.3-3.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-0.5.3-3.fc13.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 cduce-0.5.3-3.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(runtime) = 0:3.11.1 cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc-network-devel = 0:2.2.1.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-network-doc = 0:2.2.1.4 ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-network-prof = 0:2.2.1.4 ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc-network-devel = 0:2.2.1.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc-HTTP-devel = 0:4000.0.6 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc-OpenGL-devel = 0:2.2.1.1 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc-zlib-devel = 0:0.5.0.0 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc-GLUT-devel = 0:2.1.1.2 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc
Re: soname changing parted heading for rawhide
On Mon, Jan 11, 2010 at 08:19:58PM +0100, Hans de Goede wrote: > Hi, > > Today I've rebased parted to parted-2.1, this means that the libparted > soname has changed, and all libparted using packages need to be rebuild: > > [h...@localhost ~]$ sudo repoquery -q --whatrequires > 'libparted-1.9.so.0()(64bit)' > qtparted-0:0.4.5-22.fc12.x86_64 > DeviceKit-disks-0:009-3.fc12.x86_64 (now udisks) > gparted-0:0.4.8-1.fc12.x86_64 > kde-partitionmanager-0:1.0.0-2.fc12.x86_64 > libvirt-0:0.7.1-15.fc12.x86_64 I hope this was just a mistaken query and you are only rebasing parted in rawhide, and not in F12. In any case I've rebuilt the libvirt-0.7.5-1.fc13 RPM that is in rawhide against new parted. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: cduce
cduce has broken dependencies in the development tree: On x86_64: cduce-0.5.3-3.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 cduce-0.5.3-3.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 cduce-0.5.3-3.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 cduce-0.5.3-3.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-0.5.3-3.fc13.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 cduce-0.5.3-3.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 On i386: cduce-0.5.3-3.fc13.i686 requires ocaml(runtime) = 0:3.11.1 cduce-0.5.3-3.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 cduce-0.5.3-3.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 cduce-0.5.3-3.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-0.5.3-3.fc13.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 cduce-0.5.3-3.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 On x86_64: cduce-ocamlduce-0.5.3-3.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-ocamlduce-0.5.3-3.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 cduce-ocamlduce-0.5.3-3.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 cduce-ocamlduce-0.5.3-3.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 On i386: cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(runtime) = 0:3.11.1 cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 Please resolve this as soon as possible. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
rpms/ocaml-gettext/devel ocaml-gettext.spec,1.14,1.15
Author: rjones
Update of /cvs/pkgs/rpms/ocaml-gettext/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv25812
Modified Files:
ocaml-gettext.spec
Log Message:
Remove BR ocaml-camlidl. No longer required to build this.
Index: ocaml-gettext.spec
===
RCS file: /cvs/pkgs/rpms/ocaml-gettext/devel/ocaml-gettext.spec,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -p -r1.14 -r1.15
--- ocaml-gettext.spec 30 Dec 2009 13:49:45 - 1.14
+++ ocaml-gettext.spec 11 Jan 2010 15:11:08 - 1.15
@@ -3,7 +3,7 @@
Name: ocaml-gettext
Version:0.3.3
-Release:2%{?dist}
+Release:3%{?dist}
Summary:OCaml library for i18n
Group: Development/Libraries
@@ -18,7 +18,6 @@ BuildRequires: ocaml-findlib-devel >= 1
BuildRequires: ocaml-ocamldoc
BuildRequires: ocaml-camlp4-devel
BuildRequires: ocaml-fileutils-devel >= 0.4.0
-BuildRequires: ocaml-camlidl-devel
BuildRequires: ocaml-ounit-devel
BuildRequires: docbook-style-xsl
BuildRequires: libxslt
@@ -219,6 +218,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Mon Jan 11 2010 Richard W.M. Jones - 0.3.3-3
+- Remove BR ocaml-camlidl. No longer required to build this.
+
* Wed Dec 30 2009 Richard W.M. Jones - 0.3.3-2
- Rebuild for OCaml 3.11.2.
___
ocaml-devel mailing list
ocaml-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
rpms/ocaml-postgresql/devel ocaml-postgresql.spec,1.19,1.20
Author: rjones
Update of /cvs/pkgs/rpms/ocaml-postgresql/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv31492
Modified Files:
ocaml-postgresql.spec
Log Message:
* Mon Jan 11 2010 Richard W.M. Jones - 1.12.3-3
- Ignore bogus thread module Provides which the automatic dependency
generator was giving us.
- Replace %%define with %%global.
- Use upstream RPM 4.8 OCaml internal dependency generator.
Index: ocaml-postgresql.spec
===
RCS file: /cvs/pkgs/rpms/ocaml-postgresql/devel/ocaml-postgresql.spec,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -p -r1.19 -r1.20
--- ocaml-postgresql.spec 30 Dec 2009 13:52:33 - 1.19
+++ ocaml-postgresql.spec 11 Jan 2010 17:48:00 - 1.20
@@ -1,9 +1,9 @@
-%define opt %(test -x %{_bindir}/ocamlopt && echo 1 || echo 0)
-%define debug_package %{nil}
+%global opt %(test -x %{_bindir}/ocamlopt && echo 1 || echo 0)
+%global debug_package %{nil}
Name: ocaml-postgresql
Version:1.12.3
-Release:2%{?dist}
+Release:3%{?dist}
Summary:OCaml library for accessing PostgreSQL databases
Group: Development/Libraries
@@ -20,9 +20,7 @@ BuildRequires: postgresql-devel
BuildRequires: chrpath
BuildRequires: rpm >= 4.4.2.3-2
-%define _use_internal_dependency_generator 0
-%define __find_requires /usr/lib/rpm/ocaml-find-requires.sh
-%define __find_provides /usr/lib/rpm/ocaml-find-provides.sh
+%global __ocaml_provides_opts -i Condition -i Event -i Mutex -i Thread -i
ThreadUnix
%description
@@ -92,6 +90,12 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Mon Jan 11 2010 Richard W.M. Jones - 1.12.3-3
+- Ignore bogus thread module Provides which the automatic dependency
+ generator was giving us.
+- Replace %%define with %%global.
+- Use upstream RPM 4.8 OCaml internal dependency generator.
+
* Wed Dec 30 2009 Richard W.M. Jones - 1.12.3-2
- Rebuild for OCaml 3.11.2.
___
ocaml-devel mailing list
ocaml-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Broken dependencies: why
why has broken dependencies in the development tree: On x86_64: why-2.23-1.fc13.x86_64 requires ocaml(Logic_decl) = 0:f63f0d96a92a779b9e74fc74cfc2423d why-2.23-1.fc13.x86_64 requires ocaml(Ptree) = 0:dfb73bbb000b55e87b05c0cdc2c87af6 why-2.23-1.fc13.x86_64 requires ocaml(Logic) = 0:ddd0d46a3eaa2ce4a1a3d22195514e56 why-2.23-1.fc13.x86_64 requires ocaml(Cc) = 0:7017e5b498afc612807d5f6fdc2fc257 why-2.23-1.fc13.x86_64 requires ocaml(Error) = 0:808ba08d6066ba67d6c769798e909ff8 why-2.23-1.fc13.x86_64 requires ocaml(Ast) = 0:2c019415b117907d730a302cdac2b248 why-2.23-1.fc13.x86_64 requires ocaml(Types) = 0:c36604dc5d4202662cfca61be96c3303 On i386: why-2.23-1.fc13.i686 requires ocaml(Types) = 0:c36604dc5d4202662cfca61be96c3303 why-2.23-1.fc13.i686 requires ocaml(Logic_decl) = 0:f63f0d96a92a779b9e74fc74cfc2423d why-2.23-1.fc13.i686 requires ocaml(Logic) = 0:ddd0d46a3eaa2ce4a1a3d22195514e56 why-2.23-1.fc13.i686 requires ocaml(Cc) = 0:7017e5b498afc612807d5f6fdc2fc257 why-2.23-1.fc13.i686 requires ocaml(Error) = 0:808ba08d6066ba67d6c769798e909ff8 why-2.23-1.fc13.i686 requires ocaml(Ptree) = 0:dfb73bbb000b55e87b05c0cdc2c87af6 why-2.23-1.fc13.i686 requires ocaml(Ast) = 0:2c019415b117907d730a302cdac2b248 Please resolve this as soon as possible. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Broken dependencies: cduce
cduce has broken dependencies in the development tree: On x86_64: cduce-0.5.3-3.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 cduce-0.5.3-3.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 cduce-0.5.3-3.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 cduce-0.5.3-3.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-0.5.3-3.fc13.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 cduce-0.5.3-3.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 On i386: cduce-0.5.3-3.fc13.i686 requires ocaml(runtime) = 0:3.11.1 cduce-0.5.3-3.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 cduce-0.5.3-3.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 cduce-0.5.3-3.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-0.5.3-3.fc13.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 cduce-0.5.3-3.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 On x86_64: cduce-ocamlduce-0.5.3-3.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-ocamlduce-0.5.3-3.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 cduce-ocamlduce-0.5.3-3.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 cduce-ocamlduce-0.5.3-3.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 On i386: cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(runtime) = 0:3.11.1 cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 Please resolve this as soon as possible. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Broken dependencies: why
why has broken dependencies in the development tree: On x86_64: why-2.23-1.fc13.x86_64 requires ocaml(Logic_decl) = 0:f63f0d96a92a779b9e74fc74cfc2423d why-2.23-1.fc13.x86_64 requires ocaml(Ptree) = 0:dfb73bbb000b55e87b05c0cdc2c87af6 why-2.23-1.fc13.x86_64 requires ocaml(Logic) = 0:ddd0d46a3eaa2ce4a1a3d22195514e56 why-2.23-1.fc13.x86_64 requires ocaml(Cc) = 0:7017e5b498afc612807d5f6fdc2fc257 why-2.23-1.fc13.x86_64 requires ocaml(Types) = 0:c36604dc5d4202662cfca61be96c3303 why-2.23-1.fc13.x86_64 requires ocaml(Error) = 0:808ba08d6066ba67d6c769798e909ff8 why-2.23-1.fc13.x86_64 requires ocaml(Ast) = 0:2c019415b117907d730a302cdac2b248 On i386: why-2.23-1.fc13.i686 requires ocaml(Types) = 0:c36604dc5d4202662cfca61be96c3303 why-2.23-1.fc13.i686 requires ocaml(Logic_decl) = 0:f63f0d96a92a779b9e74fc74cfc2423d why-2.23-1.fc13.i686 requires ocaml(Logic) = 0:ddd0d46a3eaa2ce4a1a3d22195514e56 why-2.23-1.fc13.i686 requires ocaml(Cc) = 0:7017e5b498afc612807d5f6fdc2fc257 why-2.23-1.fc13.i686 requires ocaml(Error) = 0:808ba08d6066ba67d6c769798e909ff8 why-2.23-1.fc13.i686 requires ocaml(Ptree) = 0:dfb73bbb000b55e87b05c0cdc2c87af6 why-2.23-1.fc13.i686 requires ocaml(Ast) = 0:2c019415b117907d730a302cdac2b248 Please resolve this as soon as possible. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Broken dependencies: cduce
cduce has broken dependencies in the development tree: On x86_64: cduce-0.5.3-3.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 cduce-0.5.3-3.fc13.x86_64 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 cduce-0.5.3-3.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 cduce-0.5.3-3.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-0.5.3-3.fc13.x86_64 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 cduce-0.5.3-3.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 On i386: cduce-0.5.3-3.fc13.i686 requires ocaml(runtime) = 0:3.11.1 cduce-0.5.3-3.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 cduce-0.5.3-3.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 cduce-0.5.3-3.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-0.5.3-3.fc13.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 cduce-0.5.3-3.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 On x86_64: cduce-ocamlduce-0.5.3-3.fc13.x86_64 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-ocamlduce-0.5.3-3.fc13.x86_64 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 cduce-ocamlduce-0.5.3-3.fc13.x86_64 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 cduce-ocamlduce-0.5.3-3.fc13.x86_64 requires ocaml(runtime) = 0:3.11.1 On i386: cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(runtime) = 0:3.11.1 cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 Please resolve this as soon as possible. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: Fixing broken deps - result of new dependency generator?
On Sun, Jan 10, 2010 at 11:04:41AM -0600, Alan Dunn wrote: [...] I'd not realized that all the Fedora mailing lists had moved ... > My first build of why in a while seems to have broken deps in Rawhide: > > why has broken dependencies in the development tree: > On x86_64: >why-2.23-1.fc13.x86_64 requires ocaml(Logic_decl) = > 0:f63f0d96a92a779b9e74fc74cfc2423d >why-2.23-1.fc13.x86_64 requires ocaml(Ptree) = > 0:dfb73bbb000b55e87b05c0cdc2c87af6 >why-2.23-1.fc13.x86_64 requires ocaml(Logic) = > 0:ddd0d46a3eaa2ce4a1a3d22195514e56 >why-2.23-1.fc13.x86_64 requires ocaml(Cc) = > 0:7017e5b498afc612807d5f6fdc2fc257 >why-2.23-1.fc13.x86_64 requires ocaml(Types) = > 0:c36604dc5d4202662cfca61be96c3303 >why-2.23-1.fc13.x86_64 requires ocaml(Error) = > 0:808ba08d6066ba67d6c769798e909ff8 >why-2.23-1.fc13.x86_64 requires ocaml(Ast) = > 0:2c019415b117907d730a302cdac2b248 > On i386: >why-2.23-1.fc13.i686 requires ocaml(Types) = > 0:c36604dc5d4202662cfca61be96c3303 >why-2.23-1.fc13.i686 requires ocaml(Logic_decl) = > 0:f63f0d96a92a779b9e74fc74cfc2423d >why-2.23-1.fc13.i686 requires ocaml(Logic) = > 0:ddd0d46a3eaa2ce4a1a3d22195514e56 >why-2.23-1.fc13.i686 requires ocaml(Cc) = > 0:7017e5b498afc612807d5f6fdc2fc257 >why-2.23-1.fc13.i686 requires ocaml(Error) = > 0:808ba08d6066ba67d6c769798e909ff8 >why-2.23-1.fc13.i686 requires ocaml(Ptree) = > 0:dfb73bbb000b55e87b05c0cdc2c87af6 >why-2.23-1.fc13.i686 requires ocaml(Ast) = > 0:2c019415b117907d730a302cdac2b248 > > I'm not sure what to do to fix this. Is this potentially a result of > the new dependency generation mechanism? I don't think the spec file > has any of the types of patterns that need to be changed as listed in > https://www.redhat.com/archives/fedora-ocaml-list/2009-December/msg00011.html So I think this is a bug in the dependency generator. At the moment it doesn't handle submodules, so for example if you have modules called M.A, M.B, then it will generated dependency hashes for ocaml(M), ocaml(A) and ocaml(B). 2 of the 3 are bogus. I usually hack round this by telling the dependency generator to ignore named modules, which is what I did in this case: http://cvs.fedoraproject.org/viewvc/devel/why/why.spec?r1=1.7&r2=1.8 > . Also, is there a way I might've detected this problem in advance? If you try to use the rpm package (ie. rpm -Uvh) after building it locally then you should be able to spot these quickly. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: soname changing parted heading for rawhide
On Mon, Jan 11, 2010 at 08:19:58PM +0100, Hans de Goede wrote: > Hi, > > Today I've rebased parted to parted-2.1, this means that the libparted > soname has changed, and all libparted using packages need to be rebuild: > > [h...@localhost ~]$ sudo repoquery -q --whatrequires > 'libparted-1.9.so.0()(64bit)' > qtparted-0:0.4.5-22.fc12.x86_64 > DeviceKit-disks-0:009-3.fc12.x86_64 (now udisks) > gparted-0:0.4.8-1.fc12.x86_64 > kde-partitionmanager-0:1.0.0-2.fc12.x86_64 > libvirt-0:0.7.1-15.fc12.x86_64 libguestfs also requires this. It depends on the literal filename, which is correct because it copies that specific file. It's not linking, but creating an appliance on the fly out of named files found in the host file system. Hence: $ rpm -qR libguestfs | grep libparted /lib64/libparted-1.9.so.0 I'm rebuilding it now. 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: RFC: gtk v4l2 (webcam) control panel app + applet
Hello, Am Dienstag, den 12.01.2010, 12:39 +0100 schrieb Hans de Goede: > For Fedora-14 (to be released November 2010) it would be nice to have > a > gtk application for controlling various camera settings (brightness, > contrast, etc.) *and* a small applet which shows a webcam icon > next to the clock when a webcam is present. Very nice idea, also providing it as a capplet seems to make sense. > There already is an existing graphical v4l2 control panel application > (v4l2ucp), which can be used to model the gtk application after. This > application is not suitable as it is using the QT GUI toolkit, which > does not integrate well into the default Fedora desktop. Looking at v4l2ucp it does not seem to be that hard. So might this be a potential GSOC project? Btw.: ekiga (http://www.ekiga.org) is also tinkering around with v4l to adjust brightness and stuff. - fabian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: gtk v4l2 (webcam) control panel app + applet
Le Mar 12 janvier 2010 14:25, Nicolas Mailhot a écrit : > > Le Mar 12 janvier 2010 12:39, Hans de Goede a écrit : > >> Which remembered me that it would be nice to have a gtk app for >> controlling webcam settings like brightness, contrast, etc. > > It would be nice if it also handled non-webcam video sources (video > acquisition cards). Needed settings are a bit different : switch source (tuner > channel...) set aspect (4/3, 16/9, etc) > > People tend to thing v4l = webcams but webcams are just one v4l hardware Also how will it interact with the new gnome colorimetry applet ? -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: gtk v4l2 (webcam) control panel app + applet
Le Mar 12 janvier 2010 12:39, Hans de Goede a écrit : > Which remembered me that it would be nice to have a gtk app for > controlling webcam settings like brightness, contrast, etc. It would be nice if it also handled non-webcam video sources (video acquisition cards). Needed settings are a bit different : switch source (tuner channel...) set aspect (4/3, 16/9, etc) People tend to thing v4l = webcams but webcams are just one v4l hardware -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
Milos Jakubicek wrote: > Also I have really doubts what concerns upstreamability of the necessary > changes in packages. These are absolutely upstreamable fixes. Using symbols from a library that you do not explicity link is a bug, plain and simple. -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: gtk v4l2 (webcam) control panel app + applet
On Tuesday 12 January 2010 12:39:52 Hans de Goede wrote: > Hi, > > As you most likely know I've been steadily working on improving > webcam support under Fedora. As you also might know I used to work > at a Dutch University teaching Computer Science. I recently got a > request from them if there were any software engineering assignments > I could come up with. > > Which remembered me that it would be nice to have a gtk app for > controlling webcam settings like brightness, contrast, etc. > > This has resulted in me writing the attached assignment, since > this is now still in the planning phase (there might even not be > any students interested), this is a good moment to provide feedback > on this. So please read it, and if you have any suggestions for > better handling of v4l2 controls, please let me know. Hi Hans, nice idea, I was thinking about same app some time ago (about time I gave you that crap camera at FUDCon in Brno as it was only semi-usable after brightness corrections). It would be nice to expose Dbus interface and thus let it desktop agnostic for example with proposed default Gnome UI but it allows for example Qt based UI (which for example we prefer in Fedora KDE). And why I'm writing this? It would be nice to incorporate it to our (hopefully soon) proposed Dbus Fedora system configuration interface as it would be more higher level than classical API. Jaroslav > Thanks, > > Hans > -- Jaroslav Řezník Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: gtk v4l2 (webcam) control panel app + applet
Good idea, apart from: On Tue, 2010-01-12 at 12:39 +0100, Hans de Goede wrote: > > For Fedora-14 (to be released November 2010) it would be nice to have > a > gtk application for controlling various camera settings (brightness, > contrast, etc.) *and* a small applet which shows a webcam icon > next to the clock when a webcam is present. Having an applet showing up for each and every type of device that's plugged into your computer is a bad idea. Having a well-made capplet (a dialogue for the control-center) would be a better fit. It should obviously handle hotplugging. Cheers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
Charley Wang writes: > https://fedoraproject.org/wiki/DSOLinkBugs > > Please note that many of the packages may be failing because of a few > DSO's. Further exploration is needed to evaluate this possibility so > we can apply one patch to the source of the problem instead of dozens > of superfluous patches. We also need (and would appreciate help with) > the linking of failed build logs to their package owners. I have problems to understand the xmlrpc-c build failure | /usr/bin/ld.bfd: xml-rpc-api2cpp.5842.test: undefined reference to symbol 'pthread_cancel@@GLIBC_2.2.5' pthread_cancel() is not used by the program. I see it in the .plt section only but not where it is referenced. I would like to avoid blind '-lpthread' flags without knowing why they are required. Enrico -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RFC: gtk v4l2 (webcam) control panel app + applet
Hi, As you most likely know I've been steadily working on improving webcam support under Fedora. As you also might know I used to work at a Dutch University teaching Computer Science. I recently got a request from them if there were any software engineering assignments I could come up with. Which remembered me that it would be nice to have a gtk app for controlling webcam settings like brightness, contrast, etc. This has resulted in me writing the attached assignment, since this is now still in the planning phase (there might even not be any students interested), this is a good moment to provide feedback on this. So please read it, and if you have any suggestions for better handling of v4l2 controls, please let me know. Thanks, Hans GTK webcam control application and applet - The Fedora project (http://fedoraproject.org/) has been working on improving webcam support for a while now: https://fedoraproject.org/wiki/Features/BetterWebcamSupportF13 For Fedora-14 (to be released November 2010) it would be nice to have a gtk application for controlling various camera settings (brightness, contrast, etc.) *and* a small applet which shows a webcam icon next to the clock when a webcam is present. Both applications are to ship with the default Gnome desktop, so the end product should be a ready to release application, each Fedora release gets installed on approximately 1 million machines! v4l2 control application requirements - There already is an existing graphical v4l2 control panel application (v4l2ucp), which can be used to model the gtk application after. This application is not suitable as it is using the QT GUI toolkit, which does not integrate well into the default Fedora desktop. MUST: * Use the gtk toolkit * Be written in C, C++ or vala (your choice) * Dynamically build up its UI (like v4l2ucp), as which controls are present differs per camera. There is an API to query which conrols there are and if they are on/of controls, or have a range (iow if they should be shown as a checkbox or a slider) SHOULD: * Have a well polished UI following the GNOME Human Interface Guidelines COULD: * ... v4l2 applet requirements The v4l2 applet is meant to be started at the startup of the desktop, and then contineously stay running. When it detects the presence of a webcam, it should show a webcam icon next to the clock (using the special docking area). Clicking on this icon should show a list of detected v4l2 devices, with the possibility to launch the control application for each. During initial development it can launch v4l2ucp, so that the 2 applications can be developed independently. MUST: * Use the gtk toolkit * Be written in C, C++ or vala (your choice) * Detect when v4l2 devices are plugged in and are removed * Show a docking area icon when the first v4l2 device is detected * Hide the docking area icon when the last v4l2 device is gone * Be able to launch a v4l2 control application on each device SHOULD: * Restore v4l2 device settings when a device gets plugged in, this will require some assistence of the v4l2 control application * Have a well polished UI following the GNOME Human Interface Guidelines * Have separate backend and frontend (UI) parts, so that the main code can easily be re-used in other desktop environments COULD: * Be aware of dual mode cameras (which can do both still image capture and function as a webcam), and show the icon even if the camera is in still image capture mode, offering the user the option to put it in webcam mode. Hardware Various webcams including some dual mode ones can be made available to the students implementing this. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
enlightenment 17 maintainer awol?
E17 components are outdated since a whole while and the maintainer doesent even respond: https://bugzilla.redhat.com/show_bug.cgi?id=514882 kind regards, Rudolf Kastl p.s. put the maintainers bz email on cc -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
On Mon, Jan 11, 2010 at 01:45:55PM -0500, Charley Wang wrote: > A rebuild was conducted, and a preliminary (unsorted) list of packages > that have implicit linkage errors can be found here: > > https://fedoraproject.org/wiki/DSOLinkBugs 78 of those seem to be caused by separated libtinfo. In default ncurses configuration libtinfo is included in libncurses, so I don't think the upstreams will be very happy about adding support for non-standard configurations. Petr Machata suggested we could work around it by replacing libncurses.so and libncursesw.so symlinks with linker scripts including both libraries. Is that acceptable? -- Miroslav Lichvar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cpp and backslashes
On 01/12/2010 09:16 AM, Jakub Jelinek wrote: > Yes, the tokens are separated by whitespace, so it is sufficient if they are > again separated by whitespace after preprocessing. See > http://gcc.gnu.org/PR41445 for details why this changed, in short > without the change the tokens have incorrect location and cause unintended > differences in debug info between direct compilation and compilation where > preprocessing happens separately from compilation. > You can use cpp -P to avoid this (then the output won't be cluttered with > # > either). > Thanks for the info. I will feed this back to the OpenFOAM developers. Cheers Terry -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cpp and backslashes
On Tue, Jan 12, 2010 at 08:06:27AM +, Terry Barnaby wrote: > I am trying to build OpenFOAM on F12 and have a problem with cpp. > In OpenFOAM cpp is used to pre-process Makefiles to create the build > environment (yuck). Some of the files contain backslash-newline > sequences for line continuations. F12's cpp seems to remove the > backslash but leave the newline in place. so for example: > > LIB_LIBS = \ > -ltriSurface \ > -lmeshTools > > becomes: > > LIB_LIBS = > -ltriSurface > -lmeshTools > > Although I know this is not what cpp is intended for, is this correct > behaviour > for cpp ? Yes, the tokens are separated by whitespace, so it is sufficient if they are again separated by whitespace after preprocessing. See http://gcc.gnu.org/PR41445 for details why this changed, in short without the change the tokens have incorrect location and cause unintended differences in debug info between direct compilation and compilation where preprocessing happens separately from compilation. You can use cpp -P to avoid this (then the output won't be cluttered with # either). Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Pulseaudio update issue... [ UPDATE 2 ]
Le Mar 12 janvier 2010 09:29, Richard Zidlicky a écrit : > > On Mon, Jan 11, 2010 at 04:10:54PM -0800, Wes Hardaker wrote: > >> I didn't see anything in that message, however, that lead me to any new >> thoughts on what I should test. I don't have any kernel circular >> looping reports like the one shown in the message above. > > this needs to be enabled at kernel compile time, not sure if it is done > in the stock kernel.. somewhere under kernel debugging. I had the warning for months (if not years) and reported it both in kernel.org bugzilla and fedora pulseaudio bugzilla. I've not seen any activity trying to fix this bug. Is this a case were everyone is waiting for someone else to investigate ? -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Pulseaudio update issue... [ UPDATE 2 ]
On Mon, Jan 11, 2010 at 04:10:54PM -0800, Wes Hardaker wrote: > I didn't see anything in that message, however, that lead me to any new > thoughts on what I should test. I don't have any kernel circular > looping reports like the one shown in the message above. this needs to be enabled at kernel compile time, not sure if it is done in the stock kernel.. somewhere under kernel debugging. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
cpp and backslashes
I am trying to build OpenFOAM on F12 and have a problem with cpp. In OpenFOAM cpp is used to pre-process Makefiles to create the build environment (yuck). Some of the files contain backslash-newline sequences for line continuations. F12's cpp seems to remove the backslash but leave the newline in place. so for example: LIB_LIBS = \ -ltriSurface \ -lmeshTools becomes: LIB_LIBS = -ltriSurface -lmeshTools Although I know this is not what cpp is intended for, is this correct behaviour for cpp ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
