From przemo at firszt.eu Wed Jun 1 22:06:45 2011 From: przemo at firszt.eu (Przemo Firszt) Date: Wed, 01 Jun 2011 21:06:45 +0100 Subject: [PATCH] anki - missing python-sip-devel + up to 1.2.8 Message-ID: <1306958805.3563.2.camel@pldmachine> [przemo at pldmachine ~/rpm/packages/RPMS]$ anki Gtk-Message: (for origin information, set GTK_DEBUG): failed to retrieve property `GtkTreeView::odd-row-color' of type `GdkColor' from rc file value "((GString*) 0x991d990)" of type `GString' Traceback (most recent call last): File "/usr/bin/anki", line 27, in ankiqt.run() File "/usr/share/python2.7/site-packages/ankiqt/__init__.py", line 183, in run File "/usr/share/python2.7/site-packages/ankiqt/ui/__init__.py", line 6, in importAll File "/usr/share/python2.7/site-packages/ankiqt/ui/main.py", line 12, in File "/usr/lib/python2.7/site-packages/PyQt4/pyqtconfig.py", line 32, in ImportError: No module named sipconfig Patch 0 -> fixes missing "Requires" Patch 1 -> version up to 1.2.8 -- Przemo -------------- next part -------------- A non-text attachment was scrubbed... Name: anki.spec.1.patch Type: text/x-patch Size: 569 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: anki.spec.0.patch Type: text/x-patch Size: 318 bytes Desc: not available URL: From marcin.rybak at gmail.com Fri Jun 3 13:32:57 2011 From: marcin.rybak at gmail.com (Marcin Rybak) Date: Fri, 3 Jun 2011 13:32:57 +0200 Subject: packages: transmission/transmission.spec - ta_LK (Sri Lanka Tamil) unsuppor... In-Reply-To: References:

Message-ID: 2011/6/3 caleb > Author: caleb Date: Fri Jun 3 08:46:18 2011 GMT > Module: packages Tag: HEAD > ---- Log message: > - ta_LK (Sri Lanka Tamil) unsupported, rel 2 > caleb, why only this one? :) best regards, Marcin From caleb at pld-linux.org Fri Jun 3 13:42:05 2011 From: caleb at pld-linux.org (Caleb Maclennan) Date: Fri, 3 Jun 2011 14:42:05 +0300 Subject: packages: transmission/transmission.spec - ta_LK (Sri Lanka Tamil) unsuppor... In-Reply-To: References:

Message-ID: > caleb, why only this one? :) Valid question. The workings of find_lang and some other rpm ninja tricks are still slightly magic to me. In this case, because it worked. That one language was causing RPM to fail to install, and removing it allowed it to be installed without errors. Right now I'm struggling through cleanup of packages that have fallen out of TH because they stopped building when Gnome3 was introduced. Lots of software I have works fine as long as there are some legacy packages on the system (gnome 2.32.x libraries such as gnome-media) but on new TH installs nothing seems to be working well right now. Suggestions for what I can be working on to fix this? Caleb From marcin.rybak at gmail.com Fri Jun 3 13:52:16 2011 From: marcin.rybak at gmail.com (Marcin Rybak) Date: Fri, 3 Jun 2011 13:52:16 +0200 Subject: packages: transmission/transmission.spec - ta_LK (Sri Lanka Tamil) unsuppor... In-Reply-To: References:

Message-ID: 2011/6/3 Caleb Maclennan > > caleb, why only this one? :) > > Valid question. The workings of find_lang and some other rpm ninja > tricks are still slightly magic to me. > > In this case, because it worked. That one language was causing RPM to > fail to install, and removing it allowed it to be installed without > errors. > ok, my first through was that we drop languages that it's impossible that PLD user will ever use, and second... "why only this one" :) on what environment it fails to build? I had no problems with transmission. --- Marcin Rybak http://marcinrybak.com From caleb at pld-linux.org Fri Jun 3 14:05:53 2011 From: caleb at pld-linux.org (Caleb Maclennan) Date: Fri, 3 Jun 2011 15:05:53 +0300 Subject: packages: transmission/transmission.spec - ta_LK (Sri Lanka Tamil) unsuppor... In-Reply-To: References:

Message-ID: >> >> - ta_LK (Sri Lanka Tamil) unsupported, rel 2 >> >> >> > caleb, why only this one? :) >> >> Valid question. The workings of ?find_lang and some other rpm ninja >> tricks are still slightly magic to me. >> >> In this case, because it worked. That one language was causing RPM to >> fail to install, and removing it allowed it to be installed without >> errors. >> > > ok, my first through was that we drop languages that it's impossible that > PLD user will ever use, and second... "why only this one" :) There are an awful lot that could not realistically be used. Has the possibility of a whitelist of fully included languages been considered? It seems like every spec has a different list of problematic languages that have to be cleaned up, but across the distro there isn't a lot of consistency here. > on what environment it fails to build? I had no problems with transmission. It didn't fail to build, the resulting rpm fails to install with a dependency error on a tl_LK language directory. (TH 64) Caleb From caleb at pld-linux.org Fri Jun 3 15:02:22 2011 From: caleb at pld-linux.org (Caleb Maclennan) Date: Fri, 3 Jun 2011 16:02:22 +0300 Subject: Deps in TH Message-ID: The current zsh package on the main mirror site for TH x86_64 is zsh-4.3.12-1. When I try to upgrade to it from 4.3.11-1 I get something like this: > error: zsh-4.3.12-1.x86_64: req libc.so.6(GLIBC_2.14)(64bit) not found The version of glibc in the same TH tree is 2.13-6. Only the th-test tree has glibc-2.14. Is this a "wait it out" until all the packages come through? Why did things that depend on new glibc move over from th-test before glibc? Caleb From arekm at maven.pl Fri Jun 3 17:38:25 2011 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Fri, 3 Jun 2011 17:38:25 +0200 Subject: Deps in TH In-Reply-To: References: Message-ID: <201106031738.25491.arekm@maven.pl> On Friday 03 of June 2011, Caleb Maclennan wrote: > The current zsh package on the main mirror site for TH x86_64 is > zsh-4.3.12-1. > > When I try to upgrade to it from 4.3.11-1 I get something like this: > > error: zsh-4.3.12-1.x86_64: req libc.so.6(GLIBC_2.14)(64bit) not found > > The version of glibc in the same TH tree is 2.13-6. Only the th-test > tree has glibc-2.14. > > Is this a "wait it out" until all the packages come through? "ready" is a place where packages are moved over longer period of time to get kind of package set ready to be moved to "main". > Why did > things that depend on new glibc move over from th-test before glibc? Because there is no checking in python scripts for that. > Caleb -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From caleb at pld-linux.org Fri Jun 3 17:49:19 2011 From: caleb at pld-linux.org (Caleb Maclennan) Date: Fri, 3 Jun 2011 18:49:19 +0300 Subject: Deps in TH In-Reply-To: <201106031738.25491.arekm@maven.pl> References: <201106031738.25491.arekm@maven.pl> Message-ID: > "ready" is a place where packages are moved over longer period of time to get > kind of package set ready to be moved to "main". So is there a reason Gnome3 skipped the "ready" tree? > Because there is no checking in python scripts for that. Shouldn't there be some kind of test using rpm to check that dependencies for anything in a tree are provided by packages in the same tree? Caleb From arekm at maven.pl Fri Jun 3 17:55:18 2011 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Fri, 3 Jun 2011 17:55:18 +0200 Subject: Deps in TH In-Reply-To: References: <201106031738.25491.arekm@maven.pl> Message-ID: <201106031755.18500.arekm@maven.pl> On Friday 03 of June 2011, Caleb Maclennan wrote: > > "ready" is a place where packages are moved over longer period of time to > > get kind of package set ready to be moved to "main". > > So is there a reason Gnome3 skipped the "ready" tree? Hm, it was there for some time. It wasn't complete but nothing major was missing (it didn't have metapackage-gnome for example) > > Because there is no checking in python scripts for that. > > Shouldn't there be some kind of test using rpm to check that > dependencies for anything in a tree are provided by packages in the > same tree? We don't have such thing. Feel free to implement (cvs/pld-ftp-admin) but note that in needs to be fast (and speed is the major problem). > Caleb -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From n3npq at mac.com Fri Jun 3 18:17:20 2011 From: n3npq at mac.com (Jeff Johnson) Date: Fri, 03 Jun 2011 12:17:20 -0400 Subject: Deps in TH In-Reply-To: <201106031755.18500.arekm@maven.pl> References: <201106031738.25491.arekm@maven.pl> <201106031755.18500.arekm@maven.pl> Message-ID: On Jun 3, 2011, at 11:55 AM, Arkadiusz Miskiewicz wrote: > > We don't have such thing. Feel free to implement (cvs/pld-ftp-admin) but note > that in needs to be fast (and speed is the major problem). > Its rather easy to do rpm -ivh --dbpath /somewhere/rpmdb --justdb --nonothing *.rpm and then do rpm -Va --nofiles --dbpath /somewhere/rpmdb mechanically. Quite fast too. All that's hard there is getting the *.rpm to be _EXACTLY_ what you want. Yes there isn't a --nonothing option in rpm (but could be added with a popt alias). 73 de Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4645 bytes Desc: not available URL: From glen at delfi.ee Sat Jun 4 15:41:36 2011 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=C3=A4e?=) Date: Sat, 04 Jun 2011 16:41:36 +0300 Subject: Deps in TH In-Reply-To: References: <201106031738.25491.arekm@maven.pl> <201106031755.18500.arekm@maven.pl> Message-ID: <64b4635e09ada53bd6de6d92a79577fd@delfi.ee> On Fri, 03 Jun 2011 12:17:20 -0400, Jeff Johnson wrote: > On Jun 3, 2011, at 11:55 AM, Arkadiusz Miskiewicz wrote: >> >> We don't have such thing. Feel free to implement (cvs/pld-ftp-admin) >> but note >> that in needs to be fast (and speed is the major problem). >> > > Its rather easy to do > rpm -ivh --dbpath /somewhere/rpmdb --justdb --nonothing *.rpm > and then do > rpm -Va --nofiles --dbpath /somewhere/rpmdb > mechanically. Quite fast too. > > All that's hard there is getting the *.rpm to be _EXACTLY_ what you > want. getting *.rpm to be all packages from distro, is trivial using existing scripts, but as the packages conflict with each other (providing same functionality) can't be installed at the same time, and figuring out such conflicts is manual work -- glen From n3npq at mac.com Sat Jun 4 15:47:57 2011 From: n3npq at mac.com (Jeff Johnson) Date: Sat, 04 Jun 2011 09:47:57 -0400 Subject: Deps in TH In-Reply-To: <64b4635e09ada53bd6de6d92a79577fd@delfi.ee> References: <201106031738.25491.arekm@maven.pl> <201106031755.18500.arekm@maven.pl> <64b4635e09ada53bd6de6d92a79577fd@delfi.ee> Message-ID: <78327033-7EC2-4900-AC83-94C4D90A4321@mac.com> On Jun 4, 2011, at 9:41 AM, Elan Ruusam?e wrote: > On Fri, 03 Jun 2011 12:17:20 -0400, Jeff Johnson wrote: >> On Jun 3, 2011, at 11:55 AM, Arkadiusz Miskiewicz wrote: >>> >>> We don't have such thing. Feel free to implement (cvs/pld-ftp-admin) but note >>> that in needs to be fast (and speed is the major problem). >>> >> >> Its rather easy to do >> rpm -ivh --dbpath /somewhere/rpmdb --justdb --nonothing *.rpm >> and then do >> rpm -Va --nofiles --dbpath /somewhere/rpmdb >> mechanically. Quite fast too. >> >> All that's hard there is getting the *.rpm to be _EXACTLY_ what you want. > > getting *.rpm to be all packages from distro, is trivial using existing scripts, but as the packages conflict with each other (providing same functionality) can't be installed at the same time, and figuring out such conflicts is manual work > Note that Conflicts: with missing values are broken in RPM. Note also that rpm -Vp --nofiles --noscripts *.rpm is an even simpler detection scheme. So don't. Missing dependency detction is rather easy to automate, and is the common complaint for aggregations of *.rpm packages. If you need every detail perfectly verified instantly, then note that the assertion ... speed is the major problem. isn't as big a problem as apathy is. 73 de Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4645 bytes Desc: not available URL: From glen at delfi.ee Sat Jun 4 16:06:43 2011 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=C3=A4e?=) Date: Sat, 04 Jun 2011 17:06:43 +0300 Subject: processes ulimit weirdness [solved] [further problems] In-Reply-To: <4DDB895D.9000602@pld-linux.org> References: <4DD665F1.3000105@pld-linux.org> <6b15d3970f82ade75b9c8c14596fdcb5@delfi.ee> <4DDB895D.9000602@pld-linux.org> Message-ID: <8803275d99bae6ce7fd2a2b0ac1b248e@delfi.ee> On Tue, 24 May 2011 13:33:01 +0300, Elan Ruusam?e wrote: > On 22.05.2011 15:27, Elan Ruusam?e wrote: >> so far seems downgrade of sudo helped, one from th-archives >> sudo-1.7.4p6-1.i686 = OK >> sudo-1.7.5-1.i686 = FAIL >> sudo-1.7.6-1.i686 = FAIL > > the actual fix was to upgrade away from buggy kernel > > broken: > 2.6.36.2-1 > util-vserver-0.30.216-1.pre2955.3.x86_64 > > better: > 2.6.37.6-2 > util-vserver-0.30.216-1.pre2955.3.x86_64 2.6.37.6-2 on the other hand has other bad behaviour, like two vservers sending to each other lots of concurrent http connections, made apache processes stall in D state (mostly the main watcher), lots of Z and port 80 unresponsive for several minutes, when it just recovered. actually the http connections were coming off the internet, same "lockup" was noticed, so far had to downgrade to 2.6.36.2-1 kernel and sudo-1.7.4p6-1.i686 to continue normal work -- glen From lisu87 at gmail.com Mon Jun 6 08:44:56 2011 From: lisu87 at gmail.com (Michal Lisowski) Date: Mon, 06 Jun 2011 08:44:56 +0200 Subject: packages: qbittorrent/qbittorrent.spec - 2.8.0 - rel 1 In-Reply-To: References:

Message-ID: <4DEC7768.6070107@gmail.com> W dniu 04.06.2011 15:42, uzsolt pisze: > Author: uzsolt Date: Sat Jun 4 13:42:30 2011 GMT > Module: packages Tag: HEAD > ---- Log message: > - 2.8.0 > - rel 1 And also merge it with DEVEL, please. From qboosh at pld-linux.org Mon Jun 6 09:21:38 2011 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Mon, 6 Jun 2011 09:21:38 +0200 Subject: packages: transmission/transmission.spec - ta_LK (Sri Lanka Tamil) unsuppor... In-Reply-To: References:

Message-ID: <20110606072138.GB10896@stranger.qboosh.pl> On Fri, Jun 03, 2011 at 03:05:53PM +0300, Caleb Maclennan wrote: > >> >> - ta_LK (Sri Lanka Tamil) unsupported, rel 2 > >> >> > >> > caleb, why only this one? :) > >> > >> Valid question. The workings of ?find_lang and some other rpm ninja > >> tricks are still slightly magic to me. > >> > >> In this case, because it worked. That one language was causing RPM to > >> fail to install, and removing it allowed it to be installed without > >> errors. > >> > > > > ok, my first through was that we drop languages that it's impossible that > > PLD user will ever use, and second... "why only this one" :) > > There are an awful lot that could not realistically be used. Has the > possibility of a whitelist of fully included languages been > considered? It seems like every spec has a different list of > problematic languages that have to be cleaned up, but across the > distro there isn't a lot of consistency here. Well, up to date supported locales list is in glibc, particularly: - as comments in glibc.spec (for locales already handled in some way in PLD) - in /usr/share/i18n/SUPPORTED file (locales supported by glibc) We don't artificially drop some locale just because it's "unlikely to be used". > > on what environment it fails to build? I had no problems with transmission. > > It didn't fail to build, the resulting rpm fails to install with a > dependency error on a tl_LK language directory. (TH 64) So far (glibc 2.13, I haven't checked 2.14), Tamil (ta) is supported only or India (LANG=ta_IN). -- Jakub Bogusz http://qboosh.pl/ From udvzsolt at gmail.com Mon Jun 6 09:49:40 2011 From: udvzsolt at gmail.com (Zsolt Udvari) Date: Mon, 6 Jun 2011 09:49:40 +0200 Subject: packages: qbittorrent/qbittorrent.spec - 2.8.0 - rel 1 In-Reply-To: <4DEC7768.6070107@gmail.com> References:

<4DEC7768.6070107@gmail.com> Message-ID: Is it ok? -BuildRequires: libtorrent-rasterbar-devel >= 1:0.15.5 +BuildRequires: libtorrent-rasterbar-devel >= 1:0.15.6 -Requires: libtorrent-rasterbar >= 1:0.15.5 +Requires: libtorrent-rasterbar >= 1:0.15.6 I think, %pre is unnecessary in MAIN :) Sorry for my mistake. Zsolt 2011/6/6 Michal Lisowski : > W dniu 04.06.2011 15:42, uzsolt pisze: >> >> Author: uzsolt ? ? ? ? ? ? ? ? ? ? ? Date: Sat Jun ?4 13:42:30 2011 GMT >> Module: packages ? ? ? ? ? ? ? ? ? ? ?Tag: HEAD >> ---- Log message: >> - 2.8.0 >> - rel 1 > > And also merge it with DEVEL, please. > > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > From lisu87 at gmail.com Mon Jun 6 09:52:10 2011 From: lisu87 at gmail.com (Michal Lisowski) Date: Mon, 06 Jun 2011 09:52:10 +0200 Subject: packages: qbittorrent/qbittorrent.spec - 2.8.0 - rel 1 In-Reply-To: References:

<4DEC7768.6070107@gmail.com> Message-ID: <4DEC872A.8070104@gmail.com> W dniu 06.06.2011 09:49, Zsolt Udvari pisze: > Is it ok? > > -BuildRequires: libtorrent-rasterbar-devel>= 1:0.15.5 > +BuildRequires: libtorrent-rasterbar-devel>= 1:0.15.6 > > -Requires: libtorrent-rasterbar>= 1:0.15.5 > +Requires: libtorrent-rasterbar>= 1:0.15.6 > > I think, %pre is unnecessary in MAIN :) > > Sorry for my mistake. commits logs should be merged too... From udvzsolt at gmail.com Mon Jun 6 09:57:51 2011 From: udvzsolt at gmail.com (Zsolt Udvari) Date: Mon, 6 Jun 2011 09:57:51 +0200 Subject: packages: qbittorrent/qbittorrent.spec - 2.8.0 - rel 1 In-Reply-To: <4DEC872A.8070104@gmail.com> References:

<4DEC7768.6070107@gmail.com> <4DEC872A.8070104@gmail.com> Message-ID: > commits logs should be merged too... How can I do this? Where should I insert this? From lisu87 at gmail.com Mon Jun 6 10:00:56 2011 From: lisu87 at gmail.com (Michal Lisowski) Date: Mon, 06 Jun 2011 10:00:56 +0200 Subject: packages: qbittorrent/qbittorrent.spec - 2.8.0 - rel 1 In-Reply-To: References:

<4DEC7768.6070107@gmail.com> <4DEC872A.8070104@gmail.com> Message-ID: <4DEC8938.9050500@gmail.com> W dniu 06.06.2011 09:57, Zsolt Udvari pisze: >> commits logs should be merged too... > How can I do this? Where should I insert this? Use copy-paste method and insert all commit logs for 1.99.2 revisions between revision 1.99 and 1.100. From udvzsolt at gmail.com Mon Jun 6 10:49:22 2011 From: udvzsolt at gmail.com (Zsolt Udvari) Date: Mon, 6 Jun 2011 10:49:22 +0200 Subject: packages: qbittorrent/qbittorrent.spec - 2.8.0 - rel 1 In-Reply-To: <4DEC8938.9050500@gmail.com> References:

<4DEC7768.6070107@gmail.com> <4DEC872A.8070104@gmail.com> <4DEC8938.9050500@gmail.com> Message-ID: Ok, done. 2011/6/6 Michal Lisowski : > W dniu 06.06.2011 09:57, Zsolt Udvari pisze: >>> >>> commits logs should be merged too... >> >> How can I do this? Where should I insert this? > > Use copy-paste method and insert all commit logs for 1.99.2 revisions > between revision 1.99 and 1.100. > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > From przemo at firszt.eu Mon Jun 6 18:52:41 2011 From: przemo at firszt.eu (Przemo Firszt) Date: Mon, 06 Jun 2011 17:52:41 +0100 Subject: [PATCH] anki - missing python-sip-devel + up to 1.2.8 In-Reply-To: <1306958805.3563.2.camel@pldmachine> References: <1306958805.3563.2.camel@pldmachine> Message-ID: <1307379161.3288.2.camel@pldmachine> Dnia 2011-06-01, ?ro o godzinie 21:06 +0100, Przemo Firszt pisze: [..] > Patch 0 -> fixes missing "Requires" > Patch 1 -> version up to 1.2.8 > Patch 2 - > Add: Suggests: python-matplotlib It's required to use Graphs function -- Regards, Przemo Firszt -------------- next part -------------- A non-text attachment was scrubbed... Name: anki.spec.2.patch Type: text/x-patch Size: 554 bytes Desc: not available URL: From qboosh at pld-linux.org Sun Jun 12 18:08:25 2011 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sun, 12 Jun 2011 18:08:25 +0200 Subject: packages: libtirpc/libtirpc.spec, libtirpc/libtirpc-nis.patch (NEW), libtir... In-Reply-To: References:

Message-ID: <20110612160825.GA25363@stranger.qboosh.pl> On Sun, Jun 12, 2011 at 03:55:32PM +0200, arekm wrote: > Author: arekm Date: Sun Jun 12 13:55:32 2011 GMT > Module: packages Tag: HEAD > ---- Log message: > - headers in place where it was in glibc > +# FIXME: this allows invalid (unresolved symbols) library to be installed. > +# Left until upstream fixes this properly. > +%define no_install_post_check_so 1 There are more source files, not included in Makefile.am (like crypt_client.c, key_call.c, netname.c) - maybe they cover all the missing symbols. Distributing broken library is pointless. > +# rpc headers for glibc 2.14+ > +install -d $RPM_BUILD_ROOT%{_includedir}/rpc > +ln -s tirpc/netconfig.h $RPM_BUILD_ROOT%{_includedir}/netconfig.h > +for i in $RPM_BUILD_ROOT%{_includedir}/tirpc/rpc/*.h; do > + i="$(basename $i)" > + ln -s ../tirpc/rpc/$i $RPM_BUILD_ROOT%{_includedir}/rpc/$i > +done I don't think this is good idea - additional library is needed anyway. So if additional linker option is required (pkg-config --libs libtirpc), requiring similar compiler/preprocessor option (pkg-config --cflags libtirpc) is rational. -- Jakub Bogusz http://qboosh.pl/ From qboosh at pld-linux.org Sun Jun 12 19:58:30 2011 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sun, 12 Jun 2011 19:58:30 +0200 Subject: packages: libtirpc/libtirpc.spec, libtirpc/libtirpc-nis.patch (NEW), libtir... In-Reply-To: <20110612160825.GA25363@stranger.qboosh.pl> References:

<20110612160825.GA25363@stranger.qboosh.pl> Message-ID: <20110612175830.GA5300@stranger.qboosh.pl> On Sun, Jun 12, 2011 at 06:08:25PM +0200, Jakub Bogusz wrote: > On Sun, Jun 12, 2011 at 03:55:32PM +0200, arekm wrote: > > Author: arekm Date: Sun Jun 12 13:55:32 2011 GMT > > Module: packages Tag: HEAD > > ---- Log message: > > - headers in place where it was in glibc > > > +# FIXME: this allows invalid (unresolved symbols) library to be installed. > > +# Left until upstream fixes this properly. > > +%define no_install_post_check_so 1 > > There are more source files, not included in Makefile.am (like > crypt_client.c, key_call.c, netname.c) - maybe they cover all the missing > symbols. Not sufficient... these files refer to further symbols, not available now both in glibc and libtirpc sources. Great "solution" to advise to use libtirpc instead of glibc implementation and remove symbols it relies on... :/ -- Jakub Bogusz http://qboosh.pl/ From arekm at maven.pl Sun Jun 12 18:13:13 2011 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Sun, 12 Jun 2011 18:13:13 +0200 Subject: packages: libtirpc/libtirpc.spec, libtirpc/libtirpc-nis.patch (NEW), libtir... In-Reply-To: <20110612160825.GA25363@stranger.qboosh.pl> References:

<20110612160825.GA25363@stranger.qboosh.pl> Message-ID: <201106121813.14106.arekm@maven.pl> On Sunday 12 of June 2011, Jakub Bogusz wrote: > On Sun, Jun 12, 2011 at 03:55:32PM +0200, arekm wrote: > > Author: arekm Date: Sun Jun 12 13:55:32 2011 GMT > > Module: packages Tag: HEAD > > ---- Log message: > > - headers in place where it was in glibc > > > > +# FIXME: this allows invalid (unresolved symbols) library to be > > installed. +# Left until upstream fixes this properly. > > +%define no_install_post_check_so 1 > > There are more source files, not included in Makefile.am (like > crypt_client.c, key_call.c, netname.c) - maybe they cover all the missing > symbols. ... producing more (new) unresolved symbols. > Distributing broken library is pointless. Aren't these missing symbols available from glibc? AFAIK glibc people only prevented linking with glibc rpc implementation but it is there, providing symbols runtime. > > > +# rpc headers for glibc 2.14+ > > +install -d $RPM_BUILD_ROOT%{_includedir}/rpc > > +ln -s tirpc/netconfig.h $RPM_BUILD_ROOT%{_includedir}/netconfig.h > > +for i in $RPM_BUILD_ROOT%{_includedir}/tirpc/rpc/*.h; do > > + i="$(basename $i)" > > + ln -s ../tirpc/rpc/$i $RPM_BUILD_ROOT%{_includedir}/rpc/$i > > +done > > I don't think this is good idea - additional library is needed anyway. > So if additional linker option is required (pkg-config --libs libtirpc), > requiring similar compiler/preprocessor option (pkg-config --cflags > libtirpc) is rational. Ok, I'll drop it nex time. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From qboosh at pld-linux.org Thu Jun 16 17:42:10 2011 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Thu, 16 Jun 2011 17:42:10 +0200 Subject: packages: libtirpc/libtirpc.spec, libtirpc/libtirpc-nis.patch (NEW), libtir... In-Reply-To: <201106121813.14106.arekm@maven.pl> References:

<20110612160825.GA25363@stranger.qboosh.pl> <201106121813.14106.arekm@maven.pl> Message-ID: <20110616154210.GB5300@stranger.qboosh.pl> On Sun, Jun 12, 2011 at 06:13:13PM +0200, Arkadiusz Miskiewicz wrote: > On Sunday 12 of June 2011, Jakub Bogusz wrote: > > On Sun, Jun 12, 2011 at 03:55:32PM +0200, arekm wrote: > > > Author: arekm Date: Sun Jun 12 13:55:32 2011 GMT > > > Module: packages Tag: HEAD > > > ---- Log message: > > > - headers in place where it was in glibc > > > > > > +# FIXME: this allows invalid (unresolved symbols) library to be > > > installed. +# Left until upstream fixes this properly. > > > +%define no_install_post_check_so 1 > > > > There are more source files, not included in Makefile.am (like > > crypt_client.c, key_call.c, netname.c) - maybe they cover all the missing > > symbols. > > ... producing more (new) unresolved symbols. Also removed from glibc 2.14. I've noticed it already in the second mail. > > Distributing broken library is pointless. > > Aren't these missing symbols available from glibc? AFAIK glibc people only > prevented linking with glibc rpc implementation but it is there, providing > symbols runtime. Only if they were bound to particular symbol versions from glibc at link time, which is not done, as these symbols in glibc are hidden. Maybe it's possible to link to hidden versions by using some linker script (currently I don't have enough knowledge in this area). -- Jakub Bogusz http://qboosh.pl/ From qboosh at pld-linux.org Fri Jun 17 18:11:52 2011 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Fri, 17 Jun 2011 18:11:52 +0200 Subject: uClibc 0.9.32 Message-ID: <20110617161152.GC5300@stranger.qboosh.pl> Is it OK to merge 0.9.32 on HEAD? The simple static cases (busybox functions) which were reported to fail with 0.9.31 seem to work now (tested on i686). -- Jakub Bogusz http://qboosh.pl/ From baggins at pld-linux.org Fri Jun 17 20:19:12 2011 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Fri, 17 Jun 2011 20:19:12 +0200 Subject: uClibc 0.9.32 In-Reply-To: <20110617161152.GC5300@stranger.qboosh.pl> References: <20110617161152.GC5300@stranger.qboosh.pl> Message-ID: <20110617181912.GA2748@home.lan> On Fri, 17 Jun 2011, Jakub Bogusz wrote: > Is it OK to merge 0.9.32 on HEAD? > The simple static cases (busybox functions) which were reported to fail > with 0.9.31 seem to work now (tested on i686). If the problem is fixed then go ahead and merge. -- Jan R?korajski | ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio From adamg at pld-linux.org Sat Jun 18 00:35:15 2011 From: adamg at pld-linux.org (Adam Golebiowski) Date: Sat, 18 Jun 2011 00:35:15 +0200 Subject: packages: samba/samba.spec - updated to 3.5.9 In-Reply-To: References:

Message-ID: <4DFBD6A3.4020903@pld-linux.org> W dniu 2011-06-17 21:10, adamg pisze: > Author: adamg Date: Fri Jun 17 19:10:31 2011 GMT > Module: packages Tag: HEAD > ---- Log message: > - updated to 3.5.9 As an additional argument in recent glibc/rpc discussion - samba does not compile against glibc-2.14 due to missing rpcsvc/ypclnt.h (YPERR_KEY undefined). -- adamg at pld-linux.org From qboosh at pld-linux.org Sat Jun 18 10:14:32 2011 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sat, 18 Jun 2011 10:14:32 +0200 Subject: glibc rpc/nis headers removal [Re: packages: samba/samba.spec - updated to 3.5.9] In-Reply-To: <4DFBD6A3.4020903@pld-linux.org> References:

<4DFBD6A3.4020903@pld-linux.org> Message-ID: <20110618081431.GD5300@stranger.qboosh.pl> On Sat, Jun 18, 2011 at 12:35:15AM +0200, Adam Golebiowski wrote: > W dniu 2011-06-17 21:10, adamg pisze: > > Author: adamg Date: Fri Jun 17 19:10:31 2011 GMT > > Module: packages Tag: HEAD > > ---- Log message: > > - updated to 3.5.9 > > As an additional argument in recent glibc/rpc discussion - samba does > not compile against glibc-2.14 due to missing rpcsvc/ypclnt.h (YPERR_KEY > undefined). Fedora seem to restore these headers. I've extracted small subset from huge glibc-fedora.patch -- Jakub Bogusz http://qboosh.pl/ -------------- next part -------------- --- glibc-2.14/nis/Makefile +++ glibc-2.14-2/nis/Makefile @@ -23,9 +23,9 @@ subdir := nis aux := nis_hash +headers := $(wildcard rpcsvc/*.[hx]) distribute := nss-nis.h nss-nisplus.h nis_intern.h Banner \ - nisplus-parser.h nis_xdr.h nss \ - $(wildcard rpcsvc/*.[hx]) + nisplus-parser.h nis_xdr.h nss # These are the databases available for the nis (and perhaps later nisplus) # service. This must be a superset of the services in nss. @@ -69,6 +69,8 @@ libnss_nisplus-inhibit-o = $(filter-out .os,$(object-suffixes)) include ../Rules +CFLAGS-nis_findserv.c += -fno-strict-aliasing +CFLAGS-ypclnt.c += -fno-strict-aliasing $(objpfx)libnss_compat.so: $(objpfx)libnsl.so$(libnsl.so-version) $(objpfx)libnss_nis.so: $(objpfx)libnsl.so$(libnsl.so-version) \ --- glibc-2.14/sunrpc/Makefile +++ glibc-2.14-2/sunrpc/Makefile @@ -53,7 +53,7 @@ headers-in-tirpc = $(addprefix rpc/,auth.h auth_unix.h clnt.h pmap_clnt.h \ des_crypt.h) headers-not-in-tirpc = $(addprefix rpc/,key_prot.h rpc_des.h) \ $(rpcsvc:%=rpcsvc/%) rpcsvc/bootparam.h -headers = rpc/netdb.h +headers = rpc/netdb.h $(headers-in-tirpc) $(headers-not-in-tirpc) install-others = $(inst_sysconfdir)/rpc generated = $(rpcsvc:%.x=rpcsvc/%.h) $(rpcsvc:%.x=x%.c) $(rpcsvc:%.x=x%.stmp) \ $(rpcsvc:%.x=rpcsvc/%.stmp) rpcgen @@ -152,6 +152,10 @@ CFLAGS-openchild.c = -fexceptions CPPFLAGS += -D_RPC_THREAD_SAFE_ +CFLAGS-clnt_tcp.c += -fno-strict-aliasing +CFLAGS-clnt_udp.c += -fno-strict-aliasing +CFLAGS-clnt_unix.c += -fno-strict-aliasing + $(objpfx)tst-getmyaddr: $(common-objpfx)linkobj/libc.so $(objpfx)tst-xdrmem: $(common-objpfx)linkobj/libc.so $(objpfx)tst-xdrmem2: $(common-objpfx)linkobj/libc.so From qboosh at pld-linux.org Sun Jun 19 17:03:44 2011 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sun, 19 Jun 2011 17:03:44 +0200 Subject: packages: ntfs-3g_ntfsprogs/ntfs-3g.fdi (NEW), ntfs-3g_ntfsprogs/ntfs-3g.ru... In-Reply-To: References:

Message-ID: <20110619150344.GB25363@stranger.qboosh.pl> On Sat, Jun 18, 2011 at 10:35:00PM +0200, adamg wrote: > Author: adamg Date: Sat Jun 18 20:35:00 2011 GMT > Module: packages Tag: HEAD > ---- Log message: > - new, merge of ntfs-3g and ntfsprogs, spec based on ntfs-3g.spec > - needs some work I'd rather use traditional naming for binary packages: -n ntfs-3g-{libs,devel,static} - the library -n ntfs-3g - FUSE-based mount (and helpers, if any) -n ntfs-3g-{udev,hal} -n ntfsprogs - utilities (not depending on FUSE, but with R: ntfs-3g-libs now) -- Jakub Bogusz http://qboosh.pl/ From adamg at pld-linux.org Sun Jun 19 20:51:56 2011 From: adamg at pld-linux.org (Adam Golebiowski) Date: Sun, 19 Jun 2011 20:51:56 +0200 Subject: packages: ntfs-3g_ntfsprogs/ntfs-3g.fdi (NEW), ntfs-3g_ntfsprogs/ntfs-3g.ru... In-Reply-To: <20110619150344.GB25363@stranger.qboosh.pl> References:

<20110619150344.GB25363@stranger.qboosh.pl> Message-ID: <4DFE454C.2050200@pld-linux.org> W dniu 2011-06-19 17:03, Jakub Bogusz pisze: > On Sat, Jun 18, 2011 at 10:35:00PM +0200, adamg wrote: >> Author: adamg Date: Sat Jun 18 20:35:00 2011 GMT >> Module: packages Tag: HEAD >> ---- Log message: >> - new, merge of ntfs-3g and ntfsprogs, spec based on ntfs-3g.spec >> - needs some work > > I'd rather use traditional naming for binary packages: > > -n ntfs-3g-{libs,devel,static} - the library > -n ntfs-3g - FUSE-based mount (and helpers, if any) > -n ntfs-3g-{udev,hal} > -n ntfsprogs - utilities (not depending on FUSE, but with R: ntfs-3g-libs now) Seems reasonable, good way to avoid extra `Obsoletes:'. -- adamg at pld-linux.org From arekm at maven.pl Mon Jun 20 20:30:25 2011 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Mon, 20 Jun 2011 20:30:25 +0200 Subject: Info: buildlogs and th i686, x86_64 builders Message-ID: <201106202030.25549.arekm@maven.pl> All services mentioned in subject are unavailable until tomorrow morning (likely 6:00). -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From arekm at maven.pl Tue Jun 21 07:52:32 2011 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Tue, 21 Jun 2011 07:52:32 +0200 Subject: Info: buildlogs and th i686, x86_64 builders In-Reply-To: <201106202030.25549.arekm@maven.pl> References: <201106202030.25549.arekm@maven.pl> Message-ID: <201106210752.32680.arekm@maven.pl> On Monday 20 of June 2011, Arkadiusz Miskiewicz wrote: > All services mentioned in subject are unavailable until tomorrow morning > (likely 6:00). It will take longer than expected. Machines should be reachable at evening. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From lisu87 at gmail.com Tue Jun 21 11:28:24 2011 From: lisu87 at gmail.com (Michal Lisowski) Date: Tue, 21 Jun 2011 11:28:24 +0200 Subject: python-pygments vs. python-Pygments Message-ID: <4E006438.9050007@gmail.com> Which of these should we use? From jajcus at jajcus.net Tue Jun 21 13:42:46 2011 From: jajcus at jajcus.net (Jacek Konieczny) Date: Tue, 21 Jun 2011 13:42:46 +0200 Subject: python-pygments vs. python-Pygments In-Reply-To: <4E006438.9050007@gmail.com> References: <4E006438.9050007@gmail.com> Message-ID: <20110621114245.GB29116@jajo.eggsoft> On Tue, Jun 21, 2011 at 11:28:24AM +0200, Michal Lisowski wrote: > Which of these should we use? What is the python module name ('import pygments' or 'import Pygments')? What is the name of source tar? Greets, Jacek From lisu87 at gmail.com Wed Jun 22 16:17:50 2011 From: lisu87 at gmail.com (Michal Lisowski) Date: Wed, 22 Jun 2011 16:17:50 +0200 Subject: python-pygments vs. python-Pygments In-Reply-To: <20110621114245.GB29116@jajo.eggsoft> References: <4E006438.9050007@gmail.com> <20110621114245.GB29116@jajo.eggsoft> Message-ID: <4E01F98E.5080709@gmail.com> W dniu 21.06.2011 13:42, Jacek Konieczny pisze: > What is the python module name ('import pygments' or 'import Pygments')? import pygments > What is the name of source tar? Pygments-%{version} So it can be python-pygments.spec and python-Pygments.spec. From jajcus at jajcus.net Wed Jun 22 17:34:41 2011 From: jajcus at jajcus.net (Jacek Konieczny) Date: Wed, 22 Jun 2011 17:34:41 +0200 Subject: python-pygments vs. python-Pygments In-Reply-To: <4E01F98E.5080709@gmail.com> References: <4E006438.9050007@gmail.com> <20110621114245.GB29116@jajo.eggsoft> <4E01F98E.5080709@gmail.com> Message-ID: <20110622153441.GA4095@lolek.nigdzie> On Wed, Jun 22, 2011 at 04:17:50PM +0200, Michal Lisowski wrote: > W dniu 21.06.2011 13:42, Jacek Konieczny pisze: > > What is the python module name ('import pygments' or 'import Pygments')? > > import pygments > > > What is the name of source tar? > > Pygments-%{version} > > So it can be python-pygments.spec and python-Pygments.spec. It should be python-pygments. If anything fails on 'import pygments' it is easy to find the right package. Greets, Jacek From qboosh at pld-linux.org Thu Jun 23 13:30:59 2011 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Thu, 23 Jun 2011 13:30:59 +0200 Subject: packages: glibc/glibc-restore-rpc+nis.patch (NEW) - restore RPC/NIS headers... In-Reply-To: References:

Message-ID: <20110623113058.GC25363@stranger.qboosh.pl> On Thu, Jun 23, 2011 at 01:27:01PM +0200, qboosh wrote: > Author: qboosh Date: Thu Jun 23 11:27:01 2011 GMT > Module: packages Tag: HEAD > ---- Log message: > - restore RPC/NIS headers (from F15); tirpc cannot act as replacement currently This needs checking; I don't have time to do it now. To be dropped when glibc and tirpc become ready to tirpc to take over whole RPC code. It's not now and nothing seems to happen on tirpc side currently. -- Jakub Bogusz http://qboosh.pl/ From arekm at maven.pl Thu Jun 23 13:39:11 2011 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Thu, 23 Jun 2011 13:39:11 +0200 Subject: packages: glibc/glibc-restore-rpc+nis.patch (NEW) - restore RPC/NIS headers... In-Reply-To: <20110623113058.GC25363@stranger.qboosh.pl> References:

<20110623113058.GC25363@stranger.qboosh.pl> Message-ID: <201106231339.11933.arekm@maven.pl> On Thursday 23 of June 2011, Jakub Bogusz wrote: > On Thu, Jun 23, 2011 at 01:27:01PM +0200, qboosh wrote: > > Author: qboosh Date: Thu Jun 23 11:27:01 2011 GMT > > Module: packages Tag: HEAD > > ---- Log message: > > - restore RPC/NIS headers (from F15); tirpc cannot act as replacement > > currently > > This needs checking; I don't have time to do it now. > > To be dropped when glibc and tirpc become ready to tirpc to take over > whole RPC code. It's not now and nothing seems to happen on tirpc side > currently. There are some changes in libtirpc git but still unknown symbols are used. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From qboosh at pld-linux.org Sat Jun 25 07:08:46 2011 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sat, 25 Jun 2011 07:08:46 +0200 Subject: packages: glibc/glibc-restore-rpc+nis.patch (NEW) - restore RPC/NIS headers... In-Reply-To: <201106231339.11933.arekm@maven.pl> References:

<20110623113058.GC25363@stranger.qboosh.pl> <201106231339.11933.arekm@maven.pl> Message-ID: <20110625050846.GF5300@stranger.qboosh.pl> On Thu, Jun 23, 2011 at 01:39:11PM +0200, Arkadiusz Miskiewicz wrote: > On Thursday 23 of June 2011, Jakub Bogusz wrote: > > On Thu, Jun 23, 2011 at 01:27:01PM +0200, qboosh wrote: > > > Author: qboosh Date: Thu Jun 23 11:27:01 2011 GMT > > > Module: packages Tag: HEAD > > > ---- Log message: > > > - restore RPC/NIS headers (from F15); tirpc cannot act as replacement > > > currently > > > > This needs checking; I don't have time to do it now. > > > > To be dropped when glibc and tirpc become ready to tirpc to take over > > whole RPC code. It's not now and nothing seems to happen on tirpc side > > currently. > > There are some changes in libtirpc git but still unknown symbols are used. AFAICS the only change related to unresolved symbols is the same as my des-in-libc patch. -- Jakub Bogusz http://qboosh.pl/ From glen at pld-linux.org Tue Jun 28 20:00:04 2011 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Tue, 28 Jun 2011 21:00:04 +0300 Subject: packages: calibre/calibre.spec - updated to 0.8.7 - updated no-update.patch... In-Reply-To: References:

Message-ID: <4E0A16A4.3030900@pld-linux.org> On 28.06.2011 10:19, lisu wrote: > ---- Log message: > - updated to 0.8.7 > - updated no-update.patch > - adapt locales handling to upstream changes (locale files are now placed into a single zip file) upstream is stupid does not mean we should follow it? that is not good for distro, perhaps revert their single zip version and keep using separate .mo -- glen From lisu87 at gmail.com Wed Jun 29 11:40:08 2011 From: lisu87 at gmail.com (Michal Lisowski) Date: Wed, 29 Jun 2011 11:40:08 +0200 Subject: packages: calibre/calibre.spec - updated to 0.8.7 - updated no-update.patch... In-Reply-To: <4E0A16A4.3030900@pld-linux.org> References:

<4E0A16A4.3030900@pld-linux.org> Message-ID: <4E0AF2F8.1020109@gmail.com> W dniu 28.06.2011 20:00, Elan Ruusam?e pisze: > On 28.06.2011 10:19, lisu wrote: >> ---- Log message: >> - updated to 0.8.7 >> - updated no-update.patch >> - adapt locales handling to upstream changes (locale files are now >> placed into a single zip file) > > upstream is stupid does not mean we should follow it? > > that is not good for distro, perhaps revert their single zip version > and keep using separate .mo > Should be ok now, works for me. From glen at pld-linux.org Wed Jun 29 13:18:58 2011 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Wed, 29 Jun 2011 14:18:58 +0300 Subject: packages: calibre/calibre.spec - updated to 0.8.7 - updated no-update.patch... In-Reply-To: <4E0AF2F8.1020109@gmail.com> References:

<4E0A16A4.3030900@pld-linux.org> <4E0AF2F8.1020109@gmail.com> Message-ID: <4E0B0A22.2010606@pld-linux.org> On 29.06.2011 12:40, Michal Lisowski wrote: > W dniu 28.06.2011 20:00, Elan Ruusam?e pisze: >> On 28.06.2011 10:19, lisu wrote: >>> ---- Log message: >>> - updated to 0.8.7 >>> - updated no-update.patch >>> - adapt locales handling to upstream changes (locale files are now >>> placed into a single zip file) >> >> upstream is stupid does not mean we should follow it? >> >> that is not good for distro, perhaps revert their single zip version >> and keep using separate .mo >> > > Should be ok now, works for me. great success! -- glen From udvzsolt at gmail.com Wed Jun 29 13:25:26 2011 From: udvzsolt at gmail.com (Zsolt Udvari) Date: Wed, 29 Jun 2011 13:25:26 +0200 Subject: ccache BR Message-ID: Hi all! I don't know should I/we do anything, but I've found this error: make[1]: ccache: Command not found Should we include "BR: ccache" to almost all spec? Or any other way? Zsolt From sparky at pld-linux.org Wed Jun 29 13:27:42 2011 From: sparky at pld-linux.org (Przemyslaw Iskra) Date: Wed, 29 Jun 2011 13:27:42 +0200 Subject: ccache BR In-Reply-To: References: Message-ID: <20110629112742.GA25028@pld-linux.org> On Wed, Jun 29, 2011 at 01:25:26PM +0200, Zsolt Udvari wrote: > Hi all! > > I don't know should I/we do anything, but I've found this error: > > make[1]: ccache: Command not found > > Should we include "BR: ccache" to almost all spec? Or any other way? You could start by fixing your local setup / carme account. [sparky at carme-pld ~]$ rpm -E "%{__cc}" ccache x86_64-pld-linux-gcc ^- this is not the default in bare rpm Best regards, Przemys?aw Iskra. -- ____ sparky -- Przemyslaw ................ LANG...Pl,Ca,Es,En /____) ___ ___ _ _ || Iskra : WWW . http://ppcrcd.pld-linux.org/ \____\| -_)'___| ||^'||//\\// : WWW2 ............ http://rsget.pl/ (____/|| (_-_|_|| ||\\ || : eMail ..... From udvzsolt at gmail.com Wed Jun 29 13:59:29 2011 From: udvzsolt at gmail.com (Zsolt Udvari) Date: Wed, 29 Jun 2011 13:59:29 +0200 Subject: ccache BR In-Reply-To: <20110629112742.GA25028@pld-linux.org> References: <20110629112742.GA25028@pld-linux.org> Message-ID: Yes, I know that should install ccache. But I think if appears in spec files the "BR: tar" (Sparky, you've added this line into awesome.spec), maybe should present "BR: ccache". As I see, you can uninstall ccache without any broken deps. Or maybe rpm-build-tools should requires ccache. Or is it not so simple? 2011/6/29 Przemyslaw Iskra : > On Wed, Jun 29, 2011 at 01:25:26PM +0200, Zsolt Udvari wrote: >> Hi all! >> >> I don't know should I/we do anything, but I've found this error: >> >> make[1]: ccache: Command not found >> >> Should we include "BR: ccache" to almost all spec? Or any other way? > > You could start by fixing your local setup / carme account. > > [sparky at carme-pld ~]$ rpm -E "%{__cc}" > ccache x86_64-pld-linux-gcc > > > ^- this is not the default in bare rpm > > > Best regards, > ? ? ? ?Przemys?aw Iskra. > > -- > ?____ ? ?sparky ?-- ?Przemyslaw ?................ LANG...Pl,Ca,Es,En > /____) ___ ?___ ?_ _ || Iskra ? : WWW . http://ppcrcd.pld-linux.org/ > \____\| -_)'___| ||^'||//\\// ? : WWW2 ............ http://rsget.pl/ > (____/|| ? (_-_|_|| ?||\\ || ? ?: eMail ..... > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > From sparky at pld-linux.org Wed Jun 29 14:06:40 2011 From: sparky at pld-linux.org (Przemyslaw Iskra) Date: Wed, 29 Jun 2011 14:06:40 +0200 Subject: ccache BR In-Reply-To: References: <20110629112742.GA25028@pld-linux.org> Message-ID: <20110629120640.GA2838@pld-linux.org> On Wed, Jun 29, 2011 at 01:59:29PM +0200, Zsolt Udvari wrote: > Yes, I know that should install ccache. Noone says that you should. I was saying that you should have configuration matching your current system. > But I think if appears in spec > files the "BR: tar" (Sparky, you've added this line into > awesome.spec), maybe should present "BR: ccache". As I see, you can > uninstall ccache without any broken deps. Or maybe rpm-build-tools > should requires ccache. > Or is it not so simple? Nothing in default configuration requires ccache, so it should not be required. And BR: tar is a completely different story - there I added: BuildRequires: tar >= 1:1.22 because the source is compressed with .xz and older tars cannot guess the compression. The same way we add BR: sed >= 4.0 but never BR: sed Best regards, Przemys?aw Iskra. -- ____ sparky -- Przemyslaw ................ LANG...Pl,Ca,Es,En /____) ___ ___ _ _ || Iskra : WWW . http://ppcrcd.pld-linux.org/ \____\| -_)'___| ||^'||//\\// : WWW2 ............ http://rsget.pl/ (____/|| (_-_|_|| ||\\ || : eMail ..... From udvzsolt at gmail.com Wed Jun 29 14:21:55 2011 From: udvzsolt at gmail.com (Zsolt Udvari) Date: Wed, 29 Jun 2011 14:21:55 +0200 Subject: ccache BR In-Reply-To: <20110629120640.GA2838@pld-linux.org> References: <20110629112742.GA25028@pld-linux.org> <20110629120640.GA2838@pld-linux.org> Message-ID: > Nothing in default configuration requires ccache, so it should not be > required. Oh, okay. But I think rpm-build-tools can suggests ccache because of default %{__cc}. From sparky at pld-linux.org Wed Jun 29 14:25:15 2011 From: sparky at pld-linux.org (Przemyslaw Iskra) Date: Wed, 29 Jun 2011 14:25:15 +0200 Subject: ccache BR In-Reply-To: References: <20110629112742.GA25028@pld-linux.org> <20110629120640.GA2838@pld-linux.org> Message-ID: <20110629122515.GA5584@pld-linux.org> On Wed, Jun 29, 2011 at 02:21:55PM +0200, Zsolt Udvari wrote: > > Nothing in default configuration requires ccache, so it should not be > > required. > Oh, okay. But I think rpm-build-tools can suggests ccache because of > default %{__cc}. [sparky at quad ~/rpm/packages *master]$ grep -r ccache rpm-build-macros [sparky at quad ~/rpm/packages *master]$ Am I missing something ? Best regards, Przemys?aw Iskra. -- ____ sparky -- Przemyslaw ................ LANG...Pl,Ca,Es,En /____) ___ ___ _ _ || Iskra : WWW . http://ppcrcd.pld-linux.org/ \____\| -_)'___| ||^'||//\\// : WWW2 ............ http://rsget.pl/ (____/|| (_-_|_|| ||\\ || : eMail ..... From udvzsolt at gmail.com Wed Jun 29 14:32:56 2011 From: udvzsolt at gmail.com (Zsolt Udvari) Date: Wed, 29 Jun 2011 14:32:56 +0200 Subject: ccache BR In-Reply-To: <20110629122515.GA5584@pld-linux.org> References: <20110629112742.GA25028@pld-linux.org> <20110629120640.GA2838@pld-linux.org> <20110629122515.GA5584@pld-linux.org> Message-ID: > [sparky at quad ~/rpm/packages *master]$ grep -r ccache rpm-build-macros > [sparky at quad ~/rpm/packages *master]$ > > Am I missing something ? Hm. Indeed. I thought that ccache is in the default config. Sorry ;) Zsolt From arekm at maven.pl Wed Jun 29 18:22:29 2011 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Wed, 29 Jun 2011 18:22:29 +0200 Subject: packages: lftp/lftp.spec, lftp/lftp-pl.po-update.patch - added pl.po-update... In-Reply-To: References:

Message-ID: <201106291822.29712.arekm@maven.pl> On Sunday 19 of June 2011, qboosh wrote: > Author: qboosh Date: Sun Jun 19 14:09:55 2011 GMT > Module: packages Tag: HEAD > ---- Log message: > - added pl.po-update patch Was this send upstream? -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From glen at pld-linux.org Wed Jun 29 19:10:52 2011 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Wed, 29 Jun 2011 20:10:52 +0300 Subject: ccache BR In-Reply-To: References: <20110629112742.GA25028@pld-linux.org> <20110629120640.GA2838@pld-linux.org> Message-ID: <4E0B5C9C.8010003@pld-linux.org> On 29.06.2011 15:21, Zsolt Udvari wrote: >> Nothing in default configuration requires ccache, so it should not be >> required. > Oh, okay. But I think rpm-build-tools can suggests ccache because of > default %{__cc}. ccache is not by default in %__cc, review your local ~/.rpmmacros -- glen From glen at pld-linux.org Wed Jun 29 19:15:09 2011 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Wed, 29 Jun 2011 20:15:09 +0300 Subject: ccache BR In-Reply-To: References: Message-ID: <4E0B5D9D.4080604@pld-linux.org> On 29.06.2011 14:25, Zsolt Udvari wrote: > Hi all! > > I don't know should I/we do anything, but I've found this error: > > make[1]: ccache: Command not found > > Should we include "BR: ccache" to almost all spec? Or any other way? if the ccache is included into CC due it was present at build time, those package should be standardized and fixed somehow one example is apxs which picks compile time CC/CFLAGS/CXXFLAGS... it is not critical, as packages built by builders have plain cc $ apxs -q CC x86_64-pld-linux-gcc i suggest passing CC in each spec you build: apache1-mod_fastcgi.spec: %{apxs} -S CC="%{__cc}" -o mod_%{mod_name}.so -c *.c -- glen From arekm at maven.pl Wed Jun 29 21:49:11 2011 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Wed, 29 Jun 2011 21:49:11 +0200 Subject: uClibc 0.9.32 In-Reply-To: <20110617161152.GC5300@stranger.qboosh.pl> References: <20110617161152.GC5300@stranger.qboosh.pl> Message-ID: <201106292149.11768.arekm@maven.pl> On Friday 17 of June 2011, Jakub Bogusz wrote: > Is it OK to merge 0.9.32 on HEAD? > The simple static cases (busybox functions) which were reported to fail > with 0.9.31 seem to work now (tested on i686). This one fails: [arekm at carme-pld-i686 ~]$ cat a1.c int main () { ; return 0; } [arekm at carme-pld-i686 ~]$ i686-uclibc-gcc -o conftest -O2 -fno-strict-aliasing -fwrapv -march=i686 -mtune=pentium4 -gdwarf-4 -g2 -D_FORTIFY_SOURCE=2 -Wl,-- as-needed -Wl,--no-copy-dt-needed-entries -Wl,-z,relro -Wl,-z,combreloc a1.c [arekm at carme-pld-i686 ~]$ ./conftest zsh: segmentation fault ./conftest [arekm at carme-pld-i686 ~]$ gdb ./conftest GNU gdb (GDB) PLD Linux (7.2-3) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pld-linux". For bug reporting instructions, please see: ... Reading symbols from /home/users/arekm/conftest...done. (gdb) r Starting program: /home/users/arekm/conftest Program received signal SIGSEGV, Segmentation fault. 0xf7ffaa96 in _dl_get_ready_to_run () from /usr/i686-linux-uclibc/lib/ld- uClibc.so.0 (gdb) quit A debugging session is active. Inferior 1 [process 86675] will be killed. Quit anyway? (y or n) y [arekm at carme-pld-i686 ~]$ rpm -q uClibc uClibc-0.9.32-2.i686 [arekm at carme-pld-i686 ~]$ -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From qboosh at pld-linux.org Thu Jun 30 06:51:53 2011 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Thu, 30 Jun 2011 06:51:53 +0200 Subject: uClibc 0.9.32 In-Reply-To: <201106292149.11768.arekm@maven.pl> References: <20110617161152.GC5300@stranger.qboosh.pl> <201106292149.11768.arekm@maven.pl> Message-ID: <20110630045153.GA27728@mail> On Wed, Jun 29, 2011 at 09:49:11PM +0200, Arkadiusz Miskiewicz wrote: > On Friday 17 of June 2011, Jakub Bogusz wrote: > > Is it OK to merge 0.9.32 on HEAD? > > The simple static cases (busybox functions) which were reported to fail > > with 0.9.31 seem to work now (tested on i686). > > This one fails: > > [arekm at carme-pld-i686 ~]$ cat a1.c > int > main () > { > > ; > return 0; > } > > [arekm at carme-pld-i686 ~]$ i686-uclibc-gcc -o conftest -O2 -fno-strict-aliasing > -fwrapv -march=i686 -mtune=pentium4 -gdwarf-4 -g2 -D_FORTIFY_SOURCE=2 -Wl,-- > as-needed -Wl,--no-copy-dt-needed-entries -Wl,-z,relro -Wl,-z,combreloc a1.c > [arekm at carme-pld-i686 ~]$ ./conftest > zsh: segmentation fault ./conftest Uhm :/ More complex programs (like busybox) used to work for me at the time of testing. I don't think dwarf-4 is the reason. Does switching ld to bfd version help? -- Jakub Bogusz http://qboosh.pl/ From arekm at maven.pl Thu Jun 30 07:48:15 2011 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Thu, 30 Jun 2011 07:48:15 +0200 Subject: uClibc 0.9.32 In-Reply-To: <20110630045153.GA27728@mail> References: <20110617161152.GC5300@stranger.qboosh.pl> <201106292149.11768.arekm@maven.pl> <20110630045153.GA27728@mail> Message-ID: <201106300748.15197.arekm@maven.pl> On Thursday 30 of June 2011, Jakub Bogusz wrote: > On Wed, Jun 29, 2011 at 09:49:11PM +0200, Arkadiusz Miskiewicz wrote: > > On Friday 17 of June 2011, Jakub Bogusz wrote: > > > Is it OK to merge 0.9.32 on HEAD? > > > The simple static cases (busybox functions) which were reported to fail > > > with 0.9.31 seem to work now (tested on i686). > > > > This one fails: > > > > [arekm at carme-pld-i686 ~]$ cat a1.c > > int > > main () > > { > > > > ; > > > > return 0; > > > > } > > > > [arekm at carme-pld-i686 ~]$ i686-uclibc-gcc -o conftest -O2 > > -fno-strict-aliasing -fwrapv -march=i686 -mtune=pentium4 -gdwarf-4 -g2 > > -D_FORTIFY_SOURCE=2 -Wl,-- as-needed -Wl,--no-copy-dt-needed-entries > > -Wl,-z,relro -Wl,-z,combreloc a1.c [arekm at carme-pld-i686 ~]$ ./conftest > > zsh: segmentation fault ./conftest > > Uhm :/ > More complex programs (like busybox) used to work for me at the time of > testing. > I don't think dwarf-4 is the reason. > > Does switching ld to bfd version help? Current uClibc started to work (after rebuild). Weird because it still uses /usr/bin/ld when using uclibc wrapper. -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From qboosh at pld-linux.org Thu Jun 30 19:07:42 2011 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Thu, 30 Jun 2011 19:07:42 +0200 Subject: packages: lftp/lftp.spec, lftp/lftp-pl.po-update.patch - added pl.po-update... In-Reply-To: <201106291822.29712.arekm@maven.pl> References:

<201106291822.29712.arekm@maven.pl> Message-ID: <20110630170742.GJ5300@stranger.qboosh.pl> On Wed, Jun 29, 2011 at 06:22:29PM +0200, Arkadiusz Miskiewicz wrote: > On Sunday 19 of June 2011, qboosh wrote: > > Author: qboosh Date: Sun Jun 19 14:09:55 2011 GMT > > Module: packages Tag: HEAD > > ---- Log message: > > - added pl.po-update patch > > Was this send upstream? That one no, there were only few changes. The new one, yes. -- Jakub Bogusz http://qboosh.pl/