Re: F20 System Wide Change: ARM as primary Architecture

[Jonathan Masters]

Thanks Brendan. My Fedora doesn't even use a GNOME desktop. I've happily used 
XFCE for years. And I make no secret that I care about servers more than 
desktops (you know, that part of the market where general purpose Linux has a 
huge footprint and stands a chance). I would hate to look back in five years 
and say "yea, Hyperscale ARM servers took over and Red Hat was totally there, 
but Fedora missed the boat entirely". Move with the times. Fedora wants to 
embrace the new and revolutionary? ARM is powering some very exciting 
disruption and Fedora should not be sitting on the sidelines naval gazing and 
pining for the declining desktop of yesteryear.

-- 
Sent from my iPad

On Jul 11, 2013, at 7:05, Brendan Conoboy  wrote:

> On 07/10/2013 09:13 PM, Matthew Garrett wrote:
>> Fedora is an operating system that supports a range of desktop
>> environments, defaulting to the GNOME desktop environment. An OS that
>> supports headless servers but not desktop environments might be based on
>> Fedora, but it wouldn't be Fedora. As such, it wouldn't be suited to
>> being a Fedora PA.
> 
> It is becoming increasingly difficult to distinguish whether to read these 
> messages as high standards or hyperbole.  Maybe your Fedora means desktop OS, 
> but my Fedora has more facets than that.  Fedora Primary is not some Platonic 
> Form embodied by x86; that would be better described as Fedora Fantasy.
> 
> The all or nothing element in the above simply serves to discourage further 
> contribution and is harming Fedora's growth.  The relentless "I don't want 
> ARM to sully the good name of Fedora" is absurd: User for user, ARM is 
> considerably more popular than Fedora.  Is your definition of "Primary" a 
> sacred idea that is responsible for Fedora's success?  If held dear for too 
> long it will be the well known idea responsible for its failure.
> 
> Please consider the idea that there is a useful middle ground "Primary" and 
> "Secondary".
> 
> Primary Release/Primary Build system
>  |
> Primary Build system/Secondary Release
>  |
> Secondary Build system/Secondary Release
> 
> 
> It might be multidimensional:
> 
> Primary Desktop---Secondary Desktop
>|   |
> Primary ServerSecondary Server
> 
> 
> 15 months ago:
> 
> There were concerns about reliability- we moved to enterprise hardware in PHX.
> 
> There were concerns about build times, particularly that of the kernel: We 
> bought the fastest hardware available, moved to a unified kernel architecture 
> and sped up builds many-fold.
> 
> There were concerns about kernel and toolchain maintainship: We hired and/or 
> tasked kernel, glibc, gcc, and other engineers.
> 
> There were concerns about releases being held up: We released F19 Beta and GA 
> on the same day as x86.
> 
> There were concerns about releng: Releng wrote the new promotion proposal.
> 
> There were concerns about QA&Release criteria: We copied most of Primary's 
> procedures.
> 
> There were concerns about the installer: We're using anaconda and standard 
> image creation tooling.
> 
> There were concerns about desktop users: All supported platforms that have 
> graphical hardware have a desktop.
> 
> The list goes on and on.  For any of the above a person can be small and pick 
> out tiny details where they aren't satisfied, but if you're one of the people 
> who is going to do that, please say the following:
> 
> "I object to armv7hl moving to primary because of $DEFECT, but if $DEFECT is 
> remedied by $MILESTONE, I will then support the move of armv7hl to primary".  
> You define $DEFECT and $MILESTONE and we can have a productive discussion.
> 
> At this time I think it is quite reasonable to ask for the build systems to 
> be merged.  Whether you call it Primary, Secondary, or some new 
> middle-of-the-ground word, it's progress.
> 
> -- 
> Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
> -- 
> 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: F20 System Wide Change: ARM as primary Architecture

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 11 Jul 2013 02:12:03 -0400 (EDT)
Aleksandar Kurtakov  wrote:

> - Original Message -
> > From: "Richard W.M. Jones" 
> > To: "Development discussions related to Fedora"
> >  Sent: Wednesday, July 10, 2013
> > 11:56:40 PM Subject: Re: F20 System Wide Change: ARM as primary
> > Architecture
> > 
> > On Wed, Jul 10, 2013 at 04:17:47PM +0100, Caolán McNamara wrote:
> > > On Wed, 2013-07-10 at 08:28 -0400, Aleksandar Kurtakov wrote:
> > > > I still have serious concerns regarding build times:
> > > > * arm -
> > > > https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=150248
> > > > ~ 17h
> > > > * current primary -
> > > > https://koji.fedoraproject.org/koji/buildinfo?buildID=429023
> > > > ~1h 30m
> > > > 
> > > > This is still too huge gap - roughly 10 times slower. If ARM
> > > > will become primary arch I hope this is an exception and not
> > > > the general rule.
> > > 
> > > FWIW, the last libreoffice arm build of
> > > https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=152413,
> > > took approx 14 hours. While
> > > https://koji.fedoraproject.org/koji/buildinfo?buildID=432079 took
> > > approx 5 hours on x86
> > > 
> > > I can probably live with that without to much suffering, but it
> > > does push build times from "start build today, get result today"
> > > to "start build today, get results tomorrow".
> > 
> > Just a note that Koji is currently configured to time out builds
> > after 24 hours.
> > 
> > Not that you'd want your builds taking longer than this, but it's
> > may affect the discussion ...
> 
> I started a new f20 build to see how things will go on and Koji
> estimates it to around 20h. See
> https://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1974977 .
> What are the possibilities for koji time out to be changed to 48h
> if/when arm becomes primary? This would be highly needed to not have
> to resubmit builds because koji timed out cause it hit slow builder.
> We have seen that few times when we tried to bootstrap secondary
> archs.

It  is a viable option to give us some room just incase.

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlHeUfEACgkQkSxm47BaWfeOhACfbTvB/um7Vipr1TSWH/oP8AGY
wkMAoK/Y5SeqnYAB7q4arf0yg/3QvUiG
=Ywqd
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Adam Williamson]

On Wed, 2013-07-10 at 23:18 -0700, Brendan Conoboy wrote:
> On 07/10/2013 10:12 PM, Adam Williamson wrote:
> > As I said elsewhere in the thread, the criteria should be subsidiary to
> > the primary arch designation. If we decide we want to take ARM as a
> > primary arch in any form in which the current release criteria don't
> > apply, we should amend the release criteria.
> >
> > In context I was just providing some background information: as the
> > criteria currently stand, KDE and GNOME are the release blocking
> > desktops. (Technically that in itself isn't really an aspect of the
> > release criteria; it's Fedora status quo that predates the current form
> > of the release validation process).
> 
> Yeah, it seems like a foregone conclusion that release criteria would 
> need to be modified.  I don't think the current proposal includes this, 
> but perhaps it should.  Realistically what's going to be needed is some 
> form of granularity on "primary".  At first blush I like the idea of a 
> "primary server" and "primary desktop" designation (maintaining a 
> unified build system) but haven't thought the full consequences through.

The required change is not, in fact, necessarily that dramatic, as I
mentioned earlier in the thread. As written, the release criteria do not
explicitly require that the release-blocking desktops work on all
primary architectures. They just talk about things that are required to
work within the desktops themselves.

What would actually need to change for ARM, I think, are just the very
early criteria and preamble, where we have this stuff:

"The term 'release-blocking images' means all the images in which bugs
are currently considered capable of blocking a Fedora release. The
current set of release-blocking images includes the network install
image, the DVD image, and the live images for each of the
release-blocking desktops."

"All release-blocking images must boot in their supported
configurations.", with a bunch of footnotes about what that means
precisely.

I think we could make relatively minor tweaks to those bits - obviously,
we would extend the list of 'release-blocking images', which functions
as a very concise 'deliverables' list - and maybe make it a bit clearer
in the footnotes to the 'initialization requirements' criteria exactly
what behaviour is required from those images. That would really be all
that would be necessary, I think. We _could_ explain specifically in the
preamble that certain criteria are not relevant to certain arches, if we
wanted to.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Dan Horák]

On Wed, 10 Jul 2013 21:56:40 +0100
"Richard W.M. Jones"  wrote:

> On Wed, Jul 10, 2013 at 04:17:47PM +0100, Caolán McNamara wrote:
> > On Wed, 2013-07-10 at 08:28 -0400, Aleksandar Kurtakov wrote:
> > > I still have serious concerns regarding build times:
> > > * arm -
> > > https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=150248
> > > ~ 17h
> > > * current primary -
> > > https://koji.fedoraproject.org/koji/buildinfo?buildID=429023 ~1h
> > > 30m
> > > 
> > > This is still too huge gap - roughly 10 times slower. If ARM will
> > > become primary arch I hope this is an exception and not the
> > > general rule.
> > 
> > FWIW, the last libreoffice arm build of
> > https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=152413,
> > took approx 14 hours. While
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=432079 took
> > approx 5 hours on x86
> > 
> > I can probably live with that without to much suffering, but it does
> > push build times from "start build today, get result today" to
> > "start build today, get results tomorrow".
> 
> Just a note that Koji is currently configured to time out builds after
> 24 hours.

the timeout is currently hard-coded in the koji sources, but patch
exists to make it configurable, I should ping upstream about it as not
only ARM fights with long build times


Dan

> Not that you'd want your builds taking longer than this, but it's may
> affect the discussion ...
> 
> 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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Brendan Conoboy]

On 07/10/2013 10:12 PM, Adam Williamson wrote:

As I said elsewhere in the thread, the criteria should be subsidiary to
the primary arch designation. If we decide we want to take ARM as a
primary arch in any form in which the current release criteria don't
apply, we should amend the release criteria.

In context I was just providing some background information: as the
criteria currently stand, KDE and GNOME are the release blocking
desktops. (Technically that in itself isn't really an aspect of the
release criteria; it's Fedora status quo that predates the current form
of the release validation process).


Yeah, it seems like a foregone conclusion that release criteria would 
need to be modified.  I don't think the current proposal includes this, 
but perhaps it should.  Realistically what's going to be needed is some 
form of granularity on "primary".  At first blush I like the idea of a 
"primary server" and "primary desktop" designation (maintaining a 
unified build system) but haven't thought the full consequences through.


--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Aleksandar Kurtakov]

- Original Message -
> From: "Richard W.M. Jones" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, July 10, 2013 11:56:40 PM
> Subject: Re: F20 System Wide Change: ARM as primary Architecture
> 
> On Wed, Jul 10, 2013 at 04:17:47PM +0100, Caolán McNamara wrote:
> > On Wed, 2013-07-10 at 08:28 -0400, Aleksandar Kurtakov wrote:
> > > I still have serious concerns regarding build times:
> > > * arm - https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=150248
> > > ~ 17h
> > > * current primary -
> > > https://koji.fedoraproject.org/koji/buildinfo?buildID=429023 ~1h 30m
> > > 
> > > This is still too huge gap - roughly 10 times slower. If ARM will become
> > > primary arch I hope this is an exception and not the general rule.
> > 
> > FWIW, the last libreoffice arm build of
> > https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=152413, took
> > approx 14 hours. While
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=432079 took approx
> > 5 hours on x86
> > 
> > I can probably live with that without to much suffering, but it does
> > push build times from "start build today, get result today" to "start
> > build today, get results tomorrow".
> 
> Just a note that Koji is currently configured to time out builds after
> 24 hours.
> 
> Not that you'd want your builds taking longer than this, but it's may
> affect the discussion ...

I started a new f20 build to see how things will go on and Koji estimates it to 
around 20h. 
See https://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1974977 . What are 
the possibilities for koji time out to be changed to 48h if/when arm becomes 
primary? 
This would be highly needed to not have to resubmit builds because koji timed 
out cause it hit slow builder. We have seen that few times when we tried to 
bootstrap secondary archs.


Alexander Kurtakov
Red Hat Eclipse team

> 
> 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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Brendan Conoboy]

On 07/10/2013 09:13 PM, Matthew Garrett wrote:

Fedora is an operating system that supports a range of desktop
environments, defaulting to the GNOME desktop environment. An OS that
supports headless servers but not desktop environments might be based on
Fedora, but it wouldn't be Fedora. As such, it wouldn't be suited to
being a Fedora PA.


It is becoming increasingly difficult to distinguish whether to read 
these messages as high standards or hyperbole.  Maybe your Fedora means 
desktop OS, but my Fedora has more facets than that.  Fedora Primary is 
not some Platonic Form embodied by x86; that would be better described 
as Fedora Fantasy.


The all or nothing element in the above simply serves to discourage 
further contribution and is harming Fedora's growth.  The relentless "I 
don't want ARM to sully the good name of Fedora" is absurd: User for 
user, ARM is considerably more popular than Fedora.  Is your definition 
of "Primary" a sacred idea that is responsible for Fedora's success?  If 
held dear for too long it will be the well known idea responsible for 
its failure.


Please consider the idea that there is a useful middle ground "Primary" 
and "Secondary".


Primary Release/Primary Build system
  |
Primary Build system/Secondary Release
  |
Secondary Build system/Secondary Release


It might be multidimensional:

Primary Desktop---Secondary Desktop
|   |
Primary ServerSecondary Server


15 months ago:

There were concerns about reliability- we moved to enterprise hardware 
in PHX.


There were concerns about build times, particularly that of the kernel: 
We bought the fastest hardware available, moved to a unified kernel 
architecture and sped up builds many-fold.


There were concerns about kernel and toolchain maintainship: We hired 
and/or tasked kernel, glibc, gcc, and other engineers.


There were concerns about releases being held up: We released F19 Beta 
and GA on the same day as x86.


There were concerns about releng: Releng wrote the new promotion proposal.

There were concerns about QA&Release criteria: We copied most of 
Primary's procedures.


There were concerns about the installer: We're using anaconda and 
standard image creation tooling.


There were concerns about desktop users: All supported platforms that 
have graphical hardware have a desktop.


The list goes on and on.  For any of the above a person can be small and 
pick out tiny details where they aren't satisfied, but if you're one of 
the people who is going to do that, please say the following:


"I object to armv7hl moving to primary because of $DEFECT, but if 
$DEFECT is remedied by $MILESTONE, I will then support the move of 
armv7hl to primary".  You define $DEFECT and $MILESTONE and we can have 
a productive discussion.


At this time I think it is quite reasonable to ask for the build systems 
to be merged.  Whether you call it Primary, Secondary, or some new 
middle-of-the-ground word, it's progress.


--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Carlos O'Donell]

On 07/10/2013 01:36 PM, Jakub Jelinek wrote:
> On Wed, Jul 10, 2013 at 11:19:33AM -0500, Dennis Gilmore wrote:
>> armv7 has stack protector, aarch64 which is outside of this proposal
>> doesnt yet have it.
> 
> Only i?86/x86_64/ppc/ppc64/s390/s390x/sparc/sparc64/tilegx/tilepro
> really have full stack protector support, while perhaps -fstack-protector
> doesn't error out on armv7, it certainly isn't supported in glibc
> (neither TLS stack guard, not TLS pointer guard), so I wouldn't talk about
> arm having security standards high enough for being a primary architecture.
> 
> CCing Carlos so that they can discuss that.

Without specific support for stack protector (TLS stack guard and TLS pointer
guard) the glibc build will fall back to exporting two symbols for use by
libssp e.g. __stack_chk_guard, and __pointer_chk_guard. They serve a similar
purpose to the TLS variables but are global. Thus I would expect
-fstack-protector to work with libssp on 32-bit ARM, but I haven't verified
that. Even with that support the 32-bit ARM port of glibc lacks proper
pointer mangling/demangling routines so it doesn't make use of the
__pointer_chk_guard value.

In summary:
- I would expect -fstack-protector to work on 32-bit ARM via libssp and
  support stack guards but not pointer guards (for pointer mangling).

Next steps:
- Verify libssp works correctly on 32-bit ARM.
- Look at enhancing the existing support in glibc.
  - Add TLS stack guard.
  - Add TLS pointer guard.
  - Add pointer mangle/demangle support.
- Enhance aarch64 to support the same set of features.

The glibc team doesn't have any immediate plans to implement any of this.

Cheers,
Carlos.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Adam Williamson]

On Wed, 2013-07-10 at 20:12 -0700, Toshio Kuratomi wrote:
> 
> On Jul 10, 2013 6:08 PM, "Brendan Conoboy"  wrote:
> >
> > On 07/10/2013 02:25 PM, Adam Williamson wrote:
> >>
> >> No. The release blocking desktops are KDE and GNOME. This is stated
> in
> >> the preamble of all release criteria pages, for lack of anywhere
> better
> >> to state it.
> >
> >
> > If we were only proposing headless ARM servers for primary how would
> these criteria apply?  The changes to the build system would be the
> same with our without these desktops in either case.  Note I'm not
> asking Adam specifically; it's a question for the room.
> >
> I was thinking the same thing earlier.  I think Adamw and jreznik
> would both say that we should modify the release criteria for that.  I
> think mjg is more of the opinion that the fedora distribution means
> that certain things including the default desktop are available and
> that a different target, like headless servers, should be a spin.  I
> believe that he's left open the option to rethink how spins and
> primary arch overlap so that arm with a headless server spin could be
> primary but not called fedora.

