Hi,
yesterday, I broke my left arm, so my response time will be
significantly slowed down for about 4 weeks.
I kindly ask my co-maintainers and provenpackagers to look after my
packages.
I'll still be around, i'll also finish my packages reviews.
Regards,
H.
--
devel mailing list
devel@lists.
Am 26.04.2014 02:01, schrieb Jóhann B. Guðmundsson:
> On 04/25/2014 10:53 PM, Miloslav Trmač wrote:
>> I don't think our foundations ever implied that we need or want to be a
>> closed ecosystem restricted to only the
>> repository we produce. The just don't address this.
>
> You must understan
On 04/25/2014 10:53 PM, Miloslav Trmač wrote:
I don't think our foundations ever implied that we need or want to be
a closed ecosystem restricted to only the repository we produce. The
just don't address this.
You must understand we cannot keep back process in the distribution, be
it cl
2014-04-26 0:51 GMT+02:00 Chuck Anderson :
> > Main goal is to have local DNSSEC-validating resolver.
>
> I, as the OP, did not intend that as the goal, although I have no
> problem with that as a different goal. My intent was to fix the
> atrocious failover behavior of the glibc resolver. I als
On Fri, Apr 25, 2014 at 3:51 PM, Chuck Anderson wrote:
> I'm starting a new thread to clarify and emphasize the problem I'm
> actually trying to solve. Here is the problem restated as I posted it
> to the dns-operations list:
>
> -
> Is it really expected that the first DNS server listed in
>
2014-04-26 0:37 GMT+02:00 "Jóhann B. Guðmundsson" :
> On 04/25/2014 05:30 PM, Miloslav Trmač wrote:
>
>> That's certainly an option but it's not the only one; see the recent
>> "Functional" threads for example.
>>
>
> Sorry I did not want to get involved in yet another attack on our
> foundation,
I'm starting a new thread to clarify and emphasize the problem I'm
actually trying to solve. Here is the problem restated as I posted it
to the dns-operations list:
-
Is it really expected that the first DNS server listed in
/etc/resolv.conf should never go down? Operationally speaking, who
On 04/25/2014 05:30 PM, Miloslav Trmač wrote:
That's certainly an option but it's not the only one; see the recent
"Functional" threads for example.
Sorry I did not want to get involved in yet another attack on our
foundation,
Last time I checked Fedora was not LSB certified nor compliant s
Am 25.04.2014 19:30, schrieb Miloslav Trmač:
> 2014-04-25 12:40 GMT+02:00 "Jóhann B. Guðmundsson":
> Which is what we care about we cannot hold back progress in the
> distribution based on someone, someplace,
> somewhere might be using legacy cruff.
>
> It's better for everybody they
On 25/04/14 20:10, Simo Sorce wrote:
On Fri, 2014-04-25 at 14:03 -0400, Adam Jackson wrote:
On Fri, 2014-04-25 at 18:10 +0200, Kevin Kofler wrote:
Petr Spacek wrote:
I'm going to reproduce and debug issue in named. Do you see any specific
reason why I should use -O2 for serious debugging/devel
On Fri, 2014-04-25 at 14:03 -0400, Adam Jackson wrote:
> On Fri, 2014-04-25 at 18:10 +0200, Kevin Kofler wrote:
> > Petr Spacek wrote:
> > > I'm going to reproduce and debug issue in named. Do you see any specific
> > > reason why I should use -O2 for serious debugging/development sessions?
> >
>
On Thu, Apr 24, 2014 at 2:00 AM, Florian Weimer wrote:
> On 04/24/2014 01:57 AM, Andrew Lutomirski wrote:
>>
>> On Mon, Apr 21, 2014 at 12:17 AM, Florian Weimer
>> wrote:
>>>
>>> On 04/21/2014 03:44 AM, Andrew Lutomirski wrote:
Would it
make sense to audit all spec files to lo
I'm really trying to get a package reviewed. Someone had volunteered to
do a review swap, but I haven't heard from him in a while so am asking
again if someone wants to do a review swap?
compat-qpid-cpp - Qpid 0.24 compatibility package
https://bugzilla.redhat.com/show_bug.cgi?id=1080583
--
Darr
On Fri, 2014-04-25 at 18:10 +0200, Kevin Kofler wrote:
> Petr Spacek wrote:
> > I'm going to reproduce and debug issue in named. Do you see any specific
> > reason why I should use -O2 for serious debugging/development sessions?
>
> IMHO, you should always debug with optimization enabled. GDB can
2014-04-24 22:33 GMT+02:00 Kevin Fenzi :
> I'm not sure a open vote is the way to go here. How about we try and
> figure this out on technical grounds?
>
> Personally I think it's fine to be in dnf-plugins-core, but the
> maintainers of dnf don't think so I guess, but that could just be that
> the
2014-04-25 12:40 GMT+02:00 "Jóhann B. Guðmundsson" :
> On 04/24/2014 04:30 PM, Miloslav Trmač wrote:
>
>>
>> Only those that are maintained directly inside Fedora.
>>
>
> Which is what we care about we cannot hold back progress in the
> distribution based on someone, someplace, somewhere might be
On 25.4.2014 18:19, Simo Sorce wrote:
On Fri, 2014-04-25 at 09:56 -0600, Pete Zaitcev wrote:
On Thu, 10 Apr 2014 10:41:54 -0400
Chuck Anderson wrote:
[...] We need an independent,
system-wide DNS cache, and always point resolv.conf to 127.0.0.1 to
solve this fundamental design problem with h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 25 Apr 2014 16:50:40 +
"Jóhann B. Guðmundsson" wrote:
>
> On 04/25/2014 04:50 PM, Dennis Gilmore wrote:
> > all the compose tools fall into the base WG domain
>
> Compose tools != releng and it's service sub community.
I think you will
On 04/25/2014 04:50 PM, Dennis Gilmore wrote:
all the compose tools fall into the base WG domain
Compose tools != releng and it's service sub community.
JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 25 Apr 2014 16:33:02 +
"Jóhann B. Guðmundsson" wrote:
>
> On 04/25/2014 04:21 PM, Phil Knirsch wrote:
> > Quick summary:
> >
> > - jwb already followed up on the agenda that the securetty has
> > already been resolved
> > - jreznik wo
Thanks, Luis.
I just orphaned both python-biopython and sqlite2 so you can go ahead
and take ownership via PkgDB (I added myself as a co-maintainer for
both packages before orphaning).
Cheers,
Alex
Luis Enrique Bazán De León wrote:
> I can take part of this work :-)
> Regards!
- Original
On 04/25/2014 04:21 PM, Phil Knirsch wrote:
Quick summary:
- jwb already followed up on the agenda that the securetty has
already been resolved
- jreznik working with dglimore on the merge reviews
- As pknirsch is on PTO next Friday, jreznik will run it
- Good Open Floor discussion about
Quick summary:
- jwb already followed up on the agenda that the securetty has already
been resolved
- jreznik working with dglimore on the merge reviews
- As pknirsch is on PTO next Friday, jreznik will run it
- Good Open Floor discussion about fedup and install trees and images.
Will foll
On Fri, 2014-04-25 at 09:56 -0600, Pete Zaitcev wrote:
> On Thu, 10 Apr 2014 10:41:54 -0400
> Chuck Anderson wrote:
>
> > [...] We need an independent,
> > system-wide DNS cache, and always point resolv.conf to 127.0.0.1 to
> > solve this fundamental design problem with how name resolution works
Petr Spacek wrote:
> I'm going to reproduce and debug issue in named. Do you see any specific
> reason why I should use -O2 for serious debugging/development sessions?
IMHO, you should always debug with optimization enabled. GDB can cope quite
well with it, and it is the only way to actually debu
I can take part of this work :-)
Regards!
2014-04-25 11:14 GMT-05:00 Alex Lancaster :
> ooolatex needs to be replaced by TeXMaths anyway, see:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1018515
>
> In general, going forward at least for the immediate
> future, I will have to ramp down some
ooolatex needs to be replaced by TeXMaths anyway, see:
https://bugzilla.redhat.com/show_bug.cgi?id=1018515
In general, going forward at least for the immediate
future, I will have to ramp down some of my Fedora efforts.
In the meantime feel free to update any of my packages
if you're provenpack
On Thu, 10 Apr 2014 10:41:54 -0400
Chuck Anderson wrote:
> [...] We need an independent,
> system-wide DNS cache, and always point resolv.conf to 127.0.0.1 to
> solve this fundamental design problem with how name resolution works
> on a Linux system. Windows has had a default system-wide DNS ca
Am 25.04.2014 17:10, schrieb Adam Jackson:
> On Fri, 2014-04-25 at 16:50 +0200, Reindl Harald wrote:
>
>> but it don't justify incompatible flags
>> IMHO you enter the area of "undefined behavior" with that
>
> Your humble opinion is misguided, building without _FORTIFY_SOURCE is an
> entirely r
On Fri, 2014-04-25 at 16:50 +0200, Reindl Harald wrote:
> but it don't justify incompatible flags
> IMHO you enter the area of "undefined behavior" with that
Your humble opinion is misguided, building without _FORTIFY_SOURCE is an
entirely reasonable thing for an end developer to want to do on th
On 25.4.2014 16:50, Reindl Harald wrote:
Am 25.04.2014 16:43, schrieb Petr Spacek:
On 25.4.2014 16:28, Reindl Harald wrote:
Am 25.04.2014 16:10, schrieb Petr Spacek:
I'm trying to rebuild bind-9.9.4-12.P2.fc20.src.rpm with
CFLAGS="$CFLAGS $RPM_OPT_FLAGS -O0 -ggdb".
I did the simplest possibl
On Fri, Apr 25, 2014 at 6:24 AM, Jan Staněk wrote:
> Well, both GPLv3+ and AGPLv3+ have clause ([1], [2]) that allow code
> licensed under one of them link with code under the other one legally -
> only if you run the full product on a server and it interact with users
> trough network, you have t
Am 25.04.2014 16:43, schrieb Petr Spacek:
> On 25.4.2014 16:28, Reindl Harald wrote:
>> Am 25.04.2014 16:10, schrieb Petr Spacek:
>>> I'm trying to rebuild bind-9.9.4-12.P2.fc20.src.rpm with
>>> CFLAGS="$CFLAGS $RPM_OPT_FLAGS -O0 -ggdb".
>>>
>>> I did the simplest possible thing - edited the origi
On 25.4.2014 16:28, Reindl Harald wrote:
Am 25.04.2014 16:10, schrieb Petr Spacek:
I'm trying to rebuild bind-9.9.4-12.P2.fc20.src.rpm with
CFLAGS="$CFLAGS $RPM_OPT_FLAGS -O0 -ggdb".
I did the simplest possible thing - edited the original spec file (see
spec.diff) and built the package:
$ rpm
Am 25.04.2014 16:10, schrieb Petr Spacek:
> I'm trying to rebuild bind-9.9.4-12.P2.fc20.src.rpm with
> CFLAGS="$CFLAGS $RPM_OPT_FLAGS -O0 -ggdb".
>
> I did the simplest possible thing - edited the original spec file (see
> spec.diff) and built the package:
> $ rpmbuild -ba bind.spec
>
> The pac
https://bugzilla.redhat.com/show_bug.cgi?id=1091285
--- Comment #4 from Paul Howarth ---
OK, I've requested EPEL7 branches on the wiki. When they're done, you can
transfer ownership to me:
$ pkgdb-cli unorphan --owner pghmcfc perl-Test-Pod-Content epel7
$ pkgdb-cli unorphan --owner pghmcfc per
Hello list,
I'm trying to rebuild bind-9.9.4-12.P2.fc20.src.rpm with
CFLAGS="$CFLAGS $RPM_OPT_FLAGS -O0 -ggdb".
I did the simplest possible thing - edited the original spec file (see
spec.diff) and built the package:
$ rpmbuild -ba bind.spec
The package builds and BIND itself seems to work. T
commit 40da342725f2a4ad7cc319a564e14ba49b67adec
Author: Petr Písař
Date: Fri Apr 25 15:01:27 2014 +0200
Drop unneeded build-time dependencies
Especially the Plack::Builder created a dependency cycle between
perl-Plack and perl-Apache-LogFormat-Compiler.
perl-Apache-LogFormat-
On 04/15/2014 03:12 PM, Dan Horák wrote:
But do you still need to bootstrap ocaml on the non-native arches to
get the bytecode interpreted one?
We do not build Ocaml completely from source, so no bootstrapping within
Fedora is needed. Upstream did this for us and included the bytecode of
th
Dne 24.4.2014 17:22, Jerry James napsal(a):
> I need some advice on how to handle this for XEmacs, which is a GPLv3+
> package.
Well, both GPLv3+ and AGPLv3+ have clause ([1], [2]) that allow code
licensed under one of them link with code under the other one legally -
only if you run the full pr
On Tue, 08 Apr 2014 13:44:02 +0200
Jaroslav Reznik wrote:
> = Proposed System Wide Change: Mono 3.4 =
> https://fedoraproject.org/wiki/Changes/Mono_3.4
>
> Change owner(s): Claudio Rodrigo Pereyra Diaz
>
>
> Update the Mono stack in Fedora from 2.10 to 3.4
>
> == Detailed Description ==
> S
On 04/22/2014 12:15 PM, Nikos Roussos wrote:
There is also a third group, somewhere in between, who believe that's ok
to ship Free Software that connects and interops with proprietary
services (gtalk, aws, etc), but it's not ok to ship proprietary
software, metadata about proprietary software or
On Fri, Apr 25, 2014 at 01:30:00PM +0200, Lukáš Nykrýn wrote:
> Dne 25.4.2014 13:24, Reindl Harald napsal(a):
> >
> >
> >Am 25.04.2014 13:12, schrieb Lukáš Nykrýn:
> >>Dne 25.4.2014 12:50, Reindl Harald napsal(a):
> >>>Am 25.04.2014 12:40, schrieb Jóhann B. Guðmundsson:
> On 04/24/2014 04:30 PM
Dne 25.4.2014 13:24, Reindl Harald napsal(a):
Am 25.04.2014 13:12, schrieb Lukáš Nykrýn:
Dne 25.4.2014 12:50, Reindl Harald napsal(a):
Am 25.04.2014 12:40, schrieb Jóhann B. Guðmundsson:
On 04/24/2014 04:30 PM, Miloslav Trmač wrote:
Only those that are maintained directly inside Fedora.
Am 25.04.2014 13:12, schrieb Lukáš Nykrýn:
> Dne 25.4.2014 12:50, Reindl Harald napsal(a):
>> Am 25.04.2014 12:40, schrieb Jóhann B. Guðmundsson:
>>> On 04/24/2014 04:30 PM, Miloslav Trmač wrote:
Only those that are maintained directly inside Fedora.
>>>
>>> Which is what we care about
Dne 25.4.2014 12:50, Reindl Harald napsal(a):
Am 25.04.2014 12:40, schrieb Jóhann B. Guðmundsson:
On 04/24/2014 04:30 PM, Miloslav Trmač wrote:
Only those that are maintained directly inside Fedora.
Which is what we care about we cannot hold back progress in the
distribution based on someo
Am 25.04.2014 12:58, schrieb Jóhann B. Guðmundsson:
> On 04/25/2014 10:50 AM, Reindl Harald wrote:
>>
>> Am 25.04.2014 12:40, schrieb Jóhann B. Guðmundsson:
>>> On 04/24/2014 04:30 PM, Miloslav Trmač wrote:
Only those that are maintained directly inside Fedora.
>>> Which is what we care about
Dne 25.4.2014 02:19, Zbigniew Jędrzejewski-Szmek napsal(a):
On Thu, Apr 24, 2014 at 04:38:07PM +0200, Lukáš Nykrýn wrote:
Hi,
for the F22 I am planning some bigger changes regarding initscripts
and I would like to ask for comments.
Initscripts package was in the past a crucial part of the syste
On 04/25/2014 10:50 AM, Reindl Harald wrote:
Am 25.04.2014 12:40, schrieb Jóhann B. Guðmundsson:
On 04/24/2014 04:30 PM, Miloslav Trmač wrote:
Only those that are maintained directly inside Fedora.
Which is what we care about we cannot hold back progress in the
distribution based on someone,
Am 25.04.2014 12:40, schrieb Jóhann B. Guðmundsson:
> On 04/24/2014 04:30 PM, Miloslav Trmač wrote:
>>
>> Only those that are maintained directly inside Fedora.
>
> Which is what we care about we cannot hold back progress in the
> distribution based on someone, someplace, somewhere might be usi
On 04/24/2014 04:30 PM, Miloslav Trmač wrote:
Only those that are maintained directly inside Fedora.
Which is what we care about we cannot hold back progress in the
distribution based on someone, someplace, somewhere might be using
legacy cruff.
It's better for everybody they themselves i
On 04/25/2014 12:19 AM, Zbigniew Jędrzejewski-Szmek wrote:
I too think that this split is a lot of work for small gain. Working
out the full dependencies set of what needs what is going to take a
while, but I think it would be better to simply shrink the package to
nothing in small steps.
I al
Miroslav Suchý píše v Čt 24. 04. 2014 v 11:29 +0200:
> In https://bugzilla.redhat.com/show_bug.cgi?id=1090516
> Jiri asked for removing Copr (and Playground) DNF plugin out of
> dnf-plugins-core.
>
> Since this is not technical but merely political question I would like to ask
> wider audience:
On Fri 25 Apr 2014 06:47:10 AM CEST Tim Lauridsen wrote:
> I have started a new dnf-utils project for commuty plugins/addons there is
> not maintain by the core dnf team
>
> https://github.com/timlau/dnf-utils
>
> copr / playground is welcome here is the core dnf developers, think its
> dont fit i
54 matches
Mail list logo
