date:20140621



Am 21.06.2014 03:03, schrieb Dan Williams:
 On Fri, 2014-06-20 at 23:27 +0200, poma wrote:
 This is super duper, however if wwan is on the router as Ranhald wrote, you 
 can only click your heels three times and repeat, There's no place like 
 home.
 
 Certainly.  But that doesn't mean we shouldn't try to fix 50%, even if
 we can't achieve the stars.  So I think there's a ton of value in doing
 this despite the fact that we can't be perfect

stop the automatic bandwidth wasting at all and you don't
have to fix anything - don't you realize that this 50% are
the ones with the slow WAN and the ones with fast internet
don't need prefetch of metadata at all?

at least stop todo that as default

where are the times gone people made smart decisions instead
try to make everybody happy and be it with wrong technical
decisions - that won't lead to a Linux marketshare of 90%
and it's disgusting professionals




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: pam_script review

2014-06-21 Thread Lubomir Rintel

On Sat, 2014-06-21 at 01:12 +, Jason Taylor wrote:
 Hi Lubomir,
 
 Thank you for the information! As suggested, I took a look at a couple of 
 package submissions.
 
 https://bugzilla.redhat.com/show_bug.cgi?id=692
 
 https://bugzilla.redhat.com/show_bug.cgi?id=691
 
 https://bugzilla.redhat.com/show_bug.cgi?id=689
 
 Any tips/hints regarding reviews are appreciated!

Please don't top-post here :)

The reviews look fine, and so does your package. I'll be doing a
complete review shortly.

Thank you.
Lubo

 
 Regards,
 
 JT
 
 From: devel-boun...@lists.fedoraproject.org 
 [devel-boun...@lists.fedoraproject.org] on behalf of Lubomir Rintel 
 [lkund...@v3.sk]
 Sent: Wednesday, June 18, 2014 3:20 PM
 To: Development discussions related to Fedora
 Subject: Re: pam_script review
 
 Hi Jason,
 
 On Wed, 2014-06-18 at 18:53 +, Jason Taylor wrote:
  Hi All,
 
  I have submitted https://bugzilla.redhat.com/show_bug.cgi?id=1110913
 
 I've added some comments. If noone else steps in, I can do a formal
 review as well.
 
  As indicated in the ticket this is my first packaging attempt so I am
  looking for a sponsor as well. i would obviously like to learn more
  about packaging and help maintain packages in addition to my
  submission. So if someone happens to have the time to help me learn
  the ropes and can sponsor me so I can see about helping out I would
  appreciate it! TIA.
 
 Most sponsors (me included) would like to see you do some informal
 package reviews. Please have a look at the open reviews and if you
 identify any issues with the packages comment on the packages (with a
 note that you're not doing a formal review). You can follow up in this
 thread with the links to your review comments.
 
 Also, feel free to ask on this list if there's anything unclear about
 the guidelines. The guidelines and documentation are huge and the best
 way to get familiar with them is reviewing and creating the packages.
 
  Regards,
 
  JT
 
 Have a nice day!
 Lubo
 
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: DNF: why does it refresh metadata all the time

HI


On Sat, Jun 21, 2014 at 4:45 AM, Reindl Harald wrote:

 stop the automatic bandwidth wasting at all and you don't
 have to fix anything - don't you realize that this 50% are
 the ones with the slow WAN and the ones with fast internet
 don't need prefetch of metadata at all?


Even if I have a fast connection,  I prefer metadata refreshes to happen
automatically in the background and consider it as a useful optimization.
I would disable that service in a server perhaps and that is something for
the server product to consider.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal: time to set up the fedora-release-{cloud, workstation, server} subpackages

Hi


On Wed, Jun 18, 2014 at 4:15 PM, Matthew Miller  wrote:

 We talked about this before, but I think now it's getting really close to
 the time when we _need_ it. See
 https://bugzilla.redhat.com/show_bug.cgi?id=1110764... as Dennis says,
 we
 have not yet decided how to differentiate the different Fedora products.

 I suggest that we have fedora-release-{workstation,server,cloud} packages.


Could we extend os-release with coordination with systemd and not have
fedora-release?

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: DNF: why does it refresh metadata all the time


Am 21.06.2014 16:42, schrieb Rahul Sundaram:
 On Sat, Jun 21, 2014 at 4:45 AM, Reindl Harald wrote:
 
 stop the automatic bandwidth wasting at all and you don't
 have to fix anything - don't you realize that this 50% are
 the ones with the slow WAN and the ones with fast internet
 don't need prefetch of metadata at all?  
 
 Even if I have a fast connection,  I prefer metadata refreshes to happen 
 automatically in the background and
 consider it as a useful optimization.  I would disable that service in a 
 server perhaps and that is something for
 the server product to consider

what you or i prefer don't matter

the ordinary user never uses yum/dnf at all and most of them just
react on the new updates are available in the GUI - fine that
runs completly in the background - there is no slower/faster
in that context and most ohters case about *fresh* metadata
and not previously cached ones

however, it's even not worth to get angry about another
wrong default decision and i juest fix the settings at
my own



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: DNF: why does it refresh metadata all the time

2014-06-21 Thread drago01

On Sat, Jun 21, 2014 at 4:46 PM, Reindl Harald h.rei...@thelounge.net wrote:

 Am 21.06.2014 16:42, schrieb Rahul Sundaram:
 On Sat, Jun 21, 2014 at 4:45 AM, Reindl Harald wrote:

 stop the automatic bandwidth wasting at all and you don't
 have to fix anything - don't you realize that this 50% are
 the ones with the slow WAN and the ones with fast internet
 don't need prefetch of metadata at all?

 Even if I have a fast connection,  I prefer metadata refreshes to happen 
 automatically in the background and
 consider it as a useful optimization.  I would disable that service in a 
 server perhaps and that is something for
 the server product to consider

 what you or i prefer don't matter

 the ordinary user never uses yum/dnf at all and most of them just
 react on the new updates are available in the GUI - fine that
 runs completly in the background - there is no slower/faster
 in that context and most ohters case about *fresh* metadata
 and not previously cached ones

Well there is not much difference between a few hours old metadata and
fresh metadata. You might as well hit a mirror that is a few hours
behind in syncing 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: DNF: why does it refresh metadata all the time


Am 21.06.2014 17:20, schrieb drago01:
 On Sat, Jun 21, 2014 at 4:46 PM, Reindl Harald h.rei...@thelounge.net wrote:

 Am 21.06.2014 16:42, schrieb Rahul Sundaram:
 On Sat, Jun 21, 2014 at 4:45 AM, Reindl Harald wrote:

 stop the automatic bandwidth wasting at all and you don't
 have to fix anything - don't you realize that this 50% are
 the ones with the slow WAN and the ones with fast internet
 don't need prefetch of metadata at all?

 Even if I have a fast connection,  I prefer metadata refreshes to happen 
 automatically in the background and
 consider it as a useful optimization.  I would disable that service in a 
 server perhaps and that is something for
 the server product to consider

 what you or i prefer don't matter

 the ordinary user never uses yum/dnf at all and most of them just
 react on the new updates are available in the GUI - fine that
 runs completly in the background - there is no slower/faster
 in that context and most ohters case about *fresh* metadata
 and not previously cached ones
 
 Well there is not much difference between a few hours old metadata and
 fresh metadata. You might as well hit a mirror that is a few hours
 behind in syncing 

and that is the difference

if i type dnf upgrade because at the moment i have time and
would apply available updates due a cigarette break and get
metadata downloaded at that moment the mirror is more likely
not behind compared to denf refreshed in background before

not only only i did rm -rf /var/cache/yum/*; yum upgrade
because i knew there where a security relevant update multiple
times and then it was visible

another things whis pisses me personally is the size of the
metadat at all - that are some hundret MB not worth lying
around unused - but as said: i disable that behavior and
that's it for me - the decision need to manually disable
it remains wrong



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

dnf even allows to uninstall RPM and systemd without warnings

that is a joke - DNF even allows to remove libraries
with recursive dependencies uninstall the complete
operating system not only the running kernel

nobody can seriously argue that this is a acceptable behavior
to replace yum and the developers decided so shows once
more that recent Fedora decisions are selfish and only
pretend to care about users while not care

frankly even a packaging error or a unexpierienced user
tryies to solve dependency problems easily leads to
a destroyed system that way

[root@rawhide ~]# dnf remove pcre
Failed loading plugin: copr
Dependencies resolved.


 Package  Arch Version  
Repository
Size

Removing:
 acl  x86_64   2.2.52-5.fc21
@System
   185 k
 attr x86_64   2.4.47-7.fc21
@System
   158 k
 audit-libs   x86_64   2.3.7-2.fc21 
@System
   201 k
 autogen-libopts  x86_64   5.18.3-2.fc21
@System
   141 k
 basesystem   noarch   10.0-10.fc21 
@System
 0
 bash x86_64   4.3.18-2.fc21
@System
   6.8 M
 bash-completion  noarch   1:2.1-5.fc21 
@System
   764 k
 binutils x86_64   2.24-15.fc21 
@System
20 M
 bzip2x86_64   1.0.6-12.fc21
@System
86 k
 bzip2-libs   x86_64   1.0.6-12.fc21
@System
68 k
 ca-certificates  noarch   2013.1.97-3.fc21 
@System
   1.0 M
 chkconfigx86_64   1.3.61-2.fc21
@System
   725 k
 coreutilsx86_64   8.22-15.fc21 
@System
14 M
 cpio x86_64   2.11-28.fc21 
@System
   673 k
 cracklib x86_64   2.9.1-3.fc21 
@System
   205 k
 cracklib-dicts   x86_64   2.9.1-3.fc21 
@System
   9.0 M
 cronie   x86_64   1.4.11-7.fc21
@System
   211 k
 cronie-anacron   x86_64   1.4.11-7.fc21
@System
41 k
 crontabs noarch   
1.11-8.20130830git.fc21  @System
   3.6 k
 crypto-policies  noarch   
20140620-1.gitdac1524.fc21   @System
34 k
 cryptsetup-libs  x86_64   1.6.4-3.fc21 
@System
   679 k
 curl x86_64   7.37.0-2.fc21
@System
   514 k
 cyrus-sasl-lib   x86_64   2.1.26-17.fc21   
@System
   386 k
 dbus x86_64   1:1.8.4-2.fc21   
@System
   874 k
 dbus-libsx86_64   1:1.8.4-2.fc21   
@System
   299 k
 deltarpm x86_64   3.6-5.fc21   
@System
   210 k
 device-mapperx86_64   1.02.85-5.fc21   
@System
   183 k
 device-mapper-libs   x86_64   1.02.85-5.fc21   
@System
   254 k
 diffutilsx86_64   3.3-7.fc21   
@System
   1.0 M
 dnf  noarch   0.5.2-2.fc21 
@System
   2.4 M
 dnf-plugins-core noarch   0.1.0-3.fc21 
@System
   115 k
 dracut   x86_64   
037-13.git20140402.fc21  @System
   858 k
 e2fsprogsx86_64   1.42.10-3.fc21   
@System

Re: DNF: why does it refresh metadata all the time

2014-06-21 Thread poma

On 21.06.2014 03:03, Dan Williams wrote:

On Fri, 2014-06-20 at 23:27 +0200, poma wrote:

On 20.06.2014 17:55, Dan Williams wrote:

On Fri, 2014-06-20 at 08:55 +0200, drago01 wrote:

On Thu, Jun 19, 2014 at 8:59 PM, Jared K. Smith
jsm...@fedoraproject.org wrote:

On Thu, Jun 19, 2014 at 2:01 PM, Reindl Harald h.rei...@thelounge.net
wrote:

if *that* is what is supposed to make DNF faster it's just a lie

This is not the only thing that DNF does differently to try to make package
installations and updates go faster (or appear to go faster). Calling the
developers liers doesn't help the situation any.

if i am really interested in updates now i do yum clean metadata yum
upgrade
for many years simply because you don't know how accurat you metadata are

Sure, but you have to understand -- you're a power user. You know enough to
do this in yum for your particular use case, which means you probably know
enough to change the DNF settings with regards to cron-based metadata
retrieval. What I think you're missing (and frankly, seem to miss in the
lot of fedora-devel discussions you take part in) is that Fedora isn't
engineered around *your* particular needs. We do things mostly by
consensus, and aim to make it a pleasant experience for the *average* user
(or whatever we have in the Fedora community that approximates an average
user), and not just for power users with very specific needs and
requirements.

Whether you like it or not, one of the most common complaints about yum
(especially from people coming from another package management system) is
that it seems slow because of the necessity to download the metadata. The
DNF developers -- in trying to address this common complaint -- had solved
it by handling metadata in a different way. They've also added settings so
that power users like you and I can tune it to better fit our particular
needs.

and *no* traffic is not cheap everywhere, by far not

I probably understand this better than a lot of people on this list, as I've
been on a bandwidth-limited connection for the past nine years. Only in the
past month have I been able to get high speed internet in my home that
wasn't limited to a few gigabytes per month. So yes, I completely
understand that traffic isn't cheap (or fast) everywhere.

It should be at least smart enough to not do it on mobile broadband
(like packagekit does).

Python + D-Bus example for detecting WWAN NetworkManager 0.9+ is here:

http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/python/dbus/is-wwan-default.py

Dan

This is super duper, however if wwan is on the router as Ranhald wrote, you can only
click your heels three times and repeat, There's no place like home.

Certainly. But that doesn't mean we shouldn't try to fix 50%, even if
we can't achieve the stars. So I think there's a ton of value in doing
this despite the fact that we can't be perfect.

Dan

Your fame is well deserved, Spaniard.
However, a sensible default is what it is.

poma

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: DNF: why does it refresh metadata all the time

2014-06-21 Thread Tim Lauridsen

On Fri, Jun 20, 2014 at 4:01 PM, Zdenek Kabelac zkabe...@redhat.com wrote:

 Also for years Debian supplies short update 'diffs' - so user doesn't have
 to download multiple MB sized files - just couple short small files - again
 something much nicer then running a daemon to download tens of MB on
 background daily...


dnf/yum don't download metadata if it is not changed, the download a small
repod.xml file with checksum and other stuff, metadata is only updated when
the metadata in cache don't
match the ones in the remoted repositories.

Updates are only push once a day, and have to sync out to the mirrors, so
there is no reason to check for metadata every 10 min og every time dnf is
run.
both yum/dnf has settings to control how often the remote repos is checked
for changes, so it can be configured by the user is they don't like tge
default setting.
delta metadata is on the wishlist for dnf, but it is hard to get it to work
in good way.

Tim
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: repodata - xz

2014-06-21 Thread Tim Lauridsen

On Fri, Jun 20, 2014 at 3:44 PM, Dennis Gilmore den...@ausil.us wrote:

 because thats how createrepo works. the gzipped files are not ones you
 download. yum and dnf use the sqlite files.


yum is using the sqlite files, dnf uses the .xml.gz files
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: DNF: why does it refresh metadata all the time

Hi


On Sat, Jun 21, 2014 at 10:46 AM, Reindl Harald wrote:


 what you or i prefer don't matter


Sure it does.  Otherwise you would not insist that your perspective is the
only right one and everyone else who has a different perspective is always
wrong in any such discussion.


 the ordinary user never uses yum/dnf at all and most of them just
 react on the new updates are available in the GUI


I have been dealing with user questions in Fedora for around 10 years now
and I would disagree with that assertion.  We never really managed to
attract a large crowd of regular consumers to Fedora who preferred the
graphical interfaces for updates and the interfaces have been pretty poor
despite several revisions (up2date, pup, gpk-update etc).  It might be
change with better software managers now but I suspect that most of our
regular users are in fact using the command line for updates at this
point.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf even allows to uninstall RPM and systemd without warnings

Hi


On Sat, Jun 21, 2014 at 12:23 PM, Tim Lauridsen  wrote:

 Just run rm -rf / as root, it is much faster way to remove your os ;-)

 dnf does what you tell it to do and ask for your confirmation, it is not
 it's job to protect you from doing stupid things with all kind of stupid
 logics.

 As many others had said, a gun don't protect you for shooting yourself in
 foot.


Tim,

Is there anyone working on a protected packages plugin for Dnf?  In the
past, it has helped users avoid trashing their systems due to bugs in
package-cleanup and so on.  So it is not just the command line users of the
direct tools we need to be concerned about.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf even allows to uninstall RPM and systemd without warnings

2014-06-21 Thread Gerald B. Cox

On Sat, Jun 21, 2014 at 9:23 AM, Tim Lauridsen tim.laurid...@gmail.com
wrote:

 many people stops reading fdl, because of all the flaming and people trash
 talking each other and that is sad for Fedora :-(


Thank you.  No one likes trolling.

It should be obvious that if you start removing packages you should
understand what you are doing.  To run DNF, you first have to have root
authority - which should be the first red flag. Second, when you enter a
command to remove a package and it comes back and lists hundreds of
dependencies it is also going to remove, that should be enough of a nudge
for the prudent person to reply N.

You can't stop people from being careless by asking them again if they are
really, really sure.  If they go ahead and destroy their system and have to
re-install, maybe that will be a sufficient deterrent to keep them from
doing it again.  Just like telling a child not to touch a hot surface...
some listen and the ones that don't get burned.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf even allows to uninstall RPM and systemd without warnings

2014-06-21 Thread Naheem Zaffar

While dnf itself might want to stay pure and do as commanded, maybe
for fedora there should be a default plugin that adds some protection
for the regular users?

On 21 June 2014 18:02, Gerald B. Cox gb...@bzb.us wrote:

 On Sat, Jun 21, 2014 at 9:23 AM, Tim Lauridsen tim.laurid...@gmail.com
 wrote:

 many people stops reading fdl, because of all the flaming and people trash
 talking each other and that is sad for Fedora :-(


 Thank you.  No one likes trolling.

 It should be obvious that if you start removing packages you should
 understand what you are doing.  To run DNF, you first have to have root
 authority - which should be the first red flag. Second, when you enter a
 command to remove a package and it comes back and lists hundreds of
 dependencies it is also going to remove, that should be enough of a nudge
 for the prudent person to reply N.

 You can't stop people from being careless by asking them again if they are
 really, really sure.  If they go ahead and destroy their system and have to
 re-install, maybe that will be a sufficient deterrent to keep them from
 doing it again.  Just like telling a child not to touch a hot surface...
 some listen and the ones that don't get burned.

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf even allows to uninstall RPM and systemd without warnings

2014-06-21 Thread Gerald B. Cox

You can't child proof the world.


On Sat, Jun 21, 2014 at 10:19 AM, Naheem Zaffar naheemzaf...@gmail.com
wrote:

 While dnf itself might want to stay pure and do as commanded, maybe
 for fedora there should be a default plugin that adds some protection
 for the regular users?

 On 21 June 2014 18:02, Gerald B. Cox gb...@bzb.us wrote:
 
  On Sat, Jun 21, 2014 at 9:23 AM, Tim Lauridsen tim.laurid...@gmail.com
  wrote:
 
  many people stops reading fdl, because of all the flaming and people
 trash
  talking each other and that is sad for Fedora :-(
 
 
  Thank you.  No one likes trolling.
 
  It should be obvious that if you start removing packages you should
  understand what you are doing.  To run DNF, you first have to have root
  authority - which should be the first red flag. Second, when you enter a
  command to remove a package and it comes back and lists hundreds of
  dependencies it is also going to remove, that should be enough of a nudge
  for the prudent person to reply N.
 
  You can't stop people from being careless by asking them again if they
 are
  really, really sure.  If they go ahead and destroy their system and have
 to
  re-install, maybe that will be a sufficient deterrent to keep them from
  doing it again.  Just like telling a child not to touch a hot surface...
  some listen and the ones that don't get burned.
 
  --
  devel mailing list
  devel@lists.fedoraproject.org
  https://admin.fedoraproject.org/mailman/listinfo/devel
  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf even allows to uninstall RPM and systemd without warnings


Am 21.06.2014 19:02, schrieb Gerald B. Cox:
 On Sat, Jun 21, 2014 at 9:23 AM, Tim Lauridsen tim.laurid...@gmail.com 
 mailto:tim.laurid...@gmail.com wrote:
 
 many people stops reading fdl, because of all the flaming and people 
 trash talking each other and that is sad
 for Fedora :-(
 
 
 Thank you.  No one likes trolling.  

no one likes broken software replacing working one

 It should be obvious that if you start removing packages you should 
 understand what you are doing

bullshit - try the same with yum

that's how i learned to find out which packages are working
together over the years by simply try to uninstall them and
even package-cleanup --leaves --all don't list all packages
you can remove *safely*




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf even allows to uninstall RPM and systemd without warnings



Am 21.06.2014 18:23, schrieb Tim Lauridsen:
 Just run rm -rf / as root, it is much faster way to remove your os ;-)
 
 dnf does what you tell it to do and ask for your confirmation, it is not it's 
 job to protect you from doing stupid things with all kind of stupid logics.

bullshit

that even can happen by broken packages

 As many others had said, a gun don't protect you for shooting yourself in 
 foot.

Error: Trying to remove systemd, which is protected
Error: Trying to remove yum, which is protected

 You should properly stop wasting everybodys time and get on with something 
 useful, 
 I think everybody has figured out by now that you don't like how dnf works

until today i was not aware that it is *that broken* at all

 it dont add anything new, by saying the same stuff again  again.
 many people stops reading fdl, because of all the flaming and people trash 
 talking each other and that is sad for Fedora :-(

than Fedora devleopers should stop propose replace wroking things
with broken and dangerous ones - period





signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: repodata - xz

2014-06-21 Thread Kalev Lember



On 06/20/2014 03:19 AM, poma wrote:


f20:
[...]
*primary.sqlite.bz22.7 M
*primary.xml.gz1.3 M

rawhide:
[...]
*primary.sqlite.xz17   M
*primary.xml.gz   10   M


Anyone know why the rawhide metadata size is an order of magnitude 
bigger than in F20?


--
Kalev
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf even allows to uninstall RPM and systemd without warnings

2014-06-21 Thread Phillip T. George

Its reasonable to follow industry practices in regards to safety. To 
remove a common safety and require humans to be intelligent all of the 
time is an excellent way to introduce (more) chaos into the system.  
Sounds like an off-list discussion needs to take place.


-Phillip

On 6/21/14 12:26 PM, Gerald B. Cox wrote:

You can't child proof the world.


On Sat, Jun 21, 2014 at 10:19 AM, Naheem Zaffar 
naheemzaf...@gmail.com mailto:naheemzaf...@gmail.com wrote:


While dnf itself might want to stay pure and do as commanded, maybe
for fedora there should be a default plugin that adds some protection
for the regular users?

On 21 June 2014 18:02, Gerald B. Cox gb...@bzb.us
mailto:gb...@bzb.us wrote:

 On Sat, Jun 21, 2014 at 9:23 AM, Tim Lauridsen
tim.laurid...@gmail.com mailto:tim.laurid...@gmail.com
 wrote:

 many people stops reading fdl, because of all the flaming and
people trash
 talking each other and that is sad for Fedora :-(


 Thank you.  No one likes trolling.

 It should be obvious that if you start removing packages you should
 understand what you are doing.  To run DNF, you first have to
have root
 authority - which should be the first red flag. Second, when you
enter a
 command to remove a package and it comes back and lists hundreds of
 dependencies it is also going to remove, that should be enough
of a nudge
 for the prudent person to reply N.

 You can't stop people from being careless by asking them again
if they are
 really, really sure.  If they go ahead and destroy their system
and have to
 re-install, maybe that will be a sufficient deterrent to keep
them from
 doing it again.  Just like telling a child not to touch a hot
surface...
 some listen and the ones that don't get burned.

 --
 devel mailing list
 devel@lists.fedoraproject.org mailto:devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
devel@lists.fedoraproject.org mailto:devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct






-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: repodata - xz

2014-06-21 Thread Orion Poplawski

On 06/21/2014 11:42 AM, Kalev Lember wrote:
 
 On 06/20/2014 03:19 AM, poma wrote:

 f20:
 [...]
 *primary.sqlite.bz22.7 M
 *primary.xml.gz1.3 M


Is this Fedora or Everything ?

For f20 Everything (comparable to rawhide) I have:

 19M *-primary.sqlite.bz2

so looks like xz is helping.

 rawhide:
 [...]
 *primary.sqlite.xz17   M
 *primary.xml.gz   10   M
 
 Anyone know why the rawhide metadata size is an order of magnitude
 bigger than in F20?
 


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf even allows to uninstall RPM and systemd without warnings



Am 21.06.2014 19:57, schrieb Phillip T. George:
 Its reasonable to follow industry practices in regards to safety.  To remove 
 a common safety and require humans to
 be intelligent all of the time is an excellent way to introduce (more) chaos 
 into the system.  Sounds like an
 off-list discussion needs to take place.

Fedora perfers to throw away that existing safety and sell after enough
damage has happened and enough users complained the comeback of that
safety as new feature for Fesora 24/25, that's hwat happens with all
the new improved replacments, only too few people remember that many
of the follow-up improvements worked years before and got killed by
making things better

surely, 5 years after DNF repladed YUM you can got out and propose
that the new DNF version improves things by prevent such damage
but accept that users with expierence over years will laugh about
that and refer to some of my posts!

smart development would not gave me a single reason to complain
about such basics ignored and even close bugreports

Second, when you enter a command to remove a package and it comes back
and lists hundreds of dependencies is *censored* - df remove rpm-libs
don't list hundrets of packages - have fun to recover a system if
someone uninstalelled rpm - have fun asking the user why he did say
yes and confirmed it

the user will tell you because such damage was not possible in the
past and some arrogant developers sold steps backward in the
development as a improvement

 On 6/21/14 12:26 PM, Gerald B. Cox wrote:
 You can't child proof the world.


 On Sat, Jun 21, 2014 at 10:19 AM, Naheem Zaffar naheemzaf...@gmail.com 
 mailto:naheemzaf...@gmail.com wrote:

 While dnf itself might want to stay pure and do as commanded, maybe
 for fedora there should be a default plugin that adds some protection
 for the regular users?

 On 21 June 2014 18:02, Gerald B. Cox gb...@bzb.us 
 mailto:gb...@bzb.us wrote:
 
  On Sat, Jun 21, 2014 at 9:23 AM, Tim Lauridsen 
 tim.laurid...@gmail.com mailto:tim.laurid...@gmail.com
  wrote:
 
  many people stops reading fdl, because of all the flaming and people 
 trash
  talking each other and that is sad for Fedora :-(
 
 
  Thank you.  No one likes trolling.
 
  It should be obvious that if you start removing packages you should
  understand what you are doing.  To run DNF, you first have to have root
  authority - which should be the first red flag. Second, when you enter 
 a
  command to remove a package and it comes back and lists hundreds of
  dependencies it is also going to remove, that should be enough of a 
 nudge
  for the prudent person to reply N.
 
  You can't stop people from being careless by asking them again if they 
 are
  really, really sure.  If they go ahead and destroy their system and 
 have to
  re-install, maybe that will be a sufficient deterrent to keep them from
  doing it again.  Just like telling a child not to touch a hot 
 surface...
  some listen and the ones that don't get burned.



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: repodata - xz

2014-06-21 Thread Jon

On Sat, Jun 21, 2014 at 11:25 AM, Tim Lauridsen tim.laurid...@gmail.com wrote:

 On Fri, Jun 20, 2014 at 3:44 PM, Dennis Gilmore den...@ausil.us wrote:

 because thats how createrepo works. the gzipped files are not ones you
 download. yum and dnf use the sqlite files.


 yum is using the sqlite files, dnf uses the .xml.gz files



Would it be too much trouble to use the sqlite data in DNF?
I suppose it would be a step backwards to have our primary (future)
tool using gzip metadata.

-- 

-Jon
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf even allows to uninstall RPM and systemd without warnings

2014-06-21 Thread Orcan Ogetbil

On Sat, Jun 21, 2014 at 12:23 PM, Tim Lauridsen wrote:
 Just run rm -rf / as root, it is much faster way to remove your os ;-)

Bad example. Even rm has protection for /
See rm --help
;)

Orcan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf even allows to uninstall RPM and systemd without warnings



Am 21.06.2014 20:41, schrieb Orcan Ogetbil:
 On Sat, Jun 21, 2014 at 12:23 PM, Tim Lauridsen wrote:
 Just run rm -rf / as root, it is much faster way to remove your os ;-)
 
 Bad example. Even rm has protection for /
 See rm --help
 ;)

don't annoy with the truth :-)

guess why it has that protection - because somewhere in the
past a smart guy thought that it is very unlikely someone
types rm -rf / seriously and not by accident hit enter

it's the same way unlikely that someone seriously wants
to remove rpm, yum/dnf and the running kernel or ending
there by a cross-dependency and hit y by trusting his
operating system not make steps backwards in quality



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: repodata - xz

2014-06-21 Thread Kevin Fenzi

On Sat, 21 Jun 2014 13:28:33 -0500
Jon jdisn...@gmail.com wrote:

 Would it be too much trouble to use the sqlite data in DNF?
 I suppose it would be a step backwards to have our primary (future)
 tool using gzip metadata.

filed https://bugzilla.redhat.com/show_bug.cgi?id=871 on this. 

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: comps categories: are they any use to anyone any more?

2014-06-21 Thread Bill Nottingham

Adam Williamson (awill...@redhat.com) said: 
 Working on comps for the NetworkManager submodule change (see other
 email) made me wonder: are the comps 'categories' actually used for
 anything any more?
 
 I believe they were used in oldUI for presentation of the 'pick a
 package' UI. We don't have that UI any more, haven't since Fedora 18. I
 don't believe anaconda uses the categories any more. newUI shows
 environment groups down the left hand side of the screen. On the right
 hand side it shows the optional groups related to the current
 environment group at the top, and then all other user visible package
 groups at the bottom.
 
 So if I'm right that anaconda isn't using the categories any more, is
 anything else? Or can we just ditch them?

Check the post-install tools; I believe at least one of apper or yumex still
uses them.

Bill
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf even allows to uninstall RPM and systemd without warnings

2014-06-21 Thread Ankur Sinha

On Sat, 2014-06-21 at 12:29 -0400, Rahul Sundaram wrote:
 Tim, 
 
 Is there anyone working on a protected packages plugin for Dnf?  In
 the past, it has helped users avoid trashing their systems due to bugs
 in package-cleanup and so on.  So it is not just the command line
 users of the direct tools we need to be concerned about. 

+1

I agree that it doesn't need to be part of the DNF core, but a plugin
would be really nice. It's just a safety measure and while we,
relatively seasoned users, are aware that we need to be really careful
when removing packages, a lot of novice users aren't - I've seen quite a
few cases in #fedora over the years where novices didn't check the
transaction report and lost critical packages. 

If there isn't an RFE filed already, I could go ahead and file one. 
-- 
Thanks,
Warm regards,
Ankur (FranciscoD)

http://fedoraproject.org/wiki/User:Ankursinha

Join Fedora! Come talk to us!
http://fedoraproject.org/wiki/Fedora_Join_SIG



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Lockscreen / suspend / keyboard issue

2014-06-21 Thread Nathanael d. Noblet

On Sun, 2014-05-11 at 22:30 -0600, Nathanael d. Noblet wrote:
   After opening/closing the computer a few times sometimes I just hard
 reset the machine. Sometimes it comes to and lets me enter my password
 and unlocks. I'd like to debug and find the source of the problem. 
 
   If I login via ssh from another computer no process is consuming the
 CPU, there aren't obvious highly repetitive messages in the logs or that
 I can see would be related.
 
   This has been happening since I got the machine for all F20 kernels.
 Where do I look? What can I do to figure this out?

Hello,

  So I think what is happening is that the keyboard isn't activated. It
makes the most sense. I found some people talking about similar issues.
Most of the time it seems adding atkbd.reset to the kernel command line
seemed to fix it. Granted these were all Ubuntu machines. Adding the
atkbd.reset to grub did nothing for me. I'm not sure if we use atkbd or
if there is an equivalent command I can use on fedora to overcome this
very annoying issue. I did find a bug that may be similar enough so I
added myself and comments to it

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

I would love any pointers or things to do to figure out if the keyboard
not resuming or otherwise having issues this is indeed the case.

-- 
Nathanael

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 1110725] CVE-2014-0477 perl-Email-Address: Denial-of-Service in Email::Address::parse [epel-5]

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

Fedora Update System upda...@fedoraproject.org changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System upda...@fedoraproject.org ---
Package perl-Email-Address-1.905-1.el5:
* should fix your issue,
* was pushed to the Fedora EPEL 5 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing perl-Email-Address-1.905-1.el5'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1696/perl-Email-Address-1.905-1.el5
then log in and leave karma (feedback).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=s03EUNaWTqa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1110726] CVE-2014-0477 perl-Email-Address: Denial-of-Service in Email::Address::parse [epel-6]

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

Fedora Update System upda...@fedoraproject.org changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System upda...@fedoraproject.org ---
Package perl-Email-Address-1.905-1.el6:
* should fix your issue,
* was pushed to the Fedora EPEL 6 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing perl-Email-Address-1.905-1.el6'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1693/perl-Email-Address-1.905-1.el6
then log in and leave karma (feedback).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=EwAkxz3hPna=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1111858] New: perl-Any-Moose-0.22 is available

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

Bug ID: 858
   Summary: perl-Any-Moose-0.22 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Any-Moose
  Keywords: FutureFeature, Triaged
  Assignee: iarn...@gmail.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org,
robinlee.s...@gmail.com



Latest upstream release: 0.22
Current version/release in Fedora Rawhide: 0.21-6.fc21
URL: http://search.cpan.org/dist/Any-Moose/

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=jWc56GcdFRa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1111859] New: perl-Archive-Tar-2.00 is available

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

Bug ID: 859
   Summary: perl-Archive-Tar-2.00 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Archive-Tar
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 2.00
Current version/release in Fedora Rawhide: 1.96-2.fc21
URL: http://search.cpan.org/dist/Archive-Tar/

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=d0W3GmfsDXa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1111861] New: perl-Devel-Symdump-2.12 is available

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

Bug ID: 861
   Summary: perl-Devel-Symdump-2.12 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Devel-Symdump
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mmasl...@redhat.com,
p...@city-fan.org, perl-devel@lists.fedoraproject.org,
pertu...@free.fr



Latest upstream release: 2.12
Current version/release in Fedora Rawhide: 2.11-2.fc21
URL: http://search.cpan.org/dist/Devel-Symdump/

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=UcUtWxOiDja=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1111862] New: perl-File-ShareDir-ProjectDistDir-1.000002 is available

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

Bug ID: 862
   Summary: perl-File-ShareDir-ProjectDistDir-1.02 is
available
   Product: Fedora
   Version: rawhide
 Component: perl-File-ShareDir-ProjectDistDir
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 1.02
Current version/release in Fedora Rawhide: 1.01-2.fc21
URL: http://search.cpan.org/dist/File-ShareDir-ProjectDistDir/

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=ufL3VBtFqha=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1111863] New: perl-LDAP-0.64 is available

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

Bug ID: 863
   Summary: perl-LDAP-0.64 is available
   Product: Fedora
   Version: rawhide
 Component: perl-LDAP
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 0.64
Current version/release in Fedora Rawhide: 0.63-2.fc21
URL: http://search.cpan.org/dist/perl-ldap/

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=p1UQvxMW3Va=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1111864] New: perl-Math-PlanePath-116 is available

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

Bug ID: 864
   Summary: perl-Math-PlanePath-116 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Math-PlanePath
  Keywords: FutureFeature, Triaged
  Assignee: mhron...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: mhron...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 116
Current version/release in Fedora Rawhide: 115-2.fc21
URL: http://search.cpan.org/dist/Math-PlanePath/

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=9P9hVnhJlRa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1111865] New: perl-Pod-Checker-1.71 is available

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

Bug ID: 865
   Summary: perl-Pod-Checker-1.71 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Pod-Checker
  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.71
Current version/release in Fedora Rawhide: 1.70-2.fc21
URL: http://search.cpan.org/dist/Pod-Checker/

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=2HyNJuJOxOa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1111866] New: perl-POE-Component-IRC-6.87 is available

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

Bug ID: 866
   Summary: perl-POE-Component-IRC-6.87 is available
   Product: Fedora
   Version: rawhide
 Component: perl-POE-Component-IRC
  Keywords: FutureFeature, Triaged
  Assignee: psab...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, psab...@redhat.com



Latest upstream release: 6.87
Current version/release in Fedora Rawhide: 6.83-4.fc21
URL: http://search.cpan.org/dist/POE-Component-IRC/

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=JXnGek6hOaa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1111867] New: perl-Sys-Detect-Virtualization-0.107 is available

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

Bug ID: 867
   Summary: perl-Sys-Detect-Virtualization-0.107 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Sys-Detect-Virtualization
  Keywords: FutureFeature, Triaged
  Assignee: dd...@cpan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: dd...@cpan.org, perl-devel@lists.fedoraproject.org



Latest upstream release: 0.107
Current version/release in Fedora Rawhide: 0.106-2.fc21
URL: http://search.cpan.org/dist/Sys-Detect-Virtualization/

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=r1aMGknqfEa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1111868] New: perl-XML-DifferenceMarkup-1.05 is available

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

Bug ID: 868
   Summary: perl-XML-DifferenceMarkup-1.05 is available
   Product: Fedora
   Version: rawhide
 Component: perl-XML-DifferenceMarkup
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 1.05
Current version/release in Fedora Rawhide: 1.04-9.fc21
URL: http://search.cpan.org/dist/XML-DifferenceMarkup/

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=ByenNLiwTSa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1111870] New: perl-YAML-0.95 is available

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

Bug ID: 870
   Summary: perl-YAML-0.95 is available
   Product: Fedora
   Version: rawhide
 Component: perl-YAML
  Keywords: FutureFeature, Triaged
  Assignee: st...@silug.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
psab...@redhat.com, st...@silug.org



Latest upstream release: 0.95
Current version/release in Fedora Rawhide: 0.94-1.fc21
URL: http://search.cpan.org/dist/YAML/

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=qabXJdPqTqa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1111869] New: perl-XXX-0.21 is available

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

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



Latest upstream release: 0.21
Current version/release in Fedora Rawhide: 0.18-8.fc21
URL: http://search.cpan.org/dist/XXX/

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=z0Io7UYtPAa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1110724] CVE-2014-0477 perl-Email-Address: Denial-of-Service in Email::Address::parse [fedora-all]