I'm not actually advocating either course of action.

What I'm saying is that the release criteria are a thing that tries to
codify what we, as a community, decide we want 'Fedora' to be: the
correct process is that we make that decision, then we ensure the
release criteria reflect it.

My position is that 'we', as in Fedora, should decide whether we want
ARM as a primary arch, with whatever caveats are being produced as a
part of this discussion. If we wind up deciding that ARM should be a
primary arch but we don't require it to have a working GNOME desktop, or
whatever, then that's a perfectly valid decision, and we would then
adjust the release criteria and validation process to reflect that.

It would also be a perfectly valid decision to say 'no, all primary
arches should support a certain core feature set, and GNOME is part of
that'. I'm not specifically advocating for either of those decisions;
just saying that "the release criteria as they currently stand say X, so
ARM must do X" is not a good approach.

> Getting back to the release criteria; if we are moving towards a model
> where a headless server spin was fine as the only product for an arch
> I think we'd need to start looking at release criteria being applied
> more purely to spins.  This might require big changes to how we think
> about validating a release.  

So, that's kinda what Johann's suggesting. As I said, on a purely
'intellectual' level I like the model, but in practice, there is still a
substantial faction out there for which "Fedora" is the GNOME live image
or the default DVD install. I'm always up for process improvements, but
I think on a practical level, whatever we come up with is going to have
to ensure that those things work, as it currently does.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Matthew Garrett]

On Thu, Jul 11, 2013 at 12:43:36AM -0400, DJ Delorie wrote:
> 
> > Stack protector is not a new requirement in Fedora. It's been part of 
> > the distribution for years.
> 
> xterm has been part of the distribution for years also, but it's not a
> release requirement.

The assumption has always been that all primary architectures embody the 
same level of functionality, with the exception of fundamental 
differences between the architectures. If things that are currently 
supported by the primary architectures cease to be supported by the 
primary architectures, that's a strong argument that they're not 
fundamental to Fedora. For example, in the absence of hardware nx 
support, I wouldn't argue that ARM should be forced to implement 
execshield - both because it's fundamentally tied to 32-bit x86, and 
because we've given up on supporting it. But yes, if ARM wanted to ship 
without xterm while the other primary architectures supported it, I'd 
say that that would be a blocker for shipping ARM as a primary 
architecture.

I think what's been missed here is that the secondary architecture 
promotion guidelines were intended to be an addition to common sense 
rather than a replacement for it. They didn't seek to be an exhaustive 
list of things that had to be present for something to be a PA - they 
were an attempt to shape out the grey areas. A primary architecture 
should include everything that one could reasonable expect to be present 
in Fedora, which includes security features.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Adam Williamson]

On Wed, 2013-07-10 at 18:08 -0700, Brendan Conoboy wrote:
> On 07/10/2013 02:25 PM, Adam Williamson wrote:
> > No. The release blocking desktops are KDE and GNOME. This is stated in
> > the preamble of all release criteria pages, for lack of anywhere better
> > to state it.
> 
> If we were only proposing headless ARM servers for primary how would 
> these criteria apply?  The changes to the build system would be the same 
> with our without these desktops in either case.  Note I'm not asking 
> Adam specifically; it's a question for the room.

As I said elsewhere in the thread, the criteria should be subsidiary to
the primary arch designation. If we decide we want to take ARM as a
primary arch in any form in which the current release criteria don't
apply, we should amend the release criteria.

In context I was just providing some background information: as the
criteria currently stand, KDE and GNOME are the release blocking
desktops. (Technically that in itself isn't really an aspect of the
release criteria; it's Fedora status quo that predates the current form
of the release validation process).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Owner-change] Fedora packages ownership change

[Vít Ondruch]

Dne 9.7.2013 17:52, Orion Poplawski napsal(a):

On 07/09/2013 12:16 AM, Vít Ondruch wrote:

Dne 8.7.2013 12:00, nob...@fedoraproject.org napsal(a):

ruby-mysql [devel] was orphaned by orion
  A Ruby interface to MySQL
https://admin.fedoraproject.org/pkgdb/acls/name/ruby-mysql



Was this intentional? There is no replacement to this package in 
Fedora yet,

nor it was correctly deprecated.


Nothing uses it that I can see. 


That is like claiming nothing uses Ruby on Rails we ship in Fedora or 
nothing uses LibreOffice



rubygem-mysql2 is under review:

https://bugzilla.redhat.com/show_bug.cgi?id=974889

and that should be used going forward.


Yes, it is ... but if you suggest that is should be used, it should 
probably obsolete ruby-mysql and that should be coordinated with 
rubygem-mysql2 maintainer. I am not aware of such suggestion.




If someone really wants to resurrect this, I would suggest using this:

http://www.cora.nwra.com/~orion/fedora/rubygem-mysql-2.9.1-1.fc19.src.rpm



BTW if you really like to retire ruby-mysql, you should do it properly 
at least, click on "retire package" in pkgdb is not enough. You should 
do step 2 from 
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life



Vít
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[DJ Delorie]

> Stack protector is not a new requirement in Fedora. It's been part of 
> the distribution for years.

xterm has been part of the distribution for years also, but it's not a
release requirement.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Matthew Garrett]

On Wed, Jul 10, 2013 at 06:08:33PM -0700, Brendan Conoboy wrote:
> On 07/10/2013 02:25 PM, Adam Williamson wrote:
> >No. The release blocking desktops are KDE and GNOME. This is stated in
> >the preamble of all release criteria pages, for lack of anywhere better
> >to state it.
> 
> If we were only proposing headless ARM servers for primary how would
> these criteria apply?  The changes to the build system would be the
> same with our without these desktops in either case.  Note I'm not
> asking Adam specifically; it's a question for the room.

Fedora is an operating system that supports a range of desktop 
environments, defaulting to the GNOME desktop environment. An OS that 
supports headless servers but not desktop environments might be based on 
Fedora, but it wouldn't be Fedora. As such, it wouldn't be suited to 
being a Fedora PA.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Matthew Garrett]

On Wed, Jul 10, 2013 at 09:53:09PM -0400, Jonathan Masters wrote:

> But also guys, come on. We can't be having random new requirements 
> being added in a bike shedding exercise with the first this being 
> raised happening now.

Stack protector is not a new requirement in Fedora. It's been part of 
the distribution for years.


 |  Fedora
 |
 |
 |  "Your architecture must be at least this competent"
 |
 |
 |  stack protector
 |
 |
 |
 |  m68k
 |
 |
 |
 |
 | --- elks
 |
 |
 | --- minix
---


-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Toshio Kuratomi]

On Jul 10, 2013 6:08 PM, "Brendan Conoboy"  wrote:
>
> On 07/10/2013 02:25 PM, Adam Williamson wrote:
>>
>> No. The release blocking desktops are KDE and GNOME. This is stated in
>> the preamble of all release criteria pages, for lack of anywhere better
>> to state it.
>
>
> If we were only proposing headless ARM servers for primary how would
these criteria apply?  The changes to the build system would be the same
with our without these desktops in either case.  Note I'm not asking Adam
specifically; it's a question for the room.
>
I was thinking the same thing earlier.  I think Adamw and jreznik would
both say that we should modify the release criteria for that.  I think mjg
is more of the opinion that the fedora distribution means that certain
things including the default desktop are available and that a different
target, like headless servers, should be a spin.  I believe that he's left
open the option to rethink how spins and primary arch overlap so that arm
with a headless server spin could be primary but not called fedora.

I think I agree with mjg that we should divorce pa status from the
particular fedora spins that can be made from them.  I don't think I agree
as much that the packageset of a particular spin is what defines what
deserves the fedora name: I wouldn't have a problem with an arm packageset
that couldn't support the default desktop.

There probably is a minimal packageset, though.  the kernel, glibc, gcc,
and rpm would all be on my list.  Given that fesco has a policy about the
package depsolver having to be the same on all spins, probably the current
depdolving package manager as well. Default init system and bash are also
likely although someone might be able to make a case for alternatives to
the defaults being okay... with emphasis on "might".

Getting back to the release criteria; if we are moving towards a model
where a headless server spin was fine as the only product for an arch I
think we'd need to start looking at release criteria being applied more
purely to spins.  This might require big changes to how we think about
validating a release.

-Toshio
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Who uses abi-compliance-checker?

[Sérgio Basto]

On Qui, 2013-07-04 at 16:47 +0400, Andrey Ponomarenko wrote:
> Starting with 1.6 version of pkgdiff if you compare debug packages
> and 
> add --details option on the command line then the tool will 
> automatically run abi-dumper to dump ABI of old and new shared
> objects 
> found in the packages and then compare them by the 
> abi-compliance-checker tool.


hum , so pkgdiff -details doesn't use abi-compliance-checker without
abi-dumper installed ? 


pkgdiff x264-0.130-3.20130502git1db4621.fc20.i686.rpm
x264-0.133-1.20130709git585324f.fc20.i686.rpm -details
ERROR: cannot find ABI Dumper
reading packages ...
comparing packages ...
creating changes report ...
result: CHANGED (18.4%)
see detailed report:

pkgdiff_reports/x264/0.130-3.20130502git1db4621.fc20_to_0.133-1.20130709git585324f.fc20/changes_report.html


-- 
Sérgio M. B.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Orphaning desktopcouch

[Jeffrey Ollie]

Hello,

I've orphaned desktopcouch in pkdg, I haven't had in interest in quite
a while and it could use some attention from more active maintenance.

--
Jeff Ollie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Jonathan Masters]

That option simply preserves the global stack canary value between tasks during 
context switch. It's not really core to this. The core piece is userspace 
compiler tooling. I know the option exists and I thought/was lead to believe it 
works. But if Jakub has concerns I will add that to the feedback I have already 
raised with ARM/Linaro here in Dublin this evening.

But also guys, come on. We can't be having random new requirements being added 
in a bike shedding exercise with the first this being raised happening now. If 
there are issues then they can be prioritized and worked on, but we'll never 
get anywhere if things are raised in this manner. As I see it, ARM is the most 
popular architecture on Earth, is damn well supported in Fedora, and we do the 
Fedora community a disservice by not bringing the 4 F's into this and thinking 
about the broader context. So, I'll/we'll come back with more data on the stack 
protector implementation and what we can do about llvmpipe, but meanwhile 
please give us useful guidance on what you actually want for ARM to be a PA. 
Not "hand wavy it must be feature parity with x86". I can think of plenty of 
terrible things x86 does that I would never want to see ARM attempt to match.

Jon.

-- 
Sent from my iPad

On Jul 10, 2013, at 19:40, Peter Robinson  wrote:

> On Wed, Jul 10, 2013 at 6:36 PM, Jakub Jelinek  wrote:
>> On Wed, Jul 10, 2013 at 11:19:33AM -0500, Dennis Gilmore wrote:
>>> armv7 has stack protector, aarch64 which is outside of this proposal
>>> doesnt yet have it.
>> 
>> Only i?86/x86_64/ppc/ppc64/s390/s390x/sparc/sparc64/tilegx/tilepro
>> really have full stack protector support, while perhaps -fstack-protector
>> doesn't error out on armv7, it certainly isn't supported in glibc
>> (neither TLS stack guard, not TLS pointer guard), so I wouldn't talk about
>> arm having security standards high enough for being a primary architecture.
> 
> So what does the kernel level CC_STACKPROTECTOR config option bring to
> this as it appears to be associated with the -fstack-protector option
> as well (according to it's Kconfig description) but is only supported
> on x86/arm from that list above (plus sh).
> 
> Peter
> -- 
> 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: F20 System Wide Change: ARM as primary Architecture

[Brendan Conoboy]

On 07/10/2013 02:25 PM, Adam Williamson wrote:

No. The release blocking desktops are KDE and GNOME. This is stated in
the preamble of all release criteria pages, for lack of anywhere better
to state it.


If we were only proposing headless ARM servers for primary how would 
these criteria apply?  The changes to the build system would be the same 
with our without these desktops in either case.  Note I'm not asking 
Adam specifically; it's a question for the room.


--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Ben Boeckel]

On Wed, 03 Jul, 2013 at 04:35:58 GMT, Alex G. wrote:
> We shouldn't be surprised that update descriptions are crap. They are
> just an annoyance for a lot of us, especially since we've put all that
> information in a bunch of other places.

Where else would information like the information in this update[1]
belong? It doesn't make sense in the spec changelog or the fedora-git
changelog. This also isn't from the upstream changelog since it's
jumping a version and some of the intermediates are really of little
consequence to users. I'm all for tooling, but it won't do everything
for you; there's still work involved.

--Ben

[1]https://admin.fedoraproject.org/updates/FEDORA-2013-9760/vifm-0.7.5-1.fc19

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Owner-change] Fedora packages ownership change

[Matt Rose]

I'm not a currently approved packager, but I'd be interested in taking over 
bsd-mailx.  I use it constantly on other platforms and it doesn't make sense to 
me to drop it.

Matt 

On 2013-07-01, at 2:14 PM, nob...@fedoraproject.org wrote:

> Change in ownership over the last 168 hours
> ===
> 
> 9 packages were orphaned
> 
> mysql-connector-c++ [devel] was orphaned by remi
> MySQL database connector for C++
> https://admin.fedoraproject.org/pkgdb/acls/name/mysql-connector-c++
> guiloader-c++ [devel,f17,f18,f19] was orphaned by fab
> C++ Binding to GuiLoader Library
> https://admin.fedoraproject.org/pkgdb/acls/name/guiloader-c++
> php-pecl-apc [devel] was orphaned by remi
> APC caches and optimizes PHP intermediate code
> https://admin.fedoraproject.org/pkgdb/acls/name/php-pecl-apc
> bsd-mailx [devel] was orphaned by pschiffe
> Simple mail user agent
> https://admin.fedoraproject.org/pkgdb/acls/name/bsd-mailx
> python-github [devel,f19] was orphaned by bkabrda
> A Python library implementing the full Github API v3
> https://admin.fedoraproject.org/pkgdb/acls/name/python-github
> guiloader [devel,f17,f18,f19] was orphaned by fab
> GuiXml Loader Library
> https://admin.fedoraproject.org/pkgdb/acls/name/guiloader
> libgssglue [devel] was orphaned by steved
> Generic Security Services Application Programming Interface Library
> https://admin.fedoraproject.org/pkgdb/acls/name/libgssglue
> mysql-workbench [devel] was orphaned by remi
> A MySQL visual database modeling, administration and querying tool
> https://admin.fedoraproject.org/pkgdb/acls/name/mysql-workbench
> libgssapi [devel,f17,f18,f19] was orphaned by steved
> Generic Security Services Application Programming Interface Library
> https://admin.fedoraproject.org/pkgdb/acls/name/libgssapi
> 
> 7 packages unorphaned
> -
> rohara  unorphaned : haproxy [EL-5]
> skottlerunorphaned : rubygem-minitest [EL-6]
> romaunorphaned : fmtools [devel]
> cicku   unorphaned : elementary-icon-theme [f17]
> mizdebskunorphaned : java-service-wrapper [f18]
> cicku   unorphaned : gcin [f19]
> skottlerunorphaned : cppunit [EL-5]
> 
> 6 packages changed owner
> 
> limbgave to gwei3  : oat [EL-6]
> limbgave to than   : apiextractor [EL-6]
> limbgave to than   : python-pyside [EL-6]
> limbgave to than   : shiboken [EL-6]
> limbgave to than   : sparsehash [EL-6]
> limbgave to than   : generatorrunner [EL-6]
> -- 
> 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: Moving xine-lib and dependent apps to RPM Fusion Free for F17?

[Kevin Kofler]

Hi,

On Wednesday 10 July 2013 at 10:51:44, Xavier Bachelot wrote:
> I took a look at kaffeine as found in F19 yesterday, and it is still
> using xine-lib (and does rebuild fine against the xine-lib 1.2.3 rpm I
> prepared). A quick glance at upstream sources showed there are now an
> mplayer and vlc backend too, but it seems vlc is the default. iirc,
> there was also a gstreamer backend at some point, but I don't see it
> anymore. I don't know how to build another backend than the default one.
> Also, latest release is 2 years old.
> Do you know more about kaffeine status and would you have any advice on
> the way forward ?

Last I checked, Kaffeine upstream had, in their git repository at git.kde.org, 
moved from xine-lib to VLC to MPlayer and back to VLC, each time dropping 
support for the previous backend and not getting any closer to a release. As 
far as I can see, not much has changed in upstream git since then. (Is the 
main upstream maintainer secretly preparing yet another backend switch? Or a 
release of what's there now? Or is the project just dying? I have no idea.)

So I think the plan for Kaffeine should be to just move the current (old) 
Kaffeine release to RPM Fusion along with xine-lib.

Kevin Kofler
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Virtualization on ARM (was: Re: F20 System Wide Change: ARM as primary Architecture)

[M A Young]

On Wed, 10 Jul 2013, Richard W.M. Jones wrote:


On Tue, Jul 09, 2013 at 11:32:46AM -0400, Jonathan Masters wrote:

Excellent proposal. I of course think this would be just awesome!


This proposal doesn't address virtualization!

I think this is great, BUT I'd also like to see a widely available
cheap ARM platform that supports virtualization, AND for which
virtualization genuinely works out of the box.

Because, otherwise we can't start properly getting libvirt and the
rest of the virt stack working.


I was intending to update xen on Fedora 20 to the newly released 
xen-4.3.0. This adds ARM support as a technology preview, though I don't 
know if this meets your requirements.


Michael Young
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Adam Williamson]

