date:20180604


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


This proposal suggests to accept this reality and build the i686
packages in such a way that they require the ISA level of (early)
x86-64 CPUs.


Will Fedora 29 run on the CPU listed above?


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.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/XQYT3XJAMKQXYSD5TCL2Y5NOKHZGWPPV/

Re: F29 System Wide Change: Perl Move to MetaCPAN

2018-06-04 Thread Petr Pisar

On 2018-05-25, Jan Kurik  wrote:
>= Proposed System Wide Change: Perl Move to MetaCPAN =
> https://fedoraproject.org/wiki/Changes/Perl_Move_to_MetaCPAN
>
This change was approved and I will start updating the packages in a few
moments.

Each affected package will receive one commit with "cpan.org addresses
moved to MetaCPAN
" title.
There won't be any Release number bump.

Packages are free to apply this change into older Fedoras. Packagers do
not have to rebuild package because of this change. Most of the packages
will be rebuilt in subsequent Perl 5.28 mass rebuild that will bring the
change to the users.

-- Petr
___
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/JZJOKTYX365EFDY7MAQ77DQ244G54CXX/

F29 System Wide Change: NSS load p11-kit modules by default

2018-06-04 Thread Jan Kurik

= Proposed System Wide Change: NSS load p11-kit modules by default =
https://fedoraproject.org/wiki/Changes/NSSLoadP11KitModules


Owner(s):
  * Daiki Ueno 


When NSS database is created, PKCS#11 modules configured in the
system's p11-kit will be automatically registered and visible to NSS
applications.



== Detailed description ==
Fedora provides a mechanism to configure PKCS#11 modules system wide,
allowing the crypto libraries (GnuTLS and OpenSSL) to use PKCS#11
modules in a consistent manner. Until now NSS applications haven't
benefit from it as NSS uses a different configuration mechanism which
requires users to register PKCS#11 modules in NSS databases. This
change makes the manual procedure unnecessary, by registering the
p11-kit-proxy module (the aggregator of the system PKCS#11 modules) in
NSS databases with the default configuration.
See also:
* https://bugzilla.redhat.com/show_bug.cgi?id=1173577


== Scope ==
* Proposal owners:
** Enable p11-kit-proxy in the newly created NSS database, through the
crypto-policies package.
** Modify the opensc package not to register itself to the NSS
database upon installation.

* Other developers:
** Make sure that this change doesn't cause any regression with the
existing applications.

* Release engineering:
[https://pagure.io/releng/issue/7548 #7548]
** List of deliverables: N/A

* Policies and guidelines:
PackageMaintainers/PKCS11 needs changes basically to eliminate NSS
specific stuff

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
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/5J5SRVBJR5PDE6G6ZKOFWQG5AJ6WCFR3/

Re: Nonresponsive maintainer: guidograzioli

2018-06-04 Thread Till Hofmann



On 06/04/2018 10:14 AM, Till Hofmann wrote:
> Hi all,
> 
> I'm trying to get in contact with Guido Graizoli (FAS guidograzioli). He
> has not responded to a bug report requesting an update of bibtex2html
> [1]. The package is currently also FTBFS [2], where he did not respond
> either. I also tried contacting him privately by e-mail, but I did not
> get a response.

I reached Guido through his private e-mail. He'll reassign/orphan some
of his packages and take care of the rest.

Kind regards,
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/MUWMT2SCNSNPG2EMZ6B6OBNBGXRHDHB3/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Alexander Ploumistos

> == Detailed description ==
> Currently, the i686 RPM packages are built in such a way that they are
> compatible with very old i686 systems, such as the Pentium III.  The
> only addition over the i686/Pentium Pro baseline is a requirement to
> support long NOPs, for Intel CET.  However, the majority of
> installations of i686 packages is for use on x86_64 systems, as
> multi-lib RPMs.

Based on what data?

>  Furthermore, there are reports that the i686 kernel
> does not run stable on old hardware which is not x86-64-capable (
> https://lists.fedoraproject.org/archives/list/x...@lists.fedoraproject.org/thread/ZHV6I4IEO7GRYAZ4TUMO5VH2ZHLCNJZQ/
> ).

On some, not all.

> This proposal suggests to accept this reality and build the i686
> packages in such a way that they require the ISA level of (early)
> x86-64 CPUs.

On which x86 CPU families will Fedora continue to work?
I think this change should have been discussed on the x86 SIG mailing
list first, as it essentially goes against what the SIG had been
trying to do and deprives it of its purpose.
___
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/E2S74E7LIFWK65N2V6XHCPGUXD2LTCRF/

Re: Hiding the grub menu by default on single OS installs

2018-06-04 Thread Hans de Goede


Hi,

On 04-06-18 09:16, Hans de Goede wrote:

Hi,

Note I've dropped the fedora-devel list (-ETOOMUCHBIKESHED)
and added Javier and Jan to the Cc.


Ugh, so clearly I failed to remove fedora-devel from the CC.

Ah well. I hope this mistake shows that there is nothing
nefarious going on here and that Javier, Peter and I are
really just working on trying making the boot experience
nicer for Workstation users, while at the same time very
thoroughly keeping in mind the rescue / things broke
scenario.

Regards,

Hans




On 01-06-18 20:03, Peter Jones wrote:

On Thu, May 31, 2018 at 05:47:36PM +0200, Hans de Goede wrote:

Hi,

On 31-05-18 15:20, Robert Marcano wrote:

On 05/31/2018 06:52 AM, Hans de Goede wrote:

...
This will basically get us back the F28 behavior of showing the
menu but only after a failed boot, I think that is a good
solution, do you agree?


What is the definition of a successful boot? I ask because a machine
could boot perfectly, and when you try to interact with it on the
login screen, bugs on the display driver can change the screen to
garbage (I have seen this kind on bug long time ago), or lockup. So,
the user will be unable to activate any kind of restart with menu
enabled in order to try an older kernel, or boot to rescue mode.

I think instead of only detecting a successful boot, a machine that
wasn't properly shutdown should enable the menu


A broken install may still shutdown properly after the using pressing
the power-button and/or trying ctrl+alt+del.

But this is an interesting suggestion, I think we should track both
separately, so successful shutdown and successful boot and show the
menu if either one is not true. That should make the chance of not
being able to get the menu a lot smaller.


In my mind, the mechanism here looks like what I've sketched out below,
and I think it encapsulates the above as well as most of what I've seen
on this thread already.

The workflow is something like this:

- user updates the OS[0]
   - we automatically set the new OS to be booted /once/.


Hmm, I see you also refer to atomic and there this makes sense, but
in the traditional distro model how would we implement this?

We could implement boot a new kernel once, but since a xserver /
mesa / gnome update might break things just as easily as a kernel
update can break things I'm not sure if adding boot-once functionality
to the traditional model is really helpful.

Reverting to the old kernel might help in some cases, but we are
also going to get false-positives. I've a feeling this is going to
become really messy. As such I don't think this is a change we
can "sell" easily. Some people really don't seem to like the idea of
any changes to the grub config / menu at all.

I've a feeling that selling the hidden menu by itself is enough
of a hassle without adding in booting a new kernel once to test it.
I realize that this in a way is a way to lessen the impact of the
menu being hidden, but I'm not 100% sold on this.

I would rather just show the menu after a failed boot and have
reverting to the kernel be a conscious choice of the user. I have
a number of reasons for this:

1) Don't revert to older kernel on false-positive failed boot detects
    (limit the result of a false-positive failed boot detect to showing
     the menu without any side

2) Updates typically come in batches and the boot failure may well be
    caused by something else, so we're not necessarily helping the user
    here, even if the user manages to fix things he will now be running
    an older kernel for no good reason.

3) Since reverting to the old kernel may not be enough, we still need
    to show the menu after a failed boot

4) Principle of least surprise, we are now making unrequested changes to
    the users system and not (really) notifying the user of this.
    For Atomic I envision that after switching back to the old snapshot /
    release the UI will show a dialog after login along the lines of:
    "The new 20190214 release did not work, we've reverted your machine
     to the 20190207 release" (but then better worded). We could do
    something similar for the kernel, assuming reverting to the old
    kernel will allow us to show the dialog, but we again have the whole
    false positive thing, so now we end up showing a scary dialog because
    of a false-positive failed-boot detect.

So all in all I'm not a big fan of the boot once concept for the
traditional Fedora version. I think it makes a lot of sense for Atomic
and we should do it there, but not for Fedora.

Another thing to keep in mind is that we don't really have much time
to get things in place for F29, so especially for F29 this seems
too complex and I would prefer to only add a "GRUB_AUTO_HIDE"
option to /etc/default/grub which when set will make grub2-mkconfig
generate a grub.cfg which will hides the menu unless a failed boot
is detected and not make any changes wrt which kernel to boot when.

This also has the added advantage that it avoids

Re: Change in Copr retention policy?

2018-06-04 Thread Miroslav Suchý

Dne 4.6.2018 v 10:03 Jan Pazdziora napsal(a):
> In any case, it'd be nice to notify the owners of those repos to give
> them chance to review what they have and potentially rebuild their
> content on newer buildroots, or just mark their repos "alive" and
> extend the expiration for another 180 days. Or something to that
> effect.

I like this idea.

Miroslav
___
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/JCO5KN2BVBLHATMJ7GQHMYG7J5CGJ6PI/

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

2018-06-04 Thread 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: F29 System Wide Change: Perl Move to MetaCPAN

2018-06-04 Thread Petr Pisar

On 2018-06-04, Petr Pisar  wrote:
> On 2018-05-25, Jan Kurik  wrote:
>>= Proposed System Wide Change: Perl Move to MetaCPAN =
>> https://fedoraproject.org/wiki/Changes/Perl_Move_to_MetaCPAN
>>
> This change was approved and I will start updating the packages in a few
> moments.
>
> Each affected package will receive one commit with "cpan.org addresses
> moved to MetaCPAN
>" title.
> There won't be any Release number bump.
>
Done.

-- Petr
___
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/A5LFUOUTUKIQB564SXSNKPPC5CYHHNPG/

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

2018-06-04 Thread Ian Pilcher


On 06/04/2018 04:28 AM, Florian Weimer 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.


So the 32-bit x86 SIG would be required to rebuild all of the userspace
packages to run on actual 32-bit hardware, right?  (What would those be
called, since i686 is taken?)

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 

