date:20161007

On Oct 7, 2016 1:29 PM, "Frank Ch. Eigler"  wrote:
>
>
> >> > [...]  I always run dnf manually from the
> >> > command line, in a VT logged in as root.  And I can run X while doing
> >> > this and I've never had a dnf update issue.
>
> To the extent that the problem is that dnf gets interrupted when its
> xterm dies, can that be worked around by dnf SIG_IGN'ing SIGHUP /
> SIGPIPE?  Users could still deliberately interrupt it with SIGINT, but a
> terminal closure could in theory let it finish unmolested.
>

Python is weird^Wspecial.  See the bug I opened.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

On Fri, Oct 7, 2016 at 2:32 PM, Andrew Lutomirski  wrote:
> On Oct 7, 2016 12:39 PM, "Adam Williamson" 
> wrote:
>>
>> On Mon, 2016-10-03 at 20:03 +, John Florian wrote:
>> > On Mon, 2016-10-03 at 12:07 -0700, Adam Williamson wrote:
>> > If we do not 'support' livecd-iso-to-disk any more, we no longer
>> > support:
>> >
>> > 1) persistent storage (via overlays)
>> > 2) non-destructive write
>> >
>> >
>> > I've known for quite some time that livecd-tools was/is to be
>> > replaced with livemedia-creator, but only now did I realize that lm-c
>> > won't have persistent storage -- I simply have never had the time to
>> > explore it.  I'm extremely dependent on the persistent storage as my
>> > whole day job revolves around making hundreds of little mostly-
>> > stateless appliances for data collection purposes and has so since
>> > F13 or so.  These have been built with livecd-iso-to-disk and lots of
>> > glue via specialized kickstarts and other custom packages.  These
>> > appliances leverage a stateless OS very robustness, but do expect
>> > some persistent storage for their management.  So the above certainly
>> > caught my attention.
>>
>> There's a slight misconception in the above.
>>
>> livemedia-creator *creates the image files themselves*. We're not
>> talking about that in this thread. We're talking about the tools for
>> taking an image that's been created - whether by livecd-creator or
>> livemedia-creator or anything else - and writing them to a USB stick.
>>
>> The 'persistence' feature requires support both in the image itself and
>> in the tool used to write it. I believe livemedia-creator-produced
>> images are set up to support persistence, just like livecd-creator-
>> produced images were.
>>
>> The issue here is that we are discussing what tools for *writing the
>> image to a USB stick* should be 'supported' / 'recommended' / whatever,
>> and we'd kinda like to drop livecd-iso-to-disk from that group, but it
>> is currently the only one of the 'write image to stick' tools which
>> supports persistence.
>
> At the risk of muddying the waters a bit: now that OverlayFS is here, I
> think that even a dd-copied image should be able to support persistence.
> The image could notice that it's dd-copied (by checking GPT GUIDs or layout
> or whatever), see that there's extra space at the end, and allocate it.
>
> This could reduce the testing explosion a bit if all of the supported image
> writing tools ended up being equivalent to dd.

It's come up, and mbriza has some ideas about how to do it safely, so
we'll see if it's worth the risks.

I'm very skeptical that persistence is a critical necessity, rather
than neat. If you need persistence, the installer should be capable of
installing to your USB stick media and making it a real installed OS
seeing as that's what it's being used for.

Modifying the image at all breaks the existing media verification
option in the boot menu, and we know people get bad writes using bad
or flaky media. We could get this back various ways: embedded sha1sum
of the squashfs.img and have dracut do a comparison at boot time;
dmverity is a valid option geared explicitly for this and can include
Reed-Solomon error correction; and Btrfs. The Btrfs option is kinda
need because a.) it's on-the-fly instead of all at once b.) it's every
time a block is read, not one time, c.) can't be bypassed by the user,
and d.) Btrfs supports overlays with the seed device function. [1]
Seed device was actually intended for this specific use case. And it's
not a new feature, January 2009, upstream considers it stable. [2]


[1]
https://btrfs.wiki.kernel.org/index.php/Seed-device

[2]
https://btrfs.wiki.kernel.org/index.php/Status


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

Re: Installation validation test change proposal: merge USB tests into 'default boot and install', add more environment columns

On Fri, Oct 7, 2016 at 2:08 PM, Adam Williamson
 wrote:
> Hi folks! Sending this to devel@ as well as test@ as there's been some
> relevant discussion there recently. We've been kicking around a couple
> of issues lately:
>
> 1. Exactly what do we need to test and block on, in terms of writing
> images to USB sticks?
>
> 2. 'Default boot and install' table was supposed to require bare metal
> optical media testing at release time, but this is not clear, and
> openQA fills in results despite not testing real media on bare metal.
>
> So here's my proposal to address both topics. It involves changes to
> the Boot_default_install test:
>
> https://fedoraproject.org/wiki/User:Adamwill/Draft_Testcase_Boot_default_install
> https://fedoraproject.org/w/index.php?title=User:Adamwill/Draft_Testcase_Boot_default_install=476645=476644
>
> and the Installation matrix template page:
>
> https://fedoraproject.org/wiki/User:Adamwill/Draft_Installation_test_matrix
> https://fedoraproject.org/w/index.php?title=User:Adamwill/Draft_Installation_test_matrix=476646=476643
>
> to summarize the changes - we improve the test case's wording to give
> explicit instructions for all three media types we care about (virtual
> disc attached to a VM, real optical disc in a real machine, real USB
> stick in a real machine), we ditch the USB test matrices entirely, and
> we give the 'Default boot and install' tables extra result columns so
> they can now reflect results for VM, CD/DVD and USB testing (for BIOS
> and UEFI in all three cases, for x86_64).
>
> I didn't get too finicky about the wording for the virt case, as that's
> basically there to get filled in by openQA anyway. For the CD/DVD case,
> the test case instructs you to write the disc according to the
> 'official instructions', with a URL that is supposed to be always
> provided by the docs project for that purpose. For the USB case, the
> test case instructs you to write the stick according to
> https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB , telling
> you to use the 'most prominently-recommended method'; the intent being
> that, as things stand, we would only block on Fedora Media Writer
> issues. I didn't explicitly cover dd (e.g. with separate FMW and dd
> columns) for two reasons:
>
> 1. It should pretty reliably be the case that if FMW works, dd works
> 2. Some people are going to test plain dd anyway, it's just such a
> convenient 'expert' method that I can't imagine we won't have people
> using it throughout the test period
>
> I didn't cover livecd-iso-to-disk because it seems like, overall, the
> feedback to cmurf's "F26 proposal: Make Fedora Media Writer the
> officially supported USB install media creator" was fairly positive and
> I think justifies not guaranteeing testing for it.
>
> To be clear, this is a trade-off between 'in an ideal world we'd test
> everything' and 'but we really don't have time'. Each additional method
> adds 12 mandatory tests (6 images, both UEFI and BIOS variants of the
> test). We can discount the virt tests, as openQA will do those, so in
> the proposal, there are 24 mandatory tests for humans; if we added dd
> as its own thing there'd be 36, if we added litd as well there'd be 48.
>
> One note is that this doesn't do much to ensure that FMW is working at
> release time in all expected environments (probably at least the two
> previous stable Fedora releases, macOS, and Windows). On the other
> hand, neither does the current matrix; we explicitly list FMW, but we
> don't specify what environments it should be run in. We could consider
> adding a USB table with a slightly different focus, the idea being to
> test the *writing tool* rather than test that the *image* can be
> written and works properly. We could make that a follow-up proposal. If
> we had such a table, it could maybe cover testing livecd-iso-to-disk's
> advanced features as optional tests, or something.
>
> At present I'm not proposing any changes to the *release criteria* (we
> can maybe consider that later). This is just a proposal for what we
> will actually guarantee testing of via the validation process.


Looks and sounds good to me.

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

Fedora Rawhide-20161007.n.0 compose check report

2016-10-07 Thread Fedora compose checker

Missing expected images:

Cloud_base qcow2 x86_64
Atomic qcow2 x86_64
Cloud_base raw-xz x86_64
Atomic raw-xz x86_64

Failed openQA tests: 70/102 (x86_64), 17/17 (i386), 1/2 (arm)

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

ID: 39438   Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/39438
ID: 39439   Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/39439
ID: 39440   Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/39440
ID: 39441   Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/39441
ID: 39442   Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/39442
ID: 39450   Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/39450
ID: 39452   Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/39452
ID: 39453   Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/39453
ID: 39454   Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/39454
ID: 39455   Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/39455
ID: 39456   Test: x86_64 Atomic-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/39456
ID: 39457   Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/39457
ID: 39458   Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/39458
ID: 39466   Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/39466
ID: 39468   Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/39468
ID: 39469   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/39469
ID: 39471   Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/39471
ID: 39472   Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/39472
ID: 39473   Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/39473
ID: 39474   Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/39474
ID: 39480   Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/39480
ID: 39481   Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/39481
ID: 39490   Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/39490
ID: 39492   Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/39492
ID: 39493   Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/39493
ID: 39494   Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/39494
ID: 39495   Test: x86_64 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/39495
ID: 39496   Test: x86_64 universal install_multi
URL: https://openqa.fedoraproject.org/tests/39496
ID: 39497   Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/39497
ID: 39499   Test: x86_64 universal install_simple_free_space
URL: https://openqa.fedoraproject.org/tests/39499
ID: 39501   Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/39501
ID: 39502   Test: x86_64 universal install_delete_partial
URL: https://openqa.fedoraproject.org/tests/39502
ID: 39503   Test: x86_64 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/39503
ID: 39504   Test: x86_64 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/39504
ID: 39505   Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/39505
ID: 39506   Test: x86_64 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/39506
ID: 39507   Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/39507
ID: 39509   Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/39509
ID: 39510   Test: x86_64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/39510
ID: 39511   Test: x86_64 universal install_multi_empty@uefi
URL: https://openqa.fedoraproject.org/tests/39511
ID: 39512   Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/39512
ID: 39513   Test: x86_64 universal

Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

On Oct 7, 2016 12:39 PM, "Adam Williamson" 
wrote:
>
> On Mon, 2016-10-03 at 20:03 +, John Florian wrote:
> > On Mon, 2016-10-03 at 12:07 -0700, Adam Williamson wrote:
> > If we do not 'support' livecd-iso-to-disk any more, we no longer
> > support:
> >
> > 1) persistent storage (via overlays)
> > 2) non-destructive write
> >
> >
> > I've known for quite some time that livecd-tools was/is to be
> > replaced with livemedia-creator, but only now did I realize that lm-c
> > won't have persistent storage -- I simply have never had the time to
> > explore it.  I'm extremely dependent on the persistent storage as my
> > whole day job revolves around making hundreds of little mostly-
> > stateless appliances for data collection purposes and has so since
> > F13 or so.  These have been built with livecd-iso-to-disk and lots of
> > glue via specialized kickstarts and other custom packages.  These
> > appliances leverage a stateless OS very robustness, but do expect
> > some persistent storage for their management.  So the above certainly
> > caught my attention.
>
> There's a slight misconception in the above.
>
> livemedia-creator *creates the image files themselves*. We're not
> talking about that in this thread. We're talking about the tools for
> taking an image that's been created - whether by livecd-creator or
> livemedia-creator or anything else - and writing them to a USB stick.
>
> The 'persistence' feature requires support both in the image itself and
> in the tool used to write it. I believe livemedia-creator-produced
> images are set up to support persistence, just like livecd-creator-
> produced images were.
>
> The issue here is that we are discussing what tools for *writing the
> image to a USB stick* should be 'supported' / 'recommended' / whatever,
> and we'd kinda like to drop livecd-iso-to-disk from that group, but it
> is currently the only one of the 'write image to stick' tools which
> supports persistence.

At the risk of muddying the waters a bit: now that OverlayFS is here, I
think that even a dd-copied image should be able to support persistence.
The image could notice that it's dd-copied (by checking GPT GUIDs or layout
or whatever), see that there's extra space at the end, and allocate it.

This could reduce the testing explosion a bit if all of the supported image
writing tools ended up being equivalent to dd.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 25-20161007.n.0 compose check report

2016-10-07 Thread Fedora compose checker

No missing expected images.

Failed openQA tests: 3/102 (x86_64), 1/17 (i386)

Old failures (same test failed in 25-20161006.n.0):

ID: 39572   Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/39572
ID: 39577   Test: x86_64 Atomic-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/39577
ID: 39668   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/39668
ID: 39678   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/39678

Passed openQA tests: 99/102 (x86_64), 16/17 (i386), 2/2 (arm)

New passes (same test did not pass in 25-20161006.n.0):

ID: 39571   Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/39571
ID: 39578   Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/39578
ID: 39580   Test: x86_64 KDE-live-iso base_selinux
URL: https://openqa.fedoraproject.org/tests/39580
ID: 39581   Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/39581
ID: 39582   Test: x86_64 KDE-live-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/39582
ID: 39583   Test: x86_64 KDE-live-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/39583
ID: 39584   Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/39584
ID: 39585   Test: x86_64 KDE-live-iso desktop_terminal
URL: https://openqa.fedoraproject.org/tests/39585
ID: 39586   Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/39586
ID: 39588   Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/39588
ID: 39676   Test: i386 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/39676
ID: 39677   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/39677
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Weak password madness is back again


Hi,

On 07-10-16 18:03, Adam Williamson wrote:

On Fri, 2016-10-07 at 15:56 +0200, Hans de Goede wrote:

Hi,

So 2 devel cycles ago we had this whole discussion
about how forcing people to choose strong passwords in anaconda
was making live hard for testers / test-installs and this
decision was reverted.

So now here I'm doing a F25 Fedora ARM test install, end up
in the gnome-ified first-time-setup wizzard and cannot continue
until I make my test-user password strong enough. UGH.

So can we get this fixed please, or do we need to escalate
this all the way up to FESco again ?


It's a game. Every time we get it changed in one place, it gets changed
the other way in another place...=)

For now, you can create a user account during the install process
(rather than in gnome-initial-setup) if you want a weak password.


No such luck with the ARM sdcard images though, those are
"pre-installed" and for the workstation images one is stuck
with gnome-initial-setup (I believe the anaconda based normal
intial-setup will do the right thing).

Regards,

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

Re: Weak password madness is back again

On Fri, 2016-10-07 at 16:17 +0200, Tomas Mraz wrote:
> On Pá, 2016-10-07 at 15:56 +0200, Hans de Goede wrote:
> > Hi,
> > 
> > So 2 devel cycles ago we had this whole discussion
> > about how forcing people to choose strong passwords in anaconda
> > was making live hard for testers / test-installs and this
> > decision was reverted.
> > 
> > So now here I'm doing a F25 Fedora ARM test install, end up
> > in the gnome-ified first-time-setup wizzard and cannot continue
> > until I make my test-user password strong enough. UGH.
> > 
> > So can we get this fixed please, or do we need to escalate
> > this all the way up to FESco again ?
> 
> 
> Is that a regression? Previously the discussion was about Anaconda not
> about gnome initial setup or whatever is the password dialogue you are
> talking about. Not that I am supporter of making it impossible to
> override password strength check in any kind of initial setup tools.

It is a regression, yeah, at some point g-i-s did allow weak passwords,
with a warning. I don't recall exactly when it changed again.
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

