rawhide report: 20151101 changes

[Fedora Rawhide Report]

Compose started at Sun Nov  1 05:15:03 UTC 2015
Broken deps for i386
--
[IQmol]
IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0
IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0
IQmol-2.3.0-9.fc24.i686 requires libOpenMeshCore.so.3.2
[alliance]
alliance-5.0-40.20090901snap.fc22.i686 requires libXm.so.2
[autofs]
1:autofs-5.1.1-3.fc23.i686 requires libtirpc.so.1(TIRPC_0.3.0)
1:autofs-5.1.1-3.fc23.i686 requires libtirpc.so.1
[coriander]
coriander-2.0.1-9.fc23.i686 requires libftp.so.3
[eclipse-jbosstools]
eclipse-jbosstools-as-4.2.2-1.fc22.noarch requires 
osgi(org.eclipse.tm.terminal)
[fawkes]
fawkes-plugin-player-0.5.0-26.fc24.i686 requires libgeos-3.4.2.so
[fedfs-utils]
fedfs-utils-admin-0.10.3-4.fc23.i686 requires libtirpc.so.1(TIRPC_0.3.0)
fedfs-utils-admin-0.10.3-4.fc23.i686 requires libtirpc.so.1
fedfs-utils-server-0.10.3-4.fc23.i686 requires 
libtirpc.so.1(TIRPC_0.3.1)
fedfs-utils-server-0.10.3-4.fc23.i686 requires 
libtirpc.so.1(TIRPC_0.3.0)
fedfs-utils-server-0.10.3-4.fc23.i686 requires libtirpc.so.1
[gnash]
1:gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires 
libboost_serialization.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-klash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-klash-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-plugin-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:python-gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:python-gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:python-gnash-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:python-gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
[golang-github-kraman-libcontainer]
golang-github-kraman-libcontainer-devel-0-0.4.gitd700e5b.fc24.noarch 
requires golang(github.com/docker/docker/pkg/netlink)
[golang-github-kubernetes-heapster]
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/google/cadvisor/info/v1)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/google/cadvisor/client)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/coreos/fleet/schema)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/coreos/fleet/registry)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/coreos/fleet/p

How to manage libraries with no stack canary

[Antonio Trande]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi all,