___
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/WZMWAPNARRWXNJX5LOLUBJYDIOK2I7EU/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64


On 06/04/2018 02:39 PM, Alexander Ploumistos wrote:

== Detailed description ==
Currently, the i686 RPM packages are built in such a way that they are
compatible with very old i686 systems, such as the Pentium III.  The
only addition over the i686/Pentium Pro baseline is a requirement to
support long NOPs, for Intel CET.  However, the majority of
installations of i686 packages is for use on x86_64 systems, as
multi-lib RPMs.


Based on what data?


The mirror data I've seen, but it's really outdated at this point.


This proposal suggests to accept this reality and build the i686
packages in such a way that they require the ISA level of (early)
x86-64 CPUs.


On which x86 CPU families will Fedora continue to work?


Based on this proposed change, you will need an x86-64-capable CPU.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/6MNG7RWPR6DY6WZHI4SUAAF6VEAAENP4/

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

2018-06-04 Thread Josh Boyer

On Mon, Jun 4, 2018 at 10:09 AM Ralf Corsepius  wrote:
>
> 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.

I'm going to be as clear as I possibly can here.  Red Hat, as a
company, is not going to put resources into fixing issues found on
Pentium III machines in Fedora, regardless of whether or not this
proposal passes.  There is an x86 SIG who was tasked with that kind of
activity.  The SIG should be fixing the issues it has responsibility
for.

josh
___
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/JP7FTOLHV4M2ZCMBO7V7QKPSH3DTAAXR/

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

2018-06-04 Thread Adam Jackson

On Mon, 2018-06-04 at 08:59 -0500, Ian Pilcher wrote:
> On 06/04/2018 04:28 AM, Florian Weimer 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.
> 
> So the 32-bit x86 SIG would be required to rebuild all of the userspace
> packages to run on actual 32-bit hardware, right?  (What would those be
> called, since i686 is taken?)

No. The 32-bit ABI level being targeted here is basically the Pentium
4, which was a 32-bit part. On a P3 or older, yes, you'd need a
rebuild, but the P4 was 2001 so we're talking about hardware old enough
to vote here.

If we did want to allow for pre-P4 32-bit userspace, what I'd probably
do is (mostly) change %_libdir to /usr/lib/sse2 for i686, and leave it
as /usr/lib for a (reintroduced) i586 architecture.

- ajax
___
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/5ZTMW77HAWOFQN3QTA2BJB7IYQXWRUQW/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Adam Jackson

On Mon, 2018-06-04 at 16:04 +0200, Florian Weimer wrote:

> > > This proposal suggests to accept this reality and build the i686
> > > packages in such a way that they require the ISA level of (early)
> > > x86-64 CPUs.
> > 
> > On which x86 CPU families will Fedora continue to work?
> 
> Based on this proposed change, you will need an x86-64-capable CPU.

That's not how I read the proposal. No reason a P4 shouldn't work if
all you're requiring is SSE2+FXSR, right?

- ajax
___
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/6OYP2FKS4ASPWQ4OAZFLPUXFDTNUUEGK/

Re: F29 System Wide Change: Hide the grub menu

2018-06-04 Thread Vít Ondruch

Dne 1.6.2018 v 16:29 Ken Coar napsal(a):
> On 06/01/2018 05:06 AM, Vít Ondruch wrote:
>> It is irony, that people, who are capable to get into the grub menu if
>> they need, complain about it being hidden. So to say, I am 100% for
>> hiding the grub menu, speeding up the boot process, and if need it, I'll
>> find a way to get it.
> I fail to see any irony here.  When I need to get into the
> grub menu, it's usually an emergency (or at least highly-stressful)
> situation, with no documentation handy, and flailing about
> trying to figure out how to make it appear just adds to the
> stress and the blue tinge of the air in my vicinity.
>
> What *exactly* is this trying to solve?
>
> IIRC, the patch is to hide the grub menu IFF there's only one
> kernel because 'it serves no useful function.'  A number of
> people (myself included) have disputed that assertion.  If
> the assertion is invalid, the patch shouldn't be applied.
> Correct?  That seems simple enough.  Or maybe I don't understand
> the process, lacking sufficient Fedora-devel-fu karma.
>
> How many non-tech end users install Fedora straight
> from the distro, as opposed to those who install a frobbed
> version, with different defaults, from a repackager?
> _I.e._, repackagers can set grub up however they like.
>
> Is Fedora's goal to be end-user friendly, tech friendly, or
> the all-singing all-dancing Linux distro?

Talking from my experience running Rawhide on two my laptops for ~5
years, I really don't remember where I would really need to use older
kernel. If I had to, it was probably due to something like audio issues
with my docking station and that is hardly the situation you describe.

In my family, there are another 2 computers running Fedora. I don't
remember any kernel related issues. And if there were kernel issues,
explaining my sister that she should use older kernel would be similarly
difficult if the menu is displayed or not.

But the true is, that the computers are not using any proprietary
drivers, which might be issue.

V.
___
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/EUPTPHKWWMRBWLCN6KZTJCCQN6ZQ7GJF/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64


On 06/04/2018 05:07 PM, Adam Jackson wrote:

On Mon, 2018-06-04 at 16:04 +0200, Florian Weimer wrote:


This proposal suggests to accept this reality and build the i686
packages in such a way that they require the ISA level of (early)
x86-64 CPUs.


On which x86 CPU families will Fedora continue to work?


Based on this proposed change, you will need an x86-64-capable CPU.


That's not how I read the proposal. No reason a P4 shouldn't work if
all you're requiring is SSE2+FXSR, right?


It will probably work, but it's more of a happy accident than a 
deliberate decision.  I would still suggest it if it were incompatible 
with Pentium 4 CPUs without x86-64 support.  (The fewer of these 
Netburst power guzzlers are running, the better, to be honest.)


Certainly, I don't see us jumping to long mode, doing the computation 
there, and jumping back, so it's hard to imagine that anything more than 
SSE2 (you need fxsr for SSE2 for the context switch AFAICS anyway) will 
be required by the i686 user space in the future.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/T6TWR7E7DZK5YURPGNN26CD2S5T7YUZ6/

Re: Hiding the grub menu by default on single OS installs

2018-06-04 Thread Vít Ondruch



