Re: Fedora Present and Future: a Fedora.next 2014 Update (Part II, “What’s Happening?”)

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/30/2014 11:00 AM, Richard W.M. Jones wrote:
> On Fri, Mar 28, 2014 at 01:11:58PM -0400, Matthew Miller wrote:
>> I promised a while ago that I would provide a text version of my
>> talk at DevConf, for people who couldn't make it and because
>> sitting through a video of me standing up there going on and on
>> doesn't really make for good followup discussion.
>> 
>> I posted a link to the first part last week:
>> 
>> 
>>
>>
>> 
and now, Part II:
>> 
>> 
>>
>>
>> 
And as I said last week, I will take questions, comments, complaints, in any
>> media including replies here, on the article, on the social
>> media, or at any bar or coffee shop within walking distance of
>> Boston's MBTA.
> 
> So first I'll say these are interesting articles, and I encourage 
> people to read them.
> 
> I work better when I see some examples of what this would mean in 
> practice.  Under Fedora.next, how & where would you see the
> following being packaged?
> 
> - libvirt
> 
> Big, with lots and lots of big dependencies, but for
> virtualization it's pretty much the definition of a core, stable
> API.
> 

libvirt is one of those pieces that we need to settle on its
positioning. At the absolute minimum, the Fedora Server will almost
certainly declare it part of our guaranteed API. Given its
wide-ranging utility, I'd also like to see it as part of the Base
Design (which means that it is assumed to be a guaranteed API
available to all Products).


> - virt-manager
> 
> An application written in Python, and therefore needing to be
> "above" the stacks layer, I think?
> 

As Matthew noted: these are *policy* rings, not packaging. The idea is
that each ring could conceivably carry different policies, such as
applications that are outside this layer being given relaxed rules
(e.g. bundling exceptions in the outer rings could be assumed rather
than FPC-approved, provided that the RPM includes "Provides:
bundled(libfoo)")[1]




> - VLC
> 
> Free software video player, but with a requirement (or at least
> can use if available) proprietary / patented / ugly / semi-legal
> codecs. Currently packaged in RPMFusion for reasons I'm not clear
> on.
> 

I think it's packaged in RPMFusion because it contains an
implementation of a CSS decoder but I could be mistaken.



[1] Note: this is not an approved proposal, but it's one I'm
personally in favor of.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlM5VMcACgkQeiVVYja6o6MX9QCeMbkGUNhWr0yMbZvzomJ+bbD8
1M0AnirwkNvoXJbJsbsfq9APN09cq1FO
=ZR40
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F21 Self Contained Change: Apache Oozie

[Jaroslav Reznik]

= Proposed Self Contained Change: Apache Oozie =
https://fedoraproject.org/wiki/Changes/ApacheOozie

Change owner(s): Robert Rati   

Apache Oozie [1] is a workflow scheduler system to manage Apache Hadoop jobs. 

== Detailed Description ==
Apache Oozie is a workflow scheduler. It is integrated with the rest of the 
Hadoop stack and supports several types of Hadoop jobs out of the box (such as 
Java map-reduce, Streaming map-reduce, Pig, Hive, Sqoop and Distcp) as well as 
system specific jobs (such as Java programs and shell scripts). 

== Scope ==
* Proposal owners: Apache Oozie is packaged and awaiting review [2].
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change) 

[1] http://oozie.apache.org/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1071456
___
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 Code of Conduct: http://fedoraproject.org/code-of-conduct

F21 Self Contained Change: Apache HBase

[Jaroslav Reznik]

= Proposed Self Contained Change: Apache HBase =
https://fedoraproject.org/wiki/Changes/ApacheHBase

Change owner(s): Robert Rati   

Apache HBase [1] is a distributed database built on top of Apache Hadoop. 

== Detailed Description ==
Apache HBase is used when you need random, realtime read/write access to your 
Big Data. Apache HBase hosts very large tables -- billions of rows X millions 
of columns -- atop clusters of commodity hardware. Apache HBase is a 
distributed, versioned, non-relational database modeled after Google's 
Bigtable: A Distributed Storage System for Structured Data by Chang et al. 
Just as Bigtable leverages the distributed data storage provided by the Google 
File System, Apache HBase provides Bigtable-like capabilities on top of Hadoop 
and HDFS. 

== Scope ==
* Proposal owners: The Hbase package has been accepted into Fedora and 
provides all the functionality from the upstream release.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change) 

[1] http://hbase.apache.org/
___
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 Code of Conduct: http://fedoraproject.org/code-of-conduct

F21 Self Contained Change: Apache Hive

[Jaroslav Reznik]

= Proposed Self Contained Change: Apache Hive =
https://fedoraproject.org/wiki/Changes/ApacheHive

Change owner(s):  Peter MacKinnon 

