Re: Sources file audit - 2010-01-06
Le dimanche 10 janvier 2010 08:06:11, Kevin Fenzi a écrit : rineau:BADSOURCE:figtoipe-20080505.tar.gz:figtoipe rineau:BADSOURCE:ipe-6.0pre32patch1-src.tar.gz:ipe Does the change of URLs of Source0 worths a rebuild in Rawhide, or is the cvs commit sufficient? -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Sources file audit - 2010-01-06
Laurent Rineau wrote: Le dimanche 10 janvier 2010 08:06:11, Kevin Fenzi a écrit : rineau:BADSOURCE:figtoipe-20080505.tar.gz:figtoipe rineau:BADSOURCE:ipe-6.0pre32patch1-src.tar.gz:ipe Does the change of URLs of Source0 worths a rebuild in Rawhide, or is the cvs commit sufficient? since functionality is by no means affected, I did not do a rebuild. -- 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 05:36:18PM +0100, Till Maas wrote:
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
^
Ah well spotted. I've fixed all these packages now.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning some packages
On Wed, Jan 13, 2010 at 6:08 PM, Peter Lemenkov lemen...@gmail.com wrote: Hello All! 2010/1/13 Mike McGrath mmcgr...@redhat.com: I'm orphaning nagios, nrpe and nagios-plugins. I just don't use them anymore. If you use them and want to help out, get too it! I can take nagios and nagios-plugins. Anyone else volunteering? I'm quite happy to be a co-maintainer of all of the above. Peter -- 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 10:52 -0800, Roland McGrath wrote: - Jussi Lehtola jussileht...@fedoraproject.org wrote: So is --as-needed within the current default flags? As far as I know, no. The default will still be --no-as-needed. That's correct. This change does not affect --as-needed at all. The --as-needed flag will link libraries if A) they define symbols required by object files B) those symbols are still undefined when the library is checked That's correct. In other words, the libfoo.so DSO will only be used at runtime if the presence of -lfoo at link time actually had any effect on what symbols got resolved to what. But --as-needed is not really apropos in this thread. OK, if RPM picks only the libraries that are actually used in auto-requires, then there's no connection. Otherwise the situation would be a whole lot different, since the requires might have some bloat. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fedora-r-devel-list] Building RPMs from CRAN...
Pierre-Yves pingou-e11oz7vxvvoxcrstzzn...@public.gmane.org writes: IMHO R2spec is here to help packagers to create/generate spec file as close as possible to the Fedora standards. Fedora's RPM will never be generated fully automatically and be maintained without human intervention that's against its philosophy. I clearly need to do some reading, and possibly some advocacy closer to the center of Fedora Packaging land. [ external repositories exist but ]The problem is that most of the time they do not respect the standards asked by Fedora. One example which appears in your application is the %file section of your spec. In order to be able/allow the user to do an rpm -ivh R-*.rpm --excludedocs we marked a number of files as being documentation. Using your spec it is not possible. This is fine, for an external repository but not for inclusion in the Fedora repository. I am completely content with the idea of adding a bunch of additional steps to the specfile creation. If we end up with something like: make spec pass 1. build package install package calculate what %files should be make spec pass 2. build package install package [ recursively install all CHECK dependencies ] check package sign package that's fine by me. It's only CPU and time we waste. If we save thought and troubles for lots of folks downstream, that's a huge win. What I think we could do, is actually set up a repository of RPM for CRAN, for Bioconductor external to the official Fedora repositories where your tool would be used and very much appreciated. I am part of the project on bioinformatics.org ([3]), and if you are willing to give it a shot I believe we could sort something out. On my side time available is really small but I believe we could find some more people willing to help for such project. I'm happy to help get something off the ground. I'm also happy to try to move what we've already got towards obeying the http://fedoraproject.org/wiki/Packaging:ReviewGuidelines but I think that, once we've done this, we should be agitating for Fedora to come up with a sane way to accept such ancillary repos. My next task is to read some of the references you pointed out, and I'll see if I can fix the %files section to note documents correctly. [1] http://informatics.umdnj.edu/BioRPMs/ [2] http://biolinux.org (down atm) [3] http://www.bioinformatics.org/r-repo/wiki/ - Allen S. Rout ___ r-devel mailing list r-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/r-devel
Re: Change to DSO-linking semantics of the compiler
But, you have added an explicit dependency upon libdb to your executable by mentioning -ldb on the gcc command line. Therefore libdb will be loaded at execution start-up. But libdb has a dependency upon libpthread, so that library will also be loaded at execution start-up. Hence when you run 'string' the pthread_cancel symbol will be resolved and so 'string' really does now have a resolved reference to pthread_cancel. Hence the linker is correct in complaining that you have a reference to a symbol that is defined in a library which have not included on the linker command line. At least that is how I see it at the moment. That would all be correct if it were not a weak reference. But it is. I doubt that gold behaves this way. Does it? Regardless of what's correct, I think we agree that BFD-ld --no-add-needed and gold should behave consistently. Probably we should take this to the binutils list to resolve what all the linker experts think is right. If your logic above holds, then all if (weak_symbol == 0) tests become useless. You've redefined the semantics of a weak reference to have all the requirements of a strong reference except when nobody anywhere defines the symbol. I'm not all clear yet on jreiser's points about the symbol version binding. But let's leave that as a separate issue to resolve with the ld and rtld experts on symbol versioning. 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 16:07, Tom Lane (t...@redhat.com) wrote: Lennart Poettering mzerq...@0pointer.de writes: There's something else that came to my mind: if libxml2 is loaded into memory indirectly because some dlopen'ed module wanted it, and then used, and then unloaded again because the module got dlcose'd again, won't you leak TLS vars unless the xmlCleanupParser() function was called properly before? In that case, not calling xmlCleanupParser() is an error, right? And calling it, too, since some other plugin/thread might still need it. Which means you are in a dilemma: in either case you are doing it wrong. Got it in one. libxml's API in this area is unusably broken, and needs a ground-up redesign not random messages telling users that they didn't use it right --- there *is* no right way to use it. Dunno. I wouldn't be so harsh. If libxml2 is linked with -z nodelete (maybe it already is? I never checked...) this dilemma *does* go away. And if then xmlCleanupParser() would be renamed to something like xmlCallMeOnlyIfYouValgrindMeOtherWiseYouSuck() and then make the symbol xmlCleanupParser() a NOP plus a gcc linker warning things are more than fixed in my eyes. (Oh, and the issue above would leak memory too, not just TLS, but TLS is usually more of a scarce resource) Oh, and let's note that other libraries have exactly the same probs. Let's pick dbus for example which many might consider a benchmark in many ways. There is dbus_shutdown() which does about the same thing as xmlCleanupParser(). And libdbus isn't linked with -z nodelete. A module that pulls it in has hence exactly the same problems. For example, let's say there was a module by the name of /lib64/security/pam_ck_connector.so which links against libdbus.so it will leak memory each time it is invoked by a process that not by itself links against libdbus, which we'll call /bin/login for now. And there you have it: the same dilemma: either the module calls dbus_shutdown and hence breaks every other dbus-using PAM module that might be loaded, or it might not call it in which case it will leak memory. Same dilemma. It's a common problem. In fact, libpulse had a similar issue until i added -z nodelete to its linker line. 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: berlios.de compromised since 2005
Once upon a time, Stephen John Smoogen smo...@gmail.com said: On Wed, Jan 13, 2010 at 11:33 AM, Jon Ciesla l...@jcomserv.net wrote: Thanks, Seth. And if we don't, what's a good resource for security auditing n00bs? 1) Look over the change history. Don't trust the source repository but older versions of the tar balls and see what has changed between them. To add to this, by older versions of the tar balls, don't just download an older version from the suspected bad place (as it could have been tampered with as well). For packages that have been in Fedora since before the initial suspected attack, grab an old SRPM from a Fedora archive mirror. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
