TW
$SUBJECT can't be right, but trying to zypper rm opensans wants to remove
releasenotes. :-(
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
https://en.opensuse.org/openSUSE:Packaging_guidelines#Web_Applications
suggest to package "web applications" to /srv/www/%name. I see two
major problems with that
1. /srv is considered admin space so packages should not mess with
it. Citing FHS¹: "... no program should rely on a specific
subdirectory structure of /srv existing or data necessarily being
stored in /srv ... Distributions must take care not to remove
locally placed files in these directories without administrator
permission"
2. For the reason that admins are expected to put files in /srv that
are not tracked by package management, /srv is a default btrfs
subvolume. That means anything installed in /srv is excluded from
the default system snapshots. Ie rollbacks of packages that
install code in /srv won't have any effect and the rpm database
would not reflect what's actually running anymore.
Therefore I'd like to propose to change the section to the
following:
Web applications packaged in openSUSE should place their their files
in /etc, /usr, /var etc depending on type just like any other
application would do. A package must not install, remove or
otherwise modify /srv content as it's use is reserved to the admin
according to FHS¹. It's ok to allow the admin to configure the
software to use /srv of course.
cu
Ludwig
[1] http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSY…
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (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
All,
The ntfs-3g_ntfsprogs program does not currently include some of the
more dangerous utilities that it could include.
WIth "./configure --enable-quarantined" several "dangerous" utilities
get built and installed.
Given they are dangerous and possibly can destroy data I don't want to
put them in the main ntfs-3g_ntfsprogs package.
For now I've created a sub-package to hold them:
ntfs-3g_ntfsprogs-quarantined
https://build.opensuse.org/package/show/home:gregfreemyer:branches:filesyst…
Is there a more appropriate name for the sub-package in the openSUSE
naming conventions?
Greg
--
Greg Freemyer
www.IntelligentAvatar.net
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
even I've realized that "uname -r" is broken on any openSUSE build repo.
It's because the post-build-checks package symlinks an uname.sh script
which does not report the running kernel version anymore but a version
string from arbitrary text files or installed kernel sources.
What is the reason why we have this dirty hack? If any package would
need to know a kernel source version then it should certainly not use
uname to get it. Thus we should rather fix that package instead of
breaking uname.
Is there any chance to remove that uname.sh?
I'm fighting since months with some kind of kernel related odd behavior,
now I see that all my debugging scripts, etc. were totally useless.
That's annoying.
cu,
Rudi
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi guys,
sorry if this is the wrong list, it seemed the most fitting...
How can I prevent one package from being installed from all but one repo?
lxc is provided for Leap 42.1 in two repositories, the OSS repo and my
personal one.
> # zypper se --details --match-exact lxc
> Loading repository data...
> Reading installed packages...
>
> S | Name | Type | Version | Arch | Repository
> ---+------+------------+------------+--------+---------------------------------------------------------------
> l | lxc | package | 1.1.2-7.2 | x86_64 | openSUSE_Leap_42_1_OSS
> | lxc | package | 1.0.8-23.1 | x86_64 | openSUSE_Leap_42_1_ojkastl_buildservice_LXC_Vanilla_stable-1.0
> | lxc | srcpackage | 1.0.8-23.1 | noarch | openSUSE_Leap_42_1_ojkastl_buildservice_LXC_Vanilla_stable-1.0
For testing purposes I'd like to add a zypper lock to only get my own
lxc package when typing 'zypper in lxc‘. So I added locks for lxc from
OSS (and OSS-Updates, if an update should ever be released).
> # zypper ll
> # | Name | Type | Repository
> --+------+---------+-------------------------------
> 1 | lxc | package | openSUSE_Leap_42_1_OSS
> 2 | lxc | package | openSUSE_Leap_42_1_UPDATES_OSS
But zypper in lxc still gives me the wrong one, the one from OSS:
> # zypper se --details --match-exact lxc
> Loading repository data...
> Reading installed packages...
>
> S | Name | Type | Version | Arch | Repository
> ---+------+------------+------------+--------+---------------------------------------------------------------
> il | lxc | package | 1.1.2-7.2 | x86_64 | openSUSE_Leap_42_1_OSS
> v | lxc | package | 1.0.8-23.1 | x86_64 | openSUSE_Leap_42_1_ojkastl_buildservice_LXC_Vanilla_stable-1.0
> | lxc | srcpackage | 1.0.8-23.1 | noarch | openSUSE_Leap_42_1_ojkastl_buildservice_LXC_Vanilla_stable-1.0
> # rpm -qa|grep lxc
> lxc-1.1.2-7.2.x86_64
How to prevent this?
Are zypper's lock not the right tool, only preventing packages from
being updated or installed from a different repo?
Thanks in advance,
Johannes
Is there a way to make baselibs.conf different depending on the
distro? I could find anything in the wiki about this.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi Group,
I have a package that builds fine for all selected repos, except for openSUSE
13.1 64bit:
[ 65s] ... checking filelist
[ 65s] tryton-sao-3.8.4-1.1.noarch.rpm: directories not owned by a package:
[ 65s] - /usr/lib/node_modules
[ 65s]
Thats definitely the case as well for other 64bit repos, but there it works
fine. Why does it fail for 13.1?
Thanks
Axel
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Good Morning!
I have recognized, that a kernel package in hardware:snx does not finishing building because of the following error:
[ 91s] snx-kmp-xen.x86_64: E: suse-policy-kmp-missing-supplements (Badness: 10000)
[ 91s] snx-kmp-pv.x86_64: E: suse-policy-kmp-missing-supplements (Badness: 10000)
[ 91s] snx-kmp-default.x86_64: E: suse-policy-kmp-missing-supplements (Badness: 10000)
[ 91s] Make sure your 'BuildRequires:' include 'kernel-syms' and 'modutils' for
[ 91s] proper dependencies to be built.
I don't know what the real problem is. Both "BuildRequires" inclusions are correct, the package is correctly built for older versions.
Any hint?
Best regards,
Johannes
--
Johannes Weberhofer
Weberhofer GmbH, Austria, Vienna
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Is anyone working on (or thinking of working on) making our build
process reproducible?
https://reproducible-builds.org/
It seems Debian and Fedora are already part of the project, and the
advantages are quite compelling, not just from a security perspective,
but also due to the potential savings in storage and network
consumption:
https://hackweek.suse.com/13/projects/131
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org