openSUSE Packaging November 2010

packaging@lists.opensuse.org

52 participants
49 discussions

[opensuse-packaging] Proposal for a multimedia team.

by Dave Plater

Hi, we need a multimedia team, I know from watching submit requests that there are at least three other potential members besides me. A little bit more communication between us would be beneficial to the mmaps and mmlibs projects especially multimedia:libs which contains packages that can wreak havoc if broken. ATM when I need help I use the packaging list but sometimes the help is blind to the needs of multimedia ie. jack, it would be nice to be able to discuss these things with more experienced multimedia oriented people. I've cc'ed this to opensuse-multimedia list but I wonder how many people actually subscribe to it? Regards Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 4 months

[opensuse-packaging] perl - perl_process_packlist - assistance needed

by Christian

Hi, the macro %perl_process_packlist was updated for Factory (11.4). Now it does remove .packlist, perllocal.pod file. Hence a lot of packages in devel:languages:perl are now failing for Factory cause of |File not found: ...../.packlist ||File not found: ...../var/adm/perl-modules/%{name}| There are several possibilities to get this fixed. 1) for "noarch" packages replace %perl_process_packlist with ### since 11.4 perl_process_packlist ### removes .packlist, perllocal.pod files %if 0%{?suse_version} > 1130 %perl_process_packlist %else # do not perl_process_packlist # remove .packlist file %{__rm} -rf $RPM_BUILD_ROOT%perl_vendorarch # remove perllocal.pod file %{__rm} -f $RPM_BUILD_ROOT%perl_archlib/perllocal.pod %endif and remove /var/adm/perl-modules... from filelist 2) if it is not "noarch" replace %perl_process_packlist with ### since 11.4 perl_process_packlist ### removes .packlist, perllocal.pod files %if 0%{?suse_version} > 1130 %perl_process_packlist %else # do not perl_process_packlist # remove .packlist file find $RPM_BUILD_ROOT%perl_vendorarch/auto -name .packlist -print0 | xargs -0 -r rm ; # remove perllocal.pod file %{__rm} -f $RPM_BUILD_ROOT%perl_archlib/perllocal.pod %endif and remove /var/adm/perl-modules... from filelist 3) make use of 'cpanspec' from d:l:p and rework the spec. I would prefer this way :) and I recommend it for new perl pkgs I appreciate any help about this. THX ||||-- Christian --------------------------------------------------- Der ultimative shop für Sportbekleidung und Zubehör http://www.sc24.de --------------------------------------------------- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 4 months

[opensuse-packaging] OBS cleanup -> removal of outdated repositories

by Adrian Schröter

Hi, Please excuse the cross post. You may have noticed that we have higher and higher build load on build.o.o. While the new dispatcher algorithms are still good to prefer the "right" jobs, it is still a sign that we may should cleanup. My current plan is to remove all repositories in home projects, which have not been touched this year. Not touched means, no source submission and no meta data has been altered at all. Additionally also all non-home projects, which have not been touch in last two years. This will affect 5668 out of 15668 projects. Why remove repos and not just disable the build ? This will free disk space on our servers and also on all mirrors. As result we can be mirrored more easily. Will any source get lost ? No. How to enable it again ? Just add the wanted repos again. Which projects will get affected exactly ? Find a full list here: http://www.suse.de/~adrian/OBS-remove-list-candidates There is a project which has not been touched, but the repos are still anyway important ! Just drop me a mail .... Why not drop the entire project now that we have an undelete function ? I thought about that, but currently the webui just says that the project does not exist. It does not offer to undelete it, so that might be too agressive for now. Why not drop people a mail and ask them to remove it ? Way to many accounts have no valid email adress and past experience showed that people are often not react when they lost interesst in their project. May plan is to do the removal end of this week, except more discussion about this is needed. Just tell me your opinion, also when you support this ;) thanks adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian(a)suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 4 months

[opensuse-packaging] $RPM_BUILD_ROOT empty, %{buildroot} not expanded?

by Stefan Seyfried

Hi, I have a strange problem in project home:seife:openstack, packgage rubygem-ohai It looks like $RPM_BUILD_ROOT is empty and %{buildroot} does not get expanded but is '%{buildroot}'. But only in the SLES11_SP1 repository. I added this to the specfile: %prep %setup -q -c -T echo $RPM_BUILD_ROOT echo %{buildroot} false and got: + echo + echo '%{buildroot}' %{buildroot} + false Can anybody explain this? This looks seriously broken to me, but I don't think I did anything wrong. -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 4 months

[opensuse-packaging] Patent issue

by Johannes Weberhofer

Hello! I'm currently packaging the tine20 Groupware and CRM system http://www.tine20.org/ . They offer a nice ActiveSync module for which they say on http://www.tine20.org/wiki/index.php/Admins/Synchronisation : ---- Patent warning for US-based users Don't use our implementation of ActiveSync if you live in the USA. As Microsoft has a software patent on ActiveSync you can not use our code free of charge. We are currently in contact with Microsoft to negotiate a deal for our US-based users. Any other users are free to use our ActiveSync implementation. ---- Is it allowed to provide such a package for OpenSUSE users via the build-service, or must the package be compiled and distributed elsewhere!? Best regards, Johannes -- Johannes Weberhofer Weberhofer GmbH, Austria, Vienna -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 4 months

[opensuse-packaging] Is it ok to use /opt?

by Dave Plater

Hi, I'm putting together a libraw1394-8 package to satisfy old packages (which should be fixed) is it ok to use --prefix=/opt for it? I've redefined a couple of macros for this. home:plater libraw1394-8 Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 4 months

[opensuse-packaging] vim 7.3

by Sebastian Siebert

Hi, I create a branch from the obs://editors/vim in my home repository obs://home:Freespacer:branches:editors/vim I want to update the version of vim 7.2 to 7.3. Some patches are obsolete and some others was renewed by me. Now I get follow error message in the build log: I: Statement is overflowing a buffer E: vim bufferoverflow eval.c:21842:2 E: vim bufferoverflow eval.c:21863:5 I look for the lines from the compiler message and get these lines: ... gcc -c -I. -Iproto -DHAVE_CONFIG_H -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -Wall -pipe -fno-strict-aliasing -fstack-protector-all -o objects/ex_getln.o ex_getln.c In file included from /usr/include/string.h:640:0, from os_unix.h:519, from vim.h:265, from eval.c:17: In function 'strcpy', inlined from 'call_user_func' at eval.c:21842:2: /usr/include/bits/string3.h:107:3: warning: call to __builtin___strcpy_chk will always overflow destination buffer In function 'strcpy', inlined from 'call_user_func' at eval.c:21863:5: /usr/include/bits/string3.h:107:3: warning: call to __builtin___strcpy_chk will always overflow destination buffer ... ... gcc -c -I. -Iproto -DHAVE_CONFIG_H -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -Wall -pipe -fno-strict-aliasing -fstack-protector-all -I/usr/include -D_LARGEFILE64_SOURCE=1 -o objects/fileio.o fileio.c In file included from /usr/include/string.h:640:0, from os_unix.h:519, from vim.h:265, from eval.c:17: In function 'strcpy', inlined from 'call_user_func' at eval.c:21842:2: /usr/include/bits/string3.h:107:3: warning: call to __builtin___strcpy_chk will always overflow destination buffer In function 'strcpy', inlined from 'call_user_func' at eval.c:21863:5: /usr/include/bits/string3.h:107:3: warning: call to __builtin___strcpy_chk will always overflow destination buffer ... How can I solve this issue? Later I want to submit the package to the obs://editors/vim (obs://openSUSE:Factory/vim) Thank you, -- Kind regards, Sebastian - openSUSE Member (Freespacer) Website/Blog: <http://www.sebastian-siebert.de> Important notes on openSUSE Mailing List: <http://en.opensuse.org/OpenSUSE_mailing_list_netiquette> -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 4 months

[opensuse-packaging] Is there a directory for dbus services?

by Dave Plater

Hi, is there a specific dbus service directory? Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 5 months

[opensuse-packaging] Libraw1394-8 and the state of linux h323 and other telephony [RFC]

by Dave Plater

Hi, I innocently updated a very old libraw1394 a month and a half ago, realizing that a lot depended on it I was careful to try not to break the system but it seems it was like cleaning a mark on the wall to find out that the wall was rotten under the paint layer. I'm assuming that VoIP telephony isn't messed with because it just works but all of the associated software, with the exception of h323plus and GNOME:Factory opal (VoIP) which has updated to the latest since the libraw1394 update. I don't know the state of the other telephony apps that use libraw1394 but I'm pretty sure that any package that fails due to a missing libraw1394.so.8 is depreciated. Anyway this has come back to haunt me and I'm creating the package libraw1394-8 to prevent a sudden loss of telephony packages, it's not as easy as I thought, I have to move the headers in the devel package into a named directory to prevent a conflict with libraw1394-devel. IMHO the VoIP packages need an overhaul so any help will be appreciated - home:plater libraw1394-8, I'm slowly getting snowed under and although I learn rapidly by finding things out by trial and error this time I need some more experienced help to speed the process up. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 5 months

[opensuse-packaging] Simplifying RPM groups

by Pavol Rusnak

Hi! We had a small discussion about RPM groups on openSUSE Conference and we came to the conclusion that the current situation is a mess. We have 244(!) RPM groups, some of them are really old (System/X11/Servers/XF86_3, Productivity/Networking/Napster) and somewhere we have very precise granularity (20 groups for games, 44 groups for networking tools). This problem was tackled by Duncan 2.5 years ago - see [1] (the image links are broken, but I found the correct locations). What he did was that he mapped our RPM groups to PackageKit groups and create a new Group view[2] which is the default but the old one[3] is still present. To solve this situation we can do the following: 1) get rid of our groups 2) adopt either PackageKit or Fedora or MeeGo simplified group set (see attached files, I got PackageKit groups from their git repo, so I'm not sure if all of them are valid, Fedora and MeeGo ones are VERY similar) 3) fix rpmlint script to check for new groups What we will gain in all 3 cases: * there will be no need to use group mapping in YaST, we'll directly use the reduced set, one package groups dialog instead of two What we will gain when choosing Fedora/MeeGo group set * it will be easier to cross-distro create packages (now one has to create %if-s when the groups differ and they often do) What we will gain when choosing PackageKit group set * well, at the beginning not much, but we could ask other distros to use the same common set, this is for a long run and could fail :-( From these options I like using Fedora/MeeGo and I'm slightly inclined to MeeGo option (they don't use spaces in group names and their logic of System/* is very similar to what we currently use). What do YOU think? [1] http://duncan.mac-vicar.com/blog/archives/308 [2] http://old-en.opensuse.org/images/0/02/Rpmgroups-after.png [3] http://old-en.opensuse.org/images/d/d3/Rpmgroups-before.png -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9 prusnak[at]opensuse.org Czech Republic

10 years, 5 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging November 2010