Re: To distro-sync or not distro-sync?

[Miroslav Suchý]

Dne 26.10.2015 v 18:39 Zbigniew Jędrzejewski-Szmek napsal(a):
> --distro-sync is now (in git, I don't think this version was released yet)
> the default in dnf-plugin-system-upgrade.

OK. So I will file BZs for all issues I find with --distro-sync I hit.

>> # dnf system-upgrade download --releasever=23 --distro-sync --best 
>> --allowerasing
>> Error: package rubygem-celluloid-0.15.2-2.fc22.noarch requires 
>> rubygem(timers) < 1.2, but none of the providers can be
>> installed.
>> package fedup-dracut-0.9.2-1.fc22.x86_64 requires librpm.so.3()(64bit), but 
>> none of the providers can be installed
> 
> What version of dnf/libsolv are you using? The last update
> (libsolv-0.6.14-2.fc22,dnf-1.1.3-1.fc22) solved a bunch of
> upgrade problems.

Exactly dnf-1.1.3-1.fc22


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

Re: To distro-sync or not distro-sync?

[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

-- 

Yours sincerely,
Christopher Meng

http://awk.io
-- 
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: PSA: heads-up replacing mod_auth_kerb with mod_auth_gssapi

[Joe Orton]

On Fri, Oct 23, 2015 at 05:39:05PM -0400, Simo Sorce wrote:
> Hello fellow Fedora developers,
> I have relatively recently completed a project to replace the ancient and
> aging and unmaintained mod_auth_kerb Apache module with a new, slimmer, more
> modern and maintained module called mod_auth_gssapi[1].
> 
> The plan is to retire mod_auth_kerb soon and get it out of the distribution.
> So this is a heads up that if you have a project that somehow relies on
> mod_auth_kerb it would be nice if you could migrate it to mod_auth_gssapi
> instead, and if you have any issue doing so (missing features,
> incompatibilities, anything) that you let us know so we can address whatever
> problem you may find and accelerate the demise of mod_auth_kerb.

Great, thanks Simo.  I'm not sure if we need a Feature for this, but I'm 
happy to drop mod_auth_kerb in f24+.

I see deps from ipsilon-authkrb and koji-web FWIW.

Regards, Joe

-- 
Joe Orton // Red Hat // Web Stack Team // webstack-t...@redhat.com // @notroj
-- 
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?

[Reindl Harald]

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




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: DNF 1.1.3 and DNF-PLUGINS-CORE 0.1.13 Released + bonus

[Honza Šilhan]

> From: "Matthew Miller" 
> 
> On Tue, Oct 27, 2015 at 05:23:13AM -0400, Honza Šilhan wrote:
> > Hi, integration of Hawkey libraries and library which uses PK has
> > already started. Sharing the history db within core library written
> > in C used by DNF, PK and Gnome Software is part of long term plan.
> 
> Cool, and that should basically solve this, at least for the case of GNOME
> Software and DNF used in combination, right?

Yes, the packages installed by PK would not be autoremoved then but the
PK transaction would still not show up in "dnf history".

Honza
-- 
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-23 Branched report: 20151029 changes

[Fedora Branched Report]

Compose started at Thu Oct 29 07:15:03 UTC 2015










Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 0
Size of added packages: 0 (0 )
Size change of modified packages: 0 (0 )
Size of removed packages: 0 (0 )
Size change: 0 (0 )
Compose finished at Thu Oct 29 11:20:16 UTC 2015

-- 
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: BuildRequires: pythonN-devel unnecessary

[Dominik 'Rathann' Mierzejewski]

On Thursday, 29 October 2015 at 01:31, Christopher Meng wrote:
> On Thu, Oct 29, 2015 at 3:16 AM, Tom Hughes  wrote:
> >
> > On 28/10/15 19:12, Mike Bonnet wrote:
> >>
> >> https://fedoraproject.org/wiki/Packaging:Python#BuildRequires
> >>
> >> This is *not* required for pure Python packages, only for packages
> >> compiling native extensions:
> >
> >
> > Are you sure? Don't you need them for the RPM macros they contain?
> 
> Not my first time hitting on missing macros just because lack of
> pythonN-devel, but if you just extract them from pythonN-devel to package
> similar to these packages below, I reckon that it should be acceptable:
> 
> ---
> ghc-srpm-macros
> gnat-srpm-macros
> go-srpm-macros
> ocaml-srpm-macros
> perl-srpm-macros
> ---

How about naming them:
rpm-build-ghc
rpm-build-gnat
rpm-build-go
rpm-build-ocaml
rpm-build-perl
rpm-build-python
and so on?

Also, add
Supplements: rpm-build
to each of them.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
-- 
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: BuildRequires: pythonN-devel unnecessary

[Tom Hughes]

On 29/10/15 11:34, Dominik 'Rathann' Mierzejewski wrote:

On Thursday, 29 October 2015 at 01:31, Christopher Meng wrote:


Not my first time hitting on missing macros just because lack of
pythonN-devel, but if you just extract them from pythonN-devel to package
similar to these packages below, I reckon that it should be acceptable:

---
ghc-srpm-macros
gnat-srpm-macros
go-srpm-macros
ocaml-srpm-macros
perl-srpm-macros
---


How about naming them:
rpm-build-ghc
rpm-build-gnat
rpm-build-go
rpm-build-ocaml
rpm-build-perl
rpm-build-python
and so on?

Also, add
Supplements: rpm-build
to each of them.


Just to add extra confusion there is nodejs-packaging as well which is 
the equivalent package for nodejs...


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
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: apitrace-libs.i686 missing in x86_64 repos

[Sandro Mani]

On 25.09.2015 23:46, Sandro Mani wrote:



On 25.09.2015 22:44, Michael Schwendt wrote:

On Fri, 25 Sep 2015 19:40:16 +0200, Sandro Mani wrote:

Well, then adding the i686 build to the mash x86_64 multilib compose 
whitelist

cannot be avoided -- as it's needed to really fix #1068620.

Okay thanks - https://pagure.io/mash/issue/4.
Been a couple of weeks, is pagure being actively used for tracking mash 
requests?


Thanks
Sandro

--
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: System V to systemd unit migration

[Zbigniew Jędrzejewski-Szmek]

On Wed, Oct 28, 2015 at 10:39:53PM +0100, Reindl Harald wrote:
> 
> 
> Am 28.10.2015 um 22:27 schrieb Tom Hughes:
> >On 28/10/15 19:47, Adam Jackson wrote:
> >
> >>As a quick audit (based on 'grep _initrddir' and 'grep _initddir' over
> >>a fairly recent checkout of the spec files in pkg git, and then some
> >>manual inspection) I think the following packages will be affected:
> >
> >...and initscripts for network and netconsole ;-)
> 
> if network.service (/etc/rc.d/init.d/network) goes away i consider
> after 20 releases so far plan a migration to whatever distribution
> or even operating system because it would be the same pain than
> migrate all the customized stuff inside Fedora
IMHO /etc/init.d/network is a good candidate for an exception...
The alternatives aren't there yet for various reasons.

There's always the possibility of repackaging it to be a script
called from a systemd unit, instead of using the sysv compat interface.
But it's just a big script anyway, and changing how it is called
seems to be work without much gain.

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: To distro-sync or not distro-sync?

[Honza Šilhan]

> From: "Miroslav Suchý" 
> 
> >> # dnf system-upgrade download --releasever=23 --distro-sync --best
> >> --allowerasing
> >> Error: package rubygem-celluloid-0.15.2-2.fc22.noarch requires
> >> rubygem(timers) < 1.2, but none of the providers can be
> >> installed.
> >> package fedup-dracut-0.9.2-1.fc22.x86_64 requires librpm.so.3()(64bit),
> >> but none of the providers can be installed
> > 
> > What version of dnf/libsolv are you using? The last update
> > (libsolv-0.6.14-2.fc22,dnf-1.1.3-1.fc22) solved a bunch of
> > upgrade problems.
> 
> Exactly dnf-1.1.3-1.fc22

The distro-sync changes happened in libsolv-0.6.14-2 - it should be a 
requirement of 
dnf-plugin-system-upgrade-0.7.0.

You can exclude the conflicting packages to proceed the system-upgrade i.e.:
"dnf system-upgrade download --releasever=23 --distro-sync -x rubygem-celluloid 
--allowerasing"

> From: "Reindl Harald" 
> To: devel@lists.fedoraproject.org
> Sent: Thursday, October 29, 2015 10:56:47 AM
> Subject: Re: To distro-sync or not distro-sync?
> 
> From: "Reindl Harald" 
> 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"

dnf has `--allowerasing switch - it will resolve the conflicts by uninstallation
of conflicting packages. Installing the packages regardless the dependencies by
`--force` is really dangerous and will not be supported by DNF.

> currently we have some sort of blackbox with no output how to solve
> dependency problems

It outputs the last package conflict found by depsolver. The improvement is on
the agenda [1].


Honza

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1148627
-- 
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?

[Reindl Harald]

Am 29.10.2015 um 13:24 schrieb Honza Šilhan:

From: "Miroslav Suchý" 
From: "Reindl Harald" 
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"


dnf has `--allowerasing switch - it will resolve the conflicts by uninstallation
of conflicting packages. Installing the packages regardless the dependencies by
`--force` is really dangerous and will not be supported by DNF.


removing random packages is also really dangerous and *not* acceptable

frankly if there are problems and i need a hammer then i need a hammer 
in case i know what i am doing - i have solved yum distrupgrade troubles 
hundrets of times by "rpm -e --nodeps" for packages where i am 100% sure 
that they are not system critical and guess what - after that the deps 
where solved and even the correct dependencies installed without any 
cleanup needed after the upgrade



currently we have some sort of blackbox with no output how to solve
dependency problems


It outputs the last package conflict found by depsolver. The improvement is on
the agenda [1].

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


hopefully because 
https://bugzilla.redhat.com/show_bug.cgi?id=1148627#c27 is the truth 
until now




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: To distro-sync or not distro-sync?

[Sérgio Basto]

On Qui, 2015-10-29 at 17:09 +0800, Christopher Meng wrote:
> You have a chance to get your rpmfusion softwares wiped after the sync.
> 
> [1]---https://bugzilla.redhat.com/show_bug.cgi?id=1263677

yep, so not distro-sync


-- 
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: To distro-sync or not distro-sync?

[Reindl Harald]

Am 29.10.2015 um 13:37 schrieb Sérgio Basto:

On Qui, 2015-10-29 at 17:09 +0800, Christopher Meng wrote:

You have a chance to get your rpmfusion softwares wiped after the sync.

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


yep, so not distro-sync


nonsense when i read the bugreport

* system-upgrade now uses dnf (standard "dnf update" approach)

THAT is the problem and i really wonder what somebody thinks by 
implement it that way after *many years* of "yum --releasever=XX 
distro-sync" works absolutely relieable


* change "dnf update" mode during system upgrade to
  "dnf distro-sync --allowerasing"

THAT is the right direction but nonsense because --allowerasing is a 
terrible idea, anyways "dnf --releasever=XX distro-sync" is not affected 
by both wrong solutions as far as i see (expect DNF is intentionally or 
unintenioally broken elsewhere there)




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

rawhide report: 20151029 changes

[Fedora Rawhide Report]

Compose started at Thu Oct 29 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
[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
[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/pkg)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/coreos/fleet/machine)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/coreos/fleet/etcd)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/coreos/fleet/client)
[golang-github-prometheus-prometheus]
golang-github-prometheus-prometheus-devel-0.15.0-1.fc24.noarch requires 
golang(gopkg.in/fsnotify.v1)
[js-of-ocaml]
js-of-ocaml-2.4-8.fc23.i686 requires ocaml(runtime) = 0:4.02.2
js-of-o

