[07:18] <dholbach> davidcalle, I think I'm getting closer to finding the issue wrt dropping pages after import
[07:18] <dholbach> lots of debug statements and lots of hard looking at terminal output has helped some
[07:18] <dholbach> I'll keep you posted
[07:27] <davidcalle> Morning o/
[07:27] <davidcalle> dholbach: my hunch is that it has to do with the diff checking. When there is no diff between the import and the current page, it drops the page. I haven't looked at it closer, though.
[07:29] <dholbach> davidcalle, I was able to create a test-case for it, so I hope to have it resolved soon and we will never hear from the issue again
[07:29] <dholbach> davidcalle, mhall119: let's have a call some time when things are a bit less crazy to move all of us to postgres for good :)
[07:29] <davidcalle> :)
[07:30] <davidcalle> dholbach: what, the plan is not to lobby the web team to get all sites moved to mysql?
[07:30] <dholbach> sqlite for all the things!
[07:31] <davidcalle> \o/
[07:35] <dholbach> I love starting to work from something like:
[07:35] <dholbach> FAILED (failures=1)
[08:25] <davidcalle> dpm: dholbach: does that look accurate to you? (new IA redirects)
[08:25] <dholbach> davidcalle, on staging?
[08:25] <davidcalle> dholbach: dpm: link -> http://paste.ubuntu.com/15625545/ :)
[08:27] <davidcalle> My first iteration on this is quite simplistic. Check if the url starts with $lang/$from, replace with $lang/$to, check if new url exists, if yes: redirects.
[08:27] <dholbach> davidcalle, it looks like it matches what's in proposal #1
[08:28] <dholbach> one thing we might want to think of is how we structure the "phone - get started" journey
[08:28] <dpm> davidcalle, looks good to me, not sure about bringing "web" one level deeper
[08:30] <dpm> anyway, we can talk about it in a minute in the call. We might actually need more than 30 mins if we want to go deep into the landing page and the redirects
[08:30] <dholbach> davidcalle, you're a hero
[08:31] <davidcalle> dpm: dholbach: joining the call in 2 min, need to find a room.
[08:32] <dholbach> ok
[10:02] <davidcalle> dholbach: https://code.launchpad.net/~davidc3/developer-ubuntu-com/redirects-on-404-1/+merge/290963
[10:05] <dholbach> davidcalle, checking
[10:05] <davidcalle> I don't like hardcoding them, but I haven't found a way to properly override 404 methods in Django CMS, so it's for the sake of having them asap
[10:06] <dholbach> understood
[10:12] <dholbach> nice work!°
[10:12] <dholbach> very quickly done and just affects actually existing pages which are being redirected
[10:12] <dholbach> for this we could write tests later on as well
[10:13] <dholbach> not for this deployment, but along with an admin interface, this could be easy to test
[10:13] <davidcalle> dholbach: thanks, yes, I'm not sure if js redirection will be easy to test though
[10:15] <davidcalle> thinking out loud, but maybe the js code could live in another template, attached to a django redirect app, with a proper model and admin panel, then call it from the 404 template
[10:15] <davidcalle> Anyway, pushing to staging :)
[10:19] <dholbach> mh, maybe not so easy to test :)
[10:20] <dholbach> at least not with django.test.Client
[10:20] <dholbach> anyway: good work! :)
[10:23] <davidcalle> *duc autopilot will fix everything*
[10:32] <dholbach> <3
[11:52] <dholbach> davidcalle, I think I found the problem - let me see if it fixing it the most straight-forward way causes any other fallout :-)
[11:53] <davidcalle> dpm: can you set the size of the RT to XS and the urgency to uber-critical ;-) ? https://portal.admin.canonical.com/90349
[11:53] <davidcalle> dholbach: what is it?
[11:54] <dholbach> davidcalle, I think it is http://paste.ubuntu.com/15628202/
[11:54] <dholbach> ie when publishing ALWAYS return the public object, not the draft
[11:54] <dholbach> just running the testsuite on both sqlite and postgres
[11:55] <dholbach> that's the longest I ever spent on unindenting two lines of python code /o\
[11:55] <davidcalle> lol
[11:55] <dholbach> now let's hope it doesn't break anything else :-)
[11:56]  * davidcalle crosses fingers
[11:57] <davidcalle> dholbach: good luck ;) I'll start on creating /desktop
[12:17] <dholbach> https://code.launchpad.net/~dholbach/developer-ubuntu-com/fix-double-imports/+merge/290978
[13:06] <mhall119> dholbach: what do you mean "move all of us to postgres for good"?
[13:06] <mhall119> are you talking local development?
[13:07] <dholbach> yes
[13:42] <dpm> davidcalle, which syntax do you generally use on d.u.c pages with CLI instructions?
[13:44] <davidcalle> <div class="twelve-col"><pre><code>...</code></pre></div>
[13:44] <davidcalle> dpm ^
[13:44] <mhall119> dholbach: does the ubucon deployment use a local pip-cache like devportal does?
[13:44] <dpm> thanks davidcalle
[13:44] <mhall119> or will it pull and install from pypi?
[13:44] <dholbach> mhall119, I found it impossible to work with the instructions that were provided
[13:44] <dholbach> it didn't work at all for me
[13:44] <mhall119> what didn't?
[13:45] <dholbach> the juju layers stuff
[13:45] <dholbach> so I just did what's in the new README.local.md file
[13:45] <mhall119> ok....so is that a "no, it doesn't use pip-cache"?
[13:45] <dholbach> that's a "I don't know"
[13:46] <dholbach> I tried to understand it and replicate it locally, but I couldn't
[13:46] <dpm> mhall119, I think the issue is that after the website's deployment migration to juju layers no one knows how it all works
[13:46] <mhall119> ok, where is the charm code? I'll take a look at it
[13:46] <dpm> mhall119, for me, the local deployment worked the last time a few months ago, but seeing that it's not working for dholbach, something must have changed in the meantime in juju
[13:47] <mhall119> dholbach: is README.local.md in the charm code?
[13:47] <dholbach> mhall119, check the other README.mdf
[13:47] <dholbach> mhall119, check the other README.md
[13:47] <dholbach> mhall119, no, that's added in my MP
[13:47] <mhall119> ok
[13:47] <dpm> https://code.launchpad.net/ubucon-site
[13:47] <dholbach> that's what I did to run it locally
[13:47] <dpm> the ubucon-layer series in there contains the juju code
[13:49] <mhall119> ok, it doesn't *look* like it uses a local pip-cache, and even if it does it would be the django layer doing it, not our code, which is all I really needed to know to do this review
[13:53] <mhall119> dholbach: does aldryn need libxml2-dev and libxslt-dev from apt-get?
[13:53] <dpm> thanks davidcalle, using that now
[13:54] <dholbach> mhall119, I can't quite remember which of the pip bits needed these to compile
[13:54] <dholbach> let me retry it
[13:54] <mhall119> dholbach: but something does? If so, we need to have them added to the ubucon-layer branch
[13:55] <dholbach> mhall119, I'll let you know in a minute
[13:56] <dholbach> mhall119, it's aldryn-newsblog → lxml
[13:56] <dholbach> which makes sense
[13:57] <mhall119> ok, then those two need to be added to http://bazaar.launchpad.net/~ubucon-site-developers/ubucon-site/ubucon-layer/view/head:/django.yaml
[13:59] <dholbach> not that I know what I'm doing, but I'll send an MP
[14:02] <dholbach> I'll ping jcastro and marcoceppi
[14:02] <dholbach> mhall119, thanks for helping to figure this out
[14:03] <dholbach> mhall119, does a local test work for you or didn't you get that far? shall we merge it into trunk and then just leave the layers branch and the deployment to Marco?
[14:07] <dholbach> mhall119, can you merge the branches - I'm not member of the team
[14:07] <mhall119> dholbach: I haven't tried a local test
[14:07] <dholbach> ok
[14:07] <mhall119> dholbach: you are now :)
[14:12] <dholbach> mhall119, that's not what I had in mind :-)
[14:12] <mhall119> I know :)
[14:17] <dholbach> do we want to land https://code.launchpad.net/~dholbach/developer-ubuntu-com/fix-double-imports/+merge/290978 too in this same deployment? or do we not want to confuse them?
=== dpm is now known as dpm-afk
=== dpm-afk is now known as dpm