date:20180621

On Thu, Jun 21, 2018 at 8:53 PM, Kyle Marek  wrote:

> I've noticed that Windows 10 does MBR installs on BIOS, as well. I've
> always found that interesting because I have also found several laptops
> (I think most of them were HP) where the OEM installed a BIOS bootloader
> in addition to the EFI bootloader. My guess is that these OEMs see a
> similar value in being able to boot both BIOS and EFI.

I've seen gdisk -l output from such systems. I've never interacted
with one. The most common OEM "installer" is just an imager. Basically
it's dd'ing an image, so it it includes all the partitioning and
contents of those partitions, it's not like the Microsoft installer.
It might be that the manufacturer used the same image on a couple of
different SKUs where the only difference was whether they had legacy
BIOS enabled. I don't suppose they ever intended to have a flip from
BIOS to UEFI in the field, but maybe?

>> Are you gonna own the feature? :-) Maybe Colin Walters finds it
>> compelling enough to be co-owner?
>
> Can I? I'm a bit new to Fedora development (I don't have a FAS account,
> yet).

Sure. Jump into the deep end. Shout if you need help. Quick like a
bunny though if you want to get it in for Fedora 29.

But definitely start a new separate devel@ thread. This one's
approaching a hijacking. In the new thread you can point out the two
pronged approach, what liabilities there are, solicit liabilities you
haven't thought of. You could cull bugzilla for anaconda and grub2
bugs related to GPT and not booting for hardware models that were
affected, and include that list of models in the kickoff email. Maybe
that gets the attention of would be testers, but also at least puts
people still using such hardware some notice (even in future searches)
should they do a clean install, what problems they might run into. For
testing, it's been six years so it's plausible there have been
firmware updates fixing some or even most of these problems. Perhaps
other GRUB upstream work arounds were discovered.

One big con is the unknown factor, and how to get broad testing
coverage. A contrary position to that is, we didn't know about any
problems six years ago when the switch was flipped, and then we ran
into the problem. So how is it any worse of an idea now than it was
originally? The change is still valid as long as a bunch of people
aren't negatively impacted. Also, it's not change for the sake of
change, it has a followup feature that does incrementally simplify the
layout and makes it a bit more flexible at pretty much no cost.

> However, I do care about correcting things like this. I've found
> Fedora's way of doing boot loader configuration a little strange and
> confusing compared to other distros. If Fedora is open to contribution
> by new members, I would be happy to contribute.

Yes it is, but contribution in the context of actually changing
inertia means producing the changes: patches, commits, documentation,
tests, bug reports. Things that get much less attention are mere
feature requests without committing resources to producing a tangible
result. And also, this applies to the current spec convo
https://xkcd.com/927/

-- 
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/H5YKG4ZF65IYWR3XVGFAJLHSIAW75GDR/

Re: F29 System Wide Change: Make BootLoaderSpec the default

On 06/21/2018 10:28 PM, Chris Murphy wrote:
> On Thu, Jun 21, 2018 at 3:59 PM, Kyle Marek  wrote:
>
>> If it helps, I've only ever used GRUB on GPT when installing to BIOS
>> systems. I haven't encountered *any* issues so far.
> It was always model specific. Maybe 1/2 dozen models were affected.
> https://bugzilla.redhat.com/show_bug.cgi?id=755226
> https://bugzilla.redhat.com/show_bug.cgi?id=754850
> https://bugzilla.redhat.com/show_bug.cgi?id=741120
>
> In one case, the firmware won't boot if it doesn't see the active bit
> set on a partition in the MBR, and yet the UEFI spec says no partition
> should have an active bit set in a PMBR. And the workaround caused
> worse problems (blast from the past):
> https://bugzilla.redhat.com/show_bug.cgi?id=754850#c8
> https://bugzilla.redhat.com/show_bug.cgi?id=754850#c9
>
>
> Anyway, there must be some other bug that ultimately caused GPT to be
> abandoned, I'm not finding it at the moment though.

Interesting.

>> There was a lot to digest with the above and the GPT-default-splatting
>> part. Just for clarification, are you "completely" opposed to installing
>> GPT on BIOS systems by default *until* there is reason to believe that
>> the issues described were now-fixed GRUB bugs?
> I'm not opposed to someone looking into it. But I'm opposed to just
> assuming it's all going to work out OK. And it's not up to me anyway.
>
> It might qualify as a system wide change, deadline for which is July
> 3. The full change is GPT on BIOS by default *and* including ESP and
> BIOSBoot partitions by default needs a conversation with
> anaconda/blivet folks if they would accept patches to make that happen
> in the Fedora 29 timeframe. They need to be asked first, there's no
> point in pushing a feature proposal by a July 3 deadline if the
> anaconda folks won't merge the change. And you'd need to own the
> feature or find someone to own it, and go through the process.
> Basically realize what you might very well be counting on, is that
> buggy BIOS computers are now too old and this has since been fixed.
> But there's no evidence for this one way or another, as far as I know.
> For example, Windows 10's installer today in 2018, will only use MBR
> on a drive when the computer boots in BIOS mode. So there's maybe not
> much external testing for this. I'm not sure what other distros do by
> default. That might be a useful data point.

I've noticed that Windows 10 does MBR installs on BIOS, as well. I've
always found that interesting because I have also found several laptops
(I think most of them were HP) where the OEM installed a BIOS bootloader
in addition to the EFI bootloader. My guess is that these OEMs see a
similar value in being able to boot both BIOS and EFI.

> It may be easier to go for just GPT on BIOS by default, for Fedora 29.
> If that doesn't blow up, then go for the partition changes in Fedora
> 30.

That sounds like a fair way to make this manageable.

>> Beyond the benefit of being able to boot EFI and GPT by default, there
>> is also the benefit of not storing GRUB in the gap before the first MBR
>> partition (I think this is *especially* eyebrow raising on the MBR side
>> of things), and the benefits of having GPT in general such as a lack of
>> a partition limit, backup partition table, and support for drives larger
>> than 2 TiB (though it needs to be noted that the partitions that need to
>> be accessed with BIOS calls need to exist within the first 2 TiB, or 8
>> GiB for compatibility with really stupid/old BIOSes).
> For what it's worth, if the BIOS system has a drive bigger than 2TB,
> then GPT is used by default. This has been true since at least Fedora
> 17.
>
>
>> Once the GPT-splatting issue is better understood, I really think that
>> if GPT-by-default can be considered at all, it should be.
>>
> Are you gonna own the feature? :-) Maybe Colin Walters finds it
> compelling enough to be co-owner?

Can I? I'm a bit new to Fedora development (I don't have a FAS account,
yet).

However, I do care about correcting things like this. I've found
Fedora's way of doing boot loader configuration a little strange and
confusing compared to other distros. If Fedora is open to contribution
by new members, I would be happy to contribute.
___
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/ZOZ6C6IZA5Q64JW6XUCREGF657XECWI6/

Re: F29 System Wide Change: Make BootLoaderSpec the default

On Thu, Jun 21, 2018 at 3:59 PM, Kyle Marek  wrote:

> If it helps, I've only ever used GRUB on GPT when installing to BIOS
> systems. I haven't encountered *any* issues so far.

It was always model specific. Maybe 1/2 dozen models were affected.
https://bugzilla.redhat.com/show_bug.cgi?id=755226
https://bugzilla.redhat.com/show_bug.cgi?id=754850
https://bugzilla.redhat.com/show_bug.cgi?id=741120

In one case, the firmware won't boot if it doesn't see the active bit
set on a partition in the MBR, and yet the UEFI spec says no partition
should have an active bit set in a PMBR. And the workaround caused
worse problems (blast from the past):
https://bugzilla.redhat.com/show_bug.cgi?id=754850#c8
https://bugzilla.redhat.com/show_bug.cgi?id=754850#c9

Anyway, there must be some other bug that ultimately caused GPT to be
abandoned, I'm not finding it at the moment though.

> There was a lot to digest with the above and the GPT-default-splatting
> part. Just for clarification, are you "completely" opposed to installing
> GPT on BIOS systems by default *until* there is reason to believe that
> the issues described were now-fixed GRUB bugs?

I'm not opposed to someone looking into it. But I'm opposed to just
assuming it's all going to work out OK. And it's not up to me anyway.

It might qualify as a system wide change, deadline for which is July
3. The full change is GPT on BIOS by default *and* including ESP and
BIOSBoot partitions by default needs a conversation with
anaconda/blivet folks if they would accept patches to make that happen
in the Fedora 29 timeframe. They need to be asked first, there's no
point in pushing a feature proposal by a July 3 deadline if the
anaconda folks won't merge the change. And you'd need to own the
feature or find someone to own it, and go through the process.
Basically realize what you might very well be counting on, is that
buggy BIOS computers are now too old and this has since been fixed.
But there's no evidence for this one way or another, as far as I know.
For example, Windows 10's installer today in 2018, will only use MBR
on a drive when the computer boots in BIOS mode. So there's maybe not
much external testing for this. I'm not sure what other distros do by
default. That might be a useful data point.

It may be easier to go for just GPT on BIOS by default, for Fedora 29.
If that doesn't blow up, then go for the partition changes in Fedora
30.

> Beyond the benefit of being able to boot EFI and GPT by default, there
> is also the benefit of not storing GRUB in the gap before the first MBR
> partition (I think this is *especially* eyebrow raising on the MBR side
> of things), and the benefits of having GPT in general such as a lack of
> a partition limit, backup partition table, and support for drives larger
> than 2 TiB (though it needs to be noted that the partitions that need to
> be accessed with BIOS calls need to exist within the first 2 TiB, or 8
> GiB for compatibility with really stupid/old BIOSes).

For what it's worth, if the BIOS system has a drive bigger than 2TB,
then GPT is used by default. This has been true since at least Fedora
17.

>
> Once the GPT-splatting issue is better understood, I really think that
> if GPT-by-default can be considered at all, it should be.
>

Are you gonna own the feature? :-) Maybe Colin Walters finds it
compelling enough to be co-owner?

-- 
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/U4TED5PGT4TWAHEP3UJHRU2CC2BXF6CO/

Re: [Fedora-packaging] Re: DRAFT: Change to Systemd Packaging Guidelines - Was Re: Services that shouldn't be started in the first place

2018-06-21 Thread Jason L Tibbitts III

And I apologize, but I edited out, well, all of Gerald's message in my
reply.  I didn't quite intend to trim _all_ of the context there.

 - 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/NHKKWRB3CNFIXP32QCJSGXEPKB2HS4IW/

Re: [Fedora-packaging] DRAFT: Change to Systemd Packaging Guidelines - Was Re: Services that shouldn't be started in the first place

2018-06-21 Thread Jason L Tibbitts III

> "GBC" == Gerald B Cox writes:

To me this doesn't make much sense in the context in which you have put
it. The existing hardware activation section is just this paragraph:

-
Hardware activation occurs when a service is installed but only turns on
if a certain type of hardware is installed. Enabling of the service is
normally done with a udev rule. At this time we do not have further
guidance on how to write those udev rules. The service itself installs
its .service files in the normal places and are installed by the normal
systemd scriptlets. These services should never be enabled by the
package as they will be enabled by udev.
-

So if it only turns on if a certain type of hardware is installed, it
doesn't make sense to say "and make sure that the certain type of
hardware is actually installed".

It seems to me that your problem is not with hardware activated services
at all. The problem is that the services in question _should_ be
hardware activated, but they aren't. They're just started at boot even
when that makes no sense.

I don't disagree with the idea behind what you're proposing, but the
hardware activation section is quite the wrong place to put it.

It seems to me that a far more appropriate place would be in the
https://fedoraproject.org/wiki/Packaging:DefaultServices document. Add
to the 'Restrictions' section a paragraph about how services which are
enabled by default must not *in the course of normal operation* fail to
start in such a way that system state is anything other than 'running'.

There you would mention that services which only function if certain
hardware is present, or may fail if certain hardware is not present,
must either be hardware activated [link to hardware activation section]
or must start conditionally.

Note that in general, hardware activation is about hotpluggable things,
so saned starts when you plug in a USB scanner or something like that.
I honestly have no idea if it can be leveraged to autostart something
like rngd if various hardware random number generators are available.

- 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/TLKJPA4EBH7KRAJRF7BK2XBXLOF22XB2/

Re: F29 System Wide Change: Make BootLoaderSpec the default

On 06/21/2018 05:19 PM, Chris Murphy wrote:
> On Thu, Jun 21, 2018 at 2:28 PM, Kyle Marek  wrote:
>> On 06/21/2018 03:07 PM, Chris Murphy wrote:
>>> On Thu, Jun 21, 2018 at 11:12 AM, Kyle Marek  wrote:
>>>
 I would greatly appreciate a move to a uniform GPT+EF02+EF00
 partitioning default with a shared boot loader config.
>>> An ESP on BIOS is perhaps weird when making so much of this booting
>>> and startup stuff user facing; but it's actually integrated in the
>>> Matthew Garrett derivative of the BootLoaderSpec and is used as $BOOT.
>> I suppose it is weird without the context of EFI, but there's no reason
>> for it to cause issues.
> Weird is better than inconsistency!

Agreed.

>>> In ancient times, there were some BIOS firmware floating about that
>>> would face plant on encountering GPT, we tried it by default and it
>>> caused too many problems and had to be reverted but that was long
>>> enough ago it's possible such hardware is quite rare.
>> Wow, that really sucks, especially since most GPTs implement a
>> compatibility/protective MBR, anyway.
>>
>> There's really no reason for this behavior to exist, but since it
>> did/does (and since it should be a minority), would it be reasonable to
>> invert the logic regarding inst.gpt? (default to GPT and use MBR only if
>> "inst.mbr" is set). I would think this is fair because the
>> choking-on-GPT issue really is more of a firmware bug than something
>> that should be treated as the lowest-common-denominator.
> Likely old hardware no longer getting firmware updates. And since GPT
> is a creation of the UEFI spec, I don't know whether BIOS firmware can
> be held accountable when splatting upon encountering GPT. I don't
> remember why it splats. (When I said earlier "we tried this" that's
> the Fedora Royal We, as in Anaconda once switched to GPT by default
> and it caused too many problems for blacklisting to resolve.) Since
> bugs in the RHBZ are immortal, there might be a hint buried in the bug
> archive. There's also a hint here:
>
> /usr/share/doc/syslinux/gpt.txt
>
> I've got way too much experience with the madness of hybrid MBR on
> Macs using "Bootcamp" to support Windows; I want all of those weeks of
> time refunded to me. This is a huge FUUUCK N!
>
> But the new protocol section of that file is eyebrow raising. This
> mbrgpt.bin thing is not new, it's been around a while, and makes me
> wonder if the "bug" was originally in GRUB's initial jump code written
> to the first 440 bytes of LBA 0. Huh! This could be a long ago solved
> problem by now, as it's never been revisited in Fedora land.

If it helps, I've only ever used GRUB on GPT when installing to BIOS
systems. I haven't encountered *any* issues so far.

