date:20131030


On 10/29/2013 02:13 PM, Dridi Boukelmoune wrote:

Hi,

I'm on the CC list of the review request for rubygem-vagrant [1] and
randomly found a new review request for vagrant [2]. The two packages
are AFAICT the same, and the former is stalled due to missing
dependencies, the last one being rubygem-log4r [3].

Ironically, the two submitters (CC'ed) met on the rubygem-log4r review
request. I think that according to the guidelines vagrant is a duplicate,
but I like the name better than rubygem-vagrant (which is used on other
distros, and just a matter of renaming).

Anyway, from what I can see for rubygem-log4r, it looks like vagrant
on fedora is coming soon :)

Best Regards,
Dridi

[1] https://bugzilla.redhat.com/show_bug.cgi?id=905396
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1020456
[3] https://bugzilla.redhat.com/show_bug.cgi?id=905240

Hi,

yes, according to guidelines[1], it should be named rubygem-vagrant 
since it's convention for all RubyGems.


Josef

[1] https://fedoraproject.org/wiki/Packaging:Ruby#Naming_Guidelines
--
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: $HOME/.local/bin in $PATH

Am 30.10.2013 02:03, schrieb Chris Adams:
 Once upon a time, Reindl Harald h.rei...@thelounge.net said:
 [root@srv-rhsoft:~]$ mkdir test
 i could rm -rf ~/ here

 [root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir
 #!/bin/bash
 echo i could rm -rf ~/ here
 
 If I can write to files you own, it doesn't matter if there's a
 directory in the PATH or not.  I can write this to your .bash_profile:
 
/bin/mkdir $HOME/.bin 2 /dev/null
echo 'echo i could rm -rf ~/ here'  $HOME/.bin/mkdir
chmod +x $HOME/.bin/mkdir
PATH=$HOME/.bin:$PATH

you can do this and that - but that's no valid argumentation
doing bad things in default setups and *at least* do not
place *hidden* diretories there, ther is a good reason why
software like rkhunter alerts if you have hidden directories
somewhere in /usr/bin/

there are three type of users

* people who care about security and know that there are
  enough rough edges but smart enough to take this *not
  as excuse* to create new ones
* the ones which care only a little bit as long it comes
  not to personal comfort decisions and take bad behavior
  as excuse for create more bad behavior
* the ones who don't care about security

when it comes to decisions for a *distribution* only the
first group is relevant, the others are dangerous and
i am not sure who is more dangerous - not care at all
or realize that what happens is wrong and support it




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: [AutoQA] #445: upgradepath is failing rawhide builds due to not being higher version than other releases

2013-10-30 Thread AutoQA

#445: upgradepath is failing rawhide builds due to not being higher version than
other releases
+-
 Reporter:  tflink  |   Owner:
 Type:  defect  |  Status:  new
 Priority:  major   |   Milestone:  Hot issues
Component:  tests   |  Resolution:
 Keywords:  |  Blocked By:
 Blocking:  |
+-

Comment (by kparal):

 I don't think so. I'll try to adjust it soon (most probably not this week,
 however).

-- 
Ticket URL: https://fedorahosted.org/autoqa/ticket/445#comment:6
AutoQA http://autoqa.fedorahosted.org
Automated QA project
___
qa-devel mailing list
qa-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel

Re: Duplicate review request for rubygem-vagrant

2013-10-30 Thread Tom Hughes


On 30/10/13 09:16, Josef Stribny wrote:


yes, according to guidelines[1], it should be named rubygem-vagrant
since it's convention for all RubyGems.


Is vagrant not an Application package that mainly provides user-level 
tools that happen to be written in Ruby though? In which case by the 
third point the general naming guidelines should be followed instead?


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
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: Duplicate review request for rubygem-vagrant

What prevails between the ruby naming guidelines and  the prior art
rule (other distros package name) in the general naming guidelines ?

https://fedoraproject.org/wiki/Packaging:NamingGuidelines#General_Naming
http://packages.ubuntu.com/raring/vagrant
http://packages.debian.org/stable/vagrant

My point was more about the fact that two people are working on the
same package (one I happen to be waiting for=).

Dridi

On Wed, Oct 30, 2013 at 10:16 AM, Josef Stribny jstri...@redhat.com wrote:
 On 10/29/2013 02:13 PM, Dridi Boukelmoune wrote:

 Hi,

 I'm on the CC list of the review request for rubygem-vagrant [1] and
 randomly found a new review request for vagrant [2]. The two packages
 are AFAICT the same, and the former is stalled due to missing
 dependencies, the last one being rubygem-log4r [3].

 Ironically, the two submitters (CC'ed) met on the rubygem-log4r review
 request. I think that according to the guidelines vagrant is a duplicate,
 but I like the name better than rubygem-vagrant (which is used on other
 distros, and just a matter of renaming).

 Anyway, from what I can see for rubygem-log4r, it looks like vagrant
 on fedora is coming soon :)

 Best Regards,
 Dridi

 [1] https://bugzilla.redhat.com/show_bug.cgi?id=905396
 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1020456
 [3] https://bugzilla.redhat.com/show_bug.cgi?id=905240

 Hi,

 yes, according to guidelines[1], it should be named rubygem-vagrant since
 it's convention for all RubyGems.

 Josef

 [1] https://fedoraproject.org/wiki/Packaging:Ruby#Naming_Guidelines
 --
 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: $HOME/.local/bin in $PATH


On 2013-10-30 10:23, Reindl Harald wrote:

Am 30.10.2013 02:03, schrieb Chris Adams:

Once upon a time, Reindl Harald h.rei...@thelounge.net said:

[root@srv-rhsoft:~]$ mkdir test
i could rm -rf ~/ here

[root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir
#!/bin/bash
echo i could rm -rf ~/ here

If I can write to files you own, it doesn't matter if there's a
directory in the PATH or not.  I can write this to your .bash_profile:

/bin/mkdir $HOME/.bin 2 /dev/null
echo 'echo i could rm -rf ~/ here'  $HOME/.bin/mkdir
chmod +x $HOME/.bin/mkdir
PATH=$HOME/.bin:$PATH

you can do this and that - but that's no valid argumentation
doing bad things in default setups and *at least* do not
place *hidden* diretories there, ther is a good reason why
software like rkhunter alerts if you have hidden directories
somewhere in /usr/bin/

Some kind of reference for the bad in having a well-known, hidden 
directory in the path?


As for rkhunter, doesn't it  warn for hidden directories in many places, 
not just /usr/bin? The primary purpose seems to be to discover new, 
hidden directories created by a rootkit or so. I can't see this applies 
here.


--a



--
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: $HOME/.local/bin in $PATH


Am 30.10.2013 10:53, schrieb Alec Leamas:
 On 2013-10-30 10:23, Reindl Harald wrote:
 Am 30.10.2013 02:03, schrieb Chris Adams:
 Once upon a time, Reindl Harald h.rei...@thelounge.net said:
 [root@srv-rhsoft:~]$ mkdir test
 i could rm -rf ~/ here

 [root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir
 #!/bin/bash
 echo i could rm -rf ~/ here
 If I can write to files you own, it doesn't matter if there's a
 directory in the PATH or not.  I can write this to your .bash_profile:

 /bin/mkdir $HOME/.bin 2 /dev/null
 echo 'echo i could rm -rf ~/ here'  $HOME/.bin/mkdir
 chmod +x $HOME/.bin/mkdir
 PATH=$HOME/.bin:$PATH
 you can do this and that - but that's no valid argumentation
 doing bad things in default setups and *at least* do not
 place *hidden* diretories there, ther is a good reason why
 software like rkhunter alerts if you have hidden directories
 somewhere in /usr/bin/

 Some kind of reference for the bad in having a well-known, hidden directory 
 in the path?

the *writeable for the user* is the problem

however, since i am one of them with explicit configurations and
setting explicit $PATH in .bashrc and .bash_profile which are
readonly do what you want with defaults, i would appreciate sane
defaults but i can live with doing this job 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

wipe maintainer Scott Henson nonresponsive

2013-10-30 Thread Till Maas

Hi,

this is a contact attempt for the wipe maintainer Scott Henson according
to
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers

Bug with contact attempts:
https://bugzilla.redhat.com/show_bug.cgi?id=1019179

There are two other bugs without any response:
https://admin.fedoraproject.org/pkgdb/acls/bugs/wipe

The oldest bug is from March 2010 without any response so far.

Regards
Till
-- 
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-0.4.6

2013-10-30 Thread Ales Kozumplik


Hi,

I have just submitted the latest dnf as an F20 update [1]. It brings 
quite a few fixes and improvements, most significant of which are the 
history undo support and limiting the number of installed kernels. See 
the release notes [2] and the blog post [3].


Ales Kozumplik

[1] http://bit.ly/HeNw29
[2] http://akozumpl.github.io/dnf/release_notes.html#id17
[3] http://dnf.baseurl.org/2013/10/30/dnf-0-4-6/
--
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: $HOME/.local/bin in $PATH


On 2013-10-30 10:58, Reindl Harald wrote:

Am 30.10.2013 10:53, schrieb Alec Leamas:

On 2013-10-30 10:23, Reindl Harald wrote:

Am 30.10.2013 02:03, schrieb Chris Adams:

Once upon a time, Reindl Harald h.rei...@thelounge.net said:

[root@srv-rhsoft:~]$ mkdir test
i could rm -rf ~/ here

[root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir
#!/bin/bash
echo i could rm -rf ~/ here

If I can write to files you own, it doesn't matter if there's a
directory in the PATH or not.  I can write this to your .bash_profile:

 /bin/mkdir $HOME/.bin 2 /dev/null
 echo 'echo i could rm -rf ~/ here'  $HOME/.bin/mkdir
 chmod +x $HOME/.bin/mkdir
 PATH=$HOME/.bin:$PATH

you can do this and that - but that's no valid argumentation
doing bad things in default setups and *at least* do not
place *hidden* diretories there, ther is a good reason why
software like rkhunter alerts if you have hidden directories
somewhere in /usr/bin/


Some kind of reference for the bad in having a well-known, hidden directory in 
the path?

the *writeable for the user* is the problem

Any reference for this problem?


--alec
--
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: $HOME/.local/bin in $PATH


Am 30.10.2013 11:20, schrieb Alec Leamas:
 On 2013-10-30 10:58, Reindl Harald wrote:
 Am 30.10.2013 10:53, schrieb Alec Leamas:
 On 2013-10-30 10:23, Reindl Harald wrote:
 Am 30.10.2013 02:03, schrieb Chris Adams:
 Once upon a time, Reindl Harald h.rei...@thelounge.net said:
 [root@srv-rhsoft:~]$ mkdir test
 i could rm -rf ~/ here

 [root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir
 #!/bin/bash
 echo i could rm -rf ~/ here
 If I can write to files you own, it doesn't matter if there's a
 directory in the PATH or not.  I can write this to your .bash_profile:

  /bin/mkdir $HOME/.bin 2 /dev/null
  echo 'echo i could rm -rf ~/ here'  $HOME/.bin/mkdir
  chmod +x $HOME/.bin/mkdir
  PATH=$HOME/.bin:$PATH
 you can do this and that - but that's no valid argumentation
 doing bad things in default setups and *at least* do not
 place *hidden* diretories there, ther is a good reason why
 software like rkhunter alerts if you have hidden directories
 somewhere in /usr/bin/

 Some kind of reference for the bad in having a well-known, hidden directory 
 in the path?
 the *writeable for the user* is the problem
 Any reference for this problem?

what about consider the implications?
do you really need a written reference for any security relevant fact?
i can write one for you if you prefer links :-)



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: $HOME/.local/bin in $PATH


On 2013-10-30 11:23, Reindl Harald wrote:

Am 30.10.2013 11:20, schrieb Alec Leamas:

On 2013-10-30 10:58, Reindl Harald wrote:

Am 30.10.2013 10:53, schrieb Alec Leamas:

On 2013-10-30 10:23, Reindl Harald wrote:

Am 30.10.2013 02:03, schrieb Chris Adams:

Once upon a time, Reindl Harald h.rei...@thelounge.net said:

[root@srv-rhsoft:~]$ mkdir test
i could rm -rf ~/ here

[root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir
#!/bin/bash
echo i could rm -rf ~/ here

If I can write to files you own, it doesn't matter if there's a
directory in the PATH or not.  I can write this to your .bash_profile:

  /bin/mkdir $HOME/.bin 2 /dev/null
  echo 'echo i could rm -rf ~/ here'  $HOME/.bin/mkdir
  chmod +x $HOME/.bin/mkdir
  PATH=$HOME/.bin:$PATH

you can do this and that - but that's no valid argumentation
doing bad things in default setups and *at least* do not
place *hidden* diretories there, ther is a good reason why
software like rkhunter alerts if you have hidden directories
somewhere in /usr/bin/


Some kind of reference for the bad in having a well-known, hidden directory in 
the path?

the *writeable for the user* is the problem

Any reference for this problem?

what about consider the implications?
do you really need a written reference for any security relevant fact?
i can write one for you if you prefer links :-)

Well, the question is really if someone else out there share your 
concerns about this.


--alec
--
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: $HOME/.local/bin in $PATH



Am 30.10.2013 11:27, schrieb Alec Leamas:
 On 2013-10-30 11:23, Reindl Harald wrote:
 Am 30.10.2013 11:20, schrieb Alec Leamas:
 On 2013-10-30 10:58, Reindl Harald wrote:
 Am 30.10.2013 10:53, schrieb Alec Leamas:
 On 2013-10-30 10:23, Reindl Harald wrote:
 Am 30.10.2013 02:03, schrieb Chris Adams:
 Once upon a time, Reindl Harald h.rei...@thelounge.net said:
 [root@srv-rhsoft:~]$ mkdir test
 i could rm -rf ~/ here

 [root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir
 #!/bin/bash
 echo i could rm -rf ~/ here
 If I can write to files you own, it doesn't matter if there's a
 directory in the PATH or not.  I can write this to your .bash_profile:

   /bin/mkdir $HOME/.bin 2 /dev/null
   echo 'echo i could rm -rf ~/ here'  $HOME/.bin/mkdir
   chmod +x $HOME/.bin/mkdir
   PATH=$HOME/.bin:$PATH
 you can do this and that - but that's no valid argumentation
 doing bad things in default setups and *at least* do not
 place *hidden* diretories there, ther is a good reason why
 software like rkhunter alerts if you have hidden directories
 somewhere in /usr/bin/

 Some kind of reference for the bad in having a well-known, hidden 
 directory in the path?
 the *writeable for the user* is the problem
 Any reference for this problem?
 what about consider the implications?
 do you really need a written reference for any security relevant fact?
 i can write one for you if you prefer links :-)

 Well, the question is really if someone else out there share your concerns 
 about this

anybody with interests in security

https://www.google.at/search?q=ssh+chroot+why+needs+the+home+directory+to+be+owned+by+root

http://binblog.info/2008/04/06/openssh-chrooted-sftp-eg-for-webhosting/
However, the chroot destination must not be owned by the user for security 
reasons




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: $HOME/.local/bin in $PATH


On 2013-10-30 11:46, Reindl Harald wrote:


Am 30.10.2013 11:27, schrieb Alec Leamas:

On 2013-10-30 11:23, Reindl Harald wrote:

Am 30.10.2013 11:20, schrieb Alec Leamas:

On 2013-10-30 10:58, Reindl Harald wrote:

Am 30.10.2013 10:53, schrieb Alec Leamas:

On 2013-10-30 10:23, Reindl Harald wrote:

Am 30.10.2013 02:03, schrieb Chris Adams:

Once upon a time, Reindl Harald h.rei...@thelounge.net said:

[root@srv-rhsoft:~]$ mkdir test
i could rm -rf ~/ here

[root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir
#!/bin/bash
echo i could rm -rf ~/ here

If I can write to files you own, it doesn't matter if there's a
directory in the PATH or not.  I can write this to your .bash_profile:

   /bin/mkdir $HOME/.bin 2 /dev/null
   echo 'echo i could rm -rf ~/ here'  $HOME/.bin/mkdir
   chmod +x $HOME/.bin/mkdir
   PATH=$HOME/.bin:$PATH

you can do this and that - but that's no valid argumentation
doing bad things in default setups and *at least* do not
place *hidden* diretories there, ther is a good reason why
software like rkhunter alerts if you have hidden directories
somewhere in /usr/bin/


Some kind of reference for the bad in having a well-known, hidden directory in 
the path?

the *writeable for the user* is the problem

Any reference for this problem?

what about consider the implications?
do you really need a written reference for any security relevant fact?
i can write one for you if you prefer links :-)


Well, the question is really if someone else out there share your concerns 
about this

anybody with interests in security

https://www.google.at/search?q=ssh+chroot+why+needs+the+home+directory+to+be+owned+by+root

http://binblog.info/2008/04/06/openssh-chrooted-sftp-eg-for-webhosting/
However, the chroot destination must not be owned by the user for security 
reasons

So you are arguing that $HOME should be owned by root?!  An interesting 
subject, but isn't it a little off-topic, deserving a separate thread?



--a
--
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: Duplicate review request for rubygem-vagrant


On 10/30/2013 10:45 AM, Dridi Boukelmoune wrote:

What prevails between the ruby naming guidelines and  the prior art
rule (other distros package name) in the general naming guidelines ?

https://fedoraproject.org/wiki/Packaging:NamingGuidelines#General_Naming
http://packages.ubuntu.com/raring/vagrant
http://packages.debian.org/stable/vagrant


And how vagrant differs from rhc and other client command line tools 
that are distributed as gems and follow this convention?

--
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: $HOME/.local/bin in $PATH



Am 30.10.2013 11:55, schrieb Alec Leamas:
 On 2013-10-30 11:46, Reindl Harald wrote:
 Am 30.10.2013 11:27, schrieb Alec Leamas:
 On 2013-10-30 11:23, Reindl Harald wrote:
 Am 30.10.2013 11:20, schrieb Alec Leamas:
 On 2013-10-30 10:58, Reindl Harald wrote:
 Am 30.10.2013 10:53, schrieb Alec Leamas:
 On 2013-10-30 10:23, Reindl Harald wrote:
 Am 30.10.2013 02:03, schrieb Chris Adams:
 Once upon a time, Reindl Harald h.rei...@thelounge.net said:
 [root@srv-rhsoft:~]$ mkdir test
 i could rm -rf ~/ here

 [root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir
 #!/bin/bash
 echo i could rm -rf ~/ here
 If I can write to files you own, it doesn't matter if there's a
 directory in the PATH or not.  I can write this to your .bash_profile:

/bin/mkdir $HOME/.bin 2 /dev/null
echo 'echo i could rm -rf ~/ here'  $HOME/.bin/mkdir
chmod +x $HOME/.bin/mkdir
PATH=$HOME/.bin:$PATH
 you can do this and that - but that's no valid argumentation
 doing bad things in default setups and *at least* do not
 place *hidden* diretories there, ther is a good reason why
 software like rkhunter alerts if you have hidden directories
 somewhere in /usr/bin/

 Some kind of reference for the bad in having a well-known, hidden 
 directory in the path?
 the *writeable for the user* is the problem
 Any reference for this problem?
 what about consider the implications?
 do you really need a written reference for any security relevant fact?
 i can write one for you if you prefer links :-)

 Well, the question is really if someone else out there share your concerns 
 about this
 anybody with interests in security

 https://www.google.at/search?q=ssh+chroot+why+needs+the+home+directory+to+be+owned+by+root

 http://binblog.info/2008/04/06/openssh-chrooted-sftp-eg-for-webhosting/
 However, the chroot destination must not be owned by the user for security 
 reasons

 So you are arguing that $HOME should be owned by root?!  

*no i do not*

i gave you a starting point to learn about security and the reason
for sftp-chroot doing so is that someone could use race-conditions
to bypass the security

if you do not understand that allowing any random application running
with your normal user permissions place a binary inside PATH is a bad
idea i really can not help you

security is *always* a process and layered, there are a lot of things
to consider in different levels and while you can not gain 100%
security you can make it harder to bypass restrictions on several
places and doing things which are clearly against is not smart

you can decide taht security is not that important for you
but a distribution as such should not make such wrong decisions for all users



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

Broken dependencies: perl-PDL



perl-PDL has broken dependencies in the F-20 tree:
On x86_64:
perl-PDL-2.4.10-6.fc19.x86_64 requires perl(:MODULE_COMPAT_5.16.2)
perl-PDL-2.4.10-6.fc19.x86_64 requires libgd.so.2()(64bit)
On i386:
perl-PDL-2.4.10-6.fc19.i686 requires perl(:MODULE_COMPAT_5.16.2)
perl-PDL-2.4.10-6.fc19.i686 requires libgd.so.2
Please resolve this as soon as possible.


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

Broken dependencies: perl-Padre



perl-Padre has broken dependencies in the F-20 tree:
On x86_64:
perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0)
On i386:
perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0)
On armhfp:
perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0)
Please resolve this as soon as possible.


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

Broken dependencies: perl-Language-Expr



perl-Language-Expr has broken dependencies in the F-20 tree:
On x86_64:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
On i386:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
On armhfp:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
Please resolve this as soon as possible.


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

Broken dependencies: perl-BerkeleyDB



perl-BerkeleyDB has broken dependencies in the F-20 tree:
On x86_64:
perl-BerkeleyDB-0.53-1.fc20.x86_64 requires libdb = 0:5.3.21
On i386:
perl-BerkeleyDB-0.53-1.fc20.i686 requires libdb = 0:5.3.21
On armhfp:
perl-BerkeleyDB-0.53-1.fc20.armv7hl requires libdb = 0:5.3.21
Please resolve this as soon as possible.


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

Broken dependencies: perl-MIME-Lite-HTML



perl-MIME-Lite-HTML has broken dependencies in the F-20 tree:
On x86_64:
perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires 
perl(:MODULE_COMPAT_5.16.0)
On i386:
perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires 
perl(:MODULE_COMPAT_5.16.0)
On armhfp:
perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires 
perl(:MODULE_COMPAT_5.16.0)
Please resolve this as soon as possible.


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

Broken dependencies: slic3r



slic3r has broken dependencies in the F-20 tree:
On x86_64:
slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3)
On i386:
slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3)
On armhfp:
slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3)
Please resolve this as soon as possible.


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

