Hi Dirk and all,
Some time in the past, I've integrated my rpmlint check
(ErlangCheck.py) to openSUSE's checks. It is in Factory's rpmlint for
a long time. Now, I would like to continue and make my check available
as option to maintainers in OBS. The dependencies to ErlangCheck.py
are python-pybeam, python-construct and python-six. All of them are in
Factory for a long time. I need to modify rpmlint-mini to pack parts
of python-pybeam, python-construct in order to make ErlangCheck.py
working in OBS workers.
I see that rpmlint-mini.spec is full of magic. What is the preferred
way to pick python modules from %python_sitelib? Should I add another
deps.txt and yet another loop...? I can make this is hundred different
ways but it is better to ask prior.
--
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp:0x2207@jabber.ru
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
It's currently impossible to submit packages from Base:System due to
repo-checker blocking submissions as base packages suddenly require krb5.
This is due to a change in libtirpc, that creates a huge cycle. As I'm
protecting Factory from having that cycle too, I block such updates.
Unfortunately the check hits other packages in the cycle too, so this
means: unless this change is reverted, it won't be possible to submit
base packages.
Greetings, Stephan
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
I just started helping review team with reviews and I'm running into people who
instead of creating patches and documenting them just update and change
tarball (without bumping the version) effectivelly hiding patches inside.
It is obviously wrong, but I was asked for the policy and I'm failing to
find it. Anybody can help? Apart from that, what are the best practices for git
snaphot packages? It can be related...
Thanks
--
Michal HRUSECKY SUSE LINUX, s.r.o.
openSUSE Team Lihovarska 1060/12
PGP 0xFED656F6 19000 Praha 9
mhrusecky[at]suse.cz Czech Republic
http://michal.hrusecky.nethttp://www.suse.cz
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
I'd like to propose the following addition to the packaging
policy regarding users and groups
(https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups):
The names of users and groups which are created by a package
should be prefixed with an underscore "_". This creates a
safe namespace for the distribution and avoids collisions
between system group and usernames which are created by
packages and regular group and usernames.
Existing users and groups can be renamed with the following
scriptlet:
%pre
getent group GROUP >/dev/null && groupmod -n _GROUP GROUP
getent group _GROUP >/dev/null || groupadd -r _GROUP
getent passwd USER >/dev/null && usermod -l _USER USER
getent passwd _USER >/dev/null || useradd -r -g _GROUP -d HOMEDIR -s /sbin/nologin -c "user for PACKAGENAME" _USER
Group or username collisions can be problematic, if a username
required for a package already exists, the pre-scriptlet will
silently re-use the user/group for the package.
While YaST apparently contains a blacklist preventing the
creation of known system users/goups, this is tedious to maintain
manually and doesn't cover the case where an administrator
creates accounts via useradd/groupadd or maintains users/groups
in LDAP. The lack of a separate namespace also prevents the use
of certain group or usernames which might be desired.
There is precedent for the above policy, it has been implemented
in OpenBSD since 2002/2003 where it requires changes to about
half of the packages that provide users and/or groups. However,
the overwhelming majority are simple configuration file changes
and one-line patches to change hard-coded names (see also
http://lists.opensuse.org/opensuse-packaging/2014-02/msg00103.html
for a the numbers and
https://build.opensuse.org/package/view_file/openSUSE:Factory/rpmlint/confi…
for the group and usernames currently in use). This policy should
only be enforced for new packages while existing packages can be
gradually converted, I'd be willing to help with that.
--
Guido Berhoerster
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
What should be done about a package that has an upstream change log in
ReStructuredText (RST)? Usually the only markup I see in such a case is
the ``foo`` construct (which means something should be displayed with
fixed-width font, such as a variable or file name), so I'm not talking
about anything exotic really.
On the one hand, I think that the package change log is not an RST file
and so RST markup should be removed for the package change log. But on
the other hand, I don't feel like I should be modifying the upstream
change log in general. I could be convinced to do it in a case like
this though.
Is there a rule already I should follow?
--
Jason Craig
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On Sunday 23 February 2014 16:06:26 Jos Poortvliet wrote:
> On Feb 19, 2014 5:32 PM, "Sascha Peilicke" <speilicke(a)suse.com> wrote:
> > Hi guys,
> >
> > since more and more openSUSE projects start to make use of our CI
> > infrastructure, we have to organize who's allowed to do what. In the past
>
> we
>
> > just added more and more people with rights to organize everything. So I
>
> tried
>
> > to reduce the global list of users with admin rights. Instead, we now
>
> have a
>
> > per-project (translates to Jenkins job) ACL matrix where each project can
> > organize stuff themselves. In simple words, you now can configure per job
> > who's allowed to change things. There should be no need to bug me again
> :
> :-)
> :
> > That said, the list of ci.o.o admins now is:
> > coolo, jdsn, bmwiedemann and saschpe (me).
> >
> > The following openSUSE projects currently use ci.opensuse.org:
> > - Open Build Service / osc
> > - OpenStack
> > - Yast / libyui
> >
> > The first two projects have per-job based access rules set already. If you
> > have a ci.o.o job and want to grant somebody the right to modify it, just
> > check "Enable project-based security" and add the (already registered)
>
> user in
>
> > question.
> >
> > And if you want to add your openSUSE-related project to our CI, please
>
> get in
>
> > touch with any of the guys mentioned above. That's it.
>
> I am guessing there is a wiki page where this is documented, perhaps it
> would be possible to link to that page from http://ci.openSUSE.org?
I have to admin that ci.opensuse.org is slightly under-documented. However,
I'd like to avoid creating huge wiki pages that run out of sync. Instead, the
CI boys already agreed to add/extend Jenkins job descriptions and similar
things so that this is more obvious. I guess having a small wiki page about
"how to get your stuff tested" wouldn't hurt...
--
With kind regards,
Sascha Peilicke
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany
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
Hi,
I never got it how to get straight forward around build failures which
are caused by package checks.
In my particular case I get on "SLE_11_SP2":
....
I: Program causes undefined operation
(likely same variable used twiceand post/pre incremented in the same
expression).
e.g. x = x++; Split it in two operations.
E: dateutils sequence-point yuck-scmver.c:485
....
I've tried already rpmlintrc, for example
addFilter(".*")
addFilter("undefined operation")
addFilter(".*operation on.*may be undefined.*")
setBadness('sequence-point', 0)
Is this an rpmlint issue at all?
Or doesn't work rpmlintrc on SLE_11? I remember I had already issues in
the past with "addFilter" which worked for all distros but not for SLE.
cu,
Rudi
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello
I get this metadata error when accessing the following:
[openqa-factory-oss]
type = yast2
name = openqa-factory-oss
baseurl = http://openqa.opensuse.org/opensuse/factory-testing/repo/oss/
Possibly corrupted channel file (openqa-factory-oss).
Will it be fixed ?
Thanks Glenn
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
I'm trying to build kprinter4[1] package.
According to desktop file category guidelines[2], I included in spec file:
%suse_update_desktop_file -r %{name} Utility Printing
But then build failed with:
WARNING: Category "Printing" is unknown \!
ERROR: No sufficient Category definition: {path_to_desktop_file}
Errors in installed desktop file detected. Please refer to
http://en.opensuse.org/SUSE_Package_Conventions/RPM_Macros
Where is a problem and what it's more important, what is a solution? Our wiki
page with desktop menu categories is outdated? build/check tool issue?
[1] - https://github.com/credativ/kprinter4
[2] -
http://en.opensuse.org/openSUSE:Packaging_desktop_menu_categories#Utility
--
Pozdrawiam / Best regards,
Mariusz Fik
openSUSE Community Member
GPG: 5FCE 7241 B3B9 32FD 455B C30E 42D6 6C88 9E83 7C3D