introducing transtats

[Sundeep Anand]

Hi Everyone,

Transtats[1] has been into development for a while now and can help in making 
packages ready to ship with translation completeness[2]. With a few initial use 
cases[3] it can bring interesting results in coming releases.

Can a I have +1s if you find this useful.

thanks,
sundeep

[1] http://transtats.org/
[2] https://www.youtube.com/watch?v=8q9cg-wsrUg
[3] 
https://lists.fedoraproject.org/archives/list/g...@lists.fedoraproject.org/thread/RAPJMYAXDNAIWFKT6HUUVDXW7XQ3FZZV/
   
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1560768] New: perl-Authen-SCRAM-0.009 is available

[bugzilla]

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

Bug ID: 1560768
   Summary: perl-Authen-SCRAM-0.009 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Authen-SCRAM
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 0.009
Current version/release in rawhide: 0.007-2.fc28
URL: http://search.cpan.org/dist/Authen-SCRAM/

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

-- 
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 1560766] New: perl-IPC-Run-0.97 is available

[bugzilla]

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

Bug ID: 1560766
   Summary: perl-IPC-Run-0.97 is available
   Product: Fedora
   Version: rawhide
 Component: perl-IPC-Run
  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,
st...@silug.org



Latest upstream release: 0.97
Current version/release in rawhide: 0.96-4.fc28
URL: http://search.cpan.org/dist/IPC-Run

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

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

[EPEL-devel] Re: request commit access to python-qt5 dist-git repo to add epe7 branch

[Sérgio Basto]

On Mon, 2018-03-26 at 15:33 -0500, Rex Dieter wrote:
> Sérgio Basto wrote:
> 
> > On Tue, 2018-03-06 at 16:15 -0600, Rex Dieter wrote:
> > > I'd be ok with an epel7-only python3-sip
> > > 
> > > Since it is a new package (not a branch of an existing one), then
> > > it
> > > would require a new package review.
> > > 
> > > It would be a bit of shame though, having to fork things like
> > > that.
> > 
> > I tried this solution (epel7-only python3-sip) but
> > BUILDSTDERR: Error: This version of PyQt5 requires sip 4.19.4 or
> > later.
> > when el7 have  sip-devel  x86_64 4.14.6-4.el7 base
> > 
> > if we do package sip-qt5 we must override
> > /usr/lib64/python2.7/site-
> > packages/sip.so
> > it is possible sip-qt5 provides and obsolete sip (4.14.6-4.el7) ?
> 
> Not possible (by policy).  It should be able to work without doing
> that, but 
> it may require patching.

I don't see how. In python2, how "import sip" will work ? "import sip-qt5 as 
sip" ? 

Best regards
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: notificati...@fedoraproject.org

[Sérgio Basto]

On Mon, 2018-03-26 at 12:15 -0400, Ralph Bean wrote:
> On Fri, Mar 23, 2018 at 07:15:36PM +, Sérgio Basto wrote:
> > Hi,
> > 
> > I have a suggestion. After some confusions that I have made related
> > with notifications with a big delay .
> > 
> > Please add the date of notification on the notification .
> > 
> > Thanks,
> > --
> > Sérgio M. B.
> 
> Makes sense.  Can you file that as a RFE
> here?  https://github.com/fedora-infra/fmn/issues

Done 

https://github.com/fedora-infra/fmn/issues/285

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Fedocal] Reminder meeting : Modularity Office Hours

[nils]

Dear all,

You are kindly invited to the meeting:
   Modularity Office Hours on 2018-03-27 from 10:00:00 to 11:00:00 US/Eastern
   At fedora-modular...@chat.freenode.net

The meeting will be about:
This is where you ask the Fedora Modularity Team questions (and we try to 
answer them)!

