Orphaned Packages
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 deprecated (or obsoleted), but I am giving the option for others to pick these up easily being that they will be auto-deprecated before next release. FEDORA: - haildb - libdrizzle - python-drizzle EPEL: - haildb - libdrizzle - python-drizzle - protobuf --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Removing SysV Init Scripts
Sorry, I didn't mean to start a heated thread on SysV vs. Systemd or anything. Unfortunately my question wasn't really answered. I *am* removing SysV support from gearmand … and have already implemented Systemd scripts. My question is… for existing users still on SysV in Fedora 17 …. 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 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 I just assume that users are moved over to systemd? Do I need to call 'chkconfig --del gearmand'? --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Removing SysV Init Scripts
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 I just assume that users are moved over to systemd? Do I need to call 'chkconfig --del gearmand'? --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Heads up: protobuf .so version bump in Rawhide
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 BCC'd. Thanks. --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
GitHub Hosted upstream 'Source0'
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 tag of '1.0.0' in git. On GitHub, this tag would be 'downloadable' via a dynamic app such as: https://github.com/derks/myapp/zipball/1.0.0 This is the upstream URL that a lot of GitHub users are providing rather than a direct download link. Unfortunately the above is not usable by RPM because rpmbuild expects the URL to end with the file. If I were to use the above in my spec, I would get an error saying something to the affect of 'unknown source file 1.0.0'. Additionally, the tarbal that is created looks like: myapp-1.0.0-XXX.tar.gz Where XXX is the last bit of the git commit hash id... which cause yet another pain in that... you need to update this commit revision every time you update the spec... and it just makes things a bit less fluid. I'm wondering how other people have resolved these issues for projects using GitHub as the upstream Source0 download provider. Finally, debian has a web app to resolve these issues at: http://githubredir.debian.net/ What would be the thoughts of using that to produce more sane/traditional tarbals of upstream GitHub source? --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anyone packaging python-cloudfiles?
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 development version of Deja-dup (default backup software in GNOME using duplicity) requires it to backup to S3 or Rackspace clouds. If anyone is packaging it, I can help review it. Let me know Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a new scm module for a new package
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. Anyone can add comments to your review, and do an 'unofficial review' to help you along. However the review is not formally complete until your sponsor says so, and adds the 'fedora-review +' flag. Currently the review has not even started, otherwise the 'fedora-review' flag would be set as '?' (once a sponsor picks up your review). References: [1] http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group --- derks On Jan 6, 2011, at 1:19 PM, Adam Litke wrote: Hello all. I am a new Fedora packager and am following the process to create a new package. The associated bugzilla is 638647 [1]. At this point I am trying to request a new SCM module for my package and have followed the documented steps [2] but nothing has happened in 24 hours. Is this an automated process or does it require human intervention. Does anyone know if there is a specific problem with the state of my bugzilla bug that might be preventing the request from being picked up? Thanks for your help! [1] https://bugzilla.redhat.com/show_bug.cgi?id=638647 [2] http://fedoraproject.org/wiki/Package_SCM_admin_requests -- Thanks, Adam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python Packages + Multiple Sources
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 structure and you have optimized your upstream project release structure to meet PyPI's implied requirement. Question does PyPI handle dependency tracking? If I easy_install cement.devtools does cement get installed automagically? Yes, setup function from python setuptools has named argument 'install_requires' that causes dependencies to be pulled in during install time. Assuming cement.devtools has install_requires = ['cement'] this will work as you'd expect That is exactly right. --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python Packages + Multiple Sources
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 to easy_install'ing cement.devtools, so I wanted clarification as to whether that was necessasry. I've updated this to be more accurate, thank you. --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: php-pear dependencies install httpd
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 a dependency of php-pear, users would be confronted to sometimes obscure pecl install failures. --- derks On Dec 1, 2010, at 6:45 AM, Martín Marqués wrote: I have my laptop with php-cli and php-pear installed, and I was to do an upgrade and found that yum wanted to install httpd package to my surprise. Looking in detail, I found that php-pear needed php-devel, which needs php, which needs httpd. -- Ejecutando prueba de transacción --- Paquete php-pear.noarch 1:1.9.1-5.fc13 definido para ser actualizado -- Procesando dependencias: php-devel para el paquete: 1:php-pear-1.9.1-5.fc13.noarch -- Ejecutando prueba de transacción --- Paquete php-devel.x86_64 0:5.3.3-1.fc13 definido para ser instalado -- Procesando dependencias: php = 5.3.3-1.fc13 para el paquete: php-devel-5.3.3-1.fc13.x86_64 -- Ejecutando prueba de transacción --- Paquete php.x86_64 0:5.3.3-1.fc13 definido para ser instalado -- Procesando dependencias: httpd-mmn = 20051115 para el paquete: php-5.3.3-1.fc13.x86_64 -- Procesando dependencias: httpd para el paquete: php-5.3.3-1.fc13.x86_64 -- Ejecutando prueba de transacción --- Paquete httpd.x86_64 0:2.2.17-1.fc13.1 definido para ser instalado -- Procesando dependencias: httpd-tools = 2.2.17-1.fc13.1 para el paquete: httpd-2.2.17-1.fc13.1.x86_64 -- Procesando dependencias: apr-util-ldap para el paquete: httpd-2.2.17-1.fc13.1.x86_64 -- Ejecutando prueba de transacción --- Paquete apr-util-ldap.x86_64 0:1.3.10-1.fc13 definido para ser instalado --- Paquete httpd-tools.x86_64 0:2.2.17-1.fc13.1 definido para ser instalado Any ideas why these dependencies appeared? Basically, whi does php-pear need php-devel. -- Martín Marqués select 'martin.marques' || '@' || 'gmail.com' DBA, Programador, Administrador -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Issues with bodhi (No JSON object could be decoded)
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, does passing -v to bodhi show anything useful?
Removing the session doesn't work.
$ bodhi -n --type bug mysql-mmm-2.2.1-1.fc12 --username derks -v
proxyclient.__init__:entered
proxyclient.__init__:exited
Creating a new update for mysql-mmm-2.2.1-1.fc12
No session cached for derks
No session cached for derks
Password for derks:
Creating a new update for mysql-mmm-2.2.1-1.fc12
No session cached for derks
proxyclient.send_request: entered
Creating request https://admin.fedoraproject.org/updates/save
Headers: ['User-agent: Fedora Bodhi Client/0.5.1', 'Accept: application/json']
Data:
close_bugs=Trueedited=suggest_reboot=Falseunstable_karma=-3password=xxxstable_karma=3builds=mysql-mmm-2.2.1-1.fc12autokarma=Trueinheritance=Falsenotes=request=testingbugs=type_=buglogin=Loginuser_name=derks
ServerError(https://admin.fedoraproject.org/updates/save, 200, Error returned
from simplejson while processing https://admin.fedoraproject.org/updates/save:
No JSON object could be decoded)
Traceback (most recent call last):
File /usr/bin/bodhi, line 178, in main
data = bodhi.save(**extra_args)
File /usr/lib/python2.6/site-packages/fedora/client/bodhi.py, line 111, in
save
'bugs': bugs,
File /usr/lib/python2.6/site-packages/fedora/client/baseclient.py, line
316, in send_request
req_params = req_params, auth_params = auth_params)
File /usr/lib/python2.6/site-packages/fedora/client/proxyclient.py, line
313, in send_request
{'url': url, 'err': str(e)})
ServerError: ServerError(https://admin.fedoraproject.org/updates/save, 200,
Error returned from simplejson while processing
https://admin.fedoraproject.org/updates/save: No JSON object could be decoded)
I added a print statement to
/usr/lib/python2.6/site-packages/fedora/client/proxyclient.py and got back HTML
which looks to be the web version of the new update page as the title is:
titleNew Update Form/title
---
derks
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Review Swap: Your two for my libdrizzle/python-drizzle
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 can't sponsor. --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Packages where upstream sources are alpha/beta
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 alpha/almost beta. I've read the guidelines on versions [2] which mentions alpha/beta/cvs releases but doesn't really go into any detail. In short, my question is if there are any restrictions around submitting packages that are pre-release and if so can you provide any information that is available. [1] http://drizzle.org, http://launchpad.net/drizzle [2] https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Version Thanks. p.s. If anyone wants to review libdrizzle, it's still waiting: https://bugzilla.redhat.com/show_bug.cgi?id=578981 --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Managing spec files
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 with time with different update policies it will happen that say EPEL and rawhide .specs diverge. Maintaining a single spec with disttag conditionals is great, and makes the world a lot easier *if* you are maintaining the same source version of the package across all distros. Once you split source versions (as Steve said generally with rawhide)... its not really practical to maintain a single spec and you end up with multiple buildroots/specs. --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Incompatible upgrade - Is this workaround ok? (mysql-mmm)
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 change in that the daemon scripts were renamed:
mmmd_agent - mmm_agentd
mmmd_mon - mmm_mond
Upgrades obviously break because the INIT scripts and configuration
files reference the path to the files. Would a sufficient
work-around be a symlink to the old path, or would that not be kosher
for any reason?
Thank you for your feedback.
Well, I would suggest if you can get it setup so it continues to work
as expected on upgrade it should be fine. If thats a symlink or
whatever it should be ok.
Perhaps make and test a version, then post the spec diff for
comment/feedback if you like?
kevin
I have a working upgrade from mysql-mmm-2.0.x - mysql-mmm-2.1. I verified
that all expected changes happen, and that the running processes are gracefully
condrestart'd.
The changes are pretty straight forward. Because this is the first release of
mysql-mmm = 2.1 I am touching a file at
'%{_datadir}/mysql-mmm/.pre-2.1.0-upgrade-check' in the install. From %pre, if
this file does *not* exist then the current install is 2.1 (meaning
modifications need to be done for 2.1 compatibility). I then touch
'%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods' (in %pre)
allowing me to verify that modifications are needed in %post.
The modifications are simple sed changes for pid/status file and sbin daemon
paths. I suppose I'm looking for another set of eyes to point out anything
that is not obvious to me. The following are the [snipped] spec changes:
# --
%install
# … snipped
# Specific for upgrading from 2.0.x - 2.1
touch %{buildroot}%{_datadir}/mysql-mmm/.pre-2.1.0-upgrade-check-do-not-delete
%pre
# This is to facilitate the upgradability of 2.0.x - 2.1
DO_MOD_CHECK=%{_datadir}/mysql-mmm/.pre-2.1.0-upgrade-check-do-not-delete
DO_MOD_VERIFY=%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods
rm -f $DO_MOD_VERIFY 2/dev/null
if [ ! -f $DO_MOD_CHECK ]; then
# the 'check' file does *not* exist (only installed as of 2.1.0)
# modifications are necessary.
touch $DO_MOD_VERIFY
# copy paths for new configs (if replaced on upgrade)
cp -a %{_localstatedir}/run/mysql-mmm/mmmd_mon.pid \
%{_localstatedir}/run/mysql-mmm/mmm_mond.pid 2/dev/null ||:
cp -a %{_localstatedir}/lib/mysql-mmm/mmmd_mon.status \
%{_localstatedir}/lib/mysql-mmm/mmm_mond.status 2/dev/null ||:
cp -a %{_localstatedir}/run/mysql-mmm/mmmd_agent.pid \
%{_localstatedir}/run/mysql-mmm/mmm_agentd.pid 2/dev/null ||:
fi
%post
# This is to facilitate the upgradability of 2.0.x - 2.1
DO_MOD_VERIFY=%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods
if [ -f $DO_MOD_VERIFY ]; then
# system was upgraded from 2.1, need to modify config files/paths
if [ -f %{_sysconfdir}/mysql-mmm/mmm_mon.conf ]; then
cp -a %{_sysconfdir}/mysql-mmm/mmm_mon.conf
%{_sysconfdir}/mysql-mmm/mmm_mon.conf-pre2.1
sed -i
s|/var/run/mysql-mmm/mmmd_mon.pid|/var/run/mysql-mmm/mmm_mond.pid|g \
%{_sysconfdir}/mysql-mmm/mmm_mon.conf
sed -i
s|/var/lib/mysql-mmm/mmmd_mon.status|/var/lib/mysql-mmm/mmm_mond.status|g \
%{_sysconfdir}/mysql-mmm/mmm_mon.conf
fi
if [ -f %{_sysconfdir}/mysql-mmm/mmm_common.conf ]; then
cp -a %{_sysconfdir}/mysql-mmm/mmm_common.conf
%{_sysconfdir}/mysql-mmm/mmm_common.conf-pre2.1
sed -i
s|/var/run/mysql-mmm/mmmd_agent.pid|/var/run/mysql-mmm/mmm_agentd.pid|g \
%{_sysconfdir}/mysql-mmm/mmm_common.conf
fi
fi
%post agent
# … snipped
# This is to facilitate the upgradability of 2.0.x - 2.1
DO_MOD_VERIFY=%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods
if [ -f $DO_MOD_VERIFY ]; then
# remove old files
rm -f %{_localstatedir}/run/mysql-mmm/mmmd_agent.pid 2/dev/null ||:
fi
%post monitor
# … snipped
# This is to facilitate the upgradability of 2.0.x - 2.1
DO_MOD_VERIFY=%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods
if [ -f $DO_MOD_VERIFY ]; then
# remove old files
rm -f %{_localstatedir}/run/mysql-mmm/mmmd_mon.pid 2/dev/null ||:
rm -f %{_localstatedir}/lib/mysql-mmm/mmmd_mon.status 2/dev/null ||:
fi
# --
Thanks.
---
derks
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Incompatible upgrade - Is this workaround ok? (mysql-mmm)
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 based on mmm_agentd
and mmmd_mon based on
mmm_mond. There may be some more hack to do for configuration files.
I think symlink isn't a good idea.
Thank you. To clarify, mmmd_{agent,mon} are the names of the scripts in
/usr/sbin and not the name of the init scripts (mysql-mmm-agent,
mysql-mmm-monitor). However, the sbin scripts are referenced inside the init
scripts.
I suppose an alternative to creating a symlink in /usr/sbin would be to sed the
init/config files to reference the new paths in %post. My issue with that
however is that I only want to make such changes if the previously installed
version is 2.1. Is there a fedora proper way of determining the version of a
package before the upgrade and only performing upgrade actions in that
condition only. Maybe something like:
%pre
# determine current version, /tmp/somewhere
%post
# read previous version from /tmp/somewhere, if version 2.1 then sed up
init/config files for new paths
Just a thought.. I've done something like this before, but not under
Fedora/EPEL.
Additionally, an option would be to rename the new sbin scripts to have the old
name... but the old name is not standard, and it would be right to follow
upstream where all their documentation references the new paths.
Thanks.
---
derks
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Incompatible upgrade - Is this workaround ok? (mysql-mmm)
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 and configuration files reference the path to the files. Would a sufficient work-around be a symlink to the old path, or would that not be kosher for any reason? Thank you for your feedback. --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
