[Bug 13] Review request: rpmfusion-package-config-smart - RPM Fusion configuration files for the Smart package manager
by RPM Fusion Bugzilla
http://bugzilla.rpmfusion.org/show_bug.cgi?id=13
David Timms <dtimms(a)iinet.net.au> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dtimms(a)iinet.net.au
Blocks|2 |3
AssignedTo|rpmfusion-package- |dtimms(a)iinet.net.au
|review(a)rpmfusion.org |
--- Comment #1 from David Timms <dtimms(a)iinet.net.au> 2008-08-08 16:35:01 ---
Taking review:
! needs work.
OK no problemo
?? can't say/don't understand.
=====
[??] rpmlint output:
rpmfusion-package-config-smart.i386: W: no-documentation
rpmfusion-package-config-smart.i386: E: no-binary
2 packages and 0 specfiles checked; 1 errors, 1 warnings
1: including license like GPL's copying may be enough to hide it.
2: should this package be noarch, since it has no executable ?
[!] included source matches upstream: there is no upstream source from what I
can tell.
If no one objects, I would suggest not compressing the config files. It
will be easier to manage/qa any changes in the config files if they are
simply committed into cvs as straight text files, and hence diffs can be
more easily run.
[OK] package name follows the existing scheme used in fedora repo:
fedora-package-config-smart
[OK] spec named %name.spec
[??] source tarball contains no prebuilt binaries/libraries.
however, as suggested above, perhaps just have multiple text sources
[OK] files placed into FHS locations
[OK] changelog in standard format
[OK] correctly omits Packager, vendor, copyright, prereq
, includes license tag.
[OK] summary <80 chars, no ending period
[!] sourceX is correct:
does not exist. see previous comment regarding compressed config.
[??] buildroot differs slightly from third most preferred location.
[OK] %install correctly erases buildroot before build
[ ] mock build succeeds.
not tested.
[ ] rpmdiff between default build and mock build shows only time
{T} differences for folders.
[OK] description is column limited to <80 chars, no manual/doc info.
[OK] charset is ascii
[!] docs not included at all. perhaps include "copying" ?
[OK] debuginfo not expected in noarch package.
[OK] no static libraries, rpath, self copies of already packaged libaries
[OK] no config, initscripts, desktop files.
[OK] variable style is used consistently
[OK] not multilingual
[OK] timestamps are kept
[OK] make is python based, so smp_flags not required.
[OK] no scriptlets, no conditional dependencies
[OK] is library code not content
[OK] provides backend for each of the backend subpackages seems to make sense.
[OK] dirs/files owned by main package, except the individual backend
files {whose directory is created by the main package}.
[OK] not a web app, shoudln't conflict with other packages.
[OK] python sitelib is correctly included at top of spec.
[OK] eggs are build
[OK] no files in %{_bindir} and %{_sbindir}.
[OK] %install setup.py install -O1 --skip-build. as requested for python
packages.
=====
[??] Provides: smart-config-rpmfusion. Is this a previous package that you
are trying to supersee ? Or why is this done ?
If there is a smart config package for any of the three parent repos, then
perhaps this should provide smart-config-[oldrepo], so that the old smart
config is removed ?
[??] license: GPL+ is an allowed value. Possibly need to include a a license
file of some sort.
[!] Release is sane, but needs the %{?dist}
[??] %files:
%dir %{_sysconfdir}/smart
%dir %{_sysconfdir}/smart/channels
I think these directories shouldn't be owned by this package, but rather
by the Requires: package.
[??] The config presented in the smart config files refers to URLs that don't
exist. I assume these will get updated as rpmfusion nears public release ?
[??] package functions as described: wont work at the moment due to the above.
[??] Recently, I have recevied suggestions to use the 'checked' macros for
cp, rm, install etc, eg: %{__install} -D -p -m 0644 %{SOURCE1}
Info: you might like to look at how the equivalent yum config for freshrpms
does some of these things.
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
16 years, 3 months
Re: rpms/lastfm/F-9 lastfm.spec,1.1,1.2
by Thorsten Leemhuis
On 30.07.2008 18:09, Sergio Pascual wrote:
> Author: sergiopr
>
> Update of /cvs/free/rpms/lastfm/F-9
> In directory se02.es.rpmfusion.net:/tmp/cvs-serv19968
>
> Modified Files:
> lastfm.spec
> Log Message:
> * Wed Jul 23 2008 Sergio Pascual <sergio.pasra at gmail.com> 1.4.0.56102-3
> [...]
> - Vendor changed to rpmfusion
> [...]
>
> Index: lastfm.spec
> ===================================================================
> RCS file: /cvs/free/rpms/lastfm/F-9/lastfm.spec,v
> retrieving revision 1.1
> retrieving revision 1.2
> diff -u -r1.1 -r1.2
> --- lastfm.spec 23 Jul 2008 06:22:11 -0000 1.1
> +++ lastfm.spec 30 Jul 2008 16:09:37 -0000 1.2
> @@ -2,7 +2,7 @@
>
> Name: lastfm
> Version: 1.4.0.56102
> -Release: 2%{?dist}
> +Release: 3%{?dist}
> Summary: Last.fm music client
> [...]
> -desktop-file-install --vendor="livna" \
> +desktop-file-install --vendor="rpmfusion" \
Do we want to do that (here and everywhere)? Quoting from
http://fedoraproject.org/wiki/Packaging/Guidelines
> * If upstream uses <vendor_id>, leave it intact, otherwise use fedora as <vendor_id>.
> * It is important that vendor_id stay constant for the life of a package.
>
> This is mostly for the sake of menu-editing (which bases off of .desktop file/path names).
Opinions?
CU
knurd
16 years, 3 months
Timeout problems on the x86-buildsys seem to be solved now
by Thorsten Leemhuis
Hi!
Over the past week a lot of build jobs failed due to timeouts on the
x86-Builder when yum/mock tried to download metadata. Pix (who hosts the
x86-build server) did some magic earlier today and it seems the problem
is fixed now.
I hopefully requeued all jobs that failed earlier; might take a while
until the buildsys makes its way through the list as the build queue is
still quite long (I yesterday imported and requested builds for a lot of
packages from livna).
CU
knurd
16 years, 3 months
Re: Naming the nVidia drivers for RPMFusion
by Thorsten Leemhuis
Hi!
Sorry for the late reply. CCing rpmfusion-developers and full-quoting
message, as this discussion is relevant for RPM Fusion. Two eearlier
replies to this mail can be found in the freeworld archives and in the
attachment:
http://livna.org/pipermail/freeworld/2008-July/003115.html
http://livna.org/pipermail/freeworld/2008-July/003116.html
On 19.07.2008 18:24, Stewart Adam wrote:
> Hi,
>
> Thorsten, Nicolas and I discussed this briefly in IRC but it would be
> great to have your opinion on it. The problem we're having is that
> nVidia now has the "normal" mainstream driver along with 3 other drivers
> which are considered "legacy", each supporting a different set of GPUs.
>
> According to nVidia's driver selection on its website, the 177 series is
> recommended only for the new GeForce 200 series GPUs. The GeForce 9000
> to 5000FX series are to be used with the 173 driver, while GeForce 2/4
> are to be used with the 96.* series driver and the 71.* driver is for
> any older cards like Riva or TNT.
>
> If we choose a named scheme, such as kmod-nvidia-newest and
> kmod-nvidia-legacy, the problem is when nVidia releases a new driver
> that drops support for older cards, those users will receive updates to
> "kmod-nvidia-newest" and will be left without X.
>
> If we choose versioned names, for example "kmod-nvidia-173", then it
> would be simple to create "kmod-nvidia-177" and it would only
> "Obsoletes: kmod-nvidia-173" if it retained compatibility with the same
> cards. The disadvantage to this is that if a driver does drop support
> for old cards, the people with new cards have to manually install the
> new driver. One possibility I was thinking of was including GPU
> detection in livna-config-display so that it would be able to suggest
> users of the newer GPUs to upgrade.
>
> How do you think we should name the drivers? It doesn't have to be one
> of the two I mentioned above, those are just the option we had thought
> of on IRC.
Some general thoughts:
* For the legacy drivers I'd like to see "legacy" in the package name
(nvidia-legacy-73xx, nvidia-legacy-96xx), as that makes things like "I'm
using legacy stuff that (1) might not support all Features and (2) might
be dropped sooner or later" obvious to the user. That is a quite
important detail IMHO.
On the other hand it has some appeal to use the same scheme for all
driver packages (nvidia-71xx, nvidia-96xx, nvidia-173, nvidia-177)
* some users in the past asked us to maintain a stable branch that is
not updated immediately when nvidia releases a new version
* other users always want the latest and greatest; they even asked us
to ship beta drivers
* some people were unhappy that we used the xorg-x11-drv prefix for
our drivers; are those people still unhappy? Should we consider to get
rid of that prefix again?
* making the driver parallel installable would be really nice for
live-media
* updates don't work for all the drivers -- users need to restart; we
need to find a way to unload the module during X-restart after a nvidia
update; that should be easy; fglrx did something like that in the past
* I don't like the GUI livna-config-display much at all; cluttered
interface and some of the things (like the Xgl stuff) are totally
irrelevant for 99,9 % of our users; that needs a major cleanup!
So maybe something like this could work to solve some of the problems:
* we ship all the driver packages with a versioned name nvidia-73xx,
nvidia-96xx, nvidia-173, nvidia-177
* make those packages parallel installable
* create a init script/app that chooses the "best" driver on bootup;
that app could even have a settings file where the user could say "use
beta drivers; prefer 177 series" or something like that; it also could
yell thinks like "you have the 173 series of drivers installed but need
the legacy drivers from the 96xx series".
But that app should never ever call yum, as network might not be
accessible during start. A lot of people also dislike if packages get
installed behind their back, so we should avoid to do that.
* create two meta packages "nvidia-all" and "nvidia" to the repo;
"nvidia-all" could track in all the drivers we offer and everything will
"just work" -- the easiest solution for ordinary users. "nvidia" could
track in the driver that is considered the "standard" one (173 now) and
all newer ones (177 right now). That could be the solution for those
users that want to avoid useless downloads for the legacy driver. The
decision which driver to use would be left up to the init script;
* having a GUI app that says "you need nvidia-73xx, nvidia-96xx or
nvidia" would be nice. It IMHO should not offer the standard and newest
drivers (173, 177), as their meaning and usage might change over time;
the script can handle that better, even if that means some useless downloads
But that GUI app IMHO should not be specific to nvidia or graphics
drivers. It would be way better if it would a bit like the proprietary
driver install and configure tool Ubuntu has. Even better: make that app
able to suggest and install add-on packages like gstreamer-plugins or
xine-lib-extras-monfree for the packages it finds installed on the
system; that would be a really cool feature :-)
* users that want to avoid useless downloads can just install
nvidia-173; they can keep both pieces if it breaks because they tried to
be smart and but are not. Of course we use proper obsoletes in newer
drivers where it makes sense to not break stuff on purpose ;-)
Does that sound like a solution that fixes some of todays and tomorrows
problems?
CU
knurd
16 years, 3 months
Re: Buildsys cflags issue solved, now need someone to fix it
by Thorsten Leemhuis
On 24.07.2008 18:10, Thorsten Leemhuis wrote:
> [...] that's why that builder use the older mechanism for now (¹).
> [...]
> (¹) the plan is to reinstall the builder once we can shut livna down;
Note: for that we at least temporary need another x86_64 system that
could serve as buildsys for a few days while the livna one is getting a
fresh OS. Can anybody provide such a system? Would need a lot of hard
disk space for a local mirror or a really fast internet connection.
It would be great to have two x86_64-builders in general. So maybe that
system could stay as second builder for the foreseeable future.
Cu
knurd
16 years, 3 months