On Wed, 2013-07-10 at 18:01 -0400, Cole Robinson wrote:
> On 07/10/2013 05:34 PM, Adam Williamson wrote:
> > On Wed, 2013-07-10 at 09:46 -0600, Kevin Fenzi wrote:
> >> On Tue, 9 Jul 2013 22:36:39 +0100
> >> Peter Robinson  wrote:
> >>
> >>> On Tue, Jul 9, 2013 at 10:11 PM, Till Maas 
> >>> wrote:
> >>
> >> ...snip...
> >>
>  test instances for maintainers as described here:
>  https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
> >>>
> >>> I've never seen the above before.
> >>>
> >>> There's instances available to QA
> >>> https://fedoraproject.org/wiki/Architectures/ARM/qa-machines
> >>
> >> I was working on adding 2 more SOC's for packagers earlier this week. 
> >>
> >> I wanted to see how much call there was for these... should I try and
> >> make them accessable by all packagers? Or just have a group and
> >> interested people could be added to that group?
> > 
> > They're probably useful for update testing, but I don't think they're
> > much use for release validation, since that generally equates to testing
> > deployment, which you can't really do from an ssh session.
> > 
> 
> FWIW I'll be proposing (likely tomorrow) an F20 feature/change for ARM virt on
> x86, which will track the missing libvirt/virt-manager/etc bits needed to run
> Fedora ARM in a VM on x86 using standard tools. Hopefully that helps here.

It most DEFINITELY would, assuming it will perform at least acceptably
(not askin' for miracles, but YKWIM). Thanks muchly.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Cole Robinson]

On 07/10/2013 05:34 PM, Adam Williamson wrote:
> On Wed, 2013-07-10 at 09:46 -0600, Kevin Fenzi wrote:
>> On Tue, 9 Jul 2013 22:36:39 +0100
>> Peter Robinson  wrote:
>>
>>> On Tue, Jul 9, 2013 at 10:11 PM, Till Maas 
>>> wrote:
>>
>> ...snip...
>>
 test instances for maintainers as described here:
 https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
>>>
>>> I've never seen the above before.
>>>
>>> There's instances available to QA
>>> https://fedoraproject.org/wiki/Architectures/ARM/qa-machines
>>
>> I was working on adding 2 more SOC's for packagers earlier this week. 
>>
>> I wanted to see how much call there was for these... should I try and
>> make them accessable by all packagers? Or just have a group and
>> interested people could be added to that group?
> 
> They're probably useful for update testing, but I don't think they're
> much use for release validation, since that generally equates to testing
> deployment, which you can't really do from an ssh session.
> 

FWIW I'll be proposing (likely tomorrow) an F20 feature/change for ARM virt on
x86, which will track the missing libvirt/virt-manager/etc bits needed to run
Fedora ARM in a VM on x86 using standard tools. Hopefully that helps here.

- Cole
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: GPG verification in SPECs

[Brian C. Lane]

On Mon, Jul 08, 2013 at 11:15:05PM +0200, Till Maas wrote:
> Hi,
> 
> upstream of pam_mount pointed me to OpenSUSE's gpg-offline RPM macros at
> https://build.opensuse.org/package/show/Base:System/gpg-offline
> 
> They allow to use a keyring and detached signature as additional source
> in SPECs to get both verified. Since gpg-offline's upstream is willing
> to create a proper release to allow easy packaging for Fedora, I wonder
> if I will find any obstacles when I package it. The packaging guidelines
> allow packaging RPM macros, therefore this should be fine.
> 
> Also I am interested whether there are better options available.

In parted we have a signed upstream package and a detached signature. In
the pkg git we have the signer's public key and in %prep it runs gpg.

Source0: ftp://ftp.gnu.org/gnu/%{name}/%{name}-%{version}.tar.xz
Source1: ftp://ftp.gnu.org/gnu/%{name}/%{name}-%{version}.tar.xz.sig
Source2: pubkey.jim.meyering

gpg --import %{SOURCE2}
gpg --verify %{SOURCE1} %{SOURCE0}

What does gpg-offline add to this?

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)


pgpAJaxU21GjG.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora ARM Weekly Status Meeting Minutes 2013-07-10

[Brendan Conoboy]

Thank you everybody for joining today's Fedora-ARM meeting.  For those 
who were unable to attend the minutes are below.  Thank you!


Minutes: 
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-07-10/fedora-meeting-1.2013-07-10-20.02.html
Minutes (text): 
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-07-10/fedora-meeting-1.2013-07-10-20.02.txt
Log: 
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-07-10/fedora-meeting-1.2013-07-10-20.02.log.html



===
#fedora-meeting-1: Fedora ARM weekly status meeting
===

Meeting summary
---
* 0) Status of ACTION items from our previous meeting  (bconoboy,
  20:01:45)
  * LINK:

http://meetbot.fedoraproject.org/fedora-meeting-1/2013-06-19/fedora-meeting-1.2013-06-19-20.00.html
(bconoboy, 20:02:06)
  * aarch64 koji server setup: db host mostly setup. hub is pending
(bconoboy, 20:04:05)
  * ACTION: nirik to continue aarch64 koji server setup  (bconoboy,
20:04:15)
  * f19 release is taking priority  (bconoboy, 20:05:42)

* 1) Problem packages  (bconoboy, 20:06:35)
  * No update this week- check next week after F19 is out.  (bconoboy,
20:08:16)

* 2) Kernel Status Update  (bconoboy, 20:08:26)
  * OMAP4 broken on MP kernel with RC2  (bconoboy, 20:10:15)
  * May only be Panda-ES that's broken.  Panda-A3 reported successful.
(bconoboy, 20:14:50)

* 3) Aarch64 - Status Update, problem packages  (bconoboy, 20:15:36)
  * 10522/13595 packages built  (bconoboy, 20:17:16)
  * 535 packages are in the build queue currently  (bconoboy, 20:21:34)
  * Almost ready to retire stage3, just need gcc, and llvm rebuilt.
Maybe rpm.  (bconoboy, 20:23:14)

* 4) F19 GA - RC2 testing (VFAD?)  (bconoboy, 20:28:00)
  * Primary Go/NoGo decision is Thursday  (bconoboy, 20:31:44)
  * LINK: http://paste.fedoraproject.org/21123/ Panda ES boot issue with
RC2  (bconoboy, 20:33:55)
  * Current ARM release candidate is at
http://armpkgs.fedoraproject.org/mash/stage/19-RC2/  (bconoboy,
20:41:48)
  * LINK:

https://fedoraproject.org/wiki/Test_Results:Fedora_19_Final_RC2_Base?rd=Test_Results:Current_Base_Test
(masta, 20:42:48)
  * LINK:

https://fedoraproject.org/wiki/Test_Results:Fedora_19_Final_RC2_Desktop?rd=Test_Results:Current_Desktop_Test
(masta, 20:43:13)
  * LINK: Test the base:

https://fedoraproject.org/wiki/Test_Results:Fedora_19_Final_RC2_Base?rd=Test_Results:Current_Base_Test
(bconoboy, 20:43:39)
  * LINK: Test the desktop:

https://fedoraproject.org/wiki/Test_Results:Fedora_19_Final_RC2_Desktop?rd=Test_Results:Current_Desktop_Test
(bconoboy, 20:43:49)
  * LINK:

https://fedoraproject.org/wiki/Test_Results:Fedora_19_Final_RC2_Install?rd=Test_Results:Current_Installation_Test
(masta, 20:44:00)
  * LINK: Test anaconda installation:

https://fedoraproject.org/wiki/Test_Results:Fedora_19_Final_RC2_Install?rd=Test_Results:Current_Installation_Test
(bconoboy, 20:44:11)
  * Deadline for *successful* test completion is Friday  (bconoboy,
20:44:54)
  * Please test Wednesday and Thursday- update the tables, mention what
you're up to in #fedora-arm  (bconoboy, 20:45:29)
  * VFAD Friday 10AM US EDT, but don't wait- test now if at all
possible.  (bconoboy, 20:46:26)

* 5) Open Floor  (bconoboy, 20:47:31)
  * LINK: High level RC2 testing result page:
https://fedoraproject.org/wiki/Category:Fedora_19_ARM_RC2
(bconoboy, 20:51:53)
  * LINK: https://fedoraproject.org/wiki/Category:Fedora_19_ARM_RC2
(masta, 20:52:05)
  * page for recording Rc2 results  (masta, 20:52:20)
  * handsome_pirate looking for roomie at flock (Not johnny depp)-
contact if in need. rum optional.  (bconoboy, 20:53:19)


Action Items

* nirik to continue aarch64 koji server setup


Action Items, by person
---
* nirik
  * nirik to continue aarch64 koji server setup


People Present (lines said)
---
* bconoboy (116)
* masta (31)
* jcapik (23)
* nirik (14)
* jonmasters (13)
* msalter (9)
* zodbot (9)
* jsmith (8)
* pwhalen (5)
* handsome_pirate (5)
* dmarlin (3)
* ahs3 (1)
* j_dulaney (0)
* pbrobinson (0)
* ctyler (0)
* agreene (0)
* ddd (0)
* dgilmore (0)

--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Adam Williamson]

On Wed, 2013-07-10 at 12:09 -0400, Peter Jones wrote:

> > Is LXDE considered a release blocking desktop?  I honestly don't know.
> >  I also don't think it matters whether LXDE or FVMW2 or Gnome is the
> > default desktop on ARM.  The criteria should probably be that it ships
> > with a desktop that is considered release blocking.  If LXDE isn't
> > one, then perhaps it should be made so.  The goal here shouldn't be
> > "we have a desktop".  It should be "we have a desktop experience that
> > is the same on all primary architectures".  To that end, whichever
> > desktop is picked should be release blocking and it should function
> > the same on all primary architectures.
> 
> There's sort of a more central issue here that's causing this question -
> while the release criteria certainly are meant to be a way of evaluating
> if the release is complete and functional, there's some creep in of how
> we use them because of how they were developed.  Specifically, what
> they're implicitly testing is whether we've unexpectedly lost functionality
> (or quality) from the previous release.  Obviously that's not quite the
> metric in which we'll be evaluating arm as a PA.

I'm honestly not entirely sure what you mean by this. Could you explain
it again using short, monkey-friendly words? :)

When writing new criteria, or when doing the major re-write we did for
F19, the approach we take (or at least the one I take, for sure) is
simply to try and identify an attribute a Fedora milestone must have to
make it fit for purpose, and codify that in text. That's really it. The
concept of "whether we've unexpectedly lost functionality from the
previous release" is not one that I consciously, at least, hold in mind
when working on the criteria.

> That doesn't mean that the release criteria as they stand aren't good
> for ARM - but they're criteria for evaluating RCs, not the criteria for
> ARM as a PA.

> It's two different things, and it's important that we not confuse them.
> The question isn't "is $DESKTOP not working a release blocker" - it may
> or may not be.  The question is "is the infrastructure for normal
> desktops to work required to be a PA".

I certainly concur with this. The question we should be answering is
simply 'do we consider ARM to be worthy of being a PA yet?', and the
release criteria are not intended as a tool to help answer that
question. Rather, if the answer to that question is 'yes' but the
release criteria are not in line with a world in which ARM is a PA, we
should amend the release criteria. They are certainly not set in stone.

> And I think right now, the assumption from outside the ARM team has been
> that for ARM as a PA, we do want functionality to have parity with other
> PAs, and so yes, that infrastructure should be ready.
> 
> -- 
> Peter
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 Self Contained Change: Application Installer

[Adam Williamson]

On Wed, 2013-07-10 at 09:51 -0600, Kevin Fenzi wrote:
> On Wed, 10 Jul 2013 13:02:24 +0200
> Jaroslav Reznik  wrote:
> 
> > = Proposed Self Contained Change: Application Installer =
> > https://fedoraproject.org/wiki/Changes/AppInstaller
> > 
> > Change owner(s): Richard Hughes , together with
> > the desktop team
> > 
> > We will replace the existing gnome-packagekit frontends
> > (gpk-update-viewer and gpk-application) by a new application. 
> 
> Would there be any value in keeping those around for a cycle or so for
> folks that prefer package centric updates? Or better to just ask them
> to move to yum/yumex/apper now?

FWIW, everyone seems to hate gpk-application, so I doubt anyone would
shed any tears over its loss. =) And if gpk-update-viewer has any
committed fans, I ain't met 'em.

> > Other developers:
> > * Use gnome-software instead of gpk-update-viewer when dealing with
> > updates in gnome-settings-daemon, gnome-shell and
> > gnome-control-center 
> 
> I'm assuming this will be desktop/gnome centric? Or would it all just
> work in Xfce/LXDE/ratpoision sessions?

That's all GNOME-specific stuff, as I read it. None of this feature
looks like it particularly applies to other desktops.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Adam Williamson]

On Wed, 2013-07-10 at 09:46 -0600, Kevin Fenzi wrote:
> On Tue, 9 Jul 2013 22:36:39 +0100
> Peter Robinson  wrote:
> 
> > On Tue, Jul 9, 2013 at 10:11 PM, Till Maas 
> > wrote:
> 
> ...snip...
> 
> > > test instances for maintainers as described here:
> > > https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
> > 
> > I've never seen the above before.
> > 
> > There's instances available to QA
> > https://fedoraproject.org/wiki/Architectures/ARM/qa-machines
> 
> I was working on adding 2 more SOC's for packagers earlier this week. 
> 
> I wanted to see how much call there was for these... should I try and
> make them accessable by all packagers? Or just have a group and
> interested people could be added to that group?

They're probably useful for update testing, but I don't think they're
much use for release validation, since that generally equates to testing
deployment, which you can't really do from an ssh session.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Adam Williamson]

On Wed, 2013-07-10 at 13:56 +, "Jóhann B. Guðmundsson" wrote:
> On 07/10/2013 12:36 AM, Bill Nottingham wrote:
> 
> > Plus, in relation to this - the llvmpipe issue brings up that one of
> > the 'release blocking desktops' *does not work*. This would, by definition,
> > block the release unless we intend to have different criteria for ARM as a
> > primary arch.
> 
> Then we should remove the default label and "release blocking
> desktop(s)" entirely concept with it. 
> 
> It's far outdated anyway and relic from the past.  
> 
> Each sub-community ( be it spins be it various arch ) should need to
> provide the necessary QA/Releng resources from their sub-community
> ( if no such thing the relevant party needs to build one ) while we QA
> and Releng focus our available resources on the components that
> everyone in the whole distribution use and provide the necessary sub
> community with the assistance in relation to QA and Releng.

I'm afraid I can't agree. I like the simplicity of the model you're
proposing, but from a practical point of view, there is still a commonly
held perception that there is a 'product' called Fedora which is
basically composed of what you get if you go to get.fedoraproject.org,
download one of the things we push at you there, and install it.
Practically speaking, I believe we have to QA that 'thing called Fedora'
as a whole. I don't think your model quite matches what people perceive
Fedora to be.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Adam Williamson]

On Wed, 2013-07-10 at 07:45 -0400, Josh Boyer wrote:
> On Wed, Jul 10, 2013 at 6:02 AM, Jaroslav Reznik  wrote:
> > - Original Message -
> >> Adam Williamson (awill...@redhat.com) said:
> >> > I've had an entry on my todo list _forever_ to complete the
> >> > 'deliverables SOP' I started several releases ago:
> >> >
> >> > https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables
> >> >
> >> > (I don't really like the current layout, I was planning on revising it)
> >> >
> >> > The addition of a new arch with quite a pile of 'supported images'
> >> > would certainly raise the priority of having such a thing. (We're
> >> > already hitting a problem with our *current* primary arches in this
> >> > area, though, in that the status of the multi-live, multi-arch and
> >> > cloud/appliance images is rather unclear).
> >>
> >> Plus, in relation to this - the llvmpipe issue brings up that one of
> >> the 'release blocking desktops' *does not work*. This would, by definition,
> >> block the release unless we intend to have different criteria for ARM as a
> >> primary arch.
> >
> > I don't see a problem with different set of blocking desktops for ARM, even
> > as primary architecture. But it's really about resources - do we have people
> > willing to work for example on LXDE (I'd say more resources friendly for
> > current ARMs) - not saying there are no people, but more to support it as
> > blocking desktop, if QA would be able to validate three desktops on two
> > different platforms... And as we try to avoid "default" world in Fedora now,
> > let's have LXDE "default" in some cases.
> 
> Is LXDE considered a release blocking desktop?  I honestly don't know.

No. The release blocking desktops are KDE and GNOME. This is stated in
the preamble of all release criteria pages, for lack of anywhere better
to state it.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Peter Robinson]