> Anyway, as for GPT by default and inst.mbr as the fallback - the
> problem is that a failure puts the user into a black hole. It's
> totally opaque to them that they'd need to use inst.mbr to get out.
> I'd rather fail safe. Fail danger is only OK if the alternative is
> fail guaranteed. No I think we're obligated to demonstrate on X number
> of models known to splat with Fedora 18/19 (or whatever it was) GRUB +
> GPT, no longer splats with Fedora 28/29 GRUB +GPT.

From my own experience, I really feel as if this issue doesn't exist
anymore. However, for machines where it might, I think that good
documentation might be enough to mitigate the black hole issue.

In addition, decisions about default partitioning really only apply to
new installs on unpartitioned disks. All I am trying to say here is that
initial failure to install doesn't exactly result in a loss of anything.
Please correct me if I am wrong.

> And in any case before that time, it should be simple to pass inst.gpt
> within the Fedora compose system to get VM images that always use GPT.
> I've never heard of a VM BIOS having this bug, but if it's true it
> should be and can be fixed.
>> There's also the issue that a lot of PXE firmwares boot BIOS-only on EFI
>> machines. Personally, I address this by loading iPXE off of a flash
>> drive, but for organizations that can't/won't do this, it would be
>> useful to make an EFI-capable install even if the installer was booted
>> with BIOS for this reason.
>>
>>> OK anyway, I don't see broad BLS consensus forming yet, but I do see
>>> two items that aren't controversial and could move forward as part of
>>> this feature proposal:
>>>
>>> a. Consistent $BOOT/loader/entries for UEFI and BIOS where $BOOT is
>>> the ESP on UEFI, and $BOOT is "other" on BIOS (most likely the
>>> existing /boot ext4 volume currently used). i.e. do not put
>>> /loader/entries in /EFI/fedora
>> By "consistent", do you mean that both EFI and BIOS boot loaders will
>> reference the same entry files? I like that.
> Yes.
>
>> However, I don't like the entries existing on ESP mostly because of the
>> use case of md-RAID for /boot referenced in another thread. I think it
>> would be best to just put the GRUB EFI file on ESP and put the rest of
>> the

Re: Heads up: Python 3.7 rebuild in progress

2018-06-21 Thread Raphael Groner

> On 20.6.2018 19:24, Raphael Groner wrote:
> 
> https://github.com/originell/jpype/pull/332

Thanks, jpype package is fixed with the patch included.
___
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/YWQ7JW33GX5LYIRE23QOKUOBHW6GCIX5/

DRAFT: Change to Systemd Packaging Guidelines - Was Re: Services that shouldn't be started in the first place

I opened a fecso ticket here:  https://pagure.io/fesco/issue/1918

and it was suggested it would be better handled via FPC - so I've created a
draft.

I would appreciate feedback before I created the FPC ticket.

Adding the following paragraph to the Hardware Activation section:

https://fedoraproject.org/wiki/User:Gbcox/Packaging:Systemd#Hardware_activation

===

Enabling of a service by default must not be done unless provisions have
been made to ensure the required hardware actually exists; otherwise the
service can fail which will result in systemd entering a degraded state.
This can be accomplished by utilizing the conditional functionality of
systemd. If the capability to inquire about the specific condition does not
exist, you must request it be created and provide the necessary criteria.
If it is not possible to create a specific conditional systemd validation,
you may request an exception to this guideline until such time the
conditional functionality can be created.

===

Some history here:

On Wed, Jun 20, 2018 at 9:33 AM, Gerald B. Cox  wrote:

> This isn't related to a service, but is throwing out an spurious error
> message.  There is a patch but it hasn't made it's way
> yet into the Fedora kernel:
>
> rt_cmos registration error:  rhbz#1568276
> Basically an error is being thrown because your system doesn't have
> battery backup.  To their credit, it was quickly identified
> and patched.  We now just have to wait for the patch to be applied.
>
> However these:
>
> The mcelog.service message is associated with rhbz#1166978
> The dbxtool.service message is associated with rhbz#1508808
> The rngd.service message is associated with rhbz#1490632
>
> At least for me are the result of services being enabled by default, that
> should never have been enabled for my
> environment.
>
> mcelog:  I am using an AMD processor.  This service only applies to Intel.
> dbxtool:  I am not using SecureBoot.  This service only applies to
> machines using SecureBoot.
> rngd:  I am not using a machine that has a hardware RNG generator
>
> Again, if we are apparently so concerned about a streamlined user
> experience, why are we
> starting processes that aren't needed - and in fact are not appropriate
> for a particular environment,
> and then throwing out error messages which are spurious and confusing?
>
> In my case, this caused me to spend hours individually tracking down all
> these error messages
> to find out that there is nothing wrong with my environment.  Instead the
> issue is these services
> are inappropriately started for EVERYBODY - and in one case have been
> languishing for years.
>
> Last time I checked, Fedora wasn't an Intel only, SecureBoot only,
> mandatory hardware RNG generator
> environment.
>
___
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/F24MSRUFA26JX65ASYS3ZTHQ6T6RQOG3/

Re: F29 System Wide Change: Make BootLoaderSpec the default

On Thu, Jun 21, 2018 at 2:28 PM, Kyle Marek  wrote:
> On 06/21/2018 03:07 PM, Chris Murphy wrote:
>> On Thu, Jun 21, 2018 at 11:12 AM, Kyle Marek  wrote:
>>
>>> I would greatly appreciate a move to a uniform GPT+EF02+EF00
>>> partitioning default with a shared boot loader config.
>> An ESP on BIOS is perhaps weird when making so much of this booting
>> and startup stuff user facing; but it's actually integrated in the
>> Matthew Garrett derivative of the BootLoaderSpec and is used as $BOOT.
>
> I suppose it is weird without the context of EFI, but there's no reason
> for it to cause issues.

Weird is better than inconsistency!

>
>> In ancient times, there were some BIOS firmware floating about that
>> would face plant on encountering GPT, we tried it by default and it
>> caused too many problems and had to be reverted but that was long
>> enough ago it's possible such hardware is quite rare.
>
> Wow, that really sucks, especially since most GPTs implement a
> compatibility/protective MBR, anyway.
>
> There's really no reason for this behavior to exist, but since it
> did/does (and since it should be a minority), would it be reasonable to
> invert the logic regarding inst.gpt? (default to GPT and use MBR only if
> "inst.mbr" is set). I would think this is fair because the
> choking-on-GPT issue really is more of a firmware bug than something
> that should be treated as the lowest-common-denominator.

Likely old hardware no longer getting firmware updates. And since GPT
is a creation of the UEFI spec, I don't know whether BIOS firmware can
be held accountable when splatting upon encountering GPT. I don't
remember why it splats. (When I said earlier "we tried this" that's
the Fedora Royal We, as in Anaconda once switched to GPT by default
and it caused too many problems for blacklisting to resolve.) Since
bugs in the RHBZ are immortal, there might be a hint buried in the bug
archive. There's also a hint here:

/usr/share/doc/syslinux/gpt.txt

I've got way too much experience with the madness of hybrid MBR on
Macs using "Bootcamp" to support Windows; I want all of those weeks of
time refunded to me. This is a huge FUUUCK N!

But the new protocol section of that file is eyebrow raising. This
mbrgpt.bin thing is not new, it's been around a while, and makes me
wonder if the "bug" was originally in GRUB's initial jump code written
to the first 440 bytes of LBA 0. Huh! This could be a long ago solved
problem by now, as it's never been revisited in Fedora land.

Anyway, as for GPT by default and inst.mbr as the fallback - the
problem is that a failure puts the user into a black hole. It's
totally opaque to them that they'd need to use inst.mbr to get out.
I'd rather fail safe. Fail danger is only OK if the alternative is
fail guaranteed. No I think we're obligated to demonstrate on X number
of models known to splat with Fedora 18/19 (or whatever it was) GRUB +
GPT, no longer splats with Fedora 28/29 GRUB +GPT.

And in any case before that time, it should be simple to pass inst.gpt
within the Fedora compose system to get VM images that always use GPT.
I've never heard of a VM BIOS having this bug, but if it's true it
should be and can be fixed.

> There's also the issue that a lot of PXE firmwares boot BIOS-only on EFI
> machines. Personally, I address this by loading iPXE off of a flash
> drive, but for organizations that can't/won't do this, it would be
> useful to make an EFI-capable install even if the installer was booted
> with BIOS for this reason.
>
>> OK anyway, I don't see broad BLS consensus forming yet, but I do see
>> two items that aren't controversial and could move forward as part of
>> this feature proposal:
>>
>> a. Consistent $BOOT/loader/entries for UEFI and BIOS where $BOOT is
>> the ESP on UEFI, and $BOOT is "other" on BIOS (most likely the
>> existing /boot ext4 volume currently used). i.e. do not put
>> /loader/entries in /EFI/fedora
>
> By "consistent", do you mean that both EFI and BIOS boot loaders will
> reference the same entry files? I like that.

Yes.

> However, I don't like the entries existing on ESP mostly because of the
> use case of md-RAID for /boot referenced in another thread. I think it
> would be best to just put the GRUB EFI file on ESP and put the rest of
> the bulk GRUB stuff in its utility partition (which may be RAID-ed).

Right. The config + kernel + initramfs on traditional /boot can make
use of software raid, depending on static one time proper
configuration of each member drive's ESPs and now the ESPs never need
to be touched and thus not sync'd.

Whereas constantly changing the ESP, means we need some way to
establish a master and rsync to the extras.

>
> I think GRUB using its own partition is fair especially because GRUB
> isn't an EFI-only bootloader.
>
>> b. If GPT, installer always creates both EF02 and EF00 partitions. For
>> creating VM images, I think it's sane if the anaconda inst.gpt option
>> is always used to make sure the image is created with G

Re: F29 System Wide Change: Make BootLoaderSpec the default

On 06/21/2018 03:07 PM, Chris Murphy wrote:
> On Thu, Jun 21, 2018 at 11:12 AM, Kyle Marek  wrote:
>
>> I would greatly appreciate a move to a uniform GPT+EF02+EF00
>> partitioning default with a shared boot loader config.
> An ESP on BIOS is perhaps weird when making so much of this booting
> and startup stuff user facing; but it's actually integrated in the
> Matthew Garrett derivative of the BootLoaderSpec and is used as $BOOT.

I suppose it is weird without the context of EFI, but there's no reason
for it to cause issues.

> In ancient times, there were some BIOS firmware floating about that
> would face plant on encountering GPT, we tried it by default and it
> caused too many problems and had to be reverted but that was long
> enough ago it's possible such hardware is quite rare.

Wow, that really sucks, especially since most GPTs implement a
compatibility/protective MBR, anyway.

There's really no reason for this behavior to exist, but since it
did/does (and since it should be a minority), would it be reasonable to
invert the logic regarding inst.gpt? (default to GPT and use MBR only if
"inst.mbr" is set). I would think this is fair because the
choking-on-GPT issue really is more of a firmware bug than something
that should be treated as the lowest-common-denominator.

I would think it's more useful to have the GPT-default installations
supporting EF02 and EF00 than to use only MBR or EFI-only-GPT if it is
true that the anti-GPT BIOSes are rare.

There's also the issue that a lot of PXE firmwares boot BIOS-only on EFI
machines. Personally, I address this by loading iPXE off of a flash
drive, but for organizations that can't/won't do this, it would be
useful to make an EFI-capable install even if the installer was booted
with BIOS for this reason.

> OK anyway, I don't see broad BLS consensus forming yet, but I do see
> two items that aren't controversial and could move forward as part of
> this feature proposal:
>
> a. Consistent $BOOT/loader/entries for UEFI and BIOS where $BOOT is
> the ESP on UEFI, and $BOOT is "other" on BIOS (most likely the
> existing /boot ext4 volume currently used). i.e. do not put
> /loader/entries in /EFI/fedora

By "consistent", do you mean that both EFI and BIOS boot loaders will
reference the same entry files? I like that.

However, I don't like the entries existing on ESP mostly because of the
use case of md-RAID for /boot referenced in another thread. I think it
would be best to just put the GRUB EFI file on ESP and put the rest of
the bulk GRUB stuff in its utility partition (which may be RAID-ed).

I think GRUB using its own partition is fair especially because GRUB
isn't an EFI-only bootloader.

> b. If GPT, installer always creates both EF02 and EF00 partitions. For
> creating VM images, I think it's sane if the anaconda inst.gpt option
> is always used to make sure the image is created with GPT
> partitioning, thereby making sure they get EF02 and EF00.

EF02 and EF00 good. I would prefer if this wasn't an EFI-only
conditional due to my above responses.

Thank you for your consideration!
___
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/XYACTYIRY2WGJXCJXG4IIYCJ636HXSPS/

Re: Services that shouldn't be started in the first place: Was F29... hide.. grub

On Thu, 2018-06-21 at 12:40 -0700, stan wrote:
> On Thu, 21 Jun 2018 10:50:10 -0700
> Adam Williamson  wrote:
> 
> > On Thu, 2018-06-21 at 19:27 +0200, Lennart Poettering wrote:
> > > (Also, why is there a userspace component for this stuff in the
> > > first place? I mean streaming data from one corner of the kernel to
> > > another corner of the kernel is something probably better done
> > > inside of the kernel instead of involving userspace at all with
> > > this...)  
> > 
> > That, I don't know, and I'd sort of wondered the same. Don't know who
> > can enlighten us as to the answer.
> 
> Some maybe irrelevant information:
> 
> There is a user accessible kernel interface that allows user
> started daemons to feed entropy into the kernel entropy pool.  It works
> via a callback mechanism.  I use it to harvest entropy from atmospheric
> noise and sound card noise and feed it into the pool. I'm not sure if
> that is the same thing you are talking about.  What it means is that
> the kernel doesn't have to know anything about the device providing the
> entropy (no need for a driver).
> 
> There is also a kernel process that harvests entropy from hard disk
> noise and keyboard and mouse movement.  I'm not sure if it is part of
> rngd or not.

Thanks for the note, but no, none of this is relevant to the specific
problem here.
-- 
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/RVILXUJI6U65KVT75RERFVYGVXRHUDVM/

Re: Services that shouldn't be started in the first place: Was F29... hide.. grub

2018-06-21 Thread stan

On Thu, 21 Jun 2018 10:50:10 -0700
Adam Williamson  wrote:

> On Thu, 2018-06-21 at 19:27 +0200, Lennart Poettering wrote:

> > (Also, why is there a userspace component for this stuff in the
> > first place? I mean streaming data from one corner of the kernel to
> > another corner of the kernel is something probably better done
> > inside of the kernel instead of involving userspace at all with
> > this...)  
> 
> That, I don't know, and I'd sort of wondered the same. Don't know who
> can enlighten us as to the answer.

Some maybe irrelevant information:

There is a user accessible kernel interface that allows user
started daemons to feed entropy into the kernel entropy pool.  It works
via a callback mechanism.  I use it to harvest entropy from atmospheric
noise and sound card noise and feed it into the pool. I'm not sure if
that is the same thing you are talking about.  What it means is that
the kernel doesn't have to know anything about the device providing the
entropy (no need for a driver).

There is also a kernel process that harvests entropy from hard disk
noise and keyboard and mouse movement.  I'm not sure if it is part of
rngd or not.

It's been a while since I looked at this so the details are fuzzy for
me.
___
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/NBYSYK3SQUZO6XDAUBEDFFTJMR6Y4ZLK/

Re: F29 System Wide Change: Make BootLoaderSpec the default

On Thu, Jun 21, 2018 at 11:12 AM, Kyle Marek wrote:

> I would greatly appreciate a move to a uniform GPT+EF02+EF00
> partitioning default with a shared boot loader config.

An ESP on BIOS is perhaps weird when making so much of this booting
and startup stuff user facing; but it's actually integrated in the
Matthew Garrett derivative of the BootLoaderSpec and is used as $BOOT.

In ancient times, there were some BIOS firmware floating about that
would face plant on encountering GPT, we tried it by default and it
caused too many problems and had to be reverted but that was long
enough ago it's possible such hardware is quite rare.

OK anyway, I don't see broad BLS consensus forming yet, but I do see
two items that aren't controversial and could move forward as part of
this feature proposal:

a. Consistent $BOOT/loader/entries for UEFI and BIOS where $BOOT is
the ESP on UEFI, and $BOOT is "other" on BIOS (most likely the
existing /boot ext4 volume currently used). i.e. do not put
/loader/entries in /EFI/fedora

b. If GPT, installer always creates both EF02 and EF00 partitions. For
creating VM images, I think it's sane if the anaconda inst.gpt option
is always used to make sure the image is created with GPT
partitioning, thereby making sure they get EF02 and EF00.

--
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/2PVYRSMT5ZVR63UM6MMWH4XBLMO3CQ7O/

Re: Services that shouldn't be started in the first place: Was F29... hide.. grub

On 06/21/2018 02:00 PM, Gerald B. Cox wrote:
> On Thu, Jun 21, 2018 at 10:27 AM, Lennart Poettering 
> wrote:
>
>> Just out of curiosity: when precisely is rngd supposed to be used? As
>> soon as there's a hardware RNG device /dev/hwrng? That should be
>> easy enough: ConditionFileExists=/dev/hwrng... Or are there other
>> cases when this is supposed to be start?
>>
>> (Also, why is there a userspace component for this stuff in the first
>> place? I mean streaming data from one corner of the kernel to another
>> corner of the kernel is something probably better done inside of the
>> kernel instead of involving userspace at all with this...)
>>
>> Here are a couple of links I found:
> https://www.certdepot.net/rhel7-get-started-random-number-generator/
> https://volumeintegration.com/best-entropy-generation-software-for-linux/
>
> My understanding from the above is that "Rngd-tools and the rngd command is
> not a tool to generate entropy.
> It is a program that takes randomness from a true random hardware device
> and puts it into /dev/random."
>
> So, if you don't have the hardware device, it isn't to be used.  There are
> usb type devices such as
> OneRNG, TrueRNG, Chaoskey, NeuG that you can purchase that can provide this
> functionality.

That is interesting. Out of curiosity, does rngd have any support for a
smart card as a source of random numbers?

If so, I believe that would be an example of why the userspace daemon
might be useful; smart card communication kinda has to be userspace.
___
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/O5YVUTSRHYOKFGWCLQENNSVRVYMT5RKR/

Re: Python 3.6.5 still used on rawhide

2018-06-21 Thread Scott Talbert


On Thu, 21 Jun 2018, Antonio Trande wrote:


Hi all.

I'm confused...

Why recent python-biopython rebuild is still using Python 3.6.5 on rawhide?


Python 3.7 mass rebuild is happening in a side tag.  See:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/AWSPEQSEY5NZZIJKQ6CDICPX45HUIK4M/

Scott
___
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/5URMSQV5HID5A7TPGMVLRHOT664XKU7L/

Python 3.6.5 still used on rawhide

2018-06-21 Thread Antonio Trande

Hi all.

I'm confused...

Why recent python-biopython rebuild is still using Python 3.6.5 on rawhide?

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x5E212EE1D35568BE
GPG key server: https://keys.fedoraproject.org/



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/SESYPCVJZSP3YLCM5DDTFCHLVXSVY5VO/

Re: Services that shouldn't be started in the first place: Was F29... hide.. grub

I just installed the cpuid package.  Here is a portion of the output for my
processor.  As you can see:  RDRAND reported "= false" which means
my processor does not suppoprt the hardware random number generator feature.

 feature information (1/ecx):
  PNI/SSE3: Prescott New Instructions = true
  PCLMULDQ instruction= true
  DTES64: 64-bit debug store  = false
  MONITOR/MWAIT   = true
  CPL-qualified debug store   = false
  VMX: virtual machine extensions = false
  SMX: safer mode extensions  = false
  Enhanced Intel SpeedStep Technology = false
  TM2: thermal monitor 2  = false
  SSSE3 extensions= true
  context ID: adaptive or shared L1 data  = false
  SDBG: IA32_DEBUG_INTERFACE  = false
  FMA instruction = true
  CMPXCHG16B instruction  = true
  xTPR disable= false
  PDCM: perfmon and debug = false
  PCID: process context identifiers   = false
  DCA: direct cache access= false
  SSE4.1 extensions   = true
  SSE4.2 extensions   = true
  x2APIC: extended xAPIC support  = false
  MOVBE instruction   = false
  POPCNT instruction  = true
  time stamp counter deadline = false
  AES instruction = true
  XSAVE/XSTOR states  = true
  OS-enabled XSAVE/XSTOR  = true
  AVX: advanced vector extensions = true
  F16C half-precision convert instruction = true
  RDRAND instruction  = false
  hypervisor guest status = false



On Thu, Jun 21, 2018 at 11:00 AM, Gerald B. Cox  wrote:

>
>
> On Thu, Jun 21, 2018 at 10:27 AM, Lennart Poettering  > wrote:
>
>>
>> Just out of curiosity: when precisely is rngd supposed to be used? As
>> soon as there's a hardware RNG device /dev/hwrng? That should be
>> easy enough: ConditionFileExists=/dev/hwrng... Or are there other
>> cases when this is supposed to be start?
>>
>> (Also, why is there a userspace component for this stuff in the first
>> place? I mean streaming data from one corner of the kernel to another
>> corner of the kernel is something probably better done inside of the
>> kernel instead of involving userspace at all with this...)
>>
>> Here are a couple of links I found:
> https://www.certdepot.net/rhel7-get-started-random-number-generator/
> https://volumeintegration.com/best-entropy-generation-software-for-linux/
>
> My understanding from the above is that "Rngd-tools and the rngd command
> is not a tool to generate entropy.
> It is a program that takes randomness from a true random hardware device
> and puts it into /dev/random."
>
> So, if you don't have the hardware device, it isn't to be used.  There are
> usb type devices such as
> OneRNG, TrueRNG, Chaoskey, NeuG that you can purchase that can provide
> this functionality.
>
> This link from Wikipedia:  https://en.wikipedia.org/wiki/RdRand
>
> says that "*RDRAND* (previously known as *Bull Mountain*[1]
> ) is an instruction
>  for
> returning random numbers from an Intel
>  on-chip hardware random number
> generator 
> which has been seeded by an on-chip entropy source.[2]
>  RDRAND is
> available in Ivy Bridge
>  processors
> [a]  and is part of the 
> Intel
> 64  and IA-32
>  instruction set architectures
> . AMD added support for
> the instruction in June 2015."
>
> Also apparently:  "
>
> The CPUID  instruction can be used
> to check whether the central processing unit
>  (CPU) supports
> the RDRAND instruction on both AMD and Intel CPUs. If supported, bit 30
> of the ECX register is set after calling CPUID standard function 01H.[9]
>  AMD processors are
> checked for the feature using the same test.[10]
>  RDSEED availability
> can be checked on Intel CPUs in a similar manner. If RDSEED is supported,
> the bit 18 of the EBX register is set after calling CPUID standard function
> 07H.[11] 
>
> The opcode f

Re: Services that shouldn't be started in the first place: Was F29... hide.. grub

On Thu, Jun 21, 2018 at 10:27 AM, Lennart Poettering 
wrote:

>
> Just out of curiosity: when precisely is rngd supposed to be used? As
> soon as there's a hardware RNG device /dev/hwrng? That should be
> easy enough: ConditionFileExists=/dev/hwrng... Or are there other
> cases when this is supposed to be start?
>
> (Also, why is there a userspace component for this stuff in the first
> place? I mean streaming data from one corner of the kernel to another
> corner of the kernel is something probably better done inside of the
> kernel instead of involving userspace at all with this...)
>
> Here are a couple of links I found:
https://www.certdepot.net/rhel7-get-started-random-number-generator/
https://volumeintegration.com/best-entropy-generation-software-for-linux/

My understanding from the above is that "Rngd-tools and the rngd command is
not a tool to generate entropy.
It is a program that takes randomness from a true random hardware device
and puts it into /dev/random."

So, if you don't have the hardware device, it isn't to be used.  There are
usb type devices such as
OneRNG, TrueRNG, Chaoskey, NeuG that you can purchase that can provide this
functionality.

This link from Wikipedia:  https://en.wikipedia.org/wiki/RdRand

says that "*RDRAND* (previously known as *Bull Mountain*[1]
) is an instruction
 for
returning random numbers from an Intel 
on-chip hardware random number generator
 which has
been seeded by an on-chip entropy source.[2]
 RDRAND is available
in Ivy Bridge 
processors[a]  and is
part of the Intel 64  and IA-32
 instruction set architectures
. AMD added support for the
instruction in June 2015."

Also apparently:  "

The CPUID  instruction can be used to
check whether the central processing unit
 (CPU) supports the
RDRAND instruction on both AMD and Intel CPUs. If supported, bit 30 of the
ECX register is set after calling CPUID standard function 01H.[9]
 AMD processors are
checked for the feature using the same test.[10]
 RDSEED availability can
be checked on Intel CPUs in a similar manner. If RDSEED is supported, the
bit 18 of the EBX register is set after calling CPUID standard function 07H.
[11] 

The opcode for RDRAND is 0x0F 0xC7, followed by a ModRM byte that specifies
the destination register and optionally combined with a REX prefix in 64
bit mode.[12]" 

So, apparently, the CPUID instruction holds the key and should be checked
to see if the CPU supports it.  In the case of the external USB devices, I
don't believe you need to worry about those.  If someone purchases
them, they would know they would need to take action to get it to work.
___
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/FRROROPY7UX2A7VBSKRQMESNKFJ5PGP4/

Re: Services that shouldn't be started in the first place: Was F29... hide.. grub

On Thu, Jun 21, 2018 at 10:48 AM, Adam Williamson <
adamw...@fedoraproject.org> wrote:

> I don't maintain any of these services, so your criticism is neither
> constructive nor accurate.
>

Then why are you inserting yourself into this conversation and looking for
ways to be offended?
It's not about you.  Relax.
___
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/II2GDHSARZBMVXSXBSK5YC6D6YMWKT42/

Re: Services that shouldn't be started in the first place: Was F29... hide.. grub

On Thu, 2018-06-21 at 19:27 +0200, Lennart Poettering wrote:
> On Do, 21.06.18 10:07, Adam Williamson (adamw...@fedoraproject.org) wrote:
> 
> > On Thu, 2018-06-21 at 09:46 -0700, Gerald B. Cox wrote:
> > > Interesting... thanks Adam... but the way I read that is specifically
> > > tailored to "release criteria", not
> > > design/implementation guidelines - i.e. to me this says, don't hold up a
> > > release because someone
> > > screwed up and didn't conditionalize the process correctly.
> > 
> > I think you're being a *bit* harsh, here, btw, constantly talking about
> > how people are "screwing up". Conditionalized services are kind of an
> > advanced systemd feature and many people probably don't know about them
> > at all, and as we're discussing here, we *don't* actually have any
> > requirement that services be conditionalized in this way. I don't think
> > it's really fair to see this as packagers doing something horribly
> > wrong and bad. (Also note that it's not at all straightforward to
> > conditionalize some of these things in a reliable way - it seems
> > Lennart had to add a new feature to systemd to aid in conditionalizing
> > the secure boot-related service, and I don't think it'll be
> > particularly straightforward to find a correct conditionalization for
> > the rngd case either). It's just a situation we've identified where we
> > could possibly improve things.
> 
> Just out of curiosity: when precisely is rngd supposed to be used? As
> soon as there's a hardware RNG device /dev/hwrng? That should be
> easy enough: ConditionFileExists=/dev/hwrng... Or are there other
> cases when this is supposed to be start?

See https://bugzilla.redhat.com/show_bug.cgi?id=1490632#c42 .

> (Also, why is there a userspace component for this stuff in the first
> place? I mean streaming data from one corner of the kernel to another
> corner of the kernel is something probably better done inside of the
> kernel instead of involving userspace at all with this...)

That, I don't know, and I'd sort of wondered the same. Don't know who
can enlighten us as to the answer.
-- 
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/MDSAU3FGMEY4MM6BYIPQI4EHSIS77LNT/

Re: Services that shouldn't be started in the first place: Was F29... hide.. grub

On Thu, 2018-06-21 at 10:18 -0700, Gerald B. Cox wrote:
> On Thu, Jun 21, 2018 at 10:07 AM, Adam Williamson <
> adamw...@fedoraproject.org> wrote:
> 
> > On Thu, 2018-06-21 at 09:46 -0700, Gerald B. Cox wrote:
> > > Interesting... thanks Adam... but the way I read that is specifically
> > > tailored to "release criteria", not
> > > design/implementation guidelines - i.e. to me this says, don't hold up a
> > > release because someone
> > > screwed up and didn't conditionalize the process correctly.
> > 
> > I think you're being a *bit* harsh, here, btw, constantly talking about
> > how people are "screwing up". Conditionalized services are kind of an
> > advanced systemd feature and many people probably don't know about them
> > at all, and as we're discussing here, we *don't* actually have any
> > requirement that services be conditionalized in this way. I don't think
> > it's really fair to see this as packagers doing something horribly
> > wrong and bad. (Also note that it's not at all straightforward to
> > conditionalize some of these things in a reliable way - it seems
> > Lennart had to add a new feature to systemd to aid in conditionalizing
> > the secure boot-related service, and I don't think it'll be
> > particularly straightforward to find a correct conditionalization for
> > the rngd case either). It's just a situation we've identified where we
> > could possibly improve things.
> > 
> > First of all, I'm not "constantly talking" about how people are "screwing
> 
> up".  I made that comment in one email.
> Second, if you're going to maintain something, maintain it.  If you don't
> do something properly, or optimally... own it
> and don't make excuses.  Learn to accept constructive criticism instead of
> parsing someone's statements
> searching for reasons to feign insult for use as a deflective excuse.

