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
https://fedorapeople.org/groups/389ds/ci/nightly/2020/08/05/report-389-ds-base-1.4.4.4-20200804gitb1e4f5f.fc32.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
https://bugzilla.redhat.com/show_bug.cgi?id=1862985
--- Comment #7 from Fedora Update System ---
FEDORA-EPEL-2020-5ec68eace4 has been pushed to the Fedora EPEL 8 testing
repository.
You can provide feedback for this update here:
https://bugzilla.redhat.com/show_bug.cgi?id=1858481
--- Comment #13 from Fedora Update System ---
FEDORA-MODULAR-2020-b67d5de786 has been pushed to the Fedora 31 Modular testing
repository.
You can provide feedback for this update here:
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
https://bugzilla.redhat.com/show_bug.cgi?id=1860598
--- Comment #9 from Fedora Update System ---
FEDORA-MODULAR-2020-b67d5de786 has been pushed to the Fedora 31 Modular testing
repository.
You can provide feedback for this update here:
https://bugzilla.redhat.com/show_bug.cgi?id=1858528
--- Comment #11 from Fedora Update System ---
FEDORA-MODULAR-2020-b67d5de786 has been pushed to the Fedora 31 Modular testing
repository.
You can provide feedback for this update here:
https://bugzilla.redhat.com/show_bug.cgi?id=1855963
--- Comment #14 from Fedora Update System ---
FEDORA-MODULAR-2020-b67d5de786 has been pushed to the Fedora 31 Modular testing
repository.
You can provide feedback for this update here:
https://bugzilla.redhat.com/show_bug.cgi?id=1846729
--- Comment #11 from Fedora Update System ---
FEDORA-MODULAR-2020-b67d5de786 has been pushed to the Fedora 31 Modular testing
repository.
You can provide feedback for this update here:
https://bugzilla.redhat.com/show_bug.cgi?id=1850928
--- Comment #12 from Fedora Update System ---
FEDORA-MODULAR-2020-b67d5de786 has been pushed to the Fedora 31 Modular testing
repository.
You can provide feedback for this update here:
https://bugzilla.redhat.com/show_bug.cgi?id=1858467
--- Comment #12 from Fedora Update System ---
FEDORA-MODULAR-2020-b67d5de786 has been pushed to the Fedora 31 Modular testing
repository.
You can provide feedback for this update here:
https://bugzilla.redhat.com/show_bug.cgi?id=1862984
--- Comment #7 from Fedora Update System ---
FEDORA-EPEL-2020-5ec68eace4 has been pushed to the Fedora EPEL 8 testing
repository.
You can provide feedback for this update here:
https://bugzilla.redhat.com/show_bug.cgi?id=1862983
--- Comment #7 from Fedora Update System ---
FEDORA-EPEL-2020-5ec68eace4 has been pushed to the Fedora EPEL 8 testing
repository.
You can provide feedback for this update here:
https://bugzilla.redhat.com/show_bug.cgi?id=1854141
--- Comment #11 from Fedora Update System ---
FEDORA-MODULAR-2020-b67d5de786 has been pushed to the Fedora 31 Modular testing
repository.
You can provide feedback for this update here:
https://bugzilla.redhat.com/show_bug.cgi?id=1850935
--- Comment #11 from Fedora Update System ---
FEDORA-MODULAR-2020-b67d5de786 has been pushed to the Fedora 31 Modular testing
repository.
You can provide feedback for this update here:
https://bugzilla.redhat.com/show_bug.cgi?id=1849996
--- Comment #11 from Fedora Update System ---
FEDORA-MODULAR-2020-b67d5de786 has been pushed to the Fedora 31 Modular testing
repository.
You can provide feedback for this update here:
https://bugzilla.redhat.com/show_bug.cgi?id=1849342
--- Comment #11 from Fedora Update System ---
FEDORA-MODULAR-2020-b67d5de786 has been pushed to the Fedora 31 Modular testing
repository.
You can provide feedback for this update here:
https://bugzilla.redhat.com/show_bug.cgi?id=1858528
Fedora Update System changed:
What|Removed |Added
Fixed In Version|perl-File-Path-2.17-1.fc33 |perl-File-Path-2.17-1.fc33
https://bugzilla.redhat.com/show_bug.cgi?id=1855963
--- Comment #13 from Fedora Update System ---
FEDORA-MODULAR-2020-bfc9507514 has been pushed to the Fedora 32 Modular testing
repository.
You can provide feedback for this update here:
https://bugzilla.redhat.com/show_bug.cgi?id=1858481
--- Comment #12 from Fedora Update System ---
FEDORA-MODULAR-2020-bfc9507514 has been pushed to the Fedora 32 Modular testing
repository.
You can provide feedback for this update here:
https://bugzilla.redhat.com/show_bug.cgi?id=1854141
--- Comment #10 from Fedora Update System ---
FEDORA-MODULAR-2020-bfc9507514 has been pushed to the Fedora 32 Modular testing
repository.
You can provide feedback for this update here:
https://bugzilla.redhat.com/show_bug.cgi?id=1858528
--- Comment #9 from Fedora Update System ---
FEDORA-MODULAR-2020-bfc9507514 has been pushed to the Fedora 32 Modular testing
repository.
You can provide feedback for this update here:
https://bugzilla.redhat.com/show_bug.cgi?id=1860598
--- Comment #8 from Fedora Update System ---
FEDORA-MODULAR-2020-bfc9507514 has been pushed to the Fedora 32 Modular testing
repository.
You can provide feedback for this update here:
https://bugzilla.redhat.com/show_bug.cgi?id=1858467
--- Comment #11 from Fedora Update System ---
FEDORA-MODULAR-2020-bfc9507514 has been pushed to the Fedora 32 Modular testing
repository.
You can provide feedback for this update here:
https://bugzilla.redhat.com/show_bug.cgi?id=1850935
--- Comment #10 from Fedora Update System ---
FEDORA-MODULAR-2020-bfc9507514 has been pushed to the Fedora 32 Modular testing
repository.
You can provide feedback for this update here:
https://bugzilla.redhat.com/show_bug.cgi?id=1846729
--- Comment #10 from Fedora Update System ---
FEDORA-MODULAR-2020-bfc9507514 has been pushed to the Fedora 32 Modular testing
repository.
You can provide feedback for this update here:
https://bugzilla.redhat.com/show_bug.cgi?id=1849996
--- Comment #10 from Fedora Update System ---
FEDORA-MODULAR-2020-bfc9507514 has been pushed to the Fedora 32 Modular testing
repository.
You can provide feedback for this update here:
https://bugzilla.redhat.com/show_bug.cgi?id=1849342
--- Comment #10 from Fedora Update System ---
FEDORA-MODULAR-2020-bfc9507514 has been pushed to the Fedora 32 Modular testing
repository.
You can provide feedback for this update here:
https://bugzilla.redhat.com/show_bug.cgi?id=1850928
--- Comment #11 from Fedora Update System ---
FEDORA-MODULAR-2020-bfc9507514 has been pushed to the Fedora 32 Modular testing
repository.
You can provide feedback for this update here:
The following Fedora EPEL 6 Security updates need testing:
Age URL
12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-713ebad0a1
golang-1.13.14-1.el6
12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d1b24a2a25
snmptt-1.4.2-1.el6
The following builds have been
https://bugzilla.redhat.com/show_bug.cgi?id=1862985
--- Comment #6 from Fedora Update System ---
FEDORA-2020-4a10aa5f4d has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade
https://bugzilla.redhat.com/show_bug.cgi?id=1862984
--- Comment #6 from Fedora Update System ---
FEDORA-2020-4a10aa5f4d has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade
https://bugzilla.redhat.com/show_bug.cgi?id=1862983
--- Comment #6 from Fedora Update System ---
FEDORA-2020-4a10aa5f4d has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade
https://bugzilla.redhat.com/show_bug.cgi?id=1862984
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #5 from
https://bugzilla.redhat.com/show_bug.cgi?id=1862985
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #5 from
https://bugzilla.redhat.com/show_bug.cgi?id=1862983
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #5 from
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
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
Hey Pythonistas,
I've just retired Python 2.6 and Python 3.4 from rawhide (Fedora 33+).
- https://fedoraproject.org/wiki/Changes/RetirePython26
- https://fedoraproject.org/wiki/Changes/RetirePython34
If you use any of the mentioned Python versions on Fedora rawhide for CI
purposes, you
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
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
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
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:
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
* 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
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
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
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
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 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
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
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
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 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
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
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
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 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
>
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
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
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
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} <
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
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
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
* 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)
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
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
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 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
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 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.
>
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
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
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.
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
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 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, 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 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
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
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
>>
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:
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 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
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):
> >
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
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
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 --
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
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, 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
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
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
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,
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
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 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 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 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
1 - 100 of 191 matches
Mail list logo
