On Mon, Jan 12, 2015 at 11:27 AM, Jan Zelený jzel...@redhat.com wrote:
On 11. 1. 2015 at 20:40:56, Adrian Soliard wrote:
Hi everyone!
I'm struggling a bit with dnf. It may have advantages, but as an
end-user, I'm fighting with the list of packages when I press TAB.
It's complicated, if I
On Mon, Jan 12, 2015 at 09:15:39AM +0100, Petr Lautrbach wrote:
On 01/11/2015 09:22 PM, Pasi Kärkkäinen wrote:
Hello,
People who have their names in the Fedora tcp_wrappers changelog added to
CC list..
Any comments about the below? Obviously aclexec feature would be useful for
Hello,
On Sunday, 11 January 2015 2:27 PM, Peter Robinson wrote:
Earlier in the discussions I was told that this is not really an issue: in
production, about every server with remote access also has a KVM.
Often not the case in small business or third party hosted environments.
Without
On 01/11/2015 09:22 PM, Pasi Kärkkäinen wrote:
Hello,
People who have their names in the Fedora tcp_wrappers changelog added to CC
list..
Any comments about the below? Obviously aclexec feature would be useful for
all services using tcpwrappers/libwrap (ftp,telnet,tftp,ident,nfs, and
- Original Message -
Will F22 introduce plasma5 when it rolls out?
Yes, it will. KDE SIG guys are working on the Change page for
Fedora 22 [1]. It will be announced soon.
Jaroslav
[1] http://fedoraproject.org/wiki/Changes/Plasma_5
--
Mike Chambers
Madisonville, KY
Best little
No, this is not good idea as I wrote few minutes ago because it does not
improve security, it just provide feeling of better security, see:
https://en.wikipedia.org/wiki/Security_through_obscurity
I wonder why no-one responded like me, because this was discussed many
times ago. Well maybe many
On 11. 1. 2015 at 20:40:56, Adrian Soliard wrote:
Hi everyone!
I'm struggling a bit with dnf. It may have advantages, but as an
end-user, I'm fighting with the list of packages when I press TAB.
It's complicated, if I forget to install a specific package, dnf
wouldn't show it to me, yum do
Hello,
Sshd(8) daemon by default allows remote users to login as root.
1. Is that really necessary?
2. Lot of users use their systems as root, without even creating a
non-root user.
Such practices need to be discouraged, not allowing remote root
login could be
useful in
Hi,
On 08-01-15 13:59, Hans de Goede wrote:
Hi,
On 08-01-15 13:31, Jaroslav Reznik wrote:
- Original Message -
= Proposed System Wide Change: Change xorg input stack to use libinput =
https://fedoraproject.org/wiki/Changes/LibinputForXorg
Change owner(s): Hans de Goede
Compose started at Mon Jan 12 05:15:08 UTC 2015
Broken deps for i386
--
[Sprog]
Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0)
[aeskulap]
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libofstd.so.3.6
Am 12.01.2015 um 14:26 schrieb Richard Hughes:
On 12 January 2015 at 12:48, Josh Boyer jwbo...@fedoraproject.org wrote:
There's Workstation, which is actually looking at including KDE as well.
It is? Why?
why not?
not everybody likes GNOME for several reasons and it would be *so much*
On 01/12/2015 02:08 PM, Vít Ondruch wrote:
Dear Fedora developers,
I'd like to collect some feedback about the $SUBJECT, i.e. making
minimal build root really minimal, explicitly specifying build
dependencies, etc.
I strongly support this idea.
In the past it probaby made sense to have GCC
On 01/12/2015 08:05 AM, P J P wrote:
Again, issue being addressed is not of brute force attacks. But that
of such attacks resulting in gaining 'root' access to remote machines.
They are two distinct issues.
There still needs to be an administrative access to the system, and the
most common
On Mon, 12 Jan 2015, Przemek Klosowski wrote:
There still needs to be an administrative access to the system, and the most
common implementation by enabling 'sudo'
on the non-privileged account. So, in a sense you are both right: this feature
is just a small step rather than a
security
On Monday, 12 January 2015 5:59 PM, Milan Keršláger wrote:
You are (instead of completly mitigating), only raising complexity a
little bit (ie not completly avoiding), which is what is Security
through obscurity about (ie. by hiding source code, the attacker only
solve more complex problem -
On 12 January 2015 at 12:48, Josh Boyer jwbo...@fedoraproject.org wrote:
There's Workstation, which is actually looking at including KDE as well.
It is? Why?
RIchard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of
On 01/12/2015 02:30 PM, Marcin Juszkiewicz wrote:
W dniu 12.01.2015 o 14:08, Vít Ondruch pisze:
I'd like to collect some feedback about the $SUBJECT, i.e. making
minimal build root really minimal, explicitly specifying build
dependencies, etc.
Are you aware that this means changing
Hi,
On 12-01-15 13:48, Josh Boyer wrote:
On Mon, Jan 12, 2015 at 5:32 AM, Hans de Goede hdego...@redhat.com wrote:
Hi,
On 08-01-15 13:59, Hans de Goede wrote:
Hi,
On 08-01-15 13:31, Jaroslav Reznik wrote:
- Original Message -
= Proposed System Wide Change: Change xorg input
commit 55c7a5f55fb6ba0aa1bada16315adad046f467b2
Author: Petr Šabata con...@redhat.com
Date: Mon Jan 12 14:23:44 2015 +0100
0.72 bump; fix stalled transfers (#1177212)
.gitignore|3 ++-
perl-File-RsyncP.spec | 45 +++--
sources
- Original Message -
Dear Fedora developers,
I'd like to collect some feedback about the $SUBJECT, i.e. making
minimal build root really minimal, explicitly specifying build
dependencies, etc.
The topic originally spring out in this [1] discussion on packaging
list. Interesting
On 12 Jan 2015, at 03:56, P J P wrote:
Hello,
On Sunday, 11 January 2015 2:27 PM, Peter Robinson wrote:
Earlier in the discussions I was told that this is not really an
issue: in
production, about every server with remote access also has a KVM.
Often not the case in small business or
Dear Fedora developers,
I'd like to collect some feedback about the $SUBJECT, i.e. making
minimal build root really minimal, explicitly specifying build
dependencies, etc.
The topic originally spring out in this [1] discussion on packaging
list. Interesting FPC discussion on this topic can be
W dniu 12.01.2015 o 14:08, Vít Ondruch pisze:
I'd like to collect some feedback about the $SUBJECT, i.e. making
minimal build root really minimal, explicitly specifying build
dependencies, etc.
Are you aware that this means changing build dependencies of most of
packages? Altering them just
On Mon, Jan 12, 2015 at 8:26 AM, Richard Hughes hughsi...@gmail.com wrote:
On 12 January 2015 at 12:48, Josh Boyer jwbo...@fedoraproject.org wrote:
There's Workstation, which is actually looking at including KDE as well.
It is? Why?
Because it was a work item from F21 that didn't make it and
On Mon, 12 Jan 2015 14:30:49 +0100
Marcin Juszkiewicz mjuszkiew...@redhat.com wrote:
W dniu 12.01.2015 o 14:08, Vít Ondruch pisze:
I'd like to collect some feedback about the $SUBJECT, i.e. making
minimal build root really minimal, explicitly specifying build
dependencies, etc.
Are
Change in package status over the last 168 hours
9 packages were orphaned
dircproxy [master, f21, f20, el6, el5] was orphaned by kevin
IRC proxy server
https://admin.fedoraproject.org/pkgdb/package/dircproxy
On Mon, Jan 12, 2015 at 5:32 AM, Hans de Goede hdego...@redhat.com wrote:
Hi,
On 08-01-15 13:59, Hans de Goede wrote:
Hi,
On 08-01-15 13:31, Jaroslav Reznik wrote:
- Original Message -
= Proposed System Wide Change: Change xorg input stack to use libinput =
- Original Message -
It has happened again. :-/
| This message is a notice that Fedora 19 is now at end of life. Fedora
| has stopped maintaining and issuing updates for Fedora 19. It is
| Fedora's policy to close all bug reports from releases that are no
| longer maintained.
|
|
Hi!
I have a couple of packages submitted for review and I offer to make
swaps for them:
Globus Toolkit packages (C code - mostly loadable modules)
https://bugzilla.redhat.com/show_bug.cgi?id=1144800
globus-gridmap-eppn-callout
https://bugzilla.redhat.com/show_bug.cgi?id=1144801
If anyone is interested in having USB/IP working in Fedora, I'm looking
for someone to review the userspace tools at
https://bugzilla.redhat.com/show_bug.cgi?id=1175270.
While the USB/IP modules were in staging, this was in RPM Fusion, but
the modules have been moved out of staging and into
Hi,
That's not security through obscurity. It's a way to limit the exposure to
a brute force attack with an a privileged account.
Also this allows the user uses a different account so remote attacks that
user is unknown and can not be used to brute force delimiting more
exposure.
Most instances
Hello,
On Monday, 12 January 2015 4:09 PM, Ian Malone ibmal...@gmail.com wrote:
On 12 January 2015 at 09:20, Milan Keršláger milan.kersla...@pslib.cz
4) Blocking root access means forcing admins to log as normal user and
then do su/sudo and providing root password, which is far less
2015-01-12 5:35 GMT-03:00 Igor Gnatenko i.gnatenko.br...@gmail.com:
On Mon, Jan 12, 2015 at 11:27 AM, Jan Zelený jzel...@redhat.com wrote:
On 11. 1. 2015 at 20:40:56, Adrian Soliard wrote:
Hi everyone!
I'm struggling a bit with dnf. It may have advantages, but as an
end-user, I'm fighting
You pointed to SELinux and two factor authentication to be like your
solution (ie disabling root login), but these tools (SELinux/twofactor
auth.) are build to completly mitigate the attack (the attacker is
unable to perform the needed action in any way).
You are (instead of completly
Hello Milan,
On Monday, 12 January 2015 3:11 PM, Milan Keršláger wrote:
No, this is not good idea as I wrote few minutes ago because it does not
improve security, it just provide feeling of better security, see:
https://en.wikipedia.org/wiki/Security_through_obscurity
I disagree. First
= Proposed System Wide Change: Default Local DNS Resolver =
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
This Change was already proposed as Fedora 21 Change but moved to Fedora 22
(and discussed as Fedora 22 Change), re-announcing it as more details were
provided as
On Sun, 11.01.15 21:29, Tomasz Torcz (to...@pipebreaker.pl) wrote:
On Sat, Jan 10, 2015 at 12:16:38AM +0200, Pasi Kärkkäinen wrote:
Hello,
I recently noticed Debian/Ubuntu has had support for aclexec in
tcp_wrappers via a custom patch since 2006,
so you can do this in
Dne 12.1.2015 v 14:30 Marcin Juszkiewicz napsal(a):
W dniu 12.01.2015 o 14:08, Vít Ondruch pisze:
I'd like to collect some feedback about the $SUBJECT, i.e. making
minimal build root really minimal, explicitly specifying build
dependencies, etc.
Are you aware that this means changing build
Dne 12.1.2015 v 15:46 Przemek Klosowski napsal(a):
There still needs to be an administrative access to the system, and the
most common implementation by enabling 'sudo' on the non-privileged
account. So, in a sense you are both right: this feature is just a small
step rather than a security
WG meeting will be at 12:00 UTC (07:00 EST, 13:00 Brno, 7:00 Boston,
21:00 Tokyo, 22:00 Brisbane) in #fedora-meeting on Freenode.
= Topics =
* Fedora Rings
* revisit the plan around rings
* interpret rings with users' use cases and requirements
* sync on where SCLs, copr, languages
On Mon, 12 Jan 2015 20:39:35 +0100
Milan Keršláger milan.kersla...@pslib.cz wrote:
...snip...
Hey Milan.
I understand you have a strong opinion on this topic as does pjp.
This is however no reason to bring personal attacks into things.
Please focus on the technical discussion.
kevin
I noticed that I'm unable to watch Vimeo videos with Firefox without
Flash plugin. Same is not true if I use the Firefox build from upstream.
Do we disable something on our build that may be responsible for such
behavior? Anyone else has the same problem?
I even enabled h264 codec (although I
On 12 January 2015 at 11:58, P J P pj.pan...@yahoo.co.in wrote:
On Tuesday, 13 January 2015 12:05 AM, Stephen John Smoogen wrote:
I don't see how this is the case. All we have done is move the
first line of the root-kit script to calling sudo via the password
that was used to open the account
Dne 12.1.2015 v 20:46 Kevin Fenzi napsal(a):
On Mon, 12 Jan 2015 20:39:35 +0100
Milan Keršláger milan.kersla...@pslib.cz wrote:
...snip...
Hey Milan.
I understand you have a strong opinion on this topic as does pjp.
This is however no reason to bring personal attacks into things.
Oh
On Sat, Jan 10, 2015 at 6:12 PM, Richard W.M. Jones rjo...@redhat.com wrote:
Does this proposal apply to native non-C/C++ programs?
Rich.
I would like to see this proposal apply to native non-C/C++ programs,
but I am not sure on how that would be done?
Do the other compilers understand what
On Tuesday, 13 January 2015 12:05 AM, Stephen John Smoogen wrote:
I don't see how this is the case. All we have done is move the
first line of the root-kit script to calling sudo via the password
that was used to open the account up. Since many of Linux systems
are single user boxes.. it is most
Dear PJP, in the ship, there is a hole. You are waving the flag
unsinkable instead to stop the flow and screaming: The flow could be
stopped later!.
You dismiss my arguments without argument, just dismiss them. Unbelievable.
Is this about security or about your ego? Could do you agree that we
On 12 January 2015 at 12:52, Milan Keršláger milan.kersla...@pslib.cz
wrote:
Dne 12.1.2015 v 20:46 Kevin Fenzi napsal(a):
On Mon, 12 Jan 2015 20:39:35 +0100
Milan Keršláger milan.kersla...@pslib.cz wrote:
...snip...
Hey Milan.
I understand you have a strong opinion on this topic as
Scrap that, Kevin Kofler pointed me to this post:
https://lists.fedoraproject.org/pipermail/devel/2014-December/205490.html
Which I unfortunately missed, so the info I got from KDE upstream is
not correct because the KDE spin adds an extra component which does
directly talk to the low
On Mon, Jan 12, 2015 at 9:31 PM, Miloslav Trmač m...@redhat.com wrote:
Scrap that, Kevin Kofler pointed me to this post:
https://lists.fedoraproject.org/pipermail/devel/2014-December/205490.html
Which I unfortunately missed, so the info I got from KDE upstream is
not correct because the KDE
- Original Message -
Does this proposal apply to native non-C/C++ programs?
As written, it seems to intend so. In practice, it would probably apply or not
depending on whether the non-C/C++ programs’ builds are affected by
_hardened_build.
Ideally, I think this should apply to all
That said, even on x86_64 it isn't anything close to no overhead.
Tried last night to rebuild GCC's cc1plus as -fpie -pie, and then
rebuild stage3 of GCC with make -j1 separately with the original stage3
cc1plus (ET_EXEC binary) and PIE cc1plus (ET_DYN). The build (which
included still time
- The 'method' used to restrict remote root access is negotiable. Ie. disable
it completely by setting PermitRootLogin=no OR disable remote root login
via password by setting PermitRootLogin=without-password.
(The general theme of this mail: Being flexible is fine, and establishing this
- improves accountability for administrative actions (we know which admin
messed up :)
Nonsense. for non-malicious logins, sudo leaves as much as a trail as
sshd which tells you which credentials were used to login. For malicious
logins, once root access is obtained via password-less
On Mon, Jan 12, 2015 at 03:37:42PM -0500, Miloslav Trmač wrote:
- Original Message -
Does this proposal apply to native non-C/C++ programs?
As written, it seems to intend so. In practice, it would probably
apply or not depending on whether the non-C/C++ programs’ builds are
First of all, I agree with you that PermitRootLogin without-password is
preferable.
The discussion I am interested in is whether direct password root login
should remain enabled.
On 01/12/2015 10:02 AM, Paul Wouters wrote:
On Mon, 12 Jan 2015, Przemek Klosowski wrote:
- improves
Am Montag, den 12.01.2015, 17:20 + schrieb P J P:
If you really want to improve security and mitigate BF attacks against
root, do this:
A) do not run SSHD by default
That's a non-option.
This is actually implemented in Workstation, i.e. the sshd.service is
not enabled by default
On Mon, Jan 12, 2015 at 10:57:50AM -0800, Moez Roy wrote:
On Sat, Jan 10, 2015 at 6:12 PM, Richard W.M. Jones rjo...@redhat.com wrote:
Does this proposal apply to native non-C/C++ programs?
Rich.
I would like to see this proposal apply to native non-C/C++ programs,
but I am not sure
Devel,
I would like to un-retire mumble, but that requires ice.
I've just fixed ice to compile on f21 without much effort.
So I think I'll un-retire ice and mumble and maintain them
unless anyone objects.
Is there any reason ice was orphaned and retired other than
lack of interest?
Cheers,
Stephen Gallagher wrote:
I doubt that User C *as described* exists. I suspect you meant User C
does not want an interactive notification. They want things to be
blocked and logged appropriately, so that if things are not behaving as
expected, they can find out why and what they would need to
Michael Schwendt wrote:
* Last upstream release is from 2007 and the same as offered by Fedora.
Then it's not the Fedora maintainer who is not doing his/her job.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Jan 13, 2015 at 12:35 AM, Kevin Kofler kevin.kof...@chello.at wrote:
Vít Ondruch wrote:
I'd like to collect some feedback about the $SUBJECT, i.e. making
minimal build root really minimal, explicitly specifying build
dependencies, etc.
-1, all the serious software requires gcc,
On Mon, 12 Jan 2015, Przemek Klosowski wrote:
First of all, I agree with you that PermitRootLogin without-password is
preferable.
Good :)
The discussion I am interested in is whether direct password root login should
remain enabled.
With root logins, all you have on the client machine
Vít Ondruch wrote:
I'd like to collect some feedback about the $SUBJECT, i.e. making
minimal build root really minimal, explicitly specifying build
dependencies, etc.
-1, all the serious software requires gcc, gcc-c++ and make to build.
I actually think that cmake should be added to the
Hi Carlos,
On Tue, Jan 13, 2015 at 2:41 AM, Carlos O'Donell car...@redhat.com wrote:
I would like to un-retire mumble, but that requires ice.
I've just fixed ice to compile on f21 without much effort.
So I think I'll un-retire ice and mumble and maintain them
unless anyone objects.
Is
On Tue, Jan 13, 2015 at 7:31 AM, Richard W.M. Jones rjo...@redhat.com wrote:
On Mon, Jan 12, 2015 at 10:50:07PM +0100, Till Maas wrote:
On Mon, Jan 12, 2015 at 03:37:42PM -0500, Miloslav Trmač wrote:
- Original Message -
Does this proposal apply to native non-C/C++ programs?
As
On Tuesday, 13 January 2015 1:10 AM, Stephen John Smoogen wrote:
Sorry if I am misunderstanding but the feature is to address brute
forcing the root account so that they do not get root access to the server.
Right.
I am saying that this isn't a speed-bump because they are already trying
to
On Mon, Jan 12, 2015 at 10:50:07PM +0100, Till Maas wrote:
On Mon, Jan 12, 2015 at 03:37:42PM -0500, Miloslav Trmač wrote:
- Original Message -
Does this proposal apply to native non-C/C++ programs?
As written, it seems to intend so. In practice, it would probably
apply or
On Tue 13 Jan 2015 01:35:26 AM CET Kevin Kofler wrote:
Vít Ondruch wrote:
I'd like to collect some feedback about the $SUBJECT, i.e. making
minimal build root really minimal, explicitly specifying build
dependencies, etc.
-1, all the serious software requires gcc, gcc-c++ and make to build.
On 01/13/2015 07:12 AM, Stanislav Ochotnicky wrote:
On Tue 13 Jan 2015 01:35:26 AM CET Kevin Kofler wrote:
Vít Ondruch wrote:
I'd like to collect some feedback about the $SUBJECT, i.e. making
minimal build root really minimal, explicitly specifying build
dependencies, etc.
-1, all the
On 12. 1. 2015 at 07:55:26, Adrian Soliard wrote:
2015-01-12 5:35 GMT-03:00 Igor Gnatenko i.gnatenko.br...@gmail.com:
On Mon, Jan 12, 2015 at 11:27 AM, Jan Zelený jzel...@redhat.com wrote:
On 11. 1. 2015 at 20:40:56, Adrian Soliard wrote:
Hi everyone!
I'm struggling a bit with dnf.
On Tuesday, 13 January 2015 3:06 AM, Miloslav Trmač wrote:
(The general theme of this mail: Being flexible is fine, and establishing
this
through this discussion is great; however, ultimately the Change proposal
needs
to document the _specific outcome_ of that discussion.²)
I
snip
Vít Ondruch wrote:
I'd like to collect some feedback about the $SUBJECT, i.e. making
minimal build root really minimal, explicitly specifying build
dependencies, etc.
+1
As somebody who works on software that sometimes get rebuilt by other
people not using koji or mock, I
Hello Paul,
On Monday, 12 January 2015 11:18 PM, Paul Wouters wrote:
What if I told you Neo, that there are no strong passwords?
Passwords are weak. Some are less weak than others. I'd rather
teach people to use ssh keys for remote access and only restrict
passwords to console/physical
Hi all,
I am Zamir SUN from China. I have been promoting Open Source for some
time and been an ambassador last year. Now I want to help some more bit
in Fedora.
Recently I find some bugs that can be fixed by fixing the spec. So I'd
like to help with the packager in my spare time.
Although I
On Mon, 12 Jan 2015, P J P wrote:
Agreed Paul, yet it does not mean cracking them would be as easy as slicing
knife through butter. That too for every awkward joe trying their hands at it.
It sounds like all one has to do is just guess the username, and it's game over.
Exactly! Then we are
On 12 Jan 2015, at 12:02, P J P wrote:
On Monday, 12 January 2015 8:47 PM, Mike Pinkerton wrote:
Not just virtualized deployments, but also in remote installs on bare
metal.
Okay and the '%post' install section trick won't help there?
IIUC, it'd depend on which tool/application is used
Delimit the remote access to users with privilege is not in any case
based Security
through Obscurity. Obviously the best option for delimiting access is
disabled by default SSH. I consider before taking such drastic measures
that may affect users of cloud, is more than reasonable disable access
On Monday, 12 January 2015 10:06 PM, Milan Keršláger wrote:
No. It improves nothing. This is step backward.
It gaves bad signal to the user (strong root password is not needed).
Wrong interpretation.
It does not mitigate the BF attack. The original and main reason was to
mitigate BF even
On Monday, 12 January 2015 8:32 PM, Paul Wouters wrote:
do you use PrzemekKlosowski as your username on your fedora? I doubt it.
It is more likely to be przemek, klosowski or pklosowski. In fact, often
this is revealed in mail headers (eg sendmail invoked by user paul).
More often, people
On Monday, 12 January 2015 8:47 PM, Mike Pinkerton wrote:
Not just virtualized deployments, but also in remote installs on bare
metal.
Okay and the '%post' install section trick won't help there?
IIUC, it'd depend on which tool/application is used to do such remote
installations and if
On 12 January 2015 at 06:05, P J P pj.pan...@yahoo.co.in wrote:
On Monday, 12 January 2015 5:59 PM, Milan Keršláger wrote:
You are (instead of completly mitigating), only raising complexity a
little bit (ie not completly avoiding), which is what is Security
through obscurity about (ie.
On Monday, 12 January 2015 11:27 PM, Mike Pinkerton wrote:
Sure, if the tool provides the ability to tweak the install to enable
password-based root login, then one can log in after installation,
upload keys, configure sshd, etc. The question is whether the tool
that is available has that
https://bugzilla.redhat.com/show_bug.cgi?id=807793
Tomas Mraz tm...@redhat.com changed:
What|Removed |Added
Keywords||FutureFeature
https://bugzilla.redhat.com/show_bug.cgi?id=1181027
Bug ID: 1181027
Summary: perl-Date-Calc-XS-6.3-7.fc22 FTBFS: tests fail
Product: Fedora
Version: rawhide
Component: perl-Date-Calc-XS
Assignee: sven.nierl...@consol.de
https://bugzilla.redhat.com/show_bug.cgi?id=1181027
Petr Pisar ppi...@redhat.com changed:
What|Removed |Added
See Also|
https://bugzilla.redhat.com/show_bug.cgi?id=914969
Petr Šabata psab...@redhat.com changed:
What|Removed |Added
Status|ON_QA |CLOSED
Fixed In
https://bugzilla.redhat.com/show_bug.cgi?id=1180918
--- Comment #1 from Paul Howarth p...@city-fan.org ---
Your system appears to have openssl-libs 1.0.1k installed from the
updates-testing repository. This is not a problem in itself, but as you do not
currently have the updates-testing
commit e5d7e0d5a17a57e873fbd7fbb7b6ac512b7ee1c1
Author: Paul Howarth p...@city-fan.org
Date: Mon Jan 12 09:25:50 2015 +
Update to 1.009000
- New upstream release 1.009000
- Added support for 'fields' filtering (GH#25, CPAN RT#99499)
- This release by MICKEY → update
https://bugzilla.redhat.com/show_bug.cgi?id=628655
Jan Pazdziora jpazdzi...@redhat.com changed:
What|Removed |Added
Flags|
https://bugzilla.redhat.com/show_bug.cgi?id=1179566
Petr Pisar ppi...@redhat.com changed:
What|Removed |Added
See Also|
The lightweight tag 'perl-MetaCPAN-Client-1.009000-1.fc22' was created pointing
to:
e5d7e0d... Update to 1.009000
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
A file has been added to the lookaside cache for perl-MetaCPAN-Client:
eeccc169259c0adbe6096a9c9528ff31 MetaCPAN-Client-1.009000.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
commit 6c7ec585ee36dcc97e07b4116b54a0e0694929b4
Author: Petr Šabata con...@redhat.com
Date: Mon Jan 12 14:23:44 2015 +0100
0.72 bump; fix stalled transfers (#1177212)
- Sanitize the SPEC somewhat
.gitignore|1 +
perl-File-RsyncP.spec | 47
commit cd80fc16ecc792f2e37b157a80e76f4e843bef2c
Author: Paul Howarth p...@city-fan.org
Date: Mon Jan 12 13:28:46 2015 +
Update to 2.009
- New upstream release 2.009
- Remove util/analyze.pl; this tool is now together with other SSL tools
at
Summary of changes:
2d8cf7b... - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass (*)
30ce430... Update config.guess/sub for aarch64/ppc64le (*)
8315828... - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_M (*)
afa5470... Perl 5.20 rebuild (*)
945a7ff... 0.72 bump; fix
https://bugzilla.redhat.com/show_bug.cgi?id=1181027
Petr Šabata psab...@redhat.com changed:
What|Removed |Added
Status|NEW |ASSIGNED
A file has been added to the lookaside cache for perl-IO-Socket-SSL:
15be23e33f8183cb424254ea6a7b3bc0 IO-Socket-SSL-2.009.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://bugzilla.redhat.com/show_bug.cgi?id=1181027
--- Comment #2 from Sven Nierlein sven.nierl...@consol.de ---
thank you both.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug
https://bugzilla.redhat.com/show_bug.cgi?id=708377
Petr Šabata psab...@redhat.com changed:
What|Removed |Added
Status|MODIFIED|CLOSED
Fixed In
1 - 100 of 132 matches
Mail list logo
