[389-devel] Re: Please review 48961: Allow reset of cn=config values to default.

[William Brown]

On Fri, 2016-10-28 at 15:58 +1000, William Brown wrote:
> https://fedorahosted.org/389/ticket/48961
> 
> Please read this comment for an explanation of the change,
> 
> https://fedorahosted.org/389/ticket/48961#comment:7

http://www.port389.org/docs/389ds/design/configuration-reset.html

Combined patch.

https://fedorahosted.org/389/attachment/ticket/48961/0001-Ticket-48961-Allow-reset-of-configuration-values-to-.patch



-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane


signature.asc
Description: This is a digitally signed message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[Fedocal] Reminder meeting : Modularity WG

[jkurik]

Dear all,

You are kindly invited to the meeting:
   Modularity WG on 2016-11-01 from 15:00:00 to 16:00:00 UTC
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Meeting for the Modularity Working Group.

More information available at: [Modularity Working Group wiki 
page](https://fedoraproject.org/wiki/Modularity_Working_Group)

The agenda for the meeting is available at [modularity-wg-agendas 
pad](http://piratepad.nl/modularity-wg-agendas).



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

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

[389-devel] Please review: 49025 upgrade nunc-stans to 0.2.1

[William Brown]

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

https://fedorahosted.org/389/attachment/ticket/49025/0001-Ticket-49025-Upgrade-nunc-stans-to-0.2.1.patch

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane


signature.asc
Description: This is a digitally signed message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[Bug 1390185] perl-XML-XPath-1.38 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

-- 
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 1390179] perl-Net-CUPS-0.63 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

-- 
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 1390032] perl-Devel-CheckOS-1.79 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

-- 
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 1389743] perl-Encode-2.87 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Encode-2.87-4.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-d613a6a927

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

Re: DNF and PackageKit background data usage

[Michael Catanzaro]

On Mon, 2016-10-31 at 18:57 -0700, Adam Williamson wrote:
> Huh, since F23 or so I've found the refresh button to be pretty
> reliable. It does seem to actually force Software to go refresh the
> metadata and download available updates, now. I think in the past it
> just 'forced' a run of the refresh timer, which doesn't always
> actually
> go and check for updates, it has a bunch of conditionals that decide
> whether it will. But that got changed at some point.

The problem is that if the update fails for any reason, it reports that
everything is up to date, last check for updates at the time the update
failed. It is https://bugzilla.gnome.org/show_bug.cgi?id=763566. Note
that bug was reported with F23, you can tell by the desktop background
in my screenshot. It's still broken today I think.

In practice, updates quite often fail for me. I think PackageKit gives
up if a mirror is missing a package, which is not an infrequent
occurrence, whereas dnf just moves on to the next mirror. (Or maybe
that got fixed?) I've seen a post-install update fail five times in a
row before. :(

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

Re: DNF and PackageKit background data usage

[Adam Williamson]

On Mon, 2016-10-31 at 19:57 -0500, Michael Catanzaro wrote:

> I think it's a GNOME Software bug that it says up to date when it's
> not. I've complained about that for years. It will happily tell you
> that your freshly-installed Fedora system is up to date months after
> release, before the first update, often even after you manually check
> for updates by pressing the Refresh button. :)

Huh, since F23 or so I've found the refresh button to be pretty
reliable. It does seem to actually force Software to go refresh the
metadata and download available updates, now. I think in the past it
just 'forced' a run of the refresh timer, which doesn't always actually
go and check for updates, it has a bunch of conditionals that decide
whether it will. But that got changed at some point.
-- 
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: DNF and PackageKit background data usage

[Michael Catanzaro]

On Mon, 2016-10-31 at 15:35 -0600, Chris Murphy wrote:
> The other thing I'm seeing is, I'll get a notification for software
> updates, click on it, see the Restart & Install blue button in GNOME
> Software, close/quite GNOME Software, and at some later time relaunch
> GNOME Software and it says everything is up to date even though the
> offline update wasn't run. And if I refresh, it appears to be
> downloading a lot of data all over again - I just don't know what and
> have no good way to troubleshoot this, but the refresh is taking a
> long time, maybe 30 minutes.

I think any time you run a dnf command, the prepared update gets
invalidated. (That may be an oversimplification.) I don't think it
should be downloading unchanged packages again, though.

I think it's a GNOME Software bug that it says up to date when it's
not. I've complained about that for years. It will happily tell you
that your freshly-installed Fedora system is up to date months after
release, before the first update, often even after you manually check
for updates by pressing the Refresh button. :)

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

[Bug 1390402] New: perl-Role-Tiny-2.000004 is available

[bugzilla]

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

Bug ID: 1390402
   Summary: perl-Role-Tiny-2.04 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Role-Tiny
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, iarn...@gmail.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 2.04
Current version/release in rawhide: 2.03-3.fc25
URL: http://search.cpan.org/dist/Role-Tiny/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/10665/

-- 
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 1390400] New: perl-Moo-2.002005 is available

[bugzilla]

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

Bug ID: 1390400
   Summary: perl-Moo-2.002005 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Moo
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, iarn...@gmail.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 2.002005
Current version/release in rawhide: 2.002004-1.fc25
URL: http://search.cpan.org/dist/Moo/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/3123/

-- 
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 1390392] perl-Devel-GlobalDestruction-0.14 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Patching or scratch build for perl-Devel-GlobalDestruction-0.13 failed.

-- 
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 1390392] perl-Devel-GlobalDestruction-0.14 is available

[bugzilla]

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



--- Comment #3 from Upstream Release Monitoring 
 ---
Patches were not touched. All were applied properly

-- 
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 1390392] perl-Devel-GlobalDestruction-0.14 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
Created attachment 1215943
  --> https://bugzilla.redhat.com/attachment.cgi?id=1215943=edit
Rebase-helper rebase-helper-debug.log log file.
See for details and report the eventual error to rebase-helper
https://github.com/phracek/rebase-helper/issues.

-- 
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 1390392] New: perl-Devel-GlobalDestruction-0.14 is available

[bugzilla]

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

Bug ID: 1390392
   Summary: perl-Devel-GlobalDestruction-0.14 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Devel-GlobalDestruction
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org



Latest upstream release: 0.14
Current version/release in rawhide: 0.13-7.fc25
URL: http://search.cpan.org/dist/Devel-GlobalDestruction/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/2832/

-- 
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 1388088] perl-Module-Install-1.17 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Module-Install-1.17-1. |perl-Module-Install-1.17-1.
   |fc26|fc26
   ||perl-Module-Install-1.17-1.
   ||fc25
 Resolution|--- |ERRATA
Last Closed||2016-10-31 19:46:04



--- Comment #2 from Fedora Update System  ---
perl-Module-Install-1.17-1.fc25 has been pushed to the Fedora 25 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1387849] perl-Unicode-Collate-1.15 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Unicode-Collate-1.15-1 |perl-Unicode-Collate-1.15-1
   |.fc26   |.fc26
   ||perl-Unicode-Collate-1.16-1
   ||.fc25
 Resolution|--- |ERRATA
Last Closed||2016-10-31 19:46:15



--- Comment #11 from Fedora Update System  ---
perl-Unicode-Collate-1.16-1.fc25 has been pushed to the Fedora 25 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1388282] perl-Unicode-Collate-1.16 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Unicode-Collate-1.16-1 |perl-Unicode-Collate-1.16-1
   |.fc26   |.fc26
   ||perl-Unicode-Collate-1.16-1
   ||.fc25
 Resolution|--- |ERRATA
Last Closed||2016-10-31 19:46:13



--- Comment #5 from Fedora Update System  ---
perl-Unicode-Collate-1.16-1.fc25 has been pushed to the Fedora 25 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1388082] perl-Dist-Zilla-Plugin-Test-Compile-2.055 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Dist-Zilla-Plugin-Test
   ||-Compile-2.055-1.fc25
 Resolution|--- |ERRATA
Last Closed||2016-10-31 19:46:09



--- Comment #4 from Fedora Update System  ---
perl-Dist-Zilla-Plugin-Test-Compile-2.055-1.fc25 has been pushed to the Fedora
25 stable repository. If problems still persist, please make note of it in this
bug report.

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

[Bug 1387944] perl-Tangerine-0.23 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Tangerine-0.23-1.fc25
 Resolution|--- |ERRATA
Last Closed||2016-10-31 19:45:50



--- Comment #6 from Fedora Update System  ---
perl-Tangerine-0.23-1.fc25 has been pushed to the Fedora 25 stable repository.
If problems still persist, please make note of it in this bug report.

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

[Bug 1387805] perl-Devel-CheckOS-1.77 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Devel-CheckOS-1.77-1.f |perl-Devel-CheckOS-1.77-1.f
   |c26 |c26
   ||perl-Devel-CheckOS-1.77-1.f
   ||c25
 Resolution|--- |ERRATA
Last Closed||2016-10-31 19:45:39



--- Comment #2 from Fedora Update System  ---
perl-Devel-CheckOS-1.77-1.fc25 has been pushed to the Fedora 25 stable
repository. If problems still persist, please make note of it in this bug
report.

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

Re: DNF and PackageKit background data usage

[Rafal Luzynski]

31.10.2016 22:35 Chris Murphy  wrote:
> [...] And if I refresh, it appears to be
> downloading a lot of data all over again - I just don't know what and
> have no good way to troubleshoot this, but the refresh is taking a
> long time, maybe 30 minutes.

That's definitely not the answer for the end users but 'pkmon'
command may at least tell you what it's downloading and what's
the progress.

Regards,

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

Re: Pondering security update time frames

[Florian Weimer]

On 10/31/2016 02:12 PM, Florian Weimer wrote:

On 10/31/2016 02:01 PM, Pavel Raiskup wrote:

On Monday, October 31, 2016 1:45:22 PM CET Florian Weimer wrote:

On 10/26/2016 02:45 PM, Pavel Raiskup wrote:

On Wednesday, October 26, 2016 1:33:34 PM CEST Florian Weimer wrote:

Debian does not build from SCM, but directly from maintainer-uploaded
source packages, so there is no need to have a private SCM.


Do we have a good marketing for the fact that we are that "superior"
compared to Debian then?  Sounds like a main thing for for distro
comparison
article:  It sounds like this is much, *much* more difficult to get
malicious
software into distribution (without noticing) for Fedora packager
than for
Debian packager, right?


You need people to actually look at stuff that's being uploaded.  I
don't think there is a key difference between Fedora and Debian as far
as this aspect is concerned.  D

