Proposed F19 Feature: Syslinux Option
by Jaroslav Reznik
= Features/SyslinuxOption =
https://fedoraproject.org/wiki/Features/SyslinuxOption
Feature owner(s): Matthew Miller <mattdm(a)fedoraproject.org>
This feature will make Syslinux an optional bootloader for Fedora, in
kickstart and via a hidden Anaconda option. When used this way, it will
replace grub2.
== Detailed description ==
The Syslinux bootloader has been part of Fedora for over a decade. It's been
well-tested as the loader for the installer, but we've always used something
else on the installed OS. Newer versions of Syslinux (in the form of a version
called Extlinux) can boot from ext2/3/4 or from btrfs.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 3 months
Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
by Jaroslav Reznik
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_syst...
[2] https://github.com/bkabrda/rubypick
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 3 months
Status to make btsfs to the standard filesystem of Fedora
by Jochen Schmitt
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
11 years, 3 months
Summary/Minutes for today's FESCo meeting (2013-01-09)
by Josh Boyer
===================================
#fedora-meeting: FESCO (2013-01-09)
===================================
Meeting started by jwb at 18:00:38 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2013-01-09/fesco.2013-01-...
.
Meeting summary
---------------
* init process (jwb, 18:00:39)
* #896 Refine Feature process (jwb, 18:02:32)
* LINK: https://fedorahosted.org/fesco/ticket/896 (jwb, 18:02:33)
* AGREED: As a stop-gap for Fedora 19, FESCo will vote en bloc on
Features that do not have an explicit question/objection
(+:8,0:1,-:0) (jwb, 18:12:53)
* Features can be revisited if later questions arise (jwb, 18:13:59)
* #963 change of names of configuration files (jwb, 18:15:11)
* LINK: https://fedorahosted.org/fesco/ticket/963 (jwb, 18:15:12)
* AGREED: firstboot is fixed so closing the ticket out and maintainers
can fix remaining in the normal cycle (+:9,0:0,-:0) (jwb, 18:17:18)
* LINK: https://fedoraproject.org/wiki/User:Mitr/SystemwideFeatures
already contains this in the "scope" section (mitr, 18:20:48)
* #984 F19 Feature: 3D Printing - (jwb, 18:24:35)
* LINK: https://fedoraproject.org/wiki/Features/3D_Printing (jwb,
18:24:35)
* LINK: https://fedorahosted.org/fesco/ticket/984 (jwb, 18:24:35)
* LINK:
http://lists.fedoraproject.org/pipermail/devel/2013-January/175770.html
(jwb, 18:24:36)
* AGREED: F19 Feature: 3D Printing is accepted as a Feature
(+:8,0:0,-:0) (jwb, 18:26:33)
* #985 F19 Feature: Pillow -
https://fedoraproject.org/wiki/Features/Pillow (jwb, 18:26:41)
* LINK: https://fedorahosted.org/fesco/ticket/985 (jwb, 18:26:46)
* LINK:
http://lists.fedoraproject.org/pipermail/devel/2013-January/175769.html
(jwb, 18:26:49)
* AGREED: F19 Feature: Pillow is accepted as a Feature (+:9,0:0,-:0)
(jwb, 18:32:18)
* abadger1999 will help coordinate the porting effort (jwb, 18:32:38)
* #986 F19 Feature: DualstackNetworking - (jwb, 18:32:55)
* LINK: https://fedoraproject.org/wiki/Features/DualstackNetworking
(jwb, 18:32:56)
* LINK: https://fedorahosted.org/fesco/ticket/986 (jwb, 18:32:56)
* LINK:
http://lists.fedoraproject.org/pipermail/devel/2013-January/175773.html
(jwb, 18:32:56)
* AGREED: F19 DualstackNetworking is deferred as the feature is too
vague and it is not clear that this is more than a general
improvement in existing IPv6/dual stack support (+:8,0:0,-:0) (jwb,
18:39:55)
* It would be good to highlight the existing tracking bugs more
prominently (jwb, 18:40:28)
* Next Week's Chair (jwb, 18:41:10)
* AGREED: mmaslano to chair next week (jwb, 18:41:29)
* Open Floor (jwb, 18:41:32)
* AGREED: Next week's FESCo meeting will be new F19 Features only
(jwb, 18:45:57)
* LINK: https://fedorahosted.org/fesco/ticket/988 (nirik, 18:50:44)
Meeting ended at 18:58:33 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* jwb (105)
* nirik (53)
* pjones (34)
* sgallagh (33)
* mitr (25)
* mmaslano (18)
* abadger1999 (18)
* t8m (16)
* notting (12)
* jreznik (11)
* zodbot (9)
* Viking-Ice (5)
* adamw (4)
* tflink (3)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
11 years, 3 months
Re: Proposed F19 Feature: Replace MySQL with MariaDB
by Norvald H. Ryeng
----- Fedora(a)FamilleCollet.com wrote:
> Le 24/01/2013 02:49, Andrew Rist a écrit :
> > We've been following the discussions to replace MySQL with MariaDB
> ...
>
> /me speaking from my experience.
>
> I don't maintain MySQL, but various other mysql packages
> (mysql-utilities, mysql-connector-python, mysql-workbench, ...).
>
> Maintaining Oracle stuff in Fedora becomes a nightmare.
>
> Every new release introduce new issues, mostly because there is a lack
> of communication (upstream and downstream)
Hi,
I'm sorry to hear about the lack of communication. I'm a MySQL
developer, and for the last year I've been working with different
packagers. Linux distributions are an important part of our community,
and we'd like very much to hear your feedback and help make package
maintainers' lives easier. We've had a really constructive cooperation
on MySQL with Debian and Ubuntu the last year, and I am hoping we can
extend that to Fedora and other distributions. Please let me know how I
can help and be a direct connection to MySQL Engineering, bypassing all
the FUD currently out there.
This goes for both MySQL Server and related packages, such as those you
maintain.
Regards,
Norvald H. Ryeng
11 years, 3 months
wayland and broadway support in gtk
by Matthias Clasen
Hi,
I'm tentatively planning to enable the Wayland and Broadway backends in GTK+ for f19.
>From a quick test build, this adds 3 library dependencies to gtk (libwayland-client, libwayland-cursor and libxkbcommon), and the size of libgdk grows from ~550k to ~700k. I think this is not a terrible burden, and this will make it much easier to experiment with Wayland and Broadway in Fedora.
Comments ?
Matthias
11 years, 3 months
Re: Proposed F19 Feature: Ryu - Network Operating System
by Isaku Yamahata
Hi Pete.
> On Wed, 23 Jan 2013 15:25:53 +0000
> Jaroslav Reznik <jreznik at redhat.com> wrote:
>
> > Currently, Ryu manages network devices by using OpenFlow. You
> > can say that Ryu is an OpenFlow Controller.
>
> I'm just curious about something. Not saying if we need or do not need
> Ryu in Fedora, I notice that Ryu attempts to insert itself between
> OpenStack and OpenVSwitch (or actually anything that implements OpenFlow).
> What's the purpose of adding the layer, and how is it different from
> what Quantum is doing now? There has to be some kind of specific benefit.
>
> -- Pete
Quantum has many plugins supporting many technologies.
LinuxBridge, Open vSwitch(OVS), several OpenFlow controllers (including Ryu)
and several hardware switches.
Ryu has no conceptual difference from other OVS-based OpenFlow plugins from
bird's view.
I suppose you're talking about the difference from plain Open vSwitch plugin.
Open vSwitch (any OpenFlow switch in fact) is basically designed to function
better with OpenFlow controller.
Plain OVS plugin doesn't use OpenFlow controller. So it's rather static and
utilizes small subset of OVS. For example, it doesn't react to network usage
dynamically.
On the other hand, Ryu can control OVS in finer way. For example, it provides
centralized monitoring of OVS switch.
Ryu can provides more functionality. Currently it provides three ways
for L2-isolation for tenants mac address based, vlan and GRE tunneling.
(And vxlan coming)
Potentially Ryu can control not oly OVS and but also hardware OpenFlow
switches and optimize network based on its usage(bandwith, lantecy...).
In fact, those discussion can apply to all other OVS-based OpenFlow plugins
in principle and that's the reason why Quantum has many such plugins and
many people are trying to push their OF-plugin into Quantum.
--
yamahata
11 years, 3 months
Stalled review of pg_journal
by Tomasz Torcz
Hi,
There is some stall with the review of pg_journal:
https://bugzilla.redhat.com/show_bug.cgi?id=856560
which is journal-logging add-on for PostgreSQL.
I've addresed all the issues and upstream is really helpful, but
the reviewer dissapeared. Can I have moved the review forward?
Thanks,
--
Tomasz Torcz "Funeral in the morning, IDE hacking
xmpp: zdzichubg(a)chrome.pl in the afternoon and evening." - Alan Cox
11 years, 3 months
