Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[John M. Harris Jr]

On Tuesday, August 4, 2020 1:45:52 AM MST 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 (and it is possibly not installed anymore on
> upgraded systems).
> 
> Therefore I wonder what is the status of EarlyOOM. Should I let the
> package go? If not, then the situation should be fixed somehow, probably
> either by reverting the revert or adding the dependency into
> fedora-release as was proposed elsewhere.

Generally, if you let the package go, your system won't suffer from your 
processes getting killed needlessly. This is likely a benefit, so I don't know 
if this is really a bug.

-- 
John M. Harris, Jr.

___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Driverless scanning for WSD and ESCL supported scanners is coming

[Zdenek Dohnal]

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 multi-function devices for scanning.

Using sane-airscan, newer devices don't need vendor proprietary software
for scanning any longer (e.g. hplip with its hp-plugin).

The project is divided into main package - sane-airscan - which contains
helper tool - airscan-discover - for discovering devices in setups,
where automatic DNS-SD discovery doesn't do the trick, and subpackage -
libsane-airscan - which the main package requires and the common known
project for scanning - sane-backends - will require to get the backend
into common scanning stack installation.

Please feel free to test it.


Have a nice day,

Zdenek


[1] https://github.com/alexpevzner/sane-airscan

[2] https://bodhi.fedoraproject.org/updates/FEDORA-2020-841f4ce8df

-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C




signature.asc
Description: OpenPGP digital signature
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Reminder: upcoming Fedora 33 deadlines & milestones

[J. Scheurich]

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
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Reminder: upcoming Fedora 33 deadlines & milestones

[Ben Cotton]

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 reminder, the code complete (testable) deadline means changes
should be in a testable state. Update the tracking bug to be in a
MODIFIED state when it is ready. Changes that are not in MODIFIED or
ON_QA (100% code complete) will be considered incomplete and are
subject to being delayed to Fedora 34.

For more schedule dates, see
https://fedorapeople.org/groups/schedule/f-33/f-33-devel-tasks.html

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: OCaml + binutils 2.35 on i386

[Richard W.M. Jones]

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_TEXTREL in a PIE

32 bit is an architectural problem for OCaml.  Specifically because of
how the GC block headers are implemented it limits arrays / strings to
a maximum of 4M entries / 4M bytes, which was probably fine back in
the day but is unreasonably small today. [1]

So if something OCaml-related fails on i686, it's not something we
should worry about.  IMHO ExcludeArch %{ix86} and move on.

Rich.

[1] This is also the reason why multilib is completely irrelevant to OCaml
(and another reason why multilib should die).

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: ARM: Installed (but unpackaged) file(s) found: /usr/bin/....gdb-index-9pY4kY

[Miro Hrončok]

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 build.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: z3 soname bump

[Wolfgang Stoeggl via devel]

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 send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

OCaml + binutils 2.35 on i386

[Jerry James]

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/ocaml/ocaml/issues/9800

Here is an example of a build failure due to this:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1576636

FYI.
-- 
Jerry James
http://www.jamezone.org/
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Michael Catanzaro]

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 all, and if we're going to have a 
workaround for any one package I would recommend we use the same 
workaround for them all. And that's the merge request I have above. And 
for that to work, we would need to require that anyone touching comps 
also add a corresponding Recommends: in fedora-release. That would be 
unfortunate.


I'd rather have a proper dnf fix in place for F33.

___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: ARM: Installed (but unpackaged) file(s) found: /usr/bin/....gdb-index-9pY4kY

[Florian Weimer]

* 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
failure has a different cause.)

Does LTO produce more complicated debugging information?  Then maybe
disabling LTO on armhfp is a workaround.  There's also a way to disable
debuginfo package generation altogether, something along these lines
(untested):

%define debug_package %{nil}
%define __debug_install_post %{nil}
%global __debug_package %{nil}
%undefine _debugsource_packages
%undefine _debuginfo_subpackages
%undefine _unique_debug_names
%undefine _unique_debug_srcs

Thanks,
Florian
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: ar (binutils) segfaulting in Rawhide - known bug?

[Miro Hrončok]

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

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Vitaly Zaitsev via devel]

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 earlyoom systemd-oomd --allowerasing

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

F33 Change: Promote IoT to an Edition (Incredibly late System-Wide Change)

[Ben Cotton]

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

* Name: [[User:Pbrobinson|Peter Robinson]]
* Email: pbrobin...@gmail.com
* Responsible WG: IoT


== Detailed Description ==

As part of the newly-approved [[Editions/Promotion_Process|Edition
Promotion Process]], this promotes Fedora IoT to Edition status
alongside Workstation and Server.

Full status is documented in the
[https://docs.fedoraproject.org/en-US/iot/edition-promotion/ IoT
docs]. This change is primarily a paperwork exercise as the necessary
work has been completed or is in-progress.

== Feedback ==

== Benefit to Fedora ==

Makes Fedora IoT more prominent, which will help spread adoption. This
in turn will help drive improvements in Fedora IoT and other
ostree-based deliverables. It also gives Fedora a strong presence in
the IoT ecosystem.