On Wed, Jul 10, 2013 at 9:43 PM, Richard W.M. Jones  wrote:
> On Wed, Jul 10, 2013 at 06:14:24PM +0200, Björn Persson wrote:
>> Kevin Fenzi wrote:
>> > I was working on adding 2 more SOC's for packagers earlier this week.
>> >
>> > I wanted to see how much call there was for these... should I try and
>> > make them accessable by all packagers? Or just have a group and
>> > interested people could be added to that group?
>>
>> I for one would like to have access to some ARM systems for trying
>> things out. At least one for each arch that's a candidate to become
>> primary would be nice.
>
> I appreciate that some people cannot or don't want to buy hardware,
> but if you did have roughly $300 available, then you should probably
> get the Oct 2012 Samsung Chromebook or the Arndale development board.
> The Chromebook has the advantage IMHO that it's a decent netbook.

$45 will get your a beaglebone which the last of the core support has
landed in 3.11 and I'm testing the kernel now and there should be a
F-19 remix soon...

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Richard W.M. Jones]

On Wed, Jul 10, 2013 at 04:17:47PM +0100, Caolán McNamara wrote:
> On Wed, 2013-07-10 at 08:28 -0400, Aleksandar Kurtakov wrote:
> > I still have serious concerns regarding build times:
> > * arm - https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=150248 ~ 
> > 17h
> > * current primary - 
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=429023 ~1h 30m
> > 
> > This is still too huge gap - roughly 10 times slower. If ARM will become 
> > primary arch I hope this is an exception and not the general rule.
> 
> FWIW, the last libreoffice arm build of
> https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=152413, took
> approx 14 hours. While
> https://koji.fedoraproject.org/koji/buildinfo?buildID=432079 took approx
> 5 hours on x86
> 
> I can probably live with that without to much suffering, but it does
> push build times from "start build today, get result today" to "start
> build today, get results tomorrow".

Just a note that Koji is currently configured to time out builds after
24 hours.

Not that you'd want your builds taking longer than this, but it's may
affect the discussion ...

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

Re: F20 System Wide Change: ARM as primary Architecture

[Richard W.M. Jones]

On Wed, Jul 10, 2013 at 06:14:24PM +0200, Björn Persson wrote:
> Kevin Fenzi wrote:
> > I was working on adding 2 more SOC's for packagers earlier this week. 
> > 
> > I wanted to see how much call there was for these... should I try and
> > make them accessable by all packagers? Or just have a group and
> > interested people could be added to that group?
> 
> I for one would like to have access to some ARM systems for trying
> things out. At least one for each arch that's a candidate to become
> primary would be nice.

I appreciate that some people cannot or don't want to buy hardware,
but if you did have roughly $300 available, then you should probably
get the Oct 2012 Samsung Chromebook or the Arndale development board.
The Chromebook has the advantage IMHO that it's a decent netbook.

For more hardware options see:

  https://fedoraproject.org/wiki/Category:Fedora_ARM_Hardware

Don't get an R-Pi.  Not anything against it, just that it's a very old
and obsolete variant of the ARM architecture, and no longer supported
in Fedora (since Fedora 19 IIRC).

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: F20 Self Contained Change: Application Installer

[Adam Williamson]

On Wed, 2013-07-10 at 13:02 +0200, Jaroslav Reznik wrote:
> = Proposed Self Contained Change: Application Installer =
> https://fedoraproject.org/wiki/Changes/AppInstaller
> 
> Change owner(s): Richard Hughes , together with the 
> desktop team
> 
> We will replace the existing gnome-packagekit frontends (gpk-update-viewer 
> and 
> gpk-application) by a new application. 

Yay!

> == Detailed description ==
> The current PackageKit frontends are focused on (surprise!) packages.
> 
> The new tool, tentatively named gnome-software, is designed from the 
> beginning 
> for installing applications. It will present applications with information 
> that is relevant to users (screenshots, reviews, descriptions, ratings,...) 
> instead of information that is relevant for packagers (dependencies, package 
> size, file lists,...).
> 
> It will be possible to search and browse for available applications.
> 
> gnome-software will also be used to present information about available and 
> installed updates. Notifications about available updates will launch gnome-
> software if the user chooses to see details. gnome-software will be fully 
> integrated with 'offline updates' - if an update includes system packages, it 
> will be done as an offline update, regardless whether it gets initiated from 
> the 
> gnome-shell menu, a notification, or the gnome-software UI.

This sounds like a nice plan and will finally resolve
https://bugzilla.redhat.com/show_bug.cgi?id=863592 . I'd just like to
note that at present our release requirements are basically that the
'official' update methods have to work at Alpha:

"The installed system must be able to download and install updates with
yum and with the default graphical package manager in all
release-blocking desktops."

https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Updates

Is the planned development timeframe for this Change such that we can
expect this requirement to be satisfied?

Note that update notification is required to work starting from Beta
rather than Alpha:

"Release-blocking desktops must notify the user of available updates,
but must not do so when running as a live image."

https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Update_notification

> Other developers:
> * Use gnome-software instead of gpk-update-viewer when dealing with updates 
> in 
> gnome-settings-daemon, gnome-shell and gnome-control-center 

We really need to ensure the necessary co-ordination is done so that
this happens, and the online/offline update mess is cleared up for F20
Alpha.

> Policies and guidelines:
> * No immediate changes needed; longer-term, we probably want to make changes 
> to way applications are distributed and installed
> * The update experience will also benefit from proposed changes to batch 
> updates 

* The release criterion may need to be reworded, depending on whether
the concept of "download and install updates with the default graphical
package manager" really applies to the design.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Virtualization on ARM (was: Re: F20 System Wide Change: ARM as primary Architecture)

[Richard W.M. Jones]

On Tue, Jul 09, 2013 at 11:32:46AM -0400, Jonathan Masters wrote:
> Excellent proposal. I of course think this would be just awesome!

This proposal doesn't address virtualization!

I think this is great, BUT I'd also like to see a widely available
cheap ARM platform that supports virtualization, AND for which
virtualization genuinely works out of the box.

Because, otherwise we can't start properly getting libvirt and the
rest of the virt stack working.

The ARM-based Samsung Chromebook[0] is nearly there, although as
discussed on the arm list last week[1], there are either some missing
bits, or no one's brought all the bits together.

Rich.

[0] Cost around $300, and several virt developers have them already,
plus they are quite good Fedora development machines in and of
themselves.

[1] https://lists.fedoraproject.org/pipermail/arm/2013-July/thread.html#6319

-- 
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

Schedule for Thursday's FPC Meeting (2013-07-11 16:00 UTC)

[James Antill]

Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2013-06-27 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. rktime):

2013-07-11 09:00 Thu US/Pacific PDT
2013-07-11 12:00 Thu US/Eastern EDT
2013-07-11 16:00 Thu UTC <-
2013-07-11 17:00 Thu Europe/London  BST
2013-07-11 18:00 Thu Europe/Paris  CEST
2013-07-11 18:00 Thu Europe/Berlin CEST
2013-07-11 21:30 Thu Asia/Calcutta  IST
--new day--
2013-07-12 00:00 Fri Asia/Singapore SGT
2013-07-12 00:00 Fri Asia/Hong_Kong HKT
2013-07-12 01:00 Fri Asia/Tokyo JST
2013-07-12 02:00 Fri Australia/Brisbane EST

 Links to all tickets below can be found at: 

https://fedorahosted.org/fpc/report/12

= Followups =

#297Bundling exception for nodejs-expect-js
.fpc 297
https://fedorahosted.org/fpc/ticket/297

= New business =

#308Please deprecate usage of systemd-sysv-convert in the packaging
policy for F20
.fpc 308
https://fedorahosted.org/fpc/ticket/308

#310Request review of httpd-itk
.fpc 310
https://fedorahosted.org/fpc/ticket/310

#311Node.js guidelines update
.fpc 311
https://fedorahosted.org/fpc/ticket/311

#312Architecture specific header files
.fpc 312
https://fedorahosted.org/fpc/ticket/312

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://fedorahosted.org/fpc/report/12


 If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Moving xine-lib and dependent apps to RPM Fusion Free for F17?

[Martin Sourada]

Hi,

On Wed, 10 Jul 2013 10:58:22 +0200 
Xavier Bachelot wrote:

> Hi,
> 
> On 01/05/2012 08:56 PM, Kevin Kofler wrote:
> > The following packages currently depend on xine-lib:
> > * gxine
> > * (k9copy – already in RPM Fusion, not affected)
> > * kaffeine (my package, the reason why I maintain xine-lib in the first
> > place)
> > * oxine
> > * xine-plugin
> > * xine-ui
> > These packages would have to move to RPM Fusion along with xine-lib.
> 
> Fwiw, I've rebuilt all the above packages (but k9copy, not tested yet) 
> against the xine-lib 1.2.3 rpm I prepared and all the builds succeeded. 
> No runtime tests yet.
> 
> Would all the impacted maintainers be ok to move their package to RPM 
> Fusion, alongside with xine-lib 1.2 ?
> 
> Regards,
> Xavier
I'd welcome volunteer to take gxine over from me as I'm not using it anymore
myself and upstream isn't very dynamic either (I went through switching
between various javascript versions in Fedora because mozilla folks keep
breaking API/ABI hyperfast all too much; AFAIK current mozjs from xulrunner
still isn't supported). But if no-one volunteers I'll maintain gxine in
rpmfusion as well. But seriously, CVS and plague? That's stone age for me...
Will need to refresh my memory...

Regards,
Martin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Planned Outage: koji storage move - 2013-07-18 21:00 UTC

[Kevin Fenzi]

 Planned Outage: koji storage move - 2013-07-18 21:00 UTC

 There will be an outage starting at 2013-07-18 21:00 UTC, which will
 last approximately 24 hours.

 To convert UTC to your local time, take a look at
 http://fedoraproject.org/wiki/Infrastructure/UTCHowto
 or run:

 date -d '2013-07-18 21:00 UTC'

 Reason for outage:

 We are moving our koji package storage from one backend device to
 another, which requires a final rsync of a lot of data. During this
 outage, koji will not be available to build or download packages from,
 and the 2013-07-19 rawhide compose will not occur.
 pkgs.fedoraproject.org will be available and you can commit changes,
 but no builds will be possible. Updates pushes will not happen in this
 window either.

 Additionally, we will be tweaking our koji database during this window
 to improve it's performance.

 Affected Services:

 Buildsystem - http://koji.fedoraproject.org/

 Unaffected Services:

 Ask Fedora - http://ask.fedoraproject.org/

 BFO - http://boot.fedoraproject.org/

 Blockerbugs - https://qa.fedoraproject.org/blockerbugs/

 Bodhi - https://admin.fedoraproject.org/updates/

 GIT / Source Control - pkgs.fedoraproject.org

 DNS - ns-sb01.fedoraproject.org, ns02.fedoraproject.org,
 ns04.fedoraproject.org, ns05.fedoraproject.org

 Docs - http://docs.fedoraproject.org/

 Email system

 Fedora Account System - https://admin.fedoraproject.org/accounts/

 Fedora Community - https://admin.fedoraproject.org/community/

 Fedora Calendar - https://apps.fedoraproject.org/calendar/

 Fedora Hosted - https://fedorahosted.org/

 Fedora OpenID - https://id.fedoraproject.org/

 Fedora People - http://fedorapeople.org/

 Main Website - http://fedoraproject.org/

 Mirror List - https://mirrors.fedoraproject.org/

 Mirror Manager - https://admin.fedoraproject.org/mirrormanager/

 Package Database - https://admin.fedoraproject.org/pkgdb/

 QA Services

 Secondary Architectures

 Spins - http://spins.fedoraproject.org/

 Start - http://start.fedoraproject.org/

 Torrent - http://torrent.fedoraproject.org/

 Wiki - http://fedoraproject.org/wiki/

 Contact Information:

 Ticket Link:

 https://fedorahosted.org/fedora-infrastructure/ticket/3882

 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add
 comments to the ticket for this outage above.


signature.asc
Description: PGP signature
___
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: F20 System Wide Change: ARM as primary Architecture

[Kevin Fenzi]

On Wed, 10 Jul 2013 15:06:50 -0400 (EDT)
Aleksandar Kurtakov  wrote:

> Yeah, I know the reasons but still this would make it really hard for
> us to push changes or test a build fix. I would like all archs to
> have equal attention but not at the price of others. I still have bad
> memories from ppc building eclipse for similar time and thus causing
> huge delays. We usually update most of the Eclipse packages
> simultaneously (build order matters) as they are released on the same
> date if builds are gonna take that will be big hurdle for us. 3-4
> times slower is acceptable but more than that becomes a problem.

Interested folks can go look at:

http://arm.koji.fedoraproject.org/

and find packages they care about (please look at f19 or rawhide
builds, as f17/f18 ones also build for armv5tel and will take a lot
longer to build). 

We did experiment with SSD disk in the ARM SOC's, but that didn't seem
to help very much at all (ie, the build is mostly cpu bound, not i/o).
Arm builders are also currently Fedora 18. Moving to F19 might help,
not sure. 

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Aleksandar Kurtakov]

- Original Message -
> From: "Peter Robinson" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, July 10, 2013 9:17:49 PM
> Subject: Re: F20 System Wide Change: ARM as primary Architecture
> 
> On Wed, Jul 10, 2013 at 1:28 PM, Aleksandar Kurtakov
>  wrote:
> > - Original Message -
> >> From: "Josh Boyer" 
> >> To: "Development discussions related to Fedora"
> >> 
> >> Sent: Wednesday, July 10, 2013 2:45:53 PM
> >> Subject: Re: F20 System Wide Change: ARM as primary Architecture
> >>
> >> On Wed, Jul 10, 2013 at 6:02 AM, Jaroslav Reznik 
> >> wrote:
> >> > - Original Message -
> >> >> Adam Williamson (awill...@redhat.com) said:
> >> >> > I've had an entry on my todo list _forever_ to complete the
> >> >> > 'deliverables SOP' I started several releases ago:
> >> >> >
> >> >> > https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables
> >> >> >
> >> >> > (I don't really like the current layout, I was planning on revising
> >> >> > it)
> >> >> >
> >> >> > The addition of a new arch with quite a pile of 'supported images'
> >> >> > would certainly raise the priority of having such a thing. (We're
> >> >> > already hitting a problem with our *current* primary arches in this
> >> >> > area, though, in that the status of the multi-live, multi-arch and
> >> >> > cloud/appliance images is rather unclear).
> >> >>
> >> >> Plus, in relation to this - the llvmpipe issue brings up that one of
> >> >> the 'release blocking desktops' *does not work*. This would, by
> >> >> definition,
> >> >> block the release unless we intend to have different criteria for ARM
> >> >> as a
> >> >> primary arch.
> >> >
> >> > I don't see a problem with different set of blocking desktops for ARM,
> >> > even
> >> > as primary architecture. But it's really about resources - do we have
> >> > people
> >> > willing to work for example on LXDE (I'd say more resources friendly for
> >> > current ARMs) - not saying there are no people, but more to support it
> >> > as
> >> > blocking desktop, if QA would be able to validate three desktops on two
> >> > different platforms... And as we try to avoid "default" world in Fedora
> >> > now,
> >> > let's have LXDE "default" in some cases.
> >>
> >> Is LXDE considered a release blocking desktop?  I honestly don't know.
> >>  I also don't think it matters whether LXDE or FVMW2 or Gnome is the
> >> default desktop on ARM.  The criteria should probably be that it ships
> >> with a desktop that is considered release blocking.  If LXDE isn't
> >> one, then perhaps it should be made so.  The goal here shouldn't be
> >> "we have a desktop".  It should be "we have a desktop experience that
> >> is the same on all primary architectures".  To that end, whichever
> >> desktop is picked should be release blocking and it should function
> >> the same on all primary architectures.
> >>
> >> > For build times, Dennis has numbers prepared, we decided to let it out
> >> > of
> >> > the proposal and send it for discussion.
> >>
> >> There was significant concern on this during the first time this came
> >> up for discussion.  I think the proposal should at least include a
> >> link to the overall build time improvements.  Clearly there has been
> >> improvement, so make the proposal show that.
> >
> > I still have serious concerns regarding build times:
> > * arm - https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=150248 ~
> > 17h
> > * current primary -
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=429023 ~1h 30m
> >
> > This is still too huge gap - roughly 10 times slower. If ARM will become
> > primary arch I hope this is an exception and not the general rule.
> 
> That build gap is due to java not being the fully accelerated one, I
> know there's work being done there but it's been a while since I heard
> the latest state, the last of which was "soon"

Yeah, I know the reasons but still this would make it really hard for us to 
push changes or test a build fix. I would like all archs to have equal 
attention but not at the price of others.
I still have bad memories from ppc building eclipse for similar time and thus 
causing huge delays. We usually update most of the Eclipse packages 
simultaneously (build order matters) as they are released on the same date if 
builds are gonna take that will be big hurdle for us. 
3-4 times slower is acceptable but more than that becomes a problem.

Alexander Kurtakov
Red Hat Eclipse Team

> 
> Peter
> --
> 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: F20 System Wide Change: ARM as primary Architecture

[Peter Robinson]

On Wed, Jul 10, 2013 at 6:36 PM, Jakub Jelinek  wrote:
> On Wed, Jul 10, 2013 at 11:19:33AM -0500, Dennis Gilmore wrote:
>> armv7 has stack protector, aarch64 which is outside of this proposal
>> doesnt yet have it.
>
> Only i?86/x86_64/ppc/ppc64/s390/s390x/sparc/sparc64/tilegx/tilepro
> really have full stack protector support, while perhaps -fstack-protector
> doesn't error out on armv7, it certainly isn't supported in glibc
> (neither TLS stack guard, not TLS pointer guard), so I wouldn't talk about
> arm having security standards high enough for being a primary architecture.

So what does the kernel level CC_STACKPROTECTOR config option bring to
this as it appears to be associated with the -fstack-protector option
as well (according to it's Kconfig description) but is only supported
on x86/arm from that list above (plus sh).

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Peter Robinson]

On Wed, Jul 10, 2013 at 5:06 PM, Josh Boyer  wrote:
> On Wed, Jul 10, 2013 at 11:57 AM, Till Maas  wrote:
>> On Tue, Jul 09, 2013 at 10:36:39PM +0100, Peter Robinson wrote:
>>> On Tue, Jul 9, 2013 at 10:11 PM, Till Maas  wrote:
>>
>>> > Which hardware is supported by ARMv7 hfp 32bit builds? Will there be
>>>
>>> http://fedoraproject.org/wiki/Architectures/ARM
>>>
>>> The list is expanding regularly and there's a lot of other hardware
>>> currently supported by remix primarily because the complete kernel
>>> support isn't upstream.
>>
>> So eventually Raspberry Pi and Cubieboard devices will be supported when
>> their kernel patches are upstreamed?
>
> Raspberry Pi is an ARMv6 device, so no.  I have no idea about Cubieboard.

Cubieboard is an Allwinner A10 device which is ARMv7 so will be
supported once it lands upstream. The core SoC support is there and
enabled but it's not much use without storage and various other bits.
Networking landed in mainline kernel yesterday for example.

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Peter Robinson]

On Wed, Jul 10, 2013 at 1:28 PM, Aleksandar Kurtakov
 wrote:
> - Original Message -
>> From: "Josh Boyer" 
>> To: "Development discussions related to Fedora" 
>> 
>> Sent: Wednesday, July 10, 2013 2:45:53 PM
>> Subject: Re: F20 System Wide Change: ARM as primary Architecture
>>
>> On Wed, Jul 10, 2013 at 6:02 AM, Jaroslav Reznik  wrote:
>> > - Original Message -
>> >> Adam Williamson (awill...@redhat.com) said:
>> >> > I've had an entry on my todo list _forever_ to complete the
>> >> > 'deliverables SOP' I started several releases ago:
>> >> >
>> >> > https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables
>> >> >
>> >> > (I don't really like the current layout, I was planning on revising it)
>> >> >
>> >> > The addition of a new arch with quite a pile of 'supported images'
>> >> > would certainly raise the priority of having such a thing. (We're
>> >> > already hitting a problem with our *current* primary arches in this
>> >> > area, though, in that the status of the multi-live, multi-arch and
>> >> > cloud/appliance images is rather unclear).
>> >>
>> >> Plus, in relation to this - the llvmpipe issue brings up that one of
>> >> the 'release blocking desktops' *does not work*. This would, by
>> >> definition,
>> >> block the release unless we intend to have different criteria for ARM as a
>> >> primary arch.
>> >
>> > I don't see a problem with different set of blocking desktops for ARM, even
>> > as primary architecture. But it's really about resources - do we have
>> > people
>> > willing to work for example on LXDE (I'd say more resources friendly for
>> > current ARMs) - not saying there are no people, but more to support it as
>> > blocking desktop, if QA would be able to validate three desktops on two
>> > different platforms... And as we try to avoid "default" world in Fedora
>> > now,
>> > let's have LXDE "default" in some cases.
>>
>> Is LXDE considered a release blocking desktop?  I honestly don't know.
>>  I also don't think it matters whether LXDE or FVMW2 or Gnome is the
>> default desktop on ARM.  The criteria should probably be that it ships
>> with a desktop that is considered release blocking.  If LXDE isn't
>> one, then perhaps it should be made so.  The goal here shouldn't be
>> "we have a desktop".  It should be "we have a desktop experience that
>> is the same on all primary architectures".  To that end, whichever
>> desktop is picked should be release blocking and it should function
>> the same on all primary architectures.
>>
>> > For build times, Dennis has numbers prepared, we decided to let it out of
>> > the proposal and send it for discussion.
>>
>> There was significant concern on this during the first time this came
>> up for discussion.  I think the proposal should at least include a
>> link to the overall build time improvements.  Clearly there has been
>> improvement, so make the proposal show that.
>
> I still have serious concerns regarding build times:
> * arm - https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=150248 ~ 17h
> * current primary - 
> https://koji.fedoraproject.org/koji/buildinfo?buildID=429023 ~1h 30m
>
> This is still too huge gap - roughly 10 times slower. If ARM will become 
> primary arch I hope this is an exception and not the general rule.

That build gap is due to java not being the fully accelerated one, I
know there's work being done there but it's been a while since I heard
the latest state, the last of which was "soon"

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora ARM Weekly Status Meeting 2013-07-10

[Brendan Conoboy]

ARM enthusiasts and watchers,

Please join us today (Wednesday, July 10th) at 4PM EDT (8PM UTC)
for the Fedora ARM weekly status meeting in #fedora-meeting-1 on Freenode.

On the agenda so far:

1) Problem packages

2) Kernel Status Update

3) Aarch64 - Status Update, problem packages
   - Aarch64 Koji VM

4) F20 PA Promotion

5) Open Floor

If there is something that you would like to discuss that isn't 
mentioned please feel free to bring it up at the end of the meeting or 
send an email to the list.  Cheers,


--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 Self Contained Change: GLIBC 2.18

[Toshio Kuratomi]

Oops as noted by jreznik, this thread took a brief detour onto the docs list
by mistake.

On Wed, Jul 10, 2013 at 11:47:30AM -0400, Robyn Bergeron wrote:
> 
> 
> - Original Message -
> > From: "Toshio Kuratomi" 
> > To: "For participants of the Documentation Project" 
> > 
> > Sent: Wednesday, July 10, 2013 8:37:10 AM
> > Subject: Re: F20 Self Contained Change: GLIBC 2.18
> > 
> > On Tue, Jul 09, 2013 at 04:14:22PM -0700, Adam Williamson wrote:
> > > On 2013-07-08 7:52, Jaroslav Reznik wrote:
> > > >= Proposed Self Contained Change: GLIBC 2.18 =
> > > 
> > > ?!
> > > 
> > > A bump of glibc seems like virtually the definition of a system-wide
> > > change. Sure, it's _intended_ to be transparently compatible with
> > > 2.17, but we've seen how that goes before.
> > >
> > +1
> > 
> > For most libraries I think that an api-compatible version bump wouldn't need
> > to even go through the Planning process.  But some things, like glibc, are
> > depended upon by so many other things that they need to be system-wide
> > changes so that people can be on the lookout for unexpected problems that it
> > might cause.
> 
> Is it just a matter of "requires a mass rebuild of some sort? If yes, then 
> $X; if no, then $Y" ?
> 
For most libraries, that's probably a good rule of thumb.  I can think of
some caveats to the rule of thumb though:

* Libraries can also refer to scripting languages' modules which might not
  need a mass rebuild.
* Changes may not change the API/ABI or SONAME of elf libraries so they don't
  need a mass rebuild but they still might require testing or coordination
  across many packages.
** The setuptools update:
  https://fedoraproject.org/wiki/Changes/Python_setuptools_0.7
  Is an example of both of those caveats -- it's a scripting language and
  the changes are not supposed to change API.  But the update is an upstream
  rewrite of a large amount of the codebase and the package is used by
  a large number of other packages in Fedora.  So testing and communication
  of the change is the reason for the System-wide-change designation.

glibc, I think, is an extreme example of the second caveat.  glibc has an
effect on close to everything in the distirbution.  Upstream rebases should
probably always be treated as system-wide changes so that other packagers
can watch out for bugs or changes in behaviour that might be due to glibc
rather than their own package's code.

-Toshio


pgpJnkcPgoZ2U.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Jakub Jelinek]

On Wed, Jul 10, 2013 at 11:19:33AM -0500, Dennis Gilmore wrote:
> armv7 has stack protector, aarch64 which is outside of this proposal
> doesnt yet have it.

Only i?86/x86_64/ppc/ppc64/s390/s390x/sparc/sparc64/tilegx/tilepro
really have full stack protector support, while perhaps -fstack-protector
doesn't error out on armv7, it certainly isn't supported in glibc
(neither TLS stack guard, not TLS pointer guard), so I wouldn't talk about
arm having security standards high enough for being a primary architecture.

CCing Carlos so that they can discuss that.

Jakub
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Schedule for Wednesday's FESCo Meeting (2013-07-10)

[Jaroslav Reznik]

- Original Message -
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 07/10/2013 01:14 PM, Matthew Miller wrote:
> > On Tue, Jul 09, 2013 at 09:43:04AM -0700, Toshio Kuratomi wrote:
> >> Note: As of this writing, the agenda for this week is very light.
> >> The one known agenda item is waiting on information which hasn't
> >> been submitted yet. If you have something to discuss, please
> >> reply to this e-mail ASAP so we can discuss it in the meeting.
> >> If we don't get more information on the one agenda item or other
> >> things people want to discuss we may cancel the meeting.  Thanks
> >> for your participation! -Toshio
> > 
> > I am really, really, really okay with cancelling the meeting this
> > week.

I have one item [1], with proposal in the ticket and I don't insist
on bringing it to the meeting (and forcing FESCo to meet ;-). I'd 
just like to clarify it.

[1] https://fedorahosted.org/fesco/ticket/1134

Jaroslav

> > 
> 
> I'm fine with canceling as well. Note: I will not be around for next
> week's meeting either.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iEYEARECAAYFAlHdmIAACgkQeiVVYja6o6PMsgCfVNBSNRyPXG6i5RquVK9dtxoh
> MSgAoLB4g+IyxakjGVy9S7t9dR/vy1N5
> =ueQr
> -END PGP SIGNATURE-
> --
> 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: F20 System Wide Change: ARM as primary Architecture

[Jóhann B. Guðmundsson]

On 07/10/2013 04:09 PM, Peter Jones wrote:

That doesn't mean that the release criteria as they stand aren't good
for ARM - but they're criteria for evaluating RCs, not the criteria for
ARM as a PA.


Right



It's two different things, and it's important that we not confuse them.
The question isn't "is $DESKTOP not working a release blocker" - it may
or may not be.  The question is "is the infrastructure for normal
desktops to work required to be a PA".
I would think that each sub community like for example Gnome would be 
the ones ultimately responsible for setting/creating their own release 
criteria surrounding Gnome, testing it and arguable also be the ones who 
decide which primary architectures it would be released on based on 
their ( sub-community ) release cycle while KDE for example would have 
completely another release cycle aligned to it's upstream.


But as things stand now neither our infrastructure,releng,qa and general 
procedures allow for such flexibility and adoption by sub-communities ( 
but should be something for us to work towards to ).


so for PA to become primary I would think the only requirement would be 
does our components build correctly for that architecture not necessary 
work ( with the exception of the base/core OS ) since it would be up to 
the sub-communities to ensure the releases on the PA which they intend 
to release on meets their criteria and works at release time.



And I think right now, the assumption from outside the ARM team has been
that for ARM as a PA, we do want functionality to have parity with other
PAs, and so yes, that infrastructure should be ready.


I would think so as well.

JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads up, new cfitsio 3.350 in rawhide

[Jon Ciesla]

On Wed, Jul 10, 2013 at 12:11 PM, Sergio Pascual wrote:

> Hello, a new cfitsio (3.350) is going to land tomorrow in rawhide. This
> version comes with a significant change, upstream provides a soname for the
> shared library. This means that hopefully updating cfitsio won't be so
> painful in the future.
>
> 

-J


> Regards, Sergio
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>



-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Schedule for Wednesday's FESCo Meeting (2013-07-10)

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/10/2013 01:14 PM, Matthew Miller wrote:
> On Tue, Jul 09, 2013 at 09:43:04AM -0700, Toshio Kuratomi wrote:
>> Note: As of this writing, the agenda for this week is very light.
>> The one known agenda item is waiting on information which hasn't
>> been submitted yet. If you have something to discuss, please
>> reply to this e-mail ASAP so we can discuss it in the meeting.
>> If we don't get more information on the one agenda item or other
>> things people want to discuss we may cancel the meeting.  Thanks
>> for your participation! -Toshio
> 
> I am really, really, really okay with cancelling the meeting this
> week.
> 
> 

I'm fine with canceling as well. Note: I will not be around for next
week's meeting either.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHdmIAACgkQeiVVYja6o6PMsgCfVNBSNRyPXG6i5RquVK9dtxoh
MSgAoLB4g+IyxakjGVy9S7t9dR/vy1N5
=ueQr
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Schedule for Wednesday's FESCo Meeting (2013-07-10)

[Matthew Miller]

On Tue, Jul 09, 2013 at 09:43:04AM -0700, Toshio Kuratomi wrote:
> Note: As of this writing, the agenda for this week is very light.  The one
> known agenda item is waiting on information which hasn't been submitted yet.
> If you have something to discuss, please reply to this e-mail ASAP so we
> can discuss it in the meeting.  If we don't get more information on the one
> agenda item or other things people want to discuss we may cancel the
> meeting.  Thanks for your participation! -Toshio

I am really, really, really okay with cancelling the meeting this week.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Heads up, new cfitsio 3.350 in rawhide

[Sergio Pascual]

Hello, a new cfitsio (3.350) is going to land tomorrow in rawhide. This
version comes with a significant change, upstream provides a soname for the
shared library. This means that hopefully updating cfitsio won't be so
painful in the future.

Regards, Sergio
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Chris Murphy]

On Jul 10, 2013, at 8:29 AM, Matthew Garrett  wrote:

>  If ARM merely wants to be 
> able to produce something that's similar to Fedora then we should figure 
> out what a spin-based PA would look like, but that's not what's 
> currently being proposed.

For F20, this makes more sense to me as a next step, before going whole hog 
with all release blocking desktops. Seems like the latter is a lot of chew off 
for F20. I think more community maturation is needed to get both dev and QA 
capable users, who also have an appropriate range of hardware, to support the 
new platform. It sounds like the existing community would be eyeballs deep.

Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 10 Jul 2013 17:57:43 +0200
Till Maas  wrote:

> On Tue, Jul 09, 2013 at 10:36:39PM +0100, Peter Robinson wrote:
> > On Tue, Jul 9, 2013 at 10:11 PM, Till Maas 
> > wrote:
> 
> > > Which hardware is supported by ARMv7 hfp 32bit builds? Will there
> > > be
> > 
> > http://fedoraproject.org/wiki/Architectures/ARM
> > 
> > The list is expanding regularly and there's a lot of other hardware
> > currently supported by remix primarily because the complete kernel
> > support isn't upstream.
> 
> So eventually Raspberry Pi and Cubieboard devices will be supported
> when their kernel patches are upstreamed? 

Raspberry Pi will never be a supported device as its armv6,  but
cubieboard yes. there is a cubieboard dtb in our kernel today but not
all support is upstream yet.  but yes cubieboard will in time be
supported.

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlHdj2gACgkQkSxm47BaWfee3ACeNQfjp9FOVjCGbsxgoEHYR0tw
AWIAn0cVc1OqaWFbBWjfsaL2DGNAnvea
=eIi1
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Kyle McMartin]

On Wed, Jul 10, 2013 at 11:19:33AM -0500, Dennis Gilmore wrote:
> armv7 has stack protector, aarch64 which is outside of this proposal
> doesnt yet have it.
> from redhat-rpm-config 
> 

just because gcc accepts a flag, doesn't mean it has been implemented in
the compiler.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Peter Jones]

