openSUSE Factory December 2022

factory@lists.opensuse.org

89 participants
71 discussions

New package: os-update
by Thorsten Kukuk 09 Dec '22

09 Dec '22

Hi, there is a new package in Tumbleweed: os-update Since I'm lazy but wanted to have my non MicroOS servers also always up-to-date, I wrote this little package to make sure my servers are always fully patched like MicroOS: - runs regular via systemd.timer (default once a day) - Uses "zypper up" or "zypper dup" depending on the OS - If zypper reports "reboot necessary", a reboot will be triggered via rebootmgr, and if this is not running directly via "reboot". An enhancement could be to parse the services from the zypper ps -s output and restart the services... Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)

3 8

Tumbleweed - Move to x86-64-v2 (plus mitigation plan and call for help)
by Dominique Leuenberger / DimStar 08 Dec '22

08 Dec '22

Dear Tumbleweed users and hackers, I'm sorry to bring up an old topic once again, but it is an important one and I believe we have found a solution that works for most users and still allows openSUSE Tumbleweed to move ahead. openSUSE Factory repository is be repurposed to move forward with x86-64-v2, and openSUSE:Factory:Intel will be set up as openSUSE Factory currently exists today. This change is necessary to align with the SUSE factory first policy (https://opensource.suse.com/legal/policy) to keep aligned with the project's sponsor's development efforts. The discussed and agreed upon solution forward is the following: Repurpose of Factory * openSUSE Tumbleweed main repository: + will move to x86-64-v2 (like ALP will) + i586 support will be dropped from the repository (i.e. only x86-64-v2 left) + -32bit packages as needed by wine and such will remain present (but no complete repo to be installed meaning only the necessary -32bit parts for specific packages will exist) To become Old Factory * for users of legacy systems, we will introduce openSUSE:Factory:Intel, the same setup we have for ports like ARM, PowerPC, zSystems, RISCV. This repo will build packages for x86-64 (v1) plus i586, so basically what the current openSUSE:Factory repository does. Community Actions Needed The :Intel port will require volunteers from the community to look after it. This will entail monitoring the builds, validating QA results (if not passing) and monitoring/pushing on bugs that are exclusive to these architectures Actions for Users: Users of V2 compatible machines Users will automatically be upgraded to x86-64-v2 flavors (which is what we want to happen for the majority of users) Users who can't migrate to V2 and i586 users The repository list will need to be updated away from download.o.o/tumbleweed/repo/oss to something like download.o.o/ports/intel/tumblewed/repo/oss With this solution, we provide benefits to users of more recent machines than that of V1 by using the newer CPU instructions (and staying aligned, and thus relevant, with ALP). Yet this provides a path for users to still run Tumbleweed on machines that might not have the needed hardware. **Once the new intel port repository is ready, I'll let you know the exact location of it. We can expect for these changes to take place in the first quarter of the new year of 2023.** Cheers, Dominique

53 172

Re: Tumbleweed - Move to x86-64-v2 (plus mitigation plan and call for help)
by Dirk Müller 08 Dec '22

08 Dec '22

Hi Dominique, sorry for dropping the mailing list from the reply, fixed now again. Am Mi., 7. Dez. 2022 um 18:10 Uhr schrieb Dominique Leuenberger / DimStar <dimstar(a)opensuse.org>: > Sure - it's a wiki and can only benefit from more input. I added a pro/cons list from my point of view and expanded a bit on the baselibs idea. > The proposal I favor so far is the 'possible option' - i.e allow to > build everything (or as much as we want) proprely as a different > architecture and get this into rpm/zypp. I agree that this sounds like the "cleanest" approach, but it uses a hammer for something where not necessarily a hammer is needed, and it has therefore also quite some drawbacks. In addition, this approach has been rejected already previously by rpm upstream, I added the link to that discussion to your wiki page. Also it has a number of downsides, and myself being one of the openSUSE maintainers with the experience on armv6l/armv7l, there is a TON of software that breaks when rpm architecture is not matching the kernel architecture (aka when $(uname -m) != %arch, which is the case for armv7l <-> armv7hl). Maintaining this and getting those fixes upstream is anything but fun, and in this case it only worked because other distributions (fedora, ubuntu/debian) had the same issue, so everyone pushed the various upstreams to accept those patches. And yet, such an assumption is constantly creeping into the code requiring a constant battle of fixes. Also it breaks base interoperability requirements, especially when targetting -v3 and -v4 and thinking about containerized / cloud deployments, where cpu features can change between restart or reboot. > mls has already been lined up > and thinks it should be rather easy (for the rpm and obs part) Yes, that's true for zypper/libzypp. However in the non-openSUSE context of SUSE distributions often 3rd party software is used for systems management, and those need to be adopted for this as well. and many of those have hardcoded assumptions or false assumptions (like $(uname -m) being the rpmarchitecture). ; zypp > itself already has code to treat arch x>y but compatible (i586/i686) - > si if we get x86_64<x86_64-v3, we're all set there (plus code to detect > what machine you have) with the downsides that it requires patching of about 1000 packages (%ifarch x86_64 -> %ifarch %x86_64) and not providing coinstallability, meaning you can't have single-installation media/machine images, requiring the user to choose which version works across their data centers and clouds (and hope that they do not use anything like kubernetes that just moves around workload) plus requiring full builds of the tumbleweed distribution (while technically we could build smaller ones for the higher optimized versions, that would mean mix-match deployments on the user side and on our installation medias, increasing size requirements and complexity) Greetings, Dirk

2 2

Re: Tumbleweed - Move to x86-64-v2 (plus mitigation plan and call for help)
by Michael Schroeder 08 Dec '22

08 Dec '22

Von: Dominique Leuenberger / DimStar <dimstar(a)opensuse.org> > The proposal I favor so far is the 'possible option' - i.e allow to > build everything (or as much as we want) proprely as a different > architecture and get this into rpm/zypp. mls has already been lined up > and thinks it should be rather easy (for the rpm and obs part); It may be easy code-wise, but we would need rpm upstream to accept the new architecture. Plus, we'll need to adapt many spec files to use a new %x86_64 macro in ifarch lines. I'm actually in favor of the ld.so hwcaps subdirectory feature, for a couple of reasons: - all the container tooling does not support a way to differentiate x86_64 - the v3 package can still be installed in parallel on a host that does not support it, i.e. one can build containers that have both versions installed - there is no need for a new architecture in the build service, we can build the v3 variants in the x86_64 scheduler (using multibuild or package links). Hwcaps has the disadvantage that it only works for libraries, though. Cheers, Michael. -- Michael Schroeder SUSE Software Solutions Germany GmbH mls(a)suse.de GF: Ivo Totev HRB 36809, AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}

1 0

New package in Factory: utmp-cli
by Olav Reinert 07 Dec '22

07 Dec '22

Hi all, I would like to add a new package to Factory: utmp-cli The package provides a small command-line program of the same name. The program is for measuring temperature using USB thermometers like the ones you can buy at https://usbtemp.com/. The source code lives on Github, is MIT licensed, and reasonably well maintained: https://github.com/usbtemp/utmp-cli The devel-project is hardware:utmp-cli. I am not affiliated with usbtemp.com in any way. I just like the product, and decided to package the accompanying software for my own convenience. But I hope it might be of use to others, too, of course. Regards, Olav Reinert

1 0

New Tumbleweed snapshot 20221206 released!
by Dominique Leuenberger 07 Dec '22

07 Dec '22

Please note that this mail was generated by a script. The described changes are computed based on the x86_64 DVD. The full online repo contains too many changes to be listed here. Please check the known defects of this snapshot before upgrading: https://openqa.opensuse.org/tests/overview?distri=opensuse&groupid=1&versio… Please do not reply to this email to report issues, rather file a bug on bugzilla.opensuse.org. For more information on filing bugs please see https://en.opensuse.org/openSUSE:Submitting_bug_reports Packages changed: drbd eyeD3 (0.9.6 -> 0.9.7) libX11 (1.8.2 -> 1.8.1) pam pam-full-src pcfclock perl-Bootloader (0.939 -> 0.940) purple-mattermost (2.0 -> 2.1) systemd urlscan (0.9.9 -> 0.9.10) === Details === ==== drbd ==== Subpackages: drbd-kmp-default - BuildRequire %kernel_module_package_buildreqs (boo#1205149) ==== eyeD3 ==== Version update (0.9.6 -> 0.9.7) - update to 0.9.7: - [fixup-plugin] Added --no-dir-rename. - Add remove-all-unknown to classic plugin. <gobater(a)users.noreply.github.com> - Track/disc number support for JSON/YAML plugins (and tests) - CountAndTotalTuple named tuple for count/total values. - EyeD3 __all__ includes core.AudioFile. - AudioFile.__str__ returns path. - Strict render Frame flag to continue on render errors. Applied to RelVolAdjFrameV24, etc - Track unsupported frames and add `--remove-all-unknown` classic plugin option (#586) <gobater(a)users.noreply.github.com> - Removed display-plugin due to Grako EOL (#585) - [stats] Print bytes as text and filter private members. - Remove Python 3.6 support, EOL. (#560) - Doc grammar fixed (#537) <74979584+piatrashkakanstantinass(a)users.noreply.github.com> - Fix problem when frame file format invalid, and input.read() returns no more data at all - this had the potential to loop endlessly. (#539) <gerson.kurz(a)ng-branch-technology.com, gerson.kurz(a)gmail.com> ==== libX11 ==== Version update (1.8.2 -> 1.8.1) Subpackages: libX11-6 libX11-6-32bit libX11-data libX11-devel libX11-xcb1 - Update to version 1.8.1 This release fixes the --enable-thread-safety-constructor option to the configure script to work as intended. In the previous release, the changes for this option may not have been enabled when the option was not specified or when the --enable option was specified. While we have enabled it by default, believing that doing so will reduce the number of bugs users encounter running libX11 clients, in some cases it may expose bugs in which clients had previously gotten away with calling libX11 functions while a libX11 lock is already held, and thus now deadlock, as discussed in https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/157 - let's hope this version doesn't suffer yet from the regressions reported in boo#1205778, boo#1205818 (reported against 1.8.2); we need libX11 thread safe for totem (GNOME 43) :-( - going back to version 1.7.5 for now to get rid of regressions, which were introduced by trying to get thread-safe in libX11 itself - re-introduced U_fix-a-memory-leak-in-XRegisterIMInstantiateCallback.patch which was not yet in 1.7.5 - supersedes the following patches * U_0001-Add-XFreeThreads-function.patch * U_0002-Don-t-use-pragma-inside-a-function-it-breaks-compili.patch * U_0003-Fix-797755-Allow-X-IfEvent-to-reenter-libX11.patch * U_0004-Indentation-fixes-around-recent-dpy-in_ifevent-chang.patch * U_0005-ChkIfEv.c-fix-wrong-handling-of-dpy-in_ifevent.patch ==== pam ==== Subpackages: pam-32bit pam_unix - Move pam_env config files below /usr/etc ==== pam-full-src ==== - Move pam_env config files below /usr/etc ==== pcfclock ==== - BuildRequire %kernel_module_package_buildreqs (boo#1205149) ==== perl-Bootloader ==== Version update (0.939 -> 0.940) - merge gh#openSUSE/perl-bootloader#140 - add basic support for systemd-boot - 0.940 ==== purple-mattermost ==== Version update (2.0 -> 2.1) Subpackages: libpurple-plugin-mattermost pidgin-plugin-mattermost - update to 2.1: * Fetch last 60 messages when a channel is joined for the first time from Pidgin. ==== systemd ==== Subpackages: libsystemd0 libsystemd0-32bit libudev1 libudev1-32bit systemd-32bit systemd-container systemd-devel systemd-lang udev - Don't ship symlink /usr/lib/environment.d/99-environment.conf anymore. /etc/environment is owned and parsed (among other config files) by pam_env(8), which is included by 'systemd-user' PAM service anyway. ==== urlscan ==== Version update (0.9.9 -> 0.9.10) - update to 0.9.10: * Add "*" to allowed URL characters. Fix #125 * Strip whitespace from URLs. Fixes #124 * Redo redirection of sterr/stdout. Fix #122

1 0

openSUSE Release Engineering meeting 07.12.2022
by Lubos Kocman 07 Dec '22

07 Dec '22

All meeting minutes can be found here: https://etherpad.opensuse.org/p/ReleaseEngineering-meeting Meeting is hosted here https://meet.opensuse.org/ReleaseEngineeringMeeting ## Attendees DimStar,GuillaumeG, lkocman, Axel, Richard. maxlin, mmeissner, wengel, ddemaio ## Leap New build was published yesterday Code submission deadline for any SLES 15 SP5 related features (does not apply for 15SP4:Update etc), as well as Leap 15.5 Beta code-drop deadline is on January 25th 2023. 15.5 Feature tracking at https://code.opensuse.org/leap/features/issues Ongoing: SUSE Open Source policy review, SUSE Empoyees can participate https://opensource.suse.com/suse-open-source-policy (public facing url) I'd be happy for any feedback from community in form of e.g. email, since the github project SUSE/open-source-policy is private and limited to SUSE Employees as issues might contain discussion regarding confidential topics. Leap Micro 5.4 initial setup in place ALP release party on 19th ## openSUSE Tumbleweed openSUSE:Factory build fail stats: 80 failed 5 unresolvable (last week: 114 / 14) https://tinyurl.com/ysy4nnnz * RPM 4.18 in the queue. Trips over some packages abusing %setup -n .; they should switch to %setup -c * Staging:H: initial tests with Ruby 3.2 as default (release scheduled end of the year) * Staging:N: experiments with openssl-3 as default: main blocked are nodejs1[89], openssh and ibmtss * Staging:O: gcc13 will be introduced and take over the 'library build' (the usual two-phase introduction we do with gcc); gcc12 will stay the default compiler for now * util-linux package layout changes remains a topic to be worked out. x86-64-v2 * openSUSE:Factory:LegacyX86 is setup and builds are in a similar state as openSUSE:Factory * Bots are already up and running: ttm, pkglistgen, trigger-rebuild for rebuild=local * openQA is setup https://openqa.opensuse.org/group_overview/75 Results are not bad so far; most failures are due to the repo not being available on download.o.o yet though Only Jiri Slaby volunteered to maintain LegacyX86 so far; he mostly cares for x86-64-baseline in LegacyX86; x86-32 has no explicit volunteers (so it might just be tagging along, similar to what it did so far in openSUSE:Factory, where only few extra cycles are explicit to i586) ## Richard (MicroOS) openqa.opensuse.org now tests primarily on x86-64-v2/v3 now. New machine definitions will be reintroduced for v0/v1 testing as part of the legacy port. Desktop-GNOME: The Road to Release: transactional-update-notifier is once again WIP after great feedback about why the current approach wasn't the best idea from a security standpoint Bugs still WIP osinfo-db still doesn't recognise MicroOS as a seperate distribution - debates with upstream ongoing General MicroOS Stuff in Staging: podman 4.3.1 - broken, maintainer informed, test fixes done, but upstream bugs may require some more time https://openqa.opensuse.org/tests/2912733#step/podman/83 Considering FDE by default now single-password-entry full disk encryption is in Tumbleweed Trying to decide if it's a better approach than a fully vertified boot/OS variant of MicroOS, which wouldn't use encryption, but would then encrypt user/system data (eg /home, /var, etc) Please join the Telegram/Matrix group and give your opinion. Investigating alternative installation methods as YaST doesn't have the functionality we require and most likely wont any time soon. KDE MicroOS Desktop is still suffering from a significant lack of contribution. Please join the Telegram/Matrix group and dive in with helping. ## Max 15.5 15.5 * lua54 is available * KDE update is not ready yet, it's still pending in staging * Look into update Cinnamon in Leap 15.5, I did set up a project for the verification, after that, filed bsc#1206143 for whilteing cinnamon-settings-daemon in polkit-default-privs. And mailed Cinnamon maintainer about nemo-extensions build fail. * Dropped python2 interpreter from ftp-tree after addressed(hopefully) the remaining package what depend on python2, python2 interpreter will not available since the next snapshot Build stats(x86_64): 47 build fails, 4 unresolvables(last week: 49 build fails, 4 unresolvables) ## Guillaume - Arm Tumbleweed: * Rolling * appx WSL image now builds in Factory:ARM (tested manually on a Windows-on-Arm machine). This can be uploaded as part of some "preview" program as a 1st step. * NVIDIA: tester with aarch64 server and NVIDIA card wanted - Proprietary drivers are now available for aarch64 (only G06): https://download.nvidia.com/opensuse/tumbleweed/ - New opengpu driver also available in OBS: https://build.opensuse.org/project/monitor/X11:Drivers:Video Leap: * appx WSL images (Leap 15.4 and 15.5) work ALP: * SUSE:ALP: - WIP: Add back aarch64 in openQA ALP: * openQA job-groups: https://github.com/os-autoinst/opensuse-jobgroups/pull/233 * OBS/openQA sync: https://github.com/os-autoinst/openqa-trigger-from-obs/pull/192 ## Sarah - s390 Not available Dimstar: Fails on QA as fonts are unreadable in the installer. (https://bugzilla.opensuse.org/show_bug.cgi?id=1205585). libQt fix to address this issue should be accepted today/tomorrow Tumbleweed * No readable fonts: https://bugzilla.opensuse.org/show_bug.cgi?id=1205585 -> It can be, that it is a Mesa bug. * git tests have broken the build for git on s390x, but there is no error output. It is working on Fedora (upstream hint): https://bugzilla.opensuse.org/show_bug.cgi?id=1204762 / https://lore.kernel.org/git/CAN0heSoc+jKxseyyR-=8+ATc8rdY5UyFWZPepaQsGn9m+H… -> Workaround of disabling tests is giving a succeeded result and upstream discussion in progress Leap: * openQA tests have been failing because log files were not uploaded. okurz has created a PR for it at the end of last week: https://progress.opensuse.org/issues/119713, which works only with a single running test * problem exists continuously and is also transferred to openSUSE Tumbleweed: https://progress.opensuse.org/issues/120405 ## Doug * FOSDEM * Bus has 17 sign ups * Contact ddemaio if you're in Nuremberg and want to take the bus to FOSDEM. Space may be limited. * Planning second ALP prototype article lkocman: (right now we're blocked on PM feedback), official blog post should be shared with us on End of Business today. * Budget discussions related to project * oSC23 * Delaying CfP until contract is signed * May 26 - 28 ## Dirk Not available * Won maintainership of SUSE:ALP:RISCV - currently in bootstrap * Working on bisecting qemu/libseccomp/kernel-obs-build tests failure on Step:15-SP4/SP5 so that armv7l builds are published again https://bugzilla.suse.com/show_bug.cgi?id=1205624 ## Wolfgang (Package Hub), Scott Bahling 15 SP5 Package HUB channel is set up. Stefan did initial testing and looks good. Some packages are still missing, this is on agenda for today and next week. The workshop regarding Package HUB equivalent for ALP Lubos will schedule a call with wolfgang and Scott to ensure that they're in loop for the High Level requirements document. https://en.opensuse.org/openSUSE:ALP/Workgroups/Community/Workshops/Consumi… Package Hub for SLE-15-SP5 product definition added and SCC is currently picking it up so it will be ready for testing with the beta of SLE-15-SP5 ## Maintenance team (Marcus or Maurizio (m4u)) Nothing worrysome, preannoucement for 15.3 EOL was sent to mainling list End of December 2022. There were three chromium updates in single week. Configuration setup problem for Maintenance of Leap 15.4 maintenance updates / openQA Marcus regarding Leap 15.4 Image respin - package set will change, we do need to refresh the packagelist Lubos to talk to Jan Stehlik, we can't put all on Marcuses shoulder. https://etherpad.opensuse.org/p/ReleaseEngineering-20221110-maintenance-dis… Need to setup Leap Micro 5.3 (don't have time this week) * Pending Leap Micro 5.3 maint-setup ffmpeg - possible file conflict on the next update, no idea how to avoid vendor switching at the moment. Removing the patch on the openSUSE side (that might contain security fixes) or releasing update on the packman side could fix the issue. Lubos to give Marcus some working contact for the team. Lubos: I was asked to provide requirements for the QA team. Mostly for the GA/current release but also for the update. Lubos will make wiki with requirements (something like maintenance plan perhaps). Marcus will review it. ## Adrian - OBS Axel: there were some cleaning activities in OBS, to determine inactive users and related unmaintained projects. Is there anything going on? Adrian: the script checks a project or a package that has no changes for more than one year. It will create a delete request, that can be deleted. If there is no reaction there will be auto-acceptance in few days. Package can be always manually submitted back if the DR was missed. Users will not be deactivated. Adrian: User cleanup would have to be discussed with IDP team (SUSE IT). OBS is just a consumer. Lubos will create a request to suggest this action in Service desk. Adrian: if the user never logged in into OBS, that's probably a cleanup that could stay in touch. ## Open Floor some members might not be able to join due to conflict with ALP OpenFloor meeting. We might want to give them heads up to provide information in etherpad before the meeting starts

1 0

Re: x86-64-v2: oggenc, zstd (Stephan Kulow)
by Fritz Hudnut 07 Dec '22

07 Dec '22

---------- Forwarded message ---------- > From: Stephan Kulow <coolo(a)suse.de> > To: factory(a)lists.opensuse.org > Cc: > Bcc: > Date: Sat, 8 Oct 2022 08:13:11 +0200 > Subject: Re: x86-64-v2: oggenc, zstd > > > > Yes, systems mainly doing heavy work will be upgraded when faster > > hardware and budget is available. But the former high performance > > systems remain suitable for doing ordinary work for long time. > Yes. But the question remains on how many of those you plan > to run tumbleweed on. > > Greetings, Stephan > > Stephan: As posted previously, I'm running TW and a number of Gecko Rolling, and Debian Sid, and Manjaro, along with Lubuntu developmental . . . on a '12 cMP using a Xeon i7 processor of that era . . . . The plan is to run it until a number of parts blow up. I'm also running Leap 15.5 on an '09 MBP using Core2Duo processor, perfectly competent for daily driver. F

23 47

New Tumbleweed snapshot 20221205 released!
by Dominique Leuenberger 06 Dec '22

06 Dec '22

Please note that this mail was generated by a script. The described changes are computed based on the x86_64 DVD. The full online repo contains too many changes to be listed here. Please check the known defects of this snapshot before upgrading: https://openqa.opensuse.org/tests/overview?distri=opensuse&groupid=1&versio… Please do not reply to this email to report issues, rather file a bug on bugzilla.opensuse.org. For more information on filing bugs please see https://en.opensuse.org/openSUSE:Submitting_bug_reports Packages changed: CoreFreq (1.92.3_k6.0.10_1 -> 1.92.4_k6.0.10_1) arpwatch-ethercodes man-pages-ja (20220815 -> 20221015) mutt (2.2.7 -> 2.2.9) newt (0.52.21 -> 0.52.23) poppler (22.11.0 -> 22.12.0) poppler-qt5 (22.11.0 -> 22.12.0) python-pygit2 (1.10.1 -> 1.11.1) qpdf (11.1.1 -> 11.2.0) sunpinyin vhba-kmp virt-what (1.21 -> 1.25) === Details === ==== CoreFreq ==== Version update (1.92.3_k6.0.10_1 -> 1.92.4_k6.0.10_1) - update to 1.92.4: * [Intel/Skylake-X] Permits MSR_RING_PERF_LIMIT_REASONS ==== arpwatch-ethercodes ==== - sort existing oui.csv to show differences in future updates - sort downloaded oui.csv - move vim commands to a place where vim can find the commands ==== man-pages-ja ==== Version update (20220815 -> 20221015) - update to release 20221015 * Improved manual pages ==== mutt ==== Version update (2.2.7 -> 2.2.9) Subpackages: mutt-doc mutt-lang - update to 2.2.9: * Document the <1234> key syntax for bind. * Fix non-printable keyname printing to use <octal> syntax. * Move AM_PATH_GPG_ERROR before AM_PATH_GPGME. * Update gpgme autoconf files to the latest versions. * Adjust manual concerning IMAP Fcc in batch mode. * Add explicit void to 0-parameter function definitions. ==== newt ==== Version update (0.52.21 -> 0.52.23) - update to 0.52.23: * fix automatic height of menu/list in whiptail (broken in 0.52.22) * fix automatic width of whiptail --yesno box * fix automatic width in whiptail with unicode characters * fix automatic width with whiptail --noitem and --notags options * fix spacing with longer tags in whiptail * avoid overlapping backtitle in whiptail with automatic height * fix crash in whiptail with new libpopt * switch from usleep to nanosleep (Rosen Penev) * fix libnewt.pc to enable static linking (Alexey Sheplyakov) * fix LDFLAGS order in snack linking (Sam James) * use CFLAGS when compiling snack * improve configure.ac (Thomas Kuehne) * install header and libnewt.pc with shared library (Michael Olbrich) ==== poppler ==== Version update (22.11.0 -> 22.12.0) Subpackages: libpoppler-cpp0 libpoppler-glib8 poppler-tools - The development compiler in SLE 15 has been updated to gcc12 via maintenance update. Therefore adjusting the compiler version for SLE 15 in the spec file, to not build with gcc11 anymore. This resolves bsc#1206019 - update to 22.12.0: core: * Form::addFontToDefaultResources: Be stubborn in finding a font we can use. Issue #1272 ==== poppler-qt5 ==== Version update (22.11.0 -> 22.12.0) - The development compiler in SLE 15 has been updated to gcc12 via maintenance update. Therefore adjusting the compiler version for SLE 15 in the spec file, to not build with gcc11 anymore. This resolves bsc#1206019 - update to 22.12.0: core: * Form::addFontToDefaultResources: Be stubborn in finding a font we can use. Issue #1272 ==== python-pygit2 ==== Version update (1.10.1 -> 1.11.1) - Update to version 1.11.1 (2022-11-09) * Fix Linux wheels, downgrade to manylinux 2_24 #1176 * Windows wheels for Python 3.11 #1177 * CI: Use 3.11 final release for testing #1178 * Drop support for Python 3.7 * Update Linux wheels to manylinux 2_28 #1136 * Fix crash in signature representation #1162 * Fix memory leak in Signature #1173 * New optional argument raise_error in Repository.applies(...) #1166 * New notify/progress callbacks for checkout and stash #1167 #1169 * New Repository.remotes.names() #1159 * Now refname argument in RemoteCallbacks.push_update_reference(...) is a string, not bytes #1168 * Add missing newline at end of pygit2/decl/pack.h #1163 ==== qpdf ==== Version update (11.1.1 -> 11.2.0) - update to 11.2.0: * Move stream creation functions in the QPDF object where they belong. The ones in QPDFObjectHandle are not deprecated and will stick around. * Add some convenience methods to QPDFTokenizer::Token for testing token types. This is part of qpdfâs lexical layer and will not be needed by most developers. * Fix issue with missing symbols in the mingw build. * Fix major performance bug with the OpenSSL crypto provider. This bug was causing a 6x to 12x slowdown for encrypted files when OpenSSL 3 was in use. This includes the default Windows builds distributed with the qpdf release. * Fix obscure bug involving appended files that reuse an object number that was used as a cross reference stream in an earlier stage of the file. ==== sunpinyin ==== Subpackages: libsunpinyin3 sunpinyin-data - Remove unneeded BuildRequires on Python 2. ==== vhba-kmp ==== - BuildRequire %kernel_module_package_buildreqs (boo#1205149) ==== virt-what ==== Version update (1.21 -> 1.25) - update to 1.25: * detect AWS arm virtual instance as kvm * google-cloud: Print "kvm" fact on aarch64 instances * illumos-lx: Fix test so it works under virtualization * Detect Illumos (SmartOS/OmniOS) LX virtualization * Add detection of Red Hat's hypervisor * Display kvm/qemu fact for Nutanix AHV * Add support for Alibaba Cloud Linux * Add support for VMware ESXi on ARM * aws: Match multi-digit version number in BIOS information

