Status to make btsfs to the standard filesystem of Fedora
Hallo, for Fedora 17 we had a feature to make btrfs to the standard filesystem of Fedora. This feature was defered because the fsck utitlities for btrfs was not available on the stable state for Fedora 17. So, I would like to ask, if there any plans to make this to a feautre for F-19. I think it may be sense to integreate this feature to the rewrite of the part of anaconde which is responsible for disc partitioning. In a article of the c't magazin (a german computer magazin) I could read, that this part of the new release of anaconda may be get any more love. Additionally, because I have read about an issue relating btrfs with LVM2 on this mailing list and lost the thread, I woould like to ask about the starte of this issue. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Wednesday's FESCo Meeting (2012-01-16)
On 01/16/2013 08:36 AM, Marcela Maslanova wrote: = Followups = #topic #986 F19 Feature: DualstackNetworking -https://fedoraproject.org/wiki/Features/DualstackNetworking .fesco 986 https://fedorahosted.org/fesco/ticket/986 The feature was renamed, so it will be resent to devel list again with new name and new feature page. The discussion about the feature will happen on next meeting (23 January). Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Wednesday's FESCo Meeting (2012-01-16)
The Pillow feature should not be in the list, it was already approved by FESCO last time. On Wed, Jan 16, 2013 at 10:43 AM, Marcela Mašláňová mmasl...@redhat.comwrote: On 01/16/2013 08:36 AM, Marcela Maslanova wrote: = Followups = #topic #986 F19 Feature: DualstackNetworking -https://fedoraproject.org/* *wiki/Features/**DualstackNetworkinghttps://fedoraproject.org/wiki/Features/DualstackNetworking .fesco 986 https://fedorahosted.org/**fesco/ticket/986https://fedorahosted.org/fesco/ticket/986 The feature was renamed, so it will be resent to devel list again with new name and new feature page. The discussion about the feature will happen on next meeting (23 January). Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB in Fedora
On 01/16/2013 10:07 AM, Henrique Junior wrote: Other distros are discussing about the future of MySQL and the implementation of MariaDB as default. What is Fedora position about this matter? Got any links to those other distributions discussions JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB in Fedora
On Wed, Jan 16, 2013 at 08:07:30AM -0200, Henrique Junior wrote: Other distros are discussing about the future of MySQL and the implementation of MariaDB as default. What is Fedora position about this matter? There have been a few threads about this. We need facts to get a decision - such a fact would be a mariadb package review with a package that replaces mysql. I've started working on such a package for few months ago but haven't made any significant advances due to personal time constraints. So if anyone else would like to work on this. -- sven === jabber/xmpp: s...@lankes.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB in Fedora
On Wed, Jan 16, 2013 at 8:07 AM, Henrique Junior henrique...@gmail.com wrote: Other distros are discussing about the future of MySQL and the implementation of MariaDB as default. What is Fedora position about this matter? -- Henrique LonelySpooky Junior http://about.me/henriquejunior I think this is going to happen for F19 or F20 http://koji.fedoraproject.org/koji/packageinfo?packageID=15262 Itamar Reis Peixoto -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB in Fedora
Amazing Can it replace mysql in the future? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Wednesday's FESCo Meeting (2012-01-16)
On 01/16/2013 10:49 AM, Sandro Mani wrote: The Pillow feature should not be in the list, it was already approved by FESCO last time. On Wed, Jan 16, 2013 at 10:43 AM, Marcela Mašláňová mmasl...@redhat.com mailto:mmasl...@redhat.com wrote: On 01/16/2013 08:36 AM, Marcela Maslanova wrote: = Followups = #topic #986 F19 Feature: DualstackNetworking -https://fedoraproject.org/__wiki/Features/__DualstackNetworking https://fedoraproject.org/wiki/Features/DualstackNetworking .fesco 986 https://fedorahosted.org/__fesco/ticket/986 https://fedorahosted.org/fesco/ticket/986 The feature was renamed, so it will be resent to devel list again with new name and new feature page. The discussion about the feature will happen on next meeting (23 January). Marcela -- devel mailing list devel@lists.fedoraproject.org mailto:devel@lists.fedoraproject.org https://admin.fedoraproject.__org/mailman/listinfo/devel https://admin.fedoraproject.org/mailman/listinfo/devel Thanks, it was incorrectly marked as ready for meeting from the last time. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB in Fedora
On Wed, Jan 16, 2013 at 08:44:31AM -0200, Itamar Reis Peixoto wrote: [MariaDB] I think this is going to happen for F19 or F20 http://koji.fedoraproject.org/koji/packageinfo?packageID=15262 Great news - I totally missed this. This is the package review: https://bugzilla.redhat.com/show_bug.cgi?id=875150 -- sven === jabber/xmpp: s...@lankes.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Request to push libldm to stable
Can someone push this to stable: https://admin.fedoraproject.org/updates/FEDORA-2012-15366/libldm-0.2.3-1.fc18 I don't get any push to stable button when I log in, presumably something to do with me not having submitted it in the first place. I asked Matt Booth (the maintainer) but he seems to be off this week. This is quite important, as it makes libguestfs uninstallable on F18 at the moment (bug 895670). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Request to push libldm to stable
On Wed, Jan 16, 2013 at 11:10:18AM +, Richard W.M. Jones wrote: Can someone push this to stable: https://admin.fedoraproject.org/updates/FEDORA-2012-15366/libldm-0.2.3-1.fc18 I don't get any push to stable button when I log in, presumably something to do with me not having submitted it in the first place. I asked Matt Booth (the maintainer) but he seems to be off this week. This is quite important, as it makes libguestfs uninstallable on F18 at the moment (bug 895670). Actually Matt has just done this a few minutes ago. Sorry for the noise. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [Libjpeg-turbo-users] jpeg-9, API/ABI compatibility, and the future role of this project
On 15/01/13 20:04, Xose Vazquez Perez wrote: On 01/15/2013 01:01 PM, Adam Tkac wrote: Another interesting thread is http://sourceforge.net/mailarchive/message.php?msg_id=30352453 We are currently discussing drop of the https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABI feature because SmartScale encoding (only reason of the jpeg7 and jpeg 8 ABI bumps) was rejected by ISO and actually doesn't bring any benefit over widely used png/webp codecs. So Fedora will probably stick with old jpeg6 API/ABI unless IJG maintainer reveals some new facts about SmartScale. All facts are currently against SmartScale (image quality/size, compression/decompression speed). Upstream Tracker shows 0% of binary compatibility with previous releases: http://upstream-tracker.org/versions/libjpeg.html I hope other distributions don't use that release. FWIW i'm afraid i've had to build jpeg8 from source already to get a certain binary [1] built on Ubuntu to run on Fedora 17... [1] actually a git repo full of binaries: https://wiki.documentfoundation.org/Bibisect -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Wed, Jan 16, 2013 at 09:53:25AM +0100, Jochen Schmitt wrote: Hallo, for Fedora 17 we had a feature to make btrfs to the standard filesystem of Fedora. This feature was defered because the fsck utitlities for btrfs was not available on the stable state for Fedora 17. So, I would like to ask, if there any plans to make this to a feautre for F-19. I think it may be sense to integreate this feature to the rewrite of the part of anaconde which is responsible for disc partitioning. In a article of the c't magazin (a german computer magazin) I could read, that this part of the new release of anaconda may be get any more love. Additionally, because I have read about an issue relating btrfs with LVM2 on this mailing list and lost the thread, I woould like to ask about the starte of this issue. So there are a couple of issues with btrfs which I believe absolutely must be fixed before it can become the default (both affect virtualization, coincidentally): https://bugzilla.redhat.com/show_bug.cgi?id=863978 (data corruptor -- very serious IMHO, and it's been around for *months*) https://bugzilla.redhat.com/show_bug.cgi?id=689127 (performance problem with virtual machines) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proposed F19 Feature: Enlightenment - Integrate Enlightenment in Fedora
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/Enlightenment = https://fedoraproject.org/wiki/Features/Enlightenment * Detailed description: Enlightenment 0.17 a new stable release has been released after 12 years or so of development. The goal is to include all of the Enlightenment Foundation Libraries, the Enlightenment window manager and the integrated apps like Terminology as part of Fedora. All the essential packages are already filed for review. For the set of packages under review, see Feature page. Please, see also the Talk page https://fedoraproject.org/wiki/Talk:Features/Enlightenment Jaroslav ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Fri, Jan 11, 2013 at 04:46:25PM +0100, Michal Schmidt wrote: Dne 10.1.2013 21:28, Kevin Fenzi napsal(a): ok, I guess I could try again. Can we remove prelink? What does it get us these days? Has anything changed about prelink since the last time it was discussed here? prelink should not mess with running executables: http://lists.fedoraproject.org/pipermail/devel/2012-July/169819.html ? No - this is still bad, broken behaviour. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proposed F19 Feature: Erlyvideo - add Erlyvideo video streaming server to the Fedora repositories
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/Erlyvideo = https://fedoraproject.org/wiki/Features/Erlyvideo * Detailed description: Erlyvideo is a modern video streaming server, written in Erlang. You can use Erlyvideo to stream to Flash, iPad, Android, SetTopBox. Unique features like capturing endless streams, streaming directly from Amazon S3-like storages and connecting to SDI make this server a best choice for building video infrastructure. ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proposed F19 Feature: Ruby 2.0.0 - the latest stable version of Ruby, with major increases in speed and reliability
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/Ruby 2.0.0 = https://fedoraproject.org/wiki/Features/Ruby_2.0.0 * Detailed description: Ruby 2.0.0 is upstream's new major release of Ruby. It caries new features such as: - Refinements - Keyword arguments - Enumerable#lazy - Module#prepend - #to_h: Convention for conversion to Hash - %i: a literal for symbol array - regexp engine was changed to Onigmo - DTrace support - TracePoint Yet, it is source level backward compatible with Ruby 1.9.3, so your software will continue to work. The updated Ruby also provides better integration with Fedora, especially JRuby. But not only JRuby, it is also one step closer to be prepared for other interpreters, such as Rubinius. Provided custom Ruby loader with working name rubypick [1] will allow to easily switch interpreters executing your script, provides fallback to whatever Ruby interpreter is available on you system, yet still keeps backward compatibility with all your Ruby scripts. [1] https://github.com/bkabrda/rubypick ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
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 ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Wed, 16 Jan 2013 13:18:19 +0100, Richard W.M. Jones wrote: So there are a couple of issues with btrfs which I believe absolutely must be fixed before it can become the default (both affect virtualization, coincidentally): It affects also compilation, GDB was rebuilding for 10-15 minutes instead of 1 minute. I have provided even a reproducer for 1sec vs. 1min issue. The Bug just got automatically closed without any human reply as almost all of the kernel bugs. btrfs: poor performance https://bugzilla.redhat.com/show_bug.cgi?id=759304 I have filed more Bugs why btrfs is unusable, I had to switch back both my hosts to ext4: btrfs: No space left on device with 21GB available https://bugzilla.redhat.com/show_bug.cgi?id=857435 (after conversion to ext4 I had 50GB free on 150GB disk) btrfs: Random `No such file or directory' on files not being changed at all https://bugzilla.redhat.com/show_bug.cgi?id=759426 upstream kernel: btrfsctl -r: crash https://bugzilla.redhat.com/show_bug.cgi?id=830564 btrfs: general protection fault: set_extent_dirty https://bugzilla.redhat.com/show_bug.cgi?id=889775 Regards, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shall we modify '-g' to '-g3' to have gcc save the macro info?
On Wed, 16 Jan 2013 04:12:29 +0100, xning wrote: Shall we should modify '-g' to '-g3' to have gcc save the macro info? So when we install *-debuginfo packages, we can look up a macro definition, just like we can look up a function definition. That would be great, I have not found any official request for it, there was only short -g3 discussion in: Summary/Minutes from today's FESCo Meeting (2012-06-18) http://lists.fedoraproject.org/pipermail/devel/2012-June/168884.html The new -g3 format by Jakub Jelinek has only very small debug info size increase requirement (FIXME: missing numbers here). Thanks, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2013-01-09)
On Mon, Jan 14, 2013 at 03:02:05PM -0800, Adam Williamson wrote: On Sat, 2013-01-12 at 18:05 +0100, Kevin Kofler wrote: Adam Williamson wrote: GNOME can apply a keyboard config you set via GNOME Control Center systemwide, using localectl. I'm not sure KDE, Xfce, LXDE or other desktops have any ability to do this, though, so if you're running one of those, your only option for setting a system-wide keyboard config may be calling localectl or editing vconsole.conf directly. KDE indeed doesn't do it systemwide. We really need system-config-keyboard fixed! This should have been a release blocker. :-/ No reason why. It's practically the poster child for something that can be fixed with a post-release update, as it by definition only affects post-release configuration. I didn't even bother nominating it as a blocker and it would have been comfortably rejected if it had been proposed. Unless your password contains characters affected by the keyboard layout. One of the user accounts I test with is set up like this, and frequently hits this sort of bug -- I recommend others try the same thing. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl] Remove bundled Pod-Parser
commit 0494b1c5823db7f9d607eff207e928c464de02f1
Author: Petr Písař ppi...@redhat.com
Date: Wed Jan 16 14:13:09 2013 +0100
Remove bundled Pod-Parser
perl.spec |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
---
diff --git a/perl.spec b/perl.spec
index 1ed6a6c..c6f8d4d 100644
--- a/perl.spec
+++ b/perl.spec
@@ -29,7 +29,7 @@
Name: perl
Version:%{perl_version}
# release number must be even higher, because dual-lived modules will be
broken otherwise
-Release:246%{?dist}
+Release:247%{?dist}
Epoch: %{perl_epoch}
Summary:Practical Extraction and Report Language
Group: Development/Languages
@@ -1044,6 +1044,7 @@ This module provides things that are useful in decoding
Pod E... sequences.
Presumably, it should be used only by Pod parsers and/or formatters.
+%if %{dual_life} || %{rebuild_from_scratch}
%package Pod-Parser
Summary:Basic perl modules for handling Plain Old Documentation (POD)
Group: Development/Libraries
@@ -1059,6 +1060,7 @@ BuildArch: noarch
This software distribution contains the packages for using Perl5 POD (Plain
Old Documentation). See the perlpod and perlsyn manual pages from your
Perl5 distribution for more information about POD.
+%endif
%if %{dual_life} || %{rebuild_from_scratch}
%package Pod-Perldoc
@@ -2602,6 +2604,7 @@ sed \
%{privlib}/Pod/Escapes.pm
%{_mandir}/man3/Pod::Escapes.*
+%if %{dual_life} || %{rebuild_from_scratch}
%files Pod-Parser
%{_bindir}/pod2usage
%{_bindir}/podchecker
@@ -2625,6 +2628,7 @@ sed \
%{_mandir}/man3/Pod::PlainText.*
%{_mandir}/man3/Pod::Select.*
%{_mandir}/man3/Pod::Usage.*
+%endif
%if %{dual_life} || %{rebuild_from_scratch}
%files Pod-Perldoc
@@ -2750,6 +2754,9 @@ sed \
# Old changelog entries are preserved in CVS.
%changelog
+* Wed Jan 16 2013 Petr Pisar ppi...@redhat.com - 4:5.16.2-247
+- Remove bundled Pod-Parser
+
* Fri Jan 11 2013 Petr Pisar ppi...@redhat.com - 4:5.16.2-246
- Fix CVE-2012-6329 (misparsing of maketext strings) (bug #884354)
--
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: fedup ui
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue 15 Jan 2013 01:58:45 PM EST, Neal Becker wrote: Just tried fedup f17-f18. After digging for correct command line, I got it to work. BUT, after reboot it sits at fedora splash screen, which is pulsating. It gives almost no indication that it actually isn't dead. Attempts to switch vt do nothing, so no way to see what's happening. I eventually noticed a very small, very slowly progressing bar. Really needs better user feedback. I agree, it could use a better UI. A poorly-documented feature is that if you hit Esc at that progress bar, it will switch to text-mode where systemd will inform you of its current state. (However, if you hit Esc again to go back to the graphical screen, the progress bar will be permanently stuck at zero, which is a known bug). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlD2rW0ACgkQeiVVYja6o6PN8ACbBdNS7Flb3CaiUuWkecfazRfq thEAn1Zl+u/t/FcSyVNhHmcpbut/sMlD =JlWT -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Erlyvideo - add Erlyvideo video streaming server to the Fedora repositories
On Wed, Jan 16, 2013 at 7:38 AM, Jaroslav Reznik jrez...@redhat.com 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/Erlyvideo = https://fedoraproject.org/wiki/Features/Erlyvideo * Detailed description: Erlyvideo is a modern video streaming server, written in Erlang. You can use Erlyvideo to stream to Flash, iPad, Android, SetTopBox. Unique features like capturing endless streams, streaming directly from Amazon S3-like storages and connecting to SDI make this server a best choice for building video infrastructure. I'm kind of concerned about this one. The Feature page seems to be more of an announcement that the application is packaged than anything else. It was last updated back in August, and it is still at 0%. While we might debate the usefulness of percentages, it's hard to misinterpret 0. There isn't even a package review ticket for the package, nor either of the two packages it depends on. To be honest, I'm not sure how this was considered ready for review. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Enlightenment - Integrate Enlightenment in Fedora
I love this one, can I do something for this? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Erlyvideo - add Erlyvideo video streaming server to the Fedora repositories
- Original Message - On Wed, Jan 16, 2013 at 7:38 AM, Jaroslav Reznik jrez...@redhat.com 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/Erlyvideo = https://fedoraproject.org/wiki/Features/Erlyvideo * Detailed description: Erlyvideo is a modern video streaming server, written in Erlang. You can use Erlyvideo to stream to Flash, iPad, Android, SetTopBox. Unique features like capturing endless streams, streaming directly from Amazon S3-like storages and connecting to SDI make this server a best choice for building video infrastructure. I'm kind of concerned about this one. The Feature page seems to be more of an announcement that the application is packaged than anything else. It was last updated back in August, and it is still at 0%. While we might debate the usefulness of percentages, it's hard to misinterpret 0. There isn't even a package review ticket for the package, nor either of the two packages it depends on. To be honest, I'm not sure how this was considered ready for review. Well, I asked Peter today to extend at least How to test section, he's still interested in the feature and he did the change as requested. So I do not have a reason why to not at least announce it. From my Wrangler POV of course. If anything else arises from the announcement, I'm ok to ping him and ask for more details. Jaroslav josh -- 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
Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]
As the Feature was renamed and the content of Feature has been extended as requested by FESCo, re-announcing it to the community for re-review. See https://fedorahosted.org/fesco/ticket/986 = Features/Fix Network Name Resolution = https://fedoraproject.org/wiki/Features/FixNetworkNameResolution * Detailed description Currently the getaddrinfo() function doesn't work as it was desinged. Many of its features are buggy and cannot be used without extensive workarounds. Many software packages are using getaddrinfo() with such workarounds. Many can trigger its failures. And many packages that don't use getaddrinfo() will be ported in the near future. - Rationale We are submitting this bug fixing effort as a Feature because: It is a high-impact change that will (positively) affect allmost all networking software Developers will be able to use getaddrinfo() without ugly workarounds for new code We are going to publish guidelines for proper getaddrinfo() usage Documentation for getaddrinfo() bugs will be availabe Possible workarounds will be offered for backward compatibility Comments and errata will be sent to standards organizations We want to recieve critical response during the whole process It will be part of the next networking testweek - Problem statement The behavior of getaddrinfo() is often nonstandard, undocumented, surprising, or just plain wrong. We already indentified a number of problems. The most prominent examples are here. getaddrinfo() may return duplicate or even wrong addresses from /etc/hosts getaddrinfo() with NULL servname may return duplicate addresses getaddrinfo() with AI_PASSIVE may still return address list not suitable for bind() getaddrinfo() with AI_ADDRCONFIG may fail to translate literal addresses getaddrinfo() with AI_ADDRCONFIG may fail to resolve /etc/hosts addresses getaddrinfo() with AI_ADDRCONFIG may send unwanted queries getaddrinfo() has a bad choice of default flags/code Whether or not the problematic actually occurs depends on /etc/hosts configuration, /etc/resolv.conf configuration, getaddrinfo() input parameters, runtime kernel network interface configuration, and more. While testing the known bugs or reading the source code, more and more bugs are discovered. Bug reports related to getaddrinfo() can be found upstream: http://sourceware.org/bugzilla/buglist.cgi?quicksearch=getaddrinfo -Affected software The above problems affect software that wants to use getaddrinfo() to: Get parameters for connect() or sendto() to start communicating Get parameters for bind() to listen on specific addresses Build IP address based accesslists Perform name resolution for other purposes Although it would be nice to also test and fix all software in Fedora using getaddrinfo(), that is not feasible. Therefore we are going to concentrate on checking and fixing the GNU C library, checking and fixing the most important toolkits dealing with networking, and documenting a set of guidelines for daemons and application software. Fedora bugs related to dualstack networking including name resolution problems should be added to the following tracker bug: http://bugzilla.redhat.com/show_bug.cgi?id=883152 - Original Message - 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/DualstackNetworking = https://fedoraproject.org/wiki/Features/DualstackNetworking * Detailed description Fedora supports dualstack global networking. That means the computer with Fedora is connected to internet using both IPv4 and IPv6 protocols. But many important system services and applications either don't do IPv6, do it incorrectly, or don't cope with various network conditions. Unfortunately, while trying to improve IPv6 support, some IPv4 use cases became broken as well. That's why the goal of this feature is not only to support IPv4, but to support all possible real-world cases. Dualstack-ready software must cope with all possible scenarios including IPv4-only connectivity, IPv6-only connectivity and dual connectivity. The software must also cope with node-local (aka localhost) networking, which as been used by software for decades. Though it would be nice to have all applications in Fedora fixed to work in any of the scenarios, it is not feasible to test that. Therefore this feature is about major software used in servers, desktops and laptops. The list of such applications will be completed over the time. Bugs related to dualstack networking should be added to the following tracker bug: http://bugzilla.redhat.com/show_bug.cgi?id=883152 Also see: https://bugzilla.redhat.com/show_bug.cgi?id=ipv6blocker ___ devel-announce mailing list
Re: Shall we modify '-g' to '-g3' to have gcc save the macro info?
On Wed, Jan 16, 2013 at 02:26:00PM +0100, Jan Kratochvil wrote: On Wed, 16 Jan 2013 04:12:29 +0100, xning wrote: Shall we should modify '-g' to '-g3' to have gcc save the macro info? So when we install *-debuginfo packages, we can look up a macro definition, just like we can look up a function definition. That would be great, I have not found any official request for it, there was only short -g3 discussion in: Summary/Minutes from today's FESCo Meeting (2012-06-18) http://lists.fedoraproject.org/pipermail/devel/2012-June/168884.html The new -g3 format by Jakub Jelinek has only very small debug info size increase requirement (FIXME: missing numbers here). The tests performed on average meant that all or most of the space savings thanks to dwz were consumed again by the .debug_macro addition (+ .debug_str growth), which is why I've given up on the request to use -g3 in RPM_OPT_FLAGS by default. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proposed F19 Feature: RemovePyXML - the goal of this Feature is to remove the PyXML package from Fedora
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/RemovePyXML = https://fedoraproject.org/wiki/Features/RemovePyXML * Detailed description: PyXML has been dead upstream for many years. The main authors of it have stated this explicitly on the python-dev mailing list. It's successor, the python stdlib's xml module, has been getting bugfixes that PyXML has not. The current Fedora package maintainer (rrakus) asked about removing it in February, 2012. The Python stdlib in python2.x also has the dubious behaviour of importing PyXML if it is installed and replacing its own code with PyXML's. In some cases, this leads to bugs (For instance: Eric bug, Docutils bug) as the old PyXML code does not cope with some usages that the version in the stdlib does. We want to remove this package from Fedora. To do that we need to decide what happens to the packages that depend on it. After analyzing the packages that use it, most of them will be ported to another xml library as part of this Feature. However, a few packages will be dropped from Fedora instead. -- PS: CC'ing the maintainer of PyXML, he's aware of this Feature and he is ok with the proposal ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora ARM weekly status meeting 2013-01-16
This weeks Fedora ARM status meeting will take place today (Wednesday Jan 16th) in #fedora-meeting-1 on Freenode. Times in various time zones (please let us know if these do not work): PDT: 1pm MDT: 2pm CDT: 3pm EDT: 4pm UTC: 8pm BST: 9pm CST: 10pm Current items on the agenda: 1) Current Problem packages 2) F18 final - a) Identify final blockers b) Which kickstarts will be used? c) Adding v5 vexpress image 3) Plans for the 3.7 kernel 4) FUDCon final preparation a) Friday's dinner (http://746mass.com/ or http://715mass.com/) b) Remaining items? 5) Your topic here! If you have any other items you would like to discuss that are not mentioned, please feel free to send an email to the list or bring it up at the end of the meeting. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 laptop regression
On Wed, 16 Jan 2013 13:49:18 + Richard W.M. Jones rjo...@redhat.com wrote: On Sat, Jan 05, 2013 at 11:38:46PM +0100, Lennart Poettering wrote: is to invoke it via systemd-inhibit --what=handle-lid-switch. # systemd-inhibit --what=handle-lid-switch Missing command line to execute. .. whatever that means. The command expects to be passed the command/program you want to run and have that function inhibited while it's running. ie, if you want to burn a cd and don't want it to suspend in the middle of that you pass the cd burning program, etc. If you don't want it to do that for your entire session you presumably exec your session command with it as a wrapper. It might be nice for it to just assume 'until I kill this systemd-inhibit process' and run. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package EVR problems in Fedora 2013-01-12
On 01/11/2013 07:04 PM, build...@fedoraproject.org wrote: Broken upgrade path report for tags f18 - f18-updates - f19: crobinso: qemu: f18-updates f19 (2:qemu-1.2.2-1.fc18 2:qemu-1.2.0-25.fc19) Was working out some regressions with qemu 1.3, fixed now: http://koji.fedoraproject.org/koji/buildinfo?buildID=378379 Thanks, Cole -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB in Fedora
Henrique Junior henrique...@gmail.com writes: Other distros are discussing about the future of MySQL and the implementation of MariaDB as default. What is Fedora position about this matter? https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB We could use help with testing. Personally I'd like to dump mysql in time for F19, but we need validation that switching to maria doesn't break anything for anyone. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [Libjpeg-turbo-users] jpeg-9, API/ABI compatibility, and the future role of this project
On Wed, Jan 16, 2013 at 01:02:57PM +0100, Michael Stahl wrote: On 15/01/13 20:04, Xose Vazquez Perez wrote: On 01/15/2013 01:01 PM, Adam Tkac wrote: Another interesting thread is http://sourceforge.net/mailarchive/message.php?msg_id=30352453 We are currently discussing drop of the https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABI feature because SmartScale encoding (only reason of the jpeg7 and jpeg 8 ABI bumps) was rejected by ISO and actually doesn't bring any benefit over widely used png/webp codecs. So Fedora will probably stick with old jpeg6 API/ABI unless IJG maintainer reveals some new facts about SmartScale. All facts are currently against SmartScale (image quality/size, compression/decompression speed). Upstream Tracker shows 0% of binary compatibility with previous releases: http://upstream-tracker.org/versions/libjpeg.html I hope other distributions don't use that release. FWIW i'm afraid i've had to build jpeg8 from source already to get a certain binary [1] built on Ubuntu to run on Fedora 17... [1] actually a git repo full of binaries: https://wiki.documentfoundation.org/Bibisect I read the link and it seems libjpeg62 is sufficient (i.e. jpeg6 ABI) for bibisect. So you should not need jpeg8 ABI. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problems with Automake 1.13 and 1.13.1
On Mon, 14 Jan 2013 16:57:02 +0100 Paolo Bonzini pbonz...@redhat.com wrote: Of course (BTW the Automake maintainer now confirmed to me privately that he'd accept such a patch), though it would probably would make sense to put it in Fedora even before 1.13.2. I'll try to put together the patch tomorrow, unless anyone beats me. Any news? We really should fix this asap... since lots of people are adding nasty hacks to work around this, which they will only have to remove after it's fixed. ;( kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shall we modify '-g' to '-g3' to have gcc save the macro info?
Hello xining, xning xn...@redhat.com a écrit: Shall we should modify '-g' to '-g3' to have gcc save the macro info? So when we install *-debuginfo packages, we can look up a macro definition, just like we can look up a function definition. For what it's worth, I believe that would be useful, yes. Though I guess people would need to assess the increase in debug info size and ponder whether we are ready to support that cost or not. -- Dodji -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Wed, Jan 16, 2013 at 8:22 AM, Jan Kratochvil jan.kratoch...@redhat.comwrote: It affects also compilation, GDB was rebuilding for 10-15 minutes instead of 1 minute. I have provided even a reproducer for 1sec vs. 1min issue. The Bug just got automatically closed without any human reply as almost all of the kernel bugs. btrfs: poor performance https://bugzilla.redhat.com/show_bug.cgi?id=759304 I have filed more Bugs why btrfs is unusable, I had to switch back both my hosts to ext4: btrfs: No space left on device with 21GB available https://bugzilla.redhat.com/show_bug.cgi?id=857435 (after conversion to ext4 I had 50GB free on 150GB disk) btrfs: Random `No such file or directory' on files not being changed at all https://bugzilla.redhat.com/show_bug.cgi?id=759426 upstream kernel: btrfsctl -r: crash https://bugzilla.redhat.com/show_bug.cgi?id=830564 btrfs: general protection fault: set_extent_dirty https://bugzilla.redhat.com/show_bug.cgi?id=889775 These should probably just filed upstream. Josef Bacik left Red Hat and joined fusionio along with Chris Mason. I don't know if anyone else within Red Hat is working on Btrfs Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Drop of the libjpeg-turbo jpeg8 ABI feature
Hello all, after discussion with libjpeg and libjpeg-turbo upstreams I decided to drop the jpeg8 API/ABI feature and include only jpeg6 API/ABI. The main reason is that libjpeg upstream didn't present any valid argument for post-jpeg6 changes and libjpeg-turbo is not going to port all post-jpeg6 changes. The thread with related discussion is on http://sourceforge.net/mailarchive/message.php?msg_id=30352465 I'm going to build the libjpeg-turbo pkg with jpeg6 API/ABI and then I will start with rebuilds of all dependent packages. This can probably happen during Friday. Any comments are welcome. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On 1/16/13 10:04 AM, Rahul Sundaram wrote: On Wed, Jan 16, 2013 at 8:22 AM, Jan Kratochvil jan.kratoch...@redhat.com mailto:jan.kratoch...@redhat.com wrote: It affects also compilation, GDB was rebuilding for 10-15 minutes instead of 1 minute. I have provided even a reproducer for 1sec vs. 1min issue. The Bug just got automatically closed without any human reply as almost all of the kernel bugs. btrfs: poor performance https://bugzilla.redhat.com/show_bug.cgi?id=759304 I have filed more Bugs why btrfs is unusable, I had to switch back both my hosts to ext4: btrfs: No space left on device with 21GB available https://bugzilla.redhat.com/show_bug.cgi?id=857435 (after conversion to ext4 I had 50GB free on 150GB disk) btrfs: Random `No such file or directory' on files not being changed at all https://bugzilla.redhat.com/show_bug.cgi?id=759426 upstream kernel: btrfsctl -r: crash https://bugzilla.redhat.com/show_bug.cgi?id=830564 btrfs: general protection fault: set_extent_dirty https://bugzilla.redhat.com/show_bug.cgi?id=889775 These should probably just filed upstream. Josef Bacik left Red Hat and joined fusionio along with Chris Mason. I don't know if anyone else within Red Hat is working on Btrfs Zach Brown is, and I'm trying to get more involved as well. TBH I don't know that upstream would receive any more attention. -Eric Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Drop of the libjpeg-turbo jpeg8 ABI feature
On Wed, 16 Jan 2013 17:14:26 +0100 Adam Tkac at...@redhat.com wrote: Hello all, after discussion with libjpeg and libjpeg-turbo upstreams I decided to drop the jpeg8 API/ABI feature and include only jpeg6 API/ABI. The main reason is that libjpeg upstream didn't present any valid argument for post-jpeg6 changes and libjpeg-turbo is not going to port all post-jpeg6 changes. The thread with related discussion is on http://sourceforge.net/mailarchive/message.php?msg_id=30352465 I'm going to build the libjpeg-turbo pkg with jpeg6 API/ABI and then I will start with rebuilds of all dependent packages. This can probably happen during Friday. Any comments are welcome. Just a few. ;) 1. Are you expecting to do all the rebuilds in one day so they all land in rawhide at the same time? If not, perhaps a side tag? 2. Do you have a list of affected packages? 3. Many folks are going to be at fudcon friday, so the chances of people being around to fix their packages, etc are low. Perhaps early next week would be better to land this? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Drop of the libjpeg-turbo jpeg8 ABI feature
- Original Message - Hello all, after discussion with libjpeg and libjpeg-turbo upstreams I decided to drop the jpeg8 API/ABI feature and include only jpeg6 API/ABI. Ok, I'm going to switch libjpeg-turbo-jpeg8-ABI to incomplete category, thanks. Jaroslav The main reason is that libjpeg upstream didn't present any valid argument for post-jpeg6 changes and libjpeg-turbo is not going to port all post-jpeg6 changes. The thread with related discussion is on http://sourceforge.net/mailarchive/message.php?msg_id=30352465 I'm going to build the libjpeg-turbo pkg with jpeg6 API/ABI and then I will start with rebuilds of all dependent packages. This can probably happen during Friday. Any comments are welcome. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- 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: Status to make btsfs to the standard filesystem of Fedora
On 01/16/2013 04:23 PM, Eric Sandeen wrote: On 1/16/13 10:04 AM, Rahul Sundaram wrote: On Wed, Jan 16, 2013 at 8:22 AM, Jan Kratochvil jan.kratoch...@redhat.com mailto:jan.kratoch...@redhat.com wrote: It affects also compilation, GDB was rebuilding for 10-15 minutes instead of 1 minute. I have provided even a reproducer for 1sec vs. 1min issue. The Bug just got automatically closed without any human reply as almost all of the kernel bugs. btrfs: poor performance https://bugzilla.redhat.com/show_bug.cgi?id=759304 I have filed more Bugs why btrfs is unusable, I had to switch back both my hosts to ext4: btrfs: No space left on device with 21GB available https://bugzilla.redhat.com/show_bug.cgi?id=857435 (after conversion to ext4 I had 50GB free on 150GB disk) btrfs: Random `No such file or directory' on files not being changed at all https://bugzilla.redhat.com/show_bug.cgi?id=759426 upstream kernel: btrfsctl -r: crash https://bugzilla.redhat.com/show_bug.cgi?id=830564 btrfs: general protection fault: set_extent_dirty https://bugzilla.redhat.com/show_bug.cgi?id=889775 These should probably just filed upstream. Josef Bacik left Red Hat and joined fusionio along with Chris Mason. I don't know if anyone else within Red Hat is working on Btrfs Zach Brown is, and I'm trying to get more involved as well. TBH I don't know that upstream would receive any more attention. Afik Josef just left Red Hat not Fedora... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Erlyvideo - add Erlyvideo video streaming server to the Fedora repositories
Josh Boyer (jwbo...@gmail.com) said: On Wed, Jan 16, 2013 at 7:38 AM, Jaroslav Reznik jrez...@redhat.com 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/Erlyvideo = https://fedoraproject.org/wiki/Features/Erlyvideo * Detailed description: Erlyvideo is a modern video streaming server, written in Erlang. You can use Erlyvideo to stream to Flash, iPad, Android, SetTopBox. Unique features like capturing endless streams, streaming directly from Amazon S3-like storages and connecting to SDI make this server a best choice for building video infrastructure. I'm kind of concerned about this one. The Feature page seems to be more of an announcement that the application is packaged than anything else. It was last updated back in August, and it is still at 0%. While we might debate the usefulness of percentages, it's hard to misinterpret 0. Also, the scope bits about the issues with codecs are not encouraging. Do we know that streaming to any of the above targets will work with patent-unencumbered codecs? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Erlyvideo - add Erlyvideo video streaming server to the Fedora repositories
On Wed, Jan 16, 2013 at 5:47 PM, Bill Nottingham nott...@redhat.com wrote: Also, the scope bits about the issues with codecs are not encouraging. Do we know that streaming to any of the above targets will work with patent-unencumbered codecs? Android should work with WebM as for the others I doubt it ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Drop of the libjpeg-turbo jpeg8 ABI feature
On Wed, Jan 16, 2013 at 09:38:29AM -0700, Kevin Fenzi wrote: On Wed, 16 Jan 2013 17:14:26 +0100 Adam Tkac at...@redhat.com wrote: Hello all, after discussion with libjpeg and libjpeg-turbo upstreams I decided to drop the jpeg8 API/ABI feature and include only jpeg6 API/ABI. The main reason is that libjpeg upstream didn't present any valid argument for post-jpeg6 changes and libjpeg-turbo is not going to port all post-jpeg6 changes. The thread with related discussion is on http://sourceforge.net/mailarchive/message.php?msg_id=30352465 I'm going to build the libjpeg-turbo pkg with jpeg6 API/ABI and then I will start with rebuilds of all dependent packages. This can probably happen during Friday. Any comments are welcome. Just a few. ;) 1. Are you expecting to do all the rebuilds in one day so they all land in rawhide at the same time? If not, perhaps a side tag? Yes, rebuild will happen during one day. 2. Do you have a list of affected packages? # repoquery --alldeps --whatrequires 'libjpeg.so.8()(64bit)' |wc -l 373 3. Many folks are going to be at fudcon friday, so the chances of people being around to fix their packages, etc are low. Perhaps early next week would be better to land this? I will use my provenpackager privileges and I will rebuild pkgs myself, as I did for jpeg6-jpeg8 ABI bump. I think it's good that people are away because buildroots will be broken for some time so people won't be affected :) Separate tag is not needed, I think. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Erlyvideo - add Erlyvideo video streaming server to the Fedora repositories
- Original Message - Josh Boyer (jwbo...@gmail.com) said: On Wed, Jan 16, 2013 at 7:38 AM, Jaroslav Reznik jrez...@redhat.com 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/Erlyvideo = https://fedoraproject.org/wiki/Features/Erlyvideo * Detailed description: Erlyvideo is a modern video streaming server, written in Erlang. You can use Erlyvideo to stream to Flash, iPad, Android, SetTopBox. Unique features like capturing endless streams, streaming directly from Amazon S3-like storages and connecting to SDI make this server a best choice for building video infrastructure. I'm kind of concerned about this one. The Feature page seems to be more of an announcement that the application is packaged than anything else. It was last updated back in August, and it is still at 0%. While we might debate the usefulness of percentages, it's hard to misinterpret 0. Also, the scope bits about the issues with codecs are not encouraging. Do we know that streaming to any of the above targets will work with patent-unencumbered codecs? Indeed, from technical POV it's probably the main question - how useful it will be with codecs we provide in Fedora, what's the backend used for it and if it will be possible to split the package to bits that are ok for Fedora (and then it could be included in Fedora) and patent-encumbered stuff distributed by other means. R. Bill -- 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: Strange Build problem....
On 15/01/13 15:43, Toshio Kuratomi wrote:
The try: except: is swallowing all errors here. Getting a more verbose
traceback may help diagnose. You can remove the try: except: and dedent the
remaining code one level to get the actual traceback in the build.log.
This is exactly what I did:
# cat /tmp/test.py
import os, posix, stat, sys
import matplotlib
matplotlib.use('Agg')
import matplotlib.pyplot as plt
import matplotlib.font_manager as fm
and here is the traceback
raceback (most recent call last):
File /tmp/test.py, line 5, in module
import matplotlib.pyplot as plt
File /usr/lib64/python2.7/site-packages/matplotlib/pyplot.py, line 26, in
module
from matplotlib.figure import Figure, figaspect
File /usr/lib64/python2.7/site-packages/matplotlib/figure.py, line 34, in
module
import matplotlib.colorbar as cbar
File /usr/lib64/python2.7/site-packages/matplotlib/colorbar.py, line 29, in
module
import matplotlib.collections as collections
File /usr/lib64/python2.7/site-packages/matplotlib/collections.py, line 23,
in module
import matplotlib.backend_bases as backend_bases
File /usr/lib64/python2.7/site-packages/matplotlib/backend_bases.py, line
37, in module
import matplotlib.widgets as widgets
File /usr/lib64/python2.7/site-packages/matplotlib/widgets.py, line 17, in
module
from lines import Line2D
File /usr/lib64/python2.7/site-packages/matplotlib/lines.py, line 25, in
module
from matplotlib.font_manager import FontProperties
File /usr/lib64/python2.7/site-packages/matplotlib/font_manager.py, line
1325, in module
_rebuild()
File /usr/lib64/python2.7/site-packages/matplotlib/font_manager.py, line
1312, in _rebuild
fontManager = FontManager()
File /usr/lib64/python2.7/site-packages/matplotlib/font_manager.py, line
994, in __init__
self.defaultFont['afm'] = self.afmfiles[0]
IndexError: list index out of range
So it appears to be a problem with matplotlib
My question is why is this happen *only* in a mock environment???
Is it because that environment does not have a needed package???
thanks for the time...
steved.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Wed, Jan 16, 2013 at 11:41 AM, Jóhann B. Guðmundsson wrote: Afik Josef just left Red Hat not Fedora... I haven't seen any recent activity in Fedora from him. Have you? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On 01/16/2013 12:00 PM, Rahul Sundaram wrote: snip I haven't seen any recent activity in Fedora from him. Have you? Rahul Some patches on the btrfs list on Jan 7 and 8, 2013. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
I am testing btrfs on kvm guest, currently i have found: * Bug 894837 - Transient / Intermittent ENOSPC errors with BTRFS and F18 (btrfs gives no space left on device at full or near full filesystem and heavy io, for example deleting stuff to reclaim space.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proposed F19 Feature: Boost 1.53 Uplift - brings Boost 1.53.0 to Fedora 19
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/F19Boost153 = https://fedoraproject.org/wiki/Features/F19Boost153 * Detailed description: That feature aims at synchronising the top of the Fedora tree with the current Boost upstream release. The current Fedora release is boost-1.50.0. As of Fedora 13, the canonical sources used for the package switched from the official Boost release (with BJam build) to an alternate repository (with CMake build, for boost-1.41.0). That alternate repository has been deprecated and may be deleted any time soon (as of January 2013). boost-1.41.0 has been delivered from that (now deprecated) Boost-CMake repository (hosted on Gitorious), where the code base had slightly diverged from upstream. From Fedora 14, boost-1.44.0 has been rebased on upstream, with a mere patch implementing CMake support. Moreover, there is a new Git repository reflecting those changes, hosted on GitHub (and cloned on Gitorious). That repository relies on the Ryppl project (in particular, on the Boost Subversion replicated repository), created and maintained by two Boost developers, namely Eric Niebler and Dave Abrahams. From Fedora 18, boost-1.50.0 was rebased back to Boost.Build v2, as keeping two distinct build systems sometimes conducted to two distinct binary distributions, for instance, when compared to Debian/Ubuntu deliveries. Note that upstream Boost has decided, at the end of 2012, to switch to: Git repository, with GitHub as one of the main hosting services and project management facilities (later on, when the switch to Git will be stable enough) a modularized organisation, and CMake as the primary build system, replacing BJam/BBuild The objective is now to keep delivering the latest stable Boost release for each new Fedora release. ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proposed F19 Feature: BIND10 - next generation of the popular BIND9 DNS server rewritten from scratch
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/BIND 10 = https://fedoraproject.org/wiki/Features/BIND10 * Detailed description: BIND10 suite implements two crucial network services - DNS and DHCP. The BIND10 is going to replace both widely used ISC BIND9 and ISC DHCP4 software in the future. It is written from scratch and has modular design. The main advantages are: - modular design -- authoritative nameserver runs in separate processes. Bug in supplementary process won't affect availability of the server domain -- b10-ddns (DDNS service), b10-xfrin (incomming zone transfers), b10-xfrout (outcomming zone transfers), b10-stats (statistics) -- recursive server runs as separate process (b10-resolver) - modern design, improved scalability - officially supported SQL database backends (only SQLite currently but MySQL and PostgreSQL are planned) ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Wed, Jan 16, 2013 at 12:00 PM, Rahul Sundaram methe...@gmail.com wrote: On Wed, Jan 16, 2013 at 11:41 AM, Jóhann B. Guðmundsson wrote: Afik Josef just left Red Hat not Fedora... I haven't seen any recent activity in Fedora from him. Have you? Did you see consistent activity in Fedora while I was at Red Hat? Because that would be news to me ;) Josef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Wed, Jan 16, 2013 at 3:53 AM, Jochen Schmitt joc...@herr-schmitt.dewrote: Hallo, for Fedora 17 we had a feature to make btrfs to the standard filesystem of Fedora. This feature was defered because the fsck utitlities for btrfs was not available on the stable state for Fedora 17. So, I would like to ask, if there any plans to make this to a feautre for F-19. I think it may be sense to integreate this feature to the rewrite of the part of anaconde which is responsible for disc partitioning. In a article of the c't magazin (a german computer magazin) I could read, that this part of the new release of anaconda may be get any more love. Additionally, because I have read about an issue relating btrfs with LVM2 on this mailing list and lost the thread, I woould like to ask about the starte of this issue. I'm waiting until Anaconda settles down before I pursue btrfs in Fedora again. Things change too much and Btrfs is too reliant on the anaconda part working properly to even bother trying to push it through at this point. Thanks, Josef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Strange Build problem....
On Wed, Jan 16, 2013 at 11:59:08AM -0500, Steve Dickson wrote:
and here is the traceback
raceback (most recent call last):
File /tmp/test.py, line 5, in module
import matplotlib.pyplot as plt
File /usr/lib64/python2.7/site-packages/matplotlib/pyplot.py, line 26, in
module
from matplotlib.figure import Figure, figaspect
File /usr/lib64/python2.7/site-packages/matplotlib/figure.py, line 34, in
module
import matplotlib.colorbar as cbar
File /usr/lib64/python2.7/site-packages/matplotlib/colorbar.py, line 29,
in module
import matplotlib.collections as collections
File /usr/lib64/python2.7/site-packages/matplotlib/collections.py, line
23, in module
import matplotlib.backend_bases as backend_bases
File /usr/lib64/python2.7/site-packages/matplotlib/backend_bases.py, line
37, in module
import matplotlib.widgets as widgets
File /usr/lib64/python2.7/site-packages/matplotlib/widgets.py, line 17,
in module
from lines import Line2D
File /usr/lib64/python2.7/site-packages/matplotlib/lines.py, line 25, in
module
from matplotlib.font_manager import FontProperties
File /usr/lib64/python2.7/site-packages/matplotlib/font_manager.py, line
1325, in module
_rebuild()
File /usr/lib64/python2.7/site-packages/matplotlib/font_manager.py, line
1312, in _rebuild
fontManager = FontManager()
File /usr/lib64/python2.7/site-packages/matplotlib/font_manager.py, line
994, in __init__
self.defaultFont['afm'] = self.afmfiles[0]
IndexError: list index out of range
So it appears to be a problem with matplotlib
My question is why is this happen *only* in a mock environment???
Is it because that environment does not have a needed package???
That seems like a good guess to me. Looking at the root.log for your build,
the only font package installed is dejavu-sans-fonts. That font package
only includes true type fonts on rawhide and this matplotlib code is looking
for afm fonts. One fix/workaround may be to include a BuildRequires/Requires
for a font that ships an afm font file.
Looking at the F17 version of matplotlib, the default afm font is being set
to None there -- so a better fix (but requiring fixing in matplotlib) might
be to patch it like this:
--- /usr/lib64/python2.7/site-packages/matplotlib/font_manager.py
2012-12-04 21:32:42.0 -0500
+++ font_manager.py 2013-01-16 12:26:21.861202681 -0500
@@ -991,7 +991,10 @@
self.afmfiles = findSystemFonts(paths, fontext='afm') + \
findSystemFonts(fontext='afm')
self.afmlist = createFontList(self.afmfiles, fontext='afm')
-self.defaultFont['afm'] = self.afmfiles[0]
+try:
+self.defaultFont['afm'] = self.afmfiles[0]
+except IndexError:
+self.defaultFont['afm'] = None
self.ttf_lookup_cache = {}
self.afm_lookup_cache = {}
-Toshio
pgpeei6_9MXbV.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Erlyvideo - add Erlyvideo video streaming server to the Fedora repositories
Hello All. 2013/1/16 Bill Nottingham nott...@redhat.com: Also, the scope bits about the issues with codecs are not encouraging. Do we know that streaming to any of the above targets will work with patent-unencumbered codecs? Actually that's not a really big issue. Erlyvide can work as a proxy for other streams (say you generate bitstream somewhere else and erlyvideo just retranslates it to the clients). Although I'm going to disable all MP4/AAC-transcoding features and support for patented streaming protocols, it still will be useful. It can capture live streams from DVB-cards, other media-streaming applications, read from filesystem, from the clouds. It can be used as a RTP source for SIP, WebRTC, and XMPP applications as well as for HTTP streaming, and raw RTP streaming. -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Erlyvideo - add Erlyvideo video streaming server to the Fedora repositories
- Original Message - Hello All. 2013/1/16 Bill Nottingham nott...@redhat.com: Also, the scope bits about the issues with codecs are not encouraging. Do we know that streaming to any of the above targets will work with patent-unencumbered codecs? Actually that's not a really big issue. Erlyvide can work as a proxy for other streams (say you generate bitstream somewhere else and erlyvideo just retranslates it to the clients). Although I'm going to disable all MP4/AAC-transcoding features and support for patented streaming protocols, it still will be useful. Will it be possible to split it out to standalone package distributed by different means? Same as we do for example for GStreamer? Jaroslav It can capture live streams from DVB-cards, other media-streaming applications, read from filesystem, from the clouds. It can be used as a RTP source for SIP, WebRTC, and XMPP applications as well as for HTTP streaming, and raw RTP streaming. -- With best regards, Peter Lemenkov. -- 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
Proposed F19 Feature: GCC48 - switch GCC in Fedora 19 to 4.8.x, rebuild all packages with it
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/GCC48 = https://fedoraproject.org/wiki/Features/GCC48 * Detailed description: GCC 4.8.0 is going to be released in mid March to mid April and is currently in regression bugfix only mode. I've performed a test mass rebuild on x86_64 with gcc-4.8.0-0.1.fc19, out of 12712 packages 11687 built successfully, 933 packages failed to build both with gcc-4.8.0-0.1.fc19 and gcc-4.7.2-9.fc19 (thus unlikely gcc related), 67 packages failed due to issues on the side of the packages, 22 failed due to bugs on the gcc side that should be fixed already in gcc-4.8.0-0.3.fc19 and 3 failed due to issues still to be fixed on the GCC side. 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. ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Changing bugz.fp.o's alias (again)
A month ago, I switched over the http://bugz.fedoraproject.org alias from the current pkgdb bugs app[1] to the new packages app[2]. There was a response from the community that this shouldn't have happened during that phase of the release cycle and that the new app was broken and too slow[3][4]. I reverted the alias to point again to pkgdb. I've since done some work to fix bugs and speed up the new app and would like some feedback if you could provide it. It is up in our staging environment at: https://apps.stg.fedoraproject.org/packages/ If I were to switch over the alias again to the new packages app, the https://bugz.fedoraproject.org/kernel alias would redirect to something like: https://apps.stg.fedoraproject.org/packages/kernel/bugs/all/ Some details: I put cacheing in place. If you hit a page and it is slow the first time, it should be fast for subsequent requests. The expiration is set to 5 minutes, so changes to bugs in bugzilla during that time won't show up. After the expiry, a request for new data will fire off a background thread to refresh the cache. Again, the motivation behind switching the alias from the pkgdb app to the packages app is that the pkgdb app's code is older and getting harder to maintain. We are trying to prune (delete) non-essential parts of pkgdb's code in order to one-day rewrite only the core components on a more modern stack. Thanks in advance for any feedback. Cheers- -Ralph [1] - https://admin.fedoraproject.org/pkgdb [2] - https://apps.fedoraproject.org/packages [3] - http://lists.fedoraproject.org/pipermail/devel/2012-December/174956.html [4] - http://lists.fedoraproject.org/pipermail/devel/2012-December/175008.html pgpj4ISR4_juo.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Erlyvideo - add Erlyvideo video streaming server to the Fedora repositories
Hello All. 2013/1/16 Josh Boyer jwbo...@gmail.com: I'm kind of concerned about this one. The Feature page seems to be more of an announcement that the application is packaged than anything else. It was last updated back in August, and it is still at 0%. While we might debate the usefulness of percentages, it's hard to misinterpret 0. I'll update it. I've got a working RPM right now but there are 3 bundled libraries: * parsexml (not used by anyone else) * ranch (quite popular Erlang TCP connection pool library, should be splitted off) * cowboy (small, fast, modular HTTP server written in Erlang) * mimetypes (Erlang MIME types library). Regarding problematic stuff - it contains an Erlang binding to ffmpeg (which should be removed and used as a transcoding solution if transcoding is requested by user) and an Erlang mmap library with lost attribution (I'm working on replacing it with erlang-emmap). It fully supports RTSP ( https://tools.ietf.org/html/rfc2326 ) and RTMP (proprietary, https://en.wikipedia.org/wiki/Real_Time_Messaging_Protocol ) protocols. There isn't even a package review ticket for the package, nor either of the two packages it depends on. To be honest, I'm not sure how this was considered ready for review. I'll update it in a couple of days. So far I've got this (somewhat outdated) package for those who is interested: * http://peter.fedorapeople.org/erlyvideo/erlyvideo-2.5.3-1.fc19.src.rpm -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Erlyvideo - add Erlyvideo video streaming server to the Fedora repositories
Hello All 2013/1/16 Jaroslav Reznik jrez...@redhat.com: Although I'm going to disable all MP4/AAC-transcoding features and support for patented streaming protocols, it still will be useful. Will it be possible to split it out to standalone package distributed by different means? Same as we do for example for GStreamer? Actually I'm not that interested in a proprietary mp4 part although I must admit that it's possible. My original plan was to 1. Add Erlyvideo to Fedora 2. Ensure it works with WebM 3. Consider bringing back missing functionality (with the aid of gstreamer instead of a direct ffmpeg invocation maybe). In fact I doubt a live Video transcoding from/to proprietary evil patented stuff will be incredibly popular feature so maybe #3 won't worth our efforts. -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
So there are a couple of issues with btrfs which I believe absolutely must be fixed before it can become the default I'd agree, though I'd have a different list of pet bugs. But that's a subjective judgement. I'd be the first to admit that I'm pretty risk averse, especially when it comes to losing data and rendering machines unbootable. Is there an existing set of criteria that Fedora would use to determine that btrfs is sufficiently reliable to use as the default for new installs? - z -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Wed, Jan 16, 2013 at 1:12 PM, Zach Brown z...@zabbo.net wrote: So there are a couple of issues with btrfs which I believe absolutely must be fixed before it can become the default I'd agree, though I'd have a different list of pet bugs. But that's a subjective judgement. I'd be the first to admit that I'm pretty risk averse, especially when it comes to losing data and rendering machines unbootable. Is there an existing set of criteria that Fedora would use to determine that btrfs is sufficiently reliable to use as the default for new installs? Not really. The de facto criteria would be as stable as the current default, which is ext4. That is also somewhat subjective. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 893464] Upgrade to new upstream version
Product: Fedora EPEL https://bugzilla.redhat.com/show_bug.cgi?id=893464 --- Comment #7 from Fedora Update System upda...@fedoraproject.org --- Package perl-Net-STOMP-Client-2.0-1.el5: * should fix your issue, * was pushed to the Fedora EPEL 5 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing perl-Net-STOMP-Client-2.0-1.el5' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-0092/perl-Net-STOMP-Client-2.0-1.el5 then log in and leave karma (feedback). -- 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=W9zlVyp1kKa=cc_unsubscribe -- 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 895876] Upgrade to new upstream version
Product: Fedora EPEL https://bugzilla.redhat.com/show_bug.cgi?id=895876 --- Comment #6 from Fedora Update System upda...@fedoraproject.org --- Package perl-No-Worries-0.8-1.el5: * should fix your issue, * was pushed to the Fedora EPEL 5 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing perl-No-Worries-0.8-1.el5' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-0090/perl-No-Worries-0.8-1.el5 then log in and leave karma (feedback). -- 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=oTivDSVe0Ca=cc_unsubscribe -- 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: MariaDB in Fedora
On 01/16/2013 04:55 PM, Tom Lane wrote: https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB We could use help with testing. Personally I'd like to dump mysql in time for F19, but we need validation that switching to maria doesn't break anything for anyone. Good news guys! I'll give OpenStack a shot. -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes for today's FESCo meeting (2013-01-16)
=== #fedora-meeting: FESCO (2013-01-16) === Meeting started by mmaslano at 18:01:37 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-01-16/fesco.2013-01-16-18.01.log.html . Meeting summary --- * init process (mmaslano, 18:01:57) * #992 F19 Feature: NodeJS - https://fedoraproject.org/wiki/Features/NodeJS (mmaslano, 18:04:56) * AGREED: NodeJS is approved; for the feature to be considered complete, packaging guidelines must be approved (+8,-0) (mmaslano, 18:17:50) * sgallagh will speak about guidelines with FPC (mmaslano, 18:18:29) * #993 F19 Feature: NetworkManagerCLIAddConnection - https://fedoraproject.org/wiki/Features/NetworkManagerCLIAddConnection (mmaslano, 18:20:07) * AGREED: NetworkManagerCLIAddConnection was accepted as F19 feature (+8,-0) (mmaslano, 18:23:17) * #990 F19 Feature: PHP 5.5 - https://fedoraproject.org/wiki/Features/Php55 (mmaslano, 18:23:25) * AGREED: PHP 5.5 was accepted as F19 feature (+9,-0) (mmaslano, 18:24:25) * #991 F19 Feature: PackageSignatureCheckingDuringOSInstall - https://fedoraproject.org/wiki/Features/PackageSignatureCheckingDuringOSInstall (mmaslano, 18:24:37) * LINK: https://fedoraproject.org/wiki/Secureboot#Questions_and_Answers (abadger1999, 18:32:13) * AGREED: Package Signature Checking During OS Install was accepted as F19 feature (+7,-0) (mmaslano, 18:40:13) * Next week's chair (mmaslano, 18:40:47) * ACTION: notting will chair next meeting (mmaslano, 18:41:25) * Open Floor (mmaslano, 18:41:31) * -devel or -devel-announce for discussion of features (mmaslano, 18:47:37) * jreznik will use in ticket link to devel instead of devel-announce (mmaslano, 18:51:05) * Open Floor (mmaslano, 18:51:24) Meeting ended at 19:05:05 UTC. Action Items * notting will chair next meeting Action Items, by person --- * notting * notting will chair next meeting * **UNASSIGNED** * (none) People Present (lines said) --- * mmaslano (57) * mitr (33) * nirik (31) * abadger1999 (29) * pjones (22) * t8m (20) * sgallagh (18) * jwb (18) * Viking-Ice (13) * zodbot (9) * notting (9) * dan408_ (5) * jreznik (4) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- 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
GCC 4.8.0 is going to be released in mid March to mid April and is currently in regression bugfix only mode. I've performed a test mass rebuild on x86_64 Looking at the schedule Wouldn't it be better to do the mass rebuild in Rawhide before the branch? If we're really looking at a second-half-of-May final release, that means beta testing ends the beginning of May, which possibly puts the window for the rebuild _after_ the beta release (let alone before the branch). If we're going to have a short F19 cycle, maybe this should be accepted now for F20 and happen in Rawhide after the branch. Or, if the F19 cycle is to be longer, maybe that's not an issue. Unless we're really confident that this won't cause problems. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 665901] Review Request: perl-Gravatar-URL - Make URLs for Gravatars from an email address
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=665901 Mario Blättermann mario.blaetterm...@gmail.com changed: What|Removed |Added Status|NEW |ASSIGNED Blocks|177841 (FE-NEEDSPONSOR) | Assignee|nob...@fedoraproject.org|mario.blaetterm...@gmail.co ||m Flags||fedora-review+ --- Comment #18 from Mario Blättermann mario.blaetterm...@gmail.com --- (In reply to comment #17) Could you take it again and re-set the flags? I'll submit an SCM request then. I don't know if this is allowed, because you are not the initial requester. Anyway, I reset the approval flag. -- 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=qAtc6vuhAVa=cc_unsubscribe -- 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: GCC48 - switch GCC in Fedora 19 to 4.8.x, rebuild all packages with it
On Wed, 16 Jan 2013 14:15:25 -0500 Matthew Miller mat...@fedoraproject.org wrote: GCC 4.8.0 is going to be released in mid March to mid April and is currently in regression bugfix only mode. I've performed a test mass rebuild on x86_64 Looking at the schedule Wouldn't it be better to do the mass rebuild in Rawhide before the branch? We always do this, yes. If we're really looking at a second-half-of-May final release, that means beta testing ends the beginning of May, which possibly puts the window for the rebuild _after_ the beta release (let alone before the branch). FESCo has not yet decided the schedule. We should nuke those stupid DRAFT sections, because they are just confusing people. If we're going to have a short F19 cycle, maybe this should be accepted now for F20 and happen in Rawhide after the branch. Or, if the F19 cycle is to be longer, maybe that's not an issue. Unless we're really confident that this won't cause problems. We need to decide the schedule soon IMHO. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 757089] cpanspec error: Dest dir longer than base dir is not supported
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=757089 Jan Pazdziora jpazdzi...@redhat.com changed: What|Removed |Added CC||jpazdzi...@redhat.com --- Comment #2 from Jan Pazdziora jpazdzi...@redhat.com --- With $ rpm -q cpanspec cpanspec-1.78-10.fc17.noarch I was able to run $ cpanspec --build --packager jezek Env-C-0.09.tar.gz Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.QJ1gPX + umask 022 + cd /tmp + cd /tmp [...] Wrote: /tmp/perl-Env-C-0.09-1.fc17.src.rpm Wrote: /tmp/i386/perl-Env-C-0.09-1.fc17.i386.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.FeV2iY + umask 022 + cd /tmp + cd Env-C-0.09 + rm -rf /home/adelton/rpmbuild/BUILDROOT/perl-Env-C-0.09-1.fc17.i386 + exit 0 $ -- 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=8N0DT3hZ33a=cc_unsubscribe -- 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: 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]: 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/GCC48 = https://fedoraproject.org/wiki/Features/GCC48 I would also like to mention that we at the Fedora MinGW SIG are also preparing on introducing GCC 4.8 for our win32/win64 cross-compiler (mingw-gcc). A test mass rebuild of all our 135 mingw-* packages is currently being performed. I'll report the results back to the Fedora MinGW and upstream mingw-w64 mailing lists once this test mass rebuild is completed so we can investigate and resolve the remaining issues. We plan on introducing mingw-gcc 4.8 in rawhide shortly after the native gcc package gets updated to 4.8. That way we'll be ready before the mass rebuild of all Fedora packages starts. 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: GCC48 - switch GCC in Fedora 19 to 4.8.x, rebuild all packages with it
On Wed, Jan 16, 2013 at 08:21:24PM +0100, Tomas Mraz wrote: On Wed, 2013-01-16 at 14:15 -0500, Matthew Miller wrote: GCC 4.8.0 is going to be released in mid March to mid April and is currently in regression bugfix only mode. I've performed a test mass rebuild on x86_64 Looking at the schedule Wouldn't it be better to do the mass rebuild in Rawhide before the branch? If we're really looking at a second-half-of-May final release, that means beta testing ends the beginning of May, which possibly puts the window for the rebuild _after_ the beta release (let alone before the branch). If we're going to have a short F19 cycle, maybe this should be accepted now for F20 and happen in Rawhide after the branch. Or, if the F19 cycle is to be longer, maybe that's not an issue. Unless we're really confident that this won't cause problems. I'd say that if FESCo accepts this feature for F19, it implicates making the F19 schedule long enough to accommodate the rebuild before branching. If this is decided upon soon, the gcc packages could be ready for a mass rebuild around end of January or even slightly earlier. The package is in git right now, but so far built just as scratch builds. Jakub -- 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 Wed, 2013-01-16 at 14:15 -0500, Matthew Miller wrote: GCC 4.8.0 is going to be released in mid March to mid April and is currently in regression bugfix only mode. I've performed a test mass rebuild on x86_64 Looking at the schedule Wouldn't it be better to do the mass rebuild in Rawhide before the branch? If we're really looking at a second-half-of-May final release, that means beta testing ends the beginning of May, which possibly puts the window for the rebuild _after_ the beta release (let alone before the branch). If we're going to have a short F19 cycle, maybe this should be accepted now for F20 and happen in Rawhide after the branch. Or, if the F19 cycle is to be longer, maybe that's not an issue. Unless we're really confident that this won't cause problems. I'd say that if FESCo accepts this feature for F19, it implicates making the F19 schedule long enough to accommodate the rebuild before branching. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 739461] Surprising value for --optimize in generated spec file
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=739461 Jan Pazdziora jpazdzi...@redhat.com changed: What|Removed |Added CC||jpazdzi...@redhat.com Version|16 |18 --- Comment #3 from Jan Pazdziora jpazdzi...@redhat.com --- (In reply to comment #1) That is fixed in the current git tree, which I'll be releasing as an update soon. For now, see https://github.com/silug/cpanspec Let me mark this as still not fixed in Fedora 18 -- the http://koji.fedoraproject.org/koji/packageinfo?packageID=1525 shows that there is no 1.79 build in the queue. -- 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=qvVxLwL88Ca=cc_unsubscribe -- 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: Strange Build problem....
On 16/01/13 12:27, Toshio Kuratomi wrote:
Looking at the F17 version of matplotlib, the default afm font is being set
to None there -- so a better fix (but requiring fixing in matplotlib) might
be to patch it like this:
--- /usr/lib64/python2.7/site-packages/matplotlib/font_manager.py
2012-12-04 21:32:42.0 -0500
+++ font_manager.py 2013-01-16 12:26:21.861202681 -0500
@@ -991,7 +991,10 @@
self.afmfiles = findSystemFonts(paths, fontext='afm') + \
findSystemFonts(fontext='afm')
self.afmlist = createFontList(self.afmfiles, fontext='afm')
-self.defaultFont['afm'] = self.afmfiles[0]
+try:
+self.defaultFont['afm'] = self.afmfiles[0]
+except IndexError:
+self.defaultFont['afm'] = None
self.ttf_lookup_cache = {}
self.afm_lookup_cache = {}
This does the trick! Thank you very much!
It turns out this is the patch the caused the problem:
commit eb9a122389b7ec7e33d9816fa669d7cb1f04521a
Author: pcpa paulo.cesar.pereira.de.andr...@gmail.com
Date: Wed Jan 16 13:59:10 2013 -0200
Use fontconfig by default (#885307)
CC-ing the author and created this bz:
https://bugzilla.redhat.com/show_bug.cgi?id=896182
Thanks again for you time and effort! It was definitely
appreciated!!
steved.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [Libjpeg-turbo-users] jpeg-9, API/ABI compatibility, and the future role of this project
On 16/01/13 16:55, Adam Tkac wrote: On Wed, Jan 16, 2013 at 01:02:57PM +0100, Michael Stahl wrote: On 15/01/13 20:04, Xose Vazquez Perez wrote: I hope other distributions don't use that release. FWIW i'm afraid i've had to build jpeg8 from source already to get a certain binary [1] built on Ubuntu to run on Fedora 17... [1] actually a git repo full of binaries: https://wiki.documentfoundation.org/Bibisect I read the link and it seems libjpeg62 is sufficient (i.e. jpeg6 ABI) for bibisect. So you should not need jpeg8 ABI. read more carefully then: the git repo contains binaries built against different Ubuntu baseline versions, the older of which have jpeg6 and the newer jpeg8. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Wed, Jan 16, 2013 at 10:12:34AM -0800, Zach Brown wrote: So there are a couple of issues with btrfs which I believe absolutely must be fixed before it can become the default I'd agree, though I'd have a different list of pet bugs. But that's a subjective judgement. I'd be the first to admit that I'm pretty risk averse, especially when it comes to losing data and rendering machines unbootable. I think both of us are making a subjective judgement. For myself, I want to believe in btrfs, having championed immutable state/wandering trees, and real databases for many years. BUT I'm deeply unhappy about data corrupting bugs being effectively ignored by upstream for months. That's not good. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Strange Build problem....
2013/1/16 Steve Dickson ste...@redhat.com:
On 16/01/13 12:27, Toshio Kuratomi wrote:
Looking at the F17 version of matplotlib, the default afm font is being set
to None there -- so a better fix (but requiring fixing in matplotlib) might
be to patch it like this:
--- /usr/lib64/python2.7/site-packages/matplotlib/font_manager.py
2012-12-04 21:32:42.0 -0500
+++ font_manager.py 2013-01-16 12:26:21.861202681 -0500
@@ -991,7 +991,10 @@
self.afmfiles = findSystemFonts(paths, fontext='afm') + \
findSystemFonts(fontext='afm')
self.afmlist = createFontList(self.afmfiles, fontext='afm')
-self.defaultFont['afm'] = self.afmfiles[0]
+try:
+self.defaultFont['afm'] = self.afmfiles[0]
+except IndexError:
+self.defaultFont['afm'] = None
self.ttf_lookup_cache = {}
self.afm_lookup_cache = {}
This does the trick! Thank you very much!
It turns out this is the patch the caused the problem:
commit eb9a122389b7ec7e33d9816fa669d7cb1f04521a
Author: pcpa paulo.cesar.pereira.de.andr...@gmail.com
Date: Wed Jan 16 13:59:10 2013 -0200
Use fontconfig by default (#885307)
Sorry for that problem. It solved the problems I was having
but created at least yours problem. I am having an almost live
conversation right now about related issues at
https://sourceforge.net/mailarchive/message.php?msg_id=30202451
right after posting the first test case result this was created:
https://github.com/matplotlib/matplotlib/pull/1666
if possible, can you check if the above patch corrects your
issue?
archives of mailing list not yet updated, but I have made several
runs of matplotlib test suite, with logs at:
http://pcpa.fedorapeople.org/matplotlib-2.7+pull-1666.txt
http://pcpa.fedorapeople.org/matplotlib-2.7-bundled-stix-ttf+fontconfig=false.txt
http://pcpa.fedorapeople.org/matplotlib-2.7-mpl-data-with-bundled-stix-ttf.txt
http://pcpa.fedorapeople.org/matplotlib-2.7.txt
http://pcpa.fedorapeople.org/matplotlib-3.3.txt
CC-ing the author and created this bz:
https://bugzilla.redhat.com/show_bug.cgi?id=896182
Thanks again for you time and effort! It was definitely
appreciated!!
steved.
Thanks,
Paulo
--
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 01/16/2013 11:19 AM, Kevin Fenzi wrote: We need to decide the schedule soon IMHO. Perhaps the schedule should be decided in part on time to do mass rebuild after gcc 4.8.0 is released. The ARM team would really like to see 4.8 in F19 because 4.8 is the first gcc with native Aarch64 support. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 892381] please pull perl-Sys-Syscall 0.25 into f18
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=892381 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-Sys-Syscall-0.25-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=nkvFRw3SR8a=cc_unsubscribe -- 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: Status to make btsfs to the standard filesystem of Fedora
On Wed, 16 Jan 2013 12:18:37 -0500 Josef Bacik jo...@toxicpanda.com wrote: I'm waiting until Anaconda settles down before I pursue btrfs in Fedora again. Things change too much and Btrfs is too reliant on the anaconda part working properly to even bother trying to push it through at this point. Thanks, Well, I hope we are entering a period of bugfixing and incremental improvement in anaconda since we have the new code in now. ;) FWIW, I installed with btrfs with the f18 installer and it worked fine. (encrypted volume with / and /home subvolumes). I kept /boot as ext4 due to a anaconda issue, which I think has already been fixed. So, you might want to talk to anaconda folks and get their feedback... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Ruby 2.0.0 - the latest stable version of Ruby, with major increases in speed and reliability
Jaroslav Reznik (jrez...@redhat.com) said: Yet, it is source level backward compatible with Ruby 1.9.3, so your software will continue to work. The updated Ruby also provides better integration with Fedora, especially JRuby. But not only JRuby, it is also one step closer to be prepared for other interpreters, such as Rubinius. Provided custom Ruby loader with working name rubypick [1] will allow to easily switch interpreters executing your script, provides fallback to whatever Ruby interpreter is available on you system, yet still keeps backward compatibility with all your Ruby scripts. Reading this, it's source compatible, but not binary compatible, so everything gets a rebuild? (IOW, akin to many python version updates). Do you need a side tag for it? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: BIND10 - next generation of the popular BIND9 DNS server rewritten from scratch
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/BIND 10 = https://fedoraproject.org/wiki/Features/BIND10 * Detailed description: BIND10 suite implements two crucial network services - DNS and DHCP. The BIND10 is going to replace both widely used ISC BIND9 and ISC DHCP4 software in the future. It is written from scratch and has modular design. And... dhcp6? I note that the feature page describes this as a parallel installable stack. Is there a reason to keep both versions around in a way we didn't with other bind major upgrades? Bill -- 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 Wed, Jan 16, 2013 at 11:52:04AM -0800, Brendan Conoboy wrote: On 01/16/2013 11:19 AM, Kevin Fenzi wrote: We need to decide the schedule soon IMHO. Perhaps the schedule should be decided in part on time to do mass rebuild after gcc 4.8.0 is released. The ARM team would really like to see 4.8 in F19 because 4.8 is the first gcc with native Aarch64 support. The mass rebuild doesn't have to be with a released compiler (and in fact, usually has been performed with a prerelease compiler), it is just important that the release is released with a released compiler. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Wed, Jan 16, 2013 at 1:50 PM, Richard W.M. Jones rjo...@redhat.comwrote: On Wed, Jan 16, 2013 at 10:12:34AM -0800, Zach Brown wrote: So there are a couple of issues with btrfs which I believe absolutely must be fixed before it can become the default I'd agree, though I'd have a different list of pet bugs. But that's a subjective judgement. I'd be the first to admit that I'm pretty risk averse, especially when it comes to losing data and rendering machines unbootable. I think both of us are making a subjective judgement. For myself, I want to believe in btrfs, having championed immutable state/wandering trees, and real databases for many years. BUT I'm deeply unhappy about data corrupting bugs being effectively ignored by upstream for months. That's not good. I see no data corruption bugs that have been reported that are being ignored, link to the email? The invalidate stuff was causing problems (not a btrfs problem, we just got hurt by it the most), and it looks like those were cleared up. I'm working on the only data corruption problem I know of at the moment and it's not super clear its a data corruption problem. Thanks, Josef -- 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 01/16/2013 12:31 PM, Jakub Jelinek wrote: The mass rebuild doesn't have to be with a released compiler (and in fact, usually has been performed with a prerelease compiler), it is just important that the release is released with a released compiler. Even better! Will the 3 failed builds mentioned at the beginning of the thread be resolved by the end-of-January estimated ready to go time? Are there any outstanding bugs in the 4.8-pre compiler that might have major impact on Fedora? If gcc 4.8 has progressed to the point that it's safe to use I'd love to see it done in F19. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- 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
- Original Message - On Wed, 16 Jan 2013 14:15:25 -0500 Matthew Miller mat...@fedoraproject.org wrote: GCC 4.8.0 is going to be released in mid March to mid April and is currently in regression bugfix only mode. I've performed a test mass rebuild on x86_64 Looking at the schedule Wouldn't it be better to do the mass rebuild in Rawhide before the branch? We always do this, yes. If we're really looking at a second-half-of-May final release, that means beta testing ends the beginning of May, which possibly puts the window for the rebuild _after_ the beta release (let alone before the branch). FESCo has not yet decided the schedule. We should nuke those stupid DRAFT sections, because they are just confusing people. Sure I can do that, I did not find a better way how to communicate the decision? Any better idea? As we still need some guidance for F19. It affects more teams. If we're going to have a short F19 cycle, maybe this should be accepted now for F20 and happen in Rawhide after the branch. Or, if the F19 cycle is to be longer, maybe that's not an issue. Unless we're really confident that this won't cause problems. We need to decide the schedule soon IMHO. I think at submission deadline we should have a good overview of what's probably getting in (even not every single feature will be approved by that time, as there's +1 week for announcement, some time to discuss it). I like the idea to do proper planning but it also blocks other teams and people starts complaining (the reason I wrote above we need at least some guidance so I'd like to avoid removing even this very sparse info). But I'm getting OT here - let's talk more about it at FUDCon. Btw. for scheduling, I asked Jakub today for details before announcing the Feature, I put his answer in a Talk page. But he already answered that (you see, I expected that question ;-), I just did not want to block announcement on that as I'd like to have it ready for next FESCo meeting (to make as much stuff done before departing for FUDCon, sorry). [18:26] jakub_ jreznik: as for scheduling, mid march/mid april is the gcc upstream release, it would land into Fedora within a few days from now, then voluntary rebuilding, after a few days or week or three full mass rebuild Jaroslav kevin -- 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: BIND10 - next generation of the popular BIND9 DNS server rewritten from scratch
On 01/16/2013 09:21 PM, Bill Nottingham wrote: I note that the feature page describes this as a parallel installable stack. Is there a reason to keep both versions around in a way we didn't with other bind major upgrades? As far as I understand it, it will take some time until BIND 10 reaches feature parity and things like DLZ modules have been ported from BIND 9. BIND 10 is completely different from BIND 9. It's not like a switch from BIND 9.7 to BIND 9.8, it's like going from BIND 8 to BIND 9. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [Libjpeg-turbo-users] jpeg-9, API/ABI compatibility, and the future role of this project
Michael Stahl mst...@redhat.com writes: read more carefully then: the git repo contains binaries built against different Ubuntu baseline versions, the older of which have jpeg6 and the newer jpeg8. [ shrug... ] So we'd be incompatible with some of them no matter what. But the bigger point is that we can't let Ubuntu make decisions for us about which versions of which packages Fedora is going to ship. Personally I concur with Adam's newfound opinion that jpeg8 is a dead end we shouldn't be going down. The original point of libjpeg (which succeeded beyond my wildest dreams really) was to promote universal JPEG file compatibility. The latest jpeg8 and jpeg9 versions are antithetical to that goal because they create nonstandard files that can't be read by standard implementations, including older libjpeg. If there were a huge improvement in compression performance maybe there'd be some chance of establishing a new de facto standard, but there isn't --- so this will accomplish little except to fragment the market. I don't think Fedora should be contributing to that, not even to the small extent of breaking ABI compatibility to be ABI-compatible with those library versions. regards, tom lane once organizer, Independent JPEG Group -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: BIND10 - next generation of the popular BIND9 DNS server rewritten from scratch
On Wed, 2013-01-16 at 15:21 -0500, Bill Nottingham wrote: 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/BIND 10 = https://fedoraproject.org/wiki/Features/BIND10 * Detailed description: BIND10 suite implements two crucial network services - DNS and DHCP. The BIND10 is going to replace both widely used ISC BIND9 and ISC DHCP4 software in the future. It is written from scratch and has modular design. And... dhcp6? I note that the feature page describes this as a parallel installable stack. Is there a reason to keep both versions around in a way we didn't with other bind major upgrades? Bind 10 is a completely new project. Shares no code nor anything with bind 9, they could as well have changed name to avoid confusion but they did not. It will take quite a while before bind10 will be usable as a replacement for bind9 for most use cases. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Static Analysis: proposed interchange format (firehose)
This is a followup to my proposal in http://lists.fedoraproject.org/pipermail/devel/2012-December/175232.html I want a common output format for static analysis tools so that we can easily slurp the results from different tools into a database and have a common system for managing the results (marking false positives, having automated de-duplication, etc). (I like the name firehose for the overall system since it describes the issue we'll have of managing the flood of data). I came up with an XML format, which I've uploaded code to here: https://github.com/fedora-static-analysis/firehose Does this look sane? I think that it should be possible to write converters that turn the output from other tools into this, and I think it's possible to hack up my static analyzers to emit this format. The firehose.py script is able to turn such an XML report into a text format mimicking what GCC emits, which is useful in Emacs (and probably other editors) which can parse that text format for clicking through to the underlying source code being tested. Thoughts? BTW, I hope to run a hackfest on Static Analysis in Fedora at FUDCon Lawrence this weekend. Anyone around? [there are plenty of different tasks requiring different skill sets: Python scripting, web development, etc - you don't need to know about compiler internals! though that would help also :) ] Dave -- 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 Wed, Jan 16, 2013 at 12:38:29PM -0800, Brendan Conoboy wrote: Even better! Will the 3 failed builds mentioned at the beginning of the thread be resolved by the end-of-January estimated ready to go time? Are there any outstanding bugs in the 4.8-pre compiler that might have major impact on Fedora? If gcc 4.8 has progressed to the point that it's safe to use I'd love to see it done in F19. Two of the issues are resolved already, one (--with-lto issue in some game) probably not, but so difficult to reduce that it is probably better to suggest not using LTO there for now. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: BIND10 - next generation of the popular BIND9 DNS server rewritten from scratch
On Wed, Jan 16, 2013 at 03:21:41PM -0500, Bill Nottingham wrote: 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/BIND 10 = https://fedoraproject.org/wiki/Features/BIND10 * Detailed description: BIND10 suite implements two crucial network services - DNS and DHCP. The BIND10 is going to replace both widely used ISC BIND9 and ISC DHCP4 software in the future. It is written from scratch and has modular design. And... dhcp6? Ah, with DHCP4 I meant DHCP 4.X.X, not IPv4 DHCP, sorry for bad description. BIND10 of course supports both IPv4 and IPv6 DHCP protocols. I removed the 4 suffix on wiki to avoid confusions. I note that the feature page describes this as a parallel installable stack. Is there a reason to keep both versions around in a way we didn't with other bind major upgrades? Yes because there is _no_ backward compatibility with current bind9. Configuration is completely different, management is completely different etc... People definitely need some time for testing and transition to bind10. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: BIND10 - next generation of the popular BIND9 DNS server rewritten from scratch
On Wed, 2013-01-16 at 21:55 +0100, Adam Tkac wrote: On Wed, Jan 16, 2013 at 03:21:41PM -0500, Bill Nottingham wrote: 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/BIND 10 = https://fedoraproject.org/wiki/Features/BIND10 * Detailed description: BIND10 suite implements two crucial network services - DNS and DHCP. The BIND10 is going to replace both widely used ISC BIND9 and ISC DHCP4 software in the future. It is written from scratch and has modular design. And... dhcp6? Ah, with DHCP4 I meant DHCP 4.X.X, not IPv4 DHCP, sorry for bad description. BIND10 of course supports both IPv4 and IPv6 DHCP protocols. I removed the 4 suffix on wiki to avoid confusions. I note that the feature page describes this as a parallel installable stack. Is there a reason to keep both versions around in a way we didn't with other bind major upgrades? Yes because there is _no_ backward compatibility with current bind9. Configuration is completely different, management is completely different etc... People definitely need some time for testing and transition to bind10. It is not only a matter of configuration, is bind10 going to be pluggable ? FreeIPA with bind-dynd-ldap depends on bind9 and will require some major work to port it to bind10 ... or something else. In the meanwhile it will depend on bind9 being available in the distribution. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: BIND10 - next generation of the popular BIND9 DNS server rewritten from scratch
On Wed, Jan 16, 2013 at 03:59:10PM -0500, Simo Sorce wrote: On Wed, 2013-01-16 at 21:55 +0100, Adam Tkac wrote: On Wed, Jan 16, 2013 at 03:21:41PM -0500, Bill Nottingham wrote: 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/BIND 10 = https://fedoraproject.org/wiki/Features/BIND10 * Detailed description: BIND10 suite implements two crucial network services - DNS and DHCP. The BIND10 is going to replace both widely used ISC BIND9 and ISC DHCP4 software in the future. It is written from scratch and has modular design. And... dhcp6? Ah, with DHCP4 I meant DHCP 4.X.X, not IPv4 DHCP, sorry for bad description. BIND10 of course supports both IPv4 and IPv6 DHCP protocols. I removed the 4 suffix on wiki to avoid confusions. I note that the feature page describes this as a parallel installable stack. Is there a reason to keep both versions around in a way we didn't with other bind major upgrades? Yes because there is _no_ backward compatibility with current bind9. Configuration is completely different, management is completely different etc... People definitely need some time for testing and transition to bind10. It is not only a matter of configuration, is bind10 going to be pluggable ? FreeIPA with bind-dynd-ldap depends on bind9 and will require some major work to port it to bind10 ... or something else. In the meanwhile it will depend on bind9 being available in the distribution. Yes, it is going to be pluggable but it doesn't have any API for modules, yet. Upstream is currently busy with work on core DNS/DHCP daemons. But they design bind10 with plugins in mind. Btw about transition time, it definitely won't happen in ~1 year. I guess transition can take ~5 years, so you don't have to bother that bind9 will dissapear during next 5 - 10 Fedora releases... Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Wed, Jan 16, 2013 at 03:36:10PM -0500, Josef Bacik wrote: On Wed, Jan 16, 2013 at 1:50 PM, Richard W.M. Jones rjo...@redhat.comwrote: On Wed, Jan 16, 2013 at 10:12:34AM -0800, Zach Brown wrote: So there are a couple of issues with btrfs which I believe absolutely must be fixed before it can become the default I'd agree, though I'd have a different list of pet bugs. But that's a subjective judgement. I'd be the first to admit that I'm pretty risk averse, especially when it comes to losing data and rendering machines unbootable. I think both of us are making a subjective judgement. For myself, I want to believe in btrfs, having championed immutable state/wandering trees, and real databases for many years. BUT I'm deeply unhappy about data corrupting bugs being effectively ignored by upstream for months. That's not good. I see no data corruption bugs that have been reported that are being ignored, link to the email? The invalidate stuff was causing problems (not a btrfs problem, we just got hurt by it the most), and it looks like those were cleared up. I'm working on the only data corruption problem I know of at the moment and it's not super clear its a data corruption problem. The link is: https://bugzilla.redhat.com/show_bug.cgi?id=863978 Reported upstream here: http://thread.gmane.org/gmane.comp.file-systems.btrfs/20257 I'd love this to have been fixed upstream somewhere. It is still affecting Fedora, but we can pull in the fix if you can point to it. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Wed, Jan 16, 2013 at 9:11 PM, Richard W.M. Jones rjo...@redhat.comwrote: On Wed, Jan 16, 2013 at 03:36:10PM -0500, Josef Bacik wrote: On Wed, Jan 16, 2013 at 1:50 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Jan 16, 2013 at 10:12:34AM -0800, Zach Brown wrote: So there are a couple of issues with btrfs which I believe absolutely must be fixed before it can become the default I'd agree, though I'd have a different list of pet bugs. But that's a subjective judgement. I'd be the first to admit that I'm pretty risk averse, especially when it comes to losing data and rendering machines unbootable. I think both of us are making a subjective judgement. For myself, I want to believe in btrfs, having championed immutable state/wandering trees, and real databases for many years. BUT I'm deeply unhappy about data corrupting bugs being effectively ignored by upstream for months. That's not good. I see no data corruption bugs that have been reported that are being ignored, link to the email? The invalidate stuff was causing problems (not a btrfs problem, we just got hurt by it the most), and it looks like those were cleared up. I'm working on the only data corruption problem I know of at the moment and it's not super clear its a data corruption problem. The link is: https://bugzilla.redhat.com/show_bug.cgi?id=863978 Reported upstream here: http://thread.gmane.org/gmane.comp.file-systems.btrfs/20257 I'd love this to have been fixed upstream somewhere. It is still affecting Fedora, but we can pull in the fix if you can point to it. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Maybe is not good idea. Wait when btrfs launch officialy a least 1 stable version, because nothing 1 release yet. -- Álvaro Castillo Fedora Project, EMEA ambassador http://fedoraproject.org/wiki/User:Netsys Linux user #547784 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Wed, 2013-01-16 at 13:17 -0700, Kevin Fenzi wrote: On Wed, 16 Jan 2013 12:18:37 -0500 Josef Bacik jo...@toxicpanda.com wrote: I'm waiting until Anaconda settles down before I pursue btrfs in Fedora again. Things change too much and Btrfs is too reliant on the anaconda part working properly to even bother trying to push it through at this point. Thanks, Well, I hope we are entering a period of bugfixing and incremental improvement in anaconda since we have the new code in now. ;) FWIW, I installed with btrfs with the f18 installer and it worked fine. (encrypted volume with / and /home subvolumes). I kept /boot as ext4 due to a anaconda issue, which I think has already been fixed. So, you might want to talk to anaconda folks and get their feedback... kevin Did the root volume (/) Go into it's own subvolume, or is root just in /? If root isn't placed into a subvolume, say /root then mounted as /dev/sda1 subvolid=255 / lets say, you can't snapshot the root fs, which defeats the whole point of using btrfs . -- Sincerely, William Brown pgp.mit.edu http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x3C0AC6DAB2F928A2 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Thu, 17 Jan 2013 07:46:34 +1030 William Brown will...@firstyear.id.au wrote: Did the root volume (/) Go into it's own subvolume, or is root just in /? If root isn't placed into a subvolume, say /root then mounted as /dev/sda1 subvolid=255 / lets say, you can't snapshot the root fs, which defeats the whole point of using btrfs . # btrfs subvolume list -a / ID 256 gen 56580 top level 5 path FS_TREE/home ID 258 gen 56580 top level 5 path FS_TREE/root ID 1226 gen 55781 top level 258 path .snapshots/2013-01-16--07-00-02-@hourly ID 1227 gen 55781 top level 5 path FS_TREE/home/.snapshots/2013-01-16--07-00-02-@hourly ID 1229 gen 55890 top level 5 path FS_TREE/home/.snapshots/2013-01-16--08-00-01-@hourly ID 1230 gen 55891 top level 258 path .snapshots/2013-01-16--08-00-01-@hourly ID 1232 gen 55999 top level 258 path .snapshots/2013-01-16--09-00-02-@hourly ID 1233 gen 55999 top level 5 path FS_TREE/home/.snapshots/2013-01-16--09-00-02-@hourly ID 1234 gen 56109 top level 5 path FS_TREE/home/.snapshots/2013-01-16--10-00-01-@hourly ID 1235 gen 56109 top level 258 path .snapshots/2013-01-16--10-00-01-@hourly ID 1236 gen 56220 top level 5 path FS_TREE/home/.snapshots/2013-01-16--11-00-01-@hourly ID 1237 gen 56220 top level 258 path .snapshots/2013-01-16--11-00-01-@hourly ID 1238 gen 56327 top level 258 path .snapshots/2013-01-16--12-00-01-@hourly ID 1239 gen 56327 top level 5 path FS_TREE/home/.snapshots/2013-01-16--12-00-01-@hourly ID 1240 gen 56438 top level 258 path .snapshots/2013-01-16--13-00-01-@hourly ID 1241 gen 56438 top level 5 path FS_TREE/home/.snapshots/2013-01-16--13-00-01-@hourly ID 1242 gen 56549 top level 5 path FS_TREE/home/.snapshots/2013-01-16--14-00-01-@hourly ID 1243 gen 56549 top level 258 path .snapshots/2013-01-16--14-00-01-@hourly ... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
