Hi,
There's a request to add a system user 'tor':
https://build.opensuse.org/request/show/96531
There is no name space separation between system users and actual
logins. So especially for short names like the above there is a
chance that it could collide with an already existing user name on
some system. Having a system service running with the uid of an
actual user isn't desirable.
So what about mandating an extra prefix or suffix to (new) system
user names like 'daemon' or 'service'? Ie in the above example the
user name would be 'tor-daemon' or 'tor-service' instead of 'tor'.
Other thoughts?
cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello mates,
i'm trying to build a new packageversion.
The old Licenses Field was "GPLv3 or later". If i'm going to:
http://license.opensuse.org/ and place GPLv3 there, the Site proposes to use
"GPL-3".
If i'm placing this into the Licenses Field i become:
kvirustotal-lang.noarch: W: invalid-license GPL-3
kvirustotal.x86_64: W: invalid-license GPL-3
kvirustotal.src: W: invalid-license GPL-3
The specified license string is not recognized. Please refer to
http://license.opensuse.org/ for the list of known licences and their exact
spelling.
But why this false? Does anyone knows more?
Wish all a happy X-Mas
Sascha
--
Sincerly yours
Sascha Manns
Community &Support Agent
open-slx GmbH
http://www.open-slx.de (Business)
http://saigkill.homelinux.net (Private)
This mail is written with Balsam Professional 12.1
All,
More than once I have submitted something to factory that didn't have
all the requires and buildrequires pieces already there.
Is there a simple test I can run on the package to verify that before
I submit a new package?
In this specific case, I want to submit security -- log2timeline.
I've been slowly submitting all the pre-reqs and I think I finally
have everything in factory.
Thanks
Greg
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
I've branched server:php:applications to
https://build.opensuse.org/project/packages?project=home%3Arobert_munteanu%…
and updated a couple of packages, fixing
https://bugzilla.novell.com/show_bug.cgi?id=734936 .
These packages are in a dependency tree, and I'm not sure how to
submit requests for them. Should I start with the leaves and once they
are accepted submit the parents, or should I submit them all at once
and mention that they should be reviewed/merged together?
Thanks,
Robert
--
Sent from my (old) computer
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Am 07.12.2011 05:50, schrieb Cristian Rodríguez:
> Use > 1140 instead ;-)
Guess what? ;)
Doesn't work either. I've changed to the following:
%if 0%{?suse_version} <= 1140
%patch0 -p1
%endif
%patch1 -p1
%patch2 -p1
%patch4 -p1
%patch5 -p1
%if 0%{?suse_version} > 1140
%patch6 -p1
%endif
So patch0 should affect all releases from including 11.4 and downwards.
patch6 should affect all releases above 11.4.
Again, patch6 is only applied in Factory, not 12.1.
Maybe the build target has a wrong suse_version?
https://build.opensuse.org/package/show?package=lxdm&project=home%3AlOtz100…
---
Lutz Thuns
openSUSE member (lOtz1009)
LXDE team
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
I'm attempting to build an RPM for a more recent version of the global tag
suite than currently available for Centos 6.x, using SRPMs from
https://build.opensuse.org/package/show?package=global&project=openSUSE%3AF…
OBS Global Project .
Several minor issues related to the _docdir macro generate build/rpmlint
errors. It wouldn't be difficult to hack the spec/config info allowing the
build to complete.
This my first venture in to RPM development/troubleshooting. I'd rather make
a small contribution toward "draining the swamp" than snuff a few alligator
hatch-lings.
The issues are:
* Makefile.am (top directory of source tree) has: gtagsdir =
${datadir}/doc/packages/global
* global.spec assumes %{_docdir} = %{_datadir}/doc/packages
* CentOS does not appear to define %{_docdir}, dispite a few references to
it in other macros
* %{_docdir} is listed in OpenSuse Packaging Guidelines, but not in
guidelines any other Distro
Builds fail in %install, because the %{_docdir} is empty or substituting
%{_datadir} file source/destination paths are not symmetric relative to the
build/buildroot.
Comments/suggestions about reporting/correcting cross-distro discrepancies
would be appreciated. If difference can be mapped through macros it might be
useful to collect and distribute them.
david
--
View this message in context: http://old.nabble.com/Global-SRPM-Centos-compatibility%3A-_docdir-issues-tp…
Sent from the opensuse-packaging mailing list archive at Nabble.com.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi Nelson,
This sounds great. Does anyone know if a wiki page will be created /
updated about how spec files should look like?
As I look at your reply, I'm thinking about SLE(S|D)10 and maybe even
SLE(S|D)11 they won't be handling a missing %clean correctly as their rpm
is 4.4.2.
So I wonder if it's a good idea to remove %clean now?
Regards,
Joop.
On Fri, December 23, 2011 11:25 pm, Nelson Marques wrote:
> With RPM 4.9+ you no longer require the %clean section, it's done
> automatically. There's the new %check section amongst other things...
> Newer versions of RPM shouldn't require either the
> %defattr(-,root,root,-) as they should be doing it by default... and
> if things are like in Fedora, the BuildRoot should be handled
> automatically also (not sure if implemented on OBS).
>
> NM
>
> 2011/12/23 Joop Boonen <joop.boonen(a)boonen.org>:
>> All,
>>
>> I have a question lately I see spec files that have been changed with
>> the
>> remark (cf. specfile guidelines).
>>
>> The %clean section has been removed for example, this doesn't feel right
>> to me.
>>
>> Does anyone know something about the cf. specfile guidelines?
>> Did I miss something?
>>
>> Regards,
>>
>> Joop.
>>
>>
>> --
>> To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
>> To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
>>
>
>
>
> --
> Nelson Marques
>
> /* http://www.marques.so
> Â nmo.marques(a)gmail.com */
>
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
You may have noticed: I added libtool as buildrequire to many
packages. Now that I'm through with my list, I would like to remove
libtool from the projconfig. After that you need to buildrequire
libtool if you need it otherwise the package will fail, but unless
something slipped this should not be the case for any package
in factory.
Next stop: automake
Greetings, Stephan
--
Sent from openSUSE
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Dear Packagers,
during the time from the 24th Dec 2011 until 08th Jan 2012
(Christmas/New Year´s Eve) many teams and departments inside the SUSE
Linux Products GmbH will be on vacation or can only offer limited
services. This affects also the "autobuild-team" you might know as
reviewers for your packages submitted to Factory (and other released
distributions).
While some of us are still in the office to get the most annoying
and security bugs fixed and out to you as our customers, most of us are
using this period to spend some time aside of computers and with their
friends and families.
As result, packages in openSUSE:Factory might stay a bit longer in the
"review" state as you can expect in normal times. Please be not so angry
with us in this case - just do the same and use this time for
regeneration and preparation for the upcoming openSUSE year.
We wish you and your families a Merry Christmas and a Happy New Year!
Ah: and remember to have a lot of fun! ;-)
Lars
--
Lars Vogdt <Lars.Vogdt(a)suse.com>
- OPS Engineering Services Teamlead -
SUSE Linux Products GmbH - GF: Jeff Hawn, Jennifer Guild, Felix
Imendörffer Maxfeldstraße 5, 90409 Nuernberg, Germany - HRB 16746 (AG
Nuernberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
Over the last couple of days I reworked update-desktop-files
not to rely on an explicit %suse_update_desktop_file call.
Instead Factory will have an additional brp script that trims
the translations from .desktop files.
So: if you can live with an rpmlint warning on older distributions
(I submited a rpmlint with the warning gone for factory), you can
skip the macro now if you call it without options.
The most useful option of the macro should be the -n option now,
as this one will mark the .desktop file with translate=false, which
then also skips the trimming.
There is one problem with removing the buildrequires on
update-desktop-files though: this package includes rpm provide triggers for
mimehandler(), so don't remove the buildrequire if you have MimeType=
in your .desktop file. Or we move that triggers to a package always
installed in factory.
Greetings, Stephan
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org