Re: F35 Change: Drop the the "Allow SSH root login with password" option from the installer GUI (Self-Contained Change proposal)

[Ralf Corsepius]

On 5/14/21 2:50 PM, Martin Kolman wrote:

On Thu, 2021-05-13 at 20:09 +0200, Peter Boy wrote:



We discussed that in the Fedora Server Edition Working Group and
opted to leave it as is for the Server installation iso. A lot of
servers are running in a protected environment. And there are
situations when you need urgent access but do not sit at your desktop
and don’t have the key available. So let the server admin decide what
is best in a given installation context. In most cases it is the
current default (disallow password login)

Do those server deployments not have any users accounts other than root
? Creating a non-root user account, possibly with admin rights (all
possible from within Anaconda) would seem like a safer option for
accasional/emergency password based access to such machines over SSH.


I don't see, how this would any safer than directly using "root".

Ralf
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [rpms/perl-Plack] PR #1: Move Apache handler ro sub-packages

[Ralf Corsepius]

On 5/11/21 2:06 AM, Emmanuel Seyman wrote:


eseyman commented on the pull-request: `Move Apache handler ro sub-packages` 
that you are following:
``
Thank you for this PR, Jikta. I've been meaning to work on this since the next 
version of Bugzilla will  require PSGI and having handlers in their own 
subpackages makes things simpler.
Actually, I am surprized and irritated about not having been informed 
beforehand nor having been CC:-ed by any means.


@Jitka: What is going on here?

I can't deny thinking, Fedoras infrastructure has derailed into an 
unusable, bureaucratic mess.



Ralf, any input before I merge this?


No idea. Firstly I'd have to have look into this. Unfortunately, I 
probably will not have any time available for Fedora throughout the next 
couple of weeks..


Ralf
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI

[Ralf Corsepius]

On 4/30/21 3:21 PM, Richard W.M. Jones wrote:

On Thu, Apr 29, 2021 at 10:09:12PM +0200, Martin Kolman wrote:

Now fast forward to today, it's 2021, any use cases that needed
password based root login via SSH had 2 more years to migrate while the
amount of password guessing attacks certainly didn't get any lower.


Not everything is exposed to the internet.  Please leave the option,
disabled by default and with a suitable warning if you like.


+1

Removing this option is not helpful in a LAN.

Ralf
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: What do we think about always autoreconfing? (was: Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal))

[Ralf Corsepius]

On 4/13/21 12:26 PM, Richard W.M. Jones wrote:

Hijacking this thread originally about
https://fedoraproject.org/wiki/Changes/Autoconf_271

What is the current thinking in Fedora about always running
"autoreconf -i" during builds that use autotools?


IMO, it's naive wishful thinking, applicable to trivial packages.

Most non-trivial packages require specific versions.

Also, in general, it's not advisable to regenerate auto*tools generated 
sources at all. I am aware, this thought has become unpopular, because 
the autotools have been mostly "dormant" in recent years, so people are 
not used to face such problems, anymore.



In Debian it's been recommended for a long time:
https://wiki.debian.org/Autoreconf


Well, ... Debian's mistake.


It also could fail - I noticed that autoconf
2.71 has several incompatibilities with the most widely used autoconf
(2.69).

This is only the tip of the proverbial "iceberg".

autoconf > 2.69 is pretty imcompatible and bugged.

Ralf

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: End of CentOS Linux: What about Fedora?

[Ralf Corsepius]

On 12/9/20 12:33 PM, Jaroslav Prokop wrote:

Hello,

On 09/12/2020 12:12, Christoph Karl wrote:

Hello!

On 09.12.20 04:26, Sergio Belkin wrote:

How does this (https://blog.centos.org/2020/12/future-is-centos-stream/)
affect Fedora?


I think Fedora now needs some kind of LTS.
At least I was planning to support CentOS via EPEL as
a kind of "Fedora LTS".


If I remember correctly and not making it up there was a discussion some 
years back about Fedora LTS.


Where does the fairy tale of CentOS being a "Fedora LTS" come from?

Fedora and CentOS address completely different audiences and provide 
completely different packages and "features".



I am starting to get really confused on Fedora's position here.

So am I. Actually I do not see any common ground for Fedora and CentOS.

Are we 
anywhere in the pipeline?
Actually, I do not care. I support Fedora, RHEL is RHAT's business and 
so is its puppet/clone CentOS.


Ralf
___
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 34 Change: Route all Audio to PipeWire (System-Wide Change)

[Ralf Corsepius]

On 11/20/20 5:26 PM, Ben Cotton wrote:


The pulseaudio package will be uninstalled and pipewire-pulse will be installed.

>

pipewire-pulse does not yet implement all the features of pulseaudio
but it is expected that
comparable functionality will be implemented later. Most notable
features that are likely
not going to be available for fedora 34

IMO, this alone disqualifies this plan.

Fedora should be a stable end-user distro and not a testing site for 
eager devs to test their immature and incomplete works.


Ralf
___
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: The future of legacy BIOS support in Fedora.

[Ralf Corsepius]

On 10/19/20 6:47 PM, Stephen John Smoogen wrote:

The issue is that while 'moore's' law was no longer doubling every 18months
it was still working and tasks had to be rewritten to work with more
cores/threads/etc. As that happened the software's need for more CPU power
has increased to the point were a 10+ year computer isn't very useful for
'modern' software (browser and various applications). Instead if you want
to have something work on a 2012 system well.. just use software from
2012.  It is still available.
I know you know, you are being polemic and cheating. 2012's SW is 
unusable today.



Sure you can install Linux on that 15 year
old computer but if you have to tell the user well you can't actually use a
browser, an editor or half the things you can do on your cheapest
smart-phone.. what use is that computer?
Do yourselves a favor and try it yourselves: A 2012 mid-class system 
still outperforms many todays low-end systems and many notebooks.


These systems are well suitable for many purposes!

Ralf
___
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/fedora33 build job hangs

[Ralf Corsepius]

On 8/13/20 3:17 PM, Fabio Valentini wrote:

On Thu, Aug 13, 2020 at 3:15 PM Ralf Corsepius  wrote:


Hi,

A f33 build job, I launched a couple of hours ago, seems to hang on s390

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

What am I supposed to do?

Ralf


Wait. It's not hanging, it's not running yet.

Looking at [0] all the s390x builders are busy right now, so it's just
a matter of time until they become free again and your build will
proceed then.


Thanks, you were right.

I simply didn't expect a build job which usually takes very few minutes 
to build, to take 2hours+ for f33/s390x ;)


Ralf
___
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

s390x/fedora33 build job hangs

[Ralf Corsepius]

Hi,

A f33 build job, I launched a couple of hours ago, seems to hang on s390

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

What am I supposed to do?

Ralf
___
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: The future of legacy BIOS support in Fedora.

[Ralf Corsepius]

On 7/1/20 6:10 PM, Solomon Peachy wrote:

On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:

I'm currently using BIOS, grub, grub2 basically everywhere, even on
fresh new machines,


This won't be the case for much longer; Intel will finally drop CSM
("BIOS") support this year.

Even putting that aside, for the past several years CSM/BIOS has been
slowly bitrotting due to a lack of real testing, as the last few Windows
releases have mandated use of UEFI for preinstalled systems, plus the
EOLing of Windows 7 and (especially) XP.


Win 10 still runs on BIOS systems and (Unlike Fedora) on 32bit systems.

Ralf
___
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: The future of legacy BIOS support in Fedora.

[Ralf Corsepius]

On 6/30/20 3:34 PM, Jóhann B. Guðmundsson wrote:
Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes 
it beg the question if now would not be the time to stop supporting 
booting in legacy bios mode and move to uefi only supported boot which 
has been available on any common intel based x86 platform since atleast 
2005.
This statement is simply not true - With all due respect, I for one 
consider this statement of yours to be close to a blatant cheat and a lie.


I definitely own BIOS-only systems, which have been sold long after 2005 
and which are still in everyday use.


Now in 2017 Intel's technical marketing engineer Brian Richardson 
revealed in a presentation that the company will require UEFI Class 3 
and above as in it would remove legacy BIOS support from its client and 
datacenter platforms by 2020 and one might expect AMD to follow Intel in 
this regard.


Fedora should not care Intel's plans, but about the systems users use.

IMNSHO, this inevitably must comprise to continueg supporting 
BIOS-systems for at least another decade.


This post is just to gather feed back why Fedora should still continue 
to support legacy BIOS boot as opposed to stop supporting it and 
potentially drop grub2 and use sd-boot instead.


Definitely the former.

Share your thoughts and comments on how such move might affect you so 
feedback can be collected for the future on why such a change might be 
bad, how it might affect the distribution and scope of such change can 
be determined for potential system wide proposal.


Dropping BIOS would render Fedora entire unsuitable for me and will like 
cause me to stop supporting Fedora.


Ralf
___
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: [Test-Announce] New Release Freeze Times

[Ralf Corsepius]

On 2/20/20 8:04 PM, Mohan Boddu wrote:

Hi all,

It has been brought to our attention that release freezes starting at
00:00 UTC has been confusing for a lot of people. So, we decided to
change it to 14:00 UTC.


This longs for an explanation.

I fail to understand why 14:00 UTC should be less confusing than 00:00 
UTC. Seems like planless bikesheding to me.


Ralf
___
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: Drop Optical Media Release Criterion

[Ralf Corsepius]

On 12/17/19 5:14 PM, Adam Williamson wrote:

On Tue, 2019-12-17 at 10:43 +0100, Kamil Paral wrote:

On Tue, Dec 17, 2019 at 2:31 AM Adam Williamson 
wrote:


On Mon, 2019-12-16 at 16:52 -0700, John M. Harris Jr wrote:

I've offered to take on responsibility for these tests in this thread,

and I'm

still open to that. This is still important to many users, and I'm more

than

happy to volunteer my time to support those users.


If we can actually rely on you to show up and do these tests - within,
remember, sometimes a very short time frame - that'd be great. However,
we've gone through this loop before with some other criteria (we
propose dropping them, someone complains and promises to do the
testing, then doesn't actually do it in the end) enough times that we'd
be a bit cautious about this. Still, we have F32 Beta coming up quite
soon, we could potentially delay this feature and see how that goes -
see if anyone besides RH Fedora QE staff shows up to run the tests...



I think having community help with optical testing shouldn't really affect
the outcome of the proposal. We claim that the importance of optical media
has diminished and it's now below the threshold for granting it a
release-blocking status. That's not really affected by whom executes the
tests.


To me it is, in a weird way: I tend to view the presence of someone
who's willing to actually *do* something as a proxy for there being
others who care about it. For instance on the 32-bit x86 topic - if the
x86 SIG had *worked* and we'd had one or two people who really cared
about it show up to do the work, like we have for ARM or ppc64, I'd
have been more inclined to believe there were more people out there who
really needed to run Fedora on 32-bit x86.


From my perspective, you are twisting reality. The 32-bit x86 sig never 
had a chance, because it was clear to everybody involved, RHAT wanted to 
kill it and because everybody @RH proactively worked against any attempt 
 to support it.



So if the question is "do people really want Fedora on physical optical
disc?", I'm more likely to believe the answer is 'yes' if one or two of
them shows up to actually test it...
I am definitely for "keeping optical media". But because of the lessons 
learnt from how RHAT behaved in the i386-shoting and on the modules 
crap, I am not expecting RHAT nor FESCO to listen nor to care.


Now think about, why Fedora is loosing users.

Ralf
___
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 Python 2 packages to be removed mid-November (= in a week)

[Ralf Corsepius]

On 11/7/19 2:34 PM, Miro Hrončok wrote:

On 07. 11. 19 13:59, Felix Schwarz wrote:


Am 07.11.19 um 13:01 schrieb Petr Viktorin:

If this took you by surprise, don't panic. It's possible to change the
default. Let us know and we'll work things out.


Somehow I feel like I don't understand the report – or we are 
approaching an
(almost) unmitigated disaster here: There are so many "high profile" 
packages

which are slated for removal that we might wipe out half of our Python
packaging eco system.


What are the high profile packages you are talking about?


Fedora - Combined wiht the modules insanity, you guys seem to be keen on 
shifting Fedora into non-usability and into non-importance.


Ralf
___
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: Modularity: The Official Complaint Thread

[Ralf Corsepius]

On 11/5/19 9:41 PM, Alex Scheel wrote:


IMO, without a resolution in Fedora we'll never get one in RHEL.


And? Why should Fedora care about RHEL?

I for one consider RHEL not to be its partner, but it to be an 
initiative to gradually push Fedora out of this planet.


Ralf
___
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: FreeCAD required updates (PySide2 & Coin4)

[Ralf Corsepius]

On 10/8/19 8:03 AM, Zbigniew Jędrzejewski-Szmek wrote:

On Mon, Oct 07, 2019 at 04:34:28PM -0400, Scott Talbert wrote:

On Mon, 7 Oct 2019, Richard Shaw wrote:


I am in the midst of updating the freecad package in two major ways:
Qt4 -> Qt5 (via PySide -> PySide2, which also facilitates moving from Python
2 to 3)
and
Coin3 -> Coin4 (Which requires several other packages move to Coin4)

I have been working with the Coin2/3, SoQt, & SIMVoleon maintainer Ralf but
I stopped getting responses. The last response by email being September
13th.

I have even submitted pull requests so my requested changes can be easily
evaluated.

https://src.fedoraproject.org/rpms/SoQt/pull-request/2
https://src.fedoraproject.org/rpms/OpenSceneGraph/pull-request/2
https://src.fedoraproject.org/rpms/SIMVoleon/pull-request/1

Updating to Coin4 is required to take care of a longstanding bug[1]

So I'm trying to be nice but I don't think it's doing any good to wait for a
reply that may never come meanwhile the users could easily get the idea that
I (or Fedora) don't care about fixing bugs.


Those are fairly substantial changes, but time is of essence here.

I could not disagree more. Quality and stability is of more essence, here.


I reviewed all three PRs, and they look fine. (One needs a rebase).
I think you should just push and build all packages.


You don't want to know what I think of this.


Ralf
___
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: FreeCAD required updates (PySide2 & Coin4)

[Ralf Corsepius]

On 10/7/19 10:23 PM, Richard Shaw wrote:

I am in the midst of updating the freecad package in two major ways:

Qt4 -> Qt5 (via PySide -> PySide2, which also facilitates moving from
Python 2 to 3)
and
Coin3 -> Coin4 (Which requires several other packages move to Coin4)

I have been working with the Coin2/3, SoQt, & SIMVoleon maintainer Ralf but
I stopped getting responses. The last response by email being September
13th.


But I am very busy with other topics these days and haven't had any 
chance to look into what you've done.


To say the least, I am actually feeling quite grumpy about what I 
perceive as hastiness on your part (Keep in mind Coin4 landed in rawhide 
yesterday).


Ralf

___
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: [Test-Announce] Fedora 31 Beta Release Announcement

[Ralf Corsepius]

On 9/18/19 12:11 PM, Kalev Lember wrote:


On 9/18/19 10:29, Petr Pisar wrote:

On 2019-09-18, Ralf Corsepius  wrote:

    - package perl-libs-4:5.28.2-439.module_f31+6019+b24e098f.x86_64 is
excluded


Funnily DNF finds out that you could actually get that package satisfied
if you enabled a modular Perl. Unfortunatelly DNF does not report what
module stream the modular perl-libs packages comes from. There is indeed
some room for improvement. DNF could start recommending "maybe you wanted
to enable perl:5.28 stream?" :)


Openly said, to me, the modules are permanent source of troubles.

Hm, did perl get moved to the modular repo? That sounds like it is going 
to cause more issues than solve as it's not a leaf package. Why can't it 
stay as a regular package?

Featuritis? Actually, do not see any usefulness in any module.

Ralf
___
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: [Test-Announce] Fedora 31 Beta Release Announcement

[Ralf Corsepius]

On 9/17/19 4:04 PM, Mohan Boddu wrote:


Since this is a Beta release, we expect that you may encounter bugs or
missing features. To report issues encountered during testing, contact the
Fedora QA team via the mailing list or in #fedora-qa on Freenode.


Some not so pleasant results:

# dnf system-upgrade download --refresh --releasever=31
Before you continue ensure that your system is fully upgraded by running 
"dnf --refresh upgrade". Do you want to continue [y/N]: y

...
Ignoring repositories: rpmfusion-free-updates, rpmfusion-nonfree-updates
Modular dependency problems:

 Problem 1: conflicting requests
  - nothing provides module(platform:f30) needed by module 
eclipse:2019-06:3020190807134759:6ebe2c0f-0.x86_64
 Problem 2: module jmc:latest:3120190813124555:7188e41a-0.x86_64 
requires module(eclipse), but none of the providers can be installed

  - conflicting requests
  - nothing provides module(platform:f30) needed by module 
eclipse:2019-06:3020190807134759:6ebe2c0f-0.x86_64

Error:
 Problem 1: package crypto-utils-2.5-4.fc29.x86_64 requires 
libperl.so.5.28()(64bit), but none of the providers can be installed
  - package crypto-utils-2.5-4.fc29.x86_64 requires 
perl(:MODULE_COMPAT_5.28.0), but none of the providers can be installed
  - perl-libs-4:5.28.2-439.fc30.x86_64 does not belong to a distupgrade 
repository

  - problem with installed package crypto-utils-2.5-4.fc29.x86_64
  - package perl-libs-4:5.28.2-439.module_f31+6019+b24e098f.x86_64 is 
excluded
  - package perl-libs-4:5.28.2-439.module_f31+6050+a462f342.x86_64 is 
excluded
 Problem 2: problem with installed package 
libopenshot-0.2.3-2.20190406git101f25a.fc30.x86_64
  - package libopenshot-0.2.3-2.20190406git101f25a.fc31.x86_64 requires 
libjsoncpp.so.19()(64bit), but none of the providers can be installed
  - libopenshot-0.2.3-2.20190406git101f25a.fc30.x86_64 does not belong 
to a distupgrade repository

  - jsoncpp-1.8.4-6.fc30.x86_64 does not belong to a distupgrade repository

Ralf
___
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: mock -r fedora-31-i386 broken

[Ralf Corsepius]

On 9/13/19 1:34 PM, Vít Ondruch wrote:

Just FTR, this was brought up already:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2V2RRTT7DTHWANFHL6YBVM7RILCWDGGT/


Understood - Give me a ping when Fedora has a usable infrastructure again.

I'll suspend all Fedora activities until then. Right now, this stuff is 
just in unusable shape.


Ralf
___
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

mock -r fedora-31-i386 broken

[Ralf Corsepius]

Hi,

Apparently mock-build roots for fedora-31-i386 currently are broken:

# mock -r fedora-31-i386 --init
INFO: mock.py version 1.4.16 starting (python version = 3.7.4)...
Start: init plugins
INFO: selinux disabled
Finish: init plugins
Start: run
Start: clean chroot
Finish: clean chroot
Start: chroot init
INFO: calling preinit hooks
INFO: enabled root cache
INFO: enabled dnf cache
Start: cleaning dnf metadata
Finish: cleaning dnf metadata
INFO: enabled HW Info plugin
Mock Version: 1.4.16
INFO: Mock Version: 1.4.16
Start: dnf install
No matches found for the following disable plugin patterns: local, spacewalk
fedora 
 220 kB/s |  54 kB 00:00

Failed to download metadata for repo 'fedora'
Error: Failed to download metadata for repo 'fedora'
ERROR: Command failed:
 # /usr/bin/dnf --installroot /var/lib/mock/fedora-31-i386/root/ 
--releasever 31 --setopt=deltarpm=False --disableplugin=local 
--disableplugin=spacewalk install @buildsys-build

No matches found for the following disable plugin patterns: local, spacewalk
fedora 
 220 kB/s |  54 kB 00:00

Failed to download metadata for repo 'fedora'
Error: Failed to download metadata for repo 'fedora'


Ralf
___
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-gpg-keys not updated yet again

[Ralf Corsepius]

On 8/19/19 10:50 AM, Zbigniew Jędrzejewski-Szmek wrote:

This seems to repeat every 6 months: rawhide mock is broken on stable
Fedora, people are scrambling to install the right gpg keys, dnf reports
unsigned packages.


The same applies to f31.

The f31 repos are not in place, the mock-configs for f31 not place in 
f30/f29 (Mock building for rawhide produces fc32 rpm ...)


The usual chaos, as it has been many times before, in phases like these.

Ralf
___
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: x86-64 micro-architecture update

[Ralf Corsepius]

On 7/22/19 8:51 PM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update



After preliminary discussions with CPU vendors, we propose AVX2 as the
new baseline.  AVX2 support was introduced into CPUs from 2013 to
2015. See 
[https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
CPUs with AVX2].


In other words, Fedora will be unusable on most HW anything older than 
3-4 years.


This is not helpful and furtherly directs Fedora into meaninglessness.

Ralf
___
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 31 System-Wide Change proposal: No More i686 Kernels

[Ralf Corsepius]

On 6/21/19 7:26 PM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels

== Summary ==
Stop building i686 kernels, reduce the i686 package to a
kernel-headers package that can be used to build 32bit versions of
everything else.


How does this affect the i386 as secondary architecture?

Actually, I feel this proposal is a violoent cheat and should actually 
be entitled: Drop i386 as secondary architecture.


Ralf
___
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: Stale packages in Fedora 30

[Ralf Corsepius]

On 6/3/19 7:05 PM, Adam Williamson wrote:

Some people don't see any problem with this, personally it drives me
crazy and I wish it were policy that *every* retired package must be
obsoleted. But it isn't.
I am quite shocked to hear this from you. I wouldn't have expected this 
attitude from you.


You seem have forgotten about the problems, such obsoletes cause, e.g. 
when packages are being reintroduced or move to 3rd party repos or when 
3rd party packages depend upon them.


Ralf






___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How to install a mountpoint directory from an rpm?

[Ralf Corsepius]

On 5/1/19 2:24 AM, Ian Kent wrote:

On Tue, 2019-04-30 at 17:29 +, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, Apr 30, 2019 at 01:12:43PM -0400, Robert Marcano wrote:

On 4/30/19 11:45 AM, David Howells wrote:

Hi,

I need to install a directory (/afs) that will be a mountpoint that a
systemd
service (also installed in the rpm) will mount upon.


I seem to remember you can't create root level directories from a
program either.


Well, creating root level directories actually is prohibited by the FHS 
ever since it exists, because root level directories are standardized 
(barring the fact, Fedora/RH diverged from these rule on many occasions).


That said /afs is nothing but a - though being not uncommon - a local 
convention, among many others (e.g. /com, /srv, ...).


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [Fwd: Orphaned packages to be retired (Java packages in 2 weeks)]

[Ralf Corsepius]

On 3/19/19 11:01 AM, Stelian Iancu wrote:

On Tue, Mar 19, 2019 at 7:35 AM Emmanuel Seyman  wrote:


* Sérgio Basto [19/03/2019 00:03] :


I though it was just one person which decide orphan his 259 packages


Mikolaj is the last actif member of the Java SIG.


And who is guilty for this?


I think the bigger question here is what is going to happen with the Java SIG?

In general, what is the situation of Java in Fedora?
I regret having to say this, but I think it's inevitable: Due to the 
Java-"modularization" activities, Java in Fedora is going to be a matter 
of the past, soon.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Ralf Corsepius]