Apache Hive [1] is a data warehouse built on top of Apache Hadoop. 

== Detailed Description ==
The Apache Hive data warehouse software facilitates querying and managing 
large datasets residing in distributed storage. Apache Hive provides a 
mechanism to project structure onto this data and query the data using a SQL-
like language called HiveQL.

== Scope ==
* Proposal owners: The Hive package has been accepted into Fedora and provides 
all the functionality from the upstream release with the exception of HBase 
support since the latest stable versions are not currently aligned.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change) 

[1] http://hive.apache.org/
___
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 Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Present and Future: a Fedora.next 2014 Update (Part II, "What's Happening?")

[Josh Boyer]

On Mon, Mar 31, 2014 at 7:43 AM, Stephen Gallagher  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/30/2014 11:00 AM, Richard W.M. Jones wrote:
>> On Fri, Mar 28, 2014 at 01:11:58PM -0400, Matthew Miller wrote:
>>> I promised a while ago that I would provide a text version of my
>>> talk at DevConf, for people who couldn't make it and because
>>> sitting through a video of me standing up there going on and on
>>> doesn't really make for good followup discussion.
>>>
>>> I posted a link to the first part last week:
>>>
>>> 
>>>
>>>
>>>
> and now, Part II:
>>>
>>> 
>>>
>>>
>>>
> And as I said last week, I will take questions, comments, complaints, in any
>>> media including replies here, on the article, on the social
>>> media, or at any bar or coffee shop within walking distance of
>>> Boston's MBTA.
>>
>> So first I'll say these are interesting articles, and I encourage
>> people to read them.
>>
>> I work better when I see some examples of what this would mean in
>> practice.  Under Fedora.next, how & where would you see the
>> following being packaged?
>>
>> - libvirt
>>
>> Big, with lots and lots of big dependencies, but for
>> virtualization it's pretty much the definition of a core, stable
>> API.
>>
>
> libvirt is one of those pieces that we need to settle on its
> positioning. At the absolute minimum, the Fedora Server will almost
> certainly declare it part of our guaranteed API. Given its
> wide-ranging utility, I'd also like to see it as part of the Base
> Design (which means that it is assumed to be a guaranteed API
> available to all Products).

Workstation will require this too.  Having it be in Base is a good idea.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Present and Future: a Fedora.next 2014 Update (Part II, “What’s Happening?”)

[Matthew Miller]

On Sun, Mar 30, 2014 at 04:00:28PM +0100, Richard W.M. Jones wrote:
> So first I'll say these are interesting articles, and I encourage
> people to read them.

Thanks!

> I work better when I see some examples of what this would mean in
> practice.  Under Fedora.next, how & where would you see the following
> being packaged?
>  - libvirt
> Big, with lots and lots of big dependencies, but for virtualization
> it's pretty much the definition of a core, stable API.

Yeah, all of those dependencies present a problem, because some of those are
pretty fast moving. I think conceptually, in the modern world where
virtualization is everwhere, it belongs in the base. (I think certainly both
the server and workstation products will want it, and possibly cloud in some
cases.) The Base WG is trying to define a self-hosting core, though, and
it's possible that it'd be better for this to live outside of that.

>  - virt-manager
> An application written in Python, and therefore needing to be "above"
> the stacks layer, I think?

Right, that is more clear.




-- 
Matthew Miller--   Fedora Project--
  "Tepid change for the somewhat better!"
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Present and Future: a Fedora.next 2014 Update (Part II, "What's Happening?")

[Jaroslav Reznik]

- Original Message -
> On Mon, Mar 31, 2014 at 7:43 AM, Stephen Gallagher 
> wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 03/30/2014 11:00 AM, Richard W.M. Jones wrote:
> >> On Fri, Mar 28, 2014 at 01:11:58PM -0400, Matthew Miller wrote:
> >>> I promised a while ago that I would provide a text version of my
> >>> talk at DevConf, for people who couldn't make it and because
> >>> sitting through a video of me standing up there going on and on
> >>> doesn't really make for good followup discussion.
> >>>
> >>> I posted a link to the first part last week:
> >>>
> >>> 
> >>>
> >>>
> >>>
> > and now, Part II:
> >>>
> >>> 
> >>>
> >>>
> >>>
> > And as I said last week, I will take questions, comments, complaints, in
> > any
> >>> media including replies here, on the article, on the social
> >>> media, or at any bar or coffee shop within walking distance of
> >>> Boston's MBTA.
> >>
> >> So first I'll say these are interesting articles, and I encourage
> >> people to read them.
> >>
> >> I work better when I see some examples of what this would mean in
> >> practice.  Under Fedora.next, how & where would you see the
> >> following being packaged?
> >>
> >> - libvirt
> >>
> >> Big, with lots and lots of big dependencies, but for
> >> virtualization it's pretty much the definition of a core, stable
> >> API.
> >>
> >
> > libvirt is one of those pieces that we need to settle on its
> > positioning. At the absolute minimum, the Fedora Server will almost
> > certainly declare it part of our guaranteed API. Given its
> > wide-ranging utility, I'd also like to see it as part of the Base
> > Design (which means that it is assumed to be a guaranteed API
> > available to all Products).
> 
> Workstation will require this too.  Having it be in Base is a good idea.

