Hello all,
I was previously involved with the Drizzle community, however due to changes in
my current role at my $dayjob I am no longer much involved with the project.
The following packages were maintained as part of that project, and therefore I
am orphaning them. Some may need to be
…. are there any safeguards I
need to put in place as to not break them… or should I just rip out all the
SysV stuff and hope for the best?
Thanks.
---
derks
On Jan 13, 2012, at 3:31 PM, BJ Dierkes wrote:
Hello,
I have this bug open:
https://bugzilla.redhat.com/show_bug.cgi?id=781451
Hello,
I have this bug open:
https://bugzilla.redhat.com/show_bug.cgi?id=781451
And so, I am needing to remove my sysvinit scripts from gourmand in rawhide.
I've read the docs on SysVInit Scripts and Systemd but haven't found an answer…
How should I handle removing the init script? Should
Hello all,
I've pushed the latest protobuf-2.4.1 to Rawhide, which bumps libprotobuf.so.6
to libprotobuf.so.7. This appears to affect the following base packages:
* libcompizconfig
* mozc
* mumble
* protobuf-c
The primary maintainers of the above have been
Hello all,
I hope I am not the first to come across packaging issues for projects that use
GitHub as their upstream source download. For those not familiar, GitHub
dynamically generates downloads for all git 'tags'. So for example:
$ git tag -a -m 'Tagging 1.0.0' 1.0.0
This would create a
I've taken over that review, and will post an updated spec/srpm shortly.
---
derks
On Jan 17, 2011, at 5:12 PM, Rahul Sundaram wrote:
Hi
I only see a old review request at
https://bugzilla.redhat.com/show_bug.cgi?id=542436 and the spec file is not
available anymore. The latest
Adam,
First, thank you for joining as a Fedora contributor. You need to complete the
following before submitting for SCM module:
Find a sponsor. As this is your first package, you must have a 'proven
packager' sponsor you. See [1]
The sponsor must complete a formal review of your package.
On Dec 8, 2010, at 2:55 AM, Stanislav Ochotnicky wrote:
On 12/08/2010 04:25 AM, Jeff Spaleta wrote:
On Wed, Dec 8, 2010 at 2:39 AM, BJ Dierkes wdier...@5dollarwhitebox.org
wrote:
Hello all,
Just to be clear... PyPI has an implied one source requirement
embedded in its repository
On Dec 8, 2010, at 1:53 PM, Jeff Spaleta wrote:
On Wed, Dec 8, 2010 at 6:06 PM, BJ Dierkes wdier...@5dollarwhitebox.org
wrote:
That is exactly right.
reading over the instructions on the pypi page for cement.devtools
explicitly tells people to easy_install cement prior
php-pear most likely depends on php-devel as a courtesy, based on the fact that
PECL requires php-devel in order to build some/most/all (?) of its modules.
Meaning, when someone says:
# pecl install foo
Foo requires php-devel to build properly, and install the module. Without
php-devel as
Sorry, just saw your reply
On May 14, 2010, at 2:41 AM, Luke Macken wrote:
I'm seeing your POST requests in the logs, but some of them are not
hitting bodhi's save() method, which means it's not getting past the
identity layer. Does it work after you `rm ~/.fedora/.fedora_session`?
Also,
Hello all,
I've got two reviews that have been around for a bit... looking to do a review
or two in return for having someone review these:
libdrizzle: https://bugzilla.redhat.com/show_bug.cgi?id=578981
python-drizzle: https://bugzilla.redhat.com/show_bug.cgi?id=581344
Please note that I
Hello,
I am working with the Drizzle project [1], and have been focussing mostly on
packaging. I am beginning to submit review requests for libdrizzle,
python-drizzle, etc... the supporting pieces that are mature. However drizzle
itself is still under heavy development and is considered
On Mar 8, 2010, at 10:59 AM, Steve Traylen wrote:
It is true that the separate .spec files are maintained separately. What many
people try and do is maintain them as identical, at least at the start.
Have a look at:
http://fedoraproject.org/wiki/Packaging/DistTag#Conditionals
of course
On Feb 26, 2010, at 11:11 AM, Kevin Fenzi wrote:
On Wed, 24 Feb 2010 12:36:31 -0600
BJ Dierkes wdier...@5dollarwhitebox.org wrote:
Hello all,
I maintain Multi-Master Replication Manager for MySQL in both Fedora
and EPEL. With changes from 2.0.11 - 2.1.0 there was an
incompatible
On Feb 24, 2010, at 9:41 PM, Chen Lei wrote:
It's not problem to update mysql-mmm to the latest version for F13 and devel
soon.
For F11 F12 and EPEL5, you need write Scriptlet in the pre and check the
startlevel of mmmd_agent and
mmmd_mon, then you can adapt the startlevel mmmd_agent
Hello all,
I maintain Multi-Master Replication Manager for MySQL in both Fedora and EPEL.
With changes from 2.0.11 - 2.1.0 there was an incompatible change in that the
daemon scripts were renamed:
mmmd_agent - mmm_agentd
mmmd_mon - mmm_mond
Upgrades obviously break because the INIT scripts
17 matches
Mail list logo
