On Fri, Mar 01, 2013 at 11:20:24AM +0100, Michael Schwendt wrote:
I must admit that I've forgotten what review procedure had been used
in 2005. Only have found this odd thread:
RFE: dietlibc review
http://www.redhat.com/archives/fedora-extras-list/2005-May/msg00683.html
Who
On Sat, Sep 17, 2011 at 12:26:15AM +0200, Stepan Kasal wrote:
- halevt -- should be phased out; any volunteer that has read the
End-of-life page on wiki?
Manuel retired it. Thanks Manuel!
--
Pat
--
devel mailing list
devel@lists.fedoraproject.org
On Tue, Sep 06, 2011 at 04:26:30PM +0200, Nicola Soranzo wrote:
I'm following the procedure at:
http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
Does anyone know how to contact Štěpán Kasal (user kasal)? He is not
answering
e-mails at his listed address (I've
On Fri, Mar 18, 2011 at 09:27:42AM +0100, Stanislav Ochotnicky wrote:
I'll note that those libs are already in Fedora, but they need a new
maintainer. Who should probably work with you and other distributions
to clean up the spec files. We have some recent changes guidelines
(no need for
On Tue, Mar 15, 2011 at 12:42:19PM +, Richard Hughes wrote:
I'm planning to orphan the hal and hal-info packages in F15 and and
retire them in rawhide.
HAL has been dead upstream for 3 years now, and all development has
moved into udev, and the u* daemons like upower, udisks and urfkill.
On Wed, Sep 15, 2010 at 05:06:20PM +0100, Robert Spanton wrote:
So, would be acceptable to register requests for -static package
variants as tickets on bugzilla? Or is there a better way to try to
encourage people to generate these packages?
Providing static libraries for user needs like
On Sat, Aug 28, 2010 at 10:39:39AM +0200, Dan Horák wrote:
libmspack
I'm going to unorphan this one, because I use it as dependency it my
experimental package of the upcoming wxGTK 3.0. But per upstream web
pages there are other projects that use most likely embedded copies of
this library
On Sat, Aug 28, 2010 at 10:39:39AM +0200, Dan Horák wrote:
libmspack
I'm going to unorphan this one, because I use it as dependency it my
experimental package of the upcoming wxGTK 3.0. But per upstream web
pages there are other projects that use most likely embedded copies of
this library
On Tue, Aug 17, 2010 at 02:32:28AM -0400, Naveen Kumar wrote:
Hi,
Can we use .swf files to develop open source applications? Some of the
links, that maybe useful here:
The support for flash in free software exists, but is still not at the level
of proprietarysupport. There are many
On Fri, Jul 30, 2010 at 03:01:11PM +0200, Mathieu Bridon wrote:
First, I must say that Christian has usually not been very responsive to
emails I wrote him, but it seems he just is usually very busy, as when
he actually responded, he would respond several of my emails in a row.
I have the
On Tue, Jul 06, 2010 at 09:35:32AM -0700, Jesse Keating wrote:
The system is fairly open with regard to just about everything except
attitude. Currently it's mostly attitude that prevents openness.
The ACL system restrict changes to other people packages to provenpackagers.
And then the
On Mon, Jul 05, 2010 at 01:30:37PM -0700, Adam Williamson wrote:
This generally works out pretty well, and helps out with the problem of
having quite a small set of maintainers for an extremely large set of
packages. I was often in the situation where I happened to notice a
small issue with
On Tue, Jul 06, 2010 at 01:39:43PM +0100, Richard W.M. Jones wrote:
I think this is another problem with pkgdb or Fedora. Why is there a
maintainer (owner?) and co-maintainers, rather than just having all
co-maintainers be equal?
Because this ensures that there is a well defined person who
On Mon, Jul 05, 2010 at 12:30:19PM +0100, Mark Chappell wrote:
http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
It takes three weeks which can be frustrating, the initial can we
push this update to testing might count as the initial ticket
creation, dropping it down
On Fri, Jul 02, 2010 at 11:40:11AM +0200, Matěj Cepl wrote:
Dne 2.7.2010 11:34, Michael Schwendt napsal(a):
Of course there is. There ought to be prior communication about such plans
to upgrade a package. The primary package maintainer may have good reasons
for not upgrading the package.
On Fri, Jul 02, 2010 at 01:33:05PM +0200, Till Maas wrote:
I do not want to be asked for trivial changes to my packages that fix
bugs I neglected or rebuild it because of an update of a dependency. I
am happy for every work I do not have to do and sending extra mails for
such changes reduces
On Fri, Jul 02, 2010 at 02:23:43PM +0200, Peter Czanik wrote:
2010-07-02 03:18 keltezéssel, Kevin Kofler írta:
I think we need to get rid of the concept of ownership entirely, that'd
also
make orphaned or de-facto orphaned packages less of a problem. You see a
problem, you fix it.
On Fri, Jul 02, 2010 at 09:36:34PM +0800, Chen Lei wrote:
I think escalating to FESCo is only suitable for changes which are
controversial between different people, we should have another policy
to treat those non-responsive issues, maintainers should respond on
bugzilla report in time.
I
On Fri, Jul 02, 2010 at 07:15:54PM +0530, Rahul Sundaram wrote:
I had forgotten about this but since becoming provenpackager I have
helped out in simple rebuilds or even version bumps on occasions and
have gotten positive feedback.
You mean that you didn't only send a patch but you did
On Mon, Jun 14, 2010 at 01:17:18PM +0200, Adam Tkac wrote:
Hello,
As part of the libjpeg-turbo F14 feature
(https://fedoraproject.org/wiki/Features/libjpeg-turbo) I would like
to drop the libjpeg.a static library. No package in the Fedora uses it
so I don't see any reason for its existence.
On Fri, Jun 04, 2010 at 04:43:58AM +0200, Kevin Kofler wrote:
Chen Lei wrote:
I found the maintainer violates fedora package/naming guideline many
times, we need a people to persuade him to obey those guideline.
IMHO we need to unsponsor him and orphan his packages. There are way too
On Sun, May 09, 2010 at 10:17:39PM +0800, Chen Lei wrote:
Most of those applications are replaced, e.g. xmms2 for xmms, putty(svn)
for putty 0.60,
since it's already done by some other distributions, I think
it's quite safe to retire gtk 1.2 completely from fedora.
That's not a good
On Sun, May 09, 2010 at 10:16:45PM +0100, Adam Williamson wrote:
I don't agree with that, entirely. Think about it - Red Hat sells big
enterprise stuff. Mostly servers. Directly, PA and bleeding edge X stuff
isn't of huge immediate interest to RH. I mean, of course RH is going to
pay people
Hello,
I don't know how it happened, but I still was the package maintainer of
perl-Statistics-Descriptive
I orphaned it properly now, feel free to take it up.
It should be updated to the latest release.
--
Pat
--
devel mailing list
devel@lists.fedoraproject.org
On Sat, May 01, 2010 at 03:56:13PM +0200, Iain Arnell wrote:
On Sat, May 1, 2010 at 3:27 PM, Patrice Dumas pertu...@free.fr wrote:
Hello,
I don't know how it happened, but I still was the package maintainer of
perl-Statistics-Descriptive
I orphaned it properly now, feel free to take
Hello,
I won't, at least for now, maintain the packages I maintain in EPEL-5 in
EPEL-6. I have added a nobranch file in all of them. If you want to take up
the package, you can. It is still unclear to me how to practically ensure
that you become the EPEL-6 branch owner, instead of me, though.
On Tue, Apr 13, 2010 at 05:03:55PM -0400, Seth Vidal wrote:
Hi,
Hey, this pkg hasn't been built, even in rawhide, in a while, maybe you
should 1. check that out and 2. if the pkg is dead or unmaintained
consider retiring it.
The junction with bug information is also interesting. I think
On Wed, Mar 10, 2010 at 06:47:00AM -0500, Josh Boyer wrote:
We shouldn't be held hostage to various threats. We shouldn't be afraid to
try something because a vocal few are ranting against it.
I could, of course, be very wrong. However threatening to leave the project
if various things
On Sun, Feb 14, 2010 at 11:38:21AM -0500, Toshio Kuratomi wrote:
I went back and forth on this one but couldn't figure out how to put it in.
Perhaps, marked as optional and introduced by something like: If you want to
take a more active role in watching what your sponsoree does and correcting
On Sat, Feb 27, 2010 at 02:55:41PM +0100, Kevin Kofler wrote:
New packages which don't Obsolete existing packages or Provide existing
provided names cannot cause any of the above. (They may technically trigger
Special care should be given to the auto-generated Provides. I remember
a
On Fri, Feb 26, 2010 at 08:04:55AM -0600, Chris Adams wrote:
EPEL has run this way for a while, and it doesn't seem to be a problem.
EPEL is very different. Packages in EPEL have been tested in fedora and so
will very rarely need hotfixes aor regression fixes (except for security
fixes, which
On Fri, Feb 26, 2010 at 03:35:58PM +0100, Michael Schwendt wrote:
On Fri, 26 Feb 2010 14:07:05 +0100, Patrice wrote:
I may be remebering wrong, but an argument for bodhi against those who
wanted a simpler push mechanism (like wwhat was in the fedora extra days)
and argued that bodhi will
On Fri, Feb 26, 2010 at 08:39:19AM -0600, Chris Adams wrote:
Once upon a time, Patrice Dumas pertu...@free.fr said:
On Fri, Feb 26, 2010 at 08:04:55AM -0600, Chris Adams wrote:
EPEL has run this way for a while, and it doesn't seem to be a problem.
EPEL is very different. Packages
On Fri, Feb 26, 2010 at 05:07:24PM +, Jesse Keating wrote:
It'll require some enhancements to how bodhi is used for people
consuming testing updates, and it may require a more active role on part
of the maintainer to seek out somebody to at least give the update a
smoke test.
For many
On Fri, Feb 26, 2010 at 07:46:58AM -0800, Jesse Keating wrote:
On Fri, 2010-02-26 at 16:23 +0100, Patrice Dumas wrote:
Because EPEL has to be very stable, so additional time spent in testing is
even better, for example for reasons you highlight below. I never said
that packages should
On Fri, Feb 26, 2010 at 04:50:20PM -0500, Bill Nottingham wrote:
Patrice Dumas (pertu...@free.fr) said:
Bringinig down productivity of good packagers for a few bad ones, is,
in my opinion, not a good move.
Fedora doesn't exist for the productivity of packagers. It exists
On Fri, Feb 26, 2010 at 05:27:59PM -0500, Bill Nottingham wrote:
Regressions happen whatever policies are done. Imagine a specialized
package that hasn't any tester besides the maintainer (though it
has users), this was the case for most of the packages I maintained
in Fedora. A user
On Wed, Feb 17, 2010 at 03:04:00AM -0800, Roland McGrath wrote:
Is it ok to backport changes to F-12 for fixed packages in F-13 for
this DSO feature?
The changes to a package's linking lines that you make for this issue are
cleaning up sloppy practice to what was always the right thing to
On Tue, Feb 16, 2010 at 05:03:24PM +0100, Enrico Scholz wrote:
Gerd Hoffmann kra...@redhat.com writes:
[r...@localhost ~]# pkg-config --libs gtk+-2.0
-pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0
-lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype
On Sat, Feb 13, 2010 at 02:08:36PM -0500, Toshio Kuratomi wrote:
packager group. We want to encourage more sponsors to take on people that are
not yet good packagers but have the potential to grow into good packagers with
a little mentoring.
Updated policy drafts are here:
On Sun, Feb 14, 2010 at 12:20:08PM +0100, Patrice Dumas wrote:
On Sat, Feb 13, 2010 at 02:08:36PM -0500, Toshio Kuratomi wrote:
packager group. We want to encourage more sponsors to take on people that
are
not yet good packagers but have the potential to grow into good packagers
On Fri, Feb 12, 2010 at 02:59:37PM -0600, Eric Sandeen wrote:
I've finally been sufficiently pestered to fix this ;)
Is anybody using any of these static libs from e2fsprogs?
-%{_libdir}/libe2p.a
-%{_libdir}/libext2fs.a
-%{_libdir}/libcom_err.a
-%{_libdir}/libss.a
I'm inclined to just
On Mon, Jan 25, 2010 at 03:17:05PM +0100, Lubomir Rintel wrote:
Unfortunately, I've got difficulties while releasing ownership (
https://fedorahosted.org/packagedb/ticket/173 ).
I've seen that once too; I believe it's supposed to be a feature that
reassigns the package to another
43 matches
Mail list logo
