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
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.
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/
-----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
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
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
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
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/
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�����Ǩ�
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