On 3/26/19 5:44 PM, Tomasz Kłoczko wrote:


$ rpm --showrc | egrep -e "popd|pushd"


This scriptlet of yours isn't posix compliant, either.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular repositories in mock configs: please don't

[Ralf Corsepius]

On 3/5/19 9:08 AM, Adam Samalik wrote:

On Mon, Mar 4, 2019 at 10:26 PM Michael Cronenworth  wrote:


On 3/4/19 3:04 AM, Petr Šabata wrote:

You can view them as virtual repositories with dependencies.  I
think that might be the simplest way to put it.

You can try playing with fedmod to generate your modulemd file or
you can just write it from scratch; it's not all that complicated.


Why should I care? Please, win me over. (I'm being serious.)



I think you should care if:

a) You need to maintain multiple versions of the same app/runtime/set of
tools tools in Fedora (or an alternative to something that already exists),
or
b) You only want to maintain one source branch per package for all Fedora
releases, or
c) You could benefit from having a build recipe in case you maintain
app/runtime/set of tools tools represented by multiple packages that need
to be built in the right order

But if any of the above is something that you need/want to do, then
Modularity won't help you nor hurt you in any way.


All of what list above can be handled at the rpm-level by means of 
"proper" system integration.


That said, to me, modules are an approach to circumvent system integration.

Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

tracebacks while "git push"ing to Fedora's git

[Ralf Corsepius]

Hi,

when "git push"ing updates to Fedora's git, I am currently encountering 
this kind of tracebacks:


$ git push
Total 0 (delta 0), reused 0 (delta 0)
remote: Emitting a message to the fedmsg bus.
remote: * Publishing information for 1 commits
remote: Traceback (most recent call last):
remote:   File 
"/usr/lib/python2.7/site-packages/pagure/hooks/__init__.py", line 394, 
in run_project_hooks

remote: changes=changes,
remote:   File 
"/usr/lib/python2.7/site-packages/pagure/hooks/__init__.py", line 111, 
in runhook

remote: changes=changes,
remote:   File 
"/usr/lib/python2.7/site-packages/pagure/hooks/default.py", line 336, in 
post_receive

remote: but_uids=pr_uids,
remote:   File "/usr/lib/python2.7/site-packages/celery/local.py", line 
191, in __call__

remote: return self._get_current_object()(*a, **kw)
remote:   File "/usr/lib/python2.7/site-packages/celery/app/task.py", 
line 375, in __call__

remote: return self.run(*args, **kwargs)
remote:   File 
"/usr/lib/python2.7/site-packages/pagure/lib/tasks_utils.py", line 36, 
in decorated_function

remote: return function(self, session, *args, **kwargs)
remote:   File "/usr/lib/python2.7/site-packages/pagure/lib/tasks.py", 
line 700, in refresh_pr_cache

remote: session, project, but_uids=but_uids
remote:   File "/usr/lib/python2.7/site-packages/pagure/lib/query.py", 
line 3318, in reset_status_pull_request
remote: {model.PullRequest.merge_status: None}, 
synchronize_session=False
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/query.py", line 2796, 
in update

remote: update_op.exec_()
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/persistence.py", line 
897, in exec_

remote: self._do_exec()
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/persistence.py", line 
995, in _do_exec

remote: update_stmt, params=self.query._params)
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/session.py", line 
991, in execute

remote: bind, close_with_result=True).execute(clause, params or {})
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 
729, in execute

remote: return meth(self, multiparams, params)
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/sql/elements.py", line 
322, in _execute_on_connection
remote: return connection._execute_clauseelement(self, multiparams, 
params)
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 
826, in _execute_clauseelement

remote: compiled_sql, distilled_params
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 
958, in _execute_context

remote: context)
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 
1159, in _handle_dbapi_exception

remote: exc_info
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/util/compat.py", line 
199, in raise_from_cause

remote: reraise(type(exception), exception, tb=exc_tb)
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 
951, in _execute_context

remote: context)
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/default.py", line 
436, in do_execute

remote: cursor.execute(statement, parameters)
remote: ProgrammingError: (ProgrammingError) permission denied for 
relation pull_requests
remote:  'UPDATE pull_requests SET merge_status=%(merge_status)s, 
last_updated=%(last_updated)s WHERE pull_requests.project_id = 
%(project_id_1)s AND pull_requests.status = %(status_1)s' 
{'project_id_1': 14960, 'last_updated': datetime.datetime(2019, 3, 6, 3, 
55, 50, 495151), 'merge_status': None, 'status_1': u'Open'}

remote: Sending to redis to send commit notification emails
remote: * Publishing information for 1 commits
remote:
remote: Create a pull-request for f30
remote: 
https://src.fedoraproject.org/rpms/perl-Pod-Tests/diff/master..f30

remote:
To ssh://pkgs.fedoraproject.org/rpms/perl-Pod-Tests
   723ef5b..e29a00d  f30 -> f30

What's going on here?

Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Donate 1 minute of your time to test upgrades from F29 to F30

[Ralf Corsepius]

On 2/28/19 6:55 PM, Kalev Lember wrote:

On 2/28/19 18:05, Miro Hrončok wrote:

On 28. 02. 19 16:55, Adam Williamson wrote:

