Re: poppler soname bump in Rawhide soon

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

New packages needed to update cura

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

TeXLive 2023

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

Re: TeXLive 2022 landing in rawhide today

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

Re: TeXLive 2022 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

TeXLive 2022 landing in rawhide today

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 update.

Re: Chromium security bugs remain unfixed for > 1 month

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 th

libvpx soname bump 6.3.0 -> 7.0.0

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

Bumping lapack to 3.10.0 in rawhide

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 _

Re: RPMLint 2.0 released!

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 inclu

Re: texlive 2021 landing in Rawhide

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

texlive 2021 landing in Rawhide

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 don

Re: Let's retire original glib and gtk+

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

New lapack packages in rawhide

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

Orphaning the cura-lulzbot package set

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 long

Bullet update (sover bump)

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 d

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

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 ap

Re: Chromium built in rawhide does not render most strings

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 K

Re: Chromium built in rawhide does not render most strings

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) && def

Re: Chromium built in rawhide does not render most strings

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

Re: Chromium built in rawhide does not render most strings

), 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

Re: Chromium built in rawhide does not render most strings

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

Re: Chromium built in rawhide does not render most strings

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

Re: Chromium built in rawhide does not render most strings

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 cannot

Re: Chromium built in rawhide does not render most strings

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 render most of th

Chromium built in rawhide does not render most strings

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 in

Re: chromium/ffmpeg fails on aarch64 in F33+

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

chromium/ffmpeg fails on aarch64 in F33+

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

Chromium failing on aarch64 in rawhide

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 "./libclea

Re: module 'posix' not found when module load mpi/mpich-x86_64

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

Re: Lua 5.4.0

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

Re: Lua 5.4.0

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

Lua 5.4.0

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, To

Unretire: R-AnnotationDbi

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 -- devel@lists.fedoraproje

Re: TeXLive 2020 landing in rawhide

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 t

Re: TeXLive 2020 landing in rawhide

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é Abíl

Re: TeXLive 2020 landing in rawhide

this 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

Re: TeXLive 2020 landing in rawhide

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 Callawa

Re: TeXLive 2020 landing in rawhide

21 PM 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 P

Re: TeXLive 2020 landing in rawhide

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: > > https://bugzilla.redhat.com/show_bug.cgi?i

Re: TeXLive 2020 landing in rawhide

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 "tex(requirement.s

Re: TeXLive 2020 landing in rawhide

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

Re: TeXLive 2020 landing in rawhide

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

Re: TeXLive 2020 landing in rawhide

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. Hope

TeXLive 2020 landing in rawhide

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 tic

Re: The Chromium Dilemma

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

Re: The Chromium Dilemma

hanks, Tom 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 > &

Re: The Chromium Dilemma

ticeable to users > > 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

The Chromium Dilemma

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 d

Re: GCC help needed for 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 has t

Re: GCC help needed for chromium

nd that it is undefined behavior in the C++14 standard, but given that it is explicitly 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 Chromi

GCC help needed for chromium

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 that

Re: [Retired] gstreamer & gstreamer-plugins-base

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

[Retired] gstreamer & gstreamer-plugins-base

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 impro

Re: Big change to free maxmind GeoLite2 databases, limiting distribution

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 ge

Re: List of long term FTBFS packages to be retired in February (release candidate)

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

Re: List of long term FTBFS packages to be retired in February (release candidate)

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

scalapack 2.1 in rawhide

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 t

Claiming recently orphaned packages

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 devel-le...@lists.fedorap

Review swap?

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 unsu

Reviving torque

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

gstreamer-plugins-base revival

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 b

Re: How do I remove GLIBCXX_ASSERTIONS?

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

s390x rawhide issues?

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 /builddir/build/SOURCES/alienarena-7.71.0-svn5

Re: glibc-arm-linux-gnu help

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

Retiring v8-314

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 u

Re: Chromium C++ help needed

happy, so 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 &quo

Re: Chromium C++ help needed

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

Re: Chromium C++ help needed

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

Chromium C++ help needed

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 Fedo

Re: undefined symbol: shm_open (ppc64le and aarch64)

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 a

undefined symbol: shm_open (ppc64le and aarch64)

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 '/builddir/build/BUILDROOT/R-BiocParallel-1.16.5-1.fc30.

Server Side Public License (SSPL) v1

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

Reviews needed

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 ab

Re: CC-BY-SA-4.0

On 11/23/18 7:08 AM, Carmen Bianca Bakker wrote: > I am currently packaging a program whose README and documentation is > licensed under CC-BY-SA-4.0. However, > only lists CC-BY-SA as > meaning version 3.0 of that licence. > > Is CC-BY-SA-4.0 a "

Re: glibc-arm-linux-gnu help

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 a packaged arm cross-toolchain that was useful (with glibc, it > cannot build anything in userspace) This should have read "without glibc, it cannot bui

glibc-arm-linux-gnu help

A few years ago, I packaged up glibc-arm-linux-gnu, so that Fedora could have a packaged arm cross-toolchain that was useful (with glibc, it cannot build anything in userspace). It worked for a while, but lately, all builds have been failing with this error: /usr/bin/arm-linux-gnu-ld: skipping inc

Proposal: Abandon v8 package

Background: I made the original v8 Fedora package many moons ago, when I was more optimistic about the possibility of separating the useful components inside of chromium. Since that point, it has become clear that while v8 is useful software, the following facts are also true: 1. The v8 upstream

Re: Friendly Reminder: Your Legal Responsibilities as a Fedora Community Member

On 04/02/2018 06:39 PM, Christopher wrote: > On 04/02/2018 11:15 AM, Tom Callaway wrote: >> Most of you are very good about this, and I appreciate it. However, >> lately, at least one package cleared review and landed in Fedora which >> was obviously infringing upo

Re: Package VeraCrypt

On 04/01/2018 02:14 PM, Florian Weimer wrote: > I don't know if anything has changed since then, and what version of the > TrueCrypt license that assessment was based on. TrueCrypt upstream vanished in a puff of smoke in 2014, cancelling development. All of the forks are based on that abandoned co

Friendly Reminder: Your Legal Responsibilities as a Fedora Community Member

This should go without saying, but in Fedora, the following things should be kept in mind: 1) Copyright infringement is not permitted. This includes code, fonts, docs, or content like art/sprites taken from other works, either without permission or under non-free licenses. 2) Trademark infringeme

asymptote segfaulting in rawhide/f28, maybe gcc issue?

I'm not sure if this is a gcc issue or not, but asymptote segfaults in some situations (which is causing the FTBFS, since it bootstraps itself with itself). I filed a bug upstream with the crash and gdb backtrace: https://github.com/vectorgraphics/asymptote/issues/62 If any gcc c++ people could l

Re: Unannounced soname bump (Rawhide): poppler (libpoppler.so.73 -> libpoppler.so.74)

