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 the

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 with the nss

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

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 a pretty

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 spec changelog say Revert to 17.0.8

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). It

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

Re: Mass rebuild miss-tagged?

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 m...@fedoraproject.org wrote: I got a message from buildsys about an unsuccessful tag which I hadn't initiated - probably left over bits from

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:

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've seen

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 ke...@scrye.com 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

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

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 remote

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 packages

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 with

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, and also mailing list guidelines

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 ugliness more and more to the point where I just

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 michaeljgruber+gm...@fastmail.fm 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 ifs related

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

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 nathan...@gnat.ca mailto:nathan...@gnat.ca wrote: On 07/04/2012 03:04 AM, Michael J Gruber wrote: Hi there, gvim as provided in the Fedora packages does

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?

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 ndbeck...@gmail.com wrote: fedpkg pull Already up-to-date. git branch f12 f13 f14 f15 f16 * f17 master git

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:

Re: f15 koji buildroots broken?

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

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 packages

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 thomas.mosc...@gmail.com wrote: 2013/2/8 Josh Boyer jwbo...@gmail.com: Yes, but fedpkg is currently relying on the existing git default, which is matching. That is changing upstream in git, so

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 first

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

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 wrote: The following packages currently depend on xine-lib: * gxine

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 opensou...@till.name 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.

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 opensou...@till.name wrote: On Fri, Jul 26, 2013 at 11:25:19AM +0300, Ville Skyttä wrote: The special (pathless) %doc macro now installs docs

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

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 option you have. - FTBFS in rawhide because

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 kindness to tell me

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

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

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: 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

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

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"

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

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

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"

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

Re: GnuPG 2.2.0 and replacement of GnuPG1

Till Maas venit, vidit, dixit 04.09.2017 18:24: > On Mon, Sep 04, 2017 at 08:56:31AM +0200, Remi Collet wrote: > >> gnupg v2 is a nightmare for "server", I maintain some PHP extensions and >> libraries which works perfectly against v1, and not against v2 > > Would it be ok for you to patch the

Re: Removal of BuildRoot

No, that commit description was not helpful as it did not explain why you see a need to exert your proven packager privileges, nor the fact that this is a mass change. I had to go around and look for you and some info about your commit. Frankly, I hate it when I notice that someone is stepping

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

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: 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 --

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

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

bodhi: permission for updates from side-tags with packages from several maintainers

