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/
Hi all,
I would like to get your input and start a discussion around :
https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy
This is a draft aiming to define what a Premium Tier openSUSE
Distribution architecture is. Currently this is mostly x86_64 as it
stands today out of historic reasons, and rather than letting historic
reasons define the future, I'd like to make it a bit more transparent
on why that is and what quality standards an openSUSE distribution has
to offer for other architectures to be considered also a main /
premium Tier openSUSE Distribution.
Please be aware that this does not silently introduce aarch64 as a
premium tier, however it is aimed to define the rules that any
architecture port including aarch64 would have to meet in order to be
considered a premium tier. So once we agree on the terms and scope,
AArch64 would be requested to be evaluated against this.
For the interest of tracking, please refrain from editing the main
page, and use either the mailing list discussion here or the Talk page
for comments/questions/considerations/feedback.
Thanks!
Dirk
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
On Fri, Jul 17, 2020 at 10:40 AM Dominique Leuenberger / DimStar
<dimstar(a)opensuse.org> wrote:
>
> * Python3 package will be renamed to python38. The goal will be to
> allow multiple python versions to more easily coexist.
This isn't changing the nature of packaging Python software, is it? We
still have a concept of a *default* Python version and things will
just *work* that way? Otherwise this is going to be an utter
nightmare.
--
真実はいつも一つ!/ 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
Hello community,
We recently moved MicroOS and Kubic to use tmpfs for /tmp instead of
writing files there to disk.
This means files written to /tmp as never written to disk and so
dissapear on reboot.
This was for a number of reasons, including
- Reducing wear on SSDs/SD card storage
- Using less disk space and being more tidy generally
- Being more like many other Distro's and Unixes including Debian,
Arch, Fedora, Solaris, etc
- Being more consistant with the FHS recommendations that /tmp is
flushed on reboot
https://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES
All of these reasons also apply for regular openSUSE, so I would like
to propose that Tumbleweed moves to tmpfs for /tmp soon also.
The impact should be minimal, as all POSIX compliant applications
should already assume that /tmp is not persistant between invocations
of the program.
As we're walking paths that other distros long have, my own research
suggests that vast majority of problematic /tmp use has already been
resolved, such as by using /var/tmp instead.
We will likely impliment this as systemd mount unit, meaning if people
disable it then they will be able to return to the old behaviour.
Does anyone have any objections, concerns, thoughts?
Regards,
--
Richard Brown
Linux Distribution Engineer - Future Technology Team
Phone +4991174053-361
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409
Nuernberg
(HRB 36809, AG Nürnberg)
Geschäftsführer: 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
Hello community members,
Lubos noticed that "openSUSE way" talk [1] got some views (~500) [2] and
thus maybe community is interested about it.
I am not sure, maybe it is just fancy and attractive name
Anyway I found couple of ppl that would like to follow up and check if
we could have more easy install and config for complete Sway desktop.
During preparation to the talk I have created github project to track
progress for it and ToDo for the future of my setup [3]. In the same
repo you could find example of dotfiles for config presented in the talk.
If you are interested in this project, create cards, issues and work on
them.
Next steps are to create good pattern [4] and branding [5].
And to push more packages to Factory (wofi).
Maybe we even could move that repo/project under openSUSE github org ?
So try, migrate and have some fun with Sway and tell us if we could make
it better.
https://en.opensuse.org/Sway
1. https://denisok.github.io/oSC20-openSUSEway/index.html
2. https://www.youtube.com/watch?v=dSMxJKSNSjo
3. https://github.com/denisok/openSUSEway/projects/1
4. https://github.com/denisok/openSUSEway/issues/1
5. https://github.com/denisok/openSUSEway/issues/2
Thanks,
--
Denis Kondratenko
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
I've been having trouble with an intermittently flickering screen on
my laptop for the past few weeks. About half the time, it's minor,
just flickering for a few seconds, but it can get worse, lasting
for a minute or two and blanking large (nearly all) of the screen.
The worst incidents will end with the following in the log:
Jul 24 15:44:50 homelap7 kernel: i915 0000:00:02.0: [drm] HPD interrupt storm detected on connector eDP-1: switching from hotplug detection to polling
After this, the flickering stops.
Searching, I noticed issues like this associated with the i915
driver over the past few years, so I though I'd ask if there
might be a cause in recent Tumbleweed releases. Otherwise, I
guess I'm off to the local computer repair shop.
Here's some hopefully-relevant information about the graphics
card:
> hwinfo --gfxcard
24: PCI 02.0: 0300 VGA compatible controller (VGA)
[Created at pci.386]
Unique ID: _Znp._LgIsmf7zU8
SysFS ID: /devices/pci0000:00/0000:00:02.0
SysFS BusID: 0000:00:02.0
Hardware Class: graphics card
Model: "Intel UHD Graphics 620 (Whiskey Lake)"
Vendor: pci 0x8086 "Intel Corporation"
Device: pci 0x3ea0 "UHD Graphics 620 (Whiskey Lake)"
SubVendor: pci 0x1558 "CLEVO/KAPOK Computer"
SubDevice: pci 0x1323
Driver: "i915"
Driver Modules: "i915"
Memory Range: 0x6022000000-0x6022ffffff (rw,non-prefetchable)
Memory Range: 0x4000000000-0x400fffffff (ro,non-prefetchable)
I/O Ports: 0x4000-0x403f (rw)
Memory Range: 0x000c0000-0x000dffff (rw,non-prefetchable,disabled)
IRQ: 131 (15907724 events)
Module Alias: "pci:v00008086d00003EA0sv00001558sd00001323bc03sc00i00"
Driver Info #0:
Driver Status: i915 is active
Driver Activation Cmd: "modprobe i915"
Config Status: cfg=new, avail=yes, need=no, active=unknown
Primary display adapter: #24
Thanks!
David Walker
Hi everyone!
Last week I formatted my SSD, I installed openSUSE Leap 15.2
(actually, a development image of Linux Kamarada 15.2 Beta [1]) and I
realized Firefox was behaving differently than I remembered regarding
locales/languages on 15.1.
TLDR: Firefox is not retrieving the current user's language
preferences on GNOME.
Try the following steps (I suggest using the openSUSE Leap 15.2 GNOME
live image [2]):
1. (not needed if you are running the live image) Make sure the
MozillaFirefox-translations-common package is installed
2. (not needed if you are running the live image) Create a new user
3. (not needed if you are running the live image) Log in to this user
4. Change the GNOME language to another one different from English -
e.g. Português Brasil
(log out and log in to apply the language change)
5. Start Firefox
On openSUSE Leap 15.2, Firefox starts in English. Also, if I open
Firefox and set its interface language to Portuguese (Brazil), it
downloads the language pack. Shouldn't it use the one present on the
MozillaFirefox-translations-common package? The openSUSE Leap 15.2
GNOME live image comes with Firefox 78.0.2esr.
But if you try the Linux Kamarada 15.2 Beta live image from the
website [3] which is by now with Firefox 68.9.0esr (it's older than
the one I used to format my SSD), Firefox presents the expected
behavior: it starts in the current user's language preferences on
GNOME.
Maybe something changed from 68.9.0esr to 78.0.2esr.
Please someone confirm if that is really a bug. If so, I can open a
bug report on Bugzilla.
Thanks!
Antonio
The Linux Kamarada Project
http://kamarada.github.io/
[1]: https://build.opensuse.org/package/show/home:kamarada:15.2:dev/Linux-Kamara…
[2]: https://software.opensuse.org/distributions/leap
[3] https://kamarada.github.io/en/download/15.2/
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Dear Tumbleweed users and hackers,
Week 31 has seen a steady flow of snapshots. The biggest snapshot was
0721, for which we had to do a full rebuild due to changes in the krb5
package, that moved some files around. In order for all packages to
keep up with this change, the full rebuild was needed. The week in
total has seen 7 snapshots being published (0721, 0724, 0726, 0727,
0728, 0729 and 0730)
The changes included in those snapshots were:
* krb5 file system layout changes (moved to default locations)
* Mesa 20.1.3 & 20.1.4
* NetworkManager 1.26.0
* Flatpak 1.8.1
* Python3 package was renamed to python38, allowing for further
parallel packages like python39
* sudo 1.9.2
* KDE Plasma 5.19.4
* Mozilla Firefox 79.0
* Nano 5.0
The changes currently in stagings are around the topics of:
* grub2 to address Boothole issues (will come with a new signing key
for grub/kernel/shim)
* GCC 10.2
* LibreOffice 7.0rc2
* Change of /tmp to tmpfs
* openSSL 3.0
* RPM changes: %{_libexecdir} is being changed to /usr/libexec. This
exposes quite a lot of packages that abuse %{_libexecdir} and fail to
build. Additionally, the payload compression is being changed to zstd
Cheers,
Dominique