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 carbon-c-r
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 lower
2015-03-28 16:40 GMT-03:00 Florian Weimer :
> * 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 po
On 28 March 2015 at 19:28, Richard W.M. Jones wrote:
> 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
>
t
2015-03-28 16:06 GMT-03:00 Paulo César Pereira de Andrade
:
> Is this expected to not compile with -fno-implicit-templates?
>
> ---%<---
> $ cat test.cc
> #include
> std::string test(int i)
> {
> std::string t;
> std::string s = "(";
> t = "";
> for (int r = i; r; r>>=1) {
>
* 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 f
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 http://peo
Is this expected to not compile with -fno-implicit-templates?
---%<---
$ cat test.cc
#include
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;
}
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.
[1]
2015-03-28 13:26 GMT-03:00 Jonathan Underwood :
> On 28 March 2015 at 15:07, Paulo César Pereira de Andrade
> 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
>> https://abf
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
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 sof
On 28 March 2015 at 15:07, Paulo César Pereira de Andrade
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
> https://abf.rosalinux.ru/openmandriva/texlive-tlpkg/blob/master/tlp
On Fri, 27 Mar 2015 17:24:57 -0400
Nathaniel McCallum 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
> version than F21.
2015-03-27 16:58 GMT-03:00 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
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
https://adm
On Sat, Mar 28, 2015 at 12:51 PM, drago01 wrote:
> On Fri, Mar 27, 2015 at 11:21 PM, Luya Tshimbalanga
> wrote:
>> On 27/03/15 03:02 PM, drago01 wrote:
>>> On Fri, Mar 27, 2015 at 11:00 PM, Luya Tshimbalanga
>>> wrote:
I recently bought an Asus X550Z which comes with a Quad-Core A10 and Dua
On Fri, Mar 27, 2015 at 11:21 PM, Luya Tshimbalanga
wrote:
> On 27/03/15 03:02 PM, drago01 wrote:
>> On Fri, Mar 27, 2015 at 11:00 PM, Luya Tshimbalanga
>> wrote:
>>> I recently bought an Asus X550Z which comes with a Quad-Core A10 and Dual
>>> graphic radeon. I am surprised to find out xorg-x11-
On Sat, Mar 28, 2015 at 8:44 AM, 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-cont
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
20 matches
Mail list logo
