Bug 522988 - Review Request: afraid-dyndns - A dynamic DNS client for the free service afraid.org
Summary: Review Request: afraid-dyndns - A dynamic DNS client for the free service afr...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jan Klepek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-13 02:06 UTC by Erick Calder
Modified: 2009-11-16 07:29 UTC (History)
7 users (show)

Fixed In Version: 1.1-1.fc11
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-11-13 02:36:28 UTC
Type: ---
Embargoed:
jan.klepek: fedora-review+
kevin: fedora-cvs+


Attachments (Terms of Use)

Description Erick Calder 2009-09-13 02:06:55 UTC
Spec URL: ftp://arix.com/rpmz/specs/dyndns.spec
SRPM URL: ftp://arix.com/rpmz/src/dyndns-1.0-1.fc11.src.rpm
Description: This utility implements a client for the free afraid.org dynamic DNS
service. A cron job is set up to check whether the external IP address
has changed, and when it does, connects to afraid.org and updates the
DNS entries of all the domains of the given account.

Comment 1 Martin Gieseking 2009-09-14 07:45:52 UTC
$ rpmlint dyndns-1.0-1.fc11.src.rpm 
dyndns.src: W: invalid-license GPL
error checking signature of dyndns-1.0-1.fc11.src.rpm
dyndns.src: E: no-cleaning-of-buildroot %install
dyndns.src: E: no-buildroot-tag
1 packages and 0 specfiles checked; 2 errors, 1 warnings.

- the license tag must be GPLv2+

- add a proper BuildRoot tag (https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag)

- if you don't want to support older Fedora/EPEL versions, E: no-cleaning-of-buildroot %install can be ignored (https://fedoraproject.org/wiki/Packaging:Guidelines#Prepping_BuildRoot_For_.25install)

- add your full name to the %changelog entry and put the email address in angle brackets (https://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs)

This seems to be your first package submission to Fedora (I can't find you in the Fedora Account System). Thus you need a sponsor: https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group

Comment 2 Martin Gieseking 2009-09-14 07:47:57 UTC
(In reply to comment #1)
> This seems to be your first package submission to Fedora (I can't find you in
> the Fedora Account System). Thus you need a sponsor

Sorry, I just saw that you've already added FE-NEEDSPONSOR.

Comment 3 Erick Calder 2009-09-14 19:13:29 UTC
> $ rpmlint dyndns-1.0-1.fc11.src.rpm 

ugh.  I should have run it :)

> - the license tag must be GPLv2+

fixed

> - add a proper BuildRoot tag

I actually had removed this tag because of the text below (found at the link you indicate):

"The RPM in Fedora 10 defines a default buildroot so in Fedora 10 and above it is no longer necessary to define a buildroot tag. Fedora releases older than 10 and EPEL releases older than or equal to 5 still need to have the tag."

but I guess I should support older versions, so I've added it back

> no-cleaning-of-buildroot %install can be ignored

added back

> - add your full name to the %changelog entry

done

[rpm@janus ~]$ rpmlint /var/ftp/rpmz/src/dyndns-1.0-1.fc11.src.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

:)

Comment 4 Christoph Wickert 2009-09-14 21:19:09 UTC
I think the URL tag is not correct because I can't find anything about the program on the site.

Another problem is the package and the binaries name:
https://fedoraproject.org/wiki/Packaging_tricks#Use_of_common_namespace

Comment 5 Martin Gieseking 2009-09-14 22:15:05 UTC
rpmlint is also unhappy with the binary package: :)

rpmlint /var/lib/mock/fedora-11-x86_64/result/*.rpm
dyndns.x86_64: E: no-binary
dyndns.x86_64: E: zero-length /var/cache/dyndns
dyndns-debuginfo.x86_64: E: empty-debuginfo-package
3 packages and 0 specfiles checked; 3 errors, 0 warnings.

Adding BuildArch: noarch will remove the first and third error. Concerning the zero-length file I'm not sure. Is it really necessary to package the empty file /var/cache/dyndns? 

Erick, you should also increase the release tag every time you make changes to the spec file (so the current release is 2). 
Finally two minor notes: your email address given in the changelog seems to lack at least the TLD. Also, the list items in each changeset should start with a hyphen (even if there's only one entry), e.g:

* Sat Sep 12 2009 Erick Calder <rpm> - 1.0-1
- Initial build

Comment 6 Christoph Wickert 2009-09-14 22:58:02 UTC
(In reply to comment #5)
> Is it really necessary to package the empty file
> /var/cache/dyndns?

Should be included, but ghosted, see: http://www.rpm.org/max-rpm-snapshot/s1-rpm-inside-files-list-directives.html#S3-RPM-INSIDE-FLIST-GHOST-DIRECTIVE

Comment 7 Erick Calder 2009-09-15 03:26:11 UTC
> I think the URL tag is not correct because I can't find anything about the
> program on the site.

nah.  url was correct, I just hadn't updated the website to include info on this utility (I'm the packager and author)

> Another problem is the package and the binaries name:
> https://fedoraproject.org/wiki/Packaging_tricks#Use_of_common_namespace 

I read the link but don't see anything wrong with the name.  what are you suggesting?

Comment 8 Erick Calder 2009-09-15 03:32:46 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Is it really necessary to package the empty file
> > /var/cache/dyndns?
> 
> Should be included, but ghosted, see:

well... what I don't like about %ghost is that when I do rpm -ql I want to see my cache file.  that file is useful since it contains the external IP address of my system and unless I can have it included in the listing, I won't necessarily know where it is

Comment 9 Erick Calder 2009-09-15 03:47:44 UTC
(In reply to comment #5)
> rpmlint is also unhappy with the binary package: :)

gone as per BuildArch

> Adding BuildArch: noarch will remove the first and third error

done

> Concerning the zero-length file I'm not sure. Is it really necessary
> to package the empty file /var/cache/dyndns?

I've ghosted it as per Christoph's suggestion, with a half-hearted objection.

> Erick, you should also increase the release tag every time you make changes to
> the spec file (so the current release is 2). 

done

> Finally two minor notes: your email address given in the changelog seems to
> lack at least the TLD. Also, the list items in each changeset should start 
> with a hyphen (even if there's only one entry)

done

Comment 10 Martin Gieseking 2009-09-15 07:12:34 UTC
(In reply to comment #7)
> nah.  url was correct, I just hadn't updated the website to include info on
> this utility (I'm the packager and author)

Maybe you can also fix the license ambiguity between website and tarball. According to the file header comments, the package is licensed under GPLv2+ while the website mentions GPLv3.

Comment 11 Erick Calder 2009-09-15 07:34:20 UTC
(In reply to comment #10)
> Maybe you can also fix the license ambiguity between website and tarball.

done

Comment 12 Martin Gieseking 2009-09-15 07:55:59 UTC
Err, the file header of dyndns still mentions GPLv2+:

#   This program is free software; you can redistribute it and/or modify
#   it under the terms of the GNU General Public License as published by
#   the Free Software Foundation; either version 2 of the License, or
#   (at your option) any later version.

You should update this too. And if you leave the addition "or (at your option) any later version" the license tag is GPLv3+.

Comment 13 Erick Calder 2009-09-15 08:13:49 UTC
(In reply to comment #12)
> Err, the file header of dyndns still mentions GPLv2+:

eek.  ok, fixed.

Comment 14 Christoph Wickert 2009-09-15 08:18:43 UTC
(In reply to comment #7)
> nah.  url was correct, I just hadn't updated the website to include info on
> this utility (I'm the packager and author)

I know. ;)

> I read the link but don't see anything wrong with the name.  what are you
> suggesting?  

Give this app a proper name. "dyndns" is a protocol or a generic term, but not a name. We don't have "email", "smpt", "pop" or "parser" in Fedora, because if we allowed names like these, we would have collisions pretty soon.

"dyndns" also sounds like a claim that this is the best or the official dyndns client, although it only handles afraid.org but no other dyndns services.

You are the author, you can name this program whatever you like, but please don't call it "dyndns".

(In reply to comment #8)
> well... what I don't like about %ghost is that when I do rpm -ql I want to see
> my cache file.  that file is useful since it contains the external IP address
> of my system and unless I can have it included in the listing, I won't
> necessarily know where it is  

True, but the file should not be included as a normal file because this will confuse rpm -V.

BTW: /var/cache/dyndns shouldn't be a file but a directory containing that file. Each app using /var/cache/ is supposed to have a directory of it's own. Reading the definitions in
http://www.pathname.com/fhs/pub/fhs-2.3.html#VARCACHEAPPLICATIONCACHEDATA
I'm not even sure if /var/cache/ is the proper place, but I have no better suggestion ether.

Comment 15 Susi Lehtola 2009-09-15 09:06:29 UTC
(In reply to comment #14)
> (In reply to comment #7)
> > I read the link but don't see anything wrong with the name.  what are you
> > suggesting?  
> 
> Give this app a proper name. "dyndns" is a protocol or a generic term, but not
> a name. We don't have "email", "smpt", "pop" or "parser" in Fedora, because if
> we allowed names like these, we would have collisions pretty soon.
> 
> "dyndns" also sounds like a claim that this is the best or the official dyndns
> client, although it only handles afraid.org but no other dyndns services.
> 
> You are the author, you can name this program whatever you like, but please
> don't call it "dyndns".

Yes, it is rather confusing, especially since there is already http://www.dyndns.com/ who provide dynamical DNS services (their client is called ddclient).

Comment 16 Erick Calder 2009-09-15 23:06:56 UTC
(In reply to comment #14)
> "dyndns" also sounds like a claim that this is the best or the official dyndns
> client, although it only handles afraid.org but no other dyndns services.

so everyone ok if I call it "afraid-dyndns"?

Comment 17 Erick Calder 2009-09-15 23:10:43 UTC
(In reply to comment #14)
> Reading the definitions in
> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARCACHEAPPLICATIONCACHEDATA
> I'm not even sure if /var/cache/ is the proper place, but I have no better
> suggestion ether.  

from reading the link above I'm convinced this is the right place for it

> /var/cache/dyndns shouldn't be a file but a directory containing that
> file. Each app using /var/cache/ is supposed to have a directory of it's own.

there's no mention in that document that leads me to believe I should create a directory... though, if I did, would you have me ghost it?

Comment 18 Christoph Wickert 2009-09-16 00:53:49 UTC
(In reply to comment #17)
> from reading the link above I'm convinced this is the right place for it

Ok, fine with me.

> there's no mention in that document that leads me to believe I should create a
> directory... though, if I did, would you have me ghost it?  

Nope, include the dir and ghost the file. Then people might get a clue that there is something inside, e.g.

%dir %{_localstatedir}/cache/afraid-dyndns
%ghost %{_localstatedir}/cache/afraid-dyndns/afraid

I wouldn't say that the separate dir is a must for you as upstream developer, it's just a recommendation for packaging in Fedora similar to libexecdir:
"%{_libexecdir}. Packagers are highly encouraged to store libexecdir files in a package-specific subdirectory of %{_libexecdir}, such as %{_libexecdir}/%{name}."
see https://fedoraproject.org/wiki/Packaging/Guidelines#Libexecdir

This may also help with SELinux issues, I know this from bad experience. :(
https://bugzilla.redhat.com/show_bug.cgi?id=518068#c11

BTW: Does everything work with SELinux enabled?

Comment 19 Erick Calder 2009-09-16 08:15:57 UTC
(In reply to comment #18)
> I wouldn't say that the separate dir is a must for you as upstream developer,
> it's just a recommendation for packaging in Fedora

done.  new srpm at: ftp://arix.com/rpmz/src/afraid-dyndns-1.0-1.fc11.src.rpm

> BTW: Does everything work with SELinux enabled?  

no idea - I have it disabled in my box

Comment 20 Erick Calder 2009-09-18 08:05:32 UTC
I got sponsored today - yea! see:

    https://bugzilla.redhat.com/show_bug.cgi?id=522935

so what's next with afraid-dyndns?

Comment 21 Martin Gieseking 2009-09-18 09:53:44 UTC
(In reply to comment #20)
> so what's next with afraid-dyndns?  

Wait for somebody doing the full review. :)

Comment 22 Jan Klepek 2009-09-26 09:35:34 UTC
1] use install -p to keep timestamps
https://fedoraproject.org/wiki/Packaging/Guidelines#Timestamps

2] cron, doesn't work
from cron log: (CRON) bad username (/etc/cron.d/afraid-dyndns)

Comment 23 Erick Calder 2009-09-27 09:34:47 UTC
(In reply to comment #22)
> 1] use install -p to keep timestamps
> https://fedoraproject.org/wiki/Packaging/Guidelines#Timestamps

fixed.  there are a couple of files that needed -C which is mutually exclusive with -p so I left those as is

> 2] cron, doesn't work
> from cron log: (CRON) bad username (/etc/cron.d/afraid-dyndns)  

yikes!  I don't know how that got passed my testing (some testing I did).  I've fixed it, it's all ready to be looked at again (available at the same place but release -2)

Comment 24 Jan Klepek 2009-09-28 06:57:10 UTC
*md5sum of source/srpm ok
*rpmlint clean
*license ok
*directory ownership ok
*naming ok
*packaging guidelines ok
*working ok
*legible spec
*noarch package
*koji builds:
F-12: http://koji.fedoraproject.org/koji/taskinfo?taskID=1712414 - OK
F-11: http://koji.fedoraproject.org/koji/taskinfo?taskID=1712416 - OK
*utf-8 filenames - ok

conclusion: approved

Comment 25 Erick Calder 2009-09-28 22:52:23 UTC
New Package CVS Request
=======================
Package Name: afraid-dyndns
Short Description: A dynamic DNS client for the free service afraid.org
Owners: e
Branches: F-10 F-11 F-12 EL-5
InitialCC: jan.klepek

Comment 26 Kevin Fenzi 2009-09-29 20:21:20 UTC
Please use fedora account system names in cvs requests. 
File a new request and reset the flag to ? when you are ready.

Comment 27 Erick Calder 2009-09-30 06:42:05 UTC
New Package CVS Request
=======================
Package Name: afraid-dyndns
Short Description: A dynamic DNS client for the free service afraid.org
Owners: ekkis
Branches: F-10 F-11 F-12 EL-5

I don't know how to find out Jan's FAS account name (actually I don't really know what the InitialCC is for) so I've just removed him.

Comment 28 Mamoru TASAKA 2009-09-30 07:32:48 UTC
The FAS account of Jan is hpejakle and is sponsored by lkundrak.
By the way usually you don't have to add the reviewer to CC list.

Comment 29 Kevin Fenzi 2009-09-30 23:49:04 UTC
cvs done.

Comment 30 Erick Calder 2009-10-01 23:55:03 UTC
(In reply to comment #22)
> 1] use install -p to keep timestamps
> https://fedoraproject.org/wiki/Packaging/Guidelines#Timestamps

well... the -C for install broke the F10 install... do you figure I can just not use it?  how are these sorts of things handled? because I wouldn't want to take the option off and break it for the other releases

Comment 31 Erick Calder 2009-10-03 07:06:03 UTC
ok, I guess it doesn't really matter about the -C because the install script isn't going to run when the package gets installed anyway.  so I'm going to just yank it.  objections anyone?

Comment 32 Erick Calder 2009-10-03 07:50:31 UTC
question: I've updated the SRPM with a new (fixed) copy of the Makefile... now how do I get that new package into the system?  originally I did:

/home/rpm/cvs # ./common/cvs-import.sh -b F-10 ~/SRPMS/afraid-dyndns-1.0-2.fc11.src.rpm

but now that the package has been imported, it can't be imported again... so if I've made a change, how do I tell it to use the new 1.0-2.fc11 source package?

Comment 33 Itamar Reis Peixoto 2009-10-03 07:58:20 UTC
when you run cvs-import.sh it's tag the cvs, then if you need to change again you will need to bump release and run cvs-import.sh again

I think you should not change Makefile because it's overwritten by configure.

Comment 34 Christoph Wickert 2009-10-03 09:49:37 UTC
(In reply to comment #32)
> but now that the package has been imported, it can't be imported again... so if
> I've made a change, how do I tell it to use the new 1.0-2.fc11 source package?

Just commit the spec and the files you changed from your local cvs.

make clog (this will create a file called "clog" with your latest changelog entry)
cvs commit -F clog (clog will be used as commit message)
make tag build

As ling as a particular version of a package hasn't sucessfully been build, you can also re-tag something with

TAG_OPTS=-F make tag

But please be careful with this, never overwrite a package that has already been built.

Finally, if you really need to bump the release on an older branch, make sure you don't break the upgrade path, this means the F11 package must not be higher than the F12 one. So you'd use -1.fc11.1 instead of -2.fc11. See 
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches
for more info.

Comment 35 Erick Calder 2009-10-03 18:05:20 UTC
ok, so just so it's clear in my head... if a change if only so an older branch builds, I should just add a .1 to the %{dist} e.g. afraid-dyndns-1.0-2.fc11.src.rpm turns into afraid-dyndns-1.0-2.fc11.1.src.rpm

and now that I have that, do I cvs-import.sh it into F10 only, right?

(In reply to comment #33)
> I think you should not change Makefile because it's overwritten by configure.  

this module does not have a Configure script

(In reply to comment #34)
> Just commit the spec and the files you changed from your local cvs.

for managing my code I use SVN, so the spec and changed files are committed there... I then build an SRPM from a tarball which is what I use for the cvs-import.sh

in that context, I'm unsure what you're suggesting

> make clog (this will create a file called "clog" with your latest changelog
> entry)

do I do this in ~/cvs/F10?

> cvs commit -F clog (clog will be used as commit message)
> make tag build
> 
> As ling as a particular version of a package hasn't sucessfully been build, you
> can also re-tag something with
> 
> TAG_OPTS=-F make tag

what is the value of this tag?

> But please be careful with this, never overwrite a package that has already
> been built.

Comment 36 Christoph Wickert 2009-10-03 18:28:46 UTC
(In reply to comment #35)
> (In reply to comment #34)
> > Just commit the spec and the files you changed from your local cvs.
> 
> for managing my code I use SVN, so the spec and changed files are committed
> there... I then build an SRPM from a tarball which is what I use for the
> cvs-import.sh

You shouldn't do that, because when importing whole srpms all the time, you effectively have no version control of the changes you did to the spec. I mean, how would you compare the changes? When you are working in the local checkout of the cvs, you can easily check the changes with cvs diff -u before you commit them.

For more info, please read https://fedoraproject.org/wiki/Package_update_HOWTO

> > make clog (this will create a file called "clog" with your latest changelog
> > entry)
> 
> do I do this in ~/cvs/F10?

Yes, in the branch you want to change something.


> what is the value of this tag?

Every package must have a corresponding tag. You can checkout cvs by that particular tag and will get exactly the state that the package was built from.

Comment 37 Erick Calder 2009-10-03 18:52:31 UTC
> You shouldn't do that, because when importing whole srpms all the time, you
> effectively have no version control of the changes you did to the spec. I mean,
> how would you compare the changes? When you are working in the local checkout
> of the cvs, you can easily check the changes with cvs diff -u before you commit
> them.

hmm... I think in this case it's a little different because I'm the developer so I've included the spec file in the tarball (and it lives with my source code, under SVN)

but I do see your issue.  I'm also navigating mod_gnutls (for which I'm not the developer) through this process so my spec file isn't revisioned as it just sits in ~rpm/SPECS

I read through your link above but it does not talk about how to keep your spec (and possibly, patch files) in cvs... do you have a reference for that?

> > what is the value of this tag?
> 
> Every package must have a corresponding tag. You can checkout cvs by that
> particular tag and will get exactly the state that the package was built from.  

ok, I've decided to roll back the changes to the Makefile.  the better solution is to create a patch file specific for F10.  so now the only thing is I don't know how to apply a patch file conditionally i.e. for F10 only.  can you help with that?

Comment 38 Christoph Wickert 2009-10-03 20:00:33 UTC
(In reply to comment #37)
> but I do see your issue.  

Fine. Remember, the changes must be visible not only for you, but also for the other maintainers in Fedora. Sometimes, e. g. when a person is on vacation, someone else jumps the gun in case of an urgent problem.

> I read through your link above but it does not talk about how to keep your spec
> (and possibly, patch files) in cvs... do you have a reference for that?

Not sure if I understand your question correctly. Basically it's just like what you do with your development in SVN.

> so now the only thing is I don't
> know how to apply a patch file conditionally i.e. for F10 only.  can you help
> with that?  

Simple as that:

%if 0%{?fedora} = 10
%patch0 -p1 -b .orig
%endif

See: https://fedoraproject.org/wiki/Packaging/DistTag#Conditionals

Comment 39 Erick Calder 2009-10-04 01:36:49 UTC
(In reply to comment #38)
> Fine. Remember, the changes must be visible not only for you, but also for the
> other maintainers in Fedora. Sometimes, e. g. when a person is on vacation,
> someone else jumps the gun in case of an urgent problem.

ok. what I've done is added the spec file to ~rpm/cvs/afraid-dyndns and converted ~/prj/afraid-dyndns/spec to a link that points to it so the spec file is included in the tarball and lives with the rest of the source.  is that ok? I don't need the tarball too do I? and the patches?

(In reply to comment #38)
> %if 0%{?fedora} = 10
> %patch0 -p1 -b .orig
> %endif

for some reason -p1 breaks the process with the error:

Patch (afraid-dyndns.F10.patch):
+ /bin/cat /builddir/build/SOURCES/afraid-dyndns.F10.patch
+ /usr/bin/patch -s -p1 -b --suffix .orig --fuzz=0
missing header for unified diff at line 5 of patch
The text leading up to this was:
--------------------------
|Index: Makefile
|===================================================================
|--- Makefile	(revision 2470)
|+++ Makefile	(revision 2471)
--------------------------
File to patch: 
Skip this patch? [y] 
1 out of 1 hunk ignored

however, -p0 seems to fix that problem.  now, in getting all this to work, I bumped up the spec file to -5.  It wasn't really my intention but I haven't figure out my workflow so testing was done at points after a commitment. sigh.

now my question is: if I have a -5 in F-10, do I then have to build -5 for F-11 and up (I'm not sure I understood the point in the link you had sent), or is it ok to leave those at -2?

Comment 40 Fedora Update System 2009-10-06 22:02:49 UTC
afraid-dyndns-1.0-5.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/afraid-dyndns-1.0-5.fc10

Comment 41 Fedora Update System 2009-10-09 03:36:09 UTC
afraid-dyndns-1.0-5.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update afraid-dyndns'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-10334

Comment 42 Erick Calder 2009-10-16 01:13:48 UTC
if I now want to release version 1.1 of this package, do I need to open a new bug? do I need to open a bug at all?

Comment 43 Fedora Update System 2009-10-16 02:15:10 UTC
afraid-dyndns-1.1-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/afraid-dyndns-1.1-1.fc11

Comment 44 Fedora Update System 2009-10-16 02:15:22 UTC
afraid-dyndns-1.1-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/afraid-dyndns-1.1-1.fc12

Comment 45 Fedora Update System 2009-10-16 02:15:31 UTC
afraid-dyndns-1.1-2.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/afraid-dyndns-1.1-2.fc10

Comment 46 Fedora Update System 2009-10-21 00:35:22 UTC
afraid-dyndns-1.1-1.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update afraid-dyndns'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10560

Comment 47 Fedora Update System 2009-10-21 00:42:49 UTC
afraid-dyndns-1.1-2.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update afraid-dyndns'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-10610

Comment 48 Fedora Update System 2009-11-13 02:36:21 UTC
afraid-dyndns-1.0-5.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 49 Fedora Update System 2009-11-16 07:29:20 UTC
afraid-dyndns-1.1-2.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 50 Fedora Update System 2009-11-16 07:29:37 UTC
afraid-dyndns-1.1-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.