Re: GCC 8.0.x caused failure on Blender dependent libraries
On 2018-03-15 11:29 PM, Adam Williamson wrote: > On Thu, 2018-03-15 at 23:18 -0700, Luya Tshimbalanga wrote: >> It looks like some Blender dependencies such as openvdb and embree >> failed to build with gcc 8.x while they successfully compiled with GCC >> 7.x. Not sure what caused the issue but I can provide the result: >> >> Failure to build openvdb with gcc 8.0.1 >> https://koji.fedoraproject.org/koji/taskinfo?taskID=25736367 >> >> Failure to build embree with gcc 8.0.1 >> https://koji.fedoraproject.org/koji/buildinfo?buildID=1053061 >> >> Successful build of openvdb with gcc 7.1.1 >> https://koji.fedoraproject.org/koji/taskinfo?taskID=25736526 >> >> Successful build of embree with embree 3.0.0 >> https://koji.fedoraproject.org/koji/taskinfo?taskID=25736804 >> >> >> Upstream embree contacted me about the failure and I provided my finding >> to them about the root cause. Can someone take a look at the issue >> related to GCC 8.0.1 which is beyond my skills? Thanks > Well, these are usually really potential bugs in the upstream projects > that GCC is now catching. They usually require changes in the projects, > not in GCC. Reporting the issue to the upstream project, with the build > log attached or linked to, should be the first step. > > Looks to me like embree is an integer type conversion error (GCC 8 is > rather stricter about conversions between potentially incompatible > integer types), openvdb the error is this: > > /builddir/build/BUILD/openvdb-5.0.0/openvdb/python/pyFloatGrid.cc: In > function 'void exportFloatGrid()': > /builddir/build/BUILD/openvdb-5.0.0/openvdb/python/pyFloatGrid.cc:51:9: > error: 'py::numeric' has not been declared > > which we'd have to look into in a bit more detail to figure out. Thanks Adam. I filed a ticket to upstream openvdb: https://github.com/dreamworksanimation/openvdb/issues/225 and await possible fix from upstream embree. -- Luya Tshimbalanga Graphic & Web Designer E: l...@fedoraproject.org W: http://www.coolest-storm.net signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCC 8.0.x caused failure on Blender dependent libraries
On Thu, 2018-03-15 at 23:18 -0700, Luya Tshimbalanga wrote: > It looks like some Blender dependencies such as openvdb and embree > failed to build with gcc 8.x while they successfully compiled with GCC > 7.x. Not sure what caused the issue but I can provide the result: > > Failure to build openvdb with gcc 8.0.1 > https://koji.fedoraproject.org/koji/taskinfo?taskID=25736367 > > Failure to build embree with gcc 8.0.1 > https://koji.fedoraproject.org/koji/buildinfo?buildID=1053061 > > Successful build of openvdb with gcc 7.1.1 > https://koji.fedoraproject.org/koji/taskinfo?taskID=25736526 > > Successful build of embree with embree 3.0.0 > https://koji.fedoraproject.org/koji/taskinfo?taskID=25736804 > > > Upstream embree contacted me about the failure and I provided my finding > to them about the root cause. Can someone take a look at the issue > related to GCC 8.0.1 which is beyond my skills? Thanks Well, these are usually really potential bugs in the upstream projects that GCC is now catching. They usually require changes in the projects, not in GCC. Reporting the issue to the upstream project, with the build log attached or linked to, should be the first step. Looks to me like embree is an integer type conversion error (GCC 8 is rather stricter about conversions between potentially incompatible integer types), openvdb the error is this: /builddir/build/BUILD/openvdb-5.0.0/openvdb/python/pyFloatGrid.cc: In function 'void exportFloatGrid()': /builddir/build/BUILD/openvdb-5.0.0/openvdb/python/pyFloatGrid.cc:51:9: error: 'py::numeric' has not been declared which we'd have to look into in a bit more detail to figure out. -- 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
GCC 8.0.x caused failure on Blender dependent libraries
It looks like some Blender dependencies such as openvdb and embree failed to build with gcc 8.x while they successfully compiled with GCC 7.x. Not sure what caused the issue but I can provide the result: Failure to build openvdb with gcc 8.0.1 https://koji.fedoraproject.org/koji/taskinfo?taskID=25736367 Failure to build embree with gcc 8.0.1 https://koji.fedoraproject.org/koji/buildinfo?buildID=1053061 Successful build of openvdb with gcc 7.1.1 https://koji.fedoraproject.org/koji/taskinfo?taskID=25736526 Successful build of embree with embree 3.0.0 https://koji.fedoraproject.org/koji/taskinfo?taskID=25736804 Upstream embree contacted me about the failure and I provided my finding to them about the root cause. Can someone take a look at the issue related to GCC 8.0.1 which is beyond my skills? Thanks -- Luya Tshimbalanga Graphic & Web Designer E: l...@fedoraproject.org W: http://www.coolest-storm.net signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
On 2018-02-18 09:09 AM, Igor Gnatenko wrote: > Over this weekend I've performed scratch-mass-rebuild without having > gcc and > gcc-c++ in buildroot of all Fedora packages, many of which failed due > to random > reasons and I grepped all logs for some common errors found by analyzing > hundreds of build logs. > > Guidelines: > https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#BuildRequire > s_and_Requies > > The grep output is located here: > https://ignatenkobrain.fedorapeople.org/gcc-removal.txt > > Some packages might be missed due to short koji outage, broken > dependencies and > so on, but majority of real failures is below. > > If you fixed package(s), found false positive, found missing packages > in list > or anything else -- please let me know. Fixed for ETL, alembic, gimp-dbp, radeontop False positive for both synfig, synfigtudio which depends of ETL and python-lcms2 openvdb fails to build with gcc 8.x for some odd reasons despite the BuildRequires. https://koji.fedoraproject.org/koji/taskinfo?taskID=25736367 However, openvdb successfully compiled with gcc 7.x as seen on scratch build: https://koji.fedoraproject.org/koji/watchlogs?taskID=25736527 > -- Luya Tshimbalanga Graphic & Web Designer E: l...@fedoraproject.org W: http://www.coolest-storm.net signature.asc Description: OpenPGP digital signature ___ 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
Randy Barlow wrote: > 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? +1, I think allowing this ambiguity is a very bad idea. Kevin Kofler ___ 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}
Germano Massullo wrote: > 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? The patch should be fine, but you also need to set LIBPATH in your specfile: add: LIBPATH=\"%{_libdir}\" \ before line 43. Kevin Kofler ___ 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 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)
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 `.text._ZNK20wxObjectEventFunctor10IsMatchingERK14wxEventFunctor
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
Re: new section for 'Join the package collection maintainers'
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
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}
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 instal
Fedora Rawhide-20180315.n.1 compose check report
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 install_blivet_lvmthin@uef
Re: GCC 8.0.1 updates in F28
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
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
> 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
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
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
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
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
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
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
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'
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
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
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
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 - 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 - 1.62.0.1-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Wed Mar 14 2018 Tom Callaway - 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 - 0.22.0-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Wed Mar 14 2018 Tom Callaway - 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 - 1.10.1-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Wed Mar 14 2018 Tom Callaway - 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 - 1.12.1-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Wed Mar 14 2018 Tom Callaway - 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 - 0.99.0-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Wed Mar 14 2018 Tom Callaway - 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 - 0.14.3-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Wed Mar 14 2018 Tom Callaway - 0.16.0-1 - update to 0.16.0 Package: R-crayon-1.3.4-1.fc29 Old package: R-crayon-1.3.1-5.fc27 Summary: Colored Terminal Output RPMs: R-crayon Size: 708.59 KiB Size change: 102.98 KiB Changelog: * Wed F
f28 and rawhide ignoring static ip settings
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
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
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
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
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
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'
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
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'
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
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
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
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
Re: Fedora Atomic Host Two Week Release Announcement: 27.100
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: atomic 1.21.1-1.fc27 -> 1.22.
Re: Goodbye nvr.rsplit('-', 2), hello modularity
> > > 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
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
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
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
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
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
Re: Schedule for Thursday's FPC Meeting (2018-03-15 17:00 UTC)
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
Fedora Atomic Host Two Week Release Announcement: 27.100
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?
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
Re: F28 FTBFS bugs?
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
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
Re: glibc-headers is missing rpc/rpc.h in rawhide
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
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
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?
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
Re: F29 System Wide Change: Make dbus-broker the default DBus implementation
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 install_blivet_softw
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 install_blivet_lvmthin@uef
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