efl should be fixed in rawhide now.
~spot
On Wed, Jan 31, 2024 at 7:32 AM Michael J Gruber
wrote:
> Am Mi., 31. Jan. 2024 um 11:15 Uhr schrieb Marek Kasik >:
> >
> > Hi,
> >
> > On 1/30/24 12:15, Michael J Gruber wrote:
> > > Marek Kasik venit, vidit, dixit 2024-01-30 12:02:34:
> > >> Hi,
> >
spot merged a pull-request against the project: `perl-Wx` that you are
following.
Merged pull-request:
``
Remove unneeded complexity of the gtk requires hack
``
https://src.fedoraproject.org/rpms/perl-Wx/pull-request/3
--
___
perl-devel mailing list
Hi friends,
There are two new packages that need to be added to Fedora in order to
update Cura:
* asio-grpc - https://bugzilla.redhat.com/show_bug.cgi?id=2255630
* CuraEngine_grpc_definitions -
https://bugzilla.redhat.com/show_bug.cgi?id=2255633
These should be very easy reviews, asio-grpc is a
spot merged a pull-request against the project: `perl-MARC-Record` that you are
following.
Merged pull-request:
``
Package tests and format license to SPDX
``
https://src.fedoraproject.org/rpms/perl-MARC-Record/pull-request/1
--
___
perl-devel
spot merged a pull-request against the project: `perl-Devel-Cover` that you are
following.
Merged pull-request:
``
Add dependency to Perl version on which was build
``
https://src.fedoraproject.org/rpms/perl-Devel-Cover/pull-request/1
--
___
spot closed without merging a pull-request against the project:
`perl-Image-ExifTool` that you
are following.
Closed pull-request:
``
Update to 12.69
``
https://src.fedoraproject.org/rpms/perl-Image-ExifTool/pull-request/1
___
perl-devel mailing
spot commented on the pull-request: `Update to 12.69` that you are following:
``
Upstream for this one has asked us to track latest stable in CPAN, not latest
available.
Also, I am not a fan of %autorelease/%autochangelog.
``
To reply, visit the link below
spot merged a pull-request against the project: `perl-Net-SNMP` that you are
following.
Merged pull-request:
``
Remove deprecated Socket6 library
``
https://src.fedoraproject.org/rpms/perl-Net-SNMP/pull-request/1
___
perl-devel mailing list --
spot merged a pull-request against the project: `perl-SNMP_Session` that you
are following.
Merged pull-request:
``
Fix IPv6 functionality of SNMP_Session
``
https://src.fedoraproject.org/rpms/perl-SNMP_Session/pull-request/2
___
perl-devel mailing
spot merged a pull-request against the project: `perl-Tie-IxHash` that you are
following.
Merged pull-request:
``
Update license to SPDX format
``
https://src.fedoraproject.org/rpms/perl-Tie-IxHash/pull-request/1
___
perl-devel mailing list --
spot merged a pull-request against the project: `perl-Mail-Sender` that you are
following.
Merged pull-request:
``
Update license to SPDX format
``
https://src.fedoraproject.org/rpms/perl-Mail-Sender/pull-request/1
___
perl-devel mailing list --
spot merged a pull-request against the project: `perl-HTML-Tree` that you are
following.
Merged pull-request:
``
Update license to SPDX format
``
https://src.fedoraproject.org/rpms/perl-HTML-Tree/pull-request/1
___
perl-devel mailing list --
spot merged a pull-request against the project: `perl-File-Which` that you are
following.
Merged pull-request:
``
Update license to SPDX format
``
https://src.fedoraproject.org/rpms/perl-File-Which/pull-request/1
___
perl-devel mailing list --
spot merged a pull-request against the project: `perl-File-HomeDir` that you
are following.
Merged pull-request:
``
Update license to SPDX format
``
https://src.fedoraproject.org/rpms/perl-File-HomeDir/pull-request/1
___
perl-devel mailing list --
spot merged a pull-request against the project: `perl-PPI-Tester` that you are
following.
Merged pull-request:
``
Update Makefile.PL to not use Module::Install::DSL
``
https://src.fedoraproject.org/rpms/perl-PPI-Tester/pull-request/1
___
perl-devel
spot merged a pull-request against the project: `perl-SNMP_Session` that you
are following.
Merged pull-request:
``
Fix ipv6
``
https://src.fedoraproject.org/rpms/perl-SNMP_Session/pull-request/1
___
perl-devel mailing list --
Hi Fedora,
TeXLive 2023 (composed of texlive-base and texlive SRPMs) is in rawhide
now. I've done local testing to try to make sure it doesn't break anything
obvious... but the size and scope of TL means that there are probably still
some bugs introduced by this update.
Change wiki page here:
spot commented on the pull-request: `Rebuild with wxWidgets 3.2` that you are
following:
``
Ah, I see my mistake, I was looking at wxGTK3.
``
To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Wx/pull-request/2
___
perl-devel
spot closed without merging a pull-request against the project: `perl-Wx` that
you
are following.
Closed pull-request:
``
Rebuild with wxWidgets 3.2
``
https://src.fedoraproject.org/rpms/perl-Wx/pull-request/2
___
perl-devel mailing list --
spot commented on the pull-request: `Rebuild with wxWidgets 3.2` that you are
following:
``
I manually applied this, since it went out of sync with the mass rebuild.
I did notice that wxWidgets 3.2 doesn't seem to be in rawhide yet, you might
want to make sure you get that in there quickly or
spot merged a pull-request against the project: `perl-Alien-wxWidgets` that you
are following.
Merged pull-request:
``
Rebuild with wxWidgets 3.2
``
https://src.fedoraproject.org/rpms/perl-Alien-wxWidgets/pull-request/2
___
perl-devel mailing list
Please open a bug on this so I can track it.
Thanks,
~spot
On Sat, Jan 7, 2023 at 11:11 AM Orion Poplawski wrote:
> On 1/4/23 17:52, Tom Callaway wrote:
> > Hi Fedora,
> >
> > TeXLive 2022 (composed of texlive-base and texlive SRPMs) is landing in
> > rawhide today
Despite the size, I don't think TL updates have ever gone through that
process before. Not opposed to doing it though, do we need to revert those
builds from rawhide?
~spot
On Wed, Jan 4, 2023 at 10:26 PM Peter Robinson wrote:
> Hi Spot,
>
> > TeXLive 2022 (composed of texlive-base and texlive
Hi Fedora,
TeXLive 2022 (composed of texlive-base and texlive SRPMs) is landing in
rawhide today. I've done extensive local testing in mock to try to make
sure it doesn't break anything obvious... but the size and scope of TL
means that there are probably still some bugs introduced by this
spot merged a pull-request against the project: `perl-DBD-SQLite` that you are
following.
Merged pull-request:
``
Tests
``
https://src.fedoraproject.org/rpms/perl-DBD-SQLite/pull-request/2
___
perl-devel mailing list --
Apologies for the delays. My wife has been rather ill for a while, so my open
source time has been greatly minimized lately.
Fedora cannot use the default tarball due to legal restrictions. Additionally,
Fedora uses GCC (intentionally) which requires patch work for each release, but
improves
Updating libvpx in rawhide to 1.11.0 comes with an soname bump to 7.0.0.
Affected Fedora packages:
* baresip
* godot
* gstreamer1-plugins-good
* linphone
* qt5-qtwebengine
* seamonkey
* toxcore
* utox
* xpra
I'm doing a rawhide chain-build since all of these rebuild locally without
issue against
LAPACK & BLAS are going to 3.10.0 in rawhide. The sover on the shared libs
is still at .3, so it _should_ not break anything, but there is a history
of this not always being true.
Please file bugs if things stop building against LAPACK/BLAS.
Thanks,
~spot
I have landed rpmlint 2.0.0 in rawhide, along with Mirek Suchý's toml
configs (with updates for the licenses.toml). PRs, bug reports, and
suggestions welcome.
Thanks,
~spot
On Wed, May 19, 2021 at 6:55 AM Miroslav Suchý wrote:
> Dne 19. 05. 21 v 6:46 Michal Schorm napsal(a):
>
> * RPMLint
optimistic that the reported build failures will go away. If they do not,
you know what to do (either reply here, file new bugs, or add new info to
the existing ones).
Thanks for your help,
~spot
On Thu, May 27, 2021 at 8:43 PM Miro Hrončok wrote:
> On 27. 05. 21 23:17, Tom Callaway wr
Hi Fedorans,
Just a heads-up, texlive-base (where the compiled code and immediate
dependencies lives) and texlive (where the thousands of other noarch
components live) have been updated to TeXLive 2021 in Rawhide (and the
latest available components from CTAN at the time I did the work).
I've
FWIW, I have retired xmms. Upstream is long gone, and it was being held
together by spider-webs anyways.
~spot
On Wed, May 26, 2021 at 4:43 AM Peter Robinson wrote:
> On Tue, May 25, 2021 at 11:01 PM Michael Catanzaro
> wrote:
> >
> > On Sat, May 22 2021 at 09:23:23 AM +1000, Bob Hepple
> >
Hi Fedorans,
I've updated lapack to 3.9.1 in rawhide. This comes with several notable
changes:
1. I've moved to using the upstream build files, specifically, cmake. This
eliminates lots of ancient cruft in the Fedora lapack package that needed
to be redone by hand with every new release.
2. This
spot merged a pull-request against the project: `perl-Font-AFM` that you are
following.
Merged pull-request:
``
use NimbusSans-Bold font in test instead of phvr
``
https://src.fedoraproject.org/rpms/perl-Font-AFM/pull-request/3
___
perl-devel
This fork of cura has basically been abandoned by upstream, and the new
company that acquired Lulzbot has gone out of compliance with the source
code for the firmware. They have made it very clear that they have no real
interest in working with the community to improve this situation, and I no
Hi Fedorans,
With the consent of the maintainer, I updated bullet to 3.08 in Fedora 34
and Rawhide. I also am in the process of rebuilding the dependent packages
in Fedora (they all work fine for me in local rebuilds). gazebo and fawkes
are still going, but the others are done. There is also one
spot merged a pull-request against the project: `perl-HTML-Format` that you are
following.
Merged pull-request:
``
Correct dependencies
``
https://src.fedoraproject.org/rpms/perl-HTML-Format/pull-request/1
___
perl-devel mailing list --
Looks like VirtualGL was rebuilt:
https://koji.fedoraproject.org/koji/packageinfo?packageID=14293
~spot
On Mon, Dec 28, 2020 at 3:57 PM Miro Hrončok wrote:
> Dear maintainers.
>
> Based on the current fail to build from source policy, the following
> packages
> will be retired from Fedora 34
https://bugs.chromium.org/p/chromium/issues/detail?id=1164975
Please add in this info, it was on my TODO list, but clearly hasn't
happened yet.
~spot
On Wed, Jan 13, 2021 at 8:33 AM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:
> On Wednesday, 13 January 2021 at 03:14, Kevin
Based on my (admittedly extremely limited) understanding of things, this
seems correct as is:
#if defined(__x86_64__) || defined(__aarch64__)
case __NR_newfstatat: // fstatat(). EPERM not a valid errno.
#elif defined(__i386__) || defined(__arm__) || \
(defined(ARCH_CPU_MIPS_FAMILY) &&
Looks like this might be it. Running with --no-sandbox brings back the
strings. Is there a reference to how the stat calls should now be done?
Thanks,
~spot
On Fri, Jan 8, 2021 at 8:58 AM Florian Weimer wrote:
> * Tom Callaway:
>
> > This makes me very suspicious of something in g
), but I'm not sure where to look from here. Any
ideas?
~spot
On Sun, Jan 3, 2021 at 4:49 AM Mattia Verga via devel <
devel@lists.fedoraproject.org> wrote:
> Il 02/01/21 22:57, Kevin Kofler via devel ha scritto:
> > Tom Callaway wrote:
> >> I rebuilt chromium, but it did not r
I rebuilt chromium, but it did not resolve the issue.
~spot
On Wed, Dec 30, 2020 at 5:35 PM Marius Schwarz
wrote:
> Am 30.12.20 um 14:07 schrieb Mattia Verga via devel:
> > Il 30/12/20 10:14, Marius Schwarz ha scritto:
> >> Don't you need to recompile stuff first to have an effect? :)
> >>
>
I downgraded cairo to 1.16.0-9.fc33 and it had no effect, the bug remained.
Thanks,
~spot
On Thu, Dec 17, 2020 at 11:19 AM Kalev Lember wrote:
> On Thu, Dec 17, 2020 at 5:12 PM Tom Callaway wrote:
>
>> Okay, this one has me stumped. Any chromium package I build through
>&g
Certainly not ruling out glibc as the problem here, but if it was glibc, I
would think the problem would arise when I install the Fedora 33 build in
rawhide, and it does not...
~spot
On Thu, Dec 17, 2020 at 12:10 PM Robbie Harwood wrote:
> Tom Callaway writes:
>
> > I ca
the rawhide built chromium, it exhibits
the same missing strings bug.
~spot
On Thu, Dec 17, 2020 at 11:29 AM Robbie Harwood wrote:
> Tom Callaway writes:
>
> > Okay, this one has me stumped. Any chromium package I build through
> rawhide
> > refuses to rende
Okay, this one has me stumped. Any chromium package I build through rawhide
refuses to render most of the strings.
At first, I thought this was gcc 11, but then I noticed that the first
build with this problem was built before GCC 11 landed in rawhide (the
compiler was the same n-v-r as the one
spot merged a pull-request against the project: `perl-Class-DBI` that you are
following.
Merged pull-request:
``
Improve compatibility with EL8
``
https://src.fedoraproject.org/rpms/perl-Class-DBI/pull-request/1
___
perl-devel mailing list --
Filed as 1869884.
~tom
On Tue, Aug 18, 2020 at 5:38 PM Jeff Law wrote:
> On Tue, 2020-08-18 at 17:26 -0400, Tom Callaway wrote:
> > I don't know aarch64 assembly, but chromium (or more specifically, the
> ffmpeg part of chromium) is failing on aarch64 on F33+ (everywhere else
I don't know aarch64 assembly, but chromium (or more specifically, the
ffmpeg part of chromium) is failing on aarch64 on F33+ (everywhere else it
is fine):
obj/third_party/ffmpeg/ffmpeg_internal/videodsp.o: in function
`ff_prefetch_aarch64':
(.text+0x10): relocation truncated to fit:
This one is odd. Chromium is failing on aarch64 in rawhide, on a bit of
ffmpeg code that has not changed in _years_.
[clear_key_cdm:13/13] g++ -shared -Wl,--fatal-warnings -fPIC
-Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed
-Wl,-O2 -Wl,--gc-sections -rdynamic -o
Lmod needed a little patch to detect Lua 5.4 as a valid version, but it's
fixed and rebuilt in rawhide now (Lmod-8.3.17-2.fc33).
Thanks,
Tom
On Tue, Jun 30, 2020 at 6:24 PM Miro Hrončok wrote:
> On 30. 06. 20 19:34, Christoph Junghans wrote:
> > Adding
> > BuildRequires: lua-posix
> > doesn't
All of these are now fixed, except for lua-luv and lua-event. Lua-luv needs
a fixed cmake (FindLua.cmake needed patching to find Lua 5.4). I've been
trying to build a new cmake in rawhide all afternoon, but s390x fails to
get a buildroot established each time (not due to cmake issues). The
lua-luv
Okay. I duct taped lua-posix into a "working" state. Also did builds for
lua-argparse, lua-expat, lua-lpeg, and rpm (so that the macros say "5.4").
Any and all help is appreciated.
Tom
On Mon, Jun 29, 2020 at 4:37 PM Jerry James wrote:
> On Mon, Jun 29, 2020 at 2:34 PM Miro Hrončok wrote:
>
I just built lua 5.4.0 in Rawhide. As with previous major updates of lua,
the package also includes a copy of the lua 5.3 libraries so that rawhide
does not just become broken reps. If you depend on lua, please rebuild your
packages in rawhide and let me know if you run into any issues.
Thanks,
Hello Fedorans,
It is my intent to revive R-AnnotationDbi, as it is needed to update
R-biomaRt. I've already done the review request here:
https://bugzilla.redhat.com/show_bug.cgi?id=1845360
Thanks,
Tom
___
devel mailing list --
There are some new subpackages (and some old ones went away), but
since every package had the release value bumped, this is expected.
Tom
On 2020-05-27 at 00:52, ke...@scrye.com wrote:
> On Tue, May 26, 2020 at 05:05:32PM -0700, Adam Williamson wrote:
> ...snip...
>
> > there is, IIRC, supposed
Perhaps graphite2 generates a .tex file as part of the process? I'd have to
look at it to figure it out. Can you please open a bug on the 300+ package
increase with the specifics so I can figure out what (if anything) I can do
to remedy this?
Thanks,
Tom
On Fri, May 22, 2020 at 12:16 PM José
file, everything is fine and the
> command mentioned above works.
>
> The strange thing is that when I install python3-matplotlib from koji repo
> or from rawhide repo, both don't bring this package so it's probably a new
> dependency somewhere.
>
> Do you know what might caus
I think the issue here is that the most recent texlive package fixes landed
this morning, and the "rawhide" compose that mock would pull in doesn't
have all the fixes yet.
Tom
On Wed, May 20, 2020 at 3:12 PM Richard Shaw wrote:
> On Wed, May 20, 2020 at 2:08 PM Tom Callaway wr
Tom Callaway wrote:
> It's probably not the same bug, that error is a fairly generic error
> meaning "something has made texlive unhappy". I'm investigating.
>
> Tom
>
> On Wed, May 20, 2020 at 1:29 PM Richard Shaw wrote:
>
>> Thanks for the PR but it looks
It's probably not the same bug, that error is a fairly generic error
meaning "something has made texlive unhappy". I'm investigating.
Tom
On Wed, May 20, 2020 at 1:29 PM Richard Shaw wrote:
> Thanks for the PR but it looks like I'm being bitten by:
>
>
Richard,
I've got a PR for you that adds your explicit tex BuildRequires so that
this works again:
https://src.fedoraproject.org/rpms/OpenColorIO/pull-request/1
Upstream TeXLive sometimes moves .sty files around, so in most cases, it is
easier to specify BuildRequires using the
; On 5/14/20 3:55 PM, Tom Callaway wrote:
> >> I've just kicked off new builds for texlive and texlive-base for
> >> TeXLive 2020 in rawhide. Hopefully, everything that depends on them
> >> will continue to work, but if you notice any new issues generating
> >&
I'll get that fixed up first thing tomorrow.
Apologies,
Tom
On Thu, May 14, 2020, 6:51 PM Miro Hrončok wrote:
> On 14. 05. 20 23:55, Tom Callaway wrote:
> > I've just kicked off new builds for texlive and texlive-base for TeXLive
> 2020 in
> > rawhide. Hopefully, every
Just need that texlive build to finish and it should all clear up.
Tom
On Thu, May 14, 2020 at 6:13 PM Jerry James wrote:
> On Thu, May 14, 2020 at 3:56 PM Tom Callaway wrote:
> > I've just kicked off new builds for texlive and texlive-base for TeXLive
> 2020 in rawhide. Hopefully
I've just kicked off new builds for texlive and texlive-base for TeXLive
2020 in rawhide. Hopefully, everything that depends on them will continue
to work, but if you notice any new issues generating docs (or any missing
components or broken dependencies), feel free to email me or open Bugzilla
PM Lennart Poettering
wrote:
> On Mo, 13.04.20 09:56, Tom Callaway (tcall...@redhat.com) wrote:
>
> > C) Chromium's build process gets...angrier. Still doable, but you have to
> > do things like set ulimit -n 4096. (Fun fact: the man page section for
> > ulimit says that
On Mon, Apr 13, 2020 at 11:54 AM Kevin Kofler
wrote:
> Tom Callaway wrote:
> > So, you might be asking, why does Fedora build in shared mode? There are
> > two main reasons:
> > 1) To enable users to be able to swap out the media components from
> Fedora
> &
rs
> > when not doing benchmarks? That sounds weird.
> >
> > On Mon, Apr 13, 2020 at 9:56 am, Tom Callaway
> > wrote:
> > > This is my dilemma. (It is not my only dilemma, nor my most pressing,
> > > but it is still mine.) That said, I would love to get in
Hi Fedorans,
Here's the situation:
Recently, someone filed a bug against chromium, noting that it was
benchmarking notably slower than Google Chrome or chromium-freeworld (from
rpmfusion). I tested locally and confirmed it. They suspected that Fedora's
optflags were to blame, but since chromium
Confirmed, that gcc builds a working chromium. Thank you so much.
Tom
On Thu, Mar 12, 2020 at 6:39 AM Jakub Jelinek wrote:
> On Mon, Mar 02, 2020 at 08:57:46AM -0500, Tom Callaway wrote:
> > Wait, I know that $TOPIC is scary, come back.
> >
> > Chromium h
licitly permitted in C++17 (and that it was implicitly
permitted with this hack in C++14), it feels like this is a regression.
Nevertheless, I would appreciate any help in resolving this so that we have
a working Chromium in Fedora 32.
Thanks in advance,
Tom
On Mon, Mar 2, 2020 at 9:16 AM
Wait, I know that $TOPIC is scary, come back.
Chromium has this chunk of code (in
third_party/angle/src/common/PackedEnums.h):
// This horrible const_cast pattern is necessary to work
around a constexpr limitation.
// See https://stackoverflow.com/q/34199774/ . Note
Yes, I did. Apologies.
Tom
On Fri, Jan 31, 2020 at 8:41 AM Michael Catanzaro
wrote:
> On Fri, Jan 31, 2020 at 8:37 am, Tom Callaway
> wrote:
> > * There are significant improvements in the gstreamer0.10 branch
> > (which is separately packaged and maintained in Fedora)
>
Since I've moved my last dependent package off of this old stack, I've
retired gstreamer & gstreamer-plugins-base in rawhide (again).
Before reviving these poor and tired packages, please consider the
following:
* Upstream is not maintaining this code branch anymore.
* There are significant
FWIW, I am investigating the geolite2 license situation with Red Hat.
Thanks,
Tom
On Mon, Jan 6, 2020 at 4:45 PM Dave Dykstra wrote:
> I see that currently Fedora rawhide gets new geolite2-*-YYYMMDD packages
> (e.g. geolite2-city-20191217) each month in order to distribute the free
> maxmind
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
The only living packages from this list without current f31 or rawhide
builds:
elasticsearch (gradle hellscape)
expresso (abandoned upstream)
infinispan (lots of deps orphaned)
shim-unsigned-aarch64 (will let pjones handle)
shim-unsigned-x64 (will
I fixed dnssec-nodes (and dnssec-tools), gnomint, lilyterm,
rubygem-connection_pool, rubygem-session, target-isns, tcmu-runner,
telepathy-gabble, and telepathy-salut in rawhide. I thought about fixing
elasticsearch, but there is not enough alcohol for me to touch a gradle
package.
Thanks,
Tom
On
Hi Fedorans,
With the new upstream release of 2.1, the Fedora scalapack package in
rawhide is switching over to use the upstream provided cmake infrastructure
(instead of the Makefiles I built many years ago). As a result, there is no
longer a separate libmpiblacs library, but all of the symbols
I'm claiming (and fixing FTBFS) on busybox and sqlite2.
https://pagure.io/releng/issue/9009
https://pagure.io/releng/issue/9010
Thanks,
Tom
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
I could use a quick review for a new R package: R-Rhtslib
https://bugzilla.redhat.com/show_bug.cgi?id=1767062
Can do a review or other packaging/legal/license favors in trade.
Thanks,
Tom
___
devel mailing list -- devel@lists.fedoraproject.org
To
Never mind. I was confused by the fact that epel-8 kicks off two builds for
some reason. Looking in the wrong log. Now I get to figure out why
gnome-keyring-devel doesn't exist in EPEL8.
Tom
On Fri, Sep 6, 2019 at 11:12 AM Tom Callaway wrote:
> Building chromium-76.0.3809.132-3.el8 for ep
Building chromium-76.0.3809.132-3.el8 for epel8-candidate
Created task: 37499863
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=37499863
It fails with:
37499910 buildArch (chromium-76.0.3809.132-3.el8.src.rpm, x86_64): open (
buildhw-03.phx2.fedoraproject.org) -> FAILED:
I'm going to revive torque (one of my packages depends on it). Looks like
it was abandoned by the old maintainer, but the fix to get it building
again was trivial (missing a tex BuildRequires).
If there are any reasons not to, speak up, please.
Thanks,
Tom
I'm hoping that this one hasn't been dead for 8 weeks, because all it needs
to get it building again is to disable the gtk-doc generation...
I don't really want to own it, but I have dependent packages, so if no one
else does, I will claim it.
If you want it (or know of some reason it shouldn't
I think this is what you want:
%global optflags %(echo %{optflags} | sed 's/-Wp,-D_GLIBCXX_ASSERTIONS / /')
Tom
On Fri, Aug 2, 2019 at 11:00 AM Steven A. Falco
wrote:
> The upstream KiCAD project has requested that I remove GLIBCXX_ASSERTIONS
> from the Fedora package, as described here:
>
One of my packages (alienarena) fails to build in rawhide on s390x (and
only that arch), but the build log shows it never even starts. When I look
at the root log, I see this:
DEBUG util.py:585: BUILDSTDERR: error: unpacking of archive failed on file
instead:
https://copr.fedorainfracloud.org/coprs/lantw44/arm-linux-gnueabi-toolchain/
~tom
On Wed, Nov 7, 2018 at 11:02 AM Tom Callaway wrote:
>
>
> On 11/7/18 11:00 AM, Tom Callaway wrote:
> > A few years ago, I packaged up glibc-arm-linux-gnu, so that Fedora could
> > have
Hey, remember when I said I would keep v8-314 alive? I've changed my mind.
Why?
A) It is seriously old. I'm not sure I want to encourage anyone to try to
use it at this point.
B) Upstream v8 looks NOTHING like this package anymore
C) It doesn't build anymore because the giant SConstruct goop it
be it.
~tom
On Wed, Mar 13, 2019 at 10:37 AM Jakub Jelinek wrote:
> On Wed, Mar 13, 2019 at 10:28:29AM -0400, Tom Callaway wrote:
> > I tried removing some of the compiler flags to see if I could identify
> what
> > might be triggering this, and removing "-fno-del
n Mon, Mar 11, 2019 at 1:31 PM Jakub Jelinek wrote:
> On Mon, Mar 11, 2019 at 01:16:07PM -0400, Tom Callaway wrote:
> > I spent some time this weekend trying to get Chromium 72 building on
> > Fedora, but I kept running into a C++ issue that I was not able to
> resolve.
> >
FWIW, I did. There is no fix there.
~tom
On Mon, Mar 11, 2019 at 1:20 PM Vascom wrote:
> Look at chromium-vaapi build in rpmfusion.
>
> пн, 11 мар. 2019 г., 20:17 Tom Callaway :
>
>> Hi folks,
>>
>> I spent some time this weekend trying to get Chromium 72 bui
Hi folks,
I spent some time this weekend trying to get Chromium 72 building on
Fedora, but I kept running into a C++ issue that I was not able to resolve.
This happened with gcc-9.0.1-0.8.fc30.x86_64 and gcc-8.3.1-2.fc29.x86_64.
Here's a sample of the error (it happens in a few places), from
On 2/6/19 8:28 PM, Mamoru TASAKA wrote:
> I don't know well about R, however that is probably because R-core
> (-3.5.3-4.fc30) package already
> requires librt.so on x86_64, i686, etc, while on aarch64 and ppc64le, it
> does not, which probably indicates
> that on x86_64, i686, etc R binary is
One of my packages failed the mass rebuild, but only on ppc64le and
aarch64. The error they both hit is this:
Error: package or namespace load failed for 'BiocParallel' in
dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object
spot merged a pull-request against the project: `perl-Alien-wxWidgets` that you
are following.
Merged pull-request:
``
Remove BR on wxGTK as it is about to be retired
``
https://src.fedoraproject.org/rpms/perl-Alien-wxWidgets/pull-request/1
___
Bad License" list to include SSPLv1. No software
under that license may be included in Fedora (including EPEL and COPRs).
Thanks,
Tom Callaway
Fedora Legal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-l
When I wasn't looking, asymptote grew a new dependency, which means I
have two new packages that need reviews.
python-speg: https://bugzilla.redhat.com/show_bug.cgi?id=1663036
python-cson: https://bugzilla.redhat.com/show_bug.cgi?id=1663037
They're very small, very simple packages. Should take
spot canceled a pull-request against the project: `perl-Email-MessageID` that
you are following.
Cancelled pull-request:
``
Remove unneeded requirement
``
https://src.fedoraproject.org/rpms/perl-Email-MessageID/pull-request/1
___
perl-devel mailing
1 - 100 of 1059 matches
Mail list logo
