Re: Help to solve a possible circular Requires:
2010/12/3 Fabio M. Di Nitto fdini...@redhat.com: Hi all, I am seeking some help here to solve a possible $subject. I have been trying to find a simple alternate solution, but I just can´t see it or it´s not obvious to me. This is the situation: srpm foo 1.0 ships 2 rpm´s bar and baz. bar has a daemon inside. due to upstream split: srpm foo 1.1 now ships only bar rpm without the daemon. srpm baz 1.1 now ships 2 rpm´s, baz (exactly as in version 1.0) and baz-something that contains the bar´s daemon from 1.0. In order to avoid upgrade issues, we need to make sure that bar 1.1 will pull in baz-something 1.1 (to retain functionality), at the same time baz-something requires bar 1.1 to operate at all. There is no requirement for a strictly versioned Requires: on both sides. baz-something Requires: bar = 1.1, and bar Requires: baz-something (no version need since it´s a new rpm). From local testing, the circular Requires works just fine, both in upgrades and clean install (tested with yum and manual rpm), but I don´t like it. Is there a better way to achieve this upgrade path? Thanks Fabio -- You might be able to find some related information from http://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitting_packages Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meego and Navit ? Was Re: Fedora 15, new and exciting plans
2010/11/19 Linuxguy123 linuxguy...@gmail.com: I realize that most people on this mailing list are focused on infrastructure and server/desktop usage. But some of us are looking forward to using future Fedora releases on tablets in vehicular infotainment systems. To this end, what are the plans for releasing Meego as part of Fedora in F15 ? It would also be really nice to see Navit make it into Fedora. Its been almost there for a long time (since F10 ?) but somehow it never seems to make it. Any chance someone out there could give it a boost ? https://bugzilla.redhat.com/show_bug.cgi?id=654374 Thanks LG Meego haven't officially released any tablet UX plan yet, we still need to wait some time. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Is there anyone known how to contact Xavier Lamien?
Hi, Currently, pitivi 0.13.4 in fedora crashes frequently, I want to update pitivi to the latest verison. But we need to update gstreamer-python to 0.10.19 first, can anybody help to contact Xavier Lamien? See https://bugzilla.redhat.com/show_bug.cgi?id=634093 Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: No response from festival-speechtools maintainer since 2009-6-24
2010/10/2 Hedayat Vatankhah heda...@grad.com: Hi, There has been no response from the maintainer since 2009-06-24 as is clear in [1]. Also, the package has not been updated since then. I wonder what should I do now (?) Thanks, Hedayat [1] https://bugzilla.redhat.com/show_bug.cgi?id=507966 -- See http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Write a new naming guideline for python/python3 modules?
2010/9/16 Toshio Kuratomi a.bad...@gmail.com: When we've talked about this before, in the Packaging Committee we haven't really cared to stipulate one proper way that maintainers must follow since there's several possible ways which all seem equally valid. Inconsistency by itself is not a problem. If it's causing an issue then it would be something the packaging committee would address. Note that the packaging committee last discussed this several years ago so people might be more amenable to some parts of your proposal -- In particular, whether to mandate python-pyfoo or allow pyfoo was contentious before and new things have emerged (namely, that python3 packages must prefix with python3-). However, we'd likely grandfather existing pyfoo packages in so they wouldn't have to rename. I personally don't htink the other parts of your proposal make the guidelines more clear but the packaging committee as a whole would decide this so you're welcome to propose it. I think we can only rename pyfoo packages which are already ported to python3 (e.g. PyQt4) currently, very few packages are affected by this proposal IMHO. If a exsited pyfoo/foopy packages want to add support to python3, then we can rename them one by one to keep a consistent name with their corresponding python3 modules. However, we can mandate all new pyfoo/foopy packages add python- prefix ( it seems you also like this idea that append python- prefix to all python2 modules?[1] ). If FPC don't like this proposal, at least we should not allow foopy packages to apply exception rules to pkgname, I think python-scipy is more consistence than scipy. From Fedora naming guideline - They should take into account the upstream name of the python module. This makes a package name format of python-$NAME. When in doubt, use the name of the module that you type to import it in a script. So currently package submitters are free to choose either upstream name or module name, I'd like an opinion from FPC that which name is preferred or highly recommended for a python module - module name which we type to import it in a script or upstream name which is mostly considered as tarball name, the naming guideline is ambigous in this point. In Debian, they always use module names unless the package ships multiple python modules, it seems dmalcolm and tomspur also like this naming convention. Personally, I also like this proposal, howerer I can also acceptable use upstream name as a perfer as long as FPC detemines which naming convetion are preferred. e.g. python-zmq/python-PySide(module name) or python-pyzmq/python-pyside(upstream name) looks good for me, python-zmq/python-pyside is considered as inconsistence, there are more exsited example in fedora repos. I'm not a native English speaker, maybe my statement is not clear enough. But I think ambigous statement is not trivial to Fedora naming guideline (the name of a particular package is unimportant though) , after all the purpose of naming guildeline is providing a consistent naming convetion for the whole Fedora distribution. I hope some volunteers can help me to write a formal guideline draft. [1]http://lists.fedoraproject.org/pipermail/python-devel/2009-October/000193.html Regards, Chen Lei ___ python-devel mailing list python-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Twitter support broken in Pino
2010/9/10 Bill Nottingham nott...@redhat.com: Bill Nottingham (nott...@redhat.com) said: The other option would be to switch to gwibber (which has been un-desktop-couched in Fedora 14, so it theoretically won't bring in nearly as much to the live image. So, actual testing - building a livecd with gwibber instead of pino brings in the following packages: PyXML 4185378 python-sexy 61194 python-oauth 50819 python-imaging 1381510 python-distutils-extra 133515 mx 6599955 libsexy 102616 gwibber 2367779 Resulting live image was 704MB. Note that not all of these appear to *actually* be required by gwibber - bug 632621 filed. Bill -- Hi all, I'll update pino to the latest snapshot for F14+ soon which already add support for oauth. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retiring or orphaning pam_smb
2010/9/8 Simo Sorce sso...@redhat.com: Hello all, I have recently discovered I am still owner of pam_smb :-) and I think I would like to retire this package entirely, for I find it useless and even dangerous. If someone is interested in picking up maintainership because they need it I am also willing to just orphan it. Any takers ? If not, I think I will retire it. Simo. -- Simo Sorce * Red Hat, Inc * New York It seems pam_smb dead for 6 years. Personally, I think it'll be better to retire it in pkgdb/koji instead of orphan it. Keeping long deprecated packages is not benefical to fedora. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning slim
It seems upstream released a new version one months ago. See http://developer.berlios.de/project/showfiles.php?group_id=2663 Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review swaps
I've have several review requests that have been sitting around for a while now. Many of them are new dependencies for existing packages in fedora, anyone want to swap? EmfEngine(new dep for qtiplot 0.9.8.1): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=618480 libqmf (dep for qt-mobility): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=626122 contextkit(optional dep for qt-mobility): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=613881 libqttracker(optional dep for qt-mobility): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=614075 Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python 3.2a1 in rawhide
2010/8/22 Thomas Spura toms...@fedoraproject.org:
On Sat, 21 Aug 2010 18:48:31 -0400
David Malcolm wrote:
[snip]
So you'll need to update the %files for python3 subpackages, listing
something like:
foo/__pycache__
to capture the directory and the bytecode files within.
Unfortunately there is sometimes also a __pycache__ directory in
%{python_sitearch} (etc...) - for example in python3-minimock:
Checking for unpackaged
file(s): /usr/lib/rpm/check-files
/builddir/build/BUILDROOT/python-minimock-1.2.5-5.fc15.noarch
error: Installed (but unpackaged) file(s)
found: /usr/lib/python3.2/site-packages/__pycache__/minimock.cpython-32.pyc
/usr/lib/python3.2/site-packages/__pycache__/minimock.cpython-32.pyo
Installed (but unpackaged) file(s) found:
/usr/lib/python3.2/site-packages/__pycache__/minimock.cpython-32.pyc
/usr/lib/python3.2/site-packages/__pycache__/minimock.cpython-32.pyo
I decided to *NOT* own the __pycache__ directory, because other python3
packages will have that directory too, so I _believe_ the main python3
package should own them, isn't it?
python3-minimock currently only owns:
%{python3_sitelib}/__pycache__/minimock*
Thomas
--
Hi Thomas,
It seems your latest build points purelib to a incorrect place[1], we
should install all noarch packages to /usr/lib/python*/site-packages.
I also wonder if we can also point stdlib to /usr/lib/python*, since
those files are also arch-independent.
From python docs:
- stdlib : root of the standard library
- platstdlib: root of platform-specific elements of the standard library
- purelib: the site-packages directory for pure python modules
- platlib: the site-packages directory for platform-specific modules
- include: the include dir
- platinclude: the include dir for platform-specific files
- scripts: the directory where scripts are added
- data: the directory where data file are added
[1]http://pkgs.fedoraproject.org/gitweb/?p=python3.git;a=commitdiff;h=997d5a24f2ed0138ce205d7709f5a6acb52fd531
Regards,
Chen Lei
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED, v2] orphaned packages in F-14
2010/8/21 Bill Nottingham nott...@redhat.com: Orphan pitivi Taken, co-maintainers are welcome. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Get rid of file requires outside of the primary paths
2010/8/19 Richard W.M. Jones rjo...@redhat.com: -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- You can add %check section to the spec, then you could test if those files are available when building libguestfs. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[HEADS-UP] python-numarray will be retired for devel/f14 in 3 days
numarray is being phased out and replaced by numpy for 4 years, two packages will be affected after retiring python-numarray in fedora, however both of them can also work file with numpy. repoquery --alldeps --whatrequires python-numarray python-numarray-0:1.5.2-10.fc14.x86_64 HippoDraw-devel-0:1.21.1-12.fc15.i686 HippoDraw-devel-0:1.21.1-12.fc15.x86_64 HippoDraw-python-0:1.21.1-12.fc15.x86_64 scitools-extras-0:0.6-4.fc14.noarch -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] python-numarray will be retired for devel/f14 in 3 days
2010/8/19 Chen Lei supercyp...@gmail.com: numarray is being phased out and replaced by numpy for 4 years, two packages will be affected after retiring python-numarray in fedora, however both of them can also work file with numpy. repoquery --alldeps --whatrequires python-numarray python-numarray-0:1.5.2-10.fc14.x86_64 HippoDraw-devel-0:1.21.1-12.fc15.i686 HippoDraw-devel-0:1.21.1-12.fc15.x86_64 HippoDraw-python-0:1.21.1-12.fc15.x86_64 scitools-extras-0:0.6-4.fc14.noarch Typo: s/file/fine Regrads, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20100817 changes
2010/8/17 Rawhide Report rawh...@fedoraproject.org: Compose started at Tue Aug 17 08:15:07 UTC 2010 Broken deps for x86_64 [snip] 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libvala.so.0()(64bit) antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 It seems antlr3 bundles several different projects in srpm. The python runtime actually have a different version with antlr3, and also a different tarball. See http://cvs.fedoraproject.org/viewvc/devel/antlr3/antlr3.spec?revision=1.17view=markup Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning all my packages
I'll take SOAPpy, co-maintainers for all of my packages are welcome. Full list: https://admin.fedoraproject.org/pkgdb/users/packages/supercyper Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] adding missing systemd links in rawhide/F14 upgrades
Hi Lennart, I found that systemd-units depends on pkgconfig, is this dependency really needed for minimum systemd? Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Some questions about on Fedora
2010/8/10 Remi Collet fed...@famillecollet.com: Le 09/08/2010 09:38, Chen Lei a écrit : It seems silvercity is packaged in many distributions, e.g. gentoo freebsd mandriva PLD. It fact, RPM I found only provide the python library. From the upstream README file : Contributions are welcome for a build system for the standalone library on UNIX and for bindings to other languages. Is the bundled silvercity heavily changed? I can't find which version is used (0.9.6 or 0.9.7). And yes there is some changes, mainly namespace So, I think we could keep the bundled version of this very small library. Any FPC member comment ? It seems reasable to bundle this silvercity, it seems silvercity can't be packaged as system-wide shlib. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Some questions about on Fedora
2010/8/8 Remi Collet fed...@famillecollet.com: Le 08/08/2010 10:28, Chen Lei a écrit : I can help to review mysql-connector-c and Silvercity, howerver we may need a approve from FESCo for bundling scintilla in silvercity. I don't plan to package silvercity, but rather keep both (scintilla + silvercity) bundled in MW. + It seems silvercity is packaged in many distributions, e.g. gentoo freebsd mandriva PLD. Is the bundled silvercity heavily changed? Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Some questions about on Fedora
2010/8/8 Remi Collet fed...@famillecollet.com: Le 07/08/2010 19:17, Liang Suilong a écrit : The first one, as we know, mysql-gui-tools has retired since Fedora 13 because of many bugs. MySQL Workbench will take the place of mysql-gui-tools. Now MySQL Workbench 5.2.26 GA released. Could review request continue? The last comments said that mysql-workbench should remove two bulbed libraries. Is it OK? And Remi has packaged mysql-workbench on his personal repo. I hope this tool will get into Fedora repo soon. There is 2 packaging issues with the actual package on my repo. 1/ bundle scintilla / silvercity. Scintilla upstream doesn't take care of ABI and only build a static library (no shared lib, no soname management). Silvercity use (and extends) a patched version of scintilla. So, I think for this 2 libraries, using the bundled version is the solution. There is already some app, in the fedora repo which use a static version of scintilla. 2/ MySQL Connector C++ I also have a RPM ready for this library, but Workbench doesn't use a stable version, but a bazaar snapshot 818 for 5.2.22 819 for 5.2.24 888 for 5.2.26 I think this is really difficult to maintain (specially if other apps also need this lib). The spec files are available on : http://github.com/remicollet/remirepo/tree/master/mysql-connector-c%2B%2B/ http://github.com/remicollet/remirepo/tree/master/mysql-workbench/ If someone want to care of this reviews, and if ausil agree, I will submit them. Regards. -- I can help to review mysql-connector-c and Silvercity, howerver we may need a approve from FESCo for bundling scintilla in silvercity. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: root-doc subpackage slightly obese
2010/8/9 Kevin Kofler kevin.kof...@chello.at: Toshio Kuratomi wrote: Depending on the technologies and applications involved I could see duplication being okay when one format is meant for people utilizing less /usr/share/doc/foo/* vs running /usr/bin/documentationviewer or /usr/bin/programmer-ide That's the case for the KDE stuff: plain HTML is for plain browsers, QCH is for Qt Assistant and KDevelop. The only issue is: kdelibs-apidocs is one of the largest binary packages in Fedora… But IMHO we'll really want that QCH. (In fact, we've been discussing building it for a while, I've just been caught up in other stuff.) KDevelop not showing KDE apidocs is a poor state of affairs and a regression from Fedora 12 / KDevelop 3.5. At least the QCH is one file, so it won't bloat the file list in the repository metadata. :-) FYI, I've put up QCH apidocs for discussion in the next KDE SIG meeting (Tuesday 14:00 UTC / 16:00 CEST / 10:00 (AM) EDT / 07:00 (AM) PDT). Kevin Kofler How about qt-doc? Currently, it bundles src/qch/html docs, the src image files are completely useless and duplicate with files in html directory. The content of the qch and html docs is identical, since assistant_adp is dropped by qt 4.7, I suggest to split html docs into another subpackage or simply drop html docs. Personally, I only use assistant to open qch format docs. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Retire gstreamer-plugins-flumpegdemux in F14/devel?
sudo yum install gstreamer-plugins-flumpegdemux Package gstreamer-plugins-flumpegdemux-0.10.15-8.fc13.x86_64 is obsoleted by gstreamer-plugins-bad-free-0.10.19-1.fc13.x86_64 which is already installed Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in F-14
2010/8/5 Kevin Kofler kevin.kof...@chello.at: Bill Nottingham wrote: Orphan: nas gstreamer-plugins-bad-free requires nas-devel = 1.9.1-6.fc12 gstreamer-plugins-bad-free-extras requires libaudio.so.2 speech-dispatcher requires libaudio.so.2 speech-dispatcher requires nas-devel = 1.9.1-6.fc12 I suggest that these be just built without NAS support. NAS is basically an older competitor to PulseAudio with fewer features (it focuses on network transparency, which is just one of the things PulseAudio does), it is not compatible with PulseAudio, few to no people use it. Kevin Kofler -- Agree. nas is almost dead in upstream. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in F-14
It seems a lot of java packages will be orphaned, should we contact JAVA-SIG and maven2/eclipse/intellij-idea maintainers? Regrads, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: nonresponsive maintainer policy
2010/8/2 James Findley s...@gmx.com: On 07/30/2010 10:31 PM, Kevin Fenzi wrote: On Fri, 30 Jul 2010 16:28:11 +0200 Remember that some packages get very little activity because they need very little. Increasing someone's AWOLness counter because they didn't for example, update ed is just plain silly. If a package is no longer under heavy development, and is in a stage where releases happen very rarely if ever, and bugfixes are similarly rare, then what do you expect people to do? Reformat the spec file every three months so as to avoid the AWOL counter? Unless there are open bugs against a package with no activity from a maintainer, or it's way behind upstream (in which case there should probably be a bug open), the fact that nothing has happened in koji for three months isn't a problem. Lots of packages in Fedora are not bleeding edge GUI apps needing constant TLC. Please remember this when creating policies. Obviously, if upstream don't have a new release and the package itself doesn't have any security issue, then we don't need update it. However, I think tracking upstream in rawhide is necessary even they are command only packages. That's why gcc/glibc/coreutils in fedora rawhide are the latest version. Also, some packages which under active development are not updated for several years not just several months. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Wordpress testers needed!
2010/8/3 Jon Ciesla l...@jcomserv.net: Also I think that with wordpress 3 the separate wordpress-mu release fork has been merged into mainline. So wouldn't it be better to concentrate on wordpress 3? Well, yes, probably. That might even help with the bundled library situation. But that's an issue for the maintainer. I could help with that too, if needed. The wordpress owner said if someone with lots of PHP knowledge wants to take it I would be happy if it keeps getting maintained. in the last reply in fedora devel list. I think it will much much if we can update wordpress to 3.x. 2.8 branch is pretty old, and few people want to test it(2.9 is very mature now and 3.0 is also released a while ago). Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: unuran-1.7.1-1.fc14.x86_64 requires /sbin/install-info
2010/8/1 Neal Becker ndbeck...@gmail.com: I received this: unuran has broken dependencies in the F-14 tree: On x86_64: unuran-1.7.1-1.fc14.x86_64 requires /sbin/install-info unuran-1.7.1-1.fc14.x86_64 requires /sbin/install-info On i386: unuran-1.7.1-1.fc14.i686 requires /sbin/install-info unuran-1.7.1-1.fc14.i686 requires /sbin/install-info Please resolve this as soon as possible. unuran.spec says: Requires(post): /sbin/ldconfig, /sbin/install-info Requires(preun): /sbin/install-info Has something changed? -- Ignore it:) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: strange issue with dist-git/fedpkg
2010/7/31 Julian Sikorski beleg...@gmail.com: Dear all, I tried to make a chain build today: https://koji.fedoraproject.org/koji/taskinfo?taskID=2368385 For some reason, an ancient release was picked for goffice, and not the proper 0.8.8-1. Any thoughts? Julian -- Do you already push changes to the remote git repo? Try 'git status' Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Can anyone contact Balint Christian (rezso)?
2010/7/30 Patrice Dumas pertu...@free.fr: On Fri, Jul 30, 2010 at 03:01:11PM +0200, Mathieu Bridon wrote: First, I must say that Christian has usually not been very responsive to emails I wrote him, but it seems he just is usually very busy, as when he actually responded, he would respond several of my emails in a row. I have the same impression. So I think that having Christian as a co-maintainer, and not as the primary owner would be better. Another possibility would be to have more of a group ownership of GIS related softwares (a bit like netcdf based software some time ago). -- Pat -- It seems a considerable amount of packages in fedora don't update for years. I think we should add some policy to address those unmaintained packages, currently even provenpackager are not allowed to commit those packages diretly. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 branching and dist-git roll out
2010/7/30 Remi Collet fed...@famillecollet.com: Le 30/07/2010 01:07, Jesse Keating a écrit : https://fedoraproject.org/wiki/Using_Fedora_GIT We just might finish up before the 48 hour window is up! Thanks for that great work ! Just updated my first package. No issue :) Could be usefull to have a tips (in the wiki page) on how to apply change from a branch to another. I'm not a git expert, but I used fedpkg switch-branch f14 git cherry-pick -e xx git push origin f14:f14/master fedpkg build I don't know if this is the better solution, but it works. It seems I can't do this using fedpkg command. It seems there's a small bug in fedpkg, when we switch to a branch using 'fedpkg switch-branch', we can't use 'git push' directly. I think 'fedpkg switch-branch f14' should set up brancn f14/master instead of f14, otherwise we can't push changes easily. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
2010/7/30 Martin Sourada martin.sour...@gmail.com: On Thu, 2010-07-29 at 20:55 -0700, Jesse Keating wrote: snip Without the help of many others, this project would never have gotten done. Folks helped out with Koji modifications, with fedpkg contributions, with repeated testing of attempted conversions, with logic checking of my plans, of helping me understand more of git internals and deciphering error output, and most of all with being patient while we worked through the transition and very positive along the way. Things will be bumpy over the next few weeks as we really start putting distgit to the test. No amount of staging and testing can really replace production use. There will be many more updates to fedpkg as bugs are found and fixed and features are contributed. Wiki pages will get filled out as knowledge of how to interact with dist-git starts to spread ( https://fedoraproject.org/wiki/Using_Fedora_GIT is a good start ). Ok, so trying to update a package (libass) I've noticed a tiny problem: the fedpkg switch-branch does not seem to set up proper tracking of remote branches which then results in (uhm, I'm using git commit -a and git push, so you maybe handle this in fedpkg commit -p): pyfedpkg.FedpkgError: There are unpushed changes in your repo fedora-packager-0.5.0.1-3.fc12.noarch Martin -- I now use 'git checkout -t origin/f14/master' instead of 'fedpkg switch-branch f14' temporarily. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
2010/7/30 Martin Sourada martin.sour...@gmail.com: On Fri, 2010-07-30 at 09:49 +0100, pbrobin...@gmail.com wrote: Excellent news! Thanks for all the work. One thing I've never got around to working out how to do in git which is different from previous is dealing with branches. Where previously it was as simple as changing directories to deal with the various fedora releases obviously with real branches now we need to do something a little differnet. Could someone update the docs with details how to do this? I retried fedpkg switch-branch f-13 (and various other possible branch names) and using a git branch didn't give me any branches other than master. Could we also add some extra branch related commands to indicate things like listing the current branch, a list of all branches, and how we would commit a new spec to more than one branch. I'm not sure how it works if you do fedpkg clone -B libfoo, but probably similar to the CVS setup. If you do just fedpkg clone the branches are managed in git only so the fedpkg switch-branch f13 indeed switches you to f13 branch even though it looks like master ;-) Personally I use git merge branch-to-merge-from to sync the branches (if I have same spec for more than one branch). I think using git merge or git cherry-pick will be better than coping files from other branch like cvs, git is much smarter than cvs. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
2010/7/28 Frank Murphy frankl...@gmail.com: On 28/07/10 13:52, Mike McGrath wrote: snip Maybe as firefox4 available in updates-testing, but certainly not a core default package. +1 -- Regards, This is extremely complicated which means we can't push any xulrunner related packages to stable for a long time even for a security issue. Regard, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
2010/7/29 Conan Kudo (ニール・ゴンパ) ngomp...@gmail.com: On Wed, Jul 28, 2010 at 4:38 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2010-07-28 at 23:28 +0200, Martin Sourada wrote: Speaking of which, is there any chance to split ffmpeg into free (which could be included in fedora) and nonfree part? IIRC we've done something like that with xine-lib-extras and gst-plugins-bad in the past... ffmpeg, unfortunately, isn't set up to be modularised like this; you can't build an ffmpeg-free with the free codecs and an ffmpeg-patented with the patented ones and have them co-exist nicely. So an ffmpeg build with almost all the codecs ripped out in the Fedora repos would 'compete' with the full build in That Other Repo, not complement it, and the way the two repos are set up, it would be tricky to have a handicapped build in the Fedora repo and a full build in That Other One and have it easy for people to pick the one from That Other Repo (since Other Repo packages use the same disttag as Fedora ones). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net That is assuming that the other repo uses the same name as Fedora's. Fedora could call it ffmpeg-free, and the other repo could call it ffmpeg-nonfree, and have the nonfree one obsolete the free one. Simple fix, I think. -- The issue is who can split the patent free codecs from ffmepg? Obviously, ffmpeg upstream don't like this idea, maintaining a fedora specfic ffmepg isn't a easy job. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for Fedora 14?
2010/7/28 Filipe Rosset rosset.fil...@gmail.com: We was delayed in F-12 (two weeks) and in F-13 (two weeks), probably we'll have a final version for Firefox 4 before or a bit after we release F-14. Another thing, we can test a lot and assist in upstream during our testing phase. It's +1 for me. -- Filipe Rio Grande do Sul, Brazil -- Agree, shipping a RC version Firefox 4 for F14 is acceptable for me, F11 already shipped Firefox 3.5 beta4, it worked without any serious issues. I suggest to build Firefox 4 Beta for F15 shortly after F14 branched from Rawhide, if it works without any serious issues, then we can backport it to F14 Beta. Firefox 4 is definitely an amazing feature for Fedora 14. Regard, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
2010/7/27 Tom spot Callaway tcall...@redhat.com: On 07/19/2010 05:42 PM, M A Young wrote: On Wed, 7 Jul 2010, Tom spot Callaway wrote: [xen-maint] xen: xen-doc-4.0.0-2.fc14.x86_64 xen-libs-4.0.0-2.fc14.x86_64 xen-hypervisor-4.0.0-2.fc14.x86_64 I am a co-maintainer of the xen package, and I am trying to work out what the best way to comply with these changes since xen is rather a mess of licenses - I count 25 files or symbolic links called COPYING or LICENSE in the unpacked source and the base level COPYING file talks about license conditions at the head of some files. They all seem to be basically GPL, LGPL or BSD with one case of The Artistic License. Should I include all the COPYING or LICENSE files, one of each type of license (though some of the license files have different md5sums even when they claim to be the same license) or just the bottom level COPYING file? You're going to need to include all applicable license texts, sorry. ~spot -- If a GPL binary is compiled with mixed BSD and GPL source files, should we also add the BSD license text along with GPL text? Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: jack2
2010/7/20 Andy Shevchenko andy.shevche...@gmail.com: On Tue, May 11, 2010 at 6:17 PM, Orcan Ogetbil oget.fed...@gmail.com wrote: For F-13 it may be a little late. So shall we make this an F-14 target? I see new commit to the koji. Thanks for working on jack2, but the question is why the package name is jack-audio-connection-kit? As far as I know the package name should be derived from the main tarball name. -- With Best Regards, Andy Shevchenko -- Package name jack conflicts with some other opensource softwares, it'll better to persuade jack-audio-connection-kit upstream to avoid of using jack as package name. FYI, debian use jackd2 as package name for jack-audio-connection-kit 2. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Naming issue for meego 1.0 related packages
2010/7/11 pbrobin...@gmail.com pbrobin...@gmail.com: I don't agree with the easier, and the releases are all built on tags. Well someone will have to get the policy added to the packaging guidelines. There's guidelines for using VC repos but not for using tar files from other distros source packages. Peter It seems no guideline forbid us to use tarballs extracted from upstream repo. I think using git repo for meego packages have more harm than benefit, because the most important feature for rpm is people can validate the md5sum of the source tarball easily. Unless special case we can't find a way to get reliable souce tarballs, I think it's better to use tarballs rather than get source files from VCS. Meego repo is reliable place to get source tarballs, they also have bugzilla against those modules and they are the upstream. Also, it seems some meego packages don't have a public VCS(e.g. fennec-qt) or public VCS is not active currently(e.g. scim-panel-vkb-gtk[1]). Meego 1.0 use scim-panel-vkb-gtk 0.1.7, meego 1.1 use 0.1.8. but the latest version in the git repo is 0.1.6. [1]https://bugzilla.redhat.com/show_bug.cgi?id=615047 Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Naming issue for meego 1.0 related packages
2010/7/12 Kevin Kofler kevin.kof...@chello.at: Michel Alexandre Salim wrote: I experienced this recently with another project (openSUSE's build service client) -- GitHub lets you download a project's tagged snapshots as tarballs, but Gitorious does not have this functionality. But on-demand autogenerated tarballs are evil because they usually don't have reproducible checksums, so there's no straightforward way to verify that the tarball has not been altered. Kevin Kofler The autogenerted tarballs from original moblin VCS[1] are not evil :), they have a permanent checksums. Unfortunately, meego moved all packages to gitorious which don't have the same feature. So I suggest to use tarballs extracted from upstream SRPM[1] instead of pulling source files directly from VCS to be easier for checking md5sum. Is it forbidden by fedora packaging guideline? When we keep consistent with upstream RPM version, we can also report some bugs to meego bugzilla directly. [1]http://git.moblin.org/cgit.cgi/scim-panel-vkb-gtk/ [2]http://repo.meego.com/ Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Naming issue for meego 1.0 related packages
2010/7/16 Mattias Ellert mattias.ell...@fysast.uu.se: fre 2010-07-16 klockan 18:26 +0800 skrev Chen Lei: I think using git repo for meego packages have more harm than benefit, because the most important feature for rpm is people can validate the md5sum of the source tarball easily. Unless special case we can't find a way to get reliable souce tarballs, I think it's better to use tarballs rather than get source files from VCS. This is not a valid argument. The guidelines specify how to document in the specfile how to reproduce a source tarball created from VCS. The reviewer in order to verify the source recreates the source using the given specification and compares his created copy with the one in the SRPM. I agree that this comparison would normally have to be done using diff -r rather than md5sum due to timestamps of directories and differences in user and group assignments of the checked out files, but the verification is still possible and valid. Mattias Yes, it's no wrong to pull source from VCS, we can compare source files using diff -r, but it's not as easy as checking md5sum. Meego project have dozens of specific packages, it's not convenient to check source files for so many packages, also there are some packages don't have proper tags in meego VCS. Meego repo is a reliable place to get source and also the upstream, we don't have any security problem when using source files from upstream repo. If we have a easy way to get source files why we still use a hard way. Regrads, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Naming issue for meego 1.0 related packages
2010/7/16 Colin Walters walt...@verbum.org: But verifying a git tag is really easy too. I just disagree with you; if tarballs are provided, fine - if they aren't, it's trivial to use archives of git tags. -- Is there a script to help us to verify and pull sources from git repo? Meego project have dozens of packages(or maybe nearly one hundred packages), most of them don't provide tarballs at all except tarballs extracted from upstream SRPM. Also, some of them don't have a proper tag in the git repo or git version is older than SRPM version. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should GnuPG 1.4.x be revived?
2010/7/13 Daniel P. Berrange berra...@redhat.com: On Tue, Jul 13, 2010 at 09:57:38AM +0100, Andrew Haley wrote: On 07/13/2010 09:54 AM, Karel Klic wrote: Hi, several users of Emacs and one user of Vim complained in rhbz#574406 [1] that they can no longer use their editor to open and edit gpg-encrypted files in Fedora 13. The reason is that GnuPG 1.4 was deprecated after Fedora 12 release, and GnuPG 2 was introduced to replace it. However, GnuPG 2 is not entirely compatible with GnuPG 1.4. I looked at GnuPG 2 and it seems that it would be very difficult to modify Emacs and Vim to support it. GnuPG 2 does not allow to enter a password using shell -- it needs entire terminal (as it uses ncurses program pinentry-curses). Text editors can use only shell to send a password to GnuPG. What about reviving GnuPG 1.4? It is maintained, secure, supported, and its integration into text editors is used extensively and works well. It can live alongside GnuPG 2. What do you think? Any idea how to solve this issue? This one really must be addressed upstream. It's absurd that GnuPG doesn't work with GNU Emacs. If needs be, Richard Stallman is quite capable of knocking the maintainers' heads together. That is certainly the good approach to get a long term solution for Fedora, but it isn't much use for people using Fedora 13 today who have broken gpg support. It sounds like a compat-gnupg14 package is a reasonable approach to fixing this in Fedora 13 stable, and likely also Fedora 14 if upstream don't get their act together quickly enough for that release. Regards, Daniel -- No need to introduce a new compat-gnupg14 package, simply revive gnupg in koji is enough. http://koji.fedoraproject.org/koji/packageinfo?packageID=453 gnupg 2.x is named as gnupg2 in fedora. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should GnuPG 1.4.x be revived?
2010/7/14 Brian C. Lane b...@redhat.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/13/2010 05:38 AM, David Shaw wrote: On 07/13/2010 09:54 AM, Karel Klic wrote: several users of Emacs and one user of Vim complained in rhbz#574406 [1] that they can no longer use their editor to open and edit gpg-encrypted files in Fedora 13. The reason is that GnuPG 1.4 was deprecated after Fedora 12 release, and GnuPG 2 was introduced to replace it. However, GnuPG 2 is not entirely compatible with GnuPG 1.4. I looked at GnuPG 2 and it seems that it would be very difficult to modify Emacs and Vim to support it. GnuPG 2 does not allow to enter a password using shell -- it needs entire terminal (as it uses ncurses program pinentry-curses). Text editors can use only shell to send a password to GnuPG. What about reviving GnuPG 1.4? It is maintained, secure, supported, and its integration into text editors is used extensively and works well. It can live alongside GnuPG 2. No disagreement here in that GnuPG (of whatever version) should work with Emacs and vim. That should be fixed. However, as a GnuPG developer, I'd like to suggest another reason for keeping both GnuPG 1.x and 2.x: although there is significant overlap, they're not really aimed at the same problem. 1.x is aimed at servers where its all in one construction simplifies things, or in embedded systems or other places where space is tight. Some people also prefer the smaller and more easily reviewed code base and thus use 1.x as their desktop GnuPG. The version numbering is unfortunate in that it suggests that 2.x replaces 1.x, but in reality, the 1.x branch is a maintained product on its own. 1.x and 2.x are designed to be able to be installed together if necessary (note that the upstream code generates a binary named gpg2 - the gpg binary in F13 is due to a local patch). This was done very well in F11. This is why I'm so surprised to see gpg be deprecated in f13. Upstream is supporting both and the manpage even indicates that the binary should be gpg2. I don't see any reason for it to have been removed in f13, and am willing to help maintain it. I've been a pgp and gpg user since the early 90's, I attempted to port pgp to the Atari ST (unsuccessfully I should note :) ) at one time. - -- Brian C. Lane b...@redhat.com Please fill a Review Request for gnupg in bugzilla, if no one opposes reviving gnupg in koji . Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Naming issue for meego 1.0 related packages
2010/7/10 pbrobin...@gmail.com pbrobin...@gmail.com: On Fri, Jul 9, 2010 at 5:28 PM, Chen Lei supercyp...@gmail.com wrote: 2010/7/9 pbrobin...@gmail.com pbrobin...@gmail.com: I think it's not easy to persuade upstream to do so. Look deep at meego-panel-zones, the HEAD version in git repo is 0.2.0[1], however upstream rpm indicates the lastest version for this package is 0.2.1[2], maybe they also have a internal VCS because obviously 0.2.1 is newer than 0.2.0, 0.2.1 fixs some bugs in 0.2.0(e.g. rename meego.org to meego.com) In most cases most of their minor releases are often a single commit. I'm meeting up with a lot of the NetBook UX guys for beer tonight.. :-) I know they don't have internal VCS and I suspect either there's a single commit difference or someone forgot to push their local git. Most of the team are generally very responsive and are all active contributors to other upstream gnome technology. This is also a reason why I think relying on git tag to get source files is unsafe. Many packages in gitorious don't have a proper tag, especially small packages which only have a few committers. It'll be much better to keep close with upstream and don't create unnecessary divergence. I'm not sure if meego will provide tarballs in the future, the fact I found is all memeo and qt packages in gitorious.org don't provide tarballs in git repo(a few of them release tarballs in project website e.g. qt4, pyside), maybe this is limited by the infrastructure. Using tarballs without valid URL is not forbidden by packaging guideline[3], I think using tarballs extracted from upstream SRPM is much easier for reviewers when considering md5sum checking in package review. Also, the git source is premature, normally we need autoconf/automake to build those packages which is not needed for tarballs from SRPM. So I suggest you to use tarballs extracted from upstream SRPM, I already packaged some qt-related packages for meego 1.1, I found sometimes it's very hard to find the exact git SHA1 for a particular upstream version. Yes, but most of the Netbook side of things are from Moblin. Also if you look at a lot of the clutter/mx and other stuff they now do make tarballs and in some cases only in the last weeks. Don't rule it out. After all they cut tar files for the rpms, all they have to do it publish them separately. In the Moblin case it was just resources that stopped them originally and they eventually started to do it. Historically, moblin VCS have the function of making tarballs automatically, but they don't publish them to some other places for downloading. Meego moved all those packages to gitorious now, it seems like gitorious don't have the same function, so I think we can hardly assume meego will publish all tarballs soon based on the fact that a few widely-used packages(e.g. clutter mx qt pyside) in gitorious release tarballs publicly now. By the way, those well-known packages don't belong to meego project now, they all have seperate website. Except there's a change in the infrastructure of gitorious, I think using tarballs from upstream's SRPM is a better choice than pulling source from git repo directly. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Naming issue for meego 1.0 related packages
Hi all, I intend to review two meego-related packages[1][2], but I'm confused with which package name will be more appropiate. [1]https://bugzilla.redhat.com/show_bug.cgi?id=610794 [2]https://bugzilla.redhat.com/show_bug.cgi?id=610842 The packager is determined to package meego 1.0 packages for F14 which means we need to package old versions instead of latest upstream version. Meego 1.0 still use old package name moblin-* the same as moblin 2.1 for all of its packages. Howerver, upstream renamed all of those package to meego-* in meego 1.1 which will be released in Oct. 2010. I want to ask if it's appropiate to use new package name meego-* instead of moblin-* for meego 1.0 packages. e.g. meego-panel-devices Upstream uses moblin-panel-devices[3] in meego 1.0, but renamed it to meego-panel-devices[4] in meego 1.1. If we intend to package version 0.1.30, then which name will be more appropriate? [3]http://repo.meego.com/MeeGo/releases/1.0/netbook/repos/source/moblin-panel-devices-0.1.30-1.1.src.rpm [4]http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.9.20100706.1/netbook/repos/source/meego-panel-devices-0.2.1-1.2.src.rpm Note: It seems upstream will not rename those packages to meego-* in meego 1.0. From http://meego.gitorious.org/meego-netbook-ux/meego-panel-devices/blobs/meego-1.0/configure.ac AC_PREREQ(2.53) AC_INIT([moblin-panel-devices], [0.1.34], [http://bugs.meego.com]) Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Naming issue for meego 1.0 related packages
2010/7/9 pbrobin...@gmail.com pbrobin...@gmail.com:
Hi Chen,
As I'm the MeeGo maintainer let me outline my thoughts and reasoning
behind my MeeGo strategy.
I intend to review two meego-related packages[1][2], but I'm confused
with which package name will be more appropiate.
[1]https://bugzilla.redhat.com/show_bug.cgi?id=610794
[2]https://bugzilla.redhat.com/show_bug.cgi?id=610842
All moblin packages will be renamed to meego. Whether that is all
during the F-14 timeframe or isn't completed until F-15 I'm not sure
yet. All new packages I intend to call meego as I don't see the point
in reviewing them now and renaming them in a month or two, possibly
less.
The packager is determined to package meego 1.0 packages for F14 which
means we need to package old versions instead of latest upstream
version. Meego 1.0 still use old package name moblin-* the same as
moblin 2.1 for all of its packages. Howerver, upstream renamed all of
those package to meego-* in meego 1.1 which will be released in Oct.
2010.
No I'm not determined to package MeeGo 1.0 for F-14. So please don't
change what I have said. In the short term I plan to package MeeGo 1.0
for the alpha so that there is something for people to start testing
with. There's currently very little in the MeeGo 1.1 release and
there's a lot of churn due to the renaming upstream which is and will
cause us problems. So once F-14 alpha is out and the F-14/rawhide
branch has taken place I can then do all the rename breakage in F-15
and get the 1.1 package deps shake up stabilized there while people
can continue to test some stuff in MeeGo 1.0 in the F-14 branch where
its hopefully slightly stable and some of the other things that have
changed from Moblin 2.1 to 1.0 have changed and can be closely tested.
Once MeeGo 1.1 in F-15 rawhide is OK and looking OK I can then build
and tag it quickly and simply into F-14.
I want to ask if it's appropiate to use new package name meego-*
instead of moblin-* for meego 1.0 packages.
e.g.
meego-panel-devices
Upstream uses moblin-panel-devices[3] in meego 1.0, but renamed it to
meego-panel-devices[4] in meego 1.1. If we intend to package version
0.1.30, then which name will be more appropriate?
[3]http://repo.meego.com/MeeGo/releases/1.0/netbook/repos/source/moblin-panel-devices-0.1.30-1.1.src.rpm
[4]http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.9.20100706.1/netbook/repos/source/meego-panel-devices-0.2.1-1.2.src.rpm
Note:
It seems upstream will not rename those packages to meego-* in meego 1.0.
No, but that was due to time and QA in the lead up to release. We
don't need to follow 100% what they do and I don't see the point in 2
package reviews for the one package in less than a month. The upstream
git even for the 1.0 release is called meego, its clearly stated in
the upstream the direction the package names are going so I don't see
what the issue is.
Peter
--
Sounds reasonable to me, but the version you packaged actually are
still moblin-* [1] instead of meego-* regardless of what repo names
they use, it's unacceptable under most circumstance.
[1]http://pbrobinson.fedorapeople.org/meego-panel-zones.spec
%files -f moblin-panel-zones.lang
%defattr(-,root,root,-)
%doc COPYING README
%{_libexecdir}/moblin-panel-zones
%{_datadir}/dbus-1/services/org.moblin.UX.Shell.Panels.zones.service
%{_datadir}/mutter-moblin/panels/moblin-panel-zones.desktop
%{_datadir}/moblin-panel-zones/
Another thing confused me is why you want to use git snapshot instead
of upstream tarball in src.rpm. It seems like you rely on the git SHA1
on the particular tags in the meego 1.0 branch, but it's very hard to
track upstream in this way.
e.g. meego-panel-zones
The latest tag in meego 1.0 branch is 0.1.18[2] which is also the
version you choose to package. Howerver, upstream repo version for
meego 1.0 is 0.1.19[3] which don't have a tag in meego 1.0 branch.
Things become much worse if we look at meego 1.1, the latest git tag
is also 0.1.18[4], but upstream repo already update meego-panel-zones
to 0.2.1[5].
[2]http://meego.gitorious.org/meego-netbook-ux/meego-panel-zones/commits/meego-1.0
[3]http://repo.meego.com/MeeGo/updates/1.0/netbook/repos/source/moblin-panel-zones-0.1.19-3.3.src.rpm
[4]http://meego.gitorious.org/meego-netbook-ux/meego-panel-zones/trees/master
[5]http://repo.meego.com/MeeGo/builds/trunk/1.0.80.9.20100706.1/netbook/repos/source/meego-panel-zones-0.2.1-2.2.src.rpm
Historically, moblin released tarballs for its packages in public git
repo, but memeo and meego don't release tarball publicly. I think we
have to use tarballs in the src.rpm for meego specfic packages.
Regards,
Chen Lei
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
2010/7/8 Tom spot Callaway tcall...@redhat.com:
On 07/08/2010 04:12 AM, Michael Schwendt wrote:
On Wed, 07 Jul 2010 16:29:01 -0400, Tom wrote:
However, if a subpackage is independent of any base package (it does
not require it, either implicitly or explicitly), it must include
copies of any license texts (as present in the source) which are
applicable to the files contained within the subpackage.
With this we've reached the point once more where the default %doc dir is
a poor choice, because it is based on the subpackage's %{name} instead of
the src.rpm's or base package's %{name}.
For the common tools'n'library split of a package, the changed guidelines
duplicate the license files by storing them in two different directories
when using %doc:
/usr/share/doc/name-1.0/COPYING
/usr/share/doc/name-libs-1.0/COPYING
Yes, I absolutely understand that. The intent is to minimize this by
leveraging dependencies (tools depends on libs). A common, system-wide
directory for license files to be dropped into is a recipe for disaster
(COPYING conflicts with COPYING).
Dose this mean we only need to add license text to -libs subpackage
instead of base package if we assume the base package depends on -libs
subpackage?
Chen Lei
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
2010/7/8 Jakub Jelinek ja...@redhat.com: Generally, much better speedup can be achieved by using PGO (-fprofile-generate, run on some testsuite, -fprofile-use). GCC itself is built that way for several years, but it would be useful if other performance sensitive packages were built that way too, assuming they have some testsuite which resembles common use. E.g. bash can be easily trained on some configure or some other large shell scripts, similarly for python, perl, ... The speedups from this can go up to say 30% or so. Jakub -- It seems MeeGo builds core packages by using PGO already. Is there anyone who would like to volunteer to write a packaging guideline about using PGO? Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Can anyone contact Gérard Milmeister (gemi)?
2010/7/7 Christopher Brown snecklif...@gmail.com: If you need a co-maintainer for this please let me know. I need scons as a build tool for one of my packages. Thanks -- Christopher Brown -- Feel free to contact Gérard directly to add you as a co-maintainer of scons :) Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Can anyone contact Gérard Milmeister (gemi)?
2010/7/6 Gérard Milmeister g...@bluewin.ch: Hi, I am still alive. I had always hoped to find the time to resume work on the packages, however it turned out that circumstances do not allow me any leisure anymore for serious participation (at least for now). So I would be glad if people take over packages, especially those that require some work. I will try to follow the mailing-list for the next days. Regards and sorry for the trouble, Gérard I'm very happy that you are still involved in Fedora, I'll maintain scons temporarily before you have enough time to resume work on Fedora :) Do you mind to find more co-maintainers for your packages before you come back? Regrads, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Can anyone contact Gérard Milmeister (gemi)?
2010/6/18 Chen Lei supercyp...@gmail.com: Hi all, Following the process https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers Is someone able to get in touch with Gérard Milmeister.(gemi) I can't find any activity of him from koji and bugzilla in the past eight months, I also got no response from him after sending a private mail a month ago. See https://bugzilla.redhat.com/show_bug.cgi?id=530565 for more details. Regards, Chen Lei Hi FESCo, Can we orphan his packages now? I'd like to take scons, I don't think waiting more time will be helpful. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ember, xmllint and error propagation in F-13 vs F-14?
2010/7/4 Michel Alexandre Salim michael.silva...@gmail.com: I just fixed an ImplicitDSOLinking FTBFS for ember, but noticed that it's still not building in Rawhide due to xmllint validation errors in %check. The odd thing is, up to F-13 the same checks fail, but for some reason the failure does not generate an error number that is propagated back to rpm, and the build succeeded. Anyone has any idea why this happens? ember package owners, I'll leave it up to you to either disable %check or to update Rawhide to the latest 0.5.8 (for which a bug is already opened) Fedora 13 build (succeeds, though %check should have failed): http://koji.fedoraproject.org/koji/buildinfo?buildID=181473 Rawhide build (correctly failing): http://koji.fedoraproject.org/koji/buildinfo?buildID=181470 Thanks, -- Michel -- It looks like the owner is non-responsive in koji and bugzilla for more than 8 months. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: concept of package ownership
2010/7/3 Michael Schwendt mschwe...@gmail.com: On Sat, 03 Jul 2010 03:40:57 +0200, Kevin wrote: It is part of the Fedora Objectives: https://fedoraproject.org/wiki/Objectives to be on the leading edge of free and open source technology. Given that, it is completely unacceptable to not upgrade software to the current release in Rawhide (within a reasonable timeframe, of course we're all not available 24/7) unless there's a really good reason to (in which case that reason ought to be given in the bug report asking for the upgrade!), especially when upstream is asking for their software to be upgraded. So the maintainer's decision (assuming there even WAS a decision rather than just lack of time or worse) goes against Fedora's Objectives and so it's not OK to say that it should just get accepted. We should really be more aggressive about allowing to upgrade other people's packages in Rawhide if the maintainers don't do it within a reasonable timeframe and don't document any good reason not to do the upgrade. Ridiculous. :( The way you've phrased it doesn't meet the be excellent guidelines IMO. There is nothing completely unacceptable or against Fedora's objectives with skipping certain upstream releases. And I hope that nobody will become more aggressive or try to force me (or other packagers) to upgrade packages. I don't want anyone among the Fedora contributors to be aggressive in any way when talking to me or when trying to make me do something. As a user or fellow packager [or upstream developer], you are free to suggest upgrades in a bugzilla ticket. And hopefully you evaluate the new release to examine it for changes compared with the previous release in Fedora, so you can give a rationale for your upgrade request. If you meet resistance, you'll have to live with that or return with a competent mediator. I'm fully agree with you, but there are some maintainers who don't respond on bugzilla at all or for a very long time. They may be still active on koji, but they don't respond even when you attach a patch/spec to solve known issues or request for co-maintainership. Obviously, they cannot be defined as nonresponsive package maintainers, so we have no process/policy to treat those packages. I filled dozens of reports in bugzilla to request for updating long unmaintained packages(more than 3 years) several months ago, no packager respond yet. Regards. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
2010/7/2 Chitlesh GOORAH chitlesh.goo...@gmail.com: Hello there, I would appreciate if someone else who is NEITHER a co-maintainer NOR FESCo member don't version bump my packages, without notifying me. It looks like Petr Pisar just fixed some FTBTS bugs in rawhide after mass-rebuiding of all perl-related packages. If he done anything wrong to violate fedora packaging guideline, you can point them out, otherwise I don't think it's a serious problem for fixing FTBTS bugs before notifying particular maintainers. See https://fedoraproject.org/wiki/Features/perl5.12 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: concept of package ownership
2010/7/2 Patrice Dumas pertu...@free.fr: On Fri, Jul 02, 2010 at 02:23:43PM +0200, Peter Czanik wrote: 2010-07-02 03:18 keltezéssel, Kevin Kofler írta: I think we need to get rid of the concept of ownership entirely, that'd also make orphaned or de-facto orphaned packages less of a problem. You see a problem, you fix it. Who cares whether the package has an active maintainer or not? That's very much against the fedora policies. I'd like to get syslog-ng updated to the latest version in Rawhide (I work part time for the upstream developer and I'm also an occasional Fedora user). I contacted the package owner, no response. Created a bugreport to get it updated ( https://bugzilla.redhat.com/show_bug.cgi?id=598961 ), and also provided an updated package, which compiles and works fine on Fedora 12, 13 and Rawhide. After waiting for weeks, I started a maintainer time out. It was closed within an hour. Indeed. Maintainer time out are for completly missing maintainers, not to force them to apply a change. Obviously I'm not a proven packager to update the package myself, as I'm not a Fedora developer. Even if you were a provenpackager you would be forbidden from doing that. Provenpackagers right to modify other people packages are far from being that large. Have a look at the relevant policy if you want more information. I worked a lot to update and test the package, but still I'm stuck. And as you can see, the maintainer timeout procedure does not help either... And the provenpackager policy wouldn't help either. In the past we proposed a policy for that kind of issues with Rahul, but it was never approved (nor really considered). http://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance The only thing that can be done, right now for such issues is the traditional escalation procedure. I don't know if it is documented anywhere, but it is along * make yourself clear in a bugreport (which is already done) * explain the issue on the devel list (guess you already did that) * escalate to FESCo -- I think escalating to FESCo is only suitable for changes which are controversial between different people, we should have another policy to treat those non-responsive issues, maintainers should respond on bugzilla report in time. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg-turbo conflicts in rawhide
2010/7/1 Adam Tkac at...@redhat.com: On Tue, Jun 29, 2010 at 11:31:45PM -0400, Rich Mattes wrote: Hi all, Hello, I'm trying to build a package that has a BuildRequires: libjpeg-devel in Rawhide [1]. I get a message in root.log that libjpeg-turbo-devel obsoletes libjpeg-devel, so yum pulls in libjpeg-turbo-devel instead. Unfortunately, when it pulls in dependencies for my other BuildRequires, it's trying to pull in libjpeg and libjpeg-turbo, and I get a conflict since they both provide libjpeg.so.62.0.0 The only thing I can think of is that one of the packages I'm requiring has an explicit dep on libjpeg (I'm about to investigate which). For the time being, is there any to work around this? I read this thread and https://bugzilla.redhat.com/show_bug.cgi?id=609224 and I see two reasonable solutions for this problem: 1. Add Obsoletes/Provides libjpeg directly to libjpeg-turbo package which contains only libjpeg.so.62*. I believe this will solve both update and buildroot problems. However it also means all users of libjpeg programs (djpeg, cjpeg and friends) will need to manually install libjpeg-turbo-tools 2. Merge both libjpeg-turbo-utils and libjpeg-turbo to one package, as done in libjpeg. I must admit I like the first solution. People usually needs only libjpeg.so, not programs. People which need libjpeg programs can easily install libjpeg-turbo-tools package themselves, this incompatibility seems acceptable for me in development branch. What is your opinion about this proposal? Regards, Adam -- Only three packages in the rawhide depend on -utils: renrot gallery2-jpegtran gocr Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg-turbo conflicts in rawhide
2010/6/30 Rich Mattes richmat...@gmail.com: Hi all, I'm trying to build a package that has a BuildRequires: libjpeg-devel in Rawhide [1]. I get a message in root.log that libjpeg-turbo-devel obsoletes libjpeg-devel, so yum pulls in libjpeg-turbo-devel instead. Unfortunately, when it pulls in dependencies for my other BuildRequires, it's trying to pull in libjpeg and libjpeg-turbo, and I get a conflict since they both provide libjpeg.so.62.0.0 The only thing I can think of is that one of the packages I'm requiring has an explicit dep on libjpeg (I'm about to investigate which). For the time being, is there any to work around this? Thanks, Rich [1]: http://koji.fedoraproject.org/koji/taskinfo?taskID=2282066 -- See https://bugzilla.redhat.com/show_bug.cgi?id=607554 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg-turbo conflicts in rawhide
2010/6/30 Michael Schwendt mschwe...@gmail.com: On Wed, 30 Jun 2010 14:04:51 +0800, Chen wrote: 2010/6/30 Rich Mattes richmat...@gmail.com: Hi all, I'm trying to build a package that has a BuildRequires: libjpeg-devel in Rawhide [1]. I get a message in root.log that libjpeg-turbo-devel obsoletes libjpeg-devel, so yum pulls in libjpeg-turbo-devel instead. Unfortunately, when it pulls in dependencies for my other BuildRequires, it's trying to pull in libjpeg and libjpeg-turbo, and I get a conflict since they both provide libjpeg.so.62.0.0 The only thing I can think of is that one of the packages I'm requiring has an explicit dep on libjpeg (I'm about to investigate which). For the time being, is there any to work around this? Thanks, Rich [1]: http://koji.fedoraproject.org/koji/taskinfo?taskID=2282066 -- See https://bugzilla.redhat.com/show_bug.cgi?id=607554 Why doesn't libjpeg-turbo contain the proper Obsoletes for libjpeg? Only libjpeg-turbo-devel does it correctly for libjpeg-devel and libjpeg-static. That's only half of the show. libjpeg-turbo is meant to replace libjpeg, so it should obsolete it. And if it also added the Provides, there would be no need to rebuild dependencies, but considering that this is Rawhide, okay if it doesn't add the Provides. -- libjpeg is split into libjpeg-turbo and libjpeg-turbo-utils, Obsoletes libjpeg is already added to libjpeg-turbo-utils. I don't know why Rich's package failed to build on koji, the problem is a bit weird. Among 5 packages which require libjpeg explicitly, only java-1.6.0-openjdk will be used as a BR, however Rich's packages is irrelevant to java. FYI, provides libjpeg is also add to libjpeg-turbo-utils now, I don't know if it can solve the file conflicts. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg-turbo conflicts in rawhide
2010/6/30 Rich Mattes richmat...@gmail.com: I played with it a little bit more last night, the problem occurred when my package pulled in graphviz. Graphviz has a BR:libjpeg-devel, and makes no mention of libjpeg-utils. It only relies on libjpeg for the libraries, and doesn't need any of the utils (my package only uses libjpeg's libraries as well). I guess since libjpeg-turbo didn't obsolete libjpeg, graphviz was quite happy pulling in libjpeg instead of libjpeg-turbo. Rich -- I think It's a bug of yum-builddep, libjpeg is obsoleted by libjpeg-turbo-utils, and graphviz don't depends on libjpeg explicitly, I don't know how libjpeg can be pulled in. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg-turbo conflicts in rawhide
2010/6/30 Michael Schwendt mschwe...@gmail.com: On Wed, 30 Jun 2010 17:21:37 +0800, Chen wrote: libjpeg is split into libjpeg-turbo and libjpeg-turbo-utils, Obsoletes libjpeg is already added to libjpeg-turbo-utils. root.log of http://koji.fedoraproject.org/koji/taskinfo?taskID=2282066 doesn't refer to libjpeg-turbo-utils at all, but just libjpeg *and* libjpeg-turbo. -- It's weird, libjpeg is already obsoleted. See http://koji.fedoraproject.org/koji/rpminfo?rpmID=2040484 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg-turbo conflicts in rawhide
2010/7/1 Bruno Wolff III br...@wolff.to: On Wed, Jun 30, 2010 at 12:10:11 -0500, Rex Dieter rdie...@math.unl.edu wrote: Another wrinkle here is both libjpeg and libjpeg-turbo existing in rawhide/repo. Shouldn't libjpeg get removed now? Doing so should help matters too. If someone looks at that, they might also want to look at dropping 'man' which is in a similar situation (obsoleted, but still hanging around). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel libjpeg should be removed before mass-rebuild, because libjpeg-turbo provides: libjpeg-6b-47, the current libjpeg in the repo provides libjpeg-6b-46. I think there are no perfect solution for renaming/splitting packages, we should fix those broken dependencies finally instead of staying on workaround. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc: python2.7 for F14
2010/6/22 David Malcolm dmalc...@redhat.com: On Tue, 2010-06-22 at 08:40 +0200, Thomas Spura wrote: Am Mon, 21 Jun 2010 14:34:02 -0400 schrieb David Malcolm dmalc...@redhat.com: On Tue, 2010-06-22 at 01:57 +0800, Chen Lei wrote: Thanks, that's a great help - I hadn't seen that page. Looks like an excellent starting point. We need to look at all built (sub)packages with a requires of python(abi) = 2.6, figure out the set of src.rpms they come from, and we'll want to rebuild those once 2.7 is in f-14 in Koji. Dave -- I think Mass Rebuild the whole repo will be much easier than the packages which requires on python(abi) =2.6(nearly 1/10 packages in the repo related to python). Since gcc 4.5 is released for several months, it definitely will be used in F14, so I suggest asking Jakub first to see if it's possible to push gcc 4.5 to the repo along with python 2.7 soon. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: move libusb from /usr/lib to /lib
2010/6/23 Jan Vcelak jvce...@redhat.com:
Hi,
I would like to move libusb library from /usr/lib to /lib.
Some services might require the library when /usr is not mounted. e.g. nut
(UPS management daemon, bz #453704) needs it at shutdown time.
If course, I would like to refrain from any trouble it can bring. If you
think, that moving the library is a bad idea, or that it will break your
package, please, let me know.
I'm going to move libusb and libusb1 as well. And I will create symlinks in
/usr/lib for them.
The bug is already filed for this, #519716.
Any comments and suggestions are welcomed.
Thanks.
Regards,
Jan
--
You can simply move all *.so.* files to /%{_lib}, then create symlinks
in /usr/lib for *.so files in -devel subpackage.
See
http://koji.fedoraproject.org/koji/rpminfo?rpmID=2025071
http://koji.fedoraproject.org/koji/rpminfo?rpmID=2025072
Also, you need notice libguestfs maintainer first, because this change
will break this special package.
Regards,
Chen Lei
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc: python2.7 for F14
2010/6/22 David Malcolm dmalc...@redhat.com: On Mon, 2010-06-21 at 13:19 -0400, Neal Becker wrote: I'm interested in python2.7 as a feature for F14. This will provide backports of some nice python3 features, but will work for those needing python2 environments. Many libraries are not available for python3 yet. https://fedoraproject.org/wiki/Features/Python_2.7 I've been working on it (though have been on holiday for a week) I hope to have the latest upstream 2.7 release candidate in rawhide later this week. This will require a rebuild of all Python modules. -- Why not rebuild all python modules along with gcc 4.5? It may avoid of rebuild python-related packages twice? Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update on packages violating the Static Library guidelines
util-vserver556099 - CLOSED FYI, util-vserver is re-enabled to ship static libraries again by the maintainer now after spot disabled it. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To construct a Zope skyscraper on Fedora
2010/6/21 Nathaniel McCallum nathan...@natemccallum.com: On 06/20/2010 05:42 AM, Robin 'cheese' Lee wrote: I suspect BlueBream solves our namespace issue; namely, the zope namespace will be zope2 only. Nathaniel -- Agree, all zope components won't have any namespace conflict issue now as I known. Packaging them as normal python modules is Okay, but since Zope2 contains more than 100 modules, packaging/maintaining so many modules is not easy work. Chen Lei Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To construct a Zope skyscraper on Fedora
2010/6/20 Nathaniel McCallum nathan...@natemccallum.com: We have a unique opportunity to address many of the failings of the current zope namespace. We should get anyone interested (and willing to do the work) into a meeting I think we should talk sooner rather than later. Anyone want to setup a meeting time? Just an FYI, it is my current plan (probably because I am completely ignorant as to how much pain this will cause) is to simply package the latest version of all Zenoss dependencies and then work through whatever bugs I find. I'm in a somewhat unique situation though in that I have the ability to commit to upstream. This may be a less than ideal plan for other applications. As I mentioned to Jonathan on IRC, I think the best plan is to try to get something working'ish as soon as possible and then try to shakedown the details from there. If we bog ourselves down in policy (an easy quagmire to get stuck in when in zopeland) we may get too discouraged to continue. Not to dismiss what will be the very needed policy, I just want to make sure no-one gets burned out. One thing we may want to consider is a tenant policy. That is, the zope stack as a whole has tenants (Zenoss, Plone, etc). The tenants would be formally defined and any upgrade to any component in the platform would require signoff from all the tenants who depend on that component (or some derivation thereof). I suspect that the short-term trade-off of buildouts/bundling is not as valuable as the long-term value of testing a software product across multiple versions of its dependencies. Nathaniel I still suggest to do enough investigation first for two reason: 1.Packaging the whole zope stack is a heavy workload( we need some tools to simply our works) 2.Currently. no linux distributions include zope yet. I think we need to set up a third party repo first like texlive 2010 before finally determined to submit those components for package review. Chen Lei ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: To construct a Zope skyscraper on Fedora
2010/6/20 Rakesh Pandit rakesh.pan...@gmail.com: Thanks for clarification. I will see whether I can help with some dependencies and zope3 part (review as well). -- -- The original zope/plone in Fedora/EPEL bundles dozens of third party python modules, nearly all of those modules need review if we want to revive long retired zope and plone in the cvs. It will be much easier if we have an atuomatic spec generation tool like cpan2spec, it's entirely possible to write a such tool for python modules that using setuptools in setup.py. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New Hatari version: need help
2010/6/20 Andrea Musuruane musur...@gmail.com: Hi all, a new version of Hatari has recently been released: http://hatari.berlios.de/ The new version drops the old build system based on autotools and now it only support cmake. An (optional) python GUI is now bundled with the emulator. Moreover some static libraries have been introduced and %cmake will output them as dynamic libraries because of -DBUILD_SHARED_LIBS:BOOL=ON is defined in the macro itself. I wonder if this package needs a new review request because of these changes. I do not know how should I threat those internal libraries. How should I package them? Because upstream uses static libraries the dynamic versions cmake creates are not versioned. The python UI by default places python files in /usr/share/hatari/hatariui/. Is this acceptable or should I patch it to place them in /usr/share/hatariui/ ? Thanks in advance for you advices. Regards, Andrea. -- You can open a RFE report against this package in bugzilla for review. For internal libs, if those libs are not libs from other project, you can simply use %cmake -DBUILD_SHARED_LIBS:BOOL=OFF to avoid generation of those shlibs. Default place for python ui don't need change. Chen Lei. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Can anyone contact Gérard Milmeister (gemi)?
Hi all, Following the process https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers Is someone able to get in touch with Gérard Milmeister.(gemi) I can't find any activity of him from koji and bugzilla in the past eight months, I also got no response from him after sending a private mail a month ago. See https://bugzilla.redhat.com/show_bug.cgi?id=530565 for more details. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: debuginfo for sub packages (Help with RPM SPEC files)
2010/6/16 Trever L. Adams trever.ad...@gmail.com: Hello everyone, I am having a hard time finding documentation which explains this. I have a spec file which generates several subpackages (-classify, -clamav, etc.). I have this working fine. The problem is I am only getting a debuginfo package for the main package. This contains all the information, but because of how things are named (installed) it doesn't work for debugging tools. How do I go about telling RPM via SPEC to separate the appropriate files into their own debuginfo package for each subpackageS? Thank you, Trever -- If it's there and you can see it, it's REAL If it's there and you can't see it, it's TRANSPARENT If it's not there and you can see it, it's VIRTUAL If it's not there and you can't see it, it's GONE! -- Unknown -- This is not needed under most circumstance, currently only kernel have serveral debuginfo subpackages. If you really want to do it, you can tweak find-debuginfo.sh, but such tweak is normally unaccepted in fedora except you have compelling reason. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
2010/6/9 Thomas Moschny thomas.mosc...@gmail.com: Hi, pidgin-2.7.1-2.fc13 obsoletes pidgin = 2.7.1-1.fc13, is that meaningful? At least it causes package-manager to display an irritating (and somehow bogus) warning box that it's going to remove pidgin, and needs confirmation for that. -- Thomas Moschny thomas.mosc...@gmail.com -- Yes, the obsoletes is necessary, if you don't add it, yum will only pull in pidgin-evolution. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
2010/6/9 Thomas Moschny thomas.mosc...@gmail.com: 2010/6/9 Chen Lei supercyp...@gmail.com: Yes, the obsoletes is necessary, if you don't add it, yum will only pull in pidgin-evolution. For which operation? Can you elaborate a bit? -- Thomas Moschny thomas.mosc...@gmail.com -- yum upgrade from 2.7.1-1 will only pull in new pidgin-evolution subpackage and del old pidgin if you don't add obsoletes. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
2010/6/9 Thomas Moschny thomas.mosc...@gmail.com: 2010/6/9 Chen Lei supercyp...@gmail.com: Yes, the obsoletes is necessary, if you don't add it, yum will only pull in pidgin-evolution. For which operation? Can you elaborate a bit? -- Thomas Moschny thomas.mosc...@gmail.com -- But in this case, the obsoletes seems excessive, since pidgin-evolution already depends on pidgin. If pidgin-evolution don't depend on pidgin, the obsoletes is a must, without it pidgin will be replaced by pidgin-evolution. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
2010/6/9 Michael Schwendt mschwe...@gmail.com: On Wed, 9 Jun 2010 17:15:01 +0800, Chen wrote: 2010/6/9 Chen Lei: Yes, the obsoletes is necessary, if you don't add it, yum will only pull in pidgin-evolution. For which operation? Can you elaborate a bit? yum upgrade from 2.7.1-1 will only pull in new pidgin-evolution subpackage and del old pidgin if you don't add obsoletes. http://koji.fedoraproject.org/koji/rpminfo?rpmID=1996754 Competing Obsoletes once again. The packager is playing with fire. -- I test yum several days ago, if we split foo package into into foo and bar, we must add obsoletes to both subpackages. When we type yum upgrade, old foo will be replaced by new foo and bar. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
2010/6/10 Michael Schwendt mschwe...@gmail.com: On Wed, 9 Jun 2010 15:38:48 +0100, Stu wrote: I implemented it based on recommendations on the yum wiki that I saw someone else referred to in #fedora-devel : http://yum.baseurl.org/wiki/YumPackageUpdates#Packagesplit Well, that's exactly an example where the two Obsoletes compete with eachother. It works only partially. For an ordinary Yum update. It fails for a Yum install. I warn about such competing Obsoletes, because they strictly require the user to go the yum -y update ; yum install ... route everytime they want to install an additional package. When talking to some packagers related to broken deps, I've learned that some have tried to add extra Obsoletes to make yum install ... pull latest updates for new sub-packages just as yum update ... does. That has lead to bad updates. In case of pidgin-evolution, it only works because pidgin-evolution also _requires_ (!) a specific release of pidgin. If that weren't the case, a yum install pidgin-evolution would simply remove (= obsolete!) pidgin. For a Yum install, an arbitrary package's Obsoletes are not considered unless the package becomes part of the transaction set. Competing Obsoletes = playing with fire. I think it's accept in rawhide since it can provide a sane upgrade path for dist upgrade. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: deluge and flags sub package
2010/6/9 Ankur Sinha sanjay.an...@gmail.com:
On Tue, 2010-06-08 at 23:21 +0530, Ankur Sinha wrote:
On Wed, 2010-06-02 at 14:10 -0700, Peter Gordon wrote:
On Wed, 2010-06-02 at 00:56 +0530, Rahul Sundaram wrote:
I will work with Ankur Sinha and probably do this for Rawhide in the
next couple of days. Peter Gordon, let me know if you have any
objections
This sounds good to me - please go ahead with your changes.
(Apologies about the unavailability over the past several weeks. Final
projects and trips with family/friends have consumed most of my time.
I'm back and ready to rock some Fedora packages, though! ^_~)
hey,
I've made some kinda spec splitting the package into sub packages.
Please have a look at the spec[1]. It builds in mock. The build logs etc
are here[2]
Please let me know if(when) you think up of changes ;)
regards,
Ankur
[1] http://ankursinha.fedorapeople.org/deluge/deluge.spec
[2] http://ankursinha.fedorapeople.org/deluge/
Updated spec to handle conflicts etc. Hope thats how its to be done.
regards,
Ankur
--
I think image subpackage is not needed, maybe it can merged to
-common subpackage, also if you should not provide Provides: %{name}
= %{version}-%{release} or Provides: %{name}-flags =
%{version}-%{release} in spec.
Obseletes is enough to provide a sane upgrade path, Provides is
needed for renaming a package, but it's not suitable in the case of
spliting one package into several subpackages.
https://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitting_packages
Chen Lei
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: JBoss stalled (was Re: status of some packages ??)
Can anyone contact members in AOP alliance directly, maybe it's helpful? e.g. Cédric Beus http://beust.com/weblog/ (http://twitter.com/cbeust) All members info see http://aopalliance.sourceforge.net/members.html Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
2010/6/4 Kevin Kofler kevin.kof...@chello.at: The problem is that the mandatory functionality (SysV-style initscripts compliant to our guidelines) gets pushed to a subpackage to make room for the optional and completely unneccessary junk, and that in some cases yum prefers the nonstandard subpackages. Plus, he's also violating other guidelines, e.g. for this package: http://koji.fedoraproject.org/koji/buildinfo?buildID=176308 Version contains a SVN revision tag which MUST be in Release instead according to our guidelines. (Thanks to Chen Lei for pointing that out.) (And look at the mess that nonstandard versioning made to the bumping tool spot used, see the insane Release values it produced. We have versioning rules for a reason.) Kevin Kofler -- I found that spot disable building static libs in his package two days ago, but he reenable yesterday, I really don't know why. http://koji.fedoraproject.org/koji/buildinfo?buildID=176341 Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
-upstart subpackage vs tranditional initscripts
Fedora have upstart as the /sbin/init daemon for a long time, but we still use the old 'SysVinit' scripts from /etc/rc.d/init.d and fedora packaging guideline have nothing about upstart. Is it right for the maintainer to provide two separate subpackages, one with the tranditional rc.d contents and one with an upstart scripts and make the -upstart subpackage have a higher priority over sysinit subpackage? yum list \*-upstart Loaded plugins: downloadonly, presto, refresh-packagekit Installed Packages clamav-scanner-upstart.noarch 0.96-1403.fc14 �...@rawhide Available Packages clamav-milter-upstart.noarch 0.96-1403.fc14 rawhide dhcp-forwarder-upstart.noarch 0.8-1300.fc13 rawhide ip-sentinel-upstart.noarch 0.12-1300.fc13 rawhide milter-greylist-upstart.noarch 4.2.4-1400.fc14 rawhide tor-upstart.noarch 0.2.1.25-1400.fc14 rawhide Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
2010/6/3 Matt McCutchen m...@mattmccutchen.net: On Wed, 2010-06-02 at 20:00 +0200, Kevin Kofler wrote: Chen Lei wrote: Is it right for the maintainer to provide two separate subpackages, one with the tranditional rc.d contents and one with an upstart scripts and make the -upstart subpackage have a higher priority over sysinit subpackage? No. This is against our packaging guidelines. Where do you see that? -- Matt I'm not sure about whether ship upstart scripts violate our guidelines, but fedora package guideline has - Currently, only SystemV-style initscripts are supported in Fedora. http://fedoraproject.org/wiki/PackagingGuidelines#Initscripts Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
2010/6/3 Toshio Kuratomi a.bad...@gmail.com: This is intended to tell people that SystemVinit scripts are mandatory for services managed by the init system. But providing native upstart as an addition (or initng, minit, etc) is not prohibited by this. -Toshio I don't think provide both upstart and initscript for one package will benefic fedora, especially in the scenario when the upstart scripts have seriously functional regression compared with initscripts. Currently, only one packager provide both upstart scripts and initscripts. We currently don't have a policy about upstart scripts, however a single person to change his packaging style agaist all other packagers in the repo will confuse many linux users or system administators. Before opposing me, you can look at those -upstart subpackages, you'll found they are not as good as you imagined. They are different from other system upstart scripts. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.
2010/6/1 Bruno Wolff III br...@wolff.to: I've definately talked to quite a few of them (online and in person) over the years this has been going on. I even had a tor package made and submitted it, but Enrico and my package crossed paths and his was a day earlier, so his personal version instead of a fedora version got accepted: The reason I asked is that they might be more willing to yank the package from the current maintainer if there is someone willing to step in and fix things rather than having to orphan it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I'd like to see that fesco can assign some co-maintainers for tor and maybe some more packages from Enrico. Regardless of violating fedora package guideline, his package style is quite strance, e,g, He add noarch documention to tor main package, then leave tor binary into -core subpackage, he also add an useless upstart conf as an alternatives to initsrcipt, the package layout is very different with tor upstream and other packages in fedora. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.
2010/6/2 Kevin Kofler kevin.kof...@chello.at: Chen Lei wrote: The maintainer refuse some others to co-maintain tor package or help him to solve this issue. It's a bit complicated to fix this, fedora policy seems don't permit provenpackagers to commit a package if the maintainer are very unwilling to do so. It should be decided by fesco in which condition that a provenpackager can commit a package regardless the unwillingness of the package owner. FYI, FESCo decided on this particular issue that a provenpackager can fix tor to comply with our initscripts guidelines for released Fedoras. (As far as I know, the maintainer already fixed the Rawhide package.) Kevin Kofler No yet, as I known:), he only add a sysv initscripr to cvs, the package in rawhide still use -lsb and -upstart. Also the upstart subpackage works silly, it may need further optimization or obsolete from tor package. See http://koji.fedoraproject.org/koji/buildinfo?buildID=176044 http://koji.fedoraproject.org/koji/fileinfo?rpmID=1999845filename=/etc/rc.d/init.d/tor -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meego in Fedora repos?
2010/5/31 Peter Robinson pbrobin...@gmail.com: Thanks for the offer. The initial release of qt-mobility seems to need 4.6.x and does compile against the Qt in Fedora. I presume they'll bring it up to support 4.7 sometime before long. I'm still reviewing the requirements so I'm not exactly sure what they are but I'll certainly let you know when I know more. Peter -- I somehow a bit worry about meego spin in fedora when considering some compents in meego are forked, now mutter-mbl conflicts with mutter, it may be unacceptable for F14 which will use gnome3 as default desktop. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Request: Magit 0.8 packaging
2010/5/31 mhuht...@abo.fi: Wishful thinking: the new Magit mode v. 0.8 (Git interface for Emacs) will soon be packaged for Fedora. http://philjackson.github.com/magit/ You can package it for fedora by your self http://fedoraproject.org/wiki/PackageMaintainers/Join http://fedoraproject.org/wiki/Packaging:Emacs Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.
2010/6/1 Ryan Rix r...@n.rix.si: On Mon 31 May 2010 1:55:26 pm Paul Wouters wrote: since that's the preference of the maintainer, which violates fedora packagaging policies Then a provenpackager should fix it regardless of whether the maintainer is too busy to fix it. and even then, they shouldn't be maintaining packages they are too busy to fix! That's just as bad as blatently refusing to fix this issue. -- Ryan Rix == http://hackersramblings.wordpress.com | http://rix.si/ == == http://rix.si/page/contact/ if you need a word == The maintainer refuse some others to co-maintain tor package or help him to solve this issue. It's a bit complicated to fix this, fedora policy seems don't permit provenpackagers to commit a package if the maintainer are very unwilling to do so. It should be decided by fesco in which condition that a provenpackager can commit a package regardless the unwillingness of the package owner. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meego in Fedora repos?
2010/5/30 Peter Robinson pbrobin...@gmail.com: On Sun, May 30, 2010 at 12:40 PM, Valent Turkovic Its under review. I'm waiting for a few upstream updates that need to hit as part of the gnome 2.31.2 release. There's a few new packages, some renames but most of it should be in the repos in the not to distant future. I'll post updates to the m...@l.fp.o mailing list as things start to move. Peter -- Will meego spin include both netbook and handset packages from meego? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does pari require tetex-dvi?
See https://bugzilla.redhat.com/show_bug.cgi?id=530565 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: deluge and flags sub package
2010/5/28 Rahul Sundaram methe...@gmail.com: Hi Peter Gordon seems to be unreachable and while bumping up to rb_libtorrent to fix E-V-R, I noticed that deluge has a separate flags sub package. I remember this was proposed as a guideline and then dropped. Do we need a flags sub package anymore? Seems rather pointless. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I'd rather suggest you to split deluge into several subpackages, e.g. deluge(metapackge) deluge-gtk deluge-console deluge-web deluge-common or deluge(gtk ui) deluge-console deluge-web deluge-common. Bundling UI and Core and pulling in gtk2 dependency is not a good idea for deluge. For flags subpackage, all I known is it's still a scratch guideline. See https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: status of some packages ??
2010/5/30 Xose Vazquez Perez xose.vazq...@gmail.com: TeX Live 2009 and Ruby 1.9 JBoss[1] is still a *big* deficit. Potential for f14/15 ? [1] http://fedoraproject.org/wiki/JBoss For Texlive 2010 and Ruby 1.9,See http://fedoraproject.org/wiki/Features/TeXLive http://fedoraproject.org/wiki/Features/Ruby_1.9.1 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.
2010/5/30 Bruno Wolff III br...@wolff.to: On Sun, May 30, 2010 at 00:39:14 -0400, Matthew Miller mat...@mattdm.org wrote: So, clearly, there's some disagreement about what's fixed and what's broken. But printing out a passive-agressive warning to end-users is not the solution. The error message is confusing and very, very unhelpful. Worse, it's not _meant_ to be helpful to the poor end user -- it's meant to try to goad the other packager into action. Such things need to be taken up with FESCO, not fought about in user-visible debug output. See: https://fedorahosted.org/fesco/ticket/347 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I don't why the tor maintainer don't want to keep consistence with fedora package guideline and tor upstream. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.
2010/5/30 Matthew Miller mat...@mattdm.org: On Sun, May 30, 2010 at 12:06:12AM -0500, Bruno Wolff III wrote: See: https://fedorahosted.org/fesco/ticket/347 Yeah, I remember this coming up before with the issue of zillions of dependencies. The problem here is the output. I know (as discussed in that ticket, actually) that the Fedora guidelines don't forbid output in the post scripts. I think it _should_ be forbidden except in the case of errors, but that's not the issue here. The problem is _what_ the message says, its tone, and to whom it is addressed. All unhelpful and bad for Fedora. -- Matthew Miller mat...@mattdm.org http://mattdm.org/ -- It's actually the same problem and both caused by the misusing of redhat-lsb. The tor package looks very different from other daemons in fedora, e.g. vsftpd squid etc, a small package with so many subpackages and a metapackage seems quite strange. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: me-tv orphaned
2010/5/27 Stefan Grosse singularit...@gmx.net: Dear list, I just asked Zarko Pintar (grof) if he still maintains me-tv (application to watch dvb-t tv). He tells me that he is not. Could someone pick it up, please? Thanks! Stefan Grosse http://koji.fedoraproject.org/koji/packageinfo?packageID=8486 From: Zarko Pintar zarko.pin...@... To: Stefan Grossestefan.gro...@... Sorry, but no, I am not! And I do not know who care about this package now regards, Zarko On Wed, May 26, 2010 at 11:46 PM, Stefan Grosse stefan.gro...@... wrote: Hi Zarko, are you still maintaining me-tv on Fedora? There have been several updates (current is 1.2.4 but in Fedora latest is 1.1.6) of that program. Would you mind to start a new build? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel You should ask his to orphan it on pkgdb, then others can take this package and make an update. https://admin.fedoraproject.org/pkgdb/acls/name/me-tv Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Errors in packaging kupfer
CFLAGS=$RPM_OPT_FLAGS LDFLAGS=-lm waf configure --prefix=%{_prefix}
-
waf configure --prefix=%{_prefix} --no-runtime-deps
All python modules are not needed in runtime, don't check them. Also,
the package is noarch, optflags is not needed.
Chen Lei
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Errors in packaging kupfer
2010/5/26 Chen Lei supercyp...@gmail.com:
CFLAGS=$RPM_OPT_FLAGS LDFLAGS=-lm waf configure --prefix=%{_prefix}
-
waf configure --prefix=%{_prefix} --no-runtime-deps
All python modules are not needed in runtime, don't check them. Also,
the package is noarch, optflags is not needed.
Chen Lei
s/not needed/needed/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20100525 changes
2010/5/26 Yanko Kaneti yan...@declera.com: On Tue, 2010-05-25 at 14:26 +, Rawhide Report wrote: llvm-2.7-2.fc14 --- * Mon May 24 2010 Michel Salim sali...@fedoraproject.org - 2.7-2 - Exclude llm-gcc manpages - Turn on apidoc generation - Build with srcdir=objdir, otherwise clang doxygen build fails 729768200 clang-apidoc-2.7-2.fc14.noarch.rpm 1513180272 llvm-apidoc-2.7-2.fc14.noarch.rpm Please reconsider :/. This is big, even compared to the other doxygen monstrosities out there. Easily avoidable by removing graphviz from the build deps. 1513180272 llvm-apidoc-2.7-2.fc14.noarch.rpm 729768200 clang-apidoc-2.7-2.fc14.noarch.rpm 308665052 kdelibs-apidocs-4.4.80-1.fc14.noarch.rpm 183951176 texlive-texmf-doc-2007-35.fc13.noarch.rpm 159398728 asterisk-apidoc-1.6.2.8-0.1.rc1.fc14.x86_64.rpm 143864764 mrpt-doc-0.8.0-0.3.20100102svn1398.fc14.x86_64.rpm 118899072 cloudy-devel-doc-08.00-1.fc14.noarch.rpm 115558504 qt-doc-4.7.0-0.14.beta1.fc14.noarch.rpm 90590052 lilypond-doc-2.12.3-1.fc13.noarch.rpm 66853332 libdap-doc-3.9.3-2.fc12.x86_64.rpm 61305644 antlr3-C-docs-3.2-6.fc14.noarch.rpm 52820224 bes-doc-3.7.2-3.fc12.x86_64.rpm Roughly 10% of a particular arch tree footprint on the mirrors. Yanko -- I suggest not to ship apidocs for all applications, very few people actually need them. Most developers only need apidocs for some paticular libraries. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg for F14
repoquery --whatrequires --alldeps libpng10 libpng10-0:1.0.53-1.fc14.x86_64 libpng10-0:1.0.53-1.fc14.i686 gnome-libs-1:1.4.2-15.fc12.i686 libpng10-devel-0:1.0.53-1.fc14.i686 gnome-libs-1:1.4.2-15.fc12.x86_64 libpng10-devel-0:1.0.53-1.fc14.x86_64 libpng10 is removed in many distributions including debian, ubuntu, arch, why it still be maintained in fedora? Do we have a policy to remove long legacy libs? Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libjpeg for F14
2010/5/25 Chris Jones chrisjo...@comcen.com.au I'm curious as to what Debian/Ubuntu are using as a replacement for libpng10? Debian updated libpng10 to libpng12 long ago, they don't keep multiversion libpng. Almost all packages which still depend on libpng10 is dead.inupstream. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update
2010/5/22 Hans de Goede hdego...@redhat.com
Hi,
On 05/17/2010 03:13 AM, Chen Lei wrote:
repoquery --repoid=rawhide --whatrequires --alldeps ImageMagick-c++
ImageMagick-c++-0:6.6.0.2-8.fc14.i686
ImageMagick-c++-0:6.6.0.2-8.fc14.x86_64
inkscape-0:0.48-0.2.20100505bzr.fc14.x86_64
ImageMagick-c++-devel-0:6.6.0.2-8.fc14.x86_64
gdl-0:0.9-0.12.rc4.fc14.x86_64
pfstools-imgmagick-0:1.8.1-1.fc14.x86_64
drawtiming-0:0.7.1-1.1.fc14.x86_64
pfstools-0:1.8.1-1.fc14.x86_64
ImageMagick-c++-devel-0:6.6.0.2-8.fc14.i686
k3d-0:0.8.0.1-1.fc14.x86_64
gdl-python-0:0.9-0.12.rc4.fc14.x86_64
inkscape-view-0:0.48-0.2.20100505bzr.fc14.x86_64
BTW, some subpackages contain .la files, you should remove them in
%install.
e.g.
This is not necessarily good advice either:
1) As these la files are for plugins which are located outside of
%{_libdir},
they do no harm
2) In the past there have been cases with plugins where the libraries
plugins
loading mechanism relies on the .la files being present, that might very
well
be the case here.
.
This is actually my fault:) . ImageMagick strangely relies on those .la
files to load modules. Containing .la files in packages will pull in libtool
as dependency, can we filter it out?
Chen Lei
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