Join us on [IRC](irc://chat.freenode.net/#fedora-modularity): 
#fedora-modularity on [FreeNode](https://freenode.net)


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

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

[Bug 1560322] perl-DateTime-1.47 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-DateTime-1.48-1.fc28 has been pushed to the Fedora 28 testing repository.
If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-455e277f36

-- 
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: Facing problems in pagure

[Kevin Fenzi]

On 03/24/2018 04:43 AM, Tanmoy sarkar wrote:
> I am facing some problems in pagure. 

pagure.io? Or the pagure on src.fedoraproject.org ?

I have configured everything successfully. But when I try to clone files
with ssh this returns. signing failed: agent refused operation
permission denied (publickey). fatal: could not read from remote
repository. please make sure you have the correct access rights and the
repository exists. When I use clone with git url, it works successfully.
But when I push files to pagure repo with git url that gives: The
requested URL returned error: 403

What is the project/repo?

kevin



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

[EPEL-devel] Re: request commit access to python-qt5 dist-git repo to add epe7 branch

[Sérgio Basto]

On Tue, 2018-03-06 at 16:15 -0600, Rex Dieter wrote:
> I'd be ok with an epel7-only python3-sip
> 
> Since it is a new package (not a branch of an existing one), then it
> would require a new package review.
> 
> It would be a bit of shame though, having to fork things like that.

I tried this solution (epel7-only python3-sip) but 
BUILDSTDERR: Error: This version of PyQt5 requires sip 4.19.4 or later.
when el7 have  sip-devel  x86_64 4.14.6-4.el7 base

if we do package sip-qt5 we must override /usr/lib64/python2.7/site-
packages/sip.so

it is possible sip-qt5 provides and obsolete sip (4.14.6-4.el7) ? 

As a side note for epel-devel we also need python3-sip which is not
provide by el7, since only epel-7 have python3, isn't it ?

 

> On Tue, Mar 6, 2018 at 2:02 PM, Sérgio Basto 
> wrote:
> > new suggestion for new sip: sip-qt5
> > 
> > On Mon, 2018-03-05 at 16:35 +, Sérgio Basto wrote:
> > > I study this a little , the sip on rhel is sip 4.14 and we need
> > > sip 4.15+ , but should be cool have python3-qt5, even we they
> > > update sip in RHEL won't have pyhton3 bindings since python34 is
> > > in epel .
> > > So can we consider do a package named sip5 (for qt5) just in
> > > epel7 ?
> > > 
> > > On Mon, 2018-03-05 at 10:20 -0600, Rex Dieter wrote:
> > > > Since the requisite version of sip cannot go into epel7, I'm
> > > > not sure if it makes sense to make an epel7 branch for python-
> > > > qt5.  I'm guessing no.
> > > > 
> > > > On Sat, Mar 3, 2018 at 6:37 PM, Sérgio Basto  > > > > wrote:
> > > > > Hello,
> > > > > Same email to python-qt5
> > > > > 
> > > > > From [1] I'd like ask, please, request to commit or please
> > > > > branch
> > > > > python-qt5 into epel7 (after build sip ) and build the
> > > > > package from
> > > > > master  .
> > > > > I'd like bring python-qt5 to epel7 , as explain in PR #3 [2]
> > > > > epel 6 for now is not in the plans .
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > [2]
> > > > > https://src.fedoraproject.org/rpms/sip/pull-request/3
> > > > > 
> > > > > I'd like have python-qt5 on epel7 to build openshot and
> > > > > probably other
> > > > > packages , for that I need sip
> > > > > 
> > > > > I tested in copr [1] and build openshot successfully  for
> > > > > epel6 we
> > > > > need phonon-qt5 and phonon-qt5-backend-gstreamer , but epel6
> > > > > doesn't
> > > > > have gstreame1 for backend package ...
> > > > > 
> > > > > 
> > > > > [1]
> > > > > https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToP
> > > > > kgdb#How_do_I_request_commit_access_to_a_dist-git_repo.3F
> > > > > 
> > > > > How do I request commit access to a dist-git repo?
> > > > > 
> > > > > Email the packagename-ow...@fedoraproject.org alias asking to
> > > > > be given
> > > > > access, or file a bugzilla bug on the package asking for
> > > > > access.
> > > > > 
> > > > > 
> > > > > --
> > > > > Sérgio M. B.
> > > 
> > > -- 
> > > Sérgio M. B.
> > 
> > -- 
> > Sérgio M. B.
> 
> 
-- 
Sérgio M. B.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[Bug 1560322] perl-DateTime-1.47 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-DateTime-1.48-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-455e277f36

-- 
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: orphaned sonar

[Erik Logtenberg]

Hi all,

FYI I am considering to take over maintenance of sonar packages,
contacted Michael off-list for some more background on the decision to
orphan.

Kind regards,

Erik.


Op 26-03-18 om 15:48 schreef Michael Šimáček:
> Hi,
> 
> I've orphaned sonar and related packages:
> sonar
> sonar-plugins-parent
> sonar-runner
> sonar-update-center
> 
> They used to be a dependency of gradle, but nothing depends on them now.
> They're severely outdated.
> 
> Michael
> ___
> 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: Fedora 28 minimum memory requirement, review

[Joonas Sarajärvi]

William Moreno kirjoitti 23.03.2018 klo 01:34:
I a computer without a SSD Plasma and Gnome Shell do not work well, so 
in the current state os those desktop enviroments the page also should 
recomend to use a SSD disck, is not use a alternative desktop like 
Cinnamon or a more clasical option like Mate.


I am not sure of how useful anecdotes about this are, but anyway in my 
experience Gnome is just fine with the rotating disks that my desktop 
has. Of course it starts noticeably faster from SSD storage, but the 
difference is not dramatic enough to make me wonder if I should switch 
to an other environment on this system.

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

[Bug 1553503] perl-Time-Moment-0.43 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Time-Moment-0.43-1.fc2 |perl-Time-Moment-0.43-1.fc2
   |6   |6
   |perl-Time-Moment-0.43-1.fc2 |perl-Time-Moment-0.43-1.fc2
   |7   |7
   ||perl-Time-Moment-0.43-1.el7



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

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

Fedora-Atomic 27-20180326.1 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 2/2 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Announcing DNF 3 development

[Neal Gompa]

On Mon, Mar 26, 2018 at 12:10 PM, Martin Kolman  wrote:
> On Mon, 2018-03-26 at 11:59 -0400, Neal Gompa wrote:
>> On Mon, Mar 26, 2018 at 11:02 AM, Vít Ondruch  wrote:
>> >
>> >
>> > Dne 26.3.2018 v 10:16 Tom Hughes napsal(a):
>> > > On 26/03/18 09:06, Marcin Juszkiewicz wrote:
>> > > > W dniu 22.03.2018 o 13:40, Daniel Mach pisze:
>> > > > > We are pleased to announce that development of DNF 3 has started. 
>> > > > > This
>> > > > > version is focused on performance improvements, new API and
>> > > > > consolidating
>> > > > > the whole software management stack.
>> > > > >
>> > > > > Please read more details on our blog:
>> > > > > https://rpm-software-management.github.io/announcement/2018/03/22/dnf-3-announcement/
>> > > > >
>> > > >
>> > > > Will it FINALLY use one copy of metadata for all system users?
>> > >
>> > > Do you have a proposal as to how that might be possible in a
>> > > secure way?
>> >
>> > If DNF was just frontend for some service/daemon, that would be one
>> > possibility. It would also help with other issues like updates of X
>> > server crashing whole user session and therefore the update.
>> >
>>
>> It would be nice if dnfdaemon was actually merged into dnf itself, but
>> I'm not sure whether they'd consider it to be desirable or not.
> I have a hunch there will be some gotchas, otherwise everybody would be doing 
> it.
>
> Maybe issues with chrooting or something like that ?

We'd probably want a no-daemon switch for changing behavior, and
trigger that change for circumstances where the daemon cannot run.



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

Re: Trouble with Waivers

[Michael Cronenworth]

On 03/26/2018 11:38 AM, Adam Williamson wrote:

FWIW I think I had the same problem; I tried to submit waivers for some
rpmdeplint failures in the OpenCV 3.4.1 rebuild update and they never
seemed to 'take' (even after more than 6 hours). In the end I just
unpushed and repushed the update to get the tests re-run.


Thanks, Adam. The Fedora 26 waiver was submitted last week... so I'll unpush and 
re-push. Multiple weeks that updates cannot be pushed out. Not fun.

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

Fedora Rawhide-20180326.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 14/137 (x86_64), 7/23 (i386), 1/2 (arm)

ID: 211868  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/211868
ID: 211900  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/211900
ID: 211910  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/211910
ID: 211911  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/211911
ID: 211914  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/211914
ID: 211923  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/211923
ID: 211925  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/211925
ID: 211929  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default_upload
URL: https://openqa.fedoraproject.org/tests/211929
ID: 211930  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default@uefi
URL: https://openqa.fedoraproject.org/tests/211930
ID: 211931  Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/211931
ID: 211975  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/211975
ID: 211990  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/211990
ID: 211994  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/211994
ID: 211995  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/211995
ID: 211996  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/211996
ID: 211997  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/211997
ID: 211998  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/211998
ID: 212013  Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/212013
ID: 212015  Test: i386 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/212015
ID: 212020  Test: i386 universal install_blivet_no_swap
URL: https://openqa.fedoraproject.org/tests/212020
ID: 212025  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/212025
ID: 212026  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/212026

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

ID: 211878  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/211878
ID: 211888  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/211888
ID: 211889  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/211889
ID: 211893  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/211893
ID: 211894  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/211894
ID: 211905  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/211905
ID: 211908  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/211908
ID: 211909  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/211909
ID: 211913  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/211913
ID: 211988  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/211988
ID: 211993  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/211993
ID: 212004  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/212004
ID: 212024  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/212024

Passed openQA tests: 107/137 (x86_64), 12/23 (i386)

Skipped openQA tests: 7 of 162
-- 
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: Announcing DNF 3 development

[Colin Walters]

On Mon, Mar 26, 2018, at 11:02 AM, Vít Ondruch wrote:

> If DNF was just frontend for some service/daemon, that would be one
> possibility. It would also help with other issues like updates of X
> server crashing whole user session and therefore the update.

FWIW rpm-ostree is always a daemon today; we're really focused on the
"host system" management case so we can just assume that.  Obviously
there's PackageKit as well.

That said I spent a while thinking about this a while ago, and the thing
is a vast array of tooling assumes that package managers are CLI tools.
Not least e.g. `Dockerfile` style container builds.  And `mock`.
So you'd really end up with something that splits up the "managing a host
system" from "buildroot tool", which is how I think of rpm-ostreed
versus dnf today.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1560548] perl-Test-PostgreSQL-1.25 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Test-PostgreSQL-1.25-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-028fdd9656

-- 
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 1560173] perl-DateTime-TimeZone-2.18 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-DateTime-TimeZone-2.18-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-12382064dc

-- 
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: Trouble with Waivers

[Adam Williamson]

On Mon, 2018-03-26 at 12:14 -0400, Ralph Bean wrote:
> On Mon, Mar 26, 2018 at 08:53:41AM -0500, Michael Cronenworth wrote:
> > I have attempted to create waivers for two updates, but they are still
> > unable to be pushed. What have I done wrong?
> > 
> > https://bodhi.fedoraproject.org/updates/FEDORA-2018-c5a0e704d6
> > https://bodhi.fedoraproject.org/updates/FEDORA-2018-ec1108333e
> > 
> > $ waiverdb-cli -t dist.rpmdeplint -s '{"item": "wine-3.4-1.fc28", "type":
> > "koji_build"}' -p "fedora-28" -c "This is fine"
> > Created waiver 94 for result with subject {"item": "wine-3.4-1.fc28",
> > "type": "koji_build"} and testcase dist.rpmdeplint
> 
> It looks like you did the right thing to me.
> 
> IIRC, Bodhi checks back with Greenwave once every 6 hours, so you'll
> have to wait for that window to close for Bodhi to notice the change.
> (The plan is to have Bodhi listen to Greenwave's bus messages which
> would eliminate wait period like this.

FWIW I think I had the same problem; I tried to submit waivers for some
rpmdeplint failures in the OpenCV 3.4.1 rebuild update and they never
seemed to 'take' (even after more than 6 hours). In the end I just
unpushed and repushed the update to get the tests re-run.
-- 
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: 'endless' stream of "greenwave is a GO on glusterfs-4.0.0-2...." emails

[Ralph Bean]

On Thu, Mar 22, 2018 at 05:34:23PM -0700, Kevin Fenzi wrote:
> On 03/21/2018 01:52 PM, Kaleb S. KEITHLEY wrote:
> > On 03/21/2018 04:45 PM, Kevin Fenzi wrote:
> >> On 03/20/2018 11:02 AM, Kaleb S. KEITHLEY wrote:
> >>>
> >>> I've rec'd about 30 of these in the last hour or so, fedora-28,
> >>> fedora-27, fedora-26, and fedora-28-modular.
> >>>
> >>> Would someone please make them stop
> >>
> >> You can do so.
> >
> > I think you misunderstood what I was asking.
>
> ah, I did. sorry.
> >
> > I'm fine with getting _one_ notification. Or maybe even five.
> >
> > But I have probably 50 in my inbox after all was said and done. All from
> > one build.
>
> Yeah, that seems... wrong.
>
> CCing Ralph here, perhaps he can comment or other greenwave developers.

Yeah, the tl;dr is that Bodhi greenwave needs to be taught that an f26
build only makes sense in the f26 policy.  Today, it receives notice
about a f26 build and publishes messages about all the policies it has
that might apply to that build (f28, f27, f26, etc..).

Dan is taking a look at refactoring it to know a bit more about the
things its being asked about (builds, updates, ..) which should end
up cutting way down on this spam.  https://pagure.io/greenwave/issue/126

>
> kevin
> --
>
> >
> >>
> >> Go to:
> >>
> >> https://apps.fedoraproject.org/notifications
> >>
> >> login and select email
> >>
> >> There should be a ruleset on the right called:
> >> "Events on packages I own"
> >>
> >> Click on it to edit it.
> >>
> >> On the right now there should be a long list of possible messages, one
> >> of them is "Greenwave decisions"
> >>
> >> Click on "Greenwave decisions" and then "add this rule"
> >>
> >> Now there should be a "Greenwave decisions" rule on the left in your
> >> ruleset.
> >>
> >> Under that is a "!Negate" button. Click on that to make the rule be a
> >> negation rule instead of a matching rule.
> >>
> >> Now you should no longer get any greenwave emails.
> >>
> >> Sorry this is so confusing an interface. It really needs a re-write with
> >> input from some design folks, but we just haven't had the cycles to do
> >> so yet.
> >>
> >> kevin
> >>
> >>
> >>
> >> ___
> >> devel mailing list -- devel@lists.fedoraproject.org
> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >>
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >
>
>





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

Re: notificati...@fedoraproject.org

[Ralph Bean]

On Fri, Mar 23, 2018 at 07:15:36PM +, Sérgio Basto wrote:
> Hi,
>
> I have a suggestion. After some confusions that I have made related
> with notifications with a big delay .
>
> Please add the date of notification on the notification .
>
> Thanks,
> --
> Sérgio M. B.

Makes sense.  Can you file that as a RFE here?  
https://github.com/fedora-infra/fmn/issues


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

Re: Trouble with Waivers

[Ralph Bean]

On Mon, Mar 26, 2018 at 08:53:41AM -0500, Michael Cronenworth wrote:
> I have attempted to create waivers for two updates, but they are still
> unable to be pushed. What have I done wrong?
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2018-c5a0e704d6
> https://bodhi.fedoraproject.org/updates/FEDORA-2018-ec1108333e
>
> $ waiverdb-cli -t dist.rpmdeplint -s '{"item": "wine-3.4-1.fc28", "type":
> "koji_build"}' -p "fedora-28" -c "This is fine"
> Created waiver 94 for result with subject {"item": "wine-3.4-1.fc28",
> "type": "koji_build"} and testcase dist.rpmdeplint

It looks like you did the right thing to me.

IIRC, Bodhi checks back with Greenwave once every 6 hours, so you'll
have to wait for that window to close for Bodhi to notice the change.
(The plan is to have Bodhi listen to Greenwave's bus messages which
would eliminate wait period like this.)


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

[Bug 1560173] perl-DateTime-TimeZone-2.18 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-DateTime-TimeZone-2.18-1.fc26 has been pushed to the Fedora 26 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-eb0ef2180d

-- 
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 1560548] perl-Test-PostgreSQL-1.25 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-Test-PostgreSQL-1.25-1.fc26 has been pushed to the Fedora 26 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-b00d6c4a29

-- 
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: Announcing DNF 3 development

[Martin Kolman]

On Mon, 2018-03-26 at 11:59 -0400, Neal Gompa wrote:
> On Mon, Mar 26, 2018 at 11:02 AM, Vít Ondruch  wrote:
> > 
> > 
> > Dne 26.3.2018 v 10:16 Tom Hughes napsal(a):
> > > On 26/03/18 09:06, Marcin Juszkiewicz wrote:
> > > > W dniu 22.03.2018 o 13:40, Daniel Mach pisze:
> > > > > We are pleased to announce that development of DNF 3 has started. This
> > > > > version is focused on performance improvements, new API and
> > > > > consolidating
> > > > > the whole software management stack.
> > > > > 
> > > > > Please read more details on our blog:
> > > > > https://rpm-software-management.github.io/announcement/2018/03/22/dnf-3-announcement/
> > > > > 
> > > > 
> > > > Will it FINALLY use one copy of metadata for all system users?
> > > 
> > > Do you have a proposal as to how that might be possible in a
> > > secure way?
> > 
> > If DNF was just frontend for some service/daemon, that would be one
> > possibility. It would also help with other issues like updates of X
> > server crashing whole user session and therefore the update.
> > 
> 
> It would be nice if dnfdaemon was actually merged into dnf itself, but
> I'm not sure whether they'd consider it to be desirable or not.
I have a hunch there will be some gotchas, otherwise everybody would be doing 
it.

Maybe issues with chrooting or something like that ?
> 
> 
> -- 
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> 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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 1113  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 875  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 458  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 355  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 187  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
 124  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  29  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3e70a38ad4   
drupal7-7.57-1.el7
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-635348eab4   
php-simplesamlphp-saml2_1-1.10.6-1.el7
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7150fa5dce   
php-simplesamlphp-saml2-2.3.8-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-673b3314a1   
exim-4.90.1-3.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3f41541339   
monitorix-3.10.1-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ae3a1eae7e   
glpi-0.90.5-2.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-add4fc19d8   
mosquitto-1.4.15-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-1fbdf7f103   
chromium-65.0.3325.181-1.el7


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

adapta-gtk-theme-3.93.0.200-1.el7
akmods-0.5.6-15.el7
cacti-1.1.37-1.el7
php-scssphp-0.7.5-2.el7
python-paramiko-2.1.1-0.4.el7
python3-websocket-client-0.47.0-1.el7

Details about builds:



 adapta-gtk-theme-3.93.0.200-1.el7 (FEDORA-EPEL-2018-7502bb26cc)
 An adaptive Gtk+ theme based on Material Design Guidelines

Update Information:

- New upstream release

References:

  [ 1 ] Bug #1554424 - adapta-gtk-theme conflicts with itself
https://bugzilla.redhat.com/show_bug.cgi?id=1554424
  [ 2 ] Bug #1554156 - adapta-gtk-theme-3.93.0.200 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1554156




 akmods-0.5.6-15.el7 (FEDORA-EPEL-2018-7ca7c4028e)
 Automatic kmods build and install tool

Update Information:

- Add inihibitor for akmods@.service - Use restart on akmodsposttrans - Switch
to always retry by default - Drop akmods preset by f28 - Don't enable service on
ah - Test a rw directory




 cacti-1.1.37-1.el7 (FEDORA-EPEL-2018-d797b60200)
 An rrd based graphing tool

Update Information:

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




 php-scssphp-0.7.5-2.el7 (FEDORA-EPEL-2018-97bcf66281)
 A compiler for SCSS written in PHP

Update Information:

## v0.7.5  ### Fixes  - Fix `for` loop with units (@of2607) - Fix side-effects
in `abs()`, `ceil()`, `floor()`, and `round()` (@jugyhead)  ### New  - Add
option for custom `SourceMapGenerator` (@dleffler)  ## v0.7.4  ### Bug fixes  -
Fat fingered cleanup; broke file-based source maps (@dleffler)  ## v0.7.3  ###
Enhancements  - Add inline sourcemaps (@NicolaF, @oyejorge) - Add file-based
sourcemaps (@dleffler)  ## v0.7.2  ### Compatibility  - increase default
precision to 10 (was 5) to match ruby scss 3.5.0  ### Bug fixes  - replace
`locale()` with `number_format()` (@Arlisaha)  ## v0.7.1  ### Compat Buster  -
Server class moved to `/example` folder - Server::serveFrom() removed; use `(new
Server)->serve()` instead - Removed `.phar` build  ### Bug fixes  - `each()`
deprecated in PHP 7.2 (@marinaglancy)  ## v0.7.0

References:

  [ 1 ] Bug #1504394 - php-scssphp-0.7.5 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1504394




 

Re: Announcing DNF 3 development

[Neal Gompa]

On Mon, Mar 26, 2018 at 11:02 AM, Vít Ondruch  wrote:
>
>
> Dne 26.3.2018 v 10:16 Tom Hughes napsal(a):
>> On 26/03/18 09:06, Marcin Juszkiewicz wrote:
>>> W dniu 22.03.2018 o 13:40, Daniel Mach pisze:
 We are pleased to announce that development of DNF 3 has started. This
 version is focused on performance improvements, new API and
 consolidating
 the whole software management stack.

 Please read more details on our blog:
 https://rpm-software-management.github.io/announcement/2018/03/22/dnf-3-announcement/

>>>
>>> Will it FINALLY use one copy of metadata for all system users?
>>
>> Do you have a proposal as to how that might be possible in a
>> secure way?
>
> If DNF was just frontend for some service/daemon, that would be one
> possibility. It would also help with other issues like updates of X
> server crashing whole user session and therefore the update.
>

It would be nice if dnfdaemon was actually merged into dnf itself, but
I'm not sure whether they'd consider it to be desirable or not.


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

Re: Announcing DNF 3 development

[Nicolas Mailhot]

Le lundi 26 mars 2018 à 17:02 +0200, Vít Ondruch a écrit :
> 
> If DNF was just frontend for some service/daemon, that would be one
> possibility. It would also help with other issues like updates of X
> server crashing whole user session and therefore the update.

Yes that would be pretty awesome

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

[Bug 1560548] perl-Test-PostgreSQL-1.25 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-Test-PostgreSQL-1.25-1.fc28 has been pushed to the Fedora 28 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-e0bb7ef67b

-- 
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: Announcing DNF 3 development

[Vít Ondruch]

Dne 26.3.2018 v 10:16 Tom Hughes napsal(a):
> On 26/03/18 09:06, Marcin Juszkiewicz wrote:
>> W dniu 22.03.2018 o 13:40, Daniel Mach pisze:
>>> We are pleased to announce that development of DNF 3 has started. This
>>> version is focused on performance improvements, new API and
>>> consolidating
>>> the whole software management stack.
>>>
>>> Please read more details on our blog:
>>> https://rpm-software-management.github.io/announcement/2018/03/22/dnf-3-announcement/
>>>
>>
>> Will it FINALLY use one copy of metadata for all system users?
>
> Do you have a proposal as to how that might be possible in a
> secure way?

If DNF was just frontend for some service/daemon, that would be one
possibility. It would also help with other issues like updates of X
server crashing whole user session and therefore the update.

V.


>
>> I do not see how fetching megabytes of metadata is better than using
>> copy present in /var/cache/dnf/ directory.
>
> Well it could just use the cached copy sure, but if it was out of
> date then it wouldn't be able to update it?
>
>> It is faster to enter long password to use sudo than to wait until dnf
>> fetch useless copy of metadata.
>
> Agreed, which is why I always run dnf under sudo even for query
> operations.
>
>> Debian has APT. APT uses one copy of metadata. Be wise. Like Debian.
>
> Do we know how? Do they just not allow non-root users to get up
> to date data, or do they do something cleverer?
>
> Tom
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1560322] perl-DateTime-1.47 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

-- 
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 1560173] perl-DateTime-TimeZone-2.18 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-DateTime-TimeZone-2.18-1.fc28 has been pushed to the Fedora 28 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-6b4f1d88d3

-- 
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: Orphaning ofono

[Rex Dieter]

Rex Dieter wrote:

> Artur Iwicki wrote:
> 
>> Hello, Rex.
>> 
>> Recently a new version of modem-manager-gui has been released. This new
>> release added an option to use ofono as the modem manager. I've updated
>> the mmgui package and ran into a problem where the rawhide [1] and F28
>> [2] builds succeed, but the F27 [3] and F26 [4] builds fail, as it seems
>> the latest ofono builds for these Fedoras didn't support all
>> architectures, so the mmgui build fails due to unsatisfied dependencies.
>> 
>> Would you possibly be willing to unretire ofono
> 
> I haven't retired it yet, and probably won't in the foreseeable future
> (yet).
> 
> I'm working on updating it for all fedora releases, and it should be
> available to build against soon.

builds submitted to bodhi as updates and overrides, so test and/or try 
rebuilding things now.

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

Fedora rawhide compose report: 20180326.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20180325.n.0
NEW: Fedora-Rawhide-20180326.n.0

= SUMMARY =
Added images:2
Dropped images:  0
Added packages:  5
Dropped packages:0
Upgraded packages:   52
Downgraded packages: 1

Size of added packages:  121.84 MiB
Size of dropped packages:0 B
Size of upgraded packages:   1.60 GiB
Size of downgraded packages: 228.35 KiB

Size change of upgraded packages:   -42.57 MiB
Size change of downgraded packages: 1.41 KiB

= ADDED IMAGES =
Image: Xfce live i386
Path: Spins/i386/iso/Fedora-Xfce-Live-i386-Rawhide-20180326.n.0.iso
Image: Minimal raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Minimal-Rawhide-20180326.n.0.aarch64.raw.xz

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: R-deldir-0.1.14-1.fc29
Summary: Delaunay Triangulation and Dirichlet (Voronoi) Tessellation
RPMs:R-deldir
Size:1.39 MiB

Package: R-processx-2.0.0.1-1.fc29
Summary: Execute and Control System Processes
RPMs:R-processx
Size:545.47 KiB

Package: falkon-3.0.0-3.fc29
Summary: Modern web browser
RPMs:falkon falkon-gnome-keyring falkon-kwallet
Size:9.55 MiB

Package: godot-3.0.2-1.fc29
Summary: Multi-platform 2D and 3D game engine with a feature-rich editor
RPMs:godot godot-runner godot-server
Size:110.14 MiB

Package: libb2-0.98-1.20171225git60ea749.fc29
Summary: C library providing BLAKE2b, BLAKE2s, BLAKE2bp, BLAKE2sp
RPMs:libb2 libb2-devel
Size:227.82 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  GitPython-2.1.9-1.fc29
Old package:  GitPython-2.1.8-2.fc28
Summary:  Python Git Library
RPMs: python2-GitPython python3-GitPython
Size: 1.10 MiB
Size change:  -3.28 KiB
Changelog:
  * Sun Mar 25 2018 Kevin Fenzi <ke...@scrye.com> - 2.1.9-1
  - Update to 2.9.1. Fixes bug #1560214


Package:  R-sp-1.2.7-1.fc29
Old package:  R-sp-1.2.5-5.fc28
Summary:  Classes and Methods for Spatial Data
RPMs: R-sp R-sp-devel
Size: 10.34 MiB
Size change:  6.55 KiB
Changelog:
  * Mon Mar 26 2018 Elliott Sales de Andrade <quantum.anal...@gmail.com> - 
1.2.7-1
  - Update to latest version.


Package:  R-tikzDevice-0.11-1.fc29
Old package:  R-tikzDevice-0.10.1-2.fc29
Summary:  R Graphics Output in LaTeX Format
RPMs: R-tikzDevice
Size: 4.21 MiB
Size change:  110.88 KiB
Changelog:
  * Sat Mar 24 2018 Elliott Sales de Andrade <quantum.anal...@gmail.com> - 
0.11-1
  - Update to latest version


Package:  adapta-gtk-theme-3.93.0.200-1.fc29
Old package:  adapta-gtk-theme-3.93.0.174-1.fc29
Summary:  An adaptive Gtk+ theme based on Material Design Guidelines
RPMs: adapta-gtk-theme adapta-gtk-theme-gedit adapta-gtk-theme-plank
Size: 1.66 MiB
Size change:  5.15 KiB
Changelog:
  * Sun Mar 25 2018 Bj??rn Esser <besse...@fedoraproject.org> - 3.93.0.200-1
  - New upstream release (#1554156)


Package:  autofs-1:5.1.4-16.fc29
Old package:  autofs-1:5.1.4-14.fc29
Summary:  A tool for automatically mounting and unmounting filesystems
RPMs: autofs
Size: 5.30 MiB
Size change:  10.84 KiB
Changelog:
  * Mon Mar 26 2018 Ian Kent <ik...@redhat.com> - 1:5.1.4-15
  - tiny patch for autofs typo and possible bug.
  - add units After line to include statd service.
  - use systemd sd_notify() at startup.
  - fix NFS version mask usage.
  - fix incorrect date in changelog.

  * Mon Mar 26 2018 Ian Kent <ik...@redhat.com> - 1:5.1.4-16
  - also add missing "BuildRequires: systemd-devel".


Package:  awscli-1.14.63-1.fc29
Old package:  awscli-1.14.62-1.fc29
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 1.04 MiB
Size change:  76 B
Changelog:
  * Sun Mar 25 2018 Kevin Fenzi <ke...@scrye.com> - 1.14.63-1
  - Update to 1.4.63. Fixes bug #1559367


Package:  ejabberd-18.1.0-2.fc29
Old package:  ejabberd-18.1.0-1.fc28
Summary:  A distributed, fault-tolerant Jabber/XMPP server
RPMs: ejabberd ejabberd-selinux
Size: 5.55 MiB
Size change:  -32.89 MiB
Changelog:
  * Sun Mar 25 2018 Randy Barlow <bowlofe...@fedoraproject.org> - 18.1.0-2
  - Convert to a noarch package.


Package:  enlightenment-0.22.3-1.fc29
Old package:  enlightenment-0.22.1-2.fc28
Summary:  Enlightenment window manager
RPMs: enlightenment enlightenment-data enlightenment-devel
Size: 37.60 MiB
Size change:  31.14 KiB
Changelog:
  * Sun Mar 25 2018 Tom Callaway <s...@fedoraproject.org> - 0.22.3-1
  - update to 0.22.3


Package:  erlang-base64url-1.0-3.fc29
Old package:  erlang-base64url-1.0-2.fc28
Summary:  URL safe base64-compatible codec
RPMs: erlang-base64url
Size: 11.26 KiB
Size change:  -66.33 KiB
Changelog:
  * Sun Mar 25 2018 Randy Barlow <bowlofe...@fedoraproject.org> - 1.0-3
  - Convert to a noarch package.


Package:  erlang-cache_tab-1.0.12-4.fc29
Old package:  erlang-cac

[389-devel] Please review: Ticket 49601 - Replace HAVE_SYSTEMD define with WITH_SYSTEMD in svrcore

[Matus Honek]

https://pagure.io/389-ds-base/issue/49601#comment-501820

https://pagure.io/389-ds-base/issue/raw/files/12f4095f8d725d76f60882d2a844a0e26ad20439a84e0bbdf3c9b34bd1bbd285-0001-Ticket-49601-Replace-HAVE_SYSTEMD-define-with-WITH_S.patch
-- 
Matus Honek
Associate Software Engineer
Red Hat Czech
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: Announcing DNF 3 development

[Neal Gompa]

On Mon, Mar 26, 2018 at 9:58 AM, Martin Sehnoutka  wrote:
>
>
> On 03/26/2018 02:30 PM, Neal Gompa wrote:
>> On Mon, Mar 26, 2018 at 8:26 AM, Martin Sehnoutka  
>> wrote:
>>>
>>>
>>> On 03/26/2018 01:38 PM, Neal Gompa wrote:
 On Mon, Mar 26, 2018 at 7:22 AM, Matěj Cepl  wrote:
> On 2018-03-26, 10:52 GMT, Florian Weimer wrote:
>> On 03/22/2018 01:40 PM, Daniel Mach wrote:
>>> Please read more details on our blog:
>>> https://rpm-software-management.github.io/announcement/2018/03/22/dnf-3-announcement/
>>
>> “C++ 11 is supported by GCC in RHEL 7 / CentOS 7” — You should
>> use Developer Toolset to compile on Red Hat Enterprise Linux
>> 7 if you need C++11 support.  The system compiler, GCC 4.8,
>> has limited support only.
>
> When switching the programming langauge than I would think there
> are some better C-successors than C++, namely Rust? Mad rush of
> giving up on 46 years old language and switching to one which is
> just 33 years old seems a bit bizarre to me.
>
>>>
>>> Take a look into the code, it is mostly C with few features from C++.
>>>
>>> btw what is the motivation to use GOBjects? Is the libdnf api supposed
>>> to be consumed by dnf frontend via gi repository?
>>>
>>
>> It was a thought a while ago with libhif, and as part of the final
>> rationalization for libdnf, it's being dropped. Because libdnf is
>> going to be in C++, it's going to use SWIG for bindings generation.
>>
>
> Thanks for clarification.
>

 I'm okay with not dealing with LLVM for my system package manager,
 thank you very much. I'd be more open to Rust if Rust also could be
 built with GCC, and thus supported across literally everything, but no
 one is investing in that effort.

>>>
>>> Well, investment like this will need some justification, not saying that
>>> dnf should be the one, but you will definitely need a big, important
>>> project.
>>>
>>
>> Considering all the other "big important things" people don't invest
>> in anyway, I don't think that'd help any.
>>
 And frankly, Rust is harder to program in than C++, and creating
 bindings is no walk in the park.

>>>
>>> Purely personal opinion. You are probably referring to the learning
>>> curve, which is known to be steep, but after this period it is well
>>> worth the effort.
>>>
>>
>> Not my personal opinion. That's the opinion of several developers I
>> know who are working on Rust based projects. Not everyone gets the
>> benefit of GNOME forcing all the things so that stuff _must_ work.
>>
>
> I don't really get the last sentence. What is GNOME forcing a what must
> work?
>

Basically, when you work outside of the GNOME ecosystem, things get
much harder because you can't guarantee everything interfaces through
GObject and other stuff like it.


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

Re: Announcing DNF 3 development

[Martin Sehnoutka]

On 03/26/2018 02:30 PM, Neal Gompa wrote:
> On Mon, Mar 26, 2018 at 8:26 AM, Martin Sehnoutka  wrote:
>>
>>
>> On 03/26/2018 01:38 PM, Neal Gompa wrote:
>>> On Mon, Mar 26, 2018 at 7:22 AM, Matěj Cepl  wrote:
 On 2018-03-26, 10:52 GMT, Florian Weimer wrote:
> On 03/22/2018 01:40 PM, Daniel Mach wrote:
>> Please read more details on our blog:
>> https://rpm-software-management.github.io/announcement/2018/03/22/dnf-3-announcement/
>
> “C++ 11 is supported by GCC in RHEL 7 / CentOS 7” — You should
> use Developer Toolset to compile on Red Hat Enterprise Linux
> 7 if you need C++11 support.  The system compiler, GCC 4.8,
> has limited support only.

 When switching the programming langauge than I would think there
 are some better C-successors than C++, namely Rust? Mad rush of
 giving up on 46 years old language and switching to one which is
 just 33 years old seems a bit bizarre to me.

>>
>> Take a look into the code, it is mostly C with few features from C++.
>>
>> btw what is the motivation to use GOBjects? Is the libdnf api supposed
>> to be consumed by dnf frontend via gi repository?
>>
> 
> It was a thought a while ago with libhif, and as part of the final
> rationalization for libdnf, it's being dropped. Because libdnf is
> going to be in C++, it's going to use SWIG for bindings generation.
> 

Thanks for clarification.

>>>
>>> I'm okay with not dealing with LLVM for my system package manager,
>>> thank you very much. I'd be more open to Rust if Rust also could be
>>> built with GCC, and thus supported across literally everything, but no
>>> one is investing in that effort.
>>>
>>
>> Well, investment like this will need some justification, not saying that
>> dnf should be the one, but you will definitely need a big, important
>> project.
>>
> 
> Considering all the other "big important things" people don't invest
> in anyway, I don't think that'd help any.
> 
>>> And frankly, Rust is harder to program in than C++, and creating
>>> bindings is no walk in the park.
>>>
>>
>> Purely personal opinion. You are probably referring to the learning
>> curve, which is known to be steep, but after this period it is well
>> worth the effort.
>>
> 
> Not my personal opinion. That's the opinion of several developers I
> know who are working on Rust based projects. Not everyone gets the
> benefit of GNOME forcing all the things so that stuff _must_ work.
> 

I don't really get the last sentence. What is GNOME forcing a what must
work?

>> Regarding the bindings, if libdnf is meant to be used via gir (see my
>> question above), then there is already an effort to make this much
>> easier (I'm referring to gnome-class).
>>
> 
> As I noted earlier in this email, gir is a leftover and is being removed.
> 

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



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

[Bug 1560218] perl-MooX-StrictConstructor-0.010 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-MooX-StrictConstructor
   ||-0.010-1.fc29
 Resolution|--- |RAWHIDE
Last Closed||2018-03-26 09:57:14



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

Trouble with Waivers

[Michael Cronenworth]

I have attempted to create waivers for two updates, but they are still unable to be 
pushed. What have I done wrong?


https://bodhi.fedoraproject.org/updates/FEDORA-2018-c5a0e704d6
https://bodhi.fedoraproject.org/updates/FEDORA-2018-ec1108333e

$ waiverdb-cli -t dist.rpmdeplint -s '{"item": "wine-3.4-1.fc28", "type": 
"koji_build"}' -p "fedora-28" -c "This is fine"
Created waiver 94 for result with subject {"item": "wine-3.4-1.fc28", "type": 
"koji_build"} and testcase dist.rpmdeplint

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

orphaned sonar

[Michael Šimáček]

Hi,

I've orphaned sonar and related packages:
sonar
sonar-plugins-parent
sonar-runner
sonar-update-center

They used to be a dependency of gradle, but nothing depends on them now. 
They're severely outdated.


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

[Bug 1560548] perl-Test-PostgreSQL-1.25 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-Test-PostgreSQL-1.25-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-028fdd9656

-- 
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 1560548] perl-Test-PostgreSQL-1.25 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Test-PostgreSQL-1.25-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-e0bb7ef67b

-- 
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 1560548] perl-Test-PostgreSQL-1.25 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-Test-PostgreSQL-1.25-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-b00d6c4a29

-- 
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 1560548] perl-Test-PostgreSQL-1.25 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Test-PostgreSQL-1.25-1
   ||.fc29



--- Comment #1 from Petr Pisar  ---
A mix of fixes and enhancements. I hope it's safe for all Fedoras.

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

Re: Announcing DNF 3 development

[Neal Gompa]

On Mon, Mar 26, 2018 at 8:26 AM, Martin Sehnoutka  wrote:
>
>
> On 03/26/2018 01:38 PM, Neal Gompa wrote:
>> On Mon, Mar 26, 2018 at 7:22 AM, Matěj Cepl  wrote:
>>> On 2018-03-26, 10:52 GMT, Florian Weimer wrote:
 On 03/22/2018 01:40 PM, Daniel Mach wrote:
> Please read more details on our blog:
> https://rpm-software-management.github.io/announcement/2018/03/22/dnf-3-announcement/

 “C++ 11 is supported by GCC in RHEL 7 / CentOS 7” — You should
 use Developer Toolset to compile on Red Hat Enterprise Linux
 7 if you need C++11 support.  The system compiler, GCC 4.8,
 has limited support only.
>>>
>>> When switching the programming langauge than I would think there
>>> are some better C-successors than C++, namely Rust? Mad rush of
>>> giving up on 46 years old language and switching to one which is
>>> just 33 years old seems a bit bizarre to me.
>>>
>
> Take a look into the code, it is mostly C with few features from C++.
>
> btw what is the motivation to use GOBjects? Is the libdnf api supposed
> to be consumed by dnf frontend via gi repository?
>

It was a thought a while ago with libhif, and as part of the final
rationalization for libdnf, it's being dropped. Because libdnf is
going to be in C++, it's going to use SWIG for bindings generation.

>>
>> I'm okay with not dealing with LLVM for my system package manager,
>> thank you very much. I'd be more open to Rust if Rust also could be
>> built with GCC, and thus supported across literally everything, but no
>> one is investing in that effort.
>>
>
> Well, investment like this will need some justification, not saying that
> dnf should be the one, but you will definitely need a big, important
> project.
>

Considering all the other "big important things" people don't invest
in anyway, I don't think that'd help any.

>> And frankly, Rust is harder to program in than C++, and creating
>> bindings is no walk in the park.
>>
>
> Purely personal opinion. You are probably referring to the learning
> curve, which is known to be steep, but after this period it is well
> worth the effort.
>

Not my personal opinion. That's the opinion of several developers I
know who are working on Rust based projects. Not everyone gets the
benefit of GNOME forcing all the things so that stuff _must_ work.

> Regarding the bindings, if libdnf is meant to be used via gir (see my
> question above), then there is already an effort to make this much
> easier (I'm referring to gnome-class).
>

As I noted earlier in this email, gir is a leftover and is being removed.

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

Re: Announcing DNF 3 development

[Martin Kolman]

On Mon, 2018-03-26 at 13:22 +0200, Matěj Cepl wrote:
> On 2018-03-26, 10:52 GMT, Florian Weimer wrote:
> > On 03/22/2018 01:40 PM, Daniel Mach wrote:
> > > Please read more details on our blog:
> > > https://rpm-software-management.github.io/announcement/2018/03/22/dnf-3-announcement/
> > 
> > “C++ 11 is supported by GCC in RHEL 7 / CentOS 7” — You should 
> > use Developer Toolset to compile on Red Hat Enterprise Linux 
> > 7 if you need C++11 support.  The system compiler, GCC 4.8, 
> > has limited support only.
> 
> When switching the programming langauge than I would think there 
> are some better C-successors than C++, namely Rust? Mad rush of 
> giving up on 46 years old language and switching to one which is 
> just 33 years old seems a bit bizarre to me.
I think it is not bad to be a bit conservative when core system components
are concerned.

> 
> Best,
> 
> Matěj
> -- 
> https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
> GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
>  
> I am a Roman Catholic, so that I do not expect `history' to be
> anything but a `long defeat' -- though it contains (and in
> a legend may contain more clearly and movingly) some samples or
> glimpses of final victory.
>   -- J.R.R. Tolkien
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1560548] New: perl-Test-PostgreSQL-1.25 is available

[bugzilla]

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

Bug ID: 1560548
   Summary: perl-Test-PostgreSQL-1.25 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Test-PostgreSQL
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 1.25
Current version/release in rawhide: 1.24-1.fc29
URL: http://search.cpan.org/dist/Test-PostgreSQL/

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

-- 
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: Announcing DNF 3 development

[Martin Sehnoutka]

On 03/26/2018 01:38 PM, Neal Gompa wrote:
> On Mon, Mar 26, 2018 at 7:22 AM, Matěj Cepl  wrote:
>> On 2018-03-26, 10:52 GMT, Florian Weimer wrote:
>>> On 03/22/2018 01:40 PM, Daniel Mach wrote:
 Please read more details on our blog:
 https://rpm-software-management.github.io/announcement/2018/03/22/dnf-3-announcement/
>>>
>>> “C++ 11 is supported by GCC in RHEL 7 / CentOS 7” — You should
>>> use Developer Toolset to compile on Red Hat Enterprise Linux
>>> 7 if you need C++11 support.  The system compiler, GCC 4.8,
>>> has limited support only.
>>
>> When switching the programming langauge than I would think there
>> are some better C-successors than C++, namely Rust? Mad rush of
>> giving up on 46 years old language and switching to one which is
>> just 33 years old seems a bit bizarre to me.
>>

Take a look into the code, it is mostly C with few features from C++.

btw what is the motivation to use GOBjects? Is the libdnf api supposed
to be consumed by dnf frontend via gi repository?

> 
> I'm okay with not dealing with LLVM for my system package manager,
> thank you very much. I'd be more open to Rust if Rust also could be
> built with GCC, and thus supported across literally everything, but no
> one is investing in that effort.
> 

Well, investment like this will need some justification, not saying that
dnf should be the one, but you will definitely need a big, important
project.

> And frankly, Rust is harder to program in than C++, and creating
> bindings is no walk in the park.
> 

Purely personal opinion. You are probably referring to the learning
curve, which is known to be steep, but after this period it is well
worth the effort.

Regarding the bindings, if libdnf is meant to be used via gir (see my
question above), then there is already an effort to make this much
easier (I'm referring to gnome-class).

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



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

[Bug 1560532] New: perl-Devel-NYTProf-6.05 is available

[bugzilla]

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

Bug ID: 1560532
   Summary: perl-Devel-NYTProf-6.05 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Devel-NYTProf
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 6.05
Current version/release in rawhide: 6.04-7.fc28
URL: http://search.cpan.org/dist/Devel-NYTProf/

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

-- 
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 1560322] perl-DateTime-1.47 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-DateTime-1.47-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-455e277f36

-- 
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: Announcing DNF 3 development

[Neal Gompa]

On Mon, Mar 26, 2018 at 7:22 AM, Matěj Cepl  wrote:
> On 2018-03-26, 10:52 GMT, Florian Weimer wrote:
>> On 03/22/2018 01:40 PM, Daniel Mach wrote:
>>> Please read more details on our blog:
>>> https://rpm-software-management.github.io/announcement/2018/03/22/dnf-3-announcement/
>>
>> “C++ 11 is supported by GCC in RHEL 7 / CentOS 7” — You should
>> use Developer Toolset to compile on Red Hat Enterprise Linux
>> 7 if you need C++11 support.  The system compiler, GCC 4.8,
>> has limited support only.
>
> When switching the programming langauge than I would think there
> are some better C-successors than C++, namely Rust? Mad rush of
> giving up on 46 years old language and switching to one which is
> just 33 years old seems a bit bizarre to me.
>

I'm okay with not dealing with LLVM for my system package manager,
thank you very much. I'd be more open to Rust if Rust also could be
built with GCC, and thus supported across literally everything, but no
one is investing in that effort.

And frankly, Rust is harder to program in than C++, and creating
bindings is no walk in the park.


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

Re: josm orphaned

[Jakub Jelen]

On Sun, 2018-03-25 at 19:39 -0300, Ricardo Martinelli Oliveira wrote:
> Jakub,
> 
> Can we discuss tomorrow about the package? I'd love to be
> co-maintainer since I use josm frequently.

Hello,
thank you for the interest. I already put together a PR which makes it
building and working for me with latest stable release:

https://src.fedoraproject.org/rpms/josm/pull-request/1

I could use a review of the changes, if they make sense for you or
there are things to improve/change/do other way. This is my first java
package. Feel free to use the Pull request comments to keep it of this
(already flooded list).

Thanks,
Jakub

> On Sun, Mar 25, 2018 at 5:46 PM, Jakub Jelen 
> wrote:
> > Hello,
> > I would like take the package, but other co-maintainers are always
> > welcomed. I filled the following rel-eng ticket:
> > 
> > https://pagure.io/releng/issue/7409
> > 
> > Regards,
> > Jakub
> > ___
> > 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
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Announcing DNF 3 development

[Matěj Cepl]

On 2018-03-26, 10:52 GMT, Florian Weimer wrote:
> On 03/22/2018 01:40 PM, Daniel Mach wrote:
>> Please read more details on our blog:
>> https://rpm-software-management.github.io/announcement/2018/03/22/dnf-3-announcement/
>
> “C++ 11 is supported by GCC in RHEL 7 / CentOS 7” — You should 
> use Developer Toolset to compile on Red Hat Enterprise Linux 
> 7 if you need C++11 support.  The system compiler, GCC 4.8, 
> has limited support only.

When switching the programming langauge than I would think there 
are some better C-successors than C++, namely Rust? Mad rush of 
giving up on 46 years old language and switching to one which is 
just 33 years old seems a bit bizarre to me.

Best,

Matěj
-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
I am a Roman Catholic, so that I do not expect `history' to be
anything but a `long defeat' -- though it contains (and in
a legend may contain more clearly and movingly) some samples or
glimpses of final victory.
  -- J.R.R. Tolkien
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Announcing DNF 3 development

[Florian Weimer]

On 03/22/2018 01:40 PM, Daniel Mach wrote:

We are pleased to announce that development of DNF 3 has started. This
version is focused on performance improvements, new API and consolidating
the whole software management stack.

Please read more details on our blog:
https://rpm-software-management.github.io/announcement/2018/03/22/dnf-3-announcement/


“C++ 11 is supported by GCC in RHEL 7 / CentOS 7” — You should use 
Developer Toolset to compile on Red Hat Enterprise Linux 7 if you need 
C++11 support.  The system compiler, GCC 4.8, has limited support only.


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

[Bug 1560253] perl-App-cpm-0.963 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-App-cpm-0.963-1.fc29
 Resolution|--- |RAWHIDE
Last Closed||2018-03-26 06:18:16



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

F29 System Wide Change: Ruby on Rails 5.2

[Jan Kurik]

= Proposed System Wide Change: Ruby on Rails 5.2 =
https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_5.2


Owner(s):
  * Pavel Valena 
  * Vít Ondruch 
  * Jun Aruga 


Ruby on Rails 5.2 is the latest version of well known web framework
written in Ruby.



== Detailed description ==
The Ruby on Rails stack is evolving quickly and Fedora needs to keep
pace with it. Therefore the whole Ruby on Rails stack should be
updated from 5.1 in Fedora 28 to 5.2 (latest version) in Fedora 29.
This will ensure that all the Ruby developers using Fedora have the
latest and greatest RPM-packaged Ruby on Rails.


== Scope ==
* Proposal owners:
** The whole Rails stack has to be updated
** Some dependencies of the Rails stack will need update
=== Packages need to be created/updated ===
- rubygem-activestorage - Create package
- rubygem-actioncable - Update to 5.2.x
- rubygem-actionmailer - Update to 5.2.x
- rubygem-actionpack - Update to 5.2.x
- rubygem-actionview - Update to 5.2.x
- rubygem-activejob - Update to 5.2.x
- rubygem-activemodel - Update to 5.2.x
- rubygem-activerecord - Update to 5.2.x
- rubygem-activesupport - Update to 5.2.x
- rubygem-rails - Update to 5.2.x
- rubygem-railties - Update to 5.2.x
- rubygem-arel - Update to 9.0.x

* Other developers:
Update Rails dependent packages to be working with Ruby on Rails 5.2

* Release engineering:
#7410 https://pagure.io/releng/issue/7410

**List of deliverables:
None

* Policies and guidelines:
Not needed

* Trademark approval:
Not needed
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F29 System Wide Change: Ruby on Rails 5.2

[Jan Kurik]

= Proposed System Wide Change: Ruby on Rails 5.2 =
https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_5.2


Owner(s):
  * Pavel Valena 
  * Vít Ondruch 
  * Jun Aruga 


Ruby on Rails 5.2 is the latest version of well known web framework
written in Ruby.



== Detailed description ==
The Ruby on Rails stack is evolving quickly and Fedora needs to keep
pace with it. Therefore the whole Ruby on Rails stack should be
updated from 5.1 in Fedora 28 to 5.2 (latest version) in Fedora 29.
This will ensure that all the Ruby developers using Fedora have the
latest and greatest RPM-packaged Ruby on Rails.


== Scope ==
* Proposal owners:
** The whole Rails stack has to be updated
** Some dependencies of the Rails stack will need update
=== Packages need to be created/updated ===
- rubygem-activestorage - Create package
- rubygem-actioncable - Update to 5.2.x
- rubygem-actionmailer - Update to 5.2.x
- rubygem-actionpack - Update to 5.2.x
- rubygem-actionview - Update to 5.2.x
- rubygem-activejob - Update to 5.2.x
- rubygem-activemodel - Update to 5.2.x
- rubygem-activerecord - Update to 5.2.x
- rubygem-activesupport - Update to 5.2.x
- rubygem-rails - Update to 5.2.x
- rubygem-railties - Update to 5.2.x
- rubygem-arel - Update to 9.0.x

* Other developers:
Update Rails dependent packages to be working with Ruby on Rails 5.2

* Release engineering:
#7410 https://pagure.io/releng/issue/7410

**List of deliverables:
None

* Policies and guidelines:
Not needed

* Trademark approval:
Not needed
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Petr Viktorin]

On 03/24/18 15:28, Kevin Kofler wrote:

Petr Viktorin wrote:

As with any orphaning, that leaves two options:
- someone else agrees now to take over in 2020 (keeping in mind this is
a security-critical package and will be abandoned upstream), or


IMHO, this is clearly the right thing to do. I have been doing security
backports for qt3 and kdelibs3 for years, and now also qt 4 and kdelibs 4.
It is not an unreasonable amount of work, though to be very clear I will NOT
be the one to do this for Python 2, somebody experienced with and interested
in Python should do it.


And if you read the original mail to the end, you'll find that our 
position is not as black-and-white as it might look from the Subject line.
As Python SIG we maintain old Python versions like 2.6 or 3.3 *today* – 
but just for developers who need to test backwards compatibility of 
their upstream libraries; we don't want to see them used as a base for 
Fedora packages. Why? To make sure Fedora packages work with modern 
Python, and to have only one time-sensitive place to concentrate on when 
a critical security fix comes. We want to put Python 2.7 in the same 
situation.


Part of the reason to start dropping Python 2 packages now is to figure 
out which packages can do it now and which ones will need additional 
help or coordination in the next few years.


As I wrote in the beginning of the e-mail, we'd rather go out and change 
the packaging guidelines to say "please drop your unneeded python2 
subpackages, or let us drop them for you". (Note the word *unneeded*.) 
That would make a nice a simple message, and in effect it would give you 
the same options you have now.
But it turns out we can't say just that (for good reasons [0]), so we're 
explicitly mentioning your second option – "if you can manage the 
transition better, come and do it instead of us".
I doubt anyone can – Python SIG is, by definition, the people 
experienced with and interested in packaging Python in Fedora. And yes, 
we'll do our best to manage things, with cooperation with interested 
packagers.


There's of course a third option – if you don't want to take over 
*everything* but have ideas about how to do something better – 
respecting that if you're asking someone to do more work, they might (or 
might not) say no – then come over to Python SIG [1] and talk!


And let me mention this one explicitly: expecting us to maintain Python 
2 *is* implicitly asking us to do work. It's not necessarily bad per se, 
but don't complain if we ask you to do some work in return.

We'll be glad to help anyone who respects that.


[0] https://pagure.io/packaging-committee/issue/753
[1] https://fedoraproject.org/wiki/SIGs/Python



Especially for the first couple years, it will be possible to just borrow
fixes from other distros, in particular RHEL/CentOS. As was pointed out
elsewhere in this thread, EL7 ships Python 2.7 and should be supported until
2024. (That said, RHEL typically only fixes the really critical issues. My
experience with qt3 and kdelibs3 is that RHEL was not always proactive in
backporting security fixes and sometimes even ended up picking up my Fedora
fix, weeks later. But there are also other distros around.)

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


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

[Bug 1560220] perl-String-CamelCase-0.04 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-String-CamelCase-0.04-
   ||1.fc29
 Resolution|--- |RAWHIDE
Last Closed||2018-03-26 05:13:18



-- 
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 1560173] perl-DateTime-TimeZone-2.18 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-DateTime-TimeZone-2.18-1.fc26 has been submitted as an update to Fedora
26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-eb0ef2180d

-- 
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 1560173] perl-DateTime-TimeZone-2.18 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

   Fixed In Version||perl-DateTime-TimeZone-2.18
   ||-1.fc29



-- 
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 1560182] Concurrent Gtk2::Unique execution causes shutter to crash

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

   Keywords||Patch



--- Comment #3 from Petr Pisar  ---
I confirm that the bug is reproducible in Fedora 27 and that it the patch fixes
it. I hope this Fedora packages maintainer will apply it soon. Otherwise I will
do it.

-- 
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 1560173] perl-DateTime-TimeZone-2.18 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-DateTime-TimeZone-2.18-1.fc27 has been submitted as an update to Fedora
27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-12382064dc

-- 
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: Announcing DNF 3 development

[Jonathan Dieter]

On Mon, 2018-03-26 at 11:44 +0300, Jonathan Dieter wrote:
> I've been working on zchunk which will allow downloading only the delta
>  of the metadata.

For reference, the proposal starts at http://lists.rpm.org/pipermail/rp
m-ecosystem/2018-February/000534.html.

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

Re: Announcing DNF 3 development

[Benjamin Kircher]

> On 26. Mar 2018, at 10:39, Oron Peled  wrote:
> 
> On Monday, 26 March 2018 11:16:14 IDT Tom Hughes wrote:
>> On 26/03/18 09:06, Marcin Juszkiewicz wrote:
>>> Debian has APT. APT uses one copy of metadata. Be wise. Like Debian.
>> 
>> Do we know how? Do they just not allow non-root users to get up
>> to date data, or do they do something cleverer?
> 
> With APT, cache update and using the cache are orthogonal operations:
> * Running "apt-get update" is privileged and update the cache.
> * There's obviously an optional service to run "apt-get update" periodically 
> if root prefer this mechanism.
> * Doing just query (e.g: apt list ...) always use latest cache data.
> * So query by root or any user are the same -- no privileged and work on the 
> cache (which may/may-not be updated).

Question: Would splitting-up cache update and package upgrade operations worth 
considering for dnf 3.0?


(As a long time CentOS, Fedora user I am always envious at how snappy (no pun 
intended) apt-get update && apt-get upgrade feel when I get my hands on one of 
these :-)

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

Re: Announcing DNF 3 development

[Jonathan Dieter]

On Mon, 2018-03-26 at 09:30 +0100, Richard Hughes wrote:
> With version 3.0 dnf is switching to the codebase we originally wrote
> for PackageKit (libzif->libhif->libdnf), and so it inherits the
> "download complete cache and switch atomically" logic. This means we
> get a shared cache for free.

