New Tumbleweed snapshot 20210908 released!
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&version=Tumbleweed&build=20210908 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: chrony fuse3 (3.10.4 -> 3.10.5) glslang (11.5.0 -> 11.6.0) gnome-shell-extensions grub2 json-glib (1.6.4 -> 1.6.6) libstorage-ng (4.4.35 -> 4.4.36) man-pages (5.12 -> 5.13) mdadm mpg123 (1.28.2 -> 1.29.0) pinentry (1.1.1 -> 1.2.0) transactional-update (3.5.2 -> 3.5.3) vulkan-loader (1.2.182.0 -> 1.2.189.0) xdg-utils (1.1.3+20200220 -> 1.1.3+20201113) yast2 (4.4.16 -> 4.4.17) === Details === ==== chrony ==== Subpackages: chrony-pool-openSUSE - Added hardening to systemd service(s). Added patch(es): * harden_chrony-wait.service.patch * harden_chronyd.service.patch ==== fuse3 ==== Version update (3.10.4 -> 3.10.5) Subpackages: libfuse3-3 - Update to release 3.10.5 * Various improvements to make unit tests more robust. ==== glslang ==== Version update (11.5.0 -> 11.6.0) - Update to release 11.6.0 * Atomic memory function only for shader storage block member or shared variable * Add support for gl_MaxVaryingVectors for ogl * Fix loading bool arrays from interface blocks * Generate separate stores for partially swizzled memory stores * Allow layout(std430) uniform with GL_EXT_scalar_block_layout * Support for pragma STDGL invariant(all) * Support for GL_NV_ray_tracing_motion_blur ==== gnome-shell-extensions ==== - Add dependency on gnome-shell-extensions-common for gnome-shell-classic to fix the translations in SLE Classic and GNOME Classic(bsc#1190016 jsc#SLE-20311). ==== grub2 ==== Subpackages: grub2-i386-pc grub2-snapper-plugin grub2-systemd-sleep-plugin grub2-x86_64-efi grub2-x86_64-xen - Follow usr merge for looking up kernel config (bsc#1189782) (bsc#1190061) * 0001-templates-Follow-the-path-of-usr-merged-kernel-confi.patch - Add btrfs zstd compression on i386-pc and also make sure it won't break existing grub installations (bsc#1161823) * deleted 0001-btrfs-disable-zstd-support-for-i386-pc.patch * added 0001-i386-pc-build-btrfs-zstd-support-into-separate-modul.patch - Delete the author list from %description (the %description section is literally for package descriptions (only) these days, encoding was also problematic). - Add %doc AUTHORS to get packaged that info ==== json-glib ==== Version update (1.6.4 -> 1.6.6) Subpackages: json-glib-lang libjson-glib-1_0-0 typelib-1_0-Json-1_0 - Update to version 1.6.6: + New release with the documentation and gi-docgen included in the archive. - Drop gtk-doc BuildRequires, no longer needed, nor used. - Add docbook-xsl-stylesheets and libxslt-tools BuildRequires, needed for building of manpages. ==== libstorage-ng ==== Version update (4.4.35 -> 4.4.36) Subpackages: libstorage-ng-lang libstorage-ng-ruby libstorage-ng1 - Translated using Weblate (Indonesian) (bsc#1149754) - 4.4.36 ==== man-pages ==== Version update (5.12 -> 5.13) - version update to 5.13 [bsc#1189908] http://linux-man-pages.blogspot.com/2021/06/man-pages-512-released.html ==== mdadm ==== - Remove Spare drives line from details for external metadata (bsc#1180661, bsc#1182642) 0118-Remove-Spare-drives-line-from-details-for-external-m.patch - Don't associate spares with other arrays during RAID Examine (bsc#1180661, bsc#1182642) 0119-Don-t-associate-spares-with-other-arrays-during-RAID.patch ==== mpg123 ==== Version update (1.28.2 -> 1.29.0) Subpackages: libmpg123-0 mpg123-openal - Update to version 1.29.0 build: * added --enable-runtime-tables libmpg123: * Float deocder runtime table computation is back as option, based on suggestion and initial patch by Ethan Halsall for a smaller download size of the wasm decoder built from libmpg23. This only trims the size of the binary on disk (network), for runtime overhead and a bit of uneasyness about concurrency during table computation, which happens implicitly on handle initialization, only guarded by an integer flag. This does _not_ revive mpg123_init(). * The ID3v2 UTF-16 BOM check is now a straight-on loop and not a recursive function. ==== pinentry ==== Version update (1.1.1 -> 1.2.0) Subpackages: pinentry-gnome3 pinentry-gtk2 pinentry-qt5 - pinentry 1.2.0: * qt: Show a warning if Caps Lock is on * qt: Support password formatting. This makes generated passwords easier to transcribe * qt: Fix showing of pinentry window on Wayland * qt: Check passphrase constraints before accepting passphrase if passphrase constraints are requested to be enforced * qt: Improve detection of running in a GUI session * qt: Improve accessibility when entering new password ==== transactional-update ==== Version update (3.5.2 -> 3.5.3) Subpackages: dracut-transactional-update libtukit0 transactional-update-zypp-config tukit - Version 3.5.3 - t-u: Purge kernels as part of package operations Required for live patching support [bsc#1189728] ==== vulkan-loader ==== Version update (1.2.182.0 -> 1.2.189.0) - Update to release SDK-1.2.189.0 * loader: Dont return OOM on function load failure * Deallocate the extension lists when deleting an item from layer list * Add layer and implementation-specific logging * Allow "icd" as well as "implem" for VK_LOADER_DEBUG * Fix Vulkan CTS testcase bug: "create_instance_device_intentional_alloc_fail" * loader: Fix accidental error propagation ==== xdg-utils ==== Version update (1.1.3+20200220 -> 1.1.3+20201113) - Update to version 1.1.3+20201113: * Fix xdg-settings support for default-web-browser for Plasma 5.19+ ==== yast2 ==== Version update (4.4.16 -> 4.4.17) Subpackages: yast2-logs - Mark systemd unit/service state "maintenance" as active (bsc#1190163) - 4.4.17
I have a question about the date listed in the subject. If I look at the repomd.xml file in oss/repodata, on dl.os.org, I see a timestamp of 09-Sep-2021 13:48 (i.e. 20210909 , not 20210908). Looking inside that file I see the cpeid having a value of 20210907! Looking at the time the message was sent, that gives me a 4th date of 20210910. Why are there 4 dates associated with the release(s) that go out? internal date: 0907 title date (in message) 0908 file date: 0909 actual message date 0910. So why don't any of them agree? Shouldn't at least there be any/some agreeance? ---- Now tell me how this wasn't trimmed, and didn't have the wrong subject (except)
On 9/15/21 08:04, L A Walsh wrote:
I have a question about the date listed in the subject.
If I look at the repomd.xml file in oss/repodata, on dl.os.org, I see a timestamp of 09-Sep-2021 13:48 (i.e. 20210909 , not 20210908).
Looking inside that file I see the cpeid having a value of 20210907!
Looking at the time the message was sent, that gives me a 4th date of 20210910.
Why are there 4 dates associated with the release(s) that go out?
internal date: 0907 title date (in message) 0908 file date: 0909 actual message date 0910.
So why don't any of them agree? Shouldn't at least there be any/some agreeance?
---- Now tell me how this wasn't trimmed, and didn't have the wrong subject (except)
Well Tumbleweed snapshot dates would be a much better subject, given that your email isn't specific to this email but all snapshot emails. An understanding of the process will help you here, There are multiple "staging" where packages are built and tested individually or in groups. Once a day all the packages from statings that have passed are grouped into one "snapshot", this is where me title in the message comes from. This combined snapshot then goes through QA and is only pushed to mirrors if it passes QA this is why the "file date" could be later then the snapshot date due to the time it takes to do QA. Then I presume we wait for all the files to upload and then give some time for mirrors to sync before sending the email otherwise downloads are really slow because large number of people fetch it from the primary mirror. As for the "Internal date" depending on a staging and which other packages are also in the same staging project it may take anywhere from 1 hr to several weeks (in extreme cases) for a package to pass staging so the internal date is probably some reflection on when a packager submitted the package to tumbleweed but sometimes stuff gets moved or rebuilt so it wouldn't be 100% accurate. But in summary getting a new package to users is generally a multi day process and so you wind up with various dates depending on which part of the process you look at but we consider the date in the email to be the unique identifier for each snapshot. Cheers -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 2021/09/14 17:57, Simon Lees wrote:
But in summary getting a new package to users is generally a multi day process and so you wind up with various dates depending on which part of the process you look at but we consider the date in the email to be the unique identifier for each snapshot.
--- And where in the release is that date recorded? The cpeid date is the only date recorded in a release, so any tool that looks at the release only has that date available. Yet from what you say, the date on the email is somewhat unrelated to the version date listed inside the "repomd.xml" file. Usually, if you run a program, there is often a version option to display the current version -- but that comes from within the object. Anyone looking at one of the releases on a DVD won't necessarily have the release email, but they will have the date that is internal to repomd.xml. Is there anyway the release date could be gleaned from the repomd.xml to be used as the date in the repo release notification? This could be shorter as you don't need the primary.xml filename, but, a parse script like: # find TW data in repomd file; first only cpeid-date, # but 2nd parm as HASH of wanted dats as pointers to answer buffs # 2nd parameter is hash; currently only 1 useful item # 1) "primary_locp" - a pointer to the name of # the primary file for this repomd file sub find_repo_data($;$) { my $p = shift; my $repomd_file = shift; # alternate data pointers my $altdp = @_ ? HASH shift : {}; my $num_altdp = 0+@{[keys %$altdp]}; my ($primary_locp, $distro_date); #TPe "RD:%s)",$repomd_file; open(my $repo_h, "<", $repomd_file) || die P "Err $! opening %s", $repomd_file; while(defined($_=<$repo_h>)) { chomp; if (m{^\s+<distro cpeid="[^"]+?:(\d{8})">}) { $distro_date=$1; #TPe "got cpeid($1)"; last unless $altdp; } elsif ($primary_locp = $altdp->{primary_locp} and m{<location href="(repo[^"]+primary\.xml\.gz)"}) { $$primary_locp = $1; last unless --$num_altdp; } } $distro_date; # returns undef if no date } # find TW cust product engid (date) (only works for TW) sub get_tw_cpeid($) { my $p = shift; $p->find_repo_data($_[0]); } Wouldn't be hard to syncronize the email date w/the internal date
On 9/15/21 11:09, L A Walsh wrote:
On 2021/09/14 17:57, Simon Lees wrote:
But in summary getting a new package to users is generally a multi day process and so you wind up with various dates depending on which part of the process you look at but we consider the date in the email to be the unique identifier for each snapshot.
--- And where in the release is that date recorded?
Currently its recorded as the "VERSION_ID" in "/etc/os-release" which is installed as part of the openSUSE-Release package and is also the version number of this package. So ass you can see from the perspective of an updated filesystem this is the version number we reference. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 9/15/21 08:04, L A Walsh wrote:
I have a question about the date listed in the subject.
If I look at the repomd.xml file in oss/repodata, on dl.os.org, I see a timestamp of 09-Sep-2021 13:48 (i.e. 20210909 , not 20210908).
Looking inside that file I see the cpeid having a value of 20210907!
I do not know what file you are looking at, but if I look inside repomd.xml of Tumbleweed snapshot 20210908 I see date 20210908. http://download.opensuse.org/history/20210908/tumbleweed/repo/oss/repodata/r...
On 15.09.21 07:43, Andrei Borzenkov wrote:
I do not know what file you are looking at, but if I look inside repomd.xml of Tumbleweed snapshot 20210908 I see date 20210908.
http://download.opensuse.org/history/20210908/tumbleweed/repo/oss/repodata/r...
But the *file date* of that repomd.xml is 2021-09-09, so if you *really* want to, you can of course misinterpret that ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On 2021/09/14 22:43, Andrei Borzenkov wrote:
On 9/15/21 08:04, L A Walsh wrote:
I have a question about the date listed in the subject.
If I look at the repomd.xml file in oss/repodata, on dl.os.org, I see a timestamp of 09-Sep-2021 13:48 (i.e. 20210909 , not 20210908).
Looking inside that file I see the cpeid having a value of 20210907!
I do not know what file you are looking at, but if I look inside repomd.xml of Tumbleweed snapshot 20210908 I see date 20210908.
But that's not the repomd.xml that was at download.opensuse.org/tumbleweed/repo/oss/repodata/repomd.xml after her announcement -- that's part of the problem -- her announcement proceeds that file being updated. http://download.opensuse.org/history/20210908/tumbleweed/repo/oss/repodata/r... The file you get from 'history' shows a last-mod date of 20210909, which seems to indicate it wasn't put in place until the day after the release announcement. I've been taking her release announcement as being what's available at http:download.opensuse.org/tumbleweed/repo/oss/repodata/repomd.xml (as I thought that was the current release). I hadn't thought of use 'history/date' to download the current release (until you just now mentioned it). I'll have to watch, but would have thought when she announced "X", that was the version at 'current' (download.opensuse.org/tumbleweed/repo/oss/repodata/repomd.xml) and wouldn't expect current to show up in 'history' until the next current is announded (at which time what was 'current' became 'history'). Though I see that having no release yet announced for the 14th, the release for the 13th is in(at) both 'current' and the 0913 history URL. Does (or will) the release being announced, appear in history at the same time? It seems like it appears a day later, given the filemod time. I.e. the file with the 0913 date in the cpeid field has a last mod date of 0914.
On 16.09.21 04:24, L A Walsh wrote:
http://download.opensuse.org/history/20210908/tumbleweed/repo/oss/repodata/r...
The file you get from 'history' shows a last-mod date of 20210909, which seems to indicate it wasn't put in place until the day after the release announcement. Subject: New Tumbleweed snapshot 20210908 released! From: Dominique Leuenberger <dimstar@suse.de> To: factory@lists.opensuse.org Mail-Followup-To: factory@lists.opensuse.org Date: Fri, 10 Sep 2021 10:00:53 +0000 Message-ID: <163126805338.15681.9955158119170188019@go-agent-stagingbot-7>
Your perception of dates seems warped. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On 9/16/21 14:44, Stefan Seyfried wrote:
On 16.09.21 04:24, L A Walsh wrote:
http://download.opensuse.org/history/20210908/tumbleweed/repo/oss/repodata/r...
The file you get from 'history' shows a last-mod date of 20210909, which seems to indicate it wasn't put in place until the day after the release announcement. Subject: New Tumbleweed snapshot 20210908 released! From: Dominique Leuenberger <dimstar@suse.de> To: factory@lists.opensuse.org Mail-Followup-To: factory@lists.opensuse.org Date: Fri, 10 Sep 2021 10:00:53 +0000 Message-ID: <163126805338.15681.9955158119170188019@go-agent-stagingbot-7>
Your perception of dates seems warped.
Well ones perspective of date and time is always relative to where they are in the world as well as whether the time and date being specified are in there local time, server time or the time when they were created on the machine they were created on (there is a chance all 3 are going on here). -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Wed, 2021-09-15 at 19:24 -0700, L A Walsh wrote:
you just now mentioned it).
I'll have to watch, but would have thought when she announced "X", that was the version at 'current' (download.opensuse.org/tumbleweed/repo/oss/repodata/repomd.xml) and wouldn't expect current to show up in 'history' until the next current is announded (at which time what was 'current' became 'history'). Though I see that having no release yet announced for the 14th, the release for the 13th is in(at) both 'current' and the 0913 history URL.
The most relevant information you might be missing is that the 'snapshot release date' is the 'date, when the checkin round for said snapshot happened, i.e when I started building that snapshot'. So, currently, I am building snapshot 0915 (checkin of yesterday), 0914 is still in QA and likely to come out today) The checkin date is chosen as that is the date we can put into RPMs during build - at publish, we are way too late to inject dates and this would be terribly releasing something else than what was in QA before. The release announcement is generated at the time when the snapshot appears on download.o.o - which can be 'days' after it started building. Cheers, Dominique
On 2021/09/16 00:12, Dominique Leuenberger / DimStar wrote:
The most relevant information you might be missing is that the 'snapshot release date' is the 'date, when the checkin round for said snapshot happened,
==== Ok, that explains quite a bit. I wasn't parsing your subject as being the snapshot date, but as being the snapshot-release date, for example Snapshot#20210914 was released on 20210916(~4am PDT). and was wondering why a release dated 0914 wouldn't be released until 0916 -- but that's because it's the date the snapshot was taken. It was disconcerting in my own download process why, what appeared to be the latest download, was 2 days old. I'm zooming in on some details around my download process like wanting to know that the last-mod timestamps I'm seeing are correct. Seems to be the case despite over zealous spam processing (which isn't done by you, I understand)...I guess I'd still be a bit embarrassed by the poor implementation done in your name, but that's more just me -- and like how I get embarrassed when gmail does something flakey (as they don't follow mail-RFC's...*sigh*). thanks for the explanation, -linda
On Thu, Sep 16, 2021 at 5:25 AM L A Walsh <suse@tlinx.org> wrote:
On 2021/09/14 22:43, Andrei Borzenkov wrote:
On 9/15/21 08:04, L A Walsh wrote:
I have a question about the date listed in the subject.
If I look at the repomd.xml file in oss/repodata, on dl.os.org, I see a timestamp of 09-Sep-2021 13:48 (i.e. 20210909 , not 20210908).
Looking inside that file I see the cpeid having a value of 20210907!
I do not know what file you are looking at, but if I look inside repomd.xml of Tumbleweed snapshot 20210908 I see date 20210908.
But that's not the repomd.xml that was at download.opensuse.org/tumbleweed/repo/oss/repodata/repomd.xml after her announcement -- that's part of the problem -- her announcement proceeds that file being updated.
Most likely the mirror you happened to be using at this time was not fully updated yet.
participants (6)
-
Andrei Borzenkov -
Dominique Leuenberger -
Dominique Leuenberger / DimStar -
L A Walsh -
Simon Lees -
Stefan Seyfried