[389-devel] Please review: 49975 rpmlint

[William Brown]

https://pagure.io/389-ds-base/issue/49975

https://pagure.io/389-ds-base/pull-request/49977

-- 
Sincerely,

William
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org

Re: Cannot Boot After Doing system-upgrade

[Jon Burgess]

On Sat, 2018-10-13 at 17:34 -0600, Chris Murphy wrote:
> On Sat, Oct 13, 2018 at 5:01 PM, Garry T. Williams <
> gtwilli...@gmail.com> wrote:
> > By the way, from the journal during the dnf system-upgrade reboot:
> > 
> > ...
> > Sep 30 10:02:28 vfr dnf[831]:   shim-x64.x86_64 15-5
> > 
> > And now:
> > ...
> > shim-x64-15-7.x86_64
> > 
> 
> Good catch. It's vaguely possible there's a bug in either shim 15-5 

There is a known bug in shim 15-5 which caused the same symptoms on my
machine. Adam Williamson explains what went wrong in this comment:

https://bugzilla.redhat.com/show_bug.cgi?id=1631989#c6

Jon

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

Re: Installation image layout

[Neal Gompa]

On Sat, Oct 13, 2018 at 8:17 PM Chris Murphy  wrote:
>
> On Fri, Oct 12, 2018 at 5:26 PM, Marek Marczykowski-Górecki
>  wrote:
> > On Fri, Oct 12, 2018 at 03:44:38PM -0600, Chris Murphy wrote:
>
> >> mkfs.btrfs has --rootdir and --shrink features to pre-allocate a
> >> volume with files at mkfs time; I have no idea to what degree it
> >> depends on kernel code.
> >
> > Probably not at all, given it works as non-root user too.
> > I've tried to run it twice on the same directory (and with the same
> > --uuid) on 32MB of data and got different images (~2000 lines of hexdump
> > diff). Could be some timestamps, could be something else.
>
> There is volume UUID which is what --uuid affects. But there are other
> uuids, including the chunk uuid which gets repeated in every leaf and
> node along with the volume uuid, device uuid, each files tree
> (subvolume) get its own uuid, etc. Time stamps include atime, otime,
> mtime, and ctime. Some objects have all 0's for uuid, and some items
> have only 0.0 for times. I'll float the reproducibility question on
> the Btrfs list, if it's desirable, useful, and how difficult it is. I
> think subsetting Btrfs features to reduce complexity generally, and
> therefore increase reproducibility as a consequence of that, has
> merit.
>

This is a really interesting idea...

>
> >> It's also
> >> possible with dm-verity or dm-integrity but then that adds back the dm
> >> complexity.
> >
> > Oh, please, no...
>
> Haha...
>

This made me giggle a bit. :)

> >
> > There are two almost separate aspects here:
> >  - image layout (squashfs+ext4, squashfs alone, squashfs+btrfs)
> >  - how copy-on-write is achieved (dm-snapshot, overlay fs)
>
> ext4 alone, and btrfs alone are also viable. But since ext4 has no
> compression, image size grows by maybe a factor of 2. Btrfs supports
> lzo and zlib compression since forever, and zstd since kernel 4.14,
> same as squashfs. What's been missing is mksquashfs with zstd support,
> which I imagine will be in 5.0. The compression ratio compares well
> with xz currently being used by mksquashfs in Fedora composes, but
> with much less CPU to compress and decompress. So I'd say go with zstd
> in any case.
>

squashfs has supported zstd along with btrfs since kernel 4.14. zstd
support was mainlined into squashfs-tools a year ago:
https://github.com/plougher/squashfs-tools/commit/6113361316d5ce5bfdc118d188e5617a1fcd747c

However, there's been no releases since the migration from CVS on SF
to Git on GitHub.

>
> >
> > For reproducibility, squashfs alone is the best option, but does not
> > improve integrity checking (but also doesn't make it worse).
>
> I'm not able to estimate how much work it is to add a files hash
> manifest to squashfs, and to always use it on reads, and then add some
> error handling to EIO upon any mismatch. But yeah it'd need user space
> code in mksquashfs and also kernel code to support it.
>
>
> > As for copy-on-write, dm-snapshot is quite complex to setup and require
> > underlying FS to support write. Also, doesn't allow to write more data
> > than original image size (may be an issue for persistent partition
> > case). Overlay fs on the other hand works with any underlying fs, you
> > can write as much data as you want. And in case of persistent partition,
> > you can access that data even if base image (the lower layer) is
> > unavailable/broken. I think the only downside of overlay fs is when you
> > modify large file it gets copied in full to the upper layer. But I don't
> > think that's an issue in this use case.
> >
> > For me, overlay fs is a clear winner here.
> > But as for image layout, it isn't that simple. For reproducibility,
> > squashfs alone is better. But if the goal of this change would be also
> > improving read errors detection, then it isn't that clear anymore. It
> > may be that it takes a simple mkfs.btrfs patch to make it reproducible,
> > but it isn't obvious for me at this stage. Also, keeping two layers
> > looks like unnecessary complexity.
>
> I agree. Overlayfs works fine with any of the discussed filesystems.
> I'd give a slight edge to Btrfs seed+sprout as the overlay mechanism
> in the case of persistence on a USB stick: a) checksumming b)
> compression helps improve performance of USB flash drives and reduces
> wear c) kernel discovers both seed and sprout in early boot by sprout
> uuid alone, no special mount options needed for setup. But it's a
> really minor point because a) and b) are still possible with overlayfs
> with a new independent btrfs as the upperdir.
>
>
> > What do you think about sidestepping this discussion a little and
> > replacing dm-snapshot with overlay fs regardless of other changes here?
> > That should be doable without any change to image format and will give
> > more flexibility there.
>
> Agreed. What I can't tell you off hand is if livecd-iso-to-disk would
> be affected by this in some way; or whether the change policy applies.
> But I think it's better to file 

