Re: Help to solve a possible circular Requires:
2010/12/3 Fabio M. Di Nitto : > 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 : > 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 : > 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
xulrunner 2.0 in rawhide (F15) bundles several system libs
2010/9/29 Martin Stransky : > There's a new xulrunner/firefox in rawhide. The API (js too) is slightly > incompatible with the 1.9.2, there is a new XPCOM modules registration > and so on, see: > > https://bugzilla.redhat.com/show_bug.cgi?id=634596#c3 > https://developer.mozilla.org/en/Firefox_4_for_developers > https://developer.mozilla.org/en/XPCOM/XPCOM_changes_in_Gecko_2.0 > > ma. > -- Hi Martin, It seems xulrunner bundles several system libs, do you intend to unbundle those libs? e.g. media/libvpx media/libvorbis modules/libimg/png Regards, 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 : > 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 : > 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 : > > 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
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: 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
Re: Python 3.2a1 in rawhide
2010/8/22 Thomas Spura :
> 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 : > 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 : > > -- > 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
Re: [HEADS-UP] python-numarray will be retired for devel/f14 in 3 days
2010/8/19 Chen Lei : > 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
[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: rawhide report: 20100817 changes
2010/8/17 Rawhide Report : > 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.17&view=markup 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: 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: Some questions about on Fedora
2010/8/10 Remi Collet : > 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 : > 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: root-doc subpackage slightly obese
2010/8/9 Kevin Kofler : > 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
Re: Some questions about on Fedora
2010/8/8 Remi Collet : > 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: Broken package EOL instructions (Was Re: Retire gstreamer-plugins-flumpegdemux in F14/devel?)
2010/8/6 Bastien Nocera : > On Fri, 2010-08-06 at 17:23 +0800, Chen Lei wrote: >> 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 > > In http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife : >> git rm all the other files in the foo branches that you added >> dead.package to. > > Except that: > $ fedpkg commit -p -m "EOL package" > Could not commit: No spec file found. Using git instead of fedpkg? git rm *.spec git commit git push 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
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: [ACTION REQUIRED] orphaned packages in F-14
2010/8/5 Kevin Kofler : > 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: Wordpress testers needed!
2010/8/3 Jon Ciesla : >> 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: nonresponsive maintainer policy
2010/8/2 James Findley : > 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: unuran-1.7.1-1.fc14.x86_64 requires /sbin/install-info
2010/8/1 Neal Becker : > 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 : > 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 : > 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: The move to git!
2010/7/30 Martin Sourada : > 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 " 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: The move to git!
2010/7/30 Martin Sourada : > On Thu, 2010-07-29 at 20:55 -0700, Jesse Keating wrote: > >> 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: Fedora 14 branching and dist-git roll out
2010/7/30 Remi Collet : > 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: Firefox 4 for Fedora 14?
2010/7/29 Conan Kudo (ニール・ゴンパ) : > On Wed, Jul 28, 2010 at 4:38 PM, Adam Williamson > 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 Frank Murphy : > On 28/07/10 13:52, Mike McGrath wrote: > > 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/28 Filipe Rosset : >> > > 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
Can anyone take a look at libva(FE-Legal)?
Hi all, libva is a library and tools relating to the VAAPI video playback acceleration specification. libva is included in all major distributions(debian/ubuntu meego opensuse mandriva gentoo etc.) . I need it as a dependecy to package some meego MTF packages. Howerver, the submitter(Adam Williamson) feels that i965-va-driver plugins and many other parts of libva may have some patent issues. Are there any legal guys or developers who are familiar with libva can help to clarify the patent issues in libva? The Review Request is here and waits for a legal review for almost one year: https://bugzilla.redhat.com/show_bug.cgi?id=518546 Thanks a lot! 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/27 Tom "spot" Callaway : > 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: Fedora 14 branching and dist-git roll out
Can we filter out all .cvsignore and Makefile files it git repo? It seems those files are irrelevant to dist-git. Regrads, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: jack2
2010/7/20 Andy Shevchenko : > On Tue, May 11, 2010 at 6:17 PM, Orcan Ogetbil 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/16 Colin Walters : > > 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: Naming issue for meego 1.0 related packages
2010/7/16 Mattias Ellert : > 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/12 Kevin Kofler : > 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/11 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: Should GnuPG 1.4.x be revived?
2010/7/14 Brian C. Lane : > -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 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: Should GnuPG 1.4.x be revived?
2010/7/13 Daniel P. Berrange : > 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: Naming issue for meego 1.0 related packages
2010/7/10 pbrobin...@gmail.com : > On Fri, Jul 9, 2010 at 5:28 PM, Chen Lei wrote: >> 2010/7/9 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
Re: Naming issue for meego 1.0 related packages
2010/7/9 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
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: gcc-4.5-RH in F14
2010/7/8 Jakub Jelinek : > 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: Licensing Guidelines Update - Please Read
2010/7/8 Tom "spot" Callaway :
> 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: Can anyone contact Gérard Milmeister (gemi)?
2010/7/6 Gérard Milmeister : > 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/7/7 Christopher Brown : > > 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/6/18 Chen Lei : > 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 : > 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 : > 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: concept of package "ownership"
2010/7/2 Patrice Dumas : > 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: who is Petr Pisar from redhat ?
2010/7/2 Michael Schwendt : > On Fri, 02 Jul 2010 11:40:11 +0200, Matěj wrote: > >> Dne 2.7.2010 11:34, Michael Schwendt napsal(a): >> > Of course there is. There ought to be prior communication about such plans >> > to upgrade a package. The primary package maintainer may have good reasons >> > for not upgrading the package. Just ask! >> >> The primary package maintainer (see the other thread about "owning" a >> package) who has a package 8 months in FTBFS doesn't have much rights in >> my thinking. > > The provenpackager, who has had 8 month to notice such a problem, has had > 8 months to start the non-responsive maintainer procedure. What will > happen the next time the package is affected by a bad problem? Does the > same provenpackager now keep an eye on the package and will be available > to fix it much sooner? Or will it takes 8 months again, because that is > possible in the Fedora package collection? > This procedure is a bit idealistic, IMHO. A package which has a FTBFS bug will wait for two release cycles before orphaning it, it's too long(many of those FTBFS packages can work properly). Furthermore, we don't even have a way to orphan a particular package which is unmaintained or has a lot of unsolved issues but don't have a FTBFS bug. 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 Patrice Dumas : > On Fri, Jul 02, 2010 at 11:40:11AM +0200, Matěj Cepl wrote: >> Dne 2.7.2010 11:34, Michael Schwendt napsal(a): >> > Of course there is. There ought to be prior communication about such plans >> > to upgrade a package. The primary package maintainer may have good reasons >> > for not upgrading the package. Just ask! >> >> The primary package maintainer (see the other thread about "owning" a >> package) who has a package 8 months in FTBFS doesn't have much rights in >> my thinking. > > I think that this is very wrong. I don't know the specifics of this package > either, but I remember that for one of my packages, I had to hold of > correcting a FTBS because it meant upgrading, and I coudn't do that > because of some incompatibilities. > > Bottom line is -- unless it changed -- in the spirit of provenpackager > policies for non urgent things like FTBS, provenpackagers should do > as little as possible, contact packagers before doing anything, do change > in cvs but let time for the packager to build or revert. > > -- > Pat > -- However, FTBFS in rawhide is not allowed, your package will be orphaned/cleaned if it has a FTBFS bug for two release cycles. 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 : > 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: libjpeg-turbo conflicts in rawhide
2010/7/1 Adam Tkac : > 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/7/1 Bruno Wolff III : > On Wed, Jun 30, 2010 at 12:10:11 -0500, > Rex Dieter 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: libjpeg-turbo conflicts in rawhide
2010/6/30 Michael Schwendt : > 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/6/30 Rich Mattes : > 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 : > On Wed, 30 Jun 2010 14:04:51 +0800, Chen wrote: > >> 2010/6/30 Rich Mattes : >> > 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 : > 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: move libusb from /usr/lib to /lib
2010/6/23 Jan Vcelak :
> 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 : > On Tue, 2010-06-22 at 08:40 +0200, Thomas Spura wrote: >> Am Mon, 21 Jun 2010 14:34:02 -0400 >> schrieb David Malcolm : >> >> > 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: rfc: python2.7 for F14
2010/6/22 David Malcolm : > 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: To construct a Zope skyscraper on Fedora
2010/6/21 Nathaniel McCallum : > 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: 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: New Hatari version: need help
2010/6/20 Andrea Musuruane : > 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
Re: To construct a Zope skyscraper on Fedora
2010/6/20 Rakesh Pandit : > > 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
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 : > 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: deluge and flags sub package
> Also currently I cannot guess what happens if just "yum update" > is executed. If only deluge-common (in this spec file) is to be > installed, many users may complain "why deluge gtk cannot be found > anymore?" > This coulld be avoid by filling properly Obsoletes field, I test splitting amule and amule-nogui from rpmfusion into more subpackages a while ago, yum works fine as expected. See https://bugzilla.redhat.com/show_bug.cgi?id=599597 > Anyway I think filing a bug is needed beforehand. > Agree, filling a bug will be more clearly than discussing on mailist. Regards, 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 : > 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: pidgin obsoleting itself
2010/6/9 Michael Schwendt : > 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/9 Thomas Moschny : > 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? > > -- > Thomas Moschny > -- 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 Thomas Moschny : > 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? > > -- > Thomas Moschny > -- "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 : > 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 > -- 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: deluge and flags sub package
2010/6/9 Ankur Sinha :
> 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 : > > 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
Re: -upstart subpackage vs tranditional initscripts
2010/6/3 Toshio Kuratomi : >> > 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: -upstart subpackage vs tranditional initscripts
2010/6/3 Matt McCutchen : > 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 Kevin Kofler : > 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. You'll notice that all the > offending packages are by the same maintainer (you easily recognize them > from the ridiculous Release versions). > > All those -upstart and -lsb subpackages must go away and the -sysv > subpackages must be merged into the main package. > > Kevin Kofler > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > I found the maintainer violates fedora package/naming guideline many times, we need a people to persuade him to obey those guideline. A more ridiculous release number and a wrong version number: http://koji.fedoraproject.org/koji/buildinfo?buildID=176308 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: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.
2010/6/2 Kevin Kofler : > 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=1999845&filename=/etc/rc.d/init.d/tor -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rebuild of packages dependent on perl
2010/6/1 Marcela Mašláňová : > Hello maintainers, > I started rebuild of packages dependent on perl. At the moment are packages > rebuilt in > test buildroot dist-f14-perltest. It's quite possible that some will fail > with new perl-5.12.0. > If your package didn't pass rebuild, we (Perl-SIG) will be happy if you fix > it by yourself. If you can't, don't panic. We'll be looking at packages, > which didn't pass. Also you can ask for help at: > perl-de...@lists.fedoraproject.org > > The main changes in perl are mentioned at: > http://perldoc.perl.org/5.12.0/perldelta.html > > Regards, > Marcela > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Will we have perl 5.12.1 in F14 since it was released several weeks ago? 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/2 Paul Wouters : > On Tue, 1 Jun 2010, Bruno Wolff III wrote: > >>>> Does FESCO know you'd be willing to become the maintainer? >>> >>> 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. > > I am willing to maintain or co-maintain it, and pull it into compliance > with fedora package guidelines. > > Paul > +1 for you. As the maintainer of vidalia and polipo, I really like to see tor fedora to be more compliance with Fedora package guideline and the tor package from upstream. 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 : >> 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/1 Ryan Rix : > 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: Request: Magit 0.8 packaging
2010/5/31 : > > 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: Meego in Fedora repos?
2010/5/31 Peter Robinson : > 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: 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: Meego in Fedora repos?
2010/5/30 Peter Robinson : > 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: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.
2010/5/30 Matthew Miller : > 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: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.
2010/5/30 Bruno Wolff III : > On Sun, May 30, 2010 at 00:39:14 -0400, > Matthew Miller 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
