Hi all-
Since Apple released Swift 5.9 it requires a previous version of Swift to
build; it seems it can’t be built from scratch anymore just using the source.
To make it more complicated, during compiling it’s expected that certain
libraries are available specifically at /usr/lib/swift. In a
Hey all-
I’m still having a difficult time trying to figure out what to do
about this issue I’m having. Swift 5.9 was released awhile ago and
I’ve been able to build it for x864_64 on all versions of Fedora
(Rawhide, 39, 38, 37) just fine. On aarch64 (the only other architecture
supported),
could have made the job much easier, but I had no
idea until I asked here or in IRC.
On 27 Sep 2023, at 11:52, Carlos O'Donell wrote:
On 9/27/23 12:47, Richard W.M. Jones wrote:
On Wed, Sep 27, 2023 at 11:22:04AM -0500, Ron Olson wrote:
This is the first time I’ve heard of buildflags.md; where
This is the first time I’ve heard of buildflags.md; where might I find
this file?
On 26 Sep 2023, at 12:21, Florian Weimer wrote:
redhat-rpm-config-267-1.fc40 activates the first phase of compiler
flags
to avoid regressions in the Fedora C99 port. Implicit ints and
implicit
function
I’m trying to correlate the two; the first was a warning when using
Swift, and it was on both intel and aarch64, while in this new situation
it can’t even build Swift properly without the crash. :\
On 22 Sep 2023, at 7:02, Richard W.M. Jones wrote:
On Thu, Sep 21, 2023 at 03:39:21PM +0100,
Right, I was leaning in that direction regardless, if only because it
means keeping track of what-has-what easier. :)
On 21 Sep 2023, at 9:56, Adam Williamson wrote:
On Thu, 2023-09-21 at 09:24 -0500, Ron Olson wrote:
Could I, possibly, temporarily drop support for aarch64 in the spec
file
> Are upstream responsive to issues in general, and in particular this
> case which is not the current version? I mean to say, do you think
> they'd provide a fix very quickly if you asked them to look at it?
>
Sorry for the confusion, 5.9 is the current version, it was released on Monday;
I
Hey all-
I was trying to submit the released version of Swift 5.9 to Fedora but I get a
build failure only for the aarch64 platform for Rawhide and F39:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2291751 (F39)
https://koji.fedoraproject.org/koji/buildinfo?buildID=2291750
There isn’t a SIG, and I don’t know if there’s any interest
really, but I’d be happy to tell my tales of packaging Swift for
Fedora. :\
Ron
On 5 Jul 2023, at 1:22, Jens-Ulrik Petersen wrote:
I have submitted a Flock proposal to have a common discussion session
for
(modern) Language SIGs. I
Yep, that worked, thanks!
For folks searching similar info later, I ran:
docker pull registry.fedoraproject.org/fedora:rawhide
On 6 Jun 2023, at 8:34, David Schwörer wrote:
Seems a bit disappointing. I’ve been searching but cannot find any
info on configuring docker to use Fedora’s repo so I
Seems a bit disappointing. I’ve been searching but cannot find any
info on configuring docker to use Fedora’s repo so I could just ignore
the issue altogether. :)
On 5 Jun 2023, at 16:41, Mattia Verga via devel wrote:
Il 05/06/23 22:12, Ron Olson ha scritto:
Hey all, I am using docker
Hey all, I am using docker and pulled the latest version of rawhide to use
interactively. Sitting in the container I ran `dnf -y update` and got:
Config error: Parsing file "/etc/dnf/dnf.conf" failed: Parsing file
'/etc/dnf/dnf.conf' failed: IniParser: Missing section header at line 1
I stopped
One thing to note is that the new format doesn’t work with EPEL
releases; I had to revert to the %patchN style for them.
On 29 Mar 2023, at 3:53, Florian Festi wrote:
On 3/29/23 10:31, Michael J Gruber wrote:
Has `%patchN` been deprecated in favour of `%patch N`?
Yes, see %patch section on
Are you referring to the directories under rpmbuild? If so, I delete and
recreate the directory and its structure every single time as part of my
build shell script.
On 23 Mar 2023, at 10:17, Fabio Valentini wrote:
On Wed, Mar 22, 2023 at 4:16 PM Ron Olson
wrote:
The irony is that I
wrote:
On Mon, 20 Mar 2023 at 14:10, Ron Olson wrote:
Hey all-
I got this issue in my GH account I use for building Swift for
Fedora:
https://github.com/tachoknight/swift-lang-packaging-fedora/issues/2.
The
TL;DR is that the person was trying to build Swift on Rawhide which
he
moved to from
Oh sorry, this was copied from my Fedora 37 machine, with GCC 12. Same
error in the same place though. :\
On 20 Mar 2023, at 15:58, Florian Weimer wrote:
* Ron Olson:
Hey all-
I got this issue in my GH account I use for building Swift for
Fedora:
https://github.com/tachoknight/swift-lang
Hey all-
I got this issue in my GH account I use for building Swift for Fedora:
https://github.com/tachoknight/swift-lang-packaging-fedora/issues/2. The
TL;DR is that the person was trying to build Swift on Rawhide which he
moved to from an older version of Fedora. This tracks with something
Hi all,
I submitted a scratch build of Swift to Koji for EPEL 8 and it pretty much
immediately failed, and looking at root.log I found:
DEBUG util.py:443: error: line 71: Unknown tag: %dnl Source31:
Sorry if I missed it, but what is your script running against; are you
checking the spec files in src.fedoraproject.org? I ask because I
updated swift-lang to Apache-2.0[1] on Jan 23, but I see it’s still on
the list of packages to be converted.
[1]
Hey all-
I commented out a SOURCES line in a spec file to test something and got an
interesting warning: “Macro expanded in comment on line …”. I assume it’s just
that, a warning, but was kinda surprised to see a commented-out line being
evaluated at all. I did some searching and came across
Thanks for doing that, Swift builds correctly on Rawhide now:
https://koji.fedoraproject.org/koji/taskinfo?taskID=95546843
On 16 Dec 2022, at 5:24, Miroslav Lichvar wrote:
> On Fri, Dec 16, 2022 at 09:55:11AM +0100, Florian Weimer wrote:
>> Miroslav, we may have to revert the versioning change
If you’re interested in testing any changes/fixes with Swift, you can
use my Swift-for-Fedora repo
(https://github.com/tachoknight/swift-lang-packaging-fedora).
`setup-container.sh` does what you think it does in case you’re using
podman or docker, and `justbuild.sh` actually does all the work
Hey all-
I got linking errors on rawhide that I did not get on F37 when building
Swift related to curses support
(https://kojipkgs.fedoraproject.org//work/tasks/7462/95367462/build.log),
like:
/usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to
Hey all-
I’m curious how Upstream Monitoring works; I got a BZ filed that Swift 5.7.2 is
available, which I’m building now, but what surprised me was how fast the new
version was detected and brought to my attention. Does it use The New Hotness?
I set that up awhile ago but I don’t think it
I’d be willing to take Toilet, as I love that utility.
On 5 Dec 2022, at 5:36, Miro Hrončok wrote:
> 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
Thanks for the info and yeah, that seemed to do the trick in enabling
it, but unfortunately it still works, in that I am able to build the
package successfully without errors. :\
On 13 Sep 2022, at 14:55, Neal Gompa wrote:
On Tue, Sep 13, 2022 at 3:36 PM Ron Olson
wrote:
Unfortunately I
so
it’s pretty frustrating. The weird thing is that it _was_ working
before with earlier builds of Swift.
Sigh.
Ron
On 9 Sep 2022, at 8:12, Stephen Smoogen wrote:
On Fri, 9 Sept 2022 at 08:59, Ron Olson wrote:
Hey all-
I’m having an issue trying to get Swift 5.6.3 built on EPEL-8, even
Thanks Kevin, much appreciated!
On 11 Sep 2022, at 14:45, Kevin Fenzi wrote:
> On Sun, Sep 11, 2022 at 12:31:34PM -0500, Ron Olson wrote:
>> Hey all-
>>
>> When trying to do a `fedpkg update`, I got this response:
>>
>> ```
>> Could not execute update: Coul
Hey all-
When trying to do a `fedpkg update`, I got this response:
```
Could not execute update: Could not generate update request: {"status":
"error", "errors": [{"location": "body", "name": "builds",
"description": "Unable to create update. [SSL:
CERTIFICATE_VERIFY_FAILED] certificate
Hey all-
I’m having an issue trying to get Swift 5.6.3 built on EPEL-8, even though it
builds fine for everything else (Rawhide, F36, F35, EPEL-9): “undefined
reference to 'std::__throw_bad_array_new_length()’”.
https://koji.fedoraproject.org/koji/taskinfo?taskID=91757790
Never saw this issue
esolve the ticket. Since you have not done this,
> then you have to close the ticket yourself and possibly include the NVR in
> 'Fixed In Versoin' field.
>
>
> Vít
>
>
>
> Dne 26. 08. 22 v 15:48 Ron Olson napsal(a):
>> Hey all,
>>
>> https://bugzilla.redh
:48, Ron Olson wrote:
>
>> https://bugzilla.redhat.com/show_bug.cgi?id=2114563 was reported against
>> Swift on Rawhide. I fixed the issue and responded on 8/4 that the Koji build
>> was successful, but I got two additional, presumably automated, notes from
>> Ben Cotton a
Hey all,
https://bugzilla.redhat.com/show_bug.cgi?id=2114563 was reported against Swift
on Rawhide. I fixed the issue and responded on 8/4 that the Koji build was
successful, but I got two additional, presumably automated, notes from Ben
Cotton and Miro that suggest something else needs to be
I have a Pi 4 that runs Fedora just fine; I use it to build Swift (takes almost
24 hours, but ¯\_(ツ)_/¯) so what doesn’t work? What podcast was this mentioned
on?
On 6 Jul 2022, at 4:55, Neal Gompa wrote:
> On Wed, Jul 6, 2022 at 2:49 AM Peter Boy wrote:
>>
>> I very much appreciate the work
Hey all-
Koschei is sending me an email warning me that Nethack builds started to
fail in Rawhide[1], but it seems that it successfully built after that,
so why is it still sending the emails? Is there something I have to
acknowledge or clear to make the emails stop?
Thanks,
Ron
[1]
Ah, I was afraid of that, seems like a lot of trouble to remove the “-“, but I
understand why the process is necessary.
On 21 Jun 2022, at 10:26, Neal Gompa wrote:
> On Tue, Jun 21, 2022 at 11:25 AM Ron Olson wrote:
>>
>> Hey all, is it possible to rename a spec file? I tried to
Hey all, is it possible to rename a spec file? I tried to submit a build using
“swiftlang.spec” where previously it had been “swift-lang.spec”, and Koji
complained that it couldn’t find swift-lang.spec when trying to build the SRPM:
https://koji.fedoraproject.org/koji/taskinfo?taskID=88496417
Hi, how would I go about adding a page for Swift under Languages and
Databases? I looked at "Create a new Project" but I couldn't how to create
a page that would fall under that section.
Ron
On Fri, Jun 17, 2022 at 12:04 PM Jarek Prokop wrote:
> Hi all,
>
> I have pushed new update for Fedora
net
installs
On Thu, May 12, 2022 at 2:15 PM Richard W.M. Jones
wrote:
On Thu, May 12, 2022 at 11:35:44AM -0500, Ron Olson wrote:
Hey all-
I have a VM that I keep perpetually on Rawhide for testing that has
working fine with updates until the latest 5.18 kernels; it just
hangs. Nothing
Hey all-
I have a VM that I keep perpetually on Rawhide for testing that has working
fine with updates until the latest 5.18 kernels; it just hangs. Nothing is
shown on the screen, no kernel panics, just hangs. The VM is running on ESXi
6.0 on a X7350 Xeon (it’s a Dell PowerEdge R900 server
Thank you very much Mattia!
On 10 May 2022, at 11:36, Mattia Verga via devel wrote:
> Il 10/05/22 18:30, Mattia Verga ha scritto:
>> Il 09/05/22 22:28, Mikel Olasagasti ha scritto:
>>> Hi Ron,
>>>
>>> Hau idatzi du Ron Olson (tachokni...@gmail.com) erabilt
No, it’s not available in RHEL nor in CentOS 8 and Stream 8; if I used the rhel
tag would that include those?
On 10 May 2022, at 10:24, Neal Gompa wrote:
> On Tue, May 10, 2022 at 11:01 AM Ron Olson wrote:
>>
>> Hey all-
>>
>> I got a bug report about installing Sw
Hey all-
I got a bug report about installing Swift on RHEL 8 where nothing
provides binutils-gold. I _think_ this will fix it:
```
%if 0%{?el8}
Requires: binutils
%else
Requires: binutils-gold
%endif
```
But was hoping for some confirmation about this being the right way to
ild (noarch) completed successfully
➜ ~
But I’m not clear on what this does, and should I be doing it as part of every
koji update?
On 9 May 2022, at 15:28, Mikel Olasagasti wrote:
> Hi Ron,
>
> Hau idatzi du Ron Olson (tachokni...@gmail.com) erabiltzaileak (2022
> mai. 9, al. (22
Hi all-
I got several strange messages on my update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-bf60d68bdc
The (multiple) messages suggest the update was ejected, but I tested an install
on a fresh image of 35 and 5.6.1 installed fine. Did I do something wrong?
Thanks,
Ron
Ah, didn’t know about that url for some reason. I’ll check there next time,
thanks.
On 1 Apr 2022, at 12:02, Kevin Fenzi wrote:
> On Thu, Mar 31, 2022 at 06:19:06AM -0500, Ron Olson wrote:
>> I submitted some builds yesterday and didn’t get any emails,
>> and at least as of 6:18
I submitted some builds yesterday and didn’t get any emails, and at least as of
6:18 CDT every link I click on the main webpage replies with “server is
offline”.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
That was it! I somehow missed that change to the macros and undermining
_auto_set_build_flags fixed it. Thanks!
On 29 Mar 2022, at 4:38, Sérgio Basto wrote:
On Mon, 2022-03-28 at 16:43 -0500, Ron Olson wrote:
Hey all-
I’m unable to build Swift on Fedora 36 and Rawhide while it does
build
FWIW, I get the same result if using GCC.
On 28 Mar 2022, at 16:43, Ron Olson wrote:
Hey all-
I’m unable to build Swift on Fedora 36 and Rawhide while it does
build on F35. I’ve been able to condense the entire issue down to
the following sample code that demonstrates the problem
Hey all-
I’m unable to build Swift on Fedora 36 and Rawhide while it does build
on F35. I’ve been able to condense the entire issue down to the
following sample code that demonstrates the problem:
nothing.S:
#define ASM_TYPE_FUNCTION(symbol) .type symbol, %function
#define ASM_SIZE(symbol)
Hey all-
I’m trying to build a new version of a package and got the aforementioned
error, but only under EPEL 8, all other builds (Rawhide, F35, F34, EPEL 9)
built fine. The failed build is at
https://koji.fedoraproject.org/koji/taskinfo?taskID=84560380.
I’m curious what I can do, but also to
Weimer wrote:
* Ron Olson:
Building swiftlang on F36/Rawhide results in a a failure that,
boiled down to its essence, appears to be:
/usr/bin/ld: /tmp/lto-llvm-4fd0b1.o: relocation R_X86_64_PC32
against undefined symbol `__libc_stack_end' can not be used when
making a shared object; recompile
,--allow-shlib-undefined
On 9 Mar 2022, at 15:07, Ron Olson wrote:
> Hey all-
>
> Building swiftlang on F36/Rawhide results in a a failure that, boiled down to
> its essence, appears to be:
>
> /usr/bin/ld: /tmp/lto-llvm-4fd0b1.o: relocation R_X86_64_PC32 against
> undefined sym
Hey all-
Building swiftlang on F36/Rawhide results in a a failure that, boiled down to
its essence, appears to be:
/usr/bin/ld: /tmp/lto-llvm-4fd0b1.o: relocation R_X86_64_PC32 against undefined
symbol `__libc_stack_end' can not be used when making a shared object;
recompile with -fPIC
It
Hey all-
I’m trying to build my packages for EPEL-9 on my up-to-date F35 machine using
Mock. I checked /etc/mock but can’t find any specific epel-9 config so I went
with centos-stream+epel-next-9. Okay, fine, but when I run the job, it fails
immediately with the error “Fatal glibc error: CPU
/22 22:08, Todd Zullinger wrote:
Ron Olson wrote:
Sorry if I missed something, but under Rawhide I
discovered when I tried to “more somefile.txt” I got
“less” behavior, while Fedora 35 still runs more like, uh,
more.
I'm not quite sure what "less" behavior you mean, so I'm
only guessi
Hey all-
Sorry if I missed something, but under Rawhide I discovered when I tried to
“more somefile.txt” I got “less” behavior, while Fedora 35 still runs more
like, uh, more.
I like less, but sometimes I need to use more, so having more act like less
breaks some workflows. Is this the
Oh, I forgot I could test for Clang too…I tried that fix and it works for me. :)
On 4 Feb 2022, at 13:35, Jonathan Wakely wrote:
> On Thu, 3 Feb 2022 at 20:27, Ron Olson wrote:
>>
>> Here’s a question: what if the following was added to stdatomic.h at the end
>> of
isn’t installed, it doesn’t matter insofar as the C++ program is going
to fail anyway because it hasn’t explicitly set -std=c++2b.
Just a thought.
On 1 Feb 2022, at 14:40, Jonathan Wakely wrote:
> On Tue, 1 Feb 2022 at 15:00, Ron Olson wrote:
>>
>> Well, yes and no. Th
rig'
memory_order_##m)
^
On 1 Feb 2022, at 14:40, Jonathan Wakely wrote:
On Tue, 1 Feb 2022 at 15:00, Ron Olson wrote:
Well, yes and no. The code I linked to in the pastebin is what
demonstrates the issue. The code in question is Apple’s libdispatch
which I package separat
for their own higher-level
functions, thus why stdatomic is ultimately being invoked.
On 1 Feb 2022, at 3:26, Jonathan Wakely wrote:
> On Tue, 1 Feb 2022 at 09:15, Jonathan Wakely wrote:
>>
>> On Mon, 31 Jan 2022 at 22:45, Ron Olson wrote:
>>>
>>> Hey all,
>>>
Hey all,
I’m troubleshooting an issue and came up with this sample program:
https://pastebin.com/g9S8Z64q to demonstrate the problem. Basically, clang 13,
on Rawhide, won’t compile that program, while on Fedora 35 it does.
The reason why is that on Rawhide, stdatomic.h exists under
Hey all, I _just_ got an email for my failed job from koji
(https://koji.fedoraproject.org/koji/taskinfo?taskID=81627145). The job
started (and finished) on Friday the 21st and yet I just got the email
about five minutes ago. Is something going on, or is this a normal
amount of time?
Thanks!
Is it possible to clone a repo as part of a Source line? I’ve been looking and
can’t find any examples.
On 21 Jan 2022, at 10:34, Miro Hrončok wrote:
> On 21. 01. 22 17:21, Ron Olson wrote:
>> Hey all-
>>
>> I have a package that gets an artifact from a repo /and/ expects
Hey all-
I have a package that gets an artifact from a repo *and* expects to have
code from a different branch in the same repo. In my spec file, I can
easily get the artifact via Sources, but getting the code from the
separate branch required me to execute a “git clone” then checkout
the
Thank you Alexander, my search-engine prowess failed me here. :)
Ron
On 30 Sep 2021, at 15:03, Alexander Ploumistos wrote:
> Hello Ron,
>
> On Thu, Sep 30, 2021 at 9:55 PM Ron Olson wrote:
>>
>> I haven’t found any info about renaming an existing project/package, and w
Hey all-
To be consistent with other flavors of Linux, I’m thinking of changing the
package name from “swift-lang” to “swiftlang”. I haven’t found any info about
renaming an existing project/package, and was wondering what the procedures
would be.
Thanks!
Ron
Hey all-
I’m trying to install the packaging tools in a container image of Fedora 35 and
keep getting this error when it reaches the “RUN dnf install -y fedora-packager
fedora-review” command:
The downloaded packages were saved in cache until the next successful
transaction.
You can remove
Hey all-
I’m curious as to why submitting a new build to Bodhi takes a week to be pushed
to stable, but two weeks for EPEL-8. Is the presumption that it’s just that
much more time for folks to test and verify?
Ron
___
devel mailing list --
astructure.fedoraproject.org/repo/rhel/rhel8/koji/latest/x86_64/RHEL-8-001;
> href="non_modular/kernel-headers-4.18.0-305.3.1.el8_4.x86_64.rpm"/>
>
> Looking at the contents of the stuff local is giving.. it is only
> those files which are local to IAD2 and nothing else.. as
Funny enough, neither did I.
On 21 Jun 2021, at 11:58, Stephen John Smoogen wrote:
> I don't know.
>
> on my systems I did a find /etc/mock/ -type f -print | xargs grep
> infrastructure.fedoraproject.org and did not have any hits.
>
> On Mon, 21 Jun 2021 at 10:35, Ron Olson
--buildsrpm --rebuild
--rpmbuild-opts=--noclean --no-cleanup-after 2>&1 | tee
$MYDIR/mock-results/build-output.txt
On 21 Jun 2021, at 6:48, Stephen John Smoogen wrote:
> On Sun, 20 Jun 2021 at 18:25, Ron Olson wrote:
>>
>> Hey all-
>>
>> I’m trying to run a moc
Hey all-
I’m trying to run a mock build with EPEL-8 (epel-8-x86_64) and it fails with:
[MIRROR] kernel-headers-4.18.0-305.3.1.el8_4.x86_64.rpm: Status code: 403 for
Apologies in advance if this is laughable naïveté, but would a possible
solution be to have a different repo for packages compiled against the
latest-n-greatest architectures, and packagers could choose to include their
packages in there, similar to EPEL?
Packages in this hypothetical repo
https://github.com/tachoknight/libdispatch-packaging-fedora/blob/main/libdispatch.spec
On 2 Jun 2021, at 12:59, Tom Stellard wrote:
> On 6/2/21 10:57 AM, Ron Olson wrote:
>> Hm, I do have %global toolchain clang set, which interestingly enough was
>> not picked up by the %cmake
1 5:51 PM, Ron Olson wrote:
>> Hey all, I’m trying to build my package for EPEL and got a strange error
>>
>> clang-11: error: argument unused during compilation:
>> '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1'
>> [-Werror,-Wunused-command-line-argument]
>>
Hey all, I’m trying to build my package for EPEL and got a strange error
clang-11: error: argument unused during compilation:
'-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1'
[-Werror,-Wunused-command-line-argument]
clang-11: error: argument unused during compilation:
Oh, so, wait, when doing an EPEL build, is it against CentOS or RHEL? Honestly
I always thought CentOS was the image being using by Koji for rpm builds.
On 1 Jun 2021, at 15:49, Orion Poplawski wrote:
> CentOS has not yet released 8.4.
>
> On 6/1/21 2:45 PM, Ron Olson wrote:
>>
Out of curiosity, what will EPEL be built on going forward, if CentOS fades
away and CentOS Stream takes its place?
On 1 Jun 2021, at 17:21, Neal Gompa wrote:
> On Tue, Jun 1, 2021 at 6:06 PM Nico Kadel-Garcia wrote:
>>
>> On Tue, Jun 1, 2021 at 4:49 PM Orion Poplawski wrote:
>>>
>>> CentOS
1:1.38.0-2.el8 appstream 151 k
Transaction Summary
===
Install 6 Packages
Total download si
If I may, I think the issue is right there in the name: Fedora CoreOS. The
Fedora name brings some expectations and it seems CoreOS, by its nature, can’t
be at parity with the other Fedora flavors and that leads to confusion. I can
attest that I was surprised when I learned Fedora CoreOS didn’t
Hey all-
Awhile back I asked about the status of CMake in CentOS so I could build my
packages for EPEL-8; they require a version of CMake that is greater than
3.11.4 which is currently available. CentOS Stream has a later version, as does
RHEL 8.4. I get that CentOS Stream is the future of
Hm, so does that mean it was packaged specifically for CentOS so it
presumably shows up in the CentOS repos?
On 30 Apr 2021, at 10:33, Michael Catanzaro wrote:
On Fri, Apr 30 2021 at 10:26:49 AM -0500, Ron Olson
wrote:
Is there any plans on bringing CMake up to the current version of
Fedora
Hi all-
I’m trying to build a package under EPEL-8[1] but it fails due to
CMake being too old:
CMake 3.15.1 or higher is required. You are running version 3.11.4.
Is there any plans on bringing CMake up to the current version of Fedora
(3.19.7) or at the very least to something >=
Swift (swift-lang) absolutely, positively requires clang. I tried
building Swift with gcc and that is a lost weekend I’d love to get
back.
Ron
On 23 Apr 2021, at 14:46, Florian Weimer wrote:
* Gary Buhrmaster:
For C/C++ projects:
If the upstream has no stated preference for the compiler,
Hey all-
I have a VM that I want to always keep on Rawhide. That was F34 until
this past week or so and now I want to update it track F35. Can I
basically just follow the instructions at
https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/ and
pass it —releasever=rawhide; I
Hey all,
While installing Debian for setting up an appliance, I discovered they
have something called a “popularity contest” that, according to my
understanding, allows for package statistics to be gathered and used by
the developers/packagers.
Has anything like this been considered for
Hey all-
Pretty much as the subject says, I have a compile failure on Rawhide where
a cpp file references . I checked and the file is not present
in Rawhide, it *is* present in Fedora 32 and Fedora 33. I haven't found any
references to it being deprecated so I'm wondering why it's missing.
swift-lang includes its own private copy of LLDB for its REPL, which uses
Python as its scripting language so it too is linking correctly.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
Yes: https://github.com/apple/swift-corelibs-foundation/pull/2771
-Original Message-
From: Florian Weimer
Sent: Saturday, April 18, 2020 8:27 AM
To: Ron Olson
Cc: 'Miro Hrončok' ; devel@lists.fedoraproject.org;
swift-lang-maintain...@fedoraproject.org
Subject: Re: will disappear from
Already fixed it and sending it to Rawhide now.
-Original Message-
From: Miro Hrončok
Sent: Saturday, April 18, 2020 4:34 AM
To: devel@lists.fedoraproject.org; swift-lang-maintain...@fedoraproject.org
Subject: Re: will disappear from rawhide glibc soon
On 15. 04. 20 17:49, Florian
Hey all-
Okay, my curiosity has finally gotten the better of me; is there a way
to pass the body.template.last file to ‘fedpkg update’ so I don’t
have to fill it out for every single release, or fill it out again when
I get a timeout and have to rerun fedpkg update? I’ve been searching
for
This is what I got:
Error:
Problem 1: package gegl03-0.3.30-5.fc30.x86_64 requires
libIlmImf-2_2.so.22()(64bit), but none of the providers can be installed
- OpenEXR-libs-2.2.0-16.fc30.x86_64 does not belong to a distupgrade
repository
- problem with installed package
swift-lang has been fixed with a patch and scratch builds on F32 build
properly:
https://koji.fedoraproject.org/koji/taskinfo?taskID=37348234
On 4 Sep 2019, at 17:39, Miro Hrončok wrote:
Hello packagers!
The following packages failed to build on Fedora 32 with Python 3.8
and they still
I opened a ticket here: https://pagure.io/fesco/issue/2213 for my
specific package.
On 22 Aug 2019, at 8:29, Gabriel L. Somlo wrote:
On Thu, Aug 22, 2019 at 07:44:29 -0500, tachokni...@gmail.com wrote:
Hey all, subject line says it all. I’m trying to get in contact
with
Eric Smith
Hey all, subject line says it all. I’m trying to get in contact with
Eric Smith (https://fedoraproject.org/wiki/User:Brouhaha) regarding the
libbsd package. I’ve emailed him directly but haven’t heard back;
does anyone know if he’s still active in the Fedora community?
Thanks,
Ron
. It certainly wouldn’t be the most popular,
but for the folks who could stand to benefit from it, they’d know
where to find this particular spin.
On 22 Jul 2019, at 15:19, Solomon Peachy wrote:
On Mon, Jul 22, 2019 at 03:05:15PM -0500, Ron Olson wrote:
Perhaps as a compromise there could
My entire involvement around Fedora is based on the fact that I was able
to use machines that had been thrown away because they were deemed
‘too old’. I have several servers and multiple laptops that run
Fedora perfectly and none of them would meet this requirement,
effectively ending any
What about packages that see infrequent updates; I maintain Nethack and the Dev
Team can and does take years between releases. If it's just a blanket email to
ask the packagers if they're still interested that's one thing, but going off
package updates may be problematic for some folks.
> On
I forgot to mention that I'd be willing to do a review-swap for this as
well.
Ron
On 27 Feb 2018, at 14:08, Ron Olson wrote:
Hi all-
I'm looking for a package review of Apple's Swift programming
language:
https://bugzilla.redhat.com/show_bug.cgi?id=1536780
I greatly appreciate any
1 - 100 of 106 matches
Mail list logo
