Re: Checking the ABI of packages submitted to the updates-testing Fedora repository

2015-06-08 Thread Nikos Mavrogiannopoulos 
On Fri, 2015-06-05 at 08:00 -0400, Stephen Gallagher wrote:

> > 
> > and
> > here is what stuck to my mind.  Others are of course welcome to add 
> > 
> > what
> > I have forgotten and to correct me when I a wrong.
> > 
> > To start, we'd like to have an automated way to check the ABI
> > compatibility of binaries embedded in packages that are submitted 
> > to 
> > the
> > updates-testing repository.  When an incompatible change[1] is 
> > detected,
> 
> Just to clarify, this isn't about the karma *count*, it's about 
> whether
> a package can be pushed to stable automatically when it reaches the
> karma threshold or if it requires a conscious decision by the
> maintainer to push it. This will present backwards-incompatible 
> changes
> from going to stable *accidentally*. (There are cases where they are
> permissible, such as security patches or ABI changes that are
> coordinated with all their consumers).

I'd prefer that ABI never breaks within a stable fedora release unless
there is some special permission for it. There can be no excuse
"coordinated with all consumers", because there is also software in the end 
user's systems where we can have no 
coordination.

regards,
Nikos



-- 
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: Checking the ABI of packages submitted to the updates-testing Fedora repository

2015-06-08 Thread Dodji Seketeli 
Nikos Mavrogiannopoulos  a écrit:

> On Fri, 2015-06-05 at 08:00 -0400, Stephen Gallagher wrote:
>
>> > 
>> > and
>> > here is what stuck to my mind.  Others are of course welcome to add 
>> > 
>> > what
>> > I have forgotten and to correct me when I a wrong.
>> > 
>> > To start, we'd like to have an automated way to check the ABI
>> > compatibility of binaries embedded in packages that are submitted 
>> > to 
>> > the
>> > updates-testing repository.  When an incompatible change[1] is 
>> > detected,
>> 
>> Just to clarify, this isn't about the karma *count*, it's about 
>> whether
>> a package can be pushed to stable automatically when it reaches the
>> karma threshold or if it requires a conscious decision by the
>> maintainer to push it. This will present backwards-incompatible 
>> changes
>> from going to stable *accidentally*. (There are cases where they are
>> permissible, such as security patches or ABI changes that are
>> coordinated with all their consumers).
>
> I'd prefer that ABI never breaks within a stable fedora release unless
> there is some special permission for it. There can be no excuse
> "coordinated with all consumers", because there is also software in the end 
> user's systems where we can have no 
> coordination.

Of course, nobody likes ABI *breakage*.  And I agree that if all ABI
breakage could be detected automatically, ABI breakages would never make
it into stable releases.

The thing is, the tool detects ABI *changes*.  Some changes are
breakages.  Some are not, depending on the particular context we are
looking at.  The tool does have heuristics to categorize certain changes
as being ABI breakages, but ultimately, I believe there is going to be
cases where human intervention is going to be necessary to tell if a
given change is harmful or not.  And it's going to be so for the
foreseeable future.  You can think of it as a kind of patch review, but
for ABI changes specifically.

Cheers,

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

Orphaned Packages in rawhide (2015-06-08)

2015-06-08 Thread opensource 
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

  Package(co)maintainers  Status Change 
===
SFML   orphan, sonkun 2 weeks ago   
blahtexml  orphan 4 weeks ago   
fwbuilder  orphan, till   1 weeks ago   
gvrpcd orphan 4 weeks ago   
obexftporphan, itamarjp   8 weeks ago   
ovirt-node orphan, apevec, fabiand, jboggs,   2 weeks ago   
   mburns72h, pmyers
python-pbs orphan 0 weeks ago   
python-sqlalchemy0.5   orphan 9 weeks ago   
python-sqlamp  orphan 9 weeks ago   

The following packages require above mentioned packages:
Depending on: SFML (1), status change: 2015-05-23 (2 weeks ago)
marsshooter (maintained by: martinkg)
marsshooter-0.7.5-7.20140507gitc855d04.fc23.i686 requires 
libsfml-audio.so.2, libsfml-graphics.so.2, libsfml-system.so.2, 
libsfml-window.so.2
marsshooter-0.7.5-7.20140507gitc855d04.fc23.src requires 
SFML-devel = 2.1-4.fc23


Depending on: python-sqlalchemy0.5 (1), status change: 2015-03-31 (9 weeks ago)
python-migrate0.5 (maintained by: lmacken, mbacovsk)
python-migrate0.5-0.5.4-7.fc21.noarch requires 
python-sqlalchemy0.5 = 0.5.8-11.fc19
python-migrate0.5-0.5.4-7.fc21.src requires 
python-sqlalchemy0.5 = 0.5.8-11.fc19


Affected (co)maintainers
apevec: ovirt-node
fabiand: ovirt-node
itamarjp: obexftp
jboggs: ovirt-node
lmacken: python-sqlalchemy0.5
martinkg: SFML
mbacovsk: python-sqlalchemy0.5
mburns72h: ovirt-node
pmyers: ovirt-node
sonkun: SFML
till: fwbuilder

Orphans (9): SFML blahtexml fwbuilder gvrpcd obexftp ovirt-node
python-pbs python-sqlalchemy0.5 python-sqlamp


Orphans (dependend on) (2): SFML python-sqlalchemy0.5


Orphans (rawhide) for at least 6 weeks (dependend on) (1):
python-sqlalchemy0.5


Orphans  (rawhide)(not depended on) (7): blahtexml fwbuilder gvrpcd
obexftp ovirt-node python-pbs python-sqlamp