Makes sense for base, as with libvirt we're close to containers.

Jaroslav

> 
> josh
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Present and Future: a Fedora.next 2014 Update (Part II, "What's Happening?")

[Jóhann B. Guðmundsson]

On 03/31/2014 12:38 PM, Josh Boyer wrote:

Workstation will require this too.  Having it be in Base is a good idea.


If there emerges a WG that does not require this from WG then what and 
was not base limiting itself to it's already defined package set?



JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Present and Future: a Fedora.next 2014 Update (Part II, "What's Happening?")

[Jaroslav Reznik]

- Original Message -
> 
> On 03/31/2014 12:38 PM, Josh Boyer wrote:
> > Workstation will require this too.  Having it be in Base is a good idea.
> 
> If there emerges a WG that does not require this from WG then what and
> was not base limiting itself to it's already defined package set?

Base is common platform for products but it does not mean everything has
to be used by other products or everything has to follow base path (for
example installer is part of Base as we agreed but it can diverge a lot
over products, and even it would not be used in all products explicitely
just to provide images - cloud). Of course if some technology gets
obsoleted/deprecated by most of products, it means the time to deprecate
it in Base comes (or change of the owner). So common sense, not exact
numbers :).

Jaroslav

> 
> JBG
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F21 System Wide Change: GCC49

[Jaroslav Reznik]

= Proposed System Wide Change:  GCC49 =
https://fedoraproject.org/wiki/Changes/GCC49

Change owner(s): Jakub Jelínek  

Switch GCC in Fedora 21 to 4.9.x, rebuild all packages with it. 

== Detailed Description ==
GCC 4.9.0 is currently in stage4, in prerelease state with only regression 
bugfixes and documentation fixes allowed. The release will happen probably in 
the first half of April. Marek Polacek has performed a test mass rebuild on 
x86_64 with gcc-4.9.0-0.*.fc21, most packages have built successfully, others 
have failed to rebuild also with gcc 4.8.x, for the remaining packages most of 
the needed changes are now tracked in [1] or, if it were bugs on the gcc side, 
have been fixed in the mean time. GCC 4.9.0 prereleases have so far been built 
as scratch packages, [2]  (and similarly for ppc* and s390* secondary 
architectures). Other distributions have performed test mass rebuilds on other 
architectures (i?86, s390x, arm). 

== Scope ==
All packages should be rebuilt with the new gcc once it hits f21.

* Proposal owners:  Build gcc in f21, rebuild packages that have direct 
dependencies on exact gcc version (libtool, llvm, gcc-python-plugin).
* Other developers: First few days/weeks just voluntary rebuilds using the new 
system gcc, if things fail, look at http://gcc.gnu.org/gcc-4.9/porting_to.html 
and fix bugs in packages or, if there is a gcc bug or suspected gcc bug, 
analyze and report. 
* Release engineering: Organize a mass rebuild 
* Policies and guidelines: No policies need to be changed 

---
Change Wrangler Note: Contingency Deadline is a bit vague "Before release" but 
with GCC revert, distribution wide coordination would be needed with high 
probability of slip. I'll open it for further discussion on list for 
FESCo/releng..

[1] http://gcc.gnu.org/gcc-4.9/porting_to.html 
[2] http://koji.fedoraproject.org/scratch/jakub/task_6667028/
___
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 Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: RFC: httpd-filesystem proposal

[Joe Orton]

On Thu, Mar 27, 2014 at 07:55:19AM -0400, Matthew Miller wrote:
> I don't think gnome-user-share is installed by default anymore (or used by
> anyone?), but maybe we could finally really solve
> , while we are at it. :)

I still don't really know what is required there other than "make httpd 
smaller".  There are probably a few small things we can do there but I 
don't know of anything which could make a big difference.

Regards, Joe
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: RFC: httpd-filesystem proposal

[Matthew Miller]

On Mon, Mar 31, 2014 at 02:02:28PM +0100, Joe Orton wrote:
> > I don't think gnome-user-share is installed by default anymore (or used by
> > anyone?), but maybe we could finally really solve
> > , while we are at it. :)
> I still don't really know what is required there other than "make httpd 
> smaller".  There are probably a few small things we can do there but I 
> don't know of anything which could make a big difference.

That one was never about size. I think separating the binary from the
service control scripts would do it -- I haven't looked at gnome-user-share
since then, but at the time at least, the C source had code to write out a
temporary config file and launch the daemon from that. So, splitting the
*server* config and systemd units from the binary would do it. (For
continuity, put that in httpd and then the binaries in httpd-bin.)

