Re: FF 3.6.9 update for F-13

Christopher Aillon venit, vidit, dixit 14.09.2010 00:49: > On 09/12/2010 08:39 PM, Elio Maldonado wrote: >>On 09/12/2010 12:50 AM, Bojan Smojver wrote: >>> How did this slip through the cracks? Isn't that a security related >>> update? >>> >> No, it didn't slip trough the cracks. Some problems

Re: [ACTION REQUIRED] Retiring packages in F-16 (final warning)

Bill Nottingham venit, vidit, dixit 20.07.2011 21:28: > Each release, before branching, we block currently orphaned packages. > It's that time again for Fedora 16. > > New this go-round is that we are also blocking packages that have > failed to build since before Fedora 14. > > The following pac

Re: Why does git merge have so much trouble with Fedora package branches?

Adam Williamson venit, vidit, dixit 10.11.2011 02:46: > I'm currently going through and bumping several packages whose Rawhide > builds have got behind their F16 builds. > > I've come across several packages where git merge hit 'conflicts' for no > readily apparently reason in this case. > > Take

Re: Moving xine-lib and dependent apps to RPM Fusion Free for F17?

Kevin Kofler venit, vidit, dixit 05.01.2012 20:56: > Hi, > > the current xine-lib maintainer speaking. :-) > > The Xine project: > http://www.xine-project.org/home > has recently released a new major version, version 1.2.0. > > Unfortunately, among the list of changes: > http://sourceforge.net/p

Re: f15 koji buildroots broken?

Nikola Pajkovsky venit, vidit, dixit 11.01.2012 12:14: > Ralf Corsepius writes: > >> Hi, >> >> I am observing weird build failures for f15: >> http://koji.fedoraproject.org/koji/taskinfo?taskID=3638192 >> >> The corresponding root.log >> (http://koji.fedoraproject.org/koji/getfile?taskID=3638193&

Re: [ACTION REQUIRED] Retiring packages for F-17

Bill Nottingham venit, vidit, dixit 13.01.2012 17:11: > Each release, before branching, we block currently orphaned packages. > It's that time again for Fedora 17. > > New this go-round is that we are also blocking packages that have > failed to build since before Fedora 15. > > The following pac

Taking ownership of orphaned+retired impressive

Package "impressive" used to be available for F13 but is orphaned; it got marked retired for F14 and rawhide (master) because of maintainer inactivity. I took over ownership for F13, see: https://admin.fedoraproject.org/pkgdb/acls/name/impressive I fedpkg-cloned it, synced with upstream and ran

Unretired package "impressive" blocked in buildsys

Hi there, I took over a retired package (rereview APPROVED, took over package, reassigned bugs, SCM update request processed) but can't seem to "fedpkg build" it: I get "package impressive is blocked for tag dist-f15" (see below). Everything in pkgdb looks OK: https://admin.fedoraproject.org/pkg

Re: Is there any value to per-Fedora branch ACLs?

Toshio Kuratomi venit, vidit, dixit 08.12.2010 01:44: > On Tue, Dec 07, 2010 at 10:20:28AM -0800, Jesse Keating wrote: >> While I'm looking into the git setup and ACLs and all this, I have a >> question. >> >> Is anybody seeing any real value of having different commit ACLs per >> Fedora branch? I

Re: Fedora 12 End of Life

Kévin Raymond venit, vidit, dixit 08.12.2010 11:27: > On Thu, Dec 2, 2010 at 10:49 PM, Kevin Fenzi wrote: >> This announcement is a reminder that as of 2010-12-02, Fedora 12 has >> reached its end of life for updates and support. No further updates, >> including >> security updates, will be avail

Stomped by buildsys mail

Got this: impressive has broken dependencies in the rawhide tree: On x86_64: impressive-0.10.3-3.el6.noarch requires pygame On i386: impressive-0.10.3-3.el6.noarch requires pygame On ppc64: impressive-0.10.3-3.el6.noarch requires pygame Please resolve this as soon as possib

Re: Another request for comment, dist-git branch proposal

Jesse Keating venit, vidit, dixit 15.12.2010 23:10: > https://fedoraproject.org/wiki/Dist_Git_Branch_Proposal > > I think I'm ready to present this to FESCo for consideration, but I'd > like another round of eyes and thoughts/questions. Thanks! > Maybe along with a micro migration guide: git re

