openSUSE Factory July 2019

factory@lists.opensuse.org

102 participants
73 discussions

[opensuse-factory] Too many packages to process

by Vojtěch Zeisek

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/

4 months, 3 weeks

[opensuse-factory] Default Java

by Bernd Ritter

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

1 year, 6 months

[opensuse-factory] openSUSE reproducible builds status 2019-01

by Bernhard M. Wiedemann

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

1 year, 7 months

[opensuse-factory] please someone help with SR#711379

by Stefan Seyfried

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

1 year, 10 months

[opensuse-factory] Package firewalld should not yet replace SuSEfirewall2

by Freek de Kruijf

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

1 year, 10 months

[opensuse-factory] RFC: Stop using Group tag in spec files

by Igor Gnatenko

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

1 year, 11 months

[opensuse-factory] Proposal: Use /usr/libexec for libexec content

by Neal Gompa

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

1 year, 11 months

[opensuse-factory] LTO in openSUSE:Factory

by Martin Liška

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/LTO https://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

1 year, 11 months

[opensuse-factory] / v. /usr: What do we want?

by Daniel Molkentin

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

1 year, 11 months

[opensuse-factory] RFC: configuration files in /etc

by Thorsten Kukuk

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

1 year, 11 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

openSUSE Factory July 2019