[Fedocal] Reminder meeting : Fedora 26 Final Release Readiness Meeting

[jkurik]

Dear all,

You are kindly invited to the meeting:
   Fedora 26 Final Release Readiness Meeting on 2017-07-06 from 19:00:00 to 
21:00:00 UTC
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Join us on irc.freenode.net in #fedora-meeting-2 for the Fedora 26
Final Release Readiness Meeting meeting.

We will meet to make sure we are coordinated and ready for the Final
release of Fedora 26. Please note that this meeting is going to be
held even if the release is delayed at the Go/No-Go meeting on the
same day two hours earlier.

You may received this message several times, but it is by purpose to
open this meeting to the teams and to raise awareness, so hopefully
more team representatives will come to this meeting. This meeting
works best when we have representatives from all of the teams.

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

More information available at:
https://fedoraproject.org/wiki/Release_Readiness_Meetings

Thank you for your support and Regards, Jan


Source: https://apps.fedoraproject.org/calendar/meeting/6285/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Test-Announce] Fedora 26 Candidate RC-1.5 Available Now!

[Adam Williamson]

** NOTE ** RC-1.5 is a kind of 'conditional' compose. The sole
difference to RC-1.4 (bar anything that went odd in the compose
process) is the qemu update for
https://bodhi.fedoraproject.org/updates/FEDORA-2017-db0ad12bde . So
aside from virt guest tests, most other results should be transferable
from RC-1.4. Still, at least smoke testing each image would be great.
We may wind up shipping RC-1.4, shipping RC-1.5, or not shipping
either; it'll be decided at the Go/No-Go meeting in the morning.

According to the schedule [1], Fedora 26 Candidate RC-1.5 is now
available for testing. Please help us complete all the validation
testing! For more information on release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/26

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_26_RC_1.5_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_26_RC_1.5_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_26_RC_1.5_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_26_RC_1.5_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_26_RC_1.5_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_26_RC_1.5_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_26_RC_1.5_Security_Lab

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

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

Current Blocker and Freeze Exception bugs:
http://qa.fedoraproject.org/blockerbugs/current

[1] http://fedorapeople.org/groups/schedule/f-26/f-26-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan
[3] https://fedoraproject.org/wiki/Fedora_26_RC_Release_Criteria
[4] irc://irc.freenode.net/fedora-qa
[5] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/
-- 
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
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

cbang build error on epel

[Samuel Rakitničan]

Hi,

I am building CAMotics with cbang builds successfully for i686 and x86_64 
platforms, I am trying to make it work for other architectures, in particular 
armv7 and ppc64 (there is no v8-314 available for others).

So while testing fixes on copr I've stumbled upon an issue of what I am not 
sure about, the build for ppc64le pass for f24-f27 but fails on epel7.

src/cbang/tar/TarHeader.cpp:226:43: error: format '%llo' expects argument of 
type 'long long unsigned int', but argument 4 has type 'uint64_t {aka long 
unsigned int}' [-Werror=format=]
   sprintf(buf, "%0*" PRIo64, length - 1, n);
   ^

copr test: 
https://copr.fedorainfracloud.org/coprs/srakitnican/ppc64le-tests/build/576355/
cbang: https://github.com/CauldronDevelopmentLLC/cbang/

Is this really an issue in cbang?

Best regards,
Samuel Raktiničan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: cbang build error on epel

[Björn 'besser82' Esser]

Am 06.07.2017 um 10:14 schrieb Samuel Rakitničan:

Hi,

I am building CAMotics with cbang builds successfully for i686 and x86_64 
platforms, I am trying to make it work for other architectures, in particular 
armv7 and ppc64 (there is no v8-314 available for others).

So while testing fixes on copr I've stumbled upon an issue of what I am not 
sure about, the build for ppc64le pass for f24-f27 but fails on epel7.

src/cbang/tar/TarHeader.cpp:226:43: error: format '%llo' expects argument of 
type 'long long unsigned int', but argument 4 has type 'uint64_t {aka long 
unsigned int}' [-Werror=format=]
sprintf(buf, "%0*" PRIo64, length - 1, n);
^

copr test: 
https://copr.fedorainfracloud.org/coprs/srakitnican/ppc64le-tests/build/576355/
cbang: https://github.com/CauldronDevelopmentLLC/cbang/

Is this really an issue in cbang?

Best regards,
Samuel Raktiničan


Patch that line to read `sprintf(buf, "%0*" PRIo64, static_castlong unsigned int>(length - 1), n);` and you're cool. It might be 
related to how that particular gcc version in EPEL7 inherits those 
atomic data-types.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Schedule for Thursday's FPC Meeting (YYYY-MM-DD 16:00 UTC)

[Mat Booth]

On 6 July 2017 at 02:40, James Antill  wrote:

>  Following is the list of topics that will be discussed in the FPC
> meeting Thursday at 2017-07-06 16:00 UTC in #fedora-meeting-1 on
> irc.freenode.net.
>
>  Local time information (via. uitime):
>
> = Day: Thursday ==
> 2017-07-06 09:00 PDT  US/Pacific
> 2017-07-06 12:00 EDT  --> US/Eastern <--
> 2017-07-06 16:00 UTC  UTC
> 2017-07-06 17:00 BST  Europe/London
> 2017-07-06 18:00 CEST Europe/Berlin
> 2017-07-06 18:00 CEST Europe/Paris
> 2017-07-06 21:30 IST  Asia/Calcutta
>  New Day: Friday -
> 2017-07-07 00:00 HKT  Asia/Hong_Kong
> 2017-07-07 00:00 +08  Asia/Singapore
> 2017-07-07 01:00 JST  Asia/Tokyo
> 2017-07-07 02:00 AEST Australia/Brisbane
>
>  Links to all tickets below can be found at:
>
> https://pagure.io/packaging-committee/issues?status=Open&tags=meeting
>
> = Followups =
>
> #topic #691 noarch *sub*packages with arch-specific dependencies
> .fpc 691
> https://pagure.io/packaging-committee/issue/691
>
> #topic #693 Wiki:Packaging:RPMMacros
> .fpc 693
> https://pagure.io/packaging-committee/issue/693
>
> = Open Floor =
>
>  For more complete details, please visit each individual ticket.  The
> report of the agenda items can be found at:
>
> https://pagure.io/packaging-committee/issues?status=Open&tags=meeting
>
>  If you would like to add something to this agenda, you can reply to
> this e-mail, file a new ticket at https://fedorahosted.org/fpc,
> e-mail me directly, or bring it up at the end of the meeting, during
> the open floor topic. Note that added topics may be deferred until
> the following meeting.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>

I will not be at today's meeting 

-- 
Mat Booth
http://fedoraproject.org/get-fedora
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

some help needed with requires issue in spec file for pyproj

[Jos de Kloe]

something strange happened in my recent pyproj build on rawhide which
causes all relevant requires to be lost, see:

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

I tried to find a solution or workaround, but without succes.
When I do a local mock build the same problem arises.

I tried to activate some debug options on mock, but even adding
   " --verbose --rpmbuild-opts='-vv' "
did not give me anymore details on the process used to find the
requires. This is the only output I see for the python3 sub-package  in
my local mock build when all these debug options are active:

...
Finding  Requires(interp):
Finding  Requires(rpmlib):
Finding  Requires(verify):
Finding  Requires(pre):
Finding  Requires(post):
Finding  Requires(preun):
Finding  Requires(postun):
Finding  Requires(pretrans):
Finding  Requires(posttrans):
Finding  Requires: /bin/sh -c "  while read FILE; do echo "${FILE}" |
/usr/lib/rpm/rpmdeps -R; done | /bin/sort -u "
Finding  Conflicts:
Finding  Obsoletes:
Finding  Recommends:
Finding  Suggests:
Finding  Supplements:
Finding  Enhances:
Provides: python3-pyproj = 1.9.5.1-7.fc27 python3-pyproj(x86-64) =
1.9.5.1-7.fc27
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Processing files: pyproj-debuginfo-1.9.5.1-7.fc27.x86_64
Provides: pyproj-debuginfo = 1.9.5.1-7.fc27 pyproj-debuginfo(x86-64) =
1.9.5.1-7.fc27
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
...

While it should have requires on python3, proj-nad and proj-epsg

rpm confirms the problem:

rpm -q --requires -p
/var/lib/mock/fedora-rawhide-x86_64/result/python3-pyproj-1.9.5.1-7.fc27.x86_64.rpm
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
[end of output]

Adding explicit requires to python2 and python3 in the general
definitions in the top of the spec file or in the sub-package
definitions does not help.

Basically I have no clue what else I code do to debug this.
If anyone has an idea I would much appreciate to hear it.

Best regards,

Jos
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: some help needed with requires issue in spec file for pyproj

[Björn 'besser82' Esser]

Am 06.07.2017 um 12:03 schrieb Jos de Kloe:

something strange happened in my recent pyproj build on rawhide which
causes all relevant requires to be lost, see:

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

I tried to find a solution or workaround, but without succes.
When I do a local mock build the same problem arises.

I tried to activate some debug options on mock, but even adding
" --verbose --rpmbuild-opts='-vv' "
did not give me anymore details on the process used to find the
requires. This is the only output I see for the python3 sub-package  in
my local mock build when all these debug options are active:

...
Finding  Requires(interp):
Finding  Requires(rpmlib):
Finding  Requires(verify):
Finding  Requires(pre):
Finding  Requires(post):
Finding  Requires(preun):
Finding  Requires(postun):
Finding  Requires(pretrans):
Finding  Requires(posttrans):
Finding  Requires: /bin/sh -c "  while read FILE; do echo "${FILE}" |
/usr/lib/rpm/rpmdeps -R; done | /bin/sort -u "
Finding  Conflicts:
Finding  Obsoletes:
Finding  Recommends:
Finding  Suggests:
Finding  Supplements:
Finding  Enhances:
Provides: python3-pyproj = 1.9.5.1-7.fc27 python3-pyproj(x86-64) =
1.9.5.1-7.fc27
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Processing files: pyproj-debuginfo-1.9.5.1-7.fc27.x86_64
Provides: pyproj-debuginfo = 1.9.5.1-7.fc27 pyproj-debuginfo(x86-64) =
1.9.5.1-7.fc27
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
...

While it should have requires on python3, proj-nad and proj-epsg

rpm confirms the problem:

rpm -q --requires -p
/var/lib/mock/fedora-rawhide-x86_64/result/python3-pyproj-1.9.5.1-7.fc27.x86_64.rpm
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
[end of output]

Adding explicit requires to python2 and python3 in the general
definitions in the top of the spec file or in the sub-package
definitions does not help.

Basically I have no clue what else I code do to debug this.
If anyone has an idea I would much appreciate to hear it.

Best regards,

Jos


It looks to me like you are using the old and discouraged / deprecated 
`%filter_setup` macro stuff, valid for EPEL <= 6, only…


You should upgrade the way filtering is used:

%if 0%{?fedora} || 0%{?rhel} >= 7
# Do not check any files in docdir for requires
%global __requires_exclude_from ^%{_docdir}/.*$

# Do not check .so files in the python2_sitearch directory
# or any files in the application's directory for provides
%global __provides_exclude_from 
^(%{python2_sitearch}/.*\\.so|%{_datadir}/myapp/.*)$

%else
{previous %filter_setup macro for EPEL <= 6 stuff goes here}
%endif

If you need help to get that setup correctly, feel free to ask me.

Cheers,
  Björn
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: some help needed with requires issue in spec file for pyproj

[Björn 'besser82' Esser]

Am 06.07.2017 um 12:22 schrieb Björn 'besser82' Esser:

Am 06.07.2017 um 12:03 schrieb Jos de Kloe:

something strange happened in my recent pyproj build on rawhide which
causes all relevant requires to be lost, see:

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

I tried to find a solution or workaround, but without succes.
When I do a local mock build the same problem arises.

I tried to activate some debug options on mock, but even adding
" --verbose --rpmbuild-opts='-vv' "
did not give me anymore details on the process used to find the
requires. This is the only output I see for the python3 sub-package  in
my local mock build when all these debug options are active:

...
Finding  Requires(interp):
Finding  Requires(rpmlib):
Finding  Requires(verify):
Finding  Requires(pre):
Finding  Requires(post):
Finding  Requires(preun):
Finding  Requires(postun):
Finding  Requires(pretrans):
Finding  Requires(posttrans):
Finding  Requires: /bin/sh -c "  while read FILE; do echo "${FILE}" |
/usr/lib/rpm/rpmdeps -R; done | /bin/sort -u "
Finding  Conflicts:
Finding  Obsoletes:
Finding  Recommends:
Finding  Suggests:
Finding  Supplements:
Finding  Enhances:
Provides: python3-pyproj = 1.9.5.1-7.fc27 python3-pyproj(x86-64) =
1.9.5.1-7.fc27
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Processing files: pyproj-debuginfo-1.9.5.1-7.fc27.x86_64
Provides: pyproj-debuginfo = 1.9.5.1-7.fc27 pyproj-debuginfo(x86-64) =
1.9.5.1-7.fc27
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
...

While it should have requires on python3, proj-nad and proj-epsg

rpm confirms the problem:

rpm -q --requires -p
/var/lib/mock/fedora-rawhide-x86_64/result/python3-pyproj-1.9.5.1-7.fc27.x86_64.rpm 


rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
[end of output]

Adding explicit requires to python2 and python3 in the general
definitions in the top of the spec file or in the sub-package
definitions does not help.

Basically I have no clue what else I code do to debug this.
If anyone has an idea I would much appreciate to hear it.

Best regards,

Jos


It looks to me like you are using the old and discouraged / deprecated 
`%filter_setup` macro stuff, valid for EPEL <= 6, only…


You should upgrade the way filtering is used:

%if 0%{?fedora} || 0%{?rhel} >= 7
# Do not check any files in docdir for requires
%global __requires_exclude_from ^%{_docdir}/.*$

# Do not check .so files in the python2_sitearch directory
# or any files in the application's directory for provides
%global __provides_exclude_from 
^(%{python2_sitearch}/.*\\.so|%{_datadir}/myapp/.*)$

%else
{previous %filter_setup macro for EPEL <= 6 stuff goes here}
%endif

If you need help to get that setup correctly, feel free to ask me.

Cheers,
  Björn


For further reference, see: 
https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: some help needed with requires issue in spec file for pyproj

[Björn 'besser82' Esser]

Am 06.07.2017 um 12:24 schrieb Björn 'besser82' Esser:


Am 06.07.2017 um 12:22 schrieb Björn 'besser82' Esser:

Am 06.07.2017 um 12:03 schrieb Jos de Kloe:

something strange happened in my recent pyproj build on rawhide which
causes all relevant requires to be lost, see:

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

I tried to find a solution or workaround, but without succes.
When I do a local mock build the same problem arises.

I tried to activate some debug options on mock, but even adding
" --verbose --rpmbuild-opts='-vv' "
did not give me anymore details on the process used to find the
requires. This is the only output I see for the python3 sub-package  in
my local mock build when all these debug options are active:

...
Finding  Requires(interp):
Finding  Requires(rpmlib):
Finding  Requires(verify):
Finding  Requires(pre):
Finding  Requires(post):
Finding  Requires(preun):
Finding  Requires(postun):
Finding  Requires(pretrans):
Finding  Requires(posttrans):
Finding  Requires: /bin/sh -c "  while read FILE; do echo "${FILE}" |
/usr/lib/rpm/rpmdeps -R; done | /bin/sort -u "
Finding  Conflicts:
Finding  Obsoletes:
Finding  Recommends:
Finding  Suggests:
Finding  Supplements:
Finding  Enhances:
Provides: python3-pyproj = 1.9.5.1-7.fc27 python3-pyproj(x86-64) =
1.9.5.1-7.fc27
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Processing files: pyproj-debuginfo-1.9.5.1-7.fc27.x86_64
Provides: pyproj-debuginfo = 1.9.5.1-7.fc27 pyproj-debuginfo(x86-64) =
1.9.5.1-7.fc27
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
...

While it should have requires on python3, proj-nad and proj-epsg

rpm confirms the problem:

rpm -q --requires -p
/var/lib/mock/fedora-rawhide-x86_64/result/python3-pyproj-1.9.5.1-7.fc27.x86_64.rpm 


rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
[end of output]

Adding explicit requires to python2 and python3 in the general
definitions in the top of the spec file or in the sub-package
definitions does not help.

Basically I have no clue what else I code do to debug this.
If anyone has an idea I would much appreciate to hear it.

Best regards,

Jos


It looks to me like you are using the old and discouraged / 
deprecated `%filter_setup` macro stuff, valid for EPEL <= 6, only…


You should upgrade the way filtering is used:

%if 0%{?fedora} || 0%{?rhel} >= 7
# Do not check any files in docdir for requires
%global __requires_exclude_from ^%{_docdir}/.*$

# Do not check .so files in the python2_sitearch directory
# or any files in the application's directory for provides
%global __provides_exclude_from 
^(%{python2_sitearch}/.*\\.so|%{_datadir}/myapp/.*)$

%else
{previous %filter_setup macro for EPEL <= 6 stuff goes here}
%endif

If you need help to get that setup correctly, feel free to ask me.

Cheers,
  Björn


For further reference, see: 
https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering


I've just fixed the filtering of the provides for all recent distros and 
pushed updates.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: some help needed with requires issue in spec file for pyproj

[Jos de Kloe]

Hi Björn,

On 07/06/2017 12:22 PM, Björn 'besser82' Esser wrote:
> Am 06.07.2017 um 12:03 schrieb Jos de Kloe:
...
> It looks to me like you are using the old and discouraged / deprecated
> `%filter_setup` macro stuff, valid for EPEL <= 6, only…
> 
> You should upgrade the way filtering is used:
> 
> %if 0%{?fedora} || 0%{?rhel} >= 7
> # Do not check any files in docdir for requires
> %global __requires_exclude_from ^%{_docdir}/.*$
> 
> # Do not check .so files in the python2_sitearch directory
> # or any files in the application's directory for provides
> %global __provides_exclude_from
> ^(%{python2_sitearch}/.*\\.so|%{_datadir}/myapp/.*)$
> %else
> {previous %filter_setup macro for EPEL <= 6 stuff goes here}
> %endif
> 
> If you need help to get that setup correctly, feel free to ask me.
> 
> Cheers,
>   Björn

thanks a lot for your quick response and solution !

Still, the explicit requires for proj-nad and proj-epsg seem to get
lost. Is this related or something different?

More general: what tools/methods can be used to debug this?

Best regards,

Jos
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: some help needed with requires issue in spec file for pyproj

[Björn 'besser82' Esser]

Am 06.07.2017 um 13:09 schrieb Jos de Kloe:

Hi Björn,

On 07/06/2017 12:22 PM, Björn 'besser82' Esser wrote:

Am 06.07.2017 um 12:03 schrieb Jos de Kloe:

...

It looks to me like you are using the old and discouraged / deprecated
`%filter_setup` macro stuff, valid for EPEL <= 6, only…

You should upgrade the way filtering is used:

%if 0%{?fedora} || 0%{?rhel} >= 7
# Do not check any files in docdir for requires
%global __requires_exclude_from ^%{_docdir}/.*$

# Do not check .so files in the python2_sitearch directory
# or any files in the application's directory for provides
%global __provides_exclude_from
^(%{python2_sitearch}/.*\\.so|%{_datadir}/myapp/.*)$
%else
{previous %filter_setup macro for EPEL <= 6 stuff goes here}
%endif

If you need help to get that setup correctly, feel free to ask me.

Cheers,
   Björn

thanks a lot for your quick response and solution !

Still, the explicit requires for proj-nad and proj-epsg seem to get
lost. Is this related or something different?

More general: what tools/methods can be used to debug this?

Best regards,

Jos


Hi Jos,

you're welcome!  =)

Yes, that is because they have not been explicitly specified in the two 
sub-packages…  Each sub-package has it's very own Requires / Provides 
and doesn't inherit them from the main package.


I've moved all stuff into the right place, so it should be fine now.

Well I don't know about any automatic tools for that, but generally just 
looking into the spec file, checking where those are specified is the 
way to go.


Cheers,
  Björn
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Review swap

[Gwyn Ciesla]

On Wed, Jul 5, 2017 at 7:44 PM, Ben Cotton 
wrote:

