Re: libjpeg-turbo API/ABI bump in F19 (transition from jpeg6 to jpeg8 API/ABI)
On Thu, Oct 18, 2012 at 02:51:01PM -0700, Adam Williamson wrote: > On Thu, 2012-10-18 at 16:43 +0200, Adam Tkac wrote: > > On Thu, Oct 18, 2012 at 10:35:56AM -0400, Bill Nottingham wrote: > > > Adam Tkac (at...@redhat.com) said: > > > > I've just created > > > > https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABI page > > > > which > > > > contains plan how to successfully move from current jpeg6 API/ABI to > > > > more recent > > > > jpeg8 API/ABI for Fedora 19. > > > > > > > > All packages which depends on libjpeg.so will have to be rebuilt. Since > > > > I have > > > > provenpackager privileges, I will cook some script which will rebuild > > > > all > > > > pkgs automatically so no action will be required from maintainers. > > > > > > > > If there are no objections against this approach, I will start with > > > > this task > > > > next week. > > > > > > Ouch. I can see a need for a compat library for some period of time here - > > > the jpeg6 API has certainly been around for quite a long while. > > > > Hm, you are probably right. Since libjpeg is widely used, there might be > > some proprietary > > apps which require it. > > Yeah, I'm with Bill. I note you listed this as the 'contingency plan' > for the feature: > > Contingency Plan > > Create libjpeg-turbo-compat and libjpeg-turbo-compat-devel libraries > with jpeg6 API/ABI and ship them in distro. > > I'd suggest you should just make it a plan from the start to have the > -compat library available as part of the feature (so, really, just drop > step 4 of 'scope'), and have the 'contingency plan' be 'abandon ship and > go back to building with the jpeg6 API'. I agree with this plan and modified the feature page appropriately. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [pkgdb] GeoIP (un)retirement
Hi, On 10/22/2012 10:45 AM, Fedora PackageDB wrote: Package GeoIP in Fedora 17 has been retired by mfleming To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/GeoIP What's the story with this? Has something happened upstream? I currently use GeoIP for proftpd's mod_geoip module, which I'll have to discontinue if GeoIP goes away. Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
> From: Seth Vidal > > On Fri, 19 Oct 2012, Michael Stahnke wrote: > > > On Fri, Oct 19, 2012 at 4:22 PM, Seth Vidal > >> > >> > >> > >> On Fri, 19 Oct 2012, Michael Stahnke wrote: > >> > >>> I (we) completely realize this isn't totally awesome either. This is > >>> a problem when you have a distributed application that is trying to > >>> support the widest variety of host populations we can. > >>> > >>> This request was brought to us by community members, Red Hat > >>> employees, and business partners as well. > >>> > >>> I am happy to discuss other soutions/ideas too though. I am not 100% > >>> convinced my proposal is the best. > >>> > >> > >> I'm less worried about the people requesting the newness b/c they clearly > >> want change. I'm worried about the people who run rhel b/c they > fear change. > > I'm more worried about people with hybrid environments where RHEL is > > at the core for Puppet. (and somewhat how RHEL 7 could shake out) > > > > Do you consider it ok to not be able to have Fedora agents check into > > a RHEL master? > > > > There is a reason I want to move to a clientless configmgmt > infrastructure. > > I do not want to be hogtied like this again. I cannot speak for Fedora infrastructure, but I committed to puppet completely at work at home before realizing the horrible situation that puppet's client/server has forced on its users. While it looks like they're heading in the right direction, it does us early adopters no good to struggle through this incompatibility entanglement. Too much of what once was shown as "the way", if not the best practice, is no longer even supported (e.g., dynamically scoped variables). My first use of puppet required operation from cached resources on stateless Fedora nodes in the event that the network was offline or the "master" otherwise unreachable. I could not make the normal client/server approach work and thus adopted a rsync + cron + puppet agent apply approach as a work around. That to date has still been my best experience with puppet -- it just works because it abandons the requirements imposed by their client/server approach. As for what should be done with Fedora and RHEL I cannot say. It seems all available options stink. On one hand I'd hate to see F17 change, I'm still struggling to adjust my code to be compatible with that. I've had a difficult time keeping my puppet resources in shape for each Fedora release -- six months goes by all to fast when you have many other responsibilities -- puppet was supposed to reduce my workload, right? Right??? If 3.0 lands in F17, that's going to hurt my plans. At the same time, puppet in F17 "as is" is plagued with problems as already mentioned. Argh! "Hogtied" is a very apt description. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
> From: Matthew Miller > To: Development discussions related to Fedora > Cc: epel-devel-l...@redhat.com > Date: 10/19/2012 19:35 > Subject: Re: Fixing Puppet in Fedora/EPEL > Sent by: devel-boun...@lists.fedoraproject.org > > On Fri, Oct 19, 2012 at 04:04:24PM -0700, Michael Stahnke wrote: > > * Move EPEL 6, Fedora >= 17 to use Puppet 3.0. > > Speaking for my previous job, it would really be unfortunate to have a > non-compatible update of puppet in EPEL. Unless accompanied by very loud > trumpets and fireworks beforehand, the day that update went out would be a > very sad and busy day for a number of sysadmins. > > I'm not opposed to putting puppet 3 in, but it'd really be helpful if it > went in as "puppet3" or something, and left the stable version as is, > happily getting security-only updates. Yes, please! Something like that would be great. It was done for bacula (and may still be). I did finally get off bacula2, but it took a long time because I had many clients that couldn't run anything else and updating those clients (OS-wise) had many dependencies of their own. It's a simple unavoidable fact that some systems just cannot stay as current as they ideally should and the dependencies may run very deep and well beyond the realm of software packages and OSes alone. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Sat, Oct 20, 2012 at 1:31 AM, Seth Vidal wrote: > There is a reason I want to move to a clientless configmgmt infrastructure. Could you explain what you mean by "clientless", please? It seems to me that there always needs to be "something" running at the client handling the data from the server, and therefore there needs to be either a protocol or a data format the client and the server have in common. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-OpenOffice-UNO
perl-OpenOffice-UNO has broken dependencies in the rawhide tree: On x86_64: perl-OpenOffice-UNO-0.07-3.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) On i386: perl-OpenOffice-UNO-0.07-3.fc17.i686 requires perl(:MODULE_COMPAT_5.14.2) perl-OpenOffice-UNO-0.07-3.fc17.i686 requires libsal_textenc.so Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
F-18 Branched report: 20121022 changes
Compose started at Mon Oct 22 09:15:27 UTC 2012 Broken deps for x86_64 -- [almanah] almanah-0.8.0-7.fc18.x86_64 requires libedataserverui-3.0.so.3()(64bit) almanah-0.8.0-7.fc18.x86_64 requires libedataserver-1.2.so.16()(64bit) almanah-0.8.0-7.fc18.x86_64 requires libecal-1.2.so.12()(64bit) almanah-0.8.0-7.fc18.x86_64 requires libebook-1.2.so.13()(64bit) [dhcp-forwarder] dhcp-forwarder-upstart-0.10-1801.fc18.noarch requires /sbin/initctl [dustmite] dustmite-1-5.20120304gitcde46e0.fc17.x86_64 requires libphobos-ldc.so.59()(64bit) [evolution-exchange] evolution-exchange-3.5.2-1.fc18.x86_64 requires libedataserverui-3.0.so.3()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedataserver-1.2.so.16()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedata-cal-1.2.so.17()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedata-book-1.2.so.14()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libecal-1.2.so.12()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libebook-1.2.so.13()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libebackend-1.2.so.3()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libcamel-1.2.so.36()(64bit) [fedmsg] fedmsg-0.5.4-4.fc18.noarch requires python-moksha-hub >= 0:1.0.1 [flush] flush-0.9.10-7.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_signals-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) [func] func-0.28-1.fc17.noarch requires smolt [gcc-python-plugin] gcc-python2-debug-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18 gcc-python2-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18 gcc-python3-debug-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18 gcc-python3-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18 [gdb-heap] gdb-heap-0.5-9.fc18.x86_64 requires glibc(x86-64) = 0:2.15 [glom] glom-1.18.6-1.fc17.x86_64 requires libboost_python.so.1.48.0()(64bit) glom-libs-1.18.6-1.fc17.i686 requires libboost_python.so.1.48.0 glom-libs-1.18.6-1.fc17.x86_64 requires libboost_python.so.1.48.0()(64bit) [gnome-do-plugins] gnome-do-plugins-banshee-0.8.4-10.fc18.x86_64 requires mono(Banshee.CollectionIndexer) = 0:2.4.0.0 [gnome-pilot] gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libedataserverui-3.0.so.1()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libedataserver-1.2.so.16()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libecal-1.2.so.11()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libebook-1.2.so.13()(64bit) [gnome-shell-theme-selene] gnome-shell-theme-selene-3.4.0-5.fc18.noarch requires gnome-shell-extensions-user-theme [gwibber] 1:gwibber-3.4.2-3.fc18.i686 requires libgee-0.8.so.0 1:gwibber-3.4.2-3.fc18.x86_64 requires libgee-0.8.so.0()(64bit) [ip-sentinel] ip-sentinel-upstart-0.12-1303.fc18.noarch requires /sbin/initctl [libsyncml] 1:libsyncml-0.4.6-4.fc17.i686 requires libsoup-2.2.so.8 1:libsyncml-0.4.6-4.fc17.x86_64 requires libsoup-2.2.so.8()(64bit) [maniadrive] raydium-1.2-47.fc18.x86_64 requires libode.so.1()(64bit) [mapserver] mapserver-perl-6.0.1-5.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) [milter-greylist] milter-greylist-upstart-4.2.7-1701.fc18.noarch requires /sbin/initctl [mod_pubcookie] mod_pubcookie-3.3.4a-7.fc18.x86_64 requires httpd-mmn = 0:20051115-x86-64 [openvrml] libopenvrml-0.18.9-3.fc18.i686 requires libboost_thread-mt.so.1.48.0 libopenvrml-0.18.9-3.fc18.i686 requires libboost_system-mt.so.1.48.0 libopenvrml-0.18.9-3.fc18.i686 requires libboost_filesystem-mt.so.1.48.0 libopenvrml-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) libopenvrml-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) libopenvrml-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_thread-mt.so.1.48.0 libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_system-mt.so.1.48.0 libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_filesystem-mt.so.1.48.0 libopenvrml-gl-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) libopenvrml-gl-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) libopenvrml-gl-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) openvrml-java-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) ope
[Bug 832644] abi-compliance-checker-1.98.4 is available
https://bugzilla.redhat.com/show_bug.cgi?id=832644 --- Comment #5 from Fedora Update System --- abi-compliance-checker-1.98.4-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/abi-compliance-checker-1.98.4-1.fc17 -- 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 perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Fixing Puppet in Fedora/EPEL
On Mon, 22 Oct 2012, Miloslav Trmač wrote: On Sat, Oct 20, 2012 at 1:31 AM, Seth Vidal wrote: There is a reason I want to move to a clientless configmgmt infrastructure. Could you explain what you mean by "clientless", please? It seems to me that there always needs to be "something" running at the client handling the data from the server, and therefore there needs to be either a protocol or a data format the client and the server have in common. http://ansible.cc It connects via ssh, pushes the code it needs to run over and executes it. You're right that it does require something running on the client: sshd From a software standpoint it assumes you have python installed on the clients, but that's only by default, you could write modules instead in plain shell or in C and it would work just fine. It counts on json for output. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
> From: Seth Vidal > > On Mon, 22 Oct 2012, Miloslav Trmač wrote: > > > On Sat, Oct 20, 2012 at 1:31 AM, Seth Vidal > wrote: > >> There is a reason I want to move to a clientless configmgmt infrastructure. > > > > Could you explain what you mean by "clientless", please? It seems to > > me that there always needs to be "something" running at the client > > handling the data from the server, and therefore there needs to be > > either a protocol or a data format the client and the server have in > > common. > > > http://ansible.cc > > It connects via ssh, pushes the code it needs to run over and executes it. > You're right that it does require something running on the client: sshd > > From a software standpoint it assumes you have python installed on the > clients, but that's only by default, you could write modules instead in > plain shell or in C and it would work just fine. > > It counts on json for output. ansibile is exactly what I've been looking at as a puppet replacement. If anyone has experience with both, I'd greatly appreciate hearing of their experiences. I don't relish the idea of making the conversion, but I really do get the impression life would be simpler with ansible once there. Or am I just falling for that greener grass on the other side of the fence? -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Mon, 22 Oct 2012, john.flor...@dart.biz wrote: ansibile is exactly what I've been looking at as a puppet replacement. If anyone has experience with both, I'd greatly appreciate hearing of their experiences. I don't relish the idea of making the conversion, but I really do get the impression life would be simpler with ansible once there. Or am I just falling for that greener grass on the other side of the fence? Fedora Infrastructure has begun using ansible for some system setup and other orchestration/automation tasks. Our (just beginning) public repos of it are here: http://infrastructure.fedoraproject.org/cgit/ansible.git/ -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 users unable to log in due to cached nsswitch.conf
On 10/17/2012 07:02 PM, Simo Sorce wrote: > This will take time however, in the meanwhile it would be really nice if > we could do it the simple way by just adding sss by default until a > better solution is found. I've posted a patch to do this at the bug: https://bugzilla.redhat.com/show_bug.cgi?id=867473 sssd-client is already installed by default in all but the minimal install. So with this one change things should work as appropriate. Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 863988] perl-Coro-6.09 bundles libecb
https://bugzilla.redhat.com/show_bug.cgi?id=863988 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Coro-6.10-2.fc19 -- 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 perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
tools to catch AttributeError and TypeError in python code?
What is the state of software tools to help catch and prevent AttributeError and TypeError in python code? These two classes of errors occur often in the bugzilla reports for anaconda (recently: https://bugzilla.redhat.com/show_bug.cgi?id=868707 ). I'd like to see fewer AttributeError and TypeError. Because new attributes and types may be created at run time, in general errors may be even harder to find than in languages with static typing. Yet for most python code the set of types and attributes is semi-fixed. There are no changes at run time except due to importing modules which were created long ago. During development, the set of types and attributes changes only in bursts, and often the bursts are weeks apart. The tools for python that I found by searching the web [0][1] seemed to be oriented more towards syntax and style, and not including AttributeError and TypeError. Nothing even came close to the depth and thoroughness of BEAM [2] or Coverity [3] for C/C++. Help? - [0] google: python code checker [1] http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis#Python pychecker pylint [2] http://alexandria.tue.nl/extra2/afstversl/E/523798.pdf (IBM "BEAM" checker [Bugs, Errors, And Mistakes]; Guido Volleberg, 1999) *very* good: finds and prints an execution path which leads to null-pointer errors in C and C++; includes call+return, loop+exit, conditionals, etc. Notably helpful in the development of valgrind itself. [3] http://www.coverity.com/products/quality-advisor.html -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fedora-packaging] [perl-Coro] Work-aroung missing libecb package on build-triggering host
On Mon, Oct 22, 2012 at 10:14:25AM -0500, Rex Dieter wrote:
> On 10/22/2012 10:06 AM, Ralf Corsepius wrote:
> >On 10/22/2012 03:47 PM, Petr Pisar wrote:
> >>commit e00f8293097f8331883f1df35f74be70fbb290b9
> >>Author: Petr Písař
> >>Date: Mon Oct 22 15:46:27 2012 +0200
> >>
> >> Work-aroung missing libecb package on build-triggering host
> >>
> >> perl-Coro.spec |2 +-
> >> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>---
> >>diff --git a/perl-Coro.spec b/perl-Coro.spec
> >>index 50a855d..31589a5 100644
> >>--- a/perl-Coro.spec
> >>+++ b/perl-Coro.spec
> >>@@ -35,7 +35,7 @@ Requires: perl(EV) >= 3
> >> Requires: perl(Event) >= 1.08
> >> Requires: perl(Guard) >= 0.5
> >> Requires: perl(Storable) >= 2.15
> >>-Provides: bundled(libecb) = %(rpm -q libecb --qf '%{VERSION}')
> >>+Provides: bundled(libecb)%(rpm -q libecb --qf ' = %{VERSION}'
> >>2>/dev/null)
> >
> >I could be wrong, but IIRC, calling rpm inside of rpm specs is not
> >allowed in Fedora.
> >
> >Apart of this, what you are doing is rendering your built
> >non-deterministic - Another "strictly forbidden" item.
>
> Agreed. What you're trying to say essentially is that the bundled
> libecb version matches the system/non-bundled version, which really
> doesn't make any sense. I'd suggest you simply remove the
> versioning (or list the real bundled version some other way).
>
This is something like static library. Thus code gets frozen into the package
at build-time. So I concluded it's good idea to know which version of the
library the binary package incorporates.
However if you think this is bad idea I will remove it.
-- Petr
pgp1sT8xn5Tzn.pgp
Description: PGP signature
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: R
On 10/21/2012 11:24 PM, Richard Vickery wrote: > Hi Gang, > > For some strange reason, something has gone wrong with R, the statistics > program. R doesn't know where to find rJava and perhaps the other > programs to run JGR. so I thought I might try uninstalling - and > re-installing - it, but yum won't / can't remove the non-X part. Has > anyone experienced this before? Can you post specific logs? You need to have R-java installed, so please confirm that you do as well. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg / koji error
On 10/18/2012 03:57 AM, Thorsten Leemhuis wrote:
> I'd say the current behaviour is the quite bad, as it leads to different
> results when building with fedpkg and rpmbuild on F18. The real fix
> afaics would be to revert the change and, if wanted, define rhel as 0 in
> Fedora's redhat-rpm-config, too -- but then we obviously need to fix all
> %{!?rhel:foo} statements in current spec files.
>
> Options? Spot, Simone?
Ignoring the fact that this behavior is explicitly what we document that
you should not do in a spec file, for precisely this reason...
There is currently no way to "undefine" a macro at the rpm commandline,
so barring rpm growing that support, setting %rhel to 0 is the only way
to address the original issue that I know of.
~tom
==
Fedora Project
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 863988] perl-Coro-6.09 bundles libecb
https://bugzilla.redhat.com/show_bug.cgi?id=863988 Petr Pisar changed: What|Removed |Added Fixed In Version|perl-Coro-6.10-2.fc19 |perl-Coro-6.10-3.fc19 --- Comment #4 from Petr Pisar --- The bundle() provide has been removed in perl-Coro-6.10-3.fc19 and perl-Coro-6.09-4.fc18. -- 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 perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: tools to catch AttributeError and TypeError in python code?
> From: John Reiser > To: Development discussions related to Fedora > Date: 10/22/2012 11:25 > Subject: tools to catch AttributeError and TypeError in python code? > Sent by: devel-boun...@lists.fedoraproject.org > > What is the state of software tools to help catch and prevent > AttributeError and TypeError in python code? These two classes > of errors occur often in the bugzilla reports for anaconda > (recently: https://bugzilla.redhat.com/show_bug.cgi?id=868707 ). > I'd like to see fewer AttributeError and TypeError. > > Because new attributes and types may be created at run time, in general > errors may be even harder to find than in languages with static typing. > Yet for most python code the set of types and attributes is semi-fixed. > There are no changes at run time except due to importing modules > which were created long ago. During development, the set of types and > attributes changes only in bursts, and often the bursts are weeks apart. > > The tools for python that I found by searching the web [0][1] seemed to be > oriented more towards syntax and style, and not including AttributeError > and TypeError. Nothing even came close to the depth and thoroughness > of BEAM [2] or Coverity [3] for C/C++. Help? > > - > [0] google: python code checker > [1] http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis#Python >pychecker >pylint > [2] http://alexandria.tue.nl/extra2/afstversl/E/523798.pdf >(IBM "BEAM" checker [Bugs, Errors, And Mistakes]; Guido Volleberg, 1999) >*very* good: finds and prints an execution path which leads to null-pointer >errors in C and C++; includes call+return, loop+exit, conditionals, etc. >Notably helpful in the development of valgrind itself. > [3] http://www.coverity.com/products/quality-advisor.html I'm having pretty good success with PyCharm from JetBrains. Nothing will ever be as good as those for statically typed languages, but it's darned good at catching all sorts of things prior to run-time. My python code has improved in reliability significantly thanks to PyCharm. I've never been much of an IDE person in the past, but this tool has convinced me that they do have their uses. I focus far more on the goal now. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Formal request: non-responsive maintainer Gavin Romig-Koch for squeak-vm
Bug here, with no response: https://bugzilla.redhat.com/show_bug.cgi?id=861970 Gavin isn't responding to bugs or to email. Note that also note that Jaroslav Škarvada has an updated package in testing, has asked to become a co-maintainer, and in fact has been trying to get a response for almost a year. I checked with Jaroslav and he's still ready to take over. I'm an interested party because I want to package Scratch, and an updated Squeak VM will significantly simplify that package -- and make sound work. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 863988] perl-Coro-6.09 bundles libecb
https://bugzilla.redhat.com/show_bug.cgi?id=863988 --- Comment #5 from Fedora Update System --- perl-Coro-6.09-4.fc18, libecb-0.20121008-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/libecb-0.20121008-1.fc18,perl-Coro-6.09-4.fc18 -- 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 perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: fedpkg / koji error
On 10/22/2012 05:56 PM, Tom Callaway wrote:
On 10/18/2012 03:57 AM, Thorsten Leemhuis wrote:
I'd say the current behaviour is the quite bad, as it leads to different
results when building with fedpkg and rpmbuild on F18. The real fix
afaics would be to revert the change and, if wanted, define rhel as 0 in
Fedora's redhat-rpm-config, too -- but then we obviously need to fix all
%{!?rhel:foo} statements in current spec files.
Options? Spot, Simone?
Ignoring the fact that this behavior is explicitly what we document that
you should not do in a spec file, for precisely this reason...
There is currently no way to "undefine" a macro at the rpm commandline,
rpmbuild --define " %{nil}" ?
so barring rpm growing that support, setting %rhel to 0 is the only way
to address the original issue that I know of.
Couldn't you let pass koji --define "rhel %{nil}" or let
mock invoke rpmbuild --define "rhel %{nil}" ?
I am using a similar trick when building "other rpm-based-distros"
src.rpms on Fedora.
Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [pkgdb] GeoIP (un)retirement
On Mon, 22 Oct 2012, Paul Howarth wrote:
On 10/22/2012 10:45 AM, Fedora PackageDB wrote:
Package GeoIP in Fedora 17 has been retired by mfleming
To make changes to this package see:
https://admin.fedoraproject.org/pkgdb/acls/name/GeoIP
What's the story with this? Has something happened upstream?
I currently use GeoIP for proftpd's mod_geoip module, which I'll have to
discontinue if GeoIP goes away.
Perhaps look at "geome". I'm upstream, so I could add a mode to match
GeoIP output if that matters to you.
[paul@thinkpad ~]$ geome
{"city": "Toronto", "street_number": "700", "country": "Canada",
"region": "Ontario", "long": -79.4031778, "county": "Toronto Division",
"street": "King St W", "postal_code": "M6J", "country_code": "CA",
"lat": 43.6440866, "accuracy": 30.0}
Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updating vpnc-script for openconnect and unbound
On Sun, 21 Oct 2012, Erinn Looney-Triggs wrote: I haven't been able to get a lot of traction with this, but I figured a shot at this mailing list might help. I have written a patch against the Fedora 18 version of vpnc-script to allow it to detect that unbound is running and to set forwarders appropriately for resolving internal IPs after a VPN connection is made. That patch is attached. Great! Thank you! This is very similar to work that was done on openswan here: http://osdir.com/ml/fedora-devel-list/2012-06/msg02650.html Note your attached patch is based on an older version of the openswan patch. You should add "unbound-control flush_requestlist" as well when the tunnel goes up or down, so the outstanding queries are also dropped. There is also a bug open for this here: https://bugzilla.redhat.com/show_bug.cgi?id=865092 Added my comment there as well. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Mon, Oct 22, 2012 at 5:31 AM, wrote: >> From: Seth Vidal >> >> On Fri, 19 Oct 2012, Michael Stahnke wrote: >> >> > On Fri, Oct 19, 2012 at 4:22 PM, Seth Vidal >> >> >> >> >> >> >> >> On Fri, 19 Oct 2012, Michael Stahnke wrote: >> >> >> >>> I (we) completely realize this isn't totally awesome either. This is >> >>> a problem when you have a distributed application that is trying to >> >>> support the widest variety of host populations we can. >> >>> >> >>> This request was brought to us by community members, Red Hat >> >>> employees, and business partners as well. >> >>> >> >>> I am happy to discuss other soutions/ideas too though. I am not 100% >> >>> convinced my proposal is the best. >> >>> >> >> >> >> I'm less worried about the people requesting the newness b/c they >> >> clearly >> >> want change. I'm worried about the people who run rhel b/c they >> fear change. >> > I'm more worried about people with hybrid environments where RHEL is >> > at the core for Puppet. (and somewhat how RHEL 7 could shake out) >> > >> > Do you consider it ok to not be able to have Fedora agents check into >> > a RHEL master? >> > >> >> There is a reason I want to move to a clientless configmgmt >> infrastructure. >> >> I do not want to be hogtied like this again. > > > I cannot speak for Fedora infrastructure, but I committed to puppet > completely at work at home before realizing the horrible situation that > puppet's client/server has forced on its users. While it looks like they're > heading in the right direction, it does us early adopters no good to > struggle through this incompatibility entanglement. Too much of what once > was shown as "the way", if not the best practice, is no longer even > supported (e.g., dynamically scoped variables). > > My first use of puppet required operation from cached resources on stateless > Fedora nodes in the event that the network was offline or the "master" > otherwise unreachable. I could not make the normal client/server approach > work and thus adopted a rsync + cron + puppet agent apply approach as a work > around. That to date has still been my best experience with puppet -- it > just works because it abandons the requirements imposed by their > client/server approach. > > As for what should be done with Fedora and RHEL I cannot say. It seems all > available options stink. On one hand I'd hate to see F17 change, I'm still > struggling to adjust my code to be compatible with that. I've had a > difficult time keeping my puppet resources in shape for each Fedora release > -- six months goes by all to fast when you have many other responsibilities > -- puppet was supposed to reduce my workload, right? Right??? If 3.0 lands > in F17, that's going to hurt my plans. At the same time, puppet in F17 "as > is" is plagued with problems as already mentioned. > > Argh! "Hogtied" is a very apt description. I'm sorry if your Puppet experience isn't completely awesome. Posting on the Puppet users list might be more appropriate. In this case I am looking for packaging options/opinions on Puppet with regards to Fedora and EPEL. > > -- > John Florian > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
> From: Michael Stahnke > > On Mon, Oct 22, 2012 at 5:31 AM, wrote: > >> From: Seth Vidal > >> > >> On Fri, 19 Oct 2012, Michael Stahnke wrote: > >> > >> > On Fri, Oct 19, 2012 at 4:22 PM, Seth Vidal > >> >> > >> >> > >> >> > >> >> On Fri, 19 Oct 2012, Michael Stahnke wrote: > >> >> > >> >>> I (we) completely realize this isn't totally awesome either. This is > >> >>> a problem when you have a distributed application that is trying to > >> >>> support the widest variety of host populations we can. > >> >>> > >> >>> This request was brought to us by community members, Red Hat > >> >>> employees, and business partners as well. > >> >>> > >> >>> I am happy to discuss other soutions/ideas too though. I am not 100% > >> >>> convinced my proposal is the best. > >> >>> > >> >> > >> >> I'm less worried about the people requesting the newness b/c they > >> >> clearly > >> >> want change. I'm worried about the people who run rhel b/c they > >> fear change. > >> > I'm more worried about people with hybrid environments where RHEL is > >> > at the core for Puppet. (and somewhat how RHEL 7 could shake out) > >> > > >> > Do you consider it ok to not be able to have Fedora agents check into > >> > a RHEL master? > >> > > >> > >> There is a reason I want to move to a clientless configmgmt > >> infrastructure. > >> > >> I do not want to be hogtied like this again. > > > > > > I cannot speak for Fedora infrastructure, but I committed to puppet > > completely at work at home before realizing the horrible situation that > > puppet's client/server has forced on its users. While it looks like they're > > heading in the right direction, it does us early adopters no good to > > struggle through this incompatibility entanglement. Too much of what once > > was shown as "the way", if not the best practice, is no longer even > > supported (e.g., dynamically scoped variables). > > > > My first use of puppet required operation from cached resources onstateless > > Fedora nodes in the event that the network was offline or the "master" > > otherwise unreachable. I could not make the normal client/server approach > > work and thus adopted a rsync + cron + puppet agent apply approachas a work > > around. That to date has still been my best experience with puppet -- it > > just works because it abandons the requirements imposed by their > > client/server approach. > > > > As for what should be done with Fedora and RHEL I cannot say. It seems all > > available options stink. On one hand I'd hate to see F17 change, I'm still > > struggling to adjust my code to be compatible with that. I've had a > > difficult time keeping my puppet resources in shape for each Fedora release > > -- six months goes by all to fast when you have many other responsibilities > > -- puppet was supposed to reduce my workload, right? Right??? If3.0 lands > > in F17, that's going to hurt my plans. At the same time, puppet in F17 "as > > is" is plagued with problems as already mentioned. > > > > Argh! "Hogtied" is a very apt description. > > I'm sorry if your Puppet experience isn't completely awesome. Posting > on the Puppet users list might be more appropriate. Been there, done that since v0.24. If I'd jumped in with 3.0, my opinions might be different. I believe something like puppet is sorely needed and it solves big problems, but it's been a very bumpy ride when what was once "best practice" is now deprecated. > In this case I am looking for packaging options/opinions on Puppet > with regards to Fedora and EPEL. See my next to last paragraph beginning, "As for what should be done with Fedora and RHEL ...". Consider the rest as context. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
Em 17-10-2012 11:44, Matthew Miller escreveu: > With the stipulation that rsyslog would still be available to provide a > traditional syslog-style text logs, what are reasonable hard requirements > for making systemd the main logging system installed by default? (Or, an > alternate softer implementation: rsyslogd would be installed by default but > would not be in 'core'.) Anything that is proposed to replace rsyslogd should be capable of getting logs not only from a local machine, but also from network devices (wifi, cable/xDSL modem, VoIP phone) and from other machines. Until journald can't handle it, I don't think it is ready to be the default logger, as it won't fill even my home network needs. So, the big missing feature seems to be syslog UDP/TCP protocol support. Regards, Mauro -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
On Mon, Oct 22, 2012 at 03:26:45PM -0200, Mauro Carvalho Chehab wrote: > Anything that is proposed to replace rsyslogd should be capable of getting > logs not only from a local machine, but also from network devices > (wifi, cable/xDSL modem, VoIP phone) and from other machines. Until > journald can't handle it, I don't think it is ready to be the default logger, > as it won't fill even my home network needs. I know remote logging is important. But, even if systemd supported it, it wouldn't be _on_ by default, would it? Given that, is installing rsyslogd to support this really a blocker? In enterprise settings, one doesn't want every random machine being a log server -- setting up a specialized machine to do that job is completely normal. That's probably true at your house too. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Fri, Oct 19, 2012 at 5:35 PM, Matthew Miller wrote: > I'm not opposed to putting puppet 3 in, but it'd really be helpful if it > went in as "puppet3" or something, and left the stable version as is, > happily getting security-only updates. My biggest concern is that 2.6 will not get security updates for the lifetime of EPEL 5 and 6. To me it seems better to bite the bullet now, get version 3 into updates-testing, set the karma requirement very high just as the maintainers did for the 0.25 -> 2.6 transition. This is the main problem I see with parallel-installable packages, particularly in EPEL - it seems to give users an assumption that the old packages are fine. - Ken -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps for Fedora Security Lab
Fabian Affolter (f...@fedoraproject.org) said: > The Fedora Security Lab is an official spin since Fedora 13. So far > all packages are handled direct in the kickstart file which is not > very handy if you want to install the packages from a running Fedora > installation. > > I would like to include the Security Lab tools into comps for F19. > This way the FSL can stand shoulder-to-shoulder with the Fedora > Electronic Lab, the Robotics Spin, and others. What are you envisioning? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Mon, Oct 22, 2012 at 12:25:22PM -0600, Ken Dreyer wrote: > > I'm not opposed to putting puppet 3 in, but it'd really be helpful if it > > went in as "puppet3" or something, and left the stable version as is, > > happily getting security-only updates. > My biggest concern is that 2.6 will not get security updates for the > lifetime of EPEL 5 and 6. To me it seems better to bite the bullet As I understand it, Puppet Labs is still providing security updates for the 2.6 series. > This is the main problem I see with parallel-installable packages, > particularly in EPEL - it seems to give users an assumption that the > old packages are fine. We should cross that bridge when the old packages aren't fine anymore. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [pkgdb] GeoIP (un)retirement
On Mon, 22 Oct 2012 12:36:34 -0400 (EDT)
Paul Wouters wrote:
> On Mon, 22 Oct 2012, Paul Howarth wrote:
>
> > On 10/22/2012 10:45 AM, Fedora PackageDB wrote:
> >> Package GeoIP in Fedora 17 has been retired by mfleming
> >>
> >> To make changes to this package see:
> >>https://admin.fedoraproject.org/pkgdb/acls/name/GeoIP
> >
> > What's the story with this? Has something happened upstream?
> >
> > I currently use GeoIP for proftpd's mod_geoip module, which I'll
> > have to discontinue if GeoIP goes away.
>
> Perhaps look at "geome". I'm upstream, so I could add a mode to match
> GeoIP output if that matters to you.
>
> [paul@thinkpad ~]$ geome
> {"city": "Toronto", "street_number": "700", "country": "Canada",
> "region": "Ontario", "long": -79.4031778, "county": "Toronto
> Division", "street": "King St W", "postal_code": "M6J",
> "country_code": "CA", "lat": 43.6440866, "accuracy": 30.0}
It's OK, it turns out that it was retired by mistake during the
orphaning process, which has now been rectified. I've taken ownership
of GeoIP itself but some of mfleming's other packages are still up for
grabs (he's no time to devote to packaging these days and has orphaned
a bunch of stuff).
If anyone is interested in co-maintaining GeoIP, please apply in pkgdb
by the way.
Paul.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Formal request: non-responsive maintainer Gavin Romig-Koch for squeak-vm
On Mon, 22 Oct 2012 12:04:59 -0400 Matthew Miller wrote: > Bug here, with no response: > https://bugzilla.redhat.com/show_bug.cgi?id=861970 > > Gavin isn't responding to bugs or to email. > > Note that also note that Jaroslav Škarvada has an updated package in > testing, has asked to become a co-maintainer, and in fact has been > trying to get a response for almost a year. I checked with Jaroslav > and he's still ready to take over. > > I'm an interested party because I want to package Scratch, and an > updated Squeak VM will significantly simplify that package -- and > make sound work. As a FESCo member I will ack this per the process. I'm going to reassign the squeak-vm package now. In addition, gavin also maintains: collection | package name | description | owner | co-maintainers/cc Fedora|etoys|A media-rich model, game, and simulation construction kit and authoring tool|gavin||dcorking,sdz,tuxbrewr Fedora|fastback|File uploader, configureable file uploader|gavin|| Fedora|report|Incident reporting library|gavin||jmoskovc Fedora|squeak-image|The image files for Squeak|gavin||dcorking,jskarvad,tuxbrewr Fedora|squeak-vm|The Squeak virtual machine|gavin||dcorking,jskarvad,tuxbrewr Fedora EPEL|fastback|File uploader, configureable file uploader|gavin|| Fedora EPEL|report|Incident reporting library|gavin|| If anyone would like to take over any of these packages, please let me know. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg / koji error
On 10/22/2012 12:09 PM, Ralf Corsepius wrote:
>> There is currently no way to "undefine" a macro at the rpm commandline,
>
> rpmbuild --define " %{nil}" ?
Huh, I swear I knew that once. :) Attached is a patch to use the %{nil}
behavior instead of setting the unused dist macro to 0. I smoke tested
and confirmed that the %{rhel} macro is unset on Fedora with this patch
applied.
~tom
==
Fedora Project
diff -up fedpkg-1.10/src/pyrpkg/fedpkg/__init__.py.nil fedpkg-1.10/src/pyrpkg/fedpkg/__init__.py
--- fedpkg-1.10/src/pyrpkg/fedpkg/__init__.py.nil 2012-10-22 13:51:28.706781587 -0400
+++ fedpkg-1.10/src/pyrpkg/fedpkg/__init__.py 2012-10-22 13:54:23.750857940 -0400
@@ -197,7 +197,7 @@ class Commands(pyrpkg.Commands):
"--define '_rpmdir %s'" % self.path,
"--define 'dist .%s'" % self.dist,
"--define '%s %s'" % (self._distvar, self._distval),
-"--define '%s 0'" % self._distunset,
+"--define '%s %%{nil}'" % self._distunset,
"--define '%s 1'" % self.dist]
def load_target(self):
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 868494] perl-File-HomeDir-1.00 is available
https://bugzilla.redhat.com/show_bug.cgi?id=868494 Tom "spot" Callaway changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |RAWHIDE Last Closed||2012-10-22 16:42:18 -- 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 perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
GeoIP license partly changing
As raised in http://bugzilla.redhat.com/840896, I have changed the license of GeoIP slightly. The package was previously listed as LGPLv2+. The package contains two libraries, libGeoIP and libGeoIPUpdate, plus a few binary utility tools. Of these, libGeoIPUpdate contains some GPL code (which upstream does declare in its COPYRIGHT file), so I have changed the license to be "LGPLv2+ and GPLv2+", whereby libGeoIPUpdate and one of the utilities that is linked against it comprise the GPLv2+ part. Everything else remains LGPLv2+. Currently in Fedora there are no packages with dependencies on libGeoIPUpdate; all GeoIP library clients have dependencies on libGeoIP only. Hence I don't believe this change has any impact on existing Fedora packages. Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
On Mon, Oct 22, 2012 at 7:26 PM, Mauro Carvalho Chehab wrote: > Em 17-10-2012 11:44, Matthew Miller escreveu: >> With the stipulation that rsyslog would still be available to provide a >> traditional syslog-style text logs, what are reasonable hard requirements >> for making systemd the main logging system installed by default? (Or, an >> alternate softer implementation: rsyslogd would be installed by default but >> would not be in 'core'.) > > Anything that is proposed to replace rsyslogd should be capable of getting > logs not only from a local machine, but also from network devices > (wifi, cable/xDSL modem, VoIP phone) and from other machines. Until > journald can't handle it, I don't think it is ready to be the default logger, > as it won't fill even my home network needs. > > So, the big missing feature seems to be syslog UDP/TCP protocol support. As mentioned earlier, that's is not a feature of the journal, it does not want to speak syslog as in the protocol, or write plain text files. It is what a syslog daemon is for, and what a syslog daemon already solves properly. There is absolutely no need to go wild here and try taking over what works fine since many years. The same applies to the plain text log files. It's both a solved problem the journal should just leave alone. If people want syslog, they should just run syslog, it all works fine, and is expected to be used that way. The journal is "system logging", but not "syslog" as in the text files, or the network protocol. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Formal request: non-responsive maintainer Gavin Romig-Koch for squeak-vm
> If anyone would like to take over any of these packages, please let > me know. > I will also take squeak-image thanks & regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Formal request: non-responsive maintainer Gavin Romig-Koch for squeak-vm
On Mon, 22 Oct 2012 17:17:53 -0400 (EDT) Jaroslav Skarvada wrote: > > If anyone would like to take over any of these packages, please let > > me know. > > > I will also take squeak-image Done. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: R
On Mon, Oct 22, 2012 at 8:44 AM, Tom Callaway wrote: > On 10/21/2012 11:24 PM, Richard Vickery wrote: > > Hi Gang, > > > > For some strange reason, something has gone wrong with R, the statistics > > program. R doesn't know where to find rJava and perhaps the other > > programs to run JGR. so I thought I might try uninstalling - and > > re-installing - it, but yum won't / can't remove the non-X part. Has > > anyone experienced this before? > > Can you post specific logs? You need to have R-java installed, so please > confirm that you do as well. > > ~tom > > == > Fedora Project > > library(JGR) Loading required package: rJava Error : .onLoad failed in loadNamespace() for 'rJava', details: call: dyn.load(file, DLLpath = DLLpath, ...) error: unable to load shared object '/home/richard/R/i686-redhat-linux-gnu-library/2.15/rJava/libs/rJava.so': libjvm.so: cannot open shared object file: No such file or directory Error: package ‘rJava’ could not be loaded $ locate libjvm.so /usr/lib/gcj-4.7.2/libjvm.so /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9/jre/lib/i386/client/libjvm.so /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9/jre/lib/i386/server/libjvm.so ]$ locate rJava.so /home/richard/R/i686-redhat-linux-gnu-library/2.15/rJava/libs/rJava.so /usr/lib/R/library/rJava/libs/rJava.so Do you need anything else, Tom? Thanks for the help, -Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: R
Did you try re-installing rJava within R (i.e.
install.packages("rJava")) ?? I wasnt aware these contrib packages
were available through yum
Regards
Michael Weiner
--
On Mon, Oct 22, 2012 at 7:48 PM, Richard Vickery
wrote:
> On Mon, Oct 22, 2012 at 8:44 AM, Tom Callaway wrote:
>>
>> On 10/21/2012 11:24 PM, Richard Vickery wrote:
>> > Hi Gang,
>> >
>> > For some strange reason, something has gone wrong with R, the statistics
>> > program. R doesn't know where to find rJava and perhaps the other
>> > programs to run JGR. so I thought I might try uninstalling - and
>> > re-installing - it, but yum won't / can't remove the non-X part. Has
>> > anyone experienced this before?
>>
>> Can you post specific logs? You need to have R-java installed, so please
>> confirm that you do as well.
>>
>> ~tom
>>
>> ==
>> Fedora Project
>
>
>> library(JGR)
> Loading required package: rJava
> Error : .onLoad failed in loadNamespace() for 'rJava', details:
> call: dyn.load(file, DLLpath = DLLpath, ...)
> error: unable to load shared object
> '/home/richard/R/i686-redhat-linux-gnu-library/2.15/rJava/libs/rJava.so':
> libjvm.so: cannot open shared object file: No such file or directory
> Error: package ‘rJava’ could not be loaded
>
> $ locate libjvm.so
> /usr/lib/gcj-4.7.2/libjvm.so
> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9/jre/lib/i386/client/libjvm.so
> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9/jre/lib/i386/server/libjvm.so
>
> ]$ locate rJava.so
> /home/richard/R/i686-redhat-linux-gnu-library/2.15/rJava/libs/rJava.so
> /usr/lib/R/library/rJava/libs/rJava.so
>
>
> Do you need anything else, Tom?
>
> Thanks for the help,
> -Richard
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
--
"A patriot must always be ready to defend his country against his
government." E. Abbey
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: R
another attempt
> > install.packages("rJava")
Error: unexpected '>' in ">"
> Installing package(s) into
‘/home/richard/R/i686-redhat-linux-gnu-library/2.15’
Error: unexpected symbol in "Installing package"
> (as ‘lib’ is unspecified)
Error: unexpected input in "(as �"
> trying URL 'http://cran.stat.sfu.ca/src/contrib/rJava_0.9-3.tar.gz'
Error: unexpected symbol in "trying URL"
> Content type 'application/x-gzip' length 537153 bytes (524 Kb)
Error: unexpected symbol in "Content type"
> opened URL
Error: unexpected symbol in "opened URL"
> ==
Error: unexpected '==' in "=="
> downloaded 524 Kb
Error: unexpected numeric constant in "downloaded 524"
>
> * installing *source* package ‘rJava’ ...
Error: unexpected '*' in "*"
> ** package ‘rJava’ successfully unpacked and MD5 sums checked
Error: unexpected '^' in "**"
> checking for gcc... gcc -m32 -std=gnu99
Error: unexpected 'for' in "checking for"
> checking for C compiler default output file name... a.out
Error: unexpected 'for' in "checking for"
> checking whether the C compiler works... yes
Error: unexpected symbol in "checking whether"
> checking whether we are cross compiling... no
Error: unexpected symbol in "checking whether"
> checking for suffix of executables...
Error: unexpected 'for' in "checking for"
> checking for suffix of object files... o
Error: unexpected 'for' in "checking for"
> checking whether we are using the GNU C compiler... yes
Error: unexpected symbol in "checking whether"
> checking whether gcc -m32 -std=gnu99 accepts -g... yes
Error: unexpected symbol in "checking whether"
> checking for gcc -m32 -std=gnu99 option to accept ISO C89... none needed
Error: unexpected 'for' in "checking for"
> checking how to run the C preprocessor... gcc -m32 -std=gnu99 -E
Error: unexpected symbol in "checking how"
> checking for grep that handles long lines and -e... /usr/bin/grep
Error: unexpected 'for' in "checking for"
> checking for egrep... /usr/bin/grep -E
Error: unexpected 'for' in "checking for"
> checking for ANSI C header files... yes
Error: unexpected 'for' in "checking for"
> checking for sys/wait.h that is POSIX.1 compatible... yes
Error: unexpected 'for' in "checking for"
> checking for sys/types.h... yes
Error: unexpected 'for' in "checking for"
> checking for sys/stat.h... yes
Error: unexpected 'for' in "checking for"
> checking for stdlib.h... yes
Error: unexpected 'for' in "checking for"
> checking for string.h... yes
Error: unexpected 'for' in "checking for"
> checking for memory.h... yes
Error: unexpected 'for' in "checking for"
> checking for strings.h... yes
Error: unexpected 'for' in "checking for"
> checking for inttypes.h... yes
Error: unexpected 'for' in "checking for"
> checking for stdint.h... yes
Error: unexpected 'for' in "checking for"
> checking for unistd.h... yes
Error: unexpected 'for' in "checking for"
> checking for string.h... (cached) yes
Error: unexpected 'for' in "checking for"
> checking sys/time.h usability... yes
Error: unexpected symbol in "checking sys"
> checking sys/time.h presence... yes
Error: unexpected symbol in "checking sys"
> checking for sys/time.h... yes
Error: unexpected 'for' in "checking for"
> checking for unistd.h... (cached) yes
Error: unexpected 'for' in "checking for"
> checking for an ANSI C-conforming const... yes
Error: unexpected 'for' in "checking for"
> checking whether time.h and sys/time.h may both be included... yes
Error: unexpected symbol in "checking whether"
> configure: checking whether gcc -m32 -std=gnu99 supports static inline...
Error: unexpected symbol in "configure: checking whether"
> yes
Error: object 'yes' not found
> checking whether setjmp.h is POSIX.1 compatible... yes
Error: unexpected symbol in "checking whether"
> checking whether sigsetjmp is declared... yes
Error: unexpected symbol in "checking whether"
> checking whether siglongjmp is declared... yes
Error: unexpected symbol in "checking whether"
> checking Java support in R... present:
Error: unexpected symbol in "checking Java"
> interpreter : '/bin/java'
Error: object 'interpreter' not found
> archiver: '/bin/jar'
Error: object 'archiver' not found
> compiler: '/bin/javac'
Error: object 'compiler' not found
> header prep.: '/bin/javah'
Error: unexpected symbol in "header prep."
> cpp flags : '-I/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.6/jre/../include
-I/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.6/jre/../include/linux'
Error: unexpected symbol in "cpp flags"
> java libs : '-L/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.6/jre/lib/i386
-L/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.6/jre/lib/i386/client -ljvm'
Error: unexpected symbol in "java libs"
> checking whether JNI programs can be compiled...
Error: unexpected symbol in "checking whether"
> configure: error: Cannot compile a simple JNI program. See config.log for
details.
Error: unexpected symbol in "configure: error: Cannot compile"
>
> Make sure you have Java Development Kit installed and correctly
registered
Re: R
On 10/22/2012 09:39 PM, Richard Vickery wrote: > checking Java support in R... present: > interpreter : '/bin/java' > archiver: '/bin/jar' > compiler: '/bin/javac' > header prep.: '/bin/javah' > cpp flags : '-I/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.6/jre/../include > -I/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.6/jre/../include/linux' > java libs : '-L/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.6/jre/lib/i386 > -L/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.6/jre/lib/i386/client -ljvm' > checking whether JNI programs can be compiled... > configure: error: Cannot compile a simple JNI program. See config.log for > details. > > Make sure you have Java Development Kit installed and correctly registered in > R. > If in doubt, re-run "R CMD javareconf" as root. Have you installed java-1.7.0-openjdk-devel? Could you share the java/jni program that it's attempting to compile and the command it uses for compilation, please? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg / koji error
On 10/22/2012 10:43 PM, Tom Callaway wrote:
On 10/22/2012 12:09 PM, Ralf Corsepius wrote:
There is currently no way to "undefine" a macro at the rpm commandline,
rpmbuild --define " %{nil}" ?
Huh, I swear I knew that once. :) Attached is a patch to use the %{nil}
behavior instead of setting the unused dist macro to 0. I smoke tested
and confirmed that the %{rhel} macro is unset on Fedora with this patch
applied.
I haven't tried your patch, but don't you have to unset/define %{nil}
all build-host related rpm macros from /etc/rpm/macros.dist?
It's at least what I can not avoid doing in my before-mentioned
build-scripts.
I.e. when running my script on Fedora 17, I invoke rpmbuild this way:
rpmbuild ... \
--define "fedora %{nil}" --define "fc17 %{nil}"
--define "dist .el6" --define "rhel 6" --define "el6 1"
...
Otherwise constructs such as
%{?fc17:}
%{?el6:}
also won't work correctly in rpm.specs.
IIUC, fedpkg with your patch sets %dist and unsets %fedora, but it
doesn't seem to catch "fc17".
Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
Ken Dreyer wrote: On Fri, Oct 19, 2012 at 5:35 PM, Matthew Miller wrote: I'm not opposed to putting puppet 3 in, but it'd really be helpful if it went in as "puppet3" or something, and left the stable version as is, happily getting security-only updates. My biggest concern is that 2.6 will not get security updates for the lifetime of EPEL 5 and 6. To me it seems better to bite the bullet now, get version 3 into updates-testing, set the karma requirement very high just as the maintainers did for the 0.25 -> 2.6 transition. I'm sure that 2.6 won't last for the life of EL5, let alone EL6. At the same time, I didn't push to get 2.7 in EPEL because it isn't a completely compatible update. And 3.0 was coming so I figured we could wait to see what things looked like when it did. The alternative would have been more updates and more potential to break things and annoy the users who were perfectly happy with how 2.6 was working. (Those that needed the newest shiny or were supporting Fedora 17 could get newer bits from yum.puppetlabs.com.) This is the main problem I see with parallel-installable packages, particularly in EPEL - it seems to give users an assumption that the old packages are fine. Yeah, that's always bugged me too. If you're not paying close attention, you can easily assume that since yum update returns nothing that you are good to go. In that case, I'd much prefer that an update comes along and gets your attention, even if it breaks things. Obviously, neither option is all that great. As a user, I think compatibility is the biggest downside to puppet at this point. I love the tool, but having to always run the master on the latest version bugs me. At the least, I think a version N client should work fine with an N-1 master. Back in the pre-1.0 days it was acceptable to not have this, but as the versions have been increased to show product maturity, I think it's hard to justify not maintaining more compatibility. I'm happy to see options here and get a feel for what the least painful way forward is for everyone. I'm not terribly fond of a puppet3 package myself. It would be confusing to have it parallel installable and use different paths than the upstream defaults, as documenation would either be wrong or require a lot of conditional statements regarding where and how you installed puppet. That and it's more work to maintain, regardless of who's maintaining it. Thanks to Michael for bringing this topic up for discussion (and for being an all around good guy as well). -- ToddOpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ Abandon the search for Truth; settle for a good fantasy. pgpTTcYp3nbsP.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Mon, Oct 22, 2012 at 7:51 PM, Todd Zullinger wrote: > Ken Dreyer wrote: >> >> On Fri, Oct 19, 2012 at 5:35 PM, Matthew Miller >> wrote: >>> >>> I'm not opposed to putting puppet 3 in, but it'd really be helpful if it >>> went in as "puppet3" or something, and left the stable version as is, >>> happily getting security-only updates. >> >> >> My biggest concern is that 2.6 will not get security updates for the >> lifetime of EPEL 5 and 6. To me it seems better to bite the bullet now, get >> version 3 into updates-testing, set the karma requirement very high just as >> the maintainers did for the 0.25 -> 2.6 transition. > > > I'm sure that 2.6 won't last for the life of EL5, let alone EL6. At the > same time, I didn't push to get 2.7 in EPEL because it isn't a completely > compatible update. And 3.0 was coming so I figured we could wait to see > what things looked like when it did. The alternative would have been more > updates and more potential to break things and annoy the users who were > perfectly happy with how 2.6 was working. (Those that needed the newest > shiny or were supporting Fedora 17 could get newer bits from > yum.puppetlabs.com.) 2.6.x will be maintained (security) roughly until end of Q1 next year. That's the only real commitment we can make. It's not that we'd completely leave everybody in the dark after that, but some fixes/issues just don't port well to older versions. So this is well short of EPEL5/6 lifetimes. > > >> This is the main problem I see with parallel-installable packages, >> particularly in EPEL - it seems to give users an assumption that the old >> packages are fine. I too have always thought this. > > > Yeah, that's always bugged me too. If you're not paying close attention, > you can easily assume that since yum update returns nothing that you are > good to go. In that case, I'd much prefer that an update comes along and > gets your attention, even if it breaks things. Obviously, neither option is > all that great. > > As a user, I think compatibility is the biggest downside to puppet at this > point. I love the tool, but having to always run the master on the latest > version bugs me. At the least, I think a version N client should work fine > with an N-1 master. Back in the pre-1.0 days it was acceptable to not have > this, but as the versions have been increased to show product maturity, I > think it's hard to justify not maintaining more compatibility. This is an ongoing discussion internally on compatibility. Thoughts and opinions and real-world use cases from system admins are MORE than welcome about this topic on our puppet-users list. > > I'm happy to see options here and get a feel for what the least painful way > forward is for everyone. > > I'm not terribly fond of a puppet3 package myself. It would be confusing to > have it parallel installable and use different paths than the upstream > defaults, as documenation would either be wrong or require a lot of > conditional statements regarding where and how you installed puppet. That > and it's more work to maintain, regardless of who's maintaining it. > > Thanks to Michael for bringing this topic up for discussion (and for being > an all around good guy as well). cheers. > > -- > ToddOpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp > ~~ > Abandon the search for Truth; settle for a good fantasy. > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
HEADS-UP: Transition to guile-2.0.x and a new compat-guile1.8 package
Hello all, I've created a review request for compat-guile1.8: https://bugzilla.redhat.com/show_bug.cgi?id=868263 Once the compat package lands in rawhide, I will leave some time for the transition (I may work on the required patches if time allows me). After that, guile (now version 1.8) will become 2.0.x. I've already tried patching a few packages and there seem to be no real problems, unlike patching the old apps for the new guile. Affected packages: aisleriot autogen coot denemo drgeo freehoo freetalk geda gnubik gnucash gnurobots gnutls graphviz libctl libgeda lilypond mdk rumor TeXmacs trackballs xbindkeys Cheers, -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