Re: $HOME/.local/bin in $PATH


On 2013-10-30 12:25, Reindl Harald wrote:


Am 30.10.2013 11:55, schrieb Alec Leamas:

On 2013-10-30 11:46, Reindl Harald wrote:

Am 30.10.2013 11:27, schrieb Alec Leamas:

On 2013-10-30 11:23, Reindl Harald wrote:

Am 30.10.2013 11:20, schrieb Alec Leamas:

On 2013-10-30 10:58, Reindl Harald wrote:

Am 30.10.2013 10:53, schrieb Alec Leamas:

On 2013-10-30 10:23, Reindl Harald wrote:

Am 30.10.2013 02:03, schrieb Chris Adams:

Once upon a time, Reindl Harald h.rei...@thelounge.net said:

[root@srv-rhsoft:~]$ mkdir test
i could rm -rf ~/ here

[root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir
#!/bin/bash
echo i could rm -rf ~/ here

If I can write to files you own, it doesn't matter if there's a
directory in the PATH or not.  I can write this to your .bash_profile:

/bin/mkdir $HOME/.bin 2 /dev/null
echo 'echo i could rm -rf ~/ here'  $HOME/.bin/mkdir
chmod +x $HOME/.bin/mkdir
PATH=$HOME/.bin:$PATH

you can do this and that - but that's no valid argumentation
doing bad things in default setups and *at least* do not
place *hidden* diretories there, ther is a good reason why
software like rkhunter alerts if you have hidden directories
somewhere in /usr/bin/


Some kind of reference for the bad in having a well-known, hidden directory in 
the path?

the *writeable for the user* is the problem

Any reference for this problem?

what about consider the implications?
do you really need a written reference for any security relevant fact?
i can write one for you if you prefer links :-)


Well, the question is really if someone else out there share your concerns 
about this

anybody with interests in security

https://www.google.at/search?q=ssh+chroot+why+needs+the+home+directory+to+be+owned+by+root

http://binblog.info/2008/04/06/openssh-chrooted-sftp-eg-for-webhosting/
However, the chroot destination must not be owned by the user for security 
reasons


So you are arguing that $HOME should be owned by root?!

*no i do not*

OK


i gave you a starting point to learn about security and the reason
for sftp-chroot doing so is that someone could use race-conditions
to bypass the security

if you do not understand that allowing any random application running
with your normal user permissions place a binary inside PATH is a bad
idea i really can not help you

security is *always* a process and layered, there are a lot of things
to consider in different levels and while you can not gain 100%
security you can make it harder to bypass restrictions on several
places and doing things which are clearly against is not smart

you can decide taht security is not that important for you
but a distribution as such should not make such wrong decisions for all users
No, it should not.  However,  the right decision is in many cases a 
trade-off between security and usabilty, not always with a single 
answer. Allowing users to install sw (i. e., allowing random 
applications to put things in $PATH) has of course security 
implications. Dis-allowing has usability aspects.  My personal view is 
that for the distribution  the defaults should  allow  and support 
user-installed sw.


And, isn't  this still a little off-topic? Current defaults already has 
~/bin in $PATH, and user can certainly put things there. Isn't the issue 
here if having a hidden, writeable directory in $PATH is such a bad 
idea, given that users actually can install sw?



--alec


--
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: $HOME/.local/bin in $PATH



Am 30.10.2013 13:00, schrieb Alec Leamas:
 On 2013-10-30 12:25, Reindl Harald wrote:
 i gave you a starting point to learn about security and the reason
 for sftp-chroot doing so is that someone could use race-conditions
 to bypass the security

 if you do not understand that allowing any random application running
 with your normal user permissions place a binary inside PATH is a bad
 idea i really can not help you

 security is *always* a process and layered, there are a lot of things
 to consider in different levels and while you can not gain 100%
 security you can make it harder to bypass restrictions on several
 places and doing things which are clearly against is not smart

 you can decide that security is not that important for you
 but a distribution as such should not make such wrong decisions for all users
 No, it should not.  However,  the right decision is in many cases a trade-off 
 between security and usabilty, not
 always with a single answer. Allowing users to install sw (i. e., allowing 
 random applications to put things in
 $PATH) has of course security implications. Dis-allowing has usability 
 aspects.  My personal view is that for the
 distribution the defaults should allow and support user-installed sw.

the distribution should *not* train users doing this in their userhome

that is why /usr/local exists and software besides packages belongs
there and should be installed as root, 1 out of 1000 users need
to install software in the userhome, if so they should learn
about the implications and have a small barrier

it's not that hard to edit .bash_profile but you need to do it by hand
which means you have to spend a thought about it which is completly
different to i did not know about the door i never opened by myself

 And, isn't  this still a little off-topic? 

no it is not because the topic is in the subject

 Current defaults already has ~/bin in $PATH, and user can certainly put
 things there. Isn't the issue here if having a hidden, writeable directory 
 in $PATH is such a bad idea, given that users actually can install sw?

guess how many users are aware of the hidden directory compared with
bin in the userhome and how often someone may take a look

you can now argue that the user does not look in both of them
and i argue that extaly *this* is the problem
the defaults are dangerous for the majority of ordinary users

but there are users sometimes take a look what is in their userhome
the chance doing also in hidden subdirectories is by zero



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: Drive arched subpackage from nonarched one

On Wed, Oct 30, 2013 at 09:26:49AM +0200, مصعب الزعبي wrote:
 I read that message, but I search for a tweak.
 So I'll separate main package into (-core) nonarched, and meta one arched.

Yes, that's the normal way to deal with this. -core or -common, depending on
what makes sense.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Agenda for Today's Cloud WG Meeting (2013-10-30 19:00 UTC)

Hello everyone. Our initial Cloud WG meeting today is today at 19:00 UTC
(3pm EDT). We'll use #fedora-meeting-1 (because the FESCo meeting in
#fedora-meeting has been running more than an hour). All are welcome.

== Communications ==

- mailing list vs. irc meetings 
- trac instance

== Next Steps ==

- draft governance https://fedoraproject.org/wiki/Cloud_WG
- PRD framework https://fedoraproject.org/wiki/Cloud_PRD

== Open Floor ==


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  mat...@fedoraproject.org
-- 
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: Duplicate review request for rubygem-vagrant

On Wed, Oct 30, 2013 at 12:04 PM, Josef Stribny jstri...@redhat.com wrote:
 On 10/30/2013 10:45 AM, Dridi Boukelmoune wrote:

 What prevails between the ruby naming guidelines and  the prior art
 rule (other distros package name) in the general naming guidelines ?

 https://fedoraproject.org/wiki/Packaging:NamingGuidelines#General_Naming
 http://packages.ubuntu.com/raring/vagrant
 http://packages.debian.org/stable/vagrant


 And how vagrant differs from rhc and other client command line tools that
 are distributed as gems and follow this convention?

I am wondering if you are being sarcastic. If not, please do not mind
this answer.

If yes, this was a genuine question. I'm not saying this should be
named vagrant, just that I like the name better. It's just that some
rules conflict on this matter, and I don't know the answer. I might
package ruby stuff in the future though I haven't planned anything so
far. As I said in the next sentence, I'm more concerned about the
double review.

Sincerely,
Dridi

 --
 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: $HOME/.local/bin in $PATH


On 2013-10-30 13:08, Reindl Harald wrote:


Am 30.10.2013 13:00, schrieb Alec Leamas:

On 2013-10-30 12:25, Reindl Harald wrote:

i gave you a starting point to learn about security and the reason
for sftp-chroot doing so is that someone could use race-conditions
to bypass the security

if you do not understand that allowing any random application running
with your normal user permissions place a binary inside PATH is a bad
idea i really can not help you

security is *always* a process and layered, there are a lot of things
to consider in different levels and while you can not gain 100%
security you can make it harder to bypass restrictions on several
places and doing things which are clearly against is not smart

you can decide that security is not that important for you
but a distribution as such should not make such wrong decisions for all users

No, it should not.  However,  the right decision is in many cases a trade-off 
between security and usabilty, not
always with a single answer. Allowing users to install sw (i. e., allowing 
random applications to put things in
$PATH) has of course security implications. Dis-allowing has usability aspects. 
 My personal view is that for the
distribution the defaults should allow and support user-installed sw.

the distribution should *not* train users doing this in their userhome

that is why /usr/local exists and software besides packages belongs
there and should be installed as root, 1 out of 1000 users need
to install software in the userhome, if so they should learn
about the implications and have a small barrier

it's not that hard to edit .bash_profile but you need to do it by hand
which means you have to spend a thought about it which is completly
different to i did not know about the door i never opened by myself


And, isn't  this still a little off-topic?

no it is not because the topic is in the subject


Current defaults already has ~/bin in $PATH, and user can certainly put
things there. Isn't the issue here if having a hidden, writeable directory
in $PATH is such a bad idea, given that users actually can install sw?

guess how many users are aware of the hidden directory compared with
bin in the userhome and how often someone may take a look

you can now argue that the user does not look in both of them
and i argue that extaly *this* is the problem
the defaults are dangerous for the majority of ordinary users

but there are users sometimes take a look what is in their userhome
the chance doing also in hidden subdirectories is by zero

I'm not convinced by your arguments, and to be fair I havn't really 
argued for my own position. I suggest that we agree on that we disagree:

 - if  user-installed sw in $HOME should be supported.
 - if  having ~/.local/bin in $PATH is a bad enough idea to drop it.

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

F-20 Branched report: 20131030 changes

2013-10-30 Thread Fedora Branched Report

Compose started at Wed Oct 30 09:15:02 UTC 2013

Broken deps for armhfp
--
[blueman]
blueman-1.23-7.fc20.armv7hl requires obex-data-server = 0:0.4.3
blueman-1.23-7.fc20.armv7hl requires gvfs-obexftp
[bwm-ng]
bwm-ng-0.6-11.1.fc20.armv7hl requires libstatgrab.so.9
[cloud-init]
cloud-init-0.7.2-7.fc20.noarch requires dmidecode
[cobbler]
cobbler-2.4.0-2.fc20.noarch requires syslinux
[condor-wallaby]
condor-wallaby-client-5.0.3-4.fc20.noarch requires python-qmf = 
0:0.9.1073306
[fts]
fts-server-3.1.1-1.fc20.armv7hl requires libactivemq-cpp.so.14
[glpi]
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Version
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Stdlib
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-ServiceManager
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Loader
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-I18n
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Cache-apc
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Cache
[gnome-do-plugins]
gnome-do-plugins-thunderbird-0.8.4-14.fc20.armv7hl requires thunderbird
[gofer]
ruby-gofer-0.75-4.fc20.noarch requires rubygem(qpid) = 0:0.16.0
[gradle]
gradle-1.0-18.fc20.noarch requires plexus-container-default
[grass]
grass-6.4.3-2.fc20.armv7hl requires libgeos-3.3.8.so
grass-libs-6.4.3-2.fc20.armv7hl requires libgeos-3.3.8.so
[gtkd]
gtkd-geany-tags-2.0.0-29.20120815git9ae9181.fc18.noarch requires gtkd = 
0:2.0.0-29.20120815git9ae9181.fc18
[kawa]
1:kawa-1.11-5.fc19.armv7hl requires servlet25
[koji]
koji-vm-1.8.0-2.fc20.noarch requires python-virtinst
[kyua-cli]
kyua-cli-0.5-3.fc19.armv7hl requires liblutok.so.0
kyua-cli-tests-0.5-3.fc19.armv7hl requires liblutok.so.0
[monotone]
monotone-1.0-11.fc19.armv7hl requires libbotan-1.8.2.so
perl-Monotone-1.0-11.fc19.armv7hl requires perl(:MODULE_COMPAT_5.16.2)
[mozilla-firetray]
mozilla-firetray-thunderbird-0.3.6-0.5.143svn.fc18.1.armv7hl requires 
thunderbird = 0:11
[msp430-libc]
msp430-libc-20120224-2.fc19.noarch requires msp430-gcc = 0:4.6.3
[nifti2dicom]
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtksys.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkWidgets.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkVolumeRendering.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkViews.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkTextAnalysis.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkRendering.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkParallel.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkInfovis.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkImaging.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkIO.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkHybrid.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGraphics.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGeovis.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGenericFiltering.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkFiltering.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCommon.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCharts.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libQVTK.so.5.10
[nocpulse-common]
nocpulse-common-2.2.7-2.fc20.noarch requires perl(RHN::DBI)
[openbox]
gdm-control-3.5.2-2.fc20.armv7hl requires gnome-panel
gnome-panel-control-3.5.2-2.fc20.armv7hl requires gnome-panel
[openpts]
openpts-0.2.6-7.fc20.armv7hl requires tboot
[osm2pgsql]
osm2pgsql-0.82.0-1.fc20.armv7hl requires libgeos-3.3.8.so
[oyranos]
oyranos-libs-0.4.0-7.fc19.armv7hl requires libraw.so.5
[perl-BerkeleyDB]
perl-BerkeleyDB-0.53-1.fc20.armv7hl requires libdb = 0:5.3.21
[perl-Language-Expr]
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
[perl-MIME-Lite-HTML]
perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires 
perl(:MODULE_COMPAT_5.16.0)
[perl-Padre]
perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0)
[pure]
pure-doc-0.57-4.fc20.noarch requires pure = 0:0.57-4.fc20
[python-tag]
python-tag-2013.1-1.fc20.armv7hl requires libboost_python.so.1.53.0
[rootplot]
rootplot-2.2.1-7.fc19.noarch requires root-python
[ruby-spqr]
ruby-spqr-0.3.6-7.fc20.noarch requires ruby-qpid-qmf
[rubygem-audited-activerecord]
rubygem-audited-activerecord-3.0.0-3.fc19.noarch requires 
rubygem(activerecord)  0:4
[rubygem-fog]
rubygem-fog-1.11.1-1.fc20.noarch requires rubygem(nokogiri)  0:1.6
[scala]

Re: $HOME/.local/bin in $PATH

2013-10-30 Thread Petr Viktorin


On 10/30/2013 01:08 PM, Reindl Harald wrote:



Am 30.10.2013 13:00, schrieb Alec Leamas:

On 2013-10-30 12:25, Reindl Harald wrote:

i gave you a starting point to learn about security and the reason
for sftp-chroot doing so is that someone could use race-conditions
to bypass the security

if you do not understand that allowing any random application running
with your normal user permissions place a binary inside PATH is a bad
idea i really can not help you

security is *always* a process and layered, there are a lot of things
to consider in different levels and while you can not gain 100%
security you can make it harder to bypass restrictions on several
places and doing things which are clearly against is not smart

you can decide that security is not that important for you
but a distribution as such should not make such wrong decisions for all users

No, it should not.  However,  the right decision is in many cases a trade-off 
between security and usabilty, not
always with a single answer. Allowing users to install sw (i. e., allowing 
random applications to put things in
$PATH) has of course security implications. Dis-allowing has usability aspects. 
 My personal view is that for the
distribution the defaults should allow and support user-installed sw.


the distribution should *not* train users doing this in their userhome

that is why /usr/local exists and software besides packages belongs
there and should be installed as root, 1 out of 1000 users need
to install software in the userhome,


Do you have any source for that assumption?
For example university students usually simply can't install as root.


if so they should learn
about the implications and have a small barrier


No, they should just install the software and be done with it.


it's not that hard to edit .bash_profile but you need to do it by hand
which means you have to spend a thought about it which is completly
different to i did not know about the door i never opened by myself


Why should I do that? I expect `pip install --user` to install my 
package without me having to fiddle with .bash_profile.



And, isn't  this still a little off-topic?


no it is not because the topic is in the subject


Current defaults already has ~/bin in $PATH, and user can certainly put
things there. Isn't the issue here if having a hidden, writeable directory
in $PATH is such a bad idea, given that users actually can install sw?


guess how many users are aware of the hidden directory compared with
bin in the userhome and how often someone may take a look


Also guess how many users don't care.
Do you have data to make anything else than a guess?


you can now argue that the user does not look in both of them
and i argue that extaly *this* is the problem
the defaults are dangerous for the majority of ordinary users


I personally like that ~/bin contains what I put there myself by hand, 
and ~/.local/bin has what was installed via pip.



but there are users sometimes take a look what is in their userhome
the chance doing also in hidden subdirectories is by zero


This is wild speculation.
You can just echo $PATH to see what directories are in $PATH.


Also, if you bother securing .bash_profile so that rogue programs can't 
write into it, you can easily check if $PATH is set the way you want it.
If you don't bother, it doesn't matter if malware installs to 
~/.local/bin/rootkit or ~/.rootkit


--
Petr³

--
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: Duplicate review request for rubygem-vagrant

2013-10-30 Thread Lukas Zapletal

 And how vagrant differs from rhc and other client command line tools
 that are distributed as gems and follow this convention?

What I would like to see in both rhc and vagrant would be:

Provides: rhc

respectively

Provides: vagrant

It feels natural to me, I have issued yum install rhc several times
already. Annoying.

-- 
Later,

 Lukas lzap Zapletal
 irc: lzap #theforeman
-- 
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: Duplicate review request for rubygem-vagrant

On Wed, Oct 30, 2013 at 1:41 PM, Lukas Zapletal l...@redhat.com wrote:
 And how vagrant differs from rhc and other client command line tools
 that are distributed as gems and follow this convention?

 What I would like to see in both rhc and vagrant would be:

 Provides: rhc

 respectively

 Provides: vagrant

 It feels natural to me, I have issued yum install rhc several times
 already. Annoying.

Thanks for enlightening me, I understand your previous mail better.
And yes I agree with you, ultimately I'm waiting for vagrant and I'd
rather install it as yum install vagrant, regardless of the actual
package name.

Dridi

 --
 Later,

  Lukas lzap Zapletal
  irc: lzap #theforeman
 --
 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: Duplicate review request for rubygem-vagrant

2013-10-30 Thread Vít Ondruch


Dne 30.10.2013 13:23, Dridi Boukelmoune napsal(a):

On Wed, Oct 30, 2013 at 12:04 PM, Josef Stribny jstri...@redhat.com wrote:

On 10/30/2013 10:45 AM, Dridi Boukelmoune wrote:

What prevails between the ruby naming guidelines and  the prior art
rule (other distros package name) in the general naming guidelines ?

https://fedoraproject.org/wiki/Packaging:NamingGuidelines#General_Naming
http://packages.ubuntu.com/raring/vagrant
http://packages.debian.org/stable/vagrant



And how vagrant differs from rhc and other client command line tools that
are distributed as gems and follow this convention?

I am wondering if you are being sarcastic. If not, please do not mind
this answer.

If yes, this was a genuine question. I'm not saying this should be
named vagrant, just that I like the name better. It's just that some
rules conflict on this matter, and I don't know the answer. I might
package ruby stuff in the future though I haven't planned anything so
far. As I said in the next sentence, I'm more concerned about the
double review.

Sincerely,
Dridi



There is more examples of Ruby packages, such as deltacloud-core, 
puppet, which don't use the rubygem-prefix. The question is if vagrant 
is application or library.


If it is application, then it should be without rubygem- prefix and 
should not install into rubygems directory. If that is library, then it 
should have the rubygem- prefix and install among other rubygems. But 
the border might be fuzzy.



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

Draft Workstation WG Governance Charter

Hi All,

Below is a draft governance charter for the Workstation WG.  I have
taken much of this from the Cloud WG draft charter (found here:
https://fedoraproject.org/wiki/Cloud_WG) to have some commonality
between groups.  I left some of the sections from that off for now, as
I think that is their main landing page and we can fill in those
sections with our relevant details as we go.

Please read it over and provide any feedback or ask any questions you
may have.  Thanks!

josh

== Fedora Workstation WG Governance ==

This document describes the governing structure for the Fedora
Workstation Work Group.

=== Membership ===

The Fedora Workstation Work Group has nine voting members, with one
member selected by the Fedora Engineering Steering Committee as the
liaison to FESCo.

Members of the Working Group serve two year terms. At the end of the
two year period, FESCo will either renew the FESCo liaison or appoint
a new one. The other positions will be filled by general election
every two years. As a special exception, four seats will be filled in
one year, with those positions chosen at random (unless some number of
members decide to step down). Voting will follow the standard Fedora
election process and be open to all contributors in the CLA+1 group.

In the event that a current member relinquishes their seat, that seat
will be filled by the first runner up in the previous election.  If
that person is not able or willing to fill the seat, it will go to
each successive runner up until the seat is filled.  If there are no
candidates available or remaining from the previous election, the Work
Group will fill the seat by selecting a candidate and approving by
majority consensus.

NOTE: Clearly all of the above is open for discussion.  I've modelled
it after how FESCo current does their membership to a large degree.
If we want something else, please follow up with alternative
suggestions.

=== Current Members ===

* Josh Boyer (FESCo Liaison)
* Matthias Clasen
* Kalev Lember
* Ryan Lerch
* Jens Petersen
* Christian Schaller
* Owen Taylor
* Lukáš Tinkl
* Christoph Wickert

=== Making Decisions ===

Because Fedora is a global project, members of the working group may
be distributed across multiple timezones. It may be possible to have a
real-time IRC meetings, but in general we will conduct business on the
mailing list.

Many of our decisions can be made through lazy consensus;. Under
this model, an intended action is announced on the mailing list,
discussed, and if there is no controversy or dissenting views with a
few days, simply done.

For bigger issues, where there may be disagreement, or where there is
long-term impact, or where an action may not easily be undone, we will
[1]... Working group members can vote +1 to approve, -1 to disagree,
or 0 to abstain; five +1 votes are necessary for a measure to pass.
Non-members may comment on the item and (of course) discuss on the
mailing list, but are asked to refrain from putting votes.

[1] NOTE: for the workstation WG, we have the following option for
dispute resolution:

1) Use a trac ticketing system as the cloud WG is doing
2) Come up with an official proposal voting system on the mailing list
(specific Subject: [Proposal for Vote] ... or something).
3) Schedule an IRC meeting and do the vote live.

I'm fine with any of these, though I will point out that live meetings
across all of our relevant timezones are difficult.  If we choose to
have a trac ticketing system (which can be used for votes and for
people to report issues), I can get that created.

=== Changing these Rules ===

This document will be approved by consensus of the initial Working
Group members and approved by FESCo. After initial ratification, any
substantive changes can be approved by majority vote and sent to FESCo
for acceptance.
-- 
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: Agenda for Today's Cloud WG Meeting (2013-10-30 19:00 UTC)

On Wed, Oct 30, 2013 at 8:20 AM, Matthew Miller
mat...@fedoraproject.org wrote:
 Hello everyone. Our initial Cloud WG meeting today is today at 19:00 UTC
 (3pm EDT). We'll use #fedora-meeting-1 (because the FESCo meeting in
 #fedora-meeting has been running more than an hour). All are welcome.

 == Communications ==

 - mailing list vs. irc meetings
 - trac instance

 == Next Steps ==

 - draft governance https://fedoraproject.org/wiki/Cloud_WG

(I really really! hate wikis for doing drafts because commenting on
them this way is horrible.)

You have basically the top-level landing page for the WG there.  It
has all the relevant information one would expect, but I think some of
the sections go beyond governance.  Specifically, the Mission, Role in
Fedora, and Communications section aren't really related to the
governance _of_ the WG.  Maybe create a ==Governance== section and
split it to it's own page?

Under the membership section, you don't have anything regarding what
happens if you have a member relinquish their seat.  I added the
following to the Workstation draft.  Just an FYI:

In the event that a current member relinquishes their seat, that seat
will be filled by the first runner up in the previous election.  If
that person is not able or willing to fill the seat, it will go to
each successive runner up until the seat is filled.  If there are no
candidates available or remaining from the previous election, the Work
Group will fill the seat by selecting a candidate and approving by
majority consensus.

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

Schedule for Wednesday's (today's) FESCo meeting (2013-10-30)

2013-10-30 Thread Bill Nottingham

(Apologies for the lateness.)

Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2013-10-30 18:00 UTC'

NOTE: Due to DST switches in certain locales, please double check the
meeting time in your area.

Links to all tickets below can be found at: 
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #1170 Working Group call for volunteers
.fesco 1170
https://fedorahosted.org/fesco/ticket/1170

#topic #1180 Build virt-preview in Koji
.fesco 1180
https://fedorahosted.org/fesco/ticket/1180

= New business =

#topic #1185 Enable -Werror=format-security by default
.fesco 1185
https://fedorahosted.org/fesco/ticket/1185

#topic #1186 FESCo liason role in WGs
.fesco 1186
https://fedorahosted.org/fesco/ticket/1186

#topic #1187 Packagers should be not be allowed to ignore RH bugzilla
.fesco 1187
https://fedorahosted.org/fesco/ticket/1187

= Open Floor = 

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 
-- 
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: Duplicate review request for rubygem-vagrant




What prevails between the ruby naming guidelines and  the prior art
rule (other distros package name) in the general naming guidelines ?

https://fedoraproject.org/wiki/Packaging:NamingGuidelines#General_Naming 


http://packages.ubuntu.com/raring/vagrant
http://packages.debian.org/stable/vagrant


And how vagrant differs from rhc and other client command line tools 
that

are distributed as gems and follow this convention?

I am wondering if you are being sarcastic. If not, please do not mind
this answer.
I am indeed very sarcastic person, but this time it's just my genuine 
question.
I wrote this as I don't use vagrant, so I don't know. I just want to see 
some consistence.


There is more examples of Ruby packages, such as deltacloud-core, 
puppet, which don't use the rubygem-prefix. The question is if vagrant 
is application or library.


If it is application, then it should be without rubygem- prefix and 
should not install into rubygems directory. If that is library, then 
it should have the rubygem- prefix and install among other rubygems. 
But the border might be fuzzy.

Many RubyGems are both libs and programs, aren't they?



--
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: Duplicate review request for rubygem-vagrant


On 10/30/2013 01:41 PM, Lukas Zapletal wrote:

And how vagrant differs from rhc and other client command line tools
that are distributed as gems and follow this convention?

What I would like to see in both rhc and vagrant would be:

Provides: rhc

respectively

Provides: vagrant

It feels natural to me, I have issued yum install rhc several times
already. Annoying.


Yes, actually rhc as rubygem-rhc was a bit confusing for me as well.
--
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 1024821] New: ctstream-9 is available

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

Bug ID: 1024821
   Summary: ctstream-9 is available
   Product: Fedora
   Version: rawhide
 Component: ctstream
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-de...@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 9
Current version/release in Fedora Rawhide: 8-3.fc20
URL: http://xpisar.wz.cz/ctstream/

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=ukXA0cLQPna=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Language-Expr



perl-Language-Expr has broken dependencies in the rawhide tree:
On x86_64:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
On i386:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
On armhfp:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
Please resolve this as soon as possible.


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

Re: Duplicate review request for rubygem-vagrant

On Wed, Oct 30, 2013 at 2:18 PM, Josef Stribny jstri...@redhat.com wrote:

 What prevails between the ruby naming guidelines and  the prior art
 rule (other distros package name) in the general naming guidelines ?


 https://fedoraproject.org/wiki/Packaging:NamingGuidelines#General_Naming
 http://packages.ubuntu.com/raring/vagrant
 http://packages.debian.org/stable/vagrant


 And how vagrant differs from rhc and other client command line tools
 that
 are distributed as gems and follow this convention?

 I am wondering if you are being sarcastic. If not, please do not mind
 this answer.

 I am indeed very sarcastic person, but this time it's just my genuine
 question.
 I wrote this as I don't use vagrant, so I don't know. I just want to see
 some consistence.

Looks like I took Lukas' answer for yours :s

 There is more examples of Ruby packages, such as deltacloud-core, puppet,
 which don't use the rubygem-prefix. The question is if vagrant is
 application or library.

 If it is application, then it should be without rubygem- prefix and should
 not install into rubygems directory. If that is library, then it should have
 the rubygem- prefix and install among other rubygems. But the border might
 be fuzzy.

 Many RubyGems are both libs and programs, aren't they?




 --
 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: Agenda for Today's Cloud WG Meeting (2013-10-30 19:00 UTC)

On Wed, Oct 30, 2013 at 09:06:30AM -0400, Josh Boyer wrote:
 You have basically the top-level landing page for the WG there.  It
 has all the relevant information one would expect, but I think some of
 the sections go beyond governance.  Specifically, the Mission, Role in
 Fedora, and Communications section aren't really related to the
 governance _of_ the WG.  Maybe create a ==Governance== section and
 split it to it's own page?

Yeah, that's good feedback. Some of it is more charter than governance.

 Under the membership section, you don't have anything regarding what
 happens if you have a member relinquish their seat.  I added the
 following to the Workstation draft.  Just an FYI:

*nod* I think that partly depends on whether we want to follow the election
or appointee model.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  mat...@fedoraproject.org
-- 
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: $HOME/.local/bin in $PATH

2013-10-30 Thread Christopher

On Wed, Oct 30, 2013 at 6:27 AM, Alec Leamas leamas.a...@gmail.com wrote:
 On 2013-10-30 11:23, Reindl Harald wrote:

 Am 30.10.2013 11:20, schrieb Alec Leamas:

 On 2013-10-30 10:58, Reindl Harald wrote:

 Am 30.10.2013 10:53, schrieb Alec Leamas:

 On 2013-10-30 10:23, Reindl Harald wrote:

 Am 30.10.2013 02:03, schrieb Chris Adams:

 Once upon a time, Reindl Harald h.rei...@thelounge.net said:

 [root@srv-rhsoft:~]$ mkdir test
 i could rm -rf ~/ here

 [root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir
 #!/bin/bash
 echo i could rm -rf ~/ here

 If I can write to files you own, it doesn't matter if there's a
 directory in the PATH or not.  I can write this to your
 .bash_profile:

   /bin/mkdir $HOME/.bin 2 /dev/null
   echo 'echo i could rm -rf ~/ here'  $HOME/.bin/mkdir
   chmod +x $HOME/.bin/mkdir
   PATH=$HOME/.bin:$PATH

 you can do this and that - but that's no valid argumentation
 doing bad things in default setups and *at least* do not
 place *hidden* diretories there, ther is a good reason why
 software like rkhunter alerts if you have hidden directories
 somewhere in /usr/bin/

 Some kind of reference for the bad in having a well-known, hidden
 directory in the path?

 the *writeable for the user* is the problem

 Any reference for this problem?

 what about consider the implications?
 do you really need a written reference for any security relevant fact?
 i can write one for you if you prefer links :-)

 Well, the question is really if someone else out there share your concerns
 about this.

I share them, and I agree that it is the argument, not a citation,
that demonstrates the merits of the security case.

Supporting user-installed software in $HOME is a fine goal... but it
shouldn't be done in a way that puts user-installed software earlier
in the path by default, or expanding the number of points for users to
watch for bad-behaving apps. As a long-time user of Fedora, I'd have
never even thought of checking for executables in ~/.local/bin, until
I happened to read this thread... and when I did, it was quite
unnerving.

The one reprieve from all this, is that, when I checked, it was later
in the path than the system paths (at least for me), not earlier, as
was previously asserted in this thread.

Of course, one can always check the contents of $PATH directly... but
there's some level of trust here... because that can get quite long,
and lazy users like me assume (perhaps badly) that if we didn't modify
it in our login scripts, it wasn't modified to include any additional
user-writable paths beyond ~/bin

And, the xdg argument doesn't seem like a sufficient argument for
me... we're talking about login scripts, not X. It is very unintuitive
that an xdg-related directory would be on the default path for a bash
login, if you're not even running X. This is a bash profile... not an
X profile...

The biggest problem isn't that it's hidden or that it's there by
default, or that it's writable by potentially bad-behaving software.
The biggest problem is simply that users don't know about it. I
certainly didn't.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
-- 
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: [Fwd: F19: yum groups mark convert problem]

2013-10-30 Thread Dario Lesca

Il giorno mar, 29/10/2013 alle 16.57 -0400, Przemek Klosowski ha
scritto:
 On 10/29/2013 02:07 PM, Dario Lesca wrote:
 
  Il giorno mar, 29/10/2013 alle 09.38 +0100, Dario Lesca ha scritto:
   Sorry for cross post, but I would avoid to reinstall my notebook
   Someone can help me?
  
  Since I had not gotten any suggestion, today I have tray this command:
  
  # yum update --bugfix --security
  
  
  
  Now all work fine, I have no idea what happened, but now I can update my
  system.
  
 I would like to invite you to file a bug against yum on Fedora, using
 https://bugzilla.redhat.com . Please explain in detail what happened
 and how you resolved it:
 
 - what you did ('yum groups mark convert', presumably) 
 - why you did that (presumably something to do with un-installing
 Cinnamon desktop?)
 - what happened then (include error messages, and perhaps attach
 the /var/log/yum.log)
 - what you did to fix it and how you got the idea
 
 Having a permanent record of this in bugzilla is probably more helpful
 for the yum developers in case it touches some latent bugs that they
 may be working on. 

Done:

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

 Thanks for your help making Fedora better

Fedora IS the best!

Thank you!

-- 
Dario Lesca - sip:da...@solinos.it
(Inviato dal mio Linux Fedora19+Gnome3.8)

-- 
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: $HOME/.local/bin in $PATH

2013-10-30 Thread Ralf Corsepius


On 10/30/2013 01:08 PM, Reindl Harald wrote:


Am 30.10.2013 13:00, schrieb Alec Leamas:

On 2013-10-30 12:25, Reindl Harald wrote:
No, it should not. However, the right decision is in many cases a 
trade-off between security and usabilty, not always with a single 
answer. Allowing users to install sw (i. e., allowing random 
applications to put things in $PATH) has of course security 
implications. Dis-allowing has usability aspects. My personal view is 
that for the distribution the defaults should allow and support 
user-installed sw. 

the distribution should *not* train users doing this in their userhome

Nonsense.


that is why /usr/local exists


/usr/local exist to allow sys-admins to override the system-wide 
installation (/ and /usr).



  and software besides packages belongs
there and should be installed as root, 1 out of 1000 users need
to install software in the userhome, if so they should learn
about the implications and have a small barrier

You should not start to generalize on your limited scope of use-cases.

Surely there are installations where users are not allowed to install 
executables, but this is just local convention and by no means is the norm.


Besides that, what and where users put things underneath of $HOME is not 
a distro's busness.


Ralf

--
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: $HOME/.local/bin in $PATH


On 2013-10-30 15:05, Christopher wrote:

On Wed, Oct 30, 2013 at 6:27 AM, Alec Leamas leamas.a...@gmail.com wrote:

On 2013-10-30 11:23, Reindl Harald wrote:

Am 30.10.2013 11:20, schrieb Alec Leamas:

On 2013-10-30 10:58, Reindl Harald wrote:

Am 30.10.2013 10:53, schrieb Alec Leamas:

Some kind of reference for the bad in having a well-known, hidden
directory in the path?

the *writeable for the user* is the problem

Any reference for this problem?

what about consider the implications?
do you really need a written reference for any security relevant fact?
i can write one for you if you prefer links :-)


Well, the question is really if someone else out there share your concerns
about this.

I share them, and I agree that it is the argument, not a citation,
that demonstrates the merits of the security case.

Supporting user-installed software in $HOME is a fine goal... but it
shouldn't be done in a way that puts user-installed software earlier
in the path by default, or expanding the number of points for users to
watch for bad-behaving apps. As a long-time user of Fedora, I'd have
never even thought of checking for executables in ~/.local/bin, until
I happened to read this thread... and when I did, it was quite
unnerving.

The one reprieve from all this, is that, when I checked, it was later
in the path than the system paths (at least for me), not earlier, as
was previously asserted in this thread.
Yup, same for me, it's after the system paths. Which is fine, 
user-installed sw should not override system's by default.

[cut]

And, the xdg argument doesn't seem like a sufficient argument for
me... we're talking about login scripts, not X. It is very unintuitive
that an xdg-related directory would be on the default path for a bash
login, if you're not even running X. This is a bash profile... not an
X profile...
Still, actual usecases such as pip install are not limited to GUI 
programs. IMHO, the need for user installs together with the already 
established ~/.local/share makes it natural to use ~/.local as an 
installation prefix. Which implies  ~/.local/bin and also ~/.local/lib 
in the long run. Why should this just apply to GUI programs?

The biggest problem isn't that it's hidden or that it's there by
default, or that it's writable by potentially bad-behaving software.
The biggest problem is simply that users don't know about it. I
certainly didn't.
Agreed, this is the problem. However, to me it  seems better to use a 
consistent solution based on ~/.local rather than having each 
user-installed non-rpm package create it's own idea of a bin directory,  
possibly fiddling witg $PATH to make it work. Yes, it takes some time to 
learn - but isn't it actually easier in the long run?


--alec
--
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: $HOME/.local/bin in $PATH



Am 30.10.2013 15:29, schrieb Ralf Corsepius:
 On 10/30/2013 01:08 PM, Reindl Harald wrote:
 Besides that, what and where users put things underneath of $HOME is not a 
 distro's busness

and so it is not a distro's business to add something to $PATH
inside the userhome and finally you agreed what i said by try
to disagree



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: Draft Workstation WG Governance Charter

2013-10-30 Thread Matthew Garrett

On Wed, Oct 30, 2013 at 09:01:52AM -0400, Josh Boyer wrote:

 The Fedora Workstation Work Group has nine voting members, with one
 member selected by the Fedora Engineering Steering Committee as the
 liaison to FESCo.

Is the FESCo appointed member one of the nine voting members?

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
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 1024884] New: perl-Devel-Symdump-2.11 is available

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

Bug ID: 1024884
   Summary: perl-Devel-Symdump-2.11 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-de...@lists.fedoraproject.org,
pertu...@free.fr



Latest upstream release: 2.11
Current version/release in Fedora Rawhide: 2.10-4.fc20
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=sN6Kl2LYQBa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: [Fedora Base Design WG] Initial committee proposal and selection reasoning

On Mon, Oct 28, 2013 at 10:56 AM, Josh Boyer jwbo...@fedoraproject.org wrote:
 On Mon, Oct 28, 2013 at 10:43 AM, Phil Knirsch pknir...@redhat.com wrote:
 On 10/28/2013 03:36 PM, Jóhann B. Guðmundsson wrote:


 On 10/28/2013 01:20 PM, Phil Knirsch wrote:

 Hi everyone.

 As FESCO appointed me last Wednesday as the coordinator for the Fedora
 Base Design WG i wanted to start reaching out as soon as possible.

 The first task of a coordinator is to select and present the initial
 voting committee for the WG, chosen from the volunteers on
 https://fedoraproject.org/wiki/Fedora.next/WG_Nominations and add that
 to the corresponding fedora ticket
 https://fedorahosted.org/fesco/ticket/1170

 My approach and criteria for the selection was as follows:

 a) Include as many community members as possible as their
 representation in the volunteer list was already rather low and we
 really wanted to get at least 50% community members in there.


 Afaik you chose none.


 See my comments about Jon Disnard later in my text, i assumed he was still a
 community member only to hear about him being a RH employee for less than a
 month now on Friday evening.

 Unfortunately the only person from QE was Jóhann B. Guðmundsson, but
 he is already a committee member in the Server WG. Same goes for
 infrastructure where Kevin Fenzi is as well in the Server WG already.



 There is no rule to that says nominators cant serve on more the one
 group, infact there exist quite bit of overlap already so both of us
 could have been choisen...



 Looking at https://fedorahosted.org/fesco/ticket/1170 i see no overlap
 between all 4 WGs so far, but maybe i'm missing something.

 I'm coordinator for the Workstation WG, and also up for the Base WG.
 I did this willingly.

So thinking about this more, I'll point out that I told Phil
originally that I'm happy to participate from a kernel perspective
regardless.  I don't need to be a voting member of this WG to cover
that.  I'll already be working with all of the WGs from a kernel
perspective anyway, since they all have somewhat differing needs.  If
there is someone that is better suited to discussing and driving the
base of our products, I'm more than willing for them to take my place
on this WG.

josh
-- 
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: Draft Workstation WG Governance Charter

On Wed, Oct 30, 2013 at 10:39 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
 On Wed, Oct 30, 2013 at 09:01:52AM -0400, Josh Boyer wrote:

 The Fedora Workstation Work Group has nine voting members, with one
 member selected by the Fedora Engineering Steering Committee as the
 liaison to FESCo.

 Is the FESCo appointed member one of the nine voting members?

For the initial voting set, yes.  Going forward, I've asked FESCo to
clarify that with this ticket to be discussed at today's FESCo
meeting:

https://fedorahosted.org/fesco/ticket/1186

When I asked in IRC, I got different replies from different FESCo
members so they need to clear it up.  For now, I'm assuming yes the
liaison will always be a voting member.  If that changes, I will
change the draft to reflect that it need not be that way (and probably
flesh out what the role does then).

josh
-- 
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 1024894] New: perl-Perl-Critic-Deprecated-1.119 is available

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

Bug ID: 1024894
   Summary: perl-Perl-Critic-Deprecated-1.119 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Perl-Critic-Deprecated
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: mmasl...@redhat.com,
perl-de...@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 1.119
Current version/release in Fedora Rawhide: 1.108-9.fc20
URL: http://search.cpan.org/dist/Perl-Critic-Deprecated/

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=BWyuSRIJaBa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: $HOME/.local/bin in $PATH

2013-10-30 Thread Daniel J Walsh

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/29/2013 09:03 PM, Chris Adams wrote:
 Once upon a time, Reindl Harald h.rei...@thelounge.net said:
 [root@srv-rhsoft:~]$ mkdir test i could rm -rf ~/ here
 
 [root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir #!/bin/bash echo i could
 rm -rf ~/ here
 
 If I can write to files you own, it doesn't matter if there's a directory
 in the PATH or not.  I can write this to your .bash_profile:
 
 /bin/mkdir $HOME/.bin 2 /dev/null echo 'echo i could rm -rf ~/ here' 
 $HOME/.bin/mkdir chmod +x $HOME/.bin/mkdir PATH=$HOME/.bin:$PATH
 
 Sure, it might not take effect immediately, but that's probably not the 
 point (I can't depend on you running mkdir in a shell at any particular
 point in time anyway).  You wouldn't gain anything security-wise by
 excluding a user-writable directory in PATH.
 
 In fact, having a known ~/.local/bin could allow for a more restrictive
 SELinux policy on that directory that doesn't let arbitrary programs
 running as the user write there (don't know if that is the case though).
 
 matchpathcon /home/dwalsh/bin /home/dwalsh/.local/bin
/home/dwalsh/binstaff_u:object_r:home_bin_t:s0
/home/dwalsh/.local/bin staff_u:object_r:home_bin_t:s0


We are doing this in some form, although more towards, the only files in the
users homedir is allowed to execute is in the home_bin_t directory.

We do try to block confined apps from writing to user_home_t which is most
files in ~ and also home_bin_t.

The only reference to home_bin_t on the target right now is the following.

 sesearch -A -t home_bin_t -c file | grep home_bin_t
   allow postfix_local_t home_bin_t : file { ioctl read getattr execute
execute_no_trans open } ;
   allow procmail_t home_bin_t : file { ioctl read getattr execute
execute_no_trans open } ;

Of course lots of user domains and unconfined domains are allowed to write to
home_bin_t.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJxHH0ACgkQrlYvE4MpobOjDwCfaMO1bL17awLmc+F+DbWv44it
IEwAmgKT5WIdNege1rE+IS8ISXGLJlca
=Fc9n
-END 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

[Bug 1024896] New: perl-Perl-Critic-More-1.003 is available

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

Bug ID: 1024896
   Summary: perl-Perl-Critic-More-1.003 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Perl-Critic-More
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: mmasl...@redhat.com,
perl-de...@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 1.003
Current version/release in Fedora Rawhide: 1.000-11.fc20
URL: http://search.cpan.org/dist/Perl-Critic-More/

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=noyrD0jv9ya=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: $HOME/.local/bin in $PATH

2013-10-30 Thread Ralf Corsepius


On 10/30/2013 03:36 PM, Reindl Harald wrote:


Am 30.10.2013 15:29, schrieb Ralf Corsepius:

On 10/30/2013 01:08 PM, Reindl Harald wrote:
Besides that, what and where users put things underneath of $HOME is not a 
distro's busness

and so it is not a distro's business to add something to $PATH
inside the userhome
Yes, I agree to this. Automatically adding $HOME/.local/bin to $PATH is 
a bad idea.



  and finally you agreed what i said by try
to disagree
Well your view of users must not add binaries underneath of $HOME is 
non-sense. Actually it's the only way for ordinary users to install 
per-user installed SW.


Ralf

--
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: [Fedora Base Design WG] Initial committee proposal and selection reasoning

2013-10-30 Thread Stephen Gallagher

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/30/2013 10:44 AM, Josh Boyer wrote:
 On Mon, Oct 28, 2013 at 10:56 AM, Josh Boyer
 jwbo...@fedoraproject.org wrote:
 On Mon, Oct 28, 2013 at 10:43 AM, Phil Knirsch
 pknir...@redhat.com wrote:
 On 10/28/2013 03:36 PM, Jóhann B. Guðmundsson wrote:
 
 
 On 10/28/2013 01:20 PM, Phil Knirsch wrote:
 
 Hi everyone.
 
 As FESCO appointed me last Wednesday as the coordinator for
 the Fedora Base Design WG i wanted to start reaching out as
 soon as possible.
 
 The first task of a coordinator is to select and present
 the initial voting committee for the WG, chosen from the
 volunteers on 
 https://fedoraproject.org/wiki/Fedora.next/WG_Nominations
 and add that to the corresponding fedora ticket 
 https://fedorahosted.org/fesco/ticket/1170
 
 My approach and criteria for the selection was as follows:
 
 a) Include as many community members as possible as their 
 representation in the volunteer list was already rather low
 and we really wanted to get at least 50% community members
 in there.
 
 
 Afaik you chose none.
 
 
 See my comments about Jon Disnard later in my text, i assumed
 he was still a community member only to hear about him being a
 RH employee for less than a month now on Friday evening.
 
 Unfortunately the only person from QE was Jóhann B.
 Guðmundsson, but he is already a committee member in the
 Server WG. Same goes for infrastructure where Kevin Fenzi
 is as well in the Server WG already.
 
 
 
 There is no rule to that says nominators cant serve on more
 the one group, infact there exist quite bit of overlap
 already so both of us could have been choisen...
 
 
 
 Looking at https://fedorahosted.org/fesco/ticket/1170 i see no
 overlap between all 4 WGs so far, but maybe i'm missing
 something.
 
 I'm coordinator for the Workstation WG, and also up for the Base
 WG. I did this willingly.
 
 So thinking about this more, I'll point out that I told Phil 
 originally that I'm happy to participate from a kernel perspective 
 regardless.  I don't need to be a voting member of this WG to
 cover that.  I'll already be working with all of the WGs from a
 kernel perspective anyway, since they all have somewhat differing
 needs.  If there is someone that is better suited to discussing and
 driving the base of our products, I'm more than willing for them to
 take my place on this WG.
 

I'd like to strongly recommend considering Lennart Poettering for this
post. I can't really think of anyone in the Fedora community more
closely tied to the system's base design.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJxH68ACgkQeiVVYja6o6NA/QCfQ3u3OfKu3tWtS3fKvWwpQoSr
6hwAoIYSpkvUZDPc3I/Y6q7uUKeEWL0P
=XLSg
-END 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: $HOME/.local/bin in $PATH


On 2013-10-30 15:50, Ralf Corsepius wrote:

On 10/30/2013 03:36 PM, Reindl Harald wrote:


Am 30.10.2013 15:29, schrieb Ralf Corsepius:

On 10/30/2013 01:08 PM, Reindl Harald wrote:
Besides that, what and where users put things underneath of $HOME is 
not a distro's busness


[cut]


Is it really that simple?
- We respect the ancient traditions of ~/bin and ~/man.
- We respect the XDG specification for ~/.local/share
- This discussion: we respect ~/.local/bin, even if it's unclear if it's 
in the XDG spec.
- As Daniel Walsh pointed out in this thread, the selinux setup respect 
also ~/.local/bin


Bottom line: Fedora is not completely agnostic as to where users have 
their stuff,  there are some assumptions.


OTOH, all these could be defined as coming from some kind of 
upstream.  Perhaps the proper solution here is to patch the XDG 
specification so that it becomes clear on ~/local/bin (and probably also 
~/.local/lib).  Since Lennart Poettering is one of (the?) main 
contributor(s)  to this spec and also have been advocating the use of 
~/.local/bin it should be feasible.


--alec
--
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: abrt Bugzilla summary

2013-10-30 Thread Jakub Filak

Thank you for all your ideas!


I am going to change the default template to:


[abrt] component: function(): executable killed by SIGnum|name



Conclusion:
  - do not drop component because some email clients cannot display
custom headers in index

  - drop VR from component because Ales Kozumplik is the only one who
wants it (VR is always available in comment #0)

  - drop Process, /full/path/to/executable and signal

  - function must be prefix of 'executable killed by SIGnum|name'
because 'killed by' message is generated while coredumping and
unfortunately function is not known at that time

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

EPEL Fedora 6 updates-testing report

2013-10-30 Thread updates

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 556  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6
  70  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11274/ssmtp-2.61-21.el6
  31  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11703/chicken-4.8.0.4-4.el6
  19  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11785/phpMyAdmin-3.5.8.2-1.el6
  12  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11865/quassel-0.9.1-1.el6
  12  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11817/ReviewBoard-1.7.16-2.el6.1,python-djblets-0.7.21-1.el6
  12  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11880/GraphicsMagick-1.3.18-2.el6
  11  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11883/salt-0.17.1-1.el6
  10  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11891/libuv-0.10.18-1.el6,nodejs-0.10.21-1.el6
   1  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11970/python-backports-ssl_match_hostname-3.4.0.2-1.el6


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

ansible-1.3.4-1.el6
fts-monitoring-3.1.33-4.el6
lhapdf-5.9.1-1.el6
liquibase-3.0.7-4.el6
mock-1.1.34-1.el6
python-behave-1.2.3-8.el6
wordpress-3.7.1-1.el6

Details about builds:



 ansible-1.3.4-1.el6 (FEDORA-EPEL-2013-11992)
 SSH-based configuration management, deployment, and task execution system

Update Information:

Fixed a bug in the copy module, where a filename containing the string raw 
was handled incorrectly Fixed a bug in accelerate mode, where copying a 
zero-length file out would fail

ChangeLog:

* Tue Oct 29 2013 Kevin Fenzi ke...@scrye.com 1.3.4-1
- Update to 1.3.4




 fts-monitoring-3.1.33-4.el6 (FEDORA-EPEL-2013-11997)
 FTS3 Web Application for monitoring

Update Information:

FTS v3 web application for monitoring.
FTS v3 web application for monitoring.

References:

  [ 1 ] Bug #1024640 - fts-monitoring-3.1.11-3.el6 has invalid arch dependant 
dependencies
https://bugzilla.redhat.com/show_bug.cgi?id=1024640




 lhapdf-5.9.1-1.el6 (FEDORA-EPEL-2013-11996)
 Les Houches Accord PDF Interface

Update Information:

New version, see changelog for details:

http://lhapdf.hepforge.org/svn/tags/lhapdf-v5.9.1/ChangeLog


ChangeLog:

* Tue Oct 29 2013 Mattias Ellert mattias.ell...@fysast.uu.se - 5.9.1-1
- Update to version 5.9.1
* Sat Aug  3 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 5.8.9-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
* Tue Jun 18 2013 Dan Horák dan[at]danny.cz - 5.8.9-4
- don't run check on s390 - OOM when loading the library in Octave




 liquibase-3.0.7-4.el6 (FEDORA-EPEL-2013-11995)
 Database Refactoring Tool

Update Information:

Liquibase 3.0.7 features numerous bug fixes and additional extension support.

ChangeLog:

* Mon Oct 28 2013 Alex Wood aw...@redhat.com - 3.0.7-4
- Update to 3.0.7.
- Use jpackage-utils to generate launch script.
- Split javadoc into separate package.
* Sat Aug  3 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 2.0.5-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild

References:

  [ 1 ] Bug #1023523 - Liquibase package needs an update
https://bugzilla.redhat.com/show_bug.cgi?id=1023523




 mock-1.1.34-1.el6 (FEDORA-EPEL-2013-11994)
 Builds packages inside chroots

Update Information:

various bugfixes

EPEL Fedora 5 updates-testing report

2013-10-30 Thread updates

The following Fedora EPEL 5 Security updates need testing:
 Age  URL
 556  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5
  70  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11276/ssmtp-2.61-21.el5
  46  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11560/fail2ban-0.8.10-4.el5
  12  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11879/scipy-0.6.0-7.el5
  11  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11887/salt-0.17.1-1.el5
  10  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5


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

lhapdf-5.9.1-1.el5
wordpress-3.7.1-1.el5

Details about builds:



 lhapdf-5.9.1-1.el5 (FEDORA-EPEL-2013-11998)
 Les Houches Accord PDF Interface

Update Information:

New version, see changelog for details:

http://lhapdf.hepforge.org/svn/tags/lhapdf-v5.9.1/ChangeLog


ChangeLog:

* Tue Oct 29 2013 Mattias Ellert mattias.ell...@fysast.uu.se - 5.9.1-1
- Update to version 5.9.1
* Sat Aug  3 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 5.8.9-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
* Tue Jun 18 2013 Dan Horák dan[at]danny.cz - 5.8.9-4
- don't run check on s390 - OOM when loading the library in Octave




 wordpress-3.7.1-1.el5 (FEDORA-EPEL-2013-11956)
 Blog tool and publishing platform

Update Information:

Upstream annoucement:
* http://wordpress.org/news/2013/10/basie/
* http://wordpress.org/news/2013/10/wordpress-3-7-1/

Changes:
* http://codex.wordpress.org/Version_3.7
* http://codex.wordpress.org/Version_3.7.1




ChangeLog:

* Wed Oct 30 2013 Remi Collet rcol...@redhat.com - 3.7.1-1
- update to 3.7.1 (bugfixes)
* Fri Oct 25 2013 Remi Collet rcol...@redhat.com - 3.7-1
- update to 3.7
- requires ca-certificates for ca-bundle.crt
- drop pre-compiled Flash and Silverlight binaries - #1000267


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

Re: [389-devel] Please review lib389 ticket 47575: add test case for ticket47560

2013-10-30 Thread Rich Megginson


On 10/30/2013 10:47 AM, thierry bordaz wrote:

Hello,

This tickets implement a test case and propose a layout of the CI
tests in the 389-ds.
The basic idea is to put CI tests under:
head/dirsrvtests/
tickets/
standalone_test.py
m1c1_test.py
m2_c1_test.py
...


Does tickets in this case mean tickets for issues in the 389 trac?



testsuites/
acl_test.py
replication_test.py
...

For example, test_standalone.py would setup a standalone topology
and will contain all ticket test cases that are applicable on
standalone topology.

https://fedorahosted.org/389/attachment/ticket/47575/0001-Ticket-47575-CI-test-add-test-case-for-ticket47560.patch


So we would just keep adding tests to the single file 
standalone_test.py, every time we add a test for a trac ticket that 
deals with a standalone server?




regards
thierry


--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel


--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: $HOME/.local/bin in $PATH

2013-10-30 Thread Miloslav Trmač

On Wed, Oct 30, 2013 at 10:23 AM, Reindl Harald h.rei...@thelounge.net wrote:
 If I can write to files you own, it doesn't matter if there's a
 directory in the PATH or not.  I can write this to your .bash_profile:

/bin/mkdir $HOME/.bin 2 /dev/null
echo 'echo i could rm -rf ~/ here'  $HOME/.bin/mkdir
chmod +x $HOME/.bin/mkdir
PATH=$HOME/.bin:$PATH

 you can do this and that - but that's no valid argumentation
 doing bad things in default setups and *at least* do not
 place *hidden* diretories there, ther is a good reason why
 software like rkhunter alerts if you have hidden directories
 somewhere in /usr/bin/

 there are three type of users

 * people who care about security and know that there are
   enough rough edges but smart enough to take this *not
   as excuse* to create new ones

That's not how security works.  To get actual security, you want the
design to make a _precise_ promise, and then implement it _100%
correctly_.  Not with rough edges; compose three implementations
with rough edges and the result gives you no security promise.

In this case, the security promise needs to be the attacker can't
write to arbitrary files in your home directory; if that is broken,
the existence of ~/.local/bin doesn't make any difference.


I agree ~/.local/bin is problematic for system administration and
troubleshooting, but that's not security.  And yes, the design is
known to have problems (multi-arch in shared home directories, same as
~/bin) - but now that it has been there for some time, we really can't
remove it without breaking user's existing setups, so it would need an
_extremely_ good reason.
Mirek
-- 
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 1025004] New: Update from F19 to F20 fails due to perl version dependencies

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

Bug ID: 1025004
   Summary: Update from F19 to F20 fails due to perl version
dependencies
   Product: Fedora
   Version: rawhide
 Component: perl-Language-Expr
  Assignee: mhron...@redhat.com
  Reporter: michael.wikt...@gmail.com
QA Contact: extras...@fedoraproject.org
CC: mhron...@redhat.com,
perl-de...@lists.fedoraproject.org



Description of problem:
On an updated F19 system, running the following yum update command line:

yum --releasever=20 --enablerepo=updates-testing --enablerepo=updates
distro-sync

causes the following error for perl-Language-Expr:

Error: Package: perl-Language-Expr-0.19-4.fc19.noarch (@fedora/19)
   Requires: perl(:MODULE_COMPAT_5.16.2)
   Removing: 4:perl-5.16.3-265.fc19.x86_64 (installed)
   perl(:MODULE_COMPAT_5.16.2)
   Updated By: 4:perl-5.18.1-288.fc20.x86_64 (fedora)
  ~perl(:MODULE_COMPAT_5.18.1)
  ~perl(:MODULE_COMPAT_5.18.0)


Additional info:
This is a test requested as per:

http://www.paulmellors.net/donate-1-minute-of-your-time-to-test-upgrades-from-f19-to-f20/

in order to uncover F19-F20 packaging/dependency issues.

-- 
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=jvFaF2sRNla=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: [389-devel] Please review lib389 ticket 47575: add test case for ticket47560

2013-10-30 Thread thierry bordaz


On 10/30/2013 06:59 PM, Rich Megginson wrote:

On 10/30/2013 10:47 AM, thierry bordaz wrote:

Hello,

This tickets implement a test case and propose a layout of the CI
tests in the 389-ds.
The basic idea is to put CI tests under:
head/dirsrvtests/
tickets/
standalone_test.py
m1c1_test.py
m2_c1_test.py
...


Does tickets in this case mean tickets for issues in the 389 trac?

Yes in my mind, this directory would contains test cases for 389 tickets.



testsuites/
acl_test.py
replication_test.py
...

For example, test_standalone.py would setup a standalone topology
and will contain all ticket test cases that are applicable on
standalone topology.

https://fedorahosted.org/389/attachment/ticket/47575/0001-Ticket-47575-CI-test-add-test-case-for-ticket47560.patch


So we would just keep adding tests to the single file 
standalone_test.py, every time we add a test for a trac ticket that 
deals with a standalone server?

Yes, if we have a test case for a ticket_xyz, we may add a new class method

   class Test_standAlone(object):
def setup(self):
...
def teardown(self):
...

def test_ticket_xyz(self):
def _test_ticket_xyx_setup():
   initialization of test case ticket xyz
def _test_ticket_xyz_teardown():
cleanup for test case ticket xyz

_test_ticket_xyz_setup()

test case

_test_ticket_xyz_teardown()





def test_ticket_abc(self)
...

def test_final(self)
triggers the cleanup of the standalone instance









regards
thierry


--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel




--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: $HOME/.local/bin in $PATH



Am 30.10.2013 18:59, schrieb Miloslav Trmač:
 On Wed, Oct 30, 2013 at 10:23 AM, Reindl Harald h.rei...@thelounge.net 
 wrote:
 If I can write to files you own, it doesn't matter if there's a
 directory in the PATH or not.  I can write this to your .bash_profile:

/bin/mkdir $HOME/.bin 2 /dev/null
echo 'echo i could rm -rf ~/ here'  $HOME/.bin/mkdir
chmod +x $HOME/.bin/mkdir
PATH=$HOME/.bin:$PATH

 you can do this and that - but that's no valid argumentation
 doing bad things in default setups and *at least* do not
 place *hidden* diretories there, ther is a good reason why
 software like rkhunter alerts if you have hidden directories
 somewhere in /usr/bin/

 there are three type of users

 * people who care about security and know that there are
   enough rough edges but smart enough to take this *not
   as excuse* to create new ones
 
 That's not how security works.  To get actual security, you want the
 design to make a _precise_ promise, and then implement it _100%
 correctly_.  Not with rough edges; compose three implementations
 with rough edges and the result gives you no security promise.

no *that is* how security works
100% security is simply impossible

 In this case, the security promise needs to be the attacker can't
 write to arbitrary files in your home directory

which is not possible at all, any application running with your
user can write in your home directory and any security relevant
bug in that application may result in changes
__

even if my english is not perfect i try to explain some basics now
the only remeining question the impact of this possible changes

* have one writeable places for executeables - the attack needs to try exactly 
this
* have three writeable places for executeables - the attack needs one out of 
three

and no, you can't imagine an attack like hey i have a sehll now and
try around where i can compromise your setup - in most cases after
a buffer overlow and such things you have *one* chance to execture
your code before the applications crashs




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

Fedora search

2013-10-30 Thread Frankie Onuonga

Hi guys,
I hope all is well.


I am writing in regards to something I had written about two months ago.
This in regards to the search engine.

https://fedorahosted.org/fedora-infrastructure/ticket/1055#trac-add-comment


I think we need to seriously fix this thing once and for all.

I am looking at designing a solution for us.
I however would like to start from the basics.
We will need to look at the solutions that are present at the current time.
This should allow us to critic and analyse them.

I will then take this issue into the meeting for voting and whatever is
decided is what I shall implement.

Kindly do advice if you have any pointers on this project.
I however must be honest and say it will take me about 2 months to complete
when i start because I have a day job elsewhere.
This does not mean I will not want assistance. As always assistance is
highly appreciated.


I hope this will be fruitful so we can close this once and for all. Or
should I say until we need a revision done.

Thanks,
Kind Regards,


-- 
Skype: Frankie Onuonga
twitter: Frankie.onuonga
irc #freenode: Frankie.onuonga
-- 
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: Draft Workstation WG Governance Charter

2013-10-30 Thread Bruno Wolff III

Giving the FESCO rep a two year term seems to be a potential problem as 
they wouldn't be guaranteed to be in FESCO for two years and most of 
the time you'd probably want the rep to be a member of FESCO. Maybe the 
FESCO rep should just serve at the pleasure of FESCO?

--
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: $HOME/.local/bin in $PATH

2013-10-30 Thread Bruno Wolff III


On Wed, Oct 30, 2013 at 19:15:11 +0100,
  Reindl Harald h.rei...@thelounge.net wrote:


which is not possible at all, any application running with your
user can write in your home directory and any security relevant
bug in that application may result in changes


That doesn't have to be the case. selinux can be used to prevent some 
applications from doing that.

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

Schedule for Thursday's FPC Meeting (2013-10-31 16:00 UTC)

2013-10-30 Thread James Antill

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2013-10-31 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. rktime):

2013-10-31 09:00 Thu US/Pacific PDT
2013-10-31 12:00 Thu US/Eastern EDT
2013-10-31 16:00 Thu UTC -
2013-10-31 16:00 Thu Europe/London -
2013-10-31 17:00 Thu Europe/Paris   CET
2013-10-31 17:00 Thu Europe/Berlin  CET
2013-10-31 21:30 Thu Asia/Calcutta  IST
--new day--
2013-11-01 00:00 Fri Asia/Singapore SGT
2013-11-01 00:00 Fri Asia/Hong_Kong HKT
2013-11-01 01:00 Fri Asia/Tokyo JST
2013-11-01 02:00 Fri Australia/Brisbane EST

 Links to all tickets below can be found at: 

https://fedorahosted.org/fpc/report/12

= Followups =


#topic #339 software collections in Fedora
.fpc 339
https://fedorahosted.org/fpc/ticket/339

#topic #352 BLAS and LAPACK packaging
.fpc 352
https://fedorahosted.org/fpc/ticket/352

= New business =

#topic #355 How to package noarch packages which require a binary
dependency which doesn't build on all archs?
.fpc 355
https://fedorahosted.org/fpc/ticket/355

#topic #357 time-api prior to openJDK8
.fpc 357
https://fedorahosted.org/fpc/ticket/357


#topic #358 Please make some autotools guidelines.
.fpc 358
https://fedorahosted.org/fpc/ticket/358

#topic #359 Guideline: Forbid sysv initscripts in addition to
systemd unit files
.fpc 359
https://fedorahosted.org/fpc/ticket/359

#topic #361 Two more bundled MD5 implementations
.fpc 361
https://fedorahosted.org/fpc/ticket/361

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://fedorahosted.org/fpc/report/12


 If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 


-- 
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: $HOME/.local/bin in $PATH



Am 30.10.2013 19:51, schrieb Bruno Wolff III:
 On Wed, Oct 30, 2013 at 19:15:11 +0100,
 Reindl Harald h.rei...@thelounge.net wrote:

 which is not possible at all, any application running with your
 user can write in your home directory and any security relevant
 bug in that application may result in changes
 
 That doesn't have to be the case. selinux can be used to prevent some 
 applications from doing that

and here again the word *some* which shows 100% security is impossible
anybody really have security as his daily job is knowing that

that's the reason why security is layered and finally ends in
offer as less as possible attack vectors all over these layers

* firewall
* network
* kernel
* OS userland
* filesystem permissions
* default settings
* applications

since the only way to gain 100% security is to remove the network cable
and lock USB/Firewire completly you are limited in make any of these
layers as secure as possible by not damage normal operations

because attacks these days are so much widespreaded and applications way
too complex that any knowledgable person would avoid to say this is
for sure secure fro whatever piece of software you can only find
a good balance between as secure as possible and no longer working

any software working with untrusted data has this problem and in
doubt there is only few software not working with untrusted data
because you hardly can be sure that a image, office-document, video
or PDF or whatever file received from your best friend was not already
modified on his machine to attack whatever applications without take notice

a few years ago people called me a paranoid idiot because i statet all
this multiple times, but after the news of the last 6 months most of
these people got very silent and you can be sure that it does not
need the NSA/CIA to take advantage of security holes




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: Draft Workstation WG Governance Charter

On Wed, Oct 30, 2013 at 2:42 PM, Bruno Wolff III br...@wolff.to wrote:
 Giving the FESCO rep a two year term seems to be a potential problem as they
 wouldn't be guaranteed to be in FESCO for two years and most of the time
 you'd probably want the rep to be a member of FESCO. Maybe the FESCO rep
 should just serve at the pleasure of FESCO?

I opened a ticket[1] for clarifying exactly what FESCo intended with
the liaison role.  They just decided that:

1) The FESCo liaison is always a member of the WG's decision making body
2) WGs can decide how the FESCo liaison is selected, including the
possibility of asking FESCo to select.  (As FESCo is above the WGs,
FESCo could ask WGs to re-choose.)

So the role isn't a member of FESCo on the WG.  It's a member of
the WG that acts as the liaison to FESCo.  I'll clarify this in the
next draft I send out.

josh

[1] https://fedorahosted.org/fesco/ticket/1186
-- 
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: Draft Workstation WG Governance Charter

2013-10-30 Thread Ray Strode

Hi,

On Wed, Oct 30, 2013 at 9:01 AM, Josh Boyer jwbo...@fedoraproject.org wrote:
 The other positions will be filled by general election
 every two years. As a special exception, four seats will be filled in
 one year, with those positions chosen at random (unless some number of
 members decide to step down). Voting will follow the standard Fedora
 election process and be open to all contributors in the CLA+1 group.

 In the event that a current member relinquishes their seat, that seat
 will be filled by the first runner up in the previous election.  If
 that person is not able or willing to fill the seat, it will go to
 each successive runner up until the seat is filled.

I think, I personally, would rather see the previous working group
decide new members of the working group.  They're the ones doing the
work, so they should get the most say in the direction the work goes.
(the whole fedora is a meritocracy not a democracy thing).

Put another way: I don't think someone who works on desktop related
software should have much say in who gets to be put in the cloud
working group, or vice-versa.

Let the people already doing the work decide the continuing direction
of the work.
If things really get off course, fesco can intervene, but I don't
think that will happen.

--Ray
-- 
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: Draft Workstation WG Governance Charter

On Wed, Oct 30, 2013 at 3:16 PM, Ray Strode halfl...@gmail.com wrote:
 Hi,

 On Wed, Oct 30, 2013 at 9:01 AM, Josh Boyer jwbo...@fedoraproject.org wrote:
 The other positions will be filled by general election
 every two years. As a special exception, four seats will be filled in
 one year, with those positions chosen at random (unless some number of
 members decide to step down). Voting will follow the standard Fedora
 election process and be open to all contributors in the CLA+1 group.

 In the event that a current member relinquishes their seat, that seat
 will be filled by the first runner up in the previous election.  If
 that person is not able or willing to fill the seat, it will go to
 each successive runner up until the seat is filled.

 I think, I personally, would rather see the previous working group
 decide new members of the working group.  They're the ones doing the
 work, so they should get the most say in the direction the work goes.
 (the whole fedora is a meritocracy not a democracy thing).

 Put another way: I don't think someone who works on desktop related
 software should have much say in who gets to be put in the cloud
 working group, or vice-versa.

 Let the people already doing the work decide the continuing direction
 of the work.
 If things really get off course, fesco can intervene, but I don't
 think that will happen.

Fair.  To be honest, the more I think about it the more I dislike the
idea of doing full blown elections.  They seem overkill and cumbersome
when it comes to coordinating, etc.

In your opinion, should we have term limits imposed to ensure we have
fresh members coming into the WG?  As I said in another email, I think
we should shoot for some continuity while also encouraging new members
to step up.

josh
-- 
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: Fedora search

2013-10-30 Thread Michael Cronenworth


Frankie Onuonga wrote:

I am writing in regards to something I had written about two months ago.
This in regards to the search engine.

https://fedorahosted.org/fedora-infrastructure/ticket/1055#trac-add-comment


I think we need to seriously fix this thing once and for all.

I am looking at designing a solution for us.
I however would like to start from the basics.
We will need to look at the solutions that are present at the current time.
This should allow us to critic and analyse them.

I will then take this issue into the meeting for voting and whatever is decided
is what I shall implement.

Kindly do advice if you have any pointers on this project.
I however must be honest and say it will take me about 2 months to complete when
i start because I have a day job elsewhere.
This does not mean I will not want assistance. As always assistance is highly
appreciated.


I hope this will be fruitful so we can close this once and for all. Or should I
say until we need a revision done.


What about using a custom Google search engine?

https://www.google.com/cse/
--
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: Draft Workstation WG Governance Charter

2013-10-30 Thread Ray Strode

Hi,

On Wed, Oct 30, 2013 at 3:22 PM, Josh Boyer jwbo...@fedoraproject.org wrote:
 In your opinion, should we have term limits imposed to ensure we have
 fresh members coming into the WG?  As I said in another email, I think
 we should shoot for some continuity while also encouraging new members
 to step up.

Not sure.  I mean, as the saying goes if it ain't broke, don't fix
it.  Making membership autorotate kind of contradicts that little bit
of wisdom. I think when people get tired or ineffectual, they'll say
so, and relinquish their seats. People know when they're burned out,
or when they're not helping for the most part.  And I think the people
on current working group have good intentions, and are willing to
objectively put the project first.

--Ray
-- 
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: Fedora search

2013-10-30 Thread Frankie Onuonga

On Wed, Oct 30, 2013 at 7:29 PM, Michael Cronenworth m...@cchtml.comwrote:

Frankie Onuonga wrote:

I am writing in regards to something I had written about two months ago.
This in regards to the search engine.

https://fedorahosted.org/**fedora-infrastructure/ticket/**
1055#trac-add-commenthttps://fedorahosted.org/fedora-infrastructure/ticket/1055#trac-add-comment

I think we need to seriously fix this thing once and for all.

I am looking at designing a solution for us.
I however would like to start from the basics.
We will need to look at the solutions that are present at the current
time.
This should allow us to critic and analyse them.

I will then take this issue into the meeting for voting and whatever is
decided
is what I shall implement.

Kindly do advice if you have any pointers on this project.
I however must be honest and say it will take me about 2 months to
complete when
i start because I have a day job elsewhere.
This does not mean I will not want assistance. As always assistance is
highly
appreciated.

I hope this will be fruitful so we can close this once and for all. Or
should I
say until we need a revision done.

What about using a custom Google search engine?

https://www.google.com/cse/

My notion has always been that people always want something that is made in
house.
I do not think they will take up something that is in a black box but I
might be wrong.

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

--
Skype: Frankie Onuonga
twitter: Frankie.onuonga
irc #freenode: Frankie.onuonga
--
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: [389-devel] Please review lib389 ticket 47578: removal of 'sudo' and absolute path in lib389

2013-10-30 Thread thierry bordaz

On 10/30/2013 07:56 PM, Jan Rusnacko wrote:

Hello Thierry,

layout OK.

As for tests - instead of reinventing the wheel by defing class Test_standAlone
to set up instance, use py.test fixture.

Also, you should not force setup, test, teardown execution for each test by
specifying sub-methods for each test. Testing framework (py.test) should be
doing that. I think this will make your tests fail badly if some exception
occurs - if _test_ticket47560_setup raises exception, it will propagate back to
py.test and cleanup method will never be executed for that ticket.

Hi Jan,

thanks for you comments.
py.test will call for for each test_ticketxxx

setup
test_ticketxxx
teardown

setup will create the instance if it does not already exist, else it
provide a dirsrv to it.
teardown will remove the instance if the test_ticketxx is not able to
properly clean it up (if test_ticketxx raise the clean_please flag)
test_ticketxxx will start it executions with clean_please=true (set by
setup), if it succeeds it set clean_please=false. Unless it fails to
properly clean up the instance. In that case it sets clean_please to true.

What would be the advantages to make the setup/teardown sub-methods of
the test_ticketxx ?
At least a small drawback is that the person that write test_ticketxxx
will have to write them, instead of using the standard one.

Also, I believe each ticket should have its own file which contains one or more
testcases. I think that would reasonably group relevant things together.

Right, it was my first intention. But then I had this idea to group the
tickets per deployment module.

I don't know if it is a good idea, but it seems to be confusing :-[

On 10/30/2013 05:57 PM, thierry bordaz wrote:

https://fedorahosted.org/389/attachment/ticket/47578/0001-Ticket-47578-CI-tests-removal-of-sudo-and-absolute-p.patch

--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: Fedora search

2013-10-30 Thread Michael Cronenworth


Frankie Onuonga wrote:

My notion has always been that people always want something that is made in 
house.
I do not think they will take up something that is in a black box but I might
be wrong.


Site search engines are mostly useless to me, and I know I'm not alone. Why else 
would the ticket go untouched for 4 years?


Reasons against YASE (yet another search engine):
1. They provide horrible results. The Big Boys (G, Y!, B, etc.) aggregate on 
levels beyond what one man can program in a few hours (no offense).

2. Most people bring up one of the Big Boys to search anyway.
3. It's another piece of software Infrastructure has to maintain.

--
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: [389-devel] Please review lib389 ticket 47578: removal of 'sudo' and absolute path in lib389

2013-10-30 Thread thierry bordaz

Ok I realise it is not a good idea. I will reimplement it and send an 
other review :-)

Thanks for all your feedbacks.

thierry

On 10/30/2013 08:11 PM, Rich Megginson wrote:

On 10/30/2013 12:56 PM, Jan Rusnacko wrote:

Hello Thierry,

layout OK.

As for tests - instead of reinventing the wheel by defing class 
Test_standAlone

to set up instance, use py.test fixture.

+1


Also, you should not force setup, test, teardown execution for each 
test by
specifying sub-methods for each test. Testing framework (py.test) 
should be
doing that. I think this will make your tests fail badly if some 
exception
occurs - if _test_ticket47560_setup raises exception, it will 
propagate back to

py.test and cleanup method will never be executed for that ticket.

+1


Also, I believe each ticket should have its own file which contains 
one or more

testcases. I think that would reasonably group relevant things together.

+1


On 10/30/2013 05:57 PM, thierry bordaz wrote:
https://fedorahosted.org/389/attachment/ticket/47578/0001-Ticket-47578-CI-tests-removal-of-sudo-and-absolute-p.patch 





--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel


--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel




--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: [389-devel] Please review lib389 ticket 47578: removal of 'sudo' and absolute path in lib389

2013-10-30 Thread Rich Megginson

On 10/30/2013 02:09 PM, thierry bordaz wrote:

On 10/30/2013 07:56 PM, Jan Rusnacko wrote:

Hello Thierry,

layout OK.

As for tests - instead of reinventing the wheel by defing class Test_standAlone
to set up instance, use py.test fixture.

Hi Jan,

thanks for you comments.
py.test will call for for each test_ticketxxx

setup
test_ticketxxx
teardown

What would be the advantages to make the setup/teardown sub-methods of
the test_ticketxx ?
At least a small drawback is that the person that write
test_ticketxxx will have to write them, instead of using the
standard one.

Can we have the test framework call a default setup/teardown method if
not provided by the test?

Also, I believe each ticket should have its own file which contains one or more
testcases. I think that would reasonably group relevant things together.

Right, it was my first intention. But then I had this idea to group
the tickets per deployment module.

I don't know if it is a good idea, but it seems to be confusing :-[

On 10/30/2013 05:57 PM, thierry bordaz wrote:

https://fedorahosted.org/389/attachment/ticket/47578/0001-Ticket-47578-CI-tests-removal-of-sudo-and-absolute-p.patch

--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Summary/Minutes for Wednesday's (today's) FESCo meeting (2013-10-30)

2013-10-30 Thread Bill Nottingham

===
#fedora-meeting: FESCO (2013-10-30)
===


Meeting started by notting at 18:01:19 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2013-10-30/fesco.2013-10-30-18.01.log.html
.

Meeting summary
---
* init process  (notting, 18:01:26)
  * AGREED: meeting stays at 1800UTC until further notice (+:9)
(notting, 18:11:21)

* #1170 Working Group call for volunteers  (notting, 18:11:47)
  * AGREED: base design WG approved (+:8, -:1)  (notting, 18:27:56)
  * nirik to open a ticket to track working group governance proposals
(notting, 18:29:17)

* #1185 Enable -Werror=format-security by default  (notting, 18:29:50)
  * AGREED: defer pending results of mass rebuild (+;8, -0, 0:0)
(notting, 18:32:40)
  * AGREED: defer pending results of mass rebuild (+;9, -0, 0:0)
(notting, 18:33:30)
  * AGREED: ask gcc to make warning part of -Wall now, defer enabling it
as an error until the mass rebuild test is done (+:7, -:0, 0:0)
(notting, 18:38:28)

* #1186 FESCo liason role in WGs  (notting, 18:40:31)
  * AGREED: require that the fesco liason on a WG is always a member of
