date:20180315

On Thu, 2018-03-15 at 19:57 -0400, langdon wrote:
> On 03/15/2018 04:31 PM, Simo Sorce wrote:
> > On Thu, 2018-03-15 at 14:06 -0400, Randy Barlow wrote:
> > > On 03/15/2018 12:28 PM, Chuck Anderson wrote:
> > > > : doesn't work very well in filenames due to it being a pathname 
> > > > separator in some filesystems among other things.
> > > 
> > > It sounds like this breaks a great deal of tooling. Can we reconsider
> > > switching away from - separators in modules? Is allowing streams to have
> > > -'s in them important enough to break so many tools?
> > 
> > I vote for using ⨊ as the separator, makes things easier :-)
> > 
> > Simo.
> > 
> 
> kidding aside, we are trying to get metadata forced in to the name 
> "field"[1] in to proper metadata fields rather than just mangling the 
> names. As a result, we end up with more fields and we don't have to 
> guess what they are based on conventions.
> 
> I also am not sure why we wouldn't want to have hyphens in the names of 
> modules. For example, a package for "react-native".

If you are trying to parse a delimited string, you can cope with either
the *first* or *last* field also being allowed to contain the
delimiter. This is how it works for RPM NEVRAs: name can contain a -,
but epoch, version, release and arch cannot. This allows reliable
parsing because you know any 'extra' -s must be part of the name;
practically speaking, as the subject of the thread suggests, you can
just do a .rsplit() (or equivalent in your language of choice) to get
the fields.

So: there would be no problem with - in the *name* of the modules, so
long as that's the first field, which apparently it is.

The problem is if you allow the delimiter in *both* the first and last
fields, or in *any other field besides the first and the last*. As soon
as you do that, parsing is impossible. This is the issue with module
names, as Patrick pointed out: they allow - in the stream, which is the
*second* field. As soon as you allow this, reliably parsing the name
components out of the whole name becomes impossible.

Yes, you can say 'just don't parse strings, go ask a service instead',
but parsing strings is sometimes by a long way the most convenient way
to do things, and I really can't see how allowing the delimiter
character to appear in one of the field names is a *bigger* win than
allowing the components to be reliably parsed from the overall name.

(I have extensive experience with this field, thanks to dealing with
RPM names, image filenames, *and* Pungi compose IDs (oh God, don't make
me break out my compose ID parser as an example), and at this point I'd
like to designate a special circle of hell for people who do this sort
of thing. :>)
-- 
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

Link error in F28 (but not Rawhide)

2018-03-15 Thread Scott Talbert

I'm seeing a strange error when building wxGTK3 on F28.  This only happens
on x86_64.  The same package built fine on Rawhide.  Anyone have any ideas
what's going on here?

This is the Koji task:
https://koji.fedoraproject.org/koji/taskinfo?taskID=25734989

Here's the error:
`_ZN8wxThread8OnDeleteEv_end' referenced in section
`.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded
section `.text._ZN8wxThread8OnDeleteEv[_ZN8wxThread8OnDeleteEv]' of
advdll_sound_sdl.o
`_ZN8wxThread6OnKillEv_end' referenced in section `.gnu.build.attributes'
of advdll_sound_sdl.o: defined in discarded section
`.text._ZN8wxThread6OnKillEv[_ZN8wxThread6OnKillEv]' of advdll_sound_sdl.o
`_ZN8wxThread6OnExitEv_end' referenced in section `.gnu.build.attributes'
of advdll_sound_sdl.o: defined in discarded section
`.text._ZN8wxThread6OnExitEv[_ZN8wxThread6OnExitEv]' of advdll_sound_sdl.o
`_ZNK20wxObjectEventFunctor13GetEvtHandlerEv_end' referenced in section
`.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded
section
`.text._ZNK20wxObjectEventFunctor13GetEvtHandlerEv[_ZNK20wxObjectEventFunctor13GetEvtHandlerEv]'
of advdll_sound_sdl.o
`_ZNK20wxObjectEventFunctor12GetEvtMethodEv_end' referenced in section
`.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded
section
`.text._ZNK20wxObjectEventFunctor12GetEvtMethodEv[_ZNK20wxObjectEventFunctor12GetEvtMethodEv]'
of advdll_sound_sdl.o
`_ZNK7wxEvent16GetEventCategoryEv_end' referenced in section
`.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded
section
`.text._ZNK7wxEvent16GetEventCategoryEv[_ZNK7wxEvent16GetEventCategoryEv]'
of advdll_sound_sdl.o
`_ZN12wxEvtHandler14SetNextHandlerEPS__end' referenced in section
`.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded
section
`.text._ZN12wxEvtHandler14SetNextHandlerEPS_[_ZN12wxEvtHandler14SetNextHandlerEPS_]'
of advdll_sound_sdl.o
`_ZN12wxEvtHandler18SetPreviousHandlerEPS__end' referenced in section
`.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded
section
`.text._ZN12wxEvtHandler18SetPreviousHandlerEPS_[_ZN12wxEvtHandler18SetPreviousHandlerEPS_]'
of advdll_sound_sdl.o
`_ZN12wxEvtHandler15AddPendingEventERK7wxEvent_end' referenced in section
`.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded
section
`.text._ZN12wxEvtHandler15AddPendingEventERK7wxEvent[_ZN12wxEvtHandler15AddPendingEventERK7wxEvent]'
of advdll_sound_sdl.o
`_ZN12wxEvtHandler12TryValidatorER7wxEvent_end' referenced in section
`.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded
section
`.text._ZN12wxEvtHandler12TryValidatorER7wxEvent[_ZN12wxEvtHandler12TryValidatorER7wxEvent]'
of advdll_sound_sdl.o
`_ZN20wxObjectEventFunctorclEP12wxEvtHandlerR7wxEvent_end' referenced in
section `.gnu.build.attributes' of advdll_sound_sdl.o: defined in
discarded section
`.text._ZN20wxObjectEventFunctorclEP12wxEvtHandlerR7wxEvent[_ZN20wxObjectEventFunctorclEP12wxEvtHandlerR7wxEvent]'
of advdll_sound_sdl.o
`_ZN50wxStringToStringHashMap_wxImplementation_HashTable16GetBucketForNodeEPS_PNS_4NodeE_end'
referenced in section `.gnu.build.attributes' of advdll_sound_sdl.o:
defined in discarded section
`.text._ZN50wxStringToStringHashMap_wxImplementation_HashTable16GetBucketForNodeEPS_PNS_4NodeE[_ZN50wxStringToStringHashMap_wxImplementation_HashTable16GetBucketForNodeEPS_PNS_4NodeE]'
of advdll_sound_sdl.o
`_ZN12wxEvtHandler9TryParentER7wxEvent_end' referenced in section
`.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded
section
`.text._ZN12wxEvtHandler9TryParentER7wxEvent[_ZN12wxEvtHandler9TryParentER7wxEvent]'
of advdll_sound_sdl.o
`_ZN20wxObjectEventFunctorD2Ev_end' referenced in section
`.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded
section
`.text._ZN20wxObjectEventFunctorD2Ev[_ZN20wxObjectEventFunctorD5Ev]' of
advdll_sound_sdl.o
`_ZN20wxObjectEventFunctorD0Ev_end' referenced in section
`.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded
section
`.text._ZN20wxObjectEventFunctorD0Ev[_ZN20wxObjectEventFunctorD5Ev]' of
advdll_sound_sdl.o
`_ZN20wxThreadHelperThread5EntryEv_end' referenced in section
`.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded
section
`.text._ZN20wxThreadHelperThread5EntryEv[_ZN20wxThreadHelperThread5EntryEv]'
of advdll_sound_sdl.o
`_ZN20wxThreadHelperThreadD2Ev_end' referenced in section
`.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded
section
`.text._ZN20wxThreadHelperThreadD2Ev[_ZN20wxThreadHelperThreadD5Ev]' of
advdll_sound_sdl.o
`_ZN20wxThreadHelperThreadD0Ev_end' referenced in section
`.gnu.build.attributes' of advdll_sound_sdl.o: defined in discarded
section
`.text._ZN20wxThreadHelperThreadD0Ev[_ZN20wxThreadHelperThreadD5Ev]' of
advdll_sound_sdl.o
`_ZNK20wxObjectEventFunctor10IsMatchingERK14wxEventFunctor_end' referenced
in section `.gnu.build.attributes' of advdll_sound_sdl.o: defined in
discarded section

Re: GCC 8.0.1 updates in F28

On Thu, 2018-03-15 at 18:26 +0100, Dan Horák wrote:
> On Thu, 15 Mar 2018 17:11:49 +
> Peter Robinson  wrote:
> 
> > On Thu, Mar 15, 2018 at 6:25 AM, Vascom  wrote:
> > > Hi.
> > > 
> > > GCC 8.0.1-0.16 in F28 repo is freezed until F28 release?
> > > Or it will be updated soon so we can build some packages failed to
> > > build now?
> > > Or better use build override new gcc for this packages?
> > 
> > Is there a particular bug fix that you need in the GA release you need
> > for building against? The gcc release in stable is pretty close to GA
> > so unless there's a specific bug that was fixed between the last
> > stable build and the GA build it should make no difference to your
> > builds.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1554279 (fixed with
> gcc-8.0.1-0.18.fc28) blocks builds packages using the gdal library, so
> an update (and override) would be useful

Jakub says this is not broken in F28:

https://bugzilla.redhat.com/show_bug.cgi?id=1554279#c3
-- 
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

[Bug 1557080] New: perl-Time-HiRes-1.9757 is available

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

Bug ID: 1557080
   Summary: perl-Time-HiRes-1.9757 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Time-HiRes
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 1.9757
Current version/release in rawhide: 1.9756-1.fc29
URL: http://search.cpan.org/dist/Time-HiRes/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/3466/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1557083] New: perl-Test-Inter-1.07 is available

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

Bug ID: 1557083
   Summary: perl-Test-Inter-1.07 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Test-Inter
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 1.07
Current version/release in rawhide: 1.06-10.fc28
URL: http://search.cpan.org/dist/Test-Inter/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/3397/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1557074] New: perl-pmtools-2.2.0 is available

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

Bug ID: 1557074
   Summary: perl-pmtools-2.2.0 is available
   Product: Fedora
   Version: rawhide
 Component: perl-pmtools
  Keywords: FutureFeature, Triaged
  Assignee: de...@fateyev.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, jose.p.oliveira@gmail.com,
perl-devel@lists.fedoraproject.org,
tcall...@redhat.com



Latest upstream release: 2.2.0
Current version/release in rawhide: 2.0.0-11.fc28
URL: http://search.cpan.org/dist/pmtools/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/13293/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1557071] New: perl-Email-Address-XS-1.03 is available

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

Bug ID: 1557071
   Summary: perl-Email-Address-XS-1.03 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Email-Address-XS
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 1.03
Current version/release in rawhide: 1.02-2.fc28
URL: http://search.cpan.org/dist/Email-Address-XS/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/15740/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: new section for 'Join the package collection maintainers'

2018-03-15 Thread René Genz

On 15.03.2018 17:09, Jonathan Wakely wrote:
> On 15/03/18 00:54 +0100, René Genz wrote:
>> On 14.03.2018 14:40, Jonathan Wakely wrote:
>>> On 14/03/18 01:02 +0100, René Genz wrote:
 On 13.03.2018 15:13, Jonathan Wakely wrote:
> On 12/03/18 21:02 -0300, Athos Ribeiro wrote:
[snip]
>>
>> Taking feedback from Athos and you into account here is a new proposal:
>> ---8<---
>> 3. One-off contributions
>>
>> Changes to existing packages can be suggested by submitting > (https://docs.pagure.org/pagure/usage/pull_requests.html)>.
>> You must have a  to create a pull 
>> request.
>>
>> If your account is not a member of the 'packager' group:
>> * cloning your fork works only with the HTTPS URL and
> 
> What is "your fork"? Nothing on this page talks about having a fork.

Package maintainers do not need a fork because they can write to the repository.
One-off contributors use their copy of the project (="fork") to contribute 
changes to the project with the help of pull requests.
On the website of the "pull request" link the text "Create a Fork on Pagure" 
links to:
https://docs.pagure.org/pagure/usage/forks.html#create-fork

> And since you can't write to it, there is not point creating your own
> fork. You might as well just create the fork somewhere else like
> pagure.io
> 
> Explaining that you can't write to your fork is not necessary if you
> don't encourage people to create useless forks.
On the one hand explaining the situation might ease confusion why an external 
Git hosting platform must be used.
On the other hand the text is much shorter.
OK, let us use a shorter version.

> So I still think my previous suggestion is better, with one small
> correction:
> 
> Changes to existing packages can be suggested by submitting  requests (https://docs.pagure.org/pagure/usage/pull_requests.html)>.
> You must have a  to create
> a pull request. If your account is not in the 'packager' group then
> you cannot push changes to forks on src.fedoraproject.org so must use
> an external Git hosting platform (e.g. https://pagure.io/new) and use
> a  (https://docs.pagure.org/pagure/usage/pull_requests.html#remote-git-to-pagure-pull-request)>.

I made some minor changes (add a link, add "you", add a comma (because the last 
sentence is a conditional sentence to me)):
---8<---
3. One-off contributions
Changes to https://src.fedoraproject.org/browse/projects/)> 
can be suggested by submitting https://docs.pagure.org/pagure/usage/pull_requests.html)>.
You must have a  to create a pull 
request.
If your account is not in the 'packager' group, then you cannot push changes to 
forks on src.fedoraproject.org so you must use an external Git hosting platform 
(e.g. https://pagure.io/new) and use https://docs.pagure.org/pagure/usage/pull_requests.html#remote-git-to-pagure-pull-request)>.
---8<---
Is it OK?
-- 
Kind regards,
René
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Goodbye nvr.rsplit('-', 2), hello modularity

2018-03-15 Thread langdon


On 03/15/2018 04:31 PM, Simo Sorce wrote:

On Thu, 2018-03-15 at 14:06 -0400, Randy Barlow wrote:

On 03/15/2018 12:28 PM, Chuck Anderson wrote:

: doesn't work very well in filenames due to it being a pathname separator in 
some filesystems among other things.

It sounds like this breaks a great deal of tooling. Can we reconsider
switching away from - separators in modules? Is allowing streams to have
-'s in them important enough to break so many tools?

I vote for using ⨊ as the separator, makes things easier :-)

Simo.

kidding aside, we are trying to get metadata forced in to the name 
"field"[1] in to proper metadata fields rather than just mangling the 
names. As a result, we end up with more fields and we don't have to 
guess what they are based on conventions.


I also am not sure why we wouldn't want to have hyphens in the names of 
modules. For example, a package for "react-native". We even say in the 
naming guidelines "When naming packages for Fedora, the maintainer must 
use the dash '-' as the delimiter for name parts." [2]. Although, this 
is a bit unclear as to whether they mean "base name" or the overall rpm 
name, from context, I think it is base name.


I could see an argument for using periods as the metadata separator, 
similar to rpms. However, this might cause confusion with what the 
elements of the metadata "mean" if they are not the same as (and in the 
same order as) the elements of an rpm "name".


We chose a colon & slash (for profile names) somewhat based on the 
practice(s) of docker. However, the dnf team made the ultimate choice, 
so their opinion on the subject matters.


Langdon

[1]: what is referred to in the naming guidelines as the "base name" as 
distinct from the full name of the rpm which would include N,V, & R


[2]: 
https://fedoraproject.org/wiki/Packaging:Naming?rd=Packaging:NamingGuidelines


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

Re: QMake equivalent of CMake flag -DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir}

2018-03-15 Thread Germano Massullo

upstream made a patch
https://github.com/open-eid/chrome-token-signing/issues/80#issuecomment-373545367
but it looks like it does not work.
Could you please check if I made any mistake in applying the patch in
the RPM?

failed build
https://koji.fedoraproject.org/koji/taskinfo?taskID=25733909

Package tree
https://src.fedoraproject.org/rpms/webextension-token-signing/tree/f27

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

Fedora 28-20180315.n.0 compose check report

No missing expected images.

Failed openQA tests: 16/137 (x86_64), 5/23 (i386), 1/2 (arm)

ID: 204706  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/204706
ID: 204712  Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/204712
ID: 204727  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/204727
ID: 204738  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/204738
ID: 204741  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/204741
ID: 204743  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/204743
ID: 204744  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/204744
ID: 204745  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/204745
ID: 204746  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/204746
ID: 204758  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/204758
ID: 204762  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default_upload
URL: https://openqa.fedoraproject.org/tests/204762
ID: 204763  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default@uefi
URL: https://openqa.fedoraproject.org/tests/204763
ID: 204764  Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/204764
ID: 204777  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/204777
ID: 204787  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/204787
ID: 204811  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/204811
ID: 204824  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/204824
ID: 204835  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/204835
ID: 204850  Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/204850
ID: 204858  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/204858
ID: 204859  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/204859
ID: 204887  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/204887

Soft failed openQA tests: 68/137 (x86_64), 16/23 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 204698  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/204698
ID: 204699  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/204699
ID: 204701  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/204701
ID: 204702  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/204702
ID: 204704  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/204704
ID: 204705  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/204705
ID: 204718  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/204718
ID: 204721  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/204721
ID: 204722  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/204722
ID: 204723  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/204723
ID: 204724  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/204724
ID: 204725  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/204725
ID: 204760  Test: x86_64 AtomicHost-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/204760
ID: 204761  Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/204761
ID: 204771  Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/204771
ID: 204772  Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/204772
ID: 204773  Test: x86_64 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/204773
ID: 204774  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/204774
ID: 204775  Test: x86_64 universal

Fedora Rawhide-20180315.n.1 compose check report

2018-03-15 Thread Patrick マルタインアンドレアス Uiterwijk

No missing expected images.

Failed openQA tests: 84/137 (x86_64), 24/24 (i386), 1/2 (arm)

ID: 204419  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/204419
ID: 204420  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/204420
ID: 204422  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/204422
ID: 204423  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/204423
ID: 204425  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/204425
ID: 204426  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/204426
ID: 204439  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/204439
ID: 204442  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/204442
ID: 204443  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/204443
ID: 20  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/20
ID: 204445  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/204445
ID: 204446  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/204446
ID: 204448  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/204448
ID: 204449  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/204449
ID: 204459  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/204459
ID: 204460  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/204460
ID: 204461  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/204461
ID: 204462  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/204462
ID: 204463  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/204463
ID: 204464  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/204464
ID: 204465  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/204465
ID: 204466  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/204466
ID: 204467  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/204467
ID: 204468  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/204468
ID: 204471  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/204471
ID: 204479  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/204479
ID: 204480  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/204480
ID: 204482  Test: x86_64 AtomicHost-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/204482
ID: 204483  Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/204483
ID: 204484  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default_upload
URL: https://openqa.fedoraproject.org/tests/204484
ID: 204485  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default@uefi
URL: https://openqa.fedoraproject.org/tests/204485
ID: 204486  Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/204486
ID: 204493  Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/204493
ID: 204494  Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/204494
ID: 204495  Test: x86_64 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/204495
ID: 204496  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/204496
ID: 204497  Test: x86_64 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/204497
ID: 204498  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/204498
ID: 204499  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/204499
ID: 204500  Test: x86_64 universal install_blivet_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/204500
ID: 204501  Test: x86_64 universal install_blivet_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/204501
ID: 204502  Test: x86_64 universal

Re: GCC 8.0.1 updates in F28

2018-03-15 Thread Peter Robinson

On Thu, 15 Mar 2018, 10:26 Dan Horák,  wrote:

> On Thu, 15 Mar 2018 17:11:49 +
> Peter Robinson  wrote:
>
> > On Thu, Mar 15, 2018 at 6:25 AM, Vascom  wrote:
> > > Hi.
> > >
> > > GCC 8.0.1-0.16 in F28 repo is freezed until F28 release?
> > > Or it will be updated soon so we can build some packages failed to
> > > build now?
> > > Or better use build override new gcc for this packages?
> >
> > Is there a particular bug fix that you need in the GA release you need
> > for building against? The gcc release in stable is pretty close to GA
> > so unless there's a specific bug that was fixed between the last
> > stable build and the GA build it should make no difference to your
> > builds.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1554279 (fixed with
> gcc-8.0.1-0.18.fc28) blocks builds packages using the gdal library, so
> an update (and override) would be useful
>

Makes sense, FE blocker would be useful for that then.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

2018-03-15 Thread Randy Barlow

On 03/15/2018 04:57 PM, Mohan Boddu wrote:
>> As one of the Bodhi contributors, I am inclined to suggest that we could
>> use Bodhi on Rawhide, similar to how we use it for our stable/branched
>> releases, with more relaxed rules (perhaps 1 day in testing or something
>> simple).

> We need a better approach for this, since I am not exactly sure what this
> solve as it just waiting for only 1 day.

It will introduce automated test gating, which will help identify a few
common problems (like missing dependencies). As mentioned elsewhere in
the thread, we wouldn't even have to make it wait a day if we don't want
to - we could send it on its way once tests pass (this would simply be a
matter of policy).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

2018-03-15 Thread Mohan Boddu

> Greetings fellow Fedorans!
> 
> I would like to kick off a general discussion about how we might gate
> packages in Rawhide. I think it would be nice to get something in place
> for the Fedora 29 timeframe.
> 
> As one of the Bodhi contributors, I am inclined to suggest that we could
> use Bodhi on Rawhide, similar to how we use it for our stable/branched
> releases, with more relaxed rules (perhaps 1 day in testing or something
> simple).
We need a better approach for this, since I am not exactly sure what this
solve as it just waiting for only 1 day.
> 
> It may be possible to automate the process a bit to make it less heavy
> for developers, though there is some complication for multi-package
> updates (more on that in a bit). For simple package updates, we may be
> able to detect new commits on dist-git, and react to those by
> automatically starting a Koji build, and automatically filing a Bodhi
> update when that build is complete. I think that would be pretty nice,
> and pingou created a PoC[0] to do this about a year ago.
I am not sure if this is possible with arbitrary branches.
People can now build from different branches that does not follow
fedora release branches, so it will be difficult to identify which buildroot
to build it against. And pingou is planning to update pagure over dist-git to
able to build from one branch rather than different branches.
> 
> Multi-package updates won't be so easy though. It's not uncommon for us
> to need to update packages together, and the above workflow would be
> problematic since it would result in updates with single packages in
> them rather than updates with multiple packages. Of course, buildroot
> overrides would be a problem too, since multi-package updates often
> depend on each other at build time too.
> 
> We could create some way for packagers to indicate that a commit (or
> possibly even a whole repo) is not intended to be "autobuilt/updated".
> If the packager indicates this then their builds would go into a
> rawhide-pending (similar to what we do for f27 today). Once they have
> all their builds (and buildroot overrides) the way they want them, they
> can create the update.
Same as my above comment.
> 
> Another idea that was tossed around in some chats I had with people
> about this involved a system for packagers to use to create Koji side
> tags. Bodhi manages BuildRoot Overrides today (with expirations), so
> perhaps Bodhi could be expanded to also manage Koji side tags (also with
> expirations). I can't remember all the details about this approach or
> why it was suggested over the former approach, but I wanted to list it
> to invite others to chew on it and see if it could work.
> 
> If you have other suggestions on how we might gate packages in Rawhide
> that are wildly different than the above, please feel free to share!
> 
> 
> [0] https://pagure.io/fedobuild
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Goodbye nvr.rsplit('-', 2), hello modularity

2018-03-15 Thread Simo Sorce

On Thu, 2018-03-15 at 14:06 -0400, Randy Barlow wrote:
> On 03/15/2018 12:28 PM, Chuck Anderson wrote:
> > : doesn't work very well in filenames due to it being a pathname separator 
> > in some filesystems among other things.
> 
> It sounds like this breaks a great deal of tooling. Can we reconsider
> switching away from - separators in modules? Is allowing streams to have
> -'s in them important enough to break so many tools?

I vote for using ⨊ as the separator, makes things easier :-)

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: f28 and rawhide ignoring static ip settings

2018-03-15 Thread Arnoldas S.

On Thu, Mar 15, 2018 at 9:27 PM, Patrick マルタインアンドレアス Uiterwijk <
puiterw...@redhat.com> wrote:

> > On 03/15/2018 01:23 PM, Tomasz Torcz ️ wrote:
> >
> > It's not. Now it's enp0s3.
> >
> > And renaming /etc/sysconfig/network-scripts/ifcfg-ens3 to ifcfg-enp0s3
> > doesn't do anything.
>
> Note that the files themselves also contain a DEVICE= line that would need
> to be updated for it to apply again.
>
> Patrick
>

Hello. Mine is enp4s0.

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

Orphaned jemmy

2018-03-15 Thread Omair Majid

I no longer have the time/resources/interest to maintain jemmy:
https://src.fedoraproject.org/rpms/jemmy/

I have orphaned it. If anyone wants to take over maintainership, please
do so.

Thanks,
Omair

-- 
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 28 compose report: 20180315.n.0 changes

2018-03-15 Thread Fedora Branched Report

OLD: Fedora-28-20180314.n.2
NEW: Fedora-28-20180315.n.0

= SUMMARY =
Added images:2
Dropped images:  0
Added packages:  0
Dropped packages:1
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:121.15 MiB
Size of upgraded packages:   0 B
Size of downgraded packages: 0 B

Size change of upgraded packages:   0 B
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Server raw-xz aarch64
Path: Server/aarch64/images/Fedora-Server-28-20180315.n.0.aarch64.raw.xz
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-28-20180315.n.0.s390x.tar.xz

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: nodejs-1:8.9.4-3.fc28
Summary: JavaScript runtime
RPMs:nodejs nodejs-devel nodejs-docs npm
Size:121.15 MiB


= UPGRADED PACKAGES =

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

Re: f28 and rawhide ignoring static ip settings

> On 03/15/2018 01:23 PM, Tomasz Torcz ️ wrote:
> 
> It's not. Now it's enp0s3.
> 
> And renaming /etc/sysconfig/network-scripts/ifcfg-ens3 to ifcfg-enp0s3
> doesn't do anything.

Note that the files themselves also contain a DEVICE= line that would need to 
be updated for it to apply again.

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

Re: f28 and rawhide ignoring static ip settings

On Thu, 2018-03-15 at 14:40 -0400, Kaleb S. KEITHLEY wrote:
> On 03/15/2018 01:23 PM, Tomasz Torcz ️ wrote:
> > On Thu, Mar 15, 2018 at 01:13:09PM -0400, Kaleb S. KEITHLEY wrote:
> > > 
> > > Did I miss something?
> > > 
> > > Both machines were dnf system-upgraded from f27. Static IP settings were
> > > set at f27 install time and worked before the respective upgrades.
> > > 
> > > f28 was working correctly until a couple of days ago to the best of my
> > > knowledge.
> > > 
> > > E.g.——
> > > 
> > > %cat /etc/sysconfig/network-scripts/ifcfg-ens3
> > > ...
> > > IPADDR=192.168.122.26
> > > 
> > > But it's getting 192.168.122.169 (from dhcp?)
> > 
> >   Could you double check if your interface is still called 'ens3'?
> > There's a bug in latest systemd which breaks interface naming:
> > https://github.com/systemd/systemd/issues/8446
> 
> It's not. Now it's enp0s3.
> 
> And renaming /etc/sysconfig/network-scripts/ifcfg-ens3 to ifcfg-enp0s3
> doesn't do anything.

You'd have to change the DEVICE= line in it as well / instead.
-- 
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

Re: f28 and rawhide ignoring static ip settings

2018-03-15 Thread Kaleb S. KEITHLEY

On 03/15/2018 01:23 PM, Tomasz Torcz ️ wrote:
> On Thu, Mar 15, 2018 at 01:13:09PM -0400, Kaleb S. KEITHLEY wrote:
>>
>> Did I miss something?
>>
>> Both machines were dnf system-upgraded from f27. Static IP settings were
>> set at f27 install time and worked before the respective upgrades.
>>
>> f28 was working correctly until a couple of days ago to the best of my
>> knowledge.
>>
>> E.g.——
>>
>> %cat /etc/sysconfig/network-scripts/ifcfg-ens3
>> ...
>> IPADDR=192.168.122.26
>>
>> But it's getting 192.168.122.169 (from dhcp?)
> 
>   Could you double check if your interface is still called 'ens3'?
> There's a bug in latest systemd which breaks interface naming:
> https://github.com/systemd/systemd/issues/8446

It's not. Now it's enp0s3.

And renaming /etc/sysconfig/network-scripts/ifcfg-ens3 to ifcfg-enp0s3
doesn't do anything.

Thanks

--

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

Re: Goodbye nvr.rsplit('-', 2), hello modularity

2018-03-15 Thread Randy Barlow

On 03/15/2018 12:28 PM, Chuck Anderson wrote:
> : doesn't work very well in filenames due to it being a pathname separator in 
> some filesystems among other things.

It sounds like this breaks a great deal of tooling. Can we reconsider
switching away from - separators in modules? Is allowing streams to have
-'s in them important enough to break so many tools?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: f28 and rawhide ignoring static ip settings

On Thu, 2018-03-15 at 18:23 +0100, Tomasz Torcz ️ wrote:
> On Thu, Mar 15, 2018 at 01:13:09PM -0400, Kaleb S. KEITHLEY wrote:
> > 
> > Did I miss something?
> > 
> > Both machines were dnf system-upgraded from f27. Static IP settings were
> > set at f27 install time and worked before the respective upgrades.
> > 
> > f28 was working correctly until a couple of days ago to the best of my
> > knowledge.
> > 
> > E.g.——
> > 
> > %cat /etc/sysconfig/network-scripts/ifcfg-ens3
> > ...
> > IPADDR=192.168.122.26
> > 
> > But it's getting 192.168.122.169 (from dhcp?)
> 
>   Could you double check if your interface is still called 'ens3'?
> There's a bug in latest systemd which breaks interface naming:
> https://github.com/systemd/systemd/issues/8446

This looks like something we should probably fix for Beta, could
someone file an RH bug and nominate it as an FE? Thanks!
-- 
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

Re: GCC 8.0.1 updates in F28

2018-03-15 Thread Dan Horák

On Thu, 15 Mar 2018 17:11:49 +
Peter Robinson  wrote:

> On Thu, Mar 15, 2018 at 6:25 AM, Vascom  wrote:
> > Hi.
> >
> > GCC 8.0.1-0.16 in F28 repo is freezed until F28 release?
> > Or it will be updated soon so we can build some packages failed to
> > build now?
> > Or better use build override new gcc for this packages?
> 
> Is there a particular bug fix that you need in the GA release you need
> for building against? The gcc release in stable is pretty close to GA
> so unless there's a specific bug that was fixed between the last
> stable build and the GA build it should make no difference to your
> builds.

https://bugzilla.redhat.com/show_bug.cgi?id=1554279 (fixed with
gcc-8.0.1-0.18.fc28) blocks builds packages using the gdal library, so
an update (and override) would be useful


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

Re: new section for 'Join the package collection maintainers'

2018-03-15 Thread Jonathan Wakely


On 15/03/18 16:24 +, Tom Hughes wrote:

On 15/03/18 16:09, Jonathan Wakely wrote:


And since you can't write to it, there is not point creating your own
fork. You might as well just create the fork somewhere else like
pagure.io

Explaining that you can't write to your fork is not necessary if you
don't encourage people to create useless forks.


The intention is that you should be able to. There is a ticket somewhere
where Fesco said that people should be able to push to their own forks
without being in the packager group.

It just hasn't actually been implemented yet.

Here are the relevant tickets:

https://pagure.io/fesco/issue/1770
https://pagure.io/fedora-infrastructure/issue/6361


But as Athos said, when that happens the whole thing will need to be
rewritten anyway. Until then it doesn't add anything very useful to
the "here's how to make a one-off contribution" docs.


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

Re: f28 and rawhide ignoring static ip settings

2018-03-15 Thread Tomasz Torcz ️

On Thu, Mar 15, 2018 at 01:13:09PM -0400, Kaleb S. KEITHLEY wrote:
> 
> Did I miss something?
> 
> Both machines were dnf system-upgraded from f27. Static IP settings were
> set at f27 install time and worked before the respective upgrades.
> 
> f28 was working correctly until a couple of days ago to the best of my
> knowledge.
> 
> E.g.——
> 
> %cat /etc/sysconfig/network-scripts/ifcfg-ens3
> ...
> IPADDR=192.168.122.26
> 
> But it's getting 192.168.122.169 (from dhcp?)

  Could you double check if your interface is still called 'ens3'?
There's a bug in latest systemd which breaks interface naming:
https://github.com/systemd/systemd/issues/8446

-- 
Tomasz TorczOnly gods can safely risk perfection,
xmpp: zdzich...@chrome.pl it's a dangerous thing for a man.  -- Alia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GCC 8.0.1 updates in F28

2018-03-15 Thread Vascom

OK.
It is not so important build, only for clearness.

чт, 15 мар. 2018 г., 20:12 Peter Robinson :

> On Thu, Mar 15, 2018 at 6:25 AM, Vascom  wrote:
> > Hi.
> >
> > GCC 8.0.1-0.16 in F28 repo is freezed until F28 release?
> > Or it will be updated soon so we can build some packages failed to build
> > now?
> > Or better use build override new gcc for this packages?
>
> Is there a particular bug fix that you need in the GA release you need
> for building against? The gcc release in stable is pretty close to GA
> so unless there's a specific bug that was fixed between the last
> stable build and the GA build it should make no difference to your
> builds.
> ___
> 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 rawhide compose report: 20180315.n.1 changes

2018-03-15 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20180314.n.2
NEW: Fedora-Rawhide-20180315.n.1

= SUMMARY =
Added images:1
Dropped images:  6
Added packages:  3
Dropped packages:0
Upgraded packages:   83
Downgraded packages: 1

Size of added packages:  6.45 MiB
Size of dropped packages:0 B
Size of upgraded packages:   2.16 GiB
Size of downgraded packages: 86.24 KiB

Size change of upgraded packages:   175.97 MiB
Size change of downgraded packages: -372.19 KiB

= ADDED IMAGES =
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20180315.n.1.s390x.tar.xz

= DROPPED IMAGES =
Image: Modular boot x86_64
Path: Modular/x86_64/iso/Fedora-Modular-netinst-x86_64-Rawhide-20180314.n.2.iso
Image: Modular boot aarch64
Path: 
Modular/aarch64/iso/Fedora-Modular-netinst-aarch64-Rawhide-20180314.n.2.iso
Image: Modular boot i386
Path: Modular/i386/iso/Fedora-Modular-netinst-i386-Rawhide-20180314.n.2.iso
Image: Modular boot ppc64
Path: Modular/ppc64/iso/Fedora-Modular-netinst-ppc64-Rawhide-20180314.n.2.iso
Image: Modular boot ppc64le
Path: 
Modular/ppc64le/iso/Fedora-Modular-netinst-ppc64le-Rawhide-20180314.n.2.iso
Image: Modular boot s390x
Path: Modular/s390x/iso/Fedora-Modular-netinst-s390x-Rawhide-20180314.n.2.iso

= ADDED PACKAGES =
Package: nodejs-xdg-basedir-3.0.0-2.fc29
Summary: A JavaScript library to work with XDG Base Directory paths
RPMs:nodejs-xdg-basedir
Size:9.75 KiB

Package: python-flask-htmlmin-1.3.1-1.fc29
Summary: Flask html response minifier
RPMs:python2-flask-htmlmin python3-flask-htmlmin
Size:24.17 KiB

Package: quentier-0.4.0-0.1.20180301.git8226e31.fc29
Summary: Cross-platform desktop Evernote client
RPMs:quentier
Size:6.42 MiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  CuraEngine-lulzbot-1:2.6.69-1.fc29
Old package:  CuraEngine-lulzbot-1:2.6.66-3.fc28
Summary:  Engine for processing 3D models into G-code instructions for 3D 
printers
RPMs: CuraEngine-lulzbot
Size: 3.85 MiB
Size change:  2.05 KiB
Changelog:
  * Wed Mar 14 2018 Tom Callaway <s...@fedoraproject.org> - 1:2.6.69-1
  - update to 2.6.69


Package:  R-BH-1.66.0.1-1.fc29
Old package:  R-BH-1.62.0.1-3.fc27
Summary:  Boost C++ Header Files for R
RPMs: R-BH-devel
Size: 8.79 MiB
Size change:  801.29 KiB
Changelog:
  * Wed Feb 07 2018 Fedora Release Engineering <rel...@fedoraproject.org> - 
1.62.0.1-4
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild

  * Wed Mar 14 2018 Tom Callaway <s...@fedoraproject.org> - 1.66.0.1-1
  - update to 1.66.0-1


Package:  R-BiocGenerics-0.24.0-1.fc29
Old package:  R-BiocGenerics-0.22.0-2.fc27
Summary:  Generic functions for Bioconductor
RPMs: R-BiocGenerics
Size: 589.92 KiB
Size change:  2.97 KiB
Changelog:
  * Wed Feb 07 2018 Fedora Release Engineering <rel...@fedoraproject.org> - 
0.22.0-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild

  * Wed Mar 14 2018 Tom Callaway <s...@fedoraproject.org> - 0.24.0-1
  - update to 0.24.0


Package:  R-BiocParallel-1.12.0-1.fc29
Old package:  R-BiocParallel-1.10.1-2.fc27
Summary:  Bioconductor facilities for parallel evaluation
RPMs: R-BiocParallel
Size: 5.42 MiB
Size change:  4.76 MiB
Changelog:
  * Wed Feb 07 2018 Fedora Release Engineering <rel...@fedoraproject.org> - 
1.10.1-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild

  * Wed Mar 14 2018 Tom Callaway <s...@fedoraproject.org> - 1.12.0-1
  - update to 1.12.0


Package:  R-GenomeInfoDb-1.14.0-1.fc29
Old package:  R-GenomeInfoDb-1.12.1-2.fc27
Summary:  Utilities for manipulating chromosome and other 'seqname' 
identifiers
RPMs: R-GenomeInfoDb
Size: 3.41 MiB
Size change:  70.85 KiB
Changelog:
  * Wed Feb 07 2018 Fedora Release Engineering <rel...@fedoraproject.org> - 
1.12.1-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild

  * Wed Mar 14 2018 Tom Callaway <s...@fedoraproject.org> - 1.14.0-1
  - update to 1.14.0


Package:  R-GenomeInfoDbData-1.0.0-1.fc29
Old package:  R-GenomeInfoDbData-0.99.0-2.fc27
Summary:  Species and taxonomy ID look up tables used by GenomeInfoDb
RPMs: R-GenomeInfoDbData
Size: 17.13 MiB
Size change:  1.63 MiB
Changelog:
  * Wed Feb 07 2018 Fedora Release Engineering <rel...@fedoraproject.org> - 
0.99.0-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild

  * Wed Mar 14 2018 Tom Callaway <s...@fedoraproject.org> - 1.0.0-1
  - update to 1.0.0


Package:  R-S4Vectors-0.16.0-1.fc29
Old package:  R-S4Vectors-0.14.3-3.fc27
Summary:  S4 implementation of vectors and lists
RPMs: R-S4Vectors R-S4Vectors-devel
Size: 8.27 MiB
Size change:  5.43 KiB
Changelog:
  * Wed Feb 07 2018 Fedora Release Engineering <rel...@fedorapr

f28 and rawhide ignoring static ip settings

2018-03-15 Thread Kaleb S. KEITHLEY


Did I miss something?

Both machines were dnf system-upgraded from f27. Static IP settings were
set at f27 install time and worked before the respective upgrades.

f28 was working correctly until a couple of days ago to the best of my
knowledge.

E.g.——

%cat /etc/sysconfig/network-scripts/ifcfg-ens3
...
BOOTPROTO=none
...
IPADDR=192.168.122.26
...

But it's getting 192.168.122.169 (from dhcp?)


Thanks

--

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

Re: GCC 8.0.1 updates in F28

2018-03-15 Thread Peter Robinson

On Thu, Mar 15, 2018 at 6:25 AM, Vascom  wrote:
> Hi.
>
> GCC 8.0.1-0.16 in F28 repo is freezed until F28 release?
> Or it will be updated soon so we can build some packages failed to build
> now?
> Or better use build override new gcc for this packages?

Is there a particular bug fix that you need in the GA release you need
for building against? The gcc release in stable is pretty close to GA
so unless there's a specific bug that was fixed between the last
stable build and the GA build it should make no difference to your
builds.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: glibc-headers is missing rpc/rpc.h in rawhide

2018-03-15 Thread Sérgio Basto

On Thu, 2018-03-15 at 12:49 +0100, Jan Synacek wrote:
> On Thu, Mar 15, 2018 at 11:43 AM, Dan Horák  wrote:
> > On Thu, 15 Mar 2018 11:30:32 +0100
> > Jan Synacek  wrote:
> > 
> > > Did I miss something? The xinetd package cannot be built because
> > > of
> > > that.
> > 
> > https://fedoraproject.org/wiki/Changes/SunRPCRemoval
> 
> So I missed something. Thank you for pointing me to this!

Player package solved the problem with these 2 commits [1] 

[1]
https://src.fedoraproject.org/rpms/player/c/d9eb02da8958a22915a6fd0b24f99397b0ac84e4?branch=master
https://src.fedoraproject.org/rpms/player/c/e76cbb76eba1f08d37ff49d1e34e0670b05af975?branch=master

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GCC 8.0.1 updates in F28

2018-03-15 Thread Sérgio Basto

On Thu, 2018-03-15 at 06:25 +, Vascom wrote:
> Hi.
> 
> GCC 8.0.1-0.16 in F28 repo is freezed until F28 release?
> Or it will be updated soon so we can build some packages failed to
> build now?
> Or better use build override new gcc for this packages?

the freeze is only until beta compose is consider gold .   F28 repo is
freezed until beta announce . 

But we may nominate one gcc update , as bug blocker and will include in
 beta compose. Depends on severity of the bug ... 

Cheers, 
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Goodbye nvr.rsplit('-', 2), hello modularity

2018-03-15 Thread Chuck Anderson

On Thu, Mar 15, 2018 at 04:19:46PM +, Daniel P. Berrangé wrote:
> On Thu, Mar 15, 2018 at 04:14:34PM +0100, Patrick Uiterwijk wrote:
> > For user consumption, they are Name:Stream:Version:Context, so you may
> > need to manually convert between one representation and the other if
> > you need to look up in koji or other systems versus display to users.
> 
> What stops us using Name:Stream:Version:Context everywhere,
> or  Name:Stream:Context-Version or Name:Stream-Version-Context
> if we need it closer to RPM NVR style ?

: doesn't work very well in filenames due to it being a pathname separator in 
some filesystems among other things.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Goodbye nvr.rsplit('-', 2), hello modularity

2018-03-15 Thread Patrick マルタインアンドレアス Uiterwijk

On Thu, 2018-03-15 at 16:14 +0100, Patrick Uiterwijk wrote:
> One of the interesting things they wanted to also allow: dashes in streams.
> As a consequence, when you get an N-S-V.C as modules are represented
> in Koji builds, doing a .rsplit('-', 2) will not give you Name,
> Stream, Version.Context per se.
> You could totally have a module called
> nodejs-my-stream-5-20170314.abcd, with name=nodejs,
> stream=my-stream-5, version=20170314, context=abcd.
> There is no way for you to independently figure out what the NSVC
> components are, you will need to ask Koji, and use its name, version
> and release fields (with name=name, version=stream,
> release=version(.context)).

...

> I hope that this is useful information for anyone else finding
> themselves having to parse NVRs/NSVs.

1. Yes, it helps, thanks.
2. This is goddamn terrible and whoever is responsible should be
ashamed.
-- 
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

Re: new section for 'Join the package collection maintainers'

2018-03-15 Thread Tom Hughes


On 15/03/18 16:09, Jonathan Wakely wrote:


And since you can't write to it, there is not point creating your own
fork. You might as well just create the fork somewhere else like
pagure.io

Explaining that you can't write to your fork is not necessary if you
don't encourage people to create useless forks.


The intention is that you should be able to. There is a ticket somewhere
where Fesco said that people should be able to push to their own forks
without being in the packager group.

It just hasn't actually been implemented yet.

Here are the relevant tickets:

https://pagure.io/fesco/issue/1770
https://pagure.io/fedora-infrastructure/issue/6361

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Goodbye nvr.rsplit('-', 2), hello modularity

2018-03-15 Thread Daniel P . Berrangé

On Thu, Mar 15, 2018 at 04:14:34PM +0100, Patrick Uiterwijk wrote:
> Hi all,
> 
> If you maintain any application in Fedora Infra (or outside) that
> tries to parse things out of RPM names, you might be interested in
> this.
> 
> For those wondering where I've been spending most of my time the last
> few weeks: I've been deep in the internals of Bodhi fixing all kinds
> of issues I've found between it and Modularity (turns out enabling
> composing was just the beginning).
> 
> At some point, I was informed that for modules, they are throwing all
> kinds of old assumptions out of the door.
> One of those is the good old Name-Version-Release in RPM land.
> 
> Modules do not have an NVR, they have an NSVC: Name, Stream, Version, Context.
> Name is the name of the module ("nodejs").
> Stream is a stream, like "6", "7" or "8", these are crucial for the
> parallel availability that modules are trying to accomplish.
> Version is a date/time stamp, used to indicate new versions in the
> same name-stream.
> Context is a hash of some information in the built module that makes
> it so that the nodejs-6-20170314 built for Fedora 28 has a different
> identifier than the one built for Fedora 29.
> 
> There are some additional fields for installed things (arch and
> profile), but those aren't really important for things trying to
> parse/show module names I think.
> 
> One of the interesting things they wanted to also allow: dashes in streams.
> As a consequence, when you get an N-S-V.C as modules are represented
> in Koji builds, doing a .rsplit('-', 2) will not give you Name,
> Stream, Version.Context per se.
> You could totally have a module called
> nodejs-my-stream-5-20170314.abcd, with name=nodejs,
> stream=my-stream-5, version=20170314, context=abcd.
> There is no way for you to independently figure out what the NSVC
> components are, you will need to ask Koji, and use its name, version
> and release fields (with name=name, version=stream,
> release=version(.context)).

Have a non-deterministic naming format whose ambiguity you can only
resolve by querying Koji feels like a pretty undesirable thing. At
least it doesn't leak into the RPMs themselves, but from a developer
pov it would be really nice to be able to unambiguously parse the
module names into their parts without calling out to RPC services.
There may be contexts where you want to do such things where you
would rather not have outbound network connectivity to anywhere,
let along Koji.

If we need to allow '-' in the streams, could we use something
other than '-' as the field separator for the module names to
remove ambiguity ?

> For user consumption, they are Name:Stream:Version:Context, so you may
> need to manually convert between one representation and the other if
> you need to look up in koji or other systems versus display to users.

What stops us using Name:Stream:Version:Context everywhere,
or  Name:Stream:Context-Version or Name:Stream-Version-Context
if we need it closer to RPM NVR style ?


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: new section for 'Join the package collection maintainers'

2018-03-15 Thread Jonathan Wakely

On 15/03/18 00:54 +0100, René Genz wrote:

On 14.03.2018 14:40, Jonathan Wakely wrote:

On 14/03/18 01:02 +0100, René Genz wrote:

On 13.03.2018 15:13, Jonathan Wakely wrote:

On 12/03/18 21:02 -0300, Athos Ribeiro wrote:

[snip]

You could add a link saying something like "To make a one-off
contribution see below" to skip past the main content of the page, but
the new content should still come after the main content.