> Hi Gwyn,
>
> I'll take this in exchange for wordgrinder:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1460246
>
> On Wed, Jul 5, 2017 at 2:14 PM, Gwyn Ciesla  wrote:
> > I just submitted python-slackclient:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1467995
> >
> > Willing to do one of yours.
> >
> > Thanks!
> >
> > -G
> >
> > --
> > http://cecinestpasunefromage.wordpress.com/
> > 
> > in your fear, seek only peace
> > in your fear, seek only love
> >
> > -d. bowie
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >
>
> Excellent, thank you!
>
> --
> Ben Cotton
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: some help needed with requires issue in spec file for pyproj

[Jos de Kloe]

On 07/06/2017 01:53 PM, Björn 'besser82' Esser wrote:
> Am 06.07.2017 um 13:09 schrieb Jos de Kloe:
>> Hi Björn,
>>
>> On 07/06/2017 12:22 PM, Björn 'besser82' Esser wrote:
>>> Am 06.07.2017 um 12:03 schrieb Jos de Kloe:
>> ...
>>> It looks to me like you are using the old and discouraged / deprecated
>>> `%filter_setup` macro stuff, valid for EPEL <= 6, only…
>>>
>>> You should upgrade the way filtering is used:
>>>
>>> %if 0%{?fedora} || 0%{?rhel} >= 7
>>> # Do not check any files in docdir for requires
>>> %global __requires_exclude_from ^%{_docdir}/.*$
>>>
>>> # Do not check .so files in the python2_sitearch directory
>>> # or any files in the application's directory for provides
>>> %global __provides_exclude_from
>>> ^(%{python2_sitearch}/.*\\.so|%{_datadir}/myapp/.*)$
>>> %else
>>> {previous %filter_setup macro for EPEL <= 6 stuff goes here}
>>> %endif
>>>
>>> If you need help to get that setup correctly, feel free to ask me.
>>>
>>> Cheers,
>>>Björn
>> thanks a lot for your quick response and solution !
>>
>> Still, the explicit requires for proj-nad and proj-epsg seem to get
>> lost. Is this related or something different?
>>
>> More general: what tools/methods can be used to debug this?
>>
>> Best regards,
>>
>> Jos
> 
> Hi Jos,
> 
> you're welcome!  =)
> 
> Yes, that is because they have not been explicitly specified in the two
> sub-packages…  Each sub-package has it's very own Requires / Provides
> and doesn't inherit them from the main package.
> 
> I've moved all stuff into the right place, so it should be fine now.
> 
> Well I don't know about any automatic tools for that, but generally just
> looking into the spec file, checking where those are specified is the
> way to go.
> 
> Cheers,
>   Björn

Again thanks for your help.
I clearly overlooked the 'no-inheritance' part.
This for sure is not mentioned clearly in
https://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires

Anyway, one thing still puzzles me.
You put the proj-nad and proj-epsg requires in both sub-packages now,
and clearly this works well.
However, the BuildRequires on proj-nad and proj-epsg are still in the
generic section, so does this mean they are inherited by the
sub-packages but Requires are not? This seems rather inconsistent to me.

Cheers,

Jos
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: some help needed with requires issue in spec file for pyproj

[Michael Schwendt]

On Thu, 6 Jul 2017 14:33:21 +0200, Jos de Kloe wrote:

> Anyway, one thing still puzzles me.
> You put the proj-nad and proj-epsg requires in both sub-packages now,
> and clearly this works well.
> However, the BuildRequires on proj-nad and proj-epsg are still in the
> generic section, so does this mean they are inherited by the
> sub-packages but Requires are not? This seems rather inconsistent to me.

BuildRequires are per spec file / src.rpm, not per subpackage.
You may add them anywhere within the spec file, but they will be
global unless contained within conditional section.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 Self Contained Change: Samba AD

[Alexander Bokovoy]

On ma, 03 heinä 2017, Dario Lesca wrote:

Il giorno lun, 03/07/2017 alle 09.29 +0300, Alexander Bokovoy ha
scritto:

> When the firs (beta) F27 + samba 4.7 AD will be release, I will try
> the upgrade on a test virtual environment.

Sure!


Thanks!
I'll let you know

So, we pushed 4.7.0-RC1 to Rawhide. Also, asn/samba_ad_dc COPR repo
contains a rebuild for F25 and F26. Feel free to test that.

Note that right now FreeIPA in rawhide (and other Fedora versions) is
not binary compatbile with Samba 4.7.0. One needs to use 
https://github.com/freeipa/freeipa/pull/901 patchset to FreeIPA git

master to fix incompatibilities. Hopefully, this patchset will get
merged next week and we'll be able to get rawhide to a working state.

I think in mid-August we can run a Test Day too.

--
/ Alexander Bokovoy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F27 System Wide Change: 32 bit UEFI Support

[Jaroslav Reznik]

= System Wide Change: 32 bit UEFI Support =
https://fedoraproject.org/wiki/Changes/32BitUefiSupport

Change owner(s):
Peter Jones 

Some x86 systems ship with a 64 bit CPU, but 32 bit UEFI firmware. It
is possible to use a 32 bit UEFI grub build to boot a 64 bit kernel
and distribution on these systems. So far this setup has not been
supported in Fedora. This feature is about adding support for
installing and booting Fedora on this hardware.

== Detailed Description ==
To add support for booting Fedora x86_64 on x86 systems with 32 bit
UEFI firmware a number of (small) changes to grub, various EFI related
userspace tools and anaconda are necessary. See Scope for more
details.

== Scope ==
* Proposal owners:
** The x86_64 grub2 packages will need to include an extra grub build,
next to the current classic BIOS and 64 bit UEFI build a new 32 bit
UEFI build will be added to the x86_64 packages.
** This new grub will need to be added to the various x86_64 boot media
** A few EFI userspace utilities need to be updated to work with 32 bit x86 UEFI
** The installer (anaconda) needs some changes to the bootloader
installation code to install the 32 bit UEFI grub binary

* Other developers:

No changes are necessary outside of the affected packages

* Release engineering: [1]
** List of deliverables:
This feature should be enabled on all non cloud/container x86_64 images

* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)

[1] https://pagure.io/releng/issue/6879

Thanks,
Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Test-Announce] Fedora 26 Candidate RC-1.4 Available Now!

[Matthew Miller]

On Wed, Jul 05, 2017 at 03:04:36PM -0600, Chris Murphy wrote:
> Nope. This came up last cycle or two where compose had a weird bug
> preventing umount of the installation root fs image file, resulting in
> a corrupt file system and ensuing boot failure of the ISO. And
> actually there were some non-release blocking images that we simply
> did not ship because of those failures, and they were not respun, and
> releng said we couldn't even use a prior successfully built ISO.

I believe we ended up linking to a nightly on the spins or labs
website. These don't get a lot of downloads so it's not super-important
that they be on the mirrors.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Test-Announce] Fedora 26 Candidate RC-1.4 Available Now!

[Matthew Miller]

On Wed, Jul 05, 2017 at 02:33:01PM -0700, Adam Williamson wrote:
> With Pungi 4 we really can't do that any more. Composes have a much
> more solid identity as an actual thing. 'A compose' has a compose ID,
> production composes have a label, and these can't really be duplicated.
> There is a bunch of metadata which is produced for the compose *as a
> whole*; if we do a compose where we try 10 images and 1 fails, the
> metadata for that compose will list 9 images. If we then ran another
> compose just to produce that 1 missing image (with properties as
> similar as possible to the original compose), the metadata for the new

I understand the value of having something that is an authoritative
source of truth about release artifacts. I'm not sure at all about the
value of having The Compose like this. Especially since we already do
things like assuming that tests which apply to RC 1.4 are probably good
for 1.5 since we know none of the relevant packages have changed. I
guess we could solve this with another layer of abstraction: a
super-compose which could include artifacts from various composes or
other compose-like sources.

> script or something, both of which would be error-prone). It's also not
> actually that easy just to respin a single image; Pungi 4 isn't really
> built to do that (you'd have to create a new Pungi compose config file
> each time you wanted to do it), and releng really doesn't want to do it
> manually below the Pungi level any more in case of inconsistencies or
> errors.

Maybe that just means it needs to be easier to create and update pungi
compose configs?

> However, as I said before, we *do* have some ways we can unofficially
> provide 'missing' images. They just can't be a full part of the
> official release.

But they can still be "official Fedora" even if not part of an
"official release".

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F27 Self Contained Change: VirtualBox Guest Integration

[Jaroslav Reznik]

= Proposed Self Contained Change: VirtualBox Guest Integration =
https://fedoraproject.org/wiki/Changes/VirtualBox_Guest_Integration

Change owner(s):
* Hans de Goede 

VirtualBox is popular, easy to use virtual-machine software. The
purpose of this change is to ship the VirtualBox guest-drivers and
-tools by default in the Fedora workstation product.

== Detailed Description ==
VirtualBox runs on Windows. MacOS and Linux and is used by many users
to try it Linux for the first time. As such it is important for Fedora
to work well in VirtualBox virtual-machines. Like other
virtual-machines VirtualBox virtual-machines can offer an enhanced
user-experience when some VirtualBox specific guest-drivers and
guest-tools are installed. This change is about adding the
guest-drivers to the Fedora kernel package, packaging the
userspace-tools (VirtualBox Guest Additions) and adding the VirtualBox
Guest Additions package to the default package list for the
Workstation product.

== Scope ==
* Proposal owners:

** Adding the VirtualBox guest drivers to the kernel package. To make
this happen work is underway to clean them up and submit them
upstream.
** Package VirtualBox Guest Additions userspace parts
** Add VirtualBox Guest Additions package to the default package list
for the Workstation product

* Other developers:
N/A (not a System Wide Change)

* Release engineering: [1]

* List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)

[1] https://pagure.io/releng/issue/6880

Thanks,
Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F27 System Wide Change: The GNU C Library version 2.26

[Jaroslav Reznik]

= System Wide Change: The GNU C Library version 2.26 =
https://fedoraproject.org/wiki/Changes/GLIBC226

Change owner(s):
* Carlos O'Donell 

Switch glibc in Fedora 27 to glibc version 2.26.

== Detailed Description ==
The GNU C Library version 2.26 will be released at the beginning of
August 2017; we have started closely tracking the glibc 2.26
development code in Fedora Rawhide and are addressing any issues as
they arise. Given the present schedule Fedora 27 will branch after the
GLIBC 2.26 upstream release. However, the mass rebuild schedule means
Fedora 27 will mass rebuild just after GLIBC 2.26 upstream freezes ABI
for release, so careful attention must be paid to any last minute ABI
changes.

