Re: Looking into LLVM
Le 26/10/2009 23:30, Jud Craft a écrit : Hence I thought you were talking about ABI issues with C. I'm not up on how LLVM frontend integration works, so I actually don't understand the distinction between the LLVM C Backend and the native LLVM backends. Simply, can I write and compile a GTK program with LLVM? I'd love to use it for the intuitive error reporting, honestly. the static analyzer works also with gcc, check scan-build. H. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
ld ignoring parts of LD_LIBRARY_PATH?
Hi, this is slightly off topic, but may be relevant for fedora developing, too: I have set up a small test bed for an application I am converting to a autotools build system. In this testbed I have: ./lib/libfoo.so ./lib/bar/libbar.so When I add the lib/ entry to LD_LIBRARY_PATH it is recognized and scanned for libraries. The same for the lib/bar entry. But when I add both, the lib/ entry is ignored completely. Is this normal? regards Christoph signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- 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 (in Rawhide) is about to happen
Ewan Mac Mahon wrote: On Mon, Oct 26, 2009 at 02:06:45PM -0400, Steve Dickson wrote: On 10/26/2009 01:34 PM, Frank Ch. Eigler wrote: Steve Dickson ste...@redhat.com writes: On 10/26/2009 12:06 PM, Frank Ch. Eigler wrote: Unfortunately, this sounds like only. Is it out of the question to make the client look for this case (an upgraded client in an existing unupgraded, unchanged network) and handle it? We talked about it... See http://linux-nfs.org/pipermail/nfsv4/2009-October/011471.html But in the end, I decided not to do this since its not clear how the change would interact with other NFS servers... It's not clear to me how falling back to NFSv3 if v4 fails (and the version wasn't explicitly set to v4) could ever cause a problem - it might not help, but under what circumstances could it possibly be harmful? I had a look at the linked thread from linux-nfs and no-one there seemed to come up with anything concrete. The strongest objection I found was Older versions of ONTAP (like 6.0 through 6.2?), for example, have the same problem as the Linux NFSv4 server does currently, iirc. It's also worth noting that modern Solaris clients do not have this ENOENT workaround. So, if automounter maps are shared with Linux clients _with_ the workaround, mounting a Linux NFSv4 server, there may be some issues. In the long term, I think we are much better off living with a few months of complaints about the new version negotiation behavior, rather than having this mount.nfs workaround. I'm not going to object to it outright, though... (chuck[dot]lever[at]oracle[dot]com) I'm not going to object outright sounds to me like we can fall back to V3. I think this is the best plan for us: we should not break things for users of Fedora clients with RHEL servers or Fedora clients with Fedora servers. Further, On Oct 22, 2009, at 10:04 AM, Steve Dickson wrote: On 10/22/2009 12:21 PM, Chuck Lever wrote: This would be mitigated instantly by leaving the version negotiation default set to v3/v2. Then no workaround would be needed. Right... Or defining the negotiation in the configuration file would also cause the workaround not to be needed... That's what I meant: set defaultvers: 3 in the config file, and allow early adopters to change it. After a while, we can bump the default setting. I think this is roughly what Sun did during their transition. (chuck[dot]lever[at]oracle[dot]com) Leaving the default at Version 3 for the next year or two would mostly solve the problem. Andrew. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/fence-agents/F-11 fence-agents.spec,1.13,1.14
On Tue, 27 Oct 2009 10:51:14 + (UTC), Fabio wrote:
Author: fabbione
Update of /cvs/pkgs/rpms/fence-agents/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv15209
Modified Files:
fence-agents.spec
Log Message:
Fix Requires: on libvirt/libvirt-client
+%if 0%{?fedora} = 12
+Requires: libvirt-client
+%else
+Requires: libvirt
+%endif
+
What is this explicit dependency on a package name supposed to achieve?
There is the automatic arch-specific dependency on the libvirt SONAME
already, and it is tons better than a non-arch-specific and version-less
dependency on a package name.
https://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/fence-agents/F-11 fence-agents.spec,1.13,1.14
Michael Schwendt wrote:
On Tue, 27 Oct 2009 10:51:14 + (UTC), Fabio wrote:
Author: fabbione
Update of /cvs/pkgs/rpms/fence-agents/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv15209
Modified Files:
fence-agents.spec
Log Message:
Fix Requires: on libvirt/libvirt-client
+%if 0%{?fedora} = 12
+Requires: libvirt-client
+%else
+Requires: libvirt
+%endif
+
What is this explicit dependency on a package name supposed to achieve?
There is the automatic arch-specific dependency on the libvirt SONAME
already, and it is tons better than a non-arch-specific and version-less
dependency on a package name.
The dependency on the library is pulled in via fence_xvmd that might or
might be not build (depending on ./configure invocation).
virsh used to be part of libvirt in any release before F12. It´s now
moved to libvirt-client.
So while rpm resolver does the right thing for fence_xvmd and pulls in
the right soname Requires, it cannot detect the usage of virsh within
fence_virsh.
If there are better ways to handle it, I am absolutely happy to change
the spec file but I don´t think it is correct either to break
fence_virsh because somebody is not building fence_xvmd* (that is going
to be deprecated upstream btw in not too long future).
I also considered a specific file Requires: /usr/bin/virsh, but policy
suggests to avoid that for different reasons.
Fabio
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/fence-agents/F-11 fence-agents.spec,1.13,1.14
On Tue, 27 Oct 2009 12:17:30 +0100, Fabio wrote:
+%if 0%{?fedora} = 12
+Requires: libvirt-client
+%else
+Requires: libvirt
+%endif
+
What is this explicit dependency on a package name supposed to achieve?
There is the automatic arch-specific dependency on the libvirt SONAME
already, and it is tons better than a non-arch-specific and version-less
dependency on a package name.
The dependency on the library is pulled in via fence_xvmd that might or
might be not build (depending on ./configure invocation).
virsh used to be part of libvirt in any release before F12. It´s now
moved to libvirt-client.
So while rpm resolver does the right thing for fence_xvmd and pulls in
the right soname Requires, it cannot detect the usage of virsh within
fence_virsh.
It's good practise to add a comment to the .spec file that explains
this explicit dependency.
If there are better ways to handle it, I am absolutely happy to change
the spec file but I don´t think it is correct either to break
fence_virsh because somebody is not building fence_xvmd* (that is going
to be deprecated upstream btw in not too long future).
I also considered a specific file Requires: /usr/bin/virsh, but policy
suggests to avoid that for different reasons.
Really? What policy is that? Programs in bin paths are covered by the
primary metadata. Such a dependency would be more accurate.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/fence-agents/F-11 fence-agents.spec,1.13,1.14
Michael Schwendt wrote:
On Tue, 27 Oct 2009 12:17:30 +0100, Fabio wrote:
+%if 0%{?fedora} = 12
+Requires: libvirt-client
+%else
+Requires: libvirt
+%endif
+
What is this explicit dependency on a package name supposed to achieve?
There is the automatic arch-specific dependency on the libvirt SONAME
already, and it is tons better than a non-arch-specific and version-less
dependency on a package name.
The dependency on the library is pulled in via fence_xvmd that might or
might be not build (depending on ./configure invocation).
virsh used to be part of libvirt in any release before F12. It´s now
moved to libvirt-client.
So while rpm resolver does the right thing for fence_xvmd and pulls in
the right soname Requires, it cannot detect the usage of virsh within
fence_virsh.
It's good practise to add a comment to the .spec file that explains
this explicit dependency.
Ok, this is a no brainer. I´ll push the comment with the next series of
updates.
If there are better ways to handle it, I am absolutely happy to change
the spec file but I don´t think it is correct either to break
fence_virsh because somebody is not building fence_xvmd* (that is going
to be deprecated upstream btw in not too long future).
I also considered a specific file Requires: /usr/bin/virsh, but policy
suggests to avoid that for different reasons.
Really? What policy is that? Programs in bin paths are covered by the
primary metadata. Such a dependency would be more accurate.
https://fedoraproject.org/wiki/Packaging/Guidelines#File_Dependencies
I understand that files in bin paths are already covered by primary
data, but the way it is formulated there, it sounds (to me) that there
is still extra processing involved from the different depsolver.
As I mentioned before, I am OK to change the spec file as long as
somebody else will not complain later that I should use the package (and
start playing ping-pong).
Fabio
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/fence-agents/F-11 fence-agents.spec,1.13,1.14
On Tue, 27 Oct 2009 12:37:28 +0100, Fabio wrote: I also considered a specific file Requires: /usr/bin/virsh, but policy suggests to avoid that for different reasons. Really? What policy is that? Programs in bin paths are covered by the primary metadata. Such a dependency would be more accurate. https://fedoraproject.org/wiki/Packaging/Guidelines#File_Dependencies I understand that files in bin paths are already covered by primary data, but the way it is formulated there, it sounds (to me) that there is still extra processing involved from the different depsolver. You've misread that section. Most of it comments on file dependencies _outside_ (!) /etc and bin paths. Those are the ones you ought to avoid, as the depsolvers would need to download and parse additional metadata archives. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/fence-agents/F-11 fence-agents.spec,1.13,1.14
Michael Schwendt wrote: On Tue, 27 Oct 2009 12:37:28 +0100, Fabio wrote: I also considered a specific file Requires: /usr/bin/virsh, but policy suggests to avoid that for different reasons. Really? What policy is that? Programs in bin paths are covered by the primary metadata. Such a dependency would be more accurate. https://fedoraproject.org/wiki/Packaging/Guidelines#File_Dependencies I understand that files in bin paths are already covered by primary data, but the way it is formulated there, it sounds (to me) that there is still extra processing involved from the different depsolver. You've misread that section. Most of it comments on file dependencies _outside_ (!) /etc and bin paths. Those are the ones you ought to avoid, as the depsolvers would need to download and parse additional metadata archives. Ok, thanks for the clarification. Update spec files are on the way. Fabio -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: texlive 2009 - should set TEXMFCNF?
On Sun, Oct 25, 2009 at 03:05:34PM -0400, Neal Becker wrote: I wonder if texlive should include a /etc/profile.d package to set TEXMFCNF, so that other packages, such as xdvipdfmx will work? Or, should texlive just obsolete xdvipdfmx and include it's own version? I will try to fix it in the texmf.cnf kpathsea configuration file directly in the new TL2009 update. Jindrich -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Jindrich Novy jn...@redhat.com http://people.redhat.com/jnovy/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20091027 changes
Compose started at Tue Oct 27 06:15:09 UTC 2009 Broken deps for i386 -- blacs-lam-1.1-33.fc12.i686 requires liblamf77mpi.so.0 blacs-lam-1.1-33.fc12.i686 requires liblam.so.0 orsa-lam-0.7.0-11.fc12.i686 requires lam scalapack-lam-1.7.5-7.fc12.i686 requires liblam.so.0 scalapack-lam-1.7.5-7.fc12.i686 requires liblamf77mpi.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblam.so.0 tachyon-lam-gl-0.98.7-1.fc12.i686 requires liblamf77mpi.so.0 Broken deps for x86_64 -- blacs-lam-1.1-33.fc12.i686 requires liblamf77mpi.so.0 blacs-lam-1.1-33.fc12.i686 requires liblam.so.0 blacs-lam-1.1-33.fc12.x86_64 requires liblam.so.0()(64bit) blacs-lam-1.1-33.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) orsa-lam-0.7.0-11.fc12.x86_64 requires lam scalapack-lam-1.7.5-7.fc12.i686 requires liblam.so.0 scalapack-lam-1.7.5-7.fc12.i686 requires liblamf77mpi.so.0 scalapack-lam-1.7.5-7.fc12.x86_64 requires liblam.so.0()(64bit) scalapack-lam-1.7.5-7.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblam.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.x86_64 requires liblamf77mpi.so.0()(64bit) Broken deps for ppc -- blacs-lam-1.1-33.fc12.ppc requires liblamf77mpi.so.0 blacs-lam-1.1-33.fc12.ppc requires liblam.so.0 blacs-lam-1.1-33.fc12.ppc64 requires liblam.so.0()(64bit) blacs-lam-1.1-33.fc12.ppc64 requires liblamf77mpi.so.0()(64bit) orsa-lam-0.7.0-11.fc12.ppc requires lam scalapack-lam-1.7.5-7.fc12.ppc requires liblam.so.0 scalapack-lam-1.7.5-7.fc12.ppc requires liblamf77mpi.so.0 scalapack-lam-1.7.5-7.fc12.ppc64 requires liblam.so.0()(64bit) scalapack-lam-1.7.5-7.fc12.ppc64 requires liblamf77mpi.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.ppc requires liblam.so.0 tachyon-lam-0.98.7-1.fc12.ppc requires liblamf77mpi.so.0 tachyon-lam-gl-0.98.7-1.fc12.ppc requires liblam.so.0 tachyon-lam-gl-0.98.7-1.fc12.ppc requires liblamf77mpi.so.0 Broken deps for ppc64 -- blacs-lam-1.1-33.fc12.ppc64 requires liblam.so.0()(64bit) blacs-lam-1.1-33.fc12.ppc64 requires liblamf77mpi.so.0()(64bit) orsa-lam-0.7.0-11.fc12.ppc64 requires lam python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot scalapack-lam-1.7.5-7.fc12.ppc64 requires liblam.so.0()(64bit) scalapack-lam-1.7.5-7.fc12.ppc64 requires liblamf77mpi.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.ppc64 requires liblam.so.0()(64bit) tachyon-lam-0.98.7-1.fc12.ppc64 requires liblamf77mpi.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.ppc64 requires liblam.so.0()(64bit) tachyon-lam-gl-0.98.7-1.fc12.ppc64 requires liblamf77mpi.so.0()(64bit) New package kcm-gtk Configure the appearance of GTK apps in KDE New package python-xkit A simple, transparent and easy to extend xorg parser Removed package lam Updated Packages: 389-dsgw-1.1.4-1.fc12 - * Wed Aug 12 2009 Rich Megginson rmegg...@redhat.com - 1.1.4-1 - bump version to 1.1.4 - fix remaining licensing problems - fix adminutil.m4 * Fri Jul 24 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.1.3-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild * Tue Jul 21 2009 Rich Megginson rmegg...@redhat.com - 1.1.3-2 - use 389-adminutil instead of adminutil artwiz-aleczapka-fonts-1.3-8.fc12 - * Fri Jul 24 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.3-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild asterisk-1.6.1.7-0.4.rc2.fc12 - * Sat Oct 24 2009 Jeffrey C. Ollie j...@ocjtech.us - 1.6.1.7-0.3.rc2 - Compile against gmime 2.2 instead of gmime 2.4 because the patch to convert the API calls from 2.2 to 2.4 caused crashes. * Sat Oct 24 2009 Jeffrey C. Ollie j...@ocjtech.us - 1.6.1.7-0.4.rc2 - Add an AST_EXTRA_ARGS option to the init script - have the init script to cd to /var/spool/asterisk to prevent annoying message * Fri Oct 09 2009 Jeffrey C. Ollie j...@ocjtech.us - 1.6.1.7-0.2.rc2 - Require latex2html used in static-http documents * Thu Oct 08 2009 Jeffrey C. Ollie j...@ocjtech.us - 1.6.1.7-0.1.rc2 - Update to 1.6.1.7-rc2 - Merge firmware subpackage back into main package - No longer need to strip tarball since it no
Package Review Stats for last 7 days ending 25th Oct
Top two FAS account holders who have completed reviewing Package review components on bugzilla for last 7 days ending 25th Oct were Roman Rakus and Nicolas Mailhot. Roman Rakus : 6 https://bugzilla.redhat.com/show_bug.cgi?id=503496 https://bugzilla.redhat.com/show_bug.cgi?id=469002 https://bugzilla.redhat.com/show_bug.cgi?id=502818 https://bugzilla.redhat.com/show_bug.cgi?id=502834 https://bugzilla.redhat.com/show_bug.cgi?id=503482 https://bugzilla.redhat.com/show_bug.cgi?id=503510 Nicolas Mailhot : 4 https://bugzilla.redhat.com/show_bug.cgi?id=528675 https://bugzilla.redhat.com/show_bug.cgi?id=530190 https://bugzilla.redhat.com/show_bug.cgi?id=526204 https://bugzilla.redhat.com/show_bug.cgi?id=529323 Mamoru Tasaka : 2 https://bugzilla.redhat.com/show_bug.cgi?id=529799 https://bugzilla.redhat.com/show_bug.cgi?id=502614 Mattias Ellert : 2 https://bugzilla.redhat.com/show_bug.cgi?id=527336 https://bugzilla.redhat.com/show_bug.cgi?id=527308 Nick Bebout : 2 https://bugzilla.redhat.com/show_bug.cgi?id=528003 https://bugzilla.redhat.com/show_bug.cgi?id=512016 Parag AN(पराग) : 2 https://bugzilla.redhat.com/show_bug.cgi?id=522482 https://bugzilla.redhat.com/show_bug.cgi?id=527319 Thomas Spura : 2 https://bugzilla.redhat.com/show_bug.cgi?id=530205 https://bugzilla.redhat.com/show_bug.cgi?id=525192 David A. Wheeler : 1 https://bugzilla.redhat.com/show_bug.cgi?id=529404 David Lutterkort : 1 https://bugzilla.redhat.com/show_bug.cgi?id=514221 David Nalley : 1 https://bugzilla.redhat.com/show_bug.cgi?id=529269 Emmanuel Seyman : 1 https://bugzilla.redhat.com/show_bug.cgi?id=524896 Jaroslav Reznik : 1 https://bugzilla.redhat.com/show_bug.cgi?id=530342 Jussi Lehtola : 1 https://bugzilla.redhat.com/show_bug.cgi?id=529466 Kevin Kofler : 1 https://bugzilla.redhat.com/show_bug.cgi?id=528096 Martin Gieseking : 1 https://bugzilla.redhat.com/show_bug.cgi?id=529016 Mat Booth : 1 https://bugzilla.redhat.com/show_bug.cgi?id=515136 Miroslav Suchý : 1 https://bugzilla.redhat.com/show_bug.cgi?id=529810 Orion Poplawski : 1 https://bugzilla.redhat.com/show_bug.cgi?id=504405 Paulo Roma Cavalcanti : 1 https://bugzilla.redhat.com/show_bug.cgi?id=528892 Pierre-YvesChibon : 1 https://bugzilla.redhat.com/show_bug.cgi?id=491980 Sebastian Dziallas : 1 https://bugzilla.redhat.com/show_bug.cgi?id=527245 Simon Wesp : 1 https://bugzilla.redhat.com/show_bug.cgi?id=492810 Steve Traylen : 1 https://bugzilla.redhat.com/show_bug.cgi?id=516515 Yanko Kaneti : 1 https://bugzilla.redhat.com/show_bug.cgi?id=530233 Total reviews modified: 37 Merge Reviews: 0 Review Requests: 37 This report by generated by bzReviewReport.py. The source is available at: https://fedorahosted.org/triage/browser/scripts/bzReviewReport.py Please submit patches or bug reports at: https://fedorahosted.org/triage/ -- Rakesh Pandit https://fedoraproject.org/ freedom, friends, features, first -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
test2 please disregard
many apologies, just trying to sort out my list posting setup. -Adam -- http://maxamillion.googlepages.com - () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- 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 (in Rawhide) is about to happen
On Mon, 2009-10-26 at 10:34 -0400, Steve Dickson wrote: [With the next nfs-utils rawhide build, I will be flipping the ] [switch that will cause all NFS client mounts to try NFS v4 first ] [At the bottom of this email has the workarounds if this change does ] [indeed cause pain ] As part of the https://fedoraproject.org/wiki/Features/NFSv4Default feature I am one commit away from changing the default protocol version NFS will be using (or at least trying to use). What does this means to you? Hopefully nothing! In theory this should be a very seamless transition but with all new technology there will be (and are) some rough spots. Why are make the change? See the NFSv4Default wiki for details, but in a nutshell: * Better performance - V4 is now a stateful protocol. Meaning the server keeps state on all the clients access a particular file or directory. This allows the server to give out delegations (or leases) which in turn allows the client to aggressive cache both data and meta data locally * Firewall Friendly- With v4 only one port is used 2049 for all traffic including mounting and file locking. * Finally it enables us use upcoming minor releases of the the protocol. NFS version 4.1 and pNFS are two example of upcoming minor releases. FYI, V4 was introduced in Fedora Core 2 so it has been around for a while. I personally have been using it for my home directory for a couple years now.. For more of the nitty gritty details see http://www.iaps.com/NFSv4-new-features.html That's the good news... Here is the bad Because the mount command will try NFS v4 first, mounts to older Linux servers will start failing like: # mount linux-server:/export /mnt mount.nfs: mounting linux-server:/export failed, reason given by server: No such file or directory This is due to a defect in the Linux server exporting code, which is fixed in F-12, *but* there are a number of workarounds 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. On the client, go back to v3 mounts by doing one of the following: * Add -o v3 to command line, similar to: mount linux-server:/export /mnt * Change the default mount version in the new /etc/nfsmount.conf file by uncommenting the Nfsvers=3 setting in the 'NFSMount_Global_Options' section. See nfsmount.conf(5) man page for details. The diff would look like: --- /etc/nfsmount.conf.orig 2009-10-26 09:30:21.0 -0400 +++ /etc/nfsmount.conf2009-10-26 10:31:30.227443686 -0400 @@ -31,7 +31,7 @@ # Protocol Version [2,3,4] # This defines the default protocol version which will # be used to start the negotiation with the server. -# Defaultvers=4 +Defaultvers=3 # # Setting this option makes it mandatory the server supports the # given version. The mount will fail if the given version is Haven't gone through the full thread yet, but is it worth adding a note/admonition to our NFS installation instructions that changing the nfs server configuration may be necessary? http://docs.fedoraproject.org/install-guide/f12/en-US/html/ch03s05s02.html Thanks, James 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 (in Rawhide) is about to happen
On 10/27/2009 10:00 AM, James Laska wrote: On Mon, 2009-10-26 at 10:34 -0400, Steve Dickson wrote: [With the next nfs-utils rawhide build, I will be flipping the ] [switch that will cause all NFS client mounts to try NFS v4 first ] [At the bottom of this email has the workarounds if this change does ] [indeed cause pain ] As part of the https://fedoraproject.org/wiki/Features/NFSv4Default feature I am one commit away from changing the default protocol version NFS will be using (or at least trying to use). What does this means to you? Hopefully nothing! In theory this should be a very seamless transition but with all new technology there will be (and are) some rough spots. Why are make the change? See the NFSv4Default wiki for details, but in a nutshell: * Better performance - V4 is now a stateful protocol. Meaning the server keeps state on all the clients access a particular file or directory. This allows the server to give out delegations (or leases) which in turn allows the client to aggressive cache both data and meta data locally * Firewall Friendly- With v4 only one port is used 2049 for all traffic including mounting and file locking. * Finally it enables us use upcoming minor releases of the the protocol. NFS version 4.1 and pNFS are two example of upcoming minor releases. FYI, V4 was introduced in Fedora Core 2 so it has been around for a while. I personally have been using it for my home directory for a couple years now.. For more of the nitty gritty details see http://www.iaps.com/NFSv4-new-features.html That's the good news... Here is the bad Because the mount command will try NFS v4 first, mounts to older Linux servers will start failing like: # mount linux-server:/export /mnt mount.nfs: mounting linux-server:/export failed, reason given by server: No such file or directory This is due to a defect in the Linux server exporting code, which is fixed in F-12, *but* there are a number of workarounds 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. On the client, go back to v3 mounts by doing one of the following: * Add -o v3 to command line, similar to: mount linux-server:/export /mnt * Change the default mount version in the new /etc/nfsmount.conf file by uncommenting the Nfsvers=3 setting in the 'NFSMount_Global_Options' section. See nfsmount.conf(5) man page for details. The diff would look like: --- /etc/nfsmount.conf.orig2009-10-26 09:30:21.0 -0400 +++ /etc/nfsmount.conf 2009-10-26 10:31:30.227443686 -0400 @@ -31,7 +31,7 @@ # Protocol Version [2,3,4] # This defines the default protocol version which will # be used to start the negotiation with the server. -# Defaultvers=4 +Defaultvers=3 # # Setting this option makes it mandatory the server supports the # given version. The mount will fail if the given version is Haven't gone through the full thread yet, but is it worth adding a note/admonition to our NFS installation instructions that changing the nfs server configuration may be necessary? http://docs.fedoraproject.org/install-guide/f12/en-US/html/ch03s05s02.html Thanks, James I think that adding a note to the documentation would be a very good thing... ric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
libmusicbrainz orphaned
Heya, Seeing as libmusicbrainz will have a limited shelf life (the upstream servers for that revision of the protocol will be switched off shortly), and that no GNOME apps use it any more, I'm letting it go. I'd expect Rex to pick it up, as KDE still uses it. Cheers -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: texlive 2009 - should set TEXMFCNF?
Jindrich Novy wrote: On Sun, Oct 25, 2009 at 03:05:34PM -0400, Neal Becker wrote: I wonder if texlive should include a /etc/profile.d package to set TEXMFCNF, so that other packages, such as xdvipdfmx will work? Or, should texlive just obsolete xdvipdfmx and include it's own version? I will try to fix it in the texmf.cnf kpathsea configuration file directly in the new TL2009 update. Jindrich Could you explain? Will you replace the current xdvipdfmx? The current will use kpathsea and will look for config in /usr/share/texmf. I was thinking either: 1) Replace the current xdvipdfmx with the one shipped with texlive or 2) Use /etc/profile.d to set TEXMFCNF -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: libmusicbrainz orphaned
Man, that's worrying. libmusicbrainz is an indirect dependence of listen (through libtunepimp), if no one steps, i'll sure have to. At least, i'm willing to co-maintain it. H. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Wi-Fi Question
On most laptops, there is a way to disable Wi-Fi either through function keys or kill switch. I am wondering if there is a way programmatically speaking to figure out whether or not Wi-Fi is currently disabled because the user has pressed the Wi-Fi function key or turned Wi-Fi off with the kill switch. Martin -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: the mass rebuild and i586 rpms?
On Thursday 22 October 2009 07:29:49 pm Milos Jakubicek wrote: Hi, snip Not a primary arch package (should the package be blocked in the primary arch kojihub?) == prtconf silo xorg-x11-drv-sunffb There are much more of them! I don't know whether it is possible to block a package in a single Koji hub and if our infrastructure team is willing to go in this way -- Jesse? blocking a package on the primary hub will result in the package also being blocked on the secodnary arch hubs. since one of the things we want to do is keep the arches in sync. it will also mean that a packges doesnt get branched in cvs since the branching tools will think its no longer needed. Dennis 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
prelinked octave segfaults in F-12
I'd like to call attention to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=526833 Apparently, prelinking octave on F-12 causes it to segfault on startup. Can anyone else reproduce this? Does anyone have an idea as to why this might happen? -- 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 (in Rawhide) is about to happen
On Tue, 2009-10-27 at 10:00 -0400, James Laska wrote: Haven't gone through the full thread yet, but is it worth adding a note/admonition to our NFS installation instructions that changing the nfs server configuration may be necessary? http://docs.fedoraproject.org/install-guide/f12/en-US/html/ch03s05s02.html I do believe this change is targeting F13 though, not F12, so please don't change any F12 documentation (: -- 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: Wi-Fi Question
On Tue, 2009-10-27 at 12:24 -0400, Martin Dubuc wrote: On most laptops, there is a way to disable Wi-Fi either through function keys or kill switch. I am wondering if there is a way programmatically speaking to figure out whether or not Wi-Fi is currently disabled because the user has pressed the Wi-Fi function key or turned Wi-Fi off with the kill switch. At least on my laptop I have: /sys/class/rfkill/rfkill1/state when my kill switch is thrown. This seems to cover the wifi. When I unkill, which enables bluetooth, I get rfkill2 as well with a state of 1. In my bios I have the switch set to cover cellular and bluetooth, so no switch can kill the wifi. -- 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: prelinked octave segfaults in F-12
On Tuesday 27 October 2009 16:58:43 Orion Poplawski wrote: I'd like to call attention to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=526833 Apparently, prelinking octave on F-12 causes it to segfault on startup. Can anyone else reproduce this? I am sorry for not reporting this before but I had the same problem and I found the same solution. When octave segfaults on start the first step is to run prelink -u /usr/bin/octave and then it works again. Does anyone have an idea as to why this might happen? Not me. :-( -- José Abílio -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: proposed macro deffinitions for F-13
Dennis Gilmore wrote:
Hi All,
Id like to get some feedback on the patches that i'm proposing for F-13.
quite a few packages that need to deal with differences between 32bit/64bit
or
multilib arches have defines for the appropriate arches. sometimes
incomplete
since they don't include secondary arches.
I wanted to get some feedback. and see if there are other cases we should add.
Dennis
I have hacks like this in e2fsprogs.spec for example:
%ifarch %{multilib_arches}
mv -f %{buildroot}%{_includedir}/ext2fs/ext2_types.h \
%{buildroot}%{_includedir}/ext2fs/ext2_types-%{_arch}.h
install -p -m 644 %{SOURCE1} %{buildroot}%{_includedir}/ext2fs/ext2_types.h
%endif
Unless I'm doing a Bad Thing here, maybe some macros to facilitate this
type of header mangling for multiarch?
-Eric
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: proposed macro deffinitions for F-13
On Tuesday 27 October 2009 12:45:10 pm Eric Sandeen wrote:
Dennis Gilmore wrote:
Hi All,
Id like to get some feedback on the patches that i'm proposing for F-13.
quite a few packages that need to deal with differences between
32bit/64bit or multilib arches have defines for the appropriate arches.
sometimes incomplete since they don't include secondary arches.
I wanted to get some feedback. and see if there are other cases we should
add.
Dennis
I have hacks like this in e2fsprogs.spec for example:
%ifarch %{multilib_arches}
mv -f %{buildroot}%{_includedir}/ext2fs/ext2_types.h \
%{buildroot}%{_includedir}/ext2fs/ext2_types-%{_arch}.h
install -p -m 644 %{SOURCE1} %{buildroot}%{_includedir}/ext2fs/ext2_types.h
%endif
Unless I'm doing a Bad Thing here, maybe some macros to facilitate this
type of header mangling for multiarch?
right now you need to define multilib_arches for that to work with my proposed
changes you could drop your defines and use
%ifarch %{multilib64} %{multilib32}
maybe we want to define a multilibarches macro also that way if/when we add a
new multilib arch. we make one changes and rebuild everything and we support
it. rather than changing potentially hundresd of spec files. of course they
will need to be changed to use the new macros.
Dennis
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: RFC: proposed macro deffinitions for F-13
On Tue, 2009-10-27 at 12:40 -0500, Dennis Gilmore wrote:
Id like to get some feedback on the patches that i'm proposing for F-13.
quite a few packages that need to deal with differences between 32bit/64bit
or
multilib arches have defines for the appropriate arches. sometimes
incomplete
since they don't include secondary arches.
I wanted to get some feedback. and see if there are other cases we should add.
+%multilib32 sparc sparcv8 sparcv9 sparcv9v ppc s390
+%multilib64 x86_64 sparc64 sparc64v ppc64 s390x
Remind me what the asymmetry is for here? Why is %{ix86} not in
%{multilib32} ?
In general I'd kind of prefer to see headers modified to use gcc's
predefines for __SIZEOF_LONG__ and friends instead, but I'll take what I
can get.
- ajax
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: Wi-Fi Question
On Tue, Oct 27, 2009 at 12:24:10PM -0400, Martin Dubuc wrote: On most laptops, there is a way to disable Wi-Fi either through function keys or kill switch. I am wondering if there is a way programmatically speaking to figure out whether or not Wi-Fi is currently disabled because the user has pressed the Wi-Fi function key or turned Wi-Fi off with the kill switch. You can install rfkill package and use same-named command: % rfkill list 0: tpacpi_bluetooth_sw: Bluetooth Soft blocked: yes Hard blocked: no 2: phy0: Wireless LAN Soft blocked: no Hard blocked: no -- Tomasz TorczThere exists no separation between gods and men: xmpp: zdzich...@chrome.pl one blends softly casual into the other. pgpYJL4F0my8I.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: proposed macro deffinitions for F-13
On Tuesday 27 October 2009 01:16:46 pm Adam Jackson wrote:
On Tue, 2009-10-27 at 12:40 -0500, Dennis Gilmore wrote:
Id like to get some feedback on the patches that i'm proposing for F-13.
quite a few packages that need to deal with differences between
32bit/64bit or multilib arches have defines for the appropriate arches.
sometimes incomplete since they don't include secondary arches.
I wanted to get some feedback. and see if there are other cases we should
add.
+%multilib32 sparc sparcv8 sparcv9 sparcv9v ppc s390
+%multilib64 x86_64 sparc64 sparc64v ppc64 s390x
Remind me what the asymmetry is for here? Why is %{ix86} not in
%{multilib32} ?
In general I'd kind of prefer to see headers modified to use gcc's
predefines for __SIZEOF_LONG__ and friends instead, but I'll take what I
can get.
it should be the attached patch. the initial one was based on what gcc does
in its spec. it treats %{ix86} as not being multilib.
+%multilib32 %{ix86} %{sparc32} ppc s390
+%multilib64 x86_64 %{sparc64} ppc64 s390x
--- redhat-rpm-config-9.0.3-orig/macros 2009-10-27 10:18:01.0 -0500
+++ redhat-rpm-config-9.0.3/macros 2009-10-27 12:14:24.0 -0500
@@ -277,3 +277,7 @@
%global __find_requires /bin/sh -c %{?__filter_req_cmd} %{__deploop R} %{?__filter_from_req} \
}
+#==
+# Set up multilib arch definitions
+%multilib32 sparc sparcv8 sparcv9 sparcv9v ppc s390
+%multilib64 x86_64 sparc64 sparc64v ppc64 s390x
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 (in Rawhide) is about to happen
But with with older releases I don't messing with people configuration files since I would not want to break an existing configuration... Still never suggested that. Note, there is a number of people who are currently running with correctly configured v4 server... I would hate to mess those people up.. Of course. So push an F-11 update where whatever configuration never mentions v4 and doesn't work for v4, doesn't advertise v4. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
KDE-SIG weekly report (44/2009)
This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. -- = Weekly KDE Summary = Week: 44/2009 Time: 2009-10-27 14:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-10-27 Meeting minutes: http://meetbot.fedoraproject.org/fedora- meeting/2009-10-27/fedora-meeting.2009-10-27-14.06.html Meeting log: http://meetbot.fedoraproject.org/fedora- meeting/2009-10-27/fedora-meeting.2009-10-27-14.06.log.html -- = Participants = * BenBoeckel * EikeHein * JaroslavReznik * KevinKofler * LukasTinkl * MaryEllenFoster * RexDieter * SebastianVahl * StevenParrish * ThanNgo * ThomasJanssen * nucleo -- = Agenda = * topics to discuss: o Final Fedora 12 artwork o Status of eigen2 o qt-4.5.3: updates, F-12 o soprano status: sesame, virtuoso = Summary = o Final Fedora 12 artwork: * Current status of KSplash theme for Constantine [1] * This needs to be adapted for KDM theme. o Status of eigen2: * eigen2 was downgraded to 2.0.6 in F-12 and all depending packages were rebuilt and tagged. o qt-4.5.3: updates, F-12: * RexDieter asked about the handling of qt-4.5.3 in F-12 (updates-testing vs. F-12 final). * 2 issues are known so far: - Problems with qt-4.5.3 and the qt4 build of Opera. - 3-star-echo-mode causes the auth dialogs to pause/freeze. (kde#211250) [2] * F-12 final is preferred but awaiting feedback from ThanNgo first. o soprano status: sesame, virtuoso: * MaryEllenFoster gave a status update of her work on soprano-sesame2 backend: - https://fedoraproject.org/wiki/MaryEllenFoster/SopranoSesame [3] - There a still a lot of JPackage packages which needs to be reviewed or updated. * Virtuoso will not be working properly until KDE 4.4. gets released or the relevant changes gets backported. * virtuoso-opensource-5.0.12 packages are built as updates in F-12. * soprano-2.3.65 with virtuoso support is built in devel branch (also available in kde-unstable repositories at kde-redhat). o Open discussion: * gtk-qt-engine was replaced by kcm-gtk. -- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-11-03 -- = Links = [1] http://rezza.hofyland.cz/fedora/artwork/f12/constantine-ksplash- rain-80.png [2] https://bugs.kde.org/show_bug.cgi?id=211250 [3] https://fedoraproject.org/wiki/MaryEllenFoster/SopranoSesame 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: RFC: proposed macro deffinitions for F-13
On Tue, Oct 27, 2009 at 01:24:33PM -0500, Dennis Gilmore wrote:
it should be the attached patch. the initial one was based on what gcc does
in its spec. it treats %{ix86} as not being multilib.
That's because %{ix86} gcc isn't multilib capable, unlike e.g. ppc/ppc64
or sparcv9/sparc64 where the support is symmetric (32-bit gcc can compile
64-bit code and vice versa), on x86_64 you need x86_64 gcc to be able to
compile 64-bit stuff.
Jakub
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: proposed macro deffinitions for F-13
Dennis Gilmore wrote:
On Tuesday 27 October 2009 12:45:10 pm Eric Sandeen wrote:
Dennis Gilmore wrote:
Hi All,
Id like to get some feedback on the patches that i'm proposing for F-13.
quite a few packages that need to deal with differences between
32bit/64bit or multilib arches have defines for the appropriate arches.
sometimes incomplete since they don't include secondary arches.
I wanted to get some feedback. and see if there are other cases we should
add.
Dennis
I have hacks like this in e2fsprogs.spec for example:
%ifarch %{multilib_arches}
mv -f %{buildroot}%{_includedir}/ext2fs/ext2_types.h \
%{buildroot}%{_includedir}/ext2fs/ext2_types-%{_arch}.h
install -p -m 644 %{SOURCE1} %{buildroot}%{_includedir}/ext2fs/ext2_types.h
%endif
Unless I'm doing a Bad Thing here, maybe some macros to facilitate this
type of header mangling for multiarch?
right now you need to define multilib_arches for that to work with my
proposed
changes you could drop your defines and use
%ifarch %{multilib64} %{multilib32}
Right, I was hoping for maybe some macros to make my above mess simpler;
%{do_magic_header_stuff} header1.h header2.h ...
-Eric
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wi-Fi Question
On 27. okt. 2009 19:18, Tomasz Torcz wrote: You can install rfkill package and use same-named command: Nice app. Thanks for the tip. But does anyone have any idea about how to disable the hardware kill switch, when linux insists it is enabled no matter what position the switch is really set to: - WLAN enabled (hardware switch set to On): # rfkill list 0: hci0: Bluetooth Soft blocked: no Hard blocked: no 1: phy0: Wireless LAN Soft blocked: no Hard blocked: yes - Switching to off shows this in the log: atkbd.c: Unknown key pressed (translated set 2, code 0xf1 on isa0060/serio0). atkbd.c: Use 'setkeycodes e071 keycode' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xf1 on isa0060/serio0). atkbd.c: Use 'setkeycodes e071 keycode' to make it known. # rfkill list 0: hci0: Bluetooth Soft blocked: no Hard blocked: no 1: phy0: Wireless LAN Soft blocked: no Hard blocked: yes Still no luck... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: proposed macro deffinitions for F-13
On Tue, Oct 27, 2009 at 12:40:14PM -0500, Dennis Gilmore wrote:
+# arch macro for all supported 32 bit builds
+%32bitarches %{ix86} %{sparc32} %{arm} s390
+# arch macro for all supported 64 bit builds
+%64bitarches x86_64 %{sparc64} ia64 s390x %{alpha}
missing ppc and ppc64 respectively here, aren't you?
josh
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: proposed macro deffinitions for F-13
On Tuesday 27 October 2009 02:17:57 pm Josh Boyer wrote:
On Tue, Oct 27, 2009 at 12:40:14PM -0500, Dennis Gilmore wrote:
+# arch macro for all supported 32 bit builds
+%32bitarches %{ix86} %{sparc32} %{arm} s390
+# arch macro for all supported 64 bit builds
+%64bitarches x86_64 %{sparc64} ia64 s390x %{alpha}
missing ppc and ppc64 respectively here, aren't you?
josh
indeed i am sorry this should be better
Dennis
--- rpm-4.7.1/macros.in.orig 2009-10-27 11:36:12.0 -0500
+++ rpm-4.7.1/macros.in 2009-10-27 14:29:23.0 -0500
@@ -1194,11 +1194,23 @@
#--
# arch macro for all supported Sparc processors
%sparc sparc sparcv8 sparcv9 sparcv9v sparc64 sparc64v
+# arch macro for all supported sparc32 bit builds
+%sparc32 sparc sparcv8 sparcv9 sparcv9v
+# arch macro for all supported sparc64 bit builds
+%sparc64 sparc64 sparc64v
#--
# arch macro for all supported Alpha processors
%alpha alpha alphaev56 alphaev6 alphaev67
+
+#--
+# arch macro for all supported 32 bit builds
+%32bitarches %{ix86} %{sparc32} %{arm} s390 ppc
+# arch macro for all supported 64 bit builds
+%64bitarches x86_64 %{sparc64} ia64 s390x %{alpha} ppc64
+
+
#
# Use in %install to generate locale specific file lists. For example,
#
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: Wi-Fi Question
On 10/27/2009 03:03 PM, Ola Thoresen wrote: On 27. okt. 2009 19:18, Tomasz Torcz wrote: You can install rfkill package and use same-named command: Nice app. Thanks for the tip. But does anyone have any idea about how to disable the hardware kill switch, when linux insists it is enabled no matter what position the switch is really set to: AIUI, this means there's a physical switch somewhere on the device. -- Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wi-Fi Question
This is a very nice tool. Unfortunately, on my system running Fedora 11, I get the following erro: Can't open RFKILL control device: No such file or directory Using strace, I discovered that rfkill is trying to open path /dev/rfkill, but this path does not exist on my system. Instead, it should try to open path /sys/class/rfkill. Martin On Tue, Oct 27, 2009 at 2:18 PM, Tomasz Torcz to...@pipebreaker.pl wrote: On Tue, Oct 27, 2009 at 12:24:10PM -0400, Martin Dubuc wrote: On most laptops, there is a way to disable Wi-Fi either through function keys or kill switch. I am wondering if there is a way programmatically speaking to figure out whether or not Wi-Fi is currently disabled because the user has pressed the Wi-Fi function key or turned Wi-Fi off with the kill switch. You can install rfkill package and use same-named command: % rfkill list 0: tpacpi_bluetooth_sw: Bluetooth Soft blocked: yes Hard blocked: no 2: phy0: Wireless LAN Soft blocked: no Hard blocked: no -- Tomasz TorczThere exists no separation between gods and men: xmpp: zdzich...@chrome.pl one blends softly casual into the other. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wi-Fi Question
On Tue, Oct 27, 2009 at 08:03:54PM +0100, Ola Thoresen wrote: Nice app. Thanks for the tip. But does anyone have any idea about how to disable the hardware kill switch, when linux insists it is enabled no matter what position the switch is really set to: What hardware is this? -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: proposed macro deffinitions for F-13
On Tue, 2009-10-27 at 12:40 -0500, Dennis Gilmore wrote: Id like to get some feedback on the patches that i'm proposing for F-13. quite a few packages that need to deal with differences between 32bit/64bit or multilib arches have defines for the appropriate arches. sometimes incomplete since they don't include secondary arches. I'm not really a fan of growing more macro goo, particularly if it's Fedora specific macro goo :/ -- 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: RFC: proposed macro deffinitions for F-13
On Tuesday 27 October 2009 03:17:15 pm Jesse Keating wrote: On Tue, 2009-10-27 at 12:40 -0500, Dennis Gilmore wrote: Id like to get some feedback on the patches that i'm proposing for F-13. quite a few packages that need to deal with differences between 32bit/64bit or multilib arches have defines for the appropriate arches. sometimes incomplete since they don't include secondary arches. I'm not really a fan of growing more macro goo, particularly if it's Fedora specific macro goo :/ the multilib ones were the only ones i intended to put in redhat-rpm-config though im just as happy to try and get it into rpm. the rest i had intended to get into rpm. Dennis 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 (in Rawhide) is about to happen
On 10/27/2009 02:33 PM, Roland McGrath wrote: But with with older releases I don't messing with people configuration files since I would not want to break an existing configuration... Still never suggested that. Note, there is a number of people who are currently running with correctly configured v4 server... I would hate to mess those people up.. Of course. So push an F-11 update where whatever configuration never mentions v4 and doesn't work for v4, doesn't advertise v4. Not sure how I would do this without the update being called a regression... any update that disables features does not seem like a good thing... 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 (in Rawhide) is about to happen
On 10/26/2009 04:06 PM, Frank Ch. Eigler wrote: Steve Dickson ste...@redhat.com writes: [...] Unfortunately, this sounds like only. Is it out of the question to make the client look for this case (an upgraded client in an existing unupgraded, unchanged network) and handle it? We talked about it... See [...] But in the end, I decided not to do this since its not clear how the change would interact with other NFS servers... It's a bit odd that we're about to push a backward-incompatible change into Fedora, just in case non-Fedora servers are around. Well the reason for the incompatibility is the simple fact that the Linux server is a bit behind the rest of the servers out there when it comes to this particular type of v4 support... Note, I've been pushing kernel patches to for over a year now (which are in currently in the F-12) which would bring the server up to speed in this area... but they gained any priority with the maintainer... until recently... steved. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: proposed macro deffinitions for F-13
On Tuesday 27 October 2009, Adam Jackson wrote:
+%multilib32 sparc sparcv8 sparcv9 sparcv9v ppc s390
+%multilib64 x86_64 sparc64 sparc64v ppc64 s390x
Remind me what the asymmetry is for here? Why is %{ix86} not in
%{multilib32} ?
Hm, maybe a stupid question: in what sense are %{ix86} multilib in the first
place?
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: proposed macro deffinitions for F-13
On Tuesday 27 October 2009 03:48:13 pm Ville Skyttä wrote:
On Tuesday 27 October 2009, Adam Jackson wrote:
+%multilib32 sparc sparcv8 sparcv9 sparcv9v ppc s390
+%multilib64 x86_64 sparc64 sparc64v ppc64 s390x
Remind me what the asymmetry is for here? Why is %{ix86} not in
%{multilib32} ?
Hm, maybe a stupid question: in what sense are %{ix86} multilib in the
first place?
when you install %{ix86} packages on a x86_64 system. same for ppc and
%{sparc32} and s390.
Dennis
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 (in Rawhide) is about to happen
SD == Steve Dickson ste...@redhat.com writes: SD On the server (Which is suggested): Add the following entry to the SD /etc/exports file: SD / *(ro,fsid=0) SD Note: 'fsid=0' is explained in the exports(5) man pages. Could someone comment on any potential security issues that exporting the root in this way exposes? If all of my exported filesystems happen to live under /export, can I export that directory instead of '/' and have things work properly? If, for whatever reason, I need to export a file system that doesn't live in /export, would I still be able to mount it? - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wi-Fi Question
On 10/27/2009 03:49 PM, Martin Dubuc wrote: This is a very nice tool. Unfortunately, on my system running Fedora 11, I get the following erro: Can't open RFKILL control device: No such file or directory Using strace, I discovered that rfkill is trying to open path /dev/rfkill, but this path does not exist on my system. Instead, it should try to open path /sys/class/rfkill. Yep, that feature isn't in kernels that old. Martin On Tue, Oct 27, 2009 at 2:18 PM, Tomasz Torcz to...@pipebreaker.pl wrote: On Tue, Oct 27, 2009 at 12:24:10PM -0400, Martin Dubuc wrote: On most laptops, there is a way to disable Wi-Fi either through function keys or kill switch. I am wondering if there is a way programmatically speaking to figure out whether or not Wi-Fi is currently disabled because the user has pressed the Wi-Fi function key or turned Wi-Fi off with the kill switch. You can install rfkill package and use same-named command: % rfkill list 0: tpacpi_bluetooth_sw: Bluetooth Soft blocked: yes Hard blocked: no 2: phy0: Wireless LAN Soft blocked: no Hard blocked: no -- Tomasz TorczThere exists no separation between gods and men: xmpp: zdzich...@chrome.pl one blends softly casual into the other. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Peter For some reason it has always seemed to me that the term software engineering contains some very optimistic assumptions about the nature of reality. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wi-Fi Question
On Tue, Oct 27, 2009 at 03:49:35PM -0400, Martin Dubuc wrote: This is a very nice tool. Unfortunately, on my system running Fedora 11, I get the following erro: Can't open RFKILL control device: No such file or directory Using strace, I discovered that rfkill is trying to open path /dev/rfkill, but this path does not exist on my system. Instead, it should try to open path /sys/class/rfkill. No, it shouldn't -- not the same thing. As Peter Jones pointed-out, you need a newer kernel for that tool to work. Hth... John -- John W. LinvilleLinux should be at the core linvi...@redhat.com of your literate lifestyle. -- 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 (in Rawhide) is about to happen
Of course. So push an F-11 update where whatever configuration never mentions v4 and doesn't work for v4, doesn't advertise v4. Not sure how I would do this without the update being called a regression... any update that disables features does not seem like a good thing... I described an update that disables FEATURES YOU SAID DO NOT WORK. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wi-Fi Question
On 27. okt. 2009 21:10, Matthew Garrett wrote: On Tue, Oct 27, 2009 at 08:03:54PM +0100, Ola Thoresen wrote: Nice app. Thanks for the tip. But does anyone have any idea about how to disable the hardware kill switch, when linux insists it is enabled no matter what position the switch is really set to: What hardware is this? 02:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02) (And it is the physical switch I am turning on and off) Has had this issue for years (really). Here is a message from 2007 to this list about it: http://www.opensubscriber.com/message/fedora-devel-list@redhat.com/7502379.html - With a link to an ubuntuforum-thread about the same issue. Not really expecting a fix now, but if anyone is interessted, I can submit a bug or try different kernels or whatever you need. Rgds. Ola (T) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wi-Fi Question
On Tue, Oct 27, 2009 at 10:40:30PM +0100, Ola Thoresen wrote: On 27. okt. 2009 21:10, Matthew Garrett wrote: What hardware is this? 02:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02) (And it is the physical switch I am turning on and off) What's it plugged into? -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Packaging Survey - May 2009
On Fri, 29 May 2009 12:55:50 -0400, Rahul Sundaram sunda...@fedoraproject.org wrote: On 05/29/2009 07:34 PM, Mat Booth wrote: I don't think JEP should be on that list. I've used it in few commercial products and its a thousand dollars a pop for a source code licence: http://www.singularsys.com/order/ JEP in the wiki is linked to http://sourceforge.net/projects/jep/. Are you even talking about the same software? at the top of the sourceforge link you provided, it say As of 2008-09-29 00:00, this project may now be found at http://www.singularsys.com/jep; so yes, it's the same software -- James Cassell -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Notice: Fedora 12 Tagging Status Update
On Wed, 2009-10-21 at 16:18 -0400, Warren Togami wrote: 5) How many untagged packages are there? koji list-tagged --latest dist-f12-updates-candidate I ran this today (just for kicks). It gives back 323 packages. Even with false positives, it a large amount for zero day updates. This is just FYI. The original e-mail was about removing a backlog of 250+ packages waiting in Bodhi. -- Bojan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-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 GEORGE GIANNAKIS georgios.giannakis.stav...@gmail.com changed: What|Removed |Added CC||georgios.giannakis.stavros@ ||gmail.com --- Comment #11 from GEORGE GIANNAKIS georgios.giannakis.stav...@gmail.com 2009-10-27 12:22:42 EDT --- Eftimios TSIGROS (BANNER)! -- 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-Email-Date-Format/EL-4 perl-Email-Date-Format.spec, NONE, 1.1 sources, 1.1, 1.2
Author: spot
Update of /cvs/pkgs/rpms/perl-Email-Date-Format/EL-4
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv20336/EL-4
Modified Files:
sources
Added Files:
perl-Email-Date-Format.spec
Log Message:
epel
--- NEW FILE perl-Email-Date-Format.spec ---
Name: perl-Email-Date-Format
Version:1.002
Release:4%{?dist}
Summary:Produce RFC 2822 date strings
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/Email-Date-Format/
Source0:
http://search.cpan.org/CPAN/authors/id/R/RJ/RJBS/Email-Date-Format-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: perl(ExtUtils::MakeMaker), perl(Test::More), perl(Time::Local)
BuildRequires: perl(Test::Pod), perl(Test::Pod::Coverage)
BuildArch: noarch
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
%description
This module can be used to emit RFC 2822 style date strings.
%prep
%setup -q -n Email-Date-Format-%{version}
%build
sed -i '/LICENSE/ d' Makefile.PL
%{__perl} Makefile.PL INSTALLDIRS=vendor
make
%install
rm -rf $RPM_BUILD_ROOT
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null ';'
chmod -R u+w $RPM_BUILD_ROOT/*
%check
make test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc README LICENSE
%{perl_vendorlib}/Email/
%{_mandir}/man3/*.3*
%changelog
* Sat Jul 25 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.002-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.002-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
* Sat Feb 2 2008 Tom spot Callaway tcall...@redhat.com - 1.002-2
- rebuild for new perl
* Wed Dec 19 2007 Tom spot Callaway tcall...@redhat.com - 1.002-1
- Initial package for Fedora
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Email-Date-Format/EL-4/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 20 Dec 2007 19:33:58 - 1.1
+++ sources 27 Oct 2009 18:10:46 - 1.2
@@ -0,0 +1 @@
+7ae25275da6ab272aa8b40141eac9f82 Email-Date-Format-1.002.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-Email-Date-Format/EL-5 perl-Email-Date-Format.spec, NONE, 1.1 sources, 1.1, 1.2
Author: spot
Update of /cvs/pkgs/rpms/perl-Email-Date-Format/EL-5
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv20336/EL-5
Modified Files:
sources
Added Files:
perl-Email-Date-Format.spec
Log Message:
epel
--- NEW FILE perl-Email-Date-Format.spec ---
Name: perl-Email-Date-Format
Version:1.002
Release:4%{?dist}
Summary:Produce RFC 2822 date strings
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/Email-Date-Format/
Source0:
http://search.cpan.org/CPAN/authors/id/R/RJ/RJBS/Email-Date-Format-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: perl(ExtUtils::MakeMaker), perl(Test::More), perl(Time::Local)
BuildRequires: perl(Test::Pod), perl(Test::Pod::Coverage)
BuildArch: noarch
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
%description
This module can be used to emit RFC 2822 style date strings.
%prep
%setup -q -n Email-Date-Format-%{version}
%build
sed -i '/LICENSE/ d' Makefile.PL
%{__perl} Makefile.PL INSTALLDIRS=vendor
make
%install
rm -rf $RPM_BUILD_ROOT
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null ';'
chmod -R u+w $RPM_BUILD_ROOT/*
%check
make test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc README LICENSE
%{perl_vendorlib}/Email/
%{_mandir}/man3/*.3*
%changelog
* Sat Jul 25 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.002-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.002-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
* Sat Feb 2 2008 Tom spot Callaway tcall...@redhat.com - 1.002-2
- rebuild for new perl
* Wed Dec 19 2007 Tom spot Callaway tcall...@redhat.com - 1.002-1
- Initial package for Fedora
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Email-Date-Format/EL-5/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 20 Dec 2007 19:33:58 - 1.1
+++ sources 27 Oct 2009 18:10:46 - 1.2
@@ -0,0 +1 @@
+7ae25275da6ab272aa8b40141eac9f82 Email-Date-Format-1.002.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-Email-Date-Format/EL-4 perl-Email-Date-Format.spec, 1.1, 1.2
Author: spot
Update of /cvs/pkgs/rpms/perl-Email-Date-Format/EL-4
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv20960
Modified Files:
perl-Email-Date-Format.spec
Log Message:
el4
Index: perl-Email-Date-Format.spec
===
RCS file:
/cvs/pkgs/rpms/perl-Email-Date-Format/EL-4/perl-Email-Date-Format.spec,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- perl-Email-Date-Format.spec 27 Oct 2009 18:10:46 - 1.1
+++ perl-Email-Date-Format.spec 27 Oct 2009 18:13:05 - 1.2
@@ -1,6 +1,6 @@
Name: perl-Email-Date-Format
Version:1.002
-Release:4%{?dist}
+Release:4%{?dist}.1
Summary:Produce RFC 2822 date strings
Group: Development/Libraries
License:GPL+ or Artistic
--
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-SNMP_Session/EL-5 perl-SNMP_Session.spec, 1.5, 1.6 sources, 1.3, 1.4
Author: spot
Update of /cvs/pkgs/rpms/perl-SNMP_Session/EL-5
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv22215
Modified Files:
perl-SNMP_Session.spec sources
Log Message:
update to current
Index: perl-SNMP_Session.spec
===
RCS file: /cvs/pkgs/rpms/perl-SNMP_Session/EL-5/perl-SNMP_Session.spec,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- perl-SNMP_Session.spec 7 Sep 2006 13:58:07 - 1.5
+++ perl-SNMP_Session.spec 27 Oct 2009 18:18:53 - 1.6
@@ -1,15 +1,16 @@
Name: perl-SNMP_Session
-Version:1.08
+Version:1.12
Release:3%{?dist}
Summary:SNMP support for Perl 5
Group: Development/Libraries
-License:Artistic
+License:Artistic 2.0
URL:http://www.switch.ch/misc/leinen/snmp/perl/
Source0:
http://www.switch.ch/misc/leinen/snmp/perl/dist/SNMP_Session-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
+BuildRequires: perl(ExtUtils::MakeMaker)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
@@ -53,6 +54,21 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Sun Jul 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.12-3
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
+
+* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.12-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
+
+* Tue Apr 22 2008 Tom spot Callaway tcall...@redhat.com - 1.12-1
+- update to 1.12 (license change to Artistic 2.0)
+
+* Thu Mar 06 2008 Tom spot Callaway tcall...@redhat.com - 1.08-4.1
+- Rebuild for new perl
+
+* Tue Oct 16 2007 Tom spot Callaway tcall...@redhat.com - 1.08-3.1
+- add BR: perl(ExtUtils::MakeMaker)
+
* Thu Sep 7 2006 Jose Pedro Oliveira jpo at di.uminho.pt - 1.08-3
- Rebuild for FC6.
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-SNMP_Session/EL-5/sources,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- sources 29 Dec 2005 01:51:22 - 1.3
+++ sources 27 Oct 2009 18:18:53 - 1.4
@@ -1 +1 @@
-91ab58bd2c170145436f68578a2705ab SNMP_Session-1.08.tar.gz
+5f6b365b4c3815b13d7a902d94e254af SNMP_Session-1.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-SNMP_Session/EL-5 perl-SNMP_Session.spec,1.6,1.7
Author: spot
Update of /cvs/pkgs/rpms/perl-SNMP_Session/EL-5
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv29483
Modified Files:
perl-SNMP_Session.spec
Log Message:
minor tag bump
Index: perl-SNMP_Session.spec
===
RCS file: /cvs/pkgs/rpms/perl-SNMP_Session/EL-5/perl-SNMP_Session.spec,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -p -r1.6 -r1.7
--- perl-SNMP_Session.spec 27 Oct 2009 18:18:53 - 1.6
+++ perl-SNMP_Session.spec 27 Oct 2009 18:51:34 - 1.7
@@ -1,6 +1,6 @@
Name: perl-SNMP_Session
Version:1.12
-Release:3%{?dist}
+Release:3%{?dist}.1
Summary:SNMP support for Perl 5
Group: Development/Libraries
@@ -54,6 +54,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Tue Oct 27 2009 Tom spot Callaway tcall...@redhat.com - 1.12-3.1
+- minor bump for EL-5
+
* Sun Jul 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.12-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
--
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