But, also, the other part of my original complaint (httpd installed on
default desktop installs) does seem to have been addressed back in f15 --
gnome-user-share isn't in comps anymore, and I don't think anything pulls it
in.

Also, sorry for the sarcastic and grumpy tone back in that original bug. I
still agree with what I said, but I'd put it in a nicer tone these days. :)

-- 
Matthew Miller--   Fedora Project--
  "Tepid change for the somewhat better!"
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Present and Future: a Fedora.next 2014 Update (Part II, "What's Happening?")

[Jóhann B. Guðmundsson]

On 03/31/2014 01:00 PM, Jaroslav Reznik wrote:

Base is common platform for products but it does not mean everything has
to be used by other products or everything has to follow base path (for
example installer is part of Base as we agreed but it can diverge a lot
over products, and even it would not be used in all products explicitely
just to provide images - cloud). Of course if some technology gets
obsoleted/deprecated by most of products, it means the time to deprecate
it in Base comes (or change of the owner). So common sense, not exact
numbers:).


You do realize that the size of the base needs to be bound to the lowest 
common denominator between current and future multiple products to make 
it this kind of proposal work now and in the future right?


That immediately binds it and limit it to the size of embedded ( 
Embedded --> Cloud/Containers --> Servers --> Workstation/Desktop/Laptop 
whatever else )  to relevant packages for embedded within those 1806 
components that make up the self hosting Fedora base since there seemed 
there had been reached a perfectly logical consensus to limit what makes 
up the baseWG from those self hosting 1806 component.


Nor can you introduce components to be shared among WG outside the self 
hosting components of the baseWG and I'm quite frankly a bit stunned if 
Philipp Knirsch and the rest of the baseWG agreed to do that since by 
doing so they invalidate their own logical approach of building and 
limit baseWG to self hosting components.


JBG

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Present and Future: a Fedora.next 2014 Update (Part II, "What's Happening?")

[Miloslav Trmač]

2014-03-31 15:29 GMT+02:00 "Jóhann B. Guðmundsson" :
> You do realize that the size of the base needs to be bound to the lowest
> common denominator between current and future multiple products to make it
> this kind of proposal work now and in the future right?

We are at liberty to force all possible products to carry some
overhead to simplify our work or user's expectations. For example,
even if no program in Fedora ever called glibc's hcreate() or
strfry(), we wouldn't consider dropping the implementation and
breaking the ABI; and the same thing can happen at the library level:
We are quite at liberty to promise that libvirt.so.0 will be available
on every Fedora system (even if any attempt to connect to a hypervisor
returned an error.)

Sure, such choices to simplify our environment at the cost of Base
size would disqualify us from the "smallest distribution for embedded
use", but we have never really been in that race anyway, and I'm not
even sure that size matters all that much for the embedded cases where
Fedora is an option (compared to ease of deployment, or availability
of "common" APIs, for example).

> since by doing
> so they invalidate their own logical approach of building and limit baseWG
> to self hosting components.

Only creating Base from self-hosting components does not actually make
sense to me: fedup is not necessary to compile any package, and yet it
clearly belongs in base; various specialized build tools like
documentation extractors and build test frameworks, or even make(1),
are necessary to build packages, but we may not want to promise their
existence to Base users.
 Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Present and Future: a Fedora.next 2014 Update (Part II, "What's Happening?")

[Jóhann B. Guðmundsson]

On 03/31/2014 01:46 PM, Miloslav Trmač wrote:

Sure, such choices to simplify our environment at the cost of Base
size would disqualify us from the "smallest distribution for embedded
use", but we have never really been in that race anyway


I hardly call it simplification shifting workload and package set the 
wg's should be carrying themselves from themselves to the baseWG  and us 
not being in that race arguable is contributing to Fedora irrelevance 
since the market is moving away from traditional desktop usage to a 
smartphone/tablets.


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Present and Future: a Fedora.next 2014 Update (Part II, “What’s Happening?”)

[Rex Dieter]

Richard W.M. Jones wrote:

> - VLC
> 
> Free software video player, but with a requirement (or at least can
> use if available) proprietary / patented / ugly / semi-legal codecs.
> Currently packaged in RPMFusion for reasons I'm not clear on.

I've looked into this a bit, and discussed with other distro packagers and 
vlc upstream.

VLC is fairly modular, and it's unencumbered bits could be brought to fedora 
and the other stuff live in some -freeworld subpkg in rpmfusion. 

Implementing this would be a bit of work, but worth it in my opinion.  I 
haven't had much time to pursue implementing it myself unfortunately.  I 
only wanted to highlight that bringing vlc to fedora is possible.