More generally, the *flood* of Python 2 dep issues here is something I
was definitely concerned about with the Python 2 retirement policy
explicitly deciding not to say anything about obsoleting Python 2
subpackages :(


I wanted the py3 packages to obsolte the py2, but i was outvoted.


I completely agree with you. I think you should have gone to FESCo and
ask them to overrule the FPC in this case.


With all due respect, this would be an utter act of violence.

You can not obsolete packages which are still used by other packages nor 
can you obsolete packages which do not functionally replace other packages.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired (and everything will most likely burn)

[Ralf Corsepius]

On 2/12/19 8:22 AM, Mikolaj Izdebski wrote:

On Mon, Feb 11, 2019 at 11:19 PM Fabio Valentini  wrote:

I'm curious: What happens to modules when a package's master branch
gets retired?


Nothing. Modules will continue to exist and will continue to be
delivered to users.


Actually, I consider ant & Co's modularisation to be a non-helpful 
mistake, which should be reverted ASAP.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: perl: warning: Setting locale failed.

[Ralf Corsepius]

On 1/8/19 6:51 PM, Tim Landscheidt wrote:

Petr Šabata  wrote:


Adding
BuildRequires: glibc-all-langpacks
to all the *.specs obviously fixes this issue. However, I doubt this is
right, because I think these warnings originate from some rpm-internal
scripts and not from the packages.



I suspect you're running into the glibc-langpacks-all feature:
* 
https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot
*
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/VRIO4YQV2B2G2DUUYNRTVYQDFCMZSZGX/#B5SEICGIAETNXPRIE6VZT2VDKXRLJWSP



The locale shouldn't be set to en_US.utf8 is glibc-langpack-en is
not present.  Where does it come from?


Judging from $LANG=de_DE.UTF-8 in my mock, it gets copied
from the "host" environment.  And indeed,
mock/py/mockbuild/util.py has two instances of:

You seem to be right on the spot.

IMHO, mock should not propagate any "host" environment variables into 
its chroots. It should be using a fixed set of predefined settings, instead.



| env['LANG'] = os.environ.setdefault('LANG', 'C.UTF-8')

Adding:

| config_opts['environment']['LANG'] = 'C'


I guess, this should be 'C.UTF-8' instead of 'C'


to ~/.config/mock.cfg seems to solve that.


Unfortunately, this doesn't help with koji-builds:
c.f. e.g.
https://kojipkgs.fedoraproject.org//work/tasks/7946/31907946/build.log

Apparently, something sets LANG="en_US.UTF-8" in koji and mock bogusly 
propagates this into its chroots (Likely the servers are configured to 
use LANG='en_US.UTF-8')


Ralf
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

perl: warning: Setting locale failed.

[Ralf Corsepius]

Hi,

ATM, many (all?) of my perl packages raise several warnings of the kind 
below, when building them in mock:


...
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
...

Adding
BuildRequires: glibc-all-langpacks
to all the *.specs obviously fixes this issue. However, I doubt this is 
right, because I think these warnings originate from some rpm-internal 
scripts and not from the packages.


So, what is the official fix to this issue/build-system regression?

Ralf
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Can't set initial passwd

[Ralf Corsepius]

Hi,

I am facing a weird problem with creating a new user account:

Create a new user:
# adduser -m tester

Trying to change his passwd:
# passwd tester
Changing password for user tester.

At this point, passwd hangs and doesn't do anything.
I am not getting the "usual" passwd-prompt.

What's going on here?

Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: /etc/nssswitch.conf is supposed to be a symlink now?

[Ralf Corsepius]

On 11/28/18 4:37 PM, Robert Marcano wrote:

On 11/28/18 11:20 AM, Ralf Corsepius wrote:



# ls -l /etc/nsswitch.conf
lrwxrwxrwx. 1 root root 29 Nov 18 04:58 /etc/nsswitch.conf -> 
/etc/authselect/nsswitch.conf


My clean F29 installation had no such symbolic link, has to "authselect 
select --force ..." to force the creation of the link.


You are probably right.

I missed to mention, I currently am using authselect's "nis"-profile, 
because upgrading from f28 to f29 has screwed up my handcrafted 
nsswitch.conf, leaving me with semi-dysfunctional systems, which had 
caused me to experiment with authselect's "nis"-profile.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: /etc/nssswitch.conf is supposed to be a symlink now?

[Ralf Corsepius]

On 11/28/18 3:45 PM, Florian Weimer wrote:

* Richard W. M. Jones:


Trying to track down a bug in IPP printing
(https://bugzilla.redhat.com/show_bug.cgi?id=1653276).

We're down a rabbit hole where it seems that in Fedora 29
/etc/nssswitch.conf ought to be a symlink.  This machine has been
upgraded from F28 and this is not the case.  AFAIK I have never edited
the file.


/etc/nsswitch.conf is owned by glibc.  It is not a symbolic link as we
ship it.

If find out which packages replaces our configuration with a symbolic
link,


It's authselect.

# rpm -qV glibc
L  c /etc/nsswitch.conf


# ls -l /etc/nsswitch.conf
lrwxrwxrwx. 1 root root 29 Nov 18 04:58 /etc/nsswitch.conf -> 
/etc/authselect/nsswitch.conf


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: Move to an annual platform release starting at F30

[Ralf Corsepius]

On 11/27/18 9:16 AM, Igor Gnatenko wrote:

Because if we keep "no breaking updates in stable" policy, then Fedora
won't be "first anymore".


Users perceive your "first" as unstable and unreliable. There are plenty 
of examples of how e.g. FC30 was broken and still is.


One such example is you personal favorite: dnf.


You can do this only if rawhide will be more
popular between people.
Rawhide will never be end-user usable. I personally consider rawhide 
end-user usability to be a hoax.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Ralf Corsepius]

On 11/14/18 4:08 PM, Gerald Henriksen wrote:

On Wed, 14 Nov 2018 06:12:11 +0100, you wrote:


We, as a distro, just take a different approach.
To be bleeding edge requires to have releases often.


Such a bleeding edge distro that it took 4 years for Swift to arrive,
or still trying to get rid of Python 2.


Fedora has become "bleeding edge" in sense of being unstable, unreliable 
and containing immature, experimental features.



Regardless of what we think Fedora is or isn't, a look outside of
Fedora shows an overall Linux community that appears to be
increasingly ignoring Fedora.
Absolutely. Fedora once was a pretty solid end-user distro and 
fun-project for devs. Now it has become an unstable, experimental 
"bleeding edge" distro with a more and more balloning overhead.



Part of this discussion needs to be around the combined issues of
getting more maintainers and getting more users.

My feeling is part of the solution is to move to a yearly release
cycle.
This would be my proposal, also. I would simply extend the release 
cycles to 1 year and to return to the roots. I.e. make a distro, and 
drop "rings" "modules" and "spins".


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Buildroot broken in Rawhide

[Ralf Corsepius]

On 07/23/2018 08:01 AM, Jan Synacek wrote:

I got several FTBFS bug reports, the logs of which look like this:

+ make 'CFLAGS=-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
-std=gnu99' 'LDFLAGS=-Wl,-z,relro   -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld -lpthread -lrt -lm'
cc -MM -DDEPS_RUN -I. numad.c > .depend.X && mv .depend.X .depend
/bin/sh: cc: command not found

I consider that a broken buildroot.


You seem to be facing the nasty side-effects of the immaturity
https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot
was implemented and (not) tested.

Likely your cases are examples for what I wrote in

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2HG7KMKWU65IXRGUAU2PK2RCGDWWZWJW/

Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PEHVWHB4UVQ3COA6TQPUY65DFLPSGNFS/

Re: Auto-filing of FTBFS bugs gone wild

[Ralf Corsepius]

On 07/20/2018 03:58 PM, Igor Gnatenko wrote:

On Fri, Jul 20, 2018, 15:27 Kevin Kofler  wrote:


Igor Gnatenko wrote:

No one promised that I'm going to fix 100% of packages, I've fixed around
2k packages. What my regex couldn't catch -- please send me list of
packages, I will analyze them and try to fix as much as possible.


IMHO, it is unacceptable that you make a change breaking thousands of
packages and expect us to spend our time on fixing them or getting you to
fix them (and, as Hans pointed out, the latter likely takes MORE time
because of the communication overhead).



As I said previously (part which you quoted), I have fixed more than 2500
packages. I am pretty sure that the rest can be handled by maintainers.


Do you think this attitude of yours is acceptable?

IMHO, no.

You pushed out a change which obviously was insufficiently tested, 
though you told us you tested it, IIRC. Now you are forcing us to wipe 
up and clean up?


That said, the 2500 packages you are referring to might impress some 
readers, but it doesn't impress me, because it's obvious you missed huge 
classes of cases in your "testing".



IMHO, it is time to revert this Change.

ACK. This change was rushed out in an overly haste with insufficent testing.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TDDBQJDFJMV3NRN3CE5X7C2F4V3WPUIK/

Re: Auto-filing of FTBFS bugs gone wild

[Ralf Corsepius]

On 07/21/2018 11:02 AM, Igor Gnatenko wrote:

On Sat, Jul 21, 2018 at 10:28 AM Julian Sikorski  wrote:



This means that  build failed on checking for gcc. There are some packages
where it checks for both gcc and g++ and then fails, but there are packages
where it fails after first.

Unfortunately I can't fix this automagically.


Right. The approach you seem to have applied, is unsuitable.

There also are cases which assume a "cc" to be unconditionally present.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2HG7KMKWU65IXRGUAU2PK2RCGDWWZWJW/

Re: FESCo Elections - May 2018 : Results announcement

[Ralf Corsepius]

On 06/14/2018 03:02 PM, Michael Cronenworth wrote:

On 06/14/2018 03:42 AM, Pierre-Yves Chibon wrote:
I know we never manage to motivate many people to vote, but 86 votes 
is really

low, even for us:(


Yes, I was checking out the voter count on other pollings and the 
turnout is around 100. Disappointing. :(


Lack of awareness or advertising?


Neither - IMO, lack of "democratic culture".


I voted.
I did not, because I could not find any suitable candidates and did not 
see any reason to vote.


Ralf


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/42E7OXUMHBZBIURKM7UIG2KZFPC2KCMS/

Re: F29 System Wide Change: i686 Is For x86-64

[Ralf Corsepius]

On 06/04/2018 11:28 AM, Florian Weimer wrote:

On 06/04/2018 10:50 AM, Guido Aulisi wrote:


It should, because -march=x86-64 implies just SSE2 and FXSR, and Xeon MP 
supports both.  But the intent is what the subject says: i686 binaries 
are for running legacy software on x86-64 systems, and nothing more.


I do not agree with this sentiment all, as well as I can't deny finding 
your wording bewildering, because I think you actually are trying to say:


- You (Florian) want to abandon the i686 architecture.
- You (RH) want to play down the fact Fedora 28 is FUBARed on the PIII 
and instead of fixing the issues you want to kill it.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JBZVYP5F7XLNS4Q3KO5JNEUHOC5S3SIL/

Re: What services / tools still require NIS domain?

[Ralf Corsepius]

On 05/16/2018 05:02 PM, David Kaspar [Dee'Kej] wrote:

Hello people,

I would like to know if you know about any service / tool / application 
that still relies on NIS domain to be set in Fedora?


So far, I know only about SSSD/FreeIPA relying on it. Does anybody know 
anything else? All replies are welcome. :)


Existing user installations require it - and likely will continue to 
require it for at least another decade.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Ralf Corsepius]

On 03/23/2018 12:23 PM, Petr Viktorin wrote:
tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need 
to start dropping python2 packages now.

Bummer - I am speechless.

Python 2.7 will reach end of upstream support on 1st of January, 2020, 
after almost 10 years (!) of volunteer maintenance.


Fedora still has more than 3000 packages depending on python2 – many 
more than we can support without upstream help.

Correct.

Face it, your plan is naive and has failed even before it begun.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: josm orphaned

[Ralf Corsepius]

On 03/22/2018 11:32 AM, Matěj Cepl wrote:

On 2018-03-22, 06:51 GMT, Till Maas wrote:

I orphaned josm (https://src.fedoraproject.org/rpms/josm), the
java openstreetmap editor on request by the original
maintainer. Please adopt it. It needs to be updated regularly
to follow the current openstreetmap guidelines, currently it
is outdated (also in EPEL).


My experience with JOSM is that this is probably one of the
programs which are better not to be packaged (other example: vim
plugins). Java Web Start on
https://josm.openstreetmap.de/download/josm.jnlp works just fine
and I don't see the reason why we should bother with packaging
it ourselves.
The reasons for packaging something up as rpm is security and system 
integrety/consistency, i.e. not to endanger installations from the 
(windowish) mindset of "unpackaged" third party stuff.


What you say, basically means you are questioning and deny the 
usefulness of packaging as a whole. The key feature which has made Linux 
distros great and superior to Windows.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken dependencies: FreeSOLID

[Ralf Corsepius]

On 03/03/2018 12:19 PM, Christian Dersch wrote:

Hi,

try qhull-devel instead of pkgconfig(qhull), afaik there was a change in
qhull package some days ago.


No. The change you are referring to happened in April 2016!

Ralf (Fedora qhull packager)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Ralf Corsepius]

On 02/28/2018 05:43 PM, Adam Williamson wrote:

On Wed, 2018-02-28 at 12:14 +0100, Ralf Corsepius wrote:

On 02/27/2018 07:27 PM, Richard Shaw wrote:

On Tue, Feb 27, 2018 at 12:16 PM, Adam Williamson
<adamw...@fedoraproject.org <mailto:adamw...@fedoraproject.org>> wrote:


 Once again, folks, *please* announce your soname bumps, and co-ordinate
 rebuilds. (In fact it looks like Zdenek is the maintainer of both
 packages and could have rebuilt cups-filters, but just forgot to).


Is it time to update the packaging guidelines to enforce setting a
"%global sover " and using it in %files?

If nothing else it should at least be documented as a best practice.


I would be very opposed to this.

Even though some folks want rawhide to appear a release, rawhide is not
a release. So SONAME breakages are expected to happen in rawhide and
maintainers supposed to be reacted upon.


This is not true and I have *specifically* pointed you at the policy
page which says it is not true, more than once.


And I have to reiterate my mantra: This plan is a non-realistic 
illusion. It simply does not work and will not work.



https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master

For updates to rawhide packages, Maintainers SHOULD:

 Try not to push a clearly broken build (breaks the default
buildroot package set, etc)


Note the "SHOULD" - This is the reflection of what I said above.

Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rawhide: Can't locate ExtUtils/CBuilder.pm

[Ralf Corsepius]

On 03/01/2018 11:33 AM, Paul Howarth wrote:

On Thu, 1 Mar 2018 11:17:18 +0100
Petr Pisar <ppi...@redhat.com> wrote:


On Thu, Mar 01, 2018 at 09:38:08AM +0100, Ralf Corsepius wrote:

Hi,

perl-Plack fails to build in rawhide with
this error[1]


Sorry, of course this was perl-Server-Starter, not perl-Plack.


...
+ /usr/bin/perl Build.PL --installdirs=vendor
Can't locate ExtUtils/CBuilder.pm in @INC (you may need to install
the ExtUtils::CBuilder module) (@INC contains:
/builddir/build/BUILD/Server-Starter-0.34/_build/lib /usr/local/lib64/perl5
/usr/local/share/perl5 /usr/lib64/perl5/vendor_perl
/usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at
/usr/share/perl5/vendor_perl/Module/Build/Base.pm line 5295.
...

f26, f27 and f28 build fine.

What is going on here? perl-Plack does not carry any direct
dependency on ExtUtils::CBuilder, so my guess would be a dependency
is missing somewhere else.
   

<https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/MWK6MLOWOIJ2UVMRILR3FAZZRE3X6OCM/>
is happennning due to GCC removal from F29 build root.

If you have a package with XS modules and use Module::Build, you need
to build-require ExtUtils::CBuilder.

In case of Server-Starter, there seems to be a bug in
Module::Build::Base. It invokes auto_require() that for some reason
has $self->c_source set to [], and thus it decides it needs a
compiler and hence ExtUtils::CBuilder.

I think this condition in auto_require() should be corrected:

 $self->needs_compiler( keys %$xs_files || defined
$self->c_source );

and also the reason why $self->c_source is [] instead of undef should
be investigated.


That'll be because Server-Starter's Build.PL has

  "c_source => [qw()],"

And that's generated by Minilla, so all non-XS Minilla-based dists are
likely to be affected.
I am not familiar with Minilla, but you seem to have a point. At least, 
removing this line from Build.PL lets building perl-Server-Starter 
succeed for rawhide:

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

Ralf
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

rawhide: Can't locate ExtUtils/CBuilder.pm

[Ralf Corsepius]

Hi,

perl-Plack fails to build in rawhide with
this error[1]

...
+ /usr/bin/perl Build.PL --installdirs=vendor
Can't locate ExtUtils/CBuilder.pm in @INC (you may need to install the 
ExtUtils::CBuilder module) (@INC contains: 
/builddir/build/BUILD/Server-Starter-0.34/_build/lib 
/usr/local/lib64/perl5 /usr/local/share/perl5 
/usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl 
/usr/lib64/perl5 /usr/share/perl5 .) at 
/usr/share/perl5/vendor_perl/Module/Build/Base.pm line 5295.

...

f26, f27 and f28 build fine.

What is going on here? perl-Plack does not carry any direct dependency 
on ExtUtils::CBuilder, so my guess would be a dependency is missing 
somewhere else.



Ralf



[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1052034
https://kojipkgs.fedoraproject.org//work/tasks/4038/25384038/build.log
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Ralf Corsepius]

On 02/28/2018 11:28 AM, Rafal Luzynski wrote:

28.02.2018 09:33 Nicolas Mailhot  wrote:


Le mercredi 28 février 2018 à 00:11 -0500, Orcan Ogetbil a écrit :


Shouldn't we consider having -devel packages Require gcc or gcc-c++?
What good is a header package without a compiler anyway?
This would also (indirectly) pull in the compiler and fix most of
these failed builds.



gcc is not the only compiler that reads header files


Also, do the header files actually *require* gcc to be present?


No. C headers never require *GCC*. Packages wanting to use them need an 
arbitrary C compiler.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Ralf Corsepius]

