IRC logs for #baserock for Thursday, 2015-04-16

*** sambishop has quit IRC00:36
*** sambishop has joined #baserock00:36
*** zoli__ has joined #baserock03:45
*** zoli__ has quit IRC05:31
*** zoli__ has joined #baserock05:46
*** zoli__ has quit IRC06:00
*** zoli__ has joined #baserock06:19
paulsherwoodnovnc build is pulling from github i believe06:38
paulsherwoodhttp://paste.baserock.org/uzikowamek (baserock/openstack-v7)06:41
paulsherwoodalso librabbitmq seems to attempt to pull in a binary?06:41
paulsherwoodhttp://paste.baserock.org/esicufirox06:42
paulsherwood2015-04-06 23:48:09 [systems/openstack-server.morph] Finished :-)06:44
*** a1exhughe5 has joined #baserock07:10
*** Albert has joined #baserock07:13
*** mariaderidder has joined #baserock07:56
straycatpedroalvarez, okay cool sorry i'm building from baserock/openstack-v7 so i've merged it in there anyhow07:57
*** mdunford has joined #baserock08:08
straycatpaulsherwood, thanks for spotting that08:11
straycati also note that a package in the zookeeper stratum is being pulled in from github08:11
*** rdale has joined #baserock08:11
paulsherwoodaha.08:11
*** bashrc_ has joined #baserock08:16
*** Albert has quit IRC08:18
straycatjjardon, i've responded to your review of https://gerrit.baserock.org/#/c/321/2  you do have a point that the extension may not be entirely necesssary, however the alternative is to both add a unit file in the ntpd repo (creating a delta on upstream) and patch ntpd (creating a delta on upstream), i can be persuaded to make these changes at a later date if you really consider them necessary but right now we really need this change merged08:23
*** CTtpollard has joined #baserock08:25
jjardonstraycat: or put the unit file in the morphology file, so no delta needed :)08:28
SotKDoes anyone have a minute to +1 jjardon's gnome-common patch (https://gerrit.baserock.org/#/c/338/)? :)08:28
straycatfair point08:28
straycatjjardon, but we'd still need to patch ntpd08:28
jjardonBut sure, remember -1 in gerrit is only a -0: if the current approach works for you we can always fix it later08:29
straycatit works for me for the moment for sure :)08:30
paulsherwood+1, then :)08:30
*** ssam2 has joined #baserock08:31
*** ChanServ sets mode: +v ssam208:31
straycatjjardon, so this patch isn't actually gnome stuff08:31
jmacsDo I have to resubmit my +1 on each patch every time the patch set is updated?08:31
straycatit's autoconf stuff08:31
straycatjmacs, yes08:31
jmacso_O08:31
straycatwell it's a new set of changes, so that makes sense to me08:32
straycati re-review a v2 on an ml08:32
straycatgerrit's web interface makes it very easy to compare between any 2 versions of a patch set too08:32
jmacsI've been on projects that have got above v5008:33
straycatdon't think that's really ever happened on baserock08:34
paulsherwood:)08:34
bashrc_jjardon: I've changed the firehose readme commit in accordance with your comment. The commit sha will have changed though08:35
bashrc_sorry, I think the comment came from franred rather than jjardon08:37
*** Albert has joined #baserock08:39
straycatssam2, hey, would i submitted a new version of the ntpd changes https://gerrit.baserock.org/#/q/status:open+project:baserock/baserock/definitions+branch:master+topic:ripsum/ntpd-returns  which really need to get merged, do you have time to take a look at them?08:41
straycats/would //08:41
ssam2yes, i'll look through all the openstack stuff in review again today when I get the chance08:44
ssam2if some is higher priority than others, it might be handy if you guys can send a summary to the list saying "all this stuff is needed for openstack, but please review these ones first"08:45
ssam2we plan to do that for the project I'm on, which has a deadline of next week08:45
straycatssam2, i've got stuff based on the ntpd changes that's kinda held up08:45
straycatssam2, what i really mean is, i will merge these in the next 15 minutes unless someone gives me a really good reason not to, cause08:47
ssam2fair enough08:48
straycatyou know :)08:48
ssam2in that case, go ahead and merge. I'm not going to be able to get to it in 15 minutes, and I trust if it breaks stuff then you'll fix it08:48
straycatcool08:48
*** gary_perkins has joined #baserock08:53
SotKstraycat: I've not tested it as my machine is busy, but it all looks fine08:55
*** mariaderidder has quit IRC08:58
*** mariaderidder has joined #baserock08:58
*** edcragg has joined #baserock09:01
benbrown_09:58 <benbrown_> Do you not want set -e in that configure extension?09:06
benbrown_straycat: ^09:06
straycatbenbrown_, good point thanks09:07
*** Krin has joined #baserock09:10
ssam2SotK: I'm finding that a distbuild network using OSTree doesn't work with an existing Trove09:13
ssam2fails at the 'transferring artifacts to shared cache' stage09:14
ssam2is there anything smart in the morph-cache-server in the ostree branch to respond to requests like http://10.24.2.138:8080/1.0/artifacts?filename=foo.chunk ?09:15
*** lachlanmackenzie has joined #baserock09:15
ssam2if not, would it be difficult to add such a thing?09:15
SotKdo you have the log for the worker's cache server?09:16
*** Albert has quit IRC09:17
SotKit currently gives a 500 error if the artifact requested is not a stratum09:17
SotKI guess it would be possible to checkout the artifact, put it into a tarball and send that09:18
straycatbenbrown_, pushed a new patchset with that change https://gerrit.baserock.org/#/c/321/3/ntpd.configure09:20
ssam2SotK: I don't think logging is enabled for the cache server on the worker09:22
ssam2cache server logging is not enabled by default on distbuild nodes09:23
ssam2I can reproduce it if that's useful though09:23
SotKit'll be useful to make sure its failing how I think it is09:23
ssam2ok09:23
*** Albert has joined #baserock09:33
*** Albert has quit IRC09:41
benbrown_straycat: You could have fixed that on merge tbh.09:41
ssam2SotK: this is the cache server log file: http://paste.baserock.org/momokenicu09:43
benbrown_straycat: I see it's been merged anyway :)09:43
ssam2seems pretty conclusive: 'ERROR use `ostree pull` to get non-stratum artifacts' :)09:43
SotKyep, thats what I expected09:46
straycatbenbrown_, there's not really a concept of fix-on-merge with gerrit09:48
benbrown_straycat: I suppose that's sane.09:49
*** Albert has joined #baserock09:52
straycatssam2, is gerrit replicating all branches in gbo or just master?09:53
straycatcause i submitted a change to gerrit targetting baserock/openstack-v7 and merged it, but it didn't end up on gbo09:54
SotKssam2: I'm not actually sure how to fix this, I could create a tarball artifact as I said, but that would be the wrong thing to do if the remote was using OSTree09:54
ssam2straycat: only master09:55
ssam2could be changed if necessary09:55
SotKalthough actually I think the code which makes that request was removed by the OSTree patch anyway09:55
ssam2SotK: I'm not sure it's as important as I thought, either ...09:56
ssam2SotK: I wanted two Masons, one with OStree, one without, to compare speed. But I realised now that if they share an artifact cache then they'll share artifacts too so it won't be a useful test :)09:57
SotK:)09:57
ssam2maybe it'd be enough to just give a useful error, early on, if someone tried to use OStree-morph with an old Trove09:57
ssam2maybe the controller could query the configured shared-artifact-cache on startup, and refuse to start if it was incompatible09:58
SotKyeah, that would make sense I think09:58
ssam2we'll need to communicate in release notes that troves will need upgrading. But people should be keeping them up to date anyway of course :)09:59
KinnisonOOI can we not run both cache servers side-by-side for a time?09:59
* Kinnison appreciates they won't share artifacts09:59
SotKwe'd still need to upgrade the trove to have ostree10:01
*** Albert has quit IRC10:02
SotKI *think* old distbuild would work against an ostree trove10:02
SotKin fact, maybe not, but thats a bug in my ostree patch10:03
*** a1exhughe5 has quit IRC10:04
straycatssam2, is it very expensive to have it replicate, for example, all branches that match baserock/ ?10:07
straycatit's no bother if not, i don't mind merging manually for now10:12
pedroalvarezcan we assume in gerrit that previous +1's are still vaild if the only changes I've made are to fix some -1's ?10:12
straycatyou mean on prior patch sets?10:13
straycati think that's fair enough, if there's no massive changes between the sets; your changes are just fixing issues raised10:13
*** a1exhughe5 has joined #baserock10:18
pedroalvarezhm.. I'm currently thinking that postgresql service should depend on network-online10:23
pedroalvarez.targetr10:23
pedroalvarez-r10:23
pedroalvarezcurrently it doesn't depend on anything :S10:24
straycatthat might not be needed if it's just binding to a given interface10:33
straycatnetwork.target should be enough for that10:33
* jjardon still not sure if putting autogenerated files in git is a good idea (for the config files) but if its the only solution...10:33
pedroalvarezjjardon: i'd ponder your suggestions once we start maintaining this10:35
pedroalvarezI know that it looks wrong, but I think is the best way we can do this for now10:35
*** bashrc_ has quit IRC10:40
*** bashrc_ has joined #baserock10:41
*** bashrc_ has quit IRC10:53
*** bashrc_ has joined #baserock10:55
jjardonpedroalvarez: sure. Any idea how other openstack instances deal with this?10:58
jjardonIs it possible to reference in a cluster other cluster? So you can build another clusters from a single cluster file?10:58
ssam2straycat: the consideration isn't resource consumption. the problem is the two-directional mirroring10:58
ssam2straycat: if you have 2-directional mirroring of a branch and one version of it gets force-pushed, you have a problem10:59
ssam2straycat: for 'master', nobody should (or can) force-push so it's fine. But for baserock/ branches, it's a different story10:59
ssam2straycat: I can see that the current set up is a big pain when working with shared feature branches, though10:59
ssam2i'd like a better solution (but am not sure when I'll get time to work on infra again, probably not for a few weeks)11:00
ssam2pedroalvarez: you can count all my +1s as still valid on the openstack branches, as long as you don't introduce anything crazy :)11:01
ssam2wrt. autogenerated files in Git: it can actually be not too painful to merge new versions of the autogenerated files, because Git provides lots of tools for doing 3-way merges of things11:02
straycatssam2, ahh yes good point11:02
jjardonpedroalvarez: where is the postgresql.service file defined?11:02
ssam2although it'd probably be better to avoid having to commit them, i agree11:02
jjardonpedroalvarez: as straycat said, After=network.target should be enough11:07
franredjjardon, what do you mean?11:07
franredjjardon, https://gerrit.baserock.org/#/c/309/6/openstack/usr/lib/systemd/system/postgres-server.service11:08
jjardonfranred: cheers11:09
jjardonthat service file looks good to me11:10
jjardonbut, is it now the default to put the .service in the system as an extension, instead on the morph file? I can image that .service files can be useful for any user, not only the ones that build openstack11:12
* straycat longs for morph to report progress when fetcing artifacts11:30
straycat*fetching11:30
jjardonstraycat: I though you get that when running with -v ?11:31
ssam2me too, I think I have a patch somewhere to download artifacts with 'wget' rather than shutil.copyfileobj() so you can get progress11:31
straycatthat gives you git clone progress11:31
ssam2but I put it on hold because of the OSTree changes -- it will probably be obsolete11:32
ssam2I imagine ostree will make it easy to show the progress of fetches from the cache -- the `ostree` commandline tool shows progress11:32
straycatcool11:32
ssam2we use the library, rather than the commandline tool, but it can't be too hard11:32
straycattroves should clearly use bitorrent to distribute artifacts to each other11:34
jjardonthat would be cool11:49
paulsherwoodKinnison: 2015-04-07 02:56:18 [openstack-system-x86_64] Elapsed time 02:58:1411:49
paulsherwood(from empty)11:53
*** Albert has joined #baserock12:06
*** paulw has quit IRC12:08
*** paulw has joined #baserock12:13
Kinnisonpaulsherwood: neat.  Using all of my commits, or just the PIPE fix?12:18
straycati don't think the morph-cache-server on gbo is functioning12:24
straycat(my build is stuck fetching glibc from the cache)12:25
pedroalvarezmight be your network being slow?12:26
pedroalvarez(I've been having that kind of problems this week)12:26
straycatextremely slow then, that artifact is like 30MB ?12:27
jjardonhe, I've just going to ask the same  :)12:29
SotKit took me ~40 minutes to fetch gcc yesterday12:32
jjardonhttp://www.speedtest.net/ give me 1.76 Mbps of download speed12:33
paulsherwoodKinnison: all of them12:34
paulsherwood(which are now in mainline)12:35
Kinnisonfair enough12:35
* Kinnison won't have to rebase at least :)12:35
straycatahh yeah12:41
straycatdownloading with wget here and getting 50K/s >.>12:41
SotKssam2: I'm sad you only saw 26 seconds for the build graph speedups... I saw it down to 10 seconds when I was testing it on my x86 VM earlier12:42
* SotK wonders what he should do with pygobject12:46
ssam2SotK: this is on ARM, so maybe there's less computrons13:19
ssam2if in doubt, keep it where it is or make a pygobject stratum...13:20
SotKssam2: I mean for the OSTree definitions branch in which I duplicated it into the ostree stratum13:21
SotKrichard_maw suggested I have it in morph-utils instead, but that would still be duplicating it13:21
SotKI guess a python-pygobject stratum might make sense?13:21
ssam2yeah13:25
ssam2i know it's a bit of a pain to add a new stratum13:25
ssam2SotK: took 13 seconds to compute build graph this time13:29
SotK\o/13:29
* SotK wonders why it varies so much13:30
ssam226 seconds after I remembered to commit and push my change13:30
ssam2so seems that 13 seconds of that is 'git remote update' in my definitions repo13:31
*** lachlanmackenzie has quit IRC13:43
*** lachlanmackenzie has joined #baserock13:44
* SotK finds it maddening to edit 28 files to add a new stratum dependency to morph13:59
richard_mawruntime depends13:59
* SotK realises as he typed that that morph is in more than just build- and devel-14:00
SotKrichard_maw: +1000000014:00
SotKs/28/38/14:00
persiaRuntime depends are a nice way to solve the problem, but if we have those, how do chunks differ from packages?14:07
persia(aside from the fact that we disallow inserting them at runtime)14:07
* persia is not asserting that chunks must differ from packages, but believes that if they are not different, we ought to use the same name as other folk14:08
*** zoli__ has quit IRC14:11
SotKoh hm, I wonder how morph depending on OSTree should be handled by the cross-bootstrap system14:11
SotKgiven ostree depends on tools14:11
ssam2ouch14:16
Kinnisonhow much of tools does ostree depend on?14:16
* pedroalvarez accidentally changes the topic of the openstack patch set14:16
* SotK can't remember14:18
*** ctgriffiths_ has quit IRC14:18
*** ctgriffiths has joined #baserock14:19
* Kinnison wouldn't be terribly enthused by having huge quantities added to cross-bootstrap14:19
Kinnisonit's delicate enough as it is14:19
* SotK realises libsoup is duplicated too and is sad14:24
paulsherwoodSotK: more are duplicate i think http://paste.baserock.org/ecitugemip ?14:28
SotKpaulsherwood: indeed, but they aren't caused by the patch I'm writing :)14:33
pedroalvarezpaulsherwood: 2015-04-07 03:37:36 !!14:34
Kinnisonpedroalvarez: paulsherwood is a baserock-powered robot14:34
pedroalvarezmec mec mec14:35
pedroalvarezbuild something14:35
pedroalvarezmec mec mec14:35
paulsherwoodpedroalvarez: no, just the time on my vm is out14:36
* paulsherwood doesn't fix it, since it helps to feed the myth of his 24/7 schedule14:36
pedroalvarez:)14:37
*** edcragg has quit IRC14:40
*** ssam2 has quit IRC14:41
*** flatmush has quit IRC14:41
*** franred has quit IRC14:41
*** fay_ has quit IRC14:41
*** mauricemoss_ has quit IRC14:41
*** bashrc_ has quit IRC14:41
*** mdunford has quit IRC14:41
*** Krin has quit IRC14:41
*** sambishop has quit IRC14:41
*** nowster has quit IRC14:41
*** lachlanmackenzie has quit IRC14:41
*** paulw has quit IRC14:41
*** jonathanmaw has quit IRC14:41
*** a1exhughe5 has quit IRC14:41
*** gary_perkins has quit IRC14:41
*** tiagogomes has quit IRC14:41
*** mariaderidder has quit IRC14:42
*** CTtpollard has quit IRC14:42
persiaFixing the timestamps and automating communications at selected times in response to keywords is a more effetive means of supporting belief in constant activities independent of common diurnal experience.14:44
*** zoli__ has joined #baserock14:56
*** nowster has joined #baserock15:00
*** a1exhughe5 has joined #baserock15:01
*** a1exhughe5 has quit IRC15:10
*** paulw has joined #baserock15:10
*** mauricemoss_ has joined #baserock15:11
*** mdunford has joined #baserock15:11
*** ssam2 has joined #baserock15:11
*** ChanServ sets mode: +v ssam215:11
*** lachlanmackenzie has joined #baserock15:11
*** CTtpollard has joined #baserock15:11
*** tiagogomes_ has joined #baserock15:11
*** gary_perkins has joined #baserock15:11
*** sambishop has joined #baserock15:11
*** fay_ has joined #baserock15:11
*** jonathanmaw has joined #baserock15:12
*** mariaderidder has joined #baserock15:12
*** edcragg has joined #baserock15:13
*** bashrc_ has joined #baserock15:14
*** flatmush has joined #baserock15:15
*** nowster has quit IRC15:17
*** franred has joined #baserock15:18
ssam2seems that nfsboot.configure is redundant in systemd-networkd systems :)15:19
ssam2also, I have a modern Baserock system running on a Calxeda server, for the first time in a while...15:20
ssam2only with Linux 3.15.10  though15:20
pedroalvarezthey are alive!15:20
franredssam2, did you try 4.0? Im saying this because if it does not work for it, we should notify it to jjardon --> see https://gerrit.baserock.org/#/c/265/315:22
jjardonpaulsherwood: thats useful, is that the complete list?15:23
pedroalvarezfranred: no, they will not work with 4.015:23
jjardonssam2: nice, didn't realize about that extension when we move to systemd-networkd15:23
* radiofree seems to remember having a conversation about upgrading kernels on systems he hasn't tested the last time the kernel was upgraded15:27
jjardonjonathanmaw: after a little investigation, I put here what I think it should be done (but I do not know almost anything about PAM configuration, so maybe some of the items there are wrong ) https://storyboard.baserock.org/#!/story/2115:27
radiofreeconversation with jjardon even..15:27
*** a1exhughe5 has joined #baserock15:30
*** nowster has joined #baserock15:33
jjardonradiofree: that patch in a separate commit I only do for completeness when I upgrade to 4.015:34
radiofreejjardon: what possible benefit is it without testing?15:34
jjardonseems calxeda systems are broken since at least 2014-12-07, when they got updated to 3.1815:34
radiofreeit looks good in definitions, but if it hasn't been tested then why are these things getting merged15:35
radiofreee.g have you checked to make sure the device tree names are the same?15:35
radiofreeit should be up to the people using these bsp's to upgrade the kernel, not someone who's never been near the machine in question simple for "completeness"15:37
jjardonI think is a good exercise to show how important is to have the systems we support in the ci15:37
jjardonthe fact I submit a patch doesnt mean it has to be applied, ITs reponsability of the maintainer/ person with access to the hardware to decide15:38
radiofreei'm sure people who download, build, and deploy a non-working system will appreciate this exercise15:38
rjek:)15:38
ssam2jjardon: who is the maintainer of Baserock?15:39
jjardonwe are15:40
robtaylo1ssam2: that's you isn't it? ;)15:40
ssam2i thought you were doing it15:40
ssam2it might be useful to have a nominated maintainer for specific platforms, in future15:40
richard_mawfirehose!15:41
bashrc_firehose?15:41
ssam2spewing patches at high speed doesn't make a useful maintainer :)15:42
ssam2(that's not a subtle dig at jjardon by the way, his patches are mostly really useful)15:42
paulsherwoodjjardon: i believe so15:42
jjardonI'd remove (or move to a "unsupported" folder) any system that its not in the ci, because earlier or later it will bit rot and broke15:42
ssam2the problem is that time to maintain the CI is scarce15:44
ssam2I agree that should be a goal though15:44
radiofreejjardon: sending untested kernel upgrade patches can get through the cracks15:44
ssam2but, having stuff in CI doesn't mean it's not broken.15:44
bashrc_is CI low priority?15:45
radiofreehow about you just send patches for systems you've tested in future rather than relying on the maintainer/person with access to the hardware to test it15:45
jjardonI know, but probably is not so much is you compare the time you spend to fix systems that used to work and now are broken15:45
radiofree(btw only talking about kernel upgrades here)15:45
persiabashrc_: Rather, most of us are busy folk, and nobody has been able to spend enough time on it recently..15:46
bashrc_if it's a priority then bump it up the list15:46
persiaFor untestable patches, I think they are safe to post, but the poster should probably -1 their own patches with a comment saying they need to be tested on hardware.15:47
persiabashrc_: Which list?  Most of the folk with merge permission are busy working on systems projects for their employers: any of the infrastructure stuff happens mostly on a volunteer basis.15:47
persiaI've heard that some of the infra team have arrangements that let them spend some time on it as part of work, but I know that some other infra people only do infra on a purely volunteer basis.15:48
bashrc_prioritise your maintenance. This is maybe where gerrit is lacking15:50
bashrc_if stuff which is regarded as priority isn't getting done then something is wrong with the workflow15:50
persiabashrc_: If it is a priority for you, please do it.  If you want to adjust other's priorities, carrots can be more useful than sticks.15:55
jjardonpersia: good idea15:55
persiaTo anyone, if you're working on something as a priority that we can all use, I expect most of us would be happy to help you get it done (although we might not have time).15:56
bashrc_persia: typically I'd expect maintainers of a project to priotitise their tasks based on upcoming milestones or releases15:56
bashrc_s/priotitise/prioritise15:57
persiaThis sometimes happens for projects that are used by hobbyists, or projects with funded developers.  For tooling projects with lots of developers who are paid to use the tools, it is less common.15:57
*** a1exhughe5 has quit IRC15:58
persia(we fall into that latter category, hence the current issues)15:59
*** mariaderidder has quit IRC15:59
*** mariaderidder has joined #baserock16:00
*** mariaderidder has quit IRC16:03
*** mariaderidder has joined #baserock16:03
*** jonathanmaw has quit IRC16:13
* pedroalvarez can't send a patch for review :(16:13
pedroalvarezpatch-set16:14
pedroalvarezanyone willing to help?16:14
tiagogomes_pedroalvarez what's the error?16:15
pedroalvarezNo changes between HEAD and gerrit/master. Submitting for review would16:15
pedroalvarezbe pointless.16:15
tiagogomes_never saw that one16:17
persiapedroalvarez: Do you get something with `git log master..`?16:18
pedroalvarezyes :)16:18
pedroalvarezwell, I tried diff16:19
pedroalvareznot log16:19
persiaTry log.16:19
pedroalvarezbut yes, that shows commits16:19
persiaHow about `git log gerrit/master..`?16:19
pedroalvarezlooks like the same result16:20
persiaDo you have changeIDs in your commits?16:20
pedroalvarezok, I'm going to try another thing, and come back if that doesn't work16:20
pedroalvarezyes16:20
pedroalvarezI think there is some problem when trying to send a second version of a patch set but with more commits on it16:20
* persia is baffled: it isn't that git is confused, and it isn't the usual problems with patchsets and gerrit16:20
pedroalvarezOK16:31
pedroalvarezthe initial patch set to include openstack has been merged16:31
pedroalvarezTHANKS everyone! :)16:32
KinnisonCongratulations to that team16:32
pedroalvarezthere is now an outstanding patch set to be reviewed to change some bits to be able to deploy it on 3 nodes16:32
pedroalvarezhttps://gerrit.baserock.org/#/q/status:open+project:baserock/baserock/definitions+branch:master+topic:baserock/openstack-in-baserock-3-nodes16:33
pedroalvarezthere is also another patch-set to include ironic: https://gerrit.baserock.org/#/q/status:open+project:baserock/baserock/definitions+branch:baserock/openstack-in-baserock+topic:ironic16:33
*** Albert has quit IRC16:48
*** Albert_ has joined #baserock16:48
*** mariaderidder has quit IRC16:52
ssam2can anyone think of why a file called /usr/lib/python2.7/si16:53
ssam2te-packages/Crypto/Random/Fortuna/__init__.py might get overwritten on every boot of a baserock 'build' system with a random 32-character hex string ?16:53
ssam2(the file name doesn't actually have a newline in it)16:53
ssam2i'm very confused16:53
persiaGiven the name of the package, it sounds like a nifty hack by the package maintainers.16:54
ssam2indeed .. but it causes distbuild-setup.service not to run, because 'db6f2fde77ab4910972375d037934e12' isn't valid Python16:55
persiaIs the timestamp of the change an exact match for the boot time?  Does Fortuna stick anything special in the startup scripts?16:55
jmacsVery odd16:55
persiaIndeed: if it were indeed a cool hack, presumably they would have done something to make it parse.16:55
ssam2seems to only get overwritten if I truncate the file back to 0 bytes16:56
persiaThat sounds like filesystem corruption16:58
ssam2I should add that this is on an NFS hosted file system16:58
ssam2timestamp does get updated when the contents change17:00
ssam2and does match boot time17:00
ssam2restarting the nfs server hasn't fixed it though17:01
*** Albert_ has quit IRC17:02
persiaDoes a grep for the filename in the filesystem return anything?17:02
ssam2just .pyc files so far17:07
persiaAnnoying that, really.  Given the commonality of the basename, it isn't evn that informative.17:09
persiaAnd, given the timing, tracing is hard.17:11
jmacsIt's a bizarre bug; I can't figure out why there's a zero-length __init__.py in the first place17:11
persiaWhat happens if it is simply deleted?17:12
persiaAlso, it might be interesting to disable python-consuming startup services until one hit the service that modified that file.17:12
ssam2jmacs: python requires that __init__.py exists for it to consider a directory as a 'package'. And it can be 0 bytes to do that17:13
ssam2the file doesn't seem to have been recreated after deletion, good idea17:14
jmacsTIL.17:14
ssam2OK. Now the file doesn't appear to 'ls' or 'cat' on the nfs server or the client. But if I try to 'import Fortuna' in Python with PYTHONPATH set to the parent directory, it still gives an error that points to the file as if it exists and has the same contents as before17:16
persiaexcellent.  That narrows the problem to being something in Fortuna import routines.17:17
persiaDoes upstream use IRC?17:17
ssam2i'm not sure it's so simple...17:17
ssam2I think this can only be (a) an NFS bug, or (b) something broken recently in Baserock definitions master...17:17
ssam2actually, I don't think it can be (B) :)17:18
ssam2what I did was: PYTHONPATH=/usr/lib/python2.7/site-packages/Crypto/Random/ python17:18
*** mdunford has quit IRC17:18
ssam2and got:   File "<stdin>", line 1, in <module>17:18
ssam2  File "/usr/lib/python2.7/site-packages/Crypto/Random/Fortuna/__init__.py", line 1, in <module>17:18
ssam2    # -*- coding: utf-8 -*-17:18
ssam2NameError: name 'db6f2fde77ab4910972375d037934e12' is not defined17:18
ssam2(sorry for the long paste)17:18
ssam2that wasn't even a complete paste. here it is: http://paste.baserock.org/vesetibune17:18
persiaAnd that same code doesn't show that behaviour for non-NFS?17:19
ssam2no17:20
ssam2however, the system versions also differ in the two distbuild systems I can test these on17:20
persiaBut the Fortuna code is identical?17:20
ssam2let me check the SHA1 of /baserock/pycrypto-misc.meta17:20
persiaAnd you are running the same import test?17:20
ssam2same test17:20
ssam2same SHA1 of pycrypto17:21
persiaSomething is indeed odd if you are getting a syntax error from a nonexistent file.17:21
ssam2(which contains this file)17:21
persiaWhat I don't understand is how you get this value in python and not in cat.17:22
ssam2yes, that is weird indeed17:22
*** rdale has quit IRC17:25
*** rdale has joined #baserock17:26
ssam2rebooting the nfs server hasn't fixed this etiher17:26
ssam2robtaylor has pointed out that I didn't delete __init__.pyc  :)17:28
ssam2the __init__.py hasn't been recreated now, so hopefully I can get on with my life :)17:29
persiaaha!  pesky compilation caching17:29
* ssam2 discovers the same issue in /usr/lib/python2.7/site-packages/ansible/inventory/vars_plugins/__init__.py17:29
* ssam2 goes home17:29
*** Albert_ has joined #baserock17:30
*** ssam2 has quit IRC17:32
*** Albert_ has quit IRC17:42
*** Albert_ has joined #baserock17:42
*** edcragg has quit IRC17:51
*** gary_perkins has quit IRC18:02
*** lachlanmackenzie has quit IRC18:15
*** Albert_ has quit IRC18:22
*** Albert_ has joined #baserock18:35
*** zoli__ has quit IRC19:00
*** zoli__ has joined #baserock19:30
*** Albert_ has quit IRC19:36
*** rdale has quit IRC19:51
*** zoli__ has quit IRC20:25
*** zoli__ has joined #baserock20:38
straycathttps://lists.debian.org/debian-devel-announce/2015/04/msg00005.html22:14
rjekInteresting22:22
bwhI don't know what paultag has been smoking but the Debian release cycle is ~2 years22:30
bwhand assuming LTS continues, each release will be supported for ~5 years22:30
bwhso stretch would be supported 2017-2022, buster 2019-202422:31
bwhrealistically there will still be Python 2 only applications around for a good few years; they're presumably still being written today22:32

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!