I don't maintain any of these services, so your criticism is neither
constructive nor accurate.
-- 
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/VKHATZU52JA2ZIMNJVXGIOVEQZAVVTWY/

Re: Services that shouldn't be started in the first place: Was F29... hide.. grub

2018-06-21 Thread Lennart Poettering

On Do, 21.06.18 10:07, Adam Williamson (adamw...@fedoraproject.org) wrote:

> On Thu, 2018-06-21 at 09:46 -0700, Gerald B. Cox wrote:
> > Interesting... thanks Adam... but the way I read that is specifically
> > tailored to "release criteria", not
> > design/implementation guidelines - i.e. to me this says, don't hold up a
> > release because someone
> > screwed up and didn't conditionalize the process correctly.
> 
> I think you're being a *bit* harsh, here, btw, constantly talking about
> how people are "screwing up". Conditionalized services are kind of an
> advanced systemd feature and many people probably don't know about them
> at all, and as we're discussing here, we *don't* actually have any
> requirement that services be conditionalized in this way. I don't think
> it's really fair to see this as packagers doing something horribly
> wrong and bad. (Also note that it's not at all straightforward to
> conditionalize some of these things in a reliable way - it seems
> Lennart had to add a new feature to systemd to aid in conditionalizing
> the secure boot-related service, and I don't think it'll be
> particularly straightforward to find a correct conditionalization for
> the rngd case either). It's just a situation we've identified where we
> could possibly improve things.

Just out of curiosity: when precisely is rngd supposed to be used? As
soon as there's a hardware RNG device /dev/hwrng? That should be
easy enough: ConditionFileExists=/dev/hwrng... Or are there other
cases when this is supposed to be start?

(Also, why is there a userspace component for this stuff in the first
place? I mean streaming data from one corner of the kernel to another
corner of the kernel is something probably better done inside of the
kernel instead of involving userspace at all with this...)

Lennart

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

Re: Services that shouldn't be started in the first place: Was F29... hide.. grub

On Thu, Jun 21, 2018 at 10:07 AM, Adam Williamson <
adamw...@fedoraproject.org> wrote:

> On Thu, 2018-06-21 at 09:46 -0700, Gerald B. Cox wrote:
> > Interesting... thanks Adam... but the way I read that is specifically
> > tailored to "release criteria", not
> > design/implementation guidelines - i.e. to me this says, don't hold up a
> > release because someone
> > screwed up and didn't conditionalize the process correctly.
>
> I think you're being a *bit* harsh, here, btw, constantly talking about
> how people are "screwing up". Conditionalized services are kind of an
> advanced systemd feature and many people probably don't know about them
> at all, and as we're discussing here, we *don't* actually have any
> requirement that services be conditionalized in this way. I don't think
> it's really fair to see this as packagers doing something horribly
> wrong and bad. (Also note that it's not at all straightforward to
> conditionalize some of these things in a reliable way - it seems
> Lennart had to add a new feature to systemd to aid in conditionalizing
> the secure boot-related service, and I don't think it'll be
> particularly straightforward to find a correct conditionalization for
> the rngd case either). It's just a situation we've identified where we
> could possibly improve things.
>
> First of all, I'm not "constantly talking" about how people are "screwing
up".  I made that comment in one email.
Second, if you're going to maintain something, maintain it.  If you don't
do something properly, or optimally... own it
and don't make excuses.  Learn to accept constructive criticism instead of
parsing someone's statements
searching for reasons to feign insult for use as a deflective excuse.
___
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/2CCGSWDESGDXVGXYTMHVLSDI6C4IRGGE/

Re: F29 System Wide Change: Make BootLoaderSpec the default

On 06/21/2018 09:41 AM, Gerd Hoffmann wrote:
>   Hi,
>
>> From my perspective (Fedora CoreOS developer) that straddles
>> both physical and cloud for the server case, the problem is that
>> the virtualized case, and in particular public cloud, and really
>> specifically EC2 - no one really cares about EFI to boot their VMs.
> Indeed.  And it sucks.
>
>>>   Device   Start End Sectors  Size Type
>>>   /dev/sda1 2048   1023981924M BIOS boot
>>>   /dev/sda210240 1058815 1048576  512M EFI System
>> I wouldn't *oppose* that; in fact if you (or someone else)
>> wanted to push for that with e.g. Fedora CoreOS, I'd be happy
>> to discuss it.  But it's not like it has a truly compelling advantage
>> over what we ship today - it'd just be *another* weird variant
>> of things in the end right?
> Well, as *additional* variant it doesn't provide that much value.  More
> interesting would be to create all x86 cloud images that way, so they
> boot just fine on both bios and efi, and we don't have to bother
> creating two image variants.

I've been manually partitioning physical machines that I install Fedora
on for exactly this reason.

Similar to moving to VMs, it is especially useful when you need to
replace hardware (where the new hardware uses a different firmware), as
you can just put the drives in the new machine. Under the current
automatic partitioning, a switch from BIOS to EFI requires
repartitioning (both changing partition table type *and* partition sizes
to make room for ESP), which may even be "impossible" if the system is
on XFS.

I would greatly appreciate a move to a uniform GPT+EF02+EF00
partitioning default with a shared boot loader config.
___
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/K4G7HVPH7AP35DSVDHLS5XFTAYJ654ZP/

Re: Services that shouldn't be started in the first place: Was F29... hide.. grub

On Thu, 2018-06-21 at 09:46 -0700, Gerald B. Cox wrote:
> Interesting... thanks Adam... but the way I read that is specifically
> tailored to "release criteria", not
> design/implementation guidelines - i.e. to me this says, don't hold up a
> release because someone
> screwed up and didn't conditionalize the process correctly.

I think you're being a *bit* harsh, here, btw, constantly talking about
how people are "screwing up". Conditionalized services are kind of an
advanced systemd feature and many people probably don't know about them
at all, and as we're discussing here, we *don't* actually have any
requirement that services be conditionalized in this way. I don't think
it's really fair to see this as packagers doing something horribly
wrong and bad. (Also note that it's not at all straightforward to
conditionalize some of these things in a reliable way - it seems
Lennart had to add a new feature to systemd to aid in conditionalizing
the secure boot-related service, and I don't think it'll be
particularly straightforward to find a correct conditionalization for
the rngd case either). It's just a situation we've identified where we
could possibly improve things.
-- 
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/C52WF2MAKL4WNVT3ZKIAIGCDIBPEWFKI/

Re: Services that shouldn't be started in the first place: Was F29... hide.. grub

I opened the ticket, it is here:  https://pagure.io/fesco/issue/1918

Thanks again Stephen for the suggestion.

On Thu, Jun 21, 2018 at 9:46 AM, Gerald B. Cox  wrote:

> Interesting... thanks Adam... but the way I read that is specifically
> tailored to "release criteria", not
> design/implementation guidelines - i.e. to me this says, don't hold up a
> release because someone
> screwed up and didn't conditionalize the process correctly.
>
> On Thu, Jun 21, 2018 at 9:38 AM, Adam Williamson <
> adamw...@fedoraproject.org> wrote:
>
>> On Thu, 2018-06-21 at 12:08 -0400, Stephen Gallagher wrote:
>> > On Thu, Jun 21, 2018 at 12:03 PM Gerald B. Cox  wrote:
>> >
>> > >
>> > >
>> > > On Thu, Jun 21, 2018 at 6:39 AM, Stephen Gallagher <
>> sgall...@redhat.com>
>> > > wrote:
>> > >
>> > > >
>> > > >
>> > > >
>> > > > > I believe we're missing something fundamental here.  If a
>> > > > > program/service etc. requires specific hardware to work
>> > > > > and it can't gracefully handle situations where that hardware is
>> not
>> > > > > present - it shouldn't be a default.
>> > > > >
>> > > > > The way to handle this (and other similar situations) is to take
>> away
>> > > > > the default status until it can handle
>> > > > > situations where the hardware doesn't exist.  This is systems
>> > > > > programming 101 - and frankly I am a
>> > > > > bit surprised it's a matter of debate.
>> > > > >
>> > > > >
>> > > >
>> > > > No one on this list is disagreeing that the defaults should not
>> degrade
>> > > > the system. I *do* think that your response is an overreaction: just
>> > > > because software may have bugs on your hardware doesn't mean that
>> it should
>> > > > be turned off entirely. If it's causing problems for a small subset
>> of
>> > > > users, they can be manually disabled.
>> > > >
>> > > > These services provide CONSIDERABLE benefit on the hardware that
>> supports
>> > > > it. Removing that as a default for those systems would be a
>> significant
>> > > > regression. That's not an acceptable solution.
>> > > >
>> > > > Most of the people on this thread seem to agree: we can
>> conditionalize
>> > > > the defaults so it is either skipped or at least does not mark the
>> service
>> > > > as "failed" if the necessary hardware is not present. People are
>> already
>> > > > working on doing this.
>> > > >
>> > >
>> > > Stephen, I'm not disputing the benefit - and I very much appreciate
>> the
>> > > fact that people are working to conditionalize the defaults.  What I
>> do
>> > > disagree with is your characterization that this is a bug.
>> > > It is working as it was designed - and the design is faulty - and it's
>> > > pervasive.  I've encountered THREE different processes that aren't
>> properly
>> > > conditionalized.  That's definitely not a bug - that's a systemic
>> issue.
>> > > Yes, AMD processors are not as popular as Intel, but they do exist in
>> > > considerable numbers and most definitely should be
>> > > considered when things are implemented as defaults; additionally...
>> > > obviously... not everybody uses SecureBoot.
>> > > My comment regarding taking away default status was in regards to this
>> > > lingering for years.
>> > > I personally don't believe that is acceptable.  If one can't figure
>> out
>> > > how to fix things like this in a timely manner, then there is a
>> problem.
>> > >
>> > >
>> >
>> > Well, there was also a failure of escalation path here. If this was
>> going
>> > on for years without a resolution, why wasn't it raised on this list or
>> to
>> > FESCo a long time ago? Individual maintainers have their own priorities
>> and
>> > time constraints and don't always address every bug that comes their
>> way.
>> >
>> > However, had it risen up the chain, it's possible a group like FESCo
>> might
>> > take note and set down some rules/requirements. As it is, I think it's
>> > probably time right now to move this to a FESCo ticket and see what we
>> can
>> > do about it. Gerald, if you feel strongly about this issue, please file
>> it.
>>
>> Note we already have a release criterion related to this:
>>
>> "All system services present after installation with one of the
>> release-blocking package sets must start properly, unless they require
>> hardware which is not present."
>>
>> That lets out the rngd and Intel vs. AMD cases, I guess - it is
>> specifically written to do so, after we decided once that we didn't
>> want to block the release on the rngd case or one like it - but it
>> would cover the Secure Boot case at least.
>> --
>> 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

Re: [Modularity] Module streams with two different, non-overlapping, package sets?

2018-06-21 Thread Mikolaj Izdebski

On 06/21/2018 06:26 PM, Stephen Gallagher wrote:
>>> So, when we started looking at ways to provide alternative software, we
>>> determined that parallel-installation was a non-goal. Not needing to
>> solve
>>> an unsolvable problem meant that we could focus on the parts that really
>>> matter: allowing people to select which single version of the software
>>> meets their needs.
>>
>> So the conclusion is that inability to have parallel-installable streams
>> of the same module is not due to technical difficulties to implement
>> that feature, but rather a consequence of prioritizing different
>> requirements.
>>
>>
> You drew a conclusion that is EXACTLY the opposite of what I said above. We
> determined that parallel-installation was basically impossible to build in
> a generic way. Once that was eliminated as a possible requirement, the rest
> fell into place fairly neatly.

Allowing parallel installation of two distinct package sets, provided
that they don't conflict in any way - how is that impossible?  I get
that it's not a goal for modularity to support this, but I don't see any
technical reason not to allow it.


-- 
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
___
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/JIYXGHBSF6GETDJTLSC2EZ3CB62KIOD5/

Re: Services that shouldn't be started in the first place: Was F29... hide.. grub

Interesting... thanks Adam... but the way I read that is specifically
tailored to "release criteria", not
design/implementation guidelines - i.e. to me this says, don't hold up a
release because someone
screwed up and didn't conditionalize the process correctly.

On Thu, Jun 21, 2018 at 9:38 AM, Adam Williamson  wrote:

> On Thu, 2018-06-21 at 12:08 -0400, Stephen Gallagher wrote:
> > On Thu, Jun 21, 2018 at 12:03 PM Gerald B. Cox  wrote:
> >
> > >
> > >
> > > On Thu, Jun 21, 2018 at 6:39 AM, Stephen Gallagher <
> sgall...@redhat.com>
> > > wrote:
> > >
> > > >
> > > >
> > > >
> > > > > I believe we're missing something fundamental here.  If a
> > > > > program/service etc. requires specific hardware to work
> > > > > and it can't gracefully handle situations where that hardware is
> not
> > > > > present - it shouldn't be a default.
> > > > >
> > > > > The way to handle this (and other similar situations) is to take
> away
> > > > > the default status until it can handle
> > > > > situations where the hardware doesn't exist.  This is systems
> > > > > programming 101 - and frankly I am a
> > > > > bit surprised it's a matter of debate.
> > > > >
> > > > >
> > > >
> > > > No one on this list is disagreeing that the defaults should not
> degrade
> > > > the system. I *do* think that your response is an overreaction: just
> > > > because software may have bugs on your hardware doesn't mean that it
> should
> > > > be turned off entirely. If it's causing problems for a small subset
> of
> > > > users, they can be manually disabled.
> > > >
> > > > These services provide CONSIDERABLE benefit on the hardware that
> supports
> > > > it. Removing that as a default for those systems would be a
> significant
> > > > regression. That's not an acceptable solution.
> > > >
> > > > Most of the people on this thread seem to agree: we can
> conditionalize
> > > > the defaults so it is either skipped or at least does not mark the
> service
> > > > as "failed" if the necessary hardware is not present. People are
> already
> > > > working on doing this.
> > > >
> > >
> > > Stephen, I'm not disputing the benefit - and I very much appreciate the
> > > fact that people are working to conditionalize the defaults.  What I do
> > > disagree with is your characterization that this is a bug.
> > > It is working as it was designed - and the design is faulty - and it's
> > > pervasive.  I've encountered THREE different processes that aren't
> properly
> > > conditionalized.  That's definitely not a bug - that's a systemic
> issue.
> > > Yes, AMD processors are not as popular as Intel, but they do exist in
> > > considerable numbers and most definitely should be
> > > considered when things are implemented as defaults; additionally...
> > > obviously... not everybody uses SecureBoot.
> > > My comment regarding taking away default status was in regards to this
> > > lingering for years.
> > > I personally don't believe that is acceptable.  If one can't figure out
> > > how to fix things like this in a timely manner, then there is a
> problem.
> > >
> > >
> >
> > Well, there was also a failure of escalation path here. If this was going
> > on for years without a resolution, why wasn't it raised on this list or
> to
> > FESCo a long time ago? Individual maintainers have their own priorities
> and
> > time constraints and don't always address every bug that comes their way.
> >
> > However, had it risen up the chain, it's possible a group like FESCo
> might
> > take note and set down some rules/requirements. As it is, I think it's
> > probably time right now to move this to a FESCo ticket and see what we
> can
> > do about it. Gerald, if you feel strongly about this issue, please file
> it.
>
> Note we already have a release criterion related to this:
>
> "All system services present after installation with one of the
> release-blocking package sets must start properly, unless they require
> hardware which is not present."
>
> That lets out the rngd and Intel vs. AMD cases, I guess - it is
> specifically written to do so, after we decided once that we didn't
> want to block the release on the rngd case or one like it - but it
> would cover the Secure Boot case at least.
> --
> 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/PCKI2JZ54TWHRMFTQAIQP333K5W7MPUQ/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F