In addition, Koji likely allows you to create tagged builds which came
from SRPMs, so I don't think there is an actually difference here in
terms of attack surface (at least not in Fedora's favor).


Do you mean that this is allowed by policy or that this is "implemented"?


I don't think Koji implements the necessary build provenience checks to
implement a different policy.


I'm wrong, Koji handles this.  Thanks to Kevin for point this out to me.

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

[Test-Announce] Fedora 25 switchable graphics Test Day this Thursday, 2016-11-03

[Adam Williamson]

Yep, it's Test Day time again - most likely the final Test Day of the
Fedora 25 cycle. This Thursday, 2016-11-03, will be [switchable
graphics Test Day][1]!

'Switchable graphics' refers to the fairly common current practice of
laptops having two graphics adapters, one low-power one for general
purpose use, one more powerful one for use with applications that
require more oomph (e.g. games or 3D rendering applications). NVIDIA
brands this as 'Optimus', and AMD just as 'Switchable Graphics' or
'Dynamic Switchable Graphics'.

There are some [enhancements][2] to Fedora's support for such systems
in Fedora 25, and part of the Test Day's purpose is to test those
enhancements. The other part of the Test Day's purpose is to ensure
that support for switchable graphics on Fedora 25 Workstation with
[Wayland by default][3] is as good as it can be, and that in some cases
where we know Wayland support is not sufficient, fallback to X.org
works as expected.

If you're not sure whether you have a system with switchable graphics,
you can run `xrandr --listproviders`. If the output from this command
lists more than one 'provider', you likely have switchable graphics. If
you do, please come along to the Test Day and help us test, if you can
spare the time. If you believe your system has switchable graphics, but
the command only lists one provider, please come join the Test Day chat
on the day - we may be able to investigate and figure out what's going
on!

The [Test Day page][1] and the test cases are still being revised and
tweaked as I write this, but as the week goes along, all the
instructions you need to run the tests will be present there. As
always, the event will be in #fedora-test-day on Freenode IRC. If you
don’t know how to use IRC, you can read [these instructions][4], or
just use [WebIRC][5].

 [1]: 
https://fedoraproject.org/wiki/Test_Day:2016-11-03_BetterSwitchableGraphicsSupport
 [2]: https://fedoraproject.org/wiki/Changes/BetterSwitchableGraphicsSupport
 [3]: https://fedoraproject.org/wiki/Changes/WaylandByDefault
 [4]: http://fedoraproject.org/wiki/How_to_use_IRC
 [5]: http://webchat.freenode.net/?channels=fedora-test-day
-- 
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: DNF and PackageKit background data usage

[Chris Murphy]

On Mon, Oct 31, 2016 at 3:35 PM, Chris Murphy  wrote:
> On Mon, Oct 31, 2016 at 5:02 AM, Michael Catanzaro  
> wrote:
>> On Sun, 2016-10-30 at 22:50 -0600, Chris Murphy wrote:
>>> Since offline updates are the default, and packagekit downloads
>>> everything currently needing updating, if the user doesn't ever do a
>>> Restart & Install to proceed with offline updates, i.e. they only
>>> ever
>>> use dnf for updates and never disable packagekit updates, I'm pretty
>>> sure the expected result is it just accumulates all of these
>>> unapplied
>>> updates.
>>
>> A 7 GB cache cannot be the expected result. PackageKit can only have
>> one update prepared at a time, so it should only cache one prepared
>> update at a time and should clear the cache before preparing the next
>> one. Otherwise it's just a cache leak.
>
> Then there must be a leak as I have multiple rpms with slightly
> different versions.
>
> https://paste.fedoraproject.org/466976/
>
> The other thing I'm seeing is, I'll get a notification for software
> updates, click on it, see the Restart & Install blue button in GNOME
> Software, close/quite GNOME Software, and at some later time relaunch
> GNOME Software and it says everything is up to date even though the
> offline update wasn't run. And if I refresh, it appears to be
> downloading a lot of data all over again - I just don't know what and
> have no good way to troubleshoot this, but the refresh is taking a
> long time, maybe 30 minutes.

After refreshing, and choosing Restart  & Install, I get an offline
update. Following reboot from that, all the RPMs that were in
/var/cache/PackageKit/25/metadata/updates-testing/packages before the
update are still in that path.

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

Re: DNF and PackageKit background data usage

[Chris Murphy]

On Mon, Oct 31, 2016 at 5:02 AM, Michael Catanzaro  wrote:
> On Sun, 2016-10-30 at 22:50 -0600, Chris Murphy wrote:
>> Since offline updates are the default, and packagekit downloads
>> everything currently needing updating, if the user doesn't ever do a
>> Restart & Install to proceed with offline updates, i.e. they only
>> ever
>> use dnf for updates and never disable packagekit updates, I'm pretty
>> sure the expected result is it just accumulates all of these
>> unapplied
>> updates.
>
> A 7 GB cache cannot be the expected result. PackageKit can only have
> one update prepared at a time, so it should only cache one prepared
> update at a time and should clear the cache before preparing the next
> one. Otherwise it's just a cache leak.

Then there must be a leak as I have multiple rpms with slightly
different versions.

https://paste.fedoraproject.org/466976/

The other thing I'm seeing is, I'll get a notification for software
updates, click on it, see the Restart & Install blue button in GNOME
Software, close/quite GNOME Software, and at some later time relaunch
GNOME Software and it says everything is up to date even though the
offline update wasn't run. And if I refresh, it appears to be
downloading a lot of data all over again - I just don't know what and
have no good way to troubleshoot this, but the refresh is taking a
long time, maybe 30 minutes.


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

Re: DNF and PackageKit background data usage

[Simo Sorce]

On Mon, 2016-10-31 at 11:54 -0500, Michael Catanzaro wrote:
> On Mon, 2016-10-31 at 18:15 +0200, Alexander Ploumistos wrote:
> > This is more of an issue for Workstation and the spins destined for
> > desktop use, so any possible solution needs to rely on
> > Anaconda/Initial Setup and each DE.
> 
> My $0.02 as a sometimes contributor to gnome-initial-setup: it already
> has too many options that can be changed post-installation. Users
> report confusion about how to answer the existing, very simple options
> (enable geolocation, enable automatic crash reporting). We don't want
> to add any more. Especially as this option needs to be network-
> specific. I do think we need a graphical option somewhere, but the
> right place is the Network system settings panel.

This is something that needs to be changed after install anyway, it
should be a setting that is available via network manager or similar as
it depends on the actual interface use.

I also experienced my smartphone tethered connection being clogged with
PkgKit trying to do updates, luckily for me T-Mobile has unlimited data
even on roaming ... or the bill could have been astronomical.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1387903] perl-Mojolicious-7.09 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Mojolicious-7.09-1.fc2
   ||6
 Resolution|--- |RAWHIDE
Last Closed||2016-10-31 16:11:40



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
http://koji.fedoraproject.org/koji/buildinfo?buildID=812047

-- 
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 1389744] perl-Hijk-0.27 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Hijk-0.27-1.fc26
 Resolution|--- |RAWHIDE
Last Closed||2016-10-31 16:09:45



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
http://koji.fedoraproject.org/koji/buildinfo?buildID=814080

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

eseyman pushed to perl-Hijk (master). "Update to 0.27"

[notifications]

From 1039e236293ec532db3dc3001f2c83229cf52a40 Mon Sep 17 00:00:00 2001
From: Emmanuel Seyman 
Date: Mon, 31 Oct 2016 20:26:12 +0100
Subject: Update to 0.27

---
 .gitignore | 1 +
 perl-Hijk.spec | 9 ++---
 sources| 2 +-
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/.gitignore b/.gitignore
index 37ccecc..56b3e6b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,3 +8,4 @@
 /Hijk-0.22.tar.gz
 /Hijk-0.24.tar.gz
 /Hijk-0.26.tar.gz
+/Hijk-0.27.tar.gz
diff --git a/perl-Hijk.spec b/perl-Hijk.spec
index 7d33a20..a85cd46 100644
--- a/perl-Hijk.spec
+++ b/perl-Hijk.spec
@@ -1,11 +1,11 @@
 Name:   perl-Hijk
-Version:0.26
-Release:3%{?dist}
+Version:0.27
+Release:1%{?dist}
 Summary:Specialized HTTP client
 License:MIT
 
 URL:http://search.cpan.org/dist/Hijk/
-Source0:http://www.cpan.org/authors/id/A/AV/AVAR/Hijk-%{version}.tar.gz
+Source0:
http://www.cpan.org/authors/id/G/GU/GUGOD/Hijk-%{version}.tar.gz
 
 BuildArch:  noarch
 BuildRequires:  coreutils
@@ -68,6 +68,9 @@ make test
 %{_mandir}/man3/Hijk*
 
 %changelog
+* Mon Oct 31 2016 Emmanuel Seyman  - 0.27-1
+- Update to 0.27
+
 * Sun May 15 2016 Jitka Plesnikova  - 0.26-3
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 18f3f6c..3d683bc 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-5c2c9e2f27c406e952c415decdadfd7e  Hijk-0.26.tar.gz
+050eb415849f8f6a9100522d82e24940  Hijk-0.27.tar.gz
-- 
cgit v0.12



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

eseyman uploaded Hijk-0.27.tar.gz for perl-Hijk

[notifications]

050eb415849f8f6a9100522d82e24940  Hijk-0.27.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Hijk/Hijk-0.27.tar.gz/md5/050eb415849f8f6a9100522d82e24940/Hijk-0.27.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: MongoDB in EPEL7

[Tom Boutell]

Oops, I've copied my reply to the EPEL list as requested.