On Wed, Jul 10, 2013 at 11:19:33AM -0500, Dennis Gilmore wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Tue, 9 Jul 2013 16:33:28 -0400
> Peter Jones  wrote:
> 
> > On Tue, Jul 09, 2013 at 06:50:07PM +0100, Matthew Garrett wrote:
> > > llvmpipe has been known to be broken for months, and nobody on the
> > > ARM team appears capable of fixing it. As a result, ARM shipped in
> > > F19 without any out of the box support for running our default
> > > desktop.
> > > 
> > > This doesn't make it seem like the ARM port currently has
> > > sufficient developer expertise involved, and I'd really like to
> > > hear what the plans are for (a) fixing the existing problems, and
> > > (b) ensuring that we don't end up in a situation where other
> > > architectures are held up because there's nobody who can fix
> > > ARM-specific bugs.
> > 
> > 
> > I'm also concerned that stack protector does not workyet at all.
> > Even if the desktop was useable, how would we tell people that it's
> > okay to run e.g. firefox with a straight face?  It's not as bad as
> > if, say, selinux didn't work, but it's a significant concern.
> > 
> 
> armv7 has stack protector, aarch64 which is outside of this proposal
> doesnt yet have it.
> from redhat-rpm-config 
> 
> redhat-rpm-config-9.1.0/rpmrc:optflags: armv7hl %{__global_cflags} 
> -march=armv7-a -mfpu=vfpv3-d16  -mfloat-abi=hard
> redhat-rpm-config-9.1.0/rpmrc:optflags: aarch64 %{__global_cflags}
> - -fno-stack-protector
> redhat-rpm-config-9.1.0/macros:%__global_cflags   -O2 -g -pipe
> - -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
> - --param=ssp-buffer-size=4 -grecord-gcc-switches %{_hardened_cflags}
> 
> i agree 64 bit arm if and when it goes to primary will need it, but for
> today it is outside of the change proposal.

Thanks for clearing that up - I had been conflating the two with regards
to this specific issue.

-- 
Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 9 Jul 2013 16:33:28 -0400
Peter Jones  wrote:

> On Tue, Jul 09, 2013 at 06:50:07PM +0100, Matthew Garrett wrote:
> > llvmpipe has been known to be broken for months, and nobody on the
> > ARM team appears capable of fixing it. As a result, ARM shipped in
> > F19 without any out of the box support for running our default
> > desktop.
> > 
> > This doesn't make it seem like the ARM port currently has
> > sufficient developer expertise involved, and I'd really like to
> > hear what the plans are for (a) fixing the existing problems, and
> > (b) ensuring that we don't end up in a situation where other
> > architectures are held up because there's nobody who can fix
> > ARM-specific bugs.
> 
> 
> I'm also concerned that stack protector does not workyet at all.
> Even if the desktop was useable, how would we tell people that it's
> okay to run e.g. firefox with a straight face?  It's not as bad as
> if, say, selinux didn't work, but it's a significant concern.
> 

armv7 has stack protector, aarch64 which is outside of this proposal
doesnt yet have it.
from redhat-rpm-config 

redhat-rpm-config-9.1.0/rpmrc:optflags: armv7hl %{__global_cflags} 
-march=armv7-a -mfpu=vfpv3-d16  -mfloat-abi=hard
redhat-rpm-config-9.1.0/rpmrc:optflags: aarch64 %{__global_cflags}
- -fno-stack-protector
redhat-rpm-config-9.1.0/macros:%__global_cflags -O2 -g -pipe
- -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
- --param=ssp-buffer-size=4 -grecord-gcc-switches %{_hardened_cflags}

i agree 64 bit arm if and when it goes to primary will need it, but for
today it is outside of the change proposal.

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlHdiZsACgkQkSxm47BaWfdR2ACfchknZrlHBMKMBnhF71bM7ETT
L2sAoJwuf7NAJf0PVjobmmIg2F4AJHnV
=4yQy
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Björn Persson]

Kevin Fenzi wrote:
> I was working on adding 2 more SOC's for packagers earlier this week. 
> 
> I wanted to see how much call there was for these... should I try and
> make them accessable by all packagers? Or just have a group and
> interested people could be added to that group?

I for one would like to have access to some ARM systems for trying
things out. At least one for each arch that's a candidate to become
primary would be nice.

Initially I want to see the results of some uname and RPM commands to
make sure that I get things right in fedora-gnat-project-common.

In the future I hope to be able to test my Ada packages on ARM, but
that can't happen until somebody bootstraps GNAT on ARM. If I should
happen to come across a bucket of round tuits I might even try to
bootstrap GNAT myself, although I think it would be better done by
someone who knows more about GCC and ARM than I do.

Björn Persson


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Peter Jones]

On Wed, Jul 10, 2013 at 07:45:53AM -0400, Josh Boyer wrote:
> On Wed, Jul 10, 2013 at 6:02 AM, Jaroslav Reznik  wrote:
> >
> > I don't see a problem with different set of blocking desktops for ARM, even
> > as primary architecture. But it's really about resources - do we have people
> > willing to work for example on LXDE (I'd say more resources friendly for
> > current ARMs) - not saying there are no people, but more to support it as
> > blocking desktop, if QA would be able to validate three desktops on two
> > different platforms... And as we try to avoid "default" world in Fedora now,
> > let's have LXDE "default" in some cases.
> 
> Is LXDE considered a release blocking desktop?  I honestly don't know.
>  I also don't think it matters whether LXDE or FVMW2 or Gnome is the
> default desktop on ARM.  The criteria should probably be that it ships
> with a desktop that is considered release blocking.  If LXDE isn't
> one, then perhaps it should be made so.  The goal here shouldn't be
> "we have a desktop".  It should be "we have a desktop experience that
> is the same on all primary architectures".  To that end, whichever
> desktop is picked should be release blocking and it should function
> the same on all primary architectures.

There's sort of a more central issue here that's causing this question -
while the release criteria certainly are meant to be a way of evaluating
if the release is complete and functional, there's some creep in of how
we use them because of how they were developed.  Specifically, what
they're implicitly testing is whether we've unexpectedly lost functionality
(or quality) from the previous release.  Obviously that's not quite the
metric in which we'll be evaluating arm as a PA.

That doesn't mean that the release criteria as they stand aren't good
for ARM - but they're criteria for evaluating RCs, not the criteria for
ARM as a PA.

It's two different things, and it's important that we not confuse them.
The question isn't "is $DESKTOP not working a release blocker" - it may
or may not be.  The question is "is the infrastructure for normal
desktops to work required to be a PA".

And I think right now, the assumption from outside the ARM team has been
that for ARM as a PA, we do want functionality to have parity with other
PAs, and so yes, that infrastructure should be ready.

-- 
Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Josh Boyer]

On Wed, Jul 10, 2013 at 11:57 AM, Till Maas  wrote:
> On Tue, Jul 09, 2013 at 10:36:39PM +0100, Peter Robinson wrote:
>> On Tue, Jul 9, 2013 at 10:11 PM, Till Maas  wrote:
>
>> > Which hardware is supported by ARMv7 hfp 32bit builds? Will there be
>>
>> http://fedoraproject.org/wiki/Architectures/ARM
>>
>> The list is expanding regularly and there's a lot of other hardware
>> currently supported by remix primarily because the complete kernel
>> support isn't upstream.
>
> So eventually Raspberry Pi and Cubieboard devices will be supported when
> their kernel patches are upstreamed?

Raspberry Pi is an ARMv6 device, so no.  I have no idea about Cubieboard.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Till Maas]

On Tue, Jul 09, 2013 at 10:36:39PM +0100, Peter Robinson wrote:
> On Tue, Jul 9, 2013 at 10:11 PM, Till Maas  wrote:

> > Which hardware is supported by ARMv7 hfp 32bit builds? Will there be
> 
> http://fedoraproject.org/wiki/Architectures/ARM
> 
> The list is expanding regularly and there's a lot of other hardware
> currently supported by remix primarily because the complete kernel
> support isn't upstream.

So eventually Raspberry Pi and Cubieboard devices will be supported when
their kernel patches are upstreamed? 


> > test instances for maintainers as described here:
> > https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
> 
> I've never seen the above before.

Oh. I thought the ARM device was maintained in coordination with the ARM
SIG, but this has been cleared up in Kevin's mail.

Regards
Till
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 Self Contained Change: Application Installer

[Matthias Clasen]

On Wed, 2013-07-10 at 09:51 -0600, Kevin Fenzi wrote:
> On Wed, 10 Jul 2013 13:02:24 +0200
> Jaroslav Reznik  wrote:
> 
> > = Proposed Self Contained Change: Application Installer =
> > https://fedoraproject.org/wiki/Changes/AppInstaller
> > 
> > Change owner(s): Richard Hughes , together with
> > the desktop team
> > 
> > We will replace the existing gnome-packagekit frontends
> > (gpk-update-viewer and gpk-application) by a new application. 
> 
> Would there be any value in keeping those around for a cycle or so for
> folks that prefer package centric updates? Or better to just ask them
> to move to yum/yumex/apper now?

I don't anticipate removing those tools in the short term - 'replace'
really means 'in the default install' and 'wrt to desktop integration'.



-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 Self Contained Change: Application Installer

[Kevin Fenzi]

On Wed, 10 Jul 2013 13:02:24 +0200
Jaroslav Reznik  wrote:

> = Proposed Self Contained Change: Application Installer =
> https://fedoraproject.org/wiki/Changes/AppInstaller
> 
> Change owner(s): Richard Hughes , together with
> the desktop team
> 
> We will replace the existing gnome-packagekit frontends
> (gpk-update-viewer and gpk-application) by a new application. 

Would there be any value in keeping those around for a cycle or so for
folks that prefer package centric updates? Or better to just ask them
to move to yum/yumex/apper now?

...snip...

> To improve some problematic aspects of the updates user experience
> (long waits, locks), we will use the new hawkey backend for
> PackageKit. 
(echo issue with a different backend that Toshio had)
 
> == Scope ==
> Proposal owners:
> * Implement minimal required functionality for application
> installation in gnome-software
> * Implement minimal required functionality for updates in
> gnome-software
> * Replace gpkg-update-viewer
> * Package gnome-software
> * Include a hawkey backend in PackageKit and use it 
> 
> Other developers:
> * Use gnome-software instead of gpk-update-viewer when dealing with
> updates in gnome-settings-daemon, gnome-shell and
> gnome-control-center 

I'm assuming this will be desktop/gnome centric? Or would it all just
work in Xfce/LXDE/ratpoision sessions?
 
> Release engineering:
> * Make metadata available for packaged applications in Fedora
> (screenshots, icons, ratings,...). Not all of this needs to be in
> place for F20 

Can you expand on these exact needs? What exactly is required for f20? 
What is post f20? 
 
> Policies and guidelines:
> * No immediate changes needed; longer-term, we probably want to make
> changes to way applications are distributed and installed

Can you expand on that? In what way?

> * The update experience will also benefit from proposed changes to
> batch updates 

Is that part of this proposal? Or something else?

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Problem with abrt update on F18?

[Jakub Filak]

On Tue, 2013-07-02 at 16:19 -0500, Richard Shaw wrote:
> I saw this during the update:
> 
> 
> Updating   : abrt-libs-2.1.5-1.fc18.x86_64
>10/76
> cp: cannot create regular file
> â/var/tmp/abrt/ccpp-2013-03-27-09:24:26-2877/environâ: No such file or
> directory
> cp: cannot create regular file
> â/var/tmp/abrt/ccpp-2013-03-27-09:24:26-2877/mapsâ: No such file or
> directory
> cp: cannot create regular file
> â/var/tmp/abrt/ccpp-2013-03-27-09:24:26-2877/countâ: No such file or
> directory
> cp: cannot create regular file
> â/var/tmp/abrt/ccpp-2013-03-27-09:24:26-2877/hostnameâ: No such file
> or directory
> cp: cannot create regular file
> â/var/tmp/abrt/ccpp-2013-03-27-09:24:26-2877/core_backtraceâ: No such
> file or directory
> 
> 
> Is it anything to worry about?
> 
> 
> Richard

Since abrt-2.1.0 detected problems data are stored in /var/tmp/abrt.

We wanted to keep already detected problems visible in abrt-gui. Thus
during upgrading from abrt < 2.1.0 %post scriptlet makes a copy of
already detected problems from the old location (/var/spool/abrt) in the
new location (/var/tmp/abrt). 

So, the error messages are strange but nothing critical has happened.
The old data has not been lost, because abrt makes only a copy and
doesn't delete anything.

Do you have any idea why the following command failed?

cp --recursive -- "/var/spool/abrt/ccpp-2013-03-27-09:24:26-2877"
"/var/tmp/abrt/ccpp-2013-03-27-09:24:26-2877"


Regards,
Jakub

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Kevin Fenzi]

On Tue, 9 Jul 2013 22:36:39 +0100
Peter Robinson  wrote:

> On Tue, Jul 9, 2013 at 10:11 PM, Till Maas 
> wrote:

...snip...

> > test instances for maintainers as described here:
> > https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
> 
> I've never seen the above before.
> 
> There's instances available to QA
> https://fedoraproject.org/wiki/Architectures/ARM/qa-machines

I was working on adding 2 more SOC's for packagers earlier this week. 

I wanted to see how much call there was for these... should I try and
make them accessable by all packagers? Or just have a group and
interested people could be added to that group?

> > f17-arm-test.scrye.com is currently not reachable for me.
> 
> Didn't know it existed so I'm not sure who maintains it.

Thats me. ;) 

It's an Genesi - EFIKA MX Smartbook, but it had an old Fedora (16? 17?)
on it and I haven't had time to try and get it working with anything
newer. If someone could assist me in bringing it back up on f19, I'd be
happy to make it available. 

kevin



signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[HEADS UP] levedb update from 1.9.0 to 1.12.0 for Fedora 19

[Peter Lemenkov]

Hello All!
I'm updating leveldb from 1.9.0 to 1.12.o for Fedora 19. Actually
that's mostly a change of the number in spec-file (NOT a soname bump)
and a few compatible enhancements, however I also backported one
essential patch from Basho's fork of leveldb, which is required for
the next version of erlang-eleveldb (which in turn is necessary for
the Riak). This patch *could* cause issues, so please test it and add
karma:

* https://admin.fedoraproject.org/updates/leveldb-1.12.0-3.fc19

For the reference I set up a repository where I'm tracking all current
Fedora leveldb branches:

* https://git.fedorahosted.org/git/leveldb.git

--
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-Package-Stash] Update to 0.35

[Paul Howarth]

commit da9669e03c9e2bd63d82c256d6181106852a99c5
Author: Paul Howarth 
Date:   Wed Jul 10 16:32:58 2013 +0100

Update to 0.35

- New upstream release 0.35
  - Remove old, deprecated API
- BR: perl(Getopt::Long)
- perl(Package::DeprecationManager) is no longer needed

 perl-Package-Stash.spec |   14 +++---
 sources |2 +-
 2 files changed, 12 insertions(+), 4 deletions(-)
---
diff --git a/perl-Package-Stash.spec b/perl-Package-Stash.spec
index 3845900..a2ed896 100644
--- a/perl-Package-Stash.spec
+++ b/perl-Package-Stash.spec
@@ -2,8 +2,8 @@
 %global old_test_more %(perl -MTest::More -e 'print (($Test::More::VERSION < 
0.88) ? 1 : 0);' 2>/dev/null || echo 0)
 
 Name:  perl-Package-Stash
-Version:   0.34
-Release:   2%{?dist}
+Version:   0.35
+Release:   1%{?dist}
 Summary:   Routines for manipulating stashes
 Group: Development/Libraries
 License:   GPL+ or Artistic
@@ -19,9 +19,9 @@ BuildRequires:perl(Dist::CheckConflicts) >= 0.02
 BuildRequires: perl(ExtUtils::MakeMaker)
 BuildRequires: perl(File::Spec)
 BuildRequires: perl(File::Temp)
+BuildRequires: perl(Getopt::Long)
 BuildRequires: perl(lib)
 BuildRequires: perl(Module::Implementation) >= 0.06
-BuildRequires: perl(Package::DeprecationManager)
 BuildRequires: perl(Package::Stash::XS) >= 0.26
 BuildRequires: perl(Scalar::Util)
 BuildRequires: perl(Test::Fatal)
@@ -82,10 +82,18 @@ rm -rf %{buildroot}
 %doc Changes LICENSE README
 %{_bindir}/package-stash-conflicts
 %{perl_vendorlib}/Package/
+%{_mandir}/man1/package-stash-conflicts.1*
 %{_mandir}/man3/Package::Stash.3pm*
+%{_mandir}/man3/Package::Stash::Conflicts.3pm*
 %{_mandir}/man3/Package::Stash::PP.3pm*
 
 %changelog
+* Wed Jul 10 2013 Paul Howarth  - 0.35-1
+- Update to 0.35
+  - Remove old, deprecated API
+- BR: perl(Getopt::Long)
+- perl(Package::DeprecationManager) is no longer needed
+
 * Thu Jan 24 2013 Paul Howarth  - 0.34-2
 - BR: perl(Package::Anon) if we have Perl ≥ 5.14
 
diff --git a/sources b/sources
index 6891ddb..a9410d1 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d85874dc8abada51b8d7870d8728e3b7  Package-Stash-0.34.tar.gz
+423e99f76382cb71119f5f3a69c1e29e  Package-Stash-0.35.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: F20 Self Contained Change: Application Installer

[Matthias Clasen]

On Wed, 2013-07-10 at 11:12 -0400, Bill Nottingham wrote:
> Jaroslav Reznik (jrez...@redhat.com) said: 
> > = Proposed Self Contained Change: Application Installer =
> > https://fedoraproject.org/wiki/Changes/AppInstaller
> > 
> > Change owner(s): Richard Hughes , together with the 
> > desktop team
> > 
> > We will replace the existing gnome-packagekit frontends (gpk-update-viewer 
> > and 
> > gpk-application) by a new application. 
> 
> Does this involve large enough of a change to the backend PK APIs that other
> PK-using tools (apper, etc.) need to change?

