Re: grub2 BIOS booting iso and code

[Brandon Nielsen via devel]

On 4/15/22 5:06 PM, Thomas Schmitt wrote:

Hi,


Initial test with a CD-R and an HP Compaq 8510w are mixed.
It boots to GRUB, but it spins a long time blinking the HDD light displaying
nothing but "Welcome to GRUB". It eventually spits out "failure reading
sector 0x4f838 from 'hd31'."


'hd31' looks strange for HDD as well as for CD-ROM. Do have that many ?



Looked strange to me as well, I don't think I do...

Anyway, a reburn fixed it. I can now confirm a CD-R and the 
aforementioned HP Compaq 8510w boot fine with the test ISO.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

RE: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Stewart Smith via devel]

Chris Adams  writes:
> Once upon a time, Jared Dominguez  said:
>> Looks like they are using vSphere, which supports UEFI VMs. The same is
>> true for KVM, Xen and bhyve, so it's more about what feature set cloud
>> providers using these hypervisors are choosing to turn on.
>
> In a way, this is similar to "your router supports IPv6, why don't you
> just turn it on?":
>
> - version considerations: when did $HYPERVISOR start supporting UEFI?
>   what versions may still be running in some parts of infrastructure?
>
> - "support" vs. "really support": just because something says it
>   "supports UEFI" doesn't mean it works right; large-scale hosters need
>   to do lots of testing of all their supported systems and setups to see
>   how they actually react
>
> - internal tooling: just because a hoster is using KVM for example
>   doesn't mean they just install the vendor software and go; they have
>   their own internal management systems built on top, calling vendor
>   APIs to do things
>
> - presentation: adding user-facing options should always be carefully
>   considered, especially when they are "change this option and your VM
>   possibly won't boot" type (so more support tickets)

Support tickets don't worry me as much as making breaking changes for
customers that possibly result in outages for them do.

For example, I don't think it'd ever be possible to flip the default for
existing EC2 instance types. Maybe the default for a new major OS
version, but there's likely going to be an amount of time before all EC2
instance types support UEFI, and then there'll be customers with a
multitude of custom things enabled that don't (at least yet) work with
UEFI and will take the easy option of going back to legacy-bios,
probably for years.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Stewart Smith via devel]

Ben Cotton  writes:
> https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>
> == Summary ==
> Make UEFI a hardware requirement for new Fedora installations on
> platforms that support it (x86_64).  Legacy BIOS support is not
> removed, but new non-UEFI installation is not supported on those
> platforms.  This is a first step toward eventually removing legacy
> BIOS support entirely.

I want to add a few thoughts both from an EC2 perspective, and an Amazon
Linux as a downstream of Fedora perspective.

Currently, nearly all EC2 instance types will boot by default with
legacy-bios. All aarch64 instances are UEFI, and I'd find it unlikely
that any new x86-64 instance type would not also support UEFI. But the
default for all existing Intel and AMD instance types is
legacy-bios. This is largely to preserve backwards compatibility, and at
least for existing instance types, I cannot forsee this ever
changing. You just don't want to needlessly break customers.

Relatively recently, UEFI started becoming an option for some
non-aarch64 instance types, and can be selected either at instance
launch time, or configured to be part of the AMI.
See https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-boot.html

There are however a *lot* of instance types, a whole bunch of which are
less likely to support UEFI - the documentation gives t2.xlarge as an
example of one that only supports legacy-bios.

AMIs that don't run on all instance types tend to cause confusion, no
matter how clear you document the limitations. It's only now that this
is something that's even emerging as something that the EC2 APIs would
assist in enforcing. In fact, in Amazon Linux 2022 we went for the
decision that for aarch64 we'd require Graviton 2 and x86-64v2 as
minimal requirements, and having AL2022 AMIs not boot on a1 instances
types did surprise some people, even though we documented it.

With things like spot instances, there's a lot of customer demand for
"the cheapest possible compute, doesn't matter what or where" to run
things that aren't time critical.

Now, the interesting thing about Cloud images is that there isn't an
installer. In fact, Amazon Linux doesn't have one and we don't package
Anaconda anywhere. All users come from a disk image, which we create
using separate tooling. Thus, from an AL perspective, if Anaconda were
to stop  supporting installing for legacy-bios, this wouldn't affect
us at all.

However, we would have a big interest in having legacy-bios work well to
boot the OS, likely for a decent number of years to come (however much I
wish this wasn't the case).

I guess the interesting balance here is maintenance responsibility as
well. I *very* much don't want any of this to read like a request for
the community to maintain something that's primarily useful only to a
specific vendor. There's a point where if it's functionality that's
needed by a vendor, then said vendor has to maintain it, or be very
involved in maintaining it.

(and for non-EC2 and non-Amazon-Linux input, I have at least one machine
at home that run Fedora that don't have UEFI, a HP Microserver of a
certain age. Now, maybe it's time for me to upgrade that hardware, but I
bet there's a lot of folk who either don't want to do that, or cannot
reasonably afford to)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2075768] selecting the 'Component' at the end, cleares the 'Description'

[bugzilla]

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



--- Comment #1 from Jeff Fearn   ---
This happens because each component can have a different template for the bug
description. It should only do this if the component switched to uses a
different template than the original template completed.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2075768
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: EPEL conflicts with Satellite 6 packages

[Amos]

On Mon, Apr 18, 2022 at 4:57 PM Kevin Fenzi  wrote:

>
> Yeah, I'll echo smooge here. Can you expand on exactly what you are
> hitting?
>
> I can't seem to find the orig thread from 2016 in my mailbox, so I'm
> really not sure what the issue is here. ;(
>
> kevin
>
>
Going back to the original thread:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/772FVSHWG6XLEKDYFRSKKMB4IDNPDPRD/#replies

We don't (at least as far as I'm aware) have any broken systems, but this
is what can result:

System without EPEL:

qpid-proton-c.x86_640.28.0-3.el8
@satellite-tools-6.8-for-rhel-8-x86_64-rpms

System that has EPEL and is registered with our Satellite server:

qpid-proton-c.x86_640.37.0-1.el8   @epel


Right now this system with EPEL hasn't encountered issues, but every time
we have experienced this in the past, the system becomes unpatchable.
Since the original post is from 2016, I was just wondering if this issue
had evolved at all.


Thanks,

Amos
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: EPEL conflicts with Satellite 6 packages

[Kevin Fenzi]

On Sun, Apr 17, 2022 at 12:39:56PM -0400, Stephen John Smoogen wrote:
> On Sun, 17 Apr 2022 at 09:54, Amos  wrote:
> 
> > > On Wed, 1 Jun 2016 12:31:01 -0600 Erinn Looney-Triggs
> >  > >
> > https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provid...
> > 
> > > So, thats not a channel that EPEL strives to avoid conflicts with. We
> > could consider how to
> > > better avoid conflicts with that channel, but I'm not sure there's any
> > easy way there. kevin
> >
> > Apologies for replying to this old thread, but unless I'm mistaken, this
> > is still a problem.  More recently, there were two blog posts from Red Hat
> > that extolled the virtues of adding the EPEL repository into Satellite:
> >
> > https://www.redhat.com/sysadmin/epel-8-repo-satellite-6
> >
> > https://www.redhat.com/en/blog/whats-epel-and-how-do-i-use-it
> >
> > Apparently, however, at least based on our own experience, this is still a
> > problem with RHEL7, 8. Is there anything new on this topic?
> >
> >
> Hi, I realize you are having a problem, but the above email says NOTHING
> about what the problem is. What packages are you having and how are you
> having them? This is needed before any volunteer here can help.

Yeah, I'll echo smooge here. Can you expand on exactly what you are
hitting?

I can't seem to find the orig thread from 2016 in my mailbox, so I'm
really not sure what the issue is here. ;( 

kevin


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2076389] perl-DateTime-1.58 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-DateTime-1.58-1.fc34.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=85884420


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2076389
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2076389] perl-DateTime-1.58 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1873414
  --> https://bugzilla.redhat.com/attachment.cgi?id=1873414=edit
Update to 1.58 (#2076389)


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2076389
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2076389] New: perl-DateTime-1.58 is available

[bugzilla]

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

Bug ID: 2076389
   Summary: perl-DateTime-1.58 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-DateTime
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org, st...@silug.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.58
Current version/release in rawhide: 1.57-1.fc37
URL: http://search.cpan.org/dist/DateTime/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/2787/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2076389
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2076352] New: perl-Mojolicious-9.24 is available

[bugzilla]

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

Bug ID: 2076352
   Summary: perl-Mojolicious-9.24 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Mojolicious
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr,
perl-devel@lists.fedoraproject.org,
robinlee.s...@gmail.com, yan...@declera.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 9.24
Current version/release in rawhide: 9.23-1.fc37
URL: https://metacpan.org/release/Mojolicious

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/5966/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2076352
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: grub2 BIOS booting iso and code

[Geraldo Simião Kutz]

Tested this iso with an USB stick on this machine here and it passed the
tests and Anaconda started correctly.

Machine: Type: Laptop System: Hewlett-Packard product: HP G42 Notebook PC
Mobo: Hewlett-Packard model: 1484 v: 77.19 BIOS: Hewlett-Packard v: F.17
date: 07/06/2010
CPU Dual core Pentium T4500 2.3GHz
RAM 6GB

Geraldo Simião

@geraldosimiao:matrix.org

Em seg, 18 de abr de 2022 14:44, Thomas Schmitt 
escreveu:

> Hi,
>
> i wrote:
> > > xorrisofs option --mbr-force-bootable
>
> Chris Murphy wrote:
> > with the bit set it means older versions of
> > Tianocore or anything based on Tianocore up until maybe 6 months ago,
> > won't boot.
>
> Is this maybe about the code snippet of Tianocore which Alexander E.
> Patrakov showed in the course of the grub-bug thread of 2015/16 ?
>
>   https://marc.info/?l=grub-bug=145052969801875=2
>   "
>   OK, Tiano Core validates the protective partition as follows:
>
>   //
>   // Verify that the Protective MBR is valid
>   //
>   for (Index = 0; Index < MAX_MBR_PARTITIONS; Index++) {
> if (ProtectiveMbr->Partition[Index].BootIndicator == 0x00 &&
> ProtectiveMbr->Partition[Index].OSIndicator == PMBR_GPT_PARTITION
> &&
> UNPACK_UINT32 (ProtectiveMbr->Partition[Index].StartingLBA) == 1
> ) {
>   break;
> }
>   }
>   if (Index == MAX_MBR_PARTITIONS) {
> goto Done;  // i.e. not valid
>   }
>
>   So here is an alternative suggestion: don't mark the protective
> partition,
>   create another dummy MBR partition of type 0x00, mark it as bootable.
>   "
>
> That's what --mbr-force-bootable does.
> The shown code will find type 0xEE == PMBR_GPT_PARTITION in partition 1
> with boot/active flag == 0x00 and be happy.
>
> Others which are more picky will hopefully ignore partitions of type 0x00.
> UEFI 2.8 , 5.2.1 Legacy Master Boot Record (MBR) says:
>   "The following test must be performed to determine if a legacy MBR is
>valid:
>* The Signature must be 0xaa55.
>* A Partition Record that contains an OSType value of zero or a
>  SizeInLBA value of zero may be ignored."
>
> For now, "may be ignored" seems to be enough of protection against trouble.
>
>
> An alternative to --mbr-force-bootable could be to offer a 16-byte file
> for download together with the instructions to patch it into a pure and
> specs conformant ISO with GPT. Of course, only if a 10 year old laptop
> refuses to recognize the original ISO on USB stick.
>
> The bytes would have to be
>
>   { 128, 0, 1, 0, 0, 0, 1, 0, 0, 0, 0, 0, 1, 0, 0, 0 }
>
> Assumed the file is named "dummy_mbr_part2.img" the patch instruction
> would be
>
>dd if=dummy_mbr_part2.img of=boot-grub2-f36.iso \
>   conv=notrunc bs=1 seek=462 count=16
>
> -
>
> Ubuntu is testing this for you since about a year. :))
>
> Afaik the first official ISO of this layout was
>   ubuntu-21.04-desktop-amd64.iso
> and they did _not_ revoke it half a year later with
>   ubuntu-21.10-desktop-amd64.iso
>
>   $ xorriso -indev ubuntu-21.10-desktop-amd64.iso -report_system_area plain
>   ...
>   Volume id: 'Ubuntu 21.10 amd64'
>   System area options: 0x4201
>   System area summary: MBR protective-msdos-label grub2-mbr cyl-align-off
> GPT
>   ISO image size/512 : 6086880
>   Partition offset   : 16
>   MBR heads per cyl  : 0
>   MBR secs per head  : 0
>   MBR partition table:   N Status  TypeStart   Blocks
>   MBR partition  :   1   0x00  0xee1  6086879
>   MBR partition  :   2   0x80  0x0001
>   GPT:   N  Info
>   ...
>
>   $ /sbin/fdisk -l ubuntu-21.10-desktop-amd64.iso
>
>   Disk ubuntu-21.10-desktop-amd64.iso: 2.9 GiB, 3116482560 bytes, 6086880
> 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: EF83665C-2F29-48D6-8C3F-80F5A69CFEB7
>
>   DeviceStart End Sectors  Size Type
>   ubuntu-21.10-desktop-amd64.iso1  64 6077751 6077688  2.9G Microsoft
> basic da
>   ubuntu-21.10-desktop-amd64.iso2 6077752 60862158464  4.1M EFI System
>   ubuntu-21.10-desktop-amd64.iso3 6086216 6086815 600  300K Microsoft
> basic da
>
> -
>
> Whatever, we do not yet know for sure whether the boot failure with the
> Dell XPS 15 L502X is caused by the lack of a boot/active flag.
>
> We also don't know yet whether the failure with "CD-R and an HP Compaq
> 8510w"
> that was reported by Brandon Nielsen is due to drive-media problems with
> the CD-R or due to problems with the ISO.
>
>
> Have a nice day :)
>
> Thomas
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of 

Re: grub2 BIOS booting iso and code

[Thomas Schmitt]

Hi,

i wrote:
> > xorrisofs option --mbr-force-bootable

Chris Murphy wrote:
> with the bit set it means older versions of
> Tianocore or anything based on Tianocore up until maybe 6 months ago,
> won't boot.

Is this maybe about the code snippet of Tianocore which Alexander E.
Patrakov showed in the course of the grub-bug thread of 2015/16 ?

  https://marc.info/?l=grub-bug=145052969801875=2
  "
  OK, Tiano Core validates the protective partition as follows:

  //
  // Verify that the Protective MBR is valid
  //
  for (Index = 0; Index < MAX_MBR_PARTITIONS; Index++) {
if (ProtectiveMbr->Partition[Index].BootIndicator == 0x00 &&
ProtectiveMbr->Partition[Index].OSIndicator == PMBR_GPT_PARTITION &&
UNPACK_UINT32 (ProtectiveMbr->Partition[Index].StartingLBA) == 1
) {
  break;
}
  }
  if (Index == MAX_MBR_PARTITIONS) {
goto Done;  // i.e. not valid
  }

  So here is an alternative suggestion: don't mark the protective partition,
  create another dummy MBR partition of type 0x00, mark it as bootable.
  "

That's what --mbr-force-bootable does.
The shown code will find type 0xEE == PMBR_GPT_PARTITION in partition 1
with boot/active flag == 0x00 and be happy.

Others which are more picky will hopefully ignore partitions of type 0x00.
UEFI 2.8 , 5.2.1 Legacy Master Boot Record (MBR) says:
  "The following test must be performed to determine if a legacy MBR is
   valid:
   * The Signature must be 0xaa55.
   * A Partition Record that contains an OSType value of zero or a
 SizeInLBA value of zero may be ignored."

For now, "may be ignored" seems to be enough of protection against trouble.


An alternative to --mbr-force-bootable could be to offer a 16-byte file
for download together with the instructions to patch it into a pure and
specs conformant ISO with GPT. Of course, only if a 10 year old laptop
refuses to recognize the original ISO on USB stick.

The bytes would have to be

  { 128, 0, 1, 0, 0, 0, 1, 0, 0, 0, 0, 0, 1, 0, 0, 0 }

Assumed the file is named "dummy_mbr_part2.img" the patch instruction
would be

   dd if=dummy_mbr_part2.img of=boot-grub2-f36.iso \
  conv=notrunc bs=1 seek=462 count=16

-

Ubuntu is testing this for you since about a year. :))

Afaik the first official ISO of this layout was
  ubuntu-21.04-desktop-amd64.iso
and they did _not_ revoke it half a year later with
  ubuntu-21.10-desktop-amd64.iso

  $ xorriso -indev ubuntu-21.10-desktop-amd64.iso -report_system_area plain
  ...
  Volume id: 'Ubuntu 21.10 amd64'
  System area options: 0x4201
  System area summary: MBR protective-msdos-label grub2-mbr cyl-align-off GPT
  ISO image size/512 : 6086880
  Partition offset   : 16
  MBR heads per cyl  : 0
  MBR secs per head  : 0
  MBR partition table:   N Status  TypeStart   Blocks
  MBR partition  :   1   0x00  0xee1  6086879
  MBR partition  :   2   0x80  0x0001
  GPT:   N  Info
  ...

  $ /sbin/fdisk -l ubuntu-21.10-desktop-amd64.iso

  Disk ubuntu-21.10-desktop-amd64.iso: 2.9 GiB, 3116482560 bytes, 6086880 
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: EF83665C-2F29-48D6-8C3F-80F5A69CFEB7

  DeviceStart End Sectors  Size Type
  ubuntu-21.10-desktop-amd64.iso1  64 6077751 6077688  2.9G Microsoft basic 
