openSUSE Factory July 2020

factory@lists.opensuse.org

110 participants
70 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] [RFC] OpenSUSE Distribution Tiers Policy
by Dirk Müller 24 Nov '20

24 Nov '20

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

18 54

Python 3 packaging change (was: [opensuse-factory] Tumbleweed - Review of the week 2020/29)
by Neal Gompa 27 Aug '20

27 Aug '20

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

5 7

[opensuse-factory] Proposal: /tmp as tmpfs
by Richard Brown 14 Aug '20

14 Aug '20

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

48 153

[opensuse-factory] openSUSE way
by Denis Kondratenko 02 Aug '20

02 Aug '20

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

5 7

[opensuse-factory] Flickering screen (and worse)
by David Walker 31 Jul '20

31 Jul '20

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

7 16

[opensuse-factory] Firefox - I think I have found a bug regarding locales/languages
by Linux Kamarada 31 Jul '20

31 Jul '20

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

2 2

[opensuse-factory] Tumbleweed - Review of the week 2020/31
by Dominique Leuenberger / DimStar 31 Jul '20

31 Jul '20

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

2 1

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

openSUSE Factory July 2020