I will add it to the end of the table of contents and the end of the page. Less
links that could break.

[snip]

you cannot create a fork on src.fedoraproject.org so must use an

You can create a fork on src.fedoraproject.org if your account is not a member
of the 'packager' group.

Really?

Yes.

Wow, that's weird.

For this account and repo:
* up- and downloading with the SSH URL fails
* downloading with the HTTPS URL works
(I guess uploading with the HTTPS URL is not supported, like it is in pagure.io)

That's not creating a fork on src.fedoraproject.org, it's cloning the
repo onto your local machine.

True, I wanted to describe the behavior of the repo for accounts without
'packager' group membership.

Taking feedback from Athos and you into account here is a new proposal:
---8<---
3. One-off contributions

Changes to existing packages can be suggested by submitting https://docs.pagure.org/pagure/usage/pull_requests.html)>.
You must have a to create a pull
request.

If your account is not a member of the 'packager' group:
* cloning your fork works only with the HTTPS URL and

What is "your fork"? Nothing on this page talks about having a fork.

And since you can't write to it, there is not point creating your own
fork. You might as well just create the fork somewhere else like
pagure.io

Explaining that you can't write to your fork is not necessary if you
don't encourage people to create useless forks.

So I still think my previous suggestion is better, with one small
correction:

Changes to existing packages can be suggested by submitting https://docs.pagure.org/pagure/usage/pull_requests.html)>.
You must have a to create
a pull request. If your account is not in the 'packager' group then
you cannot push changes to forks on src.fedoraproject.org so must use
an external Git hosting platform (e.g. https://pagure.io/new) and use
a https://docs.pagure.org/pagure/usage/pull_requests.html#remote-git-to-pagure-pull-request)>.

(This just changes "cannot create a fork on src.fp.org" to "cannot
push changes to forks on src.fp.o" compared to my previous suggestion.

* you cannot write to your fork
That is why you must upload your changes to an external Git hosting platform (e.g.
https://pagure.io/new)>) and use a https://docs.pagure.org/pagure/usage/pull_requests.html#remote-git-to-pagure-pull-request)>.

The requirement for accounts to be a member of the 'packager' group in order to
be able to write to their forks on src.fedoraproject.org is being worked on.
---8<---

Anything that should be changed?
--
Kind regards,
René
___
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: Goodbye nvr.rsplit('-', 2), hello modularity

> On 15/03/18 15:30, Patrick Uiterwijk wrote:
> 
> Well currently at any rate? What's the long term story?
> 
> Only when some module rpms accidentally leaked into rawhide
> recently they definitely had the kind of rather unhelpful names
> that you described in your post and I got the impression at
> the time that it was anticipated they might come to rawhide
> for real at some point.

Note that the module builds I was talking about are the actual modules, not the 
module content.
The RPMs that ended up in rawhide standard repos (which was a bug, they should 
have gone to, and will go to a Modular side-repo), are standard RPMS with NVR 
like $packagename-$version-$release.module_$tag.
In other words, the packages that end up in the repos fit the NVR pattern, it's 
just that the release part has its .%{dist} replaced with .module_%{tag}.

My email was about module description builds as you'd submit them to Bodhi for 
example, like https://koji.fedoraproject.org/koji/buildinfo?buildID=1055963.

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

Re: Goodbye nvr.rsplit('-', 2), hello modularity

2018-03-15 Thread Nico Kadel-Garcia

On Thu, Mar 15, 2018 at 11:14 AM, Patrick Uiterwijk
 wrote:
> Hi all,
>
> If you maintain any application in Fedora Infra (or outside) that
> tries to parse things out of RPM names, you might be interested in
> this.
>
> For those wondering where I've been spending most of my time the last
> few weeks: I've been deep in the internals of Bodhi fixing all kinds
> of issues I've found between it and Modularity (turns out enabling
> composing was just the beginning).
>
> At some point, I was informed that for modules, they are throwing all
> kinds of old assumptions out of the door.
> One of those is the good old Name-Version-Release in RPM land.
>
> Modules do not have an NVR, they have an NSVC: Name, Stream, Version, Context.
> Name is the name of the module ("nodejs").
> Stream is a stream, like "6", "7" or "8", these are crucial for the
> parallel availability that modules are trying to accomplish.
> Version is a date/time stamp, used to indicate new versions in the
> same name-stream.
> Context is a hash of some information in the built module that makes
> it so that the nodejs-6-20170314 built for Fedora 28 has a different
> identifier than the one built for Fedora 29.

Isn't that what "%{dist}" is for? Do you have a pointer to where this
is laid out?

We've seen people try to re-invent version numbering before.with other
applications, to add features for their desired workflow. Examples
includes the hashes added to python module versions at pypi.org, which
seriously broke py2pack and forced them to add an impedance matching
utility on their website so the old tools continued to work. Is this a
really desirable change?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 7 updates-testing report

2018-03-15 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 1102  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 864  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 447  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 344  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 176  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
 113  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  63  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73ee944e65   
rootsh-1.5.3-17.el7
  18  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3e70a38ad4   
drupal7-7.57-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-815e0064e9   
tor-0.2.9.15-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f7a629b46f   
python-django16-1.6.11.7-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-635348eab4   
php-simplesamlphp-saml2_1-1.10.6-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7150fa5dce   
php-simplesamlphp-saml2-2.3.8-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-673b3314a1   
exim-4.90.1-3.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

dictd-1.12.1-20.el7
jwhois-4.0-46.el7
libmodulemd-1.1.0-1.el7
monitorix-3.10.1-1.el7

Details about builds:



 dictd-1.12.1-20.el7 (FEDORA-EPEL-2018-f4620ae6d6)
 DICT protocol (RFC 2229) server and command-line client

Update Information:

Fix packaging for EL-6 (don't confuse systemd service with the old initd
script).

References:

  [ 1 ] Bug #1444555 - dictd-server includes a wrong kind of initscript
https://bugzilla.redhat.com/show_bug.cgi?id=1444555




 jwhois-4.0-46.el7 (FEDORA-EPEL-2018-4408a2a797)
 Internet whois/nicname client

Update Information:

Add options to to force querying on ipv4 or ipv6 (patch by John Fawcett)

References:

  [ 1 ] Bug #1551215 - Enhancement to foce querying on ipv4 or ipv6
https://bugzilla.redhat.com/show_bug.cgi?id=1551215




 libmodulemd-1.1.0-1.el7 (FEDORA-EPEL-2018-32f78e466c)
 Module metadata manipulation library

Update Information:

* Adds support for handling modulemd-defaults YAML documents * Adds peek()/dup()
routines to all object properties * Adds Modulemd.Module.dup_nsvc() to retrieve
the canonical form of the unique module identifier. * Adds support for boolean
types in the XMD section




 monitorix-3.10.1-1.el7 (FEDORA-EPEL-2018-3f41541339)
 A free, open source, lightweight system monitoring tool

Update Information:

Prior Monitorix versions are vulnerable to cross-site scripting (XSS), caused by
improper validation of user-supplied input by the monitorix.cgi file. A remote
attacker could exploit this vulnerability using some of the arguments provided
(graph= or when=) in a specially-crafted URL to execute script in a victim's Web
browser within the security context of the hosting Web site, once the URL is
clicked. An attacker could use this vulnerability to steal the victim's cookie-
based authentication credentials.  I would like to thank Sebastian Gilon from
TestArmy for reporting that issue.  The rest of bugs fixed are, as always,
reflected in the Changes file.  All users still using older versions are advised
and encouraged to upgrade to this version, which resolves this security issue.

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

Re: Goodbye nvr.rsplit('-', 2), hello modularity

2018-03-15 Thread Tom Hughes


On 15/03/18 15:30, Patrick Uiterwijk wrote:



This does not affect traditional RPM/SRPM packages, right?


Correct, this only impacts modules.


Well currently at any rate? What's the long term story?

Only when some module rpms accidentally leaked into rawhide
recently they definitely had the kind of rather unhelpful names
that you described in your post and I got the impression at
the time that it was anticipated they might come to rawhide
for real at some point.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 6 updates-testing report

2018-03-15 Thread updates

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 974  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 864  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 836  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 447  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 176  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
  95  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e   
optipng-0.7.6-6.el6
  67  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462   
heimdal-7.5.0-1.el6
  62  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-752a7c9ad4   
rootsh-1.5.3-17.el6
  18  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-5d12c76136   
drupal7-7.57-1.el6
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-a27d71c715   
pax-utils-1.2.3-1.el6
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-4bcfff2d5e   
tor-0.2.9.15-1.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-0f3319c1ea   
php-simplesamlphp-saml2_1-1.10.6-1.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-57cbc61216   
php-simplesamlphp-saml2-2.3.8-1.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-910749f9c8   
exim-4.90.1-3.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

dictd-1.12.1-20.el6
monitorix-3.10.1-1.el6

Details about builds:



 dictd-1.12.1-20.el6 (FEDORA-EPEL-2018-229e4b4653)
 DICT protocol (RFC 2229) server and command-line client

Update Information:

Fix packaging for EL-6 (don't confuse systemd service with the old initd
script).

References:

  [ 1 ] Bug #1444555 - dictd-server includes a wrong kind of initscript
https://bugzilla.redhat.com/show_bug.cgi?id=1444555




 monitorix-3.10.1-1.el6 (FEDORA-EPEL-2018-10ff026fa8)
 A free, open source, lightweight system monitoring tool

Update Information:

Prior Monitorix versions are vulnerable to cross-site scripting (XSS), caused by
improper validation of user-supplied input by the monitorix.cgi file. A remote
attacker could exploit this vulnerability using some of the arguments provided
(graph= or when=) in a specially-crafted URL to execute script in a victim's Web
browser within the security context of the hosting Web site, once the URL is
clicked. An attacker could use this vulnerability to steal the victim's cookie-
based authentication credentials.  I would like to thank Sebastian Gilon from
TestArmy for reporting that issue.  The rest of bugs fixed are, as always,
reflected in the Changes file.  All users still using older versions are advised
and encouraged to upgrade to this version, which resolves this security issue.

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

Re: Fedora Atomic Host Two Week Release Announcement: 27.100

2018-03-15 Thread Sinny Kumari

On Thu, Mar 15, 2018 at 7:24 PM,   wrote:
>
> A new Fedora Atomic Host update is available via an OSTree update:
>
> Version: 27.100
> Commit(x86_64): 
> 326f62b93a5cc836c97d31e73a71b6b6b6955c0f225f7651b52a693718e6aa91
> Commit(aarch64): 
> ba2aa19d99466c53e614651f014c8b97ae1940f87885b7c7dfed1fb62ae91567
> Commit(ppc64le): 
> ca0ea3a6e15b6270aefe3c7b55ffbee3c8bd27707fd6d979cc66b39fc18fa5f4
>
>
> We are releasing images from multiple architectures but please note
> that x86_64 architecture is the only one that undergoes automated
> testing at this time.
>
> Existing systems can be upgraded in place via e.g. `atomic host upgrade`.
>
> Corresponding image media for new installations can be downloaded from:
>
> https://getfedora.org/en/atomic/download/
>
> Alternatively, image artifacts can be found at the following links:
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/Atomic/aarch64/iso/Fedora-Atomic-ostree-aarch64-27-20180314.0.iso
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/Atomic/ppc64le/iso/Fedora-Atomic-ostree-ppc64le-27-20180314.0.iso
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/Atomic/x86_64/iso/Fedora-Atomic-ostree-x86_64-27-20180314.0.iso
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/CloudImages/aarch64/images/Fedora-Atomic-27-20180314.0.aarch64.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/CloudImages/aarch64/images/Fedora-Atomic-27-20180314.0.aarch64.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/CloudImages/ppc64le/images/Fedora-Atomic-27-20180314.0.ppc64le.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/CloudImages/ppc64le/images/Fedora-Atomic-27-20180314.0.ppc64le.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/CloudImages/x86_64/images/Fedora-Atomic-27-20180314.0.x86_64.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/CloudImages/x86_64/images/Fedora-Atomic-27-20180314.0.x86_64.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/CloudImages/x86_64/images/Fedora-Atomic-Vagrant-27-20180314.0.x86_64.vagrant-libvirt.box
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/CloudImages/x86_64/images/Fedora-Atomic-Vagrant-27-20180314.0.x86_64.vagrant-virtualbox.box
>
> Respective signed CHECKSUM files can be found here:
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/Atomic/aarch64/iso/Fedora-Atomic-27-20180314.0-aarch64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/Atomic/ppc64le/iso/Fedora-Atomic-27-20180314.0-ppc64le-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/Atomic/x86_64/iso/Fedora-Atomic-27-20180314.0-x86_64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/CloudImages/aarch64/images/Fedora-CloudImages-27-20180314.0-aarch64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/CloudImages/ppc64le/images/Fedora-CloudImages-27-20180314.0-ppc64le-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/CloudImages/x86_64/images/Fedora-CloudImages-27-20180314.0-x86_64-CHECKSUM
>
> For direct download, the "latest" targets are always available here:
> https://getfedora.org/atomic_iso_latest
> https://getfedora.org/atomic_qcow2_latest
> https://getfedora.org/atomic_raw_latest
> https://getfedora.org/atomic_vagrant_libvirt_latest
> https://getfedora.org/atomic_vagrant_virtualbox_latest
>
> Filename fetching URLs are available here:
> https://getfedora.org/atomic_iso_latest_filename
> https://getfedora.org/atomic_qcow2_latest_filename
> https://getfedora.org/atomic_raw_latest_filename
> https://getfedora.org/atomic_vagrant_libvirt_latest_filename
> https://getfedora.org/atomic_vagrant_virtualbox_latest_filename
>
> For more information about the latest targets, please reference the Fedora
> Atomic Wiki space.
>
> 
> https://fedoraproject.org/wiki/Atomic_WG#Fedora_Atomic_Image_Download_Links
>
> Do note that it can take some of the mirrors up to 12 hours to "check-in" at
> their own discretion.
>
> Thank you,
> Fedora Release Engineering
>
> ___
> cloud mailing list -- cl...@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
>

An example of the diff between this and the previous released version
(for x86_64) is:

ostree diff commit old:
da0bd968610aa1e29c5bb37065649407fbbfffa53e63831afdadbd34a3b05327
ostree diff commit new:
326f62b93a5cc836c97d31e73a71b6b6b6955c0f225f7651b52a693718e6aa91
Upgraded:

Re: Goodbye nvr.rsplit('-', 2), hello modularity

2018-03-15 Thread Patrick Uiterwijk

>
>
> This does not affect traditional RPM/SRPM packages, right?

Correct, this only impacts modules.

>
> Thanks,
> -Mat
> ___
> 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: Goodbye nvr.rsplit('-', 2), hello modularity

2018-03-15 Thread Mátyás Selmeci


On 03/15/2018 10:14 AM, Patrick Uiterwijk wrote:

Hi all,

If you maintain any application in Fedora Infra (or outside) that
tries to parse things out of RPM names, you might be interested in
this.

For those wondering where I've been spending most of my time the last
few weeks: I've been deep in the internals of Bodhi fixing all kinds
of issues I've found between it and Modularity (turns out enabling
composing was just the beginning).

At some point, I was informed that for modules, they are throwing all
kinds of old assumptions out of the door.
One of those is the good old Name-Version-Release in RPM land.

Modules do not have an NVR, they have an NSVC: Name, Stream, Version, Context.
Name is the name of the module ("nodejs").
Stream is a stream, like "6", "7" or "8", these are crucial for the
parallel availability that modules are trying to accomplish.
Version is a date/time stamp, used to indicate new versions in the
same name-stream.
Context is a hash of some information in the built module that makes
it so that the nodejs-6-20170314 built for Fedora 28 has a different
identifier than the one built for Fedora 29.

There are some additional fields for installed things (arch and
profile), but those aren't really important for things trying to
parse/show module names I think.

One of the interesting things they wanted to also allow: dashes in streams.
As a consequence, when you get an N-S-V.C as modules are represented
in Koji builds, doing a .rsplit('-', 2) will not give you Name,
Stream, Version.Context per se.
You could totally have a module called
nodejs-my-stream-5-20170314.abcd, with name=nodejs,
stream=my-stream-5, version=20170314, context=abcd.
There is no way for you to independently figure out what the NSVC
components are, you will need to ask Koji, and use its name, version
and release fields (with name=name, version=stream,
release=version(.context)).

Also as a consequence, modules should not be dash-separated in
anything the users see.
For user consumption, they are Name:Stream:Version:Context, so you may
need to manually convert between one representation and the other if
you need to look up in koji or other systems versus display to users.

Also, note that if you are touching older modules in Koji (e.g.
because you go through all koji builds), modules before February 19th
will be lacking the Context field.
However, I've been told that those modules will not be used, so unless
you or your app goes spelunking in koji (for fun and profit), you
should never see those.

I hope that this is useful information for anyone else finding
themselves having to parse NVRs/NSVs.

Regards,
Patrick


This does not affect traditional RPM/SRPM packages, right?

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

Goodbye nvr.rsplit('-', 2), hello modularity

2018-03-15 Thread Patrick Uiterwijk

Hi all,

If you maintain any application in Fedora Infra (or outside) that
tries to parse things out of RPM names, you might be interested in
this.

For those wondering where I've been spending most of my time the last
few weeks: I've been deep in the internals of Bodhi fixing all kinds
of issues I've found between it and Modularity (turns out enabling
composing was just the beginning).

