Re: glibc-arm-linux-gnu help
On Mon, 10 Jun 2019 at 16:46, Tom Callaway wrote: > > Reviving this. I do not have the time nor the energy to attempt to keep this > going, so I am going to disable the shared bits in cross-gcc and kill off > glibc-arm-linux-gnu. It's been broken for a while, so I doubt anyone will be > seriously impacted by this. Ah that's unfortunate. I've been working on something that could possibly make use of this, but I haven't quite reached the stage of testing this out with it, and since it wasn't in Rawhide, I hadn't taken much look into it. I see that Debian has pretty much every cross version of libc6: https://packages.debian.org/search?keywords=libc6&searchon=names&suite=all§ion=all What makes it so easy for them? / What makes it difficult for us? How can we make cross toolchains easier? > If you are, I suggest using this copr instead: > https://copr.fedorainfracloud.org/coprs/lantw44/arm-linux-gnueabi-toolchain/ > > ~tom > > On Wed, Nov 7, 2018 at 11:02 AM Tom Callaway wrote: >> >> >> >> On 11/7/18 11:00 AM, Tom Callaway wrote: >> > A few years ago, I packaged up glibc-arm-linux-gnu, so that Fedora could >> > have a packaged arm cross-toolchain that was useful (with glibc, it >> > cannot build anything in userspace) >> >> This should have read "without glibc, it cannot build anything in >> userspace". >> >> ~tom > > ___ > 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 -- Elliott ___ 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: New Go Packaging Guidelines landed in rawhide (koji) today
- Original Message - > From: "Nicolas Mailhot via devel" > To: gol...@lists.fedoraproject.org > Cc: devel@lists.fedoraproject.org, annou...@lists.fedoraproject.org, "Nicolas > Mailhot" > Sent: Saturday, June 8, 2019 3:45:20 PM > Subject: New Go Packaging Guidelines landed in rawhide (koji) today > > Hi, > > Fedora’s new Go packaging macros landed in rawhide (koji) today. > I thought that we have agreed on Go SIG meeting with eclipseo to do this in side tag along with golang rebase(to avoid 2 rebuilds), so there is no observable breakage(if any would occur) for package builds and all packages "just" pop in using new macros and following new guidelines. Currently following packages are FTBFS due to this change https://apps.fedoraproject.org/koschei/affected-by/go-srpm-macros?epoch1=0&version1=2&release1=19.fc30&epoch2=0&version2=3.0.8&release2=3.fc31&collection=f31 (thanks to qulogic for this query). And still we will have to do the side tag rebuild(for this change). We could have done that in one pass without causing any observable breakage for anyone. > The corresponding Fedora Go packaging conventions are therefore > EFFECTIVE for new rawhide builds. For the first time in Fedora’s > history, we will be able to perform Go package builds conforming to an > approved Fedora Packaging Guideline. > > Packaging documentation: > https://eclipseo.fedorapeople.org/guidelines/packaging-guidelines/Golang/ > and approval: https://pagure.io/packaging-committee/issue/382 > The go-rpm-templates package provides more complete info. > > F31 change page: > https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines > and approval: https://pagure.io/fesco/issue/2120 It seems that this change has been accepted as Self Contained Change but IMHO it is System Wide Change as it seems to affect (nearly) all Go based packages in distribution(and will require work/attention of people that are not change owners, actually not accounted for in change proposal). For past several releases I have been doing rebase of Go compiler change(yet to be filed for F31) that is IMHO comparable(maybe a bit smaller) in scope and they were always deemed by FESCO as System Wide Changes. This really leaves me confused. Could someone from FESCO clarify? > > While the guidelines will feel familiar to anyone who created a Fedora > Go packages in the last two years, they DO include a backwards- > incompatible change. Making GOPATH manipulation robust required moving > the corresponding logic to %prep with a new %goprep macro. > > Therefore, existing specs are expected to fail without the addition of > the %goprep call. When this has been discussed, new macros have been presented to me as backwards compatible(i.e. current packages will work and build as is, although requiring refresh to adopt new features), so it has not been concern for me. Other issue that I have is that you have not communicated this change(landing the new macro package) prior it happening here or elsewhere. I'm a Go SIG member(and maintainer of the previous macros packages, which by the way are still out there) and I have not been aware of this pending change landing now. > > This is of course not the end of the road, just a key step. I would much appreciate if you would communicate a bit more before landing such a big changes(go-rpm-package) in future, it would made possible to avoid some breakages, collect feedback and improve overall packagers experience. I think that communication is not easy, at least not for me, and I don't think that it is my strong skill, but we shouldn't resign on it as it is IMO crucial part of the Fedora community. Is there something that can I do to improve the information flow from my side? JC > > It opens the way to a mass cleanup and refresh of the Fedora Go stack. > https://pagure.io/packaging-committee/issue/901 > > A preview of this refresh is available here: > https://copr.fedorainfracloud.org/coprs/eclipseo/golang-ng/builds/ > > Enormous thanks to > – Robert-André Mauchin (eclipseo) for the gigantic work done reviewing > updating and cleaning-up all those packages, and to > – Elliott Sales de Andrade (Qulogic), that picked up maintenance of > golist and fixed many of its long-standing bugs and limitations. > > Many thanks to the mock, rpm and redhat-rpm-config maintainers, > that integrated the changes, we built upon (Igor Gnatenko, Florian > Festi, Miroslav Suchý, Panu Matilainen) > > The macro set supports Go DynamicBuildRequires > https://fedoraproject.org/wiki/Changes/DynamicBuildRequires > > They will be usable in mock as soon as rpm 4.15 lands > https://fedoraproject.org/wiki/Changes/RPM-4.15 > > Use in koji or copr will have to wait for the corresponding refresh > buldsystem-side. So this part of the change is a technology preview for > now. > > Best regards, > > -- > Nicolas Mailhot > ___ > devel mailing list -- devel@l
Re: Heads-up: rpm 4.15 alpha coming to rawhide
On 6/11/19 6:33 PM, Petr Pisar wrote:
> On 2019-06-10, Panu Matilainen wrote:
>> As per https://fedoraproject.org/wiki/Changes/RPM-4.15, rpm 4.15-alpha
>> will be hitting rawhide soon. A soname bump is involved but Igor kindly
>> promised to handle rebuilding all dependent packages as part of the
>> change, so no further action required from others on that account.
>>
>> There are some other things that will require actions from others however:
>>
>> A pile of language-specific macros and scripts have been eliminated from
>> rpm upstream, notably %__python and %__perl and everything built around
>> them, such as %python_sitelib and %perl_sitelib and their relatives.
>> Python packages should be using the version specific macros already,
>> provided by respective pythonN-devel packages so this shouldn't be an
>> issue. On perl-side, those macros have been temporarily added to
>> redhat-rpm-config instead to avoid breaking things right now, later to
>> be moved to final destination in perl-macros or such.
>>
> Thanks for the heads up. Perl maintainers are deliberating an optimal
> resolution now. We will come up with a proposal in a few days.
%{__perl} will be moved to perl-srpm-macros. Some packages use it in
list of
BuildRequires and so it has to be defined in buildroot when source rpm
is built.
%perl_sitearch and %perl_sitelib will be removed, because they are not used
in any spec file.
%perl_vendorlib, %perl_vendorarch, %perl_archlib and %perl_privlib will be
placed in perl-macros. To prevent the build failures, perl-macros will be
added as build-require to packages, which use the macros and doesn't
build-require perl-generators (it run-requires perl-macros).
%requires_eq isn't perl macro and it stays in redhat-rpm-config. The macro
is used only in samba.spec.
Regards,
Jitka
--
Jitka Plesnikova
Software Engineer
Red Hat
___
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: Do people not care about broken dependencies?
On Wed, Jun 12, 2019 at 3:21 AM Neal Gompa wrote: > > On Tue, Jun 11, 2019 at 11:08 PM Nico Kadel-Garcia wrote: > > > > On Mon, Jun 10, 2019 at 8:31 AM Dan Horák wrote: > > > > > > On Mon, 10 Jun 2019 11:35:52 +0200 > > > Igor Gnatenko wrote: > > > > > > > On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch > > > > wrote: > > > > > > > > > > There used to be sent nagging email about broken dependencies, but > > > > > it is not sent anymore. I last received such email on 11th of March > > > > > 2018, so probably we don't really care ... > > > > > > > > The problem with that check is that it just checks if all dependencies > > > > are provided by other packages, but it doesn't check if they can be > > > > installed at the same time. So if I would have package with Requires: > > > > foo + Conflicts: foo, that check won't tell anything. > > > > > > > > Same applies to rich dependencies "with", it just checks if one > > > > condition is provided by anything so this check is not useful for > > > > packages with rich dependencies at all… > > > > > > IIRC the original problem was that repoclosure used yum underneath which > > > didn't understand rich/weak deps at all. Do we still wait on a tool > > > using dnf/libsolv to provide equivalent functionality as repoclosure? > > > > "Weak" dependencies make the problem insuluble. > > No, they don't. Weak dependencies are not hard to deal with. > There are two ways to treat them in repoclosure: treat them as > Requires or ignore them. Right now, we ignore them, but we could > easily modify our repoclosure to treat them as Requires. This is not a complete test. To be complete, it includes the combinatorial complexity of all the different components, installed one by one, in deifferent sequiences, with weak dependencies turned on and off for each different component, each version of the component, and all the different components that may be obsoleted, added, or conflicted with the *next* update. It makes the overall problem intractable, if not insoluble. ___ 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: New Go Packaging Guidelines landed in rawhide (koji) today
Le 2019-06-12 10:39, Jakub Cajka a écrit : Fedora’s new Go packaging macros landed in rawhide (koji) today. I thought that we have agreed on Go SIG meeting with eclipseo to do this in side tag along with golang rebase(to avoid 2 rebuilds), https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines#Summary “ This proposal consists of: Packaging the new Go macros: go-rpm-macros Getting the Guidelines approved by the FPC Updating all Go libraries with the new macros Mass-rebuilding all the Go package in a side tag ” You complain that step 3 and 4 are separate, but that’s how it was planed from the start up and approved in the change page. You're conflating merging two mass Go package rebuilds (one for the new Go compiler, and another for the new, and first, Go packaging guidelines) with merging step 3 and 4 (which would have had other drawbacks, that were never discussed, because that's not how we planed things). And BTW it was already so in https://pagure.io/GoSIG/go-sig/issue/20 6 months ago (though this page is obsolete, you made us rewrite the plan in so many formats over time I've lost track or what is up to date or not. The change page is up to date, it’s the most recent rewrite) Sincerely, -- Nicolas Mailhot ___ 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: Heads-up: rpm 4.15 alpha coming to rawhide
On 6/12/19 12:12 PM, Jitka Plesnikova wrote:
On 6/11/19 6:33 PM, Petr Pisar wrote:
On 2019-06-10, Panu Matilainen wrote:
As per https://fedoraproject.org/wiki/Changes/RPM-4.15, rpm 4.15-alpha
will be hitting rawhide soon. A soname bump is involved but Igor kindly
promised to handle rebuilding all dependent packages as part of the
change, so no further action required from others on that account.
There are some other things that will require actions from others however:
A pile of language-specific macros and scripts have been eliminated from
rpm upstream, notably %__python and %__perl and everything built around
them, such as %python_sitelib and %perl_sitelib and their relatives.
Python packages should be using the version specific macros already,
provided by respective pythonN-devel packages so this shouldn't be an
issue. On perl-side, those macros have been temporarily added to
redhat-rpm-config instead to avoid breaking things right now, later to
be moved to final destination in perl-macros or such.
Thanks for the heads up. Perl maintainers are deliberating an optimal
resolution now. We will come up with a proposal in a few days.
%{__perl} will be moved to perl-srpm-macros. Some packages use it in
list of
BuildRequires and so it has to be defined in buildroot when source rpm
is built.
%perl_sitearch and %perl_sitelib will be removed, because they are not used
in any spec file.
%perl_vendorlib, %perl_vendorarch, %perl_archlib and %perl_privlib will be
placed in perl-macros. To prevent the build failures, perl-macros will be
added as build-require to packages, which use the macros and doesn't
build-require perl-generators (it run-requires perl-macros).
Ok, sounds more or less the way I expected it to be.
%requires_eq isn't perl macro and it stays in redhat-rpm-config. The macro
is used only in samba.spec.
%requires_eq was considered somehow perl-related in upstream (due to
whatever long forgotten history) but okay, even better if its not used
in perl either. That way we can bury it into samba.spec and remove
elsewhere, because it violates the "dont run rpm queries from spec"
principle and we dont want to encourage such use by providing example.
Thanks for the swift analysis.
- 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: Do people not care about broken dependencies?
On Wed, Jun 12, 2019 at 6:03 AM Nico Kadel-Garcia wrote: > > On Wed, Jun 12, 2019 at 3:21 AM Neal Gompa wrote: > > > > On Tue, Jun 11, 2019 at 11:08 PM Nico Kadel-Garcia wrote: > > > > > > On Mon, Jun 10, 2019 at 8:31 AM Dan Horák wrote: > > > > > > > > On Mon, 10 Jun 2019 11:35:52 +0200 > > > > Igor Gnatenko wrote: > > > > > > > > > On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch > > > > > wrote: > > > > > > > > > > > > There used to be sent nagging email about broken dependencies, but > > > > > > it is not sent anymore. I last received such email on 11th of March > > > > > > 2018, so probably we don't really care ... > > > > > > > > > > The problem with that check is that it just checks if all dependencies > > > > > are provided by other packages, but it doesn't check if they can be > > > > > installed at the same time. So if I would have package with Requires: > > > > > foo + Conflicts: foo, that check won't tell anything. > > > > > > > > > > Same applies to rich dependencies "with", it just checks if one > > > > > condition is provided by anything so this check is not useful for > > > > > packages with rich dependencies at all… > > > > > > > > IIRC the original problem was that repoclosure used yum underneath which > > > > didn't understand rich/weak deps at all. Do we still wait on a tool > > > > using dnf/libsolv to provide equivalent functionality as repoclosure? > > > > > > "Weak" dependencies make the problem insuluble. > > > > No, they don't. Weak dependencies are not hard to deal with. > > > There are two ways to treat them in repoclosure: treat them as > > Requires or ignore them. Right now, we ignore them, but we could > > easily modify our repoclosure to treat them as Requires. > > This is not a complete test. To be complete, it includes the > combinatorial complexity of all the different components, installed > one by one, in deifferent sequiences, with weak dependencies turned on > and off for each different component, each version of the component, > and all the different components that may be obsoleted, added, or > conflicted with the *next* update. It makes the overall problem > intractable, if not insoluble. No. It's the same level of complexity for repoclosure and installcheck for even just strong dependencies. You can make the assumption that if you flip the weak attribute strong for repoclosure and installcheck purposes that you've caught all the necessary cases for dealing with dependency shifts like obsoletes. This is a problem I've stared deep in the face for literally years at this point. While you're technically correct that there's tons of variation for usage, there is not for specifically dependency checking. Rich dependencies with boolean clauses are the ones that make things complex, not weak dependencies. That's when you need to start "testing" dependency statements. -- 真実はいつも一つ！/ 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
Re: Heads-up: rpm 4.15 alpha coming to rawhide
Dne 10. 06. 19 v 13:39 Panu Matilainen napsal(a): > More info and details available in the preliminary release notes at > https://rpm.org/wiki/Releases/4.15.0 and the change > page linked at the start of this message. Where can I read more about this: > Add support for rootless chroot-operations on Linux (experimental) ? -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ 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: glibc-arm-linux-gnu help
Le mer. 12 juin 2019 à 10:50, Elliott Sales de Andrade a écrit : > > On Mon, 10 Jun 2019 at 16:46, Tom Callaway wrote: > > > > Reviving this. I do not have the time nor the energy to attempt to keep > > this going, so I am going to disable the shared bits in cross-gcc and kill > > off glibc-arm-linux-gnu. It's been broken for a while, so I doubt anyone > > will be seriously impacted by this. > > Ah that's unfortunate. I've been working on something that could > possibly make use of this, but I haven't quite reached the stage of > testing this out with it, and since it wasn't in Rawhide, I hadn't > taken much look into it. > > I see that Debian has pretty much every cross version of libc6: > https://packages.debian.org/search?keywords=libc6&searchon=names&suite=all§ion=all > > What makes it so easy for them? / What makes it difficult for us? How > can we make cross toolchains easier? Probably time/human ressources. I would be interested in having a working cross compilation toolchain also (specially for case where 32bit linking is an issue like chromium or else). I have tried to work on some patches (including kernel-headers), but not had time to fully qualify the changes. FYI, I've tried to contact the maintainer of the copr repo pointed by Tom, so far no answer. Looking at some of his copr contributions, he haven't found the right step to contribute to fedora main repository yet (also others topics). This is unfortunate and I fear this situation is going to increase with users kept in their copr projects... -- - Nicolas (kwizart) ___ 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: glibc-arm-linux-gnu help
* Elliott Sales de Andrade: > On Mon, 10 Jun 2019 at 16:46, Tom Callaway wrote: >> >> Reviving this. I do not have the time nor the energy to attempt to keep this >> going, so I am going to disable the shared bits in cross-gcc and kill off >> glibc-arm-linux-gnu. It's been broken for a while, so I doubt anyone will be >> seriously impacted by this. > > Ah that's unfortunate. I've been working on something that could > possibly make use of this, but I haven't quite reached the stage of > testing this out with it, and since it wasn't in Rawhide, I hadn't > taken much look into it. > > I see that Debian has pretty much every cross version of libc6: > https://packages.debian.org/search?keywords=libc6&searchon=names&suite=all§ion=all > > What makes it so easy for them? / What makes it difficult for us? How > can we make cross toolchains easier? They just did the work, like Fedora did for Windows. The benefits that GNU/Linux cross-toolchains provide to Debian is greater than it would be on Fedora because most of Debian's development packages install header files and libraries into directories with multi-arch tuples, and dpkg supports installation of such packages from foreign architectures, using their package repositories. This means that the Debian cross-toolchain can use all these development packages, and Debian developers are not stuck with glibc/libstdc++ only for cross-builds. 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
Fedora Distgits
There's a nifty site here: https://redhat-oss-git-stats.softwarefactory-project.io/project.html?pid=Fedora%20Distgits That collects statistics on git contributions to Fedora (as well as other projects), including numbers of commits by individuals. However, it's based on email address, and many people have used multiple addresses. You can claim your contributions and aggregate multiple email addresses by doing the following: - create or update your Github account to have all of your email addresses associated with it. - Click on "Claim your contributions/Login" at the top of the Distgits page, which will connect to your github account and link your emails together. From a quick scan of the stats, the following people likely have multiple addresses: Adam Jackson Akira TAGOH Bastien Nocera Bill Nottingham Dennis Gilmore Fabian Affolter gil Hans de Goede Igor Gnatenko Jason Tibbitts Jens Petersen Jerry James Jochen Schmitt Josh Boyer kalev Karsten Hopp Kevin Fenzi Kevin Kofler Lubomir Rintel Mamoru Tasaka Mamoru TASAKA Marcela Mašláňová Martin Stransky Matthias Clasen Mattias Ellert Nicolas Chauvet Nils Philippsen Paul Howarth Peter Jones Peter Robinson Remi Collet Rex Dieter Richard W.M. Jones Shawn Iwinski Than Ngo Tim Waugh Ville Skyttä -- 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/ smime.p7s Description: S/MIME Cryptographic 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: New Go Packaging Guidelines landed in rawhide (koji) today
On Wed, Jun 12, 2019 at 04:39:07AM -0400, Jakub Cajka wrote: > > F31 change page: > > https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines > > and approval: https://pagure.io/fesco/issue/2120 > > It seems that this change has been accepted as Self Contained Change > but IMHO it is System Wide Change as it seems to affect (nearly) all > Go based packages in distribution(and will require work/attention of > people that are not change owners, actually not accounted for in > change proposal). For past several releases I have been doing rebase > of Go compiler change(yet to be filed for F31) that is IMHO > comparable(maybe a bit smaller) in scope and they were always deemed > by FESCO as System Wide Changes. This really leaves me > confused. Could someone from FESCO clarify? https://fedoraproject.org/wiki/Changes/Policy#Self_contained_changes says > Examples include [...] a coordinated effort within a SIG with > limited impact outside the SIG's functional area So in this case, even though the change affects so many packages, it falls into the "self contained change" category. That said, the difference between "system-wide" and "self-contained" boils down to two things: some additional data required in the change page, and filing the change a bit earlier. In this case the additional data is mostly there in the change page, and the change was filed early, so even if we were to change the Change to "system-wide", the effect would be cosmetic. Zbyszek ___ 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: Review swaps
On Sunday, 9 June 2019 03:41:00 CEST Jerry James wrote: > It's time for another game of "my package just grew some new > dependencies." I need reviews for the following and am willing to do > reviews in exchange: > > 1. catch2: a C++ header-only test framework for unit tests >https://bugzilla.redhat.com/show_bug.cgi?id=1718597 > > 2. cli11: a header-only command line parser for C++11 >https://bugzilla.redhat.com/show_bug.cgi?id=1718598 > > 3. drat-trim: a proof checker for DIMACS proofs >https://bugzilla.redhat.com/show_bug.cgi?id=1718599 > > 4. drat2er: a proof transformer for propositional logic, depends on 1-3 >https://bugzilla.redhat.com/show_bug.cgi?id=1718600 > > 5. flamegraph: a stack trace visualizer and a set of stack collapsing > scripts >https://bugzilla.redhat.com/show_bug.cgi?id=1718601 > > 6. gap-pkg-singular: a GAP interface to Singular >https://bugzilla.redhat.com/show_bug.cgi?id=1718602 > > Thank you! Still okay for swapping? I'm looking for a review for: https://bugzilla.redhat.com/show_bug.cgi?id=1719798 It's Intel SVT-AV1 encoder, x86_64 only. It is a dev snapshot as the latest release does not have the decoder enabled. Thanks! Robert-André ___ 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: Fedora Distgits
On Wed, Jun 12, 2019 at 8:47 AM Orion Poplawski wrote: > - create or update your Github account to have all of your email > addresses associated with it. [snip] > From a quick scan of the stats, the following people likely have > multiple addresses: [snip] > Jerry James There are 4 entries for me. I consolidated my gmail.com address and my fedoraproject.org addresses. One of the other two is an email address that no longer exists. The fourth entry says that there are no commits associated with it, and I am unable to tell which email address it is associated with. I tried adding the email address that no longer exists to my github account anyway, just to let this service read it. Github announced that it was sending a verification email (which would bounce), but showed it. I clicked on the "Claim your contributions/Login" link as instructed, authorized reading my github email addresses, and got only the gmail.com and fedoraproject.org addresses. It appears that whatever method is being used to read the email addresses does not read unverified addresses. Due to not being able to tell what one email address is and the service not reading unverified github email addresses, I am able to consolidate only 2 of the 4 entries bearing my name. Regards, -- Jerry James http://www.jamezone.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: Heads-up: rpm 4.15 alpha coming to rawhide
On Wed, 2019-06-12 at 12:40 +0300, Panu Matilainen wrote:
> On 6/12/19 12:12 PM, Jitka Plesnikova wrote:
> > On 6/11/19 6:33 PM, Petr Pisar wrote:
> > > On 2019-06-10, Panu Matilainen wrote:
> > > > As per https://fedoraproject.org/wiki/Changes/RPM-4.15, rpm 4.15-alpha
> > > > will be hitting rawhide soon. A soname bump is involved but Igor kindly
> > > > promised to handle rebuilding all dependent packages as part of the
> > > > change, so no further action required from others on that account.
> > > >
> > > > There are some other things that will require actions from others
> > > > however:
> > > >
> > > > A pile of language-specific macros and scripts have been eliminated from
> > > > rpm upstream, notably %__python and %__perl and everything built around
> > > > them, such as %python_sitelib and %perl_sitelib and their relatives.
> > > > Python packages should be using the version specific macros already,
> > > > provided by respective pythonN-devel packages so this shouldn't be an
> > > > issue. On perl-side, those macros have been temporarily added to
> > > > redhat-rpm-config instead to avoid breaking things right now, later to
> > > > be moved to final destination in perl-macros or such.
> > > >
> > > Thanks for the heads up. Perl maintainers are deliberating an optimal
> > > resolution now. We will come up with a proposal in a few days.
> > %{__perl} will be moved to perl-srpm-macros. Some packages use it in
> > list of
> > BuildRequires and so it has to be defined in buildroot when source rpm
> > is built.
> > %perl_sitearch and %perl_sitelib will be removed, because they are not used
> > in any spec file.
> > %perl_vendorlib, %perl_vendorarch, %perl_archlib and %perl_privlib will be
> > placed in perl-macros. To prevent the build failures, perl-macros will be
> > added as build-require to packages, which use the macros and doesn't
> > build-require perl-generators (it run-requires perl-macros).
>
> Ok, sounds more or less the way I expected it to be.
>
> > %requires_eq isn't perl macro and it stays in redhat-rpm-config. The macro
> > is used only in samba.spec.
>
> %requires_eq was considered somehow perl-related in upstream (due to
> whatever long forgotten history)
AIUI, it is/was commonly used by perl module packages to require the
same version of perl as the module package was built with, because this
is/was a thing in perl - when perl's version got bumped, all modules
needed rebuilding too. That's probably where the 'perl-related' thing
comes in - it's not that the actual thing %requires_eq does is in any
way perl-specific, but it's a thing that was introduced in response to
this particular property of perl and its modules, and IIRC not often or
ever used by anything else.
However in Fedora, we don't use %requires_eq for perl modules, at least
not any more (perhaps we did in the past, I don't know). Instead we
have the perl(:MODULE_COMPAT_[version]) dependency that is handled by
our own perl macros (provided by the interpreter package and
automatically required by module packages). I *have* run across the use
of %requires_eq in SUSE packages, though.
--
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
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: Node.js 12.x Plans for F31+
On Tue, May 28, 2019 at 9:30 AM Stephen Gallagher wrote: > > On Mon, May 27, 2019 at 6:59 AM Vít Ondruch wrote: > > > > > > Dne 24. 05. 19 v 21:00 Stephen Gallagher napsal(a): > > > On Tue, Apr 23, 2019 at 5:40 PM Stephen Gallagher > > > wrote: > > >> Today, the Node.js upstream released 12.0.0, the next in its line of > > >> long-term support releases. I plan to make this the default version of > > >> Node.js in Fedora 31+, but not immediately. I'm currently working on > > >> getting a modular version of 12.x built for F29, F30 and Rawhide. I'll > > >> get that out to updates-testing this week. I'll send out an update > > >> once it's pushed to updates-testing. > > >> > > >> Once that's available, I encourage all NPM packagers in Fedora to > > >> start testing their build and runtime with the 12.x module. I will be > > >> filing a Change Proposal and plan to switch the system interpreter for > > >> Rawhide over to 12.x around the end of May or beginning of June. > > >> > > >> The exact timing may depend on the current status of the > > >> modules-in-the-non-modular-buildroot work in Fedora. If that's > > >> available by this time, I will retire the non-modular Node.js > > >> interpreter package and make the 12.x module the default stream for > > >> F31+. If it's not available, I'll continue to do what I've been doing > > >> in F29 and F30; building both the modular and non-modular packages. > > >> > > >> If you discover that you own NPM packages that are critical and do not > > >> work with Node.js 12.x, please inform me immediately. We'll talk with > > >> upstream and see what we can do about it. > > > I plan to make this switch on Friday, May 31st, so if you have > > > packages that may break, now would be a good time to let me know. > > > > > > Since the buildroot work isn't yet completely ready, I'm going to take > > > the stop-gap approach and merge the '12' branch to master and do a > > > non-modular build of Node.js 12.x in Rawhide on that day. > > > > > > I might be missing something, but you promised "I will be filing a > > Change Proposal" in your original email above. Was it filled? Was it > > approved? > > You are correct; I forgot to file the Change I promised. *sigh* > > Filing it now and I will move out the cut-over date to June 14th to > give enough time for it to be approved. Just a reminder, I will cut Rawhide over to Node.js 12.x on Friday, June 14th. That's two days from now. ___ 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: Review swaps
On Wed, Jun 12, 2019 at 9:55 AM Robert-André Mauchin wrote: > Still okay for swapping? I'm looking for a review for: > https://bugzilla.redhat.com/show_bug.cgi?id=1719798 > > It's Intel SVT-AV1 encoder, x86_64 only. It is a dev snapshot as the latest > release does not have the decoder enabled. I'm on it. -- Jerry James http://www.jamezone.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
Fedora updates-20190613.0 compose check report
Missing expected images: Atomichost raw-xz x86_64 Atomichost qcow2 x86_64 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 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
Fedora testing-20190613.0 compose check report
Missing expected images: Atomichost raw-xz x86_64 Atomichost qcow2 x86_64 Failed openQA tests: 1/2 (x86_64) ID: 411401 Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/411401 Passed openQA tests: 1/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 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
Intent to retire drabt
The drabt package was only ever needed for the cvc4 %check script. The latest release of cvc4, which I am about to build, no longer uses drabt. Nothing else in Fedora needs it, so I intend to retire it next week. If you want it, let me know. -- Jerry James http://www.jamezone.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
