[opensuse-buildservice] Why does OBS think some packages are "unresolvable" while they are not?
Hi there, I've given up (I think) trying to understand why OBS sometimes behaves different than what I'd expect. Here is my (current) challenge: I'm trying to build firefox69 in my own project in home:manfred-h:mozilla. The repository metadata is set up as follows: $ osc meta prj home:manfred-h:mozilla <project name="home:manfred-h:mozilla"> <title>mozilla</title> <description> Mozilla based projects and support packages. </description> <person userid="manfred-h" role="maintainer"/> <build> <disable/> </build> <repository name="openSUSE_Leap_42.3"> <path project="home:manfred-h:devel:languages:rust" repository="openSUSE_Leap_42.3"/> <path project="mozilla" repository="openSUSE_Leap_42.3"/> <path project="openSUSE:Leap:42.3:Update" repository="standard"/> <path project="openSUSE:Leap:42.3" repository="standard"/> <arch>x86_64</arch> </repository> <repository name="openSUSE_Leap_15.1"> <path project="devel:languages:rust" repository="openSUSE_Leap_15.1"/> <path project="mozilla" repository="openSUSE_Leap_15.1"/> <path project="openSUSE:Leap:15.1:Update" repository="standard"/> <path project="openSUSE:Leap:15.1" repository="standard"/> <arch>x86_64</arch> </repository> <repository name="openSUSE_Leap_15.0"> <path project="home:manfred-h:devel:languages:rust" repository="openSUSE_Leap_15.0"/> <path project="mozilla" repository="openSUSE_Leap_15.0"/> <path project="openSUSE:Leap:15.0:Update" repository="standard"/> <path project="openSUSE:Leap:15.0" repository="standard"/> <arch>x86_64</arch> </repository> </project> As you can see, nothing should get build by default (this is enabled purely on a package by package case) and repositories are setup so that "rust" and related packages should be taken from - devel:languages:rust for openSUSE_Leap_15.1 - home:manfred-h:devel:languages:rust for 42.3 and 15.0 firefox69 now needs rust-cbindgen >= 0.9.0, so I copied that package to my home:manfred-h:devel:languages:rust as rust-cbindgen-0.9.0 and built it there successfully for openSUSE_Leap_42.3 and openSUSE_Leap_15.0 Still OBS thinks "nothing provides rust-cbindgen >= 0.9.0" for 15.0 and 42.3, but the packages are there: <https://build.opensuse.org/package/binary/home:manfred-h:devel:languages:rust/rust-cbindgen-0.9.0/openSUSE_Leap_15.0/x86_64/rust-cbindgen-0.9.0-lp150.1.1.x86_64.rpm> <https://build.opensuse.org/package/binary/home:manfred-h:devel:languages:rust/rust-cbindgen-0.9.0/openSUSE_Leap_42.3/x86_64/rust-cbindgen-0.9.0-1.1.x86_64.rpm> both providing: rust-cbindgen = 0.9.0-1.1 rust-cbindgen(x86-64) = 0.9.0-1.1 FWIW, as a last resort, I linked my rust-cbindgen-0.9.0 package to rust-cbindgen in the home:manfred-h:devel:languages:rust project, but this did not change anything unfortunately. Can anybody tell me what I'm doing wrong here? Or is this a bug in the OBS resolver? TIA, cheers. l8er manfred PS: No complaints wrt/ 42.3, I'm not yet done with migrating all systems I maintain to 15.1 yet! Therefore I'm trying to keep those packages still building which are not services but still as close to the Internet as possible, i.e. the _bad world_ ;)
On Freitag, 6. September 2019, 15:44:04 CEST Manfred Hollstein wrote:
Hi there,
I've given up (I think) trying to understand why OBS sometimes behaves different than what I'd expect.
Here is my (current) challenge:
I'm trying to build firefox69 in my own project in home:manfred-h:mozilla. The repository metadata is set up as follows:
$ osc meta prj home:manfred-h:mozilla <project name="home:manfred-h:mozilla"> <title>mozilla</title> <description> Mozilla based projects and support packages. </description> <person userid="manfred-h" role="maintainer"/> <build> <disable/> </build> <repository name="openSUSE_Leap_42.3"> <path project="home:manfred-h:devel:languages:rust" repository="openSUSE_Leap_42.3"/> <path project="mozilla" repository="openSUSE_Leap_42.3"/> <path project="openSUSE:Leap:42.3:Update" repository="standard"/> <path project="openSUSE:Leap:42.3" repository="standard"/> <arch>x86_64</arch> </repository> <repository name="openSUSE_Leap_15.1"> <path project="devel:languages:rust" repository="openSUSE_Leap_15.1"/> <path project="mozilla" repository="openSUSE_Leap_15.1"/> <path project="openSUSE:Leap:15.1:Update" repository="standard"/> <path project="openSUSE:Leap:15.1" repository="standard"/> <arch>x86_64</arch> </repository> <repository name="openSUSE_Leap_15.0"> <path project="home:manfred-h:devel:languages:rust" repository="openSUSE_Leap_15.0"/> <path project="mozilla" repository="openSUSE_Leap_15.0"/> <path project="openSUSE:Leap:15.0:Update" repository="standard"/> <path project="openSUSE:Leap:15.0" repository="standard"/> <arch>x86_64</arch> </repository> </project>
As you can see, nothing should get build by default (this is enabled purely on a package by package case) and repositories are setup so that "rust" and related packages should be taken from
- devel:languages:rust for openSUSE_Leap_15.1 - home:manfred-h:devel:languages:rust for 42.3 and 15.0
firefox69 now needs rust-cbindgen >= 0.9.0, so I copied that package to my home:manfred-h:devel:languages:rust as rust-cbindgen-0.9.0 and built it there successfully for openSUSE_Leap_42.3 and openSUSE_Leap_15.0
Still OBS thinks "nothing provides rust-cbindgen >= 0.9.0" for 15.0 and 42.3, but the packages are there:
<https://build.opensuse.org/package/binary/home:manfred-h:devel:languages:r ust/rust-cbindgen-0.9.0/openSUSE_Leap_15.0/x86_64/rust-cbindgen-0.9.0-lp150. 1.1.x86_64.rpm> <https://build.opensuse.org/package/binary/home:manfred-h:devel:languages:r ust/rust-cbindgen-0.9.0/openSUSE_Leap_42.3/x86_64/rust-cbindgen-0.9.0-1.1.x8 6_64.rpm>
both providing:
rust-cbindgen = 0.9.0-1.1 rust-cbindgen(x86-64) = 0.9.0-1.1
FWIW, as a last resort, I linked my rust-cbindgen-0.9.0 package to rust-cbindgen in the home:manfred-h:devel:languages:rust project, but this did not change anything unfortunately.
Can anybody tell me what I'm doing wrong here? Or is this a bug in the OBS resolver?
I don't see it unresolvable in home:manfred-h:mozilla, but blocked. please note that events between repos in different projects are handled with low prio. So it might take some time to see an effect. Use "osc buildinfo" to debug a dependency issue instead, it does a current evaluation. -- Adrian Schroeter <adrian@suse.de> Build Infrastructure Project Manager SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany (HRB 247165, AG München), Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Sep 06 2019, Manfred Hollstein <mhollstein@t-online.de> wrote:
Still OBS thinks "nothing provides rust-cbindgen >= 0.9.0" for 15.0 and 42.3, but the packages are there:
The package is currently building, maybe you didn't wait long enough for the scheduler to pick up the newly built packages? Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Fri, 06 Sep 2019, 15:44:04 +0200, Manfred Hollstein wrote:
Hi there,
I've given up (I think) trying to understand why OBS sometimes behaves different than what I'd expect.
Here is my (current) challenge:
I'm trying to build firefox69 in my own project in home:manfred-h:mozilla. The repository metadata is set up as follows:
$ osc meta prj home:manfred-h:mozilla <project name="home:manfred-h:mozilla"> <title>mozilla</title> <description> Mozilla based projects and support packages. </description> <person userid="manfred-h" role="maintainer"/> <build> <disable/> </build> <repository name="openSUSE_Leap_42.3"> <path project="home:manfred-h:devel:languages:rust" repository="openSUSE_Leap_42.3"/> <path project="mozilla" repository="openSUSE_Leap_42.3"/> <path project="openSUSE:Leap:42.3:Update" repository="standard"/> <path project="openSUSE:Leap:42.3" repository="standard"/> <arch>x86_64</arch> </repository> <repository name="openSUSE_Leap_15.1"> <path project="devel:languages:rust" repository="openSUSE_Leap_15.1"/> <path project="mozilla" repository="openSUSE_Leap_15.1"/> <path project="openSUSE:Leap:15.1:Update" repository="standard"/> <path project="openSUSE:Leap:15.1" repository="standard"/> <arch>x86_64</arch> </repository> <repository name="openSUSE_Leap_15.0"> <path project="home:manfred-h:devel:languages:rust" repository="openSUSE_Leap_15.0"/> <path project="mozilla" repository="openSUSE_Leap_15.0"/> <path project="openSUSE:Leap:15.0:Update" repository="standard"/> <path project="openSUSE:Leap:15.0" repository="standard"/> <arch>x86_64</arch> </repository> </project>
As you can see, nothing should get build by default (this is enabled purely on a package by package case) and repositories are setup so that "rust" and related packages should be taken from
- devel:languages:rust for openSUSE_Leap_15.1 - home:manfred-h:devel:languages:rust for 42.3 and 15.0
firefox69 now needs rust-cbindgen >= 0.9.0, so I copied that package to my home:manfred-h:devel:languages:rust as rust-cbindgen-0.9.0 and built it there successfully for openSUSE_Leap_42.3 and openSUSE_Leap_15.0
Still OBS thinks "nothing provides rust-cbindgen >= 0.9.0" for 15.0 and 42.3, but the packages are there:
<https://build.opensuse.org/package/binary/home:manfred-h:devel:languages:rust/rust-cbindgen-0.9.0/openSUSE_Leap_15.0/x86_64/rust-cbindgen-0.9.0-lp150.1.1.x86_64.rpm> <https://build.opensuse.org/package/binary/home:manfred-h:devel:languages:rust/rust-cbindgen-0.9.0/openSUSE_Leap_42.3/x86_64/rust-cbindgen-0.9.0-1.1.x86_64.rpm>
both providing:
rust-cbindgen = 0.9.0-1.1 rust-cbindgen(x86-64) = 0.9.0-1.1
FWIW, as a last resort, I linked my rust-cbindgen-0.9.0 package to rust-cbindgen in the home:manfred-h:devel:languages:rust project, but this did not change anything unfortunately.
as an update, the linked package "rust-cbindgen" is now "finished" (not yet "succeeded"), and after sending my former message, firefox69 is "blocked" because of rust-cbindgen now. At least a change... ;)
Can anybody tell me what I'm doing wrong here? Or is this a bug in the OBS resolver?
TIA, cheers.
l8er manfred
PS: No complaints wrt/ 42.3, I'm not yet done with migrating all systems I maintain to 15.1 yet! Therefore I'm trying to keep those packages still building which are not services but still as close to the Internet as possible, i.e. the _bad world_ ;)
On Fri, 06 Sep 2019, 16:04:39 +0200, Manfred Hollstein wrote:
On Fri, 06 Sep 2019, 15:44:04 +0200, Manfred Hollstein wrote:
Hi there,
I've given up (I think) trying to understand why OBS sometimes behaves different than what I'd expect.
Here is my (current) challenge:
I'm trying to build firefox69 in my own project in home:manfred-h:mozilla. The repository metadata is set up as follows:
$ osc meta prj home:manfred-h:mozilla <project name="home:manfred-h:mozilla"> <title>mozilla</title> <description> Mozilla based projects and support packages. </description> <person userid="manfred-h" role="maintainer"/> <build> <disable/> </build> <repository name="openSUSE_Leap_42.3"> <path project="home:manfred-h:devel:languages:rust" repository="openSUSE_Leap_42.3"/> <path project="mozilla" repository="openSUSE_Leap_42.3"/> <path project="openSUSE:Leap:42.3:Update" repository="standard"/> <path project="openSUSE:Leap:42.3" repository="standard"/> <arch>x86_64</arch> </repository> <repository name="openSUSE_Leap_15.1"> <path project="devel:languages:rust" repository="openSUSE_Leap_15.1"/> <path project="mozilla" repository="openSUSE_Leap_15.1"/> <path project="openSUSE:Leap:15.1:Update" repository="standard"/> <path project="openSUSE:Leap:15.1" repository="standard"/> <arch>x86_64</arch> </repository> <repository name="openSUSE_Leap_15.0"> <path project="home:manfred-h:devel:languages:rust" repository="openSUSE_Leap_15.0"/> <path project="mozilla" repository="openSUSE_Leap_15.0"/> <path project="openSUSE:Leap:15.0:Update" repository="standard"/> <path project="openSUSE:Leap:15.0" repository="standard"/> <arch>x86_64</arch> </repository> </project>
As you can see, nothing should get build by default (this is enabled purely on a package by package case) and repositories are setup so that "rust" and related packages should be taken from
- devel:languages:rust for openSUSE_Leap_15.1 - home:manfred-h:devel:languages:rust for 42.3 and 15.0
firefox69 now needs rust-cbindgen >= 0.9.0, so I copied that package to my home:manfred-h:devel:languages:rust as rust-cbindgen-0.9.0 and built it there successfully for openSUSE_Leap_42.3 and openSUSE_Leap_15.0
Still OBS thinks "nothing provides rust-cbindgen >= 0.9.0" for 15.0 and 42.3, but the packages are there:
<https://build.opensuse.org/package/binary/home:manfred-h:devel:languages:rust/rust-cbindgen-0.9.0/openSUSE_Leap_15.0/x86_64/rust-cbindgen-0.9.0-lp150.1.1.x86_64.rpm> <https://build.opensuse.org/package/binary/home:manfred-h:devel:languages:rust/rust-cbindgen-0.9.0/openSUSE_Leap_42.3/x86_64/rust-cbindgen-0.9.0-1.1.x86_64.rpm>
both providing:
rust-cbindgen = 0.9.0-1.1 rust-cbindgen(x86-64) = 0.9.0-1.1
FWIW, as a last resort, I linked my rust-cbindgen-0.9.0 package to rust-cbindgen in the home:manfred-h:devel:languages:rust project, but this did not change anything unfortunately.
as an update, the linked package "rust-cbindgen" is now "finished" (not yet "succeeded"), and after sending my former message, firefox69 is "blocked" because of rust-cbindgen now. At least a change... ;)
On Fri, 06 Sep 2019, 15:54:14 +0200, Adrian Schröter wrote:
I don't see it unresolvable in home:manfred-h:mozilla, but blocked.
please note that events between repos in different projects are handled with low prio. So it might take some time to see an effect.
and On Fri, 06 Sep 2019, 15:58:55 +0200, Andreas Schwab wrote:
The package is currently building, maybe you didn't wait long enough for the scheduler to pick up the newly built packages?
both of your answers go into the direction I thought I've waited long enough for... Looks like I just need to wait a little longer :) Thanks for you replies anyway! In case it doesn't resolve in the coming days, I'll be back ;) Cheers. l8er manfred
Hi there, On Fri, 06 Sep 2019, 17:08:05 +0200, Manfred Hollstein wrote:
On Fri, 06 Sep 2019, 16:04:39 +0200, Manfred Hollstein wrote:
On Fri, 06 Sep 2019, 15:44:04 +0200, Manfred Hollstein wrote:
Hi there,
I've given up (I think) trying to understand why OBS sometimes behaves different than what I'd expect.
Here is my (current) challenge:
I'm trying to build firefox69 in my own project in home:manfred-h:mozilla. The repository metadata is set up as follows: ... On Fri, 06 Sep 2019, 15:54:14 +0200, Adrian Schröter wrote: I don't see it unresolvable in home:manfred-h:mozilla, but blocked.
please note that events between repos in different projects are handled with low prio. So it might take some time to see an effect.
and
On Fri, 06 Sep 2019, 15:58:55 +0200, Andreas Schwab wrote:
The package is currently building, maybe you didn't wait long enough for the scheduler to pick up the newly built packages?
both of your answers go into the direction I thought I've waited long enough for... Looks like I just need to wait a little longer :)
Thanks for you replies anyway!
In case it doesn't resolve in the coming days, I'll be back ;)
and here I am again... I have re-created the situation in a small project at <https://build.opensuse.org/project/show/home:manfred-h:TEST>. It contains four packages of which two BuildRequire the two other ones: (1) firefox68 BuildRequires rust-cbindgen >= 0.8.7 provided by rust-cbindgen-0.8.7 (2) firefox69 BuildRequires rust-cbindgen >= 0.9.0 provided by rust-cbindgen-0.9.0 Building firefox68 succeeds, although I don't understand why it doesn't pick up rust-cbindgen-0.9.0 which perfectly fulfills the BuildRequire, too. But, firefox69 fails with "unresolvable": nothing provides rust-cbindgen >= 0.9.0 Am I wrong assuming this ought to work? Worth a bugzilla? Cheers. l8er manfred
On Sep 08 2019, Manfred Hollstein <mhollstein@t-online.de> wrote:
Building firefox68 succeeds, although I don't understand why it doesn't pick up rust-cbindgen-0.9.0 which perfectly fulfills the BuildRequire, too.
There is no rust-cbindgen-0.9.0.rpm, there is only rust-cbindgen.rpm, which has been picked up from home:manfred-h:TEST/rust-cbindgen-0.8.7, with version 0.8.7.
But, firefox69 fails with "unresolvable": nothing provides rust-cbindgen >= 0.9.0
Because rust-cbindgen.rpm has version 0.8.7.
Am I wrong assuming this ought to work?
Yes. A repository can only hold a single version of a binary package with a given name. If you want to provide different versions of a package, you need to build them in different repositories, and control the visibilty via the repository path. Alternatively, you can rename the binary package to make its name unique. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Sun, 08 Sep 2019, 14:12:45 +0200, Andreas Schwab wrote:
On Sep 08 2019, Manfred Hollstein <mhollstein@t-online.de> wrote:
Building firefox68 succeeds, although I don't understand why it doesn't pick up rust-cbindgen-0.9.0 which perfectly fulfills the BuildRequire, too.
There is no rust-cbindgen-0.9.0.rpm, there is only rust-cbindgen.rpm, which has been picked up from home:manfred-h:TEST/rust-cbindgen-0.8.7, with version 0.8.7.
then, why do both versions exist at <https://download.opensuse.org/repositories/home:/manfred-h:/TEST/openSUSE_Leap_15.1/x86_64/> ??
But, firefox69 fails with "unresolvable": nothing provides rust-cbindgen >= 0.9.0
Because rust-cbindgen.rpm has version 0.8.7.
Nope: zypper ar https://download.opensuse.org/repositories/home:/manfred-h:/TEST/openSUSE_Le... TEST zypper ref zypper se -s rust-cbindgen Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository --+---------------+------------+-----------------+--------+----------- | rust-cbindgen | package | 0.9.0-lp151.3.1 | x86_64 | TEST | rust-cbindgen | package | 0.8.7-lp151.8.1 | x86_64 | TEST | rust-cbindgen | srcpackage | 0.9.0-lp151.3.1 | noarch | TEST | rust-cbindgen | srcpackage | 0.8.7-lp151.8.1 | noarch | TEST so it's there and would be installed in version 0.9.0-lp151.3.1 when running zypper in rust-cbindgen
Am I wrong assuming this ought to work?
Yes. A repository can only hold a single version of a binary package with a given name. If you want to provide different versions of a package, you need to build them in different repositories, and control the visibilty via the repository path. Alternatively, you can rename the binary package to make its name unique.
See above. AFAICS, the update repos work exactly like this - they just add a newer version on top of the stack, but in the same repo.
Andreas.
Cheers. l8er manfred
On Sonntag, 8. September 2019 15:29:02 CEST Manfred Hollstein wrote:
On Sun, 08 Sep 2019, 14:12:45 +0200, Andreas Schwab wrote:
On Sep 08 2019, Manfred Hollstein <mhollstein@t-online.de> wrote:
Building firefox68 succeeds, although I don't understand why it doesn't pick up rust-cbindgen-0.9.0 which perfectly fulfills the BuildRequire, too.
There is no rust-cbindgen-0.9.0.rpm, there is only rust-cbindgen.rpm, which has been picked up from home:manfred-h:TEST/rust-cbindgen-0.8.7, with version 0.8.7.
then, why do both versions exist at
<https://download.opensuse.org/repositories/home:/manfred-h:/TEST/openSUSE_ Leap_15.1/x86_64/>
You are confusing download directories with OBS projects. Each OBS project can have exactly *one* version of each package. Each update is created in a separate maintenance project and the built packages are synced to the download directory. Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
On Sep 08 2019, Stefan Brüns <stefan.bruens@rwth-aachen.de> wrote:
You are confusing download directories with OBS projects. Each OBS project can have exactly *one* version of each package.
This isn't exactly true either. A project can have more than one build repository, each one containing its own set of unversioned binary packages. But each build can only see one version of a binary package, with the visibility defined through the repository path. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Moin, On Sun, 08 Sep 2019, 13:32:42 +0200, Manfred Hollstein wrote:
Hi there,
On Fri, 06 Sep 2019, 17:08:05 +0200, Manfred Hollstein wrote:
On Fri, 06 Sep 2019, 16:04:39 +0200, Manfred Hollstein wrote:
On Fri, 06 Sep 2019, 15:44:04 +0200, Manfred Hollstein wrote:
Hi there,
I've given up (I think) trying to understand why OBS sometimes behaves different than what I'd expect.
Here is my (current) challenge:
I'm trying to build firefox69 in my own project in home:manfred-h:mozilla. The repository metadata is set up as follows: ... On Fri, 06 Sep 2019, 15:54:14 +0200, Adrian Schröter wrote: I don't see it unresolvable in home:manfred-h:mozilla, but blocked.
please note that events between repos in different projects are handled with low prio. So it might take some time to see an effect.
and
On Fri, 06 Sep 2019, 15:58:55 +0200, Andreas Schwab wrote:
The package is currently building, maybe you didn't wait long enough for the scheduler to pick up the newly built packages?
both of your answers go into the direction I thought I've waited long enough for... Looks like I just need to wait a little longer :)
Thanks for you replies anyway!
In case it doesn't resolve in the coming days, I'll be back ;)
and here I am again...
I have re-created the situation in a small project at <https://build.opensuse.org/project/show/home:manfred-h:TEST>. It contains four packages of which two BuildRequire the two other ones:
(1) firefox68 BuildRequires rust-cbindgen >= 0.8.7 provided by rust-cbindgen-0.8.7 (2) firefox69 BuildRequires rust-cbindgen >= 0.9.0 provided by rust-cbindgen-0.9.0
Building firefox68 succeeds, although I don't understand why it doesn't pick up rust-cbindgen-0.9.0 which perfectly fulfills the BuildRequire, too.
But, firefox69 fails with "unresolvable": nothing provides rust-cbindgen >= 0.9.0
Am I wrong assuming this ought to work? Worth a bugzilla?
FWIW, building it using a local build script (build-20190128-lp151.1.1.noarch) behaves exactly like I would expect: (0) Both rust-cbindgen package have been built and are available in the same RPMS subdirectory: RPMS/rust-cbindgen-0.8.7-0.x86_64.rpm RPMS/rust-cbindgen-0.9.0-0.x86_64.rpm (1) firefox68 picks up RPMS/rust-cbindgen-0.9.0-0.x86_64.rpm because of the higher version number (2) firefox69 picks up RPMS/rust-cbindgen-0.9.0-0.x86_64.rpm, too, i.e. no trouble to resolve "rust-cbindgen >= 0.9.0"! So, to me this looks like a bug in OBS, no?!? Cheers. l8er manfred
On Sep 08 2019, Manfred Hollstein <mhollstein@t-online.de> wrote:
(0) Both rust-cbindgen package have been built and are available in the same RPMS subdirectory: RPMS/rust-cbindgen-0.8.7-0.x86_64.rpm RPMS/rust-cbindgen-0.9.0-0.x86_64.rpm
The repository can only hold rust-cbindgen.rpm.
So, to me this looks like a bug in OBS, no?!?
No. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Sun, 08 Sep 2019, 14:44:08 +0200, Andreas Schwab wrote:
On Sep 08 2019, Manfred Hollstein <mhollstein@t-online.de> wrote:
(0) Both rust-cbindgen package have been built and are available in the same RPMS subdirectory: RPMS/rust-cbindgen-0.8.7-0.x86_64.rpm RPMS/rust-cbindgen-0.9.0-0.x86_64.rpm
The repository can only hold rust-cbindgen.rpm.
which I honestly doubt! Here's another live example from the updates repo: zypper se -s -x kernel-default i+ | kernel-default | package | 4.12.14-lp151.28.13.1 | x86_64 | update.local v | kernel-default | package | 4.12.14-lp151.28.10.1 | x86_64 | update.local v | kernel-default | package | 4.12.14-lp151.28.7.1 | x86_64 | update.local v | kernel-default | package | 4.12.14-lp151.28.4.1 | x86_64 | update.local This looks to me as if the repo can hold more than one version.
So, to me this looks like a bug in OBS, no?!?
No.
Still not convinced.
Andreas.
Cheers. l8er manfred
On Sep 08 2019, Manfred Hollstein <mhollstein@t-online.de> wrote:
which I honestly doubt! Here's another live example from the updates repo:
zypper se -s -x kernel-default i+ | kernel-default | package | 4.12.14-lp151.28.13.1 | x86_64 | update.local v | kernel-default | package | 4.12.14-lp151.28.10.1 | x86_64 | update.local v | kernel-default | package | 4.12.14-lp151.28.7.1 | x86_64 | update.local v | kernel-default | package | 4.12.14-lp151.28.4.1 | x86_64 | update.local
These all come from separate repositories. A download directory is *not* a repository in the OBS sense. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Sonntag, 8. September 2019 13:32:42 CEST Manfred Hollstein wrote:
Hi there,
I have re-created the situation in a small project at <https://build.opensuse.org/project/show/home:manfred-h:TEST>. It contains four packages of which two BuildRequire the two other ones:
I am just wondering what you are trying to achieve at all. Currently you are: - building mozilla69 and mozilla68, both are unmodified copies of the packages from the mozilla OBS projects. - building each one for Leap 42.3, 15.0 and 15.1 - doing the same in your :mozilla and :TEST subprojects. These are 2 * 3 * 2 = 12 instances of mozilla package builds. These packages compete with the MozillaFirefox packages from Tumbleweed and its Stagings. Only 4 of the OBS workers have enough resources to build Firefox, so the whole Staging process gets slowed down considerably. Please: - disable building for the project(s) you don't work on - disable building for all but one distribution, thats sufficient for your setup experiments. And as Andreas has said already - don't try to build different versions of the same package in one project. A project can hold exactly one version of a package at any time. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
On Sun, 08 Sep 2019, 15:12:58 +0200, Stefan Brüns wrote:
On Sonntag, 8. September 2019 13:32:42 CEST Manfred Hollstein wrote:
Hi there,
I have re-created the situation in a small project at <https://build.opensuse.org/project/show/home:manfred-h:TEST>. It contains four packages of which two BuildRequire the two other ones:
I am just wondering what you are trying to achieve at all. Currently you are:
- building mozilla69 and mozilla68, both are unmodified copies of the packages from the mozilla OBS projects. - building each one for Leap 42.3, 15.0 and 15.1 - doing the same in your :mozilla and :TEST subprojects.
you did not look at the projects, did you? :TEST is just a set of four packages with *no* files to be stored into the built RPMs; I created them just as a small test case to describe what I see. I now learned that I have to re-think my impression of a repository in the sense of OBS vs zypper, but that's another issue.
These are 2 * 3 * 2 = 12 instances of mozilla package builds. These packages compete with the MozillaFirefox packages from Tumbleweed and its Stagings.
Are you saying I should not help Wolfgang, who is the maintainer for the mozilla packages and his work? The current situation that I'm back at revision 1 is just a matter of having to re-base/sync my work with Wolfgang's.
Only 4 of the OBS workers have enough resources to build Firefox, so the whole Staging process gets slowed down considerably.
Please: - disable building for the project(s) you don't work on - disable building for all but one distribution, thats sufficient for your setup experiments.
Please read above. If you want, I can certainly stop contributing to various packages...
And as Andreas has said already - don't try to build different versions of the same package in one project. A project can hold exactly one version of a package at any time.
Yep, *now* I know.
Regards,
Stefan
Cheers. l8er manfred
On Sonntag, 8. September 2019 17:08:14 CEST Manfred Hollstein wrote:
On Sun, 08 Sep 2019, 15:12:58 +0200, Stefan Brüns wrote:
On Sonntag, 8. September 2019 13:32:42 CEST Manfred Hollstein wrote:
These are 2 * 3 * 2 = 12 instances of mozilla package builds. These packages compete with the MozillaFirefox packages from Tumbleweed and its Stagings. Are you saying I should not help Wolfgang, who is the maintainer for the mozilla packages and his work? The current situation that I'm back at revision 1 is just a matter of having to re-base/sync my work with Wolfgang's.
Only 4 of the OBS workers have enough resources to build Firefox, so the whole Staging process gets slowed down considerably.
Please: - disable building for the project(s) you don't work on - disable building for all but one distribution, thats sufficient for your setup experiments.
Please read above. If you want, I can certainly stop contributing to various packages...
I never said that. I just asked kindly to consider the effects of rebuilding packages in your home project *after* submitting your work. You are effectively hurting yourself - you are slowing down Factory progress, and thus also extend the time it takes until the next Firefox or Thunderbird version is accepted. When you start the next round, you can just start with *one* target repository enabled, and enable the other ones once the first one succeeds, just prior to submission. Unfortunately, powerful workers are a scarce resource in the OBS. Using only as few resources as needed helps *all* contributors. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
On Freitag, 6. September 2019, 17:08:05 CEST Manfred Hollstein wrote:
On Fri, 06 Sep 2019, 16:04:39 +0200, Manfred Hollstein wrote:
On Fri, 06 Sep 2019, 15:44:04 +0200, Manfred Hollstein wrote:
Hi there,
I've given up (I think) trying to understand why OBS sometimes behaves different than what I'd expect.
Here is my (current) challenge:
I'm trying to build firefox69 in my own project in
home:manfred-h:mozilla. The repository metadata is set up as follows: $ osc meta prj home:manfred-h:mozilla <project name="home:manfred-h:mozilla">
<title>mozilla</title> <description>
Mozilla based projects and support packages.
</description> <person userid="manfred-h" role="maintainer"/> <build>
<disable/>
</build> <repository name="openSUSE_Leap_42.3">
<path project="home:manfred-h:devel:languages:rust" repository="openSUSE_Leap_42.3"/> <path project="mozilla" repository="openSUSE_Leap_42.3"/> <path project="openSUSE:Leap:42.3:Update" repository="standard"/> <path project="openSUSE:Leap:42.3" repository="standard"/> <arch>x86_64</arch>
</repository> <repository name="openSUSE_Leap_15.1">
<path project="devel:languages:rust" repository="openSUSE_Leap_15.1"/> <path project="mozilla" repository="openSUSE_Leap_15.1"/> <path project="openSUSE:Leap:15.1:Update" repository="standard"/> <path project="openSUSE:Leap:15.1" repository="standard"/> <arch>x86_64</arch>
</repository> <repository name="openSUSE_Leap_15.0">
<path project="home:manfred-h:devel:languages:rust" repository="openSUSE_Leap_15.0"/> <path project="mozilla" repository="openSUSE_Leap_15.0"/> <path project="openSUSE:Leap:15.0:Update" repository="standard"/> <path project="openSUSE:Leap:15.0" repository="standard"/> <arch>x86_64</arch>
</repository>
</project>
As you can see, nothing should get build by default (this is enabled purely on a package by package case) and repositories are setup so that "rust" and related packages should be taken from
- devel:languages:rust for openSUSE_Leap_15.1 - home:manfred-h:devel:languages:rust for 42.3 and 15.0
firefox69 now needs rust-cbindgen >= 0.9.0, so I copied that package to my home:manfred-h:devel:languages:rust as rust-cbindgen-0.9.0 and built it there successfully for openSUSE_Leap_42.3 and openSUSE_Leap_15.0
Still OBS thinks "nothing provides rust-cbindgen >= 0.9.0" for 15.0 and
42.3, but the packages are there: <https://build.opensuse.org/package/binary/home:manfred-h:devel:langua ges:rust/rust-cbindgen-0.9.0/openSUSE_Leap_15.0/x86_64/rust-cbindgen-0 .9.0-lp150.1.1.x86_64.rpm> <https://build.opensuse.org/package/binary/home:manfred-h:devel:langu ages:rust/rust-cbindgen-0.9.0/openSUSE_Leap_42.3/x86_64/rust-cbindgen- 0.9.0-1.1.x86_64.rpm>> > both providing: rust-cbindgen = 0.9.0-1.1 rust-cbindgen(x86-64) = 0.9.0-1.1
FWIW, as a last resort, I linked my rust-cbindgen-0.9.0 package to rust-cbindgen in the home:manfred-h:devel:languages:rust project, but this did not change anything unfortunately.
as an update, the linked package "rust-cbindgen" is now "finished" (not yet "succeeded"), and after sending my former message, firefox69 is "blocked" because of rust-cbindgen now. At least a change... ;)
On Fri, 06 Sep 2019, 15:54:14 +0200, Adrian Schröter wrote:
I don't see it unresolvable in home:manfred-h:mozilla, but blocked.
please note that events between repos in different projects are handled with low prio. So it might take some time to see an effect.
and
On Fri, 06 Sep 2019, 15:58:55 +0200, Andreas Schwab wrote:
The package is currently building, maybe you didn't wait long enough for the scheduler to pick up the newly built packages?
both of your answers go into the direction I thought I've waited long enough for... Looks like I just need to wait a little longer :)
Thanks for you replies anyway!
In case it doesn't resolve in the coming days, I'll be back ;)
don't wait, use "osc buildinfo" to see if you have problems right now. The scheduler will follow, if that has worked.... -- Adrian Schroeter <adrian@suse.de> Build Infrastructure Project Manager SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany (HRB 247165, AG München), Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
not completely unrelated... due to the fact that firefox68 AND firefox69 both don't build in the mozilla project right now my systems have reverted to the mozilla 60.8esr from the updates repo... which means the more important ones of the addons that I'm using are not working anymore. Also, firefox crashes on exit. *not* funny. Cheers MH -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Am 09.09.19 um 10:47 schrieb Mathias Homann:
not completely unrelated...
due to the fact that firefox68 AND firefox69 both don't build in the mozilla project right now my systems have reverted to the mozilla 60.8esr from the updates repo... which means the more important ones of the addons that I'm using are not working anymore. Also, firefox crashes on exit.
*not* funny.
can you please elaborate what you are doing on which distribution and so on? Wolfgang -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Am Montag, 9. September 2019, 10:50:58 CEST schrieb Wolfgang Rosenauer:
Am 09.09.19 um 10:47 schrieb Mathias Homann:
not completely unrelated...
due to the fact that firefox68 AND firefox69 both don't build in the mozilla project right now my systems have reverted to the mozilla 60.8esr from the updates repo... which means the more important ones of the addons that I'm using are not working anymore. Also, firefox crashes on exit.
*not* funny.
can you please elaborate what you are doing on which distribution and so on?
I'm running Leap 15.0 and have the mozilla repository enabled, so that I have the same firefox on linux that I have on windows, mainly because some of the addons that I use refuse to work on anything older than the latest firefox. right now the available firefox from the mozilla repo is even older than the one from the updates repo, both are too old for the addons. Cheers MH *Mathias Homann* Mathias.Homann@openSUSE:.org[1] irc: [Lemmy] @ freenode, ircnet obs: lemmy04 *gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102* -------- [1] mailto:Mathias.Homann@eregion.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Am 09.09.19 um 11:23 schrieb Mathias Homann:
Am Montag, 9. September 2019, 10:50:58 CEST schrieb Wolfgang Rosenauer:
Am 09.09.19 um 10:47 schrieb Mathias Homann:
not completely unrelated...
due to the fact that firefox68 AND firefox69 both don't build in the mozilla project right now my systems have reverted to the mozilla 60.8esr from the updates repo... which means the more important ones of the addons that I'm using are not working anymore. Also, firefox crashes on exit.
*not* funny.
can you please elaborate what you are doing on which distribution and so on?
I'm running Leap 15.0 and have the mozilla repository enabled, so that I have the same firefox on linux that I have on windows, mainly because some of the addons that I use refuse to work on anything older than the latest firefox.
Firefox 69 currently does not build on 15.0 due to old rust toolchain and the rust guys not providing successful rust builds for 15.0 at this moment unfortunately so the toolchain import does not work. Firefox 68.1 is currently building with a hotfix because the packages provided for a very short time before were broken on x86(-64) therefore I wiped the binaries directly after publishing. Wolfgang -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Mon, 09 Sep 2019, 12:02:01 +0200, Wolfgang Rosenauer wrote:
Am 09.09.19 um 11:23 schrieb Mathias Homann:
Am Montag, 9. September 2019, 10:50:58 CEST schrieb Wolfgang Rosenauer:
Am 09.09.19 um 10:47 schrieb Mathias Homann:
not completely unrelated...
due to the fact that firefox68 AND firefox69 both don't build in the mozilla project right now my systems have reverted to the mozilla 60.8esr from the updates repo... which means the more important ones of the addons that I'm using are not working anymore. Also, firefox crashes on exit.
*not* funny.
can you please elaborate what you are doing on which distribution and so on?
I'm running Leap 15.0 and have the mozilla repository enabled, so that I have the same firefox on linux that I have on windows, mainly because some of the addons that I use refuse to work on anything older than the latest firefox.
Firefox 69 currently does not build on 15.0 due to old rust toolchain and the rust guys not providing successful rust builds for 15.0 at this moment unfortunately so the toolchain import does not work.
For the time being, you could use <https://build.opensuse.org/project/show/home:manfred-h:devel:languages:rust> for 15.0, too. I use it for firefox68 and firefox69 (while my firefox68 is not your 68esr atm).
Firefox 68.1 is currently building with a hotfix because the packages provided for a very short time before were broken on x86(-64) therefore I wiped the binaries directly after publishing.
see above.
Wolfgang
Cheers. l8er manfred
Am Montag, 9. September 2019, 12:02:01 CEST schrieb Wolfgang Rosenauer:
Firefox 68.1 is currently building with a hotfix because the packages provided for a very short time before were broken on x86(-64) therefore I wiped the binaries directly after publishing.
dude, if you ever find yourself somewhere in southern lower saxony and in desperate need of beer, coffee, or sandwiches, gimme a holler. -- *Mathias Homann* Mathias.Homann@openSUSE.org[1] telegram: https://telegram.me/lemmy98[2] irc: [lemmy] on freenode and ircnet obs: lemmy04 *gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102 * -------- [1] mailto:Mathias.Homann@eregion.de [2] https://telegram.me/lemmy98
Am Montag, 9. September 2019, 12:02:01 CEST schrieb Wolfgang Rosenauer:
Firefox 68.1 is currently building with a hotfix because the packages provided for a very short time before were broken on x86(-64) therefore I wiped the binaries directly after publishing.
hm. that binary crashes immediately when I start any video playback (youtube, twitch). Cheers MH *Mathias Homann* Mathias.Homann@openSUSE.org[1] telegram: https://telegram.me/lemmy98[2] irc: [lemmy] on freenode and ircnet obs: lemmy04 *gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102 * -------- [1] mailto:Mathias.Homann@eregion.de [2] https://telegram.me/lemmy98 -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Am 09.09.19 um 21:46 schrieb Mathias Homann:
Am Montag, 9. September 2019, 12:02:01 CEST schrieb Wolfgang Rosenauer:
Firefox 68.1 is currently building with a hotfix because the packages provided for a very short time before were broken on x86(-64) therefore I wiped the binaries directly after publishing.
hm. that binary crashes immediately when I start any video playback (youtube, twitch).
hmm, unfortunate. But yes, I found another bug in that build which _should_ just cause a bad video coloring. At least that is what is happening for me. If it crashes for you that is quite a bigger issue. The bug should be fixed with recent submission but as I also needed to fix something in NSPR for Tumbleweed the whole repo needs to rebuild which now will take again some time. Wolfgang -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Am Montag, 9. September 2019, 22:31:53 CEST schrieb Wolfgang Rosenauer:
Am 09.09.19 um 21:46 schrieb Mathias Homann:
Am Montag, 9. September 2019, 12:02:01 CEST schrieb Wolfgang Rosenauer:
Firefox 68.1 is currently building with a hotfix because the packages provided for a very short time before were broken on x86(-64) therefore I wiped the binaries directly after publishing.
hm. that binary crashes immediately when I start any video playback (youtube, twitch).
hmm, unfortunate. But yes, I found another bug in that build which _should_ just cause a bad video coloring. At least that is what is happening for me. If it crashes for you that is quite a bigger issue.
Guess I wasn't completely clear: as soon as I start video playback I can see that the video area is blue - then FF crashes. Detail: nvidia optimus here. Can't test on a "normal" nvidia rig before tomorrow night.
The bug should be fixed with recent submission but as I also needed to fix something in NSPR for Tumbleweed the whole repo needs to rebuild which now will take again some time.
That's ok, i can just go and have breakfast in the meantime... XD Cheers MH *Mathias Homann* Mathias.Homann@openSUSE.org[1] telegram: https://telegram.me/lemmy98[2] irc: [lemmy] on freenode and ircnet obs: lemmy04 *gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102 * -------- [1] mailto:Mathias.Homann@eregion.de [2] https://telegram.me/lemmy98
Am Montag, 9. September 2019, 22:31:53 CEST schrieb Wolfgang Rosenauer:
Am 09.09.19 um 21:46 schrieb Mathias Homann:
Am Montag, 9. September 2019, 12:02:01 CEST schrieb Wolfgang Rosenauer:
Firefox 68.1 is currently building with a hotfix because the packages provided for a very short time before were broken on x86(-64) therefore I wiped the binaries directly after publishing.
hm. that binary crashes immediately when I start any video playback (youtube, twitch).
hmm, unfortunate. But yes, I found another bug in that build which _should_ just cause a bad video coloring. At least that is what is happening for me. If it crashes for you that is quite a bigger issue. The bug should be fixed with recent submission but as I also needed to fix something in NSPR for Tumbleweed the whole repo needs to rebuild which now will take again some time.
Wolfgang
By now I'm running the binaries from that last build, no more blue videos and no more crashes. What I said about beer/coffee/sandwiches stands. Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org telegram: https://telegram.me/lemmy98 irc: [lemmy] on freenode and ircnet obs: lemmy04 gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102 -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Am 2019-09-09 22:31, schrieb Wolfgang Rosenauer:
Am 09.09.19 um 21:46 schrieb Mathias Homann:
Am Montag, 9. September 2019, 12:02:01 CEST schrieb Wolfgang Rosenauer:
Firefox 68.1 is currently building with a hotfix because the packages provided for a very short time before were broken on x86(-64) therefore I wiped the binaries directly after publishing.
hm. that binary crashes immediately when I start any video playback (youtube, twitch).
hmm, unfortunate. But yes, I found another bug in that build which _should_ just cause a bad video coloring. At least that is what is happening for me. If it crashes for you that is quite a bigger issue. The bug should be fixed with recent submission but as I also needed to fix something in NSPR for Tumbleweed the whole repo needs to rebuild which now will take again some time.
not completely unrelated: could you please turn on publishing on the thunderbird68 package but leave building disabled, then wipe its binaries? After they have been removed from the repos you can turn publishing off again... right now the repos contain Thunderbird 68.0 which is basically broken when it comes to addons, and Thunderbird 60.9 which works fine but gets replaced by the broken tb 68 unless you lock it... Cheers Mathias -- Mathias Homann Mathias.Homann@openSUSE.org telegram: https://telegram.me/lemmy98 irc: [lemmy] on freenode and ircnet obs: lemmy04 gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102 -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Hi, Am 13.09.19 um 08:15 schrieb Mathias Homann:
not completely unrelated: could you please turn on publishing on the thunderbird68 package but leave building disabled, then wipe its binaries? After they have been removed from the repos you can turn publishing off again... right now the repos contain Thunderbird 68.0 which is basically broken when it comes to addons, and Thunderbird 60.9 which works fine but gets replaced by the broken tb 68 unless you lock it...
hmm, what do you mean by "basically broken when it comes to addons"? The fact that it does not support old-style xul addons but only webextensions? Or is there anything else? If it's the former there is no reason to remove TB68 because the change will happen anyway. The plan also is to go to 68.1 in Tumbleweed within the next days. The only way to stay with TB 68.9 (I'm not even sure if there will be a 60.10 is to lock it anyway which is always the case if a new version arrives. Wolfgang -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Am Freitag, 13. September 2019, 08:34:14 CEST schrieb Wolfgang Rosenauer:
Hi,
Am 13.09.19 um 08:15 schrieb Mathias Homann:
not completely unrelated: could you please turn on publishing on the thunderbird68 package but leave building disabled, then wipe its binaries? After they have been removed from the repos you can turn publishing off again... right now the repos contain Thunderbird 68.0 which is basically broken when it comes to addons, and Thunderbird 60.9 which works fine but gets replaced by the broken tb 68 unless you lock it...
hmm, what do you mean by "basically broken when it comes to addons"? The fact that it does not support old-style xul addons but only webextensions? Or is there anything else?
well, there is the fact that so far no addons have actually been updated, or if they have they don't work - not even the ones that come packaged with it., like lightning.
If it's the former there is no reason to remove TB68 because the change will happen anyway.
maybe then the change shouldn't happen yet?
The plan also is to go to 68.1 in Tumbleweed within the next days. The only way to stay with TB 68.9 (I'm not even sure if there will be a 60.10 is to lock it anyway which is always the case if a new version arrives.
guess i'll end up having to do that then - but then maybe you could turn *on* pubishing for a moment, so that the already built 68.1 actually gets out? Or is there still work to be done on that package? I'm trying the 68.1 binaries right now, and the first I see is this: https://gyazo.com/2e1b4633008da15847bd49ffe84921c3 Cheers MH *Mathias Homann* Mathias.Homann@openSUSE.org[2] telegram: https://telegram.me/lemmy98[3] irc: [lemmy] on freenode and ircnet obs: lemmy04 *gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102 * -------- [1] https://gyazo.com/2e1b4633008da15847bd49ffe84921c3 [2] mailto:Mathias.Homann@eregion.de [3] https://telegram.me/lemmy98 -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Am 13.09.19 um 09:09 schrieb Mathias Homann:
Am Freitag, 13. September 2019, 08:34:14 CEST schrieb Wolfgang Rosenauer:
Hi,
Am 13.09.19 um 08:15 schrieb Mathias Homann:
not completely unrelated: could you please turn on publishing on the thunderbird68 package but leave building disabled, then wipe its binaries? After they have been removed from the repos you can turn publishing off again... right now the repos contain Thunderbird 68.0 which is basically broken when it comes to addons, and Thunderbird 60.9 which works fine but gets replaced by the broken tb 68 unless you lock it...
hmm, what do you mean by "basically broken when it comes to addons"? The fact that it does not support old-style xul addons but only webextensions? Or is there anything else?
well, there is the fact that so far no addons have actually been updated, or if they have they don't work - not even the ones that come packaged with it., like lightning.
If it's the former there is no reason to remove TB68 because the change will happen anyway.
maybe then the change shouldn't happen yet?
That is what people said when Firefox dropped old-style extension support. And it's similar for a lot of things: At some point it needs to be enforced otherwise it will never happen. I do not say that the timing is perfect but it is how it is. I cannot change anything really. I can try to find out if there is another 60.x release but if not there is no real choice. Otherwise we have bought 4-6 more weeks during that period other people would complain to not get 68.x.
The plan also is to go to 68.1 in Tumbleweed within the next days. The only way to stay with TB 68.9 (I'm not even sure if there will be a 60.10 is to lock it anyway which is always the case if a new version arrives.
guess i'll end up having to do that then - but then maybe you could turn *on* pubishing for a moment, so that the already built 68.1 actually gets out? Or is there still work to be done on that package?
Publishing is turned on. Building is off to save OBS cycles. For a final build (and probable submission to TW) the security changelog entries are missing. The only issue is that I'm not sure which binaries are actually served exactly and if there was a relevant change since building is disabled.
I'm trying the 68.1 binaries right now, and the first I see is this:
Since I guess that this is called only on first upgrade of a profile I cannot reproduce easily. I will try. Do you have the full URL somewhere on the screen? Wolfgang -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Am Freitag, 13. September 2019, 09:40:40 CEST schrieb Wolfgang Rosenauer:
hmm, what do you mean by "basically broken when it comes to addons"? The fact that it does not support old-style xul addons but only webextensions? Or is there anything else?
well, there is the fact that so far no addons have actually been updated, or if they have they don't work - not even the ones that come packaged with it., like lightning.
actually by now *most* of the extesions that I have to have work, after you manually reinstall them - not all, but the important ones, I can get at my calendars and contacts.
I'm trying the 68.1 binaries right now, and the first I see is this:
Since I guess that this is called only on first upgrade of a profile I cannot reproduce easily. I will try. Do you have the full URL somewhere on the screen?
it actually shows up every time I start TB68 - and there is no full URL anywhere. I'll keep trying 68.1 for a bit. Cheers -- Mathias Homann Mathias.Homann@openSUSE.org telegram: https://telegram.me/lemmy98 irc: [lemmy] on freenode and ircnet obs: lemmy04 gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102 -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
participants (7)
-
Adrian Schröter -
Andreas Schwab -
Manfred Hollstein -
Mathias Homann -
Mathias Homann
-
Stefan Brüns -
Wolfgang Rosenauer