Re: what is initramfs-0-rescue in F19?
Am 09.04.2013 00:00, schrieb Jeffrey Bastian:
On Mon, Apr 08, 2013 at 04:03:47PM -0500, Jeffrey Bastian wrote:
I removed my initramfs-0-rescue-* file because I didn't know what it was
and no rpm claimed to own it. How do I get it back? I've tried running
dracut with various options and it doesn't regenerate the image.
Attempting to answer my own question... I'm not sure if this is the
correct way, but I tried running this:
/etc/kernel/postinst.d/51-dracut-rescue-postinst.sh $(uname -r) \
/boot/initramfs-$(uname
-r)*
And now I have rescue files again:
# ls -latr /boot/*0-rescue*
-rw---. 1 root root 27496022 Apr 8 16:46
/boot/initramfs-0-rescue-...img
-rw---. 1 root root 7860871 Apr 8 16:46 /boot/vmlinuz-0-rescue-...
Is dracut supposed to run the /etc/kernel/postinst.d/* scripts
automatically? I ran dracut through 'bash -x' and strace and it didn't
appear to even look in /etc/kernel/postinst.d
The reason I removed the file in the first place is because grub2-mkconfig
generates a not-very-descriptive entry in the menu. My grub.cfg now has this:
menuentry 'Fedora, with Linux 0-rescue-344...c20' ... {
Furthermore, my system is set up to dual boot between Fedora 17 and 19
Alpha, and now grub2-mkconfig has set this rescue image as the default
kernel for F17.
menuentry 'Fedora release 17 (Beefy Miracle)' ... {
...
linux /vmlinuz-0-rescue-344...
}
That seems a little strange to me.
Jeff
/etc/kernel/postinst.d/* scripts are called by new-kernel-pkg, which is called
in the kernel.spec, when you install a kernel.
new-kernel-pkg uses grubby to generate a grub config.
grub2-mkconfig destroys anything grubby has setup.
Well, we could patch grub2-mkconfig to recognize the rescue image, but we should
better concentrate to make grub2-mkconfig obsolete and integrate the bootloader
spec.
http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Keeping old versions of packages
Using PackageKit and yum on the command line is often painful as we have to always download metadata unless it's less than a few hours old. Being able to update the metadata once a week would be awesome (with the possible exception of security updates) so that we could schedule the 20Mb+ metadata update when the user is idle rather than waiting for updates. I'm wondering what the interest would be in keeping packages referenced in metadata on the mirrors for say a month? We'd probably need a separate fedora-security repo too that's designed to be kept small enough so that metadata checks every day would be not costly in terms of bandwidth and time. If anyone is interested in doing this, you'd be awesome. Thanks. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On 9 April 2013 10:21, Reindl Harald h.rei...@thelounge.net wrote: metadata_expire=7d From a package manager point of view, this happens: 1 check expire timeout, all okay 2 depsolve update set 3 download 4 package not found! 5 download needed metadata based on some heuristic 6 goto 2 Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-19 Branched report: 20130409 changes
Compose started at Tue Apr 9 09:15:14 UTC 2013 Broken deps for x86_64 -- [aeolus-conductor] aeolus-conductor-0.10.6-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [alexandria] alexandria-0.6.9-4.fc19.noarch requires ruby(abi) = 0:1.9.1 [amide] amide-1.0.0-4.fc19.x86_64 requires libvolpack.so.1()(64bit) [clementine] clementine-1.1.1-1.fc19.x86_64 requires libprotobuf.so.7()(64bit) clementine-1.1.1-1.fc19.x86_64 requires libimobiledevice.so.3()(64bit) [connman] connman-1.5-4.fc19.i686 requires libxtables.so.7 connman-1.5-4.fc19.i686 requires libgnutls.so.26(GNUTLS_1_4) connman-1.5-4.fc19.i686 requires libgnutls.so.26 connman-1.5-4.fc19.x86_64 requires libxtables.so.7()(64bit) connman-1.5-4.fc19.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit) connman-1.5-4.fc19.x86_64 requires libgnutls.so.26()(64bit) [deltacloud-core] deltacloud-core-1.0.5-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [denemo] denemo-0.9.4-0.fc18.x86_64 requires libgtksourceview-3.0.so.0()(64bit) [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [eruby] eruby-1.0.5-19.fc18.x86_64 requires libruby.so.1.9()(64bit) eruby-libs-1.0.5-19.fc18.i686 requires ruby(abi) = 0:1.9.0 eruby-libs-1.0.5-19.fc18.i686 requires libruby.so.1.9 eruby-libs-1.0.5-19.fc18.x86_64 requires ruby(abi) = 0:1.9.0 eruby-libs-1.0.5-19.fc18.x86_64 requires libruby.so.1.9()(64bit) [fawkes] fawkes-firevision-0.5.0-5.fc19.i686 requires libjpeg.so.8(LIBJPEG_8.0) fawkes-firevision-0.5.0-5.fc19.i686 requires libjpeg.so.8 fawkes-firevision-0.5.0-5.fc19.x86_64 requires libjpeg.so.8(LIBJPEG_8.0)(64bit) fawkes-firevision-0.5.0-5.fc19.x86_64 requires libjpeg.so.8()(64bit) fawkes-guis-0.5.0-5.fc19.i686 requires libgraph.so.5 fawkes-guis-0.5.0-5.fc19.x86_64 requires libgraph.so.5()(64bit) fawkes-plugin-clips-0.5.0-5.fc19.i686 requires libclipsmm.so.2 fawkes-plugin-clips-0.5.0-5.fc19.x86_64 requires libclipsmm.so.2()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libgeos-3.3.6.so()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libboost_thread-mt.so.1.50.0()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libboost_system-mt.so.1.50.0()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libboost_signals-mt.so.1.50.0()(64bit) fawkes-plugin-tabletop-objects-0.5.0-5.fc19.x86_64 requires libboost_thread-mt.so.1.50.0()(64bit) fawkes-plugin-tabletop-objects-0.5.0-5.fc19.x86_64 requires libboost_system-mt.so.1.50.0()(64bit) [flowcanvas] flowcanvas-0.7.1-8.fc18.i686 requires libgraph.so.5 flowcanvas-0.7.1-8.fc18.x86_64 requires libgraph.so.5()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 [gdcm] gdcm-2.0.18-6.fc18.i686 requires libpoppler.so.26 gdcm-2.0.18-6.fc18.x86_64 requires libpoppler.so.26()(64bit) [gearbox] gearbox-10.11-3.fc19.i686 requires libIceUtil.so.35b gearbox-10.11-3.fc19.x86_64 requires libIceUtil.so.35b()(64bit) [gnome-applets] 1:gnome-applets-3.5.92-3.fc18.x86_64 requires libgweather-3.so.1()(64bit) [gnome-panel] gnome-panel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) gnome-panel-devel-3.6.2-6.fc19.i686 requires libgnome-desktop-3.so.5 gnome-panel-devel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) [gnome-pie] gnome-pie-0.5.3-3.20120826git1b93e1.fc19.x86_64 requires libbamf3.so.0()(64bit) [gnomint] gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_2_8)(64bit) gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit) gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26()(64bit) [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [gorm] gorm-1.2.18-1.fc19.i686 requires libgnustep-gui.so.0.22 gorm-1.2.18-1.fc19.x86_64 requires libgnustep-gui.so.0.22()(64bit) [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [libkolab] php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [matreshka] matreshka-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-mofext-0.3.0-3.fc19.i686
Re: Keeping old versions of packages
On Tue, Apr 09, 2013 at 10:10:26AM +0100, Richard Hughes wrote: I'm wondering what the interest would be in keeping packages referenced in metadata on the mirrors for say a month? We'd probably need a separate fedora-security repo too that's designed to be kept small enough so that metadata checks every day would be not costly in terms of bandwidth and time. If anyone is interested in doing this, you'd be awesome. Thanks. I've heard of a plan in development about batching non-critical updates into monthly sets. It seems like these two things could go together. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On Tue, Apr 09, 2013 at 02:48:40PM +0200, Reindl Harald wrote: depends often on the workload and currect jobs and the cirtical apllication wheer a bug will hurt you much may change from project to project As I understand it, you'll be able to opt for an all-updates track. In fact, that will be encouraged for active developers and testers. there are months where i would not care if LibreOffice does not start at all and there are weeks where i need it all day long So, presumably, you don't want it gratuitously updating during those times you need it all day long, and you don't care either way the rest of the time. Sounds perfect. -- Matthew Miller mat...@mattdm.org http://mattdm.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what is initramfs-0-rescue in F19?
/etc/kernel/postinst.d/* scripts are called by new-kernel-pkg, which is called in the kernel.spec, when you install a kernel. new-kernel-pkg uses grubby to generate a grub config. grub2-mkconfig destroys anything grubby has setup. Well, we could patch grub2-mkconfig to recognize the rescue image, but we should better concentrate to make grub2-mkconfig obsolete and integrate the bootloader spec. http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec grub2-mkconfig should be patched, too. Implementing the BooLoaderSpec just might encounter problems in practice, like every other attempt for the past 20 years to create a grand unified boot loader that correctly understands all existing OS and hardware configurations. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Alpha status: blockers, karma requests etc
- Original Message - Hi folks! Time for the first blocker status mail of the Fedora 19 cycle. The tl;dr summary: Hi Adam, thanks for summary. Updates follows. Input needed from blocker voters and developers on: * https://bugzilla.redhat.com/show_bug.cgi?id=947142 Three more are waiting for feedback: * https://bugzilla.redhat.com/show_bug.cgi?id=949912 * https://bugzilla.redhat.com/show_bug.cgi?id=923828 * https://bugzilla.redhat.com/show_bug.cgi?id=949831 Longer version follows. https://bugzilla.redhat.com/show_bug.cgi?id=947142 input on that from blocker voters and relevant developers would be very helpful. It is quite hard to decide on the blocker status of the bug without some kind of information on how many UEFI systems it is likely to affect. Of course, the sooner a fix or workaround can be devised, the better. The fix is worked on upstream, Matthew Garrett has patches submitted, concerns by EFI maintainer but seems we could get at least some patches soon in case we will need it, not sure how soon. Jwb thinks the impact could be low, I hope we will get more info from Peter/Mathew. Also Kamil hit some UEFI bugs. * https://bugzilla.redhat.com/show_bug.cgi?id=949912 ValueError: Cannot remove extended partition sda4. Logical partitions present. dlehman has a working fix in case we will need it (and no workaround is known) * https://bugzilla.redhat.com/show_bug.cgi?id=923828 kactivitymanagerd crashed on KDE start, running debug kernel Seems like not very reproducible even with debug kernel enabled and somehow related to disabling services - non default configuration? * https://bugzilla.redhat.com/show_bug.cgi?id=949831 Fedora 19 RC1 - Cannot open theme file /usr/share/kde4/apps/kdm/themes/SphericalCow - Wrong default theme The RC1 is broken, regression as schroedinger-cat-kde-theme-18.91.5-1.fc19 and kde-settings-19-16.fc19 were not picked up (part of TC4+). So at least the last one is fixable just by requesting a new compose with correct kde theme and kde settings. For Anaconda one, we have a fix, thanks dlehman! So please, let feedback on the proposed bugs, don't forget the Go/No-Go meeting is in two days! Thanks everyone, and let's hope we can get the Alpha out on time for once! Go/no-go is on Thursday, so we need to have a build fully tested without blockers by then. Thanks guys Jaroslav /me will be online again later today... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list t...@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Weird broken deps.
On Mon, Apr 8, 2013 at 8:00 PM, Michael Schwendt mschwe...@gmail.com wrote:
On Mon, 8 Apr 2013 19:51:15 +0300, Gilboa Davara wrote:
Hello all,
Can anyone help me make sense of the following broken-dep message?
springlobby has broken dependencies in the rawhide tree:
On i386:
springlobby-0.169-2.fc20.i686 requires
bdb835272157f37cbb0067c02ab4fc437596ed.debug
springlobby-0.169-2.fc20.i686 requires
508df0cdc1c9e84cded295738bec13842f070d.debug
Please resolve this as soon as possible.
?!?!
- Gilboa
On platforms where %_libdir is /usr/lib, don't include
%{_libdir}/*
in the %files section, because it will include the -debuginfo package
files. Be more specific about which files you want to include in your
package.
Got it. Thanks.
- Gilboa
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
Am 09.04.2013 11:10, schrieb Richard Hughes: Using PackageKit and yum on the command line is often painful as we have to always download metadata unless it's less than a few hours old. Being able to update the metadata once a week would be awesome (with the possible exception of security updates) so that we could schedule the 20Mb+ metadata update when the user is idle rather than waiting for updates [root@rh:~]$ cat /etc/yum.repos.d/fedora.repo [fedora] name=Fedora $releasever - $basearch failovermethod=priority #baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/ mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releaseverarch=$basearch enabled=1 metadata_expire=7d I'm wondering what the interest would be in keeping packages referenced in metadata on the mirrors for say a month? We'd probably need a separate fedora-security repo too that's designed to be kept small enough so that metadata checks every day would be not costly in terms of bandwidth and time this does not work for many reasons and having more repos would make things worser with low bandwidth because you have to load more metadata at all and if i want search for updates i use yum clean metadata yum upgrade which is a real pain on slow bandwith the reason is that the metadata getting larger and larger because all of the shiny ideas what additional ones would be nice while the developers are on LAN or at least very fast LAN networks signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
Am 09.04.2013 14:27, schrieb Matthew Miller: On Tue, Apr 09, 2013 at 10:10:26AM +0100, Richard Hughes wrote: I'm wondering what the interest would be in keeping packages referenced in metadata on the mirrors for say a month? We'd probably need a separate fedora-security repo too that's designed to be kept small enough so that metadata checks every day would be not costly in terms of bandwidth and time. If anyone is interested in doing this, you'd be awesome. Thanks. I've heard of a plan in development about batching non-critical updates into monthly sets. It seems like these two things could go together a terrible idea for a distribution with a new release all 6 months if i want monthly pacthdays i use Microsoft or Oracle you can hardly classify which bug is for which user critical! depends often on the workload and currect jobs and the cirtical apllication wheer a bug will hurt you much may change from project to project there are months where i would not care if LibreOffice does not start at all and there are weeks where i need it all day long signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On 9 April 2013 13:48, Reindl Harald h.rei...@thelounge.net wrote: if i want monthly pacthdays i use Microsoft or Oracle Not at all. Patchdays make perfect sense for planning reboots/downtime/maintenance and that kind of thing. you can hardly classify which bug is for which user critical! Sure you can, Red Hat does it for updates in RHEL, and you just have to define what the terms mean. 90% of the updates I'm looking at right now for F18 are really not important at all. Spec file fixups, new versions without bugfixes, updated artwork; that can all wait until a certain point in the month. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
Hi, Am 09.04.2013 14:27, schrieb Matthew Miller: On Tue, Apr 09, 2013 at 10:10:26AM +0100, Richard Hughes wrote: I'm wondering what the interest would be in keeping packages referenced in metadata on the mirrors for say a month? We'd probably need a separate fedora-security repo too that's designed to be kept small enough so that metadata checks every day would be not costly in terms of bandwidth and time. If anyone is interested in doing this, you'd be awesome. Thanks. I've heard of a plan in development about batching non-critical updates into monthly sets. It seems like these two things could go together I'm sorry, but that is a very bad idea. When users report bugs, and I mean real bugs here, like crashes or non working functionality. I always do my best to get them a fixed package asap, and AFAIK they really appreciate this. Moreover this is just a very non Fedora thing to do, one of the things Fedora is, is about being First. A lot of out users expect us to quickly give them new packages after upstream bug-fix releases. Lumping these all together in a single day in the month just does not feel like a Fedora thing to do. Also many packages in Fedora are maintained by volunteers lumping all the updates together will mean a flag day where all of the packages maintained by someone will get pushed at once, leading to a peak in work load, since despite testing, etc. There will be regressions as well as new packages sometimes leading to questions. And there also will be a peak workload a few days before the flag day to try and get things in now, instead of needing to wait a month. Having such peak workloads is not a good idea in general, and esp. not with volunteers. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On 9 April 2013 16:16, Hans de Goede hdego...@redhat.com wrote: them new packages after upstream bug-fix releases. Lumping these all together in a single day in the month just does not feel like a Fedora thing to do. You can't QA a trickle. If packages are small and self-contained then sure, it might work, but applications depending on ~30 other libraries and ~20 other daemons not so much. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl] Sub-package Sys-Syslog
commit b177230d9a1d764faf4402a4a1e29b16818b2392
Author: Petr Písař ppi...@redhat.com
Date: Tue Apr 9 16:44:54 2013 +0200
Sub-package Sys-Syslog
perl.spec | 31 +--
1 files changed, 29 insertions(+), 2 deletions(-)
---
diff --git a/perl.spec b/perl.spec
index 4964763..896c4e7 100644
--- a/perl.spec
+++ b/perl.spec
@@ -31,7 +31,7 @@
Name: perl
Version:%{perl_version}
# release number must be even higher, because dual-lived modules will be
broken otherwise
-Release:268%{?dist}
+Release:269%{?dist}
Epoch: %{perl_epoch}
Summary:Practical Extraction and Report Language
Group: Development/Languages
@@ -1476,6 +1476,19 @@ really be high enough to warrant the use of a keyword,
and the size so small
such that being individual extensions would be wasteful.
%endif
+%package Sys-Syslog
+Summary:Perl interface to the UNIX syslog(3) calls
+Group: Development/Libraries
+License:GPL+ or Artistic
+Epoch: 0
+Version:0.29
+Requires: %perl_compat
+Requires: perl(XSLoader)
+
+%description Sys-Syslog
+Sys::Syslog is an interface to the UNIX syslog(3) function. Call syslog() with
+a string priority and a list of printf() arguments just like at syslog(3).
+
%if %{dual_life} || %{rebuild_from_scratch}
%package Term-UI
Summary:Term::ReadLine UI made easy
@@ -1776,7 +1789,8 @@ Requires: perl-Params-Check, perl-Parse-CPAN-Meta,
perl-Perl-OSType
Requires: perl-Pod-Checker, perl-Pod-Escapes, perl-Pod-LaTeX
Requires: perl-Pod-Parser, perl-Pod-Perldoc, perl-Pod-Usage
Requires: perl-podlators, perl-Pod-Simple
-Requires: perl-Socket, perl-Term-UI, perl-Test-Harness, perl-Test-Simple
+Requires: perl-Socket, perl-Sys-Syslog, perl-Term-UI, perl-Test-Harness,
+Requires: perl-Test-Simple
Requires: perl-Text-ParseWords, perl-Text-Soundex, perl-Thread-Queue
Requires: perl-Time-Local, perl-Time-Piece, perl-Version-Requirements,
Requires: perl-version, perl-threads, perl-threads-shared, perl-parent
@@ -2610,6 +2624,11 @@ sed \
%exclude %{_mandir}/man3/List::Util*
%exclude %{_mandir}/man3/Scalar::Util*
+# Sys-Syslog
+%exclude %{archlib}/Sys/Syslog.pm
+%exclude %{archlib}/auto/Sys/Syslog/
+%exclude %{_mandir}/man3/Sys::Syslog.*
+
# Term-UI
%exclude %{privlib}/Term/UI.pm
%exclude %{privlib}/Term/UI/
@@ -3337,6 +3356,11 @@ sed \
%{_mandir}/man3/Scalar::Util*
%endif
+%files Sys-Syslog
+%{archlib}/Sys/Syslog.pm
+%{archlib}/auto/Sys/Syslog/
+%{_mandir}/man3/Sys::Syslog.*
+
%if %{dual_life} || %{rebuild_from_scratch}
%files Socket
%dir %{archlib}/auto/Socket
@@ -3448,6 +3472,9 @@ sed \
# Old changelog entries are preserved in CVS.
%changelog
+* Tue Apr 09 2013 Petr Pisar ppi...@redhat.com - 4:5.16.3-269
+- Sub-package Sys-Syslog (bug #950057)
+
* Fri Apr 05 2013 Petr Pisar ppi...@redhat.com - 4:5.16.3-268
- Sub-package Getopt-Long (bug #948855)
- Sub-package Locale-Maketext (bug #948974)
--
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: Self Introduction
Hi On Tue, Apr 9, 2013 at 1:59 AM, Ravindra Kumar ravindraku...@vmware.comwrote: Hi all, I work for VMware. My Fedora account name is ravindrakumar. I would like to contribute open-vm-tools package to ongoing development of Fedora 19. For more details about open-vm-tools project, please refer http://open-vm-tools.sourceforge.net/. My review request for this contribution can be tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=905255#c6 This is going to be my first contribution to Fedora, so I need a sponsor for my contribution. I would really appreciate if someone could review my work and sponsor me. Welcome to Fedora. If you are taking over from someone else, please file a new review request and close the existing one as duplicate. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Getopt-Long-2.39.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Getopt-Long: 84c8643de29faade9491c56d72afdba0 Getopt-Long-2.39.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
[perl-Getopt-Long] Import
commit a4ab06b5cbfcde1ccbc321ea888233ceb9f34f9d
Author: Petr Písař ppi...@redhat.com
Date: Tue Apr 9 17:33:40 2013 +0200
Import
.gitignore|1 +
perl-Getopt-Long.spec | 59 +
sources |1 +
3 files changed, 61 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..88890cd 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Getopt-Long-2.39.tar.gz
diff --git a/perl-Getopt-Long.spec b/perl-Getopt-Long.spec
new file mode 100644
index 000..2c117ee
--- /dev/null
+++ b/perl-Getopt-Long.spec
@@ -0,0 +1,59 @@
+Name: perl-Getopt-Long
+Version:2.39
+Release:1%{?dist}
+Summary:Extended processing of command line options
+License:GPLv2+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Getopt-Long/
+Source0:
http://www.cpan.org/authors/id/J/JV/JV/Getopt-Long-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl
+BuildRequires: perl(Config)
+BuildRequires: perl(lib)
+BuildRequires: perl(ExtUtils::MakeMaker) = 5.0
+# Run-time:
+BuildRequires: perl(constant)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(overload)
+BuildRequires: perl(strict)
+BuildRequires: perl(Text::ParseWords)
+BuildRequires: perl(vars)
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(overload)
+Requires: perl(Text::ParseWords)
+# Recommended:
+Requires: perl(Pod::Usage) = 1.14
+
+%description
+The Getopt::Long module implements an extended getopt function called
+GetOptions(). It parses the command line from @ARGV, recognizing and removing
+specified options and their possible values. It adheres to the POSIX syntax
+for command line options, with GNU extensions. In general, this means that
+options have long names instead of single letters, and are introduced with
+a double dash --. Support for bundling of command line options, as was the
+case with the more traditional single-letter approach, is provided but not
+enabled by default.
+
+%prep
+%setup -q -n Getopt-Long-%{version}
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc Announce CHANGES examples README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Fri Apr 05 2013 Petr Pisar ppi...@redhat.com 2.39-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..0f09931 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+84c8643de29faade9491c56d72afdba0 Getopt-Long-2.39.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: MySQL and MariaDB in Fedora
On Mon, 08 Apr 2013 09:38:53 +0200 Honza Horak hho...@redhat.com wrote: ...snip... How do we get push access to the git repo? It would be great to get 5.6 in before the test day on April 30. To get involved, just follow standard process as described on Fedora wiki: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers If any of the existing maintainers of the package are willing to mentor you, you could also use: http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer as a quicker way to get involved in just those packages. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
Richard Hughes (hughsi...@gmail.com) said: Using PackageKit and yum on the command line is often painful as we have to always download metadata unless it's less than a few hours old. Being able to update the metadata once a week would be awesome (with the possible exception of security updates) so that we could schedule the 20Mb+ metadata update when the user is idle rather than waiting for updates. I'm wondering what the interest would be in keeping packages referenced in metadata on the mirrors for say a month? We'd probably need a separate fedora-security repo too that's designed to be kept small enough so that metadata checks every day would be not costly in terms of bandwidth and time. If anyone is interested in doing this, you'd be awesome. Thanks. The thing that creates the repos is 'mash', so that's where such a change needs to be. It currently talks to koji to get the builds for a particular tag, and has the following config settings: latest = True Grab only the latest package latest = False Grab *all* the versions of the packages. It only supports these two variations, because that's what koji supports. If you wanted to keep more versions on the mirrors, you have the following options: 1) Have mash create everything, and then run a script that prunes versions older than X, and re-runs createrepo. We used to do this in the old days. It's an utter hack, and not very efficient. 2) Have mash try and implement a date-based expiry itself from what it requests from koji. The problem here is that mash pulls from koji, and only has two times that it could use as a key: - build time (not really what you want, as packages can build and sit for a while) - time it was tagged into the repo (which is affected by rel-eng operations if packages need to be retagged or moved) 3) Have mash sort through the packages retrieved by koji, and pull some subset less than 'all' (the last 2/3/4 versions). This is probably doable - it requires requesting all tagged packages from koji and then doing some postprocessing on the list before you download them. It's merely a matter of code. So, needless to say, I'd suggest anyone interested in this to look at option #3. Note that enabling something like that on rawhide would have a large effect on the repository creation time - there's only so many ways to speed up scanning across 5 packages 100GB on a SAN. Bill (former mash maintainer) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On Tuesday, April 09, 2013 11:52 PM, Bill Nottingham wrote: If you wanted to keep more versions on the mirrors, you have the following options: 1) Have mash create everything, and then run a script that prunes versions older than X, and re-runs createrepo. [... snip ...] 2) Have mash try and implement a date-based expiry itself from what it requests from koji. [... snip ...] 3) Have mash sort through the packages retrieved by koji, and pull some subset less than 'all' (the last 2/3/4 versions). This is probably doable - it requires requesting all tagged packages from koji and then doing some postprocessing on the list before you download them. It's merely a matter of code. It seems to me that all of these solutions focus on making mash do more stuff, without ever changing Koji. But couldn't the Koji API grow a new parameter, which would be used for specifying how many versions of each package to get at most? The current behaviour would be obtained by setting it to 1, and setting it to 2 would already be a positive change as it would allow downgrading a package if the update went wrong. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On Tue, Apr 09, 2013 at 05:16:45PM +0200, Hans de Goede wrote: I've heard of a plan in development about batching non-critical updates into monthly sets. It seems like these two things could go together I'm sorry, but that is a very bad idea. When users report bugs, and I mean real bugs here, like crashes or non working functionality. I always do my best to get them a fixed package asap, and AFAIK they really appreciate this. To be clear, the plan I heard (which isn't mine and I don't think is finished anyway) isn't to *withhold* updates until a certain date; it's to batch them up and make them available as a collection by default. If want all *or some* updates as soon as they become available, you could still do that. Also many packages in Fedora are maintained by volunteers lumping all the updates together will mean a flag day where all of the packages maintained by someone will get pushed at once, leading to a peak in work load, since despite testing, etc. There will be regressions as well as new packages sometimes leading to questions. And there also will be a peak workload a few days before the flag day to try and get things in now, instead of needing to wait a month. Having such peak workloads is not a good idea in general, and esp. not with volunteers. Overall, it's a more predictable workload, which *is* a good idea, for both volunteer and otherwise. It's also more effective to QA packages in sets, and more effective can mean more efficient. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On Tue, 2013-04-09 at 17:16 +0200, Hans de Goede wrote: Hi, Am 09.04.2013 14:27, schrieb Matthew Miller: On Tue, Apr 09, 2013 at 10:10:26AM +0100, Richard Hughes wrote: I'm wondering what the interest would be in keeping packages referenced in metadata on the mirrors for say a month? We'd probably need a separate fedora-security repo too that's designed to be kept small enough so that metadata checks every day would be not costly in terms of bandwidth and time. If anyone is interested in doing this, you'd be awesome. Thanks. I've heard of a plan in development about batching non-critical updates into monthly sets. It seems like these two things could go together I'm sorry, but that is a very bad idea. When users report bugs, and I mean real bugs here, like crashes or non working functionality. I always do my best to get them a fixed package asap, and AFAIK they really appreciate this. Moreover this is just a very non Fedora thing to do, one of the things Fedora is, is about being First. A lot of out users expect us to quickly give them new packages after upstream bug-fix releases. Lumping these all together in a single day in the month just does not feel like a Fedora thing to do. Also many packages in Fedora are maintained by volunteers lumping all the updates together will mean a flag day where all of the packages maintained by someone will get pushed at once, leading to a peak in work load, since despite testing, etc. There will be regressions as well as new packages sometimes leading to questions. And there also will be a peak workload a few days before the flag day to try and get things in now, instead of needing to wait a month. Having such peak workloads is not a good idea in general, and esp. not with volunteers. Can't they get them from updates-testing if they need a fix right now ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] New Branch - 389-ds-base-1.3.1
The new 389-ds-base-1.3.1 branch has been created. Commits for 1.3.1 will have to be checked into master first, then cherry-picked to 1.3.1 -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Keeping old versions of packages
On Wed, Apr 10, 2013 at 00:05:45 +0800, Mathieu Bridon boche...@fedoraproject.org wrote: The current behaviour would be obtained by setting it to 1, and setting it to 2 would already be a positive change as it would allow downgrading a package if the update went wrong. I don't think that is really what you want either. The idea is to keep recently obsoleted updates around, not 2 or 3 versions of everything. The change has some other benefits. Reverting bad updates in rawhide would be easier. You can use yum downgrade instead of having to going look at koji and download builds. Dealing with packages dropping out of repos when moving between test and updates. The latter issue is especially bad with branched during freezes. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On Wednesday, April 10, 2013 12:09 AM, Matthew Miller wrote: On Tue, Apr 09, 2013 at 05:16:45PM +0200, Hans de Goede wrote: I've heard of a plan in development about batching non-critical updates into monthly sets. It seems like these two things could go together I'm sorry, but that is a very bad idea. When users report bugs, and I mean real bugs here, like crashes or non working functionality. I always do my best to get them a fixed package asap, and AFAIK they really appreciate this. To be clear, the plan I heard (which isn't mine and I don't think is finished anyway) isn't to *withhold* updates until a certain date; it's to batch them up and make them available as a collection by default. If want all *or some* updates as soon as they become available, you could still do that. For what it's worth, this is exactly what we do at $dayjob. The way I set our repos up is that there are 1 testing repo, and 2 stable repos: current and released. We use Bodhi to move things from testing to current, as they get QA-ed, just like in Fedora. But by default, neither the current nor testing repositories are enabled. Only the released repository is. Once a month, we synchronize current into released. This way, we have the monthly « Patch Tuesday » by default, and it's trivial to move to the model of getting updates as they are published if you want to. It also allows users to be selective: they can get an update without waiting if it's important to them, but without updating everything else right now. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On Tue, 9 Apr 2013 11:18:54 -0500 Bruno Wolff III br...@wolff.to wrote: On Wed, Apr 10, 2013 at 00:05:45 +0800, Mathieu Bridon boche...@fedoraproject.org wrote: The current behaviour would be obtained by setting it to 1, and setting it to 2 would already be a positive change as it would allow downgrading a package if the update went wrong. I don't think that is really what you want either. The idea is to keep recently obsoleted updates around, not 2 or 3 versions of everything. The change has some other benefits. Reverting bad updates in rawhide would be easier. You can use yum downgrade instead of having to going look at koji and download builds. Dealing with packages dropping out of repos when moving between test and updates. The latter issue is especially bad with branched during freezes. So - this is just an idea - and not necessarily a good one - but what about moving older pkgs which are not in the initial release repo into an updates-archive repo. We could leave the repo disabled by default and only keep 2 copies of any single pkg name in the repo at a time. That way in the best of all possible worlds you'd have at most 4 copies of a pkg in total: 1 - in the base release 'everything' repo 1 - in updates 2 - in updates-archive -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
Thanks Rahul. Given that Simone has already accepted existing bug for review, I will create a new bug if he is ok with that. Does that sound ok? Thanks, Ravindra - Original Message - From: Rahul Sundaram methe...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Tuesday, April 9, 2013 8:32:26 AM Subject: Re: Self Introduction Hi On Tue, Apr 9, 2013 at 1:59 AM, Ravindra Kumar ravindraku...@vmware.com wrote: Hi all, I work for VMware. My Fedora account name is ravindrakumar. I would like to contribute open-vm-tools package to ongoing development of Fedora 19. For more details about open-vm-tools project, please refer http://open-vm-tools.sourceforge.net/ . My review request for this contribution can be tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=905255#c6 This is going to be my first contribution to Fedora, so I need a sponsor for my contribution. I would really appreciate if someone could review my work and sponsor me. Welcome to Fedora. If you are taking over from someone else, please file a new review request and close the existing one as duplicate. Rahul -- 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: Self Introduction
Hi On Tue, Apr 9, 2013 at 12:59 PM, Ravindra Kumar ravindraku...@vmware.comwrote: Thanks Rahul. Given that Simone has already accepted existing bug for review, I will create a new bug if he is ok with that. Does that sound ok? Sure. That was just FYI since some of the report generating scripts assumes that the person who opened the review request is the package maintainer last I checked. Rahul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] L10N Desktop testing day for Fedora 19 - 13/04/11
Hello everyone, We are glad to announce that the L10N Test day for Fedora 19 is scheduled for 11th April (Thursday) [1]. Translators all around the world are kindly invited to test their languages and file bugs if necessary, thus contributing to make the Fedora desktop one of the best desktops in your languages. Details for testing is available at [1]. Test cases are available at [2]. As you can see, the test cases are categorized as Frequently Used Applications (FUA) and non FUAs to simplify the testing process and reduce the load on the wiki. Few new gnome packages have been added to the list for this testing. Please feel free to file bugs against the relevant package if you find any issue in your language. Thank you all in advance for your corporation. Feel free to ask any doubts if any. Thanking you Best regards FLTG [1] - https://fedoraproject.org/wiki/Test_Day:2013-04-11_Translation_%28l10n%29 [2] - https://fedoraproject.org/wiki/Test_Day:2013-04-11_Translation_%28l10n%29#Test_Matrix ___ 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: [Test-Announce] Fedora 19 Alpha Release Candidate 1 (RC1) Available Now!
2013/4/9 Andre Robatino robat...@fedoraproject.org *IMPORTANT*: Same images as with 19 Alpha TC3, TC4, and TC5 are over their size targets (all DVDs and Lives with the exception of Live KDE and Live SoaS). As per the Fedora 19 schedule [1], Fedora 19 Alpha Release Candidate 1 (RC1) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/5545#comment:15 . Please see the following pages for download links (including delta ISOs) and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace dl with download-ib01 in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Ideally, all Alpha priority test cases for Installation [2], Base [3], and Desktop [4] should pass in order to meet the Alpha Release Criteria [5]. Help is available on #fedora-qa on irc.freenode.net [6], or on the test list [7]. Create Fedora 19 Alpha test composes (TC) and release candidates (RC) https://fedorahosted.org/rel-eng/ticket/5545 Current Blocker and NTH bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-19/f-19-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Base_validation_testing [4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [5] https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria [6] irc://irc.freenode.net/fedora-qa [7] https://admin.fedoraproject.org/mailman/listinfo/test ___ 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 I tried the live image on two computers and could not get into GDM. Is this a known bug or should I report it? /Andreas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
Once upon a time, Bill Nottingham nott...@redhat.com said: So, needless to say, I'd suggest anyone interested in this to look at option #3. Note that enabling something like that on rawhide would have a large effect on the repository creation time - there's only so many ways to speed up scanning across 5 packages 100GB on a SAN. It would also have a significant impact on the mirror servers' disk space (speaking for a mirror that is running low on disk and no $$ to upgrade). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 19 Alpha Release Candidate 1 (RC1) Available Now!
On 09/04/13 10:41 AM, Andreas Tunek wrote: I tried the live image on two computers and could not get into GDM. Is this a known bug or should I report it? It's hard to tell with no more details than that, but there are no known general showstopper bugs in the GDM/GNOME path of RC1, no. there's known to be a showstopper for KDE: https://bugzilla.redhat.com/show_bug.cgi?id=949831 (a snafu in the build process). -- 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
Re: Keeping old versions of packages
On Tuesday 09 April 2013 16:02:14 Richard Hughes wrote: now for F18 are really not important at all. Spec file fixups, new versions without bugfixes, updated artwork; that can all wait until a certain point in the month. Security-critical updates are already tagged as such, aren't they? So users are already able to defer installing non-critical updates to a point in time where it's convenient for them. There's even a yum plugin for that. Maybe the existing tools could be enhanced but changing stuff on the repo side? I'm not so sure... Lars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Autoconf in rawhide broken?
I was trying to do a test build for aarch64 by adding autoreconf to the spec file. I was getting an error that it doesn't exist. When I tried to mock chroot for Rawhide I got the following: # autoreconf Can't locate Carp.pm in @INC (@INC contains: /usr/share/autoconf /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /usr/share/autoconf/Autom4te/Channels.pm line 72. BEGIN failed--compilation aborted at /usr/share/autoconf/Autom4te/Channels.pm line 72. Compilation failed in require at /usr/share/autoconf/Autom4te/ChannelDefs.pm line 19. BEGIN failed--compilation aborted at /usr/share/autoconf/Autom4te/ChannelDefs.pm line 19. Compilation failed in require at /usr/bin/autoreconf line 39. BEGIN failed--compilation aborted at /usr/bin/autoreconf line 39. Doing the same in a F18 mock chroot works as expected. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Devel-GlobalDestruction-XS] Created tag perl-Devel-GlobalDestruction-XS-0.01-3.el5
The lightweight tag 'perl-Devel-GlobalDestruction-XS-0.01-3.el5' was created pointing to: 84d6cc4... Drop redundant explicit dependency on perl(XSLoader) (#9284 -- 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-Devel-GlobalDestruction-XS] Created tag perl-Devel-GlobalDestruction-XS-0.01-3.el6
The lightweight tag 'perl-Devel-GlobalDestruction-XS-0.01-3.el6' was created pointing to: 84d6cc4... Drop redundant explicit dependency on perl(XSLoader) (#9284 -- 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-Devel-GlobalDestruction-XS] Created tag perl-Devel-GlobalDestruction-XS-0.01-3.fc17
The lightweight tag 'perl-Devel-GlobalDestruction-XS-0.01-3.fc17' was created pointing to: 84d6cc4... Drop redundant explicit dependency on perl(XSLoader) (#9284 -- 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-Devel-GlobalDestruction-XS] Created tag perl-Devel-GlobalDestruction-XS-0.01-3.fc19
The lightweight tag 'perl-Devel-GlobalDestruction-XS-0.01-3.fc19' was created pointing to: 84d6cc4... Drop redundant explicit dependency on perl(XSLoader) (#9284 -- 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-Devel-GlobalDestruction-XS] Created tag perl-Devel-GlobalDestruction-XS-0.01-3.fc18
The lightweight tag 'perl-Devel-GlobalDestruction-XS-0.01-3.fc18' was created pointing to: 84d6cc4... Drop redundant explicit dependency on perl(XSLoader) (#9284 -- 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-Devel-GlobalDestruction-XS] Created tag perl-Devel-GlobalDestruction-XS-0.01-3.fc20
The lightweight tag 'perl-Devel-GlobalDestruction-XS-0.01-3.fc20' was created pointing to: 84d6cc4... Drop redundant explicit dependency on perl(XSLoader) (#9284 -- 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: Autoconf in rawhide broken?
On Tue, 9 Apr 2013 14:39:56 -0500, Richard Shaw wrote: I was trying to do a test build for aarch64 by adding autoreconf to the spec file. I was getting an error that it doesn't exist. The error output tells you something different: When I tried to mock chroot for Rawhide I got the following: # autoreconf Can't locate Carp.pm in @INC (@INC contains: /usr/share/autoconf /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /usr/share/autoconf/Autom4te/Channels.pm line 72. BEGIN failed--compilation aborted at /usr/share/autoconf/Autom4te/Channels.pm line 72. Compilation failed in require at /usr/share/autoconf/Autom4te/ChannelDefs.pm line 19. BEGIN failed--compilation aborted at /usr/share/autoconf/Autom4te/ChannelDefs.pm line 19. Compilation failed in require at /usr/bin/autoreconf line 39. BEGIN failed--compilation aborted at /usr/bin/autoreconf line 39. Doing the same in a F18 mock chroot works as expected. It could not find the Perl Carp module. Which version of the autoconf package is this with? $ rpm -qR autoconf|grep -i carp perl(Carp) $ rpm -q autoconf autoconf-2.69-10.fc19.noarch -- Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.0-0.rc5.git1.301.fc19.x86_64 loadavg: 0.39 0.38 0.36 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Autoconf in rawhide broken?
On Ter, 2013-04-09 at 22:09 +0200, Michael Schwendt wrote: On Tue, 9 Apr 2013 14:39:56 -0500, Richard Shaw wrote: I was trying to do a test build for aarch64 by adding autoreconf to the spec file. I was getting an error that it doesn't exist. The error output tells you something different: When I tried to mock chroot for Rawhide I got the following: # autoreconf Can't locate Carp.pm in @INC (@INC contains: /usr/share/autoconf /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /usr/share/autoconf/Autom4te/Channels.pm line 72. BEGIN failed--compilation aborted at /usr/share/autoconf/Autom4te/Channels.pm line 72. Compilation failed in require at /usr/share/autoconf/Autom4te/ChannelDefs.pm line 19. BEGIN failed--compilation aborted at /usr/share/autoconf/Autom4te/ChannelDefs.pm line 19. Compilation failed in require at /usr/bin/autoreconf line 39. BEGIN failed--compilation aborted at /usr/bin/autoreconf line 39. Doing the same in a F18 mock chroot works as expected. Hi, sorry don't read all thread , but I had same problem this weekend , I think add gettext on BuildRequires, fixes the issue . BuildRequires: libtool gettext or BuildRequires: automake autoconf BuildRequires: gettext It could not find the Perl Carp module. Which version of the autoconf package is this with? $ rpm -qR autoconf|grep -i carp perl(Carp) $ rpm -q autoconf autoconf-2.69-10.fc19.noarch -- Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.0-0.rc5.git1.301.fc19.x86_64 loadavg: 0.39 0.38 0.36 -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Autoconf in rawhide broken?
On 04/09/2013 01:39 PM, Richard Shaw wrote: I was trying to do a test build for aarch64 by adding autoreconf to the spec file. I was getting an error that it doesn't exist. When I tried to mock chroot for Rawhide I got the following: # autoreconf Can't locate Carp.pm in @INC (@INC contains: /usr/share/autoconf /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /usr/share/autoconf/Autom4te/Channels.pm line 72. BEGIN failed--compilation aborted at /usr/share/autoconf/Autom4te/Channels.pm line 72. Compilation failed in require at /usr/share/autoconf/Autom4te/ChannelDefs.pm line 19. BEGIN failed--compilation aborted at /usr/share/autoconf/Autom4te/ChannelDefs.pm line 19. Compilation failed in require at /usr/bin/autoreconf line 39. BEGIN failed--compilation aborted at /usr/bin/autoreconf line 39. perl Carp was broken for a while - https://bugzilla.redhat.com/show_bug.cgi?id=924938 You might need to go backwards (distro-sync) -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Autoconf in rawhide broken?
On Tue, Apr 9, 2013 at 4:57 PM, Orion Poplawski or...@cora.nwra.com wrote: perl Carp was broken for a while - https://bugzilla.redhat.com/** show_bug.cgi?id=924938https://bugzilla.redhat.com/show_bug.cgi?id=924938 You might need to go backwards (distro-sync) Don't really help me for koji though... :) Or a mock build either... Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Autoconf in rawhide broken?
On Tue, 9 Apr 2013 17:37:32 -0500 Richard Shaw hobbes1...@gmail.com wrote: On Tue, Apr 9, 2013 at 4:57 PM, Orion Poplawski or...@cora.nwra.com wrote: perl Carp was broken for a while - https://bugzilla.redhat.com/** show_bug.cgi?id=924938https://bugzilla.redhat.com/show_bug.cgi?id=924938 You might need to go backwards (distro-sync) Don't really help me for koji though... :) Or a mock build either... That perl issue was fixed a while back. There's not enough info here for me to help you. Can you provide a link to a build you did that failed in this way? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 19 Alpha Release Candidate 2 (RC2) Available Now!
*IMPORTANT*: Same images as with 19 Alpha TC3 through RC1 are over their size targets (all DVDs and Lives with the exception of Live KDE and Live SoaS). As per the Fedora 19 schedule [1], Fedora 19 Alpha Release Candidate 2 (RC2) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/5545#comment:18 . Please see the following pages for download links (including delta ISOs) and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace dl with download-ib01 in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Ideally, all Alpha priority test cases for Installation [2], Base [3], and Desktop [4] should pass in order to meet the Alpha Release Criteria [5]. Help is available on #fedora-qa on irc.freenode.net [6], or on the test list [7]. Create Fedora 19 Alpha test composes (TC) and release candidates (RC) https://fedorahosted.org/rel-eng/ticket/5545 Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-19/f-19-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Base_validation_testing [4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [5] https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria [6] irc://irc.freenode.net/fedora-qa [7] https://admin.fedoraproject.org/mailman/listinfo/test signature.asc Description: OpenPGP digital 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
Broken dependencies: perl-Bio-SamTools
perl-Bio-SamTools has broken dependencies in the rawhide tree: On x86_64: perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) On i386: perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Math-Clipper
perl-Math-Clipper has broken dependencies in the rawhide tree: On x86_64: perl-Math-Clipper-1.17-3.fc19.x86_64 requires libpolyclipping.so.5()(64bit) On i386: perl-Math-Clipper-1.17-3.fc19.i686 requires libpolyclipping.so.5 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Bio-ASN1-EntrezGene
perl-Bio-ASN1-EntrezGene has broken dependencies in the rawhide tree: On x86_64: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) On i386: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Bio-SamTools
perl-Bio-SamTools has broken dependencies in the F-19 tree: On x86_64: perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) On i386: perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Bio-ASN1-EntrezGene
perl-Bio-ASN1-EntrezGene has broken dependencies in the F-19 tree: On x86_64: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) On i386: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Math-Clipper
perl-Math-Clipper has broken dependencies in the F-19 tree: On x86_64: perl-Math-Clipper-1.17-3.fc19.x86_64 requires libpolyclipping.so.5()(64bit) On i386: perl-Math-Clipper-1.17-3.fc19.i686 requires libpolyclipping.so.5 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 950017] New: Unable to use LOG_EMERG level in Sys::Syslog
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=950017 Bug ID: 950017 Summary: Unable to use LOG_EMERG level in Sys::Syslog Product: Fedora Version: 18 Component: perl Keywords: Regression Severity: medium Priority: medium Assignee: mmasl...@redhat.com Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: cw...@alumni.drew.edu, iarn...@gmail.com, jples...@redhat.com, ka...@ucw.cz, lkund...@v3.sk, lzac...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com, rc040...@freenet.de, tcall...@redhat.com External Bug ID: CPAN 82368 Category: --- +++ This bug was initially created as a clone of Bug #949927 +++ Description of problem: Level LOG_EMERG seems to be not recognized as valid level for syslog calls. Other levels LOG_ALERT LOG_CRIT LOG_ERR LOG_WARNING LOG_NOTICE LOG_INFO were accepted and produced messages. LOG_DEBUG was accepted as valid level too. Version-Release number of selected component (if applicable): perl-5.16.2-[...] Steps to Reproduce: 1. perl -e 'use Sys::Syslog; syslog(LOG_EMERG, emergency)' Actual results: syslog: level must be given at -e line 1. Expected results: emergency message written [...] --- Additional comment from RHEL Product and Program Management on 2013-04-09 10:02:47 GMT --- This bugzilla has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being [proposed|marked] as a blocker for this release. Please resolve ASAP. --- Additional comment from Petr Pisar on 2013-04-09 13:08:53 GMT --- Thanks for the report. It has been fixed in Sys-Syslog-0.31 http://cpansearch.perl.org/src/SAPER/Sys-Syslog-0.31/Changes which has not yet been merged into stable perl release. I will sub-package Sys-Syslog from perl and package latest release from CPAN which contains the fix. All perl 5.16 releases are affected, F≥18 are affected. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=aqf38LJhX6a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Devel-GlobalDestruction-XS/f18] (2 commits) ...Drop redundant explicit dependency on perl(XSLoader) (#928418)
Summary of changes: 778fb47... Initial import (perl-Devel-GlobalDestruction-XS-0.01-2) (*) 84d6cc4... Drop redundant explicit dependency on perl(XSLoader) (#9284 (*) (*) 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Devel-GlobalDestruction-XS/f17] (2 commits) ...Drop redundant explicit dependency on perl(XSLoader) (#928418)
Summary of changes: 778fb47... Initial import (perl-Devel-GlobalDestruction-XS-0.01-2) (*) 84d6cc4... Drop redundant explicit dependency on perl(XSLoader) (#9284 (*) (*) 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Devel-GlobalDestruction-XS/el6] (2 commits) ...Drop redundant explicit dependency on perl(XSLoader) (#928418)
Summary of changes: 778fb47... Initial import (perl-Devel-GlobalDestruction-XS-0.01-2) (*) 84d6cc4... Drop redundant explicit dependency on perl(XSLoader) (#9284 (*) (*) 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Devel-GlobalDestruction-XS/el5] (2 commits) ...Drop redundant explicit dependency on perl(XSLoader) (#928418)
Summary of changes: 778fb47... Initial import (perl-Devel-GlobalDestruction-XS-0.01-2) (*) 84d6cc4... Drop redundant explicit dependency on perl(XSLoader) (#9284 (*) (*) 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 927999] Not compatible with current Bugzilla
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=927999 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA Last Closed||2013-04-09 21:34:35 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=rYc4zApR7za=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 927999] Not compatible with current Bugzilla
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=927999 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-BZ-Client-1.04-5.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=ExFyfwSC0Ia=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 927999] Not compatible with current Bugzilla
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=927999 --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- perl-BZ-Client-1.04-3.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=ndeW6VDiGta=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[389-devel] please review: Ticket 47315 - filter option in fixup-memberof requires more clarification
https://fedorahosted.org/389/ticket/47315 https://fedorahosted.org/389/attachment/ticket/47315/0001-Ticket-47315-filter-option-in-fixup-memberof-require.patch -- Mark Reynolds Red Hat, Inc mreyno...@redhat.com -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please review: Ticket #47320 - put conn on work_q not poll list if conn has buffered more_data
https://fedorahosted.org/389/attachment/ticket/47320/0004-Ticket-47320-put-conn-on-work_q-not-poll-list-if-con.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please review: [389 Project] #608: Posix Winsync plugin throws posix_winsync_end_update_cb: failed to add task entry error message
https://fedorahosted.org/389/ticket/608 https://fedorahosted.org/389/attachment/ticket/608/0001-Ticket-608-Posix-Winsync-plugin-throws-posix_winsync.patch Bug description: When a task posixWinsyncCreateMemberOfTask is already running, another same task request is received, the Posix Winsync Plug-in issues an error posix-winsync - posix_ winsync_end_update_cb: failed to add task entry. This is not an error but an expected behaviour. Fix description: Instead of filing the message as SLAPI_LOG_ FATAL, this patch logs clearer message task entry taskname already exists if the log level is SLAPI_LOG_PLUGIN. posix_winsync_end_update_cb -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