Re: Orphaned Packages in rawhide (2015-09-21)

> The following packages require above mentioned packages: > Depending on: flickcurl (1), status change: 2015-09-11 (1 weeks ago) > darktable (maintained by: madko, germano) > darktable-1.6.8-2.fc24.i686 requires libflickcurl.so.0 > darktable-1.6.8-2.fc24.src requi

Re: Intend to retire kde-plasma-daisy

Kevin Kofler venit, vidit, dixit 01.03.2015 06:43: > Michael J Gruber wrote: >> this is a heads up notice that I intend to retire kde-plasma-daisy, the >> reasons being: >> >> - no upstream updates in almost 3 years > > Then retiring it is pretty much the only

Re: Please BuildRequire python3-setuptools explicitly

Hi there Thanks for the clear posting. I have updated dblatex with the BR in rawhide. I guess it's enough to trickle this down to other branches when they need a rebuild anyways. The hit on portmidi is a false positive: while it allows to be built with setuptools it by default does not, and th

Re: Please BuildRequire python3-setuptools explicitly

So, turns out I got this right somehow (setup.py defaults to distutils) but not really: We don't even use setup.py but build the portmidi python module directly (cython/gcc/install). I removed setup.py and rebuilt, this works fine and produces the same package. So, I suggest removing setup.py

Intent to orphan jbig2dec EPEL branch(es)

Hi there I intend to orphan the EPEL branches which I'm maintaining. In fact: "I'm maintaining" is an exaggeration. The EPEL requirements simply do not match my time constraints as soon as EPEL gets behind maintained Fedora versions. For upstreams without any maintenance branches nor ABI stabil

Re: Stop the git abuse

Sérgio Basto venit, vidit, dixit 18.05.2012 22:25: > On Sex, 2012-05-18 at 18:35 +0200, Stanislav Ochotnicky wrote: >> I've been seeing this ugliness more and more to the point where I just >> can't keep writing individual emails. Repeat after me: git is not CVS. >> >> When you have 2 branches wit

Re: Stop the git abuse

Karel Zak venit, vidit, dixit 21.05.2012 12:43: > On Mon, May 21, 2012 at 11:52:40AM +0200, Michael J Gruber wrote: >> Just like we have mandatory packaging guidelines, we should have >> mandatory git guidelines simply because it is part of the build system, > > yep,

Re: Stop the git abuse

Stanislav Ochotnicky venit, vidit, dixit 21.05.2012 14:49: > Quoting Michael J Gruber (2012-05-21 11:52:40) >> Sérgio Basto venit, vidit, dixit 18.05.2012 22:25: >>> On Sex, 2012-05-18 at 18:35 +0200, Stanislav Ochotnicky wrote: >>>> I've been seeing this ugline

Re: Stop the git abuse

