Re: F15 Feature - convert as many service init files as possible to the native SystemD services
Hi, What services are installed by default when installong form Live GNOME/KDE/etc and DVD? -- Best regards, Michal Sent from my iToaster -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Help to solve a possible circular Requires:
Hi all, I am seeking some help here to solve a possible $subject. I have been trying to find a simple alternate solution, but I just can´t see it or it´s not obvious to me. This is the situation: srpm foo 1.0 ships 2 rpm´s bar and baz. bar has a daemon inside. due to upstream split: srpm foo 1.1 now ships only bar rpm without the daemon. srpm baz 1.1 now ships 2 rpm´s, baz (exactly as in version 1.0) and baz-something that contains the bar´s daemon from 1.0. In order to avoid upgrade issues, we need to make sure that bar 1.1 will pull in baz-something 1.1 (to retain functionality), at the same time baz-something requires bar 1.1 to operate at all. There is no requirement for a strictly versioned Requires: on both sides. baz-something Requires: bar = 1.1, and bar Requires: baz-something (no version need since it´s a new rpm). From local testing, the circular Requires works just fine, both in upgrades and clean install (tested with yum and manual rpm), but I don´t like it. Is there a better way to achieve this upgrade path? Thanks Fabio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive maintainer for libical
I know I'm not following the NonResponsiveMaintainer policy closely, but I believe, in this particular case, it would be with no gain. I'm fine to take ownership of the libical package and do releases for it. I am orphaning it in PackageDB. Please take up ownership. Thanks, Debarshi -- The camera is to the brush what Java is to assembly. -- Sougata Santra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
issues with duplicate entries in /etc/mtab
Hello! As you can see with a current rawhide install you might end up with filesystems that have multible entries in mtab: http://fpaste.org/Z7Ne/ df also outputs the filesystems redundantly. If the system is to be changed and mtab is going to be removed all the tools writing to and reading from it have to be looked at as well i guess. I am not sure if the right people are already aware of the issue. kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
meego session (fedora netbook) broken in rawhide
After installing the complete stack yesterday and trying to login i figured that it doesent work in the current state. Havent deeply analyzed it but the first errors in the logs are related to consolekit [00.67] [11545] user rkastl, tty #2, session /usr/bin/mutter --sm-disable [00.014231] [11545] Error: Unable to open session with ConsoleKit: org.freedesktop.CkConnector.Error: Unable to open session: Rejected send message, 3 matched rules; type=method_call, sender=:1.285 (uid=501 pid=11545 comm=/usr/sbin/uxlaunch) interface=org.freedesktop.ConsoleKit.Manager member=OpenSessionWithParameters error name=(unset) requested_reply=0 destination=org.freedesktop.ConsoleKit (uid=0 pid=1857 comm=/usr/sbin/console-kit-daemon)) [00.014231] [11545] Error: Unable to open session with ConsoleKit: org.freedesktop.CkConnector.Error: Unable to open session: Rejected send message, 3 matched rules; type=method_call, sender=:1.285 (uid=501 pid=11545 comm=/usr/sbin/uxlaunch) interface=org.freedesktop.ConsoleKit.Manager member=OpenSessionWithParameters error name=(unset) requested_reply=0 destination=org.freedesktop.ConsoleKit (uid=0 pid=1857 comm=/usr/sbin/console-kit-daemon)) not sure if it is already reported or worth reporting with the current rawhide state (or any changes already pending fixing it) kind regards, Rudolf Kastl p.s. i hope that at some point mutter-mbl is either obsolete because the changes are finally upstream or atleast properly packaged so it is parallel installable. this issue is present since ages now and in fedora 15 it will lead to conflicts with the gnome-shell setup. both sessions wont be parallel installable. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20101203 changes
Compose started at Fri Dec 3 08:15:13 UTC 2010 Broken deps for x86_64 -- beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0(VER_1)(64bit) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 dh-make-0.55-2.fc15.noarch requires debhelper eog-plugins-2.30.0-2.fc14.x86_64 requires libgdata.so.7()(64bit) gedit-vala-0.10.2-2.fc15.i686 requires libvala-0.10.so.0 gedit-vala-0.10.2-2.fc15.x86_64 requires libvala-0.10.so.0()(64bit) 1:gnome-bluetooth-moblin-2.91.2-1.fc15.x86_64 requires libmoblin-panel.so.0()(64bit) 1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gnome-gmail-notifier-0.10.1-1.fc14.x86_64 requires libnotify.so.1()(64bit) gnome-pilot-eds-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevdocument.so.3()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevview.so.3()(64bit) gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-totem-2.32.0-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(Mono.Data.SqliteClient) = 0:2.0.0.0 gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-gtk-0.6.so.0()(64bit) gshutdown-0.2-6.fc12.x86_64 requires libnotify.so.1()(64bit) gsql-0.2.1-4.fc12.i686 requires libnotify.so.1 gsql-0.2.1-4.fc12.x86_64 requires libnotify.so.1()(64bit) gyachi-plugin-libnotify-1.2.10-3.fc14.x86_64 requires libnotify.so.1()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libnotify.so.1()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) ibus-fbterm-0.9.1-10.fc15.x86_64 requires libibus.so.2()(64bit) ibus-input-pad-0.1.3-3.fc15.x86_64 requires libinput-pad.so.0()(64bit) intellij-idea-9.0.1.94.399-12.fc15.x86_64 requires commons-collections ircp-tray-0.7.4-1.fc14.x86_64 requires libnotify.so.1()(64bit) java-gnome-4.0.16-3.fc14.x86_64 requires libnotify.so.1()(64bit) libnotifymm-0.6.1-8.fc14.i686 requires libnotify.so.1 libnotifymm-0.6.1-8.fc14.x86_64 requires libnotify.so.1()(64bit) log4net-1.2.10-13.fc13.x86_64 requires mono(System) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Data) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(mscorlib) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Xml) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Web) = 0:1.0.5000.0 mars-sim-2.84-6.fc14.noarch requires commons-collections moblin-panel-media-0.0.8-0.2.fc13.x86_64 requires libmoblin-panel.so.0()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libmoblin-panel.so.0()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libsocialweb-client.so.1()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Drawing) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Windows.Forms) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(mscorlib) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Xml) = 0:1.0.5000.0 1:nant-0.85-34.fc13.x86_64 requires mono(ICSharpCode.SharpZipLib) = 0:0.84.0.0 nntpgrab-gui-0.6.90-3.fc15.x86_64 requires libnotify.so.1()(64bit) ocfs2-tools-pcmk-1.4.3-8.fc15.x86_64 requires dlm-pcmk padevchooser-0.9.4-0.11.svn20070925.fc13.x86_64 requires libnotify.so.1()(64bit) pcmanx-gtk2-0.3.9-6.20100618svn.fc14.i686 requires libnotify.so.1 pcmanx-gtk2-0.3.9-6.20100618svn.fc14.x86_64 requires libnotify.so.1()(64bit) pidgin-gfire-0.9.2-2.fc15.x86_64 requires libnotify.so.1()(64bit) qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) spacewalk-backend-tools-1.2.74-2.fc15.noarch requires spacewalk-admin = 0:0.1.1-0 sunbird-1.0-0.33.b2pre.fc15.x86_64 requires libnotify.so.1()(64bit) synce-trayicon-0.15-1.fc14.x86_64 requires libnotify.so.1()(64bit)
Re: meego session (fedora netbook) broken in rawhide
On Fri, Dec 3, 2010 at 11:31 AM, Rudolf Kastl che...@gmail.com wrote: After installing the complete stack yesterday and trying to login i figured that it doesent work in the current state. Havent deeply analyzed it but the first errors in the logs are related to consolekit [00.67] [11545] user rkastl, tty #2, session /usr/bin/mutter --sm-disable [00.014231] [11545] Error: Unable to open session with ConsoleKit: org.freedesktop.CkConnector.Error: Unable to open session: Rejected send message, 3 matched rules; type=method_call, sender=:1.285 (uid=501 pid=11545 comm=/usr/sbin/uxlaunch) interface=org.freedesktop.ConsoleKit.Manager member=OpenSessionWithParameters error name=(unset) requested_reply=0 destination=org.freedesktop.ConsoleKit (uid=0 pid=1857 comm=/usr/sbin/console-kit-daemon)) [00.014231] [11545] Error: Unable to open session with ConsoleKit: org.freedesktop.CkConnector.Error: Unable to open session: Rejected send message, 3 matched rules; type=method_call, sender=:1.285 (uid=501 pid=11545 comm=/usr/sbin/uxlaunch) interface=org.freedesktop.ConsoleKit.Manager member=OpenSessionWithParameters error name=(unset) requested_reply=0 destination=org.freedesktop.ConsoleKit (uid=0 pid=1857 comm=/usr/sbin/console-kit-daemon)) not sure if it is already reported or worth reporting with the current rawhide state (or any changes already pending fixing it) Its already reported. See RHBZ # 642943 , the MeeGo problem in general is being tracked in # 628921 The session is starting and I get some popups (selinux etc) but I get the white screen, the above bug doesn't seem to affect it too much, I'm at a bit of a loss where to go from here but the opensuse guys are seeing it as well with meego 1.1 on opensuse 11.4 so we're not alone. I suspect some change in some api or similar but I'm really not sure where to go from here and any help is appreciated. Planning a blog post about it very soon. kind regards, Rudolf Kastl p.s. i hope that at some point mutter-mbl is either obsolete because the changes are finally upstream or atleast properly packaged so it is parallel installable. this issue is present since ages now and in fedora 15 it will lead to conflicts with the gnome-shell setup. both sessions wont be parallel installable. Nope, not fixed as yet, I keep getting told by both parties soon but still no movement. Sort of flies in the face of MeeGo's upstream first policy and I would love to see the problem closed. Cheers, peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A comps group for the Design Suite
On Mon, 2010-10-18 at 11:13 -0400, Bill Nottingham wrote: Right, it would be (for Fedora 15, *not* 14) renaming the graphics grop to the 'design suite' group, and adjusting the package list appropriately. Bill Hi, I'm sorry for going quiet on this. I somehow missed the mail. So, how would we go about this? Should I submit the above mentioned as a feature for F15? Would that be the way to go? I can take over the task too. Thanks, regards, Ankur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 659428] perl-Wx-Perl-ProcessStream-0.29 is available
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=659428 Petr Pisar ppi...@redhat.com changed: What|Removed |Added CC|mmasl...@redhat.com |ppi...@redhat.com AssignedTo|mmasl...@redhat.com |ppi...@redhat.com -- 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: issues with duplicate entries in /etc/mtab
Dne 3.12.2010 11:59, Rudolf Kastl napsal(a): As you can see with a current rawhide install you might end up with filesystems that have multible entries in mtab: http://fpaste.org/Z7Ne/ dmesg|grep mounts would tell you more. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: issues with duplicate entries in /etc/mtab
On Fri, 3 Dec 2010 11:59:25 +0100 Rudolf Kastl wrote: As you can see with a current rawhide install you might end up with filesystems that have multible entries in mtab: http://fpaste.org/Z7Ne/ df also outputs the filesystems redundantly. If the system is to be changed and mtab is going to be removed all the tools writing to and reading from it have to be looked at as well i guess. I am not sure if the right people are already aware of the issue. Lennart wants mtab to be a symlink to /proc/mounts: https://bugzilla.redhat.com/show_bug.cgi?id=655571 Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Wx-Perl-ProcessStream-0.29.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Wx-Perl-ProcessStream: 0aef4f0723677742aa703998ccf12b21 Wx-Perl-ProcessStream-0.29.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: Unresponsive maintainer for libical
On Fri, 2010-12-03 at 12:47 +0200, Debarshi Ray wrote: I know I'm not following the NonResponsiveMaintainer policy closely, but I believe, in this particular case, it would be with no gain. I'm fine to take ownership of the libical package and do releases for it. I am orphaning it in PackageDB. Please take up ownership. Hi, thanks. Could you give me a link to the proper PackageDB page, please? I seem to lose it and I do not have much idea how to find it. (Bad of me, I'm sorry). Thanks and bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: exiv2 soname bump
Rex Dieter wrote: exiv2-0.21 was released recently, and includes a soname bump. I plan on importing this into rawhide next week sometime, if all goes well. Here's a scratch build for testing, http://koji.fedoraproject.org/koji/taskinfo?taskID=2636872 I've done a few test builds of the items below, and the only one that ftbfs is pyexiv2 (a usual suspect, being a low-level binding). one more ftbfs, libgexiv2-0:0.2.0-1.fc15.src , I tried the latest 0.2.1 too, and there seems to be no upstream ticket yet either. Will try to delay until we hear from our own libgexiv2 maintainer(s) or it's upstream. -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: exiv2 soname bump
Rex Dieter wrote: Rex Dieter wrote: exiv2-0.21 was released recently, and includes a soname bump. I plan on importing this into rawhide next week sometime, if all goes well. Here's a scratch build for testing, http://koji.fedoraproject.org/koji/taskinfo?taskID=2636872 I've done a few test builds of the items below, and the only one that ftbfs is pyexiv2 (a usual suspect, being a low-level binding). one more ftbfs, libgexiv2-0:0.2.0-1.fc15.src , I tried the latest 0.2.1 too, and there seems to be no upstream ticket yet either. Will try to delay until we hear from our own libgexiv2 maintainer(s) or it's upstream. filed, http://trac.yorba.org/ticket/2913 -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: issues with duplicate entries in /etc/mtab
On 12/03/2010 07:46 AM, Matej Cepl wrote: dmesg|grep mounts would tell you more. Could you explain in more detail? On my F14 it isn't very informative: dmesg | grep mounts no output dmesg | grep mount EXT3-fs: mounted filesystem with ordered data mode. EXT3-fs: mounted filesystem with ordered data mode. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
gtk3 in rawhide
Hey, I'm sorry that a new gtk3 hit rawhide today without the necessary rebuilds of dependent packages. You might want to hold off on that until we get nautilus, evince, gedit, etc rebuilt. Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive maintainer for libical
MC == Milan Crha mc...@redhat.com writes: MC Could you give me a link to the proper PackageDB MC page, please? Personally I just go to http://bugz.fedoraproject.org/packagname and click the Package Info link. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Help to solve a possible circular Requires:
2010/12/3 Fabio M. Di Nitto fdini...@redhat.com: Hi all, I am seeking some help here to solve a possible $subject. I have been trying to find a simple alternate solution, but I just can´t see it or it´s not obvious to me. This is the situation: srpm foo 1.0 ships 2 rpm´s bar and baz. bar has a daemon inside. due to upstream split: srpm foo 1.1 now ships only bar rpm without the daemon. srpm baz 1.1 now ships 2 rpm´s, baz (exactly as in version 1.0) and baz-something that contains the bar´s daemon from 1.0. In order to avoid upgrade issues, we need to make sure that bar 1.1 will pull in baz-something 1.1 (to retain functionality), at the same time baz-something requires bar 1.1 to operate at all. There is no requirement for a strictly versioned Requires: on both sides. baz-something Requires: bar = 1.1, and bar Requires: baz-something (no version need since it´s a new rpm). From local testing, the circular Requires works just fine, both in upgrades and clean install (tested with yum and manual rpm), but I don´t like it. Is there a better way to achieve this upgrade path? Thanks Fabio -- You might be able to find some related information from http://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitting_packages Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[pkgdb] perl-Email-MIME-Modifier (un)retirement
Package perl-Email-MIME-Modifier in Fedora devel has been retired by spot To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Email-MIME-Modifier -- 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
[pkgdb] perl-Email-MIME-Creator (un)retirement
Package perl-Email-MIME-Creator in Fedora devel has been retired by spot To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Email-MIME-Creator -- 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-Email-MIME-Modifier] dead.package
commit d31e94307ac1154c12d6c81500999627e5130810 Author: Tom spot Callaway tcall...@redhat.com Date: Fri Dec 3 10:41:15 2010 -0500 dead.package dead.package |3 + perl-Email-MIME-Modifier.spec | 114 - sources |1 - 3 files changed, 3 insertions(+), 115 deletions(-) --- diff --git a/dead.package b/dead.package new file mode 100644 index 000..e30faff --- /dev/null +++ b/dead.package @@ -0,0 +1,3 @@ +This package is now provided by perl-Email-MIME 1.906. + +~tom callaway, 2010-12-03 -- 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-Email-MIME-Modifier] dead.package
commit faee9866c8bb956713f0b302e221471301e70591
Author: Tom spot Callaway tcall...@redhat.com
Date: Fri Dec 3 10:42:22 2010 -0500
dead.package
perl-Email-MIME-Modifier.spec | 114 +
1 files changed, 114 insertions(+), 0 deletions(-)
---
diff --git a/perl-Email-MIME-Modifier.spec b/perl-Email-MIME-Modifier.spec
new file mode 100644
index 000..50d509d
--- /dev/null
+++ b/perl-Email-MIME-Modifier.spec
@@ -0,0 +1,114 @@
+Name: perl-Email-MIME-Modifier
+Version:1.444
+Release:4%{?dist}
+Summary:Modify Email::MIME Objects Easily
+
+Group: Development/Libraries
+License:GPL+ or Artistic
+URL:http://search.cpan.org/dist/Email-MIME-Modifier/
+Source0:
http://www.cpan.org/authors/id/R/RJ/RJBS/Email-MIME-Modifier-%{version}.tar.gz
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+
+BuildArch: noarch
+BuildRequires: perl(Email::MessageID) = 1.2
+BuildRequires: perl(Email::MIME) = 1.82
+BuildRequires: perl(Email::MIME::Encodings) = 1.3
+BuildRequires: perl(Email::MIME::ContentType) = 1.011
+BuildRequires: perl(Email::Simple) = 1.92
+BuildRequires: perl(Test::Pod) = 1.14
+BuildRequires: perl(Test::Pod::Coverage) = 1.08
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%description
+Provides a number of useful methods for manipulating MIME messages.
+These method are declared in the Email::MIME namespace, and are used
+with Email::MIME objects.
+
+
+%prep
+%setup -q -n Email-MIME-Modifier-%{version}
+
+# Provides: filter perl(Email::MIME)
+cat __EOF__ %{name}-filterprovides
+#!/bin/sh
+%{__perl_provides} \$* | grep -v 'perl(Email::MIME)'
+__EOF__
+%define __perl_provides
%{_builddir}/Email-MIME-Modifier-%{version}/%{name}-filterprovides
+chmod +x %{__perl_provides}
+
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+
+%install
+rm -rf $RPM_BUILD_ROOT
+make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
+find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2/dev/null ';'
+chmod -R u+w $RPM_BUILD_ROOT/*
+
+
+%check
+make test
+
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+
+%files
+%defattr(-,root,root,-)
+%doc Changes README
+%{perl_vendorlib}/Email
+%{_mandir}/man3/*.3pm*
+
+
+%changelog
+* Sat May 01 2010 Marcela Maslanova mmasl...@redhat.com - 1.444-4
+- Mass rebuild with perl-5.12.0
+
+* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 1.444-3
+- Mass rebuild with perl-5.12.0
+
+* Mon Dec 7 2009 Stepan Kasal ska...@redhat.com - 1.444-2
+- rebuild against perl 5.10.1
+
+* Thu Aug 6 2009 Tom spot Callaway tcall...@redhat.com - 1.444-1
+- update to 1.444
+
+* Sat Jul 25 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.443-3
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
+
+* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.443-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
+
+* Thu Feb 12 2009 Ralf Corsépius corse...@fedoraproject.org - 1.443-1
+- Upstream update.
+- Fix directory ownership.
+- Remove hard-codes /usr/lib/rpm/perl.prov from provides filter.
+
+* Wed Feb 27 2008 Tom spot Callaway tcall...@redhat.com - 1.442-3
+- Rebuild for perl 5.10 (again)
+
+* Mon Jan 28 2008 Tom spot Callaway tcall...@redhat.com - 1.442-2
+- rebuild for new perl
+
+* Wed Nov 28 2007 Tom spot Callaway tcall...@redhat.com - 1.442-1
+- bump to 1.442
+
+* Fri Dec 1 2006 Jose Pedro Oliveira jpo at di.uminho.pt - 1.441-1
+- Update to 1.441.
+
+* Sat Oct 14 2006 Jose Pedro Oliveira jpo at di.uminho.pt - 1.440-1
+- Update to 1.440.
+
+* Fri Jul 14 2006 Jose Pedro Oliveira jpo at di.uminho.pt - 1.43-1
+- Update to 1.43.
+
+* Thu Sep 8 2005 Jose Pedro Oliveira jpo at di.uminho.pt - 1.42-2
+- Filter the Email::MIME provide.
+
+* Thu Sep 08 2005 Jose Pedro Oliveira jpo at di.uminho.pt - 1.42-1
+- First build.
--
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-Email-MIME-Creator] dead.package
commit 4084e7b0bd64688e42032b96f7bd56bf87a2450c Author: Tom spot Callaway tcall...@redhat.com Date: Fri Dec 3 10:43:54 2010 -0500 dead.package dead.package |3 +++ sources |1 - 2 files changed, 3 insertions(+), 1 deletions(-) --- diff --git a/dead.package b/dead.package new file mode 100644 index 000..e30faff --- /dev/null +++ b/dead.package @@ -0,0 +1,3 @@ +This package is now provided by perl-Email-MIME 1.906. + +~tom callaway, 2010-12-03 -- 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
[Bug 659635] Requesting upgrade to 1.905+
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=659635 --- Comment #4 from Tom spot Callaway tcall...@redhat.com 2010-12-03 10:46:16 EST --- Done. -- 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: A comps group for the Design Suite
Ankur Sinha (sanjay.an...@gmail.com) said: Right, it would be (for Fedora 15, *not* 14) renaming the graphics grop to the 'design suite' group, and adjusting the package list appropriately. I'm sorry for going quiet on this. I somehow missed the mail. So, how would we go about this? Should I submit the above mentioned as a feature for F15? Would that be the way to go? I can take over the task too. Sounds great to me. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A comps group for the Design Suite
On Fri, 2010-12-03 at 10:52 -0500, Bill Nottingham wrote: Sounds great to me. Bill Hello, Feature page is here[1] [1] https://fedoraproject.org/wiki/Features/Design_Suite_Group Thanks, regards, Ankur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Help to solve a possible circular Requires:
On Fri, 2010-12-03 at 10:24 +0100, Fabio M. Di Nitto wrote: Hi all, I am seeking some help here to solve a possible $subject. I have been trying to find a simple alternate solution, but I just can´t see it or it´s not obvious to me. This is the situation: srpm foo 1.0 ships 2 rpm´s bar and baz. bar has a daemon inside. due to upstream split: srpm foo 1.1 now ships only bar rpm without the daemon. srpm baz 1.1 now ships 2 rpm´s, baz (exactly as in version 1.0) and baz-something that contains the bar´s daemon from 1.0. In order to avoid upgrade issues, we need to make sure that bar 1.1 will pull in baz-something 1.1 (to retain functionality), at the same time baz-something requires bar 1.1 to operate at all. There is no requirement for a strictly versioned Requires: on both sides. baz-something Requires: bar = 1.1, and bar Requires: baz-something (no version need since it´s a new rpm). The above reads more complicated than I think it is. I assume you have two problems: 1. When moving from foo-1.0 = foo-1.1 and baz-1.1, you have a package split ... this implies using versioned Obsoletes (= 1.0) on bar from baz-something. 2. In baz-something-1.1 you have a normal requires on bar-1.1 ... so just add a versioned (= 1.1) require. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Thought excersize: A different take on replication
Hi We were discussing different setups of replication agreements (multi master) between a large number of hosts and ways to minimize contention during updates with interconnected hosts. For example the same change might arrive on a host from two other hosts via different paths at the same time causing errors in the log because of exponential back off. If you have to many connections you get a replication storm, to little connections and replication takes to long. The problem to us sounds very much like a network problem or maybe the effectiveness of the underlying database to lock the data more effectively. We dreamt up a couple of solutions/ideas and I am writing this email to illicit some more discussions and/or comments. One solution would be to change the underlying database to one that supports improved granular locking (firebird comes to mind ) . Another idea we discussed was based on the following question: What if you could only define the list of master servers and let the master servers figure out the details with regards to doing multi mastering and distributing the data and taking care of broken paths? There is similarities with OSPF... Do you have any thoughts on this? Have you had similar ideas? Are we missing the point? Regards In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses. -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Unresponsive maintainer for libical
On Fri, 2010-12-03 at 14:36 +, Peter Robinson wrote: https://admin.fedoraproject.org/pkgdb/packages/ Then you need to login and search for the package. Hi, thanks both for the link. I see [1] the libical is not orphaned yet, neither in devel, nor in F14, as I only can add myself to the package, but not take ownership as with other orphaned packages. I'm keeping this on the next Monday. :) Thanks and bye, Milan [1] https://admin.fedoraproject.org/pkgdb/acls/name/libical -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [389-devel] Thought excersize: A different take on replication
Hi Gerrard, Since you are already mentioning OSPF, how about grouping the Masterservers into zones and have only one of the hosts taking care of the communication to other zones. Changes could always only be replicated via the communication master. The main problem that arises here is the potential outage of one of those communication masters, this could be solved by either an election process or by an explicit order. I think this would be a good way to go because it is very close to real life scenarios form my point of view, I most likely have a view masters in geographically distributed locations, but not tens of servers in one location ( maybe already counting e.g. different buildings on a campus as locations ) Not sure if that is a way to go, but maybe it helps a little Best Regards, Soeren Malchow CIO Phone: +49 40 806008 120 Mobile: +49 171 5525102 Email: soeren.malc...@mcon.net Web: www.mcon.net MCon Germany GmbH Neuer Pferdemarkt 1 20359 Hamburg Germany Berlin . Hamburg . Karlsruhe . Koeln . Muenchen Traderegister HRB 110600 Local Court Mannheim | VAT-Id. No.: DE235236333 | Tax No.: 35 007 055033 Managing Partner: Dirk Meissner, Guenther Kreuzpaintner, Soeren Malchow Member of MCon Group Austria . China . Czech Republic . France . Germany . Japan . Malaysia . Russia . South Korea . Switzerland . UK . USA This e-mail may contain confidential and/ or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material contained in this e-mail is strictly prohibited. Please consider the environment before printing this e-mail -Original Message- From: 389-devel-boun...@lists.fedoraproject.org [mailto:389-devel-boun...@lists.fedoraproject.org] On Behalf Of Gerrard Geldenhuis Sent: Friday, December 03, 2010 5:25 PM To: '389-de...@lists.fedoraproject.org' Subject: [389-devel] Thought excersize: A different take on replication Hi We were discussing different setups of replication agreements (multi master) between a large number of hosts and ways to minimize contention during updates with interconnected hosts. For example the same change might arrive on a host from two other hosts via different paths at the same time causing errors in the log because of exponential back off. If you have to many connections you get a replication storm, to little connections and replication takes to long. The problem to us sounds very much like a network problem or maybe the effectiveness of the underlying database to lock the data more effectively. We dreamt up a couple of solutions/ideas and I am writing this email to illicit some more discussions and/or comments. One solution would be to change the underlying database to one that supports improved granular locking (firebird comes to mind ) . Another idea we discussed was based on the following question: What if you could only define the list of master servers and let the master servers figure out the details with regards to doing multi mastering and distributing the data and taking care of broken paths? There is similarities with OSPF... Do you have any thoughts on this? Have you had similar ideas? Are we missing the point? Regards In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses. -- 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
Re: [389-devel] Thought excersize: A different take on replication
-Original Message- From: 389-devel-boun...@lists.fedoraproject.org [mailto:389-devel- boun...@lists.fedoraproject.org] On Behalf Of Soeren Malchow (MCon) Sent: 03 December 2010 16:42 To: 389 Directory server developer discussion. Subject: Re: [389-devel] Thought excersize: A different take on replication Hi Gerrard, Since you are already mentioning OSPF, how about grouping the Masterservers into zones and have only one of the hosts taking care of the communication to other zones. Changes could always only be replicated via the communication master. The main problem that arises here is the potential outage of one of those communication masters, this could be solved by either an election process or by an explicit order. Thanks for the reply Soeren, would this election process be on a OSPF basis/level? How do you differentiate between the host not available from a network point of view and from a service point of view. My network skills are limited and to be honest; OSPF was mentioned during our discussions but I had to read up on it afterwards and it seemed similar to the solutions we were discussing. I think this would be a good way to go because it is very close to real life scenarios form my point of view, I most likely have a view masters in geographically distributed locations, but not tens of servers in one location ( maybe already counting e.g. different buildings on a campus as locations ) Not sure if that is a way to go, but maybe it helps a little Regards In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses. -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Adding a new comps group (WAS Re: A comps group for the Design Suite)
On Fri, Dec 3, 2010 at 11:13 AM, Ankur Sinha sanjay.an...@gmail.com wrote: On Fri, 2010-12-03 at 10:52 -0500, Bill Nottingham wrote: Sounds great to me. Bill Hello, Feature page is here[1] [1] https://fedoraproject.org/wiki/Features/Design_Suite_Group Thanks, regards, Ankur So what exactly is the process for getting a new group into comps? The wiki[1] indicates that one just needs to consult the devel list for approval. Over on the Robotics SIG list, we are throwing around the idea of adding a Robotics group to comps.xml, in tandem with our stalled Spin effort for F15. With or without a Robotics spin, our own comps group would be beneficial: it keeps all of the important packages in one place and lets the community know that we take robotics very seriously. I think it's in a similar vein as the design suite or the electronics lab, and it's something we can add to our F15 feature page[2]. Rich [1] https://fedoraproject.org/wiki/Comps.xml [2] https://fedoraproject.org/wiki/Features/RoboticsSpin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Go frontend, GCC 4.6, F15
Hello all The Go frontend has been committed to GCC trunk: http://gcc.gnu.org/ml/gcc/2010-12/msg00117.html I checked the wiki, but there doesn't seem to be any mention of GCC 4.6 on the F15 feature list: http://fedoraproject.org/wiki/Releases/15/FeatureList Does anybody have any idea on the plans for GCC 4.6 and F15, and what kind of work would have to be done to get the Go frontend included? Assuming it could happen, I would like to contribute any help I can. Regards Albert -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
koji server down?
Hello. It seems koji is currently down (no hosts seems enabled) http://koji.fedoraproject.org/koji/hosts and many tasks are hanging. Were there any announcement I may have missed or is the current status unexpected? Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Howto: Create a new package and retiring a package
On 11/20/2010 03:17 PM, Richard W.M. Jones wrote: On Sat, Nov 20, 2010 at 02:00:35PM -0500, Steve Dickson wrote: Hello, Currently the nfs-utils-lib package has two libraries, libnfsidmap and librpcsecgss. librpcsecgss is no longer needed since it was functionally replaced by libtirpc and Are you happy about the licensing of libtirpc? I was worried about this commit where the license seems to have been changed unilaterally: http://libtirpc.svn.sourceforge.net/viewvc/libtirpc/trunk/COPYING?view=log There are other forks of TI-RPC. I wrote about some of them here: http://people.redhat.com/~rjones/secure_rpc/ (section 3.13) Yes... Spot got all that worked with both Sun and then Oracle... We are good go... steved. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive maintainer for libical
Dne 3.12.2010 14:21, Milan Crha napsal(a): thanks. Could you give me a link to the proper PackageDB page, please? I seem to lose it and I do not have much idea how to find it. (Bad of me, I'm sorry). This is the URL you want to have in your Firefox bookmarks https://admin.fedoraproject.org/pkgdb/acls/list/*%s* With proper keyword attached it would make you searching for packages a breeze. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [389-devel] Thought excersize: A different take on replication
OSPF was only the example for me, in OSPF the daemon itself has this election logic built in. So either the service is running and can take part in the election or not, this means, the logic needs to be implemented within the ldap daemon. It also implies, that there is some kind of heartbeat between the nodes. -Original Message- From: 389-devel-boun...@lists.fedoraproject.org [mailto:389-devel-boun...@lists.fedoraproject.org] On Behalf Of Gerrard Geldenhuis Sent: Friday, December 03, 2010 5:52 PM To: '389 Directory server developer discussion.' Subject: Re: [389-devel] Thought excersize: A different take on replication -Original Message- From: 389-devel-boun...@lists.fedoraproject.org [mailto:389-devel- boun...@lists.fedoraproject.org] On Behalf Of Soeren Malchow (MCon) Sent: 03 December 2010 16:42 To: 389 Directory server developer discussion. Subject: Re: [389-devel] Thought excersize: A different take on replication Hi Gerrard, Since you are already mentioning OSPF, how about grouping the Masterservers into zones and have only one of the hosts taking care of the communication to other zones. Changes could always only be replicated via the communication master. The main problem that arises here is the potential outage of one of those communication masters, this could be solved by either an election process or by an explicit order. Thanks for the reply Soeren, would this election process be on a OSPF basis/level? How do you differentiate between the host not available from a network point of view and from a service point of view. My network skills are limited and to be honest; OSPF was mentioned during our discussions but I had to read up on it afterwards and it seemed similar to the solutions we were discussing. I think this would be a good way to go because it is very close to real life scenarios form my point of view, I most likely have a view masters in geographically distributed locations, but not tens of servers in one location ( maybe already counting e.g. different buildings on a campus as locations ) Not sure if that is a way to go, but maybe it helps a little Regards In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses. -- 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
Re: mpfr soname bump in rawhide
Adam Williamson wrote: Thanks, Bruno! Reply goes for Ivana too. On the topic of Ivana not being 'superuser' (I guess you meant provenpackager?), does it make sense for anyone who maintains a library that other packages build against to be given provenpackager privileges, or at least automatic co-maintainer status for those other packages? Why not just do away with ACL restrictions entirely, opening all packages to all packagers as in the good old Extras? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: old_testing_critpath notifications
On Fri, 2010-12-03 at 22:09 +0100, Kevin Kofler wrote: Adam Williamson wrote: We're working on this. It won't always be practical, however; in the current case, for example, you need specific hardware to test mdadm. Uh, this is md, not dm, you don't need very special HARDWARE (basically only 2 HDDs, which do not even have to be identical, and you might even get away with only 1 for testing, with absymal performance of course), you do need a special setup though, which means repartitioning, and so isn't practical to test on a production machine which isn't already set up that way. mdadm is also used to support Intel BIOS RAID, so you need an appropriate motherboard to test that path. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mpfr soname bump in rawhide
On Fri, 2010-12-03 at 22:11 +0100, Kevin Kofler wrote: Adam Williamson wrote: Thanks, Bruno! Reply goes for Ivana too. On the topic of Ivana not being 'superuser' (I guess you meant provenpackager?), does it make sense for anyone who maintains a library that other packages build against to be given provenpackager privileges, or at least automatic co-maintainer status for those other packages? Why not just do away with ACL restrictions entirely, opening all packages to all packagers as in the good old Extras? well, I've already asked that question myself, but it doesn't seem to be a flyer. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mpfr soname bump in rawhide
On 12/03/2010 01:45 PM, Adam Williamson wrote: On Fri, 2010-12-03 at 22:11 +0100, Kevin Kofler wrote: Adam Williamson wrote: Thanks, Bruno! Reply goes for Ivana too. On the topic of Ivana not being 'superuser' (I guess you meant provenpackager?), does it make sense for anyone who maintains a library that other packages build against to be given provenpackager privileges, or at least automatic co-maintainer status for those other packages? Why not just do away with ACL restrictions entirely, opening all packages to all packagers as in the good old Extras? well, I've already asked that question myself, but it doesn't seem to be a flyer. :) Largely because sponsors don't want to feel responsible for sponsoring somebody to have access to the entire package set in the distribution. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: issues with duplicate entries in /etc/mtab
Dne 3.12.2010 14:55, Przemek Klosowski napsal(a): Could you explain in more detail? On my F14 it isn't very informative: dmesg | grep mounts no output No, it isn't ... in relation to systemd in F15, it is necessary currently to have /etc/mtab just as a symlink to /proc/self/mounts. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gtk3 in rawhide
Dne 3.12.2010 15:02, Matthias Clasen napsal(a): I'm sorry that a new gtk3 hit rawhide today without the necessary rebuilds of dependent packages. You might want to hold off on that until we get nautilus, evince, gedit, etc rebuilt. evince, eog, control-center, and rhythmbox are not problem ... they have been broken in Rawhide for the last couple of weeks anyway ;) Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gtk3 in rawhide
On Fri, 2010-12-03 at 23:07 +0100, Matej Cepl wrote: Dne 3.12.2010 15:02, Matthias Clasen napsal(a): I'm sorry that a new gtk3 hit rawhide today without the necessary rebuilds of dependent packages. You might want to hold off on that until we get nautilus, evince, gedit, etc rebuilt. evince, eog, control-center, and rhythmbox are not problem ... they have been broken in Rawhide for the last couple of weeks anyway ;) I don't have any problem with eog, control-center, or Zarafa. Only Rhythmbox is broken (because it doesn't have a completed, buildable GTK+ 3 port yet). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gtk3 in rawhide
On Fri, 2010-12-03 at 14:19 -0800, Adam Williamson wrote: On Fri, 2010-12-03 at 23:07 +0100, Matej Cepl wrote: Dne 3.12.2010 15:02, Matthias Clasen napsal(a): I'm sorry that a new gtk3 hit rawhide today without the necessary rebuilds of dependent packages. You might want to hold off on that until we get nautilus, evince, gedit, etc rebuilt. evince, eog, control-center, and rhythmbox are not problem ... they have been broken in Rawhide for the last couple of weeks anyway ;) I don't have any problem with eog, control-center, or Zarafa. Only sigh. typo. I meant Evince not Zarafa. If you're wondering how I can possibly screw that up, I tested Evince by loading the Zarafa user manual. =) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Request for comment: Potential change to dist-git branch structure
I'm working on fixing a few long standing bugs in fedpkg that have to do with our branch structure (https://bugzilla.redhat.com/show_bug.cgi?id=619979 and https://bugzilla.redhat.com/show_bug.cgi?id=622592). This has me examining our branch structure again and trying to remember why exactly I chose it (obviously I did a poor job of documenting that...). The original thought was to have top level branches that are named after distribution releases, eg f14, f15, el5. Then we would force branches of those branches use a naming structure of f14/topic. The reason was so that our tooling could look at the name of the branch and easily work back to the f14 part. This would work even if it was f14/user/fred/topic/mybranch or other such craziness. When I went to test this, I realized that git won't allow you to have both f14 and f14/topic as branches, because of the way the git metadata works on the filesystem. When I encountered this, I made f14/master become the top level branch, and then f14/somethingelse could coexist. Unfortunately I also wanted to keep things easy for users and tried to maintain tooling that would allow you to just say f14. This didn't get enough real world testing and in hindsight was a bad idea. Things go wrong quickly in git if your local branch name doesn't match the remote branch name. When thinking about the above, and the two bugs I'm working on, I realized that we don't have any real strong need to be using / as a delineator. It makes some code easier, but makes other things more complex and difficult. So what if we changed it? What I'm thinking about now is switching from / to - as a delineator. This would improve a couple things. First, we could achieve upstream top level branch names that are short and simple: f14, f15, master. We can have branches that build upon those names: f14-rebase, f15-cve223, f15-user-jkeating-private. We could keep the simple fedpkg tooling that allows users to just type f14 and the like to reference a branch, and now the local branch will match the name of the remote branch. As for the first two bugs I mentioned, it doesn't directly help them. However I would feel better about telling people that their local branches must follow a naming scheme of release-something and then we could easily guess what release the local branch is for if it isn't tracking a remote branch. However the bug about what to do if there are no remote branches is really not touched by any of this, it just got me thinking about branches :) What kind of user impact would this have? My hope is that the impact would be minimal. Git allows branch renames, and can successfully rename f14/master to f14. All the history is renamed. We should be able to do this without an outage of the git server. The ACL system will need a slight tweaking, and a regeneration of the ACLs but that is fairly quick and minor to accomplish. However there will be some issues client side. We will not be able to make use of git's symbolic-ref feature of aliasing a branch. We cannot make f14/master an alias for f14, again because of the filesystem layout issues. These issues rear their head once again when a client does a pull of an already checked out repo that had branches. Because there was already a f14/master, when the client sees a new branch just named f14 it will fail to create it. Git has a command that will fix this git remote prune origin. That will remove the local reference to f14/master and a subsequent pull sees the creation of the f14 branch happen successfully. However, if a user had a local branch of f14 or f14/master they will be left with mismatched .git/config entries. In this case it's easiest to delete the local branch (git branch -d f14) and check it out again. If there are changes on the branch one can fix the config to point it to the right upstream location. Also we would need to get a new fedpkg into the hands of all the developers that handles the new branchnames. We could do a build that handles both the oldnames and the new and have it out and available for a reasonable period of time before we make the switch. So, some pain, for some pretty good gain. This time around I can setup pkgs.stg with this branch configuration and builds of fedpkg to use it for a more through testing before rolling it into production. So please, tell me what you think! -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Critical path test case creation process
Hi, everyone. Further to the recent discussions on both lists about the benefits of providing specific test cases for critical path testing, I have opened a trac ticket to track this process: https://fedorahosted.org/fedora-qa/ticket/154 over the next few days I'll be filing tickets for the components that have so far been identified as obvious candidates for such test cases (off the top of my head, so far, we have PackageKit, the kernel, openldap and a few others). We can then start creating test cases. I'm hoping to work with Luke and Till to integrate this process with bodhi and fedora-easy-karma, so they can provide interfaces to the test cases and make it easy to provide test case-specific feedback to Bodhi. This will work best when Bodhi has non-numeric karma, but we could bodge something up via fedora-easy-karma before that, using stock comment texts. Contributions from anyone are greatly welcomed! Thanks. Anyone can help create test cases; it's really pretty simple (it just involves creating a new Wiki page with a name in the correct format - I'll figure out a naming scheme for these test cases soon - based on the test case template, and filling in the steps into the template; it only takes a few minutes to create a simple test case). Maintainers of critical path packages can certainly help by letting me know, on list or in a trac ticket or by carrier pigeon or any other way :), broadly anything that needs to be done to properly test their packages, particularly critical path packages. Thanks again. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
On Fri, 3 Dec 2010 09:14:26 +0100 Michał Piotrowski mkkp...@gmail.com wrote: Hi, What services are installed by default when installong form Live GNOME/KDE/etc and DVD? Varies? :) I don't know that anyone has a list... it should be pretty easy to do some installs and run 'chkconfig --list | grep 5:on'. Or did you mean for f15? It's a bit early to tell, especially with systemd changes. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: koji server down?
On Sat, 04 Dec 2010 03:54:16 +0900 Mamoru Tasaka mtas...@ioa.s.u-tokyo.ac.jp wrote: Hello. It seems koji is currently down (no hosts seems enabled) http://koji.fedoraproject.org/koji/hosts and many tasks are hanging. Were there any announcement I may have missed or is the current status unexpected? Sorry about that. The builders were going to be updated to rhel6 final, and all of them got taken out instead of a small group at a time. ;( We added some back in shortly after that. Sorry for the trouble. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mpfr soname bump in rawhide
On 12/03/2010 10:11 PM, Kevin Kofler wrote: Adam Williamson wrote: Thanks, Bruno! Reply goes for Ivana too. On the topic of Ivana not being 'superuser' (I guess you meant provenpackager?), does it make sense for anyone who maintains a library that other packages build against to be given provenpackager privileges, or at least automatic co-maintainer status for those other packages? Why not just do away with ACL restrictions entirely, To prevent overzealous maintainers, who believe to understand what they are doing but actually don't, from doing harm to packages. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Request for comment: Potential change to dist-git branch structure
On 12/3/2010 18:34, Jesse Keating wrote: The original thought was to have top level branches that are named after distribution releases, eg f14, f15, el5. Then we would force branches of those branches use a naming structure of f14/topic. The reason was so that our tooling could look at the name of the branch and easily work back to the f14 part. This would work even if it was f14/user/fred/topic/mybranch or other such craziness. When I went to test this, I realized that git won't allow you to have both f14 and f14/topic as branches, because of the way the git metadata works on the filesystem. When I encountered this, I made f14/master become the top level branch, and then f14/somethingelse could coexist. Unfortunately I also wanted to keep things easy for users and tried to maintain tooling that would allow you to just say f14. This didn't get enough real world testing and in hindsight was a bad idea. Things go wrong quickly in git if your local branch name doesn't match the remote branch name. When thinking about the above, and the two bugs I'm working on, I realized that we don't have any real strong need to be using / as a delineator. It makes some code easier, but makes other things more complex and difficult. So what if we changed it? What I'm thinking about now is switching from / to - as a delineator. This would improve a couple things. First, we could achieve upstream top level branch names that are short and simple: f14, f15, master. We can have branches that build upon those names: f14-rebase, f15-cve223, f15-user-jkeating-private. We could keep the simple fedpkg tooling that allows users to just type f14 and the like to reference a branch, and now the local branch will match the name of the remote branch. Yes, please! Getting rid of the '/' strangeness ought to make things a little easier to understand and use across the board. I suspect that few enough packages use shared feature or bugfix branches that a transition won't trip up very many people. Perhaps a hook on Fedora's repositories that prints transition instructions when one attempts to push to old-style branches in conjunction with a fedpkg command that attempts to migrate existing local branches and remotes would help somewhat. As for the first two bugs I mentioned, it doesn't directly help them. However I would feel better about telling people that their local branches must follow a naming scheme ofrelease-something and then we could easily guess what release the local branch is for if it isn't tracking a remote branch. However the bug about what to do if there are no remote branches is really not touched by any of this, it just got me thinking about branches :) Why tie branch names down to specific releases? While that scheme makes it easy for fedpkg to guess what release to attempt to build against when one only cares about one release, it makes little sense to call a branch f14-rh123456 when in reality that branch will merge into f13 as well as f14. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
2010/12/4 Kevin Fenzi ke...@scrye.com: On Fri, 3 Dec 2010 09:14:26 +0100 Michał Piotrowski mkkp...@gmail.com wrote: Hi, What services are installed by default when installong form Live GNOME/KDE/etc and DVD? Varies? :) I don't know that anyone has a list... it should be pretty easy to do some installs and run 'chkconfig --list | grep 5:on'. Yes, but unfortunately I have no way to install OS on VM and check - my CPU lacks VMX, and I don't want to reinstall OS. Or did you mean for f15? Yes, actual nightly builds It's a bit early to tell, especially with systemd changes. It seems to me that conversion of all init scripts to native systemd scripts might be impossible for F15 - work is not progressing rapidly enough. Currently I take the trivial targets. The next targets will be services that I use in daily work - web apps related things. Having a list of default services would be useful when choosing the next conversion targets. Would be nice to have all init scripts for commonly used things converted to systemd. kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal Sent from my iToaster -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Date-Manip-6.20.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Date-Manip: 196076af3aa50fee294551e67b42d9e3 Date-Manip-6.20.tar.gz -- 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-Date-Manip] v6.20 release bump
commit 5529f1a3968b6605942262942573953c6fd5154a
Author: Petr Sabata psab...@redhat.com
Date: Fri Dec 3 09:12:17 2010 +0100
v6.20 release bump
.gitignore |1 +
perl-Date-Manip.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 69af1d4..fb109d2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@ Date-Manip-6.07.tar.gz
/Date-Manip-6.12.tar.gz
/Date-Manip-6.13.tar.gz
/Date-Manip-6.14.tar.gz
+/Date-Manip-6.20.tar.gz
diff --git a/perl-Date-Manip.spec b/perl-Date-Manip.spec
index dd106ae..1b7b456 100644
--- a/perl-Date-Manip.spec
+++ b/perl-Date-Manip.spec
@@ -1,5 +1,5 @@
Name: perl-Date-Manip
-Version:6.14
+Version:6.20
Release:1%{?dist}
Summary:A Perl module containing a wide variety of date manipulation
routines
@@ -74,6 +74,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Fri Dec 3 2010 Petr Sabata psab...@redhat.com - 6.20-1
+- 6.20 bump, internal resources might be incompatible with previous versions
+
* Wed Oct 27 2010 Petr Pisar ppi...@redhat.com - 6.14-1
- 6.14 bump
- Remove double-required perl(YAML::Syck)
diff --git a/sources b/sources
index b968fdb..5cf6ed1 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-9119d2ef3612adb819fe9e814dec0e6a Date-Manip-6.14.tar.gz
+196076af3aa50fee294551e67b42d9e3 Date-Manip-6.20.tar.gz
--
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 659427] perl-Date-Manip-6.20 is available
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=659427 Petr Sabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Date-Manip-6.20-1.fc15 Resolution||RAWHIDE Last Closed||2010-12-03 03:21:42 -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Class-XSAccessor-1.10.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Class-XSAccessor: a3508241a42abf398c762c9a7f76e080 Class-XSAccessor-1.10.tar.gz -- 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-Class-XSAccessor] v1.10 release bump
commit 50c031b463a698f86dc6193f52c59e671885aa43
Author: Petr Sabata psab...@redhat.com
Date: Fri Dec 3 09:29:01 2010 +0100
v1.10 release bump
.gitignore |1 +
perl-Class-XSAccessor.spec |5 -
sources|2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 6016843..7b1ea34 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@ Class-XSAccessor-1.05.tar.gz
/Class-XSAccessor-1.07.tar.gz
/Class-XSAccessor-1.08.tar.gz
/Class-XSAccessor-1.09.tar.gz
+/Class-XSAccessor-1.10.tar.gz
diff --git a/perl-Class-XSAccessor.spec b/perl-Class-XSAccessor.spec
index 0bb38e2..c796de7 100644
--- a/perl-Class-XSAccessor.spec
+++ b/perl-Class-XSAccessor.spec
@@ -1,5 +1,5 @@
Name: perl-Class-XSAccessor
-Version:1.09
+Version:1.10
Release:1%{?dist}
Summary:Generate fast XS accessors without run-time compilation
License:GPL+ or Artistic
@@ -57,6 +57,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/Class::*
%changelog
+* Fri Dec 3 2010 Petr Sabata psab...@redhat.com - 1.10-1
+- New upstream release, v1.10
+
* Mon Nov 8 2010 Petr Sabata psab...@redhat.com - 1.09-1
- New upstream release, v1.09
diff --git a/sources b/sources
index 1c19f3a..ffe1567 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a95b4a9c2d1de7949eca5edfe1a65ccb Class-XSAccessor-1.09.tar.gz
+a3508241a42abf398c762c9a7f76e080 Class-XSAccessor-1.10.tar.gz
--
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 659426] perl-Class-XSAccessor-1.10 is available
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=659426 Petr Sabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Class-XSAccessor-1.10- ||1.fc15 Resolution||RAWHIDE Last Closed||2010-12-03 03:36:12 -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 659635] New: Requesting upgrade to 1.905+
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Requesting upgrade to 1.905+ https://bugzilla.redhat.com/show_bug.cgi?id=659635 Summary: Requesting upgrade to 1.905+ Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: medium Priority: low Component: perl-Email-MIME AssignedTo: tcall...@redhat.com ReportedBy: emmanuel.sey...@club-internet.fr QAContact: extras...@fedoraproject.org CC: tcall...@redhat.com, fedora-perl-devel-l...@redhat.com Classification: Fedora Bugzilla 4.0rc1 came out a while back, sporting a dependency on Email::MIME 1.905. This makes it uninstallable on Fedora where perl-Email-MIME is at 1.863 . Can we get an upgrade in rawhide? -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Email-MIME-1.906.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Email-MIME: 8c37be23b7813ba9e72f9b043d0620ce Email-MIME-1.906.tar.gz -- 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-Email-MIME] Update to 1.906 (#659635)
commit 7bef3fcf9ff38fdf42773b8709761613aaedf0f7
Author: Paul Howarth p...@city-fan.org
Date: Fri Dec 3 10:31:46 2010 +
Update to 1.906 (#659635)
- New upstream release 1.906
- BR: perl(Email::Date::Format) and perl(Email::MessageID)
- BR: perl(Test::MinimumVersion) for additional test coverage
- Bump perl(Email::MIME::Encodings) version requirement to 1.313
- Bump perl(Email::Simple) version requirement to 2.004
.gitignore |2 +-
perl-Email-MIME.spec | 19 ++-
sources |2 +-
3 files changed, 16 insertions(+), 7 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 19b148d..864d2be 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-Email-MIME-1.863.tar.gz
+/Email-MIME-1.906.tar.gz
diff --git a/perl-Email-MIME.spec b/perl-Email-MIME.spec
index 03e1743..cae0c06 100644
--- a/perl-Email-MIME.spec
+++ b/perl-Email-MIME.spec
@@ -1,6 +1,6 @@
Name: perl-Email-MIME
-Version:1.863
-Release:5%{?dist}
+Version:1.906
+Release:1%{?dist}
Summary:Easy MIME message parsing
Group: Development/Libraries
@@ -10,14 +10,16 @@ Source0:
http://www.cpan.org/authors/id/R/RJ/RJBS/Email-MIME-%{version}.t
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
+BuildRequires: perl(Email::Date::Format)
BuildRequires: perl(Email::MIME::ContentType) = 1.011
-BuildRequires: perl(Email::MIME::Encodings) = 1.3
-BuildRequires: perl(Email::Simple) = 1.995
+BuildRequires: perl(Email::MIME::Encodings) = 1.313
+BuildRequires: perl(Email::MessageID)
+BuildRequires: perl(Email::Simple) = 2.004
BuildRequires: perl(MIME::Types) = 1.13
+BuildRequires: perl(Test::MinimumVersion)
BuildRequires: perl(Test::Pod) = 1.14
BuildRequires: perl(Test::Pod::Coverage) = 1.08
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-Requires: perl(Email::Simple) = 1.91
Requires: perl(MIME::Types) = 1.13
%description
@@ -60,6 +62,13 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Fri Dec 3 2010 Paul Howarth p...@city-fan.oth - 1.906-1
+- Update to 1.906 (#659635)
+- BR: perl(Email::Date::Format) and perl(Email::MessageID)
+- BR: perl(Test::MinimumVersion) for additional test coverage
+- Bump perl(Email::MIME::Encodings) version requirement to 1.313
+- Bump perl(Email::Simple) version requirement to 2.004
+
* Sat May 01 2010 Marcela Maslanova mmasl...@redhat.com - 1.863-5
- Mass rebuild with perl-5.12.0
diff --git a/sources b/sources
index fac4a13..7a64e59 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-339b0a09fab042c1f9a6292a220b333d Email-MIME-1.863.tar.gz
+8c37be23b7813ba9e72f9b043d0620ce Email-MIME-1.906.tar.gz
--
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-Email-MIME] Created tag perl-Email-MIME-1.906-1.fc15
The lightweight tag 'perl-Email-MIME-1.906-1.fc15' was created pointing to: 7bef3fc... Update to 1.906 (#659635) -- 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 659635] Requesting upgrade to 1.905+
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=659635 Paul Howarth p...@city-fan.org changed: What|Removed |Added Status|NEW |CLOSED CC||p...@city-fan.org Fixed In Version||perl-Email-MIME-1.906-1.fc1 ||5 Resolution||RAWHIDE Last Closed||2010-12-03 05:49:59 --- Comment #1 from Paul Howarth p...@city-fan.org 2010-12-03 05:49:59 EST --- Bumped to 1.906 in Rawhide. -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 659635] Requesting upgrade to 1.905+
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=659635 --- Comment #2 from Emmanuel Seyman emmanuel.sey...@club-internet.fr 2010-12-03 06:28:55 EST --- Note that you'll have to obsolete perl-Email-MIME-Modifier and perl-Email-MIME-Creator which were merged in 1.900 -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Email-MIME] Obsolete perl-Email-MIME-{Creator,Modifier}
commit ad3abf4d80d6ac8560b24177694c3938ca8f9788
Author: Paul Howarth p...@city-fan.org
Date: Fri Dec 3 11:52:37 2010 +
Obsolete perl-Email-MIME-{Creator,Modifier}
- Obsolete perl-Email-MIME-Creator and perl-Email-MIME-Modifier, merged into
Email::MIME at version 1.900
perl-Email-MIME.spec | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
---
diff --git a/perl-Email-MIME.spec b/perl-Email-MIME.spec
index cae0c06..709f24f 100644
--- a/perl-Email-MIME.spec
+++ b/perl-Email-MIME.spec
@@ -1,6 +1,6 @@
Name: perl-Email-MIME
Version:1.906
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Easy MIME message parsing
Group: Development/Libraries
@@ -21,6 +21,10 @@ BuildRequires: perl(Test::Pod) = 1.14
BuildRequires: perl(Test::Pod::Coverage) = 1.08
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
Requires: perl(MIME::Types) = 1.13
+Obsoletes: perl-Email-MIME-Creator 1.457
+Obsoletes: perl-Email-MIME-Modifier 1.445
+Provides: perl-Email-MIME-Creator = %{version}
+Provides: perl-Email-MIME-Modifier = %{version}
%description
This is an extension of the Email::Simple module, to handle MIME
@@ -62,6 +66,10 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Fri Dec 3 2010 Paul Howarth p...@city-fan.oth - 1.906-2
+- Obsolete perl-Email-MIME-Creator and perl-Email-MIME-Modifier, merged into
+ Email::MIME at version 1.900
+
* Fri Dec 3 2010 Paul Howarth p...@city-fan.oth - 1.906-1
- Update to 1.906 (#659635)
- BR: perl(Email::Date::Format) and perl(Email::MessageID)
--
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-Email-MIME] Created tag perl-Email-MIME-1.906-2.fc15
The lightweight tag 'perl-Email-MIME-1.906-2.fc15' was created pointing to:
ad3abf4... Obsolete perl-Email-MIME-{Creator,Modifier}
--
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 659635] Requesting upgrade to 1.905+
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=659635 Paul Howarth p...@city-fan.org changed: What|Removed |Added Fixed In Version|perl-Email-MIME-1.906-1.fc1 |perl-Email-MIME-1.906-2.fc1 |5 |5 --- Comment #3 from Paul Howarth p...@city-fan.org 2010-12-03 07:02:18 EST --- Obsoleted/provided in 1.906-2 Spot, can you retire perl-Email-MIME-Modifier and perl-Email-MIME-Creator in pkgdb and mark them as dead packages in git please? -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 630802] perl-Test-Smoke must not provide perl(Mail::Sendmail)
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=630802 Bug Zapper tri...@lists.fedoraproject.org changed: What|Removed |Added Status|MODIFIED|CLOSED Resolution||WONTFIX Flag|needinfo?(rc040...@freenet. | |de) | Last Closed||2010-12-03 07:35:18 --- Comment #6 from Bug Zapper tri...@lists.fedoraproject.org 2010-12-03 07:35:18 EST --- Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Wx-Perl-ProcessStream] 0.29 bump
commit c1c89c74a530b595abc8329449dcf795d9229958
Author: Petr Písař ppi...@redhat.com
Date: Fri Dec 3 14:12:56 2010 +0100
0.29 bump
In addition, enable tests. xinit discards make's exit code, signall success
by
file.
.gitignore |1 +
perl-Wx-Perl-ProcessStream.spec | 19 ++-
sources |2 +-
3 files changed, 16 insertions(+), 6 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index d97855f..503ec95 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
Wx-Perl-ProcessStream-0.27.tar.gz
/Wx-Perl-ProcessStream-0.28.tar.gz
+/Wx-Perl-ProcessStream-0.29.tar.gz
diff --git a/perl-Wx-Perl-ProcessStream.spec b/perl-Wx-Perl-ProcessStream.spec
index cd1e7d2..dfec40f 100644
--- a/perl-Wx-Perl-ProcessStream.spec
+++ b/perl-Wx-Perl-ProcessStream.spec
@@ -1,8 +1,8 @@
-# don't run test, because they need gtk display
-%define enable_test 0
+# Tests need X display
+%define enable_test 1
Name: perl-Wx-Perl-ProcessStream
-Version:0.28
+Version:0.29
Release:1%{?dist}
Summary:Access IO of external processes via events
License:GPL+ or Artistic
@@ -11,11 +11,14 @@ URL:
http://search.cpan.org/dist/Wx-Perl-ProcessStream/
Source0:
http://www.cpan.org/authors/id/M/MD/MDOOTSON/Wx-Perl-ProcessStream-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
-BuildRequires: perl(Archive::Tar)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::More)
BuildRequires: perl(Time::HiRes) = 1.2
BuildRequires: perl(Wx) = 0.5
+%if %enable_test
+BuildRequires: xorg-x11-server-Xvfb
+BuildRequires: xorg-x11-xinit
+%endif
Requires: perl(Time::HiRes) = 1.2
Requires: perl(Wx) = 0.5
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
@@ -46,7 +49,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%check
%if %enable_test
-make test
+xinit /bin/sh -c '%{_bindir}/make test touch tests.ok' \
+-- %{_bindir}/Xvfb :666
+[ -f tests.ok ] || exit 1
%endif
%clean
@@ -59,6 +64,10 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Fri Dec 03 2010 Petr Pisar ppi...@redhat.com - 0.29-1
+- 0.29 bump
+- Enable tests by running own X server
+
* Wed Sep 22 2010 Marcela Mašláňová mmasl...@redhat.com - 0.28-1
- update, works with Wx 0.97
diff --git a/sources b/sources
index 28bbabf..2e302d7 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-9a893347401af6e1c40b22c72d92b383 Wx-Perl-ProcessStream-0.28.tar.gz
+0aef4f0723677742aa703998ccf12b21 Wx-Perl-ProcessStream-0.29.tar.gz
--
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 659428] perl-Wx-Perl-ProcessStream-0.29 is available
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=659428 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Wx-Perl-ProcessStream- ||0.29-1.fc15 Resolution||RAWHIDE Last Closed||2010-12-03 08:34:21 -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 544738] cpanspec doesn't escape / in --filter-requires leading to bad sed statements
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=544738 Bug Zapper tri...@lists.fedoraproject.org changed: What|Removed |Added Status|NEW |CLOSED Resolution||WONTFIX Flag|needinfo?(bugzi...@kosowsky | |.org) | Last Closed||2010-12-03 21:08:32 --- Comment #5 from Bug Zapper tri...@lists.fedoraproject.org 2010-12-03 21:08:32 EST --- Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 528159] warning in Fedora::Bugzilla
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=528159 Bug Zapper tri...@lists.fedoraproject.org changed: What|Removed |Added Status|NEW |CLOSED Resolution||WONTFIX Flag|needinfo?(mmasl...@redhat.c | |om) | Last Closed||2010-12-04 02:31:42 --- Comment #8 from Bug Zapper tri...@lists.fedoraproject.org 2010-12-04 02:31:42 EST --- Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 526255] tkmib crashes
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=526255 Bug Zapper tri...@lists.fedoraproject.org changed: What|Removed |Added Status|NEW |CLOSED Resolution||WONTFIX Flag|needinfo?(jsafr...@redhat.c | |om) | Last Closed||2010-12-04 02:36:39 --- Comment #3 from Bug Zapper tri...@lists.fedoraproject.org 2010-12-04 02:36:39 EST --- Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