At some point, I was informed that for modules, they are throwing all
kinds of old assumptions out of the door.
One of those is the good old Name-Version-Release in RPM land.

Modules do not have an NVR, they have an NSVC: Name, Stream, Version, Context.
Name is the name of the module ("nodejs").
Stream is a stream, like "6", "7" or "8", these are crucial for the
parallel availability that modules are trying to accomplish.
Version is a date/time stamp, used to indicate new versions in the
same name-stream.
Context is a hash of some information in the built module that makes
it so that the nodejs-6-20170314 built for Fedora 28 has a different
identifier than the one built for Fedora 29.

There are some additional fields for installed things (arch and
profile), but those aren't really important for things trying to
parse/show module names I think.

One of the interesting things they wanted to also allow: dashes in streams.
As a consequence, when you get an N-S-V.C as modules are represented
in Koji builds, doing a .rsplit('-', 2) will not give you Name,
Stream, Version.Context per se.
You could totally have a module called
nodejs-my-stream-5-20170314.abcd, with name=nodejs,
stream=my-stream-5, version=20170314, context=abcd.
There is no way for you to independently figure out what the NSVC
components are, you will need to ask Koji, and use its name, version
and release fields (with name=name, version=stream,
release=version(.context)).

Also as a consequence, modules should not be dash-separated in
anything the users see.
For user consumption, they are Name:Stream:Version:Context, so you may
need to manually convert between one representation and the other if
you need to look up in koji or other systems versus display to users.