Hi there I have a side-tag into which several maintainers have built their packages successfully so that I can push a coordinated update. Now, when I try to submit that update, bodhi cli gives an unqualified auth error, and bodhi web tells me I need commit access for 2 of the 5 packages (I

Re: Orphaned packages looking for new maintainers

> Dne 21. 09. 20 v 18:37 Michael J Gruber napsal(a): > > > No, please not! It is just build dependency. I have orphaned the package > to have it removed from Fedora. May be I should have retire it instead, > but I wanted to give change if somebody have some real reason to h

Re: Orphaned packages looking for new maintainers

> The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life >

Re: jbig2dec 0.19

Please build in the side-tag to pick up the new jbig2dec/mupdf: fedpkg build --target=f34-build-side-30401 I guess we need to coordinate how far this gets merged down (f33, f32). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe

jbig2dec 0.19

There is a new version of jbig2dec which the new version of ghostscript requires. Given how previous updates went I intend to try a side-tag now. If you think your package is affected then please follow the discussion at: https://bugzilla.redhat.com/show_bug.cgi?id=1877889 Also, if there are

Re: jbig2dec 0.19

... this or build root overrides, but what about rawhide? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct:

Re: jbig2dec 0.19

Thanks for the input. I don't mind learning how to do this ;) Just to confirm that I picked the right path (from various I found documented): fedpkg request-side-tag --base-tag rawhide fedpkg build --target= .. and wait for all of us to the builds, before using: bodhi updates new --from-tag

Re: libcroco retired on Rawhide, breaking builds

In support of Kevin's statement: Out-of-source builds make sense if you want to build from the source multiple times, or if you want to ensure that the source is immutable (for the build process). None of this seems to be the goal of the Change which was motivated solely by general "you

Re: libcroco retired on Rawhide, breaking builds

It is tagged as f33-rebuild f33-updates-candidate now but not as f33 and bodhi does not know about it either. Is it possible/advisable to tag it as f33 directly to get the other rebuilds going again? ___ devel mailing list --

Re: libcroco retired on Rawhide, breaking builds

Well, that second mass rebuild made things worse for me. The time between the two was really short - we do need time to fix things (see below). The second rebuild not only forced us to rebase changes which were in QA (and rewrite the changelog because of date order stubbornness) but - what's

Re: Disable LTO for now ?

> On Wed, 2020-07-29 at 14:13 +0100, sergio(a)serjux.com wrote: > In general I want to have a very good > indicator the issue is LTO related before I > disable. THe build you referenced doesn't have any good indicators that LTO > is > the problem. > > For ppc64le is that the build was done with

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

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

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

Re: Highlights from the latest Copr release

Same today: ssh: connect to host 3.237.199.13 port 22: Connection timed out https://download.copr.fedorainfracloud.org/results/mjg/scribus/fedora-32-x86_64/01768969-scribus156/builder-live.log.gz Copr infra networked borked? ___ devel mailing list --

Re: Highlights from the latest Copr release

Builds seem to be failing right in the middle due to "broken ssh connections" again and again now. Maybe builders switching over one by one and taking build down? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: Highlights from the latest Copr release

Thanks for fixing it! I tried on irc, but I'm not an irc guy and couldn't make it past "cannot send to nick/channel" ... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora

Re: Orphaned packages looking for new maintainers (see note about xinetd)

> = NOTE about xinetd = > > Many packagers are listed as affected by xinetd. The dependency chain is: > > cvs (kasal, ppisar) > cvs-inetd.noarch requires xinetd > > git (amahdal, besser82, chrisw, pcahyna, pstodulk, skisela, tmz) > git.src

Re: Orphaned packages looking for new maintainers

> spec > actually provides a "tex-preview" package that is just preview.sty and > is used by several packages to do tex rendering and preview: > $ repoquery --repo=rawhide{,-source} --whatrequires tex-preview > Last metadata expiration check: 0:02:29 ago on Tue 18 May 2021 11:25:34 PM > BST. >

Re: Orphaned packages looking for new maintainers (a.k.a. the Return of the Javapocalypse)

> (The subject line referes to https://www.youtube.com/watch?v=E3418SeWZfQ) Made my day, thanks :) portmidi is affected, and so is python-pygame through portmidi. portmidi does not see any development to speak of but I don't see a direct replacemnt. I can build portmidi without java, though:

Re: /usr/include/c++/11/type_traits:3164:1: error: template with C linkage

I'm wondering, though, whether we have to fix a FTBFS on F34 (!) just a few days after the mass rebuild. The glib change which caused all this was pushed after the mass rebuild, basically rendering mute the point of the mass rebuild. In my case (notmuch) I got the notice from koschei - funnily

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

So, you list 3 typical reasons why packages in rawhide FTBFS and 2 existing policies which are meant to prevent 2 of these 3 reasons if packagers followed these policies. And you want these policies to be enforced technically What I am missing is: - A viable suggestion on how to prevent the

Re: Orphaned packages looking for new maintainers

adf-accanthis-fonts: Taken by mjg :) ___ 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/project/code-of-conduct/ List

Re: Orphaned packages looking for new maintainers

> portmidi mjg, orphan, xavierb 0 weeks ago Taking since I was co-maintaining anyways and maintain a dependency of portmidi. Though, anyone is welcome to take over. ___ devel mailing list --

Re: pdftk retired?

Depending on what you want to achieve, mupdf and its tools may be an option. Back then I switched impressive from pdftk to mupdf/mutool. It has python bindings, too. As for a "swiss army knife" command line utility, qpdf is very versatile if you don't mind the learning curve. There is a gui

rpmautospec release ccalculation

Hi there When trying to switch to rpmautospec I noticed some surprises in how autospec computes the next release. Environment: I run "rpmautospec" on Fedora 34 as a check before committing to dist-git. I converted one spec file so far, but IIUC "rpmautospec calculate-release" does not depend

Re: rpmautospec release ccalculation

> On Wed, Aug 11, 2021 at 4:08 PM Michael J Gruber wrote: > > I think these can be split into a different cases: > > - BibTool: spec: Release: 4%{?dist} verrel: BibTool-2.68-4.fc36 > calculate_release release: 6 > - adf-gillius-fonts: spec: Release: 2%{?dist} verrel: > a

Woah! [Thanks, Nest sponsors]

Today that special package for Nest participants arrived here. Back then I thought: "Nice, a few stickers." Today, after opening the package, I thought: "Woah!". [ No spoilers here ;) ] So, thanks to anyone who made possible Nest as well as this form of community appreciation! [posting it here

Re: Converting montserrat spec to new version

Have you managed to get this to work, or what is the particular issue? Seeing "%fontmeta" in there reminds me of the unbreaking which I did back then for adf-accanthis-fonts. The upshot was that a packager suggested new font packaging macros which required a change in rpm (or base macros,

Re: HEADS UP: Update to tesseract-5.0.0 in rawhide

> On 12/15/21 4:11 AM, Michael J Gruber wrote: > > Sorry to pile on but I somehow lost the original e-mail. > > "/usr/share/tessconfigs" seems to be missing so output to PDF or txt > fails with "read_params_file: Can't open txt" or "read_params_f

Re: HEADS UP: Update to tesseract-5.0.0 in rawhide

Now, depending packages seem to be broken. Have ypu pushed the side-tag incompletely, or does the new tesseract -3 bump soname again? https://bugzilla.redhat.com/show_bug.cgi?id=2033986 https://bugzilla.redhat.com/show_bug.cgi?id=2033984 https://bugzilla.redhat.com/show_bug.cgi?id=2033988

Re: Package owner required for ImageMagick

Sounds as if we need to keep ImageMagick 6.x for legacy reasons as long as it's safe to do so, but instead of switching to 7.x at some point, switching to GraphicsMagick is at most as much work if not less, but more future-proof? [Judging from the current state of upstreams which is subject to

Re: jpegxl soname bump

F35 updates has libaom-3.2.0-2 and libjxl-0.6.1-6 already - so did the buildroot go through? (This conflicts with heif from rpmfusion, which I can't complain about here, of course.) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe

Re: HEADS UP: Update to tesseract-5.0.0 in rawhide

Are you planning to bring these to F35, as well? Tesseract-5.0.0 appears to be mostly a bugfix release along with some other improvements, so I dunno (and haven't tested so far - the heads up was a few hours before the push). ___ devel mailing list --

Re: Possibly unexpcted soname change: liblept.so.5 -> libleptonica.so.5.4.0

> On 25.02.22 11:37, Mamoru TASAKA wrote: > > Apologies, my mistake, upstream uses different library names depending > on whether you build with autotools or cmake, and when switching to > cmake I accidentally only provided the compat symlink for the > unversioned link library, but not for the

Re: Possibly unexpcted soname change: liblept.so.5 -> libleptonica.so.5.4.0

So, I explicitely asked what your plan was and got no response. I suggested to fix the problem at the root package and you went ahead rebuilding depending packages. I asked you to use proper commit messages/changelog if you do and got a series of "Rebuild (leptonica)", "Bump as F36 needs

Re: Possibly unexpcted soname change: liblept.so.5 -> libleptonica.so.5.4.0

On 2022-03-03 15:47, Sandro Mani wrote: > > On 03.03.22 15:30, Michael J Gruber wrote: > > So, I explicitely asked what your plan was and got no response. > > > > I suggested to fix the problem at the root package and you went ahead > rebuilding depending packages.

dist-git force push

Hi there I know why we do not allow to force push to dist-git in the rpms namespace, but I am wondering whether we can implement this more in line with the reason: dist-git has to be a permanent record for the "source" (spec etc.) against which a package is built, but currently we deny pushing

Re: dist-git force push

> On Fri, Apr 1, 2022 at 4:27 PM Robbie Harwood wrote: > > Why not this then: > > - fedpkg commit -sc && fedpkg scratch-build --srpm && fedpkg push > && > fedpkg build > > Yes, it'll still take longer, but you won't need to context switch > unless the scratch build fails (which would make you

Re: List of long term FTBFS packages to be retired in March

Still the same fallout from that rage quit ... I wouldn't mind taking adf-tribun-fonts (I already have two from that foundry), but I'm really wondering whether we should package fonts which no other package depends upon: It's easy for users to install them directly, packaged versions do not

Re: CVE-2021-4034: why is pkexec still a thing?

I vaguely remember we had a move off consolekit at some point: In 2016, I moved "luckybackup" away from "beesu" (which uses consolekit) to "pkexec" (from polkit). We still have "beesu" in Fedora. Should I switch back? ;) Seriously, while it's worthwhile to ponder which approach tu use or avoid

Re: question about dnf5 upgrade output

Am Do., 7. Sept. 2023 um 14:02 Uhr schrieb Zbigniew Jędrzejewski-Szmek : > > I'm testing the upgrade to F39, and I see the following: > > Installing group/module packages: > tlwg-waree-fontsnoarch 0.7.3-9.fc39 fedora > 250.3 KiB >replacing

Re: F40 Change Proposal: KDE Plasma 6 (System Wide)

Am Mi., 13. Sept. 2023 um 23:29 Uhr schrieb Neal Gompa : > > On Wed, Sep 13, 2023 at 5:24 PM Fabio Valentini wrote: > > > > On Wed, Sep 13, 2023 at 11:19 PM Steven A. Falco > > wrote: > > > > > > A question about this - the removal of X11 is listed on a change proposal > > > for KDE. Does the

Re: FAS 2FA recovery keys?

Am Di., 12. Sept. 2023 um 11:22 Uhr schrieb Barry Scott : > > I have been updating my FAS account security. > When I setup 2FA I was not offer any recovery keys. You can register multiple OTP tokens: https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/2-factor/ > In the event that I lose

Re: Is this number ok?

Am Di., 12. Sept. 2023 um 20:28 Uhr schrieb Adam Williamson : > > On Tue, 2023-09-12 at 17:20 +, Alessio wrote: > > I know about this accepted change: > > https://fedoraproject.org/wiki/Changes/Color_Bash_Prompt > > > > But what is this number that appears time to time in the prompt? > > > >

  1   2   3   >