I've been working on zchunk which will allow downloading only the delta
 of the metadata.  AIUI, currently dnf uses librepo to download the
metadata, so that's where I was planning to do the zchunk integration. 
Is there somewhere else I should be looking at for dnf 3.0, or is it
still using librepo to do the actual downloads?

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

[Bug 1560173] perl-DateTime-TimeZone-2.18 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-DateTime-TimeZone-2.18-1.fc28 has been submitted as an update to Fedora
28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-6b4f1d88d3

-- 
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: Announcing DNF 3 development

[Oron Peled]

On Monday, 26 March 2018 11:16:14 IDT Tom Hughes wrote:
> On 26/03/18 09:06, Marcin Juszkiewicz wrote:
> > Debian has APT. APT uses one copy of metadata. Be wise. Like Debian.
> 
> Do we know how? Do they just not allow non-root users to get up
> to date data, or do they do something cleverer?

With APT, cache update and using the cache are orthogonal operations:
 * Running "apt-get update" is privileged and update the cache.
 * There's obviously an optional service to run "apt-get update" periodically 
if root prefer this mechanism.
 * Doing just query (e.g: apt list ...) always use latest cache data.
 * So query by root or any user are the same -- no privileged and work on the 
cache (which may/may-not be updated).


KISS,

-- 
Oron Peled Voice: +972-4-8228492

May the Source be with you!


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

Re: Announcing DNF 3 development

[Tom Hughes]

On 26/03/18 09:30, Richard Hughes wrote:

On 26 March 2018 at 09:16, Tom Hughes  wrote:

Will it FINALLY use one copy of metadata for all system users?

Do you have a proposal as to how that might be possible in a
secure way?


I think he means removing the duplication of the cache between
PackageKit and dnf. The former only uses a separate cache as it
updates the cache all at one, and switches to new versions atomically
so applications like gnome-software can always run transactions with
known latencies. dnf (the command line tool) only downloaded the
metadata files it needed for the current request, and so it could be
you had to start downloading something like the filelists when you
actually depsolved a transaction (which is somewhat incompatible with
offline updates for instance).


Well that's an issue as well, but he specifically referred to the
per-user caching behaviour of dnf and the need to run it under sudo
to use the system cache instead of building a new one.

In other words if I do "dnf search foo" as myself it will fetch a
new cache from scratch into /tmp instead of using the system one.

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

Re: Announcing DNF 3 development

[Marcin Juszkiewicz]

W dniu 26.03.2018 o 10:16, Tom Hughes pisze:
> On 26/03/18 09:06, Marcin Juszkiewicz wrote:

>> Will it FINALLY use one copy of metadata for all system users?
> 
> Do you have a proposal as to how that might be possible in a
> secure way?

Use. Not download. And inform (like always) how old that data is.

>> I do not see how fetching megabytes of metadata is better than using
>> copy present in /var/cache/dnf/ directory.
> 
> Well it could just use the cached copy sure, but if it was out of
> date then it wouldn't be able to update it?

Then it is out-of-date. But still is. And not everyone runs rawhide to
make it a difference when metadata is few days old.

>> It is faster to enter long password to use sudo than to wait until dnf
>> fetch useless copy of metadata.
> 
> Agreed, which is why I always run dnf under sudo even for query
> operations.

I hate having to do that. Also dislike fact that if I do not do that
then have to wait and wait and wait until it finally fetch metadata to
show me result.

DNF started as user can not install packages so why it can not just use
systemwide metadata?

>> Debian has APT. APT uses one copy of metadata. Be wise. Like Debian.
> 
> Do we know how? Do they just not allow non-root users to get up
> to date data, or do they do something cleverer?

APT has separate command for updating metadata. YUM/DNF tries to do that
every time they think that metadata is too old.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Announcing DNF 3 development

[Richard Hughes]

On 26 March 2018 at 09:16, Tom Hughes  wrote:
>> Will it FINALLY use one copy of metadata for all system users?
> Do you have a proposal as to how that might be possible in a
> secure way?

I think he means removing the duplication of the cache between
PackageKit and dnf. The former only uses a separate cache as it
updates the cache all at one, and switches to new versions atomically
so applications like gnome-software can always run transactions with
known latencies. dnf (the command line tool) only downloaded the
metadata files it needed for the current request, and so it could be
you had to start downloading something like the filelists when you
actually depsolved a transaction (which is somewhat incompatible with
offline updates for instance).

With version 3.0 dnf is switching to the codebase we originally wrote
for PackageKit (libzif->libhif->libdnf), and so it inherits the
"download complete cache and switch atomically" logic. This means we
get a shared cache for free.

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

[Bug 1560182] Concurrent Gtk2::Unique execution causes shutter to crash

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

Summary|The version of  |Concurrent Gtk2::Unique
   |perl-Gtk2-Unique is out of  |execution causes shutter to
   |date, causing shutter to|crash
   |crash   |



-- 
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: Announcing DNF 3 development

[Tom Hughes]

On 26/03/18 09:06, Marcin Juszkiewicz wrote:

W dniu 22.03.2018 o 13:40, Daniel Mach pisze:

We are pleased to announce that development of DNF 3 has started. This
version is focused on performance improvements, new API and consolidating
the whole software management stack.

Please read more details on our blog:
https://rpm-software-management.github.io/announcement/2018/03/22/dnf-3-announcement/


Will it FINALLY use one copy of metadata for all system users?


Do you have a proposal as to how that might be possible in a
secure way?


I do not see how fetching megabytes of metadata is better than using
copy present in /var/cache/dnf/ directory.


Well it could just use the cached copy sure, but if it was out of
date then it wouldn't be able to update it?


It is faster to enter long password to use sudo than to wait until dnf
fetch useless copy of metadata.


Agreed, which is why I always run dnf under sudo even for query
operations.


Debian has APT. APT uses one copy of metadata. Be wise. Like Debian.


Do we know how? Do they just not allow non-root users to get up
to date data, or do they do something cleverer?

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

Re: Announcing DNF 3 development

[Marcin Juszkiewicz]

W dniu 22.03.2018 o 13:40, Daniel Mach pisze:
> We are pleased to announce that development of DNF 3 has started. This
> version is focused on performance improvements, new API and consolidating
> the whole software management stack.
> 
> Please read more details on our blog:
> https://rpm-software-management.github.io/announcement/2018/03/22/dnf-3-announcement/

Will it FINALLY use one copy of metadata for all system users?

I do not see how fetching megabytes of metadata is better than using
copy present in /var/cache/dnf/ directory.

It is faster to enter long password to use sudo than to wait until dnf
fetch useless copy of metadata.

10:01 (1s) hrw@puchatek:~$ LANGUAGE=C LANG=C COLUMNS=60  dnf list nano
Spotify (negativo17) 31 kB/s |  11 kB 00:00
Fedora 27 - x86_64 - Update 8.4 MB/s |  21 MB 00:02
Fedora 27 - x86_64   15 MB/s |  58 MB 00:03
Google Chrome (stable)   57 kB/s | 3.7 kB 00:00
google-earth 72 kB/s | 4.7 kB 00:00
RPM Fusion for Fedora 27 -  984 kB/s | 351 kB 00:00
RPM Fusion for Fedora 27 -  1.3 MB/s | 717 kB 00:00
RPM Fusion for Fedora 27 -   50 kB/s |  87 kB 00:01
RPM Fusion for Fedora 27 -  128 kB/s | 163 kB 00:01
Skype Repository 40 kB/s | 1.8 kB 00:00
Last metadata expiration check: 0:00:00 ago on Mon Mar 26 10:03:01 2018.
Available Packages
nano.x86_64   2.8.7-1.fc27fedora
10:02 (40s) hrw@puchatek:~$

40 seconds just because of good download speed.


Debian has APT. APT uses one copy of metadata. Be wise. Like Debian.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1559196] perl-DBIx-Class-Schema-Loader-0.07049 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-DBIx-Class-Schema-Load
   ||er-0.07049-1.fc29
 Resolution|--- |RAWHIDE
Last Closed||2018-03-26 03:57:32



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

[EPEL-devel] Re: yum does not find a package that I submitted to EPEL7 stable

[Germano Massullo]

Il 25/03/2018 00:24, Jason L Tibbitts III ha scritto:
> The package should appear in the repositories with the next EPEL7
> compose.
>
>  - J<
>
Thank you Jason, when next EPEL7 compose will happen?
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[Bug 1560182] The version of perl-Gtk2-Unique is out of date, causing shutter to crash

[bugzilla]

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



--- Comment #2 from 40898...@opayq.com ---
Yes, indeed, the version is uptodate, but it has this bug which imo should be
patched with the patch that you refered to.

-- 
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 1560182] The version of perl-Gtk2-Unique is out of date, causing shutter to crash

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 CC||ppi...@redhat.com
External Bug ID||CPAN 120115



--- Comment #1 from Petr Pisar  ---
perl-Gtk2-Unique version is 0.05 in Fedora 27
. Latest
upstream version is 0.05 . It's
definitely not out-dated.

Aren't you more after including patch for Gtk2-Unique bug
?

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