Bug 507223 - Review Request: dalston - Moblin System Information Icons
Summary: Review Request: dalston - Moblin System Information Icons
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Christoph Wickert
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 506721
Blocks: FedoraMoblin20
TreeView+ depends on / blocked
 
Reported: 2009-06-21 19:22 UTC by Peter Robinson
Modified: 2009-10-08 06:20 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-10-08 06:20:04 UTC
Type: ---
Embargoed:
christoph.wickert: fedora-review+
kevin: fedora-cvs+


Attachments (Terms of Use)

Description Peter Robinson 2009-06-21 19:22:25 UTC
SPEC: http://pbrobinson.fedorapeople.org/dalston.spec
SRPM: http://pbrobinson.fedorapeople.org/dalston-0.0.25-1.fc11.src.rpm

System information icons for Moblin

Comment 1 Parag AN(पराग) 2009-07-03 10:59:06 UTC
I assume this package review is for Fedora that mean I should get this package working and functionally fine. When I installed this and restart gdm, I got both applets in systray but in disabled mode. I can't even rigth-click it. Why those applets are not enabled by defualt. Is it because I already have gnome-volume-control-applet running?

Comment 2 Peter Robinson 2009-07-03 11:05:15 UTC
Its for moblin. Its not designed or been tested to run within the standard gnome desktop.

Comment 3 Ralf Corsepius 2009-07-03 12:06:21 UTC
(In reply to comment #2)
> Its for moblin. Its not designed or been tested to run within the standard
> gnome desktop.  

So would you mind to explain why this package should be in Fedora?
Are you going to implement a "moblin-desktop" or is this just a piece of currently more or less defunct, immature SW, lacking generality?

That said, I am not sure, this package should enter Fedora.

Besides this, I am not excited about how you package your moblin packages. In particular, I consider you to be acting pretty careless wrt. the autotools, NVRs and further details.

Comment 4 Peter Robinson 2009-07-03 12:18:26 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > Its for moblin. Its not designed or been tested to run within the standard
> > gnome desktop.  
> 
> So would you mind to explain why this package should be in Fedora?
> Are you going to implement a "moblin-desktop" or is this just a piece of
> currently more or less defunct, immature SW, lacking generality?

Yes. I am. That's why its a dep against the FedoraMoblin tracker bug. See https://fedoraproject.org/wiki/Features/FedoraMoblin for further details.

> That said, I am not sure, this package should enter Fedora.

Why?

> Besides this, I am not excited about how you package your moblin packages. In
> particular, I consider you to be acting pretty careless wrt. the autotools,
> NVRs and further details.  

What's exactly wrong with them, I'm quite happy with constructive criticism. I believe the adhere to to the Package Guidelines but its always possible that I've missed stuff.

Comment 5 Ralf Corsepius 2009-07-03 12:47:47 UTC
(In reply to comment #4)

> > That said, I am not sure, this package should enter Fedora.
> 
> Why?
Fedora's mission is to be a "leading edge distro", not a "bleeding edge" distro, consisting of more or less non-functional, immature packages.

IMO, this package is not unlikely of the latter kind.

> > Besides this, I am not excited about how you package your moblin packages. In
> > particular, I consider you to be acting pretty careless wrt. the autotools,
> > NVRs and further details.  
> 
> What's exactly wrong with them,
You should not run the autotools at build-time, but run them in advance and add the result through patches - That's how the autotools are supposed to be used.

By not doing so, you are exposing yourselves to the risks of non-determinisic builts and your users to risks of exposing them to mis-built packages.

> I
> believe the adhere to to the Package Guidelines but its always possible that
> I've missed stuff.  
The FPG doesn't contain a rule mandating it, because certain key-people in Fedora refuse to implement such a rule and prefer to expose people to risks because "it's so convenient".

My opinion differs substantially. I conside running the autotools during builts as elementary beginners mistake and refuse to review any package doing so.

Comment 6 Peter Robinson 2009-07-03 13:03:31 UTC
> > > That said, I am not sure, this package should enter Fedora.
> > 
> > Why?
> Fedora's mission is to be a "leading edge distro", not a "bleeding edge"
> distro, consisting of more or less non-functional, immature packages.
> 
> IMO, this package is not unlikely of the latter kind.

That is your opinion, not mine or others I've spoken to, its not a topic for a bug report.

> > > Besides this, I am not excited about how you package your moblin packages. In
> > > particular, I consider you to be acting pretty careless wrt. the autotools,
> > > NVRs and further details.  
> > 
> > What's exactly wrong with them,
> You should not run the autotools at build-time, but run them in advance and add
> the result through patches - That's how the autotools are supposed to be used.
> 
> By not doing so, you are exposing yourselves to the risks of non-determinisic
> builts and your users to risks of exposing them to mis-built packages.

But its a much used method within packages. Same as above its not a discussion to be had on a bug report but a discussion to be bought up as a proposed on fedora-devel if you feel strongly about it.

> > I
> > believe the adhere to to the Package Guidelines but its always possible that
> > I've missed stuff.  
> The FPG doesn't contain a rule mandating it, because certain key-people in
> Fedora refuse to implement such a rule and prefer to expose people to risks
> because "it's so convenient".
> 
> My opinion differs substantially. I conside running the autotools during builts
> as elementary beginners mistake and refuse to review any package doing so.  

I'm not making you review my package and as you mentioned its your opinion. I don't necessarily disagree but until upstream do proper 'make dist' packages its going to remain the way it is. Its a perfectly valid package as the current packaging requirements. Packaging guidelines discussions are for the mailing list.

Comment 7 Ralf Corsepius 2009-07-03 14:42:45 UTC
(In reply to comment #6)
> > > > That said, I am not sure, this package should enter Fedora.
> > > 
> > > Why?
> > Fedora's mission is to be a "leading edge distro", not a "bleeding edge"
> > distro, consisting of more or less non-functional, immature packages.
> > 
> > IMO, this package is not unlikely of the latter kind.
> 
> That is your opinion, not mine or others I've spoken to, its not a topic for a
> bug report.
A package's maturity/quality is topic within a review.


> But its a much used method within packages.
Yes, these packages and your specs are of low quality.

> Packaging guidelines discussions are for the mailing
> list.  
Free free to continue shipping these apparently dysfunctional low quality packages.

My advise to reviewers: Do not approve this package in this current shape.

Comment 8 Alexander Boström 2009-07-04 10:38:41 UTC
Moblin (the distro) version 2.0 beta has been released, so it seems reasonable to package the individual components for rawhide now.

If these shows up automatically on GNOME logins then it's a bug that breaks existing functionality, where functionality means "a GNOME desktop that is not cluttered with broken and irrelevant icons". In that case I agree that it should be a priority to fix that.

Comment 9 Peter Robinson 2009-07-06 10:57:18 UTC
> If these shows up automatically on GNOME logins then it's a bug that breaks
> existing functionality, where functionality means "a GNOME desktop that is not
> cluttered with broken and irrelevant icons". In that case I agree that it
> should be a priority to fix that.  

I've excluded the autostart files from the rpm so it won't start when in other desktop environments. I'm going to investigate other ways of starting them, possibly through the moblin session manager/startup. Thoughts?

SPEC: http://pbrobinson.fedorapeople.org/dalston.spec
SRPM: http://pbrobinson.fedorapeople.org/dalston-0.0.27-1.fc11.src.rpm

Comment 10 Peter Robinson 2009-07-06 10:59:01 UTC
Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1456527

Comment 12 Peter Robinson 2009-07-26 16:28:19 UTC
(In reply to comment #11)
> New upstream release
> 
> SRPM: http://pbrobinson.fedorapeople.org/bisho-0.10.7-1.fc11.src.rpm
> koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=1502659  

Ignore this. Wrong bug.

Comment 14 Christoph Wickert 2009-08-08 22:32:43 UTC
OK - MUST: $ rpmlint /var/lib/mock/fedora-rawhide-x86_64/result/dalston-*
3 packages and 0 specfiles checked; 0 errors, 0 warnings.
OK - MUST: named according to the Package Naming Guidelines
OK - MUST: spec file name matches the base package %{name}
OK - MUST: package meets the Packaging Guidelines
OK - MUST: Fedora approved license and meets the Licensing Guidelines: LGPLv2 and GPLv2+
FIX - MUST: License field in spec file doesnt match the actual license LGPLv2 and GPLv2
OK - MUST: license file included in %doc
OK - MUST: spec is in American English
OK - MUST: spec is legible
OK - MUST: sources match the upstream source by MD5 a0ec0af90200c7d11c418514eeba1cb1
OK - MUST: successfully compiles and builds into binary rpms on x86_64
OK - MUST: No ExcludeArch
OK - MUST: all build dependencies are listed in BuildRequires.
OK - MUST: handles locales properly with %find_lang
OK - MUST: not designed to be relocatable
OK - MUST: owns all directories that it creates
OK - MUST: no duplicate files in the %files listing
OK - MUST: Permissions on files are set properly, includes %defattr(...)
OK - MUST: package has a %clean section, which contains rm -rf %{buildroot}
OK - MUST: consistently uses macros
OK - MUST: package contains code
OK - MUST: No large documentation files
OK - MUST: Files included as %doc do not affect the runtime of the application
N/A - MUST: Header files must be in a -devel package
N/A - MUST: Static libraries must be in a -static package
N/A - MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig'.
OK - MUST: The package does not contain any .la libtool archives.
 - MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. The package contains a GUI application and includes a %{name}.desktop file, and that file is properly installed with desktop-file-install in the %install section.

OK - MUST: packages does not own files or directories already owned by other packages.
OK - MUST: at the beginning of %install, the package runs rm -rf %{buildroot}
OK - MUST: all filenames valid UTF-8


SHOULD Items:
OK - SHOULD: Source package includes license text(s) as a separate file.
N/A - SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available.
OK - SHOULD: builds in mock.
OK - SHOULD: compiles and builds into binary rpms on all supported architectures.
OK - SHOULD: functions as described.
FIX - SHOULD: Scriptlets not sane: you are updating icon cache although there are no icons
N/A - SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency.
N/A - SHOULD:  pkgconfig(.pc) files should be placed in a -devel pkg.
N/A - SHOULD: no dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin


Other issues:
OK - latest stable version
OK - SourceURL valid
OK - Compiler flags ok
OK - Debuginfo complete


Issues:
- License field
- drop redundant glib2-devel BR
- drop Requires(post): /bin/touch
- %description does not end with dot.
- %description should be more detailed, mention power and volume
- add INSTALL='install p' to make install
- rm the autostart file instead of %exclude
- no libtool archives, so nothing to remove
- README missing from %doc
- configure is run twice, your hack doesn't work

Comment 15 Ralf Corsepius 2009-08-09 05:41:48 UTC
From build.log:

* Using wrong autotools:
...
/usr/bin/gnome-autogen.sh
[[1mchecking for autoconf >= 2.53...
[(B[[m  testing autoconf2.50... not found.
  testing autoconf... /usr/bin/autoconf: line 519: echo: write error: Broken pipe
found 2.63
...

* broken Makefile.am:
dalston/Makefile.am: installing `./depcomp'  
libhal-panel-glib/Makefile.am:3: `%'-style pattern rules are a GNU make extension
libhal-panel-glib/Makefile.am:4: subst -,_,$*: non-POSIX variable name
libhal-panel-glib/Makefile.am:4: (probably a GNU make extension)
libhal-power-glib/Makefile.am:3: `%'-style pattern rules are a GNU make extension
libhal-power-glib/Makefile.am:4: subst -,_,$*: non-POSIX variable name
libhal-power-glib/Makefile.am:4: (probably a GNU make extension)

Likely harmless, but needs to be checked for correct operation in detail.


* MUSTFIX: Make rules are non-verbose
...
Making all in libhal-glib
  CC    egg-dbus-monitor.o 
  CC    egg-dbus-proxy.o
  CC    egg-debug.o
  CC    hal-marshal.o
  CC    hal-device.o
  CC    hal-manager.o

This is an automake-1.10/automake-1.11 incompatibility orginating from running  the autotools during build.s

Comment 16 Peter Robinson 2009-08-11 12:46:10 UTC
From Christoph the following are fixed:
- License field
- drop redundant glib2-devel BR
- drop Requires(post): /bin/touch
- %description does not end with dot.
- %description should be more detailed, mention power and volume
- add INSTALL='install p' to make install
- no libtool archives, so nothing to remove
- README missing from %doc

These are modified:
- rm the autostart file instead of %exclude
* Upstream has fixed these to add OnlyShowIn=MOBLIN; so it will only start in the Moblin Desktop so I've added them back in. This has the issues that desktop file validation won't work. Trying to ascertain the status of getting MOBLIN added into the upstream package.

From Ralf the following are fixed:
- MUSTFIX: Make rules are non-verbose

From both I'm investigating these further, will fix/send upstream as appropriate:
- Using wrong autotools
- broken Makefile.am
- configure is run twice, your hack doesn't work
* disabled for the moment. Will re-enable once I've had time to investigate it further.

Updated files as follows:
SPEC: http://pbrobinson.fedorapeople.org/dalston.spec
SRPM: http://pbrobinson.fedorapeople.org/dalston-0.0.29-2.fc11.src.rpm
koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=1597693

Comment 18 Peter Robinson 2009-08-28 17:06:50 UTC
New upstream relese
SRPM: http://pbrobinson.fedorapeople.org/dalston-0.1.2-1.fc11.src.rpm

Comment 19 Christoph Wickert 2009-08-31 23:43:26 UTC
Looks good so far, but the autotools issues from comment #15 remain. Ralf, you mind helping out with a patch?

Comment 20 Ralf Corsepius 2009-09-02 15:16:50 UTC
(In reply to comment #19)
> Looks good so far, but the autotools issues from comment #15 remain. Ralf, you
> mind helping out with a patch?  
I don't understand - which of the issues from comment #15 are you referring to?

Some of them are related to bugs in gnome-autogen.sh, others are related to the original source code abusing the autotools (the pattern-rules), other issues are releated Mr. Robinson using an incorrectly packaged tarball.

Comment 21 Christoph Wickert 2009-09-02 23:44:14 UTC
(In reply to comment #20)
> I don't understand - which of the issues from comment #15 are you referring to?

The one first one "using wrong autotools". IIRC your approach to avoid running autotools during build is to run them manually and create a patch from that. If we created a patch, would we also be able to fix this error while we are at it?

> other issues
> are releated Mr. Robinson using an incorrectly packaged tarball.

This sounds like you are blaming Peter for the tarball, not upstream.

Comment 22 Christoph Wickert 2009-09-02 23:46:48 UTC
Let me put it differently:

(In reply to comment #15)
> * Using wrong autotools:
> ...
> /usr/bin/gnome-autogen.sh
> [[1mchecking for autoconf >= 2.53...
> [(B[[m  testing autoconf2.50... not found.
>   testing autoconf... /usr/bin/autoconf: line 519: echo: write error: Broken
> pipe
> found 2.63

I've seen this error in a couple of packages without any notable loss of function or other bugs. Do you consider this a problem for the app itself of only for the build process?

Comment 23 Ralf Corsepius 2009-09-03 08:15:43 UTC
(In reply to comment #22)
AFAICT, this is a bug in gnome-autogen.sh.

Another one (unrelated to this package) is this:
...
checking for autoconf >= 2.53...
  testing autoconf2.50... not found.
  testing autoconf... found 2.63
...
(In reply to comment #21)
> > other issues
> > are releated Mr. Robinson using an incorrectly packaged tarball.
> 
> This sounds like you are blaming Peter for the tarball, not upstream.  
It's partially upstream's mistake, it's partially Mr. Robinson's mistake.

Upstream ships an incomplete tarball. Mr. Robinson refuses to use this tarball in compliance to the autotools' working principles.

Or differently: If Mr. Robinson was using a "make dist" generated tarball or was running the autotools in advance to building and was applying patches, all the issues we currently are discussing would not be around.

Comment 24 Peter Robinson 2009-09-03 09:17:35 UTC
> Or differently: If Mr. Robinson was using a "make dist" generated tarball or
> was running the autotools in advance to building and was applying patches, all
> the issues we currently are discussing would not be around.  

Mr Robinson would gladly use a make dist tarball if they were distributed by upstream :) Believe me it would make my life so much easier!

Comment 25 Ralf Corsepius 2009-09-03 09:35:36 UTC
(In reply to comment #24)
> > Or differently: If Mr. Robinson was using a "make dist" generated tarball or
> > was running the autotools in advance to building and was applying patches, all
> > the issues we currently are discussing would not be around.  
> 
> Mr Robinson would gladly use a make dist tarball if they were distributed by
> upstream :) Believe me it would make my life so much easier!  
And why don't _you_ do it?

Comment 27 Christoph Wickert 2009-09-10 16:47:28 UTC
Let's see what we've got:

$ rpmlint Downloads/dalston-*
dalston.x86_64: W: non-conffile-in-etc /etc/xdg/autostart/dalston-power-applet.desktop
dalston.x86_64: W: non-conffile-in-etc /etc/xdg/autostart/dalston-volume-applet.desktop
3 packages and 0 specfiles checked; 0 errors, 2 warnings.

Minor. Please mark the files %config (although it's not really necessary since changes will be saved in user's XDG_CONFIG_HOME.)

OK - Source matches upstream source by md5 aeb4b0c644694a9833c92e1976fab6c6
OK - SourceURL valid
OK - License tag correct: LGPLv2 and GPLv2+
OK - dropped redundant glib2-devel BR
OK - dropped Requires(post): /bin/touch
OK - %description ends with dot
OK - timestamps preserved during %install
OK - no libtool archives, so nothing to remove
OK - README added to %doc
OK - verbose make rules
OK - configure is only run once


Issues:
FIX - SHOULD: Scriptlets not sane: you are still updating icon cache although there are no icons.
- autotools incompatibility from comment #15. Bug in gnome-autogen.sh
- Makefile.am problem from comment #15: harmless


(In reply to comment #23)
> Mr. Robinson refuses to use this tarball
> in compliance to the autotools' working principles.
> 
> Or differently: If Mr. Robinson was using a "make dist" generated tarball or
> was running the autotools in advance to building and was applying patches, all
> the issues we currently are discussing would not be around.  

No hypothetical "what - if" please. There are no "make dist" generated tarballs and you said Peter uses *this one* incorrectly. Ether you come up with a patch or I'm going to approve this package regardless of the running autotools. IMO this is a minor issue here, so I'm not going to delay this review for it.

Comment 28 Ralf Corsepius 2009-09-10 17:18:56 UTC
> (In reply to comment #23)
> > Mr. Robinson refuses to use this tarball
> > in compliance to the autotools' working principles.
> > 
> > Or differently: If Mr. Robinson was using a "make dist" generated tarball or
> > was running the autotools in advance to building and was applying patches, all
> > the issues we currently are discussing would not be around.  
> 
> No hypothetical "what - if" please. There are no "make dist" generated tarballs

.. shipped by upstream.

> and you said Peter uses *this one* incorrectly.
Right. The upstream tarball is incomplete.

> Ether you come up with a patch
> or I'm going to approve this package regardless of the running autotools.
Addressing this is trivial:

He can run "make dist" in advance to building and either use this "make dist" generated tarball, or use diffs between the upstream tarball and his generated tarball.


> IMO this is a minor issue here,
That's the misunderstanding and mistake of people, who refuse to comprehend why running the autotools during builds is harmful. They are underestimating the amount of breakage changes may cause. It's worse with packages like this one, which apply autotool wrappers (intltool, gnome-autogen.sh etc.)

Comment 29 Peter Robinson 2009-09-14 23:20:50 UTC
> Issues:
> FIX - SHOULD: Scriptlets not sane: you are still updating icon cache although
> there are no icons.

I've updates the script to run on the dalston icons as discussed.

SPEC: as before
SRPM: http://pbrobinson.fedorapeople.org/dalston-0.1.6-1.fc11.src.rpm

koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=1679032

Comment 30 Bastien Nocera 2009-09-17 18:05:52 UTC
FYI, you might want to integrate this patch as well:
http://bugzilla.moblin.org/show_bug.cgi?id=6226

Comment 31 Peter Robinson 2009-09-27 21:12:38 UTC
New build with patches for the new nbtk-1.2 and adding Bastien's g-v-c patch.

SPEC: http://pbrobinson.fedorapeople.org/dalston.spec
SRPM: http://pbrobinson.fedorapeople.org/dalston-0.1.6-2.fc11.src.rpm
koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=1711917

Comment 32 Christoph Wickert 2009-10-01 00:04:09 UTC
(In reply to comment #28)
> Addressing this is trivial:
> 
> He can run "make dist" in advance to building and either use this "make dist"
> generated tarball, or use diffs between the upstream tarball and his generated
> tarball.

I tried to follow your suggestion, but I didn't manage to get it done. Obviously it's not as trivial as you claim. Can you give us more detailed instructions please?

Comment 33 Peter Robinson 2009-10-03 22:11:38 UTC
(In reply to comment #32)
> (In reply to comment #28)
> > Addressing this is trivial:
> > 
> > He can run "make dist" in advance to building and either use this "make dist"
> > generated tarball, or use diffs between the upstream tarball and his generated
> > tarball.
> 
> I tried to follow your suggestion, but I didn't manage to get it done.
> Obviously it's not as trivial as you claim. Can you give us more detailed
> instructions please?  

Um. Try:
./autogen.sh
./configure
make dist

Comment 34 Peter Robinson 2009-10-03 22:13:19 UTC
SPEC: http://pbrobinson.fedorapeople.org/dalston.spec
SRPM: http://pbrobinson.fedorapeople.org/dalston-0.1.6-3.fc11.src.rpm
koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=1726127

Spec file updated with a make dist tarball and the details of how the tarball is generated. I think this fixes everything. Ralf is this OK?

Comment 35 Christoph Wickert 2009-10-03 22:42:13 UTC
(In reply to comment #33)
> Um. Try:
> ./autogen.sh
> ./configure
> make dist

Now I'm getting really confused:
1. I tried that with 0.1.6-1 and it failed for me.
2. This still doesn't fix the "-style pattern rules" errors.
3. Obviously you changed the source from 0.1.6-1 to 0.1.6-2. Please make notice of things like this in the review.

Comment 36 Peter Robinson 2009-10-03 22:56:10 UTC
> Now I'm getting really confused:
> 1. I tried that with 0.1.6-1 and it failed for me.
> 2. This still doesn't fix the "-style pattern rules" errors.

I don't actually see how they are an issue here with regards to a package review. The job of the package review is to review the packaging not the source code. I don't see how the style pattern rules are an issue of the package review, they should be handled upstream. They would only be an issue if it was to be built with none gnu automake which isn't the case in Fedora.

> 3. Obviously you changed the source from 0.1.6-1 to 0.1.6-2. Please make notice
> of things like this in the review.  

Nope. Same one, otherwise I would have made note of it.

Comment 37 Christoph Wickert 2009-10-03 23:32:46 UTC
Huh? 0.1.6-1.fc11 contained a bz2 while 0.1.6-2.fc11 has gz.

$ md5sum dalston-0.1.6-1.fc11.src/dalston-0.1.6.tar.bz2 
1749759cf14192ccf94260733e22b93c  dalston-0.1.6-1.fc11.src/dalston-0.1.6.tar.bz2
$ md5sum dalston-0.1.6-2.fc11.src/dalston-0.1.6.tar.gz 
276042f0e53344f14ece080b37e58d8d  dalston-0.1.6-2.fc11.src/dalston-0.1.6.tar.gz

Comment 38 Peter Robinson 2009-10-03 23:38:15 UTC
(In reply to comment #37)
> Huh? 0.1.6-1.fc11 contained a bz2 while 0.1.6-2.fc11 has gz.
> 
> $ md5sum dalston-0.1.6-1.fc11.src/dalston-0.1.6.tar.bz2 
> 1749759cf14192ccf94260733e22b93c 
> dalston-0.1.6-1.fc11.src/dalston-0.1.6.tar.bz2
> $ md5sum dalston-0.1.6-2.fc11.src/dalston-0.1.6.tar.gz 
> 276042f0e53344f14ece080b37e58d8d  dalston-0.1.6-2.fc11.src/dalston-0.1.6.tar.gz  

Umm.... from the top of the spec file:

# Creation of the tarball as follows:
# wget http://git.moblin.org/cgit.cgi/%{name}/snapshot/%{name}-%{version}.tar.bz2
# tar xf %{name}-%{version}.tar.bz2
# cd %{name}-%{version}
# patch -p1 dalston-nbtk-1.2.patch
# patch -p1 0001-Update-to-latest-gnome-volume-control-code.patch
# make dist

the 'make dist' creates a .gz file. I may have over written the -2 file but -3 is the current build.

Comment 39 Peter Robinson 2009-10-06 20:57:47 UTC
New upstream release:

SPEC: http://pbrobinson.fedorapeople.org/dalston.spec
SRPM: http://pbrobinson.fedorapeople.org/dalston-0.1.8-1.fc11.src.rpm
koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=1731572

I don't see that there's anything else to do.

Comment 40 Christoph Wickert 2009-10-07 00:25:12 UTC
(In reply to comment #38)
> Umm.... from the top of the spec file:

Well, if you want this package reviewed ASAP, then you should make notice of the fact that you changes Source0 in order to fix the autotools mismatch. I thought we were still waiting for something all the time.

(In reply to comment #39)
> I don't see that there's anything else to do.  

The gtk-update-icon-cache stuff still is wrong. It is only needed when a package puts icons into gtk's icon search path [1], this means into /usr/share/icons. %{_datadir}/dalston/icons is a private location, nothing except dalston will ever look there. Just drop the scriptlets.

I don't see any blockers left, so the package is finally APPROVED.


[1] http://standards.freedesktop.org/icon-theme-spec/latest/ar01s03.html
    http://standards.freedesktop.org/icon-theme-spec/latest/ar01s05.html

Comment 41 Peter Robinson 2009-10-07 06:24:31 UTC
Thank you.

New Package CVS Request
=======================
Package Name: dalston
Short Description: Moblin System Information Icons
Owners: pbrobinson
Branches: F-12
InitialCC:

Comment 42 Kevin Fenzi 2009-10-08 05:59:25 UTC
cvs done.

Comment 43 Peter Robinson 2009-10-08 06:20:04 UTC
Imported and built. Thanks all for your assistance.


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