On Thu, 2016-08-18 at 19:52 +0000, Michael Terry wrote: > > > > We still run autopkgtests. > OK, in the most technical sense, you still run autopkgtests. But the > script you run only has some exports and a commented out exec line. > > So lets not be pedantic; there are no autopkgtests right now.
The script is there to satisfy the need for autopkgtests to run a script. What we do for the autopkgtests is require a built tree, which means when the autopkgtests run, the source is re-built and the same unit tests run during normal package build, are ran again during that build. We were also running the integration tests against the installed packages, but to work around the issues in the harness, we disabled the tests using the harness in both the normal build (run against the scopes built in the tree), and the run against the installed scopes packages. > > > > We just don't run the integration tests > > which depend on the python test harness for scopes, due to a bug. > > Until > > the bug is fixed, we can't really enable them, as they will be > > unreliable. > Yup, I know. "due to a bug" is bug 1532358, that I already linked > above. The bug where the plan was to temporarily disable the tests. > Six months ago. Yes. They are temporarily disabled until the issue is fixed in unity- scopes-shell. > So who's working on figuring out why the tests are flaky? Is every > single test flaky? All of them were disabled. Can we discover which > are flaky and can we selectively disable only them? Have things > gotten > more stable in the last six months? Nobody has been assigned to fix the larger issues in the scopes harness. It's not just that some tests are flaky, but that the scopes harness itself is flaky, and not that single tests were failing, but any one of the tests could fail arbitrarily. As in that bug report, the status on unity-scopes-shell for it has not changed, so no I don't imagine they have gotten more stable in the last six months. > That doesn't really address the issue -- which is binary blobs being > distributed without their "preferred form of modification" being a > violation of the DFSG. For example, what locales were used on the > command line? And it looks like you need a very particular setup > with > certain packages installed... But it's not just an arbitrary binary blob. It's an sqlite database. It's something which can easily be modified and has a well defined format (granted the schema in use may not be entirely well defined by certain standards). This is just a pre-seeded cache. > i.e. someone with just the tarball can't easily reproduce that > database With just what tarball? The unity-scope-click upstream source tree? Yes they can. The tool that generated the schema, and that was used to create the database, is all in the source tree. > See https://ftp-master.debian.org/REJECT-FAQ.html and its "Generated > files" entry. > > Is there a way we can generate the file on first boot? Or ship some > .desktop files in the package along with a script so that we can > generate the file during build? (Or build-dep on some packages to > get > access to their desktop files...) No. The translations are pulled from the server for the Ubuntu App Store (https://search.apps.ubuntu.com/) to build the database. However, as I mentioned, I do hope we can get rid of it and just ship the translations for the departments in the unity-scope-click domain in the future. There are some concerns about how snaps will have departments (or something like it) in the store, and all of the departments related code in the scope might end up being invalidated by that as well. It's not something we can easily change right now, but we are aware of the issues with database. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1614203 Title: [MIR] unity-scope-click To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+bug/1614203/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