that WG's decision making body (+:8, 0:0, -:0  (pjones, 18:48:28)
  * AGREED: WGs can decide how the FESCo liason is selected, including
the possibility of asking FESCo to select. (As FESCo is above the
WGs, FESCo could ask WGs to re-choose.) (+:8, -:0, 0:0)  (notting,
19:03:03)

* #1187 Packagers should be not be allowed to ignore RH bugzilla
  (notting, 19:03:20)
  * AGREED: let people come to fesco on a package-by-package basis if
they think there are package maintenance issues (+:7, -:0, 0:0)
(notting, 19:20:04)
  * if the person filing the ticket has specific issues, he should bring
them up, as per:
https://fedoraproject.org/wiki/Package_maintainer_responsibilities
(pjones, 19:20:41)
  * Note that handling bugs is part of package maintainership, per
https://fedoraproject.org/wiki/Package_maintainer_responsibilities
(notting, 19:22:04)

* next week's chair  (notting, 19:22:36)
  * abadger1999 to chair next week's meeting  (notting, 19:23:14)

* Open Floor  (notting, 19:23:22)
  * LINK:
http://fedoraproject.org/wiki/Board/Possible_Future_of_Fedora_Governance
(old and drafty)  (nirik, 19:28:41)

Meeting ended at 19:35:04 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* notting (88)
* pjones (75)
* sgallagh (63)
* nirik (61)
* abadger1999 (44)
* jwb (43)
* mattdm (38)
* mitr (34)
* t8m (22)
* Viking-Ice (18)
* pknirsch (18)
* zodbot (13)
* mmaslano (12)
* frankieonuonga (3)
* handsome_pirate (1)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
18:01:19 notting #startmeeting FESCO (2013-10-30)
18:01:19 zodbot Meeting started Wed Oct 30 18:01:19 2013 UTC.  The chair is 
notting. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:19 zodbot Useful Commands: #action #agreed #halp #info #idea #link 
#topic.
18:01:22 mitr Hello
18:01:26 notting #meetingname fesco
18:01:26 zodbot The meeting name has been set to 'fesco'
18:01:26 notting #chair abadger1999 mattdm mitr mmaslano notting nirik pjones 
t8m sgallagh
18:01:26 notting #topic init process
18:01:26 zodbot Current chairs: abadger1999 mattdm mitr mmaslano nirik 
notting pjones sgallagh t8m
18:01:28 nirik hey.
18:01:35 * nirik runs to get coffee, back in a minute
18:01:46 * mattdm has coffee in hand
18:02:11 sgallagh I'm around; closing out the Server WG meeting
18:02:31 mattdm I'll be leaving in 55 minutes to start the cloud wg meeting :)
18:03:19 pjones hello.
18:03:33 * abadger1999 shows up
18:03:42 pjones mattdm: sgallagh: so this is becoming an increasingly bad 
time slot then, eh?
18:04:05 sgallagh pjones: It works for me; I like having an upper limit on 
the Server WG slot
18:04:10 mattdm pjones or we could keep this meeting to an hour :)
18:04:19 notting is that everyone except mmaslano?
18:04:27 notting looks like it
18:04:30 mattdm but for the cloud wg, this week probably isn't representative
18:04:46 mattdm (not sure if we will even be able to find a regular time)
18:05:21 mmaslano hi
18:05:43 nirik also, US changes time next week...
18:05:44 notting ok, i believe that's everyone.
18:05:45 sgallagh Before we get started.
18:05:52 sgallagh nirik: beat me to it
18:06:33 abadger1999 (and eu changed already)
18:06:43 notting is everyone ok with the meeting staying at 1800UTC , with 
their local time shifted back?
18:06:51 t8m I am ok with that
18:06:57 t8m actually I prefer that
18:07:13 nirik sure.
18:07:17 * nirik hates timezones
18:07:44 mattdm i slightly prefer the later time but either works
18:07:48 abadger1999 Works for me.
18:07:50 mmaslano yeah, it's okay
18:07:56 * t8m hates DST
18:08:01 sgallagh So that moves it to 1:00 EDT next week?

Summary/Minutes for Cloud WG (2013-10-30)

=
#fedora-meeting-1: Cloud (2013-10-30)
=


Meeting started by mattdm at 19:00:22 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-10-30/fedora-meeting-1.2013-10-30-19.00.log.html
.



Meeting summary
---
* Intro  (mattdm, 19:02:02)

* Mailing List vs. IRC Meetings  (mattdm, 19:05:31)
  * AGREED: weekly irc meetings to start.  (mattdm, 19:08:19)
  * more like a checkpoint/coordination than a $topic: DISCUSS type of
meeting  (mattdm, 19:10:22)
  * $topic: DISCUSS  should be on the mailing list  (mattdm, 19:10:36)
  * ACTION: mattdm will coordinate time for next/ongoing meeting
(mattdm, 19:10:53)

* Trac Instance  (mattdm, 19:11:07)
  * LINK: https://fedorahosted.org/cloud/   (mattdm, 19:11:23)
  * adding rbergeron and number80 as trac admins, will add others who
want to be bothered with it on request :)  (mattdm, 19:14:54)
  * for example frankieonuonga  (mattdm, 19:15:05)

* Draft Governance  (mattdm, 19:15:53)
  * LINK: https://fedoraproject.org/wiki/Cloud_WG   (mattdm, 19:15:59)
  * ACTION: mattdm will reorganize 'landing page' aspects of current
draft into actual landing page  (mattdm, 19:18:03)
  * IDEA: borrow from https://fedoraproject.org/wiki/Infrastructure
(mattdm, 19:18:30)
  * AGREED: the liaison to fesco will preferably be a member of fesco,
but in the case there isn't a fesco member willing to work on the
behalf of the cloud WG, a non-fesco member can be appointed liaison
(samkottler)  (number80, 19:34:24)
  * AGREED: the liaison to fesco will preferably be a member of fesco,
but in the case there isn't a fesco member willing to work on the
behalf of the cloud WG, a non-fesco member can be appointed liaison
(samkottler) +6  (number80, 19:35:15)
  * AGREED: one member of the cloud wg will be elected to serve as chair
of the group, organizing meetings and driving; other people will
step up as needed if chair is temporarily unavailable (+7)  (mattdm,
19:47:34)
  * AGREED: Because continuity is important, Working Group members serve
as long as they are able and willing. When a position on the group
becomes available, that position will be filled by unanimous consent
of the existing members (+7)  (number80, 19:58:19)
  * ACTION: mattdm to draft an update to the governance document and
bring it back to the mailing list  (mattdm, 20:03:47)

* PRD Framework  (mattdm, 20:04:13)
  * LINK: https://fedoraproject.org/wiki/Cloud_PRD   (mattdm, 20:04:17)

Meeting ended at 20:24:41 UTC.




Action Items

* mattdm will coordinate time for next/ongoing meeting
* mattdm will reorganize 'landing page' aspects of current draft into
  actual landing page
* mattdm to draft an update to the governance document and bring it back
  to the mailing list




Action Items, by person
---
* mattdm
  * mattdm will coordinate time for next/ongoing meeting
  * mattdm will reorganize 'landing page' aspects of current draft into
actual landing page
  * mattdm to draft an update to the governance document and bring it
back to the mailing list
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* mattdm (161)
* rbergeron (93)
* samkottler (76)
* number80 (76)
* frankieonuonga (50)
* jzb (28)
* red_trela (27)
* geppetto (13)
* dgilmore (11)
* zodbot (10)
* jwb (6)
* abadger1999 (3)
* nirik (2)
* sgallagh (1)
* orc_emac_ (1)
* hguemar (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  mat...@fedoraproject.org
-- 
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: Fedora search

2013-10-30 Thread Frankie Onuonga

On Wed, Oct 30, 2013 at 8:11 PM, Michael Cronenworth m...@cchtml.comwrote:

Frankie Onuonga wrote:

My notion has always been that people always want something that is made
in house.
I do not think they will take up something that is in a black box but I
might
be wrong.

Site search engines are mostly useless to me, and I know I'm not alone.
Why else would the ticket go untouched for 4 years?

Reasons against YASE (yet another search engine):
1. They provide horrible results. The Big Boys (G, Y!, B, etc.) aggregate
on levels beyond what one man can program in a few hours (no offense).
2. Most people bring up one of the Big Boys to search anyway.
3. It's another piece of software Infrastructure has to maintain.

i would not go with the word useless.
I also would not conclude in such a hurry that is the reason the ticket has
gone un touched.
I think there was no one to optimise performance at the time independent
of the solution that was chosen.

In terms of the reasons your opinion is highly respected. I however doubt
it on horrible results.
I would kindly request you to have a look at what other distros have done.

I respect your opinions but I can not conclude in a solid way with them.
Sorry.

Re: $HOME/.local/bin in $PATH

2013-10-30 Thread drago01

On Wed, Oct 30, 2013 at 7:15 PM, Reindl Harald h.rei...@thelounge.net wrote:
 and no, you can't imagine an attack like hey i have a sehll now and
 try around where i can compromise your setup - in most cases after
 a buffer overlow and such things you have *one* chance to execture
 your code before the applications crashs

No. A typical buffer overflow attack is used to either spawn a local
shell or a reverse shell using execve().
-- 
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: $HOME/.local/bin in $PATH

2013-10-30 Thread Scott Schmit

On Wed, Oct 30, 2013 at 01:08:48PM +0100, Reindl Harald wrote:
 Am 30.10.2013 13:00, schrieb Alec Leamas:
  Current defaults already has ~/bin in $PATH, and user can certainly put
  things there. Isn't the issue here if having a hidden, writeable directory 
  in $PATH is such a bad idea, given that users actually can install sw?
 
 guess how many users are aware of the hidden directory compared with
 bin in the userhome and how often someone may take a look
The only reason I know I can put executables in $HOME/bin and have it
just work is *because* it's in my $PATH.  $HOME/bin isn't created for
new accounts.  FWIW, neither is $HOME/.local.

$HOME/.bashrc $HOME/.bash_profile are both already executed on bash
invocation, and they're writable to the user.  If some exploit or
malware can inject entire files into my home directory and mark them
executable, and I'm allowed to execute anything out of $HOME, then it
doesn't matter what's in $PATH or not.

I suspect that SELinux policies already prevent creation of files in
$HOME by confined domains, making this less of an issue anyway.  If you
turn off SELinux and don't want executables in $HOME, then mount /home
noexec.

I imagine $HOME/.local/bin is ahead of the system executables so that if
my sysadmin has an ancient version of some software package and I need
something newer, I can build and install a newer version in my home
directory.  I remember doing this at school when I was using lab
machines.

What's the issue here?

-- 
Scott Schmit


smime.p7s
Description: S/MIME cryptographic 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: Schedule for Thursday's FPC Meeting (2013-10-31 16:00 UTC)

2013-10-30 Thread Christopher Meng

Please check #350 again.

Thanks.
-- 
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: $HOME/.local/bin in $PATH

2013-10-30 Thread Ben Boeckel

On Wed, 30 Oct, 2013 at 14:05:05 GMT, Christopher wrote:
 And, the xdg argument doesn't seem like a sufficient argument for
 me... we're talking about login scripts, not X. It is very unintuitive
 that an xdg-related directory would be on the default path for a bash
 login, if you're not even running X. This is a bash profile... not an
 X profile...

The XDG spec parts aren't really X-specific anyways. Does having to set
W3M_DOWNLOAD_DIR as well as XDG_DOWNLOAD_DIR sound at all appealing? I
see that XDG comes from X Desktop Group, but for XDG_* stuff.
Backronyming to [Cross] Desktop Guidelines (of which a TTY login is
just a degenerative case for most things (icons, menus, etc.)) wouldn't
be the worst thing...

-- Ben

-- 
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: $HOME/.local/bin in $PATH

2013-10-30 Thread Chris Adams

Once upon a time, Reindl Harald h.rei...@thelounge.net said:
 you can do this and that - but that's no valid argumentation
 doing bad things in default setups

But you are calling it bad with no real argument except repitition.
I've shown that it is not _any_ worse for security.

 *at least* do not
 place *hidden* diretories there, ther is a good reason why
 software like rkhunter alerts if you have hidden directories
 somewhere in /usr/bin/

There's a vast difference between $HOME/.local/bin and a dot-directory
under /usr/bin (where nothing installs them on normal systems but root
kits often do).

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

[perl-Text-Table/f20] 1.128 bump

2013-10-30 Thread Petr Šabata

Summary of changes:

  47ab221... 1.128 bump (*)

(*) This commit already existed in another branch; no separate mail sent
--
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

[perl-Text-Table/f19] (4 commits) ...1.128 bump

2013-10-30 Thread Petr Šabata

Summary of changes:

  cbe6a87... 1.127 bump, test suite enhancements (*)
  fc1d09c... Perl 5.18 rebuild (*)
  30e0549... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*)
  47ab221... 1.128 bump (*)

(*) This commit already existed in another branch; no separate mail sent
--
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 1023711] perl-Text-Table-1.128 is available

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



--- Comment #1 from Fedora Update System upda...@fedoraproject.org ---
perl-Text-Table-1.128-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/perl-Text-Table-1.128-1.fc20

-- 
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=GV1KN35YNQa=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 1023711] perl-Text-Table-1.128 is available

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



--- Comment #2 from Fedora Update System upda...@fedoraproject.org ---
perl-Text-Table-1.128-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/perl-Text-Table-1.128-1.fc19

-- 
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=WVOIH2AGBKa=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 1025004] Update from F19 to F20 fails due to perl version dependencies

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

Paul Howarth p...@city-fan.org changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||p...@city-fan.org
 Resolution|--- |DUPLICATE
Last Closed||2013-10-30 17:29:01



--- Comment #1 from Paul Howarth p...@city-fan.org ---
Known issue, not likely to be fixed until perl 5.18.2 comes out.

*** This bug has been marked as a duplicate of bug 992666 ***

-- 
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=NAy36mUUl5a=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 992666] perl-Language-Expr: FTBFS in rawhide

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

Paul Howarth p...@city-fan.org changed:

   What|Removed |Added

 CC||michael.wikt...@gmail.com



--- Comment #8 from Paul Howarth p...@city-fan.org ---
*** Bug 1025004 has been marked as a duplicate of this bug. ***

-- 
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=FyxxFHbuz0a=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 992666] perl-Language-Expr: FTBFS in rawhide

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



--- Comment #9 from Miro Hrončok mhron...@redhat.com ---
Is there something I can do to prevent failures such as bz1025004? E.g. delete
the package from F20 somehow?

-- 
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=Iao3Lmdr5Ca=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 992666] perl-Language-Expr: FTBFS in rawhide