On 12/12/2013 04:19 AM, Mathieu Bridon wrote:
On Wed, 2013-12-11 at 17:18 +0100, Matthias Runge wrote:
The idea behind is:
you have some application with an issue/error. You'll do rpm -qf
filename and will get a package name, not necessarily the source
package name.
When filing a bug
On Thu, 2013-12-12 at 09:02 +0100, Matthias Runge wrote:
On 12/12/2013 04:19 AM, Mathieu Bridon wrote:
On Wed, 2013-12-11 at 17:18 +0100, Matthias Runge wrote:
The idea behind is:
you have some application with an issue/error. You'll do rpm -qf
filename and will get a package name, not
On 12/12/2013 09:15 AM, Mathieu Bridon wrote:
How is a new user or a GUI-only person
Well, you were talking about someone who had just used rpm -qf, so in
that context rpm -qi made a lot of sense.
Yes, you're right, in that context, it makes sense.
For example:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
Final RC1 images have been uploaded to EC2 and are available at
ami-3b361952 : us-east-1 image for i386
ami-1337187a : us-east-1 image for x86_64
additionally if your looking to the AMI's they have been added to files
in the release tree
On Wed, Dec 11, 2013 at 8:07 PM, Miloslav Trmač m...@volny.cz wrote:
On Wed, Dec 11, 2013 at 6:59 PM, Toshio Kuratomi a.bad...@gmail.com wrote:
* Should packages that ship their own cacerts be patched to use Shared
System Certificates instead? [I think the answer to this is yes]
* If the
Hi there,
Getting a spec for NetworkManager-iodine took minutes (pretty similar to
the NetworkManager-ssh one, which I also maintain).
It's here:
https://bugzilla.redhat.com/show_bug.cgi?id=1040459
Happy to review anything else in return, however I'm aware I'm not a very
experienced packager.
Compose started at Thu Dec 12 08:16:58 UTC 2013
Broken deps for armhfp
--
[avro]
avro-mapred-1.7.5-1.fc20.noarch requires hadoop-mapreduce
avro-mapred-1.7.5-1.fc20.noarch requires hadoop-client
[blueman]
Compose started at Thu Dec 12 08:11:11 UTC 2013
Broken deps for i386
--
[LuxRender]
LuxRender-1.0-16.fc21.i686 requires libImath-2_0.so.10
LuxRender-1.0-16.fc21.i686 requires libIlmThread-2_0.so.10
Dne 10.12.2013 14:20, Pierre-Yves Chibon napsal(a):
On Wed, Nov 13, 2013 at 02:52:27PM +0100, Pierre-Yves Chibon wrote:
I am at a point where I think it starts to look good, the unit-tests are passing
and I seem to be able to do what I want with it. Thus I thought this would be a
good time to
On Thu, Dec 12, 2013 at 01:23:12PM +0100, Vít Ondruch wrote:
Dne 10.12.2013 14:20, Pierre-Yves Chibon napsal(a):
On Wed, Nov 13, 2013 at 02:52:27PM +0100, Pierre-Yves Chibon wrote:
I am at a point where I think it starts to look good, the unit-tests are
passing
and I seem to be able to do
On 13 November 2013 16:59, Pierre-Yves Chibon pin...@pingoured.fr wrote:
On Wed, Nov 13, 2013 at 04:57:38PM +0100, Michael Schwendt wrote:
On Wed, 13 Nov 2013 14:52:27 +0100, Pierre-Yves Chibon wrote:
The development instance of pkgdb2 is at:
http://209.132.184.188/
That page says
On Wed, Dec 11, 2013 at 10:33:34PM +0100, Michał Piotrowski wrote:
The beauty of ecryptfs is that I can encrypt one dir - not whole file
system.
What's the concern with encrypting the whole filesystem? It's better
for you because you leave significant personal information all over
the disk, eg
Dne 12.12.2013 14:42, Pierre-Yves Chibon napsal(a):
On Thu, Dec 12, 2013 at 01:23:12PM +0100, Vít Ondruch wrote:
Dne 10.12.2013 14:20, Pierre-Yves Chibon napsal(a):
On Wed, Nov 13, 2013 at 02:52:27PM +0100, Pierre-Yves Chibon wrote:
I am at a point where I think it starts to look good, the
On Thu, Dec 12, 2013 at 15:17:33 +,
Richard W.M. Jones rjo...@redhat.com wrote:
On Wed, Dec 11, 2013 at 10:33:34PM +0100, Michał Piotrowski wrote:
The beauty of ecryptfs is that I can encrypt one dir - not whole file
system.
What's the concern with encrypting the whole filesystem? It's
Hi,
2013/12/12 Bruno Wolff III br...@wolff.to
On Thu, Dec 12, 2013 at 15:17:33 +,
Richard W.M. Jones rjo...@redhat.com wrote:
On Wed, Dec 11, 2013 at 10:33:34PM +0100, Michał Piotrowski wrote:
The beauty of ecryptfs is that I can encrypt one dir - not whole file
system.
What's
Hi everyone.
During last weeks Base WG discussion about package set and self hosting
of Base we came to a point where especially the self hosting of Base
would currently look absurd as we'd require more than 2000 components to
do so.
For that reason we'd like to propose the following
Agenda:
- Buildreq cleanup initiative
- Review latest WGs planing and PRD state and impacts on Base
- Open Floor
Please send any other topics as usual to the list and/or bring them up
at the start of the meeting.
See you all tomorrow!
Thanks regards, Phil
--
Philipp Knirsch
On 12/12/2013 06:02 PM, Phil Knirsch wrote:
- Review latest WGs planing and PRD state and impacts on Base
?
It's the other way around as in the WG's have to be in alignment how the
impact of Base affects them.
JBG
--
devel mailing list
devel@lists.fedoraproject.org
On Tue, Dec 10, 2013 at 09:44:43PM +0100, Mattias Ellert wrote:
tis 2013-12-10 klockan 12:18 -0500 skrev Darryl L. Pierce:
Of all the packages I
maintain, only one was affected by this issue. That one was easily
solvable by deleting the bundled swig generated code in the sources and
On Thu, Dec 12, 2013 at 06:50:31PM +0100, Phil Knirsch wrote:
Now, to figure our how the build chains for these packages look like
i've cobbled together a (really bad) hack using python and
repoclosure that basically takes a set of packages as an input
(actually a set of requirements) and then
On Thu, Dec 12, 2013 at 06:44:09PM +, Jóhann B. Guðmundsson wrote:
On 12/12/2013 06:02 PM, Phil Knirsch wrote:
- Review latest WGs planing and PRD state and impacts on Base
It's the other way around as in the WG's have to be in alignment how
the impact of Base affects them.
I hope we're
At the Fedora 20 Final Go/No-Go Meeting that just occurred, it was
agreed to Go with the Fedora 20 by Fedora QA and Fedora Development.
Fedora Release Engineering to be notified.
#agreed Fedora QA and Fedora Development are both Go; Fedora Release
Engineering to be notified (with possibility to
On 12/11/2013 11:00 PM, Kevin Kofler wrote:
Brendan Jones wrote:
What is the best way to handle this case:
qWarning(QObject::tr(Client name '%1' occupied.).arg(name).toUtf8());
something like, or can I make it simpler:
qWarning(%s,qPrintable(QObject::tr(Client name '%1'
RHEL7 beta is out - too early to start thinking about EPEL7?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301
Just the right time if you ask me! How do we get the ball rolling?
On Thu, Dec 12, 2013 at 10:53 AM, Orion Poplawski or...@cora.nwra.comwrote:
RHEL7 beta is out - too early to start thinking about EPEL7?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA,
W dniu 12.12.2013 19:55, Jeff Sheltren pisze:
Just the right time if you ask me! How do we get the ball rolling?
Hm, how can I help for? ;)
On Thu, Dec 12, 2013 at 10:53 AM, Orion Poplawski or...@cora.nwra.com
mailto:or...@cora.nwra.com wrote:
RHEL7 beta is out - too early to start
It's not at all too soon, and I was/am planning on writing up a more
detailed email on it very soon.
Look for that in the next few days...
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
Greetings.
Several folks have been asking about epel7 and we should get the ball
rolling now that there is a public rhel7 beta.
I'd like to propose a similar plan to the one we used for epel6, which
the possible exception of branching method.
For epel6 we asked maintainers who didn't want to
branch from EPEL6?
How to deal with systemd related things?
Is it possible to branch from branches determined by packagers?
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
On Thu, Dec 12, 2013 at 5:07 PM, Kevin Fenzi ke...@scrye.com wrote:
Several folks have been asking about epel7 and we should get the ball
rolling now that there is a public rhel7 beta.
I'd like to propose a similar plan to the one we used for epel6, which
the possible exception of branching
The following Fedora EPEL 5 Security updates need testing:
Age URL
600
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5
114
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11276/ssmtp-2.61-21.el5
90
The following Fedora EPEL 6 Security updates need testing:
Age URL
600
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6
114
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11274/ssmtp-2.61-21.el6
56
On 12/12/2013 05:07 PM, Kevin Fenzi wrote:
Greetings.
Several folks have been asking about epel7 and we should get the ball
rolling now that there is a public rhel7 beta.
I'd like to propose a similar plan to the one we used for epel6, which
the possible exception of branching method.
For
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 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:
A file has been added to the lookaside cache for perl-Path-Tiny:
a4cda6f443033934eb557cbb8b1256af Path-Tiny-0.049.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
commit b00bff754cc070d326ccc3ec44b90950d65f9e8e
Author: Paul Howarth p...@city-fan.org
Date: Thu Dec 12 12:11:17 2013 +
Update to 0.049
- New upstream release 0.049
- Added 'subsumes' method
- The 'chomp' option for 'lines' will remove any end-of-line sequences
The lightweight tag 'perl-Path-Tiny-0.049-1.fc21' was created pointing to:
b00bff7... Update to 0.049
--
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=1041304
Bug ID: 1041304
Summary: FTBFS: self check failures
Product: Fedora
Version: 20
Component: perl-PDL
Severity: high
Priority: medium
Assignee: jples...@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1041304
--- Comment #1 from Karsten Hopp kars...@redhat.com ---
Created attachment 835830
-- https://bugzilla.redhat.com/attachment.cgi?id=835830action=edit
root.log
--
You are receiving this mail because:
You are on the CC list for the bug.
A file has been added to the lookaside cache for perl-Gtk2:
605b419fca92c5166f0d0077663c7c98 Gtk2-1.249.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
commit f64bb9f7ce22257efafda44ca8fa27c03b122335
Author: Tom Callaway s...@fedoraproject.org
Date: Thu Dec 12 13:19:40 2013 -0500
1.249
.gitignore |1 +
perl-Gtk2.spec |5 -
sources|2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git
https://bugzilla.redhat.com/show_bug.cgi?id=1040416
Tom spot Callaway tcall...@redhat.com changed:
What|Removed |Added
Status|NEW |CLOSED
A file has been added to the lookaside cache for perl-GD:
b2f1e47dfc1c4e4fdda3277f165d36e5 GD-2.50.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
commit b76f082a0bfb575ca118f3f1a2d368724c69d3d7
Author: Tom Callaway s...@fedoraproject.org
Date: Thu Dec 12 16:44:15 2013 -0500
update to 2.50, disable -Wformat=0
.gitignore |1 +
perl-GD.spec |9 +++--
sources |2 +-
3 files changed, 9 insertions(+), 3
https://bugzilla.redhat.com/show_bug.cgi?id=1037241
Tom spot Callaway tcall...@redhat.com changed:
What|Removed |Added
Status|NEW |CLOSED
https://fedorahosted.org/389/ticket/47621
https://fedorahosted.org/389/attachment/ticket/47621/0001-Ticket-47621-make-referential-integrity-configuratio.patch
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
Hi all,
This review takes into account the previous review recommendations:
- change args.get with default values
- change list() so that it returns
- default the environment file related to the instance
(/etc/sysconfig/dirsrv-serverid or
https://fedorahosted.org/389/ticket/47613
https://fedorahosted.org/389/attachment/ticket/47613/0001-Ticket-47613-Issues-setting-allowed-mechanisms.patch
--
Mark Reynolds
389 Development Team
Red Hat, Inc
mreyno...@redhat.com
--
389-devel mailing list
389-devel@lists.fedoraproject.org
The fix did not cleanly cherry-pick to 1.3.2 and 1.3.1, this caused the
replication schedule to be freed twice. The second free dereferenced
the null pointer.
https://fedorahosted.org/389/ticket/47620
https://fedorahosted.org/389/ticket/47525
https://fedorahosted.org/389/attachment/ticket/47525/0001-Ticket-47525-Don-t-modify-preop-entry-in-memberOf-co.patch
The previous fix for this issue was causing a crash in one of the
in-tree tests. This patch addresses the crash.
--
389-devel mailing
On 12/12/2013 04:08 PM, Nathan Kinder wrote:
https://fedorahosted.org/389/ticket/47525
https://fedorahosted.org/389/attachment/ticket/47525/0001-Ticket-47525-Don-t-modify-preop-entry-in-memberOf-co.patch
The previous fix for this issue was causing a crash in one of the
in-tree tests. This
- Original Message -
On 12/12/2013 01:18 AM, Bohuslav Kabrda wrote:
Well yeah, my point is that there is no upstream-acceptable way other than
checking the file hashes by ensurepip, is there? If I wouldn't want to
check file hashes, I'd have to query RPM for release - or is there
53 matches
Mail list logo