Re: Services that shouldn't be started in the first place: Was F29... hide.. grub

On Thu, 2018-06-21 at 12:08 -0400, Stephen Gallagher wrote:
> On Thu, Jun 21, 2018 at 12:03 PM Gerald B. Cox  wrote:
> 
> > 
> > 
> > On Thu, Jun 21, 2018 at 6:39 AM, Stephen Gallagher 
> > wrote:
> > 
> > > 
> > > 
> > > 
> > > > I believe we're missing something fundamental here.  If a
> > > > program/service etc. requires specific hardware to work
> > > > and it can't gracefully handle situations where that hardware is not
> > > > present - it shouldn't be a default.
> > > > 
> > > > The way to handle this (and other similar situations) is to take away
> > > > the default status until it can handle
> > > > situations where the hardware doesn't exist.  This is systems
> > > > programming 101 - and frankly I am a
> > > > bit surprised it's a matter of debate.
> > > > 
> > > > 
> > > 
> > > No one on this list is disagreeing that the defaults should not degrade
> > > the system. I *do* think that your response is an overreaction: just
> > > because software may have bugs on your hardware doesn't mean that it 
> > > should
> > > be turned off entirely. If it's causing problems for a small subset of
> > > users, they can be manually disabled.
> > > 
> > > These services provide CONSIDERABLE benefit on the hardware that supports
> > > it. Removing that as a default for those systems would be a significant
> > > regression. That's not an acceptable solution.
> > > 
> > > Most of the people on this thread seem to agree: we can conditionalize
> > > the defaults so it is either skipped or at least does not mark the service
> > > as "failed" if the necessary hardware is not present. People are already
> > > working on doing this.
> > > 
> > 
> > Stephen, I'm not disputing the benefit - and I very much appreciate the
> > fact that people are working to conditionalize the defaults.  What I do
> > disagree with is your characterization that this is a bug.
> > It is working as it was designed - and the design is faulty - and it's
> > pervasive.  I've encountered THREE different processes that aren't properly
> > conditionalized.  That's definitely not a bug - that's a systemic issue.
> > Yes, AMD processors are not as popular as Intel, but they do exist in
> > considerable numbers and most definitely should be
> > considered when things are implemented as defaults; additionally...
> > obviously... not everybody uses SecureBoot.
> > My comment regarding taking away default status was in regards to this
> > lingering for years.
> > I personally don't believe that is acceptable.  If one can't figure out
> > how to fix things like this in a timely manner, then there is a problem.
> > 
> > 
> 
> Well, there was also a failure of escalation path here. If this was going
> on for years without a resolution, why wasn't it raised on this list or to
> FESCo a long time ago? Individual maintainers have their own priorities and
> time constraints and don't always address every bug that comes their way.
> 
> However, had it risen up the chain, it's possible a group like FESCo might
> take note and set down some rules/requirements. As it is, I think it's
> probably time right now to move this to a FESCo ticket and see what we can
> do about it. Gerald, if you feel strongly about this issue, please file it.

Note we already have a release criterion related to this:

"All system services present after installation with one of the
release-blocking package sets must start properly, unless they require
hardware which is not present."

That lets out the rngd and Intel vs. AMD cases, I guess - it is
specifically written to do so, after we decided once that we didn't
want to block the release on the rngd case or one like it - but it
would cover the Secure Boot case at least.
-- 
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/PCKI2JZ54TWHRMFTQAIQP333K5W7MPUQ/

Re: [Modularity] Module streams with two different, non-overlapping, package sets?

On Thu, Jun 21, 2018 at 11:56 AM Mikolaj Izdebski 
wrote:

> On 06/20/2018 04:15 PM, Stephen Gallagher wrote:
> > On Wed, Jun 20, 2018 at 10:06 AM Mikolaj Izdebski 
> > wrote:
> >
> >> On 06/20/2018 02:30 PM, Petr Šabata wrote:
> >>> Parallel installation of streams on a single system indeed
> >>> isn't supported at this point and isn't planned anytime in the
> >>> near future.  In general it's a more complicated problem than
> >>> it might seem at first.
> >>
> >> Could you elaborate and explain what's so complicated about it?
> >>
> >
> > The short answer is that there exists no generic solution for
> > parallel-installation. Many packages rely on well-known resources[1] and
> > cannot be parallel-installed at all. Other packages *may* support
> > parallel-installation but consumers must take special steps to enable
> > support for it.
>
> In general case, when packages conflict, I would agree. But as subject
> says, this is about a special case - non-overlapping, non-conflicting
> package sets, which can be installed in parallel without taking any
> special steps, like java-1.8.0-openjdk and java-11-openjdk that were
> brought up in the first message.
>
>
Yes, but in order to support that in Modularity, we would need a
general-case solution that would work for all packages. Just because *some*
RPMs don't conflict between versions doesn't mean that a generic solution
can be built for all RPMs.


> > I don't have a good link right now, but folks at Red Hat did a number of
> > customer studies and determined that in real-world deployments,
> > parallel-installation was very rarely used. Generally, the OS was
> > established with a standard set of packages and then anything that needed
> > an alternate version was deployed as a VM or container.
>
> Some packages are designed to be parallel-installable for a reason -
> because users expect and require that. OpenJDK is an example of such
> package. Even different version-releases of the same component can be,
> by design, installed in parallel.
>
>
Sure, and that's why we recommend that in THIS case, you would probably
build a separate module (or use standard RPMs) instead.


> > So, when we started looking at ways to provide alternative software, we
> > determined that parallel-installation was a non-goal. Not needing to
> solve
> > an unsolvable problem meant that we could focus on the parts that really
> > matter: allowing people to select which single version of the software
> > meets their needs.
>
> So the conclusion is that inability to have parallel-installable streams
> of the same module is not due to technical difficulties to implement
> that feature, but rather a consequence of prioritizing different
> requirements.
>
>
You drew a conclusion that is EXACTLY the opposite of what I said above. We
determined that parallel-installation was basically impossible to build in
a generic way. Once that was eliminated as a possible requirement, the rest
fell into place fairly neatly.
___
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/IUE4AYMCCIFI74STTB45GVCK6Y24VU2T/

Re: Services that shouldn't be started in the first place: Was F29... hide.. grub

Stephen,

Yes, unfortunately, it appears that is needed.  I'll create a ticket.

Thanks Stephen.

On Thu, Jun 21, 2018 at 9:08 AM, Stephen Gallagher 
wrote:

>
>
> On Thu, Jun 21, 2018 at 12:03 PM Gerald B. Cox  wrote:
>
>>
>>
>> On Thu, Jun 21, 2018 at 6:39 AM, Stephen Gallagher 
>> wrote:
>>
>>>
>>>
>>>
 I believe we're missing something fundamental here.  If a
 program/service etc. requires specific hardware to work
 and it can't gracefully handle situations where that hardware is not
 present - it shouldn't be a default.

 The way to handle this (and other similar situations) is to take away
 the default status until it can handle
 situations where the hardware doesn't exist.  This is systems
 programming 101 - and frankly I am a
 bit surprised it's a matter of debate.


>>> No one on this list is disagreeing that the defaults should not degrade
>>> the system. I *do* think that your response is an overreaction: just
>>> because software may have bugs on your hardware doesn't mean that it should
>>> be turned off entirely. If it's causing problems for a small subset of
>>> users, they can be manually disabled.
>>>
>>> These services provide CONSIDERABLE benefit on the hardware that
>>> supports it. Removing that as a default for those systems would be a
>>> significant regression. That's not an acceptable solution.
>>>
>>> Most of the people on this thread seem to agree: we can conditionalize
>>> the defaults so it is either skipped or at least does not mark the service
>>> as "failed" if the necessary hardware is not present. People are already
>>> working on doing this.
>>>
>>
>> Stephen, I'm not disputing the benefit - and I very much appreciate the
>> fact that people are working to conditionalize the defaults.  What I do
>> disagree with is your characterization that this is a bug.
>> It is working as it was designed - and the design is faulty - and it's
>> pervasive.  I've encountered THREE different processes that aren't properly
>> conditionalized.  That's definitely not a bug - that's a systemic issue.
>> Yes, AMD processors are not as popular as Intel, but they do exist in
>> considerable numbers and most definitely should be
>> considered when things are implemented as defaults; additionally...
>> obviously... not everybody uses SecureBoot.
>> My comment regarding taking away default status was in regards to this
>> lingering for years.
>> I personally don't believe that is acceptable.  If one can't figure out
>> how to fix things like this in a timely manner, then there is a problem.
>>
>>
> Well, there was also a failure of escalation path here. If this was going
> on for years without a resolution, why wasn't it raised on this list or to
> FESCo a long time ago? Individual maintainers have their own priorities and
> time constraints and don't always address every bug that comes their way.
>
> However, had it risen up the chain, it's possible a group like FESCo might
> take note and set down some rules/requirements. As it is, I think it's
> probably time right now to move this to a FESCo ticket and see what we can
> do about it. Gerald, if you feel strongly about this issue, please file 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/YJOUFL2QBIQHZL5I52TLPZIA4VJLM6YK/
>
>
___
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/WB6HGXAVFXTF7YFQXZAT4TRL77KT5O73/

Re: FESCo Elections - May 2018 : Results announcement

2018-06-21 Thread Kevin Fenzi