== Scope ==
* Proposal owners: Update glibc to 2.26 from tested upstream release.

* Other developers: Developers need to ensure that rawhide is stable
and ready for the Fedora 27 branch. Given that glibc is backwards
compatible and we have been testing the new glibc in rawhide it should
make very little impact when updated.

* Release engineering: [1] All Fedora releases must be released using
a released version of glibc. The Fedora glibc team is responsible for
ensuring that Fedora Rawhide stabilizes ABI before a Fedora release,
or that after the branch that the Fedora release is rebased (a very
small rebase) to the final released version. This is a requirement for
Fedora to inherit the ABI and API guarantees provided by upstream. If
a mass rebuild is required by glibc or other components, the Fedora
glibc team will ensure coordination with release engineering such that
a mass rebuild uses the released version of glibc to fix any last
minute ABI changes. The GNU C Library (glibc) does not require a mass
rebuild for this release.

* List of deliverables: all

* Policies and guidelines: The policies and guidelines do not need to
be updated.

* Trademark approval: N/A (not needed for this Change)

[1] https://pagure.io/releng/issue/6890

Thanks,
Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F27 System Wide Change: Graphical Applications as Flatpaks

[Jaroslav Reznik]

= System Wide Change: Graphical Applications as Flatpaks =
https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks

Change owner(s):
* Owen Taylor 

This change is to enable package maintainers to build Flatpaks of
their applications and make those Flatpaks available for installation.

== Detailed Description ==

See Workstation/Flatpaks [1] for the full development plan.

The goal of this change is make Flatpaks available as a distribution
mechanism for software packaged in Fedora.

Multiple Flatpaks on the system can share a runtime of common
libraries. There will be a single Fedora runtime maintained on the
same schedule as the Platform module for Fedora. It will be be defined
as a module that includes libraries that are commonly used for
graphical applications. Some of these will inherit from the Platform
module.

Applications then bundle the code for the application itself and for
additional libraries they depend on beyond the base runtime. Each
application has its own module in which the relevant RPMs are rebuilt
with a special RPM macros (in the flatpak-rpm-macros package) to
relocate the application and bundled libraries into the /app prefix.
(This is necessary, because inside an executing Flatpak, the
application is mounted at /app, and the runtime at /usr)

The packages are then composed into Flatpaks by the layered image
service, sharing as much of the workflow and code as possible with
containers. While the native delivery mechanism for Flatpaks is as an
ostree repository, they can also be distributed as OCI images, and our
goal is to use this format during the build process, and to distribute
them to users via registry.fedoraproject.com.

Automation of rebuilds and integration with Bodhi will also be needed
to make sure that security and bug-fix updates to packages end up
being distributed to users. This part is least specified at the
current time, and full automation may not be achievable for Fedora 27.
If the above plan is followed, most of this work is shared with work
needed for modularity in general and for server-side containers.

== Scope ==
* Proposal owners: (f27)
** Create and maintain a flatpak-runtime module
** Provide tools for application authors to use to create module
descriptions for their flatpaks
** Provide patches for the container build pipeline (atomic reactor
and friends) to build flatpaks as well as containers
** Create some way to get summary information for all flatpaks on
registry.fedoraproject.org; this might be a patch to the codebase, a
look-aside file, or a separate service.
** Modify flatpak and gnome-software so that flatpaks can be installed
from registry.fedoraproject.org.

* Proposal owners: (f28)
** Provide a "SDK" profile of the flatpak-runtime module to create a
Flatpak SDK for third-party non-RPM builds against the SDK using
flatpak-builder

* Other developers: (f27)
** Provide exports of built modules as repositories (the "On Demand
Compose Service")
** Provide some reasonably self-service way for packagers to create
modules without a lot of overhead. (Does it make sense to allow
''application modules'' where when a package corresponds one-to-one to
a module to allow the modulemd to live in dist-git next to the spec
file?)
** Allow Fedora packagers to submit module builds
** Allow uploading OCI images to registry.fedoraproject.org Upstream
pull request [2]
** Make sure that Bodhi updates can be submitted for Flatpaks/OCI
Images in the same way as for Docker containers (no significant code
changes are expected beyond the current work to enable multiple types
of Bodhi updates.)

* Other developers: (f28)
** Create a unified workflow for package and container/flatpak updates
(detailed plan to be developed, something like:)
*** updates submitted to bodhi for a package should trigger automatic
module and container/flatpak builds
*** Pushing a package to stable should push the updated flatpaks/containers
*** the Bodhi user interface should show modules/containers that
include a package and their status

* Release engineering: [3] (a check of an impact with Release
Engineering is needed)
** List of deliverables: Most likely, runtime and applications would
not be part of the deliverables list. However, we will need to
consider the quality of the runtime and applications as part of the
overall quality of release - if some common application did not run on
upgrade that would seriously affect users. This should, as much as
possible, be addressed through continuous automated testing.

* Policies and guidelines: The people working on this change will need
to work closely in the development of module guidelines, and make sure
that Flatpak specifics are documented as well (for example,
documenting the creation of a 'flatpak.json' with permissions and
other metadata for the Flatpak). It's possible some changes will be
needed to the packaging guidelines to make sure that all relevant
packages relocate to /app properly, but it's expected that most
packa

Re: F27 Self Contained Change: VirtualBox Guest Integration

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jul 06, 2017 at 04:10:29PM +0200, Jaroslav Reznik wrote:
> = Proposed Self Contained Change: VirtualBox Guest Integration =
> https://fedoraproject.org/wiki/Changes/VirtualBox_Guest_Integration
> 
> Change owner(s):
> * Hans de Goede 
> 
> VirtualBox is popular, easy to use virtual-machine software. The
> purpose of this change is to ship the VirtualBox guest-drivers and
> -tools by default in the Fedora workstation product.

Please make sure when running on non-VirtualBox machines the
drivers and services are not loaded and there are no warnings emitted.
(I know we've had similar problems before — e.g.
https://bugzilla.redhat.com/show_bug.cgi?id=999804, and some other
bugs I cannot find now, so I'm just saying that this is something
worth checking for from the start.)
Probably the right solution is to use a udev rule to trigger starting
of various services only if the "devices" are found. Something like
/usr/lib/udev/rules.d/70-spice-vdagentd.rules in spice-vdagent.rpm.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Modularity] A proposal for stream naming

[langdon]

On 06/29/2017 01:40 PM, Matthew Miller wrote:

On Thu, Jun 29, 2017 at 07:20:15PM +0200, Petr Šabata wrote:

* Such modules MAY additionally have a "latest" stream, which
   would be "rolling release" of the latest stable version (as
   opposed to master, which corresponds to rawhide and may be
   unstable).

Sounds like the no-more-alphas Rawhide.  Such "latest" streams
would drop major changes/rebases on the end users' systems.
It makes sense to have this, especially for developers, but
we should warn people that it's not the best choice for stable
systems and that... it will eat their babies ;)

No, this should definitely not eat babies. (Even Rawhide doesn't do
that anymore. Usually.) And while automatic gating would be fine, it
wouldn't need to be.

Given the response above it appears you understand streams
somewhat differently.  Until now we've been operating with
the assumption (and everything is coded that way) that streams
map directly to branch names.  If you have a "latest" stream,
you develop it in a branch called "latest".  If a user consumes
this stream, their automatically get breaking changes because
the "latest stable version" means different things at different
times.  Hence the comparison to Rawhide.

It might be somewhat comparable to rawhide, but it definitely shouldn't
be _called_ rawhide, because that implies a tie to either rawhide as it
stands today or a rawhide version of the platform+host. Doesn't it?



Are they bound to the artifact or could that depend on the
context?  Like "this module will go EOL next year for standard
Fedora and nobody will care to make it work with the latest
Platform but we'll still support it in the context of this LTS
spin / derived distro / whatnot".

If this is a thing, modularity hasn't really succeeded.

I don't know how to respond to this.

The point of modularity is to separate application and stack lifecycle
from the platform. If we end up with per-platform application and stack
lifecycles in the end, that point isn't achieved at all.



This is partly why I described EOL as "EOL no earlier than" (thanks to
Langdon). I think the best thing to do in the case of a long extension
would be to create a new branch/stream with the new EOL. That's part of
why I think modules need to carry their own succession information,
too.

Making people switch between update streams if the content they
already consume becomes supported for longer doesn't feel like
the best UX decision.  EOL shouldn't be tied to stream names.

Ok, I'm convinced on that point. But, EOL shouldn't be changed lightly,
either. Users (and spin/edition creators) should be able to trust
lifecycle statements.



current design. I guess one option would be for master to automatically
correspond to "latest major version, rolling release", but that
seems not as helpful as being explicit. Maybe "master" should just
contain a readme describing the various branches.

Works for me.  Right now we use it for random development but
that's because we're just starting with all this.

Is this something that could/should be enforced by policy in MBS?


We actually have some tests in place that enforce some policy (very 
lightly at the moment). However, the goal is that whatever we determine 
to be "true" in the modularity guidelines is enforced by a system-wide 
test(s) on modules whenever they are built. This would be a gating test 
where any exceptions to the guideline would have to be registered in the 
"waiver system" (which I can't remember the name of in factory).


Langdon

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Modularity] A proposal for stream naming

[langdon]

On 06/29/2017 11:27 AM, Josh Boyer wrote:

On Thu, Jun 29, 2017 at 11:19 AM, Matthew Miller
  wrote:

On Thu, Jun 29, 2017 at 03:26:50PM +0200, Petr Šabata wrote:

I have an alternate idea too: "collection" type modules would
use arbitrary integer versions starting with 1 and increase only if the
content undergoes a major switch. ALL module streams would contain EOL
information after the version number separated by a ":". This EOL info
would be a date as above, or the string "latest", _or_ the string
"stable", indicating that no abi-breaking changes are expected ever and
that we basically have no known EOL.

I like simple integer approach and it feels natural from an
engineer's point of view.  I think.  I can also imagine using
years or years.months, depending on how often the module
maintainer decides to release a new... thing.

Like "tools 2017", "tools 2017.6".  *shrugs*
But I don't really have a preference.