including EOL and vulnerable software in Fedora

Dear All,
I was made aware that EOL software with known security bugs that will
not be fixed upstream (due to EOL status) was reviewed and accepted into
Fedora recently. This came on the back of the FPC ticket [1] asking to
make some changes in the Python Packaging Guidelines. I did go back and
re-read our current guidelines and found that we don't have any policy
on that. As a result, I opened a FESCo ticket [2] with the aim of
establishing a clear policy on how to treat EOL software with known
security vulnerabilities.

My proposal is:
1. Prevent EOL software with known security vulnerabilities from
entering Fedora in the first place, i.e. make it a review bullet point
(if the package is EOL it MUST NOT have any known security
vulnerabilties). If existing packages are found to be EOL and have known
security vulnerabilities, the vulnerability must either be patched by
the maintainer (or otherwise handled, e.g. by switching to an actively
maintained fork) or the package must be removed from Fedora.
2. A ticket may be opened to FESCo applying for an exception to the
above. FESCo should most likely seek the advice of the Fedora
Security Team in such cases.

Please read comments in both referenced tickets to avoid repeating
arguments which were given already.

References:
[1] https://fedorahosted.org/fpc/ticket/650
[2] https://fedorahosted.org/fesco/ticket/1634

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Weak password madness is back again

2016-10-07 Thread Michael Catanzaro

On Fri, 2016-10-07 at 18:07 +0200, Hans de Goede wrote:
> Suggested fix if you "shell out to passwd" in g-c-c, then why not
> also do this in g-i-s presumable you can share the code then and
> have less security sensitive code to worry about ? When you do
> make sure you run passwd as root (from g-i-s), not as the newly
> created user. I can set whatever passwd I want using
> "passwd " as root just fine.

We should probably just switch to using accountsservice, which runs as
root, to change the password; it's kind of silly to use passwd directly
"for auditability" if it's possible to change passwords using
accountsservice instead. accountsservice should be changed to use
passwd if desired. (Currently accountsservice uses usermod, which is I
guess why we don't use it in g-c-c.) Does that sound OK, Ondrej?

Then that would solve the problem of getting errors from PAM, and we
can decide whether to enforce password strength in GNOME based on
whether the current user is an admin or not (or if he is authenticated
as an admin for editing other accounts... that would be kind of
confusing, though, if a non-admin user with access to an admin password
gets hit by the password strength policy just because he didn't unlock
the panel with the admin password before changing his password; not
sure what the UI should be for this).

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

Re: Weak password madness is back again


Hi,

On 07-10-16 18:58, Michael Catanzaro wrote:

On Fri, 2016-10-07 at 18:07 +0200, Hans de Goede wrote:

Suggested fix if you "shell out to passwd" in g-c-c, then why not
also do this in g-i-s presumable you can share the code then and
have less security sensitive code to worry about ? When you do
make sure you run passwd as root (from g-i-s), not as the newly
created user. I can set whatever passwd I want using
"passwd " as root just fine.


We should probably just switch to using accountsservice, which runs as
root, to change the password; it's kind of silly to use passwd directly
"for auditability" if it's possible to change passwords using
accountsservice instead. accountsservice should be changed to use
passwd if desired. (Currently accountsservice uses usermod, which is I
guess why we don't use it in g-c-c.) Does that sound OK, Ondrej?

Then that would solve the problem of getting errors from PAM, and we
can decide whether to enforce password strength in GNOME based on
whether the current user is an admin or not (or if he is authenticated
as an admin for editing other accounts... that would be kind of
confusing, though, if a non-admin user with access to an admin password
gets hit by the password strength policy just because he didn't unlock
the panel with the admin password before changing his password; not
sure what the UI should be for this).


Sounds good to me, I'm pretty much happy with any solution which you
think is safe and maintainable; and I understand if we won't see this
fixed till F26, but please do fix it for F26.

Thank you & Regards,

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

Re: Weak password madness is back again


Hi,

On 07-10-16 17:42, Michael Catanzaro wrote:

On Fri, 2016-10-07 at 15:56 +0200, Hans de Goede wrote:

So can we get this fixed please, or do we need to escalate
this all the way up to FESco again ?


Hi,

The status quo is that we are not in compliance with FESCo's policy
[1], which clearly applies to all tools that change passwords and not
just anaconda, but we can't change anything in GNOME until libpwquality
stops blocking weak passwords via its PAM module, since we ultimately
shell out to passwd to implement that (for auditability). (Actually, I
think gnome-initial-setup does not use passwd, but gnome-control-center
definitely does, and we are not going to implement different password
checking behavior between the two of them.)

I informed FESCo of this at the time of their decision, and reminded
them in the original ticket a month or two ago. At any rate, it's been
this way for several releases now, so I don't want to change anything
in F25 this late in the game, but it would be nice to fix in the F26
timeframe. I don't want to work on the PAM module, but if somebody else
fixes it, then send me a ping and I'll try to update gnome-initial-
setup and gnome-control-center to comply with the policy.

But there is one more issue. FESCo's policy actually requires that only
admin users (wheel users, including the initial user account) would be
able to set weak passwords, and that unprivileged users should be
blocked from doing so. Again, this is not currently possible to
implement in GNOME, as it requires additional plumbing in at least the
PAM module, and probably also in libpwquality proper. Again, I don't
plan to work on this, but again, if someone else fixes it then I'm
happy to make whatever changes are needed in g-i-s/g-c-c.


First of all thank you for the long explanation, and good to know that
this is on your radar.

As a developer I understand what you're saying. But TBH as an end
user I don't give a hoot. We first had this whole discussion about
anaconda breaking the freedom to chose a password around F-22
and now we've F25 coming up 18 months later and this is still not
fixed (in some places). That is simply unacceptable IMHO.

Suggested fix if you "shell out to passwd" in g-c-c, then why not
also do this in g-i-s presumable you can share the code then and
have less security sensitive code to worry about ? When you do
make sure you run passwd as root (from g-i-s), not as the newly
created user. I can set whatever passwd I want using
"passwd " as root just fine.

This will at least fix g-i-s, which is the biggest hurdle for users.

Changing a passwd later, a wheel group user can always drop to
the terminal and do "sudo passwd " as a workaround,
but at g-i-s time no such workarounds are possible. Or simply
also run passwd as root for wheel group users (they have sudo
rights after all).

Regards,

Hans

> [1] https://fedoraproject.org/wiki/Passphrase_policy

Note that this page too is over a year old, really it is time
to fix this.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: including EOL and vulnerable software in Fedora

2016-10-07 Thread Zbigniew Jędrzejewski-Szmek

On Fri, Oct 07, 2016 at 06:43:10PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> Dear All,
> I was made aware that EOL software with known security bugs that will
> not be fixed upstream (due to EOL status) was reviewed and accepted into
> Fedora recently. This came on the back of the FPC ticket [1] asking to
> make some changes in the Python Packaging Guidelines. I did go back and
> re-read our current guidelines and found that we don't have any policy
> on that. As a result, I opened a FESCo ticket [2] with the aim of
> establishing a clear policy on how to treat EOL software with known
> security vulnerabilities.

A parallel could be drawn between previous python versions and
previous C standards, like c89, c90, c99, etc. One could say that they
are obsolete, but it is still very convenient to be able to add
CFLAGS=-ansi. The difference is that gcc has this built in, while
python does not have compatibility with previous "standards", so the
only way to test with previous versions is to run those previous
versions.  It's damn useful for testing, and it's much more convenient
to do it through dnf install than through
virtualization/containers/cloud/hand-compilation/copr/other-nonstandard-things.

So from my side, a vote for
1. labelling old pythons very clearly as such,
2. allowing people to install them using dnf.

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

Summary/Minutes from today's FESCo Meeting (2016-10-07)

2016-10-07 Thread Kalev Lember

===
#fedora-meeting: FESCO (2016-10-07)
===


Meeting started by kalev at 16:00:29 UTC. The full logs are available at
https://meetbot.fedoraproject.org/fedora-meeting/2016-10-07/fesco.2016-10-07-16.00.log.html
.



Meeting summary
---
* init process  (kalev, 16:00:32)

* #1568 F25 Self Contained Changes  (kalev, 16:02:35)
  * LINK: https://fedorahosted.org/fesco/ticket/1568   (kalev, 16:02:37)
  * AGREED: Allow late Jekyll change to proceed (+1:6, 0:0, -1:0)
(kalev, 16:06:15)
  * AGREED: Allow late Jekyll change to proceed (+1:7, 0:0, -1:0)
(kalev, 16:06:39)

* Next week's chair  (kalev, 16:08:20)
  * paragan to chair next week  (kalev, 16:09:05)

* Open Floor  (kalev, 16:09:11)
  * LINK: https://fedorahosted.org/fesco/ticket/1634   (Rathann,
16:09:27)
  * LINK:

https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/
(paragan, 16:15:58)
  * ACTION: Rathann to start a devel list discussion about old python
compatibility versions in Fedora  (kalev, 16:23:58)

Meeting ended at 16:25:18 UTC.




Action Items

* Rathann to start a devel list discussion about old python
  compatibility versions in Fedora




Action Items, by person
---
* Rathann
  * Rathann to start a devel list discussion about old python
compatibility versions in Fedora
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* kalev (40)
* Rathann (36)
* dgilmore (20)
* zodbot (14)
* paragan (10)
* nirik (7)
* jsmith (5)
* maxamillion (5)
* sgallagh (3)
* cstratak (2)
* jwb (1)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

grub, grubby, btrfs, was: PSA: Do not run 'dnf update' inside GNOME, KDE ...

This probably should have its own thread but I'm just changing the subject.

On Thu, Oct 6, 2016 at 10:18 PM, Eric Griffith  wrote:
> I'm just thinking out loud here, but, given that rpm-ostree does not use
> grubby, and we do have the Bootloader Spec, and no other distro uses grubby,
> would it be prudent to take a really hard look at whether grubby is still a
> path we want to walk?

It's a question for pjones or his clone :-D

My recollection is grubby was going to get a rethink, but I don't know
the scope. There are test cases built-into grubby that are considered
valuable, I'm not sure about the rest. Gene found the code difficult.
I think the main issue is, whether grubby or something else, it needs
to be easier to follow the trail of breadcrumbs, self describing. If
it's too easy, of course, it just means telling different people "no"
about their use case. If you're going to support all use cases that's
hard to invent and maintain. See GRUB.

> If it is, then more work obviously needs to be put into it to get it where
> we want/need it. Personally, I would love to see btrfs subvolume support, so
> that we could have snapshotting like on Suse, though it appears rpm-ostree
> would negate the need for it, correct?

Single Btrfs volume that includes /boot runs into the encryption
problem. An unencrypted /boot is still needed until someone does the
Anaconda and GRUB work to bring GRUB's existing LUKS support to
Fedora. It would probably be disposable work because of the VFS per
file and Brfs per subvolume encryption work happening, but I still
think worth while.

rpm-ostree doesn't need Btrfs, but it leverages Btrfs for some things
and more optimizations are possible. rpm-ostree is well positioned to
support dm thin snapshots,  overlayfs (which is what Cloud/Atomic WG
folks are looking into for F26), or Btrfs and take advantage of each.

The opensuse implementation works really well. But it's a bit
complicated to explain and understand it all. Conventional backup and
restore doesn't apply. Right now only the OS installer understands how
to create the unique layout they're using. So really, you just backup
home and maybe some system settings, and bet on doing a fresh
installation if your drive dies or the system face plants beyond the
ability to recover with snapshots. Also, home is still on XFS, so no
snapshots there.

> If it's not a path we want to walk anymore, then let's announce an
> "Intention To Deprecate" to give all interested parties (RHEL) plenty of
> warning, and start figuring out what all will break by the removal of
> grubby.

It's a lot simpler to just let it wither away slowly into the night,
and not worry about Btrfs on /boot. Or someone figures it out and
patches grubby to support it. Deprecation and starting over is a lot
of work with essentially zero glory.

> Adam, the only other distro that has serious alternate architecture support,
> AFAIK, is Debian. How do they handle grub2 + non-x86? Likewise, the
> alternate architectures that we support, how do we handle their bootloaders?
> Are they grub-based? Ext/Syslinux based? Grub-legacy?

Nothing in Fedora uses GRUB legacy.

ARM is using Das U-Boot. I'm not sure if grubby is involved here or not.

Fedora uses isolinux, extlinux, grub2, yaboot (power7 and older), and
zipl (s390). If the last two are gone or going away then it's syslinux
(and variants), grub2, and uboot.

> I agree with Kevin that grub2 is nonintuitive. But the only other
> serious option we have is bootctl, and I am not sure if that's even a
> possibility for a distro like Fedora. I know Arch has it as an install time
> option, but I don't know it's limitations.

systemd-boot (gummiboot) is UEFI only. It depends on kernel and
initramfs being on the EFI system partition, which if we're reusing an
existing one will be too small. Starting in Fedora 25 /boot is 1GiB,
mainly because RHEL folks are running out of space due to kdump being
used by default and putting its little gems on /boot - to give an idea
how much space is needed for an ESP to start holding kernels and
initramfs's.

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

Weak password madness is back again


Hi,

So 2 devel cycles ago we had this whole discussion
about how forcing people to choose strong passwords in anaconda
was making live hard for testers / test-installs and this
decision was reverted.

So now here I'm doing a F25 Fedora ARM test install, end up
in the gnome-ified first-time-setup wizzard and cannot continue
until I make my test-user password strong enough. UGH.

So can we get this fixed please, or do we need to escalate
this all the way up to FESco again ?

Regards,

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

Re: Weak password madness is back again

On Fri, Oct 7, 2016 at 9:42 AM, Michael Catanzaro  wrote:

> But there is one more issue. FESCo's policy actually requires that only
> admin users (wheel users, including the initial user account) would be
> able to set weak passwords, and that unprivileged users should be
> blocked from doing so.

The less privileged account must have a stronger passphrase. It's
adorable nonsense.

FESCo should reconsider that distinction.

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

Re: Docker/Libvirt networking issue / bug?

2016-10-07 Thread Neil Horman

On Fri, Oct 07, 2016 at 12:51:59AM +0300, Catalin wrote:
> maybe I'm come with not right answer ,
> I think that depend by network configuration over internet and routing process
> over applications. so will not be any conflict. I'm right?
> > Both docker and libvirt use iptables to direct traffic in various ways.  
> > They may well be in conflict
> 
I think you're comment doesn't justify your conclusion.  You are correct in your
indication that iptables rules may be different based on network and routing
configuration, but just because they may be different based on configuration in
no way precludes the two systems (docker and libvirt) from being in conflict.

Neil

> 
> 2016-10-06 22:18 GMT+03:00 Neil Horman :
> > On Thu, Oct 06, 2016 at 02:02:09PM -0500, Dan Williams wrote:
> >> On Thu, 2016-10-06 at 12:39 -0600, Nathanael D. Noblet wrote:
> >> > On Thu, 2016-10-06 at 14:28 -0400, Neil Horman wrote:
> >> > >
> >> > > I rarely mess with docker, but I expect that the docker0 bridge has
> >> > > an ip
> >> > > address on it which may conflict with the one on libvirt
> >> > > bridge.  That is to
> >> > > say, if they are on the same subnet, and the route for the docker0
> >> > > bridge takes
> >> > > precidence, you will loose dhcp.  Check the docker bridge ip and
> >> > > remove it if
> >> > > you see one, I expect that will restore your functionality
> >> > >
> >> >
> >> > Unfortunately that isn't the issue as the docker bridge is 172... and
> >> > bridge0 is 192.168... so they don't conflict. Also docker0 doesn't
> >> > seem
> >> > to have any devices (meaning it brctl show has no interfaces attached
> >> > to it). Finally shutting down docker and removing docker0 doesn't
> >> > restore connectivity, only a reboot does. Not even restarting NM
> >> > fixes
> >> > the issue.
> >>
> >> Try running 'iptables-save' before you start docker, and then running
> >> 'iptables-save' after.  Diff the results.  Did docker remove anything?
> >>
> > +1, thats the next thing to look at.  Both docker and libvirt use iptables 
> > to
> > direct traffic in various ways.  They may well be in conflict
> > Neil
> >
> >> Dan
> >> ___
> >> devel mailing list -- devel@lists.fedoraproject.org
> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [security fix] ghostscript rebased to 9-20 for all releases

2016-10-07 Thread Solomon Peachy

On Fri, Oct 07, 2016 at 03:14:57PM -, David Kaspar wrote:
> Right now, I think only packages that depend on ghostscript-devel subpackage 
> *might* be affected by this change. List of those packages:
> > ariamaestosa
> > ImageMagick
> > wfdb

Add gutenprint to that list.  I don't expect the existing package will 
malfunction in any way with the ghostscript bump, but it's not 
rebuildable without ijs-config.  There's an already-upstreamed patch 
that switches over to using pkg-config:

https://sourceforge.net/p/gimp-print/source/ci/233a909a77dd4c18d359bf32cd8ef99ed1b7b459/

(For the life of me I can't figure out how to get sourceforge to display 
 a raw diff.  I can supply one out of my local repo if need be..)

 - Solomon
-- 
Solomon Peachy pizza at shaftnet dot org
Delray Beach, FL  ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.

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

[security fix] ghostscript rebased to 9-20 for all releases

2016-10-07 Thread David Kaspar

Hello folks,

ghostscript package has been rebased to version 9.20 across all current Fedora 
releases. I am very well aware that we shouldn't do rebases for current 
releases, to avoid stability problems. However, I have decided for this step in 
order to fix 4 CVEs that arrived yesterday for ghostscript (3 of them with 
security impact=high).

Backporting the security fixes from upstream across 4 versions of ghostscript 
could increase the possibility the fixes wouldn't be backported correctly, and 
it would be most likely much more time consuming. (I'm in time constraints ATM).

I have discussed the rebase with upstream - THERE SHOULD BE NO API/ABI CHANGES 
between versions 9.16 ->> 9.20. Another notes for Fedora maintainers:
* ghostscript sub-package structure remained same
* 'ijs-config' custom tool from upstream has been removed (by upstream), 
'pkg-config' is used by default now instead [1]
* more info in release notes [2][3][4]

Right now, I think only packages that depend on ghostscript-devel subpackage 
*might* be affected by this change. List of those packages:
> ariamaestosa
> ImageMagick
> wfdb

I think we can all agree that it's better to have some (not-critical) 
functionality broken for few days than vulnerable Fedora. :) I will be 
contacting maintainers of those packages and ask them to rebuild their package, 
to make sure everything will be working as it should.

Thank you for your understanding!

Best regards,

Dee'Kej
--
[1] http://git.ghostscript.com/?p=ghostpdl.git;h=0c176a91d53c85cda
[2] https://bodhi.fedoraproject.org/updates/ghostscript-9.20-2.fc25
[3] https://bodhi.fedoraproject.org/updates/ghostscript-9.20-2.fc24
[4] https://bodhi.fedoraproject.org/updates/ghostscript-9.20-2.fc23
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Weak password madness is back again

2016-10-07 Thread Michael Catanzaro

On Fri, 2016-10-07 at 15:56 +0200, Hans de Goede wrote:
> So can we get this fixed please, or do we need to escalate
> this all the way up to FESco again ?

Hi,

The status quo is that we are not in compliance with FESCo's policy
[1], which clearly applies to all tools that change passwords and not
just anaconda, but we can't change anything in GNOME until libpwquality
stops blocking weak passwords via its PAM module, since we ultimately
shell out to passwd to implement that (for auditability). (Actually, I
think gnome-initial-setup does not use passwd, but gnome-control-center 
definitely does, and we are not going to implement different password
checking behavior between the two of them.)

I informed FESCo of this at the time of their decision, and reminded
them in the original ticket a month or two ago. At any rate, it's been
this way for several releases now, so I don't want to change anything
in F25 this late in the game, but it would be nice to fix in the F26
timeframe. I don't want to work on the PAM module, but if somebody else
fixes it, then send me a ping and I'll try to update gnome-initial-
setup and gnome-control-center to comply with the policy.

But there is one more issue. FESCo's policy actually requires that only
admin users (wheel users, including the initial user account) would be
able to set weak passwords, and that unprivileged users should be
blocked from doing so. Again, this is not currently possible to
implement in GNOME, as it requires additional plumbing in at least the
PAM module, and probably also in libpwquality proper. Again, I don't
plan to work on this, but again, if someone else fixes it then I'm
happy to make whatever changes are needed in g-i-s/g-c-c.

Michael

[1] https://fedoraproject.org/wiki/Passphrase_policy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Weak password madness is back again

2016-10-07 Thread Tomas Mraz

On Pá, 2016-10-07 at 15:56 +0200, Hans de Goede wrote:
> Hi,
> 
> So 2 devel cycles ago we had this whole discussion
> about how forcing people to choose strong passwords in anaconda
> was making live hard for testers / test-installs and this
> decision was reverted.
> 
> So now here I'm doing a F25 Fedora ARM test install, end up
> in the gnome-ified first-time-setup wizzard and cannot continue
> until I make my test-user password strong enough. UGH.
> 
> So can we get this fixed please, or do we need to escalate
> this all the way up to FESco again ?

Is that a regression? Previously the discussion was about Anaconda not
about gnome initial setup or whatever is the password dialogue you are
talking about. Not that I am supporter of making it impossible to
override password strength check in any kind of initial setup tools.

The only place where the password strength check should not be
overridable is when a regular user tries to change his own password.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)

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

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

2016-10-07 Thread Kevin Fenzi

On Fri, 7 Oct 2016 00:18:21 -0400
Eric Griffith  wrote:

> I'm just thinking out loud here, but, given that rpm-ostree does not
> use grubby, and we do have the Bootloader Spec, and no other distro
> uses grubby, would it be prudent to take a really hard look at
> whether grubby is still a path we want to walk? 

Well, the bootloader spec has a lot of things missing that we
expect/want to support. Like multibooting, BIOS boot chainloading
booting, etc. 

Matthew Garrett started working on proposed changes to the spec: 
https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/
but the owners of the spec didn't seem to interested in those cases and
Matthew went on to other work. 

So, I think we would need to get buyin to get our changes into the spec
and get everyone to agree on it before we would want to move to it. 

kevin

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

Re: [security fix] ghostscript rebased to 9-20 for all releases

2016-10-07 Thread David Kaspar [Dee'Kej]

Thank you, Solomon for that info,

actually gutenprint maintainer is my colleague, but he is sick today. I'm
adding him into CC, so he's aware of it when he returns. ;)

2 Zdenek: Please, look at the whole thread here -
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WZYPIRENDRAT3XZLTOVUVNOCJDZQIW3M/
- we have discussed a little on Thursday, so you should know what's going
on. :)

Best regards,

David Kaspar [Dee'Kej]
*Associate Software Engineer*
*Brno, Czech Republic*

RED HAT | TRIED. TESTED. TRUSTED.
Every airline in the Fortune 500 relies on Red Hat.
Find out why at Trusted | Red Hat .

On Fri, Oct 7, 2016 at 5:28 PM, Solomon Peachy  wrote:

> On Fri, Oct 07, 2016 at 03:14:57PM -, David Kaspar wrote:
> > Right now, I think only packages that depend on ghostscript-devel
> subpackage *might* be affected by this change. List of those packages:
> > > ariamaestosa
> > > ImageMagick
> > > wfdb
>
> Add gutenprint to that list.  I don't expect the existing package will
> malfunction in any way with the ghostscript bump, but it's not
> rebuildable without ijs-config.  There's an already-upstreamed patch
> that switches over to using pkg-config:
>
> https://sourceforge.net/p/gimp-print/source/ci/
> 233a909a77dd4c18d359bf32cd8ef99ed1b7b459/
>
> (For the life of me I can't figure out how to get sourceforge to display
>  a raw diff.  I can supply one out of my local repo if need be..)
>
>  - Solomon
> --
> Solomon Peachy pizza at shaftnet dot org
> Delray Beach, FL  ^^ (email/xmpp) ^^
> Quidquid latine dictum sit, altum viditur.
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Screenshots with Wayland and Dual Displays

2016-10-07 Thread Jeffrey Ollie

On Thu, Oct 6, 2016 at 10:41 PM, Chris Murphy 
wrote:

> On Thu, Oct 6, 2016 at 3:59 PM, Jeffrey Ollie  wrote:
> > I just noticed that I can't take a screenshot of anything on the
> secondary
> > display when using two displays - you just get a transparent PNG. In
> fact,
> > if you try and grab an area that spans the displays it'll capture the
> screen
> > from the primary display properly while the area from the secondary
> display
> > is transparent. I didn't find anything in Bugzilla that looked similar
> but I
> > wasn't sure if it should be filed under Wayland or something else.
>
> File it against the thing that's taking the screenshot.
>
> What command are you using? I'm using Wayland and taking screenshots
> and don't have that problem with gnome-screenshot; but I have
> something similar with Shutter.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1363845
>

I was able to figure out the search-fu that I needed and found this
existing bug report:

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

-- 
Jeff Ollie
The majestik møøse is one of the mäni interesting furry animals in Sweden.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Weak password madness is back again


Hi,

On 07-10-16 16:17, Tomas Mraz wrote:

On Pá, 2016-10-07 at 15:56 +0200, Hans de Goede wrote:

Hi,

So 2 devel cycles ago we had this whole discussion
about how forcing people to choose strong passwords in anaconda
was making live hard for testers / test-installs and this
decision was reverted.

So now here I'm doing a F25 Fedora ARM test install, end up
in the gnome-ified first-time-setup wizzard and cannot continue
until I make my test-user password strong enough. UGH.

So can we get this fixed please, or do we need to escalate
this all the way up to FESco again ?


Is that a regression?


I don't know this is the first time I encountered the
gnome initial-setup wizard instead of using anaconda (due to how
arm images work).


Previously the discussion was about Anaconda


Right, but since we've had this whole heated discussion about how
a strong password should not be mandatory for initial account
creation, it seems silly to me that only Anaconda actually abides
by that decision and other tools with the same purpose do not.


not about gnome initial setup or whatever is the password dialogue you are
talking about.


I got something which looks like the gnome welcome wizard, but then
before logging in, since there did not exist any user on the system yet.

This version of the gnome welcome wizard allows one to create an user
and select a timezone in essence taking the place of initial-setup-gui
on non workstation spins.

If someone knows the package name of the gnome replacement for
initial-setup-gui used on the workstation spin, then please let me
know then I will file a bug for this.


 Not that I am supporter of making it impossible to
override password strength check in any kind of initial setup tools.


Right, exactly my point.


The only place where the password strength check should not be
overridable is when a regular user tries to change his own password.


Ack, that is not what I'm talking about, this is initial account
creation for the first user on the system.

Regards,

Hans

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

Re: Weak password madness is back again

On Fri, Oct 7, 2016 at 8:17 AM, Tomas Mraz  wrote:
> On Pá, 2016-10-07 at 15:56 +0200, Hans de Goede wrote:
>> Hi,
>>
>> So 2 devel cycles ago we had this whole discussion
>> about how forcing people to choose strong passwords in anaconda
>> was making live hard for testers / test-installs and this
>> decision was reverted.
>>
>> So now here I'm doing a F25 Fedora ARM test install, end up
>> in the gnome-ified first-time-setup wizzard and cannot continue
>> until I make my test-user password strong enough. UGH.
>>
>> So can we get this fixed please, or do we need to escalate
>> this all the way up to FESco again ?
>
> Is that a regression? Previously the discussion was about Anaconda not
> about gnome initial setup or whatever is the password dialogue you are
> talking about. Not that I am supporter of making it impossible to
> override password strength check in any kind of initial setup tools.
>
> The only place where the password strength check should not be
> overridable is when a regular user tries to change his own password.

To this day in the latest Windows and macOS, the regular user can use
"hi" as a password, and the world is still not ending. More user
freedom for passwords on proprietary platforms. It's ironic.

The shortest password I can get GNOME's Settings > Users > Change
Password to accept is UiNls8%M which is hilarious.

February is also eight characters, but I'm punished for using a common
word. Even february5 is disallowed. The shortest easiest to remember
one I could come up with was june5may which is eight characters.

It's from the same era of pompous fake security as compulsory password
changes after 90 days. Oh well, we have bigger problems anyway.

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

Re: Weak password madness is back again

On Fri, 2016-10-07 at 15:56 +0200, Hans de Goede wrote:
> Hi,
> 
> So 2 devel cycles ago we had this whole discussion
> about how forcing people to choose strong passwords in anaconda
> was making live hard for testers / test-installs and this
> decision was reverted.
> 
> So now here I'm doing a F25 Fedora ARM test install, end up
> in the gnome-ified first-time-setup wizzard and cannot continue
> until I make my test-user password strong enough. UGH.
> 
> So can we get this fixed please, or do we need to escalate
> this all the way up to FESco again ?

It's a game. Every time we get it changed in one place, it gets changed
the other way in another place...=)

For now, you can create a user account during the install process
(rather than in gnome-initial-setup) if you want a weak password.
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

On Fri, 2016-10-07 at 17:35 +, Fedora compose checker wrote:
> No missing expected images.
> 
> Failed openQA tests: 3/102 (x86_64), 1/17 (i386)
> 
> Old failures (same test failed in 25-20161006.n.0):
> 
> ID: 39572 Test: x86_64 Workstation-live-iso 
> desktop_notifications_postinstall
> URL: https://openqa.fedoraproject.org/tests/39572

This is kinda a test issue. GNOME's update notification mechanism is
rather awkward to design an automated test for, and the version of the
test currently in production doesn't quite work to reliably ensure the
update notification will be triggered. I'm working on a fix for this on
staging ATM, but it's proving a bit tricky.

> ID: 39577 Test: x86_64 Atomic-dvd_ostree-iso install_default
> URL: https://openqa.fedoraproject.org/tests/39577

This currently actually looks to be failing due to a test issue
too...because ostree installs are quite fast and we made root password
typing quite slow, it seems like the test currently is getting back
from the ROOT PASSWORD spoke with the install process already
completed, and in that case the USER CREATION spoke link looks somewhat
different (it's greyed a bit rather than being black) and the needles
don't match. I'll fix that. I think the test would still fail later due
to
https://bugzilla.redhat.com/show_bug.cgi?id=1374082 , though.

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

Still good ol' https://bugzilla.redhat.com/show_bug.cgi?id=1378156 .

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

Still https://bugzilla.redhat.com/show_bug.cgi?id=1333591 .
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

2016-10-07 Thread Roberto Ragusa

On 10/04/2016 08:10 PM, stan wrote:

> I think I can confirm this advice.  I always run dnf manually from the
> command line, in a VT logged in as root.  And I can run X while doing
> this and I've never had a dnf update issue.

The problem with this is that the VT doesn't have a long history,
so if you can't really see what dnf has done.
(e.g. I visually search any rpmsave rpmorig rpmnew warning)

-- 
   Roberto Ragusamail at robertoragusa.it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

On Tue, 2016-10-04 at 11:12 +0200, Martin Kolman wrote:
> 
> > There is currently no real way to use FMW on non-Fedora Linux
> > distributions that don't a) support Flatpak and b) have an
> > appropriate
> > Flatpak runtime for running FMW on (beyond compiling it yourself, I
> > guess).
> 
> That sounds weird - why can't it be packaged for other distros by using
> the normal distro packaging mechanisms (RPM/deb,etc. packages) ?

There's no reason it *couldn't* be done, it just *hasn't* been done.
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

On Fri, 2016-10-07 at 21:11 +0200, Roberto Ragusa wrote:
> On 10/04/2016 08:10 PM, stan wrote:
> 
> > I think I can confirm this advice.  I always run dnf manually from the
> > command line, in a VT logged in as root.  And I can run X while doing
> > this and I've never had a dnf update issue.
> 
> 
> The problem with this is that the VT doesn't have a long history,
> so if you can't really see what dnf has done.
> (e.g. I visually search any rpmsave rpmorig rpmnew warning)

Several ways to handle this have already been discussed upthread, and
another thing you can do is look at the 'dnf history info' output for
the transaction; that contains all the same warnings that are shown
real-time.
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: including EOL and vulnerable software in Fedora

On Friday, 07 October 2016 at 19:35, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Oct 07, 2016 at 06:43:10PM +0200, Dominik 'Rathann' Mierzejewski 
> wrote:
> > Dear All,
> > I was made aware that EOL software with known security bugs that will
> > not be fixed upstream (due to EOL status) was reviewed and accepted into
> > Fedora recently. This came on the back of the FPC ticket [1] asking to
> > make some changes in the Python Packaging Guidelines. I did go back and
> > re-read our current guidelines and found that we don't have any policy
> > on that. As a result, I opened a FESCo ticket [2] with the aim of
> > establishing a clear policy on how to treat EOL software with known
> > security vulnerabilities.
> 
> A parallel could be drawn between previous python versions and
> previous C standards, like c89, c90, c99, etc. One could say that they
> are obsolete, but it is still very convenient to be able to add
> CFLAGS=-ansi.

gcc is a bit of a special case IMHO. It's rarely installed on servers,
especially Internet-facing ones. The only runtime component is libgcc,
which is fairly small and even if you're using an application binary
compiled with an ancient gcc because it won't compile with a newer one,
any vulnerabilities will more likely come from that application than from
gcc itself.

> The difference is that gcc has this built in, while
> python does not have compatibility with previous "standards", so the
> only way to test with previous versions is to run those previous
> versions.  It's damn useful for testing, and it's much more convenient
> to do it through dnf install than through
> virtualization/containers/cloud/hand-compilation/copr/other-nonstandard-things.
> 
> So from my side, a vote for
> 1. labelling old pythons very clearly as such,

How do you propose we do that? I can imagine patching the interpreter
to print some warning about this every time it's run, but I wonder
if that's too much to ask.

> 2. allowing people to install them using dnf.

I am not denying the usefulness, though I wonder why you would want to
test against an unmaintained branch. I can see a case for python-2.6,
which will be maintained by Red Hat for a couple more years and I'd expect
the Fedora maintainer to either be the same person who maintains it in
RHEL or that they follow the RHEL package closely otherwise. I can't find
python3 in RHEL, so the above doesn't hold for python3.x.

Also, your point 2. is achievable through COPR.

However, my point is a more general one, that's why I'm asking our
security team for their thoughts as well. You'll notice that I
purposefully propose to leave a way for such packages to enter Fedora
anyway after their risks and benefits have been reviewed by FESCo and/or
FST. I hope you'll agree that such packages deserve greater scrutiny.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

On Tue, 2016-10-04 at 09:16 -0600, Chris Murphy wrote:
The one concern I have is with Sugar on a Stick spin. Their
installation instructions require livecd-iso-to-disk, because their
media boots straight into SoaS, not Anaconda. But I have some ideas
about how to deal with that going forward to, rather than depend
indefinitely on livecd-iso-to-disk.

I don't quite get what you mean by this. Are you saying that they
recommend using livecd-iso-to-disk with persistence as the official
method for 'installing' SoaS?
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

On Wed, 2016-10-05 at 21:51 +0200, Kevin Kofler wrote:
> I personally think that wiping all existing data on the USB stick is 
> extremely user-unfriendly. A non-destructive method that just works would 
> make everyone happy (both the majority that wants something that just works, 
> no matter how, and those who want the non-destructive method). It is sad 
> that liveusb-creator chickened out and implemented the dd option instead of 
> fixing the issues with the non-destructive method, and that the rewrite is 
> even destructive only. The wasted space due to the lack of a persistent 
> overlay is also sad.

The problem is that it's very difficult to do *all of the following*:

1. Write the stick non-destructively
2. Ensure it boots on as many systems as possible via BIOS
3. Ensure it boots on as many systems as possible via UEFI
4. Ensure it boots on Macs (a special case of 3, basically)

there are all kinds of considerations in achieving 2, 3 and 4 with a
single stick, and trying to achieve 1 as well immediately makes 2, 3
and 4 massively harder. Not caring about 1 makes 2, 3 and 4 a lot
easier.
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Installation validation test change proposal: merge USB tests into 'default boot and install', add more environment columns

Hi folks! Sending this to devel@ as well as test@ as there's been some
relevant discussion there recently. We've been kicking around a couple
of issues lately:

1. Exactly what do we need to test and block on, in terms of writing
images to USB sticks?

2. 'Default boot and install' table was supposed to require bare metal
optical media testing at release time, but this is not clear, and
openQA fills in results despite not testing real media on bare metal.

So here's my proposal to address both topics. It involves changes to
the Boot_default_install test:

https://fedoraproject.org/wiki/User:Adamwill/Draft_Testcase_Boot_default_install
https://fedoraproject.org/w/index.php?title=User:Adamwill/Draft_Testcase_Boot_default_install=476645=476644

and the Installation matrix template page:

https://fedoraproject.org/wiki/User:Adamwill/Draft_Installation_test_matrix
https://fedoraproject.org/w/index.php?title=User:Adamwill/Draft_Installation_test_matrix=476646=476643

to summarize the changes - we improve the test case's wording to give
explicit instructions for all three media types we care about (virtual
disc attached to a VM, real optical disc in a real machine, real USB
stick in a real machine), we ditch the USB test matrices entirely, and
we give the 'Default boot and install' tables extra result columns so
they can now reflect results for VM, CD/DVD and USB testing (for BIOS
and UEFI in all three cases, for x86_64).

I didn't get too finicky about the wording for the virt case, as that's
basically there to get filled in by openQA anyway. For the CD/DVD case,
the test case instructs you to write the disc according to the
'official instructions', with a URL that is supposed to be always
provided by the docs project for that purpose. For the USB case, the
test case instructs you to write the stick according to
https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB , telling
you to use the 'most prominently-recommended method'; the intent being
that, as things stand, we would only block on Fedora Media Writer
issues. I didn't explicitly cover dd (e.g. with separate FMW and dd
columns) for two reasons:

1. It should pretty reliably be the case that if FMW works, dd works
2. Some people are going to test plain dd anyway, it's just such a
convenient 'expert' method that I can't imagine we won't have people
using it throughout the test period

I didn't cover livecd-iso-to-disk because it seems like, overall, the
feedback to cmurf's "F26 proposal: Make Fedora Media Writer the
officially supported USB install media creator" was fairly positive and
I think justifies not guaranteeing testing for it.

To be clear, this is a trade-off between 'in an ideal world we'd test
everything' and 'but we really don't have time'. Each additional method
adds 12 mandatory tests (6 images, both UEFI and BIOS variants of the
test). We can discount the virt tests, as openQA will do those, so in
the proposal, there are 24 mandatory tests for humans; if we added dd
as its own thing there'd be 36, if we added litd as well there'd be 48.

One note is that this doesn't do much to ensure that FMW is working at
release time in all expected environments (probably at least the two
previous stable Fedora releases, macOS, and Windows). On the other
hand, neither does the current matrix; we explicitly list FMW, but we
don't specify what environments it should be run in. We could consider
adding a USB table with a slightly different focus, the idea being to
test the *writing tool* rather than test that the *image* can be
written and works properly. We could make that a follow-up proposal. If
we had such a table, it could maybe cover testing livecd-iso-to-disk's
advanced features as optional tests, or something.

At present I'm not proposing any changes to the *release criteria* (we
can maybe consider that later). This is just a proposal for what we
will actually guarantee testing of via the validation process.
--
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Review swaps

2016-10-07 Thread Björn Esser


Hello,

I have another three reviews to swap [1].  The first one in the tree is 
pretty brain-dead, the other two are a bit more advanced C-compiled 
packages, but not too exhausting.


Any offers?

Cheers,
  Björn


[1] 
https://bugzilla.redhat.com/showdependencytree.cgi?id=1382810_resolved=1

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

Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

On Mon, 2016-10-03 at 20:03 +, John Florian wrote:
> On Mon, 2016-10-03 at 12:07 -0700, Adam Williamson wrote:
> If we do not 'support' livecd-iso-to-disk any more, we no longer
> support:
> 
> 1) persistent storage (via overlays)
> 2) non-destructive write
> 
> 
> I've known for quite some time that livecd-tools was/is to be
> replaced with livemedia-creator, but only now did I realize that lm-c 
> won't have persistent storage -- I simply have never had the time to
> explore it.  I'm extremely dependent on the persistent storage as my
> whole day job revolves around making hundreds of little mostly-
> stateless appliances for data collection purposes and has so since
> F13 or so.  These have been built with livecd-iso-to-disk and lots of
> glue via specialized kickstarts and other custom packages.  These
> appliances leverage a stateless OS very robustness, but do expect
> some persistent storage for their management.  So the above certainly
> caught my attention.

There's a slight misconception in the above.

livemedia-creator *creates the image files themselves*. We're not
talking about that in this thread. We're talking about the tools for
taking an image that's been created - whether by livecd-creator or
livemedia-creator or anything else - and writing them to a USB stick.

The 'persistence' feature requires support both in the image itself and
in the tool used to write it. I believe livemedia-creator-produced
images are set up to support persistence, just like livecd-creator-
produced images were.

The issue here is that we are discussing what tools for *writing the
image to a USB stick* should be 'supported' / 'recommended' / whatever,
and we'd kinda like to drop livecd-iso-to-disk from that group, but it
is currently the only one of the 'write image to stick' tools which
supports persistence.

No-one's proposing dropping livecd-iso-to-disk entirely at present, so
you will still be able to attempt to write sticks with persistent
storage, but we are discussing effectively a downgrade in how much
testing it gets and how much we care if it's broken.

It is worth noting that we've never formally tested the persistence
features in any case, so we would never have blocked a release for
'persistence doesn't work right' anyhow. But at present we do, by
policy, block the release if writing sticks with livecd-iso-to-disk
doesn't work.

> Are there plans to get persistent storage capabilities into lm-c?
> 
> Also, after much work I managed to get my live ISO spins generated
> out of a private Koji setup.  I see there a warning "spin-livecd is
> deprecated and will be replaced with spin-livemedia" -- I assume this
> related, true?  If so, do any improvements to lm-c (say to add
> persistence) automagically benefit the "spin-livemedia" method in
> Koji?

Well, yeah. 'spin-livecd' is the Koji method for creating images with
livecd-creator; it's now deprecated and never used in the official
Fedora Koji instance, Fedora live images are all now created with the
'spin-livemedia' method. 'spin-livemedia' is the Koji method for
creating images with livemedia-creator.

So since what 'spin-livemedia' *does* is create a live image using
livemedia-creator, of course any changes to livemedia-creator will be
reflected when you create an image with the Koji 'spin-livemedia'
method.
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

On Fri, Oct 7, 2016 at 1:26 PM, Adam Williamson
 wrote:
> On Tue, 2016-10-04 at 09:16 -0600, Chris Murphy wrote:
> The one concern I have is with Sugar on a Stick spin. Their
> installation instructions require livecd-iso-to-disk, because their
> media boots straight into SoaS, not Anaconda. But I have some ideas
> about how to deal with that going forward to, rather than depend
> indefinitely on livecd-iso-to-disk.
>
> I don't quite get what you mean by this. Are you saying that they
> recommend using livecd-iso-to-disk with persistence as the official
> method for 'installing' SoaS?

They recommend various methods but yes...

https://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Installation

In the Download section you get different instructions, to use Live
USB Creator with the persistence slider set. And same for Unetbootin.
In all cases, it's copy the files in the SoaS ISO to the stick, and
setup persistence. There's no use of Anaconda.



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

Re: Review swaps

2016-10-07 Thread Christian Dersch

Hi Björn,

Let's swap :D I've got some packages to review, just pick some ones open
in Astronomy SIG tracker :)

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

Greetings,
Christian


On 10/07/2016 09:18 PM, Björn Esser wrote:
> Hello,
>
> I have another three reviews to swap [1].  The first one in the tree
> is pretty brain-dead, the other two are a bit more advanced C-compiled
> packages, but not too exhausting.
>
> Any offers?
>
> Cheers,
>   Björn
>
>
> [1]
> https://bugzilla.redhat.com/showdependencytree.cgi?id=1382810_resolved=1
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

2016-10-07 Thread Lars Seipel

On Tue, Oct 04, 2016 at 09:16:12AM -0600, Chris Murphy wrote:
> Over on Windows and macOS, there is no such thing as a non-destructive
> install media creation. It warns but obliterates the entire stick.
> They also don't have persistence. So I think you're on very solid
> ground calling both features edge cases, and as such probably not
> reasonable to block a release on if it weren't to work.

For these systems and most of their user base, installing the OS from
scratch already is an edge case. Most people use the preinstalled copy
that came with their machine. It wasn't that long ago that you couldn't
install them from an USB stick at all but had to use some kind of
optical disc. Long into the 2000's you had to use a freakin' floppy
drive to inject storage device drivers into the Windows install process.

Fedora is not in a position to impose such ridiculous demands on its
users and I, for one, wouldn't want to even if we could.

That's not to say we should block the release for persistence-enabled
live media. I don't think we should. It's just that the Windows or MacOS
install process isn't a very useful comparison for our needs. Fedora
has a far more diverse set of use-cases than any of these systems and
thus requires much more flexibility in its installation infrastructure.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Test-Announce] Proposal to CANCEL: 2016-10-10 Fedora blocker review meeting

Hi folks! I'm proposing we cancel Monday's blocker review meeting.
There's just one proposed Final blocker to review:

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

there are five proposed Final freeze exceptions, but we're some way out
from Final freeze, no real need to review them yet. I figure it's not
worth running a meeting for just one bug. If folks want to get that
proposal reviewed now, go ahead and vote in the bug.

Thanks folks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

On Fri, 2016-10-07 at 13:32 -0700, Andrew Lutomirski wrote:
> 
> At the risk of muddying the waters a bit: now that OverlayFS is here, I
> think that even a dd-copied image should be able to support persistence.
> The image could notice that it's dd-copied (by checking GPT GUIDs or layout
> or whatever), see that there's extra space at the end, and allocate it.

In fact, our cloud images do something rather like this so that when
you write them to a hard disk, they expand the root partition to fill
the available space on the disk on the initial boot.

So yeah, it seems entirely plausible that we could design a persistence
mechanism that worked that way. But the current one doesn't :)
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

On Fri, Oct 7, 2016 at 2:32 PM, Chris Murphy  wrote:
> Modifying the image at all breaks the existing media verification
> option in the boot menu, and we know people get bad writes using bad
> or flaky media

This part, at least, should be relatively straightforward to get
around.  The allocation of a persistence partition literally just
create a new partition, so if the media verification could learn to
verify the partition (bitwise) instead of the whole device, it would
work fine.

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

Re: grub, grubby, btrfs, was: PSA: Do not run 'dnf update' inside GNOME, KDE ...

2016-10-07 Thread Josh Boyer

On Fri, Oct 7, 2016 at 5:14 PM, Chris Murphy  wrote:
> Changed this subject to match the other one I changed, so if I'm doing
> it wrong at least I'm consistent!
>
> On Fri, Oct 7, 2016 at 9:22 AM, Kevin Fenzi  wrote:
>> So, I think we would need to get buyin to get our changes into the spec
>> and get everyone to agree on it before we would want to move to it.
>
> The original spec is unworkable. And attempts to expand the upstream
> spec for real world use cases needed in Fedora haven't gone anywhere.
> It exchanges reduced complexity in the bootloader, by increasing it in
> the installer and increasing wasted space on the drive. I'd try to
> help make it salvageable but I think it's pointless. Make a Fedora
> specific version and if people like it they can adopt it.

Which, in effect, could just as well be writing a "specification" for grubby.

I don't see the point in writing something nobody will adopt twice.

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

Re: grub, grubby, btrfs, was: PSA: Do not run 'dnf update' inside GNOME, KDE ...

On Fri, Oct 7, 2016 at 4:55 PM, Josh Boyer  wrote:
> On Fri, Oct 7, 2016 at 5:14 PM, Chris Murphy  wrote:
>> Changed this subject to match the other one I changed, so if I'm doing
>> it wrong at least I'm consistent!
>>
>> On Fri, Oct 7, 2016 at 9:22 AM, Kevin Fenzi  wrote:
>>> So, I think we would need to get buyin to get our changes into the spec
>>> and get everyone to agree on it before we would want to move to it.
>>
>> The original spec is unworkable. And attempts to expand the upstream
>> spec for real world use cases needed in Fedora haven't gone anywhere.
>> It exchanges reduced complexity in the bootloader, by increasing it in
>> the installer and increasing wasted space on the drive. I'd try to
>> help make it salvageable but I think it's pointless. Make a Fedora
>> specific version and if people like it they can adopt it.
>
> Which, in effect, could just as well be writing a "specification" for grubby.

I disagree.

The bootloader spec, update-grub, and pretty much everything except
grubby are stateless in the sense that the list of installed kernels
and other things is generated freshly each time it updates.  (The
bootloader spec does this at every boot, and update-grub does it
whenever it's run.)  These solutions don't try to let users customize
the result after the fact.  Instead, any customization is written to a
file intended for the specific purpose of customizing the boot
process, and that file is never written by automatic tools.
Bootloader spec parsing, update-grub, etc are all idempotent, which is
a *really* nice property.

Grubby attempts to parse a configuration file and apply a change for a
single kernel addition or removal to it without losing other
customizations.  This is a much harder problem to solve well.  It's
also not idempotent.  Unsurprisingly (to me, anyway), it doesn't seem
to work all that well and it's a PITA to maintain.

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

intention to unretire package: psad

Dear All,
I intend to unretire the package psad (Port Scan Attack Detector)
which was retired due to not having a native systemd unit.

I have updated the package to the latest upstream version which
supports journalctl and added an unit file. Here's my review
request: https://bugzilla.redhat.com/show_bug.cgi?id=1382875

Review swaps welcome.

Regards,
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Test-Announce] 2016-10-10 @ 15:00 UTC - Fedora QA Meeting

# Fedora Quality Assurance Meeting
# Date: 2016-10-10
# Time: 15:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

It's meeting time again on Monday! We've polished off the Beta, so it's
time to clean up any loose ends, and see where we stand in preparation
for the Final release. We can also check in on Test Days and other
proposals.

If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.

== Proposed Agenda Topics ==

1. Previous meeting follow-up
2. Fedora 25 Beta post-mortem
3. Fedora 25 Final planning
4. Test Day status
5. 'Default boot and install' validation test proposal / USB testing
6. Open floor
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Call for help contacting contributor: spike

2016-10-07 Thread Pierre-Yves Chibon

On Fri, Oct 07, 2016 at 08:35:52AM +0200, Pierre-Yves Chibon wrote:
> On Thu, Oct 06, 2016 at 07:20:55PM +0200, spike wrote:
> > On 05.10.2016 12:44, Pierre-Yves Chibon wrote:
> > > It has been a month, more than I expected, so I asked FESCo to consider 
> > > the user
> > > spike MIA: https://fedorahosted.org/fesco/ticket/1632
> > 
> > Sorry, must have missed that mail. Just changed my Bugzilla EMail address 
> > back to what is was. 
> 
> It looks like the emails are still not matching.
> Your FAS email is the one used here `spikefedora - gmail`, while as far as I 
> can
> see [1], your bugzilla email is your @fedoraproject.org alias.
> Both addresses need to match.
> 
> Could you look into it?

FTR, spike has fixed the email address used in bugzilla, so this is now resolved
:)

Many thanks to spike!


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

Re: /sbin/nologin in /etc/shells

2016-10-07 Thread Björn Persson

Andrew Toskin wrote:
> If it were really important to make sure the user could no longer
> access the system at all, why not just delete the account? Deleting
> the user does not (necessarily) delete their data, so what's the use
> case for keeping the account at all in such a situation?

The files they owned, which may not only be in their home directory but
also in shared directories, will remain owned by the former user's
numeric user ID. That user ID is now unallocated, and may get reused
when a new account is created. The new user then gets access to all of
the former user's files.

Björn 

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

Re: Call for help contacting contributor: spike

2016-10-07 Thread Pierre-Yves Chibon

On Thu, Oct 06, 2016 at 07:20:55PM +0200, spike wrote:
> On 05.10.2016 12:44, Pierre-Yves Chibon wrote:
> > It has been a month, more than I expected, so I asked FESCo to consider the 
> > user
> > spike MIA: https://fedorahosted.org/fesco/ticket/1632
> 
> Sorry, must have missed that mail. Just changed my Bugzilla EMail address 
> back to what is was. 

It looks like the emails are still not matching.
Your FAS email is the one used here `spikefedora - gmail`, while as far as I can
see [1], your bugzilla email is your @fedoraproject.org alias.
Both addresses need to match.

Could you look into it?


Thanks,
Pierre


[1] using this ticket, assigned to you 
https://bugzilla.redhat.com/show_bug.cgi?id=1340441
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Many directories without owning packages

On Thursday, 06 October 2016 at 18:58, Dridi Boukelmoune wrote:
> Hello,
> 
> I was surprised to see /usr/share/texlive on my system although I
> remembered very well removing it months ago. It turned out to be
> caused by two rpmsave files, although some *empty* directories weren't
> removed:
[...]
That's normal rpm behaviour. It only deletes directories if they're
owned by the removed package and empty.

> But then I decided to check my whole /usr tree and found more orphans
> than I expected.

Feel free to open bugs against the offending packages. Complete file and
directory ownership is mandated in the packaging guidelines.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Orphaning vdr-streamdev

2016-10-07 Thread Thomas Sailer


On 09/27/2016 04:47 AM, Felix Kaechele wrote:


I'm orphaning vdr-streamdev since I no longer use it. There shouldn't be any 
open issues with this one.


Since apparently nobody is all that keen to take it and I'm still using 
it, I'm willing to take it.


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

OpenSSL 1.1.0 in Rawhide very soon

2016-10-07 Thread Tomas Mraz

Hi all,

the openssl will be rebased in Rawhide to 1.1.0 on Monday. There will
be also 1.0.2 compat package (compat-openssl10) so the dependencies are
not broken and Rawhide should be installable. Also things that do not
depend on openssl should be rebuildable without changes.

On the other hand due to the major API changes in 1.1.0 if your package
uses OpenSSL it will not be possible to rebuild it without patching.
Some upstreams already updated their code to work with 1.1.0 so if it
is your case again there might not be any problems rebuilding it.

I will be also working on patching and rebuilding the dependencies
starting with minimal install and expanding to broader installs of
Fedora. However there might be cases where the package is using some
obscure features of the old 1.0.x API and the port might be non-trivial 
- I do not expect such packages to be common however cooperation with
the respective package upstream might be needed in such cases.

At worst if the patching of a package is highly non-trivial and the
upstream is not responsive we might have to drop the package from
Fedora.

We do not want to keep 1.0.2 devel around as that could make it to look
like the 1.0.2 is still fully "supported" in Fedora and there would be
no incentive to switch to 1.1.0. Also to get any new features from
upstream OpenSSL we have to move to newer versions as they are released
as the old versions get only bug fixes.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


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

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

2016-10-07 Thread Frank Ch. Eigler


>> > [...]  I always run dnf manually from the
>> > command line, in a VT logged in as root.  And I can run X while doing
>> > this and I've never had a dnf update issue.

To the extent that the problem is that dnf gets interrupted when its
xterm dies, can that be worked around by dnf SIG_IGN'ing SIGHUP /
SIGPIPE?  Users could still deliberately interrupt it with SIGINT, but a
terminal closure could in theory let it finish unmolested.

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

grub, grubby, btrfs, was: PSA: Do not run 'dnf update' inside GNOME, KDE ...

Changed this subject to match the other one I changed, so if I'm doing
it wrong at least I'm consistent!

On Fri, Oct 7, 2016 at 9:22 AM, Kevin Fenzi  wrote:
> On Fri, 7 Oct 2016 00:18:21 -0400
> Eric Griffith  wrote:
>
>> I'm just thinking out loud here, but, given that rpm-ostree does not
>> use grubby, and we do have the Bootloader Spec, and no other distro
>> uses grubby, would it be prudent to take a really hard look at
>> whether grubby is still a path we want to walk?
>
> Well, the bootloader spec has a lot of things missing that we
> expect/want to support. Like multibooting, BIOS boot chainloading
> booting, etc.
>
> Matthew Garrett started working on proposed changes to the spec:
> https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/
> but the owners of the spec didn't seem to interested in those cases and
> Matthew went on to other work.

In effect, rpm-ostree uses the newer spec configuration format for a
narrowed use case. So there's the original spec, the mjg59 variant of
the spec, the rpm-ostree variant of mjg59's spec, and the Fedora GRUB
blscfg variant, all of which are very similar but mutually
incompatible in one way or another. Since Fedora does its own thing in
this area anyway, I don't see it as a problem to continue on that
path.

The way this works with rpm-ostree now, it creates snippets only for
its own installation, and then runs grub2-mkconfig. A new
/etc/grub.d/15_ostree  [1] reads those snippets, reformats their
content to GRUB format and inserts that into the new grub.cfg. So
everything else grub2-mkconfig is set to do like other Linux and
Windows discovery, still happens. That doesn't really need to be in
the Bootloader Spec, it's sort of a can of worms anyway.

My recommendation is fork a 3rd written spec based on rpm-ostree's
real world implementation; modify the spec to add things *that are
useful to Fedora that also come with people willing to do the work to
implement it*, whether from the prior two specs or just plain good
ideas; and then fix blscfg.mod and rpm-ostree to match the spec. In
particular I'd like to see blscfg.mod do an in-memory merge of
grub.cfg and the rpm-ostree created boot configuration snippet files,
rather than stomping on the grub.cfg with grub2-mkconfig everytime.
This gets back to the original idea behind grubby and bootloader spec
to stop stomping on bootloader files. And maybe we end up with
something that isn't like watching Rejected 11 times in a row [2]

It's probably a good idea to run it all by the syslinux and uboot
folks too in case they want to support the drop in scripts format at
least.

> So, I think we would need to get buyin to get our changes into the spec
> and get everyone to agree on it before we would want to move to it.

The original spec is unworkable. And attempts to expand the upstream
spec for real world use cases needed in Fedora haven't gone anywhere.
It exchanges reduced complexity in the bootloader, by increasing it in
the installer and increasing wasted space on the drive. I'd try to
help make it salvageable but I think it's pointless. Make a Fedora
specific version and if people like it they can adopt it.

[1]
https://github.com/ostreedev/ostree/tree/master/src/boot/grub2

[2]
https://www.youtube.com/watch?v=MuOvqeABHvQ
https://en.wikipedia.org/wiki/Rejected

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

Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

On Fri, Oct 7, 2016 at 5:58 PM, Andrew Lutomirski  wrote:
> On Fri, Oct 7, 2016 at 2:32 PM, Chris Murphy  wrote:
>> Modifying the image at all breaks the existing media verification
>> option in the boot menu, and we know people get bad writes using bad
>> or flaky media
>
> This part, at least, should be relatively straightforward to get
> around.  The allocation of a persistence partition literally just
> create a new partition, so if the media verification could learn to
> verify the partition (bitwise) instead of the whole device, it would
> work fine.

Maybe.

This is what we're doing to create our ISO images. Note there are
three partition maps needing modification: MBR, GPT, and APM.
https://mjg59.dreamwidth.org/4957.html

The md5's are embedded in an ISO 9660 metadata area using
implantisomd5, and rd.live.check causes dracut to run checkisomd5.
This isn't partition based. I don't see a configurable offset, but
maybe there's a fixed offset that puts the partition maps outside the
area being checked.

Anyway, it's still suboptimal:

1. On macOS, right after media creation, the OS always automounts the
HFS+ volume found on these ISOs, read-write. This instantly changes
the content of a portion of the media that is subject to media
verification. So any stick created on macOS always fails media
verification. Mbriza has said he's heard this happens on Windows also.
I haven't tested it.

2. It's slow and interrupts user flow.

3. It's one shot, not every read is checked every time.

4. The user can opt out.

For optical media, it's a good solution that's portable. Optical media
is unlikely to have transient corruptions. But I think it's inadequate
for flash media where they can produce transient corruption on reads
without any error being reported by the stick itself. So if media
verification is at all important, I think the longer term plan should
look at dmverity or Btrfs seed device.

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

Re: A new tool for backward compatibility analysis of API/ABI interfaces in RPM packages

2016-10-07 Thread Pierre-Yves Chibon

On Thu, Oct 06, 2016 at 05:58:10PM +0300, Ponomarenko Andrey wrote:
> 
> 
> 06.10.2016, 08:23, "Pierre-Yves Chibon":
> > On Wed, Oct 05, 2016 at 06:36:16PM +0300, Ponomarenko Andrey wrote:
> >>  The tool is based on different software stack for analysis of backward
> >>  compatibility developed since 2009: https://github.com/lvc (ABI 
> >> Compliance Checker, ABI Dumper, etc.)
> >>
> >>  RedHat created an alternative libabigail tool in 2013. Implementation and 
> >> reports are completely different. But anyway, two is better than one. Now 
> >> we can verify reports of both tools by each other.
> >
> > I'm confused what Red Hat as to do in there. As far as I know, it's a 
> > person not
> > a company that runs the development or libabigail and I very much doubt that
> > this person was tasked to do that by some higher power.
> >
> > That being said, did you look at it? Did you make some comparison on how it
> > performs compared to this stack you mention?
> > Are there times where one finds something that the other don't, vice-versa?
> > Can they be ranked or are they too different to be compared?
> >
> > Thanks,
> > Pierre
> 
> After a closer look at the source code, reports and docs of abipkgdiff / 
> libabigail tools I can list some pros and cons of 
> https://github.com/lvc/pkg-abidiff / abi-compliance-checker:
> 
> PROS
> - separated analysis of both backward binary compatibility and backward 
> source compatibility
> - assigning severity levels to ABI changes
> - explaining effects of ABI changes

> - checks for more compatibility rules
> - less false positives

Can you quantify these last two? Are we speaking about 1 or 2 more checks or
much more?
Are we speaking about 1 or 2 more false positives or much more? Over how many
packages?

Also, while I'm not involved in either projects, did you report this to the
libabigail maintainers? I'm sure he would welcome bug reports and test-cases for
their project.


Maybe there is a way to collaborate in such way that both projects improve :)


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

Re: problems in Virtualbox

2016-10-07 Thread Pavel Valena

Hi,

- Original Message -
> From: "mario riassetto" 
> To: devel@lists.fedoraproject.org
> Sent: Tuesday, October 4, 2016 2:52:41 PM
> Subject: problems in Virtualbox
> 
> I have noted a one problem in to the start of the image in Virtualbox.
> Virtualbox in fedora, not starting the virtual system installed.

can you elaborate on that a bit?
 - Fedora version
 - Error message (logs)
 - Virtualbox version

For me, everything works fine in Fedora 23 with virtualbox from rpmfusion.

Pavel Valena
Associate Software Engineer
Brno, Czech Republic

RED HAT | TRIED. TESTED. TRUSTED.
All of the airlines in the Fortune Global 500 rely on Red Hat.
Find out why at Trusted | Red Hat


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

[389-devel] please review: Ticket 49003 - console - always use the host and port when constructing an LDAP URL

2016-10-07 Thread Mark Reynolds

https://fedorahosted.org/389/ticket/49003

ds-console

https://fedorahosted.org/389/attachment/ticket/49003/0001-Ticket-49003-Add-the-host-and-port-to-the-ldapurl-in.patch

idm-console-framework

https://fedorahosted.org/389/attachment/ticket/49003/0001-Ticket-49003-Add-host-and-port-to-LDAP-URL-construct.patch

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

dfateyev uploaded Mock-Sub-1.07.tar.gz for perl-Mock-Sub

d17f1b3657aea192c16c440cba845ec2  Mock-Sub-1.07.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Mock-Sub/Mock-Sub-1.07.tar.gz/md5/d17f1b3657aea192c16c440cba845ec2/Mock-Sub-1.07.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

dfateyev pushed to perl-Mock-Sub (epel7). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild"

From ac083305cb05ada25f8171340387bcd299efc4fd Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Thu, 4 Feb 2016 14:36:42 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild

---
 perl-Mock-Sub.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mock-Sub.spec b/perl-Mock-Sub.spec
index c3b4151..5e3a85e 100644
--- a/perl-Mock-Sub.spec
+++ b/perl-Mock-Sub.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mock-Sub
 Version:1.06
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:Mock package, object and standard subroutines, with unit 
testing in mind
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -63,5 +63,8 @@ make test RELEASE_TESTING=1
 
 
 %changelog
+* Thu Feb 04 2016 Fedora Release Engineering  - 
1.06-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
+
 * Sun Jan 24 2016 Denis Fateyev  - 1.06-1
 - Initial release
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Mock-Sub.git/commit/?h=epel7=ac083305cb05ada25f8171340387bcd299efc4fd
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

dfateyev pushed to perl-Mock-Sub (el6). "Mandatory Perl build-requires added "

From ce37685364f1ec31f3babb01eebe3ee78eef597d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Fri, 24 Jun 2016 09:42:44 +0200
Subject: Mandatory Perl build-requires added
 

---
 perl-Mock-Sub.spec | 1 +
 1 file changed, 1 insertion(+)

diff --git a/perl-Mock-Sub.spec b/perl-Mock-Sub.spec
index 33c83cd..1f04199 100644
--- a/perl-Mock-Sub.spec
+++ b/perl-Mock-Sub.spec
@@ -13,6 +13,7 @@ BuildRequires:  coreutils
 BuildRequires:  findutils
 BuildRequires:  make
 BuildRequires:  perl
+BuildRequires:  perl-generators
 BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(strict)
 BuildRequires:  perl(warnings)
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Mock-Sub.git/commit/?h=el6=ce37685364f1ec31f3babb01eebe3ee78eef597d
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

dfateyev pushed to perl-Mock-Sub (el6). "Perl 5.24 rebuild"

From d96c58f226d4f7734037557f54dcc4243c61ccc9 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Sun, 15 May 2016 17:05:20 +0200
Subject: Perl 5.24 rebuild

---
 perl-Mock-Sub.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mock-Sub.spec b/perl-Mock-Sub.spec
index 5e3a85e..33c83cd 100644
--- a/perl-Mock-Sub.spec
+++ b/perl-Mock-Sub.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mock-Sub
 Version:1.06
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:Mock package, object and standard subroutines, with unit 
testing in mind
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -63,6 +63,9 @@ make test RELEASE_TESTING=1
 
 
 %changelog
+* Sun May 15 2016 Jitka Plesnikova  - 1.06-3
+- Perl 5.24 rebuild
+
 * Thu Feb 04 2016 Fedora Release Engineering  - 
1.06-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Mock-Sub.git/commit/?h=el6=d96c58f226d4f7734037557f54dcc4243c61ccc9
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

dfateyev pushed to perl-Mock-Sub (epel7). "perl-Mock-Sub: 1.07 release"

From e9ac2a0907d8b6b655d81677a58c813248e1abe1 Mon Sep 17 00:00:00 2001
From: Denis Fateyev 
Date: Sat, 8 Oct 2016 04:10:41 +0600
Subject: perl-Mock-Sub: 1.07 release

---
 .gitignore | 1 +
 perl-Mock-Sub.spec | 7 +--
 sources| 2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index 6de9688..19773e2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 /Mock-Sub-1.06.tar.gz
+/Mock-Sub-1.07.tar.gz
diff --git a/perl-Mock-Sub.spec b/perl-Mock-Sub.spec
index 1f04199..4af9b5e 100644
--- a/perl-Mock-Sub.spec
+++ b/perl-Mock-Sub.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mock-Sub
-Version:1.06
-Release:3%{?dist}
+Version:1.07
+Release:1%{?dist}
 Summary:Mock package, object and standard subroutines, with unit 
testing in mind
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -64,6 +64,9 @@ make test RELEASE_TESTING=1
 
 
 %changelog
+* Fri Oct 07 2016 Denis Fateyev  - 1.07-1
+- Update to 1.07 release
+
 * Sun May 15 2016 Jitka Plesnikova  - 1.06-3
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 7e486fd..ac660b5 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-532acb250e2c80e965b6f95513254488  Mock-Sub-1.06.tar.gz
+d17f1b3657aea192c16c440cba845ec2  Mock-Sub-1.07.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Mock-Sub.git/commit/?h=epel7=e9ac2a0907d8b6b655d81677a58c813248e1abe1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

dfateyev pushed to perl-Mock-Sub (f25). "perl-Mock-Sub: 1.07 release"

From e9ac2a0907d8b6b655d81677a58c813248e1abe1 Mon Sep 17 00:00:00 2001
From: Denis Fateyev 
Date: Sat, 8 Oct 2016 04:10:41 +0600
Subject: perl-Mock-Sub: 1.07 release

---
 .gitignore | 1 +
 perl-Mock-Sub.spec | 7 +--
 sources| 2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index 6de9688..19773e2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 /Mock-Sub-1.06.tar.gz
+/Mock-Sub-1.07.tar.gz
diff --git a/perl-Mock-Sub.spec b/perl-Mock-Sub.spec
index 1f04199..4af9b5e 100644
--- a/perl-Mock-Sub.spec
+++ b/perl-Mock-Sub.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mock-Sub
-Version:1.06
-Release:3%{?dist}
+Version:1.07
+Release:1%{?dist}
 Summary:Mock package, object and standard subroutines, with unit 
testing in mind
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -64,6 +64,9 @@ make test RELEASE_TESTING=1
 
 
 %changelog
+* Fri Oct 07 2016 Denis Fateyev  - 1.07-1
+- Update to 1.07 release
+
 * Sun May 15 2016 Jitka Plesnikova  - 1.06-3
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 7e486fd..ac660b5 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-532acb250e2c80e965b6f95513254488  Mock-Sub-1.06.tar.gz
+d17f1b3657aea192c16c440cba845ec2  Mock-Sub-1.07.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Mock-Sub.git/commit/?h=f25=e9ac2a0907d8b6b655d81677a58c813248e1abe1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: including EOL and vulnerable software in Fedora

2016-10-07 Thread Zbigniew Jędrzejewski-Szmek

On Fri, Oct 07, 2016 at 06:43:10PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> Dear All,
> I was made aware that EOL software with known security bugs that will
> not be fixed upstream (due to EOL status) was reviewed and accepted into
> Fedora recently. This came on the back of the FPC ticket [1] asking to
> make some changes in the Python Packaging Guidelines. I did go back and
> re-read our current guidelines and found that we don't have any policy
> on that. As a result, I opened a FESCo ticket [2] with the aim of
> establishing a clear policy on how to treat EOL software with known
> security vulnerabilities.

A parallel could be drawn between previous python versions and
previous C standards, like c89, c90, c99, etc. One could say that they
are obsolete, but it is still very convenient to be able to add
CFLAGS=-ansi. The difference is that gcc has this built in, while
python does not have compatibility with previous "standards", so the
only way to test with previous versions is to run those previous
versions.  It's damn useful for testing, and it's much more convenient
to do it through dnf install than through
virtualization/containers/cloud/hand-compilation/copr/other-nonstandard-things.

So from my side, a vote for
1. labelling old pythons very clearly as such,
2. allowing people to install them using dnf.

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

[389-devel] please review: Ticket 49003 - idm-console-framework - remove incorrect restriction on host and port in LDAP URLs

2016-10-07 Thread Mark Reynolds

https://fedorahosted.org/389/ticket/49003

https://fedorahosted.org/389/attachment/ticket/49003/0001-Ticket-49003-Allow-LDAP-Urls-with-host-and-port.patch
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

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

2016-10-07 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 578  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 341  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
  59  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-23fa04bf1c   
redis-3.2.3-1.el7
  58  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-4b8dd3488d   
knot-1.6.8-1.el7
  43  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e8f4ff76b3   
chicken-4.11.0-3.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-aca1572ceb   
mingw-gnutls-3.3.24-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-28ad6782b3   
php-adodb-5.20.6-2.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-208f62faa6   
links-2.13-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-452534ff97   
php-ZendFramework-1.12.20-1.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-39560a2353   
mingw-c-ares-1.12.0-1.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-60045af95e   
mingw-libidn-1.33-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-0890ae6d2d   
nsd-4.1.13-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-387d58ef27   
chromium-53.0.2785.143-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-03fb3c1531   
banshee-2.6.2-11.el7 dbus-sharp-0.7.0-15.el7 dbus-sharp-glib-0.5.0-13.el7 
gdata-sharp-1.4.0.2-18.el7 gio-sharp-0.3-14.el7 gkeyfile-sharp-0.1-19.el7 
gnome-sharp-2.24.2-12.el7 gtk-sharp-beans-2.14.0-17.el7 
gtk-sharp2-2.12.26-3.el7 gtk-sharp3-2.99.3-16.el7 gudev-sharp-0.1-18.el7 
libappindicator-12.10.0-11.el7 libgpod-0.8.3-8.el7 mono-4.2.4-7.el7 
mono-addins-1.1-3.el7 mono-cecil-0.9.6-6.el7 mono-zeroconf-0.9.0-16.el7 
notify-sharp-0.4.0-0.26.20100411svn.el7 notify-sharp3-3.0.3-2.el7 
nunit-3.5-1.el7 nunit2-2.6.4-14.el7 pinta-1.6-5.el7 taglib-sharp-2.1.0.0-3.el7


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

php-sabre-vobject-3.5.3-1.el7

Details about builds:



 php-sabre-vobject-3.5.3-1.el7 (FEDORA-EPEL-2016-e4ea12ae67)
 Library to parse and manipulate iCalendar and vCard objects

Update Information:

**Version 3.5.3**  * Fix #331: Fix dealing with multiple overridden instances
falling on the same date/time (afedyk-sugarcrm).

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

[Bug 1380152] perl-HTTP-Tiny 0.068 pulls in lots of new dependencies including Xorg

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |ON_QA



--- Comment #16 from Fedora Update System  ---
perl-URI-1.71-5.fc25 has been pushed to the Fedora 25 testing repository. If
problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-5c74e5732c

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

dist.depcheck PASSED for FEDORA-2016-50a2bc7997

dist.depcheck PASSED for FEDORA-2016-50a2bc7997

https://taskotron.fedoraproject.org/artifacts/all/571dad3c-8ca0-11e6-b011-525400120b80/task_output/FEDORA-2016-50a2bc7997.i386.log
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 807793] Please build pcsc-perl for EPEL6

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|pcsc-perl-1.4.14-2.el7  |pcsc-perl-1.4.14-2.el7
   ||pcsc-perl-1.4.14-2.el6



--- Comment #10 from Fedora Update System  ---
pcsc-perl-1.4.14-2.el6, pcsc-tools-1.4.25-1.el6 has been pushed to the Fedora
EPEL 6 stable repository. If problems still persist, please make note of it in
this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[389-devel] Re: Please review design proposal for tickets 47986 and 48976

2016-10-07 Thread Ludwig Krispenz

there is a problem not yet covered in the proposal: setting the backend 
to "referral-on-update" until the topology is in sync prevents to ealry 
client updates, but what to do about internal updates, eg passwordpolicy 
attributes.


I have a wild idea, but maybe someone  has a suggestion on how to handle 
this


thanks,
Ludwig