(Richard is on vacation this week, I'll try to answer as well as I can)

From my understanding, it does not necessarily involve any change of PK
backend apis. Although we may need some new apis related to metadata.
I'll ask Richard to flesh out that part of the change page when he's
back.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

File Package-Stash-0.35.tar.gz uploaded to lookaside cache by pghmcfc

[Paul Howarth]

A file has been added to the lookaside cache for perl-Package-Stash:

423e99f76382cb71119f5f3a69c1e29e  Package-Stash-0.35.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Requesting provenpackager help

[Mattia Verga]

Great. Thank you!

Il 09/07/2013 20:35, Jochen Schmitt ha scritto:

On Tue, Jul 09, 2013 at 06:48:17PM +0200, Mattia Verga wrote:


There's nothing to be changed in spec file, just a rebuild is needed
(and to push the update to stable or creating an override in koji).
Is there any provenpackager that can take care of this?

I have create an update request and a buildroot override which should
expired on 07/20/2013.

Best Regards:

Jochen Schmitt



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-Dist-CheckConflicts] Created tag perl-Dist-CheckConflicts-0.08-1.fc20

[Paul Howarth]

The lightweight tag 'perl-Dist-CheckConflicts-0.08-1.fc20' was created pointing 
to:

 2588498... Update to 0.08
--
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: F20 System Wide Change: ARM as primary Architecture

[Caolán McNamara]

On Wed, 2013-07-10 at 08:28 -0400, Aleksandar Kurtakov wrote:
> I still have serious concerns regarding build times:
> * arm - https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=150248 ~ 17h
> * current primary - 
> https://koji.fedoraproject.org/koji/buildinfo?buildID=429023 ~1h 30m
> 
> This is still too huge gap - roughly 10 times slower. If ARM will become 
> primary arch I hope this is an exception and not the general rule.

FWIW, the last libreoffice arm build of
https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=152413, took
approx 14 hours. While
https://koji.fedoraproject.org/koji/buildinfo?buildID=432079 took approx
5 hours on x86

I can probably live with that without to much suffering, but it does
push build times from "start build today, get result today" to "start
build today, get results tomorrow".

C.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 Self Contained Change: Application Installer

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
> = Proposed Self Contained Change: Application Installer =
> https://fedoraproject.org/wiki/Changes/AppInstaller
> 
> Change owner(s): Richard Hughes , together with the 
> desktop team
> 
> We will replace the existing gnome-packagekit frontends (gpk-update-viewer 
> and 
> gpk-application) by a new application. 

Does this involve large enough of a change to the backend PK APIs that other
PK-using tools (apper, etc.) need to change?

Bill
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Matthew Garrett]

On Wed, Jul 10, 2013 at 06:02:57AM -0400, Jaroslav Reznik wrote:

> I don't see a problem with different set of blocking desktops for ARM, even
> as primary architecture. But it's really about resources - do we have people
> willing to work for example on LXDE (I'd say more resources friendly for
> current ARMs) - not saying there are no people, but more to support it as
> blocking desktop, if QA would be able to validate three desktops on two
> different platforms... And as we try to avoid "default" world in Fedora now,
> let's have LXDE "default" in some cases.

I do. Fedora is a Linux distribution that has a specific set of software 
available, and runs a specific desktop by default. We have a process 
whereby people can produce Fedora variants with different defaults, and 
we release those as spins. If ARM wants to be *Fedora*, it should behave 
identically to the other Fedora architectures. If ARM merely wants to be 
able to produce something that's similar to Fedora then we should figure 
out what a spin-based PA would look like, but that's not what's 
currently being proposed.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: I'm going to retire opengl-games-utils

[Jon Ciesla]

On Wed, Jul 10, 2013 at 9:18 AM, Peter Lemenkov  wrote:

> Hello All!
>
> I've no idea how did I become an opengl-games-utils maintainer in the
> first place (perhaps I applied as a co-maintainer years ago). Also I
> think that the package isn't needed anymore, so I'm going to remove
> myself as a maintainer. If anyone wants to take care of this package,
> then don't hesitate to grab it.
>
> * https://admin.fedoraproject.org/pkgdb/acls/name/opengl-games-utils
>

Taken, I have packages that use it.

-J

>
> --
> With best regards, Peter Lemenkov.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel




-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

I'm going to retire opengl-games-utils

[Peter Lemenkov]

Hello All!

I've no idea how did I become an opengl-games-utils maintainer in the
first place (perhaps I applied as a co-maintainer years ago). Also I
think that the package isn't needed anymore, so I'm going to remove
myself as a maintainer. If anyone wants to take care of this package,
then don't hesitate to grab it.

* https://admin.fedoraproject.org/pkgdb/acls/name/opengl-games-utils

--
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[off topic] [research] Interview for contributors over 50 for Oregon State University Research

[Jen D]

Hello,

Researchers at Oregon State University are striving to conduct
research to learn more about the free/open source software community
landscape as it relates to older adults. We’re looking for older
adults who are older than 50 and are currently involved with a
free/open source software project. You will be excluded from the study
if you are younger than 50, have not contributed to a free/open source
software project, or are not fluent in English. If you’re interested,
we will either do an in-person interview (if you are local to the
Corvallis or Portland area), or an interview over the phone (if you
are not local). The interview is expected to last no longer than an
hour. You will not be compensated for participating in this study.

The study title is Involving Older Adults in the Design and
Development of Free/Open Source Software – Part 2. The principal
investigator is Dr. Carlos Jensen.

If you would like to participate in the study, please read through the
eligibility document and consent document [1]. Please email us at
david...@onid.orst.edu to set up a time to determine your eligibility
and to set up a time/location to do an interview.


Thank you,

Jennifer DavidsonCarlos Jensen

david...@onid.orst.edu cjen...@eecs.oregonstate.edu

[1] people.oregonstate.edu/~davidsje/researchForms/groupB/

--
Jennifer Davidson
Human-Computer Interaction PhD Student
IGERT in Aging Sciences Program
Center for Healthy Aging Research
Department of Electrical Engineering and Computer Science
Oregon State University
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[drago01]

On Wednesday, July 10, 2013, "Jóhann B. Guðmundsson" <
johan...@gmail.com> wrote:
> On 07/09/2013 08:00 PM, drago01 wrote:
>
>
> On Tuesday, July 9, 2013, Jonathan Masters  wrote:
>> Matthew,
>>
>> We'll be looking into LLVM in due course. There are a few of us capable
of fixing the issue (that you were noted as being extremely concerned about
on IRC at the time - we will be happy to send you updates on this) but we
balance this with other priorities (as well as a desire not to grow a
dependency on LLVM more broadly - Fedora relies heavily upon the expertise
of RH's tools team, which focuses on GCC almost exclusively precisely to
avoid fragmenting the resources that do exist to develop awesome new
tooling). Right now, many desktops work just fine, and there is no reason
ARM cannot be a a Primary Architecture because of a temporary bug in
llvmpipe (or otherwise we can revive this thread for you next time it
breaks on the other architecture and see if it should be demoted
accordingly?). If there is a rule saying "PA needs GNOME" then this can
easily be adjusted to reflect the fact that many are running Fedora on ARM
today happily with a variety of other desktop environments.
>>
>
> It is not only that one desktop does not work but pretty much everything
that uses GL ... Which is not acceptable in 2013 IMO ... And this has
nothing to do with GCC vs llvm either ...
>
> Since when do we make the requirement that PA have to run any DE et all
period regardless if it's 2013 or not?

You missed the point. I am not talking ab out Desktops but OpenGL if wie
dont have such criteria wie should ad it.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Jóhann B. Guðmundsson]

On 07/10/2013 12:36 AM, Bill Nottingham wrote:

Plus, in relation to this - the llvmpipe issue brings up that one of
the 'release blocking desktops'*does not work*. This would, by definition,
block the release unless we intend to have different criteria for ARM as a
primary arch.


Then we should remove the default label and "release blocking 
desktop(s)" entirely concept with it.


It's far outdated anyway and relic from the past.

Each sub-community ( be it spins be it various arch ) should need to 
provide the necessary QA/Releng resources from their sub-community ( if 
no such thing the relevant party needs to build one ) while we QA and 
Releng focus our available resources on the components that everyone in 
the whole distribution use and provide the necessary sub community with 
the assistance in relation to QA and Releng.



Outside of that, how might we expect release criteria to change for ARM,
given the different deliverables that are planned?



It's pretty self explanatory if you dont use "anaconda" or rather an 
installer of some sort then those criteria items dont apply  to your 
arch or spin for that matter so fourth and so on so the release criteria 
should be applicable in it's current form and be applied by relevance 
regardless of the hardware or hardware architecture being used, If it's 
not that's we need to adapt/adjust the criteria to those limitations.


JBG
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Jóhann B. Guðmundsson]

On 07/09/2013 08:00 PM, drago01 wrote:



On Tuesday, July 9, 2013, Jonathan Masters > wrote:

> Matthew,
>
> We'll be looking into LLVM in due course. There are a few of us 
capable of fixing the issue (that you were noted as being extremely 
concerned about on IRC at the time - we will be happy to send you 
updates on this) but we balance this with other priorities (as well as 
a desire not to grow a dependency on LLVM more broadly - Fedora relies 
heavily upon the expertise of RH's tools team, which focuses on GCC 
almost exclusively precisely to avoid fragmenting the resources that 
do exist to develop awesome new tooling). Right now, many desktops 
work just fine, and there is no reason ARM cannot be a a Primary 
Architecture because of a temporary bug in llvmpipe (or otherwise we 
can revive this thread for you next time it breaks on the other 
architecture and see if it should be demoted accordingly?). If there 
is a rule saying "PA needs GNOME" then this can easily be adjusted to 
reflect the fact that many are running Fedora on ARM today happily 
with a variety of other desktop environments.

>

It is not only that one desktop does not work but pretty much 
everything that uses GL ... Which is not acceptable in 2013 IMO ... 
And this has nothing to do with GCC vs llvm either ...


Since when do we make the requirement that PA have to run any DE et all 
period regardless if it's 2013 or not?


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Moving xine-lib and dependent apps to RPM Fusion Free for F17?

[Xavier Bachelot]

On 07/10/2013 01:42 PM, Michael J Gruber wrote:

Do you top-post on rpmfusion-developers? I'm sorry if I messed that up,
I'm not on that list and don't know the policy.


As on most lists, no, we don't top post, but no worries ;-)


We were talking about restructuring the xine packages, and xine-ui was
supposed to be subsumed by another package if I remember correctly.


Ok, I see what you had in mind now.
Currently, xine-lib is split into the main package in Fedora, and a 
companion package in RPM Fusion (xine-lib-extras-freeworld) that ships 
all the bits of xine-lib that cannot be in Fedora for some reason.
xine-ui and the other xine-lib dependant packages don't suffer from this 
kind of split, so they'll stay as they are, just at a different location.



Do we move first than repackage?

I guess the plan could be to have all the packages created in RPM 
Fusion, then all the packages retired from Fedora. We'll need to first 
build xine-lib, then all the other packages. I don't have experience on 
this particular matter, so I welcome any advice. Especially, I don't 
know if the moved packages will need to be re-reviewed or not. There is 
a review ticket open for xine-lib in RPM Fusion bugzilla, but this is a 
bit different, as this is about merging xine-lib and 
xine-lib-extras-freeworld packages.


Please note the target is Fedora 20, so we'll have a bit of time to land 
all of this in devel, I'd say the target could be before branching 
Rawhide for F20. Indeed, the packages that are currently in Fedora 19 
and earlier and EPEL are not affected. Only the devel and f20 branches 
will be touched.



In that case we would need an rpmfusion maintainer for xine-ui, or I
would need to become one. If someone wants to jump in - by all means go
for it. Otherwise I hope that rpmfusion maintainership doesn't differ
too much from fedora maintainership in terms of tools etc. I won't be
able to before mid August, though.


RPM Fusion strictly follows the Fedora packaging guidelines, but is less 
strict on the allowed software and licenses. However, the tools are a 
bit different than what we have now in Fedora (git vs cvs, koji vs 
plague, bodhi vs manual scripts). I think moving closer to the Fedora 
build infrastructure is in the works, but I don't know about the current 
status.


About maintainership of the packages, the easiest would probably be to 
keep the current maintainers. That's true even for xine-lib, but as I'm 
looking at updating it to a more recent release and Kevin wants to step 
down from maintaining it, I'm de facto volunteering myself ;-) About 
xine-ui, that's one of the frontends I'm using so I could be maintainer 
or co-maintainer if you wish, but again, I'm not trying to grab more 
packages, I have already my share ;-)


Michael


Regards,
Xavier


Xavier Bachelot venit, vidit, dixit 10.07.2013 12:34:

On 07/10/2013 11:57 AM, Michael J Gruber wrote:

Xavier Bachelot venit, vidit, dixit 10.07.2013 10:58:

Hi,

On 01/05/2012 08:56 PM, Kevin Kofler wrote:

The following packages currently depend on xine-lib:
* gxine
* (k9copy – already in RPM Fusion, not affected)
* kaffeine (my package, the reason why I maintain xine-lib in the first place)
* oxine
* xine-plugin
* xine-ui
These packages would have to move to RPM Fusion along with xine-lib.


Fwiw, I've rebuilt all the above packages (but k9copy, not tested yet)
against the xine-lib 1.2.3 rpm I prepared and all the builds succeeded.
No runtime tests yet.

Would all the impacted maintainers be ok to move their package to RPM
Fusion, alongside with xine-lib 1.2 ?


Yes, more than happy.

great.


I assume that packages such as xine-ui would be
subsumed in other packages then?

I'm not sure to understand what you mean here, but each package would be
retired from Fedora and a corresponding package be created in RPM
Fusion. The RPM Fusion maintainer can be the same person as the former
Fedora maintainer, as a sponsored Fedora packager is entitled to be an
RPM Fusion packager automatically. Indeed, if the Fedora packager
doesn't want to keep maintaining his package in RPM Fusion, another
maintainer will have to be found or else the package would have to
unfortunately be retired, if no one steps up.


I'd pass over maintainership to the
corresponding superpackage maintainer then.

Michael


Regards,
Xavier



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 Self Contained Change: Application Installer

[Pete Travis]

On Jul 10, 2013 5:25 AM, "Jaroslav Reznik"  wrote:
>
> = Proposed Self Contained Change: Application Installer =
> https://fedoraproject.org/wiki/Changes/AppInstaller
>
> Change owner(s): Richard Hughes , together with the
> desktop team
>
> We will replace the existing gnome-packagekit frontends
(gpk-update-viewer and
> gpk-application) by a new application.
>
> == Detailed description ==
> The current PackageKit frontends are focused on (surprise!) packages.
>
> The new tool, tentatively named gnome-software, is designed from the
beginning
> for installing applications. It will present applications with information
> that is relevant to users (screenshots, reviews, descriptions,
ratings,...)
> instead of information that is relevant for packagers (dependencies,
package
> size, file lists,...).
>
> It will be possible to search and browse for available applications.
>
> gnome-software will also be used to present information about available
and
> installed updates. Notifications about available updates will launch
gnome-
> software if the user chooses to see details. gnome-software will be fully
> integrated with 'offline updates' - if an update includes system
packages, it
> will be done as an offline update, regardless whether it gets initiated
from the
> gnome-shell menu, a notification, or the gnome-software UI.
>
> To improve some problematic aspects of the updates user experience (long
> waits, locks), we will use the new hawkey backend for PackageKit.
>
> == Scope ==
> Proposal owners:
> * Implement minimal required functionality for application installation in
> gnome-software
> * Implement minimal required functionality for updates in gnome-software
> * Replace gpkg-update-viewer
> * Package gnome-software
> * Include a hawkey backend in PackageKit and use it
>
> Other developers:
> * Use gnome-software instead of gpk-update-viewer when dealing with
updates in
> gnome-settings-daemon, gnome-shell and gnome-control-center
>
> Release engineering:
> * Make metadata available for packaged applications in Fedora
(screenshots,
> icons, ratings,...). Not all of this needs to be in place for F20
>
> Policies and guidelines:
> * No immediate changes needed; longer-term, we probably want to make
changes
> to way applications are distributed and installed
> * The update experience will also benefit from proposed changes to batch
> updates
>
> ___

A few questions:

How does gnome-software differentiate between user facing applications and
other packages, ie back end dependencies, system libraries, texlive
packages? What role do maintainers have in making this distinction, and by
what process?

Where does the additional user facing metadata live? How can maintainers
provide it for their packages, and in what format? Will other packagekit
applications be able to take advantage of it, or just gnome-software?

Thanks,

--Pete
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Aleksandar Kurtakov]

