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
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
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
> 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
> 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
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 -
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
> 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
Adding to what Vitaly has said:
The other question is where you get those signatures from. If upstream does not
sign tarballs any more then there is nothing to check, sadly.
In a source-git based workflow, or if you roll your own using rpkg or such, you
have the upstream source available so
I guess there's (at least) two ways to understand "stable":
- things don't break
- things don't change
(... unless absolutely necessary, in each case)
To me, "things don't break" describes Fedora stable releases (as opposed to
rawhide), and "things don't change" describes RHEL.
A typical
While it is annoying to spell out each file it does catch package changes which
might go unnoticed otherwise. In particular, we've had a few unannounced soname
changes and such lately. [Disclaimer: I have not checked whether the maintainer
ignored the build failure for an explicit soname or got
Thanks!
I would have been happy with the first reply already, but either it wasn't
there yet or my question was posted late, which in a sense is the same, of
course :)
Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
Is there a quick way to see what changed (in terms of package versions) between
different RC composes?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
With this libxml2 update:
```
gm convert -list format
...
gm convert: Unable to load module
("/usr/lib64/GraphicsMagick-1.3.38/modules-Q16/coders/url.la: file not found")
```
In fact, `url.so` is there but cannot be dlopen'ed. This works after
downgrading libxml2 to 2.9.
I noticed because my
In this context, since we are still in freeze:
Can dnf distinguish between updates in testing and updates in testing submitted
for stable?
People might want to dist-upgrade to F37 now (I'm not critizing the release
decision) and want to get "the same updates as on F36". Ideally, no F36 package
Did this work fine for python 3.11 in Fedora 37? Asking for a friend ...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
Thanks for the clarification. (I was quite thrown off by f26 until I realised
it as a potential typo.)
It's always disappointing to see packages go FTI as a result of other upgrades.
So, if you are packager, cloning the dist-git repo and filing a merge request
would be the easiest option (for
Can you give a bit more context about what you are trying to achieve?
A quick look at mailman3 and postorius in fedora dist-git reveals that they
were retired from rawhide/f37 because they do not build against python 3.11.
So, a minor update on f36 (which still has python 3.10) is not really
> On Tue, Oct 18, 2022 at 10:43 PM Ben Cotton
>
> Neal, Matt, what is the rationale for enabling persistence for the default
> boot option? I have mixed opinions about this. One of the benefits of a
> Live image, as we use it today, is that it's always the same/fresh. If I
> use it and then
Thanks for all your work!
Dropping pantheon is not the only fallout of GNOME's schedule around our
release. (I do understand why we wanted it in.)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
You do have to admit that this happens only as a result of:
- wanting to support EOLed chroots
- not wanting to support non EOLed chroots (for those projects)
- not receiving notification e-mails
- not logging onto the web UI for more than 75 days
All of this in combination, and knowingly, as
> Oh, also I forgot to mention...
>
> If your sidetag is deleted, you can just request a new one, tag the old
> builds back into it and be back in business. I realize that that could
> be anoying if you told people a specific one and then had to make a new
> one, but it's not like those builds
> On Wed, Sep 28, 2022 at 1:15 PM Michael J Gruber wrote:
>
> Let's talk for a moment here about this. I'm going to give you some
> "inside baseball" (or at least as much as I can). I can tell you up
> front that ffmpeg in Fedora is *entirely* my fault.
Thanks for the
> As one of the people that has previously generated one of the hobbled
> tarballs you consider a potential trust issue: The hobbled tarball is the
> upstream tarball for the particular release we ship after we extract it, run
> ./hobble-openssl (which you’ll find in the package) and repack it.
>
> Note that depending on the legal outcome mesa might have to go the hobbled
> route, too:
> simply disabling the codecs in %build does not change anything about
> redistributing the
> source.
... or may not, if it's only about the hardware implementation, in which case I
would suggest merely
As Fedora users and contributors, we profit a lot from everything that RedHat
provides to the Fedora project, be it infra, people-power or "leverage"
(talking to vendors etc.). In turn, RedHat can expect a certain amount of
understanding from "us" for their business interests, which include
> - zathura-pdf-mupdf-0:0.3.9-1.fc36 > zathura-pdf-mupdf-0:0.3.8-8.fc37
Missed bodhi activation point, sorry. Built in koji but not submitted to bodhi.
Done now (with the usual wait for stable).
https://bodhi.fedoraproject.org/updates/FEDORA-2022-967bda05d8
If you test upgrades from f36 to f37 currently, you get:
webkit2gtk4.0.x86_64 2.37.91-1.fc37 replaces webkit2gtk3.x86_64 2.36.7-1.fc36
webkit2gtk4.1.x86_64 2.37.91-1.fc37 installed as upgrade
webkit2gtk5.0.x86_64 2.37.91-1.fc37 installed as upgrade
That surely is confusing, unless you've been
> On Mon, Sep 5, 2022 at 2:01 PM Sandro
>
> pyproject does not work well, and is not backwards compatible. This is
> particularly a problem for EPEL ports from Fedora. Personally, I'd
> like to see it fixed for EPEL before relying on it for anything in
> Fedora.
The current py packaging
Funny observation:
- take up an orphaned package
- refresh dashboard
- see the package listed in your dashboard as "directly owned" as well as
"orphaned ... ago" (red warning)
Obviously, different parts of the aggregated information is aggregated on
different schedules ...
> Hi,
>
> I want to start qarte-5.1 on Fedora 37, but the startup aborts
> with the following error message:
>
> $ qarte -d
> 16:06:00: INFO - qarte Qarte-5.1.0
> 16:06:00: INFO - qarte Python 3.11.0rc1 on
> Linux-5.19.1-300.fc37.x86_64-x86_64-with-glibc2.36
> 16:06:00: INFO - qarte File system
> On 26. 07. 22 17:15, Michael J Gruber wrote:
>
> I don't think so:
>
> https://src.fedoraproject.org/rpms/redhat-rpm-config/c/1926c37598951ae307...
>
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1968550
>
> https://bodhi.fedoraproject.org/updates/FED
> Next failure is portmidi due to "Drop_i686_JDKs"
> https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs
>
> I don't know how I missed that change proposal. I cannot even make sense of
> the
> English in those template mails (never got any myself). This is going to be a
> lot of fun
> ...
Next failure is portmidi due to "Drop_i686_JDKs"
https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs
I don't know how I missed that change proposal. I cannot even make sense of the
English in those template mails (never got any myself). This is going to be a
lot of fun ...
notmuch failed to build from source because of a strange test suite failure on
ppc64le:
https://koji.fedoraproject.org/koji/taskinfo?taskID=89837091
The only failing test is a pytest run on the bindings
```
T391-python-cffi: Testing python bindings (pytest)
FATAL:
> On Wed, Jun 29, 2022 at 7:37 PM Vipul Siddharth
>
> Given that flathub provides similar / overlapping content compared to
> RPMFusion (or often, even more "legally problematic" than what's
> available from RPMFusion, i.e. prebuilt blobs), doesn't this same
> reasoning also apply there? I.e.
So, thanks to the good and fast review sfsexp is in rawhide now. Hooray!
It turns out that bodhi applies the same boundary conditions to "newpackage"
updates (no karma for your own update, 7 days minimum to stable by time). I
don't think a new leave package can disturb current systems much ...
>
> I also think that every package change (including rebuild) must be
> tracked in changelog.
I think that convolution is at the very heart of the problem:
As it is, dist-git tracks "packaging sources", i.e. spec and source hashes or
files, and this determines the content of the src.rpm and
... so fi you click on "send" a second time (in hyperkitty) because the 1st
time appeared to have no effect (no reaction, no browser indication, just the
form sitting there) you can send the message twice. Oh well. Patience ;-)
___
devel mailing list
mupdf 1.20.0 is coming to rawhide in side-tag f37-build-side-54574.
As always, I coordinate this with the maintainers of zathura-pdf-mupdf and
python-PyMuPDF directly via PRs (but I may have missed some indirect
dependency).
___
devel mailing list --
mupdf 1.20.0 is coming to rawhide in side-tag f37-build-side-54574.
As always, I coordinate this with the maintainers of zathura-pdf-mupdf and
python-PyMuPDF directly via PRs (but I may have missed some indirect
dependency).
___
devel mailing list --
Am Mo., 20. Juni 2022 um 12:08 Uhr schrieb Miro Hrončok :
>
> On 20. 06. 22 11:57, Michael J Gruber wrote:
> > I recently took over py3status from orphanage and tried a scratch build
> > against the side tag. The results are somewhat surprsing (to me):
> >
> > ```
Hi
> I've now merged the side tag. Remarks:
...
> - python-PyMuPDF test fail due to a corrupted double-linked list
> assertion. I've disabled the test for now, and will investigate further.
> - python-fiona test fail due to a segmentation fault. I've disabled the
> test for now, and will
I recently took over py3status from orphanage and tried a scratch build against
the side tag. The results are somewhat surprsing (to me):
```
DEBUG util.py:443: Error:
DEBUG util.py:443: Problem: conflicting requests
DEBUG util.py:443:- nothing provides python(abi) = 3.10 needed by
https://bugzilla.redhat.com/show_bug.cgi?id=2095717
This is an optional dependency of notmuch, the mail indexer. sfsexp enhances
notmuch's capabilities considerably.
Feel free to suggest a review swap within my capabilities (say C/Python).
Cheers
Michael
> On Thu, Jun 9, 2022 at 3:32 PM David Sommerseth wrote:
>
> I'm surprised that the EPEL 9 chroots haven't switched to RHEL 9 yet.
> We've had RHEL 9 + EPEL 9 configs for almost a month now...
>
> Pavel, do you know when they're going to be deployed to COPR?
Also, there seems to be a general
Thanks Ben, you are completely right:
Basically, the generated doc is the website. And besides the weird feeling of
packaging a website, it comes with all the problems that you pointed me to
(bundling jquery, licenses).
So, even though I had gotten `mkdocs-simple-hooks` to build meanwhile,
py3status looks like a nice i3status provider, which is why I have looked into
taking the orphaned package.
Alas, the package needs an update from 3.34 (as packaged) to 3.44 (as current).
In between these versions, the doc build chain changed from sphinx to mkdocs.
Upstream uses the plugin
> On 26. 04. 22 17:50, Michael J Gruber wrote:
>
> And by unchanged spec file, you mean by updating the package to a new version
> and not changing anything else, or literally by building the same package
> version again? Because the rpminspect logs assume you updated it.
The
Hi there,
with an unchanged spec file, I'm getting some new errors from rpminspect now.
That's why I'm wondering whether something has changed or I've missed a change
to be followed in spec. There are two issues:
Auto-generated library dependencies (f35 f36 f37):
> 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
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
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.
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
> 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
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
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
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
> 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
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 --
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
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
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,
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
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
> 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
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
> 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.
>
> (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:
> 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 --
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
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
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
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
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 --
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
> = 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
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
> 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
> 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
>
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
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
... 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:
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
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
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 --
> 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
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
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
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
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
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
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
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).
> 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
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
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 --
Hi there
I have rebuilt
https://apps.fedoraproject.org/packages/portmidi
with cythonizing during build rather than using the project-shipped ancient
cython output. Is this change supposed to trickle down to F30? (The package
itself needs to go away sooner or later anyways.)
MIchael
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
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
101 - 200 of 247 matches
Mail list logo