-- Rex

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Agenda for Env-and-Stacks WG meeting (2014-04-01)

[Marcela Mašláňová]

WG meeting will be at 12:00 UTC, 14:00 Central Europe, 8:00 Boston, 5:00 
San Francisco, 21:00 Tokyo in #fedora-meeting on Freenode.


I hope time make sense. Otherwise please comment the thread about 
meeting time.


== Topic ==
* Automatically approve topics, which weren't refused on mailing list:
 * Open Questions - Playground: Signing
 * Open Questions - Playground: Provenpackagers
* Approve on list or irc:
 * Open Questions - distinguish packages
  * Does my proposal passed or not?
  * Proposal: Do not try to distinguish them. Rpmfusion packages also 
don't have different dist tag. You can find out if really want to by rpm 
-something or check key, which will be also different.

 * Open Questions - Playground: reviews
  * Are conflicts inside Playground repository allowed?
  * How many other checks do we want to have?
* 1 Big repo vs multiple small ones - finally decide which one to pick
* finish change proposal 
https://fedoraproject.org/wiki/Env_and_Stacks/Changes_Drafts/Playground_repository


Marcela
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Owner-change] Fedora packages ownership change

[nobody]

Change in ownership over the last 168 hours
===

13 packages were orphaned
-
npth [devel,f19,f20] was orphaned by kevin
 The New GNU Portable Threads library
 https://admin.fedoraproject.org/pkgdb/acls/name/npth
horde [EL-6] was orphaned by nb
 The common Horde Framework for all Horde applications
 https://admin.fedoraproject.org/pkgdb/acls/name/horde
numactl [devel,f19,f20] was orphaned by aarapov
 Library for tuning for Non Uniform Memory Access machines
 https://admin.fedoraproject.org/pkgdb/acls/name/numactl
python-pip [EL-6,f19,f20] was orphaned by tflink
 Pip is a replacement for easy_install
 https://admin.fedoraproject.org/pkgdb/acls/name/python-pip
gnote [devel,f19,f20] was orphaned by sundaram
 Note-taking application
 https://admin.fedoraproject.org/pkgdb/acls/name/gnote
turba [EL-5] was orphaned by nb
 The Horde contact management application
 https://admin.fedoraproject.org/pkgdb/acls/name/turba
imp [EL-5,EL-6] was orphaned by nb
 The Internet Messaging Program: webmail access to IMAP/POP3 accounts
 https://admin.fedoraproject.org/pkgdb/acls/name/imp
ingo [EL-5,EL-6] was orphaned by nb
 The Horde web-based Email Filter Rules Manager
 https://admin.fedoraproject.org/pkgdb/acls/name/ingo
sysfsutils [devel,f20] was orphaned by aarapov
 Utilities for interfacing with sysfs
 https://admin.fedoraproject.org/pkgdb/acls/name/sysfsutils
bind-dyndb-ldap [devel,f19,f20] was orphaned by atkac
 LDAP back-end plug-in for BIND
 https://admin.fedoraproject.org/pkgdb/acls/name/bind-dyndb-ldap
kronolith [EL-5,EL-6] was orphaned by nb
 The Horde calendar application
 https://admin.fedoraproject.org/pkgdb/acls/name/kronolith
irqbalance [devel,f20] was orphaned by aarapov
 IRQ balancing daemon.
 https://admin.fedoraproject.org/pkgdb/acls/name/irqbalance
python-tgcaptcha2 [epel7] was orphaned by pingou
 TurboGears captcha plugin
 https://admin.fedoraproject.org/pkgdb/acls/name/python-tgcaptcha2

21 packages unorphaned
--
cicku   unorphaned : libupnp [EL-6]
petersenunorphaned : ghc-transformers [devel]
vascom  unorphaned : kbackup [EL-6,devel,f19,f20]
pholasekunorphaned : numactl [f20]
vicodan unorphaned : marco [epel7]
vicodan unorphaned : eom [epel7]
ankursinha  unorphaned : gnote [devel,f19,f20]
cheeselee   unorphaned : stow [EL-5]
petersenunorphaned : ghc-QuickCheck [devel]
vicodan unorphaned : mozo [epel7]
cicku   unorphaned : dzen2 [EL-6]
vicodan unorphaned : mate-themes [epel7]
bkabrda unorphaned : python-pip [EL-6,devel,epel7,f19,f20]
vicodan unorphaned : pluma [epel7]
vicodan unorphaned : caja [epel7]
teufunorphaned : spice-vdagent [devel,f19,f20]
pholasekunorphaned : sysfsutils [devel]
vicodan unorphaned : caja-extensions [epel7]
pspacek unorphaned : bind-dyndb-ldap [devel,f19,f20]
pholasekunorphaned : irqbalance [devel,devel,f19,f19,f20]
vicodan unorphaned : mate-sensors-applet [epel7]

