Re: Meeting minutes from Env-and-Stacks WG meeting (2014-10-14)

2014-10-15 Thread Václav Pavlín 


On 14.10.2014 16:51, Honza Horak wrote:



#fedora-meeting: Env and Stacks (2014-10-14)







Meeting started by hhorak at 13:02:18 UTC. The full logs are available

at

http://meetbot.fedoraproject.org/fedora-meeting/2014-10-14/env-and-stacks.2014-10-14-13.02.log.html

.







Meeting summary

---

* init process  (hhorak, 13:02:39)



* Docker, Docker, Docker  (hhorak, 13:06:09)

  * LINK: https://fedoraproject.org/wiki/Docker   (ncoghlan, 13:07:26)

  * ACTION: hhorak will create a new task about preparing dockerfiles

recommended tips  (hhorak, 13:40:28)



* dockerfile_lint  (hhorak, 13:41:03)

  * LINK:



https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-October/000565.html

(ncoghlan, 13:45:20)

  * checks to dockerfile_lint might be done in parallel with defining

some recommended practices to write dockerfiles  (hhorak, 13:46:20)

  * IDEA: dockerfile_lint could be run in %check section of

fedora-dockerfiles package; dockerfile_lint does not seem to be

usable in Taskotron unless we start building layered images in

Fedora  (hhorak, 13:54:55)
Yes, running in %check should be ok for now. When we start building 
layered images, we will probably want to check every Dockerfile coming 
for build and fail on errors, or at least report warnings.


Vašek


  * taskotron will allow to run some tasks for arbitrary components

only, but since it does not do it now we should be fine with running

dockerfile_lint in %check for now  (hhorak, 14:08:35)

  * we should start to think about delivering layered images during some

of the next meetings (or on ML)  (hhorak, 14:17:23)



* Picking chairman for the next meeting  (hhorak, 14:20:06)



* OpenFloor  (hhorak, 14:21:13)



* standardized macros for bootstrapping packages  (hhorak, 14:46:30)

  * IDEA: packages bootstraps are implemented without any

standardization, but with some rules at least for RPM macros names

it might be much more easy to bootstrap packages  (hhorak, 14:46:30)



Meeting ended at 14:50:15 UTC.









Action Items



* hhorak will create a new task about preparing dockerfiles recommended

  tips









Action Items, by person

---

* hhorak

  * hhorak will create a new task about preparing dockerfiles

recommended tips

* **UNASSIGNED**

  * (none)









People Present (lines said)

---

* hhorak (65)

* ncoghlan (54)

* nphilipp (21)

* juhp (17)

* tflink (13)

* bkabrda1 (6)

* [GNU] (5)

* zodbot (4)

* pkovar (2)

* bkabrda (0)

* samkottler (0)

* sicampbell (0)

* vpavlin (0)

* tjanez (0)









Generated by `MeetBot`_ 0.1.4



.. _`MeetBot`: http://wiki.debian.org/MeetBot

___

env-and-stacks mailing list

env-and-sta...@lists.fedoraproject.org

https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks






--

Lead Infrastructure Engineer
Developer Experience
Brno, Czech Republic


--
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: How to include fonts in Gnome Software?

2014-10-15 Thread Richard Hughes 
On 14 October 2014 22:41, Zbigniew Jędrzejewski-Szmek  wrote:
> I was looking into what I need to do to have my fonts in displayed
> in gnome-software. They all seem to fail with appdata required.

I'm going to work on documenting the font requirements today; I'll
follow up with a blog post and some new instructions :)

Richard
-- 
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: [lapack] Use generic macro to detect 64 bit platforms

2014-10-15 Thread Panu Matilainen 

On 10/14/2014 10:14 PM, Jerry James wrote:

On Tue, Oct 14, 2014 at 4:57 AM, Panu Matilainen
 wrote:

[1] says no such thing, the isa macros are defined for all architectures
except obviously noarch. Perhaps you're misinterpreting the example on 64bit
package requiring a 32bit package which warns that not all 64bit
architectures multiarch.


Ah, probably so.  I think I was already prejudiced in that direction
by seeing messages like this one:
https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20140317/1209708.html.


That would be an issue with koji, there's at least these two bugs on it:
https://bugzilla.redhat.com/show_bug.cgi?id=1141513
https://bugzilla.redhat.com/show_bug.cgi?id=1096480

There is no such architecture as "arm" defined in rpm, so obviously 
arch-specific macros such as the isa-stuff is not defined for it.


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

libimobiledevice soname bumps

2014-10-15 Thread Peter Robinson 
Hi All,

A new version of the libimobiledevice stack is on it's way to rawhide.
There's some soname bumps but I'll deal with any rebuilds necessary.

Peter
-- 
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: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys

2014-10-15 Thread Vít Ondruch 
Dne 17.9.2014 v 14:05 Kai Engert napsal(a):
> On Mon, 2014-09-08 at 12:53 +0200, Vít Ondruch wrote:
>>> I believe that we must contact Amazon and Symantec about this issue.
>>> Amazon should remove the second intermediate, ending the path with the
>>> G5 intermediate. This will allow openssl to find the trusted root CA.
>>>
>>> Also, Symantec should reach out to all of their customers and tell them
>>> you update their configuration.
>>>
>>> I will contact them.
>> Great! Thanks. Should I open ticket against ca-certificates to keep
>> track about this issue?
> There was a short discussion here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=986005#c4
>
> In this particular case, because it works with NSS/Firefox, the admins
> don't think it's necessary to reconfigure?
>
> I think it doesn't help to track the issue with this particular web
> site. I've been told this is a default configuration, which had been
> recommended by the CA to the customers for a long time, in order to
> achieve maximum compatibility with clients. So it's unlikely to get all
> sites changed, for two reasons, worry of site admins to break
> compatibility, and the fact that it's unrealistic to reach and convince
> all site admins.
>
> This means, we'll either have to find a software solution (such as
> getting gnutls/openssl enhanced to construct alternative chains), or
> wait with weak 1024-bit removals by default, until all involved server
> certificates have expired, which would be very unfortunate (and which
> might take several years, because of the transitioning trick, that
> causes recently issued certificates to appear to have been issued by
> both the weak legacy and stronger replacement root ca cert).

I am in favor of the former solution, but the later is good as well.

Nevertheless, I am still unsure how to proceed with RubyGems. Should I
ship the bundled certificates again? Or should I wait until somebody
notices?


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

F-21 Branched report: 20141015 changes

2014-10-15 Thread Fedora Branched Report 
Compose started at Wed Oct 15 07:15:03 UTC 2014
Broken deps for armhfp
--
[PyQuante]
PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 
0:1.1.6-2.fc21
[audtty]
audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2
[authhub]
authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0
[avro]
avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce
avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client
[cduce]
cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 
0:ebd368022fd2bc7b305a42902efa4c90
[cp2k]
cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21
cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 
0:1.1.6-2.fc21
cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1
cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 
0:1.1.6-2.fc21
[deltacloud-core]
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudservers)
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudfiles)
[django-recaptcha]
django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14
[dragonegg]
dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21
[edelib]
edelib-2.1-5.fc21.armv7hl requires libedelib.so
edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so
[eucalyptus]
eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl 
requires hibernate3-jbosscache >= 0:3.6.10-7
[fatrat]
1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires 
libtorrent-rasterbar.so.7
[flush]
flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7
[freesteam]
freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires 
libascend.so.1
[gedit-valencia]
gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires 
libvala-0.24.so.0
[gnome-python2-desktop]
gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires 
libmetacity-private.so.0
[gofer]
ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0
[leiningen]
leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks
leiningen-1.7.1-7.fc20.noarch requires classworlds
[libghemical]
libghemical-2.99.1-24.fc20.armv7hl requires libf77blas.so.3
libghemical-2.99.1-24.fc20.armv7hl requires libatlas.so.3
[libopensync-plugin-irmc]
1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1
[ltsp]
ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs
ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog
[meshmagick]
meshmagick-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1
meshmagick-libs-0.6.0-20.svn2898.fc21.armv7hl requires 
libOgreMain.so.1.8.1
[monodevelop-vala]
monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala < 0:0.25.0
[netdisco]
netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay)
[ocaml-pa-do]
ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 
0:ebd368022fd2bc7b305a42902efa4c90
[openslides]
openslides-1.3.1-3.fc21.noarch requires python-django < 0:1.5
[openstack-nova]
openstack-nova-compute-2014.1.2-1.fc21.noarch requires 
libvirt-daemon-xen
[openvas-client]
openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_omp.so.6
openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_nasl.so.6
openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_misc.so.6
openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_hg.so.6
openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_base.so.6
[perl-RT-Authen-ExternalAuth]
perl-RT-Authen-ExternalAuth-0.11-5.fc21.noarch requires rt3
[perl-RT-Extension-CommandByMail]
perl-RT-Extension-CommandByMail-0.07-10.fc21.noarch requires 
perl(RT::Interface::Email)
[pipelight-selinux]
pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common
pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common
pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight
pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight
[pootle]
pootle-2.1.6-8.fc21.noarch requires python-django14
[python-askbot-fedmsg]
python-askbot-fedmsg-0.1.0-2.fc21.noarch requires askbot
[python-coffin]
python-coffin-0.3.7-3.fc21.noarch requires python-django14
[python-django-addons]
python-django-addons-0.6.6-2.fc21.noarch requires python-django14
[python-django-longerusername]
python-django-longerusername-0.4-5.20130204gite4e85d7d.fc21.noarch 
requires python-django14
[rubygem-linecache19]
rubygem-linecache19-0.5.13-6.fc20.armv7hl requires libruby.so.2.0
[rubygem-rubigen]
rubygem-rubigen-1.5.8-3.fc21.noarch requires rubygem(activesupport) < 
0:3.2.0
[rubygem-ruby-debug-base19]
rubygem-ruby-debug-base19-0.11.26-6.fc20.armv7hl requires libru