On 02/28/2018 12:21 PM, Vít Ondruch wrote:



Dne 28.2.2018 v 12:14 Ralf Corsepius napsal(a):

On 02/27/2018 07:27 PM, Richard Shaw wrote:

On Tue, Feb 27, 2018 at 12:16 PM, Adam Williamson
<adamw...@fedoraproject.org <mailto:adamw...@fedoraproject.org>> wrote:


     Once again, folks, *please* announce your soname bumps, and
co-ordinate
     rebuilds. (In fact it looks like Zdenek is the maintainer of both
     packages and could have rebuilt cups-filters, but just forgot to).


Is it time to update the packaging guidelines to enforce setting a
"%global sover " and using it in %files?

If nothing else it should at least be documented as a best practice.


I would be very opposed to this.

Even though some folks want rawhide to appear a release, rawhide is
not a release. So SONAME breakages are expected to happen in rawhide
and maintainers supposed to be reacted upon.


Yes, if they notice!
They - rsp. the maintainers of dependent packages - (usually) will 
notice very soon, because they'll receive an email notifying them about 
the breakage.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Ralf Corsepius]

On 02/28/2018 02:41 AM, Richard Shaw wrote:
On Tue, Feb 27, 2018 at 6:47 PM, Kevin Kofler > wrote:


Richard Shaw wrote:
> Is it time to update the packaging guidelines to enforce setting a
> "%global sover " and using it in %files?
>
> If nothing else it should at least be documented as a best practice.

Not yet another bureaucratic guideline making it harder to maintain
packages!

Hardcoded soversions in specfiles are a pain!


Unannounced soname bumps are a pain :)


SONAME bumps are "daily business" in rawhide and should be reacted upon 
in timely manners.


Whether they are announced or not actually, actually doesn't make much 
difference.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Ralf Corsepius]

On 02/27/2018 07:27 PM, Richard Shaw wrote:
On Tue, Feb 27, 2018 at 12:16 PM, Adam Williamson 
> wrote:



Once again, folks, *please* announce your soname bumps, and co-ordinate
rebuilds. (In fact it looks like Zdenek is the maintainer of both
packages and could have rebuilt cups-filters, but just forgot to).


Is it time to update the packaging guidelines to enforce setting a 
"%global sover " and using it in %files?


If nothing else it should at least be documented as a best practice.


I would be very opposed to this.

Even though some folks want rawhide to appear a release, rawhide is not 
a release. So SONAME breakages are expected to happen in rawhide and 
maintainers supposed to be reacted upon.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Ralf Corsepius]

On 02/19/2018 11:27 AM, Igor Gnatenko wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2018-02-19 at 09:02 +, Tom Hughes wrote:

On 19/02/18 08:30, Igor Gnatenko wrote:


On Mon, 2018-02-19 at 09:12 +0100, Guido Aulisi wrote:


amsynth has been fixed in all supported branches.


It should have both gcc and gcc-c++.


I don't think you ever need both - the guidelines say "gcc, gcc-c++ or
clang" and gcc-c++ has to require gcc anyway.


If your code needs both, better to be explicit and write both.


Wrong. g++ requires gcc for technical reasons.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: to batch or not to batch?

[Ralf Corsepius]

On 02/17/2018 11:15 PM, Zbigniew Jędrzejewski-Szmek wrote:

Bodhi currently provides "batched updates" [1] which lump updates of
packages that are not marked urgent into a single batch, released once
per week. This means that after an update has graduated from testing,
it may be delayed up to a week before it becomes available to users.

Batching is now the default, but maintainers can push theirs updates
to stable, overriding this default, and make the update available the
next day.

Batching is liked by some maintainers, but hated by others


As a maintainer, I hate them, because the primary effect "batched" has, 
is to furtherly increase update delay from 1 week up to 2 weeks or more 
(like in recent times).


That said, I consider "batched" to be superfluous bureaucracy.

Ralf


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Ralf Corsepius]

IMO, bikesheding and stylishness with any actual usefulness.

If you really want to enforce this, make it a feature request for f30 
and have FESCO vote on it.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RANT: Packaging is changing too fast and is not well documented

[Ralf Corsepius]

On 02/11/2018 08:40 AM, Kevin Kofler wrote:

Richard Shaw wrote:

$ fedpkg request-branch 
Could not execute request_branch: The "token" value must be set under the
"fedpkg.pagure" section in your "fedpkg" user configuration


WTF?! So, instead of going to a web interface and making the change (old,
now discontinued, pkgdb), we now have to:
1. go to the web interface
2. read the token there
3. locate a config file
4. edit the config file with a text editor
5. manually insert the token from step 2 there
6. use a CLI to make the change
and that is an improvement, HOW?


Been there, struggled with this and feeling really p***ed by it ;)

This pagureio stuff is a massive usability and a functional regression.

Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Mass-macro-escape in %changelog

[Ralf Corsepius]

On 02/09/2018 09:18 AM, Igor Gnatenko wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I've went and fixed 493 packages (listed below). If it broke something, please
let me know. I checked diff briefly and don't think that I broke anything…


Did you ask FESCO? If not you, have abused your Fedora privileges, 
IMNSHO to play down a long unfixed *bug* in rpm.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: binutils 2.30

[Ralf Corsepius]

On 02/06/2018 09:05 AM, Florian Weimer wrote:

On 02/06/2018 09:02 AM, Richard W.M. Jones wrote:

On Tue, Feb 06, 2018 at 08:49:53AM +0100, Florian Weimer wrote:

On 02/06/2018 08:38 AM, Richard W.M. Jones wrote:

binutils 2.30 has been out for about a week.  Will we get it in
Rawhide soon?  It has some modest enhancements related to the RISC-V
architecture.


No, not before Fedora 28 branches.


Is there a particular issue with 2.30, eg. not stable enough for
a stable release of Fedora?


There isn't any specific issue.

Toolchain updates always carry some risk, and we already have enough 
moving parts due to GCC 8 and other low-level changes that landed in 
rawhide recently.


Hmm, IMO, GCC + binutils updates are an ideal candidate to be pushed 
simultaneously and an ideal opportunity for a mass rebuild.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GCC broken in rawhide?

[Ralf Corsepius]

On 01/30/2018 11:16 AM, Jakub Jelinek wrote:

On Tue, Jan 30, 2018 at 11:11:02AM +0100, Ralf Corsepius wrote:

On 01/30/2018 10:00 AM, Florian Weimer wrote:

On 01/30/2018 09:54 AM, Ralf Corsepius wrote:

annobin.spec now uses:

    %undefine _annotated_build

so at least the circular dependency is no longer there.  You still
have to remember to rebuild it when a new version of GCC comes out
however.


... which apparently has just happened.


Yes, Fedora 28 will use GCC 8.


Consequences are affecting all released versions of Fedora, because
it's impossible to apply bugfix updates to Fedora < rawhide, due to
the GCC-chaos in rawhide.


Please provide more context when reporting issues, otherwise we have a
hard time helping you.

Seeming hundreds of packages currently carry broken deps, dnf is
malfunctioning etc.


That is what we have the mass rebuild scheduled for (AFAIK this week).

How comes, I am observing these breakages right now, in the official 
rawhide repos?


They are preventing me to bugfix-update released fedoras, because the 
corresponding rawhide build are failing.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GCC broken in rawhide?

[Ralf Corsepius]

On 01/30/2018 10:00 AM, Florian Weimer wrote:

On 01/30/2018 09:54 AM, Ralf Corsepius wrote:

annobin.spec now uses:

   %undefine _annotated_build

so at least the circular dependency is no longer there.  You still
have to remember to rebuild it when a new version of GCC comes out
however.


... which apparently has just happened.


Yes, Fedora 28 will use GCC 8.

Consequences are affecting all released versions of Fedora, because 
it's impossible to apply bugfix updates to Fedora < rawhide, due to 
the GCC-chaos in rawhide.


Please provide more context when reporting issues, otherwise we have a 
hard time helping you.
Seeming hundreds of packages currently carry broken deps, dnf is 
malfunctioning etc.


Eg.

Error:
 Problem 1: cannot install both libgfortran-8.0.1-0.6.fc28.x86_64 and 
libgfortran-7.3.1-1.fc28.x86_64
  - package gcc-gfortran-8.0.1-0.6.fc28.x86_64 requires 
libgfortran.so.5()(64bit), but none of the providers can be installed
  - package blacs-mpich-devel-2.0.2-23.fc27.x86_64 requires 
libgfortran.so.4()(64bit), but none of the providers can be installed

  - cannot install the best candidate for the job
 Problem 2: gcc-gfortran-7.3.1-1.fc28.i686 has inferior architecture
  - package mpich-devel-3.2.1-2.fc28.x86_64 requires gcc-gfortran, but 
none of the providers can be installed
  - package gcc-gfortran-7.3.1-1.fc28.x86_64 requires gcc = 
7.3.1-1.fc28, but none of the providers can be installed
  - package gcc-7.3.1-1.fc28.i686 requires cpp = 7.3.1-1.fc28, but none 
of the providers can be installed
  - package gcc-7.3.1-1.fc28.x86_64 requires cpp = 7.3.1-1.fc28, but 
none of the providers can be installed
  - package libtool-2.4.6-21.fc28.x86_64 requires gcc(major) = 8, but 
none of the providers can be installed
  - package gcc-8.0.1-0.6.fc28.x86_64 requires cpp = 8.0.1-0.6.fc28, 
but none of the providers can be installed
  - cannot install both cpp-7.3.1-1.fc28.x86_64 and 
cpp-8.0.1-0.6.fc28.x86_64
  - cannot install both cpp-8.0.1-0.6.fc28.x86_64 and 
cpp-7.3.1-1.fc28.x86_64

  - cannot install the best candidate for the job
  - package gcc-gfortran-8.0.1-0.6.fc28.x86_64 requires 
libgfortran.so.5()(64bit), but none of the providers can be installed
  - cannot install both libgfortran-8.0.1-0.6.fc28.x86_64 and 
libgfortran-7.3.1-1.fc28.x86_64
  - package blacs-openmpi-devel-2.0.2-23.fc27.x86_64 requires 
libgfortran.so.4()(64bit), but none of the providers can be installed
 Problem 3: package scalapack-openmpi-devel-2.0.2-23.fc27.x86_64 
requires libscalapack.so.2()(64bit)(openmpi-x86_64), but none of the 
providers can be installed
  - package scalapack-openmpi-2.0.2-23.fc27.x86_64 requires 
libgfortran.so.4()(64bit), but none of the providers can be installed
  - cannot install both libgfortran-8.0.1-0.6.fc28.x86_64 and 
libgfortran-7.3.1-1.fc28.x86_64
  - package gcc-gfortran-8.0.1-0.6.fc28.x86_64 requires 
libgfortran.so.5()(64bit), but none of the providers can be installed
  - package openmpi-devel-2.1.1-5.fc28.x86_64 requires gcc-gfortran, 
but none of the providers can be installed
  - package gcc-gfortran-7.3.1-1.fc28.i686 requires gcc = 7.3.1-1.fc28, 
but none of the providers can be installed
  - package gcc-7.3.1-1.fc28.i686 requires cpp = 7.3.1-1.fc28, but none 
of the providers can be installed
  - package gcc-7.3.1-1.fc28.x86_64 requires cpp = 7.3.1-1.fc28, but 
none of the providers can be installed
  - package gcc-gfortran-7.3.1-1.fc28.x86_64 requires gcc = 
7.3.1-1.fc28, but none of the providers can be installed
  - package gcc-c++-8.0.1-0.6.fc28.x86_64 requires gcc = 
8.0.1-0.6.fc28, but none of the providers can be installed
  - package gcc-8.0.1-0.6.fc28.x86_64 requires cpp = 8.0.1-0.6.fc28, 