current WildMagic5 (http://www.geometrictools.com/) libraries, rebuilt
with flags for hardened builds
(https://fedoraproject.org/wiki/Changes/Harden_All_Packages), are:

# checksec --dir /usr/lib64 | grep Wm5
Full RELRO  No canary found   NX enabledDSO No
RPATH   No RUNPATH   /usr/lib64/libWm5Applications.so.5.13

Full RELRO  Canary found  NX enabledDSO No
RPATH   No RUNPATH   /usr/lib64/libWm5Core.so.5.13

Full RELRO  Canary found  NX enabledDSO No
RPATH   No RUNPATH   /usr/lib64/libWm5Graphics.so.5.13

Full RELRO  Canary found  NX enabledDSO No
RPATH   No RUNPATH   /usr/lib64/libWm5Imagics.so.5.13

Full RELRO  Canary found  NX enabledDSO No
RPATH   No RUNPATH   /usr/lib64/libWm5Mathematics.so.5.13

Full RELRO  Canary found  NX enabledDSO No
RPATH   No RUNPATH   /usr/lib64/libWm5Physics.so.5.13

Samples executable files are tagged with noPIE: http://fpaste.org/285748/

I don't know how to manage the file with "No canary found" supposing
that i have added all flags correctly.

SPEC file: http://fpaste.org/285749/
Scratch build on F22:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1121

- -- 
Antonio Trande

mailto: sagitter 'at' fedoraproject 'dot' org
http://fedoraos.wordpress.com/
https://fedoraproject.org/wiki/User:Sagitter
GPG Key: 0x565E653C
Check on https://keys.fedoraproject.org/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWNi5qAAoJEF5tK7VWXmU8BOoH/igVYj/2+T7LH0tYpmS2BCNm
KEsm5Yh2dTdb06qe+64dxYUYhP4kcS2BSSXrb0QNxpl/c/5xGiy+lgzkwXgfdWUA
W8q5GR6lsmhqQxFssM9BPONKMM2/+MGwfMc3xS91C5V7G6vIegYAxdNOSBoQwDyy
qYa1SUVGxrw2FgWBQ9hcWe6Dh1vS+TcAn7XKU52HtSQHpsMxJUz9S84qBPHhOxf0
yH8jvE7zio6kSXyPSFv72HKYecJC2wuXBNF3pEKqVL3mukYT0I1uaQAcXocxuuMp
rimWFblKU2uk9ScnZ1WchkznRSswS0EL8IH3w4FMYD532mppmmvhXmSG1IfAGHY=
=97xg
-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

Orphaning JBoss Tools package

[Gerard Ryan]

Hi devel list (and cc'ed eclipse-sig list),

I'm going to orphan the eclipse-jbosstools package in rawhide, as I'm no
longer able to give it the time that it needs. My understanding is that
if nobody takes it, it will be auto-retired after 6 weeks (please
correct me if I'm wrong here).

If you're interested in taking it & have any questions, I'm happy to
provide any input I can. I think ideally it would want more than one
active maintainer to get it into the shape that it needs to be (not all
features are currently packaged, and significant effort would be
required there).

Thanks,
Gerard.
-- 
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: To distro-sync or not distro-sync?

[Nico Kadel-Garcia]

On Thu, Oct 29, 2015 at 5:56 AM, Reindl Harald  wrote:
>
>
> Am 29.10.2015 um 10:09 schrieb Christopher Meng:
>>
>> You have a chance to get your rpmfusion softwares wiped after the sync.
>>
>> [1]---https://bugzilla.redhat.com/show_bug.cgi?id=1263677
>
>
> unacceptable
>
> the software upgrade just have to mention the conflicting packages and stop
> until somebody enables a --force switch and in general DNF has to be much
> more verbose in case of dependency problems instead just saying "can't do
> anything because broken deps"
>
> in the past you saw *exactly* which package requires which so-version and so
> find out where the problem starts, which packages you may consider to remove
> and then try again
>
> currently we have some sort of blackbox with no output how to solve
> dependency problems

Is there any reason you can't put that in the actual Bugzilla thread?
-- 
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: no influxdb for fedora 22, but there is for 21 and 23

[Jan Chaloupka]

Hi Muayyad,

i have requested to push the build into f22 stable. Still, there is no 
influxdb subpackage with binaries. Just curious, what are you using the 
package for?


Regards
Jan

On 10/31/2015 05:19 PM, Muayyad AlSadi wrote:

but there is an old "stable" one for fedora 21?!

https://bodhi.fedoraproject.org/updates/FEDORA-2015-0299

how can this happen? did I miss something or it's normal?


On Sat, Oct 31, 2015 at 5:14 PM, Tomasz Torcz > wrote:


On Sat, Oct 31, 2015 at 04:58:31PM +0200, Muayyad AlSadi wrote:
> Hi,
>
> it seems that influxdb is missing in fedora 22
>
>

https://bodhi.fedoraproject.org/updates/?packages=golang-github-influxdb-influxdb
>
> [root@laptop ~]# cat /etc/system-release
> Fedora release 22 (Twenty Two)
>
> [root@laptop ~]# dnf -C info golang-github-influxdb-influxdb
> Last metadata expiration check performed 2:59:31 ago on Sat Oct
31 13:57:20
> 2015.
> Error: No matching Packages to list

  It stil being tested:
https://bodhi.fedoraproject.org/updates/FEDORA-2015-14091

  You can help by instaling it from updates-testing, checking if
it works
and providing positive comment on Bodhi page.


--
Tomasz Torcz72->|   80->|
xmpp: zdzich...@chrome.pl 
72->|  80->|


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






--
Jan Chaloupka
--
* Software Engineer  *
* Server Experience  *
* Red Hat Czech, s. r. o.*
* UTC+1 (CET), jchaloup  *

-- 
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: packaging golang guidelines (like etcd, consul)

[Jan Chaloupka]

On 10/30/2015 10:07 PM, Muayyad AlSadi wrote:

hi,

I'm on f22 and have consul and etcd from the repos

ldd /usr/bin/consul
linux-vdso.so.1 (0x7ffc98fa2000)
liblmdb.so.0.0.0 => /lib64/liblmdb.so.0.0.0 (0x7f99bc1b5000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f99bbf99000)
libc.so.6 => /lib64/libc.so.6 (0x7f99bbbd8000)
/lib64/ld-linux-x86-64.so.2 (0x562f58dbf000)

ldd /usr/bin/etcd
not a dynamic executable

I found that when CGO_ENABLED=0 it would be statically linked
the dynamic one like consul above is not actually dynamically linked 
(because of the size)


are there some fedora guidelines for golang apps?
are there macros and helpers for rpm?



https://fedoraproject.org/wiki/PackagingDrafts/Go





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

Re: Fedora 23 Final RC10 status is GO !

[Sérgio Basto]

On Sex, 2015-10-30 at 17:47 +0100, Jan Kurik wrote:
> At the third round of Fedora 23 Final Go/No-Go Meeting, that just
> ends, has been Fedora 23 Final-RC10 declared as GOLD.
> GA of this release is planed on Tuesday 2015-Nov-03.
> 
Today we got 531 updates for F23 , IMO, you should include it on Fedora
23 Final before GA , doesn't make sense (to me) after download an ISO
have 1/2 Giga of updates, but this happens since RedHad 9 at least . 
IMO, testing team should respin ISO with updates and testing again . 
I have some difficulty in following all development, fortunately Fedora
is always at great speed, but it is not easy to follow. And do more
tests we not lose anything, IMHO.


Thanks,




> Meeting details can be seen here:
> Minutes:
> http://meetbot.fedoraproject.org/fedora-meeting-2/2015-10-30/f23-final-go_no_go-meeting_3.2015-10-30-16.00.html
> Log:
> http://meetbot.fedoraproject.org/fedora-meeting-2/2015-10-30/f23-final-go_no_go-meeting_3.2015-10-30-16.00.log.html
> 
> Thanks everyone who participated on this release!
> 
> 
> Regards,
> 
> Jan
> 
> -- 
> Jan Kuřík
> Platform & Fedora Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
> ___
> devel-announce mailing list
> devel-annou...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel-announce

-- 
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: Fedora 23 Final RC10 status is GO !

[Digimer]

On 01/11/15 12:06 PM, Sérgio Basto wrote:
> On Sex, 2015-10-30 at 17:47 +0100, Jan Kurik wrote:
>> At the third round of Fedora 23 Final Go/No-Go Meeting, that just
>> ends, has been Fedora 23 Final-RC10 declared as GOLD.
>> GA of this release is planed on Tuesday 2015-Nov-03.
>>
> Today we got 531 updates for F23 , IMO, you should include it on Fedora
> 23 Final before GA , doesn't make sense (to me) after download an ISO
> have 1/2 Giga of updates, but this happens since RedHad 9 at least . 
> IMO, testing team should respin ISO with updates and testing again . 
> I have some difficulty in following all development, fortunately Fedora
> is always at great speed, but it is not easy to follow. And do more
> tests we not lose anything, IMHO.
> 
> 
> Thanks,

How does that compare to the normal volume of incoming updates? What I
mean is, if they re-rolled and re-tested, would a roughly similar number
of updates be waiting again?

-- 
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without
access to education?
-- 
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: [HEADS UP] Upcoming soname change for libtirpc

[Kalev Lember]

On 10/30/2015 05:36 PM, Kevin Fenzi wrote:
> On Fri, 30 Oct 2015 11:50:48 -0400
> Steve Dickson  wrote:
>> 2) find and rebuild all the dependencies?
> 
> Should be something like: 
> 
> % sudo dnf repoquery --whatrequires 'libtirpc.so.1()(64bit)'
> Last metadata expiration check performed 0:01:17 ago on Fri Oct 30 10:34:06 
> 2015.
> autofs-1:5.1.1-3.fc23.x86_64
> fedfs-utils-admin-0:0.10.3-4.fc23.x86_64
> fedfs-utils-server-0:0.10.3-4.fc23.x86_64
> libtirpc-devel-0:0.3.2-3.0.fc24.x86_64
> nfs-utils-1:1.3.2-10.fc23.x86_64
> rpcbind-0:0.2.3-0.2.fc23.x86_64

Now that the libtirpc update is in, I tried to kick off rebuilds for
these to make them them installable again in rawhide (they are breaking
nightly image composes). Didn't get very far with this though because
rpcbind and fedfs-utils are failing to build and are blocking others:

rpcbind (http://koji.fedoraproject.org/koji/buildinfo?buildID=695404) failed 
with:

src/rpcb_svc_com.c: In function 'handle_reply':
src/rpcb_svc_com.c:1277:6: error: 'SVCXPRT {aka struct __rpc_svcxprt}' has no 
member named 'xp_auth'
  xprt->xp_auth = &svc_auth_none;

and fedfs-utils (http://koji.fedoraproject.org/koji/buildinfo?buildID=695402) 
failed the same way:

gss.c: In function 'fedfsd_get_gss_cred':
gss.c:178:23: error: 'SVCXPRT {aka struct __rpc_svcxprt}' has no member named 
'xp_auth'
  auth = rqstp->rq_xprt->xp_auth;

-- 
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: Fedora 23 Final RC10 status is GO !

[Peter Robinson]

On Sun, Nov 1, 2015 at 5:06 PM, Sérgio Basto  wrote:
> On Sex, 2015-10-30 at 17:47 +0100, Jan Kurik wrote:
>> At the third round of Fedora 23 Final Go/No-Go Meeting, that just
>> ends, has been Fedora 23 Final-RC10 declared as GOLD.
>> GA of this release is planed on Tuesday 2015-Nov-03.
>>
> Today we got 531 updates for F23 , IMO, you should include it on Fedora
> 23 Final before GA , doesn't make sense (to me) after download an ISO
> have 1/2 Giga of updates, but this happens since RedHad 9 at least .
> IMO, testing team should respin ISO with updates and testing again .
> I have some difficulty in following all development, fortunately Fedora
> is always at great speed, but it is not easy to follow. And do more
> tests we not lose anything, IMHO.

The problem is we have to freeze sometime to ensure stability in the
installer platform, the live and other images which are static. If not
it's too much of a moving target to try and QA and ensure everything
works as expected. To freeze is a fairly standard procedure for all
distro development.

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: Self Introduction: Randy Barlow

[Randy Barlow]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/07/2015 01:37 PM, Randy Barlow wrote:
> I've filed a request to add a new package called ari-backup:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1269609

My package reviewer and I had some questions about whether the
permissions I have set in my spec file are justifiable or not. This
software is a backup server, and the spec file I have created
configured the backup store (/var/lib/ari-backup) to have restrictive
permissions (root:root, 0700). The reasoning is that I didn't want to
assume that it would be OK for other users who may have access to the
backup server to be able to see files from other systems that have
been stored there.

Additionally, the folder /etc/ari-backup/jobs.d contains job
configuration files, and is also configured for 0700. This is to
prevent any information about what is being backed up (and how it is
being backed up) from leaking. The backup jobs in there are Python
scripts, and can contain arbitrary code to be executed during the
backup jobs.

What do others think? Are the permissions I have selected in my spec
file appropriate for a backup server?

- -- 
R
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWNlHEAAoJEHhEzLg73SRi30AP/37NkJEKbU0gObQ+vilkgRwM
xV/nKACEXYV1YKz6RIch/PrVF9pGoVmPsXMEnVr3SHYL+nuCXRlwbQuLci4id9JS
3b/rudUScW5IMVAinvCsWuep03ryOc72qr57o2lrjijh1jiGyw2pRtWXknUzaxZD
igChWE/zZ16BaSpGrRQegG38cySo/SwaCz16xseHop0GhN+ZGxGETwIVOUEHg0ar
hJPJnvK/18EtzsU1XheVk/vA13EdpGbPmGglt5ljeDfdJunM/4LVMX8bUQQ9hvLV
GPIpc/8DvBH+V+MLgSQrsRfqBQo+gopdwNSl8OjHeoD4bRg1PFdI7ezAf4bQL6l6
nVPaLQ0+iGgc5J9AtuDpVqT2Zk5a/ywymis6zEgYN71vM7Gw8CqC1qLT0iwDFlVa
DZ+Kz1eMYGgH6Q9bte6kkxoVOhNaY7jlhoKCcCa8LQLGEGxaX2GpT5VTkhpa0r90
7sXhUW1sonvHZoNXB9Dtcv++3OmLuvnqqmAg5PVOPiTtsX+3yar4sU8/qDm8kFWO
vJV+QYucsuqLW9icJuLazf1LK/Q18Rxg3bzQtyW6sD8gafI4wFoYxReR8FOzA5vi
c/TOAFNKdNK+4kkn1RD5zeefouOhO0dbCTqZGGu2z2sTSyhkYqNZajj8ICTw4kE5
0bCKtYsaWj8DN92IkDzp
=GNAx
-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: Fedora 23 Final RC10 status is GO !

[Kevin Kofler]

Peter Robinson wrote:
> The problem is we have to freeze sometime to ensure stability in the
> installer platform, the live and other images which are static. If not
> it's too much of a moving target to try and QA and ensure everything
> works as expected. To freeze is a fairly standard procedure for all
> distro development.

IMHO, we should have at most 1 week of strict freeze. If we decide that we 
have to slip anyway, then we should pull in ALL updates pending stable and 
restart the release process (freeze, spin RCs, test) from there.

(That would also make it less painful to slip multiple times and thus 
decrease the pressure to rush out quick hacks to work around blockers 
instead of clean fixes.)

I also think that the decision:
* when an image is a Go,
* what issues to consider as blockers and
* what new builds to take as freeze overrides
ought to be made by the WG/SIG responsible for the individual deliverable. 
(And this is NOT a personal power grab attempt. I am no longer a voting 
member of the KDE SIG, for reasons detailed on the kde mailing list.) The 
current process where the SIG/WG has to argue for every single freeze 
override they want to take in, and have rel-eng/QA reject some of them, is 
just broken (and there I can speak from experience, with my 8 years of KDE 
SIG involvement).

Kevin Kofler

-- 
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 Rawhide 20151101 compose check report

[Fedora compose checker]

Missing expected images:

Cloud disk raw i386
Cloud_atomic disk raw x86_64
Generic boot x86_64
Workstation live x86_64
Workstation live i386
Generic boot i386
Kde disk raw armhfp
Kde live i386
Cloud disk raw x86_64
Kde live x86_64

No images in this compose but not Rawhide 20151031

Images in Rawhide 20151031 but not this:

Xfce live i386
Games live x86_64
Lxde live i386
Soas disk raw armhfp
Security live x86_64
Games live i386
Soas live x86_64
Xfce live x86_64
Lxde live x86_64
Lxde disk raw armhfp
Soas live i386
Server disk raw armhfp
Security live i386
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
-- 
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: no influxdb for fedora 22, but there is for 21 and 23

[Muayyad AlSadi]

> Just curious, what are you using the package for?

I was just exploring. and found that it's strange that f21 but not f22 and
asked to see if this was intentional or a slip.




On Sun, Nov 1, 2015 at 6:42 PM, Jan Chaloupka  wrote:

> Hi Muayyad,
>
> i have requested to push the build into f22 stable. Still, there is no
> influxdb subpackage with binaries. Just curious, what are you using the
> package for?
>
> Regards
> Jan
>
>
> On 10/31/2015 05:19 PM, Muayyad AlSadi wrote:
>
> but there is an old "stable" one for fedora 21?!
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2015-0299
>
> how can this happen? did I miss something or it's normal?
>
>
> On Sat, Oct 31, 2015 at 5:14 PM, Tomasz Torcz 
> wrote:
>
>> On Sat, Oct 31, 2015 at 04:58:31PM +0200, Muayyad AlSadi wrote:
>> > Hi,
>> >
>> > it seems that influxdb is missing in fedora 22
>> >
>> >
>> https://bodhi.fedoraproject.org/updates/?packages=golang-github-influxdb-influxdb
>> >
>> > [root@laptop ~]# cat /etc/system-release
>> > Fedora release 22 (Twenty Two)
>> >
>> > [root@laptop ~]# dnf -C info golang-github-influxdb-influxdb
>> > Last metadata expiration check performed 2:59:31 ago on Sat Oct 31
>> 13:57:20
>> > 2015.
>> > Error: No matching Packages to list
>>
>>   It stil being tested:
>> https://bodhi.fedoraproject.org/updates/FEDORA-2015-14091
>>
>>   You can help by instaling it from updates-testing, checking if it works
>> and providing positive comment on Bodhi page.
>>
>>
>> --
>> Tomasz Torcz   72->|
>>  80->|
>> xmpp: zdzich...@chrome.pl
>> 72->|   80->|
>>
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/devel
>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
>
>
>
>
> --
> Jan Chaloupka
> --
> * Software Engineer  *
> * Server Experience  *
> * Red Hat Czech, s. r. o.*
> * UTC+1 (CET), jchaloup  *
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Michael Catanzaro]

On Sun, 2015-11-01 at 20:03 +0100, Kevin Kofler wrote:
> Peter Robinson wrote:
> > The problem is we have to freeze sometime to ensure stability in
> > the
> > installer platform, the live and other images which are static. If
> > not
> > it's too much of a moving target to try and QA and ensure
> > everything
> > works as expected. To freeze is a fairly standard procedure for all
> > distro development.
> 
> IMHO, we should have at most 1 week of strict freeze. If we decide
> that we 
> have to slip anyway, then we should pull in ALL updates pending
> stable and 
> restart the release process (freeze, spin RCs, test) from there.
> 
> (That would also make it less painful to slip multiple times and thus
> decrease the pressure to rush out quick hacks to work around blockers
> instead of clean fixes.)

I think Kevin is closer to right on this. It's unreasonable to have 500
updates queued for users on release day. Yeah, freeze is required to do
QA on the release, but QA on the release is not worth so much if it all
goes out the door the first time someone clicks update. (Well, it's
essential for the installation process, but beyond that)

I will say: Fedora has the *best* release QA *by far* of any comparable 
community distro -- maybe even better than Debian! -- but we all know our 
updates break things all the time. In F22, we had at least two (I think 
actually three, but I lost count) separate updates that broke the ability to 
apply further (PackageKit) updates. Come on! We have to fix this for OEMs to 
have any confidence in shipping Fedora. (At least, I'd like to see Fedora in 
stores, and I think I'm not the only one)

My recommendation is the opposite of what Kevin would say, though. I'd like to 
see a third party responsible for giving final approval on all updates, charged 
with reducing the size of the updates pipe dramatically. Maintainers should not 
have final say on updates except in the event of a serious regression (in which 
case we need a revert button to skip updates-testing).

An alternative we've been throwing around in the Workstation group is service 
packs (or "update packs") -- all non-security updates get bundled together, 
QAed, and released every 4-8 weeks. If you want to get your update out faster 
than that, you need a CVE or a special exception.

> I also think that the decision:
> * when an image is a Go,
> * what issues to consider as blockers and
> * what new builds to take as freeze overrides
> ought to be made by the WG/SIG responsible for the individual
> deliverable. 
> (And this is NOT a personal power grab attempt. I am no longer a
> voting 
> member of the KDE SIG, for reasons detailed on the kde mailing list.)
> The 
> current process where the SIG/WG has to argue for every single freeze
> override they want to take in, and have rel-eng/QA reject some of
> them, is 
> just broken (and there I can speak from experience, with my 8 years
> of KDE 
> SIG involvement).

Then we need to have separate release cycles for each product, since I
don't want Workstation blocked indefinitely on everything
Cloud/Server/KDE want to fix, and presumably those groups don't want to
block on us... it's frankly annoying to me that we risk blocking
Workstation on such issues, but it's a compromise we need to make to
ensure the other releases are good. (And that vice-versa when the other
releases get blocked on Workstation issues.) As long as we have four
separate releases on the same cycle, it makes sense that QA gets final
say.

Besides, they're the ones testing the thing.

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

Re: Fedora 23 Final RC10 status is GO !

[Michael Catanzaro]

On Sun, 2015-11-01 at 17:53 +, Peter Robinson wrote:
> The problem is we have to freeze sometime to ensure stability in the
> installer platform, the live and other images which are static. If
> not
> it's too much of a moving target to try and QA and ensure everything
> works as expected. To freeze is a fairly standard procedure for all
> distro development.

Yeah, but most distros stay frozen... to unfreeze after release -- let
alone with 500 updates on day zero! -- is something uniquely Fedora.

Really, only my updates should be allowed out to users. All of yours
should have to wait for the next release. Obviously not a serious
statement, but we all think our own updates are important, whereas
collectively it is important to Fedora to reduce the quantity of
updates. That implies individual maintainers shouldn't have final say
on updates

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

Re: Fedora 23 Final RC10 status is GO !

[Reindl Harald]

Am 01.11.2015 um 23:20 schrieb Michael Catanzaro:

On Sun, 2015-11-01 at 17:53 +, Peter Robinson wrote:

The problem is we have to freeze sometime to ensure stability in the
installer platform, the live and other images which are static. If
not
it's too much of a moving target to try and QA and ensure everything
works as expected. To freeze is a fairly standard procedure for all
distro development.


Yeah, but most distros stay frozen... to unfreeze after release -- let
alone with 500 updates on day zero! -- is something uniquely Fedora.

Really, only my updates should be allowed out to users. All of yours
should have to wait for the next release. Obviously not a serious
statement, but we all think our own updates are important, whereas
collectively it is important to Fedora to reduce the quantity of
updates. That implies individual maintainers shouldn't have final say
on updates


nonsense

if individual should not have final say on updates one could use also 
Debian and *not* Fedora - the is no perfect reason because issues are 
different


refrain from updates may keep annoying bugs currently in Fedora fixed 
soon and updates *may* introduce new bugs


*who* if not the package maintainer which hopefully uses his own 
packages should have the final say? some group of people not 
understanding the issues really?




signature.asc
Description: OpenPGP digital 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

Updates (was Fedora 23 Final RC10 status is GO !)

[Michael Catanzaro]

To be clear, my email proposed two orthogonal solutions -- service
packs, and an oversight body to approve updates -- and here Reindl is
objecting to the later. We could do one or the other, or both, or
neither.

On Sun, 2015-11-01 at 23:31 +0100, Reindl Harald wrote:
> refrain from updates may keep annoying bugs currently in Fedora fixed
> soon and updates *may* introduce new bugs

Yeah, that's the clear disadvantage. The service pack approach
sidesteps that problem: everything still goes out, just not so soon, so
everything spends plenty of time in testing. All the bugs still get
fixed, just not as fast.

(This also solves the problem of maintainers releasing individually
-good updates too frequently.)

> *who* if not the package maintainer which hopefully uses his own 
> packages should have the final say? some group of people not 
> understanding the issues really?

The counterargument is that we keep seeing major version updates that
violate our existing updates policy. Who if not a neutral party charged
with upholding that policy should have the final say? Some maintainers
who clearly haven't read it?

If we have another party approving updates, then it's the maintainer's
job to write an argument in favor of releasing the update: a quick
summary of what the fix is and the regression potential. If the update
gets rejected, the maintainer might really be wrong! and if not would
have to try again to explain better. I think this would be good
regardless of whether or not we do updates packs.

Michael
-- 
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: Updates (was Fedora 23 Final RC10 status is GO !)

[Reindl Harald]

Am 02.11.2015 um 00:36 schrieb Michael Catanzaro:

*who* if not the package maintainer which hopefully uses his own
packages should have the final say? some group of people not
understanding the issues really?


The counterargument is that we keep seeing major version updates that
violate our existing updates policy. Who if not a neutral party charged
with upholding that policy should have the final say? Some maintainers
who clearly haven't read it?


and what about software not breaking randomly?

a version number don't say *anything* about the impact of a update - 
there are stol developers out there which are able to provide new 
feautures without breaking everything left and right


show me as example *one* postfix major update in the last 10 years 
breaking existing setups - not every upstream acts like GNOME




signature.asc
Description: OpenPGP digital 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: Fedora 23 Final RC10 status is GO !

[Sérgio Basto]

On Dom, 2015-11-01 at 17:53 +, Peter Robinson wrote:
> On Sun, Nov 1, 2015 at 5:06 PM, Sérgio Basto  wrote:
> > On Sex, 2015-10-30 at 17:47 +0100, Jan Kurik wrote:
> >> At the third round of Fedora 23 Final Go/No-Go Meeting, that just
> >> ends, has been Fedora 23 Final-RC10 declared as GOLD.
> >> GA of this release is planed on Tuesday 2015-Nov-03.
> >>
> > Today we got 531 updates for F23 , IMO, you should include it on Fedora
> > 23 Final before GA , doesn't make sense (to me) after download an ISO
> > have 1/2 Giga of updates, but this happens since RedHad 9 at least .
> > IMO, testing team should respin ISO with updates and testing again .
> > I have some difficulty in following all development, fortunately Fedora
> > is always at great speed, but it is not easy to follow. And do more
> > tests we not lose anything, IMHO.
> 
> The problem is we have to freeze sometime to ensure stability in the
> installer platform, the live and other images which are static. If not
> it's too much of a moving target to try and QA and ensure everything
> works as expected. To freeze is a fairly standard procedure for all
> distro development.

Make an respin for F23 with stable updates, IMHO, should not break
anything, because at this stage, just stable things are being pushed. So
it should be just one more loop in testing phase, anyway if breaks
something test team can freeze process again, until provide a  fix.
This is not new !, respins of fedoraunity was an example and we already
have living respins [1], so we just need do new respin officially!.
Shouldn't be a big deal, If I'm not mistaken.



[1] http://alt.fedoraproject.org/pub/alt/live-respins/

> Peter

-- 
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: [HEADS UP] Upcoming soname change for libtirpc

[Ian Kent]

On Sun, 2015-11-01 at 18:48 +0100, Kalev Lember wrote:
> On 10/30/2015 05:36 PM, Kevin Fenzi wrote:
> > On Fri, 30 Oct 2015 11:50:48 -0400
> > Steve Dickson  wrote:
> > > 2) find and rebuild all the dependencies?
> > 
> > Should be something like: 
> > 
> > % sudo dnf repoquery --whatrequires 'libtirpc.so.1()(64bit)'
> > Last metadata expiration check performed 0:01:17 ago on Fri Oct 30
> > 10:34:06 2015.
> > autofs-1:5.1.1-3.fc23.x86_64
> > fedfs-utils-admin-0:0.10.3-4.fc23.x86_64
> > fedfs-utils-server-0:0.10.3-4.fc23.x86_64
> > libtirpc-devel-0:0.3.2-3.0.fc24.x86_64
> > nfs-utils-1:1.3.2-10.fc23.x86_64
> > rpcbind-0:0.2.3-0.2.fc23.x86_64
> 
> Now that the libtirpc update is in, I tried to kick off rebuilds for
> these to make them them installable again in rawhide (they are
> breaking
> nightly image composes). Didn't get very far with this though because
> rpcbind and fedfs-utils are failing to build and are blocking others:
> 
> rpcbind (http://koji.fedoraproject.org/koji/buildinfo?buildID=695404)
> failed with:
> 
> src/rpcb_svc_com.c: In function 'handle_reply':
> src/rpcb_svc_com.c:1277:6: error: 'SVCXPRT {aka struct
> __rpc_svcxprt}' has no member named 'xp_auth'
>   xprt->xp_auth = &svc_auth_none;
> 
> and fedfs-utils (
> http://koji.fedoraproject.org/koji/buildinfo?buildID=695402) failed
> the same way:
> 
> gss.c: In function 'fedfsd_get_gss_cred':
> gss.c:178:23: error: 'SVCXPRT {aka struct __rpc_svcxprt}' has no
> member named 'xp_auth'
>   auth = rqstp->rq_xprt->xp_auth;

Steve is aware of this, or will be soon, as it was raised on the
upstream libtirpc mailing list.

So we need to wait until rpcbind is updated before we can go further
with this.

I had a look at the libtirpc code and the autofs library pre-open might
still be needed. I didn't yet look far enough to see if there's a
library unload destructor, which may be all that's needed, to resolve
this. So I need to get around looking further before posting to the
upstream list.

In the mean time I have committed a change to autofs to also pre-open
the new library.

> 
> -- 
> 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: [HEADS UP] Upcoming soname change for libtirpc

[Ian Kent]

On Mon, 2015-11-02 at 11:02 +0800, Ian Kent wrote:
> On Sun, 2015-11-01 at 18:48 +0100, Kalev Lember wrote:
> > On 10/30/2015 05:36 PM, Kevin Fenzi wrote:
> > > On Fri, 30 Oct 2015 11:50:48 -0400
> > > Steve Dickson  wrote:
> > > > 2) find and rebuild all the dependencies?
> > > 
> > > Should be something like: 
> > > 
> > > % sudo dnf repoquery --whatrequires 'libtirpc.so.1()(64bit)'
> > > Last metadata expiration check performed 0:01:17 ago on Fri Oct
> > > 30
> > > 10:34:06 2015.
> > > autofs-1:5.1.1-3.fc23.x86_64
> > > fedfs-utils-admin-0:0.10.3-4.fc23.x86_64
> > > fedfs-utils-server-0:0.10.3-4.fc23.x86_64
> > > libtirpc-devel-0:0.3.2-3.0.fc24.x86_64
> > > nfs-utils-1:1.3.2-10.fc23.x86_64
> > > rpcbind-0:0.2.3-0.2.fc23.x86_64
> > 
> > Now that the libtirpc update is in, I tried to kick off rebuilds
> > for
> > these to make them them installable again in rawhide (they are
> > breaking
> > nightly image composes). Didn't get very far with this though
> > because
> > rpcbind and fedfs-utils are failing to build and are blocking
> > others:
> > 
> > rpcbind (
> > http://koji.fedoraproject.org/koji/buildinfo?buildID=695404)
> > failed with:
> > 
> > src/rpcb_svc_com.c: In function 'handle_reply':
> > src/rpcb_svc_com.c:1277:6: error: 'SVCXPRT {aka struct
> > __rpc_svcxprt}' has no member named 'xp_auth'
> >   xprt->xp_auth = &svc_auth_none;
> > 
> > and fedfs-utils (
> > http://koji.fedoraproject.org/koji/buildinfo?buildID=695402) failed
> > the same way:
> > 
> > gss.c: In function 'fedfsd_get_gss_cred':
> > gss.c:178:23: error: 'SVCXPRT {aka struct __rpc_svcxprt}' has no
> > member named 'xp_auth'
> >   auth = rqstp->rq_xprt->xp_auth;
> 
> Steve is aware of this, or will be soon, as it was raised on the
> upstream libtirpc mailing list.
> 
> So we need to wait until rpcbind is updated before we can go further
> with this.
> 
> I had a look at the libtirpc code and the autofs library pre-open
> might
> still be needed. I didn't yet look far enough to see if there's a
> library unload destructor, which may be all that's needed, to resolve
> this. So I need to get around looking further before posting to the
> upstream list.
> 
> In the mean time I have committed a change to autofs to also pre-open
> the new library.

btw, Chuck Lever (fedfs-utils) was also part of that discussion but he
may not have yet realized fedfs-utils is affected too.

Once the change to be made is decided we should be able to fix these
pretty quickly.

I can commit changes to fedfs-utils if Chuck doesn't have time.

> 
> > 
> > -- 
> > 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: Fedora 23 Final RC10 status is GO !

[Peter Gordon]

On 11/01/2015 09:06 AM, Sérgio Basto wrote:
> Today we got 531 updates for F23 , IMO, you should include it on Fedora
> 23 Final before GA , doesn't make sense (to me) after download an ISO
> have 1/2 Giga of updates, but this happens since RedHad 9 at least . 
> IMO, testing team should respin ISO with updates and testing again . 
> I have some difficulty in following all development, fortunately Fedora
> is always at great speed, but it is not easy to follow. And do more
> tests we not lose anything, IMHO.

Ideally, once the release is GA, deltarpms should mitigate most of the
download cost. Alternatively, you can use the netinstall ISO image
instead (usually about 450 MB or so), and then the newest versions of
packages in the repositories will be download on-demand during install
time. (You can also achieve this by adding the updates repository during
install time on a regular installer image.)

While recreating the installer with more updates may seem like a good
idea , unfortunately it requires more server resources and more
man-hours during which we'd have to freeze with that set of updates. I
feel that if we did that, by the time the testing for that respin is
complete, that new release will itself have a huge number of pending
updates and it could create a cycle of respin-test-respin-test-etc. that
would detract our already-limited community resources from advancing
toward the next release.

Regards.
-- 
Peter Gordon (codergeek42) 
Who am I? :: http://thecodergeek.com/about-me



signature.asc
Description: OpenPGP digital 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] 2015-11-02 @ ** 16:00 ** UTC - Fedora QA Meeting

[Adam Williamson]

# Fedora Quality Assurance Meeting
# Date: 2015-11-02
# Time: ** 16:00 ** UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

It's QA meeting time again! We've finished up Fedora 23 - big thanks to
everyone for all your work - so it's time to check in on any final
tasks there, and look back at how the cycle went.

Note that the clocks changed in North America this weekend, so the
meeting time in UTC is also changed. If your clocks changed this
weekend, the meeting will be at the same local time as always, for you.
If your clocks did not change, it'll be an hour later.

== Proposed Agenda Topics ==

1. Previous meeting follow-up
2. Fedora 23 status and final tasks
3. Fedora 23 retrospective
4. Open floor
-- 
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