Re: Packages which use the BuildRoot: directive

Unfortunately it seems that many of these packages have had the BuildRoot tags _added back in_ after previously having them removed. A number of the commits even delete existing changelog entries, a sure sign that someone is just copying the specfile from some outside source. As a reminder, the

Packages which use the BuildRoot: directive

The Packaging Guidelines indicate that BuildRoot: should not be used in Fedora specfiles. The BuildRoot: tag has not been required since RHEL6 and was also not required in EPEL5 (due to some magic in epel-rpm-macros). It has not been needed in any Fedora release since at least Fedora 12. It has

Packages which use banned tags

The packaging guidelines indicate that the following tags must not be used: Copyright: Packager: Vendor: PreReq: https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sections I wasn't aware that a package would even build if the first three were used, but it seems that a few

Re: Packages which use the BuildRoot: directive

> "JB" == Josh Boyer writes: JB> That's impossible to enforce and unrealistic. I will go as far as "it's somewhat difficult to enforce and idealistic", but no further. JB> We can say that as much as we'd like, but there is nothing we can do JB> to prevent people from syncing from

Re: Packages which use banned tags

My apologies; after closer inspection I see that dpkg is a false positive. It does match "^Vendor:" but that string occurs inside of a here-document within a section. Will improve the scripting to only look for tags when the rpm parser will be outside of section context. I did fix the other

Re: Packages which use the BuildRoot: directive

> "MM" == Matthew Miller writes: MM> Yeah, this argument seems pretty compelling to me. I think that if MM> people want to maintain an outside spec file, they *must* also MM> respect changes made to the primary one in dist-git. I took a break from this discussion, but I did want to point

Re: Removal of GCC from the buildroot

> "RPH" == R P Herrold writes: RPH> This list seems to only cover packages starting with an uppercase RPH> letter, or a letter before lowercase 'i' Well, the list is incomplete because the mass rebuild is not complete. Upper case letters and digits were submitted first. Currently packages

Re: Updating Brotli to 1.0.5 in Rawhide

I wanted to point out that because libcurl now depends on brotli [1], nearly every package in the distribution indirectly depends on brotli. So repoquery --whatreqires brotli --recursive gives me 57775 packages. If anyone feels up to it, I'm sure our friend pouar might like to have a

Re: F28 Self Contained Change: Enabling Python Generators

> "ZJ" == Zbigniew Jędrzejewski-Szmek writes: ZJ> What about BuildRequires? Quite often that list even more work to ZJ> generate, and your proposal does not address it in any way. Does any dependency generation we use currently (i.e. Perl or even just the plain C/C++

Re: EPEL support in "master" branch (aka speeding up Fedora development)

> "VO" == Vít Ondruch writes: VO> I think FPC does not know. Certainly we know what we generally try to do, but Fedora changes quickly and some things aren't always stated as well as they could be. Plus the experts who draft the more esoteric guidelines often have other

Re: EPEL support in "master" branch (aka speeding up Fedora development)

> "SR" == Samuel Rakitničan writes: SR> I think conditionals should be documented with more examples as well SR> [1], in order to minimize such bugs. Specific examples of what you'd like to see are certainly welcome. Feel free to file tickets at

Re: EPEL support in "master" branch (aka speeding up Fedora development)

> "SB" == Sérgio Basto writes: SB> Can't we fix things on EPEL, to speed up Fedora devel ? We can try. See the macro work I've done (though the real work there was against EPEL5, which is fortunately forgotten now). SB> another story that is bugging me is python2

Re: Proposed Fedora packaging guideline: More Go packaging

> "nm" == nicolas mailhot writes: nm> I don't know about EPEL6, but we use it as-is in EL7 and it works nm> just as well (except maybe for the %autosetup bits but IIRC that's nm> autosetup which is broken in EL7). I had ported autosetup to EPEL6 and then at the

Re: Proposed Fedora packaging guideline: More Go packaging

I wish this message wasn't crossposted everywhere, but I don't want to lose any discussion by trimming the CC list. Sorry if replies generate bounces for some. > "nm" == nicolas mailhot writes: nm> And the forge macros are now available since nm>

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

