[01:31] <wgrant> cjwatson: Should I revert your pytz upgrade?
[07:19] <cjwatson> wgrant: I think so, haven't heard anything from stub as yet regarding my pytz fixes
[07:19] <stub> ?
[07:19] <cjwatson> 13:19 <cjwatson> stub: Would it be possible to get a new pytz release with https://code.launchpad.net/~cjwatson/pytz/smarter-utcoffset/+merge/245472 or similar soonish, or should I be looking to revert my Launchpad commit that upgraded to 2014.10?
[07:21] <stub> cjwatson: Is this https://bugs.launchpad.net/pytz/+bug/1319939 ?
[07:21] <mup> Bug #1319939: 2014.3 tz change in US/Central looks wrong <pytz:Opinion> <https://launchpad.net/bugs/1319939>
[07:25] <cjwatson> Hm, possibly related
[07:25] <cjwatson> Does that mean you think the LP test suite should just avoid exercising these cases?
[07:26] <cjwatson> (I didn't find that bug because Opinion.)
[07:28] <wgrant> Aha, hi.
[07:28] <wgrant> Welcome to the team.
[07:29] <cjwatson> Thanks :-)
[07:33] <wgrant> cjwatson: It looks like only that one test is broken because of it?
[07:33] <wgrant>     >>> sending_date = datetime(
[07:33] <wgrant>     ...     2008, 5, 20, 10, 5, 47, tzinfo=pytz.timezone('Europe/Prague'))
[07:33] <wgrant> evil!
[07:33] <wgrant> Easy fix :)
[07:33] <stub> cjwatson: You should avoid those cases, because using the 'latest' timezone may break too.
[07:34] <stub> cjwatson: Or better yet, fix things to correctly construct the localized datetime instances.
[07:34] <stub> I need to steel myself to write some C code, so I can get this all sorted in Python core :-P
[07:35] <stub> Unless I can find a volunteer
[07:36] <cjwatson> wgrant: There were two or three, I think.
[07:36] <stub> Ahh... there is the MP. In my 'reviews' folder, with 16k other unread emails. I think I need to improve those filters.
[07:36] <wgrant> cjwatson: The others all look like the AxxT short name changes.
[07:37] <cjwatson> Oh, no, you're right, it was just that one.
[07:37] <wgrant> (upstream was finally convinced to prepend "A" to all the Australian timezonse)
[07:37] <cjwatson> Yeah, already have a testfix branch for that.
[07:37] <wgrant> Which we've been wanting for well over a decade.
[07:37] <wgrant> Excellent.
[07:37] <cjwatson> OK, I'll soup it up to fix the bugnotification test too to avoid that
[07:37] <cjwatson> The default timezone __repr__ just seemed sufficiently bizarre that I thought that was going to need a fix :-)
[07:42] <wgrant> Heh, yeah...
[07:43] <wgrant> now really does seem like a better option, but perhaps that's an argument for why it shouldn't be the default.
[07:43] <wgrant> At least this makes the bug obvious.
[08:13] <cjwatson> wgrant: https://code.launchpad.net/~cjwatson/launchpad/testfix-pytz-2014.10/+merge/245547
[08:13] <wgrant> cjwatson: Yay
[08:13] <wgrant> Thanks.
[08:14] <cjwatson> Landing
[11:49] <cjwatson> wgrant: Do you have a bootstrap.py incantation handy that works in lazr.anything?
[11:49] <cjwatson> I keep getting variants of "pkg_resources.VersionConflict: (setuptools 0.6c11 (/tmp/tmpQjsW5z/setuptools-0.6c11-py2.7.egg), Requirement.parse('setuptools>=8.0'))", and my attempts to fix this aren't making things better ...
[11:52] <stub> Your only going to get a version of setuptools that recent via pip or buildout
[11:52] <wgrant> cjwatson: Where did you obtain that bootstrap.py, and how are you invoking it?
[11:52] <wgrant> There was also a setuptools debacle recently.
[11:52] <wgrant> Where they unreleased a version.
[11:53] <wgrant> Though that was setuptools 10.2, so not relevant.
[11:56] <cjwatson> wgrant: lazr.yourpkg
[11:56] <cjwatson> and "python bootstrap.py", after symlinking in download-cache and eggs per https://dev.launchpad.net/HackingLazrLibraries
[11:57] <cjwatson> (in a precise LXC instance)
[11:58] <cjwatson> actually, sorry, I replaced that bootstrap.py with http://downloads.buildout.org/1/bootstrap.py after previous problems ...
[11:58] <cjwatson> stub: yeah I don't actually want a newer setuptools and haven't asked for that; have not been able to puzzle out where that requirement is coming from
[11:58] <stub> I imagine one of the buildout dependencies is modern setuptools, so it needs to be installed before buildout (in the python venv, or package or pip I guess?)
[11:59] <cjwatson> wgrant: but lazr.restful (say) behaves this way if invoked via "python bootstrap.py" on precise
[12:00] <cjwatson> oh, here, "python bootstrap.py --setup-source=ez_setup.py --download-base=download-cache/dist --eggs=eggs --version=1.7.1" at least bootstraps ... what a mess
[12:01] <stub> That is a polite way of putting it
[12:01] <cjwatson> (but then bin/buildout fails)
[12:01] <wgrant> cjwatson: The incantation should be in the various makefiles of things that have been touched recently.
[12:04] <cjwatson> I don't suppose you have an example?  The only ones I can find that have a Makefile just have python bootstrap.py or python -S bootstrap.py.
[12:05] <cjwatson> And lazr.uri make fails in both precise and vivid.
[12:05] <wgrant> lazr.restful(client) should work.
[12:05] <wgrant> I think
[12:05] <wgrant> Let me see.
[12:05] <xnox> i have been removing bootstrap support and moving towards "normal" setuptools + python setup.py test
[12:06] <xnox> however there is a magical set of commands that do work with bootstrap/buildout
[12:06] <xnox> (none of them work with python3, and one needs to do bootstrap of the bootstrap utils first to make sure none of the system things (e.g. setuptools) are used)
[12:07] <xnox> sigh, my working rebootstrap script is in ~/bin/ on my laptop and not with me atm, so I can't share it with you.
[12:23] <cjwatson> Maybe I should just leave whatever broken bootstrap crap comes from lazr.yourpkg in place, ignore it, and just use setup.py directly.
[12:23] <cjwatson> But I kind of want to get versions.cfg right.
[12:27] <xnox> yes, versions.cfg is nice. but it's a pain to use/update at the moment. As most of versions listed there are obsoleted (e.g. much newer stuff is on pypi and in precis/trusty)
[12:28] <xnox> and it does not work in python3.
[12:28] <xnox> =/
[12:33] <cjwatson> Sure, but for something that will be imported into the main Launchpad tree I need to make sure that it's at least buildout-compatible.
[12:36] <wgrant> cjwatson: The versions.cfg in the lazr project is only relevant for development.
[12:37] <wgrant> Likewise any buildout or bootstrappery.
[12:37] <wgrant> Launchpad's buildout and versions.cfg are used when it's imported into LP
[12:38] <wgrant> xnox's approach is probably best, at least for simple cases like this.
[12:45] <xnox> cjwatson: wgrant: Happy New Year! =) all the awesomely best in this year ;-)
[12:46] <wgrant> xnox: Likewise! Hope you're doing well in your new role.
[12:48] <xnox> wgrant: i think so ;-)
[12:50] <wgrant> :)
[14:23] <cjwatson> OK, using a venv to run bootstrap.py and then using "bin/buildout buildout:install-from-cache=true buildout:download-cache=download-cache buildout:eggs-directory=eggs buildout:allow-picked-versions=false -v" appears to be working somewhat better
[16:31] <cjwatson> wgrant: Do you want to have a look over lp:lazr.sshserver before I call it 0.1?  I have an LP branch that uses it and passes the relevant tests.
[22:18] <wgrant> cjwatson: Were you able to reuse anything from lazr.yourpkg?
[22:57] <cjwatson> wgrant: Saved me figuring out the skeleton from scratch, I guess, and writing the basic generic docs
[22:57] <cjwatson> wgrant: I kept most of buildout.cfg too
[23:00] <wgrant> cjwatson: Sounds good. I'd split out poppy to make sure it's sufficiently reusable before releasing it, though.
[23:01] <cjwatson> Fair.
[23:02] <cjwatson> I'll grab that task and do it tomorrow.
[23:03] <wgrant> Thanks. The most non-trivial bit is probably the config.
[23:04] <wgrant> (txlongpoll was in a similar situation, and nowadays uses a yaml config file)
[23:09] <cjwatson> Yeah, that would make sense.  Its config isn't very complicated.
[23:10] <wgrant> It's also currently weird because it takes the path on the commandline, but the rest of the config in lazr.config.
[23:11] <cjwatson> wgrant: Used to; I don't think it does any more.
[23:12] <wgrant> Oh, true.
[23:30] <cjwatson> poppy will have to end up as lazr.poppy I guess, because
[23:30] <cjwatson> https://launchpad.net/poppy
[23:31] <elmo> pretty please rename it entirely?
[23:32] <elmo> it's one of the old katie style names
[23:32] <elmo> albeit less obvious than some
[23:32] <wgrant> Yeah, we always rename things when they're extracted.
[23:32] <wgrant> Or moved.
[23:32] <wgrant> If they had stupid names before.
[23:32] <cjwatson> Yeah, also fair.
[23:35] <cjwatson> lazr.uploadserver?  Bit generic but ftporsftpuploadserver is just no
[23:36] <wgrant> It is quite Debian-specific
[23:36] <elmo> anonymousdebianuploadserverbutcouldbeconceivablyusedforotherthings
[23:36] <wgrant> In that it has special behaviour on .changes files, etc.
[23:36] <cjwatson> Or maybe launchpad- since it's not really a reusable component in the lazr sense.
[23:36] <wgrant> I wouldn't call it lazr-, no.
[23:36] <wgrant> But it also won't be using any Launchpad-specific interfaces within a couple of months.
[23:37] <cjwatson> wgrant: changes> It does?  AFAIK its special behaviour is more about (S)FTP sessions.
[23:37] <elmo> heh, yeah, I stumbled across a bug from iwj complaining about that the other day
[23:37] <elmo> (suggesting it special case .changes instead)
[23:37] <elmo> 4 digit bug or something
[23:37] <wgrant> Huh, indeed.
[23:37] <cjwatson> Well, there's the distro detection thing
[23:38] <wgrant> The only special handling it has is for the .distro files, which are dreadfully obsolete anyway.
[23:38] <wgrant> I thought we deleted that code years ago...
[23:39] <wgrant> Oh, it used to have the .changes special case when it checked signatures.
[23:40] <cjwatson> Meh, will think about it tomorrow.  Night.
[23:40] <wgrant> Night!
[23:40] <wgrant> I hate naming things.