1 0

Fwd: Undeliverable: Re: tcp mss clamping or ... ?
by L A Walsh 06 Dec '22

06 Dec '22

Anyone else getting these bounces -- looks like a misconfiguration somewhere? -------- Original Message -------- Subject: Undeliverable: Re: tcp mss clamping or ... ? Date: Tue, 29 Nov 2022 20:09:28 +0000 From: <postmaster(a)outlook.com> To: <suse(a)tlinx.org> References: <6385568C.6040308(a)tlinx.org> <CAMRG9HjAtDrBf9qN_o+8ZF_wEVXatuF0jFdRsL2=6Jqq4H+a7Q(a)mail.gmail.com> <638666DD.4020000(a)tlinx.org> *Delivery has failed to these recipients or groups:* amdlnx60(a)googlemail.com <mailto:amdlnx60@googlemail.com> Your message wasn't delivered because the recipient's email provider rejected it. *Diagnostic information for administrators:* Generating server: GV1P251MB0793.EURP251.PROD.OUTLOOK.COM amdlnx60(a)googlemail.com Remote Server returned '550-5.7.26 This message does not pass authentication checks (SPF and DKIM both 550-5.7.26 do not pass). SPF check for [tlinx.org] does not pass with ip: 550-5.7.26 [2a01:111:f400:7e0e::200].To best protect our users from spam, the 550-5.7.26 message has been blocked. Please visit 550-5.7.26 https://support.google.com/mail/answer/81126#authentication for more 550 5.7.26 information. z12-20020a056402274c00b0046afd9f07b0si8389199edd.14 - gsmtp' Original message headers: Received: from DB9P251MB0545.EURP251.PROD.OUTLOOK.COM (2603:10a6:10:336::16) by GV1P251MB0793.EURP251.PROD.OUTLOOK.COM (2603:10a6:150:50::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5834.15; Tue, 29 Nov 2022 20:09:26 +0000 Resent-From: <ppapen(a)hotmail.de> Received: from DB9P251MB0545.EURP251.PROD.OUTLOOK.COM ([::1]) by DB9P251MB0545.EURP251.PROD.OUTLOOK.COM ([fe80::278b:12f7:6b32:45dd%9]) with Microsoft SMTP Server id 15.20.5857.023; Tue, 29 Nov 2022 20:09:26 +0000 Authentication-Results: spf=pass (sender IP is 195.135.221.145) smtp.mailfrom=lists.opensuse.org; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=tlinx.org; Received-SPF: Pass (protection.outlook.com: domain of lists.opensuse.org designates 195.135.221.145 as permitted sender) receiver=protection.outlook.com; client-ip=195.135.221.145; helo=anna.opensuse.org; pr=C X-IncomingTopHeaderMarker: OriginalChecksum:B690860E3801DD1AABD7FDBE95586F50F5F0CC41A7D78CB4263EAE5C9DCC9896;UpperCasedChecksum:A718C217E7D5BF699F6077A0C83DC8C068CFCFCE4C5C1C5F2EF76F46998EC458;SizeAsReceived:3299;Count:36 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mx1.infra.opensuse.org X-Spam-Level: X-Spam-Status: No, score=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI, RCVD_IN_ZEN_BLOCKED_OPENDNS,SPF_HELO_NONE,URIBL_DBL_BLOCKED_OPENDNS, URIBL_ZEN_BLOCKED_OPENDNS autolearn=disabled version=3.4.5 X-Spam-Virus: No Message-ID: <638666DD.4020000(a)tlinx.org> Date: Tue, 29 Nov 2022 12:09:01 -0800 From: L A Walsh <suse(a)tlinx.org> User-Agent: Thunderbird MIME-Version: 1.0 To: Erwin Van de Velde <erwin.vandevelde(a)gmail.com> Subject: Re: tcp mss clamping or ... ? References: <6385568C.6040308(a)tlinx.org> <CAMRG9HjAtDrBf9qN_o+8ZF_wEVXatuF0jFdRsL2=6Jqq4H+a7Q(a)mail.gmail.com> In-Reply-To: <CAMRG9HjAtDrBf9qN_o+8ZF_wEVXatuF0jFdRsL2=6Jqq4H+a7Q(a)mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: FJHSAAV5NKVRS4TSSZDY46BKEZDH7HIG X-Message-ID-Hash: FJHSAAV5NKVRS4TSSZDY46BKEZDH7HIG X-MailFrom: SRS0=sw8Z=35=tlinx.org=suse(a)opensuse.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; header-match-config-2; header-match-config-3; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: oS-fctry <opensuse-factory(a)opensuse.org> X-Mailman-Version: 3.3.6 Precedence: list List-Id: Discussions about the development of the openSUSE distributions <factory.lists.opensuse.org> Archived-At: <https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message…> List-Archive: <https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/> List-Help: <mailto:factory-request@lists.opensuse.org?subject=help> List-Owner: <mailto:factory-owner@lists.opensuse.org> List-Post: <mailto:factory@lists.opensuse.org> List-Subscribe: <mailto:factory-join@lists.opensuse.org> List-Unsubscribe: <mailto:factory-leave@lists.opensuse.org> X-IncomingHeaderCount: 36 Return-Path: suse(a)tlinx.org X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: HE1EUR04FT063:EE_|DB9P251MB0476:EE_|DB9P251MB0545:EE_|GV1P251MB0793:EE_ X-MS-Office365-Filtering-Correlation-Id: 96c91591-c82f-4ddb-1d56-08dad2459cca X-MS-Exchange-EOPDirect: true X-Sender-IP: 195.135.221.145 X-SID-PRA: SUSE(a)TLINX.ORG X-SID-Result: NONE X-Microsoft-Antispam: BCL:0; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Nov 2022 20:09:25.0633 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 96c91591-c82f-4ddb-1d56-08dad2459cca X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: HE1EUR04FT063.eop-eur04.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P251MB0476 X-MS-Exchange-Transport-EndToEndLatency: 00:00:01.1991091 X-MS-Exchange-Processed-By-BccFoldering: 15.20.5857.023 X-MS-Exchange-Inbox-Rules-Loop: ppapen(a)hotmail.de X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-00b75.templateTenant UmVwb3J0aW5nLU1UQTogZG5zO0dWMVAyNTFNQjA3OTMuRVVSUDI1MS5QUk9ELk9VVExPT0su Q09NDQpSZWNlaXZlZC1Gcm9tLU1UQTogZG5zO0RCOVAyNTFNQjA1NDUuRVVSUDI1MS5QUk9E Lk9VVExPT0suQ09NDQpBcnJpdmFsLURhdGU6IFR1ZSwgMjkgTm92IDIwMjIgMjA6MDk6MjYg KzAwMDANCg0KRmluYWwtUmVjaXBpZW50OiByZmM4MjI7YW1kbG54NjBAZ29vZ2xlbWFpbC5j b20NCkFjdGlvbjogZmFpbGVkDQpTdGF0dXM6IDUuNy4yNg0KRGlhZ25vc3RpYy1Db2RlOiBz bXRwOzU1MC01LjcuMjYgVGhpcyBtZXNzYWdlIGRvZXMgbm90IHBhc3MgYXV0aGVudGljYXRp b24gY2hlY2tzIChTUEYgYW5kIERLSU0gYm90aA0KIDU1MC01LjcuMjYgZG8gbm90IHBhc3Mp LiBTUEYgY2hlY2sgZm9yIFt0bGlueC5vcmddIGRvZXMgbm90IHBhc3Mgd2l0aCBpcDoNCiA1 NTAtNS43LjI2IFsyYTAxOjExMTpmNDAwOjdlMGU6OjIwMF0uVG8gYmVzdCBwcm90ZWN0IG91 ciB1c2VycyBmcm9tIHNwYW0sIHRoZQ0KIDU1MC01LjcuMjYgbWVzc2FnZSBoYXMgYmVlbiBi bG9ja2VkLiBQbGVhc2UgdmlzaXQNCiA1NTAtNS43LjI2ICBodHRwczovL3N1cHBvcnQuZ29v Z2xlLmNvbS9tYWlsL2Fuc3dlci84MTEyNiNhdXRoZW50aWNhdGlvbiBmb3IgbW9yZQ0KIDU1 MCA1LjcuMjYgaW5mb3JtYXRpb24uIHoxMi0yMDAyMGEwNTY0MDIyNzRjMDBiMDA0NmFmZDlm MDdiMHNpODM4OTE5OWVkZC4xNCAtIGdzbXRwDQoNCg0K

7 7

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 December 2022