*** sambishop has quit IRC | 00:36 | |
*** sambishop has joined #baserock | 00:36 | |
*** zoli__ has joined #baserock | 03:45 | |
*** zoli__ has quit IRC | 05:31 | |
*** zoli__ has joined #baserock | 05:46 | |
*** zoli__ has quit IRC | 06:00 | |
*** zoli__ has joined #baserock | 06:19 | |
paulsherwood | novnc build is pulling from github i believe | 06:38 |
---|---|---|
paulsherwood | http://paste.baserock.org/uzikowamek (baserock/openstack-v7) | 06:41 |
paulsherwood | also librabbitmq seems to attempt to pull in a binary? | 06:41 |
paulsherwood | http://paste.baserock.org/esicufirox | 06:42 |
paulsherwood | 2015-04-06 23:48:09 [systems/openstack-server.morph] Finished :-) | 06:44 |
*** a1exhughe5 has joined #baserock | 07:10 | |
*** Albert has joined #baserock | 07:13 | |
*** mariaderidder has joined #baserock | 07:56 | |
straycat | pedroalvarez, okay cool sorry i'm building from baserock/openstack-v7 so i've merged it in there anyhow | 07:57 |
*** mdunford has joined #baserock | 08:08 | |
straycat | paulsherwood, thanks for spotting that | 08:11 |
straycat | i also note that a package in the zookeeper stratum is being pulled in from github | 08:11 |
*** rdale has joined #baserock | 08:11 | |
paulsherwood | aha. | 08:11 |
*** bashrc_ has joined #baserock | 08:16 | |
*** Albert has quit IRC | 08:18 | |
straycat | jjardon, 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 merged | 08:23 |
*** CTtpollard has joined #baserock | 08:25 | |
jjardon | straycat: or put the unit file in the morphology file, so no delta needed :) | 08:28 |
SotK | Does anyone have a minute to +1 jjardon's gnome-common patch (https://gerrit.baserock.org/#/c/338/)? :) | 08:28 |
straycat | fair point | 08:28 |
straycat | jjardon, but we'd still need to patch ntpd | 08:28 |
jjardon | But sure, remember -1 in gerrit is only a -0: if the current approach works for you we can always fix it later | 08:29 |
straycat | it works for me for the moment for sure :) | 08:30 |
paulsherwood | +1, then :) | 08:30 |
*** ssam2 has joined #baserock | 08:31 | |
*** ChanServ sets mode: +v ssam2 | 08:31 | |
straycat | jjardon, so this patch isn't actually gnome stuff | 08:31 |
jmacs | Do I have to resubmit my +1 on each patch every time the patch set is updated? | 08:31 |
straycat | it's autoconf stuff | 08:31 |
straycat | jmacs, yes | 08:31 |
jmacs | o_O | 08:31 |
straycat | well it's a new set of changes, so that makes sense to me | 08:32 |
straycat | i re-review a v2 on an ml | 08:32 |
straycat | gerrit's web interface makes it very easy to compare between any 2 versions of a patch set too | 08:32 |
jmacs | I've been on projects that have got above v50 | 08:33 |
straycat | don't think that's really ever happened on baserock | 08:34 |
paulsherwood | :) | 08:34 |
bashrc_ | jjardon: I've changed the firehose readme commit in accordance with your comment. The commit sha will have changed though | 08:35 |
bashrc_ | sorry, I think the comment came from franred rather than jjardon | 08:37 |
*** Albert has joined #baserock | 08:39 | |
straycat | ssam2, 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 |
straycat | s/would // | 08:41 |
ssam2 | yes, i'll look through all the openstack stuff in review again today when I get the chance | 08:44 |
ssam2 | if 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 |
ssam2 | we plan to do that for the project I'm on, which has a deadline of next week | 08:45 |
straycat | ssam2, i've got stuff based on the ntpd changes that's kinda held up | 08:45 |
straycat | ssam2, what i really mean is, i will merge these in the next 15 minutes unless someone gives me a really good reason not to, cause | 08:47 |
ssam2 | fair enough | 08:48 |
straycat | you know :) | 08:48 |
ssam2 | in 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 it | 08:48 |
straycat | cool | 08:48 |
*** gary_perkins has joined #baserock | 08:53 | |
SotK | straycat: I've not tested it as my machine is busy, but it all looks fine | 08:55 |
*** mariaderidder has quit IRC | 08:58 | |
*** mariaderidder has joined #baserock | 08:58 | |
*** edcragg has joined #baserock | 09:01 | |
benbrown_ | 09:58 <benbrown_> Do you not want set -e in that configure extension? | 09:06 |
benbrown_ | straycat: ^ | 09:06 |
straycat | benbrown_, good point thanks | 09:07 |
*** Krin has joined #baserock | 09:10 | |
ssam2 | SotK: I'm finding that a distbuild network using OSTree doesn't work with an existing Trove | 09:13 |
ssam2 | fails at the 'transferring artifacts to shared cache' stage | 09:14 |
ssam2 | is 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 #baserock | 09:15 | |
ssam2 | if not, would it be difficult to add such a thing? | 09:15 |
SotK | do you have the log for the worker's cache server? | 09:16 |
*** Albert has quit IRC | 09:17 | |
SotK | it currently gives a 500 error if the artifact requested is not a stratum | 09:17 |
SotK | I guess it would be possible to checkout the artifact, put it into a tarball and send that | 09:18 |
straycat | benbrown_, pushed a new patchset with that change https://gerrit.baserock.org/#/c/321/3/ntpd.configure | 09:20 |
ssam2 | SotK: I don't think logging is enabled for the cache server on the worker | 09:22 |
ssam2 | cache server logging is not enabled by default on distbuild nodes | 09:23 |
ssam2 | I can reproduce it if that's useful though | 09:23 |
SotK | it'll be useful to make sure its failing how I think it is | 09:23 |
ssam2 | ok | 09:23 |
*** Albert has joined #baserock | 09:33 | |
*** Albert has quit IRC | 09:41 | |
benbrown_ | straycat: You could have fixed that on merge tbh. | 09:41 |
ssam2 | SotK: this is the cache server log file: http://paste.baserock.org/momokenicu | 09:43 |
benbrown_ | straycat: I see it's been merged anyway :) | 09:43 |
ssam2 | seems pretty conclusive: 'ERROR use `ostree pull` to get non-stratum artifacts' :) | 09:43 |
SotK | yep, thats what I expected | 09:46 |
straycat | benbrown_, there's not really a concept of fix-on-merge with gerrit | 09:48 |
benbrown_ | straycat: I suppose that's sane. | 09:49 |
*** Albert has joined #baserock | 09:52 | |
straycat | ssam2, is gerrit replicating all branches in gbo or just master? | 09:53 |
straycat | cause i submitted a change to gerrit targetting baserock/openstack-v7 and merged it, but it didn't end up on gbo | 09:54 |
SotK | ssam2: 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 OSTree | 09:54 |
ssam2 | straycat: only master | 09:55 |
ssam2 | could be changed if necessary | 09:55 |
SotK | although actually I think the code which makes that request was removed by the OSTree patch anyway | 09:55 |
ssam2 | SotK: I'm not sure it's as important as I thought, either ... | 09:56 |
ssam2 | SotK: 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 |
ssam2 | maybe it'd be enough to just give a useful error, early on, if someone tried to use OStree-morph with an old Trove | 09:57 |
ssam2 | maybe the controller could query the configured shared-artifact-cache on startup, and refuse to start if it was incompatible | 09:58 |
SotK | yeah, that would make sense I think | 09:58 |
ssam2 | we'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 |
Kinnison | OOI can we not run both cache servers side-by-side for a time? | 09:59 |
* Kinnison appreciates they won't share artifacts | 09:59 | |
SotK | we'd still need to upgrade the trove to have ostree | 10:01 |
*** Albert has quit IRC | 10:02 | |
SotK | I *think* old distbuild would work against an ostree trove | 10:02 |
SotK | in fact, maybe not, but thats a bug in my ostree patch | 10:03 |
*** a1exhughe5 has quit IRC | 10:04 | |
straycat | ssam2, is it very expensive to have it replicate, for example, all branches that match baserock/ ? | 10:07 |
straycat | it's no bother if not, i don't mind merging manually for now | 10:12 |
pedroalvarez | can 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 |
straycat | you mean on prior patch sets? | 10:13 |
straycat | i think that's fair enough, if there's no massive changes between the sets; your changes are just fixing issues raised | 10:13 |
*** a1exhughe5 has joined #baserock | 10:18 | |
pedroalvarez | hm.. I'm currently thinking that postgresql service should depend on network-online | 10:23 |
pedroalvarez | .targetr | 10:23 |
pedroalvarez | -r | 10:23 |
pedroalvarez | currently it doesn't depend on anything :S | 10:24 |
straycat | that might not be needed if it's just binding to a given interface | 10:33 |
straycat | network.target should be enough for that | 10: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 | |
pedroalvarez | jjardon: i'd ponder your suggestions once we start maintaining this | 10:35 |
pedroalvarez | I know that it looks wrong, but I think is the best way we can do this for now | 10:35 |
*** bashrc_ has quit IRC | 10:40 | |
*** bashrc_ has joined #baserock | 10:41 | |
*** bashrc_ has quit IRC | 10:53 | |
*** bashrc_ has joined #baserock | 10:55 | |
jjardon | pedroalvarez: sure. Any idea how other openstack instances deal with this? | 10:58 |
jjardon | Is it possible to reference in a cluster other cluster? So you can build another clusters from a single cluster file? | 10:58 |
ssam2 | straycat: the consideration isn't resource consumption. the problem is the two-directional mirroring | 10:58 |
ssam2 | straycat: if you have 2-directional mirroring of a branch and one version of it gets force-pushed, you have a problem | 10:59 |
ssam2 | straycat: for 'master', nobody should (or can) force-push so it's fine. But for baserock/ branches, it's a different story | 10:59 |
ssam2 | straycat: I can see that the current set up is a big pain when working with shared feature branches, though | 10:59 |
ssam2 | i'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 |
ssam2 | pedroalvarez: you can count all my +1s as still valid on the openstack branches, as long as you don't introduce anything crazy :) | 11:01 |
ssam2 | wrt. 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 things | 11:02 |
straycat | ssam2, ahh yes good point | 11:02 |
jjardon | pedroalvarez: where is the postgresql.service file defined? | 11:02 |
ssam2 | although it'd probably be better to avoid having to commit them, i agree | 11:02 |
jjardon | pedroalvarez: as straycat said, After=network.target should be enough | 11:07 |
franred | jjardon, what do you mean? | 11:07 |
franred | jjardon, https://gerrit.baserock.org/#/c/309/6/openstack/usr/lib/systemd/system/postgres-server.service | 11:08 |
jjardon | franred: cheers | 11:09 |
jjardon | that service file looks good to me | 11:10 |
jjardon | but, 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 openstack | 11:12 |
* straycat longs for morph to report progress when fetcing artifacts | 11:30 | |
straycat | *fetching | 11:30 |
jjardon | straycat: I though you get that when running with -v ? | 11:31 |
ssam2 | me too, I think I have a patch somewhere to download artifacts with 'wget' rather than shutil.copyfileobj() so you can get progress | 11:31 |
straycat | that gives you git clone progress | 11:31 |
ssam2 | but I put it on hold because of the OSTree changes -- it will probably be obsolete | 11:32 |
ssam2 | I imagine ostree will make it easy to show the progress of fetches from the cache -- the `ostree` commandline tool shows progress | 11:32 |
straycat | cool | 11:32 |
ssam2 | we use the library, rather than the commandline tool, but it can't be too hard | 11:32 |
straycat | troves should clearly use bitorrent to distribute artifacts to each other | 11:34 |
jjardon | that would be cool | 11:49 |
paulsherwood | Kinnison: 2015-04-07 02:56:18 [openstack-system-x86_64] Elapsed time 02:58:14 | 11:49 |
paulsherwood | (from empty) | 11:53 |
*** Albert has joined #baserock | 12:06 | |
*** paulw has quit IRC | 12:08 | |
*** paulw has joined #baserock | 12:13 | |
Kinnison | paulsherwood: neat. Using all of my commits, or just the PIPE fix? | 12:18 |
straycat | i don't think the morph-cache-server on gbo is functioning | 12:24 |
straycat | (my build is stuck fetching glibc from the cache) | 12:25 |
pedroalvarez | might be your network being slow? | 12:26 |
pedroalvarez | (I've been having that kind of problems this week) | 12:26 |
straycat | extremely slow then, that artifact is like 30MB ? | 12:27 |
jjardon | he, I've just going to ask the same :) | 12:29 |
SotK | it took me ~40 minutes to fetch gcc yesterday | 12:32 |
jjardon | http://www.speedtest.net/ give me 1.76 Mbps of download speed | 12:33 |
paulsherwood | Kinnison: all of them | 12:34 |
paulsherwood | (which are now in mainline) | 12:35 |
Kinnison | fair enough | 12:35 |
* Kinnison won't have to rebase at least :) | 12:35 | |
straycat | ahh yeah | 12:41 |
straycat | downloading with wget here and getting 50K/s >.> | 12:41 |
SotK | ssam2: 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 earlier | 12:42 |
* SotK wonders what he should do with pygobject | 12:46 | |
ssam2 | SotK: this is on ARM, so maybe there's less computrons | 13:19 |
ssam2 | if in doubt, keep it where it is or make a pygobject stratum... | 13:20 |
SotK | ssam2: I mean for the OSTree definitions branch in which I duplicated it into the ostree stratum | 13:21 |
SotK | richard_maw suggested I have it in morph-utils instead, but that would still be duplicating it | 13:21 |
SotK | I guess a python-pygobject stratum might make sense? | 13:21 |
ssam2 | yeah | 13:25 |
ssam2 | i know it's a bit of a pain to add a new stratum | 13:25 |
ssam2 | SotK: took 13 seconds to compute build graph this time | 13:29 |
SotK | \o/ | 13:29 |
* SotK wonders why it varies so much | 13:30 | |
ssam2 | 26 seconds after I remembered to commit and push my change | 13:30 |
ssam2 | so seems that 13 seconds of that is 'git remote update' in my definitions repo | 13:31 |
*** lachlanmackenzie has quit IRC | 13:43 | |
*** lachlanmackenzie has joined #baserock | 13:44 | |
* SotK finds it maddening to edit 28 files to add a new stratum dependency to morph | 13:59 | |
richard_maw | runtime depends | 13:59 |
* SotK realises as he typed that that morph is in more than just build- and devel- | 14:00 | |
SotK | richard_maw: +10000000 | 14:00 |
SotK | s/28/38/ | 14:00 |
persia | Runtime 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 folk | 14:08 | |
*** zoli__ has quit IRC | 14:11 | |
SotK | oh hm, I wonder how morph depending on OSTree should be handled by the cross-bootstrap system | 14:11 |
SotK | given ostree depends on tools | 14:11 |
ssam2 | ouch | 14:16 |
Kinnison | how much of tools does ostree depend on? | 14:16 |
* pedroalvarez accidentally changes the topic of the openstack patch set | 14:16 | |
* SotK can't remember | 14:18 | |
*** ctgriffiths_ has quit IRC | 14:18 | |
*** ctgriffiths has joined #baserock | 14:19 | |
* Kinnison wouldn't be terribly enthused by having huge quantities added to cross-bootstrap | 14:19 | |
Kinnison | it's delicate enough as it is | 14:19 |
* SotK realises libsoup is duplicated too and is sad | 14:24 | |
paulsherwood | SotK: more are duplicate i think http://paste.baserock.org/ecitugemip ? | 14:28 |
SotK | paulsherwood: indeed, but they aren't caused by the patch I'm writing :) | 14:33 |
pedroalvarez | paulsherwood: 2015-04-07 03:37:36 !! | 14:34 |
Kinnison | pedroalvarez: paulsherwood is a baserock-powered robot | 14:34 |
pedroalvarez | mec mec mec | 14:35 |
pedroalvarez | build something | 14:35 |
pedroalvarez | mec mec mec | 14:35 |
paulsherwood | pedroalvarez: no, just the time on my vm is out | 14:36 |
* paulsherwood doesn't fix it, since it helps to feed the myth of his 24/7 schedule | 14:36 | |
pedroalvarez | :) | 14:37 |
*** edcragg has quit IRC | 14:40 | |
*** ssam2 has quit IRC | 14:41 | |
*** flatmush has quit IRC | 14:41 | |
*** franred has quit IRC | 14:41 | |
*** fay_ has quit IRC | 14:41 | |
*** mauricemoss_ has quit IRC | 14:41 | |
*** bashrc_ has quit IRC | 14:41 | |
*** mdunford has quit IRC | 14:41 | |
*** Krin has quit IRC | 14:41 | |
*** sambishop has quit IRC | 14:41 | |
*** nowster has quit IRC | 14:41 | |
*** lachlanmackenzie has quit IRC | 14:41 | |
*** paulw has quit IRC | 14:41 | |
*** jonathanmaw has quit IRC | 14:41 | |
*** a1exhughe5 has quit IRC | 14:41 | |
*** gary_perkins has quit IRC | 14:41 | |
*** tiagogomes has quit IRC | 14:41 | |
*** mariaderidder has quit IRC | 14:42 | |
*** CTtpollard has quit IRC | 14:42 | |
persia | Fixing 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 #baserock | 14:56 | |
*** nowster has joined #baserock | 15:00 | |
*** a1exhughe5 has joined #baserock | 15:01 | |
*** a1exhughe5 has quit IRC | 15:10 | |
*** paulw has joined #baserock | 15:10 | |
*** mauricemoss_ has joined #baserock | 15:11 | |
*** mdunford has joined #baserock | 15:11 | |
*** ssam2 has joined #baserock | 15:11 | |
*** ChanServ sets mode: +v ssam2 | 15:11 | |
*** lachlanmackenzie has joined #baserock | 15:11 | |
*** CTtpollard has joined #baserock | 15:11 | |
*** tiagogomes_ has joined #baserock | 15:11 | |
*** gary_perkins has joined #baserock | 15:11 | |
*** sambishop has joined #baserock | 15:11 | |
*** fay_ has joined #baserock | 15:11 | |
*** jonathanmaw has joined #baserock | 15:12 | |
*** mariaderidder has joined #baserock | 15:12 | |
*** edcragg has joined #baserock | 15:13 | |
*** bashrc_ has joined #baserock | 15:14 | |
*** flatmush has joined #baserock | 15:15 | |
*** nowster has quit IRC | 15:17 | |
*** franred has joined #baserock | 15:18 | |
ssam2 | seems that nfsboot.configure is redundant in systemd-networkd systems :) | 15:19 |
ssam2 | also, I have a modern Baserock system running on a Calxeda server, for the first time in a while... | 15:20 |
ssam2 | only with Linux 3.15.10 though | 15:20 |
pedroalvarez | they are alive! | 15:20 |
franred | ssam2, 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/3 | 15:22 |
jjardon | paulsherwood: thats useful, is that the complete list? | 15:23 |
pedroalvarez | franred: no, they will not work with 4.0 | 15:23 |
jjardon | ssam2: nice, didn't realize about that extension when we move to systemd-networkd | 15:23 |
* radiofree seems to remember having a conversation about upgrading kernels on systems he hasn't tested the last time the kernel was upgraded | 15:27 | |
jjardon | jonathanmaw: 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/21 | 15:27 |
radiofree | conversation with jjardon even.. | 15:27 |
*** a1exhughe5 has joined #baserock | 15:30 | |
*** nowster has joined #baserock | 15:33 | |
jjardon | radiofree: that patch in a separate commit I only do for completeness when I upgrade to 4.0 | 15:34 |
radiofree | jjardon: what possible benefit is it without testing? | 15:34 |
jjardon | seems calxeda systems are broken since at least 2014-12-07, when they got updated to 3.18 | 15:34 |
radiofree | it looks good in definitions, but if it hasn't been tested then why are these things getting merged | 15:35 |
radiofree | e.g have you checked to make sure the device tree names are the same? | 15:35 |
radiofree | it 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 |
jjardon | I think is a good exercise to show how important is to have the systems we support in the ci | 15:37 |
jjardon | the fact I submit a patch doesnt mean it has to be applied, ITs reponsability of the maintainer/ person with access to the hardware to decide | 15:38 |
radiofree | i'm sure people who download, build, and deploy a non-working system will appreciate this exercise | 15:38 |
rjek | :) | 15:38 |
ssam2 | jjardon: who is the maintainer of Baserock? | 15:39 |
jjardon | we are | 15:40 |
robtaylo1 | ssam2: that's you isn't it? ;) | 15:40 |
ssam2 | i thought you were doing it | 15:40 |
ssam2 | it might be useful to have a nominated maintainer for specific platforms, in future | 15:40 |
richard_maw | firehose! | 15:41 |
bashrc_ | firehose? | 15:41 |
ssam2 | spewing 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 |
paulsherwood | jjardon: i believe so | 15:42 |
jjardon | I'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 broke | 15:42 |
ssam2 | the problem is that time to maintain the CI is scarce | 15:44 |
ssam2 | I agree that should be a goal though | 15:44 |
radiofree | jjardon: sending untested kernel upgrade patches can get through the cracks | 15:44 |
ssam2 | but, having stuff in CI doesn't mean it's not broken. | 15:44 |
bashrc_ | is CI low priority? | 15:45 |
radiofree | how 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 it | 15:45 |
jjardon | I know, but probably is not so much is you compare the time you spend to fix systems that used to work and now are broken | 15:45 |
radiofree | (btw only talking about kernel upgrades here) | 15:45 |
persia | bashrc_: 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 list | 15:46 |
persia | For 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 |
persia | bashrc_: 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 |
persia | I'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 lacking | 15:50 |
bashrc_ | if stuff which is regarded as priority isn't getting done then something is wrong with the workflow | 15:50 |
persia | bashrc_: 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 |
jjardon | persia: good idea | 15:55 |
persia | To 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 releases | 15:56 |
bashrc_ | s/priotitise/prioritise | 15:57 |
persia | This 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 IRC | 15:58 | |
persia | (we fall into that latter category, hence the current issues) | 15:59 |
*** mariaderidder has quit IRC | 15:59 | |
*** mariaderidder has joined #baserock | 16:00 | |
*** mariaderidder has quit IRC | 16:03 | |
*** mariaderidder has joined #baserock | 16:03 | |
*** jonathanmaw has quit IRC | 16:13 | |
* pedroalvarez can't send a patch for review :( | 16:13 | |
pedroalvarez | patch-set | 16:14 |
pedroalvarez | anyone willing to help? | 16:14 |
tiagogomes_ | pedroalvarez what's the error? | 16:15 |
pedroalvarez | No changes between HEAD and gerrit/master. Submitting for review would | 16:15 |
pedroalvarez | be pointless. | 16:15 |
tiagogomes_ | never saw that one | 16:17 |
persia | pedroalvarez: Do you get something with `git log master..`? | 16:18 |
pedroalvarez | yes :) | 16:18 |
pedroalvarez | well, I tried diff | 16:19 |
pedroalvarez | not log | 16:19 |
persia | Try log. | 16:19 |
pedroalvarez | but yes, that shows commits | 16:19 |
persia | How about `git log gerrit/master..`? | 16:19 |
pedroalvarez | looks like the same result | 16:20 |
persia | Do you have changeIDs in your commits? | 16:20 |
pedroalvarez | ok, I'm going to try another thing, and come back if that doesn't work | 16:20 |
pedroalvarez | yes | 16:20 |
pedroalvarez | I think there is some problem when trying to send a second version of a patch set but with more commits on it | 16:20 |
* persia is baffled: it isn't that git is confused, and it isn't the usual problems with patchsets and gerrit | 16:20 | |
pedroalvarez | OK | 16:31 |
pedroalvarez | the initial patch set to include openstack has been merged | 16:31 |
pedroalvarez | THANKS everyone! :) | 16:32 |
Kinnison | Congratulations to that team | 16:32 |
pedroalvarez | there is now an outstanding patch set to be reviewed to change some bits to be able to deploy it on 3 nodes | 16:32 |
pedroalvarez | https://gerrit.baserock.org/#/q/status:open+project:baserock/baserock/definitions+branch:master+topic:baserock/openstack-in-baserock-3-nodes | 16:33 |
pedroalvarez | there 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:ironic | 16:33 |
*** Albert has quit IRC | 16:48 | |
*** Albert_ has joined #baserock | 16:48 | |
*** mariaderidder has quit IRC | 16:52 | |
ssam2 | can anyone think of why a file called /usr/lib/python2.7/si | 16:53 |
ssam2 | te-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 |
ssam2 | i'm very confused | 16:53 |
persia | Given the name of the package, it sounds like a nifty hack by the package maintainers. | 16:54 |
ssam2 | indeed .. but it causes distbuild-setup.service not to run, because 'db6f2fde77ab4910972375d037934e12' isn't valid Python | 16:55 |
persia | Is the timestamp of the change an exact match for the boot time? Does Fortuna stick anything special in the startup scripts? | 16:55 |
jmacs | Very odd | 16:55 |
persia | Indeed: if it were indeed a cool hack, presumably they would have done something to make it parse. | 16:55 |
ssam2 | seems to only get overwritten if I truncate the file back to 0 bytes | 16:56 |
persia | That sounds like filesystem corruption | 16:58 |
ssam2 | I should add that this is on an NFS hosted file system | 16:58 |
ssam2 | timestamp does get updated when the contents change | 17:00 |
ssam2 | and does match boot time | 17:00 |
ssam2 | restarting the nfs server hasn't fixed it though | 17:01 |
*** Albert_ has quit IRC | 17:02 | |
persia | Does a grep for the filename in the filesystem return anything? | 17:02 |
ssam2 | just .pyc files so far | 17:07 |
persia | Annoying that, really. Given the commonality of the basename, it isn't evn that informative. | 17:09 |
persia | And, given the timing, tracing is hard. | 17:11 |
jmacs | It's a bizarre bug; I can't figure out why there's a zero-length __init__.py in the first place | 17:11 |
persia | What happens if it is simply deleted? | 17:12 |
persia | Also, it might be interesting to disable python-consuming startup services until one hit the service that modified that file. | 17:12 |
ssam2 | jmacs: python requires that __init__.py exists for it to consider a directory as a 'package'. And it can be 0 bytes to do that | 17:13 |
ssam2 | the file doesn't seem to have been recreated after deletion, good idea | 17:14 |
jmacs | TIL. | 17:14 |
ssam2 | OK. 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 before | 17:16 |
persia | excellent. That narrows the problem to being something in Fortuna import routines. | 17:17 |
persia | Does upstream use IRC? | 17:17 |
ssam2 | i'm not sure it's so simple... | 17:17 |
ssam2 | I think this can only be (a) an NFS bug, or (b) something broken recently in Baserock definitions master... | 17:17 |
ssam2 | actually, I don't think it can be (B) :) | 17:18 |
ssam2 | what I did was: PYTHONPATH=/usr/lib/python2.7/site-packages/Crypto/Random/ python | 17:18 |
*** mdunford has quit IRC | 17:18 | |
ssam2 | and 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 |
ssam2 | NameError: name 'db6f2fde77ab4910972375d037934e12' is not defined | 17:18 |
ssam2 | (sorry for the long paste) | 17:18 |
ssam2 | that wasn't even a complete paste. here it is: http://paste.baserock.org/vesetibune | 17:18 |
persia | And that same code doesn't show that behaviour for non-NFS? | 17:19 |
ssam2 | no | 17:20 |
ssam2 | however, the system versions also differ in the two distbuild systems I can test these on | 17:20 |
persia | But the Fortuna code is identical? | 17:20 |
ssam2 | let me check the SHA1 of /baserock/pycrypto-misc.meta | 17:20 |
persia | And you are running the same import test? | 17:20 |
ssam2 | same test | 17:20 |
ssam2 | same SHA1 of pycrypto | 17:21 |
persia | Something is indeed odd if you are getting a syntax error from a nonexistent file. | 17:21 |
ssam2 | (which contains this file) | 17:21 |
persia | What I don't understand is how you get this value in python and not in cat. | 17:22 |
ssam2 | yes, that is weird indeed | 17:22 |
*** rdale has quit IRC | 17:25 | |
*** rdale has joined #baserock | 17:26 | |
ssam2 | rebooting the nfs server hasn't fixed this etiher | 17:26 |
ssam2 | robtaylor has pointed out that I didn't delete __init__.pyc :) | 17:28 |
ssam2 | the __init__.py hasn't been recreated now, so hopefully I can get on with my life :) | 17:29 |
persia | aha! pesky compilation caching | 17:29 |
* ssam2 discovers the same issue in /usr/lib/python2.7/site-packages/ansible/inventory/vars_plugins/__init__.py | 17:29 | |
* ssam2 goes home | 17:29 | |
*** Albert_ has joined #baserock | 17:30 | |
*** ssam2 has quit IRC | 17:32 | |
*** Albert_ has quit IRC | 17:42 | |
*** Albert_ has joined #baserock | 17:42 | |
*** edcragg has quit IRC | 17:51 | |
*** gary_perkins has quit IRC | 18:02 | |
*** lachlanmackenzie has quit IRC | 18:15 | |
*** Albert_ has quit IRC | 18:22 | |
*** Albert_ has joined #baserock | 18:35 | |
*** zoli__ has quit IRC | 19:00 | |
*** zoli__ has joined #baserock | 19:30 | |
*** Albert_ has quit IRC | 19:36 | |
*** rdale has quit IRC | 19:51 | |
*** zoli__ has quit IRC | 20:25 | |
*** zoli__ has joined #baserock | 20:38 | |
straycat | https://lists.debian.org/debian-devel-announce/2015/04/msg00005.html | 22:14 |
rjek | Interesting | 22:22 |
bwh | I don't know what paultag has been smoking but the Debian release cycle is ~2 years | 22:30 |
bwh | and assuming LTS continues, each release will be supported for ~5 years | 22:30 |
bwh | so stretch would be supported 2017-2022, buster 2019-2024 | 22:31 |
bwh | realistically there will still be Python 2 only applications around for a good few years; they're presumably still being written today | 22:32 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!