Orphans (rawhide) for at least 6 weeks (not dependend on) (2): obexftp
python-sqlamp


Depending packages (rawhide) (2): marsshooter python-migrate0.5


Packages depending on packages orphaned (rawhide) for more than 6
weeks (1): python-migrate0.5


Not found in repo (rawhide) (1): ovirt-node

-- 
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its trac instance:
https://fedorahosted.org/rel-eng/
The sources of this script can be found at:
https://git.fedorahosted.org/cgit/releng/tree/scripts/find_unblocked_orphans.py
-- 
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: Checking the ABI of packages submitted to the updates-testing Fedora repository

2015-06-08 Thread Nikos Mavrogiannopoulos 
On Mon, 2015-06-08 at 09:39 +0200, Dodji Seketeli wrote:

> Of course, nobody likes ABI *breakage*.  And I agree that if all ABI
> breakage could be detected automatically, ABI breakages would never 
> make
> it into stable releases.
> The thing is, the tool detects ABI *changes*.  Some changes are
> breakages.  Some are not, depending on the particular context we are
> looking at.  The tool does have heuristics to categorize certain 
> changes
> as being ABI breakages, but ultimately, I believe there is going to 
> be
> cases where human intervention is going to be necessary to tell if a
> given change is harmful or not.  And it's going to be so for the
> foreseeable future.  You can think of it as a kind of patch review, 
> but for ABI changes specifically.

I have not seen the output of abicheck (I use abi-compliance-checker
personally but I guess abidiff is as good). However, I'm not sure about
which changes which are not breakages you mean? I'm not aware of ABI
changes which do not break users of libraries.

regards,
Nikos

-- 
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: Checking the ABI of packages submitted to the updates-testing Fedora repository

2015-06-08 Thread Alexander Bokovoy 

On Mon, 08 Jun 2015, Nikos Mavrogiannopoulos wrote:

On Mon, 2015-06-08 at 09:39 +0200, Dodji Seketeli wrote:


Of course, nobody likes ABI *breakage*.  And I agree that if all ABI
breakage could be detected automatically, ABI breakages would never
make
it into stable releases.
The thing is, the tool detects ABI *changes*.  Some changes are
breakages.  Some are not, depending on the particular context we are
looking at.  The tool does have heuristics to categorize certain
changes
as being ABI breakages, but ultimately, I believe there is going to
be
cases where human intervention is going to be necessary to tell if a
given change is harmful or not.  And it's going to be so for the
foreseeable future.  You can think of it as a kind of patch review,
but for ABI changes specifically.


I have not seen the output of abicheck (I use abi-compliance-checker
personally but I guess abidiff is as good). However, I'm not sure about
which changes which are not breakages you mean? I'm not aware of ABI
changes which do not break users of libraries.

Adding new functions to ABI constitute changes that don't break existing
users as long as previously available data structures are not affected.
--
/ Alexander Bokovoy
--
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: Checking the ABI of packages submitted to the updates-testing Fedora repository

2015-06-08 Thread Nikos Mavrogiannopoulos 
On Mon, 2015-06-08 at 11:53 +0300, Alexander Bokovoy wrote:

> > I have not seen the output of abicheck (I use abi-compliance
> > -checker
> > personally but I guess abidiff is as good). However, I'm not sure 
> > about
> > which changes which are not breakages you mean? I'm not aware of 
> > ABI
> > changes which do not break users of libraries.
> Adding new functions to ABI constitute changes that don't break 
> existing
> users as long as previously available data structures are not 
> affected.

Ok. In that aspect abi-compliance-checker is better as it notifies of
ABI breakages and not just any changes.

regards,
Nikos

-- 
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: Checking the ABI of packages submitted to the updates-testing Fedora repository

2015-06-08 Thread Dodji Seketeli 
Nikos Mavrogiannopoulos  a écrit:

> On Mon, 2015-06-08 at 11:53 +0300, Alexander Bokovoy wrote:
>
>> > I have not seen the output of abicheck (I use abi-compliance
>> > -checker
>> > personally but I guess abidiff is as good). However, I'm not sure 
>> > about
>> > which changes which are not breakages you mean? I'm not aware of 
>> > ABI
>> > changes which do not break users of libraries.
>> Adding new functions to ABI constitute changes that don't break 
>> existing
>> users as long as previously available data structures are not 
>> affected.
>
> Ok. In that aspect abi-compliance-checker is better as it notifies of
> ABI breakages and not just any changes.

I am afraid things are not only that simple.

For instance, if you have a function "void foo(struct something*p)", and
there is a change in "struct something".  That change is an ABI change.
But it might or might be an ABI breakage.  In that particular case, I
think abi-compliance-checker won't notice that change.  But it can be
harmful.

Please look at the code examples at 
https://sourceware.org/libabigail/manual/abidiff.html#usage-examples.

Cheers,

-- 
Dodji
-- 
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: 20150608 changes

