Re: Fedora 27 kernel updates make system unbootable (sort of)

[Chris Murphy]

On Tue, Apr 24, 2018 at 1:08 PM, François Cami  wrote:
>> On Fri, Apr 20, 2018 at 3:32 PM, Lennart Poettering
>> >
>> OK after a bunch of additional testing, one thing is certain; grubby
>> and grub-mkconfig are not even remotely crash safe. They do not
>> fsync() or sync() at all. That's not good no matter the file system.
>
> May I point you to https://github.com/rhboot/grubby/pull/24 which *should* 
> fix most of that.

Merged upstream almost a year ago, meanwhile Fedora is based on
something 3 years old. I have no idea what's going on with that. I
know for sure fsync() alone does not fully commit everything, most
changes are in the journal. So while it is crash safe as far as kernel
log replay code is concerned, it's not bootloader crash safe for ext4,
XFS, or Btrfs. I've tested that.


>
> https://github.com/rhboot/grubby/pull/28 will fix *all* of that when /boot is 
> a separate FS.

It doesn't.

1. The biggest problem is when /boot is on / and when / can't remount-ro.
2. It still doesn't sync() when /boot is not separate.
3. I could be mistaken but, pretty sure on non-journaled file systems
you need to fsync() the file and fsync() the containing directory for
it to fully commit; or you need to use sync().

But I am confused how this is merged almost a year ago and Fedora's
grubby appears to last be rebased three years ago, so it doesn't have
this fix.