On 03/24/2018 05:07 AM, Tomasz Kłoczko wrote: > Rhetorical question: is it any and/or at least one good reason why > those ~180 texlive-base packages using ~350 source tar balls must be > (re)built always together? Legitimate answer: Those are the CTAN TeX components that either include (or are en

License tag change (EPL)

Hi Fedorans, If your package uses code under the Eclipse Public License, please take a moment and change the license tag to reflect the version. There are now two versions of the EPL, 1.0 and 2.0. Both are permitted in Fedora, neither is GPL compatible. You do not need to push an update solely to

libvpx 1.7.0 update in rawhide

The new libvpx 1.7.0 update in rawhide bumped SOVER because of an ABI break. I rebuilt all the dependent packages I could find with dnf repoquery, except for firefox and thunderbird due to lack of access. Apologies if I missed something. ~tom P.S. I will not be pushing libvpx 1.7.0 into any stab

Re: Tagging large packages (texlive) takes a very long time

On 11/16/2017 11:03 AM, Kevin Fenzi wrote: > I'm not sure what more we can do... While not solving this immediate problem, I am working on redoing the texlive package to make it less evil, in my spare cycles. ~tom ___ devel mailing list -- devel@lists.f

CDDL 1.0 and 1.1

Hi Fedorans, Fernando Nasser noticed that there were now two versions of the CDDL. Accordingly, we have created new shortname identifiers: * CDDL-1.0 * CDDL-1.1 We have also retired the old, unversioned, "CDDL" shortname identifier. If you maintain a package which includes CDDL code, please che

Announcement: fdk-aac

audio codec. The package containing this library is called "fdk-aac". No other AAC implementations (regardless of copyright license) are permitted in Fedora at this time. Thanks, Tom Callaway ___ devel mailing list -- devel@lists.fedoraproj

Re: Is it possible atlas is linked wrongly by new binutils?

On 08/16/2017 04:34 PM, Tom Callaway wrote: > > > On 08/09/2017 05:37 AM, Richard W.M. Jones wrote: >> >> ocaml-gsl (OCaml bindings for GNU Scientific Library) currently >> fails to link to atlas: >> >> + /usr/bin/ocamlfind ocamlopt -g -I lib -linkpkg -

Re: Is it possible atlas is linked wrongly by new binutils?

On 08/09/2017 05:37 AM, Richard W.M. Jones wrote: > > ocaml-gsl (OCaml bindings for GNU Scientific Library) currently > fails to link to atlas: > > + /usr/bin/ocamlfind ocamlopt -g -I lib -linkpkg -package bigarray -I lib -I > examples lib/gsl.cmxa examples/blas_ex.cmx -o examples/blas_ex.nati

Re: Arduino in Fedora

On 08/16/2017 09:09 AM, Peter Robinson wrote: > For reference there's a bunch of history on this bug about getting it > up to date https://bugzilla.redhat.com/show_bug.cgi?id=1316315 Thanks. I give lots of credit to Gianluca's work on the 1.6 branch, most of that was still applicable in the 1.8

Arduino in Fedora

In attempting to figure out why the lulzbot-marlin-firmware was not being compiled properly, I noticed that the arduino packages in Fedora were a bit out of date. To remedy this, I made updated versions of them and put them in my copr here: https://copr.fedorainfracloud.org/coprs/spot/arduino-1.8/

Re: Retiring Packages with Broken Dependencies in branched (2017-06-12)

On 06/12/2017 06:38 PM, t...@fedoraproject.org wrote: > In preparation for the Final Freeze on 2017-06-27 Release > Engineering will retire all packages in Branched with broken dependencies and > all packages depending on these. If you get this e-mail directly this affects > at least one of your pa

Re: R packages needing review

I just need one more review... > R-GenomicAlignments : https://bugzilla.redhat.com/show_bug.cgi?id=1457453 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: R packages needing review

On 06/01/2017 12:00 PM, Mattias Ellert wrote: > I can take a few a these. If you could review these two python packages > for me: All done. Thank you for helping me (and for making such clean packages). ~tom ___ devel mailing list -- devel@lists.fedorap

R packages needing review

Background: R recently released 3.4.0, which introduced changes that required all "compiled" R modules to be rebuilt against it. I've been working over the last week or so to do this, and at the same time, bring them to the latest revisions. Unfortunately, CRAN and Bioconductor (where the majority

Re: mp3 encoding now ok

On 05/04/2017 09:09 AM, Jon Ciesla wrote: > > > On Thu, May 4, 2017 at 8:07 AM, Christian Schaller > wrote: > > Hi, not sure why Spot hasn't chimed in, but yes this > has been run through legal. Tom and I where on the same > email thread with the laywers.

gcc7 issue with efl + aarch64

I'm stumped here. efl builds against all rawhide arches except aarch64, where it has started failing like this (since gcc 7): https://kojipkgs.fedoraproject.org//work/tasks/2376/17972376/build.log libtool: link: gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -

Re: Orphaned: elementry, evas-generic-loaders

On 09/06/2016 03:48 AM, Peter Robinson wrote: > On Tue, Sep 6, 2016 at 2:32 AM, Ding Yi Chen wrote: >> As elementry and evas-generic-loaders are merged to efl after 1.8.0. >> >> The elementry and evas-generic-loaders will be orphanded. > > Please actually actively retire them, rather than just or

Re: Policy change on emulators

On 05/11/2016 08:39 AM, Hans de Goede wrote: > "Naturally I imagine that some emulator writers want to charge a > shareware fee for the code they have > written and we have absolutely no problem with that as long as they > aren't, in any sense, charging for the parts of the code that are > (c)Ams

  1   2   3   4   5   6   >