On Thu, 12 Jul 2012 15:09:05 +0200, Darryl L. Pierce wrote:
> I think if those packages are languishing, it's like
> the packager was already notified and chose not to push.
Package goes into testing with the goal to get into stable. Therefore by
default it should go into stable when it gets appr
On 07/12/2012 07:08 PM, Jitesh Shah wrote:
django-recaptcha
Looking deeper into upstream, I think, this package should be
deprecated. I'd replace it with a django-recaptcha solutuion from
https://github.com/praekelt/django-recaptcha
gnome-rdp
libdwarf
tcptrack
Jitesh
Thank you for caring ab
That explains it. Thanks a lot!
~kad (android'ed)
On Jul 12, 2012 10:31 PM, "Remi Collet" wrote:
> Le 13/07/2012 07:22, Jorge Gallegos a écrit :
> > Hello everyone,
> >
> > Am I reading this right? the main PEAR package is not in any EPEL
> > version:
> >
> > https://admin.fedoraproject.org/pkgd
Le 13/07/2012 07:22, Jorge Gallegos a écrit :
> Hello everyone,
>
> Am I reading this right? the main PEAR package is not in any EPEL
> version:
>
> https://admin.fedoraproject.org/pkgdb/acls/name/php-pear
>
> However some PEAR libraries *are* in EPEL, which confuses me a
> little bit. How come
Hello everyone,
Am I reading this right? the main PEAR package is not in any EPEL
version:
https://admin.fedoraproject.org/pkgdb/acls/name/php-pear
However some PEAR libraries *are* in EPEL, which confuses me a little
bit. How come some libraries are there but not php-pear?
Thanks in advance
On Thu, Jul 12, 2012 at 6:43 PM, David Sommerseth wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 01/06/12 19:42, Brian Wheeler wrote:
>>
>>
>> On 06/01/2012 12:21 PM, Lennart Poettering wrote:
>>> I think most of the noise in this flame thread is due to a
>>> misunderstanding how
On 2012-07-12 18:01, Paul Wouters wrote:
> Unfortunately, the spec file from upstream did not use
> %config(noreplace). Someone enabled epel and ran "yum update" and the
> EPEL package was seen as an upgrade, and the noreplae bug in their
> package caused our package to blow away their configurati
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/06/12 19:42, Brian Wheeler wrote:
>
>
> On 06/01/2012 12:21 PM, Lennart Poettering wrote:
>> I think most of the noise in this flame thread is due to a
>> misunderstanding how modern memory management works and the
>> assumption that having an
On 07/12/2012 12:13 PM, Tom Callaway wrote:
On 07/12/2012 11:41 AM, Paul Wouters wrote:
On 07/12/2012 11:38 AM, Peter Jones wrote:
So, this makes me wonder. Is there a good reason rpm doesn't check the new
package and the old package for having the same file during an upgrade, and
simply use
On 07/12/2012 11:39 AM, Paul Wouters wrote:
> On 07/12/2012 11:20 AM, Tom Callaway wrote:
>
>> On 07/12/2012 11:01 AM, Paul Wouters wrote:
>>> I would like to prevent this from happening. But since this only happens
>>> when upgrading from a third-party 1.3 (which we don't ship) to a 1.4,
>>> eve
On 07/12/2012 11:41 AM, Paul Wouters wrote:
> On 07/12/2012 11:38 AM, Peter Jones wrote:
>
>> So, this makes me wonder. Is there a good reason rpm doesn't check the new
>> package and the old package for having the same file during an upgrade, and
>> simply use the flags on the incoming package i
Paul Wouters wrote:
> On 07/12/2012 11:38 AM, Peter Jones wrote:
> > So, this makes me wonder. Is there a good reason rpm doesn't check the
> > new package and the old package for having the same file during an
> > upgrade, and simply use the flags on the incoming package if they're
> > both prese
On Thu, Jul 12, 2012 at 5:01 PM, Paul Wouters wrote:
> Therefore neither Fedora nor EPEL
> ever shipped 1.3.x, and we started out with 1.4.x.
> So perhaps the best way would be to never allow the upgrade from 1.3.x
> to 1.4.x. Is there any kind of support for this?
I don't think so, and in gen
Hi,
In an ideal world, when pm is asked to update from a package with no
protections, to a package which has files marked as config or
config(noreplace), should not it apply the config attributes to the
package beeing replaced?
Or are there cases where it is not desirable?
--
Nicolas Mailhot
-
On 07/12/2012 11:38 AM, Peter Jones wrote:
> So, this makes me wonder. Is there a good reason rpm doesn't check the new
> package and the old package for having the same file during an upgrade, and
> simply use the flags on the incoming package if they're both present?
What if the incoming packa
On 07/12/2012 11:20 AM, Tom Callaway wrote:
> On 07/12/2012 11:01 AM, Paul Wouters wrote:
>> I would like to prevent this from happening. But since this only happens
>> when upgrading from a third-party 1.3 (which we don't ship) to a 1.4,
>> even if I used triggers to work around the config file
On 07/12/2012 11:20 AM, Tom Callaway wrote:
On 07/12/2012 11:01 AM, Paul Wouters wrote:
I would like to prevent this from happening. But since this only happens
when upgrading from a third-party 1.3 (which we don't ship) to a 1.4,
even if I used triggers to work around the config file issue, th
https://bugzilla.redhat.com/show_bug.cgi?id=839701
Bill Pemberton changed:
What|Removed |Added
Summary|Determine if words are |Review Request:
|rese
On 07/12/2012 11:01 AM, Paul Wouters wrote:
> I would like to prevent this from happening. But since this only happens
> when upgrading from a third-party 1.3 (which we don't ship) to a 1.4,
> even if I used triggers to work around the config file issue, the users
> would end up with a broken data
https://bugzilla.redhat.com/show_bug.cgi?id=839701
Bill Pemberton changed:
What|Removed |Added
CC||perl-devel@lists.fedoraproj
Once upon a time, Paul Wouters said:
> So perhaps the best way would be to never allow the upgrade from 1.3.x
> to 1.4.x. Is there any kind of support for this? Looking at the
> triggers, and the fact that the bad packages are already installed on
> those systems, I don't think any of the triggers
Hi,
One of the packages I maintain is shipped with a version of 1.4.x.
Upstream has a 1.3.x branch. The 1.3 branch is considered stable by
upstream, but my experience was that 1.4.x was actually more stable.
Additionally, migration from 1.3 to 1.4 was tedious and involved
manually changing sqlite/
Hi All,
I'm going on vacation for a week starting tomorrow, and I will *not*
be reading email, etc. during that time.
Regards,
Hans
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, Jul 11, 2012 at 04:38:19PM -0700, Adam Williamson wrote:
> Hey, folks.
>
> So I've had a feeling lately that the amount of karma being filed on
> updates has dropped - especially since proventesters was axed - but I
> don't have hard numbers. I've put it on my todo list to check into this
- Original Message -
> 2012/7/11 Matthias Runge :
> > On 07/11/2012 02:33 PM, Rakesh Pandit wrote:
> >>
> >> @devel
> >> May someone take care of this rename and review so that it happens
> >> before f18 branching ?
> >>
> >> Regards,
> >>
> > done
> >
> > https://bugzilla.redhat.com/show_b
2012/7/11 Matthias Runge :
> On 07/11/2012 02:33 PM, Rakesh Pandit wrote:
>>
>> @devel
>> May someone take care of this rename and review so that it happens
>> before f18 branching ?
>>
>> Regards,
>>
> done
>
> https://bugzilla.redhat.com/show_bug.cgi?id=839382
>
Regarding this issue, I need help
On Thu, 12 Jul 2012 08:34:46 +0200, Nicolas Mailhot wrote:
>
> > The Original post was simply letting everyone know that upstream
> > changed their license. If you have an issue with that, they would be
> > the ones to address it, not anyone here in Fedora land.
>
> Technically, if upstream bung
On Wed, 11 Jul 2012 15:31:43 -0700, Adam Williamson wrote:
> Look at it this way: it's the *project* which is in the exposed,
> dangerous position, not the contributors. You're arguing it almost the
> opposite way.
That must be a misunderstanding. Perhaps as a result of reading too quickly.
I've
On 07/12/2012 08:41 AM, yersinia wrote:
> For the folk here that don't follow fd. The author is a well know and
> respected security researcher.
There's a much more sane independent analysis of Fedora's position at
http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web
Andrew.
For the folk here that don't follow fd. The author is a well know and
respected security researcher.
Just for info.
Best regards
-- Forwarded message --
From: Georgi Guninski
Date: Thu, 12 Jul 2012 10:13:58 +0300
Subject: [Full-disclosure] The right to read, debuggers and buildin
30 matches
Mail list logo