I wouldn't include EOL directly in the stream (i.e. branch)
name but I totally agree it needs to be prominently displayed
in any user interface that deals with modules.  No matter where
the tools get it from.

I really, really don't want anyone creating new modules without
considering lifecycle. Forcing it into the stream name is:

I agree with lifecycle being required.  I disagree completely with it
being in the stream name.  It doesn't make sense at all for a large
variety of reasons.  It's a cheap hack to get what you really want,
and I think it's just going to incur technical debt we should avoid in
the first place.

Modularity is new.  It's different.  It will be hard at first.  Let's
not hamstring ourselves from the start.

josh
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org


As I said to Matt on IRC, I agree with the point that metadata should 
*not* be encoded in "yet another string" like "name" has been used for a 
long time. We need to be very careful of this problem as it is 
*incredibly* tempting to use our years of experience with doing this to 
basically introduce the problem again. We need to add metadata labels 
for new metadata when we need it. We need to try VERY hard not to use 
any string to hold more than one piece of metadata. TBH, I fell in to 
that trap myself when first talking about it to Matt.


I also am not the biggest fan of the "stream" being a user-defined 
thing, rather, I wish it could be something that is more like a computed 
amalgamation of the other metadata (this is kinda what Nix does). 
However, I am still on the fence on this. Stream != name.. and name is 
where "lamp with httpd" kinda belongs.


As I said in another part of the thread (/me hates thread splitting), we 
fully expect to have guideline enforcement gating release of modules. We 
can very easily require that EOL be provided (whether it be modulemd, 
pdc, or something else) as part of that test. In fact, we have planned 
for it to be there all along and prominently displayed in UX tools (one 
of the very early dev topics). However, the problem of "how to store it" 
has come up multiple times because it is HARD. I am also not sure EOL is 
something we can just plop in somewhere and then fix it later. So, your 
concerns are very valid and well understood, we just haven't figured out 
exactly how to solve it. Current plan is PDC along with SLA but I would 
need to follow up with Ralph, et al to know if that part got implemented 
yet.


Langdon
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F27 System Wide Change: NSS Default File Format SQL

[Jaroslav Reznik]

= System Wide Change: NSS Default File Format SQL =
https://fedoraproject.org/wiki/Changes/NSSDefaultFileFormatSql

Change owner(s):
* Kai Engert 

Change the NSS library default to use the sqlite based data storage,
when applications don't specify their preferred storage file format.

== Detailed Description ==

Applications that use the NSS library often use a database for storage
of keys, certificates and trust. NSS supports two different file
formats, one called DBM (based on berkeley DB files) and another one
called SQL (based on sqlite DB files).

Today's default file format used by NSS, used when applications omit
the type parameter, is the older DBM file format, which forbids
parallel access to the storage. The suggestion is to change the
default file format to SQL, which allows parallel access to the
storage.

Applications, or users using the NSS command line utilities, often
provide the database storage location using a simple directory path
parameter. Some might not be aware, or forget, that the parameter can
be prefixed with a type modifier, either "dbm:" or "sql:".

As a result, when not providing this parameter, the file format used
will be the fragile DBM file format. This is particuarly problematic,
if a user attempts to modify the NSS storage using command line tools,
while another process, such as a daemon, is running concurrently,
which also accesses the same database in the DBM file format. This
often results in corrupted database storage, which cannot be
recovered.

By changing the default, all applications that currently use the DBM
file format, will automatically be migrated to the SQL file format.
NSS has the ability to discover if a storage location (a directory)
contains the DBM file format. If configured to use the modern SQL
format, NSS will automatically perform a one-time conversion from the
DBM to the SQL format.

The same applies to the NSS command line utilities. If the NSS library
default is changed to SQL, the NSS tools will also trigger the
one-time conversion, or access the already converted files.

== Scope ==

* Proposal owners:

A small downstream patch needs to be applied to the NSS library
package, which changes the library default.

* Other developers:

It's up to developers of NSS applications, if they accept the new
default and an automatic conversion, or if they prefer to continue to
use the classic DBM storage format. Although not recommended,
developers can easily do so, by adding a "dbm:" prefix to the storage
parameter they provide to NSS at NSS library initialization time.

* Release engineering: [1]

No help should be necessary. No mass rebuild necessary.

* Policies and guidelines: N/A

* Trademark approval: N/A

[1] https://pagure.io/releng/issue/6883

Thanks,
Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

rawhide compose failures the last few days

[Kevin Fenzi]

Greetings.

Rawhide hasnt composed the last few days. The issue is:

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

Somehow the bind99-libs package isn't getting pulled in anymore and
dhclient breaks. It seems like it would be a change in bind/bind99, but
I can't see anything obvious there.

If anyone has time to dig into this that would be great.

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F27 System Wide Change: NSS signtool deprecation

[Jaroslav Reznik]

= System Wide Change: NSS signtool deprecation =
https://fedoraproject.org/wiki/Changes/NSSSigntoolDeprecation

Change owner(s):
* Kai Engert 

Deprecate the NSS tool named signtool, currently shipped as part of
the nss-tools package, and available in the default search path at
/usr/bin/signtool. Move it to
/usr/lib*/nss/unsupported-tools/signtool.

== Detailed Description ==
The NSS signtool is hardcoded to use SHA1 for signatures, however,
SHA1 is no longer considered secure. Because it seems difficult to
change the signtool default to make use of a more secure hash
algorithm in a backwards and forwards compatible way, and because
signtool might no longer be required for common uses, the suggestion
is to deprecate it.

See also [1] and [2]

== Scope ==
* Proposal owners:

The work required to implement this change is a simple packaging change.

* Other developers:

Users who used signtool for signing Jar/Zip/etc. files must use a
different tool. A possible alternative is the jarsigner tool, which is
shipped as part of the java-*-openjdk-devel package.

* Release engineering: [1]

* List of deliverables:
N/A

* Policies and guidelines:
N/A, no changes should be necessary.

* Trademark approval:
N/A (not needed for this Change)

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1345528
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1444136
[3] https://pagure.io/releng/issue/6882

Thanks,
Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 Self Contained Change: VirtualBox Guest Integration

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jul 06, 2017 at 06:17:53PM +0200, Reindl Harald wrote:
> 
> 
> Am 06.07.2017 um 17:18 schrieb Zbigniew Jędrzejewski-Szmek:
> >On Thu, Jul 06, 2017 at 04:10:29PM +0200, Jaroslav Reznik wrote:
> >>= Proposed Self Contained Change: VirtualBox Guest Integration =
> >>https://fedoraproject.org/wiki/Changes/VirtualBox_Guest_Integration
> >>
> >>Change owner(s):
> >>* Hans de Goede 
> >>
> >>VirtualBox is popular, easy to use virtual-machine software. The
> >>purpose of this change is to ship the VirtualBox guest-drivers and
> >>-tools by default in the Fedora workstation product.
> >
> >Please make sure when running on non-VirtualBox machines the
> >drivers and services are not loaded and there are no warnings emitted.
> >(I know we've had similar problems before — e.g.
> >https://bugzilla.redhat.com/show_bug.cgi?id=999804, and some other
> >bugs I cannot find now, so I'm just saying that this is something
> >worth checking for from the start.)
> >Probably the right solution is to use a udev rule to trigger starting
> >of various services only if the "devices" are found. Something like
> >/usr/lib/udev/rules.d/70-spice-vdagentd.rules in spice-vdagent.rpm
> 
> this needs to be done like for VMware and if systemd don't detect
> vbox systemd needs to be fixed instead dirty udev workarounds
> 
> [Unit]
> Description=VMware Tools
> ConditionVirtualization=vmware

I don't know how exactly how VirtualBox (or VMWare) implement guest
additions, but using an udev rule in general is a better solution:

1. Using ConditionVirtualization=xxx assumes that the guest additions are
   *always* enabled when ConditionVirtualization=xxx is true. From what I
   have seen, that's generally not true, and you need to configure a
   specific "channel" in virtualization configuration. That means that
   ConditionVirtualization is just not specific enough.
2. Using ConditionVirtualization means that the service start is always
   enqueued (and skipped on the majority of systems). This appears in
   the logs, and it's just nicer not to have that.
3. If the "channel" is "hot pluggable", the device can appear any time
   after bootup. With the udev rule, that'll just work. ConditionVirtualization
   would only be checked once at bootup.

The way that the configuration for spice-vdagent.service is done is
pretty nice:
1. /usr/lib/udev/rules.d/70-spice-vdagentd.rules contains the rule that
  pulls in spice-vdagentd.target
2. spice-vdagentd.service has [Install] WantedBy=spice-vdagentd.target
3. /usr/lib/systemd/system-preset/90-default.preset has "enable 
spice-vdagentd.service"
4. spice-vdagent.rpm has "systemctl preset spice-vdagentd.service"

This means that things work out of the box, are completely silent if not
virtualized or the channel is not configured, and the admin can enable/disable
the service at will, and it's possible to configure different or additional
stuff to start if the channel is available. Flexible, but without any hacks.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Another Fedora 26 test request: VMware

[Adam Williamson]

On Wed, 2017-07-05 at 17:26 -0700, Adam Williamson wrote:
> Hi folks! Got another request for Fedora 26 Final testing: can folks
> please try booting RC-1.4 in VMware? For me, the Workstation live fails
> to boot properly, in various configurations; in comparison the F25
> Final Workstation live boots fine. That worried me a bit, so it'd be
> good to hear results from other testers...

Thanks for all the feedback on this, folks. Sounds like people are
seeing broadly the same thing as me, so I'll file a bug.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Coming soon: Pagure service for dist-git

[Paul W. Frields]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

For some time, the Fedora Infrastructure team and fellow community
members have been working on service upgrades for package dist-git.
This includes creating a Pagure front end like the one at
, a separate instance that enables forks and pull
requests on dist-git.  This change solves multiple problems -- both
common, current ones, and predicted future ones -- that stymie
community growth and contribution.  Examples include proposing simple
packaging fixes, changes to the dist-git branching model, and enabling
better, more continuous production models for Fedora.

These changes will *not* require packagers to change their workflows
for existing processes.  Using fedpkg and git at the command line to
manage packaging will work just as before.  However, it will now be
possible for other contributors to suggest changes in a
fork/pull-request model.

WE'VE TALKED ABOUT THIS FOR A LONG TIME. WHY NOW?
- -

If you've been paying attention to release tooling efforts in Fedora,
you know we're trying to accelerate the release of the Atomic Host
deliverable.  Part of this effort is establishing a pipeline for
continuous integration and delivery (CI/CD) in Fedora[1].  This and
the modularity effort also are driving the establishment of services
like this dist-git front end.  The hooks and capabilities of Pagure
are part of enabling CI/CD.

In early phases, these efforts will target the packages that comprise
the Atomic Host, rather than the entire universe of Fedora packages.
This temporary measure will prove out the pipeline in an open source,
iterative way.  In later phases, packagers throughout Fedora will be
able to opt-in to the pipeline as well.  The benefit is that we will
know more often whether a package has problems before either breaking
the distro or impacting users.  In the future, we hope this will have
a positive impact on Rawhide, making it usable by more of the
community, more often.

WHAT TO EXPECT
- --

One of the contributions expected in this early phase is testing. The
standard interface[2] developed as part of the CI effort provides a
framework for test contributions.  Shortly after Pagure/dist-git shows
up, we hope to receive test contributions from quality engineers for
packages that comprise the Atomic Host.  These should come in the form
of pull requests for the package maintainers, following the
established standards.

This is a benefit for Fedora not only because it kickstarts the CI
effort, but because it provides examples the whole Fedora community
can use in later phases.  The intention is that maintainers and
co-maintainers continue to control these tests so they can modify or
add to them as needed.

If you're a packager with a package in the Atomic Host, you may
receive pull requests soon after the new Pagure instance is deployed,
with these tests included.  We encourage you to review and merge these
pull requests (provided they look good), so your package can take
advantage of the CI work.  If you have problems with the pull request,
you can use the Pagure instance to work with the contributor to fix
it.

It is possible to turn off PRs for your dist-git repo in the repo
settings.  However, we strongly encourage you to allow PRs because
this is a strong source of potential contributions with little or no
downside.  We plan to work with FESCo on a project-wide policy that
makes sense and fits Fedora's values.

WANT TO TRY IT OUT?
- ---

If you're interested to see what this new capability looks like, and
want to test a working version, visit
.  Changes here won't
affect the actual Fedora RPMs, but the staging instance lets you
explore the new functionality.  Note that the staging content is
updated on a schedule, so some newer package data may not appear
there.

It will be at least a few more weeks before the production instance is
ready.  We appreciate your constructive feedback and bugs[3], as
always.

* * *
[1] https://fedoraproject.org/wiki/CI
[2] https://fedoraproject.org/wiki/Changes/InvokingTests
[3] https://pagure.io/pagure/issues

- -- 
Paul W. Frieldshttp://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com

-BEGIN PGP SIGNATURE-

iD8DBQFZXmrvrNvJN70RNxcRAv2CAJsHL66rtcFl6z/ooEOyfexkye3gBQCeOpHF
LQjAwhGOmVD2kjCD4W5Ql0c=
=AyX9
-END PGP SIGNATURE-
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@

Re: [Modularity] A proposal for stream naming

[langdon]

On 06/29/2017 11:30 AM, Matthew Miller wrote:

On Thu, Jun 29, 2017 at 10:49:20AM -0400, Owen Taylor wrote:

To what extent do we want to encourage "collections of stuff" modules?

Numerically, most modules will likely to be designed to be installed as
containers or flatpaks because that's how we handle conflicting dependencies.
If you leave those modules out, then you really have the constraint that
every package has to be in no more than one module. We can't have
"Matthew's System Tools" and "Owen's System Tools" that are independently
curated, because they can't be enabled on the same system.

Well, we *can*. The question is whether we *should*. :)

I'm kind of on the "we shouldn't" side, but I could be convinced. My
intention is for anything that is in the System Tools module which gets
its own more focused module to be moved out.





So my expectation is that the number of "collections modules" that have
no strong connection to a particular upstream release process will be
small and well defined - say Platform, Runtime, System Tools, and a few more.
As such, I think it *would* be reasonable to say that they all
are versioned at the same tempo and even keep the F stream naming.

Langdon? Rebuttal? :)

I think containers are just a packaging type. In other words, whether 
the "thing" is delivered as a docker container, flatpak, rpm, 
something-not-though-of-yet, it is still the same module. This is kind 
of the point, we want to disconnect the "content needed to provide the 
service" from the "packaging mechanism to deliver the content" (very 
loosely). As a result, we may see many different module collections of 
stuff even if they are only being shipped as containers (or whatever).


So, I am not sure. I think Owen may have a point, but I think whether we 
have "many" collections will evolve over time. However, I definitely 
would not agree with the f naming because why would it need to 
"stream change" because of the fedora base? In other words,  a new 
stream indicates a new ABI/API but, I can tell you, no matter how many 
versions of fedora go by, we are never gonna drop emacs OR vi from the 
system-tools type collection so why would the stream change? The module 
should be allowed to make decisions on its content based on its own 
timescale not an arbitrary release boundary. I think this applies to 
"collections of stuff" just as much as the more obvious "single 
applications."


I definitely think there are a few more "tightly defined" collections of 
stuff as Owen describes. However, I am not sure we have found them all 
yet. Something like "system-tools" is definitely one of them and there 
may be a few others. That said, I don't think we know which way we will 
want to go. I definitely think we want to start on the conservative side 
and see how often we run in to "needing exceptions". That said, I think 
it is important that we don't encode these types of rules in to our 
systems (except as tests which we can disable/modify as the rules change).





Hmmm, I see a couple of issues:
  
  * If we have 'apache' with a stream of 2.4 and 'GNOME Desktop' with a

stream of 3.24, we can't have the stream name be the main way we
convey EOL information. So then it's just confusing that for *some*
modules the EOL is duplicated in the stream name.
  
  * The ability to change the EOL for a stream is quite likely useful -

to decide it will have a longer support lifetime than originally
planned. It would be even more confusing to have *incorrect* EOL's
as the stream name.

  * Aren't people in July 2018 going to think f1806 is the current stream,
not a two-year old stream?

Yeah that last one is pretty bad. I think all of this argues for a real
first-class EOL metadata item.



If we need arbitrary stream names that are consistent across Fedora, I think
release dates would be a lot clearer than EOL dates - EOL dates seem more
clever than useful.

Okay, I'm convinced, as long as we can get lifecycle/EOL as a first-class
metadata item.


\o/ ;)

Langdon
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Modularity] A proposal for stream naming

[langdon]

On 07/03/2017 06:53 AM, Brian Exelbierd wrote:


On Thu, Jun 29, 2017, at 10:34 PM, Matthew Miller wrote:

On Thu, Jun 29, 2017 at 10:29:29PM +0200, Brian Exelbierd wrote:

However, considering this from a different angle, a LAMP stack module,
for example, might just need to make a certain API/ABI promise and then
it could roll for quite a while.  This would be without regard to the
changes in the underlying software versions, as long as what was
promised on the wrapper was still met.  If this is the case then
"collections" are no different from "single applications."

In terms of EOL, right. But collections have no obvious intrinsic
version number to use as the major stream identifier, whereas
applications (and environments and stacks) do.

I think we should allow for an arbitrary version number when the
collection is not obviously tied to a specific release/user space.
However, I think that should strongly be discouraged and if at all
possible the motivating software in the collection's version number
should be used.  This is not something that should ever require heavy
debate, imho.  I trust packagers to make the right decision.

regards,

bex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


one quick point, even in the case of "single applications" what is 
included may not be obvious. For example, does this mariadb module 
include the client? how about python bindings? For what versions of 
python? You quickly run in to problems when trying to fit information in 
to the name that isn't the name of the thing. Major +1 to the points 
about NOT encoding information in to the "wrong" metadata element.


Again, struggling with how do we capture all this? I believe it should 
be in the module guidelines, however, it would be useful to capture 
these discussions so that when we (I, for sure :) ) forget, we can see 
the "threads". Should we shift this kind of discussion to the "wiki 
discussion" page? Should we move the guidelines to a pagure repo and do 
it with PRs, issues, etc?


Langdon
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Modularity] A proposal for stream naming

[Matthew Miller]

On Thu, Jul 06, 2017 at 01:39:35PM -0400, langdon wrote:
> I definitely think there are a few more "tightly defined"
> collections of stuff as Owen describes. However, I am not sure we
> have found them all yet. Something like "system-tools" is definitely
> one of them and there may be a few others. That said, I don't think

The system-tools comps group as definied has an awkward mix of
command-line utilities, GUI apps, and things that are actually services
(like incron). I think we should make this module *just* command-line
utilities. Services should *probably* get their own individual modules.
I don't know about GUI apps.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Modularity] A proposal for stream naming

[Matthew Miller]

On Thu, Jul 06, 2017 at 01:48:39PM -0400, langdon wrote:
> capture these discussions so that when we (I, for sure :) ) forget,
> we can see the "threads". Should we shift this kind of discussion to
> the "wiki discussion" page? Should we move the guidelines to a
> pagure repo and do it with PRs, issues, etc?

That sounds good to me.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 Self Contained Change: VirtualBox Guest Integration

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jul 06, 2017 at 06:55:46PM +0200, Reindl Harald wrote:
> 
> 
> Am 06.07.2017 um 18:43 schrieb Zbigniew Jędrzejewski-Szmek:
> >On Thu, Jul 06, 2017 at 06:17:53PM +0200, Reindl Harald wrote:
> >>
> >>
> >>Am 06.07.2017 um 17:18 schrieb Zbigniew Jędrzejewski-Szmek:
> >>>On Thu, Jul 06, 2017 at 04:10:29PM +0200, Jaroslav Reznik wrote:
> = Proposed Self Contained Change: VirtualBox Guest Integration =
> https://fedoraproject.org/wiki/Changes/VirtualBox_Guest_Integration
> 
> Change owner(s):
> * Hans de Goede 
> 
> VirtualBox is popular, easy to use virtual-machine software. The
> purpose of this change is to ship the VirtualBox guest-drivers and
> -tools by default in the Fedora workstation product.
> >>>
> >>>Please make sure when running on non-VirtualBox machines the
> >>>drivers and services are not loaded and there are no warnings emitted.
> >>>(I know we've had similar problems before — e.g.
> >>>https://bugzilla.redhat.com/show_bug.cgi?id=999804, and some other
> >>>bugs I cannot find now, so I'm just saying that this is something
> >>>worth checking for from the start.)
> >>>Probably the right solution is to use a udev rule to trigger starting
> >>>of various services only if the "devices" are found. Something like
> >>>/usr/lib/udev/rules.d/70-spice-vdagentd.rules in spice-vdagent.rpm
> >>
> >>this needs to be done like for VMware and if systemd don't detect
> >>vbox systemd needs to be fixed instead dirty udev workarounds
> >>
> >>[Unit]
> >>Description=VMware Tools
> >>ConditionVirtualization=vmware
> >
> >I don't know how exactly how VirtualBox (or VMWare) implement guest
> >additions, but using an udev rule in general is a better solution:
> >
> >1. Using ConditionVirtualization=xxx assumes that the guest additions are
> >*always* enabled when ConditionVirtualization=xxx is true. From what I
> >have seen, that's generally not true, and you need to configure a
> >specific "channel" in virtualization configuration. That means that
> >ConditionVirtualization is just not specific enough
> 
> it's the answer to "Please make sure when running on non-VirtualBox
> machines" not more and not less even if by accident the unit is
> enabled/installed on bare metal

We want to make the default installation do the right thing, as far as
possible, on any system, without any explicit configuration or admin steps.
In this case it's possible: if a virtualization "channel" is configured,
we should assume that the user wants the service. This means that the
"guest additions" rpms should be a) installed by default, b) enabled
when installed, c) work ootb when running in the right virtualization
and silently do nothing otherwise.

Essentially, I want to take the same image and boot it in virtualbox,
kvm, on bare metal, and in a container, and have things just work.

> how do you come to the conclusion that a dsiablked service is
> suddenly enabled just because of that additional
> ConditionVirtualization in the systemd-unit?

Like I wrote above, we want it installed and enabled by default.

End users on windows can be expected to be even less experienced than
average, so it's important to make things as automatic and seamless
as possible.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Modularity] A proposal for stream naming

[Owen Taylor]

On Thu, 2017-07-06 at 13:39 -0400, langdon wrote:
> On 06/29/2017 11:30 AM, Matthew Miller wrote:
> > On Thu, Jun 29, 2017 at 10:49:20AM -0400, Owen Taylor wrote:
> > > So my expectation is that the number of "collections modules"
> > > that have no strong connection to a particular upstream release
> > > process will be small and well defined - say Platform, Runtime,
> > > System Tools, and a few more. As such, I think it *would* be
> > > reasonable to say that they all are versioned at the same tempo
> > > and even keep the F stream naming.
> > 
> > Langdon? Rebuttal? :
> 
> I think containers are just a packaging type. In other words, whether
> the "thing" is delivered as a docker container, flatpak,
> rpm,  something-not-though-of-yet, it is still the same module. This
> is kind of the point, we want to disconnect the "content needed to
> provide the service" from the "packaging mechanism to deliver the
> content" (very loosely). As a result, we may see many different
> module collections of stuff even if they are only being shipped as
> containers (or whatever).

I think you make different decisions depending on how you expect your
module to be packaged/deployed.

> So, I am not sure. I think Owen may have a point, but I think whether
> we have "many" collections will evolve over time. However, I
> definitely would not agree with the f naming because why would it
> need to "stream change" because of the fedora base? In other
> words,  a new stream indicates a new ABI/API but, I can tell you, no
> matter how many versions of fedora go by, we are never gonna drop
> emacs OR vi from the system-tools type collection so why would the
> stream change? The module should be allowed to make decisions on its
> content based on its own timescale not an arbitrary release boundary.
> I think this applies to "collections of stuff" just as much as the
> more obvious "single applications."

But dropping emacs out of the system-tools collection would only be one
form of ABI/API breakage. The following can also be breakages:

 * Upgrading a package, if the package changes its ABI, API,
   configuration files or command line options.
 * Adding a new package (the new package may conflict with packages
   from other modules with unpredictable results)

And if module A depends on module B, and module B changes its ABI/API,
that also effectively changes the ABI/API of module A in the general
case.

One of the main ways we have of handling this fragility is to
distribute in a container (or container-like thing). If you design for
distributing in a container, and always distribute in a container, then
 consumers can ignore a lot of things that happen inside the module.

But for a module that is not containerized, that has a lot of packages
in it, that depends on the Fedora Platform module, I think that the
only realistic model that provides API/ABI stable streams is to release
new streams often, probably in sync with the Platform model, and not
change the streams much after release.

Whether those streams are called F or 201806 or whatever is a
somewhat arbitrary choice.

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Modularity] A proposal for stream naming

[langdon]

On 07/06/2017 02:58 PM, Owen Taylor wrote:

On Thu, 2017-07-06 at 13:39 -0400, langdon wrote:

On 06/29/2017 11:30 AM, Matthew Miller wrote:

On Thu, Jun 29, 2017 at 10:49:20AM -0400, Owen Taylor wrote:

So my expectation is that the number of "collections modules"
that have no strong connection to a particular upstream release
process will be small and well defined - say Platform, Runtime,
System Tools, and a few more. As such, I think it *would* be
reasonable to say that they all are versioned at the same tempo
and even keep the F stream naming.

Langdon? Rebuttal? :

I think containers are just a packaging type. In other words, whether
the "thing" is delivered as a docker container, flatpak,
rpm,  something-not-though-of-yet, it is still the same module. This
is kind of the point, we want to disconnect the "content needed to
provide the service" from the "packaging mechanism to deliver the
content" (very loosely). As a result, we may see many different
module collections of stuff even if they are only being shipped as
containers (or whatever).

I think you make different decisions depending on how you expect your
module to be packaged/deployed.


So, I am not sure. I think Owen may have a point, but I think whether
we have "many" collections will evolve over time. However, I
definitely would not agree with the f naming because why would it
need to "stream change" because of the fedora base? In other
words,  a new stream indicates a new ABI/API but, I can tell you, no
matter how many versions of fedora go by, we are never gonna drop
emacs OR vi from the system-tools type collection so why would the
stream change? The module should be allowed to make decisions on its
content based on its own timescale not an arbitrary release boundary.
I think this applies to "collections of stuff" just as much as the
more obvious "single applications."

But dropping emacs out of the system-tools collection would only be one
form of ABI/API breakage. The following can also be breakages:

  * Upgrading a package, if the package changes its ABI, API,
configuration files or command line options.
  * Adding a new package (the new package may conflict with packages
from other modules with unpredictable results)

And if module A depends on module B, and module B changes its ABI/API,
that also effectively changes the ABI/API of module A in the general
case.

One of the main ways we have of handling this fragility is to
distribute in a container (or container-like thing). If you design for
distributing in a container, and always distribute in a container, then
  consumers can ignore a lot of things that happen inside the module.

But for a module that is not containerized, that has a lot of packages
in it, that depends on the Fedora Platform module, I think that the
only realistic model that provides API/ABI stable streams is to release
new streams often, probably in sync with the Platform model, and not
change the streams much after release.


I think the modules:
a) need to assume, as much as possible, that they are independent from 
all other modules that they don't depend on. We may need to provide some 
tooling that makes this "true" but that is ok
b) a module should depend on as few other modules as possible, in other 
words, just host&plat and shared-userspace. Otherwise, your lifecycle, 
as you say, is bound to the other module.


I think you are probably right, at first. However, I expect, over time, 
that this will shift. Either more things will be containerized, the 
dependency set will get cleaner, better bundling methods will be 
supported, etc.


Whether those streams are called F or 201806 or whatever is a
somewhat arbitrary choice.
so ^^ yes.. but as in the rest of this thread.. I strongly disagree with 
the perception of binding to a "release" even if, for some period of 
time we most of the time do. If we don't carefully & quickly move away 
from the "release" terminology, the flexibility will be lost because 
people will think there is a requirement of a lock when there may not, 
in fact, be.


Langdon


Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 26 status is GO, release on July 11, 2017

[Jaroslav Reznik]

The Fedora 26 Final 1.5 compose [1] is considered as GOLD and is going
to be shipped live on Tuesday, July 11th, 2017.

For more information please check the Go/No-Go meeting minutes [2] or logs [3].

I'd like to thank everyone for the hard work on this release and great job Jan!

[1] https://kojipkgs.fedoraproject.org/compose/26/Fedora-26-20170705.0/compose/
[2] 
https://meetbot.fedoraproject.org/fedora-meeting-2/2017-07-06/f26_final_gono-go_meeting.2017-07-06-17.00.html
[3] 
https://meetbot.fedoraproject.org/fedora-meeting-2/2017-07-06/f26_final_gono-go_meeting.2017-07-06-17.00.log.html

Thanks,
Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 26 RC 1.5 compose check report

[Adam Williamson]

On Thu, 2017-07-06 at 05:08 +, Fedora compose checker wrote:
> No missing expected images.
> 
> Failed openQA tests: 4/135 (x86_64), 1/24 (i386), 1/2 (arm)
> 
> New failures (same test did not fail in 26 RC 1.4):
> 
> ID: 117809Test: x86_64 Server-dvd-iso install_default@uefi
> URL: https://openqa.fedoraproject.org/tests/117809
> ID: 117853Test: x86_64 KDE-live-iso install_default_upload
> URL: https://openqa.fedoraproject.org/tests/117853
> ID: 117867Test: arm Minimal-raw_xz-raw.xz 
> install_arm_image_deployment_upload
> URL: https://openqa.fedoraproject.org/tests/117867
> ID: 117933Test: x86_64 universal upgrade_desktop_encrypted_64bit
> URL: https://openqa.fedoraproject.org/tests/117933
> ID: 117965Test: i386 universal upgrade_2_desktop_32bit
> URL: https://openqa.fedoraproject.org/tests/117965

These were all random test glitches, I re-ran them all.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Announce: Fedora Layered Image Release

[Adam Miller]

Hello all,
On behalf of the Fedora Atomic WG[0] and Fedora Release
Engineering[1], I am pleased to announce the latest Fedora Layered
Image Release. This follows the latest Atomic Host Release that came
out today[2].

At this time the following Container Images are available in the
Fedora Registry.

Updated Base Images:

(Note that the "latest" tag currently points to "25" and the "rawhide"
tag currently points to "27", if no tag is provided in your pull
command then it will always default to "latest")

registry.fedoraproject.org/fedora:latest
registry.fedoraproject.org/fedora:rawhide
registry.fedoraproject.org/fedora:27
registry.fedoraproject.org/fedora:26
registry.fedoraproject.org/fedora:25