>
>> The best near term change that I think we should make is putting a
>> sync() somewhere in grubby. I've tested modifying new-kernel-pkg to
>> add a sync right before the last line, and
>>
>> # dnf update -y /path/to/kernelrpms && echo b > /proc/sysrq-trigger
>>
>> With very limited testing (dozens of reboots in multiple fs
>> configurations of a VM only, using unsafe caching), all configurations
>> including XFS are better off with sync() added. It a highly
>> non-deterministic mess to sort out without sync().
>>
>> But with sync() and with /boot on XFS: the kernel, initramfs, or
>> grub.cfg - there is an unknown (let's say 50/50) probability the
>> bootloader can't find or read those files despite the sync(). The most
>> common outcome I ran into was a partially modified grub.cfg containing
>> an incomplete default entry for the new kernel which is missing the
>> grubby insertion for the initrd. So it can't boot. But if the grub
>> menu appears at all, the previous kernel and rescue entries are still
>> there, and they work. Log replay during boot fixes up everything and
>> now the next boot works fine by default without user interaction. So
>> even though sync() is still not good enough for XFS always, it's way
>> better than no sync().
>>
>> Meanwhile FAT, ext2, ext4, and Btrfs all appear to flush to disk with
>> sync() sufficient for the bootloader to have no problems.
>>
>> Note that fsync() is actually insufficient at least some of the time
>> on all journaled file systems. e.g. dracut -f only does fsync() on the
>> copied over initramfs to /boot and that new initramfs is often not
>> seen by the bootloader for journaled file systems.
>
> Not after 
> https://github.com/dracutdevs/dracut/commit/58e3971b920fbb60e5a90edfd30aa887f9818100

OK but still doesn't work if the containing directory is not a mount
point, so /boot directory on / is exempt *and* there is no sync() so
even on ext4 and Btrfs it's not bootloader crash safe with the earlier
fsync() alone.




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

Fedora-Atomic 28-20180424.4 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 2/2 (x86_64)
-- 
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

[Bug 1571484] New: perl-Mojolicious-7.76 is available

[bugzilla]

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

Bug ID: 1571484
   Summary: perl-Mojolicious-7.76 is available
   Product: Fedora
   Version: rawhide
 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



Latest upstream release: 7.76
Current version/release in rawhide: 7.75-1.fc29
URL: http://mojolicio.us/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/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.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: script to run after hotspot authentication?

[Björn Persson]

Paul Wouters  wrote:
> So I guess the problem that is used is
> /usr/libexec/gnome-shell-portal-helper

Writing "problem" instead of "program" seems quite appropriate, given
the quality of most software in the world.

Björn Persson


pgpC0reNedOSb.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: script to run after hotspot authentication?

[Sam Varshavchik]

Paul Wouters writes:



Hi,

Is there a way to run a custom command after hotspot authentication?

Fedora has/had some ways of detecting portals. dnssec-trigger,
NetworkManager and Gnome3. I think the current method is supposed
to be based on the latter. So I guess the problem that is used is
/usr/libexec/gnome-shell-portal-helper

Does that signal anything back to NM? It seems the helper itself has
no "post" commands it can run.

Specifially, I'm trying to solve the problem of IPsec MOBIKE support.
When we receive a notification of the new IP address via netlink, the
network isn't working yet and our mobike address update request using
this new IP address dies in the portal filter. The user authenticats
and the captive portal disables the filter, but we no longer receive
any update about this event from netlink/kernel.


You might be able to hook into dhclient.

See /usr/share/doc/dhcp-client/README.dhclient.d



pgpqKwzAhIhVB.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

script to run after hotspot authentication?

[Paul Wouters]

Hi,

Is there a way to run a custom command after hotspot authentication?

Fedora has/had some ways of detecting portals. dnssec-trigger,
NetworkManager and Gnome3. I think the current method is supposed
to be based on the latter. So I guess the problem that is used is
/usr/libexec/gnome-shell-portal-helper

Does that signal anything back to NM? It seems the helper itself has
no "post" commands it can run.

Specifially, I'm trying to solve the problem of IPsec MOBIKE support.
When we receive a notification of the new IP address via netlink, the
network isn't working yet and our mobike address update request using
this new IP address dies in the portal filter. The user authenticats
and the captive portal disables the filter, but we no longer receive
any update about this event from netlink/kernel.

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

Fedora 28-20180424.n.0 compose check report

[Fedora compose checker]

No missing expected images.

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

New failures (same test did not fail in 28-20180423.n.0):

ID: 229239  Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/229239
ID: 229275  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/229275
ID: 229364  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/229364

Old failures (same test failed in 28-20180423.n.0):

ID: 229278  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/229278
ID: 229279  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/229279
ID: 229294  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/229294
ID: 229379  Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/229379

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

Old soft failures (same test soft failed in 28-20180423.n.0):

ID: 229243  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/229243
ID: 229256  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/229256
ID: 229257  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/229257
ID: 229298  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default_upload
URL: https://openqa.fedoraproject.org/tests/229298
ID: 229302  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default@uefi
URL: https://openqa.fedoraproject.org/tests/229302
ID: 229304  Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/229304
ID: 229318  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/229318
ID: 229335  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/229335
ID: 229341  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/229341

Passed openQA tests: 127/137 (x86_64), 19/24 (i386)

Skipped openQA tests: 1 of 163

Installed system changes in test x86_64 Server-boot-iso install_default: 
System load changed from 0.27 to 0.10
Previous test data: https://openqa.fedoraproject.org/tests/228931#downloads
Current test data: https://openqa.fedoraproject.org/tests/229234#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
System load changed from 1.20 to 0.65
Average CPU usage changed from 31.89523810 to 15.15238095
Previous test data: https://openqa.fedoraproject.org/tests/228958#downloads
Current test data: https://openqa.fedoraproject.org/tests/229261#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
System load changed from 0.83 to 0.63
Average CPU usage changed from 34.27619048 to 3.24761905
Previous test data: https://openqa.fedoraproject.org/tests/228960#downloads
Current test data: https://openqa.fedoraproject.org/tests/229263#downloads

Installed system changes in test x86_64 Workstation-boot-iso 
install_default@uefi: 
System load changed from 0.41 to 0.24
Used swap changed from 4 MiB to 7 MiB
Previous test data: https://openqa.fedoraproject.org/tests/228973#downloads
Current test data: https://openqa.fedoraproject.org/tests/229276#downloads

Installed system changes in test i386 Workstation-live-iso install_default: 
System load changed from 0.84 to 0.59
Previous test data: https://openqa.fedoraproject.org/tests/228974#downloads
Current test data: https://openqa.fedoraproject.org/tests/229277#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
Average CPU usage changed from 26.61428571 to 3.88571429
Previous test data: https://openqa.fedoraproject.org/tests/228979#downloads
Current test data: https://openqa.fedoraproject.org/tests/229282#downloads

Installed system changes in test i386 KDE-live-iso install_default: 
System load changed from 1.14 to 1.03
Previous test data: https://openqa.fedoraproject.org/tests/228990#downloads
Current test data: https://openqa.fedoraproject.org/tests/229293#downloads

Installed system changes in test x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.16 to 0.33
Previous test data: https://openqa.fedoraproject.org/tests/228995#downloads
Current test data: https://openqa.fedoraproject.org/tests/229298#downloads

Installed system changes in test x86_64 universal install_package_set_kde: 
System load changed from 0.97 to 0.55
Used mem changed from 913 MiB to 804 MiB
Previous test data: 

[Bug 1571021] perl-String-Compare-ConstantTime-0.320 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-String-Compare-ConstantTime-0.320-1.fc28 has been pushed to the Fedora 28
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-13a62bbfc8

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

[Bug 1570797] perl-Mail-JMAPTalk-0.11 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-Mail-JMAPTalk-0.11-1.fc28 has been pushed to the Fedora 28 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-c0ee451cce

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

Re: Fedora 27 kernel updates make system unbootable (sort of)

[François Cami]

> On Fri, Apr 20, 2018 at 3:32 PM, Lennart Poettering
>  
> OK after a bunch of additional testing, one thing is certain; grubby
> and grub-mkconfig are not even remotely crash safe. They do not
> fsync() or sync() at all. That's not good no matter the file system.

May I point you to https://github.com/rhboot/grubby/pull/24 which *should* fix 
most of that.

https://github.com/rhboot/grubby/pull/28 will fix *all* of that when /boot is a 
separate FS.

> The best near term change that I think we should make is putting a
> sync() somewhere in grubby. I've tested modifying new-kernel-pkg to
> add a sync right before the last line, and
> 
> # dnf update -y /path/to/kernelrpms && echo b > /proc/sysrq-trigger
> 
> With very limited testing (dozens of reboots in multiple fs
> configurations of a VM only, using unsafe caching), all configurations
> including XFS are better off with sync() added. It a highly
> non-deterministic mess to sort out without sync().
> 
> But with sync() and with /boot on XFS: the kernel, initramfs, or
> grub.cfg - there is an unknown (let's say 50/50) probability the
> bootloader can't find or read those files despite the sync(). The most
> common outcome I ran into was a partially modified grub.cfg containing
> an incomplete default entry for the new kernel which is missing the
> grubby insertion for the initrd. So it can't boot. But if the grub
> menu appears at all, the previous kernel and rescue entries are still
> there, and they work. Log replay during boot fixes up everything and
> now the next boot works fine by default without user interaction. So
> even though sync() is still not good enough for XFS always, it's way
> better than no sync().
> 
> Meanwhile FAT, ext2, ext4, and Btrfs all appear to flush to disk with
> sync() sufficient for the bootloader to have no problems.
> 
> Note that fsync() is actually insufficient at least some of the time
> on all journaled file systems. e.g. dracut -f only does fsync() on the
> copied over initramfs to /boot and that new initramfs is often not
> seen by the bootloader for journaled file systems.

Not after 
https://github.com/dracutdevs/dracut/commit/58e3971b920fbb60e5a90edfd30aa887f9818100

> Instead, the
> bootloader sees the old initramfs that had been deleted, which during
> boot (if successful) replays the log and completes the delete of old
> initramfs, and now the new one appears and isused at next boot. Other
> combinations are possible.
> 
> Minor in comparison, I see grubby doing a metric ton of fdatasync() on
> /var/log/grubby -  80 fdatasync() 's for 17 lines and 1.2KiB of
> changes for a single kernel installation. Does that make sense to
> anyone? How about one fdatasync() for all of those changes? Or just
> fsync() the file?
> 
> I think any plan for doing freeze/thaw anywhere can be postponed
> pending further discussion and testing.
> 
> In the meantime I'll come up with a patch for new-kernel-pkg to do a
> sync() unless someone else beats me to it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 27 kernel updates make system unbootable (sort of)

[Lennart Poettering]

On Di, 24.04.18 11:36, Chris Murphy (li...@colorremedies.com) wrote:

> Note that fsync() is actually insufficient at least some of the time
> on all journaled file systems. e.g. dracut -f only does fsync() on the
> copied over initramfs to /boot and that new initramfs is often not
> seen by the bootloader for journaled file systems. Instead, the
> bootloader sees the old initramfs that had been deleted, which during
> boot (if successful) replays the log and completes the delete of old
> initramfs, and now the new one appears and isused at next boot. Other
> combinations are possible.

BTW, just to mention this: by default, if you let systemd mount the
EFI ESP for you then it will do that as automount point, meaning after
a few seconds of not accessing the ESP it will be unmounted
again. This means during normal operation the ESP won't be mounted at
all, and it will only be mounted (and thus potentially be in a dirty
state) for a very short time window around actual accesses, even
though it appears available all the time due to the automount logic.

Quite frankly, I think it would be a good idea, to just drop the
seperate /boot stuff, and simply place the kernel+initrd directly in
the ESP, and let systemd do its automount magic on it. That has the
benefit that the firmware groks the file system as well as our kernel
does, and that we do our best to keep the fs in the cleanest state
possible. In addition it's a much simpler approach, as we just reuse
the stuff already there and don't invent anything complex new.

Lennart

-- 
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

[smooge]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2018-04-25 from 18:00:00 to 19:00:00 GMT
   At fedora-meet...@irc.freenode.net

The meeting will be about:
The EPEL Steering Committee will have a weekly meeting to cover current tasks 
and problems needed to keep EPEL going.


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

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

Re: Fedora 27 kernel updates make system unbootable (sort of)

[Chris Murphy]

On Fri, Apr 20, 2018 at 3:32 PM, Lennart Poettering
 wrote:
> On Fr, 20.04.18 12:20, Chris Murphy (li...@colorremedies.com) wrote:
>
>> I'm honestly mystified why the plymouth commit hasn't been reverted in
>> the interim. But I'm also mystified why the bootloader folks don't
>> give a shit to commit their configuration files to disk when they know
>> they can't do journal replay and have known that for 20 years. But
>> then I'm also mystified why systemd developers won't fallback to
>> freeze/thaw if rootfs remount-ro fails three times, instead of just
>> giving up and forcing a reboot, they did discuss doing this a year ago
>> and then poof, no action.
>
> Quite frankly, if you want to put the blame somewhere, I'd probably
> place it with the xfs folks? I mean, there's a well-defined API on
> linux for syncing a file system to disk so that it is in a clean
> state, it's called sync(). Turns out that doesn't work though, it
> doesn't actually do that.

OK after a bunch of additional testing, one thing is certain; grubby
and grub-mkconfig are not even remotely crash safe. They do not
fsync() or sync() at all. That's not good no matter the file system.

The best near term change that I think we should make is putting a
sync() somewhere in grubby. I've tested modifying new-kernel-pkg to
add a sync right before the last line, and

# dnf update -y /path/to/kernelrpms && echo b > /proc/sysrq-trigger

With very limited testing (dozens of reboots in multiple fs
configurations of a VM only, using unsafe caching), all configurations
including XFS are better off with sync() added. It a highly
non-deterministic mess to sort out without sync().

But with sync() and with /boot on XFS: the kernel, initramfs, or
grub.cfg - there is an unknown (let's say 50/50) probability the
bootloader can't find or read those files despite the sync(). The most
common outcome I ran into was a partially modified grub.cfg containing
an incomplete default entry for the new kernel which is missing the
grubby insertion for the initrd. So it can't boot. But if the grub
menu appears at all, the previous kernel and rescue entries are still
there, and they work. Log replay during boot fixes up everything and
now the next boot works fine by default without user interaction. So
even though sync() is still not good enough for XFS always, it's way
better than no sync().

Meanwhile FAT, ext2, ext4, and Btrfs all appear to flush to disk with
sync() sufficient for the bootloader to have no problems.

Note that fsync() is actually insufficient at least some of the time
on all journaled file systems. e.g. dracut -f only does fsync() on the
copied over initramfs to /boot and that new initramfs is often not
seen by the bootloader for journaled file systems. Instead, the
bootloader sees the old initramfs that had been deleted, which during
boot (if successful) replays the log and completes the delete of old
initramfs, and now the new one appears and isused at next boot. Other
combinations are possible.

Minor in comparison, I see grubby doing a metric ton of fdatasync() on
/var/log/grubby -  80 fdatasync() 's for 17 lines and 1.2KiB of
changes for a single kernel installation. Does that make sense to
anyone? How about one fdatasync() for all of those changes? Or just
fsync() the file?

I think any plan for doing freeze/thaw anywhere can be postponed
pending further discussion and testing.

In the meantime I'll come up with a patch for new-kernel-pkg to do a
sync() unless someone else beats me to it.



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

Fedora 28 compose report: 20180424.n.0 changes

[Fedora Branched Report]

OLD: Fedora-28-20180423.n.0
NEW: Fedora-28-20180424.n.0

= SUMMARY =
Added images:3
Dropped images:  0
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: AtomicHost raw-xz ppc64le
Path: AtomicHost/ppc64le/images/Fedora-AtomicHost-28-20180424.n.0.ppc64le.raw.xz
Image: AtomicHost qcow2 ppc64le
Path: AtomicHost/ppc64le/images/Fedora-AtomicHost-28-20180424.n.0.ppc64le.qcow2
Image: Container_Base docker armhfp
Path: 
Container/armhfp/images/Fedora-Container-Base-28-20180424.n.0.armhfp.tar.xz

= DROPPED IMAGES =

= 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

[Bug 1570441] perl-Dist-Milla-v1.0.20 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Dist-Milla-1.0.20-1.fc
   ||29
 Resolution|--- |RAWHIDE
Last Closed||2018-04-24 10:58:33



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

openCOLLADA soname bump

[Richard Shaw]

openCOLLADA has been built for Fedora as a git checkout since it was first
imported. At some point upstream finally started to maintain an actual
release with version (still no soversion, but that's another story).

I plan to build 1.6.62 in Rawhide and F28 and rebuild Blender with it
(already tested locally) which is the only dependency I could find.

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

[Bug 1542666] perl-Net-OpenSSH package fails to pull in required IO:: Pty module

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 CC||emman...@seyman.fr



--- Comment #10 from Emmanuel Seyman  ---
I think Paul correctly summed up the problem in comment #4.

Net::OpenSSH doesn't require perl(IO::Pty) except when called in the
libvirt-tck package.

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

[Bug 1570441] perl-Dist-Milla-v1.0.20 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1570441
Bug 1570441 depends on bug 1571122, which changed state.

Bug 1571122 Summary: Review Request: perl-Dist-Zilla-Plugin-StaticInstall - 
Identify a distribution as eligible for static installation
https://bugzilla.redhat.com/show_bug.cgi?id=1571122

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution|--- |RAWHIDE



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

Re: OpenCOLLADA build error

[Richard Shaw]

That got it, Thanks!

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

Re: [Guidelines change] Changes to the packaging guidelines

[Miro Hrončok]

On 24.4.2018 15:32, Miro Hrončok wrote:

On 23.4.2018 21:37, Mátyás Selmeci wrote:

On 04/23/2018 01:06 PM, Jason L Tibbitts III wrote:

The Python guidelines now more clearly indicate that use of %{__python},
%{python_sitelib} and %{python_sitearch} is forbidden.

  * https://fedoraproject.org/wiki/Packaging:Python#Macros
  * https://pagure.io/packaging-committee/issue/745



The EPEL guidelines for Python [1] still recommend these for EPEL6 
instead of %{python2_sitelib}, etc.  Is that still the case, or should 
those guidelines be updated?


AFAIK all of those macros are available in EPEL6. Will check and open an 
issue at http://pagure.io/packaging-committee/


Indeed. https://pagure.io/packaging-committee/issue/765

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

Re: [Guidelines change] Changes to the packaging guidelines

[Miro Hrončok]

On 23.4.2018 21:37, Mátyás Selmeci wrote:

On 04/23/2018 01:06 PM, Jason L Tibbitts III wrote:

The Python guidelines now more clearly indicate that use of %{__python},
%{python_sitelib} and %{python_sitearch} is forbidden.

  * https://fedoraproject.org/wiki/Packaging:Python#Macros
  * https://pagure.io/packaging-committee/issue/745



The EPEL guidelines for Python [1] still recommend these for EPEL6 
instead of %{python2_sitelib}, etc.  Is that still the case, or should 
those guidelines be updated?


AFAIK all of those macros are available in EPEL6. Will check and open an 
issue at http://pagure.io/packaging-committee/



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

[Bug 1571273] perl-Tie-Handle-Offset-0.004 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Tie-Handle-Offset-0.00
   ||4-1.fc29
 Resolution|--- |RAWHIDE
Last Closed||2018-04-24 09:13:05



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

[Bug 1571273] New: perl-Tie-Handle-Offset-0.004 is available

[bugzilla]

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

Bug ID: 1571273
   Summary: perl-Tie-Handle-Offset-0.004 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Tie-Handle-Offset
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 0.004
Current version/release in rawhide: 0.003-7.fc28
URL: http://search.cpan.org/dist/Tie-Handle-Offset/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/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/8356/

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

[Bug 1571270] New: perl-Test-Deep-JSON-0.05 is available

[bugzilla]

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

Bug ID: 1571270
   Summary: perl-Test-Deep-JSON-0.05 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Test-Deep-JSON
  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



Latest upstream release: 0.05
Current version/release in rawhide: 0.04-2.fc28
URL: http://search.cpan.org/dist/Test-Deep-JSON/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/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/12565/

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

Re: Contributing docs for maintaining and creating a Fedora remix

[Aidan Kahrs]

I as unaware. Guess that is what this review is for. I will update the
playbook and docs.

On Tue, Apr 24, 2018, 7:39 AM Neal Gompa  wrote:

> On Tue, Apr 24, 2018 at 7:19 AM, Aidan Kahrs  wrote:
> > Neal,
> > Bex is correct that the download server with the RPM repo and ISOs is a
> > separate machine from the machine used to build the RPMs and ISOs. The
> build
> > machine runs the latest version of Fedora and the download server runs
> > CentOS to give a measure of LTS support while still staying within the
> RHEL
> > family.
> > The download server could feasibly run any distribution.
> > Hope this clarifies.
> >
>
> I'd still recommend not suggesting the usage of the legacy createrepo
> (though I don't know why we haven't just made createrepo_c replace it
> already...). The older createrepo has known issues with how it
> generates metadata. createrepo_c is available via EPEL, so you can use
> it with EL6 or EL7. And of course, it's available on Mageia 6 and
> later and openSUSE Leap 42.2 and later.
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Contributing docs for maintaining and creating a Fedora remix

[Neal Gompa]

On Tue, Apr 24, 2018 at 7:19 AM, Aidan Kahrs  wrote:
> Neal,
> Bex is correct that the download server with the RPM repo and ISOs is a
> separate machine from the machine used to build the RPMs and ISOs. The build
> machine runs the latest version of Fedora and the download server runs
> CentOS to give a measure of LTS support while still staying within the RHEL
> family.
> The download server could feasibly run any distribution.
> Hope this clarifies.
>

I'd still recommend not suggesting the usage of the legacy createrepo
(though I don't know why we haven't just made createrepo_c replace it
already...). The older createrepo has known issues with how it
generates metadata. createrepo_c is available via EPEL, so you can use
it with EL6 or EL7. And of course, it's available on Mageia 6 and
later and openSUSE Leap 42.2 and later.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fwd: Contributing docs for maintaining and creating a Fedora remix

[Aidan Kahrs]

Forwarding here now that I am subscribed so that context is there.
-- Forwarded message -
From: Aidan Kahrs 
Date: Tue, Apr 24, 2018, 7:18 AM
Subject: Re: Contributing docs for maintaining and creating a Fedora remix
To: Neal Gompa 
Cc: Development discussions related to Fedora ,
For participants of the Documentation Project ,
tige...@ritlug.com 


Neal,
Bex is correct that the download server with the RPM repo and ISOs is a
separate machine from the machine used to build the RPMs and ISOs. The
build machine runs the latest version of Fedora and the download server
runs CentOS to give a measure of LTS support while still staying within the
RHEL family.
The download server could feasibly run any distribution.
Hope this clarifies.

Thank you.
Sincerely,
Aidan Kahrs
abka...@fedoraproject.org

On Tue, Apr 24, 2018, 5:20 AM Neal Gompa  wrote:

> On Tue, Apr 24, 2018 at 5:03 AM, Brian (bex) Exelbierd
>  wrote:
> > +devel list to attract feedback from other folks in releng or working on
> > other remixes and spins
> >
> > On Mon, Apr 23, 2018 at 7:04 PM, Aidan Kahrs  wrote:
> >>
> >> Hello.
> >> I know this thread has been kinda quiet the last few days. I wanted to
> put
> >> out an update that the draft documentation is finished. I have gotten
> input
> >> from my team. I would now like input from people within the docs effort
> >> before I say it is ready to publish.
> >>
> >> The draft docs can be found at
> >>
> https://pagure.io/fedora-docs/remix-building/blob/master/f/remix-ci.adoc
> >
> >
> > One comment:
> >
> > 14: Why is this server required to be a CentOS server?  I have no problem
> > with CentOS but we should explain that choice in the context of a Fedora
> > Remix.
> >
>
> My experience is that it _should not_ be anything but a Fedora system.
> It should be at least be the target Fedora version or higher. Ideally,
> you always run the target version's livemedia-creator+Anaconda, which
> is why Koji uses mock to set up the environment and then run it inside
> of there.
>
> In addition, it's a very bad idea to recommend using "createrepo"
> instead of "createrepo_c", due to the former not supporting most of
> Fedora's newer RPM features and potentially weird things happening
> there.
>
> If you're using livecd-creator, you can get away with a lot more,
> since you're no longer sensitive to Anaconda's fragilities and the
> build engine is DNF.
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenCOLLADA build error

[Petr Pisar]

On 2018-04-20, Richard Shaw  wrote:
>
> I'm getting the following error when I build with mock in both f27 and
> rawhide:
>
> BUILDSTDERR: In file included from
> /builddir/build/BUILD/OpenCOLLADA-1.6.62/COLLADABaseUtils/src/COLLADABUURI.cpp:18:
> BUILDSTDERR: /usr/include/pcre.h:325:33: error: conflicting declaration
> 'typedef struct real_pcre8_or_16 pcre'
> BUILDSTDERR:  typedef struct real_pcre8_or_16 pcre;
> BUILDSTDERR:  ^~~~
> BUILDSTDERR: In file included from
> /builddir/build/BUILD/OpenCOLLADA-1.6.62/COLLADABaseUtils/src/COLLADABUURI.cpp:14:
> BUILDSTDERR:
> /builddir/build/BUILD/OpenCOLLADA-1.6.62/COLLADABaseUtils/include/COLLADABUPcreCompiledPattern.h:17:26:
> note: previous declaration as 'typedef struct real_pcre pcre'
> BUILDSTDERR:  typedef struct real_pcre pcre;
> BUILDSTDERR:   ^~~~
>
> I do not get this error doing a local build on my f27 desktop...
>
This is change in pcre-8.42-RC1 that fixed out-dated typedefs:

-struct real_pcre; /* declaration; the definition is private  */
-typedef struct real_pcre pcre;
+struct real_pcre8_or_16;  /* declaration; the definition is private  */
+typedef struct real_pcre8_or_16 pcre;

-struct real_pcre16;   /* declaration; the definition is private  */
-typedef struct real_pcre16 pcre16;
+struct real_pcre8_or_16;  /* declaration; the definition is private  */
+typedef struct real_pcre8_or_16 pcre16;

Your code COLLADABaseUtils/include/COLLADABUPcreCompiledPattern.h:17
redefines them:

struct real_pcre;
typedef struct real_pcre pcre;

OpenCOLLADA should remove the redifinitions.

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

[Bug 1542666] perl-Net-OpenSSH package fails to pull in required IO:: Pty module

[bugzilla]

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

Steve Traylen  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution|--- |NEXTRELEASE
Last Closed||2018-04-24 06:06:56



--- Comment #9 from Steve Traylen  ---
Oh 
Suggests:   perl(IO::Pty)

has already been added.

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

[Bug 1542666] perl-Net-OpenSSH package fails to pull in required IO:: Pty module

[bugzilla]

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

Steve Traylen  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Comment #8 from Steve Traylen  ---
Adding 'perl(IO::Pty)' to the requires is fine. 

It's a tiny dep at the end of the day.

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

Re: Contributing docs for maintaining and creating a Fedora remix

[Brian (bex) Exelbierd]

On Tue, Apr 24, 2018 at 11:19 AM, Neal Gompa  wrote:

> On Tue, Apr 24, 2018 at 5:03 AM, Brian (bex) Exelbierd
>  wrote:
> > +devel list to attract feedback from other folks in releng or working on
> > other remixes and spins
> >
> > On Mon, Apr 23, 2018 at 7:04 PM, Aidan Kahrs  wrote:
> >>
> >> Hello.
> >> I know this thread has been kinda quiet the last few days. I wanted to
> put
> >> out an update that the draft documentation is finished. I have gotten
> input
> >> from my team. I would now like input from people within the docs effort
> >> before I say it is ready to publish.
> >>
> >> The draft docs can be found at
> >> https://pagure.io/fedora-docs/remix-building/blob/master/f/
> remix-ci.adoc
> >
> >
> > One comment:
> >
> > 14: Why is this server required to be a CentOS server?  I have no problem
> > with CentOS but we should explain that choice in the context of a Fedora
> > Remix.
> >
>
> My experience is that it _should not_ be anything but a Fedora system.
> It should be at least be the target Fedora version or higher. Ideally,
> you always run the target version's livemedia-creator+Anaconda, which
> is why Koji uses mock to set up the environment and then run it inside
> of there.
>
> In addition, it's a very bad idea to recommend using "createrepo"
> instead of "createrepo_c", due to the former not supporting most of
> Fedora's newer RPM features and potentially weird things happening
> there.
>
> If you're using livecd-creator, you can get away with a lot more,
> since you're no longer sensitive to Anaconda's fragilities and the
> build engine is DNF.
>

I believe we may be talking about different servers.  The page seems to
indicate the CentOS server is used to serve the bits.

regards,

bex



>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 
Brian (bex) Exelbierd | bexel...@redhat.com | b...@pobox.com
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1571021] perl-String-Compare-ConstantTime-0.320 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-String-Compare-ConstantTime-0.320-1.fc26 has been submitted as an update
to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-36f63a6c48

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

[Bug 1571021] perl-String-Compare-ConstantTime-0.320 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-String-Compare-ConstantTime-0.320-1.fc27 has been submitted as an update
to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-15938dad7c

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

[Bug 1571021] perl-String-Compare-ConstantTime-0.320 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-String-Compare-ConstantTime-0.320-1.fc28 has been submitted as an update
to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-13a62bbfc8

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

Re: Contributing docs for maintaining and creating a Fedora remix

[Neal Gompa]

On Tue, Apr 24, 2018 at 5:03 AM, Brian (bex) Exelbierd
 wrote:
> +devel list to attract feedback from other folks in releng or working on
> other remixes and spins
>
> On Mon, Apr 23, 2018 at 7:04 PM, Aidan Kahrs  wrote:
>>
>> Hello.
>> I know this thread has been kinda quiet the last few days. I wanted to put
>> out an update that the draft documentation is finished. I have gotten input
>> from my team. I would now like input from people within the docs effort
>> before I say it is ready to publish.
>>
>> The draft docs can be found at
>> https://pagure.io/fedora-docs/remix-building/blob/master/f/remix-ci.adoc
>
>
> One comment:
>
> 14: Why is this server required to be a CentOS server?  I have no problem
> with CentOS but we should explain that choice in the context of a Fedora
> Remix.
>

My experience is that it _should not_ be anything but a Fedora system.
It should be at least be the target Fedora version or higher. Ideally,
you always run the target version's livemedia-creator+Anaconda, which
is why Koji uses mock to set up the environment and then run it inside
of there.

In addition, it's a very bad idea to recommend using "createrepo"
instead of "createrepo_c", due to the former not supporting most of
Fedora's newer RPM features and potentially weird things happening
there.

If you're using livecd-creator, you can get away with a lot more,
since you're no longer sensitive to Anaconda's fragilities and the
build engine is DNF.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1571021] perl-String-Compare-ConstantTime-0.320 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-String-Compare-Constan
   ||tTime-0.320-1.fc29



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.

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

Re: Contributing docs for maintaining and creating a Fedora remix

[Brian (bex) Exelbierd]

+devel list to attract feedback from other folks in releng or working on
other remixes and spins

On Mon, Apr 23, 2018 at 7:04 PM, Aidan Kahrs  wrote:

> Hello.
> I know this thread has been kinda quiet the last few days. I wanted to put
> out an update that the draft documentation is finished. I have gotten input
> from my team. I would now like input from people within the docs effort
> before I say it is ready to publish.
>
> The draft docs can be found at https://pagure.io/fedora-docs/
> remix-building/blob/master/f/remix-ci.adoc
>

One comment:

14: Why is this server required to be a CentOS server?  I have no problem
with CentOS but we should explain that choice in the context of a Fedora
Remix.

The rest reads fine.  I hope other releng/remix/spin folks will comment on
the technical details.

regards,

bex


> DocGist was misbehaving so I was unable to get a rendered preview.
>
> Please let me know what you think.
>
> Thank you.
> Sincerely,
>
> Aidan Kahrs
> abka...@fedoraproject.org
>
>
> ___
> docs mailing list -- d...@lists.fedoraproject.org
> To unsubscribe send an email to docs-le...@lists.fedoraproject.org
>
>


-- 
Brian (bex) Exelbierd | bexel...@redhat.com | b...@pobox.com
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1570874] Installing perl-PAR-Packer causes perl DOWNGRADE

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-PAR-Packer-1.036-7.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-7f5db64fb6

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

[Bug 1570874] Installing perl-PAR-Packer causes perl DOWNGRADE

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-PAR-Packer-1.041-2.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-d5693ce353

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

[Bug 1570874] Installing perl-PAR-Packer causes perl DOWNGRADE

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   See Also||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=1470542



--- Comment #1 from Jitka Plesnikova  ---
I'll rebuild the package with newer Perl.

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

[Bug 1470542] PAR:: Packer requires the same perl version it was built against

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

   See Also||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=1570874



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

[Bug 1570797] perl-Mail-JMAPTalk-0.11 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-Mail-JMAPTalk-0.11-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-ccb471a200

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

[Bug 1570797] perl-Mail-JMAPTalk-0.11 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-Mail-JMAPTalk-0.11-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-904d336f60

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

[Bug 1570797] perl-Mail-JMAPTalk-0.11 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Mail-JMAPTalk-0.11-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-c0ee451cce

-- 
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-Atomic 27-20180424.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 2/2 (x86_64)
-- 
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

[Bug 1570797] perl-Mail-JMAPTalk-0.11 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Mail-JMAPTalk-0.11-1.f
   ||c29



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for all Fedoras.

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

[Bug 1570441] perl-Dist-Milla-v1.0.20 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Depends On||1571122




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1571122
[Bug 1571122] Review Request: perl-Dist-Zilla-Plugin-StaticInstall -
Identify a distribution as eligible for static installation
-- 
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

[Bug 1570441] perl-Dist-Milla-v1.0.20 is available

[bugzilla]

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



--- Comment #1 from Petr Pisar  ---
This requires not yet packaged Dist::Zilla::Plugin::StaticInstall. Suitable for
Rawhide only.

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