3 packages were retired

nwdiag [devel] was retired by dridi
 nwdiag generates network-diagram images from text
 https://admin.fedoraproject.org/pkgdb/acls/name/nwdiag
ghc-network-enumerator [devel] was retired by petersen
 Enumerators for network sockets
 https://admin.fedoraproject.org/pkgdb/acls/name/ghc-network-enumerator
actdiag [devel] was retired by dridi
 actdiag generates activity-diagram images from text
 https://admin.fedoraproject.org/pkgdb/acls/name/actdiag

17 packages changed owner
-
limbgave to cicku  : yaz [epel7]
kevin   gave to theinric   : libmongo-client [devel,f19,f20]
limbgave to petersen   : ghc-transformers [epel7,f19,f20]
kevin   gave to theinric   : ceelog [devel,f19,f20]
limbgave to cicku  : undbx [EL-6,epel7]
limbgave to petersen   : ghc-HTTP [epel7,f19,f20]
limbgave to jdunn  : perl-Net-Twitter [EL-6]
kevin   gave to theinric   : libumberlog [devel,f19,f20]
limbgave to petersen   : ghc-QuickCheck [EL-5,epel7,f19]
limbgave to bkabrda: python-progress [f20]
limbgave to cicku  : darkhttpd [epel7]
limbgave to cicku  : xvkbd [EL-6,epel7]
ppisar  gave to pghmcfc: perl-Module-Install-GithubMeta 
[epel7]
ppisar  gave to pghmcfc: perl-Module-Install-AutoLicense 
[epel7]
limbgave to cicku  : hg-git [epel7]
limbgave to gecko-maint: thunderbird [epel7,epel7]
limbgave to jskarvad   : pptpd [EL-6,epel7]


Sources: https://github.com/pypingou/

Re: Fedora Present and Future: a Fedora.next 2014 Update (Part II, "What's Happening?")

[Corey Sheldon]

As I've til recently been a whimsical just install whatever a package needs
but am now beginning to look more granularly at this could someone either
briefly explain differences in main sources etc or link me to a good
write-up to this effect??


much appreciated and while it hasn't been the easiest distro to learn it
has been a great learning experience and look forward to staying and
helping the community much more in the coming months and years..


TIA

Corey W Sheldon
Owner, 1st Class Mobile Shine
310.909.7672
www.facebook.com/1stclassmobileshine


On Mon, Mar 31, 2014 at 9:55 AM, "Jóhann B. Guðmundsson"  wrote:

>
> On 03/31/2014 01:46 PM, Miloslav Trmač wrote:
>
>> Sure, such choices to simplify our environment at the cost of Base
>> size would disqualify us from the "smallest distribution for embedded
>> use", but we have never really been in that race anyway
>>
>
> I hardly call it simplification shifting workload and package set the wg's
> should be carrying themselves from themselves to the baseWG  and us not
> being in that race arguable is contributing to Fedora irrelevance since the
> market is moving away from traditional desktop usage to a
> smartphone/tablets.
>
> JBG
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F21 Self Contained Change: Better Erlang Support

[Jaroslav Reznik]

= Proposed Self Contained Change: Better Erlang Support =
https://fedoraproject.org/wiki/Changes/BetterErlangSupport

Change owner(s):  Peter Lemenkov , Sam Kottler , Fedora Erlang SIG 

Update Erlang/OTP to R17, and improve Erlang integration with the rest of 
Fedora. 

== Detailed Description ==
Erlang in Fedora is already in a good shape. However we can do better since 
there are a number of annoying shortcomings and issues. Just a few of them:

* Fedora partially enabled Ellyptic Curve Crypto recently but we still provide 
Erlang with EC disabled completely because there is no way to enable just a 
few EC in the current Erlang version.
* Erlang<->systemd interaction is in a quite poor state currently.
* There is no way to install "headless" Erlang. Every Fedora Erlang user have 
to install graphical libraries even if (s)he doesn't want to use GUI on the 
target machine.
* Every daemon written in Erlang has its own logging solution which doesn't 
use neither syslog nor Journald.
* Erlang packaging is quite complex and undocumented mostly.

In order to address all these issues we should do the following:

* Enable fine grained EC crypto support [1] by upgrading Erlang to the latest 
R17 (not yet released, and scheduled to April, 2014).
* Start working on a better systemd support in Erlang by enabling EPMD systemd 
support. This could be done by merging  patches from Matwey V. Kornilov [2] 
and systemd unit-files from openSUSE  [3].
* Add erlang-ejournald [4], erlang-lager_journald_backend [5], and make 
Journald as a default logging backend.
* Split-off infrequently used modules [6] which requires X11, Pulseaudio and 
ensure that it won't break anything.
* Fix the long-standing noarch issue by providing additional default location 
for Erlang bytecode data.
* Update Erlang RPM-related macros to improve packaging by reducing spec-file 
sizes.

== Scope ==
Proposal owners:
* We must rebuild Erlang R17 and submit it to build-overrides.
** We have to rebuild all the packages listed below in the Dependencies [7] 
section.
* WiP: A necessary *.socket unit must be added to erlang-erts to enable EPMD 
socket activation.
** Every Erlang daemon's systemd unit must require epmd.socket.
* We need to fill new review request for erlang-ejournald
** We have to fill new review request for erlang-lager_journald_backend
* We have to patch out GUI parts and provide a way to tell user what to do in 
order to enable this functionality.
* Add another default directory to look for Erlang *.beam files.
* Every Erlang package must require erlang-rpm-macros.
* Riak has growing Bugzilla backlog. We have to address all of these issues.
Other developers: N/A
Release engineering: N/A
Policies and guidelines: We should create Erlang Packaging Guidelines which 
doesn't exist yet.

[1] https://bugzilla.redhat.com/1023017
[2] https://github.com/matwey/otp/tree/systemd
[3] https://build.opensuse.org/package/show/openSUSE:Factory/erlang 
[4] https://github.com/travelping/ejournald 
[5] https://github.com/travelping/lager_journald_backend
[6] https://bugzilla.redhat.com/784693
[7] https://fedoraproject.org/wiki/Changes/BetterErlangSupport#Dependencies
___
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 Code of Conduct: http://fedoraproject.org/code-of-conduct

Announcing an X11 protocol tracing package

[David Howells]

xtrace, an X11 protocol tracing package that is already available in Debian is
now also available in updates-testing for F20 and Rawhide.

xtrace-1.3.1-5.fc20 newpackage  testing 2014-03-30

This is used by running a program under xtrace, eg:

xtrace xterm

The xtrace program then acts as a dummy/proxy X server to the program it runs,
setting DISPLAY appropriately.  It can also be run as a standalone proxy for
processes to connect to:

xtrace -D :9

The output appears on stderr or can be dumped into a file.  It looks like:

000:<:01c7: 20: Request(77): ImageText16 drawable=0x07a0002d gc=0x07a0002c x=2 
y=13 string=0x2000;
000:<:01c8: 32: Request(65): PolyLine coordinate-mode=Previous(0x01) 
drawable=0x07a0002d gc=0x07a00032 points={x=2 y=2},{x=5 y=0},{x=0 y=12},{x=-5 
y=0},{x=0 y=-12};
000:>:01c8: Event PropertyNotify(28) window=0x07a00022 atom=0x14d(unrecognized 
atom) time=0x3dfa5e3f state=NewValue(0x00)
000:>:01c8: Event PropertyNotify(28) window=0x07a00022 atom=0x1c7(unrecognized 
atom) time=0x3dfa5e3f state=NewValue(0x00)
000:>:01c8: Event PropertyNotify(28) window=0x07a00022 atom=0x1cf(unrecognized 
atom) time=0x3dfa5e40 state=NewValue(0x00)

David
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F21 Self Contained Change: Improved Ivy Packaging

[Jaroslav Reznik]

= Proposed Self Contained Change: Improved Ivy Packaging  =
https://fedoraproject.org/wiki/Changes/ImprovedIvyPackaging

Change owner(s): Mikolaj Izdebski 

This change aims at improving the way of packaging Java software, which uses 
Apache Ivy to manage build dependencies. 

== Detailed Description ==
Currently packages which use Apache Ivy as dependency manager are packaged in 
manual way. Dependencies must be symlinked manually, all files have to be 
explicitly installed, there are no auto-requires.

This change aims at simplifying Ivy packaging in a similar way as it was done 
with Maven packaging [1].

In particular, the following changes will be implemented:

* automatic resolution of Ivy artifacts,
* integration with system Maven repository,
* automatic installation of Ivy artifact metadata,
* auto requires. 

== Scope ==
Proposal owners:
* Implement code to resolve and publish Ivy artifacts in XMvn upstream
* Package new upstream version XMvn in Fedora or backport Ivy changes to 
current XMvn version
* Implement necessary macros in Javapackages Tools upstream
* Package new upstream version Javapackages Tools in Fedora or backport 
necessary changes to current Javapackages Tools version
* Prepare draft of Java packaging guidelines change and submit to FPC

Other developers:
* Maintainers of packages using Apache Ivy during build or installing Ivy 
artifacts can optionally update their packages to use the new packaging 
techniques, but that's not absolutely required as existing ways of packaging 
Ivy artifacts will continue to work. 

Release engineering:
* No action required.

Policies and guidelines:
* Java packaging guidelines will have to be updated to include the new way of 
packaging Ivy artifacts.

[1] https://fedoraproject.org/wiki/Features/Simplified_Maven_Packaging
___
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 Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Present and Future: a Fedora.next 2014 Update (Part II, “What’s Happening?”)