Updated Layered Images:

(Note: Layered Images are namespaced in the registry and at this time
we are only releasing for the f25 namespace.)

registry.fedoraproject.org/f25/ruby:0-9.f25docker
registry.fedoraproject.org/f25/ruby:0
registry.fedoraproject.org/f25/ruby
registry.fedoraproject.org/f25/kubernetes-master:0.1-16.f25container
registry.fedoraproject.org/f25/kubernetes-master:0.1
registry.fedoraproject.org/f25/kubernetes-master
registry.fedoraproject.org/f25/kubernetes-kubelet:0-15.f25container
registry.fedoraproject.org/f25/kubernetes-kubelet:0
registry.fedoraproject.org/f25/kubernetes-kubelet
registry.fedoraproject.org/f25/redis:0-6.f25container
registry.fedoraproject.org/f25/redis:0
registry.fedoraproject.org/f25/redis
registry.fedoraproject.org/f25/etcd:0.1-16.f25container
registry.fedoraproject.org/f25/etcd:0.1
registry.fedoraproject.org/f25/etcd
registry.fedoraproject.org/f25/cockpit:135-11.f25container
registry.fedoraproject.org/f25/cockpit:135
registry.fedoraproject.org/f25/cockpit
registry.fedoraproject.org/f25/mongodb:0-6.f25container
registry.fedoraproject.org/f25/mongodb:0
registry.fedoraproject.org/f25/mongodb
registry.fedoraproject.org/f25/php:0-5.f25container
registry.fedoraproject.org/f25/php:0
registry.fedoraproject.org/f25/php
registry.fedoraproject.org/f25/s2i-base:1-14.f25container
registry.fedoraproject.org/f25/s2i-base:1
registry.fedoraproject.org/f25/s2i-base
registry.fedoraproject.org/f25/nodejs:0-6.f25container
registry.fedoraproject.org/f25/nodejs:0
registry.fedoraproject.org/f25/nodejs
registry.fedoraproject.org/f25/kubernetes-controller-manager:0.1-15.f25container
registry.fedoraproject.org/f25/kubernetes-controller-manager:0.1
registry.fedoraproject.org/f25/kubernetes-controller-manager
registry.fedoraproject.org/f25/mariadb:10.1-14.f25container
registry.fedoraproject.org/f25/mariadb:10.1
registry.fedoraproject.org/f25/mariadb
registry.fedoraproject.org/f25/kubernetes-scheduler:0.1-15.f25container
registry.fedoraproject.org/f25/kubernetes-scheduler:0.1
registry.fedoraproject.org/f25/kubernetes-scheduler
registry.fedoraproject.org/f25/kubernetes-node:0.1-15.f25container
registry.fedoraproject.org/f25/kubernetes-node:0.1
registry.fedoraproject.org/f25/kubernetes-node
registry.fedoraproject.org/f25/kubernetes-proxy:0-15.f25container
registry.fedoraproject.org/f25/kubernetes-proxy:0
registry.fedoraproject.org/f25/kubernetes-proxy
registry.fedoraproject.org/f25/httpd:0-8.f25container
registry.fedoraproject.org/f25/httpd:0
registry.fedoraproject.org/f25/httpd
registry.fedoraproject.org/f25/toolchain:1-12.f25container
registry.fedoraproject.org/f25/toolchain:1
registry.fedoraproject.org/f25/toolchain
registry.fedoraproject.org/f25/kubernetes-apiserver:0.1-15.f25container
registry.fedoraproject.org/f25/kubernetes-apiserver:0.1
registry.fedoraproject.org/f25/kubernetes-apiserver
registry.fedoraproject.org/f25/mirrormanager2-mirrorlist:0.7.3-8.f25container
registry.fedoraproject.org/f25/mirrormanager2-mirrorlist:0.7.3
registry.fedoraproject.org/f25/mirrormanager2-mirrorlist
registry.fedoraproject.org/f25/flannel:0.1-14.f25container
registry.fedoraproject.org/f25/flannel:0.1
registry.fedoraproject.org/f25/flannel

The source of this content is provided in DistGit which can easily be
searched via the container pkgdb namespace[3].

As always, we welcome feedback and would encourage anyone interested
to come join the Fedora Atomic WG[0] as we continue to iterate on
integrating the Project Atomic[4] family of technologies into Fedora.
Anyone interested in contributing Container Images, please feel free
to join in and submit one for Review[5][6].

Thank you,
-AdamM

[0] - https://pagure.io/atomic-wg
[1] - https://docs.pagure.org/releng/
[2] - 
https://lists.fedoraproject.org/archives/list/cl...@lists.fedoraproject.org/thread/CCYVMZIO4YLJC4QMW2PGY7TILTCHC7G5/
[3] - https://admin.fedoraproject.org/pkgdb/packages/container/%2A/
[4] - https://www.projectatomic.io/
[5] - https://fedoraproject.org/wiki/Container:Review_Process
[6] - https://fedoraproject.org/wiki/Container:Guidelines
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

super-drafty F28 and F29 schedules

[Matthew Miller]

It's probably no surprise if you've ever heard me talk that I really
think hitting early May / late October is important for our release
cadence. Those specific dates aren't magic, but they avoid some big
public holidays, and the key thing is that if we're consistent with
landmarks, it makes planning easier.

I took a look at the planned F27 schedule
https://fedoraproject.org/wiki/Releases/27/Schedule and sketched out
what the same time periods would look like with a May target for F28,
and then repeated again for F29, making very drafty preliminary
schedules:

https://fedoraproject.org/wiki/Releases/28/Schedule
https://fedoraproject.org/wiki/Releases/29/Schedule

and, really, I think it looks very nice. There's a built-in week for
both Beta and Final to slip if need be, and, realistically, if we end
up going a week or two past the planned GA, we're still in decent
shape in May and November.

The key thing, though, is that this is predicated on "No More Alphas"
actually working. That in turn has two big parts.

First, there is gating from rel-eng and QA in progress here: 
https://fedoraproject.org/wiki/Changes/NoMoreAlpha (Note that this is
compose/validation gating, not the CI stuff we're also talking about
separately.) That's key in keeping the release basically stable. But
there's another part:

Unless we want to have very soft release criteria and ship stuff we
know to be broken (or suspect but haven't completely checked out), we
need changes after we branch (and especially after the beta is
released) to follow the stable releases updates policy --
https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases. That
way, we have a fighting chance of identifying blockers with enough time
to get resources directed to fix them without indefinite delay.

Hopefully, by the time we are at F28, Modularity will provide a way for
us to offer faster streams for people who want them -- but let's also
focus on stable releases. The ironic effect of this is that we can get
new software to people *faster*, because we'll be able to more reliably
hit the six-month ship dates, rather than taking eight or nine months.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Coming soon: Pagure service for dist-git

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jul 06, 2017 at 12:53:03PM -0400, Paul W. Frields wrote:
> .

I wasn't able to log in (gateway timeout), so some impressions based
only on browsing the interface:

1. The "All projects (18686)" front page is not very useful, unless
   the package you are looking for starts with digit. I think an
   almost-empty lean landing with a search box in the style of google
   would be more useful.

   For logged-in users, the list of projects they contributed to
   recently would be nice.

2. completions in search show "null" under every entry

3. The default landing page for a package shows a message about
   the missing readme. Maybe we could show the %description there in
   such cases?

4. releases tab shows tags. I think koji used to create those tags
   when builds happened automatically, but this hasn't been happening
   for a long time. (adamw yelled at me and I added a bunch manually to
   systemd, but) most projects don't have any tags, or have some from
   the f13-f14 era, so that content is not useful.

   It would be great to get something like the "Active release overview"
   from https://apps.fedoraproject.org/packages/ that
   shows "Latest Released Version" and "Version in Testing" for each
   Fedora branch. I understand this might be out of scope.

Zbyszek

   
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unable to login to Wayland session on Fedora 26 Workstation

[Timothy Ward]

Is there any link to some docs on this and the reasons etc, every time
I see a reference or message to this, there is no docs to refer to. 


On Wed, 2017-07-05 at 14:24 -0700, Adam Williamson wrote:
> On Wed, 2017-07-05 at 19:51 +, Sumit Bhardwaj wrote:
> > I have gone ahead and filed a bug for this  (Bug ID: 1468029) and
> > proposed it as final blocker as we are so close to Final release of
> > Fedora 26 and this definitely seems like a blocker to me. A working
> > Wayland session is a requirement for final release if I am not
> > wrong.
> 
> In fact it isn't, the requirements are functional, not linked to
> implementation details: we require that graphical installs boot to a
> working desktop, we don't get into the details of what the display
> server should be.
> 
> In any case, I rather doubt this is a general issue. I rebooted this
> system 8 days ago and it's certainly running Wayland. I just booted
> up
> the RC-1.4 Workstation live in a VM, and it's running Wayland.
> 
> There are some specific hardware configurations on which the Wayland
> session will *intentionally* downgrade to X, and when the Wayland
> session fails to start correctly, it will automatically retry with an
> X
> session; you might be running into one of these cases.
> -- 
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin .
> net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rawhide compose failures the last few days

[Yanko Kaneti]

On Thu, 2017-07-06 at 10:31 -0600, Kevin Fenzi wrote:
> Greetings.
> 
> Rawhide hasnt composed the last few days. The issue is:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1467710
> 
> Somehow the bind99-libs package isn't getting pulled in anymore and
> dhclient breaks. It seems like it would be a change in bind/bind99,
> but
> I can't see anything obvious there.
> 
> If anyone has time to dig into this that would be great.

Just some pointers... don't have much time to chase it further.

A recent (dunno which specific one) rpm in rawhide changed (either
fixed or broke depending on the viewpoint) the interpretation of some
old ways of doing filtering (%filter_setup , %filter_requires_in...),
while the new ways of filtering (%global __prov) still work.

This apparently left some packages with incomplete requires/provides,
specifically missing auto shared lib provides/requires.
I am guessing dhcp was one of them.

Yesterday, changing a similiar filter setup in samba to the new way of
doing filtering worked around the rpm issue.
http://pkgs.fedoraproject.org/cgit/rpms/samba.git/commit/?id=bff8742edff6e12d9ecc219c0c52623f9419c0bc


Regards
Yanko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org