Greg Swift venit, vidit, dixit 21.05.2012 15:29: > On Mon, May 21, 2012 at 4:52 AM, Michael J Gruber > wrote: >> * put compatibility cludges for older releases on their respective >> branches (this gets rid of many if's in spec) > > i'm not against cleaning up

vim with Gnome integration: session restore support and vim-subpackage structure

Hi there, gvim as provided in the Fedora packages does not support session restore (i.e. reopening with the same buffers) because it does not integrate with the GNOME nor KDE desktop environments. Recompiling with gnome support helps: as a proof of concept, I've added a vim-gnome subpackage to th

Re: vim with Gnome integration: session restore support and vim-subpackage structure

Johannes Lips venit, vidit, dixit 04.07.2012 17:04: > On Wed, Jul 4, 2012 at 4:02 PM, Nathanael D. Noblet <mailto:nathan...@gnat.ca>> wrote: > > On 07/04/2012 03:04 AM, Michael J Gruber wrote: > > Hi there, > > gvim as provided in the Fe

pdftk retired?

I just git a "broken dependencies" notice for a package that I maintain. The reason is that "pdftk" got retired just the other day. I may have missed a corresponding post on fedora-devel, but I think a heads up notice to maintainers of depending packages may be in order before you retire a package

Man pages for multiple python versions

Hi there, I'm about to package gmpy2, a python extension module which succeeds gmpy without being upwards compatible. That's why it should be a new package rather than an update. The old gmpy is packaged as "gmpy" for python2 only. The new gmpy2 comes with sources which are intended for being bu

Re: qt (4) no longer injects $RPM_OPT_FLAGS by default (on f24+)

Rex Dieter venit, vidit, dixit 18.01.2016 15:00: > In response to recent additions to default $RPM_OPT_FLAGS that depend on > redhat-rpm-config to be present, and in response to bug > http://bugzilla.redhat.com/1279265 > > Qt4's qmake will no longer inject $RPM_OPT_FLAGS any more, starting with

Re: [ACTION REQUIRED v2] Retiring packages for Fedora 18

> Package qtparted (fails to build) That one is at 0.4.5 in the repo and at 0.6.0 upstream. Maybe getting the 0.6.0 to build is more promising? Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

xine plans

Hi there, I'm currently messing with xine-ui updates (sync with upstream 0.99.7, epel6 build, split out xine-check). There were some plans in the past to move all of xine to rpmfusion and, possibly, build more xine packages from the same spec. Is there any new development in this respect? Michae

Re: should I see a F18 branch?

Andrew Price venit, vidit, dixit 04.09.2012 01:43: > On 03/09/12 23:31, Neal Becker wrote: >> Ken Dreyer wrote: >> >>> On Mon, Sep 3, 2012 at 4:01 PM, Neal Becker wrote: fedpkg pull Already up-to-date. git branch f12 f13 f14 f15 f16 >>>

Re: Doc dir related changes coming up

Kevin Fenzi venit, vidit, dixit 07.08.2013 18:39: > On Tue, 6 Aug 2013 17:53:22 +0200 > Till Maas wrote: > >> On Fri, Jul 26, 2013 at 11:25:19AM +0300, Ville Skyttä wrote: >> >>> The special (pathless) %doc macro now installs docs to unversioned >>> /usr/share/doc/%{name} dir in Rawhide. Packages

Re: Doc dir related changes coming up

Michael J Gruber venit, vidit, dixit 08.08.2013 16:03: > Kevin Fenzi venit, vidit, dixit 07.08.2013 18:39: >> On Tue, 6 Aug 2013 17:53:22 +0200 >> Till Maas wrote: >> >>> On Fri, Jul 26, 2013 at 11:25:19AM +0300, Ville Skyttä wrote: >>> >>>> The

thunderbird-24.0.2 reverted - why? (Use the commit log..., Luke)

Hi there, I can see that thunderbird 24 had been built successfully and then reverted on the fc18 branch (and others). The git commit log and the spec changelog say Revert to 17.0.8 and nothing else. I do understand that more than a "successful build" is necessary for a package to be pushed, but

Re: thunderbird-24.0.2 reverted - why? (Use the commit log..., Luke)

Jan Horak venit, vidit, dixit 24.09.2013 16:00: > On 09/24/2013 10:16 AM, Michael J Gruber wrote: >> Hi there, >> >> I can see that thunderbird 24 had been built successfully and then >> reverted on the fc18 branch (and others). The git commit log and the >> s

Re: Moving xine-lib and dependent apps to RPM Fusion Free for F17?

Xavier Bachelot venit, vidit, dixit 13.10.2013 11:36: > Hi maintainers, > > On 01/05/2012 08:56 PM, Kevin Kofler wrote: >> (d) Move the whole thing (back) to RPM Fusion (where it originally was, >> before >> we started needing xine-lib for Amarok and Phonon, which both no longer >> use it

Re: Moving xine-lib and dependent apps to RPM Fusion Free for F17?

Xavier Bachelot venit, vidit, dixit 10.07.2013 10:58: > Hi, > > On 01/05/2012 08:56 PM, Kevin Kofler wrote: >> The following packages currently depend on xine-lib: >> * gxine >> * (k9copy – already in RPM Fusion, not affected) >> * kaffeine (my package, the reason why I maintain xine-lib in the fi

Re: Moving xine-lib and dependent apps to RPM Fusion Free for F17?

7;t be able to before mid August, though. Michael Xavier Bachelot venit, vidit, dixit 10.07.2013 12:34: > On 07/10/2013 11:57 AM, Michael J Gruber wrote: >> Xavier Bachelot venit, vidit, dixit 10.07.2013 10:58: >>> Hi, >>> >>> On 01/05/2012 08:56 PM, Kevin Kofler wr

Thunderbird security update for F24 locked in bodhi

https://bodhi.fedoraproject.org/updates/FEDORA-2016-e77b6d963a TB 45.3 fixes a few security issue. The update for F24 has karma +3 but is in locked stayed (sumbitted for testing), and has been so for several days. It's in testing for F23, in stable for F25. Is there anything to be done to unlock

New packager: Do the reviewer and the sponsor have to be the same

I would like to help this poor soul get his package into Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=860249 (adobe-source-code-pro-fonts) I'm a packager but no sponsor, he's no packager (so needs a sponsor). It's not clear to me whether I can just make a formal review and ask a sponsor t

Re: orphaning dblatex to allow a new maintainer

Alex Lancaster venit, vidit, dixit 24.01.2013 00:55: > Hi there, > > As I don't use this package much anymore, I am dropping back to > co-maintainership > and orphaning dblatex to let somebody else be the primary owner, see: > > https://admin.fedoraproject.org/pkgdb/acls/name/dblatex > > It's

Re: fedpkg: Change in git push method?

Josh Boyer venit, vidit, dixit 08.02.2013 18:56: > On Fri, Feb 8, 2013 at 12:54 PM, Thomas Moschny > wrote: >> 2013/2/8 Josh Boyer : >>> Yes, but fedpkg is currently relying on the existing git default, which >>> is matching. That is changing upstream in git, so fedpkg needs to set >>> a default

Intend to retire kde-plasma-daisy

Hi there this is a heads up notice that I intend to retire kde-plasma-daisy, the reasons being: - no upstream updates in almost 3 years - FTBFS in rawhide because there's no kde-workspace{-devel} - I don't use it myself. - Repackaging for Plasma 5 would probably require a new package plasma-da

Re: koji is broken

Ralf Corsepius venit, vidit, dixit 26.02.2015 19:09: > On 02/26/2015 06:44 PM, Matěj Cepl wrote: >> On 2015-02-26, 16:22 GMT, Ralf Corsepius wrote: That should be completely unrelated to the kojipkgs issue, as that is talking to the koji hub directly. >>> >>> And would you have the kindne

Re: Orphaned Packages in rawhide (2017-06-04)

I've taken over mupdf. I use mupdf myself and maintain a package which depends on mupdf (impressive - that is the package name ;) ); I've built mupdf on copr before (for early testing and such). I welcome comaintainers, especially for the EPEL6 branch, which I've taken over so that it doesn't fal

Re: PkgDB and the ArbitraryBranching Change

So, PkgDB now comes with a big fat warning saying: "Attention! PkgDB will be replaced during the week of July 10th, 2017. Please read the following for migration instructions: https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb"; If I go there I find no "migration instructions" what

Mass rebuild miss-tagged?

I got a message from buildsys about an unsuccessful tag which I hadn't initiated - probably left over bits from the F20 mass rebuild. Should I simply (re)build on master to try abd deal with that? Since fedpkg has no "scratch-head" command I'll settle for "scratch-build" next... Michael BibTool

Re: Mass rebuild miss-tagged?

.fp.o and myself The srpm builds in scratch: http://koji.fedoraproject.org/koji/taskinfo?taskID=6271675 Michael > On Mon, Dec 9, 2013 at 1:10 PM, Michael J Gruber > wrote: >> I got a message from buildsys about an unsuccessful tag which I hadn't >> initiated - probably

Re: SLA of Copr and changes in future

Miroslav Suchy venit, vidit, dixit 14.03.2016 23:01: > There is ongoing discussion on Fedora Infrastructure mailing list, that > only fully supported services should remain in fedoraproject.org domain. > All experimental services should be moved to fedorainfracloud.org. > Recently there was suggest

Re: Firefox 49.0.2

Martin Stransky venit, vidit, dixit 26.10.2016 11:42: > Thanks for pointing it here, I miss that minor update. Btw. a new #BZ at > bugzilla.redhat.com would work even better. > > There are two security bugs marked as "High" which means "Moderate" in > Fedora terms. The big ones has "Critical" ra

State of LuaTeX in F25/rawhide

Hi there, I have some strange doc-build failures in F25 and rawhide. The pertaining TeX-files work nicely with both pdfTeX and LuaTeX in F24 as well as with pdfTeX in F25. Upstream builds the doc with LuaTeX. Is LuaTeX in F25 known in to be in a working state? More specifically, I'm trying to bu

Re: State of LuaTeX in F25/rawhide

Avram Lubkin venit, vidit, dixit 28.11.2016 21:13: > On Mon, Nov 28, 2016 at 3:11 PM, Avram Lubkin > wrote: > > Forcing the pdftex driver gives an error about missing pdf primitives, > so this is most probably related to the removed pdf primitives in LuaTeX >

Re: Orphaned packages looking for new maintainers (75 to be retired)

Note that javapackages-tools provides jpackage-utils, so apparantly some of these reports are wrong. But it might be a good idea to update the requires instead of considering this a virtual (feature) provide. ___ devel mailing list -- devel@lists.fedora

Intent to orphan dblatex (asciidoc dependency)

This is to let you know that I intend to orphan dblatex. Background: dblatex depends on python 2 (https://bugzilla.redhat.com/show_bug.cgi?id=1737967) which will be retired in Fedora 32 (https://fedoraproject.org/wiki/Changes/RetirePython2). Some packages depend on dblatex directly, some indire

Re: Intent to orphan dblatex (asciidoc dependency)

> On Tue, Sep 3, 2019 at 9:37 AM Michael J Gruber wrote: > > Does this still apply with the new Python 3 port of asciidoc? > https://github.com/asciidoc/asciidoc-py3 Yes. asciidoc-py3 still calls dblatex which depends on python 2. Note that asciidoc-py3 is a port just to make curr

Re: Intent to orphan dblatex (asciidoc dependency)

Okay, just quickly two good news: - Nikola Forró has a patch that got me much further, there's hope for a working dblatex on py3! - Upstream showed life signs, I'll try to coordinate (and get patches upstreamed now or later once we have them ready). _

Re: Intent to orphan dblatex (asciidoc dependency)

Okay, more news: There's a repo for the porting efforts, with NF's and my patches combined and split into logical chunks: https://github.com/mjg/dblatex-py3 Let's hope upstream can work with that ;) There's a cor rep where I've built dblatex with py3, and where I am rebuilding all packages whic

Re: Defining the future of the packager workflow in Fedora

There is the current worklflow and the current mindset. One influences the other. For a long-time gitter, the prevailing Fedora packager mindset is still very much "dist-cvs". dist-git is often used as merely a tool to drive "dist-something", not so much as a vcs, and really rarely as a tool fo

Re: Strange hook in cloned package repositories

Alternatively, rpkg could ship the hook in a more central location (which has exec). This would allow you to set `core.hooksPath` for your fedpkg repos, maybe even automatically by using something like `git config includeif.gitdir:~/fedora/.path ~/.config/git/config.fedora` and putting the hook

%patchN deprecated?

Has `%patchN` been deprecated in favour of `%patch N`? I got a push by a proven packager to one of the packages which I maintain, commit subject and changelog entry "Fix deprecated patch rpm macro". It contains no explanation and no reference whatsoever. I didn't find any heads up notice, nor i

Re: %patchN deprecated?

Yes, I've figured this out meanwhile. I still see it as the proven packager's job to give some information before or at least while pushing a change that was neither announced, nor called for by a change proposal. As you point out correctly, the new syntax just landed in rpm 4.18 (F37 up), so t

Re: Fedora 38 Workstation boot time and memory improvements

> I didn't mention this in time to even discuss whether it'd make a good > addition to the release notes, but I think users will be happy to see > that Fedora 38 Workstation boots faster and uses less baseline memory > (measured from a session logged in to GNOME with only a terminal > applicati

Re: Fedora 38 Workstation boot time and memory improvements

> On 2023-04-14 01:28, Michael J Gruber wrote: > > > The boot time improvements came from removing iscsi from the critical > path.  There's no longer a dependency on network-online in the path to > graphical.target. > > The memory improvements came from allowin

Re: It’s time to transform the Fedora devel list into something new

How dare you - I'm glad you did :) Even though I'm a "mail/mailing list guy" using TUI MUAs, I found myself turning delivery off on many high volume MLs where the volume does not correspond to my contributor's frequency. I even read fedora-devel via hyperkitty's web interface, which is really s

Re: The new version of Fedora Messaging Notifications will arrive this week

Speaking of not obvious ... One starts with no rule at all. Does that mean no notifications? I.e., is include or exclude the default? A few templates might not hurt. Or is that what "tracking rule" means? Should we disable all rules on the old fmn, i.e. does the old one keep sending, or is it

Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

Makes a lot of sense and improves the information value of the version greatly. I'm just wondering whether the name suffix is the right place to put "flatpak" as if it were a subpackage - can we use the dist tag instead, say `fi39` for "fedora immutable based on fedora 39" or something like that

Re: F39 Change Proposal: Aspell Depreciation (Self-Contained Change)

> === BuildRequires === > repoquery -q --repo=rawhide{,-source} --whatrequires 'aspell*' | grep > -v '^aspell' | grep 'src$' | pkgname > ... > hunspell-az > > hunspell-csb > > hunspell-de > > hunspell-en > > hunspell-fa > > hunspell-gv > > hunspell-ky Apparantly, our spelling dictionaries

Re: LibreOffice packages

> Il 02/06/23 01:55, Sandro ha scritto: > I'm having a bad feeling about Fedora future lately, seeing all these RH > withdrawals from the project. That escalated quickly, yes. More worryingly: It escalated non-openly and non-collaboratively. > I hope to be wrong. But could Fedora survive the da

Re: LibreOffice packages

I've taken up hyphen and the orphaned hyphen-* packages. They don't appear to be high maintenance, but co-admins welcome, of course. Similarly, feel free to admin as co-admin to other hyphen-* in case something needs coordinations. The language packages are basically a "cp" in "%install", though

Re: LibreOffice packages

The main difference is that Fedora - be it rpms, flatpaks from module rpms (current state), flatpaks from whatever - comes with the promise of all the four F's, including freedom from legal issues as outlined in our guidelines. That enables RedHat to make the guarantees which they make for their

Re: Releasing package updates in multiple Fedora releases

> On Sun, Jun 18, 2023 at 09:16:28AM +, Mattia Verga via devel wrote: > > So one alternative is *not* to push the change to all branches. > > Unless it's really necessary, such as fixing an essential bug, I tend > to leave older Fedora branches on a stable release, to reduce churn Exactly. B

Re: What is Fedora?

> On 6/22/23 06:21, Gordon Messmer wrote: > > That's how I understand it well and I'm a bit confused what's the > "fuss" about. The git.centos.org mirrored sources that were used to build > CentOS. Since CentOS is no longer supported, and we have the CentOS Stream, > the same is > true - the sour

Re: F39 Change Proposal: LibuserDeprecation (System Wide)

> https://fedoraproject.org/wiki/Changes/LibuserDeprecation ... > == Scope == > * Proposal owners: Dropping the package, move it to EPEL eventually If it's not in Fedora it can't be in EPEL (once dropped), can it? There may also be a language issue here: Does the CP owner mean "possibly/maybe"?

Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week

I took care of lensfun, which was not quite as much fun as it sounds: https://src.fedoraproject.org/rpms/lensfun/pull-request/4 Could use a pair of critical python packager eyeballs, though ;-) ___ devel mailing list -- devel@lists.fedoraproject.org To

Re: SPDX Statistics

> false negative - especially > the *-fonts because they declare the license using macro, which I am unable > to process > (yet).| Can I put the new tags in the same macro, e.g.: ``` %global foundry ADF -%global fontlicense GPLv2+ with exceptions +%global fontlicense GPL-2

Re: Include minor version number in packaged Python shebangs

I'm wondering how you specify Python 3.8+ in the shebang ... If the EPEL 8 packages work with the EPEL 8 python then there is nothing to fix on the packaging side, really. For pip installs virtualenv or conda and the like seem to be the way forward, or adjusting their shebang to the non-default

Re: COPR and rpmautospec

I'm afraid you're not holding it right ;) %autorelease needs the git history, and you are building from dist-git, so that part is fine. But you are not using `Release: %autorelease` but, instead, there are additional tags in there. And - depending on your view on old vs. new version names - thi

Re: copr and centos9 ?

> The devel package are not included in CentOS repositories unless requested Yes, but Mark reports that his package builds "with EPEL, but not with CentOS". As for as I know, we have the following in copr: chroot "epel 9" has base RHEL9 and repos base+AppStream+CRB+Extras+EPEL chroot "centos str

Re: rpmautospec - how to add suffix to the current release and don't bump it right now

> On Tue, Jan 03, 2023 at 12:00:21PM +0100, Zdenek Dohnal wrote: > > My understanding — which may be not be the whole picture — is that this is not > supported by rpmautospec natively. Essentially, every spec file change is > _supposed_ to caused the Release number to grow, so by definition, a com

Re: TeXLive 2022 landing in rawhide today

First breakage seems to be here: https://koji.fedoraproject.org/koji/taskinfo?taskID=95811080 Related to lua loading of otf fonts ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Use cases for 'fedpkg scratch-build'

Yes, testing local changes with `srpm` is the main use case. I would even say that using `scratch-build` without `--srpm` is a typical mistake for new packagers - thinking they test before they push, when in effect they don't. Testing (scratch-building) the pushed head makes sense when there are

dnf ref-counting of identical files?

I have two packages which install identical files under the same name in the same locations (/usr/share/icons/hicolor/256x256/mimetypes/ and the like). `dnf install` does not warn about conflicts, `rpm -qf` shows both packages as owner, `dnf erase`ing one leaves the files in place, erasing the l

Re: Proposal: dnf should offer to update all of the dependencies of any package installed or updated

libsoup3 depends on libnghttp2.so.14 Apparantly, either libsoup3 should depend on the minor version (in addition to the major version), or libnghhttp2 should have bumped major, depending on the "history" of that symbol. Probably the former (API addition in a minor bump to the same major). _

Packaging portmidi versions: devel conflicts OK?

SHORT VERSION The portmidi library in Fedora is at version 217, which is quite old. Upstream changed to a new version scheme, currently at 2.0.4, and dumped some subpackages. To serve the needs of different other packages, it would be easiest for me (as the portmidi maintainer in Fedora) and them

Re: Packaging portmidi versions: devel conflicts OK?

> Il 03/03/23 19:00, Michael J Gruber ha scritto: > What about: > > - create a compat-portmidi0 package and move current portmidi there > (bonus: mark it as deprecated) > - change frescobaldi to require the compat package until a fix is available > - update current portmidi p

Re: Packaging portmidi versions: devel conflicts OK?

> On Sat, Mar 4, 2023 at 8:13 AM Michael J Gruber wrote: > > > Compatibility packages do not get a "compat-" prefix any more; they only > get a version suffix. The old portmidi could be portmidi217 (to match the > old versioning) or possibly portmidi0 (to mat

Re: Packaging portmidi versions: devel conflicts OK?

> I think so , see openssl example : > > dnf install openssl1.1-devel openssl-devel > > Package openssl-devel-1:3.0.8-1.fc37.x86_64 is already installed. > Error: > Problem: problem with installed package openssl-devel-1:3.0.8- > 1.fc37.x86_64 > - package openssl1.1-devel-1:1.1.1q-2.fc37.i686 co

soname bump: mupdf 1.24.6 coming to rawhide and f40

Hi there mupdf 1.24.x release branch received a series of bugfix releases which bumped soname. With 1.24.6 it appears to be about time to bring it to rawhide and F40 (from 1.24.2). I built mupdf in a side-tag, will rebuild dependencies myself or via PRs (qpdfview). Michael f41-build-side-92323

Re: Fedora Mass Rebuild 41 has completed

Am Mo., 29. Juli 2024 um 20:11 Uhr schrieb Tomi Lähteenmäki : > > On ma, heinä 22 2024 at 12.43.30 -07:00:00, Kevin Fenzi > wrote: > > The mass rebuild was done in a side tag (f41-rebuild) and moved over to f41. > Failures can be seen > https://kojipkgs.fedoraproject.org/mass-rebuild/f41-failur

Re: Fedora Mass Rebuild 41 has completed

Am Di., 30. Juli 2024 um 12:47 Uhr schrieb Alexander Ploumistos : > > One month ago, input-remapper was rebuilt for Python 3.13: > https://koji.fedoraproject.org/koji/buildinfo?buildID=2480729 > > The build was successful, even though in the build log there are some > "Logging errors" and the proba

Re: Early adopting EPEL 10 in Fedora Copr?

Neal Gompa venit, vidit, dixit 2024-08-15 16:14:30: > On Thu, Aug 15, 2024 at 9:45 AM Pavel Raiskup wrote: > > > > The epel-8-* and epel-9-* chroots in Fedora Copr are aliases > > to the "rhel+epel-*" chroots from `mock-core-configs` package. We'd > > like to have the same approach for `epel-10`

Re: Early adopting EPEL 10 in Fedora Copr?

Pavel Raiskup venit, vidit, dixit 2024-08-16 11:06:21: > On čtvrtek 15. srpna 2024 17:02:30, SELČ Michael J Gruber wrote: > > Neal Gompa venit, vidit, dixit 2024-08-15 16:14:30: > > > On Thu, Aug 15, 2024 at 9:45 AM Pavel Raiskup wrote: > > > > > > > > T

Re: Early adopting EPEL 10 in Fedora Copr?

Pavel Raiskup venit, vidit, dixit 2024-08-19 08:24:44: > Hello Michael, > > On pátek 16. srpna 2024 11:31:15, SELČ Michael J Gruber wrote: > > Pavel Raiskup venit, vidit, dixit 2024-08-16 11:06:21: > > > On čtvrtek 15. srpna 2024 17:02:30, SELČ Michael J Gruber wrote:

Re: how to create a rpm-autospec based package

Hello, Martin Gansser venit, vidit, dixit 2024-09-05 11:41:04: > Hello, > > I have created a new package pyliblo3.spec [1] and would like to know how to > create a rpm-autospec` based package from it. welcome to the club :) > If I use the following command > > [martin@fc40 SPECS]$ rpmautospec

Re: how to create a rpm-autospec based package

Martin Gansser venit, vidit, dixit 2024-09-05 13:20:16: > First i converting the specfile with: > > [martin@fc40 SPECS]$ rpmautospec convert pyliblo3.spec > Converted to %autorelease and %autochangelog. > > and then I create the src.rpm file with > > [martin@fc40 SPECS]$ rpmbuild -bs pyliblo3.s

Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week

Some packages may build with py 3.12 but not work with it if they don't have tests. For example, python-PyMuPDF fails when it tries to builds its documentation, but the error is in rst2pdf. If I disable doc creation then python-PyMuPDF builds against py 3.12 (and the tests succeed). I may have

Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week

Perfect! https://src.fedoraproject.org/rpms/rst2pdf/pull-request/2 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/p

Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

Kevin Kofler via devel venit, vidit, dixit 2023-07-11 12:49:10: > Oracle has (finally – the community projects Rocky and Alma were much > quicker to react) made an announcement about the situation: > https://www.oracle.com/news/announcement/blog/keep-linux-open-and-free-2023-07-10/ Thanks for the

Re: [Test-Announce] Kernel 6.4.3 is now available for testing in koji

Sumantro Mukherjee venit, vidit, dixit 2023-07-12 18:02:31: > Hey Folks, > > We are currently running the Fedora Kernel Test Week before we rebase > 6.4. There is a new > build 6.4.3 is fresh and you can now provide feedback! > Thanks a lot to all for making the test weeks so successful. The links

Re: dist-git: Diverging branches can't be fast-forwarded

Kevin Kofler via devel venit, vidit, dixit 2023-07-21 15:52:23: > Miroslav Suchý wrote: > > When I make SPDX statistics I have git checkout of all dist-gits and do > > git-pull every two week there. This morning I found that two times I got > > an error: > > > > hint: Diverging branches can't be f

Re: speed-dreams-2.3.0: how to handle bundled jar files in spec file ?

Am Di., 25. Juli 2023 um 10:19 Uhr schrieb Martin Gansser : > > Hi, > > i want to package the current version of speed-dreams 2.3.0, but i noticed > that jar files for the trackeditor are included in the package, but they > already exist in the system. Not really, there are two different things

Re: compilation of vdr-epgfixer on rawhide fails

Am Mi., 26. Juli 2023 um 10:36 Uhr schrieb Martin Gansser : > > Hi, > > the compilation of the package vdr-epgfixer fails on rawhide with the message > [1] > ... > install -D libvdr-epgfixer.so > /builddir/build/BUILDROOT/vdr-epgfixer-0.3.1-26.20180416git354f28b.fc39.x86_64/usr/lib64/vdr/libvdr-e

  1   2   3   4   >