[Adam Williamson]

On Mon, 2014-03-31 at 09:17 -0500, Rex Dieter wrote:
> Richard W.M. Jones wrote:
> 
> > - VLC
> > 
> > Free software video player, but with a requirement (or at least can
> > use if available) proprietary / patented / ugly / semi-legal codecs.
> > Currently packaged in RPMFusion for reasons I'm not clear on.
> 
> I've looked into this a bit, and discussed with other distro packagers and 
> vlc upstream.
> 
> VLC is fairly modular, and it's unencumbered bits could be brought to fedora 
> and the other stuff live in some -freeworld subpkg in rpmfusion. 
> 
> Implementing this would be a bit of work, but worth it in my opinion.  I 

Well, I'm not so sure. A *lot* of people really don't understand the
patent issue. Like, at all. They don't understand modularity. Like, at
all. To a lot of people, the thing called 'vlc' is a magic black box
that plays every video ever. They "install VLC" and then they play
videos. This is the limit of their understanding.

If we make it so you can 'yum install vlc' and get something that can
barely play anything, then tell people they 'just' have to 'yum install
vlc-freeworld' to get it to actually work properly, we may wind up with
more unhappiness than we have just by having all of vlc in the Sekrit
Third Party Repository in the first place. That kinda forces them to get
the whole thing or nothing, which is almost always what they want. They
never wind up in the twilight zone where they have what is, to them,
half a VLC.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Present and Future: a Fedora.next 2014 Update (Part II, "What's Happening?")

[Corey Sheldon]

Whatever if they can't learn the basics and the fundamental basis of Linux
or the "Patent" issues and what have you then go somewhere else like to mac
or windows..sometimes you need to work for things and teaching a man to
fish is always better and personally while i think at first you may be
right the community as a whole will have less of the "why the #@#@@# can't
I use this or that in the development forums and force the maintainers to
make this more transparent and beyond that if you can't grasp that minor
issue then why are you on a RPM-based IT linux distro much less Fedora in
the blanking first place?


Corey W Sheldon
Owner, 1st Class Mobile Shine
310.909.7672
www.facebook.com/1stclassmobileshine


On Mon, Mar 31, 2014 at 8:17 PM, Adam Williamson wrote:

> On Mon, 2014-03-31 at 09:17 -0500, Rex Dieter wrote:
> > Richard W.M. Jones wrote:
> >
> > > - VLC
> > >
> > > Free software video player, but with a requirement (or at least can
> > > use if available) proprietary / patented / ugly / semi-legal codecs.
> > > Currently packaged in RPMFusion for reasons I'm not clear on.
> >
> > I've looked into this a bit, and discussed with other distro packagers
> and
> > vlc upstream.
> >
> > VLC is fairly modular, and it's unencumbered bits could be brought to
> fedora
> > and the other stuff live in some -freeworld subpkg in rpmfusion.
> >
> > Implementing this would be a bit of work, but worth it in my opinion.  I
>
> Well, I'm not so sure. A *lot* of people really don't understand the
> patent issue. Like, at all. They don't understand modularity. Like, at
> all. To a lot of people, the thing called 'vlc' is a magic black box
> that plays every video ever. They "install VLC" and then they play
> videos. This is the limit of their understanding.
>
> If we make it so you can 'yum install vlc' and get something that can
> barely play anything, then tell people they 'just' have to 'yum install
> vlc-freeworld' to get it to actually work properly, we may wind up with
> more unhappiness than we have just by having all of vlc in the Sekrit
> Third Party Repository in the first place. That kinda forces them to get
> the whole thing or nothing, which is almost always what they want. They
> never wind up in the twilight zone where they have what is, to them,
> half a VLC.
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Present and Future: a Fedora.next 2014 Update (Part II, "What's Happening?")

[David]

On 3/31/2014 8:37 PM, Corey Sheldon wrote:
> Whatever if they can't learn the basics and the fundamental basis of
> Linux or the "Patent" issues and what have you then go somewhere else
> like to mac or windows..sometimes you need to work for things and
> teaching a man to fish is always better and personally while i think at
> first you may be right the community as a whole will have less of the
> "why the #@#@@# can't I use this or that in the development forums and
> force the maintainers to make this more transparent and beyond that if
> you can't grasp that minor issue then why are you on a RPM-based IT
> linux distro much less Fedora in the blanking first place?
> 
> 
> Corey W Sheldon
> Owner, 1st Class Mobile Shine
> 310.909.7672
> www.facebook.com/1stclassmobileshine
> 


So what you are saying is that you want people that Use Windows in some
form or MacOS in some form that actually works as installed to switch to
Linux in some form that *does not work without fudges and hacks*?  Good
luck with that.


-- 

  David
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct