Re: HEADS UP: DynamicBuildRequires are available

> "MC" == Michael Cronenworth writes: MC> Yes, something would have to be invented, and I guess that's why no MC> one replied. Well I replied, bit I'm behind on email so... MC> However, the data exists it is just not available in a standard, MC> parsable format. And that was really my

Re: miniz: a soname bump and a license change

> "PP" == Petr Pisar writes: PP> I'm going to rebase miniz in Rawhide from 1.15_r4 to PP> 2.1.0. Thanks for doing this; it allows me to unbundle miniz from prusa-slicer, at least in rawhide. - J< ___ devel mailing list --

Re: How to install a mountpoint directory from an rpm?

> "DH" == David Howells writes: DH> I'm not entirely clear how I should go about requesting FPC DH> approval. It says it is preferable that a ticket be filed in the DH> packaging committee pagure - do they mean to raise an issue, do you DH> know? Just file a ticket:

Re: Package with open and closed dual license

> "AT" == Andrew Toskin writes: AT> I'm looking specifically into VeraCrypt, the open-source fork from AT> TrueCrypt. Has the situation which has kept VeraCrypt out of Fedora previously been changed? See this, for example:

Re: Fedora 31 Self-Contained Change proposal: Ship BerkleyDB backend as a module

> "SG" == Stephen Gallagher writes: SG> Do any tools exist to simplify the conversion to MDB? Can this be SG> automated? I'd like to know this as well. It's always better to provide tools or extremely clear and detailed instructions, because it's not safe to assume that people know how to

Re: RFC: Drop lz4-static

> "DS" == David Sommerseth writes: DS> As I can see it, there is little benefit of removing lz4-static. Isn't that entirely the decision of those maintaining the package? It's still completely reasonable if they want to remove it for no other reason than it eliminates ten lines from the

Re: Let's revisit the FTBFS policy

> "GH" == Gerald Henriksen writes: GH> On the other hand, unbuildable packages could be viewed as a GH> security risk. I mentioned security explicitly in my message. Just not in the portion you quoted. GH> If you can't just fix the security issue and rebuild, but instead GH> have to also

Re: Let's revisit the FTBFS policy

> "MH" == Miro Hrončok writes: MH> If we stop here, the current "setting to ASSIGNED to stop this" MH> remains a problem. Let's think about why this is perceived as a problem. The maintainer has performed an affirmative act that shows they noticed. Can't we just accept that as some

Re: Let's revisit the FTBFS policy

> "FW" == Florian Weimer writes: FW> Debian treats FTBFS bugs as release-critical. They either have to FW> be fixed, or the package gets removed from the release. However, FW> this is not an automated process. Of course, Debian works on a slightly different release schedule, so it's not

Re: What does this koji error mean?

