Am 10.02.19 um 18:58 schrieb Christian Mahr:

Hi

I am using vdr 2.4.0 from  obs://build.opensuse.org/vdr . Today I saw a new version vdr-2.4.0-153.6 which seems not to install because of a missing glibc 2.28

You shouldn't use the openSUSE_Factory repository, but openSUSE_Tumbleweed. Greetings, Stephan -- Lighten up, just enjoy life, smile more, laugh more, and don't get so worked up about things. Kenneth Branagh -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 10.02.19 um 20:48 schrieb Christian Mahr:

Hi Stephan

well, yes, but tumbleweed has only vdr 2.2, not 2.4...  - which is out already since April 2018...?

seife@strolchi:~> osc meta prj vdr|grep -B1 '"openSUSE:Factory"' <repository name="openSUSE_Tumbleweed"> <path project="openSUSE:Factory" repository="snapshot"/> -- <repository name="openSUSE_Factory"> <path project="openSUSE:Factory" repository="standard"/> seife@strolchi:~> osc rblt vdr vdr openSUSE_Tumbleweed x86_64|tail [ 225s] RPMS/x86_64/vdr-debugsource-2.4.0-153.3.x86_64.rpm [ 225s] RPMS/x86_64/vdr-debuginfo-2.4.0-153.3.x86_64.rpm [ 225s] RPMS/x86_64/vdr-devel-2.4.0-153.3.x86_64.rpm [ 225s] RPMS/noarch/vdr-lang-2.4.0-153.3.noarch.rpm [ 225s] RPMS/noarch/vdr-devel-doc-2.4.0-153.3.noarch.rpm [ 225s] SRPMS/vdr-2.4.0-153.3.src.rpm [ 225s] OTHER/rpmlint.log [ 225s] OTHER/_statistics The openSUSE_Tumbleweed build of the vdr repo certainly has vdr 2.4.0 But you will not gain anything from this update, because the only change is a rebuild due to changed glibc: seife@strolchi:~> osc triggerreason vdr vdr openSUSE_Factory i586 https://api.opensuse.org vdr vdr openSUSE_Factory i586 meta change (at 2019-02-08 20:20:57) changed keys: md5sum glibc-devel md5sum glibc-locale added glibc-locale-base added libcrypt1 added libxcrypt-devel seife@strolchi:~> osc buildhist vdr vdr openSUSE_Factory i586|tail -6 2018-12-29 21:51:40 b390929cc0c4d282c8e13d67c456b48b 2.4.0-153.1 136 288 2019-01-15 14:51:04 b390929cc0c4d282c8e13d67c456b48b 2.4.0-153.2 136 475 2019-01-29 19:06:18 b390929cc0c4d282c8e13d67c456b48b 2.4.0-153.3 136 219 2019-01-30 08:42:21 b390929cc0c4d282c8e13d67c456b48b 2.4.0-153.4 136 283 2019-02-08 18:22:29 b390929cc0c4d282c8e13d67c456b48b 2.4.0-153.5 136 309 2019-02-08 20:28:20 b390929cc0c4d282c8e13d67c456b48b 2.4.0-153.6 136 414 => no source changes. But good thing is that you remind me to finally submit the updated vdr stuff to Factory ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

PS: I copied the source for vdr-plugin-vdrmanager from https://projects.vdr-developer.org/git/vdr-manager.git/ and manually compiled and manually installed it it works (compilation with some warnings, vdr startup warning for missing SSL) :-) Actually I have no idea how to create an updated package for the distribution .... best regards Christian Am 10.02.19 um 22:03 schrieb Christian Mahr:

Hi Stephan

OK, you are rigth. thank for the hint. I added the https://download.opensuse.org/repositories/vdr/openSUSE_Tumbleweed/ and removed the ...._Factory. I downgraded all relevant packages to slightly earlier version - to clean up. vdr 2.4 is present and works.

Now I tried to add ans additional plugin:  vdr-plugin-vdrmanager:

-------------

Problem: vdr-plugin-vdrmanager-0.12-3.26.x86_64 requires vdr(abi) = 2.2.0, but this requirement cannot be provided   not installable providers: vdr-2.2.0-6.2.i586[openSUSE-20180410-0]                    vdr-2.2.0-6.2.x86_64[openSUSE-20180410-0]                    vdr-2.2.0-7.1.x86_64[openSUSE-Leap_42.3-0]  Solution 1: Following actions will be done:   downgrade of vdr-2.4.0-153.3.x86_64 to vdr-2.2.0-6.2.x86_64   install vdr-2.2.0-6.2.x86_64 (with vendor change)     obs://build.opensuse.org/vdr  -->  openSUSE   deinstallation of vdr-plugin-vnsiserver-1.8.0-1.4.x86_64   downgrade of vdr-devel-2.4.0-153.3.x86_64 to vdr-devel-2.2.0-6.2.x86_64   install vdr-devel-2.2.0-6.2.x86_64 (with vendor change)     obs://build.opensuse.org/vdr  -->  openSUSE   downgrade of vdr-lang-2.4.0-153.3.noarch to vdr-lang-2.2.0-6.2.noarch   install vdr-lang-2.2.0-6.2.noarch (with vendor change)     obs://build.opensuse.org/vdr  -->  openSUSE  Solution 2: do not install vdr-plugin-vdrmanager-0.12-3.26.x86_64  Solution 3: break vdr-plugin-vdrmanager-0.12-3.26.x86_64 by ignoring some of its dependencies

----

Although taken from vdr:plugin/openSuse-Tumbleweed, this plugin asks for a downgrade to vdr-2.2 ..???

Is this really correct? any suggestion?

Thanks

    Christian

Am 10.02.19 um 21:10 schrieb Stefan Seyfried:

...

Am 10.02.19 um 20:48 schrieb Christian Mahr:

...

Hi Stephan

well, yes, but tumbleweed has only vdr 2.2, not 2.4...  - which is out already since April 2018...? seife@strolchi:~> osc meta prj vdr|grep -B1 '"openSUSE:Factory"'    <repository name="openSUSE_Tumbleweed">      <path project="openSUSE:Factory" repository="snapshot"/> --    <repository name="openSUSE_Factory">      <path project="openSUSE:Factory" repository="standard"/> seife@strolchi:~> osc rblt vdr vdr openSUSE_Tumbleweed x86_64|tail [  225s] RPMS/x86_64/vdr-debugsource-2.4.0-153.3.x86_64.rpm [  225s] RPMS/x86_64/vdr-debuginfo-2.4.0-153.3.x86_64.rpm [  225s] RPMS/x86_64/vdr-devel-2.4.0-153.3.x86_64.rpm [  225s] RPMS/noarch/vdr-lang-2.4.0-153.3.noarch.rpm [  225s] RPMS/noarch/vdr-devel-doc-2.4.0-153.3.noarch.rpm [  225s] SRPMS/vdr-2.4.0-153.3.src.rpm [  225s] OTHER/rpmlint.log [  225s] OTHER/_statistics

The openSUSE_Tumbleweed build of the vdr repo certainly has vdr 2.4.0

But you will not gain anything from this update, because the only change is a rebuild due to changed glibc:

seife@strolchi:~> osc triggerreason vdr vdr openSUSE_Factory i586 https://api.opensuse.org vdr vdr openSUSE_Factory i586 meta change (at 2019-02-08 20:20:57) changed keys:     md5sum glibc-devel     md5sum glibc-locale     added glibc-locale-base     added libcrypt1     added libxcrypt-devel

seife@strolchi:~> osc buildhist vdr vdr openSUSE_Factory i586|tail -6 2018-12-29 21:51:40 b390929cc0c4d282c8e13d67c456b48b 2.4.0-153.1 136 288 2019-01-15 14:51:04 b390929cc0c4d282c8e13d67c456b48b 2.4.0-153.2 136 475 2019-01-29 19:06:18 b390929cc0c4d282c8e13d67c456b48b 2.4.0-153.3 136 219 2019-01-30 08:42:21 b390929cc0c4d282c8e13d67c456b48b 2.4.0-153.4 136 283 2019-02-08 18:22:29 b390929cc0c4d282c8e13d67c456b48b 2.4.0-153.5 136 309 2019-02-08 20:28:20 b390929cc0c4d282c8e13d67c456b48b 2.4.0-153.6 136 414

