date:20170823

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

Fedora Update System  changed:

   What|Removed |Added

 Status|CLOSED  |ON_QA
 Resolution|ERRATA  |---
   Keywords||Reopened



--- Comment #16 from Fedora Update System  ---
perl-Text-Fuzzy-0.27-1.fc25 has been pushed to the Fedora 25 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-2017-76a36d95cf

-- 
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 1481915] perl-Text-Fuzzy-0.27 is available

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



--- Comment #7 from Fedora Update System  ---
perl-Text-Fuzzy-0.27-1.fc25 has been pushed to the Fedora 25 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-2017-76a36d95cf

-- 
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 1481915] perl-Text-Fuzzy-0.27 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #6 from Fedora Update System  ---
perl-Text-Fuzzy-0.27-1.fc26 has been pushed to the Fedora 26 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-2017-4fc72f83be

-- 
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: No i686 build of grub2?

2017-08-23 Thread Kevin Kofler

Peter Jones wrote:
> It is still built as grub2-pc{,-modules}, just built a bit differently.

It is not. There is no grub2-pc in dist-git, and grub2 has this ExcludeArch:
http://pkgs.fedoraproject.org/rpms/grub2/blob/master/f/grub2.spec#_57

It is not enough to build the 32-bit PC/BIOS grub2 on x86_64, it has to be 
built on i686 too to be in the i686 repo.

Ideally, you would also support the 32-bit UEFI and even 64-bit UEFI 
binaries on the i686 distro, but at the very least, the BIOS version that 
was always there needs to be built again.

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

Re: [modularity] Modularizing the world fast and iteratively

2017-08-23 Thread Kevin Kofler

Adam Samalik wrote:
> all their dependencies, we need to build them. But, for example, a pretty
> commonly needed thing like autotools [3] has pretty crazy build
> dependencies [4] including Java, gtk2, gtk3, erlang, X11, python2,
> python3, etc.

This is exactly why the separate Core and Extras were such a PITA and why 
the Core-Extras Merge was done. Doing the opposite now is a BAD idea.

Modularity may sound great on paper, but as soon as you actually try to 
implement it, it falls apart like a house of cards.

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

Re: Platform Python changes and python3dist tags

2017-08-23 Thread Scott Talbert


On Tue, 22 Aug 2017, Scott Talbert wrote:


Hi,

I was just trying to build a new package in Rawhide that built fine a few 
days ago.  The failure seems to be occurring because the python3 
setuptools_scm module isn't being found.  I'm using the new pythonXdist 
tags:


BuildRequires:  %{py2_dist py pytest setuptools_scm}
BuildRequires:  %{py3_dist py pytest setuptools_scm}

It seems this is causing several of the recently added platform-python
packages to be pulled in:
Installing:
platform-python-pytestnoarch3.2.1-2.fc28   fedora 438 
k

platform-python-setuptools_scmnoarch1.15.6-4.fc28  fedora 36 k

Both the python3-setuptools_scm and platform-python-setuptools_scm packages 
have the python3dist tag:


$ rpm -q --provides -p 
platform-python-setuptools_scm-1.15.6-4.fc28.noarch.rpm
warning: platform-python-setuptools_scm-1.15.6-4.fc28.noarch.rpm: Header V3 
RSA/SHA256 Signature, key ID 9db62fb1: NOKEY

platform-python-setuptools_scm = 1.15.6-4.fc28
python3.6dist(setuptools-scm) = 1.15.6
python3dist(setuptools-scm) = 1.15.6

$ rpm -q --provides -p python3-setuptools_scm-1.15.6-4.fc28.noarch.rpm
warning: python3-setuptools_scm-1.15.6-4.fc28.noarch.rpm: Header V3 
RSA/SHA256 Signature, key ID 9db62fb1: NOKEY

python3-setuptools_scm = 1.15.6-4.fc28
python3.6dist(setuptools-scm) = 1.15.6
python3dist(setuptools-scm) = 1.15.6
[swt2c@rawhide-test ~][PROD]$

It seems that probably the platform-python packages shouldn't have these 
tags?


I'm hearing a lot of crickets.

I filed https://bugzilla.redhat.com/show_bug.cgi?id=1484607 against rpm as 
I didn't see any obvious way for the platform-python packages to exclude 
themselves from the python3dist provides.


I'm just going to stop using the py3_dist stuff for now.

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

Re: ImageMagick Unresponsive Maintainer process - hubbitus (Pavel Alexeev)

2017-08-23 Thread Moez Roy

On Mon, Jul 31, 2017 at 12:13 PM, Kevin Fenzi  wrote:

> ok, I rebuilt the following ones. The ones with F next to them failed to
> build:
>
>   autotrace-0.31.1-44.fc26.src.rpm
>   converseen-0.9.6.2-1.fc27.src.rpm
>   dmtx-utils-0.7.4-2.fc27.src.rpm
>   drawtiming-0.7.1-20.fc26.src.rpm
> F gtatool-2.2.0-4.fc27.src.rpm
>   imageinfo-0.05-25.fc26.src.rpm
>   inkscape-0.92.1-5.20170510bzr15686.fc27.src.rpm
>   kxstitch-1.2.0-7.fc26.src.rpm
>   perl-Image-SubImageFind-0.03-11.fc27.src.rpm
>   pfstools-2.0.6-1.fc27.src.rpm
> F php-magickwand-1.0.9.2-9.fc24.src.rpm
> F php-pecl-imagick-3.4.3-0.3.RC1.fc26.src.rpm
>   psiconv-0.9.8-20.fc26.src.rpm
>   q-7.11-27.fc27.src.rpm
>   ripright-0.11-3.fc26.src.rpm
>   rss-glx-0.9.1.p-29.fc26.src.rpm
> F rubygem-rmagick-2.16.0-3.fc26.src.rpm
> F synfig-1.2.0-5.fc27.src.rpm
>   (boost issues)
> F synfigstudio-1.1.10-0.20160706gitd4e547.fc25.src.rpm
>   (needs synfig)
>   vdr-scraper2vdr-1.0.5-2.20170611git254122b.fc27.src.rpm
>   vips-8.5.6-1.fc27.src.rpm
>   WindowMaker-0.95.8-1.fc27.src.rpm
> F cuneiform
>   (some c++ blowup)
>   k3d
>
> With that I think rawhide should be back on track.
>
> If all looks well for a bit I guess I can try and do f25/f26.
>
> kevin
>
>
>
>

The soname bump requires packages that depend on it need to be rebuilt, so
I updated ImageMagick to 7.0.6-9.

I tagged this update now  for Updates Testing for f25 & f26 as it is an
urgent fix.

It is also in build root override so affected packages can now be rebuilt.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1484602] New: perl-Test-Trap-v0.3.3 is available

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

Bug ID: 1484602
   Summary: perl-Test-Trap-v0.3.3 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Test-Trap
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, lkund...@v3.sk,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: v0.3.3
Current version/release in rawhide: 0.3.2-8.fc27
URL: http://search.cpan.org/dist/Test-Trap/

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

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

Self Introduction: Charlie Sale

2017-08-23 Thread Charlie Sale

Hello Fedora Community!

My name is Charlie Sale and I am an amateur C and C++ developer. I've been
programming for about 4 years now and have produced a variety of projects.
I am now releasing my first large-scale distributed project on the Fedora
project. I have submitted my package review at
https://bugzilla.redhat.com/show_bug.cgi?id=1484164 . Please give me a
shot. I very involved in my project and intend to maintain it with
diligence. I am also in need of a sponsor, so if you are interested, please
help me out.

I am looking forward to joining the package maintainer's community.

Regards,

Charlie
-- 

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

Fedora Rawhide-20170823.n.0 compose check report

2017-08-23 Thread Fedora compose checker

Missing expected images:

Server dvd i386
Workstation live i386
Server boot i386
Kde live i386

Failed openQA tests: 32/137 (x86_64), 1/2 (arm)

New failures (same test did not fail in Rawhide-20170822.n.0):

ID: 133549  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/133549
ID: 133551  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/133551
ID: 133555  Test: x86_64 Workstation-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/133555
ID: 133556  Test: x86_64 Workstation-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/133556
ID: 133557  Test: x86_64 Workstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/133557
ID: 133569  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/133569
ID: 133621  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/133621

Old failures (same test failed in Rawhide-20170822.n.0):

ID: 133502  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/133502
ID: 133509  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/133509
ID: 133511  Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/133511
ID: 133515  Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/133515
ID: 133523  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/133523
ID: 133525  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/133525
ID: 133542  Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/133542
ID: 133546  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/133546
ID: 133550  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/133550
ID: 133566  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/133566
ID: 133567  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/133567
ID: 133568  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/133568
ID: 133570  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/133570
ID: 133571  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/133571
ID: 133572  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/133572
ID: 133573  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/133573
ID: 133574  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/133574
ID: 133575  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/133575
ID: 133576  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/133576
ID: 133578  Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/133578
ID: 133579  Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/133579
ID: 133584  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/133584
ID: 133633  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/133633
ID: 133634  Test: x86_64 universal install_rescue_encrypted
URL: https://openqa.fedoraproject.org/tests/133634
ID: 133635  Test: x86_64 universal install_rescue_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/133635
ID: 133723  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/133723

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

New soft failures (same test did not soft fail in Rawhide-20170822.n.0):

ID: 133521  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/133521
ID: 133538  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/133538
ID: 133539  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/133539

Old soft failures (same test soft failed in Rawhide-20170822.n.0):

ID: 133585  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/133585
ID: 133717  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/133717

Passed

Re: introducing fed-install: easy way to install packages from koji and other releases

2017-08-23 Thread Kevin Fenzi

On 08/23/2017 01:17 AM, Tomas Tomecek wrote:
> 
> 
> On Sun, Aug 20, 2017 at 10:59 PM, Kevin Fenzi  > wrote:
> 
> 
> First, one thing that would be very handy (but could perhaps just be a
> dnf plugin) is to install from koji, but use signed packages (if
> available). I'm not sure how hard it would be to implement in your tool,
> but you might take a look if you are interested.
> 
> 
> What would be the place to pick the signed packages from?

If there is a written out signed rpm you can find it at (for example):

https://kojipkgs.fedoraproject.org/packages/fedrepo-req/1.5.0/2.fc28/data/signed/9db62fb1/noarch/fedrepo-req-1.5.0-2.fc28.noarch.rpm

These are culled when they are no longer tagged into active release
tags, but if they are recent enough there should be a written out signed
rpm.

> I think this is a great suggestion. The reason it's implemented like
> this is because I had no idea where to get those signed packages.

koji download-build also has a option to download signed packages:

  --key=KEY Download rpms signed with the given key


> Secondly, I think this could indeed be handy for folks running rawhide
> or branched, but I worry about people on stable releases mistakenly
> using it and upgrading a chunk of their install to rawhide when they
> didn't realize it would do that. Not sure how to prevent that though,
> perhaps a warning in some cases?
> 
> 
> I like this suggestion. I opened an upstream issue for that:
> 
> https://github.com/TomasTomecek/fed-install/issues/3

Thanks!

kevin




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

Self Introduction: Richard Kellner

2017-08-23 Thread Richard Kellner

Hello everyone,

my name is Richard Kellner and I am a Python developer. In my free time, I
am also a PyCon SK volunteer. Recently I have got this crazy idea to submit
some of my packages to Fedora, so here I am. I have just submitted my first
package for review: https://bugzilla.redhat.com/show_bug.cgi?id=1484561
hopefully several more will come soon.

Looking forward to becoming part of the Fedora community.

Regards,

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

Re: [modularity] Modules and AppStream

2017-08-23 Thread Owen Taylor

On Wed, 2017-08-23 at 17:25 +0100, Richard Hughes wrote:
> On 23 August 2017 at 13:57, Marius Vollmer  wrote:
> > In a modular repository, I think the same thing should happen so that
> > GNOME Software can present interesting modules to the user in a nice
> > way.
> 
> What kind of modules would be shown in gnome-software? Are
> applications like Firefox going to be supported in the new modularity
> system? We're not going to be showing httpd there for instance.