Re: Cannot Boot After Doing system-upgrade

[Chris Murphy]

On Sat, Oct 13, 2018 at 5:57 PM, Garry T. Williams  wrote:
> On Saturday, October 13, 2018 7:34:44 PM EDT Chris Murphy wrote:
>> Good catch. It's vaguely possible there's a bug in either shim 15-5
>> or grub2-efi 2.02-58 as it relates to your firmware, that caused
>> it to silently fail, and the firmware did a fallback to the 2nd
>> BootOrder, which is the Ubuntu entry.
>
> I want to emphasize that it was *not* boot order that changed.  I
> manually attempted to boot Fedora, but it failed (oh how I wish I had
> paid attention to the details).
>
> Anyway, I can manually change the boot order to either OS and it
> respects my change.  My problem was something else entirely since a
> manual change didn't boot Fedora.

I'd expect any failure (due to bug or general disagreement between
firmware and shim and grub) to result in the firmware using the next
boot entry in BootOrder. This fallback behavior is in the UEFI
specification for all firmware to follow and supposedly behave
consistently, it's not something you're doing.



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

Re: Installation image layout

[Chris Murphy]

On Fri, Oct 12, 2018 at 5:26 PM, Marek Marczykowski-Górecki
 wrote:
> On Fri, Oct 12, 2018 at 03:44:38PM -0600, Chris Murphy wrote:

>> mkfs.btrfs has --rootdir and --shrink features to pre-allocate a
>> volume with files at mkfs time; I have no idea to what degree it
>> depends on kernel code.
>
> Probably not at all, given it works as non-root user too.
> I've tried to run it twice on the same directory (and with the same
> --uuid) on 32MB of data and got different images (~2000 lines of hexdump
> diff). Could be some timestamps, could be something else.

There is volume UUID which is what --uuid affects. But there are other
uuids, including the chunk uuid which gets repeated in every leaf and
node along with the volume uuid, device uuid, each files tree
(subvolume) get its own uuid, etc. Time stamps include atime, otime,
mtime, and ctime. Some objects have all 0's for uuid, and some items
have only 0.0 for times. I'll float the reproducibility question on
the Btrfs list, if it's desirable, useful, and how difficult it is. I
think subsetting Btrfs features to reduce complexity generally, and
therefore increase reproducibility as a consequence of that, has
merit.


>> It's also
>> possible with dm-verity or dm-integrity but then that adds back the dm
>> complexity.
>
> Oh, please, no...

Haha...

>
> There are two almost separate aspects here:
>  - image layout (squashfs+ext4, squashfs alone, squashfs+btrfs)
>  - how copy-on-write is achieved (dm-snapshot, overlay fs)

ext4 alone, and btrfs alone are also viable. But since ext4 has no
compression, image size grows by maybe a factor of 2. Btrfs supports
lzo and zlib compression since forever, and zstd since kernel 4.14,
same as squashfs. What's been missing is mksquashfs with zstd support,
which I imagine will be in 5.0. The compression ratio compares well
with xz currently being used by mksquashfs in Fedora composes, but
with much less CPU to compress and decompress. So I'd say go with zstd
in any case.


>
> For reproducibility, squashfs alone is the best option, but does not
> improve integrity checking (but also doesn't make it worse).

I'm not able to estimate how much work it is to add a files hash
manifest to squashfs, and to always use it on reads, and then add some
error handling to EIO upon any mismatch. But yeah it'd need user space
code in mksquashfs and also kernel code to support it.


> As for copy-on-write, dm-snapshot is quite complex to setup and require
> underlying FS to support write. Also, doesn't allow to write more data
> than original image size (may be an issue for persistent partition
> case). Overlay fs on the other hand works with any underlying fs, you
> can write as much data as you want. And in case of persistent partition,
> you can access that data even if base image (the lower layer) is
> unavailable/broken. I think the only downside of overlay fs is when you
> modify large file it gets copied in full to the upper layer. But I don't
> think that's an issue in this use case.
>
> For me, overlay fs is a clear winner here.
> But as for image layout, it isn't that simple. For reproducibility,
> squashfs alone is better. But if the goal of this change would be also
> improving read errors detection, then it isn't that clear anymore. It
> may be that it takes a simple mkfs.btrfs patch to make it reproducible,
> but it isn't obvious for me at this stage. Also, keeping two layers
> looks like unnecessary complexity.

I agree. Overlayfs works fine with any of the discussed filesystems.
I'd give a slight edge to Btrfs seed+sprout as the overlay mechanism
in the case of persistence on a USB stick: a) checksumming b)
compression helps improve performance of USB flash drives and reduces
wear c) kernel discovers both seed and sprout in early boot by sprout
uuid alone, no special mount options needed for setup. But it's a
really minor point because a) and b) are still possible with overlayfs
with a new independent btrfs as the upperdir.