> "OO" == Orcan Ogetbil writes: OO> Shouldn't we consider having -devel packages Require gcc or gcc-c++? OO> What good is a header package without a compiler anyway? You could argue whether they're useful without a compiler, but they are certainly useful without gcc.

Re: Broken system upgrade due to rich dependencies

> "PM" == Panu Matilainen writes: PM> It's not a solution because doing so usually drags half the distro PM> along due to library dependencies etc. That's true if you're updating to the rpm/dnf/whatever from the distro you want to upgrade to. That's not true if you're

Re: Python 2 will be replaced with Python 3 in the next RHEL major release

> "RG" == Raphael Groner writes: RG> what to do with packages that can not be ported to python3? Can anything really not be ported to python3? I suppose if there was something which messed with the internals of the python interpreter in some way then that would

Re: How should I coordinate the package updates with you guys?

> writes: > Brotli apparently just got a new update, and I was told I have to > coordinate package updates with you guys in Rawhide instead of just > uploading the updates unannounced. How should I proceed? Well, there's only really a need to coordinate if the versioning

Re: Intent to orphan Python 2

> "ZJ" == Zbigniew Jędrzejewski-Szmek writes: ZJ> Please don't. This is a repeat of the original idea of having ZJ> separate python3 packages back when python3 was being ZJ> introduced. It seems that you are suggesting that pointless bureaucracy be kept in place purely

Re: Intent to orphan Python 2

> "CS" == Charalampos Stratakis writes: CS> On a relevant note, python packaging guidelines are soon subject for CS> a change in regards to that [0] CS> [0] https://pagure.io/packaging-committee/issue/753 Please note that the ticket there started off as a strong

Re: Upcoming gdouros-*-fonts license change and subsequent complications

> "AP" == Alexander Ploumistos writes: AP> However, in his last message, he left open the possibility of AP> negotiating a different license for/with Fedora Project, but I don't AP> feel I am the right person to engage in any further negotiations AP> with him.

[Guidelines change] Changes to the packaging guidelines

Here are the recent changes to the packaging guidelines. - A note was added to the Python guidelines indicating that the python2 stack may go away and that upstreams should be contacted about software not yet ported to python3. *

Re: non responsive maintainer - package python-flask-login

Is there some reason that you couldn't mention who the package maintainer is? Both Richard Marko (rmarko) and Jan Kaluža (jkaluza) are listed as maintainers that package. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send

Re: systemd 238 and sysusers

> "ZJ" == Zbigniew Jędrzejewski-Szmek writes: ZJ> - various transfiletriggers have been ported from Mageia, for the ZJ> udev hwdb and rules, the journal catalog, sysctl.d, binfmt.d, ZJ> sysusers.d, and tmpfiles.d. This means that for many packages, ZJ> which do not

Re: Packages with scriptlets which call ldconfig

> "TH" == Till Hofmann writes: TH> Not strictly a script error: I already updated most of my packages TH> without rebuilding them, so they are all false positives. That's fine. I could exclude those but I don't know which they are and the benefit would be pretty low. TH> I guess I'm not

Re: Packages with scriptlets which call ldconfig

After modifying the script to strip comments and running it against the most recent version of rawhide on my local mirror, I found that abrt, pcsc-cyberjack and slic3r dropped off the list. But I found that libdnf actually appeared on the list when it wasn't before.. I checked the package and

Re: What is the criterion for Python 3.7 side tag merge?

> "MH" == Miro Hrončok writes: MH> What is the criterion to merge the side tag? I think ultimately that's up to you, but certainly the idea is to balance disruption (breaking builds or rawhide usability) against holding back progress (the approved python 3.7 feature). It would certainly be

Re: Fedora should replace mailing lists with Discourse

BC> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Jason L Tibbitts III - ti...@math.uh.edu - 713/743-3486 - 660PGH System Manager: University of Houston Department of Mathematics ___ devel mailing list -- devel@lis

Re: Fedora should replace mailing lists with Discourse

> "GBC" == Gerald B Cox writes: GBC> Probably not fair to judge the system on the capabilities of your GBC> email client. It is entirely fair. Moving to this system will remove capabilities that I have now and will not provide adequate replacements for them. Since moving to this system

Re: Fedora should replace mailing lists with Discourse