but none of the providers can be installed
  - cannot install both cpp-7.3.1-1.fc28.x86_64 and 
cpp-8.0.1-0.6.fc28.x86_64
  - cannot install both cpp-8.0.1-0.6.fc28.x86_64 and 
cpp-7.3.1-1.fc28.x86_64

  - cannot install the best candidate for the job
(try to add '--allowerasing' to command line to replace conflicting 
packages or '--skip-broken' to skip uninstallable packages)

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GCC broken in rawhide?

[Ralf Corsepius]

On 01/29/2018 04:45 PM, Richard W.M. Jones wrote:

On Mon, Jan 29, 2018 at 03:55:53PM +0100, Florian Weimer wrote:

On 01/29/2018 03:43 PM, Kevin Kofler wrote:

Is https://fedoraproject.org/wiki/Changes/Annobin (no user-visible
improvements, only yet another global distrowide size increase) really worth
the circular dependency nightmare (rebuilding annobin requires GCC, but GCC
is configured to not work without annobin) or is it time to drop the feature
and enact the contingency plan?


Yes, it is required for meeting our security hardening objectives.

Ideally, annobin would be built from the GCC source package, but
since GCC needs more than twelve hours to build on armhfp, that is
not really an option while we are still adjusting the information
that annobin collects.


annobin.spec now uses:

   %undefine _annotated_build

so at least the circular dependency is no longer there.  You still
have to remember to rebuild it when a new version of GCC comes out
however.


... which apparently has just happened.

Consequences are affecting all released versions of Fedora, because it's 
impossible to apply bugfix updates to Fedora < rawhide, due to the 
GCC-chaos in rawhide.


Ralf

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GCC broken in rawhide?

[Ralf Corsepius]

On 01/26/2018 08:13 AM, Philip Kovacs wrote:

I'm getting:

configure: error: C compiler cannot create executables


This is exactly what I get.

Having a look into the corresponing config.log gives the error related 
annobin, I was referring to.


Ralf

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GCC broken in rawhide?

[Ralf Corsepius]

On 01/26/2018 08:05 AM, Samuel Sieb wrote:

On 01/25/2018 10:50 PM, Ralf Corsepius wrote:

Digging into details led me to this error:
...
cc1: error: fail to initialize plugin 
/usr/lib/gcc/x86_64-redhat-linux/7/plugin/annobin.so
annobin: conftest.c: Error: plugin built for compiler version (7.3.1) 
but run with compiler version (7.2.1)

...

AFAIS, GCC in rawhide was updated to GCC-7.3.1, but apparently annobin 
wasn't rebuilt, resulting into rawhide now carrying an inconsistent 
GCC-toolchain.


Are you sure you're reading that correctly?

Yes, I am.

# rpm -qa gcc* anno*
annobin-3.1-1.fc28.x86_64
gcc-c++-7.3.1-1.fc28.x86_64
gcc-gfortran-7.3.1-1.fc28.x86_64
gcc-7.3.1-1.fc28.x86_64

# grep annobin: config.log
annobin: conftest.c: Error: plugin built for compiler version (7.3.1) 
but run with compiler version (7.2.1)


  That message tells me that 
annobin was rebuilt for 7.3.1, but the gcc in the build environment is 
still 7.2.1.


cf. above.

Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

GCC broken in rawhide?

[Ralf Corsepius]

Hi,

ATM all rawhide builds are failing for me, because autoconf's tests for 
CC are failing.


Digging into details led me to this error:
...
cc1: error: fail to initialize plugin 
/usr/lib/gcc/x86_64-redhat-linux/7/plugin/annobin.so
annobin: conftest.c: Error: plugin built for compiler version (7.3.1) 
but run with compiler version (7.2.1)

...

AFAIS, GCC in rawhide was updated to GCC-7.3.1, but apparently annobin 
wasn't rebuilt, resulting into rawhide now carrying an inconsistent 
GCC-toolchain.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Ralf Corsepius]

On 12/18/2017 09:42 PM, Gerald B. Cox wrote:

Mozilla has already admitted they made a mistake and removed Looking 
Glass from the
Fx Studies.  I believe they understand the situation quite well.  It's 
not helpful to beat

a dead horse.


Do you think it's a dead horse? I don't.

Actually, I think Mozilla's management finally has unhidden their real 
face. Time for changes at Mozilla and for personal changes in their 
management - Period.


Ralf


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Which Fedora/EPEL is targeted by packaging guidelines?

[Ralf Corsepius]

On 12/02/2017 02:35 AM, Kevin Kofler wrote:

Vít Ondruch wrote:

This is big and old-school hammer. If you did "git cherry-pick" instead,
you could get most of the changes you did in master without the
branches. Also, merging means that you get into older (or EPEL) branches
stuff like changelogs from mass rebuild, which should not be there IMO.


Cherry-picking and diverging changelogs mean one keeps having to manually
fix conflicts. With the one specfile with conditionals, I only have to do a
fast-forward merge and build, which is a lot more convenient.


Until you get confused by conditionals' magic, bitten by unexpected 
behavior, bugs or compatibility problems in the different verions of rpm 
or rpm-macros.


That said, I prefer avoiding conditionals and prefer clean, 
"one-spec-per release" rpm.specs.



But keep in mind that I don't do EPEL, so my conditionals are few and far
between, and I will remove conditionals for EOL Fedora releases.


So do I. IMHO, mixing epel specs with fedoras specs is a lost battle. 
It's error-prone at best and hardly possible in "more than trivial" cases.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Package naming question

[Ralf Corsepius]

On 12/04/2017 10:33 AM, Giovanni wrote:

On Mon, Dec 04, 2017 at 10:20:13AM +0100, Igor Gnatenko wrote:

* rust-parallel
* parallel-rust
* parallel-rs


I vote parallel-rust. It's very clear where it comes from.

This choice is probably an interesting one: it would mark some sort of best
practice for the "replacement of Y in X": x-y.


We already have such practices in place.


Do you think we will see a lot of rust replacements for standard
utilities in the future?


Before such effort can take effect, replacing a well established package 
with another one will have to prove its viablity and sustainabilty.


ATM, to me personally, replacing packages with rust package qualifies as 
non-sense, probably based on personal preferences and religion.



Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why is Fx 57 in Updates Testing?

[Ralf Corsepius]

On 10/13/2017 07:11 PM, nicolas.mail...@laposte.net wrote:


Which all means our release planning is too focused on Gnome and not enough 
thought is put into the roadmap of major non-Gnome desktop apps such as Firefox 
or Libreoffice. I'd argue that this kind of Firefox change is way more 
impacting for our users than the latest gnome settings redesign.


Definitely. Fedora in danger to become (or already is) Gnome's and 
Firefox's "puppet".



This needs to change. Fedora should be in service of its users not 
arbitrary upstreams or their package maintainers.



Too late to switch to ESR now, the best outcome would be to make FF57 a major 
feature of F27 (since it will be), ship it (even as prerelease) from day 1 and 
pretend that was always what our release engineering intended to do.
IMHO, it would be reasonable and common sense to either postpone F27 
until FF57 has become stable or to revert the firefox change.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to chainbuild in a build override?

[Ralf Corsepius]

On 09/22/2017 01:07 PM, Petr Pisar wrote:

On 2017-09-22, Ralf Corsepius <rc040...@freenet.de> wrote:

How to build a sub tree of packages in fc27, when the root of this tree
changed SONAME?


In rawhide, if you want a longer time isolation, you ask relengs for
a sige tag, you do all builds there without affecting others and then
you ask relengs to merge the builds back to rawhide. Of course this has
same races and one needs to reaply all rawhide changes into the side tag
otherwise a mismatches can happen after the merge.


This certainly makes sense for larger number of packages.


I don't know if this procedure is acceptable for f27.

I would not want to do this.

However, I meanwhile seem to have resolved my problem.

The trick was to use several build overrides, one for each "tree level" 
of the package tree being involved.


In this case, the tree was 2 levels deep, comprising 6 packages, with a 
dependency graph like this:


A1 -> B1
   -> B2
   -> B3 -> C1
 -> C2

One build override on "A1" and one build override on "B3".

As Tom said, painful, but doable due to the fairly small size of 
packages being involved ;)



In my opinion the whole idea of chaning a SONAME in f27 is wrong.


Nah, it's just a more or less a last minute update (Remember F27 is 
still in testing!), which seemed useful because A1's upstream released 
the first major bugfix update for ca. 2 years. "Just in time"/"last 
minute" to make it into Fedora.


In former Fedora times, I would have updated A1 by brute force and then 
gradually have let the other packages catch up.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to chainbuild in a build override?

[Ralf Corsepius]

On 09/22/2017 09:32 AM, Tom Hughes wrote:

On 22/09/17 08:03, Ralf Corsepius wrote:


I am trying to build a chain of packages in a build override?

I.e. a series of packages: A->B->C

I set up a build override for A, and B built successfully. Now, I 
would have expect building C to pickup B from the A-override.


You seem to be confused about what an override is ;-)


Quite likely, I rarely used them and have always found the tooling to be 
hard to use ;)


It's not a separate environment just for you - if it was then you would 
have to say which override you wanted to use when building.

Correct. That's a issue I never understood about build overrides.

Rather it just adds that package to the global build environment that 
everybody sees.


But in order for B to appear in the build environment for C to use you 
would need to add an override for B and then wait for it to appear 
there.


That's what I had presumed. But this implies me to deliberately break deps.

I believe chainbuild knows how to do the waiting but not how to 
request an override.


So in summary chainbuild is I believe only useful in rawhide, and in 
branched before bodhi is enabled.
That's clear. I was using the term chain-building in the meaning of 
building a hierarchy of packages.


So let me rephrase my question:

How to build a sub tree of packages in fc27, when the root of this tree 
changed SONAME?



Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

How to chainbuild in a build override?

[Ralf Corsepius]

Hi,

I am trying to build a chain of packages in a build override?

I.e. a series of packages: A->B->C

I set up a build override for A, and B built successfully. Now, I would 
have expect building C to pickup B from the A-override.


This does not seem to apply. C fails to build, apparently because 
building doesn't pickup "B" from A's build override.


Is this a timing issue (Do I need to wait)? Do I have to setup another 
build-override for B?


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

SONAME bump: Update OpenSceneGraph to 3.4.1

[Ralf Corsepius]

Hi,

I am going to update OpenSceneGraph from 3.4.0 to 3.4.1 on rawhide (for 
now).


This will be accompanied with SONAME bumps of various shared libs 
supplied by OpenSceneGraph and thus will require rebuilds of several 
packages depending on these libs. I intend to take care of these and to 
rebuild them.


Unless this update encounters major problems, I am considering to 
subsequently also update OpenSceneGraph on fc27.


Ralf

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rawhide packages not getting pushed?

[Ralf Corsepius]

On 09/20/2017 10:16 PM, Peter Robinson wrote:


I just ran:
koji untag-pkg f28-pending  k3d-0.8.0.6-9.fc28; koji tag-pkg
f28-pending  k3d-0.8.0.6-9.fc28

>> and you'll see now it's tagged into f28

Thanks, this seems to have done it.

Though *-9.fc28 doesn't seem to have landed in rawhide, I see it being 
pulled in through rawhide/latest in mock ;)


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

rawhide packages not getting pushed?

[Ralf Corsepius]

Hi,

For ca. 3 weeks (or more) buildsys nags me with warning mails on k3d:
...
k3d has broken dependencies in the rawhide tree:
On x86_64:
k3d-0.8.0.6-8.fc28.x86_64 requires libMagick++-7.Q16HDRI.so.3()(64bit)
...

Due to these, I bumped k3d's NEVR to k3d-0.8.0.6-9 and built it for 
rawhide on 2017-09-11:

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

However, apparently this package never was pushed into rawhide and the 
nag-mails continued.


Is going on? What am I supposed to do?

Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Urgent attention required; ImageMagick update breakage

[Ralf Corsepius]

On 09/02/2017 12:14 AM, Michael Cronenworth wrote:

On 09/01/2017 01:13 PM, Adam Williamson wrote:

FESCo decided at today's meeting that 7 should not go to F27 (unless it
can be made parallel installable and not used by anything release-
blocking by default), and to go into F28 there must be a system-wide
Change:


The libs are definitely parallel installable.
This could makessome sense, if these are really used and if 
vulnerabilities can be reacted upon/fixed in the old versions.


If the latter doesn't apply, it would be better to those remove package 
which requires these old libs from the distro.


The binaries share a name 
so we could use alternatives and default to version 6.
IMO, alternatives don't make any sense, here, because alternatives 
requires binaries to be call backward compatible.


Versioned binaries could make some sense if the these binaries are not 
call-compatible.


Ralf


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Ralf Corsepius]

On 08/28/2017 04:35 PM, Florian Weimer wrote:


https://bugzilla.redhat.com/show_bug.cgi?id=1482798
(Bug 1482798 - Illegal instruction in SHA1_Update() when used by chronyd)


That's definitely a bug for F27.

nss-softok is broken in similar ways on fedora-26-i686

Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Ralf Corsepius]

On 07/12/2017 03:44 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Wed, Jul 12, 2017 at 08:44:02AM -0400, Matthew Miller wrote:

On Wed, Jul 12, 2017 at 01:20:58PM +0200, Ralf Corsepius wrote:

The fact that i686 kernels continue to work in general is basically luck.

You probably will deny this, but in practice it has been so for many
years, because the i686 has dropped out of RHAT's business interest.


I don't think this is unreasonable. It is easy for us to support
architectures that a company is paying people to support. It is hard
for us to support architectures that are not getting that that kind of
support. As noted in this thread, this isn't just Red Hat -- it is true
of upstream i686 as well. No one is really interested in this. I
guarantee you that if some non-Red Hat person showed up and said "Hey,
I'm here to work on i686 N hours per week", we would say "awesome", not
"Red Hat doesn't care".


Would it be possible to make this a Prioritized Bug?
It seems to be a classic case of "affects a lot of people, nobody seems
to want to take interest".


Agreed, however I feel it's a classic case of "affects a lot of people, 
but RHAT doesn't allow anybody to take action".


That said, I do own and use several i686, but have learnt it's fruitless 
to report bugs, because RHAT ignores them and because RHAT does not 
allow the community to get involved.


Ralf

PS: Yes, your impression is right. I feel very grumpy about all this.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Golang packages snapshot versionning

[Ralf Corsepius]

On 08/19/2017 01:36 PM, Robert-André Mauchin wrote:

Hello,


When packaging Golang librairies we often use development snapshots instead of
releases. In such case there is two conflicting guidelines regarding
versionning:

  - the "main" Guidelines that says the version should be 
MMDD
  Cf: https://fedoraproject.org/wiki/Packaging:Versioning#Snapshots


This is the official set of rules.


  - the Go Draft Guidelines that says the vesrion should just be 
  without any date.
  Cf https://fedoraproject.org/wiki/PackagingDrafts/Go#Versions


And this one is "draft", i.e. it's more or less meaningless.

As things appear to me, it's likely outdated.


Which one supersedes the other? the main guideline or the Go draft?

The former.

Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Elections to FESCo & FAmSCo - Voting period is in progress

[Ralf Corsepius]

On 08/18/2017 08:23 AM, Jan Kurik wrote:

On Thu, Aug 17, 2017 at 3:17 PM, Benson Muite
 wrote:

Is it possible for the people who are running and have not answered
interview questions for the blog or have an informative profile to do so?
Voting is not limited to relevant group, so some information on election
options is helpful. One can of course do a web search, email list posting
and commit history summary, but this may not always give exactly relevant
information.


This is up to the candidates. Candidates can use i.e. social networks
to present them self. Typically every candidate has a User page which
is linked from the voting machine. And again, it is up to the
candidate what information he would like to publish there. We are not
forcing candidates to publish any information, it is their free will.


IMHO, this needs to change to make the elections meaningful, again.

Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Ralf Corsepius]

On 08/16/2017 05:50 PM, Stephen John Smoogen wrote:



On 16 August 2017 at 03:38, Till Maas > wrote:


Am 15. August 2017 15:47:49 MESZ schrieb Jan Kurik
>:

>I am personally not convinced this will help as the set of questions
>in Questionnaire is almost the same for the last several elections, as
>we copy them from one elections to another. So, candidates can prepare
>them self in advance even now. However, I do not see a reason why we
>can not start collection of questions for the Questionnaire one week
>earlier. I can modify the schedule for F27 release cycle, if agreed.

Would it be possible to have longer nomination and election periods?
In other processes such as removal of packages and the no responsive
maintainer process we have much longer waiting times (6 weeks) to
account for vacations and other commitments.


We had this in the past, and candidates had complained that it was 
taking too long for an election to occur with so few people voting.


Do you realize that this time the election period was midst of the 
summer holiday season, which means many people probably were off at 
least for some time?


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken dependencies messages

[Ralf Corsepius]

On 08/06/2017 05:38 PM, Björn 'besser82' Esser wrote:

Am 06.08.2017 um 17:28 schrieb mcatanz...@gnome.org:

Hi,

Since yesterday I'm getting a huge number of messages about broken 
dependencies in packages that I don't care about. Anybody else 
experiencing this?


Seems I'm being aliased to, at a minimum, 
poppler-ow...@fedoraproject.org and empathy-ow...@fedoraproject.org... 
plus several more.


Michael


For which reason are the dependencies broken?  There should be a note 
about that in these messages.


At least for me, they ain't:

> freefem++ has broken dependencies in the rawhide tree:
> On x86_64:
>freefem++-3.56-1.fc27.x86_64 requires libgsl.so.19()(64bit)

AFAIK, there was a new version of poppler pushed to Rawhide, but most of 
the depending packages should be rebuilt now.


In my case above, the culprit indeed seems to have been poppler.
Apparently it broken texlive, i.e. I am facing a broken dep chain
poppler->texlive->freefem++:

DEBUG util.py:439:  Error: nothing provides libpoppler.so.67()(64bit) 
needed by texlive-pdftex-bin-6:svn40987-35.20160520.fc27.1.x86_64


I'll wait for a couple of days until the dust settles ;)

Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: fedpkg new-sources broken?

[Ralf Corsepius]

On 07/21/2017 11:09 AM, Patrick  マルタインアンドレアス  Uiterwijk wrote:

Hi,


I seem to be unable to upload a new tarball for freefem++:

$ fedpkg new-sources freefem++-3.56.tar.gz
/usr/lib/python2.7/site-packages/fedora/client/bodhi.py:48:
DeprecationWarning: fedora.client.bodhi has been deprecated. Please use
bodhi.client.bindings instead.
DeprecationWarning)
Uploading: freefem++-3.56.tar.gz

100.0%
Could not execute new_sources: Fail to upload files. Server returns
status 502


Any ideas about what is going on here?


We were testing a fix for the double-upload.

Could you let us know what versions you have of: fedora-packager fedpkg curl 
python2-pycurl libcurl.


This should be F26 with all "released updates" applied.

# rpm -q fedora-packager fedpkg curl python2-pycurl libcurl
fedora-packager-0.6.0.1-2.fc26.noarch
fedpkg-1.28-1.fc26.noarch
curl-7.53.1-7.fc26.x86_64
python2-pycurl-7.43.0-8.fc26.x86_64
libcurl-7.53.1-7.fc26.x86_64


Also, please retry now, as we have reverted the server-side change that likely 
made you hit this.
OK, I see. The double-uploads now seem to be back, however "fedpkg 
new-sources" appears to be functional, now ;)


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

fedpkg new-sources broken?

[Ralf Corsepius]

Hi,


I seem to be unable to upload a new tarball for freefem++:

$ fedpkg new-sources freefem++-3.56.tar.gz
/usr/lib/python2.7/site-packages/fedora/client/bodhi.py:48: 
DeprecationWarning: fedora.client.bodhi has been deprecated. Please use 
bodhi.client.bindings instead.

  DeprecationWarning)
Uploading: freefem++-3.56.tar.gz
 
100.0%
Could not execute new_sources: Fail to upload files. Server returns 
status 502



Any ideas about what is going on here?

Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Ralf Corsepius]

On 07/11/2017 11:03 PM, Justin Forbes wrote:

On Tue, Jul 11, 2017 at 3:43 PM, Matthew Miller
 wrote:

On Tue, Jul 11, 2017 at 10:26:03PM +0200, Florian Weimer wrote:

I ran into this unannounced change:
   https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
If this is accepted, all x86 hardware on which Fedora can run will
support SSE2, and we should reflect that in the i686 build flags.
How likely is it that this proposal is accepted?  Ideally, we would know
this before the mass rebuild so that we can change the compiler flags in
redhat-rpm-config.


Currently i686 users are at about 1/6th of x86_64 users, by mirror
checkins. I don't have an easy way of knowing how many of those i686
checkins are old releases -- I'll need to ask Smooge to make a custom
report -- but I think it's fair to guess that it's significantly tilted
that way. So, taking a SWAG, I'd say maybe 10% of our users would be
impacted. That's pretty big, but on the other hand if the cost is
disproportionate -- and having heard from the kernel people about this
for several years, I think it might be -- it's probably something we
should do anyway.



The kernel team quit "supporting" i686 several releases ago, it is
down to community support, which is pretty much nonexistent. 


This was obvious.


Sure,
people file bugs, but rarely do people point to or supply patches for
those bugs. 
I was amongst them. The problem to users is not getting any response nor 
any hint from anybody to enable them chase bugs.


Fortunately, most presumed i686 specific issues seem to "heal" by 
itself, likely due  to upstream fixes or because they were not i686 
specific.



Justin

My biggest problem with is your announcement mentioned above.

I take this as a rude slap into my face, to say the least.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rawhide, dnf can not load RPM file *.fc26.x86_64.rpm

[Ralf Corsepius]

On 07/13/2017 06:30 AM, Chris Murphy wrote:

On Wed, Jul 12, 2017 at 10:22 PM, Samuel Sieb  wrote:

On 07/12/2017 09:14 PM, Chris Murphy wrote:


On Wed, Jul 12, 2017 at 10:03 PM, Chris Murphy 
wrote:


-rw-rw-r--. 1 chris chris unconfined_u:object_r:user_home_t:s0
53190 Jul 12 19:26 kernel-4.11.10-300.fc26.x86_64.rpm
kernel-4.11.10-300.fc26.x86_64.rpm:   data



I downloaded the same files, from the same location on the same
Rawhide system again and now it's

kernel-4.11.10-300.fc26.x86_64.rpm:RPM v3.0 bin
i386/x86_64 kernel-4.11.10-300.fc26

I don't understand why, or why it would behave one way for hours and
now behave a different way.



It would be interesting to see what the other contents of the file were, but
I guess it's too late now.  Are they the same size as before?



HUH. It gets even stranger! The ones first downloaded that are broken,
every single one is exactly 8192 bytes smaller than the good
replacements.


Do you happen to run F26?

The phenomenon you are describing would match with what I am 
occasionally observing happening on F26.


What I am occasionally seeing here, is writing out the "end of a (large) 
file (last block?) to disk" to take a very long time (In the order of 
several minutes), seemingly occasionally leaving shortened files behind. 
To me, the symptoms look like fflush/fclose/fsync issues which lets me 
suspect the origin being the kernel or glibc.


Ralf



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rawhide, dnf can not load RPM file *.fc26.x86_64.rpm