Re: Possible PPC kernel bug on builders

2014-10-15 Thread Normand 



On 08/10/2014 08:36, Dan Horák wrote:

On Tue, 7 Oct 2014 16:27:52 -0600
Jerry James  wrote:


On Mon, Oct 6, 2014 at 2:36 PM, Jerry James 
wrote:

I posted about this 5 days ago on ppc list [1], but have had no
response.  I tried to get some attention on #fedora-ppc today, also
with no success.  I am failing miserably to get the attention of any
of the PPC folks, so I am trying email here to see if this will
work.


Still nothing.  Can anybody help me get the attention of somebody on
the PPC team?


we know about it, don't have any answer yet :-(


Dan, is there a bug reference ?

--
Michel Normand

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

rawhide report: 20141015 changes

2014-10-15 Thread Fedora Rawhide Report 
Compose started at Wed Oct 15 05:15:05 UTC 2014
Broken deps for i386
--
[3Depict]
3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0
[Agda]
ghc-Agda-2.3.2.2-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so
ghc-Agda-2.3.2.2-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so
ghc-Agda-2.3.2.2-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
libHSterminfo-0.3.2.5-ghc7.6.3.so
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
libHShaskeline-0.7.0.3-ghc7.6.3.so
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3)
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
[PyQuante]
PyQuante-libint-1.6.4-11.fc22.1.i686 requires libint(x86-32) = 
0:1.1.6-2.fc21
[Sprog]
Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0)
[audtty]
audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2
[authhub]
authhub-0.1.2-3.fc19.i686 requires libjson.so.0
[cab]
cab-0.1.9-12.fc22.i686 requires cabal-dev
[collectd]
collectd-onewire-5.4.1-9.fc22.i686 requires libowcapi-2.9.so.5
[condor]
condor-plumage-8.1.4-7.a1a7df5.fc22.i686 requires libmongoclient.so
[darcs]
darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so
darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so
darcs-2.8.4-5.fc22.i686 requires 
ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3)
darcs-2.8.4-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
ghc-darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so
ghc-darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so
ghc-darcs-2.8.4-5.fc22.i686 requires 
ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3)
ghc-darcs-2.8.4-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
ghc-darcs-devel-2.8.4-5.fc22.i686 requires 
ghc-devel(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3)
ghc-darcs-devel-2.8.4-5.fc22.i686 requires 
ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
[debconf]
debconf-1.5.53-1.fc22.noarch requires perl(:MODULE_COMPAT_5.18.2)
[deltacloud-core]
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudservers)
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudfiles)
[django-recaptcha]
django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14
[dnssec-check]
dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14
dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14
[dragonegg]
dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21
[edelib]
edelib-2.1-5.fc22.i686 requires libedelib.so
edelib-devel-2.1-5.fc22.i686 requires libedelib.so
[eucalyptus]
eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.i686 requires 
hibernate3-jbosscache >= 0:3.6.10-7
[fatrat]
1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7
[flush]
flush-0.9.12-10.fc22.i686 requires libtorrent-rasterbar.so.7
[gedit-valencia]
gedit-valencia-0.4.0-1.20131223git94442bf.fc21.i686 requires 
libvala-0.24.so.0
[ghc-hjsmin]
ghc-hjsmin-0.1.4.7-3.fc22.i686 requires 
libHSoptparse-applicative-0.9.0-ghc7.6.3.so
[glite-jobid-api-java]
glite-jobid-api-java-1.3.9-1.fc21.noarch requires jakarta-commons-codec
[gnome-python2-desktop]
gnome-python2-metacity-2.32.0-18.fc21.i686 requires 
libmetacity-private.so.0
[gofer]
ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0
[gorm]
gorm-1.2.18-5.fc20.i686 requires libgnustep-gui.so.0.23
[hadoop]
hadoop-common-2.4.1-5.fc22.noarch requires commons-httpclient
[hledger]
ghc-hledger-0.19.3-5.fc22.i686 requires 
libHSterminfo-0.3.2.5-ghc7.6.3.so
ghc-hledger-0.19.3-5.fc22.i686 requires 
libHShaskeline-0.7.0.3-ghc7.6.3.so
ghc-hledger-0.19.3-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
ghc-hledger-devel-0.19.3-5.fc22.i686 requires 
ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
hledger-0.19.3-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so
hledger-0.19.3-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so
hledger-0.19.3-5.fc22.i686 requires 
ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3)
hledger-0.19.3-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
[idris]
idris-0.9.9.1-3.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so
idris-0.9.9.1-

Re: [Test-Announce] Taskotron Has Replaced AutoQA

2014-10-15 Thread Kamil Paral 
> > """
> > taskotron-dev.fedoraproject.org uses an invalid security certificate.
> > The certificate is not trusted because no issuer chain was provided.
> > The certificate is only valid for taskotron-dev01.qa.fedoraproject.org
> > """

Tim needs to respond to that.

> 
> """
> https://taskotron-dev.fedoraproject.org/resultsdb
> 
> Not Found
> The requested URL /resultsdb was not found on this server.
> """

I filed https://phab.qadevel.cloud.fedoraproject.org/T359 . Where did you come 
from? I fixed https://fedoraproject.org/wiki/Taskotron/Tasks .

> 
> Sorry to be so negative :)

Bug reports very welcome. Thanks.
-- 
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: How to include fonts in Gnome Software?

2014-10-15 Thread Richard Hughes 
On 15 October 2014 09:06, Richard Hughes  wrote:
> I'm going to work on documenting the font requirements today; I'll
> follow up with a blog post and some new instructions :)

Okay, this is the results of a day hacking:
http://blogs.gnome.org/hughsie/2014/10/15/gnome-software-and-fonts/

Feedback very welcome. If this looks reasonable, I'll top-post again
to devel@fedora and the fonts mailing lists. Thanks.

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

man-db without cache update (no cron or systemd *.timer)

2014-10-15 Thread Jan Chaloupka 

Hi,

there has been a discussion about if we need cache for man-db for users
which use man pages or update system only from time to time and thus
don't need to update cache every day. man-db as it is now depends on
systemd which brings another set of packages. The use case is "I just
want to read man page. So I install man which on the other hand download
another set of packages. I want to read man page and it downloads systemd.".

Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1119625

