[13:12] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: Jammin’ with Jami – Freedom, privacy, snaps @ https://ubuntu.com//blog/jammin-with-jami-freedom-privacy-snaps
[14:29] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: ROS 2 Foxy and ROS Melodic EOL – Keep your robots up and running @ https://ubuntu.com//blog/ros-foxy-ros-melodic-eol
[19:31] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: Ubuntu Pro is Now Available to Anyone Who Wants It @ https://www.omgubuntu.co.uk/2023/01/ubuntu-pro-general-availability (by Joey Sneddon)
[22:16] -SwissBot:#ubuntu-news- ::UbuntuOnAir:: Ubuntu Summit 2022 | Flavor and Release Team Panel Session @ https://www.youtube.com/watch?v=txq7nC1vyv8 (by Ubuntu OnAir)
[22:35] -SwissBot:#ubuntu-news- ::UbuntuOnAir:: Ubuntu Desktop Team Indaba - January 27, 2023 @ https://www.youtube.com/watch?v=vBHidYFpb9M (by Ubuntu OnAir)


[08:05] <dpm> good morning all
[08:29] <happyaron> morning david, !
[09:04] <dpm> hey happyaron :)
[09:06] <dpm> happyaron, there is internal discussion going on right now about the complete zh_CN desktop project. I'm sorry these are all the details I can give for now, but I just wanted to let you know, that after these last few weeks someone is already working at estimating the work, cost, etc.
[09:09] <happyaron> dpm: good to know, thanks!
[09:10] <dpm> happyaron, np, I'll keep you updated as soon as I get more news :)
[09:11] <happyaron> :)
[09:12] <TLE> dpm: hey
[09:12] <dpm> good morning TLE
[09:13] <TLE> How's it going with the server setup, had any time to work on it?
[09:18] <dpm> TLE, unfortunately no, I'm sorry :( The server is online and out there, but I've got django just half-configured -> http://<IP_ADDRESS>/
[09:21] <TLE> dpm: ok, did you know something about how to change this (db?) encryption (seed?) (in the settings file there is a "secret key" which I'm assuming has something to do with that and which has now been shared on LP), that I wrote about in the email, or should I try and look into that?
[09:22] <dpm> TLE, I haven't had the chance to look at it since you mentioned it. Just a sec, let me re-read the e-mail to remind myself of the details
[09:23] <TLE> dpm: yeah ok, it was just that if you knew then there would be no reason for me to research, but otherwise we might as well share the work
[09:26] <dpm> TLE, from what I understand, it seems regeneration is a matter of just rewriting a new value. I think this can be done manually or alternatively, by running django-admin.py startproject and copying it from there to the docs project. http://stackoverflow.com/questions/7382149/django-secret-key - as per keeping it secret: give me two mins to see what other projects do
[09:28] <TLE> dpm: Yeah I imagined as much, I think the best way is to figure out what magic command to execute to change it. Then we simply do that whenever we pull from lp, that way we can keep having a functioning version in lp (with public key) and regenerate when we pull to the server
[09:29] <TLE> I'll just read the post, but I think it is better to figure out how to change the key and regenerate, reinitializing the project will be a bit more work
[09:31] <dpm> TLE, I believe there is no command to change it, just django-admin will generate one and it will be used at runtime as far as I understand it - I'm not talking about regenerating the project, just running django-admin.py start project to create a dummy project and copy the generated SECRET_KEY value to the docs project. But looking at the LoCo directory project from loco.ubuntu.com, it seems they're not using one at all -> http://bazaar.launchpad.
[09:31] <dpm> net/~ltp-devs/loco-team-portal/0.2/view/head:/loco_directory/settings.py
[09:35] <TLE> dpm: hmm yes, if it is only used at runtime there that would work
[09:36] <dpm> TLE, I'm asking dholbach and mhall119, as they are loco directory hackers. Hopefully they should be able to tell us more - I hope we can set it to an empty value and forget about it
[09:37] <TLE> dpm: yeah
[09:45] <dpm> TLE, ok, so while waiting for a definitive answer, I think the current practice is to set the sensitive values to empty strings in the settings.py version kept under revision control, and then have a unique settings_local.py file on the server where the service it's running, the values of which are loaded. Here's what I've just read (sorry the result came only in Spanish, but google translate should do a good job at translating it, as the text is
[09:45] <dpm> quite technical) http://fitoria.net/2011/11/django-suite-ii-configurando-nuestro-proyecto-de-manera-correcta/
[09:49] <dpm> TLE, dholbach confirms that:
 dpm, it's set in local_settings.py
 so we don't have to share the actual value in the bzr branch
[09:50] <TLE> dpm: yes that makes sense, does he confirm also that the value is only used at runtime?
[10:01] <dpm> asking now...
[10:02] <dpm> TLE,
[10:02] <dpm> dholbach, we've already mistakenly shared the value on bzr. Do you happen to know whether we can just generate a new one, hide it in local_settings.py and forget about it? Or can it only be generated at the start of a project?
 yes
 yes to 'we can just generate a new one...'?
 yes
[10:02] <dpm>  :)
[10:11] <TLE> dpm: great. I'll make the change
[10:12] <TLE> on another note, I have had a little time to think about the directory structure and I might just change it again, but as long as you are still settings up the server I guess that is ok
[10:14] <TLE> sorry about flipflopping on this, I think I should have given it a little more thorough thought to begin with
[10:16] <TLE> no actually, now I'm _sure_ I need to change it, I'll fix it and let you know
[10:17] <dpm> cool, yeah, no worries at all about changing structure. Even if I had gotten to set it up with the old structure, it should not be too hard to move things around
[10:18] <TLE> dpm: great