> "GBC" == Gerald B Cox writes: GBC> People keep saying it isn't sufficient or it doesn't work. I've GBC> been using it for 3 days and looks and acts like a normal mailing GBC> list. And I've been using it since the RT project switched a couple of years ago. And... it doesn't really look

Re: Use immutable CRAN URLs

> "IU" == Iñaki Ucar writes: IU> This URL format is not recommended by CRAN, but more importantly, IU> the Source0 format does not work anymore, as [1] noted, when a new IU> version is released. However, there is an immutable format IU> available, as [2] pointed out. So my proposal is to use

Re: Should we also list "Trivial" review tickets on Easyfix?

> "AS" == Ankur Sinha writes: AS> The package review process suggests the use of "Trivial" on the AS> Whiteboard for simpler tickets to aid new-comers. So, they seem to AS> serve the same purpose as EasyFix. Would it be OK to also list these AS> tickets on the EasyFix page? I don't see why

Re: Use immutable CRAN URLs

Spent a couple of seconds looking at this and have a couple of questions. Once I have answers it should take me only a couple of minutes to give you something to test. Does the source URL for CRAN not have any kind of file extension? Could you provide a couple of sample packages for me to look

Re: Use immutable CRAN URLs

I've been trying to stay away from computers for a few days. Just catching back up with email. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct:

Re: Use immutable CRAN URLs

Looking at this further, this URL scheme is just terrible and will be "fun" to make use of. Basically you have to keep in mind that a tool like spectool can't trust the filename that is sent by the remote web server and will instead use only the filename extracted from the URL. That means if you

Re: Use immutable CRAN URLs

> "IU" == Iñaki Ucar writes: IU> https://cran.r-project.org/package=simmer=3.0.0 IU> returns a redirection (303) to the complete URL, with file IU> extension. 303 is actually "See Other". Which is odd as that's usually sent in response to a PUT or POST, not a GET. Maybe you can get the

Re: Use immutable CRAN URLs

> "IU" == Iñaki Ucar writes: IU> This is great. However, in theory, given the naming guidelines, by IU> stripping the leading "R-" you should get the package name. In IU> practice, at least one package doesn't adhere to this: R-TH-data, IU> while the R package name is TH.data, not TH-data.

Re: Use immutable CRAN URLs

