[opensuse-kde] UpdatedApps for 11.3
Hey! I tried to install digikam 1.9 from the UpdatedApps repo on a 11.3. It complains about digikam-lang 1.2.0 needing digikam 1.2.0, so one has to remove it. After doing so it installs but fails to start because of symbol lookup errors. I'd assume that if any dependencies were not met it would complain. Having a look at the repo there are quite some packages that fail, digikam among them. Since UpdatedApps is part of the list of repos that can be added via YaST, i.e. semi-official, would it please be possible to fix it? I guess that the digikam package lacks a dependency to digikam-sharedlibs for example. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Søndag den 2. oktober 2011 12:24:28 skrev Sven Burmeister:
At least it should be possible to remove the broken packages. But 11.3 will die in a few months anyway. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am 03.10.2011 18:03, schrieb Martin Schlander:
At least it should be possible to remove the broken packages. But 11.3 will die in a few months anyway.
don´t be sure about it. Maybe some of the evergreen guys will take it over... Kim -- -o) Kim Leyendecker /\\ openSUSE Ambassador, openSUSE Wiki Team DE _\_v http://www.opensuse.org - Linux for open minds -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Montag, 3. Oktober 2011, 18:03:58 schrieb Martin Schlander:
At least it should be possible to remove the broken packages. But 11.3 will die in a few months anyway.
Indeed. It does make a bad impression if repos are broken, no matter whether 11.3 will run out in months or not. So if UpdatedApps does not get the attention that would be needed to recommend it (remember that this was the repo managed by opensuse staff) it should be removed from the community repos list offered in YaST. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Mandag den 3. oktober 2011 18:42:18 skrev Sven Burmeister:
Even if it was maintained by someone who knew what they were doing, it's very unlikely anyone would test all the packages on all suse versions and archs. KUA is using a distinct "if it builds, ship it!" policy. Noone reported any problems until now, so I don't think it would have made a difference if someone else maintained it. Even though it's in the community repos list, it's still an unsupported repo, and some minor risks should be accepted. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Montag, 3. Oktober 2011, 18:47:42 schrieb Martin Schlander:
It's not about testing but simply not having it broken for weeks. A repo which is basically unmaintained should not be offered on the community repos list. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Mandag den 3. oktober 2011 18:56:30 skrev Sven Burmeister:
And how are you supposed to know it's broken without testing it and noone reporting there's a problem? -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On 3 October 2011 20:15, Martin Schlander <martin.schlander@gmail.com> wrote:
In this specific case just looking at https://build.opensuse.org/project/monitor?project=KDE%3AUpdatedApps The last successful build of digikam was on 2011-07-22. Let's face it, KUA is unmaintained... -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Mandag den 3. oktober 2011 21:37:32 skrev Cristian Morales Vega:
The way it works is that when some new app appears in KDF it's linked to KUA - if it builds it builds - if it fails it shouldn't hurt anyone. You can't expect everything to build on old 11.3. E.g. digiKam 2.x failing to build on 11.3 is not really a problem. In fact it's expected. This does not serve as a hint to anyone that digiKam 1.9 binaries are broken on 11.3. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On 3 October 2011 20:51, Martin Schlander <martin.schlander@gmail.com> wrote:
It also fails in 11.4, the latest stable release.
If every maintainer of KUA agrees in that this is the level of support that should be expected OK. But then you have my vote to raise the minimum level of support required to be in the community repos list and remove KUA from it. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Mandag den 3. oktober 2011 22:13:31 skrev Cristian Morales Vega:
Well. If one broken published binary on an old distro version, ever, is enough to remove a repo from the community repos list, then you can remove all of them, including packman and mozilla. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Dienstag, 4. Oktober 2011, 08:24:38 schrieb Martin Schlander:
The mozilla repo seems pretty green, 100% for 11.4 and one package failing for 11.3 and that's a branding package. I have not tested every package in KUA and you might be right that all the ~20 packages failing might not be published – nevertheless they fail. And the issue is not that there is one broken binary but simply that there is nobody checking whether it builds within KUA and to fix it within hours/days (reverting to a version that builds within KUA), i.e. no maintainer. Packman has a huge number of packages, so I'm not sure it is comparable but mozilla certainly does have a maintainer who is even active on the mailing list answering questions regarding issues with the packages. I do not see the issue with having "all green" as a target for repos which are offered in the community repos list. If there are any recommended repos at all it's those that are on the community repos list. If there are no resources for that fair enough but then one should just remove it. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Tirsdag den 4. oktober 2011 10:52:23 skrev Sven Burmeister:
This is the last time I repeat myself. Users are not affected by build failures. Noone is. The amount of "red" and build failures couldn't be less significant - especially not in a repo for leaf packages only. It's a complete non-issue. What does matter is the binaries that actually get published for users. If the build fails, the package isn't published. And the "old" binary remains in the repo. That is why users still see digikam 1.9 in KUA, when digikam 2.0 fails to build. The brokenness of digikam 1.9 on 11.3 has absolutely NOTHING to do with digikam 2.0 or any other package in KUA failing to build. And digikam 2.0 or any other package in KUA failing to build does not hurt ANY user. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Dienstag, 4. Oktober 2011, 11:46:52 schrieb Martin Schlander:
To repeat myself again. There is no maintainer for KUA! QA is not given. That's all that matters. How do I know? Simply because there would not be a broken 1.9 package in there months after it built correctly (if ever) last time if somebody cared. And that's exactly the problem which I think you ignore. Unless there is an active maintainer it does not belong on the community repos list. And another thing you ignore is that all those supposedly not hurting build failures hide feedback regarding the published packages. The repo monitor and the repo content are not in sync and thus this makes it even more difficult to know which packages are ok in the repo but failing to build or failing to build and broken in the repo as well. So what you do when seeing a build failure in KUA is to assume that it's ok since there are the last working binaries still in the repo. You don't know and that's simply not enough for a repo to be recommended, i.e. part of the community repos list. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Tue, Oct 4, 2011 at 12:12 PM, Sven Burmeister <sven.burmeister@gmx.net> wrote:
The build status tells you absolutely nothing about whether the package works when installed. Packages can be, and are, green across the board and still fail to install or fail when running (in fact I am currently fixing a problem with wine where it builds but refuses to install in Factory). OBS does not check whether packages work when installed. So even if it built successfuly that would still not be enough to assume the binaries work. -Todd -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Dienstag, 4. Oktober 2011, 14:23:53 schrieb todd rme:
So? I never claimed it would be enough. But it would be more than having a failing package. Currently the build status is unknown or failing and there is no info about the binary working or not. How can that be any better than having it built correctly? Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Tirsdag den 4. oktober 2011 12:12:11 skrev Sven Burmeister:
To repeat myself again. There is no maintainer for KUA! QA is not given. That's all that matters.
KUA has at least the same level of QA as any other unsupported OBS repo, i.e. none - except the maintainer himself (that would basically be me, though I call in the cavalry when I become aware of significant problems I cannot fix) using most of the packages on one specific distro version and arch. All QA besides that depends on users reporting problems. This is the same as for any other OBS repo, whether in the community repos list or not. Since KUA is limited to links to KDF the packages will actually have been tested somewhat before entering KUA, although in a different environment.
You still have not explained how the maintainer is supposed to fix something noone reported is broken. Or how he's supposed to know it's broken without testing every package on every distro and arch. Which doesn't not happen for any package in any unsupported OBS repo - whether in community repos list or not. On 11.4 the digikam 1.9 package works fine afaict. Btw. the offending digikam 1.9 package has now been wiped for 11.3. So no more 11.3 users will have any problems because of it. Thanks for reporting the problem. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Dienstag, 4. Oktober 2011, 14:27:01 schrieb Martin Schlander:
As stated in one of my first emails KUA/Backports was once maintained by opensuse staff and at that time this was one of the main reasons to put it on the community repos list. So there was a decrease in QA which should be reflected in its recommendation status. It seems that while there was a distinction between Community and Backports repo back then, now there is not anymore.
Whatever the test was, it failed in this case.
You still have not explained how the maintainer is supposed to fix something noone reported is broken.
Usually the maintainer should check the build status – which is obviously impossible if "does not build does not mean anything" applies. And I still don't get why there is only the choice of having links rather than the last version that works with distro x.y. If there ever was a working digikam version the maintainer should check whether a new version builds. If not the source for that distro should be reverted to the building version. Or even let Cor take over if he can build digikam even for 11.3.
That's why "it does not build does not mean anything" is dangerous, because it hides the first "warning", i.e. the build status. Building does not mean it works but not building is even less informative. Further if there are any changes that demand a rebuild of the package that won't happen. People are stuck with some binary. To me that sounds like Playground.
Wiping is not really what I would call maintaining a package or fixing a problem. I can understand that you do not have enough time to do it in another way but removing is giving up maintainership and not maintaining. So that's why I agree with Cristian that KUA is basically unmaintained. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On 4 October 2011 13:27, Martin Schlander <martin.schlander@gmail.com> wrote:
As an 11.4 user I ask myself: - Who will patch the digikam 1.8 package from the main repo if there is ever a security issue? The security team. - Who will patch the digikam 2.2 package from the KDF repo if there is ever a security issue? There are two independent teams here. At the very minimum upstream will do it (and the KDF maintainers will publish the update from upstream). And I expect the security team and/or the KDF maintainers to also do some basic checks since those packages have to go to Factory. Perhaps it's not as secure as the package from the official repo, but it gives me some confidence to know someone is watching it. - Who will patch the digikam 1.9 package from the KUA repo if there is ever a security issue? Upstream is NOT going to. KDF maintainers are NOT going to. Who is going to then? And that's the simple reason why packages should build. Trust in a package is a temporal state that disappears the moment the maintainer published an update. What I really trust is the maintainer, not the package, and the maintainer can only transfer that trust to the LATEST package. I even stop trusting the packages from the official repo once an update is published in the updates repo...
So KUA users should check themselves for security issues and report them to you? Well, perhaps that should be the official minimum for a repo to be in the list: "We don't make any promises about how long it will take to fix security issues. But YOU will NOT need to check for security issues in the packages from these repos." -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Dienstag, 4. Oktober 2011, 17:03:56 schrieb Cristian Morales Vega:
I thought about that issue too – but the answer you will get is that every user who uses any obs repo accepts the risk of doing so and thus has to care about any issues himself. Not nice, certainly not something to make openSUE more popular, but given the resources kind of understandable. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Montag, 3. Oktober 2011, 21:51:05 schrieb Martin Schlander:
Nobody expects that. But what I thought that one could expect is that all packages in it build, i.e. are not broken. So if digikam 1.9 is the last version that builds fine for KUA it should be in there and not updated to 2.0.
See above. If a version does not compile for distro x.y it should not be included in KUA. Everything that is in the repo and installable via YaST should work. Of course there can be issues if a new version is introduced but then it should be fixed ASAP after it was noticed. If the latter does not work within days or a week max then the repo should not be on the community repo list, IMHO. I'm not saying that one can demand anything from anyone, just that whatever repo is put on the community repo list must have a certain QA standard and be maintained. If those standards cannot be met then the repo has to be removed. In case of digikam there is a tarball which contains all necessary libs, so it should be buildable, but I might be wrong about that. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Op 03-10-11 23:15, Sven Burmeister schreef:
I have looked into building digikam 2 on vanilla 11.4 with original KDE some time ago. The tarball does indeed have the necessary libs, but KDF is using these libs external. It is a lot of work to build with "internal" libs. The easiest way is to add the necessary packages to KUA (including some KDE 4.7 stuff). I have done this successfully in my home prj. See https://build.opensuse.org/project/show?project=home%3Acornelisbb%3Adigikam The only thing is that an extra patch is necessary to force use of external libs on KDE 4.6 (I have called it "digikam-force-external-libs-4.6.patch"). The result is a nicely working digikam on vanilla 11.4. I can do a submitreq somewhere, but because KUA is mainly links, I do not really know how to do this. But maybe this can help. Regards, Cor -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Mandag den 3. oktober 2011 23:55:44 skrev Cor Blom:
It would certainly be nice if someone would help out with KUA. Especially since my skillz are pretty much limited to setting links. I don't know if it's worth a lot of effort to backport digiKam 2.x to 11.4 and 11.3. Especially not if it means doing weird, messy stuff to the package in KDF. Again, some packages failing to build in KUA does not hurt any users. Of course it's a problem when actual published binaries are broken, but that's two completely unrelated issues. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Montag, 3. Oktober 2011, 23:55:44 schrieb Cor Blom:
I have no clue about obs building, so I might be completely wrong. But before this was done via a package digikam-sharedlibs. If that spec-file is still around somewhere could you not use that or is there another thing which causes a lot of work? I build digikam as well from git on openSUSE 11.4 but only locally.
I can do a submitreq somewhere, but because KUA is mainly links, I do not really know how to do this. But maybe this can help.
Do packages in KUA have to be links? This would mean that by design some packages would have to be dropped during the life-cycle of a distro version. So why not replace the links by packages in case a new version does not build or another build process than with KDF is necessary? If others would comment on this it could be decided here otherwise at the next meeting. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Søndag den 2. oktober 2011 12:24:28 skrev Sven Burmeister:
At least it should be possible to remove the broken packages. But 11.3 will die in a few months anyway. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am 03.10.2011 18:03, schrieb Martin Schlander:
At least it should be possible to remove the broken packages. But 11.3 will die in a few months anyway.
don´t be sure about it. Maybe some of the evergreen guys will take it over... Kim -- -o) Kim Leyendecker /\\ openSUSE Ambassador, openSUSE Wiki Team DE _\_v http://www.opensuse.org - Linux for open minds -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Montag, 3. Oktober 2011, 18:03:58 schrieb Martin Schlander:
At least it should be possible to remove the broken packages. But 11.3 will die in a few months anyway.
Indeed. It does make a bad impression if repos are broken, no matter whether 11.3 will run out in months or not. So if UpdatedApps does not get the attention that would be needed to recommend it (remember that this was the repo managed by opensuse staff) it should be removed from the community repos list offered in YaST. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Mandag den 3. oktober 2011 18:42:18 skrev Sven Burmeister:
Even if it was maintained by someone who knew what they were doing, it's very unlikely anyone would test all the packages on all suse versions and archs. KUA is using a distinct "if it builds, ship it!" policy. Noone reported any problems until now, so I don't think it would have made a difference if someone else maintained it. Even though it's in the community repos list, it's still an unsupported repo, and some minor risks should be accepted. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Montag, 3. Oktober 2011, 18:47:42 schrieb Martin Schlander:
It's not about testing but simply not having it broken for weeks. A repo which is basically unmaintained should not be offered on the community repos list. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Mandag den 3. oktober 2011 18:56:30 skrev Sven Burmeister:
And how are you supposed to know it's broken without testing it and noone reporting there's a problem? -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On 3 October 2011 20:15, Martin Schlander <martin.schlander@gmail.com> wrote:
In this specific case just looking at https://build.opensuse.org/project/monitor?project=KDE%3AUpdatedApps The last successful build of digikam was on 2011-07-22. Let's face it, KUA is unmaintained... -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Mandag den 3. oktober 2011 21:37:32 skrev Cristian Morales Vega:
The way it works is that when some new app appears in KDF it's linked to KUA - if it builds it builds - if it fails it shouldn't hurt anyone. You can't expect everything to build on old 11.3. E.g. digiKam 2.x failing to build on 11.3 is not really a problem. In fact it's expected. This does not serve as a hint to anyone that digiKam 1.9 binaries are broken on 11.3. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On 3 October 2011 20:51, Martin Schlander <martin.schlander@gmail.com> wrote:
It also fails in 11.4, the latest stable release.
If every maintainer of KUA agrees in that this is the level of support that should be expected OK. But then you have my vote to raise the minimum level of support required to be in the community repos list and remove KUA from it. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Mandag den 3. oktober 2011 22:13:31 skrev Cristian Morales Vega:
Well. If one broken published binary on an old distro version, ever, is enough to remove a repo from the community repos list, then you can remove all of them, including packman and mozilla. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Dienstag, 4. Oktober 2011, 08:24:38 schrieb Martin Schlander:
The mozilla repo seems pretty green, 100% for 11.4 and one package failing for 11.3 and that's a branding package. I have not tested every package in KUA and you might be right that all the ~20 packages failing might not be published – nevertheless they fail. And the issue is not that there is one broken binary but simply that there is nobody checking whether it builds within KUA and to fix it within hours/days (reverting to a version that builds within KUA), i.e. no maintainer. Packman has a huge number of packages, so I'm not sure it is comparable but mozilla certainly does have a maintainer who is even active on the mailing list answering questions regarding issues with the packages. I do not see the issue with having "all green" as a target for repos which are offered in the community repos list. If there are any recommended repos at all it's those that are on the community repos list. If there are no resources for that fair enough but then one should just remove it. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Tirsdag den 4. oktober 2011 10:52:23 skrev Sven Burmeister:
This is the last time I repeat myself. Users are not affected by build failures. Noone is. The amount of "red" and build failures couldn't be less significant - especially not in a repo for leaf packages only. It's a complete non-issue. What does matter is the binaries that actually get published for users. If the build fails, the package isn't published. And the "old" binary remains in the repo. That is why users still see digikam 1.9 in KUA, when digikam 2.0 fails to build. The brokenness of digikam 1.9 on 11.3 has absolutely NOTHING to do with digikam 2.0 or any other package in KUA failing to build. And digikam 2.0 or any other package in KUA failing to build does not hurt ANY user. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Dienstag, 4. Oktober 2011, 11:46:52 schrieb Martin Schlander:
To repeat myself again. There is no maintainer for KUA! QA is not given. That's all that matters. How do I know? Simply because there would not be a broken 1.9 package in there months after it built correctly (if ever) last time if somebody cared. And that's exactly the problem which I think you ignore. Unless there is an active maintainer it does not belong on the community repos list. And another thing you ignore is that all those supposedly not hurting build failures hide feedback regarding the published packages. The repo monitor and the repo content are not in sync and thus this makes it even more difficult to know which packages are ok in the repo but failing to build or failing to build and broken in the repo as well. So what you do when seeing a build failure in KUA is to assume that it's ok since there are the last working binaries still in the repo. You don't know and that's simply not enough for a repo to be recommended, i.e. part of the community repos list. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Tue, Oct 4, 2011 at 12:12 PM, Sven Burmeister <sven.burmeister@gmx.net> wrote:
The build status tells you absolutely nothing about whether the package works when installed. Packages can be, and are, green across the board and still fail to install or fail when running (in fact I am currently fixing a problem with wine where it builds but refuses to install in Factory). OBS does not check whether packages work when installed. So even if it built successfuly that would still not be enough to assume the binaries work. -Todd -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Dienstag, 4. Oktober 2011, 14:23:53 schrieb todd rme:
So? I never claimed it would be enough. But it would be more than having a failing package. Currently the build status is unknown or failing and there is no info about the binary working or not. How can that be any better than having it built correctly? Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Tirsdag den 4. oktober 2011 12:12:11 skrev Sven Burmeister:
To repeat myself again. There is no maintainer for KUA! QA is not given. That's all that matters.
KUA has at least the same level of QA as any other unsupported OBS repo, i.e. none - except the maintainer himself (that would basically be me, though I call in the cavalry when I become aware of significant problems I cannot fix) using most of the packages on one specific distro version and arch. All QA besides that depends on users reporting problems. This is the same as for any other OBS repo, whether in the community repos list or not. Since KUA is limited to links to KDF the packages will actually have been tested somewhat before entering KUA, although in a different environment.
You still have not explained how the maintainer is supposed to fix something noone reported is broken. Or how he's supposed to know it's broken without testing every package on every distro and arch. Which doesn't not happen for any package in any unsupported OBS repo - whether in community repos list or not. On 11.4 the digikam 1.9 package works fine afaict. Btw. the offending digikam 1.9 package has now been wiped for 11.3. So no more 11.3 users will have any problems because of it. Thanks for reporting the problem. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Dienstag, 4. Oktober 2011, 14:27:01 schrieb Martin Schlander:
As stated in one of my first emails KUA/Backports was once maintained by opensuse staff and at that time this was one of the main reasons to put it on the community repos list. So there was a decrease in QA which should be reflected in its recommendation status. It seems that while there was a distinction between Community and Backports repo back then, now there is not anymore.
Whatever the test was, it failed in this case.
You still have not explained how the maintainer is supposed to fix something noone reported is broken.
Usually the maintainer should check the build status – which is obviously impossible if "does not build does not mean anything" applies. And I still don't get why there is only the choice of having links rather than the last version that works with distro x.y. If there ever was a working digikam version the maintainer should check whether a new version builds. If not the source for that distro should be reverted to the building version. Or even let Cor take over if he can build digikam even for 11.3.
That's why "it does not build does not mean anything" is dangerous, because it hides the first "warning", i.e. the build status. Building does not mean it works but not building is even less informative. Further if there are any changes that demand a rebuild of the package that won't happen. People are stuck with some binary. To me that sounds like Playground.
Wiping is not really what I would call maintaining a package or fixing a problem. I can understand that you do not have enough time to do it in another way but removing is giving up maintainership and not maintaining. So that's why I agree with Cristian that KUA is basically unmaintained. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On 4 October 2011 13:27, Martin Schlander <martin.schlander@gmail.com> wrote:
As an 11.4 user I ask myself: - Who will patch the digikam 1.8 package from the main repo if there is ever a security issue? The security team. - Who will patch the digikam 2.2 package from the KDF repo if there is ever a security issue? There are two independent teams here. At the very minimum upstream will do it (and the KDF maintainers will publish the update from upstream). And I expect the security team and/or the KDF maintainers to also do some basic checks since those packages have to go to Factory. Perhaps it's not as secure as the package from the official repo, but it gives me some confidence to know someone is watching it. - Who will patch the digikam 1.9 package from the KUA repo if there is ever a security issue? Upstream is NOT going to. KDF maintainers are NOT going to. Who is going to then? And that's the simple reason why packages should build. Trust in a package is a temporal state that disappears the moment the maintainer published an update. What I really trust is the maintainer, not the package, and the maintainer can only transfer that trust to the LATEST package. I even stop trusting the packages from the official repo once an update is published in the updates repo...
So KUA users should check themselves for security issues and report them to you? Well, perhaps that should be the official minimum for a repo to be in the list: "We don't make any promises about how long it will take to fix security issues. But YOU will NOT need to check for security issues in the packages from these repos." -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Dienstag, 4. Oktober 2011, 17:03:56 schrieb Cristian Morales Vega:
I thought about that issue too – but the answer you will get is that every user who uses any obs repo accepts the risk of doing so and thus has to care about any issues himself. Not nice, certainly not something to make openSUE more popular, but given the resources kind of understandable. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Montag, 3. Oktober 2011, 21:51:05 schrieb Martin Schlander:
Nobody expects that. But what I thought that one could expect is that all packages in it build, i.e. are not broken. So if digikam 1.9 is the last version that builds fine for KUA it should be in there and not updated to 2.0.
See above. If a version does not compile for distro x.y it should not be included in KUA. Everything that is in the repo and installable via YaST should work. Of course there can be issues if a new version is introduced but then it should be fixed ASAP after it was noticed. If the latter does not work within days or a week max then the repo should not be on the community repo list, IMHO. I'm not saying that one can demand anything from anyone, just that whatever repo is put on the community repo list must have a certain QA standard and be maintained. If those standards cannot be met then the repo has to be removed. In case of digikam there is a tarball which contains all necessary libs, so it should be buildable, but I might be wrong about that. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Op 03-10-11 23:15, Sven Burmeister schreef:
I have looked into building digikam 2 on vanilla 11.4 with original KDE some time ago. The tarball does indeed have the necessary libs, but KDF is using these libs external. It is a lot of work to build with "internal" libs. The easiest way is to add the necessary packages to KUA (including some KDE 4.7 stuff). I have done this successfully in my home prj. See https://build.opensuse.org/project/show?project=home%3Acornelisbb%3Adigikam The only thing is that an extra patch is necessary to force use of external libs on KDE 4.6 (I have called it "digikam-force-external-libs-4.6.patch"). The result is a nicely working digikam on vanilla 11.4. I can do a submitreq somewhere, but because KUA is mainly links, I do not really know how to do this. But maybe this can help. Regards, Cor -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Mandag den 3. oktober 2011 23:55:44 skrev Cor Blom:
It would certainly be nice if someone would help out with KUA. Especially since my skillz are pretty much limited to setting links. I don't know if it's worth a lot of effort to backport digiKam 2.x to 11.4 and 11.3. Especially not if it means doing weird, messy stuff to the package in KDF. Again, some packages failing to build in KUA does not hurt any users. Of course it's a problem when actual published binaries are broken, but that's two completely unrelated issues. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Montag, 3. Oktober 2011, 23:55:44 schrieb Cor Blom:
I have no clue about obs building, so I might be completely wrong. But before this was done via a package digikam-sharedlibs. If that spec-file is still around somewhere could you not use that or is there another thing which causes a lot of work? I build digikam as well from git on openSUSE 11.4 but only locally.
I can do a submitreq somewhere, but because KUA is mainly links, I do not really know how to do this. But maybe this can help.
Do packages in KUA have to be links? This would mean that by design some packages would have to be dropped during the life-cycle of a distro version. So why not replace the links by packages in case a new version does not build or another build process than with KDF is necessary? If others would comment on this it could be decided here otherwise at the next meeting. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
participants (6)
-
Cor Blom
-
Cristian Morales Vega
-
Kim Leyendecker
-
Martin Schlander
-
Sven Burmeister
-
todd rme