Dne 1.6.2018 v 19:00 Jason L Tibbitts III napsal(a):
>> "TK" == Tomas Kovar  writes:
> TK> - this one is on the polish side of things:
> [don't keep bouncing to text mode]
>
> I might also add that as part of this, we'd also need to get rid of the
> very early message about EFI secure boot being enabled.  Then we'd be
> left only with the random kernel message spew that some machines have
> just before X starts up.  (For me it's usually something complaining
> about ACPI tables or somesuch.)

Good point, I see such messages + messages about high temperature and
throttling CPU every boot.

V.

 
>   But I'm sure Hans has already thought
> of all of that.
>
>  - J<
> ___
> 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/GSXVCVYM2V7B43L6CXR26WPSM5TV3RWW/
___
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/B4H6S66BUBWP67BQJW55GXVWRLB27DT4/

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

2018-06-04 Thread Al Dunsmuir

On Monday, June 4, 2018, 4:35:34 AM, Jan Kurik wrote:
> = Proposed System Wide Change: i686 Is For x86-64 =
> https://fedoraproject.org/wiki/Changes/i686_Is_For_x86-64

> Owner(s):
>   * Florian Weimer 

> Fedora builds its i686 packages for use on x86-64 systems as multi-lib RPMs.

> == Detailed description ==
> Currently, the i686 RPM packages are built in such a way that they are
> compatible with very old i686 systems, such as the Pentium III.  The
> only addition over the i686/Pentium Pro baseline is a requirement to
> support long NOPs, for Intel CET.  However, the majority of
> installations of i686 packages is for use on x86_64 systems, as
> multi-lib RPMs.  Furthermore, there are reports that the i686 kernel
> does not run stable on old hardware which is not x86-64-capable (
> https://lists.fedoraproject.org/archives/list/x...@lists.fedoraproject.org/thread/ZHV6I4IEO7GRYAZ4TUMO5VH2ZHLCNJZQ/
> ).
> This proposal suggests to accept this reality and build the i686
> packages in such a way that they require the ISA level of (early)
> x86-64 CPUs.


> == Scope ==
> * Proposal owners:
> Adjust the redhat-rpm-config, gcc, and glibc packages to switch to the
> new compiler flags. Except for mstackrealign, there is substantial
> experience with this configuration downstream.

> * Other developers:
> Other developers can enable SSE2 optimization in their packages if
> they want, where this has been a compile-time option only.

> * Release engineering:
> https://pagure.io/releng/issues/7543 #7543

> ** List of deliverables: TBD

> * Policies and guidelines:
> i686 is no longer a primary architecture. The Packaging Guidelines do
> not currently require support for non-SSE2 x86 systems, so no change
> is required there.

I think this change is fundamentally wrong.

If  you  have  the 64-bit capable hardware, should not the focus be on
the  X84-64  modules?   The 32-bit modules are targeted to an entirely
different audience, who have already decided to take a performance hit
by running in 32-bit mode.

Requiring  64-bit  hardware  to run the 32-bit modules does not simply
impact the i686 secondary architecture - it fundamentally breaks it.

I  don't see this change as being reasonable unless the i686 secondary
arch is going to get a full parallel build to support i686 hardware. I
don't see that happening either.

Al
___
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/X5MHFHEHQISB2YJBENM6JB3UUDPRJBSM/

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

2018-06-04 Thread Justin Forbes

On Mon, Jun 4, 2018 at 8:23 AM, Ralf Corsepius  wrote:
> 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.
>
I don't think RH is trying to hide anything here. The i686 SIG was
created specifically to handle issues like this. What are they doing
to fix it?
___
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/5JTHNVTE6J5KV6DRGQ7J2NSZHRUOEGZ5/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Adam Jackson

On Mon, 2018-06-04 at 17:21 +0200, Florian Weimer wrote:
> On 06/04/2018 05:07 PM, Adam Jackson wrote:
> > On Mon, 2018-06-04 at 16:04 +0200, Florian Weimer wrote:
> > 
> > > > > This proposal suggests to accept this reality and build the i686
> > > > > packages in such a way that they require the ISA level of (early)
> > > > > x86-64 CPUs.
> > > > 
> > > > On which x86 CPU families will Fedora continue to work?
> > > 
> > > Based on this proposed change, you will need an x86-64-capable CPU.
> > 
> > That's not how I read the proposal. No reason a P4 shouldn't work if
> > all you're requiring is SSE2+FXSR, right?
> 
> It will probably work, but it's more of a happy accident than a 
> deliberate decision.  I would still suggest it if it were incompatible 
> with Pentium 4 CPUs without x86-64 support.  (The fewer of these 
> Netburst power guzzlers are running, the better, to be honest.)

Certainly, I'm no netburst fan either. But the last[*] 32-bit-only
Intel chip was Yonah (Core 1), which went out of production in 2008-
ish, so there's about seven years worth of CPUs between the
introductions of SSE2 and AMD64. So this isn't eliminating the
possibility of extant i686 kernels, which "will need an x86-64-capable
CPU" might otherwise imply.

[*] - Ignoring Quark, as the rest of the market did.

- ajax
___
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/TGAZS4TK3F5XW4PIRXCJCLMQYVC4HCZP/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 4, 2018 at 7:20 AM, Florian Weimer  wrote:

> = Proposed System Wide Change: i686 Is For x86-64 =
> https://fedoraproject.org/wiki/Changes/i686_Is_For_x86-64
>
>
> Owner(s):
>   * Florian Weimer 
>
>
> Fedora builds its i686 packages for use on x86-64 systems as multi-lib
> RPMs.
>
>
>
> == Detailed description ==
> Currently, the i686 RPM packages are built in such a way that they are
> compatible with very old i686 systems, such as the Pentium III.  The
> only addition over the i686/Pentium Pro baseline is a requirement to
> support long NOPs, for Intel CET.  However, the majority of
> installations of i686 packages is for use on x86_64 systems, as
> multi-lib RPMs.  Furthermore, there are reports that the i686 kernel
> does not run stable on old hardware which is not x86-64-capable (
> https://lists.fedoraproject.org/archives/list/x...@lists.fedo
> raproject.org/thread/ZHV6I4IEO7GRYAZ4TUMO5VH2ZHLCNJZQ/
> ).
> This proposal suggests to accept this reality and build the i686
> packages in such a way that they require the ISA level of (early)
> x86-64 CPUs.
>

Would you please provide more detail on what problem or problems we are
trying to solve? Is this purely for efficiency reasons?

jeff
___
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/MMJYA7KVFJ3UEYMVFQL3OFQLI7R27Z54/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Chris Adams

Once upon a time, Adam Jackson  said:
> Certainly, I'm no netburst fan either. But the last[*] 32-bit-only
> Intel chip was Yonah (Core 1), which went out of production in 2008-
> ish, so there's about seven years worth of CPUs between the
> introductions of SSE2 and AMD64.

I think you are missing a some of The Atom chips that are 32-bit only;
there are versions that were released as late as 2010 that don't support
64-bit (I don't know when they were discontinued).  Whether that's a
target for Fedora i686, I don't know.

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/LWHYMRNOWRTFDJ5YPPYFV6EF7FPARIDB/

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

On Mon, Jun 4, 2018 at 11:01 AM, Adam Jackson  wrote:

> On Mon, 2018-06-04 at 08:59 -0500, Ian Pilcher wrote:
> > On 06/04/2018 04:28 AM, Florian Weimer 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.
> >
> > So the 32-bit x86 SIG would be required to rebuild all of the userspace
> > packages to run on actual 32-bit hardware, right?  (What would those be
> > called, since i686 is taken?)
>
> No. The 32-bit ABI level being targeted here is basically the Pentium
> 4, which was a 32-bit part. On a P3 or older, yes, you'd need a
> rebuild, but the P4 was 2001 so we're talking about hardware old enough
> to vote here.
>
> If we did want to allow for pre-P4 32-bit userspace, what I'd probably
> do is (mostly) change %_libdir to /usr/lib/sse2 for i686, and leave it
> as /usr/lib for a (reintroduced) i586 architecture.
>

If there is truly a pressing need to enable SSE2 for *all* i686 binaries,
I'd support this as a compromise.

jeff

-- 
Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
___
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/Q7ZN5JPBX44TSYF5KBUY2656BQ5PRFQE/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 4, 2018 at 11:52 AM, Adam Jackson  wrote:

> On Mon, 2018-06-04 at 17:21 +0200, Florian Weimer wrote:
> > On 06/04/2018 05:07 PM, Adam Jackson wrote:
> > > On Mon, 2018-06-04 at 16:04 +0200, Florian Weimer wrote:
> > >
> > > > > > This proposal suggests to accept this reality and build the i686
> > > > > > packages in such a way that they require the ISA level of (early)
> > > > > > x86-64 CPUs.
> > > > >
> > > > > On which x86 CPU families will Fedora continue to work?
> > > >
> > > > Based on this proposed change, you will need an x86-64-capable CPU.
> > >
> > > That's not how I read the proposal. No reason a P4 shouldn't work if
> > > all you're requiring is SSE2+FXSR, right?
> >
> > It will probably work, but it's more of a happy accident than a
> > deliberate decision.  I would still suggest it if it were incompatible
> > with Pentium 4 CPUs without x86-64 support.  (The fewer of these
> > Netburst power guzzlers are running, the better, to be honest.)
>
> Certainly, I'm no netburst fan either. But the last[*] 32-bit-only
> Intel chip was Yonah (Core 1), which went out of production in 2008-
> ish, so there's about seven years worth of CPUs between the
> introductions of SSE2 and AMD64. So this isn't eliminating the
> possibility of extant i686 kernels, which "will need an x86-64-capable
> CPU" might otherwise imply.
>

Yeah, I have a handful of i686 hardware newer than 2001 that runs pretty
well.

jeff

-- 
Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
___
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/MFVSHYVEJA4KWCHFUTBGIYKD2LFG2KI4/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64


On 06/04/2018 05:55 PM, Jeff Backus wrote:
Would you please provide more detail on what problem or problems we are 
trying to solve? Is this purely for efficiency reasons?


Mainly developer efficiency.  There will be fewer test suite problems 
due to excess precision (a bunch of packages carry patches which 
introduce -ffloat-store on i686 to work around them).  Packagers will 
not have to figure out a way how to build for compatibility with 
non-SSE2 systems (which some upstreams do not support anymore).


Furthermore, the divergence from downstream is troubling to Red Hatters 
for various reasons.  (Red Hat Enterprise Linux 7 already underwent a 
similar change.)


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/PN7J74LU7EOCY5UYPT4UTNSZCN2NWL2S/

Fedora rawhide compose report: 20180604.n.0 changes

2018-06-04 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20180603.n.1
NEW: Fedora-Rawhide-20180604.n.0

= SUMMARY =
Added images:4
Dropped images:  1
Added packages:  0
Dropped packages:0
Upgraded packages:   36
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   700.23 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -30.16 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Python_Classroom vagrant-libvirt i386
Path: 
Labs/i386/images/Fedora-Python-Classroom-Vagrant-Rawhide-20180604.n.0.i386.vagrant-libvirt.box
Image: Python_Classroom vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20180604.n.0.x86_64.vagrant-virtualbox.box
Image: Python_Classroom vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20180604.n.0.x86_64.vagrant-libvirt.box
Image: Python_Classroom vagrant-virtualbox i386
Path: 
Labs/i386/images/Fedora-Python-Classroom-Vagrant-Rawhide-20180604.n.0.i386.vagrant-virtualbox.box

= DROPPED IMAGES =
Image: Container_Minimal_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Minimal-Base-Rawhide-20180603.n.1.aarch64.tar.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  ModemManager-1.8.0-1.fc29
Old package:  ModemManager-1.6.12-3.fc28
Summary:  Mobile broadband modem management service
RPMs: ModemManager ModemManager-devel ModemManager-glib 
ModemManager-glib-devel ModemManager-vala
Size: 11.91 MiB
Size change:  689.31 KiB
Changelog:
  * Tue Apr 24 2018 Lubomir Rintel  - 1.8.0-0.rc2.1
  - Update to 1.8 release candidate 2

  * Sun Jun 03 2018 Lubomir Rintel  - 1.8.0-1
  - Update to 1.8.0 release


Package:  awscli-1.15.31-1.fc29
Old package:  awscli-1.15.28-1.fc29
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 1.05 MiB
Size change:  20 B
Changelog:
  * Sun Jun 03 2018 Kevin Fenzi  - 1.15.31-1
  - Update to 1.15.31. Fixes bug #1583867


Package:  buildah-1.0-17.gitf90b6c0.fc29
Old package:  buildah-1.0-16.git70641ee.fc29
Summary:  A command line tool used for creating OCI Images
RPMs: buildah
Size: 17.59 MiB
Size change:  356 B
Changelog:
  * Mon Jun 04 2018 Lokesh Mandvekar (Bot)  - 
1.0-17.gitf90b6c0
  - autobuilt f90b6c0


Package:  calibre-3.25.0-1.fc29
Old package:  calibre-3.24.2-1.fc29
Summary:  E-book converter and library manager
RPMs: calibre
Size: 206.73 MiB
Size change:  -244.73 KiB
Changelog:
  * Sun Jun 03 2018 Kevin Fenzi  - 3.25.0-1
  - Update to 3.25.0. Fixes bug #1585171


Package:  julia-0.6.3-1.fc29
Old package:  julia-0.6.2-3.fc29
Summary:  High-level, high-performance dynamic language for technical 
computing
RPMs: julia julia-common julia-devel julia-doc
Size: 31.09 MiB
Size change:  -42.08 KiB
Changelog:
  * Sun Jun 03 2018 Milan Bouchet-Valat  - 0.6.3-1
  - New upstream release.


Package:  kf5-baloo-5.47.0-1.fc29
Old package:  kf5-baloo-5.46.0-1.fc29
Summary:  A Tier 3 KDE Frameworks 5 module that provides indexing and 
search functionality
RPMs: kf5-baloo kf5-baloo-devel kf5-baloo-file kf5-baloo-libs
Size: 4.36 MiB
Size change:  268.80 KiB
Changelog:
  * Sat Jun 02 2018 Rex Dieter  - 5.47.0-1
  - 5.47.0


Package:  kf5-frameworkintegration-5.47.0-1.fc29
Old package:  kf5-frameworkintegration-5.46.0-2.fc29
Summary:  KDE Frameworks 5 Tier 4 workspace and cross-framework integration 
plugins
RPMs: kf5-frameworkintegration kf5-frameworkintegration-devel 
kf5-frameworkintegration-libs
Size: 11.30 MiB
Size change:  1.11 KiB
Changelog:
  * Sat Jun 02 2018 Rex Dieter  - 5.47.0-1
  - 5.47.0


Package:  kf5-kactivities-5.47.0-1.fc29
Old package:  kf5-kactivities-5.46.0-1.fc29
Summary:  A KDE Frameworks 5 Tier 3 to organize user work into separate 
activities
RPMs: kf5-kactivities kf5-kactivities-devel kf5-kactivities-libs
Size: 1.31 MiB
Size change:  92.75 KiB
Changelog:
  * Sat Jun 02 2018 Rex Dieter  - 5.47.0-1
  - 5.47.0


Package:  kf5-kactivities-stats-5.47.0-1.fc29
Old package:  kf5-kactivities-stats-5.46.0-1.fc29
Summary:  A KDE Frameworks 5 Tier 3 library for accessing the usage data 
collected by the activities system
RPMs: kf5-kactivities-stats kf5-kactivities-stats-devel
Size: 868.64 KiB
Size change:  36.47 KiB
Changelog:
  * Sat Jun 02 2018 Rex Dieter  - 5.47.0-1
  - 5.47.0


Package:  kf5-kcmutils-5.47.0-1.fc29
Old package:  kf5-kcmutils-5.46.0-1.fc29
Summary:  KDE Frameworks 5 Tier 3 addon with extra API to write 
KConfigModules
RPMs: kf5-kcmutils kf5-kcmutils-devel
Size: 2.31 MiB
Size change:  40.14 KiB
Changelog:
  * Sat Jun 02 2018 Rex Dieter  - 5.47.0-1
  - 5.47.0


Package:  kf5-kdeclarative-5.47.0-1.fc29
Old package:  kf5-kdeclarative

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Emmanuel Seyman

* Chris Adams [04/06/2018 10:58] :
>
> I think you are missing a some of The Atom chips that are 32-bit only;
> there are versions that were released as late as 2010 that don't support
> 64-bit (I don't know when they were discontinued).

You're thinking of the Lincroft series of Intel CPUs:
http://www.cpu-world.com/CPUs/Atom/Intel-Atom%20Z650%20AY80609007296AA.html
http://www.cpu-world.com/CPUs/Atom/Intel-Atom%20Z670%20AY80609007293AA.html

They were introduced in 2011 and EOL-ed in 2013.

Emmanuel
___
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/WMM6HM4V6FYBNMZ5BYLJWZLFWLAKO4EP/

Re: F29 System Wide Change: Hide the grub menu

2018-06-04 Thread Chris Murphy

On Mon, Jun 4, 2018 at 1:22 AM, Till Maas  wrote:

>
> My proposal was for the instructions to recommend pressing a certain key
> but still accepting any key in grub, then there is no lie, since "Press
> space to enter grub" is still true when other keys allow the same.

I'm still not a fan because it's not accurate. But it isn't terrible
and isn't a hill I'm gonna die on.



>> >Also it would be awesome if it was still possible to easily
>> > reboot to grub after the kernel took over, e.g. from the harddisk
>> > password screen, GDM login screen and Gnome logout dialog. Then you can
>> > just make it user-friendly and obvious.
>>
>> password screen is a plymouth feature request; from what I'm looking
>> at gdm login and gnome logout dialog both have a restart option which
>> gets me back to GRUB so I'm not following what different behavior
>> you're proposing.
>
> My idea was to not have a short timeout when a user selects "Reboot to
> Bootloader" (to be implemented) as restart option, so that user do not
> have to fiddle with pressing the right key at the right time when they
> already know I want to get to the grub menu. Also when they missed the
> right time during boot, plymouth could recognise this, make sure the
> grub menu will be shown without a short timeout in the next boot and
> reboot.

Agreed but there are more options possible to help the user avoid the
mess that is keyboard shortcuts for firmware and bootloader:


Reboot to bootloader
Reboot to firmware setup
Reboot to macOS/Windows (upon detection one of those exists)




-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/6HJ4ZVVQY4QLPAAHQTP5C5H2TAUFDBCU/

Re: F29 System Wide Change: Hide the grub menu

2018-06-04 Thread Przemek Klosowski

On 05/31/2018 04:54 PM, Jason L Tibbitts III wrote:

Plus, there's an upside: if you're hammering F11 or F8 or F12 or Esc or
whatever to try and get into the BIOS, and you miss it, then at least
you stop in grub instead of going straight into the OS.

A big part of the 'dark pattern' of the current boot process is that
there is rarely a feedback for all those keystroke events. We are
conditioned to go full Rachmaninoff on the keyboard---I usually try to
play chords and/or crescendos of Escape, F2, F8, F9 and F12.

Recent DELL BIOS/EFI firmware flashes short announcements ('Press F2 for
system configuration') and acknowledges seeing keystrokes ("Entering
boot selection menu"). Even though the response is not very real-time,
it's still a big improvement over the old "typing into the dark and
hoping something happens".

It would be a step forward if the proposed new boot process printed out
a message as soon as it saw something important happen, e.g.

"F12 key pressed; entering boot selection menu. Other keys include F8
for ... and Esc for ..."

"Previous OS boot incomplete or unsuccessful; entering boot selection menu"

"Unrecognized key pressed. Valid boot selection keys include F12 (boot
selection), F8 (...) ..."

___
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/4C2PBRCQC6YUCYMF3WDH2ZYSYGEGZASA/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 4, 2018 at 12:11 PM, Florian Weimer  wrote:

> On 06/04/2018 05:55 PM, Jeff Backus wrote:
>
>> Would you please provide more detail on what problem or problems we are
>> trying to solve? Is this purely for efficiency reasons?
>>
>
> Mainly developer efficiency.  There will be fewer test suite problems due
> to excess precision (a bunch of packages carry patches which introduce
> -ffloat-store on i686 to work around them).  Packagers will not have to
> figure out a way how to build for compatibility with non-SSE2 systems
> (which some upstreams do not support anymore).
>
> Furthermore, the divergence from downstream is troubling to Red Hatters
> for various reasons.  (Red Hat Enterprise Linux 7 already underwent a
> similar change.)
>
>
Thanks for the insight. Yes, I can see the advantages. However, have things
really gotten so bad that it justifies ejecting part of the community? Yes,
a minor part of the community, but a part of the community none the less.
As you mentioned, the excess precision issue has a known work around. And
for packages where upstream does not support non-SSE2, packagers can raise
a flag with the x86 SIG. If there isn't enough interest or bandwidth to add
support for non-SSE2 systems, then I think it is perfectly reasonable to
add a note in the package description and move on. I believe packages such
as Dark Table already do this?

Until (unless?) we have data indicating that this is a major drain on
community resources, I'd push back on a change that actively excludes part
of the community. Now, if we do have data indicating that supporting
non-SSE2 systems with the i686 architecture is a not-insignificant burden
on the community, then I ask that this proposal be updated to include a
solution that allows us to not push out part of the community, e.g. Ajax's
i586 suggestion.

Not trying to be quarrelsome. I understand the desire to focus efforts,
however, I hope we can also appreciate the concerns of those of us with
currently supported hardware that would be affected by this proposal.

jeff

-- 
Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
___
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/3K3SWOKJHZNRIVYN2WWASDSLVBZLQCBJ/

Re: Introduction

On Mon, Jun 04, 2018 at 09:21:22AM +0200, Lukáš Tyrychtr wrote:
> My name is Lukáš Tyrychtr and i am a student currently having an
> intership at Red Hat. The objective of the internship is mainly
> fixing accessibility bugs and overall improving the situation in
> Fedora, so in the future you can expect some work in this regard,
> currently i am working on a complete rewrite of the packages for the
> Festival speech synthesis system.


Welcome Lukáš, and thanks for your work on this!

-- 
Matthew Miller

Fedora Project Leader
___
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/ZG2POP674HBTEHP7VYPNYCJNYH2FVECC/

xpa license change

2018-06-04 Thread Sergio Pascual

The license in xpa has changed from LGPLv2+ in version 2.1.15 to MIT in xpa
2.1.18

Regards, Sergio
___
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/GSN2MSQRTH5RZ2ZLVMOVHNQMYAKFZYE4/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Rex Dieter

Jeff Backus wrote:


> Until (unless?) we have data indicating that this is a major drain on
> community resources, I'd push back on a change that actively excludes part
> of the community. Now, if we do have data indicating that supporting
> non-SSE2 systems with the i686 architecture is a not-insignificant burden
> on the community, then I ask that this proposal be updated to include a
> solution that allows us to not push out part of the community, e.g. Ajax's
> i586 suggestion.

Fwiw, Qt5 officially doesn't support non-sse2 systems either.  kde-sig has 
had to carry patches/hacks to make it work (or at least be buildable), but 
I'd love to be able to not have to do that anymore.

-- Rex
___
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/ZLCNHV7UX5HKAIRW763U5ECPW6AKEH3E/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Josh Boyer

On Mon, Jun 4, 2018 at 12:55 PM Jeff Backus  wrote:
>
>
>
> On Mon, Jun 4, 2018 at 12:11 PM, Florian Weimer  wrote:
>>
>> On 06/04/2018 05:55 PM, Jeff Backus wrote:
>>>
>>> Would you please provide more detail on what problem or problems we are 
>>> trying to solve? Is this purely for efficiency reasons?
>>
>>
>> Mainly developer efficiency.  There will be fewer test suite problems due to 
>> excess precision (a bunch of packages carry patches which introduce 
>> -ffloat-store on i686 to work around them).  Packagers will not have to 
>> figure out a way how to build for compatibility with non-SSE2 systems (which 
>> some upstreams do not support anymore).
>>
>> Furthermore, the divergence from downstream is troubling to Red Hatters for 
>> various reasons.  (Red Hat Enterprise Linux 7 already underwent a similar 
>> change.)
>>
>
> Thanks for the insight. Yes, I can see the advantages. However, have things 
> really gotten so bad that it justifies ejecting part of the community? Yes, a 
> minor part of the community, but a part of the community none the less. As 
> you mentioned, the excess precision issue has a known work around. And for 
> packages where upstream does not support non-SSE2, packagers can raise a flag 
> with the x86 SIG. If there isn't enough interest or bandwidth to add support 
> for non-SSE2 systems, then I think it is perfectly reasonable to add a note 
> in the package description and move on. I believe packages such as Dark Table 
> already do this?

You're describing the status quo today.

> Until (unless?) we have data indicating that this is a major drain on 
> community resources, I'd push back on a change that actively excludes part of 
> the community. Now, if we do have data indicating that supporting non-SSE2 
> systems with the i686 architecture is a not-insignificant burden on the 
> community, then I ask that this proposal be updated to include a solution 
> that allows us to not push out part of the community, e.g. Ajax's i586 
> suggestion.

How about data that indicates it's less performant for other usecase
applications?  There are a number of situations where 32-bit binaries
would possibly be preferable, such as limited memory VMs, etc.
However, because the tuning is aimed at hardware that is so old, the
performance is worse.  Or if we're looking at multi-lib situations,
what if a 32-bit application that requires a 32-bit library happens to
be built with SSE2 enabled?  The application can benefit from the
hardware, but the libraries the OS provides cannot.  That is an odd
mix.

At some point in time, a determination needs to be made on when to
move on and take advantage of advances in computing hardware.
Continuing to not leverage newer 32-bit hardware seems folly.

> Not trying to be quarrelsome. I understand the desire to focus efforts, 
> however, I hope we can also appreciate the concerns of those of us with 
> currently supported hardware that would be affected by this proposal.

We should really stop using the word "support" here.  It implies that
an entity, the Fedora project in this case, is responsible for keeping
it working or treating it as a regression if it does not work.  That
is not an accurate description of the situation.  We should talk about
i686 hardware as community maintained, which implies the onus is on
those that want it to work to get it to work.  One could say "but
Fedora is a community project" and they'd be completely correct but
"support" has too much baggage to use with Fedora in general.

josh
___
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/WXCZSJGNHTGNASALYGZSD2CDCUZH3SRD/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 04, 2018 at 04:04:30PM +0200, Florian Weimer wrote:
> >>only addition over the i686/Pentium Pro baseline is a requirement to
> >>support long NOPs, for Intel CET.  However, the majority of
> >>installations of i686 packages is for use on x86_64 systems, as
> >>multi-lib RPMs.
> >Based on what data?
> The mirror data I've seen, but it's really outdated at this point.

There are currently about 275,000 IP address checking in with x86_64
systems every day. and 25,000 x86_32. So it's about 11:1.

However, that includes systems going back to FC6; if we looked at just
recent releases it'd be even more tilted. (I don't have a quick way to
break that out at my fingertips, but could ask for it if it's really
helpful.)

-- 
Matthew Miller

Fedora Project Leader
___
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/IAO2TJVPNUNEZF33CTQUKNDKSAT35WZI/

Re: Introduction

2018-06-04 Thread Lukáš Tyrychtr


Hi and thank you. :)

L. T.

Dne 04.06.2018 v 18:55 Matthew Miller napsal(a):

On Mon, Jun 04, 2018 at 09:21:22AM +0200, Lukáš Tyrychtr wrote:

My name is Lukáš Tyrychtr and i am a student currently having an
intership at Red Hat. The objective of the internship is mainly
fixing accessibility bugs and overall improving the situation in
Fedora, so in the future you can expect some work in this regard,
currently i am working on a complete rewrite of the packages for the
Festival speech synthesis system.


Welcome Lukáš, and thanks for your work on this!


___
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/GTRYYMRBLQTEAWN7HEFKDIJIXCNAAAI7/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 04, 2018 at 02:01:13PM -0400, Matthew Miller wrote:
> > >>support long NOPs, for Intel CET.  However, the majority of
> > >>installations of i686 packages is for use on x86_64 systems, as
> > >>multi-lib RPMs.
> > >Based on what data?
> > The mirror data I've seen, but it's really outdated at this point.
> There are currently about 275,000 IP address checking in with x86_64
> systems every day. and 25,000 x86_32. So it's about 11:1.

Here's a breakdown as arch percentage over time:

https://twitter.com/mattdm/status/1003701941724172295

Looks like the 50:50 point was about five years ago.

-- 
Matthew Miller

Fedora Project Leader
___
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/UQFO6ET7IHYYXJIMF2CCYR3OKEBTGK4Q/

Re: equivalent of Debian config-package?

2018-06-04 Thread Dave Love

You wrote: 

> I think generally the Fedora/RH-ecosystem answer is to use Ansible for
> configuration, rather than configuration packages.
>
> That's not sayin' there can't be another answer, but in general that's
> the route *I'd* take to solve this problem on my systems.

I guess we disagree about what the problem is, but it's unfortunate if
Fedora/RH isn't interested in the sort of environment for which
config-package was developed.
___
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/WASK32G3OQEWODPV44O3HL7VNXHZOSPR/

Re: equivalent of Debian config-package?

2018-06-04 Thread Dave Love

You wrote: 

> Neal Gompa wrote:
>> No such thing currently exists, because an equivalent to `dpkg-divert`
>> does not exist in RPM.
>
> You are probably aware of this, but for the other readers of this thread:

I wasn't anyhow, thanks!

> File triggers can be (ab)used to do something like that, though it's not as 
> easy as running a `dpkg-divert` command, you have to build a dummy package 
> with a file trigger that munges the file.

Unfortunately they're not available on RHEL, which is the main target of
interest.
___
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/DG6C4OFKE4Q52HTGD5NOCRV7GDAIPYND/

Re: equivalent of Debian config-package?

2018-06-04 Thread Josh Boyer

On Mon, Jun 4, 2018 at 2:29 PM Dave Love  wrote:
>
> You wrote:
>
> > I think generally the Fedora/RH-ecosystem answer is to use Ansible for
> > configuration, rather than configuration packages.
> >
> > That's not sayin' there can't be another answer, but in general that's
> > the route *I'd* take to solve this problem on my systems.
>
> I guess we disagree about what the problem is, but it's unfortunate if
> Fedora/RH isn't interested in the sort of environment for which
> config-package was developed.

Can you elaborate more on what that environment is?  I read the
website you linked to, but I still don't understand how this wouldn't
be similarly solved with Ansible.

josh
___
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/L3B3VQSD5GL3PPQG67G3VR2EHQ3IX5UO/

Re: F29 System Wide Change: Strong crypto settings: phase 2

2018-06-04 Thread Adam Williamson

On Fri, 2018-06-01 at 13:40 +0200, Jan Kurik wrote:
> = Proposed System Wide Change: Strong crypto settings: phase 2 =
> https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2

The "how to test" section for this Change seems a little worryingly
barebones:

"Applications which follow the system-wide policy (e.g., curl,wget)
should be tested:

* whether they can connect to legacy (TLS1.0, TLS1.1) servers when
system is in legacy mode
* whether the previous connection breaks when system is in default mode
* whether the system can connect to TLS 1.2 servers when in default,
legacy or future mode."

That "e.g., curl,wget" especially is pretty slapdash. We (QA) would
suggest it's incumbent on the Change owners here to do a better job of
identifying things that respect the system-wide policy, especially
considering release-critical components. For instance, does Firefox
respect the policy? I believe the answer is "yes", but this should be
something the Change owners look into. For another instance, do
components of FreeIPA respect the policy, and if so, have we considered
how this will affect those when e.g. an F29 system is enrolled as a
member of a FreeIPA domain where the server is running on an older
Fedora, or RHEL, or something?

How about clients for networking with other OSes - e.g. Samba clients,
and the tools for enrolling systems as Active Directory domain members?
Do those respect the system policy? If so, have we considered the
impact of these changes on those configurations?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/Q6WUF2FGZCRUOCGUI3R7FWC2AZGXA2TI/

Fedora Rawhide-20180604.n.0 compose check report

2018-06-04 Thread Fedora compose checker

No missing expected images.

Failed openQA tests: 12/137 (x86_64), 5/24 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20180603.n.1):