And with some tweaks to the macro file (current version at https://www.math.uh.edu/~tibbs/fedora/macros.test) and the R-uuid package is reduced to the following. Not quite as simple, but it shows how you can still split out the individual sections when you need to add something, and also cope

Re: Use immutable CRAN URLs

> "JLT" == Jason L Tibbitts writes: JLT> It depends on how far you want to go, and how specific you can be JLT> before you're not actually simplifying a majority of the R packages JLT> we have. Just for fun I took the R-webp package and constructed a macro that generates most of the

Re: Use immutable CRAN URLs

> "IU" == Iñaki Ucar writes: IU> - Version: As you already found out, there are many version formats IU> allowed. But it's easy to work from Version: in the normal case and simply allow the CRAN version to be specified separately, as I showed in the R-uuid sample. If it's rather more

Re: Use immutable CRAN URLs

> "IU" == Iñaki Ucar writes: IU> I see. Anyway, I suppose that it's healthy to preserve some manual IU> intervention in these sections. Well, it would be super great if we didn't have to do that and one day RPM might give us some reasonable way to generate more of the specfile based on the

Re: Use immutable CRAN URLs

Since I actually had an existing pagure repo for random RPM macro experiments, I just dropped the R macro stuff there. https://pagure.io/misc-rpm-macros https://pagure.io/misc-rpm-macros/blob/master/f/macros.R-extra I still have some ideas to implement but feel free to test what's there. To use

Re: Ursa Major (modules in buildroot) enablement

> "FW" == Florian Weimer writes: FW> Modules do not support parallel installations of different module FW> versions. Many SCLs are constructed in such a way that this is FW> possible. So I'm not sure if modules are a clear improvement over FW> SCLs. And the really fun thing is that once

Re: Fedora Packaging Guidelines on docs.fedoraproject.org

> "AS" == Ankur Sinha writes: AS> For example, maybe [1] should link to [2], since I expect the AS> sponsorship process falls under the FPC's scope? It does not. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an

Re: Orphaned python2-matplotlib

> "MH" == Miro Hrončok writes: MH> I've orphaned python2-matplotlib. Nobody replied to my previous MH> heads up e-mails. So that nobody is confused by this, the python2-matplotlib package was previously an EPEL-only stub package maintained by me that existed so packagers could simply

Re: Orphaned python2-matplotlib

> "SJS" == Stephen John Smoogen writes: SJS> What packages? And where are they depending on it? I believe the underlying issue is that previously the Fedora python-matplotib package produced both python2 and python3 subpackages. But recently it dropped support for python2. What I don't

Re: package downgrades from f28 to f29

> "KP" == Kamil Paral writes: KP> That policy has been cancelled. Since the upgrade tools started KP> doing basically "dnf distrosync (--allowerasing)" for upgrades, the KP> upgrade path between distros stopped being a major issue and the KP> policy has been dropped. If this is true then

Re: Fedora Packaging Guidelines on docs.fedoraproject.org

> "BP" == Björn Persson writes: BP> This was on Fedora 27. So one needs Fedora 28 to help fixing the BP> formatting of the guidelines then? (Once that other breakage is BP> fixed I suppose?) I believe one could build the antora stack from scratch instead of using a container. I would hope

Re: Fedora Packaging Guidelines on docs.fedoraproject.org

> "AS" == Ankur Sinha writes: AS> Thank you---that's really neat! Would other relatively static pages AS> such as these also be migrated? Those are outside the scope of the packaging committee. They could certainly be migrated in a similar fashion, but they wouldn't live in the packaging

Re: Fedora Packaging Guidelines on docs.fedoraproject.org

Indeed, asciidoctor works a bit better than asciidoc does but still converts quickly. It's actually in the "rubygem-asciidoctor" package. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: Fedora Packaging Guidelines on docs.fedoraproject.org

> "NG" == Neal Gompa writes: NG> I'm wondering if it was a good idea to use asciidoc in the first NG> place. Unlike reStructuredText, asciidoc implementations seem to be NG> in very poor shape. It's what the documentation team has chosen. I don't think the packaging committee would want to

Re: Fedora Packaging Guidelines on docs.fedoraproject.org

> "JF" == John Florian writes: JF> I would agree with that, but I read the announcement as if this JF> *was* finished. The announcement was unfortunately made before things were in what I would consider to be a "releasable" condition. Currently the Wiki pages continue to exist and have not

Re: Fedora Lifecycles: imagine longer-term possibilities

> "IU" == Iñaki Ucar writes: IU> In this respect (the kernel), it's true that something changed IU> compared to a decade ago: there was no LTS support upstream IU> then. Now, there is. That is not really true. 2.6.16 (the first kernel that I recall anyone calling some equivalent of "LTS")

Re: F30 Self-Contained Change proposal: krb5 crypto modernization

> "BC" == Ben Cotton writes: BC> == Detailed Description == [elided] Is it just me or does this not actually say clearly what is changing? The first paragraph talks about two RFCs. The second paragraph talks about how easy it is to break single DES. The third paragraph talks about how

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

> "FV" == Fabio Valentini writes: FV> - unless those other, main icon theme packages have also added FV> %transfiletrigger* scriptlets, like I've done for elementary and FV> Paper. Perhaps it should be mandatory for icon themes to add the necessary file triggers so that no package will ever

Re: F30 Self-Contained Change proposal: krb5 crypto modernization

> "JLT" == Jason L Tibbitts writes: JLT> Is it just me or does this not actually say clearly what is JLT> changing? Seems it's just me; somehow that's in the summary but not in the detailed description. Seems odd for the details to have less information than the short version, but I guess

[Guidelines change] Changes to the packaging guidelines

Here are the recent changes to the packaging guidelines. - We have begun to remove content from the wiki. The old pages should all now have links to the new docs site. As we continue to work on the new documents, the corresponding wiki pages will be emptied and left only with the link to

Re: [HEADS UP] Removal of ldconfig scriptlets

> "RG" == Raphael Groner writes: RG> Fedora packaging is becoming to get heavy magic aspects. Well, obviously we would prefer that the scriptlets just go away and not be replaced with magic. The magic macros exist to accommodate those who wish to have a single spec across Fedora and EPEL,

Re: F30 Self-Contained Change proposal: krb5 crypto modernization

> "RH" == Robbie Harwood writes: RH> If I backport this to fc29, will that assuage people's concerns? I think it would certainly help and I wouldn't complain. In fact, I'd love to start running that as soon as I can. However, it wouldn't help anyone who does a (supposedly supported)

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

> "MH" == Miro Hrončok writes: MH> Is there anything we can do to prevent maintains to override the MH> change with their next "magical sync" from jira/RDO/github/whatever? MH> I mean we already say they should not do that, but can we somehow MH> make sure they actually won't? This

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

> "KL" == Kalev Lember writes: KL> I agree with Zbyszek, I think it would be best to push the changes KL> directly to git. But then we're back to the same problem: Do you remove the ldconfig calls entirely or do you add the macros? Prepare for flames if you get it wrong, even though it's

Re: Stalled Review Request - Close it and create new?

> "AB" == Andrew Bauer writes: AB> In the interested of getting this review completed, am I in my right AB> to close this request and create a new one, or is there better AB> course of action? If you have a package ready to go, then certainly just close the old review ticket. If someone is

Re: prevent accidentally creating branches in dist-git

> "DM" == Dusty Mabe writes: DM> I personally think this should be the default for all projects but I DM> don't know if there is a way to easily make that happen when a DM> project gets created. I'm sure there could be. But I'd go further and say that we should set that on all existing

Re: Remove Package from Rawhide

> "SS" == Salman Siddiqui writes: SS> I accidentally submitted a Koji build for 4 packages [1] that SS> are not supposed to be packaged for Rawhide. Are they EPEL only packages are something? In any case, if those packages aren't ever supposed to be in rawhide (or be branched for f30 in

Re: Running fedpkg on Fedora 28

> "MM" == Mike Miller writes: MM> I have installed the latest fedpkg, fedpkg-1.35-1.fc28.noarch. Do I MM> need to upgrade to 29? I thought fedpkg would still work on 28. I'm still on F28 (for another hour or so) and have no problems running fedpkg. fedpkg-1.35-1.fc28.noarch

Re: Better fonts by default?

> "NG" == Neal Gompa writes: NG> Most of these fonts look like they are licensed appropriately, the NG> only problem is the Ubuntu fonts, which have been noted to have a NG> non-free license[3] (unless someone can get Canonical to fix it). I had a look at the license at

Re: Fedora Lifecycles: imagine longer-term possibilities

> "MM" == Matthew Miller writes: MM> It's the fundamental contradiction that all operating systems face: MM> users complain "too fast and too slow!" at the same time. Well, then lengthening the Fedora lifecycle does not seem to me to be the real solution. Instead, I think, it's to

Re: Fedora Lifecycles: imagine longer-term possibilities

> "IU" == Iñaki Ucar writes: IU> AFAIK, that wasn't officially supported. What does "official" actually mean, and what relevance does that have? Adrian Bunk didn't maintain 2.6.16 in a way that's much different than the current long term support kernels are supported. And even before that,

Re: prevent accidentally creating branches in dist-git

I filed https://pagure.io/fedora-infrastructure/issue/7398 to see if the infrastructure folks (or pingou or whoever) would be willing to turn this on for all existing repositories. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To

Re: Automating package maintainers responsivity check

> "PO" == Peter Oliver writes: PO> Also, it's hard to volunteer to co-maintain a package which has a PO> non-responsive maintainer, because there is no one to grant you PO> access. Well, certainly there is but the issue is finding the proper way to ask for it. And I don't think we have any

Re: F30 Self-Contained Change proposal: krb5 crypto modernization

> "RH" == Robbie Harwood writes: RH> Ah, I see, you're talking about the case when the enctype is already RH> not permitted. That all makes sense then. Right. Basically, if any one of these: * Warnings in previous versions about principals without modern etypes * Logging in the new

Re: F30 Self-Contained Change proposal: krb5 crypto modernization

> "RH" == Robbie Harwood writes: RH> I've spent a nontrivial amount of time working on improving that, RH> but am always willing to process more bugs in the RH> documentation/errors area. I know, and I don't mean to denigrate any work that's been done in making the MIT KRB stack better.

Re: sqlite + django pains and serious bodhi confusion

> "JF" == John Florian writes: JF> I thought I'd start by consulting JF> https://bodhi.fedoraproject.org/updates/?packages=sqlite to see what JF> changed but much to my surprise the newest build I see there is JF> sqlite-3.22.0-5.fc28! Huh? Where are the f29 builds? First, note that Bodhi

Re: F30 Self-Contained Change proposal: krb5 crypto modernization

> "RH" == Robbie Harwood writes: RH> Per your follow-up email, I'm not clear on whether you want changes RH> here. If you do, speak up, especially if you have suggestions. Well, it was just odd that the summary had information not contained at all within the detailed description. Since

Re: [Fedora-packaging] Re: Periods in compat package names

> Björn 'besser82' Esser writes: > From what I know, and what is pratically done, one would name the > compatibility package "python-sqlalchemy05". Please see the relevant guidelines:

[Guidelines change] Changes to the packaging guidelines

Here are the recent changes to the packaging guidelines. - The Python packaging guidelines have been updated to reflect the fact that Python 2 is deprecated. All relevant information for legacy Python 2 packaging has been moved to the appendix. Together with this change, the rule for

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

> "ZJ" == Zbigniew Jędrzejewski-Szmek writes: ZJ> I think it's pretty clear: all the standard invocations of ZJ> scriptlets that have by replaced by transfiletriggers will be ZJ> removed, along with the whole %post/%postun sections if its the only ZJ> thing in them. I do think it would be

Re: Package Naming Guildelines for compat-lua packages

> "RS" == Robert Scheck writes: RS> wouldn't it have been a clever alternative to use lua52-* rather a RS> quite unspecific "compat-lua-" to be really similar with your RS> python2/3 example? I made a similar suggestion in the packaging committee ticket. "compat-" is nonspecific and goes

Re: Anitya not working again?

> "RM" == Robert-André Mauchin writes: RM> Since our float of Golang packages is severely out of date, I was RM> expecting a load of new messages from Bugzilla. I don't believe it notifies when the project is first added. It should notify when the project is next updated. - J<

Re: Proposal: Stewardship Group / SIG for taking care of otherwise "module-only" packages

> "MH" == Miro Hrončok writes: MH> You realize that once it is maintained by the group, nobody else is MH> going to take it? When the stewardship SIG maintains a package, it should be for the sole purpose of keeping it around just long enough to avoid serious disruption that would be caused

Re: Fork a 119MB pagure project to updating monitoring?

> "KF" == Kevin Fenzi writes: KF> Well, I find it unfortunate, does that count? :) It is unfortunate, but note that it's unfortunate simply because of our procedures. Certainly it would be nice if the functionality for making new branches and changing monitoring and some bugzilla settings

Re: Fork a 119MB pagure project to updating monitoring?

> "JC" == Jeremy Cline writes: JC> The effort would be a 1-2 line change in the-new-hotness, and JC> distributing the config to each package repository (some proven JC> packager could do this easily). Well that seems easy enough. We still need the repo for the bugzilla assignee override

Re: Sphinx and xindy

> "MH" == Miro Hrončok writes: MH> There should be a configuration option that disbales xindly. Does MH> the documentation build with it? Since xindy isn't really something that can be relied upon, is it possible (or reasonable) to do this globally in our sphinx packages? Even when it was

Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)

> "MH" == Miro Hrončok writes: MH> On 08. 03. 19 21:16, Neal Gompa wrote: >> I really wish we'd allow Epochs to be reset on distribution upgrades. >> With dnf distro-sync (which is used by system-upgrade) Epochs don't >> really matter and upgrades work as intended anyway... MH> Let's do a

Re: Allowing Epoch to be reset between releases

> "MH" == Miro Hrončok writes: MH> One thing to consider here is other packages that have Requires MH> etc. on something like "foo > 1:1.2", so if it is automated, this MH> part needs to be automated as well. Indeed. And of course this breaks any such dependency outside of Fedora as well.

Re: Allowing Epoch to be reset between releases

> "ZJ" == Zbigniew Jędrzejewski-Szmek writes: ZJ> This doesn't sound convincing at all. I was not attempting to be convincing. ZJ> We *know* that people miss announcements all the time. Dropping ZJ> epochs would introduce yet another case where a "magical" step is ZJ> needed at a specific