The current expectation is that the only way that modules are going to
show up in GNOME Software is when they are safely wrapped up as a Flatpak.
Because un-encapsulated modules can't be arbitrarily mixed and combined,
displaying them to users would add a huge amount of complexity.

> >  - Metainfo is in packages, but we need to be installing modules.
> 
> How are we going to be installing modules in a modular-system?
> PackageKit is only going to be able to install packages so
> gnome-software will obviously need to be able to install things.

Via flatpak, not via PackageKit. :-)

> >  Thus,
> >the collection data needs to have module names into the AppStream
> > tag.
> 
> I think the pkgname tag needs to contain the package name. We have a
>  tag that might be more suitable for adding things like
> version or stream information.

yeah, the appstream provided via registry.fedoraproject.org  will have what to
install in the  tag.

> >  I propose to keep AppStream metainfo data in
> >packages, and map from package names to module names during
> >construction of the collection data.
> 
> Can you elaborate a bit? At the moment in Fedora we generate the
> AppStream metadata from a mirror of all the packages using
> appstream-builder.

appstream for modules is something that Marius is going to have to 
eloborate on :-) For the desktop, the appstream data will be collected
from the Flatpaks uploaded to registry.fedoraproject.org and made available
for download.

> >  - Because of streams and profiles, there can be multiple versions of
> >metainfo for a given AppStream component id.  These need to be
> >merged
> 
> No, I don't think they do. If you have two very different versions of
> Firefox (one LTS, one bleeding edge) you want a different description,
> different screenshots and different reviews.
> 
> The way we've solved this in Flatpak is to use a different application
> ID, for instance Firefox nightly would be
> org.mozilla.Firefox.Nightly.desktop rather than
> org.mozilla.Firefox.desktop
> 
> I don't think you can pretend that applications from different
> branches (with different features, bugs and possibly UI) are the
> "same" component, especially when you can install zero, one or many at
> the same time.

The Flatpak build tooling currently enforces that the branch is the same
as the module stream, but allows the packager to use different IDs for
different streams if they want - so they can have a nightly and a stable
stream that can be parallel installed as above. (With caveats of needing
to modify application code appropriately.)

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

ppisar pushed to perl-Module-Install (master). "Upgrade to Fedora Rawhide"

From 3aacaa49758092830f30e5b27c0917e30357b5bf Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Aug 23 2017 15:37:07 +
Subject: Upgrade to Fedora Rawhide


---

diff --git a/perl-Module-Install.yaml b/perl-Module-Install.yaml
index de87cff..29c381b 100644
--- a/perl-Module-Install.yaml
+++ b/perl-Module-Install.yaml
@@ -11,46 +11,55 @@ data:
 module: [ MIT ]
 dependencies:
 buildrequires:
-base-runtime: master
+platform: master
 perl: master
 perl-Module-Install-bootstrap: master
+# Explicitly require transitive dependencies to work around
+# .
+host: master
 requires:
 perl: master
 references:
 community: https://fedoraproject.org/wiki/Modularity
 documentation: 
https://fedoraproject.org/wiki/Fedora_Packaging_Guidelines_for_Modules
+profiles:
+default:
+description: Module::Install Perl module.
+rpms:
+- perl-Module-Install
+tests:
+description: Author and Extra tests.
+rpms:
+- perl-Module-Install-AuthorTests
+- perl-Module-Install-ExtraTests
 api:
 rpms:
 - perl-Module-Install
 - perl-Module-Install-AuthorTests
 - perl-Module-Install-ExtraTests
-filter:
+buildopts:
 rpms:
-# This is provided by MBR, we do not need any different content
-# there, not providing it will preserve MBR's NEVRA and that's
-# good for dependend modules.
-- perl-srpm-macros
+macros: |
+%_without_perl_Module_Runtime_enables_optional_test 1
+%_without_perl_Module_ScanDeps_enables_prefork 1
+%_without_perl_YAML_Tiny_enables_JSON_MaybeX_test 1
 components:
 rpms:
-perl-srpm-macros:
-rationale: Build dependency.
-ref: dab4d381e4a515018e089413f8742a6fe004b356
-buildorder: -1
 perl-File-Remove:
 rationale: Run-time dependency.
-ref: f26
+ref: master
 perl-Module-Install:
 rationale: The API.
-ref: f26
+ref: master
 perl-Module-Install-AuthorTests:
 rationale: The API.
-ref: f26
+ref: master
 perl-Module-Install-ExtraTests:
 rationale: The API.
-ref: f26
+ref: master
 perl-Module-ScanDeps:
 rationale: Run-time dependency.
-ref: f26
+ref: master
 perl-YAML-Tiny:
 rationale: Run-time dependency.
-ref: f26
+ref: master



https://src.fedoraproject.org/modules/perl-Module-Install/c/3aacaa49758092830f30e5b27c0917e30357b5bf?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pghmcfc pushed to perl-MailTools (f27). "Update to 2.19, drop EL-5 support (..more)"

From 80b56f0826fa49a1094ce1d1eea8aae408275bfc Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Aug 23 2017 15:16:11 +
Subject: Update to 2.19, drop EL-5 support


- New upstream release 2.19
  - Block namespace MailTools (CPAN RT#120905)
- Add "ancient" to %summary and %description
- Drop EL-5 support
  - Drop BuildRoot: and Group: tags
  - Drop explicit buildroot cleaning in %install section
  - Drop explicit %clean section

---

diff --git a/perl-MailTools.spec b/perl-MailTools.spec
index 672f41f..4f9a8af 100644
--- a/perl-MailTools.spec
+++ b/perl-MailTools.spec
@@ -1,19 +1,17 @@
-Summary:   Various mail-related perl modules
+Summary:   Various ancient mail-related perl modules
 Name:  perl-MailTools
-Version:   2.18
-Release:   5%{?dist}
+Version:   2.19
+Release:   1%{?dist}
 License:   GPL+ or Artistic
-Group: Development/Libraries
 URL:   http://search.cpan.org/dist/MailTools/
 Source0:   
http://search.cpan.org/CPAN/authors/id/M/MA/MARKOV/MailTools-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
 BuildArch: noarch
 # Module Build
 BuildRequires: coreutils
 BuildRequires: findutils
 BuildRequires: make
-BuildRequires: perl-interpreter >= 3:5.8.1
 BuildRequires: perl-generators
+BuildRequires: perl-interpreter
 BuildRequires: perl(ExtUtils::MakeMaker)
 BuildRequires: sed
 # Module Runtime
@@ -42,7 +40,7 @@ Requires: perl(Net::Domain) >= 1.05
 Requires:  perl(Net::NNTP)
 
 %description
-MailTools is a set of Perl modules related to mail applications.
+MailTools is a set of ancient Perl modules related to mail applications.
 
 %prep
 %setup -q -n MailTools-%{version}
@@ -63,18 +61,14 @@ perl Makefile.PL INSTALLDIRS=vendor
 make %{?_smp_mflags}
 
 %install
-rm -rf %{buildroot}
 make pure_install DESTDIR=%{buildroot}
 find %{buildroot} -type f -name .packlist -delete
-%{_fixperms} %{buildroot}
+%{_fixperms} -c %{buildroot}
 
 %check
 make test
 make test TEST_FILES="xt/*.t"
 
-%clean
-rm -rf %{buildroot}
-
 %files
 %doc ChangeLog README* examples/
 %dir %{perl_vendorlib}/Mail/
@@ -92,6 +86,7 @@ rm -rf %{buildroot}
 %doc %{perl_vendorlib}/Mail/Mailer.pod
 %doc %{perl_vendorlib}/Mail/Send.pod
 %doc %{perl_vendorlib}/Mail/Util.pod
+%doc %{perl_vendorlib}/MailTools.pod
 %{perl_vendorlib}/Mail/Address.pm
 %{perl_vendorlib}/Mail/Cap.pm
 %{perl_vendorlib}/Mail/Filter.pm
@@ -110,6 +105,7 @@ rm -rf %{buildroot}
 %{perl_vendorlib}/Mail/Mailer/smtp.pm
 %{perl_vendorlib}/Mail/Mailer/smtps.pm
 %{perl_vendorlib}/Mail/Mailer/testfile.pm
+%{perl_vendorlib}/MailTools.pm
 %{_mandir}/man3/Mail::Address.3*
 %{_mandir}/man3/Mail::Cap.3*
 %{_mandir}/man3/Mail::Field.3*
@@ -122,8 +118,18 @@ rm -rf %{buildroot}
 %{_mandir}/man3/Mail::Mailer.3*
 %{_mandir}/man3/Mail::Send.3*
 %{_mandir}/man3/Mail::Util.3*
+%{_mandir}/man3/MailTools.3*
 
 %changelog
+* Wed Aug 23 2017 Paul Howarth  - 2.19-1
+- Update to 2.19
+  - Block namespace MailTools (CPAN RT#120905)
+- Add "ancient" to %%summary and %%description
+- Drop EL-5 support
+  - Drop BuildRoot: and Group: tags
+  - Drop explicit buildroot cleaning in %%install section
+  - Drop explicit %%clean section
+
 * Thu Jul 27 2017 Fedora Release Engineering  - 
2.18-5
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
 
diff --git a/sources b/sources
index 702671e..c593c9f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-972468ab5207b90398d77bed4ffc361d  MailTools-2.18.tar.gz
+SHA512 (MailTools-2.19.tar.gz) = 
a4ecba2acba56f2d41294e1b299c08b138d5e4796880635afcea7628adf60e11d5b138fc56001c331f765048bd91fa94da27bd7fdeedc51ff91e4ef5770a068e



https://src.fedoraproject.org/rpms/perl-MailTools/c/80b56f0826fa49a1094ce1d1eea8aae408275bfc?branch=f27
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pghmcfc pushed to perl-MailTools (master). "Update to 2.19, drop EL-5 support (..more)"

From 80b56f0826fa49a1094ce1d1eea8aae408275bfc Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Aug 23 2017 15:16:11 +
Subject: Update to 2.19, drop EL-5 support


- New upstream release 2.19
  - Block namespace MailTools (CPAN RT#120905)
- Add "ancient" to %summary and %description
- Drop EL-5 support
  - Drop BuildRoot: and Group: tags
  - Drop explicit buildroot cleaning in %install section
  - Drop explicit %clean section

---

diff --git a/perl-MailTools.spec b/perl-MailTools.spec
index 672f41f..4f9a8af 100644
--- a/perl-MailTools.spec
+++ b/perl-MailTools.spec
@@ -1,19 +1,17 @@
-Summary:   Various mail-related perl modules
+Summary:   Various ancient mail-related perl modules
 Name:  perl-MailTools
-Version:   2.18
-Release:   5%{?dist}
+Version:   2.19
+Release:   1%{?dist}
 License:   GPL+ or Artistic
-Group: Development/Libraries
 URL:   http://search.cpan.org/dist/MailTools/
 Source0:   
http://search.cpan.org/CPAN/authors/id/M/MA/MARKOV/MailTools-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
 BuildArch: noarch
 # Module Build
 BuildRequires: coreutils
 BuildRequires: findutils
 BuildRequires: make
-BuildRequires: perl-interpreter >= 3:5.8.1
 BuildRequires: perl-generators
+BuildRequires: perl-interpreter
 BuildRequires: perl(ExtUtils::MakeMaker)
 BuildRequires: sed
 # Module Runtime
@@ -42,7 +40,7 @@ Requires: perl(Net::Domain) >= 1.05
 Requires:  perl(Net::NNTP)
 
 %description
-MailTools is a set of Perl modules related to mail applications.
+MailTools is a set of ancient Perl modules related to mail applications.
 
 %prep
 %setup -q -n MailTools-%{version}
@@ -63,18 +61,14 @@ perl Makefile.PL INSTALLDIRS=vendor
 make %{?_smp_mflags}
 
 %install
-rm -rf %{buildroot}
 make pure_install DESTDIR=%{buildroot}
 find %{buildroot} -type f -name .packlist -delete
-%{_fixperms} %{buildroot}
+%{_fixperms} -c %{buildroot}
 
 %check
 make test
 make test TEST_FILES="xt/*.t"
 
-%clean
-rm -rf %{buildroot}
-
 %files
 %doc ChangeLog README* examples/
 %dir %{perl_vendorlib}/Mail/
@@ -92,6 +86,7 @@ rm -rf %{buildroot}
 %doc %{perl_vendorlib}/Mail/Mailer.pod
 %doc %{perl_vendorlib}/Mail/Send.pod
 %doc %{perl_vendorlib}/Mail/Util.pod
+%doc %{perl_vendorlib}/MailTools.pod
 %{perl_vendorlib}/Mail/Address.pm
 %{perl_vendorlib}/Mail/Cap.pm
 %{perl_vendorlib}/Mail/Filter.pm
@@ -110,6 +105,7 @@ rm -rf %{buildroot}
 %{perl_vendorlib}/Mail/Mailer/smtp.pm
 %{perl_vendorlib}/Mail/Mailer/smtps.pm
 %{perl_vendorlib}/Mail/Mailer/testfile.pm
+%{perl_vendorlib}/MailTools.pm
 %{_mandir}/man3/Mail::Address.3*
 %{_mandir}/man3/Mail::Cap.3*
 %{_mandir}/man3/Mail::Field.3*
@@ -122,8 +118,18 @@ rm -rf %{buildroot}
 %{_mandir}/man3/Mail::Mailer.3*
 %{_mandir}/man3/Mail::Send.3*
 %{_mandir}/man3/Mail::Util.3*
+%{_mandir}/man3/MailTools.3*
 
 %changelog
+* Wed Aug 23 2017 Paul Howarth  - 2.19-1
+- Update to 2.19
+  - Block namespace MailTools (CPAN RT#120905)
+- Add "ancient" to %%summary and %%description
+- Drop EL-5 support
+  - Drop BuildRoot: and Group: tags
+  - Drop explicit buildroot cleaning in %%install section
+  - Drop explicit %%clean section
+
 * Thu Jul 27 2017 Fedora Release Engineering  - 
2.18-5
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
 
diff --git a/sources b/sources
index 702671e..c593c9f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-972468ab5207b90398d77bed4ffc361d  MailTools-2.18.tar.gz
+SHA512 (MailTools-2.19.tar.gz) = 
a4ecba2acba56f2d41294e1b299c08b138d5e4796880635afcea7628adf60e11d5b138fc56001c331f765048bd91fa94da27bd7fdeedc51ff91e4ef5770a068e



https://src.fedoraproject.org/rpms/perl-MailTools/c/80b56f0826fa49a1094ce1d1eea8aae408275bfc?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pghmcfc uploaded MailTools-2.19.tar.gz for perl-MailTools

a4ecba2acba56f2d41294e1b299c08b138d5e4796880635afcea7628adf60e11d5b138fc56001c331f765048bd91fa94da27bd7fdeedc51ff91e4ef5770a068e
  MailTools-2.19.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-MailTools/MailTools-2.19.tar.gz/sha512/a4ecba2acba56f2d41294e1b299c08b138d5e4796880635afcea7628adf60e11d5b138fc56001c331f765048bd91fa94da27bd7fdeedc51ff91e4ef5770a068e/MailTools-2.19.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik pushed to perl-Config-Model-Tester (f27). "3.002 bump"

From 8a9e1cffd086f99a49cd5015cd240749af4515d9 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Aug 23 2017 07:03:40 +
Subject: 3.002 bump


---

diff --git a/.gitignore b/.gitignore
index 64b50b8..bf1e8e4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -9,3 +9,4 @@
 /Config-Model-Tester-2.060.tar.gz
 /Config-Model-Tester-2.061.tar.gz
 /Config-Model-Tester-3.001.tar.gz
+/Config-Model-Tester-3.002.tar.gz
diff --git a/perl-Config-Model-Tester.spec b/perl-Config-Model-Tester.spec
index 2c5a223..09fb903 100644
--- a/perl-Config-Model-Tester.spec
+++ b/perl-Config-Model-Tester.spec
@@ -1,6 +1,6 @@
 Name:   perl-Config-Model-Tester
-Version:3.001
-Release:2%{?dist}
+Version:3.002
+Release:1%{?dist}
 Summary:Test framework for Config::Model
 License:LGPLv2
 Group:  Development/Libraries
@@ -62,6 +62,9 @@ perl Build.PL installdirs=vendor
 %{_mandir}/man3/*
 
 %changelog
+* Wed Aug 23 2017 Jitka Plesnikova  - 3.002-1
+- 3.002 bump
+
 * Thu Jul 27 2017 Fedora Release Engineering  - 
3.001-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
 
diff --git a/sources b/sources
index 187df6b..2cca2ff 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Config-Model-Tester-3.001.tar.gz) = 
b25bc2edf751238751313062df109f2ca6a84442ea6c857f0897f24d51ea4c9cc806d732c9f55cd2ac34aa3c682a47660ded4c571eb722b84f8e4d775e53e10d
+SHA512 (Config-Model-Tester-3.002.tar.gz) = 
93ad17c795bff38bf55ac19c79d2e8eab49e64f6e6e71354f01cdf666fb3b4b4ea33bdca522116163ce1f4e9cd81c85f22ef1a6953fa33a6f46a134accf629e4



https://src.fedoraproject.org/rpms/perl-Config-Model-Tester/c/8a9e1cffd086f99a49cd5015cd240749af4515d9?branch=f27
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik pushed to perl-Config-Model-Tester (master). "3.002 bump"

From 8a9e1cffd086f99a49cd5015cd240749af4515d9 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Aug 23 2017 07:03:40 +
Subject: 3.002 bump


---

diff --git a/.gitignore b/.gitignore
index 64b50b8..bf1e8e4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -9,3 +9,4 @@
 /Config-Model-Tester-2.060.tar.gz
 /Config-Model-Tester-2.061.tar.gz
 /Config-Model-Tester-3.001.tar.gz
+/Config-Model-Tester-3.002.tar.gz
diff --git a/perl-Config-Model-Tester.spec b/perl-Config-Model-Tester.spec
index 2c5a223..09fb903 100644
--- a/perl-Config-Model-Tester.spec
+++ b/perl-Config-Model-Tester.spec
@@ -1,6 +1,6 @@
 Name:   perl-Config-Model-Tester
-Version:3.001
-Release:2%{?dist}
+Version:3.002
+Release:1%{?dist}
 Summary:Test framework for Config::Model
 License:LGPLv2
 Group:  Development/Libraries
@@ -62,6 +62,9 @@ perl Build.PL installdirs=vendor
 %{_mandir}/man3/*
 
 %changelog
+* Wed Aug 23 2017 Jitka Plesnikova  - 3.002-1
+- 3.002 bump
+
 * Thu Jul 27 2017 Fedora Release Engineering  - 
3.001-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
 
diff --git a/sources b/sources
index 187df6b..2cca2ff 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Config-Model-Tester-3.001.tar.gz) = 
b25bc2edf751238751313062df109f2ca6a84442ea6c857f0897f24d51ea4c9cc806d732c9f55cd2ac34aa3c682a47660ded4c571eb722b84f8e4d775e53e10d
+SHA512 (Config-Model-Tester-3.002.tar.gz) = 
93ad17c795bff38bf55ac19c79d2e8eab49e64f6e6e71354f01cdf666fb3b4b4ea33bdca522116163ce1f4e9cd81c85f22ef1a6953fa33a6f46a134accf629e4



https://src.fedoraproject.org/rpms/perl-Config-Model-Tester/c/8a9e1cffd086f99a49cd5015cd240749af4515d9?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik uploaded Config-Model-Tester-3.002.tar.gz for perl-Config-Model-Tester

93ad17c795bff38bf55ac19c79d2e8eab49e64f6e6e71354f01cdf666fb3b4b4ea33bdca522116163ce1f4e9cd81c85f22ef1a6953fa33a6f46a134accf629e4
  Config-Model-Tester-3.002.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-Config-Model-Tester/Config-Model-Tester-3.002.tar.gz/sha512/93ad17c795bff38bf55ac19c79d2e8eab49e64f6e6e71354f01cdf666fb3b4b4ea33bdca522116163ce1f4e9cd81c85f22ef1a6953fa33a6f46a134accf629e4/Config-Model-Tester-3.002.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1482536] perl-Time-HiRes-1.9746 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Time-HiRes-1.9746-1.fc |perl-Time-HiRes-1.9746-1.fc
   |28  |28
   ||perl-Time-HiRes-1.9746-1.fc
   ||26
 Resolution|--- |ERRATA
Last Closed||2017-08-23 15:55:05



--- Comment #4 from Fedora Update System  ---
perl-Time-HiRes-1.9746-1.fc26 has been pushed to the Fedora 26 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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: Review swap

2017-08-23 Thread Andrea Musuruane

Hi Volerk,

Hello Andrea!
>
> Please add it to http://fedoraproject.org/wiki/GIS
>

Added!!

Bye,

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

Re: Review swap

2017-08-23 Thread Volker Fröhlich


Am 2017-08-23 um 12:16 schrieb Andrea Musuruane:

Hi!
 I'm looking for a reviewer for

osmctools - Tools to manipulate OpenStreetMap files:
https://bugzilla.redhat.com/show_bug.cgi?id=1464777

Maybe some other OSM mapper is interested?

I'm happy to exchange reviews.

Thanks in advance.

Bye,

Andrea



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



Hello Andrea!

Please add it to http://fedoraproject.org/wiki/GIS

Greetings,

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

Re: autoconf-archive suddenly gone in EPEL 7

2017-08-23 Thread Benjamin Kircher


> On 23. Aug 2017, at 14:29, Stephen Gallagher  wrote:
> 
> This is one of those unfortunate things that happens when using CentOS; major 
> releases trail RHEL and sometimes when things make the shift from EPEL to 
> RHEL proper, CentOS users end up without some packages available for a while. 
> We're dealing with the same issue with the `http-parser` package, which not 
> only got moved from EPEL to RHEL, but also downgraded the NVR in the process 
> (so we can't just leave the EPEL package in the repo  until CentOS catches 
> up).

First time this has bitten me. To be honest, this is actually pretty bad. 
(Understandable though.)

Luckily, 7.4.1708 is expected somewhere between Aug 22 and Sept 12 according to 
[1].

BK

[1] 
https://seven.centos.org/2017/08/centos-linux-7-1708-based-on-rhel-7-4-source-code/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: nodejs broken

On Wed, Aug 23, 2017 at 12:02 PM Peter Robinson 
wrote:

> > The problem is that CentOS 7.4 still doesn't exist yet, so if Node.js
> > requires OpenSSL 1.0.2 functionality, it's still broken for CentOS users.
>
> Yep, but then also is a bunch of other stuff due to the fact things
> were bumped in RHEL, sadly without forking of each el7 dot release
> there's not much can be done about that and the consensus (right or
> wrong) has been to build for RHEL and when CentOS catches up they'll
> be OK.
>
>
Yeah, not having forked minor releases for EPEL tends to leave stuff like
this unsolvable.

> You could do a whole bunch of work here to find CentOS is out before
> the fix hits stable, if you've got that amount of time go for it.
>
>
That was my original plan; to just carry the bundled http-parser in
epel-testing for a week or two while CentOS caught up, then switch the
Bodhi update back to using the unbundled version. Unfortunately, I didn't
foresee the OpenSSL issue.

> > I'm trying right now to figure out if I build it for 1.0.1 functionality
> if
> > 1.0.2 is sufficiently backwards-compatible. Because my initial glance
> > suggests that it might not be and so I would have to choose between
> whether
> > it works against 1.0.1 and breaks RHEL 7.4 users or 1.0.2 and breaks
> CentOS
> > 7.3 users.
> >
>

So, the patch for 1.0.1 support is very invasive and would be painful to
make work when 1.0.2 is in the buildroot (which of course it is because
Koji uses the latest RHEL repos).

I think the only sane approach here is going to be to just drop all of the
7.3-specific stuff and just tell people that they're unfortunately out of
luck on CentOS until 7.4 is out for that platform.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: [modularity] Modules and AppStream

2017-08-23 Thread Richard Hughes

On 23 August 2017 at 13:57, Marius Vollmer  wrote:
> In a modular repository, I think the same thing should happen so that
> GNOME Software can present interesting modules to the user in a nice
> way.

What kind of modules would be shown in gnome-software? Are
applications like Firefox going to be supported in the new modularity
system? We're not going to be showing httpd there for instance.

>  - Metainfo is in packages, but we need to be installing modules.

How are we going to be installing modules in a modular-system?
PackageKit is only going to be able to install packages so
gnome-software will obviously need to be able to install things.

>  Thus,
>the collection data needs to have module names into the AppStream
> tag.

I think the pkgname tag needs to contain the package name. We have a
 tag that might be more suitable for adding things like
version or stream information.

>  I propose to keep AppStream metainfo data in
>packages, and map from package names to module names during
>construction of the collection data.

Can you elaborate a bit? At the moment in Fedora we generate the
AppStream metadata from a mirror of all the packages using
appstream-builder.

>  - Because of streams and profiles, there can be multiple versions of
>metainfo for a given AppStream component id.  These need to be
>merged

No, I don't think they do. If you have two very different versions of
Firefox (one LTS, one bleeding edge) you want a different description,
different screenshots and different reviews.

The way we've solved this in Flatpak is to use a different application
ID, for instance Firefox nightly would be
org.mozilla.Firefox.Nightly.desktop rather than
org.mozilla.Firefox.desktop

I don't think you can pretend that applications from different
branches (with different features, bugs and possibly UI) are the
"same" component, especially when you can install zero, one or many at
the same time.

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

Re: modularity: (my) expectations vs. reality

2017-08-23 Thread stan

On Wed, 23 Aug 2017 07:51:57 +0200
Michal Novotny  wrote:

> I guess I am missing something but I don't see how modularity adds
> flexibility. rpm, yum repos, ansible, dnf seem to be quite flexible
> even now and having that + something else on top seems to be less
> flexible. I am just speaking my mind here.

I'm not involved in modularity, and I'm speaking as an observer.  But
it seems that it would be a lot more effective to put the libraries in
containers, and keep applications in rpms.

That is, say there is a python container, and it contains the various
formats of python, 2.6, 2.7, 3.5, 3.6, etc.  Then any application that
needs python just specifies the python it needs, and the OS links it
with the proper library from the container when it runs.

Or, gtk, with all its variations in a container, and again, applications
get the version they need to run transparently.

This would eliminate all the redundant library duplication that
containers as they are now envisioned would entail.  There would still
be redundancy, but it would be the minimal set for the applications that
are installed.  And it would still allow the upstream of applications to
specify specific libraries without worrying about
variations in distributions.  

This doesn't address security concerns if an application upstream
specifies a library that is known to be insecure or unmaintained, and
it is in a container.  But that's just a policy decision of a
distribution as to whether they allow a library container to contain
insecure versions in order to permit applications to install.

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

Re: removable setup rpm?!


Dne 18.8.2017 v 13:43 Petr Stodulka napsal(a):

which leads to unusable system, because of missing important files,
like /etc/shadow, 


Lets just focus on this one package. The question is why the removal of the 
package is removing
  /etc/shadow
  /etc/passwd
?

When I remove it it will:
warning: /etc/shadow saved as /etc/shadow.rpmsave
warning: /etc/passwd saved as /etc/passwd.rpmsave

That is because there is in spec file:

%verify(not md5 size mtime) %config(noreplace) /etc/passwd
%verify(not md5 size mtime) %config(noreplace) /etc/group

I would expect rather %ghost directive there.

With %ghost in place we can even omit the %posttrans:

#throw away useless and dangerous update stuff until rpm will be able to
#handle it ( http://rpm.org/ticket/6 )
%post -p 
for i, name in ipairs({"passwd", "shadow", "group", "gshadow"}) do
 os.remove("/etc/"..name..".rpmnew")
end

The initial content should be IMHO populated by anaconda.

With the %ghost the removal of package will leave the important files on disk 
and the system will be operational.

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

[EPEL-devel] Re: nodejs broken

2017-08-23 Thread Peter Robinson

On Wed, Aug 23, 2017 at 4:52 PM, Stephen Gallagher  wrote:
>
>
> On Wed, Aug 23, 2017 at 10:02 AM Peter Robinson 
> wrote:
>>
>> > It turns out there's an additional issue; it appears that Node.js 6.11.2
>> > with the bundled http-parser doesn't work properly with OpenSSL 1.0.1 on
>> > EPEL 7. This would also be fixed by requiring RHEL/CentOS 7.4 (since it
>> > upgraded to OpenSSL 1.0.2).
>> >
>> > I'm trying to figure out what to do here. We can't just put back the
>> > http-parser in EPEL unfortunately because the RHEL folks unintentionally
>> > released a lower NVR for the official package. If we put ours back, it
>> > would
>> > supersede RHEL and take them out of support on any package linking
>> > against
>> > it (which now includes parts of SSSD).
>>
>> > I'm going to spend a little time today trying to figure out if I can fix
>> > the
>> > OpenSSL 1.0.1 compatibility patch and push out an update that will work
>> > with
>> > the bundled http-parser for now.
>>
>> Can you not just rebuild nodejs, which will rebuild the bundled
>> http-parser, against the new 1.0.2 build in 7.4?
>
>
> The problem is that CentOS 7.4 still doesn't exist yet, so if Node.js
> requires OpenSSL 1.0.2 functionality, it's still broken for CentOS users.

Yep, but then also is a bunch of other stuff due to the fact things
were bumped in RHEL, sadly without forking of each el7 dot release
there's not much can be done about that and the consensus (right or
wrong) has been to build for RHEL and when CentOS catches up they'll
be OK.

You could do a whole bunch of work here  to find CentOS is out before
the fix hits stable, if you've got that amount of time go for it.

> I'm trying right now to figure out if I build it for 1.0.1 functionality if
> 1.0.2 is sufficiently backwards-compatible. Because my initial glance
> suggests that it might not be and so I would have to choose between whether
> it works against 1.0.1 and breaks RHEL 7.4 users or 1.0.2 and breaks CentOS
> 7.3 users.
>
> For the record, this is irrespective of the http-parser issue. That one at
> least is solved just by carrying the bundled copy for a short time. But I
> can't do the same with OpenSSL because the Node.js bundled copy of OpenSSL
> is known to have encumbered codecs and I see no value in duplicating the
> effort of stripping them out.

Sure, I don't know the whole problem, I was just going on the snippets
of info you provided.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: nodejs broken

2017-08-23 Thread Peter Robinson

On Wed, Aug 23, 2017 at 4:38 PM, Stephen John Smoogen  wrote:
> On 23 August 2017 at 10:01, Peter Robinson  wrote:
>>> On Wed, Aug 23, 2017 at 7:17 AM Richard Grainger  wrote:
>
>>> I'm trying to figure out what to do here. We can't just put back the
>>> http-parser in EPEL unfortunately because the RHEL folks unintentionally
>>> released a lower NVR for the official package. If we put ours back, it would
>>> supersede RHEL and take them out of support on any package linking against
>>> it (which now includes parts of SSSD).
>>
>> We should really be bumping and pushing an errata if RHEL picked up
>
> I am not sure who the we here is. I am guessing Red Hat but it could
> also be EPEL. If there is something we can do inside of EPEL, I will
> try to get it done this week.

We is Red Hat EL platform engineering, nothing EPEL can do.

>> the EPEL package and pulled it into core RHEL anyway because if people
>> had been previously using it in EPEL for other reasons (and 100s of
>> enterprises do sync EPEL) they would already be in a situation where
>> they're running an unsupported version, there is no other fix to that
>> and Red Hat engineering needs to improve their processes in this
>> regard because there is a number of these issues each el7 cycle.
>>
>
> The usual issue is the following:
>
> 1. The package gets pulled into RHEL-7-next by whatever arcane
> processes does that.
> 2. The owner usually fixes some problem and thinks that the version
> they are pushing with the fix will be accepted internally.
> 3. The fix is too late in the arcane processes and RHEL ships with an
> older version.
> 4. Everyone points fingers at each other for a couple of months after
> a release. Someone tries to iron out problems.
> 5. We have a good release cycle next time.
> 6. Some arcane process changes
> 7. Goto 1.
>
> I think we have done this dance every other minor release since 5.1
>
> I have some ideas on how we can try to 'fix' this from now on that I
> will be presenting at FLOCK next week so that releng and related
> groups can fix/kill.

Sure, but it's a Red Hat not a Fedora/EPEL problem so I don't actually
see how a Flock presentation can fix it, it needs internal product
management etc to put together a process to deal.

>>> I'm going to spend a little time today trying to figure out if I can fix the
>>> OpenSSL 1.0.1 compatibility patch and push out an update that will work with
>>> the bundled http-parser for now.
>>
>> Can you not just rebuild nodejs, which will rebuild the bundled
>> http-parser, against the new 1.0.2 build in 7.4?
>> ___
>> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
>> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
>
>
>
> --
> Stephen J Smoogen.
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: nodejs broken

On Wed, Aug 23, 2017 at 10:02 AM Peter Robinson 
wrote:

> > It turns out there's an additional issue; it appears that Node.js 6.11.2
> > with the bundled http-parser doesn't work properly with OpenSSL 1.0.1 on
> > EPEL 7. This would also be fixed by requiring RHEL/CentOS 7.4 (since it
> > upgraded to OpenSSL 1.0.2).
> >
> > I'm trying to figure out what to do here. We can't just put back the
> > http-parser in EPEL unfortunately because the RHEL folks unintentionally
> > released a lower NVR for the official package. If we put ours back, it
> would
> > supersede RHEL and take them out of support on any package linking
> against
> > it (which now includes parts of SSSD).
>
> > I'm going to spend a little time today trying to figure out if I can fix
> the
> > OpenSSL 1.0.1 compatibility patch and push out an update that will work
> with
> > the bundled http-parser for now.
>
> Can you not just rebuild nodejs, which will rebuild the bundled
> http-parser, against the new 1.0.2 build in 7.4?
>

The problem is that CentOS 7.4 still doesn't exist yet, so if Node.js
requires OpenSSL 1.0.2 functionality, it's still broken for CentOS users.

I'm trying right now to figure out if I build it for 1.0.1 functionality if
1.0.2 is sufficiently backwards-compatible. Because my initial glance
suggests that it might not be and so I would have to choose between whether
it works against 1.0.1 and breaks RHEL 7.4 users or 1.0.2 and breaks CentOS
7.3 users.

For the record, this is irrespective of the http-parser issue. That one at
least is solved just by carrying the bundled copy for a short time. But I
can't do the same with OpenSSL because the Node.js bundled copy of OpenSSL
is known to have encumbered codecs and I see no value in duplicating the
effort of stripping them out.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: nodejs broken

2017-08-23 Thread Stephen John Smoogen

On 23 August 2017 at 10:01, Peter Robinson  wrote:
>> On Wed, Aug 23, 2017 at 7:17 AM Richard Grainger  wrote:

>> I'm trying to figure out what to do here. We can't just put back the
>> http-parser in EPEL unfortunately because the RHEL folks unintentionally
>> released a lower NVR for the official package. If we put ours back, it would
>> supersede RHEL and take them out of support on any package linking against
>> it (which now includes parts of SSSD).
>
> We should really be bumping and pushing an errata if RHEL picked up

I am not sure who the we here is. I am guessing Red Hat but it could
also be EPEL. If there is something we can do inside of EPEL, I will
try to get it done this week.

> the EPEL package and pulled it into core RHEL anyway because if people
> had been previously using it in EPEL for other reasons (and 100s of
> enterprises do sync EPEL) they would already be in a situation where
> they're running an unsupported version, there is no other fix to that
> and Red Hat engineering needs to improve their processes in this
> regard because there is a number of these issues each el7 cycle.
>

The usual issue is the following:

1. The package gets pulled into RHEL-7-next by whatever arcane
processes does that.
2. The owner usually fixes some problem and thinks that the version
they are pushing with the fix will be accepted internally.
3. The fix is too late in the arcane processes and RHEL ships with an
older version.
4. Everyone points fingers at each other for a couple of months after
a release. Someone tries to iron out problems.
5. We have a good release cycle next time.
6. Some arcane process changes
7. Goto 1.

I think we have done this dance every other minor release since 5.1

I have some ideas on how we can try to 'fix' this from now on that I
will be presenting at FLOCK next week so that releng and related
groups can fix/kill.

>> I'm going to spend a little time today trying to figure out if I can fix the
>> OpenSSL 1.0.1 compatibility patch and push out an update that will work with
>> the bundled http-parser for now.
>
> Can you not just rebuild nodejs, which will rebuild the bundled
> http-parser, against the new 1.0.2 build in 7.4?
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

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

[EPEL-devel] Re: RHEL-7.4 is released (build roots updating)

2017-08-23 Thread Mátyás Selmeci

Is there a list of the packages that will be removed from EPEL because 
they are in RHEL 7.4? (And when that will happen?) Many of our users are 
on Scientific Linux and SL 7.4 is not out yet.


Thanks,
-Mat

On 08/01/17 16:24, Stephen John Smoogen wrote:



RHEL-7.4 was released today and so the build roots for EPEL packages 
will be updated as soon as the automatic reposync is done.


This may cause problems for EPEL builds for CentOS people so please be 
careful in pushing items from epel-testing to epel until CentOS is 
caught up.


--
Stephen J Smoogen.



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

Re: No i686 build of grub2?

2017-08-23 Thread Peter Jones

On Wed, Aug 23, 2017 at 07:27:44AM -0500, Bruno Wolff III wrote:
> Currently grub2 isn't being built for i686 since somewhere between 2.02-8
> and 2.02-10.
> I looked through the change log (but not the git log yet) and didn't see
> anything mentioning this, which I would have expected if it was an
> intentional change.
> So is this a new permanent feature going forward or a temporary oops?
> (I still have one machine I use regularly, that only runs i686 and it will
> probably be a while before I can afford to replace it.)

It is still built as grub2-pc{,-modules}, just built a bit differently.
I'll figure out how to re-work it so you won't see a problem, thanks for
the heads up.

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

alglib soname bump

2017-08-23 Thread Sandro Mani


Hi

I'm updating to alglib-3.12.0 in rawhide and F27, I'll rebuild the 
following dependent packages:


gmsh-3.0.4-1.fc27.src.rpm
qmapshack-1.9.0-1.fc27.src.rpm


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

Re: f27 builds in COPR fail without logs

2017-08-23 Thread Alexander Ploumistos

On Wed, Aug 23, 2017 at 3:00 PM, Miroslav Suchý  wrote:
> Dne 22.8.2017 v 14:53 Michal Novotny napsal(a):
>>
>> Eventually, a new version should pop up here:
>> https://bodhi.fedoraproject.org/updates/?packages=mock
>>
>> You can give it Karma when it appears so that it reaches Fedora repos a
>> bit faster.
>>
>
> It is there waiting for your karma.

[facepalm]
I had seen the updates in bodhi, but for some reason I was waiting for
an fc27 update...

What are copr builders running by the way?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: nodejs broken

2017-08-23 Thread Peter Robinson

> On Wed, Aug 23, 2017 at 7:17 AM Richard Grainger  wrote:
>>
>> OK, thanks,
>>
>> On Wed, Aug 23, 2017 at 12:13 PM, Anssi Johansson  wrote:
>>>
>>> Anssi Johansson kirjoitti 23.8.2017 klo 13.31:

 Richard Grainger kirjoitti 23.8.2017 klo 11.55:
>
> yum install nodejs

 Try with this:

 yum install nodejs --enablerepo=epel-testing

 This will install nodejs with http-parser bundled in. http-parser was
 removed from EPEL because it is now in RHEL 7.4, and EPEL does not ship
 packages that are also in RHEL. http-parser will be in CentOS 7.4 once it 
 is
 released.
>>>
>>>
>>> I forgot to mention that this is only a temporary workaround. Once CentOS
>>> 7.4 is released, nodejs will revert back to depending on http-parser from
>>> RHEL/CentOS.
>>
>>
>
>
> It turns out there's an additional issue; it appears that Node.js 6.11.2
> with the bundled http-parser doesn't work properly with OpenSSL 1.0.1 on
> EPEL 7. This would also be fixed by requiring RHEL/CentOS 7.4 (since it
> upgraded to OpenSSL 1.0.2).
>
> I'm trying to figure out what to do here. We can't just put back the
> http-parser in EPEL unfortunately because the RHEL folks unintentionally
> released a lower NVR for the official package. If we put ours back, it would
> supersede RHEL and take them out of support on any package linking against
> it (which now includes parts of SSSD).

We should really be bumping and pushing an errata if RHEL picked up
the EPEL package and pulled it into core RHEL anyway because if people
had been previously using it in EPEL for other reasons (and 100s of
enterprises do sync EPEL) they would already be in a situation where
they're running an unsupported version, there is no other fix to that
and Red Hat engineering needs to improve their processes in this
regard because there is a number of these issues each el7 cycle.

> I'm going to spend a little time today trying to figure out if I can fix the
> OpenSSL 1.0.1 compatibility patch and push out an update that will work with
> the bundled http-parser for now.

Can you not just rebuild nodejs, which will rebuild the bundled
http-parser, against the new 1.0.2 build in 7.4?
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: Complicated problem: kiwi and kiwi-gtk conflict

2017-08-23 Thread Matthew Miller

On Wed, Aug 23, 2017 at 09:42:29AM -0400, Neal Gompa wrote:
> It's both: http://suse.github.io/kiwi/development/kiwi_from_python.html
> It's explicitly designed to be used as a Python module as well as a
> command line tool.

Ok then. :)


-- 
Matthew Miller

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

Re: Complicated problem: kiwi and kiwi-gtk conflict

On Wed, Aug 23, 2017 at 9:39 AM, Matthew Miller
 wrote:
> On Wed, Aug 23, 2017 at 05:40:27AM -0400, Neal Gompa wrote:
>> So I submitted a review request on Sunday for python-kiwi[1], which is
>> the KIWI appliance image builder tool from SUSE[2] and is registered
>> in PyPI as kiwi[3].
>
> Shouldn't this new package just be named "kiwi"? From the docs, it's a
> command-line application that happens to be written in Python, not a
> Python module.
>

It's both: http://suse.github.io/kiwi/development/kiwi_from_python.html

It's explicitly designed to be used as a Python module as well as a
command line tool.

The older Perl-based one was the same way.


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

[EPEL-devel] Re: nodejs broken

On Wed, Aug 23, 2017 at 7:17 AM Richard Grainger  wrote:

> OK, thanks,
>
> On Wed, Aug 23, 2017 at 12:13 PM, Anssi Johansson  wrote:
>
>> Anssi Johansson kirjoitti 23.8.2017 klo 13.31:
>>
>>> Richard Grainger kirjoitti 23.8.2017 klo 11.55:
>>>
 yum install nodejs

>>>
>>> Try with this:
>>>
>>> yum install nodejs --enablerepo=epel-testing
>>>
>>> This will install nodejs with http-parser bundled in. http-parser was
>>> removed from EPEL because it is now in RHEL 7.4, and EPEL does not ship
>>> packages that are also in RHEL. http-parser will be in CentOS 7.4 once it
>>> is released.
>>>
>>
>> I forgot to mention that this is only a temporary workaround. Once CentOS
>> 7.4 is released, nodejs will revert back to depending on http-parser from
>> RHEL/CentOS.
>>
>
>

It turns out there's an additional issue; it appears that Node.js 6.11.2
with the bundled http-parser doesn't work properly with OpenSSL 1.0.1 on
EPEL 7. This would also be fixed by requiring RHEL/CentOS 7.4 (since it
upgraded to OpenSSL 1.0.2).

I'm trying to figure out what to do here. We can't just put back the
http-parser in EPEL unfortunately because the RHEL folks unintentionally
released a lower NVR for the official package. If we put ours back, it
would supersede RHEL and take them out of support on any package linking
against it (which now includes parts of SSSD).

I'm going to spend a little time today trying to figure out if I can fix
the OpenSSL 1.0.1 compatibility patch and push out an update that will work
with the bundled http-parser for now.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: Complicated problem: kiwi and kiwi-gtk conflict

2017-08-23 Thread Matthew Miller

On Wed, Aug 23, 2017 at 05:40:27AM -0400, Neal Gompa wrote:
> So I submitted a review request on Sunday for python-kiwi[1], which is
> the KIWI appliance image builder tool from SUSE[2] and is registered
> in PyPI as kiwi[3].

Shouldn't this new package just be named "kiwi"? From the docs, it's a
command-line application that happens to be written in Python, not a
Python module.

-- 
Matthew Miller

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

Re: Complicated problem: kiwi and kiwi-gtk conflict

On Wed, Aug 23, 2017 at 8:58 AM, Haïkel  wrote:
> 2017-08-23 14:44 GMT+02:00 Miroslav Suchý :
>> Dne 23.8.2017 v 11:40 Neal Gompa napsal(a):
>>>
>>> However, there's a problem. It seems python-kiwi already exists in
>>> Fedora[4], and it's the kiwi-gtk framework[5].
>>>
>>> I'm not sure what to do in this scenario. I've requested from upstream
>>> to rename the module[6], but I don't think they'll go for that,
>>> especially since they actually do have the kiwi name in PyPI.
>>>
>>> So what can I do?
>>
>>
>> Ask hguemar (owner of python-kiwi in fedora) to rename python-kiwi to
>> python-kiwi-gtk.
>>
>> Mirek
>
> Since it got renamed in pypi, ok, but Neal will have to review the
> renamed package.
>
> H.
>

Sure, I will. Just assign the rename request to me and I'll take a
crack at it.



-- 
真実はいつも一つ！/ 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: [modularity] Modularizing the world fast and iteratively

2017-08-23 Thread Matthew Miller

On Wed, Aug 23, 2017 at 09:54:25AM +0200, Adam Samalik wrote:
> So instead of trying to make everything perfect from the begining, we could
> build everything we need against the Bootstrap module - a module that is
> used as a buildroot for Host and Platform and contains mostly everything we
> need. To compare, there is a report without using bootstrap [5] and with
> using bootstrap [6]. This way we'll have a pretty decent set of module very
> soon.

I am +1 to a plan which yields a decent set of modules very soon. :)

Also, I'm continuing to feel good about this picture I drew several
years ago — https://mattdm.org/fedora/2015rings/ :)




-- 
Matthew Miller

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

Re: CI projects in Copr

2017-08-23 Thread jkonecny

Hi, 

We are making daily builds of Anaconda in Copr for Rawhide[1] and
actual Fedora[2]. These daily builds are used for our other test
suites.

[1]: https://copr.fedorainfracloud.org/coprs/g/rhinstaller/Anaconda/
[2]: https://copr.fedorainfracloud.org/coprs/g/rhinstaller/Anaconda-dev
el/

On Wed, 2017-08-23 at 13:46 +0200, Miroslav Suchý wrote:
> Hi,
> I am gathering informations about various use of CI with Copr. Do you
> use Copr for building packages for nightlies? For 
> building packages before pull request is merged? Do you have your set
> up described somewhere? What is the name of your 
> project?
> 
> Please let me know. Either here or via private reply.
> It will help me to understand your use of Copr and to make Copr
> better.
> 
> Thanks in advance.
> 
> Miroslav Suchy
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 build of grub2?

On Wed, Aug 23, 2017 at 9:13 AM, Bruno Wolff III  wrote:
> On Wed, Aug 23, 2017 at 08:57:30 -0400,
>  Mauricio Tavares  wrote:
>>
>> I think I read here (or in other mailing list) about an interest in
>> dropping 32bit altogether. But this might be just my imagination.
>
>
> Certainly there was a discussion, but I hadn't heard this was definitive, or
> that it was going to start in f27. (I'm using f28, but the change happened
> to f27 builds around the branch time.) I would expect this actually being
> done to be worthy of an announcement. That's why I think this might be a
> temporary issue. But how I work around it will depend on whether on not
> there will be official i686 builds again soon.

That addition of %ix86 to the ExcludeArch should probably be dropped.
There was nothing that indicated that should have been added to begin
with.


-- 
真実はいつも一つ！/ 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: No i686 build of grub2?

2017-08-23 Thread Bruno Wolff III


On Wed, Aug 23, 2017 at 08:57:30 -0400,
 Mauricio Tavares  wrote:

I think I read here (or in other mailing list) about an interest in
dropping 32bit altogether. But this might be just my imagination.


Certainly there was a discussion, but I hadn't heard this was definitive, 
or that it was going to start in f27. (I'm using f28, but the change 
happened to f27 builds around the branch time.) I would expect this 
actually being done to be worthy of an announcement. That's why I think 
this might be a temporary issue. But how I work around it will depend 
on whether on not there will be official i686 builds again soon.

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

Re: No i686 build of grub2?

2017-08-23 Thread Tom Hughes


On 23/08/17 13:57, Vascom wrote:


This commit remove add i686 to ExcludeArch
https://src.fedoraproject.org/rpms/grub2/c/ecef1ed7b50ed05b65574c8b8815d7ae66e5a0a9
ExcludeArch: s390 s390x %{arm} %{?ix86}


Without of course the required comment pointing at the required bug 
which blocks the relevant tracker bugs:


https://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Build_Failures

and nothing on the tracker bug that I can see:

https://bugzilla.redhat.com/showdependencytree.cgi?id=F-ExcludeArch-x86_resolved=1

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[ANNOUNCE] D-Bus Broker Project

2017-08-23 Thread David Herrmann

This is the first public release of dbus-broker.

Git Tag: v3
Archive: 
https://github.com/bus1/dbus-broker/archive/v3/dbus-broker-v3.tar.gz

The dbus-broker project is an implementation of a message bus as
defined by the D-Bus specification. Its aim is to provide high
performance and reliability, while keeping compatibility to the D-Bus
reference implementation. It is exclusively written for linux systems,
and makes use of many modern features provided by recent linux kernel
releases. Details are discussed in its introductory blog post:

https://dvdhrm.github.io/rethinking-the-dbus-message-bus/

The project is still experimental and not meant for production use,
yet. Packages are available for Fedora and Arch Linux. Other
distributions will follow.

DETAILS:
https://github.com/bus1/dbus-broker/wiki

BUG REPORTS:
https://github.com/bus1/dbus-broker/issues

GIT:
g...@github.com:bus1/dbus-broker.git
https://github.com/bus1/dbus-broker.git

PACKAGES:
https://copr.fedorainfracloud.org/coprs/g/bus1/dbus/package/dbus-broker/
https://aur.archlinux.org/packages/dbus-broker
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Complicated problem: kiwi and kiwi-gtk conflict

2017-08-23 Thread Haïkel

2017-08-23 14:44 GMT+02:00 Miroslav Suchý :
> Dne 23.8.2017 v 11:40 Neal Gompa napsal(a):
>>
>> However, there's a problem. It seems python-kiwi already exists in
>> Fedora[4], and it's the kiwi-gtk framework[5].
>>
>> I'm not sure what to do in this scenario. I've requested from upstream
>> to rename the module[6], but I don't think they'll go for that,
>> especially since they actually do have the kiwi name in PyPI.
>>
>> So what can I do?
>
>
> Ask hguemar (owner of python-kiwi in fedora) to rename python-kiwi to
> python-kiwi-gtk.
>
> Mirek

Since it got renamed in pypi, ok, but Neal will have to review the
renamed package.

H.

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

[modularity] Modules and AppStream

2017-08-23 Thread Marius Vollmer

Hi,

what happens when the packages in a module contain AppStream metainfo
files?

In a non-modular repository, all these metainfo files get collected into
a big AppStream collection file which is then used by GNOME Software
(for example) to present interesting packages to the user in a nice way.

In a modular repository, I think the same thing should happen so that
GNOME Software can present interesting modules to the user in a nice
way.

I think we need to change the collection process in the following ways,
it unfortunately wont just work:

 - Metainfo is in packages, but we need to be installing modules.  Thus,
   the collection data needs to have module names into the AppStream
tag.  I propose to keep AppStream metainfo data in
   packages, and map from package names to module names during
   construction of the collection data.

 - Because of streams and profiles, there can be multiple versions of
   metainfo for a given AppStream component id.  These need to be
   merged, using something like

   https://github.com/ximion/appstream/pull/132[1]

What do you think?

How would you map from a package name to module/stream/profile tuples?

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

Re: No i686 build of grub2?

2017-08-23 Thread Mauricio Tavares

I think I read here (or in other mailing list) about an interest in
dropping 32bit altogether. But this might be just my imagination.

On Wed, Aug 23, 2017 at 8:27 AM, Bruno Wolff III  wrote:
> Currently grub2 isn't being built for i686 since somewhere between 2.02-8
> and 2.02-10.
> I looked through the change log (but not the git log yet) and didn't see
> anything mentioning this, which I would have expected if it was an
> intentional change.
> So is this a new permanent feature going forward or a temporary oops?
> (I still have one machine I use regularly, that only runs i686 and it will
> probably be a while before I can afford to replace it.)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 build of grub2?

2017-08-23 Thread Vascom

This commit remove add i686 to ExcludeArch
https://src.fedoraproject.org/rpms/grub2/c/ecef1ed7b50ed05b65574c8b8815d7ae66e5a0a9
ExcludeArch: s390 s390x %{arm} %{?ix86}


ср, 23 авг. 2017 г. в 15:35, Bruno Wolff III :

> Currently grub2 isn't being built for i686 since somewhere between
> 2.02-8 and 2.02-10.
> I looked through the change log (but not the git log yet) and didn't see
> anything mentioning this, which I would have expected if it was an
> intentional change.
> So is this a new permanent feature going forward or a temporary oops?
> (I still have one machine I use regularly, that only runs i686 and it
> will probably be a while before I can afford to replace it.)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1484400] New: perl-Shell-Config-Generate-0.28 is available

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

Bug ID: 1484400
   Summary: perl-Shell-Config-Generate-0.28 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Shell-Config-Generate
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 0.28
Current version/release in rawhide: 0.26-1.fc27
URL: http://search.cpan.org/dist/Shell-Config-Generate/

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

-- 
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: Removal of code signing trust bits from ca-certificates

2017-08-23 Thread Kai Engert

There hasn't been any negative feedback, neither in Rawhide, nor from updates
testing.

I've just pushed the update to stable F25 and F26.

Kai


On Tue, 2017-07-18 at 22:11 +0200, Kai Engert wrote:
> Until recently, Mozilla maintained three individual trust bits for each root
> CA
> certificate:
> - trust for TLS servers
> - trust for email security
> - trust for code signing
> 
> The next CA update from Mozilla will switch the code signing trust bit
> OFF for all CAs.
> 
> Mozilla will no longer maintain this trust bit.
> 
> See 
> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/004uvRRnVy
> Y
> for background.
> 
> I'm not aware of anyone using this trust bit. The removal might have no
> effect.
> 
> This update of the CA list is supposed to get published with Firefox 56 on
> September 26.
> 
> In order to allow the Fedora community to test potential effects of this
> change,
> I intend to publish an update to the ca-certificates packages early, and keep
> it
> in updates-testing for a few weeks.
> 
> Tracking bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=1472468
> 
> Thanks
> Kai
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Complicated problem: kiwi and kiwi-gtk conflict


Dne 23.8.2017 v 11:40 Neal Gompa napsal(a):

However, there's a problem. It seems python-kiwi already exists in
Fedora[4], and it's the kiwi-gtk framework[5].

I'm not sure what to do in this scenario. I've requested from upstream
to rename the module[6], but I don't think they'll go for that,
especially since they actually do have the kiwi name in PyPI.

So what can I do?


Ask hguemar (owner of python-kiwi in fedora) to rename python-kiwi to 
python-kiwi-gtk.

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

No i686 build of grub2?

2017-08-23 Thread Bruno Wolff III

Currently grub2 isn't being built for i686 since somewhere between 
2.02-8 and 2.02-10.
I looked through the change log (but not the git log yet) and didn't see 
anything mentioning this, which I would have expected if it was an 
intentional change.

So is this a new permanent feature going forward or a temporary oops?
(I still have one machine I use regularly, that only runs i686 and it 
will probably be a while before I can afford to replace it.)

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

Re: autoconf-archive suddenly gone in EPEL 7

On Tue, Aug 22, 2017 at 8:41 AM Benjamin Kircher 
wrote:

>
> > On 22. Aug 2017, at 12:53, Vascom  wrote:
> >
> > As you can see here
> https://src.fedoraproject.org/rpms/autoconf-archive/commits/epel7
> > autoconf-archive removed from EPEL7 because it must be included in main
> CentOS repos.
>
>
> Thanks for the pointer.
>
> Unfortunately this new RHEL package is not yet in current Vagrant images
> (1707.01) nor available in copr making builds that depend on those Autoconf
> macros fail.
>
>
This is one of those unfortunate things that happens when using CentOS;
major releases trail RHEL and sometimes when things make the shift from
EPEL to RHEL proper, CentOS users end up without some packages available
for a while. We're dealing with the same issue with the `http-parser`
package, which not only got moved from EPEL to RHEL, but also downgraded
the NVR in the process (so we can't just leave the EPEL package in the repo
 until CentOS catches up).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CI projects in Copr

2017-08-23 Thread Fabio Valentini

Hi,

As the maintainer of the Pantheon DE components and elementary apps, I
have a setup that runs "nightly" builds of 59 of those packages in the
"decathorpe/elementary-nightly" COPR repository for all supported
fedora releases.

This "CI-like" setup helps me catch upstream changes (that warrant
packaging changes) early, and it has even made it possible for me (and
upstream) to find (and fix) errors and / or incompatible changes
early, and not only after a release was tagged upsteram.

The setup I have for triggering and running the builds is a bit
special, as I use a program that I wrote myself (kentauros [1]), which
is triggered by a systemd timer on my machine. The packaging files
(and the program itself) are available on github [2]. I have looked at
tito, but since I don't have access to the upstream repositories, I
needed to find my own solution.

Fabio

[1]: https://github.com/decathorpe/kentauros
[2]: https://github.com/decathorpe/elementary-nightly-rpms

On Wed, Aug 23, 2017 at 1:46 PM, Miroslav Suchý  wrote:
> Hi,
> I am gathering informations about various use of CI with Copr. Do you use
> Copr for building packages for nightlies? For building packages before pull
> request is merged? Do you have your set up described somewhere? What is the
> name of your project?
>
> Please let me know. Either here or via private reply.
> It will help me to understand your use of Copr and to make Copr better.
>
> Thanks in advance.
>
> Miroslav Suchy
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CI projects in Copr

2017-08-23 Thread Martin Sehnoutka

Hi,

I'm using Copr for build on commit for dnssec-trigger project:
https://github.com/InfrastructureServices/dnssec-trigger-fedora
It's using tito.

But I'm looking for a different way of doing this. Especially when I
work on some upstream project and I don't want to force them to include
tito. Anyway I didn't have time to check other possible solutions to
this problem.

Regards,
Martin

On 08/23/2017 01:46 PM, Miroslav Suchý wrote:
> Hi,
> I am gathering informations about various use of CI with Copr. Do you
> use Copr for building packages for nightlies? For building packages
> before pull request is merged? Do you have your set up described
> somewhere? What is the name of your project?
>
> Please let me know. Either here or via private reply.
> It will help me to understand your use of Copr and to make Copr better.
>
> Thanks in advance.
>
> Miroslav Suchy
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

-- 
Martin Sehnoutka | Associate Software Engineer
PGP: 5FD64AF5
UTC+1 (CET)
RED HAT | TRIED. TESTED. TRUSTED.




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

Re: f27 builds in COPR fail without logs


Dne 22.8.2017 v 14:53 Michal Novotny napsal(a):

Eventually, a new version should pop up here: 
https://bodhi.fedoraproject.org/updates/?packages=mock

You can give it Karma when it appears so that it reaches Fedora repos a bit 
faster.



It is there waiting for your karma.

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

Re: Deprecating rpmgrill-fetch-build and rpmgrill-analyze-local

2017-08-23 Thread Kamil Paral

On Wed, Aug 23, 2017 at 9:00 AM, Róman Joost  wrote:

> Hi,
>
> The rpmgrill tool ships with two commands which I think can be
> deprecated:
>
> rpmgrill-fetch-build in favour of `koji download-task`
> rpmgrill-analyze-local in favour of rpmgrill-unpack; rpmgrill unpacked
>
> Does anybody use these binaries and has disagreements?
>

Hi, we don't seem to be using any of those two commands in
https://pagure.io/taskotron/task-rpmgrill

So it shouldn't be a problem for us.
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org

Re: Review swap

2017-08-23 Thread Andrea Musuruane

Hi,

On Wed, Aug 23, 2017 at 12:30 PM, Alexander Ploumistos <
alex.ploumis...@gmail.com> wrote:

> Hello Andrea,
>
> I've taken it, but my ISP is giving me some trouble at the moment,
> they said they'll get things sorted out within the hour.
>
> I don't have a package ready for review yet, but I think I might have
> one by next week.
>

No problem at all.

Let me know when your package will be ready.

Bye,

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

Re: retired packages in rawhide/f27

2017-08-23 Thread Honggang LI

On Tue, Aug 22, 2017 at 09:29:58AM -0700, Kevin Fenzi wrote:
> On 08/22/2017 02:30 AM, Petr Pisar wrote:
> > On 2017-08-22, Honggang LI  wrote:
> >> hi,
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1404043#c41
> >> libibcm, libibumad, libibverbs, librdmacm and ibacm had been replaced by
> >> the new rdma-core package. Those five packages are sub-packages of the
> >> new rdma-core package.
> >>
> >> I had retired the f27 and rawhide branches of those five packages in
> >> last week. But the build...@fedoraproject.org keep sending messages to
> >> complain broken dependencies for those five packages.
> >>
> > The "fedgkg retire" tool is/was broken and could not perform a retirement
> > .
> > 
> > Koji reports for ibacm source package:
> > 
> > $ koji list-pkgs --show-blocked --package=ibacm
> > Package Tag Extra Arches Owner  
> > 
> > --- ---  
> > ---
> > [...]
> > ibacm   f27  releng 
> >  [BLOCKED]
> > ibacm   f26-Alphahonli  
> > 
> > ibacm   f26-Beta honli  
> > 
> > ibacm   f28  releng 
> > 
> > 
> > It means the package was not removed from Rawhide (f28) repositories.
> > 
> > If rerunning "fedpkg retire" does not help, you should file a ticket to
> >  or
> > .
> 
> Yeah, the retirement here seems to have only happened in f27.
> 
> I suspect this was right around branching time when you did this and
> something wasn't happy.
> 
> In any case, due to the rdma-core not building on armv7, blocking these
> packages currently breaks composes. (Thats one reason why we have not
> had a branched compose in a while).
> 
> So, I would appreciate it if you could leave f28/rawhide for now (since
> we do get composes there) until we get lorax set to handle things.

I'm still working on to get a ARM32 system or virtual machine. The hold
day was wasted because of different issues of software or hardware.

I will try my best to check the dep chain issue of ARM32. I send this email to
you to avoid spam the mailing list, just to let you know I'm working on
this.

I will reply to the mailing list until I get a working ARM32 system and
checked the dep chain issue.

thanks
> 
> kevin
> 
> 




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

CI projects in Copr


Hi,
I am gathering informations about various use of CI with Copr. Do you use Copr for building packages for nightlies? For 
building packages before pull request is merged? Do you have your set up described somewhere? What is the name of your 
project?


Please let me know. Either here or via private reply.
It will help me to understand your use of Copr and to make Copr better.

Thanks in advance.

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

[389-devel] Please review: Issue 47840-Add docstrings to setup and use generate_ds_params

2017-08-23 Thread Amita Sharma

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

https://pagure.io/389-ds-base/issue/raw/files/eaa6e56273ea3713584e252043017927240179e518d23f86000d79378e32-0001-Issue-47840-Add-docstrings-to-setup.patch

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

[EPEL-devel] Re: nodejs broken

2017-08-23 Thread Richard Grainger

OK, thanks,

On Wed, Aug 23, 2017 at 12:13 PM, Anssi Johansson  wrote:

> Anssi Johansson kirjoitti 23.8.2017 klo 13.31:
>
>> Richard Grainger kirjoitti 23.8.2017 klo 11.55:
>>
>>> yum install nodejs
>>>
>>
>> Try with this:
>>
>> yum install nodejs --enablerepo=epel-testing
>>
>> This will install nodejs with http-parser bundled in. http-parser was
>> removed from EPEL because it is now in RHEL 7.4, and EPEL does not ship
>> packages that are also in RHEL. http-parser will be in CentOS 7.4 once it
>> is released.
>>
>
> I forgot to mention that this is only a temporary workaround. Once CentOS
> 7.4 is released, nodejs will revert back to depending on http-parser from
> RHEL/CentOS.
>
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: nodejs broken

2017-08-23 Thread Anssi Johansson


Anssi Johansson kirjoitti 23.8.2017 klo 13.31:

Richard Grainger kirjoitti 23.8.2017 klo 11.55:

yum install nodejs


Try with this:

yum install nodejs --enablerepo=epel-testing

This will install nodejs with http-parser bundled in. http-parser was 
removed from EPEL because it is now in RHEL 7.4, and EPEL does not ship 
packages that are also in RHEL. http-parser will be in CentOS 7.4 once 
it is released.


I forgot to mention that this is only a temporary workaround. Once 
CentOS 7.4 is released, nodejs will revert back to depending on 
http-parser from RHEL/CentOS.

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

[EPEL-devel] Re: nodejs broken

2017-08-23 Thread Anssi Johansson


Richard Grainger kirjoitti 23.8.2017 klo 11.55:

yum install nodejs


Try with this:

yum install nodejs --enablerepo=epel-testing

This will install nodejs with http-parser bundled in. http-parser was 
removed from EPEL because it is now in RHEL 7.4, and EPEL does not ship 
packages that are also in RHEL. http-parser will be in CentOS 7.4 once 
it is released.

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

Re: Review swap

2017-08-23 Thread Alexander Ploumistos

Hello Andrea,

I've taken it, but my ISP is giving me some trouble at the moment,
they said they'll get things sorted out within the hour.

I don't have a package ready for review yet, but I think I might have
one by next week.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1477136] perl-No-Worries-1.5 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-No-Worries-1.5-1.fc26  |perl-No-Worries-1.5-1.fc26
   |perl-No-Worries-1.5-1.el6   |perl-No-Worries-1.5-1.el6
   ||perl-No-Worries-1.5-1.el7



--- Comment #9 from Fedora Update System  ---
perl-No-Worries-1.5-1.el7 has been pushed to the Fedora EPEL 7 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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 1477136] perl-No-Worries-1.5 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-No-Worries-1.5-1.fc26  |perl-No-Worries-1.5-1.fc26
   ||perl-No-Worries-1.5-1.el6



--- Comment #8 from Fedora Update System  ---
perl-No-Worries-1.5-1.el6 has been pushed to the Fedora EPEL 6 stable
repository. If problems still persist, please make note of it in this bug
report.

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

Review swap

2017-08-23 Thread Andrea Musuruane

Hi!
I'm looking for a reviewer for

osmctools - Tools to manipulate OpenStreetMap files:
https://bugzilla.redhat.com/show_bug.cgi?id=1464777

Maybe some other OSM mapper is interested?

I'm happy to exchange reviews.

Thanks in advance.

Bye,

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

Complicated problem: kiwi and kiwi-gtk conflict

Hey all,

So I submitted a review request on Sunday for python-kiwi[1], which is
the KIWI appliance image builder tool from SUSE[2] and is registered
in PyPI as kiwi[3].

However, there's a problem. It seems python-kiwi already exists in
Fedora[4], and it's the kiwi-gtk framework[5].

I'm not sure what to do in this scenario. I've requested from upstream
to rename the module[6], but I don't think they'll go for that,
especially since they actually do have the kiwi name in PyPI.

So what can I do?

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1483339
[2]: https://github.com/SUSE/kiwi
[3]: https://pypi.org/project/kiwi/
[4]: https://src.fedoraproject.org/rpms/python-kiwi
[5]: https://pypi.org/project/kiwi-gtk/
[6]: https://github.com/SUSE/kiwi/issues/471

-- 
真実はいつも一つ！/ 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: [DONE] Mass package change (python2- binary package renaming)

2017-08-23 Thread Kalev Lember

On 08/23/2017 02:00 AM, Kevin Fenzi wrote:
> Also, I'd like to very much thank you for doing this work. :)
> It's great to get done, it's great to do it quickly and I know it's a
> lot of hard work to script and build things.

Yes, thank you for doing this, Zbyszek!

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

[Bug 1483773] perl-CPAN-Perl-Releases-3.32 is available

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



--- Comment #4 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.32-1.fc26 has been pushed to the Fedora 26 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-2017-059c90f4f7

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

[EPEL-devel] nodejs broken

2017-08-23 Thread Richard Grainger

Hi

Dependencies for nodejs seem to be broken currently on CentOS 7.  Are EPEL
builds for 7.4 still ongoing?:

[root@b4982b06b5fd /]# yum install nodejs
Loaded plugins: fastestmirror, ovl
Loading mirror speeds from cached hostfile
 * base: mirror.as29550.net
 * epel: mirrors.coreix.net
 * extras: mirror.freethought-internet.co.uk
 * updates: mirror.freethought-internet.co.uk
Resolving Dependencies
--> Running transaction check
---> Package nodejs.x86_64 1:6.11.1-1.el7 will be installed
--> Processing Dependency: npm = 1:3.10.10-1.6.11.1.1.el7 for package:
1:nodejs-6.11.1-1.el7.x86_64
--> Processing Dependency: libuv >= 1:1.9.1 for package:
1:nodejs-6.11.1-1.el7.x86_64
--> Processing Dependency: http-parser >= 2.7.0 for package:
1:nodejs-6.11.1-1.el7.x86_64
--> Processing Dependency: libuv.so.1()(64bit) for package:
1:nodejs-6.11.1-1.el7.x86_64
--> Processing Dependency: libicuuc.so.50()(64bit) for package:
1:nodejs-6.11.1-1.el7.x86_64
--> Processing Dependency: libicui18n.so.50()(64bit) for package:
1:nodejs-6.11.1-1.el7.x86_64
--> Processing Dependency: libicudata.so.50()(64bit) for package:
1:nodejs-6.11.1-1.el7.x86_64
--> Processing Dependency: libhttp_parser.so.2()(64bit) for package:
1:nodejs-6.11.1-1.el7.x86_64
--> Running transaction check
---> Package libicu.x86_64 0:50.1.2-15.el7 will be installed
---> Package libuv.x86_64 1:1.10.2-1.el7 will be installed
---> Package nodejs.x86_64 1:6.11.1-1.el7 will be installed
--> Processing Dependency: http-parser >= 2.7.0 for package:
1:nodejs-6.11.1-1.el7.x86_64
--> Processing Dependency: libhttp_parser.so.2()(64bit) for package:
1:nodejs-6.11.1-1.el7.x86_64
---> Package npm.x86_64 1:3.10.10-1.6.11.1.1.el7 will be installed
--> Finished Dependency Resolution
Error: Package: 1:nodejs-6.11.1-1.el7.x86_64 (epel)
   Requires: libhttp_parser.so.2()(64bit)
Error: Package: 1:nodejs-6.11.1-1.el7.x86_64 (epel)
   Requires: http-parser >= 2.7.0
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[Bug 1483773] perl-CPAN-Perl-Releases-3.32 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.32-1.fc25 has been pushed to the Fedora 25 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-2017-8b4b3e1443

-- 
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: src.fedoraproject.org, forking projects, PRs

2017-08-23 Thread Pierre-Yves Chibon

On Wed, Aug 23, 2017 at 09:44:56AM +0200, Dan Horák wrote:
> On Wed, 23 Aug 2017 07:34:22 -
> "Wolfgang Stoeggl"  wrote:
> 
> > Hello,
> > is forking projects, PRs etc. already supposed to work at
> > src.fedoraproject.org? So far, I am getting the following:
> > 
> > # Source GIT URL: SSH
> > git clone ssh://pkgs.fedoraproject.org/forks/c72578/rpms/cacti.git
> > Permission denied (publickey).
> > # Remark: the ~/.ssh/id_rsa key is present here and working (e.g. for
> > # fedpkg)
> 
> I had to change the URL to contain my username when I forked FF
> ssh://shar...@pkgs.fedoraproject.org/forks/sharkcz/rpms/firefox.git
> 
> I guess that's a bug how pagure provides the cloning URL

Our usage of gitolite in dist-git is quite convoluted and pagure (the
application) was written with the traditional deployment of gitolite in mind.

There is a ticket in pagure (the app) to make it support the specificities of
the deployment in dist-git:
https://pagure.io/pagure/issue/2524


Let's see if I can get to it quickly :)

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

Re: introducing fed-install: easy way to install packages from koji and other releases

2017-08-23 Thread Tomas Tomecek

On Sun, Aug 20, 2017 at 10:59 PM, Kevin Fenzi  wrote:

>
> First, one thing that would be very handy (but could perhaps just be a
> dnf plugin) is to install from koji, but use signed packages (if
> available). I'm not sure how hard it would be to implement in your tool,
> but you might take a look if you are interested.
>

What would be the place to pick the signed packages from?

I think this is a great suggestion. The reason it's implemented like this
is because I had no idea where to get those signed packages.



> Secondly, I think this could indeed be handy for folks running rawhide
> or branched, but I worry about people on stable releases mistakenly
> using it and upgrading a chunk of their install to rawhide when they
> didn't realize it would do that. Not sure how to prevent that though,
> perhaps a warning in some cases?
>

I like this suggestion. I opened an upstream issue for that:

https://github.com/TomasTomecek/fed-install/issues/3


> Anyhow, will poke around with the tool and let you know any further
> thoughts. Thanks for sharing!
>
> kevin
>

Thanks Kevin!


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

[modularity] Modularizing the world fast and iteratively

2017-08-23 Thread Adam Samalik

Starting with a summary: Let's 1) use something like dependency-report
scripts [1] to get coordinated, and 2) make the initial builds against
bootstrap so we get a working thing fast and can iterate.

I've realized that developing the initial set of modules for F27 could be a
bit tricky in the beginning as some things might require many basic
dependencies on top of Platform to run and build. These dependencies, like
autotools or dynamic languages for example, need to get modularized first.

In F26 Boltron we had a 'shared-userspace' and 'shared-build-dependencies'
modules that kind of randomly included many of the shared dependencies of
other modules. I don't think that's necessarily terrible (although I'm sure
contyk would argue it is!), but it's not ideal. We should make modules that
represent a thing, like autotools, python2, python3, ruby, gtk2, gtk3, git,
etc. But making all of these modules on a greenfield without a solid base
could be tricky. How do we help people to know what they should include,
and what's going to be somewhere else?

For this, I have written a set of scripts, and already named them badly
'dependency-report' [1]. We have tested it with FreeIPA maintainers to
generate a dependency report [2] for them, and we have already identified
many modules that FreeIPA need as dependencies. I think we could use this
to help us with the initial design.

This brings me to my second thought... to build what we want, we need to
modularize a lot of other stuff. And when we are ready with the initial
design - that means we have identified all the modules we want to have and
all their dependencies, we need to build them. But, for example, a pretty
commonly needed thing like autotools [3] has pretty crazy build
dependencies [4] including Java, gtk2, gtk3, erlang, X11, python2, python3,
etc. And many of these need autotools, of course. We need to do
bootstraping.

So instead of trying to make everything perfect from the begining, we could
build everything we need against the Bootstrap module - a module that is
used as a buildroot for Host and Platform and contains mostly everything we
need. To compare, there is a report without using bootstrap [5] and with
using bootstrap [6]. This way we'll have a pretty decent set of module very
soon.

The next step would be lookin at the build dependencies of these initial
modules, building them against bootstrap, and rebuilding the initial
modules against these new ones. And then do it for the new ones as well,
until we have everything in place.

Also, with this top-down approach, we'll be flexible with the frequent
changes of the Platform module as it's getting stabilized which also makes
the design of the low-level modules nearly impossible right now.

With this approach, we:
1) get coordinated and make modules without conflicts
2) have a working thing very soon
3) can iterate on expanding the base set over time

If you'd like to participate, please feel free to propose your module on
the F27 content plan [7], I'll make you a repository under the
modularity-modules space [8] which serves as an input to the scripts, and
include your module in there.

Cheers!
Adam

[1] https://github.com/fedora-modularity/dependency-report
[2]
https://github.com/fedora-modularity/dependency-report/tree/master/modules/freeipa
[3]
https://github.com/fedora-modularity/dependency-report/tree/original-plan/modules/autotools
[4]
https://github.com/fedora-modularity/dependency-report/blob/original-plan/modules/autotools/all/buildtime-binary-packages-short.txt
[5]
https://github.com/fedora-modularity/dependency-report/tree/original-plan/global_reports
[6]
https://github.com/fedora-modularity/dependency-report/tree/bootstrap/global_reports
[7] https://github.com/fedora-modularity/f27-content-tracking
[8] https://github.com/modularity-modules

Adam Šamalík
---
Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: src.fedoraproject.org, forking projects, PRs

2017-08-23 Thread Wolfgang Stoeggl

Thanks for the hint!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: src.fedoraproject.org, forking projects, PRs

2017-08-23 Thread Dan Horák

On Wed, 23 Aug 2017 07:34:22 -
"Wolfgang Stoeggl"  wrote:

> Hello,
> is forking projects, PRs etc. already supposed to work at
> src.fedoraproject.org? So far, I am getting the following:
> 
> # Source GIT URL: SSH
> git clone ssh://pkgs.fedoraproject.org/forks/c72578/rpms/cacti.git
> Permission denied (publickey).
> # Remark: the ~/.ssh/id_rsa key is present here and working (e.g. for
> # fedpkg)

I had to change the URL to contain my username when I forked FF
ssh://shar...@pkgs.fedoraproject.org/forks/sharkcz/rpms/firefox.git

I guess that's a bug how pagure provides the cloning URL


Dan


> 
> # Source GIT URL: GIT
> git clone https://src.fedoraproject.org/forks/c72578/rpms/cacti.git
> cd cacti
> git push
> fatal: unable to access
> 'https://src.fedoraproject.org/forks/c72578/rpms/cacti.git/': The
> requested URL returned error: 403
> 
> So far, there is documentation on forking projects on pagure.io, what
> about src.fedoraproject.org? e.g.:
> https://fedoraproject.org/wiki/How_to_fix_bugs_on_the_Fedora_Project_website
> https://docs.pagure.org/releng/contributing.html
> 
> Thanks
> Wolfgang
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

src.fedoraproject.org, forking projects, PRs

2017-08-23 Thread Wolfgang Stoeggl

Hello,
is forking projects, PRs etc. already supposed to work at src.fedoraproject.org?
So far, I am getting the following:

# Source GIT URL: SSH
git clone ssh://pkgs.fedoraproject.org/forks/c72578/rpms/cacti.git
Permission denied (publickey).
# Remark: the ~/.ssh/id_rsa key is present here and working (e.g. for fedpkg)

# Source GIT URL: GIT
git clone https://src.fedoraproject.org/forks/c72578/rpms/cacti.git
cd cacti
git push
fatal: unable to access 
'https://src.fedoraproject.org/forks/c72578/rpms/cacti.git/': The requested URL 
returned error: 403

So far, there is documentation on forking projects on pagure.io, what about 
src.fedoraproject.org?
e.g.:
https://fedoraproject.org/wiki/How_to_fix_bugs_on_the_Fedora_Project_website
https://docs.pagure.org/releng/contributing.html

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

[Bug 1484170] perl-Config-Model-Tester-3.002 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Config-Model-Tester-3.
   ||002-1.fc28
   ||perl-Config-Model-Tester-3.
   ||002-1.fc27
 Resolution|--- |RAWHIDE
Last Closed||2017-08-23 03:14:35



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

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

2017-08-23 Thread updates

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 776  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 770  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 660  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 632  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 242  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 138  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-c0d33ae70f   
tnef-1.4.14-1.el6
  40  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e8124f23c8   
heimdal-7.4.0-1.el6
  15  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-87be2d4d20   
potrace-1.15-1.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-938c876edd   
php-PHPMailer-5.2.24-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-035ed8efb3   
qpdf-5.1.1-5.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-3f527c60d9   
firebird-2.5.7.27050.0-1.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-0ad4c424f0   
redis-3.2.10-2.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-01dbc69547   
exim-4.89-2.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-f14c660f60   
tomcat-7.0.81-1.el6


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

cacti-1.1.19-1.el6
distribution-gpg-keys-1.14-1.el6
engauge-digitizer-10.2-1.el6
lldpd-0.9.8-1.el6
php-horde-Horde-Core-2.30.1-1.el6
tomcat-7.0.81-1.el6
zstd-1.3.1-1.el6

Details about builds:



 cacti-1.1.19-1.el6 (FEDORA-EPEL-2017-c28c0c3e0c)
 An rrd based graphing tool

Update Information:

- Update to 1.1.19  Release notes:
https://www.cacti.net/release_notes.php?version=1.1.19    - Update to 1.1.17
Release notes: https://www.cacti.net/release_notes.php?version=1.1.17




 distribution-gpg-keys-1.14-1.el6 (FEDORA-EPEL-2017-a250a81044)
 GPG keys of various Linux distributions

Update Information:

* Add Fedora 28 keys * Add several third parties keys (Adobe, Dell, JPackage,
CalcForge, VirtualBox, PostgreSQL, Skype, Google, Dropbox, Remi) * Add new
Copr's project keys




 engauge-digitizer-10.2-1.el6 (FEDORA-EPEL-2017-c957aa2684)
 Convert graphs or map files into numbers

Update Information:

- Update to 10.2




 lldpd-0.9.8-1.el6 (FEDORA-EPEL-2017-e4dc3d5318)
 ISC-licensed implementation of LLDP

Update Information:

Update to 0.9.8

References:

  [ 1 ] Bug #1483362 - lldpd-0.9.8 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1483362




 php-horde-Horde-Core-2.30.1-1.el6 (FEDORA-EPEL-2017-4bd24554b3)
 Horde Core Framework libraries

Update Information:

**Horde_Core 2.30.1**  * [mjr] Fix issue that could break ActiveSync sync if
object not found.




 tomcat-7.0.81-1.el6 (FEDORA-EPEL-2017-f14c660f60)
 Apache Servlet/JSP Engine, RI for Servlet 3.0/JSP 2.2 API

Update Information:

This update includes a rebase from 7.0.78 up to 7.0.81 which resolves a single
CVE along with various other bugs/features:  - rh#1480621 CVE-2017-7674 tomcat:
Cache Poisoning

References:

  [ 1 ] Bug #1480621 - CVE-2017-7674 tomcat: Cache Poisoning [epel-6]
https://bugzilla.redhat.com/show_bug.cgi?id=1480621

[Bug 1479680] perl-Time-OlsonTZ-Download-0.006 is available

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



--- Comment #13 from Fedora Update System  ---
perl-Time-OlsonTZ-Download-0.006-2.fc25 has been pushed to the Fedora 25 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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 1477175] fusioninventory-agent-2.3.21 is available