ID: 244870  Test: x86_64 universal install_blivet_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/244870

Old failures (same test failed in Rawhide-20180603.n.1):

ID: 244825  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/244825
ID: 244826  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/244826
ID: 244827  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/244827
ID: 244828  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/244828
ID: 244829  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/244829
ID: 244831  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/244831
ID: 244840  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/244840
ID: 244841  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/244841
ID: 244874  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/244874
ID: 244890  Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/244890
ID: 244899  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/244899
ID: 244904  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/244904
ID: 244913  Test: x86_64 universal install_multi_empty@uefi
URL: https://openqa.fedoraproject.org/tests/244913
ID: 244915  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/244915
ID: 244919  Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/244919
ID: 244937  Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/244937
ID: 244938  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/244938

Soft failed openQA tests: 4/137 (x86_64), 2/24 (i386)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Rawhide-20180603.n.1):

ID: 244802  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/244802
ID: 244803  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/244803
ID: 244804  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/244804
ID: 244856  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/244856
ID: 244907  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/244907
ID: 244908  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/244908

Passed openQA tests: 110/137 (x86_64), 17/24 (i386)

New passes (same test did not pass in Rawhide-20180603.n.1):

ID: 244781  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/244781
ID: 244810  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/244810
ID: 244920  Test: x86_64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/244920

Skipped openQA tests: 12 of 163

Installed system changes in test x86_64 Server-boot-iso install_default: 
1 packages(s) added since previous compose: lmdb-libs
1 packages(s) removed since previous compose: nss-pem
Previous test data: https://openqa.fedoraproject.org/tests/244518#downloads
Current test data: https://openqa.fedoraproject.org/tests/244780#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
System load changed from 1.59 to 1.47
Previous test data: https://openqa.fedoraproject.org/tests/244522#downloads
Current test data: https://openqa.fedoraproject.org/tests/244784#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
System load changed from 1.80 to 1.14
Previous test data: https://openqa.fedoraproject.org/tests/244524#downloads
Current test data: https://openqa.fedoraproject.org/tests/244786#downloads

Installed system changes in test i386 Server-boot-iso install_default: 
1 packages(s) removed since previous compose: nss-pem
Previous test data: https://openqa.fedoraproject.org/tests/244541#downloads
Current test data: https://openqa.fedoraproject.org/tests/244803#downloads

Installed system changes in test i386 Server-dvd-iso install_default: 
System load changed from 0.28 to 0.11
Previous test data: https://openqa.fedoraproject.org/

Re: F29 System Wide Change: Hide the grub menu

2018-06-04 Thread Adam Williamson

On Thu, 2018-05-31 at 12:43 +0200, Jan Kurik wrote:
> = Proposed System Wide Change: Hide the grub menu =
> https://fedoraproject.org/wiki/Changes/HiddenGrubMenu

We (QA) would like to note that the "How to test" section of this
Change seems heavily under-developed:

"1. Install Fedora in a fresh vm or select reclaim diskspace -> delete
all in the installer (od a single os install).
2. Boot the system the grub menu should not show
3. (Re)boot press F8 repeatedly when the firmware / vendor logo shows,
you should now get the grub menu"

I mean, that doesn't even consider testing that the change is *not*
applied when doing a "multi OS" install, which is explicitly part of
the Change. As a *bare minimum*, that needs to be covered.

It also doesn't cover other situations. One brought up at our QA
meeting was - what happens if you install Fedora first and then another
Linux distribution second?

The Change as a whole doesn't seem to consider what should happen in
this case, which seems like an omission; obviously if there *is* an
expected outcome in this case, the "How to test" section should cover
testing it.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/TBT36IKLIGGOUHXEWZ4W7BB6CKXHKUF2/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 4, 2018 at 1:46 PM, Josh Boyer 
wrote:

> On Mon, Jun 4, 2018 at 12:55 PM Jeff Backus  wrote:
> >
> >
> >
> > On Mon, Jun 4, 2018 at 12:11 PM, Florian Weimer 
> wrote:
> >>
> >> On 06/04/2018 05:55 PM, Jeff Backus wrote:
> >>>
> >>> Would you please provide more detail on what problem or problems we
> are trying to solve? Is this purely for efficiency reasons?
> >>
> >>
> >> Mainly developer efficiency.  There will be fewer test suite problems
> due to excess precision (a bunch of packages carry patches which introduce
> -ffloat-store on i686 to work around them).  Packagers will not have to
> figure out a way how to build for compatibility with non-SSE2 systems
> (which some upstreams do not support anymore).
> >>
> >> Furthermore, the divergence from downstream is troubling to Red Hatters
> for various reasons.  (Red Hat Enterprise Linux 7 already underwent a
> similar change.)
> >>
> >
> > Thanks for the insight. Yes, I can see the advantages. However, have
> things really gotten so bad that it justifies ejecting part of the
> community? Yes, a minor part of the community, but a part of the community
> none the less. As you mentioned, the excess precision issue has a known
> work around. And for packages where upstream does not support non-SSE2,
> packagers can raise a flag with the x86 SIG. If there isn't enough interest
> or bandwidth to add support for non-SSE2 systems, then I think it is
> perfectly reasonable to add a note in the package description and move on.
> I believe packages such as Dark Table already do this?
>
> You're describing the status quo today.
>

Yes, I am arguing in favor of the status quo.


>
> > Until (unless?) we have data indicating that this is a major drain on
> community resources, I'd push back on a change that actively excludes part
> of the community. Now, if we do have data indicating that supporting
> non-SSE2 systems with the i686 architecture is a not-insignificant burden
> on the community, then I ask that this proposal be updated to include a
> solution that allows us to not push out part of the community, e.g. Ajax's
> i586 suggestion.
>
> How about data that indicates it's less performant for other usecase
> applications?  There are a number of situations where 32-bit binaries
> would possibly be preferable, such as limited memory VMs, etc.
> However, because the tuning is aimed at hardware that is so old, the
> performance is worse.  Or if we're looking at multi-lib situations,
> what if a 32-bit application that requires a 32-bit library happens to
> be built with SSE2 enabled?  The application can benefit from the
> hardware, but the libraries the OS provides cannot.  That is an odd
> mix.
>

I agree that this is a valid use case. The i586 arch would be reasonable
compromise, depending on the amount of effort required to split i686.


>
> At some point in time, a determination needs to be made on when to
> move on and take advantage of advances in computing hardware.
> Continuing to not leverage newer 32-bit hardware seems folly.
>

Agreed. I'm just arguing for choosing a path that excludes as few users as
possible.


>
> > Not trying to be quarrelsome. I understand the desire to focus efforts,
> however, I hope we can also appreciate the concerns of those of us with
> currently supported hardware that would be affected by this proposal.
>
> We should really stop using the word "support" here.  It implies that
> an entity, the Fedora project in this case, is responsible for keeping
> it working or treating it as a regression if it does not work.  That
> is not an accurate description of the situation.  We should talk about
> i686 hardware as community maintained, which implies the onus is on
> those that want it to work to get it to work.  One could say "but
> Fedora is a community project" and they'd be completely correct but
> "support" has too much baggage to use with Fedora in general.
>
>
Good point, and, yes, I should have used a more precise term. Secondary
arches definitely fall under the purview of 'community maintained'. I stand
corrected.

jeff


-- 
Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
___
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/2ZHT6DR7O4VXMJB55I7M64KYLVHCYY4W/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 4, 2018 at 1:45 PM, Rex Dieter  wrote:

> Jeff Backus wrote:
>
>
> > Until (unless?) we have data indicating that this is a major drain on
> > community resources, I'd push back on a change that actively excludes
> part
> > of the community. Now, if we do have data indicating that supporting
> > non-SSE2 systems with the i686 architecture is a not-insignificant burden
> > on the community, then I ask that this proposal be updated to include a
> > solution that allows us to not push out part of the community, e.g.
> Ajax's
> > i586 suggestion.
>
> Fwiw, Qt5 officially doesn't support non-sse2 systems either.  kde-sig has
> had to carry patches/hacks to make it work (or at least be buildable), but
> I'd love to be able to not have to do that anymore.
>
>
Hmm.. Yes, we've had discussions within the SIG re: window managers that
support i586/i686, and KDE was on the list of WMs that no longer support
our target system. Do these patches/hacks only apply to KDE or do they
apply to Qt in general?

jeff

-- 
Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
___
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/OROU4NJTSJELPTGQ4GNUTTCZGFNFVB4I/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 4, 2018 at 2:01 PM, Matthew Miller 
wrote:

> On Mon, Jun 04, 2018 at 04:04:30PM +0200, Florian Weimer wrote:
> > >>only addition over the i686/Pentium Pro baseline is a requirement to
> > >>support long NOPs, for Intel CET.  However, the majority of
> > >>installations of i686 packages is for use on x86_64 systems, as
> > >>multi-lib RPMs.
> > >Based on what data?
> > The mirror data I've seen, but it's really outdated at this point.
>
> There are currently about 275,000 IP address checking in with x86_64
> systems every day. and 25,000 x86_32. So it's about 11:1.
>
> However, that includes systems going back to FC6; if we looked at just
> recent releases it'd be even more tilted. (I don't have a quick way to
> break that out at my fingertips, but could ask for it if it's really
> helpful.)
>

Thanks for the data. 25k is still a pretty healthy number. :) I realize
that there are a lot of unknowns in the data, so it is difficult to draw
any hard conclusions, but 25k is still much larger than 0. Splitting into
i686 into i586 and i686 would give more insight into who still needs
non-SSE2... Probably hurts my argument, though. :)

jeff

-- 
Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
___
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/VRNHT4KNFXRAQ6CTN6NCD6OZLXE45XR6/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Stephen John Smoogen

On 4 June 2018 at 14:18, Matthew Miller  wrote:
> On Mon, Jun 04, 2018 at 02:01:13PM -0400, Matthew Miller wrote:
>> > >>support long NOPs, for Intel CET.  However, the majority of
>> > >>installations of i686 packages is for use on x86_64 systems, as
>> > >>multi-lib RPMs.
>> > >Based on what data?
>> > The mirror data I've seen, but it's really outdated at this point.
>> There are currently about 275,000 IP address checking in with x86_64
>> systems every day. and 25,000 x86_32. So it's about 11:1.
>
> Here's a breakdown as arch percentage over time:
>
> https://twitter.com/mattdm/status/1003701941724172295
>
> Looks like the 50:50 point was about five years ago.
>

For F26,F27,F28 for the first 150 days of the year:

Days:  150
X86_32: 3769.4 avg/day
X86_64: 159540 avg/day
Ratio (32/64) 0.0236267 (1:42)

The reason is that the majority of i386 users are not moving off of
dead/old releases. For the month of May

Avg/day release
28623.7 epel6
16009.2 epel5
4043.37 f25
3318.53 f20
2759.2 f08
2127.8 f23
1589.63 f27
1401.7 f22
1371 f26
1277.53 f21
1056.33 f28
874.2 f24
733.8 f14
562.533 f19
509.067 f11

In comparison, x86_64 is mostly living on the latest release:
[smooge@data-analysis01 mirrors]$ grep '^2018-05-.* x86_64' out-2018
| awk '{print $3}' | sort | uniq -c | sort -bnr | head -n 15 | awk
'{print $1/30, $2}'
671455 epel7
605436 epel6
87367.4 f27
60159.7 f28
37857.6 epel5
34421.4 f26
27011 f25
19115.4 f23
14292.2 f24
8627.47 f22
6603.3 f20
5863.47 f21
1413.37 modular_f28
1091.87 f19
868.833 f18

The 30 is because only 30 days of May have been analyzed. [And yes
there are still many Fedora 08 systems showing up for x86_32]

Personally I think the number of those systems which are running
Pentium III hardware with the latest OS are probably already on this
mailing list.. I expect that they would also be looking at only
needing to support a small subset of the software since running
GNOME/KDE with usually 128->512 MB of RAM is not possible. It also
would probably want a very stripped down installer since anaconda is
aimed at 'current' hardware... probably something like the images that
ARM-32 makes.



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/CKOZSPOK63LLQK5MOVV6J4JX4COYI7XK/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 4, 2018 at 2:18 PM, Matthew Miller 
wrote:

> On Mon, Jun 04, 2018 at 02:01:13PM -0400, Matthew Miller wrote:
> > > >>support long NOPs, for Intel CET.  However, the majority of
> > > >>installations of i686 packages is for use on x86_64 systems, as
> > > >>multi-lib RPMs.
> > > >Based on what data?
> > > The mirror data I've seen, but it's really outdated at this point.
> > There are currently about 275,000 IP address checking in with x86_64
> > systems every day. and 25,000 x86_32. So it's about 11:1.
>
> Here's a breakdown as arch percentage over time:
>
> https://twitter.com/mattdm/status/1003701941724172295
>
> Looks like the 50:50 point was about five years ago.
>

Thanks! Very helpful to see x86_32 compared to ARM. Trajectory is very
important, but laying that aside, x86_32 a) significantly larger than both
ARM arches combined, and b) roughly 10% of the "user base".

jeff

-- 
Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
___
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/U5NQTR3ILSAD4XCQJ2N2O33FZFYYHK2U/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Michael Cronenworth


On 06/04/2018 02:50 PM, Jeff Backus wrote:
Thanks for the data. 25k is still a pretty healthy number. :) I realize that there 
are a lot of unknowns in the data, so it is difficult to draw any hard 
conclusions, but 25k is still much larger than 0. Splitting into i686 into i586 
and i686 would give more insight into who still needs non-SSE2... Probably hurts 
my argument, though. :)




Jeff,

If you want to do the work involved to split up the 32-bit arches please do it.

The discussion going on here is not a democratic vote on if non-x86_64 CPUs are 
supported. :)


Thanks,
Michael
___
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/KKS3QTVPVGWGE4QG2YI7ES2J5P3GSKBG/

Re: [X86] Re: Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 4, 2018 at 3:53 PM, Stephen John Smoogen 
wrote:

> On 4 June 2018 at 14:18, Matthew Miller  wrote:
> > On Mon, Jun 04, 2018 at 02:01:13PM -0400, Matthew Miller wrote:
> >> > >>support long NOPs, for Intel CET.  However, the majority of
> >> > >>installations of i686 packages is for use on x86_64 systems, as
> >> > >>multi-lib RPMs.
> >> > >Based on what data?
> >> > The mirror data I've seen, but it's really outdated at this point.
> >> There are currently about 275,000 IP address checking in with x86_64
> >> systems every day. and 25,000 x86_32. So it's about 11:1.
> >
> > Here's a breakdown as arch percentage over time:
> >
> > https://twitter.com/mattdm/status/1003701941724172295
> >
> > Looks like the 50:50 point was about five years ago.
> >
>
> For F26,F27,F28 for the first 150 days of the year:
>
> Days:  150
> X86_32: 3769.4 avg/day
> X86_64: 159540 avg/day
> Ratio (32/64) 0.0236267 (1:42)
>
> The reason is that the majority of i386 users are not moving off of
> dead/old releases. For the month of May
>
> Avg/day release
> 28623.7 epel6
> 16009.2 epel5
> 4043.37 f25
> 3318.53 f20
> 2759.2 f08
> 2127.8 f23
> 1589.63 f27
> 1401.7 f22
> 1371 f26
> 1277.53 f21
> 1056.33 f28
> 874.2 f24
> 733.8 f14
> 562.533 f19
> 509.067 f11
>
> In comparison, x86_64 is mostly living on the latest release:
> [smooge@data-analysis01 mirrors]$ grep '^2018-05-.* x86_64' out-2018
> | awk '{print $3}' | sort | uniq -c | sort -bnr | head -n 15 | awk
> '{print $1/30, $2}'
> 671455 epel7
> 605436 epel6
> 87367.4 f27
> 60159.7 f28
> 37857.6 epel5
> 34421.4 f26
> 27011 f25
> 19115.4 f23
> 14292.2 f24
> 8627.47 f22
> 6603.3 f20
> 5863.47 f21
> 1413.37 modular_f28
> 1091.87 f19
> 868.833 f18
>
> The 30 is because only 30 days of May have been analyzed. [And yes
> there are still many Fedora 08 systems showing up for x86_32]
>
> Personally I think the number of those systems which are running
> Pentium III hardware with the latest OS are probably already on this
> mailing list.. I expect that they would also be looking at only
> needing to support a small subset of the software since running
> GNOME/KDE with usually 128->512 MB of RAM is not possible. It also
> would probably want a very stripped down installer since anaconda is
> aimed at 'current' hardware... probably something like the images that
> ARM-32 makes.
>

Very good point!

And wow! Fedora 08 was quite some time ago... :)

-- 
Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
___
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/DZW44V5B32MCO7AKTBSMT3HMTKRQRKTF/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 4, 2018 at 4:00 PM, Michael Cronenworth  wrote:

> On 06/04/2018 02:50 PM, Jeff Backus wrote:
>
>> Thanks for the data. 25k is still a pretty healthy number. :) I realize
>> that there are a lot of unknowns in the data, so it is difficult to draw
>> any hard conclusions, but 25k is still much larger than 0. Splitting into
>> i686 into i586 and i686 would give more insight into who still needs
>> non-SSE2... Probably hurts my argument, though. :)
>>
>>
> Jeff,
>
> If you want to do the work involved to split up the 32-bit arches please
> do it.
>
> The discussion going on here is not a democratic vote on if non-x86_64
> CPUs are supported. :)
>
>
Fair point. :)

-- 
Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
___
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/WNMZXU23ME5KYXO4B77HLKSLUJUEBIBL/

Re: equivalent of Debian config-package?

2018-06-04 Thread Stephen John Smoogen

On 4 June 2018 at 14:29, Dave Love  wrote:
> You wrote:
>
>> I think generally the Fedora/RH-ecosystem answer is to use Ansible for
>> configuration, rather than configuration packages.
>>
>> That's not sayin' there can't be another answer, but in general that's
>> the route *I'd* take to solve this problem on my systems.
>
> I guess we disagree about what the problem is, but it's unfortunate if
> Fedora/RH isn't interested in the sort of environment for which
> config-package was developed.

1. Do not strip out who you are replying to. There are hundreds of
people on this list and people come in at different times... and I am
not sure who "You" was.
2. Saying that Fedora/RH isn't interested by 1-2 comments is like me
walking into Debian lists getting 1 person saying "noone would ever
use Ansible" and assuming they speak for all of Debian.
3. There are people who do system management by rpm as can be seen by
various emails. Even Red Hat does so for the deployment of in the
field laptops who aren't getting regular checkins for a puppet or
ansible to work on.
4. System administration/configuration management is 99% "I have a
solution I endure and I don't have time to re-engineer it." and 1% "Oh
I think I want to write my own configuration management toolkit
because I can't endure what I am doing now." You are going to get
pushback from any site you are proposing this to until you show it is
useful for them.

So let us roll this discussion back a bit. There isn't an existing
system to do this. Most sites I have worked with roll their own using
different amounts of cron, config files, scripts in /usr/local/sbin
and rpms with %post/%pre and lots of %triggers. The ones who do this
would probably enjoy a tool which automated most of this work for
them, but they are all expecting someone else to write it for them.
And then because these solutions (even the Debian one) can go wrong
badly.. they are hesitant to use some other one until they see it
works.

-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/B26CFSANPZKFFMS7IU6W7OWMNYAKA2K6/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Rex Dieter

Jeff Backus wrote:

> On Mon, Jun 4, 2018 at 1:45 PM, Rex Dieter  wrote:
> 
>> Jeff Backus wrote:
>>
>>
>> > Until (unless?) we have data indicating that this is a major drain on
>> > community resources, I'd push back on a change that actively excludes
>> part
>> > of the community. Now, if we do have data indicating that supporting
>> > non-SSE2 systems with the i686 architecture is a not-insignificant
>> > burden on the community, then I ask that this proposal be updated to
>> > include a solution that allows us to not push out part of the
>> > community, e.g.
>> Ajax's
>> > i586 suggestion.
>>
>> Fwiw, Qt5 officially doesn't support non-sse2 systems either.  kde-sig
>> has had to carry patches/hacks to make it work (or at least be
>> buildable), but I'd love to be able to not have to do that anymore.
>>
>>
> Hmm.. Yes, we've had discussions within the SIG re: window managers that
> support i586/i686, and KDE was on the list of WMs that no longer support
> our target system. Do these patches/hacks only apply to KDE or do they
> apply to Qt in general?

I'm speaking about Qt5 here

-- Rex

___
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/3MCCFNKJR624URBSLXWESH5S4J35VEDK/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 4, 2018 at 4:41 PM, Rex Dieter  wrote:

> Jeff Backus wrote:
>
> > On Mon, Jun 4, 2018 at 1:45 PM, Rex Dieter  wrote:
> >
> >> Jeff Backus wrote:
> >>
> >>
> >> > Until (unless?) we have data indicating that this is a major drain on
> >> > community resources, I'd push back on a change that actively excludes
> >> part
> >> > of the community. Now, if we do have data indicating that supporting
> >> > non-SSE2 systems with the i686 architecture is a not-insignificant
> >> > burden on the community, then I ask that this proposal be updated to
> >> > include a solution that allows us to not push out part of the
> >> > community, e.g.
> >> Ajax's
> >> > i586 suggestion.
> >>
> >> Fwiw, Qt5 officially doesn't support non-sse2 systems either.  kde-sig
> >> has had to carry patches/hacks to make it work (or at least be
> >> buildable), but I'd love to be able to not have to do that anymore.
> >>
> >>
> > Hmm.. Yes, we've had discussions within the SIG re: window managers that
> > support i586/i686, and KDE was on the list of WMs that no longer support
> > our target system. Do these patches/hacks only apply to KDE or do they
> > apply to Qt in general?
>
> I'm speaking about Qt5 here
>
>
I was afraid of that. I would like to express my heartfelt gratitude to you
and the rest of the KDE-SIG for all of the effort you folks make. :)

-- 
Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
___
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/YSZSH3Y4TOKKED3Z5R4HOFM6VOBCC2VV/

Re: [X86] Re: Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Justin Forbes

