I'm not sure, if this is bug or feature... After few days, update applet (TW,
KDE) says there are 6843 new updates (TeX, R, ... ;-). When I click to
"Install updates" error "Too many packages to process (6843/5200)" appears.
Zypper handles it well. Is it worth of bug report? To b.o.o?
Yours,
V.
--
Vojtěch Zeisek
Komunita openSUSE GNU/Linuxu
Community of the openSUSE GNU/Linux
https://www.opensuse.org/https://trapa.cz/
Hi there,
just wanted to let you guysome days ago I wondered what the default java
version would be. It should be Java 11. So I've installed a clean leap
beta installation.
I've installed java-openjdk-10, java-openjdk-11, java-openjdk-1_8_0.
Same with the equivalent devel packages. The default java version is
Java 11 both with "java" and "javac" via update-alternatives.
So everything's fine. I've updated the wiki page accordingly
(https://en.opensuse.org/Features_15.1#Java).
Does anyone know why there is no Apache Maven available in the default
packages? There is this "maven-local", which I think is not the maven
program itself.
Cheers,
Bernd
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Hi,
last month's status:
https://lists.opensuse.org/opensuse-factory/2018-12/msg00171.html
Last months' r-b project updates (including my work):
https://reproducible-builds.org/blog/posts/195/https://reproducible-builds.org/blog/posts/194/https://reproducible-builds.org/blog/posts/193/https://reproducible-builds.org/blog/posts/192/
I uploaded https://rb.zq1.de/compare.factory-20190125/ today
and rbstats are:
total-packages: 11298
build-tried: 11297
build-failed: 37
build-n-a: 107
build-succeeded: 11153
build-official-failed+na: 85
build-compare-failed: 283
build-compare-succeeded: 10870
bit-by-bit-identical: 10605
not-bit-by-bit-identical: 538
Fixed core packages since last month:
breeze5-icons dolphin libqt5-qtwebkit wireshark syntax-highlighting:
Qt rcc/qrc fix merged in Factory
https://build.opensuse.org/request/show/663360
also fixed dozens others like bitcoin.
opa-ff
CPU-detection via -march=native
https://build.opensuse.org/request/show/661771
gengetopt
https://build.opensuse.org/request/show/661735
nearly fixed:
pcre2
PGO/parallelism https://build.opensuse.org/request/show/668163
perl:
ASLR-induced randomness
https://build.opensuse.org/request/show/668211
--- ring0 ---
acl
gcc7
gcc8
--- ring1 ---
MozillaFirefox
MozillaThunderbird
ant
bsf
colord
emacs
firebird
gconf2-branding-openSUSE
gdb
gimp
gnome-documents
go1.10
go1.11
groff-full
grub2
hamcrest
installation-images
java-11-openjdk
java-1_8_0-openjdk
jing-trang
jtidy
junit
junitperf
kernel-debug
kernel-default
kernel-vanilla
kubernetes
libkolabxml
libqt5-qtscript
libreoffice
mono-core
mozilla-nss
pcp
php7
python-base
python3-base
qdox
release-notes-openSUSE
ruby2.5
rubygem-gem2rpm
rust
scons
transfig
virtualbox
xmlbeans
yodl
If you are interested in why they vary:
acl:
date+time in /usr/share/locale/en(a)boldquot/LC_MESSAGES/acl.mo
-PO-Revision-Date: 2018-10-23 01:45+0000
+PO-Revision-Date: 2033-11-24 15:01+0000
gcc7 gcc8:
indeterminism from PGO/parallelism + mtime. See also
https://github.com/bmwiedemann/theunreproduciblepackage/tree/master/pgo
MozillaFirefox MozillaThunderbird:
date+time, rust, other
has bug around update.locale symlink
/usr/lib64/firefox/libxul.so varies from
https://github.com/rust-lang/rust/issues/57041
.../browser/extensions/langpack-ca(a)xxxxxxxxxxxxxxxxxxx/manifest.json
- "version": "20181009013946"
+ "version": "20331110172641"
apache-commons-lang3 apache-pdfbox dom4j hsqldb icu4j javassist
jing-trang jtidy junitperf jython objectweb-asm qdox tomcat xerces-j2
xpp2 xpp3:
date + mtime
in .jar + javadoc html
can be normalized by strip-nondeterminism
bsh2 cglib:
/usr/share/maven-metadata/bsh2.xml has ASLR order issues
date + mtime in .jar + javadoc html
colord
some randomness from uninitialized memory
maybe from glib-compile-resources
16-byte random profileID in .icc files from cd-create-profile
plus an uncommitted date/time fix in lib/colord/cd-it8.c:
priv->enable_created = FALSE
ecj
ASLR + date?
/usr/share/maven-metadata/ecj.xml has alias entries in random order
emacs
dumps lisp interpreter memory to create its binaries
(similar to clisp)
causes variations in /usr/bin/emacs-*
firebird:
ships unreproducible database
http://tracker.firebirdsql.org/browse/CORE-5548
gconf2-branding-openSUSE
embeds mtime values in
/etc/gconf/gconf.xml.vendor/%gconf-tree.xml
gdb
contains testresults
https://bugzilla.opensuse.org/show_bug.cgi?id=1110708
gimp
ASLR
12 byte differ in bKGD header
from gegl
GEGL_USE_OPENCL=no GEGL_SWAP=ram /usr/bin/gegl
../../icons/Symbolic/64/gimp-texture.png -o 64/gimp-texture.png --
gegl:invert-gamma
gnome-documents
gnome-documents-getting-started.pdf has random ID from inkscape
go1.10 go1.11:
variations in /usr/lib64/go/1.10/pkg/obj/go-build/*/*-a
groff-full
date+time + unknown reason?
.ps files vary
.html files have CreationDate
grub2
mtime + readdir
https://savannah.gnu.org/bugs/index.php?54841
hamcrest
java .class files vary from
build/temp/hamcrest-core/generated-code
/org/hamcrest/CoreMatchers.java written by ant
javadoc html varies
installation-images
many variations from mtimes + filesys/readdir and %post scripts
java-1_8_0-openjdk java-10-openjdk java-11-openjdk
various .jar .zip .html .jmod
ordering in /usr/lib64/jvm/java-10-openjdk-10/lib/classlist
kernel-debug kernel-default kernel-vanilla
date+time ; random keys?
"Build time autogenerated kernel key0
..181009012108Z..21180915012108Z0.1,0"
kubernetes:
fixed upstream: order in man-pages
https://github.com/kubernetes/kubernetes/pull/68983
maybe fixed upstream: random build-ids
libkolabxml
unknown/ASLR?
from build/kolabformat-xcal-schema.cxx
created by compiled/xsdbin.cxx
libqt5-qtscript
filesys order
libreoffice
various .jar .so .dat/.bau (.zip) javadoc_log.txt
mono-core
date+time ; other
mozilla-nss
DSA random temp-key from shlibsign
https://bugzilla.opensuse.org/show_bug.cgi?id=1081723
pcp
/var/lib/pcp/testsuite/perfevent/perfevent_coverage has random diffs
from gcov / .gcno files causing diff in .o ?
php7
date / EPOCH timestamps
e.g. in /usr/share/php7/PEAR/.channels/__uri.reg
python-base python3-base:
PGO
varies .o files that go into /usr/lib64/libpython3.6m.so.1.0
.pyc files vary
python-base shows influence from date+hostname (in PGO?)
python-numpy
1 .pyc file varied
release-notes-openSUSE
partial fix in https://github.com/openSUSE/daps/issues/482
date+time in .pdf ; needs work on fop java code
random id values in .html
ruby2.5
2 gemspec files have date
created.rid varies
rubygem-gem2rpm
mtime ?
/usr/lib64/ruby/gems/2.5.0/cache/checksums.yaml varies
rust
asm diffs in cargo and others from llvm's llc
- filed at https://github.com/rust-lang/rust/issues/57041
some progress made here with the switch to llvm7
scons
hostname in various places
tigervnc
date+time+randomness in
/usr/share/vnc/classes/META-INF/TIGERVNC.RSA
from SignJar.cmake calling jarsigner with temporary private key
partial fix merged https://github.com/TigerVNC/tigervnc/pull/765
transfig
date+time
in sample-presentation.pdf /CreationDate /ModDate
from pdflatex
virtualbox
tar + random
https://www.virtualbox.org/ticket/16854
.so files have random NT_GNU_BUILD_ID (unique build ID bitstring)
maybe from out/linux.amd64/release/obj/webservice/gsoapH_from_gsoap.h
that has date+time in comment
/usr/share/virtualbox/extensions/VNC-5.2.16.vbox-extpack
unhandled gzip content: POSIX tar archive (GNU)
-13343137165.010505. 5...
+16773576625.010527. 5...
xmlbeans
index.xsb varies from filesystem
created in org.apache.xmlbeans.impl.tool.SchemaCompiler
yodl
pdf from latex/ghostscript/dvips/ps2pdf
additionally, on the SLE15 list
===============================
gnuplot
date+time in pdf from pdflatex
golang-github-prometheus-prometheus
date+time+random build-id
hawk2
https://bugzilla.opensuse.org/show_bug.cgi?id=1112159
ibus-libzhuyin libpinyin libzhuyin
random bytes - maybe uninitialized memory
perf
random filesys order
from nftw call in ./linux-*/tools/perf/pmu-events/jevents.c
python-keystoneauth1
https://bugs.launchpad.net/keystoneauth/+bug/1796899
https://build.opensuse.org/request/show/711379
Please, someone override factory-auto. It's running amok.
--
Stefan Seyfried
"For a successful technology, reality must take precedence over
public relations, for nature cannot be fooled." -- Richard Feynman
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Now that the date is near when SuSEfirewall2 will be removed I finally looked
into what firewalld is offering.
My analyses are that firewalld just offers only very basic features. It lacks
however more advanced features like rate limiting and control over logging.
My conclusion is that SuSEfirewall2 should not yet be replaced by firewalld.
First firewalld should at least have the lacking features mentioned above.
I don't see any reason why SuSEfirewall2 should currently be replaced.
Maintenance on it is minimal, so it could still exits next to firewalld.
--
fr.gr.
member openSUSE
Freek de Kruijf
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Hello,
My name is Igor. I'm long-time contributor in Fedora and started
recently to contribute to the openSUSE with focus on cross-distro
collaboration. I'm also contributor to many upstream projects which
includes RPM.
You can see my oSC19 talk here:
https://events.opensuse.org/conferences/oSC19/program/proposals/2489
There are still few things which are different between Fedora and
openSUSE spec files for rust packages, more specifically those are
license header, Group tag and changelog. While license header and
changelog things are not easy to fix, the Group one is.
In Fedora, we have removed all Group tags in F30:
https://fedoraproject.org/wiki/Changes/Remove_Group_Tag
Groups are hard to choose (I would rather prefer to see some kind of
tags), there is no check from RPM itself (it is basically free-form
text field) and usually you can't put application into one group
because they belong to multiple groups.
I spoke to a few people on the oSC and it seems that only YaST is
using this information to generate UI. So it should be doable to
change its representation which is not based on the Group tag.
Considering above, is there some process like Fedora Changes
(https://fedoraproject.org/wiki/Changes/Policy) in openSUSE where I
can propose this?
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Hello,
I'd like to propose adding /usr/libexec to the openSUSE FHS and
reverting the definition of %_libexecdir in rpm back to /usr/libexec
so that libexec content is installed there.
Currently, openSUSE overrides rpm to define %_libexecdir as /usr/lib,
which leads to pollution of the /usr/lib directory with executable
content as well as 64-bit content when there shouldn't be any. The
/usr/libexec has been in use on RH/Fedora and Mageia systems in the
Linux world, but has its origins in BSD and is still used today in
BSDs and variants (like Mac OS X). The usage of /usr/libexec for
libexec content has also been recognized by FHS with v3.0, released in
2015. In the Linux distribution landscape (that is, all major
families, not just RPM ones), /usr/libexec is in use on Red Hat,
Mandrake, Gentoo, and Slackware families.
This is a breaking change, as it means that as packages are rebuilt,
libexec content *should* migrate from /usr/lib to /usr/libexec. The
major advantage of migrating the libexec content is that it will make
openSUSE consistent with other major RPM-based Linux distributions,
and ease efforts in supporting SUSE distributions along with Red Hat
ones by removing the need for hacks and tweaks to support two
different hierarchies. This simplifies the portability headaches in
supporting both distribution families, and makes it easier for
applications that were originally aimed for RHEL/CentOS to run on
SLE/openSUSE Leap.
This change would be done in three stages:
1. Make the change to the filesystem package to add /usr/libexec to
the hierarchy.
2. Add /usr/libexec to allowed prefixes in rpmlint-checks and remove
spec-cleaner rule that assumes /usr/lib == %_libexecdir.
3. Make the change to the rpm package to set %_libexecdir back to
/usr/libexec. This one will cause a fair bit of work to fix packages
that do the wrong thing one way or another with %_libexecdir.
What do you all think?
Best regards,
Neal
--
真実はいつも一つ!/ Always, there's only one truth!
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Hi.
We as toolchain team are working on enablement of LTO in Factory:
LTO stands for Link Time Optimization and it is a GCC optimization
technique that improves speed and reduces size of binaries. According
to our measurements, ELF binaries will be about 5% smaller and debug
info packages by 15%. Now, there are various interesting packages that
have been LTO in Factory right now: libreoffice, MozillaFirefox, python3,
gcc9.
Our goal is to extend the scope to as many packages as possible. We'll achieve
that via a new RPM macro: _lto_cflags. We expect that about 5% of packages will
have LTO disabled due to various reasons. A new META bug has been created for that
and will link all these packages:
https://bugzilla.opensuse.org/show_bug.cgi?id=1133084
I'm also planning to collect all relevant information for package maintainers
on the following WIKI page:
https://en.opensuse.org/openSUSE:LTO
Note that Debian and Gentoo are also trying to adopt LTO in their corresponding
ecosystems:
https://wiki.debian.org/LTOhttps://github.com/InBetweenNames/gentooLTO
Martin
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Hi,
it is my understanding that openSUSE will no longer boot without /usr
being around. A long time ago I hence opened
https://bugzilla.suse.com/show_bug.cgi?id=1029961, with all the apps
that I could find as subtickets. The suggestion was move all apps to
/usr, and symlink /bin and /sbin, a step performed by Fedora a while ago.
So far I can see:
- Pro arguments:
- We can consolidate the root directories with their peers in /usr
- People have a hard time telling which binary is where
- The only real argument for providing an environment without /usr
being potentially available is now invalid due to systemd living in
/usr, and being required as early as the rootfs.
- Couter arguments:
- RPM cannot (or could not) deal with symlink. It was Fedora had
issues due to that (but now if/how it was ultimately resolved)
- "I like things the way they are"
As you can see from the maintainer response in the some of the
subtickets, there was not much love for giving up the root locations. So
I was about to close this ticket.
However, the current state is completely arbitrary, and other people
noticed and asked me to ask for direction and opinion here. How should
we proceed?
Cheers,
Daniel
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Hi,
for this, who don't want to read a lot of text, there is a video of
my talk about this topic from openSUSE Conference:
https://youtu.be/ony0ajC0PWA
The slides can be found here:
https://github.com/thkukuk/atomic-updates_and_etc/tree/master/Slides
and the full, detailed abstract can be found here:
https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md
What is this about?
RPM has a really very simple configuration file handling: overwrite
the config, move it away and write the new config or write the new config
in a different file (*.rpmsave and *.rpmnew).
If the rpm contains a configuration file marked as %config, and the
packager fixes a typo in a comment, RPM will move the by the admin
modified and adjusted configuration file away and put's the default
configuration file there, which means, your service will not work until
you merge the configuration files.
This is already bad, but it's getting really worse if you think about
atomic updates (transactional-updates on openSUSE):
- admin modifies configuration files
- admin starts an transactional update, the configuration file will
be modified
- admin makes changes to the configuration file
- admin reboots to active the changes
-> admin needs to find out which changes where done by whom and needs to
merge them all to get the service working again
While this shouldn't happen very often, more really seldom, if it happens,
it's really bad. Especially, if you think about big clusters with many
machines and not only a few workstations.
So I started looking into different solutions.
The first thing is: we are not alone with the problem, every distribution
with atomic updates has it, but every distribution has their own solution.
Which reminds me on the pre-FHS times, when you had to learn for every
distribution again where the configuration files and other tools could
be found.
So we need something, which helps everybody and is good enough specified,
that people will use this solution.
The second thing is: people want to have the configuration files in one
place, so that it is easy to find.
And at least, no, there is not the perfect solution solving everything,
for some I even have no idea, but for others we make big improvements
compared to today.
The goal is to provide a concept working for all Linux Distributors (like
the FHS, preferred is to get this into the FHS). Short to midterm, it should
solve the problems with atomic updates. Midterm to longterm, the result
should be, that no package installs anything in /etc, it should only contain
changes made by the system administrator or configuration files managed by
the system administrator.
The current proposals are:
https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md#pro…
A short summary:
Application configuration files:
Do something similar to what systemd is already doing today (See
https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Examples,
"Overriding vendor settings"). Put the default, by a Linux distributor
shipped configuration files somewhere below /usr, and /etc only contains
the overwrite.
This sounds like a lot of work, but in reality, many applications we
have on openSUSE Tumbleweed alredy support different locations for
configuration files and overwrite of them, like sysctl, dracut, PAM and
many more. For this, this is only a packaging exercise and rpmlint
checks.
System databases:
This are files in /etc like rpc, services and protocols.
We can put them somewhere below /usr, and /etc/ only contains the changes.
A glibc NSS module could merge them automatcially, different implementations
do exist already today for this.
/etc/passwd, /etc/group and /etc/shadow:
This is the big, open problem. We looked at many possible solutions,
but didn't found the real, generic one.
So, what is the expected outcome of this mail?
1. We need to agree, if we want to solve the problem or not
In my opinion, there is no real choice, if we don't do it
coordinated as Linux distributor, this will happen in a chaotic way.
2. We need to agree on the goal, so for me, this would be:
- short term: solve the problem for packages on openSUSE MicroOS
- mid term: solve the problem for openSUSE Tumbleweed
- long term: /etc/ only contains admin created files, a Linux
Distribution does not install there anything
3. We need to agree on a path below /usr for the default configuration
files
4. We need to agree on how we want to solve it.
Your comments and feedback?
Thanks,
Thorsten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org