openSUSE Factory April 2020

factory@lists.opensuse.org

123 participants
117 discussions

[opensuse-factory] Can we assume that /bin/sh is bash?
by Martin Wilck 21 Mar '22

21 Mar '22

Hi Jan, all, I'd like to carry our OBS dicussion to a wider audience (https://build.opensuse.org/request/show/672510). The question is whether we can assume that "/bin/sh" links to bash, in particular whether rpm scriptlets without explicit -p interpreter can be assumed to interpreted by bash. I'm aware that, in principle, /bin/sh is supposed to be the Bourne shell on Unix systems. But as a matter of fact, on current openSUSE, it is not. Unless it's tampered with, /bin/sh is a symlink to /bin/bash. bash is not started in full POSIX mode if invoked as /bin/sh, and even if it's in POSIX mode, it supports some extensions over the POSIX shell spec (e.g. the [[ ]] construct), which makes it behave differently than another shell not supporting [[ ]] would (*). Problably there are more differences, I can't claim to know them all. Here are some arguments why I think it'd be reasonable to assume that /bin/sh is bash on openSUSE: 1. patterns-base-minimal_base depends on bash, and the /bin/sh symlink is a non-configurable part of the "bash" package. 2. we could handle /bin/sh via /etc/alternatives, but we don't. 3. our Wiki suggests testing failing scriplets using "bash -xv" (https://en.opensuse.org/openSUSE:Packaging_scriptlet_snippets) 4. /bin/sh has pointed to bash for a long time (not sure how long exactly). FTR, Fedora basically guarantees (sh == bash) for the purpose of rpm scriptlets (https://fedoraproject.org/wiki/Packaging:Scriptlets). So Fedora <-> openSUSE portability may also be an issue to consider. If we can't assume that /bin/sh is bash, what else can we assume? I recall from earlier work that writing really 100% compatible shell code for all kinds of environments is really hard. E.g., "[" isn't 100% portable either, even though it's part of the POSIX "test" standard (http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html). We should have clear rules which syntax expressions can be used in rpm scriptlets, and which can't. IMO we should define one of the various existing shells as a reference by saying "if it's supported by this shell, it's valid scriptlet code". That'd be easier (especially for testing compliance) than referring to a spec. That reference shell doesn't have to be bash, of course. Thanks Martin (*) For example: # ln -s /usr/bin/echo '/usr/bin/[[' # ls -l /bin/sh lrwxrwxrwx 1 root root 4 Feb 8 10:38 /bin/sh -> bash # /bin/sh --posix -c '[[ 2 = 1 ]] && echo yes' # dash -c '[[ 2 = 1 ]] && echo yes' 2 -eq 1 ]] yes -- Dr. Martin Wilck <mwilck(a)suse.com>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

25 147

[opensuse-factory] openSUSE:Factory git mirror update
by Bernhard M. Wiedemann 04 Oct '21

04 Oct '21

Hi, our experimental git mirror of openSUSE:Factory got a new feature: It now makes single commits from most individual updates with some useful info in the commit message. This makes the whole history much nicer to read: https://github.com/bmwiedemann/openSUSE/commits/master In the usual case of SRs it links back to the SR on OBS, because that is where most of the discussion might have happened: https://github.com/bmwiedemann/openSUSE/commit/d1afc9699 but sometimes direct commits happen and they are shown with the commit message and a link to the OBS change https://github.com/bmwiedemann/openSUSE/commit/b2786e5c8 Ideas for future work: In theory we could also track these packages' devel projects on a 'devel' branch In a similar fashion we could also track openSUSE:Leap:15.* on stable/leap15_N branches to allow offline diff We could try to enable osc build to work from such git dirs. Either this uses the OBS server-side logic to resolve dependencies to get the usual .osc/_buildinfo* and .osc/_buildconfig* files or we re-implement or re-use OBS server logic to allow builds when offline. And then (in the foggy far future) it would be possible to make a gateway back from github pull-requests or gitlab merge-requests to submitting SRs in OBS. Or we re-think how OBS handles its source files until then. See https://www.youtube.com/watch?v=iY_ADUQiiQI&t=787 Ciao Bernhard M.

4 8

[opensuse-factory] Too many packages to process
by Vojtěch Zeisek 12 Mar '21

12 Mar '21

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/

8 10

[opensuse-factory] openSUSE reproducible builds status 2020-03
by Bernhard M. Wiedemann 02 Jun '20

02 Jun '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, last month's status: https://lists.opensuse.org/opensuse-factory/2020-03/msg00014.html Last months' reproducible builds project updates (including my work): https://reproducible-builds.org/reports/2020-02/ I uploaded https://rb.zq1.de/compare.factory-20200402/ today and rbstats are: total-packages: 12781 (+89) build-tried: 12772 (+89) build-failed: 54 (+14) build-n-a: 86 (+1) build-succeeded: 12632 (+74) build-official-failed+na: 135 (+43) build-compare-failed: 408 (+17) build-compare-succeeded: 12224 (+57) verify-failed: 526 (+7) verified-semi-reproducible: 11458 (+87) verified-bit-identical: 0 (+0) bit-by-bit-identical: 11862 (+58) not-bit-by-bit-identical: 764 (+17) not-bit-by-bit-identicalcheck: 770 (+16) https://rb.zq1.de/compare.factory-20200402/graph.png shows the change over time https://rb.zq1.de/compare.factory-20200402/unreproduciblerings.txt lists very unreproducible core packages (bootstrap+DVD) Of the badly unreproducible packages, 4 were in ring0 44 were in ring1 That makes it 48/2901 => 1.65 % which is below the overall average of 408/12632 => 3.23 % 764/12632 => 6.05 % of packages are not perfectly reproducible newly unreproducible core packages: cri-o parallelism causes go buildid to vary - same problem as in many of our go packages (since go1.10) python3 filesystem readdir order influences .pyc file marshalling https://bugs.python.org/issue34033 Ciao Bernhard M. -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQRk4KvQEtfG32NHprVJNgs7HfuhZAUCXoXALgAKCRBJNgs7Hfuh ZI5NAJ92/xS9ZDT7FQBg0HwnAHfO46lBYACgsvlwixFNKxHssknMR1089KXD1qY= =kxCI -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 4

[opensuse-factory] netcfg (15.1 and TW)
by Frans de Boer 18 May '20

18 May '20

LS, I can't start postfix or nfs-server because /etc/services is relocated to /usr/etc/services as from Jan 30. Other programs are not accordingly adjusted! This happens both under TW and 15.1. Please, correct this issue. Regards, Frans. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

9 19

[opensuse-factory] Leap 15.2 more than 2000 packages are missing
by Daniel Noga 07 May '20

07 May '20

Hi, I have more time to try a new software and I am constantly finding that some package is missing not only from Leap 15.1, but from grand new Leap 15.2 too . So I just compared http://download.opensuse.org/tumbleweed/repo/oss/x86_64/ to http://download.opensuse.org/distribution/leap/15.2/repo/oss/x86_64/ and I found that Tumbleweed has 23286 packages there and Leap 15.2 has only 20797 . I thought, that we are deep in Beta phase, so new Leap will have similar count of packages as Tumbleweed. But it is not the case. What is behind? Most distribution maintainers moved to Tumbleweed and Leap is now mostly abandoned from developer perspective? Or there is another syncing phase Tumbleweed -> Leap, which does not happened yet? Daniel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 6

[opensuse-factory] PATH and other environment variables reduced after update 20200419-0 -> 20200427-0
by Bernhard Voelker 04 May '20

04 May '20

Just updated a VM: openSUSE Tumbleweed 20200419-0 -> 20200427-0 After reboot + login, I miss some environment variables which should be set by some scripts in /etc/profile.d/, and also ones from ~/.profile are missing. E.g. also PATH lacks $HOME/bin: berny@tweedy:~> printenv PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin For comparison as root: $ printenv PATH /sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin Any idea what's wrong/different? Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 3

[opensuse-factory] The (near) future of AutoYaST
by Imobach González Sosa 04 May '20

04 May '20

Hi all, After rewriting our storage layer and, partially, our network stack, the YaST team is looking now to AutoYaST, which is showing its age. Just in case someone does not know, AutoYaST is a software component that, using an XML based description, orchestrates YaST modules to install/upgrade and configure the system in an unattended way. You might want to check the docs[1][2] for more information. We have started started to analyze and build a list of the things we would like to address, but we would love to hear your opinion. Do you have some use case you would like to see supported? Which problems have you faced when using AutoYaST? Which features do you miss? Do you have a different vision of what AutoYaST should be (we can learn from those opinions too)? Any idea/comment is welcome. Thanks a lot in advance! Regards, Imo [1] https://documentation.suse.com/sles/15-SP1/html/SLES-all/book-autoyast.html [2] https://doc.opensuse.org/projects/autoyast/ -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/

13 20

[opensuse-factory] Closing The Leap Gap Weekly Update Meeting 30.04.2020
by Lubos Kocman 04 May '20

04 May '20

Closing the Leap Gap - Weekly Update All meeting minutes can be found here: https://etherpad.opensuse.org/p/ClosingTheLeapGap-meeting Attendees (please add yourself): gp, vmoutoussamy, lpechacek, mawerner, lkocman, mmeissner, sbehlert, jsrain =================================== 1.0 Project plan: https://confluence.suse.com/display/leap/Project+plan =================================== 2.0 Schedule: https://en.opensuse.org/openSUSE:Roadmap openSUSE Leap 15.2 FCS July 2nd 2020 =================================== 3.0 Priority items and blockers List of features marked as "DeveloperProgram" https://jira.suse.com/secure/Dashboard.jspa?selectPageId=34230 JUMP related work is tracked here https://progress.opensuse.org/projects/jump_152/issues Simplified Feature request for openSUSE Leap contributors https://jira.suse.com/browse/JIRA-722 No blockers as of today. =================================== 4.0 Updates from individual teams =================================== 4.1 Product Management Owner: Stefan Behlert Next round of Feature reviews set-up for Wednesday next week. We are progressing nicely on the features, as far as PM can see, but there are still some hills before us. Matthias: Features are ongoing, Stefan and Michal are constantly reviewing project related features. It's quite a lot of requests. Handing of External communication in progress. =================================== 4.2 openSUSE Leap Release Management Owner: Lubos Kocman Friday meeting with QA Maintenance resulted in the following action items: * Have a statistics about tracked SLE Community requests as part of openSUSE Leap 15.2 retrospective. * Add a weekly update about SLE Community requests to openSUSE Release Engineering meeting A CtLG guidance for where to submit request: https://confluence.suse.com/pages/viewpage.action?pageId=476709080 =================================== 4.3. openSUSE Leap Release Engineering Owner: Max Lin Not available =================================== 4.4 SLE Release Management Owner: Alex Herzig, Stefan Weiberg Yast - Issues with 32 bit kernel, this is already clarified (there will be no i586 kernel). These packages will be accepted on staging later today. =================================== 4.5 Autobuild Owner: Lars Vogdt, Adrian Schroeter No udate on Jump project itself. We had a meeting regarding handling of Source submissions with focus on backports project. We've agreed that we'll have a build service extension, and any submission against Jump will be redirected to backports. We will need to discuss with SLE people and autobuild team on how to handle submissions for core packages. We need to take care of handling of submissions against maintenance project (e.g. in case that package origin is SUSE:SLE-15- SP0*) A full ftp tree build is now finished. =================================== 4.6 Maintenance Owner: Stephan Barth Stephan: Same like last week: no news, waiting for workable items. =================================== 4.7 Security Owner: Marcus Meissner No upate, Marcus is involved in current CtLG features. Clarification of ECO and CtLG. This will be covered in FAQ https://confluence.suse.com/pages/viewpage.action?pageId=476709080 =================================== 4.8 Packagehub Owner: Wolfgang Engel Not available. Ismail and Wolfgang were available on the previous meeting regarding Jump Sources (see notes bellow). 4.9 Beta Program Owner: Vincent Moutoussamy We've started a draft of communication regarding recent changes towards improved transparency with the community. Communication will not happen until Monday. Gerald offered help to review the document. Thanks Gerald for community teasers. How would be the go/nogo for the CtLG handled? Lubos: Distribution build wise: I'd like to have a installable image build as part of the Jump:15.2 OBS project. Then we'd like have a period of testing for the community, consume fedback and have a Go-Nogo session on the openSUSE Release Engineering meeting. Gerald: There is multiple related efforts, such opening Bugzilla, improving the feature process, merging changes in Leap to SLE, Jump,.... Many of these should quite non-controversial. Unless there is clear pushback, openSUSE tends to follow a "those who do decide". Lubos: the CtLG effort has multiple building blocks. Each block has probably different set of stakeholders or approvers. Let's make sure that we get them all right. Action item for Lubos is to map efforts on https://en.opensuse.org/Portal:Leap - Discuss, Define and be Transparent with the openSUSE Community: Communication sent to openSUSE but also internal SUSE ML (linux@) and Public SLE Beta ML (sle-beta(a)lists.suse.com): https://lists.opensuse.org/opensuse-project/2020-04/msg00145.html - Upcoming news-o-o -> https://github.com/openSUSE/news-o-o/pull/36 I hope to review some to give an initial inputs on the opening bugzilla initiative next week. Gerald: I've read the email thread and there was just one response. Was it just an update or are there any next steps from the email. Vincent: It was intended to be a status update on all of the efforts and initiatives which are currently. Action item: keep opensuse-project@ updated with perhaps changes. This could be first set of incomming bugs and so on. Way for community to engage or see the value. Vincent: the initiative for bugzilla is a longer term effort, so please expect this to take some time. Gerald: Release early, Release often. =================================== 4.10 Engineering / Product Migration Owner: Jiri Srain No update. Discussion regarding yast dependency on kernel. kernel does not exist for i586. No conclusion yet. Current migration scenarion is being tested by QA (roughly for a month already). Have a look into Fedora single click migration. 3 step migration, in principal everything is in. Necessary packages need to be part of opensuse (migration plugin etc.) SCC will have to be configured properly. We'll have to deal with packaging issues regarding branding packages. Everything should be ideally solved on the packaging side. Some hacks can be done but it's not prefered. Current approach is handling all on the packaging side (Effort by Ludwig). Registration schema (for AutoYaST) is currently in the queue for Public RC milestone of SLES. Todo: Migration path from Leap to Jump. =================================== 4.11 Engineering - Kernel Owner: Libor Pechacek Yast package dependency on kernel on i586 has been resolved. Libor does not see any compelling reason, other than support for "old" hardware, for building 32bit kernel so the 32bit topic is closed for the moment on his side. Maybe we should keep Jump with aligned with SLE as much as possibe, to make the migration path to SLE as easy as possible. We don't have 32bit kernel in SLE therefore it shouldn't be in Jump or Leap as well. This topic was raised because of the yast2 buildrequires on kernel. See SLE RM section. Libor is open to hear any other reasoning to have 32bit in Leap. There are two features about RT, what should QA do about them? The highest RT level, does not come for free and development have invested quite a lot of time to get this working. It's a PM decision. lkocman: sync of kernel-rt was approved, but nothing to do for QA yet on any RT features. stefan: We do not expect Leap to ship the full RT product as of now. Libor: Current Leap kernel has bettert RT behavior than SLE, so the fact that we would not include in in Leap seems awkward. Adrian: Jump would get kernel-rt as soon as it's exported, so would have to blacklist it from ftp tree in Leap. Let's postpone pending RT features (lttng, ...) to the next release. =================================== 4.12 Engineering - Desktop Owner: Stefan Weiberg Not available =================================== 4.13 Quality Assurance Owner: Marita Werner Nothing to do for RT in SP2. Team is looking to all features, and checking whether there is some work for them or not. Vincent: Is there a dedicated team on openSUSE, just like in SLE? Lubos: There is an agreement to have a one person a week dedicated to openSUSE Leap. Marita: Outside of regular work there are some people who are involved more into community effort and people who are less. =================================== 4.14 SLE Architect Owner: Thorsten Kukuk Not present, therefore no update. =================================== 4.15 Marketing and Community management Owner: Douglas DeMaio Not available =================================== 4.16 Marketing Customers & Partners Owner: Sarah Whitlock No update this week. =================================== 4.17 Gerald Owner: Gerald ;-) Gerald and Matthias an interview with Swapnil Bhartiya, an online journalist, on CtLG. Will share link when available. =================================== ## Notes from today's (Apr 30) Jump Sources meeting Attendees: Adrian, Dominique, Ismail, Lubos, Max, Wolfgang If package build fails: backports disables the build and wipes out binaries Leap sources feed the backports project. Adrian would do the sync in a way that sources are not part of the Jump project, and are synced to backports instead. Jump would have only "temporarily forked packages". This would be the case only for packages where functionality is different. Dimstar: This approach makes sense, submissions would be sent to openSUSE:Backports project. How do we handle submissions to SUSE: namespace? Currently subject to Community SLE Feature Requests https://jira.suse.com/browse/JIRA-722 Dimstar: openSUSE:Backports will be the dominant part of the openSUSE Leap. How do we help Backports to manage the incoming work? openSUSE Leap resources would be there to help Backports. We're certainly not reducing the number of resources working on openSUSE. Ismail: Joined resources should improve quality for both Leap and SLE. Adrian: All Submissions would happen against Jump:15.2 (later openSUSE:Leap) and would be automatically redirected to openSUSE:Backports. Backports would still inherit sources from SLE, so we'd not be losing any submissions. This would not be a problem as Backports would remove conflicting packages at GA. Adrian is tracking work in https://jira.suse.com/browse/OBS-59 Max: can you submit parallel requests against Backports? Adrian: The build service part is done in this way, it's the tooling that might not support it yet. openSUSE Leap Staging currently supports only single submit requests against a single package. Will Backports support multiple requests per package? Adrian: think it's a good idea but staging tooling is currently the only part that is missing the support. Ismail doesn't see why we shouldn't support this. Backports currently does not have Staging in place. Adrian: I don't know what to do if we have an SR against Jump and if we redirect it. Won't it be "transformed" into a maintenance request? We've agreed not to allow submissions to Jump from others until 15.2 is released. This will then change after the GA. We would track the pending work on pre-integration testing (install- check on synced packages) that will be tracked in openSUSE Release tools. N��r��y隊Z)z{.��r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.��r�+��0��Ǩ�

5 6

[opensuse-factory] Renumbering patches and the factory bot
by Martin Wilck 03 May '20

03 May '20

My current request for hamster-time-tracker https://build.opensuse.org/request/show/798689 (needed to make the hamster GNOME extension work with GNOME 3.36) is repeatedly rejected by the factory bot with messages like this: "A patch (0002-Fix-disable-callback-gnome-shell-3.30- compatibility.patch) is being deleted without this removal being mentioned in the changelog." If you look at the changelog, you can see that the patches have been *renumbered* to avoid ambiguity, and that I've documented this in the changelog in detail. Can someone please override the bot? Or if not, can I get some guidance how to document this such that the bot accepts it? Martin -- Dr. Martin Wilck <mwilck(a)suse.com>, Tel. +49 (0)911 74053 2107 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

12 23

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

openSUSE Factory April 2020