Re: Does abrt work?
Hi Neal, this happens because retrace server uses yum and yum is not able to fully resolve dependencies in some specific situations. In that case there is no reason to continue because the resulting backtrace would be unusable. What package are you trying to retrace? AFAIK there seems to be a problem with gnome-related packages. Thanks a lot. Michal On 09.08.2011 19:40, Neal Becker wrote: > Here's what I got trying to use retrace server for crash of inkscape: > > Retrace job failed > Analyzing crash data OK > Initializing virtual root OK > Generating backtrace Error > Unable to chmod the executable > > (exited with 1) > > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Autodetecting insufficiently hardened builds (was: New hardened build support (coming) in F16)
> Matthew Garrett wrote: > > Unless the checking is part of autoqa this simply isn't > > sufficient. There's a huge benefit to implementing it in the way > > that's > > easiest for maintainers. > > The earlier a problem is detected, the cheaper it is to fix. If I have > understood AutoQA right, it gets involved only after I submit a > package to > updates-testing. Currently we (the AutoQA) are able to run the test either after you submit it to Bodhi, or even right after the build is finished in Koji (which is probably better for your use case). Feel free to discuss details with us in autoqa-devel [1]. [1] https://fedorahosted.org/mailman/listinfo/autoqa-devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: advice on libjpeg
Hello Ankur, our current libjpeg-turbo build in Fedora is 100% API/ABI compatible with former ijg libjpeg 6b. I would recommend to simply package the application and try to build it against libjpeg-turbo. If something fails, feel free to send me a mail with details and I will try to help you. Regards, Adam On 08/09/2011 04:28 PM, Ankur Sinha wrote: > Hello, > > One of the packages[2] I am trying to package requires libjpeg from the > ijg[1]. Since fedora is using libjpeg-turbo, I wanted to know if libjpeg > and libjpeg are installable in parallel? Should I package libjpeg as a > build dep, or should I be trying to patch the source to use > libjpeg-turbo? > > [1] http://libjpeg.sourceforge.net/ > [2] http://ingenium.home.xs4all.nl/dicom.html > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
Hi Jan, On Tue, Aug 9, 2011 at 12:56 PM, Jan Kratochvil wrote: > On Tue, 09 Aug 2011 16:44:31 +0200, Colin Walters wrote: >> the goal being that they see warnings more easily. > > You should make -Werror default instead, by compiling packages without -Werror > various bugs creep in which would be much easier fixed before the compilation. I've gone back and forth on this over the years - what I ultimately concluded is that what one really wants in general is a system for tracking warning *regressions*. That's obviously harder, but I've been thinking about how to do it in our GNOME builds. Anyways - seems like there was rough consensus for the original patch so I've committed it, pushed and started a build for rawhide. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Does abrt work?
This was inkscape. Michal Toman wrote: > Hi Neal, > > this happens because retrace server uses yum and yum is not able to > fully resolve dependencies in some specific situations. In that case > there is no reason to continue because the resulting backtrace would be > unusable. > What package are you trying to retrace? AFAIK there seems to be a > problem with gnome-related packages. > > Thanks a lot. > > Michal > > On 09.08.2011 19:40, Neal Becker wrote: >> Here's what I got trying to use retrace server for crash of inkscape: >> >> Retrace job failed >> Analyzing crash data OK >> Initializing virtual root OK >> Generating backtrace Error >> Unable to chmod the executable >> >> (exited with 1) >> >> -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Grubby and Xen (patch to apply) - needed for F16
On Sun, Aug 07, 2011 at 09:41:17PM +0300, Pasi Kärkkäinen wrote: > On Mon, Jul 25, 2011 at 08:36:00AM -0400, Adam Jackson wrote: > > On 7/25/11 8:31 AM, Roman Rakus wrote: > > > On 07/25/2011 04:38 AM, W. Michael Petullo wrote: > > >> Is anyone who is a grubby contributor interested in adding these features > > >> to grubby to support the XenPvopsDom0 feature? I've provided a patch in > > >> bug #658387. > > >> > > > Is it possible to use augeas [1]? There is currently lens for grub.conf > > > > > > [1] http://augeas.net/ > > > > It may certainly be possible - and perhaps even desirable - to replace > > grubby with augeas, but that's not really what he asked. > > > > Yep. Anyone willing to apply the patch from #658387 ? > Ping? -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: advice on libjpeg
On Wed, 2011-08-10 at 11:04 +0200, Adam Tkac wrote: > Hello Ankur, > > our current libjpeg-turbo build in Fedora is 100% API/ABI compatible > with former ijg libjpeg 6b. I would recommend to simply package the > application and try to build it against libjpeg-turbo. If something > fails, feel free to send me a mail with details and I will try to help you. > > Regards, Adam > Hi Adam, Thank you for clarifying this. I'll go try building my package :) -- Thanks, Regards, Ankur: "FranciscoD" http://fedoraproject.org/wiki/User:Ankursinha http://dodoincfedora.wordpress.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 729504] perl-Dancer: please update to version 1.3071
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=729504 --- Comment #4 from Jose Pedro Oliveira 2011-08-10 08:42:31 EDT --- (In reply to comment #3) > Is perl-Devel-StackTrace not in the RHEL-6 optional channel? It was there in > the 6.0 beta (perl-Devel-StackTrace-1.22-4.el6.src.rpm) and a package with > that > NEVR is in CentOS 6.0. Paul, I forgot to mention that perl-Plack-0.9980 (using the F15 SRPM) wants Devel::StackTrace 1.23 and only version 1.22 is available in the main repositories (Argh! Major problem...). Some of the perl-Plack 0.9980 missing requirements in EPEL-6: perl(Devel::StackTrace) >= 1.23 perl(Devel::StackTrace::AsHTML) >= 0.11 perl(Filesys::Notify::Simple) perl(Test::SharedFork) perl(Hash::MultiValue) >= 0.05 perl(Test::TCP) >= 0.11 perl(Authen::Simple::Adapter) /jpo -- 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 perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the rawhide tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) 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
Broken dependencies: perl-NOCpulse-Gritch
perl-NOCpulse-Gritch has broken dependencies in the rawhide tree: On x86_64: perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) 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
rawhide report: 20110810 changes
Compose started at Wed Aug 10 08:15:16 UTC 2011 Broken deps for x86_64 -- acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) almanah-0.7.3-12.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libcryptui.so.0()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit) awstats-7.0-3.fc16.noarch requires perl(Switch) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) bluetile-0.5.3-11.fc16.x86_64 requires ghc(xmonad-contrib-0.9.2) = 0:d669bbdb9b9f7adb145fcb61825dec73 claws-mail-plugins-geolocation-3.7.9-7.fc16.x86_64 requires libcogl.so.1()(64bit) cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet dh-make-0.55-3.fc15.noarch requires debhelper emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave evolution-mapi-3.1.3-1.fc16.i686 requires libcamel-provider-1.2.so.27 evolution-mapi-3.1.3-1.fc16.i686 requires libcamel-1.2.so.27 evolution-mapi-3.1.3-1.fc16.x86_64 requires libcamel-provider-1.2.so.27()(64bit) evolution-mapi-3.1.3-1.fc16.x86_64 requires libcamel-1.2.so.27()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5 fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4 fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libgeos-3.2.1.so()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libboost_thread-mt.so.1.46.1()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libboost_signals-mt.so.1.46.1()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) flaw-1.2.4-2.fc15.x86_64 requires libSDL_gfx.so.0()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk_images.so.1.1()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk.so.1.1()(64bit) flush-0.9.10-3.fc16.x86_64 requires libboost_thread-mt.so.1.46.1()(64bit) flush-0.9.10-3.fc16.x86_64 requires libboost_system-mt.so.1.46.1()(64bit) flush-0.9.10-3.fc16.x86_64 requires libboost_signals-mt.so.1.46.1()(64bit) flush-0.9.10-3.fc16.x86_64 requires libboost_filesystem-mt.so.1.46.1()(64bit) fuse-encfs-1.7.4-1.fc16.i686 requires libboost_system-mt.so.1.46.1 fuse-encfs-1.7.4-1.fc16.i686 requires libboost_serialization-mt.so.1.46.1 fuse-encfs-1.7.4-1.fc16.i686 requires libboost_filesystem-mt.so.1.46.1 fuse-encfs-1.7.4-1.fc16.x86_64 requires libboost_system-mt.so.1.46.1()(64bit) fuse-encfs-1.7.4-1.fc16.x86_64 requires libboost_serialization-mt.so.1.46.1()(64bit) fuse-encfs-1.7.4-1.fc16.x86_64 requires libboost_filesystem-mt.so.1.46.1()(64bit) garden-1.0.8-3.fc15.x86_64 requires liballeg.so.4.2()(64bit) gcstar-1.6.2-1.fc17.noarch requires perl(Switch) glom-1.18.3-1.fc16.x86_64 req
Fwd: [Fedora Update] [CRITPATH] [old_testing_critpath] mdadm-3.1.3-0.git20100804.3.fc14
Can we please either disable these nag messages or give developers the ability to push a package regardless of testing when it reaches nag age? Original Message Subject: [Fedora Update] [CRITPATH] [old_testing_critpath] mdadm-3.1.3-0.git20100804.3.fc14 Date: Wed, 10 Aug 2011 00:00:17 + From: upda...@fedoraproject.org To: dledf...@redhat.com The critical path update for mdadm-3.1.3-0.git20100804.3.fc14 has been in 'testing' status for over 2 weeks, and has yet to be approved. mdadm-3.1.3-0.git20100804.3.fc14 Update ID: FEDORA-2011-9424 Release: Fedora 14 Status: testing Type: bugfix Karma: 1 Bugs: 653207 - mdadm[862]: segfault at 0 ip 7fc6adff8314 sp : 7fff7016fb90 error 4 in : libc-2.12.90.so[7fc6adf91000+199000] Notes: This is a minor update to resolve mdmon segfaulting when called to : see if it should takeover any arrays on the system and : version 0.90 arrays are active. Submitter: dledford Submitted: 2011-07-15 00:15:35 Comments: bodhi - 2011-07-15 00:15:50 (karma 0) This update has been submitted for testing by dledford. This critical path update has not yet been approved for pushing to the stable repository. It must first reach a karma of 2, consisting of 1 positive karma from proventesters, along with 1 additional karma from the community. bodhi - 2011-07-16 07:36:06 (karma 0) This update has been pushed to testing boblfoot (proventesters) - 2011-07-28 07:30:00 (karma 0) no raid thedonvaughn (proventesters) - 2011-08-01 20:47:38 (karma 1) no regression here. mdmad still works https://admin.fedoraproject.org/updates/mdadm-3.1.3-0.git20100804.3.fc14 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide
On 08/09/2011 06:45 PM, Eric Sandeen wrote: >> I've made the first WIP release of e2fsprogs 1.42. The primary purpose >> is for people to test the 64-bit functionality and be confident that we >> didn't introduce any 32-bit regressions. > So in theory you can at least mfks & mount a 16T fs and beyond, if you'd > like to test that. Isn't this just a snapshot? In that case, the package should follow the standard naming guidelines https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 729644] New: RFE: request that DateTime-Format-ISO8601 be added to EPEL.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: RFE: request that DateTime-Format-ISO8601 be added to EPEL. https://bugzilla.redhat.com/show_bug.cgi?id=729644 Summary: RFE: request that DateTime-Format-ISO8601 be added to EPEL. Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: unspecified Priority: unspecified Component: perl-DateTime-Format-ISO8601 AssignedTo: cw...@alumni.drew.edu ReportedBy: steve.tray...@cern.ch QAContact: extras...@fedoraproject.org CC: cw...@alumni.drew.edu, fedora-perl-devel-l...@redhat.com Classification: Fedora Story Points: --- Type: --- Hi Chris, I was hoping you might consider adding perl-DateTime-Fromat-ISO8601 to EPEL branches. I just verified that the current devel package builds unmodified in mock for EPEL 5 and 6. (EPEL4 fails for lack of perl(DateTime::Format::Builder) >= 0.77 but I an not bothered about EPEL4 anyway.) Previously you have been happy for me to take the EPEL branches which I am happy to do again for this package. Let me know. In fact I want to add DateTime::Format::XSD to fedora and epel, I'll submit that now anyway for review. Many Thanks. Steve. -- 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 perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: rawhide report: 20110810 changes
On 08/10/2011 06:47 AM, Rawhide Report wrote: > Compose started at Wed Aug 10 08:15:16 UTC 2011 > > Broken deps for x86_64 > -- > > New package: c3p0-0.9.2-0.5.pre1.fc15 > > > Updated Packages: > Perhaps this could be split into two report - broken deps and updated packages? Personally, I would find it easier to track changes that way. -- 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On Tue, Aug 09, 2011 at 02:20:53PM +0100, Matthew Garrett wrote: > You can't bring a policy to FESCO, fail to turn up to any of the > meetings and then be surprised if the enacted proposal doesn't perfectly > match yours. The ticket was flagged "meeting" up until the point where > it was closed which means it's under active consideration, and the > meeting summaries posted to fedora-devel contained the various proposals > and action items that we worked through. Give Steve a break here. This is hardly the first time that things have been discussed at FESCO without even a courtesy email being sent to the people involved. In fact, back in 2008 I kicked up enough of a fuss about this that it's now a policy for Feature owners to be sent email about all meetings where their features are discussed: http://fedoraproject.org/wiki/Extras/SteeringComittee/Meeting-20081112 This clearly needs to be extended to changes in policy. Flagging a ticket as "meeting" is an obscure bit of wonkishness. A courtesy email should be sent before the meeting instead. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Autodetecting insufficiently hardened builds
> > The earlier a problem is detected, the cheaper it is to fix. If I have > > understood AutoQA right, it gets involved only after I submit a > > package to > > updates-testing. Kamil Paral wrote: > Currently we (the AutoQA) are able to run the test either after you submit > it to Bodhi, or even right after the build is finished in Koji (which is > probably better for your use case). Thanks for the correction. Yes that's better, but better still is to also run the test from RPMbuild on my local workstation, for example when I do "fedpkg local" or "fedpkg mockbuild". Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On Wed, Aug 10, 2011 at 02:46:17PM +0100, Richard W.M. Jones wrote: > This clearly needs to be extended to changes in policy. Flagging a > ticket as "meeting" is an obscure bit of wonkishness. A courtesy > email should be sent before the meeting instead. It's helpful to mail feature owners directly because the trac ticket will typically be in the name of the feature wrangler rather than the feature owner. https://fedorahosted.org/fesco/ticket/563 shows active discussion of the fact that we've been talking about this, links to the draft policy documents and makes it clear that this is being discussed in fesco meetings, and Steve's Cc:ed on all of that. It's been on the posted agendas for months. Yet the last time he was in #fedora-meeting appears to have been in February. That's not an impressive amount of involvement in the Fedora process. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Which db should I build this package against?
Hello, I'm working on packaging conquest[1] for fedora which can be built against dbase,mysql, postgresql *and* mysql. Which one should I build it against? Should I build it against all of them and make different subpackages?? I've uploaded the build scripts here if someone wants a peek http://ankursinha.fedorapeople.org/conquest/ [1] http://ingenium.home.xs4all.nl/dicom.html -- Thanks, Regards, Ankur: "FranciscoD" http://fedoraproject.org/wiki/User:Ankursinha http://dodoincfedora.wordpress.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Which db should I build this package against?
Hello Ankur! Try to build against both. You can take a look at the Zabbix package for inspiration, for instance. Volker Am Mittwoch, 10. August 2011, 16:02:05 schrieb Ankur Sinha: > Hello, > > I'm working on packaging conquest[1] for fedora which can be built > against dbase,mysql, postgresql *and* mysql. Which one should I build it > against? Should I build it against all of them and make different > subpackages?? > > I've uploaded the build scripts here if someone wants a peek > > http://ankursinha.fedorapeople.org/conquest/ > > [1] http://ingenium.home.xs4all.nl/dicom.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Which db should I build this package against?
On Wed, 2011-08-10 at 16:08 +0200, Volker Fröhlich wrote: > Hello Ankur! > > Try to build against both. You can take a look at the Zabbix package for > inspiration, for instance. > > Volker Hi Volker, I'll go try that. I noticed I had mentioned mysql twice. I meant dbase, postgresql, mysql and sqlite. > > Am Mittwoch, 10. August 2011, 16:02:05 schrieb Ankur Sinha: > > Hello, > > > > I'm working on packaging conquest[1] for fedora which can be built > > against dbase,mysql, postgresql *and* mysql. Which one should I build it > > against? Should I build it against all of them and make different > > subpackages?? > > > > I've uploaded the build scripts here if someone wants a peek > > > > http://ankursinha.fedorapeople.org/conquest/ > > > > [1] http://ingenium.home.xs4all.nl/dicom.html > -- Thanks, Regards, Ankur: "FranciscoD" http://fedoraproject.org/wiki/User:Ankursinha http://dodoincfedora.wordpress.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Which db should I build this package against?
On Wed, Aug 10, 2011 at 9:10 AM, Ankur Sinha wrote: > On Wed, 2011-08-10 at 16:08 +0200, Volker Fröhlich wrote: >> Hello Ankur! >> >> Try to build against both. You can take a look at the Zabbix package for >> inspiration, for instance. >> >> Volker > > Hi Volker, > > I'll go try that. > > I noticed I had mentioned mysql twice. I meant dbase, postgresql, mysql > and sqlite. If the sub-packages work, great. If not I would consider the target audience. Is it expected that they have a mysql or other database server available? If not, sqlite might be the best option. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Which db should I build this package against?
No idea about dbase, but you should support Sqlite, PostgreSQL and MySQL if it makes sense. If the developers said, foo doesn't work well with Sqlite, you should probably not build though. Volker Am Mittwoch, 10. August 2011, 16:10:54 schrieb Ankur Sinha: > On Wed, 2011-08-10 at 16:08 +0200, Volker Fröhlich wrote: > > Hello Ankur! > > > > Try to build against both. You can take a look at the Zabbix package for > > inspiration, for instance. > > > > Volker > > Hi Volker, > > I'll go try that. > > I noticed I had mentioned mysql twice. I meant dbase, postgresql, mysql > and sqlite. > > > Am Mittwoch, 10. August 2011, 16:02:05 schrieb Ankur Sinha: > > > Hello, > > > > > > I'm working on packaging conquest[1] for fedora which can be built > > > against dbase,mysql, postgresql *and* mysql. Which one should I build > > > it against? Should I build it against all of them and make different > > > subpackages?? > > > > > > I've uploaded the build scripts here if someone wants a peek > > > > > > http://ankursinha.fedorapeople.org/conquest/ > > > > > > [1] http://ingenium.home.xs4all.nl/dicom.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Dancer-1.3071.tar.gz uploaded to lookaside cache by mmaslano
A file has been added to the lookaside cache for perl-Dancer: 9fbe54f6d43c95c7d4aea4f765075bdb Dancer-1.3071.tar.gz -- 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: Which db should I build this package against?
On 08/10/2011 07:32 PM, Ankur Sinha wrote: > Hello, > > I'm working on packaging conquest[1] for fedora which can be built > against dbase,mysql, postgresql *and* mysql. Which one should I build it > against? Should I build it against all of them and make different > subpackages?? Did you talk to upstream and figure out if all these options are equally well supported? That would determine if you want to build sub packages for all or not Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Which db should I build this package against?
> On 08/10/2011 07:32 PM, Ankur Sinha wrote: >> Hello, >> >> I'm working on packaging conquest[1] for fedora which can be built >> against dbase,mysql, postgresql *and* mysql. Which one should I build it >> against? Should I build it against all of them and make different >> subpackages?? > > Did you talk to upstream and figure out if all these options are equally > well supported? That would determine if you want to build sub packages > for all or not > > Rahul > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > See also bacula. It rebuilds 3 times for sqlite, mysql and postgresql support. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive maintainer: cvsgraph
On Wed, 10 Aug 2011 01:19:43 + (UTC) Bojan Smojver wrote: > Kevin Fenzi scrye.com> writes: > > > Done. > > Still having no luck submitting this as an update via bodhi. I get: > > bojan does not have commit access to cvsgraph > > Anyone knows what else is required for a package to be submitted as > an update? It seems that commit access on the branch is not > sufficient. You may need commit on devel/master as well? If you apply I can get you approved. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Which db should I build this package against?
>>> I'm working on packaging conquest[1] for fedora which can be built >>> against dbase,mysql, postgresql *and* mysql. Which one should I build it >>> against? Should I build it against all of them and make different >>> subpackages?? >> Did you talk to upstream and figure out if all these options are equally >> well supported? That would determine if you want to build sub packages >> for all or not > See also bacula. It rebuilds 3 times for sqlite, mysql and postgresql > support. Perhaps upstream could deliver N shared libraries, then at run time use dlopen() to load the one which corresponds to the database package that is being used. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages in F-16 (final warning)
On Mon, Aug 08, 2011 at 10:18:48PM +0200, Chitlesh GOORAH wrote: > Hello there, > > It seems that guile-gnome-platform should be unblocked as well. > > > > > Hello there, > > > > I wish to take ownership of gnusim8085 and gwave. > > Can you please grant me the "Take Ownership" for the respective devel > > branch ? > > Hey Chitlesh, These have already been retired. According to the policy that FESCo updated just prior to their approving the retiring of these packages, once retired, packages need a re-review in order to be brought back into Fedora. http://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Deprecated_Package -Toshio pgp3mP6TM6b9j.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
boot.fedoraproject.org (bfo)
Hello, A bit of (hopefully) constructive feedback. It might help with testing and adoption of fedora if the rcs and alpha releases are made available in the bfo setup. Actually within the "experimental" folder there is only a tc1 of f15 currently. Potential ideas for bfo: * keep the "experimental" option more up to date in the future. * while simple to install make the lkrn available in a ready to use rpm Last time i tried an install via bfo it didnt really select mirrors close to me. (i think for the install it didnt use a mirrorlist but instead a hardcoded repo by default) Is this still the case? kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide
On 08/10/2011 07:59 AM, Rahul Sundaram wrote: > On 08/09/2011 06:45 PM, Eric Sandeen wrote: >>> I've made the first WIP release of e2fsprogs 1.42. The primary purpose >>> is for people to test the 64-bit functionality and be confident that we >>> didn't introduce any 32-bit regressions. >> So in theory you can at least mfks & mount a 16T fs and beyond, if you'd >> like to test that. > > Isn't this just a snapshot? In that case, the package should follow the > standard naming guidelines > > https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages > > Rahul As far as I know, I did. If I did something wrong, can you provide me with some details? -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Test-DistManifest/el6] Changes for EPEL 4/5 compatibility
commit ffe0670781a4723ab64f936c51538e02ead4871f
Author: Paul Howarth
Date: Wed Aug 10 13:22:10 2011 +0100
Changes for EPEL 4/5 compatibility
- Changes for EPEL 4/5 compatibility:
- Add buildroot
- Add %clean section and clean buildroot at start of %install
- Patch out requirement for ExtUtils::MakeMaker ≥ 6.31 if necessary;
ExtUtils::MakeMaker 6.17 in RHEL-4 works just fine
- Drop Test::More ≥ 0.62 version requirement; Test::More 0.47 in RHEL-4
works just fine
- Drop Test::NoWarnings ≥ 0.084 version requirement; Test::NoWarnings
0.083
in EPEL-4 works just fine
- Add traditional dependency filtering scheme
- Disable debug package rather than removing its temporary files to avoid
breaking the manifest test
- No need to set compiler optimization flags for noarch package
- Drop redundant explicit runtime dependency on perl(Test::Builder)
- Simplify dependency filtering
- Run the release tests too
- BR: perl(Pod::Coverage::TrustPod), perl(Test::Kwalitee), perl(Test::Pod),
perl(Test::Pod::Coverage) and perl(Test::Portability::Files) for the
release tests
Test-DistManifest-1.011-old-eu::mm.patch | 30 +++
perl-Test-DistManifest.spec | 78 +++---
2 files changed, 90 insertions(+), 18 deletions(-)
---
diff --git a/Test-DistManifest-1.011-old-eu::mm.patch
b/Test-DistManifest-1.011-old-eu::mm.patch
new file mode 100644
index 000..1d42281
--- /dev/null
+++ b/Test-DistManifest-1.011-old-eu::mm.patch
@@ -0,0 +1,30 @@
+--- Test-DistManifest/Makefile.PL
Test-DistManifest/Makefile.PL
+@@ -4,7 +4,7 @@
+
+ BEGIN { require 5.008; }
+
+-use ExtUtils::MakeMaker 6.31;
++use ExtUtils::MakeMaker;
+
+
+
+@@ -16,7 +16,7 @@
+ 'Test::NoWarnings' => '0.084'
+ },
+ 'CONFIGURE_REQUIRES' => {
+-'ExtUtils::MakeMaker' => '6.31'
++'ExtUtils::MakeMaker' => '0'
+ },
+ 'DISTNAME' => 'Test-DistManifest',
+ 'EXE_FILES' => [],
+@@ -49,6 +49,9 @@
+ delete $WriteMakefileArgs{CONFIGURE_REQUIRES}
+ unless eval { ExtUtils::MakeMaker->VERSION(6.52) };
+
++delete $WriteMakefileArgs{LICENSE}
++ unless eval { ExtUtils::MakeMaker->VERSION(6.31) };
++
+ WriteMakefile(%WriteMakefileArgs);
+
+
diff --git a/perl-Test-DistManifest.spec b/perl-Test-DistManifest.spec
index f45ba99..42dd561 100644
--- a/perl-Test-DistManifest.spec
+++ b/perl-Test-DistManifest.spec
@@ -1,36 +1,46 @@
+# We don't really need ExtUtils::MakeMaker ≥ 6.31
+%global old_eumm %(perl -MExtUtils::MakeMaker -e 'printf "%d\\n",
$ExtUtils::MakeMaker::VERSION < 6.31 ? 1 : 0;' 2>/dev/null || echo 0)
+
+# noarch, but to avoid debug* files interfering with manifest test:
+%global debug_package %{nil}
+
Name: perl-Test-DistManifest
Version:1.011
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Author test that validates a package MANIFEST
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Test-DistManifest/
Source0:
http://www.cpan.org/authors/id/J/JA/JAWNSY/Test-DistManifest-%{version}.tar.gz
+Patch0: Test-DistManifest-1.011-old-eu::mm.patch
BuildArch: noarch
-BuildRequires: perl(ExtUtils::MakeMaker) >= 6.31
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
+BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::Spec)
BuildRequires: perl(File::Spec::Unix)
BuildRequires: perl(Module::Manifest) >= 0.07
BuildRequires: perl(Test::Builder)
-BuildRequires: perl(Test::More) >= 0.62
+BuildRequires: perl(Test::More)
# Tests only:
BuildRequires: perl(Test::Builder::Tester)
-BuildRequires: perl(Test::NoWarnings) >= 0.084
+BuildRequires: perl(Test::NoWarnings)
+# Release tests
+BuildRequires: perl(Pod::Coverage::TrustPod)
+%if 0%{?fedora} || 0%{?rhel} > 5
+BuildRequires: perl(Test::Kwalitee)
+%endif
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage)
+BuildRequires: perl(Test::Portability::Files)
+# Runtime requirements
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
Requires: perl(Module::Manifest) >= 0.07
-Requires: perl(Test::Builder)
# This is a plug-in into Test::More. Depend on it even if not mentioned in the
# code
-Requires: perl(Test::More) >= 0.62
+Requires: perl(Test::More)
-%{?perl_default_filter:
-# Filter underspecifed dependencies
-%filter_from_requires /^perl(Module::Manifest)$/d
-# Filter multiple dependencies
-%filter_from_requires /^perl(Test::Builder)$/d
-%perl_default_filter
-}
-%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}perl\\((Module::Manifest|Test::Builder)\\)$
+# Filter underspecified dependency (rpm 4.9 onwards)
+%global __requires_exclude ^perl\\(Module::Manifest\\)$
%description
This module provides a simple method of testing that a MANIFEST matches the
@@ -39,11 +49,
python-fedora package split
This is a heads up for people packaging or using applications that depend on python-fedora. Currently, python-fedora is one package that contains code useful for both building clients that talk to Fedora Infrastructure Services and servers that run on Fedora Infrastructure (mainly CSRF protection and an auth provider to talk to the Fedora Account System). The package has Require: deps to make the client code run but not everything to make the server run as that would drag packages that are only needed on servers onto the clients. I've been requested to fix this so I'll be splitting the python-fedora package into three subpackages: python-fedora: will continue to provide the client code. It will continue to have the same deps as the current package. python-fedora-turbogears: will provide the helpers for integrating with TurboGears1 and TurboGears2 applications. This package will dep on the TurboGears and TurboGears2 packages in addition to the base package. python-fedora-django: will provide the integration with django servers. It will dep on Django in addition to the python-fedora base package. For packagers, developers, and sysadmins needing python-fedora client code, this should mean you need to make no changes. yum install python-fedora or Requires: python-fedora will continue to get you python-fedora and the minimal deps needed for the client code to function. For packagers, developers, and sysadmins working with server apps that need python-fedora's server helper code, you'll need to update to pulling in the subpackage relevant to your framework (for instance, bodhi should change to use Requires: python-fedora-turbogears ). The lack of complete deps was noted on an F14 box... since this is a somewhat disruptive change (hopefully only for the relatively small number of people working with server code) I was debating how far back to push it. Since it needs to go into EPEL5 and EPEL6 as well as Fedora I've decided that I'll push it out to F15+ as a compromise between keeping things stable and fixing the issue everywhere. Thank you, -Toshio pgpSZmp8RDFYs.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide
On 08/10/2011 07:59 AM, Rahul Sundaram wrote: > On 08/09/2011 06:45 PM, Eric Sandeen wrote: >>> I've made the first WIP release of e2fsprogs 1.42. The primary purpose >>> is for people to test the 64-bit functionality and be confident that we >>> didn't introduce any 32-bit regressions. >> So in theory you can at least mfks & mount a 16T fs and beyond, if you'd >> like to test that. > > Isn't this just a snapshot? In that case, the package should follow the > standard naming guidelines > > https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages > > Rahul The subject has upstream's name/version, but as packaged, it's: Package Namee2fsprogs Version 1.42 Release 0.1.WIP.0702.fc17 which is correct, AFAICT. -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Test-DistManifest/el5] Changes for EPEL 4/5 compatibility
Summary of changes: ffe0670... Changes for EPEL 4/5 compatibility (*) (*) This commit already existed in another branch; no separate mail sent -- 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
[perl-Test-DistManifest/el4] Changes for EPEL 4/5 compatibility
Summary of changes: ffe0670... Changes for EPEL 4/5 compatibility (*) (*) This commit already existed in another branch; no separate mail sent -- 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
fusecompress needs new maintainers/comaintainers
Greetings, For the past few release cycles I've been keeping fusecompress alive since I was using it on a box with limited HD space. Now that I no longer use that box, I don't use fusecompress anymore. The maintainer and other comaintainers of our fusecompress package are busy and have also stopped using fusecompress so it would be great if someone who does use it would like to work on it for future releases. Upstream for fusecompress does not release often so there's not too much work there. It requires a rebuild almost every cycle as it requires boost and boost gets upgraded ABI incompatibly almost every Fedora releasre cycle (I haven't had to port to new API in several release cycles, though). -Toshio pgp85JYGuUU1S.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: python-fedora package split
On Wed, 2011-08-10 at 10:51 -0700, Toshio Kuratomi wrote: > For packagers, developers, and sysadmins needing python-fedora client > code, > this should mean you need to make no changes. yum install > python-fedora > or Requires: python-fedora will continue to get you python-fedora and > the > minimal deps needed for the client code to function. > > For packagers, developers, and sysadmins working with server apps that > need > python-fedora's server helper code, you'll need to update to pulling > in the > subpackage relevant to your framework (for instance, > bodhi should change to use Requires: python-fedora-turbogears ). With the traditionnal dependency chain: $ repoquery --whatrequires python-fedora python-fedora-0:0.3.23-1.fc14.noarch beacon-0:0.5-3.fc12.noarch bodhi-client-0:0.7.9-2.fc14.noarch bodhi-client-0:0.8.0-1.fc14.noarch bodhi-server-0:0.7.9-2.fc14.noarch bodhi-server-0:0.8.0-1.fc14.noarch cnucnu-0:0-0.5.20100704git0fe054e7.fc14.noarch cnucnu-0:0-0.7.20110308git2033ec78.fc14.noarch fedora-business-cards-0:0.2.4.2-4.fc14.noarch fedora-business-cards-0:0.2.4.3-1.fc14.noarch fedora-easy-karma-0:0-0.7.20100709git561718c8.fc14.noarch fedora-easy-karma-0:0-0.10.20101123gitf70e9b6d.fc14.noarch fedpkg-0:0.5.1.4-5.fc14.noarch fedpkg-0:0.5.9.2-1.fc14.noarch mirrormanager-0:1.3.7-1.fc14.noarch sigul-0:0.97-2.fc14.noarch supybot-fedora-0:0.2.8-2.fc14.noarch supybot-fedora-0:0.2.8-3.fc14.noarch (sorry it's the F14 version) Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Test-DistManifest] Created tag perl-Test-DistManifest-1.011-3.fc14
The lightweight tag 'perl-Test-DistManifest-1.011-3.fc14' was created pointing to: 71d4870... update filtering for rpm 4.9 -- 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
[perl-Test-DistManifest] Created tag perl-Test-DistManifest-1.011-3.fc15
The lightweight tag 'perl-Test-DistManifest-1.011-3.fc15' was created pointing to: 71d4870... update filtering for rpm 4.9 -- 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
[perl-Test-DistManifest] Created tag perl-Test-DistManifest-1.011-4.el4
The lightweight tag 'perl-Test-DistManifest-1.011-4.el4' was created pointing to: ffe0670... Changes for EPEL 4/5 compatibility -- 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
[perl-Test-DistManifest] Created tag perl-Test-DistManifest-1.011-4.el5
The lightweight tag 'perl-Test-DistManifest-1.011-4.el5' was created pointing to: ffe0670... Changes for EPEL 4/5 compatibility -- 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
[perl-Test-DistManifest] Created tag perl-Test-DistManifest-1.011-4.el6
The lightweight tag 'perl-Test-DistManifest-1.011-4.el6' was created pointing to: ffe0670... Changes for EPEL 4/5 compatibility -- 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: Which db should I build this package against?
On Wed, 2011-08-10 at 08:43 -0700, John Reiser wrote: > Perhaps upstream could deliver N shared libraries, then at run time > use > dlopen() to load the one which corresponds to the database package > that is being used. > > Thank you for all the suggestions. I'll try the sub package method first and see where it gets me. :) -- Thanks, Regards, Ankur: "FranciscoD" http://fedoraproject.org/wiki/User:Ankursinha http://dodoincfedora.wordpress.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 729504] perl-Dancer: please update to version 1.3071
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=729504 --- Comment #8 from Jose Pedro Oliveira 2011-08-10 14:28:55 EDT --- (In reply to comment #6) --[SNIP]-- > > I'll do updates in Fedora, you can take it in EPEL if you wish. Ok. I will start requesting EPEL-6 branches for the missing requirements and looking into the perl-Devel-StackTrace version problem. Regards, jpo -- 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 perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: python-fedora package split
On Wed, Aug 10, 2011 at 08:01:11PM +0200, Pierre-Yves Chibon wrote: > On Wed, 2011-08-10 at 10:51 -0700, Toshio Kuratomi wrote: > > For packagers, developers, and sysadmins needing python-fedora client > > code, > > this should mean you need to make no changes. yum install > > python-fedora > > or Requires: python-fedora will continue to get you python-fedora and > > the > > minimal deps needed for the client code to function. > > > > For packagers, developers, and sysadmins working with server apps that > > need > > python-fedora's server helper code, you'll need to update to pulling > > in the > > subpackage relevant to your framework (for instance, > > bodhi should change to use Requires: python-fedora-turbogears ). > > With the traditionnal dependency chain: > > $ repoquery --whatrequires python-fedora Of those,the ones using the server API and therefore needing to be updated are: > bodhi-server-0:0.7.9-2.fc14.noarch > bodhi-server-0:0.8.0-1.fc14.noarch > mirrormanager-0:1.3.7-1.fc14.noarch Thanks, -Toshio pgpdx4ubIdZt9.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 729768] New: Provides perl(Switch) improperly
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Provides perl(Switch) improperly https://bugzilla.redhat.com/show_bug.cgi?id=729768 Summary: Provides perl(Switch) improperly Product: Fedora Version: 16 Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: unspecified Priority: unspecified Component: perl-POE-Test-Loops AssignedTo: cw...@alumni.drew.edu ReportedBy: tcall...@redhat.com QAContact: extras...@fedoraproject.org CC: cw...@alumni.drew.edu, fedora-perl-devel-l...@redhat.com Classification: Fedora Story Points: --- Type: --- Description of problem: This package claims to provide perl(Switch), but it does not, this is a false Provides. -- 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 perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: 2011-07-29 - F16 Alpha blocker bug review #3 - recap
2011/8/2 Andreas Tunek : > 2011/8/2 Adam Williamson : >> On Sun, 2011-07-31 at 11:40 +0200, Andreas Tunek wrote: >>> 2011/7/29 James Laska : >>> >>> > >>> > * http://bugzilla.redhat.com/show_bug.cgi?id=711489 (jlaska, 17:42:29) >>> > * atl1c: transmit queue timeout (ASUS 522) (jlaska, 17:42:33) >>> > * AGREED: 711489 - RejectedBlocker - nasty, but impacts limited >>> > hardware and has a workaround. May re-evaluate if new information >>> > surfaces (jlaska, 17:48:14) >>> >>> What is the workaround for this bug? None is given in bugzilla. >> >> Yes, it is: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=711489#c2 > > Do you mean that having an active ethernet connection at all times is > the workaround? For all affected, here is a proper workaround: in /etc/modprobe.d/blacklist.conf add the follwing line blacklist atl1c reboot You won't have wired internet, but it won't crash when you unplug the cable. /Andreas >> -- >> Adam Williamson >> Fedora QA Community Monkey >> IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora >> http://www.happyassassin.net >> >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> > > /Andreas > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: make sure the DBVERSION file ends in a newline
From f989c36a523740f3ce7fe2dfee38e6e423f9ac8b Mon Sep 17 00:00:00 2001
From: Rich Megginson
Date: Wed, 10 Aug 2011 14:56:54 -0600
Subject: [PATCH] make sure the DBVERSION file ends in a newline
---
ldap/servers/slapd/back-ldbm/dbversion.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/ldap/servers/slapd/back-ldbm/dbversion.c b/ldap/servers/slapd/back-ldbm/dbversion.c
index 5c5cdeb..4c47c3d 100644
--- a/ldap/servers/slapd/back-ldbm/dbversion.c
+++ b/ldap/servers/slapd/back-ldbm/dbversion.c
@@ -122,7 +122,9 @@ dbversion_write(struct ldbminfo *li, const char *directory,
len = strlen(buf);
ptr = buf + len;
}
-len = strlen( buf );
+/* end in a newline */
+PL_strncpyz(ptr, "\n", sizeof(buf) - len);
+len = strlen(buf);
if ( slapi_write_buffer( prfd, buf, len ) != len )
{
LDAPDebug( LDAP_DEBUG_ANY, "Could not write to file \"%s\"\n", filename, 0, 0 );
--
1.7.1
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please review: make sure the DBVERSION file ends in a newline
ack. Thanks, Rich!! --noriko Rich Megginson wrote: -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[Test-Announce] 2011-08-12 @ 17:00 UTC - F16 Alpha Blocker Bug Review #5
# F16 Alpha Blocker Review meeting #3 # Date: 2011-08-12 # Time: 17:00 UTC [1] (13:00 EDT, 10:00 PDT, 10:00 MST) # Location: #fedora-bugzappers on irc.freenode.net The Fedora 16 alpha release has been pushed back a week, so we get another blocker bug review meeting for alpha! The next Fedora 16 Alpha go/no_go meeting will be on August 17 [2]. The fifth Alpha blocker review meeting starts at 17:00 UTC in #fedora-bugzappers. We'll review proposed and accepted F16 Alpha blocker bugs. An updated list of blocker bugs is available at https://fedoraproject.org/wiki/Current_Release_Blockers. We'll be reviewing the bugs to determine ... 1. Whether they meet the Alpha release criteria [3] and should stay on the list 2. Whether they are getting the attention they need For guidance on Blocker and Nice-to-have (NTH) bugs, refer to https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and https://fedoraproject.org/wiki/QA:SOP_nth_bug_processp Thanks, Tim == Suggested Meeting Preparation == Maintainers ... * If your bug is *not* MODIFIED ... this issue is at risk of slipping the release date * If your bug is in MODIFIED ... please make sure a build with the fix exists Testers ... * If you REPORT a bug ... please be responsive to any requests for additional information. * Help test Fedora 16 alpha ... https://fedoraproject.org/wiki/Category:Fedora_16_Alpha_RC_Test_Results [1] https://fedoraproject.org/wiki/Infrastructure/UTCHowto [2] http://rbergero.fedorapeople.org/schedules/f-16/f-16-quality-tasks.html [3] https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria signature.asc Description: PGP signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive maintainer: cvsgraph
Kevin Fenzi scrye.com> writes: > You may need commit on devel/master as well? > If you apply I can get you approved. Applied. Thanks for your help. -- Bojan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 16 Alpha to slip by one week.
Today at the Go/No-Go meeting it was decided to slip the Alpha by one week[1]. Minutes follow below. There are numerous unresolved blocker bugs at this time[2], requiring the creation of an RC4 once these blockers are resolved. As a result, ALL MAJOR MILESTONES, and their dependent tasks, will be pushed out by one week. We will proceed with having the F16 Alpha readiness meeting tomorrow, 2011-08-11, as previously announced on the Logistics mailing list. We will have another F16 Alpha Blocker Bug meeting this Friday. The adjustments to the F16 schedule will be done (very late) tonight, and published to the Schedule wiki page[3]. Thanks for your patience. We will be meeting again next Wednesday for another Go/No-Go meeting. -Robyn [1] Logs: http://meetbot.fedoraproject.org/fedora-meeting/2011-08-10/f16_alpha_gono-go_meeting.2011-08-10-21.00.log.html Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2011-08-10/f16_alpha_gono-go_meeting.2011-08-10-21.00.html [2] https://fedoraproject.org/wiki/Current_Release_Blockers [3] https://fedoraproject.org/wiki/Releases/16/Schedule === #fedora-meeting: F16 Alpha Go/No-Go Meeting === Meeting started by rbergeron at 21:00:26 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-08-10/f16_alpha_gono-go_meeting.2011-08-10-21.00.log.html Meeting summary --- * present: spot, codeblock, dgilmore, pjones, athmane, cebbert, jsmith-mobile, adamw (rbergeron, 21:03:42) * Go/No-Go Meeting (rbergeron, 21:04:07) * the Purpose of the Go/No-Go is to gather yay/nay's from Release Engineering, QA, and devel on whether or not what we have put together is ready for release and meets the release criteria. (rbergeron, 21:05:28) * LINK: https://fedoraproject.org/wiki/Go_No_Go_Meeting (adamw, 21:06:17) * LINK: https://fedoraproject.org/wiki/Current_Release_Blockers <-- that one I know by heart, though. (rbergeron, 21:06:42) * Proposed Blockers (rbergeron, 21:09:50) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=729563 (rbergeron, 21:10:04) * clumens has an updates image (linked in BZ) for people to try out. (rbergeron, 21:12:33) * AGREED: : #729563, NTH Alpha, consider adding criterion for selinux must be enabled by default later. (rbergeron, 21:14:39) * http://bugzilla.redhat.com/show_bug.cgi?id=729500 (rbergeron, 21:15:04) * Error while installing updates on Fedora 16 Alpha RC3 (rbergeron, 21:15:20) * AGREED: revisit #729563 at Blocker meeting friday, try to get more testers. PLEASE TEST THIS ONE AND TRY TO DUPLICATE, FOLKS! (rbergeron, 21:17:34) * https://bugzilla.redhat.com/show_bug.cgi?id=729528 (rbergeron, 21:17:53) * #729528 - Unable to configure events in reporter to forward in anaconda for F-16-Alpha-RC3 (rbergeron, 21:18:09) * AGREED: #729528 Alpha Blocker, per criterion of installer must be able to report failures to BZ, wiht appropriate info included. (rbergeron, 21:22:19) * http://bugzilla.redhat.com/show_bug.cgi?id=729537 (rbergeron, 21:22:53) * 729537 - Anaconda cannot report crashes in text mode in F16 Alpha RC3 due to missing report-cli (rbergeron, 21:23:14) * AGREED: 729537 Alpha Blocker, per criterion of installer must be able to report failures to BZ, with appropriate info included. (rbergeron, 21:25:32) * https://bugzilla.redhat.com/show_bug.cgi?id=728707 (rbergeron, 21:25:48) * 728707 - on package upgrade RPM is removing empty directories accidentally (rbergeron, 21:26:02) * AGREED: 728707 is a blocker under 'must be able to install updates' criterion - this constitutes not installing updates properly (adamw, 21:33:36) * https://bugzilla.redhat.com/show_bug.cgi?id=729600 (adamw, 21:37:37) * LINK: http://docs.fedoraproject.org/en-US/Fedora/15/html/Installation_Guide/Making_USB_Media-UNIX_Linux.html (jlk, 21:47:30) * AGREED: 729600 not blocker or nth, installing from a dd'ed DVD iso is expected to require extra configuration. documentation should be improved to outline the steps required (adamw, 21:56:27) * https://bugzilla.redhat.com/show_bug.cgi?id=728863 (adamw, 21:57:30) * go/no-go vote (adamw, 22:00:30) * AGREED: Fedora 16 Alpha is no-go at this time (adamw, 22:01:32) * ACTION: rbergeron will take care of updating the schedules (adamw, 22:02:04) * open floor (adamw, 22:03:40) Meeting ended at 22:05:08 UTC. Action Items * rbergeron will take care of updating the schedules Action Items, by person --- * rbergeron * rbergeron will take care of updating the schedules * **UNASSIGNED** * (none) People Present (lines said) --- * adamw (167) * rbergeron (73) * pjones (66) * jlk (49) * dgilmore (36) * Viking_Alpha (35) * tfli
gnome-screensaver: How reliable is it for you?
I'm having regular but intermittent problems with gnome-screensaver not locking before swiching users (i.e. leaving an X session unlocked) or when gnome-shell crashes. My bugs are getting no interest, so the problem must be just with me. Is anyone else experiencing similar problems? Ref: https://bugzilla.redhat.com/show_bug.cgi?id=697199 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
