Bug 455631 - jd update frequency and spec question
jd update frequency and spec question
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: jd (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Mamoru TASAKA
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-16 14:09 EDT by Kevin Fenzi
Modified: 2009-07-14 12:03 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 12:03:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kevin Fenzi 2008-07-16 14:09:14 EDT
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 08:32:00 EDT
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 12:51:09 EDT
>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 13:02:21 EDT
(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-09 22:06:59 EDT
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 12:03:41 EDT
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.