Summary/Minutes from Wednesday's FESCo Meeting (2014-04-09)

[Tomas Mraz]

===
#fedora-meeting: FESCO (2014-04-09)
===

Meeting started by t8m at 18:00:21 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2014-04-09/fesco.2014-04-09-18.00.log.html
.

Meeting summary
---
* init process  (t8m, 18:00:39)
  * abadger1999 assures us he's not around  (pjones, 18:05:28)

* #1244 F21 System Wide Change: cron to systemd time units  (t8m,
  18:06:16)
  * LINK: https://fedoraproject.org/wiki/User:Notting/timer   (nirik,
18:10:19)
  * AGREED: Talk to FPC about replacing SHOULD with MUST, address
concerns there (+7 -0 0:0)  (t8m, 18:28:56)
  * ACTION: notting will bring it up with FPC  (t8m, 18:30:48)

* #1221 Product working group activity reports  (t8m, 18:31:29)
  * Server: Spent the last two weeks organizing and filing Change
Proposals  (sgallagh, 18:32:30)
  * Work on the Role Infrastructure was stalled by my unavailability.
(sgallagh, 18:32:34)
  * Please, WG liaisons add the reports to the ticket if you have
anything new to report  (t8m, 18:36:07)

* #1250 F21 Self Contained Changes  (t8m, 18:37:13)
  * AGREED: All F21 Self Contained Changes for 2014-04-09 meeting are
approved (+7, -0, 0:0)  (t8m, 18:40:13)

* #1269 Closing all 'Merge Review' bugs  (t8m, 18:40:55)
  * ACTION: dgilmore to organise a vfad to finish off merge reviews
(dgilmore, 18:42:50)
  * ACTION: dgilmore will e-mail devel-announce to encourage
provenpackagers to fix things from stalled merge reviews  (t8m,
18:46:10)

* #1272 Reschedule meeting for DST shift?  (t8m, 18:46:51)
  * AGREED: The FESCo meeting is moved one hour earlier (+5, -0, 0:3)
(t8m, 18:50:30)

* #1274 F21 System Wide Change: GCC49 -
  https://fedoraproject.org/wiki/Changes/GCC49  (t8m, 18:50:51)
  * AGREED: F21 System Wide Change: GCC49 is approved (+7, -0, 0:0)
(t8m, 18:54:21)

* #1275 F21 System Wide Change: GHC 7.8 -
  https://fedoraproject.org/wiki/Changes/GHC_7.8  (t8m, 18:54:34)
  * AGREED: F21 System Wide Change: GHC 7.8 is approved (+8, -0, 0:0)
(t8m, 18:57:26)
  * if there are no ordering requirements for the haskell-using packages
the F21 mass rebuild could be used for rebuilding them  (t8m,
18:59:01)

* #1276 F21 System Wide Change: lbzip2 as default bzip2 implementation
  (t8m, 18:59:19)
  * AGREED: F21 System Wide Change: lbzip2 as default bzip2
implementation was rejected  (t8m, 19:08:14)
  * AGREED: FESCo would be happy to consider a re-proposal that includes
a compatible library replacement, and some indication of project
maturity (+7, -0, 0:1)  (t8m, 19:14:53)

* #1277 F21 System Wide Change: RPM-4.12  (t8m, 19:15:17)
  * AGREED: F21 System Wide Change: RPM-4.12 is approved (+8, -0, 0:0)
(t8m, 19:16:55)

* Next week's chair  (t8m, 19:17:17)
  * ACTION: notting will chair the next meeting  (t8m, 19:19:38)

* Open Floor  (t8m, 19:20:00)

Meeting ended at 19:24:01 UTC.


Action Items

* notting will bring it up with FPC
* dgilmore to organise a vfad to finish off merge reviews
* dgilmore will e-mail devel-announce to encourage provenpackagers to
  fix things from stalled merge reviews
* notting will chair the next meeting




Action Items, by person
---
* dgilmore
  * dgilmore to organise a vfad to finish off merge reviews
  * dgilmore will e-mail devel-announce to encourage provenpackagers to
fix things from stalled merge reviews
* notting
  * notting will bring it up with FPC
  * notting will chair the next meeting
* **UNASSIGNED**
  * (none)


People Present (lines said)
---
* t8m (105)
* mitr (47)
* nirik (43)
* pjones (43)
* sgallagh (37)
* dgilmore (35)
* Viking-Ice (24)
* notting (24)
* mattdm (15)
* zodbot (15)
* abadger1999 (12)
* drago01 (4)
* jwb (4)
* ffesti (2)
* mmaslano (0)

--

18:00:21  #startmeeting FESCO (2014-04-09)
18:00:21  Meeting started Wed Apr  9 18:00:21 2014 UTC.  The chair is 
t8m. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:21  Useful Commands: #action #agreed #halp #info #idea #link 
#topic.
18:00:21  #meetingname fesco
18:00:22  #chair abadger1999 dgilmore mattdm mitr notting nirik pjones t8m 
sgallagh mmaslano jwb
18:00:22  The meeting name has been set to 'fesco'
18:00:22  Current chairs: abadger1999 dgilmore jwb mattdm mitr mmaslano 
nirik notting pjones sgallagh t8m
18:00:39  #topic init process
18:00:59  Hi everyone
18:01:08  Hello
18:01:15  hello
18:01:24  Salutations
18:02:02  morning
18:03:02  I would like to request if it is possible fesco starts 
with ticket 1244 since I'm in a bit of a hurry
18:03:58  Viking-Ice, no problem
18:04:46 * notting is here. sorry i'm a few minutes late
18:04:56  dgilmore, mattdm, abadger1999, around?
18:05:06  abadger1999 is off at pycon.
18:05:11  not sure on the others.
18:05:14  t8m: I'm not around.
18:05:28  #info abadger1999 assures us he's not around
18:05:31  :)
18:05:39  ;-)
18:06:05  we will sta

File MooseX-Types-LoadableClass-0.012.tar.gz uploaded to lookaside cache by ppisar

[Petr Pisar]

A file has been added to the lookaside cache for 
perl-MooseX-Types-LoadableClass:

7cc6a67656af0d91fd29c639d6716393  MooseX-Types-LoadableClass-0.012.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: trimming down Fedora installed size

[Marius A]

On Wed, Apr 9, 2014 at 10:57 PM, James Antill wrote:

> On Wed, 2014-04-09 at 12:37 +0300, Ville Skyttä wrote:
> > On Wed, Apr 9, 2014 at 10:33 AM, Marius A  wrote:
> > > 1. remove /usr/share/docs
> >
> > Try this in /etc/rpm/macros.whatever:
> > %_excludedocs 1
>
>  For recent yum it's significantly better to do:
>
> yum fs filter nodocs
>


>
> > Try this in /etc/rpm/macros.whatever:
> > %_install_langs en
>
>  Dito. to get rid of extra languages by:
>
> yum fs filter langs en
>
> ...then you can yum fs refilter / yum fs refilter-cleanup.
>

Wow, this is exactly what I was looking for. Thanks!
On Fedora 21, any way to apply these before installing to SDD from live usb
image? e.g. open terminal, run fs filter's, then start the install?

This thread has spawned good discussions tough :)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

rotated /var/log/journal (was Re: trimming down Fedora installed size)

[Marius A]

On Wed, Apr 9, 2014 at 2:23 PM, Michal Schmidt  wrote:

> On 04/09/2014 09:33 AM, Marius A wrote:
> > 3. cleanup /var/log/journal, which seems it's not automatically rotated
>
> It's supposed to be automatic. How big did it become on your system?
>
600mb. Now in April I still had files from January.
Looks about right according to man page:
The first pair defaults to 10% and the second to 15% of the size of the
respective file system.


> If the default size limits do not suit you, you can change them in
> /etc/systemd/journald.conf.
>
Got it, I'll use that in the future. Thanks!

Would be good to have a sample entry in man page with
 SystemMaxUse=, SystemKeepFree=,
I cannot tell if it's bytes, mb, or percentage of file system size. Google
answered that (e.g. 50M)

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

Re: trimming down Fedora installed size

[Miroslav Suchý]

On 04/09/2014 09:33 AM, Marius A wrote:

Are there any other disk space saving tips?


From Debian world:
https://wiki.debian.org/ReduceDebian


--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [CHANGE PROPOSAL] The securetty file is empty by default

[Daniel P. Berrange]

