Re: Fedora Notifications System.
Kevin Fenzi wrote: > I'm not sure a notification applet by itself is going to be the best > answer here... as people may be busy or not see the notice and a few > seconds later it goes away and they miss it. That's why the notification should not time out unless/until the user clicks it away! In KDE, the old-style notifications just stay on the screen until clicked away, the new-style Plasma notifications (which are the default) retract (after some timeout) to an (i) button in the systray, which will only move to the hidden part of the systray if the notifications in it are clicked away by the user. > Perhaps something that puts itself in the system tray and lets them > click on it at their leisure? Well, see above, the notification system should do that. :-p Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum appmarket
Roberto Ragusa wrote: > Some more tags for "functionally comparable to" and the name of > some well known programs for Windows or Macintosh would let > people cope with the original names of Linux apps. > > Nero -> k3b, xcdroast > Adobe Illustrator -> inkscape > Adobe Reader -> evince, kpdf, okular I think that would not fly for trademark reasons. I know there are sites which do that kind of mapping and that some upstream projects advertise their program as "comparable with (popular proprietary program XYZ)", but they're treading on a very fine line legally. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python 3.2a1 in rawhide
On Mon, Aug 23, 2010 at 01:19:53AM -0400, Orcan Ogetbil wrote: > > That sounds like the only place where this convention is useful. > > How about .py files in /usr/bin/ ? We currently don't byte-compile the > .py files in standard PATH, but maybe since they will go into a > __pycache__ subdirectory, we can byte-compile them now. > > Is there any "law" in FHS that forbids having a /usr/bin/__pycache__/ > directory? > .pyc files wouldn't be used there so it's not relevant. (Not because they're in /usr/bin but because the script being invoked is /usr/bin/something.py and python won't look for a byte compiled version of the file being invoked. -Toshio pgpMiuwcsObnf.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python 3.2a1 in rawhide
On Mon, Aug 23, 2010 at 12:40 AM, Kalev Lember wrote: > On 08/23/2010 03:34 AM, Orcan Ogetbil wrote: >> On Sat, Aug 21, 2010 at 6:48 PM, David Malcolm wrote: >>> I just built Python 3.2a1 into rawhide: >>> http://koji.fedoraproject.org/koji/buildinfo?buildID=191382 >>> so the meaning of "python3" in rawhide just jumped from Python 3.1 to >>> Python 3.2 >> [cut] >>> with Python 3.2 onwards you now have a __pycache__ directory: >> [cut] >>> The idea is to permit sharing of modules between multiple >>> parallel-installable versions of Python. >>> >> >> I am not sure that I understood this correctly. There will be a >> __pycache__ directory in the following structure: >> >> /usr/lib/python3.2/site-packages/foo/foo.py >> /usr/lib/python3.2/site-packages/foo/__pycache__/foo.cpython-32.pyc >> /usr/lib/python3.2/site-packages/foo/__pycache__/foo.cpython-32.pyo >> >> But now when the user installs python-3.3, he will have >> >> /usr/lib/python3.3/site-packages/foo/foo.py >> /usr/lib/python3.3/site-packages/foo/__pycache__/foo.cpython-33.pyc >> /usr/lib/python3.3/site-packages/foo/__pycache__/foo.cpython-33.pyo >> >> The two directories have different roots /usr/lib/python3.*/ and the >> module foo.py is not shared. >> >> Where is the catch? > > /usr/lib/python*/ isn't the only place where Python bytecode files are > installed. I'd imagine that the new structure is far more useful in > other places where Python version isn't already encoded in the directory > name. For example, currently the RabbitVCS nautilus extension installs > the following files: > /usr/lib64/nautilus/extensions-2.0/python/RabbitVCS.py > /usr/lib64/nautilus/extensions-2.0/python/RabbitVCS.pyc > /usr/lib64/nautilus/extensions-2.0/python/RabbitVCS.pyo > > With the new directory structure the bytecompiled files would end up > named differently for each Python parallel-installable version: > /usr/lib64/nautilus/extensions-2.0/python/RabbitVCS.py > /usr/lib64/nautilus/extensions-2.0/python/__pycache__/RabbitVCS.cpython-33.pyc > /usr/lib64/nautilus/extensions-2.0/python/__pycache__/RabbitVCS.cpython-33.pyo > That sounds like the only place where this convention is useful. How about .py files in /usr/bin/ ? We currently don't byte-compile the .py files in standard PATH, but maybe since they will go into a __pycache__ subdirectory, we can byte-compile them now. Is there any "law" in FHS that forbids having a /usr/bin/__pycache__/ directory? Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python 3.2a1 in rawhide
On 08/23/2010 03:34 AM, Orcan Ogetbil wrote: > On Sat, Aug 21, 2010 at 6:48 PM, David Malcolm wrote: >> I just built Python 3.2a1 into rawhide: >> http://koji.fedoraproject.org/koji/buildinfo?buildID=191382 >> so the meaning of "python3" in rawhide just jumped from Python 3.1 to >> Python 3.2 > [cut] >> with Python 3.2 onwards you now have a __pycache__ directory: > [cut] >> The idea is to permit sharing of modules between multiple >> parallel-installable versions of Python. >> > > I am not sure that I understood this correctly. There will be a > __pycache__ directory in the following structure: > > /usr/lib/python3.2/site-packages/foo/foo.py > /usr/lib/python3.2/site-packages/foo/__pycache__/foo.cpython-32.pyc > /usr/lib/python3.2/site-packages/foo/__pycache__/foo.cpython-32.pyo > > But now when the user installs python-3.3, he will have > > /usr/lib/python3.3/site-packages/foo/foo.py > /usr/lib/python3.3/site-packages/foo/__pycache__/foo.cpython-33.pyc > /usr/lib/python3.3/site-packages/foo/__pycache__/foo.cpython-33.pyo > > The two directories have different roots /usr/lib/python3.*/ and the > module foo.py is not shared. > > Where is the catch? /usr/lib/python*/ isn't the only place where Python bytecode files are installed. I'd imagine that the new structure is far more useful in other places where Python version isn't already encoded in the directory name. For example, currently the RabbitVCS nautilus extension installs the following files: /usr/lib64/nautilus/extensions-2.0/python/RabbitVCS.py /usr/lib64/nautilus/extensions-2.0/python/RabbitVCS.pyc /usr/lib64/nautilus/extensions-2.0/python/RabbitVCS.pyo With the new directory structure the bytecompiled files would end up named differently for each Python parallel-installable version: /usr/lib64/nautilus/extensions-2.0/python/RabbitVCS.py /usr/lib64/nautilus/extensions-2.0/python/__pycache__/RabbitVCS.cpython-33.pyc /usr/lib64/nautilus/extensions-2.0/python/__pycache__/RabbitVCS.cpython-33.pyo -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Notifications System.
On Sat, 21 Aug 2010 00:46:43 +0400 Mahmoud Abdul Jawad wrote: > Hi all,, > > before two weeks, a discussion started in ambassadors mailing-list > about a work around to deliver the important notifications to the > fedora desktop (whatever the desktop is). > after some discussion, we started with some guide lines & putted them > on the wiki: > https://fedoraproject.org/wiki/Fedora_notifications_system > > Continuing, I created an early prototype i want people to check & > gives feedbacks about it. > you can reach it through gitweb: > http://fedorapeople.org/gitweb?p=megenius/public_git/fns.git;a=summary > or, you can grab your own clone from the git repo: > git://fedorapeople.org/megenius/fns.git > > keep in mind that last_check file should be writeable by the world, & > you should change its value to an earlier date, so you can see some > notifications. It doesn't seem to output anything here: ke...@ohm ~/git/fns (git)-[master] % python fns.py [] Might include a README file as to what it needed and what output you expect? I'm not sure a notification applet by itself is going to be the best answer here... as people may be busy or not see the notice and a few seconds later it goes away and they miss it. Perhaps something that puts itself in the system tray and lets them click on it at their leisure? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python 3.2a1 in rawhide
On Sat, Aug 21, 2010 at 6:48 PM, David Malcolm wrote: > I just built Python 3.2a1 into rawhide: > http://koji.fedoraproject.org/koji/buildinfo?buildID=191382 > so the meaning of "python3" in rawhide just jumped from Python 3.1 to > Python 3.2 [cut] > with Python 3.2 onwards you now have a __pycache__ directory: [cut] > The idea is to permit sharing of modules between multiple > parallel-installable versions of Python. > I am not sure that I understood this correctly. There will be a __pycache__ directory in the following structure: /usr/lib/python3.2/site-packages/foo/foo.py /usr/lib/python3.2/site-packages/foo/__pycache__/foo.cpython-32.pyc /usr/lib/python3.2/site-packages/foo/__pycache__/foo.cpython-32.pyo But now when the user installs python-3.3, he will have /usr/lib/python3.3/site-packages/foo/foo.py /usr/lib/python3.3/site-packages/foo/__pycache__/foo.cpython-33.pyc /usr/lib/python3.3/site-packages/foo/__pycache__/foo.cpython-33.pyo The two directories have different roots /usr/lib/python3.*/ and the module foo.py is not shared. Where is the catch? Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python 3.2a1 in rawhide
On Sat, Aug 21, 2010 at 5:48 PM, David Malcolm wrote: > I just built Python 3.2a1 into rawhide: > http://koji.fedoraproject.org/koji/buildinfo?buildID=191382 > so the meaning of "python3" in rawhide just jumped from Python 3.1 to > Python 3.2 I tried rebuilding python-lxml, but I ran into this error: gcc -pthread -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fPIC -I/usr/include/libxml2 -I/usr/include/python3.2 -c src/lxml/lxml.etree.c -o build/temp.linux-x86_64-3.2/src/lxml/lxml.etree.o -w src/lxml/lxml.etree.c: In function '__Pyx_Method_ClassMethod': src/lxml/lxml.etree.c:144925:44: error: 'PyMethodDescrObject' has no member named 'd_type' error: command 'gcc' failed with exit status 1 The full build log can be found here: http://koji.fedoraproject.org/koji/getfile?taskID=2417411&name=build.log I'm not familiar enough with C extensions in Python to find the fix quickly, unless there's a FAQ somewhere with common problems when porting between Python 2 and Python 3... -- Jeff Ollie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Notifications System.
2010/8/22 Till Maas > On Sun, Aug 22, 2010 at 10:19:53PM +0400, Mahmoud Abdul Jawad wrote: > > > without help i'll not be able to continue. > > please test the application on non-KDE desktops, think for improvements & > > give feedbacks. > > Maybe you get more feedback if you make it a F15 feature: > https://fedoraproject.org/wiki/Features/Policy > > Also you might get more feedback from potential users, e.g. if you ask on > the > fedora user list or in the fedora forum. Another way might be to finalize > it so > that it can be packaged and installed. Then people can install it and use > it. > > I am not part of the target audience of the application, therefore I cannot > tell > you much about it. But please do not rely on a global writeable file. > > Regards > Till > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > 1) I was the one who put a google wave link in the wiki, I tought it might be a good way of comunication because anyone with a Gmail account can acess to a wave and use it. If someone do not have a Gmail account he/she simply can use the IRC, can contact anyone that's helping via their wiki's and also can use this mailing list. I do not see any problem there. 2) I think the final goal of this is to have an app that could be packaged and used in fedora 15 or a future release as till said, but we're just starting... let time be time :) I'm here for anything you need. P.S. I wrote an article for the Fedora-LATAM magazine about this project. Maybe with that we can broadcast wider and get some more help. The magazine is going to be released on september 5th. -- <-Manuel Escudero-> Linux User #509052 @GWave: jmlev...@googlewave.com @Blogger: http://www.blogxenode.tk/ (Xenode Systems Blog) PGP/GnuPG: DAE3 82E9 D68E 7AE4 ED31 1F8F 4AF4 D00C 50E7 ABC6 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Notifications System.
> > > > 1) I was the one who put a google wave link in the wiki, I tought it might > be a good way of comunication because anyone with a Gmail account can acess > to a wave and use it. If someone do not have a Gmail account he/she simply > can use the IRC, can contact anyone that's helping via their wiki's and also > can use this mailing list. I do not see any problem there. > > You might not see a problem but there are people here who have an irrational fear of Google, yet use stuff that could be considered more evil. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python 3.2a1 in rawhide
On Sun, 2010-08-22 at 16:31 +0200, Thomas Spura wrote:
> 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:
Oops; good catch - thanks!
Looks like the python3 package needs to own this.
Toshio fixed this in python3-3.2-0.2.a1
http://koji.fedoraproject.org/koji/buildinfo?buildID=191446
(I only noticed this after trying to push my fix for this :( )
Yes; anything that installs any .py files into %{python_sitearch} should
also be installing bytecode files into
%{python_sitearch}/__pycache__
and if you install subdirectories, the subdirectories should themselves
install a __pycache__ subdir.
> 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?
That sounds correct.
> python3-minimock currently only owns:
> %{python3_sitelib}/__pycache__/minimock*
This seems correct.
Thanks!
Dave
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Notifications System.
On Sun, Aug 22, 2010 at 10:19:53PM +0400, Mahmoud Abdul Jawad wrote: > without help i'll not be able to continue. > please test the application on non-KDE desktops, think for improvements & > give feedbacks. Maybe you get more feedback if you make it a F15 feature: https://fedoraproject.org/wiki/Features/Policy Also you might get more feedback from potential users, e.g. if you ask on the fedora user list or in the fedora forum. Another way might be to finalize it so that it can be packaged and installed. Then people can install it and use it. I am not part of the target audience of the application, therefore I cannot tell you much about it. But please do not rely on a global writeable file. Regards Till pgpAG9AinuCZZ.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python 3.2a1 in rawhide
On Sun, Aug 22, 2010 at 04:31:08PM +0200, Thomas Spura wrote:
> 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*
>
Makes sense to me -- if python3 owns site-packages then it should also own
site-packages/__pychache__.
Spec updated and build queued.
-Toshio
pgpbiyQJeUnXE.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Notifications System.
On Sat, Aug 21, 2010 at 3:10 PM, Mahmoud Abdul Jawad < abduljawad.mahm...@gmail.com> wrote: > > can you forget that there's a link for googlewave discussion in that page?? > in fact, i don't care where the discussion is being done. however, if > there's anybody who have a googlewave account it would be nice to talk with > him (btw, check the wiki page history to know who added that link). > i was talking about a Fedora Notifications System, not a googlewave > discussion. > & after a half a day, i didn't get any feedbacks. > > again, if you have any idea to improve the application please post it, & > if you found anything to improve how the program works please post it. > > > -- > Regards,, > Mahmoud Abdul Jawad > @meGenius > > hey people,, without help i'll not be able to continue. please test the application on non-KDE desktops, think for improvements & give feedbacks. -- Regards,, Mahmoud Abdul Jawad @meGenius -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Sun, Aug 22, 2010 at 7:45 PM, Rex Dieter wrote: > pbrobin...@gmail.com wrote: > >> I know its been discussed in the past but there's been reasons not to >> drop a default MTA but now that cronie (the last actual dependency) >> has support for logging to system logs is there any reason to include >> an MTA by default for F-14? > > A bit late to consider for F-14 imo (I'd argue something like should in > place and testable by or near feature freeze), F-15 is doable. Test what? That no MTA is present? I'd say we should stop arguing forever and just do it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mcelog errors
Michael Schwendt wrote: > Bugs are to be reported in bugzilla, e.g. via this convenient link: > http://bugz.fedoraproject.org/mcelog Thanks. It appears that there are a number of bug reports already opened on exactly this problem. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Sun, Aug 22, 2010 at 6:45 PM, Rex Dieter wrote: > pbrobin...@gmail.com wrote: > >> I know its been discussed in the past but there's been reasons not to >> drop a default MTA but now that cronie (the last actual dependency) >> has support for logging to system logs is there any reason to include >> an MTA by default for F-14? > > A bit late to consider for F-14 imo (I'd argue something like should in > place and testable by or near feature freeze), F-15 is doable. It was discussed as part of F-12 and F-13 and we now have all the pieces in place. BTW Why change the subject line? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
pbrobin...@gmail.com wrote: > I know its been discussed in the past but there's been reasons not to > drop a default MTA but now that cronie (the last actual dependency) > has support for logging to system logs is there any reason to include > an MTA by default for F-14? A bit late to consider for F-14 imo (I'd argue something like should in place and testable by or near feature freeze), F-15 is doable. -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaned: nget & tla
I have just orphaned the following two packages: + nget + tla Both have been dead for quite some time and has very few users. Think twice before picking them up. Cheers, Debarshi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
drop default MTA for Fedora 14
Hi All, I know its been discussed in the past but there's been reasons not to drop a default MTA but now that cronie (the last actual dependency) has support for logging to system logs is there any reason to include an MTA by default for F-14? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED, v2] orphaned packages in F-14
Taken libsigc++. Co-maintainers welcome. Cheers, Debarshi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum appmarket
seth vidal wrote: > I was just noodling around in the pkgtags db that I just posted about > and noticed that the a lot of pkgs have the 'Application' tag applied to > them. I could modify the appmarket plugin to use this information if it > is available. > > Coupling that data with tags like 'XFCE' it would be trivial to list > just xfce applications, for example. The database at https://admin.fedoraproject.org/pkgdb/apps/search/tanks would be more useful if you could search for "photoshop" and get "gimp, krita". Some more tags for "functionally comparable to" and the name of some well known programs for Windows or Macintosh would let people cope with the original names of Linux apps. Nero -> k3b, xcdroast Adobe Illustrator -> inkscape Adobe Reader -> evince, kpdf, okular This tags could also be added by the users, in a wiki like form. It is easy to build a good amount of useful information with a good specialized wiki, for example: http://www.thinkwiki.org/wiki/ThinkWiki -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mcelog errors
On Sun, 22 Aug 2010 09:45:47 -0600, Petrus wrote: > The mcelog script in cron.hourly runs hourly and, hourly, I get system mail > stating that > a "device does not exist". This is a regression, as this error was present in > rawhide > before f13 came out, and now, in f14α, it is back. Bugs are to be reported in bugzilla, e.g. via this convenient link: http://bugz.fedoraproject.org/mcelog -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
mcelog errors
The mcelog script in cron.hourly runs hourly and, hourly, I get system mail stating that a "device does not exist". This is a regression, as this error was present in rawhide before f13 came out, and now, in f14α, it is back. -- 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
F-14 Branched report: 20100822 changes
Compose started at Sun Aug 22 13:15:23 UTC 2010 Broken deps for x86_64 -- PragmARC-20060427-6.fc13.i686 requires libgnarl-4.4.so PragmARC-20060427-6.fc13.i686 requires libgnat-4.4.so PragmARC-20060427-6.fc13.x86_64 requires libgnarl-4.4.so()(64bit) PragmARC-20060427-6.fc13.x86_64 requires libgnat-4.4.so()(64bit) QuantLib-test-1.0.1-3.fc14.x86_64 requires libboost_unit_test_framework.so.1.41.0()(64bit) 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 1:anjuta-2.30.0.0-2.fc14.i686 requires libwebkit-1.0.so.2 1:anjuta-2.30.0.0-2.fc14.i686 requires libdevhelp-1.so.1 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libdevhelp-1.so.1()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit) antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 cairo-java-1.0.5-12.fc12.i686 requires libgcj.so.10 cairo-java-1.0.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) cyphesis-0.5.21-2.fc13.x86_64 requires libpython2.6.so.1.0()(64bit) easystroke-0.5.3-1.fc14.x86_64 requires libboost_serialization-mt.so.1.41.0()(64bit) ekg2-python-0.2-0.12.rc1.fc14.x86_64 requires libpython2.6.so.1.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libedata-book-1.2.so.2()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-1.2.so.17()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libgtkhtml-editor.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-provider-1.2.so.17()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libecal-1.2.so.7()(64bit) fmt-ptrn-java-1.3.20-5.fc13.i686 requires libgcj.so.10 fmt-ptrn-java-1.3.20-5.fc13.x86_64 requires libgcj.so.10()(64bit) frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_system-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_program_options-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_iostreams-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_serialization-mt.so.1.41.0()(64bit) glib-java-0.2.6-16.fc12.i686 requires libgcj.so.10 glib-java-0.2.6-16.fc12.x86_64 requires libgcj.so.10()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples libgconf-java-2.12.4-14.fc12.i686 requires libgcj.so.10 libgconf-java-2.12.4-14.fc12.x86_64 requires libgcj.so.10()(64bit) libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10 libglade-java-2.12.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10 libgnome-java-2.12.4-12.fc12.x86_64 requires libgcj.so.10()(64bit) libgtk-java-2.8.7-13.fc13.i686 requires libgcj.so.10 libgtk-java-2.8.7-13.fc13.x86_64 requires libgcj.so.10()(64bit) libopenvrml-0.18.6-1.fc14.i686 requires libboost_filesystem-mt.so.1.41.0 libopenvrml-0.18.6-1.fc14.i686 requires libboost_thread-mt.so.1.41.0 libopenvrml-0.18.6-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) libopenvrml-0.18.6-1.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) libopenvrml-gl-0.18.6-1.fc14.i686 requires libboost_filesystem-mt.so.1.41.0 libopenvrml-gl-0.18.6-1.fc14.i686 requires libboost_thread-mt.so.1.41.0 libopenvrml-gl-0.18.6-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) libopenvrml-gl-0.18.6-1.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) libpst-python-0.6.47-4.fc14.x86_64 requires libboost_python.so.1.41.0()(64bit) libvirt-qpid-0.2.18-1.fc14.x86_64 requires libqmf.so.1()(64bit) libvte-java-0.12.1-15.fc12.i686 requires libgcj.so.10 libvte-java-0.12.1-15.fc12.x86_64 requires libgcj.so.10()(64bit) matahari-0.0.5-1.fc14.x86_64 requires libqmf.so.1()(64bit) mine_detector-6.0-3.fc13.x86_64 requires libgnat-4.4.so()(64bit) mingw
Re: Python 3.2a1 in rawhide
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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED, v2] orphaned packages in F-14
Bill Nottingham píše v Pá 20. 08. 2010 v 16:25 -0400: > The attached list shows currently orphaned packages in F-14. If they are > not claimed by the end of next week, they will be blocked, potentially > breaking dependencies (and causing more things to be blocked...) > > If you already co-maintain the package, please step up and take it. > (If you don't, it may be assigned to you anyway.) Otherwise, volunteers would > be appreciated for those packages that other things require. > > Bill > > Orphan mapserver > comaintained by: devrim oliver Taken -- Pavel Lisy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100822 changes
Compose started at Sun Aug 22 08:15:21 UTC 2010 Broken deps for x86_64 -- OpenSceneGraph-libs-2.8.3-2.fc14.i686 requires libpoppler.so.6 OpenSceneGraph-libs-2.8.3-2.fc14.x86_64 requires libpoppler.so.6()(64bit) PragmARC-20060427-6.fc13.i686 requires libgnarl-4.4.so PragmARC-20060427-6.fc13.i686 requires libgnat-4.4.so PragmARC-20060427-6.fc13.x86_64 requires libgnarl-4.4.so()(64bit) PragmARC-20060427-6.fc13.x86_64 requires libgnat-4.4.so()(64bit) RackTables-0.18.3-1.fc15.noarch requires /usr/local/bin/php RackTables-0.18.3-1.fc15.noarch requires perl(File::FnMatch) RackTables-0.18.3-1.fc15.noarch requires perl(Net::Telnet::Cisco) 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 1:anjuta-2.30.0.0-2.fc14.i686 requires libwebkit-1.0.so.2 1:anjuta-2.30.0.0-2.fc14.i686 requires libvala.so.0 1:anjuta-2.30.0.0-2.fc14.i686 requires libdevhelp-1.so.1 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libdevhelp-1.so.1()(64bit) 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 cairo-java-1.0.5-12.fc12.i686 requires libgcj.so.10 cairo-java-1.0.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) cyphesis-0.5.21-2.fc13.x86_64 requires libpython2.6.so.1.0()(64bit) dpm-python3-1.7.4.7-3.fc14.x86_64 requires python(abi) = 0:3.1 dpm-python3-1.7.4.7-3.fc14.x86_64 requires libpython3.1.so.1.0()(64bit) emerillon-0.1.2-7.fc14.x86_64 requires librest-0.6.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libedata-book-1.2.so.2()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-1.2.so.17()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libgtkhtml-editor.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-provider-1.2.so.17()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libecal-1.2.so.7()(64bit) fmt-ptrn-java-1.3.20-5.fc13.i686 requires libgcj.so.10 fmt-ptrn-java-1.3.20-5.fc13.x86_64 requires libgcj.so.10()(64bit) frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) gedit-vala-0.6.1-1.fc13.x86_64 requires libvala.so.0()(64bit) gloobus-preview-0.4.1-6.fc14.x86_64 requires libpoppler.so.6()(64bit) 3:gnome-commander-1.2.8.7-1.fc14.x86_64 requires libpoppler.so.6()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) inkscape-0.48-0.4.20100505bzr.fc14.x86_64 requires libpoppler.so.6()(64bit) inkscape-view-0.48-0.4.20100505bzr.fc14.x86_64 requires libpoppler.so.6()(64bit) intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples lfc-python3-1.7.4.7-3.fc14.x86_64 requires libpython3.1.so.1.0()(64bit) lfc-python3-1.7.4.7-3.fc14.x86_64 requires python(abi) = 0:3.1 libextractor-plugins-pdf-0.6.1-1402.fc14.x86_64 requires libpoppler.so.6()(64bit) libgconf-java-2.12.4-14.fc12.i686 requires libgcj.so.10 libgconf-java-2.12.4-14.fc12.x86_64 requires libgcj.so.10()(64bit) libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10 libglade-java-2.12.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10 libgnome-java-2.12.4-12.fc12.x86_64 requires libgcj.so.10()(64bit) libgtk-java-2.8.7-13.fc13.i686 requires libgcj.so.10 libgtk-java-2.8.7-13.fc13.x86_64 requires libgcj.so.10()(64bit) libopenvrml-0.18.6-1.fc14.i686 requires libboost_filesystem-mt.so.1.41.0 libopenvrml-0.18.6-1.fc14.i686 requires libboost_thread-mt.so.1.41.0 libopenvrml-0.18.6-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) libopenvrml-0.18.6-1.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) libopenvrml-gl-0.18.6-1.fc14.i686 requires libboost_filesystem-mt.so.1.41.0 libopenvrml-gl-0.18.6-1.fc14.i686 requires libboost_thread-mt.so.1.41.0 libopenvrml-gl-0.18.6-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) libopenvrml-gl-0.18.6-1.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) libselinux-python3-2.0.96-3.fc14.x86_
