On Thu, Dec 31, 2020 at 3:46 PM Till Maas wrote:
>
> Hi,
>
> On Thu, Dec 31, 2020 at 07:58:53AM -0600, Richard Shaw wrote:
>
> > 4. Build the packages in COPR.
> >
> > Easy enough using a bash script but is there a better way?
>
> packit allows to create
there is some blocker).
I am talking about running upstream tests via GitHub actions on Fedora directly
instead of dockerized Fedora on Ubuntu. E.g. the "Native support for Fedora in
Travis" point in the original email (the line I forgot to quote). Not about Copr.
As a specif
about running upstream tests via GitHub actions on Fedora directly
instead of dockerized Fedora on Ubuntu. E.g. the "Native support for Fedora in
Travis" point in the original email (the line I forgot to quote). Not about Copr.
--
Miro Hrončok
--
Phone: +420777974800
IRC
oslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
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
ll add it to
spreadsheet manually.
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedor
Hi,
Miroslav Suchý writes:
> Let me sum up what we - the Copr team - did in 2020:
>
> * We enabled CDN for repos. https://fedora-copr.github.io/posts/copr-cdn
>
> * We enabled runtime dependecies on repositories
> https://fedora-copr.github.io/posts/runtime-dependencies
On 04. 01. 21 18:40, Alexander Scheel wrote:
* Native support for Fedora in Travis.
Travis has made a lot of changes to how OSS projects can use it, and
(IMO) burnt a lot of good will in the community. All of our upstream
projects ended up moving off it and onto GitHub Actions. Is there any
Congrats! I can say I've used several of these features and they work
well, thanks for your team's work!
One query inline... :)
On Mon, Jan 4, 2021 at 11:53 AM Miroslav Suchý wrote:
>
> Let me sum up what we - the Copr team - did in 2020:
>
> * We enabled CDN for repos. ht
Let me sum up what we - the Copr team - did in 2020:
* We enabled CDN for repos. https://fedora-copr.github.io/posts/copr-cdn
* We enabled runtime dependecies on repositories
https://fedora-copr.github.io/posts/runtime-dependencies
* We migrated all our servers from PHX datacenter to AWS
ld
work for you 1:1. I don't know what scm provider is the upstream using so
I can not advice how to "automatically" trigger the builds in Copr using
the existing webhooks. Otherwise there's no "polling" mechanism
implemented in Copr now.
In the worst case there's 'copr buil
It's still manually initiated, but I wrote a bash script which takes care
of the process nicely.
I just pass the package name and the test version and then:
1. It clones the package in a temporary directory
2. Used sed to change the alpha macro from 0 to 1 which I use to control
the Source URL
and the patch
> level incremented.
>
> Currently I'm just trying to keep up with them by hand using pagure forks of
> the official repos so I don't accidentally pollute SCM with the changes and
> build them in COPR.
>
> Things I need to manage automagically:
> 1. Monitor the t
On Thu, Dec 31, 2020 at 8:41 AM Till Maas wrote:
> Hi,
>
> On Thu, Dec 31, 2020 at 07:58:53AM -0600, Richard Shaw wrote:
>
> > 4. Build the packages in COPR.
> >
> > Easy enough using a bash script but is there a better way?
>
> packit allows to create tes
Hi,
On Thu, Dec 31, 2020 at 07:58:53AM -0600, Richard Shaw wrote:
> 4. Build the packages in COPR.
>
> Easy enough using a bash script but is there a better way?
packit allows to create test builds in COPR based on GitHub PRs and
probably also releases. Maybe this can make it easie
em by hand using pagure forks
of the official repos so I don't accidentally pollute SCM with the changes
and build them in COPR.
Things I need to manage automagically:
1. Monitor the test URLs to look for new versions.
I could write a bash script for this and add a cron or systemd timer but I
://vault.centos.org/ server (this is first time
experience, so we don't know the stability or throughput).
WARNING: It is very unlikely you want to waste your time and Copr
resources (computational power but especially storage) with epel-6, so
we'd still like to appeal to you to _disable_ epel-6 chroots
The Fedora 31 and EPEL 6 chroots are marked as EOL in Copr now (for the epel
case, it's not even easily possible to build there nowadays because CentOS
already stopped mirroring of the repos).
There's additional 180 days period when we keep the build results. If you want
to keep the results
) called in chroot against
sub-chroot when the arhmfp arch is emulated (Copr case):
https://bugzilla.redhat.com/show_bug.cgi?id=1895363
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NNP6TZNG2ZRQ3XCKCJWFTL3XIABOBZJW/#HUO7T5KMV
Dne 30. 11. 20 v 19:29 Rudolf Kastl napsal(a):
> copr-cli has a --timeout option (in seconds). had the same issue with llvm.
WebUI has the the option as well when you specify new build.
> the default timeout from 18000 seconds (5 hours). You can set it to a max of
> 20 hours.
Th
Hi guys,
not sure whether I missed something, but I have realized troubles
with building for the armhfp arch. The build process crash on
installation of requirements because of inssuficient space:
Thanks for the replies. I'll add the CLI timeout flag to our CI scripts.
Steve
On 11/30/20 1:29 PM, Rudolf Kastl wrote:
copr-cli has a --timeout option (in seconds). had the same issue with llvm.
- Rudolf Kastl
Am Mo., 30. Nov. 2020 um 19:24 Uhr schrieb Richard Shaw :
On Mon, Nov
copr-cli has a --timeout option (in seconds). had the same issue with llvm.
- Rudolf Kastl
Am Mo., 30. Nov. 2020 um 19:24 Uhr schrieb Richard Shaw :
>
> On Mon, Nov 30, 2020 at 11:42 AM Steven A. Falco
> wrote:
>>
>> KiCAD has a large package containing 3D component mod
On Mon, Nov 30, 2020 at 11:42 AM Steven A. Falco
wrote:
> KiCAD has a large package containing 3D component models. It takes a long
> time to compress with the new zstd compressor. So long in fact that the
> copr build system is throwing a timeout. You can see an example here:
&g
KiCAD has a large package containing 3D component models. It takes a long time
to compress with the new zstd compressor. So long in fact that the copr build
system is throwing a timeout. You can see an example here:
https://download.copr.fedorainfracloud.org/results/@kicad/kicad/fedora-33
Hello!
we recently merged [1] a development version of ansible module for
enabling copr repositories. At this moment we would like to get your
early feedback - before we submit this to Galaxy, or propose this as
ansible core library.
Quick howto. Either copy the copr.py file into
`/usr/share
On Mon, Nov 23, 2020 at 11:31 AM Jakub Kadlcik wrote:
>
> Ah, so you meant the F28 and F29 chroots listed here in the build details,
> e.g.
>
> https://copr.fedorainfracloud.org/coprs/alexpl/molsketch/build/869545/
Yes, that's what I was talking about.
> That is as expected. Possibly we can
Ah, so you meant the F28 and F29 chroots listed here in the build details, e.g.
https://copr.fedorainfracloud.org/coprs/alexpl/molsketch/build/869545/
That is as expected. Possibly we can improve our deletion script to
hide/remove them as well but it is not done yet. The important thing
(from
Hello again,
Perhaps I'm the one who's misunderstood. Is the fact that F28 and F29
builds are still around unrelated to which chroots are actually there?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
But I can't see any data on the backend, that are older than F30 for
those respective projects:
https://download.copr.fedorainfracloud.org/results/alexpl/molsketch/
https://download.copr.fedorainfracloud.org/results/alexpl/scidavis/
Is that what you mean by
> I noticed that some of my projects
On Mon, Nov 23, 2020 at 9:54 AM Jakub Kadlcik wrote:
>
> Hello Alexander,
> what do those chroots say in their "Remaining time" column, please?
They are not listed at all, see these two:
https://copr.fedorainfracloud.org/coprs/alexpl/molsketch/repositories/
Hello Alexander,
what do those chroots say in their "Remaining time" column, please?
Jakub
On Mon, Nov 23, 2020 at 8:34 AM Alexander Ploumistos
wrote:
>
> Hello Jakub,
>
> I noticed that some of my projects still have chroots for even older
> releases, e.g. F28, F29 without the option to
Hello Jakub,
I noticed that some of my projects still have chroots for even older
releases, e.g. F28, F29 without the option to remove them. In another
instance, only a specific F30 arch shows up among the chroots to be
removed or extended, while the others architectures are not picked up.
Is
On Monday, November 23, 2020 12:52:43 AM CET Jakub Kadlcik wrote:
> The email notifications for upcoming deletion proved to be unreliable
> for some users in the past, therefore we tried to improve this
> situation within the latest Copr release [3].
Because of what Jakub said ^^, we ma
Hello again,
the Fedora 30 chroots are disabled for around three months now but so far we
haven't marked the built results as outdated. I did it just now, so
according to Outdated chroots removal policy [1], Copr is
going to preserve existing build results in those chroots for another
180 days
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
On Saturday, November 14, 2020 2:36:43 PM CET Michael J Gruber wrote:
> 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
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
On Friday, November 13, 2020 6:44:14 PM CET Iñaki Ucar wrote:
> On Fri, 13 Nov 2020 at 18:13, Pavel Raiskup wrote:
> > > - Can a build depend on more than one build ID?
> >
> > You should rather think about "batches" in this case, and each batch can
> > only depend on one batch.
> >
> > Corner
On Fri, 13 Nov 2020 at 18:13, Pavel Raiskup wrote:
>
> Thanks for questions!
>
> On Friday, November 13, 2020 5:50:46 PM CET Iñaki Ucar wrote:
> > On Fri, 13 Nov 2020 at 17:26, Pavel Raiskup wrote:
> > >
> > > Hello!
> > >
> > > On Nov 13
Thanks for questions!
On Friday, November 13, 2020 5:50:46 PM CET Iñaki Ucar wrote:
> On Fri, 13 Nov 2020 at 17:26, Pavel Raiskup wrote:
> >
> > Hello!
> >
> > On Nov 13 2020, a new Copr release landed production. The list of user
> > visible
> > c
On Fri, 13 Nov 2020 at 17:50, Iñaki Ucar wrote:
>
> On Fri, 13 Nov 2020 at 17:26, Pavel Raiskup wrote:
> >
> > Hello!
> >
> > On Nov 13 2020, a new Copr release landed production. The list of user
> > visible
> > changes is in the release notes
On Fri, 13 Nov 2020 at 17:26, Pavel Raiskup wrote:
>
> Hello!
>
> On Nov 13 2020, a new Copr release landed production. The list of user
> visible
> changes is in the release notes document:
>
> https://docs.pagure.org/copr.copr/release-notes/2020-11-13.html
Many than
Hello!
On Nov 13 2020, a new Copr release landed production. The list of user visible
changes is in the release notes document:
https://docs.pagure.org/copr.copr/release-notes/2020-11-13.html
Happy building!
Copr Team
___
devel mailing list
On Thu, Nov 05, 2020 at 09:29:46AM +0100, Didier Fabert wrote:
> Hi,
>
> I try to make an epel-8 package on COPR, and I get the following errors in
> root.log
> DEBUG util.py:634: No matching package to install: 'Judy-devel'
> DEBUG util.py:634: No matching package to ins
Hi,
I try to make an epel-8 package on COPR, and I get the following errors
in root.log
DEBUG util.py:634: No matching package to install: 'Judy-devel'
DEBUG util.py:634: No matching package to install: 'libuv-devel'
It's working as expected on Koji.
AM I missing something in my conf
libraries?
Any hints, even a polite "rtfm" with the name of the docs I am missing
would be very welcome at this point.
Thanks,
/mark
On 2020-10-22 13:47, Mark Olesen wrote:
This will presumably also affect Fedora, but need to recheck.
We are experiencing some very odd build
libraries?
Any hints, even a polite "rtfm" with the name of the docs I am missing
would be very welcome at this point.
Thanks,
/mark
On 2020-10-22 13:47, Mark Olesen wrote:
This will presumably also affect Fedora, but need to recheck.
We are experiencing some very odd build
I/usr/include/openmpi-x86_64 -pthread
-Wl,-rpath -Wl,/usr/lib64/openmpi/lib -Wl,--enable-new-dtags
-L/usr/lib64/openmpi/lib -lmpi
A link to the copr builds would be useful to see what flags you have
been using.
I would also suggest to try to build with mpicc and see whether that
fixes the iss
Any hints, even a polite "rtfm" with the name of the docs I am missing
would be very welcome at this point.
Thanks,
/mark
On 2020-10-22 13:47, Mark Olesen wrote:
This will presumably also affect Fedora, but need to recheck.
We are experiencing some very odd build behaviour u
This will presumably also affect Fedora, but need to recheck.
We are experiencing some very odd build behaviour using copr to compile
for various Fedora and CentOS/RedHat versions
(https://copr.fedorainfracloud.org/coprs/openfoam/openfoam).
The built package on centos8 is automatically given
On Thu, Oct 8, 2020 at 2:37 PM Germano Massullo
wrote:
> ganglia EPEL 7 successfully builds on mock and copr [1] but fails on
> koji [2], complaining about a missing close in a %if block. By seeing
> the spec file I don't see any missing closure in the block, and I don't
>
ganglia EPEL 7 successfully builds on mock and copr [1] but fails on
koji [2], complaining about a missing close in a %if block. By seeing
the spec file I don't see any missing closure in the block, and I don't
understand this different behaviour between copr and koji
What do you think about
Hi,
I requested review of the proposed package in
https://bugzilla.redhat.com/show_bug.cgi?id=1880953
<https://bugzilla.redhat.com/show_bug.cgi?id=1880953>
Andy
> Begin forwarded message:
>
> From: Andreas R Maier
> Subject: Fwd: Copr package build fails on python-nocasel
> Please consider reporting this against rpkg-util:
> https://pagure.io/rpkg-util <https://pagure.io/rpkg-util>
I just created https://pagure.io/rpkg-util/issue/28
<https://pagure.io/rpkg-util/issue/28>
Andy
> Begin forwarded message:
>
> From: Pavel Raiskup
>
On Monday, September 21, 2020 9:07:32 AM CEST Andreas R Maier wrote:
> Hello Robert,
> I suspect the reason I get the python-%{srcname}-%{version} in the .tar.gz
> file is that I was setting up COPR to use "rpkg". When using "copr-cli build"
> as shown in your mail,
Hello Robert,
I suspect the reason I get the python-%{srcname}-%{version} in the .tar.gz file
is that I was setting up COPR to use "rpkg". When using "copr-cli build" as
shown in your mail, it works on COPR. So I think we can ignore that issue.
At this point, I can succes
On Friday, 18 September 2020 12:24:21 CEST Andreas R Maier wrote:
> Thanks for the quick help and for the mini-review.
>
> I have updated the spec file as recommended, except for the %py_provides
> macro because COPR did not like that when running the rpkg command:
>
>
Thanks for the quick help and for the mini-review.
I have updated the spec file as recommended, except for the %py_provides macro
because COPR
did not like that when running the rpkg command:
Running: rpkg srpm --outdir /tmp/copr-rpmbuild-vtejek5l --spec
/tmp/copr-rpmbuild-vtejek5l/obtain
On Friday, 18 September 2020 09:19:48 CEST Andreas R Maier wrote:
> Hi,
> I am new to building packages, and I'm trying to build a new package
> 'python-nocaselist' on Copr, and it fails in the %prep stage when unpacking
> the SRPM file because it cannot cd into the directory it
Hi,
I am new to building packages, and I'm trying to build a new package
'python-nocaselist' on Copr, and it fails in the %prep stage when unpacking the
SRPM file because it cannot cd into the directory it assumes got unpacked:
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.6rjfBt
+ umask 022
Since the new mock-core-configs are in Fedora stable, it allowed us to enable
fedora-eln- [1] buildroots in Fedora Copr. Feel free to try them.
Note that Fedora ELN repositories aren't mirrored at this moment, and thus
we can face some weird repo/package downloading issues (as e.g. discussed
I solved the previous error about macros expanded in comments, and now
the build fails for other strange reasons.
https://copr.fedorainfracloud.org/coprs/germano/kernel_204253_comment_14_patch/build/1616496/
By the way by commenting my patch on spec file, the kernel builds
successfully
On Wed, Aug 19, 2020 at 8:12 AM Germano Massullo
wrote:
>
> I solved the previous error about macros expanded in comments, and now
> the build fails for other strange reasons.
> https://copr.fedorainfracloud.org/coprs/germano/kernel_204253_comment_14_patch/build/1616496/
Macros expanded in
I solved the previous error about macros expanded in comments, and now
the build fails for other strange reasons.
https://copr.fedorainfracloud.org/coprs/germano/kernel_204253_comment_14_patch/build/1616496/
By the way by commenting my patch on spec file, the kernel builds
successfully
On Tuesday, August 18, 2020 5:09:32 PM CEST Cole Robinson wrote:
> On 8/18/20 10:48 AM, Pavel Raiskup wrote:
> > On Tuesday, August 18, 2020 3:12:06 PM CEST Jakub Kadlcik wrote:
> >> we have just disabled Fedora 30 chroots in Copr.
> >
> > And at the same time,
On 8/18/20 10:48 AM, Pavel Raiskup wrote:
> On Tuesday, August 18, 2020 3:12:06 PM CEST Jakub Kadlcik wrote:
>> we have just disabled Fedora 30 chroots in Copr.
>
> And at the same time, we enabled fedora-33-* chroots. It required us to do
> a small bug-fix release of copr-fro
On Tuesday, August 18, 2020 3:12:06 PM CEST Jakub Kadlcik wrote:
> we have just disabled Fedora 30 chroots in Copr.
And at the same time, we enabled fedora-33-* chroots. It required us to do
a small bug-fix release of copr-frontend today, but I believe it went out
smoothly without interru
Hello,
we have just disabled Fedora 30 chroots in Copr.
According to the Fedora wiki [1], Fedora 30 reached the end of its life
on 2020-05-26 and therefore we are disabling it in Copr.
That effectively means that from this moment, it is no longer possible
to submit builds for the following
blk-mq scheduler
> > https://bugzilla.kernel.org/show_bug.cgi?id=204253#c14
> >
> > The only errors I can see are like "Macro expanded in comment",
> but as I
> > said, these expanded macros were already present in official Fedora
>
Macro expanded in comment", but as I
> > said, these expanded macros were already present in official Fedora
> > build, so I don't understand why the build fails on my Copr repository.
> >
> > Thank you
>
> From your log:
>
> Applying: PCI: Add MCFG quirks for
the build fails on my Copr repository.
Thank you
From your log:
Applying: PCI: Add MCFG quirks for Tegra194 host controllers
Applying: Work around for gcc bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
Applying:
error: Bad exit status from /var/tmp/rpm-tmp.FxtIcw (%prep)
That
scheduler
https://bugzilla.kernel.org/show_bug.cgi?id=204253#c14
The only errors I can see are like "Macro expanded in comment", but as I
said, these expanded macros were already present in official Fedora
build, so I don't understand why the build fails on my Copr repository.
Unfortunately, Copr still deletes data without warning:
https://bugzilla.redhat.com/show_bug.cgi?id=1868367
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
On Wed, 12 Aug 2020 at 12:32, Pavel Raiskup wrote:
>
> On Wednesday, August 12, 2020 11:19:00 AM CEST Iñaki Ucar wrote:
> > On Wed, 12 Aug 2020 at 10:29, Pavel Raiskup wrote:
> > > - Copr newly provides a build-time macro %buildtag. Its format is
> > > `
On Wednesday, August 12, 2020 11:19:00 AM CEST Iñaki Ucar wrote:
> On Wed, 12 Aug 2020 at 10:29, Pavel Raiskup wrote:
> >
> > Hello.
> >
> > On Aug 12 2020, a new Copr release landed production. Here is the list
> > of visible changes:
> >
> > - P
On 12. 08. 20 11:19, Iñaki Ucar wrote:
- Copr newly provides a build-time macro %buildtag. Its format is
`.copr` and is useable for auto-incrementing the package's NVR
in subsequent builds. It may be used in spec file like:
Release: 1%{?dist}%{?buildtag}
It could be useful
On 12. 08. 20 11:20, Pavel Raiskup wrote:
- Copr newly provides a build-time macro %buildtag. Its format is
`.copr` and is useable for auto-incrementing the package's NVR
in subsequent builds. It may be used in spec file like:
Release: 1%{?dist}%{?buildtag}
It could
On Wednesday, August 12, 2020 10:51:56 AM CEST Miro Hrončok wrote:
> On 12. 08. 20 10:29, Pavel Raiskup wrote:
> > - Project karma implemented; Logged-in users can give
> >thumbs-up/thumbs-down to the existing copr projects. [snip]
> >This is just
>
> Assuming
On Wed, 12 Aug 2020 at 10:29, Pavel Raiskup wrote:
>
> Hello.
>
> On Aug 12 2020, a new Copr release landed production. Here is the list
> of visible changes:
>
> - Project karma implemented; Logged-in users can give
> thumbs-up/thumbs-down to the existing copr
On 12. 08. 20 10:29, Pavel Raiskup wrote:
Hello.
On Aug 12 2020, a new Copr release landed production. Here is the list
of visible changes:
- Project karma implemented; Logged-in users can give
thumbs-up/thumbs-down to the existing copr projects. This is just
another way to give
Hello.
On Aug 12 2020, a new Copr release landed production. Here is the list
of visible changes:
- Project karma implemented; Logged-in users can give
thumbs-up/thumbs-down to the existing copr projects. This is just
another way to give feedback about a particular Copr project quality
On Thu, Aug 06, 2020 20:23:33 +0200, Andy Mender wrote:
> On Thu, 6 Aug 2020 at 19:30, Ankur Sinha wrote:
>
> Hello,
>
> We've got quite a few unmaintained repos on COPR under the neuro-sig
> group. I intend to do a bit of housekeeping to remove projects there
Silvie Chlupova writes:
> Hi Dave,
> at this point, we still don't have working ppc64le workers. Please see this
> issue https://pagure.io/fedora-infrastructure/issue/9059. Unfortunately, I
> can't give you better information at the moment.
OK, thanks. I can sympathize, being in an
ate of ppc64le in copr? Is it coming back and, if so, is
> there a timescale for that? Sorry I can't find the info about it from a
> while back, but I thought things were meant to be restored by August.
> It would definitely be more useful to m
What's the state of ppc64le in copr? Is it coming back and, if so, is
there a timescale for that? Sorry I can't find the info about it from a
while back, but I thought things were meant to be restored by August.
It would definitely be more useful to me than s390x
On Thu, 6 Aug 2020 at 19:30, Ankur Sinha wrote:
> Hello,
>
> We've got quite a few unmaintained repos on COPR under the neuro-sig
> group. I intend to do a bit of housekeeping to remove projects there
> that aren't in use any more. Please take a look and let me know if you
&
Hello,
We've got quite a few unmaintained repos on COPR under the neuro-sig
group. I intend to do a bit of housekeeping to remove projects there
that aren't in use any more. Please take a look and let me know if you
do not want me to delete a project:
https://copr.fedorainfracloud.org/groups/g
On Fri, 2020-07-31 at 11:44 -0300, Augusto Caringi wrote:
> Hi,
>
> On Thu, Jul 30, 2020 at 12:47 PM Jeremy Linton wrote:
> > On 7/28/20 4:39 PM, Jeff Law wrote:
> > > On Tue, 2020-07-28 at 15:29 -0500, Michael Catanzaro wrote:
> > > > On Tue, Jul 28, 2020 at 2:01 pm, Jeff Law wrote:
> > > > >
Hi,
On Thu, Jul 30, 2020 at 12:47 PM Jeremy Linton wrote:
>
> On 7/28/20 4:39 PM, Jeff Law wrote:
> > On Tue, 2020-07-28 at 15:29 -0500, Michael Catanzaro wrote:
> >> On Tue, Jul 28, 2020 at 2:01 pm, Jeff Law wrote:
> >>> If this is a new failure (say in the last week), it could be an out
> >>>
On 7/28/20 4:39 PM, Jeff Law wrote:
On Tue, 2020-07-28 at 15:29 -0500, Michael Catanzaro wrote:
On Tue, Jul 28, 2020 at 2:01 pm, Jeff Law wrote:
If this is a new failure (say in the last week), it could be an out
of memory
scenario. Try disabling LTO. The standard way to do that is
%define
On 7/29/20 6:09 PM, Jeff Law wrote:
On Wed, 2020-07-29 at 17:14 -0500, Brandon Nielsen wrote:
On 7/29/20 4:40 PM, Jeff Law wrote:
ACK. I don't see msp430-development-tools in the standard fedora repos. So
I'll
leave it to you to fix the package in whatever repo it lives in.
Also note, you
On Wed, 2020-07-29 at 17:14 -0500, Brandon Nielsen wrote:
> On 7/29/20 4:40 PM, Jeff Law wrote:
> > ACK. I don't see msp430-development-tools in the standard fedora repos.
> > So I'll
> > leave it to you to fix the package in whatever repo it lives in.
> >
> > Also note, you may ultimately be
On 7/29/20 4:40 PM, Jeff Law wrote:
ACK. I don't see msp430-development-tools in the standard fedora repos. So
I'll
leave it to you to fix the package in whatever repo it lives in.
Also note, you may ultimately be better off getting msp430 added to the cross-
{binutils,gcc} packages rather
On Wed, 2020-07-29 at 14:24 -0500, Brandon Nielsen wrote:
> On 7/28/20 4:39 PM, Jeff Law wrote:
> > On Tue, 2020-07-28 at 15:29 -0500, Michael Catanzaro wrote:
> > > On Tue, Jul 28, 2020 at 2:01 pm, Jeff Law wrote:
> > > > If this is a new failure (say in the last week), it could be an out
> > >
On 7/28/20 4:39 PM, Jeff Law wrote:
On Tue, 2020-07-28 at 15:29 -0500, Michael Catanzaro wrote:
On Tue, Jul 28, 2020 at 2:01 pm, Jeff Law wrote:
If this is a new failure (say in the last week), it could be an out
of memory
scenario. Try disabling LTO. The standard way to do that is
%define
We know about this possibility, but we still want to try to use RHEL
directly in Copr, as discussed here
https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/43SHF6FAE6Z4QKKFOVRWIKQDT5SSA5RI/
Silvie Chlupova
On Tue, Jul 28, 2020 at 9:16 PM R P Herrold
On Tue, 2020-07-28 at 15:29 -0500, Michael Catanzaro wrote:
> On Tue, Jul 28, 2020 at 2:01 pm, Jeff Law wrote:
> > If this is a new failure (say in the last week), it could be an out
> > of memory
> > scenario. Try disabling LTO. The standard way to do that is
> >
> > %define _lto_cflags
On Tue, Jul 28, 2020 at 2:01 pm, Jeff Law wrote:
If this is a new failure (say in the last week), it could be an out
of memory
scenario. Try disabling LTO. The standard way to do that is
%define _lto_cflags %{nil}
In your %build stanza in the spec file.
Heff
I agree, it's almost
d locally
> with mock. The copr failures are reproducible so I'm sure I'm doing
> something wrong, but I can't figure out what. Any ideas?
>
> [0] -
> https://copr.fedorainfracloud.org/coprs/nielsenb/msp430-development-tools/build/1577708/
> [1] -
> https://copr.fedorainfracloud.
301 - 400 of 1071 matches
Mail list logo