On Mon, Oct 31, 2016 at 1:17 PM, Tom Boutell  wrote:
> There is no version 2.8 of Mongo, they renamed that to 3.0 before release of 
> 3.0.
>
> Just to provide a sense of the thought process other EPEL7 users might be 
> going through here:
>
> I started researching this when I became aware that 2.6 was nearing upstream 
> end-of-life (that is now happening today).
>
> I was aware of the recent major version upgrade of nodejs in EPEL7, so I 
> assumed something like that was imminent. However, when I looked here:
>
> http://koji.fedoraproject.org/koji/buildinfo?buildID=802214
>
> I saw that there have been several patches to EPEL6 MongoDB 2.4 since it 
> reached its upstream end-of-life in March.
>
> So based on that evidence of prior commitment to maintaining MongoDB past 
> end-of-life, I assumed that the intention was to keep on backporting patches 
> to both 2.4 and 2.6. And I cancelled my red alert and stopped worrying about 
> transitioning to the official MongoDB repositories.
>
> However it sounds like Marek, as the maintainer, is saying he doesn't have 
> time to maintain 2.4 or 2.6.
>
> That's fair of course. Free is a very good price, and all that. (:
>
> For EPEL7, the upgrade seems fairly straightforward. 3.0 was really a 
> marketing switch in the name of 2.8. I have experienced few problems moving 
> projects between 3.0 and 2.6. Swapping the binaries and restarting is 
> officially supported according to the documentation. The compatibility break 
> pages are pretty short and there isn't much that would be in typical queries.
>
> For EPEL6, the upgrade is harder because you must first bump them to 2.6 and 
> then to 3.0, there is no support for moving directly from 2.4 to 3.0. We 
> could push out 2.6, wait a few weeks, and push out 3.0, but this would have a 
> very unsatisfactory result for people who just don't happen to upgrade during 
> those few weeks. They would get moved directly from 2.4 to 3.0 and the 
> process would not work.
>
> There are also more bc breaks moving from 2.4, 2.6 and above are "pickier," 
> notably a $set with no properties in the object will fail. 
> https://docs.mongodb.com/v2.6/release-notes/2.6-compatibility/#driver-compatibility-changes
>
> In both cases, a proper announcement is necessary.
>
> A fair question is whether we should move to 3.0 or 3.2. The folks 
> maintaining nodejs for EPEL chose to move from 0.10 to 6.x, skipping 4.x, 
> because one bc break is better than two.
>
> So what I would suggest is this:
>
> FOR EPEL 6
>
> * Announce our intentions.
> * IN THE MEANTIME: If any really major security fails occur between now and 
> when we get this done, we grit our teeth and patch 2.4.
> * Publish a 3.0 package that refuses to install with an appropriate error 
> message if it sees 2.4 (but is fine with seeing 2.6).
> * Simultaneously publish 2.6-for-upgrading package; the instructions for 
> those with 2.4 point you to that package, and to this URL:
>
> https://docs.mongodb.com/v3.2/release-notes/2.6-upgrade/
>
> * Users must manually install the 2.6-for-upgrading package, since the 
> possible complexities of a 2.4 to 2.6 upgrade are beyond an automated 
> post-install script IMHO. Notably:
>
> https://docs.mongodb.com/v3.2/release-notes/2.6-upgrade/#upgrade-auth-prereq
>
> * Once a user succeeds in that process, they can "yum update" painlessly to 
> 3.0 like the EPEL7 people (see below).
>
> FOR EPEL 7
>
> * Announce our intentions. I don't know how much notice is thought 
> appropriate. The nodejs maintainers gave a lot of warning, but they also knew 
> what was up way before end of life (:
> * Prepare a package for 3.0. It's a forced upgrade from 2.6.
> * Release it. If possible, print this URL after install:
> https://docs.mongodb.com/v3.2/release-notes/3.0-compatibility/
> * Done (:
>
> Just my suggestion — I realize I just blew into town.
>
> Hope we can figure this out before the next CVE!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 


THOMAS BOUTELL, SUPPORT LEAD
P'UNK AVENUE | (215) 755-1330  |  punkave.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: MongoDB in EPEL7

[Tom Boutell]

There is no version 2.8 of Mongo, they renamed that to 3.0 before release of 
3.0.

Just to provide a sense of the thought process other EPEL7 users might be going 
through here:

I started researching this when I became aware that 2.6 was nearing upstream 
end-of-life (that is now happening today).

I was aware of the recent major version upgrade of nodejs in EPEL7, so I 
assumed something like that was imminent. However, when I looked here:

http://koji.fedoraproject.org/koji/buildinfo?buildID=802214

I saw that there have been several patches to EPEL6 MongoDB 2.4 since it 
reached its upstream end-of-life in March.

So based on that evidence of prior commitment to maintaining MongoDB past 
end-of-life, I assumed that the intention was to keep on backporting patches to 
both 2.4 and 2.6. And I cancelled my red alert and stopped worrying about 
transitioning to the official MongoDB repositories.

However it sounds like Marek, as the maintainer, is saying he doesn't have time 
to maintain 2.4 or 2.6. 

That's fair of course. Free is a very good price, and all that. (:

For EPEL7, the upgrade seems fairly straightforward. 3.0 was really a marketing 
switch in the name of 2.8. I have experienced few problems moving projects 
between 3.0 and 2.6. Swapping the binaries and restarting is officially 
supported according to the documentation. The compatibility break pages are 
pretty short and there isn't much that would be in typical queries.

For EPEL6, the upgrade is harder because you must first bump them to 2.6 and 
then to 3.0, there is no support for moving directly from 2.4 to 3.0. We could 
push out 2.6, wait a few weeks, and push out 3.0, but this would have a very 
unsatisfactory result for people who just don't happen to upgrade during those 
few weeks. They would get moved directly from 2.4 to 3.0 and the process would 
not work.

There are also more bc breaks moving from 2.4, 2.6 and above are "pickier," 
notably a $set with no properties in the object will fail. 
https://docs.mongodb.com/v2.6/release-notes/2.6-compatibility/#driver-compatibility-changes

In both cases, a proper announcement is necessary.

A fair question is whether we should move to 3.0 or 3.2. The folks maintaining 
nodejs for EPEL chose to move from 0.10 to 6.x, skipping 4.x, because one bc 
break is better than two.

So what I would suggest is this:

FOR EPEL 6

* Announce our intentions.
* IN THE MEANTIME: If any really major security fails occur between now and 
when we get this done, we grit our teeth and patch 2.4.
* Publish a 3.0 package that refuses to install with an appropriate error 
message if it sees 2.4 (but is fine with seeing 2.6).
* Simultaneously publish 2.6-for-upgrading package; the instructions for those 
with 2.4 point you to that package, and to this URL:

https://docs.mongodb.com/v3.2/release-notes/2.6-upgrade/

* Users must manually install the 2.6-for-upgrading package, since the possible 
complexities of a 2.4 to 2.6 upgrade are beyond an automated post-install 
script IMHO. Notably:

https://docs.mongodb.com/v3.2/release-notes/2.6-upgrade/#upgrade-auth-prereq

* Once a user succeeds in that process, they can "yum update" painlessly to 3.0 
like the EPEL7 people (see below).

FOR EPEL 7

* Announce our intentions. I don't know how much notice is thought appropriate. 
The nodejs maintainers gave a lot of warning, but they also knew what was up 
way before end of life (:
* Prepare a package for 3.0. It's a forced upgrade from 2.6.
* Release it. If possible, print this URL after install: 
https://docs.mongodb.com/v3.2/release-notes/3.0-compatibility/
* Done (:

Just my suggestion — I realize I just blew into town.

Hope we can figure this out before the next CVE!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: DNF and PackageKit background data usage

[Michael Catanzaro]

On Mon, 2016-10-31 at 18:15 +0200, Alexander Ploumistos wrote:
> This is more of an issue for Workstation and the spins destined for
> desktop use, so any possible solution needs to rely on
> Anaconda/Initial Setup and each DE.

My $0.02 as a sometimes contributor to gnome-initial-setup: it already
has too many options that can be changed post-installation. Users
report confusion about how to answer the existing, very simple options
(enable geolocation, enable automatic crash reporting). We don't want
to add any more. Especially as this option needs to be network-
specific. I do think we need a graphical option somewhere, but the
right place is the Network system settings panel.

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

Re: MongoDB in EPEL7

[Marek Skalický]

Hi,
thanks for answers and suggestion that epel-de...@lists.fp.o would be better - 
so I've posted it there 
https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org/thread/TQPBQ25T6F323WYOGNOB6XYMEZDCSFEK/

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

[EPEL-devel] MongoDB in EPEL7

[Marek Skalický]

Hi,
current situation:
EPEL6 - MongoDB 2.4.x
EPEL7 - MongoDB 2.6.x

Upstream supports only upgrade to next major version. So from 2.4 it is 
supported only to 2.6.
Therefore I kept MongoDB 2.6 in EPEL7 (even two next major versions are 
released).

But MongoDB 2.6 is going to EOL (probably this week), so MongoDB in EPEL7 will 
be unsupported.

How to solve this - what EPEL/Fedora guidelines says about upgrades? Upgrade 
EPEL6 to EPEL7? Or keep unsupported version in EPEL7? 

I've post same question to de...@lists.fp.o [1] - there I was noticed that 
epel-devel would be better.

Upstream says that there might be some minor incompatibilities between major 
releases and it suggests users to check and fix these incompatibilities before 
upgrade. So these upgrade might break some users instances.

I like answer of Peter Robinson [2] - upgrade to next major version. Left some 
time for users to upgrade to this new version and after that prepare major 
upgrade again.
Does this comply to guidelines? (If I send some announcement to this listbefore)

Thanks,
Marek

[1] 
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/4LX7UAETNOAACF6AEU5DNQDRX3B3TFLU/
[2] 
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/IYEFYGXINNC76TOBIGOXC6MAWRDZKXCD/
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: DNF and PackageKit background data usage

[Adam Williamson]

On Mon, 2016-10-31 at 12:25 -0400, Bastien Nocera wrote:

> Otherwise your description doesn't seem to square with the fact that
> > most everyone sees background update downloads OOTB.
> > 
> > Even still, in fact, kparal mentioned them happening on hotel wifi, so
> > why would that be the case if the default is 'metered'?
> 
> Looks like I switched metered and unmetered around in my description ;)
> 
> They're unmetered unless you either tag them as metered, or something
> (like a DHCP server) tells NM they're metered.
> 
> Sorry about that.

Ah, indeed, that lines up better with the observed data =) Still, it's
interesting that the DHCP metered indication thing doesn't seem to be
working, per my recall and kparal's nmcli output?
-- 
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: Bodhi For Rawhide?

[Matthew Miller]

On Mon, Oct 31, 2016 at 04:19:54PM +, Petr Pisar wrote:
> > Yeah, so I guess "all" is the wrong word. It'd be nice to be able to
> > review and override specific rpmlint errors on a per-package bases (and
> > maybe a process to review those overrides to prevent abuse when there's
> > a real problem).
> Already implemented. You can supress test failures by a python code in
> a .rpmlint file in package's dist-git repository.

I can? Where is this documented? Can we add a link to that
documentation to the output from Taskotron in Bodhi?

-- 
Matthew Miller

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

Re: Pondering security update time frames

[Kevin Fenzi]

On Mon, 31 Oct 2016 14:12:24 +0100
Florian Weimer  wrote:

> On 10/31/2016 02:01 PM, Pavel Raiskup wrote:
> > On Monday, October 31, 2016 1:45:22 PM CET Florian Weimer wrote:  
> >> On 10/26/2016 02:45 PM, Pavel Raiskup wrote:  
> >>> On Wednesday, October 26, 2016 1:33:34 PM CEST Florian Weimer
> >>> wrote:  
>  Debian does not build from SCM, but directly from
>  maintainer-uploaded source packages, so there is no need to have
>  a private SCM.  
> >>>
> >>> Do we have a good marketing for the fact that we are that
> >>> "superior" compared to Debian then?  Sounds like a main thing for
> >>> for distro comparison article:  It sounds like this is much,
> >>> *much* more difficult to get malicious software into distribution
> >>> (without noticing) for Fedora packager than for Debian packager,
> >>> right?  
> >>
> >> You need people to actually look at stuff that's being uploaded.  I
> >> don't think there is a key difference between Fedora and Debian as
> >> far as this aspect is concerned.  D
> >>
> >> In addition, Koji likely allows you to create tagged builds which
> >> came from SRPMs, so I don't think there is an actually difference
> >> here in terms of attack surface (at least not in Fedora's favor).  
> >
> > Do you mean that this is allowed by policy or that this is
> > "implemented"?  
> 
> I don't think Koji implements the necessary build provenience checks
> to implement a different policy.

koji only allows src.rpms to be used for scratch builds or if you have
the koji admin permission. Otherwise you must build all official builds
from our packages git with a known hash.  

So, no, regular packagers cannot tag src.rpm builds into anything. 

kevin




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

Re: DNF and PackageKit background data usage

[Matthew Miller]

On Mon, Oct 31, 2016 at 09:23:06AM -0700, Adam Williamson wrote:
> For that matter, I'm fairly sure I've seen background update
> downloading happen when I was using an Android wifi tether
> connection. I'm pretty sure I remember it blowing my data cap one
> month when I was using my laptop on the bus.

As far as I can see, the default is "unknown". You can set
"CONNECTION_METERED=yes" in the
/etc/sysconfig/network-scripts/ifcfg-[whatever] file to change it on a
per-device basis.

The man page for NetworkManager.conf doesn't document this as one of
the properties which can have its default overridden (and says that
anything not documented can't be overridden). I took that at its word;
possibly worth testing anyway. :)

-- 
Matthew Miller

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

Re: DNF and PackageKit background data usage

[Bastien Nocera]

No, there's no UI:
https://bugzilla.gnome.org/show_bug.cgi?id=745747

- Original Message -
> On Mon, 2016-10-31 at 15:09 +, Richard Hughes wrote:
> > 
> > I think this kind of issue is really fixed the hard way, i.e. fixing
> > bugs and adding unimplemented features rather than just adding complex
> > UI workarounds.
> 
> I think making it work as best as possible without interaction is
> great, but I'd argue that fundamentally this needs interaction. At a
> bare minimum the UI for users to mark connections as metered or
> unmetered needs to be there. Is there actually UI for this already? I
> could not find it.
> 
> The question of what the default state should be is an interesting one,
> and I bet your take on it differs substantially depending on your level
> of 'internet connection privilege'. ;)
> --
> 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
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: DNF and PackageKit background data usage

[Bastien Nocera]

- Original Message -
> On Mon, 2016-10-31 at 08:18 -0400, Bastien Nocera wrote:
> 
> > > How does a connection become "unmetered"? It can't just be on interface
> > > type,
> > > as I have metered connections on all interface types, so presumably you
> > > use
> > > some form of web service to distinguish "metered" from "unmetered" based
> > > on
> > > a list of known IP blocks?
> > > 
> > > Or do you simply assume that all connections are metered until the user
> > > says
> > > otherwise?
> > 
> > They're metered unless you either tag them as unmetered, or hints are
> > provided
> > to NetworkManager by what you're connected to. For example, Android
> > tethering
> > is automatically tagged as metered as Android provides a hint in its DHCP
> > configuration.
> 
> Does NetworkManager 'hint' that wired connections are unmetered?

It doesn't say "definitely metered" or "definitely unmetered". We usually take
that to mean it's unmetered.

> Otherwise your description doesn't seem to square with the fact that
> most everyone sees background update downloads OOTB.
> 
> Even still, in fact, kparal mentioned them happening on hotel wifi, so
> why would that be the case if the default is 'metered'?

Looks like I switched metered and unmetered around in my description ;)

They're unmetered unless you either tag them as metered, or something
(like a DHCP server) tells NM they're metered.

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

Re: DNF and PackageKit background data usage

[Adam Williamson]

On Mon, 2016-10-31 at 08:18 -0400, Bastien Nocera wrote:

> > How does a connection become "unmetered"? It can't just be on interface 
> > type,
> > as I have metered connections on all interface types, so presumably you use
> > some form of web service to distinguish "metered" from "unmetered" based on
> > a list of known IP blocks?
> > 
> > Or do you simply assume that all connections are metered until the user says
> > otherwise?
> 
> They're metered unless you either tag them as unmetered, or hints are provided
> to NetworkManager by what you're connected to. For example, Android tethering
> is automatically tagged as metered as Android provides a hint in its DHCP
> configuration.

Does NetworkManager 'hint' that wired connections are unmetered?
Otherwise your description doesn't seem to square with the fact that
most everyone sees background update downloads OOTB.

Even still, in fact, kparal mentioned them happening on hotel wifi, so
why would that be the case if the default is 'metered'?
-- 
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: DNF and PackageKit background data usage

[Matthew Miller]

On Mon, Oct 31, 2016 at 09:06:50AM -0700, Adam Williamson wrote:
> One of the bugs has a note I was not aware of before: there's
> actually a DHCP value that can be sent by the server to denote a
> metered connection. If that's actually widely respected, and set by
> phone wifi AP applications and the like, it could be pretty accurate.
> Not perfect, but better than heuristics. I've no idea how widely it's
> used in the real world, though.

For what it's worth, with wifi hotspot on my Nexus 6P running latest
Android N:

$ nmcli -f connection.metered connection show myhotspotssid
connection.metered: unknown


-- 
Matthew Miller

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

Re: DNF and PackageKit background data usage

[Adam Williamson]

On Mon, 2016-10-31 at 09:13 -0700, Adam Williamson wrote:
> On Mon, 2016-10-31 at 08:18 -0400, Bastien Nocera wrote:
> 
> > > How does a connection become "unmetered"? It can't just be on interface 
> > > type,
> > > as I have metered connections on all interface types, so presumably you 
> > > use
> > > some form of web service to distinguish "metered" from "unmetered" based 
> > > on
> > > a list of known IP blocks?
> > > 
> > > Or do you simply assume that all connections are metered until the user 
> > > says
> > > otherwise?
> > 
> > They're metered unless you either tag them as unmetered, or hints are 
> > provided
> > to NetworkManager by what you're connected to. For example, Android 
> > tethering
> > is automatically tagged as metered as Android provides a hint in its DHCP
> > configuration.
> 
> Does NetworkManager 'hint' that wired connections are unmetered?
> Otherwise your description doesn't seem to square with the fact that
> most everyone sees background update downloads OOTB.
> 
> Even still, in fact, kparal mentioned them happening on hotel wifi, so
> why would that be the case if the default is 'metered'?

For that matter, I'm fairly sure I've seen background update
downloading happen when I was using an Android wifi tether connection.
I'm pretty sure I remember it blowing my data cap one month when I was
using my laptop on the bus.
-- 
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: Bodhi For Rawhide?

[Petr Pisar]

On 2016-10-27, Matthew Miller  wrote:
> Yeah, so I guess "all" is the wrong word. It'd be nice to be able to
> review and override specific rpmlint errors on a per-package bases (and
> maybe a process to review those overrides to prevent abuse when there's
> a real problem).

Already implemented. You can supress test failures by a python code in
a .rpmlint file in package's dist-git repository.

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

Re: DNF and PackageKit background data usage

[Adam Williamson]

On Mon, 2016-10-31 at 15:09 +, Richard Hughes wrote:
> 
> I think this kind of issue is really fixed the hard way, i.e. fixing
> bugs and adding unimplemented features rather than just adding complex
> UI workarounds.

I think making it work as best as possible without interaction is
great, but I'd argue that fundamentally this needs interaction. At a
bare minimum the UI for users to mark connections as metered or
unmetered needs to be there. Is there actually UI for this already? I
could not find it.

The question of what the default state should be is an interesting one,
and I bet your take on it differs substantially depending on your level
of 'internet connection privilege'. ;)
-- 
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: DNF and PackageKit background data usage

[Alexander Ploumistos]

Hello,

I'm not sure I have all my facts straight -and by all means, please
help straighten them out-, but I would like to address Adam's original
proposals.

This is more of an issue for Workstation and the spins destined for
desktop use, so any possible solution needs to rely on
Anaconda/Initial Setup and each DE. In essence, we need a script that
runs with elevated privileges and disables/enables the makecache timer
and Packagit. This could then be wrapped in zenity or whatever similar
works in every DE. I think this would work regardless of
NetworkManager's presence, metered connection detection etc..

Would it be unfeasible to craft an Initial Setup add-on that runs
after the EULA screen, displays a notification explaining background
data usage and allows the user to turn it off (temporarily)? Since
having updates turned off indefinitely is a Bad Thing™, this add-on
could spawn a systemd service that checks if the makecache timer and
PackageKit have been disabled and if so, throw a nag screen (which
could be disabled, but not too easily ;) ) every n minutes/hours/days.
After the first run, every DE could have each own (control) panel
item/button/widget to enable toggling automatic updates on and off.

All of the above would require a) the Initial Setup add-on, b) a
systemd service and/or timer and c) a DE-specific package to alter the
state of things, which would have to be among the default packages in
each DE group. Having looked at the code of yumex, it doesn't look
that difficult to adapt the toggle to work with any underlying package
management system, at least the mainstream ones. Perhaps each DE could
enhance it even further, e.g. GNOME could integrate
gnome-online-accounts, so users could selectively disable specific
sync activities or any background data-consuming jobs altogether.

And now that I re-read what I have written, is this work that can be
done in Fedora or would we have to work with upstream from the get-go?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Koji payload hash?

[Christopher]

On Mon, Oct 31, 2016 at 12:01 PM Panu Matilainen 
wrote:

> On 10/31/2016 05:17 PM, Florian Weimer wrote:
> > On 10/21/2016 05:34 PM, Kevin Fenzi wrote:
> >> On Thu, 20 Oct 2016 16:42:02 +
> >> Christopher  wrote:
> >>
> >>> What is the "Payload Hash" in koji?
> >>> It looks like an MD5, but of what? It's not the rpm... I've checked.
> >>> Should koji be providing verification hashes for manual downloads of
> >>> built RPMs? I think this would be useful for testing.
> >>>
> >>> http://koji.fedoraproject.org/koji/rpminfo?rpmID=8351409
> >>
> >> I'm not sure either. I think it's the internal payload before adding
> >> the signatures, etc?
> >
> > It's the RPM_SIGTAG_MD5 RPM header:
> >
> >   SIGNATURE:SIGTAG_HEADERSIGNATURES (BIN):
> > 003e0007ffa00010
> >   SIGNATURE:SIGTAG_SHA1HEADER (STRING):
> > "bbc33a4f6670d31817cd571de632f3190a72e1bf"
> >   SIGNATURE:SIGTAG_SIZE (INT32): 103674
> >   SIGNATURE:SIGTAG_MD5 (BIN):
> > cdf775308f76e659385444b50ee26a7a
> >   SIGNATURE:SIGTAG_PAYLOADSIZE (INT32): 396760
> >
> > I'm not completely sure over which part of the RPM it is computed.  I
> > suspect over the non-signature header followed by the decompressed
> payload.
>
> All RPM v3 digests (so yes, RPM_SIGTAG_MD5) and signatures are on the
> (non-signature) header + compressed payload. Only the individual file
> digests are on uncompressed data.
>
> - Panu -
>
>

Thanks. This was explained on https://pagure.io/koji/issue/190 with
instructions on how to verify.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reviews Weekly

[nobody]

Start Date: 2016-10-24 10:08:01.487323
End Date: 2016-10-31 10:08:01.487323

Jitka Plesnikova : 4

https://bugzilla.redhat.com/show_bug.cgi?id=1387634 
perl-Devel-Gladiator
https://bugzilla.redhat.com/show_bug.cgi?id=1387626 perl-Term-Chrome
https://bugzilla.redhat.com/show_bug.cgi?id=1387604 
perl-Filter-Encoding
https://bugzilla.redhat.com/show_bug.cgi?id=1387619 perl-Test-Is


Zbigniew Jędrzejewski-Szmek : 4

https://bugzilla.redhat.com/show_bug.cgi?id=1389955 
gnome-shell-extension-no-top-left-hot-corner
https://bugzilla.redhat.com/show_bug.cgi?id=1384729 
python3-decorator
https://bugzilla.redhat.com/show_bug.cgi?id=1383725 
python-restructuredtext-lint
https://bugzilla.redhat.com/show_bug.cgi?id=1384133 python3-suds


Antonio Trande : 2

https://bugzilla.redhat.com/show_bug.cgi?id=1387835 python-binstruct
https://bugzilla.redhat.com/show_bug.cgi?id=1387836 python-bitstruct


Petr Pisar : 2

https://bugzilla.redhat.com/show_bug.cgi?id=1382926 
perl-HTTP-MultiPartParser
https://bugzilla.redhat.com/show_bug.cgi?id=1382922 
perl-WWW-Form-UrlEncoded


Randy Barlow : 2

https://bugzilla.redhat.com/show_bug.cgi?id=1387291 
python-lazr-delegates
https://bugzilla.redhat.com/show_bug.cgi?id=1374137 
ghc-enclosed-exceptions


Ankur Sinha (FranciscoD) : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1375222 
python-django-jsonfield


Christian Dersch : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1387834 python-evic


Dave Love : 1

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


Matthew Garrett : 1

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


Michael Simacek : 1

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


Miroslav Suchý : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1381661 obs-build


Neal Gompa : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1389784 python-scour


Patrick Uiterwijk : 1

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



Completed Review Requests: 22
This report was generated by bz-review-report.py.
The original source is available at: 
https://git.fedorahosted.org/cgit/triage.git/tree/scripts/bzReviewReport.py
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[POC-change] Fedora packages point of contact updates

[nobody]

Change in package status over the last 168 hours


2 packages were orphaned

rodent [master] was orphaned by sagitter
 Advanced user file manager for Linux/BSD systems
 https://admin.fedoraproject.org/pkgdb/package/rodent
tktable [master] was orphaned by sagitter
 Table/matrix widget extension to Tcl/Tk
 https://admin.fedoraproject.org/pkgdb/package/tktable

2 packages were retired

python-typing [master, f25] was retired by chandankumar
 Type Hints for Python
 https://admin.fedoraproject.org/pkgdb/package/python-typing
xorg-x11-drv-vmmouse [f25] was retired by jwrdegoede
 Xorg X11 vmmouse input driver
 https://admin.fedoraproject.org/pkgdb/package/xorg-x11-drv-vmmouse

3 packages unorphaned
-
ec2-metadata [f23, master, f25, f24] was unorphaned by manpaz
 EC2 instance metadata query tool
 https://admin.fedoraproject.org/pkgdb/package/ec2-metadata
psad [master, f25] was unorphaned by limb
 Port Scan Attack Detector (psad) watches for suspect traffic
 https://admin.fedoraproject.org/pkgdb/package/psad
rawtherapee [f23, master, f25, f24] was unorphaned by mattia
 Raw image processing software
 https://admin.fedoraproject.org/pkgdb/package/rawtherapee

0 packages were unretired


6 packages were given

discount [f23, master, f25, f24] was given by cbb to greghellings
 A command-line utility for converting Markdown files into HTML
 https://admin.fedoraproject.org/pkgdb/package/discount
hoard [f23, master, el6, f25, f24] was given by rhl to rjones
 A fast, scalable, and memory-efficient allocator
 https://admin.fedoraproject.org/pkgdb/package/hoard
kexec-tools [f23, master, f25, f24] was given by baoquan to yangrr
 The kexec/kdump userspace component
 https://admin.fedoraproject.org/pkgdb/package/kexec-tools
mailman [master] was given by jkaluza to pavlix
 Mailing list manager with built in Web access
 https://admin.fedoraproject.org/pkgdb/package/mailman
system-storage-manager [f23, master, f25, f24] was given by lczerner to jtulak
 A single tool to manage your storage
 https://admin.fedoraproject.org/pkgdb/package/system-storage-manager
tcpdump [f23, master, f25, f24] was given by mruprich to msehnout
 A network traffic monitoring tool
 https://admin.fedoraproject.org/pkgdb/package/tcpdump

0 packages had new branches



Sources: https://github.com/pypingou/fedora-owner-change
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: DNF and PackageKit background data usage

[Adam Williamson]

On Mon, 2016-10-31 at 11:55 +, Tom Hughes wrote:
> On 31/10/16 11:41, Richard Hughes wrote:
> > On 30 October 2016 at 01:26, Adam Williamson  
> > wrote:
> > > 1) Both dnf and GNOME Software / PackageKit default to performing
> > > fairly data-hungry transactions in the background, out of the box,
> > > without telling you about it. GNOME's is particularly bad, as it will
> > > happily download available updates in the background, which can be
> > > gigabytes worth of data.
> > 
> > If you're on an "unmetered" connection type...
> 
> The problem, as I believe has been repeatedly explained, is that you 
> don't really have any idea whether the connection is metered. Yes you 
> may be trying to guess by considering things like 3G connections as 
> metered but that is an extremely poor proxy for whether a connection is 
> metered.
> 
> It's not something that can be tied to connection types anyway. A wifi 
> interface might be unmetered if I'm at home but metered if I'm in a cafe 
> or hotel. An ethernet interface might be metered at certain times of day 
> and not at others.
> 
> The idea that you can programatically determine, using a simple 
> heuristic, if a connection will be metered is just nonsense.

One of the bugs has a note I was not aware of before: there's actually
a DHCP value that can be sent by the server to denote a metered
connection. If that's actually widely respected, and set by phone wifi
AP applications and the like, it could be pretty accurate. Not perfect,
but better than heuristics. I've no idea how widely it's used in the
real world, though.
-- 
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: Koji payload hash?

[Panu Matilainen]

On 10/31/2016 05:17 PM, Florian Weimer wrote:

On 10/21/2016 05:34 PM, Kevin Fenzi wrote:

On Thu, 20 Oct 2016 16:42:02 +
Christopher  wrote:


What is the "Payload Hash" in koji?
It looks like an MD5, but of what? It's not the rpm... I've checked.
Should koji be providing verification hashes for manual downloads of
built RPMs? I think this would be useful for testing.

http://koji.fedoraproject.org/koji/rpminfo?rpmID=8351409


I'm not sure either. I think it's the internal payload before adding
the signatures, etc?


It's the RPM_SIGTAG_MD5 RPM header:

  SIGNATURE:SIGTAG_HEADERSIGNATURES (BIN):
003e0007ffa00010
  SIGNATURE:SIGTAG_SHA1HEADER (STRING):
"bbc33a4f6670d31817cd571de632f3190a72e1bf"
  SIGNATURE:SIGTAG_SIZE (INT32): 103674
  SIGNATURE:SIGTAG_MD5 (BIN):
cdf775308f76e659385444b50ee26a7a
  SIGNATURE:SIGTAG_PAYLOADSIZE (INT32): 396760

I'm not completely sure over which part of the RPM it is computed.  I
suspect over the non-signature header followed by the decompressed payload.


All RPM v3 digests (so yes, RPM_SIGTAG_MD5) and signatures are on the 
(non-signature) header + compressed payload. Only the individual file 
digests are on uncompressed data.


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

Re: Pondering security update time frames

[Kevin Fenzi]

On Wed, 26 Oct 2016 12:23:58 +0200
Pavel Raiskup  wrote:

> On Tuesday, October 25, 2016 7:37:32 PM CEST Kevin Fenzi wrote:
> > > 3. AFAIK Fedora has no means by which it can participate in
> > > embargoed updates.  For this to work, I think there ought to be
> > > private git branches, a way to get Koji to make a private build
> > > from a private git branch, and a way to get private karma on a
> > > private update.  Then, when an embargo is lifted, the packager
> > > could merge the private branch in, the various infrastructure
> > > bits could notice that the very same git commit is now public and
> > > permit all of the private builds, updates, and karma to become
> > > public and allow an immediate push to updates.  
> > 
> > Yep. Thats a gigantic pile of work there for sure.  
> 
> That's too vague statement, really.  Can you make a better
> estimation?  As far as I understand, there are processes in Debian
> which allow them preparing CVE builds so they are able to provide
> "testing" builds to users immediately after the public announcement.

Well, I don't think I would be the one to provide an estimate, it would
be the authors of all the tools we use that are affected. 

> Seems like we need to:
> 
>   [x] have another git repository, say prepared-rpms/PACKAGE
>   - that's clone of rpms/PACKAGE
>   - permission bits inherited from rpms/PACKAGE, but not publicly
> available for cloning, + security guys
> 
>   [x] Making sure that only one repo is writeable:
>   - if prepared-rpms/PKG exists, rpms/PKG is read only
>   - the info "why" it is read-only shouldn't be public information
> 
>   [x] Support for "private" builds in koji. Maintainer should be able
> to re-tag security/prepared build into public tag once thing is
> publicly announced.
> 
>   [x] Nothing changes in bodhi, if we consder 'testing' to be enough
> for security purpose.  But yeah, there could be 'testing-security'
> optionally available for users...
> 
> Note that this is not security-only.  That's the reason for
> 'prepared-rpms' prefix, e.g. if we had something like that in Fedora,
> we could test/use this feature several times a year as we are
> informed by PostgreSQL upstream about upcoming releases, we have
> tarball in advance ...  but now it is shame we are not able to
> announce updates immediately with upstream.  We are not allowed to
> share the tarballs with upstream before announcement, of course.

So whats the lag here there? they announce and it's an hour or two
until you have finished builds and submitted updates? Is an hour or two
really worth all this... complexity?

kevin



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

ppisar pushed to perl-Module-Install-DOAP (master). "Import"

[notifications]

ppisar pushed to perl-Module-Install-DOAP (master).  "Import"

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

ppisar changed jplesnik's 'approveacls' permission on perl-Module-Install-DOAP (master) to 'Approved'

[notifications]

ppisar changed jplesnik's 'approveacls' permission on perl-Module-Install-DOAP 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Module-Install-DOAP/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed perl-sig's 'watchcommits' permission on perl-Module-Install-DOAP (master) to 'Approved'

[notifications]

ppisar changed perl-sig's 'watchcommits' permission on perl-Module-Install-DOAP 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Module-Install-DOAP/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed perl-sig's 'watchbugzilla' permission on perl-Module-Install-DOAP (master) to 'Approved'

[notifications]

ppisar changed perl-sig's 'watchbugzilla' permission on 
perl-Module-Install-DOAP (master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Module-Install-DOAP/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed jplesnik's 'commit' permission on perl-Module-Install-DOAP (master) to 'Approved'

[notifications]

ppisar changed jplesnik's 'commit' permission on perl-Module-Install-DOAP 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Module-Install-DOAP/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1390285] New: Upgrade perl-Term-ANSIColor to 4.06

[bugzilla]

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

Bug ID: 1390285
   Summary: Upgrade perl-Term-ANSIColor to 4.06
   Product: Fedora
   Version: rawhide
 Component: perl-Term-ANSIColor
  Keywords: FutureFeature
  Assignee: dd...@cpan.org
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: dd...@cpan.org, perl-devel@lists.fedoraproject.org



Latest Fedora delivers 4.05 version. Upstream released 4.06. When you have free
time, please upgrade it.

Also please consider enabling release monitoring
 to
receive update notifications automatically.

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

limb changed jplesnik's package request for perl-Parallel-Pipes in master from Awaiting Review to Approved

[notifications]

limb changed jplesnik's package request for perl-Parallel-Pipes in master from 
Awaiting Review to Approved
https://admin.fedoraproject.org/pkgdb/package/perl-Parallel-Pipes/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed perl-sig's 'watchcommits' permission on perl-Parallel-Pipes (master) to 'Approved'

[notifications]

limb changed perl-sig's 'watchcommits' permission on perl-Parallel-Pipes 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Parallel-Pipes/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed perl-sig's 'watchbugzilla' permission on perl-Parallel-Pipes (master) to 'Approved'

[notifications]

limb changed perl-sig's 'watchbugzilla' permission on perl-Parallel-Pipes 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Parallel-Pipes/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed perl-sig's 'commit' permission on perl-Parallel-Pipes (master) to 'Approved'

[notifications]

limb changed perl-sig's 'commit' permission on perl-Parallel-Pipes (master) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Parallel-Pipes/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed ppisar's 'watchcommits' permission on perl-Parallel-Pipes (master) to 'Approved'

[notifications]

limb changed ppisar's 'watchcommits' permission on perl-Parallel-Pipes (master) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Parallel-Pipes/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed ppisar's 'commit' permission on perl-Parallel-Pipes (master) to 'Approved'

[notifications]

limb changed ppisar's 'commit' permission on perl-Parallel-Pipes (master) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Parallel-Pipes/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed jplesnik's 'approveacls' permission on perl-Parallel-Pipes (master) to 'Approved'

[notifications]

limb changed jplesnik's 'approveacls' permission on perl-Parallel-Pipes 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Parallel-Pipes/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed ppisar's 'watchbugzilla' permission on perl-Parallel-Pipes (master) to 'Approved'

[notifications]

limb changed ppisar's 'watchbugzilla' permission on perl-Parallel-Pipes 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Parallel-Pipes/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1390185] perl-XML-XPath-1.38 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-XML-XPath-1.38-1.fc25 has been submitted as an update to Fedora 25.
https://bodhi.fedoraproject.org/updates/FEDORA-2016-fea9c2fea5

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

Fedora Rawhide-20161031.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 6/101 (x86_64), 3/17 (i386), 1/2 (arm)

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

ID: 45159   Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/45159

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

ID: 45160   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/45160
ID: 45173   Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/45173
ID: 45207   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/45207
ID: 45221   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/45221
ID: 45224   Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/45224
ID: 45226   Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/45226
ID: 45229   Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/45229
ID: 45247   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/45247
ID: 45248   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/45248

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

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

ID: 45228   Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/45228

Skipped openQA tests: 1 of 120
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1390185] perl-XML-XPath-1.38 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-XML-XPath-1.38-1.fc26



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

jplesnik pushed to perl-XML-XPath (f25). "1.38 bump"

[notifications]

From 50257ac1fc5d87dc79ad5ebf50a4c595c436b7c0 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Mon, 31 Oct 2016 16:18:57 +0100
Subject: 1.38 bump

---
 .gitignore  | 1 +
 perl-XML-XPath.spec | 5 -
 sources | 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 2d8f719..9dd4674 100644
--- a/.gitignore
+++ b/.gitignore
@@ -16,3 +16,4 @@ XML-XPath-1.13.tar.gz
 /XML-XPath-1.35.tar.gz
 /XML-XPath-1.36.tar.gz
 /XML-XPath-1.37.tar.gz
+/XML-XPath-1.38.tar.gz
diff --git a/perl-XML-XPath.spec b/perl-XML-XPath.spec
index 6efa672..a986386 100644
--- a/perl-XML-XPath.spec
+++ b/perl-XML-XPath.spec
@@ -1,5 +1,5 @@
 Name:   perl-XML-XPath
-Version:1.37
+Version:1.38
 Release:1%{?dist}
 Summary:XPath parser and evaluator for Perl
 # XML/XPath.pm, XML/XPath/PerlSAX.pm, REAME: GPL+ or Artistic
@@ -76,6 +76,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Mon Oct 31 2016 Jitka Plesnikova  - 1.38-1
+- 1.38 bump
+
 * Thu Jun 02 2016 Jitka Plesnikova  - 1.37-1
 - 1.37 bump
 
diff --git a/sources b/sources
index 16c9330..4d0cfe4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-72103d045298f8d7fb945d8b1ae31313  XML-XPath-1.37.tar.gz
+5f326479eebddfb4f95db89862783bc4  XML-XPath-1.38.tar.gz
-- 
cgit v0.12



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

jplesnik pushed to perl-XML-XPath (master). "1.38 bump"

[notifications]

From a7e9b25a17c2368dcfbe30a0cabcfc13c2256bc4 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Mon, 31 Oct 2016 16:18:57 +0100
Subject: 1.38 bump

---
 .gitignore  | 1 +
 perl-XML-XPath.spec | 5 -
 sources | 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 2d8f719..9dd4674 100644
--- a/.gitignore
+++ b/.gitignore
@@ -16,3 +16,4 @@ XML-XPath-1.13.tar.gz
 /XML-XPath-1.35.tar.gz
 /XML-XPath-1.36.tar.gz
 /XML-XPath-1.37.tar.gz
+/XML-XPath-1.38.tar.gz
diff --git a/perl-XML-XPath.spec b/perl-XML-XPath.spec
index 6efa672..a986386 100644
--- a/perl-XML-XPath.spec
+++ b/perl-XML-XPath.spec
@@ -1,5 +1,5 @@
 Name:   perl-XML-XPath
-Version:1.37
+Version:1.38
 Release:1%{?dist}
 Summary:XPath parser and evaluator for Perl
 # XML/XPath.pm, XML/XPath/PerlSAX.pm, REAME: GPL+ or Artistic
@@ -76,6 +76,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Mon Oct 31 2016 Jitka Plesnikova  - 1.38-1
+- 1.38 bump
+
 * Thu Jun 02 2016 Jitka Plesnikova  - 1.37-1
 - 1.37 bump
 
diff --git a/sources b/sources
index 16c9330..4d0cfe4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-72103d045298f8d7fb945d8b1ae31313  XML-XPath-1.37.tar.gz
+5f326479eebddfb4f95db89862783bc4  XML-XPath-1.38.tar.gz
-- 
cgit v0.12



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

jplesnik uploaded XML-XPath-1.38.tar.gz for perl-XML-XPath

[notifications]

5f326479eebddfb4f95db89862783bc4  XML-XPath-1.38.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-XML-XPath/XML-XPath-1.38.tar.gz/md5/5f326479eebddfb4f95db89862783bc4/XML-XPath-1.38.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Koji payload hash?

[Florian Weimer]

On 10/21/2016 05:34 PM, Kevin Fenzi wrote:

On Thu, 20 Oct 2016 16:42:02 +
Christopher  wrote:


What is the "Payload Hash" in koji?
It looks like an MD5, but of what? It's not the rpm... I've checked.
Should koji be providing verification hashes for manual downloads of
built RPMs? I think this would be useful for testing.

http://koji.fedoraproject.org/koji/rpminfo?rpmID=8351409


I'm not sure either. I think it's the internal payload before adding
the signatures, etc?


It's the RPM_SIGTAG_MD5 RPM header:

  SIGNATURE:SIGTAG_HEADERSIGNATURES (BIN):
003e0007ffa00010
  SIGNATURE:SIGTAG_SHA1HEADER (STRING): 
"bbc33a4f6670d31817cd571de632f3190a72e1bf"

  SIGNATURE:SIGTAG_SIZE (INT32): 103674
  SIGNATURE:SIGTAG_MD5 (BIN):
cdf775308f76e659385444b50ee26a7a
  SIGNATURE:SIGTAG_PAYLOADSIZE (INT32): 396760

I'm not completely sure over which part of the RPM it is computed.  I 
suspect over the non-signature header followed by the decompressed payload.


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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 602  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 364  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
  83  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-23fa04bf1c   
redis-3.2.3-1.el7
  67  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e8f4ff76b3   
chicken-4.11.0-3.el7
  22  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-c3527eff6c   
libass-0.13.4-1.el7
   9  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-14.el7 libyui-bindings-1.1.0-7.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
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-ee3cc4d1b6   
compat-guile18-1.8.8-14.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-95eaec7747   
bubblewrap-0.1.3-2.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-f0f6483aa7   
tor-0.2.8.9-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-2fcbc39837   
chromium-54.0.2840.71-1.el7


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

ivykis-0.36.3-1.el7

Details about builds:



 ivykis-0.36.3-1.el7 (FEDORA-EPEL-2016-508ac89b65)
 Library for asynchronous I/O readiness notification

Update Information:

Update to 0.36.3.

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

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 480  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 474  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 406  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8156   
nagios-4.0.8-1.el6
 364  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 336  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 222  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-30a8346813   
vtun-3.0.1-10.el6
  67  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-8594ed3a53   
chicken-4.11.0-3.el6
  39  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-25e30f6dc3   
jansson-2.9-1.el6
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-2f6f1435ed   
tor-0.2.8.9-1.el6
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-a886ace670   
tomcat-7.0.72-1.el6
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-cb5398893b   
nodejs-0.10.48-3.el6


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

ddclient-3.8.3-1.el6
php-ocramius-proxy-manager-1.0.2-2.el6

Details about builds:



 ddclient-3.8.3-1.el6 (FEDORA-EPEL-2016-01ed3129d5)
 Client to update dynamic DNS host entries

Update Information:

New upstream release 3.8.3




 php-ocramius-proxy-manager-1.0.2-2.el6 (FEDORA-EPEL-2016-96dbf8c878)
 OOP proxy wrappers utilities

Update Information:

## php-ocramius-proxy-manager  ### 1.0.2  * 249: Weird problem with
FileWriterGeneratorStrategy * 250: Hotfix - #249 file writer generator strategy
rename failures * 254: Please check 1.0.1 tag  ### 1.0.1  * 249: Weird problem
with FileWriterGeneratorStrategy * 250: Hotfix - #249 file writer generator
strategy rename failures  ---  ## php-ocramius-generated-hydrator  RPM: Added
autoloader  ### 1.2.0  * 31: travis add php 7 + hhvm-nightly * 34: update
manual's url to "current" instead of specified version at README * 41: Tag
release allowing PHP 7 in Composer dependencies list  ---  ## php-ocramius-code-
generator-utils  RPM: Added autoloader

References:

  [ 1 ] Bug #1350615 - php-ocramius-proxy-manager: FTBFS in rawhide
https://bugzilla.redhat.com/show_bug.cgi?id=1350615
  [ 2 ] Bug #1251784 - php-ocramius-proxy-manager-1.0.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1251784

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

Re: DNF and PackageKit background data usage

[Richard Hughes]

On 31 October 2016 at 14:56, Bastien Nocera  wrote:
> I'd really like the kernel to do QoS on the user's own connections. We can 
> know
> whether downloads are interactive or not, so there is metadata available
> to make this better, and not cripple interactive downloads while background
> downloads are ongoing.

We actually do this with PackageKit. It used to work when we were
using yum, but I don't think the libdnf code does any kind of
throttling. Certainly PackageKit knows which transactions are
background and non-interactive, so it certainly makes sense to dribble
those down slowly.

I think this kind of issue is really fixed the hard way, i.e. fixing
bugs and adding unimplemented features rather than just adding complex
UI workarounds.

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

Fedora 25-20161031.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Cloud_base qcow2 x86_64
Server boot x86_64
Atomic qcow2 x86_64
Server dvd i386
Server dvd x86_64
Cloud_base raw-xz x86_64
Server boot i386
Atomic raw-xz x86_64

Failed openQA tests: 1/2 (arm)

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

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

Passed openQA tests: 22/22 (x86_64), 2/2 (i386)

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

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

Skipped openQA tests: 1 of 26
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: DNF and PackageKit background data usage

[Bastien Nocera]

- Original Message -
> > On 30 October 2016 at 01:26, Adam Williamson 
> > wrote:
> > > 1) Both dnf and GNOME Software / PackageKit default to performing
> > > fairly data-hungry transactions in the background, out of the box,
> > > without telling you about it. GNOME's is particularly bad, as it will
> > > happily download available updates in the background, which can be
> > > gigabytes worth of data.
> > 
> > If you're on an "unmetered" connection type...
> 
> This can be problematic even on an unmetered connection. An anecdotal
> experience: A few months back I was on a hotel wifi, I vitally needed some
> information quick, and the wifi simply didn't work - all web pages timed
> out. I was very disgruntled about a crappy hotel wifi (that used to work the
> day before), when in 5-10 minutes, I saw "Your updates were downloaded and
> are ready to install" popup. Then I realized... tried the web browser and
> web pages loaded normally. The wifi connection was so slow that while
> PackageKit was downloading updates in the background, I couldn't access the
> web at all.
> 
> My poor experience stemmed from:
> a) not being informed that updates were being downloaded in the background -
> so I assumed the problem was elsewhere
> b) not being able to pause/abort background downloads - even if I had
> realized/figured out PackageKit was hogging the network, there'd have been
> no way to stop the downloads (certainly no user accessible one, and even
> when I tried to kill the process some time in the past, it just kept
> respawning)
> 
> You can disregard this as a "slow hotel wifi problem only", but I live in a
> block of flats, the air is jammed with 20-30 wifi networks all around me,
> and I experience a similar situation (though not that severe) from time to
> time even at my home, a few meters from the AP - one full speed download can
> completely kill any other (my own) network traffic. Again, this would not be
> a problem if I a) knew about it b) could stop it.

I'd really like the kernel to do QoS on the user's own connections. We can know
whether downloads are interactive or not, so there is metadata available
to make this better, and not cripple interactive downloads while background
downloads are ongoing.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1390179] perl-Net-CUPS-0.63 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Net-CUPS-0.63-1.fc24 has been submitted as an update to Fedora 24.
https://bodhi.fedoraproject.org/updates/FEDORA-2016-4b9949ddbd

-- 
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 1390179] perl-Net-CUPS-0.63 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-Net-CUPS-0.63-1.fc25 has been submitted as an update to Fedora 25.
https://bodhi.fedoraproject.org/updates/FEDORA-2016-57514681ec

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

Re: DNF and PackageKit background data usage

[Bill Peck]

On Mon, 2016-10-31 at 10:32 -0400, Kamil Paral wrote:
> > 
> > On 30 October 2016 at 01:26, Adam Williamson  > t.org>
> > wrote:
> > > 
> > > 1) Both dnf and GNOME Software / PackageKit default to performing
> > > fairly data-hungry transactions in the background, out of the
> > > box,
> > > without telling you about it. GNOME's is particularly bad, as it
> > > will
> > > happily download available updates in the background, which can
> > > be
> > > gigabytes worth of data.
> > 
> > If you're on an "unmetered" connection type...
> 
> This can be problematic even on an unmetered connection. An anecdotal
> experience: A few months back I was on a hotel wifi, I vitally needed
> some information quick, and the wifi simply didn't work - all web
> pages timed out. I was very disgruntled about a crappy hotel wifi
> (that used to work the day before), when in 5-10 minutes, I saw "Your
> updates were downloaded and are ready to install" popup. Then I
> realized... tried the web browser and web pages loaded normally. The
> wifi connection was so slow that while PackageKit was downloading
> updates in the background, I couldn't access the web at all.
> 
> My poor experience stemmed from:
> a) not being informed that updates were being downloaded in the
> background - so I assumed the problem was elsewhere
> b) not being able to pause/abort background downloads - even if I had
> realized/figured out PackageKit was hogging the network, there'd have
> been no way to stop the downloads (certainly no user accessible one,
> and even when I tried to kill the process some time in the past, it
> just kept respawning)
> 
> You can disregard this as a "slow hotel wifi problem only", but I
> live in a block of flats, the air is jammed with 20-30 wifi networks
> all around me, and I experience a similar situation (though not that
> severe) from time to time even at my home, a few meters from the AP -
> one full speed download can completely kill any other (my own)
> network traffic. Again, this would not be a problem if I a) knew
> about it b) could stop it.


Some sort of notification stating that it is happening with a
[pause/cancel/never do this] button so you could control this in the
moment.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

jplesnik pushed to perl-Net-CUPS (f24). "0.63 bump"

[notifications]

From 7d371a51118ecd7d4fb77dc054b5d0e1d92bbe78 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Mon, 31 Oct 2016 15:30:06 +0100
Subject: 0.63 bump

---
 .gitignore | 1 +
 perl-Net-CUPS.spec | 6 +-
 sources| 2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index ab4f7b8..36af6e7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 Net-CUPS-0.61.tar.gz
 /Net-CUPS-0.62.tar.gz
+/Net-CUPS-0.63.tar.gz
diff --git a/perl-Net-CUPS.spec b/perl-Net-CUPS.spec
index 6043f79..b291131 100644
--- a/perl-Net-CUPS.spec
+++ b/perl-Net-CUPS.spec
@@ -1,5 +1,5 @@
 Name:   perl-Net-CUPS
-Version:0.62
+Version:0.63
 Release:1%{?dist}
 Summary:Perl bindings to the CUPS C API Interface
 License:GPL+ or Artistic
@@ -7,6 +7,7 @@ Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Net-CUPS/
 Source0:
http://search.cpan.org/CPAN/authors/id/N/NI/NINE/Net-CUPS-%{version}.tar.gz
 Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+BuildRequires:  coreutils
 BuildRequires:  cups-devel
 BuildRequires:  cups-filters-devel
 BuildRequires:  findutils
@@ -56,6 +57,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Mon Oct 31 2016 Jitka Plesnikova  - 0.63-1
+- 0.63 bump
+
 * Fri Jul 22 2016 Jitka Plesnikova  - 0.62-1
 - 0.62 bump
 
diff --git a/sources b/sources
index 7ae8307..f13f9d8 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-77a606d9bd08265043fc24477da6abcd  Net-CUPS-0.62.tar.gz
+d4446a98ede418bb7bb6f6cb2a01965b  Net-CUPS-0.63.tar.gz
-- 
cgit v0.12



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

[Bug 1390179] perl-Net-CUPS-0.63 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Net-CUPS-0.63-1.fc26



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

jplesnik pushed to perl-Net-CUPS (f25). "0.63 bump"

[notifications]

From 509e14d1dc097a0926b0c69250b13c53ce756885 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Mon, 31 Oct 2016 15:30:06 +0100
Subject: 0.63 bump

---
 .gitignore | 1 +
 perl-Net-CUPS.spec | 6 +-
 sources| 2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index ab4f7b8..36af6e7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 Net-CUPS-0.61.tar.gz
 /Net-CUPS-0.62.tar.gz
+/Net-CUPS-0.63.tar.gz
diff --git a/perl-Net-CUPS.spec b/perl-Net-CUPS.spec
index 19da670..2b8558f 100644
--- a/perl-Net-CUPS.spec
+++ b/perl-Net-CUPS.spec
@@ -1,5 +1,5 @@
 Name:   perl-Net-CUPS
-Version:0.62
+Version:0.63
 Release:1%{?dist}
 Summary:Perl bindings to the CUPS C API Interface
 License:GPL+ or Artistic
@@ -7,6 +7,7 @@ Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Net-CUPS/
 Source0:
http://search.cpan.org/CPAN/authors/id/N/NI/NINE/Net-CUPS-%{version}.tar.gz
 Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+BuildRequires:  coreutils
 BuildRequires:  cups-devel
 BuildRequires:  cups-filters-devel
 BuildRequires:  findutils
@@ -56,6 +57,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Mon Oct 31 2016 Jitka Plesnikova  - 0.63-1
+- 0.63 bump
+
 * Fri Jul 22 2016 Jitka Plesnikova  - 0.62-1
 - 0.62 bump
 
diff --git a/sources b/sources
index 7ae8307..f13f9d8 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-77a606d9bd08265043fc24477da6abcd  Net-CUPS-0.62.tar.gz
+d4446a98ede418bb7bb6f6cb2a01965b  Net-CUPS-0.63.tar.gz
-- 
cgit v0.12



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

Re: DNF and PackageKit background data usage

[Kamil Paral]

> On 30 October 2016 at 01:26, Adam Williamson 
> wrote:
> > 1) Both dnf and GNOME Software / PackageKit default to performing
> > fairly data-hungry transactions in the background, out of the box,
> > without telling you about it. GNOME's is particularly bad, as it will
> > happily download available updates in the background, which can be
> > gigabytes worth of data.
> 
> If you're on an "unmetered" connection type...

This can be problematic even on an unmetered connection. An anecdotal 
experience: A few months back I was on a hotel wifi, I vitally needed some 
information quick, and the wifi simply didn't work - all web pages timed out. I 
was very disgruntled about a crappy hotel wifi (that used to work the day 
before), when in 5-10 minutes, I saw "Your updates were downloaded and are 
ready to install" popup. Then I realized... tried the web browser and web pages 
loaded normally. The wifi connection was so slow that while PackageKit was 
downloading updates in the background, I couldn't access the web at all.

My poor experience stemmed from:
a) not being informed that updates were being downloaded in the background - so 
I assumed the problem was elsewhere
b) not being able to pause/abort background downloads - even if I had 
realized/figured out PackageKit was hogging the network, there'd have been no 
way to stop the downloads (certainly no user accessible one, and even when I 
tried to kill the process some time in the past, it just kept respawning)

You can disregard this as a "slow hotel wifi problem only", but I live in a 
block of flats, the air is jammed with 20-30 wifi networks all around me, and I 
experience a similar situation (though not that severe) from time to time even 
at my home, a few meters from the AP - one full speed download can completely 
kill any other (my own) network traffic. Again, this would not be a problem if 
I a) knew about it b) could stop it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Python packages tests directory co-ownership

[Zbigniew Jędrzejewski-Szmek]

On Mon, Oct 31, 2016 at 12:00:58PM -0200, Athos Ribeiro wrote:
> tl;dr: different packages own /usr/lib/pythonX/site-packages/tests and
> different files with the same name inside that directory.
> 
> Hi all,
> 
> I was going through a package review and realized the package under
> review owns
> 
> /usr/lib/pythonX/site-packages/tests
> 
> and some files inside the directory.
> 
> since there were no subdirectories and there were no namespaces for the
> file names inside the directory, I went further and realized that the
> following packages are doing the same:
> 
> python3-custodia-0:0.1.0-3.fc24.noarch
> python3-django-federated-login-0:1.0.0-9.fc24.noarch
> python3-journal-brief-0:1.1.3-3.fc24.noarch
> python3-oauth2-0:1.9.0-2.post1.fc24.noarch
> python3-repoze-who-plugins-sa-0:1.0.1-10.20160106gite1a36c5.fc24.noarch
> python-custodia-0:0.1.0-3.fc24.noarch
> python-django-federated-login-0:1.0.0-9.fc24.noarch
> python-libturpial-0:1.7.0-4.fc24.noarch
> python-repoze-who-plugins-sa-0:1.0.1-10.20160106gite1a36c5.fc24.noarch
> 
> what's the problem with that? Well what if we would have a package named
> python-tests? shouldn't it own that directory?

No, it's a bug in each and every one of those packages. Usually this
is an upstream issue, and the fix is to make tests/ a submodule of the
main module.
For example of doing this properly, let's take numpy: it has numpy and
numpy.testing. After installation, you can test your *installed* numpy
by running numpy.testing.test(). Countless other packages get this
right too. Squatting on a common name like "test", "tests", "testing"
in the global namespace should be caught in review.

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

Re: Python packages tests directory co-ownership

[Zbigniew Jędrzejewski-Szmek]

On Mon, Oct 31, 2016 at 12:00:58PM -0200, Athos Ribeiro wrote:
> tl;dr: different packages own /usr/lib/pythonX/site-packages/tests and
> different files with the same name inside that directory.
> 
> Hi all,
> 
> I was going through a package review and realized the package under
> review owns
> 
> /usr/lib/pythonX/site-packages/tests
> 
> and some files inside the directory.
> 
> since there were no subdirectories and there were no namespaces for the
> file names inside the directory, I went further and realized that the
> following packages are doing the same:
> 
> python3-custodia-0:0.1.0-3.fc24.noarch
> python3-django-federated-login-0:1.0.0-9.fc24.noarch
> python3-journal-brief-0:1.1.3-3.fc24.noarch
> python3-oauth2-0:1.9.0-2.post1.fc24.noarch
> python3-repoze-who-plugins-sa-0:1.0.1-10.20160106gite1a36c5.fc24.noarch
> python-custodia-0:0.1.0-3.fc24.noarch
> python-django-federated-login-0:1.0.0-9.fc24.noarch
> python-libturpial-0:1.7.0-4.fc24.noarch
> python-repoze-who-plugins-sa-0:1.0.1-10.20160106gite1a36c5.fc24.noarch
> 
> what's the problem with that? Well what if we would have a package named
> python-tests? shouldn't it own that directory?

No, it's a bug in each and every one of those packages. Usually this
is an upstream issue, and the fix is to make tests/ a submodule of the
main module.
For example of doing this properly, let's take numpy: it has numpy and
numpy.testing. After installation, you can test your *installed* numpy
by running numpy.testing.test(). Countless other packages get this
right too. Squatting on a common name like "test", "tests", "testing"
in the global namespace should be caught in review.

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

jplesnik pushed to perl-Net-CUPS (master). "0.63 bump"

[notifications]

From 7193ebcb4e998d203f10ed6e233b0558fe63187a Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Mon, 31 Oct 2016 15:30:06 +0100
Subject: 0.63 bump

---
 .gitignore | 1 +
 perl-Net-CUPS.spec | 6 +-
 sources| 2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index ab4f7b8..36af6e7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 Net-CUPS-0.61.tar.gz
 /Net-CUPS-0.62.tar.gz
+/Net-CUPS-0.63.tar.gz
diff --git a/perl-Net-CUPS.spec b/perl-Net-CUPS.spec
index 19da670..2b8558f 100644
--- a/perl-Net-CUPS.spec
+++ b/perl-Net-CUPS.spec
@@ -1,5 +1,5 @@
 Name:   perl-Net-CUPS
-Version:0.62
+Version:0.63
 Release:1%{?dist}
 Summary:Perl bindings to the CUPS C API Interface
 License:GPL+ or Artistic
@@ -7,6 +7,7 @@ Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Net-CUPS/
 Source0:
http://search.cpan.org/CPAN/authors/id/N/NI/NINE/Net-CUPS-%{version}.tar.gz
 Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+BuildRequires:  coreutils
 BuildRequires:  cups-devel
 BuildRequires:  cups-filters-devel
 BuildRequires:  findutils
@@ -56,6 +57,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Mon Oct 31 2016 Jitka Plesnikova  - 0.63-1
+- 0.63 bump
+
 * Fri Jul 22 2016 Jitka Plesnikova  - 0.62-1
 - 0.62 bump
 
diff --git a/sources b/sources
index 7ae8307..f13f9d8 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-77a606d9bd08265043fc24477da6abcd  Net-CUPS-0.62.tar.gz
+d4446a98ede418bb7bb6f6cb2a01965b  Net-CUPS-0.63.tar.gz
-- 
cgit v0.12



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

jplesnik uploaded Net-CUPS-0.63.tar.gz for perl-Net-CUPS

[notifications]

d4446a98ede418bb7bb6f6cb2a01965b  Net-CUPS-0.63.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Net-CUPS/Net-CUPS-0.63.tar.gz/md5/d4446a98ede418bb7bb6f6cb2a01965b/Net-CUPS-0.63.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Python packages tests directory co-ownership

[Tom Hughes]

On 31/10/16 14:00, Athos Ribeiro wrote:


tl;dr: different packages own /usr/lib/pythonX/site-packages/tests and
different files with the same name inside that directory.

Hi all,

I was going through a package review and realized the package under
review owns

/usr/lib/pythonX/site-packages/tests

and some files inside the directory.


Well if, as I suspect, those files are the tests for the packages in 
question then they probably shouldn't be installed at all.


I only have one of those packages installed on my machine but it does 
appear in that cases to the be the tests for the package which should 
probably have been run in %check but not included in the installed files.


Tom

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

Fedora rawhide compose report: 20161031.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20161030.n.0
NEW: Fedora-Rawhide-20161031.n.0

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

Size of added packages:  0.00 B
Size of dropped packages:0.00 B
Size of upgraded packages:   271.35 MiB
Size of downgraded packages: 0.00 B

Size change of upgraded packages:   1.10 MiB
Size change of downgraded packages: 0.00 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  arduino-1:1.6.4-10.fc26
Old package:  arduino-1:1.6.4-8.fc25
Summary:  An IDE for Arduino-compatible electronics prototyping platforms
RPMs: arduino arduino-core arduino-doc
Size: 6157750 bytes
Size change:  -1620 bytes
Changelog:
  * Thu Sep 22 2016 Dennis Chen <barracks...@gmail.com> - 1:1.6.4-9
  - Fixed broken rawhide deps

  * Sun Oct 30 2016 Dennis Chen <barracks...@gmail.com> - 1:1.6.4-10
  - Fixed Bugzilla #1380938


Package:  cryptsetup-1.7.3-1.fc26
Old package:  cryptsetup-1.7.2-3.fc25
Summary:  A utility for setting up encrypted disks
RPMs: cryptsetup cryptsetup-devel cryptsetup-libs cryptsetup-python 
cryptsetup-python3 cryptsetup-reencrypt veritysetup
Size: 2264832 bytes
Size change:  1808 bytes
Changelog:
  * Sun Oct 30 2016 Milan Broz <gmazyl...@gmail.com> - 1.7.3-1
  - Update to cryptsetup 1.7.3.


Package:  esniper-2.32.0-1.fc26
Old package:  esniper-2.31.0-5.fc24
Summary:  A lightweight console application for sniping eBay auctions
RPMs: esniper
Size: 227848 bytes
Size change:  1544 bytes
Changelog:
  * Mon Oct 31 2016 Volker Fr??hlich <volke...@gmx.at> - 2.32.0-1
  - New upstream release


Package:  gdal-2.1.2-1.fc26
Old package:  gdal-2.1.1-2.fc26
Summary:  GIS file format library
RPMs: gdal gdal-devel gdal-doc gdal-java gdal-javadoc gdal-libs 
gdal-perl gdal-python gdal-python3
Size: 34087248 bytes
Size change:  92524 bytes
Changelog:
  * Sun Oct 30 2016 Volker Froehlich <volke...@gmx.at> - 2.1.2-1
  - New upstream release


Package:  ghc-rpm-macros-1.6.10-2.fc26
Old package:  ghc-rpm-macros-1.6.10-1.fc26
Summary:  RPM macros for building Haskell packages for GHC
RPMs: ghc-obsoletes ghc-rpm-macros ghc-rpm-macros-extra
Size: 533376 bytes
Size change:  1444 bytes
Changelog:
  * Mon Oct 31 2016 Jens Petersen <peter...@redhat.com> - 1.6.10-2
  - only disable arm dynlinking for f26 (#1386126)


Package:  glib2-2.51.0-1.fc26
Old package:  glib2-2.50.1-1.fc26
Summary:  A library of handy utility functions
RPMs: glib2 glib2-devel glib2-doc glib2-fam glib2-static glib2-tests
Size: 24045090 bytes
Size change:  266932 bytes
Changelog:
  * Sun Oct 30 2016 Kalev Lember <klem...@redhat.com> - 2.51.0-1
  - Update to 2.51.0


Package:  gmsh-2.14.1-1.fc26
Old package:  gmsh-2.14.0-2.fc26
Summary:  A three-dimensional finite element mesh generator
RPMs: gmsh gmsh-common gmsh-devel gmsh-doc gmsh-libs gmsh-mpich 
gmsh-mpich-devel gmsh-mpich-libs gmsh-openmpi gmsh-openmpi-devel 
gmsh-openmpi-libs
Size: 56441164 bytes
Size change:  -272772 bytes
Changelog:
  * Sun Oct 30 2016 Sandro Mani <manisan...@gmail.com> - 2.14.1-1
  - Update to 2.14.1


Package:  gnome-calculator-3.23.1-1.fc26
Old package:  gnome-calculator-3.22.1-1.fc26
Summary:  A desktop calculator
RPMs: gnome-calculator
Size: 3915960 bytes
Size change:  -9236 bytes
Changelog:
  * Sun Oct 30 2016 Kalev Lember <klem...@redhat.com> - 3.23.1-1
  - Update to 3.23.1


Package:  gnome-desktop3-3.23.1-1.fc26
Old package:  gnome-desktop3-3.22.1-1.fc26
Summary:  Shared code among gnome-panel, gnome-session, nautilus, etc
RPMs: gnome-desktop3 gnome-desktop3-devel gnome-desktop3-tests
Size: 2731320 bytes
Size change:  256 bytes
Changelog:
  * Sun Oct 30 2016 Kalev Lember <klem...@redhat.com> - 3.23.1-1
  - Update to 3.23.1


Package:  gnome-initial-setup-3.23.1-1.fc26
Old package:  gnome-initial-setup-3.22.1-1.fc26
Summary:  Bootstrapping your OS
RPMs: gnome-initial-setup
Size: 5489068 bytes
Size change:  2088 bytes
Changelog:
  * Sun Oct 30 2016 Kalev Lember <klem...@redhat.com> - 3.23.1-1
  - Update to 3.23.1


Package:  gnome-maps-3.23.1-1.fc26
Old package:  gnome-maps-3.22.1-1.fc26
Summary:  Map application for GNOME
RPMs: gnome-maps
Size: 2430828 bytes
Size change:  1404 bytes
Changelog:
  * Sun Oct 30 2016 Kalev Lember <klem...@redhat.com> - 3.23.1-1
  - Update to 3.23.1


Package:  gnome-nibbles-3.23.1-1.fc26
Old package:  gnome-nibbles-3.22.1-1.fc26
Summary:  GNOME Nibbles game
RPMs: gnome-nibbles
Size: 4406704 bytes
Size change:  -1712 bytes
Changelog:
  * Sun Oct 30 2016 Kal

compat-openssl10-engine_pkcs11

[Nikos Mavrogiannopoulos]

Hi,
 In F26 with the openssl 1.1.0 rebase libp11/engine_pkcs11 will be
compiled only for openssl 1.1.0. That means that there will be no
engine_pkcs11 for the packages linking to openssl 1.0.x. For that I've
created the compat-openssl10-libp11 package which is intended to
provide just that (engine_pkcs11). It will not provide libp11-devel for
these packages, and the shipped libp11 will have different versioned
symbols and soname.

Any objections or issues found with this approach? Otherwise who would
like to review this compat package?

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

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

Broken dependencies: perl-Alien-ROOT

[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

Re: Pondering security update time frames

[Pavel Raiskup]

On Monday, October 31, 2016 1:42:12 PM CET Florian Weimer wrote:
> On 10/26/2016 02:31 PM, Pavel Raiskup wrote:
> > On Wednesday, October 26, 2016 2:03:20 PM CEST Florian Weimer wrote:
> >>> However, extending Koji to support "hidden builds" is certainly a good
> >>> idea.
> >>
> >> Trust me, it's not.  Embargoes are against the spirit of Fedora, and a
> >> general hassle for everyone involved.
> >
> > Vague argument, sorry.  Please elaborate what's against Fedora.
> 
> Looks like I was wrong.  I couldn't find an explicit commitment towards 
> transparency and openness.

Hms, can't comment this personally.

> Debian has one when it comes to bugs, but Fedora does not.

So how debian treats embargo bugs?  As I understood it previously, it
looked like they are able to build in advance, or not?  Do they consider
this "open" enough?

Do we consider temporary window before transparentl publishing everything to be
an issue against openness or transparency?  To making all of this
acceptable (for me), it requires of course that the package "push" action
is a kind of "atomic":

  - builds are published only if CVE is published in the end
  - builds are published only if the sources were already published
(immediately before)
  - there must be obvious that packer did not build something from crafted
SRPM

> > The "status quo" is bad, our _users_ are the ones who suffer from delays
> > in CVE fixes.  We should care take about users, in the first place.
> 
> The question is where these delays come from.
> 
> If a (allegedly non-critical) Firefox update is delayed by weeks, this 
> is certainly not caused by not being able to build embargoed package 
> updates for Fedora.
> 
> In fact, I strongly suggest that any delay by more than one day is *not* 
> caused by lack of embargo support in the Fedora infrastructure because 
> the delay added by fedpkg push && fedpkg build rarely amounts to that.
> 
> There are certainly security updates which require more time to prepare, 
> but those typically require coordination over several packages and 
> involve potentially backwards-incompatible changes.  This is hardly 
> something which is feasible to do under embargo.

Yep, accepted.  But we don't have to cover all use cases.

> >> Deploying a lot of infrastructure for the one or two cases per year
> >> where it comes in handy does not make sense.
> >
> > That's more than _two cases_ a year
> 
> Could you name a few cases where this would make a difference?  If there 
> are so many, surely it's easy to come up with a couple of examples.

Starting the list of examples by PostgreSQL, there are several updates a
year (some are security related).  Distro packagers are nicely asked to
have a look at the tarballs and perform testing in advance.

> Than we could look at Fedora update delays for those and see to what 
> extent building fixed packages in secret, during the embargo period, 
> would reduce those delays.

*Full* update delays are usually related to karma++.  But once the build
is in 'testing', it is fine from the security POV.

So in the end, the delay is basically between upstream announcement and
(git push;  fedpkg build; fedpkg update).  It is usually not a huge delay,
because we plan this according to upstream schedule -> but having the
update prepared with full respect to upstream would ease the preparation
phase.

> > Upstream maintainers are *asking us* in advance to report them back
> > whether the release tarball works for us!  And they would willingly fix
> > the release tarballs or help us with issues, but we are unable to respond
> > (that's shame).   Yeah, I'm able to do my local build on x86_64 machine
> > (and build in i686 mock), but that's everything I can do;  if the aarch64
> > fails for me, then we'll have nontrivial delay..
> 
> Again, concrete examples here (and not for rebases targeting rawhide),
> would be more convincing.

Personally I can mention only PostgreSQL, there was such upgrade last week
(while I posted my previous message actually).  That's not only about
Rawhide (F23+).

> > I'm OK to accept the fact "hidden builds" are not perfect approach, that's
> > right, but that could be relatively easy for implementation.
> 
> I haven't tried to implement anything in Koji, so I'm not sure how easy 
> it is to get there.  There seem to be a lot of corner cases to consider:
> Should fedpkg new-sources uploads default to private?  Are all packages
> allowed to see all embargoed builds?  Do we need one temporary build
> root per embargoed fix to deal with dependency chains?

IMO: No && s/packages/packagers/ No && Yes.

> These look like difficult decisions, and that's not even about
> implementation at all.

No doubts..  Doesn't sound easy at all, so if there was easier way to solve the
problem?

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

Python packages tests directory co-ownership

[Athos Ribeiro]

tl;dr: different packages own /usr/lib/pythonX/site-packages/tests and
different files with the same name inside that directory.

Hi all,

I was going through a package review and realized the package under
review owns

/usr/lib/pythonX/site-packages/tests

and some files inside the directory.

since there were no subdirectories and there were no namespaces for the
file names inside the directory, I went further and realized that the
following packages are doing the same:

python3-custodia-0:0.1.0-3.fc24.noarch
python3-django-federated-login-0:1.0.0-9.fc24.noarch
python3-journal-brief-0:1.1.3-3.fc24.noarch
python3-oauth2-0:1.9.0-2.post1.fc24.noarch
python3-repoze-who-plugins-sa-0:1.0.1-10.20160106gite1a36c5.fc24.noarch
python-custodia-0:0.1.0-3.fc24.noarch
python-django-federated-login-0:1.0.0-9.fc24.noarch
python-libturpial-0:1.7.0-4.fc24.noarch
python-repoze-who-plugins-sa-0:1.0.1-10.20160106gite1a36c5.fc24.noarch

what's the problem with that? Well what if we would have a package named
python-tests? shouldn't it own that directory? Also, since there are no
namespaces inside that directory for each package owning files in there,
they could end up owning different files with the same name. Actually,
the following packages own /usr/lib/python3.5/site-packages/tests/__init__.py
python3-custodia-0:0.1.0-3.fc24.noarch
python3-django-federated-login-0:1.0.0-9.fc24.noarch
python3-oauth2-0:1.9.0-2.post1.fc24.noarch
python3-repoze-who-plugins-sa-0:1.0.1-10.20160106gite1a36c5.fc24.noarch

or /usr/lib/python2.7/site-packages/tests/__init__.py

python-custodia-0:0.1.0-3.fc24.noarch
python-django-federated-login-0:1.0.0-9.fc24.noarch
python-libturpial-0:1.7.0-4.fc24.noarch
python-repoze-who-plugins-sa-0:1.0.1-10.20160106gite1a36c5.fc24.noarch

Is that all really a problem or am I missing something in the guidelines?

-- 
Athos Ribeiro

http://www.ime.usp.br/~athoscr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 25 compose report: 20161031.n.0 changes

[Fedora Branched Report]

OLD: Fedora-25-20161030.n.0
NEW: Fedora-25-20161031.n.0

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

Size of added packages:  0.00 B
Size of dropped packages:0.00 B
Size of upgraded packages:   0.00 B
Size of downgraded packages: 0.00 B

Size change of upgraded packages:   0.00 B
Size change of downgraded packages: 0.00 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
Broken deps for armhfp
--
[OmegaT]
OmegaT-2.6.3-2.fc22.armv7hl requires hunspell <= 0:1.4.0
[RackTables]
RackTables-0.20.10-7.fc24.noarch requires php-mysql
[asterisk]
asterisk-dahdi-13.9.1-1.fc25.1.armv7hl requires dahdi-tools >= 0:2.0.0
asterisk-dahdi-13.9.1-1.fc25.1.armv7hl requires libtonezone.so.2.0
[beacon]
beacon-0.5-13.fc24.noarch requires php-mysql
[bionetgen]
bionetgen-2.2.6-3.fc25.armv7hl requires libsundials_cvode.so.1
bionetgen-2.2.6-3.fc25.armv7hl requires libsundials_nvecserial.so.0
[collectd]
collectd-onewire-5.6.0-2.fc25.armv7hl requires libowcapi-3.1.so.0
[docker]
2:docker-1.12.2-5.git8f1975c.fc25.armv7hl requires skopeo-containers
[golang-github-aws-aws-sdk-go]
golang-github-aws-aws-sdk-go-devel-1.1.3-2.fc25.noarch requires 
golang(golang.org/x/tools/go/types)
[golang-github-gonum-matrix]
golang-github-gonum-matrix-devel-0-0.5.gitfb13962.fc25.noarch requires 
golang(github.com/gonum/lapack/lapack64)
[golang-github-kubernetes-heapster]
golang-github-kubernetes-heapster-devel-0.16.1-4.fc25.noarch requires 
golang(github.com/google/cadvisor/client)
golang-github-kubernetes-heapster-devel-0.16.1-4.fc25.noarch requires 
golang(github.com/google/cadvisor/info/v1)
[golang-github-samalba-dockerclient]
golang-github-samalba-dockerclient-devel-0-0.3.gitc37a52f.fc24.noarch 
requires golang(github.com/docker/docker/pkg/timeutils)
[moksha]
moksha-server-1.0.0-11.fc24.noarch requires orbited
[mrbs]
mrbs-1.4.10-4.fc24.noarch requires php-mysql
[nodejs-co-mocha]
nodejs-co-mocha-1.1.2-1.fc25.noarch requires npm(co) >= 0:4.0.0
[nodejs-cross-spawn]
nodejs-cross-spawn-4.0.0-1.fc25.noarch requires npm(lru-cache) >= 
0:4.0.1
[nodejs-grunt-contrib-csslint]
nodejs-grunt-contrib-csslint-0.4.0-6.fc24.noarch requires 
npm(strip-json-comments) < 0:2
[nodejs-npm-stats]
nodejs-npm-stats-1.1.0-3.fc24.noarch requires npm(JSONStream) < 0:1
[nodejs-rc]
nodejs-rc-1.1.6-2.fc24.noarch requires npm(strip-json-comments) < 0:2
[php-magickwand]
php-magickwand-1.0.9.2-9.fc24.armv7hl requires php(api) = 0:20131106-32
php-magickwand-1.0.9.2-9.fc24.armv7hl requires php(zend-abi) = 
0:20131226-32
[php-pecl-cairo]
php-pecl-cairo-0.3.2-11.fc25.armv7hl requires php(api) = 0:20131106-32
php-pecl-cairo-0.3.2-11.fc25.armv7hl requires php(zend-abi) = 
0:20131226-32
[php-pecl-parsekit]
php-pecl-parsekit-1.3.0-10.fc25.armv7hl requires php(api) = 
0:20131106-32
php-pecl-parsekit-1.3.0-10.fc25.armv7hl requires php(zend-abi) = 
0:20131226-32
[php-pecl-runkit]
php-pecl-runkit-1.0.4-3.fc25.armv7hl requires php(api) = 0:20131106-32
php-pecl-runkit-1.0.4-3.fc25.armv7hl requires php(zend-abi) = 
0:20131226-32
[php-pecl-sphinx]
php-pecl-sphinx-1.3.2-6.fc24.armv7hl requires php(api) = 0:20131106-32
php-pecl-sphinx-1.3.2-6.fc24.armv7hl requires php(zend-abi) = 
0:20131226-32
[poweradmin]
poweradmin-2.1.7-1.fc24.noarch requires php-pear(MDB2_Driver_mysql)
[pyqtrailer]
pyqtrailer-0.6.2-10.fc25.noarch requires pytrailer >= 0:0.6.0
[python-assimulo]
python2-assimulo-2.9-2.fc25.armv7hl requires libsundials_idas.so.0
python2-assimulo-2.9-2.fc25.armv7hl requires libsundials_kinsol.so.1
python2-assimulo-2.9-2.fc25.armv7hl requires libsundials_nvecserial.so.0
python3-assimulo-2.9-2.fc25.armv7hl requires libsundials_idas.so.0
python3-assimulo-2.9-2.fc25.armv7hl requires libsundials_kinsol.so.1
python3-assimulo-2.9-2.fc25.armv7hl requires libsundials_nvecserial.so.0
[python-ironicclient]
python3-ironicclient-1.3.1-3.fc25.noarch requires 
python3-openstackclient >= 0:2.1.0
[python-pysaml2]
python3-pysaml2-3.0.2-3.fc25.noarch requires python3-pycrypto >= 0:2.5
[python-zope-i18n]
python2-zope-i18n-4.1.0-4.fc25.noarch requires python2-zope-schema
[qutim]
qutim-0.3.2-5.git.6f3a98a.fc23.armv7hl requires libhunspell-1.3.so.0
[rOCCI-server]
rOCCI-server-1.1.9-1.fc25.noarch requires rubygem(rails) < 0:4.3
rOCCI-server-1.1.9-1.fc25.noarch requires rubygem(responders) < 0:2.2
[redland-bindings]
php-redland-1

Broken dependencies: perl-Data-Alias

[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