- Original Message -
> From: "Josh Boyer" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, July 10, 2013 2:45:53 PM
> Subject: Re: F20 System Wide Change: ARM as primary Architecture
> 
> On Wed, Jul 10, 2013 at 6:02 AM, Jaroslav Reznik  wrote:
> > - Original Message -
> >> Adam Williamson (awill...@redhat.com) said:
> >> > I've had an entry on my todo list _forever_ to complete the
> >> > 'deliverables SOP' I started several releases ago:
> >> >
> >> > https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables
> >> >
> >> > (I don't really like the current layout, I was planning on revising it)
> >> >
> >> > The addition of a new arch with quite a pile of 'supported images'
> >> > would certainly raise the priority of having such a thing. (We're
> >> > already hitting a problem with our *current* primary arches in this
> >> > area, though, in that the status of the multi-live, multi-arch and
> >> > cloud/appliance images is rather unclear).
> >>
> >> Plus, in relation to this - the llvmpipe issue brings up that one of
> >> the 'release blocking desktops' *does not work*. This would, by
> >> definition,
> >> block the release unless we intend to have different criteria for ARM as a
> >> primary arch.
> >
> > I don't see a problem with different set of blocking desktops for ARM, even
> > as primary architecture. But it's really about resources - do we have
> > people
> > willing to work for example on LXDE (I'd say more resources friendly for
> > current ARMs) - not saying there are no people, but more to support it as
> > blocking desktop, if QA would be able to validate three desktops on two
> > different platforms... And as we try to avoid "default" world in Fedora
> > now,
> > let's have LXDE "default" in some cases.
> 
> Is LXDE considered a release blocking desktop?  I honestly don't know.
>  I also don't think it matters whether LXDE or FVMW2 or Gnome is the
> default desktop on ARM.  The criteria should probably be that it ships
> with a desktop that is considered release blocking.  If LXDE isn't
> one, then perhaps it should be made so.  The goal here shouldn't be
> "we have a desktop".  It should be "we have a desktop experience that
> is the same on all primary architectures".  To that end, whichever
> desktop is picked should be release blocking and it should function
> the same on all primary architectures.
> 
> > For build times, Dennis has numbers prepared, we decided to let it out of
> > the proposal and send it for discussion.
> 
> There was significant concern on this during the first time this came
> up for discussion.  I think the proposal should at least include a
> link to the overall build time improvements.  Clearly there has been
> improvement, so make the proposal show that.

I still have serious concerns regarding build times:
* arm - https://arm.koji.fedoraproject.org/koji/buildinfo?buildID=150248 ~ 17h
* current primary - 
https://koji.fedoraproject.org/koji/buildinfo?buildID=429023 ~1h 30m

This is still too huge gap - roughly 10 times slower. If ARM will become 
primary arch I hope this is an exception and not the general rule.

Alexander Kurtakov
Red Hat Eclipse Team

> 
> 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

Re: F20 System Wide Change: ARM as primary Architecture

[Josh Boyer]

On Wed, Jul 10, 2013 at 6:02 AM, Jaroslav Reznik  wrote:
> - Original Message -
>> Adam Williamson (awill...@redhat.com) said:
>> > I've had an entry on my todo list _forever_ to complete the
>> > 'deliverables SOP' I started several releases ago:
>> >
>> > https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables
>> >
>> > (I don't really like the current layout, I was planning on revising it)
>> >
>> > The addition of a new arch with quite a pile of 'supported images'
>> > would certainly raise the priority of having such a thing. (We're
>> > already hitting a problem with our *current* primary arches in this
>> > area, though, in that the status of the multi-live, multi-arch and
>> > cloud/appliance images is rather unclear).
>>
>> Plus, in relation to this - the llvmpipe issue brings up that one of
>> the 'release blocking desktops' *does not work*. This would, by definition,
>> block the release unless we intend to have different criteria for ARM as a
>> primary arch.
>
> I don't see a problem with different set of blocking desktops for ARM, even
> as primary architecture. But it's really about resources - do we have people
> willing to work for example on LXDE (I'd say more resources friendly for
> current ARMs) - not saying there are no people, but more to support it as
> blocking desktop, if QA would be able to validate three desktops on two
> different platforms... And as we try to avoid "default" world in Fedora now,
> let's have LXDE "default" in some cases.

Is LXDE considered a release blocking desktop?  I honestly don't know.
 I also don't think it matters whether LXDE or FVMW2 or Gnome is the
default desktop on ARM.  The criteria should probably be that it ships
with a desktop that is considered release blocking.  If LXDE isn't
one, then perhaps it should be made so.  The goal here shouldn't be
"we have a desktop".  It should be "we have a desktop experience that
is the same on all primary architectures".  To that end, whichever
desktop is picked should be release blocking and it should function
the same on all primary architectures.

> For build times, Dennis has numbers prepared, we decided to let it out of
> the proposal and send it for discussion.

There was significant concern on this during the first time this came
up for discussion.  I think the proposal should at least include a
link to the overall build time improvements.  Clearly there has been
improvement, so make the proposal show that.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Moving xine-lib and dependent apps to RPM Fusion Free for F17?

[Michael J Gruber]

Do you top-post on rpmfusion-developers? I'm sorry if I messed that up,
I'm not on that list and don't know the policy.

We were talking about restructuring the xine packages, and xine-ui was
supposed to be subsumed by another package if I remember correctly.

Do we move first than repackage?

In that case we would need an rpmfusion maintainer for xine-ui, or I
would need to become one. If someone wants to jump in - by all means go
for it. Otherwise I hope that rpmfusion maintainership doesn't differ
too much from fedora maintainership in terms of tools etc. I won't be
able to before mid August, though.

Michael

Xavier Bachelot venit, vidit, dixit 10.07.2013 12:34:
> On 07/10/2013 11:57 AM, Michael J Gruber wrote:
>> Xavier Bachelot venit, vidit, dixit 10.07.2013 10:58:
>>> Hi,
>>>
>>> On 01/05/2012 08:56 PM, Kevin Kofler wrote:
 The following packages currently depend on xine-lib:
 * gxine
 * (k9copy – already in RPM Fusion, not affected)
 * kaffeine (my package, the reason why I maintain xine-lib in the first 
 place)
 * oxine
 * xine-plugin
 * xine-ui
 These packages would have to move to RPM Fusion along with xine-lib.
>>>
>>> Fwiw, I've rebuilt all the above packages (but k9copy, not tested yet)
>>> against the xine-lib 1.2.3 rpm I prepared and all the builds succeeded.
>>> No runtime tests yet.
>>>
>>> Would all the impacted maintainers be ok to move their package to RPM
>>> Fusion, alongside with xine-lib 1.2 ?
>>
>> Yes, more than happy.
> great.
> 
>> I assume that packages such as xine-ui would be
>> subsumed in other packages then?
> I'm not sure to understand what you mean here, but each package would be 
> retired from Fedora and a corresponding package be created in RPM 
> Fusion. The RPM Fusion maintainer can be the same person as the former 
> Fedora maintainer, as a sponsored Fedora packager is entitled to be an 
> RPM Fusion packager automatically. Indeed, if the Fedora packager 
> doesn't want to keep maintaining his package in RPM Fusion, another 
> maintainer will have to be found or else the package would have to 
> unfortunately be retired, if no one steps up.
> 
>> I'd pass over maintainership to the
>> corresponding superpackage maintainer then.
>>
>> Michael
>>
> Regards,
> Xavier
> 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

F20 Self Contained Change: Application Installer

[Jaroslav Reznik]

= Proposed Self Contained Change: Application Installer =
https://fedoraproject.org/wiki/Changes/AppInstaller

Change owner(s): Richard Hughes , together with the 
desktop team

We will replace the existing gnome-packagekit frontends (gpk-update-viewer and 
gpk-application) by a new application. 

== Detailed description ==
The current PackageKit frontends are focused on (surprise!) packages.

The new tool, tentatively named gnome-software, is designed from the beginning 
for installing applications. It will present applications with information 
that is relevant to users (screenshots, reviews, descriptions, ratings,...) 
instead of information that is relevant for packagers (dependencies, package 
size, file lists,...).

It will be possible to search and browse for available applications.

gnome-software will also be used to present information about available and 
installed updates. Notifications about available updates will launch gnome-
software if the user chooses to see details. gnome-software will be fully 
integrated with 'offline updates' - if an update includes system packages, it 
will be done as an offline update, regardless whether it gets initiated from 
the 
gnome-shell menu, a notification, or the gnome-software UI.

To improve some problematic aspects of the updates user experience (long 
waits, locks), we will use the new hawkey backend for PackageKit. 

== Scope ==
Proposal owners:
* Implement minimal required functionality for application installation in 
gnome-software
* Implement minimal required functionality for updates in gnome-software
* Replace gpkg-update-viewer
* Package gnome-software
* Include a hawkey backend in PackageKit and use it 

Other developers:
* Use gnome-software instead of gpk-update-viewer when dealing with updates in 
gnome-settings-daemon, gnome-shell and gnome-control-center 

Release engineering:
* Make metadata available for packaged applications in Fedora (screenshots, 
icons, ratings,...). Not all of this needs to be in place for F20 

Policies and guidelines:
* No immediate changes needed; longer-term, we probably want to make changes 
to way applications are distributed and installed
* The update experience will also benefit from proposed changes to batch 
updates 

___
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

F20 Self Contained Change: Shared Certificate Tools

[Jaroslav Reznik]

= Proposed Self Contained Change: Shared Certificate Tools =
https://fedoraproject.org/wiki/Changes/SharedCertificateTools

Change owner(s): Stef Walter 

Fedora now has infrastructure for sharing system trusted certificates between 
the various crypto libraries.

Tools are being worked on for adding/removing these shared trusted 
certificates, as well as blacklisted certificates. This is being worked on 
upstream in the p11-kit project.

This change integrates that upstream work into Fedora. 

== Detailed description ==
A tool will be added to the p11-kit-trust package which can be used to perform 
the following actions:

* Add a trust anchor
* Disable a trust anchor
* Remove an added trust anchor
* Blacklist a certificate or key
* Remove an blacklisted certificate or key 

Because not all crypto implementations read their trusted information directly 
from the dynamic database, the tool will take care of extracting things as 
appropriate after making a change. This will enable administrators to run a 
single command to add an anchor (and perform other tasks). 

== Scope ==
p11-kit has had work done to have the trust module store changes. The initial 
tool has been written upstream. Remainder of the tool needs completion.

The ca-certificates package will need some minor tweaks to make sure the new 
tools integrate correctly with it.

Although this feature can potentially affect a large number of packages, the 
implementation is well bounded. It is limited to a p11-kit (with one or two 
lines changed in ca-certificates).

Proposal owners: stefw, see above
Other developers: kaie (for ca-certificates)
Release engineering: N/A (not a System Wide Change)
Policies and guidelines: N/A (not a System Wide Change) 
___
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

F20 Self Contained Change: Hadoop

[Jaroslav Reznik]

= Proposed Self Contained Change: Hadoop =
https://fedoraproject.org/wiki/Changes/Hadoop

Change owner(s): Matthew Farrellee 

Provide native Apache Hadoop packages. 

== Detailed description ==
Apache Hadoop is a widely used, increasingly complete big data platform, with 
a strong open source community and growing ecosystem. The goal is to package 
and integrate the core of the Hadoop ecosystem for Fedora, allowing for 
immediate use and creating a base for the rest of the ecosystem. 

== Scope ==
Proposal owners:
* Note: target is Apache Hadoop 2.0.5-alpha
* Package all dependencies needed for Apache Hadoop 2.x
* Package the Apache Hadoop 2.x software 

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) 
___
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: Moving xine-lib and dependent apps to RPM Fusion Free for F17?

[Xavier Bachelot]

On 07/10/2013 11:57 AM, Michael J Gruber wrote:

Xavier Bachelot venit, vidit, dixit 10.07.2013 10:58:

Hi,

On 01/05/2012 08:56 PM, Kevin Kofler wrote:

The following packages currently depend on xine-lib:
* gxine
* (k9copy – already in RPM Fusion, not affected)
* kaffeine (my package, the reason why I maintain xine-lib in the first place)
* oxine
* xine-plugin
* xine-ui
These packages would have to move to RPM Fusion along with xine-lib.


Fwiw, I've rebuilt all the above packages (but k9copy, not tested yet)
against the xine-lib 1.2.3 rpm I prepared and all the builds succeeded.
No runtime tests yet.

Would all the impacted maintainers be ok to move their package to RPM
Fusion, alongside with xine-lib 1.2 ?


Yes, more than happy.

great.


I assume that packages such as xine-ui would be
subsumed in other packages then?
I'm not sure to understand what you mean here, but each package would be 
retired from Fedora and a corresponding package be created in RPM 
Fusion. The RPM Fusion maintainer can be the same person as the former 
Fedora maintainer, as a sponsored Fedora packager is entitled to be an 
RPM Fusion packager automatically. Indeed, if the Fedora packager 
doesn't want to keep maintaining his package in RPM Fusion, another 
maintainer will have to be found or else the package would have to 
unfortunately be retired, if no one steps up.



I'd pass over maintainership to the
corresponding superpackage maintainer then.

Michael


Regards,
Xavier

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Jaroslav Reznik]

- Original Message -
> Adam Williamson (awill...@redhat.com) said:
> > I've had an entry on my todo list _forever_ to complete the
> > 'deliverables SOP' I started several releases ago:
> > 
> > https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables
> > 
> > (I don't really like the current layout, I was planning on revising it)
> > 
> > The addition of a new arch with quite a pile of 'supported images'
> > would certainly raise the priority of having such a thing. (We're
> > already hitting a problem with our *current* primary arches in this
> > area, though, in that the status of the multi-live, multi-arch and
> > cloud/appliance images is rather unclear).
> 
> Plus, in relation to this - the llvmpipe issue brings up that one of
> the 'release blocking desktops' *does not work*. This would, by definition,
> block the release unless we intend to have different criteria for ARM as a
> primary arch.

I don't see a problem with different set of blocking desktops for ARM, even
as primary architecture. But it's really about resources - do we have people
willing to work for example on LXDE (I'd say more resources friendly for
current ARMs) - not saying there are no people, but more to support it as
blocking desktop, if QA would be able to validate three desktops on two
different platforms... And as we try to avoid "default" world in Fedora now,
let's have LXDE "default" in some cases.

For build times, Dennis has numbers prepared, we decided to let it out of
the proposal and send it for discussion.

Jaroslav

> Outside of that, how might we expect release criteria to change for ARM,
> given the different deliverables that are planned?
> 
> 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: Moving xine-lib and dependent apps to RPM Fusion Free for F17?

[Michael J Gruber]

Xavier Bachelot venit, vidit, dixit 10.07.2013 10:58:
> Hi,
> 
> On 01/05/2012 08:56 PM, Kevin Kofler wrote:
>> The following packages currently depend on xine-lib:
>> * gxine
>> * (k9copy – already in RPM Fusion, not affected)
>> * kaffeine (my package, the reason why I maintain xine-lib in the first 
>> place)
>> * oxine
>> * xine-plugin
>> * xine-ui
>> These packages would have to move to RPM Fusion along with xine-lib.
> 
> Fwiw, I've rebuilt all the above packages (but k9copy, not tested yet) 
> against the xine-lib 1.2.3 rpm I prepared and all the builds succeeded. 
> No runtime tests yet.
> 
> Would all the impacted maintainers be ok to move their package to RPM 
> Fusion, alongside with xine-lib 1.2 ?

Yes, more than happy. I assume that packages such as xine-ui would be
subsumed in other packages then? I'd pass over maintainership to the
corresponding superpackage maintainer then.

Michael
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Moving xine-lib and dependent apps to RPM Fusion Free for F17?

[Xavier Bachelot]

Hi,

On 01/05/2012 08:56 PM, Kevin Kofler wrote:

The following packages currently depend on xine-lib:
* gxine
* (k9copy – already in RPM Fusion, not affected)
* kaffeine (my package, the reason why I maintain xine-lib in the first place)
* oxine
* xine-plugin
* xine-ui
These packages would have to move to RPM Fusion along with xine-lib.


Fwiw, I've rebuilt all the above packages (but k9copy, not tested yet) 
against the xine-lib 1.2.3 rpm I prepared and all the builds succeeded. 
No runtime tests yet.


Would all the impacted maintainers be ok to move their package to RPM 
Fusion, alongside with xine-lib 1.2 ?


Regards,
Xavier
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Moving xine-lib and dependent apps to RPM Fusion Free for F17?

[Xavier Bachelot]

Hi Kevin,

On 01/05/2012 08:56 PM, Kevin Kofler wrote:

In Kaffeine's case, upstream is switching from xine-lib to MPlayer in their git
repository, so it will likely have to move to RPM Fusion sooner or later
anyway.


I took a look at kaffeine as found in F19 yesterday, and it is still 
using xine-lib (and does rebuild fine against the xine-lib 1.2.3 rpm I 
prepared). A quick glance at upstream sources showed there are now an 
mplayer and vlc backend too, but it seems vlc is the default. iirc, 
there was also a gstreamer backend at some point, but I don't see it 
anymore. I don't know how to build another backend than the default one. 
Also, latest release is 2 years old.
Do you know more about kaffeine status and would you have any advice on 
the way forward ?


Regards,
Xavier
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel