Re: /usr/bin/ld is broken in rawhide
Orion Poplawski wrote: > With current koji buildroot I end up with: > > + ls -l /usr/bin/ld /usr/bin/ld.bfd /usr/bin/ld.gold /usr/bin/ldd > --w---. 1 root root 3814880 Feb 27 04:00 /usr/bin/ld > -rwxr-xr-x. 1 root root 1841608 Feb 26 15:02 /usr/bin/ld.bfd > -rwxr-xr-x. 1 root root 3814880 Feb 26 15:02 /usr/bin/ld.gold > -rwxr-xr-x. 1 root root5441 Feb 19 07:39 /usr/bin/ldd > > and thus: > > BUILDSTDERR: collect2: fatal error: cannot find 'ld' https://bugzilla.redhat.com/show_bug.cgi?id=1683408 It might be worth untagging the binutils update until a fixed build is ready, which it looks like Mamoru has done: https://pagure.io/releng/issue/8172 -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
/usr/bin/ld is broken in rawhide
With current koji buildroot I end up with: + ls -l /usr/bin/ld /usr/bin/ld.bfd /usr/bin/ld.gold /usr/bin/ldd --w---. 1 root root 3814880 Feb 27 04:00 /usr/bin/ld -rwxr-xr-x. 1 root root 1841608 Feb 26 15:02 /usr/bin/ld.bfd -rwxr-xr-x. 1 root root 3814880 Feb 26 15:02 /usr/bin/ld.gold -rwxr-xr-x. 1 root root5441 Feb 19 07:39 /usr/bin/ldd and thus: BUILDSTDERR: collect2: fatal error: cannot find 'ld' -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Self Introduction: ChillyBot
On Wed, Feb 27, 2019 at 2:42 AM absolutezero wrote: > > Hello everyone! > > My name is Chilly. I am looking to bring back Snort IDS into the Fedora > Project and maintain it for at least several years. I am relatively new to > packaging but have been using Fedora for many years now as my daily driver. > Doing my best to follow to guide according to > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers and am > excited to contribute. I work as a Linux Sysadmin and infosec/privacy > consultant. Grad to hear that! > > GPG Fingerprint: 0977E14243A7B76741A6E049076FD2093766DC98 > > Any question or comments feel free to contact me directly :) > > Best wishes, > > Chilly > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
On Tue, 2019-02-26 at 22:44 +0100, Florian Weimer wrote: > * Sérgio Basto: > > > stdio.h defines EOF as -1 , so if we want work with files > > and use EOF character, we need use signed chars, though . > > No, this is not how it works. > > Most C interfaces (hopefully all of them, but I wouldn't be sure) > that > use in-band signaling for EOF return ints. EOF is returned as int, > and > the characters are returned after casting them to unsigned char, even > if > char is signed on the architecture. > > So getchar returns 255 when reading the character 'ÿ' in ISO-8859-1, > and > -1 for EOF. > > It is a common mistake to use a char variable to store the result of > getchar and similar functions because this way, you cannot tell 'ÿ' > and > EOF apart. This leads either to premature detection of EOF, or > infinite > loops reading 'ÿ' over and over again, depending on the architecture. OK , I made another patch [1] not touching ./Source/Common/gdcmString.h and instead use definition of EOL, I use the default char of template ... [1] https://src.fedoraproject.org/fork/sergiomb/rpms/gdcm/blob/master/f/gdcm-2.8.8-dont_use_EOF.patch > Thanks, > Florian -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Reminder: Beta freeze and code complete deadline in one week
On Tue, 2019-02-26 at 16:09 -0800, Kevin Fenzi wrote: > On 2/26/19 11:11 AM, Sérgio Basto wrote: > > On Tue, 2019-02-26 at 10:38 -0500, Ben Cotton wrote: > > > According to the Fedora 30 schedule[1], the 100% code complete > > > deadline[2] for Changes is Tuesday, 5 March. The beta freeze[3] > > > takes effect on this date as well. All Changes should be in > > > "ON_QA" > > > state by then. > > > > I still haven't any compose for F30 completed, we should have time > > to > > We have. The compose on the 24th finished and synced out. > > > build some packages against f30 buildroots , this situation also > > happened in F29 . > > The buildroot is in koji and is always updated, or do you mean > something > else? yes, without composes, buildroots on copr, mock and RPMFusion aren't updated . > > Question why composer are broken , when is most needed ? > > Because we don't have gating and everyone drops tons of changes in. > > > What I mean is Beta freeze should be postponed after two weeks of > > composer start to work . Given 2 week to packages maintainers fix > > the > > FTBFS packages etc . > > You can work on FTBFS anytime... thats not constrained by the > compose. Without buildroots updated is much more difficult test the builds. Sorry for my bad mood , I'm tired, but since I'm on reflection , I think after mass rebuild with new gcc we should wait a little more until mass branching, new gcc always have a lot of FTBFS No branched composes also means no testing installations, dnf broken deps and debug a lot of things . Many thanks, -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Reminder: Beta freeze and code complete deadline in one week
On 2/26/19 11:11 AM, Sérgio Basto wrote: > On Tue, 2019-02-26 at 10:38 -0500, Ben Cotton wrote: >> According to the Fedora 30 schedule[1], the 100% code complete >> deadline[2] for Changes is Tuesday, 5 March. The beta freeze[3] >> takes effect on this date as well. All Changes should be in "ON_QA" >> state by then. > > I still haven't any compose for F30 completed, we should have time to We have. The compose on the 24th finished and synced out. > build some packages against f30 buildroots , this situation also > happened in F29 . The buildroot is in koji and is always updated, or do you mean something else? > Question why composer are broken , when is most needed ? Because we don't have gating and everyone drops tons of changes in. > What I mean is Beta freeze should be postponed after two weeks of > composer start to work . Given 2 week to packages maintainers fix the > FTBFS packages etc . You can work on FTBFS anytime... thats not constrained by the compose. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python-cherrypy vs python3-cherrypy - can we keep just one?
On 26. 02. 19 18:37, Ken Dreyer wrote: On Fri, Feb 15, 2019 at 1:10 AM Matthias Runge wrote: With that, I'm looking for co-maintainers for python-cherrypy. The package is severely outdated and it seems there hasn't been any significant contribution to this over the past 4 years. I may have been too optimistic with my available time for this. The newest versions of Ceph depend on CherryPy, so I'm interested in keeping it up-to-date as long as that continues. There are several new dependencies to bring in. I've packaged them in https://copr.fedorainfracloud.org/coprs/ktdreyer/python-cherrypy/ Would you please send this as a PR to the python-cherrypy package? We also need python-path to be updated, https://src.fedoraproject.org/rpms/python-path/pull-request/2 . Xavier would you please review and merge that change? I've posted some comments there. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages that will be retired
On Mon, Feb 25, 2019 at 9:51 PM Miro Hrončok wrote: > > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > Note: If you received this mail directly you (co)maintain one of the affected > packages or a package that depends on one. Please adopt the affected package > or > retire your depending package to avoid broken dependencies, otherwise your > package will be retired when the affected package gets retired. > > Full dependencies breakdown at > https://churchyard.fedorapeople.org/orphans-2019-02-25.txt > Grep it for your FAS name. > > Package (co)maintainers Status > Change > > OSGi-bundle-ant-task orphan 3 weeks ago > RunSnakeRun orphan 6 weeks ago > SimplyHTMLmizdebsk, orphan 2 weeks ago > aether-connector-okhttp galileo, mizdebsk, orphan2 weeks ago > ant akurtakov, jcapik, kdaniel, 2 weeks ago >mizdebsk, msrb, orphan > ant-antunit mizdebsk, orion, orphan 2 weeks ago I'll take ant and ant-antunit > apache-commons-daemon mizdebsk, orphan, spike 2 weeks ago and apache-commons-daemon if no one objects to it ( https://pagure.io/releng/issue/8171 ). Regards, François > apache-commons-discovery lkundrak, mizdebsk, orphan, 2 weeks ago >spike > apache-commons-el fnasser, mizdebsk, orphan, 2 weeks ago >spike > apache-commons-fileupload jerboaa, mizdebsk, mmraka, 2 weeks ago >orphan, spike > apache-commons-io mizdebsk, orphan, spike 2 weeks ago > apache-commons-jexl mizdebsk, orphan 2 weeks ago > apache-commons-jxpath fnasser, mizdebsk, orphan, 2 weeks ago >spike > apache-commons-lang mizdebsk, orphan, spike 2 weeks ago > apache-commons-lang3 mizdebsk, orphan 2 weeks ago > apache-commons-loggingkdaniel, mizdebsk, orphan, 2 weeks ago >spike > apache-commons-netmizdebsk, orphan, spike 2 weeks ago > apache-ivymizdebsk, orphan 2 weeks ago > apache-james-project lef, mizdebsk, orphan2 weeks ago > apache-logging-parent mizdebsk, orphan 2 weeks ago > apache-mime4j lef, mizdebsk, orphan2 weeks ago > apache-parent mizdebsk, orphan 2 weeks ago > apache-ratmizdebsk, orphan 2 weeks ago > apache-resource-bundles mizdebsk, orphan 2 weeks ago > apiguardian mizdebsk, orphan 2 weeks ago > aqute-bnd jcapik, mizdebsk, orphan 2 weeks ago > args4jjcapik, mizdebsk, orphan 2 weeks ago > atinject kdaniel, mizdebsk, orphan2 weeks ago > avalon-framework jerboaa, mizdebsk, orphan2 weeks ago > avalon-logkit jerboaa, mizdebsk, orphan2 weeks ago > base64coder jcapik, mizdebsk, orphan 2 weeks ago > batik jvanek, mizdebsk, orphan 2 weeks ago > bcel mizdebsk, orphan 2 weeks ago > bea-stax jcapik, mizdebsk, orphan 2 weeks ago > beust-jcommander jcapik, jvanek, mizdebsk,2 weeks ago >orphan > blobbyorphan 3 weeks ago > bsf choeger, mizdebsk, orphan2 weeks ago > bsh mizdebsk, orphan 2 weeks ago > c3p0 dchen, lef, orphan 2 weeks ago > cal10nmizdebsk, orphan 2 weeks ago > catkinorphan, rmattes, robotics-sig, 5 weeks ago >thofmann > checkstyledbhole, greghellings, lef, 2 weeks ago >mizdebsk, nsantos, orphan, >rmyers > clang5.0
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
* Sérgio Basto: > stdio.h defines EOF as -1 , so if we want work with files > and use EOF character, we need use signed chars, though . No, this is not how it works. Most C interfaces (hopefully all of them, but I wouldn't be sure) that use in-band signaling for EOF return ints. EOF is returned as int, and the characters are returned after casting them to unsigned char, even if char is signed on the architecture. So getchar returns 255 when reading the character 'ÿ' in ISO-8859-1, and -1 for EOF. It is a common mistake to use a char variable to store the result of getchar and similar functions because this way, you cannot tell 'ÿ' and EOF apart. This leads either to premature detection of EOF, or infinite loops reading 'ÿ' over and over again, depending on the architecture. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
* Tom Hughes: > On 26/02/2019 19:42, Sérgio Basto wrote: > >> Is stdio.h that defines EOF as -1 , so if we what work with files and >> use EOF character, we need use signed chars, though . > > No, you need to use int. The EOF value is deliberately outside the > range of character values so that EOF is not a valid character! EOF is a valid character, 'ÿ', in the Latin-1 encoding on x86 and various other architectures. On those architectures, EOF and 'ÿ' have the same type and value as far as the C language is concerned. (In C++, character literals have type char, so the types are different.) Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
On Tue, 2019-02-26 at 20:52 +, Jonathan Wakely wrote: > On 26/02/19 19:42 +, Sérgio Basto wrote: > > On Tue, 2019-02-26 at 14:46 +, Jonathan Wakely wrote: > > > On 26/02/19 13:28 +0100, Florian Weimer wrote: > > > > * Sérgio Basto: > > > > > > > > > The key was "can't represent -1 with an unsigned number" , I > > > > > add > > > > > some sign char to the code [1] and it fix the FTBFS > > > > > > > > > > Thanks , > > > > > > > > > > [1] > > > > > > > > > https://src.fedoraproject.org/fork/sergiomb/rpms/gdcm/blob/master/f/gdcm-2.8.8-fix-narrow.patch > > > > > > > > Please note that this patch changes the mangled names of > > > > template > > > > instantiations and thus breaks ABI. I'm not sure if this > > > > appropriate > > > > for a Fedora downstream-only patch, but maybe it's okay based > > > > on > > > > what > > > > the package does. > > > > > > I was going to say the same thing. It looks very wrong to me. > > > > > > It would be better to fix the use of the class, not the > > > definition of > > > the class. i.e. change String to String<(char)EOF, > > > ...>. > > > > > > Or stop assuming that EOF can fit in a character type and use > > > something like String<(char)-1, ...> instead. Otherwise if EOF > > > happens > > > to be a value like -191 then (char)EOF will produce the character > > > 'A' > > > which is probably not what it wants as a delimiter. EOF isn't > > > going > > > to > > > equal -191 for glibc, but it's still bogus to use EOF there IMO. > > > > Is stdio.h that defines EOF as -1 , so if we what work with files > > and > > use EOF character, we need use signed chars, though . > > I don't understand what you're saying here, sorry. stdio.h defines EOF as -1 , so if we want work with files and use EOF character, we need use signed chars, though . > If you're saying any code using files needs to use signed char, > that's > not true. You just need to stop trying to use EOF where a char is > needed. EOF is not a char, it's an int. ok > > This code is just part of directory Testing > > But your patch is to Source/Common/gdcmString.h which is not just a > test, right? aah yes now I understood the point . Thanks, -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: apiextractor FTBFS troubleshooting
On Tue, Feb 26, 2019 at 1:29 PM Jakub Jelinek wrote: > No, see my other mail on what should be done. > Since the scratch build shows that the tests pass I'm tempted to disable %check for now just to fix the FTBFS issue and re-enable when qt is fixed. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: qt4 rebuild
Richard Shaw wrote: > Ok, I updated the patch the COMPILER_VERSION issue (committed) and have > a local patch for the Q_FOREACH problem based on a qt 5 commit: > > https://github.com/qt/qtbase/commit/c35a3f519007af44c3b364b9af86f6a336f6411b > > With both of those problems fixed the build still fails probably due to > gcc 9 being more pedantic than previous versions. > > With my scratch build[1] I'm getting this strange error that I don't get > on a local mock build: > > collect2: fatal error: cannot find 'ld' > > So I'm pretty much out of my league at this point. I can commit the > Q_FOREACH patch if needed. > > Thanks, > Richard > > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=33069763 See https://bugzilla.redhat.com/show_bug.cgi?id=1683408 rob ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: qt4 rebuild
Ok, I updated the patch the COMPILER_VERSION issue (committed) and have a local patch for the Q_FOREACH problem based on a qt 5 commit: https://github.com/qt/qtbase/commit/c35a3f519007af44c3b364b9af86f6a336f6411b With both of those problems fixed the build still fails probably due to gcc 9 being more pedantic than previous versions. With my scratch build[1] I'm getting this strange error that I don't get on a local mock build: collect2: fatal error: cannot find 'ld' So I'm pretty much out of my league at this point. I can commit the Q_FOREACH patch if needed. Thanks, Richard [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=33069763 > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
On 26/02/19 19:42 +, Sérgio Basto wrote: On Tue, 2019-02-26 at 14:46 +, Jonathan Wakely wrote: On 26/02/19 13:28 +0100, Florian Weimer wrote: > * Sérgio Basto: > > > The key was "can't represent -1 with an unsigned number" , I add > > some sign char to the code [1] and it fix the FTBFS > > > > Thanks , > > > > [1] > > https://src.fedoraproject.org/fork/sergiomb/rpms/gdcm/blob/master/f/gdcm-2.8.8-fix-narrow.patch > > Please note that this patch changes the mangled names of template > instantiations and thus breaks ABI. I'm not sure if this > appropriate > for a Fedora downstream-only patch, but maybe it's okay based on > what > the package does. I was going to say the same thing. It looks very wrong to me. It would be better to fix the use of the class, not the definition of the class. i.e. change String to String<(char)EOF, ...>. Or stop assuming that EOF can fit in a character type and use something like String<(char)-1, ...> instead. Otherwise if EOF happens to be a value like -191 then (char)EOF will produce the character 'A' which is probably not what it wants as a delimiter. EOF isn't going to equal -191 for glibc, but it's still bogus to use EOF there IMO. Is stdio.h that defines EOF as -1 , so if we what work with files and use EOF character, we need use signed chars, though . I don't understand what you're saying here, sorry. If you're saying any code using files needs to use signed char, that's not true. You just need to stop trying to use EOF where a char is needed. EOF is not a char, it's an int. This code is just part of directory Testing But your patch is to Source/Common/gdcmString.h which is not just a test, right? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
On 26/02/2019 19:42, Sérgio Basto wrote: Is stdio.h that defines EOF as -1 , so if we what work with files and use EOF character, we need use signed chars, though . No, you need to use int. The EOF value is deliberately outside the range of character values so that EOF is not a valid character! If you look at the stdio functions that can return EOF you will find that they all use int not char... 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 Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: apiextractor FTBFS troubleshooting
On Tue, Feb 26, 2019 at 11:38 AM Jakub Jelinek wrote: > On Wed, Feb 27, 2019 at 02:29:32AM +0900, Mamoru TASAKA wrote: > > Richard Shaw wrote on 2019/02/27 2:23: > > > On Tue, Feb 26, 2019 at 11:17 AM Mamoru TASAKA < > mtas...@fedoraproject.org> > > > wrote: > > > > > > > So... I guess Qt "foreach" behavior changed with gcc9.. > > > > > > > > > > Is there any chance this will change or magically get fixed if qt is > > > rebuilt with gcc 9? > > > > > > Thanks, > > > Richard > > > > > > > Well, foreach or Q_FOREACH is just a "#define" macro (from > /usr/include/Qt/qglobal.h and > > /usr/include/QtCore/qglobal.h), so rebuilding qt(4) itself does not > sense. > > The Q_FOREACH macro relied on a G++ bug, which got fixed (in particular, > g++ > rejects forever break; and continue; in statement expressions > outside of a loop body (condition, init expr, increment expr) if there is > no outer loop, but due to a bug if it got past this check, for C++ would > jump to the break/continue labels of the inner rather than outer loop; for > C > we got it right, and for GCC 9 finally fixed it. > You need the > > https://github.com/qt/qtbase/commit/c35a3f519007af44c3b364b9af86f6a336f6411b > fix, which should be in reasonably recent Qt, but if some packages use very > old headers, the patch needs to be applied... > I created a patch based on that commit and am uploading an SRPM scratch build (I didn't want to commit it if it's wrong) but it is uploading VERY slowly. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
On Tue, 2019-02-26 at 14:46 +, Jonathan Wakely wrote: > On 26/02/19 13:28 +0100, Florian Weimer wrote: > > * Sérgio Basto: > > > > > The key was "can't represent -1 with an unsigned number" , I add > > > some sign char to the code [1] and it fix the FTBFS > > > > > > Thanks , > > > > > > [1] > > > https://src.fedoraproject.org/fork/sergiomb/rpms/gdcm/blob/master/f/gdcm-2.8.8-fix-narrow.patch > > > > Please note that this patch changes the mangled names of template > > instantiations and thus breaks ABI. I'm not sure if this > > appropriate > > for a Fedora downstream-only patch, but maybe it's okay based on > > what > > the package does. > > I was going to say the same thing. It looks very wrong to me. > > It would be better to fix the use of the class, not the definition of > the class. i.e. change String to String<(char)EOF, ...>. > > Or stop assuming that EOF can fit in a character type and use > something like String<(char)-1, ...> instead. Otherwise if EOF > happens > to be a value like -191 then (char)EOF will produce the character 'A' > which is probably not what it wants as a delimiter. EOF isn't going > to > equal -191 for glibc, but it's still bogus to use EOF there IMO. Is stdio.h that defines EOF as -1 , so if we what work with files and use EOF character, we need use signed chars, though . This code is just part of directory Testing > -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Retire YUM 3
On Tue, 2019-02-26 at 06:22 +, Sérgio Basto wrote: > On Fri, 2019-02-01 at 11:23 -0500, Neal Gompa wrote: > > RepoView just needs a patch to switch from rpmUtils and yum.comps > > to > > rpm and libcomps Python bindings, which I think I already wrote and > > put somewhere. I'll have to dig it out. Sorry my last email had lots of typo . I need a tool to read repos and compare it . I imported yours repoview repo [1] into gitub [2] , I don't use / know mercurial Neal Gompa have use a user in github to update the authors in github [3] And other subject is "tracker bug for Fedora to switch over to dnf from yum " [4] we still have a lot of packages dependent on yum . Best regards, [1] https://bitbucket.org/Conan_Kudo/repoview [2] https://github.com/sergiomb2/repoview [3] https://github.com/sergiomb2/repoview/import/authors [4] https://bugzilla.redhat.com/show_bug.cgi?id=1156491 > I need a tool to read repos and compare it , meanwhile I found one > bug tracker bug for Fedora to switch over to dnf from yum and yum- > utils [1] > > If you could find this code would be great , I checking your repo > meanwhile . > > Thanks. > > [1] > > https://bugzilla.redhat.com/show_bug.cgi?id=1156491 > > -- > Sérgio M. B. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: apiextractor FTBFS troubleshooting
On Tue, Feb 26, 2019 at 01:25:54PM -0600, Richard Shaw wrote: > > What I did is: > > > > LANG=C grep -rl 'foreach.*,' . | \ > > xargs sed -i -e '\@foreach.*,@s|foreach\(.*\),|for\1:|' > > > > So now I appreciate it if someone would investigate Q_FOREACH macro. > > > > Thanks Mamoru! As far as you know is this safe to put in an official build? No, see my other mail on what should be done. Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: apiextractor FTBFS troubleshooting
On Tue, Feb 26, 2019 at 11:39 AM Mamoru TASAKA wrote: > Mamoru TASAKA wrote on 2019/02/27 2:29: > > Richard Shaw wrote on 2019/02/27 2:23: > >> On Tue, Feb 26, 2019 at 11:17 AM Mamoru TASAKA < > mtas...@fedoraproject.org> > >> wrote: > >> > >>> So... I guess Qt "foreach" behavior changed with gcc9.. > >>> > >> > >> Is there any chance this will change or magically get fixed if qt is > >> rebuilt with gcc 9? > >> > >> Thanks, > >> Richard > >> > > > > Well, foreach or Q_FOREACH is just a "#define" macro (from > /usr/include/Qt/qglobal.h and > > /usr/include/QtCore/qglobal.h), so rebuilding qt(4) itself does not > sense. > > > > So now I tried to change all "foreach(... , ...)" usage with "for(... : > ...)", > actually it seems okay?? > > https://koji.fedoraproject.org/koji/taskinfo?taskID=33067948 > > What I did is: > > LANG=C grep -rl 'foreach.*,' . | \ > xargs sed -i -e '\@foreach.*,@s|foreach\(.*\),|for\1:|' > > So now I appreciate it if someone would investigate Q_FOREACH macro. > Thanks Mamoru! As far as you know is this safe to put in an official build? Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Reminder: Beta freeze and code complete deadline in one week
On Tue, 2019-02-26 at 10:38 -0500, Ben Cotton wrote: > According to the Fedora 30 schedule[1], the 100% code complete > deadline[2] for Changes is Tuesday, 5 March. The beta freeze[3] > takes effect on this date as well. All Changes should be in "ON_QA" > state by then. I still haven't any compose for F30 completed, we should have time to build some packages against f30 buildroots , this situation also happened in F29 . Question why composer are broken , when is most needed ? What I mean is Beta freeze should be postponed after two weeks of composer start to work . Given 2 week to packages maintainers fix the FTBFS packages etc . > [1] https://fedoraproject.org/wiki/Releases/30/Schedule > [2] > https://fedoraproject.org/wiki/Changes/Policy#Change_Checkpoint:_100.25_code_complete_deadline > [3] https://fedoraproject.org/wiki/Milestone_freezes > > -- > Ben Cotton > Fedora Program Manager > TZ=America/Indiana/Indianapolis > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Self Introduction: ChillyBot
Hello everyone! My name is Chilly. I am looking to bring back Snort IDS into the Fedora Project and maintain it for at least several years. I am relatively new to packaging but have been using Fedora for many years now as my daily driver. Doing my best to follow to guide according to https://fedoraproject.org/wiki/Join_the_package_collection_maintainers and am excited to contribute. I work as a Linux Sysadmin and infosec/privacy consultant. GPG Fingerprint: [0977E14243A7B76741A6E049076FD2093766DC98](http://keys.fedoraproject.org/pks/lookup?search=0x0977E14243A7B76741A6E049076FD2093766DC98&fingerprint=on&hash=on&op=index) Any question or comments feel free to contact me directly :) Best wishes, Chilly___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: qt4 rebuild
On Tue, Feb 26, 2019 at 10:27 AM Rex Dieter wrote:
> Richard Shaw wrote:
>
> > I'm troubleshooting why apiextractor tests segfault during package
> > building. I have not been able to attribute it to any change in build
> > flags so I started looking at qt4 which appears to still be FTBFS for F30
> > rebuild.
> >
> > There's a check in the spec file which fails:
> >
> > + grep '^#define QT_BUILD_KEY ' src/corelib/global/qconfig.h
> > #define QT_BUILD_KEY "x86_64 linux g++-9 full-config"
> > BUILDSTDERR: ++ grep '^#define QT_BUILD_KEY '
> src/corelib/global/qconfig.h
> > BUILDSTDERR: ++ cut '-d ' -f5
> > QT_BUILD_KEY_COMPILER failure
> > + QT_BUILD_KEY_COMPILER=g++-9
> > + '[' g++-9 '!=' g++-4 ']'
> > + echo 'QT_BUILD_KEY_COMPILER failure'
> > + exit 1
> >
> > It looks like after configuration that the "KEY" changed from g++4 to
> > g++9.
> >
> > Is this check appropriate?
>
> The check is legit'ish. In particular, afaik, the key should not have
> changed, so that should be fixed in qt4
>
Found it... configure has been heavily patched to deal with newer gcc
versions but has not been updated to deal with gcc 9...
#---
# generate QT_BUILD_KEY
#---
# some compilers generate binary incompatible code between different
versions,
# so we need to generate a build key that is different between these
compilers
COMPAT_COMPILER=
case "$COMPILER" in
g++*)
# GNU C++
COMPILER_VERSION=`${QMAKE_CONF_COMPILER} -dumpversion 2>/dev/null`
case "$COMPILER_VERSION" in
*.*.*)
QT_GCC_MAJOR_VERSION=`echo $COMPILER_VERSION | sed
's,^\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\).*,\1,'`
QT_GCC_MINOR_VERSION=`echo $COMPILER_VERSION | sed
's,^\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\).*,\2,'`
QT_GCC_PATCH_VERSION=`echo $COMPILER_VERSION | sed
's,^\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\).*,\3,'`
;;
*.*)
QT_GCC_MAJOR_VERSION=`echo $COMPILER_VERSION | sed
's,^\([0-9]*\)\.\([0-9]*\).*,\1,'`
QT_GCC_MINOR_VERSION=`echo $COMPILER_VERSION | sed
's,^\([0-9]*\)\.\([0-9]*\).*,\2,'`
QT_GCC_PATCH_VERSION=0
;;
*)
QT_GCC_MAJOR_VERSION=$COMPILER_VERSION
QT_GCC_MINOR_VERSION=0
QT_GCC_PATCH_VERSION=0
;;
esac
case "$COMPILER_VERSION" in
2.95.*)
COMPILER_VERSION="2.95.*"
;;
3.*)
COMPILER_VERSION="3.*"
;;
5*|4.*) <<<--- HERE ---|||
COMPILER_VERSION="4"
;;
*)
;;
esac
[ '!' -z "$COMPILER_VERSION" ] && COMPILER="g++-${COMPILER_VERSION}"
;;
icc*)
I just updated the patch and performing a local mock build to see if that
was the only issue.
Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: apiextractor FTBFS troubleshooting
Mamoru TASAKA wrote on 2019/02/27 2:29: Richard Shaw wrote on 2019/02/27 2:23: On Tue, Feb 26, 2019 at 11:17 AM Mamoru TASAKA wrote: So... I guess Qt "foreach" behavior changed with gcc9.. Is there any chance this will change or magically get fixed if qt is rebuilt with gcc 9? Thanks, Richard Well, foreach or Q_FOREACH is just a "#define" macro (from /usr/include/Qt/qglobal.h and /usr/include/QtCore/qglobal.h), so rebuilding qt(4) itself does not sense. So now I tried to change all "foreach(... , ...)" usage with "for(... : ...)", actually it seems okay?? https://koji.fedoraproject.org/koji/taskinfo?taskID=33067948 What I did is: LANG=C grep -rl 'foreach.*,' . | \ xargs sed -i -e '\@foreach.*,@s|foreach\(.*\),|for\1:|' So now I appreciate it if someone would investigate Q_FOREACH macro. Regards, Mamoru ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python-cherrypy vs python3-cherrypy - can we keep just one?
On Fri, Feb 15, 2019 at 1:10 AM Matthias Runge wrote: > With that, I'm looking for co-maintainers for python-cherrypy. The > package is severely outdated and it seems there hasn't been any > significant contribution to this over the past 4 years. I may have been > too optimistic with my available time for this. The newest versions of Ceph depend on CherryPy, so I'm interested in keeping it up-to-date as long as that continues. There are several new dependencies to bring in. I've packaged them in https://copr.fedorainfracloud.org/coprs/ktdreyer/python-cherrypy/ We also need python-path to be updated, https://src.fedoraproject.org/rpms/python-path/pull-request/2 . Xavier would you please review and merge that change? - Ken ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: apiextractor FTBFS troubleshooting
On Wed, Feb 27, 2019 at 02:29:32AM +0900, Mamoru TASAKA wrote: > Richard Shaw wrote on 2019/02/27 2:23: > > On Tue, Feb 26, 2019 at 11:17 AM Mamoru TASAKA > > wrote: > > > > > So... I guess Qt "foreach" behavior changed with gcc9.. > > > > > > > Is there any chance this will change or magically get fixed if qt is > > rebuilt with gcc 9? > > > > Thanks, > > Richard > > > > Well, foreach or Q_FOREACH is just a "#define" macro (from > /usr/include/Qt/qglobal.h and > /usr/include/QtCore/qglobal.h), so rebuilding qt(4) itself does not sense. The Q_FOREACH macro relied on a G++ bug, which got fixed (in particular, g++ rejects forever break; and continue; in statement expressions outside of a loop body (condition, init expr, increment expr) if there is no outer loop, but due to a bug if it got past this check, for C++ would jump to the break/continue labels of the inner rather than outer loop; for C we got it right, and for GCC 9 finally fixed it. You need the https://github.com/qt/qtbase/commit/c35a3f519007af44c3b364b9af86f6a336f6411b fix, which should be in reasonably recent Qt, but if some packages use very old headers, the patch needs to be applied... Note, clang/clang++ for some weird reason chose the non-sensical behavior. Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: apiextractor FTBFS troubleshooting
Richard Shaw wrote on 2019/02/27 2:23: On Tue, Feb 26, 2019 at 11:17 AM Mamoru TASAKA wrote: So... I guess Qt "foreach" behavior changed with gcc9.. Is there any chance this will change or magically get fixed if qt is rebuilt with gcc 9? Thanks, Richard Well, foreach or Q_FOREACH is just a "#define" macro (from /usr/include/Qt/qglobal.h and /usr/include/QtCore/qglobal.h), so rebuilding qt(4) itself does not sense. Regards, Mamoru ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: apiextractor FTBFS troubleshooting
On Tue, Feb 26, 2019 at 11:17 AM Mamoru TASAKA wrote: > So... I guess Qt "foreach" behavior changed with gcc9.. > Is there any chance this will change or magically get fixed if qt is rebuilt with gcc 9? Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: apiextractor FTBFS troubleshooting
John Reiser wrote on 2019/02/26 13:18:
That test 'testvoidarg' succeeds for me (normal termination, no SIGSEGV) on
Fedora 28 and Fedora 29.
Yes, it only seems to affect f30/Rawhide with GCC 9 (though I'm not sure it's
the culprit).
The traceback says:
> 41 QCOMPARE(addedFunc->arguments().count(), 0);
so the suggestion is to check if addedFunc->arguments() is NULL.
'addedFunc' itself is 0 (NULL).
Substituting testvoidarg.cpp.o as compiled by gcc-8.2.1-6.fc28.x86_64 (from the
same source)
gives the same SIGSEGV. So compiling testvoidarg.cpp with gcc-9 is no longer a
suspect.
=
void TestVoidArg::testVoidParsedFunction()
{
const char cppCode[] = "struct A { void a(void); };";
const char xmlCode[] = "\
\
\
";
TestUtil t(cppCode, xmlCode);
AbstractMetaClassList classes = t.builder()->classes();
AbstractMetaClass* classA = classes.findClass("A");
QVERIFY(classA);
const AbstractMetaFunction* addedFunc = classA->findFunction("a");
QCOMPARE(addedFunc->arguments().count(), 0); / line 41
}
=
The trouble here is that on "findFunction" as defined in
abstractmetalang.cpp:1487
1487 const AbstractMetaFunction* AbstractMetaClass::findFunction(const
QString& functionName) const
1488 {
1489 foreach (const AbstractMetaFunction *f, functions()) {
1490 if (f->name() == functionName)
1491 return f;
1492 }
1493 return 0;
1494 }
for QString list functions() it is expected to contain "a" but actually it just
contains "A" , which looks like its class name instead of function names
contained
in the class - so it does not match and findFunction() returns 0.
Then... at least for testvoidarg test, the following patch seems to work...
--- apiextractor-0.10.10/abstractmetalang.cpp.for 2019-02-27
02:08:50.743492673 +0900
+++ apiextractor-0.10.10/abstractmetalang.cpp 2019-02-27 02:09:26.443445212
+0900
@@ -1486,7 +1486,8 @@
const AbstractMetaFunction* AbstractMetaClass::findFunction(const QString& functionName) const
{
-foreach (const AbstractMetaFunction *f, functions()) {
+//foreach (const AbstractMetaFunction *f, functions()) {
+ for (const AbstractMetaFunction *f : functions()) {
if (f->name() == functionName)
return f;
}
==
https://koji.fedoraproject.org/koji/taskinfo?taskID=33067706
(There are still many test failures, but at least this shows:
Start 33: testvoidarg
33/35 Test #33: testvoidarg .. Passed0.01 sec
So... I guess Qt "foreach" behavior changed with gcc9..
Regards,
Mamoru
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: qt4 rebuild
Richard Shaw wrote: > I'm troubleshooting why apiextractor tests segfault during package > building. I have not been able to attribute it to any change in build > flags so I started looking at qt4 which appears to still be FTBFS for F30 > rebuild. > > There's a check in the spec file which fails: > > + grep '^#define QT_BUILD_KEY ' src/corelib/global/qconfig.h > #define QT_BUILD_KEY "x86_64 linux g++-9 full-config" > BUILDSTDERR: ++ grep '^#define QT_BUILD_KEY ' src/corelib/global/qconfig.h > BUILDSTDERR: ++ cut '-d ' -f5 > QT_BUILD_KEY_COMPILER failure > + QT_BUILD_KEY_COMPILER=g++-9 > + '[' g++-9 '!=' g++-4 ']' > + echo 'QT_BUILD_KEY_COMPILER failure' > + exit 1 > > It looks like after configuration that the "KEY" changed from g++4 to > g++9. > > Is this check appropriate? The check is legit'ish. In particular, afaik, the key should not have changed, so that should be fixed in qt4 -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: apiextractor FTBFS troubleshooting
There are 8 libraries (-lQtTest -lQtCore -lQtGui -lxslt -lxml2 -lQtCore -lQtXmlPatterns -lQtXml) plus an explicit libapiextractor.so.0.10.1. Did you run nine tests, replacing the pieces one-by-one with their Fedora 29 versions? I'm not sure how to do that in a mock chroot... Boot the Fedora 30 Live Workstation from a USB flash memory drive, then use that. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: apiextractor FTBFS troubleshooting
On Tue, Feb 26, 2019 at 9:52 AM John Reiser wrote: > > Is it definitely the linking? Or should I check the compiler arguments > as well? > > There are 8 libraries (-lQtTest -lQtCore -lQtGui -lxslt -lxml2 -lQtCore > -lQtXmlPatterns -lQtXml) > plus an explicit libapiextractor.so.0.10.1. Did you run nine tests, > replacing the pieces > one-by-one with their Fedora 29 versions? > I'm not sure how to do that in a mock chroot... Right now I just noticed that qt did not get rebuilt yet for F30 due to this check in the spec file: + grep '^#define QT_BUILD_KEY ' src/corelib/global/qconfig.h #define QT_BUILD_KEY "x86_64 linux g++-9 full-config" BUILDSTDERR: ++ grep '^#define QT_BUILD_KEY ' src/corelib/global/qconfig.h BUILDSTDERR: ++ cut '-d ' -f5 QT_BUILD_KEY_COMPILER failure + QT_BUILD_KEY_COMPILER=g++-9 + '[' g++-9 '!=' g++-4 ']' + echo 'QT_BUILD_KEY_COMPILER failure' + exit 1 I wonder if getting a good rebuild could fix the problem? Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
qt4 rebuild
I'm troubleshooting why apiextractor tests segfault during package building. I have not been able to attribute it to any change in build flags so I started looking at qt4 which appears to still be FTBFS for F30 rebuild. There's a check in the spec file which fails: + grep '^#define QT_BUILD_KEY ' src/corelib/global/qconfig.h #define QT_BUILD_KEY "x86_64 linux g++-9 full-config" BUILDSTDERR: ++ grep '^#define QT_BUILD_KEY ' src/corelib/global/qconfig.h BUILDSTDERR: ++ cut '-d ' -f5 QT_BUILD_KEY_COMPILER failure + QT_BUILD_KEY_COMPILER=g++-9 + '[' g++-9 '!=' g++-4 ']' + echo 'QT_BUILD_KEY_COMPILER failure' + exit 1 It looks like after configuration that the "KEY" changed from g++4 to g++9. Is this check appropriate? Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: apiextractor FTBFS troubleshooting
Is it definitely the linking? Or should I check the compiler arguments as well? There are 8 libraries (-lQtTest -lQtCore -lQtGui -lxslt -lxml2 -lQtCore -lQtXmlPatterns -lQtXml) plus an explicit libapiextractor.so.0.10.1. Did you run nine tests, replacing the pieces one-by-one with their Fedora 29 versions? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Introducing packit
On 20. 02. 19 23:24, Tomas Tomecek wrote: Hello, at DevConf.cz, we have introduced a new project: packit [1] [2]. [1] https://www.youtube.com/watch?v=KpF27v6K4Oc [2] https://github.com/packit-service/packit From the ticket: >> FESCo is concerned that the presented idea of how this automation >> should work is only applicable to a very limited set of packages and >> would rather see a focus on automating stuff for greater >> audience. > > Yes and no. With source-git [3] this is applicable to any project. > > [3] https://github.com/packit-service/packit#ehm-whats-source-git This sounds like it is only applicable to projects: - controlled by Fedora AND - not concerned by the separation of concerns between upstream and downstream. However it says something about source-git only projects as well. This seems like it is adding one extra level of complexity. Care to elaborate how this works exactly? A) for the package maintain who deliberately chose to do this B) for a provenpackager doing a mass change (e.g. removing py2 subpackages) C) for releng doing a mass rebuild I be especially interested in a step by step example in a form of "(who) does (what)". Thanks. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Reminder: Beta freeze and code complete deadline in one week
According to the Fedora 30 schedule[1], the 100% code complete deadline[2] for Changes is Tuesday, 5 March. The beta freeze[3] takes effect on this date as well. All Changes should be in "ON_QA" state by then. [1] https://fedoraproject.org/wiki/Releases/30/Schedule [2] https://fedoraproject.org/wiki/Changes/Policy#Change_Checkpoint:_100.25_code_complete_deadline [3] https://fedoraproject.org/wiki/Milestone_freezes -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Modularity] Team IRC meeting minutes (2019-02-26)
#fedora-meeting-3: Weekly Meeting of the Modularity Team Meeting started by nils at 15:00:00 UTC. Minutes: https://meetbot.fedoraproject.org/fedora-meeting-3/2019-02-26/modularity.2019-02-26-15.00.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-3/2019-02-26/modularity.2019-02-26-15.00.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-3/2019-02-26/modularity.2019-02-26-15.00.log.html Meeting summary --- * Roll Call (nils, 15:00:00) * Agenda (nils, 15:02:28) * #112 Discussion: Module lifecycles (nils, 15:02:28) * #115 Discussion: Stream branch ownership for packages & modules (nils, 15:02:28) * #112 Discussion: Module lifecycles (nils, 15:03:46) * LINK: https://pagure.io/modularity/issue/112 (nils, 15:03:46) * LINK: https://pagure.io/fesco/issue/2027 (nils, 15:03:46) * ACTION: sgallagh will send a PR to the lifecycles proposal removing implementation details (asamalik, 15:14:00) * #115 Discussion: Stream branch ownership for packages & modules (nils, 15:20:50) * LINK: https://pagure.io/modularity/issue/115 (nils, 15:20:50) * LINK: https://pagure.io/fesco/issue/2028 (nils, 15:20:50) * postponed until next meeting (nils, 15:21:20) * Open Floor (nils, 15:22:12) * fedmod 0.5.0 released and submitted as a Fedora update (nils, 15:23:08) * summarize-module can query information from build systems (MBS) alternatively to RPM repositories now (nils, 15:26:20) * LINK: https://bodhi.fedoraproject.org/updates/FEDORA-2019-5f16d857b1 F28 update (nils, 15:26:56) * LINK: https://bodhi.fedoraproject.org/updates/FEDORA-2019-773ef3b70b F29 update (nils, 15:27:09) * ACTION: nils write a blog post and get it published to communityblog.fedoraproject.org (nils, 15:28:24) Meeting ended at 15:31:59 UTC. Action Items * sgallagh will send a PR to the lifecycles proposal removing implementation details * nils write a blog post and get it published to communityblog.fedoraproject.org Action Items, by person --- * nils * nils write a blog post and get it published to communityblog.fedoraproject.org * sgallagh * sgallagh will send a PR to the lifecycles proposal removing implementation details * **UNASSIGNED** * (none) People Present (lines said) --- * nils (49) * asamalik (27) * langdon (17) * contyk (13) * zodbot (13) * sgallagh (10) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- Nils Philippsen"Those who would give up Essential Liberty to Software Engineer purchase a little Temporary Safety, deserve neither Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint:C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: apiextractor FTBFS troubleshooting
On Tue, Feb 26, 2019 at 8:44 AM John Reiser wrote: > > 'addedFunc' itself is 0 (NULL). > > Substituting testvoidarg.cpp.o as compiled by > gcc-8.2.1-6.fc28.x86_64 (from the same source) > > gives the same SIGSEGV. So compiling testvoidarg.cpp with gcc-9 is > no longer a suspect. > > > > > > I just performed a mockbuild for Fedora 29 and all tests passed... What > am I missing? > > Look at the final command (the static binding) that built the > 'testvoidarg' executable: > = > cd .../BUILD/apiextractor-0.10.10/x86_64-redhat-linux-gnu/tests && > /usr/bin/cmake -E cmake_link_script CMakeFiles/testvoidarg.dir/link.txt > --verbose=1 > > /usr/bin/c++ -O2 -g -pipe -Wall -Werror=format-security > -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS \ > -fexceptions -fstack-protector-strong -grecord-gcc-switches > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 \ > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic > -fasynchronous-unwind-tables \ > -fstack-clash-protection -fcf-protection -Wall -fvisibility=hidden > -DNDEBUG -Wl,-z,relro -Wl,-z,now \ > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -rdynamic > CMakeFiles/testvoidarg.dir/testvoidarg.cpp.o \ > -o testvoidarg > -Wl,-rpath,.../BUILD/apiextractor-0.10.10/x86_64-redhat-linux-gnu/tests \ > -lQtTest -lQtCore -lQtGui libapiextractor.so.0.10.10 -lxslt -lxml2 > -lQtCore -lQtXmlPatterns -lQtXml > = > > Replace each piece, one-by-one, with the corresponding piece from Fedora > 29, > (or from Fedora 30, but compiled by gcc-8.2.1-6) and test before replacing > the next piece, too. In this case: each '-l' argument, and the > libapiextractor.so.0.10.10 . > The lines are identical other than rawhide added -Wl,--as-needed but I tried removing it and there was no difference. I also checked the contents of all the spec files and they are also identical. Is it definitely the linking? Or should I check the compiler arguments as well? Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
On 26/02/19 13:28 +0100, Florian Weimer wrote: * Sérgio Basto: The key was "can't represent -1 with an unsigned number" , I add some sign char to the code [1] and it fix the FTBFS Thanks , [1] https://src.fedoraproject.org/fork/sergiomb/rpms/gdcm/blob/master/f/gdcm-2.8.8-fix-narrow.patch Please note that this patch changes the mangled names of template instantiations and thus breaks ABI. I'm not sure if this appropriate for a Fedora downstream-only patch, but maybe it's okay based on what the package does. I was going to say the same thing. It looks very wrong to me. It would be better to fix the use of the class, not the definition of the class. i.e. change String to String<(char)EOF, ...>. Or stop assuming that EOF can fit in a character type and use something like String<(char)-1, ...> instead. Otherwise if EOF happens to be a value like -191 then (char)EOF will produce the character 'A' which is probably not what it wants as a delimiter. EOF isn't going to equal -191 for glibc, but it's still bogus to use EOF there IMO. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: apiextractor FTBFS troubleshooting
'addedFunc' itself is 0 (NULL). Substituting testvoidarg.cpp.o as compiled by gcc-8.2.1-6.fc28.x86_64 (from the same source) gives the same SIGSEGV. So compiling testvoidarg.cpp with gcc-9 is no longer a suspect. I just performed a mockbuild for Fedora 29 and all tests passed... What am I missing? Look at the final command (the static binding) that built the 'testvoidarg' executable: = cd .../BUILD/apiextractor-0.10.10/x86_64-redhat-linux-gnu/tests && /usr/bin/cmake -E cmake_link_script CMakeFiles/testvoidarg.dir/link.txt --verbose=1 /usr/bin/c++ -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS \ -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 \ -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables \ -fstack-clash-protection -fcf-protection -Wall -fvisibility=hidden -DNDEBUG -Wl,-z,relro -Wl,-z,now \ -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -rdynamic CMakeFiles/testvoidarg.dir/testvoidarg.cpp.o \ -o testvoidarg -Wl,-rpath,.../BUILD/apiextractor-0.10.10/x86_64-redhat-linux-gnu/tests \ -lQtTest -lQtCore -lQtGui libapiextractor.so.0.10.10 -lxslt -lxml2 -lQtCore -lQtXmlPatterns -lQtXml = Replace each piece, one-by-one, with the corresponding piece from Fedora 29, (or from Fedora 30, but compiled by gcc-8.2.1-6) and test before replacing the next piece, too. In this case: each '-l' argument, and the libapiextractor.so.0.10.10 . ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Broken modules on rawhide
On 26. 02. 19 15:07, Petr Šabata wrote: On Tue, Feb 26, 2019 at 02:23:35PM +0100, Miroslav Suchý wrote: From: https://bugzilla.redhat.com/show_bug.cgi?id=1680320#c2 When you try to run: mock -r fedora-rawhide-x86_64 shell You will get: Problem 1: conflicting requests - nothing provides module(platform:f30) needed by module stratis:1:20181215204600:a5b0195c-0.x86_64 Problem 2: conflicting requests - nothing provides module(platform:f30) needed by module standard-test-roles:3.0:3020190214144451:a5b0195c-0.x86_64 rawhide has module_id=platform:f31. I think this shouldn't have been updated until after the branch point. When will be all rawhide modules rebuild? Or what is the solution for this? Because right now all rawhide modules are basically broken. And because Mock started using modular fedora repos, then all Mock attempts for rawhides builds are broken too. At branch point, modules that can run on any platform, or are compatible with platform:f31, will simply be tagged. Modules that could run of f31 if rebuilt will be rebuilt. I think this is an unfortunate timing issue and needs to be coordinated better in the future. The branch point happens later this week; perhaps we could revert the change for the time being? I don't know what do you exactly mean by "branch point" but "Branch Fedora 30 from Rawhide" already happened a week ago. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Broken modules on rawhide
On 26/02/2019 14:08, Petr Šabata wrote: I always wonder why people disable the repo -- it's part of Fedora. What's your motivation? I'm not using it and it's extra metadata to fetch, parse and store that slows down updating? That and on work machines we're not currently mirroring modules to our local mirror because we're not using them. 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 Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: apiextractor FTBFS troubleshooting
On Mon, Feb 25, 2019 at 10:19 PM John Reiser wrote: > > That test 'testvoidarg' succeeds for me (normal termination, no > SIGSEGV) on Fedora 28 and Fedora 29. > > > > > > Yes, it only seems to affect f30/Rawhide with GCC 9 (though I'm not sure > it's the culprit). > > > > > > The traceback says: > > > 41QCOMPARE(addedFunc->arguments().count(), 0); > > so the suggestion is to check if addedFunc->arguments() is NULL. > > 'addedFunc' itself is 0 (NULL). > Substituting testvoidarg.cpp.o as compiled by gcc-8.2.1-6.fc28.x86_64 > (from the same source) > gives the same SIGSEGV. So compiling testvoidarg.cpp with gcc-9 is no > longer a suspect. > I just performed a mockbuild for Fedora 29 and all tests passed... What am I missing? Test project /builddir/build/BUILD/apiextractor-0.10.10/x86_64-redhat-linux-gnu Start 1: testabstractmetaclass 1/35 Test #1: testabstractmetaclass Passed0.02 sec Start 2: testabstractmetatype 2/35 Test #2: testabstractmetatype . Passed0.02 sec Start 3: testaddfunction 3/35 Test #3: testaddfunction .. Passed0.02 sec Start 4: testarrayargument 4/35 Test #4: testarrayargument Passed0.01 sec Start 5: testcodeinjection 5/35 Test #5: testcodeinjection Passed0.01 sec Start 6: testcontainer 6/35 Test #6: testcontainer Passed0.01 sec Start 7: testconversionoperator 7/35 Test #7: testconversionoperator ... Passed0.01 sec Start 8: testconversionruletag 8/35 Test #8: testconversionruletag Passed0.02 sec Start 9: testctorinformation 9/35 Test #9: testctorinformation .. Passed0.01 sec Start 10: testdroptypeentries 10/35 Test #10: testdroptypeentries .. Passed0.02 sec Start 11: testdtorinformation 11/35 Test #11: testdtorinformation .. Passed0.01 sec Start 12: testenum 12/35 Test #12: testenum . Passed0.02 sec Start 13: testextrainclude 13/35 Test #13: testextrainclude . Passed0.01 sec Start 14: testfunctiontag 14/35 Test #14: testfunctiontag .. Passed0.01 sec Start 15: testimplicitconversions 15/35 Test #15: testimplicitconversions .. Passed0.01 sec Start 16: testinserttemplate 16/35 Test #16: testinserttemplate ... Passed0.01 sec Start 17: testmodifyfunction 17/35 Test #17: testmodifyfunction ... Passed0.01 sec Start 18: testmultipleinheritance 18/35 Test #18: testmultipleinheritance .. Passed0.01 sec Start 19: testnamespace 19/35 Test #19: testnamespace Passed0.01 sec Start 20: testnestedtypes 20/35 Test #20: testnestedtypes .. Passed0.01 sec Start 21: testnumericaltypedef 21/35 Test #21: testnumericaltypedef . Passed0.01 sec Start 22: testprimitivetypetag 22/35 Test #22: testprimitivetypetag . Passed0.01 sec Start 23: testrefcounttag 23/35 Test #23: testrefcounttag .. Passed0.01 sec Start 24: testreferencetopointer 24/35 Test #24: testreferencetopointer ... Passed0.01 sec Start 25: testremovefield 25/35 Test #25: testremovefield .. Passed0.01 sec Start 26: testremoveimplconv 26/35 Test #26: testremoveimplconv ... Passed0.01 sec Start 27: testremoveoperatormethod 27/35 Test #27: testremoveoperatormethod . Passed0.01 sec Start 28: testresolvetype 28/35 Test #28: testresolvetype .. Passed0.01 sec Start 29: testreverseoperators 29/35 Test #29: testreverseoperators . Passed0.01 sec Start 30: testtemplates 30/35 Test #30: testtemplates Passed0.02 sec Start 31: testtoposort 31/35 Test #31: testtoposort . Passed0.01 sec Start 32: testvaluetypedefaultctortag 32/35 Test #32: testvaluetypedefaultctortag .. Passed0.01 sec Start 33: testvoidarg 33/35 Test #33: testvoidarg .. Passed0.01 sec Start 34: testtyperevision 34/35 Test #34: testtyperevision . Passed0.01 sec Start 35: testmodifydocumentation 35/35 Test #35: testmodifydocumentation .. Passed0.01 sec 100% tests passed, 0 tests failed out of 35 Thanks, RIchard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archi
Re: Broken modules on rawhide
On Tue, Feb 26, 2019 at 02:41:56PM +0100, Fabio Valentini wrote: > On Tue, Feb 26, 2019, 14:24 Miroslav Suchý wrote: > > > From: > > https://bugzilla.redhat.com/show_bug.cgi?id=1680320#c2 > > > > When you try to run: > > mock -r fedora-rawhide-x86_64 shell > > > > You will get: > > Problem 1: conflicting requests > > - nothing provides module(platform:f30) needed by module > > stratis:1:20181215204600:a5b0195c-0.x86_64 > > Problem 2: conflicting requests > > - nothing provides module(platform:f30) needed by module > > standard-test-roles:3.0:3020190214144451:a5b0195c-0.x86_64 > > > > > > rawhide has module_id=platform:f31. > > > > When will be all rawhide modules rebuild? Or what is the solution for > > this? Because right now all rawhide modules are > > basically broken. And because Mock started using modular fedora repos, > > then all Mock attempts for rawhides builds are > > broken too. > > > > Related: It would be nice if module repositories in mock (and COPR) were an > optional thing (right now, probably default=off, until that stuff is > fixed), like bootstrap chroot and network access. > > I know, "just add another option" ... still, I'll manually disable all > modular repos in mock configs on my local system, but that's not an option > for COPR. I always wonder why people disable the repo -- it's part of Fedora. What's your motivation? P signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Broken modules on rawhide
On Tue, Feb 26, 2019 at 02:23:35PM +0100, Miroslav Suchý wrote: > From: > https://bugzilla.redhat.com/show_bug.cgi?id=1680320#c2 > > When you try to run: > mock -r fedora-rawhide-x86_64 shell > > You will get: > Problem 1: conflicting requests > - nothing provides module(platform:f30) needed by module > stratis:1:20181215204600:a5b0195c-0.x86_64 > Problem 2: conflicting requests > - nothing provides module(platform:f30) needed by module > standard-test-roles:3.0:3020190214144451:a5b0195c-0.x86_64 > > > rawhide has module_id=platform:f31. I think this shouldn't have been updated until after the branch point. > When will be all rawhide modules rebuild? Or what is the solution for this? > Because right now all rawhide modules are > basically broken. And because Mock started using modular fedora repos, then > all Mock attempts for rawhides builds are > broken too. At branch point, modules that can run on any platform, or are compatible with platform:f31, will simply be tagged. Modules that could run of f31 if rebuilt will be rebuilt. I think this is an unfortunate timing issue and needs to be coordinated better in the future. The branch point happens later this week; perhaps we could revert the change for the time being? P signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Broken modules on rawhide
On Tue, Feb 26, 2019, 14:24 Miroslav Suchý wrote: > From: > https://bugzilla.redhat.com/show_bug.cgi?id=1680320#c2 > > When you try to run: > mock -r fedora-rawhide-x86_64 shell > > You will get: > Problem 1: conflicting requests > - nothing provides module(platform:f30) needed by module > stratis:1:20181215204600:a5b0195c-0.x86_64 > Problem 2: conflicting requests > - nothing provides module(platform:f30) needed by module > standard-test-roles:3.0:3020190214144451:a5b0195c-0.x86_64 > > > rawhide has module_id=platform:f31. > > When will be all rawhide modules rebuild? Or what is the solution for > this? Because right now all rawhide modules are > basically broken. And because Mock started using modular fedora repos, > then all Mock attempts for rawhides builds are > broken too. > Related: It would be nice if module repositories in mock (and COPR) were an optional thing (right now, probably default=off, until that stuff is fixed), like bootstrap chroot and network access. I know, "just add another option" ... still, I'll manually disable all modular repos in mock configs on my local system, but that's not an option for COPR. Fabio > Miroslav > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Broken modules on rawhide
From: https://bugzilla.redhat.com/show_bug.cgi?id=1680320#c2 When you try to run: mock -r fedora-rawhide-x86_64 shell You will get: Problem 1: conflicting requests - nothing provides module(platform:f30) needed by module stratis:1:20181215204600:a5b0195c-0.x86_64 Problem 2: conflicting requests - nothing provides module(platform:f30) needed by module standard-test-roles:3.0:3020190214144451:a5b0195c-0.x86_64 rawhide has module_id=platform:f31. When will be all rawhide modules rebuild? Or what is the solution for this? Because right now all rawhide modules are basically broken. And because Mock started using modular fedora repos, then all Mock attempts for rawhides builds are broken too. Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
* Sérgio Basto: > The key was "can't represent -1 with an unsigned number" , I add some sign > char to the code [1] and it fix the FTBFS > > Thanks , > > [1] > https://src.fedoraproject.org/fork/sergiomb/rpms/gdcm/blob/master/f/gdcm-2.8.8-fix-narrow.patch Please note that this patch changes the mangled names of template instantiations and thus breaks ABI. I'm not sure if this appropriate for a Fedora downstream-only patch, but maybe it's okay based on what the package does. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages that will be retired
On Mon, 2019-02-25 at 21:49 +0100, Miro Hrončok wrote: > Note: If you received this mail directly you (co)maintain one of the affected > packages or a package that depends on one. Please adopt the affected package > or > retire your depending package to avoid broken dependencies, otherwise your > package will be retired when the affected package gets retired. [...] > python-rdflib dcallagh, dmalcolm, dscott, 1 weeks ago >orphan, pingou [...] > nphilipp: python-rdflib I'll take over this one, as it's a dependency of lv2, which I maintain. https://pagure.io/releng/issue/8169 Nils -- Nils Philippsen"Those who would give up Essential Liberty to Software Engineer purchase a little Temporary Safety, deserve neither Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint:C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: APT,Synaptic ... ORPHANED
On 2/26/19 9:37 AM, Mosaab Alzoubi wrote: Due to like-dead upstream and security issue, I orphan these packages: apt synaptic fedora-package-config-apt Thank you! - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: APT,Synaptic ... ORPHANED
On Tue, Feb 26, 2019 at 2:37 AM Mosaab Alzoubi wrote: > > Due to like-dead upstream and security issue, I orphan these packages: > > apt I'll take this. Then it can be updated to latest apt-dpkg instead and used for other things. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Retire kchildlock package
Hi all. I am plan to retire package kchildlock from Fedora. It is KDE4 application long time unsupported and FTBFS on rawhide and F30. If no one need it I will retire package in one week. https://src.fedoraproject.org/rpms/kchildlock https://store.kde.org/p/1127875/ https://sourceforge.net/projects/kchildlock/ -- Best regards, Vasiliy Glazov ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaning procedure for qblade
Hi all. I abandoned qblade packaging because upstream is unresponsive (as always). Currently, qblade does not compile with gcc9. Upstream project: https://sourceforge.net/projects/qblade/ -- --- Antonio Trande Fedora Project mailto 'sagitter at fedoraproject dot org' GPG key: 0x6e0331dd1699e4d7 GPG key server: https://keys.fedoraproject.org/ signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages that will be retired (and everything will most likely burn)
Dne 20. 02. 19 v 10:02 Till Maas napsal(a): > On Fri, Feb 15, 2019 at 04:28:17PM +0100, Vít Ondruch wrote: >> Dne 15. 02. 19 v 14:22 Emmanuel Seyman napsal(a): >>> * Hans de Goede [15/02/2019 12:09] : And automatic scripts really just should hand it over to the first co-maintainer in the list. >> >> As long as we have no idea if the other maintainers are active, I am >> strongly against the automation. I've been there. Followed nor >> responsive policy just to find out later that instead of orphaning the >> package, next inactive maintainer became owner. Very frustrating > The advantage is that this will clean up the co-maintainer list > eventually. Orphaned package is eventually retired and co-mainatainer list is irrelevant then. I can't see your point. Vít > > Kind regards > Till > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