=> no source changes.

But good thing is that you remind me to finally submit the updated vdr stuff to Factory ;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Stephan Well I am not sure wether vdrmanager or androvdr  is the better App. On the computer I use lazybones and vdr-admin-am to handle timers. So I  am still searching for the most convient way to control a headless vdr  (for watching I use Kodi on libreelec) ... from my PS: you need not search long for the build problems. I copied the source for vdr-plugin-vdrmanager from https://projects.vdr-developer.org/git/vdr-manager.git/ latest version and manually compiled and manually installed it. it works (compilation with some warnings, vdr startup warning for missing SSL...) - so maybe the update to vdr 2.4 compatibilty is straigthforward? best regards Christian Am 11.02.19 um 09:32 schrieb Stefan Seyfried:

Am 10.02.19 um 22:03 schrieb Christian Mahr:

...

Hi Stephan

OK, you are rigth. thank for the hint. I added the https://download.opensuse.org/repositories/vdr/openSUSE_Tumbleweed/ and removed the ...._Factory. I downgraded all relevant packages to slightly earlier version - to clean up. vdr 2.4 is present and works.

Now I tried to add ans additional plugin:  vdr-plugin-vdrmanager:

-------------

Problem: vdr-plugin-vdrmanager-0.12-3.26.x86_64 requires vdr(abi) = 2.2.0, but this requirement cannot be provided   not installable providers: vdr-2.2.0-6.2.i586[openSUSE-20180410-0]                    vdr-2.2.0-6.2.x86_64[openSUSE-20180410-0]                    vdr-2.2.0-7.1.x86_64[openSUSE-Leap_42.3-0] That's because it does not build for vdr-2.4. Neiter in /..._Tumbleweed, nor for ..._Factory, so nothing changed.

I could not imagine that someone actually uses this, so have not investigated the build failure yet. It was actually on my list to get removed, but if someone uses it... ;-)

Note that everything in vdr:plugins is totally unsupported (at least by me).

...

Although taken from vdr:plugin/openSuse-Tumbleweed, this plugin asks for a downgrade to vdr-2.2 ..???

Is this really correct? any suggestion?-- Stefan Seyfried

"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 11/02/2019 07:28, Bruno Friedmann wrote:

On dimanche, 10 février 2019 09.43:03 h CET Stephan Kulow wrote:

...

Hi,

The latest snapshot has built with glibc 2.29 and ruby 2.6 (and hopefully a good enough fix for netconfig), but as it hit openQA, too many problems appear.

https://openqa.opensuse.org/group_overview/1 shows > 60 failures and among things that are kind of expected (e.g. there was an update of the GNOME theme, which does not help openQA), all network installations fail to detect the installation source.

So this will need to be debugged before we can continue with releasing snapshots.

Greetings, Stephan

Thanks for the heads up, Coolo.

Am I the only victim of big chunks of changes ?

I'm still waiting an update (one for security reason, the other for the shake of all the goodness PostgreSQL 11 would bring to us)

https://build.opensuse.org/request/show/651973 since 3 months ago as PostgreSQL dba, we live naked !

https://build.opensuse.org/request/show/669145 which more recent (13 days) but a superseed of the 3 month https://build.opensuse.org/request/show/653551

If someone can provide an explanation about why we are not able to provide security first fix, in place of major upgrade which are known to stalled snapshot delivery, I would be really thanksfull to him(her), I always want to learn about our process.

And yes I've tried all that I can to contact directly maintainers to make it happen, before expressing this mail (that I can understand could look like a rumble), but hell the next PostgreSQL release will happen in a few weeks afterwards ;-)

In this issue there's a comment in the SR explaining "In order to get the CVE fix in, we should have a pgsql10 submission that does not rely on the libs being built by pgsql11 - since not everything builds with pgsql11 yet, we can't perform the switch" In general for significant security fixes we have the ability to push an update to the update repo without releasing a new snapshot. This is less then ideal so it only gets done if openQA is properly broken and the issue is significant. IE if there was another shellshock style vulnerability disclosed tomorrow we can still release a fix even with openQA in a bad state. Ideally the package would just have 1-2 patches containing the fix and wouldn't be a new feature release. -- 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