> "C" == Christopher writes: C> BuildError: package thrift is C> blocked for tag f32-updates-candidate C> (https://koji.fedoraproject.org/koji/taskinfo?taskID=37187038) It means that thrift has been blocked in koji. The usual reason for this is that the package has been retired, and the

Re: [Test-Announce] Fedora 31 Beta Freeze

> "CM" == Chris Murphy writes: CM> But anyway, I did laugh a bit out loud at 23:45 UTC because *of CM> course* there are many other totally unambiguous times to choose CM> from instead. Some of the best comedy is pointing out the obvious. If we're going to bikeshed it, I'll vote for two

Re: Fedora 31 Self-Contained Change proposal: Limit Scriptlet Usage of core packages

> "PM" == Panu Matilainen writes: PM> So a big +1 for sysusers in sub-packages + file trigger to handle PM> running systemd-sysusers. It solves more problems than the current PM> sysusers-proposal and in a far more elegant way at that. It's great that you agree. That leaves all of the

Re: Rolling out Phase I of rawhide package gating

> "KF" == Kevin Fenzi writes: KF> * If you use metalinks, rpm signatures are just gravy on top, in the KF> end you are still just trusing SSL CA's. Only if you trust every mirror to always serve authentic content. - J< ___ devel mailing list --

Re: Rolling out Phase I of rawhide package gating

> "FW" == Florian Weimer writes: FW> At one point, there was a verified hash chain from the https:// FW> metalink service, to the repository metadata, down to individual FW> packages. Any tampering was detected then. I understand that the metalink contains enough information to verify the

Re: Rolling out Phase I of rawhide package gating

> "NG" == Neal Gompa writes: NG> You just set localpkg_gpgcheck=1 in /etc/dnf/dnf.conf NG> That said, you probably don't want to do that, since most downloaded NG> packages aren't signed... I think that the ideal behavior would be to always check, but warn/prompt for unsigned packages or

Re: s390x rawhide issues?

> "TC" == Tom Callaway writes: TC> One of my packages (alienarena) fails to build in rawhide on s390x TC> (and only that arch), but the build log shows it never even TC> starts. Does it fail repeatably? This error is known but as far as I know it's always been transient. It only seems to

Re: dnf & rpm-devel both seem to be uninstallable in the Rawhide buildroot

t; https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List MH> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines MH> List Archives: MH> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Jason L Tibbitts III - j...@tib.bs - 71

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

> "BC" == Ben Cotton writes: BC> * Other developers: Other developers may have to adjust test suites BC> which expect exact floating point results, and correct linking with BC> libatomic. They will also have to upgrade their x86-64 BC> machines to something that can execute AVX2

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

> "JLT" == Jason L Tibbitts writes: JLT> And, let's see, I'd have to toss out five desktops (which isn't too JLT> bad, I guess) I was wrong. It would be 36 desktops. Being charitable requires me to assume this was proposed without adequate consideration of just how much hardware is

Re: Discussion around app retirements and categorizations by the CPE team

> "FW" == Florian Weimer writes: FW> I strongly doubt this will be true indefinitely. I expect things FW> will change pretty quickly once partners can access and file bugs in FW> the other bug tracker. This is interesting in light of the fact that one reason given for not enabling Pagure

Re: Vim and spec template

> "ZD" == Zdenek Dohnal writes: ZD> Hi all, I would like to ask as Vim co-maintainer, do you find useful ZD> for Vim to do: ZD> - when you open new file with .spec suffix, Vim will get you basic ZD> spec file structure? Personally I have always found that behavior annoying. If I open a

Re: Self Introduction: Dee'Kej (looking for sponsor)

Welcome back to Fedora. I've clicked the necessary sponsorship buttons. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct:

Re: Vim and spec template

> "ZD" == Zdenek Dohnal writes: ZD> Converted to spaces now. Well I appreciate that, but my point is that it's really personal preference. ZD> It is designed for user to run rpmdev-bumpspec ZD> .spec, so the tool will supply correct format of changelog ZD> entry and increment the release.

Re: are the ppc64le builders healthy?

> "KK" == Kaleb Keithley writes: KK> I built the latest ceph-14 (14.2.2) on rawhide successfully two days KK> ago. Two different builds on f30 built or are building fine on KK> x86_64, i686, and aarch64, but failed with different errors on KK> ppc64le at different places in the build. One

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

> "FW" == Florian Weimer writes: FW> ELF multilib DSOs inside RPMs result in code deduplication, FW> affecting container image size. I think it's important to quantify this kind of thing. I think we can all agree that there is very little benefit to duplicating every single library, so

Re: Fedora 31 Self-Contained Change proposal: Limit Scriptlet Usage of core packages

> "VO" == Vít Ondruch writes: VO> I just wonder what is the point of: VO> https://github.com/systemd/systemd/blob/b0ca726/src/core/macros.systemd.in#L122 I guess it just saves packagers from having to call systemd-sysusers properly. You include the configuration file in the source

Re: are the ppc64le builders healthy?

> "TS" == Tom Stellard writes: TS> Are these updated builders only used for f30? It appears that there are 29 PPC64le builders configured currently: https://koji.fedoraproject.org/koji/hosts?start=80=enabled=name They don't all have the same "capacity" rating. TS> Because I'm still

Re: [Fedora-packaging] Re: HEADS UP: Source File Verification

> "JO" == Joe Orton writes: JO> In the historic CVS-based build system which predated what we now JO> use, we could do GPG key verification at the time of downloading and JO> importing a new tarball. You're right; tmz dug up a copy of the old Makefile.common file:

Re: findbugs-contrib building on i686 builders despite ExcludeArch

> "RF" == Richard Fearn writes: RF> According to RF> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_architecture_build_failures: >> If a Fedora package does not successfully compile, build or work on >> an architecture, then those architectures should be listed in the >> spec

Re: Guidelines for scriptlets modifying %config(noreplace) files

> "JN" == Jamie Nguyen writes: JN> I couldn't find clear packaging policy on this. The guidelines [0] JN> talk about %config(noreplace) vs %config, but /etc/named.conf is JN> installed as a "noreplace" file. I don't think there's a guideline about this. %config and %config(noreplace) are

Re: Defining the future of the packager workflow in Fedora

> "C" == Christopher writes: C> With version-controlled package sources, changelogs in SPEC seem so C> obsolete to me. They are already problematic today when they conflict C> due to changes in multiple branches. It's important to note that the RPM changelog is rather a different thing

Re: Fedora 32 System-Wide Change proposal: Annobin Used By Bodhi

> "BC" == Ben Cotton writes: BC> Use the annocheck program from the annobin package to BC> produce an analysis of the security hardening of a compiled package BC> when reviewing a Bodhi update. While I don't disagree with running annocheck at some point in the build process, _only_ doing

Re: Old changelog entries removal

> "MM" == Matthew Miller writes: MM> Whether or not it's documented policy (and I can't remember or find MM> anything either), many packages have the practice of trimming very MM> old entries. You can't always do this. I tried to purge changelog entries from a package older than 2010 and

Re: Fedora 32 Self-Contained Change proposal: Free Pascal Compiler 3.2.0

> "AI" == Artur Iwicki writes: AI> I imagine the reason is that this allows us to add new AI> architectures to FPC and do some trial-and-error builds of FPC AI> without affecting dependent packages - if FPC itself used AI> %{fpc_arches}, then adding new architectures to FPC would require AI>

Re: F37 Change: RetireARMv7 (System-Wide Change proposal)

> Gary Buhrmaster writes: > I have occasionally conjectured that there should be a "last gasp" > version of some core package released into updates for a version going > unsupported that drops a file into /etc/motd.d that is, essentially: I've thought about it as well, but I still wonder

Re: RFC: Reduce number of packages that are built for i686

> Robbie Harwood writes: > Fabio Valentini writes: >> Since it's not practical to modify almost all Fedora packages to add >> "ExcludeArch: %{ix86}" to them, we'd probably need a different >> machanism for this. > Is it really not? This seems the easiest way to go about it, honestly > -

Re: Looking for %{forgemeta} GitHub example

> Brandon Nielsen writes: > I would like to see the forge macros removed from the guidelines if > development truly has ceased. I would like to get into them and at least see what needs to change but... the internal implementation is somewhat baroque and my time is severely limited. I

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

> Ben Cotton writes: > == Make UEFI a hardware requirement for new Fedora installations on > platforms that support it (x86_64). My problem here is that I have real, useful hardware which has always run Fedora that I would like to continue using. But it's just old enough (purchased in

Re: -Werror=implicit-int -Werror=implicit-function-declaration coming to rawhide

> Sandro writes: > That aside, having the document linked in the packaging guidelines is > a big step towards letting packagers know of its existence. I just wanted to point out that the packaging guidelines have pointed users to the document for quite some time (early 2019) in this

Re: Packaging web extension native part and shared directory ownership

> Robert Marcano via devel writes: > I seriously don't know how gnome-browser-connector [1] has ownership > of: > /usr/lib64/mozilla/native-messaging-hosts > and not have conflict problems with mozilla-filesystem at install > time, maybe because they usually get installed at the same

How much free space in /var is required for upgrades?

So I went to do a dnf system-upgrade from F35 to F36 on a test machine, as part of my usual testing. In the middle of the process, it appears that /var filled up and that left the system in an unfortunate state. Surprisingly (to me) it did boot with a random mix of F35 and F36 packages and even

Re: Karma for OpenSSL needed

> Ewoud Kohl van Wijngaarden writes: > Right now you can't test them since they haven't been migrated to > testing yet. You can download the packages directly from koji. From the relevant update page, you can clock the "Builds" tab which will give you a link. You can down exactly the

Re: Tenacity

> stan via devel writes: > As they say in the BUILDING.md file, > though, fedora lacks wxWidgets 3.1.5 or greater. That stops the > configuration, cmake -G Ninja -S . -B build when it errors out. That's odd; as far as I can see, F36 has 3.1.5 and F37 has 3.2.1. - J<

Re: Unannounced soname bump: libotf

> Gary Buhrmaster writes: > I have found that using something like libfoo.so.X{,.*} in the %files > directive can be a useful reminder (enforcer) to reduce such surprises > (that particular glob presumes semantic versioning, and that minor and > patch level updates do not require rebuilds,

Re: Proven to be sickened

So I've been in this situation, both on the receiving end of nasty flames because I dared touch someone else's package and having duplicated work because I didn't check before trying to update something. > Michael J Gruber writes: > So, due to me following my package (notmuch) The idea is

Re: Email Change Requested for kevin

Please ignore that message; it was generated in error when an administrator was attempting to fix up the perl-sig address to refer to the fedoraproject.org address for this list instead of the old redhat.com one. - J -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl

[Guielines Change] Changes to the packaging guidelines

%license must be used in place of %doc to designate any file containing the license information for a package. See https://fedoraproject.org/wiki/Packaging:Guidelines#Documentation and https://fedoraproject.org/wiki/Packaging:LicensingGuidelines Guidelines for DevAssistant packages (DAP) were

[Guidelines change] Changes to the packaging guidelines

Here are the recent changes to the packaging guidelines: The documentation section of the guidelines has been updated to include a prohibition on using both %doc and direct installation of files into %_pkgdocdir. * https://fedoraproject.org/wiki/Packaging:Guidelines#Documentation *

[Guidelines change] Changes to the packaging guidelines

Here are the recent changes to the packaging guidelines: The guidelines for packaging static libraries were amended to indicate that the -static package should require the -devel package: * https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries_2 *

Proposal to require python3-supporting modules to be packaged for python3

I've not posted here before, but I've been becoming more familiar with python and have been doing some work on the various guidelines in my capacity as an FPC member. I was kind of surprised that with the push for python 3 as default we don't actually have a guideline that modules supporting

Re: fedora wikipage Packaging:Python

MB == Martin Bukatovič martin.bukato...@gmail.com writes: MB The page doesn't discuss much any differences in guidelines for MB packages of python modules, python applications and when python MB project provides both. It shouldn't really need to; the question isn't specific to python at all.

[Guidelines change] Changes to the packaging guidelines

Here are the recent changes to the packaging guidelines: The policy for systemd presets has been modified to merge the individual treatments of service, socket and timer units into one policy. The policy page was also moved into the packaging guidelines proper. *

Re: Python guidelines cleanup

Also, When using the python_provide macro as detailed in the guidelines, I can't seem to get fedpkg to generate an srpm: fedpkg srpm error: line 36: Unknown tag: ERROR: not recognized. error: query of specfile /home/tibbs/work/fpkg/python-requests/python-requests.spec failed, can't parse That

Re: Python guidelines cleanup

JLT == Jason L Tibbitts ti...@math.uh.edu writes: JLT Also, When using the python_provide macro as detailed in the JLT guidelines, I can't seem to get fedpkg to generate an srpm: OK, I think a question mark somehow got converted to a % in the draft. %{?python_provide:%python_provide

Re: Python guidelines cleanup

ZJ == Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl writes: ZJ There's a dead link in Example common spec file. Oops, missed a colon. Fixed, thanks. ZJ I wrote that. I turns out, which I didn't know at the time, that ZJ this is only true for binary modules (for example python-systemd has ZJ

Re: Python guidelines cleanup

MH == Miro Hrončok mhron...@redhat.com writes: MH * in example spec, you mix srcname and pypi_name macros Yeah, fixed that up. MH * For example, the python 3 version of coverage must ship MHexecutables MH /usr/bin/coverage, /usr/bin/coverage-2 and /usr/bin/coverage-2.7, MH while the

Re: Python guidelines cleanup

After some additional discussion and cleanup, I've gone ahead and moved my drafts into place in the main guidelines. Please let me know if I've made any mistakes or typos or left out anything important. However, there is one thing I'm trying to understand about the new guidelines (which came

[Guidelines change] Changes to the packaging guidelines

Here are the recent changes to the packaging guidelines. - The big change is that the Python guidelines have been extensively reorganized and partially rewritten, and new macros are available which simplify packaging by removing some of the boilerplate which was previously required. The

[Guidelines change] Changes to the packaging guidelines

Here are the recent changes to the packaging guidelines. - The guidelines were updated to reflect the current policy that Fedora packages are no longer permitted to carry SysV-style initscripts. The relevant guidelines page has been moved to the EPEL hierarchy. *

[Guidelines change] Changes to the packaging guidelines

Here are the recent changes to the packaging guidelines. Note that there is also a set of Python guideline changes pending which I will send in a separate announcement. - Guidelines for making use of weak dependencies (Recommends:, Suggests:, etc.) have been added.

Re: macros.python2 requires update in F21+

> "H" == Haïkel writes: H> Hi, Nobody answered, should I assume that everyone is ok with me H> pushing Orion's patches in F21 and F22? I'm for whatever works, but I should ask if there's any possibility of getting these macros out of the main python package and

Re: Mention dist-info files in the packaging policy?

> "NC" == Nick Coghlan writes: NC> I just noticed that the packaging policy doesn't currently mention NC> dist-info directories, only the older egg-info: NC> https://fedoraproject.org/wiki/Packaging:Python#Files_to_include dist-info is completely new to me. I never

[EPEL-devel] Re: Additional python34 components for epel7

> "DF" == Denis Fateyev writes: DF> If we just could work "the same SRPMS name" problem around ;-) DF> Healthy repos with the master branch orphaned [1] may look a little DF> weird to users... That is not abnormal for EPEL-only packages, though. The dead.package file in

[EPEL-devel] Re: Which python3 versions to package for EPEL7?

> "TK" == Toshio Kuratomi writes: TK> We would have been in a lot better place today if we had separate TK> packaging of python2 and python3 packages in Fedora so that they TK> were never in sync there but that's not something we can probably TK> change now Nothing

Re: [EPEL-devel] Re: Which python3 versions to package for EPEL7?

> "TK" == Toshio Kuratomi writes: TK> We would have been in a lot better place today if we had separate TK> packaging of python2 and python3 packages in Fedora so that they TK> were never in sync there but that's not something we can probably TK> change now Nothing

[EPEL-devel] Re: epel-rpm-macros for EL6 (and EL5)

> "AT" == Antonio Trande writes: AT> %{__global_ldflags} is another macro that it's not available in AT> EPEL6. It appears that gets exported as a shell variable in the scope of %build by %__build_pre, as well as being mentioned in the %cmake, %cmake_kde4, %qmake_qt4

[EPEL-devel] Re: epel-rpm-macros for EL6 (and EL5)

> "JLT" == Jason L Tibbitts writes: JLT> Does that actually work on EL6? Looking at the spec, it seems obvious that it works on EL6. The package isn't branched for EL5 but if anyone knows if -Wl,-z,relro will work there than I'll add it there as well (once I get around

[EPEL-devel] Re: Mass rebuild of EPEL6

> "AT" == Antonio Trande writes: AT> This is not current tktable release. Well, it's what is currently on the master mirror. I'm not building from git; I'm taking the current set of released SRPMs. I could take them from testing instead if that's thought to be

[EPEL-devel] epel-rpm-macros for EL6 (and EL5)

Lately I've been working on an EL6 branch of epel-rpm-macros with the goal of removing the need for some of the %ifdefs and line noise and such required if you want to have one spec which builds on Fedora and EL6. Right now it simply enables %license in the %files section (mapped to %doc as the

[EPEL-devel]Re: python2-setuptools metapackage

> "DC" == Dan Callaghan writes: DC> Would it be easier to request the RHEL packages to add a virtual DC> Provides for the python2-* name? That is, python-setuptools in RHEL DC> could provide python2-setuptools. I can't imagine Red Hat going through all of the

[EPEL-devel] Re: Please test epel-rpm-macros 5-1 and 6-4

I should also note that epel-rpm-macros-6-2 has gone to stable, and it adds the requested node.js macro. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Please test epel-rpm-macros 5-1 and 6-4

The epel-rpm-macros-5-1 package for EPEL5 should now be in stable but I have not yet requested that it be added to the buildroot. This adds a number of things which I've mentioned earlier (Group:, BuildRoot: and %clean not needed; buildroot automatically cleaned in %install) and allows packagers

[EPEL-devel] Re: EPEL5 mass rebuild (2016-01-20, 179 failures)

> "RF" == Richard Fearn writes: RF> My point was that you couldn't get it to build because there was no RF> libewf to build it against. There is now, because the RF> disktype/libewf update has finally been pushed. Cool, then I suppose it will all be cleaned up after

[EPEL-devel] Re: Orphaned Packages in epel6 (2016-02-01)

> "o" == opensource writes: o> The following packages are orphaned and will be retired when they are o> orphaned for six weeks, [...] o> directfb orphan, kwizart, thias 17 weeks ago How does the retiring actually happen? I know it's a manual process,

[EPEL-devel] Re: Virtual packages providing python2-*

> "P" == Peter writes: P> I would be worried, though, that you'll have packages that were built P> against python that are now trying to pull in and possibly run on P> python2 unnecessarily, and possibly detrimentally if Red Hat suddenly P> decides to push python2

[EPEL-devel] Re: Virtual packages providing python2-*

> "JH" == James Hogarth writes: JH> Do just to be clear from your wording you are talking about RHEL JH> python packages that are known as python-foo in RHEL rather than JH> python2-foo there, since there is no other python within base to JH> cause confusion? Right,

[EPEL-devel] Re: How to go on with unmaintainable package?

> "CD" == Christian Dersch writes: CD> [...] for EPEL 6 I'm CD> unable to apply security fixes as one of them (the most important CD> one...) requires C++11 features not available in gcc 4.4 :( What is CD> the best strategy for such a package? Maybe ask someone who is

[EPEL-devel] Virtual packages providing python2-*

One annoying difference between packaging for Fedora and EPEL7 (and probably older) is the fact that Python packages in Fedora are required to provide "python2-foo" whereas many EL7 packages don't. This leads to ifdefs and unpleasantness, and kind of complicates our ability to hide some details

[Guidelines change] Changes to the packaging guidelines

Here are the recent changes to the packaging guidelines. - Some PHP scriptlets are now unnecessary in F24 due to the use of file triggers. * https://fedoraproject.org/wiki/Packaging:PHP#PECL_Modules * https://fedorahosted.org/fpc/ticket/597 - A page describing the implementation of

[EPEL-devel] Re: Virtual packages providing python2-*

> "TK" == Toshio Kuratomi writes: TK> The easiest thing to do if you want a single spec file for EPEL7 and TK> Fedora is to Requires: python-foo rather than python2-foo. Except that FPC would like to move away from this. That's the entire reason I've brought this up.

[EPEL-devel] Re: EPEL5 mass rebuild (2016-01-20, 179 failures)

> "DC" == Dan Callaghan writes: DC> All of these broken dependencies onto python-setuptools-devel seemed DC> a little strange to me so I dug into it. Thanks for doing this. I thought it was a bit odd but figured it was better to actually get the report out there rather

[EPEL-devel] Necessity of some old RPM constructs in EL5

I'm now working on some magic macros for EPEL5. Currently (on my machine, at least) you can use %license and don't need BuildRoot:. I'm curious about some other boilerplate constructs, though. %defattr in %files: I've been told that even EPEL5 doesn't need this, but still it persists. Can

[EPEL-devel] Re: Adding epel-rpm-macros to the buildroot

> "DG" == Dennis Gilmore writes: DG> When you are ready for the change to be made, please file a ticket DG> with releng, we will need to coordinate a koji and comps change. Yep, that was part of my plan. After committing the tiny fixes needed for those few packages (many

[EPEL-devel] Adding epel-rpm-macros to the buildroot

I've now done many mass rebuilds both with and without epel-rpm-macros in the buildroot and have found exactly 31 failures which result from the presence of the macro package. This macro package enables, in EPEL6, the use of %license in the %files section of the spec without having to

[EPEL-devel] EPEL5 mass rebuild (2016-01-20, 179 failures)

I performed a mass build of EPEL5, skipping only a few packages that take absolutely forever to build (libguestfs, thunderbird-lightning, ikarus and pypy). I also skipped rubygem-eventmachine because its test suite hangs forever. Turns out that I should also have skipped

[EPEL-devel] Re: Necessity of some old RPM constructs in EL5

> "PH" == Paul Howarth writes: PH> does not. It's probably still there because people can't remember PH> whether it was EL-5 or EL-6 that removed the need for it, and left PH> it there to be on the safe side. That's good to know. I also think there's more than a fair

[EPEL-devel] Re: Necessity of some old RPM constructs in EL5

> "DJ" == Dave Johansen writes: DJ> And it's not helped by the fact that the version of rpmlint on EL 5 DJ> and 6 warns when it's missing. Interesting. Well, we can fix rpmlint. And I can grep at least the rawhide specfiles for remaining instances, generate a

[EPEL-devel] %autosetup for EL6, epel-rpm-macros-6 license change

It appears that it's actually trivial to add %autosetup to RHEL6. You just need the Fedora macros plus a couple of extra definitions. That's in git now. I don't want to push this to testing because there's another version soaking in testing which I don't want to supersede. However, you can

[Guidelines change] Changes to the packaging guidelines

Here are the recent changes to the packaging guidelines. - A section on the treatment of pregenerated code has been added to the main guideline page. *​https://fedoraproject.org/wiki/Packaging:Guidelines#Use_of_pregenerated_code *​https://fedorahosted.org/fpc/ticket/580 - Text was

[EPEL-devel] Re: PSA: epel-rpm-macros in EL5 mock buildroots

The releng folks managed to get to the bottom of this and fix the underlying issue, so epel5 mock builds should now have the epel-rpm-macros package available for your specfile de-crufting needs. And remember, epel-rpm-macros-5 with functioning %autosetup is now in testing. Should make it to

[EPEL-devel] Re: Simplifying use of Python 3 macros?

> "DJ" == Dave Johansen writes: DJ> Is there anything that could be done in EPEL to make the Python 3 DJ> macros be usable without requiring %{python3_pkgversion}? Well, there has been some on and off work focused on making python packaging less hideous. A spec

[EPEL-devel] Re: using epel-rpm-macros

> "DL" == Dave Love writes: DL> How is the epel-rpm-macros package supposed to work? I have DL> epel-rpm-macros-6-4 installed, which is up-to-date against DL> epel-testing, and is supposed to make %license work like %doc but DL> doesn't seem to have any effect.

[EPEL-devel] Re: using epel-rpm-macros

And I just pulled two random package with EL6 branches, changed %doc to %license in the appropriate places, and built them in mock. Everything came out as expected (no build failures, and the license files are in with the rest of the documentation). So I unfortunately have no idea what might be

[EPEL-devel] Re: using epel-rpm-macros

> "SJS" == Stephen John Smoogen writes: SJS> What bug? Sorry we really need to see some actual output and SJS> problems here to have an idea of what we are trying to tackle. I think he's referring to the fact that the SCL macros break if you try to do too much with other

[EPEL-devel] %autosetup for EPEL5

I thought it was impossible. Then I thought it was merely impossible without some terrible hacking. But now, after a bit of inspiration in the shower this morning, I went ahead and implemented the complete %autosetup functionality for EPEL5. Currently built as epel-rpm-macros-5.3 but not yet

[EPEL-devel] Re: PSA: epel-rpm-macros in EL5 mock buildroots

> "DJ" == Dave Johansen writes: DJ> To my knowledge mock for EL 5 has been broken for several months DJ> now: I've had no problems using it. I did rebuild all of EPEL5 at least ten times recently and while there were plenty of failures I'm pretty sure those failures

[EPEL-devel] PSA: epel-rpm-macros in EL5 mock buildroots

Something went wrong when epel-rpm-macros-5 was added to the EPEL5 buildroot such that it works fine in koji but isn't actually present when you build in mock. So if you were trying to de-cruft your specs and found that things weren't working as you expected when you did a mock build, that's why.

[EPEL-devel] Python macros for EPEL6 available in testing

I added a set of python macros to epel-rpm-macros-6 and pushed them out to testing. This should allow you to use the all of what's in the regular Fedora Python guidelines as is. You will still have to %if out some of the python3 stuff (build deps, subpackage declarations, %files, etc.), but

Re: Problems with script installation in RPM's

> "PV" == Petr Viktorin writes: PV> Unfortunately, changing the Guidelines isn't trivial – we have a PV> ticket that's been sitting in FPC's queue for half a year [1]... Thanks for the snark. Nobody has submitted a draft and that ticket isn't particularly urgent

[EPEL-devel] %autosetup now in EPEL5 and EPEL6 proper

Just FYI, EPEL5 and EPEL6 now have functioning %autosetup implementations. For EPEL6 there are no caveats; for EPEL6, if you have patches numbered higher than Patch9: then you will need to set %el5_patches_limit appropriately. But, uh, why would you do that? All documented at

<    1   2   3   4   5   6   7   >