From caleb at pld-linux.org Fri Oct 1 12:00:25 2010 From: caleb at pld-linux.org (Caleb Maclennan) Date: Fri, 1 Oct 2010 13:00:25 +0300 Subject: kernel-xenU on non-64bit EC2 instance Message-ID: Alright guys I'm lost. I've been poking around in specs trying to figure this out and can't make out what I'm supposed to use or what I need to work on if there isn't the right thing available. I am trying to maintain several TH machines on i386 instances over on EC2. They have recently opened up their systems to running custom kernels inside the instance using pv-grub. I can't figure out what pld kernel package to use for this. The kernel-xenU package is set to x86_64 only? The kernel-xen package was last maintained in 2008? The kernel package doesn't have xen block drivers. What path should I be pursuing here? Caleb From pawelz at pld-linux.org Fri Oct 1 12:10:16 2010 From: pawelz at pld-linux.org (=?iso-8859-2?Q?Pawe=B3?= Zuzelski) Date: Fri, 1 Oct 2010 12:10:16 +0200 Subject: kernel-xenU on non-64bit EC2 instance In-Reply-To: References: Message-ID: <20101001101016.GA4715@pzz.touk.pl> On Fri, 01 Oct 2010, Caleb Maclennan wrote: > Alright guys I'm lost. I've been poking around in specs trying to > figure this out and can't make out what I'm supposed to use or what I > need to work on if there isn't the right thing available. > > I am trying to maintain several TH machines on i386 instances over on > EC2. They have recently opened up their systems to running custom > kernels inside the instance using pv-grub. I can't figure out what pld > kernel package to use for this. > > The kernel-xenU package is set to x86_64 only? Yes, that is because I use xen domU on x86_64 machines only. If you need xen domU on i686, feel free to add this arch to kernel-xenU.spec. Any help with this spec will be appreciate. > The kernel-xen package was last maintained in 2008? Yes, it is obsolte. > The kernel package doesn't have xen block drivers. Yes, other kernels are compiled without xen domU support. Use kernel-xenU.spec (and please, help to develop/test it on 32 archs). -- Pawe? From glen at pld-linux.org Fri Oct 1 16:14:33 2010 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Fri, 01 Oct 2010 17:14:33 +0300 Subject: naming packages installed to /usr/share/pear Message-ID: <4CA5ECC9.7070306@pld-linux.org> nowadays pear package has lost it's meaning of being code hosted at http://pear.php.net/ there seems to be coming larger amount of packages that are suggested to be installed using pear command http://www.phpunit.de/manual/current/en/installation.html http://www.ezcomponents.org/ http://pear.horde.org/ ... (see php-pear.spec for channel defs) the package naming rules should be unfied, because php-pear-PEAR_Command_Packaging not only creates new .spec files, but also creates depdendencies based on that info. currently pear make-rpm-spec decides (and seems work farily well): - if package cames from pear channel, name it php-pear-%{pkgname} - if cames elsewhere, name it as php-%{pkgname} - if it is source package, it will be named as php-pecl-%{pkgname} does anybody see problem with this pattern? should the pear-channel packages renamed also to php-%{pkgname} and what to do with ezcomponents.spec, drop it and build each package from separate spec? similar package is php-seclib.spec, which initially packages whole channel, should each of them be created own .spec? if ezcomponents.spec and php-seclib.spec aren't split to package specs, should it P: names if they would? -- glen From pawelz at pld-linux.org Tue Oct 12 13:16:37 2010 From: pawelz at pld-linux.org (=?iso-8859-2?Q?Pawe=B3?= Zuzelski) Date: Tue, 12 Oct 2010 13:16:37 +0200 Subject: roundcubemail-0.4.2 - th-main In-Reply-To: <4CB323B3.20609@farba.eu.org> References: <4CB2422E.7080508@farba.eu.org> <2195899e7700dc78e46786a8f05c7faf@zsp2.krotoszyn.net> <4CB25368.2050708@farba.eu.org> <4CB2C8ED.9060801@dc.net.pl> <4CB323B3.20609@farba.eu.org> Message-ID: <20101012111637.GB4701@pzz.touk.pl> On Mon, 11 Oct 2010, Wieslaw Kierbedz wrote: > W dniu 10/11/10 12:57 PM, Bartosz ?wi?tek anonsuje:: > > W dniu 11 pa?dziernika 2010 10:21 u?ytkownik Robert Grauzenis > > napisa?: > >> W dniu 2010-10-11 01:59, Wieslaw Kierbedz napisa?(a): > >>>> Mia?em przed chwil? to samo :( Zwalczy?em nadpisuj?c katalog "program" > >>>> wersj? z svn. > >>> He, he, a mia?o by? tylko stable. > >>> No to nie b?dzie. > >> Spaczkowana wersja tak ma, wersja uruchomiona bezpo?rednio ze ?r?de? > >> dzia?a prawid?owo (w sobot? aktualizowa?em na jednej z maszyn). > > Potwierdzam. > I ja. I ja. I ja. I ja. Onomatopeja. > Te? chc? potwierdzi?. This problem was caused by shared-folders.patch. I disabled it in 0.4.2-2, so now roundcube works correctly, at least for me. Please test: http://carme.pld-linux.org/~pawelz/th/noarch/ If noone will fixes this patch / updates config for it, I'll send roundcube without spoken patch to th builders today in the evening. -- Regards, Pawe? From pawelz at pld-linux.org Tue Oct 12 13:18:04 2010 From: pawelz at pld-linux.org (=?iso-8859-2?Q?Pawe=B3?= Zuzelski) Date: Tue, 12 Oct 2010 13:18:04 +0200 Subject: PLD-doc: cvs-hints.txt - How to add DEVEL branch. In-Reply-To: References: Message-ID: <20101012111804.GC4701@pzz.touk.pl> On Tue, 12 Oct 2010, lmasko wrote: > +* Add a DEVEL branch (assuming, that the DEVEL tag does not exist): > + > + builder -B DEVEL name.spec > + cvs up -r DEVEL name.spec > + cvs ci name.spec Just curious: why this is better than just: cd rpm/packages/name; cvs tag -b DEVEL ? -- Regards, Pawe? From hawk at pld-linux.org Tue Oct 12 13:26:50 2010 From: hawk at pld-linux.org (Marcin Krol) Date: Tue, 12 Oct 2010 13:26:50 +0200 Subject: PLD-doc: cvs-hints.txt - How to add DEVEL branch. In-Reply-To: <20101012111804.GC4701@pzz.touk.pl> References: <20101012111804.GC4701@pzz.touk.pl> Message-ID: <4CB445FA.60106@pld-linux.org> > On Tue, 12 Oct 2010, lmasko wrote: >> +* Add a DEVEL branch (assuming, that the DEVEL tag does not exist): >> + >> + builder -B DEVEL name.spec >> + cvs up -r DEVEL name.spec >> + cvs ci name.spec > > Just curious: why this is better than just: > cd rpm/packages/name; > cvs tag -b DEVEL > > ? Because it tags source files and patches as well. M. From pawelz at pld-linux.org Tue Oct 12 13:38:07 2010 From: pawelz at pld-linux.org (=?iso-8859-2?Q?Pawe=B3?= Zuzelski) Date: Tue, 12 Oct 2010 13:38:07 +0200 Subject: PLD-doc: cvs-hints.txt - How to add DEVEL branch. In-Reply-To: <4CB445FA.60106@pld-linux.org> References: <20101012111804.GC4701@pzz.touk.pl> <4CB445FA.60106@pld-linux.org> Message-ID: <20101012113807.GF4701@pzz.touk.pl> On Tue, 12 Oct 2010, Marcin Krol wrote: > > On Tue, 12 Oct 2010, lmasko wrote: > >> +* Add a DEVEL branch (assuming, that the DEVEL tag does not exist): > >> + > >> + builder -B DEVEL name.spec > >> + cvs up -r DEVEL name.spec > >> + cvs ci name.spec > > > > Just curious: why this is better than just: > > cd rpm/packages/name; > > cvs tag -b DEVEL > > > > ? > > Because it tags source files and patches as well. cvs tag -b DEVEL with cwd=packages/name will tag all tracked files in packages/name directory (?) -- Pawe? From hawk at pld-linux.org Tue Oct 12 13:50:04 2010 From: hawk at pld-linux.org (Marcin Krol) Date: Tue, 12 Oct 2010 13:50:04 +0200 Subject: PLD-doc: cvs-hints.txt - How to add DEVEL branch. In-Reply-To: <20101012113807.GF4701@pzz.touk.pl> References: <20101012111804.GC4701@pzz.touk.pl> <4CB445FA.60106@pld-linux.org> <20101012113807.GF4701@pzz.touk.pl> Message-ID: <4CB44B6C.9050507@pld-linux.org> > cvs tag -b DEVEL with cwd=packages/name will tag all tracked files > in packages/name directory (?) True. Builder will tag only those actually associated with spec file. M. From kamil.listy at klecza.pl Wed Oct 13 09:13:09 2010 From: kamil.listy at klecza.pl (Kamil Dziedzic) Date: Wed, 13 Oct 2010 09:13:09 +0200 Subject: Broken blueman after upgrade Message-ID: <201010130913.10057.kamil.listy@klecza.pl> Hi. After upgrade-dist blueman-applet doesn't want to start. It says something about missing icon. I use kde instead of gnome however bluetooth-applet works fine. Any ideas how to fix blueman? Log: # LC_ALL=c blueman-applet (process:15285): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. Loading configuration plugins _________ (/usr/share/python2.7/site-packages/blueman/main/Config.py:20) Skipping plugin Gconf No module named gconf Using file config backend Stale PID, overwriting Using file config backend _________ Load (/usr/bin/blueman-applet:117) ['Networking', 'AuthAgent', 'KillSwitch', 'TransferService', 'StandardItems', 'Indicator', 'NMPANSupport', 'PPPSupport', 'NetUsage', 'Headset', 'Menu', 'NMDUNSupport', 'SerialManager', 'PulseAudio', 'RecentConns', 'PowerManager', 'DhcpClient', 'DBusService', 'StatusIcon', 'DiscvManager'] _________ Load (/usr/bin/blueman-applet:117) Unable to load plugin module NMPANSupport No module named gconf _________ __load_plugin (/usr/bin/blueman-applet:182) loading _________ __load_plugin (/usr/bin/blueman-applet:182) loading _________ __load_plugin (/usr/bin/blueman-applet:182) loading Using file config backend _________ __load_plugin (/usr/bin/blueman-applet:182) loading _________ __load_plugin (/usr/bin/blueman-applet:182) loading Traceback (most recent call last): File "/usr/share/python2.7/site-packages/blueman/plugins/AppletPlugin.py", line 105, in _load self.on_load(applet) File "/usr/share/python2.7/site- packages/blueman/plugins/applet/PowerManager.py", line 37, in on_load self.item = create_menuitem(_("Bluetooth Off"), get_icon("gtk- stop", 16)) File "/usr/share/python2.7/site-packages/blueman/Functions.py", line 171, in get_icon icon = ic.load_icon("gtk-missing-image", size, 0) GError: Icon 'gtk-missing-image' not present in theme _________ __load_plugin (/usr/bin/blueman-applet:182) Failed to load PowerManager Icon 'gtk-missing-image' not present in theme -- Regards, Kamil Dziedzic From caleb at pld-linux.org Wed Oct 13 14:26:43 2010 From: caleb at pld-linux.org (Caleb Maclennan) Date: Wed, 13 Oct 2010 15:26:43 +0300 Subject: packages: VirtualBox-bin/VirtualBox-bin.spec - Up to 3.2.10 In-Reply-To: References: Message-ID: On Wed, Oct 13, 2010 at 13:50, caleb wrote: > - Up to 3.2.10 Sorry guys neglected to mark this commit NFY without a release number. There are some path changes and such that need to be fixed in this upgrade, and I had only just started. The commit was just to switch to a different devel box. From przemo at firszt.eu Fri Oct 15 21:24:12 2010 From: przemo at firszt.eu (Przemo Firszt) Date: Fri, 15 Oct 2010 20:24:12 +0100 Subject: Broken blueman after upgrade In-Reply-To: <201010130913.10057.kamil.listy@klecza.pl> References: <201010130913.10057.kamil.listy@klecza.pl> Message-ID: <1287170652.6729.32.camel@pldmachine> Dnia 2010-10-13, ?ro o godzinie 09:13 +0200, Kamil Dziedzic pisze: > Hi. > > After upgrade-dist blueman-applet doesn't want to start. It says something > about missing icon. I use kde instead of gnome however bluetooth-applet works > fine. Any ideas how to fix blueman? > > Log: > # LC_ALL=c blueman-applet > > (process:15285): Gtk-WARNING **: Locale not supported by C library. > Using the fallback 'C' locale. > Loading configuration plugins > _________ > (/usr/share/python2.7/site-packages/blueman/main/Config.py:20) > Skipping plugin Gconf > No module named gconf > Using file config backend > Stale PID, overwriting > Using file config backend > _________ > Load (/usr/bin/blueman-applet:117) > ['Networking', 'AuthAgent', 'KillSwitch', 'TransferService', 'StandardItems', > 'Indicator', 'NMPANSupport', 'PPPSupport', 'NetUsage', 'Headset', 'Menu', > 'NMDUNSupport', 'SerialManager', 'PulseAudio', 'RecentConns', 'PowerManager', > 'DhcpClient', 'DBusService', 'StatusIcon', 'DiscvManager'] > _________ > Load (/usr/bin/blueman-applet:117) > Unable to load plugin module NMPANSupport > No module named gconf > _________ > __load_plugin (/usr/bin/blueman-applet:182) > loading > _________ > __load_plugin (/usr/bin/blueman-applet:182) > loading > _________ > __load_plugin (/usr/bin/blueman-applet:182) > loading > Using file config backend > _________ > __load_plugin (/usr/bin/blueman-applet:182) > loading > _________ > __load_plugin (/usr/bin/blueman-applet:182) > loading > Traceback (most recent call last): > File "/usr/share/python2.7/site-packages/blueman/plugins/AppletPlugin.py", > line 105, in _load > self.on_load(applet) > File "/usr/share/python2.7/site- > packages/blueman/plugins/applet/PowerManager.py", line 37, in on_load > self.item = create_menuitem(_("Bluetooth Off"), get_icon("gtk- > stop", 16)) > File "/usr/share/python2.7/site-packages/blueman/Functions.py", line 171, in > get_icon > icon = ic.load_icon("gtk-missing-image", size, 0) > GError: Icon 'gtk-missing-image' not present in theme > _________ > __load_plugin (/usr/bin/blueman-applet:182) > Failed to load PowerManager > Icon 'gtk-missing-image' not present in theme > Do you have gnome-icon-theme installed? I use gnome, so I can't test it. -- Przemo Firszt From kamil.listy at klecza.pl Fri Oct 15 22:31:43 2010 From: kamil.listy at klecza.pl (Kamil Dziedzic) Date: Fri, 15 Oct 2010 22:31:43 +0200 Subject: Broken blueman after upgrade In-Reply-To: <201010130913.10057.kamil.listy@klecza.pl> References: <201010130913.10057.kamil.listy@klecza.pl> Message-ID: <201010152231.49981.kamil.listy@klecza.pl> Same thing for nm-applet #LC_ALL=c nm-applet (process:5240): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. ** (nm-applet:5240): WARNING **: get_all_cb: couldn't retrieve system settings properties: (2) The name org.freedesktop.NetworkManagerSystemSettings was not provided by any .service files. ** (nm-applet:5240): WARNING **: fetch_connections_done: error fetching system connections: (2) The name org.freedesktop.NetworkManagerSystemSettings was not provided by any .service files. ** (nm-applet:5240): WARNING **: Fallback icon 'gtk-dialog-error' missing: (0) Icon 'gtk-dialog-error' not present in theme ** ERROR:applet.c:2769:nma_icons_reload: assertion failed: (applet- >fallback_icon) Przerwane -- Regards, Kamil Dziedzic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From przemo at firszt.eu Sun Oct 17 22:24:04 2010 From: przemo at firszt.eu (Przemo Firszt) Date: Sun, 17 Oct 2010 21:24:04 +0100 Subject: Broken blueman after upgrade In-Reply-To: <201010152231.49981.kamil.listy@klecza.pl> References: <201010130913.10057.kamil.listy@klecza.pl> <201010152231.49981.kamil.listy@klecza.pl> Message-ID: <1287347044.15075.1.camel@pldmachine> Dnia 2010-10-15, pi? o godzinie 22:31 +0200, Kamil Dziedzic pisze: > Same thing for nm-applet > > #LC_ALL=c nm-applet > > (process:5240): Gtk-WARNING **: Locale not supported by C library. > Using the fallback 'C' locale. > > ** (nm-applet:5240): WARNING **: get_all_cb: couldn't retrieve system settings > properties: (2) The name org.freedesktop.NetworkManagerSystemSettings was not > provided by any .service files. > > ** (nm-applet:5240): WARNING **: fetch_connections_done: error fetching system > connections: (2) The name org.freedesktop.NetworkManagerSystemSettings was not > provided by any .service files. > > ** (nm-applet:5240): WARNING **: Fallback icon 'gtk-dialog-error' missing: (0) > Icon 'gtk-dialog-error' not present in theme > ** > ERROR:applet.c:2769:nma_icons_reload: assertion failed: (applet- > >fallback_icon) > Przerwane [..] Try to install gnome-icon-theme. It might fix both problems, but I cannot test it as a gnome user. -- Przemo Firszt From lm at zork.pl Mon Oct 18 10:59:52 2010 From: lm at zork.pl (Lukasz Michalski) Date: Mon, 18 Oct 2010 10:59:52 +0200 Subject: need xmlrpc-c up to 1.24.1 Message-ID: <4CBC0C88.8010408@zork.pl> Hello, I need recent version of xmlrpc-c. 1.20.3 from distro has fatal bug related to keepalive timeout. I cannot reference bug tracker entry due to strange policy of xmlrpc-c maintainer (send all bugs to me, I don't need a bug tracker :-) ) Anyway, I removed two obsolete patches from xmlrpc-c and switched from CMake to autotools (CMake build had problems and this was suggested to me by maintaier). The only problem with 1.24.1 is that I cannot find a way to generate *.pc files so I cannot pack them. My questions are: - can we switch to official 'advanced' branch (http://xmlrpc-c.svn.sourceforge.net/viewvc/xmlrpc-c/advanced/)? - do we need those *.pc files? I really don't know this pkgconfig stuff and I don't see any way to generate them. - how to properly get sources for this package? Currently I use svn checkout from branch and revision and use builder -nn Patch (with *.pc files problem left to solve) attached, Thanks, ?ukasz -------------- next part -------------- Index: xmlrpc-c.spec =================================================================== RCS file: /cvsroot/packages/xmlrpc-c/xmlrpc-c.spec,v retrieving revision 1.39 diff -u -r1.39 xmlrpc-c.spec --- xmlrpc-c.spec 3 Feb 2010 00:45:45 -0000 1.39 +++ xmlrpc-c.spec 18 Oct 2010 08:36:49 -0000 @@ -8,24 +8,22 @@ Summary: XML-RPC C library - an implementation of the xmlrpc protocol Summary(pl.UTF-8): Biblioteka XML-RPC C - implementacja protoko?u xmlrpc Name: xmlrpc-c -Version: 1.20.3 -Release: 6 +Version: 1.24.1 +Release: 1 License: XML-RPC for C License (BSD-like) Group: Libraries # generated by 'make svn-sources [SVN_VER=%version SVN_REV=%svnrev]'. Unfortunately, # upstream does not tag versions so we must fetch from the branch and # check which version was used for it -Source0: %{name}-%{version}.tar.bz2 +Source0: %{name}-%{version}.tar.gz # Source0-md5: d987c3d989ca1a4774ce12fada437238 Patch0: %{name}-fastdep.patch Patch1: %{name}-soname.patch Patch2: %{name}-cflags.patch Patch3: %{name}-cmake.patch Patch4: %{name}-longlong.patch -Patch5: %{name}-printf-size_t.patch -Patch6: %{name}-uninit-curl.patch -Patch7: %{name}-va_list.patch -Patch8: %{name}-verbose-curl.patch +Patch5: %{name}-uninit-curl.patch +Patch6: %{name}-verbose-curl.patch URL: http://xmlrpc-c.sourceforge.net/ BuildRequires: cmake BuildRequires: curl-devel @@ -139,30 +137,27 @@ %patch4 -p1 %patch5 -p1 %patch6 -p1 -%patch7 -p1 -%patch8 -p1 %patch1 -p1 ## not needed... rm doc/{INSTALL,configure_doc} %build -mkdir -p build -cd build -%cmake .. \ - -D_lib:STRING=%{_lib} \ - -DMUST_BUILD_CURL_CLIENT:BOOL=ON \ - -DMUST_BUILD_LIBWWW_CLIENT:BOOL=ON \ - -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} \ - -DBUILD_SHARED_LIBS:BOOL=ON \ - -DENABLE_TOOLS:BOOL=ON +%{__libtoolize} +%{__aclocal} +%{__autoconf} +%{__autoheader} +%configure \ + --enable-tools \ + --enable-libxml2-backend + -%{__make} VERBOSE=1 +%{__make} %install rm -rf $RPM_BUILD_ROOT -%{__make} -C build install \ +%{__make} install \ DESTDIR=$RPM_BUILD_ROOT \ chmod +x $RPM_BUILD_ROOT%{_libdir}/*.so @@ -211,24 +206,24 @@ %files c++ %defattr(644,root,root,755) %attr(755,root,root) %{_libdir}/libxmlrpc++.so.*.* -%attr(755,root,root) %ghost %{_libdir}/libxmlrpc++.so.6 +%attr(755,root,root) %ghost %{_libdir}/libxmlrpc++.so.7 %attr(755,root,root) %{_libdir}/libxmlrpc_cpp.so.*.* -%attr(755,root,root) %ghost %{_libdir}/libxmlrpc_cpp.so.6 +%attr(755,root,root) %ghost %{_libdir}/libxmlrpc_cpp.so.7 %attr(755,root,root) %{_libdir}/libxmlrpc_packetsocket.so.*.* -%attr(755,root,root) %ghost %{_libdir}/libxmlrpc_packetsocket.so.6 +%attr(755,root,root) %ghost %{_libdir}/libxmlrpc_packetsocket.so.7 %attr(755,root,root) %{_libdir}/libxmlrpc_server++.so.*.* -%attr(755,root,root) %ghost %{_libdir}/libxmlrpc_server++.so.6 +%attr(755,root,root) %ghost %{_libdir}/libxmlrpc_server++.so.7 %attr(755,root,root) %{_libdir}/libxmlrpc_server_abyss++.so.*.* -%attr(755,root,root) %ghost %{_libdir}/libxmlrpc_server_abyss++.so.6 -%attr(755,root,root) %{_libdir}/libxmlrpc_server_cgi++.so.6.20 -%attr(755,root,root) %ghost %{_libdir}/libxmlrpc_server_cgi++.so.6 +%attr(755,root,root) %ghost %{_libdir}/libxmlrpc_server_abyss++.so.7 +%attr(755,root,root) %{_libdir}/libxmlrpc_server_cgi++.so.7.24 +%attr(755,root,root) %ghost %{_libdir}/libxmlrpc_server_cgi++.so.7 %attr(755,root,root) %{_libdir}/libxmlrpc_server_pstream++.so.*.* -%attr(755,root,root) %ghost %{_libdir}/libxmlrpc_server_pstream++.so.6 +%attr(755,root,root) %ghost %{_libdir}/libxmlrpc_server_pstream++.so.7 %files client++ %defattr(644,root,root,755) %attr(755,root,root) %{_libdir}/libxmlrpc_client++.so.*.* -%attr(755,root,root) %ghost %{_libdir}/libxmlrpc_client++.so.6 +%attr(755,root,root) %ghost %{_libdir}/libxmlrpc_client++.so.7 %files apps %defattr(644,root,root,755) @@ -253,15 +248,15 @@ %attr(755,root,root) %{_libdir}/libxmlrpc_server_abyss.so %attr(755,root,root) %{_libdir}/libxmlrpc_server_cgi.so %attr(755,root,root) %{_libdir}/libxmlrpc_util.so -%{_pkgconfigdir}/xmlrpc.pc -%{_pkgconfigdir}/xmlrpc_abyss.pc -%{_pkgconfigdir}/xmlrpc_client.pc -%{_pkgconfigdir}/xmlrpc_cpp.pc -%{_pkgconfigdir}/xmlrpc_packetsocket.pc -%{_pkgconfigdir}/xmlrpc_server.pc -%{_pkgconfigdir}/xmlrpc_server_abyss.pc -%{_pkgconfigdir}/xmlrpc_server_cgi.pc -%{_pkgconfigdir}/xmlrpc_util.pc +#%{_pkgconfigdir}/xmlrpc.pc +#%{_pkgconfigdir}/xmlrpc_abyss.pc +#%{_pkgconfigdir}/xmlrpc_client.pc +#%{_pkgconfigdir}/xmlrpc_cpp.pc +#%{_pkgconfigdir}/xmlrpc_packetsocket.pc +#%{_pkgconfigdir}/xmlrpc_server.pc +#%{_pkgconfigdir}/xmlrpc_server_abyss.pc +#%{_pkgconfigdir}/xmlrpc_server_cgi.pc +#%{_pkgconfigdir}/xmlrpc_util.pc %dir %{_includedir}/xmlrpc-c %{_includedir}/xmlrpc-c/*.h # legacy @@ -275,12 +270,12 @@ %attr(755,root,root) %{_libdir}/libxmlrpc_server_pstream++.so %attr(755,root,root) %{_libdir}/libxmlrpc_server++.so %attr(755,root,root) %{_libdir}/libxmlrpc++.so -%{_pkgconfigdir}/xmlrpc_client++.pc -%{_pkgconfigdir}/xmlrpc++.pc -%{_pkgconfigdir}/xmlrpc_server_abyss++.pc -%{_pkgconfigdir}/xmlrpc_server_cgi++.pc -%{_pkgconfigdir}/xmlrpc_server++.pc -%{_pkgconfigdir}/xmlrpc_server_pstream++.pc +#%{_pkgconfigdir}/xmlrpc_client++.pc +#%{_pkgconfigdir}/xmlrpc++.pc +#%{_pkgconfigdir}/xmlrpc_server_abyss++.pc +#%{_pkgconfigdir}/xmlrpc_server_cgi++.pc +#%{_pkgconfigdir}/xmlrpc_server++.pc +#%{_pkgconfigdir}/xmlrpc_server_pstream++.pc %{_includedir}/xmlrpc-c/*.hpp # legacy %{_includedir}/XmlRpcCpp.h -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From arekm at maven.pl Tue Oct 19 14:03:35 2010 From: arekm at maven.pl (Arkadiusz Miskiewicz) Date: Tue, 19 Oct 2010 14:03:35 +0200 Subject: naming packages installed to /usr/share/pear In-Reply-To: <4CA5ECC9.7070306@pld-linux.org> References: <4CA5ECC9.7070306@pld-linux.org> Message-ID: <201010191403.35526.arekm@maven.pl> On Friday 01 of October 2010, Elan Ruusam?e wrote: > currently pear make-rpm-spec decides (and seems work farily well): > - if package cames from pear channel, name it php-pear-%{pkgname} > - if cames elsewhere, name it as php-%{pkgname} > - if it is source package, it will be named as php-pecl-%{pkgname} > > does anybody see problem with this pattern? Looks fine to me. > should the pear-channel packages renamed also to php-%{pkgname} IMO php-pear is better (so at least I know that it is from pear.php.net). > and what to do with ezcomponents.spec, > drop it and build each package from separate spec? No idea. Choose some way. > similar package is php-seclib.spec, which initially packages whole > channel, should each of them be created own .spec? > > if ezcomponents.spec and php-seclib.spec aren't split to package specs, > should it P: names if they would? -- Arkadiusz Mi?kiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/ From kamil.listy at klecza.pl Wed Oct 20 10:20:25 2010 From: kamil.listy at klecza.pl (Kamil Dziedzic) Date: Wed, 20 Oct 2010 10:20:25 +0200 Subject: Broken blueman after upgrade In-Reply-To: <201010152231.49981.kamil.listy@klecza.pl> References: <201010130913.10057.kamil.listy@klecza.pl> <201010152231.49981.kamil.listy@klecza.pl> Message-ID: <201010201020.34493.kamil.listy@klecza.pl> Przemo Firszt: > Try to install gnome-icon-theme. It might fix both problems, but I > cannot test it as a gnome user. > My emails are not reaching pld-devel-en for unknown reason - that's why > a private email. I already did that - nothing changed. # rpm -qa | grep theme | sort gnome-icon-theme-2.30.3-2.noarch gnome-themes-2.32.0-1.x86_64 gnome-themes-extras-2.22.0-1.x86_64 gnome-themes-extras-Neu-2.22.0-1.x86_64 gnome-themes-HighContrast-SVG-2.32.0-1.x86_64 hicolor-icon-theme-0.12-2.noarch kadu-theme-icons-glass16-0.6.5.4-5.x86_64 kadu-theme-icons-glass22-0.6.5.4-5.x86_64 kadu-theme-icons-kadu05-0.6.5.4-5.x86_64 kadu-theme-icons-oxygen16-0.6.5.4-5.x86_64 kadu-theme-icons-tango16-0.6.5.4-5.x86_64 kde4-decoration-aurorae-themes-4.5.2-1.x86_64 sound-theme-freedesktop-0.3-1.noarch splashutils-theme-black-1-3.noarch tango-icon-theme-0.8.1-1.noarch -- Regards, Kamil Dziedzic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From pawelz at pld-linux.org Wed Oct 20 18:54:33 2010 From: pawelz at pld-linux.org (=?iso-8859-2?Q?Pawe=B3?= Zuzelski) Date: Wed, 20 Oct 2010 18:54:33 +0200 Subject: server side mv request =?utf-8?Q?=28coovac?= =?utf-8?B?aGlsbGkg4oaS?= coova-chilli) Message-ID: <20101020165433.GA4839@davabel.touk.pl> Please, rename coovachilli to coova-chilli. Also please rename .spec and patches. There is a little confusion about official project name. Sometimes they write it CoovaChilli, sometimes coova-chilli, sometimes just Coova, and a binary is named ?chilli?. Anyway, tarball is named coova-chilli-%{version}.tar.gz and other distros (medianix, OpenWRT) use ?coova-chilli? name. I think we should follow them. -- Pawe? From glen at pld-linux.org Wed Oct 20 19:19:56 2010 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Wed, 20 Oct 2010 20:19:56 +0300 Subject: server side mv request (coovachilli =?UTF-8?B?4oaSIGNvb3ZhLWM=?= =?UTF-8?B?aGlsbGkp?= In-Reply-To: <20101020165433.GA4839@davabel.touk.pl> References: <20101020165433.GA4839@davabel.touk.pl> Message-ID: <4CBF24BC.4080303@pld-linux.org> On 20.10.2010 19:54, Pawe? Zuzelski wrote: > Please, rename coovachilli to coova-chilli. Also please rename .spec > and patches. > > There is a little confusion about official project name. Sometimes > they write it CoovaChilli, sometimes coova-chilli, sometimes just > Coova, and a binary is named ?chilli?. > > Anyway, tarball is named coova-chilli-%{version}.tar.gz and other > distros (medianix, OpenWRT) use ?coova-chilli? name. I think we > should follow them. > done. also removed packages/coovachilli.spec in process (added to packages root by paszczus) -- glen From kamil.listy at klecza.pl Thu Oct 21 00:32:45 2010 From: kamil.listy at klecza.pl (Kamil Dziedzic) Date: Thu, 21 Oct 2010 00:32:45 +0200 Subject: Broken blueman after upgrade In-Reply-To: <201010130913.10057.kamil.listy@klecza.pl> References: <201010130913.10057.kamil.listy@klecza.pl> Message-ID: <201010210032.45523.kamil.listy@klecza.pl> Also back and forward icons are missing in iceweasel. But I founded solution: https://bugs.archlinux.org/task/21084 http://bugs.gentoo.org/219278 https://bugzilla.gnome.org/show_bug.cgi?id=629878 First I tried to patch gtk+: https://bugs.archlinux.org/task/21084?getfile=5843 ... but this doesn't helped me. Then I used this (gnome-icon-theme required): # echo -e "gtk-icon-theme-name=\"gnome\"" >>~/.gtkrc-2.0 And now everything is back to normal... except now in iceweasel I got those ugly gnome icons:) -- Regards, Kamil Dziedzic From udvzsolt at gmail.com Thu Oct 21 10:22:57 2010 From: udvzsolt at gmail.com (Zsolt Udvari) Date: Thu, 21 Oct 2010 10:22:57 +0200 Subject: Poldek memory fault Message-ID: Hi all! Do only I have poldek segfault, everybody nothing? https://bugs.launchpad.net/pld-linux/+bug/658291 Zsolt From pawelz at pld-linux.org Tue Oct 26 17:19:10 2010 From: pawelz at pld-linux.org (=?iso-8859-2?Q?Pawe=B3?= Zuzelski) Date: Tue, 26 Oct 2010 17:19:10 +0200 Subject: packages: kernel/kernel.spec - added (commented by default) the kernel-usb_... In-Reply-To: References: Message-ID: <20101026151910.GD4912@davabel.touk.pl> On Tue, 26 Oct 2010, witekfl wrote: > Author: witekfl Date: Tue Oct 26 14:44:19 2010 GMT > Module: packages Tag: HEAD > ---- Log message: > - added (commented by default) the kernel-usb_reset.patch (for T41) > - do not remove it. It is easier to uncomment two lines, then patch > kernel.spec every time. Add a bcond. It will be clear that this patch is needed. -- Regards, Pawe? From pawelz at pld-linux.org Sun Oct 31 02:08:45 2010 From: pawelz at pld-linux.org (=?iso-8859-2?Q?Pawe=B3?= Zuzelski) Date: Sun, 31 Oct 2010 02:08:45 +0200 Subject: packages: dovecot/dovecot.spec - TODO was accidentally removed (sorry), but... In-Reply-To: References: Message-ID: <20101031000845.GA8637@davabel> On Thu, 28 Oct 2010, caleb wrote: > Author: caleb Date: Thu Oct 28 09:53:02 2010 GMT > Module: packages Tag: HEAD > ---- Log message: > - TODO was accidentally removed (sorry), but having [percent]service in the spec even on a commented line breaks the build. Bug in builder? No, it is not a bug. '#' is not a comment in spec files. To be precise, it does not prevent rpmbuild from expanding %macros. The problem is that %service macro is multiline macro, so # - use %service macros expands to # - use { skip_auto_restart() { [ -f /etc/sysconfig/rpm ] && . /etc/sysconfig/rpm [ -f /etc/sysconfig/ ] && . /etc/sysconfig/ echo ${RPM_SKIP_AUTO_RESTART:-no} }; if [ $(skip_auto_restart) = no ]; then if [ -f /var/lock/subsys/ ]; then /sbin/service 1>&2 || :; else echo 'Run "/sbin/service start" to start service.' fi fi }; macros ^^^ obviously it is incorrect If you want to prevent builder from expanding macro, use double percent: # - use %%service macros it expands to # - use %service macros In fact the only correct way to comment something out on spec level is: %if 0 ... %endif -- Regards, Pawe? From n3npq at mac.com Sun Oct 31 02:00:09 2010 From: n3npq at mac.com (Jeff Johnson) Date: Sat, 30 Oct 2010 21:00:09 -0400 Subject: packages: dovecot/dovecot.spec - TODO was accidentally removed (sorry), but... In-Reply-To: <20101031000845.GA8637@davabel> References: <20101031000845.GA8637@davabel> Message-ID: <95AD070D-698D-48F0-A68F-F73ACED66E0E@mac.com> On Oct 30, 2010, at 8:08 PM, Pawe? Zuzelski wrote: > On Thu, 28 Oct 2010, caleb wrote: > >> Author: caleb Date: Thu Oct 28 09:53:02 2010 GMT >> Module: packages Tag: HEAD >> ---- Log message: >> - TODO was accidentally removed (sorry), but having [percent]service in the spec even on a commented line breaks the build. Bug in builder? > > No, it is not a bug. > > '#' is not a comment in spec files. To be precise, it does not > prevent rpmbuild from expanding %macros. The problem is that > %service macro is multiline macro, so > Yup: macros are context free, expanded everywhere they are encountered, within quuoted strings, in comments, everywhere (aside) They used to be expanded in the false branch of %if but that was a bit painful .. MEANWHILE ... ... there's actually a feature hidden ther too. Let's say you have two sets of macros you need to define, like Fedora <-> Mandriva have decided to rearrange all the paths in a package for some reason (I use "vendor" only for clarity, there's lots of times that you want two rather different sets of values defined in packaging). If you capture, say, the Fedora != Mandriva differing in what to call "mysql" %fedora \\\ Requires: MySqL \\\ # %mandriva \\\ Requires: mYsQl \\\ # Then in the spec file you would put # %{?fedora} %{?mandriva} Which (assuming no typoes from me) one ends up with multiline expansions that "drops down" one or the other (or both if both %fedora/%mandriva are defined) exposing the Requires: (or whatever text one wanted) into the spec file. I've always wanted to see cleaner packaging using the fact that macros _ARE_ expanded in comments, rather than the unexpected behavior bug report. hth 73 de Jeff From qboosh at pld-linux.org Sun Oct 31 21:42:29 2010 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sun, 31 Oct 2010 21:42:29 +0100 Subject: packages: tar/tar.spec - 1.24 broken, rel down (tar -C seems have problems, ... In-Reply-To: References: Message-ID: <20101031204228.GI24059@stranger.qboosh.pl> On Fri, Oct 29, 2010 at 08:57:32AM +0200, glen wrote: > Author: glen Date: Fri Oct 29 06:57:32 2010 GMT > Module: packages Tag: HEAD > ---- Log message: > - 1.24 broken, rel down (tar -C seems have problems, see icedove builds) What is the problem? I haven't tried icedove; but xulrunner builds fine using tar 1.24. -- Jakub Bogusz http://qboosh.pl/ From glen at delfi.ee Sun Oct 31 23:46:02 2010 From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Mon, 01 Nov 2010 00:46:02 +0200 Subject: packages: tar/tar.spec - 1.24 broken, rel down (tar -C seems have problems, ... In-Reply-To: <20101031204228.GI24059@stranger.qboosh.pl> References: <20101031204228.GI24059@stranger.qboosh.pl> Message-ID: <4CCDF1AA.2030904@delfi.ee> On 31/10/10 22:42, Jakub Bogusz wrote: > On Fri, Oct 29, 2010 at 08:57:32AM +0200, glen wrote: >> Author: glen Date: Fri Oct 29 06:57:32 2010 GMT >> Module: packages Tag: HEAD >> ---- Log message: >> - 1.24 broken, rel down (tar -C seems have problems, see icedove builds) > > What is the problem? > > I haven't tried icedove; but xulrunner builds fine using tar 1.24. see yourself? it fails to unpack the enigmail tarball http://ep09.pld-linux.org/~builderth/queue.html#66056 http://buildlogs.pld-linux.org/index.php?dist=th&arch=x86_64&ok=0&ns=&cnt=50&off=0&name=icedove&id=508234bb-4fa4-45f7-bdda-cac1a26279ad ... + cd mozilla + /bin/gzip -dc /home/users/builder/rpm/SOURCES/enigmail-1.1.2.tar.gz + /bin/tar -xf - -C mailnews/extensions /bin/tar: enigmail/build: Cannot utime: No such file or directory /bin/tar: enigmail/CVS: Cannot utime: No such file or directory /bin/tar: enigmail/ipc: Cannot utime: No such file or directory ... -- glen