Also, note that if you are touching older modules in Koji (e.g.
because you go through all koji builds), modules before February 19th
will be lacking the Context field.
However, I've been told that those modules will not be used, so unless
you or your app goes spelunking in koji (for fun and profit), you
should never see those.

I hope that this is useful information for anyone else finding
themselves having to parse NVRs/NSVs.

Regards,
Patrick


p.s.: This is a forward of my email sent originally to the Infra list.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: glibc-headers is missing _G_config.h

2018-03-15 Thread Michael Cronenworth


On 03/15/2018 09:55 AM, Michael Cronenworth wrote:

Is this header deprecated? It's no longer shipped in the Rawhide package.


Answering myself: Yes.

https://sourceware.org/git/?p=glibc.git;a=commit;h=48a8f8328122ab8d06b7333cb87be46feeaf7cca
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: glibc-headers is missing _G_config.h

2018-03-15 Thread Daniel P . Berrangé

On Thu, Mar 15, 2018 at 09:55:09AM -0500, Michael Cronenworth wrote:
> Is this header deprecated? It's no longer shipped in the Rawhide package.

Yes, deprecated in 2.27 and gone in 2.28

https://sourceware.org/ml/libc-announce/2018/msg0.html

[quote]
* The nonstandard header files  and <_G_config.h> are deprecated
  and will be removed in a future release.  Software that is still using
  either header should be updated to use standard  interfaces
  instead.

  libio.h was originally the header for a set of supported GNU extensions,
  but they have not been maintained as such in many years, they are now
  standing in the way of improvements to stdio, and we don't think there are
  any remaining external users.  _G_config.h was never intended for public
  use, but predates the bits convention.