On 10/05/2016 05:51 PM, Ludwig Krispenz wrote:


On 09/30/2016 02:15 AM, Noriko Hosoi wrote:

Hi Ludwig,

On 09/29/2016 05:43 AM, Ludwig Krispenz wrote:

This is the initial proposal, thanks for your feedback

http://www.port389.org/docs/389ds/design/delay-accepting-updates-after-init.html 




Please help me understanding the design...

I'm having a bit hard time to figure out the relationship/dependency 
among these 3 config parameters.


sorry if I was not clear enough, I will update the doc, but let me try 
to explain here


nsslapd-replica-accept-updates-state: on/off
nsslapd-replica-accept-updates-delay: -1/0/n
nsslapd-replica-accept-updates-auto: on/off

Are they independent or dependent?  Do they take any combinations -- 
2 * 3 * 2 == 12.



no. the primary parameter is: nsslapd-replica-accept-updates-state
If it is off, the other determine when it should be set to on again 
(without an explicite change by an admin).

if it is on, the other two will not be used

independent of auto on/off the "delay" defines if(>=0) the state will 
be reset to on and when


the "auto" param determines if the server should in the defined 
"delay" it should try to detect if it is in sync and switch to "on" 
earlier.



There are 12 different behaviors?  (assuming n for -delay is one case :)

What is your recommendation to the customers?  I mean, what is the 
default setting?


that is a good question, there is the option to choose the default by 
what is "my" recommendation (auto: on, delay: n) or what is backward 
compatible (no change in default behaviour: auto off, delay: 0)


  For instance, if -auto is "on", when an online init is executed on 
the master, the scenario is automatically kicked in?


Thanks,
--noriko





||


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


--
Red Hat GmbH,http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander


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


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

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

dist.depcheck PASSED for FEDORA-2016-50a2bc7997

dist.depcheck PASSED for FEDORA-2016-50a2bc7997

https://taskotron.fedoraproject.org/artifacts/all/571dad3c-8ca0-11e6-b011-525400120b80/task_output/FEDORA-2016-50a2bc7997.x86_64.log
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

dfateyev pushed to perl-Mock-Sub (el6). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild"

From ac083305cb05ada25f8171340387bcd299efc4fd Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Thu, 4 Feb 2016 14:36:42 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild

---
 perl-Mock-Sub.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mock-Sub.spec b/perl-Mock-Sub.spec
index c3b4151..5e3a85e 100644
--- a/perl-Mock-Sub.spec
+++ b/perl-Mock-Sub.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mock-Sub
 Version:1.06
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:Mock package, object and standard subroutines, with unit 
testing in mind
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -63,5 +63,8 @@ make test RELEASE_TESTING=1
 
 
 %changelog
+* Thu Feb 04 2016 Fedora Release Engineering  - 
1.06-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
+
 * Sun Jan 24 2016 Denis Fateyev  - 1.06-1
 - Initial release
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Mock-Sub.git/commit/?h=el6=ac083305cb05ada25f8171340387bcd299efc4fd
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1382865] New: manually specified Requires: are ignored

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

Bug ID: 1382865
   Summary: manually specified Requires: are ignored
   Product: Fedora
   Version: rawhide
 Component: perl-generators
  Assignee: jples...@redhat.com
  Reporter: domi...@greysector.net
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Created attachment 1208272
  --> https://bugzilla.redhat.com/attachment.cgi?id=1208272=edit
example package showing the bug

Description of problem:
Manually specified Requires: perl(foo) from the specfile do not make it into
final package Requires:.

Version-Release number of selected component (if applicable):
1.10-1.fc25

How reproducible:
Always.

Steps to Reproduce:
1. Try building the attached package.
2. Check the Requires of the resulting package.

Actual results:
Requires: /usr/bin/perl perl(Data::Dumper) perl(File::Copy) perl(File::Path)
perl(Getopt::Long) perl(IO::Handle) perl(IO::Select) perl(IO::Socket)
perl(POSIX) perl(Socket) perl(strict)

Expected results:
Requires: /usr/bin/perl perl(Bit::Vector) perl(Carp::Clan) perl(Data::Dumper)
perl(Date::Calc) perl(File::Copy) perl(File::Path) perl(Getopt::Long)
perl(IO::Handle) perl(IO::Select) perl(IO::Socket) perl(IPTables::ChainMgr)
perl(IPTables::Parse) perl(NetAddr::IP) perl(POSIX) perl(Socket) perl(Storable)
perl(strict) perl(Unix::Syslog)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1382865] manually specified Requires: perl(foo) are ignored

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

Dominik 'Rathann' Mierzejewski  changed:

   What|Removed |Added

 Blocks||1382875




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1382875
[Bug 1382875] Review Request: psad - Port Scan Attack Detector (psad)
watches for suspect traffic
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

dfateyev pushed to perl-Mock-Sub (epel7). "Perl 5.24 rebuild"

From d96c58f226d4f7734037557f54dcc4243c61ccc9 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Sun, 15 May 2016 17:05:20 +0200
Subject: Perl 5.24 rebuild

---
 perl-Mock-Sub.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mock-Sub.spec b/perl-Mock-Sub.spec
index 5e3a85e..33c83cd 100644
--- a/perl-Mock-Sub.spec
+++ b/perl-Mock-Sub.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mock-Sub
 Version:1.06
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:Mock package, object and standard subroutines, with unit 
testing in mind
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -63,6 +63,9 @@ make test RELEASE_TESTING=1
 
 
 %changelog
+* Sun May 15 2016 Jitka Plesnikova  - 1.06-3
+- Perl 5.24 rebuild
+
 * Thu Feb 04 2016 Fedora Release Engineering  - 
1.06-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Mock-Sub.git/commit/?h=epel7=d96c58f226d4f7734037557f54dcc4243c61ccc9
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

dfateyev pushed to perl-Mock-Sub (f24). "Perl 5.24 rebuild"

From d96c58f226d4f7734037557f54dcc4243c61ccc9 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Sun, 15 May 2016 17:05:20 +0200
Subject: Perl 5.24 rebuild

---
 perl-Mock-Sub.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mock-Sub.spec b/perl-Mock-Sub.spec
index 5e3a85e..33c83cd 100644
--- a/perl-Mock-Sub.spec
+++ b/perl-Mock-Sub.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mock-Sub
 Version:1.06
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:Mock package, object and standard subroutines, with unit 
testing in mind
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -63,6 +63,9 @@ make test RELEASE_TESTING=1
 
 
 %changelog
+* Sun May 15 2016 Jitka Plesnikova  - 1.06-3
+- Perl 5.24 rebuild
+
 * Thu Feb 04 2016 Fedora Release Engineering  - 
1.06-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Mock-Sub.git/commit/?h=f24=d96c58f226d4f7734037557f54dcc4243c61ccc9
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

dfateyev pushed to perl-Mock-Sub (epel7). "Mandatory Perl build-requires added "

From ce37685364f1ec31f3babb01eebe3ee78eef597d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Fri, 24 Jun 2016 09:42:44 +0200
Subject: Mandatory Perl build-requires added
 

---
 perl-Mock-Sub.spec | 1 +
 1 file changed, 1 insertion(+)

diff --git a/perl-Mock-Sub.spec b/perl-Mock-Sub.spec
index 33c83cd..1f04199 100644
--- a/perl-Mock-Sub.spec
+++ b/perl-Mock-Sub.spec
@@ -13,6 +13,7 @@ BuildRequires:  coreutils
 BuildRequires:  findutils
 BuildRequires:  make
 BuildRequires:  perl
+BuildRequires:  perl-generators
 BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(strict)
 BuildRequires:  perl(warnings)
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Mock-Sub.git/commit/?h=epel7=ce37685364f1ec31f3babb01eebe3ee78eef597d
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

dfateyev pushed to perl-Mock-Sub (el6). "perl-Mock-Sub: 1.07 release"

From e9ac2a0907d8b6b655d81677a58c813248e1abe1 Mon Sep 17 00:00:00 2001
From: Denis Fateyev 
Date: Sat, 8 Oct 2016 04:10:41 +0600
Subject: perl-Mock-Sub: 1.07 release

---
 .gitignore | 1 +
 perl-Mock-Sub.spec | 7 +--
 sources| 2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index 6de9688..19773e2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 /Mock-Sub-1.06.tar.gz
+/Mock-Sub-1.07.tar.gz
diff --git a/perl-Mock-Sub.spec b/perl-Mock-Sub.spec
index 1f04199..4af9b5e 100644
--- a/perl-Mock-Sub.spec
+++ b/perl-Mock-Sub.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mock-Sub
-Version:1.06
-Release:3%{?dist}
+Version:1.07
+Release:1%{?dist}
 Summary:Mock package, object and standard subroutines, with unit 
testing in mind
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -64,6 +64,9 @@ make test RELEASE_TESTING=1
 
 
 %changelog
+* Fri Oct 07 2016 Denis Fateyev  - 1.07-1
+- Update to 1.07 release
+
 * Sun May 15 2016 Jitka Plesnikova  - 1.06-3
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 7e486fd..ac660b5 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-532acb250e2c80e965b6f95513254488  Mock-Sub-1.06.tar.gz
+d17f1b3657aea192c16c440cba845ec2  Mock-Sub-1.07.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Mock-Sub.git/commit/?h=el6=e9ac2a0907d8b6b655d81677a58c813248e1abe1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1382865] manually specified Requires: are ignored

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

Dominik 'Rathann' Mierzejewski  changed:

   What|Removed |Added

Summary|manually specified  |manually specified
   |Requires: are ignored   |Requires: perl(foo) are
   ||ignored



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[389-devel] Jenkins build is back to normal : 389-DS-NIGHTLY #94

2016-10-07 Thread Jenkins

See 

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

pghmcfc pushed to perl-URI (perl-URI-1.71-5.fc25). "Soften Business::ISBN dependency from Requires: to Suggests: (..more)"

From c89b6346fce383d05aba97584797cac28d118d47 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Fri, 7 Oct 2016 08:11:35 +0100
Subject: Soften Business::ISBN dependency from Requires: to Suggests:

This avoids pulling in gd and X libraries (#1380152)
---
 perl-URI.spec | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/perl-URI.spec b/perl-URI.spec
index 78ad0a7..487603c 100644
--- a/perl-URI.spec
+++ b/perl-URI.spec
@@ -1,6 +1,6 @@
 Name:   perl-URI
 Version:1.71
-Release:4%{?dist}
+Release:5%{?dist}
 Summary:A Perl module implementing URI parsing and manipulation
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -16,10 +16,6 @@ BuildRequires:  perl-generators
 BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.76
 BuildRequires:  perl(utf8)
 # Module Runtime
-# Business::ISBN → Test::Pod → Pod::Simple → HTML::Entities (HTML::Parser) → 
URI
-%if 0%{!?perl_bootstrap:1}
-BuildRequires:  perl(Business::ISBN)
-%endif
 BuildRequires:  perl(Carp)
 BuildRequires:  perl(constant)
 BuildRequires:  perl(Cwd)
@@ -43,13 +39,20 @@ BuildRequires:  perl(Test)
 BuildRequires:  perl(Test::More) >= 0.96
 # Runtime
 Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
-Requires:   perl(Business::ISBN)
 Requires:   perl(Cwd)
 Requires:   perl(Data::Dumper)
 Requires:   perl(Encode)
 Requires:   perl(MIME::Base64) >= 2
 Requires:   perl(Net::Domain)
 
+# Optional Functionality
+# Business::ISBN pulls in gd and X libraries for barcode support, hence this 
soft dependency (#1380152)
+# Business::ISBN → Test::Pod → Pod::Simple → HTML::Entities (HTML::Parser) → 
URI
+%if 0%{!?perl_bootstrap:1}
+BuildRequires:  perl(Business::ISBN)
+%endif
+Suggests:   perl(Business::ISBN)
+
 %description
 This module implements the URI class. Objects of this class represent
 "Uniform Resource Identifier references" as specified in RFC 2396 (and
@@ -88,6 +91,10 @@ make test
 %{_mandir}/man3/URI::ldap.3*
 
 %changelog
+* Fri Oct  7 2016 Paul Howarth  - 1.71-5
+- Soften Business::ISBN dependency from Requires: to Suggests: to avoid
+  pulling in gd and X libraries (#1380152)
+
 * Wed May 18 2016 Jitka Plesnikova  - 1.71-4
 - Perl 5.24 re-rebuild of bootstrapped packages
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-URI.git/commit/?h=perl-URI-1.71-5.fc25=c89b6346fce383d05aba97584797cac28d118d47
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pghmcfc pushed to perl-URI (perl-URI-1.71-5.fc26). "Soften Business::ISBN dependency from Requires: to Suggests: (..more)"

This commit already existed in another branch.

http://pkgs.fedoraproject.org/cgit/perl-URI.git/commit/?h=perl-URI-1.71-5.fc26=c89b6346fce383d05aba97584797cac28d118d47
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1380152] perl-HTTP-Tiny 0.068 pulls in lots of new dependencies including Xorg

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

Paul Howarth  changed:

   What|Removed |Added

 CC||jples...@redhat.com
  Component|perl-IO-Socket-SSL  |perl-URI



--- Comment #15 from Paul Howarth  ---
OK, I've done that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

2016-10-07 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 578  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 340  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
  59  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-23fa04bf1c   
redis-3.2.3-1.el7
  57  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-4b8dd3488d   
knot-1.6.8-1.el7
  42  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e8f4ff76b3   
chicken-4.11.0-3.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-aca1572ceb   
mingw-gnutls-3.3.24-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-28ad6782b3   
php-adodb-5.20.6-2.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-208f62faa6   
links-2.13-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-452534ff97   
php-ZendFramework-1.12.20-1.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-39560a2353   
mingw-c-ares-1.12.0-1.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-60045af95e   
mingw-libidn-1.33-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-0890ae6d2d   
nsd-4.1.13-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-387d58ef27   
chromium-53.0.2785.143-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-03fb3c1531   
banshee-2.6.2-11.el7 dbus-sharp-0.7.0-15.el7 dbus-sharp-glib-0.5.0-13.el7 
gdata-sharp-1.4.0.2-18.el7 gio-sharp-0.3-14.el7 gkeyfile-sharp-0.1-19.el7 
gnome-sharp-2.24.2-12.el7 gtk-sharp-beans-2.14.0-17.el7 
gtk-sharp2-2.12.26-3.el7 gtk-sharp3-2.99.3-16.el7 gudev-sharp-0.1-18.el7 
libappindicator-12.10.0-11.el7 libgpod-0.8.3-8.el7 mono-4.2.4-7.el7 
mono-addins-1.1-3.el7 mono-cecil-0.9.6-6.el7 mono-zeroconf-0.9.0-16.el7 
notify-sharp-0.4.0-0.26.20100411svn.el7 notify-sharp3-3.0.3-2.el7 
nunit-3.5-1.el7 nunit2-2.6.4-14.el7 pinta-1.6-5.el7 taglib-sharp-2.1.0.0-3.el7


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

acme-tiny-0.1-10.20160810git5a7b4e7.el7
drupal7-7.51-1.el7
fedfind-2.5.0-1.el7
fedpkg-copr-0.8-1.el7
guacamole-server-0.9.9-1.el7
libgsasl-1.8.0-8.el7
pdf-stapler-0.3.3-8.el7
php-symfony-2.8.12-2.el7
php-twig-1.26.1-1.el7
python-pyroute2-0.4.9-1.el7
python-sync2jira-0.4-1.el7
relval-2.1.4-1.el7
tito-0.6.7-1.el7
uwsgi-2.0.14-1.el7
x2goserver-4.0.1.19-12.el7

Details about builds:



 acme-tiny-0.1-10.20160810git5a7b4e7.el7 (FEDORA-EPEL-2016-f5a987216a)
 Tiny auditable script to issue, renew Let's Encrypt certificates

Update Information:

A tiny package to make acme-tiny secure and fire and forget easy on Fedora and
EPEL.  Read the README for hints on using acme certs with sendmail, httpd, and
dovecot.

References:

  [ 1 ] Bug #1366355 - None
https://bugzilla.redhat.com/show_bug.cgi?id=1366355




 drupal7-7.51-1.el7 (FEDORA-EPEL-2016-5813e2c938)
 An open-source content-management platform

Update Information:

https://www.drupal.org/project/drupal/releases/7.51

References:

  [ 1 ] Bug #1382177 - None
https://bugzilla.redhat.com/show_bug.cgi?id=1382177




 fedfind-2.5.0-1.el7 (FEDORA-EPEL-2016-cf25788bac)
 Fedora Finder finds Fedora

Update Information:

The major change in this update is that fedfind now has the ability to
effectively override the productmd-formatted metadata provided by Pungi in
specific cases where it's problematic. There is a new helper function,
`helpers.correct_image`, which applies these 'corrections', and the image dicts
returned by the `Release.all_images` property - commonly used for getting a flat
list of image dicts from the compose metadata - now have these corrections
applied.  This is intended to work around a [significant
issue](https://pagure.io/pungi/issue/417) that's appeared along with the
introduction of a Workstation ostree installer image for Fedora: pungi sets the
`type` for ostree installer images to `boot`, but that means there is no way to
distinguish a Workstation network install image from a Workstation ostree
install image using the metadata. This is

pghmcfc pushed to perl-URI (master). "Soften Business::ISBN dependency from Requires: to Suggests: (..more)"

From c89b6346fce383d05aba97584797cac28d118d47 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Fri, 7 Oct 2016 08:11:35 +0100
Subject: Soften Business::ISBN dependency from Requires: to Suggests:

This avoids pulling in gd and X libraries (#1380152)
---
 perl-URI.spec | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/perl-URI.spec b/perl-URI.spec
index 78ad0a7..487603c 100644
--- a/perl-URI.spec
+++ b/perl-URI.spec
@@ -1,6 +1,6 @@
 Name:   perl-URI
 Version:1.71
-Release:4%{?dist}
+Release:5%{?dist}
 Summary:A Perl module implementing URI parsing and manipulation
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -16,10 +16,6 @@ BuildRequires:  perl-generators
 BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.76
 BuildRequires:  perl(utf8)
 # Module Runtime
-# Business::ISBN → Test::Pod → Pod::Simple → HTML::Entities (HTML::Parser) → 
URI
-%if 0%{!?perl_bootstrap:1}
-BuildRequires:  perl(Business::ISBN)
-%endif
 BuildRequires:  perl(Carp)
 BuildRequires:  perl(constant)
 BuildRequires:  perl(Cwd)
@@ -43,13 +39,20 @@ BuildRequires:  perl(Test)
 BuildRequires:  perl(Test::More) >= 0.96
 # Runtime
 Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
-Requires:   perl(Business::ISBN)
 Requires:   perl(Cwd)
 Requires:   perl(Data::Dumper)
 Requires:   perl(Encode)
 Requires:   perl(MIME::Base64) >= 2
 Requires:   perl(Net::Domain)
 
+# Optional Functionality
+# Business::ISBN pulls in gd and X libraries for barcode support, hence this 
soft dependency (#1380152)
+# Business::ISBN → Test::Pod → Pod::Simple → HTML::Entities (HTML::Parser) → 
URI
+%if 0%{!?perl_bootstrap:1}
+BuildRequires:  perl(Business::ISBN)
+%endif
+Suggests:   perl(Business::ISBN)
+
 %description
 This module implements the URI class. Objects of this class represent
 "Uniform Resource Identifier references" as specified in RFC 2396 (and
@@ -88,6 +91,10 @@ make test
 %{_mandir}/man3/URI::ldap.3*
 
 %changelog
+* Fri Oct  7 2016 Paul Howarth  - 1.71-5
+- Soften Business::ISBN dependency from Requires: to Suggests: to avoid
+  pulling in gd and X libraries (#1380152)
+
 * Wed May 18 2016 Jitka Plesnikova  - 1.71-4
 - Perl 5.24 re-rebuild of bootstrapped packages
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-URI.git/commit/?h=master=c89b6346fce383d05aba97584797cac28d118d47
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pghmcfc pushed to perl-URI (f25). "Soften Business::ISBN dependency from Requires: to Suggests: (..more)"

From c89b6346fce383d05aba97584797cac28d118d47 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Fri, 7 Oct 2016 08:11:35 +0100
Subject: Soften Business::ISBN dependency from Requires: to Suggests:

This avoids pulling in gd and X libraries (#1380152)
---
 perl-URI.spec | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/perl-URI.spec b/perl-URI.spec
index 78ad0a7..487603c 100644
--- a/perl-URI.spec
+++ b/perl-URI.spec
@@ -1,6 +1,6 @@
 Name:   perl-URI
 Version:1.71
-Release:4%{?dist}
+Release:5%{?dist}
 Summary:A Perl module implementing URI parsing and manipulation
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -16,10 +16,6 @@ BuildRequires:  perl-generators
 BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.76
 BuildRequires:  perl(utf8)
 # Module Runtime
-# Business::ISBN → Test::Pod → Pod::Simple → HTML::Entities (HTML::Parser) → 
URI
-%if 0%{!?perl_bootstrap:1}
-BuildRequires:  perl(Business::ISBN)
-%endif
 BuildRequires:  perl(Carp)
 BuildRequires:  perl(constant)
 BuildRequires:  perl(Cwd)
@@ -43,13 +39,20 @@ BuildRequires:  perl(Test)
 BuildRequires:  perl(Test::More) >= 0.96
 # Runtime
 Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
-Requires:   perl(Business::ISBN)
 Requires:   perl(Cwd)
 Requires:   perl(Data::Dumper)
 Requires:   perl(Encode)
 Requires:   perl(MIME::Base64) >= 2
 Requires:   perl(Net::Domain)
 
+# Optional Functionality
+# Business::ISBN pulls in gd and X libraries for barcode support, hence this 
soft dependency (#1380152)
+# Business::ISBN → Test::Pod → Pod::Simple → HTML::Entities (HTML::Parser) → 
URI
+%if 0%{!?perl_bootstrap:1}
+BuildRequires:  perl(Business::ISBN)
+%endif
+Suggests:   perl(Business::ISBN)
+
 %description
 This module implements the URI class. Objects of this class represent
 "Uniform Resource Identifier references" as specified in RFC 2396 (and
@@ -88,6 +91,10 @@ make test
 %{_mandir}/man3/URI::ldap.3*
 
 %changelog
+* Fri Oct  7 2016 Paul Howarth  - 1.71-5
+- Soften Business::ISBN dependency from Requires: to Suggests: to avoid
+  pulling in gd and X libraries (#1380152)
+
 * Wed May 18 2016 Jitka Plesnikova  - 1.71-4
 - Perl 5.24 re-rebuild of bootstrapped packages
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-URI.git/commit/?h=f25=c89b6346fce383d05aba97584797cac28d118d47
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

2016-10-07 Thread updates

The following Fedora EPEL 5 Security updates need testing:
 Age  URL
 848  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2014-1626   
puppet-2.7.26-1.el5
 697  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2014-3849   
sblim-sfcb-1.3.8-2.el5
 340  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-edbea40516   
mcollective-2.8.4-1.el5
 312  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-582c8075e6   
thttpd-2.25b-24.el5
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-f724258766   
irssi-0.8.20-2.el5
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-803d3bfa1a   
openssl101e-1.0.1e-9.el5
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-c9c041384d   
c-ares-1.12.0-1.el5
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-b78def3304   
perl-Image-Info-1.38-6.el5


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

drupal7-7.51-1.el5

Details about builds:



 drupal7-7.51-1.el5 (FEDORA-EPEL-2016-bafba43b07)
 An open-source content-management platform

Update Information:

https://www.drupal.org/project/drupal/releases/7.51

References:

  [ 1 ] Bug #1382177 - None
https://bugzilla.redhat.com/show_bug.cgi?id=1382177

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

Broken dependencies: perl-Alien-ROOT

2016-10-07 Thread buildsys



perl-Alien-ROOT has broken dependencies in the rawhide tree:
On aarch64:
perl-Alien-ROOT-5.34.36.1-1.fc26.noarch requires root-core
Please resolve this as soon as possible.

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

Broken dependencies: perl-Data-Alias

2016-10-07 Thread buildsys



perl-Data-Alias has broken dependencies in the rawhide tree:
On aarch64:
perl-Data-Alias-1.20-2.fc24.aarch64 requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.aarch64 requires perl(:MODULE_COMPAT_5.22.1)
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.

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

dfateyev pushed to perl-Mock-Sub (f24). "Mandatory Perl build-requires added "

From ce37685364f1ec31f3babb01eebe3ee78eef597d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Fri, 24 Jun 2016 09:42:44 +0200
Subject: Mandatory Perl build-requires added
 

---
 perl-Mock-Sub.spec | 1 +
 1 file changed, 1 insertion(+)

diff --git a/perl-Mock-Sub.spec b/perl-Mock-Sub.spec
index 33c83cd..1f04199 100644
--- a/perl-Mock-Sub.spec
+++ b/perl-Mock-Sub.spec
@@ -13,6 +13,7 @@ BuildRequires:  coreutils
 BuildRequires:  findutils
 BuildRequires:  make
 BuildRequires:  perl
+BuildRequires:  perl-generators
 BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(strict)
 BuildRequires:  perl(warnings)
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Mock-Sub.git/commit/?h=f24=ce37685364f1ec31f3babb01eebe3ee78eef597d
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

dfateyev pushed to perl-Mock-Sub (f24). "perl-Mock-Sub: 1.07 release"

From e9ac2a0907d8b6b655d81677a58c813248e1abe1 Mon Sep 17 00:00:00 2001
From: Denis Fateyev 
Date: Sat, 8 Oct 2016 04:10:41 +0600
Subject: perl-Mock-Sub: 1.07 release

---
 .gitignore | 1 +
 perl-Mock-Sub.spec | 7 +--
 sources| 2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index 6de9688..19773e2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 /Mock-Sub-1.06.tar.gz
+/Mock-Sub-1.07.tar.gz
diff --git a/perl-Mock-Sub.spec b/perl-Mock-Sub.spec
index 1f04199..4af9b5e 100644
--- a/perl-Mock-Sub.spec
+++ b/perl-Mock-Sub.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mock-Sub
-Version:1.06
-Release:3%{?dist}
+Version:1.07
+Release:1%{?dist}
 Summary:Mock package, object and standard subroutines, with unit 
testing in mind
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -64,6 +64,9 @@ make test RELEASE_TESTING=1
 
 
 %changelog
+* Fri Oct 07 2016 Denis Fateyev  - 1.07-1
+- Update to 1.07 release
+
 * Sun May 15 2016 Jitka Plesnikova  - 1.06-3
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 7e486fd..ac660b5 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-532acb250e2c80e965b6f95513254488  Mock-Sub-1.06.tar.gz
+d17f1b3657aea192c16c440cba845ec2  Mock-Sub-1.07.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Mock-Sub.git/commit/?h=f24=e9ac2a0907d8b6b655d81677a58c813248e1abe1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

dfateyev pushed to perl-Mock-Sub (master). "perl-Mock-Sub: 1.07 release"

From e9ac2a0907d8b6b655d81677a58c813248e1abe1 Mon Sep 17 00:00:00 2001
From: Denis Fateyev 
Date: Sat, 8 Oct 2016 04:10:41 +0600
Subject: perl-Mock-Sub: 1.07 release

---
 .gitignore | 1 +
 perl-Mock-Sub.spec | 7 +--
 sources| 2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index 6de9688..19773e2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 /Mock-Sub-1.06.tar.gz
+/Mock-Sub-1.07.tar.gz
diff --git a/perl-Mock-Sub.spec b/perl-Mock-Sub.spec
index 1f04199..4af9b5e 100644
--- a/perl-Mock-Sub.spec
+++ b/perl-Mock-Sub.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mock-Sub
-Version:1.06
-Release:3%{?dist}
+Version:1.07
+Release:1%{?dist}
 Summary:Mock package, object and standard subroutines, with unit 
testing in mind
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -64,6 +64,9 @@ make test RELEASE_TESTING=1
 
 
 %changelog
+* Fri Oct 07 2016 Denis Fateyev  - 1.07-1
+- Update to 1.07 release
+
 * Sun May 15 2016 Jitka Plesnikova  - 1.06-3
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 7e486fd..ac660b5 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-532acb250e2c80e965b6f95513254488  Mock-Sub-1.06.tar.gz
+d17f1b3657aea192c16c440cba845ec2  Mock-Sub-1.07.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Mock-Sub.git/commit/?h=master=e9ac2a0907d8b6b655d81677a58c813248e1abe1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1382888] New: RFE: Upgrade to JSON-MaybeXS >= 1.003007

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

Bug ID: 1382888
   Summary: RFE: Upgrade to JSON-MaybeXS >= 1.003007
   Product: Fedora
   Version: 24
 Component: perl-JSON-MaybeXS
  Severity: low
  Assignee: p...@city-fan.org
  Reporter: rc040...@freenet.de
QA Contact: extras...@fedoraproject.org
CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org



Description of problem:
I would like to upgrade perl-Plack to Plack-1.0042 on f23/f24.

Unfortunately, Plack-1.0042, for unknown reasons, claims to require a
JSON-MaybeXS >= 1.003007.
=> I can't upgrade Plack on f23/f24, due to them shipping an insufficient
JSON-MaybeXS.

=> Please upgrade to a JSON-MaybeXS >= 1.003007 on f23/f24.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1380212] perl-DateTime-TimeZone-2.05 is available

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



--- Comment #4 from Fedora Update System  ---
perl-DateTime-TimeZone-2.01-3.fc23 has been pushed to the Fedora 23 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-2016-3420069149

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1380212] perl-DateTime-TimeZone-2.05 is available

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



--- Comment #5 from Fedora Update System  ---
perl-DateTime-TimeZone-2.01-3.fc24 has been pushed to the Fedora 24 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-2016-36b67f7308

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pkgdb_updater updated: description of perl-Messaging-Message

pkgdb_updater updated: description of perl-Messaging-Message
https://admin.fedoraproject.org/pkgdb/package/perl-Messaging-Message/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pkgdb_updater updated: description of perl-LaTeX-ToUnicode