Re: Allowing Epoch to be reset between releases

> "VO" == Vít Ondruch writes: VO> In this case, if DNF said something like "you have installed VO> foo-1:1.0, but there is available foo-0:2.0" it would give me VO> hint. From the start it would be annoying, but once we would reach VO> the point 4, I would, at least, know that I should do

Re: F30 Self-Contained Change proposal: MongoDB Removal

> "JH" == John Harris writes: JH> For what reason is SSPL considered non-free? As I see, it's JH> essentially a GPL incompatible AGPL license. It's been pretty well covered throughout this whole debacle, but here's the most recent announcement from Fedora Legal:

Re: [HEADS UP] Rebasing to Readline-8.0 in rawhide

> "SV" == Siteshwar Vashisht writes: SV> I would do that. Thanks. SV> I will also provide a compatibility package for readline 7. That does help, but then you have to know that it's the magic package you need to install in order to restore the command line editing capability. Nothing

Re: Orphaned packages to be retired

> "RG" == Raphael Groner writes: RG> Hi Miro, winetricks should get assigned to ekulik as he's the new RG> main admin. I've made ekulik the main admin of the winetricks repository. It's not blocked in koji so everything should be OK now. - J<

Re: [HEADS UP] Rebasing to Readline-8.0 in rawhide