== Scope ==
* Proposal owners: See the
[https://docs.fedoraproject.org/en-US/iot/edition-promotion/ IoT docs]

* Other developers: N/A
* Release engineering: work already completed
* Policies and guidelines: N/A
* Trademark approval:
[https://pagure.io/Fedora-Council/tickets/issue/277 Granted]

== Upgrade/compatibility impact ==
N/A

== How To Test ==
[https://fedoraproject.org/wiki/Category:IoT_Acceptance_Test_Cases Test cases]

== Dependencies ==
See the [https://docs.fedoraproject.org/en-US/iot/edition-promotion/ IoT docs]

== Contingency Plan ==

* Contingency mechanism: (What to do?  Who will do it?) Delay
promotion until F34
* Contingency deadline: F33 Final release date
* Blocks release? No

== Documentation ==
https://docs.fedoraproject.org/en-US/iot/

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: ar (binutils) segfaulting in Rawhide - known bug?

[Nikola Forró]

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 to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: ARM: Installed (but unpackaged) file(s) found: /usr/bin/....gdb-index-9pY4kY

[Jeff Law]

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 (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/prusa-slicer.wrapped.gdb-index-9pY4kY
> > > >  Installed (but unpackaged) file(s) found:
> > > > /usr/bin/prusa-slicer.wrapped.gdb-index-9pY4kY
> > > > 
> > > > The gdb-index-9pY4kY files are not created explcitiyl by anything in
> > > > the package.
> > > 
> > > This happens if debuginfo generation fails with a crash:
> > > 
> > > extracting debug info from 
> > > /builddir/build/BUILDROOT/prusa-slicer-2.2.0-4.fc33.arm/usr/bin/prusa-slicer.wrapped
> > > ../../gdb/utils.c:691: internal-error: virtual memory exhausted: can't 
> > > allocate 234696314 bytes.
> > > A problem internal to GDB has been detected,
> > > further debugging may prove unreliable.
> > > Quit this debugging session? (y or n) [answered Y; input not from 
> > > terminal]
> > > This is a bug, please report it.  For instructions, see:
> > > ;.
> > > /usr/bin/gdb-add-index: line 106: 22699 Aborted (core 
> > > dumped) $GDB --batch -nx -iex 'set auto-load no' -ex "file $file" -ex 
> > > "save gdb-index $dwarf5 $dir"
> > > 
> > > The crash is normally ignored.
> > > 
> > > > Does anybody know what this is?
> > > 
> > > Not enough RAM, apparently.
> > 
> > Thank you Florian, I wonder how can I workaround this issu. Usually this was
> > to lower parallelism during build, but I suppose extracting debug info is
> > not parallelized :/
> 
> I'll note that armv7 buildvm's have 24GB memory. 
> 
> Trying to allocate 234GB doesn't seem very friendly to it working and
> sounds more like a bug somewhere to me.
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?

jeff
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: ARM: Installed (but unpackaged) file(s) found: /usr/bin/....gdb-index-9pY4kY

[Kevin Fenzi]

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 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/prusa-slicer.wrapped.gdb-index-9pY4kY
> > >  Installed (but unpackaged) file(s) found:
> > > /usr/bin/prusa-slicer.wrapped.gdb-index-9pY4kY
> > > 
> > > The gdb-index-9pY4kY files are not created explcitiyl by anything in
> > > the package.
> > 
> > This happens if debuginfo generation fails with a crash:
> > 
> > extracting debug info from 
> > /builddir/build/BUILDROOT/prusa-slicer-2.2.0-4.fc33.arm/usr/bin/prusa-slicer.wrapped
> > ../../gdb/utils.c:691: internal-error: virtual memory exhausted: can't 
> > allocate 234696314 bytes.
> > A problem internal to GDB has been detected,
> > further debugging may prove unreliable.
> > Quit this debugging session? (y or n) [answered Y; input not from terminal]
> > This is a bug, please report it.  For instructions, see:
> > .
> > /usr/bin/gdb-add-index: line 106: 22699 Aborted (core 
> > dumped) $GDB --batch -nx -iex 'set auto-load no' -ex "file $file" -ex "save 
> > gdb-index $dwarf5 $dir"
> > 
> > The crash is normally ignored.
> > 
> > > Does anybody know what this is?
> > 
> > Not enough RAM, apparently.
> 
> Thank you Florian, I wonder how can I workaround this issu. Usually this was
> to lower parallelism during build, but I suppose extracting debug info is
> not parallelized :/

I'll note that armv7 buildvm's have 24GB memory. 

Trying to allocate 234GB doesn't seem very friendly to it working and
sounds more like a bug somewhere to me.

kevin


signature.asc
Description: PGP signature
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Switching package to fragmented default configuration

[Zbigniew Jędrzejewski-Szmek]

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 /etc/chrony.conf to load other files, please consider just
> > building this logic directly into the code. There is also no need to
> > make those config paths configurable.
> 
> That's possible (the paths could be hardcoded in the systemd unit
> file), but is it a good idea to force the users to use the new system?
> If someone has a modified config, or is using one of the many ansible
> roles for configuring NTP for example, why should it stop working? We
> don't have to break configuration tools that just generate a config
> from scratch.

Backwards compatiblity should be kept obviously. In systemd we look at
{/usr,/usr/local,/etc,/run}/foo.conf and
{/usr,/usr/local,/etc,/run}/foo.conf.d/*.conf, so foo.conf is the main
config file, while the "drop-ins" in /etc/ have higher priority and
server as overrides. This is backwards compatible with having just
/etc/foo.conf.

> > > My concern is that it will basically break all existing tools that
> > > need to check and/or modify the configuration (e.g. anaconda). They
> > > will need to know the naming of the files which have specific settings
> > > in order to override them, or implement a parser duplicating the
> > > chronyd logic to figure out which files are loaded from where.
> > 
> > The whole goal of the config-in-dropin-files-logic is that anaconda
> > wouldn't parse existing config, it would just write
> > /etc/chrony.d/50-anaconda.conf that would override only the parts it
> > cares about.
> 
> 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. In some cases users/vendors/products may want to specify
> additional servers, sometimes replace them.

This can be handled by having a directive that means "wipe previous
config for this setting". In systemd we handle this by treating an
empty assignment as special:
SystemCallFilter=open
SystemCallFilter=
SystemCallFilter=write
SystemCallFilter=read close
is equivalent to SystemCallFilter=write read close.

> > Also, please don't invent a new logic — just follow the same one that
> > systemd does [1]. This has the advantage that if something *needs* to
> > look all of config, it can reuse what an existing loader. Also, admins
> > don't need to learn a new set of rules. Ideally,
> > 'systemd-analyze cat-config chrony.conf' would just work.
> 
> I was following the liboverdrop logic, which probably adopted the
> systemd convention. For printing the whole configuration there is now
> a "chronyd -p" command. The systemd cat-config command seems to expect
> the ini-style syntax. That's not going to work here.

Zbyszek
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: ARM: Installed (but unpackaged) file(s) found: /usr/bin/....gdb-index-9pY4kY

[Miro Hrončok]

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
error: Installed (but unpackaged) file(s) found:
/usr/bin/prusa-slicer.wrapped.gdb-index-9pY4kY
 Installed (but unpackaged) file(s) found:
/usr/bin/prusa-slicer.wrapped.gdb-index-9pY4kY

The gdb-index-9pY4kY files are not created explcitiyl by anything in
the package.


This happens if debuginfo generation fails with a crash:

extracting debug info from 
/builddir/build/BUILDROOT/prusa-slicer-2.2.0-4.fc33.arm/usr/bin/prusa-slicer.wrapped
../../gdb/utils.c:691: internal-error: virtual memory exhausted: can't allocate 
234696314 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]
This is a bug, please report it.  For instructions, see:
.
/usr/bin/gdb-add-index: line 106: 22699 Aborted (core dumped) $GDB --batch -nx -iex 
'set auto-load no' -ex "file $file" -ex "save gdb-index $dwarf5 $dir"

The crash is normally ignored.


Does anybody know what this is?


Not enough RAM, apparently.


Thank you Florian, I wonder how can I workaround this issu. Usually this was to 
lower parallelism during build, but I suppose extracting debug info is not 
parallelized :/


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What to do about FTBFS because auf cmake change?

[Neal Gompa]

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 %undefine line inside guards?
>
> %if (0%{?rhel} || (0%{?fedora} && 0%{?fedora} < 33))
> %undefine __cmake_in_source_build
> %endif
>
> I am asking this because I always forgot when was a given functionality
> introduced or it is no more required.
>
> A simple example is "rm -rf $RPM_BUILD_ROOT" that I know that it is not
> necessary in Fedora anymore but it is very easy to know in which epel version
> it is necessary ( <= 6 I think).
>
> Does that solution makes sense or am I over-engineering this?
>

You're overthinking this a bit. :)

Undefining the variable makes it consistent across the board, and
there's no impact caused by undefining a variable that's already not
defined. You *can* do that if you want, but it doesn't matter. :)


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Switching package to fragmented default configuration

[Neal Gompa]

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 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. It seems to be a modern trend, used
> > by many packages in Fedora, and I have received some RFEs to adopt
> > in chrony.
> >
> > The default /etc/chrony.conf would just have a single directive
> > loading configuration fragments from /etc/chrony.d and
> > /var/lib/chrony.d (and maybe also /var/run/chrony.d).
>
> 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 logic directly into the code. There is also no need to
> make those config paths configurable.
>
> As to the locations to look at: /usr/lib or /usr/share (packaged
> distro defaults), /usr/local/lib or /usr/share (local installed
> defaults), /etc (admin overrides), /run (temporary overrides) are the
> standard prefixes to look at. /var/lib is for persistent application
> state, not config.
>
> > My concern is that it will basically break all existing tools that
> > need to check and/or modify the configuration (e.g. anaconda). They
> > will need to know the naming of the files which have specific settings
> > in order to override them, or implement a parser duplicating the
> > chronyd logic to figure out which files are loaded from where.
>
> The whole goal of the config-in-dropin-files-logic is that anaconda
> wouldn't parse existing config, it would just write
> /etc/chrony.d/50-anaconda.conf that would override only the parts it
> cares about.
>
> Also, please don't invent a new logic — just follow the same one that
> systemd does [1]. This has the advantage that if something *needs* to
> look all of config, it can reuse what an existing loader. Also, admins
> don't need to learn a new set of rules. Ideally,
> 'systemd-analyze cat-config chrony.conf' would just work.
>
> > Also,
> > I'm not sure how user-friendly this is for regular users who modify
> > the configuration manually.
> >
> > Are there any recommendations for switching an existing single-config
> > package to a fully fragmented configuration? Is it worth the trouble,
> > or do you have any other suggestions?
>
> Yes, it's definitely worth the trouble, it makes many things easier and
> more robust.
>
> Zbyszek
>
> [1] We don't have a nice description of the logic anywhere. systemd.unit(5)
> is the canonical source, but there there are many complications which
> don't matter in the general case. Actually zram-generator.conf(5) which
> was added recently seems to be a better reference:
> https://github.com/systemd/zram-generator/blob/master/man/zram-generator.conf.md.

The libeconf library[0][1] makes it easy to implement the systemd-like
drop-in and override configuration behavior. This is how PAM does
it[2], and util-linux[3] will as well.

I would suggest considering implementing it in chrony by using this
library, as it simplifies the effort required to implement this
behavior.

[0]: https://github.com/openSUSE/libeconf
[1]: https://fosdem.org/2020/schedule/event/ilbsclte/
[2]: 
https://github.com/linux-pam/linux-pam/commit/65d6735c5949ec233df9813f734e918a93fa36cf
[3]: 
https://github.com/karelzak/util-linux/commit/d5e8818e03e581e2e4fab8942a13a4c6731f5da9



--
真実はいつも一つ！/ Always, there's only one truth!
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: %{_vpath_builddir} needs to be in the Cmake packaging guidelines

[Richard Shaw]

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:
> > > >>
> > > >> 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 :)
> > > >
> > > You are not supposed to use %__cmake_builddir.
> >
> > You say I'm not supposed to use that macro, but that's exactly the macro
> I need.
> >
> > > That macro only exists
> > > so we don't have to mutate %_vpath_builddir when switching behaviors
> > > through %__cmake_in_source_build.
> >
> > Any other way would do exactly what you just wrote here - I would be
> > re-implementing this macro - which doesn't make sense.
> >
> > I'm open to new ideas, but this (using the "%__cmake_builddir" )
> > sounds like the most straightforward and easy way to do it.
> >
>
> It is not documented, and eventually will be removed. So don't rely on
> it. If you want to change the build directory, set %_vpath_builddir
> instead.
>

In my case I don't want to change it, I just need to know what it is for
some of my projects.

Thanks,
Richard
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Remote wipe options for Fedora?

[Chris Murphy]

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 
> need a network/internet based service as control point.
>
> Googling and searching the mailing list has not turned any leads.
>
> It is a can of worms, naturally, and I am well aware of limitations, and 
> tricky tradeoffs in remote-wipe schemes. For some use cases, including one 
> affecting me, it can reduce attack surface. I am hoping that some solutions 
> exist, I would be happy to improve, package, integrate...
>

Such a thing doesn't currently exist. There are pieces here and there,
that could be tied together, or used as references:

- livecd-tools and dracut have a reset boot parameter for the live
read-write persistent overlay. We don't use such a thing in
conventionally installed systems though.

- Silverblue/rpm-ostree and Fedora Core OS based systems have
'rpm-ostree reset' to blow away overlays. I'm not sure if it currently
has an option to blow away user home as well as /etc and /var. If not,
it could be extended.

- Perhaps this is something either ignition (CoreOS installer) or
systemd-repart could do? Possibly more the former than the latter,
because systemd-repart use case is more about adding, not removing,
and growing, not shrinking.

- If you were to use 'blkdiscard' on an entire partition or drive,
doesn't mean the data is truly gone, i.e. data remanence. It might be
easier and safer to secure such data with LUKS encryption, and have a
way to wipe the key or keys.

- There's also the concept on Android, Windows, and macOS for
"recovery" partitions and booting. These recovery partitions tend to
be read-only boots, with limited tools and interface. This could be
leveraged for multiple needs: recovery boot for doing volume rescue
and repair; it could contain the installer, capable of doing a network
(re)install; or it could even be a "seed" from which a new system is
provisioned, and made whole by e.g. 'dnf group install'.

- Fedora has a "rescue" GRUB boot menu option. This is a "no
host-only" initramfs. Currently it's never updated, i.e. it gets
stale. For a while I've wanted us to remove this initramfs during
release upgrades, so they get regenerated. At the least it'd be nice
to make this more useful than it currently is.


--
Chris Murphy
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Switching package to fragmented default configuration

[Chris Adams]

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 been meaning to file a bug about:
anaconda has behavior around NTP that nothing else does.  If anaconda
gets NTP servers from DHCP, it deletes the pool entries from the default
config and replaces that with the DHCP-provided servers.  This is wrong;
it assumes that the installation network is the same as the production
network, and overrides default config without any prompt or kickstart
config.

When an operational system gets NTP servers from DHCP (e.g. via
NetworkManager), it does not touch the config in /etc; it instead
notifies the NTP service to add the server.

IMHO anaconda is just wrong to do this, and it breaks using an
installation network.  Right now, I have to hack around it in a
kickstart by telling anaconda to not configure NTP at all, but the
enable the service and add the package.
-- 
Chris Adams 
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Switching package to fragmented default configuration

[Miroslav Lichvar]

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 logic directly into the code. There is also no need to
> make those config paths configurable.

That's possible (the paths could be hardcoded in the systemd unit
file), but is it a good idea to force the users to use the new system?
If someone has a modified config, or is using one of the many ansible
roles for configuring NTP for example, why should it stop working? We
don't have to break configuration tools that just generate a config
from scratch.

> > My concern is that it will basically break all existing tools that
> > need to check and/or modify the configuration (e.g. anaconda). They
> > will need to know the naming of the files which have specific settings
> > in order to override them, or implement a parser duplicating the
> > chronyd logic to figure out which files are loaded from where.
> 
> The whole goal of the config-in-dropin-files-logic is that anaconda
> wouldn't parse existing config, it would just write
> /etc/chrony.d/50-anaconda.conf that would override only the parts it
> cares about.

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. In some cases users/vendors/products may want to specify
additional servers, sometimes replace them.

> Also, please don't invent a new logic — just follow the same one that
> systemd does [1]. This has the advantage that if something *needs* to
> look all of config, it can reuse what an existing loader. Also, admins
> don't need to learn a new set of rules. Ideally,
> 'systemd-analyze cat-config chrony.conf' would just work.

I was following the liboverdrop logic, which probably adopted the
systemd convention. For printing the whole configuration there is now
a "chronyd -p" command. The systemd cat-config command seems to expect
the ini-style syntax. That's not going to work here.

-- 
Miroslav Lichvar
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Headsup: dbus 1.12.10-1.fc29 is missing systemd dbus.service file, breaking almost everything

[Kevin Fenzi]

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 messages.
> >
> 
> I don't think mailman has any idea about group membership and I really
> don't have the time to deal with 'I am the upstream developer of XYZ
> and I am trying to respond to this thread.. why do I have to join
> multiple groups to post?'
> 
> I also note that a lot of fas account members have email addresses
> different from what they send email here as.

I'd like to add: Please don't reply on list to spam?

Mail the list owner(s) directly is fine, infrastructure ticktet if they
aren't responding, but replying to the list just ampifies the spam. ;( 

kevin


signature.asc
Description: PGP signature
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What to do about FTBFS because auf cmake change?

[José Abílio Matos]

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))
%undefine __cmake_in_source_build
%endif

I am asking this because I always forgot when was a given functionality 
introduced or it is no more required.

A simple example is "rm -rf $RPM_BUILD_ROOT" that I know that it is not 
necessary in Fedora anymore but it is very easy to know in which epel version 
it is necessary ( <= 6 I think).

Does that solution makes sense or am I over-engineering this?

Regards,
-- 
José Abílio

___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Chris Murphy]

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

systemd-oomd is coming along but it'll be Fedora 34 most likely, but
possibly Fedora 35.

Hopefully there will be a way to do some kind of "rebase" where
recommended things are favored on upgrades (to a new release version),
but without having to obsolete them, and not applied to each update
within a given release.

-- 
Chris Murphy
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Switching package to fragmented default configuration

[Zbigniew Jędrzejewski-Szmek]

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 file into a directory, instead of having to
> modify a packaged config file. It seems to be a modern trend, used
> by many packages in Fedora, and I have received some RFEs to adopt
> in chrony.
> 
> The default /etc/chrony.conf would just have a single directive
> loading configuration fragments from /etc/chrony.d and
> /var/lib/chrony.d (and maybe also /var/run/chrony.d).

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 logic directly into the code. There is also no need to
make those config paths configurable.

As to the locations to look at: /usr/lib or /usr/share (packaged
distro defaults), /usr/local/lib or /usr/share (local installed
defaults), /etc (admin overrides), /run (temporary overrides) are the
standard prefixes to look at. /var/lib is for persistent application
state, not config.

> My concern is that it will basically break all existing tools that
> need to check and/or modify the configuration (e.g. anaconda). They
> will need to know the naming of the files which have specific settings
> in order to override them, or implement a parser duplicating the
> chronyd logic to figure out which files are loaded from where.

The whole goal of the config-in-dropin-files-logic is that anaconda
wouldn't parse existing config, it would just write
/etc/chrony.d/50-anaconda.conf that would override only the parts it
cares about.

Also, please don't invent a new logic — just follow the same one that
systemd does [1]. This has the advantage that if something *needs* to
look all of config, it can reuse what an existing loader. Also, admins
don't need to learn a new set of rules. Ideally,
'systemd-analyze cat-config chrony.conf' would just work.

> Also,
> I'm not sure how user-friendly this is for regular users who modify
> the configuration manually.
> 
> Are there any recommendations for switching an existing single-config
> package to a fully fragmented configuration? Is it worth the trouble,
> or do you have any other suggestions?

Yes, it's definitely worth the trouble, it makes many things easier and
more robust.

Zbyszek

[1] We don't have a nice description of the logic anywhere. systemd.unit(5)
is the canonical source, but there there are many complications which
don't matter in the general case. Actually zram-generator.conf(5) which
was added recently seems to be a better reference:
https://github.com/systemd/zram-generator/blob/master/man/zram-generator.conf.md.
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Chris Murphy]

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 drop the madness once there's a dnf solution?

By the way... just in case it matters
https://src.fedoraproject.org/fork/catanzaro/rpms/fedora-release/c/a0df346ba785363adccdedeab4cc5d3edb24?branch=master

line 562 should be `zram-generator-defaults` - 'zram' will be
obsoleted by 'zram-generator-defaults` in F33.


-- 
Chris Murphy
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: ARM: Installed (but unpackaged) file(s) found: /usr/bin/....gdb-index-9pY4kY

[Florian Weimer]

* 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) file(s) found:
>/usr/bin/prusa-slicer.wrapped.gdb-index-9pY4kY
> Installed (but unpackaged) file(s) found:
>/usr/bin/prusa-slicer.wrapped.gdb-index-9pY4kY
>
> The gdb-index-9pY4kY files are not created explcitiyl by anything in
> the package.

This happens if debuginfo generation fails with a crash:

extracting debug info from 
/builddir/build/BUILDROOT/prusa-slicer-2.2.0-4.fc33.arm/usr/bin/prusa-slicer.wrapped
../../gdb/utils.c:691: internal-error: virtual memory exhausted: can't allocate 
234696314 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]
This is a bug, please report it.  For instructions, see:
.
/usr/bin/gdb-add-index: line 106: 22699 Aborted (core dumped) 
$GDB --batch -nx -iex 'set auto-load no' -ex "file $file" -ex "save gdb-index 
$dwarf5 $dir"

The crash is normally ignored.

> Does anybody know what this is?

Not enough RAM, apparently.

Thanks,
Florian
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: vim has lost it's damn mind

[Jonathan Wakely]

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 still consider this a bug as the file doesn't even end in c, cpp, cxx,
>c++ etc.

What's turning it on for non-C files?



Got me, I haven't dug in that far, just turned it off for now.


I see nocindent by default on F32, even for C files.

My personal vimrc turns it on explicitly for ft=c and ft=cpp and off
for everything else, but it shouldn't be on unless you've turned it
on.

___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Lots of FTBFS bugs filed for S390x "BuildrootError: Requested repo (1785390) is DELETED" / "rpm.error: error reading package header" errors

[Jonathan Wakely]

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: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:
>> >>
>> >> "BuildrootError: Requested repo (1785390) is DELETED"
>> >>
>> >> The second set of rebuilds failed with:
>> >>
>> >> "rpm.error: error reading package header"
>> >>
>> >> errors.
>> >>
>> >> The last error was also seen quite a bit during the F32 mass rebuid ...
>> >
>> > I'm sorry this is happening, and it makes me very grumpy too.
>> >
>> > I have some thoughts on improvements we can make to help try and make
>> > this better, but I was under the impression it was mostly working ok for
>> > the second pass.
>> >
>> > We went from 4162 to 2833 failures, so it had to have been working at
>> > least sometime there?
>>
>> It seems for me the s390x failures on the second build are limited
>> to package names starting with A-Z and "aa*" - "an*" .
>>
>> Any chance we can get a third mass rebuild for package-names starting
>> with A-Z and "a*" ?
>>
>> Or maybe all those where the only failing platform is on s390x ?
>>
>> (no idea how easy it is to script any of this)
>
>I am already resubmitting all builds that failed in koji but that
>currently pass locally in mock with "--enablerepo local".
>So far this has reduced the number of FTBFS packages by almost 100,
>and the script is still running.
>This should take care of all packages that only failed due to infra issues.

It looks like the %release was bumped again for these second rebuilds.
That shouldn't have been necessary, right?


I wondered about this too. The answer was: Usually no, but this time,
yes, because ELN:
https://pagure.io/releng/issue/9616#comment-668524


I see, thanks!

___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: vim has lost it's damn mind

[Richard Shaw]

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 doesn't even end in c, cpp, cxx,
> >c++ etc.
>
> What's turning it on for non-C files?
>

Got me, I haven't dug in that far, just turned it off for now.

Thanks,
Richard
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: %{_vpath_builddir} needs to be in the Cmake packaging guidelines

[Neal Gompa]

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 "%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 :)
> > >
> > You are not supposed to use %__cmake_builddir.
>
> You say I'm not supposed to use that macro, but that's exactly the macro I 
> need.
>
> > That macro only exists
> > so we don't have to mutate %_vpath_builddir when switching behaviors
> > through %__cmake_in_source_build.
>
> Any other way would do exactly what you just wrote here - I would be
> re-implementing this macro - which doesn't make sense.
>
> I'm open to new ideas, but this (using the "%__cmake_builddir" )
> sounds like the most straightforward and easy way to do it.
>

It is not documented, and eventually will be removed. So don't rely on
it. If you want to change the build directory, set %_vpath_builddir
instead.



--
真実はいつも一つ！/ Always, there's only one truth!
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Lots of FTBFS bugs filed for S390x "BuildrootError: Requested repo (1785390) is DELETED" / "rpm.error: error reading package header" errors

[Fabio Valentini]

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:
> >> >> 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:
> >> >>
> >> >> "BuildrootError: Requested repo (1785390) is DELETED"
> >> >>
> >> >> The second set of rebuilds failed with:
> >> >>
> >> >> "rpm.error: error reading package header"
> >> >>
> >> >> errors.
> >> >>
> >> >> The last error was also seen quite a bit during the F32 mass rebuid ...
> >> >
> >> > I'm sorry this is happening, and it makes me very grumpy too.
> >> >
> >> > I have some thoughts on improvements we can make to help try and make
> >> > this better, but I was under the impression it was mostly working ok for
> >> > the second pass.
> >> >
> >> > We went from 4162 to 2833 failures, so it had to have been working at
> >> > least sometime there?
> >>
> >> It seems for me the s390x failures on the second build are limited
> >> to package names starting with A-Z and "aa*" - "an*" .
> >>
> >> Any chance we can get a third mass rebuild for package-names starting
> >> with A-Z and "a*" ?
> >>
> >> Or maybe all those where the only failing platform is on s390x ?
> >>
> >> (no idea how easy it is to script any of this)
> >
> >I am already resubmitting all builds that failed in koji but that
> >currently pass locally in mock with "--enablerepo local".
> >So far this has reduced the number of FTBFS packages by almost 100,
> >and the script is still running.
> >This should take care of all packages that only failed due to infra issues.
>
> It looks like the %release was bumped again for these second rebuilds.
> That shouldn't have been necessary, right?

I wondered about this too. The answer was: Usually no, but this time,
yes, because ELN:
https://pagure.io/releng/issue/9616#comment-668524

Fabio
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Arch-specific LTO problems

[Jerry James]

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

Okay, I'll check into that possibility, too.  Thanks for the feedback,
Tom and Jeff.
-- 
Jerry James
http://www.jamezone.org/
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Orphaned dbus-java and libmatthew-java

[Omair Majid]

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 information that you may find useful if you are interested in
maintaining these.

The original upstream for dbus-java and libmatthew-java is dead. The
last commit on dbus-java was 10 years ago [1]. libmatthew-java doesn't
even have a source repository [2].

dbus-java has a new fork now which is being maintained [3]. However, the
fork is not source or binary compatible with the original dbus-java. It
also uses a completely different build system. The fork doesn't use
libmatthew-java, but instead uses jnr-socket, among other maven
artifacts.

Switching to the fork would require the spec file to be mostly
re-written.

It probably makes sense to retire libmatthew-java and update dbus-java
to the (incompatible) new upstream version.

Omair

[1] https://github.com/freedesktop/dbus-java/
[2] http://www.matthew.ath.cx/projects/java/
[3] https://github.com/hypfvieh/dbus-java/

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Automatic logout due to quota

[Steve Grubb]

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 1000 exceeded its 'bytes' quota on
> >> UID 1000.
> > 
> > I wrote a script that searched every binary on my system to see what
> > possibly matches this output. Turns out this cryptic message is from
> > dbus-broker. As best I can tell, a KDE program is triggering this. And I
> > have no idea how to reconfigure things to fix it, but the failure is
> > catestrophic when it shouldn't be. And its happening with some
> > regularity.
> > 
> > You are warned...
> 
> When reporting problems of this kind, could you share a link to the
> bugzilla you've filed against dbus-broker 

https://github.com/bus1/dbus-broker/issues/236

Still discussing this...

> or this KDE program?

No bug filed yet. I need to review my logs carefully to see if I can pinpoint 
something relevant. But akonadiconsole seems to be part of what triggers this 
catastrophic failure.

But this leads into another topic. akonadiconsole segfaults. So does akonadi. 
They both call Dr Konqui. It asks if you want to file a report. You say yes. 
Then it does something and says no backtrace generated, can't file a report.

So, that leads me to wonder, why do we enable Dr Konqui which cannot do 
anything and not let abrtd process it so that all the segfaulting KDE stuff 
gets collected up somewhere actionable instead of being lost forever? Not 
having any visbility into crashes occuring in KDE components is not helping 
improve software quality. 

-Steve

___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Switching package to fragmented default configuration

[Miroslav Lichvar]

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. It seems to be a modern trend, used
by many packages in Fedora, and I have received some RFEs to adopt
in chrony.

The default /etc/chrony.conf would just have a single directive
loading configuration fragments from /etc/chrony.d and
/var/lib/chrony.d (and maybe also /var/run/chrony.d).

My concern is that it will basically break all existing tools that
need to check and/or modify the configuration (e.g. anaconda). They
will need to know the naming of the files which have specific settings
in order to override them, or implement a parser duplicating the
chronyd logic to figure out which files are loaded from where. Also,
I'm not sure how user-friendly this is for regular users who modify
the configuration manually.

Are there any recommendations for switching an existing single-config
package to a fully fragmented configuration? Is it worth the trouble,
or do you have any other suggestions?

Thanks,

-- 
Miroslav Lichvar
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal to Add: Log In/Out Blocker Criteria

[Adam Williamson]

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 logging out of one user account and logging into
> another account that has already been accessed before during that boot. The
> criterion listed in the bug[2] doesn't seem to fit, as it is more focused
> on what happens after the system is booted (which does work in the case of
> this bug). There is a Final criterion[3] that covers switching between two
> accounts, where the data in the account switched out of is retained, but
> that is not the case presented here (as this bug has to do with "logging
> in/out" of accounts, not "switching" as they are defined technically).
> Intellectually, we believe this type of bug should violate the criteria, as
> it seems a common use-case, and so we are bringing it up as a possible
> addition as there is nothing that currently covers this kind of bug.
> 
> The new criterion could look something like "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."
> 
> We would appreciate feedback on this idea and the wording of the criterion.
> Should this be a beta or a final blocker? If nothing is heard in a
> reasonable amount of time (before next week's blocker review meeting), we
> will assume there is no issue with the proposal and add it to the criteria
> at that time.

There's a sort of technical argument to be made that this is covered by
https://fedoraproject.org/wiki/Fedora_33_Beta_Release_Criteria#desktop-shutdown-reboot-logout
 .
That says "Shutting down, logging out and rebooting must work using
standard console commands and the mechanisms offered (if any) by all
release-blocking desktops", with a footnote "Logging out must return
the user to the environment from which they logged in, working as
expected." Arguably the environment from which they logged in is not
"working as expected" if you can't then log in as someone else.

Adding a more explicit requirement wouldn't hurt, though, I guess. I
sort of feel like it would be nice to somehow combine and rationalize
all these related requirements somehow...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Arch-specific LTO problems

[Jeff Law]

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 expected, though I 
> > > didn't trip
> > > over any in my i686 testing (I have a theory for why, but it's not 
> > > terribly
> > > important).
> > 
> > I will try to come up with a definitive answer today on whether memory
> > exhaustion is or is not the problem.  However, the ppc64le symbol
> > problem with the primecount package appears to be something else
> > entirely.  See https://bugzilla.redhat.com/show_bug.cgi?id=1862181.
> > 
> 
> 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.
Agreed.

jeff
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Arch-specific LTO problems

[Tom Stellard]

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 for why, but it's not terribly
important).


I will try to come up with a definitive answer today on whether memory
exhaustion is or is not the problem.  However, the ppc64le symbol
problem with the primecount package appears to be something else
entirely.  See https://bugzilla.redhat.com/show_bug.cgi?id=1862181.



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.

-Tom
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Arch-specific LTO problems

[Jerry James]

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

I will try to come up with a definitive answer today on whether memory
exhaustion is or is not the problem.  However, the ppc64le symbol
problem with the primecount package appears to be something else
entirely.  See https://bugzilla.redhat.com/show_bug.cgi?id=1862181.
-- 
Jerry James
http://www.jamezone.org/
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: vim has lost it's damn mind

[Jonathan Wakely]

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 non-C files?

___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Vít Ondruch]

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 want to keep earlyoom on the system in case there is
systemd-oomd or whatever should be the successor.


Vít
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Lots of FTBFS bugs filed for S390x "BuildrootError: Requested repo (1785390) is DELETED" / "rpm.error: error reading package header" errors

[Jonathan Wakely]

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
>> failing to build on s390x. The first set of rebuilds failed with:
>>
>> "BuildrootError: Requested repo (1785390) is DELETED"
>>
>> The second set of rebuilds failed with:
>>
>> "rpm.error: error reading package header"
>>
>> errors.
>>
>> The last error was also seen quite a bit during the F32 mass rebuid ...
>
> I'm sorry this is happening, and it makes me very grumpy too.
>
> I have some thoughts on improvements we can make to help try and make
> this better, but I was under the impression it was mostly working ok for
> the second pass.
>
> We went from 4162 to 2833 failures, so it had to have been working at
> least sometime there?

It seems for me the s390x failures on the second build are limited
to package names starting with A-Z and "aa*" - "an*" .

Any chance we can get a third mass rebuild for package-names starting
with A-Z and "a*" ?

Or maybe all those where the only failing platform is on s390x ?

(no idea how easy it is to script any of this)


I am already resubmitting all builds that failed in koji but that
currently pass locally in mock with "--enablerepo local".
So far this has reduced the number of FTBFS packages by almost 100,
and the script is still running.
This should take care of all packages that only failed due to infra issues.


It looks like the %release was bumped again for these second rebuilds.
That shouldn't have been necessary, right?

___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Lots of FTBFS bugs filed for S390x "BuildrootError: Requested repo (1785390) is DELETED" / "rpm.error: error reading package header" errors

[Jonathan Wakely]

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:

"BuildrootError: Requested repo (1785390) is DELETED"

The second set of rebuilds failed with:

"rpm.error: error reading package header"

errors.

The last error was also seen quite a bit during the F32 mass rebuid ...


I'm sorry this is happening, and it makes me very grumpy too.

I have some thoughts on improvements we can make to help try and make
this better, but I was under the impression it was mostly working ok for
the second pass.

We went from 4162 to 2833 failures, so it had to have been working at
least sometime there?


It seems for me the s390x failures on the second build are limited
to package names starting with A-Z and "aa*" - "an*" .

Any chance we can get a third mass rebuild for package-names starting
with A-Z and "a*" ?


It's not just "a*" because boost also failed with that error. And it
got the same error on armv7hf as well, not only s390x.


Or maybe all those where the only failing platform is on s390x ?

(no idea how easy it is to script any of this)


___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Remote wipe options for Fedora?

[Michel Alexandre Salim]

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
> naturally need a network/internet based service as control point.
> 
> Googling and searching the mailing list has not turned any leads. 
> 

I'm not aware of one myself, though I am interested if one exists (and
am contemplating writing one if none does).

I have a potentially easier use case in that I can assume disks are
encrypted with LUKS, and so removing all the LUKS keys and rebooting
the machine would lock out anyone in possession of the machine anyway.

One possible approach is to just write an MDM (Mobile Device Management
- sic) client for Linux, since there are open source MDM servers like
micromdm - https://github.com/micromdm/micromdm

Best regards,

-- 
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2


signature.asc
Description: This is a digitally signed message part
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: %{_vpath_builddir} needs to be in the Cmake packaging guidelines

[Michal Schorm]

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_builddir}" ).
> >
> > Ok, I'll use that in the future, but it still needs a mention in the 
> > guidelines :)
> >
> You are not supposed to use %__cmake_builddir.

You say I'm not supposed to use that macro, but that's exactly the macro I need.

> That macro only exists
> so we don't have to mutate %_vpath_builddir when switching behaviors
> through %__cmake_in_source_build.

Any other way would do exactly what you just wrote here - I would be
re-implementing this macro - which doesn't make sense.

I'm open to new ideas, but this (using the "%__cmake_builddir" )
sounds like the most straightforward and easy way to do it.

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal to Add: Log In/Out Blocker Criteria

[Zbigniew Jędrzejewski-Szmek]

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_Criteria#Shutdown.2C_reboot.2C_logout
> >
> > So let's just include logging in as well, and we're done:
> > "Shutting down, rebooting, logging in and logging out must work using 
> > standard console commands and the mechanisms offered (if any) by all 
> > release-blocking desktops."
> >
> > We'd also update the "Work?" footnote:
> > "Similar to the Basic criterion for shutting down, shutdown and reboot 
> > mechanisms must take storage volumes down cleanly and correctly request a 
> > shutdown or reboot from the system firmware. Logging in must transfer the 
> > user from the login screen/prompt to his/her working environment, and 
> > logging out must return the user to the environment from which they logged 
> > in, working as expected."
> >
> Simple is good. I like this approach.

+1

Maybe "their" and not "his/her" — "his/her" is already starting to feel dated.

Zbyszek
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Michael Catanzaro]

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 manage 
this file.' \


  || :

I.e. only a hint is emitted. I'm open to suggestions how to improve 
it.


Zbyszek


Zbigniew, do you agree that we should remove the script if and only if 
it is generated by NetworkManager? Otherwise, the change is only 
partially-implemented for users upgrading from F32 and earlier.


___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What to do about FTBFS because auf cmake change?

[Neal Gompa]

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_test equiv.
>
> I've used:
>
>  %cmake_build -- test
>
> There is also:
>
>  %ctest
>
> But I don't know if that works with all projects using cmake.
>

If your project is using the standard CMake built-in testing functionality,
then %ctest will work. Otherwise it might require doing something
else. That's more or less the same as before...



--
真実はいつも一つ！/ Always, there's only one truth!
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Vitaly Zaitsev via devel]

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.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Michael Catanzaro]

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 (and it is possibly not installed anymore 
on

upgraded systems).

Therefore I wonder what is the status of EarlyOOM. Should I let the
package go? If not, then the situation should be fixed somehow, 
probably

either by reverting the revert or adding the dependency into
fedora-release as was proposed elsewhere.


We're tracking this problem in 
https://pagure.io/fedora-workstation/issue/138 and 
https://bugzilla.redhat.com/show_bug.cgi?id=1814306. It's high priority 
for Workstation, but it's blocked on dnf. We've been working around it 
in an ad-hoc way for each package we add in a different way in every 
release. In this case, I removed our original workaround in 
https://src.fedoraproject.org/rpms/earlyoom/pull-request/2 because we 
intended to replace it with a new workaround, 
https://src.fedoraproject.org/fork/catanzaro/rpms/fedora-release/c/a0df346ba785363adccdedeab4cc5d3edb24?branch=master. 
However, we decided the new workaround was a little outrageous and we 
would just wait for a dnf fix instead. In the meantime, if you want to 
keep earlyoom, don't use autoremove. 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.


Michael

___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Lots of FTBFS bugs filed for S390x "BuildrootError: Requested repo (1785390) is DELETED" / "rpm.error: error reading package header" errors

[Michel Alexandre Salim]

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
> > > currently pass locally in mock with "--enablerepo local".
> > > So far this has reduced the number of FTBFS packages by almost
> > 100,
> > > and the script is still running.
> > > This should take care of all packages that only failed due to
> > infra
> > > issues.
> > > 
> 
> (snip)
> 
> > Could this be why the queue to get an s390x build seems longer than
> > usual today, and is there an ETA for when this script will finish?
> > 
> > I have some builds for Eternal Terminal (et) that have all
> > completed on
> > all platforms (even armv7hl) but are still all queued on s390x
> > 
> > https://koji.fedoraproject.org/koji/packageinfo?packageID=27370
> > 
> > Thanks,
> 
> Almost certainly no. Since I'm running a local mock build as sanity
> check before submitting anything to koji, there's usually no more
> than 3-4 builds running at one point, and I'm submitting them with
> both --fail-fast (if they fail anywhere, other arches are cancelled
> immediately) and --background (lower priority).
> 
Just to close the loop -- Kevin Fenzi was reconfiguring the s390x
builders and I missed that thread.

Thanks for the work Kevin! Only one of my four builds eventually failed
spuriously on s390x, and restarting it once worked, which seems better
than previously.

-- 
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2


signature.asc
Description: This is a digitally signed message part
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Headsup: dbus 1.12.10-1.fc29 is missing systemd dbus.service file, breaking almost everything

[Stephen John Smoogen]

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't have the time to deal with 'I am the upstream developer of XYZ
and I am trying to respond to this thread.. why do I have to join
multiple groups to post?'

I also note that a lot of fas account members have email addresses
different from what they send email here as.

> --
> Sincerely,
>   Vitaly Zaitsev (vit...@easycoding.org)
> ___
> 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/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Remote wipe options for Fedora?

[Martin Langhoff]

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 searching the mailing list has not turned any leads.

It is a can of worms, naturally, and I am well aware of limitations, and
tricky tradeoffs in remote-wipe schemes. For some use cases, including one
affecting me, it can reduce attack surface. I am hoping that some solutions
exist, I would be happy to improve, package, integrate...

regards,


martin
-- 
 martin.langh...@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted~  http://github.com/martin-langhoff
   by shiny stuff
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: %{_vpath_builddir} needs to be in the Cmake packaging guidelines

[Christoph Junghans]

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")
> >>> 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 :)
> >>
> >
> > You are not supposed to use %__cmake_builddir. That macro only exists
> > so we don't have to mutate %_vpath_builddir when switching behaviors
> > through %__cmake_in_source_build.
>
> Surely that's exactly the advantage of using %__cmake_builddir, that it
> points at the place that was actually used for the build regardless of
> whether in source builds are enabled or disabled...
I had to do some similar hackery to make the legion package build
again after the cmake changes:
https://src.fedoraproject.org/rpms/legion/c/bebc0d947b45caa64941507f0f21306b11d87f73?branch=master
certainly not the most elegant way.

My question is if one can set __cmake_builddir to shell variable,
which expands later, something like:

%build
%global __cmake_builddir ${mpi:-serial}
. /etc/profile.d/modules.sh
for mpi in '' mpich openmpi ; do
  test -n "${mpi}" && module load mpi/${mpi}-%{_arch}
  %cmake
  %cmake_build
  test -n "${mpi}" && module unload mpi/${mpi}-%{_arch}
done

But I am not 100% sure about the expansion order.

Christoph

>
> Tom
>
> --
> Tom Hughes (t...@compton.nu)
> http://compton.nu/
> ___
> 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/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Christoph Junghans
Web: http://www.compphys.de
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: %{_vpath_builddir} needs to be in the Cmake packaging guidelines

[Tom Hughes via devel]

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 use that in the future, but it still needs a mention in the guidelines 
:)



You are not supposed to use %__cmake_builddir. That macro only exists
so we don't have to mutate %_vpath_builddir when switching behaviors
through %__cmake_in_source_build.


Surely that's exactly the advantage of using %__cmake_builddir, that it
points at the place that was actually used for the build regardless of
whether in source builds are enabled or disabled...

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Headsup: dbus 1.12.10-1.fc29 is missing systemd dbus.service file, breaking almost everything

[Stephen John Smoogen]

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 mentions user followers. So, everyone, who need it, 
>> go here.
>
>
> So, how do we ban spammers from this list? CC devel-owner.
>

User has been unsubscribed from the list. banning usually doesn't work
because they have normally a couple hundred other accounts to use.

> ___
> 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/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal to Add: Log In/Out Blocker Criteria

[Ben Cotton]

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 as well, and we're done:
> "Shutting down, rebooting, logging in and logging out must work using 
> standard console commands and the mechanisms offered (if any) by all 
> release-blocking desktops."
>
> We'd also update the "Work?" footnote:
> "Similar to the Basic criterion for shutting down, shutdown and reboot 
> mechanisms must take storage volumes down cleanly and correctly request a 
> shutdown or reboot from the system firmware. Logging in must transfer the 
> user from the login screen/prompt to his/her working environment, and logging 
> out must return the user to the environment from which they logged in, 
> working as expected."
>
Simple is good. I like this approach.

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Did check 0.15.x in rawhide break packages' test suites?

[Fabio Valentini]

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
> > calls.  However, upstream didn't do it right, with the result that gcc
> > warned on pretty much every use of the check macros.  I submitted a
> > patch upstream to fix that, which upstream applied and included in
> > version 0.15.1.  That patch, however, broke other things, such as the
> > ability to call fail_if() with only one argument.
> >
> > I've been working on another patch to fix *that*.  It's not too hard
> > to do for gcc, which makes __VA_OPT__ available to the C compiler, but
> > not so easy for the Microsoft compiler.  I'll attach what I have so
> > far.  Comments or suggestions on how to make it better are much
> > appreciated.  I would like to submit something upstream by tomorrow.
> > If upstream likes the idea, I'll do another build of check that
> > includes the patch.
>
> Upstream went with a simpler fix.  It seems that the fail_* macros are
> deprecated anyway (your upstreams should switch to using ck_assert*
> calls instead), so they just added an extra NULL argument to the end.
> That will make GCC complain about too many arguments for the format
> string in the case that more than one argument is passed, but will fix
> the breakage when only one argument is passed.
>
> I will add upstream's commit to the our package and rebuild.

Thanks! It looks like the packages which are using those macros in
their test suites now build correctly.
They'll get resubmitted by my "resubmit this if the F33FTBFS issue was
caused by a transient issue" script soon. :)

Fabio
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: %{_vpath_builddir} needs to be in the Cmake packaging guidelines

[Neal Gompa]

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 it still needs a mention in the 
> guidelines :)
>

You are not supposed to use %__cmake_builddir. That macro only exists
so we don't have to mutate %_vpath_builddir when switching behaviors
through %__cmake_in_source_build.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What to do about FTBFS because auf cmake change?

[Miro Hrončok]

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:

%ctest

But I don't know if that works with all projects using cmake.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

ARM: Installed (but unpackaged) file(s) found: /usr/bin/....gdb-index-9pY4kY

[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) file(s) found:
   /usr/bin/prusa-slicer.wrapped.gdb-index-9pY4kY
Installed (but unpackaged) file(s) found:
   /usr/bin/prusa-slicer.wrapped.gdb-index-9pY4kY

The gdb-index-9pY4kY files are not created explcitiyl by anything in the 
package.

Most recent builds:
https://koji.fedoraproject.org/koji/taskinfo?taskID=48609410
https://koji.fedoraproject.org/koji/taskinfo?taskID=48609410

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1865257

Does anybody know what this is?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What to do about FTBFS because auf cmake change?

[Peter Robinson]

> > 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 packages "a complete mess"?
> >
> > More seriously, are we expected to fix this ourselves? What happened to
> > "proposal owners will fix as many Fedora packages as possible"? Should I
> > just re-assign the bug to cmake?
> >
> > I don't generally mind fixing my packages, but I'm confused by the lack
> > of communication here.
>
> There are only a few packages that were considered a complete mess,
> mostly packages that did crazy build process scripting in the %build
> and %install sections. Most packages don't fall in that category.
> Basically if I can't understand how it works, I don't want to touch
> it.
>
> The reason yours hadn't been touched yet is because neither Igor nor
> myself managed to get to yours before the mass rebuild.
>
> It would be ideal if you can fix your own packages if we hadn't gotten
> to them, as you know your packages. :)
>
> The general advice I would give is that if you did the following:
>
> %cmake .
> %make_build
> %make_install
>
> Then you should change it to the following:
>
> %cmake
> %cmake_build
> %cmake_install
>
> (Note the lack of "." as an argument to %cmake)
>
> If you are doing something like the following:
>
> mkdir -p %{_target_platform}
> pushd %{_target_platform}
> %cmake ..
> popd
>
> %make_build -C %{_target_platform}
> %make_install -C %{_target_platform}
>
> Or like the following
>
> mkdir -p %{_target_platform}
> pushd %{_target_platform}
> %cmake ..
> popd
>
> pushd %{_target_platform}
> %make_build
> popd
> pushd %{_target_platform}
> %make_install
> popd
>
> Then you should do the following:
>
> %undefine __cmake_in_source_build
>
> %cmake
> %cmake_build
> %cmake_install

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.
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal to Add: Log In/Out Blocker Criteria

[Kamil Paral]

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 logging out of one user account and logging into
> another account that has already been accessed before during that boot. The
> criterion listed in the bug[2] doesn't seem to fit, as it is more focused
> on what happens after the system is booted (which does work in the case of
> this bug). There is a Final criterion[3] that covers switching between two
> accounts, where the data in the account switched out of is retained, but
> that is not the case presented here (as this bug has to do with "logging
> in/out" of accounts, not "switching" as they are defined technically).
> Intellectually, we believe this type of bug should violate the criteria, as
> it seems a common use-case, and so we are bringing it up as a possible
> addition as there is nothing that currently covers this kind of bug.
>
> The new criterion could look something like "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."
>

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 as well, and we're done:
"Shutting down, rebooting, logging in and logging out must work using
standard console commands and the mechanisms offered (if any) by all
release-blocking desktops."

We'd also update the "Work?" footnote:
"Similar to the Basic criterion for shutting down, shutdown and reboot
mechanisms must take storage volumes down cleanly and correctly request a
shutdown or reboot from the system firmware. Logging in must transfer the
user from the login screen/prompt to his/her working environment, and
logging out must return the user to the environment from which they logged
in, working as expected."

This sufficiently covers the discussed bug and seems to fit naturally into
the existing criterion. One unclear area might be what the console console
used for logging in is. We can either explicitly say that for logging in we
don't require any specific console command, or we can note that the most
likely command to get covered by this is "su". We can also not define it
and leave that up to blocker discussion, if such a situation occurs in the
future. I'd lean towards the last option, but all sound fine to me.

Thoughts?
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Headsup: dbus 1.12.10-1.fc29 is missing systemd dbus.service file, breaking almost everything

[Vitaly Zaitsev via devel]

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.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Miro Hrončok]

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 rawhide were not successfully built at least since Fedora 31.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb 


   Package (co)maintainers  Latest build
===
OpenCoarrays   jussilehtolaFedora 30
js-jquery-jqplot   xavierb Fedora 30
js-jquery1 nodejs-sig, patches, vondruch   Fedora 30
js-jquery2 vondruchFedora 30
js-sizzle  nodejs-sig, patches, vondruch   Fedora 30
nodejs-path-type   nodejs-sig, orphan  Fedora 30
nodejs-temp-write  orphan  Fedora 30
nodejs-unique-stream   jsmith, nodejs-sig  Fedora 30
orpie  bowlofeggs, orphan  Fedora 30
rubygem-ruby-hmac  humaton, mmorsi Fedora 30


This has been done.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: LTO vs LD_PRELOAD (libvirt FTBFS test suite failure)

[Daniel P . Berrangé]

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 invocation.  We don't
> really know what kind of transformations libtool does in this case.

Upstream libvirt has just yesterday replaced use of autotools with
meson. I just tried a Fedora rawhide build of our new meson based
code and it succeeded with LTO.

Given this, I think I'm fine just disabling LTO in rawhide for the
current libvirt release, with the expectation we'll re-enable LTO
in ~1 month time when we import the meson based release of libvirt.

IOW lets not waste any more time debugging this LTO / LD_PRELOAD
problem with libvirt.

> libtool is really not built for LTO, and it really should not be used on
> GNU systems.  But I understand that this is not uncontroversial.

There's oooh so many problems with libtool we've hit over the years,
especially with it re-arranging order of compiler/linker flags, and
so I'm beyond ecstatic that we've finally thrown it away for libvirt
in favour of meson.

There may have been a time & place for libtool and autotools in
general, but that time has passed

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: %{_vpath_builddir} needs to be in the Cmake packaging guidelines

[Richard Shaw]

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
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Headsup: dbus 1.12.10-1.fc29 is missing systemd dbus.service file, breaking almost everything

[Kamil Paral]

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

So, how do we ban spammers from this list? CC devel-owner.
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What to do about FTBFS because auf cmake change?

[Neal Gompa]

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 are considered "a complete mess" are not
> touched. Are all my packages "a complete mess"?
>
> More seriously, are we expected to fix this ourselves? What happened to
> "proposal owners will fix as many Fedora packages as possible"? Should I
> just re-assign the bug to cmake?
>
> I don't generally mind fixing my packages, but I'm confused by the lack
> of communication here.

There are only a few packages that were considered a complete mess,
mostly packages that did crazy build process scripting in the %build
and %install sections. Most packages don't fall in that category.
Basically if I can't understand how it works, I don't want to touch
it.

The reason yours hadn't been touched yet is because neither Igor nor
myself managed to get to yours before the mass rebuild.

It would be ideal if you can fix your own packages if we hadn't gotten
to them, as you know your packages. :)

The general advice I would give is that if you did the following:

%cmake .
%make_build
%make_install

Then you should change it to the following:

%cmake
%cmake_build
%cmake_install

(Note the lack of "." as an argument to %cmake)

If you are doing something like the following:

mkdir -p %{_target_platform}
pushd %{_target_platform}
%cmake ..
popd

%make_build -C %{_target_platform}
%make_install -C %{_target_platform}

Or like the following

mkdir -p %{_target_platform}
pushd %{_target_platform}
%cmake ..
popd

pushd %{_target_platform}
%make_build
popd
pushd %{_target_platform}
%make_install
popd

Then you should do the following:

%undefine __cmake_in_source_build

%cmake
%cmake_build
%cmake_install


The %undefine is only needed if you reuse your spec on F32 and older
(including EPEL). Note that EPEL7 with cmake3 requires also undefining
%__cmake3_in_source_build, since all macros use "cmake3" instead of
"cmake" in that instance.

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: dnspython 2.0.0rc1 (without Python 2 support)

[Lumir Balhar]

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/20 6:47 AM, Lumir Balhar wrote:
dnspython 2.0.0 has been released upstream and it's available in COPR: 
https://copr.fedorainfracloud.org/coprs/lbalhar/dns/


The builds are okay except the two mentioned before. I'll coordinate 
update with https://bugzilla.redhat.com/show_bug.cgi?id=1737930


Lumír

On 7/7/20 8:30 AM, Lumir Balhar wrote:

python-dns 2.0.0rc2 is ready in the COPR.

- mailman3 FTBFS because it has missing dependencies in rawhide
- python-ryu FTBFS but the problem is only in COPR (probably caused 
by an empty resolv.conf) and it builds fine in mock.


Lumír

On 6/25/20 12:30 PM, Lumir Balhar wrote:

Hello.

tl;dr - if your package [build]requires python3-dns, please test it 
with python-dns from COPR [0] and let me know in case of any troubles.


I'm slowly getting ready to update python-dns to 2.0.0 which drops 
Python 2 support. dnspython is still a release candidate but the 
final release should be available soon.


Only mailman and trac-spamfilter-plugin depend on python2-dns. A new 
version of trac-spamfilter-plugin should be released soon [0] so we 
can update both together but I have no idea about plans for mailman. 
Is there any ETA for Python 3 support there?


It seems that all packages with build-dependency on python3-dns 
build fine [0] except python-ryu but the issue there seems to be 
caused by eventlet [2].


Have a nice day.

Lumír

[0] https://copr.fedorainfracloud.org/coprs/lbalhar/dns/
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1737930
[2] https://github.com/eventlet/eventlet/issues/619
___
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/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
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/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
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/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: ocaml-ppx-tools-versioned debuginfo disabled, dune and ppx extensions

[Richard W.M. Jones]

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 I should be able to reenable debuginfo again in this package.
> (The same bug possibly affects all ppx extensions).

Several things were broken.  It should all be fixed now.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: /usr/bin/strip: unable to copy file '/builddir/build/BUILDROOT/ocaml-omake-0.10.3-27.fc33.x86_64/usr/bin/omake'; reason: Permission denied

[Petr Pisar]

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 file 
> > '/builddir/build/BUILDROOT/ocaml-omake-0.10.3-27.fc33.x86_64/usr/bin/omake';
> >  reason: Permission denied
> > error: Bad exit status from /var/tmp/rpm-tmp.5A3ApT (%install)
> 
> After updating to more Rawhide I _am_ able to reproduce it.  It seems
> to be caused because the binary is installed 0555:
> 
>   -r-xr-xr-x. 1 rjones rjones 8042912 Aug  3 22:41 
> /home/rjones/rpmbuild/BUILDROOT/ocaml-omake-0.10.3-27.fc33.x86_64/usr/bin/omake
> 
> However nothing has changed in this package for years (last rebase was
> in Nov 2017) but apparently strip didn't have a problem before now.
> 
> I was able to work around it by adding an explicit
> 
>%install
>make install \
>  INSTALL_ROOT=$RPM_BUILD_ROOT
>   +chmod 0755 $RPM_BUILD_ROOT%{_bindir}/omake
> 
> so I guess that "fixes" it, but why?
> 
I saw a similar randomly occuring issue when a spec Source file was copied
into the %buildroot. It turned out that the Source file was created without
a write bit when unpacking a source package. Probably due to an unexpected
umask on a builder. My solution was using "install -m" instead of "cp -a".

-- Petr


signature.asc
Description: PGP signature
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Headsup: dbus 1.12.10-1.fc29 is missing systemd dbus.service file, breaking almost everything

[Mike Johnson]

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 list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Headsup: dbus 1.12.10-1.fc29 is missing systemd dbus.service file, breaking almost everything

[Mike Johnson]

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 list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

What to do about FTBFS because auf cmake change?

[Till Hofmann]

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 packages "a complete mess"?

More seriously, are we expected to fix this ourselves? What happened to
"proposal owners will fix as many Fedora packages as possible"? Should I
just re-assign the bug to cmake?

I don't generally mind fixing my packages, but I'm confused by the lack
of communication here.

Kind regards,
Till
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: arm/neon LTO-related FTBS

[Dominique Martinet]

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 that's not appropriate for
> fedora, but this is this and that is that, no need to shout.

Actually I take that back, this really is a LTO/gcc bug.

They compile everything that the compiler supports and at runtime detect
what is available and run the appropriate best function ('best' being
decided uppon the order of an enum, so YMMV, but at least it won't try
to run the neon function on a board that doesn't have neon even if the
binary enables it).

So I'd really need a way to have only that file compiled with the
optimisations, and other files without it -- Jeff or someone else, could
you please advise?

Thanks,
-- 
Dominique


___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Test-Announce] Fedora 33 Rawhide 20200804.n.0 nightly compose nominated for testing

[rawhide]

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/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20200731.n.0: anaconda-33.23-1.fc33.src, 20200804.n.0: 
anaconda-33.24-1.fc33.src
parted - 20200731.n.0: parted-3.3-4.fc33.src, 20200804.n.0: 
parted-3.3-5.fc33.src
pykickstart - 20200731.n.0: pykickstart-3.27-1.fc33.src, 20200804.n.0: 
pykickstart-3.27-2.fc33.src
lorax - 20200731.n.0: lorax-33.8-1.fc33.src, 20200804.n.0: lorax-33.8-2.fc33.src
pungi - 20200731.n.0: pungi-4.2.3-2.fc33.src, 20200804.n.0: 
pungi-4.2.3-3.fc33.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/33

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200804.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200804.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200804.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200804.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200804.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200804.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200804.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal to Add: Log In/Out Blocker Criteria

[Christopher Engelhard]

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

Christopher
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: %{_vpath_builddir} needs to be in the Cmake packaging guidelines

[Michal Schorm]

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 behind each such argument can be quite
complicated.

Now (with the new CMake behaviour), when you call "cmake -LAH" after
you used the "%cmake", it will create a *new* cache, in the current
(that usually mean source) directory, *with incorrect values* and show
you that values instead of the correct ones (from the correct
builddir).
That was a nice quantum physic problem - since the new incorrect cache
was only created when you wanted to observe it :)
I'd like to anyone after me to not get caught by this (probably
correct, but not intuitive) behaviour.

I'd like to have the "%{__cmake_builddir}" and "%_vpath_builddir" more
visible, than hidden behind "See the Defining source and build
directories for more information".
I was on that page several times but I haven't clicked that link since
I was looking how to *get* the patch of the builddir, instead of
defining it.
I'd submit a PR, but unfortunately no good idea how to reword the
sentence has passed my mind yet.

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--


On Tue, Aug 4, 2020 at 9:37 AM Igor Raits
 wrote:
>
> -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 response to
> > one
> > of my earlier emails to find the answer again...
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/
>
> %__cmake_in_source_build
>
> Controls whether builds are done in-source (when defined) or out-
> of-source (when undefined). See the Defining source and build
> directories for more information.
>
> Links to:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/vpath/
>
> Feel free to submit a PR to make it more visible.
>
> >
> > %{_vpath_builddir}
> >
> > But that begs the question, now that we have updated %cmake, and new
> > %cmake_build & %cmake_install, why is it %_vpath_builddir and not
> > %_cmake_builddir?
> >
> > Thanks,
> > Richard
> > ___
> > 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/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
> - --
> Igor Raits 
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8pECIACgkQEV1auJxc
> Hh4L7Q/+M7N/MJg0od9JZ2ri3Kcd7dtzd7WzU6X6/MPtoTtnTYd5AlJQM8zZYrfj
> jLFM6Hd9JdhReUodTeXYMzcuIRctjFNJv3ycI7E7pF5XvkQc6rnie6e/NwrUyCUG
> b0/I4F4RUpHQfAbR/Pa05lbBfFb1pN0jCoXsc77dLWLZ//FefBYEVYTdzc44mKhx
> TMOX8MPapBlu6P4XITajcI/cXMwecqgSfGPmiGwz2aqn9Ec4415khsKhjhT6CnaA
> IkgLGPHZwrO1WwZXnOR+TLR6QBpGyna3xLOCE7VskH+WmsYgd6UGTm+t86BFbBDl
> hThVdjK4I+uV0SU7qVq+NqtOIQRd014aKBGJpl1pmadjJhvBApJgZyC8e83OiOLm
> FC1OziylaOsYvJuUIZzBG7VMyFNM4J7YR8CKD4r0CLkvkCTT0Re0jzxmXzvZzQd+
> mmAsvehjIHPG0SDti8521l22dN7pvkvVO0OAfb0XDXKAdQaIQnosZyEi2G3Q4w1j
> kRNLyKsIvLdHaXMqqQ/6T/O5zkaSdM7vdD54HebdzcR3iVqy3TyaI8TmMsSlA0jz
> DfSd5/+W/dIen6lBOAwVO6R935Y9LCt5IdD5Szbs75wAJNOyRLnwHj2I8beNHxVi
> iaUNm4KdaKxupzqwiQ9EPpClssNdkgEi2HQi/q3B+PXSu57RrOI=
> =ZYgX
> -END PGP SIGNATURE-
> ___
> 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/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: arm/neon LTO-related FTBS

[Dominique Martinet]

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 NEON on armhfp
> because there are ARMv7 processors that don't have NEON and that would
> then crash on those devices.

Hm, yes and no - it is a bug in waypipe as you've said below, but we
already were building the neon object before and what broke the build is
LTO.


So, sure, I can also work towards disabling neon optimisations instead;
the meson file doesn't provide an option for that but it's not too
difficult.
Note there is the same problem with avx, it builds with avx512f if the
compiler supports it -- I think it's fairly standard for upstreams to
just enable everything by default if it's available, and we need to turn
it off.

I'm not sure what the standard way is to do that with meson, will have
to do some zoology first... neon and avx instructions are pretty
mainstream for streaming (waypipe is a kind of vnc) so I expect other
packages have fixed similar problems in the past...


> On aarch64/ARMv8 it can be assumed there's NEON because it's a
> required part of the standard, but it's not a requirement for ARMv7
> processors so the software should do run time detection / fast path
> code to optimise if it detects NEON at runtime NOT compile time.

waypipe is actually one of the better projects in the regard that there
are tests run in the %check section (thanks to whoever made the initial
package I took over), and the tests run fine with NEON enabled on arm.

Would it be possible to have hardware we're actually supposed to support
available for rpm checks?
I think it's precisely why we have checks ; this package has been broken
for platforms without neon ever since it had been introduced.
It's also probably broken on machines without avx512.

I don't have access to any such machine where I could do this kind of
tests, and I'm not the original packager of this thing, so don't expect
me to know how to deal with that.


> > I don't think gcc can intuite this so it's probably not a bug though
> > (hence I'm not planning on opening a bug), but it is a regression of
> > sort...
> 
> You're wrong.

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 that's not appropriate for
fedora, but this is this and that is that, no need to shout.

Thanks,
-- 
Dominique
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: LTO vs LD_PRELOAD (libvirt FTBFS test suite failure)

[Florian Weimer]

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

libtool is really not built for LTO, and it really should not be used on
GNU systems.  But I understand that this is not uncontroversial.

Thanks,
Florian
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal to Add: Log In/Out Blocker Criteria

[Paul Howarth]

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

Paul.
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Still seeing "DWARF version 0 unhandled" (was: Re: No debugsource generated, weird DWARF errors)

[Richard W.M. Jones]

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)
> > 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_versioned/metaquot_409/ppx.exe:
> >  DWARF version 0 unhandled
> > 
> > This is with binutils 2.35-10.fc33 which AFAIK should fix this.
> > [...]
> >   + gcc -O2 -fno-strict-aliasing -fwrapv -O2 -g -pipe -Wall 
> > -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
> > -fexceptions -fstack-protector-strong -grecord-gcc-switches 
> > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
> > -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wall 
> > -Wdeclaration-after-statement -Werror -fno-common 
> > -fexcess-precision=standard -fno-tree-vrp -ffunction-sections 
> > -D_FILE_OFFSET_BITS=64 -D_REENTRANT -DCAML_NAME_SPACE  -Wl,-E -o 
> > '.ppx/344604af5ef56e11f45ae295381bcce7/ppx.exe'  
> > '-L/usr/lib64/ocaml/compiler-libs' 
> > '-L/usr/lib64/ocaml/ocaml-migrate-parsetree' 
> > '-L/usr/lib64/ocaml/ppx_derivers' '-L/usr/lib64/ocaml/result' '-L.' 
> > '-L.ppx_tools_versioned.objs/byte' '-L.ppx_tools_versioned.objs/native' 
> > '-L.ppx_tools_versioned_metaquot_409.objs/byte' 
> > '-L.ppx_tools_versioned_metaquot_409.objs/native' '-L/usr/lib64/ocaml'  
> > '/tmp/camlstartup93ae0f.o' '/usr/lib64/ocaml/std_exit.o' 
> > '.ppx/344604af5ef56e11f45ae295381bcce7/_ppx.o' 
> > 'ppx_tools_versioned_metaquot_409.a' 'ppx_tools_versioned.a' 
> > '/usr/lib64/ocaml/ocaml-migrate-parsetree/migrate_parsetree.a' 
> > '/usr/lib64/ocaml/ppx_derivers/ppx_derivers.a' 
> > '/usr/lib64/ocaml/result/result.a' 
> > '/usr/lib64/ocaml/compiler-libs/ocamlcommon.a' '/usr/lib64/ocaml/stdlib.a' 
> > '/usr/lib64/ocaml/libasmrun.a' -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
> > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -lm -ldl 
> > 
> > Not sure how to diagnose this further.  None of this is reproducible
> > for me locally even with all the same Rawhide packages installed.
> 
> If I had to guess, then I would guess that one of the static libraries
> under /usr/lib/64/ocaml/*.a contain bad DWARF. Might it be that one of
> those was build with a bad binutils gas?

That's a good point.

I realised that locally I had a slightly older OCaml package than what
is in Rawhide.  Upgrading to ocaml-4.11.0-0.7.dev2.fc33 and trying to
build ocaml-ppx-tools-versioned and *yes* I'm able to reproduce the
problem locally.

This would indicate a problem in *.a files in the OCaml package as you say.

I'll rebuild it (the OCaml package) and see if I can fix the problem
in Koji that way.

Thanks,

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: vim has lost it's damn mind

[Sérgio Basto]

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 , cindent is buggy for long time, I could say about 10 years , TBH
I don't remember when I turn cindent off .  
> Thanks,
> Richard
> 
> ___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/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
-- 
Sérgio M. B.

___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Still seeing "DWARF version 0 unhandled" (was: Re: No debugsource generated, weird DWARF errors)

[Mark Wielaard]

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: 
> /builddir/build/BUILDROOT/ocaml-ppx-tools-versioned-5.4.0-5.fc33.x86_64/usr/lib64/ocaml/ppx_tools_versioned/metaquot_409/ppx.exe:
>  DWARF version 0 unhandled
> 
> This is with binutils 2.35-10.fc33 which AFAIK should fix this.
> [...]
>   + gcc -O2 -fno-strict-aliasing -fwrapv -O2 -g -pipe -Wall 
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
> -fexceptions -fstack-protector-strong -grecord-gcc-switches 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wall 
> -Wdeclaration-after-statement -Werror -fno-common -fexcess-precision=standard 
> -fno-tree-vrp -ffunction-sections -D_FILE_OFFSET_BITS=64 -D_REENTRANT 
> -DCAML_NAME_SPACE  -Wl,-E -o '.ppx/344604af5ef56e11f45ae295381bcce7/ppx.exe'  
> '-L/usr/lib64/ocaml/compiler-libs' 
> '-L/usr/lib64/ocaml/ocaml-migrate-parsetree' 
> '-L/usr/lib64/ocaml/ppx_derivers' '-L/usr/lib64/ocaml/result' '-L.' 
> '-L.ppx_tools_versioned.objs/byte' '-L.ppx_tools_versioned.objs/native' 
> '-L.ppx_tools_versioned_metaquot_409.objs/byte' 
> '-L.ppx_tools_versioned_metaquot_409.objs/native' '-L/usr/lib64/ocaml'  
> '/tmp/camlstartup93ae0f.o' '/usr/lib64/ocaml/std_exit.o' 
> '.ppx/344604af5ef56e11f45ae295381bcce7/_ppx.o' 
> 'ppx_tools_versioned_metaquot_409.a' 'ppx_tools_versioned.a' 
> '/usr/lib64/ocaml/ocaml-migrate-parsetree/migrate_parsetree.a' 
> '/usr/lib64/ocaml/ppx_derivers/ppx_derivers.a' 
> '/usr/lib64/ocaml/result/result.a' 
> '/usr/lib64/ocaml/compiler-libs/ocamlcommon.a' '/usr/lib64/ocaml/stdlib.a' 
> '/usr/lib64/ocaml/libasmrun.a' -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -lm -ldl 
> 
> Not sure how to diagnose this further.  None of this is reproducible
> for me locally even with all the same Rawhide packages installed.

If I had to guess, then I would guess that one of the static libraries
under /usr/lib/64/ocaml/*.a contain bad DWARF. Might it be that one of
those was build with a bad binutils gas?

Cheers,

Mark
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: arm/neon LTO-related FTBS

[Peter Robinson]

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/48362576/build.log
>
> Basically what they do is compile different .a with different level of
> optimisations as required, and then link them into the final program
> without any optim flag and intend to have it just use the optimised
> functions as is.
>
> Without LTO, this just embeds the code so the rest of the program was
> built naively and it used to work, but with LTO the compiler tries to
> use neon optimisations at some point apparently and the link fails :
>
> /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/10/include/arm_neon.h:10426:22: 
> fatal error: You must enable NEON instructions (e.g. ‘-mfloat-abi=softfp’ 
> ‘-mfpu=neon’) to use these intrinsics.
>
>
> 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 NEON on armhfp
because there are ARMv7 processors that don't have NEON and that would
then crash on those devices.

I believe this is actually a bug in the waypipe project where it's
trying to optimise for the processor is compiling on, not what the
tool chain is telling it to because the the final binary may not run
on the build processor.

On aarch64/ARMv8 it can be assumed there's NEON because it's a
required part of the standard, but it's not a requirement for ARMv7
processors so the software should do run time detection / fast path
code to optimise if it detects NEON at runtime NOT compile time.

So the bug report upstream needs to be about honoring what the
compiler flags is asking it to do not what it thinks it should do.

> I don't think gcc can intuite this so it's probably not a bug though
> (hence I'm not planning on opening a bug), but it is a regression of
> sort...

You're wrong.
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Still seeing "DWARF version 0 unhandled" (was: Re: No debugsource generated, weird DWARF errors)

[Richard W.M. Jones]

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_versioned/metaquot_409/ppx.exe:
 DWARF version 0 unhandled

This is with binutils 2.35-10.fc33 which AFAIK should fix this.

The ocamlopt command which generates this file is:

  Running[230]: (cd _build/default && /usr/bin/ocamlopt.opt -g -o 
.ppx/344604af5ef56e11f45ae295381bcce7/ppx.exe -w -24 -I 
/usr/lib64/ocaml/compiler-libs -I /usr/lib64/ocaml/ocaml-migrate-parsetree -I 
/usr/lib64/ocaml/ppx_derivers -I /usr/lib64/ocaml/result -I . -I 
.ppx_tools_versioned.objs/byte -I .ppx_tools_versioned.objs/native -I 
.ppx_tools_versioned_metaquot_409.objs/byte -I 
.ppx_tools_versioned_metaquot_409.objs/native 
/usr/lib64/ocaml/compiler-libs/ocamlcommon.cmxa 
/usr/lib64/ocaml/result/result.cmxa 
/usr/lib64/ocaml/ppx_derivers/ppx_derivers.cmxa 
/usr/lib64/ocaml/ocaml-migrate-parsetree/migrate_parsetree.cmxa 
ppx_tools_versioned.cmxa ppx_tools_versioned_metaquot_409.cmxa 
.ppx/344604af5ef56e11f45ae295381bcce7/_ppx.ml)

which runs:

  + as  -o '.ppx/344604af5ef56e11f45ae295381bcce7/_ppx.o' '/tmp/camlasmca413d.s'
  + as  -o '/tmp/camlstartup93ae0f.o' '/tmp/camlstartup1ccce5.s'
  + gcc -O2 -fno-strict-aliasing -fwrapv -O2 -g -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-fexceptions -fstack-protector-strong -grecord-gcc-switches 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wall 
-Wdeclaration-after-statement -Werror -fno-common -fexcess-precision=standard 
-fno-tree-vrp -ffunction-sections -D_FILE_OFFSET_BITS=64 -D_REENTRANT 
-DCAML_NAME_SPACE  -Wl,-E -o '.ppx/344604af5ef56e11f45ae295381bcce7/ppx.exe'  
'-L/usr/lib64/ocaml/compiler-libs' '-L/usr/lib64/ocaml/ocaml-migrate-parsetree' 
'-L/usr/lib64/ocaml/ppx_derivers' '-L/usr/lib64/ocaml/result' '-L.' 
'-L.ppx_tools_versioned.objs/byte' '-L.ppx_tools_versioned.objs/native' 
'-L.ppx_tools_versioned_metaquot_409.objs/byte' 
'-L.ppx_tools_versioned_metaquot_409.objs/native' '-L/usr/lib64/ocaml'  
'/tmp/camlstartup93ae0f.o' '/usr/lib64/ocaml/std_exit.o' 
'.ppx/344604af5ef56e11f45ae295381bcce7/_ppx.o' 
'ppx_tools_versioned_metaquot_409.a' 'ppx_tools_versioned.a' 
'/usr/lib64/ocaml/ocaml-migrate-parsetree/migrate_parsetree.a' 
'/usr/lib64/ocaml/ppx_derivers/ppx_derivers.a' 
'/usr/lib64/ocaml/result/result.a' 
'/usr/lib64/ocaml/compiler-libs/ocamlcommon.a' '/usr/lib64/ocaml/stdlib.a' 
'/usr/lib64/ocaml/libasmrun.a' -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld -lm -ldl 

Not sure how to diagnose this further.  None of this is reproducible
for me locally even with all the same Rawhide packages installed.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal to Add: Log In/Out Blocker Criteria

[Christopher Engelhard]

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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal to Add: Log In/Out Blocker Criteria

[Miro Hrončok]

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 a singe user system, I'd like to be able to log out and back in again.


+1 to make this a beta blocker

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Vít Ondruch]

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

Therefore I wonder what is the status of EarlyOOM. Should I let the
package go? If not, then the situation should be fixed somehow, probably
either by reverting the revert or adding the dependency into
fedora-release as was proposed elsewhere.


Vít


[1]
https://src.fedoraproject.org/rpms/earlyoom/c/a6d0f45a3524830642a4120704e8d295598f8ec3?branch=master


Dne 03. 01. 20 v 20:18 Ben Cotton napsal(a):
> https://fedoraproject.org/wiki/Changes/EnableEarlyoom
>
> == Summary ==
> Install earlyoom package, and enable it by default. This will cause
> the kernel oomkiller to trigger sooner, but will not affect which
> process it chooses to kill off. The idea is to recover from out of
> memory situations sooner, rather than the typical complete system hang
> in which the user has no other choice but to force power off.
>
>
> == Owner ==
> * Name: [[User:chrismurphy| Chris Murphy]]
> * Email: bugzi...@colorremedies.com
>
> == Detailed Description ==
> Workstation working group has discussed "better interactivity in
> low-memory situations" for some months. In certain use cases,
> typically compiling, if all RAM and swap are completely consumed,
> system responsiveness becomes so abysmal that a reasonable user can
> consider the system "lost", and resorts to forcing a power off. This
> is objective a very bad UX. The broad discussion of this problem, and
> some ideas for near term and long term solutions, is located here:
>
> Recent long discussions on "Better interactivity in low-memory situations"
> https://pagure.io/fedora-workstation/issue/98
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XUZLHJ5O32OX24LG44R7UZ2TMN6NY47N/
>
> Fedora editions and spins, have the in-kernel OOM (out-of-memory)
> manager enabled. The manager's concern is keeping the kernel itself
> functioning. It has no concern about user space function or
> interactivity. This proposed change attempts to improve the user
> experience, in the short term, by triggering the in-kernel process
> killing mechanism, sooner. Instead of the system becoming completely
> unresponsive for tens of minutes, hours or days, the expectation is an
> offending process (determined by oom_score, same as now) will be
> killed off within seconds or a few minutes. This is an incremental
> improvement in user experience, but admittedly still suboptimal. There
> is additional work on-going to improve the user experience further.
>
> Workstation working group discussion specific to enabling earlyoom by default
> https://pagure.io/fedora-workstation/issue/119
>
> Other in-progress solutions:
> https://gitlab.freedesktop.org/hadess/low-memory-monitor
>
> Background information on this complicated problem:
> https://www.kernel.org/doc/gorman/html/understand/understand016.html
> https://lwn.net/Articles/317814/
>
> == Benefit to Fedora ==
>
> There are two major benefits to Fedora:
>
> * improved user experience by more quickly regaining control over
> one's system, rather than having to force power off in low-memory
> situations where there's aggressive swapping. Once a system becomes
> unresponsive, it's completely reasonable for the user to assume the
> system is lost, but that includes high potential for data loss.
>
> * reducing forced poweroff as the main work around will increase data
> collection, improving understanding of low memory situations and how
> to handle them better
>
>
> == Scope ==
> * Proposal owners:
> a. Modify 
> {{code|https://pagure.io/fedora-comps/blob/master/f/comps-f32.xml.in}}
> to include earlyoom package for Workstation.
> b. Modify 
> {{code|https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/80-workstation.preset}}
> to include:
> 
> # enable earlyoom by default on workstation
> enable earlyoom.service
> 
>
> * Other developers:
> Restricted to Workstation edition, unless other editions/spins want to opt-in.
>
> * Release engineering: [https://pagure.io/releng/issues #9141] (a
> check of an impact with Release Engineering is needed) 
>
> * Policies and guidelines: N/A
> * Trademark approval: N/A
>
> == Upgrade/compatibility impact ==
> earlyoom.service will be enabled on upgrade. An upgraded system should
> exhibit the same behaviors as a clean installed system.
>
> == How To Test ==
> * Fedora 30/31 users can test today, any edition or spin:
> {{code|sudo dnf install earlyoom}}
> {{code|sudo systemctl enable --now earlyoom}}
>
> And then attempt to cause an out of memory situation. Examples:
> {{code|tail /dev/zero}}
> {{code|https://lkml.org/lkml/2019/8/4/15}}
>
> * Fedora Workstation 32 (and Rawhide) users will see this service is
> already enabled. It can be toggled with  {{code|sudo syste

Re: Review exchange

[Qiyu Yan]

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.com/show_bug.cgi?id=1861188
> - https://bugzilla.redhat.com/show_bug.cgi?id=1861190

Above is done, and included into rawhide, and I need following
 - https://bugzilla.redhat.com/show_bug.cgi?id=1862660
to be reviewed to finish. Anyone interested in this?

Still, let me know if you need me to do some review in exchange!

>
> I think they will be trivial to review (go2rpm and fix all #FIXME
> parts), can someone help me?
>
> I can do reviews in exchange.
>
> --
> Best regards,
> Qiyu Yan
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: s390x builder improvements

[Hans de Goede]

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 4. (Those are 15-24).

2. I moved the varnish package cache from 07 (a z/vm guest) to 24 (a kvm
guest). I have noticed the z/vm ones (thats 01-14) seem to suffer from
slowdowns or high io wait more under high load and/or over a long time.
Hopefully moving that to a more stable instance will help with lots of
issues people have seen with not being able to download or the like.

3. I switched the cache model on the kvm ones to unsafe, which we had
already used on a number of other builders. I think the worst that can
happen here is that the vm becomes corrupt if it's abruptly shutdown or
killed, but thats fine, we can just spin up a new one. If a build gets
messed up, koji would just restart it again on another vm, etc.

4. There was a misconfiguration in kojid where if the cache was not
answering it tried directly, but it was trying the wrong url. I have
corrected this, so if the primary cache is down it should fall back to
trying directly on it's own.

5. I've updated and rebooted them all. They seem to behave much better
after reboots and then slowly get slower over time. ;(

I've been watching it for the last hour or so and so far 0 failures that
I can attribute to s390x cache or builder infra.

Hopefully that should make things more stable.


Awesome, thank you!

Regards,

Hans
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning a bunch of my packages (part 2 of X)

[Raphael Groner]

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.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 Mass Rebuild

[Vít Ondruch]

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?buildID=1567804

while the ticket references some failed ELN build:

https://koji.fedoraproject.org/koji/taskinfo?taskID=48384772


Thanks


Vít


Dne 02. 08. 20 v 0:57 Mohan Boddu napsal(a):
> Hi all,
>
> Per the Fedora 33 schedule[1] we started a mass rebuild for Fedora 33
> on Jul 27th 2017. We did a mass rebuild for Fedora 33 for the changes listed 
> in:
>
> https://pagure.io/releng/issue/9616
>
> Mass rebuild was done in a side tag (f33-rebuild) and moved over to f33.
>
> Failures can be seen
> https://kojipkgs.fedoraproject.org/mass-rebuild/f33-failures.html
>
> Things still needing rebuilt
> https://kojipkgs.fedoraproject.org/mass-rebuild/f33-need-rebuild.html
>
> 18002 builds have been tagged into f33, there are currently 2811 failed
> builds that need to be addressed by the package maintainers.
>
> Mass rebuildling of modules and FTBFS bugs will be filed shortly.
>
> Please be sure to let releng know if you see any bugs in the
> reporting. You can contact releng in #fedora-releng on freenode, by
> dropping an email to our list[2] or filing an issue in pagure[3]
>
> Regards,
> Mohan Boddu.
>
> [1] https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html
> [2] 
> https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
> [3] https://pagure.io/releng/
>
> On Wed, Jul 22, 2020 at 10:59 AM Mohan Boddu  wrote:
>> Hi all,
>>
>> The mass rebuild is postponed to next Monday 27th July 2020 since a
>> couple of changes haven't landed yet.
>>
>> For more information, please look at https://pagure.io/fesco/issue/2451
>>
>> We will keep you posted if anything changes.
>>
>> Thanks.
>>
>> On Mon, Jul 20, 2020 at 5:38 PM Mohan Boddu  wrote:
>>> Mohan Boddu 
>>>
>>> 4:32 PM (1 hour ago)
>>> to devel-announce
>>> Hi all,
>>>
>>> Per the Fedora 33 schedule[1] we will start a mass rebuild for Fedora 33
>>> on Jul 22nd 2020. We will run a mass rebuild for Fedora 33 for the
>>> changes listed in:
>>>
>>> https://pagure.io/releng/issues?status=Open&tags=mass+rebuild
>>>
>>> Mass rebuild will be done in a side tag (f33-rebuild) and moved over
>>> when completed.
>>>
>>> Failures can be seen
>>> https://kojipkgs.fedoraproject.org/mass-rebuild/f33-failures.html
>>>
>>> Things still needing rebuilt
>>> https://kojipkgs.fedoraproject.org/mass-rebuild/f33-need-rebuild.html
>>>
>>> FTBFS bugs will be filed shortly.
>>>
>>> Please be sure to let releng know if you see any bugs in the
>>> reporting. You can contact releng in #fedora-releng on freenode, by
>>> dropping an email to our list[2] or filing an issue in pagure[3]
>>>
>>> Regards,
>>> Mohan Boddu.
>>>
>>> [1] https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html
>>> [2] 
>>> https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
>>> [3] https://pagure.io/releng/
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
> ___
> 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/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

ocaml-ppx-tools-versioned debuginfo disabled, dune and ppx extensions

[Richard W.M. Jones]

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 possibly affects all ppx extensions).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: %{_vpath_builddir} needs to be in the Cmake packaging guidelines

[Igor Raits]

-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 response to
> one
> of my earlier emails to find the answer again...

https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/

%__cmake_in_source_build

Controls whether builds are done in-source (when defined) or out-
of-source (when undefined). See the Defining source and build
directories for more information.

Links to:
https://docs.fedoraproject.org/en-US/packaging-guidelines/vpath/

Feel free to submit a PR to make it more visible.

> 
> %{_vpath_builddir}
> 
> But that begs the question, now that we have updated %cmake, and new
> %cmake_build & %cmake_install, why is it %_vpath_builddir and not
> %_cmake_builddir?
> 
> Thanks,
> Richard
> ___
> 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/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8pECIACgkQEV1auJxc
Hh4L7Q/+M7N/MJg0od9JZ2ri3Kcd7dtzd7WzU6X6/MPtoTtnTYd5AlJQM8zZYrfj
jLFM6Hd9JdhReUodTeXYMzcuIRctjFNJv3ycI7E7pF5XvkQc6rnie6e/NwrUyCUG
b0/I4F4RUpHQfAbR/Pa05lbBfFb1pN0jCoXsc77dLWLZ//FefBYEVYTdzc44mKhx
TMOX8MPapBlu6P4XITajcI/cXMwecqgSfGPmiGwz2aqn9Ec4415khsKhjhT6CnaA
IkgLGPHZwrO1WwZXnOR+TLR6QBpGyna3xLOCE7VskH+WmsYgd6UGTm+t86BFbBDl
hThVdjK4I+uV0SU7qVq+NqtOIQRd014aKBGJpl1pmadjJhvBApJgZyC8e83OiOLm
FC1OziylaOsYvJuUIZzBG7VMyFNM4J7YR8CKD4r0CLkvkCTT0Re0jzxmXzvZzQd+
mmAsvehjIHPG0SDti8521l22dN7pvkvVO0OAfb0XDXKAdQaIQnosZyEi2G3Q4w1j
kRNLyKsIvLdHaXMqqQ/6T/O5zkaSdM7vdD54HebdzcR3iVqy3TyaI8TmMsSlA0jz
DfSd5/+W/dIen6lBOAwVO6R935Y9LCt5IdD5Szbs75wAJNOyRLnwHj2I8beNHxVi
iaUNm4KdaKxupzqwiQ9EPpClssNdkgEi2HQi/q3B+PXSu57RrOI=
=ZYgX
-END PGP SIGNATURE-
___
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/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org