Re: Packaging Webmin for Fedora 11+
Already made the decision to remove the file when building and have spoken to Jamie Cameron, he will stop distributing these in his packages. But that was not really what I was after. This feature of detecting binary files in noarch packages seems to be fairly new. I was wondering how I can tell rpmbuild to include such files in an rpm package explicitly? On Sat, 2009-09-26 at 15:04 +0200, Iain Arnell wrote: On Sat, Sep 26, 2009 at 2:40 PM, Howard Wilkinson wrote: I have run into a problem when trying to package webmin for Fedora 11+. Webmin is a noarch package but it contains some binary files (effectively firmware) it is a dll that gets downloaded onto Windows based browsers. xenroll.dll? It's hardly firmware - copyright microsoft and almost certainly not redistributable. The safest option is probably to remove it completely (from the source tarball too). And if you haven't seen them already, I'd also recommend taking a look at the previous review requests for webmin - it's not the easiest thing to get packaged properly https://bugzilla.redhat.com/show_bug.cgi?id=184080 https://bugzilla.redhat.com/show_bug.cgi?id=468570 -- Iain. -- Howard Wilkinson how...@cohtech.com Coherent Technology Limited -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: CVS Outage Notification - 2009-09-29 04:25 UTC
On Mon, 2009-09-28 at 21:22 -0700, Jesse Keating wrote: There will be a CVS outage starting at 2009-09-29 04:25 UTC, which will last approximately 3 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2009-09-29 04:25 UTC' Affected Services: CVS / Source Control Unaffected Services: Everything else. Reason for Outage: The CVS server will not accept connections so that we can mass-branch for Fedora 12. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. The outage is now over. Please contact me or anybody else in #fedora-admin if you have issues with your branch (don't forget to cvs up -d) or with building. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part ___ Fedora-devel-announce mailing list fedora-devel-annou...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: sugar-pippy dependencies
On Tue, Sep 29, 2009 at 2:33 AM, Bernie Innocenti ber...@codewiz.org wrote: Hello, the sugar-pippy rpm in Fedora depends on pygame, which is used by some of the examples. So far, so good, but pygame in turn depends on numpy, a 7.7MB package which a lot of huge dependencies such as atlas (11MB), libgfortran (1MB), blas (700KB) and python-nose (1MB). The rest of Sugar is now free of numpy, so it would be good if we could get rid of it completely. One quick solution would be splitting the problematic examples to a sugar-pippy-examples-extra package. Another possibility -- probably the cleanest -- would be splitting the optional classes surfarray and sndarray to a subpackage of pygame. The numpy dep issue was discussed on fedora-devel a while ago and I thought they were going to split the specific bit of numpy that depended on atlas et al out into a separate package. I was of the understanding that this had already been done. Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
hostapd
For some time the wifi drivers have been moving away from even WEP AP mode in kernel. Is it possible to get hostapd as a package with a compile configuration similar to the attached one? Thank you, Trever Adams -- Magazines all too frequently lead to books and should be regarded by the prudent as the heavy petting of literature. -- Fran Lebowitz # Example hostapd build time configuration # # This file lists the configuration options that are used when building the # hostapd binary. All lines starting with # are ignored. Configuration option # lines must be commented out complete, if they are not to be included, i.e., # just setting VARIABLE=n is not disabling that variable. # # This file is included in Makefile, so variables like CFLAGS and LIBS can also # be modified from here. In most cass, these lines should use += in order not # to override previous values of the variables. # Driver interface for Host AP driver CONFIG_DRIVER_HOSTAP=y # Driver interface for wired authenticator #CONFIG_DRIVER_WIRED=y # Driver interface for madwifi driver #CONFIG_DRIVER_MADWIFI=y #CFLAGS += -I../../madwifi # change to the madwifi source directory # Driver interface for Prism54 driver #CONFIG_DRIVER_PRISM54=y # Driver interface for drivers using the nl80211 kernel interface CONFIG_DRIVER_NL80211=y # driver_nl80211.c requires a rather new libnl (version 1.1) which may not be # shipped with your distribution yet. If that is the case, you need to build # newer libnl version and point the hostapd build to use it. #LIBNL=/usr/src/libnl #CFLAGS += -I$(LIBNL)/include #LIBS += -L$(LIBNL)/lib # Driver interface for FreeBSD net80211 layer (e.g., Atheros driver) #CONFIG_DRIVER_BSD=y #CFLAGS += -I/usr/local/include #LIBS += -L/usr/local/lib # Driver interface for no driver (e.g., RADIUS server only) #CONFIG_DRIVER_NONE=y # IEEE 802.11F/IAPP CONFIG_IAPP=y # WPA2/IEEE 802.11i RSN pre-authentication CONFIG_RSN_PREAUTH=y # PeerKey handshake for Station to Station Link (IEEE 802.11e DLS) CONFIG_PEERKEY=y # IEEE 802.11w (management frame protection) # This version is an experimental implementation based on IEEE 802.11w/D1.0 # draft and is subject to change since the standard has not yet been finalized. # Driver support is also needed for IEEE 802.11w. #CONFIG_IEEE80211W=y # Integrated EAP server CONFIG_EAP=y # EAP-MD5 for the integrated EAP server CONFIG_EAP_MD5=y # EAP-TLS for the integrated EAP server CONFIG_EAP_TLS=y # EAP-MSCHAPv2 for the integrated EAP server CONFIG_EAP_MSCHAPV2=y # EAP-PEAP for the integrated EAP server CONFIG_EAP_PEAP=y # EAP-GTC for the integrated EAP server CONFIG_EAP_GTC=y # EAP-TTLS for the integrated EAP server CONFIG_EAP_TTLS=y # EAP-SIM for the integrated EAP server CONFIG_EAP_SIM=y # EAP-AKA for the integrated EAP server CONFIG_EAP_AKA=y # EAP-AKA' for the integrated EAP server # This requires CONFIG_EAP_AKA to be enabled, too. CONFIG_EAP_AKA_PRIME=y # EAP-PAX for the integrated EAP server CONFIG_EAP_PAX=y # EAP-PSK for the integrated EAP server (this is _not_ needed for WPA-PSK) CONFIG_EAP_PSK=y # EAP-SAKE for the integrated EAP server CONFIG_EAP_SAKE=y # EAP-GPSK for the integrated EAP server CONFIG_EAP_GPSK=y # Include support for optional SHA256 cipher suite in EAP-GPSK CONFIG_EAP_GPSK_SHA256=y # EAP-FAST for the integrated EAP server # Note: Default OpenSSL package does not include support for all the # functionality needed for EAP-FAST. If EAP-FAST is enabled with OpenSSL, # the OpenSSL library must be patched (openssl-0.9.9-session-ticket.patch) # to add the needed functions. CONFIG_EAP_FAST=y # Wi-Fi Protected Setup (WPS) #CONFIG_WPS=y # Enable UPnP support for external WPS Registrars #CONFIG_WPS_UPNP=y # EAP-IKEv2 CONFIG_EAP_IKEV2=y # Trusted Network Connect (EAP-TNC) CONFIG_EAP_TNC=y # PKCS#12 (PFX) support (used to read private key and certificate file from # a file that usually has extension .p12 or .pfx) CONFIG_PKCS12=y # RADIUS authentication server. This provides access to the integrated EAP # server from external hosts using RADIUS. #CONFIG_RADIUS_SERVER=y # Build IPv6 support for RADIUS operations CONFIG_IPV6=y # IEEE Std 802.11r-2008 (Fast BSS Transition) CONFIG_IEEE80211R=y # Use the hostapd's IEEE 802.11 authentication (ACL), but without # the IEEE 802.11 Management capability (e.g., madwifi or FreeBSD/net80211) #CONFIG_DRIVER_RADIUS_ACL=y # IEEE 802.11n (High Throughput) support CONFIG_IEEE80211N=y # Remove debugging code that is printing out debug messages to stdout. # This can be used to reduce the size of the hostapd considerably if debugging # code is not needed. #CONFIG_NO_STDOUT_DEBUG=y signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Thunderbird 3.0pre?
Mail Lists, Sun, 27 Sep 2009 11:23:11 -0400: You might want to delete your .thunderbird directory and try again. Im happy for you. For what its worth, I have several accounts too - not just many mail folders. My experience is that it is better to run IMAP server on localhost and store all messages there ... emails are too valuable thing to be given to pre-release code. Anyway ... It did not work for me - whilst the vanilla 3.0pre version works fine - witrhout deleting anything. I would love to see a bug report for this with a backtrace of thunderbird when it is in 100% CPU state. So, please: 1) install all -debuginfo packages (debuginfo-install thunderbird is your friend), 2) start TB, 3) open gnome-terminal (or whatever terminal emulator you use in X) and when TB goes to 100% CPU, you will have hopefully at least enough juice to Alt+TAB to the terminal and run gdb --pid=$(/sbin/pidof thunderbird-bin) (you can have it prepared on the command line, so you just run Alt+TAB and Enter) 4) when you finally get gdb prompt, run command thread apply all backtrace 5) you get many screens of stuff, please, copy it into a new bug report against Thunderbird component on bugzilla.redhat.com. Thank you, Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: CVS Outage Notification - 2009-09-29 04:25 UTC
On Tue, 2009-09-29 at 00:40 -0700, Jesse Keating wrote: The outage is now over. Please contact me or anybody else in #fedora-admin if you have issues with your branch (don't forget to cvs up -d) or with building. It was pointed out to me that many of the packages starting with a were not properly branched. I've restarted the branch run for the a packages, however this time email will go out for the branch events, and this won't incur another outage. The branching of a packages should be done in 10 or 15 minutes. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part ___ Fedora-devel-announce mailing list fedora-devel-annou...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
2009/9/29 Rahul Sundaram sunda...@fedoraproject.org Are we removing rsync from the distribution? I hope not. What is your argumentation for keeping rsync, even it doesn't meet the fedora guidelines? What is with the other packages which doesn't meet the guidelines? I believe there are no consequences for packages they are already in. no one cares. zsync seems to bean an exception! -- Josephine Fine Tannhäuser 2.6.29.6-213.fc11.i586 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
Le Mar 29 septembre 2009 10:54, Josephine Tannhäuser a écrit : 2009/9/29 Rahul Sundaram sunda...@fedoraproject.org Are we removing rsync from the distribution? I hope not. What is your argumentation for keeping rsync, even it doesn't meet the fedora guidelines? What is with the other packages which doesn't meet the guidelines? I believe there are no consequences for packages they are already in. no one cares. zsync seems to bean an exception! Of course we care about existing packages; no packager should consider his work is done once the package is in. However, rsync is a widely-used package, it can't be yanked that easily. Generally speaking removing a package is the WMD option and it's very sad when a packager forces releng to use this stick. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Packaging Webmin for Fedora 11+
Am Dienstag, den 29.09.2009, 08:24 +0100 schrieb Howard Wilkinson: Already made the decision to remove the file when building During build is not enough. If we are not allowed to redistribute it, we cannot distribute it in our source rpms ether. Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
2009/9/29 Nicolas Mailhot nicolas.mail...@laposte.net Of course we care about existing packages; Oh, really? There exist a tracker for bugs with duplicated libs. There are not really activities on these bugs. Perhaps the maintainers ( not that I blame them) are not interessted in solving these bugs. Like the open bugs for switching to PolicyKit. Or the discussion of flags. It seems to me they fizzled out So the most of these bugs will fizzled out, if there is no one (of the higher ranks in the fedoraproject, maybe redhat?) who take care of the implemention of the guidelines! Seems that violations of the guidelines are not so important like the violation of the Trademark (The hunting of fedora related sites, like blogs or forums with adhesions contracts)... Are the project related activities are out of balance? -- Josephine Fine Tannhäuser 2.6.29.6-213.fc11.i586 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Packaging Webmin for Fedora 11+
It has to been clean out of the source. -- Josephine Fine Tannhäuser 2.6.29.6-213.fc11.i586 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Packaging Webmin for Fedora 11+
btw. what was the reason for debian to drop webmin? -- Josephine Fine Tannhäuser 2.6.29.6-213.fc11.i586 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On 09/29/2009 05:14 PM, Josephine Tannhäuser wrote: Seems that violations of the guidelines are not so important like the violation of the Trademark (The hunting of fedora related sites, like blogs or forums with adhesions contracts)... Are the project related activities are out of balance? They are called guidelines and there are always exceptions. Bundling a library is not ideal but removing rsync would be a extreme step. I don't think the situation warrants that. Let's not loose perspective here. Legal issues might deserve a higher priority but would vary on a case by case basis. If you have concerns about that, take it to fedora-legal or fedora advisory board list. A number of changes have been made in the trademark guidelines recently in response to concerns and afaik, it has been addressed thoroughly. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
2009/9/29 Rahul Sundaram sunda...@fedoraproject.org Bundling a library is not ideal but removing rsync would be a extreme step. I believe this isn't a technical problem, more a psychological one. Fedora is a (software) technic orientated project, or? -- Josephine Fine Tannhäuser 2.6.29.6-213.fc11.i586 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On 09/29/2009 05:45 PM, Josephine Tannhäuser wrote: 2009/9/29 Rahul Sundaram Bundling a library is not ideal but removing rsync would be a extreme step. I believe this isn't a technical problem, more a psychological one. Fedora is a (software) technic orientated project, or? It is clearly a technical problem. All of the packaging guidelines are. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Removing provide statement from an existing spec file
Hi all, I took over a package a couple of days ago and have a question according to a provide statement. Consider the following one: Name: myapp Provides: myapp.pl If I interpret the naming guidelines right, then a period is not allowed in a package name. But what about a provide statement (guess it's the same)? In case it is also illegal what would be the best to do. Will yum update the package if a user installed previously myapp.pl instead of myapp and the new package does not have a provide statement anymore? In the end the question would be should I follow the guidelines or provide backward compatibility in sense of updating. cheers Stefan PS: .pl should indicate that it is a Perl script, not a locale. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Removing provide statement from an existing spec file
On Tue, 29 Sep 2009 14:32:06 +0200, Stefan wrote: Hi all, I took over a package a couple of days ago and have a question according to a provide statement. Consider the following one: Name: myapp Provides: myapp.pl If I interpret the naming guidelines right, then a period is not allowed in a package name. Well, better is, but it's not entirely right. Think openoffice.org packages. ;) The period is used as separator/delimiter in RPM package file names, however, so using it elsewhere may cause confusion in software that cannot deal with the extra period characters. But what about a provide statement (guess it's the same)? No. See e.g. the automatic library SONAME provides: libfoo.so.0 Or see rpm -qa --provides. In case it is also illegal what would be the best to do. Will yum update the package if a user installed previously myapp.pl instead of myapp and the new package does not have a provide statement anymore? Yes, because the newer myapp package will replace the older one, regardless of its Provides. In the end the question would be should I follow the guidelines or provide backward compatibility in sense of updating. cheers Stefan PS: .pl should indicate that it is a Perl script, not a locale. Try: repoquery --whatrequires myapp.pl If nothing uses this virtual package name (and it isn't used upstream either), get rid of it. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
Once upon a time, Josephine Tannhäuser josephine.tannhau...@googlemail.com said: 2009/9/29 Rahul Sundaram sunda...@fedoraproject.org Bundling a library is not ideal but removing rsync would be a extreme step. I believe this isn't a technical problem, more a psychological one. Fedora is a (software) technic orientated project, or? Since rsync is used in the distribution of Fedora, removing it _would_ be a technical problem. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On 09/29/2009 12:31 AM, Jesse Keating wrote: On Mon, 2009-09-28 at 23:00 +0100, Mat Booth wrote: What do we have to do in order to build on PPC? Does it happen automagically? Once the ppc builders are setup and running smoothly, successful build requests on the primary arches will be tried on the secondary arches, which will include ppc. You'll need to do nothing specific on your end for this to happen. What about ppc specific packages (with exclusive arch set to ppc/ppc64)? RR -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Packaging Webmin for Fedora 11+
Am Dienstag, den 29.09.2009, 13:55 +0200 schrieb Josephine Tannhäuser: btw. what was the reason for debian to drop webmin? Dunno, maybe the fact that webmin is a weapon of mass destruction. ;) Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Removing provide statement from an existing spec file
SSF == Stefan Schulze Frielinghaus ste...@seekline.net writes: SSF If I interpret the naming guidelines right, then a period is not SSF allowed in a package name. Could you indicate where in the naming guidelines you see that a period is not valid in a package name? - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Tue, Sep 29, 2009 at 03:56:52PM +0200, Roman Rakus wrote: On 09/29/2009 12:31 AM, Jesse Keating wrote: On Mon, 2009-09-28 at 23:00 +0100, Mat Booth wrote: What do we have to do in order to build on PPC? Does it happen automagically? Once the ppc builders are setup and running smoothly, successful build requests on the primary arches will be tried on the secondary arches, which will include ppc. You'll need to do nothing specific on your end for this to happen. What about ppc specific packages (with exclusive arch set to ppc/ppc64)? What about them? They can exist in the CVS repo. You just won't be able to build them in koji for F-13 until a secondary arch instance is going. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Removing provide statement from an existing spec file
On Tue, 2009-09-29 at 09:33 -0500, Jason L Tibbitts III wrote: SSF == Stefan Schulze Frielinghaus ste...@seekline.net writes: SSF If I interpret the naming guidelines right, then a period is not SSF allowed in a package name. Could you indicate where in the naming guidelines you see that a period is not valid in a package name? https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Separators When naming packages for Fedora, the maintainer must use the dash '-' as the delimiter for name parts. The maintainer must NOT use an underscore '_', a plus '+', or a period '.' as a delimiter unless indicated by the few exceptions underneath. -Stefan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: bitmap-fonts by default?
On Mon, Sep 28, 2009 at 11:29 PM, Jens Petersen peter...@redhat.com wrote: We have been looking at updating bitmap-fonts recently, and noticed that it is still listed mandatory in the comps @base-x group. So I just wondered a couple of naive questions: - does bitmap-fonts have to be installed by default? - what actually needs it? Jens XEmacs needs it. We have an explicit reference to a LucidaTypewriter font. We started to transition to fontconfig 2004-ish. Unfortunately, the developers who started that effort have since mostly disappeared. If there are any competent fontconfig developers who could give us a hand completing the transition, please stop by xemacs-b...@xemacs.org and say hello. I will personally send a box of home-made oatmeal raisin cookies [1] to anyone who can help us finish the job. Footnotes: [1] I can make no guarantees about the state of crumbliness on arrival, of course. -- Jerry James http://www.jamezone.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[KDE] Which Phonon? Phonon backend - GStreamer or Xine?
Hi! We, KDE SIG, are considering which backend should be default for Phonon in Fedora. Seems like it's not easy to agree on final decision @ KDE SIG meetings, we'd like to summarize what's the problem, some backends facts (please correct me, comment, add, etc.) and we'd like to hear comments from outer KDE SIG universe, from you, Fedora developers users, too. First question is which Phonon use - there are two actually - one is part of Qt, one is part of KDE. Upstream recommends building/packaging phonon from qt, and building/packaging backends separately. Some backends facts... GStreamer backend facts: * now default one in Fedora (F12, rawhide) * GStreamer is Fedora's default multimedia framework - better support from Fedora side? (PA, releases) * Phonon backend not as mature as Xine one - missing functionality * Maybe more support from upstream developers in the future? [1] * Nokia is upstream Xine backend facts: * default in F10 F11 * recommended by sandsmark (upstream developer) and Amarok team * Xine is not as well supported as GStreamer in Fedora - but currently nearly bug free * KDE is upstream We prepared test plan but still we don't have any response from our users. For some users Xine one works better, for others GStreamer backend works better. Seems like it depends on sound HW, ALSA support, PA, engine, backend - lots of possibilities. So there are two questions: 1. which Phonon 2. which backend fits better to Fedora... [1] http://mail.kde.org/pipermail/phonon-backends/2009-September/000304.html Jaroslav KDE SIG -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On 09/29/2009 04:48 PM, Josh Boyer wrote: On Tue, Sep 29, 2009 at 03:56:52PM +0200, Roman Rakus wrote: On 09/29/2009 12:31 AM, Jesse Keating wrote: On Mon, 2009-09-28 at 23:00 +0100, Mat Booth wrote: What do we have to do in order to build on PPC? Does it happen automagically? Once the ppc builders are setup and running smoothly, successful build requests on the primary arches will be tried on the secondary arches, which will include ppc. You'll need to do nothing specific on your end for this to happen. What about ppc specific packages (with exclusive arch set to ppc/ppc64)? What about them? They can exist in the CVS repo. You just won't be able to build them in koji for F-13 until a secondary arch instance is going. josh ah, ok. Thanks RR -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On 09/29/2009 05:00 AM, Rahul Sundaram wrote: On 09/29/2009 05:14 PM, Josephine Tannhäuser wrote: Seems that violations of the guidelines are not so important like the violation of the Trademark (The hunting of fedora related sites, like blogs or forums with adhesions contracts)... Are the project related activities are out of balance? They are called guidelines and there are always exceptions. Bundling a library is not ideal but removing rsync would be a extreme step. I don't think the situation warrants that. Let's not loose perspective here. So in this case, I think the following things could be said: * Removing rsync is not an option because of how widely it is used. * Bundling libraries in zsync is not an option * If there really exists a way to build against the system zlib and remain compatible (which librsync claims, someone notting talked to does, but zsync upstream does not) then that should be done and we'll patch our packages to do so even if upstream does not accept it. * If we have to use a forked zlib, we'd patch our packages to pull the zlib out of the rsync package with its own soname and ship that so zsync and zsync can interoperate even if upstream does not accept it. However we need to coordinate this with upstream or the other distributions to come up with one standard libname, version, etc. The alternative is that: * People assert that bundled libraries are not problematical enough in the general case to warrant prohibition so the Guideline should be dropped. To do this probably means adding other procedures for maintainers to follow to address the issues that do exist with bundled libraries. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Heads up: net-snmp soname bump in rawhide
Net-SNMP 5.5 is heading to rawhide (i.e. Fedora 13). The update comes with soname bump and few changes in include files. I have tried to recompile all dependent packages in mock and most of them succeeded. I've already notified maintainers of the problematic ones and they know how to fix them. Full list of packages to rebuild: 389-ds-base apcupsd asterisk cacti cluster-glue clustermon collectd cpqarrayd cyrus-imapd hplip ifstat nagios-plugins-snmp-disk-proc netdisco ntop nut openhpi openhpi-subagent OpenIPMI openscada openser pacemaker php pysnmp sipwitch tog-pegasus zabbix Let me know if you have problems rebuilding your package. Regards, Jan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Thunderbird 3.0pre?
On 09/27/2009 08:15 AM, Mail Lists wrote: On 09/27/2009 11:02 AM, drago01 wrote: On Sun, Sep 27, 2009 at 5:00 PM, mike cloakedmike.cloa...@gmail.com wrote: Is there any chance there will be a build of Thunderbird 3.0PRE in Koji soon? It would be nice to see a build for F11 and F12 as I believe there are significant fixes compared to 3.0beta 4 in the 3.0pre build. like? I do know that the 64 bit fedora beta 4 (there is no 64 bit mozilla.org as, last I read a while ago, they are not comfortable the code is 64 bit clean) had terrible problems from beta 4 (tho beta 3 was fine). I switched to 32 bit mozilla.org 3.0pre (on x64 install of f11) and the problems went away. The beta 4 (from updates-testing) started the indexing thing - and then it took 100% cpu and memory growth went to 3.5 GiB - after a period memory use fell to 200 MiB, cpu declined .. then it repeated this cycle several times .. i left this for 6 hours - eventually tb locked up and left a dirty screen image - stuck - cpu usage went to 0 for TB. I had to hand kill it. Installing the stock mozilla 386 build has no such problems. I suspect there is some 64 very unclean code underlying the problem. Tho it could be beta 4 versus pre as well. Tweaking the following pref: mailnews.database.global.indexer.enabled = false Should work around the problem for now. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Removing provide statement from an existing spec file
On Tue, 2009-09-29 at 14:45 +0200, Michael Schwendt wrote: [...] But what about a provide statement (guess it's the same)? No. See e.g. the automatic library SONAME provides: libfoo.so.0 Or see rpm -qa --provides. Good point. In case it is also illegal what would be the best to do. Will yum update the package if a user installed previously myapp.pl instead of myapp and the new package does not have a provide statement anymore? Yes, because the newer myapp package will replace the older one, regardless of its Provides. That was the behavior of yum I expected/hoped to see. In the end the question would be should I follow the guidelines or provide backward compatibility in sense of updating. cheers Stefan PS: .pl should indicate that it is a Perl script, not a locale. Try: repoquery --whatrequires myapp.pl If nothing uses this virtual package name (and it isn't used upstream either), get rid of it. No other package uses this name (also not upstream) so I'm going to remove it. Thanks for clarification, Stefan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
FJR == Jaroslav Reznik jrez...@redhat.com writes: FJR * Phonon backend not as mature as Xine one FJR - missing functionality Perhaps you could supply more detail as to which functionality is missing? - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Removing provide statement from an existing spec file
Le Mar 29 septembre 2009 17:26, Jason L Tibbitts III a écrit : SSF == Stefan Schulze Frielinghaus ste...@seekline.net writes: SSF https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Separators SSF When naming packages for Fedora, the maintainer must use the dash SSF '-' as the delimiter for name parts. The maintainer must NOT use an SSF underscore '_', a plus '+', or a period '.' as a delimiter unless SSF indicated by the few exceptions underneath. delimiter for name parts. That doesn't say a period is invalid in a package name, because it's explicitly listed as valid at the top of the document. The section you quote indicates why we have foo-devel and perl-Foo-Bar instead of foo.devel and perl.Foo.Bar. I don't think the list of examples right below this § supports your view (and actually I do believe the list of existing infringing packages is small enough renaming them would have been worth removing any future package confusion) -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Removing provide statement from an existing spec file
Le Mar 29 septembre 2009 17:43, Nicolas Mailhot a écrit : I don't think the list of examples right below this § supports your view (and actually I do believe the list of existing infringing packages is small enough renaming them would have been worth removing any future package confusion) And BTW could someone remove https://fedoraproject.org/wiki/Packaging/NamingGuidelines#AddonLocale or find some other example? It's in direct contradiction with the font package naming guidelines. Regards, -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20090929 changes
perl-HTML-Tree-3.23-9.fc12 -- * Mon Sep 28 2009 Tom spot Callaway tcall...@redhat.com - 1:3.23-9 - apply Jeff Fearn's fix for the missing close tag bug (bz 535587) perl-Test-Script-1.06-1.fc12 * Mon Sep 28 2009 Ralf Corsépius corse...@fedoraproject.org - 1.06-1 - Upstream update. - BR: perl(Probe::Perl) - Activate AUTOMATED_TESTING=1 RELEASE_TESTING=1. perl-XML-TreeBuilder-3.09-16.fc12 - * Tue Sep 29 2009 Jeff Fearn jfe...@redhat.com - 3.09-16 - Stupid man! Don't eat entities :( perl-mecab-0.98-1.fc12 -- * Tue Sep 29 2009 Mamoru Tasaka mtas...@ioa.s.u-tokyo.ac.jp - 0.98-1 - 0.98 pixman-0.16.2-1.fc12 * Mon Sep 28 2009 Soren Sandmann s...@redhat.com - 0.16.2-1 - pixman 0.16.2 plplot-5.9.5-1.fc12 --- * Mon Sep 28 2009 - Orion Poplawski or...@cora.nwra.com - 5.9.5-1 - Update to 5.9.5 - Disable qt tests for now until Xvfb bug is fixed. - Remove ocaml dep code for now - breaks other dep generation plymouth-0.8.0-0.2009.28.09.fc12 * Mon Sep 28 2009 Ray Strode rstr...@redhat.com 0.8.0-0.2009.28.09 - Add prerelease of 0.8.0 for multihead support pycdio-0.15-4.fc12 -- * Mon Sep 28 2009 Jay Greguske jgreg...@redhat.com - 0.15-4 - Off-by-one compensation in get_devices_* not needed anymore python-TurboMail-3.0-1.fc12 --- * Mon Sep 28 2009 Felix Schwarz felix.schw...@oss.schwarz.eu - 3.0-1 - Update to new major version 3.0 - fixed copyright attribution in LICENSE.txt python-mecab-0.98-1.fc12 * Tue Sep 29 2009 Mamoru Tasaka mtas...@ioa.s.u-tokyo.ac.jp - 0.98-1 - 0.98 python-slip-0.2.6-1.fc12 * Mon Sep 28 2009 Nils Philippsen n...@redhat.com - 0.2.6-1 - ship all slip.dbus modules (#525790) qemu-0.11.0-2.fc12 -- * Mon Sep 28 2009 Mark McLoughlin mar...@redhat.com - 2:0.11.0-1 - Update to 0.11.0 release - Drop a couple of upstreamed patches * Mon Sep 28 2009 Mark McLoughlin mar...@redhat.com - 2:0.11.0-2 - Fix pci hotplug to not exit if supplied an invalid NIC model (#524022) qt-4.5.2-20.fc12 * Mon Sep 28 2009 Rex Dieter rdie...@fedoraproject.org - 4.5.2-20 - use internal Qt Assistant/Designer icons - -devel: move designer.qch,linguist.qch here - move ownership of %_qt4_docdir, %_qt4_docdir/qch to main pkg redhat-rpm-config-9.0.3-18.fc12 --- * Mon Sep 28 2009 Bill Nottingham nott...@redhat.com - Drop xz compression level to 2 rhythmbox-0.12.5-3.fc12 --- * Mon Sep 28 2009 Richard Hughes rhug...@redhat.com - 0.12.5-2 - Apply a patch from upstream to inhibit gnome-session, rather than gnome-power-manager. This fixes a warning on rawhide. * Mon Sep 28 2009 Bastien Nocera bnoc...@redhat.com 0.12.5-3 - Fix the symbols for the browser plugin being mangled (#525826) ruby-mecab-0.98-1.fc12 -- * Tue Sep 29 2009 Mamoru Tasaka mtas...@ioa.s.u-tokyo.ac.jp - 0.98-1 - 0.98 scim-1.4.9-4.fc12 - * Tue Sep 29 2009 Peng Huang phu...@redhat.com - 1.4.9-4 - Remove workaround patch added in 1.4.9-3. - The bug 517001 has been fixed in glibc. senamirmir-washra-fonts-4.1-5.fc12 -- * Mon Sep 28 2009 Nicolas Mailhot nicolas.mailhot at laposte.net - 4.1-5 — Tweak fontconfig fixing skkdic-20090929-1.T0800.fc12 * Tue Sep 29 2009 Mamoru Tasaka mtas...@ioa.s.u-tokyo.ac.jp - 20090929-1.T0800 - Update for F12Beta sound-juicer-2.28.0-3.fc12 -- * Mon Sep 28 2009 Richard Hughes rhug...@redhat.com - 2.28.0-3 - Apply a patch from upstream to inhibit gnome-session, rather than gnome-power-manager. This fixes a warning on rawhide when using sound-juicer. sound-theme-freedesktop-0.7-1.fc12 -- * Mon Sep 28 2009 Jon McCann jmcc...@redhat.com 0.7-1 - Update to 0.7 sssd-0.6.0-0.fc12 - * Mon Sep 28 2009 Sumit Bose sb...@redhat.com - 0.6.0-0 - New upstream release 0.6.0 sysprof-1.1.2-3.fc12 system-config-date-1.9.50-1.fc12 * Mon Sep 28 2009 Nils Philippsen n...@redhat.com - 1.9.50-1 - pick up new translations system-config-date-docs-1.0.8-1.fc12 * Mon Sep 28 2009 Nils Philippsen n...@redhat.com - 1.0.8-1 - pick up new translations * Wed Aug 26 2009 Nils Philippsen n...@redhat.com - explain obsoleting old versions system-config-nfs-1.3.49-1.fc12 --- * Mon Sep 28 2009 Nils Philippsen n...@redhat.com - 1.3.49-1 - pick up new translations system-config-nfs-docs-1.0.7-1.fc12 --- * Mon Sep 28 2009 Nils Philippsen n...@redhat.com - 1.0.7-1 - pick up new translations * Wed Aug 26 2009 Nils Philippsen n...@redhat.com - explain obsoleting old versions system-config
Re: Adding encrypted drive to encrypted system post installation
On Sat, 2009-09-26 at 20:02 +0200, Till Maas wrote: You need to edit /etc/crypttab (man crypttab) to create a mapping for unencrypting the partition and /etc/fstab to mount the unencrypted volume. This was what I needed, thank you. After adding that line, I just needed to add a line to /etc/fstab to mount the partition by label (i.e. LABEL=...). Tim. */ signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: net-snmp soname bump in rawhide
On Tue, Sep 29, 2009 at 05:16:13PM +0200, Jan Safranek wrote: Net-SNMP 5.5 is heading to rawhide (i.e. Fedora 13). The update comes Rawhide is still based on dist-f12. We have no cute name for dist-f13. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
Jaroslav Reznik wrote: GStreamer backend facts: * now default one in Fedora (F12, rawhide) * GStreamer is Fedora's default multimedia framework - better support from Fedora side? (PA, releases) * Phonon backend not as mature as Xine one - missing functionality More bugs too. * Maybe more support from upstream developers in the future? [1] * Nokia is upstream But nobody knows for how long because Nokia is working on an alternative multimedia framework for Qt as part of the Qt Mobility project. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Fedora 12 Freeze at 0600~ 2009-09-30 UTC
Just a reminder that the Fedora 12 freeze will be happening tonight at 0600 2009-09-30 UTC, just prior to the rawhide compose tonight. The rawhide for 20090930 will be built from frozen content. You do not need to send tag requests until after that. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part ___ Fedora-devel-announce mailing list fedora-devel-annou...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
On Tue, 29.09.09 18:23, Kevin Kofler (kevin.kof...@chello.at) wrote: Jaroslav Reznik wrote: GStreamer backend facts: * now default one in Fedora (F12, rawhide) * GStreamer is Fedora's default multimedia framework - better support from Fedora side? (PA, releases) * Phonon backend not as mature as Xine one - missing functionality More bugs too. * Maybe more support from upstream developers in the future? [1] * Nokia is upstream But nobody knows for how long because Nokia is working on an alternative multimedia framework for Qt as part of the Qt Mobility project. Uh. Nokia stands pretty firmly behind gst. As do most embedded folks. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Upcoming Fedora 12 Development/Release Engineering Tasks
Upcoming Fedora 12 Development/Release Engineering Tasks Name Start End Alpha Testing Tue 2009-08-25 Tue 2009-09-29 Software: Rebuild all translated packages Tue 2009-09-22 Tue 2009-09-29 Test 'Test Compose' (boot media testing) Wed 2009-09-23 Wed 2009-09-30 Mass Branching Mon 2009-09-28 Mon 2009-09-28 End of Alpha Testing Tue 2009-09-29 Tue 2009-09-29 Final (Beta) Freeze: Development Code Complete Tue 2009-09-29 Tue 2009-09-29 Deliver features 100% to FESCo Wed 2009-09-30 Wed 2009-09-30 Compose Beta Candidate Thu 2009-10-01 Thu 2009-10-01 Test Beta CandidateThu 2009-10-01 Thu 2009-10-08 Beta Blocker Day (F12Beta) #4 Fri 2009-10-02 Fri 2009-10-02 Beta Blocker Bug (go/no go)Mon 2009-10-05 Mon 2009-10-05 Beta Project Wide Release Readiness MeetingWed 2009-10-07 Wed 2009-10-07 Start Stage Sync Beta to Mirrors Thu 2009-10-08 Thu 2009-10-08 Stage Sync Beta to Mirrors Thu 2009-10-08 Tue 2009-10-13 Beta Export Control Reporting Fri 2009-10-09 Fri 2009-10-09 Beta Release Public Availability Tue 2009-10-13 Tue 2009-10-13 Beta Testing Tue 2009-10-13 Mon 2009-10-26 I realize the formatting of these emails is not pretty if your email reader uses a proportional font. The mail archives are worse, for example https://www.redhat.com/archives/fedora-trans-list/2009-September/msg00082.html Right now I'm using a simple python script to parse and add spaces to a CSV file created by TaskJuggler. Let me know if there are any ideas for fixing this. Thanks, John -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Removing provide statement from an existing spec file
On Tue, 29 Sep 2009 17:43:38 +0200, Nicolas wrote:
Le Mar 29 septembre 2009 17:26, Jason L Tibbitts III a écrit :
SSF == Stefan Schulze Frielinghaus writes:
SSF https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Separators
SSF When naming packages for Fedora, the maintainer must use the dash
SSF '-' as the delimiter for name parts. The maintainer must NOT use an
SSF underscore '_', a plus '+', or a period '.' as a delimiter unless
SSF indicated by the few exceptions underneath.
delimiter for name parts. That doesn't say a period is invalid in a
package name, because it's explicitly listed as valid at the top of the
document. The section you quote indicates why we have foo-devel and
perl-Foo-Bar instead of foo.devel and perl.Foo.Bar.
I don't think the list of examples right below this § supports your view
(and actually I do believe the list of existing infringing packages is small
enough renaming them
would have been worth removing any future package confusion)
The delimiter is implicit anyway for an ordinary
%package foo
sub-package definition which results in %{name}-foo without that
the packager needs to decide on using '-' or '.' anywhere.
As opposed to doing it explicitly %package -n something.foo
for a sub-package.
[...]
Why does it need an exception for locale packages?
https://fedoraproject.org/wiki/Packaging/NamingGuidelines#AddonLocale
If a package adds a locale to an existing parent package, then it can
use an underscore in the locale.
Examples:
ttfonts-zh_TW (adds zh_TW locale fonts in ttfonts family)
ttfonts-zh_CN (adds zh_CN locale fonts in ttfonts family)
That's the typical parent-child scheme, with the locale being a name
part. Why does it need an exception for an underscore in the child name?
The underscore here is no name parts delimiter, but part of an ordinary
package name.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: net-snmp soname bump in rawhide
On Tue, 2009-09-29 at 12:13 -0400, Josh Boyer wrote: Rawhide is still based on dist-f12. We have no cute name for dist-f13. Futurehide -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) identi.ca (http://identi.ca/jkeating) signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: net-snmp soname bump in rawhide
On Tue, 29 Sep 2009, Jesse Keating wrote: On Tue, 2009-09-29 at 12:13 -0400, Josh Boyer wrote: Rawhide is still based on dist-f12. We have no cute name for dist-f13. Futurehide I expect that to be the name of a scifi book published by ToR -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: net-snmp soname bump in rawhide
On 09/29/2009 01:16 PM, Jesse Keating wrote: On Tue, 2009-09-29 at 12:13 -0400, Josh Boyer wrote: Rawhide is still based on dist-f12. We have no cute name for dist-f13. Futurehide Runandhide -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: net-snmp soname bump in rawhide
Seth Vidal wrote: On Tue, 29 Sep 2009, Jesse Keating wrote: On Tue, 2009-09-29 at 12:13 -0400, Josh Boyer wrote: Rawhide is still based on dist-f12. We have no cute name for dist-f13. Futurehide I expect that to be the name of a scifi book published by ToR -sv Yeah, but a movie then gives us the theme song. Tag 'em up, build 'em out, bodhi-client, mash it down, yum update -y, futurehide! -- in your fear, seek only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On Tue, 2009-09-29 at 08:15 -0500, Chris Adams wrote: Once upon a time, Josephine Tannhäuser josephine.tannhau...@googlemail.com said: 2009/9/29 Rahul Sundaram sunda...@fedoraproject.org Bundling a library is not ideal but removing rsync would be a extreme step. I believe this isn't a technical problem, more a psychological one. Fedora is a (software) technic orientated project, or? Since rsync is used in the distribution of Fedora, removing it _would_ be a technical problem. and the reason we (QA) want it added to Fedora is so we can use it in the distribution of Fedora... (we want to use it to allow people to reduce the size of nightly live image downloads). The point is that the initial meeting specified that neither rsync nor zsync would be allowed to use an internal copy of zlib. Yet rsync is still using one, zsync is still apparently not allowed in, and no-one wants to do anything about it but argue. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
On Tue, 2009-09-29 at 17:03 +0200, Jaroslav Reznik wrote: Hi! We, KDE SIG, are considering which backend should be default for Phonon in Fedora. Seems like it's not easy to agree on final decision @ KDE SIG meetings, we'd like to summarize what's the problem, some backends facts (please correct me, comment, add, etc.) and we'd like to hear comments from outer KDE SIG universe, from you, Fedora developers users, too. First question is which Phonon use - there are two actually - one is part of Qt, one is part of KDE. Upstream recommends building/packaging phonon from qt, and building/packaging backends separately. Some backends facts... GStreamer backend facts: * now default one in Fedora (F12, rawhide) * GStreamer is Fedora's default multimedia framework - better support from Fedora side? (PA, releases) * Phonon backend not as mature as Xine one - missing functionality It would help to note exactly what functionality is still missing with the gstreamer backend. Last time I dealt with this issue was around KDE 4.0 / 4.1 in Mandriva, at which point the gstreamer backend still had significant problems, such as being entirely unable to play audio CDs. My take on this issue would depend to quite some extent on the significance of the remaining functionality gap between gstreamer and xine backends. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090929 changes
On Tue, Sep 29, 2009 at 03:57:34PM +, Rawhide Report wrote: ocaml-cairo-1.2.0.cvs20080301-10.fc12.i686 requires ocaml(Gdk) = 0:55ef19f3e95d047e0df14bf67c04 ocaml-camlimages-3.0.1-11.fc12.i686 requires ocaml(Gdk) = 0:55ef19f3e95d047e0df14bf67c04 ocaml-camlimages-3.0.1-11.fc12.i686 requires ocaml(GDraw) = 0:1cec90246740aa7ee40aa16bee922301 ocaml-ocamlnet-2.2.9-14.fc12.i686 requires ocaml(GDraw) = 0:1cec90246740aa7ee40aa16bee922301 ocaml-ocamlnet-2.2.9-14.fc12.i686 requires ocaml(GdkEvent) = 0:e26b8dad95d4063101853aa65730fd2e ocaml-ocamlnet-2.2.9-14.fc12.i686 requires ocaml(Gdk) = 0:55ef19f3e95d047e0df14bf67c04 ocaml-ocamlnet-2.2.9-14.fc12.i686 requires ocaml(Gtk) = 0:8d7ac7453a17a1195bd20bde26127c45 ocaml-ocamlnet-2.2.9-14.fc12.i686 requires ocaml(GObj) = 0:1b90b109f84f92fa1ea43ba1b520406f Sorry, this was an accident - I meant to update it in F-13 only. Nevertheless ... It happened and the new version is just an incremental bugfix release, despite the large apparent bump in the version number. I've now rebuilt the packages above in F-12 and F-13. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: net-snmp soname bump in rawhide
On Tue, 2009-09-29 at 13:19 -0400, Seth Vidal wrote: On Tue, 29 Sep 2009, Jesse Keating wrote: On Tue, 2009-09-29 at 12:13 -0400, Josh Boyer wrote: Rawhide is still based on dist-f12. We have no cute name for dist-f13. Futurehide I expect that to be the name of a scifi book published by ToR whereas if it were published by Baen it would be Futurehide War: A Stony McJawline Adventure? Ahh, good to find someone to share sf book geek jokes with :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Fedora-packaging] Exemption for bundling local copy of system library?
On 09/29/2009 11:37 AM, Michel Alexandre Salim wrote: Hi, Oolite http://oolite.org is currently undergoing review, and a stumbling block is in its use of its own copy of libjs. An upstream developer is participating in the review and has a clear explanation for the rationale: https://bugzilla.redhat.com/show_bug.cgi?id=459211 libjs is not exposed to any network interfaces, so the risk is probably quite low -- the alternative is to wait until xulrunner 2.0 is released (the previous stable version has problems in its scripting mechanism and most third-party add-ons for Oolite do not work on it anymore. Would it be alright in this case to bundle libjs? I would argue no. The guidelines are written to apply to all libraries except with very limited exceptions to keep this from happening because security vulnerabilities are not limited to network facing code, suid code, or any other class that we've been able to identify. The libz vulnerability many years ago is the classic example of this. Many programs were embedding libz, many statically. When a security vulnerability in libz was discovered, we had to find all of those programs, remove the vulnerable library, patch any code that didn't work with the newer version, and rebuild all of those packages. This is not what you want to do when you are in the time-constrained situation of putting out a zero day update to the code. The statement that libjsis not exposed to the network is also not a guarantee that security problems will be low-impact on several counts: 1) Libraries in C can cause problems in unrelated sections of code because they can access memory directly. Sometimes this can lead to very bad exploits (especially in code with enhanced privileges), other times it is the first step for an attacker to look for other programs on your machine that are vulnerable to other sorts of attacks. 2) Libjs is used to run local user-installed scripts (as parts of expansion packs) only. Although libjs may not retrieve scripts directly from the network, it is definitely handling data of foreign origin. If I download an expansion pack because I saw a review that made it look really cool and then run it, I am exposing libjs to that code from a random source. If there were a buffer overflow in libjs and someone realized that OOList contains its own copy of libjs, they could try to craft an expansion pack that takes advantage of that fact. And it's probably premature to go to FESCo with this. Firefox does not use the system libjs.so. So you should find out if the spidermonkey maintainer is willing to compile with JS_C_STRINGS_ARE_UTF8. At present the only depending package I see is mediatomb so this might be the best option. Also note, it sounds like Oolite is updating to js-1.80 -- that's currently at rc1, not an actual release. You'll need to work with the js maintainer and make sure that that is okay as well. PS the no bundled libraries draft (http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries) does not clearly indicate which mailing list is to be used The actual decision is a FESCo decision. That would be tracked in their trac instance. But FPC people are going to have input on it which would be here. Everyone on fedora-devel-list has 2 cents to put in on these cases but very few of them seem to want to look at the problems that arise with bundling libraries and propose solutions so it's easy to be mislead into thinking that something's acceptable because it's easy rather than likely to be denied because there's no basis to grant an exception. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Sugar-devel] sugar-pippy dependencies
El Tue, 29-09-2009 a las 12:36 +, Aleksey Lim escribió: pygame and numpy are parts of Sugar Platform[1], at least for 0.84, so, the right question is should these pakcages be a part of SP-0.86 I guess +1 for both, since we have honey activities that are depend on these packages. In Sugar shell 0.82, the only thing that numpy was providing was a bit matrix. In 0.82, we replaced it with faster and lighter C code in sugar-base, and it was a big performance win. I suspect the #1 usecase for numpy is to compensate for lack of good array support in Python. Questions: 1) are there lighter-weight alternatives for the most popular uses of numpy? 1) how many of the existing activities actually depend on numpy? 2) would it be hard to remove this dependency from them? 3) Should we define a policy for deprecating components of the Sugar Platform in new revisions? All evolving standards need to find a balance between new features with old feature removal to avoid unbounded bloat. 4) Even if numpy is going to stay around for the Sugar Platform, could we remove it from Pippy and other core activities to save resources and allow shipping lighter weight live distros? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Sugar-devel] sugar-pippy dependencies
On Tue, Sep 29, 2009 at 9:10 PM, Bernie Innocenti ber...@codewiz.org wrote: El Tue, 29-09-2009 a las 12:36 +, Aleksey Lim escribió: pygame and numpy are parts of Sugar Platform[1], at least for 0.84, so, the right question is should these pakcages be a part of SP-0.86 I guess +1 for both, since we have honey activities that are depend on these packages. In Sugar shell 0.82, the only thing that numpy was providing was a bit matrix. In 0.82, we replaced it with faster and lighter C code in sugar-base, and it was a big performance win. I suspect the #1 usecase for numpy is to compensate for lack of good array support in Python. Questions: 1) are there lighter-weight alternatives for the most popular uses of numpy? 1) how many of the existing activities actually depend on numpy? A quick repo query gives me pippy and sugar-speak in the fedora repo. Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Sugar-devel] sugar-pippy dependencies
El Tue, 29-09-2009 a las 16:25 -0400, Benjamin M. Schwartz escribió: Bernie Innocenti wrote: 1) are there lighter-weight alternatives for the most popular uses of numpy? No. It has no competition, and is used by virtually every program that uses python and performs array manipulation. I think it would probably be part of the python standard library except for political issues (now mostly resolved). It's not used as much as you think: 1!ber...@giskard:~$ LANG=C rpm -e numpy error: Failed dependencies: numpy is needed by (installed) pygame-1.8.1-7.fc12.x86_64 ber...@giskard:~$ rpm -qa | grep python | wc -l 93 It's also one of the worst startup time offenders I've ever seen in Python: with hot caches, it takes 300ms on a fast computer (~2 seconds on an XO). A lot longer if you have to actually fetch it from disk along with its unique dependencies. 2) would it be hard to remove this dependency from them? Yes. Numpy provides high-speed math for python. high-speed *advanced* math functions. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
Lennart Poettering wrote: Uh. Nokia stands pretty firmly behind gst. As do most embedded folks. Behind GStreamer, sure. Behind Phonon (and thus also Phonon-GStreamer), not so much. They're currently using it, but there are people working on the Qt Mobility project talking about replacing Phonon with something else (another abstraction layer, again around native backends (GStreamer in the GNU/Linux case), I really don't see what the advantage would be over Phonon). Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Sugar-devel] sugar-pippy dependencies
On Tue, Sep 29, 2009 at 9:42 PM, Bernie Innocenti ber...@codewiz.org wrote: El Tue, 29-09-2009 a las 16:25 -0400, Benjamin M. Schwartz escribió: Bernie Innocenti wrote: 1) are there lighter-weight alternatives for the most popular uses of numpy? No. It has no competition, and is used by virtually every program that uses python and performs array manipulation. I think it would probably be part of the python standard library except for political issues (now mostly resolved). It's not used as much as you think: 1!ber...@giskard:~$ LANG=C rpm -e numpy error: Failed dependencies: numpy is needed by (installed) pygame-1.8.1-7.fc12.x86_64 ber...@giskard:~$ rpm -qa | grep python | wc -l 93 On a standard SoaS install unfortunately that is completely useless because of course .xo files have no dependency tracking so it only covers the few packages that are rpms. Of course if the rpm format was used the dep tracking would be easy :-D Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: sugar-pippy dependencies
On 09/29/2009 12:51 AM, Peter Robinson wrote: On Tue, Sep 29, 2009 at 2:33 AM, Bernie Innocenti ber...@codewiz.org wrote: Hello, the sugar-pippy rpm in Fedora depends on pygame, which is used by some of the examples. So far, so good, but pygame in turn depends on numpy, a 7.7MB package which a lot of huge dependencies such as atlas (11MB), libgfortran (1MB), blas (700KB) and python-nose (1MB). The rest of Sugar is now free of numpy, so it would be good if we could get rid of it completely. One quick solution would be splitting the problematic examples to a sugar-pippy-examples-extra package. Another possibility -- probably the cleanest -- would be splitting the optional classes surfarray and sndarray to a subpackage of pygame. The numpy dep issue was discussed on fedora-devel a while ago and I thought they were going to split the specific bit of numpy that depended on atlas et al out into a separate package. I was of the understanding that this had already been done. I admit I'm not following sugar and numpy discussions too closely so I might have missed it but I don't remember this. I do remember talking about removing the numpy dependency from pygtk because it dragged in atlas, et al and was only used by a single pygtk function. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Removing provide statement from an existing spec file
Le Mar 29 septembre 2009 17:42, Stefan Schulze Frielinghaus a écrit : Right. I was in doubt if the provide statement was/is really fine, so I wanted to clarify this. Also package naming guidelines do not apply to provides. FPC has even explicitely used the just stuff it in provides argument to refuse changes in package naming conventions -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: sugar-pippy dependencies
On Tue, Sep 29, 2009 at 9:45 PM, Toshio Kuratomi a.bad...@gmail.com wrote: On 09/29/2009 12:51 AM, Peter Robinson wrote: On Tue, Sep 29, 2009 at 2:33 AM, Bernie Innocenti ber...@codewiz.org wrote: Hello, the sugar-pippy rpm in Fedora depends on pygame, which is used by some of the examples. So far, so good, but pygame in turn depends on numpy, a 7.7MB package which a lot of huge dependencies such as atlas (11MB), libgfortran (1MB), blas (700KB) and python-nose (1MB). The rest of Sugar is now free of numpy, so it would be good if we could get rid of it completely. One quick solution would be splitting the problematic examples to a sugar-pippy-examples-extra package. Another possibility -- probably the cleanest -- would be splitting the optional classes surfarray and sndarray to a subpackage of pygame. The numpy dep issue was discussed on fedora-devel a while ago and I thought they were going to split the specific bit of numpy that depended on atlas et al out into a separate package. I was of the understanding that this had already been done. I admit I'm not following sugar and numpy discussions too closely so I might have missed it but I don't remember this. I do remember talking about removing the numpy dependency from pygtk because it dragged in atlas, et al and was only used by a single pygtk function. I remember that as well but at least with a quick repoquery (I might have got it wrong) it looks like the dependency is still there. Not sure what happened to the fix. Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: sugar-pippy dependencies
On 09/29/2009 01:52 PM, Peter Robinson wrote: On Tue, Sep 29, 2009 at 9:45 PM, Toshio Kuratomi a.bad...@gmail.com wrote: I admit I'm not following sugar and numpy discussions too closely so I might have missed it but I don't remember this. I do remember talking about removing the numpy dependency from pygtk because it dragged in atlas, et al and was only used by a single pygtk function. I remember that as well but at least with a quick repoquery (I might have got it wrong) it looks like the dependency is still there. Not sure what happened to the fix. Was that on F-11 or rawhide? I downloaded the pygtk2 package from rawhide and it looks fixed. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: sugar-pippy dependencies
On Tue, Sep 29, 2009 at 10:02 PM, Toshio Kuratomi a.bad...@gmail.com wrote: On 09/29/2009 01:52 PM, Peter Robinson wrote: On Tue, Sep 29, 2009 at 9:45 PM, Toshio Kuratomi a.bad...@gmail.com wrote: I admit I'm not following sugar and numpy discussions too closely so I might have missed it but I don't remember this. I do remember talking about removing the numpy dependency from pygtk because it dragged in atlas, et al and was only used by a single pygtk function. I remember that as well but at least with a quick repoquery (I might have got it wrong) it looks like the dependency is still there. Not sure what happened to the fix. Was that on F-11 or rawhide? I downloaded the pygtk2 package from rawhide and it looks fixed. rawhide, I think the numpy support was just dropped from pygtk2 as opposed to fixing the dependencies in numpy themselves. numpy still depends on atlas and various other stuff. I'm not sure what the impact of either changes are, I'd have to dig back through archives to find the thread. Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: sugar-pippy dependencies
On 09/29/2009 02:11 PM, Peter Robinson wrote: rawhide, I think the numpy support was just dropped from pygtk2 as opposed to fixing the dependencies in numpy themselves. numpy still depends on atlas and various other stuff. I'm not sure what the impact of either changes are, I'd have to dig back through archives to find the thread. Yep, this is what I remember the outcome of the thread being. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On 09/29/2009 05:43 PM, Jesse Keating wrote: On Tue, 2009-09-29 at 17:33 -0400, Steve Dickson wrote: Buyer Beware: A Major Change in NFS is about to happen Which means you're about a month too late in making it for Fedora 12. Please reconsider making this change, as we're /well/ past the Feature freeze, and since your package(s) are already branched for F-12/ you can make this change on devel/ only and target F-13. I thought today was the dead line... http://www.linux-archive.org/fedora-development/372823-all-features-need-100-beta-freeze-2009-09-29-a.html Plus all the kernel parts and the user level code have been in placed for a few months... it already to go... steved. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On Tue, 2009-09-29 at 17:52 -0400, Steve Dickson wrote: I thought today was the dead line... http://www.linux-archive.org/fedora-development/372823-all-features-need-100-beta-freeze-2009-09-29-a.html Plus all the kernel parts and the user level code have been in placed for a few months... it already to go... It was the deadline to be 100% complete with all the bugfixes, etc.. All those features had to be testable as of the Alpha freeze, and it sounds like yours wasn't. What I'm trying to prevent here is a surprise in the final release where suddenly tonnes of systems can't mount anymore and we have to scramble to revert the change or do more fixing. We've already seen two changes that were thought to be OK cause havoc in some of our most critical packages and processes. I'd like to not repeat that. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On Tue, 2009-09-29 at 17:52 -0400, Steve Dickson wrote: I thought today was the dead line... http://www.linux-archive.org/fedora-development/372823-all-features-need-100-beta-freeze-2009-09-29-a.html I should mention that Beta is the deadline to have the code in what we think is the final state, baring any glaring bugs, not a point to enable experimental code/settings for further experimentation. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On 09/29/2009 06:13 PM, Jesse Keating wrote: On Tue, 2009-09-29 at 17:52 -0400, Steve Dickson wrote: I thought today was the dead line... http://www.linux-archive.org/fedora-development/372823-all-features-need-100-beta-freeze-2009-09-29-a.html I should mention that Beta is the deadline to have the code in what we think is the final state, baring any glaring bugs, not a point to enable experimental code/settings for further experimentation. This is in the final state... its been a 18 month effort to get this accepted by upstream... At the end of the day, I was just following the rules that were deemed by that email and a number of earlier ones... I'm a bit dumbfound... steved. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Sugar-devel] sugar-pippy dependencies
On 09/29/2009 02:35 PM, Michel Alexandre Salim wrote: On Tue, Sep 29, 2009 at 4:10 PM, Bernie Innocentiber...@codewiz.org wrote: El Tue, 29-09-2009 a las 12:36 +, Aleksey Lim escribió: Questions: 1) are there lighter-weight alternatives for the most popular uses of numpy? How about numarray? http://www.stsci.edu/resources/software_hardware/numarray numarray is being phased out and replaced by numpy. STScI has migrated all of its software to use numpy, and the current release of stsci_python and STSDAS/TABLES uses numpy in place of numarray. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On Tue, Sep 29, 2009 at 06:21:35PM -0400, Steve Dickson wrote: On 09/29/2009 06:13 PM, Jesse Keating wrote: On Tue, 2009-09-29 at 17:52 -0400, Steve Dickson wrote: I thought today was the dead line... http://www.linux-archive.org/fedora-development/372823-all-features-need-100-beta-freeze-2009-09-29-a.html I should mention that Beta is the deadline to have the code in what we think is the final state, baring any glaring bugs, not a point to enable experimental code/settings for further experimentation. This is in the final state... its been a 18 month effort to get this accepted by upstream... At the end of the day, I was just following the rules that were deemed by that email and a number of earlier ones... I'm a bit dumbfound... I think that what we need, Steve, is some sort of information about what testing has happened up to this point that satisfies FESCo that this change the equivalent of moving the needle from 99% complete to 100% complete, as opposed to moving from 90% complete to 91% complete (with testing being the last 9%). -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Fedora-packaging] Exemption for bundling local copy of system library?
On 09-09-29 15:37:10, Toshio Kuratomi wrote: I would argue no. The guidelines are written to apply to all libraries except with very limited exceptions to keep this from happening because security vulnerabilities are not limited to network facing code, suid code, or any other class that we've been able to identify. The libz vulnerability many years ago is the classic example of this. Many programs were embedding libz, many statically. When a security vulnerability in libz was discovered, we had to find all of those programs, remove the vulnerable library, patch any code that didn't work with the newer version, and rebuild all of those packages. This is not what you want to do when you are in the time- constrained situation of putting out a zero day update to the code. ... If the number of exceptional packages is kept small, and the exeptions were to Provide private_libfoo (for each foo lib), then would it be manageable enough? At least it would be easy to find the broken packages, though they would still need to be fixed. -- TonyN.:' mailto:tonynel...@georgeanelson.com ' http://www.georgeanelson.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On 09/29/2009 06:55 PM, Paul W. Frields wrote: On Tue, Sep 29, 2009 at 06:21:35PM -0400, Steve Dickson wrote: On 09/29/2009 06:13 PM, Jesse Keating wrote: On Tue, 2009-09-29 at 17:52 -0400, Steve Dickson wrote: I thought today was the dead line... http://www.linux-archive.org/fedora-development/372823-all-features-need-100-beta-freeze-2009-09-29-a.html I should mention that Beta is the deadline to have the code in what we think is the final state, baring any glaring bugs, not a point to enable experimental code/settings for further experimentation. This is in the final state... its been a 18 month effort to get this accepted by upstream... At the end of the day, I was just following the rules that were deemed by that email and a number of earlier ones... I'm a bit dumbfound... I think that what we need, Steve, is some sort of information about what testing has happened up to this point that satisfies FESCo that this change the equivalent of moving the needle from 99% complete to 100% complete, as opposed to moving from 90% complete to 91% complete (with testing being the last 9%). Not a problem... I want to and will work closely with FESCo to make sure we know all the ins and outs of this change... believe me my slate is cleared for few weeks to be as responsive as possible for this new feature... In the end this will be a good thing... And I do apology for (unwittingly) spring this on everyone in such an unexpected way... But again, truly truly truly thought I was just following the development cycle that was laid out on the fedora-devel-announce list.. With all that said... Back to your point... What type of testing is done today on NFS and other File systems? Unfortunately I can not comment on a process I don't know about? steved. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On Tue, Sep 29, 2009 at 07:12:03PM -0400, Steve Dickson wrote: On 09/29/2009 06:55 PM, Paul W. Frields wrote: On Tue, Sep 29, 2009 at 06:21:35PM -0400, Steve Dickson wrote: On 09/29/2009 06:13 PM, Jesse Keating wrote: On Tue, 2009-09-29 at 17:52 -0400, Steve Dickson wrote: I thought today was the dead line... http://www.linux-archive.org/fedora-development/372823-all-features-need-100-beta-freeze-2009-09-29-a.html I should mention that Beta is the deadline to have the code in what we think is the final state, baring any glaring bugs, not a point to enable experimental code/settings for further experimentation. This is in the final state... its been a 18 month effort to get this accepted by upstream... At the end of the day, I was just following the rules that were deemed by that email and a number of earlier ones... I'm a bit dumbfound... I think that what we need, Steve, is some sort of information about what testing has happened up to this point that satisfies FESCo that this change the equivalent of moving the needle from 99% complete to 100% complete, as opposed to moving from 90% complete to 91% complete (with testing being the last 9%). Not a problem... I want to and will work closely with FESCo to make sure we know all the ins and outs of this change... believe me my slate is cleared for few weeks to be as responsive as possible for this new feature... In the end this will be a good thing... [...snip...] I want to be perfectly clear that I'm not sounding an all clear on this by any means. If your answer here means that this change hasn't been thoroughly tested, you're going to have a hard time convincing anyone that it should be turning over on Beta freeze day. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On Tue, 2009-09-29 at 19:16 -0400, Paul W. Frields wrote: I think that what we need, Steve, is some sort of information about what testing has happened up to this point that satisfies FESCo that this change the equivalent of moving the needle from 99% complete to 100% complete, as opposed to moving from 90% complete to 91% complete (with testing being the last 9%). Not a problem... I want to and will work closely with FESCo to make sure we know all the ins and outs of this change... believe me my slate is cleared for few weeks to be as responsive as possible for this new feature... In the end this will be a good thing... [...snip...] I want to be perfectly clear that I'm not sounding an all clear on this by any means. If your answer here means that this change hasn't been thoroughly tested, you're going to have a hard time convincing anyone that it should be turning over on Beta freeze day. Well Steve, obviously some testing had to be done right? You wouldn't change filesystem things without testing it, or else how would you know if it was successful or not? My main concern is with installer, installing from NFS shares from older servers, say RHEL5. How will anaconda handle mounting? Will there be odd errors that are difficult to figure out? Has this been tested in the anaconda environment at all? -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) identi.ca (http://identi.ca/jkeating) signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On 09/29/2009 07:16 PM, Paul W. Frields wrote: On Tue, Sep 29, 2009 at 07:12:03PM -0400, Steve Dickson wrote: On 09/29/2009 06:55 PM, Paul W. Frields wrote: On Tue, Sep 29, 2009 at 06:21:35PM -0400, Steve Dickson wrote: On 09/29/2009 06:13 PM, Jesse Keating wrote: On Tue, 2009-09-29 at 17:52 -0400, Steve Dickson wrote: I thought today was the dead line... http://www.linux-archive.org/fedora-development/372823-all-features-need-100-beta-freeze-2009-09-29-a.html I should mention that Beta is the deadline to have the code in what we think is the final state, baring any glaring bugs, not a point to enable experimental code/settings for further experimentation. This is in the final state... its been a 18 month effort to get this accepted by upstream... At the end of the day, I was just following the rules that were deemed by that email and a number of earlier ones... I'm a bit dumbfound... I think that what we need, Steve, is some sort of information about what testing has happened up to this point that satisfies FESCo that this change the equivalent of moving the needle from 99% complete to 100% complete, as opposed to moving from 90% complete to 91% complete (with testing being the last 9%). Not a problem... I want to and will work closely with FESCo to make sure we know all the ins and outs of this change... believe me my slate is cleared for few weeks to be as responsive as possible for this new feature... In the end this will be a good thing... [...snip...] I want to be perfectly clear that I'm not sounding an all clear on this by any means. If your answer here means that this change hasn't been thoroughly tested, you're going to have a hard time convincing anyone that it should be turning over on Beta freeze day. By no means did I interpret that at all... but here lies the problem... I had no idea I would have to convenience *anybody* of *anything* because I thought I made the dead line... again all following was the schedule in: http://www.linux-archive.org/fedora-development/372823-all-features-need-100-beta-freeze-2009-09-29-a.html And Today I am %100 finished... Please point out which part of that did I misinterpret, because the last thing I want to do is cause problems... steved. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On Tue, 29 Sep 2009, Steve Dickson wrote: On 09/29/2009 07:16 PM, Paul W. Frields wrote: On Tue, Sep 29, 2009 at 07:12:03PM -0400, Steve Dickson wrote: On 09/29/2009 06:55 PM, Paul W. Frields wrote: On Tue, Sep 29, 2009 at 06:21:35PM -0400, Steve Dickson wrote: On 09/29/2009 06:13 PM, Jesse Keating wrote: On Tue, 2009-09-29 at 17:52 -0400, Steve Dickson wrote: I thought today was the dead line... http://www.linux-archive.org/fedora-development/372823-all-features-need-100-beta-freeze-2009-09-29-a.html I should mention that Beta is the deadline to have the code in what we think is the final state, baring any glaring bugs, not a point to enable experimental code/settings for further experimentation. This is in the final state... its been a 18 month effort to get this accepted by upstream... At the end of the day, I was just following the rules that were deemed by that email and a number of earlier ones... I'm a bit dumbfound... I think that what we need, Steve, is some sort of information about what testing has happened up to this point that satisfies FESCo that this change the equivalent of moving the needle from 99% complete to 100% complete, as opposed to moving from 90% complete to 91% complete (with testing being the last 9%). Not a problem... I want to and will work closely with FESCo to make sure we know all the ins and outs of this change... believe me my slate is cleared for few weeks to be as responsive as possible for this new feature... In the end this will be a good thing... [...snip...] I want to be perfectly clear that I'm not sounding an all clear on this by any means. If your answer here means that this change hasn't been thoroughly tested, you're going to have a hard time convincing anyone that it should be turning over on Beta freeze day. By no means did I interpret that at all... but here lies the problem... I had no idea I would have to convenience *anybody* of *anything* because I thought I made the dead line... again all following was the schedule in: http://www.linux-archive.org/fedora-development/372823-all-features-need-100-beta-freeze-2009-09-29-a.html And Today I am %100 finished... Please point out which part of that did I misinterpret, because the last thing I want to do is cause problems... Because we do seem to fight this problem every release. Was anyone else confused about when the deadline was? It seems very clear to me, on several occasions, when features needed to be in by. What more could we have done to make this more clear? I understand what that one email says, but there's several others that clarify. -Mike -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
Steve Dickson said the following on 09/29/2009 04:35 PM Pacific Time: On 09/29/2009 07:16 PM, Paul W. Frields wrote: On Tue, Sep 29, 2009 at 07:12:03PM -0400, Steve Dickson wrote: On 09/29/2009 06:55 PM, Paul W. Frields wrote: On Tue, Sep 29, 2009 at 06:21:35PM -0400, Steve Dickson wrote: On 09/29/2009 06:13 PM, Jesse Keating wrote: On Tue, 2009-09-29 at 17:52 -0400, Steve Dickson wrote: I thought today was the dead line... http://www.linux-archive.org/fedora-development/372823-all-features-need-100-beta-freeze-2009-09-29-a.html I should mention that Beta is the deadline to have the code in what we think is the final state, baring any glaring bugs, not a point to enable experimental code/settings for further experimentation. This is in the final state... its been a 18 month effort to get this accepted by upstream... At the end of the day, I was just following the rules that were deemed by that email and a number of earlier ones... I'm a bit dumbfound... I think that what we need, Steve, is some sort of information about what testing has happened up to this point that satisfies FESCo that this change the equivalent of moving the needle from 99% complete to 100% complete, as opposed to moving from 90% complete to 91% complete (with testing being the last 9%). Not a problem... I want to and will work closely with FESCo to make sure we know all the ins and outs of this change... believe me my slate is cleared for few weeks to be as responsive as possible for this new feature... In the end this will be a good thing... [...snip...] I want to be perfectly clear that I'm not sounding an all clear on this by any means. If your answer here means that this change hasn't been thoroughly tested, you're going to have a hard time convincing anyone that it should be turning over on Beta freeze day. By no means did I interpret that at all... but here lies the problem... I had no idea I would have to convenience *anybody* of *anything* because I thought I made the dead line... again all following was the schedule in: http://www.linux-archive.org/fedora-development/372823-all-features-need-100-beta-freeze-2009-09-29-a.html And Today I am %100 finished... Please point out which part of that did I misinterpret, because the last thing I want to do is cause problems... steved. https://www.redhat.com/archives/fedora-devel-announce/2009-July/msg00027.html Many of us were assuming that testable and significantly complete would be enough to imply that a change like this should be done so it could be tested during the Alpha. How should we word things differently in the future so it is clearer? Thanks, John -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On 09/29/2009 07:52 PM, Mike McGrath wrote: By no means did I interpret that at all... but here lies the problem... I had no idea I would have to convenience *anybody* of *anything* because I thought I made the dead line... again all following was the schedule in: http://www.linux-archive.org/fedora-development/372823-all-features-need-100-beta-freeze-2009-09-29-a.html And Today I am %100 finished... Please point out which part of that did I misinterpret, because the last thing I want to do is cause problems... Because we do seem to fight this problem every release. Was anyone else confused about when the deadline was? It seems very clear to me, on several occasions, when features needed to be in by. What dead line did I miss?? The deadline in above email said to be %100 by today... I am %100 done today... Believe I wish I was %100 percent done two weeks ago... Life would have much easier... What more could we have done to make this more clear? I understand what that one email says, but there's several others that clarify. This is by far the best question asked so far... I have thought about this since I've gotten this (very unexpected) reaction... Please, if you don't mind, which emails are you referring to, because I really want to know what I missed and how I missed... steved. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On 09/29/2009 05:38 PM, Steve Dickson wrote: On 09/29/2009 08:17 PM, John Poelstra wrote: [...snip...] I want to be perfectly clear that I'm not sounding an all clear on this by any means. If your answer here means that this change hasn't been thoroughly tested, you're going to have a hard time convincing anyone that it should be turning over on Beta freeze day. By no means did I interpret that at all... but here lies the problem... I had no idea I would have to convenience *anybody* of *anything* because I thought I made the dead line... again all following was the schedule in: http://www.linux-archive.org/fedora-development/372823-all-features-need-100-beta-freeze-2009-09-29-a.html And Today I am %100 finished... Please point out which part of that did I misinterpret, because the last thing I want to do is cause problems... steved. Thanks, John https://www.redhat.com/archives/fedora-devel-announce/2009-July/msg00027.html Many of us were assuming that testable and significantly complete would be enough to imply that a change like this should be done so it could be tested during the Alpha. How should we word things differently in the future so it is clearer? Again, John, that is a wonderful question... From my perspective I had my head down working as hard as I could to make this deadline... I knew about the alpha deadline and this dealing... I my past, added things of this size in a beta release was actually common.. In alpha release you get the software married to the hardware (i.e. barely booting) and in beta release you added everything else... Now the post beta release is when the door close... nothing but bug fixes.. One thing I think is unclear this cycle is the usage of the word Beta. It's been said many times that beta is not really beta but actually final freeze. For instance: If all goes as planned the Beta (previously known as Final Development) Freeze in the message steved linked to. And yet, no one actually expects that beta is the final development freeze. Maybe we should just give up and not use the beta moniker for it. As inaccurate as it is, release candidate is a *better inaccuracy* in terms of communicating to developers. Developers understand that by release candidate we're going to be very tough about getting changes in, even if they appear to improve the experience. Some things will just have to be deferred after a release candidate is out the door. The downside of release candidate, as Jesse has pointed out before, is that it communicates the wrong thing to end-users. There's zero chance that this cut is going to be the absolute final set of bits that we use on release day so from an end-user perspective, it's not a release candidate. One possibility is to have a beta1 at feature freeze and a beta2 now. This helps developers realize that nothing but bugfixes should be going in from feature freeze on but lets end user's know that the release we're making now is still not finished. It still doesn't give the sense of urgency and finality that release candidate does, though, so I'm not sure if that's enough. Another thing that seems to be apparent in steved's complaint is that what the expectations for Final Feature Freeze (in July) are not clear enough. What is meant by testable? It seems that we mean, the Feature should be in, enabled, and in final form at that point. We want to be able to do integration testing from that point forward. That means we're no longer testing the Feature in isolation, but as part of the whole experience of installing and running the distro. Bugfixes can be applied but nothing that changes the basic shape or architecture of the distro as a whole. Plainly, changing the default from nfsv3 to nfsv4 should happen at Feature Freeze rather than now for that testing to be performed. But there's other meanings of testable. I'm sure that steved considered the Feature testable at Feature Freeze... he just wasn't applying the idea that it needed to be testable as part of the whole distro experience. Perhaps we need to list some examples of things that should not happen after Feature Freeze as well as expectation of what should happen. Examples of what to do and not do from this point forward: Do: Have something testable Do: Have the the feature significantly complete Do: submit bugfixes Do not: Enable the feature by default Do not: Make changes that cause other software to have to make changes et al. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
Once upon a time, Steve Dickson ste...@redhat.com said: On the server (Which is suggested): * Add the following entry to the /etc/exports file: / *(ro,fsid=0) Note: 'fsid=0' is explained in the exports(5) man pages. The suggested solution is to change your NFS servers (that work just fine with other clients today) to export the root filesystem to everybody? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On Tue, Sep 29, 2009 at 8:15 PM, Steve Dickson ste...@redhat.com wrote: My main concern is with installer, installing from NFS shares from older servers, say RHEL5. How will anaconda handle mounting? Will there be odd errors that are difficult to figure out? Has this been tested in the anaconda environment at all? This issue is this... when the the F12 does a mount to a linux server and that linux server is *not* configured with a / *(ro,fsid=0) export, the mount will fail with ENOENT (or No such file or directory). If the server does have that export, things will work as expected... So my advice is to added that one line to your rhel5 server and every thing should as expected... or may even better... ;-) Another workaround is to added the '-o v3' mount options... would that be hard? Why not just see the error and fall back and try v3 programatically rather than forcing that upon unsuspecting users? If someone explicitly specifies v4, then sure, if that fails, it should fail. But if they don't, we should be forgiving in what we do rather than giving cryptic error messages. How will anaconda handle mounting? I don't know since I believe anaconda has its own mounting code so it does its own thing... and in the end that will mostly likely work, since that code didn't change... anaconda hasn't been using its own mounting code for several releases now. The change to force v3 could be done, but that then makes things different from the real system which is something that's been trying to be avoided. - Jeremy -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On 09/29/2009 09:42 PM, Chris Adams wrote: Once upon a time, Steve Dickson ste...@redhat.com said: On the server (Which is suggested): * Add the following entry to the /etc/exports file: / *(ro,fsid=0) Note: 'fsid=0' is explained in the exports(5) man pages. The suggested solution is to change your NFS servers (that work just fine with other clients today) to export the root filesystem to everybody? Unfortunately the answer to your question yes... With version 4 there is this concept of a pseudo root. Which meanings one can define, through exports, what the root of an export can be. Which is a good idea because you can define /export as the root, and nothing above /export can be accessed... So the idea was to use 'fsid=0' to define the V4 root of the exports. Which, in theory is a good idea because you can define the namespace the client have access to. A feature, I believe, is not available in any other NFS implementation... But... The problem is the V4 protocol requires a pseudo root to exist. So with Linux servers, if the fsid=0 export does not exist, the mount will die with ENOENT (or 'No such file or directory'). Other NFS implementation decided not to support a definable pseudo roots and they just made, under the covers, their '/' as the pseudo root, along with the appropriate protections. With F-12, I have added code to both the kernel and nfs-utils that will do both. Allow the 'fsid=0' export to define the pseudo root and make '/' the pseudo root (with the appropriate protections) when there is not an fsid=0 entry. So Yes, one work around to make F-12 mounts work with Linux servers is to define a pseudo root on the server with a fsid=0 export. But if that is not an option, you can make the F12 clients only use V3 mount (which would avoid the problem, but not take advantage of the V4 protocol) by set either setting the '-o v3' mount option or set the Nfsvers=3 in the new /etc/nfsmount.conf file (which would make all mounts from that machine v3 mounts). I hope this helped... steved. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On 09/29/2009 09:21 PM, Toshio Kuratomi wrote: One thing I think is unclear this cycle is the usage of the word Beta. It's been said many times that beta is not really beta but actually final freeze. For instance: If all goes as planned the Beta (previously known as Final Development) Freeze in the message steved linked to. And yet, no one actually expects that beta is the final development freeze. Maybe we should just give up and not use the beta moniker for it. As inaccurate as it is, release candidate is a *better inaccuracy* in terms of communicating to developers. Developers understand that by release candidate we're going to be very tough about getting changes in, even if they appear to improve the experience. Some things will just have to be deferred after a release candidate is out the door. In the kernel world they have a number of RC releases... As the number increases the window of opportunity closes... and I believe after a certain rc release, no new features are allowed.. One possibility is to have a beta1 at feature freeze and a beta2 now. This helps developers realize that nothing but bugfixes should be going in from feature freeze on but lets end user's know that the release we're making now is still not finished. It still doesn't give the sense of urgency and finality that release candidate does, though, so I'm not sure if that's enough. Yeah, agree with this... beta1 or beta2 meanings nothing.. is still a beta... Another thing that seems to be apparent in steved's complaint is that what the expectations for Final Feature Freeze (in July) are not clear enough. What is meant by testable? It seems that we mean, the Feature should be in, enabled, and in final form at that point. Right or wrong.. I took Final Feature Freeze as the last chance of getting a feature into F12.. And I will be the first to admit I do not read all the rule and regulations of all the steps of a release... I look at dates.. When is the alpha and when is the beta. After a beta release I don't even try to get anything new in, just bug fixes... We want to be able to do integration testing from that point forward. That means we're no longer testing the Feature in isolation, but as part of the whole experience of installing and running the distro. Bugfixes can be applied but nothing that changes the basic shape or architecture of the distro as a whole. Plainly, changing the default from nfsv3 to nfsv4 should happen at Feature Freeze rather than now for that testing to be performed. But there's other meanings of testable. I'm sure that steved considered the Feature testable at Feature Freeze... he just wasn't applying the idea that it needed to be testable as part of the whole distro experience. This issue for me was terminology As I said before, I took Feature Freeze as the day I had to get my feature in and approved... after that I figured I had a number of release deadline to the code in... Perhaps we need to list some examples of things that should not happen after Feature Freeze as well as expectation of what should happen. Examples of what to do and not do from this point forward: Do: Have something testable Do: Have the the feature significantly complete Do: submit bugfixes Do not: Enable the feature by default Do not: Make changes that cause other software to have to make changes Again from my prospective, if it was required to get kernel changes, including any and all packages (ala nfs-utils, udev, hal) that effect those kernel changes that would be a bit more clearer... steved. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Packaging Webmin for Fedora 11+
2009/9/29 Christoph Wickert christoph.wick...@googlemail.com Dunno, maybe the fact that webmin is a weapon of mass destruction. ;) Afairr it is/was one. Bring it to fedora won't be a good idea?! -- Josephine Fine Tannhäuser 2.6.29.6-213.fc11.i586 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
On Wed, Sep 30, 2009 at 8:11 AM, Lennart Poettering mzerq...@0pointer.de wrote: Do I hear an I told you so!? Abstractionitis is an illness, not a remedy. Aren't you the pulseaudio developer? /runs and hides -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Where is Callum Lerwick / seg?
On Wed, Sep 23, 2009 at 11:53 AM, Jason L Tibbitts III ti...@math.uh.edu wrote: I know that Callum has in the past had periods where he is very busy. Given that he's asked for assistance before, and that no reasonable maintainer wouldn't want help from experienced packagers when busy, I went ahead and approved agoode and rdieter's requests for watchbugzilla, watchcommits and commit privileges on the openjpeg package. I did not approve oliver's requests as he only requested commit access without asking for watchbugzilla or watchcommits, which I don't think it a terribly good idea. I also did not approve the requests for approveacls, just in case Callum still wishes to maintain control over that. Yes, my internet access and time has become limited, and I'm really too ADHD for boring old long term maintenance anyway, so all my packages should probably just be orphaned at this point. I've actually been in something of a, err, one-third life crisis and am considering uprooting myself, getting the hell out of the midwest and moving to the bay area or something... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rpms/perl-Locale-Maketext-Gettext/devel import.log, NONE, 1.1 perl-Locale-Maketext-Gettext.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: rlandmann
Update of /cvs/pkgs/rpms/perl-Locale-Maketext-Gettext/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv8074/devel
Modified Files:
.cvsignore sources
Added Files:
import.log perl-Locale-Maketext-Gettext.spec
Log Message:
* Mon Sep 21 2009 Rüdiger Landmann rland...@redhat.com 1.27-2
- added BuildRequires: perl(Test::More) and BuildRequires: perl(Test::Pod)
* Mon Sep 07 2009 Rüdiger Landmann rland...@redhat.com 1.27-1
- Specfile autogenerated by cpanspec 1.78.
--- NEW FILE import.log ---
perl-Locale-Maketext-Gettext-1_27-2_fc11:HEAD:perl-Locale-Maketext-Gettext-1.27-2.fc11.src.rpm:1253910438
--- NEW FILE perl-Locale-Maketext-Gettext.spec ---
Name: perl-Locale-Maketext-Gettext
Version:1.27
Release:2%{?dist}
Summary:Joins the gettext and Maketext frameworks
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Locale-Maketext-Gettext/
Source0:
http://www.cpan.org/authors/id/I/IM/IMACAT/Locale-Maketext-Gettext-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Module::Build)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
Locale::Maketext::Gettext joins the GNU gettext and Maketext frameworks. It
is a subclass of Locale::Maketext(3) that follows the way GNU gettext
works. It works seamlessly, both in the sense of GNU gettext and Maketext.
As a result, you enjoy both their advantages, and get rid of both their
problems, too.
%prep
%setup -q -n Locale-Maketext-Gettext-%{version}
%build
%{__perl} Build.PL installdirs=vendor
./Build
%install
rm -rf $RPM_BUILD_ROOT
./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
rm -f debugsources.list debugfiles.list debuglinks.list
./Build test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Artistic BUGS Changes COPYING README THANKS TODO
%{perl_vendorlib}/*
%{_mandir}/man3/*
%{_bindir}/maketext
%{_mandir}/man1/*
%changelog
* Mon Sep 21 2009 Rüdiger Landmann rland...@redhat.com 1.27-2
- added BuildRequires: perl(Test::More) and BuildRequires: perl(Test::Pod)
* Mon Sep 07 2009 Rüdiger Landmann rland...@redhat.com 1.27-1
- Specfile autogenerated by cpanspec 1.78.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Locale-Maketext-Gettext/devel/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 25 Sep 2009 16:34:55 - 1.1
+++ .cvsignore 25 Sep 2009 20:30:47 - 1.2
@@ -0,0 +1 @@
+Locale-Maketext-Gettext-1.27.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Locale-Maketext-Gettext/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 25 Sep 2009 16:34:55 - 1.1
+++ sources 25 Sep 2009 20:30:47 - 1.2
@@ -0,0 +1 @@
+58019c37c8ad1c4526476a7fb98b64c6 Locale-Maketext-Gettext-1.27.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Locale-Maketext-Gettext/F-11 import.log, NONE, 1.1 perl-Locale-Maketext-Gettext.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: rlandmann
Update of /cvs/pkgs/rpms/perl-Locale-Maketext-Gettext/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv20944/F-11
Modified Files:
.cvsignore sources
Added Files:
import.log perl-Locale-Maketext-Gettext.spec
Log Message:
* Mon Sep 21 2009 Rüdiger Landmann rland...@redhat.com 1.27-2
- added BuildRequires: perl(Test::More) and BuildRequires: perl(Test::Pod)
* Mon Sep 07 2009 Rüdiger Landmann rland...@redhat.com 1.27-1
- Specfile autogenerated by cpanspec 1.78.
--- NEW FILE import.log ---
perl-Locale-Maketext-Gettext-1_27-2_fc11:F-11:perl-Locale-Maketext-Gettext-1.27-2.fc11.src.rpm:1253912782
--- NEW FILE perl-Locale-Maketext-Gettext.spec ---
Name: perl-Locale-Maketext-Gettext
Version:1.27
Release:2%{?dist}
Summary:Joins the gettext and Maketext frameworks
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Locale-Maketext-Gettext/
Source0:
http://www.cpan.org/authors/id/I/IM/IMACAT/Locale-Maketext-Gettext-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Module::Build)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
Locale::Maketext::Gettext joins the GNU gettext and Maketext frameworks. It
is a subclass of Locale::Maketext(3) that follows the way GNU gettext
works. It works seamlessly, both in the sense of GNU gettext and Maketext.
As a result, you enjoy both their advantages, and get rid of both their
problems, too.
%prep
%setup -q -n Locale-Maketext-Gettext-%{version}
%build
%{__perl} Build.PL installdirs=vendor
./Build
%install
rm -rf $RPM_BUILD_ROOT
./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
rm -f debugsources.list debugfiles.list debuglinks.list
./Build test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Artistic BUGS Changes COPYING README THANKS TODO
%{perl_vendorlib}/*
%{_mandir}/man3/*
%{_bindir}/maketext
%{_mandir}/man1/*
%changelog
* Mon Sep 21 2009 Rüdiger Landmann rland...@redhat.com 1.27-2
- added BuildRequires: perl(Test::More) and BuildRequires: perl(Test::Pod)
* Mon Sep 07 2009 Rüdiger Landmann rland...@redhat.com 1.27-1
- Specfile autogenerated by cpanspec 1.78.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Locale-Maketext-Gettext/F-11/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 25 Sep 2009 16:34:55 - 1.1
+++ .cvsignore 25 Sep 2009 21:08:43 - 1.2
@@ -0,0 +1 @@
+Locale-Maketext-Gettext-1.27.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Locale-Maketext-Gettext/F-11/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 25 Sep 2009 16:34:55 - 1.1
+++ sources 25 Sep 2009 21:08:44 - 1.2
@@ -0,0 +1 @@
+58019c37c8ad1c4526476a7fb98b64c6 Locale-Maketext-Gettext-1.27.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Locale-Maketext-Gettext/F-12 import.log, NONE, 1.1 perl-Locale-Maketext-Gettext.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: rlandmann
Update of /cvs/pkgs/rpms/perl-Locale-Maketext-Gettext/F-12
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv26684/F-12
Modified Files:
.cvsignore sources
Added Files:
import.log perl-Locale-Maketext-Gettext.spec
Log Message:
* Mon Sep 21 2009 Rüdiger Landmann rland...@redhat.com 1.27-2
- added BuildRequires: perl(Test::More) and BuildRequires: perl(Test::Pod)
* Mon Sep 07 2009 Rüdiger Landmann rland...@redhat.com 1.27-1
- Specfile autogenerated by cpanspec 1.78.
--- NEW FILE import.log ---
perl-Locale-Maketext-Gettext-1_27-2_fc11:F-12:perl-Locale-Maketext-Gettext-1.27-2.fc11.src.rpm:1253913443
--- NEW FILE perl-Locale-Maketext-Gettext.spec ---
Name: perl-Locale-Maketext-Gettext
Version:1.27
Release:2%{?dist}
Summary:Joins the gettext and Maketext frameworks
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Locale-Maketext-Gettext/
Source0:
http://www.cpan.org/authors/id/I/IM/IMACAT/Locale-Maketext-Gettext-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Module::Build)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
Locale::Maketext::Gettext joins the GNU gettext and Maketext frameworks. It
is a subclass of Locale::Maketext(3) that follows the way GNU gettext
works. It works seamlessly, both in the sense of GNU gettext and Maketext.
As a result, you enjoy both their advantages, and get rid of both their
problems, too.
%prep
%setup -q -n Locale-Maketext-Gettext-%{version}
%build
%{__perl} Build.PL installdirs=vendor
./Build
%install
rm -rf $RPM_BUILD_ROOT
./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
rm -f debugsources.list debugfiles.list debuglinks.list
./Build test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Artistic BUGS Changes COPYING README THANKS TODO
%{perl_vendorlib}/*
%{_mandir}/man3/*
%{_bindir}/maketext
%{_mandir}/man1/*
%changelog
* Mon Sep 21 2009 Rüdiger Landmann rland...@redhat.com 1.27-2
- added BuildRequires: perl(Test::More) and BuildRequires: perl(Test::Pod)
* Mon Sep 07 2009 Rüdiger Landmann rland...@redhat.com 1.27-1
- Specfile autogenerated by cpanspec 1.78.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Locale-Maketext-Gettext/F-12/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 25 Sep 2009 16:34:55 - 1.1
+++ .cvsignore 25 Sep 2009 21:18:42 - 1.2
@@ -0,0 +1 @@
+Locale-Maketext-Gettext-1.27.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Locale-Maketext-Gettext/F-12/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 25 Sep 2009 16:34:55 - 1.1
+++ sources 25 Sep 2009 21:18:42 - 1.2
@@ -0,0 +1 @@
+58019c37c8ad1c4526476a7fb98b64c6 Locale-Maketext-Gettext-1.27.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Locale-Maketext-Gettext/F-10 import.log, NONE, 1.1 perl-Locale-Maketext-Gettext.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: rlandmann
Update of /cvs/pkgs/rpms/perl-Locale-Maketext-Gettext/F-10
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv29841/F-10
Modified Files:
.cvsignore sources
Added Files:
import.log perl-Locale-Maketext-Gettext.spec
Log Message:
* Mon Sep 21 2009 Rüdiger Landmann rland...@redhat.com 1.27-2
- added BuildRequires: perl(Test::More) and BuildRequires: perl(Test::Pod)
* Mon Sep 07 2009 Rüdiger Landmann rland...@redhat.com 1.27-1
- Specfile autogenerated by cpanspec 1.78.
--- NEW FILE import.log ---
perl-Locale-Maketext-Gettext-1_27-2_fc11:F-10:perl-Locale-Maketext-Gettext-1.27-2.fc11.src.rpm:1253913966
--- NEW FILE perl-Locale-Maketext-Gettext.spec ---
Name: perl-Locale-Maketext-Gettext
Version:1.27
Release:2%{?dist}
Summary:Joins the gettext and Maketext frameworks
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Locale-Maketext-Gettext/
Source0:
http://www.cpan.org/authors/id/I/IM/IMACAT/Locale-Maketext-Gettext-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Module::Build)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
Locale::Maketext::Gettext joins the GNU gettext and Maketext frameworks. It
is a subclass of Locale::Maketext(3) that follows the way GNU gettext
works. It works seamlessly, both in the sense of GNU gettext and Maketext.
As a result, you enjoy both their advantages, and get rid of both their
problems, too.
%prep
%setup -q -n Locale-Maketext-Gettext-%{version}
%build
%{__perl} Build.PL installdirs=vendor
./Build
%install
rm -rf $RPM_BUILD_ROOT
./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
rm -f debugsources.list debugfiles.list debuglinks.list
./Build test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Artistic BUGS Changes COPYING README THANKS TODO
%{perl_vendorlib}/*
%{_mandir}/man3/*
%{_bindir}/maketext
%{_mandir}/man1/*
%changelog
* Mon Sep 21 2009 Rüdiger Landmann rland...@redhat.com 1.27-2
- added BuildRequires: perl(Test::More) and BuildRequires: perl(Test::Pod)
* Mon Sep 07 2009 Rüdiger Landmann rland...@redhat.com 1.27-1
- Specfile autogenerated by cpanspec 1.78.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Locale-Maketext-Gettext/F-10/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 25 Sep 2009 16:34:55 - 1.1
+++ .cvsignore 25 Sep 2009 21:27:36 - 1.2
@@ -0,0 +1 @@
+Locale-Maketext-Gettext-1.27.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Locale-Maketext-Gettext/F-10/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 25 Sep 2009 16:34:55 - 1.1
+++ sources 25 Sep 2009 21:27:36 - 1.2
@@ -0,0 +1 @@
+58019c37c8ad1c4526476a7fb98b64c6 Locale-Maketext-Gettext-1.27.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Locale-Maketext-Gettext/EL-5 import.log, NONE, 1.1 perl-Locale-Maketext-Gettext.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: rlandmann
Update of /cvs/pkgs/rpms/perl-Locale-Maketext-Gettext/EL-5
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv782/EL-5
Modified Files:
.cvsignore sources
Added Files:
import.log perl-Locale-Maketext-Gettext.spec
Log Message:
* Mon Sep 21 2009 Rüdiger Landmann rland...@redhat.com 1.27-2
- added BuildRequires: perl(Test::More) and BuildRequires: perl(Test::Pod)
* Mon Sep 07 2009 Rüdiger Landmann rland...@redhat.com 1.27-1
- Specfile autogenerated by cpanspec 1.78.
--- NEW FILE import.log ---
perl-Locale-Maketext-Gettext-1_27-2_fc11:EL-5:perl-Locale-Maketext-Gettext-1.27-2.fc11.src.rpm:1253914796
--- NEW FILE perl-Locale-Maketext-Gettext.spec ---
Name: perl-Locale-Maketext-Gettext
Version:1.27
Release:2%{?dist}
Summary:Joins the gettext and Maketext frameworks
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Locale-Maketext-Gettext/
Source0:
http://www.cpan.org/authors/id/I/IM/IMACAT/Locale-Maketext-Gettext-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Module::Build)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
Locale::Maketext::Gettext joins the GNU gettext and Maketext frameworks. It
is a subclass of Locale::Maketext(3) that follows the way GNU gettext
works. It works seamlessly, both in the sense of GNU gettext and Maketext.
As a result, you enjoy both their advantages, and get rid of both their
problems, too.
%prep
%setup -q -n Locale-Maketext-Gettext-%{version}
%build
%{__perl} Build.PL installdirs=vendor
./Build
%install
rm -rf $RPM_BUILD_ROOT
./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
rm -f debugsources.list debugfiles.list debuglinks.list
./Build test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Artistic BUGS Changes COPYING README THANKS TODO
%{perl_vendorlib}/*
%{_mandir}/man3/*
%{_bindir}/maketext
%{_mandir}/man1/*
%changelog
* Mon Sep 21 2009 Rüdiger Landmann rland...@redhat.com 1.27-2
- added BuildRequires: perl(Test::More) and BuildRequires: perl(Test::Pod)
* Mon Sep 07 2009 Rüdiger Landmann rland...@redhat.com 1.27-1
- Specfile autogenerated by cpanspec 1.78.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Locale-Maketext-Gettext/EL-5/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 25 Sep 2009 16:34:55 - 1.1
+++ .cvsignore 25 Sep 2009 21:41:16 - 1.2
@@ -0,0 +1 @@
+Locale-Maketext-Gettext-1.27.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Locale-Maketext-Gettext/EL-5/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 25 Sep 2009 16:34:55 - 1.1
+++ sources 25 Sep 2009 21:41:16 - 1.2
@@ -0,0 +1 @@
+58019c37c8ad1c4526476a7fb98b64c6 Locale-Maketext-Gettext-1.27.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Locale-Maketext-Gettext/EL-4 import.log, NONE, 1.1 perl-Locale-Maketext-Gettext.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: rlandmann
Update of /cvs/pkgs/rpms/perl-Locale-Maketext-Gettext/EL-4
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv7041/EL-4
Modified Files:
.cvsignore sources
Added Files:
import.log perl-Locale-Maketext-Gettext.spec
Log Message:
* Mon Sep 21 2009 Rüdiger Landmann rland...@redhat.com 1.27-2
- added BuildRequires: perl(Test::More) and BuildRequires: perl(Test::Pod)
* Mon Sep 07 2009 Rüdiger Landmann rland...@redhat.com 1.27-1
- Specfile autogenerated by cpanspec 1.78.
--- NEW FILE import.log ---
perl-Locale-Maketext-Gettext-1_27-2_fc11:EL-4:perl-Locale-Maketext-Gettext-1.27-2.fc11.src.rpm:1253915652
--- NEW FILE perl-Locale-Maketext-Gettext.spec ---
Name: perl-Locale-Maketext-Gettext
Version:1.27
Release:2%{?dist}
Summary:Joins the gettext and Maketext frameworks
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Locale-Maketext-Gettext/
Source0:
http://www.cpan.org/authors/id/I/IM/IMACAT/Locale-Maketext-Gettext-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Module::Build)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
Locale::Maketext::Gettext joins the GNU gettext and Maketext frameworks. It
is a subclass of Locale::Maketext(3) that follows the way GNU gettext
works. It works seamlessly, both in the sense of GNU gettext and Maketext.
As a result, you enjoy both their advantages, and get rid of both their
problems, too.
%prep
%setup -q -n Locale-Maketext-Gettext-%{version}
%build
%{__perl} Build.PL installdirs=vendor
./Build
%install
rm -rf $RPM_BUILD_ROOT
./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
rm -f debugsources.list debugfiles.list debuglinks.list
./Build test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Artistic BUGS Changes COPYING README THANKS TODO
%{perl_vendorlib}/*
%{_mandir}/man3/*
%{_bindir}/maketext
%{_mandir}/man1/*
%changelog
* Mon Sep 21 2009 Rüdiger Landmann rland...@redhat.com 1.27-2
- added BuildRequires: perl(Test::More) and BuildRequires: perl(Test::Pod)
* Mon Sep 07 2009 Rüdiger Landmann rland...@redhat.com 1.27-1
- Specfile autogenerated by cpanspec 1.78.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Locale-Maketext-Gettext/EL-4/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 25 Sep 2009 16:34:55 - 1.1
+++ .cvsignore 25 Sep 2009 21:55:34 - 1.2
@@ -0,0 +1 @@
+Locale-Maketext-Gettext-1.27.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Locale-Maketext-Gettext/EL-4/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 25 Sep 2009 16:34:55 - 1.1
+++ sources 25 Sep 2009 21:55:34 - 1.2
@@ -0,0 +1 @@
+58019c37c8ad1c4526476a7fb98b64c6 Locale-Maketext-Gettext-1.27.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 526255] New: tkmib crashes
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: tkmib crashes https://bugzilla.redhat.com/show_bug.cgi?id=526255 Summary: tkmib crashes Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: perl-Tk AssignedTo: andreas.bierf...@lowlatency.de ReportedBy: jsafr...@redhat.com QAContact: extras...@fedoraproject.org CC: andreas.bierf...@lowlatency.de, fedora-perl-devel-list@redhat.com Classification: Fedora Target Release: --- Description of problem: /usr/bin/tkmib from net-snmp-gui-5.4.2.1-17.fc12.x86_64 crashes on rawhide, while the same /usr/bin/tkmib runs well on Fedora 11. Version-Release number of selected component (if applicable): perl-Tk-804.028-10.fc12.x86_64 perl-5.10.0-82.fc12.x86_64 How reproducible: always Steps to Reproduce: 1. yum install net-snmp-gui 2. tkmib Actual results: setting opts Segmentation fault (core dumped) Expected results: tkmib shows some fancy GUI Stack trace: Core was generated by `/usr/bin/perl /usr/bin/tkmib'. Program terminated with signal 11, Segmentation fault. #0 Tk_AllocFontFromObj (interp=value optimized out, tkwin=0x275d7c0, objPtr=0x278a470) at tkFont.c:1145 1145 fontPtr-resourceRefCount = 1; (gdb) bt #0 Tk_AllocFontFromObj (interp=value optimized out, tkwin=0x275d7c0, objPtr=0x278a470) at tkFont.c:1145 #1 0x7f176f349dc2 in DoObjConfig (interp=0x26c8190, recordPtr=value optimized out, optionPtr=0x276d880, valuePtr=0x278a470, tkwin=value optimized out, savedOptionPtr=0x0) at tkConfig.c:799 #2 0x7f176f34a002 in Tk_InitOptions (interp=0x26c8190, recordPtr=value optimized out, optionTable=value optimized out, tkwin=0x275d7c0) at tkConfig.c:569 #3 0x7f176d1b8838 in Tk_MenubuttonObjCmd (clientData=value optimized out, interp=0x26c8190, objc=value optimized out, objv=0x2043aa0) at tkMenubutton.c:306 #4 0x7f176f2cf595 in Call_Tk (info=value optimized out, items=4, args=0x2043aa0) at tkGlue.c:2283 #5 0x7f176f2d1190 in XSTkCommand (cv=0x278a038, mwcd=value optimized out, proc=0x7f176d1b8550 Tk_MenubuttonObjCmd, items=4, args=0x2043aa0) at tkGlue.c:3062 #6 0x7f176d1b7064 in XS_Tk_menubutton (my_perl=0x1e2c010, cv=0x278a038) at Menubutton.xs:29 #7 0x7f177751411a in Perl_pp_entersub (my_perl=0x1e2c010) at pp_hot.c:2850 #8 0x7f17774ea4a8 in Perl_runops_debug (my_perl=0x1e2c010) at dump.c:1931 #9 0x7f1777510049 in S_run_body (oldscope=value optimized out, my_perl=value optimized out) at perl.c:2386 #10 perl_run (oldscope=value optimized out, my_perl=value optimized out) at perl.c:2309 #11 0x00400cfc in main (argc=2, argv=0x7fff1e77b7a8, env=0x7fff1e77b7c0) at perlmain.c:113 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 525587] Close tag missing in XML output of optionally empty tags
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=525587 --- Comment #7 from Fedora Update System upda...@fedoraproject.org 2009-09-29 10:27:56 EDT --- perl-HTML-Tree-3.23-9.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 525587] Close tag missing in XML output of optionally empty tags
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=525587 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||3.23-9.fc11 Resolution||ERRATA -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-POE-Component-Client-Keepalive/devel perl-POE-Component-Client-Keepalive.spec, 1.12, 1.13
Author: cweyl
Update of /cvs/extras/rpms/perl-POE-Component-Client-Keepalive/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv22946
Modified Files:
perl-POE-Component-Client-Keepalive.spec
Log Message:
* Tue Sep 29 2009 Chris Weyl cw...@alumni.drew.edu 0.260-2
- fix provides version (for perl-POE-Component-Client-HTTP)
Index: perl-POE-Component-Client-Keepalive.spec
===
RCS file:
/cvs/extras/rpms/perl-POE-Component-Client-Keepalive/devel/perl-POE-Component-Client-Keepalive.spec,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -p -r1.12 -r1.13
--- perl-POE-Component-Client-Keepalive.spec27 Sep 2009 09:01:18 -
1.12
+++ perl-POE-Component-Client-Keepalive.spec29 Sep 2009 14:51:43 -
1.13
@@ -1,6 +1,6 @@
Name: perl-POE-Component-Client-Keepalive
Version:0.260
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Manages and keeps alive client connections
Group: Development/Libraries
@@ -19,7 +19,7 @@ BuildRequires: perl(POE::Component::Cli
BuildRequires: perl(Net::IP) = 1.25
# Satisfy automaticly generated requires that want this module = 0.0901
-Provides: perl(POE::Component::Client::Keepalive) = %{version}
+Provides: perl(POE::Component::Client::Keepalive) = %{version}0
### auto-added reqs!
Requires: perl(Net::IP) = 1.25
@@ -69,6 +69,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*.3*
%changelog
+* Tue Sep 29 2009 Chris Weyl cw...@alumni.drew.edu 0.260-2
+- fix provides version (for perl-POE-Component-Client-HTTP)
+
* Sun Sep 27 2009 Chris Weyl cw...@alumni.drew.edu 0.260-1
- update filtering
- auto-update to 0.260 (by cpan-spec-update 0.01)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-POE-Component-Client-Keepalive/F-12 perl-POE-Component-Client-Keepalive.spec, 1.12, 1.13
Author: cweyl
Update of /cvs/extras/rpms/perl-POE-Component-Client-Keepalive/F-12
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv1773
Modified Files:
perl-POE-Component-Client-Keepalive.spec
Log Message:
* Tue Sep 29 2009 Chris Weyl cw...@alumni.drew.edu 0.260-2
- fix provides version (for perl-POE-Component-Client-HTTP)
Index: perl-POE-Component-Client-Keepalive.spec
===
RCS file:
/cvs/extras/rpms/perl-POE-Component-Client-Keepalive/F-12/perl-POE-Component-Client-Keepalive.spec,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -p -r1.12 -r1.13
--- perl-POE-Component-Client-Keepalive.spec27 Sep 2009 09:01:18 -
1.12
+++ perl-POE-Component-Client-Keepalive.spec29 Sep 2009 15:31:39 -
1.13
@@ -1,6 +1,6 @@
Name: perl-POE-Component-Client-Keepalive
Version:0.260
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Manages and keeps alive client connections
Group: Development/Libraries
@@ -19,7 +19,7 @@ BuildRequires: perl(POE::Component::Cli
BuildRequires: perl(Net::IP) = 1.25
# Satisfy automaticly generated requires that want this module = 0.0901
-Provides: perl(POE::Component::Client::Keepalive) = %{version}
+Provides: perl(POE::Component::Client::Keepalive) = %{version}0
### auto-added reqs!
Requires: perl(Net::IP) = 1.25
@@ -69,6 +69,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*.3*
%changelog
+* Tue Sep 29 2009 Chris Weyl cw...@alumni.drew.edu 0.260-2
+- fix provides version (for perl-POE-Component-Client-HTTP)
+
* Sun Sep 27 2009 Chris Weyl cw...@alumni.drew.edu 0.260-1
- update filtering
- auto-update to 0.260 (by cpan-spec-update 0.01)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-common-sense/F-12 import.log, NONE, 1.1 perl-common-sense.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/perl-common-sense/F-12
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv27296/F-12
Modified Files:
.cvsignore sources
Added Files:
import.log perl-common-sense.spec
Log Message:
initial import
--- NEW FILE import.log ---
perl-common-sense-1_0-2_fc11:F-12:perl-common-sense-1.0-2.fc11.src.rpm:1254275244
--- NEW FILE perl-common-sense.spec ---
Name: perl-common-sense
Version:1.0
Release:2%{?dist}
# see LICENSE
License:GPL+ or Artistic
Group: Development/Libraries
Summary:Common sense Perl defaults
Source:
http://search.cpan.org/CPAN/authors/id/M/ML/MLEHMANN/common-sense-%{version}.tar.gz
Url:http://search.cpan.org/dist/common-sense
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
%{?perl_default_filter}
%description
This module implements some sane defaults for Perl programs, as defined
by two typical (or not so typical - use your common sense) specimens of
Perl coders:
use strict qw(vars subs);
use feature qw(say state switch);
no warnings;
%prep
%setup -q -n common-sense-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc LICENSE Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
* Sun Sep 27 2009 Chris Weyl cw...@alumni.drew.edu 1.0-2
- update summary (though now we deviate from upstream)
* Mon Aug 31 2009 Chris Weyl cw...@alumni.drew.edu 1.0-1
- auto-update to 1.0 (by cpan-spec-update 0.01)
* Fri Aug 21 2009 Chris Weyl cw...@alumni.drew.edu 0.04-0
- initial RPM packaging
- generated with cpan2dist (CPANPLUS::Dist::RPM version 0.0.8)
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-common-sense/F-12/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 29 Sep 2009 20:20:04 - 1.1
+++ .cvsignore 30 Sep 2009 01:47:28 - 1.2
@@ -0,0 +1 @@
+common-sense-1.0.tar.gz
Index: sources
===
RCS file: /cvs/extras/rpms/perl-common-sense/F-12/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 29 Sep 2009 20:20:04 - 1.1
+++ sources 30 Sep 2009 01:47:28 - 1.2
@@ -0,0 +1 @@
+c6fd2a8fd579f62c57211d7c8e4115f3 common-sense-1.0.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-common-sense/F-11 import.log, NONE, 1.1 perl-common-sense.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/perl-common-sense/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv27470/F-11
Modified Files:
.cvsignore sources
Added Files:
import.log perl-common-sense.spec
Log Message:
initial import
--- NEW FILE import.log ---
perl-common-sense-1_0-2_fc11:F-11:perl-common-sense-1.0-2.fc11.src.rpm:1254275254
--- NEW FILE perl-common-sense.spec ---
Name: perl-common-sense
Version:1.0
Release:2%{?dist}
# see LICENSE
License:GPL+ or Artistic
Group: Development/Libraries
Summary:Common sense Perl defaults
Source:
http://search.cpan.org/CPAN/authors/id/M/ML/MLEHMANN/common-sense-%{version}.tar.gz
Url:http://search.cpan.org/dist/common-sense
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
%{?perl_default_filter}
%description
This module implements some sane defaults for Perl programs, as defined
by two typical (or not so typical - use your common sense) specimens of
Perl coders:
use strict qw(vars subs);
use feature qw(say state switch);
no warnings;
%prep
%setup -q -n common-sense-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc LICENSE Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
* Sun Sep 27 2009 Chris Weyl cw...@alumni.drew.edu 1.0-2
- update summary (though now we deviate from upstream)
* Mon Aug 31 2009 Chris Weyl cw...@alumni.drew.edu 1.0-1
- auto-update to 1.0 (by cpan-spec-update 0.01)
* Fri Aug 21 2009 Chris Weyl cw...@alumni.drew.edu 0.04-0
- initial RPM packaging
- generated with cpan2dist (CPANPLUS::Dist::RPM version 0.0.8)
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-common-sense/F-11/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 29 Sep 2009 20:20:04 - 1.1
+++ .cvsignore 30 Sep 2009 01:47:38 - 1.2
@@ -0,0 +1 @@
+common-sense-1.0.tar.gz
Index: sources
===
RCS file: /cvs/extras/rpms/perl-common-sense/F-11/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 29 Sep 2009 20:20:04 - 1.1
+++ sources 30 Sep 2009 01:47:38 - 1.2
@@ -0,0 +1 @@
+c6fd2a8fd579f62c57211d7c8e4115f3 common-sense-1.0.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-common-sense/F-10 import.log, NONE, 1.1 perl-common-sense.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/perl-common-sense/F-10
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv27693/F-10
Modified Files:
.cvsignore sources
Added Files:
import.log perl-common-sense.spec
Log Message:
initial import
--- NEW FILE import.log ---
perl-common-sense-1_0-2_fc11:F-10:perl-common-sense-1.0-2.fc11.src.rpm:1254275267
--- NEW FILE perl-common-sense.spec ---
Name: perl-common-sense
Version:1.0
Release:2%{?dist}
# see LICENSE
License:GPL+ or Artistic
Group: Development/Libraries
Summary:Common sense Perl defaults
Source:
http://search.cpan.org/CPAN/authors/id/M/ML/MLEHMANN/common-sense-%{version}.tar.gz
Url:http://search.cpan.org/dist/common-sense
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
%{?perl_default_filter}
%description
This module implements some sane defaults for Perl programs, as defined
by two typical (or not so typical - use your common sense) specimens of
Perl coders:
use strict qw(vars subs);
use feature qw(say state switch);
no warnings;
%prep
%setup -q -n common-sense-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc LICENSE Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
* Sun Sep 27 2009 Chris Weyl cw...@alumni.drew.edu 1.0-2
- update summary (though now we deviate from upstream)
* Mon Aug 31 2009 Chris Weyl cw...@alumni.drew.edu 1.0-1
- auto-update to 1.0 (by cpan-spec-update 0.01)
* Fri Aug 21 2009 Chris Weyl cw...@alumni.drew.edu 0.04-0
- initial RPM packaging
- generated with cpan2dist (CPANPLUS::Dist::RPM version 0.0.8)
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-common-sense/F-10/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 29 Sep 2009 20:20:04 - 1.1
+++ .cvsignore 30 Sep 2009 01:47:57 - 1.2
@@ -0,0 +1 @@
+common-sense-1.0.tar.gz
Index: sources
===
RCS file: /cvs/extras/rpms/perl-common-sense/F-10/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 29 Sep 2009 20:20:04 - 1.1
+++ sources 30 Sep 2009 01:47:58 - 1.2
@@ -0,0 +1 @@
+c6fd2a8fd579f62c57211d7c8e4115f3 common-sense-1.0.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-WWW-Mechanize-GZip/devel import.log, NONE, 1.1 perl-WWW-Mechanize-GZip.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/perl-WWW-Mechanize-GZip/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv28092/devel
Modified Files:
.cvsignore sources
Added Files:
import.log perl-WWW-Mechanize-GZip.spec
Log Message:
initial import
--- NEW FILE import.log ---
perl-WWW-Mechanize-GZip-0_12-1_fc11:HEAD:perl-WWW-Mechanize-GZip-0.12-1.fc11.src.rpm:1254275342
--- NEW FILE perl-WWW-Mechanize-GZip.spec ---
Name: perl-WWW-Mechanize-GZip
Version:0.12
Release:1%{?dist}
# lib/WWW/Mechanize/GZip.pm - GPL+ or Artistic
License:GPL+ or Artistic
Group: Development/Libraries
Summary:Fetch compressed webpages
Source:
http://search.cpan.org/CPAN/authors/id/P/PE/PEGI/WWW-Mechanize-GZip-%{version}.tar.gz
Url:http://search.cpan.org/dist/WWW-Mechanize-GZip
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
BuildArch: noarch
BuildRequires: perl(Compress::Zlib)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
BuildRequires: perl(WWW::Mechanize)
Requires: perl(WWW::Mechanize)
Requires: perl(Compress::Zlib)
%{?perl_default_filter}
%description
The WWW::Mechanize::GZip module tries to fetch a URL by requesting
gzip-compression from the webserver. If the response contains
a header with 'Content-Encoding: gzip', it decompresses the response in
order to get the original (uncompressed) content. This module will help
to reduce bandwith fetching webpages, if supported by the webeserver.
If the webserver does not support gzip-compression, no decompression
will be made.
%prep
%setup -q -n WWW-Mechanize-GZip-%{version}
find . -type f -exec chmod -x -c {} \;
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc README Changes
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
* Sat Sep 26 2009 Chris Weyl cw...@alumni.drew.edu 0.12-1
- submission
- update filtering
* Sat Sep 26 2009 Chris Weyl cw...@alumni.drew.edu 0.12-0
- initial RPM packaging
- generated with cpan2dist (CPANPLUS::Dist::RPM version 0.0.8)
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-WWW-Mechanize-GZip/devel/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 29 Sep 2009 20:22:13 - 1.1
+++ .cvsignore 30 Sep 2009 01:49:06 - 1.2
@@ -0,0 +1 @@
+WWW-Mechanize-GZip-0.12.tar.gz
Index: sources
===
RCS file: /cvs/extras/rpms/perl-WWW-Mechanize-GZip/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 29 Sep 2009 20:22:13 - 1.1
+++ sources 30 Sep 2009 01:49:07 - 1.2
@@ -0,0 +1 @@
+c3475fcff561629dddbd25b9db611e49 WWW-Mechanize-GZip-0.12.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-WWW-Mechanize-GZip/F-12 import.log, NONE, 1.1 perl-WWW-Mechanize-GZip.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/perl-WWW-Mechanize-GZip/F-12
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv28258/F-12
Modified Files:
.cvsignore sources
Added Files:
import.log perl-WWW-Mechanize-GZip.spec
Log Message:
initial import
--- NEW FILE import.log ---
perl-WWW-Mechanize-GZip-0_12-1_fc11:F-12:perl-WWW-Mechanize-GZip-0.12-1.fc11.src.rpm:1254275353
--- NEW FILE perl-WWW-Mechanize-GZip.spec ---
Name: perl-WWW-Mechanize-GZip
Version:0.12
Release:1%{?dist}
# lib/WWW/Mechanize/GZip.pm - GPL+ or Artistic
License:GPL+ or Artistic
Group: Development/Libraries
Summary:Fetch compressed webpages
Source:
http://search.cpan.org/CPAN/authors/id/P/PE/PEGI/WWW-Mechanize-GZip-%{version}.tar.gz
Url:http://search.cpan.org/dist/WWW-Mechanize-GZip
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
BuildArch: noarch
BuildRequires: perl(Compress::Zlib)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
BuildRequires: perl(WWW::Mechanize)
Requires: perl(WWW::Mechanize)
Requires: perl(Compress::Zlib)
%{?perl_default_filter}
%description
The WWW::Mechanize::GZip module tries to fetch a URL by requesting
gzip-compression from the webserver. If the response contains
a header with 'Content-Encoding: gzip', it decompresses the response in
order to get the original (uncompressed) content. This module will help
to reduce bandwith fetching webpages, if supported by the webeserver.
If the webserver does not support gzip-compression, no decompression
will be made.
%prep
%setup -q -n WWW-Mechanize-GZip-%{version}
find . -type f -exec chmod -x -c {} \;
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc README Changes
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
* Sat Sep 26 2009 Chris Weyl cw...@alumni.drew.edu 0.12-1
- submission
- update filtering
* Sat Sep 26 2009 Chris Weyl cw...@alumni.drew.edu 0.12-0
- initial RPM packaging
- generated with cpan2dist (CPANPLUS::Dist::RPM version 0.0.8)
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-WWW-Mechanize-GZip/F-12/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 29 Sep 2009 20:22:13 - 1.1
+++ .cvsignore 30 Sep 2009 01:49:17 - 1.2
@@ -0,0 +1 @@
+WWW-Mechanize-GZip-0.12.tar.gz
Index: sources
===
RCS file: /cvs/extras/rpms/perl-WWW-Mechanize-GZip/F-12/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 29 Sep 2009 20:22:13 - 1.1
+++ sources 30 Sep 2009 01:49:18 - 1.2
@@ -0,0 +1 @@
+c3475fcff561629dddbd25b9db611e49 WWW-Mechanize-GZip-0.12.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-WWW-Mechanize-GZip/F-11 import.log, NONE, 1.1 perl-WWW-Mechanize-GZip.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/perl-WWW-Mechanize-GZip/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv28428/F-11
Modified Files:
.cvsignore sources
Added Files:
import.log perl-WWW-Mechanize-GZip.spec
Log Message:
initial import
--- NEW FILE import.log ---
perl-WWW-Mechanize-GZip-0_12-1_fc11:F-11:perl-WWW-Mechanize-GZip-0.12-1.fc11.src.rpm:1254275364
--- NEW FILE perl-WWW-Mechanize-GZip.spec ---
Name: perl-WWW-Mechanize-GZip
Version:0.12
Release:1%{?dist}
# lib/WWW/Mechanize/GZip.pm - GPL+ or Artistic
License:GPL+ or Artistic
Group: Development/Libraries
Summary:Fetch compressed webpages
Source:
http://search.cpan.org/CPAN/authors/id/P/PE/PEGI/WWW-Mechanize-GZip-%{version}.tar.gz
Url:http://search.cpan.org/dist/WWW-Mechanize-GZip
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
BuildArch: noarch
BuildRequires: perl(Compress::Zlib)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
BuildRequires: perl(WWW::Mechanize)
Requires: perl(WWW::Mechanize)
Requires: perl(Compress::Zlib)
%{?perl_default_filter}
%description
The WWW::Mechanize::GZip module tries to fetch a URL by requesting
gzip-compression from the webserver. If the response contains
a header with 'Content-Encoding: gzip', it decompresses the response in
order to get the original (uncompressed) content. This module will help
to reduce bandwith fetching webpages, if supported by the webeserver.
If the webserver does not support gzip-compression, no decompression
will be made.
%prep
%setup -q -n WWW-Mechanize-GZip-%{version}
find . -type f -exec chmod -x -c {} \;
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc README Changes
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
* Sat Sep 26 2009 Chris Weyl cw...@alumni.drew.edu 0.12-1
- submission
- update filtering
* Sat Sep 26 2009 Chris Weyl cw...@alumni.drew.edu 0.12-0
- initial RPM packaging
- generated with cpan2dist (CPANPLUS::Dist::RPM version 0.0.8)
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-WWW-Mechanize-GZip/F-11/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 29 Sep 2009 20:22:13 - 1.1
+++ .cvsignore 30 Sep 2009 01:49:30 - 1.2
@@ -0,0 +1 @@
+WWW-Mechanize-GZip-0.12.tar.gz
Index: sources
===
RCS file: /cvs/extras/rpms/perl-WWW-Mechanize-GZip/F-11/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 29 Sep 2009 20:22:13 - 1.1
+++ sources 30 Sep 2009 01:49:30 - 1.2
@@ -0,0 +1 @@
+c3475fcff561629dddbd25b9db611e49 WWW-Mechanize-GZip-0.12.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
