Can't build anything in Koji that uses mdadm: mdadm conflicts with dracut
http://kojipkgs.fedoraproject.org//work/tasks/952/4890952/root.log
There's no conflict in dracut.spec. However mdadm.spec has the
following lines:
%if %{fedora} = 18
Conflicts: dracut 024-23
[...]
%endif
%if %{fedora} = 17
Conflicts: dracut 009-14
[...]
%endif
But as far as I can see from the root.log, dracut isn't installed in
the buildroot. Maybe dracut is installed implicitly?
The latest dracut in 'master' is dracut-023-13.git20120821.fc19.
The latest in 'f18' is dracut-024-23.git20130118.fc18. Which gets
installed and why?
Why does mdadm conflict with dracut anyway?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Can't build anything in Koji that uses mdadm: mdadm conflicts with dracut
Richard W.M. Jones píše v Út 22. 01. 2013 v 08:19 +:
http://kojipkgs.fedoraproject.org//work/tasks/952/4890952/root.log
There's no conflict in dracut.spec. However mdadm.spec has the
following lines:
%if %{fedora} = 18
Conflicts: dracut 024-23
[...]
%endif
%if %{fedora} = 17
Conflicts: dracut 009-14
[...]
%endif
But as far as I can see from the root.log, dracut isn't installed in
the buildroot. Maybe dracut is installed implicitly?
the package set being resolved from libguestfs BuildRequires will bring
both dracut and mdadm in
The latest dracut in 'master' is dracut-023-13.git20120821.fc19.
The latest in 'f18' is dracut-024-23.git20130118.fc18. Which gets
installed and why?
because dracut wasn't ever built from the master branch
koji latest-pkg f19 dracut returns dracut-024-18.git20130102.fc18
Why does mdadm conflict with dracut anyway?
Dan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Can't build anything in Koji that uses mdadm: mdadm conflicts with dracut
On Tue, Jan 22, 2013 at 09:54:01AM +0100, Dan Horák wrote:
Richard W.M. Jones píše v Út 22. 01. 2013 v 08:19 +:
http://kojipkgs.fedoraproject.org//work/tasks/952/4890952/root.log
There's no conflict in dracut.spec. However mdadm.spec has the
following lines:
%if %{fedora} = 18
Conflicts: dracut 024-23
[...]
%endif
%if %{fedora} = 17
Conflicts: dracut 009-14
[...]
%endif
But as far as I can see from the root.log, dracut isn't installed in
the buildroot. Maybe dracut is installed implicitly?
the package set being resolved from libguestfs BuildRequires will bring
both dracut and mdadm in
The latest dracut in 'master' is dracut-023-13.git20120821.fc19.
The latest in 'f18' is dracut-024-23.git20130118.fc18. Which gets
installed and why?
because dracut wasn't ever built from the master branch
koji latest-pkg f19 dracut returns dracut-024-18.git20130102.fc18
Why does mdadm conflict with dracut anyway?
So ... the action to fix this is what?
I tried adding a buildoverride of dracut-024-23.git20130118.fc18. Of
course that didn't work (I now realize) because that only affects F18
builds. Or perhaps inheritance should pull it into Rawhide? In any
case, it didn't work -- same conflict.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Can't build anything in Koji that uses mdadm: mdadm conflicts with dracut
Richard W.M. Jones wrote, at 01/22/2013 07:43 PM +9:00:
On Tue, Jan 22, 2013 at 09:54:01AM +0100, Dan Horák wrote:
Richard W.M. Jones píše v Út 22. 01. 2013 v 08:19 +:
http://kojipkgs.fedoraproject.org//work/tasks/952/4890952/root.log
There's no conflict in dracut.spec. However mdadm.spec has the
following lines:
%if %{fedora} = 18
Conflicts: dracut 024-23
[...]
%endif
%if %{fedora} = 17
Conflicts: dracut 009-14
[...]
%endif
But as far as I can see from the root.log, dracut isn't installed in
the buildroot. Maybe dracut is installed implicitly?
the package set being resolved from libguestfs BuildRequires will bring
both dracut and mdadm in
The latest dracut in 'master' is dracut-023-13.git20120821.fc19.
The latest in 'f18' is dracut-024-23.git20130118.fc18. Which gets
installed and why?
because dracut wasn't ever built from the master branch
koji latest-pkg f19 dracut returns dracut-024-18.git20130102.fc18
Why does mdadm conflict with dracut anyway?
So ... the action to fix this is what?
I tried adding a buildoverride of dracut-024-23.git20130118.fc18. Of
course that didn't work (I now realize) because that only affects F18
builds. Or perhaps inheritance should pull it into Rawhide? In any
case, it didn't work -- same conflict.
Rich.
For only a workaround, I just tagged dracut-024-23.git20130118.fc18
as f19, which should appear in F-19 buildroot soon.
dracut maintainer: this is just a workaround, so please build the
latest dracut also on F-19, thank you.
Regards,
Mamoru
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Heads-up: cyrus-sasl-2.1.26 with libsasl2 soname bump
Hi all, I'm going to push update cyrus-sasl-2.1.26 into Rawhide soon. Part of this update is also SONAME bump to libsasl2.so.3. The main issue with this update is that it would break buildroot since there is the openldap package requiring libsasl2.so.2 which is part of buildroot. So I'll do needed steps in co-operation with Jan Vcelak - the openldap maintainer - in order not to break it. There are also several other packages dependent on libsasl2.so.2 [1], which will need rebuild. It's my understanding that there will be mass rebuild soon so I wouldn't rebuild all of them manually, but I would wait for this rebuild. Comments? Suggestions? Thanks, Petr [1] # repoquery -s --whatrequires --alldeps 'libsasl2.so*' | uniq 389-admin-1.1.31-1.fc19.1.src.rpm 389-ds-base-1.3.0.2-1.fc19.src.rpm 389-dsgw-1.1.9-3.fc18.src.rpm argus-3.0.4-3.fc18.src.rpm autofs-5.0.7-10.fc19.src.rpm claws-mail-3.9.0-1.fc19.src.rpm cyrus-imapd-2.4.17-1.fc19.src.rpm cyrus-sasl-2.1.25-2.fc19.src.rpm ekiga-4.0.0-2.fc19.src.rpm evolution-data-server-3.7.4-1.fc19.src.rpm exim-4.80.1-1.fc19.src.rpm freeipa-3.1.0-1.fc19.src.rpm gtk-vnc-0.5.1-5.fc19.src.rpm kdebase3-3.5.10-21.fc18.src.rpm kdepim-4.9.97-1.fc19.src.rpm kdepimlibs-4.9.98-1.fc19.src.rpm libetpan-1.1-3.fc18.src.rpm libguestfs-1.21.2-2.fc19.src.rpm libmemcached-1.0.15-1.fc19.src.rpm nufw-2.4.3-6.fc18.src.rpm pidgin-2.10.6-4.fc19.src.rpm libvirt-1.0.1-4.fc19.src.rpm mozldap-6.0.5-9.fc18.src.rpm mutt-1.5.21-16.fc19.src.rpm myproxy-5.9-2.fc19.src.rpm nss_ldap-265-10.fc17.src.rpm nufw-2.4.3-6.fc18.src.rpm openldap-2.4.33-3.fc19.src.rpm php-5.4.11-1.fc19.src.rpm postfix-2.9.5-2.fc19.src.rpm ptlib-2.10.9-1.fc19.src.rpm qpid-cpp-0.18-5.fc19.src.rpm saslwrapper-0.16-2.fc18.src.rpm qca-cyrus-sasl-2.0.0-0.4.beta3.fc18.src.rpm qemu-1.3.0-3.fc19.src.rpm qpid-cpp-0.18-5.fc19.src.rpm rinputd-1.0.5-1.fc19.src.rpm ruby-qpid-0.8-7.fc18.src.rpm qpid-cpp-0.18-5.fc19.src.rpm saslwrapper-0.16-2.fc18.src.rpm samba-4.0.1-1.fc19.src.rpm sendmail-8.14.6-2.fc19.src.rpm spice-gtk-0.16-1.fc19.src.rpm spice-0.12.2-2.fc19.src.rpm squid-3.2.5-1.fc19.src.rpm subversion-1.7.8-3.fc19.src.rpm -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-up: cyrus-sasl-2.1.26 with libsasl2 soname bump
On Tue, Jan 22, 2013 at 15:19:18 +0100, Petr Lautrbach plaut...@redhat.com wrote: It's my understanding that there will be mass rebuild soon so I wouldn't rebuild all of them manually, but I would wait for this rebuild. Comments? Suggestions? The rebuild will likely be in a side tag and things won't be fixed until the rebuild is complete. It may be better to do the manual rebuild for the affected packages. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-up: cyrus-sasl-2.1.26 with libsasl2 soname bump
On 01/22/2013 03:53 PM, Bruno Wolff III wrote: On Tue, Jan 22, 2013 at 15:19:18 +0100, Petr Lautrbach plaut...@redhat.com wrote: It's my understanding that there will be mass rebuild soon so I wouldn't rebuild all of them manually, but I would wait for this rebuild. Comments? Suggestions? The rebuild will likely be in a side tag and things won't be fixed until the rebuild is complete. It may be better to do the manual rebuild for the affected packages. At first I'd planned to do it manually so I requested a tag for these rebuilds too [1]. But with oncoming mass rebuild I'm not really sure if I can manage all rebuilds before main rebuild given that I'm not a proven packager. [1] https://fedorahosted.org/rel-eng/ticket/5451 Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: installer final touches matters
John Reiser wrote: I await documentation of claims that anaconda RAM requirements have been skyrocketing over the last several releases. The officially documented RAM requirements are, at least: RHL 9: http://www.gurulabs.com/downloads/RELEASE-NOTES-RHL9.html | Memory: | - Minimum for text-mode: 64MB | - Minimum for graphical: 128MB | - Recommended for graphical: 192MB F17: http://docs.fedoraproject.org/en-US/Fedora/17/html/Release_Notes/sect- Release_Notes-Welcome_to_Fedora_17.html#sect-Release_Notes-Hardware_Overview | Minimum RAM for text-mode: 768 MiB | Minimum RAM for graphical: 768 MiB | Recommended RAM for graphical: 1152 MiB A 12-fold increase since the inception of Fedora. (For F18, the memory requirements are entirely undocumented in the release notes.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-up: cyrus-sasl-2.1.26 with libsasl2 soname bump
On 01/22/2013 03:53 PM, Bruno Wolff III wrote: On Tue, Jan 22, 2013 at 15:19:18 +0100, Petr Lautrbach plaut...@redhat.com wrote: It's my understanding that there will be mass rebuild soon so I wouldn't rebuild all of them manually, but I would wait for this rebuild. Comments? Suggestions? The rebuild will likely be in a side tag and things won't be fixed until the rebuild is complete. It may be better to do the manual rebuild for the affected packages. I don't think mass rebuilds are done in side tag. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-ZMQ-LibZMQ3/f18] * First Fedora build.
Summary of changes: aa1c16c... * First Fedora build. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-ZMQ-LibZMQ3/f17] * First Fedora build.
Summary of changes: aa1c16c... * First Fedora build. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Proposed F19 Feature: Package Signature Checking During Installation
On Thu, Jan 10, 2013 at 23:43:07 +0100, Björn Persson bjorn@rombobjörn.se wrote: And since people don't check the certificate anyway it would be better if Firefox would silently switch to plain HTTP when it can't verify the certificate? Not just use the unverified certificate but skip all the cryptography altogether without even telling the user about it? Would that improve anything? Because that's the equivalent of what Anaconda does. It would be better if it just noted that it didn't trust the certificate chain and continued using https, since that would still provide protection from eaves dropping by passive attackers. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New packager: Do the reviewer and the sponsor have to be the same
Le Lun 21 janvier 2013 16:47, Susi Lehtola a écrit : On Mon, 21 Jan 2013 16:30:04 +0100 Michael J Gruber m...@fedoraproject.org wrote: I would like to help this poor soul get his package into Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=860249 (adobe-source-code-pro-fonts) I'm a packager but no sponsor, he's no packager (so needs a sponsor). It's not clear to me whether I can just make a formal review and ask a sponsor to say yes, or the new packager needs an actual review from a sponsor (different pages seem to disagree somewhat on this). An old request for sponsorship on the fonts-SIG list has not been answered so far, which is why I'm trying to help this way. Well, my opinion is: go for it. IMHO it's a lot easier to sponsor someone who already has shown his/her packaging skills. It's just less work for the sponsor... providing the review is of good quality. Now, of course the package won't make it into the repo before the packager has been sponsored. The request looks good, if I had more free time to help a new packager I wouldn't have a problem sponsoring him. As things stand I would be an absentee sponsor which is something I want to avoid. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-up: cyrus-sasl-2.1.26 with libsasl2 soname bump
On Tue, 22 Jan 2013 08:53:06 -0600 Bruno Wolff III br...@wolff.to wrote: On Tue, Jan 22, 2013 at 15:19:18 +0100, Petr Lautrbach plaut...@redhat.com wrote: It's my understanding that there will be mass rebuild soon so I wouldn't rebuild all of them manually, but I would wait for this rebuild. Comments? Suggestions? The rebuild will likely be in a side tag and things won't be fixed until the rebuild is complete. It may be better to do the manual rebuild for the affected packages. Yeah, I don't know if we plan to use a side tag or not, but I think it's better for you to just rebuild all those packages when the change is made. Are you a provenpackager? Or is there one you know willing to help rebuild all those? It's not yet clear when the mass rebuild will be yet... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-up: cyrus-sasl-2.1.26 with libsasl2 soname bump
On Tue, Jan 22, 2013 at 16:13:49 +0100, Petr Lautrbach plaut...@redhat.com wrote: The rebuild will likely be in a side tag and things won't be fixed until the rebuild is complete. It may be better to do the manual rebuild for the affected packages. At first I'd planned to do it manually so I requested a tag for these rebuilds too [1]. But with oncoming mass rebuild I'm not really sure if I can manage all rebuilds before main rebuild given that I'm not a proven packager. [1] https://fedorahosted.org/rel-eng/ticket/5451 If you expect simple rebuilds (just changing the version in the spec file) to work, you can ask for help from proven packagers and probably get it. I'd probably be able to help depending on the timing. Kevin has been known to do this kind of thing as well. The list doesn't look so long that the rebuilds couldn't be done in a short period of time manaully. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Help figure out the debug slowness
As mentioned in the FUDCon kernel talk, we are trying to figure out exactly what causes the massive slowdown for some people with debug kernels. At this point, debug is completely off in the rawhide kernel. Every update this week will turn on more debug options until we find out which one is causing the slowdown. For this to work, we need people testing rawhide proper (not rawhide-nodebug). So please, if you can update daily and give us feedback when you hit a wall, we would really appreciate it. Feedback should be sent to ker...@lists.fedoraproject.org Thanks, Justin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: installer final touches matters
On Tue, 22 Jan 2013 16:17:48 +0100 Kevin Kofler kevin.kof...@chello.at wrote: John Reiser wrote: I await documentation of claims that anaconda RAM requirements have been skyrocketing over the last several releases. The officially documented RAM requirements are, at least: RHL 9: http://www.gurulabs.com/downloads/RELEASE-NOTES-RHL9.html | Memory: | - Minimum for text-mode: 64MB | - Minimum for graphical: 128MB | - Recommended for graphical: 192MB F17: http://docs.fedoraproject.org/en-US/Fedora/17/html/Release_Notes/sect- Release_Notes-Welcome_to_Fedora_17.html#sect-Release_Notes-Hardware_Overview | Minimum RAM for text-mode: 768 MiB | Minimum RAM for graphical: 768 MiB | Recommended RAM for graphical: 1152 MiB A 12-fold increase since the inception of Fedora. (For F18, the memory requirements are entirely undocumented in the release notes.) I have this strange sense of deja-vu. Like we have had this exact same thread/conversation before. Why yes, yes we have: http://lists.fedoraproject.org/pipermail/devel/2012-November/173800.html Can you please stop the argument by repetition ? It's getting very very old. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-up: cyrus-sasl-2.1.26 with libsasl2 soname bump
On Tue, 22 Jan 2013 09:31:37 -0600 Bruno Wolff III br...@wolff.to wrote: If you expect simple rebuilds (just changing the version in the spec file) to work, you can ask for help from proven packagers and probably get it. I'd probably be able to help depending on the timing. Kevin has been known to do this kind of thing as well. The list doesn't look so long that the rebuilds couldn't be done in a short period of time manaully. I'd be happy to help if you need someone with provenpackager. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: installer final touches matters
On 01/21/2013 07:37 PM, Kevin Kofler wrote: * DO NOT REWRITE code! It will ALWAYS break things! You're joking, right? If nobody ever rewrote code... we wouldn't have Linux. ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: installer final touches matters
Please take discussions like these to the installer development list; fedora-devel is too broad a list to discuss mintuae like this I think. On 01/20/2013 05:15 AM, Muayyad AlSadi wrote: we see 3 items, one of them no disk selected it has the same level of importance as the rest two, I believe its background or foreground should be made red or orange. Would it help if the bright orange /!\ icon immediately next to it was larger? choosing the destination is scary, since people know there are some steps might wipe the entire disk, the screen below needs a way to gently tell the user that this step is not scare the monster is not in this step http://i.minus.com/jWQMDfIBvDHZZ.png That's a fair point. later steps should *tell* the user what to do eg. delete a partition then activate auto partitioning or create an ext4 mounted as / always tell the user what is the problem and how can he/she fix it Unfortunately, Anaconda can't read the user's mind as to what the user is looking to achieve, but if you aren't trying to do something advanced or complicated you'll be led through the guided installation path which is very well documented and has a lot of explanatory language to guide the user through. I noticed you didn't include screenshots of any of that. ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Sysadm-Install-0.42.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Sysadm-Install: 9f9d3a7b174b8be45a326b833dd8401e Sysadm-Install-0.42.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-Sysadm-Install] Update to 0.42
commit 3060956d5f15186b1b2a84bb4270659254997980
Author: Paul Howarth p...@city-fan.org
Date: Tue Jan 22 16:47:00 2013 +
Update to 0.42
- New upstream release 0.42
- No longer silently remove directories that are in the way before untar()
- Better error diagnosis on failing untar() tests
perl-Sysadm-Install.spec |7 ++-
sources |2 +-
2 files changed, 7 insertions(+), 2 deletions(-)
---
diff --git a/perl-Sysadm-Install.spec b/perl-Sysadm-Install.spec
index c7abe7f..291c70e 100644
--- a/perl-Sysadm-Install.spec
+++ b/perl-Sysadm-Install.spec
@@ -1,6 +1,6 @@
Summary: Typical installation tasks for system administrators
Name: perl-Sysadm-Install
-Version: 0.41
+Version: 0.42
Release: 1%{?dist}
License: GPL+ or Artistic
Group: Development/Libraries
@@ -74,6 +74,11 @@ find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
%{_mandir}/man3/Sysadm::Install.3pm*
%changelog
+* Tue Jan 22 2013 Paul Howarth p...@city-fan.org 0.42-1
+- Update to 0.42
+ - No longer silently remove directories that are in the way before untar()
+ - Better error diagnosis on failing untar() tests
+
* Tue Dec 18 2012 Paul Howarth p...@city-fan.org 0.41-1
- Update to 0.41
- Added home_dir() function returning user's home directory
diff --git a/sources b/sources
index 21ac734..0a2f762 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a70c90aaa5b00741f87fb16e6cd31336 Sysadm-Install-0.41.tar.gz
+9f9d3a7b174b8be45a326b833dd8401e Sysadm-Install-0.42.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: Install from ISO file supported
On 01/20/2013 11:43 PM, Rahul Sundaram wrote: Hi On Sun, Jan 20, 2013 at 11:22 PM, Ray Strodewrote: Hi, I find it easier (and smaller) to download the netinst.iso (like Fedora-18-x86_64-netinst.iso) Loop-back mount and pull the vmlinuz and initrd.img into /boot The vmlinuz and initrd are made available separately here: http://mirrors.kernel.org/fedora//releases/18/Fedora/x86_64/os/images/pxeboot/ So you can avoid the loop-back mount. It's a good tip, though. Sometimes creating a grub entry is the most straightforward way to get things rolling. Ideally, fedup should do this as a option. If someone wants it, file a RFE I thought fedup does this already? What am I missing here---I just ran fedup for the first time the other day and it created a new default 'Update Fedora' entry during boot. How is it different from what you are discussing here? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] FUDCon ARM related followup
Always was done with yaboot. Do we know if OLPC will move to UEFI? -- Sent from my phone. Please excuse formatting and brevity. Peter Robinson pbrobin...@gmail.com wrote: - Original Message - From: Peter Robinson pbrobin...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Cc: a...@lists.fedoraproject.org Sent: Monday, January 21, 2013 6:28 PM Subject: Re: [fedora-arm] FUDCon ARM related followup On Mon, Jan 21, 2013 at 1:57 PM, Bruno Wolff III br...@wolff.to wrote: On Sun, Jan 20, 2013 at 23:56:49 -0500, Jonathan Masters j...@redhat.com wrote: We had a number of conversations about how to involve more people in Fedora on ARM. We also had many other conversations that are being minuted on the wiki, with more notes and links to follow. Now is a great time to join arm@ and add your input. Since a number of Fedora developers where given XO 1.75s last summer, getting Fedora builds for those people might be a way to get more testing. (Yeah, they mostly use Fedora stuff now, but they don't use a Fedora kernel.) I have been testing OLPC builds, but that wipes my customizations, and I'd rather do more normal Fedora testing with it. Fedora kernels don't support them because they're not all up stream and we don't have support for OFW even where their kernels are upstream. That being said you can use Fedora relatively easily while still doing an initial install with the XO image and getting XO kernel updates but still receiving standard Fedora updates and installing all the other standard Fedora stuff using yum. I documented it here: http://nullr0ute.com/2012/09/using-fedora-on-your-shiny-new-olpc-xo/ It doesn't seem like OF would be that hard to support, given PPC and sparc both use it, and it isn't -that- different then uBoot. Probably not too hard to support but I believe PPC support is via yaboot (or maybe now grub2) layered on top of OFW rather than directly supporting OFW. Peter ___ arm mailing list a...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Coordinating libffi upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Thu, 17 Jan 2013 06:35:08 -0500 (EST) Anthony Green gr...@redhat.com escribió: Dennis wrote: I am right now building a compat-libffi package that has just the old .so nothing to be built against. so expect that early this week the .so of libffi will be bumped. Hey, thanks Dennis! I really appreciate this. I'm hoping to release 3.0.12 soon and get that into the F19 release. Among other things, this include AArch64 support. Anthony Green No problem. seemed it was kinda important and needed doing. as long as the soname of 3.0.12 doesnt change it should be simple. aarch64 support will be needed :) Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlD+0rcACgkQkSxm47BaWfc8mACdG8ly6e52UA+sxhAe8dn2a+4B KvwAnjSRnDkECahj6f/7zk0bGPtKkXcM =k4Nx -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
Jaroslav Reznik (jrez...@redhat.com) said: As decided by FESCo on 2012-12-05 meeting, all proposed Features are required to pass through the community review by announcing them on devel-announce list. FESCo votes on new features no sooner than a week from the announcement. = Features/ReplaceMySQLwithMariaDB = https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB * Detailed description: MariaDB is a fork of the MySQL database project that provides a drop-in replacement for MySQL. It preserves API/ABI compatibility with MySQL and adds some new features. The original company behind MySQL, MySQL AB, were bought out by Sun which was then bought by Oracle. Recent changes made by Oracle indicate they are moving the MySQL project to be more closed. They are no longer publishing any useful information about security issues (CVEs), and they are not providing complete regression tests any more, and a very large fraction of the mysql bug database is now not public. MariaDB, which was founded by some of the original MySQL developers, has a more open-source attitude and an active community. We have found them to be much easier to work with, especially in regards to security matters. We would like to replace MySQL with MariaDB in early development cycle for Fedora 19. MySQL will continue to be available for at least one release, but MariaDB will become the default. Also, we do not intend to support concurrent installation of both packages on the same machine; pick one or the other. What does it mean to replace it as the default if neither is ever installed in a default 'next - next - next' installation? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-up: cyrus-sasl-2.1.26 with libsasl2 soname bump
On Tue, 22 Jan 2013, Petr Lautrbach wrote: Hi all, I'm going to push update cyrus-sasl-2.1.26 into Rawhide soon. Part of this update is also SONAME bump to libsasl2.so.3. Are there any reasons for soname bump? Could you please point out for those? Are there are changes to existing API/structures? -- / Alexander Bokovoy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] FUDCon ARM related followup
On Tue, Jan 22, 2013 at 12:55 PM, Jon Masters j...@redhat.com wrote: Always was done with yaboot. Do we know if OLPC will move to UEFI? I very much doubt it Sent from my phone. Please excuse formatting and brevity. Peter Robinson pbrobin...@gmail.com wrote: - Original Message - From: Peter Robinson pbrobin...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Cc: a...@lists.fedoraproject.org Sent: Monday, January 21, 2013 6:28 PM Subject: Re: [fedora-arm] FUDCon ARM related followup On Mon, Jan 21, 2013 at 1:57 PM, Bruno Wolff III br...@wolff.to wrote: On Sun, Jan 20, 2013 at 23:56:49 -0500, Jonathan Masters j...@redhat.com wrote: We had a number of conversations about how to involve more people in Fedora on ARM. We also had many other conversations that are being minuted on the wiki, with more notes and links to follow. Now is a great time to join arm@ and add your input. Since a number of Fedora developers where given XO 1.75s last summer, getting Fedora builds for those people might be a way to get more testing. (Yeah, they mostly use Fedora stuff now, but they don't use a Fedora kernel.) I have been testing OLPC builds, but that wipes my customizations, and I'd rather do more normal Fedora testing with it. Fedora kernels don't support them because they're not all up stream and we don't have support for OFW even where their kernels are upstream. That being said you can use Fedora relatively easily while still doing an initial install with the XO image and getting XO kernel updates but still receiving standard Fedora updates and installing all the other standard Fedora stuff using yum. I documented it here: http://nullr0ute.com/2012/09/using-fedora-on-your-shiny-new-olpc-xo/ It doesn't seem like OF would be that hard to support, given PPC and sparc both use it, and it isn't -that- different then uBoot. Probably not too hard to support but I believe PPC support is via yaboot (or maybe now grub2) layered on top of OFW rather than directly supporting OFW. Peter ___ arm mailing list a...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-up: cyrus-sasl-2.1.26 with libsasl2 soname bump
Alexander Bokovoy píše v Út 22. 01. 2013 v 19:59 +0200: On Tue, 22 Jan 2013, Petr Lautrbach wrote: Hi all, I'm going to push update cyrus-sasl-2.1.26 into Rawhide soon. Part of this update is also SONAME bump to libsasl2.so.3. Are there any reasons for soname bump? Could you please point out for those? Are there are changes to existing API/structures? like a report from abi-compliance-checker Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install from ISO file supported
2013/1/22 Przemek Klosowski przemek.klosow...@nist.gov On 01/20/2013 11:43 PM, Rahul Sundaram wrote: Hi On Sun, Jan 20, 2013 at 11:22 PM, Ray Strodewrote: Hi, I find it easier (and smaller) to download the netinst.iso (like Fedora-18-x86_64-netinst.iso) Loop-back mount and pull the vmlinuz and initrd.img into /boot The vmlinuz and initrd are made available separately here: http://mirrors.kernel.org/**fedora//releases/18/Fedora/** x86_64/os/images/pxeboot/http://mirrors.kernel.org/fedora//releases/18/Fedora/x86_64/os/images/pxeboot/ So you can avoid the loop-back mount. It's a good tip, though. Sometimes creating a grub entry is the most straightforward way to get things rolling. Ideally, fedup should do this as a option. If someone wants it, file a RFE I thought fedup does this already? What am I missing here---I just ran fedup for the first time the other day and it created a new default 'Update Fedora' entry during boot. How is it different from what you are discussing here? We're talking about of using a LiveCD ISO file -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why do we have a kernel with version number - 20X?
On 01/19/2013 05:50 PM, Bruno Wolff III wrote The hundreds series is speific to the fedora version. Currently f17 is 1xx and f18 is 2xx. The purpose is to keep f18 versions ahead of f17 versions so that updates will work better. .. Presumably as new kernels come out the base number will change to reflect the currently supported versions of Fedora. So that for the 3.9 kernel, f18 will probably be 1xx and f19 2xx. That's a pretty arcane scheme. Would it work to use 17xx, 18xx and 19xx instead? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why do we have a kernel with version number - 20X?
On Tue, Jan 22, 2013 at 14:13:23 -0500, Przemek Klosowski przemek.klosow...@nist.gov wrote: On 01/19/2013 05:50 PM, Bruno Wolff III wrote The hundreds series is speific to the fedora version. Currently f17 is 1xx and f18 is 2xx. The purpose is to keep f18 versions ahead of f17 versions so that updates will work better. .. Presumably as new kernels come out the base number will change to reflect the currently supported versions of Fedora. So that for the 3.9 kernel, f18 will probably be 1xx and f19 2xx. That's a pretty arcane scheme. Would it work to use 17xx, 18xx and 19xx instead? Probably. Putting the release after the dist tag would also probably work. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why do we have a kernel with version number - 20X?
On Jan 22, 2013, at 12:13 PM, Przemek Klosowski przemek.klosow...@nist.gov wrote: On 01/19/2013 05:50 PM, Bruno Wolff III wrote The hundreds series is speific to the fedora version. Currently f17 is 1xx and f18 is 2xx. The purpose is to keep f18 versions ahead of f17 versions so that updates will work better. .. Presumably as new kernels come out the base number will change to reflect the currently supported versions of Fedora. So that for the 3.9 kernel, f18 will probably be 1xx and f19 2xx. That's a pretty arcane scheme. Would it work to use 17xx, 18xx and 19xx instead? 7xx, 8xx, 9xx, 0xx, The first number of a Fedora release seems mostly superfluous. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To the Mate package maintainers
Le Dim 20 janvier 2013 06:46, David Tardon a écrit : Hi, On Sat, Jan 19, 2013 at 03:20:29PM +0100, Vít Ondruch wrote: Dne 19.1.2013 12:46, Tomasz Torcz napsal(a): On Sat, Jan 19, 2013 at 11:11:29AM +0100, Michael Schwendt wrote: On Fri, 18 Jan 2013 18:10:06 -0500, Sam Varshavchik wrote: I see that Gnome's lock screen now shows a pretty clock, after the display wakes up, that must be swiped away in order to unlock the desktop. I just hit Enter or Return to achieve the same. Or Esc. Or scroll by mouse wheel ... I love it :) Great. That makes third obsucre mechanism just to unlock screen (or, rather, just to show the password field). But do not try to wake it up by pressing num lock twice fast. It should be a noop but you can hit a gnome race and hose the system -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why do we have a kernel with version number - 20X?
On 01/22/2013 11:28 AM, Chris Murphy wrote: 7xx, 8xx, 9xx, 0xx, The first number of a Fedora release seems mostly superfluous. 9xx-0xx breaks the goal that updates will work better. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Strange Build problem....
Le Sam 19 janvier 2013 13:34, Paulo César Pereira de Andrade a écrit : 2013/1/19 Nicolas Mailhot nicolas.mail...@laposte.net: Do you have any hints on working on option 3? Well, that means not using fontconfig, so might not be worth for a generic Linux solution... What renderer is matplotlib using now ? Because IIRC it could use cairo, and cairo does support complex font shaping and modern font formats via pango-cairo. 5-6 years ago at an xorg text summit people agreed to converge on a single text rendering stack, and we are finally getting there with QT and GTK both using harfbuzz-ng (+ libreoffice, firefox, etc) The text stack should look like freetype ↓ fontconfig ↓ harfbuzz-ng ↓ upper layers : QT, gtk → pango, cairo → pango, etc -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why do we have a kernel with version number - 20X?
On Tue, Jan 22, 2013 at 11:44:11AM -0800, Josh Stone wrote: 7xx, 8xx, 9xx, 0xx, The first number of a Fedora release seems mostly superfluous. 9xx-0xx breaks the goal that updates will work better. Also would be unnecessarily confusing. It's not like we're running out of numbers here. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Sub-Exporter-Progressive-0.001008.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Sub-Exporter-Progressive: d80a27859c13d471019c75494409282e Sub-Exporter-Progressive-0.001008.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
Self introduction
Hello Fedora faithful, My name is Ben Harper and work for Rackspace as a RPM developer in Austin, TX. My duties include creating RPMs for internal use, but also for iuscommunity.org (IUS). IUS provides new versions of packages found in RHEL. I am looking to become a package maintainer for EPEL. There are some cases where IUS packages have dependences that are not available from packages provided by RHEL and should be provided by EPEL. Currently I do not have package I am looking to get approved, but just looking for a sponsor. I would like to prove that I can follow the documation and create quality packages. I have been reading over the docs and created the needed accounts with this email account. -Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: GCC48 - switch GCC in Fedora 19 to 4.8.x, rebuild all packages with it
Jaroslav Reznik schreef op wo 16-01-2013 om 12:35 [-0500]: See https://lists.fedoraproject.org/pipermail/devel/2013-January/175876.html for details. Once gcc-4.8.0-* is built into Fedora, after a few days or weeks a mass rebuild should be performed. I see that gcc 4.8 was just imported in rawhide some hours ago. What's the plan next? Will the rebuilds happen in a side-tag or in the master branch and when is it scheduled? We on the Fedora MinGW side are ready to import mingw-gcc 4.8 in rawhide as well and we would like to know what's going to happen next so we make the necessary preparations. Introducing mingw-gcc 4.8 is a bit more painful for us at the moment as upstream has decided to use a different exception handling model for the win64 target starting with gcc 4.8 (SEH instead of SjLj). Therefore various packages need to be rebuilt soon after the introduction of mingw-gcc 4.8 to avoid broken dependencies. Regards, Erik van Pienbroek Fedora MinGW SIG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
Bill Nottingham nott...@redhat.com writes: Jaroslav Reznik (jrez...@redhat.com) said: We would like to replace MySQL with MariaDB in early development cycle for Fedora 19. MySQL will continue to be available for at least one release, but MariaDB will become the default. Also, we do not intend to support concurrent installation of both packages on the same machine; pick one or the other. What does it mean to replace it as the default if neither is ever installed in a default 'next - next - next' installation? Default might not be the exactly correct word here. The main thing I'm expecting would be that the mysql database package group would actually give you mariadb, as would the anaconda checkbox. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: GCC48 - switch GCC in Fedora 19 to 4.8.x, rebuild all packages with it
On Tue, Jan 22, 2013 at 09:22:00PM +0100, Erik van Pienbroek wrote: Jaroslav Reznik schreef op wo 16-01-2013 om 12:35 [-0500]: See https://lists.fedoraproject.org/pipermail/devel/2013-January/175876.html for details. Once gcc-4.8.0-* is built into Fedora, after a few days or weeks a mass rebuild should be performed. I see that gcc 4.8 was just imported in rawhide some hours ago. What's the plan next? Will the rebuilds happen in a side-tag or in the master It hasn't been imported into rawhide yet, it was just built (first two non-scratch builds) and (almost) immediately untagged, just so that before tomorrow's FeSCo meeting there are packages already available and ready to be tagged into f19 instantly. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why do we have a kernel with version number - 20X?
On Tue, Jan 22, 2013 at 01:23:44PM -0600, Bruno Wolff III wrote: On Tue, Jan 22, 2013 at 14:13:23 -0500, Przemek Klosowski przemek.klosow...@nist.gov wrote: On 01/19/2013 05:50 PM, Bruno Wolff III wrote The hundreds series is speific to the fedora version. Currently f17 is 1xx and f18 is 2xx. The purpose is to keep f18 versions ahead of f17 versions so that updates will work better. .. Presumably as new kernels come out the base number will change to reflect the currently supported versions of Fedora. So that for the 3.9 kernel, f18 will probably be 1xx and f19 2xx. That's a pretty arcane scheme. Would it work to use 17xx, 18xx and 19xx instead? Probably. Putting the release after the dist tag would also probably work. We're not changing it again. It's just a number. The only reason anyone even noticed is because it was a jump, but we've already been doing this for months. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
On Tue, 22 Jan 2013 15:25:46 -0500 Tom Lane t...@redhat.com wrote: Bill Nottingham nott...@redhat.com writes: Jaroslav Reznik (jrez...@redhat.com) said: We would like to replace MySQL with MariaDB in early development cycle for Fedora 19. MySQL will continue to be available for at least one release, but MariaDB will become the default. Also, we do not intend to support concurrent installation of both packages on the same machine; pick one or the other. What does it mean to replace it as the default if neither is ever installed in a default 'next - next - next' installation? Default might not be the exactly correct word here. The main thing I'm expecting would be that the mysql database package group would actually give you mariadb, as would the anaconda checkbox. Would this involve moving around any of the provides for mysql over to MariaDB? Also, what about those packages depending on unversioned mysql? move those in the next cycle when mysql is completely dropped? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
Kevin Fenzi ke...@scrye.com writes: Would this involve moving around any of the provides for mysql over to MariaDB? Yes, that's the general idea --- any dependencies on mysql should result in installing mariadb, unless the user takes specific action to get mysql instead. Ideally we'd just do the standard Provides/Obsoletes dance for replacing one package with another, but I'm not quite sure how that should work if we still want original mysql to be installable. Any thoughts from RPM experts would be welcome. (If the compatibility testing goes *really* smoothly, maybe we could just drop the requirement for original mysql to still be available, in which case it reduces to the standard package-replacement problem. But I'm not prepared to bet on that quite yet.) Also, what about those packages depending on unversioned mysql? move those in the next cycle when mysql is completely dropped? We could leave 'em as is, couldn't we? regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why do we have a kernel with version number - 20X?
On 22 Jan 2013 20:35, Josh Boyer jwbo...@redhat.com wrote: On Tue, Jan 22, 2013 at 01:23:44PM -0600, Bruno Wolff III wrote: On Tue, Jan 22, 2013 at 14:13:23 -0500, Przemek Klosowski przemek.klosow...@nist.gov wrote: On 01/19/2013 05:50 PM, Bruno Wolff III wrote The hundreds series is speific to the fedora version. Currently f17 is 1xx and f18 is 2xx. The purpose is to keep f18 versions ahead of f17 versions so that updates will work better. .. Presumably as new kernels come out the base number will change to reflect the currently supported versions of Fedora. So that for the 3.9 kernel, f18 will probably be 1xx and f19 2xx. That's a pretty arcane scheme. Would it work to use 17xx, 18xx and 19xx instead? Probably. Putting the release after the dist tag would also probably work. We're not changing it again. It's just a number. The only reason anyone even noticed is because it was a jump, but we've already been doing this for months. I agree. We really don't need a discussion as to the colour of the bike, the people who are maintaining shed have made the decision it will work. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
x2go and nx-libs
I'm starting to look at packaging up x2go (http://x2go.org) which appears to be taking up the charge of maintaining the nx libraries as well as developing new tools around it. So the proposal would be to replace the current nx packages with a nx-libs package using the x2go sources. Some initial notes are here: https://bugzilla.redhat.com/show_bug.cgi?id=886198 Existing nx packages (qtnx, remmina-plugins-nx, freenx-client, freenx-server, nxssh) would need to be ported to the new nx-libs package, which hopefully is just a matter of using the new names. I have some current and ongoing work up at http://www.cora.nwra.com/~orion/fedora/nx/ Please take a look and provide feedback. Thank you. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder 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
Fedora ARM VFAD - 2013-01-23
Good evening all, Please join us tomorrow in #fedora-arm on Freenode for a VFAD to address our final blockers for F18 RC1 for ARM. Let's start off with a short meeting beginning at 10am (EST) to discuss the remaining items - what needs to be done and who will be assisting with each part. F18 RC1 Blocker list - 1) eclipse - build in progress - http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=108801 - https://bugzilla.redhat.com/show_bug.cgi?id=863801 2) js (pkexec/PackageKit) - https://bugzilla.redhat.com/show_bug.cgi?id=892382 3) ghc - using LLVM as compiler, as a result incorrect triplet 4) DTB Distribution for F18 - Work currently in progress, kernel-dtb subpackage - update on status Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
what is the current state of ext4 metadata checksums in Fedora?
Hi, Ext4 metadata checksums feature was merged into Linux 3.6. Can I use it out of the box with Fedora kernel or is there some magic switch to enable it? Are there any plans to support it in e2fsprogs shipped in Fedora - backport or rebase to 1.43 version? Last but equally important - how stable this feature is? Do anyone has any experience with it? -- Best regards, Michal http://eventhorizon.pl/ https://getactive.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]
On Mon, 21.01.13 10:25, Daniel P. Berrange (berra...@redhat.com) wrote: The glibc maintainers don't seem to be against this idea and I am willing to put time into design and implementation. Perhaps I'm misunderstanding what you're after, but doesn't getaddrinfo_a already provide an async version of getaddrinfo ? Asynchronous Hostname Lookup API http://www.akkadia.org/drepper/asynchnl.pdf That said I don't see the reverse - getnameinfo_a Bh. It's designed around process signal delivery. I am shuddering. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
Tom Lane (t...@redhat.com) said: Yes, that's the general idea --- any dependencies on mysql should result in installing mariadb, unless the user takes specific action to get mysql instead. Ideally we'd just do the standard Provides/Obsoletes dance for replacing one package with another, but I'm not quite sure how that should work if we still want original mysql to be installable. Any thoughts from RPM experts would be welcome. (If the compatibility testing goes *really* smoothly, maybe we could just drop the requirement for original mysql to still be available, in which case it reduces to the standard package-replacement problem. But I'm not prepared to bet on that quite yet.) Honestly, I'd be curious as to whether we could get all the compatibility testing done early enough, and packages changed, such that we could consider dropping MySQL. It's just... cleaner. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Schedule for Wednesday's FESCo Meeting (2013-01-23)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC (1:00pm EST, 19:00 CET) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #896 Refine Feature process .fesco 896 https://fedorahosted.org/fesco/ticket/896 = New business = #986F19 Feature: Fix Network Name Resolution - https://fedoraproject.org/wiki/Features/FixNetworkNameResolution .fesco 986 https://fedorahosted.org/fesco/ticket/986 #996F19 Feature: BIND10 - https://fedoraproject.org/wiki/Features/BIND10 .fesco 996 https://fedorahosted.org/fesco/ticket/996 #997F19 Feature: Enlightement - https://fedoraproject.org/wiki/Features/Enlightenment .fesco 997 https://fedorahosted.org/fesco/ticket/997 #998F19 Feature: Erlyvideo -https://fedoraproject.org/wiki/Features/Erlyvideo .fesco 998 https://fedorahosted.org/fesco/ticket/998 #999F19 Feature: Fedora 19 Boost 1.53 Uplift - https://fedoraproject.org/wiki/Features/F19Boost153 .fesco 999 https://fedorahosted.org/fesco/ticket/999 #1000 F19 Feature: GCC 4.8.x - https://fedoraproject.org/wiki/Features/GCC48 .fesco 1000 https://fedorahosted.org/fesco/ticket/1000 #1001 F19 Feature: JRuby 1.7 - https://fedoraproject.org/wiki/Features/JRuby_1.7 .fesco 1001 https://fedorahosted.org/fesco/ticket/1001 #1002 F19 Feature: Ruby 2.0.0 - https://fedoraproject.org/wiki/Features/Ruby_2.0.0 .fesco 1002 https://fedorahosted.org/fesco/ticket/1002 #1003 F19 Feature: RemovePyXML - https://fedoraproject.org/wiki/Features/RemovePyXML .fesco 1003 https://fedorahosted.org/fesco/ticket/1003 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what is the current state of ext4 metadata checksums in Fedora?
On 1/22/13 7:10 PM, Michał Piotrowski wrote: Hi, Ext4 metadata checksums feature was merged into Linux 3.6. Can I use it out of the box with Fedora kernel or is there some magic switch to enable it? Are there any plans to support it in e2fsprogs shipped in Fedora - backport or rebase to 1.43 version? Last but equally important - how stable this feature is? Do anyone has any experience with it? There is no 1.43 released yet, latest is 1.42.7 which I just built in rawhide. The WIP branch in git has the metadata checksum bits, so you could play with that if you want. I have no plans to backport unreleased upstream work in progress to Fedora, I don't think that'd be wise. To be honest, I haven't yet done a whole lot of testing with it myself, yet. -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
'Nice to have' process is now 'Freeze exception' process, improvements to blocker / freeze exception tracker aliases
Hey folks! At FUDCon Lawrence, Tim Flink presented on the Fedora blocker bug and 'NTH' processes, and we got some interesting and useful feedback. People felt that the 'nice to have' / 'accepted' name used in that process was confusing and difficult to understand, and that the aliases used for the tracker bugs were inconsistent. We developed a proposal to rename the aliases and the 'nice to have' process. This was refined over the period of a few days' discussion on the test@ mailing list: see https://lists.fedoraproject.org/pipermail/test/2013-January/113363.html for the thread. There was a very solid consensus that the old scheme sucked and the final form of the new proposal was miles better, and this is not the first time the topic has come up (there are various proposals in the list archives). So I decided to go ahead and Just Do It, putting the proposal into 'production' today. I have adjusted the tracker bugs themselves, https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers , https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process , https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting , and renamed https://fedoraproject.org/wiki/QA:SOP_nth_bug_process to https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process and adjusted it. I have also made the obvious changes to the relatively large number of other wiki pages that link to and talk about the 'nth' / 'freeze exception' process: see my Wiki edit history for those changes. Here are the practical changes: The 'nice to have' / 'NTH' process is now the 'freeze exception' process: thanks to Jared Smith for the name (though I believe it's actually a resurrection from the old 'freeze exception request' process, which was a better name but a much worse process). This name, very much unlike the other one, 'does what it says on the tin': the freeze exception process is how you request freeze exceptions. Seems pretty simple. 'Freeze exception' is kind of jargon, but it's pretty standard terminology in the tech world, doing a web search for it gives you useful results that explain what it is, as noted it is terminology Fedora has used in the past, and we could not think of a way of concisely expressing the concept in non-jargon English. The 'new style' tracker bug aliases are as follows: AlphaBlocker AlphaFreezeException BetaBlocker BetaFreezeException FinalBlocker FinalFreezeException These names are consistent and, again, 'do what they say on the tin'. We were using aliases ending with -accepted for NTH bugs before, which was a really terrible idea (not least because it meant we used the word 'accepted' in two entirely different ways in one process), and the Final aliases did not follow the same pattern as the Alpha and Beta ones. These primary aliases do not need to be versioned, as Kamil Paral perceptively pointed out: as they are only aliases and can be transferred from bug to bug, we can file a new set of tracker bugs for each release, but transfer these unversioned aliases at the time of each release. So right now these aliases are applied to the F19 trackers: at the time of F19 release, they will be transferred to the F20 trackers. This basically means that, at any point in time, you can simply mark a bug as blocking 'AlphaBlocker' and it will be nominated as blocking the next Alpha release. Versioned aliases will still be applied to all the tracker bugs, so that we can find older ones when we need to and so that a consistent naming scheme is always available for all releases. This format will be used: F18AlphaBlocker F18AlphaFreezeExcept F18BetaBlocker F18BetaFreezeExcept F18FinalBlocker F18FinalFreezeExcept The shortening of 'Exception' to 'Except' is unfortunately forced upon us by a Bugzilla limit of 20 characters for alias names. I have submitted a bug requesting this limit be raised: if this is done, the versioned aliases will be changed to follow the format of the unversioned (FreezeException instead of FreezeExcept). I have not yet filed the Fedora 20 tracker bugs as the text in the tracker bug descriptions refers to these aliases and cannot easily be changed after the bug is filed, so I am waiting to see the resolution of this issue before I file those bugs to ensure accurate text can be included. As our Bugzilla allows for multiple aliases to be applied to bugs, bugs can have both the dynamic aliases and their static aliases applied at once, we can maintain 'backwards compatibility', and old trackers can have the new-style aliases applied to them so you can always use the same naming scheme to find the trackers for any release, even old ones. The Fedora 19 tracker bugs consequently have three aliases each at present: the 'dynamic' alias, the new-style versioned alias, and the old-style alias, so people and tools which are used to searching for the old names can still succeed. For example, the F19 Beta freeze exception bug has the aliases 'BetaFreezeException', 'F19BetaFreezeExcept', and
Re: 'Nice to have' process is now 'Freeze exception' process, improvements to blocker / freeze exception tracker aliases
On Tue, 2013-01-22 at 19:30 -0800, Adam Williamson wrote: I can think of a couple of potential issues with the 'dynamic' tracker names (I'm not sure whether nominations will 'transfer' from one release to the next when we change where the alias points, and if so, whether we want that, especially for closed bugs), I just tested this in Landfill, it doesn't seem to be a problem - bugzilla displays the alias, not the bug number, in the Blocks: field but it actually *uses* the bug number. So if you mark Bug #100 as blocking AlphaBlocker (the alias of Bug #1), then transfer that alias from Bug #1 to Bug #2, Bug #100 continues to block Bug #1, not Bug #2. So that's fine. -- 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: 'Nice to have' process is now 'Freeze exception' process, improvements to blocker / freeze exception tracker aliases
On Tue, Jan 22, 2013 at 19:30:25 -0800, Adam Williamson awill...@redhat.com wrote: There was a very solid consensus that the old scheme sucked and the final form of the new proposal was miles better, and this is not the first time the topic has come up (there are various proposals in the list archives). So I decided to go ahead and Just Do It, putting the proposal into 'production' today. I have adjusted the tracker bugs themselves, Thanks for doing this! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
On Wed, Jan 16, 2013 at 08:05:23AM -0500, Jaroslav Reznik wrote: As decided by FESCo on 2012-12-05 meeting, all proposed Features are required to pass through the community review by announcing them on devel-announce list. FESCo votes on new features no sooner than a week from the announcement. = Features/JRuby 1.7 = https://fedoraproject.org/wiki/Features/JRuby_1.7 * Detailed description: Transition to JRuby 1.7 will consist of 3 basic steps: - Updating packages Most of the packages that JRuby depends on are in Fedora just because of JRuby, so they can be safely updated. Some dependencies are shared with other packages, so they will have to be discussed with their owners (see #Scope). - Integration with Fedora Normally, each Ruby implementations ships with its own copy of RubyGems library. This is wrong because a) it's bundling, b) there is no reason why multiple Ruby implementations wouldn't be able to share one RubyGems library. There used to be some differencies in JRuby's copy of RubyGems, but the JRuby upstream has been very cooperative and managed to get them all merged into upstream RubyGems. The integration will require changing Fedora's operating_system.rb (place for distro-specific defaults for RubyGems). This change will result into all Gems with binary extensions having to be recompiled, as the binary extension placement will change. See [1] for current operating_system.rb look and its changes from F18. What should /usr/bin/ruby point to? During standard Gem packaging process, the executable files in Gems get shebangs according to the binary that they are packaged with (Ruby = /usr/bin/ruby; JRuby = /usr/bin/jruby). Therefore executing a Ruby binary runs the interpreter that was used for building (or the hardcoded one, which is usually Ruby). Using alternatives for /usr/bin/ruby doesn't seem to be a very good option, because Ruby and JRuby are not in fact full alternatives, as they for example cannot use same extension Gems (but it still makes sense to allow executing same binaries with them). Also, alternatives are only switchable on admin level (we want every developer with non-root privileges to be able to choose the interpreter). Therefore Ruby-SIG has come up with solution of having /usr/bin/ruby as a bash script (currently called rubypick) [2], that allows user to choose the interpreter as first argument on invocation (_mri_ or _jruby_), if such a parameter is present. Otherwise it falls back to a default. For example invoking ruby_binary _jruby_ --foo=bar in fact invokes /usr/bin/jruby ruby_binary --foo=bar. This bash script will be in a separate package and both Ruby and JRuby will depend on it. Ruby-SIG knows that this feature might be controversial and we wouldn't want it to stop us from bringing JRuby's power to Fedora (if met with a heavy resistance). So if anyone will suggest a more suitable solution, we'll go with it instead of this one. - Changes in packaging None yet. JRuby will be able to use pure Ruby Gems packaged into RPM out of the box, but packaging of Gems with JRuby extensions is turning out to be very complicated, so the guidelines for it will be postponed to next release (as well as the actual packaging). Users will be still able to install Gems with JRuby extensions, both system-wide (into /usr/local/) and into their home directories. [1] https://github.com/bkabrda/jruby.spec/blob/master/rubygems/operating_system.rb [2] https://github.com/bkabrda/rubypick As JRuby is setup to share pure ruby gems with ruby, I don't think this can be approved (inlcuding the update to the jruby package to do this) until FPC rules on whether it's okay for interpreters and languages which are not completely compatible to share modules. FPC will hopefully have quorum tomorrow morning to meet. If not, or if they have issues with the guidelines, perhaps slavek and I can meet to try to figure out ways around the issues. I'll know more after the FPC meeting time tomorrow morning. -Toshio pgpEO2lk8b54d.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM VFAD - 2013-01-23
3) ghc - using LLVM as compiler, as a result incorrect triplet Not sure what this is referring to: ghc ARM devel for F18 is basically done (except for a few minor libs appearing in the Branch report that need rebuilding) and working fine. Maybe this is referring to this Rawhide llvm issue https://bugzilla.redhat.com/show_bug.cgi?id=893294 which I don't think should be on the F18ARMBLocker list, and hopefully will be fixed in llvm-3.1-13.fc19 which is currently building. -Jens -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self introduction
On Tue, Jan 22, 2013 at 8:33 AM, Dan Mashal dan.mas...@gmail.com wrote: On Mon, Jan 21, 2013 at 11:12 PM, Juerg Haefliger jue...@gmail.com wrote: Hi everyboy, My name is Juerg Haefliger and I'm a software engineer with Hewlett-Packard based in Switzerland. Part of my responsibilities is building guest images for the HP cloud that runs OpenStack. Although we use Ubuntu on bare metal, thanks to my imaging work I'm exposed to different distro flavors and the pain and joy that come with it :-) In terms of open source contributions, I'm a developer and maintainer of two hardware monitoring kernel drivers which are part of the lm-sensors project and I've also contributed to cloud-init which is a customization tool for cloud images. My main interest at the moment is to bring some new packages to Fedora and RHEL to support cloud images, so be on the lookout for a sponsor request shortly :-) Best Welcome Juerg. Thank Dan What packages do you plan on submitting? cloud-utils and cloud-initramfs-tools to support automatic partition growing for cloud images. Here are some links to help you get started: http://fedoraproject.org/wiki/How_to_create_an_RPM_package http://fedoraproject.org/wiki/Packaging:NamingGuidelines http://fedoraproject.org/wiki/Package_Review_Process http://fedoraproject.org/wiki/Packaging:Guidelines http://fedoraproject.org/wiki/Packaging:ReviewGuidelines Thanks. I went through most of those already. Still need to tweak the packages a little before I can initiate the review process. ...Juerg See ya around. Dan -- 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: Proposed F19 Feature: Replace MySQL with MariaDB
Bill Nottingham nott...@redhat.com writes: Tom Lane (t...@redhat.com) said: (If the compatibility testing goes *really* smoothly, maybe we could just drop the requirement for original mysql to still be available, in which case it reduces to the standard package-replacement problem. But I'm not prepared to bet on that quite yet.) Honestly, I'd be curious as to whether we could get all the compatibility testing done early enough, and packages changed, such that we could consider dropping MySQL. It's just... cleaner. Quite honestly, I'd prefer that too. But we need to have a good case that it's not going to break very many things for very many people. Database people hate it when you break their database. So ... as mentioned in the feature page, we really need help testing this during the F19 devel cycle. We'll need to make decisions before we reach alpha/beta stage. It strikes me that we missed a bet in setting up the mariadb package for only F19-and-up in git. If we made a version available for F18, that would allow people to test compatibility without having to run rawhide, which is something that would give most DBAs the willies. However, that would require facing the problem of how to declare the package vis-a-vis mysql, since we surely can't drop mysql from F18. So I could still use some advice as to how we might work the provides-obsoletes-conflicts mechanics for that. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
On Wed, 2013-01-23 at 02:12 -0500, Tom Lane wrote: Bill Nottingham nott...@redhat.com writes: Tom Lane (t...@redhat.com) said: (If the compatibility testing goes *really* smoothly, maybe we could just drop the requirement for original mysql to still be available, in which case it reduces to the standard package-replacement problem. But I'm not prepared to bet on that quite yet.) Honestly, I'd be curious as to whether we could get all the compatibility testing done early enough, and packages changed, such that we could consider dropping MySQL. It's just... cleaner. Quite honestly, I'd prefer that too. But we need to have a good case that it's not going to break very many things for very many people. Database people hate it when you break their database. So ... as mentioned in the feature page, we really need help testing this during the F19 devel cycle. We'll need to make decisions before we reach alpha/beta stage. Yeah, 'all the compatibility testing' is something of a vague idea to pin down :) We can certainly run a couple of test days and ask as many people as possible to try Maria on their setups and make sure nothing's amiss, but it's the kind of thing where it's pretty hard to know you've covered everything. I'm no SQL expert and I'm not sure who is; is there anyone who's well-experienced in this area who would be willing to lead testing efforts? Is there any kind of well-known, respected test suite for MySQL? -- 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
[perl-DBI/f18] (2 commits) ...1.623 bump
Summary of changes: d0d3143... Disable Coro properly (*) 9f50def... 1.623 bump (*) (*) 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 893916] perl-DBD-CSV-0.38 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=893916 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-Clone-0.34-1.fc18,perl-DBI-1.623-1.fc18,perl-DBD-CSV-0.38-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/perl-Clone-0.34-1.fc18,perl-DBI-1.623-1.fc18,perl-DBD-CSV-0.38-1.fc18 -- 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=jBn1Jr50lma=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 755903] Use of uninitialized value in string eq at .. FormFu/Constraint.pm line 107
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=755903 Daniel Piddock dgp...@corefiling.co.uk changed: What|Removed |Added Flags|needinfo?(dgp-bz@corefiling | |.co.uk) | --- Comment #4 from Daniel Piddock dgp...@corefiling.co.uk --- The code is part of a Catalyst project. I've gone back to it and cannot reproduce the warning messages using the current 0.09007-1.fc16 so I can't figure out a smaller test case. -- 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=IuFevzUncAa=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
File ZMQ-LibZMQ3-1.08.tar.gz uploaded to lookaside cache by jpo
A file has been added to the lookaside cache for perl-ZMQ-LibZMQ3: 387b58a73efb0cac913e191fa6d8fbaf ZMQ-LibZMQ3-1.08.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-ZMQ-LibZMQ3] * First Fedora build.
commit aa1c16c29e27c3ca9b37600f435740abe641c692
Author: Jose Pedro Oliveira j...@di.uminho.pt
Date: Tue Jan 22 16:09:31 2013 +
* First Fedora build.
.gitignore|1 +
perl-ZMQ-LibZMQ3.spec | 89 +
sources |1 +
3 files changed, 91 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..f523094 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/ZMQ-LibZMQ3-1.08.tar.gz
diff --git a/perl-ZMQ-LibZMQ3.spec b/perl-ZMQ-LibZMQ3.spec
new file mode 100644
index 000..272c946
--- /dev/null
+++ b/perl-ZMQ-LibZMQ3.spec
@@ -0,0 +1,89 @@
+Name: perl-ZMQ-LibZMQ3
+Version:1.08
+Release:2%{?dist}
+Summary:Perl wrapper for the libzmq 3.x library
+
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/ZMQ-LibZMQ3/
+Source0:
http://search.cpan.org/CPAN/authors/id/D/DM/DMAKI/ZMQ-LibZMQ3-%{version}.tar.gz
+
+BuildRequires: perl(AnyEvent)
+BuildRequires: perl(Carp)
+BuildRequires: perl(Cwd)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(Test::Fatal)
+BuildRequires: perl(Test::More) = 0.98
+BuildRequires: perl(Test::Requires)
+BuildRequires: perl(Test::SharedFork)
+BuildRequires: perl(Test::TCP) = 1.08
+BuildRequires: perl(threads)
+BuildRequires: perl(ZMQ::Constants)
+BuildRequires: zeromq3-devel
+
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+
+%{?perl_default_filter}
+
+%description
+The ZMQ::LibZMQ3 module is a wrapper of the 0MQ message passing library for
+Perl. It's a thin wrapper around the C API. Please read http://zeromq.org
+for more details on 0MQ.
+
+
+%prep
+%setup -q -n ZMQ-LibZMQ3-%{version}
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+
+%files
+%doc Changes
+%{perl_vendorarch}/auto/*
+%{perl_vendorarch}/ZMQ*
+%{_mandir}/man3/*.3*
+
+
+%changelog
+* Mon Jan 21 2013 Jose Pedro Oliveira jpo at di.uminho.pt - 1.08-2
+- BR: perl(threads) (#868531).
+
+* Sat Jan 19 2013 Jose Pedro Oliveira jpo at di.uminho.pt - 1.08-1
+- Update to version 1.08
+
+* Wed Jan 16 2013 Jose Pedro Oliveira jpo at di.uminho.pt - 1.07-1
+- Update to version 1.07
+
+* Sun Jan 13 2013 Jose Pedro Oliveira jpo at di.uminho.pt - 1.06-1
+- Update to version 1.06
+
+* Wed Jan 9 2013 Jose Pedro Oliveira jpo at di.uminho.pt - 1.05-1
+- Update to version 1.05
+
+* Sat Jan 5 2013 Jose Pedro Oliveira jpo at di.uminho.pt - 1.03-1
+- Update to version 1.03
+
+* Fri Dec 28 2012 Jose Pedro Oliveira jpo at di.uminho.pt - 1.02-1
+- Update to version 1.02
+
+* Thu Dec 27 2012 Jose Pedro Oliveira jpo at di.uminho.pt - 1.01-2
+- Specfile corrections (based on the review of ZMQ::LibZMQ2)
+
+* Sat Oct 20 2012 Jose Pedro Oliveira jpo at di.uminho.pt - 1.01-1
+- First Fedora specfile
+
+# vim:set ai ts=4 sw=4 sts=4 et:
diff --git a/sources b/sources
index e69de29..e9a1ce6 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+387b58a73efb0cac913e191fa6d8fbaf ZMQ-LibZMQ3-1.08.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-Sysadm-Install] Created tag perl-Sysadm-Install-0.42-1.fc19
The lightweight tag 'perl-Sysadm-Install-0.42-1.fc19' was created pointing to: 3060956... Update to 0.42 -- 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-Sub-Exporter-Progressive] Update to 0.001008
commit 2eb099ea57647e423d21840f96e70a3d1d35f90a
Author: Paul Howarth p...@city-fan.org
Date: Tue Jan 22 20:09:01 2013 +
Update to 0.001008
- New upstream release 0.001008
- Rewrite -tag to :tag for Exporter.pm
- Fix prereqs
- Update old Test::More patch, and apply if we have Test::More 0.96
- Bump perl(Exporter) version requirement to 5.58
...orter-Progressive-0.001008-old-Test::More.patch | 42 ---
perl-Sub-Exporter-Progressive.spec | 18 ++--
sources|2 +-
3 files changed, 40 insertions(+), 22 deletions(-)
---
diff --git a/Sub-Exporter-Progressive-0.001006-old-Test::More.patch
b/Sub-Exporter-Progressive-0.001008-old-Test::More.patch
similarity index 69%
rename from Sub-Exporter-Progressive-0.001006-old-Test::More.patch
rename to Sub-Exporter-Progressive-0.001008-old-Test::More.patch
index 1b88196..5692b7e 100644
--- a/Sub-Exporter-Progressive-0.001006-old-Test::More.patch
+++ b/Sub-Exporter-Progressive-0.001008-old-Test::More.patch
@@ -1,13 +1,14 @@
--- Makefile.PL
+++ Makefile.PL
-@@ -10,6 +10,6 @@ WriteMakefile(
- NAME = 'Sub-Exporter-Progressive',
- VERSION_FROM = 'lib/Sub/Exporter/Progressive.pm',
- $key = {
-- 'Test::More' = 0.89,
-+ 'Test::More' = 0.47,
- }
+@@ -10,7 +10,7 @@ my %deps = (
+ },
);
+ my $key = eval { ExtUtils::MakeMaker-VERSION(6.56) } ? 'BUILD_REQUIRES' :
'PREREQ_PM' ;
+-$deps{$key}{'Test::More'} = '0.96';
++$deps{$key}{'Test::More'} = '0.47';
+
+ WriteMakefile(
+ NAME = 'Sub-Exporter-Progressive',
--- t/all.t
+++ t/all.t
@@ -2,7 +2,7 @@
@@ -19,7 +20,7 @@
use List::Util 'first';
use lib 't/lib';
use A::JunkAll;
-@@ -10,5 +10,3 @@ use A::JunkAll;
+@@ -18,5 +18,3 @@ use A::JunkAll ':all';
ok(main-can('junk1'), 'sub exported');
ok(main-can('junk2'), 'sub exported');
ok(! $INC{'Sub/Exporter.pm'}, 'Sub::Exporter not loaded');
@@ -80,15 +81,24 @@
use strict;
use warnings;
--use Test::More 0.89;
-+use Test::More tests = 4;
+-use Test::More 0.96;
++use Test::More tests = 44;
use List::Util 'first';
+ use Carp;
use lib 't/lib';
- use A::Junk ':other';
-@@ -10,6 +10,3 @@ ok(!main-can('junk1'), 'junk1 not expor
- ok(!main-can('junk2'), 'junk2 not exported');
- ok(main-can('junk3'), 'junk3 exported');
- ok(! $INC{'Sub/Exporter.pm'}, 'Sub::Exporter not loaded');
--
+@@ -38,9 +38,7 @@ sub check_tag
+ {
+ my ($tag, $should, $shouldnt) = @_;
+ my $pkg = 'Local::Importer' . ++$i;
+- subtest test the '$tag' tag = sub
+ {
+- plan tests = 1 + @$should + @$shouldnt;
+ local $@ = undef;
+
+ ok(eval qq{
+@@ -65,5 +63,3 @@ check_tag('-bb', [qw/bar baz/], [qw/foo/
+ check_tag(':all', [qw/foo bar baz/], []);
+ check_tag('-all', [qw/foo bar baz/], []);
+
-done_testing;
-
diff --git a/perl-Sub-Exporter-Progressive.spec
b/perl-Sub-Exporter-Progressive.spec
index 6ea2d03..7119740 100644
--- a/perl-Sub-Exporter-Progressive.spec
+++ b/perl-Sub-Exporter-Progressive.spec
@@ -1,21 +1,22 @@
# We need to patch the test suite if we have old versions of Test::More
-%global old_test_more %(perl -MTest::More -e 'print (($Test::More::VERSION
0.88) ? 1 : 0);' 2/dev/null || echo 0)
+%global old_test_more %(perl -MTest::More -e 'print (($Test::More::VERSION
0.96) ? 1 : 0);' 2/dev/null || echo 0)
Name: perl-Sub-Exporter-Progressive
-Version: 0.001006
+Version: 0.001008
Release: 1%{?dist}
Summary: Only use Sub::Exporter if you need it
Group: Development/Libraries
License: GPL+ or Artistic
URL: http://search.cpan.org/dist/Sub-Exporter-Progressive/
Source0:
http://search.cpan.org/CPAN/authors/id/L/LE/LEONT/Sub-Exporter-Progressive-%{version}.tar.gz
-Patch1:Sub-Exporter-Progressive-0.001006-old-Test::More.patch
+Patch1:Sub-Exporter-Progressive-0.001008-old-Test::More.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildArch: noarch
# === Module Build ==
BuildRequires: perl(ExtUtils::MakeMaker)
# === Module Runtime
-BuildRequires: perl(Exporter)
+BuildRequires: perl(Carp)
+BuildRequires: perl(Exporter) = 5.58
BuildRequires: perl(List::Util)
BuildRequires: perl(Sub::Exporter)
# === Test Suite
@@ -23,7 +24,7 @@ BuildRequires:perl(lib)
BuildRequires: perl(Test::More)
# === Module Runtime
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
-Requires: perl(Exporter)
+Requires: perl(Exporter) = 5.58
Requires: perl(Sub::Exporter)
%description
@@ -69,6 +70,13 @@ rm -rf %{buildroot}
%{_mandir}/man3/Sub::Exporter::Progressive.3pm*
%changelog
+* Tue Jan 22 2013 Paul Howarth p...@city-fan.org - 0.001008-1
+- Update to 0.001008
+ -
[perl-Sub-Exporter-Progressive] Created tag perl-Sub-Exporter-Progressive-0.001008-1.fc19
The lightweight tag 'perl-Sub-Exporter-Progressive-0.001008-1.fc19' was created pointing to: 2eb099e... Update to 0.001008 -- 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-ClamAV-Client] (7 commits) ...Upload the sources
Summary of changes:
5a4563c... Initial setup of the pre-review repo
ab3a777... Initial package for Fedora
6702df3... Don't use the %{__perl} macro
eedf434... Add two missing requirements
6c7399c... New submission for Fedora
efbc943... The package was approved in Fedora
df4e8ed... Upload the sources
--
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-ClamAV-Client: 1/7] Initial setup of the pre-review repo
commit 5a4563c3f94b1e8d67efa8cbee987dbe6c995b50 Author: Mathieu Bridon boche...@fedoraproject.org Date: Tue Jan 15 16:36:35 2013 +0800 Initial setup of the pre-review repo 0 files changed, 0 insertions(+), 0 deletions(-) --- diff --git a/.gitignore b/.gitignore new file mode 100644 index 000..e69de29 diff --git a/sources b/sources new file mode 100644 index 000..e69de29 -- 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-ClamAV-Client: 2/7] Initial package for Fedora
commit ab3a77758c925c6085a1b7728b243566816afa42
Author: Mathieu Bridon boche...@fedoraproject.org
Date: Wed Jan 16 12:01:31 2013 +0800
Initial package for Fedora
This was submitted for review on Tue Jan 15 2013:
https://bugzilla.redhat.com/show_bug.cgi?id=895480#c0
perl-ClamAV-Client.spec | 51 +++
1 files changed, 51 insertions(+), 0 deletions(-)
---
diff --git a/perl-ClamAV-Client.spec b/perl-ClamAV-Client.spec
new file mode 100644
index 000..ddada5b
--- /dev/null
+++ b/perl-ClamAV-Client.spec
@@ -0,0 +1,51 @@
+Name: perl-ClamAV-Client
+Summary:Client class for the ClamAV clamd virus scanner daemon
+Version:0.11
+Release:1%{?dist}
+License:GPL+ or Artistic
+URL:http://search.cpan.org/dist/ClamAV-Client/
+Source0:
http://www.cpan.org/authors/id/J/JM/JMEHNLE/clamav-client/ClamAV-Client-%{version}.tar.gz
+
+BuildArch: noarch
+
+BuildRequires: perl(Module::Build)
+
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%{?perl_default_filter}
+
+%description
+ClamAV::Client is a class acting as a client for a ClamAV clamd virus
+scanner daemon. The daemon may run locally or on a remote system as
+ClamAV::Client can use both Unix domain sockets and TCP/IP sockets. The
+full functionality of the clamd client/server protocol is supported.
+
+
+%prep
+%setup -q -n ClamAV-Client-%{version}
+
+
+%build
+%{__perl} Build.PL installdirs=vendor
+./Build
+
+
+%install
+./Build install destdir=%{buildroot} create_packlist=0
+
+%{_fixperms} %{buildroot}/*
+
+
+%check
+./Build test
+
+
+%files
+%doc CHANGES README
+%{_mandir}/man3/ClamAV*
+%{perl_vendorlib}/ClamAV
+
+
+%changelog
+* Tue Jan 15 2013 Mathieu Bridon boche...@fedoraproject.org - 0.11-1
+- Initial package for Fedora, with help from cpanspec.
--
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-ClamAV-Client: 3/7] Don't use the %{__perl} macro
commit 6702df363b6bc6cf0c1ba39461bd688c9c641063
Author: Mathieu Bridon boche...@fedoraproject.org
Date: Tue Jan 22 11:35:41 2013 +0800
Don't use the %{__perl} macro
This was suggested by Petr during the review.
perl-ClamAV-Client.spec |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
---
diff --git a/perl-ClamAV-Client.spec b/perl-ClamAV-Client.spec
index ddada5b..9472124 100644
--- a/perl-ClamAV-Client.spec
+++ b/perl-ClamAV-Client.spec
@@ -10,7 +10,7 @@ BuildArch: noarch
BuildRequires: perl(Module::Build)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%{?perl_default_filter}
@@ -26,7 +26,7 @@ full functionality of the clamd client/server protocol is
supported.
%build
-%{__perl} Build.PL installdirs=vendor
+perl Build.PL installdirs=vendor
./Build
@@ -47,5 +47,7 @@ full functionality of the clamd client/server protocol is
supported.
%changelog
+- Replace usage of the %%{__perl} macro by the plain perl command.
+
* Tue Jan 15 2013 Mathieu Bridon boche...@fedoraproject.org - 0.11-1
- Initial package for Fedora, with help from cpanspec.
--
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-ClamAV-Client: 4/7] Add two missing requirements
commit eedf43498f5233299e9bfd237c9656e89045
Author: Mathieu Bridon boche...@fedoraproject.org
Date: Tue Jan 22 11:36:09 2013 +0800
Add two missing requirements
These were caught by Petr during the review.
perl-ClamAV-Client.spec |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
---
diff --git a/perl-ClamAV-Client.spec b/perl-ClamAV-Client.spec
index 9472124..7bcca09 100644
--- a/perl-ClamAV-Client.spec
+++ b/perl-ClamAV-Client.spec
@@ -12,6 +12,10 @@ BuildRequires: perl(Module::Build)
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+# These are not found by rpmbuild
+Requires: perl(IO::Socket::INET)
+Requires: perl(IO::Socket::UNIX)
+
%{?perl_default_filter}
%description
@@ -48,6 +52,7 @@ perl Build.PL installdirs=vendor
%changelog
- Replace usage of the %%{__perl} macro by the plain perl command.
+- Add two run-time requirements missed by rpmbuild.
* Tue Jan 15 2013 Mathieu Bridon boche...@fedoraproject.org - 0.11-1
- Initial package for Fedora, with help from cpanspec.
--
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-ClamAV-Client: 5/7] New submission for Fedora
commit 6c7399c7f719a0639b74de3e9ceb857672ee4449
Author: Mathieu Bridon boche...@fedoraproject.org
Date: Tue Jan 22 11:50:51 2013 +0800
New submission for Fedora
This was submitted on Tue Jan 22:
https://bugzilla.redhat.com/show_bug.cgi?id=895480#c2
perl-ClamAV-Client.spec |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
---
diff --git a/perl-ClamAV-Client.spec b/perl-ClamAV-Client.spec
index 7bcca09..3acecb6 100644
--- a/perl-ClamAV-Client.spec
+++ b/perl-ClamAV-Client.spec
@@ -1,7 +1,7 @@
Name: perl-ClamAV-Client
Summary:Client class for the ClamAV clamd virus scanner daemon
Version:0.11
-Release:1%{?dist}
+Release:2%{?dist}
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/ClamAV-Client/
Source0:
http://www.cpan.org/authors/id/J/JM/JMEHNLE/clamav-client/ClamAV-Client-%{version}.tar.gz
@@ -51,6 +51,7 @@ perl Build.PL installdirs=vendor
%changelog
+* Tue Jan 22 2013 Mathieu Bridon boche...@fedoraproject.org - 0.11-2
- Replace usage of the %%{__perl} macro by the plain perl command.
- Add two run-time requirements missed by rpmbuild.
--
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-ClamAV-Client: 7/7] Upload the sources
commit df4e8ed0cb37f48c015da228ffaba45e239ff1be Author: Mathieu Bridon boche...@fedoraproject.org Date: Wed Jan 23 12:16:44 2013 +0800 Upload the sources .gitignore |1 + sources|1 + 2 files changed, 2 insertions(+), 0 deletions(-) --- diff --git a/.gitignore b/.gitignore index e69de29..0925cee 100644 --- a/.gitignore +++ b/.gitignore @@ -0,0 +1 @@ +/ClamAV-Client-0.11.tar.gz diff --git a/sources b/sources index e69de29..474ce1d 100644 --- a/sources +++ b/sources @@ -0,0 +1 @@ +6e32cf376af67bcbd5d3018b7823d86f ClamAV-Client-0.11.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-ClamAV-Client: 6/7] The package was approved in Fedora
commit efbc9439a40c3810628e2d0b11864ce1fd128b9b Merge: fba5557 6c7399c Author: Mathieu Bridon boche...@fedoraproject.org Date: Wed Jan 23 12:16:05 2013 +0800 The package was approved in Fedora perl-ClamAV-Client.spec | 59 +++ 1 files changed, 59 insertions(+), 0 deletions(-) --- -- 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] Active Directory and 389 LDAP password checks
Hi 389 developers, We have a separate Windows Active Directory (AD) environment and a separate 389-LDAP (389) environments. Users that existing in both environments will have the same username. I.E. jsmith in AD and 389, but may have the same or different password. We have a security requirements to make sure the 398 password is NOT the same with AD. In 389, is there a way or a plugin that can enable us to do this? We are willing to pay top dollars for the solution or even a contracting position. Thanks, Tong The information contained in this e-mail (including any attachments) is intended solely for the use of the intended recipient(s), may be used solely for the purpose for which it was sent, may contain confidential, proprietary, or personally identifiable information, and/or may be subject to the attorney-client or attorney work product privilege or other applicable confidentiality protections. If you are not an intended recipient please notify the author by replying to this e-mail and delete this e-mail immediately. Any unauthorized copying, disclosure, retention, distribution or other use of this email, its contents or its attachments is strictly prohibited. -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