On 06/21/2018 08:53 AM, David Malcolm wrote:
> On Fri, 2018-06-15 at 00:01 +0200, Till Maas wrote:
>> On Thu, Jun 14, 2018 at 08:02:33AM -0500, Michael Cronenworth wrote:
>>> On 06/14/2018 03:42 AM, Pierre-Yves Chibon wrote:
 I know we never manage to motivate many people to vote, but 86
 votes is really
 low, even for us:(
>>>
>>> Yes, I was checking out the voter count on other pollings and the
>>> turnout is
>>> around 100. Disappointing. :(
>>>
>>> Lack of awareness or advertising? I voted.
>>
>> I assume lack of badges for voting, misalignment with the other
>> elections and not enough contributors/candidates.
>>
>> Also in the past there were wore blog posts about people who voted on
>> planet etc.
>>
>> Kind regards
>> Till
> 
> It struck me that we could have "I Voted" badges in the Fedora badges
> subsystem, so I've filed:
> "Family of badges for voting in Fedora elections: "I Voted""
>   https://pagure.io/fedora-badges/issue/626
> 
> (possibly with an element of penance for forgetting to vote myself)
See: https://pagure.io/fedora-badges/issue/45

basically they were proposed, but people objected to the elections app
emitting fedmsgs when people voted, so it was decided they should be
'claimable' from the elections app after you voted (or anytime after)

However, it looks like that was never implemented in the elections app:
https://pagure.io/elections/issue/45

So, we just need to implement that and we get badges going for it.

I'm not sure how hard that would be off hand.

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/NLBTLBOGN2YUQ7YXAQWVOY72B55B7JXD/

Re: F29 System Wide Change: Make BootLoaderSpec the default

On Thu, Jun 21, 2018 at 10:04:03AM -0400, Colin Walters wrote:
> 
> 
> On Thu, Jun 21, 2018, at 9:41 AM, Gerd Hoffmann wrote:
> >
> > Well, as *additional* variant it doesn't provide that much value.  More
> > interesting would be to create all x86 cloud images that way, so they
> > boot just fine on both bios and efi, and we don't have to bother
> > creating two image variants.
> 
> We aren't creating two[1] image variants today.  Why would we?  Who
> would use them and why?

Well, sooner or later we will have to make the switch to uefi in
virtualization, following the trend on physical hardware which ships
with uefi firmware since years.  And having cloud images which work
fine with both bios and uefi will make the transition easier ...

cheers,
  Gerd
___
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/AMHRLHKX6FXKYFI4PFKNHPURUROMPTQ2/

Re: FESCo Elections - May 2018 : Results announcement

2018-06-21 Thread Matthew Miller

On Thu, Jun 21, 2018 at 11:53:13AM -0400, David Malcolm wrote:
> It struck me that we could have "I Voted" badges in the Fedora badges
> subsystem, so I've filed:
> "Family of badges for voting in Fedora elections: "I Voted""
>   https://pagure.io/fedora-badges/issue/626
> (possibly with an element of penance for forgetting to vote myself)

This has been suggested before, but there was a lot of pushback on the
anonymity issue. Personally, I think having a "Get my badge for voting"
checkbox — or even a final button — is a fine compromise.

-- 
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/SQWLLIZRQD4Y7O62GNRFSEBKIWOVUXFI/

Re: Services that shouldn't be started in the first place: Was F29... hide.. grub

On Thu, Jun 21, 2018 at 12:03 PM Gerald B. Cox  wrote:

>
>
> On Thu, Jun 21, 2018 at 6:39 AM, Stephen Gallagher 
> wrote:
>
>>
>>
>>
>>> I believe we're missing something fundamental here.  If a
>>> program/service etc. requires specific hardware to work
>>> and it can't gracefully handle situations where that hardware is not
>>> present - it shouldn't be a default.
>>>
>>> The way to handle this (and other similar situations) is to take away
>>> the default status until it can handle
>>> situations where the hardware doesn't exist.  This is systems
>>> programming 101 - and frankly I am a
>>> bit surprised it's a matter of debate.
>>>
>>>
>> No one on this list is disagreeing that the defaults should not degrade
>> the system. I *do* think that your response is an overreaction: just
>> because software may have bugs on your hardware doesn't mean that it should
>> be turned off entirely. If it's causing problems for a small subset of
>> users, they can be manually disabled.
>>
>> These services provide CONSIDERABLE benefit on the hardware that supports
>> it. Removing that as a default for those systems would be a significant
>> regression. That's not an acceptable solution.
>>
>> Most of the people on this thread seem to agree: we can conditionalize
>> the defaults so it is either skipped or at least does not mark the service
>> as "failed" if the necessary hardware is not present. People are already
>> working on doing this.
>>
>
> Stephen, I'm not disputing the benefit - and I very much appreciate the
> fact that people are working to conditionalize the defaults.  What I do
> disagree with is your characterization that this is a bug.
> It is working as it was designed - and the design is faulty - and it's
> pervasive.  I've encountered THREE different processes that aren't properly
> conditionalized.  That's definitely not a bug - that's a systemic issue.
> Yes, AMD processors are not as popular as Intel, but they do exist in
> considerable numbers and most definitely should be
> considered when things are implemented as defaults; additionally...
> obviously... not everybody uses SecureBoot.
> My comment regarding taking away default status was in regards to this
> lingering for years.
> I personally don't believe that is acceptable.  If one can't figure out
> how to fix things like this in a timely manner, then there is a problem.
>
>
Well, there was also a failure of escalation path here. If this was going
on for years without a resolution, why wasn't it raised on this list or to
FESCo a long time ago? Individual maintainers have their own priorities and
time constraints and don't always address every bug that comes their way.

However, had it risen up the chain, it's possible a group like FESCo might
take note and set down some rules/requirements. As it is, I think it's
probably time right now to move this to a FESCo ticket and see what we can
do about it. Gerald, if you feel strongly about this issue, please file 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/YJOUFL2QBIQHZL5I52TLPZIA4VJLM6YK/

Re: Services that shouldn't be started in the first place: Was F29... hide.. grub

On Thu, Jun 21, 2018 at 6:39 AM, Stephen Gallagher 
wrote:

>
>
>
>> I believe we're missing something fundamental here.  If a program/service
>> etc. requires specific hardware to work
>> and it can't gracefully handle situations where that hardware is not
>> present - it shouldn't be a default.
>>
>> The way to handle this (and other similar situations) is to take away the
>> default status until it can handle
>> situations where the hardware doesn't exist.  This is systems programming
>> 101 - and frankly I am a
>> bit surprised it's a matter of debate.
>>
>>
> No one on this list is disagreeing that the defaults should not degrade
> the system. I *do* think that your response is an overreaction: just
> because software may have bugs on your hardware doesn't mean that it should
> be turned off entirely. If it's causing problems for a small subset of
> users, they can be manually disabled.
>
> These services provide CONSIDERABLE benefit on the hardware that supports
> it. Removing that as a default for those systems would be a significant
> regression. That's not an acceptable solution.
>
> Most of the people on this thread seem to agree: we can conditionalize the
> defaults so it is either skipped or at least does not mark the service as
> "failed" if the necessary hardware is not present. People are already
> working on doing this.
>

Stephen, I'm not disputing the benefit - and I very much appreciate the
fact that people are working to conditionalize the defaults.  What I do
disagree with is your characterization that this is a bug.
It is working as it was designed - and the design is faulty - and it's
pervasive.  I've encountered THREE different processes that aren't properly
conditionalized.  That's definitely not a bug - that's a systemic issue.
Yes, AMD processors are not as popular as Intel, but they do exist in
considerable numbers and most definitely should be
considered when things are implemented as defaults; additionally...
obviously... not everybody uses SecureBoot.
My comment regarding taking away default status was in regards to this
lingering for years.
I personally don't believe that is acceptable.  If one can't figure out how
to fix things like this in a timely manner, then there is a problem.
___
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/KJSDTXYB7HGFPJJZ7DL34QQPU6MWN2R4/

Re: [Modularity] Module streams with two different, non-overlapping, package sets?

2018-06-21 Thread Mikolaj Izdebski

On 06/20/2018 04:15 PM, Stephen Gallagher wrote:
> On Wed, Jun 20, 2018 at 10:06 AM Mikolaj Izdebski 
> wrote:
> 
>> On 06/20/2018 02:30 PM, Petr Šabata wrote:
>>> Parallel installation of streams on a single system indeed
>>> isn't supported at this point and isn't planned anytime in the
>>> near future.  In general it's a more complicated problem than
>>> it might seem at first.
>>
>> Could you elaborate and explain what's so complicated about it?
>>
> 
> The short answer is that there exists no generic solution for
> parallel-installation. Many packages rely on well-known resources[1] and
> cannot be parallel-installed at all. Other packages *may* support
> parallel-installation but consumers must take special steps to enable
> support for it.

In general case, when packages conflict, I would agree. But as subject
says, this is about a special case - non-overlapping, non-conflicting
package sets, which can be installed in parallel without taking any
special steps, like java-1.8.0-openjdk and java-11-openjdk that were
brought up in the first message.

> I don't have a good link right now, but folks at Red Hat did a number of
> customer studies and determined that in real-world deployments,
> parallel-installation was very rarely used. Generally, the OS was
> established with a standard set of packages and then anything that needed
> an alternate version was deployed as a VM or container.

Some packages are designed to be parallel-installable for a reason -
because users expect and require that. OpenJDK is an example of such
package. Even different version-releases of the same component can be,
by design, installed in parallel.

> So, when we started looking at ways to provide alternative software, we
> determined that parallel-installation was a non-goal. Not needing to solve
> an unsolvable problem meant that we could focus on the parts that really
> matter: allowing people to select which single version of the software
> meets their needs.

So the conclusion is that inability to have parallel-installable streams
of the same module is not due to technical difficulties to implement
that feature, but rather a consequence of prioritizing different
requirements.

-- 
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
___
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/WMAO2HRVCJMP23NL6XKYPZFPCULY6FF3/

Re: FESCo Elections - May 2018 : Results announcement

2018-06-21 Thread David Malcolm

On Fri, 2018-06-15 at 00:01 +0200, Till Maas wrote:
> On Thu, Jun 14, 2018 at 08:02:33AM -0500, Michael Cronenworth wrote:
> > On 06/14/2018 03:42 AM, Pierre-Yves Chibon wrote:
> > > I know we never manage to motivate many people to vote, but 86
> > > votes is really
> > > low, even for us:(
> > 
> > Yes, I was checking out the voter count on other pollings and the
> > turnout is
> > around 100. Disappointing. :(
> > 
> > Lack of awareness or advertising? I voted.
> 
> I assume lack of badges for voting, misalignment with the other
> elections and not enough contributors/candidates.
> 
> Also in the past there were wore blog posts about people who voted on
> planet etc.
> 
> Kind regards
> Till

It struck me that we could have "I Voted" badges in the Fedora badges
subsystem, so I've filed:
"Family of badges for voting in Fedora elections: "I Voted""
  https://pagure.io/fedora-badges/issue/626

(possibly with an element of penance for forgetting to vote myself)
___
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/QOVB2M5VRTBWDOHJ6Y5PUBLEFEFHDLZU/

Re: i686 kernel missing on rawhide / disabling archs in critical path pkgs

2018-06-21 Thread Laura Abbott

On 06/21/2018 01:50 AM, Daniel P. Berrangé wrote:

The kernel change that introduced the i686 build problem was just a
rebase between 2 arbitrary pre-release git snapshots. I don't really
a compelling justification to rebase to a known broken snapshot,
without allowing time for x86 SIG to resolve it first. AFAIK there
was no prior warning or request for help - i686 was just disabled
immediately and other package maintainers left to deal with the
consequences of broken deps.
>
A more pragmatic approach would have been to report the problem to the

x86 SIG and then *not* do the rebase for some reasonable period of time
(perhaps 1 week grace period), to allow for the problem to be addressed.
Only disable the i686 build if there is no solution is forthcoming, thus
avoiding causing this pain for a whole chain of packages/maintainers in
Fedora.

I'll admit to not realizing just how many problems disabling this
would cause so I do apologize for that. This came in during the
merge window when we really want to be getting things out to test
so it seemed worth it to just disable it and move on.

Having said all this, the message about brokenness on x86 SIG mailing
list doesn't appear to be treated with the urgency I think it needs,
givin the ripple effect it has from a critical path package. There were
a few messages the day after it was reported, and then nothing until
Wednesday.

The silence on the mailing list is an example of why I didn't try
asking first before rebasing. I know there are a few people who are
very passionate about i686 but the fact of the matter is the response
rate for actual problems has been very low. If someone had responded
with "this will be fixed by date X" I would have been willing to
revert and wait but that's a big part of the issue: nobody is driving
or setting direction. If someone had even told me "Talk to person X
instead of just the mailing list" I would have done that as well.

Thorsten Leemhuis also pointed out this problem has been going
on for a while https://bugzilla.redhat.com/show_bug.cgi?id=1592374#c1

For a package that is critical path like the kernel, I'd expect this
to be a top priority item to resolve with immediate effect because of
the broad impact it has on other maintainers. Maybe this has been
happening in the background, with no activity visible on the mailing
list, if so I apologize in advance.

I encourage you to file a ticket with FESCO.

Regards,
Daniel

Thanks,
Laura
___
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/YBB7C55D3MTKWA4BARPSTBQWEWAD35NX/

Re: F29 System Wide Change: Make BootLoaderSpec the default

2018-06-21 Thread Colin Walters

On Thu, Jun 21, 2018, at 9:41 AM, Gerd Hoffmann wrote:
>
> Well, as *additional* variant it doesn't provide that much value.  More
> interesting would be to create all x86 cloud images that way, so they
> boot just fine on both bios and efi, and we don't have to bother
> creating two image variants.

We aren't creating two[1] image variants today.  Why would we?  Who
would use them and why?

> Why do you need that?  Wouldn't FAH just drop a new file for the new
> version into /boot/loader/entries on updates?  So you have old and new
> version listed in the boot menu and can easily rollback to the old
> version if needed?

The entire design of libostree is around being able to transactionally
swap the bootloader configuration.  While preparing an update, we
temporarily have *three* deployments on disk (new, current, and rollback),
but only two bootloader entries.  If we weren't able to do a full
transactional replacement then we'd have to deal with possibly
having three entries, and be able to clean that up afterwards.
Which we could do - particularly now that we have
https://github.com/ostreedev/ostree/pull/1464
and it's easier for admins to control what's available locally, and we
can assume that we can just GC other things.

[1] For BIOS/UEFI - clearly there are a ton of image variants in general
___
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/H3O7QDPZWA4YXIWNSJOHFHJKOZKJC2SW/

Re: F29 System Wide Change: Modules for Everyone

On Thu, Jun 21, 2018 at 9:43 AM Stephen John Smoogen 
wrote:

> On 21 June 2018 at 09:05, Stephen Gallagher  wrote:
> >
> >
> > On Thu, Jun 21, 2018 at 8:51 AM Petr Pisar  wrote:
> >>
> >> On 2018-06-21, Stephen Gallagher  wrote:
> >> > On Thu, Jun 21, 2018 at 5:17 AM Kevin Kofler 
> >> > wrote:
> >> >> Will the repositories be enabled or disabled by default?
> >> >>
> >> >
> >> > Enabled by default. Packaging policy will require that modules with a
> >> > default stream may not override packages in the standard repo.
> >> >
> >> How are packagers supposed to implement a seamless move from a bare
> >> package to
> >> a module not to disrupt users?
> >>
> >> Example: I have a gscan2pdf package that I want to move to a module.
> >> According to the policy firtst I have to remove the package from
> >> a repository. Now the user cannot install the package. Then the module
> >> review will be approved and the module built. And finally package is
> >> available to users again.
> >>
> >> I don't think this is a great user experience.
> >
> >
> > I oversimplified that last statement, sorry. I shouldn't post before
> > breakfast. What you're requesting is permissible; if you are the
> maintainer
> > of a package and want to move it into a module with a default stream to
> > replace the version in the standard repos, that's fine.
> >
> > My statement was more about protecting against "I have Node.js 8.x in the
> > traditional repos, but 10.x in the default module stream, which overrides
> > it, thus resulting in a different experience with and without the modular
> > repos enabled." If you decide to replace a package with a module default
> > stream, it will need to follow the stable updates policy for the current
> > Fedora release. (So if I wanted to move from Node.js 8.x bare RPMs to a
> > module, then the 8.x module stream would have to be the default, not
> 10.x).
> >
>
> Maybe I am misunderstanding it, but this is the scenario this brings up:
>
> Say I have a package which has now required NodeJS 10.x so I need to
> put that as a requirement to fix a bug. In my mind, I am not replacing
> Nodejs because it isn't my package.. it is just something that the OS
> is providing. I put in the Requires and fix my problem..
>
> To the user, that causes a problem because it then replaces their
> Nodejs-8 they may have been using for some other app.
>
> What is going to warn me/stop me that I should not have done that
> before the package gets into updates?
>
>
It's going to fail the dependency check in Bodhi and you will get an email.
If it depends on a non-default stream, then it must be built as a module
that depends on that non-default stream.
___
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/XEBETDJPR77F26HMVMXIMU4P7SNQ4ORG/

Re: F29 System Wide Change: Modules for Everyone

2018-06-21 Thread Stephen John Smoogen

On 21 June 2018 at 09:05, Stephen Gallagher  wrote:
>
>
> On Thu, Jun 21, 2018 at 8:51 AM Petr Pisar  wrote:
>>
>> On 2018-06-21, Stephen Gallagher  wrote:
>> > On Thu, Jun 21, 2018 at 5:17 AM Kevin Kofler 
>> > wrote:
>> >> Will the repositories be enabled or disabled by default?
>> >>
>> >
>> > Enabled by default. Packaging policy will require that modules with a
>> > default stream may not override packages in the standard repo.
>> >
>> How are packagers supposed to implement a seamless move from a bare
>> package to
>> a module not to disrupt users?
>>
>> Example: I have a gscan2pdf package that I want to move to a module.
>> According to the policy firtst I have to remove the package from
>> a repository. Now the user cannot install the package. Then the module
>> review will be approved and the module built. And finally package is
>> available to users again.
>>
>> I don't think this is a great user experience.
>
>
> I oversimplified that last statement, sorry. I shouldn't post before
> breakfast. What you're requesting is permissible; if you are the maintainer
> of a package and want to move it into a module with a default stream to
> replace the version in the standard repos, that's fine.
>
> My statement was more about protecting against "I have Node.js 8.x in the
> traditional repos, but 10.x in the default module stream, which overrides
> it, thus resulting in a different experience with and without the modular
> repos enabled." If you decide to replace a package with a module default
> stream, it will need to follow the stable updates policy for the current
> Fedora release. (So if I wanted to move from Node.js 8.x bare RPMs to a
> module, then the 8.x module stream would have to be the default, not 10.x).
>

Maybe I am misunderstanding it, but this is the scenario this brings up:

Say I have a package which has now required NodeJS 10.x so I need to
put that as a requirement to fix a bug. In my mind, I am not replacing
Nodejs because it isn't my package.. it is just something that the OS
is providing. I put in the Requires and fix my problem..

To the user, that causes a problem because it then replaces their
Nodejs-8 they may have been using for some other app.

What is going to warn me/stop me that I should not have done that
before the package gets into updates?

-- 
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/XNWZOQPYOTE36EPILHAVQGYJ2AGMM3F7/

[Bug 1593698] perl-Getopt-Lucid-1.09 is available

2018-06-21 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-Getopt-Lucid-1.09-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-4d5adefc9d

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org/message/JDIR3MBCCJ66LPKCGTJQKQVUV3CQ5EW7/

Re: F29 System Wide Change: Make BootLoaderSpec the default

  Hi,

> From my perspective (Fedora CoreOS developer) that straddles
> both physical and cloud for the server case, the problem is that
> the virtualized case, and in particular public cloud, and really
> specifically EC2 - no one really cares about EFI to boot their VMs.

Indeed.  And it sucks.

> >   Device   Start End Sectors  Size Type
> >   /dev/sda1 2048   1023981924M BIOS boot
> >   /dev/sda210240 1058815 1048576  512M EFI System
> 
> I wouldn't *oppose* that; in fact if you (or someone else)
> wanted to push for that with e.g. Fedora CoreOS, I'd be happy
> to discuss it.  But it's not like it has a truly compelling advantage
> over what we ship today - it'd just be *another* weird variant
> of things in the end right?

Well, as *additional* variant it doesn't provide that much value.  More
interesting would be to create all x86 cloud images that way, so they
boot just fine on both bios and efi, and we don't have to bother
creating two image variants.

> And the fact that FAT has no ability to do atomic replacement bothers
> me a lot. (A wrinkle here is that ostree implements an atomic swap of
> /boot/loader - you can today boot FAH/Silverblue and just ls -al /boot
> to see it)

Why do you need that?  Wouldn't FAH just drop a new file for the new
version into /boot/loader/entries on updates?  So you have old and new
version listed in the boot menu and can easily rollback to the old
version if needed?

But anyway: The scheme works with and without separate /boot.

cheers,
  Gerd
___
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/L4Q7ILZRWGWGVH77UCVMWG52FMATLR5X/

Re: Services that shouldn't be started in the first place: Was F29... hide.. grub

On Wed, Jun 20, 2018 at 8:54 PM Gerald B. Cox  wrote:

> On Wed, Jun 20, 2018 at 3:26 PM, Adam Williamson <
> adamw...@fedoraproject.org> wrote:
>
>> On Wed, 2018-06-20 at 13:15 -0400, Stephen Gallagher wrote:
>> > On Wed, Jun 20, 2018 at 12:34 PM Gerald B. Cox  wrote:
>> >
>> > The proper behavior here would be for these services not to be marked as
>> > "failed" when the appropriate hardware is not present. When possible, we
>> > should be using systemd's Condition* features to skip attempting to
>> start
>> > it at all, but for things where we can't know it ahead of time, we
>> should
>> > modify the start script to look for appropriate error codes/messages and
>> > treat the service as "success" if it's skipped because it's not
>> supported
>> > on the current hardware.
>>
>> Well, for rngd, the maintainer actually argued that he does *not* think
>> this is the "proper" behaviour. See
>> https://bugzilla.redhat.com/show_bug.cgi?id=1490632#c11 . I don't agree
>> with him (as you can, er, tell from the subsequent discussion), but it
>> seemed worth noting it's not a universally agreed truth.
>>
>> (I don't *think* he'd object to a Condition-type fix, though, if we
>> could come up with a reliable one).
>>
>> I believe we're missing something fundamental here.  If a program/service
> etc. requires specific hardware to work
> and it can't gracefully handle situations where that hardware is not
> present - it shouldn't be a default.
>
> The way to handle this (and other similar situations) is to take away the
> default status until it can handle
> situations where the hardware doesn't exist.  This is systems programming
> 101 - and frankly I am a
> bit surprised it's a matter of debate.
>
>
No one on this list is disagreeing that the defaults should not degrade the
system. I *do* think that your response is an overreaction: just because
software may have bugs on your hardware doesn't mean that it should be
turned off entirely. If it's causing problems for a small subset of users,
they can be manually disabled.

These services provide CONSIDERABLE benefit on the hardware that supports
it. Removing that as a default for those systems would be a significant
regression. That's not an acceptable solution.

Most of the people on this thread seem to agree: we can conditionalize the
defaults so it is either skipped or at least does not mark the service as
"failed" if the necessary hardware is not present. People are already
working on doing 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/UQYDWO6O3SOCJPCWHL66PVQADIDKBD4R/

Re: FESCo Elections - May 2018 : Results announcement

2018-06-21 Thread William Moreno

>
> I think that might have a lot to do with the turnout, indeed. I believe
>> there's a general perception in the community that FESCo has been doing a
>> good job, and there's not really any significant issues involved in the
>> election.
>>
>
> But also, consider election burnout. FESCo, Mindshare, and Council
> elections, every six months or thereabouts... it turns out to be a lot,
> right? We've had nine completed elections in the past year, or fourteen if
> you count the five cancelled elections. [1] That's a quirk of our releases
> not being exactly six months apart, but it's also kind of a lot, right?
> Reading the interviews for the same candidates again and again each year
> gets old pretty fast. So if we want to increase turnout and improve our
> elections, the first thing I would do is make the elections less frequent,
> to reduce voter burnout, e.g. once hold them all once per year (for three
> elections per year) instead of twice per year.
>
>
I do agree here, +1
___
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/IJDJ2LWWTJC4TPZMBEW2Z2EZYVFKQIRY/

Re: FESCo Elections - May 2018 : Results announcement

2018-06-21 Thread Michael Cronenworth


On 06/21/2018 01:46 AM, Ralf Corsepius wrote:
I did not, because I could not find any suitable candidates and did not see any 
reason to vote. 


Ralf,

It's great to see you. Every comment seems to be a polar opposite of anyone that has 
a discussion.


You know you can vote "0" and no candidates get your vote, but the voter count will 
still tick up.


FYI.
___
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/RCWE2VSH43WJDQIW7YWXCGR2I3G6RHIQ/

Re: Heads up: Python 3.7 rebuild in progress

2018-06-21 Thread Miro Hrončok


On 20.6.2018 19:24, Raphael Groner wrote:

FTBFS of jpype. Please be aware of PEP 432. No idea if upstream needs to 
provide a fix.


https://github.com/originell/jpype/pull/332

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/JCVLMIBUALG3OYTXSRPHAMMUWBTRNNNW/

Re: F29 System Wide Change: Modules for Everyone

On Thu, Jun 21, 2018 at 8:51 AM Petr Pisar  wrote:

> On 2018-06-21, Stephen Gallagher  wrote:
> > On Thu, Jun 21, 2018 at 5:17 AM Kevin Kofler 
> wrote:
> >> Will the repositories be enabled or disabled by default?
> >>
> >
> > Enabled by default. Packaging policy will require that modules with a
> > default stream may not override packages in the standard repo.
> >
> How are packagers supposed to implement a seamless move from a bare
> package to
> a module not to disrupt users?
>
> Example: I have a gscan2pdf package that I want to move to a module.
> According to the policy firtst I have to remove the package from
> a repository. Now the user cannot install the package. Then the module
> review will be approved and the module built. And finally package is
> available to users again.
>
> I don't think this is a great user experience.
>

I oversimplified that last statement, sorry. I shouldn't post before
breakfast. What you're requesting is permissible; if you are the maintainer
of a package and want to move it into a module with a default stream to
replace the version in the standard repos, that's fine.

My statement was more about protecting against "I have Node.js 8.x in the
traditional repos, but 10.x in the default module stream, which overrides
it, thus resulting in a different experience with and without the modular
repos enabled." If you decide to replace a package with a module default
stream, it will need to follow the stable updates policy for the current
Fedora release. (So if I wanted to move from Node.js 8.x bare RPMs to a
module, then the 8.x module stream would have to be the default, not 10.x).
___
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/WFOIZM4JBXCCF5SG4CAQAKNW4UP3R6MY/

Re: F29 System Wide Change: Modules for Everyone

2018-06-21 Thread Petr Pisar

On 2018-06-21, Stephen Gallagher  wrote:
> On Thu, Jun 21, 2018 at 5:17 AM Kevin Kofler  wrote:
>> Will the repositories be enabled or disabled by default?
>>
>
> Enabled by default. Packaging policy will require that modules with a
> default stream may not override packages in the standard repo.
>
How are packagers supposed to implement a seamless move from a bare package to
a module not to disrupt users?

Example: I have a gscan2pdf package that I want to move to a module.
According to the policy firtst I have to remove the package from
a repository. Now the user cannot install the package. Then the module
review will be approved and the module built. And finally package is
available to users again.

I don't think this is a great user experience.

-- 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/NB4BV236KDPXD2QCGKTS4TIPFZR3NMFR/

Re: F29 System Wide Change: Modules for Everyone

On Thu, Jun 21, 2018 at 5:17 AM Kevin Kofler  wrote:

> Jan Kurik wrote:
> > In Fedora 28, the Server Edition debuted new modular functionality,
> > allowing end-users access to alternative versions of popular software.
> Due
> > to technical limitations with package-management software, it was not
> > available for non-Server deployments of Fedora. Beginning with Fedora 29,
> > all installations of Fedora will have modules available for installation
> > and update. This will be done by merging the `fedora-repos-modular`
> > sub-package back into the `fedora-repos` package.
>
> Will the repositories be enabled or disabled by default?
>

Enabled by default. Packaging policy will require that modules with a
default stream may not override packages in the standard repo.
___
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/SKEQRWOGYKQIYS2UPEVBIGWJS4FIMK33/

Re: No kernel on i686

2018-06-21 Thread Josh Boyer

On Thu, Jun 21, 2018 at 4:50 AM Richard W.M. Jones  wrote:
>
> Just wanted to bring this to wider attention:
>
>   https://bugzilla.redhat.com/show_bug.cgi?id=1592374
>   https://bugzilla.redhat.com/show_bug.cgi?id=1593411
>   
> https://lists.fedoraproject.org/archives/list/x...@lists.fedoraproject.org/thread/YCBS5Y33YFBN2NPNPRUH6YJQFB5CVQ4F/
>
> There is no kernel being built on i686.  This breaks several
> assumptions:
>
> (1) Any package which depends on a kernel module by requiring
> ‘kmod(foo.ko)’ will no longer be installable on i686.  If it
> BuildRequires the package it will FTBFS.
>
> Packages affected:
>  - batctl
>  - floppy-support
>  - gfs2-utils
>  - joystick-support
>  - snapd
>  - usbip
>  - xl2tpd
>
> (2) Any package which depends on ‘kernel-devel’ or
> ‘kernel-devel-uname-r’ will no longer be installable.  If it
> BuildRequires the package it will FTBFS.
>
> Packages affected (some of these may be from rpmfusion):
>  - akmods
>  - bcc-tools
>  - dkms
>  - systemtap-devel  [this causes lots of packages to FTBFS]
>
> My real question: Is this going to be a long-term state of affairs?
> Should I start dropping dependencies / stop building stuff which needs
> a kernel on i686?  Or should we wait it out?

The x86 SIG was emailed about the issue preventing the kernel from
building.  I'm not sure if they've responded.  If the SIG needs help
with the thing they're supposed to be tasked with, they should reach
out to see if there are others that are willing to debug.

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/K5TEQVOKRHMBWEVRJ2BUSR75X5HSUMC5/

Re: Heads up: Python 3.7 rebuild in progress

2018-06-21 Thread Miro Hrončok


On 21.6.2018 06:12, Jerry James wrote:

On Wed, Jun 20, 2018 at 1:36 AM Miro Hrončok  wrote:

Unfortunately this is blocked by failing:

python-manuel
https://koji.fedoraproject.org/koji/taskinfo?taskID=27740145
https://bugzilla.redhat.com/show_bug.cgi?id=1593132


I had planned to look at that tonight.  However, just as I arrived
home from work tonight, as I was pulling into my driveway, my
neighbor's propane grill exploded, catching his deck and then his
house on fire.  Fortunately there were no serious injuries.


I'm glad nobody go seriously hurt.


Is there a way to do a mock build against the packages currently in f29-python?


fedpkg mock-config --target f29-python

This gives you a mock config you can use with mock -r or fedpkg 
mockbuild --root. (Untested.)



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/VY4265GQFVL5WODLCJOTBTDRHXPBGSJW/

Re: F29 System Wide Change: Make BootLoaderSpec the default

2018-06-21 Thread Colin Walters

On Thu, Jun 21, 2018, at 3:30 AM, Gerd Hoffmann wrote:
>   Hi,
> 
> > And in my opinion, it's not simple to say: OK if you have this size
> > ESP to start, you get this layout, and if it's bigger you get this
> > other layout, and if it's BIOS you have this 3rd layout.

Chris, I have to say I'm glad you're part of the Fedora community - your
input on this topic has been very valuable!

> Well, for fresh installs[1] there is no reason to have efi and bios use
> different layouts.  You can just do this:

When you say "install" it really matters to say install of *what* - a
desktop system, a physical server, a VM, etc.

From my perspective (Fedora CoreOS developer) that straddles
both physical and cloud for the server case, the problem is that
the virtualized case, and in particular public cloud, and really
specifically EC2 - no one really cares about EFI to boot their VMs.
Except a special case here is "disaster recovery" scenarios where
a physical server is imaged and uploaded to the cloud as a VM,
and the topic of UEFI does come up there.  Apparently most
implementations of this convert back to BIOS.

Don't get me wrong, I agree with Lennart (indirectly) in that it is
kind of crazy how influentual the "Windows dual boot for desktop"
case is on everything Fedora, which also includes physical
servers.  But the virtualized case also pushes at this from the other
angle.

>   [root@ibm-p8-kvm-03-guest-02 ~]# fdisk -l /dev/sda
>   Disk /dev/sda: 4 GiB, 4294967296 bytes, 8388608 sectors
>   Units: sectors of 1 * 512 = 512 bytes
>   Sector size (logical/physical): 512 bytes / 512 bytes
>   I/O size (minimum/optimal): 512 bytes / 512 bytes
>   Disklabel type: gpt
>   Disk identifier: 92035660-BEFD-45D5-9883-B2B91EC429D1
> 
>   Device   Start End Sectors  Size Type
>   /dev/sda1 2048   1023981924M BIOS boot
>   /dev/sda210240 1058815 1048576  512M EFI System

I wouldn't *oppose* that; in fact if you (or someone else)
wanted to push for that with e.g. Fedora CoreOS, I'd be happy
to discuss it.  But it's not like it has a truly compelling advantage
over what we ship today - it'd just be *another* weird variant
of things in the end right?  

And the fact that FAT has no ability to do atomic replacement bothers
me a lot. (A wrinkle here is that ostree implements an atomic swap of
/boot/loader - you can today boot FAH/Silverblue and just ls -al /boot
to see 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/MNRANIETDFYCPU5RN3MEW65W6PFSI7C2/

Re: F29 System Wide Change: Modules for Everyone

2018-06-21 Thread Kevin Kofler

Jan Kurik wrote:
> In Fedora 28, the Server Edition debuted new modular functionality,
> allowing end-users access to alternative versions of popular software. Due
> to technical limitations with package-management software, it was not
> available for non-Server deployments of Fedora. Beginning with Fedora 29,
> all installations of Fedora will have modules available for installation
> and update. This will be done by merging the `fedora-repos-modular`
> sub-package back into the `fedora-repos` package.

Will the repositories be enabled or disabled by default?

Kevin
___
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/AANGEQWMBT77FTBQWVHXDEAR4NLONM4R/

Re: i686 kernel missing on rawhide / disabling archs in critical path pkgs

2018-06-21 Thread Kevin Kofler

Daniel P. Berrangé wrote:
> Having said all this, the message about brokenness on x86 SIG mailing
> list doesn't appear to be treated with the urgency I think it needs,
> givin the ripple effect it has from a critical path package. There were
> a few messages the day after it was reported, and then nothing until
> Wednesday.

It is pretty clear that the x86 mailing list is just a fake put up to keep 
the architecture running. Just look at the ridiculously low activity at:
https://lists.fedoraproject.org/archives/list/x...@lists.fedoraproject.org/

This month's activity is unusually high because the "F29 System Wide Change: 
i686 Is For x86-64" thread (i.e., the discussion on enabling SSE2) was 
mostly cross-posted from this list (devel) to that list (x86). But otherwise 
this is little more than a Potemkin village. There is very little going on 
behind the façade.

Kevin Kofler
___
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/PE54WTVCMS7HF4U52RL3PTWTXXAZ6DOH/

Re: No kernel on i686

2018-06-21 Thread Richard W.M. Jones


[Dan & I were discussing this on IRC and how it affected our
own packages, hence the overlapping messages on the same subject ...]

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/DG543VBXTKBNYSHQQ4IFSMJ7L3GJWQPA/

i686 kernel missing on rawhide / disabling archs in critical path pkgs

2018-06-21 Thread Daniel P . Berrangé

Fedora rawhide has not had any kernel build available for i686 for a
week now. It was disabled in a rebase due to part of the build process
segfaulting.

  commit 861ae54010f0dae5c988105b6179a8f2442851e7
  Author: Laura Abbott 
  Date:   Thu Jun 14 10:57:47 2018 -0700

Don't build for i686

There is a segfault on i686

+ ./process_configs.sh -n -c kernel 4.18.0
~/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git9.1.fc29.i686 
~/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git9.1.fc29.i686/configs
Processing 
/builddir/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git9.1.fc29.i686/configs/kernel-4.18.0-aarch64.config
 ... 
/builddir/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git9.1.fc29.i686/configs/kernel-4.18.0-aarch64.config:5814:warning:
 override: SPARSEMEM_MANUAL changes choice state

/builddir/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git9.1.fc29.i686/configs/kernel-4.18.0-aarch64.config:6846:warning:
 override: VIRT_CPU_ACCOUNTING_NATIVE changes choice state
make[1]: *** [scripts/kconfig/Makefile:64: olddefconfig] Segmentation fault 
(core dumped)

No idea why but we don't want to stop other arches. Disable it
for now.

There is a message posted to the x86 SIG at the same time as it was
disabled:

   
https://lists.fedoraproject.org/archives/list/x...@lists.fedoraproject.org/thread/YCBS5Y33YFBN2NPNPRUH6YJQFB5CVQ4F/

Now, i686 is an alternative architecture, so IIUC, it is currently allowed
by our package maint guidelines to disable packages on i686 when there are
build problems.

The kernel, however, is a critical path component that is a dependancy of
many other RPMs in Fedora.

Personally I'm impacted by inability to build QEMU in rawhide, because
it needs systemtap and systemtap needs the kernel-devel package. The
same impacts libvirt.

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

The GFS userspace is showing similar problems

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

which again impacts parts of the virt stack.

IOW, the result of disabling i686 in the kernel has to be pass on pain
to countless downstream package maintainers who are now blocked unless
they also disable i686,  which will in turn break further downstream
packages which depend on them, rinse repeat.



Based on this ripple effect, I think the package maint policy here is
flawed with respect to packages that are on the critical path.

We have a root cause here that's there's a i686 build issue to
be addressed. No debate there.


Simply disabling an architecture doesn't fix the problem - it actually
expands the problem out to more & more packages/maintainers, making it
worse than it was to start with.


IMHO for packages that are in the critical and/or an upstream dependancy
of many other packages in Fedora, we should *NOT* disable architectures
except as a last resort, and certainly not before giving time to identify
what has caused the problem & fix it.


The kernel change that introduced the i686 build problem was just a
rebase between 2 arbitrary pre-release git snapshots. I don't really
a compelling justification to rebase to a known broken snapshot,
without allowing time for x86 SIG to resolve it first. AFAIK there
was no prior warning or request for help - i686 was just disabled
immediately and other package maintainers left to deal with the
consequences of broken deps.


A more pragmatic approach would have been to report the problem to the
x86 SIG and then *not* do the rebase for some reasonable period of time
(perhaps 1 week grace period), to allow for the problem to be addressed.
Only disable the i686 build if there is no solution is forthcoming, thus
avoiding causing this pain for a whole chain of packages/maintainers in
Fedora.


Having said all this, the message about brokenness on x86 SIG mailing
list doesn't appear to be treated with the urgency I think it needs,
givin the ripple effect it has from a critical path package. There were
a few messages the day after it was reported, and then nothing until
Wednesday.

For a package that is critical path  like the kernel, I'd expect this
to be a top priority item to resolve with immediate effect because of
the broad impact it has on other maintainers. Maybe this has been
happening in the background, with no activity visible on the mailing
list, if so I apologize in advance.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/

No kernel on i686

2018-06-21 Thread Richard W.M. Jones

Just wanted to bring this to wider attention:

  https://bugzilla.redhat.com/show_bug.cgi?id=1592374
  https://bugzilla.redhat.com/show_bug.cgi?id=1593411
  
https://lists.fedoraproject.org/archives/list/x...@lists.fedoraproject.org/thread/YCBS5Y33YFBN2NPNPRUH6YJQFB5CVQ4F/

There is no kernel being built on i686.  This breaks several
assumptions:

(1) Any package which depends on a kernel module by requiring
‘kmod(foo.ko)’ will no longer be installable on i686.  If it
BuildRequires the package it will FTBFS.

Packages affected:
 - batctl
 - floppy-support
 - gfs2-utils
 - joystick-support
 - snapd
 - usbip
 - xl2tpd

(2) Any package which depends on ‘kernel-devel’ or
‘kernel-devel-uname-r’ will no longer be installable.  If it
BuildRequires the package it will FTBFS.

Packages affected (some of these may be from rpmfusion):
 - akmods
 - bcc-tools
 - dkms
 - systemtap-devel  [this causes lots of packages to FTBFS]

My real question: Is this going to be a long-term state of affairs?
Should I start dropping dependencies / stop building stuff which needs
a kernel on i686?  Or should we wait it out?

(I have no need for i686 nor any particular desire to actually
investigate or fix the problems on this obsolete hardware.)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
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/6HCJSETHD2T2R6ZACWS6GKUOHNRITMZD/

F29 System Wide Change: IBus 1.5.19

2018-06-21 Thread Jan Kurik

= Proposed System Wide Change: IBus 1.5.19 =
https://fedoraproject.org/wiki/Changes/IBus_1.5.19


Owner(s):
  * Takao Fujiwara 


IBus 1.5.19 will have two features.

# Move the input entry on IBus emoji dialog to the input entry on each
application using IBus pre-edit text so that the focus event is not
changed when the emoji typing is enabled# Ctrl-Shift-u feature of
typing Unicode code points is separated from Ctrl-Shift-e feature so
that neither an additional dialog or popup window is needed.

# Typing compose keys will have a pre-edit text



== Detailed description ==
Currently Ctrl-Shift-e launches an IBus emoji dialog and users type
emoji annotations in an input entry on the dialog and the input entry
can convert the muti-byte annotation to an emoji character, besides
ASCII annotation. However the dialog takes the current input focus in
any desktop environments and also the dialog position cannot
determined in Wayland because the dialog has no parent windows.
IBus 1.5.19 will move the input entry on the emoji dialog to the
current input context on each applications using IBus pre-edit
feature. Users type emoji annotations on the pre-edit text after they
type Ctrl-Shift-e and typing space key launches a lookup window to
show emoji candidates.
Currently Ctrl-Shift-u feature of typing Unicode code point is
consolidated in the emoji dialog because one shortcut key of
Ctrl-Shift-e can cover the feature but the code point feature would
not need to launch the dialog because the candidate character is only
one so IBus 1.5.19 will separate the Ctrl-Shift-u feature from
Ctrl-Shift-e one and both keybindings can be customizable with
ibus-setup.
Currently IBus compose feature does not show anything until the output
character is determined. IBus 1.5.9 will shows the pre-edit text
during users compose a sequence.
E.g. Multi_key-apostrophe-e outputs 'é' and shows the apostrophe as a
character on the pre-edit until 'e' is typed.


== Scope ==

* Proposal owners:
IBusEngine class will be changed in ibus-libs package to handle
Ctrl-Shift-e and Ctrl-Shift-u and it will effects all IBus engines.

* Other developers:
N/A

* Release engineering:
#7582 [https://pagure.io/releng/issue/7582]

** List of deliverables:
N/A

* Policies and guidelines:
N/A

* Trademark approval:
N/A
--
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/IHIKAUYGSUUA6FXE5DM5KKOX7MM3INHM/

Re: F29 System Wide Change: Make BootLoaderSpec the default

2018-06-21 Thread Lennart Poettering

On Mi, 20.06.18 19:28, Chris Murphy (li...@colorremedies.com) wrote:

> >> Except, it's not simple for installers to migrate to a new bigger ESP
> >> in the dual boot case. And having different layouts for UEFI and BIOS
> >> and whether there's dual boot or single boot, isn't simpler.
> >
> > Again, if you don't want to resize the ESP, then go for option #2
> > above. But if the ESP is usable, then go for option #1.
> 
> In 100% of the cases where the ESP already exists, it is too small to
> share. No one. Not Apple, not Microsoft, not Windows OEMs, not Fedora,
> not any distro, creates an ESP bigger than 550MB. Typical is 99MB for
> the Microsoft installer (I have a laptop partitioned by Microsoft's
> install, not an OEM installer, and it's 99MB), and 128MB for Apple,
> and 200MB for Linux distros. None of these are big enough to share.

On my Lenovo I got an ESP of 256M, and I use it happily and without
issues for systemd-boot. Maybe that's anecdotal, but all this entirely
besides the point.

Fedora is not a system that is exclusively dual-booted. it's entirely
fine to follow slightly different setups if fedora is installed onto a
system that already has Windows installed, or if a fresh full-disk
image is generated for it, that can be installed by "dd" or such.

All I am saying is that if you built a clean image, i.e. do not do the
augment-an-existing-windows-installation dance then there's really no
point in doing two partitions...

(And quite frankly, I still don't buy the "ESP resizing is totally
impossible" thing. It's not. When you install Fedora onto an existing
Windows installation disk, you have to resize/move the Windows NTFS
partitions anyway to make space for Fedora. And if you do, you might
as well move the ESP too. I mean resizing/moving the ESP is a lot
simpler and less dangerous than resizing/moving NTFS. But this
discussion is entirely pointless anyway, as $BOOT may be separate from
the ESP according the spec.)

> And the ESP partition is wedged in, again in 100% of cases. It can't
> be resized in place.
> 
> Therefore, Option #2 will be extremely common. What percent of Fedora
> users dual boot? I have no empirical data. I'd guess 1/2.

Fedora generates cloud images and suchlike. All those images really
don't need to bother with compat with Windows.

> You have to decide which is more important. Broad adoption, which will
> require equal doses of compromise and simplicity. Or narrow
> adoption.

Yupp, compromise is already built into the spec. If it wasn't for
compromise then $BOOT would not exist as a concept, and we'd just
always use the ESP.

> And as Fedora is right now looking to implement BLS, what did they
> actually do? Adopt the BLS file format and drop in concept, and
> abandon the other 90% of the spec by punting.

Yeah, what Fedora is doing has nothing to do with the boot loader
spec, that's true. It should really drop referencing the spec.

But seriously, $BOOT may be separate from the ESP. It's fine if Fedora
implements it separately, and totally conforming to the spec. I am not
sure what you even are insisting on here. You appear to say that
merging the two should be *against* the spec. But why do you even
care about that? You can totally choose to implement the "keep $BOOT
separate from the ESP" part, and ignore the "merge $BOOT with ESP"
part. It's *entirely* fine if Fedora does it that way. 

> I'll tell you what. Maybe consider a general purpose layout and a
> simplified layout. The typical layout represents a compromise no
> matter the firmware, and no matter what OS is already present - your
> option 2. This would be used for workstations, and any case where dual
> or multiboot is expected. And for things like Fedora VM images, IoT,
> possibly server, possibly ARM - where the sharing aspect of $BOOT is
> not expected or a consideration, go with the simplified layout - your
> option 1.

But this is what the spec pretty much already says! It says: merge it
if possible, split if if needed. How you define "possible" and
"needed" is up to you. All the spec tries to make sure though is that
once the decision is made for a specific image the other parties that
might want to process the entries know how to find the thing.

Lennart

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

Re: F29 System Wide Change: Make BootLoaderSpec the default

2018-06-21 Thread Lennart Poettering

On Mi, 20.06.18 19:40, Chris Murphy (li...@colorremedies.com) wrote:

> > What's going on? What is this? Why is this called "Boot loader spec"
> > if it implements an entirely different logic, and misses the entire
> > point of the boot loader spec?
> >
> > Quite frankly, I am really surprised by this and this makes me wonder
> > what the whole point of this feature is at all, and very sure we
> > shouldn't have it like this.
> 
> I agree.
> 
> But I also think there is some incremental risk of namespace collision
> with /loader/entries as mentioned in Matthew Garrett's derivative of
> the spec, if it's not located in /EFI/fedora/
> 
> Could $BOOT/org/freedesktop/bls/entries instead be
> $BOOT/org.freedesktop.bls/entries ?

The boot loader spec is already implemented in various tools under the
very "$BOOT/loader/entries" name (just read it aloud, it tells you
exactly what this is), I doubt there's need to rename it now. it's not
that the namespace below $BOOT or ESP is particularly crowded,
anyway. Also, I like my bikesheds blue.

Lennart

-- 
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/2MTPVW265CZ6O4OUETABRLQE4OQOZDN6/

Re: F29 System Wide Change: Make BootLoaderSpec the default

  Hi,

> Therefore, Option #2 will be extremely common. What percent of Fedora
> users dual boot? I have no empirical data. I'd guess 1/2.

Sure?  I would expect in the age of virtualization people prefer
virtual machines, because you can run fedora and $someotheros at the
same time then.

The installer must be able to handle this even if it is 10% only, so the
numbers don't change much on the fundamental issue.

I'm just curious ...

cheers,
  Gerd
___
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/GZPZAAH5YPXJK7GZXPIKQNPOIKWN3LLU/

Re: F29 System Wide Change: Make BootLoaderSpec the default