Re: [Bug 1614203] Re: [MIR] unity-scope-click
On Tue, 2016-09-20 at 16:57 +, Michael Terry wrote: > OK, so with [1] I'm feeling a little better about the departments.db > mystery. There still doesn't seem to be information about which > clicks > are listed in the database, and thus which clicks you should have > installed before running the init-departments tool. If I'm > understanding how the tool works... But this is a step in the right > direction anyway. Hopefully the db will go away quickly regardless. Yes. If I'd had the time, the db would be gone today. We just didn't have time to do that for yakkety. As we move to only supporting snaps in the scope over the next few months, it will definitely be going away. > So all that's missing is someone committing to fixing bug 1532358 (or > apparently, from latest reports, committing to working around it). > They > don't have to fix it right now, I just want to be assured that > someone > that cares about it is working on it, or will work on it soon. Yes, Marcus is working on trying to create a minimal example which shows the crash, so we can properly report the issue upstream. There are some similar issues which seem to be fixed by another branch, but we may be hitting a specific corner case in the scope. Hopefully it won't take long to resolve that issue, but I can at least say it is definitely being worked on right now. -- 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1614203] Re: [MIR] unity-scope-click
I've been trying to explain that there really is no reason to need to perform an update of this file, unless we are releasing a new phone/tablet in a new country. However, I have made a branch which more clearly states how to update the file with new languages, in an MP: https://code.launchpad.net/~dobey/unity-scope-click/initdb- readme/+merge/306135 For the autopkgtests issue, we are committed to getting it fixed (and even have MPs to do so now, but we are unable to land the fix for this due to a race condition causing a crash when the scope is killed, in Qt 5.6, due to the change to use threads for async in QDBus. Once we can get that bug fixed, we'll be able to land the change to re-enable the autopkgtests. With those two things under way, along with the python3 packaging fix, can we move this MIR along to be approved then? On Tue, 2016-09-20 at 15:28 +, Mathieu Trudel-Lapierre wrote: > After further discussion on the subject; it's arguable that the > departments.db file is data and not code, so not a blocker for main > inclusion. I'll file about about just how clunky the process is > though; > I think this is a definite target for improvement of the package. > Please > see about including a README file (as mentioned by mterry) on how to > prepare the update to departments.db when doing a new upload of > unity- > scope-click. This way we have less risk of omitting the update > process, > or someone without deep knowledge of how the package works can do a > drive-by fix/update of the cache. > -- 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1614203] Re: [MIR] unity-scope-click
On Fri, 2016-08-19 at 14:11 +, Michael Terry wrote: > OK, maybe I was overly grumpy last time I commented, I didn't mean to > sound hostile. > > --- > > As for the autopkg tests, you're right that building the package is > something. > > But one of the goals of a MIR is to ensure that packages are well > maintained. And letting the integration tests bit rot for six months > is > not a great sign. > > Ideally either the unity-scope-click maintainers would have gone down > a > stack and committed to fixing the harness or applied enough pressure > to > the harness maintainers to commit to fixing it. > > Neither happened, which is why I'm a touch worried that we'll never > get > to the point of turning the integration tests back on, simply because > no > one is working on it. > > Can you commit to putting resources into it or find someone that can? > According to the bug it's easy to reproduce. Just a little hard to > fix. I can't personally commit to it, but I've asked if someone more knowledgeable of the python test harness code than I am, could be scheduled to look at it. Hopefully it turns out to be an easy fix. > --- > > As for the database, yes an sqlite database isn't quite as bad as an > executable blob sitting there. > > Someone *could* generate the same database, *if* they knew which > locales > were specified on the command line *and* what clicks were installed > on > the system at the time (right, it pulls list of clicks from the > installed set?). > > At a minimum, I'd like to see some documentation. Like a README > saying > "install latest Touch image and run 'init-departments my.db en_US > zh_CN > fr_FR' to get this same db". > > But what I'm trying to get at is, can we make it more generate-able? > Like... Can we hardcode the list of clicks and just grab those > translations from the store? It doesn't solve the fact that we need > to > hit the network for translations, so we still can't generate the db > at > build. But at least it could be generated straight from a built tree > rather than having to set up a separate Touch system. No I don't think we can make it easier to generate the db at build. The database doesn't need to be re-generated cleanly every time either, so there isn't a need to set up a BQ phone image to run it on. There is a README in the sub-directory for the tool in the source tree, which states how to call the command. I don't know that we'll have time to make this better for yakkety release, but there are a few bugs about the init-departments tool filed, and as many of the assertions about how we need to handle departments are no longer valid (and we won't really be supporting clicks on yakkety+ anyway), what we really want to do here is just get rid of the tool and thus the pre-seeded cache completely. There's some higher priority work than trimming that fat at the moment though, like fixing the scope so that we can launch apps from snaps instead of just clicks. As soon as yakkety-proposed clears up and I can get those bits finished, I might have some more time to poke at the lower hanging fruit of removing that database and just including the translations locally. -- 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1614203] Re: [MIR] unity-scope-click
On Thu, 2016-08-18 at 19:52 +, 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1614203] Re: [MIR] unity-scope-click
On Wed, 2016-08-17 at 21:00 +, Michael Terry wrote:
> - Bug 1532358 was worked around by just not running autopkg tests.
> That's not an ideal response (understandable short term, but it's
> been
> six months). Any word on what it would take to re-enable them?
We still run autopkgtests. 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.
> - How is the default departments.db generated? I don't see a target
> in
> the source. It's bad form / against policy to ship binary files in a
> source tarball like that without their source.
With the init-departments-db tool in the source. Hopefully we can get
rid of this tool, and the departments.db in the future, as it appears
we'll have something else for snaps, and the reason we had to do it
this way is no longer valid. This is really just an initial cache
though.
> - This needs a team bug subscriber from our package-subscribers list.
> Maybe phablet-team or unity-api-team? I see ubuntuone-client-
> engineering is subscribed, but maybe ubuntuone-hackers would work
> then?
I've already subscribed unity-api-team today, but maybe you checked
prior to that.
> - ${python:Depends} should be ${python3:Depends} for the autopilot
> package and --with python3 should be passed to dh to fill that
> variable
> out (with a dh-python build-dep).
Can you file a separate bug for this (fixing it obviously doesn't
resolve the MIR, but would like a bug to link to)?
--
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