Re: PSA: heads-up replacing mod_auth_kerb with mod_auth_gssapi

[Simo Sorce]

On 29/10/15 05:31, Joe Orton wrote:

On Fri, Oct 23, 2015 at 05:39:05PM -0400, Simo Sorce wrote:

Hello fellow Fedora developers,
I have relatively recently completed a project to replace the ancient and
aging and unmaintained mod_auth_kerb Apache module with a new, slimmer, more
modern and maintained module called mod_auth_gssapi[1].

The plan is to retire mod_auth_kerb soon and get it out of the distribution.
So this is a heads up that if you have a project that somehow relies on
mod_auth_kerb it would be nice if you could migrate it to mod_auth_gssapi
instead, and if you have any issue doing so (missing features,
incompatibilities, anything) that you let us know so we can address whatever
problem you may find and accelerate the demise of mod_auth_kerb.


Great, thanks Simo.  I'm not sure if we need a Feature for this, but I'm
happy to drop mod_auth_kerb in f24+.

I see deps from ipsilon-authkrb and koji-web FWIW.


Thanks Joe,
Ipsilon is going to use mod_auth_gssapi, who should I talk to move 
koji-web to mod_auth_gssapi ?


Simo.

--
Simo Sorce * Red Hat, Inc * New York
--
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?

[Zbigniew Jędrzejewski-Szmek]

On Thu, Oct 29, 2015 at 01:33:45PM +0100, Reindl Harald wrote:
> 
> Am 29.10.2015 um 13:24 schrieb Honza Šilhan:
> >>From: "Miroslav Suchý" 
> >>From: "Reindl Harald" 
> >>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"
> >
> >dnf has `--allowerasing switch - it will resolve the conflicts by 
> >uninstallation
> >of conflicting packages. Installing the packages regardless the dependencies 
> >by
> >`--force` is really dangerous and will not be supported by DNF.
> 
> removing random packages is also really dangerous and *not* acceptable
> 
> frankly if there are problems and i need a hammer then i need a
> hammer in case i know what i am doing - i have solved yum
> distrupgrade troubles hundrets of times by "rpm -e --nodeps" for
> packages where i am 100% sure that they are not system critical and
> guess what - after that the deps where solved and even the correct
> dependencies installed without any cleanup needed after the upgrade

It asks for confirmation. The list of packages to remove is the last
thing before the prompt... Those prompts could be made more visible,
and/or we could make it easier to retrieve the list of removed packages
after the installation is done, but that's about it.

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: To distro-sync or not distro-sync?

[Sérgio Basto]

On Qui, 2015-10-29 at 13:44 +0100, Reindl Harald wrote:
> 
> Am 29.10.2015 um 13:37 schrieb Sérgio Basto:
> > On Qui, 2015-10-29 at 17:09 +0800, Christopher Meng wrote:
> >> You have a chance to get your rpmfusion softwares wiped after the sync.
> >>
> >> [1]---https://bugzilla.redhat.com/show_bug.cgi?id=1263677
> >
> > yep, so not distro-sync
> 
> nonsense when i read the bugreport
> 
> * system-upgrade now uses dnf (standard "dnf update" approach)
> 
> THAT is the problem and i really wonder what somebody thinks by 
> implement it that way after *many years* of "yum --releasever=XX 
> distro-sync" works absolutely relieable
> 
> * change "dnf update" mode during system upgrade to
>"dnf distro-sync --allowerasing"
> 
> THAT is the right direction but nonsense because --allowerasing is a 
> terrible idea, anyways "dnf --releasever=XX distro-sync" is not affected 
> by both wrong solutions as far as i see (expect DNF is intentionally or 
> unintenioally broken elsewhere there)

You need --allowerasing for updates which obsolete other packages, if
not you can't update.  
distro-sync can downgrading packages which in upgrading is not the best
place . You can do it after upgrade the system . 
dnf update --allowerasing  is what I want /need .

-- 
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: To distro-sync or not distro-sync?

[Reindl Harald]

Am 29.10.2015 um 14:11 schrieb Sérgio Basto:

On Qui, 2015-10-29 at 13:44 +0100, Reindl Harald wrote:


Am 29.10.2015 um 13:37 schrieb Sérgio Basto:

On Qui, 2015-10-29 at 17:09 +0800, Christopher Meng wrote:

You have a chance to get your rpmfusion softwares wiped after the sync.

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


yep, so not distro-sync


nonsense when i read the bugreport

* system-upgrade now uses dnf (standard "dnf update" approach)

THAT is the problem and i really wonder what somebody thinks by
implement it that way after *many years* of "yum --releasever=XX
distro-sync" works absolutely relieable

* change "dnf update" mode during system upgrade to
"dnf distro-sync --allowerasing"

THAT is the right direction but nonsense because --allowerasing is a
terrible idea, anyways "dnf --releasever=XX distro-sync" is not affected
by both wrong solutions as far as i see (expect DNF is intentionally or
unintenioally broken elsewhere there)


You need --allowerasing for updates which obsolete other packages, if
not you can't update


what??

that would be another regression compared to yum


distro-sync can downgrading packages which in upgrading is not the best
place . You can do it after upgrade the system .
dnf update --allowerasing  is what I want /need


the whole purpose of distro-sync is that it can downgrade - as exmaple 
you may have stuff from updates-testing installed and updates-testing 
not enabled due distro-sync and so the versions in the newer release can 
be lower


the only right thing to do in that case is downgrade them, also for 
packages where maintainers just forgot to rebuild for the next release 
which happened often enough in the past




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: To distro-sync or not distro-sync?

[Zbigniew Jędrzejewski-Szmek]

On Thu, Oct 29, 2015 at 01:44:34PM +0100, Reindl Harald wrote:
> 
> 
> Am 29.10.2015 um 13:37 schrieb Sérgio Basto:
> >On Qui, 2015-10-29 at 17:09 +0800, Christopher Meng wrote:
> >>You have a chance to get your rpmfusion softwares wiped after the sync.
> >>
> >>[1]---https://bugzilla.redhat.com/show_bug.cgi?id=1263677
> >
> >yep, so not distro-sync
> 
> nonsense when i read the bugreport
> 
> * system-upgrade now uses dnf (standard "dnf update" approach)
> 
> THAT is the problem and i really wonder what somebody thinks by
> implement it that way after *many years* of "yum --releasever=XX
> distro-sync" works absolutely relieable
> 
> * change "dnf update" mode during system upgrade to
>   "dnf distro-sync --allowerasing"
> 
> THAT is the right direction but nonsense because --allowerasing is a
> terrible idea, anyways "dnf --releasever=XX distro-sync" is not
> affected by both wrong solutions as far as i see (expect DNF is
> intentionally or unintenioally broken elsewhere there)

There are three options:
(1, no distro-sync) — upgrade only packages which can be upgraded
  without conflicts. Leaves a partially upgraded system in some cases.
(2, distro-sync) — upgrade packages which can be upgraded, remove
  conflicting ones. Lose some packages during upgrade.
(3, force) — upgrade all packages ignoring conflicts. Leaves the
  system with some programs broken.

You seem to dislike all the options, but I don't see anything else
possible. Do you have some better proposal?

(Note that the user is always asked for confirmation before proceeding,
so she can always stop to remove/update packages by hand in all three
cases.)

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: To distro-sync or not distro-sync?

[Reindl Harald]

Am 29.10.2015 um 14:18 schrieb Zbigniew Jędrzejewski-Szmek:

On Thu, Oct 29, 2015 at 01:44:34PM +0100, Reindl Harald wrote:



Am 29.10.2015 um 13:37 schrieb Sérgio Basto:

On Qui, 2015-10-29 at 17:09 +0800, Christopher Meng wrote:

You have a chance to get your rpmfusion softwares wiped after the sync.

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


yep, so not distro-sync


nonsense when i read the bugreport

* system-upgrade now uses dnf (standard "dnf update" approach)

THAT is the problem and i really wonder what somebody thinks by
implement it that way after *many years* of "yum --releasever=XX
distro-sync" works absolutely relieable

* change "dnf update" mode during system upgrade to
   "dnf distro-sync --allowerasing"

THAT is the right direction but nonsense because --allowerasing is a
terrible idea, anyways "dnf --releasever=XX distro-sync" is not
affected by both wrong solutions as far as i see (expect DNF is
intentionally or unintenioally broken elsewhere there)


There are three options:
(1, no distro-sync) — upgrade only packages which can be upgraded
   without conflicts. Leaves a partially upgraded system in some cases.
(2, distro-sync) — upgrade packages which can be upgraded, remove
   conflicting ones. Lose some packages during upgrade.
(3, force) — upgrade all packages ignoring conflicts. Leaves the
   system with some programs broken.

You seem to dislike all the options, but I don't see anything else
possible. Do you have some better proposal?


just behave like "yum --releasever=XX distro-sync" all the years before 
and just REFUSE to upgrade if there are conflicts because anything else 
is undefined behavior


DNF just needs to give enough information how to solve the dependency 
problems




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: To distro-sync or not distro-sync?

[Vít Ondruch]

Dne 29.10.2015 v 13:24 Honza Šilhan napsal(a):
> You can exclude the conflicting packages to proceed the system-upgrade i.e.:
> "dnf system-upgrade download --releasever=23 --distro-sync -x 
> rubygem-celluloid --allowerasing"


Does the "-x" work actually? Last time I tried, the package I excluded
was not downloaded (as expected), but after restart, the "-x" was not
used and my system-upgrade failed (this was unexpected). These flags
should be propagated and honored after restart, during the upgrade phase.


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

Re: To distro-sync or not distro-sync?

[Zbigniew Jędrzejewski-Szmek]

On Thu, Oct 29, 2015 at 02:20:50PM +0100, Reindl Harald wrote:
> 
> 
> Am 29.10.2015 um 14:18 schrieb Zbigniew Jędrzejewski-Szmek:
> >On Thu, Oct 29, 2015 at 01:44:34PM +0100, Reindl Harald wrote:
> >>
> >>
> >>Am 29.10.2015 um 13:37 schrieb Sérgio Basto:
> >>>On Qui, 2015-10-29 at 17:09 +0800, Christopher Meng wrote:
> You have a chance to get your rpmfusion softwares wiped after the sync.
> 
> [1]---https://bugzilla.redhat.com/show_bug.cgi?id=1263677
> >>>
> >>>yep, so not distro-sync
> >>
> >>nonsense when i read the bugreport
> >>
> >>* system-upgrade now uses dnf (standard "dnf update" approach)
> >>
> >>THAT is the problem and i really wonder what somebody thinks by
> >>implement it that way after *many years* of "yum --releasever=XX
> >>distro-sync" works absolutely relieable
> >>
> >>* change "dnf update" mode during system upgrade to
> >>   "dnf distro-sync --allowerasing"
> >>
> >>THAT is the right direction but nonsense because --allowerasing is a
> >>terrible idea, anyways "dnf --releasever=XX distro-sync" is not
> >>affected by both wrong solutions as far as i see (expect DNF is
> >>intentionally or unintenioally broken elsewhere there)
> >
> >There are three options:
> >(1, no distro-sync) — upgrade only packages which can be upgraded
> >   without conflicts. Leaves a partially upgraded system in some cases.
> >(2, distro-sync) — upgrade packages which can be upgraded, remove
> >   conflicting ones. Lose some packages during upgrade.
> >(3, force) — upgrade all packages ignoring conflicts. Leaves the
> >   system with some programs broken.
> >
> >You seem to dislike all the options, but I don't see anything else
> >possible. Do you have some better proposal?
> 
> just behave like "yum --releasever=XX distro-sync" all the years
> before and just REFUSE to upgrade if there are conflicts because
> anything else is undefined behavior
Well, that's what it does, more or less. Depending on --allowerasing
being there or not, it asks or refuses. You can always say "no".

> DNF just needs to give enough information how to solve the
> dependency problems
Yeah, it should. It's not too bad already.

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: BuildRequires: pythonN-devel unnecessary

[Petr Pisar]

On 2015-10-29, Dominik 'Rathann' Mierzejewski  wrote:
> On Thursday, 29 October 2015 at 01:31, Christopher Meng wrote:
>> On Thu, Oct 29, 2015 at 3:16 AM, Tom Hughes  wrote:
>> >
>> > On 28/10/15 19:12, Mike Bonnet wrote:
>> >>
>> >> https://fedoraproject.org/wiki/Packaging:Python#BuildRequires
>> >>
>> >> This is *not* required for pure Python packages, only for packages
>> >> compiling native extensions:
>> >
>> >
>> > Are you sure? Don't you need them for the RPM macros they contain?
>> 
>> Not my first time hitting on missing macros just because lack of
>> pythonN-devel, but if you just extract them from pythonN-devel to package
>> similar to these packages below, I reckon that it should be acceptable:
>> 
>> ---
>> ghc-srpm-macros
>> gnat-srpm-macros
>> go-srpm-macros
>> ocaml-srpm-macros
>> perl-srpm-macros
>> ---
>
> How about naming them:
> rpm-build-ghc
> rpm-build-gnat
> rpm-build-go
> rpm-build-ocaml
> rpm-build-perl
> rpm-build-python
> and so on?
>
Difference between srpm-macros and devel macros is that srpm-macros
macros are intended for building source RPM packages (hence the srpm
in the name) without introducing any new dependencies into minimal build
root. This is not obviously the case of devel packages.

While simple rename is not against anything, the "build" name associates
building binary RPM package which is not correct.

However, I have to admit, that having a standard package name for macros
needed for building non-native-extenstion (noarch) binary packages can
be handy. Especially if major of packages do not need header files and
compiler, so depending on devel package is superfluos overshot wasting
resources.

-- Petr

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

[Przemek Klosowski]

On 10/29/2015 05:56 AM, Reindl Harald wrote:


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



I believe "dnf update --best"  is more verbose and tells you where 
conflict is coming from. This is not very discoverable; I can't remember 
how I arrived at trying --best,  but it probably should be the default, 
as you say.




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

[Petr Pisar]

On 2015-10-29, Reindl Harald  wrote:
> removing random packages is also really dangerous and *not* acceptable
>
It does not remove random packages. It removes packages that are not
needed because the package was not installed explicitly and it's not
a transitive dependency of such explicitly installed package.

So either it's a bug in dependency specification, or the user should
mark the package as explicitly wanted.

Frankly if someone do a mass upgrade, he should expect some changes.

A contraexemple: A package splits into more subpackages. Suddenly
packages needing a moved file and requiring a package name instead of
a file name will stop work.

Are we going to fight against splitting packages?

(Better distributions have system of notifications that allows to warn
a user before the upgrade that something important is going to change.)

-- Petr

-- 
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 IPv6 testing and improvements - request for ideas

[Pavel Simerda]

Hi all,

I am writing to Fedora development mailing lists to get opinions
and ideas regarding our project on improving IPv6 support in
Fedora across its components.

https://fedoraproject.org/wiki/QA/Networking

Most prominent subpages:

 * https://fedoraproject.org/wiki/QA/Networking/Test_environment
 * https://fedoraproject.org/wiki/QA/Networking/Client_software
 * https://fedoraproject.org/wiki/QA/Networking/Server_software

During the first phase we are interested in getting feedback on
testing methods and test cases. Any other ideas are of course
welcome. Even contacts for future collaboration would be great.

Cheers,

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

[Przemek Klosowski]

On 10/29/2015 08:33 AM, Reindl Harald wrote:


Am 29.10.2015 um 13:24 schrieb Honza Šilhan:


dnf has `--allowerasing switch - it will resolve the conflicts by 
uninstallation
of conflicting packages. Installing the packages regardless the 
dependencies by

`--force` is really dangerous and will not be supported by DNF.


removing random packages is also really dangerous and *not* acceptable
For what it's worth, in the YUM days few years back I had a botched 
update (not even upgrade!). I believe it was a 5.x Centos, and yum 
decided to delete a ton of packages. The system became unbootable, and I 
had to do a lot of manual yum installs including IIRC yum itself, to 
restore it. I didn't even file yum  bugs because that system has a rich 
history and a lot of odd software installed so I chalked it to 
'self-inflicted', but:


I learned to be very careful reading the lists of packages 
suggested for deletion.



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

[Reindl Harald]

Am 29.10.2015 um 16:30 schrieb Przemek Klosowski:

On 10/29/2015 08:33 AM, Reindl Harald wrote:


Am 29.10.2015 um 13:24 schrieb Honza Šilhan:


dnf has `--allowerasing switch - it will resolve the conflicts by
uninstallation
of conflicting packages. Installing the packages regardless the
dependencies by
`--force` is really dangerous and will not be supported by DNF.


removing random packages is also really dangerous and *not* acceptable

For what it's worth, in the YUM days few years back I had a botched
update (not even upgrade!). I believe it was a 5.x Centos, and yum
decided to delete a ton of packages. The system became unbootable, and I
had to do a lot of manual yum installs including IIRC yum itself, to
restore it. I didn't even file yum  bugs because that system has a rich
history and a lot of odd software installed so I chalked it to
'self-inflicted', but:

I learned to be very careful reading the lists of packages
suggested for deletion


well, luckily we have now /etc/dnf/protected.d/dnf.conf containing "dnf" 
to prevent the combination of bugs and mistakes doing that sort of 
damage - i remember well summer 2014 how hard i was defended to demand 
get that back since yum had it for years


the same for uninstall the running kernel



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: System V to systemd unit migration

[Robert Scheck]

Hello Adam,

On Wed, 28 Oct 2015, Adam Jackson wrote:
> As a quick audit (based on 'grep _initrddir' and 'grep _initddir' over
> a fairly recent checkout of the spec files in pkg git, and then some
> manual inspection) I think the following packages will be affected:

your grep calls should include %{_sysconfdir}/rc.d/init.d/, too.


Greetings,
  Robert


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

Re: To distro-sync or not distro-sync?

[Dominik 'Rathann' Mierzejewski]

On Thursday, 29 October 2015 at 15:00, Vít Ondruch wrote:
> Dne 29.10.2015 v 13:24 Honza Šilhan napsal(a):
> > You can exclude the conflicting packages to proceed the system-upgrade i.e.:
> > "dnf system-upgrade download --releasever=23 --distro-sync -x 
> > rubygem-celluloid --allowerasing"
> 
> 
> Does the "-x" work actually? Last time I tried, the package I excluded
> was not downloaded (as expected), but after restart, the "-x" was not
> used and my system-upgrade failed (this was unexpected). These flags
> should be propagated and honored after restart, during the upgrade phase.

It doesn't, at least not in F21:
https://bugzilla.redhat.com/show_bug.cgi?id=1238204

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
-- 
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] Fedora 23 Final (second round) status is NO-GO

[Jan Kurik]

At the second round of Fedora 23 Final Go/No-Go Meeting, that just ends,
was agreed *not to release* the Fedora 23 Final.

Due to a present blocker (BZ 1276165) in the RC6 build, the decision is
No-Go. There is currently rebuild of RC in progress, fixing the issue.
Third run of the Go/No-Go meeting is going to be planned on this Friday
2015-Oct-30.
There are currently no changes in the schedule of F23, and GA is still
expected on Tuesday 2015-Nov-03.

Meeting details can be seen here:
Minutes:
http://meetbot.fedoraproject.org/fedora-meeting-2/2015-10-29/f23-final-go_no_go-meeting_2.2015-10-29-16.00.html

Log:
http://meetbot.fedoraproject.org/fedora-meeting-2/2015-10-29/f23-final-go_no_go-meeting_2.2015-10-29-16.00.log.html


Thanks everyone!

-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: apitrace-libs.i686 missing in x86_64 repos

[Kevin Fenzi]

On Thu, 29 Oct 2015 12:44:55 +0100
Sandro Mani  wrote:

> On 25.09.2015 23:46, Sandro Mani wrote:
> >
> >
> > On 25.09.2015 22:44, Michael Schwendt wrote:  
> >> On Fri, 25 Sep 2015 19:40:16 +0200, Sandro Mani wrote:
> >>
> >> Well, then adding the i686 build to the mash x86_64 multilib
> >> compose whitelist
> >> cannot be avoided -- as it's needed to really fix #1068620.  
> > Okay thanks - https://pagure.io/mash/issue/4.  
> Been a couple of weeks, is pagure being actively used for tracking
> mash requests?

yes.

However: 

1) There's some kind of big release releng is working on.
Something 23? It's taking up a lot of their time. ;) 

2) I think there's a pagure issue here where PR's aren't notifying
people who can merge them. I didn't see any notice of this one... 
Will try and file a ticket on that. 

kevin





pgpJ47zOgcWhe.pgp
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

Fedora 23 Go/No-Go Meeting - 3rd round, on Friday, October 30th, 4PM (UTC)

[Jan Kurik]

Join us on irc.freenode.net in #fedora-meeting-2 for the third round of the
Go/No-Go meeting, wherein we shall determine the readiness of the Fedora
23. The meeting is scheduled at 4PM (UTC). Please follow the [FedoCal] link
to find the time of the meeting in your time-zone.

[FedoCal] https://apps.fedoraproject.org/calendar/meeting/3154/



"Before each public release Development, QA and Release Engineering meet to
determine if the release criteria are met for a particular release. This
meeting is called the Go/No-Go Meeting."

"Verifying that the Release criteria are met is the responsibility of the
QA Team."


For more details about this meeting see:
https://fedoraproject.org/wiki/Go_No_Go_Meeting


In the meantime, keep an eye on the Fedora 23 Final Blocker list:
https://qa.fedoraproject.org/blockerbugs/milestone/23/final/buglist


Thanks for attending, 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-- 
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: apitrace-libs.i686 missing in x86_64 repos

[Pierre-Yves Chibon]

On Thu, Oct 29, 2015 at 11:48:25AM -0600, Kevin Fenzi wrote:
> On Thu, 29 Oct 2015 12:44:55 +0100
> Sandro Mani  wrote:
> 
> > On 25.09.2015 23:46, Sandro Mani wrote:
> > >
> > >
> > > On 25.09.2015 22:44, Michael Schwendt wrote:  
> > >> On Fri, 25 Sep 2015 19:40:16 +0200, Sandro Mani wrote:
> > >>
> > >> Well, then adding the i686 build to the mash x86_64 multilib
> > >> compose whitelist
> > >> cannot be avoided -- as it's needed to really fix #1068620.  
> > > Okay thanks - https://pagure.io/mash/issue/4.  
> > Been a couple of weeks, is pagure being actively used for tracking
> > mash requests?
> 
> yes.
> 
> However: 
> 
> 1) There's some kind of big release releng is working on.
> Something 23? It's taking up a lot of their time. ;) 
> 
> 2) I think there's a pagure issue here where PR's aren't notifying
> people who can merge them. I didn't see any notice of this one... 
> Will try and file a ticket on that. 

It warns people with direct commit rights but not people in groups having
commits right, there is a ticket opened for this:
https://pagure.io/pagure/issue/449

Pierre


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

Re: To distro-sync or not distro-sync?

[Kevin Kofler]

Petr Pisar wrote:
> It does not remove random packages. It removes packages that are not
> needed because the package was not installed explicitly and it's not
> a transitive dependency of such explicitly installed package.

That's the autoremove misfeature, which is really a different issue than the 
--allowerasing to resolve dependency conflicts that is being discussed here.

IMHO, enabling autoremoval by default was a horrible idea.

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

[Test-Announce] Fedora 23 Final Release Candidate 9 (RC9) Available Now!

[Adam Williamson]

On our modified schedule [1], Fedora 23 Final Release Candidate 9 (RC9)
is now available for testing. Please help us complete all the
validation testing!

The only difference between RC6 and RC9 is that RC9 includes the
correct version of fedora-release-notes. We don't really need to do a
full validation run on RC9, we should just check the release-notes are
as expected, and then concentrate on sanity checking - running basic
installs with all the images, ideally written to real media - to ensure
nothing went wonky during compose. RC7 and RC8 were failed compose
attempts.

As a heads-up, it's possible we'll be doing an RC10 to try and fix the
anaconda help issue. Work is ongoing on that.

Content information, including changes, can be found at
https://fedorahosted.org/rel-eng/ticket/6266#comment:22 . Please see
the following pages for download links and testing instructions.
Normally dl.fedoraproject.org should provide the fastest download, but
download-
ib01.fedoraproject.org is available as a mirror (with an approximately
1 hour lag) in case of trouble. To use it, just replace "dl" with 
"download-ib01" in the download URL.

Installation:

https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

Base:

https://fedoraproject.org/wiki/Test_Results:Current_Base_Test

Workstation and Desktop:

https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test

Server:

https://fedoraproject.org/wiki/Test_Results:Current_Server_Test

Cloud:

https://fedoraproject.org/wiki/Test_Results:Current_Cloud_Test

Summary:

https://fedoraproject.org/wiki/Test_Results:Current_Summary

All Alpha, Beta and Final priority test cases for each of these test
pages [2] must pass in order to meet the Final Release Criteria [3].

Help is available on #fedora-qa on irc.freenode.net [4], or on the 
test list [5].

Create Fedora 23 Final test compose (TC) and release candidate (RC) 
https://fedorahosted.org/rel-eng/ticket/6266

Current Blocker and Freeze Exception bugs:
http://qa.fedoraproject.org/blockerbugs/current
[1] http://fedorapeople.org/groups/schedule/f-23/f-23-quality-tasks.htm
l
[2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan
[3] https://fedoraproject.org/wiki/Fedora_23_Final_Release_Criteria
[4] irc://irc.freenode.net/fedora-qa
[5] https://admin.fedoraproject.org/mailman/listinfo/test
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


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

Re: Looking for someone to take over Asterisk and related packages

[Jared K. Smith]

On Wed, Oct 28, 2015 at 5:03 PM, Jeffrey Ollie  wrote:

> So, after almost 10 years, it's time to find someone else to take over the
> Asterisk packages.  If you're interested, reply to the list.  I'd prefer if
> someone with proven packaging skills would step up - Asterisk has several
> security-related releases a year in addition to several bug-fix releases so
> this isn't the package to get started with.
>
> I'd be happy to help out.

--
Jared Smith
-- 
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 IPv6 testing and improvements - request for ideas

[Peter Robinson]

On Thu, Oct 29, 2015 at 3:15 PM, Pavel Simerda  wrote:
> Hi all,
>
> I am writing to Fedora development mailing lists to get opinions
> and ideas regarding our project on improving IPv6 support in
> Fedora across its components.
>
> https://fedoraproject.org/wiki/QA/Networking

In the above page:
* Network configuration: I see NetworkManager in there but nothing
about systemd-networkd
* Other: firewalld including zones and other such configurations (you
mention iptables)

> Most prominent subpages:
>
>  * https://fedoraproject.org/wiki/QA/Networking/Test_environment

In this section I see "IPv6 node" but nothing that covers a IPv6 only
routed network with IPv6 to IPv4 gateway ie it runs v6 only internally
but uses 6 to 4 services for legacy services.

>  * https://fedoraproject.org/wiki/QA/Networking/Client_software

Again nothing about a native IPv6 only network with a gateway that
supports 6to4 for legacy services outside the network.

What about a iOS9 style preferring of IPv6 over IPv4 in the general
desktop. In the iOS9 case they do network measurements and favour IPv6
bydefault, and if it's going to be faster but fail back quickly if
it's not, how would we deal with this?

>  * https://fedoraproject.org/wiki/QA/Networking/Server_software

Nothing in here about:
* IPv6 services RA, dhcp6, 6 to 4 proxies, 4 to 6 proxies and other
such transition servers
* what about VPN services like a IPv6 only network connecting to a
dual stack VPN, or a IPv4 only VPN or a number of combinations there
of IE interfaces that are v6 only and ones that are v4 only. What
happens with routing then if there's other 6 to 4 services in play?
* Load balancers ie like facebook uses to bridge external dual stack
to IPv6 only internal services, or providing IPv6 externally to
present internal v4 services externally to v6

There's also nothing I can see from a quick read about offload
engines. A lot of 10Gb+ network interfaces have offloads for generic
IP, TCP, other acceleration to enable to do line speed 10+gb on IPv4,
we obviously want acceleration because IPv6 headers are larger and
hence take up more memory. There's toolkits like dpgk (
http://dpdk.org ) for acceleration of packets across large bandwidth
interfaces but I don't see any mention of that or network IO
virtualisation/offload.

Facebook and others have been testing these sorts of things:

https://code.facebook.com/posts/1123882380960538/linux-ipv6-improvement-routing-cache-on-demand/
https://code.facebook.com/posts/938078729581886/improving-the-linux-kernel-with-upstream-contributions/

Along these lines also I see nothing about Open vSwitch and SND
encapsulation protocols testing such as vxlan, GRE, GENEVE etc

> During the first phase we are interested in getting feedback on
> testing methods and test cases. Any other ideas are of course
> welcome. Even contacts for future collaboration would be great.

A future development would be around 6LoWPAN and the routing protocols
etc for that so we can communicate with IoT devices.

The way I read a lot of the pages above is a "this is how we did it on
IPv4 lets test it on IPv6" rather than a review of how things are
going to change with IPv6, how would I get to a IPv4 site if I'm on a
IPv6 network, visa versa and the whole sets of new use cases that are
appearing as a result of it.

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: Fedora IPv6 testing and improvements - request for ideas

[Zach Villers]

If it helps, Sixxs (https://www.sixxs.net/main/) is a very highly
recommended tunnel broker. I have not tried it and am not affiliated. I do
have ipv6 capability from my isp, so could help with testing.

On Thu, Oct 29, 2015 at 3:35 PM, Peter Robinson 
wrote:

> On Thu, Oct 29, 2015 at 3:15 PM, Pavel Simerda 
> wrote:
> > Hi all,
> >
> > I am writing to Fedora development mailing lists to get opinions
> > and ideas regarding our project on improving IPv6 support in
> > Fedora across its components.
> >
> > https://fedoraproject.org/wiki/QA/Networking
>
> In the above page:
> * Network configuration: I see NetworkManager in there but nothing
> about systemd-networkd
> * Other: firewalld including zones and other such configurations (you
> mention iptables)
>
> > Most prominent subpages:
> >
> >  * https://fedoraproject.org/wiki/QA/Networking/Test_environment
>
> In this section I see "IPv6 node" but nothing that covers a IPv6 only
> routed network with IPv6 to IPv4 gateway ie it runs v6 only internally
> but uses 6 to 4 services for legacy services.
>
> >  * https://fedoraproject.org/wiki/QA/Networking/Client_software
>
> Again nothing about a native IPv6 only network with a gateway that
> supports 6to4 for legacy services outside the network.
>
> What about a iOS9 style preferring of IPv6 over IPv4 in the general
> desktop. In the iOS9 case they do network measurements and favour IPv6
> bydefault, and if it's going to be faster but fail back quickly if
> it's not, how would we deal with this?
>
> >  * https://fedoraproject.org/wiki/QA/Networking/Server_software
>
> Nothing in here about:
> * IPv6 services RA, dhcp6, 6 to 4 proxies, 4 to 6 proxies and other
> such transition servers
> * what about VPN services like a IPv6 only network connecting to a
> dual stack VPN, or a IPv4 only VPN or a number of combinations there
> of IE interfaces that are v6 only and ones that are v4 only. What
> happens with routing then if there's other 6 to 4 services in play?
> * Load balancers ie like facebook uses to bridge external dual stack
> to IPv6 only internal services, or providing IPv6 externally to
> present internal v4 services externally to v6
>
> There's also nothing I can see from a quick read about offload
> engines. A lot of 10Gb+ network interfaces have offloads for generic
> IP, TCP, other acceleration to enable to do line speed 10+gb on IPv4,
> we obviously want acceleration because IPv6 headers are larger and
> hence take up more memory. There's toolkits like dpgk (
> http://dpdk.org ) for acceleration of packets across large bandwidth
> interfaces but I don't see any mention of that or network IO
> virtualisation/offload.
>
> Facebook and others have been testing these sorts of things:
>
>
> https://code.facebook.com/posts/1123882380960538/linux-ipv6-improvement-routing-cache-on-demand/
>
> https://code.facebook.com/posts/938078729581886/improving-the-linux-kernel-with-upstream-contributions/
>
> Along these lines also I see nothing about Open vSwitch and SND
> encapsulation protocols testing such as vxlan, GRE, GENEVE etc
>
> > During the first phase we are interested in getting feedback on
> > testing methods and test cases. Any other ideas are of course
> > welcome. Even contacts for future collaboration would be great.
>
> A future development would be around 6LoWPAN and the routing protocols
> etc for that so we can communicate with IoT devices.
>
> The way I read a lot of the pages above is a "this is how we did it on
> IPv4 lets test it on IPv6" rather than a review of how things are
> going to change with IPv6, how would I get to a IPv4 site if I'm on a
> IPv6 network, visa versa and the whole sets of new use cases that are
> appearing as a result of it.
>
> 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
>
-- 
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: apitrace-libs.i686 missing in x86_64 repos

[Sandro Mani]

On 29.10.2015 18:48, Kevin Fenzi wrote:

On Thu, 29 Oct 2015 12:44:55 +0100
Sandro Mani  wrote:


On 25.09.2015 23:46, Sandro Mani wrote:


On 25.09.2015 22:44, Michael Schwendt wrote:

On Fri, 25 Sep 2015 19:40:16 +0200, Sandro Mani wrote:

Well, then adding the i686 build to the mash x86_64 multilib
compose whitelist
cannot be avoided -- as it's needed to really fix #1068620.

Okay thanks - https://pagure.io/mash/issue/4.

Been a couple of weeks, is pagure being actively used for tracking
mash requests?

yes.

However:

1) There's some kind of big release releng is working on.
Something 23? It's taking up a lot of their time. ;)

2) I think there's a pagure issue here where PR's aren't notifying
people who can merge them. I didn't see any notice of this one...
Will try and file a ticket on that.

No stress, was just wondering. Thanks for the reply.

Sandro

--
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 IPv6 testing and improvements - request for ideas

[Chris Adams]

Once upon a time, Zach Villers  said:
> If it helps, Sixxs (https://www.sixxs.net/main/) is a very highly
> recommended tunnel broker. I have not tried it and am not affiliated. I do
> have ipv6 capability from my isp, so could help with testing.

There's also Hurricane Electric's free IPv6 tunnels.

BTW: one issue that I have seen with IPv6 and address privacy extensions
is that, since temporary address handling moved to user-space
(NetworkManager I guess?) instead of kernel-space, temporary addresses
are expired even when they are still in use.  This affects anything that
uses long-lived sessions (such as SSH to a server) and is highly
annoying.

The RFC (4941 section 3.4) says:

  "As an optional optimization, an implementation MAY remove a
   deprecated temporary address that is not in use by applications or
   upper layers as detailed in Section 6."

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

Orphaning flasm

[Kevin Kofler]

Hi,

I am hereby orphaning the flasm (Flash bytecode assembler disassembler) 
package. (I am about to click the buttons in pkgdb.) I was asked to pick 
this up back when I picked up gnash. I have since long given up 
maintainership of gnash. I have never had any use for this package (not even 
when I was still maintaining gnash), and I have not touched it for ages. I 
also wonder whether anybody uses it at all. Either way, I am not the right 
person to maintain this package.

The owner of the gnash package may want to take it up (as it is a tool that 
can be used to debug gnash). Or they might not have any use for it either, 
in which case it might be time to retire it (which will happen anyway if 
nobody picks it up). In any case, it is free to take.

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

Self Introduction: Noel Barrachina

[Noel B. A.]

Hola!

My name is Noel and I am a Spanish linux sysadmin. I work primarily with
CentOS servers and workstations.
I am a former Apple employee with experience packaging software for Mac.

I'd like to join the maintainers to help out and gain more experience.

What prompted me to start contributing was the version of tmux on my Fedora
22.

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

kdbus module being removed from Rawhide

[Josh Boyer]

Hi All,

We will be removing the kdbus driver from Rawhide kernels before the
4.3 final release upstream.  Realistically, this means kdbus will be
gone from Fedora by Monday November 2nd at the latest.  If you have a
setup using kdbus, please adjust it accordingly.

The upstream developers asked me to remove the module from Fedora
while they rethink some of the approach they are taking with kdbus.

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: Self Introduction: Noel Barrachina

[Orion Poplawski]

On 10/29/2015 04:29 PM, Noel B. A. wrote:

Hola!

My name is Noel and I am a Spanish linux sysadmin. I work primarily with
CentOS servers and workstations.
I am a former Apple employee with experience packaging software for Mac.

I'd like to join the maintainers to help out and gain more experience.

What prompted me to start contributing was the version of tmux on my
Fedora 22.



Welcome.

If you're looking to co-maintain tmux, you may want to read: 
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer


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

Fedora Rawhide 20151029 compose check report

[Fedora compose checker]

No missing expected images.

Images in this compose but not Rawhide 20151028:

Cloud disk raw i386
Cloud_atomic disk raw x86_64
Cloud disk qcow x86_64
Cloud docker x86_64
Cloud vagrant libvirt x86_64
Cloud vagrant virtualbox x86_64
Cloud_atomic disk qcow x86_64
Cloud disk raw x86_64
Cloud_atomic vagrant virtualbox x86_64
Cloud disk qcow i386
Cloud_atomic vagrant libvirt x86_64

No images in Rawhide 20151028 but not this.
-- 
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: Fedora IPv6 testing and improvements - request for ideas

[Scott Schmit]

On Thu, Oct 29, 2015 at 11:15:10AM -0400, Pavel Simerda wrote:
> I am writing to Fedora development mailing lists to get opinions
> and ideas regarding our project on improving IPv6 support in
> Fedora across its components.
> 
> https://fedoraproject.org/wiki/QA/Networking
> 
> Most prominent subpages:
> 
>  * https://fedoraproject.org/wiki/QA/Networking/Test_environment

It may make sense to have a IPv6 case between global & local that has
all 4 categories of address (I see this as loosely analogous to the IPv4
masqueraded case).

Another case would be multi-homed IPv6, where you have global IPv6
addresses from multiple sources (could be two ISPs, two tunnel
providers, or one ISP and one tunnel provider).

IPv6 is designed to be inherently more dynamic than IPv4 (particularly
with RAs) -- we should test transitions between connectivity states
(simulating an ISP connection dropping and coming back up or a router
going down and coming back up).

Speed differences between IPv6 & IPv4 could be a factor as well (happy
eyeballs) -- though reportedly IPv6 has tended to be faster than IPv4
rather than the previously-expected inverse.

Checking support for DHCPv6-PD would also be valuable.

>  * https://fedoraproject.org/wiki/QA/Networking/Client_software
>  * https://fedoraproject.org/wiki/QA/Networking/Server_software
> 
> During the first phase we are interested in getting feedback on
> testing methods and test cases. Any other ideas are of course
> welcome. Even contacts for future collaboration would be great.

-- 
Scott
-- 
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: BuildRequires: pythonN-devel unnecessary

[Christopher Meng]

On Thu, Oct 29, 2015 at 10:48 PM, Petr Pisar  wrote:
> However, I have to admit, that having a standard package name for macros
> needed for building non-native-extenstion (noarch) binary packages can
> be handy. Especially if major of packages do not need header files and
> compiler, so depending on devel package is superfluos overshot wasting
> resources.

Yes, and to avoid faddish name like nodejs-packaging. It's better to
create a central repository for macros, and then decide where to put
them.

-- 

Yours sincerely,
Christopher Meng

http://cicku.me
-- 
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] Fedora 23 Final Release Candidate 10 (RC10) Available Now!

[Adam Williamson]

On our modified schedule [1], Fedora 23 Final Release Candidate 10
(RC10) is now available for testing. Please help us complete all the
validation testing!

All deities willing, this should be the last RC. The difference between
RC9 and RC10 is that yelp has been downgraded to 3.17.2 to make
anaconda's help pages work. The focus for RC10 should be any tests that
weren't run for RC3 or RC6 or RC9, basic sanity/smoke testing, checking
that anaconda help works on all images and still works properly for
GNOME apps; I've tested that quite a bit myself but more testing is
welcome! I've transferred results from RC3 and RC6 to the RC10 pages;
coconut's results should come in a few hours, you can check RC6 pages
to see which tests coconut runs and not bother duplicating them.

At the Go/No-Go tomorrow we'll be deciding whether to ship RC9 or RC10,
or slip again.

Content information, including changes, can be found at
https://fedorahosted.org/rel-eng/ticket/6266#comment:24 . Please see
the following pages for download links and testing instructions.
Normally dl.fedoraproject.org should provide the fastest download, but
download-
ib01.fedoraproject.org is available as a mirror (with an approximately
1 hour lag) in case of trouble. To use it, just replace "dl" with 
"download-ib01" in the download URL.

Installation:

https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

Base:

https://fedoraproject.org/wiki/Test_Results:Current_Base_Test

Workstation and Desktop:

https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test

Server:

https://fedoraproject.org/wiki/Test_Results:Current_Server_Test

Cloud:

https://fedoraproject.org/wiki/Test_Results:Current_Cloud_Test

Summary:

https://fedoraproject.org/wiki/Test_Results:Current_Summary

All Alpha, Beta and Final priority test cases for each of these test
pages [2] must pass in order to meet the Final Release Criteria [3].

Help is available on #fedora-qa on irc.freenode.net [4], or on the 
test list [5].

Create Fedora 23 Final test compose (TC) and release candidate (RC) 
https://fedorahosted.org/rel-eng/ticket/6266

Current Blocker and Freeze Exception bugs:
http://qa.fedoraproject.org/blockerbugs/current
[1] http://fedorapeople.org/groups/schedule/f-23/f-23-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan
[3] https://fedoraproject.org/wiki/Fedora_23_Final_Release_Criteria
[4] irc://irc.freenode.net/fedora-qa
[5] https://admin.fedoraproject.org/mailman/listinfo/test
-- 
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