> What do you think about sidestepping this discussion a little and
> replacing dm-snapshot with overlay fs regardless of other changes here?
> That should be doable without any change to image format and will give
> more flexibility there.

Agreed. What I can't tell you off hand is if livecd-iso-to-disk would
be affected by this in some way; or whether the change policy applies.
But I think it's better to file the change so there's awareness and
coordination: installer team would have to sign off on the pull
request for lorax, and then releng team probably should know about it
because they define their own compose settings (I guess they often use
upstreams defaults but they don't have to), and then QA might want a
heads up so if things blow up they know who to ask what's up, and then
it's also a good idea to let SOAS folks know about it. And a central
point of filing changes is coordination.

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



-- 
Chris Murphy

[Test-Announce] 2018-10-15 @ 16:00 UTC - Fedora 29 Blocker Review Meeting

[Adam Williamson]

# F29 Blocker Review meeting
# Date: 2018-10-15
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.freenode.net

Hi folks! We have 7 proposed Final blockers and 2 proposed Final freeze
exceptions to review, so let's have a review meeting on Monday. We have
GNOME and dnf bugs, and one iSCSI bug on the list.

** NOTE ** I may not be able to run the meeting, as I'm going on
vacation that same Monday. If I'm not available, we really need someone
else to step up and run the meeting, as this is the last review meeting
before the go/no-go meeting which is on Thursday. Running the meeting
is easy, there is an SOP (linked below) and you can also refer to the
logs from previous meetings for tips.

If you have time this weekend, you can take a look at the proposed or
accepted blockers before the meeting -  the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .

We'll be evaluating these bugs to see if they violate any of the 
Release Criteria and warrant the blocking of a release if they're not 
fixed. Information on the release criteria for F29 can be found on the 
wiki [0].

For more information about the Blocker and Freeze exception process, 
check out these links:
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting 
works - or how it's supposed to go and you want to run one - check out 
the SOP on the wiki:
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

Have a good weekend and see you on Monday!

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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

[EPEL-devel] Re: [Fedocal] Reminder meeting : Virtual FAD for Python3

[Neal Gompa]

On Sat, Oct 13, 2018 at 8:00 PM  wrote:
>
> Dear all,
>
> You are kindly invited to the meeting:
>Virtual FAD for Python3 on 2018-10-16 from 00:00:00 to 00:00:00 UTC
>At freenode@epel
>
> The meeting will be about:
> This will be a virtual activity day to update all python packages ot the 
> latest python wanted.
>

Are we moving to Python 3.7 (which, as far as I know, is not in EPEL7
yet), or to Python 3.6?



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

Re: Cannot Boot After Doing system-upgrade

[Garry T. Williams]

On Saturday, October 13, 2018 7:34:44 PM EDT Chris Murphy wrote:
> Good catch. It's vaguely possible there's a bug in either shim 15-5
> or grub2-efi 2.02-58 as it relates to your firmware, that caused
> it to silently fail, and the firmware did a fallback to the 2nd
> BootOrder, which is the Ubuntu entry.

I want to emphasize that it was *not* boot order that changed.  I
manually attempted to boot Fedora, but it failed (oh how I wish I had
paid attention to the details).

Anyway, I can manually change the boot order to either OS and it
respects my change.  My problem was something else entirely since a
manual change didn't boot Fedora.

I may try the manual downgrade, if I get time.  I am usually
physically away from this system so I will retrieve the old versions
and be ready when I can get the time.

Again, thank you for your thoughtful follow-ups.

-- 
Garry T. Williams


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

Re: Cannot Boot After Doing system-upgrade

[Chris Murphy]

On Sat, Oct 13, 2018 at 5:01 PM, Garry T. Williams  wrote:
> By the way, from the journal during the dnf system-upgrade reboot:
>
> Sep 30 10:02:27 vfr dnf[831]:   grub2-common.noarch 1:2.02-58.fc29
> Sep 30 10:02:27 vfr dnf[831]:   grub2-efi-x64.x86_64 1:2.02-58.fc29
> Sep 30 10:02:27 vfr dnf[831]:   grub2-pc.x86_64 1:2.02-58.fc29
> Sep 30 10:02:27 vfr dnf[831]:   grub2-pc-modules.noarch 1:2.02-58.fc29
> Sep 30 10:02:27 vfr dnf[831]:   grub2-tools.x86_64 1:2.02-58.fc29
> Sep 30 10:02:27 vfr dnf[831]:   grub2-tools-efi.x86_64 1:2.02-58.fc29
> Sep 30 10:02:27 vfr dnf[831]:   grub2-tools-extra.x86_64
> 1:2.02-58.fc29
> Sep 30 10:02:27 vfr dnf[831]:   grub2-tools-minimal.x86_64
> 1:2.02-58.fc29
>
> Sep 30 10:02:28 vfr dnf[831]:   shim-x64.x86_64 15-5
>
> And now:
>
> garry@vfr$ rpm -q grub2-common grub2-efi-x64 grub2-pc grub2-pc-modules
> grub2-tools grub2-tools-efi grub2-tools-extra grub2-tools-minimal
> shim-x64
> grub2-common-2.02-62.fc29.noarch
> grub2-efi-x64-2.02-62.fc29.x86_64
> grub2-pc-2.02-62.fc29.x86_64
> grub2-pc-modules-2.02-62.fc29.noarch
> grub2-tools-2.02-62.fc29.x86_64
> grub2-tools-efi-2.02-62.fc29.x86_64
> grub2-tools-extra-2.02-62.fc29.x86_64
> grub2-tools-minimal-2.02-62.fc29.x86_64
> shim-x64-15-7.x86_64
> garry@vfr$


Good catch. It's vaguely possible there's a bug in either shim 15-5 or
grub2-efi 2.02-58 as it relates to your firmware, that caused it to
silently fail, and the firmware did a fallback to the 2nd BootOrder,
which is the Ubuntu entry.

One way to find out, that probably isn't worth it, is to manually
downgrade to those versions, separately, to see which one (if any)
restores the problem. But, it's fixed so I probably wouldn't test it
as those versions have been superseded now.


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

Re: Cannot Boot After Doing system-upgrade

[Chris Murphy]

On Sat, Oct 13, 2018 at 4:44 PM, Garry T. Williams  wrote:
> On Saturday, October 13, 2018 5:42:15 PM EDT Chris Murphy wrote:
>> On Sat, Oct 13, 2018 at 1:30 PM, Garry T. Williams
>>  wrote:
>> > On Saturday, October 13, 2018 3:12:44 PM EDT Samuel Sieb wrote:
>> >> On 10/13/18 10:39 AM, Garry T. Williams wrote:
>> >>
>> >> > What am I doing wrong here that I cannot boot after a
>> >> > system-upgrade?
>> >>
>> >> "Doesn't boot" is no information.  What exactly is happening?
>> >
>> > Sorry, the boot record is gone.
>>
>> You determined this how?
>
> The machine did not boot the Fedora OS.  Instead, it booted the OS on
> /dev/sda.

That is not evidence the boot record is gone. If this is a UEFI
system, it's suggestive that an NVRAM variable has been altered, such
as BootOrder, or an entry removed. But NVRAM modification are also
something that dnf system upgrade cannot do.





>
> Admittedly, this is output from the now-recovered system, but I can
> attest that the same was displayed when the command was done using the
> Ubuntu system that loaded from /dev/sda.
>
>> > The system-upgrade somehow wiped out my boot record on /dev/sdb.
>>
>> "boot record" is a BIOS term, so this could mean the code on LBA 0
>> or in the MBR gap or BIOS Boot partition has been stepped on; but
>> dnf system upgrade doesn't have such an ability. In fact it's a bit
>> of a security and bug endurance problem that 'grub2-install' isn't
>> run on BIOS upgrades. Whereas on UEFI the bootloader binaries on
>> the EFI System partition are replaced during updates, so what
>> you're describing might be a GRUB bug.
>
> OK, the system was able to boot from /dev/sdb only after I reinstalled
> grub2-efi and shim.
>
> I assumed that was what restored the boot record (or whatever it's
> called).

On UEFI there's NVRAM which contains boot entries that point to
bootloader location by device, partition, and path.

But yeah you're right, autopsy is difficult now that the system is
working again. In any case, there's no single thing that really
qualifies as boot record on UEFI.


> garry@vfr$ efibootmgr -v
> BootCurrent: 0002
> Timeout: 1 seconds
> BootOrder: 0002,,0003,0004,0005,0006,0007,0008,0009
> Boot  ubuntuHD(1,GPT,3252a9ab-23eb-4fd4-9d11-6dc13c6f50ec,
> 0x800,0xfa000)/File(\EFI\ubuntu\shimx64.efi)
> Boot0002* FedoraHD(1,GPT,0534ef43-afb9-409c-8dc8-a1eff1e396ef,
> 0x800,0x64000)/File(\EFI\fedora\shim.efi)


Entry 0002 is stale; shim.efi is still valid for Fedora 29 but new
installations refer to shimx64.efi the same as the  entry for
Ubuntu. Thing is, dnf system upgrade doesn't change NVRAM menu
entries. Anyway, it may be unrelated. It's just a data point for now.
But everything you provided looks sane, which is probably why it's
booting, and evidence of the unworking state isn't available so we can
only guess what happened.

- BootOrder shouldn't be changed by anything dnf system upgrade does
- Deleting boot entries from NVRAM should be anything dnf system upgrade does
- dnf system upgrade should have replaced pretty much all the binary
files on the /dev/sdb EFI System partition, same as you reinstalling
shim and grub2-efi

I suspect a detail is missing that seems innocuous and unintuitive as
to it's relationship to the failure; but is actually related.

For example, on my HP with Windows 10 and Fedora 29:

[chris@flap ~]$ sudo efibootmgr -v
[sudo] password for chris:
BootCurrent: 
Timeout: 0 seconds
BootOrder: ,3000,0002,2001,2002,2004
Boot* Fedora
HD(2,GPT,0273e9d0-2c96-49fc-a046-b67914664deb,0xfa000,0x32000)/File(\EFI\fedora\shimx64.efi)
Boot0002* Windows Boot Manager
HD(2,GPT,0273e9d0-2c96-49fc-a046-b67914664deb,0xfa000,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...r
Boot2001* EFI USB DeviceRC
Boot3000* Internal Hard Disk or Solid State DiskRC
Boot3002* Internal Hard Disk or Solid State DiskRC
[chris@flap ~]$

Fedora should boot first. However, if I enter firmware setup and
close, whether I change anything or not? It always boots Windows by
default from then on. The BootOrder variable is changed, just by
virtue of entering firmware setup (not the firmware's boot manager).
That's fakaked! However, I have to change BootOrder with efibootmgr,
reinstalling shim and grub2-efi doesn't fix it, because installing
those packages doesn't change EFI NVRAM variables.



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

Re: Cannot Boot After Doing system-upgrade

[Garry T. Williams]

By the way, from the journal during the dnf system-upgrade reboot:

Sep 30 10:02:27 vfr dnf[831]:   grub2-common.noarch 1:2.02-58.fc29
Sep 30 10:02:27 vfr dnf[831]:   grub2-efi-x64.x86_64 1:2.02-58.fc29
Sep 30 10:02:27 vfr dnf[831]:   grub2-pc.x86_64 1:2.02-58.fc29
Sep 30 10:02:27 vfr dnf[831]:   grub2-pc-modules.noarch 1:2.02-58.fc29
Sep 30 10:02:27 vfr dnf[831]:   grub2-tools.x86_64 1:2.02-58.fc29
Sep 30 10:02:27 vfr dnf[831]:   grub2-tools-efi.x86_64 1:2.02-58.fc29
Sep 30 10:02:27 vfr dnf[831]:   grub2-tools-extra.x86_64 
1:2.02-58.fc29
Sep 30 10:02:27 vfr dnf[831]:   grub2-tools-minimal.x86_64 
1:2.02-58.fc29

Sep 30 10:02:28 vfr dnf[831]:   shim-x64.x86_64 15-5

And now:

garry@vfr$ rpm -q grub2-common grub2-efi-x64 grub2-pc grub2-pc-modules 
grub2-tools grub2-tools-efi grub2-tools-extra grub2-tools-minimal 
shim-x64
grub2-common-2.02-62.fc29.noarch
grub2-efi-x64-2.02-62.fc29.x86_64
grub2-pc-2.02-62.fc29.x86_64
grub2-pc-modules-2.02-62.fc29.noarch
grub2-tools-2.02-62.fc29.x86_64
grub2-tools-efi-2.02-62.fc29.x86_64
grub2-tools-extra-2.02-62.fc29.x86_64
grub2-tools-minimal-2.02-62.fc29.x86_64
shim-x64-15-7.x86_64
garry@vfr$

-- 
Garry T. Williams


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

Re: Cannot Boot After Doing system-upgrade

[Garry T. Williams]

On Saturday, October 13, 2018 5:42:15 PM EDT Chris Murphy wrote:
> On Sat, Oct 13, 2018 at 1:30 PM, Garry T. Williams
>  wrote:
> > On Saturday, October 13, 2018 3:12:44 PM EDT Samuel Sieb wrote:
> >> On 10/13/18 10:39 AM, Garry T. Williams wrote:
> >> 
> >> > What am I doing wrong here that I cannot boot after a
> >> > system-upgrade?
> >>
> >> "Doesn't boot" is no information.  What exactly is happening?
> >
> > Sorry, the boot record is gone.
> 
> You determined this how?

The machine did not boot the Fedora OS.  Instead, it booted the OS on
/dev/sda.

Of course, I attempted to boot from the Fedora disk by using the boot
device configuration screen by hitting F12 during reboot.  This
failed.  (A photograph of the error would have been a good idea.)

I assumed that the reason was the boot record was missing.

> >I happen to have another system on
> >
> > the same machine and that system boots instead of the Fedora
> > system before my recovery actions.  When I forced a boot from
> > the fedora system using the machine's boot selection screen, it
> > fails.  (No diagnostic information in the BIOS setup screen --
> > just won't boot.  I was forced to specify the USB Live system to
> > start a recovery.)
> 
> Screen shots or cell photo of the failure might be useful because
> failure/won't boot doesn't tell us what is happening. And what is
> happening is a hint as to what the source of the problem is, how to
> prevent it, and how to fix it. But "won't boot" is not much to go
> on.

Understood.

> Is this BIOS or UEFI? From any other Linux, what do you get for
> 'parted -l u s p'  or "fdisk -l" ? And what do you get for
> 'efibootmgr -v' ?

This is useful.  I will try to document these results when I upgrade
to F30, if the same happens again.

The fdisk -l did show what I expected it to show:

Disk /dev/sda: 477 GiB, 512110190592 bytes, 1000215216 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: 4B21E327-DFE8-4105-AA9B-FEFF8AE8439F

Device StartEnd   Sectors   Size Type
/dev/sda1   20481026047   1024000   500M EFI System
/dev/sda210260487317503   6291456 3G Microsoft basic data
/dev/sda37317504  933572607 926255104 441.7G Linux filesystem
/dev/sda4  933572608 1000214527  66641920  31.8G Linux swap

Disk /dev/sdb: 477 GiB, 512110190592 bytes, 1000215216 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: 9114D615-2FD0-4CF1-A601-DAD4507F6254

Device   StartEnd   Sectors   Size Type
/dev/sdb1 2048 411647409600   200M EFI System
/dev/sdb2   4116482508799   2097152 1G Linux filesystem
/dev/sdb3  2508800 1000214527 997705728 475.8G Linux LVM

Admittedly, this is output from the now-recovered system, but I can
attest that the same was displayed when the command was done using the
Ubuntu system that loaded from /dev/sda.

> > The system-upgrade somehow wiped out my boot record on /dev/sdb.
> 
> "boot record" is a BIOS term, so this could mean the code on LBA 0
> or in the MBR gap or BIOS Boot partition has been stepped on; but
> dnf system upgrade doesn't have such an ability. In fact it's a bit
> of a security and bug endurance problem that 'grub2-install' isn't
> run on BIOS upgrades. Whereas on UEFI the bootloader binaries on
> the EFI System partition are replaced during updates, so what
> you're describing might be a GRUB bug.

OK, the system was able to boot from /dev/sdb only after I reinstalled
grub2-efi and shim.

I assumed that was what restored the boot record (or whatever it's
called).

(I was able to boot normally from Fedora immediately before doing the
dnf system-upgrade.  A reinstall was not accepted by dnf, so I used
update instead.)

> But the details you're giving only lead to speculation so you need
> to provide specifics, just won't boot is identical to what happens
> to a computer without a drive at all.

Well, I will not be so fast to restore, if it occurs again (f30).

Thank you for your suggestions.  I am sorry for the assumptions I
made.

For what it's worth now:

garry@vfr$ efibootmgr -v
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,,0003,0004,0005,0006,0007,0008,0009
Boot  ubuntuHD(1,GPT,3252a9ab-23eb-4fd4-9d11-6dc13c6f50ec,
0x800,0xfa000)/File(\EFI\ubuntu\shimx64.efi)
Boot0002* FedoraHD(1,GPT,0534ef43-afb9-409c-8dc8-a1eff1e396ef,
0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0003* UEFI: SanDisk Extreme 0001PciRoot(0x0)/Pci(0x14,0x0)/
USB(17,0)/HD(1,MBR,0x3cb5dbe1,0x16960,0x2990)..BO
Boot0004* Diskette DriveBBS(Floppy,Diskette Drive,0x0)..BO
Boot0005* P0: SK hynix SC300 SATA 512GB BBS(HD,P0: SK hynix SC300 SATA 
512GB ,0x0)..BO
Boot0006* P2: INTEL SSDSC2KF512H6 SATA 5BBS(HD,P2: INTEL 
SSDSC2KF512H6 

Re: Redis modules license change and the 'GoodFORM' project

[Gavin Henry]

Great work!

On Thu, 4 Oct 2018 at 08:04, Nathan Scott  wrote:

> Hi all,
>
> This is a general notice about the 'Apache Commons Clause' license
> change affecting several Redis Labs modules.  In Fedora today the
> 'rejson' and 'rebloom' packages are affected.
> https://fedoraproject.org/wiki/Licensing:Main#License_Changes
>
> After much discussion, the Debian maintainer (of a similarly
> re-licensed module) and I have decided to collaborate on maintaining
> forks of the last open versions of these modules.
>
> https://goodformcode.com/
>
> Any support you can show would be much appreciated - thanks!
>
> cheers.
>
> --
> Nathan
> ___
> 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
>
-- 
http://www.suretecsystems.com/services/openldap/
http://www.surevoip.co.uk
___
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

Fedora 29-20181013.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 6/133 (x86_64), 1/2 (arm)

ID: 295158  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/295158
ID: 295179  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/295179
ID: 295180  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/295180
ID: 295192  Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/295192
ID: 295196  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/295196
ID: 295200  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/295200
ID: 295257  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/295257

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

ID: 295162  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/295162
ID: 295163  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/295163
ID: 295218  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/295218
ID: 295246  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/295246
ID: 295271  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/295271

Passed openQA tests: 124/133 (x86_64), 22/24 (i386)

Skipped openQA tests: 1 of 159
-- 
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://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

[Bug 1638230] Upgrade perl-File-Slurp to 9999.21

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-File-Slurp-.21-1.fc29 has been pushed to the Fedora 29 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-a44e606dd7

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

Re: What to do about sagemath

[Miro Hrončok]

On 12.10.2018 22:13, Jerry James wrote:

This is from Includes/cpython/longintrepr.pxd in Cython 0.28.4, which
does not trigger the above error:

 ctypedef struct PyLongObject:
 digit* ob_digit

This is from the same file in Cython 0.29~rc2-1, which does trigger
the above error:

 ctypedef class __builtin__.py_long [object PyLongObject]:
 cdef digit* ob_digit


This was done in 
https://github.com/cython/cython/commit/4bd2c9b85ac2d85fe40a56296dcc86f271313c11


Particularly interesting is the change in tests/run/longintrepr.pyx:

  ret = _PyLong_New(index + 1)
- (ret).ob_digit[index] = low
+ ret.ob_digit[index] = low



There is exactly one use of PyLongObject, on line 211:

 cdef const digit* D = (x).ob_digit


Would changing to:

cdef const digit* D = x.ob_digit

do?

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

Re: Yet another gargantuan mathematical software update

[Till Hofmann]

On 10/12/18 9:14 PM, Jerry James wrote:
> On Sun, Oct 7, 2018 at 7:33 AM Till Hofmann  
> wrote:
>> FYI: gazebo is currently FTBFS because player is FTBFS. I looked into
>> player and fixed two smaller issues [1], but it's still FTBFS [2]. It
>> looks like it's still requiring python2 but uses the default python3
>> during build and then fails. So it needs to be migrated to python3...
> 
> Okay, I will skip gazebo ... and fawkes too, then, right?  Thanks,
> 

Yes, I'm afraid so.

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

Fedora 29 compose report: 20181013.n.0 changes

[Fedora Branched Report]

OLD: Fedora-29-20181012.n.0
NEW: Fedora-29-20181013.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   3
Downgraded packages: 0

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

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  krb5-1.16.1-21.fc29
Old package:  krb5-1.16.1-20.fc29
Summary:  The Kerberos network authentication system
RPMs: krb5-devel krb5-libs krb5-pkinit krb5-server krb5-server-ldap 
krb5-workstation libkadm5
Size: 18.42 MiB
Size change:  4.84 KiB
Changelog:
  * Tue Oct 09 2018 Adam Williamson  - 1.16.1-21
  - Revert the patch from -20 for now as it seems to make FreeIPA worse


Package:  nautilus-3.30.2-1.fc29
Old package:  nautilus-3.30.1-1.fc29
Summary:  File manager for GNOME
RPMs: nautilus nautilus-devel nautilus-extensions
Size: 16.16 MiB
Size change:  24.49 KiB
Changelog:
  * Fri Oct 12 2018 Kalev Lember  - 3.30.2-1
  - Update to 3.30.2


Package:  plymouth-0.9.3-14.fc29
Old package:  plymouth-0.9.3-13.fc29
Summary:  Graphical Boot Animation and Logger
RPMs: plymouth plymouth-core-libs plymouth-devel plymouth-graphics-libs 
plymouth-plugin-fade-throbber plymouth-plugin-label plymouth-plugin-script 
plymouth-plugin-space-flares plymouth-plugin-throbgress 
plymouth-plugin-two-step plymouth-scripts plymouth-system-theme 
plymouth-theme-charge plymouth-theme-fade-in plymouth-theme-script 
plymouth-theme-solar plymouth-theme-spinfinity plymouth-theme-spinner
Size: 5.81 MiB
Size change:  22.62 KiB
Changelog:
  * Thu Oct 04 2018 Hans de Goede  - 0.9.3-14
  - Add patches from upstream to fix the disk unlock screen sometimes having
a very low resolution on UEFI machines:
https://gitlab.freedesktop.org/plymouth/plymouth/issues/68



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

[Bug 1638230] Upgrade perl-File-Slurp to 9999.21

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
perl-File-Slurp-.21-1.fc29 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-a44e606dd7

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

[Bug 1638230] Upgrade perl-File-Slurp to 9999.21

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-File-Slurp-.21-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-73bf152903

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

[Bug 1638230] Upgrade perl-File-Slurp to 9999.21

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-File-Slurp-.21-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-f8bbc4a096

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

Re: Fedora 29 Final Go/No-Go meeting

[Dusty Mabe]

On 10/12/2018 10:08 PM, Trever L. Adams wrote:
> On 10/12/18 9:27 AM, Ben Cotton wrote:
>> Dear all,
>>
>> The Go/No-Go meeting for the Fedora 29 Final release will be held on
>> Thursday, 2018-10-18 at 17:00 UTC in #fedora-meeting-1. For more
>> information, see: https://fedoraproject.org/wiki/Go_No_Go_Meeting
>>
>> View the meeting on Fedocal at
>> https://apps.fedoraproject.org/calendar/Fedora%20release/2018/10/18/#m9379
>>
> I am not part of the groups that are at these meetings. Please, consider
> Bug #1636811 about FreeRadius. It is a simple fix.

Good news! You can propose it yourself here and it will be considered:

https://qa.fedoraproject.org/blockerbugs/propose_bug
___
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

[rpms/perl-File-Slurp] New Commits To "rpms/perl-File-Slurp" (f27)

[pagure]

The following commits were pushed to the repo rpms/perl-File-Slurp on branch
f27, which you are following:
a58b37268a94de8b3ea0b5d377e392a5b88235bdRalf CorsépiusCleanup merger.
7911a88a91d5841e2cd2c2dbc2d9a7e36324aed9Ralf CorsépiusCleanup merger.
66bea19432a5858fe79ca901d3a35c63faa1aa51Ralf CorsépiusUpdate to 
.21-1. Rework BRs. Drop xt-test. Spec file cosmetics.
4cfa84f8abba587742ac43cb67d5f4729c74be2bFedora Release Engineering- 
Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
b083a77289e72189fa39314029d3dd46036d24b5Jitka PlesnikovaPerl 5.28 
rebuild
bcc83595cb8c5b03790ef2c20301acb83ac32c25Petr Písařcpan.org addresses 
moved to MetaCPAN 
f16295a9993b2aeb35098c1648cb38f4055d2f25Fedora Release Engineering- 
Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-File-Slurp/commits/f27
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[rpms/perl-File-Slurp] New Commits To "rpms/perl-File-Slurp" (f28)

[pagure]

The following commits were pushed to the repo rpms/perl-File-Slurp on branch
f28, which you are following:
7911a88a91d5841e2cd2c2dbc2d9a7e36324aed9Ralf CorsépiusCleanup merger.
66bea19432a5858fe79ca901d3a35c63faa1aa51Ralf CorsépiusUpdate to 
.21-1. Rework BRs. Drop xt-test. Spec file cosmetics.
4cfa84f8abba587742ac43cb67d5f4729c74be2bFedora Release Engineering- 
Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
b083a77289e72189fa39314029d3dd46036d24b5Jitka PlesnikovaPerl 5.28 
rebuild
bcc83595cb8c5b03790ef2c20301acb83ac32c25Petr Písařcpan.org addresses 
moved to MetaCPAN 



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-File-Slurp/commits/f28
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[rpms/perl-File-Slurp] New Commits To "rpms/perl-File-Slurp" (f29)

[pagure]

The following commits were pushed to the repo rpms/perl-File-Slurp on branch
f29, which you are following:
66bea19432a5858fe79ca901d3a35c63faa1aa51Ralf CorsépiusUpdate to 
.21-1. Rework BRs. Drop xt-test. Spec file cosmetics.



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-File-Slurp/commits/f29
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: package downgrades from f28 to f29

[José Abílio Matos]

On Wednesday, 10 October 2018 21.34.47 WEST David Timms wrote:
> Given Fedora runs on community power, have you tried rebuilding the
> packages that interest you under f29 to see/fix any problems that arise ?

Yes. As long as the time that I available allows.

> You can also use the web tools to see what the current rpm spec and
> builds have been requested, and if any new freshness bugs are in bugzilla.
> The maintainer may very well appreciate your assistance.
> 
> Dave.

Dave I can understand the purpose of your message but IMHO it fails the point 
of this thread.

Some releases ago I have updated one package in the two supported stable 
releases (F-(n-2) and F-(n-1)) while the moving of updates to stable from the 
soon to be released F-n versions were frozen (just like they are now).

Of course I could have remembered that and have delayed the update until the 
ban to move packages to stable was lifted, ensuring then that the upgrade path 
between releases is always working. It was my mistake, I got a notice that the 
updates to versions F-(n-2) and F-(n-1) were ready to go to stable, the 
feedback was positive and thus I pushed then to stable.

The corollary of this thread and of the previous story is that I think that 
the tools that we use to issue updates should help us detect those corner 
cases where the update path is broken.

Regards, :-)
-- 
José Abílio

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

Review swaps

[Robert-André Mauchin]

Hello,

I'd like to ask your assistance to review some packages, in exchange of yours.

2 C++ packages recently featured in FedoraMagazine: 
https://fedoramagazine.org/better-image-upscaling-waifu2x/

 - Review Request: waifu2x-converter-cpp - Image Super-Resolution for 
Anime-style art using OpenCL and OpenCV
   https://bugzilla.redhat.com/show_bug.cgi?id=1638958

 - Review Request: qtwaifu2x - Frontend for waifu2x-converter-cpp 
   https://bugzilla.redhat.com/show_bug.cgi?id=1638959

3 simple Golang packages needed by the latest version of Rclone:

 - Review Request: golang-github-azure-pipeline - Implements an HTTP 
request/response middleware pipeline
   https://bugzilla.redhat.com/show_bug.cgi?id=1636471

 - Review Request: golang-github-azure-storage-blob - Microsoft Azure Blob 
Storage Library for Go
   https://bugzilla.redhat.com/show_bug.cgi?id=1636549

 - Review Request: golang-github-google-martian - Library for building custom 
HTTP/S proxies 
   https://bugzilla.redhat.com/show_bug.cgi?id=1636497

Thank you all!

Robert-André

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

Re: Fedora 29 Final Go/No-Go meeting

[Matthew Miller]

On Fri, Oct 12, 2018 at 08:08:20PM -0600, Trever L. Adams wrote:
> I am not part of the groups that are at these meetings. Please, consider
> Bug #1636811 about FreeRadius. It is a simple fix.

Hi Trever. I'm not sure this violates any of our release criteria, and may
be more appropriate to just have as a zero-day fix. If there's a criterion
you can see that it violates, you can nominate it as a blocker bug (even if
you're not at the meeting).

https://fedoraproject.org/wiki/Fedora_29_Final_Release_Criteriaa

If it doesn't seem to be a release blocker but affects a significant number
of people and doesn't seem to be getting attention, consider nominating it
as a prioritized bug instead:

https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues_-_the_process



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

[rpms/perl-File-Slurp] New Commits To "rpms/perl-File-Slurp" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-File-Slurp on branch
master, which you are following:
66bea19432a5858fe79ca901d3a35c63faa1aa51Ralf CorsépiusUpdate to 
.21-1. Rework BRs. Drop xt-test. Spec file cosmetics.



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-File-Slurp/commits/master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org