[Ralf Corsepius]

On 07/13/2017 06:14 AM, Chris Murphy wrote:

On Wed, Jul 12, 2017 at 10:03 PM, Chris Murphy  wrote:

-rw-rw-r--. 1 chris chris unconfined_u:object_r:user_home_t:s0
53190 Jul 12 19:26 kernel-4.11.10-300.fc26.x86_64.rpm
kernel-4.11.10-300.fc26.x86_64.rpm:   data



I downloaded the same files, from the same location on the same
Rawhide system again and now it's

kernel-4.11.10-300.fc26.x86_64.rpm:RPM v3.0 bin
i386/x86_64 kernel-4.11.10-300.fc26


I don't understand why, or why it would behave one way for hours and
now behave a different way.


Did you compare the files and are you sure to really have downloaded the 
files from the same server?


These days, there are URLs which redirect downloads to different hosts, 
as well as many Fedora mirrors are broken.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Ralf Corsepius]

On 07/12/2017 01:39 PM, Reindl Harald wrote:



Am 12.07.2017 um 13:24 schrieb Ralf Corsepius:

On 07/12/2017 11:57 AM, Dominik 'Rathann' Mierzejewski wrote:

On Wednesday, 12 July 2017 at 02:06, Kevin Kofler wrote:

Dominik 'Rathann' Mierzejewski wrote:
Considering that SSE2 was introduced by Intel in 2001 and AMD 
caught up

with it in 2003, I'd be +1 (with my FESCo hat on) to requiring SSE2,
regardless of whether the above change is accepted.


If you require SSE2, you limit the usefulness of the i686 kernel to
basically just a single generation of CPUs, the next generation 
introduced

x86_64.


Right. It probably makes sense to abandon i686 kernels altogether,
then.


If you intend to kill Fedora, and furtherly emphasize the impression 
of Fedora not being community driven distro :(


that is FUD and polemic
Well, I of course have disagree. The course Fedora has taken is obvious: 
Servers and  containers.


And the course Fedora i686 has taken leads users directly to Ubuntu, 
Debian, Windows or the trash bin.



i strongly doubt a relevant usebase is on i686 kernels at all for 
reasons mutilple times explained - why would anybody run a bleeding 
edge distribution seriously on ages old hardware


Like I said before, I doubt the arm, powerpc etc. to have a user-base 
which is magnitudes smaller than the i686.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Ralf Corsepius]

On 07/11/2017 10:43 PM, Matthew Miller wrote:

On Tue, Jul 11, 2017 at 10:26:03PM +0200, Florian Weimer wrote:

I ran into this unannounced change:
   https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
If this is accepted, all x86 hardware on which Fedora can run will
support SSE2, and we should reflect that in the i686 build flags.
How likely is it that this proposal is accepted?  Ideally, we would know
this before the mass rebuild so that we can change the compiler flags in
redhat-rpm-config.


Currently i686 users are at about 1/6th of x86_64 users, by mirror
checkins. I don't have an easy way of knowing how many of those i686
checkins are old releases -- I'll need to ask Smooge to make a custom
report -- but I think it's fair to guess that it's significantly tilted
that way. So, taking a SWAG, I'd say maybe 10% of our users would be
impacted. That's pretty big, but on the other hand if the cost is
disproportionate If cost is an issue, consider to drop all these ppc, arm, s370 and mips 

targets.

Their user base is like magnitudes smaller than the i686 user base, 
while these target are having a significant impact (and thus cost) on 
everything in Fedora.



Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Ralf Corsepius]

On 07/12/2017 12:16 PM, Dominik 'Rathann' Mierzejewski wrote:


I still have my N270 netbook, but I guess even more people still have
Z6xx-based devices. Still, they're over 7 years old at this point.


The N270s are still supported by Windows 10.

Furthermore: Linux (thus Fedora) has always one of the last resorts for 
people wanting to escape Windows' and their violent HW obsolesence on 
older HW.


Do you want Fedora to join this choir? I don't.

Ralf


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Ralf Corsepius]

On 07/12/2017 11:57 AM, Dominik 'Rathann' Mierzejewski wrote:

On Wednesday, 12 July 2017 at 02:06, Kevin Kofler wrote:

Dominik 'Rathann' Mierzejewski wrote:

Considering that SSE2 was introduced by Intel in 2001 and AMD caught up
with it in 2003, I'd be +1 (with my FESCo hat on) to requiring SSE2,
regardless of whether the above change is accepted.


If you require SSE2, you limit the usefulness of the i686 kernel to
basically just a single generation of CPUs, the next generation introduced
x86_64.


Right. It probably makes sense to abandon i686 kernels altogether,
then.


If you intend to kill Fedora, and furtherly emphasize the impression of 
Fedora not being community driven distro :(


Ralf


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Ralf Corsepius]

On 07/11/2017 10:57 PM, Josh Boyer wrote:

On Tue, Jul 11, 2017 at 4:41 PM, Dominik 'Rathann' Mierzejewski
 wrote:

On Tuesday, 11 July 2017 at 22:26, Florian Weimer wrote:

I ran into this unannounced change:

   https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels


I noticed this is categorized as self-contained, which I think is wrong.

I also have hardware that would no longer run Fedora after such change
(a netbook with an older Intel Atom CPU which supports SSE2, but is
32bit). Unless the change proponent can provide some numbers suggesting
that 32bit users are a tiny minority of our userbase, I'll probably
be against such change.


Anyone with 32-bit hardware is going to be against this change.

Well, many 32-bit intels support SSE2. Original i686ers don't.

That said, I am against this step.


 It is
a known downside.  It also doesn't change the fact that i686 kernels
are in a zombie state, where the kernel team does not actively support
them and the community has not significantly stepped up to do so.
That approach was done quite a while ago, and explicitly communicated.

This was a step, anybody with 32bit HW should have being against.

And in deed, I have always considered this decision to be management and 
leadership mistake.



The fact that i686 kernels continue to work in general is basically luck.
You probably will deny this, but in practice it has been so for many 
years, because the i686 has dropped out of RHAT's business interest.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [SONAME change] MySQL, MariaDB

[Ralf Corsepius]

On 07/03/2017 04:02 PM, Michal Schorm wrote:

Nope.

MariaDB is a drop-in replacement. In version 5.5.


What you wrote is an API change
=> MariaDB is not a drop-in replacement for MySQL anymore.

The "many ṕackages requiring changes" you mentioned furtherly manifest this.

Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [SONAME change] MySQL, MariaDB

[Ralf Corsepius]

On 07/03/2017 03:12 PM, Michal Schorm wrote:

Hello everybody!

Since MariaDB 10.2 is finally stable and I resolved all issues that 
blocked it for Fedora, I'd like to propose an update for Rawhide.


Current version of MariaDB: 10.1.24
Update planned to: 10.2.6 (or newer)

*This change introduces change of library name from "libmysqlclient.so" 
to "libmariadb.so".*


In other word mariadb is failing its mission to be a drop-in replacement 
for mysql.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Test-Announce] Fedora 26 Candidate Beta-1.4 Available Now!

[Ralf Corsepius]

On 06/01/2017 08:21 AM, Ralf Corsepius wrote:

On 06/01/2017 06:28 AM, rawh...@fedoraproject.org wrote:

According to the schedule [1], Fedora 26 Candidate Beta-1.4 is now
available for testing.


Trying Fedora-Workstation-netinst-i386-26_Beta-1.4.iso on an older 
i686-netbook fails with this:

...
[Failed] Failed to start Switch Root
See 'systemctl status initrd-switch-root.service' for details
...
Entering emergency mode
...

In "emergency mode":
# systemctl status initrd-switch-root.service
Failed to map properties: Bad message



Seems to me, as if dracut is segfaulting:

# cat rdsosreport.txt | grep segfault
[   16.346293] localhost kernel: dracut-cmdline[173]: segfault at 
805c1000 ip b771c239 sp bfb6a138 error 4 in libc-2.25.so[b75af000+1dd000]
[   20.57] localhost kernel: dracut-pre-trig[328]: segfault at 
81fef000 ip b76d9239 sp bf9cb758 error 4 in libc-2.25.so[b756c000+1dd000]



rpc also seems to be in trouble:
# cat rdsosreport.txt | grep rpc
...
[   20.701711] localhost systemd-tmpfiles[300]: Failed to open 
'rpcbind.conf': No such file or directory
[   20.703255] localhost dracut-pre-udev[221]: rpcbind: 
/run/rpcbind/rpcbind.lock: No such file or directory

[   20.731156] localhost rpc.statd[304]: Version 2.1.1 starting
[   20.748734] localhost rpc.statd[304]: Initializing NSM state
[   20.751577] localhost rpc.statd[304]: Running as root.  chown 
/var/lib/nfs/statd to choose different user
[   20.767872] localhost rpc.statd[304]: Failed to register (statd, 1, 
udp): svc_reg() err: RPC: Remote system error - Connection refused
[   20.784099] localhost rpc.statd[304]: Failed to register (statd, 1, 
tcp): svc_reg() err: RPC: Remote system error - Connection refused
[   20.800277] localhost rpc.statd[304]: Failed to register (statd, 1, 
udp6): svc_reg() err: RPC: Remote system error - Connection refused
[   20.816495] localhost rpc.statd[304]: Failed to register (statd, 1, 
tcp6): svc_reg() err: RPC: Remote system error - Connection refused
[   20.817708] localhost rpc.statd[304]: failed to create RPC listeners, 
exiting



Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Test-Announce] Fedora 26 Candidate Beta-1.4 Available Now!

[Ralf Corsepius]

On 06/01/2017 08:30 AM, Christian Dersch wrote:

What is "an older i686-netbook"?


It's a 2008's Medion Akoya E1210 (To Germans, aka "The Aldi-Netbook"), a 
rebranded variant of the MSI Wind U100 in a grub/BIOS-multiboot 
configuration:


With Fedora 25:
# cat /proc/cpuinfo
model name  : Intel(R) Atom(TM) CPU N270   @ 1.60GHz
...
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc 
arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 
xtpr pdcm movbe lahf_lm dtherm

...

Fedoras < 26, Ubuntu, Debian all were installable without major probs.

Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Test-Announce] Fedora 26 Candidate Beta-1.4 Available Now!

[Ralf Corsepius]

On 06/01/2017 06:28 AM, rawh...@fedoraproject.org wrote:

According to the schedule [1], Fedora 26 Candidate Beta-1.4 is now
available for testing.


Trying Fedora-Workstation-netinst-i386-26_Beta-1.4.iso on an older 
i686-netbook fails with this:

...
[Failed] Failed to start Switch Root
See 'systemctl status initrd-switch-root.service' for details
...
Entering emergency mode
...

In "emergency mode":
# systemctl status initrd-switch-root.service
Failed to map properties: Bad message

Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Killing koji buildjobs

[Ralf Corsepius]

On 04/28/2017 01:32 PM, Milan Crha wrote:

On Fri, 2017-04-28 at 12:33 +0200, Ralf Corsepius wrote:

These 2 build jobs (launched by me) seem to be hanging and don't seem
to be wanting to finish (or fail) for 3 days (for reasons unknown to
me):


Hi,
it looks like it got stuck after a failure in the tests. See the build
logs (tail is enough), where it says:


../test-driver-ff: line 103: 21324 Aborted
   (core dumped) ${TEST_FFPP} ${FLAGS_FFPP} "$@" > $log_file 2>&1


I didn't look into all build logs, but both i686 and aarch64 have this,
while x86_64 (which finished successfully) doesn't.


Yes, I also saw this (2 days ago). Trying to investigate whether this is 
a gcc regression, actually was the reason, why I launched the f26 
scratch-build ;)


However, I do not understand, why the build jobs got stuck.
Doesn't koji have any timeouts anymore?

Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org