i think it's worth writing out a spec/proposed migration plan (e.g. to answer questions like what should happen if admin checks out 1.1.0 tag and does not re-run setup, how should the virtualenv be migrated, etc.). making securedrop-admin code python 3 compliant is not going to be the main work, it's mostly the migration
Sprint planning/retro notes can now be found on the wiki as well, and planning board / spreadsheet should be in sync.
Still a few more estimates to add, we can do so during Monday/Tuesday standups.
if anyone was looking at #4852 I've updated the PR with another dirty hack for the dynamic inventory.
As a reminder, no GMeet standup on Fridays, but quick updates to https://pad.riseup.net/p/SecureDropDailyStandup are appreciated :)
Hello everyone! Our standup is in 5 minutes at the usual location:
https://meet.google.com/ekb-kkhf-mrk
Anyone is welcome to participate! Notes are taken on an Etherpad and will be moved to the GitHub wiki by the end of the day.
Hello everyone! Our standup is in 3 minutes at the usual location:
https://meet.google.com/ekb-kkhf-mrk
Anyone is welcome to participate! Notes are taken on an Etherpad and will be moved to the GitHub wiki by the end of the day.
Hello everyone! Our standup is in 5 minutes at the usual location:
https://meet.google.com/ekb-kkhf-mrk
Anyone is welcome to participate! Notes are taken on an Etherpad and will be moved to the GitHub wiki by the end of the day.
looknig at fixing #4387 - would it make more sense to just not start the GUI updater if the amnesia user doesn't have a password set?
upside is it doesn't present the user with something they can't use, downside is that if they never log in with a password set, they never see the gui updater
@rmol @zenmonkeykstop are either of you planning to poke at the securedrop-admin py3 changes today? freedomofpress/securedrop#4867
It's basically the last day we have before QA
@rmol the app code dependencies are installed via ansible. it'd be a bit cleaner and more predictable if we allowed apt to resolve the package dependencies. I suspect we added the ansible install tasks, that essentially duplicate the app-code dependencies, in order to support the install-from-local-packages logic in staging. if we're using
dpkg for the deb install, which does not handle Depends on packages, perhaps we could use aptitude instead
i haven't actually confirmed that
aptitude will intelligently handle dependencies, but worth a look. that'll allow us to verify that the deps are what's determining the packages pulled in, not the ansible logic (which is seldom run)
@zenmonkeykstop your updater strategy sounds good! if you do reach a good stopping point, would appreciate if you could still get some review on #4867 in. if a merge is at all realistic today it's only going to be if both you and John have a chance to test it. If it looks good, Conor can potentially stamp it later.
@conorsch any preferred order of operations for merge? my sense would be that #4865 should go in first so the simpler operation (updating prompt_toolkit) can be applied on the new base
since those were authored by conor/kushal and need to get independent testing and review
effectively the diff review has already been performed by @emkll on #4865, so my +1 means two thorough reviews.
will grab some lunch and then take a swing at #4867