Re: packages: poppler/poppler.spec - explicitly disable gtk test
On Thu, Nov 12, 2009 at 11:36:48AM +0100, patrys wrote: Author: patrys Date: Thu Nov 12 10:36:48 2009 GMT Module: packages Tag: HEAD Log message: - explicitly disable gtk test why? wrobell wrob...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: python-psycopg2/python-psycopg2.spec - Release 2. Disabled agai...
On Fri, Jul 10, 2009 at 07:58:38AM +0200, matkor wrote: Author: matkor Date: Fri Jul 10 05:58:38 2009 GMT Module: packages Tag: HEAD Log message: - Release 2. Disabled again nonworking (in Th) conditional build with python-mx-DateTime Build was failing on missing python-mx-DateTime-devel headers. look, instead of discussing the thing, you are again starting stupid commit war. could you calm down a bit and think what are you doing, mate? regards, wrobell wrob...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: postgresql/postgresql.spec - rel 1 - looks good to me, blame rade...
On Thu, Jul 02, 2009 at 05:33:43PM +0200, baggins wrote: Author: baggins Date: Thu Jul 2 15:33:43 2009 GMT Module: packages Tag: HEAD Log message: - rel 1 - looks good to me, blame radek and wrobell if something is broken well, it builds, it starts and i am able to connect to a database... enjoy regards, wrobell wrob...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: util-vserver/util-vserver.spec, util-vserver/TODO (NEW) - move TO...
On Wed, May 13, 2009 at 01:53:38PM +0200, Pawel Golaszewski wrote: On Wed, 13 May 2009, Elan Ruusamäe wrote: On Wednesday 13 May 2009 13:44:38 blues wrote: $Log$ +Revision 1.225 2009/05/13 10:44:33 blues +- move TODO to separate file why? i liked the otherwise it's 1. in spec file, always around when you edit the file 3. nobody really goes to see what is in TODO, maybe i'm bored and i fix something. 2. PLD-doc/make-todo.sh scanned SPECS for TODO sections 4. if there are lots of SOURCES in package (like php for example), catching eye on TODO in `ls` is unlikely. Because: - it makes only noise in spec not true, because they are usually short - nobody goes to see TODO in spec too :) it is easy to spot todo in spec, imho - it's clean and nice - TODO can be not only for SPEC so what? it is about the package not spec - TODO can be vry long... any examples... even if there is one or two, then usually they are short if i reckon well wrobell wrob...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
cvs directory structure change (was: Re: INFO: cvs downtime)
On Tue, Apr 28, 2009 at 05:48:20PM +0200, Jan Rekorajski wrote: On Tue, 28 Apr 2009, Elan Ruusamäe wrote: [...] i'm just pissed that nobody warned such things like whole tree migrate are going to be done, just was only said it is going to be done, now, 20 minutes ago Sorry for this. I (at least) was afraid that posting something more elaborate would induce another flamewar and all will end in total failure. i propose to perform SCM migration in similar way. ;) but seriously, the information about the change could be titled something better than cvs downtime. may i suggest swine flu killer next time, so spam filters pick it up? ;) beside that, it is better now. thanks! regards, wrobell wrob...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
postgresql 8.4 beta 1
i have upgraded postgresql to version 8.4 beta 1 on DEVEL branch. it builds on th builders (test build only, if i understand arekm well, don't expect beta of postgresql in th) and seems to work on my machine. postgis, psycopg2 will follow on DEVEL branch in few days, i hope. enjoy. wrobell wrob...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: hudson.spec - deploy hudson in tomcat - is this a correct way to pac...
On Mon, Jan 26, 2009 at 10:05:21AM +0100, pawelz wrote: Author: pawelz Date: Mon Jan 26 09:05:21 2009 GMT Module: SPECS Tag: HEAD Log message: - deploy hudson in tomcat - is this a correct way to package .war apps? Please comment. It works out-of-the-box. If you have apache-tomcat installed, you can just rpm -ivh hudson and it works. 1. it would be nice to compile it from sources as it was decided long time ago, i.e. how do you want to apply a patch if required? .src.rpm won't contain source, just binary 2. hudson can be run standalone using embedded winstone http server, i would suggest putting tomcat related stuff into separate subpackage regards, wrobell wrob...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: hudson.spec - deploy hudson in tomcat - is this a correct way to pac...
On Mon, Jan 26, 2009 at 10:34:13PM +0100, Paweł Zuzelski wrote:
On Monday 26 of January 2009 20:22:38 wrobell wrote:
On Mon, Jan 26, 2009 at 10:05:21AM +0100, pawelz wrote:
Author: pawelz Date: Mon Jan 26 09:05:21 2009 GMT
Module: SPECS Tag: HEAD
Log message:
- deploy hudson in tomcat
- is this a correct way to package .war apps? Please comment. It works
out-of-the-box. If you have apache-tomcat installed, you can just
rpm -ivh hudson and it works.
[...]
2. hudson can be run standalone using embedded winstone http server,
i would suggest putting tomcat related stuff into separate subpackage
It would be great to have subpackages: hudson-tomcat and hudson-standalone
(hudson-jboss, hudson-my-fovorite-application-server)? If there is anyone who
want to maintain and use other configurations than hudson-tomcat, feel free
to split hudson into subpackages. I need hudson only as an application inside
tomcat.
i do understand, but from the start you put dependencies, which are not
needed... if one uses jboss, geronimo or whatever.
And what do you think about deploing apps into tomcat using rpm? AFAIK no
other distro does it this way (am I right?).
imho, that's nice. the only problem i see if you start to put tomcat
dependency on every java lib/app we have :) so i would suggest subpackages :)
BTW thanks for comments.
no problem, commenting is easy :)
regards,
wrobell wrob...@pld-linux.org
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: template-python.spec - python 2.4 is only in AC line, let's use (kin...
On Fri, Jan 23, 2009 at 12:52:40PM +0200, Elan Ruusamäe wrote: On Friday 23 January 2009 02:30:52 wrobell wrote: but i do care. i really want to know why i am supposed to maintain some support for obsolete software on HEAD. my only conclusion is - AC line. what support? you don't have to _add_ anything, it it's present, leave it, don't touch it? for example, please take a look at commit fight around mx.DateTime in python-psycopg2.spec. the ones, who constantly were reverting my changes never bothered to contact me or to respond why they are doing that. so, please, respect my time, ok? [...] regards, wrobell wrob...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: template-python.spec - python 2.4 is only in AC line, let's use (kin...
On Thu, Jan 22, 2009 at 07:18:57AM +0100, Jakub Bogusz wrote:
On Thu, Jan 22, 2009 at 02:10:57AM +0100, wrobell wrote:
Author: wrobell Date: Thu Jan 22 01:10:57 2009 GMT
Module: SPECS Tag: HEAD
Log message:
- python 2.4 is only in AC line, let's use (kinda) agreed pld release bcond
instead of py_ver usage to not introduce more mess on HEAD
@@ -46,7 +46,7 @@
%doc AUTHORS CREDITS ChangeLog NEWS README THANKS TODO
%{py_sitedir}/*.py[co]
%attr(755,root,root) %{py_sitedir}/*.so
-%if %{py_ver} 2.4
+%if %{pld_release} == ac
%{py_sitedir}/TEMPLATE-*.egg-info
%endif
Why mess? This is exact condition.
If some day Ac goes to python 2.5 (unlikely, but...), such distro-line
conditions will need to be changed.
so new bcond for other languange in AC. for some framework new bcond as
well... and so on? do you want to track all of them?
regards,
wrobell wrob...@pld-linux.org
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: template-python.spec - python 2.4 is only in AC line, let's use (kin...
Patryk Zawadzki writes: On Thu, Jan 22, 2009 at 10:49 AM, wrobell wrob...@pld-linux.org wrote: On Thu, Jan 22, 2009 at 07:18:57AM +0100, Jakub Bogusz wrote: Why mess? This is exact condition. If some day Ac goes to python 2.5 (unlikely, but...), such distro-line conditions will need to be changed. so new bcond for other languange in AC. for some framework new bcond as well... and so on? do you want to track all of them? The whole point being: egg-info files are python 2.5+-specific, not Th-specific. good point :] some want to support AC on HEAD - that's all. we do _not_ want to support python 2.4 on HEAD, do we? well, until you want to live in hell :P it is really amazing. we started with one ac bcond in xulrunner.spec and we will have over 20 specs affected (python), more when the rest follows. i wonder who will cleanup this mess in the future. regards, wrobell wrob...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: python-psycopg2.spec - Release 3. Killed nonworking mx bcond. Prepar...
Radoslaw Zielinski writes: wrobell wrob...@pld-linux.org [22-01-2009 02:43]: [...] i changed my mind. AC bcond is used. hope that's ok and it won't invoke any fucking cvs commit war. That's what branches are for. Creating mess in specs for a decaying distro line doesn't sound like a good idea to me. i know. you really do not have to convince me. see thread about ac bcond in xulrunner.spec about month ago. regards, wrobell wrob...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: python-psycopg2.spec - Release 3. Killed nonworking mx bcond. Prepar...
On Tue, Dec 23, 2008 at 10:48:41AM +, wrobell wrote:
On Fri, Dec 19, 2008 at 06:19:19PM +, wrobell wrote:
On Fri, Dec 19, 2008 at 09:49:35AM +0100, matkor wrote:
Author: matkor Date: Fri Dec 19 08:49:34 2008 GMT
Module: SPECS Tag: HEAD
Log message:
- Release 3. Killed nonworking mx bcond. Prepared for Ac.
now, if somebody wants to to compile psycopg, then he has to build it with
mx.DateTime, which
- is non-standard
- i don't know any modern application, which uses it
what's the point? is it for python 2.4 and Ac? then just do that on ac
branch, please.
at least, you could leave mx bcond and explain why it is not working for
you.
no answer so far and my understanding is that matkor's change was due to
python 2.4 in ac. therefore my proposal to solve this conflict is as
follows
- i will move python-psycopg2.spec to AC-branch
- i will revert HEAD of the spec to previous version and upgrade it
to 2.0.8
- if distro line bconds (whatever you call it) are allowed on HEAD,
then matkor, please use the distro line bcond instead of py_ver hack
(to not introduce more mess), but please leave mx bcond for those
who would like to use it[1]
i changed my mind. AC bcond is used. hope that's ok and it won't invoke any
fucking cvs commit war.
regards,
wrobell wrob...@pld-linux.org
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: TeXLive again
On Sat, Dec 27, 2008 at 07:16:33PM +0100, Przemyslaw Iskra wrote: On Sat, Dec 27, 2008 at 04:36:52PM +0100, Zsolt Udvari wrote: First: you must set TEXMFMAIN environment variable (this maybe isn't error, but would be nice when shouldn't set). Second: it missed *.fmt and I don't know how can I create. This the biggest problem. It's done. Next problem: sometimes needs to create fonts, and there are few possibilities: - create the fonts to $HOME/.texlive-2008 directory - imho this is not too good solution - create the fonts to /var/lib/texmf (or any other directory) - it's the better, but there are problems with this. It must be writeable by all users. The idea, that its owner/group is 'texmf', and some files of texlive has sgid, doesn't work, because it calls 'mkdir', 'cp'. What should I do? Could you tell us more about those fonts ? As far as I understand this is just some font cache. - Is it generated for every shape and size ? - How big are those files, compared to source ? - How much time does it take to generate them ? - How often same cache is used ? How probable is that different users will be interested in same font cache ? Maybe we could generate this cache for fonts we distribute and place it somewere under /usr/share ? And if a user needs some additional fonts she could just use that $HOME/.tex... directory. that's bit complicated. if you use different dpi for you dvi documents, then fonts should be regenerated for you. for sure people are using 300dpi, 600dpi, but... you never know :) wrobell wrob...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: TeXLive again
On Sat, Dec 27, 2008 at 04:36:52PM +0100, Zsolt Udvari wrote: First: you must set TEXMFMAIN environment variable (this maybe isn't error, but would be nice when shouldn't set). Second: it missed *.fmt and I don't know how can I create. This the biggest problem. It's done. Next problem: sometimes needs to create fonts, and there are few possibilities: - create the fonts to $HOME/.texlive-2008 directory - imho this is not too good solution - create the fonts to /var/lib/texmf (or any other directory) - it's the better, but there are problems with this. It must be writeable by all users. The idea, that its owner/group is 'texmf', and some files of texlive has sgid, doesn't work, because it calls 'mkdir', 'cp'. What should I do? that was solved in tetex.spec, isn't it? /var/cache/fonts has sticky bit if i reckon well. wrobell wrob...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: libdrm 2.4.3 = X segfault
On Wed, Dec 24, 2008 at 12:55:56PM +0100, Radoslaw Zielinski wrote: After upgrading libdrm to 2.4.3, my X have segfaulted like this: Backtrace: 0: /usr/bin/Xorg(xorg_backtrace+0x3b) [0x8120717] 1: /usr/bin/Xorg(xf86SigHandler+0x4d) [0x80b7980] 2: [0xb80c5400] 3: /usr/lib/xorg/modules/drivers//intel_drv.so [0xb7b97400] 4: /usr/lib/xorg/modules/drivers//intel_drv.so [0xb7b98c36] 5: /usr/bin/Xorg(AddScreen+0x184) [0x806ac36] 6: /usr/bin/Xorg(InitOutput+0x1f7) [0x809fff8] 7: /usr/bin/Xorg(main+0x276) [0x806b3e9] 8: /lib/libc.so.6(__libc_start_main+0xee) [0xb7cf46ee] Fatal server error: Caught signal 11. Server aborting Full log: http://radek.cc/Xorg.0.log which version of kernel? regards, wrobell wrob...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: python-psycopg2.spec - Release 3. Killed nonworking mx bcond. Prepar...
On Tue, Dec 23, 2008 at 04:36:55PM +0200, Elan Ruusamäe wrote: On Tuesday 23 December 2008 12:48:41 wrobell wrote: - if distro line bconds (whatever you call it) are allowed on HEAD, forbidding it, is like forbidding commits to SPECS module, i'll continue add them if i find it better than making AC-branch, and likely same applies to Titanium branch and hawk's family. please, use the other thread. wrobell wrob...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: xulrunner.spec and ac bcond
On Tue, Dec 23, 2008 at 04:34:52PM +0200, Elan Ruusamäe wrote: On Monday 22 December 2008 20:43:48 wrobell wrote: On Mon, Dec 22, 2008 at 01:17:11PM +0200, Elan Ruusamäe wrote: On Monday 22 December 2008 11:22:42 wrobell wrote: On Fri, Dec 19, 2008 at 07:35:54PM +0100, Pawel Golaszewski wrote: On Fri, 19 Dec 2008, wrobell wrote: as i know we have ac branch for ac distro line. what's the point of ac bcond in xulrunner.spec? I think it's good direction when the difference is only in BR's or some simple configure options. There is no point in branching for so simple things. one question, though. if one of the distro lines dies, then who is going to clean up the conditionals introduced by such distro line? you can always do cvs annotate and ask whoever added it... to be honest, that's too optymistic statement. but... will you? i'l complete the sentence: and ask whoever added it, whether you can remove it. i don't say how things should be, i just say how they are... well... me too :) my point is that it is really easy to remove a branch or a tag from CVS, but it is a lot of work to remove the bconds from multiple specs. regards, wrobell wrob...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: xulrunner.spec and ac bcond
On Fri, Dec 19, 2008 at 07:35:54PM +0100, Pawel Golaszewski wrote: On Fri, 19 Dec 2008, wrobell wrote: as i know we have ac branch for ac distro line. what's the point of ac bcond in xulrunner.spec? I think it's good direction when the difference is only in BR's or some simple configure options. There is no point in branching for so simple things. one question, though. if one of the distro lines dies, then who is going to clean up the conditionals introduced by such distro line? wrobell wrob...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: xulrunner.spec and ac bcond
On Mon, Dec 22, 2008 at 01:17:11PM +0200, Elan Ruusamäe wrote: On Monday 22 December 2008 11:22:42 wrobell wrote: On Fri, Dec 19, 2008 at 07:35:54PM +0100, Pawel Golaszewski wrote: On Fri, 19 Dec 2008, wrobell wrote: as i know we have ac branch for ac distro line. what's the point of ac bcond in xulrunner.spec? I think it's good direction when the difference is only in BR's or some simple configure options. There is no point in branching for so simple things. one question, though. if one of the distro lines dies, then who is going to clean up the conditionals introduced by such distro line? you can always do cvs annotate and ask whoever added it... to be honest, that's too optymistic statement. but... will you? best regards, wrobell wrob...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: xulrunner.spec and ac bcond
On Sat, Dec 20, 2008 at 02:04:39PM +0100, Pawel Golaszewski wrote: On Fri, 19 Dec 2008, wrobell wrote: as i know we have ac branch for ac distro line. what's the point of ac bcond in xulrunner.spec? I think it's good direction when the difference is only in BR's or some simple configure options. There is no point in branching for so simple things. it is messy as you need to look at distro line i 3 ways - trunk (no changes) - ac branch - and now ac bcond No, there should be always AC branch/tag for last version that s prepared for AC. It's easier to move tag/branch than merge changes. i really don't mind until specs get messy. your choice guys. so just to state it loud. we do allow distro line bconds like ra, ac, and ti. there shall be no th bconds as it is trunk forever. is that ok for everyone? [...] wrobell wrob...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: python-psycopg2.spec - Release 3. Killed nonworking mx bcond. Prepar...
On Fri, Dec 19, 2008 at 09:49:35AM +0100, matkor wrote: Author: matkor Date: Fri Dec 19 08:49:34 2008 GMT Module: SPECS Tag: HEAD Log message: - Release 3. Killed nonworking mx bcond. Prepared for Ac. now, if somebody wants to to compile psycopg, then he has to build it with mx.DateTime, which - is non-standard - i don't know any modern application, which uses it what's the point? is it for python 2.4 and Ac? then just do that on ac branch, please. at least, you could leave mx bcond and explain why it is not working for you. best regards, wrobell wrob...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
xulrunner.spec and ac bcond
as i know we have ac branch for ac distro line. what's the point of ac bcond in xulrunner.spec? best regards, wrobell wrob...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: xulrunner.spec and ac bcond
On Fri, Dec 19, 2008 at 07:35:54PM +0100, Pawel Golaszewski wrote: On Fri, 19 Dec 2008, wrobell wrote: as i know we have ac branch for ac distro line. what's the point of ac bcond in xulrunner.spec? I think it's good direction when the difference is only in BR's or some simple configure options. There is no point in branching for so simple things. it is messy as you need to look at distro line i 3 ways - trunk (no changes) - ac branch - and now ac bcond and i bet it will kick our asses sooner or later. people will abuse the bcond thing. moreover, it already happens with python-psycopg2.spec to build psycopg with python 2.4. we will end up with mess. best regards, wrobell wrob...@pld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: TeXLive
On Fri, Nov 28, 2008 at 06:35:29PM +0100, Zsolt Udvari wrote: Hi folks! I want to create texlive.spec, and it's under developing. I use the tetex.spec as the beginning, but I've a question: should I split more subpackages the texlive package? What I think: the style-files, documentclass-files, e.g. exam.cls put into texlive-latex-exam, etc. When you think it, I make it. Imho it would be better (nearer to pld-philosphy: http://www.pld-linux.org/Features - Micropackages). well, tetex.spec went bit nuts :) i do remember that tetex package split gave us real HDD space[1] and network usage[2] savings, so it is worth the effort. for example, tetex-*context* packages, which i don't use, are over 38MB in size (to download). if you know that adding some subpackage will save several MB in size, then why not. otherwise i would not bother. regards, wrobell [EMAIL PROTECTED] [1] my asus eee pc has 4GB of storage, so don't event try to tell me that sdd space is cheap [2] i am accessing internet via 3G, so please don't tell me that bandwith is cheap, as well ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: TeXLive
On Sat, Dec 06, 2008 at 05:19:41PM -0500, Jeff Johnson wrote: On Dec 6, 2008, at 4:41 PM, wrobell wrote: [1] my asus eee pc has 4GB of storage, so don't event try to tell me that sdd space is cheap [2] i am accessing internet via 3G, so please don't tell me that bandwith is cheap, as well Well asus eee is not exactly representative hqrdware, and 3G doesn't exactly supply bandwidth yet, are the flaws in your reasoning abt packaging. you are right for asus eee pc, but still... it is nice to have tetex on it and not waste over 60MB in unneeded stuff. hence, pld on my machine instead of other distro. in case of 3G... well... let's allow the flame to start. i don't mind 10KB/s download speeds (as _not_ advertised) but 1GB for 9.99eu or 0.49eu for 1MB if you are over your limit is not cheap. for me, at least. But points noted fer sure, TeX is not easy packaging, never has been. indeed :) best regards, wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: TeXLive
On Sat, Dec 06, 2008 at 06:05:57PM -0500, Jeff Johnson wrote: On Dec 6, 2008, at 5:35 PM, wrobell wrote: But points noted fer sure, TeX is not easy packaging, never has been. indeed :) Note I dinna say either of (Diskspace|bandwidth) is cheap. Being stoopid is way more costly than commodity items. Ugly and evil have the same flaws. well, every time, we started to talk about splitting packages on this list, somebody claimed that something (cpu, bandwidth, disk space) is cheap, hence my off-topic remarks. but it seems, that if one tries to prevent stupid discussion about somebody's dick length[1], then we are ending up with an off-topic, philosophical thread. my fault, lesson learnt. [...] regards, wrobell [EMAIL PROTECTED] [1] my desktop machine is so huuug, baby ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: Zope-Interface.spec - package site-packages/zope as no other package...
On Fri, Sep 19, 2008 at 08:08:44PM +0200, patrys wrote: Author: patrys Date: Fri Sep 19 18:08:44 2008 GMT Module: SPECS Tag: HEAD Log message: - package site-packages/zope as no other package from ftp uses it - rel 2 Zope-dirs.spec provides it. wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: python macros
On Mon, Nov 10, 2008 at 04:11:54AM +0200, Elan Ruusamäe wrote: 1. what's the point of such macros? $ rpm -E '%pyrequires_eq python-libs' Requires: python-libs $ rpm -E '%pyrequires_eq python-modules' Requires: python-modules in the past it was evaluating to Requires: python-modules = 2.5 2.6 (assuming that you python 2.5 is installed) who changed that and why... i have no idea. having the pyrequires_eq macro in current state is pointless. see cvs log rpm-macros.python cvs up -r 1.4 rpm-macros.python [...] wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
pld on asus eee pc 701
i have just installed th pld linux on asus eee pc 701. if anybody wants to share some experiences, then... regards, wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: jakarta-commons-*.spec naming
On Fri, Oct 03, 2008 at 11:06:32PM +0300, Elan Ruusamäe wrote: On Friday 03 October 2008 22:24:19 Jacek Konieczny wrote: On Fri, Oct 03, 2008 at 10:04:52PM +0300, Elan Ruusamäe wrote: i understand that we need to rename packages that have moved to http://commons.apache.org how do we call them? - apache-commons-io (*) - commons-io - java-commons-io - java-apache-commons-io (*) i prefer this one, unless it rises some additional confusion or restruction due name use... I prefer the third (java-commons-io) and I would be happy to see similar change for all java libraries. This way they would be grouped like python or perl modules. And there would be no confusion because of the http server in 'apache' package or because library names looking like application names. sounds sane, but this (java- prefix) would apply only to libraries not applications? i mean tomcat, jAlbum won't be named as java-apache-tomcat, java-jAlbum, java-gallery-remote.. ? only libs like in case of python, i.e. python-psycopg2 (lib) but gaphor (an app). wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Packaging .py files
On Thu, Jul 17, 2008 at 07:47:31PM +0200, Patryk Zawadzki wrote:
[...]
Not to mention the friggin' codegen.{py,pyc} substitution we need to
do for most of the packages containing bindings.
just propose the patch. if good, i bet it will be accepted. at least
it was always in my case - every patch solving lack of .py files was
applied against sources of given project.
[...]
wrobell [EMAIL PROTECTED]
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Packaging .py files
On Fri, Jul 18, 2008 at 01:24:13AM +0200, Mariusz Mazur wrote: [...] This means that Th contains ~45% of potential (in pure theory) packages available in PLD. Additionally: 67% of Th packages are patched with also almost 1.5 patches on average. sad truth is, that a lot of patches is not sent to project maintainers. this way we need to perform more work while upgrading packages. our problem is communication with outside world and marketing, not pld save-the-world-by-geeks approach. [...] wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: PLD-specs-TODO
On Sat, May 24, 2008 at 01:27:56PM +0200, Bartosz Taudul wrote: On Sat, May 24, 2008 at 11:46:49AM +0200, Tomasz Pala wrote: +1 +1 -1 -57 *2 wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: beagle.spec - added missing files, nfy
hi, beagle main package contains beagled binary but all the configuration files are in beagle-crawl-system package. is it a mistake or was it done on purpose? regards, wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: pldlinux.pl for PLD Linux purposes
On Sun, Mar 23, 2008 at 08:03:00PM +0100, Wojciech Błaszkowski wrote: [...] pldlinux.pl is only to protect PLD Linux mark. pld-linux.pl or pldlinux.pl? imho, adding pldlinux.* will generate more confusion. can't we stick with pld-linux.*? regards, wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm --root problem
On Sun, Mar 23, 2008 at 09:42:32AM +0100, Andrzej 'The Undefined' Dopierała wrote: On Sun, Mar 23, 2008 at 03:31:51AM +, wrobell wrote: i am trying to install some packages in chroot using rpm # rpm --root /home/new-sys -qa gpg-pubkey-e64e7bf7-47b35206.(none) # rpm --root /home/new-sys -i --ignorearch --ignoreos rpms/setup-2.4.11-2.i686.rpm warning: rpms/setup-2.4.11-2.i686.rpm: Header V3 DSA signature: NOKEY, key ID e4f1bc2d warning: package file rpms/setup-2.4.11-2.i686.rpm was skipped rpm -vv ... ? # rpm -vv --root /home/new-sys -i --ignorearch --ignoreos rpms/setup-2.4.11-2.i486.rpm D: == rpms/setup-2.4.11-2.i486.rpm D: Expected size: 188060 = lead(96)+sigs(344)+pad(0)+data(187620) D: Actual size: 188060 D: opening db environment /home/new-sys/var/lib/rpm/Packages cdb:mpool D: opening db index /home/new-sys/var/lib/rpm/Packages rdonly mode=0x0 D: locked db index /home/new-sys/var/lib/rpm/Packages D: opening db index /home/new-sys/var/lib/rpm/Pubkeys rdonly mode=0x0 warning: rpms/setup-2.4.11-2.i486.rpm: Header V3 DSA signature: NOKEY, key ID e4f1bc2d warning: package file rpms/setup-2.4.11-2.i486.rpm was skipped D: found 0 source and 0 binary packages D: closed db index /home/new-sys/var/lib/rpm/Pubkeys D: closed db index /home/new-sys/var/lib/rpm/Packages D: closed db environment /home/new-sys/var/lib/rpm/Packages just to make things clear. i am installing i486/i686 packages in chroot on ppc box. let's skip ignorearch/ignoreos rpm parameters: # rpm -vv --root /home/new-sys -i rpms/setup-2.4.11-2.i486.rpm D: == rpms/setup-2.4.11-2.i486.rpm D: Expected size: 188060 = lead(96)+sigs(344)+pad(0)+data(187620) D: Actual size: 188060 D: opening db environment /home/new-sys/var/lib/rpm/Packages cdb:mpool D: opening db index /home/new-sys/var/lib/rpm/Packages rdonly mode=0x0 D: locked db index /home/new-sys/var/lib/rpm/Packages D: opening db index /home/new-sys/var/lib/rpm/Pubkeys rdonly mode=0x0 warning: rpms/setup-2.4.11-2.i486.rpm: Header V3 DSA signature: NOKEY, key ID e4f1bc2d warning: package file rpms/setup-2.4.11-2.i486.rpm was skipped D: found 0 source and 0 binary packages D: closed db index /home/new-sys/var/lib/rpm/Pubkeys D: closed db index /home/new-sys/var/lib/rpm/Packages D: closed db environment /home/new-sys/var/lib/rpm/Packages i would expect 'incorrect architecture' rpm error. it seems that, when using --root option, rpm misbehaves completely. bad kid! ;) regards, wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm --root problem
On Sun, Mar 23, 2008 at 07:16:20AM -0400, Jeff Johnson wrote: [...] i would expect 'incorrect architecture' rpm error. You can expect anything of rpm you wish, everyone does! :))) well... it is hard to live without rpm :))) it seems that, when using --root option, rpm misbehaves completely. bad kid! ;) You have any number of ways to install ppc *.rpm packages on i386, in chroot's, with qemu, in VMWare instances and more. Try rpm2cpio for starters. Or add regex's to /etc/rpm/platform to configure arch compatibility. Never mind that ppc binaries will never execute on ix86, and so installing without disabling scriptlets and triggers will instantly segfault. right! i did not think about it :) But if segfault's are your idea of compatiblity, by all means, configure /etc/rpm/platform regex patterns to make ppc packages compatible with ix86. thanks for suggestions. indeed, rpm2cpio seems to be the best option, now. regards, wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
rpm --root problem
i am trying to install some packages in chroot using rpm
# rpm --root /home/new-sys -qa
gpg-pubkey-e64e7bf7-47b35206.(none)
# rpm --root /home/new-sys -i --ignorearch --ignoreos
rpms/setup-2.4.11-2.i686.rpm
warning: rpms/setup-2.4.11-2.i686.rpm: Header V3 DSA signature: NOKEY, key
ID e4f1bc2d
warning: package file rpms/setup-2.4.11-2.i686.rpm was skipped
# rpm --root /home/new-sys -qa
gpg-pubkey-e64e7bf7-47b35206.(none)
as you can see above, installation of a package was not performed.
rpm reported no error.
i am trying to install i686 arch rpms on ppc box, thus the ignore{arch,os}
options.
any hints?
regards,
wrobell [EMAIL PROTECTED]
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: OE and PLD
On Sun, Dec 02, 2007 at 01:00:42AM +0100, Mateusz Kijowski wrote: Hi, I have been trying to bootstrap OpenEmbedded in PLD for a while. I was hitting my head against a wall with gettext-native failing to link ( /bin/sh was complaining on libtool spitting out bad substitution ). The problem was /bin/sh pointing to /bin/ksh . I managed it by linking /bin/sh to /bin/bash manualy, but I'm not sure if it's is the right solution. well, it means that they have some nice bashisms there :) i would rip them off and send appropriate patch to OE team. if you need some help with that, then just post here. there is always some anti-bash guru here ;) Also, to ease starting OE development in PLD I was thinking of creating a openembedded-essentials package which would at least depend on necessary packages. Any comments? just go ahead :) regards, wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: vim languages
On Tue, Aug 07, 2007 at 01:30:02PM +0200, Mariusz Mazur wrote: Dnia wtorek, 7 sierpnia 2007, Pawel Golaszewski napisał: On Mon, 6 Aug 2007, Mariusz Mazur wrote: any comments? The basic packages should be 'low reqs' and 'high reqs' (which translates to -- no langs and all langs). Anything in between should be left to ppl directly interested. All-or-nothing isn't the best choice... I think that there should be 3 possibilities: - vim like in current packages we know. It would be nice to keep it. - vim-tiny (or minimal) - for monks - vim-full - for those who like all the bells and whistles What's the difference between current vim and vim-full? current vim shall not be full. for very long period of time there were no complaints because of vim non-fullness if i remember well :] maybe everyone is on holidays now, but it seems that switching off languages is ok for now. if somebody needs all of them, then... vim-full? regards, wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
vim languages
speaking about ruby/python/tcl/perl support in vim. i would like to switch off above languages support by default (as it was almost always before, excluding perl for some reasons). if one needs support for specific language, then please create new subpackage (i.e. vim-python). the reason is that i doubt that any of us writes scripts in *all* above languages for vim. but if one really needs all of them, then please create vim-lang-all (or something). any comments? regards, wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: vim.spec - with python,
On Mon, Jun 18, 2007 at 04:41:28PM +0200, Andrzej Krzysztofowicz wrote: Mariusz Mazur wrote: Dnia poniedziałek, 18 czerwca 2007, Andrzej Krzysztofowicz napisał: OO. For all the minimum requirements there's always vim-static and e3. -static is in contradiction with minimum. Yup. We should have full vim with everything (X, python, perl, ruby, brainfuck, you name it) and a vim-minimal for those, that want to have the lightest version possible. Agreed. what's the current conclusion? regards, wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: vim.spec - with python, ruby and tcl by default - rel 3 for...
On Sun, Jun 17, 2007 at 05:41:19PM +0200, Jakub Bogusz wrote: On Tue, Jun 05, 2007 at 05:20:07PM +0200, czarny wrote: Author: czarny Date: Tue Jun 5 15:20:07 2007 GMT Module: SPECS Tag: HEAD Log message: - with python, ruby and tcl by default IIRC this makes vim binary depend on python, ruby and tcl libraries. Is it worth its profits? imho it should be off by default. if one wants fat vim, then please create vim-enahnced/vim-fat/whatever packages. regards, wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [RFC] Repository layout chan ge / Zmiana układu repo
On Tue, May 15, 2007 at 12:13:36AM +0200, Jakub Bogusz wrote: On Sun, May 13, 2007 at 09:28:52PM +0100, wrobell wrote: On Sun, May 13, 2007 at 09:58:06PM +0200, Patryk Zawadzki wrote: [...] What are the problems? The so called problems are the rare situations where you need to grep through ALL the spec files. This could easily be solved by a tool like adapter, builder, recompile, repackage and other scripts that are there just to help you in certain situations. grep -r ? Wrong, it will grep not only specs, but also sources and whole overgrown metadata, taking more time and returning some junk matches outside specs. grep -r --include \*.spec regex . [...] wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [RFC] Repository layout chan ge / Zmiana układu repo
On Sun, May 13, 2007 at 09:58:06PM +0200, Patryk Zawadzki wrote: [...] What are the problems? The so called problems are the rare situations where you need to grep through ALL the spec files. This could easily be solved by a tool like adapter, builder, recompile, repackage and other scripts that are there just to help you in certain situations. grep -r ? :) wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [RFC] Repository layout chan ge / Zmiana układu repo
On Sun, May 13, 2007 at 11:02:41PM +0200, Radoslaw Zielinski wrote: Patryk Zawadzki [EMAIL PROTECTED] [13-05-2007 21:58]: [...] others. But, if we want to switch to anything else, we have to change the repository layout from flat SPECS/SOURCES to dir-per-package, because any other CMS won't handle such layout (you can imagine how would SVN repo look like - a ~milion directories, and GIT just doesn't scale - I did a test on SPECS and got a monstrosity). This clearly shows problems with *other* VC systems. There is no point in switching. It would create more problems than it'd solve. What are the problems? Off the top of my head: - excessive metadata (CVS/Entries is just a few dozen bytes per file) - $Log$ - existing tools / macros / aliases / one liners / whatever We have tamed CVS over the years and know how to deal with its shortcomings. The only real unsolved problem is lack of cvs mv, but this could be changed with far less work than changing VCS, if someone cared enough. lack of mv... and also - off-line diff - revert (on-line/off-line) - atomic commit - lack of something like svk for svn (or i am just not aware) anyway, it was all discussed several times, so... eot? :) wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [RFC] Repository layout chan ge / Zmiana układu repo
On Mon, May 14, 2007 at 12:07:01AM +0200, Radoslaw Zielinski wrote: wrobell [EMAIL PROTECTED] [13-05-2007 23:22]: On Sun, May 13, 2007 at 11:02:41PM +0200, Radoslaw Zielinski wrote: [...] We have tamed CVS over the years and know how to deal with its shortcomings. The only real unsolved problem is lack of cvs mv, but this could be changed with far less work than changing VCS, if someone cared enough. lack of mv... and also - off-line diff - revert (on-line/off-line) rm cvs up; you can't do much being offline anyway. i can: diff and revert. that's what would be nice to have, so please... - atomic commit Blah. nice answer for pro cvs arguments, thanks ;) :P - lack of something like svk for svn (or i am just not aware) You mean for CVS (as svk with svn Just Works)? According to svk h svk with svn just works. mi|grep cvs it's supported, but I couldn't get it to work last time I tried... That would also fix the online diff issue. no one cares about cvs, now. this is the main issue for me. wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS (DEVEL): gnome-utils.spec - floppy subpackage is back; updat...
On Tue, Mar 06, 2007 at 11:10:59PM +0200, Elan Ruusamäe wrote: On Tuesday 06 March 2007, Jan Rekorajski wrote: -Requires: gnome-vfs2 = 2.16.2 -Requires: libgnomeui = 2.16.1 +Requires(post,preun): GConf2 +Requires: gnome-vfs2 = 2.17.91 +Requires: libgnomeui = 2.17.92 [cut] shouldn't then runtime deps should be done with %requires_eq/%requires_eq_to then? Lucky for us it's not _that_ bad :) It's just GNOME 2.x needs libs 2.x.*, so %requires_eq/%requires_eq_to would be an overkill. so, why not use = 2.17 without minor version because you sometimes get into trouble (experienced myself). it's good thing. regards, wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [Th] libtool(/usr/lib/*.la) dependencies
On Mon, Jan 01, 2007 at 04:35:24PM +0100, Tomasz Pala wrote:
Hello,
I don't know if I've missed something, but is this really necessary to
install *-devel subpackages for things like:
koffice-kword-1.6.0-1 marks pcre-devel-7.0-1 (cap
libtool(/usr/lib/libpcre.la))
or is this only effect of 'file-issue'?
The same for subversion and apr-util.
1) perl-subversion-1.4.2-2 marks apr-util-devel-1.2.8-2.1 (cap
libtool(/usr/lib/libaprutil-1.la))
2) perl-subversion-1.4.2-2 marks subversion-devel-1.4.2-2 (cap
libtool(/usr/lib/libsvn_delta-1.la))
3) apr-util-devel-1.2.8-2.1 marks mysql-devel-5.1.14-2 (cap
libtool(/usr/lib/libmysqlclient_r.la))
Ad 1) and Ad 2) Both are unnecessary, obviously.
Ad 3)
apr-util modularizes database support (i.e. postgresql, sqlite) and *-devel
stuff
really does not require mysql devel stuff. Moreover mysql stuff is not even
part of official apr-util distribution (see source no 1 in apr-util.spec).
The whole poldek output:
Processing dependencies...
subversion-1.4.2-1 obsoleted by subversion-1.4.2-2
greedy upgrade subversion-svnserve-1.4.2-1 to 1.4.2-2 (unresolved subversion
= 1.4.2-1)
subversion-svnserve-1.4.2-1 obsoleted by subversion-svnserve-1.4.2-2
subversion-1.4.2-2 marks subversion-libs-1.4.2-2 (cap subversion-libs = 1.4.2-2)
subversion-libs-1.4.2-1 obsoleted by subversion-libs-1.4.2-2
greedy upgrade perl-subversion-1.4.2-1 to 1.4.2-2 (unresolved
subversion-libs = 1.4.2-1)
perl-subversion-1.4.2-1 obsoleted by perl-subversion-1.4.2-2
There are more than one package which provide
libtool(/usr/lib/libaprutil-1.la):
a) apr-util-devel-1.2.8-2.1
b) apr-util-devel-1.2.8-2
c) apr-util-devel-1.2.8-1
Which one do you want to install ('Q' to abort)? [a]
perl-subversion-1.4.2-2 marks apr-util-devel-1.2.8-2.1 (cap
libtool(/usr/lib/libaprutil-1.la))
apr-util-devel-1.2.8-2.1 marks apr-util-1.2.8-2.1 (cap apr-util =
1:1.2.8-2.1)
apr-util-1.2.8-1 obsoleted by apr-util-1.2.8-2.1
apr-util-devel-1.2.8-2.1 marks mysql-devel-5.1.14-2 (cap
libtool(/usr/lib/libmysqlclient_r.la))
mysql-devel-5.1.14-2 marks mysql-libs-5.1.14-2 (cap mysql-libs =
5.1.14-2)
mysql-libs-5.0.27-3 obsoleted by mysql-libs-5.1.14-2
perl-subversion-1.4.2-2 marks subversion-devel-1.4.2-2 (cap
libtool(/usr/lib/libsvn_delta-1.la))
subversion-devel-1.4.2-2 marks neon-devel-0.26.2-1 (cap
libtool(/usr/lib/libneon.la))
greedy upgrade python-subversion-1.4.2-1 to 1.4.2-2 (unresolved
subversion-libs = 1.4.2-1)
python-subversion-1.4.2-1 obsoleted by python-subversion-1.4.2-2
There are 11 packages to install (10 marked by dependencies), 7 to uninstall:
I subversion-1.4.2-2
D apr-util-1.2.8-2.1, apr-util-devel-1.2.8-2.1, mysql-devel-5.1.14-2,
mysql-libs-5.1.14-2, neon-devel-0.26.2-1, perl-subversion-1.4.2-2,
D python-subversion-1.4.2-2, subversion-devel-1.4.2-2, subversion-libs-1.4.2-2,
subversion-svnserve-1.4.2-2
R subversion-libs-1.4.2-1, subversion-1.4.2-1, subversion-svnserve-1.4.2-1,
perl-subversion-1.4.2-1, python-subversion-1.4.2-1,
R apr-util-1.2.8-1, mysql-libs-5.0.27-3
Need to get 5.6MB of archives (4.2MB to download).
After unpacking 29.6MB will be used.
wrobell [EMAIL PROTECTED]
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: galeon
On Mon, Jan 01, 2007 at 10:55:10PM +0100, Jakub Bogusz wrote: On Mon, Jan 01, 2007 at 05:01:59PM +0100, Marcin Król wrote: I've been trying to get galeon running with xulrunner, w/o success. It compiles cleanly, but it crashes right after displaying browser window. The weird thing is when I try to debug the problem with gdb it doesn't crash. Someone have an idea for source of such behaviour? BTW, is xulrunner maintained? There was no release since July 2006 and probably that release contains many security bugs fixed in firefox/thunderbird/seamonkey during last six months :/ http://wiki.mozilla.org/XULRunner:Roadmap wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: eventum-db.patch missing
On Sat, Nov 25, 2006 at 02:46:09PM +0200, Elan Ruusamäe wrote: what for? :) guess :P wrobell [EMAIL PROTECTED] On Friday 24 November 2006 19:36, wrobell wrote: On Fri, Nov 24, 2006 at 01:50:14PM +0200, Elan Ruusamäe wrote: well. to use that patch you must first use version before that one, so the previous trigger can be ran, otherwise the other db changes won't be done (that patch just removes duplicate update queries) please, stop top-posting. wrobell [EMAIL PROTECTED] -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: vim mimetype
On Fri, Oct 27, 2006 at 01:56:18AM +0300, Elan Ruusamäe wrote: On Friday 27 October 2006 01:43, wrobell wrote: On Thu, Oct 26, 2006 at 11:55:37AM +0300, Elan Ruusamäe wrote: On Thursday 26 October 2006 02:30, wrobell wrote: anyway back to topic, so it's kde bug it's not opening terminal (that desktop file works ok if started from menu)? it seems. in gnome menu it works perfectly so, does it work also without mimetype=text/plain in vim.desktop? as i remember - no. but i can be wrong. could you test? it should be hard as invoking: $ sudo vim /usr/share/applications/vim.desktop seems to work wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS (DEVEL): mozilla-firefox.spec - added more configure options...
On Wed, Nov 01, 2006 at 01:48:26AM +0100, glen wrote: Author: glen Date: Wed Nov 1 00:48:26 2006 GMT Module: SPECS Tag: DEVEL Log message: - added more configure options, reviewed them - install section cleanup and skip tgz step - firefox-chrome+xpcom-generate cleanup and comments - postun dropped (should be done as ghost files instead) Files affected: SPECS: mozilla-firefox.spec (1.95.2.32 - 1.95.2.33) Diffs: Index: SPECS/mozilla-firefox.spec diff -u SPECS/mozilla-firefox.spec:1.95.2.32 SPECS/mozilla-firefox.spec:1.95.2.33 --- SPECS/mozilla-firefox.spec:1.95.2.32 Thu Oct 26 11:26:09 2006 +++ SPECS/mozilla-firefox.specWed Nov 1 01:48:20 2006 @@ -8,13 +8,17 @@ [...] +BuildRequires: jdk will it build on ppc? gcj is enough? does it introduce java runtime dependency? [...] wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: vim mimetype
On Thu, Oct 26, 2006 at 11:55:37AM +0300, Elan Ruusamäe wrote: On Thursday 26 October 2006 02:30, wrobell wrote: anyway back to topic, so it's kde bug it's not opening terminal (that desktop file works ok if started from menu)? it seems. in gnome menu it works perfectly so, does it work also without mimetype=text/plain in vim.desktop? as i remember - no. but i can be wrong. wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: vim mimetype
On Wed, Oct 25, 2006 at 10:40:59PM +0300, Elan Ruusamäe wrote: On Wednesday 25 October 2006 22:02, wrobell wrote: proposition: remove MimeType=text/plain; from vim.desktop because after fresh kde login the default view source application is vim besides that i don't want it to be vim but some gui application, it doesn't work. it opens vim without terminal and vim quits. this works very nice for gnome... do you actually need that text/plain binding? isn't start menu item enough? yes, i need. vim is best thing for editing and viewing text-based files, isn't it? (including xml, html, etc) :] on the other point of view there was Terminal=true option, which should be added to desktop file? i do not know wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: vim mimetype
On Thu, Oct 26, 2006 at 01:56:09AM +0300, Elan Ruusamäe wrote: On Thursday 26 October 2006 01:39, wrobell wrote: this works very nice for gnome... do you actually need that text/plain binding? isn't start menu item enough? yes, i need. vim is best thing for editing and viewing text-based files, isn't it? (including xml, html, etc) i run vim from terminal (and a lot). in x11 i expect something with mouse scrollable ;) you are heretic ;) but vim.desktop doesn't have mapping for text/html; haha :D works when i press c-u (view page source) in epiphany :] anyway back to topic, so it's kde bug it's not opening terminal (that desktop file works ok if started from menu)? it seems. in gnome menu it works perfectly, but: $ grep Terminal /usr/share/applications/vim.desktop Terminal=true $ rpm -qf /usr/share/applications/vim.desktop vim-7.0.081-2.ppc wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
python 2.5 bytecode problems
I am planning to build Python 2.5 (final version) on TH builders. This will cause major problems on your systems - you will not be able to run software, which is not rebuilt against Python 2.5. This situation is caused by bug in Python prior to version 2.5c2, which fixing required changing bytecode magic number (#1520864). Therefore, please do not upgrade your Python related software on TH based systems for few days till migration to Python 2.5 is finished. Sorry for any inconvenience, wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: rpm.spec - build with python 2.5, rel 1.11
On Fri, 2006-08-25 at 14:12 +0200, Jakub Bogusz wrote: On Fri, Aug 25, 2006 at 11:09:46AM +0200, wrobell wrote: Author: wrobell Date: Fri Aug 25 09:09:46 2006 GMT Module: SPECS Tag: HEAD Log message: - build with python 2.5, rel 1.11 python 2.5 bytecode magic must be added to file mackage in order to *.py[co] files be still recognized by rpm dependency generator. i will do it during the weekend. wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
python 2.5 in th
1/08/2006 python 2.5 rc1 is planned to be released. this day (or bit later) i would like to update python.spec (current beta is on PYTHON_2_5 branch) and start upgrading th packages to use python 2.5. any requests? any notes? wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: bug in ksh?
On Fri, 2006-07-07 at 12:48 +0200, Andrzej 'The Undefined' Dopierała wrote: weirdy difference between sh from ksh and bash: [EMAIL PROTECTED] ~]$ bash [EMAIL PROTECTED] ~]$ [ 30 -ge 20 ] echo works works [EMAIL PROTECTED] ~]$ sh [EMAIL PROTECTED] ~]$ [ 30 -ge 20 ] echo works [EMAIL PROTECTED] ~]$ [EMAIL PROTECTED] ~]$ rpm -qf /bin/sh /bin/bash pdksh-5.2.14-43 bash-3.1.017-1 32 bit unsigned int vs 32 bit signed int vs 64 bit long? wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: PLD is not for non-Poles
On Mon, 2006-06-26 at 12:53 +0200, Dirk Ullrich wrote: Hi, PLD-developers, I'm a longstanding Debian user, but I thought it would be a good idea to broaden my Linux knowledge a bit. Thus I was looking for an RPM-based Linux distribution and and came across PLD. In my opinion PLD is by far the most interesting RPM-based distribution. But there is a big grain of salt for somebody like me not being able to understand Polish: It seems the nearly all interesting communication is done in Polish. That's a pitty since this fact prevents me from becoming an active member of the PLD community. Although you state at PLD's main web page that the P in PLD does not stand in for Polish or something alike it should to properly characterize PLD. Of course I would much prefer to see PLD switching to a 'truly internationalized' development (and user) model. But I'm afraid that this would not happen soon. It's a great pity since I have now to look for another, less interesting RPM-based distribution. Dear Dirk, Thank you for your letter. Don't worry about pl lists. There are a lot of people on en lists, who can help you both with utilizing features of PLD and development of distro. Just shoot questions. For sure they will be answered. Regards, wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: xulrunner.spec (NEW) - started packaging xulrunner, spec ba...
On Mon, 2006-05-15 at 21:57 +0200, hawk wrote: Author: hawk Date: Mon May 15 19:57:52 2006 GMT Module: SPECS Tag: HEAD Log message: [...] +URL: http://www.mozilla.org/projects/xulrunner/ 404 not found wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: xulrunner.spec (NEW) - started packaging xulrunner, spec ba...
On Mon, 2006-05-15 at 21:57 +0200, hawk wrote: Author: hawk Date: Mon May 15 19:57:52 2006 GMT Module: SPECS Tag: HEAD [...] Index: SPECS/xulrunner.spec great. so it seems that this is the project, which galeon and epiphany should be compiled against. any comments? [...] wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: xulrunner.spec (NEW) - started packaging xulrunner, spec ba...
On Tue, 2006-05-16 at 17:41 +0200, Marcin Król wrote: BTW, there was mozilla-xulrunner.spec already. Ooops! Which one we should kill then? Or maybe some merge? mozilla.spec mozilla-firefox.spec mozilla-thunderbird.spec so it should be called mozilla-xulrunner.spec, imho regards, wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: xulrunner.spec (NEW) - started packaging xulrunner, spec ba...
On Tue, 2006-05-16 at 18:12 +0200, Marcin Król wrote: great. so it seems that this is the project, which galeon and epiphany should be compiled against. any comments? Both of them were incompatible with xulrunners typeahead feature. Galeon was fixed, but epiphany wasn't. And also both xulrunner specs should be reviewed/merged before using it for building other stuff. what version of epiphany? wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: python-django.spec - we don't insert .py files into package...
On Mon, 2006-05-15 at 12:31 +0200, Jakub Bogusz wrote:
On Mon, May 15, 2006 at 12:23:00PM +0200, Arkadiusz Miskiewicz wrote:
On Monday 15 May 2006 12:05, troll wrote:
Author: trollDate: Mon May 15 10:05:48 2006 GMT
Module: SPECS Tag: HEAD
Log message:
- we don't insert .py files into packages
We shoudln't avoid them in Th. I so often need to check py sources that
it's a
nightmare when not having them.
The same for C sources sometimes... so?
exactly, this was discussed long time ago. it is settled.
wrobell [EMAIL PROTECTED]
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: python-django.spec - we don't insert .py files into package...
On Mon, 2006-05-15 at 14:10 +0200, Paweł Gołaszewski wrote:
On Mon, 15 May 2006, Arkadiusz Miskiewicz wrote:
Author: trollDate: Mon May 15 10:05:48 2006 GMT
Module: SPECS Tag: HEAD
Log message:
- we don't insert .py files into packages
We shoudln't avoid them in Th. I so often need to check py sources that
it's a nightmare when not having them.
put them into separate package.
.src.rpm
it was really discussed several years ago. please use
list archives... oopsss do we have pld.org.pl list archives? :]
wrobell [EMAIL PROTECTED]
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: p7zip in AC
On Wed, 2006-05-10 at 11:00 +0200, Andrzej Krzysztofowicz wrote: =?ISO-8859-2?Q?Pawe=B3_Go=B3aszewski?= wrote: It's broken - it looks for his files in wrong place: [...] open(/usr/bin//usr/lib/p7zip, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOENT (No such file or directory) open(/usr/bin//usr/lib/p7zip/Formats, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOENT (No such file or directory) [...] # rpm -q p7zip p7zip-4.29-1 Mozesz podac architekture i testcase ? please, this is english list. wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm changelog
On Thu, 2006-04-27 at 20:05 +0300, Elan Ruusamäe wrote: On Thursday 27 April 2006 15:04, wrobell wrote: On Thu, 2006-04-27 at 14:03 +0200, Marcin Król wrote: how this all relates to subversion repository and claims that you always need complete changelog? But we don't build any rpms from subversion? but while we were discussing migration to svn it was stated that we really need complete changelog. always. i'm lazy to search the conversation, but wasn't it about the changelog in spec files, ie that svn can't provide changelog into spec files like cvs does. yep. you are right. sorry for misinformation. wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm changelog
On Thu, 2006-04-27 at 13:07 +0200, Marcin Król wrote: and if you want complete changelog, you can always use cvsweb. or cvs log at commandline :) how this all relates to subversion repository and claims that you always need complete changelog? wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm changelog
On Thu, 2006-04-27 at 14:03 +0200, Marcin Król wrote: how this all relates to subversion repository and claims that you always need complete changelog? But we don't build any rpms from subversion? but while we were discussing migration to svn it was stated that we really need complete changelog. always. wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: epiphany.spec - build with firefox by default - rel. 2
On Mon, Apr 17, 2006 at 06:07:53PM +0200, wrobell wrote: Author: wrobell Date: Mon Apr 17 16:07:53 2006 GMT Module: SPECS Tag: HEAD Log message: - build with firefox by default - rel. 2 the reasons for above change: - mozilla suite is obsoloted by seamonkey - firefox is the official browser of mozilla project - epiphany requires only gecko engine, which is provided by firefox wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: sending build requests for th, a proposal of rules
On Fri, Apr 14, 2006 at 11:57:19AM +0200, Arkadiusz Miskiewicz wrote: On Thursday 13 April 2006 10:02, wrobell wrote: [...] 2. if you want to send a package to builders, then _build_ and _run_ it on your machine first. this means, that if soname changes then it is sender responsibility to rebuild or other dependant packages. if you have no time for soname play, then don't send a request to builders. if you are in middle of the process and your cat needs you, then ask other developer to finish the job. if it involves a lot of time (i.e. openssl), then tell people on the list about it. There are two packages currently with soname changes. expat and openssl. expat case isn't yet clear and rebuilding stuff for openssl and then again for expat would be stupid. So openssl has to wait. It didn't upgrade on builders so what the problem? speaking about openssl and th it is not a problem, now. :) openssl was just an example. if you have your plan then it is ok. eventually, just let us know what is going to happen. let's be flexible. [...] wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: AC-branch usage suggestion
On Thu, 2006-04-13 at 00:13 +0300, Elan Ruusamäe wrote: On Wednesday 12 April 2006 21:07, Michal Kochanowicz wrote: Because it against natural reading order. Why? Topposting. What is most annoying in the Internet? i post to top when i don't have anything to quote, but reply to whole message. and you are so brave to claim that no other person will answer to yours? :) cheers, wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
sending build requests for th, a proposal of rules
hello, th is quite usable for some of us now, so what about such two rules? 1. if you send something to th builders, then it should build on all archs. this means that if package building fails on one of the builders, then it is sender responsibility to fix this before sending another request. if you are not able to fix something, then tell about it on the list, so we can work together to fix the problem. 2. if you want to send a package to builders, then _build_ and _run_ it on your machine first. this means, that if soname changes then it is sender responsibility to rebuild or other dependant packages. if you have no time for soname play, then don't send a request to builders. if you are in middle of the process and your cat needs you, then ask other developer to finish the job. if it involves a lot of time (i.e. openssl), then tell people on the list about it. of course, this is only a proposal. i think that such rules could improve stability of system for testers. then, maybe we could gain more people to test pld th. regards, wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: python.spec - added python info pages as separate subpackage
On Sun, 2006-03-26 at 15:01 +0200, twittner wrote: Author: twittner Date: Sun Mar 26 13:01:42 2006 GMT Module: SPECS Tag: HEAD Log message: - added python info pages as separate subpackage [...] +BuildRequires: emacs = 21 is there any other way? installing emacs just to build info docs... wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
libghoto2
warning: Installed (but unpackaged) file(s) found: /usr/share/locale/nb/LC_MESSAGES/libgphoto2_port-0.mo /usr/share/locale/sl/LC_MESSAGES/libgphoto2_port-0.mo /usr/share/locale/uk/LC_MESSAGES/libgphoto2_port-0.mo Wrote: /home/users/wrobell/rpm/RPMS/libgphoto2-2.1.99-1.ppc.rpm Wrote: /home/users/wrobell/rpm/RPMS/libgphoto2-devel-2.1.99-1.ppc.rpm Wrote: /home/users/wrobell/rpm/RPMS/libgphoto2-static-2.1.99-1.ppc.rpm Wrote: /home/users/wrobell/rpm/RPMS/libgphoto2-port-serial-2.1.99-1.ppc.rpm what should be done with locales listed above? w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: latex problems
On Sat, 2006-03-04 at 23:33 +0100, Tomasz Grobelny wrote: In default installation latex eats all available memory when trying to compile a simple file. Issuing these two commands works around the problem: $ sudo ln -s /var/lib/texmf/web2c/latex.fmt /usr/share/texmf/web2c/latex.fmt $ sudo ln -s /var/lib/texmf/web2c/pdflatex.fmt /usr/share/texmf/web2c/pdflatex.fmt Why are those two files in /var/... when latex and pdflatex command search for them in /usr/...? can you send me document which triggers problem (on priv, pls)? wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm arch - ppc 7450
On Fri, 2006-03-03 at 12:44 +0100, Przemek Iskra wrote: On Fri, Mar 03, 2006 at 09:02:20AM +, wrobell wrote: On Thu, 2006-03-02 at 23:12 +0100, Przemek Iskra wrote: On Thu, Mar 02, 2006 at 06:02:59PM +, wrobell wrote: ppc 7450 is not going to be supported on th builders. in such situation rpm-morearchs patch should go on some branch, doesn't it? this situation is exactly same as pentium3, pentium4, s390 and few others: if someone needs it can compile for such arch ok. but it compiles on my ppc with ppc7450 by default. this causes some troubles with several specs which know nothing about ppc7450 (i.e. compat-libstdc++.spec and ExclusiveArch). as i understand your words, packages should be compiled on ppc with ppc arch by default? yes, they should, and they will unless you build rpm for ppc7450 arch and if you have rpm build for ppc7450 it shuld produce 7450 packages by default so something is wrong $ rpm -q rpm gnome-desktop rpm-4.4.4-1.ppc gnome-desktop-2.13.92-1.ppc7450 wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
rpm arch - ppc 7450
ppc 7450 is not going to be supported on th builders. in such situation rpm-morearchs patch should go on some branch, doesn't it? wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: broken openssh in Ac (xauth path)
On Mon, 2006-02-20 at 13:00 +0100, Arkadiusz Miskiewicz wrote: On Monday 20 February 2006 12:55, Jakub Bogusz wrote: Recent openssh in Ac has been built from HEAD, with post-Ac xauth path - so X forwarding is broken now. Someone didn't create AC-branch then. who is allowed to do it and when? imho, it should be done at once some time ago. best regards, wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: multisync.spec - release 5 - don't build plugin for archaic...
On Mon, 2006-01-23 at 13:02 +, wrobell wrote: On Wed, 2006-01-18 at 19:27 +, wrobell wrote: On Wed, 2006-01-18 at 19:41 +0100, Jan Rekorajski wrote: On Wed, 18 Jan 2006, wrobell wrote: On Wed, 2006-01-18 at 19:15 +0100, baggins wrote: Author: baggins Date: Wed Jan 18 18:15:12 2006 GMT Module: SPECS Tag: HEAD Log message: - release 5 - don't build plugin for archaic evolution Files affected: SPECS: multisync.spec (1.37 - 1.38) [...] Name:multisync Version: 0.83 i would switch to completly new opensync/multisync from www.opensync.org or drop multisync 0.83 from ac. You're welcome to do it. [...] i will try irmc with my phone as soon as possible (after bluez upgrade). sorry guys, but i cannot test it. i am not able to connect to my phone with bluetooth currently (kernel 2.6.15.1). anyone else can try this? [...] wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: multisync.spec - release 5 - don't build plugin for archaic...
On Wed, 2006-01-18 at 19:27 +, wrobell wrote: On Wed, 2006-01-18 at 19:41 +0100, Jan Rekorajski wrote: On Wed, 18 Jan 2006, wrobell wrote: On Wed, 2006-01-18 at 19:15 +0100, baggins wrote: Author: baggins Date: Wed Jan 18 18:15:12 2006 GMT Module: SPECS Tag: HEAD Log message: - release 5 - don't build plugin for archaic evolution Files affected: SPECS: multisync.spec (1.37 - 1.38) [...] Name: multisync Version: 0.83 i would switch to completly new opensync/multisync from www.opensync.org or drop multisync 0.83 from ac. You're welcome to do it. libopensync.spec is on head. i am going to work on some plugins this week: libopensync-plugin-evolution2 libopensync-plugin-file libopensync-plugin-irmc libopensync-plugin-python and multisync from opensync.org next week. libopensync plugins and multisync (commandline version) on head, now. i have tested syncing with evolution and file plugins. works fine. i will try irmc with my phone as soon as possible (after bluez upgrade). warning: dependencies still can be wrong. wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: multisync.spec - release 5 - don't build plugin for archaic...
On Wed, 2006-01-18 at 19:15 +0100, baggins wrote: Author: baggins Date: Wed Jan 18 18:15:12 2006 GMT Module: SPECS Tag: HEAD Log message: - release 5 - don't build plugin for archaic evolution Files affected: SPECS: multisync.spec (1.37 - 1.38) [...] Name:multisync Version: 0.83 i would switch to completly new opensync/multisync from www.opensync.org or drop multisync 0.83 from ac. wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: multisync.spec - release 5 - don't build plugin for archaic...
On Wed, 2006-01-18 at 19:41 +0100, Jan Rekorajski wrote:
On Wed, 18 Jan 2006, wrobell wrote:
On Wed, 2006-01-18 at 19:15 +0100, baggins wrote:
Author: baggins Date: Wed Jan 18 18:15:12 2006 GMT
Module: SPECS Tag: HEAD
Log message:
- release 5
- don't build plugin for archaic evolution
Files affected:
SPECS:
multisync.spec (1.37 - 1.38)
[...]
Name:multisync
Version: 0.83
i would switch to completly new opensync/multisync
from www.opensync.org or drop multisync 0.83 from ac.
You're welcome to do it.
libopensync.spec is on head.
i am going to work on some plugins this week:
libopensync-plugin-evolution2
libopensync-plugin-file
libopensync-plugin-irmc
libopensync-plugin-python
and multisync from opensync.org next week.
wrobell [EMAIL PROTECTED]
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: tetex-latex-mhchem.spec (NEW) - Initial for PLD
On Mon, 2006-01-16 at 21:12 +0100, piti wrote:
Author: piti Date: Mon Jan 16 20:12:10 2006 GMT
Module: SPECS Tag: HEAD
Log message:
- Initial for PLD
Files affected:
SPECS:
tetex-latex-mhchem.spec (NONE - 1.1) (NEW)
Diffs:
Index: SPECS/tetex-latex-mhchem.spec
diff -u /dev/null SPECS/tetex-latex-mhchem.spec:1.1
--- /dev/null Mon Jan 16 21:12:10 2006
+++ SPECS/tetex-latex-mhchem.spec Mon Jan 16 21:12:04 2006
@@ -0,0 +1,78 @@
+# $Revision$, $Date$
+%define short_name mhchem
+%define texhash [ ! -x %{_bindir}/texhash ] || %{_bindir}/texhash 12 ;
what about putting texhash macro in rpm macros?
[...]
wrobell [EMAIL PROTECTED]
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: rhythmbox.spec - 0.9.2, dropped hal requirement (ankry uses...
On Mon, 2005-11-28 at 19:13 +0100, freetz wrote: Author: freetz Date: Mon Nov 28 18:13:41 2005 GMT Module: SPECS Tag: HEAD Log message: - 0.9.2, dropped hal requirement (ankry uses rhythmbox on a 2.4.x box), bcond hal? [...] wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: xorg-app-x11perf.spec - removed outdated man patch, fixed a...
On Fri, 2005-10-21 at 12:00 +0200, Jakub Piotr Cłapa wrote:
Jakub Bogusz wrote:
On Fri, Oct 21, 2005 at 11:47:38AM +0200, Jakub Piotr Cłapa wrote:
qboosh wrote:
Author: qboosh Date: Fri Oct 21 05:56:58 2005 GMT
Module: SPECS Tag: HEAD
Log message:
- removed outdated man patch, fixed appmandir
And what's the difference between 1x and 1? (why all X packages use ?x
by default?)
We don't (and never did) have %{_mandir}/man?x dirs.
And they are not present in man.config.
That's what I thought. Maybe it would be a good idea to add them?
what says fhs?
wrobell [EMAIL PROTECTED]
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn...
On Fri, 2005-09-09 at 00:55 +0200, Piotr Szymanski wrote: [...] -) The disadvantage 100% terrible working with branches, cvs is just much more comfortable, with cvs you only need to know the branch name, while in svn you need to know the directory you want to do the svn switch ^^^ which is de facto the branch name... so, what's the problem? wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Thu, 2005-09-08 at 01:53 +0200, Jan Rekorajski wrote:
On Wed, 07 Sep 2005, wrobell wrote:
On Wed, 2005-09-07 at 11:03 +0200, Jan Rekorajski wrote:
Example: http://svn.pld-linux.org/svn/rc-scripts
I want to keep only trunk, branches and _some_ tags, tell me how to do
it, and how to prevent svn up from getting all tags.
svn up trunk?
svn up tags/tagireallywant?
come on...
Ok, that's solved then, thanks. One more question - how to do 'svn up' in
directory where I did checkouts so it will update all checked subdirs?
With cvs all I need to do is `mkdir CVS ; echo $CVSROOT CVS/Root ; cvs up`
A recipe for svn much appreciated :)
1. create your own local repo
2. checkout it
3. svn propedit svn:externals .
4. add tags, branches, whatever
5. svn up
the advantage: you will never fsck up anything with cvs up -A
(imho, but not tested with cvs)
And the royal PITA, which svn is, is not worth it.
... it is really hard to discuss with such arguments, which seem
to be matter of taste.
i think (let's skip svn for now), we need:
- to keep history of tags and branches
ok, I guess all versioning systems must have it, or do you mean
dead/deleted tags and branches? What for?
yes. deleted tags and branches. i.e. when you merge DEVEL, delete
it, then for some reason you want to compare HEAD with DEVEL
(i.e. something went wrong while merging).
- atomic commit (so we can commit patches and specs with one move
and revert it easily later if there is a need)
Example?
svn ci -m patches updated for 3.0 \
SPECS/tetex.spec SOURCES/teTeX*patch
and then, later, you can easily see what exact changes
where made. good luck with cvs.
- ability to rename specs and patches without pain and loosing
information and _without_administrator_ help
Maybe, but do we really do this that often?
not often. but happens from time to time. again: not only specs,
but very useful for renaming patches.
- check changes without making connection to remote server
And svn solves it how?
maybe i should put it this way: check _local_ changes...
svn diff|status|revert
http://svnbook.red-bean.com/en/1.1/apas03.html
these are my problems with cvs. svn solves them.
svn gives us some advantages. disadvantages? any real, which makes life
really painful? let's talk but without royal PITA, i do not care
for lost information, i do not care for renaming, etc. please.
One BIG disadvantege is that we will have to reorganize the entire repo
into one package = one svn dir layout. And then it's either a
fscking lot of copying svn-local-repo - ~/rpm/* or constant editing of
~/.rpmmacros. With current layout I can just checkout entire SPECS and
SOURCES and work with any package on any branch easily.
i think, that we are able to create such structure (and even structures)
that it will be as easy as it is now and it will give us more options
(so yes, i see rpm/{SPECS,SOURCES} as _not_ obsoleted)
And then, what lost information? And the argument about renaming is
just making me laugh, we have more than 9400 specs, we needed to rename
how much of them? 10? 20? Come on.
it is sick to ask admin, isn't it? please consider renaming of patches
too.
then, if svn is not solution for us, then what other alternatives
we can use? let's think about it, because cvs is not solution
for us.
Why it is not? I work with it from the beggining and I don't feel any
need to switch, I haven't yet seen a versioning system that would give
enough advantages that I'd consider switching.
i wrote reasons in other post. and there are people who think we
should switch and they (we) have real problems which would be
solved then.
wrobell [EMAIL PROTECTED]
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn...
On Thu, 2005-09-08 at 01:36 +0200, Jan Rekorajski wrote: On Wed, 07 Sep 2005, Paweł Sakowski wrote: On Wed, 2005-09-07 at 10:20 +0100, wrobell wrote: - atomic commit (so we can commit patches and specs with one move and revert it easily later if there is a need) A propos reverting. One thing that we use (need?) and svn lacks is support for $Log$. So, we would be missing autogenerated %changelog. However, I personally would be happy to get rid of it, because: - it only reflects commits to the spec, not to the patches (and seeing that the only difference between two releases is rel up is confusing and doesn't help one bit) Smash the uneducated ;) Seriously having or not changelog in spec will not change some people habbit of putting dumb comments. But, most of the time changelog in spec helps. you are right. and for me having changelog in specs is very useful. $Log$ is not supported by svn http://subversion.tigris.org/faq.html#log-in-source but i think that we can achieve appropriate functionality. give me few days, please. wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Wed, 2005-09-07 at 16:51 +0200, Tomasz Pala wrote: On Wed, Sep 07, 2005 at 10:20:54AM +0100, wrobell wrote: svn gives us some advantages. disadvantages? any real, which makes life really painful? How to resolve conflict? I've got a situation: ~: vi blabla ~: svn ci blabla snv reports conflict here [fixing it manually] oops sorry... svn resolve file missing here ~: svn ci blabla svn reports there's unresolved conflict wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: vte.spec - broken, rel. down to 0.1
On Wed, 2005-08-03 at 18:03 +0200, Fryderyk Dziarmagowski wrote: --- Paweł Sakowski [EMAIL PROTECTED] wrote: On Wed, 2005-08-03 at 16:19 +0200, freetz wrote: $Log$ +Revision 1.77 2005/08/03 14:19:04 freetz +- broken, rel. down to 0.1 + Revision 1.76 2005/08/03 08:53:52 aflinta - up to version 0.11.14 If you elaborate what it is that you find broken, there's a chance that someone will fix it. sending a problem description to authors it's not sufficient? should I cc you with every problem I've found? and I don't belive that someone will fix it. chances are very, very small (as usual). still we don't know what the problem is. maybe we should downgrade? so... what's the problem? wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: vte.spec - broken, rel. down to 0.1
On Wed, 2005-08-03 at 18:45 +0200, Fryderyk Dziarmagowski wrote: --- Bartosz Taudul [EMAIL PROTECTED] wrote: +Revision 1.77 2005/08/03 14:19:04 freetz +- broken, rel. down to 0.1 If you elaborate what it is that you find broken, there's a chance that someone will fix it. sending a problem description to authors it's not sufficient? should I In case you didn't noticed, you commited into PLD cvs, not vte author's one. don't like my commits? feel free to report a abuse to PLD CDG. come on.. fuck the system. we just want to know the problem :) wrobell [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