da
  ubuntu-21.10-desktop-amd64.iso2 6077752 60862158464  4.1M EFI System
  ubuntu-21.10-desktop-amd64.iso3 6086216 6086815 600  300K Microsoft basic 
da

-

Whatever, we do not yet know for sure whether the boot failure with the
Dell XPS 15 L502X is caused by the lack of a boot/active flag.

We also don't know yet whether the failure with "CD-R and an HP Compaq 8510w"
that was reported by Brandon Nielsen is due to drive-media problems with
the CD-R or due to problems with the ISO.


Have a nice day :)

Thomas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: fedora-obsolete-packages for arch specific issues

[Miro Hrončok]

On 17. 04. 22 15:56, Miroslav Suchý wrote:

We have specific issues during an Fedora upgrade.

In past, it was issue with rdma-core [1] during upgrade to F34. Nowadays, for 
upgrade to F36, we have an issue with lilv [2]


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1919864

[2] https://bugzilla.redhat.com/show_bug.cgi?id=2052588

Both issues happens, in generall, when you have multilib package A-1.0.i686 and 
A-1.0.x86_64 which is going to be upgraded to A-2.0.noarch.


We have package `fedora-obsolete-packages` for obsoleting problematic packages. 
But this package is noarch. And obviously noarch package cannot obsolete 
multilib package.


I am not aware of any trick that can solve this on rpm level - if you know, 
please comment in BZ [2].


I think this can be solved by introducing new package which will work like 
`fedora-obsolete-packages`, but will not be arch. I.e. we will have version for 
specific architecture and we can obsolete architecture specific packages.


Comments? Ideas?


What if A-2.0.noarch obsoleted A < 2. Would that help?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: grub2 BIOS booting iso and code

[Brian C. Lane]

On Sun, Apr 17, 2022 at 03:12:59PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> I've tested your ISO with:
> 
> - Dell XPS 15 L502X 8GB RAM (BIOS only) CD-R physical media
> 
> Booted and started the installer reasonably fast
> 
> - same machine USB media (written to whole device using dd)
> 
> Boot fails with "Operation system not found" error.
> Same USB stick boots fine on another machine (UEFI+SecureBoot), so
> the medium is fine.

In my experience this mean the BIOS didn't find anything it wants to
boot. Does a current F35 iso boot on this system when written to USB?

Thanks,

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Fedora EPEL 8 updates-testing report

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-7aca455c41   
pdns-4.6.2-1.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

efifs-1.8-3.el8

Details about builds:



 efifs-1.8-3.el8 (FEDORA-EPEL-2022-4257a90e16)
 Free software EFI/UEFI standalone file system drivers

Update Information:

- Update bundled edk2 to 202202 and add GCC 12 fixes (#2045335)

ChangeLog:

* Mon Apr 18 2022 Robert Scheck  1.8-3
- Update bundled edk2 to 202202 and add GCC 12 fixes (#2045335)
* Thu Jan 20 2022 Fedora Release Engineering  - 1.8-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

References:

  [ 1 ] Bug #2045335 - efifs: FTBFS in Fedora rawhide/f36
https://bugzilla.redhat.com/show_bug.cgi?id=2045335


___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: grub2 BIOS booting iso and code

[Chris Murphy]

On Mon, Apr 18, 2022 at 5:17 AM Thomas Schmitt  wrote:
>
> Hi,
>
> Dominik 'Rathann' Mierzejewski wrote:
> > > > Dell XPS 15 L502X 8GB RAM (BIOS only)
>
> BIOS-only on a laptop might mean the firmware quirk which demands
> to see the "boot/active" flag at some MBR partition table slot.
>
> See a thread of grub-bug (and later grub-devel) from 2015/16
>   https://marc.info/?l=grub-bug=145052506901159=2
> where Alexander E. Patrakov wrote:
>   "Subject: [bug #46716] Protective MBR partition is not marked as bootable
>[...]
>Changing the byte at offset 0x1be to 0x80 in the resulting iso makes
>it bootable on such boards."
>
> This led to the creation of xorrisofs option --mbr-force-bootable in
> xorriso-1.4.3.

This sounds equivalent to the pbmr_boot option in parted. If so, it's
a catch-22 because without the bit set it means some buggy BIOS
systems won't boot; but with the bit set it means older versions of
Tianocore or anything based on Tianocore up until maybe 6 months ago,
won't boot.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Fedora EPEL 9 updates-testing report

[updates]

The following Fedora EPEL 9 Security updates need testing:
 Age  URL
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-72a7426715   
pdns-4.6.2-1.el9
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-cfff8c1f5c   
composer-2.3.5-1.el9


The following builds have been pushed to Fedora EPEL 9 updates-testing

NetworkManager-l2tp-1.20.2-1.el9
efifs-1.8-3.el9
libpreludedb-5.2.0-2.el9
prelude-correlator-5.2.0-1.el9
prelude-lml-5.2.0-2.el9
prelude-lml-rules-5.2.0-1.el9
prelude-manager-5.2.0-1.el9
python-google-auth-2.6.5-1.el9

Details about builds:



 NetworkManager-l2tp-1.20.2-1.el9 (FEDORA-EPEL-2022-cdb6aa6fd1)
 NetworkManager VPN plugin for L2TP and L2TP/IPsec

Update Information:

Updated to 1.20.2 release

ChangeLog:

* Mon Apr 18 2022 Douglas Kosovic  - 1.20.2-1
- Updated to 1.20.2 release
- Conditional gtk4 support added
* Wed Jan 19 2022 Fedora Release Engineering  - 
1.20.0-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild




 efifs-1.8-3.el9 (FEDORA-EPEL-2022-13ea94c301)
 Free software EFI/UEFI standalone file system drivers

Update Information:

- Update bundled edk2 to 202202 and add GCC 12 fixes (#2045335)

ChangeLog:

* Mon Apr 18 2022 Robert Scheck  1.8-3
- Update bundled edk2 to 202202 and add GCC 12 fixes (#2045335)
* Thu Jan 20 2022 Fedora Release Engineering  - 1.8-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

References:

  [ 1 ] Bug #2045335 - efifs: FTBFS in Fedora rawhide/f36
https://bugzilla.redhat.com/show_bug.cgi?id=2045335




 libpreludedb-5.2.0-2.el9 (FEDORA-EPEL-2022-904d610d88)
 Framework for easy access to the IDMEF database

Update Information:

LibpreludeDB EPEL9

ChangeLog:

* Fri Apr 15 2022 Thomas Andrejak  - 5.2.0-2
- Merge from epel8
* Thu Sep 17 2020 Thomas Andrejak  - 5.2.0-1
- Bump version 5.2.0




 prelude-correlator-5.2.0-1.el9 (FEDORA-EPEL-2022-904d610d88)
 Real time correlator of events received by Prelude Manager

Update Information:

LibpreludeDB EPEL9

ChangeLog:

* Thu Sep 17 2020 Thomas Andrejak  - 5.2.0-1
- Bump version 5.2.0
* Fri Oct 11 2019 Thomas Andrejak  - 5.1.0-1
- Bump version 5.1.0
* Wed Jul 24 2019 Thomas Andrejak  - 5.0.1-1
- Bump version 5.0.1
* Thu Mar  7 2019 Troy Dawson  - 4.1.1-4
- Rebuilt to change main python from 3.4 to 3.6




 prelude-lml-5.2.0-2.el9 (FEDORA-EPEL-2022-904d610d88)
 Log analyzer sensor with IDMEF output

Update Information:

LibpreludeDB EPEL9

ChangeLog:

* Fri Apr 15 2022 Thomas Andrejak  - 5.2.0-2
- Merge from epel8
* Thu Sep 17 2020 Thomas Andrejak  - 5.2.0-1
- Bump version 5.2.0
* Thu Sep 17 2020 Thomas Andrejak  - 5.2.0-1
- Bump version 5.2.0




 prelude-lml-rules-5.2.0-1.el9 (FEDORA-EPEL-2022-904d610d88)
 Prelude LML community ruleset

Update Information:

LibpreludeDB EPEL9

ChangeLog:

* Thu Sep 17 2020 Thomas Andrejak  - 5.2.0-1
- Bump version 5.2.0
* Fri Oct 11 2019 Thomas Andrejak  - 5.1.0-1
- Bump version 5.1.0
* Wed Jul 24 2019 Thomas Andrejak  - 5.0.0-1
- Bump version 5.0.0

Re: BIOS boot - an alternative approach

[Neal Gompa]

On Mon, Apr 18, 2022 at 11:26 AM Ian Pilcher  wrote:
>
> I'm not a Fedora developer, just a long time interested user, so take
> this for what it's worth.  I'd like to suggest an alternative approach
> to the BIOS boot (and potentially other similar boot issues), or at
> least suggest that this approach be discussed.
>
> Basically, I suggest that Fedora stop worrying about BIOS boot or other
> "weird" boot configurations.  Instead, provide a truly manual
> installation path where all boot and storage configuration is the
> responsibility of the user.
>
> This would include:
>
> * Installing and configuring the boot loader.
>
> * Updating the boot loader configuration when new kernels are installed
>(although anyone who desires should obviously be free to contribute
>packages that automate this for particular boot loaders).
>
> * All storage configuration - creating partitions, RAID devices, logical
>volumes, etc.  (I.e. the Fedora wouldn't perform any sort of discovery
>of storage devices; the user would be responsible for selecting
>devices that already exist in /proc/partitions.)
>
> * Booting *something* that can run the Fedora installer.
>
> AFAIK, it's still possible to skip boot loader installation during
> Fedora installation, and the live media installation path exists, so I
> believe that the main work here would be to package the installer and
> its associated runtimes, libraries, etc. into some sort of self-
> contained package that is as independent as possible from the OS on
> which it is running.
>
> Not only would this provide a path for BIOS boot, and similar issues,
> but it would also support other complex configurations.  (I can't even
> count the number of Anaconda crashes I had back in the day with LVM on
> MD-RAID.)
>
> As I said, I'm not a Fedora developer, but I see this approach as
> potentially eliminating a lot of work and increasing Fedora's
> "flexibility" over the long term.
>
> OK, now tear this apart.  :-)
>

Setting up boot stuff correctly for the myriad of configurations is an
area where Fedora provides significant value, so it only sounds good
to do this if we expect people to be able to manually do this. The
majority of people will not be capable of doing this properly, even
many advanced users won't be able to.

If you want to have an Arch-like installation process, the live media
does provide a way to do this in the form of all the partitioning
tools and DNF being available on the media. We don't provide an
Arch/Gentoo-style "minimal" media that people can use to run these
things, but pretty much any live media can be used for this purpose.

And frankly, I don't want to support some complex boot configurations
at a Fedora distribution level, such as /boot on LVM+LUKS. If someone
wants to set that up, fine, but it has enough pitfalls that it's not
worth broadly supporting.

Any "manual" installation process comes with the important caveat of
"we can't test it, so we can't support it" for whatever definition of
support you'd like to apply. :)

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

BIOS boot - an alternative approach

[Ian Pilcher]

I'm not a Fedora developer, just a long time interested user, so take
this for what it's worth.  I'd like to suggest an alternative approach
to the BIOS boot (and potentially other similar boot issues), or at
least suggest that this approach be discussed.

Basically, I suggest that Fedora stop worrying about BIOS boot or other
"weird" boot configurations.  Instead, provide a truly manual
installation path where all boot and storage configuration is the
responsibility of the user.

This would include:

* Installing and configuring the boot loader.

* Updating the boot loader configuration when new kernels are installed
  (although anyone who desires should obviously be free to contribute
  packages that automate this for particular boot loaders).

* All storage configuration - creating partitions, RAID devices, logical
  volumes, etc.  (I.e. the Fedora wouldn't perform any sort of discovery
  of storage devices; the user would be responsible for selecting
  devices that already exist in /proc/partitions.)

* Booting *something* that can run the Fedora installer.

AFAIK, it's still possible to skip boot loader installation during
Fedora installation, and the live media installation path exists, so I
believe that the main work here would be to package the installer and
its associated runtimes, libraries, etc. into some sort of self-
contained package that is as independent as possible from the OS on
which it is running.

Not only would this provide a path for BIOS boot, and similar issues,
but it would also support other complex configurations.  (I can't even
count the number of Anaconda crashes I had back in the day with LVM on
MD-RAID.)

As I said, I'm not a Fedora developer, but I see this approach as
potentially eliminating a lot of work and increasing Fedora's
"flexibility" over the long term.

OK, now tear this apart.  :-)

--

Google  Where SkyNet meets Idiocracy

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-36-20220418.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 8/229 (x86_64), 10/161 (aarch64)

New failures (same test not failed in Fedora-36-20220417.n.0):

ID: 1229381 Test: x86_64 Workstation-live-iso evince
URL: https://openqa.fedoraproject.org/tests/1229381
ID: 1229453 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/1229453
ID: 1229470 Test: aarch64 Server-dvd-iso install_blivet_lvm_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/1229470
ID: 1229524 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1229524
ID: 1229602 Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/1229602

Old failures (same test failed in Fedora-36-20220417.n.0):

ID: 1229376 Test: x86_64 Workstation-live-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1229376
ID: 1229390 Test: x86_64 Workstation-live-iso desktop_printing_builtin
URL: https://openqa.fedoraproject.org/tests/1229390
ID: 1229411 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1229411
ID: 1229509 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1229509
ID: 1229510 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1229510
ID: 1229512 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1229512
ID: 1229543 Test: x86_64 Workstation-upgrade apps_startstop
URL: https://openqa.fedoraproject.org/tests/1229543
ID: 1229546 Test: x86_64 Workstation-upgrade gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1229546
ID: 1229561 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1229561
ID: 1229565 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1229565
ID: 1229567 Test: aarch64 Workstation-upgrade desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1229567
ID: 1229631 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/1229631
ID: 1229690 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1229690

Soft failed openQA tests: 6/161 (aarch64), 10/229 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-36-20220417.n.0):

ID: 1229507 Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1229507

Old soft failures (same test soft failed in Fedora-36-20220417.n.0):

ID: 1229379 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1229379
ID: 1229383 Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1229383
ID: 1229394 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1229394
ID: 1229404 Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1229404
ID: 1229421 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1229421
ID: 1229426 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1229426
ID: 1229428 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1229428
ID: 1229429 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1229429
ID: 1229435 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1229435
ID: 1229486 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1229486
ID: 1229525 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1229525
ID: 1229529 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1229529
ID: 1229537 Test: x86_64 Workstation-upgrade desktop_browser
URL: https://openqa.fedoraproject.org/tests/1229537
ID: 1229559 Test: aarch64 Workstation-upgrade desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1229559
ID: 1229572 Test: aarch64 Workstation-upgrade eog@uefi
URL: https://openqa.fedoraproject.org/tests/1229572

Passed openQA tests: 211/229 (x86_64), 145/161 (aarch64)

New passes (same test not passed in Fedora-36-20220417.n.0):

ID: 1229399 Test: x86_64 KDE-live-iso base_package_install_remove
URL: https://openqa.fedoraproject.org/tests/1229399
ID: 1229450 Test: aarch64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1229450
ID: 1229454 Test: aarch64 

Fedora-IoT-36-20220418.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 1/15 (aarch64)

Old failures (same test failed in Fedora-IoT-36-20220417.0):

ID: 1229728 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/1229728

Passed openQA tests: 15/15 (x86_64), 14/15 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F37 Change: Replace jwhois package with whois for Fedora Workstation (Self-Contained Change proposal)

[Ben Cotton]

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

== Summary ==
Fedora Workstation product core group includes `jwhois` package.
Replace it with `whois` package which is more actively developed.


== Detailed Description ==
`Fedora Workstation product core` group includes `jwhois` package. Its
last commit is [http://www.gnu.org/software/jwhois/ from 2015]. Users
having issues with certain TLDs and the solution is usually manually
editing the `/etc/jwois.conf` file. `whois` package is
[https://github.com/rfc1036/whois more actively maintained] and
doesn't have those issues.


== Benefit to Fedora ==
Users will have a better experience querying `whois` information for a domain.

== Scope ==
* Proposal owners:
* Other developers:
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:


== Upgrade/compatibility impact ==


== How To Test ==
* Run `rpm -q --whatprovides whois`
* It should print `whois-*`


== User Experience ==


== Dependencies ==


== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change),


== Documentation ==

N/A (not a System Wide Change)

== Release Notes ==



-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F37 Change: Replace jwhois package with whois for Fedora Workstation (Self-Contained Change proposal)

[Ben Cotton]

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

== Summary ==
Fedora Workstation product core group includes `jwhois` package.
Replace it with `whois` package which is more actively developed.


== Detailed Description ==
`Fedora Workstation product core` group includes `jwhois` package. Its
last commit is [http://www.gnu.org/software/jwhois/ from 2015]. Users
having issues with certain TLDs and the solution is usually manually
editing the `/etc/jwois.conf` file. `whois` package is
[https://github.com/rfc1036/whois more actively maintained] and
doesn't have those issues.


== Benefit to Fedora ==
Users will have a better experience querying `whois` information for a domain.

== Scope ==
* Proposal owners:
* Other developers:
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:


== Upgrade/compatibility impact ==


== How To Test ==
* Run `rpm -q --whatprovides whois`
* It should print `whois-*`


== User Experience ==


== Dependencies ==


== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change),


== Documentation ==

N/A (not a System Wide Change)

== Release Notes ==



-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: grub2 BIOS booting iso and code

[John Reiser]

It would be very nice to run /sbin/dmidecode, which is on the .iso,
and report the "BIOS Information" section, such as:



Is the attached any use?


In the attachment I see these interesting lines (snipped):
=
SMBIOS 3.0.0 present.

BIOS Information
Vendor: American Megatrends Inc.
Version: 0801  ## first release (01) for product line 08
Release Date: 01/25/2017  ## only 5 years old
ROM Size: 16 MB  ## probably has lots of VGA-gui "eye candy"
Boot from CD is supported
Selectable boot is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported  ## claims to be *not* "BIOS-only"
BIOS Revision: 5.12  ## the low-level BIOS code

Base Board Information
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: STRIX Z270H GAMING  ## only 3 hardware generations old; 
current is Z5xx
Version: Rev 1.xx
=
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora 36 compose report: 20220418.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-36-20220417.n.0
NEW: Fedora-36-20220418.n.0

= SUMMARY =
Added images:2
Dropped images:  1
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

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

Size change of upgraded packages:   0 B
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-36-20220418.n.0.s390x.qcow2
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-36-20220418.n.0.s390x.raw.xz

= DROPPED IMAGES =
Image: Container_Minimal_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Minimal-Base-36-20220417.n.0.aarch64.tar.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unretiring Icedtea-web

[Florian Apolloner]

> On Thu, Mar 10, 2022 at 09:25:36AM -0500, Steve Cossette wrote:
> There aren't too many of them today, but I guess they
> still exist.

I actually use them quite frequently to access remote control on IPMI/KVM 
webpages on "older" servers. Luckily newer servers do provide HTML5 based 
remote access, but that is not an option for older ones. I also do not know of 
any alternative and am still running the f35 package on f36.

Cheers,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: grub2 BIOS booting iso and code

[Philip Rhoades via devel]

People,


On 2022-04-18 12:41, John Reiser wrote:

- Dell XPS 15 L502X 8GB RAM (BIOS only) CD-R physical media


It would be very nice to run /sbin/dmidecode, which is on the .iso,
and report the "BIOS Information" section, such as:



Is the attached any use?

Phil.



=
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 2.5 present.
70 structures occupying 2511 bytes.
Table at 0x000F0730.

Handle 0x, DMI type 0, 24 bytes
BIOS Information
Vendor: American Megatrends Inc.
Version: 1613
Release Date: 12/03/2008
Address: 0xF
Runtime Size: 64 kB
ROM Size: 1 MB
Characteristics:
ISA is supported
PCI is supported
PNP is supported
APM is supported
BIOS is upgradeable
BIOS shadowing is allowed
ESCD support is available
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
LS-120 boot is supported
ATAPI Zip drive boot is supported
BIOS boot specification is supported
Targeted content distribution is supported
BIOS Revision: 16.13
=
of which the Vendor, Version, and Release Date are the most important.
In the installer, type Ctrl+Alt+F2 to get a TTY, re-direct the output
of dmidecode into a file, and copy the file to a machine with a more-
hospitable environment (using wired ethernet, USB flash memory, etc.)

If there are any errors or unusual behavior, then it also is 
interesting
to know if the interface for the Floppy disk drive is enabled; but 
often
this requires searching through BIOS configuration screens.  Sometimes 
a
CD or DVD can be Read under Floppy emulation, and it is easy for the 
BIOS

to try this regardless of settings.  Try disabling the Floppy
in the BIOS settings, then re-booting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure


--
Philip Rhoades

PO Box 896
Cowra  NSW  2794
Australia
E-mail:  p...@pricom.com.au# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.0.0 present.
Table at 0x8B1AC000.

Handle 0x, DMI type 0, 24 bytes
BIOS Information
Vendor: American Megatrends Inc.
Version: 0801
Release Date: 01/25/2017
Address: 0xF
Runtime Size: 64 kB
ROM Size: 16 MB
Characteristics:
PCI is supported
APM is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 5.12

Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: System manufacturer
Product Name: System Product Name
Version: System Version
Serial Number: System Serial Number
UUID: 234d2060-d7da-11dd-97c0-2c4d54d79ed3
Wake-up Type: Power Switch
SKU Number: SKU
Family: To be filled by O.E.M.

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: STRIX Z270H GAMING
Version: Rev 1.xx
Serial Number: 170193764401522
Asset Tag: Default string
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: Default string
  

Re: grub2 BIOS booting iso and code

[Thomas Schmitt]

Hi,

Dominik 'Rathann' Mierzejewski wrote:
> > > Dell XPS 15 L502X 8GB RAM (BIOS only)

BIOS-only on a laptop might mean the firmware quirk which demands
to see the "boot/active" flag at some MBR partition table slot.

See a thread of grub-bug (and later grub-devel) from 2015/16
  https://marc.info/?l=grub-bug=145052506901159=2
where Alexander E. Patrakov wrote:
  "Subject: [bug #46716] Protective MBR partition is not marked as bootable
   [...]
   Changing the byte at offset 0x1be to 0x80 in the resulting iso makes
   it bootable on such boards."

This led to the creation of xorrisofs option --mbr-force-bootable in
xorriso-1.4.3.

Does the following bash hack "repair" the USB stick so that it boots on
the affected machine ?

  echo $'\x80' | dd of=/dev/sdX conv=notrunc bs=1 seek=446 count=1

(Of course with outmost care when choosing the real sdX name.
Users who have a safe copy-image-to-USB-stick program should consider
to patch the image file instead and then copy it to the stick.
Therefore i added the "conv=notrunc" option to this proposal.)

The difference will not show up in partition editor listings, except
possibly as complaint that this boot/active flag with the 0xEE partition
is illegal.
EFI systems might refuse to boot from this stick for the same reason.

If it turns out that we here face this BIOS bug, then a decision is needed
whether those firmwares shall stay supported. If yes, then the mildest
known remedy would be to add xorrisofs option

  --mbr-force-bootable

which will cause a second MBR partition of type 0x00 from LBA 0 with
size 1 and boot/active flag. Something like:

  MBR partition table:   N Status  TypeStart   Blocks
  MBR partition  :   1   0x00  0xee1  1334255
  MBR partition  :   2   0x80  0x0001

EFI implementations are supposed to ignore the partition of type 0x00.
Buggy BIOS should be happy with its boot/active flag (Status 0x80).
Normal BIOS should not care for that flag, which is rather a hint for
a class of x86 MBR code on which PBMR to hop. GRUB's MBR is not of that
class.

xorrisofs option --mbr-force-bootable may be added to the grub-mkrescue
arguments. If we indeed face this bug, then a grub-mrescue ISO with EFI
equipment should not boot on the affected machine, unless this extra
option was given at production time.


Have a nice day :)

Thomas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-34-20220418.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-34-20220417.0):

ID: 1229296 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1229296
ID: 1229305 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1229305

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: grub2 BIOS booting iso and code

[Dominik 'Rathann' Mierzejewski]

On Monday, 18 April 2022 at 10:13, Thomas Schmitt wrote:
> Hi,
> 
> Dominik 'Rathann' Mierzejewski wrote:
> > - same machine USB media (written to whole device using dd)
> > Boot fails with "Operation system not found" error.
> 
> (Looks like my optimism was somewhat premature.)
> 
> I wonder from where this message comes. Was it really "Operation system"
> and not "Operating system" ?

Yes, that's the exact message. It might be coming from BIOS.

> In the cleartext strings of boot-grub2-f36.iso i find no matches for
> the two word string. Searching "peration" yields mostly lines with the
> word "Microsoft" which i assume stem from the EFI secure boot equipment.
> Searching for "perating" i find a few matches.
> None looks like a possible component of the quoted message.
> 
> So either i looked for the wrong text snippets, or the message comes
> from the compressed files in the ISO, or it comes from the firmware.
> 
> If it comes from the compressed files, then i assume that GRUB was
> found and started. Do you see any message that stems from GRUB ?

None that I can catch. Something might be getting printed to the screen
and then cleared before I can see it.

> > Same USB stick boots fine on another machine (UEFI+SecureBoot), so
> > the medium is fine.
> 
> Just to be clear (and just because i cannot get a grip on the problem):
> 
> Is this the same USB stick with same ISO image on it ?

Yes, the exact same USB stick works on another machine in UEFI mode.
I'll try to dig up my other BIOS-only machine and try it there.

> More far fetched:
> 
> Can you build a grub-mkrescue ISO from a GRUB development installation
> for legacy BIOS and EFI ?
> I don't mean a boot installation of GRUB but rather installed packages
> equivalent to what Debian offers as:
>   grub-common grub-pc-bin grub-efi-amd64-bin
> (Sorry, i failed to find the Fedora equivalent of
>   https://tracker.debian.org/pkg/grub2
> where i could learn about the equivalent package names.)

https://src.fedoraproject.org/rpms/grub2

> With the necesseray GRUB packages installed, do
> 
>   mkdir minimal
>   touch minimal/empty-file.txt
>   grub-mkrescue -o output.iso minimal
> 
> If such an "output.iso" can be built, then it would be interesting to
> know whether it boots to a "grub> " prompt (more it cannot do without
> any payload).

Thanks. I'll try that and report back.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: grub2 BIOS booting iso and code

[Thomas Schmitt]

Hi,

Dominik 'Rathann' Mierzejewski wrote:
> - same machine USB media (written to whole device using dd)
> Boot fails with "Operation system not found" error.

(Looks like my optimism was somewhat premature.)

I wonder from where this message comes. Was it really "Operation system"
and not "Operating system" ?
In the cleartext strings of boot-grub2-f36.iso i find no matches for
the two word string. Searching "peration" yields mostly lines with the
word "Microsoft" which i assume stem from the EFI secure boot equipment.
Searching for "perating" i find a few matches.
None looks like a possible component of the quoted message.

So either i looked for the wrong text snippets, or the message comes
from the compressed files in the ISO, or it comes from the firmware.

If it comes from the compressed files, then i assume that GRUB was
found and started. Do you see any message that stems from GRUB ?


> Same USB stick boots fine on another machine (UEFI+SecureBoot), so
> the medium is fine.

Just to be clear (and just because i cannot get a grip on the problem):

Is this the same USB stick with same ISO image on it ?


More far fetched:

Can you build a grub-mkrescue ISO from a GRUB development installation
for legacy BIOS and EFI ?
I don't mean a boot installation of GRUB but rather installed packages
equivalent to what Debian offers as:
  grub-common grub-pc-bin grub-efi-amd64-bin
(Sorry, i failed to find the Fedora equivalent of
  https://tracker.debian.org/pkg/grub2
where i could learn about the equivalent package names.)

With the necesseray GRUB packages installed, do

  mkdir minimal
  touch minimal/empty-file.txt
  grub-mkrescue -o output.iso minimal

If such an "output.iso" can be built, then it would be interesting to
know whether it boots to a "grub> " prompt (more it cannot do without
any payload).


Have a nice day :)

Thomas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2076185] New: perl-Net-Whois-Raw-2.99034 is available

[bugzilla]

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

Bug ID: 2076185
   Summary: perl-Net-Whois-Raw-2.99034 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Net-Whois-Raw
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 2.99034
Current version/release in rawhide: 2.99.032-2.fc36
URL: http://search.cpan.org/dist/Net-Whois-Raw/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/6677/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2076185
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure