Re: Proposed mass bug filing for webkitgtk/webkitgtk3 package removal

[Michael Catanzaro]

On Tue, 2016-09-13 at 23:26 -0500, Michael Catanzaro wrote:
> I've started filing bugs and will continue throughout the week.
> 
> Michael

Well nevermind that, I'm (mostly) finished:

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

The one thing I did not do was file individual bugs for all of the
dependencies of wxGTK3. There are quite a few. Anyone know if this
package will be ported to WebKit2? If it's likely to happen, then we
probably don't need to file bugs for its dependencies as most of them
won't need to change anything. But if it's not likely to happen in
time, then I will file bugs for its dependencies to let them know they
are in trouble and should look into helping wxGTK3.

Michael
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fedora Rawhide-20160913.n.2 compose check report

[Fedora compose checker]

Missing expected images:

Cloud_base raw-xz i386
Atomic raw-xz x86_64

Failed openQA tests: 10/92 (x86_64), 4/17 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20160913.n.1):

ID: 34248   Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/34248
ID: 34251   Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/34251
ID: 34349   Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/34349

Old failures (same test failed in Rawhide-20160913.n.1):

ID: 34241   Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/34241
ID: 34242   Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/34242
ID: 34250   Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/34250
ID: 34252   Test: x86_64 Atomic-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/34252
ID: 34261   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/34261
ID: 34307   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/34307
ID: 34321   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/34321
ID: 34326   Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/34326
ID: 34329   Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/34329
ID: 34346   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/34346
ID: 34347   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/34347
ID: 34351   Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/34351

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

New soft failures (same test did not softfail in Rawhide-20160913.n.1):

ID: 34253   Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/34253

Passed openQA tests: 76/92 (x86_64), 13/17 (i386)

Skipped openQA tests: 6 of 111
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1375826] New: perl-Gtk2-WebKit will be removed with webkitgtk

[bugzilla]

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

Bug ID: 1375826
   Summary: perl-Gtk2-WebKit will be removed with webkitgtk
   Product: Fedora
   Version: rawhide
 Component: perl-Gtk2-WebKit
  Assignee: fed...@famillecollet.com
  Reporter: mcatanz...@gnome.org
QA Contact: extras...@fedoraproject.org
CC: fed...@famillecollet.com,
perl-devel@lists.fedoraproject.org
Blocks: 1375784 (webkit1-removal)



The webkitgtk package will be removed from rawhide after Fedora 26 is branched
due to the high number of unfixed security vulnerabilities. You must remove
this dependency or your package will not be present in Fedora 27.

Please refer to [1] for a FAQ on this matter and be advised that for some
packages this may require a substantial amount of work.

Note: I presume perl-Gtk2-WebKit is a bindings package specifically intended to
provide WebKit bindings for GTK+ 2 bindings, so there's nothing to be done here
except retire the package. This bug is just to serve as a heads-up.

[1]
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/AKVB363GFCHHJ5MTHGVYHYT6NLLTF5VM/


Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1375784
[Bug 1375784] Port applications to WebKit2
-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: F24, small backward steps

[Peter Hutterer]

On Fri, Sep 09, 2016 at 03:53:06PM -0400, Roger Wells wrote:
> Just a couple of smallish things after upgrading (via dnf) from F23 to
> F24 a couple of months ago:
> 
> 1. deja-dup gui:
> 
> one has to deselect then reselect the Overview option in order
> to be offered the "Backup Now" option.
> 
> The details option in the progress dialog will only display two
> or three lines, is not resizeable, and does not follow resizing the
> entire dialog
> 
> The progress dialog does not wait to be dismissed at the end,
> causing any messages about problems (like failure to backup a particular
> file) to not be seen
> 
> 2. fingerprint identification:
> 
> The laptop has a fingerprint reader and it works fine.  However
> I prefer not to use it. The user set up specifies that fingerprint login
> is disabled.
> 
> However whenever I am asked for a password the fingerprint
> reader blinks until I swipe a finger over it (even after using a
> password). 
> 
> No fingerprint is registered.
> 
> This is different than F23 where it never blinked.
> 
> 3. Scrolling issues:
> 
> This, edge and natural scrolling via the touchpad, was covered
> nicely in a previous thread. 
> 
> Solutions offered there work well but should be better
> integrated as I am sure they will be.

what was the problem here? can you point me to the original thread?

Cheers,
   Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora 25-20160911.n.0 compose check report

[Adam Williamson]

On Mon, 2016-09-12 at 10:08 -0700, Adam Williamson wrote:
> On Mon, 2016-09-12 at 00:39 +, Fedora compose checker wrote:
> Missing expected images:
> 
> 
> Cloud_base raw-xz i386
> Atomic raw-xz x86_64
> 
> 
> Failed openQA tests: 12/92 (x86_64), 2/17 (i386), 1/2 (arm)
> 
> 
> 
> 
> Sorry, I'm not sure why these emails are getting duplicated lately;
> I'll look into it...
> 

So at least the one that got duplicated today happened because a test
got stuck in a kind of 'zombie' state when it was closing out; the
server didn't exactly count that test as running any more, so when the
last test apart from that one finished, the 'remaining tests' counter
that triggers the report went to 0 and the report was sent...but when
that test finally timed out and died for real, that generated another
'test complete' fedmsg with a 'remaining' count of 0, so the mail was
sent again.

I'll talk to upstream and see if we can identify the bug and get it
fixed. I could teach the compose check report sender to keep a record
of what composes it's sent mails for and refuse to duplicate reports
without a manual override, but it'd make it a bit messier so I'll only
do that if we can't fix the openQA bug soon...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Proposed mass bug filing for webkitgtk/webkitgtk3 package removal

[Michael Catanzaro]

On Mon, 2016-09-05 at 08:36 -0500, Michael Catanzaro wrote:
> > I propose to carry out a mass bug filing with the bug title:
> "Remove
> > webkitgtk/webkitgtk3 dependency" (depending on which package is
> > dependend on) and following text:

I've started filing bugs and will continue throughout the week.

Michael
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fedora Rawhide-20160913.n.2 compose check report

[Fedora compose checker]

Missing expected images:

Cloud_base raw-xz i386
Atomic raw-xz x86_64

Failed openQA tests: 10/92 (x86_64), 4/17 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20160913.n.1):

ID: 34248   Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/34248
ID: 34251   Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/34251
ID: 34349   Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/34349

Old failures (same test failed in Rawhide-20160913.n.1):

ID: 34241   Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/34241
ID: 34242   Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/34242
ID: 34250   Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/34250
ID: 34252   Test: x86_64 Atomic-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/34252
ID: 34261   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/34261
ID: 34307   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/34307
ID: 34321   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/34321
ID: 34326   Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/34326
ID: 34329   Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/34329
ID: 34346   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/34346
ID: 34347   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/34347
ID: 34351   Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/34351

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

New soft failures (same test did not softfail in Rawhide-20160913.n.1):

ID: 34253   Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/34253

Passed openQA tests: 76/92 (x86_64), 13/17 (i386)

Skipped openQA tests: 6 of 111
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fedora Rawhide-20160913.n.2 compose check report

[Fedora compose checker]

Missing expected images:

Cloud_base raw-xz i386
Atomic raw-xz x86_64

Failed openQA tests: 10/92 (x86_64), 4/17 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20160913.n.1):

ID: 34248   Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/34248
ID: 34251   Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/34251
ID: 34349   Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/34349

Old failures (same test failed in Rawhide-20160913.n.1):

ID: 34241   Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/34241
ID: 34242   Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/34242
ID: 34250   Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/34250
ID: 34252   Test: x86_64 Atomic-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/34252
ID: 34261   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/34261
ID: 34307   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/34307
ID: 34321   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/34321
ID: 34326   Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/34326
ID: 34329   Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/34329
ID: 34346   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/34346
ID: 34347   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/34347
ID: 34351   Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/34351

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

New soft failures (same test did not softfail in Rawhide-20160913.n.1):

ID: 34253   Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/34253

Passed openQA tests: 76/92 (x86_64), 13/17 (i386)

Skipped openQA tests: 6 of 111
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fedora Rawhide-20160913.n.2 compose check report

[Fedora compose checker]

Missing expected images:

Cloud_base raw-xz i386
Atomic raw-xz x86_64

Failed openQA tests: 10/92 (x86_64), 4/17 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20160913.n.1):

ID: 34248   Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/34248
ID: 34251   Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/34251
ID: 34349   Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/34349

Old failures (same test failed in Rawhide-20160913.n.1):

ID: 34241   Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/34241
ID: 34242   Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/34242
ID: 34250   Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/34250
ID: 34252   Test: x86_64 Atomic-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/34252
ID: 34261   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/34261
ID: 34307   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/34307
ID: 34321   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/34321
ID: 34326   Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/34326
ID: 34329   Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/34329
ID: 34346   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/34346
ID: 34347   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/34347
ID: 34351   Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/34351

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

New soft failures (same test did not softfail in Rawhide-20160913.n.1):

ID: 34253   Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/34253

Passed openQA tests: 76/92 (x86_64), 13/17 (i386)

Skipped openQA tests: 6 of 111
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora Rawhide-20160913.n.2 compose check report

[Adam Williamson]

On Wed, 2016-09-14 at 03:37 +, Fedora compose checker wrote:
> Missing expected images:
> 
> 
> Cloud_base raw-xz i386
> Atomic raw-xz x86_64
> 
> 
> Failed openQA tests: 10/92 (x86_64), 4/17 (i386), 1/2 (arm)
> 
> 
> New failures (same test did not fail in Rawhide-20160913.n.1):
> 
> 
> ID: 34248 Test: x86_64 Workstation-boot-iso install_default
> URL: https://openqa.fedoraproject.org/tests/34248
> ID: 34251 Test: i386 Workstation-boot-iso install_default
> URL: https://openqa.fedoraproject.org/tests/34251
> ID: 34349 Test: x86_64 Workstation-boot-iso install_default@uefi
> URL: https://openqa.fedoraproject.org/tests/34349

These are just because the network install image uses the default
repositories, so when it ran on 0913.n.1 those still contained the
older packages which didn't have the getting-started bug. When it ran
on 0913.n.2 the repos had been updated, so these three tests now hit
that bug too.

I've reported that bug as:
https://bugzilla.gnome.org/show_bug.cgi?id=771393
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fedora Rawhide-20160913.n.2 compose check report

[Fedora compose checker]

Missing expected images:

Cloud_base raw-xz i386
Atomic raw-xz x86_64

Failed openQA tests: 10/92 (x86_64), 4/17 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20160913.n.1):

ID: 34248   Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/34248
ID: 34251   Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/34251
ID: 34349   Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/34349

Old failures (same test failed in Rawhide-20160913.n.1):

ID: 34241   Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/34241
ID: 34242   Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/34242
ID: 34250   Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/34250
ID: 34252   Test: x86_64 Atomic-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/34252
ID: 34261   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/34261
ID: 34307   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/34307
ID: 34321   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/34321
ID: 34326   Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/34326
ID: 34329   Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/34329
ID: 34346   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/34346
ID: 34347   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/34347
ID: 34351   Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/34351

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

New soft failures (same test did not softfail in Rawhide-20160913.n.1):

ID: 34253   Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/34253

Passed openQA tests: 76/92 (x86_64), 13/17 (i386)

Skipped openQA tests: 6 of 111
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[389-devel] Please review: 59, 45 nunc-stans

[William Brown]

https://fedorahosted.org/nunc-stans/ticket/59#comment:4

https://fedorahosted.org/nunc-stans/attachment/ticket/59/0001-Ticket-59-Heap-use-after-free-in-ns_job_done.4.patch

Add the extra assert as per Noriko's advice.

https://fedorahosted.org/nunc-stans/ticket/45

https://fedorahosted.org/nunc-stans/attachment/ticket/45/0001-Ticket-45-Upgrade-liblfds-to-710.patch

Upgrade lfds to lfds710. Passes all tests, plus passes ldclt with DS. 

Next step after this is replace the ASSERT in a few functions with
something more permanent (PR_ASSERT relies on -DDEBUG to work), so we
can catch errors in runtime. 



-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane


signature.asc
Description: This is a digitally signed message part
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

[EPEL-devel] Re: Requirements for SRPM names

[Dennis Gilmore]

On Tuesday, September 13, 2016 11:54:41 PM CDT Peter Robinson wrote:
> >> I'm looking for some clarification on the naming requirements for
> >> SRPMs.
> >> 
> >> In the EPEL 7 in Python 3 Plan Draft [1], it specifies that SRPM names
> >> can't conflict with RHEL SRPM names, but in the Limited Arch Packages
> >> [2]section of EPEL: Packaging, it seems to imply the SRPM name would
> >> be the same, but the release number would be pretended with "0.".
> >> 
> >> Could someone please clarify?
> >> 
> >> If, in fact, the name can be the same, it will make it much easier to
> >> provide Python 3 packages for EPEL since a separate package would not
> >> be required in the Fedora Package DB.
> > 
> > So, here's the thing (at least as I understand it):
> > 
> > koji operates on source packages.
> > 
> > If there's a package in RHEL called 'foo' and also one in EPEL called
> > 'foo' it will use the epel one in all cases for everything that foo
> > makes.
> 
> Is that the case with external repos? I didn't think it was that smart
> in that case, but I'm tired so might be mis-remembering.
It 100% is the case. Koji treats external repos exactly the same as internal.  
it even taks special care to ensure that all binary rpms for a given srpm are 
included even if the binary rpms are spread acorss different external repos

> > So, with the limited arch packages this means that _ALL_ things
> > building in koji will use the epel package. The reason for the
> > prepended 0 is so that users don't install the epel package and instead
> > get the newer rhel version. The limited arch guideline also says you
> > should try and keep the package as close as possible to the rhel
> > version.
> 
> For el7, and even in some of the big (java*) use cases in el6 the
> delta in packages between the arches is getting a lot less, and I
> believe this will be more so as we move forward in el7.
I honestly am not sure there is any limited arch packages in epel7 

> > So, if we had say: python-foobar-1.0-1.el7.src.rpm in rhel that made a
> > python-foobar-1.0-1.noarch.rpm and then we made a epel
> > python-foobar-1.0-1.el7.src.rpm that had
> > python3-foobar-1.0-1.noarch.rpm it would mean anything that builds
> > against python-foobar in epel would break (it would be not found). End
> > users would be ok, but buildroots could be broken by it.
> > 
> > So we are kinda in a lerch here... I think the best way is just new
> > packages with python3-whatever.
> > 
> > kevin
> > 
> > 
> > 
> > ___
> > epel-devel mailing list
> > epel-devel@lists.fedoraproject.org
> > https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject
> > .org
> ___
> epel-devel mailing list
> epel-devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.o
> rg

___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Requirements for SRPM names

[Dennis Gilmore]

On Tuesday, September 13, 2016 5:35:29 PM CDT Neal Gompa wrote:
> On Tue, Sep 13, 2016 at 5:26 PM, Kevin Fenzi  wrote:
> > On Tue, 13 Sep 2016 14:13:44 -0400
> > 
> > Avram Lubkin  wrote:
> >> I'm looking for some clarification on the naming requirements for
> >> SRPMs.
> >> 
> >> In the EPEL 7 in Python 3 Plan Draft [1], it specifies that SRPM names
> >> can't conflict with RHEL SRPM names, but in the Limited Arch Packages
> >> [2]section of EPEL: Packaging, it seems to imply the SRPM name would
> >> be the same, but the release number would be pretended with "0.".
> >> 
> >> Could someone please clarify?
> >> 
> >> If, in fact, the name can be the same, it will make it much easier to
> >> provide Python 3 packages for EPEL since a separate package would not
> >> be required in the Fedora Package DB.
> > 
> > So, here's the thing (at least as I understand it):
> > 
> > koji operates on source packages.
> > 
> > If there's a package in RHEL called 'foo' and also one in EPEL called
> > 'foo' it will use the epel one in all cases for everything that foo
> > makes.
> > 
> > So, with the limited arch packages this means that _ALL_ things
> > building in koji will use the epel package. The reason for the
> > prepended 0 is so that users don't install the epel package and instead
> > get the newer rhel version. The limited arch guideline also says you
> > should try and keep the package as close as possible to the rhel
> > version.
> > 
> > So, if we had say: python-foobar-1.0-1.el7.src.rpm in rhel that made a
> > python-foobar-1.0-1.noarch.rpm and then we made a epel
> > python-foobar-1.0-1.el7.src.rpm that had
> > python3-foobar-1.0-1.noarch.rpm it would mean anything that builds
> > against python-foobar in epel would break (it would be not found). End
> > users would be ok, but buildroots could be broken by it.
> > 
> > So we are kinda in a lerch here... I think the best way is just new
> > packages with python3-whatever.
> 
> That doesn't make sense. Builds are done by pulling in base, epel, and
> buildroot repositories into a generated mock config and executed (i.e.
> passed to mock to build the SRPM and then the RPMs). No part of mock
> would have a problem here. Therefore, there is no reason for the
> absurdity of having python3-* SRPMs.
> 
> Sure, Koji operates on SRPMs, but Fedora Koji does not build RHEL or
> CentOS. So this particular problem doesn't exist from that perspective
> either. Content from RHEL/CentOS essentially is a black box to Koji.

The koji repos will only include binary packages from exactly one source rpm 
of a given name. koji builds its own repos and does not use the repos in the 
way you think and you would at home. Koji was tought to treat external repos 
exactly the same as internal repos. Net result being if you rebuild python-foo 
to get a python3 build you will have to also build python2 version and ensure 
that the nvr is lower. The only realistic option given that there will be 
python3 mass rebuilds as python versions change is to have python3 specific 
srpms

Dennis
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Fedora rawhide compose report: 20160913.n.2 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20160913.n.1
NEW: Fedora-Rawhide-20160913.n.2

= SUMMARY =
Added images:4
Dropped images:  0
Added packages:  0
Dropped packages:32
Upgraded packages:   40
Downgraded packages: 0

Size of added packages:  0.00 B
Size of dropped packages:66.00 MiB
Size of upgraded packages:   135.04 MiB
Size of downgraded packages: 0.00 B

Size change of upgraded packages:   -14.48 MiB
Size change of downgraded packages: 0.00 B

= ADDED IMAGES =
Image: Xfce live x86_64
Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-Rawhide-20160913.n.2.iso
Image: Xfce live i386
Path: Spins/i386/iso/Fedora-Xfce-Live-i386-Rawhide-20160913.n.2.iso
Image: Design_suite live i386
Path: Labs/i386/iso/Fedora-Design_suite-Live-i386-Rawhide-20160913.n.2.iso
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20160913.n.2.iso

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: and-1.2.2-24.fc24
Summary: Auto nice daemon
RPMs:and
Size:124374 bytes

Package: cvsclient-71-4.jenkins11.fc24
Summary: CVS library for Java
RPMs:cvsclient cvsclient-javadoc
Size:768168 bytes

Package: dbmail-3.2.3-3.fc24
Summary: A database backed mail storage system
RPMs:dbmail dbmail-auth-ldap
Size:1204776 bytes

Package: dwatch-0.1.1-18.fc24
Summary: A program that watches over other programs
RPMs:dwatch
Size:74134 bytes

Package: elementary-1.17.1-2.fc25
Summary: Basic widget set that is easy to use based on EFL
RPMs:elementary elementary-devel
Size:40097372 bytes

Package: firecontrol-0.2-15.fc24
Summary: A console oriented tool for Linux to access a FireWire bus
RPMs:firecontrol
Size:78702 bytes

Package: ghc-editline-0.2.1.1-13.fc25
Summary: Bindings to the libedit library
RPMs:ghc-editline ghc-editline-devel
Size:303360 bytes

Package: ghc-primes-0.2.1.0-10.fc25
Summary: Efficient, purely functional generation of prime numbers
RPMs:ghc-primes ghc-primes-devel
Size:253820 bytes

Package: glusterfs-hadoop-2.3.2-7.fc24
Summary: GlusterFS Hadoop Compatible File System (HCFS) plugin
RPMs:glusterfs-hadoop glusterfs-hadoop-javadoc
Size:94872 bytes

Package: gnome-password-generator-1.6-13.fc24
Summary: Graphical secure password generator
RPMs:gnome-password-generator
Size:33194 bytes

Package: gnustep-back-0.24.0-4.fc24
Summary: The GNUstep back-end library
RPMs:gnustep-back
Size:1922954 bytes

Package: gnustep-examples-1.3.0-25.fc24
Summary: The GNUstep examples
RPMs:gnustep-examples
Size:730638 bytes

Package: gnustep-gui-0.24.0-6.fc25
Summary: The GNUstep GUI library
RPMs:gnustep-gui gnustep-gui-devel gnustep-gui-doc gnustep-gui-libs
Size:8576796 bytes

Package: gorm-1.2.20-3.fc24
Summary: The GNUstep graphical interface builder
RPMs:gorm gorm-devel gorm-doc
Size:2603754 bytes

Package: gresolver-0.0.5-17.fc25
Summary: Graphical DNS query tool
RPMs:gresolver
Size:30490 bytes

Package: js-jquery-migrate-1.2.1-6.fc23
Summary: APIs and features removed from jQuery core
RPMs:js-jquery-migrate
Size:25728 bytes

Package: kaya-0.5.2-24.fc22
Summary: A Statically typed, imperative programming-language
RPMs:kaya kaya-doc
Size:6299220 bytes

Package: latex2emf-1.0.0-15.fc24
Summary: Create an EMF file from LaTeX source
RPMs:latex2emf
Size:78030 bytes

Package: libsieve-2.3.1-5.fc24
Summary: A library for parsing, sorting and filtering your mail
RPMs:libsieve libsieve-devel
Size:310692 bytes

Package: luma-3.0.7-7.fc25
Summary: A graphical tool for managing LDAP servers
RPMs:luma
Size:1102514 bytes

Package: netmonitor-0.5-17.fc24
Summary: The free linux network bandwidth monitor
RPMs:netmonitor
Size:90782 bytes

Package: open-cobol-1.1-5.fc24
Summary: OpenCOBOL - COBOL compiler
RPMs:libcob open-cobol
Size:996956 bytes

Package: phpMemcachedAdmin-1.2.2-11.svn262.fc24
Summary: Graphic stand-alone administration for memcached to monitor and debug 
purpose
RPMs:phpMemcachedAdmin
Size:50930 bytes

Package: picprog-1.9.1-12.fc24
Summary: Microchip PIC serial programmer software
RPMs:picprog
Size:165976 bytes

Package: polipo-1.1.1-4.fc24
Summary: Lightweight caching web proxy
RPMs:polipo
Size:675782 bytes

Package: psgml-1.2.5-20.fc24
Summary: GNU Emacs major mode for editing SGML documents
RPMs:psgml
Size:152286 bytes

Package: pypop-0.7.0-17.fc25
Summary: Python for Population Genomics
RPMs:pypop
Size:768494 bytes

Package: queuegraph-1.1-24.fc25
Summary: A RRDtool frontend for Mail statistics
RPMs:queuegraph queuegraph-selinux
Size:32872 bytes

Package: rhncfg-5.10.93-1.fc25
Summary: Spacewalk Configuration Client Libraries
RPMs:rhncfg rhncfg-actions rhncfg-client rhncfg-management
Size:229260 bytes

Package: snobol-4.1.5-9.fc24
Summary: The SNOBOL programming language
RPMs:snobol
Size:642198 bytes

Re: Video performance degradation in F24

[Basil Mohamed Gohar]

On 09/12/2016 01:21 PM, Zdenek Kabelac wrote:
> Dne 12.9.2016 v 17:48 Basil Mohamed Gohar napsal(a):
>> On 09/11/2016 02:19 PM, stan wrote:
>>> On Sat, 10 Sep 2016 22:04:22 -0400
>>> Basil Mohamed Gohar  wrote:
>>>
>>>
> On 09/08/2016 03:44 AM, Basil Mohamed Gohar wrote:
>> Even since I installed F24 on both my desktop as well as my laptop
>> I've noticed a severe performance degradation in terms of video
>> playback.
>>>
>>> Is this using a browser, or a player on the system, like vlc or mplayer?
>>> What does your 'severe performance degradation' consist of?  Dropped
>>> frames?  Lock up?  Artifacts?  Could network congestion or speed be a
>>> factor?  Or do you just mean that the gui is slow to respond?
>>>
>>
>> I've noticed this performance issue in both MATE (my preferred DE)
>> as well as Gnome.  I have AMD CPUs with AMD GPUs (the laptop is an
>> APU but also has a discrete card as well).
>>
>> I don't want to use devel just to report a problem, but I'd also
>>>
>>> This really belongs on users.  You can subscribe to users by
>>> sending an email message to
>>> users-requ...@lists.fedoraproject.org
>>> with subscribe in the subject line, and from email address
>>> basilgo...@librevideo.org
>>>
>> like some help in diagnosing the issue so that a fix can be found
>> – but unfortunately I don't really know where to start.
>>>
>>> What does top show happening on your system when you notice the problem?
>>> How about iotop?  Is there lots of disk usage happening? Are there
>>> things like locate or other search aids running in the background to
>>> update their databases?  Are you updating your system when it seems
>>> slow? Is your system memory constrained?  Other cron scheduled jobs?
>>> This usually is really heavy early in system usage as they build their
>>> databases, and then tapers off as only incremental changes are made.
>>>
>>> It's unlikely to be due to F24, more likely to be due to your situation.
> 
> Personally I'm also interested why the video playback  in Firefox is so
> horrible.
> 
> I'm using C2D - this is easily capable to play high bitrate FullHD
> movies in mplayer.
> 
> Yet it gets chooked by quite low-bandwidth low quality 640-pixel-wide
> videos from Youtube.
> 
> Doesn't really matter much if the native h265 codec is used or it's
> passed through the oldish 'flash' adobe plugin.
> 
> Looking at 'perf' trace - it obviously spends ages in libxul -  and it's
> very quickly passing though ffmpeg library used now by 'ff'.
> 
> There is some 'minor' difference between   h265/flash playback
> smoothness - but none of them is NOWHERE near to be usable.
> 
> So whenever I want to see a video playing fluently without using some
> later 4x3GHz i7 CPU -  I simply need to download video and play via
> mplayer
> 
> I'd love to see some progress here - but it's getting worst with each
> new relase of FF - not mentionion  'FF' starts to cut interfaces so less
> and less plugins do work. And no I see zero interest of 'ff' group to
> solve this issue for Linux - they mostly care purely about windows these
> days :(
> 
> 
> And of course horrible playback is in '-safe-mode' as well - so no
> plugin could be accused for this. As well as I'm using -nodebug Fedora
> kernels
> and latest/greatest  SNA xf86 driver.
> 
> Regards
> 
> Zdenek

Funny, mplayer by default has the same or similar stuttering that I see
in Totem and Firefox.  I haven't tried with different draw/acceleration
methods (there are plenty), so it's whatever's being used by default.

Again, to contrast, VLC video playback is smooth as butter.


-- 
Libre Video
http://librevideo.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Broken dependencies: perl-Data-Alias

[buildsys]

perl-Data-Alias has broken dependencies in the rawhide tree:
On x86_64:
perl-Data-Alias-1.20-2.fc24.x86_64 requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.x86_64 requires perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-Data-Alias-1.20-2.fc24.i686 requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.i686 requires perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-Data-Alias-1.20-2.fc24.armv7hl requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.armv7hl requires perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1375103] perl-App-Daemon missing in EPEL7

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-App-Daemon-0.22-6.el7 has been pushed to the Fedora EPEL 7 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-EPEL-2016-58ac381290

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 555  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 317  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
  80  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e0c08a1414   
php-PHPMailer-5.2.16-2.el7
  35  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-23fa04bf1c   
redis-3.2.3-1.el7
  34  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-4b8dd3488d   
knot-1.6.8-1.el7
  19  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e8f4ff76b3   
chicken-4.11.0-3.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-c1dbac22db   
elog-3.1.1-7.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-2a2061ee5f   
php-adodb-5.15-10.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-7e2d0ee701   
wordpress-4.6.1-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-12c4b7b928   
php-horde-Horde-Core-2.26.1-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-c7c4c1e885   
php-horde-Horde-Mime-Viewer-2.2.1-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-175e2d3d7c   
php-horde-Horde-Text-Filter-2.3.5-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-f71c0650c3   
php-horde-horde-5.2.12-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-77f23b948f   
GraphicsMagick-1.3.25-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-0e40142bd3   
pdns-3.4.10-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-6d70ae9a57   
chromium-53.0.2785.101-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-24caa7d205   
drupal7-google_analytics-2.3-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-f1d880ae22   
distribution-gpg-keys-1.7-1.el7 mock-1.2.21-1.el7


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

awscli-1.10.62-1.el7
composer-1.2.1-1.el7
distribution-gpg-keys-1.7-1.el7
hitch-1.4.0-1.el7
libuv-1.9.1-1.el7
mock-1.2.21-1.el7
nodejs-6.5.0-104.el7
perl-App-Daemon-0.22-6.el7
php-myclabs-deep-copy-1.5.3-1.el7
php-udan11-sql-parser-3.4.6-1.el7
python-boto3-1.4.0-1.el7
python-botocore-1.4.52-3.el7
python-impacket-0.9.15-4.el7
python-s3transfer-0.1.3-1.el7
qmapshack-1.7.1-1.el7
yamllint-1.3.2-2.el7

Details about builds:



 awscli-1.10.62-1.el7 (FEDORA-EPEL-2016-11fa3f8e0e)
 Universal Command Line Environment for AWS

Update Information:

Update to the aws stack :)




 composer-1.2.1-1.el7 (FEDORA-EPEL-2016-ee761a7b69)
 Dependency Manager for PHP

Update Information:

**Version 1.2.1** - 2016-09-12* Fixed edge case issues with the static
autoloader   * Minor fixes




 distribution-gpg-keys-1.7-1.el7 (FEDORA-EPEL-2016-f1d880ae22)
 GPG keys of various Linux distributions

Update Information:

* Security fix for CVE-2016-6299 * Additionally GPG key for Mageia has been
renamed

References:

  [ 1 ] Bug #1375490 - CVE-2016-6299 mock: privilige escalation via mock-scm
https://bugzilla.redhat.com/show_bug.cgi?id=1375490




 hitch-1.4.0-1.el7 (FEDORA-EPEL-2016-21d423ff88)
 Network proxy that terminates TLS/SSL connections

Update Information:

New upstream release, a feature release:  - NPN/ALPN support for negotiating a
protocol in the SSL handshake - PROXY protocol support for communicating an
ALPN/NPN negotiated protocol to the backend  Also some bugfixes, see the
CHANGES.rst included in the package, or upstream at
https://github.com/varnish/hitch/blob/master/CHANGES.rst




 libuv-1.9.1-1.el7 (FEDORA-EPEL-2016-8f6ed4db26)
 Platform layer for node.js

Update Information:

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 433  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 427  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 358  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8156   
nagios-4.0.8-1.el6
 317  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 289  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 174  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-30a8346813   
vtun-3.0.1-10.el6
  80  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-db7e78fac7   
php-PHPMailer-5.2.16-2.el6
  73  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-d0e444c5f2   
pypy-5.0.1-4.el6
  34  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-a1450d7fe0   
knot-1.6.8-1.el6
  19  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-8594ed3a53   
chicken-4.11.0-3.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-eb5607d339   
wordpress-4.6.1-1.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-0e948eb4e8   
php-horde-Horde-Core-2.26.1-1.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e2038f5db3   
php-horde-Horde-Mime-Viewer-2.2.1-1.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-d4f645229a   
php-horde-Horde-Text-Filter-2.3.5-1.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-665fb50899   
php-horde-horde-5.2.12-1.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-4b16af69a6   
varnish-2.1.5-6.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-f2d60f53f3   
GraphicsMagick-1.3.25-1.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-bcc7555c8a   
drupal7-google_analytics-2.3-1.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-204f2f07aa   
drupal7-panels-3.7-1.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e079d167e3   
distribution-gpg-keys-1.7-1.el6 mock-1.2.21-1.el6


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

distribution-gpg-keys-1.7-1.el6
hitch-1.4.0-1.el6
mock-1.2.21-1.el6
pcllib-1.12-1.el6

Details about builds:



 distribution-gpg-keys-1.7-1.el6 (FEDORA-EPEL-2016-e079d167e3)
 GPG keys of various Linux distributions

Update Information:

* Security fix for CVE-2016-6299 * Additionally GPG key for Mageia has been
renamed

References:

  [ 1 ] Bug #1375490 - CVE-2016-6299 mock: privilige escalation via mock-scm
https://bugzilla.redhat.com/show_bug.cgi?id=1375490




 hitch-1.4.0-1.el6 (FEDORA-EPEL-2016-425b747114)
 Network proxy that terminates TLS/SSL connections

Update Information:

New upstream release, a feature release:  - NPN/ALPN support for negotiating a
protocol in the SSL handshake - PROXY protocol support for communicating an
ALPN/NPN negotiated protocol to the backend  Also some bugfixes, see the
CHANGES.rst included in the package, or upstream at
https://github.com/varnish/hitch/blob/master/CHANGES.rst




 mock-1.2.21-1.el6 (FEDORA-EPEL-2016-e079d167e3)
 Builds packages inside chroots

Update Information:

* Security fix for CVE-2016-6299 * Additionally GPG key for Mageia has been
renamed

References:

  [ 1 ] Bug #1375490 - CVE-2016-6299 mock: privilige escalation via mock-scm
https://bugzilla.redhat.com/show_bug.cgi?id=1375490




 pcllib-1.12-1.el6 (FEDORA-EPEL-2016-62ed1d7108)
 Portable Coroutine Library (PCL)

Update Information:

Initial version of the package

___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[Bug 1372510] perl-Sys-Syslog-0.35 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Sys-Syslog-0.35-1.fc26 |perl-Sys-Syslog-0.35-1.fc26
   |perl-Sys-Syslog-0.35-1.fc25 |perl-Sys-Syslog-0.35-1.fc25
   |perl-Sys-Syslog-0.35-1.fc24 |perl-Sys-Syslog-0.35-1.fc24
   ||perl-Sys-Syslog-0.35-1.fc23



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1372504] perl-Sereal-Decoder-3.015 is available

[bugzilla]

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



--- Comment #15 from Fedora Update System  ---
perl-Sereal-Decoder-3.015-1.fc23 has been pushed to the Fedora 23 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.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1372504] perl-Sereal-Decoder-3.015 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Sereal-Decoder-3.015-1 |perl-Sereal-Decoder-3.015-1
   |.fc26   |.fc26
   |perl-Sereal-Decoder-3.015-1 |perl-Sereal-Decoder-3.015-1
   |.fc25   |.fc25
   |perl-Sereal-Decoder-3.015-1 |perl-Sereal-Decoder-3.015-1
   |.fc24   |.fc24
   ||perl-Sereal-Decoder-3.015-1
   ||.fc23



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1372510] perl-Sys-Syslog-0.35 is available

[bugzilla]

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



--- Comment #13 from Fedora Update System  ---
perl-Sys-Syslog-0.35-1.fc23 has been pushed to the Fedora 23 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.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[EPEL-devel] Re: Requirements for SRPM names

[Stephen John Smoogen]

On 13 September 2016 at 17:14, Avram Lubkin  wrote:
> On Tue, Sep 13, 2016 at 2:28 PM, Stephen John Smoogen 
> wrote:
>>
>>
>> The reasoning for needing a python3-foobaz is that we don't replace
>> the python2 version of foobaz with a package which does not work at
>> all with the python2 installed and possibly breaks an existing app.
>
>
> You seem to be talking about RPM names and not SRPM names. By convention,
> any Python 3 package for EPEL7 would actually be python34-package. The point
> of this thread is to discuss SRPM names and if python34-package can be built
> from a SPRM package named python-package like in Fedora. Since python2 and
> python3 packages are generally built from the same source and spec, the SRPM
> and Fedora Git repo are usually not versioned. The problem is when a python2
> package exists in RHEL, but we want to supply a python34 package. The draft
> guidelines (which are the only ones we have) say this is a conflict, but it
> seems that is not stated anywhere in the EPEL guidelines. The main problem
> this creates is very few python34 packages get created because people don't
> want to maintain multiple repos for the same thing.
>

You are right, I was not correctly thinking when I wrote that. Part of
my brain was assuming that you would be pulling in newer versions of
python-foobaz since usually the stuff in RHEL is considered old and
decrepit for people wanting python3.  The one issue I can see with
using the python-foobaz-1.3-0.1.epel.src.rpm is that it is going to
cause problems for CentOS builders/users in that the spec file for the
CentOS package is going to conflict with the EPEL one.. but that is
just a concern that I would want the CentOS members to talk about.

> As far as the limited arch packages, I bring that up because it seems from
> the guidelines their SRPM name would be the same as the one in RHEL. If that
> is acceptable there, it likely should be for python packages.
>
> Avram
>
>
>
> ___
> epel-devel mailing list
> epel-devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
>



-- 
Stephen J Smoogen.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Requirements for SRPM names

[Peter Robinson]

>> I'm looking for some clarification on the naming requirements for
>> SRPMs.
>>
>> In the EPEL 7 in Python 3 Plan Draft [1], it specifies that SRPM names
>> can't conflict with RHEL SRPM names, but in the Limited Arch Packages
>> [2]section of EPEL: Packaging, it seems to imply the SRPM name would
>> be the same, but the release number would be pretended with "0.".
>>
>> Could someone please clarify?
>>
>> If, in fact, the name can be the same, it will make it much easier to
>> provide Python 3 packages for EPEL since a separate package would not
>> be required in the Fedora Package DB.
>
> So, here's the thing (at least as I understand it):
>
> koji operates on source packages.
>
> If there's a package in RHEL called 'foo' and also one in EPEL called
> 'foo' it will use the epel one in all cases for everything that foo
> makes.

Is that the case with external repos? I didn't think it was that smart
in that case, but I'm tired so might be mis-remembering.

> So, with the limited arch packages this means that _ALL_ things
> building in koji will use the epel package. The reason for the
> prepended 0 is so that users don't install the epel package and instead
> get the newer rhel version. The limited arch guideline also says you
> should try and keep the package as close as possible to the rhel
> version.

For el7, and even in some of the big (java*) use cases in el6 the
delta in packages between the arches is getting a lot less, and I
believe this will be more so as we move forward in el7.

> So, if we had say: python-foobar-1.0-1.el7.src.rpm in rhel that made a
> python-foobar-1.0-1.noarch.rpm and then we made a epel
> python-foobar-1.0-1.el7.src.rpm that had
> python3-foobar-1.0-1.noarch.rpm it would mean anything that builds
> against python-foobar in epel would break (it would be not found). End
> users would be ok, but buildroots could be broken by it.
>
> So we are kinda in a lerch here... I think the best way is just new
> packages with python3-whatever.
>
> kevin
>
>
>
> ___
> epel-devel mailing list
> epel-devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
>
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[Bug 1372498] perl-Locale-Codes-3.40 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Locale-Codes-3.40-1.fc |perl-Locale-Codes-3.40-1.fc
   |26  |26
   |perl-Locale-Codes-3.40-1.fc |perl-Locale-Codes-3.40-1.fc
   |25  |25
   ||perl-Locale-Codes-3.40-1.fc
   ||24



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1372504] perl-Sereal-Decoder-3.015 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Sereal-Decoder-3.015-1 |perl-Sereal-Decoder-3.015-1
   |.fc26   |.fc26
   |perl-Sereal-Decoder-3.015-1 |perl-Sereal-Decoder-3.015-1
   |.fc25   |.fc25
   ||perl-Sereal-Decoder-3.015-1
   ||.fc24
 Resolution|--- |ERRATA
Last Closed|2016-09-09 17:48:17 |2016-09-13 18:25:03



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1372498] perl-Locale-Codes-3.40 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Locale-Codes-3.40-1.fc24 has been pushed to the Fedora 24 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.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1372503] perl-Sereal-3.015 is available

[bugzilla]

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

Bug 1372504 Summary: perl-Sereal-Decoder-3.015 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1372504

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1372504] perl-Sereal-Decoder-3.015 is available

[bugzilla]

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



--- Comment #14 from Fedora Update System  ---
perl-Sereal-Decoder-3.015-1.fc24 has been pushed to the Fedora 24 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.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1372505] perl-Sereal-Encoder-3.015 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Sereal-Encoder-3.015-1 |perl-Sereal-Encoder-3.015-1
   |.fc26   |.fc26
   |perl-Sereal-Encoder-3.015-1 |perl-Sereal-Encoder-3.015-1
   |.fc25   |.fc25
   ||perl-Sereal-Encoder-3.015-1
   ||.fc24
 Resolution|--- |ERRATA
Last Closed|2016-09-09 17:48:09 |2016-09-13 18:24:55



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1372503] perl-Sereal-3.015 is available

[bugzilla]

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

Bug 1372505 Summary: perl-Sereal-Encoder-3.015 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1372505

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1372982] perl-IO-Interactive-1.022 is available

[bugzilla]

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



--- Comment #10 from Fedora Update System  ---
perl-IO-Interactive-1.022-1.fc24 has been pushed to the Fedora 24 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.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1372503] perl-Sereal-3.015 is available

[bugzilla]

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



--- Comment #12 from Fedora Update System  ---
perl-Sereal-3.015-1.fc24 has been pushed to the Fedora 24 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.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1372505] perl-Sereal-Encoder-3.015 is available

[bugzilla]

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



--- Comment #12 from Fedora Update System  ---
perl-Sereal-Encoder-3.015-1.fc24 has been pushed to the Fedora 24 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.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1372982] perl-IO-Interactive-1.022 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-IO-Interactive-1.022-1 |perl-IO-Interactive-1.022-1
   |.fc26   |.fc26
   |perl-IO-Interactive-1.022-1 |perl-IO-Interactive-1.022-1
   |.fc25   |.fc25
   ||perl-IO-Interactive-1.022-1
   ||.fc24



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1372503] perl-Sereal-3.015 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Sereal-3.015-1.fc26|perl-Sereal-3.015-1.fc26
   |perl-Sereal-3.015-1.fc25|perl-Sereal-3.015-1.fc25
   ||perl-Sereal-3.015-1.fc24
 Resolution|--- |ERRATA
Last Closed|2016-09-09 17:48:04 |2016-09-13 18:24:49



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: F24, small backward steps

[Michael Catanzaro]

On Tue, 2016-09-13 at 14:46 -0700, Adam Williamson wrote:
> 
> I'm not sure it really is unmaintained. There was 34.2 release this
> April, by the looks of things.
> 
> http://koji.fedoraproject.org/koji/packageinfo?packageID=10035

Aaaand I do see it in Software now. At long last!
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Adam Williamson]

On Tue, 2016-09-13 at 17:17 -0400, Roger Wells wrote:
> 
> if it is unmaintained why does its GUI operation change between Fedora
> versions?

I'm not sure it really is unmaintained. There was 34.2 release this
April, by the looks of things.

http://koji.fedoraproject.org/koji/packageinfo?packageID=10035
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel] Re: Requirements for SRPM names

[Neal Gompa]

On Tue, Sep 13, 2016 at 5:26 PM, Kevin Fenzi  wrote:
> On Tue, 13 Sep 2016 14:13:44 -0400
> Avram Lubkin  wrote:
>
>> I'm looking for some clarification on the naming requirements for
>> SRPMs.
>>
>> In the EPEL 7 in Python 3 Plan Draft [1], it specifies that SRPM names
>> can't conflict with RHEL SRPM names, but in the Limited Arch Packages
>> [2]section of EPEL: Packaging, it seems to imply the SRPM name would
>> be the same, but the release number would be pretended with "0.".
>>
>> Could someone please clarify?
>>
>> If, in fact, the name can be the same, it will make it much easier to
>> provide Python 3 packages for EPEL since a separate package would not
>> be required in the Fedora Package DB.
>
> So, here's the thing (at least as I understand it):
>
> koji operates on source packages.
>
> If there's a package in RHEL called 'foo' and also one in EPEL called
> 'foo' it will use the epel one in all cases for everything that foo
> makes.
>
> So, with the limited arch packages this means that _ALL_ things
> building in koji will use the epel package. The reason for the
> prepended 0 is so that users don't install the epel package and instead
> get the newer rhel version. The limited arch guideline also says you
> should try and keep the package as close as possible to the rhel
> version.
>
> So, if we had say: python-foobar-1.0-1.el7.src.rpm in rhel that made a
> python-foobar-1.0-1.noarch.rpm and then we made a epel
> python-foobar-1.0-1.el7.src.rpm that had
> python3-foobar-1.0-1.noarch.rpm it would mean anything that builds
> against python-foobar in epel would break (it would be not found). End
> users would be ok, but buildroots could be broken by it.
>
> So we are kinda in a lerch here... I think the best way is just new
> packages with python3-whatever.

That doesn't make sense. Builds are done by pulling in base, epel, and
buildroot repositories into a generated mock config and executed (i.e.
passed to mock to build the SRPM and then the RPMs). No part of mock
would have a problem here. Therefore, there is no reason for the
absurdity of having python3-* SRPMs.

Sure, Koji operates on SRPMs, but Fedora Koji does not build RHEL or
CentOS. So this particular problem doesn't exist from that perspective
either. Content from RHEL/CentOS essentially is a black box to Koji.

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: F24, small backward steps

[Kevin Fenzi]

On Tue, 13 Sep 2016 15:03:28 -0500
Michael Catanzaro  wrote:

> On Tue, 2016-09-13 at 14:33 -0400, Roger Wells wrote:
> > It was the first problem, the one with deja-dup  
> 
> Where did you report the bug? The upstream bug tracker is [1]. If you
> reported it somewhere else, of course you'd be told it's the wrong
> place
> 
> Unfortunately, I think deja-dup is unmaintained, so reporting bugs is
> not likely to result in fixes. It's not even user-visible, for many
> years, now due to some problem with the appdata file. But there's no
> chance of a fix if the issue isn't reported, so still a good idea

FYI, I fixed the visibility in gnome-software a while back and the
maintainer applied my patches. 

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

kevin


pgpXYZkVN0YLj.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Notifying co-maintainers about bug reports (was: F24, small backward steps)

[Björn Persson]

Pierre-Yves Chibon wrote:
> Everyone having `watchbugzilla` on a package is automatically cc'ed
> to the bug reports.
> In the early days of pkgdb2, I had it be: everyone with
> `watchbugzilla` or `commit` but I was asked to remove that last
> condition [1].

Would it be possible to show that information in the web interface?
Explain what effects the various privileges have, and what effects they
don't have, so that co-maintainers can predict whether they will notice
when bugs are reported.

I'm surprised to learn that I won't notice bug reports to packages I co-
maintain. I've been assuming that "commit" implied "watchbugzilla" and
"watchcommits", because I thought that made sense. Apparently you also
thought so originally.

I see a link to documentation for sysadmins and developers, but in a few
minutes of searching I didn't find any explanations of the privileges
there. I don't see anything that explains the web interface to users.

Björn Persson


pgpu2gi_XbAgM.pgp
Description: OpenPGP digital signatur
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unversioned and >/=/>= obsoletes

[Kevin Fenzi]

On Tue, 13 Sep 2016 11:38:24 +0200
Igor Gnatenko  wrote:

> I'm going to do mass bug filling for those packages which are still
> not fixed. Are there some scripts to do that or I have to write my
> own?
> 
> Unfixed packages:
> https://ignatenkobrain.fedorapeople.org/broken-obsoletes/latest/broken-obsoletes.txt

Can you please take a look at: 

https://fedoraproject.org/wiki/Mass_bug_filing

and address the items there before filing?

Happy to help review a proposed bug text/announcement.

kevin


pgpVgvj62u6Ng.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Reviews Weekly

[Kevin Fenzi]

On Mon, 12 Sep 2016 15:01:29 +0200
Milan Crha  wrote:

> On Mon, 2016-09-12 at 14:26 +0200, Igor Gnatenko wrote:
> > > Javier Peña : 1  
> > Please fix unicode issues ;)  
> 
>   Hi,
> it's because the related part claims:
>  Content-Type: text/plain; charset="us-ascii"
> while using UTF-8 in the body. When I override the charset in the mail
> application I use, then it shows the umlauts and so on properly.
>   Bye,
>   Milan

Filed https://fedorahosted.org/fedora-infrastructure/ticket/5475 to fix
this. 

Thanks, 

kevin



pgpGeU0z5jbW1.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel] Re: Requirements for SRPM names

[Kevin Fenzi]

On Tue, 13 Sep 2016 14:13:44 -0400
Avram Lubkin  wrote:

> I'm looking for some clarification on the naming requirements for
> SRPMs.
> 
> In the EPEL 7 in Python 3 Plan Draft [1], it specifies that SRPM names
> can't conflict with RHEL SRPM names, but in the Limited Arch Packages
> [2]section of EPEL: Packaging, it seems to imply the SRPM name would
> be the same, but the release number would be pretended with "0.".
> 
> Could someone please clarify?
> 
> If, in fact, the name can be the same, it will make it much easier to
> provide Python 3 packages for EPEL since a separate package would not
> be required in the Fedora Package DB.

So, here's the thing (at least as I understand it): 

koji operates on source packages. 

If there's a package in RHEL called 'foo' and also one in EPEL called
'foo' it will use the epel one in all cases for everything that foo
makes.

So, with the limited arch packages this means that _ALL_ things
building in koji will use the epel package. The reason for the
prepended 0 is so that users don't install the epel package and instead
get the newer rhel version. The limited arch guideline also says you
should try and keep the package as close as possible to the rhel
version. 

So, if we had say: python-foobar-1.0-1.el7.src.rpm in rhel that made a
python-foobar-1.0-1.noarch.rpm and then we made a epel
python-foobar-1.0-1.el7.src.rpm that had
python3-foobar-1.0-1.noarch.rpm it would mean anything that builds
against python-foobar in epel would break (it would be not found). End
users would be ok, but buildroots could be broken by it. 

So we are kinda in a lerch here... I think the best way is just new
packages with python3-whatever. 

kevin




pgpj91ng6ZZPx.pgp
Description: OpenPGP digital signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Requirements for SRPM names

[Neal Gompa]

On Tue, Sep 13, 2016 at 5:14 PM, Avram Lubkin  wrote:
> On Tue, Sep 13, 2016 at 2:28 PM, Stephen John Smoogen 
> wrote:
>>
>>
>> The reasoning for needing a python3-foobaz is that we don't replace
>> the python2 version of foobaz with a package which does not work at
>> all with the python2 installed and possibly breaks an existing app.
>
>
> You seem to be talking about RPM names and not SRPM names. By convention,
> any Python 3 package for EPEL7 would actually be python34-package. The point
> of this thread is to discuss SRPM names and if python34-package can be built
> from a SPRM package named python-package like in Fedora. Since python2 and
> python3 packages are generally built from the same source and spec, the SRPM
> and Fedora Git repo are usually not versioned. The problem is when a python2
> package exists in RHEL, but we want to supply a python34 package. The draft
> guidelines (which are the only ones we have) say this is a conflict, but it
> seems that is not stated anywhere in the EPEL guidelines. The main problem
> this creates is very few python34 packages get created because people don't
> want to maintain multiple repos for the same thing.
>
> As far as the limited arch packages, I bring that up because it seems from
> the guidelines their SRPM name would be the same as the one in RHEL. If that
> is acceptable there, it likely should be for python packages.
>

In general, I do not understand why we need to have brand new
"python3-*" SRPMs for these things. It makes far more sense to just
add a conditional for building the Python2 version so that it doesn't
get built for EPEL in places where it overlaps with an existing
package from the base. The SRPM names should be irrelevant and reusing
the SRPMs from Fedora makes tracking things much simpler.

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: Fedora Rawhide-20160913.n.1 compose check report

[Adam Williamson]

On Tue, 2016-09-13 at 20:13 +, Fedora compose checker wrote:
> Missing expected images:
> 
> 
> Cloud_base raw-xz i386
> Atomic raw-xz x86_64
> 
> 
> Failed openQA tests: 8/92 (x86_64), 3/17 (i386), 1/2 (arm)
> 
> 
> New failures (same test did not fail in Rawhide-20160912.n.0):
> 
> 
> ID: 34125 Test: x86_64 Workstation-live-iso install_default_upload
> URL: https://openqa.fedoraproject.org/tests/34125
> ID: 34126 Test: x86_64 Workstation-live-iso install_default@uefi
> URL: https://openqa.fedoraproject.org/tests/34126
> ID: 34134 Test: i386 Workstation-live-iso install_default
> URL: https://openqa.fedoraproject.org/tests/34134
> ID: 34205 Test: x86_64 universal upgrade_desktop_64bit
> URL: https://openqa.fedoraproject.org/tests/34205
> ID: 34208 Test: x86_64 universal upgrade_desktop_encrypted_64bit
> URL: https://openqa.fedoraproject.org/tests/34208
> ID: 34210 Test: x86_64 universal upgrade_2_desktop_64bit
> URL: https://openqa.fedoraproject.org/tests/34210
> ID: 34213 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
> URL: https://openqa.fedoraproject.org/tests/34213
> ID: 34230 Test: i386 universal upgrade_desktop_32bit
> URL: https://openqa.fedoraproject.org/tests/34230

The GNOME 'Getting Started' screen, which should appear after the
initial-setup wizard is complete, just doesn't seem to be showing up on
Rawhide at all. I'll reproduce this locally and file a bug soon.
There's also still an issue with things crashing and/or freezing on 32-
bit which I'm trying to look at locally.

> Old failures (same test failed in Rawhide-20160912.n.0):
> 
> 
> ID: 34136 Test: x86_64 Atomic-boot-iso install_default
> URL: https://openqa.fedoraproject.org/tests/34136

This is still https://bugzilla.redhat.com/show_bug.cgi?id=1331864 .

> ID: 34145 Test: arm Minimal-raw_xz-raw.xz 
> install_arm_image_deployment_upload
> URL: https://openqa.fedoraproject.org/tests/34145

This is running into initial-setup bugs, I believe; we have two filed
as blockers:

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

> ID: 34231 Test: i386 universal upgrade_2_desktop_32bit
> URL: https://openqa.fedoraproject.org/tests/34231

https://bugzilla.redhat.com/show_bug.cgi?id=1333591 is still going
strong...

> ID: 34236 Test: x86_64 universal install_iscsi
> URL: https://openqa.fedoraproject.org/tests/34236

A lorax update fixed the previous iSCSI bug, now we have a shiny new one:
https://bugzilla.redhat.com/show_bug.cgi?id=1375712
> 
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel] Re: Requirements for SRPM names

[Avram Lubkin]

On Tue, Sep 13, 2016 at 2:28 PM, Stephen John Smoogen 
wrote:

>
> The reasoning for needing a python3-foobaz is that we don't replace
> the python2 version of foobaz with a package which does not work at
> all with the python2 installed and possibly breaks an existing app.
>

You seem to be talking about RPM names and not SRPM names. By convention,
any Python 3 package for EPEL7 would actually be python34-package. The
point of this thread is to discuss SRPM names and if python34-package can
be built from a SPRM package named python-package like in Fedora. Since
python2 and python3 packages are generally built from the same source and
spec, the SRPM and Fedora Git repo are usually not versioned. The problem
is when a python2 package exists in RHEL, but we want to supply a python34
package. The draft guidelines (which are the only ones we have) say this is
a conflict, but it seems that is not stated anywhere in the EPEL
guidelines. The main problem this creates is very few python34 packages get
created because people don't want to maintain multiple repos for the same
thing.

As far as the limited arch packages, I bring that up because it seems from
the guidelines their SRPM name would be the same as the one in RHEL. If
that is acceptable there, it likely should be for python packages.

Avram
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: F24, small backward steps

[Roger Wells]

On 09/13/2016 04:03 PM, Michael Catanzaro wrote:
> On Tue, 2016-09-13 at 14:33 -0400, Roger Wells wrote:
>> It was the first problem, the one with deja-dup
> 
> Where did you report the bug? The upstream bug tracker is [1]. If you
> reported it somewhere else, of course you'd be told it's the wrong
> place
> 
> Unfortunately, I think deja-dup is unmaintained, so reporting bugs is
> not likely to result in fixes. It's not even user-visible, for many
> years, now due to some problem with the appdata file. But there's no
> chance of a fix if the issue isn't reported, so still a good idea
> 
if it is unmaintained why does its GUI operation change between Fedora
versions?

> Michael
> 
> [1] https://bugs.launchpad.net/deja-dup
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
> 


-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Chris Murphy]

On Tue, Sep 13, 2016 at 2:24 PM, Stephen John Smoogen  wrote:
> On 13 September 2016 at 16:03, Michael Catanzaro  wrote:
>> On Tue, 2016-09-13 at 14:33 -0400, Roger Wells wrote:
>>> It was the first problem, the one with deja-dup
>>
>> Where did you report the bug? The upstream bug tracker is [1]. If you
>> reported it somewhere else, of course you'd be told it's the wrong
>> place
>>
>> Unfortunately, I think deja-dup is unmaintained, so reporting bugs is
>> not likely to result in fixes. It's not even user-visible, for many
>> years, now due to some problem with the appdata file. But there's no
>> chance of a fix if the issue isn't reported, so still a good idea
>>
>
> OK this is the most frustrating of a TON of frustrating parts of this
> conversation.
>
> 1. WHY DO WE SHIP PACKAGES THAT WE 'KNOW' AREN'T MAINTAINED?
> 2. Why are people 'maintainers' of such packages if they know upstream
> is dead and they aren't going to maintain things.
> 3. If someone isn't going to read the bugzillas why do we even have
> them in bugzilla or the distribution?


Yeah really, I thought this is what orphaned means?


-- 
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel] Re: Requirements for SRPM names

[Jim Perrin]

On 09/13/2016 01:28 PM, Stephen John Smoogen wrote:
> On 13 September 2016 at 14:13, Avram Lubkin  wrote:
>> I'm looking for some clarification on the naming requirements for SRPMs.
>>
>> In the EPEL 7 in Python 3 Plan Draft [1], it specifies that SRPM names can't
>> conflict with RHEL SRPM names, but in the Limited Arch Packages [2]section
>> of EPEL: Packaging, it seems to imply the SRPM name would be the same, but
>> the release number would be pretended with "0.".
>>
> 
> Limited arch packages are ones where you are building something for
> say ppc or aarch64 which has a RHEL package already in x86_64 but no
> corresponding RHEL ppc or x86_64 one. The reason to put a 0. in front
> is that sometimes RHEL does offer such packages later in a release
> cycle and we want that version to overwrite anything we built to
> satisfy a dependency. [Also if CentOS builds all the packages for
> their port of EL-X to PPC or aarch64 we do not conflict with their
> packages.]
> 
> This is only meant for that case.
> 
>> Could someone please clarify?
>>
>> If, in fact, the name can be the same, it will make it much easier to
>> provide Python 3 packages for EPEL since a separate package would not be
>> required in the Fedora Package DB.
>>
> 
> The reasoning for needing a python3-foobaz is that we don't replace
> the python2 version of foobaz with a package which does not work at
> all with the python2 installed and possibly breaks an existing app.
> 
> My personal take is that all python3 apps should be called python3 in
> their names and all python2 apps should have been called python2 as
> every time python does these major updates we end up with years of
> maintaining this split brain damage which lasts longer than the
> language version exists.



I'm in the process of working through this for a few python bits for
EPEL7. While I generally agree, it's problematic at times because the
fedora sources provide a sane split for this, while the EL sources do
not. This occasionally means creating a new package just for EPEL rather
than simply branching the fedora tree.


-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: F24, small backward steps

[Stephen John Smoogen]

On 13 September 2016 at 16:03, Michael Catanzaro  wrote:
> On Tue, 2016-09-13 at 14:33 -0400, Roger Wells wrote:
>> It was the first problem, the one with deja-dup
>
> Where did you report the bug? The upstream bug tracker is [1]. If you
> reported it somewhere else, of course you'd be told it's the wrong
> place
>
> Unfortunately, I think deja-dup is unmaintained, so reporting bugs is
> not likely to result in fixes. It's not even user-visible, for many
> years, now due to some problem with the appdata file. But there's no
> chance of a fix if the issue isn't reported, so still a good idea
>

OK this is the most frustrating of a TON of frustrating parts of this
conversation.

1. WHY DO WE SHIP PACKAGES THAT WE 'KNOW' AREN'T MAINTAINED?
2. Why are people 'maintainers' of such packages if they know upstream
is dead and they aren't going to maintain things.
3. If someone isn't going to read the bugzillas why do we even have
them in bugzilla or the distribution?

I am saying this from the point of view that we have put various
people in no-win situations and then set them up to fight each other.
A. The developer who  has to watch N packages that they can't
maintain, don't want to maintain, and are going to ignore.
B. The user who gets told to file a bug which is never going to be looked at.

The only person who is making anything here is the Press person who
gets to write a yearly "Why is Fedora so messed up yet again?"

Either maintain and watch a package and its bugs or don't. If you
can't watch more than 5 packages.. then watch those packages and drop
the rest. If the f'ing distro drops down to 200 packages then we can
at least say we know those 200 are maintainable and the OS is usable.
Then we can ship snappacks of the rest of the software that the user
can have a nice big button saying "good luck"


> Michael
>
> [1] https://bugs.launchpad.net/deja-dup
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



-- 
Stephen J Smoogen.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fedora Rawhide-20160913.n.1 compose check report

[Fedora compose checker]

Missing expected images:

Cloud_base raw-xz i386
Atomic raw-xz x86_64

Failed openQA tests: 8/92 (x86_64), 3/17 (i386), 1/2 (arm)

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

ID: 34125   Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/34125
ID: 34126   Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/34126
ID: 34134   Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/34134
ID: 34205   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/34205
ID: 34208   Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/34208
ID: 34210   Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/34210
ID: 34213   Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/34213
ID: 34230   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/34230

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

ID: 34136   Test: x86_64 Atomic-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/34136
ID: 34145   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/34145
ID: 34231   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/34231
ID: 34236   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/34236

Passed openQA tests: 79/92 (x86_64), 14/17 (i386)

New passes (same test did not pass in Rawhide-20160912.n.0):

ID: 34160   Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/34160
ID: 34237   Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/34237

Skipped openQA tests: 6 of 111
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Michael Catanzaro]

On Tue, 2016-09-13 at 14:33 -0400, Roger Wells wrote:
> It was the first problem, the one with deja-dup

Where did you report the bug? The upstream bug tracker is [1]. If you
reported it somewhere else, of course you'd be told it's the wrong
place

Unfortunately, I think deja-dup is unmaintained, so reporting bugs is
not likely to result in fixes. It's not even user-visible, for many
years, now due to some problem with the appdata file. But there's no
chance of a fix if the issue isn't reported, so still a good idea

Michael

[1] https://bugs.launchpad.net/deja-dup
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2016-09-08)

[Athmane Madjoudj]

Hi all,

On Tue, Sep 13, 2016 at 8:45 PM, Till Maas  wrote:
>> Depending on: freeradius-client (11), status change: 2016-04-29 (18 weeks 
>> ago)
>>   asterisk (maintained by: jsmith, gtjoseph, itamarjp, lbazan, 
>> leifmadsen, russellb)
>>   asterisk-13.9.1-1.fc25.1.src requires freeradius-client-devel 
>> = 1.1.7-10.fc24
>>   asterisk-radius-13.9.1-1.fc25.1.i686 requires 
>> libfreeradius-client.so.2
>>
...SNIP...

I took freeradius-client since I'm using nagios plugins and nrpe.



Best regards.

- Athmane
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Ground rules for riscv64 in Fedora dist-git

[Russell Doty]

On Tue, 2016-09-13 at 12:52 +0100, Richard W.M. Jones wrote:
> On Tue, Sep 13, 2016 at 11:32:26AM +0200, Florian Weimer wrote:
> > 
> > On 09/12/2016 08:55 PM, Richard W.M. Jones wrote:
> > > 
> > > On Mon, Sep 12, 2016 at 07:48:31PM +0100, Richard W.M. Jones
> > > wrote:
> > > > 
> > > > On Mon, Sep 12, 2016 at 09:06:59AM +0200, Florian Weimer wrote:
> > > > > 
> > > > > I had a brief look at the glibc patches.  Apparently, off_t
> > > > > and
> > > > > time_t are 32-bit.  For a new architecture, that's quite
> > > > > strange.
> > > 
> > > How do you determine this?
> > 
> > I looked at the patch.
> > 
> > > 
> > > I wrote a simple program which prints sizeof (off_t) and sizeof
> > > (time_t)
> > > inside the RISC-V environment.  I *didn't* define
> > > `-D_FILE_OFFSET_BITS=64' when compiling the program.  Both values
> > > are
> > > printed as 8 (bytes).  So it seems we're OK?
> > 
> > Yes, for 64-bit.  But the 32-bit parts do not look acceptable as-
> > is.
> 
> Fair enough.  For Fedora we are only building for 64 bit[1].  There
> aren't even multilib 32 bit libs.  (I'm not saying someone couldn't
> come along and add that later, but initially we're not considering
> it)
> 
> The reasons for this are:
> 
> - There is no legacy of 32 bit code to support.
> 
> - By the time this is available, people will care even less about 32
> bit.
> 
> - I've even talked to embedded manufacturers who intend to jump
> straight to RV64 (which surprised me because RV32 is designed for
> embedded uses).
Interesting! I'd like some more details on this; embedded systems range
from low end (16 bit or 32 bit cpu, 10's of KB of memory, hundreds of
KB of storage) to fairly serious systems.
> 
> > 
> > If you only want the 64-bit architecture, then getting the author
> > to
> > submit only the 64-bit parts first to glibc upstream would be the
> > prudent thing to do.  (This has to come from the patch author, and
> > the author has to assign copyright to the FSF.)
> 
> I've been telling everyone who will listen that they should get their
> changes upstream.
> 
> Rich.
> 
> [1] Specifically for "RV64G" = "RV64IMAFD" = RISC-V, 64 bit with
> Integer, Multiplication/division, Atomics, single Floats, and Double
> floats.  For more info, see section 10.4 in this document:
> https://people.eecs.berkeley.edu/~krste/papers/riscv-spec-2.0.pdf
> 
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2016-09-08)

[Till Maas]

Hi there,

On Thu, Sep 08, 2016 at 11:07:06AM +, opensou...@till.name wrote:

> The following packages require above mentioned packages:
> Depending on: freeradius-client (11), status change: 2016-04-29 (18 weeks ago)
>   asterisk (maintained by: jsmith, gtjoseph, itamarjp, lbazan, 
> leifmadsen, russellb)
>   asterisk-13.9.1-1.fc25.1.src requires freeradius-client-devel = 
> 1.1.7-10.fc24
>   asterisk-radius-13.9.1-1.fc25.1.i686 requires 
> libfreeradius-client.so.2
> 
>   nagios-plugins (maintained by: nb, kmf, mhayden, ondrejj, swilkerson)
>   nagios-plugins-2.1.1-1.fc24.src requires 
> freeradius-client-devel = 1.1.7-10.fc24
>   nagios-plugins-radius-2.1.1-1.fc24.i686 requires 
> libfreeradius-client.so.2
> 
>   opensips (maintained by: ivaxer, peter)
>   opensips-1.11.6-4.fc25.src requires freeradius-client-devel = 
> 1.1.7-10.fc24
>   opensips-aaa_radius-1.11.6-4.fc25.i686 requires 
> libfreeradius-client.so.2
> 
>   python-sippy (maintained by: peter)
>   python-sippy-1.0.3-14.fc25.noarch requires 
> freeradius-client-utils = 1.1.7-10.fc24
> 
>   asterisk-gui (maintained by: fantom)
>   asterisk-gui-2.0-12.20120518svn5220.fc24.noarch requires 
> asterisk = 13.9.1-1.fc25.1
> 
>   asterisk-sounds-core (maintained by: jsmith, itamarjp)
>   asterisk-sounds-core-en-1.5.0-1.fc24.noarch requires asterisk = 
> 13.9.1-1.fc25.1
> 

>   nagios-plugins-check-updates (maintained by: jpo)
>   nagios-plugins-check-updates-1.6.18-2.fc26.i686 requires 
> nagios-plugins = 2.1.1-1.fc24
> 
>   nagios-plugins-lcgdm (maintained by: rocha, aalvarez, adev, 
> andreamanzi, stevetraylen)
>   nagios-plugins-lcgdm-common-0.9.6-3.fc26.i686 requires 
> nagios-plugins(x86-32) = 2.1.1-1.fc24, nrpe(x86-32) = 2.15-8.fc24
> 
>   nrpe (maintained by: nb, jpo, kmf, mhayden, ondrejj, skottler, 
> swilkerson)
>   nagios-plugins-nrpe-2.15-8.fc24.i686 requires nagios-plugins = 
> 2.1.1-1.fc24
> 
>   nagios-plugins-snmp-disk-proc (maintained by: spot)
>   nagios-plugins-snmp-disk-proc-1.3.1-2.fc24.i686 requires 
> nagios-plugins = 2.1.1-1.fc24
> 
>   nordugrid-arc-nagios-plugins (maintained by: ellert, jonkni)
>   nordugrid-arc-nagios-plugins-1.8.4-5.fc25.i686 requires 
> nagios-plugins = 2.1.1-1.fc24

Am I missing something here or should asterisk and the nagios-plugins
really be retired? freeradius-client is now 18 weeks unmaintained and
needs to be retired now which means that asterisk and the nagios-plugins
will be retired as well or it needs to get a maintainer. Also if there
is a secret plan to make asterisk or nagios not depend on
freeradius-client, it is now the time to do so (actually it was a few
weeks ago).

Kind regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: comiing to koji aarch64

[Peter Robinson]

>> We are in the process of importing aarch64 to the primary koji instance as
>> part of https://fedoraproject.org/wiki/Architectures/
>> RedefiningSecondaryArchitectures  The import and enablement of aarch64 is for
>> rawhide only,  we expect to add power big and little endiian sometime before
>> the mass rebuild.
>>
>> We will be making changes to the compose process early next week to enable
>> aarch64 in the rawhide compose,  at the same time i386 we be moving from 
>> /pub/
>> fedora/ to /pub/fedora-secondary/
>>
>> A further announcement will come when building of aarch64 is enabled
>
> Does this also enable the new armv7 builders?  AIUI those were to be VMs
> running on aarch64 hardware.  If not, any updates on that?

Not yet, still working on this, it's still planned RSN, I had to break
things down into smaller more bite size chunks.

Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: comiing to koji aarch64

[Josh Stone]

On 09/10/2016 07:19 AM, Dennis Gilmore wrote:
> Hi All,
> 
> We are in the process of importing aarch64 to the primary koji instance as 
> part of https://fedoraproject.org/wiki/Architectures/
> RedefiningSecondaryArchitectures  The import and enablement of aarch64 is for 
> rawhide only,  we expect to add power big and little endiian sometime before 
> the mass rebuild.
> 
> We will be making changes to the compose process early next week to enable 
> aarch64 in the rawhide compose,  at the same time i386 we be moving from /pub/
> fedora/ to /pub/fedora-secondary/
> 
> A further announcement will come when building of aarch64 is enabled

Does this also enable the new armv7 builders?  AIUI those were to be VMs
running on aarch64 hardware.  If not, any updates on that?
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Broken dependencies: perl-Data-Alias

[buildsys]

perl-Data-Alias has broken dependencies in the rawhide tree:
On x86_64:
perl-Data-Alias-1.20-2.fc24.x86_64 requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.x86_64 requires perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-Data-Alias-1.20-2.fc24.i686 requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.i686 requires perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-Data-Alias-1.20-2.fc24.armv7hl requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.armv7hl requires perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: F24, small backward steps

[Roger Wells]

On 09/13/2016 12:31 PM, Bastien Nocera wrote:
> For which one of the problems you listed? It would certainly have been 
> interesting to list those in your original mail.
It was the first problem, the one with deja-dup
> 
> - Original Message -
>> On 09/13/2016 11:09 AM, Daniel P. Berrange wrote:
>>> On Tue, Sep 13, 2016 at 10:00:32AM -0500, Michael Catanzaro wrote:
 Hi,

 To be clear, the problem is that a small handful of package maintainers
 (including Bastien) are collectively "responsible" for all of the GNOME
 and freedesktop components in Fedora (including fprintd), and it's
 simply not reasonable to expect them to read all the bugs that are
 assigned to them, let alone take the time to forward them upstream. If
 you use Red Hat Bugzilla, the right developers may never notice your
 bug report at all.

 You have a much better chance filing bugs upstream. You should only use
 Red Hat Bugzilla for these components if you happen to know there is a
 specific maintainer who actually looks at the Red Hat bugs for that
 specific component, or if you're planning to propose it as a release
 blocker, or if you just don't care whether anybody sees your bug. If
 you have a packaging bug then it's the right place, but please ping
 someone to be sure it gets noticed.

 Of course this is not how Bugzilla is intended to work, but it is how
 it actually works for GNOME stuff. It's unfortunate, but without some
 Launchpad-style automatic bug forwarding, this is going to remain the
 case indefinitely.
>>>
>>> This is a truly awful experiance from POV of a Fedora user filing bugs :-(
>>> We've set a silent trap for them with no warning of the fact that their
>>> bug reports are going to be ignored until Fedora EOL procedure closes
>>> them :-(
>>>
>>> Even if we can't enhance Red hat Bugzilla, we can at least do more to
>>> alert users to this so they stand a chance of doing the right thing.
>>>
>>> eg, update the component description to tell user to file in GNOME
>>> bugzilla instead, and have a bot that adds a comment to any new bugs
>>> that are still filed, closing them WONTFIX and asking the user to
>>> re-open against upstream GNOME bugzilla, instead of leaving the bug
>>> open and ignored until Fedora EOL.
>>>
>>> Regards,
>>> Daniel
>>>
>> Thanks for recognizing this.  I am the OP.  I pretty quickly got a
>> response suggesting that I file a bug report "upstream".  I did that, or
>> so I thought, and immediately got a response from someone that it was
>> the wrong place or list followed by another declaring the matter closed.
>> I went back to my day job.
>>
>>
>> --
>> Roger Wells, P.E.
>> leidos
>> 221 Third St
>> Newport, RI 02840
>> 401-847-4210 (voice)
>> 401-849-1585 (fax)
>> roger.k.we...@leidos.com
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
> 


-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel] Re: Requirements for SRPM names

[Stephen John Smoogen]

On 13 September 2016 at 14:13, Avram Lubkin  wrote:
> I'm looking for some clarification on the naming requirements for SRPMs.
>
> In the EPEL 7 in Python 3 Plan Draft [1], it specifies that SRPM names can't
> conflict with RHEL SRPM names, but in the Limited Arch Packages [2]section
> of EPEL: Packaging, it seems to imply the SRPM name would be the same, but
> the release number would be pretended with "0.".
>

Limited arch packages are ones where you are building something for
say ppc or aarch64 which has a RHEL package already in x86_64 but no
corresponding RHEL ppc or x86_64 one. The reason to put a 0. in front
is that sometimes RHEL does offer such packages later in a release
cycle and we want that version to overwrite anything we built to
satisfy a dependency. [Also if CentOS builds all the packages for
their port of EL-X to PPC or aarch64 we do not conflict with their
packages.]

This is only meant for that case.

> Could someone please clarify?
>
> If, in fact, the name can be the same, it will make it much easier to
> provide Python 3 packages for EPEL since a separate package would not be
> required in the Fedora Package DB.
>

The reasoning for needing a python3-foobaz is that we don't replace
the python2 version of foobaz with a package which does not work at
all with the python2 installed and possibly breaks an existing app.

My personal take is that all python3 apps should be called python3 in
their names and all python2 apps should have been called python2 as
every time python does these major updates we end up with years of
maintaining this split brain damage which lasts longer than the
language version exists.

> Avram
>
>
> [1]
> https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3#Packaging_Parallel_python3X_stacks
> [2] https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages
>
>
> ___
> epel-devel mailing list
> epel-devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
>



-- 
Stephen J Smoogen.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: F24, small backward steps

[Michael Catanzaro]

On Tue, 2016-09-13 at 18:49 +0200, Pierre-Yves Chibon wrote:
> If ABRT is a firehose of bugs flying to RH's bugzilla, would the
> situation be
> really better if the reports were sent to gnome's BZ?

Yes, it would. Keep in mind that upstream maintainers are responsible
for far fewer packages than Fedora maintainers. A busy GNOME maintainer
might maintain 2-5 packages upstream, but 20-50 Fedora packages (not
counting comaintainence, then we're talking hundreds). It's a lot
easier to look at crashes for 2-5 packages than 20-50 packages.

Now, it's not going to make things perfect. Some GNOME maintainers
don't look at upstream bugs either (but that's comparatively rare). And
many packages are just totally unmaintained. But for most components,
it would be a big improvement to file the bugs upstream where the right
maintainers will see it.

Michael
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Resultsdb v2.0 - API docs

[Randy Barlow]

Will the api/v1.0/ endpoint continue to function as-is for a while, to give 
integrators time to adjust to the new API? That would be ideal for Bodhi, so we 
can adjust our code to work with v2.0 after it is already in production. If 
not, we will need to coordinate bodhi and resultsdb releases at the same time.
___
qa-devel mailing list
qa-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org

[EPEL-devel] Requirements for SRPM names

[Avram Lubkin]

I'm looking for some clarification on the naming requirements for SRPMs.

In the EPEL 7 in Python 3 Plan Draft [1], it specifies that SRPM names
can't conflict with RHEL SRPM names, but in the Limited Arch Packages
[2]section of EPEL: Packaging, it seems to imply the SRPM name would be the
same, but the release number would be pretended with "0.".

Could someone please clarify?

If, in fact, the name can be the same, it will make it much easier to
provide Python 3 packages for EPEL since a separate package would not be
required in the Fedora Package DB.

Avram


[1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3#
Packaging_Parallel_python3X_stacks
[2] https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] [Fedocal] Reminder meeting : EPSCO meeting

[smooge]

Dear all,

You are kindly invited to the meeting:
   EPSCO meeting on 2016-09-14 from 18:00:00 to 19:00:00 GMT
   At fedora-meet...@irc.freenode.net

The meeting will be about:
Extra Packages for Enterprise Linux Steering COmmittee (EPSCO) has a weekly 
meeting to go over concerns and problems in the EPEL distribution. 

You are kindly invited to come and meet with us


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

___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: Python SIG on-boarding issue

[Tim Orling]

On Tue, Sep 13, 2016 at 10:36 AM, Miro Hrončok  wrote:

> On 13.9.2016 19:27, Dhanesh Bhalchandra Sabane wrote:
>
>> Aloha Python-SIG!
>> I was wondering whether it is a good time to make the new pages official.
>> Also, I would like to know whether the idea of splitting the SIG into two
>> FAS groups is acceptable so that we can start taking necessary actions.
>>
> Yes and yes.


+1

>
> CommOps is currently working on the Python SIG On-Boarding ticket [1] and
>>> one of the tasks
>>> we have identified is re-writing the Python SIG wiki page to make it more
>>> beginner-friendly. I was assigned with this particular task which is now
>>> complete [2] [3].
>>>  We received some feedback from mhroncok today during the CommOps
>>> meeting and following
>>> points were discussed:
>>>
>>> 1. Splitting Python SIG in two FAS groups:
>>> 1.1 *python-sig* for newcomers and interested members who hang out and
>>> help with Python on
>>> Fedora
>>> 1.2 *python-packagers* for proven members of the community / packagers
>>> who will also
>>> receive security-related bugs. Promising members from *python-sig* group
>>> can be promoted
>>> to *python-packagers* given that they have contributed to the package's
>>> git.
>>>
>>>
This will make the intent much clearer :)
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

Re: F24, small backward steps

[Pierre-Yves Chibon]

On Tue, Sep 13, 2016 at 01:19:04PM -0400, Paul Wouters wrote:
> On Tue, 13 Sep 2016, Ralf Corsepius wrote:
> 
> > >  This is a truly awful experiance from POV of a Fedora user filing bugs 
> > > :-(
> > >  We've set a silent trap for them with no warning of the fact that their
> > >  bug reports are going to be ignored until Fedora EOL procedure closes
> > >  them :-(
> > 
> > One lesson I have learnt in Fedora, is that filing bugs reports against
> > packages owned by certain people equals to sending bugs to /dev/null.
> > 
> > IMHO, Fedora should consider to take disciplinary measures against these
> > people.
> 
> And get less packagers?
> 
> It would be useful if package co-owners would automatically get added to
> the bugzilla bug, instead of only the package owner. Most packages don't
> have dedicated aliases for that.

Everyone having `watchbugzilla` on a package is automatically cc'ed to the bug
reports.
In the early days of pkgdb2, I had it be: everyone with `watchbugzilla` or
`commit` but I was asked to remove that last condition [1].

[1] https://fedorahosted.org/pkgdb2/ticket/10


Pierre
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Josh Boyer]

On Tue, Sep 13, 2016 at 11:00 AM, Michael Catanzaro
 wrote:
> Hi,
>
> To be clear, the problem is that a small handful of package maintainers
> (including Bastien) are collectively "responsible" for all of the GNOME
> and freedesktop components in Fedora (including fprintd), and it's
> simply not reasonable to expect them to read all the bugs that are
> assigned to them, let alone take the time to forward them upstream. If
> you use Red Hat Bugzilla, the right developers may never notice your
> bug report at all.
>
> You have a much better chance filing bugs upstream. You should only use
> Red Hat Bugzilla for these components if you happen to know there is a
> specific maintainer who actually looks at the Red Hat bugs for that
> specific component, or if you're planning to propose it as a release

That is the crux of the problem with this approach.  It is impossible
for a user to determine which packages have maintainers that look in
RH Bugzilla and which do not.

josh
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Python SIG on-boarding issue

[Miro Hrončok]

On 13.9.2016 19:27, Dhanesh Bhalchandra Sabane wrote:

Aloha Python-SIG!
I was wondering whether it is a good time to make the new pages official. Also, 
I would like to know whether the idea of splitting the SIG into two FAS groups 
is acceptable so that we can start taking necessary actions.

Yes and yes.


CommOps is currently working on the Python SIG On-Boarding ticket [1] and one 
of the tasks
we have identified is re-writing the Python SIG wiki page to make it more
beginner-friendly. I was assigned with this particular task which is now 
complete [2] [3].
 We received some feedback from mhroncok today during the CommOps meeting and 
following
points were discussed:

1. Splitting Python SIG in two FAS groups:
1.1 *python-sig* for newcomers and interested members who hang out and help 
with Python on
Fedora
1.2 *python-packagers* for proven members of the community / packagers who will 
also
receive security-related bugs. Promising members from *python-sig* group can be 
promoted
to *python-packagers* given that they have contributed to the package's git.

2. Python Features section on the wiki page needs some love.

3.  Targeting specific information for newcomers to include in their 
self-introductions
that would be helpful for SIG members to know where someone fits in the Python 
community
and what their expertise is.

We would like to hear your feedback on the draft and also on the aforementioned 
points.
Everyone is welcome to leave a comment on the ticket[1].

[1] https://pagure.io/fedora-commops/issue/84
[2] https://fedoraproject.org/wiki/User:Dhanesh95/SIGs/Python
[3] https://fedoraproject.org/wiki/User:Dhanesh95/SIGs/Python/Join


---
Dhanesh B. Sabane
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

Re: Python SIG on-boarding issue

[Dhanesh Bhalchandra Sabane]

Aloha Python-SIG!
I was wondering whether it is a good time to make the new pages official. Also, 
I would like to know whether the idea of splitting the SIG into two FAS groups 
is acceptable so that we can start taking necessary actions. 

> CommOps is currently working on the Python SIG On-Boarding ticket [1] and one 
> of the tasks
> we have identified is re-writing the Python SIG wiki page to make it more
> beginner-friendly. I was assigned with this particular task which is now 
> complete [2] [3].
>  We received some feedback from mhroncok today during the CommOps meeting and 
> following
> points were discussed:
> 
> 1. Splitting Python SIG in two FAS groups: 
> 1.1 *python-sig* for newcomers and interested members who hang out and help 
> with Python on
> Fedora
> 1.2 *python-packagers* for proven members of the community / packagers who 
> will also
> receive security-related bugs. Promising members from *python-sig* group can 
> be promoted
> to *python-packagers* given that they have contributed to the package's git. 
> 
> 2. Python Features section on the wiki page needs some love.
> 
> 3.  Targeting specific information for newcomers to include in their 
> self-introductions
> that would be helpful for SIG members to know where someone fits in the 
> Python community
> and what their expertise is.
> 
> We would like to hear your feedback on the draft and also on the 
> aforementioned points.
> Everyone is welcome to leave a comment on the ticket[1].
> 
> [1] https://pagure.io/fedora-commops/issue/84
> [2] https://fedoraproject.org/wiki/User:Dhanesh95/SIGs/Python
> [3] https://fedoraproject.org/wiki/User:Dhanesh95/SIGs/Python/Join

---
Dhanesh B. Sabane
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

Re: F24, small backward steps

[Paul Wouters]

On Tue, 13 Sep 2016, Ralf Corsepius wrote:


 This is a truly awful experiance from POV of a Fedora user filing bugs :-(
 We've set a silent trap for them with no warning of the fact that their
 bug reports are going to be ignored until Fedora EOL procedure closes
 them :-(


One lesson I have learnt in Fedora, is that filing bugs reports against 
packages owned by certain people equals to sending bugs to /dev/null.


IMHO, Fedora should consider to take disciplinary measures against these 
people.


And get less packagers?

It would be useful if package co-owners would automatically get added to
the bugzilla bug, instead of only the package owner. Most packages don't
have dedicated aliases for that.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Pierre-Yves Chibon]

On Tue, Sep 13, 2016 at 12:32:20PM -0400, Bastien Nocera wrote:
> 
> 
> - Original Message -
> 
> > This is a truly awful experiance from POV of a Fedora user filing bugs :-(
> > We've set a silent trap for them with no warning of the fact that their
> > bug reports are going to be ignored until Fedora EOL procedure closes
> > them :-(
> > 
> > Even if we can't enhance Red hat Bugzilla, we can at least do more to
> > alert users to this so they stand a chance of doing the right thing.
> > 
> > eg, update the component description to tell user to file in GNOME
> > bugzilla instead, and have a bot that adds a comment to any new bugs
> > that are still filed, closing them WONTFIX and asking the user to
> > re-open against upstream GNOME bugzilla, instead of leaving the bug
> > open and ignored until Fedora EOL.
> 
> A couple of things could be done to help with that:
> - Bring back the x-bugzilla .desktop metadata, and have ABRT file upstream 
> bugs
> - Make ABRT reports more useful (right now it's attaches a *lot* of extra
>   information, basically everything it can, as files). It's not possible
>   to search for parts of backtraces in the query tool.
> - More useful templates when filing bugs, explaining where to file RFEs and
>   non-packaging bugs. As (for GNOME and a lot of other tools) we simply
>   package upstream, it would be most better to point directly to the
>   right place to file bugs.

If ABRT is a firehose of bugs flying to RH's bugzilla, would the situation be
really better if the reports were sent to gnome's BZ?

I believe ABRT has the possibility to not send report for some application,
would it make more sense to just stop sending these reports then?
If no-one looks at them and all they do is clutter the BZ and give our user a
sense of being neglected, is it really interested?

Maybe we could list all the GNOME components and block all of which where ABRT
is more deleterious than beneficial?
Ideally, I guess we should revisit this list periodically to check with
maintainers if they still wish to be on that list or if they wish to give ABRT a
try again.


Food for thoughts :)
Pierre
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Bastien Nocera]

- Original Message -

> Could you elaborate a little on your reasoning/thoughts please?
> 
> I am quite interesting to understand your point of view.
> From where I stand, we are offering a way for someone to unlock someone's
> else
> computer without a password.
> I understand the procedure isn't straight forward:
> - Find unattended and unlocked laptop
> - Enroll your fingerprint
> - Gain access to the computer whenever you want
> 
> I do realise that to do the second step you need access to the machine, which
> is
> pretty much the third step.
> But enrolling your fingerprint is likely less noticeable by the owner of the
> machine then, say, changing their password (which actually asks for the
> current
> password first), but will give you want you ask: permanent access to the
> machine
> (physically).

Password prompts in GNOME do mention that the fingerprint reader is activated, 
so
it's not so much opening a backdoor as opening the bay window next to the front
door.

> This is all nicely theoretical but it still seems like something that should
> be
> fixed, no?

It keeps slipping by, and it's not super important, which is the reason why it
keeps getting forgotten.

I'll get to it next time I do maintenance on fprintd.

Cheers
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Bastien Nocera]

- Original Message -
> 
> 
> - Original Message -
> > I'm seeing 24 bugs at:
> > https://apps.fedoraproject.org/packages/fprintd/bugs/all
> > including a potential security one: https://bugzilla.redhat.com/1333882
> 
> Fedora's bugzilla is a garbage fire as far as I'm concerned. I already made
> that abundantly clear I think.

I said "garbage fire" when I meant "tire fire". It keeps on burning and I'm
too lazy/busy to handle those bugs downstream when the majority of the work,
triaging and discussions happen upstream.

I should also note that the Red Hat bugzilla is far too coarse for handling
split-up projects like gnome-control-center and gnome-settings-daemon, both of
which are connected to multiple system layers (the kernel, systemd, a lot
of specialised daemons, windowing systems, and their dependencies) and which
have separate maintainers upstream.

Apologies again for the vocabulary used.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Bastien Nocera]

For which one of the problems you listed? It would certainly have been 
interesting to list those in your original mail.

- Original Message -
> On 09/13/2016 11:09 AM, Daniel P. Berrange wrote:
> > On Tue, Sep 13, 2016 at 10:00:32AM -0500, Michael Catanzaro wrote:
> >> Hi,
> >>
> >> To be clear, the problem is that a small handful of package maintainers
> >> (including Bastien) are collectively "responsible" for all of the GNOME
> >> and freedesktop components in Fedora (including fprintd), and it's
> >> simply not reasonable to expect them to read all the bugs that are
> >> assigned to them, let alone take the time to forward them upstream. If
> >> you use Red Hat Bugzilla, the right developers may never notice your
> >> bug report at all.
> >>
> >> You have a much better chance filing bugs upstream. You should only use
> >> Red Hat Bugzilla for these components if you happen to know there is a
> >> specific maintainer who actually looks at the Red Hat bugs for that
> >> specific component, or if you're planning to propose it as a release
> >> blocker, or if you just don't care whether anybody sees your bug. If
> >> you have a packaging bug then it's the right place, but please ping
> >> someone to be sure it gets noticed.
> >>
> >> Of course this is not how Bugzilla is intended to work, but it is how
> >> it actually works for GNOME stuff. It's unfortunate, but without some
> >> Launchpad-style automatic bug forwarding, this is going to remain the
> >> case indefinitely.
> > 
> > This is a truly awful experiance from POV of a Fedora user filing bugs :-(
> > We've set a silent trap for them with no warning of the fact that their
> > bug reports are going to be ignored until Fedora EOL procedure closes
> > them :-(
> > 
> > Even if we can't enhance Red hat Bugzilla, we can at least do more to
> > alert users to this so they stand a chance of doing the right thing.
> > 
> > eg, update the component description to tell user to file in GNOME
> > bugzilla instead, and have a bot that adds a comment to any new bugs
> > that are still filed, closing them WONTFIX and asking the user to
> > re-open against upstream GNOME bugzilla, instead of leaving the bug
> > open and ignored until Fedora EOL.
> > 
> > Regards,
> > Daniel
> > 
> Thanks for recognizing this.  I am the OP.  I pretty quickly got a
> response suggesting that I file a bug report "upstream".  I did that, or
> so I thought, and immediately got a response from someone that it was
> the wrong place or list followed by another declaring the matter closed.
> I went back to my day job.
> 
> 
> --
> Roger Wells, P.E.
> leidos
> 221 Third St
> Newport, RI 02840
> 401-847-4210 (voice)
> 401-849-1585 (fax)
> roger.k.we...@leidos.com
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
> 
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Bastien Nocera]

- Original Message -
> Hi,
> 
> To be clear, the problem is that a small handful of package maintainers
> (including Bastien) are collectively "responsible" for all of the GNOME
> and freedesktop components in Fedora (including fprintd), and it's
> simply not reasonable to expect them to read all the bugs that are
> assigned to them, let alone take the time to forward them upstream. If
> you use Red Hat Bugzilla, the right developers may never notice your
> bug report at all.
> 
> You have a much better chance filing bugs upstream. You should only use
> Red Hat Bugzilla for these components if you happen to know there is a
> specific maintainer who actually looks at the Red Hat bugs for that
> specific component, or if you're planning to propose it as a release
> blocker, or if you just don't care whether anybody sees your bug. If
> you have a packaging bug then it's the right place, but please ping
> someone to be sure it gets noticed.
> 
> Of course this is not how Bugzilla is intended to work, but it is how
> it actually works for GNOME stuff. It's unfortunate, but without some
> Launchpad-style automatic bug forwarding, this is going to remain the
> case indefinitely.

Couldn't have put it better, thanks.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Pierre-Yves Chibon]

On Tue, Sep 13, 2016 at 12:24:33PM -0400, Bastien Nocera wrote:
> 
> 
> - Original Message -
> > On Tue, Sep 13, 2016 at 07:30:07AM -0400, Bastien Nocera wrote:
> > > 
> > > 
> > > - Original Message -
> > > > I'm seeing 24 bugs at:
> > > > https://apps.fedoraproject.org/packages/fprintd/bugs/all
> > > > including a potential security one: https://bugzilla.redhat.com/1333882
> > > 
> > > Fedora's bugzilla is a garbage fire as far as I'm concerned. I already 
> > > made
> > > that abundantly clear I think.
> > 
> > Well, https://bugzilla.redhat.com/1333882 is a security bug, blocking:
> > https://bugzilla.redhat.com/1305770 which mentions:
> > ``
> > Upstream bug:
> > 
> > https://bugs.freedesktop.org/show_bug.cgi?id=89407
> > ``
> > 
> > and:
> > ``
> > This issue has been reported as far back as 2011:
> > 
> > https://bugzilla.gnome.org/show_bug.cgi?id=651196
> > ``
> > 
> > So, you may not care about Red Hat bugzilla, but there is a security bug
> > issued
> > in there for more than 6 months and which is referencing a bug "upstreamed"
> > for
> > 5 years.
> 
> Which I don't consider to be a security bug, hence the reason why I didn't 
> touch it.

Could you elaborate a little on your reasoning/thoughts please?

I am quite interesting to understand your point of view.
From where I stand, we are offering a way for someone to unlock someone's else
computer without a password.
I understand the procedure isn't straight forward:
- Find unattended and unlocked laptop
- Enroll your fingerprint
- Gain access to the computer whenever you want

I do realise that to do the second step you need access to the machine, which is
pretty much the third step.
But enrolling your fingerprint is likely less noticeable by the owner of the
machine then, say, changing their password (which actually asks for the current
password first), but will give you want you ask: permanent access to the machine
(physically).

This is all nicely theoretical but it still seems like something that should be
fixed, no?


Thanks,
Pierre
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Bastien Nocera]

- Original Message -

> This is a truly awful experiance from POV of a Fedora user filing bugs :-(
> We've set a silent trap for them with no warning of the fact that their
> bug reports are going to be ignored until Fedora EOL procedure closes
> them :-(
> 
> Even if we can't enhance Red hat Bugzilla, we can at least do more to
> alert users to this so they stand a chance of doing the right thing.
> 
> eg, update the component description to tell user to file in GNOME
> bugzilla instead, and have a bot that adds a comment to any new bugs
> that are still filed, closing them WONTFIX and asking the user to
> re-open against upstream GNOME bugzilla, instead of leaving the bug
> open and ignored until Fedora EOL.

A couple of things could be done to help with that:
- Bring back the x-bugzilla .desktop metadata, and have ABRT file upstream bugs
- Make ABRT reports more useful (right now it's attaches a *lot* of extra
  information, basically everything it can, as files). It's not possible
  to search for parts of backtraces in the query tool.
- More useful templates when filing bugs, explaining where to file RFEs and
  non-packaging bugs. As (for GNOME and a lot of other tools) we simply
  package upstream, it would be most better to point directly to the
  right place to file bugs.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Bastien Nocera]

- Original Message -
> On Tue, Sep 13, 2016 at 07:30:07AM -0400, Bastien Nocera wrote:
> > 
> > 
> > - Original Message -
> > > I'm seeing 24 bugs at:
> > > https://apps.fedoraproject.org/packages/fprintd/bugs/all
> > > including a potential security one: https://bugzilla.redhat.com/1333882
> > 
> > Fedora's bugzilla is a garbage fire as far as I'm concerned. I already made
> > that abundantly clear I think.
> 
> Well, https://bugzilla.redhat.com/1333882 is a security bug, blocking:
> https://bugzilla.redhat.com/1305770 which mentions:
> ``
> Upstream bug:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=89407
> ``
> 
> and:
> ``
> This issue has been reported as far back as 2011:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=651196
> ``
> 
> So, you may not care about Red Hat bugzilla, but there is a security bug
> issued
> in there for more than 6 months and which is referencing a bug "upstreamed"
> for
> 5 years.

Which I don't consider to be a security bug, hence the reason why I didn't 
touch it.

> To me it looks like there is something in your "garbage" that needs a little
> attention.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

ppisar pushed to perl (master). "Remove old obsoleting perl-ExtUtils-Typemaps (..more)"

[notifications]

From 7032c6382ae38503fc809a9ef5db8b0c14a694c3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Tue, 13 Sep 2016 18:02:33 +0200
Subject: Remove old obsoleting perl-ExtUtils-Typemaps

Last perl-ExtUtils-Typemaps build existed in Fedora 17.
---
 perl.spec | 1 -
 1 file changed, 1 deletion(-)

diff --git a/perl.spec b/perl.spec
index 98ef868..d983b04 100644
--- a/perl.spec
+++ b/perl.spec
@@ -1331,7 +1331,6 @@ Requires:   %perl_compat
 %gendep_perl_ExtUtils_ParseXS
 %endif
 BuildArch:  noarch
-Obsoletes:  perl-ExtUtils-Typemaps
 
 %description ExtUtils-ParseXS
 ExtUtils::ParseXS will compile XS code into C code by embedding the constructs
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl.git/commit/?h=master=7032c6382ae38503fc809a9ef5db8b0c14a694c3
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar pushed to perl-Test-Harness (master). "Remove old obsoleting perl-TAP-Harness-Env (..more)"

[notifications]

From 029d0a1ed40423c9bc512d3b90d0abf3445d1d03 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Tue, 13 Sep 2016 18:08:26 +0200
Subject: Remove old obsoleting perl-TAP-Harness-Env

Last perl-TAP-Harness-Env build existed in Fedora 20.
---
 perl-Test-Harness.spec | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/perl-Test-Harness.spec b/perl-Test-Harness.spec
index 3d1a6ee..f0820d0 100644
--- a/perl-Test-Harness.spec
+++ b/perl-Test-Harness.spec
@@ -1,6 +1,6 @@
 Name:   perl-Test-Harness
 Version:3.36
-Release:367%{?dist}
+Release:368%{?dist}
 Summary:Run Perl standard test scripts with statistics
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -53,8 +53,6 @@ BuildRequires:  perl(TAP::Formatter::HTML) >= 0.10
 BuildRequires:  perl(YAML)
 %endif
 Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
-# perl-Test-Harness >= 3.29 delivers perl-TAP-Harness-Env files, bug #1067098
-Obsoletes:  perl-TAP-Harness-Env
 
 # Filter example dependencies
 %global __requires_exclude_from 
%{?__requires_exclude_from:%__requires_exclude_from|}^%{_datadir}/doc
@@ -93,6 +91,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Tue Sep 13 2016 Petr Pisar  - 3.36-368
+- Remove old obsoleting perl-TAP-Harness-Env
+
 * Wed Aug 03 2016 Jitka Plesnikova  - 3.36-367
 - Avoid loading optional modules from default . (CVE-2016-1238)
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Test-Harness.git/commit/?h=master=029d0a1ed40423c9bc512d3b90d0abf3445d1d03
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar pushed to perl-ExtUtils-ParseXS (master). "Remove old obsoleting perl-ExtUtils-Typemaps (..more)"

[notifications]

From 7754663c30881dd590b7128e12d8155f3303971a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Tue, 13 Sep 2016 17:58:05 +0200
Subject: Remove old obsoleting perl-ExtUtils-Typemaps

Last perl-ExtUtils-Typemaps build existed in Fedora 17.
---
 perl-ExtUtils-ParseXS.spec | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/perl-ExtUtils-ParseXS.spec b/perl-ExtUtils-ParseXS.spec
index f04b6ee..57ba874 100644
--- a/perl-ExtUtils-ParseXS.spec
+++ b/perl-ExtUtils-ParseXS.spec
@@ -3,7 +3,7 @@ Name:   perl-ExtUtils-ParseXS
 # Epoch to compete with perl.spec
 Epoch:  1
 Version:3.31
-Release:366%{?dist}
+Release:367%{?dist}
 Summary:Module and a script for converting Perl XS code into C code
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -44,8 +44,6 @@ BuildRequires:  perl(overload)
 BuildRequires:  perl(Test::More) >= 0.47
 Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 Requires:   perl(Exporter) >= 5.57
-# perl-ExtUtils-Typemaps has been merged into perl-ExtUtils-ParseXS, bug 
#891952
-Obsoletes:  perl-ExtUtils-Typemaps
 
 # Remove under-specified dependencies
 %global __requires_exclude 
%{?__requires_exclude:%__requires_exclude|}^perl\\(Exporter\\)$
@@ -83,6 +81,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Tue Sep 13 2016 Petr Pisar  - 1:3.31-367
+- Remove old obsoleting perl-ExtUtils-Typemaps
+
 * Wed Aug 03 2016 Jitka Plesnikova  - 1:3.31-366
 - Avoid loading optional modules from default . (CVE-2016-1238)
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-ExtUtils-ParseXS.git/commit/?h=master=7754663c30881dd590b7128e12d8155f3303971a
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar pushed to perl-ExtUtils-ParseXS (master). "Cosmetic changes in the spec file"

[notifications]

From 257d55d068d145ead122e453e58ab49692ede701 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Tue, 13 Sep 2016 18:00:03 +0200
Subject: Cosmetic changes in the spec file

---
 perl-ExtUtils-ParseXS.spec | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/perl-ExtUtils-ParseXS.spec b/perl-ExtUtils-ParseXS.spec
index 57ba874..ccbbf52 100644
--- a/perl-ExtUtils-ParseXS.spec
+++ b/perl-ExtUtils-ParseXS.spec
@@ -18,6 +18,8 @@ BuildRequires:  coreutils
 BuildRequires:  findutils
 BuildRequires:  make
 BuildRequires:  perl
+BuildRequires:  perl-devel
+BuildRequires:  perl-generators
 BuildRequires:  perl(Config)
 BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.46
 BuildRequires:  perl(File::Spec)
@@ -32,8 +34,6 @@ BuildRequires:  perl(File::Basename)
 BuildRequires:  perl(re)
 BuildRequires:  perl(Symbol)
 # Tests:
-BuildRequires:  perl-devel
-BuildRequires:  perl-generators
 BuildRequires:  perl(attributes)
 BuildRequires:  perl(Carp)
 BuildRequires:  perl(DynaLoader)
@@ -64,7 +64,7 @@ make %{?_smp_mflags}
 
 %install
 make pure_install DESTDIR=$RPM_BUILD_ROOT
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+find $RPM_BUILD_ROOT -type f -name .packlist -delete
 %{_fixperms} $RPM_BUILD_ROOT/*
 # Do not install xsubpp twice, RT#117289
 rm $RPM_BUILD_ROOT%{perl_vendorlib}/ExtUtils/xsubpp
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-ExtUtils-ParseXS.git/commit/?h=master=257d55d068d145ead122e453e58ab49692ede701
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: F24, small backward steps

[Rich Mattes]

On Tue, Sep 13, 2016 at 11:43 AM, Ralf Corsepius  wrote:
> On 09/13/2016 05:09 PM, Daniel P. Berrange wrote:
>
>> This is a truly awful experiance from POV of a Fedora user filing bugs :-(
>> We've set a silent trap for them with no warning of the fact that their
>> bug reports are going to be ignored until Fedora EOL procedure closes
>> them :-(
>
>
> One lesson I have learnt in Fedora, is that filing bugs reports against
> packages owned by certain people equals to sending bugs to /dev/null.
>
> IMHO, Fedora should consider to take disciplinary measures against these
> people.
>
> Ralf
>

For what it's worth, there are a set of Package Maintainer
Responsibilities[1] on the wiki.  The section "Deal with reported bugs
in a timely manner" does offer suggestions for what to do if you find
yourself unable to handle bug reports, but there's no discussion of
what to do when a package maintainer is not living up to these
responsibilities.  I agree that it would be good to try to outline an
approach to address cases where a package maintainer is not honoring
these responsibilities, would a FESCo ticket be the correct forum?

Rich

[1] https://fedoraproject.org/wiki/Package_maintainer_responsibilities
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Ralf Corsepius]

On 09/13/2016 05:09 PM, Daniel P. Berrange wrote:


This is a truly awful experiance from POV of a Fedora user filing bugs :-(
We've set a silent trap for them with no warning of the fact that their
bug reports are going to be ignored until Fedora EOL procedure closes
them :-(


One lesson I have learnt in Fedora, is that filing bugs reports against 
packages owned by certain people equals to sending bugs to /dev/null.


IMHO, Fedora should consider to take disciplinary measures against these 
people.


Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Roger Wells]

On 09/13/2016 11:09 AM, Daniel P. Berrange wrote:
> On Tue, Sep 13, 2016 at 10:00:32AM -0500, Michael Catanzaro wrote:
>> Hi,
>>
>> To be clear, the problem is that a small handful of package maintainers
>> (including Bastien) are collectively "responsible" for all of the GNOME
>> and freedesktop components in Fedora (including fprintd), and it's
>> simply not reasonable to expect them to read all the bugs that are
>> assigned to them, let alone take the time to forward them upstream. If
>> you use Red Hat Bugzilla, the right developers may never notice your
>> bug report at all.
>>
>> You have a much better chance filing bugs upstream. You should only use
>> Red Hat Bugzilla for these components if you happen to know there is a
>> specific maintainer who actually looks at the Red Hat bugs for that
>> specific component, or if you're planning to propose it as a release
>> blocker, or if you just don't care whether anybody sees your bug. If
>> you have a packaging bug then it's the right place, but please ping
>> someone to be sure it gets noticed.
>>
>> Of course this is not how Bugzilla is intended to work, but it is how
>> it actually works for GNOME stuff. It's unfortunate, but without some
>> Launchpad-style automatic bug forwarding, this is going to remain the
>> case indefinitely.
> 
> This is a truly awful experiance from POV of a Fedora user filing bugs :-(
> We've set a silent trap for them with no warning of the fact that their
> bug reports are going to be ignored until Fedora EOL procedure closes
> them :-(
> 
> Even if we can't enhance Red hat Bugzilla, we can at least do more to
> alert users to this so they stand a chance of doing the right thing.
> 
> eg, update the component description to tell user to file in GNOME
> bugzilla instead, and have a bot that adds a comment to any new bugs
> that are still filed, closing them WONTFIX and asking the user to
> re-open against upstream GNOME bugzilla, instead of leaving the bug
> open and ignored until Fedora EOL.
> 
> Regards,
> Daniel
> 
Thanks for recognizing this.  I am the OP.  I pretty quickly got a
response suggesting that I file a bug report "upstream".  I did that, or
so I thought, and immediately got a response from someone that it was
the wrong place or list followed by another declaring the matter closed.
I went back to my day job.


-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Daniel P. Berrange]

On Tue, Sep 13, 2016 at 10:00:32AM -0500, Michael Catanzaro wrote:
> Hi,
> 
> To be clear, the problem is that a small handful of package maintainers
> (including Bastien) are collectively "responsible" for all of the GNOME
> and freedesktop components in Fedora (including fprintd), and it's
> simply not reasonable to expect them to read all the bugs that are
> assigned to them, let alone take the time to forward them upstream. If
> you use Red Hat Bugzilla, the right developers may never notice your
> bug report at all.
> 
> You have a much better chance filing bugs upstream. You should only use
> Red Hat Bugzilla for these components if you happen to know there is a
> specific maintainer who actually looks at the Red Hat bugs for that
> specific component, or if you're planning to propose it as a release
> blocker, or if you just don't care whether anybody sees your bug. If
> you have a packaging bug then it's the right place, but please ping
> someone to be sure it gets noticed.
> 
> Of course this is not how Bugzilla is intended to work, but it is how
> it actually works for GNOME stuff. It's unfortunate, but without some
> Launchpad-style automatic bug forwarding, this is going to remain the
> case indefinitely.

This is a truly awful experiance from POV of a Fedora user filing bugs :-(
We've set a silent trap for them with no warning of the fact that their
bug reports are going to be ignored until Fedora EOL procedure closes
them :-(

Even if we can't enhance Red hat Bugzilla, we can at least do more to
alert users to this so they stand a chance of doing the right thing.

eg, update the component description to tell user to file in GNOME
bugzilla instead, and have a bot that adds a comment to any new bugs
that are still filed, closing them WONTFIX and asking the user to
re-open against upstream GNOME bugzilla, instead of leaving the bug
open and ignored until Fedora EOL.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Michael Catanzaro]

Hi,

To be clear, the problem is that a small handful of package maintainers
(including Bastien) are collectively "responsible" for all of the GNOME
and freedesktop components in Fedora (including fprintd), and it's
simply not reasonable to expect them to read all the bugs that are
assigned to them, let alone take the time to forward them upstream. If
you use Red Hat Bugzilla, the right developers may never notice your
bug report at all.

You have a much better chance filing bugs upstream. You should only use
Red Hat Bugzilla for these components if you happen to know there is a
specific maintainer who actually looks at the Red Hat bugs for that
specific component, or if you're planning to propose it as a release
blocker, or if you just don't care whether anybody sees your bug. If
you have a packaging bug then it's the right place, but please ping
someone to be sure it gets noticed.

Of course this is not how Bugzilla is intended to work, but it is how
it actually works for GNOME stuff. It's unfortunate, but without some
Launchpad-style automatic bug forwarding, this is going to remain the
case indefinitely.

Michael
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Pierre-Yves Chibon]

On Tue, Sep 13, 2016 at 07:30:07AM -0400, Bastien Nocera wrote:
> 
> 
> - Original Message -
> > I'm seeing 24 bugs at:
> > https://apps.fedoraproject.org/packages/fprintd/bugs/all
> > including a potential security one: https://bugzilla.redhat.com/1333882
> 
> Fedora's bugzilla is a garbage fire as far as I'm concerned. I already made
> that abundantly clear I think.

Well, https://bugzilla.redhat.com/1333882 is a security bug, blocking:
https://bugzilla.redhat.com/1305770 which mentions:
``
Upstream bug:

https://bugs.freedesktop.org/show_bug.cgi?id=89407
``

and:
``
This issue has been reported as far back as 2011:

https://bugzilla.gnome.org/show_bug.cgi?id=651196
``

So, you may not care about Red Hat bugzilla, but there is a security bug issued
in there for more than 6 months and which is referencing a bug "upstreamed" for
5 years.

To me it looks like there is something in your "garbage" that needs a little
attention.


Pierre
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel] Re: Strategy for Node.js upgrade in EPEL 7

[Jim Perrin]

On 09/13/2016 08:28 AM, Stephen Gallagher wrote:

>> Due to upstream terminating support for 0.10.x on 2016-10-01, we *will* be
>> cutting over to 6.x on or around that date, so this testing request is
>> time-sensitive.

I'm wondering if it might not be prudent to put something in fedora
magazine about this that we could redistribute or link-to for CentOS as
well. This change seems like it deserves making some community noise
beyond some threads on the mailing list.


Thoughts?



-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77



signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Strategy for Node.js upgrade in EPEL 7

[Stephen Gallagher]

Apologies for the re-send, but I typoed the epel-devel email address on the
first try.

On 09/13/2016 09:27 AM, Stephen Gallagher wrote:
> Yesterday, I built the latest upstream version of Node.js for EPEL 7 (this
> version will be supported until 2019-04-01)
> 
> I have added it to the buildroot overrides so that anyone can rebuild their 
> npm
> modules at will. This *is* an API/ABI-breaking upgrade, so some modules will
> fail to function on this version. We don't know ahead of time which ones will 
> do
> so, except for binary modules.
> 
> I am electing *not* to build in a side-tag for this. Many of the noarch 
> packages
> will just work (or they won't, and a rebuild wouldn't help us detect this). I 
> am
> therefore putting out a request to anyone using nodejs-* packages in EPEL to
> please install nodejs from epel-testing[2] and help us find any issues before
> October.
> 
> If you maintain a nodejs-* package in EPEL, please test that it continues to
> work with Node.js 6.x. If it does not, please update it and build it in Koji. 
> If
> the update is compatible with 0.10.x, feel free to submit it to Bodhi; if it 
> is
> not (or you simply want to push them all together), please notify me directly 
> I
> will add it to the Bodhi update for nodejs so that it goes stable at the same
> time as the interpreter.
> 
> 
> 
> Due to upstream terminating support for 0.10.x on 2016-10-01, we *will* be
> cutting over to 6.x on or around that date, so this testing request is
> time-sensitive.
> 
> 
> [1] There's a long story behind this, but the short version is that the 
> bundling
> style of npm makes it basically impossible to maintain, as even bugfix 
> releases
> result in a huge tangled mess of dependencies. It is infeasible to keep up 
> with
> bugfix and security updates. Node.js upstream is highly responsible and
> responsive about security issues, so we considered it an acceptable risk to
> bundle npm with the main package.
> 
> [2] https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-epel/ also has
> it, if your epel-testing mirrors don't have it yet.




signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

ppisar pushed to perl-Frontier-RPC (master). "Correct change name (..more)"

[notifications]

From 4c4a2d23ea17d1df77475d96c57a4383616956cf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Tue, 13 Sep 2016 14:01:44 +0200
Subject: Correct change name

The patch is not about FTP.
---
 perl-Frontier-RPC.spec | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/perl-Frontier-RPC.spec b/perl-Frontier-RPC.spec
index cf9dc1d..61edf32 100644
--- a/perl-Frontier-RPC.spec
+++ b/perl-Frontier-RPC.spec
@@ -11,7 +11,7 @@ Patch1: perl-frontier-raw-serve.patch
 Patch2: perl-frontier-undef-scalar.patch
 Patch3: security-xml-external-entity.patch
 Patch4: apache2.patch
-# Respect proxy setting for HTTPS, FTP, and FTP, bug #832390, CPAN RT#117812
+# Respect proxy setting for HTTPS, bug #832390, CPAN RT#117812
 Patch5: Frontier-RPC-0.07b4p1-Respect-proxy-setting-for-HTTPS.patch
 BuildArch:  noarch
 BuildRequires:  perl
@@ -92,7 +92,7 @@ make test
 
 %changelog
 * Tue Sep 13 2016 Petr Pisar  - 0.07b4p1-27
-- Respect proxy setting for HTTPS, FTP, and FTP (bug #832390)
+- Respect proxy setting for HTTPS (bug #832390)
 
 * Mon May 16 2016 Jitka Plesnikova  - 0.07b4p1-26
 - Perl 5.24 rebuild
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Frontier-RPC.git/commit/?h=master=4c4a2d23ea17d1df77475d96c57a4383616956cf
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar pushed to perl-Frontier-RPC (master). "Respect proxy setting for HTTPS, FTP, and FTP"

[notifications]

From 0748904343bfb047b4716c894a9befe4b24f56db Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Tue, 13 Sep 2016 13:03:35 +0200
Subject: Respect proxy setting for HTTPS, FTP, and FTP

---
 ...-0.07b4p1-Respect-proxy-setting-for-HTTPS.patch | 36 ++
 perl-Frontier-RPC.spec |  8 -
 2 files changed, 43 insertions(+), 1 deletion(-)
 create mode 100644 Frontier-RPC-0.07b4p1-Respect-proxy-setting-for-HTTPS.patch

diff --git a/Frontier-RPC-0.07b4p1-Respect-proxy-setting-for-HTTPS.patch 
b/Frontier-RPC-0.07b4p1-Respect-proxy-setting-for-HTTPS.patch
new file mode 100644
index 000..e9ddb51
--- /dev/null
+++ b/Frontier-RPC-0.07b4p1-Respect-proxy-setting-for-HTTPS.patch
@@ -0,0 +1,36 @@
+From c5ffabf72c254ba3c185b0234ca77e0525eed57f Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
+Date: Tue, 13 Sep 2016 13:00:14 +0200
+Subject: [PATCH] Respect proxy setting for HTTPS
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+URLs different from http schema ignored specified proxy. This patch
+passes the proxy setting for http and https schemata.
+
+Signed-off-by: Petr Písař 
+---
+ lib/Frontier/Client.pm | 6 --
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/lib/Frontier/Client.pm b/lib/Frontier/Client.pm
+index 6ea7b60..a7bdce2 100644
+--- a/lib/Frontier/Client.pm
 b/lib/Frontier/Client.pm
+@@ -28,8 +28,10 @@ sub new {
+   if !defined $self->{'url'};
+ 
+ $self->{'ua'} = LWP::UserAgent->new;
+-$self->{'ua'}->proxy('http', $self->{'proxy'})
+-  if(defined $self->{'proxy'});
++my @schemes = grep { $self->{'ua'}->is_protocol_supported($_) }
++  qw/http https/;
++$self->{'ua'}->proxy([@schemes], $self->{'proxy'})
++  if(defined $self->{'proxy'} && @schemes);
+ $self->{'rq'} = HTTP::Request->new (POST => $self->{'url'});
+ $self->{'rq'}->header('Content-Type' => 'text/xml');
+ # Patch to enable basic authentication:
+-- 
+2.7.4
+
diff --git a/perl-Frontier-RPC.spec b/perl-Frontier-RPC.spec
index d75a5c6..cf9dc1d 100644
--- a/perl-Frontier-RPC.spec
+++ b/perl-Frontier-RPC.spec
@@ -1,7 +1,7 @@
 Summary:A Perl interface for making and serving XML-RPC calls
 Name:   perl-Frontier-RPC
 Version:0.07b4p1
-Release:26%{?dist}
+Release:27%{?dist}
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Frontier-RPC/
@@ -11,6 +11,8 @@ Patch1: perl-frontier-raw-serve.patch
 Patch2: perl-frontier-undef-scalar.patch
 Patch3: security-xml-external-entity.patch
 Patch4: apache2.patch
+# Respect proxy setting for HTTPS, FTP, and FTP, bug #832390, CPAN RT#117812
+Patch5: Frontier-RPC-0.07b4p1-Respect-proxy-setting-for-HTTPS.patch
 BuildArch:  noarch
 BuildRequires:  perl
 BuildRequires:  perl-generators
@@ -63,6 +65,7 @@ Documentation and examples to Frontier::RPC and 
Frontier::RPC::Client.
 %patch2 -p1
 %patch3 -p1
 %patch4 -p1
+%patch5 -p1
 
 %build
 perl Makefile.PL INSTALLDIRS=vendor
@@ -88,6 +91,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Tue Sep 13 2016 Petr Pisar  - 0.07b4p1-27
+- Respect proxy setting for HTTPS, FTP, and FTP (bug #832390)
+
 * Mon May 16 2016 Jitka Plesnikova  - 0.07b4p1-26
 - Perl 5.24 rebuild
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Frontier-RPC.git/commit/?h=master=0748904343bfb047b4716c894a9befe4b24f56db
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Ground rules for riscv64 in Fedora dist-git

[Richard W.M. Jones]

On Tue, Sep 13, 2016 at 11:32:26AM +0200, Florian Weimer wrote:
> On 09/12/2016 08:55 PM, Richard W.M. Jones wrote:
> >On Mon, Sep 12, 2016 at 07:48:31PM +0100, Richard W.M. Jones wrote:
> >>On Mon, Sep 12, 2016 at 09:06:59AM +0200, Florian Weimer wrote:
> >>>I had a brief look at the glibc patches.  Apparently, off_t and
> >>>time_t are 32-bit.  For a new architecture, that's quite strange.
> >
> >How do you determine this?
> 
> I looked at the patch.
> 
> >I wrote a simple program which prints sizeof (off_t) and sizeof (time_t)
> >inside the RISC-V environment.  I *didn't* define
> >`-D_FILE_OFFSET_BITS=64' when compiling the program.  Both values are
> >printed as 8 (bytes).  So it seems we're OK?
> 
> Yes, for 64-bit.  But the 32-bit parts do not look acceptable as-is.

Fair enough.  For Fedora we are only building for 64 bit[1].  There
aren't even multilib 32 bit libs.  (I'm not saying someone couldn't
come along and add that later, but initially we're not considering it)

The reasons for this are:

- There is no legacy of 32 bit code to support.

- By the time this is available, people will care even less about 32 bit.

- I've even talked to embedded manufacturers who intend to jump
straight to RV64 (which surprised me because RV32 is designed for
embedded uses).

> If you only want the 64-bit architecture, then getting the author to
> submit only the 64-bit parts first to glibc upstream would be the
> prudent thing to do.  (This has to come from the patch author, and
> the author has to assign copyright to the FSF.)

I've been telling everyone who will listen that they should get their
changes upstream.

Rich.

[1] Specifically for "RV64G" = "RV64IMAFD" = RISC-V, 64 bit with
Integer, Multiplication/division, Atomics, single Floats, and Double
floats.  For more info, see section 10.4 in this document:
https://people.eecs.berkeley.edu/~krste/papers/riscv-spec-2.0.pdf

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Bastien Nocera]

- Original Message -
> I'm seeing 24 bugs at:
> https://apps.fedoraproject.org/packages/fprintd/bugs/all
> including a potential security one: https://bugzilla.redhat.com/1333882

Fedora's bugzilla is a garbage fire as far as I'm concerned. I already made
that abundantly clear I think.

> so I'm not sure what you call 'upstream bugs' but there are bugs reported
> against fprintd.

By upstream, I mean upstream. That's https://bugs.freedesktop.org for fprintd.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Pierre-Yves Chibon]

On Tue, Sep 13, 2016 at 07:05:32AM -0400, Bastien Nocera wrote:
> 
> 
> - Original Message -
> > 
> > 
> > Dne 9.9.2016 v 21:53 Roger Wells napsal(a):
> > > Just a couple of smallish things after upgrading (via dnf) from F23 to
> > > F24 a couple of months ago:
> > >
> > >
> > > 2. fingerprint identification:
> > >
> > > The laptop has a fingerprint reader and it works fine.  However
> > > I prefer not to use it. The user set up specifies that fingerprint login
> > > is disabled.
> > >
> > > However whenever I am asked for a password the fingerprint
> > > reader blinks until I swipe a finger over it (even after using a
> > > password).
> > >
> > > No fingerprint is registered.
> > >
> > > This is different than F23 where it never blinked.
> > >
> > >
> > 
> > 
> > If I am not mistaken "dnf remove fprintd-pam" should completely disable
> > the fingerprint reader, although you might observe some error messages
> > in your journal later.
> > 
> > But don't worry, the fprind daemon is broken for ages and nobody cares,
> > so it might work once, but then it crashes ...
> 
> There's no upstream bugs against fprintd specifically, so, like, you're wrong?

I'm seeing 24 bugs at:
https://apps.fedoraproject.org/packages/fprintd/bugs/all
including a potential security one: https://bugzilla.redhat.com/1333882

so I'm not sure what you call 'upstream bugs' but there are bugs reported
against fprintd.


Pierre
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Bastien Nocera]

- Original Message -
> 
> 
> Dne 9.9.2016 v 21:53 Roger Wells napsal(a):
> > Just a couple of smallish things after upgrading (via dnf) from F23 to
> > F24 a couple of months ago:
> >
> >
> > 2. fingerprint identification:
> >
> > The laptop has a fingerprint reader and it works fine.  However
> > I prefer not to use it. The user set up specifies that fingerprint login
> > is disabled.
> >
> > However whenever I am asked for a password the fingerprint
> > reader blinks until I swipe a finger over it (even after using a
> > password).
> >
> > No fingerprint is registered.
> >
> > This is different than F23 where it never blinked.
> >
> >
> 
> 
> If I am not mistaken "dnf remove fprintd-pam" should completely disable
> the fingerprint reader, although you might observe some error messages
> in your journal later.
> 
> But don't worry, the fprind daemon is broken for ages and nobody cares,
> so it might work once, but then it crashes ...

There's no upstream bugs against fprintd specifically, so, like, you're wrong?
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Installing alsa-ucm by default in F25?

[Bastien Nocera]

FWIW, this was done in:
commit 07106ddaa4f45aa188019d497a6a042bd7b58750
Author: Peter Robinson 
Date:   Sat Apr 2 10:24:17 2016 +0100

add alsa-ucm

For F24 and F25.

Thanks!

- Original Message -
> > alsa-ucm contains routing information to setup sound codecs
> > on some machines, usually SoC-based. It contains configuration
> > that's mostly relevant to ARM devices, but also a few Atom (CherryTrail and
> > Broadwell) related SoCs on Intel.
> >
> > Could we install alsa-ucm by default? As it is necessary for PulseAudio to
> > be able to use those devices, should we get it dragged in as a PA
> > dependency?
> 
> I think pulling it in by default is fine, it's tiny in size and has no
> extra deps, I'd add it to comps as opposed to a hard dep on pulseaudio
> though.
> 
> Peter
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
> 
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org