[/quote]

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

glibc-headers is missing _G_config.h

2018-03-15 Thread Michael Cronenworth


Is this header deprecated? It's no longer shipped in the Rawhide package.

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

[Bug 1556425] perl-CPAN-Meta-YAML: FTBFS in F28

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



--- Comment #2 from Fedora Update System  ---
perl-CPAN-Meta-YAML-0.018-397.fc28 has been submitted as an update to Fedora
28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-8c39a1d671

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Schedule for Thursday's FPC Meeting (2018-03-15 17:00 UTC)

2018-03-15 Thread mcatanzaro

On Wed, Mar 14, 2018 at 10:55 PM, James Antill 
 wrote:

#topic #694 Packaging guidelines for application independence
.fpc 694
https://pagure.io/packaging-committee/issue/694


I had been hoping to attend the meeting to discuss this change, but 
it's been on the meeting agenda for five months now, so I long ago gave 
up on joining for the meeting, idling, and noticing that it's once 
again not actually going to be discussed.


I suggest you try to determine in advance what topics will actually be 
discussed at the meeting, what might be discussed if time permits, and 
what probably won't be reached. Then I can know whether or not I should 
join and pay attention.


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

[Bug 1556107] perl-Test-LeakTrace: FTBFS in F28

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



--- Comment #5 from Fedora Update System  ---
perl-Test-LeakTrace-0.16-6.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-ce7aa5e68e

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Fedora Atomic Host Two Week Release Announcement: 27.100

2018-03-15 Thread noreply


A new Fedora Atomic Host update is available via an OSTree update:

Version: 27.100
Commit(x86_64): 326f62b93a5cc836c97d31e73a71b6b6b6955c0f225f7651b52a693718e6aa91
Commit(aarch64): 
ba2aa19d99466c53e614651f014c8b97ae1940f87885b7c7dfed1fb62ae91567
Commit(ppc64le): 
ca0ea3a6e15b6270aefe3c7b55ffbee3c8bd27707fd6d979cc66b39fc18fa5f4


We are releasing images from multiple architectures but please note
that x86_64 architecture is the only one that undergoes automated
testing at this time.

Existing systems can be upgraded in place via e.g. `atomic host upgrade`.

Corresponding image media for new installations can be downloaded from:

https://getfedora.org/en/atomic/download/

Alternatively, image artifacts can be found at the following links:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/Atomic/aarch64/iso/Fedora-Atomic-ostree-aarch64-27-20180314.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/Atomic/ppc64le/iso/Fedora-Atomic-ostree-ppc64le-27-20180314.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/Atomic/x86_64/iso/Fedora-Atomic-ostree-x86_64-27-20180314.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/CloudImages/aarch64/images/Fedora-Atomic-27-20180314.0.aarch64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/CloudImages/aarch64/images/Fedora-Atomic-27-20180314.0.aarch64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/CloudImages/ppc64le/images/Fedora-Atomic-27-20180314.0.ppc64le.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/CloudImages/ppc64le/images/Fedora-Atomic-27-20180314.0.ppc64le.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/CloudImages/x86_64/images/Fedora-Atomic-27-20180314.0.x86_64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/CloudImages/x86_64/images/Fedora-Atomic-27-20180314.0.x86_64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/CloudImages/x86_64/images/Fedora-Atomic-Vagrant-27-20180314.0.x86_64.vagrant-libvirt.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/CloudImages/x86_64/images/Fedora-Atomic-Vagrant-27-20180314.0.x86_64.vagrant-virtualbox.box

Respective signed CHECKSUM files can be found here:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/Atomic/aarch64/iso/Fedora-Atomic-27-20180314.0-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/Atomic/ppc64le/iso/Fedora-Atomic-27-20180314.0-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/Atomic/x86_64/iso/Fedora-Atomic-27-20180314.0-x86_64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/CloudImages/aarch64/images/Fedora-CloudImages-27-20180314.0-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/CloudImages/ppc64le/images/Fedora-CloudImages-27-20180314.0-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180314.0/CloudImages/x86_64/images/Fedora-CloudImages-27-20180314.0-x86_64-CHECKSUM

For direct download, the "latest" targets are always available here:
https://getfedora.org/atomic_iso_latest
https://getfedora.org/atomic_qcow2_latest
https://getfedora.org/atomic_raw_latest
https://getfedora.org/atomic_vagrant_libvirt_latest
https://getfedora.org/atomic_vagrant_virtualbox_latest

Filename fetching URLs are available here:
https://getfedora.org/atomic_iso_latest_filename
https://getfedora.org/atomic_qcow2_latest_filename
https://getfedora.org/atomic_raw_latest_filename
https://getfedora.org/atomic_vagrant_libvirt_latest_filename
https://getfedora.org/atomic_vagrant_virtualbox_latest_filename

For more information about the latest targets, please reference the Fedora
Atomic Wiki space.

https://fedoraproject.org/wiki/Atomic_WG#Fedora_Atomic_Image_Download_Links

Do note that it can take some of the mirrors up to 12 hours to "check-in" at
their own discretion.

Thank you,
Fedora Release Engineering
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 FTBFS bugs?

2018-03-15 Thread Michael Schwendt

On Thu, 15 Mar 2018 11:01:00 +0100, Daiki Ueno wrote:

> Hello,
> 
> Yesterday I received a couple of new FTBFS bugs, apparently triggered by
> the F28 mass rebuild:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1556047
> https://bugzilla.redhat.com/show_bug.cgi?id=1556162
> 
> As the mentioned koji builds are back in February, I am wondering if
> those are something I should still worry about.
> 
> I suspect the former was failing due to a Vala regression recently
> fixed[1], and the latter could be a false-positive as it points to the
> build against f27-candidate.

Those tickets are misleading and would have deserved a better
explanation. At some point, builds have failed for unknown reasons (and
the logs have expired already, so one cannot examine them anymore), and
therefore builds may still be missing within koji if no later build has
completed successfully.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1556105] perl-MongoDB: FTBFS in F28

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-MongoDB-1.8.1-2.fc28 has been pushed to the Fedora 28 testing repository.
If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-9812edde45

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1556646] perl-Time-HiRes-1.9755 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Time-HiRes-1.9756-1.fc28 has been pushed to the Fedora 28 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-cd75b181e3

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1555101] perl-MCE-1.835 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-MCE-1.835-1.fc28, perl-MCE-Shared-1.836-1.fc28 has been pushed to the
Fedora 28 testing repository. If problems still persist, please make note of it
in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-3284ae4218

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: F28 FTBFS bugs?

2018-03-15 Thread Dennis Gilmore

El jue, 15-03-2018 a las 11:01 +0100, Daiki Ueno escribió:
> Hello,
> 
> Yesterday I received a couple of new FTBFS bugs, apparently triggered
> by
> the F28 mass rebuild:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1556047
> https://bugzilla.redhat.com/show_bug.cgi?id=1556162
> 
> As the mentioned koji builds are back in February, I am wondering if
> those are something I should still worry about.
> 
> I suspect the former was failing due to a Vala regression recently
> fixed[1], and the latter could be a false-positive as it points to
> the
> build against f27-candidate.
> 
> Footnotes: 
> [1]  https://bugzilla.gnome.org/show_bug.cgi?id=793299
> 
have you rebuilt your packages?  if not yes you need to rebuild them

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: glibc-headers is missing rpc/rpc.h in rawhide

2018-03-15 Thread Jan Synacek

On Thu, Mar 15, 2018 at 11:43 AM, Dan Horák  wrote:
> On Thu, 15 Mar 2018 11:30:32 +0100
> Jan Synacek  wrote:
>
>> Did I miss something? The xinetd package cannot be built because of
>> that.
>
> https://fedoraproject.org/wiki/Changes/SunRPCRemoval

So I missed something. Thank you for pointing me to this!

Cheers,
-- 
Jan Synacek
Software Engineer, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1556107] perl-Test-LeakTrace: FTBFS in F28

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



--- Comment #4 from Petr Pisar  ---
I believe so.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1556107] perl-Test-LeakTrace: FTBFS in F28

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



--- Comment #3 from Paul Howarth  ---
OK, so I expect koji won't allow me to build perl-Test-LeakTrace-0.16-5.fc28 in
the f28 branch as there's already a build perl-Test-LeakTrace-0.16-5.fc28 in
f29, I guess I need to bump and rebuild for both?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1556107] perl-Test-LeakTrace: FTBFS in F28

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

Petr Pisar  changed:

   What|Removed |Added

 CC||ppi...@redhat.com



--- Comment #2 from Petr Pisar  ---
$ koji list-tag-history --build perl-Test-LeakTrace-0.16-5.fc28
Tue Feb 20 13:12:26 2018: perl-Test-LeakTrace-0.16-5.fc28 tagged into
f29-pending by pghmcfc
Tue Feb 20 13:12:39 2018: perl-Test-LeakTrace-0.16-5.fc28 tagged into f29 by
autopen [still active]
Tue Feb 20 13:12:39 2018: perl-Test-LeakTrace-0.16-5.fc28 untagged from
f29-pending by autopen

perl-Test-LeakTrace-0.16-5.fc28 was built into f29. It has fc28 dist tag
because at that time fedora-release package that brings the %dist macro had
version 28-0.2.

It seems you built perl-Test-LeakTrace from master when the koji had already
updated rawhide to f29 but before fedora-release package was upgraded to define
dist as fc29.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: glibc-headers is missing rpc/rpc.h in rawhide

2018-03-15 Thread Dan Horák

On Thu, 15 Mar 2018 11:30:32 +0100
Jan Synacek  wrote:

> Did I miss something? The xinetd package cannot be built because of
> that.

https://fedoraproject.org/wiki/Changes/SunRPCRemoval


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

Re: glibc-headers is missing rpc/rpc.h in rawhide

2018-03-15 Thread Daniel P . Berrangé

