On Tue, Aug 4, 2020, 01:50 Michel Alexandre Salim
wrote:
> Hi Fabio,
>
> On Mon, 2020-08-03 at 19:29 +0200, Fabio Valentini wrote:
> > On Mon, Aug 3, 2020 at 6:59 PM Hans de Goede
> > wrote:
> > > Hi,
> > >
> > > On 8/3/20 5:53 PM, Kevin Fenzi wrote:
> > > > On Mon, Aug 03, 2020 at 05:21:58PM +0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Mon, 2020-08-03 at 22:14 -0500, Richard Shaw wrote:
> Sometimes you need to get into the build directory, in my case for
> OpenColorIO I use help2man to generate some of the man pages.
>
> I had to rely on the power of Google/Gmail to find Neal's
I disabled debuginfo generation in ocaml-ppx-tools-versioned
temporarily.
It seems there is a bug in dune which causes the -g option to be
omitted when linking ppx extensions. This will require a fix to dune,
and then I should be able to reenable debuginfo again in this package.
(The same bug pos
Mohan,
Could you please check the script filling out the FTBFS tickets is doing
the right thing?
There was reported this ticket against Ruby:
https://bugzilla.redhat.com/show_bug.cgi?id=1865667
But I have rebuild Ruby already on Friday 31st:
https://koji.fedoraproject.org/koji/buildinfo?buildI
Kevin, thanks for caring about Trojitá. Just in case, I'm still keeping admin
ACL, especially for EPEL if you're not interested there as written.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fe
Hi,
On 8/4/20 2:29 AM, Kevin Fenzi wrote:
ok. I did what I could with the resources we have right now to improve
things on the s390x builders.
1. I noticed that we had the kvm instances oversubscribed on cpus (the
host has 32, we had 42 used). So, I lowered all the kvm builders to 3
vcpus from
Qiyu Yan 于2020年7月28日周二 下午1:56写道：
>
> Hello all!
>
> I am trying to package a golang program to fedora and found that I
> need to bring those dependencies:
>
> - https://bugzilla.redhat.com/show_bug.cgi?id=1861185
> - https://bugzilla.redhat.com/show_bug.cgi?id=1861187
> - https://bugzilla.redhat.c
Yesterday, I have updated my Rawhide and wondered why `dnf autoremove`
would want to remove earlyoom just to discover that soft dependency in
earlyoom was dropped [1] and hence nothing requires earlyoom and DNF is
free to remove this package (and it is possibly not installed anymore on
upgraded sys
On 04. 08. 20 8:49, Geoffrey Marr wrote:
"A system with multiple user accounts must be able to log in and out of said
accounts as presented by all release-blocking desktops in their default
configuration."
I would even go further and remove the "with multiple user accounts" condition.
Even on
On 04.08.20 10:47, Miro Hrončok wrote:
> I would even go further and remove the "with multiple user accounts"
> condition. Even on a singe user system, I'd like to be able to log out
> and back in again.
+1 on that.
Christopher
___
devel mailing list --
In https://kojipkgs.fedoraproject.org//work/tasks/5877/48605877/build.log
(from https://koji.fedoraproject.org/koji/taskinfo?taskID=48605877)
I'm still seeing errors like:
/usr/lib/rpm/debugedit:
/builddir/build/BUILDROOT/ocaml-ppx-tools-versioned-5.4.0-5.fc33.x86_64/usr/lib64/ocaml/ppx_tools_v
On Tue, Aug 4, 2020 at 8:14 AM Dominique Martinet
wrote:
>
> Hi,
>
> this is more of a head's up than a bug per se (well, I'm actually not
> sure if it's a bug, is it?), but I've had a package fail to build due to
> LTO and neon optimisations:
> https://kojipkgs.fedoraproject.org//work/tasks/2576/
Hi Richard,
On Tue, Aug 04, 2020 at 09:55:45AM +0100, Richard W.M. Jones wrote:
> In https://kojipkgs.fedoraproject.org//work/tasks/5877/48605877/build.log
> (from https://koji.fedoraproject.org/koji/taskinfo?taskID=48605877)
> I'm still seeing errors like:
>
> /usr/lib/rpm/debugedit:
> /build
On Mon, 2020-08-03 at 13:32 -0500, Richard Shaw wrote:
> I finally ran into another issue and used the vim faq. It was ":set
> cindent" that was causing the crazy indentation in spec file
> %changelogs.
> I still consider this a bug as the file doesn't even end in c, cpp,
> cxx, c++ etc.
yes , ci
On Tue, Aug 04, 2020 at 11:24:24AM +0200, Mark Wielaard wrote:
> Hi Richard,
>
> On Tue, Aug 04, 2020 at 09:55:45AM +0100, Richard W.M. Jones wrote:
> > In https://kojipkgs.fedoraproject.org//work/tasks/5877/48605877/build.log
> > (from https://koji.fedoraproject.org/koji/taskinfo?taskID=48605877)
On Tue, 4 Aug 2020 10:55:30 +0200
Christopher Engelhard wrote:
> On 04.08.20 10:47, Miro Hrončok wrote:
> > I would even go further and remove the "with multiple user accounts"
> > condition. Even on a singe user system, I'd like to be able to log
> > out and back in again.
>
> +1 on that.
If
* Daniel P. Berrangé:
> Taken from https://koji.fedoraproject.org/koji/taskinfo?taskID=48525923
Sorry, what would be more interesting is the linker invocation. The
build log does not show this, only the libtool invocation. We don't
really know what kind of transformations libtool does in this c
Peter Robinson wrote on Tue, Aug 04, 2020:
> > The "fix" here is simple and upstream is reactive so I'll just resubmit
> > the package with -mfpu=neon appended to linker args as well, but this
> > might come bite other projects as well.
>
> NO! That is not the fix. We explicitly don't build with N
Since this change, all (subsequent) CMake commands (after "%cmake")
MUST be used with the builddir argument ( "-B %{__cmake_builddir}" ).
I use in my packages "cmake -LAH" from time to time, to verify that
all CMake arguments (-D...) were passed and processed correctly, since
the processing logic
On 04.08.20 11:54, Paul Howarth wrote:
> If you remove the "with multiple user accounts" then being able to log
> in and out on a single-user system would satisfy the requirement even
> if the multi-user bug was present, which wouldn't be very helpful.
Hm, true. As usual, the devil is in the detai
Announcing the creation of a new nightly release validation test event
for Fedora 33 Rawhide 20200804.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki
Dominique Martinet wrote on Tue, Aug 04, 2020:
> I would appreciate slightly less conflicting exchanges in the future;
> I'm happy to do things differently if I'm pointed at problems but there
> *is* a change of behaviour with LTO and that isn't wrong.
>
> I apprently proceeded to fix it in a way
Hi all,
I have a number of packages that are FTBFS due to
https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds.
None of my packages has seen any commits for that change. I've read on
the list that packages that are considered "a complete mess" are not
touched. Are all my packag
Thank you for this headsup, I want to share some info too. I have found one
site https://soclikes.com/buy-instagram-mentions-user-followers, here you can
cheap get instagram mentions user followers. So, everyone, who need it, go here.
___
devel mailing
Thank you for this headsup, I want to share some info too. I have found one
site https://soclikes.com/buy-instagram-mentions-user-followers, here you can
cheap get instagram mentions user followers. So, everyone, who need it, go here.
___
devel mailing
On Mon, Aug 03, 2020 at 10:46:33PM +0100, Richard W.M. Jones wrote:
> On Mon, Aug 03, 2020 at 10:42:01PM +0100, Richard W.M. Jones wrote:
> > I can't reproduce this locally but it happens in Koji reliably enough:
> >
> > + /usr/lib/rpm/brp-strip /usr/bin/strip
> > /usr/bin/strip: unable to copy fi
On Tue, Aug 04, 2020 at 08:46:40AM +0100, Richard W.M. Jones wrote:
> I disabled debuginfo generation in ocaml-ppx-tools-versioned
> temporarily.
>
> It seems there is a bug in dune which causes the -g option to be
> omitted when linking ppx extensions. This will require a fix to dune,
> and then
The split is finished now in rawhide:
python-dns produces up-to-date python3-dns:
https://koji.fedoraproject.org/koji/taskinfo?taskID=48619774
python2-dns produces the old version of python2-dns with python 2
support: https://koji.fedoraproject.org/koji/taskinfo?taskID=48619230
Lumír
On 7/20
On Tue, Aug 4, 2020 at 7:32 AM Till Hofmann wrote:
>
> Hi all,
>
> I have a number of packages that are FTBFS due to
> https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds.
>
> None of my packages has seen any commits for that change. I've read on
> the list that packages that a
On Tue, Aug 4, 2020 at 12:42 PM Mike Johnson wrote:
> Thank you for this headsup, I want to share some info too. I have found
> one site https://soclikes.com/buy-instagram-mentions-user-followers, here
> you can cheap get instagram mentions user followers. So, everyone, who need
> it, go here.
>
On Tue, Aug 4, 2020 at 6:17 AM Michal Schorm wrote:
> Since this change, all (subsequent) CMake commands (after "%cmake")
> MUST be used with the builddir argument ( "-B %{__cmake_builddir}" ).
>
Ok, I'll use that in the future, but it still needs a mention in the
guidelines :)
Thanks,
RIchard
On Tue, Aug 04, 2020 at 12:02:05PM +0200, Florian Weimer wrote:
> * Daniel P. Berrangé:
>
> > Taken from https://koji.fedoraproject.org/koji/taskinfo?taskID=48525923
>
> Sorry, what would be more interesting is the linker invocation. The
> build log does not show this, only the libtool invocatio
On 28. 07. 20 11:56, Miro Hrončok wrote:
Dear maintainers.
Based on the current fail to build from source policy, the following packages
will be retired from Fedora 33 in a week.
Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
The packages in
On 04.08.2020 13:58, Kamil Paral wrote:
> So, how do we ban spammers from this list? CC devel-owner.
Allow only CLA+1 group members to post messages.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedorapro
On Tue, Aug 4, 2020 at 8:50 AM Geoffrey Marr wrote:
> At today's blocker review meeting[0], we ran across a bug[1] that we
> believe is bad enough to warrant blocker status, but as the criteria
> currently stand, does not violate any particular criterion. The bug in
> question has to do with logg
> > I have a number of packages that are FTBFS due to
> > https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds.
> >
> > None of my packages has seen any commits for that change. I've read on
> > the list that packages that are considered "a complete mess" are not
> > touched. Are
Hello, I've got this failure I cannot really understand, it happens on armv7hl
only (aarch64 and s390x were cancelled):
Checking for unpackaged file(s): /usr/lib/rpm/check-files
/builddir/build/BUILDROOT/prusa-slicer-2.2.0-4.fc33.arm
error: Installed (but unpackaged) file(s) found:
/usr/bin
On 04. 08. 20 14:54, Peter Robinson wrote:
What's the proper way to deal with a "make test" in %check, I've seen
a few get confused still by that even when the %cmake bits earlier in
the process pass, it seems there's not a %cmake_test equiv.
I've used:
%cmake_build -- test
There is also:
On Tue, Aug 4, 2020 at 9:10 AM Richard Shaw wrote:
>
> On Tue, Aug 4, 2020 at 6:17 AM Michal Schorm wrote:
>>
>> Since this change, all (subsequent) CMake commands (after "%cmake")
>> MUST be used with the builddir argument ( "-B %{__cmake_builddir}" ).
>
>
> Ok, I'll use that in the future, but
On Mon, Aug 3, 2020 at 8:32 PM Jerry James wrote:
>
> On Sun, Aug 2, 2020 at 11:27 AM Jerry James wrote:
> > You can point the finger of blame at least partly at me for this.
> > Version 0.15.0 of check introduced the use of
> > __attribute__((printf)) to check the arguments to some of the
>
On Tue, Aug 4, 2020 at 8:48 AM Kamil Paral wrote:
>
> Actually, I'd make this even simpler. We already have a Beta criterion
> related to logging out (among others):
> https://fedoraproject.org/wiki/Fedora_33_Beta_Release_Criteria#Shutdown.2C_reboot.2C_logout
>
> So let's just include logging in
On Tue, 4 Aug 2020 at 08:58, Kamil Paral wrote:
>
> On Tue, Aug 4, 2020 at 12:42 PM Mike Johnson wrote:
>>
>> Thank you for this headsup, I want to share some info too. I have found one
>> site https://soclikes.com/buy-instagram-mentions-user-followers, here you
>> can cheap get instagram menti
On 04/08/2020 14:11, Neal Gompa wrote:
On Tue, Aug 4, 2020 at 9:10 AM Richard Shaw wrote:
On Tue, Aug 4, 2020 at 6:17 AM Michal Schorm wrote:
Since this change, all (subsequent) CMake commands (after "%cmake")
MUST be used with the builddir argument ( "-B %{__cmake_builddir}" ).
Ok, I'll
On Tue, Aug 4, 2020 at 7:22 AM Tom Hughes via devel
wrote:
>
> On 04/08/2020 14:11, Neal Gompa wrote:
> > On Tue, Aug 4, 2020 at 9:10 AM Richard Shaw wrote:
> >>
> >> On Tue, Aug 4, 2020 at 6:17 AM Michal Schorm wrote:
> >>>
> >>> Since this change, all (subsequent) CMake commands (after "%cmake
Are there options for remote-wipe features for Fedora (or RHEL for that
matter)?
Ideally something integrated into the early boot process, as well as a
persistent service that is non-trivial to tamper with. It would naturally
need a network/internet based service as control point.
Googling and se
On Tue, 4 Aug 2020 at 09:37, Vitaly Zaitsev via devel
wrote:
>
> On 04.08.2020 13:58, Kamil Paral wrote:
> > So, how do we ban spammers from this list? CC devel-owner.
>
> Allow only CLA+1 group members to post messages.
>
I don't think mailman has any idea about group membership and I really
don
On Tue, 2020-08-04 at 09:20 +0200, Fabio Valentini wrote:
> On Tue, Aug 4, 2020, 01:50 Michel Alexandre Salim <
> mic...@michel-slm.name> wrote:
> > Hi Fabio,
> >
> > On Mon, 2020-08-03 at 19:29 +0200, Fabio Valentini wrote:
> > > I am already resubmitting all builds that failed in koji but that
>
On Tue, Aug 4, 2020 at 10:45 am, Vít Ondruch
wrote:
Yesterday, I have updated my Rawhide and wondered why `dnf autoremove`
would want to remove earlyoom just to discover that soft dependency in
earlyoom was dropped [1] and hence nothing requires earlyoom and DNF
is
free to remove this package
On 04.08.2020 15:48, Michael Catanzaro wrote:
> In the meantime, if you want to keep earlyoom, don't use autoremove.
sudo dnf mark install earlyoom
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproje
On Tue, Aug 4, 2020 at 9:55 AM Miro Hrončok wrote:
>
> On 04. 08. 20 14:54, Peter Robinson wrote:
> > What's the proper way to deal with a "make test" in %check, I've seen
> > a few get confused still by that even when the %cmake bits earlier in
> > the process pass, it seems there's not a %cmake_
On Tue, Jul 28, 2020 at 5:23 pm, Zbigniew Jędrzejewski-Szmek
wrote:
Right now there's the following scriptlet:
grep -q 'Generated by NetworkManager' /etc/resolv.conf 2>/dev/null &&
\
echo -e '/etc/resolv.conf was generated by
NetworkManager.\nConsider removing it to let systemd-resolved
On Tue, Aug 04, 2020 at 09:18:56AM -0400, Ben Cotton wrote:
> On Tue, Aug 4, 2020 at 8:48 AM Kamil Paral wrote:
> >
> > Actually, I'd make this even simpler. We already have a Beta criterion
> > related to logging out (among others):
> > https://fedoraproject.org/wiki/Fedora_33_Beta_Release_Crite
On Tue, Aug 4, 2020 at 3:12 PM Neal Gompa wrote:
> On Tue, Aug 4, 2020 at 9:10 AM Richard Shaw wrote:
> > On Tue, Aug 4, 2020 at 6:17 AM Michal Schorm wrote:
> >>
> >> Since this change, all (subsequent) CMake commands (after "%cmake")
> >> MUST be used with the builddir argument ( "-B %{__cmake
Hi Martin,
On Tue, 2020-08-04 at 09:40 -0400, Martin Langhoff wrote:
> Are there options for remote-wipe features for Fedora (or RHEL for
> that matter)?
>
> Ideally something integrated into the early boot process, as well as
> a persistent service that is non-trivial to tamper with. It would
>
On 03/08/20 18:03 +0200, Hans de Goede wrote:
Hi,
On 8/3/20 5:53 PM, Kevin Fenzi wrote:
On Mon, Aug 03, 2020 at 05:21:58PM +0200, Hans de Goede wrote:
Hi All,
I just noticed that a lot my packages got a FTBFS because of
failing to build on s390x. The first set of rebuilds failed with:
"Buil
On 03/08/20 19:29 +0200, Fabio Valentini wrote:
On Mon, Aug 3, 2020 at 6:59 PM Hans de Goede wrote:
Hi,
On 8/3/20 5:53 PM, Kevin Fenzi wrote:
> On Mon, Aug 03, 2020 at 05:21:58PM +0200, Hans de Goede wrote:
>> Hi All,
>>
>>
>> I just noticed that a lot my packages got a FTBFS because of
>> f
Dne 04. 08. 20 v 16:05 Vitaly Zaitsev via devel napsal(a):
> On 04.08.2020 15:48, Michael Catanzaro wrote:
>> In the meantime, if you want to keep earlyoom, don't use autoremove.
> sudo dnf mark install earlyoom
>
I think the "don't use autoremove" is better suggestion ATM, because I
don't really
On 03/08/20 13:32 -0500, Richard Shaw wrote:
I finally ran into another issue and used the vim faq. It was ":set
cindent" that was causing the crazy indentation in spec file %changelogs.
I still consider this a bug as the file doesn't even end in c, cpp, cxx,
c++ etc.
What's turning it on for
On Tue, Aug 4, 2020 at 12:33 AM Jeff Law wrote:
> If we're blowing up memory on the builder, then we should probably disable
> LTO on
> the 32bit platforms. This is something that was expected, though I didn't
> trip
> over any in my i686 testing (I have a theory for why, but it's not terribly
On 8/4/20 11:02 AM, Jerry James wrote:
On Tue, Aug 4, 2020 at 12:33 AM Jeff Law wrote:
If we're blowing up memory on the builder, then we should probably disable LTO
on
the 32bit platforms. This is something that was expected, though I didn't trip
over any in my i686 testing (I have a theory
On Tue, 2020-08-04 at 08:05 -0700, Tom Stellard wrote:
> On 8/4/20 11:02 AM, Jerry James wrote:
> > On Tue, Aug 4, 2020 at 12:33 AM Jeff Law wrote:
> > > If we're blowing up memory on the builder, then we should probably
> > > disable LTO on
> > > the 32bit platforms. This is something that was
On Tue, 2020-08-04 at 00:49 -0600, Geoffrey Marr wrote:
> At today's blocker review meeting[0], we ran across a bug[1] that we
> believe is bad enough to warrant blocker status, but as the criteria
> currently stand, does not violate any particular criterion. The bug in
> question has to do with lo
I'm considering to split the default configuration file in the chrony
package to make it easier for vendors, products, and configuration
tools to override some specific settings (like the default NTP
servers) by dropping a file into a directory, instead of having to
modify a packaged config file. I
On Monday, August 3, 2020 12:42:13 PM EDT Robbie Harwood wrote:
> > On Saturday, August 1, 2020 1:27:07 PM EDT Steven Grubb wrote:
> >> I was using my desktop system when I got logged out. After logging back
> >> in, I found this message in my logs:
> >>
> >> Aug 1 13:08:22 x2 journal[1751]: UID
Hi,
I have just orphaned these two packages:
https://src.fedoraproject.org/rpms/dbus-java
https://src.fedoraproject.org/rpms/libmatthew-java
I have not been able to provide them with the care they deserve.
If you are interested in the packages, please pick them up. Here's some
additional inform
On Tue, Aug 4, 2020 at 9:06 AM Jeff Law wrote:
> On Tue, 2020-08-04 at 08:05 -0700, Tom Stellard wrote:
> > I think this is also an OOM problem. I've seen similar error messages
> > before when a compiler process gets killed while it is in the middle of
> > piping assembly into the assembler.
>
On Tue, Aug 4, 2020 at 5:46 PM Jonathan Wakely
wrote:
>
> On 03/08/20 19:29 +0200, Fabio Valentini wrote:
> >On Mon, Aug 3, 2020 at 6:59 PM Hans de Goede wrote:
> >>
> >> Hi,
> >>
> >> On 8/3/20 5:53 PM, Kevin Fenzi wrote:
> >> > On Mon, Aug 03, 2020 at 05:21:58PM +0200, Hans de Goede wrote:
> >>
On Tue, Aug 4, 2020 at 11:50 AM Michal Schorm wrote:
>
> On Tue, Aug 4, 2020 at 3:12 PM Neal Gompa wrote:
> > On Tue, Aug 4, 2020 at 9:10 AM Richard Shaw wrote:
> > > On Tue, Aug 4, 2020 at 6:17 AM Michal Schorm wrote:
> > >>
> > >> Since this change, all (subsequent) CMake commands (after "%cm
On Tue, Aug 4, 2020 at 10:49 AM Jonathan Wakely
wrote:
> On 03/08/20 13:32 -0500, Richard Shaw wrote:
> >I finally ran into another issue and used the vim faq. It was ":set
> >cindent" that was causing the crazy indentation in spec file %changelogs.
> >
> >I still consider this a bug as the file
On 04/08/20 17:48 +0200, Fabio Valentini wrote:
On Tue, Aug 4, 2020 at 5:46 PM Jonathan Wakely
wrote:
On 03/08/20 19:29 +0200, Fabio Valentini wrote:
>On Mon, Aug 3, 2020 at 6:59 PM Hans de Goede wrote:
>>
>> Hi,
>>
>> On 8/3/20 5:53 PM, Kevin Fenzi wrote:
>> > On Mon, Aug 03, 2020 at 05:21:5
On 04/08/20 10:59 -0500, Richard Shaw wrote:
On Tue, Aug 4, 2020 at 10:49 AM Jonathan Wakely
wrote:
On 03/08/20 13:32 -0500, Richard Shaw wrote:
>I finally ran into another issue and used the vim faq. It was ":set
>cindent" that was causing the crazy indentation in spec file %changelogs.
>
>I
* Miro Hrončok:
> Hello, I've got this failure I cannot really understand, it happens on
> armv7hl only (aarch64 and s390x were cancelled):
>
> Checking for unpackaged file(s): /usr/lib/rpm/check-files
> /builddir/build/BUILDROOT/prusa-slicer-2.2.0-4.fc33.arm
> error: Installed (but unpackaged) fi
On Tue, Aug 4, 2020 at 7:49 AM Michael Catanzaro wrote:
> In the meantime, it will get
> pulled in on upgrades to F32 due to the old workaround, but it's not
> currently being pulled in on upgrades to F33.
Should we go back to the old workaround for F33? Madness for one more
release? And then dro
On Tue, Aug 04, 2020 at 05:11:49PM +0200, Miroslav Lichvar wrote:
> I'm considering to split the default configuration file in the chrony
> package to make it easier for vendors, products, and configuration
> tools to override some specific settings (like the default NTP
> servers) by dropping a fi
On Tue, Aug 4, 2020 at 8:46 AM Vít Ondruch wrote:
>
>
> Dne 04. 08. 20 v 16:05 Vitaly Zaitsev via devel napsal(a):
> > On 04.08.2020 15:48, Michael Catanzaro wrote:
> >> In the meantime, if you want to keep earlyoom, don't use autoremove.
> > sudo dnf mark install earlyoom
> >
>
> I think the "don
On Tuesday, 4 August 2020 12.42.30 WEST Neal Gompa wrote:
> Then you should do the following:
>
> %undefine __cmake_in_source_build
>
> %cmake
> %cmake_build
> %cmake_install
Would not it be more clean to place the %undefine line inside guards?
%if (0%{?rhel} || (0%{?fedora} && 0%{?fedora} < 33
On Tue, Aug 04, 2020 at 09:45:40AM -0400, Stephen John Smoogen wrote:
> On Tue, 4 Aug 2020 at 09:37, Vitaly Zaitsev via devel
> wrote:
> >
> > On 04.08.2020 13:58, Kamil Paral wrote:
> > > So, how do we ban spammers from this list? CC devel-owner.
> >
> > Allow only CLA+1 group members to post mes
On Tue, Aug 04, 2020 at 04:32:35PM +, Zbigniew Jędrzejewski-Szmek wrote:
> It's nice to not require any files in /etc (so for example the admin
> can do 'rm -rf /etc/*' to restore vendor defaults). So instead of
> using /etc/chrony.conf to load other files, please consider just
> building this
Once upon a time, Miroslav Lichvar said:
> The trouble is that a fragment having a different name cannot disable
> servers specified in a different fragment. If anaconda wanted to
> override the default servers, it would need to know the name of the
> fragment.
So, that brings up something I've b
On Tue, Aug 4, 2020 at 7:40 AM Martin Langhoff
wrote:
>
> Are there options for remote-wipe features for Fedora (or RHEL for that
> matter)?
>
> Ideally something integrated into the early boot process, as well as a
> persistent service that is non-trivial to tamper with. It would naturally
> n
On Tue, Aug 4, 2020 at 11:47 AM Neal Gompa wrote:
> On Tue, Aug 4, 2020 at 11:50 AM Michal Schorm wrote:
> >
> > On Tue, Aug 4, 2020 at 3:12 PM Neal Gompa wrote:
> > > On Tue, Aug 4, 2020 at 9:10 AM Richard Shaw
> wrote:
> > > > On Tue, Aug 4, 2020 at 6:17 AM Michal Schorm
> wrote:
> > > >>
>
On Tue, Aug 4, 2020 at 1:28 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Tue, Aug 04, 2020 at 05:11:49PM +0200, Miroslav Lichvar wrote:
> > I'm considering to split the default configuration file in the chrony
> > package to make it easier for vendors, products, and configuration
> > tools to over
On Tue, Aug 4, 2020 at 1:40 PM José Abílio Matos wrote:
>
> On Tuesday, 4 August 2020 12.42.30 WEST Neal Gompa wrote:
> > Then you should do the following:
> >
> > %undefine __cmake_in_source_build
> >
> > %cmake
> > %cmake_build
> > %cmake_install
>
> Would not it be more clean to place the %unde
On 04. 08. 20 18:16, Florian Weimer wrote:
* Miro Hrončok:
Hello, I've got this failure I cannot really understand, it happens on
armv7hl only (aarch64 and s390x were cancelled):
Checking for unpackaged file(s): /usr/lib/rpm/check-files
/builddir/build/BUILDROOT/prusa-slicer-2.2.0-4.fc33.arm
e
On Tue, Aug 04, 2020 at 07:05:45PM +0200, Miroslav Lichvar wrote:
> On Tue, Aug 04, 2020 at 04:32:35PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > It's nice to not require any files in /etc (so for example the admin
> > can do 'rm -rf /etc/*' to restore vendor defaults). So instead of
> > using /
On Tue, Aug 04, 2020 at 07:52:54PM +0200, Miro Hrončok wrote:
> On 04. 08. 20 18:16, Florian Weimer wrote:
> > * Miro Hrončok:
> >
> > > Hello, I've got this failure I cannot really understand, it happens on
> > > armv7hl only (aarch64 and s390x were cancelled):
> > >
> > > Checking for unpackage
On Tue, 2020-08-04 at 11:34 -0700, Kevin Fenzi wrote:
> On Tue, Aug 04, 2020 at 07:52:54PM +0200, Miro Hrončok wrote:
> > On 04. 08. 20 18:16, Florian Weimer wrote:
> > > * Miro Hrončok:
> > >
> > > > Hello, I've got this failure I cannot really understand, it happens on
> > > > armv7hl only (aarc
On Fri, 2020-07-31 at 12:11 -0600, Jeff Law wrote:
> Note the linker bug should be fixed now. So you should be able to
> rebuild man-db with LTO now.
Thank you, done.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email t
After discussing this with FESCo last week, this is submitted at a F33
change since it's largely a paperwork exercise at this point.
https://fedoraproject.org/wiki/Changes/IoTEditionPromotion
= Promote IoT to an Edition =
== Summary ==
Promote Fedora IoT to an official Fedora Edition.
== Owner
On 04.08.2020 16:45, Vít Ondruch wrote:
> I think the "don't use autoremove" is better suggestion ATM, because I
> don't really want to keep earlyoom on the system in case there is
> systemd-oomd or whatever should be the successor.
You can always easily swap one package to another:
sudo dnf swap
On 27. 07. 20 21:24, Jeff Law wrote:
In the immediate term, disabling LTO seems reasonable.
%define _lto_cflags %{nil}
Can this please be documented at:
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflags.md
?
I'd do it, but I don't know what useful to write about
* Jeff Law:
> Actually, isn't it "just" 234MB. Still I'm surprised why that failed. Do we
> have more than one build running at a time on those boxes?
It's a 32-bit build. I assume it's not the first large allocation.
(FWIW, GDB always prints “virtual memory exhausted”, even if the malloc
fail
On Tue, Aug 4, 2020 at 10:31 am, Chris Murphy
wrote:
Should we go back to the old workaround for F33? Madness for one more
release? And then drop the madness once there's a dnf solution?
We could, but we have installed so many other things that it's becoming
quite hard to keep track of them a
When ocamlopt is used with binutils 2.35 to link an executable, we now
get warnings that look like this:
/usr/bin/ld: tests/test_topsort.o: warning: relocation in read-only
section `.text'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE
There is an open upstream issue:
https://github.com/ocam
Thanks Jerry for providing all the details about the z3 soname bump.
FYI: cppcheck has been rebuilt now [1]
Wolfgang
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=48648878
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
On 04. 08. 20 21:36, Florian Weimer wrote:
Does LTO produce more complicated debugging information? Then maybe
disabling LTO on armhfp is a workaround.
I've actually tried this before reading your e-mail and went to report back:
%ifarch %{arm}
%global _lto_cflags %{nil}
%endif
This makes it
On Tue, Aug 04, 2020 at 01:48:45PM -0600, Jerry James wrote:
> When ocamlopt is used with binutils 2.35 to link an executable, we now
> get warnings that look like this:
>
> /usr/bin/ld: tests/test_topsort.o: warning: relocation in read-only
> section `.text'
> /usr/bin/ld: warning: creating DT_TE
Here are some upcoming deadlines and milestones for the Fedora 33
development cycle:
* 2020-08-11 - Change checkpoint: code complete (testable)
* 2020-08-11 - Branch Fedora 33 from Rawhide
* 2020-08-25 - Change checkpoint: 100% code complete deadline
* 2020-08-25 - Beta freeze begins
As a reminde
Am 05.08.20 um 01:52 schrieb Ben Cotton:
Here are some upcoming deadlines and milestones for the Fedora 33
development cycle:
Are you sure, that boost1.73 should be part of fedora 33 ?
It lloks like boost.173 would require a future verson of gcc/g++
ao long
MUFTI
_
Hi all,
I would like to announce sane-airscan project [1] will be shipped in the
official Fedora repositories from Fedora 32 [2].
sane-airscan implements a backend for Microsoft WSD and ESCL (usually
called AirScan, originating from Apple) protocols, which are common in
newer (2012+) scanners and
1 - 100 of 101 matches
Mail list logo