2015-06-08 Thread Fedora Rawhide Report 
Compose started at Mon Jun  8 05:15:03 UTC 2015
Broken deps for i386
--
[ambari]
ambari-server-1.5.1-3.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
ambari-server-1.5.1-3.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
ambari-server-1.5.1-3.fc22.noarch requires 
mvn(com.sun.jersey:jersey-client)
ambari-server-1.5.1-3.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-multipart)
ambari-server-1.5.1-3.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
ambari-views-1.5.1-3.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
[apache-scout]
apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws)
apache-scout-1.2.6-11.fc21.noarch requires 
mvn(org.apache.juddi:juddi-client)
[boo]
boo-0.9.4.9-11.fc22.i686 requires mono(mscorlib) = 0:2.0.0.0
boo-0.9.4.9-11.fc22.i686 requires mono(System.Xml) = 0:2.0.0.0
boo-0.9.4.9-11.fc22.i686 requires mono(System.Core) = 0:3.5.0.0
boo-0.9.4.9-11.fc22.i686 requires mono(System) = 0:2.0.0.0
boo-0.9.4.9-11.fc22.i686 requires mono(Microsoft.Build.Utilities) = 
0:2.0.0.0
boo-0.9.4.9-11.fc22.i686 requires mono(Microsoft.Build.Tasks) = 
0:2.0.0.0
boo-0.9.4.9-11.fc22.i686 requires mono(Microsoft.Build.Framework) = 
0:2.0.0.0
boo-devel-0.9.4.9-11.fc22.i686 requires mono(mscorlib) = 0:2.0.0.0
boo-devel-0.9.4.9-11.fc22.i686 requires mono(System.Xml) = 0:2.0.0.0
boo-devel-0.9.4.9-11.fc22.i686 requires mono(System.Core) = 0:3.5.0.0
boo-devel-0.9.4.9-11.fc22.i686 requires mono(System) = 0:2.0.0.0
boo-devel-0.9.4.9-11.fc22.i686 requires mono(NAnt.DotNetTasks) = 
0:0.90.3780.0
boo-devel-0.9.4.9-11.fc22.i686 requires mono(NAnt.Core) = 0:0.90.3780.0
[dmlite-plugins-memcache]
dmlite-plugins-memcache-0.5.0-7.fc20.i686 requires libprotobuf.so.8
[gambas3]
gambas3-gb-pdf-3.7.1-1.fc23.i686 requires libpoppler.so.49
[gdal]
gdal-1.11.2-6.fc23.i686 requires libpoppler.so.49
gdal-java-1.11.2-6.fc23.i686 requires libpoppler.so.49
gdal-libs-1.11.2-6.fc23.i686 requires libpoppler.so.49
gdal-perl-1.11.2-6.fc23.i686 requires libpoppler.so.49
[hadoop]
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-servlet)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
hadoop-hdfs-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-hdfs-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hadoop-mapreduce-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-mapreduce-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-servlet)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-client)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
hadoop-yarn-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-json)
hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hadoop-yarn-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-client)
hadoop-yarn-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
[hbase]
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
[julia]
julia-0.3.7-2.fc23.i686 requires libLLVM-3.5.so
julia-devel-0.3.7-2.fc23.i686 requires libLLVM-3.5.so
[libreoffice]
1:libreoffice-pdfimport-5.0.0.0-3.beta1.fc23.i686 requires 
libpoppler.so.49
[matreshka]
matreshka-servlet-devel-0.7.0-1.fc23.i686 requires 
matreshka-servlet-lib{?_isa} = 0:0.7.0-1.fc23
matreshka-servlet-lib-0.7.0-1.fc23.i686 requires matreshka{?_isa} = 
0:0.7.0-1.fc23
matreshka-spikedog-api-devel-0.7.0-1.fc23.i686 requires 
matreshka-spikedog-api-lib{?_isa} = 0:0.7.0-1.fc23
matreshka-spiked

Re: Checking the ABI of packages submitted to the updates-testing Fedora repository

2015-06-08 Thread Dodji Seketeli 

> On Mon, 08 Jun 2015, Nikos Mavrogiannopoulos wrote:

[...]

>> I have not seen the output of abicheck (I use abi-compliance-checker
>> personally but I guess abidiff is as good).

It's abidiff :-)

>> However, I'm not sure about which changes which are not breakages you
>> mean? I'm not aware of ABI changes which do not break users of
>> libraries.

Alexander Bokovoy  a écrit:

> Adding new functions to ABI constitute changes that don't break existing
> users as long as previously available data structures are not
> affected.

Yes.

Though, in this particular case, you can invoke "abidiff" in a way that
makes it not mention these new function additions.

You can, for instance, invoke it in a way that makes it show only the
exported functions/variables that got removed, as well as those
functions/variables for which sub-types have changed in their
signatures.

These have more chance to be ABI related issues.  The "interesting" case
in my opinion is when the functions/variables have sub-type changes
which doesn't cause any underlying ELF symbol name change.  It's usually
In those cases that we might need a qualified user to review "the abi
diff" to tell if it constitutes an ABI breakage or not.

Cheers,

-- 
Dodji
-- 
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: Checking the ABI of packages submitted to the updates-testing Fedora repository

2015-06-08 Thread Petr Pisar 
On 2015-06-05, Dodji Seketeli  wrote:
> The nature of programs written in these dynamic languages makes it quite
> hard to compare types used in the API entry points of a library

Pedantic note: There is difference between dynamic vs. static languages
and dynamically vs. statically typed languages. While dynamic languages
usually are dynamically typed, it does not imply it.

-- 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: Checking the ABI of packages submitted to the updates-testing Fedora repository

2015-06-08 Thread Michael Stahl 
On 08.06.2015 12:37, Petr Pisar wrote:
> On 2015-06-05, Dodji Seketeli  wrote:
>> The nature of programs written in these dynamic languages makes it quite
>> hard to compare types used in the API entry points of a library
> 
> Pedantic note: There is difference between dynamic vs. static languages
> and dynamically vs. statically typed languages. While dynamic languages
> usually are dynamically typed, it does not imply it.

while we are being pedantic, we would be remiss not to mention that
there is no such thing as "dynamically typed", given that types are a
*syntactic* property.