My suggestion is to create a subpackage (called minimal for example),
which will be without cron/*.timer file. Thus no dependency on systemd.
User will be responsible for updating cache. The proposal was to make
this man-db-minimal implicit, not explicit.

I would like to start discussion if it is really important to update
cache periodically (so keep it implicit and create man-db-minimal
without update) or make it optional (man-db without update and create
man-db-enhanced for example).

Regards
Jan

--
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: Engineering Representiatve for the new Fedora Council

2014-10-15 Thread Haïkel 
After consulting various people, I nominate Josh Boyer as a candidate.

He is an experienced and highly esteemed fesco & board member and I believe
he is the right person to join the council as Eng. Rep.
His experience and his broad but deep understanding of Fedora engineering
will be valuable.

I'm speaking here on my own behalf, not as a board member.
This should not prevent you to nominate another candidate including
yourself.

H.
-- 
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: man-db without cache update (no cron or systemd *.timer)

2014-10-15 Thread Chris Adams 
Once upon a time, Jan Chaloupka  said:
> there has been a discussion about if we need cache for man-db for users
> which use man pages or update system only from time to time and thus
> don't need to update cache every day. man-db as it is now depends on
> systemd which brings another set of packages. The use case is "I just
> want to read man page. So I install man which on the other hand download
> another set of packages. I want to read man page and it downloads systemd.".

On the majority of systems these days, is it really an issue to cache
man pages anymore?  I mean, back when a long man page (thinking about
some of the perl documentation for example) could take a while to
render, it mattered.  Now however, systems are much much faster, and we
expect GUI web browsers to render vastly more complicated content in a
fraction of a second.

Maybe the time has come to just stop caching man pages at all, or at
least make that functionality optional (and non-default)?

-- 
Chris Adams 
-- 
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: Engineering Representiatve for the new Fedora Council

2014-10-15 Thread Bruno Wolff III 

On Wed, Oct 15, 2014 at 16:44:09 +0200,
 Haïkel  wrote:

After consulting various people, I nominate Josh Boyer as a candidate.


My concern is burning Josh out. He has taken on a lot of responsiblity 
in Fedora already.

--
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: Engineering Representiatve for the new Fedora Council

2014-10-15 Thread Matthew Miller 
On Wed, Oct 15, 2014 at 04:44:09PM +0200, Haïkel wrote:
> After consulting various people, I nominate Josh Boyer as a candidate.
> He is an experienced and highly esteemed fesco & board member and I believe
> he is the right person to join the council as Eng. Rep.
> His experience and his broad but deep understanding of Fedora engineering
> will be valuable.

I second this nomination -- Josh would be great.


-- 
Matthew Miller

Fedora Project Leader
-- 
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: man-db without cache update (no cron or systemd *.timer)

2014-10-15 Thread Peter Schiffer 

On 10/15/2014 04:47 PM, Chris Adams wrote:

Once upon a time, Jan Chaloupka  said:

there has been a discussion about if we need cache for man-db for users
which use man pages or update system only from time to time and thus
don't need to update cache every day. man-db as it is now depends on
systemd which brings another set of packages. The use case is "I just
want to read man page. So I install man which on the other hand download
another set of packages. I want to read man page and it downloads systemd.".


On the majority of systems these days, is it really an issue to cache
man pages anymore?  I mean, back when a long man page (thinking about
some of the perl documentation for example) could take a while to
render, it mattered.  Now however, systems are much much faster, and we
expect GUI web browsers to render vastly more complicated content in a
fraction of a second.

Maybe the time has come to just stop caching man pages at all, or at
least make that functionality optional (and non-default)?



Hello,

I would add some noteworthy information:

 * the man-db cron/timer script is taking care of man DB containing
only the man page title and short description i.e., the first NAME
section of the man page. This DB is speeding up the searching in
mentioned section with the man -k command. It is not used for
displaying man pages or doing the full text search with man -K command
and it is not required for normal usage of man command (man -k should
also work without this DB).

 * Debian is updating this DB via deb hooks (or how it is called)
during package installation/update and via daily cron script for man
pages installed outside of package manager.

 * updating this DB is usually pretty quick, but creation can take some
time..

 * man pages cache, pre-formatted man pages stored on disk in plain
text, called cat pages in man-db context, is not used in Fedora.

peter

--
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: [Test-Announce] Taskotron Has Replaced AutoQA

2014-10-15 Thread Tim Flink 
On Tue, 14 Oct 2014 21:10:26 +0200
Zbigniew Jędrzejewski-Szmek  wrote:

> On Tue, Oct 14, 2014 at 04:28:33AM -0400, Martin Krizek wrote:
> > - Original Message -
> > > From: "Vít Ondruch" 
> > > To: devel@lists.fedoraproject.org
> > > Sent: Tuesday, October 14, 2014 8:57:26 AM
> > > Subject: Re: [Test-Announce] Taskotron Has Replaced AutoQA
> > > 
> > > You have not mentioned URL of Taskotron here nor the Wiki is
> > > updated to contain the link to the production version of
> > > Taskotron.
> > > 
> > > Vít
> > 
> > https://taskotron.fedoraproject.org/
> This says "Taskotron is in the very early stages of development with
> the objective to replace AutoQA for automating selected QA tasks in
> Fedora.", which doesn't seem to be true anymore.

Thanks for pointing that out, I'll get it updated soon (today if my
freeze break request is approved).

> Also:
> 
> """
> taskotron-dev.fedoraproject.org uses an invalid security certificate.
> The certificate is not trusted because no issuer chain was provided.
> The certificate is only valid for taskotron-dev01.qa.fedoraproject.org
> """

That stems from two things: first is that the actual hostname of the
machine responding to http requests doesn't match the public-facing
hostname (this is true of almost all infra hosts). For the self-signed
cert bit, as far as I know, most fedora app dev instances are using
self-signed certs. It doesn't make a whole lot of sense to me to pay
for a real SSL cert on a dev instance - especially when it would mean
having individual certs on every dev instance (there's no central proxy
for dev).

Both stg and production are using proper SSL certs, though.

Tim


signature.asc
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

Re: Engineering Representiatve for the new Fedora Council

2014-10-15 Thread Josh Boyer 
On Wed, Oct 15, 2014 at 10:48 AM, Bruno Wolff III  wrote:
> On Wed, Oct 15, 2014 at 16:44:09 +0200,
>  Haïkel  wrote:
>>
>> After consulting various people, I nominate Josh Boyer as a candidate.
>
>
> My concern is burning Josh out. He has taken on a lot of responsiblity in
> Fedora already.

Thanks for the nomination and the concern.  I'm fine with this if
people think I'd be a good representative for them.

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: Engineering Representiatve for the new Fedora Council

2014-10-15 Thread Paul W. Frields 
On Mon, Oct 13, 2014 at 04:52:08PM +0200, Haïkel wrote:
> I'll be speaking in my own name:
> 
> The Eng. Rep. is not necessarily a Fesco member but should be
> someone willing to collaborate regularly with them.  She should have
> a fairly broad overview of Fedora Engineering and be an active
> contributor.
> 
> The ideal candidate should be someone who has experience in the
> technical committees, and able to communicate effectively with
> various groups.  You don't need to be a "super contributor", but
> this is no role for a rookie as the time commitment will be
> important.  About the selection, since it will take a lot of your
> time, I think that interested people should nominate themselves.
> Then, either fesco choose to hold an election or not is up to them.
> 
> Though I have few names in mind, I won't disclose them before
> speaking with them.  Some are obvious, the others may surprise you
> ;)

Although I may not have all the deep technical knowledge of some FESCo
members, I'd be willing to serve in this capacity.  I do have
experience working with different groups in Fedora, including the
Board and FESCo, and release related groups like Rel-Eng, Docs, L10n,
and Websites.

I also manage the team in Red Hat that supports our infrastructure and
applications.  That could come in handy in helping the Council direct
resources to work on the priorities needed for Fedora to succeed.

However, I want to be clear that my being involved is *not* a
pre-requisite for that support.  I would expect to support Matthew and
the Council regardless.  I'm sure there are other worthy candidates,
and I'd work with any of them who fill this role.

-- 
Paul W. Frieldshttp://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.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: How to include fonts in Gnome Software?

2014-10-15 Thread Zbigniew Jędrzejewski-Szmek 
On Wed, Oct 15, 2014 at 02:51:39PM +0100, Richard Hughes wrote:
> On 15 October 2014 09:06, Richard Hughes  wrote:
> > I'm going to work on documenting the font requirements today; I'll
> > follow up with a blog post and some new instructions :)
> 
> Okay, this is the results of a day hacking:
> http://blogs.gnome.org/hughsie/2014/10/15/gnome-software-and-fonts/
> 
> Feedback very welcome. If this looks reasonable, I'll top-post again
> to devel@fedora and the fonts mailing lists. Thanks.
Hi,

maybe you could include some more information how the font appdata
files themselves should look, as opposed to the one-level-up metadata
files. E.g. I looked at the schema at 
http://people.freedesktop.org/~hughsient/appdata/
and they don't seem to have the string "font" in them at all.

Some more examples would be good too. Does [1] look OK?
appdata-validate complains about missing screenshots, are those necessary
for fonts' appdata?

[1] http://pkgs.fedoraproject.org/cgit/unifont.git/tree/unifont.appdata.xml


> 
> Richard.
> -- 
> 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: [Test-Announce] Taskotron Has Replaced AutoQA

2014-10-15 Thread Zbigniew Jędrzejewski-Szmek 
On Wed, Oct 15, 2014 at 09:21:10AM -0400, Kamil Paral wrote:
> > > """
> > > taskotron-dev.fedoraproject.org uses an invalid security certificate.
> > > The certificate is not trusted because no issuer chain was provided.
> > > The certificate is only valid for taskotron-dev01.qa.fedoraproject.org
> > > """
> 
> Tim needs to respond to that.
> 
> > 
> > """
> > https://taskotron-dev.fedoraproject.org/resultsdb
> > 
> > Not Found
> > The requested URL /resultsdb was not found on this server.
> > """
> 
> I filed https://phab.qadevel.cloud.fedoraproject.org/T359 . Where did you 
> come from? I fixed https://fedoraproject.org/wiki/Taskotron/Tasks .

Yes, from there.

Thanks,
Zbyszek
-- 
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: How to include fonts in Gnome Software?

2014-10-15 Thread Richard Hughes 
On 15 October 2014 16:38, Zbigniew Jędrzejewski-Szmek  wrote:
> maybe you could include some more information how the font appdata
> files themselves should look, as opposed to the one-level-up metadata
> files

Right, the examples I gave there are the actual files; that is the
post-0.6 AppStream version which only works with Fedora > 20.

> E.g. I looked at the schema at 
> http://people.freedesktop.org/~hughsient/appdata/
> and they don't seem to have the string "font" in them at all.

Right, those are AppData files for applications, not MetaInfo files
for fonts and addons. When F20 is EOL I'll update that page to the new
metadata format.

> Some more examples would be good too. Does [1] look OK?
> appdata-validate complains about missing screenshots, are those necessary
> for fonts' appdata?

Right; you need to use a metainfo file and a git version of
appstream-glib to validate those. I only wrote the code 6 hours ago :)

> [1] http://pkgs.fedoraproject.org/cgit/unifont.git/tree/unifont.appdata.xml

Not appdata.xml, but metainfo.xml -- This is the patch I want to apply for lato:

diff --git a/lato-fonts.spec b/lato-fonts.spec
index 0eb3837..e0f1fa8 100644
--- a/lato-fonts.spec
+++ b/lato-fonts.spec
@@ -64,9 +64,30 @@ install -m 0755 -d
$RPM_BUILD_ROOT%{_fontconfig_templatedir} $RPM_BUILD_ROOT%{_f
 install -m 0644 -p %{SOURCE1}
$RPM_BUILD_ROOT%{_fontconfig_templatedir}/%{fontconf}
 ln -s %{_fontconfig_templatedir}/%{fontconf}
$RPM_BUILD_ROOT%{_fontconfig_confdir}/%{fontconf}

+# Add AppStream metadata
+mkdir -p $RPM_BUILD_ROOT%{_datadir}/appdata
+cat > $RPM_BUILD_ROOT%{_datadir}/appdata/Lato.metainfo.xml <
+
+
+  Lato
+  CC0-1.0
+  Lato
+  A classical sans-serif font family
+  
+
+  The semi-rounded details of the letters give Lato a feeling of warmth,
+  while the strong structure provides stability and seriousness.
+
+  
+  richard_at_hughsie_dot_com
+  http://www.latofonts.com/
+
+EOF

 %_font_pkg -f %{fontconf} *.ttf
 %doc Lato2OFL/{OFL.txt,README.txt}
+%{_datadir}/appdata/Lato.metainfo.xml


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

The Poodlebleed Bug

2014-10-15 Thread Sérgio Basto 
this site 
http://poodlebleed.com/ 

says that my server with F19 is vulnerable 

any news about this ? 

Thanks, 
-- 
Sérgio M. B.

-- 
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: man-db without cache update (no cron or systemd *.timer)

2014-10-15 Thread Zbigniew Jędrzejewski-Szmek 
On Wed, Oct 15, 2014 at 05:12:07PM +0200, Peter Schiffer wrote:
> On 10/15/2014 04:47 PM, Chris Adams wrote:
> >Once upon a time, Jan Chaloupka  said:
> >>there has been a discussion about if we need cache for man-db for users
> >>which use man pages or update system only from time to time and thus
> >>don't need to update cache every day. man-db as it is now depends on
> >>systemd which brings another set of packages. The use case is "I just
> >>want to read man page. So I install man which on the other hand download
> >>another set of packages. I want to read man page and it downloads systemd.".
> >
> >On the majority of systems these days, is it really an issue to cache
> >man pages anymore?  I mean, back when a long man page (thinking about
> >some of the perl documentation for example) could take a while to
> >render, it mattered.  Now however, systems are much much faster, and we
> >expect GUI web browsers to render vastly more complicated content in a
> >fraction of a second.
> >
> >Maybe the time has come to just stop caching man pages at all, or at
> >least make that functionality optional (and non-default)?
> >
> 
> Hello,
> 
> I would add some noteworthy information:
> 
>  * the man-db cron/timer script is taking care of man DB containing
> only the man page title and short description i.e., the first NAME
> section of the man page. This DB is speeding up the searching in
> mentioned section with the man -k command. It is not used for
> displaying man pages or doing the full text search with man -K command
> and it is not required for normal usage of man command (man -k should
> also work without this DB).
> 
>  * Debian is updating this DB via deb hooks (or how it is called)
> during package installation/update and via daily cron script for man
> pages installed outside of package manager.
> 
>  * updating this DB is usually pretty quick, but creation can take some
> time..
> 
>  * man pages cache, pre-formatted man pages stored on disk in plain
> text, called cat pages in man-db context, is not used in Fedora.

I don't think that adding an additional subpackage to be manually
installed is worth the trouble. We should be making things simpler for
administrators, not require more manual involvement. From Peters'
description it seems it would be fine to simply ignore the timer and
not have the cache if systemd is not running for whatever reason. So
it would seem that ommitting systemd from the dependency list is the
answer. But omitting systemd from the dependency list is not possible,
because the dependency is necessary to order man-db after systemd in
case of a normal installation of both in one transaction. After things
calm down with F21, I'll return to the idea of splitting out
systemd-filesystem (name subject to change) to allow packages which
only need to enable a unit not to have a depenedency on full systemd
stack (see the thread "systemd dependencies" from August for recent
discussion).

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

New hardware for Retrace Server

2014-10-15 Thread Michal Toman 

Hi everybody,

we have just replaced the old (and slow :)) host running Retrace Server 
and ABRT server with a new one. The most significant changes for users are:
- Retracing now runs in memory, which means faster generating of 
backtraces (by an order of magnitude)

- Reports from CentOS 7 are now accepted and cross-referenced with Fedora
- ABRT Server now marks problems as probably fixed when a newer build 
exists and did not experience the problem in 14 days


Some more features will probably be deployed soon - new webui, filtering 
of tainted reports and displaying user comments - stay tuned :).


Please let us know in case anything does not work.

Michal & ABRT Team
--
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: The Poodlebleed Bug

2014-10-15 Thread Nathanael D. Noblet 
On Wed, 2014-10-15 at 17:00 +0100, Sérgio Basto wrote:
> this site 
> http://poodlebleed.com/ 
> 
> says that my server with F19 is vulnerable 
> 
> any news about this ? 

Disable SSL3? Who needs IE6 on XP?



-- 
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: The Poodlebleed Bug

2014-10-15 Thread Andrew Lutomirski 
On Wed, Oct 15, 2014 at 9:00 AM, Sérgio Basto  wrote:
> this site
> http://poodlebleed.com/
>
> says that my server with F19 is vulnerable
>
> any news about this ?

Poodlebleed?

For Pete's sake.  The attack is called POODLE, and it's much more
likely to be an attack against a client instead of an attack against a
server.

That being said, if you aren't serving a web page that you need IE6 on
XP to connect to, you can turn off SSLv3 to protect your clients.  The
setting varies depending on what server application you're using.

>
> Thanks,
> --
> Sérgio M. B.
>
> --
> 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: New hardware for Retrace Server

2014-10-15 Thread Josh Boyer 
On Wed, Oct 15, 2014 at 12:02 PM, Michal Toman  wrote:
>
> Some more features will probably be deployed soon - new webui, filtering of
> tainted reports and displaying user comments - stay tuned :).

YAY.  I'm really looking forward to the filtering changes :).

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: Engineering Representiatve for the new Fedora Council

2014-10-15 Thread Haïkel 
2014-10-15 17:21 GMT+02:00 Paul W. Frields :
>
> Although I may not have all the deep technical knowledge of some FESCo
> members, I'd be willing to serve in this capacity.  I do have
> experience working with different groups in Fedora, including the
> Board and FESCo, and release related groups like Rel-Eng, Docs, L10n,
> and Websites.
>

Deep technical knowledge should not be a prerequisite for this role,
fesco membership shouldn't either.

> I also manage the team in Red Hat that supports our infrastructure and
> applications.  That could come in handy in helping the Council direct
> resources to work on the priorities needed for Fedora to succeed.
>
> However, I want to be clear that my being involved is *not* a
> pre-requisite for that support.  I would expect to support Matthew and
> the Council regardless.  I'm sure there are other worthy candidates,
> and I'd work with any of them who fill this role.
>

I appreciate the gesture, and I expect that you will actively
participate in the council, whoever is chosen for this seat :)

H.

> --
> Paul W. Frieldshttp://paul.frields.org/
>   gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
>   http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
> The open source story continues to grow: http://opensource.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
-- 
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: man-db without cache update (no cron or systemd *.timer)

2014-10-15 Thread Ondrej Vasik 
On Wed, 2014-10-15 at 18:01 +0200, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Oct 15, 2014 at 05:12:07PM +0200, Peter Schiffer wrote:
> > On 10/15/2014 04:47 PM, Chris Adams wrote:
> > >Once upon a time, Jan Chaloupka  said:
> > >>there has been a discussion about if we need cache for man-db for users
> > >>which use man pages or update system only from time to time and thus
> > >>don't need to update cache every day. man-db as it is now depends on
> > >>systemd which brings another set of packages. The use case is "I just
> > >>want to read man page. So I install man which on the other hand download
> > >>another set of packages. I want to read man page and it downloads 
> > >>systemd.".
> > >
> > >On the majority of systems these days, is it really an issue to cache
> > >man pages anymore?  I mean, back when a long man page (thinking about
> > >some of the perl documentation for example) could take a while to
> > >render, it mattered.  Now however, systems are much much faster, and we
> > >expect GUI web browsers to render vastly more complicated content in a
> > >fraction of a second.
> > >
> > >Maybe the time has come to just stop caching man pages at all, or at
> > >least make that functionality optional (and non-default)?
> > >
> > 
> > Hello,
> > 
> > I would add some noteworthy information:
> > 
> >  * the man-db cron/timer script is taking care of man DB containing
> > only the man page title and short description i.e., the first NAME
> > section of the man page. This DB is speeding up the searching in
> > mentioned section with the man -k command. It is not used for
> > displaying man pages or doing the full text search with man -K command
> > and it is not required for normal usage of man command (man -k should
> > also work without this DB).
> > 
> >  * Debian is updating this DB via deb hooks (or how it is called)
> > during package installation/update and via daily cron script for man
> > pages installed outside of package manager.
> > 
> >  * updating this DB is usually pretty quick, but creation can take some
> > time..
> > 
> >  * man pages cache, pre-formatted man pages stored on disk in plain
> > text, called cat pages in man-db context, is not used in Fedora.
> 
> I don't think that adding an additional subpackage to be manually
> installed is worth the trouble. We should be making things simpler for
> administrators, not require more manual involvement. From Peters'
> description it seems it would be fine to simply ignore the timer and
> not have the cache if systemd is not running for whatever reason. So
> it would seem that ommitting systemd from the dependency list is the
> answer. But omitting systemd from the dependency list is not possible,
> because the dependency is necessary to order man-db after systemd in
> case of a normal installation of both in one transaction. After things
> calm down with F21, I'll return to the idea of splitting out
> systemd-filesystem (name subject to change) to allow packages which

Or we may even move unitdir into the basic filesystem package - if the
unitdir is the only requirement - which is probably the case for most of
the daemons. It would probably be better than systemd-filesystem
subpackage.

Ondrej

> only need to enable a unit not to have a depenedency on full systemd
> stack (see the thread "systemd dependencies" from August for recent
> discussion).
> 
> Zbyszek
> -- 
> 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

Fedora ARM Status Meeting - Cancelled - 2014-10-15

2014-10-15 Thread Paul Whalen 


Good afternoon all, 

Sorry for the short notice, a number of team members won't be able 
to make the meeting today so let's cancel this week. 

Please assist by testing Fedora 21 Beta TC3[1] and add the results
to the QA testing matrices[2].

If you have anything you would like to discuss in the interim, please
send to the list. 

Paul 

[1] - https://dl.fedoraproject.org/pub/alt/stage/21_Beta_TC3/
[2] - https://fedoraproject.org/wiki/Test_Results:Fedora_21_Beta_TC3_Summary
-- 
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: man-db without cache update (no cron or systemd *.timer)

2014-10-15 Thread Jóhann B. Guðmundsson 


On 10/15/2014 05:36 PM, Ondrej Vasik wrote:

On Wed, 2014-10-15 at 18:01 +0200, Zbigniew Jędrzejewski-Szmek wrote:

On Wed, Oct 15, 2014 at 05:12:07PM +0200, Peter Schiffer wrote:

On 10/15/2014 04:47 PM, Chris Adams wrote:

Once upon a time, Jan Chaloupka  said:

there has been a discussion about if we need cache for man-db for users
which use man pages or update system only from time to time and thus
don't need to update cache every day. man-db as it is now depends on
systemd which brings another set of packages. The use case is "I just
want to read man page. So I install man which on the other hand download
another set of packages. I want to read man page and it downloads systemd.".

On the majority of systems these days, is it really an issue to cache
man pages anymore?  I mean, back when a long man page (thinking about
some of the perl documentation for example) could take a while to
render, it mattered.  Now however, systems are much much faster, and we
expect GUI web browsers to render vastly more complicated content in a
fraction of a second.

Maybe the time has come to just stop caching man pages at all, or at
least make that functionality optional (and non-default)?


Hello,

I would add some noteworthy information:

  * the man-db cron/timer script is taking care of man DB containing
only the man page title and short description i.e., the first NAME
section of the man page. This DB is speeding up the searching in
mentioned section with the man -k command. It is not used for
displaying man pages or doing the full text search with man -K command
and it is not required for normal usage of man command (man -k should
also work without this DB).

  * Debian is updating this DB via deb hooks (or how it is called)
during package installation/update and via daily cron script for man
pages installed outside of package manager.

  * updating this DB is usually pretty quick, but creation can take some
time..

  * man pages cache, pre-formatted man pages stored on disk in plain
text, called cat pages in man-db context, is not used in Fedora.

I don't think that adding an additional subpackage to be manually
installed is worth the trouble. We should be making things simpler for
administrators, not require more manual involvement. From Peters'
description it seems it would be fine to simply ignore the timer and
not have the cache if systemd is not running for whatever reason. So
it would seem that ommitting systemd from the dependency list is the
answer. But omitting systemd from the dependency list is not possible,
because the dependency is necessary to order man-db after systemd in
case of a normal installation of both in one transaction. After things
calm down with F21, I'll return to the idea of splitting out
systemd-filesystem (name subject to change) to allow packages which

Or we may even move unitdir into the basic filesystem package - if the
unitdir is the only requirement - which is probably the case for most of
the daemons. It would probably be better than systemd-filesystem
subpackage.

Ondrej




I discussed this with Peter Schiffer and the end result was in the 
future the man-db cron should be removed and man-db database should be 
updated with rpm triggerand the cron job should be kept as is until 
then, presicecly to prevent this from happening ( systemd being pulled 
in when it should not or component magically expecting it to be there )  
and correct dependency on coreOS/baseOS components would be kept.


Just make FESCO/FPC clean this up it was them who decided not to make it 
mandatory what should or should not be migrated to timer units and this 
is precisely the fallout I had expected from not doing that.


Those individuals need to start accepting responsibility for the fallout 
from their decision making so as I said have them clean it up.


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

Re: man-db without cache update (no cron or systemd *.timer)

2014-10-15 Thread Zbigniew Jędrzejewski-Szmek 
On Wed, Oct 15, 2014 at 07:36:49PM +0200, Ondrej Vasik wrote:
> On Wed, 2014-10-15 at 18:01 +0200, Zbigniew Jędrzejewski-Szmek wrote:
> > On Wed, Oct 15, 2014 at 05:12:07PM +0200, Peter Schiffer wrote:
> > > On 10/15/2014 04:47 PM, Chris Adams wrote:
> > > >Once upon a time, Jan Chaloupka  said:
> > > >>there has been a discussion about if we need cache for man-db for users
> > > >>which use man pages or update system only from time to time and thus
> > > >>don't need to update cache every day. man-db as it is now depends on
> > > >>systemd which brings another set of packages. The use case is "I just
> > > >>want to read man page. So I install man which on the other hand download
> > > >>another set of packages. I want to read man page and it downloads 
> > > >>systemd.".
> > > >
> > > >On the majority of systems these days, is it really an issue to cache
> > > >man pages anymore?  I mean, back when a long man page (thinking about
> > > >some of the perl documentation for example) could take a while to
> > > >render, it mattered.  Now however, systems are much much faster, and we
> > > >expect GUI web browsers to render vastly more complicated content in a
> > > >fraction of a second.
> > > >
> > > >Maybe the time has come to just stop caching man pages at all, or at
> > > >least make that functionality optional (and non-default)?
> > > >
> > > 
> > > Hello,
> > > 
> > > I would add some noteworthy information:
> > > 
> > >  * the man-db cron/timer script is taking care of man DB containing
> > > only the man page title and short description i.e., the first NAME
> > > section of the man page. This DB is speeding up the searching in
> > > mentioned section with the man -k command. It is not used for
> > > displaying man pages or doing the full text search with man -K command
> > > and it is not required for normal usage of man command (man -k should
> > > also work without this DB).
> > > 
> > >  * Debian is updating this DB via deb hooks (or how it is called)
> > > during package installation/update and via daily cron script for man
> > > pages installed outside of package manager.
> > > 
> > >  * updating this DB is usually pretty quick, but creation can take some
> > > time..
> > > 
> > >  * man pages cache, pre-formatted man pages stored on disk in plain
> > > text, called cat pages in man-db context, is not used in Fedora.
> > 
> > I don't think that adding an additional subpackage to be manually
> > installed is worth the trouble. We should be making things simpler for
> > administrators, not require more manual involvement. From Peters'
> > description it seems it would be fine to simply ignore the timer and
> > not have the cache if systemd is not running for whatever reason. So
> > it would seem that ommitting systemd from the dependency list is the
> > answer. But omitting systemd from the dependency list is not possible,
> > because the dependency is necessary to order man-db after systemd in
> > case of a normal installation of both in one transaction. After things
> > calm down with F21, I'll return to the idea of splitting out
> > systemd-filesystem (name subject to change) to allow packages which
> 
> Or we may even move unitdir into the basic filesystem package - if the
> unitdir is the only requirement - which is probably the case for most of
> the daemons. It would probably be better than systemd-filesystem
> subpackage.
This is not about the unit dir, but about the %post scripts:
'systemctl enable', 'systemctl preset', etc.

(I don't think that the ownership of the directory is that important.
Packaging rules, and all that, I know, but the truth is that both the
location and format of systemd unit files is a stable upstream API,
and cannot realistically change without significant upheaval. So
I'd be totally fine with different packages co-owning the directory,
except that this doesn't really solve anything.)

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

Summary/Minutes from today's FESCo meeting (2014-10-15 at 17UTC)

2014-10-15 Thread Kevin Fenzi 
===
#fedora-meeting: FESCO (2014-10-15)
===


Meeting started by nirik at 17:00:11 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2014-10-15/fesco.2014-10-15-17.00.log.html
.



Meeting summary
---
* init process  (nirik, 17:00:11)

* #1322 F21 Changes - Progress at Change Checkpoint: 100% Code Complete
  Deadline  (nirik, 17:01:54)
  * LINK: https://fedorahosted.org/fesco/ticket/1322   (nirik, 17:01:54)
  * LINK: https://fedoraproject.org/wiki/Changes/jQuery no contingency;
postpone  (mitr, 17:04:31)
  * AGREED: postpone this change. (+6,0,0)  (nirik, 17:05:49)
  * LINK: https://fedoraproject.org/wiki/Changes/FormatSecurity; ignore
contingency (reverting the change), get someone to verify status
(mitr, 17:06:18)
  * AGREED: bug 1078901 Format Security - done/approved, will ask for a
status update on the bug (+6,0,0)  (nirik, 17:10:38)
  * LINK: https://fedoraproject.org/wiki/Changes/u-boot_syslinux,
contingency: “ make sure all supported boards work with
arm-boot-config and use it as a fallback. ”  (mitr, 17:11:11)
  * LINK:
http://fedoraproject.org/wiki/Architectures/ARM/Supported_Platforms
(mattdm, 17:36:39)
  * AGREED: 1078911 u-boot syslinux by default is blocking beta (+5,1,0)
(nirik, 17:42:17)
  * LINK:
https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork
no contingency needed, no known progress, proposal: propose  (mitr,
17:43:19)
  * AGREED: 1084102 PrivateDevices?=yes and PrivateNetwork?=yes For
Long-Running Services is postponed (+6,0,0)  (nirik, 17:46:04)
  * LINK:

https://fedoraproject.org/wiki/Changes/%28A%29Periodic_Updates_to_Cloud_Images
, no contingency needed  (mitr, 17:46:25)
  * AGREED: 1091299 (A)Periodic Updates to Cloud Images - (+6,0,0)
(nirik, 17:56:02)
  * LINK:
https://fedoraproject.org/wiki/Changes/Smaller_Cloud_Image_Footprint
, no cintingency needed  (mitr, 17:56:49)
  * change is ready for beta, no action needed.  (nirik, 17:57:24)
  * LINK: https://fedoraproject.org/wiki/Changes/Web_Assets , no
contingency needed.  (mitr, 17:58:16)
  * AGREED: 998583 Web Assets - postpone to f22 (+6,0,0)  (nirik,
18:00:19)
  * AGREED: atomic cloud work ongoing this week, still approved to land
(+6,0,0)  (nirik, 18:12:56)
  * will ping mariadb and mesos maintainers again since their changes
seem done.  (nirik, 18:14:22)

* #1350 Updates Policy should require inter-dependent packages be
  submitted together  (nirik, 18:15:37)
  * LINK: https://fedorahosted.org/fesco/ticket/1350   (nirik, 18:15:38)
  * AGREED: Make policy changes now, defer enforcement until later
(+6,0,0)  (nirik, 18:30:03)

* #1355 Please select Engineering Representiatve for the new Fedora
  Council  (nirik, 18:30:20)
  * LINK: https://fedorahosted.org/fesco/ticket/1355   (nirik, 18:30:21)
  * HELP: all this should be added to the fesco elections page or a
council page or somewhere better than meeting minutes.  (mattdm,
18:43:04)
  * AGREED: Draft of fedora council represenative selection process to
be written up and ratified next week. (+5,0,0)  (nirik, 18:46:11)
  * ACTION: dgilmore-bne to send out announcement of nomination period
starting.  (nirik, 18:48:57)
  * ACTION: jwb to write up draft of selection policy document for next
week  (nirik, 18:49:15)

* Next week's chair  (nirik, 18:49:21)
  * mattdm to chair next week.  (nirik, 18:51:50)

* Open Floor  (nirik, 18:51:55)

Meeting ended at 18:54:08 UTC.




Action Items

* dgilmore-bne to send out announcement of nomination period starting.
* jwb to write up draft of selection policy document for next week




Action Items, by person
---
* dgilmore
  * dgilmore-bne to send out announcement of nomination period starting.
* dgilmore-bne
  * dgilmore-bne to send out announcement of nomination period starting.
* jwb
  * jwb to write up draft of selection policy document for next week
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* nirik (163)
* mattdm (87)
* dgilmore-bne (72)
* jwb (66)
* mitr (55)
* kalev (30)
* tflink (21)
* adamw (17)
* zodbot (17)
* pjones (8)
* halfie (3)
* taquilla (1)
* misc (1)
* mmaslano (0)
* sgallagh (0)
* t8m (0)
* thozza (0)
* dgilmore (0)
--
17:00:11  #startmeeting FESCO (2014-10-15)
17:00:11  Meeting started Wed Oct 15 17:00:11 2014 UTC.  The chair is 
nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:11  Useful Commands: #action #agreed #halp #info #idea #link 
#topic.
17:00:11  #meetingname fesco
17:00:11  #chair dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh 
t8m thozza
17:00:11  #topic init process
17:00:11  The meeting name has been set to 'fesco'
17:00:11  Current chairs: dgilmore jwb kalev mattdm mitr mmaslano nirik 
sgallagh t8m thozza
17:00:16  Hello
17:00:26  hi
17:00:48  hola
17:00:54 *

Re: Summary/Minutes from today's FESCo meeting (2014-10-15 at 17UTC)

2014-10-15 Thread Jerry James 
On Wed, Oct 15, 2014 at 12:54 PM, Kevin Fenzi  wrote:
> * #1350 Updates Policy should require inter-dependent packages be
>   submitted together  (nirik, 18:15:37)
>   * LINK: https://fedorahosted.org/fesco/ticket/1350   (nirik, 18:15:38)
>   * AGREED: Make policy changes now, defer enforcement until later
> (+6,0,0)  (nirik, 18:30:03)

That ticket has already been closed, so I will comment here.  Say that
I have a package that I want to update, the update breaks somebody
else's package, and I lack the knowledge to fix that other package.
How much waiting for the other maintainer am I required to undergo?
The discussion on the ticket implies that the answer is "an infinite
amount of time".  Is that really the intent?  Let me present two cases
where I think "an infinite amount of time" is the wrong answer.

The first case is when a non-critpath package depends on a critpath
package.  I've got a concrete example.  I maintain the polymake
package.  It has its hooks buried deeply into the guts of perl, so it
depends on the exact perl version it was built with.  Every major perl
release, without fail, breaks polymake.  Sometimes upstream has
already noticed and I can update to the latest snapshot to fix the
problem.  Sometimes upstream has not noticed and I have to ask them to
produce a fix, which can sometimes take a little while.  If a critical
perl update were needed, say to fix a glaring performance or security
problem, and the update broke the polymake build, I think the right
thing to do would be to push the perl update anyway.  That will break
things for me and both of the other people who use polymake (hi,
guys!), but too bad for us.  We can fix polymake as quickly as we can
and get things back to normal, but we shouldn't block that update from
going out to all of the people who need it.

The second case is hypothetical, although it is loosely based on an
actual situation I encountered a couple of years ago.  Say that I want
to push a non-backwards-compatible update to a library, and that
packages A, B, and C depend on that library.  I rebuild A and B
successfully with the new version of the library, but C fails to
rebuild.  I try to diagnose the problem, but find that C is such a
horrible mass of spaghetti that I can't make heads or tails out of it.
So I file a bug against C and wait for the maintainer to respond.  And
wait.  And wait.  And wait.  At what point am I allowed to push the
new version of the library, along with A and B rebuilds, and write C
off as a loss, since I can't fix it and the maintainer isn't
responding?  Does it depend on the severity of the problem the update
is intended to fix?  If so, who is the judge of degree of severity?
-- 
Jerry James
http://www.jamezone.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: Review swap

2014-10-15 Thread Jerry James 
On Mon, Oct 13, 2014 at 11:42 AM, Jerry James  wrote:
> One of my packages has picked up a dependency on libpuma in a new release:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1135654
>
> Would someone care to do a review swap?  Thanks,

I've had some helpful comments on the bug, but no takers for a review
yet.  Would someone care to swap with me?  Give me a hard one.  I
probably deserve it.
-- 
Jerry James
http://www.jamezone.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: Summary/Minutes from today's FESCo meeting (2014-10-15 at 17UTC)

2014-10-15 Thread Kevin Fenzi 
On Wed, 15 Oct 2014 13:32:50 -0600
Jerry James  wrote:

> On Wed, Oct 15, 2014 at 12:54 PM, Kevin Fenzi  wrote:
> > * #1350 Updates Policy should require inter-dependent packages be
> >   submitted together  (nirik, 18:15:37)
> >   * LINK: https://fedorahosted.org/fesco/ticket/1350   (nirik,
> > 18:15:38)
> >   * AGREED: Make policy changes now, defer enforcement until later
> > (+6,0,0)  (nirik, 18:30:03)
> 
> That ticket has already been closed, so I will comment here.  Say that
> I have a package that I want to update, the update breaks somebody
> else's package, and I lack the knowledge to fix that other package.
> How much waiting for the other maintainer am I required to undergo?

Speaking for myself, "A reasonable amount of time". 

There are going to be cases where you can't push all interdependent
packages at the same time. You should try and avoid that, but it could
well happen. 

This is one of the reasons we were talking about taskotron and
enforcement. There MUST be a way to override any auto enforcement for
at least: 

* I know this one thing is broken, but it's vastly less important than
  fixing all these others. 

* The test is wrong/broken/bugged. 

kevin


signature.asc
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

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

2014-10-15 Thread James Antill 
 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2014-10-16 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. rktime):

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

 Links to all tickets below can be found at: 

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

= Followups =

#topic #382 Go Packaging Guidelines Draft
.fpc 382
https://fedorahosted.org/fpc/ticket/382

(more info. needed, PHP now complies)
#topic #452 Crypto policies packaging guideline
.fpc 452
https://fedorahosted.org/fpc/ticket/452

(more info. needed)
#topic #454 Bundling exception for php-phpoffice-phpexcel
.fpc 454
https://fedorahosted.org/fpc/ticket/454

= 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
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Summary/Minutes from today's FESCo meeting (2014-10-15 at 17UTC)

2014-10-15 Thread Kalev Lember 
On 10/15/2014 09:32 PM, Jerry James wrote:
> On Wed, Oct 15, 2014 at 12:54 PM, Kevin Fenzi  wrote:
>> * #1350 Updates Policy should require inter-dependent packages be
>>   submitted together  (nirik, 18:15:37)
>>   * LINK: https://fedorahosted.org/fesco/ticket/1350   (nirik, 18:15:38)
>>   * AGREED: Make policy changes now, defer enforcement until later
>> (+6,0,0)  (nirik, 18:30:03)
> 
> That ticket has already been closed, so I will comment here.  Say that
> I have a package that I want to update, the update breaks somebody
> else's package, and I lack the knowledge to fix that other package.
> How much waiting for the other maintainer am I required to undergo?
> The discussion on the ticket implies that the answer is "an infinite
> amount of time".  Is that really the intent?  Let me present two cases
> where I think "an infinite amount of time" is the wrong answer.

One thing that might not have been clear when reading the FESCo
discussion is that this only applies to the releases where Bodhi is
enabled -- the stable releases (F19, F20) and Branched (F21). It does
_not_ apply to rawhide.

> The first case is when a non-critpath package depends on a critpath
> package.  I've got a concrete example.  I maintain the polymake
> package.  It has its hooks buried deeply into the guts of perl, so it
> depends on the exact perl version it was built with.  Every major perl
> release, without fail, breaks polymake.  Sometimes upstream has
> already noticed and I can update to the latest snapshot to fix the
> problem.  Sometimes upstream has not noticed and I have to ask them to
> produce a fix, which can sometimes take a little while.  If a critical
> perl update were needed, say to fix a glaring performance or security
> problem, and the update broke the polymake build, I think the right
> thing to do would be to push the perl update anyway.  That will break
> things for me and both of the other people who use polymake (hi,
> guys!), but too bad for us.  We can fix polymake as quickly as we can
> and get things back to normal, but we shouldn't block that update from
> going out to all of the people who need it.

We shouldn't get a perl rebase in a a stable Fedora release anyway.
Major Perl rebases are always System Wide Changes and land in rawhide
before the next release is branched.

> The second case is hypothetical, although it is loosely based on an
> actual situation I encountered a couple of years ago.  Say that I want
> to push a non-backwards-compatible update to a library, and that
> packages A, B, and C depend on that library.  I rebuild A and B
> successfully with the new version of the library, but C fails to
> rebuild.  I try to diagnose the problem, but find that C is such a
> horrible mass of spaghetti that I can't make heads or tails out of it.
> So I file a bug against C and wait for the maintainer to respond.  And
> wait.  And wait.  And wait.  At what point am I allowed to push the
> new version of the library, along with A and B rebuilds, and write C
> off as a loss, since I can't fix it and the maintainer isn't
> responding?  Does it depend on the severity of the problem the update
> is intended to fix?  If so, who is the judge of degree of severity?

Pushing out ABI incompatible library versions in a stable Fedora release
isn't something one should do anyway. They should either go in the next
Fedora (rawhide), or if it's important to backport the ABI change to the
current stable release, it's best to introduce a parallel-installable
package for the new library. If an ABI change cannot be avoided, it's
possible to ask for a FESCo exception:
http://fedoraproject.org/wiki/Updates_Policy#Exceptions

-- 
Hope this clears things up,
Kalev
-- 
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: Summary/Minutes from today's FESCo meeting (2014-10-15 at 17UTC)

2014-10-15 Thread Matthew Miller 
On Wed, Oct 15, 2014 at 09:54:23PM +0200, Kalev Lember wrote:
> One thing that might not have been clear when reading the FESCo
> discussion is that this only applies to the releases where Bodhi is
> enabled -- the stable releases (F19, F20) and Branched (F21). It does
> _not_ apply to rawhide.

Yes. But also worth noting that _eventually_ I think we want to get to some
point where there are gate checks to rawhide, or at least for some subset of
what is currently rawhide.


-- 
Matthew Miller

Fedora Project Leader
-- 
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 hardware for Retrace Server

2014-10-15 Thread Kalev Lember 
On 10/15/2014 06:02 PM, Michal Toman wrote:
> Hi everybody,
> 
> we have just replaced the old (and slow :)) host running Retrace Server
> and ABRT server with a new one. The most significant changes for users are:
> - Retracing now runs in memory, which means faster generating of
> backtraces (by an order of magnitude)
> - Reports from CentOS 7 are now accepted and cross-referenced with Fedora
> - ABRT Server now marks problems as probably fixed when a newer build
> exists and did not experience the problem in 14 days
> 
> Some more features will probably be deployed soon - new webui, filtering
> of tainted reports and displaying user comments - stay tuned :).

NICE!

I am really excited to hear about this. The retrace server with its web
UI is seriously awesome and helps prioritise bugs to work on and find
crashers that a lot of people hit.

Thanks for working on this!

-- 
Kalev
-- 
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: bugzilla usage trends

2014-10-15 Thread Jakub Filak 
On Fri, 2014-10-10 at 11:12 +0100, Richard W.M. Jones wrote:
> On Thu, Oct 09, 2014 at 05:39:34PM -0400, Przemek Klosowski wrote:
> > I was curious about the rate of bug reporting in Fedora, and did
> > this quick experiment. I thought it might be interesting to folks
> > here who either work on the infrastructure or are curious about
> > long-term collaboration trends in Fedora.
> > 
> > I checked the date of reporting of every 10,000th bug (bugzilla #1,
> > #1, etc, all the way to the recent 115---see attached data).
> > Some bugs were private so I didn't have access to their info, but I
> > got enough data to  calculate bug velocity (increase in the bug
> > number divided by the time interval) over time. The data is a little
> > noisy, but you can clearly see the ever-increasing trend.
> 
> I'm afraid there are a couple of problems with this analysis:
> 
> - Automated bugs (eg from abrt) may or may not be considered to be
>   real bug reports.

~35% bugs are from ABRT :
https://jfilak.fedorapeople.org/media/abrt_bz_stats.txt



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

Re: New hardware for Retrace Server

2014-10-15 Thread Orion Poplawski 

On 10/15/2014 10:02 AM, Michal Toman wrote:

Hi everybody,

we have just replaced the old (and slow :)) host running Retrace Server
and ABRT server with a new one. The most significant changes for users are:
- Retracing now runs in memory, which means faster generating of
backtraces (by an order of magnitude)
- Reports from CentOS 7 are now accepted and cross-referenced with Fedora
- ABRT Server now marks problems as probably fixed when a newer build
exists and did not experience the problem in 14 days

Some more features will probably be deployed soon - new webui, filtering
of tainted reports and displaying user comments - stay tuned :).

Please let us know in case anything does not work.

Michal & ABRT Team


We used to have the ability to get statistics grouped by packager, 
right, or am I mis-remembering?


--
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: New hardware for Retrace Server

2014-10-15 Thread Jakub Filak 
On Wed, 2014-10-15 at 16:55 -0600, Orion Poplawski wrote:
> 
> We used to have the ability to get statistics grouped by packager, 
> right, or am I mis-remembering?

We still have it, but you can filter by packager only on 'Problems'
page:

https://retrace.fedoraproject.org/faf/problems/hot/*/265/*/


Or are you missing something else?



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

Nominations for Engineering representative to the Fedora Council

2014-10-15 Thread Dennis Gilmore 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi All,

As you are likely aware, we are undergoing some changes in governance[1]
for Fedora On behalf of FESCo I am writing to you all to ask for
nominations. preferably people will self nominate, however we will
accept nominations from others as longa s the nominated person agrees
to be considered.

In order to submit your nomination please notify FESCo via the
currently open ticket[2] in trac requesting a FESCo appointee. you have
until Tuesday October 21 @ 23:59 UTC to get nominations in. FESCo will
choose a representive in next weeks meeting.

Thank you

Dennis

[1] https://fedoraproject.org/wiki/Council
[2] https://fedorahosted.org/fesco/ticket/1355
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJUP1+IAAoJEH7ltONmPFDRfb4P/1xvmQpyqMuECBQEBoQi3d5l
6FGJCV2ckbfxzFhqzuunbOWM7/k/e6J3F4zmJvL3QoefV9svUs/uNtCVM5ZNfgEZ
W87Qf8K9Zar0dXyhhu2X6NFvKNnKMVCZZ4k7izfAAD/Kh8esutx9wujzaPXJYBBe
uLscNfUG8fUAfBCmMjqlAyYgongOaOg7c27M3rRG7Q28Dmo5O17UdCvX1Kz4cdzX
Pusblj3JSiIBnNtrug+d8OzQIrP8M0tITy/yxFi0m40lMOEH/zve85gg8nrF/yf5
F61IKeh8B39pp5iZkZdOSQ3AVR63sUbpNW3YM1KKQ8YMZ3RSA+sfK95v0cIgfGKM
mikySeEJgALh1tDl6J5ROoIItZRzhsO5ZdleMYTEMDMBg0jVZGeGVht1E4iVn05l
VDGh41oAXOfvyo5SDW8nYzogeawW/bLIV1ie8q4GTZRObOCckQjJ6bePEVMkByFt
0T7y4HBmHd7RodPpEn8luDLE0neju+vFwvkQQGaA9F+uHwdq4m4+Anfw/IEflYj1
GcngtzDAMKAqokJf66btqbRrXzjqKnfPGpQOc0LcVQ2BX6q9t3AHCOdff0m1h433
c/5JGSmBHhcOA/X5dZn+lF6HEM7IvA2ITZEdDsRLSNzvNUASUqEVlBpvXrKY4Kx0
pjUQFWFe9yoqCz3DNvqZ
=CNA+
-END 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
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct