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
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
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
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
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
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
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
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
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
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