"A type system is a tractable syntactic method for proving the absence
of certain program behaviors by classifying phrases according to the
kinds of values they compute." - Pierce, Benjamin C. (2002). Types and
Programming Languages. MIT Press. ISBN 978-0-262-16209-8.

for further discussion of the topic including an explanation of how the
term "dynamic language" actually goes back to the Visigoths, i refer to:

http://lambda-the-ultimate.org/node/1562#comment-18623

-- 
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 22 and missing applications

2015-06-08 Thread Tim Lauridsen 
On Wed, 27 May 2015 at 17:19 Matthew Miller 
wrote:

> On Wed, May 27, 2015 at 05:07:52PM +0200, Michael Schwendt wrote:
> > > Having keywords makes the search functionality much
> > > better, but isn't actually required for your application to be shown
> > > in the software center.
> > What would they add that's not found within the RPM package %description
> > and %summary already?
>
> Often, synonyms — terms that should apply, but for whatever reason
> isn't in the description.
>
> Richard, sorry for the dumb question, but is there a path to pull in
> keywords from ? Or, going the
> other way, can we get the Fedora apps team to highlight/prioritize
> packages which match applications on your list within Tagger?
>
>
>
The fedora repository contains -pkgtags.sqlite.gz metadata, they was
used by yum, but IFAIK not supported in dnf/hawkey/librepo but the
information exist in the repositories.

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

pl-7.2.0-1.fc23 changed license

