Re: SPECS: adapter.awk - parse epoches from ../PLD-doc/BuildRequires.txt
Author: glen Date: Tue Jan 24 07:42:38 2006 GMT Module: SPECS Tag: HEAD Log message: - parse epoches from ../PLD-doc/BuildRequires.txt This can sometimes provide faulty BRs. E.g.: BR: avifile-devel = 0.5 becomes 1:0.5 (correct: unchanged) BR: avifile-devel = 0.7.16 becomes 1.0.7.16 (correct: 3:0.7.16) -- Paweł Sakowski [EMAIL PROTECTED] PLD Linux Distribution ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: glibc.spec - prevent: # rpm -qf /usr/include/gnu file /usr/...
On Sun, 2005-10-02 at 20:46 +0200, blues wrote:
--- SPECS/glibc.spec:1.603Sat Jun 18 23:48:12 2005
+++ SPECS/glibc.spec Sun Oct 2 20:46:16 2005
@@ -1376,7 +1376,8 @@
%endif
%{_includedir}/arpa
%{_includedir}/bits
-%{_includedir}/gnu
+%dir %{_includedir}/gnu
+%{_includedir}/gnu/*.h
%{_includedir}/net
%{_includedir}/netash
%{_includedir}/netatalk
@@ -1493,6 +1494,11 @@
All persons listed below can be reached at cvs_login@pld-linux.org
$Log$
+Revision 1.604 2005/10/02 18:46:16 blues
+- prevent:
+# rpm -qf /usr/include/gnu
+file /usr/include/gnu is not owned by any package
?? How does that prevent anything? Both variants include
%{_includedir}/gnu in the file list.
--
Paweł Sakowski [EMAIL PROTECTED]
PLD Linux Distribution
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SOURCES: klibc-kill_bashism.patch (REMOVED) - last change reverted...
On Fri, 2005-09-30 at 15:40 +0200, Arkadiusz Miskiewicz wrote: echo '[ foo = bar -a -u = zoo ]'|/bin/sh /bin/sh: stdin[1]: [: zoo: unexpected operator/operand alternatives: echo '[ foo = bar ] [ -u = zoo ]'|/bin/sh echo '[ foo = bar -a x-u = xzoo ]'|/bin/sh The original test should work since is posix quoting and it should quote -u, too I guess. The quoting isn't kept when the arguments are passed to [, whether it is a builtin or /usr/bin/[. You can use \-u\ = \zoo\ if you wish, to the same effect as with x bash, zsh work well with the original test. ksh doesn't not, sounds like ksh bug. More likely syntax ambiguity resolved differently by different parsers. Looks like bash first matches the X = Y syntax rule and ksh: -u Z. In alternative #1 the same token sequence happens to match X = Y on ksh too, but it's underspecified and not to be relied on. On encountering -u, [ is rightfully allowed to suppose it means file is suid. You can (and should) easily avoid ambiguity by prefixing any a priori unknown strings with x (or anything not starting with -=!(] ). -- Paweł Sakowski [EMAIL PROTECTED] PLD Linux Distribution ___ 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 reloaded
On Wed, 2005-09-14 at 15:02 +0200, Paweł Sikora wrote:
Dnia środa, 14 września 2005 12:59, Jakub Bogusz napisał:
Well, what I _need_ is to have local SPECS directory regularly updated
and be able to easily commit individual specs without traversing
directory structure all the time.
I _won't_ sacrifice few times more time for multiple chdir()s or typing
longer paths during specs cleanups/fixes/cosmetics, just in order to use
more modern VCS.
http://subversion.tigris.org/faq.html#symlinks ?
The problem is that they are, strictly speaking, filesystem symlinks. To
use them you'd have to have all foo/trunk/foo.spec checked out manually
anyway, which makes it pointless (unversioned `for i in */*.spec;do ln
-s $i;done` is way easier and does pretty much the same thing). If you
add a oneliner script with readlink and svn ci, you get qboosh'es
condition of commits without long paths or chdir fulfilled. For a
price. `cd SPECS;cvs up` gets more complex (you're working with
thousands of project directories); you can get a script to minimize
typing everytime, but the process will take longer. Plus, you have to
stand the awkwardness of the solution.
I believe an elegant solution would be to have versioned hardlinks. That
is, SPECS/trunk/foo.spec being the same as foo/trunk/foo.spec,
permitting commits to any one of those paths with the same effect. Alas,
subversion doesn't support that. But...
I think it's possible to write a post-commit hook that would effectively
simulate a hardlink capability. The idea is that whenever a modification
of a spec is committed, the change would be applied to the other
location as well (generating another revision). Thus, both versions
would be kept in sync. Preserving the commit log over the merge doesn't
seem to be a problem. There are some special cases to consider regarding
svn {cp,mv,add,rm} of specs. Et voila, you have package directories that
profit from all svn features discussed before, and you keep the
traditional SPECS directory for spec reviews (and grepping the dir
contents for inspiration and/or policy verification).
Does it sound like something that will keep everybody happy?
Note: there might be a race condition on resyncking when there are two
simultaneous commits to both locations. I'd have to check if the hooks
are (or can be) run on a mutexed repository.
--
Paweł Sakowski [EMAIL PROTECTED]
PLD Linux Distribution
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
cvs vs svn reloaded
In the spirit of don't take my word for it I've created a proof-of-concept of how an svn-based, package-oriented repository would look like. http://svn.pld-linux.org/svn/cvs2svn-migration/trunk Requires a (partial) mirror of the repo. Have fun creating brand new PLD repositories and invoking the brand new builder to build rpms from it. Feedback most welcome. -- Paweł Sakowski [EMAIL PROTECTED] PLD Linux Distribution ___ 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 13:28 +0200, Piotr Szymanski wrote: And sharing other sources isn't very useful and can sometimes prove to be a bad idea (one might inadvertently modify one package when working on another). Yeah, like our SOURCES/kde-common-PLD.patch ? The admin dir is the same along every kde release, we want it to be shared beween specs. If (since) it's not customized for each individual package, DF will be more than happy to accept that file. -- Paweł Sakowski [EMAIL PROTECTED] PLD Linux Distribution ___ 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: - it makes it impossible to revert by `cvs up -j` (you lose changelog entries) Is it really that important? After 6 years of work with our CVS I can't remember needing it. Then how would you/did you ever revert a non-trivial release? Probably the least manual way is to `cvs diff` for the change being reverted, editing the result (sed or vim) to strip the changes in the changelog and `patch -R` the result, then commit. Any easier way? Did someone said something about disconnected work with svn? Yes. That `svn diff` (local vs repo) and `svn revert` work disconnected. Noboby stated anything beyond that. Come on svn fans, you're contradicting yourselves. Please elaborate. Show me two statements of mine (or other svn fans) which logically contradict one another about that matter. I never claimed that `svn log` works disconnected. And breaking news: neither does `svn ci`. -- Paweł Sakowski [EMAIL PROTECTED] PLD Linux Distribution ___ 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 Tue, 2005-09-06 at 19:27 +0200, Jan Rekorajski wrote: At the cost of keeping ALL tags/branches locally. You're joking. [EMAIL PROTECTED] rpm]$ du -hs SOURCES SPECS 959MSOURCES 63M SPECS Obviously svn makes no sense with such file organization (in two directories). To allow reasonable branching, each package would have to have a directory of its own. Which is a good idea anyway, but probably it's not worth changing now. -- Paweł Sakowski [EMAIL PROTECTED] PLD Linux Distribution ___ 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-elspy.spec (NEW) - initial pld release
On Thu, 2005-09-01 at 17:08 +0200, arekm wrote:
+%attr(755,root,root) %{py_sitescriptdir}/%{module}/*.py[co]
If there are no dirty tricks in the code, 644 perms should suffice.
--
Paweł Sakowski [EMAIL PROTECTED]
PLD Linux Distribution
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: php-pear-HTML_AJAX.spec - BR: sed 4.0, use __sed macro
On Thu, 2005-08-18 at 23:06 +0200, Tomasz Wittner wrote:
By what reasons We use %{__make}? - it is just /usr/bin/make .
Until redefined as /usr/bin/make -j2 for faster SMP builds.
--
Paweł Sakowski [EMAIL PROTECTED]
PLD Linux Distribution
___
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 - rpm-build P: rpmbuild(monoautodeps)
On Fri, 2005-08-12 at 01:27 +0200, wolf wrote: Author: wolf Date: Thu Aug 11 23:27:10 2005 GMT Module: SPECS Tag: HEAD Log message: - rpm-build P: rpmbuild(monoautodeps) which doesn't really describe: -# because of -fvisibility... related fixes -Requires:gcc = 5:4.0.1-0.20050514.2 Was that on purpose? -- Paweł Sakowski [EMAIL PROTECTED] PLD Linux Distribution ___ 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 - The interpreter works fine without the readli...
On Mon, 2005-08-08 at 15:17 +0200, saq wrote:
Author: saq Date: Mon Aug 8 13:17:32 2005 GMT
Module: SPECS Tag: HEAD
Log message:
- The interpreter works fine without the readline module, so moving it to
-modules. It makes way more sense there.
Does anybody have a strong feeling about merging the python{,-libs}
packages? Without readline, the python package contains nothing but
-rwxr-xr-x1 rootroot3736 May 4 22:47 /usr/bin/python
-rw-r--r--1 rootroot4777 May 4 22:47
/usr/share/man/man1/python.1.gz
the only big dependency being libstdc++.
--
Paweł Sakowski [EMAIL PROTECTED]
PLD Linux Distribution
___
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: 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). One of previous commiter screwed up the upgrade, doesn't build, this version crashes in the commit log would have made me happy. -- Paweł Sakowski [EMAIL PROTECTED] PLD Linux Distribution ___ 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 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. -- Paweł Sakowski [EMAIL PROTECTED] PLD Linux Distribution ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Non-integer grub
glen, arekm: what's the current status of grub? It's had a float release for almost 3 months now. Any pending changes, or can it be sent to build? -- Paweł Sakowski [EMAIL PROTECTED] PLD Linux Distribution ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Non-integer OpenIPMI
Revision 1.28 2005/07/27 10:26:17 blekot - up to 2.0.2 - rel 0.99 ??? What pending changes are there to keep a float release? -- Paweł Sakowski [EMAIL PROTECTED] PLD Linux Distribution ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS/jabbah.spec
On Tue, 2005-07-26 at 21:09 +0200, Patrys :: Patryk Zawadzki wrote: Library is in prealpha stages and does not provide any functionality, therefore I request cvs rm on the file. SOD#1 -- Paweł Sakowski [EMAIL PROTECTED] PLD Linux Distribution ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
SOURCES naming (devel-hints-en)
glen committed: Naming files in SOURCES. few unexplained conventions (if smb knows, plz explain the reasons): - NAME-foo.patch - patches - NAME.cron - cron fragments which go to /etc/cron.d dir - NAME.logrotate - logrotate config whichgoes to /etc/logrotate.d - NAME.sysconfig - application cofing which goes to /etc/sysconfig - NAME.init - initscript which goes to /etc/rc.d/init.d The reasons, off the top of my head: - to decrease entropy (it's good to have _a_ policy, this one is just as good as any other) - for grouping files in SOURCES (as in `rm SOURCES/galeon*` or visual inspection of `ls`) - to avoid filename conflicts between packages by prefixing (half the specs could want to use the name ac_am-fix.patch) - to easily determine visually which package a given source belongs to (by the filename prefix) -- Paweł Sakowski [EMAIL PROTECTED] PLD Linux Distribution ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SOURCES naming (devel-hints-en)
On Sat, 2005-07-16 at 17:02 +0300, Elan Ruusamäe wrote: i was more thinking why NAME.cron not NAME-cron. Hmm... probably because it's more natural -- the nomenclature name.extension (a.k.a. contents_description.type) has been around for years. OTOH: any reasons to start using NAME-cron? -- Paweł Sakowski [EMAIL PROTECTED] PLD Linux Distribution ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: PLD-doc: devel-hints-pl.txt - jak widac najbardziej oczywiste rzec...
On Tue, 2005-07-12 at 10:29 +0200, ankry wrote: --- PLD-doc/devel-hints-pl.txt:1.42 Wed Jun 22 15:04:15 2005 +++ PLD-doc/devel-hints-pl.txtTue Jul 12 10:29:03 2005 @@ -1,5 +1,11 @@ Wskazówki dla deweloperów PLD +Należy pamiętać, że projekt PLD jest pracą zespołową; podstawowymi listami +dyskusyjnymi dla developerów są pld-devel-pl@lists.pld-linux.org (w języku +polskim) i pld-devel-en@lists.pld-linux.org (w języku angielskim). Listy te +są przeznaczone między innymi do omawiania dokonanych zmian w repozytorium +i dyskutowania zmian planowanych. + What about devel-hints-en? -- Paweł Sakowski [EMAIL PROTECTED] PLD Linux Distribution ___ 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-py-xmlrpc.spec (NEW) - new, useful for gnue-*
On Tue, 2005-07-05 at 21:09 +0200, radek wrote:
+#Summary(pl):
Missing.
+Requires:python
It doesn't, only python-libs. And use %pyrequires_eq . Plus, xmlrpclib
is imported but not required (BTW, does xmlrpclib package have the right
name?)
+#%description -l pl
Missing.
+%{py_sitedir}/*.py?
It's customary to write *.py[co] and remove *.py in %install .
--
Paweł Sakowski [EMAIL PROTECTED]
PLD Linux Distribution
___
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-macros.spec (NEW) - initial idea
On Sun, 2005-06-19 at 19:36 +0200, glen wrote: +%define rpm_macros_rev 1.223 +Summary: PLD Linux RPM Macros +Name:rpm-macros +Version: 0.1 Let's just use initial version 1.223 . -- Pawe Sakowski [EMAIL PROTECTED] PLD Linux Distribution ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS (AC-branch): rpm.spec - merged fro HEAD - version 4.4.1 - re...
On Fri, 2005-06-17 at 17:55 +0200, Arkadiusz Miskiewicz wrote: HEAD (still) differs from AC-branch for rpm Invoked after the merge, before further changes: [EMAIL PROTECTED] BUILD]$ cd ~/PLD/SPECS/ [EMAIL PROTECTED] SPECS]$ cvs diff -rHEAD -rAC-branch rpm.spec [EMAIL PROTECTED] SPECS]$ -- Pawe Sakowski [EMAIL PROTECTED] PLD Linux Distribution ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