On Thu, Mar 15, 2018 at 11:30:32AM +0100, Jan Synacek wrote:
> Did I miss something? The xinetd package cannot be built because of that.

GLibc dropped the RPC functionality. You need to change the code to
use tirpc instead. It is API compatible, but your build system will
need to know to link the different library.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

glibc-headers is missing rpc/rpc.h in rawhide

2018-03-15 Thread Jan Synacek

Did I miss something? The xinetd package cannot be built because of that.

Cheers,
-- 
Jan Synacek
Software Engineer, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F28 FTBFS bugs?

2018-03-15 Thread Daiki Ueno

Hello,

Yesterday I received a couple of new FTBFS bugs, apparently triggered by
the F28 mass rebuild:

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

As the mentioned koji builds are back in February, I am wondering if
those are something I should still worry about.

I suspect the former was failing due to a Vala regression recently
fixed[1], and the latter could be a false-positive as it points to the
build against f27-candidate.

Footnotes: 
[1]  https://bugzilla.gnome.org/show_bug.cgi?id=793299

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

[Bug 1556647] perl-Test2-Suite-0.000111 is available

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



--- Comment #2 from Petr Pisar  ---
Waiting on perl-Test2-Suite-0.000108-1.fc28 to get stable.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1556647] perl-Test2-Suite-0.000111 is available

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Test2-Suite-0.000111-1
   ||.fc29



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for Fedora ≥ 28.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1556646] perl-Time-HiRes-1.9755 is available

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



--- Comment #2 from Fedora Update System  ---
perl-Time-HiRes-1.9756-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-cd75b181e3

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1556646] perl-Time-HiRes-1.9755 is available

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

Petr Pisar  changed:

   What|Removed |Added

   Fixed In Version||perl-Time-HiRes-1.9756-1.fc
   ||29



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for Fedora ≥ 28.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1556105] perl-MongoDB: FTBFS in F28

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



--- Comment #2 from Fedora Update System  ---
perl-MongoDB-1.8.1-2.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-9812edde45

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1556105] perl-MongoDB: FTBFS in F28

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Comment #1 from Petr Pisar  ---
The koji logs does not exist anymore. According to Koschei there was a problem
in Boost packages.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1556425] perl-CPAN-Meta-YAML: FTBFS in F28

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



--- Comment #1 from Paul Howarth  ---
perl-CPAN-Meta-YAML-0.018-396.fc28 was built on 20th February, well before the
bodhi activation point, and is included in Rawhide but somehow not f28. Any
ideas why that is?

https://koji.fedoraproject.org/koji/buildinfo?buildID=1032996

$ koji latest-pkg f28 perl-CPAN-Meta-YAML
Build Tag   Built by
   

perl-CPAN-Meta-YAML-0.018-395.fc27f28   releng

$ koji latest-pkg f29 perl-CPAN-Meta-YAML
Build Tag   Built by
   

perl-CPAN-Meta-YAML-0.018-396.fc28f29   pghmcfc

I can't even submit an update with this build because the build isn't tagged as
an updates candidate.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1556107] perl-Test-LeakTrace: FTBFS in F28

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



--- Comment #1 from Paul Howarth  ---
perl-Test-LeakTrace-0.16-5.fc28 was built on 20th February, well before the
bodhi activation point, and is included in Rawhide but somehow not in f28. Any
ideas on why that is?

https://koji.fedoraproject.org/koji/buildinfo?buildID=1047048

$ koji latest-pkg f28 perl-Test-LeakTrace
Build Tag   Built by
   

perl-Test-LeakTrace-0.16-1.fc27   f28   pghmcfc

$ koji latest-pkg f29 perl-Test-LeakTrace
Build Tag   Built by
   

perl-Test-LeakTrace-0.16-5.fc28   f29   pghmcfc

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: F29 System Wide Change: Make dbus-broker the default DBus implementation

2018-03-15 Thread Zbigniew Jędrzejewski-Szmek

FTR, patches to convert at-spi2-core to use dbus-broker:
https://github.com/GNOME/at-spi2-core/pull/2
https://src.fedoraproject.org/rpms/at-spi2-core/pull-request/1

Zbyszek


On Tue, Mar 13, 2018 at 05:32:20PM +0100, Jan Kurik wrote:
> = Proposed System Wide Change: Make dbus-broker the default DBus
> implementation =
> https://fedoraproject.org/wiki/Changes/DbusBrokerAsTheDefaultDbusImplementation
> 
> 
> Owner(s):
>   * David Herrmann 
>   * Tom Gundersen 
> 
> 
> Enable dbus-broker.service to use dbus-broker as system and session
> message bus backend.
> 
> 
> == Detailed description ==
> The dbus-broker project is an implementation of a message bus as
> defined by the D-Bus specification. Its aim is to provide high
> performance and reliability, while keeping compatibility to the D-Bus
> reference implementation. It is exclusively written for linux systems,
> and makes use of many modern features provided by recent linux kernel
> releases.
> The main focus points of dbus-broker are reliability, scalability and
> security. The dbus-broker project tries to improve on these points
> over dbus-daemon, and thus provide a better alternative. And in-depth
> analysis can be found in the initial announcement of dbus-broker. An
> excerpt:
> 
> * Accounting: dbus-broker maintains per-user accounting, including
> inter-user quotas. This guarantees that no single user can cause
> irregularly high memory consumption in the daemon. Unlike dbus-broker,
> dbus-daemon accounts memory in a multi-tier system, based on plain
> resource counters on users, connections, and other resources. The
> multi-tier system suffers from resource-chaining-exhaustion, where
> clients effectively circumvent the accounting by creating multiple
> connections/objects, which themselves grant them each a new set of
> quotas. The single-tier accounting scheme of dbus-broker avoids this,
> while at the same time adding inter-user quotas to prevent misuse even
> across clients.
> 
> * Reliability: While D-Bus is used on reliable transports, dbus-daemon
> might still silently drop messages and given circumstances. This is
> the only possible solution dbus-daemon has, given several of its
> runtime guarantees. The dbus-broker project changed the architecture
> of the bus daemon to a degree, that it can provide many guarantees,
> including that no message will be silently, or unexpectedly, dropped.
> 
> * Scalability: The message bus broker is a crucial infrastructure on
> modern linux system, which is a hot-path for almost all IPC going on.
> Hence, the broker should perform fast and be scalable to its users.
> dbus-daemon has several **global** data-structures that affect the
> overall scalability of independent message transactions. dbus-broker
> does not employ any global data-structures (unless required by the
> spec), as such any message transaction is only affected by the data
> provided by the involved peers. Moreover, even for spec-defined global
> behavior, dbus-broker avoids global data-structures, unless clients
> actually make use of these obscure features. In several other cases,
> dbus-daemon scales O(n) time looking up message targets and related
> data. dbus-broker runs all these in O(log(n)) time.
> 
> * Linux-specific: The dbus-broker project was explicitly designed for
> linux system, making use of many linux-specific APIs and behavior.
> This allows mitigation of several possible DoS attacks.
> 
> 
> == Scope ==
> * Proposal owners:
> ** Fix regressions.
> ** Enable dbus-broker.service in system and user-global context of
> systemd (via systemd presets).
> ** Pull in dbus-broker package from dbus package.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 28-20180314.n.2 compose check report

No missing expected images.

Failed openQA tests: 17/137 (x86_64), 5/23 (i386), 1/2 (arm)

ID: 203825  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/203825
ID: 203831  Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/203831
ID: 203857  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/203857
ID: 203860  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/203860
ID: 203862  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/203862
ID: 203863  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/203863
ID: 203864  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/203864
ID: 203865  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/203865
ID: 203877  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/203877
ID: 203881  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default_upload
URL: https://openqa.fedoraproject.org/tests/203881
ID: 203882  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default@uefi
URL: https://openqa.fedoraproject.org/tests/203882
ID: 203883  Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/203883
ID: 203896  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/203896
ID: 203901  Test: x86_64 universal install_delete_partial@uefi
URL: https://openqa.fedoraproject.org/tests/203901
ID: 203922  Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/203922
ID: 203927  Test: x86_64 universal install_delete_partial
URL: https://openqa.fedoraproject.org/tests/203927
ID: 203930  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/203930
ID: 203943  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/203943
ID: 203954  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/203954
ID: 203969  Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/203969
ID: 203977  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/203977
ID: 203978  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/203978
ID: 203981  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/203981

Soft failed openQA tests: 66/137 (x86_64), 16/23 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 203817  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/203817
ID: 203818  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/203818
ID: 203820  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/203820
ID: 203821  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/203821
ID: 203823  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/203823
ID: 203824  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/203824
ID: 203837  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/203837
ID: 203840  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/203840
ID: 203841  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/203841
ID: 203842  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/203842
ID: 203843  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/203843
ID: 203844  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/203844
ID: 203879  Test: x86_64 AtomicHost-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/203879
ID: 203880  Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/203880
ID: 203890  Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/203890
ID: 203891  Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/203891
ID: 203892  Test: x86_64 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/203892
ID: 203893  Test: x86_64 universal

Fedora Rawhide-20180314.n.2 compose check report

No missing expected images.

Failed openQA tests: 83/137 (x86_64), 24/24 (i386), 1/2 (arm)

ID: 203982  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/203982
ID: 203983  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/203983
ID: 203985  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/203985
ID: 203986  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/203986
ID: 203988  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/203988
ID: 203989  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/203989
ID: 204002  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/204002
ID: 204005  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/204005
ID: 204006  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/204006
ID: 204007  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/204007
ID: 204008  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/204008
ID: 204009  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/204009
ID: 204011  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/204011
ID: 204012  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/204012
ID: 204022  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/204022
ID: 204023  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/204023
ID: 204024  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/204024
ID: 204025  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/204025
ID: 204026  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/204026
ID: 204027  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/204027
ID: 204028  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/204028
ID: 204029  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/204029
ID: 204030  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/204030
ID: 204031  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/204031
ID: 204034  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/204034
ID: 204042  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/204042
ID: 204043  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/204043
ID: 204045  Test: x86_64 AtomicHost-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/204045
ID: 204046  Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/204046
ID: 204047  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default_upload
URL: https://openqa.fedoraproject.org/tests/204047
ID: 204048  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default@uefi
URL: https://openqa.fedoraproject.org/tests/204048
ID: 204049  Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/204049
ID: 204056  Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/204056
ID: 204057  Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/204057
ID: 204058  Test: x86_64 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/204058
ID: 204059  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/204059
ID: 204060  Test: x86_64 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/204060
ID: 204061  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/204061
ID: 204062  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/204062
ID: 204063  Test: x86_64 universal install_blivet_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/204063
ID: 204064  Test: x86_64 universal install_blivet_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/204064
ID: 204065  Test: x86_64 universal

Fedora-Atomic 27-20180315.0 compose check report

No missing expected images.

Passed openQA tests: 2/2 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1551668] perl-Verilog-Perl-3.448-1.fc29 FTBFS: t/ 35_sigparser.t crashes

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Blocks||1555378
 CC||rel...@fedoraproject.org



--- Comment #1 from Jitka Plesnikova  ---
*** Bug 1556108 has been marked as a duplicate of this bug. ***


Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1555378
[Bug 1555378] (F28FTBFS) Fedora 28 Mass Rebuild FTBFS Tracker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1556108] perl-Verilog-Perl: FTBFS in F28