2015-06-08 Thread Petr Pisar 
A new version of SWI Prologue pl-7.2.0-1.fc23 brought a new code and new
licenses. For your information the license of `pl' package was changed from 

(GPLv2+ with exceptions or Artistic 2.0) and (GPLv2+ with exceptions) and
LGPLv2+ and LGPLv2 and UCD and BSD and Public Domain and EPL and GPLv2 and
GPLv3+

to

(GPLv2+ with exceptions or Artistic 2.0) and (GPLv2+ with exceptions) and
(GPLv2 with exception) and (GPL+ or Artistic) and LGPLv2+ and LGPLv2 and UCD
and (UCD and MIT) and BSD and Public Domain and EPL and GPLv2 and GPLv3+

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

F23 System Wide Change: Boost 1.59 Uplift

2015-06-08 Thread Jan Kurik 
= Proposed System Wide Change: Boost 1.59 Uplift =
https://fedoraproject.org/wiki/Changes/F23Boost159

Change owner(s):  Jon Wakely 

This change brings Boost 1.58.0 or later to Fedora 23. We generally aim to ship 
1.59.0, as that seems likely to make it (hence the Change name), but 1.58.0 is 
out and available now. 

== Detailed Description ==
The aim is to synchronize Fedora with the most recent Boost release. Because 
ABI stability is one of explicit Boost non-goals, this entails rebuilding of 
all dependent packages. This has also always entailed yours truly assisting 
maintainers of client packages in decoding cryptic boostese seen in output from 
g++. Such care is to be expected this time around as well.

Boost 1.59 does not have firm schedule yet. I do not think there is even a 
provisional schedule at this point. We may have to package Boost 1.58 instead.

Here is the Fedora 22 Change, should you need it. 


== Scope ==
Rebasing Boost has a fairly large impact on Fedora. For Fedora 20, the scope 
was: about 130 packages _must_ be rebuilt due to ABI breakage inherent in 
bumping Boost sonames. There were almost 250 client packages total. I expect 
these numbers to stay in the same ballpark for Fedora 23.

* Proposal owners:
  ** Build will be done with Boost.Build v2 (which is upstream-sanctioned way 
of building Boost)
  ** Request a "boost" build system tag (discussion) (take a look at the ticket 
#6093 for inspiration)
  ** Build boost into that tag (take a look at the build #606493 for 
inspiration)
  ** Post a request for rebuilds to fedora-devel (XXX link to fedora-devel 
message here)
  ** Work on rebuilding dependent packages in the tag.
  ** When most is done, re-tag all the packages to rawhide
  ** Watch fedora-devel and assist in rebuilding broken Boost clients (by 
fixing the client, or Boost). 

* Other developers: Those who depend on Boost DSO's will have to rebuild their 
packages. Feature owners will alleviate some of this work as indicated above, 
and will assist those whose packages fail to build in debugging them. 

* Release engineering: Side tag creation. 

* Policies and guidelines: Apart from scope, this is business as usual, so no 
policies, no guidelines. 


-- 
Jan Kuřík
___
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: fedup for F23 and beyond

2015-06-08 Thread Neal Gompa 
On Sun, Jun 7, 2015 at 3:30 PM, Will Woods  wrote:
> On Sun, 2015-06-07 at 07:41 -0400, Neal Gompa wrote:
>> Uhh, this might be a stupid question, but what actually prevents us
>> from integrating the FedUp process into install media (that is, not
>> live images)? I mean, yeah, it's nice that we can do upgrades online,
>> but what about when the system we need to upgrade doesn't necessarily
>> have online access? I'd like to be able to trigger the upgrade
>> environment from install media (like with a Fedora Server ISO).
>
> Nothing, really - it's *better* if you have access to the updates repos
> during the upgrade, but it's technically feasible to do the upgrade
> from local media/repos.
>
> To make that work, you'd need:
>
> a) a way to easily enable the media as a repo, and then
> b) run DNF in offline mode (so it's OK with the unreachable network
> repos), and then
> c) ensure that the media will be mounted in the same place after reboot
> (e.g. by adding it to /etc/fstab) so the upgrade can proceed.
>
> (this workflow might even work with the current dnf-plugin-fedup, but I
> haven't tried it...)
>
> So, yeah, the last one is the trickiest part. It's very hard to be
> certain about whether a given filesystem path will be there when you
> reboot. So we either need to just leave that up to the user, or write
> mount units for *everything* on the system and hope that systemd
> figures it out after we reboot.
>
> (It's on my TODO list, since the fedup supported this with --device,
> but.. I just don't have spare time right now.)
>
> -w
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

From my view, if you're booting from an ISO already, wouldn't you be
able to consider that in a state in which you could just do the
upgrade? Couldn't Anaconda just drive DNF through the upgrade process?
When you're booting from the ISO, you've already mounted the local
filesystem and package repositories, so you could use it from there. I
would figure that DNF is already configured for offline mode during
anaconda installs as it is (unless, of course, you tell it to grab
updates from the Internet). Unless I'm missing something really big, I
don't see why you need to reboot when you're already offline and using
the Fedora install media boot environment to do an upgrade.

-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
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: fedup for F23 and beyond

2015-06-08 Thread Miroslav Suchý 
Dne 29.5.2015 v 13:38 Petr Hracek napsal(a):
> Please have a look on Feature proposed in Fedora 19.
> https://fedoraproject.org/wiki/Features/FedoraUpgrade
> It should be redesigned maybe. Package already exists in Fedora.
> 
> What do you think about it?

It is still there. Just not marked as Feature, but it is there. And it works.
And I will still continue to maintain it as it does the work.

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

[Base] Base Design WG agenda meeting 8st June 2015 14:15 UTC on #fedora-meeting-2

2015-06-08 Thread Harald Hoyer 
*IMPORTANT*: #fedora-meeting-2 ... I repeat: *two*

Agenda:
 - Interview candidates for new memberships
 - Optionally accept new members
 - Status - Docker
 - Status - BuildRequires
 - Open Floor

Please add items by replying to this mail.


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

[POC-change] Fedora packages point of contact updates

2015-06-08 Thread nobody 
Change in package status over the last 168 hours


5 packages were orphaned

docx2txt [f22, f21] was orphaned by bochecha
 Convert Docx documents to Text
 https://admin.fedoraproject.org/pkgdb/package/docx2txt
jna [el5] was orphaned by walters
 Pure Java access to native libraries
 https://admin.fedoraproject.org/pkgdb/package/jna
pyflakes [el5] was orphaned by scop
 A simple program which checks Python source files for errors
 https://admin.fedoraproject.org/pkgdb/package/pyflakes
python-pbs [f22, f21, f20, master, el6, el5] was orphaned by stevetraylen
 PBS/Torque python module
 https://admin.fedoraproject.org/pkgdb/package/python-pbs
weighttp [f22, f21, f20] was orphaned by bochecha
 Small tool to benchmark webservers
 https://admin.fedoraproject.org/pkgdb/package/weighttp

3 packages were retired

apache-juddi [master] was retired by mizdebsk
 Client API for UDDI
 https://admin.fedoraproject.org/pkgdb/package/apache-juddi
docx2txt [master] was retired by bochecha
 Convert Docx documents to Text
 https://admin.fedoraproject.org/pkgdb/package/docx2txt
weighttp [master] was retired by bochecha
 Small tool to benchmark webservers
 https://admin.fedoraproject.org/pkgdb/package/weighttp

2 packages unorphaned
-
jna [f22, f21, f20, master] was unorphaned by mizdebsk
 Pure Java access to native libraries
 https://admin.fedoraproject.org/pkgdb/package/jna
pyflakes [el6, epel7] was unorphaned by mrunge
 A simple program which checks Python source files for errors
 https://admin.fedoraproject.org/pkgdb/package/pyflakes

0 packages were unretired


6 packages were given

abootimg [epel7] was given by yaneti to jkastner
 Tool for manipulating Android boot images
 https://admin.fedoraproject.org/pkgdb/package/abootimg
fence-agents [f22, f21, f20, master] was given by fabbione to marx
 Fence Agents for Red Hat Cluster
 https://admin.fedoraproject.org/pkgdb/package/fence-agents
multitail [f22, f21, f20, master] was given by fabbione to jstanley
 View one or multiple files like tail but with multiple windows
 https://admin.fedoraproject.org/pkgdb/package/multitail
perl-Net-Telnet [f22, f21, f20, master] was given by fabbione to kanarip
 Net-Telnet Perl module
 https://admin.fedoraproject.org/pkgdb/package/perl-Net-Telnet
pyflakes [f22, f21, f20, master] was given by jcollie to scop
 A simple program which checks Python source files for errors
 https://admin.fedoraproject.org/pkgdb/package/pyflakes
resource-agents [f22, f21, f20, master] was given by fabbione to dvossel
 Open Source HA Reusable Cluster Resource Scripts
 https://admin.fedoraproject.org/pkgdb/package/resource-agents

5 packages had new branches

eclipse-e4-importer had a new branches: f22, master for sopotc by limb
 Alternative importer of Eclipse projects
 https://admin.fedoraproject.org/pkgdb/package/eclipse-e4-importer
eclipse-launchbar had a new branches: f22, master for sopotc by limb
 Alternative launcher toolbar for Eclipse
 https://admin.fedoraproject.org/pkgdb/package/eclipse-launchbar
eclipse-tm-terminal had a new branches: f22, master for akurtakov by limb
 Terminal plugin for Eclipse
 https://admin.fedoraproject.org/pkgdb/package/eclipse-tm-terminal
rubygem-rmail-sup had a new branches: f22, f21, master for kumarpraveen by limb
 A lightweight mail library written in ruby
 https://admin.fedoraproject.org/pkgdb/package/rubygem-rmail-sup
sdcc had a new branches: f22, f21, el6, master, el5 for jcapik by limb
 Small Device C Compiler
 https://admin.fedoraproject.org/pkgdb/package/sdcc


Sources: https://github.com/pypingou/fedora-owner-change
-- 
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: FESCo and Council elections in June 2015

2015-06-08 Thread Jan Kurik 
- Original Message -
> From: "Jan Kurik" 
> To: devel-annou...@lists.fedoraproject.org, annou...@lists.fedoraproject.org
> Sent: Wednesday, June 3, 2015 12:48:10 PM
> Subject: FESCo and Council elections in June 2015
> 
> Greetings,
> 
> FESCo and Council elections are now open and we're looking for new
> candidates:
>   https://fedoraproject.org/wiki/Elections
> 
> For FESCo we have opened four seats:
>   https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
> 
> For Council we have opened one seat:
>   https://fedoraproject.org/wiki/Council/Nominations

We have added Env and Stacks elections as well. Currently we have five open 
seats:
  https://fedoraproject.org/wiki/Env_and_Stacks/Nominations

Regards,
Jan

> The Elections schedule is as follows:
> * June 08-14: Nomination period open (closes promptly at 23:59 UTC on June
> 14th)
> * June 15-21: Campaign period. Individual blog posts, etc. encouraged. Will
> also have an email interview with all answers published simultaneously on
> the 21st.
> * June 22-28: Voting open (closes promptly at 23:59 UTC on June 28th)
> * June 29:Results announcement
> 
> 
> Elections Questionnaire needs more questions for Fedora Magazine interviews!
> If you have anything you would like to ask candidates to FESCo or to
> Council, please add it to the wiki.
>   http://fedoraproject.org/wiki/Elections/Questionnaire
> 
> 
> Read more about the FESCo at:
>   http://fedoraproject.org/wiki/Development/SteeringCommittee
> and about the Council at:
>   http://fedoraproject.org/wiki/Council
> 
> --
> Jan Kuřík

-- 
Jan Kuřík
Platform 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

FESCo, Council and Env and Stacks elections - Nomination period is now open

2015-06-08 Thread Jan Kurik 
Hello everyone!
The nomination period for FESCo, Council and Env and Stack Elections is now 
open.

We will be selecting four seats on FESCo [1], one seat on Council [2] and five 
seats on Env and Stacks [3]. If you are interested in these roles, please add 
yourself to the lists of nominees (check the links [1], [2], [3]) before 
23:59:59 UTC on June 14, 2015!  If you wish to nominate someone else, please 
consult with that person ahead of time. If you know someone who would be a good 
candidate, now is a great time to make sure they're thinking about it.

If you have questions you'd like to ask candidates, please add them to the 
Elections Questionnaire wiki page [4]. Nominees will answer these questions and 
the answers will be published simultaneously on June 22nd as part of campaign 
period. Questions may be moderated to fit Fedora Magazine interview format.

Elections schedule:
* June 08-14: Nomination period open
* June 15-21: Campaign period
* June 22-28: Voting open
* June29: Results announcement 

[1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
[2] https://fedoraproject.org/wiki/Council/Nominations
[3] https://fedoraproject.org/wiki/Env_and_Stacks/Nominations
[4] https://fedoraproject.org/wiki/Elections/Questionnaire

-- 
Jan Kuřík
___
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

Planned Outage: Storage migration - 2015-06-09 23:00 UTC

2015-06-08 Thread Kevin Fenzi 
 Planned Outage: Storage migration - 2015-06-09 23:00 UTC

 There will be an outage starting at 2015-06-09 23:00 UTC, which will
 last approximately 4 hours.

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

 date -d '2015-06-09 23:00 UTC'

 Reason for outage:

 This outage has now been rescheduled to 2015-06-09. 

 We will be migrating our NFS based storage from one backend to another.
 This will involve unmounting existing mounts, doing a final mirror of
 storage changes and remounting from the new backend. Note that this
 migration includes the master mirrors volumes. In the event we don't
 finish migrating all the volumes, an additional outage may be
 scheduled.

 Affected Services:

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

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

 Downloads - https://dl.fedoraproject.org master mirrors.

 GIT / Source Control - pkgs.fedoraproject.org

 Secondary Architectures

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

 Unaffected Services:

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

 Badges - https://badges.fedoraproject.org/

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

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

 Darkserver - https://darkserver.fedoraproject.org/

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

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

 Elections - https://admin.fedoraproject.org/voting

 Email system

 Fedmsg busmon - http://apps.fedoraproject.org/busmon

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

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

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

 Fedora Hosted - https://fedorahosted.org/

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

 Fedora People - http://fedorapeople.org/

 Main Website - http://fedoraproject.org/

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

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

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

 QA Services

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

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

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

 Contact Information:

 Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/4748

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

--

Comment (by kevin):

 The outage will now be starting at:

 2015-06-09 23:00 UTC and lasting 4 hours.


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

Re: Docker base image naming for non-x86_64

2015-06-08 Thread Vincent Batts 

On 06/06/15 16:40 -0400, Colin Walters wrote:

On Tue, Jun 2, 2015, at 11:02 AM, Adam Miller wrote:

Hello all,
There was recently a thread on the Fedora ARM mailing list[0]
about getting a Fedora ARM image into the official Docker Hub. That
discussion lead down the trail of how to best handle the naming for
all of this.

The current questions are either using Fedora's namespace and just
making a new image (using Fedora ARM as an example), this would be the
"FROM" line for a Dockerfile

FROM fedora/armhfp


Upstream Docker does have an Architecture metadata field.

I'd imagine there is some possibility to teach the client how to pull
the right base image based on an architecture.

There's probably some discussion of this somewhere upstream?
I'm CC'ing Vincent who might know.


this is a rough process. The client and registry work fine, on a given
arch, but not sharing. Upstream has talked of making an arm.docker.io as
a stop gap, but the problem needs to be fixed in the manifest and
registry API. This discussion always tends to end with "we'll do more
for this in the next release cycle". :-\


Or at least, detect when you pull an incompatible image?

It'd be good to coordinate this with other distributions like Debian
too - what patterns are they using?

I think what might be nicest is if the architecture became an implicit
3rd field or something?

So if I did:

docker pull fedora:22 from an x86_64 host I got x86_64 (or
amd64 in Debian terms),

But it should be *possible* to do:
docker pull fedora:22:arm64 or whatever on x86_64, even if
it won't actually run.


feel free to open the topic on
https://groups.google.com/forum/#!forum/docker-dev

IBMers and others would gladly pile in on the topic.

vb


pgp7vBxBRRrPA.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: [Base] Base Design WG agenda meeting 8st June 2015 14:15 UTC on #fedora-meeting-2

2015-06-08 Thread Harald Hoyer 
On 08.06.2015 10:29, Harald Hoyer wrote:
> *IMPORTANT*: #fedora-meeting-2 ... I repeat: *two*
> 
> Agenda:
>  - Interview candidates for new memberships
>  - Optionally accept new members
>  - Status - Docker
>  - Status - BuildRequires
>  - Open Floor
> 
> Please add items by replying to this mail.
> 
> 

Minutes:


Minutes (text):


Log:

-- 
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: Puppet 4

2015-06-08 Thread Zbigniew Jędrzejewski-Szmek 
On Sat, Jun 06, 2015 at 06:52:35PM -0400, Nico Kadel-Garcia wrote:
> On Fri, Jun 5, 2015 at 11:31 AM, Matthew Miller
>  wrote:
> > On Fri, Jun 05, 2015 at 01:31:10PM +, John Florian wrote:
> >> Personally I do so using a scheme like /opt/$VENDOR/$PRODUCT/$RELEASE,
> >> but to my knowledge the FHS has never ratified anything like that.  The
> >> FHS seems to take a rather vague stance on /opt overall IMHO.
> >
> > This is actually specifically addressed in FHS 3.0, released, actually,
> > _just this week_. See
> >
> >   http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs-30
> >
> > and specifically
> >
> >   http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html
> >
> > and the provider list:
> >
> >   http://www.lanana.org/lsbreg/providers/providers.txt
> >
> > which includes Fedora. (Credit to Tom and Toshio for working on this.)
> 
> Given the profound discrepancies between the FHS 3 and everything that
> systemd touches, I'm afraid it's become a confusing guideline for
> Fedora work. 
Fully agreed that using FHS as a guideline in confusing. It is
disappointing that the authors seem to completely ignore changes like
the merge to /usr, the ways in which /run is being used, etc.

Whatever one may think about it, systemd and the locations promulgated
by systemd have become *the* defaults for a great majority of modern
linux landscape. Even if systemd was spearheading some of those
changes, such decisions have to be implemented by the whole distro, and
were coordinated between multiple distros. FHS makes itself obsolete by
ignoring them.

> In particular, the insistence in sytemd of putting
> mountable medie under "/run", and of migrating system-specific
> conffigurations from "/etc" to "/run are at direct variance with even
> that most recent FHS. So it's not going to be a complete or reliable
> guideline.

Actually it's not systemd: udisks uses this location for removable
media. Neither is systemd migrating configurations from "/etc" to "/run"
(they would get wiped at reboot ;)).

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: F23 Self Contained Change: Netizen Spin

2015-06-08 Thread Debarshi Ray 
On Thu, Jun 04, 2015 at 10:45:20AM -0600, Kevin Fenzi wrote:
> Ideally it would not only install those packages, but configure them to
> a default to privacy setup. Additionally making some other changes from
> default desktop settings to do that as well. This is something that
> could be done in the spin %post or the like (all the other spins setup
> various config there), or perhaps in a seperate package like a
> 'netizen-privacy' that makes those changes. 

But, but ...

> So, you not only include say tor, but you setup the browser to use it
> by default, etc. 

... then there is the issue of choice. I am paranoid, but I also have
strong opinions on how my desktop should look and behave. Will we be
offering different variants of the Netizen spin, then?

Or have we finally given up on this choice thing? ;)

You could take that as a general criticism of most of the non-DE spins
out there.

I would be happier if someone did the hard work of making things more
secure, in the products and spins that we already have.  I don't think
our users should have to choose between a more secure and a less
secure Fedora. eg., just because someone wants to use Tor, doesn't
mean that she should have to install a different flavour of
Fedora. She should be able to configure it in any of the flavours or
products that she is already using.

Other than that, I have found it hard to comprehend the text on the
Wiki.  It spends a lot of time talking about a paper from 1943 and
physiological needs. I don't understand why "citizens" are considered
alternative users of Fedora.

Cheers,
Debarshi

pgpEJiT6i1NZK.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: F23 Self Contained Change: Netizen Spin

2015-06-08 Thread Kevin Fenzi 
On Mon, 8 Jun 2015 15:18:12 +
Debarshi Ray  wrote:

> On Thu, Jun 04, 2015 at 10:45:20AM -0600, Kevin Fenzi wrote:
> > Ideally it would not only install those packages, but configure
> > them to a default to privacy setup. Additionally making some other
> > changes from default desktop settings to do that as well. This is
> > something that could be done in the spin %post or the like (all the
> > other spins setup various config there), or perhaps in a seperate
> > package like a 'netizen-privacy' that makes those changes. 
> 
> But, but ...
> 
> > So, you not only include say tor, but you setup the browser to use
> > it by default, etc. 
> 
> ... then there is the issue of choice. I am paranoid, but I also have
> strong opinions on how my desktop should look and behave. Will we be
> offering different variants of the Netizen spin, then?
> 
> Or have we finally given up on this choice thing? ;)

No. I am not sure what point you are trying to make here...
can you try and rephrase or clarify?

You can still install and configure tor on any install. 

I think it pretty unlikely that tor setup would be default on all
installs. Tor is slow, many people don't want it. 

Having a spin where it's setup and configured for you could be a useful
starting point for some people who desire that. You can always adjust
from there. 

> You could take that as a general criticism of most of the non-DE spins
> out there.

They are handy starting points, IMHO. 
 
> I would be happier if someone did the hard work of making things more
> secure, in the products and spins that we already have.  I don't think
> our users should have to choose between a more secure and a less
> secure Fedora. eg., just because someone wants to use Tor, doesn't
> mean that she should have to install a different flavour of
> Fedora. She should be able to configure it in any of the flavours or
> products that she is already using.

Sure and they can. 

There's (as always) many ways to the same goals here. 

* A spin that is configured so people have an example and starting
  point. 

* Better out of the box config on packages (like tor) that make it
  easier to set them up and configure things to use them. 

* Better docs on how to do the above. 

Look at all that choice!

kevin


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

Re: fedup for F23 and beyond

2015-06-08 Thread Stephen John Smoogen 
On 8 June 2015 at 06:37, Neal Gompa  wrote:
> On Sun, Jun 7, 2015 at 3:30 PM, Will Woods  wrote:
>> On Sun, 2015-06-07 at 07:41 -0400, Neal Gompa wrote:
>>> Uhh, this might be a stupid question, but what actually prevents us
>>> from integrating the FedUp process into install media (that is, not
>>> live images)? I mean, yeah, it's nice that we can do upgrades online,
>>> but what about when the system we need to upgrade doesn't necessarily
>>> have online access? I'd like to be able to trigger the upgrade
>>> environment from install media (like with a Fedora Server ISO).
>>
>> Nothing, really - it's *better* if you have access to the updates repos
>> during the upgrade, but it's technically feasible to do the upgrade
>> from local media/repos.
>>
>> To make that work, you'd need:
>>
>> a) a way to easily enable the media as a repo, and then
>> b) run DNF in offline mode (so it's OK with the unreachable network
>> repos), and then
>> c) ensure that the media will be mounted in the same place after reboot
>> (e.g. by adding it to /etc/fstab) so the upgrade can proceed.
>>
>> (this workflow might even work with the current dnf-plugin-fedup, but I
>> haven't tried it...)
>>
>> So, yeah, the last one is the trickiest part. It's very hard to be
>> certain about whether a given filesystem path will be there when you
>> reboot. So we either need to just leave that up to the user, or write
>> mount units for *everything* on the system and hope that systemd
>> figures it out after we reboot.
>>
>> (It's on my TODO list, since the fedup supported this with --device,
>> but.. I just don't have spare time right now.)
>>
>> -w
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/devel
>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
> From my view, if you're booting from an ISO already, wouldn't you be
> able to consider that in a state in which you could just do the
> upgrade? Couldn't Anaconda just drive DNF through the upgrade process?
> When you're booting from the ISO, you've already mounted the local
> filesystem and package repositories, so you could use it from there. I
> would figure that DNF is already configured for offline mode during
> anaconda installs as it is (unless, of course, you tell it to grab
> updates from the Internet). Unless I'm missing something really big, I
> don't see why you need to reboot when you're already offline and using
> the Fedora install media boot environment to do an upgrade.

The problem that has plagued updates since RHL-4 in 1997 has been that
updates on the system may and can be of a newer NEVR than what is on
the ISO. This then requires you to be able to have the system online
to download updates and then have space for those updates which at
that point usually ends up meaning you are not gaining much from the
iso.

The usual problem usually ends up being something like: Fedora X and
X+1 have 2 libraries (let us say with the same major.minor numbers at
release time. Then there was a security update which got applied to
the system which means that the ISO has an older major.minor version
than the system. [This is usually something like gzip, gpg or some
other tool] You then either  have to abort the upgrade or do an rpm
-Uvh --force  type of upgrade. Or you have to tell the user that they
need a network connection and space on the system to download various
upgrades to sort out what was needed. However the reason most people
are wanting to upgrade from an ISO is because the system doesn't have
a good network connection and they were hoping to not have to pay for
a multi gigabyte download. Let us just say that a lot of users
complained about this and have done so for the time frame of ISO
updates until it was finally dropped by the anaconda team because they
were sick and tired of trying to deal with it.


>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



-- 
Stephen J Smoogen.
-- 
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: F23 System Wide Change: Default Local DNS Resolver

2015-06-08 Thread Vít Ondruch 
Dne 1.6.2015 v 14:03 Jan Kurik napsal(a):
> = Proposed System Wide Change: Default Local DNS Resolver =
> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
>
>

The "How To Test" section now contains a lot of steps such as "configure
NM", "enable/disable service", but when there will be something which I
can get working just by something like "dnf install localsdnsresolver".
I hope that I won't need to do this steps manually after F23
installation, otherwise it could be hardly called "default". So when
there will be available final version which does not need any additional
configuration available for testing?


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