Is this expected to not compile with -fno-implicit-templates?
---%---
$ cat test.cc
#include string
std::string test(int i)
{
std::string t;
std::string s = (;
t = ;
for (int r = i; r; r=1) {
if (r 1)
t = 1 + t;
else
t = 0 + t;
}
s
* Matthew Miller:
On Fri, Mar 27, 2015 at 08:28:21PM +0100, drago01 wrote:
Actually machine generated isn't per se bad ... it saves a lot of
effort and should be done more (for other packages too where
possible).
Why waste man power for something that can be automated?
As for tex ... we
https://bugzilla.redhat.com/show_bug.cgi?id=1171035
--- Comment #4 from Upstream Release Monitoring
upstream-release-monitor...@fedoraproject.org ---
Scratch build succeeded
http://koji.fedoraproject.org/koji/taskinfo?taskID=9358380
--
You are receiving this mail because:
You are on the CC
Hi
if you want can take one of these
https://bugzilla.redhat.com/show_bug.cgi?id=1202470
https://bugzilla.redhat.com/show_bug.cgi?id=1199841
https://bugzilla.redhat.com/show_bug.cgi?id=1199842
regards
gil
Il 28/03/2015 22:58, Piotr Popieluch ha scritto:
I am looking for a review for
https://bugzilla.redhat.com/show_bug.cgi?id=1171035
Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org
changed:
What|Removed |Added
https://bugzilla.redhat.com/show_bug.cgi?id=1171035
--- Comment #3 from Upstream Release Monitoring
upstream-release-monitor...@fedoraproject.org ---
Created attachment 1007883
-- https://bugzilla.redhat.com/attachment.cgi?id=1007883action=edit
[patch] Update to 1.012 (#1171035)
--
You are
2015-03-28 16:06 GMT-03:00 Paulo César Pereira de Andrade
paulo.cesar.pereira.de.andr...@gmail.com:
Is this expected to not compile with -fno-implicit-templates?
---%---
$ cat test.cc
#include string
std::string test(int i)
{
std::string t;
std::string s = (;
t = ;
for
I am looking for a review for carbon-c-relay and offering a review swap,
I really want to get this in.
https://bugzilla.redhat.com/show_bug.cgi?id=1190390
I've also got some nodejs module review requests pending, also doing a
review swap for any of them:
https://tinyurl.com/oeyju9l
(this has
On Sat, Mar 28, 2015 at 06:05:11PM +, Jonathan Underwood wrote:
rjonesemacs-common-tuareg
Update in Rawhide:
http://pkgs.fedoraproject.org/cgit/emacs-common-tuareg.git/commit/?id=4e05b9b64d9a6723d0b72b9b7319428ee670cf0d
Rich.
--
Richard Jones, Virtualization Group, Red Hat
On 28 March 2015 at 19:28, Richard W.M. Jones rjo...@redhat.com wrote:
On Sat, Mar 28, 2015 at 06:05:11PM +, Jonathan Underwood wrote:
rjonesemacs-common-tuareg
Update in Rawhide:
perl-Getopt-GUI-Long has broken dependencies in the epel-5 tree:
On ppc:
perl-Getopt-GUI-Long-0.91-5.el5.noarch requires perl(Gtk2)
On x86_64:
perl-Getopt-GUI-Long-0.91-5.el5.noarch requires perl(Gtk2)
On i386:
perl-Getopt-GUI-Long-0.91-5.el5.noarch requires perl(Gtk2)
perl-Getopt-GUI-Long has broken dependencies in the epel-5 tree:
On ppc:
perl-Getopt-GUI-Long-0.91-5.el5.noarch requires perl(Gtk2)
On x86_64:
perl-Getopt-GUI-Long-0.91-5.el5.noarch requires perl(Gtk2)
On i386:
perl-Getopt-GUI-Long-0.91-5.el5.noarch requires perl(Gtk2)
perl-XML-Xerces has broken dependencies in the epel-5 tree:
On ppc:
perl-XML-Xerces-2.7.0_0-4.el5.ppc requires libxerces-c.so.27
On x86_64:
perl-XML-Xerces-2.7.0_0-4.el5.x86_64 requires libxerces-c.so.27()(64bit)
On i386:
perl-XML-Xerces-2.7.0_0-4.el5.i386 requires
https://bugzilla.redhat.com/show_bug.cgi?id=1205658
Fedora Update System upda...@fedoraproject.org changed:
What|Removed |Added
Status|MODIFIED|ON_QA
2015-03-28 16:40 GMT-03:00 Florian Weimer f...@deneb.enyo.de:
* Matthew Miller:
On Fri, Mar 27, 2015 at 08:28:21PM +0100, drago01 wrote:
Actually machine generated isn't per se bad ... it saves a lot of
effort and should be done more (for other packages too where
possible).
Why waste man
https://bugzilla.redhat.com/show_bug.cgi?id=1197438
--- Comment #2 from Fedora Update System upda...@fedoraproject.org ---
perl-HTTP-Body-1.22-1.fc22 has been pushed to the Fedora 22 stable repository.
If problems still persist, please make note of it in this bug report.
--
You are receiving
https://bugzilla.redhat.com/show_bug.cgi?id=1202793
Fedora Update System upda...@fedoraproject.org changed:
What|Removed |Added
Fixed In Version|perl-Module-Path-0.19-1.fc2
https://bugzilla.redhat.com/show_bug.cgi?id=1204317
Bug 1204317 depends on bug 1203767, which changed state.
Bug 1203767 Summary: perl-Config-MVP-2.200010 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1203767
What|Removed |Added
https://bugzilla.redhat.com/show_bug.cgi?id=1203767
Fedora Update System upda...@fedoraproject.org changed:
What|Removed |Added
Status|ON_QA |CLOSED
https://bugzilla.redhat.com/show_bug.cgi?id=1203779
Bug 1203779 depends on bug 1203767, which changed state.
Bug 1203767 Summary: perl-Config-MVP-2.200010 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1203767
What|Removed |Added
https://bugzilla.redhat.com/show_bug.cgi?id=1204104
--- Comment #4 from Fedora Update System upda...@fedoraproject.org ---
perl-Scope-Upper-0.26-1.fc22 has been pushed to the Fedora 22 stable
repository. If problems still persist, please make note of it in this bug
report.
--
You are
perl-XML-Xerces has broken dependencies in the epel-5 tree:
On ppc:
perl-XML-Xerces-2.7.0_0-4.el5.ppc requires libxerces-c.so.27
On x86_64:
perl-XML-Xerces-2.7.0_0-4.el5.x86_64 requires libxerces-c.so.27()(64bit)
On i386:
perl-XML-Xerces-2.7.0_0-4.el5.i386 requires
perl-SystemC-Vregs has broken dependencies in the epel-5 tree:
On ppc:
emacs-vregs-mode-1.463-1.el5.noarch requires emacs(bin) = 0:22.1
On x86_64:
emacs-vregs-mode-1.463-1.el5.noarch requires emacs(bin) = 0:22.1
On i386:
emacs-vregs-mode-1.463-1.el5.noarch requires
https://bugzilla.redhat.com/show_bug.cgi?id=1205652
Fedora Update System upda...@fedoraproject.org changed:
What|Removed |Added
Status|MODIFIED|ON_QA
https://bugzilla.redhat.com/show_bug.cgi?id=1202793
Fedora Update System upda...@fedoraproject.org changed:
What|Removed |Added
Fixed In Version|perl-Module-Path-0.19-1.fc2
On Sat, Mar 28, 2015 at 8:44 AM, Richard Hughes hughsi...@gmail.com wrote:
The end result would be that we don't show applications that have
failed the previous two releases mass rebuilds in GNOME Software i.e.
we don't show f19 packages in f21, and we don't show f20 packages in
f22. Should be
Hello,
I'm orphaning a few packages as I do not use them anymore.
* scons
* jed
* greylistd
* and the zathura stack: girara, zathura, zathura-cb, zathura-djvu,
zathura-pdf-poppler, zathura-ps (maintained by contyk)
Regards,
François
--
devel mailing list
devel@lists.fedoraproject.org
On Fri, Mar 27, 2015 at 11:21 PM, Luya Tshimbalanga
l...@fedoraproject.org wrote:
On 27/03/15 03:02 PM, drago01 wrote:
On Fri, Mar 27, 2015 at 11:00 PM, Luya Tshimbalanga
l...@fedoraproject.org wrote:
I recently bought an Asus X550Z which comes with a Quad-Core A10 and Dual
graphic radeon. I
On Sat, Mar 28, 2015 at 12:51 PM, drago01 drag...@gmail.com wrote:
On Fri, Mar 27, 2015 at 11:21 PM, Luya Tshimbalanga
l...@fedoraproject.org wrote:
On 27/03/15 03:02 PM, drago01 wrote:
On Fri, Mar 27, 2015 at 11:00 PM, Luya Tshimbalanga
l...@fedoraproject.org wrote:
I recently bought an
On 28 March 2015 at 15:07, Paulo César Pereira de Andrade
paulo.cesar.pereira.de.andr...@gmail.com wrote:
I maintained a slowly evolving approach in Mandriva for some years,
(but now it is quickly approaching one year I left Mandriva...), see the
main script at
Richard Hughes wrote:
The end result would be that we don't show applications that have
failed the previous two releases mass rebuilds in GNOME Software i.e.
we don't show f19 packages in f21, and we don't show f20 packages in
f22. Should be pretty non-controversial, right? The kind of
On Fri, 27 Mar 2015 17:24:57 -0400
Nathaniel McCallum npmccal...@redhat.com wrote:
...snip...
When the F21 update was being automatically pushed to stable,
taskotron reported that the upgradepath test failed and that push to
stable was unavailable. The failure was because F22 has a lower
2015-03-27 16:58 GMT-03:00 Matthew Miller mat...@fedoraproject.org:
On Fri, Mar 27, 2015 at 08:28:21PM +0100, drago01 wrote:
Actually machine generated isn't per se bad ... it saves a lot of
effort and should be done more (for other packages too where
possible).
Why waste man power for
On 28/03/15 04:51 AM, drago01 wrote:
Thanks. I submitted a bug report to the right component.
https://bugzilla.redhat.com/show_bug.cgi?id=1206733
Your logs in the bug are with nomodeset that's not really helpful
you need to attack logs with nomodeset not set.
If the system does not finish
2015-03-28 13:26 GMT-03:00 Jonathan Underwood jonathan.underw...@gmail.com:
On 28 March 2015 at 15:07, Paulo César Pereira de Andrade
paulo.cesar.pereira.de.andr...@gmail.com wrote:
I maintained a slowly evolving approach in Mandriva for some years,
(but now it is quickly approaching one
Hi,
Presently a lot of packages are not complying with the Emacs packaging
guidelines[1]. These guidelines have been in place in their current
form since Fedora 16, so it's probably time to start fixing packages.
The lists below detail packages with various problems, and their
package owners.
The following Fedora EPEL 7 Security updates need testing:
Age URL
135
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3989/cross-binutils-2.23.88.0.1-2.el7.1
29
The following Fedora EPEL 6 Security updates need testing:
Age URL
1070
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6
135
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-4008/cross-binutils-2.23.51.0.3-1.el6.1
123
The following Fedora EPEL 5 Security updates need testing:
Age URL
1070
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5
525
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5
289
The end result would be that we don't show applications that have
failed the previous two releases mass rebuilds in GNOME Software i.e.
we don't show f19 packages in f21, and we don't show f20 packages in
f22. Should be pretty non-controversial, right? The kind of software
that failed two rebuilds
perl-PDL has broken dependencies in the rawhide tree:
On x86_64:
perl-PDL-2.7.0-8.fc22.x86_64 requires libproj.so.0()(64bit)
On i386:
perl-PDL-2.7.0-8.fc22.i686 requires libproj.so.0
On armhfp:
perl-PDL-2.7.0-8.fc22.armv7hl requires libproj.so.0
Please resolve this as
41 matches
Mail list logo
