Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 455631 - jd update frequency and spec question
Summary: jd update frequency and spec question
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: jd
Version: 9
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Mamoru TASAKA
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-16 18:09 UTC by Kevin Fenzi
Modified: 2009-07-14 16:03 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-07-14 16:03:41 UTC


Attachments (Terms of Use)

Description Kevin Fenzi 2008-07-16 18:09:14 UTC
Is there a compelling reason to keep updating and building every day jd packages
for f8/f9? Wouldn't this cause a problem if a security update needed to be
applied without upgrading the entire package? 

Upgrading often in rawhide seems fine, but why checkin and build for f8/f9 every
day?

Also, a question about the spec file: 

Why is: 
# set TZ for __TIME__
export TZ='Asia/Tokyo'
needed?

Thanks for your reply.

Comment 1 Mamoru TASAKA 2008-07-17 12:32:00 UTC
First of all, JD is a web client to browse or participate in Japanese 2ch bbs:
http://2ch.net/
http://en.wikipedia.org/wiki/2channel
All conversation is done with Japanese language. JD itself also supports only
Japansese
language.

Then:
1. but why checkin and build for f8/f9 every day?
From requests by Fedora JD users. The discussion of the development of JD is
also done
using 2ch JD thread
(currently: http://pc11.2ch.net/test/read.cgi/linux/1202126579/ ), where the
upstream
developer usually reacts to requests or bug reports quickly and JD development
is rather
fast. Then we don't care anything other than the latest svn trunk revision.
I usually rebuilds JD rather frequently on all repositories to help JD
developers and
Fedora JD users discussing on JD thread to accelerate JD development.

2. export TZ='Asia/Tokyo'
When subversion is not available (note that jd.spec has explicitly commented out
the line
"find . -name .svn | sort -r | xargs %{__rm} -rf") jd build tries to use the
time when
JD is rebuild for reporting bugs (see jdlib/miscutil.cpp and __TIME__ is used).
Again JD is Japanese 2ch BBS client and mainly used by Japanese people.
koji server is out of Japan and I explicitly set TZ on compilation.

Comment 2 Kevin Fenzi 2008-07-18 16:51:09 UTC
>Then:
>1. but why checkin and build for f8/f9 every day?
>From requests by Fedora JD users. The discussion of the development of JD is
>also done
>using 2ch JD thread
>(currently: http://pc11.2ch.net/test/read.cgi/linux/1202126579/ ), where the
>upstream
>developer usually reacts to requests or bug reports quickly and JD development
>is rather
>fast. Then we don't care anything other than the latest svn trunk revision.
>I usually rebuilds JD rather frequently on all repositories to help JD
>developers and
>Fedora JD users discussing on JD thread to accelerate JD development.
 
Ah, so they get those builds direct from koji to test and do further development?
And they are all on various Fedora versions? 
 
>2. export TZ='Asia/Tokyo'
>When subversion is not available (note that jd.spec has explicitly commented out
>the line
>"find . -name .svn | sort -r | xargs %{__rm} -rf") jd build tries to use the
>time when
>JD is rebuild for reporting bugs (see jdlib/miscutil.cpp and __TIME__ is used).
>Again JD is Japanese 2ch BBS client and mainly used by Japanese people.
>koji server is out of Japan and I explicitly set TZ on compilation.
 
ok. Makes sense. Perhaps you could just get them to hard code that in
(and perhaps make it overrideable).

Thank you for your quick reply.

Comment 3 Mamoru TASAKA 2008-07-18 17:02:21 UTC
(In reply to comment #2)
> >Then:
> >1. but why checkin and build for f8/f9 every day?
> >From requests by Fedora JD users. 
> Ah, so they get those builds direct from koji to test and do further development?
> And they are all on various Fedora versions? 

Yes! Even for issues not related to JD, Japanese 2ch user often say "Have you
seen such
issue I see now?" "Have you tried the newest package on koji?"

> >2. export TZ='Asia/Tokyo'
> >When subversion is not available (note that jd.spec has explicitly commented out
> >the line
> >"find . -name .svn | sort -r | xargs %{__rm} -rf") jd build tries to use the
> >time when
> >JD is rebuild for reporting bugs (see jdlib/miscutil.cpp and __TIME__ is used).
> >Again JD is Japanese 2ch BBS client and mainly used by Japanese people.
> >koji server is out of Japan and I explicitly set TZ on compilation.
>  
> ok. Makes sense. Perhaps you could just get them to hard code that in
> (and perhaps make it overrideable).
> 
> Thank you for your quick reply.



Comment 4 Bug Zapper 2009-06-10 02:06:59 UTC
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 5 Bug Zapper 2009-07-14 16:03:41 UTC
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


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