On Mon, Jun 4, 2018 at 3:08 PM, Jeff Backus  wrote:
>
>
> On Mon, Jun 4, 2018 at 3:53 PM, Stephen John Smoogen 
> wrote:
>>
>> On 4 June 2018 at 14:18, Matthew Miller  wrote:
>> > On Mon, Jun 04, 2018 at 02:01:13PM -0400, Matthew Miller wrote:
>> >> > >>support long NOPs, for Intel CET.  However, the majority of
>> >> > >>installations of i686 packages is for use on x86_64 systems, as
>> >> > >>multi-lib RPMs.
>> >> > >Based on what data?
>> >> > The mirror data I've seen, but it's really outdated at this point.
>> >> There are currently about 275,000 IP address checking in with x86_64
>> >> systems every day. and 25,000 x86_32. So it's about 11:1.
>> >
>> > Here's a breakdown as arch percentage over time:
>> >
>> > https://twitter.com/mattdm/status/1003701941724172295
>> >
>> > Looks like the 50:50 point was about five years ago.
>> >
>>
>> For F26,F27,F28 for the first 150 days of the year:
>>
>> Days:  150
>> X86_32: 3769.4 avg/day
>> X86_64: 159540 avg/day
>> Ratio (32/64) 0.0236267 (1:42)
>>
>> The reason is that the majority of i386 users are not moving off of
>> dead/old releases. For the month of May
>>
>> Avg/day release
>> 28623.7 epel6
>> 16009.2 epel5
>> 4043.37 f25
>> 3318.53 f20
>> 2759.2 f08
>> 2127.8 f23
>> 1589.63 f27
>> 1401.7 f22
>> 1371 f26
>> 1277.53 f21
>> 1056.33 f28
>> 874.2 f24
>> 733.8 f14
>> 562.533 f19
>> 509.067 f11
>>
>> In comparison, x86_64 is mostly living on the latest release:
>> [smooge@data-analysis01 mirrors]$ grep '^2018-05-.* x86_64' out-2018
>> | awk '{print $3}' | sort | uniq -c | sort -bnr | head -n 15 | awk
>> '{print $1/30, $2}'
>> 671455 epel7
>> 605436 epel6
>> 87367.4 f27
>> 60159.7 f28
>> 37857.6 epel5
>> 34421.4 f26
>> 27011 f25
>> 19115.4 f23
>> 14292.2 f24
>> 8627.47 f22
>> 6603.3 f20
>> 5863.47 f21
>> 1413.37 modular_f28
>> 1091.87 f19
>> 868.833 f18
>>
>> The 30 is because only 30 days of May have been analyzed. [And yes
>> there are still many Fedora 08 systems showing up for x86_32]
>>
>> Personally I think the number of those systems which are running
>> Pentium III hardware with the latest OS are probably already on this
>> mailing list.. I expect that they would also be looking at only
>> needing to support a small subset of the software since running
>> GNOME/KDE with usually 128->512 MB of RAM is not possible. It also
>> would probably want a very stripped down installer since anaconda is
>> aimed at 'current' hardware... probably something like the images that
>> ARM-32 makes.
>
>
> Very good point!
>
> And wow! Fedora 08 was quite some time ago... :)


It was, and it was used as a long time as a base image for VMs
somewhere, which is probably where a lot of those numbers are coming
from. It would be really interesting if we could see a breakdown of VM
vs raw metal, as I am guessing a whole lot of the i686 is VM traffic.
I know I have at least 4 of those VMs per release checking in just for
kernel testing bits.  For a long time there was also a trend of people
running 32bit guests wherever they could to reduce memory footprint.

>
> --
> Jeff Backus
> jeff.bac...@gmail.com
> http://github.com/jsbackus
>
>
> ___
> 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/DZW44V5B32MCO7AKTBSMT3HMTKRQRKTF/
>
___
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/AZA7QEFYYV5X4PJNR3JPQIRAEOBZYHXU/

[Fedocal] Reminder meeting : Modularity Office Hours

2018-06-04 Thread nils

Dear all,

You are kindly invited to the meeting:
   Modularity Office Hours on 2018-06-05 from 10:00:00 to 11:00:00 US/Eastern
   At fedora-modular...@chat.freenode.net

The meeting will be about:
This is where you ask the Fedora Modularity Team questions (and we try to 
answer them)!

Join us on [IRC](irc://chat.freenode.net/#fedora-modularity): 
#fedora-modularity on [FreeNode](https://freenode.net)


Source: https://apps.fedoraproject.org/calendar/meeting/5910/

___
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/NCRNMB7WVE7ZNKXE2G34PPLM4OQEUKVN/

Re: equivalent of Debian config-package?

2018-06-04 Thread devzero2000

Il gio 31 mag 2018, 13:42 Neal Gompa  ha scritto:

> On Thu, May 31, 2018 at 6:54 AM Dave Love 
> wrote:
> >
> > Is there any existing system for rpm like the Debian one
> >  for building local
> > configuration packages?  If not, would it be feasible to implement one?
>
> No such thing currently exists, because an equivalent to `dpkg-divert`
> does not exist in RPM.
>
> It is technically possible to implement such a mechanism, but it does
> not exist right now.
>
> A toy WIP never completed is here :
>

https://github.com/yersinia/rpm-gen-rpm-configuration

>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://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/BMDUJ3ANQG6OJRWBWOOFU72OJ56WVF2G/
>
___
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/ZJVWOABDP3WIZUECMRFVNMBJ7PX5PLUL/

Release criteria proposal: drop kickstart package criterion

2018-06-04 Thread Adam Williamson

Hi, folks!

We currently have a Final release criterion that reads as follows:

"A spin-kickstarts package which contains the exact kickstart files
used to build the release must be present in the release repository.
The included kickstarts must define the correct set of release
repositories.

Why?

This is considered part of Fedora's duty to be 'self-hosting': the
kickstarts used to produce the release images are a vital piece of
information required to duplicate that release, so they must be
preserved along with the release."

Lately this requirement has been fairly annoying in practice. Updating
the package prior to release does not appear to be in anyone's regular
schedule, so invariably what happens is shortly before the release
deadline I realize we haven't built a 'release' spin-kickstarts package
and have to file a blocker bug and ping people with the necessary
permissions (of which there are only a few) to build one in a tearing
hurry. Then we have to approve the blocker bug and push the updated
package through the freeze, all wasting time we could be spending on
more important fixes.

The benefit here is really fairly tiny, as well. It's arguable whether
anyone cares particularly whether a Fedora release, as a frozen
artifact, is 100% internally reproducible (and I'm not sure whether our
releases actually *are* reproducible in any case, these days, I'm not
at all sure we ship all the necessary metadata and so on for *every
single deliverable* within the distribution).

These days I'd suggest it should be quite acceptable to simply use git
tags for this purpose. It should be quite easy for rel-eng to adjust
the release scripts to create a tag in the fedora-kickstarts repo (and
why not fedora-comps too, while we're at it) for each 'candidate'
compose, named for the compose ID. That would make it very easy to
access the correct kickstarts for any Fedora candidate compose just by
a 'git checkout', with no need for the cumbersome work of getting the
package into the compose.

Naturally this would go along with updates to any relevant docs or wiki
pages, recommending to use the git repository instead of the RPM
packages, and explaining the tagging scheme. As for the package, we
could either keep it but not sweat about updating it for each release,
retire it entirely, or change it to contain only a text file pointing
to the git repository (or to the doc / wiki page that explains the git
repo location and tagging strategy).

Thoughts? Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/X4YKEUQYAKLRGEPDJOOIMZNJZMM23CMU/

Re: Release criteria proposal: drop kickstart package criterion

2018-06-04 Thread Peter Robinson

On Tue, Jun 5, 2018 at 12:39 AM, Adam Williamson
 wrote:
> Hi, folks!
>
> We currently have a Final release criterion that reads as follows:
>
> "A spin-kickstarts package which contains the exact kickstart files
> used to build the release must be present in the release repository.
> The included kickstarts must define the correct set of release
> repositories.
>
> Why?
>
> This is considered part of Fedora's duty to be 'self-hosting': the
> kickstarts used to produce the release images are a vital piece of
> information required to duplicate that release, so they must be
> preserved along with the release."
>
> Lately this requirement has been fairly annoying in practice. Updating
> the package prior to release does not appear to be in anyone's regular
> schedule, so invariably what happens is shortly before the release
> deadline I realize we haven't built a 'release' spin-kickstarts package
> and have to file a blocker bug and ping people with the necessary
> permissions (of which there are only a few) to build one in a tearing
> hurry. Then we have to approve the blocker bug and push the updated
> package through the freeze, all wasting time we could be spending on
> more important fixes.
>
> The benefit here is really fairly tiny, as well. It's arguable whether
> anyone cares particularly whether a Fedora release, as a frozen
> artifact, is 100% internally reproducible (and I'm not sure whether our
> releases actually *are* reproducible in any case, these days, I'm not
> at all sure we ship all the necessary metadata and so on for *every
> single deliverable* within the distribution).
>
> These days I'd suggest it should be quite acceptable to simply use git
> tags for this purpose. It should be quite easy for rel-eng to adjust
> the release scripts to create a tag in the fedora-kickstarts repo (and
> why not fedora-comps too, while we're at it) for each 'candidate'
> compose, named for the compose ID. That would make it very easy to
> access the correct kickstarts for any Fedora candidate compose just by
> a 'git checkout', with no need for the cumbersome work of getting the
> package into the compose.
>
> Naturally this would go along with updates to any relevant docs or wiki
> pages, recommending to use the git repository instead of the RPM
> packages, and explaining the tagging scheme. As for the package, we
> could either keep it but not sweat about updating it for each release,
> retire it entirely, or change it to contain only a text file pointing
> to the git repository (or to the doc / wiki page that explains the git
> repo location and tagging strategy).
>
> Thoughts? Thanks!

It makes perfect sense, the package is not actually shipped as part of
any of the actual deliverable artifacts and they're widely available
in a public git repository for people to consume so it's not reducing
the ability to reproduce Fedora, we don't rush around and ensure all
the tools that might need last minute patches in the compose process
are all tagged stable in the release either so I don't see actually
shipping this package as stable makes any difference in reality, we
don't even use the package in the compose process, we pull the
kickstarts directly from git.

Peter
___
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/Z5IKRMU2AKGMCF3FB2WNWVM6ZD2EYTYK/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 04, 2018 at 03:50:34PM -0400, Jeff Backus wrote:
> Thanks for the data. 25k is still a pretty healthy number. :) I realize

Yeah, absolutely. And it's likely that those mirror numbers undercount,
because not every system checks in daily, and then there's also NAT.

But, my gut feeling is that about half of those are not using a current
release _anyway_. Honest question: do you think that 12k would still
count as a healthy number? I mean, it's not peanuts. But maybe it'd be
better served by a Fedora remix (or similar) specifically targetting
older and low-powered systems?

> that there are a lot of unknowns in the data, so it is difficult to draw
> any hard conclusions, but 25k is still much larger than 0. Splitting into
> i686 into i586 and i686 would give more insight into who still needs
> non-SSE2... Probably hurts my argument, though. :)

Soo this is the kind of thing that more a detailed hardware
census could really help us with!

-- 
Matthew Miller

Fedora Project Leader
___
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/TDDINBL32E2UCMD2QDVLGDFZOODH55YD/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64