> "SV" == Siteshwar Vashisht writes: SV> Readline-8.0 was released earlier this month[1]. I am going to SV> rebase it in rawhide in couple of weeks. Note that a couple of things break in weird ways every time readline gets a new major version. For me that's the command line editing

Re: Can we maybe reduce the set of packages we install by default a bit?

> "LP" == Lennart Poettering writes: LP> That's not true anymore. There's a kernel compile time option now LP> for that in CONFIG_RANDOM_TRUST_CPU=y. And yes, the Fedora kernel LP> sets that since a while. Isn't this arch-dependent? config RANDOM_TRUST_CPU bool "Trust the CPU

Re: Sphinx and xindy

> "JJ" == Jerry James writes: JJ> Somebody out there has been involved with past attempts to build JJ> xindy. Please, I would like to make progress on this so I can get JJ> back to building the coq stack's new versions. Which package used JJ> to contain xindy? It is/was part of

Re: Updating/rebuilding of coin-or packages

> "AT" == Antonio Trande writes: AT> Is it correct tagging an absolute path with %doc? Yes, it's fine; that just sets the flag that tells RPM "this file/directory contains documentation". That's not really any different than, say, using %config to set the "this is a configuration file"

Re: Can we maybe reduce the set of packages we install by default a bit?

> "LP" == Lennart Poettering writes: LP> Yes it is. But so is rngd afaik? The software isn't exclusive to any particular architecture, though it may of course have different sources of entropy on different architectures. - J< ___ devel mailing

Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

> "PM" == Panu Matilainen writes: PM> Note that rpm doesn't support parallel zstd compression, and while PM> it does for xz, that's not even utilized in Fedora. Doing parallel xz compression has a surprising cost in compression ratio which gets worse as the thread count increases (because

Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

> "BC" == Ben Cotton writes: BC> * The change requires setting a new compression algorithm in rpm BC> macros. Then a mass rebuild of all packages is required. Technically there is no harm if a mass rebuild is not done; there will simply be no benefit for packages which aren't rebuilt.

Langpacks and the packages needed to display/input a language

I noticed that my F30 installs are coming out far larger than my F29 installs (by 3GB or so) and did some digging into why. With F30 we switched away from having groups named like "korean-support" that you could install to get input methods and fonts needed to display a language and instead we

Re: Langpacks and the packages needed to display/input a language

> "JP" == Jens-Ulrik Petersen writes: JP> Jason, can you explain in more details (bug report is also fine) how JP> exactly you are installing? I install a generic minimal system via kickstart (booted using the Server PXE images and using the Everything repositories) and then after the

Re: HEADS UP: DynamicBuildRequires are available

> "MC" == Michael Cronenworth writes: MC> Any long term plans to support C/C++ apps? Depends on what you mean by "support", really. Really there's just a new spec section that gets run and it just needs to echo a list of build dependencies. That's really all this does; the existing Rust

<    1   2   3   4   5   6   7   >