On Wed, Apr 09, 2014 at 10:20:36PM +0200, Lennart Poettering wrote:
> On Wed, 02.04.14 09:12, quickbooks office (quickbooks.off...@gmail.com) wrote:
> 
> > [CHANGE PROPOSAL] The securetty file is empty by default
> > 
> > All the info has been sitting here @
> > https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default
> > since March 20th.
> > 
> > Did I mess something up? Or is there just a backlog?
> 
> This sounds entirely backwards, and I'd instead vote for removing
> securetty from the PAM stacks we ship altogether. The concept is
> outdated. It was useful in a time where the primary way to access a
> server was via physically attached TTY devices. But that time is mostly
> over...
> 
> Nowadays the device names exposed by the kernel tend to be dynamically
> assigned, they should not be assumed stable (with one exeption, classic
> UART 16650 serial ports). Stable paths for these devices we add in via
> symlinks these days, using /dev/*/by-path/, /dev/*/by-id/, -- as you
> might know from disk devices. Now, the securetty logic is unable to
> verify things using these symlinks, hence the entire concept is
> flawed. It will use an unsteable device name instead, making it mostly
> useless in hotplug scenarios.
> 
> securetty is particularly annoying when we use containers. Tools like
> "machinectl login" will dynamically spawn a getty for you on a pts
> device in the container, but since pts is not listed in securetty you
> cannot log in as root by default. And you cannot event add a wildcard
> match of pts/* to it, to make this work nicely.

Yep, the securetty file is one of only 2 remaining blockers for getting
login working out of the box in containers. Removing securetty would be a
great help there given the inability to wildcard pts/*. The other problem
is of course the horrible pam audit module, which the kernel guys are
hopefully working towards a solution for.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F21 system GCC changed to 4.9.0 prerelease

[Jakub Jelinek]

Hi!

FYI, gcc in rawhide has been upgraded to 4.9.0 prerelease,
please visit http://gcc.gnu.org/gcc-4.9/porting_to.html if your
package no longer builds.  To investigate runtime rather than compile time
issues, please consider using temporarily -fsanitize=undefined and/or
-fsanitize=address to look for undefined behavior in the packages
you own.

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

libcdr license change

[David Tardon]

Hello,

libcdr has changed license from GPLv2+ / LGPLv2+ / MPLv1.1 to MPLv2.0 in
version 0.0.16.

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

Re: F21 System Wide Change: Framework for Server Role Deployment

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/09/2014 07:28 PM, Rob K wrote:
> On 10/04/2014 7:50 AM, Jeffrey Ollie wrote:
> 
>> +1 - What are 'server roles'? Are we just reinventing 
>> Ansible/Puppet/et al here? Yeah, why is someone spending time
>> creating a new Fedora-specific configuration management system
>> rather than just shipping an Ansible playbook or a Salt formula
>> or whatever?
> 
> Pretty much this. The world has enough reinvented wheels as it is.
> I'd like to see a clear use case and implementation example
> without handwaving about dbus and so on.
> 

Ok, first we probably need to clarify a few things: the Server Role
Deployment Framework is meant to describe a layer more than a specific
implementation.

The purpose of this layer is to provide a vastly simplified mechanism
for deploying common infrastructure services in a best-practices
manner. The idea is that this layer should intentionally limit choices
to those that are known to work in the vast majority of cases. This
will hopefully make our volunteer support teams happy, as it means
that there should be a reduction in the number of edge-cases and poor
configuration choices.

Second, we really envision this as being the mechanism that a tool
such as Ansible would call out to in order to perform these
operations. Instead of writing a complicated and custom configuration
for complex services like a domain controller, an ansible playbook
should be able to instead just invoke our tool (or D-BUS API, or
OpenLMI remote interface, etc.) to do all of the work for them.

In other words, instead of coordinating the placement of a dozen or so
configuration files and custom command-line tools to set up a service,
these config management utilities should instead be able to operate
against a single interface.

Furthermore, we expect this approach to improve our users' experience
when it comes to software updates on their systems. Implicit in the
inclusion of a package in a Server Role is also an additional
guarantee on its stability: we intend to end the days where packages
that need to be tested together are instead only testing on their own
(a classic example being the semi-regular cases where a 389DS update
causes deployments of FreeIPA to fail). By ensuring that these
packages are all tested as a unit, we can make much more confident
claims about Fedora's suitability as a production server.

I hope that addresses some of your concerns.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNGhtcACgkQeiVVYja6o6Oh8ACgpmctP4O+lLEWflu3XSiLfV54
TUcAn1Ju0P461WXUsnS5rEGKTBHVSblO
=3oPJ
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Schedule for Thursday's FPC Meeting (2014-04-10 16:00 UTC)

[Antonio Trande]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/09/2014 09:53 PM, James Antill wrote:
> On Wed, 2014-04-09 at 20:45 +0200, Antonio Trande wrote:
> 
>> I don't see the topic about bundled files in Icecat ( 
>> https://fedorahosted.org/fpc/ticket/391). It's still pending.
> 
> AFAIK it's not, if you look at the log from the last meeting:
> 
> http://meetbot.fedoraproject.org/fedora-meeting-1/2014-04-03/fpc.2014-04-03-16.02.log.html
>
>  ...this happened at the end of the #391 ticket:
> 
> 17:34:07  Proposal: firefox has a bundling exception
> since it has an active security team tracking issues in their
> codebase. icecat has an exception since it is a fork of firefox
> that closely tracks firefox's changes. 17:34:11  +1 
> 17:34:32  +1 17:34:36  +1 17:34:43
>  +1 17:41:09  +1
> 
> ...it didn't get an #info log, but and writeups will be a little
> backed up due to PyCon ... but AFAIK it's all dealt with. If you
> have any other questions etc. feel free to drop by tomorrow.
> 

So the ticket will be closed today, I think.

- -- 
Antonio Trande

mailto: sagitterATfedoraproject.org
http://www.fedoraos.worpress.com
https://fedoraproject.org/wiki/User:Sagitter
GPG Key: D400D6C4
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTRojeAAoJED2vIvfUANbEUMgP/0TsY9Dc9KasG/Kor15y9WWU
Okf+ztNdZfuvEJgJdssofB5qR4Rp5NyMC76WAg+Ozg+andnaVLJKVB1NJfkU8iIs
JYcs81LY9PbTNaEfOuPMsXMD+08cKUrih+dH/XqW4Av7k2T2NvzprYx9WBtNpzCD
a0q7KLUj3+GIDKV3OxiFarIEukcoeUnC4l71htJC5fFqSVo6c72UKKx9jAqdFRLW
Mj5GDHeXmTJ7jM3OotqjPkLw7JO28BkFdz7Akja2IB/cTw5LKaU0cQBxfiAaAs/V
kFJFGvT94ZmN2CPxCIx/iSarx3lo6GXbHkoQyIR8h+q20AfCtwBCvxbRGNFP2AaQ
f5L+7RFFmSs4S5BYSgabNERPAgFxARFdsYke3Vhqe3HiQ7RM63s6MRdvjrDn4g4s
vDmWZDZQQDp4DgYf9LU/8BhvelQrmV7pXavHt0Vtd89Gpix9aEkXm4jMZL1ICwYo
MzyoxIF1Gr/f5o1PcOSHPpLXV9mlNZx8/FKrIitNshZsnEkAWMXsxMDHCPl4t9o+
FFFqK2VV0LIHdb4U/TT+XpweUmk/xqlMUOiI/xx5m3U0IVsV0yAyfZIxq7JMB2+Q
u+ZocZviKWjYTbfDe6b10846gsru0H47ZLW1MD3KgR0cvOQ8E1SMFRZkBim78wE9
MfUC9KMp+QR1ffX/QJTV
=jzo9
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: trimming down Fedora installed size

[James Antill]

On Wed, 2014-04-09 at 16:41 -0400, Matthew Miller wrote:
> On Wed, Apr 09, 2014 at 03:57:27PM -0400, James Antill wrote:
> >  For recent yum it's significantly better to do:
> > yum fs filter nodocs
> >  Dito. to get rid of extra languages by:
> > yum fs filter langs en
> > ...then you can yum fs refilter / yum fs refilter-cleanup.
> 
> So -- if the host is originally installed with anaconda's kickstart options
> for nodocs and language selection, will `yum fs refilter` still work?

 The way the nodocs stuff is done in anaconda is by changing the rpm
macros directly where yum uses the slightly saner API there of setting
the rpm.RPMTRANS_FLAG_NODOCS transaction flag. And yum looks just for
that transaction flag when it sets/gets the yumdb tsflag_nodocs.
 On the other hand, the only way to change the installed languages is
via. the rpm macro ... so while anaconda doesn't use the yum
configuration to do it, I believe yum will still see that the rpm macro
has changes and get/set yumdb ts_install_langs correctly.

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

Re: trimming down Fedora installed size

[James Antill]

On Thu, 2014-04-10 at 10:42 +0300, Marius A wrote:

> Wow, this is exactly what I was looking for. Thanks!
> On Fedora 21, any way to apply these before installing to SDD from live usb
> image? e.g. open terminal, run fs filter's, then start the install?

 So the way "yum fs filter" works is to change the yum configuration for
tsflags and override_install_langs.
 If you specify --installroot when running the filter command then yum
should write the new yum.conf within the installroot. Then when you run
the next installroot command, to actually install, it will pickup those
configurations and dtrt.
 You can also use --setopt to set them too, or .conf.blah if you are
using the API.

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

[Bug 1082957] perl does not build with GCC 4.9

[bugzilla]

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



--- Comment #2 from Petr Pisar  ---
These two tests fail (sometimes) without the patches:

t/op/numconvert.t
t/op/range.t

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=WBwRp9LXkW&a=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: F21 system GCC changed to 4.9.0 prerelease

[Josh Boyer]

On Thu, Apr 10, 2014 at 6:23 AM, Jakub Jelinek  wrote:
> Hi!
>
> FYI, gcc in rawhide has been upgraded to 4.9.0 prerelease,
> please visit http://gcc.gnu.org/gcc-4.9/porting_to.html if your
> package no longer builds.  To investigate runtime rather than compile time
> issues, please consider using temporarily -fsanitize=undefined and/or
> -fsanitize=address to look for undefined behavior in the packages
> you own.

Hm.  So the kernel I tried to build this morning failed on ARM:

http://koji.fedoraproject.org/koji/getfile?taskID=6723963&name=build.log

That cross-built locally (gcc 4.8.1) here fine before I sent it to
koji.  Anyone have any ideas on that?

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

Re: F21 system GCC changed to 4.9.0 prerelease

[Jóhann B. Guðmundsson]

On 04/10/2014 02:06 PM, Josh Boyer wrote:

On Thu, Apr 10, 2014 at 6:23 AM, Jakub Jelinek  wrote:

Hi!

FYI, gcc in rawhide has been upgraded to 4.9.0 prerelease,
please visit http://gcc.gnu.org/gcc-4.9/porting_to.html if your
package no longer builds.  To investigate runtime rather than compile time
issues, please consider using temporarily -fsanitize=undefined and/or
-fsanitize=address to look for undefined behavior in the packages
you own.

Hm.  So the kernel I tried to build this morning failed on ARM:

http://koji.fedoraproject.org/koji/getfile?taskID=6723963&name=build.log

That cross-built locally (gcc 4.8.1) here fine before I sent it to
koji.  Anyone have any ideas on that?

Could be this [1]

JBG

1. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60663

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

F21 System Wide Change: (A)Periodic Updates to Images

[Jaroslav Reznik]

= Proposed System Wide Change: (A)Periodic Updates to Images = 
https://fedoraproject.org/wiki/Changes/%28A%29Periodic_Updates_to_Images

Change owner(s): Cloud WG collectively, with Matthew Miller 
 as point of contact
Responsible WG: Cloud 

We want to be able to release updated images not just at release time. Hope 
for a one-month regular cadence, plus emergency updates if needed. 

== Detailed Description ==
We need to be able to produce official updates to the Fedora Cloud images. 
Initially, we plan to release these updates monthly, but also need the ability 
to release an out-of-cycle update in the event of a severe security issue.

This involves:

   1. policy for level of security issue required for out-of-cycle updates
   2. procedure for notification of security updates in images (as with rpm 
updates)
   3. automated QA (at least smoketests)
   4. documentation of QA expectations
   5. release engineering process
   6. mirroring of updated images
   7. updates to web site for new download links and EC2 AMI IDs. 

Note that this will apply to the Cloud Base Image, the Docker Host Image, the 
Big Data Image, and the Docker Container Base Image. (The latter may need 
separate handling.)

Ultimately, we would like to produce updates whenever a package on the image 
or the kickstart file for the image changes. This is a step towards that goal. 

== Scope ==
* Proposal owners: Create policies and procedures as outlined above. Will also 
assist with changes to release engineering.
* Other developers: Contributions welcome!
* Release engineering: Significant impact, obviously. Cloud WG will interact 
heavily with Release Engineering and work in concert.
* Policies and guidelines: No changes to existing policies.

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

File Cpanel-JSON-XS-2.3404.tar.gz uploaded to lookaside cache by pghmcfc

[Paul Howarth]

A file has been added to the lookaside cache for perl-Cpanel-JSON-XS:

6fa33e4f6d5b16bcec62e3340c198437  Cpanel-JSON-XS-2.3404.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Cpanel-JSON-XS] Initial import (perl-Cpanel-JSON-XS-2.3404-2)

[Paul Howarth]

commit f40360d1204c6f1c4a42374f407c7e99915dbf03
Author: Paul Howarth 
Date:   Thu Apr 10 15:20:44 2014 +0100

Initial import (perl-Cpanel-JSON-XS-2.3404-2)

This module converts Perl data structures to JSON and vice versa. Its
primary goal is to be correct and its secondary goal is to be fast. To
reach the latter goal it was written in C.

 .gitignore  |1 +
 Cpanel-JSON-XS-2.3404-no-clzf.patch |   37 
 perl-Cpanel-JSON-XS.spec|  105 +++
 sources |1 +
 4 files changed, 144 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..db3f510 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Cpanel-JSON-XS-[0-9.]*.tar.gz
diff --git a/Cpanel-JSON-XS-2.3404-no-clzf.patch 
b/Cpanel-JSON-XS-2.3404-no-clzf.patch
new file mode 100644
index 000..61a8971
--- /dev/null
+++ b/Cpanel-JSON-XS-2.3404-no-clzf.patch
@@ -0,0 +1,37 @@
+diff -Naur old/bin/cpanel_json_xs new/bin/cpanel_json_xs
+--- old/bin/cpanel_json_xs 2013-11-12 08:26:09.0 +1100
 new/bin/cpanel_json_xs 2014-04-10 18:02:15.694903565 +1000
+@@ -40,8 +40,6 @@
+ 
+ =item bencode - use Convert::Bencode, if available (used by torrent files, 
among others)
+ 
+-=item clzf - Compress::LZF format (requires that module to be installed)
+-
+ =item eval - evaluate the given code as (non-utf-8) Perl, basically the 
reverse of "-t dump"
+ 
+ =item yaml - YAML (avoid at all costs, requires the YAML module :)
+@@ -74,8 +72,6 @@
+ 
+ =item bencode - use Convert::Bencode, if available (used by torrent files, 
among others)
+ 
+-=item clzf - Compress::LZF format
+-
+ =item yaml - YAML
+ 
+ =item dump - Data::Dump
+@@ -176,7 +172,6 @@
+"storable"  => sub { Storable::thaw $_ },
+"storable-file" => sub { open my $fh, "<", \$_; Storable::fd_retrieve $fh 
},
+"bencode"   => sub { require Convert::Bencode; 
Convert::Bencode::bdecode ($_) },
+-   "clzf"  => sub { require Compress::LZF; Compress::LZF::sthaw ($_) 
},
+"yaml"  => sub { require YAML; YAML::Load ($_) },
+"eval"  => sub { my $v = eval "no strict; no warnings; no 
utf8;\n#line 1 \"input\"\n$_"; die "$@" if $@; $v },
+ );
+@@ -196,7 +191,6 @@
+"storable-file" => sub { open my $fh, ">", \my $buf; Storable::nstore_fd 
$_, $fh; $buf },
+ 
+"bencode"   => sub { require Convert::Bencode; 
Convert::Bencode::bencode ($_) },
+-   "clzf"  => sub { require Compress::LZF; Compress::LZF::sfreeze_cr 
($_) },
+"yaml"  => sub { require YAML; YAML::Dump ($_) },
+"dumper"=> sub {
+   require Data::Dumper;
diff --git a/perl-Cpanel-JSON-XS.spec b/perl-Cpanel-JSON-XS.spec
new file mode 100644
index 000..7a63993
--- /dev/null
+++ b/perl-Cpanel-JSON-XS.spec
@@ -0,0 +1,105 @@
+# Note: Compress::LZF format support has been disabled until such
+# time as the Compress::LZF module becomes available in Fedora (#1074129)
+
+Name:  perl-Cpanel-JSON-XS
+Summary:   JSON::XS for Cpanel, fast and correct serializing
+Version:   2.3404
+Release:   2%{?dist}
+License:   GPL+ or Artistic
+URL:   http://search.cpan.org/dist/Cpanel-JSON-XS/
+Source0:   
http://search.cpan.org/CPAN/authors/id/R/RU/RURBAN/Cpanel-JSON-XS-%{version}.tar.gz
+Patch0:Cpanel-JSON-XS-2.3404-no-clzf.patch
+# Module Build
+BuildRequires: perl
+BuildRequires: perl(ExtUtils::MakeMaker)
+# Module Runtime
+BuildRequires: perl(Carp)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(overload)
+BuildRequires: perl(XSLoader)
+# Script Runtime
+#BuildRequires:perl(Compress::LZF)
+BuildRequires: perl(Convert::Bencode)
+BuildRequires: perl(Data::Dump)
+BuildRequires: perl(YAML)
+# Test Suite
+BuildRequires: perl(common::sense) >= 3.5
+BuildRequires: perl(Config)
+BuildRequires: perl(Data::Dumper)
+BuildRequires: perl(Encode) >= 1.9081
+BuildRequires: perl(Hash::Util)
+BuildRequires: perl(strict)
+BuildRequires: perl(Test)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Tie::Array)
+BuildRequires: perl(Tie::Hash)
+BuildRequires: perl(utf8)
+BuildRequires: perl(warnings)
+# Maintainer Tests
+BuildRequires: perl(File::Copy)
+BuildRequires: perl(Perl::MinimumVersion) >= 1.20
+BuildRequires: perl(Test::CPAN::Meta) >= 0.12
+BuildRequires: perl(Test::Kwalitee)
+BuildRequires: perl(Test::MinimumVersion) >= 0.008
+BuildRequires: perl(Test::Pod) >= 1.00
+BuildRequires: perl(Test::Pod::Coverage) >= 1.04
+# Runtime
+Requires:  perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+Requires:  perl(Carp)
+#Requires: perl(Compress::LZF)
+Requires:  perl(Convert::Bencode)
+Requires:  perl(Data::Dump)
+Requires:  perl(YAML)
+
+# Avoid unwanted provides and dependencies
+%{?perl_default_filter}
+
+%description
+This module converts Perl data structures to JSON and vice versa. Its
+primary goal is to be correct and its secondary 

Re: trimming down Fedora installed size

[James Antill]

On Wed, 2014-04-09 at 23:10 +0200, Florian Festi wrote:
> On 04/09/2014 08:42 PM, Bill Nottingham wrote:
> > Given the number of packages that ship localization, this seems like it
> > would have a pretty dramatic effect on metadata size. Is this a concern?
> 
> Meta data is a concern. But the major part of the meta data is file data
> and change logs. Everything else is less than 10%. So doubling or even
> tripling this part won't hurt.

 I'm not sure what you mean by 10% here, but tripling primary would hurt
a lot. Eg. for Fedora 18/updates we have:

404K comps-f18.xml.gz
 17M filelists.sqlite.bz2
6.2M other.sqlite.bz2
780K pkgtags.sqlite.gz
2.7M prestodelta.xml.gz
 12M primary.sqlite.bz2
1.2M updateinfo.xml.gz

...and downloading ~15M does matter, so while compression helps and we
are already in a lot of pain ... more pain is more pain. Also this
locally turns into:

  86M filelists_db.sqlite
  34M other_db.sqlite
 1.8M pkgtags.sqlite
  13M prestodelta.xml
  51M primary_db.sqlite
  13M updateinfo.xml

...and randomly using 80+MB of extra disk space is also painful in some
use cases.

 Not that I assume splitting lanauges and docs. into sub packages would
triple primary numbers, but if it did ... that would be bad.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F21 System Wide Change: Anaconda Support for Server Roles

[Jaroslav Reznik]

= Proposed System Wide Change: Anaconda Support for Server Roles = 
https://fedoraproject.org/wiki/Changes/AnacondaServerRoleSupport

Change owner(s): Stephen Gallagher 
Responsible WG: Server WG 

The Fedora Server SIG will develop a plug-in for Anaconda to support the 
deployment of Fedora Server Roles in kickstart files. 

== Detailed Description ==
Deploying Server Roles during installation will require a higher level of 
access to the installed system than %post can provide. The Fedora Server SIG 
will develop an Anaconda plug-in that will add kickstart directives to deploy 
available server roles. 

== Scope ==
* Proposal owners: Development work of the Anaconda plug-in.
* Other developers:
** This Change is contingent upon the Server Role Framework [1]  being 
implemented.
* Release engineering:
** It will be necessary to include this plug-in into the installer image.
* Policies and guidelines: N/A

[1] https://fedoraproject.org/wiki/Changes/FrameworkForServerRoleDeployment

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

F21 Self Contained Change: Adopt-Your-Cattle

[Jaroslav Reznik]

= Proposed Self Contained Change: Adopt-Your-Cattle = 
https://fedoraproject.org/wiki/Changes/Adopt-Your-Cattle

Change owner(s): Matthew Miller , Stephen Gallagher 

Responsible WG: Cloud 

We provide a smooth path so a Cloud Base Image can be turned into Fedora 
Server. 

== Detailed Description ==
This is code to be written - it will be a simple script which will take a 
generic Fedora Cloud Base Image and turn it into Fedora Server. 

== Scope ==
* Proposal owners: Will work with Cloud and Server SIG members to develop the 
script and documentation and policies around it.
* Other developers: N/A 
* Release engineering: N/A 
* Policies and guidelines: N/A
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 system GCC changed to 4.9.0 prerelease

[Richard W.M. Jones]

On Thu, Apr 10, 2014 at 12:23:07PM +0200, Jakub Jelinek wrote:
> To investigate runtime rather than compile time
> issues, please consider using temporarily -fsanitize=undefined and/or
> -fsanitize=address to look for undefined behavior in the packages
> you own.

Which is this in case anyone else was wondering:

  '-fsanitize=address'
 Enable AddressSanitizer, a fast memory error detector.  Memory
 access instructions will be instrumented to detect out-of-bounds
 and use-after-free bugs.  See
  for more details.
 The run-time behavior can be influenced using the 'ASAN_OPTIONS'
 environment variable; see
 
 for a list of supported options.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

default local DNS caching name server

[Chuck Anderson]

Back in 2012 there was a discussion about having Fedora default to
using a local DNS caching name server [1]:

[1] http://comments.gmane.org/gmane.linux.redhat.fedora.devel/166018

I think this needs to be revisited.  While DNSSEC support has
historically been a driving factor for implementing this, there is an
even more fundamental need due to the poor performance of the system
in case the first listed nameserver in /etc/resolv.conf fails for some
reason.  It is shameful that Linux systems and applications in general
still, after 20+ years, can't perform adequately after a primary DNS
server failure.  The stub resolver in glibc which uses
/etc/resolv.conf can decide that the first listed nameserver entry is
down, but this decision has to be made over and over in every single
process on the system that is doing DNS resolution, resulting in
repeated long application hangs/delays.  We need an independent,
system-wide DNS cache, and always point resolv.conf to 127.0.0.1 to
solve this fundamental design problem with how name resolution works
on a Linux system.  Windows has had a default system-wide DNS cache
for over a decade.  It is about time that Linux catches up.

Yesterday, a new version of dnsmasq was released [2] that adds full
DNSSEC support and provides an alternative to unbound which
dnssec-trigger requires.  There has also been great work done to solve
the NTP/DNSSEC bootstrap problem [3].  What options are currently
available in e.g. NetworkManager for using a local DNS cache and what
is the current status of this integration?  Is it ready yet for
turning on by default in all Fedora products?

[2] http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2014q2/008416.html
[3] http://comments.gmane.org/gmane.comp.embedded.cerowrt.devel/2244
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F21 Self Contained Change: Apache Accumulo

[Jaroslav Reznik]

= Proposed Self Contained Change: Apache Accumulo = 
https://fedoraproject.org/wiki/Changes/ApacheAccumulo

Change owner(s): Christopher Tubbs 

The Apache Accumulo [1] is a scalable sorted, distributed, key/value store. 

== Detailed Description ==
The Apache Accumulo™ sorted, distributed key/value store is a robust, 
scalable, high performance data storage and retrieval system. Apache Accumulo 
is based on Google's BigTable design and is built on top of Apache Hadoop, 
Zookeeper, and Thrift. Apache Accumulo features a few novel improvements on 
the BigTable design in the form of cell-based access control and a server-side 
programming mechanism that can modify key/value pairs at various points in the 
data management process. 

== Scope ==
* Proposal owners: The Accumulo package will provide all the functionality 
from the upstream release, packaged for Fedora.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)

[1] http://accumulo.apache.org/
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F21 Self Contained Change: Apache Ambari

[Jaroslav Reznik]

= Proposed Self Contained Change: Apache Ambari = 
https://fedoraproject.org/wiki/Changes/ApacheAmbari

Change owner(s): Peter MacKinnon 

Apache Ambari [1] is a cluster management framework and UI for Apache Hadoop. 

== Detailed Description ==
The Apache Ambari project is aimed at making Hadoop management simpler by 
developing software for provisioning, managing, and monitoring Apache Hadoop 
clusters. Ambari provides an intuitive, easy-to-use Hadoop management web UI 
backed by its RESTful APIs. 

== Scope ==
* Proposal owners: The Ambari [2] package has not yet been accepted into 
Fedora. There is an outstanding FPC request [3] for a temporary bundling 
exception for Javascript libraries distributed by upstream. 
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)

[1] http://ambari.apache.org/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1076506
[3] https://fedorahosted.org/fpc/ticket/415
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl-Cpanel-JSON-XS/f20] Initial import (perl-Cpanel-JSON-XS-2.3404-2)

[Paul Howarth]

Summary of changes:

  f40360d... Initial import (perl-Cpanel-JSON-XS-2.3404-2) (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: F21 System Wide Change: PHP 5.6

[Remi Collet]

Le 08/04/2014 13:57, Miloslav Trmač a écrit :
> 2014-04-08 10:58 GMT+02:00 Jaroslav Reznik :
> 
>> = Proposed System Wide Change: PHP 5.6 =
>> https://fedoraproject.org/wiki/Changes/Php56
>>
> 
> Contingency mechanism: Wait for 5.6.0RC1 for rawhide import, so we'll, at
>> least, ship a RC
> 
> 
> That's covering upstream contingency of slipping the upstream schedule, but
> not Fedora's contingency of e.g. having too many applications broken and
> having to revert.  We need to worry about the possible necessity to revert
> more because it takes more time.
> Mirek
> 

PHP 5.6.0 should be release in June
Fedora 21 should be release in October.

So this give upstream 4 months to fix their app.

So my is : drop upstream dead and broken packages.

Remember our foundation : "First".


Remi.

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

Re: F21 system GCC changed to 4.9.0 prerelease

[Josh Boyer]

On Thu, Apr 10, 2014 at 10:06 AM, Josh Boyer  wrote:
> On Thu, Apr 10, 2014 at 6:23 AM, Jakub Jelinek  wrote:
>> Hi!
>>
>> FYI, gcc in rawhide has been upgraded to 4.9.0 prerelease,
>> please visit http://gcc.gnu.org/gcc-4.9/porting_to.html if your
>> package no longer builds.  To investigate runtime rather than compile time
>> issues, please consider using temporarily -fsanitize=undefined and/or
>> -fsanitize=address to look for undefined behavior in the packages
>> you own.
>
> Hm.  So the kernel I tried to build this morning failed on ARM:
>
> http://koji.fedoraproject.org/koji/getfile?taskID=6723963&name=build.log
>
> That cross-built locally (gcc 4.8.1) here fine before I sent it to
> koji.  Anyone have any ideas on that?

An f20 scratch build of the same SRPM has progressed past the failure
point above.  I suppose I'll dig into what changed in this regard and
see if there's a fix that works for both.  In the meantime, if anyone
knows what might have changed in gcc 4.9 to cause this, please speak
up.

http://koji.fedoraproject.org/koji/taskinfo?taskID=6724145

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

Re: F21 system GCC changed to 4.9.0 prerelease

[Josh Boyer]

On Thu, Apr 10, 2014 at 10:15 AM, "Jóhann B. Guðmundsson"
 wrote:
>
> On 04/10/2014 02:06 PM, Josh Boyer wrote:
>>
>> On Thu, Apr 10, 2014 at 6:23 AM, Jakub Jelinek  wrote:
>>>
>>> Hi!
>>>
>>> FYI, gcc in rawhide has been upgraded to 4.9.0 prerelease,
>>> please visit http://gcc.gnu.org/gcc-4.9/porting_to.html if your
>>> package no longer builds.  To investigate runtime rather than compile
>>> time
>>> issues, please consider using temporarily -fsanitize=undefined and/or
>>> -fsanitize=address to look for undefined behavior in the packages
>>> you own.
>>
>> Hm.  So the kernel I tried to build this morning failed on ARM:
>>
>> http://koji.fedoraproject.org/koji/getfile?taskID=6723963&name=build.log
>>
>> That cross-built locally (gcc 4.8.1) here fine before I sent it to
>> koji.  Anyone have any ideas on that?
>
> Could be this [1]
>
> JBG
>
> 1. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60663

Indeed.  I just found that myself.  Thanks.

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

Re: default local DNS caching name server

[Billy Crook]

On Thu, Apr 10, 2014 at 9:41 AM, Chuck Anderson  wrote:
> Back in 2012 there was a discussion about having Fedora default to
> using a local DNS caching name server [1]:
...
> repeated long application hangs/delays.  We need an independent,
> system-wide DNS cache, and always point resolv.conf to 127.0.0.1 to


I don't think pointing resolv.conf at 127.0.0.1 is the right answer
for this.  The functionality should be implemented as a 'hosts'
service to be listed in nsswitch.conf between files and dns.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: default local DNS caching name server

[Paul Wouters]

On Thu, 10 Apr 2014, Chuck Anderson wrote:


Yesterday, a new version of dnsmasq was released [2] that adds full
DNSSEC support and provides an alternative to unbound which
dnssec-trigger requires.  There has also been great work done to solve
the NTP/DNSSEC bootstrap problem [3].  What options are currently
available in e.g. NetworkManager for using a local DNS cache and what
is the current status of this integration?  Is it ready yet for
turning on by default in all Fedora products?

[2] http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2014q2/008416.html
[3] http://comments.gmane.org/gmane.comp.embedded.cerowrt.devel/2244


In my opinion, the last remaining hurdle is roaming users and captive
portals. Nothing else prevents anyone from running with dnssec enabled
per default (and even on laptops, developers can run with dnssec-triggerd
and unbound). If you run a server, you should already be running unbound
or bind (or dnsmasq w dnssec).

I do not know if dnsmasq contains the proper code for being reconfigured
on the fly based on network changes, which is a requirement for adopting
to DNSSEC in various situations (such as VPNs, connecting to corporate
LAN/Wifi with internal-only domains, DHCP/ISP forwarder failures). But
libreswan, vpnc and openvpn already have the neccessary unbound
reconfiguration code to properly support VPNs (eg flushing the cache for
the vpn domain when (dis)connecting the VPN, etc)

What is really needed to complete the solution and make it usable for
users, not developers, is the proper integration of dnssec-trigger like
code natively into NM. That must include captive portal checking (which
dnssec-triggerd does) and upstream DNS forwarder checker, with dynamic
reconfiguration on the fly. The current dnssec-trigger does a decent job,
but its problematic because it is not native to NM. Fedora already hosts
the captive portal detection services for dnssec-trigger.

It would also need a little anaconda support. When the user is requested
to put in a DNS server (for a static server configuration, not dhcp)
than anaconda should configure that server as a _forwarder_ in an
unbound configuration and ensure DNSSEC is enabled and running after
install. For the roaming laptop case, anaconda should install unbound
with the NM integrated dnssec-trigger replacement.

In a perfect world, where all network applications are NM aware, it
would be awesome if NM would launch a secure container to do the probing
and captive portal logon using a sandboxed browser window. None of the
other applications would even know there is a network. Once the captive
portal login has succeeded, the uplink becomes available to all apps
and the secure container can be destroyed. This would offer the maximum
protection for applications against unsafe DNS, and limit the required
acceptance of "DNS lies" to the captive portal login procedure only.

The main issue to make this happen has been that we don't have enough
resources to convert the dnssec-trigger code into native NM code.

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

Re: default local DNS caching name server

[Paul Wouters]

On Thu, 10 Apr 2014, Billy Crook wrote:


I don't think pointing resolv.conf at 127.0.0.1 is the right answer
for this.  The functionality should be implemented as a 'hosts'
service to be listed in nsswitch.conf between files and dns.


For security reasons, you really want resolv.conf to only point to
127.0.0.1. Otherwise applications cannot determine the security of
the DNSSEC answers without doing full validation inside every
application themselves.

See recent discussions on the DANE mailinglist regarding the AD bit
discussion:

http://www.ietf.org/mail-archive/web/dane/current/maillist.html

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

Re: F21 System Wide Change: (A)Periodic Updates to Images

[Bruno Wolff III]

On Thu, Apr 10, 2014 at 16:19:37 +0200,
  Jaroslav Reznik  wrote:

= Proposed System Wide Change: (A)Periodic Updates to Images =
https://fedoraproject.org/wiki/Changes/%28A%29Periodic_Updates_to_Images


Is this perodic updates to just cloud images? If so the title of the 
change should probably reflect that.

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

Re: trimming down Fedora installed size

[Bill Nottingham]

James Antill (ja...@fedoraproject.org) said: 
>  Not that I assume splitting lanauges and docs. into sub packages would
> triple primary numbers, but if it did ... that would be bad.

To put it in perspective, if we split out 'langpacks' for apps per language,
something like gedit then grows *100* new subpackages.

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

Re: F21 System Wide Change: (A)Periodic Updates to Images

[Matthew Miller]

On Thu, Apr 10, 2014 at 10:51:46AM -0500, Bruno Wolff III wrote:
> >= Proposed System Wide Change: (A)Periodic Updates to Images =
> >https://fedoraproject.org/wiki/Changes/%28A%29Periodic_Updates_to_Images
> Is this perodic updates to just cloud images? If so the title of the
> change should probably reflect that.

Yes, that's the proposal. If anyone wants to take it wider than that, I
haven't heard.


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

Re: trimming down Fedora installed size

[Andrew Price]

On 10/04/14 17:05, Bill Nottingham wrote:

James Antill (ja...@fedoraproject.org) said:

  Not that I assume splitting lanauges and docs. into sub packages would
triple primary numbers, but if it did ... that would be bad.


To put it in perspective, if we split out 'langpacks' for apps per language,
something like gedit then grows *100* new subpackages.

Bill


It's a shame we can't store .mo files compressed. The ratio seems quite 
good:


[root@phanto ~]# cd /usr/share
[root@phanto share]# cp -r locale locale-compressed
[root@phanto share]# find locale-compressed -type f -name '*.mo' -exec 
bzip2 --best {} \;

[root@phanto share]# du -sh locale locale-compressed
657Mlocale
245Mlocale-compressed

(NB this isn't a newly installed system.)

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

Re: trimming down Fedora installed size

[Peter Oliver]

On 9 April 2014 22:10, Florian Festi  wrote:
>
> On 04/09/2014 08:42 PM, Bill Nottingham wrote:
> > Given the number of packages that ship localization, this seems like it
> > would have a pretty dramatic effect on metadata size. Is this a concern?
>
> Meta data is a concern. But the major part of the meta data is file data
> and change logs. Everything else is less than 10%. So doubling or even
> tripling this part won't hurt.

What about performance?  I don't have any figures, but my feeling was
that TeX seemed to update awfully slowly after it was split into many
small packages.

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

Re: F21 system GCC changed to 4.9.0 prerelease

[Orion Poplawski]

On 04/10/2014 04:23 AM, Jakub Jelinek wrote:
> Hi!
> 
> FYI, gcc in rawhide has been upgraded to 4.9.0 prerelease,
> please visit http://gcc.gnu.org/gcc-4.9/porting_to.html if your
> package no longer builds.  To investigate runtime rather than compile time
> issues, please consider using temporarily -fsanitize=undefined and/or
> -fsanitize=address to look for undefined behavior in the packages
> you own.
> 
>   Jakub
> 

I think I've found a regression in gfortran with list-directed reading
from character arrays: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60810
unless this is some kind of new standards compliance, but this seems to
have worked forever.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 system GCC changed to 4.9.0 prerelease

[Josh Boyer]

On Thu, Apr 10, 2014 at 11:01 AM, Josh Boyer  wrote:
> On Thu, Apr 10, 2014 at 10:15 AM, "Jóhann B. Guðmundsson"
>  wrote:
>>
>> On 04/10/2014 02:06 PM, Josh Boyer wrote:
>>>
>>> On Thu, Apr 10, 2014 at 6:23 AM, Jakub Jelinek  wrote:

 Hi!

 FYI, gcc in rawhide has been upgraded to 4.9.0 prerelease,
 please visit http://gcc.gnu.org/gcc-4.9/porting_to.html if your
 package no longer builds.  To investigate runtime rather than compile
 time
 issues, please consider using temporarily -fsanitize=undefined and/or
 -fsanitize=address to look for undefined behavior in the packages
 you own.
>>>
>>> Hm.  So the kernel I tried to build this morning failed on ARM:
>>>
>>> http://koji.fedoraproject.org/koji/getfile?taskID=6723963&name=build.log
>>>
>>> That cross-built locally (gcc 4.8.1) here fine before I sent it to
>>> koji.  Anyone have any ideas on that?
>>
>> Could be this [1]
>>
>> JBG
>>
>> 1. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60663
>
> Indeed.  I just found that myself.  Thanks.

On the bright side, a scratch build with just i686 and x86_64 does build fine:

http://koji.fedoraproject.org/koji/taskinfo?taskID=6724931

So the issue seems isolated to ARM.  At least in terms of building.
Haven't tested functionality yet.

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

Re: F21 system GCC changed to 4.9.0 prerelease

[Corey Sheldon]

how stable is the x86 4.9 prerelease?
when building I mean


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


On Thu, Apr 10, 2014 at 2:05 PM, Josh Boyer wrote:

> On Thu, Apr 10, 2014 at 11:01 AM, Josh Boyer 
> wrote:
> > On Thu, Apr 10, 2014 at 10:15 AM, "Jóhann B. Guðmundsson"
> >  wrote:
> >>
> >> On 04/10/2014 02:06 PM, Josh Boyer wrote:
> >>>
> >>> On Thu, Apr 10, 2014 at 6:23 AM, Jakub Jelinek 
> wrote:
> 
>  Hi!
> 
>  FYI, gcc in rawhide has been upgraded to 4.9.0 prerelease,
>  please visit http://gcc.gnu.org/gcc-4.9/porting_to.html if your
>  package no longer builds.  To investigate runtime rather than compile
>  time
>  issues, please consider using temporarily -fsanitize=undefined and/or
>  -fsanitize=address to look for undefined behavior in the packages
>  you own.
> >>>
> >>> Hm.  So the kernel I tried to build this morning failed on ARM:
> >>>
> >>>
> http://koji.fedoraproject.org/koji/getfile?taskID=6723963&name=build.log
> >>>
> >>> That cross-built locally (gcc 4.8.1) here fine before I sent it to
> >>> koji.  Anyone have any ideas on that?
> >>
> >> Could be this [1]
> >>
> >> JBG
> >>
> >> 1. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60663
> >
> > Indeed.  I just found that myself.  Thanks.
>
> On the bright side, a scratch build with just i686 and x86_64 does build
> fine:
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=6724931
>
> So the issue seems isolated to ARM.  At least in terms of building.
> Haven't tested functionality yet.
>
> josh
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 system GCC changed to 4.9.0 prerelease

[Josh Boyer]

On Thu, Apr 10, 2014 at 2:09 PM, Corey Sheldon  wrote:
> how stable is the x86 4.9 prerelease?
> when building I mean

Well... it built a kernel.  It possibly built other packages in koji
in the meantime.  Other than that, I have no idea.

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

Re: default local DNS caching name server

[P J P]

   Hello Chuck,

Thank you so much for brining this up.

> On Thursday, 10 April 2014 8:12 PM, Chuck Anderson wrote:
> I think this needs to be revisited. We need an independent,
> system-wide DNS cache, and always point resolv.conf to 127.0.0.1 to
> solve this fundamental design problem with how name resolution works
> on a Linux system.

  Totally agree. In fact, recently there have been multiple instances of 
discussions wherein this exact same topic was discussed and unanimously 
everyone agrees that for various reasons having a default local DNS resolver 
running at 127.0.0.1:53 is the best solution. And going forward it'll be even 
more beneficial.

Paul pointed to one of these discussions in his reply.

I plan to file a feature/change request for this one. I got caught up with 
other work this past week so could not do it. Will start with it right away.

Thank you!
---
Regards
   -Prasad
http://feedmug.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: ImageMagick 6.8.8-10 in rawhide. Soname change.

[Pavel Alexeev]

10.04.2014 05:25, Sérgio Basto пишет:
> On Qui, 2014-04-10 at 01:40 +0200, Tadej Janež wrote: 
>> Hi!
>>
>> On Tue, 2014-04-08 at 18:30 +0400, Pavel Alexeev wrote: 
>>> Packages for rebuild:
>>> $ repoquery --repoid=rawhide --whatrequires --alldeps ImageMagick\* |
>>> fgrep -v 'ImageMagick-' | sort -u
>> As Michael Schwendt already pointed out, your query missed some packages
>> that need rebuilding (BTW, I noticed this because my package, techne,
>> was not listed on your list).
>>
>> Comparing:
>> repoquery --whatrequires 'libMagick*.so.*' --repoid=rawhide --source
>> --qf '%{name}' | sed 's!-[^-]\+-[^-]\+\.src\.rpm$!!g' | sort -u
>>
>> to:
>> repoquery --whatrequires 'ImageMagick*' --repoid=rawhide --source --qf
>> '%{name}' | sed 's!-[^-]\+-[^-]\+\.src\.rpm$!!g' | sort -u
>>
>> revealed that the first command catches some packages that the second
>> command doesn't. These are:
>> ale
>> imageinfo
>> php-magickwand
>> php-pecl-imagick
>> psiconv
>> q
>> ripright
>> techne
>>
>> But it also goes the other way around. The second command catches a lot
>> more packages that the first one. These are:
>> a2ps
>> anyremote
>> caja-extensions
>> c-graph
>> dblatex
>> epix
>> fbida
>> freewrl
>> fvwm
>> gallery2
>> ...
>
> Hi, I had study this recently (find dependencies for mass rebuilds ) and
> found your bug, query rawhide when ImageMagick is already rebuilt,
> query now rawhide we got :
>
> repoquery --repoid=rawhide --requires techne | grep libMag
> libMagickCore-6.Q16.so.1()(64bit)
> libMagickWand-6.Q16.so.1()(64bit)
>
> repoquery --repoid=rawhide --provides ImageMagick-libs | grep libMag
> libMagickCore-6.Q16.so.2
> libMagickWand-6.Q16.so.2
> libMagickCore-6.Q16.so.2()(64bit)
> libMagickWand-6.Q16.so.2()(64bit)
>
>
> So repoquery is correct techne requires
> libMagickWand-6.Q16.so.1()(64bit) and ImageMagick provides
> libMagickCore-6.Q16.so.2()(64bit) :D
>
>
> 2nd - about "your" first command which catches some others packages, the
> packages are, the packages that requires only ImageMagick and not
> ImageMagick-libs , this packages that just requires ImageMagick binaries
> don't need to be rebuild. if a package need to use convert , don't need
> to be rebuild. 
>
> Conclusion the correct repoquery should be made on a repo that have all
> packages without broken deps, on F20 for example.
>
> repoquery  --whatrequires ImageMagick-libs --source | perl -pe
> 's/-\d.*?-\d+(\..*)?\.fc\d+(\..*)?.src.rpm//' | sort -u 
>
> and you got there your package 
Thanks for comments. Each time I have more and more variants :)
>
> Best regards,

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

Re: trimming down Fedora installed size

[Basil Mohamed Gohar]

On 04/10/2014 01:23 PM, Peter Oliver wrote:
> On 9 April 2014 22:10, Florian Festi  wrote:
>>
>> On 04/09/2014 08:42 PM, Bill Nottingham wrote:
>>> Given the number of packages that ship localization, this seems like it
>>> would have a pretty dramatic effect on metadata size. Is this a concern?
>>
>> Meta data is a concern. But the major part of the meta data is file data
>> and change logs. Everything else is less than 10%. So doubling or even
>> tripling this part won't hurt.
> 
> What about performance?  I don't have any figures, but my feeling was
> that TeX seemed to update awfully slowly after it was split into many
> small packages.
> 

If package metadata is a problem, what if we split up the repositories
and allocate some, that we can deem to be, to some degree, optional, to
be for these less-than-mandatory packages.

So, for example, if the extra languages packages are put into their own
repository.  This would, of course, be unfair to the languages that are
not considered main, and this would likely heavily be biased towards
English given it probably has the widest coverage.

But what if manpages were in their own repository?

I guess my point is, can we spread the problem out across semi-optional
repositories and handle dependencies in a soft a way such that they'll
be installed if they are present [i.e., the repository(-ies) with the
given dependency(-ies) is/are present] but then the install continues
without a problem except maybe a gentle notice that there exist optional
dependencies so someone can choose to enable the associated repositories?

I don't know if this will introduce more problems than it solves, but
for the typical 1TB+ desktop user of Fedora, we can enable pretty-much
all of these "optional" repositories, and for the embedded and/or
minimal/micro installs, these optional repositories can be left unenabled.

I think this would require fewer changes to the dependency logic and RPM
itself than, say, a complicated set of flags and package labeling/tagging.

P.S.  Please forgive me if I use terms that might have specific meaning
to the packaging team (maybe tagging means something I don't intend in
that context, I'm using it generically).

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

Re: New Copr release

[Igor Gnatenko]

Cool! I'll send update for dnf plugin with search function.
On Apr 10, 2014 3:15 AM, "Miroslav Suchy"  wrote:

> Hi,
> I just deployed new version of Copr.
>   https://copr.fedoraproject.org/
>
> Changes:
> * a lot of small bugfixes
> * each src.rpm have separate task now - you can still submit bunch of
> src.rpm, but the list of src.rpm are split and each src.rpm is submitted
> to builders as one task. This means that Monitor and deleting is more
> predictable.
> * you can submit src.rpm only to subset of chroots you selected for your
> project.
> * when someone request permission on your project, then copr sends you
> notification via email now.
> * repo files now have better URL (which ends with .repo suffix), which
> should make yours wget happy.
> * new API calls:
>   * call for fulltext searching (this is first step to "dnf copr search")
>   * you add "additional repos" to project via API call now
>   * when submitting src.rpm, then you get list of ids instead of one id.
>
> The last change will probably break old 'copr-cli'. When you submit
> src.rpm it will be sucesfully sent, but then copr-cli query the status
> of build and in this phase old clients will throw error.
> It is not fatal, your packages will be build, but you will have to check
> the status on WebUI. Or upgrade to newer 'copr-cli' which I just sent to
> updates-testing.
>
> I wish you happy building.
>
> --
> Miroslav Suchy, RHCE, RHCDS
> Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
> ___
> copr-devel mailing list
> copr-de...@lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/copr-devel
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: trimming down Fedora installed size

[James Antill]

On Thu, 2014-04-10 at 12:05 -0400, Bill Nottingham wrote:
> James Antill (ja...@fedoraproject.org) said: 
> >  Not that I assume splitting lanauges and docs. into sub packages would
> > triple primary numbers, but if it did ... that would be bad.
> 
> To put it in perspective, if we split out 'langpacks' for apps per language,
> something like gedit then grows *100* new subpackages.

 FWIW here is some data (For x86_64):

Ver | pkgs. num. | pkgs. size | primary size

 10 | 14,303 |  16 G  |  8.2M
 11 | 16,577 |  20 G  | 11M
 12 | 19,122 |  17 G  | 12M
 13 | 20,840 |  20 G  | 13M
 14 | 22,161 |  22 G  | 14M
 15 | 24,085 |  23 G  | 14M
 16 | 25,098 |  25 G  | 15M
 17 | 27,033 |  27 G  | 15M
 18 | 33,868 |  33 G  | 18M
 19 | 36,253 |  36 G  | 18M
 20 | 38,561 |  38 G  | 19M

...which gives about 500-600 bytes of primary per. package. Doing the
same thing for updates gives:

Ver | pkgs. num. | pkgs. size | primary size

 10 |  9,024 |  11 G  |  6M
 11 | 10,066 |  13 G  |  6.6M
 12 |  9,645 |  12 G  |  6.4M
 13 |  9,655 |  12 G  |  6.5M
 14 |  9,982 |  13 G  |  6.8M
 15 | 10,214 |  13 G  |  7.1M
 16 | 11,055 |  15 G  |  7.6M
 17 | 13,163 |  18 G  |  8.4M
 18 | 18,606 |  20 G  | 12M

...which is a bit more at about 650 bytes per. package, probably due to
compression not working as well with small numbers of packages.

 So to do some math with F20:

 "in @^minimal-environment" gives me 218 packages, so adding an extra
docs package to just those is ~120k in release primary MD
 "in @^web-server-environment" (which requires filelists to resolve,
nice) is 524 packages so you are at ~300k
 "in @^gnome-desktop-environment" is 1,265 packages and you are at
~750k.

...if you added 100x the packages to even the first though, it would
obviously be pretty bad.




 Stats. generating using:

repo=fedora

for num in $(seq 10 20); do
yum --disablerepo=\* --enablerepo=$repo repoinfo $repo --releasever=$num | \
  egrep -- '-(name|pkg|size)'
( cd /var/cache/yum/x86_64/$num/$repo; ls --size -h *primary* )
done

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

Re: Review swap...

[Darryl L. Pierce]

On Thu, Mar 27, 2014 at 09:59:26AM -0400, Darryl L. Pierce wrote:
> Ive got a package review for compat-qpid-cpp [1] and am willing to trade
> reviews.
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1080583

Anybody interested in doing a review swap?

-- 
Darryl L. Pierce 
http://mcpierce.blogspot.com/
Famous last words:
   "I wonder what happens if we do it this way?"


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

[Test-Announce] Rawhide validation testing is now OPEN!

[Adam Williamson]

Thanks to everyone for the feedback on the initial proposal to do
optional installation and base validation testing for Rawhide nightly
builds.

I've revised the Installation validation page based on the feedback, and
added a similar Base validation page, and I think we can say we're now
open for business!

https://fedoraproject.org/wiki/Test_Results:Fedora_21_Rawhide_2014_04_Install
https://fedoraproject.org/wiki/Test_Results:Fedora_21_Rawhide_2014_04_Base

In case anyone missed the proposal: the idea is that we run some of our
usual release validation tests -
https://fedoraproject.org/wiki/QA:Installation_validation_testing ,
https://fedoraproject.org/wiki/QA:Base_validation_testing - on the
nightly Rawhide builds. We get nightly live images, network install
images, and 'appliance' (ARM and Cloud) images these days.

This is *entirely optional* testing - no-one else is relying on us to do
this, no releases are being held up for it, so no-one needs to be
pulling any all-nighters. The idea is just to get a feel for where we
stand with the Fedora 21 codebase as we go along for the next few
months, and get the biggest showstopper bugs fixed, so we don't wind up
entering the Alpha milestone with a huge backlog of stuff to test and
fix.

The process should be much like it is for our usual milestone validation
testing, except you'll be grabbing Rawhide nightly images, not the TC/RC
images. The pages include the necessary links for getting those images,
but I'll include them here too:

* Nightly and 'appliance' images can be found from the snazzy new
Release Engineering dashboard:
https://apps.fedoraproject.org/releng-dash/

* The latest network install images are always at the same URLs:
** x86_64 -
http://download.fedoraproject.org/pub/fedora/linux/development/rawhide/x86_64/os/images/boot.iso
** i686 -
http://download.fedoraproject.org/pub/fedora/linux/development/rawhide/i386/os/images/boot.iso

The only other major difference is that you should include the date of
the image you tested in your result entry. The "Key" section of each
page has been edited to give examples of this, and I'll try to run a few
tests and add some sample entries tomorrow to give folks a feel for it.

The main aim here is to identify major bugs and showstoppers, so please
focus on those. It may not be the best idea to file minor bugs at this
point in the cycle, though keep an eye on any you find as we move
towards Alpha and Beta.

I've left Desktop testing out for now, as Johann suggested that we may
need to re-organize our approach due to the Fedora.next changes.
Installation and Base testing should give us enough to be going along
with :)

Thanks everyone!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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

Re: Help understanding Anaconda source - walk through needed.

[Aaron Gray]

On 24 March 2014 19:26, Matthew Garrett  wrote:
> On Mon, Mar 24, 2014 at 07:21:51PM +, Aaron Gray wrote:
>> The HP Dl140 G3 has MCA based graphics. F20 seems to be mainly fixed
>> apart from MCA based Anaconda, which gets the resolution wrong, the
>> screen being too small for the Anaconda graphics.
>> VESA setup mode works fine however.
>
> Ah. You mean MGA, not MCA. It's entirely possible that there's a bug in
> the mgag200 driver that's resulting in a failure to get the correct
> EDID, but that's a kernel bug rather than an anaconda one.

Why is the system when installed fine then ?

Its just Anaconda setup that's getting the lower resolution.

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

Re: Help understanding Anaconda source - walk through needed.

[Aaron Gray]

On 17 March 2014 22:02, Adam Williamson  wrote:
> On Mon, 2014-03-17 at 09:39 -0400, Adam Jackson wrote:
>> On Wed, 2014-03-12 at 20:07 +, Aaron Gray wrote:
>>
>> > I am looking for someone to walk me through the Anaconda source as I
>> > need to understand it and cannot find where its 'main' is and how it
>> > launches X Windows as I need to work out why the main installer is not
>> > working on my HP D140 G3's with MCA video controllers.
>>
>> Anaconda doesn't really "configure" X before running it, it just relies
>> on X's autoconfiguration logic to Do The Right Thing.  I'm hoping you
>> don't really mean MCA to mean Micro Channel Architecture there, one I
>> didn't think anybody besides IBM was foolish enough to use that and two
>> Fedora's X hasn't supported buses older than PCI for a couple of
>> releases now.
>>
>> Whatever problem you're having with graphics at install time, you will
>> almost certainly also have after installed; it's usually easier to debug
>> by going ahead and installing in text mode and then debugging graphics
>> once installed.
>
> I think the system he's referring to is this one:
>
> http://reviews.cnet.com/soho-servers/hp-proliant-dl140/4507-3125_7-30620088.html
>
> Graphics Controller
>
> Type Integrated
> Interface Type PCI
> Graphics Processor / Vendor ATI RAGE XL
> Video Memory 8 MB / 8 MB (max) SDRAM
> Video Interfaces VGA

Adam,

We thought it was an ATI Rage to begin with but X.org says differently
for my systems.

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

Re: trimming down Fedora installed size

[J. Randall Owens]

On 04/09/2014 12:57 PM, James Antill wrote:
> On Wed, 2014-04-09 at 12:37 +0300, Ville Skyttä wrote:
>> On Wed, Apr 9, 2014 at 10:33 AM, Marius A  wrote:
>>> 1. remove /usr/share/docs
>>
>> Try this in /etc/rpm/macros.whatever:
>> %_excludedocs 1
> 
>  For recent yum it's significantly better to do:
> 
> yum fs filter nodocs
> 
>> Try this in /etc/rpm/macros.whatever:
>> %_install_langs en
> 
>  Dito. to get rid of extra languages by:
> 
> yum fs filter langs en
> 
> ...then you can yum fs refilter / yum fs refilter-cleanup.
> 
>> It's possible that these settings break some things such as scriptlets
>> that do not take missing files into account, but at least they're
>> cleaner attempts than simply deleting installed files/dirs.
> 
>  This can still be true though.
> 

Of course, this would all be much more obvious if the `yum help` output
didn't say "fs  Creates filesystem snapshots, or lists/deletes current
snapshots," exactly what it also says for fssnapshot. Bug filed. [1]

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1086461

-- 
J. Randall Owens | http://www.ghiapet.net/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

fedora-atomic discussion point: /usr/lib/passwd

[Colin Walters]

For the fedora-atomic work, the only not-in-Fedora package is 
shadow-utils because it requires a patch, that still lives in my 
walters/rpm-ostree COPR.


Patch is linked from my post here:
http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/2014-March/010099.html

Also, some discussion in the glibc bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=16142

What I'd like to open is a discussion about whether /usr/lib/passwd is 
the right thing long term.  I think it'd be very useful to support it 
short term, but it's not perfect.


The main case where it breaks is when you have a daemon that runs as 
non-root and saves state, so you give it its own system user, but not a 
reserved uid.  Daemons in this class will have their uids effectively 
ordered by package installation order =/


One way to fix this that goes with my general direction of moving 
things out of %post into systemd: a dynamic uid reservation system that 
saves state persistently.  


Crudely, this would be ExecStartPre=/usr/sbin/useradd -r ...
except we'd wrap that with something that checked whether the user 
existed first.


Then /etc/passwd would still be local system-persistent state, and 
OSTree still wouldn't need to run a %post.  I think though it'd be good 
to still use /usr/lib/passwd in this model for daemons that *don't* 
save state persistently, like dbus.  No need to pollute /etc/passwd 
with them.


(Note, we'd also need to teach %systemd_preun to run some kind of 
ExecUninstall=, or skip spawning subprocesses and teach systemd how to 
modify the user database directly)


Thoughts?

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