IRC logs for #baserock for Wednesday, 2015-08-26

*** zoli__ has joined #baserock05:24
*** paulw has joined #baserock06:35
*** straycat has left #baserock06:44
*** bashrc has joined #baserock08:06
*** mdunford has joined #baserock08:19
*** mariaderidder has joined #baserock08:37
*** jonathanmaw has joined #baserock08:49
tlsaI'm trying to run `sudo python build` on morph on debian08:55
tlsaI get: error: [Errno 2] No such file or directory: 'build/lib/morphlib/exts/add-config-files.configure'08:55
tlsait seems that file is in build/lib.linux-x86_64-2.7/morphlib/exts/add-config-files.configure08:56
tlsaso it needs to look in the build/lib.<platform> place, rather than build/lib08:57
tlsabut I'm not sure how to do that08:57
SotKLooks like that path is hardcoded here:
paulsherwoodtlsa: why are you trying to run morph on debian? it's unsupported iiuc08:57
tlsapaulsherwood: firehose is a morph plugin08:58
*** ssam2 has joined #baserock08:58
*** ChanServ sets mode: +v ssam208:58
paulsherwoodtlsa: can we decouple it?08:58
tlsaI don't plan to do morph builds on debian, just run firehose08:58
tlsano idea08:58
paulsherwoodhow much code in firehose itself?08:58
* SotK imagines it uses morphlib for reading definitions08:59
tlsaI think it depends heavily on morphlib for definitions reading/writing08:59
* paulsherwood tries to re-engage brain....08:59
SotKISTR it ended up as a morph plugin because of the config morph needs/needed for some stuff08:59
SotKI could be wrong08:59
bashrcthe thing is, firehose isn't standalone. It's horribly entangled with morph09:00
paulsherwoodyou may be right, i've just never thought very hard about firehose. what does it *do* precisely?09:00
* paulsherwood is trying to help, hopes he isn't coming across as a troll :)09:01
SotKAssuming the repo on git.b.o is up to date, this is the dependency I guess:
SotKWe no longer need to care about system branches and workspaces like that, so it can be cleaned up (and maybe just import morphlib rather than being a morph plugin, idk)09:03
bashrcduring my tenure on it, firehose was very dependent on morph, gerrit and the baserock definitions09:03
bashrcI'm not sure it would make any sense to try to use the existing firehose on Debian09:03
SotKpaulsherwood: I believe it looks at new commits on a configurable set of upstream projects updates the ref in definitions to that commit, then sends it to Gerrit/somewhere to be tested.09:04
SotKs/projects updates/projects, updates/09:04
*** lmackenzie_2015 has joined #baserock09:20
paulsherwoodwell, firehose looks nicely written. i can't see that it actually *needs* a whole lot of morph for what it should be doing09:22
paulsherwoodbut i've been wrong before09:22
SotKIt seems to just use MorphSet for updating the morphologies09:23
ssam2i would like to have a 'tools for working with baserock definitions' library in some form09:25
SotKme too09:25
tlsa <-- that made it work, but I'm disgusted by it09:25
ssam2tlsa: wat09:26
* SotK wonders if that would break on a Baserock system now09:26
ssam2if you are trying to get morphlib to install on Debian.. probably easier to just add it to your PYTHONPATH manually if you can09:27
*** lachlanmackenzie has quit IRC09:28
*** CTtpollard has quit IRC09:28
*** CTtpollard has joined #baserock09:28
*** lachlanmackenzie has joined #baserock09:28
*** lachlanmackenzie has joined #baserock09:28
tlsassam2: it's for this -- the build/lib dir had the .<plat> here09:29
ssam2I think that it will probably not work on Baserock now, though. Anyway, you have my sympathy for having to deal with files09:34
ssam2at EuroPython 2015 someone asked Guido van Rossum what his least favourite aspect of Python was, and his answer was something like "anything to do with packaging and distributing Python modules" :-)09:35
bwhI've tried to avoid packaging any Python since going to the Python BoF at DebConf 609:36
bwh...not entirely successfully, as perf embeds Python09:36
paulsherwoodbwh: what happened at the BoF to put you off?09:39
bwhheated discussion about the two different Python packaging helpers in Debian (that is since resolved), also finding that the maintainer for Python itself didn't have much to do with those packaging modules09:40
paulsherwoodoh dear. i guess every project has its drawback09:46
*** edcragg has joined #baserock10:11
*** mariaderidder has quit IRC10:33
*** mariaderidder has joined #baserock10:48
*** De|ta has quit IRC11:04
*** De|ta has joined #baserock11:05
ssam2i imported a baserock 15.34 build system image into OpenStack, and then started cloud-init.service manually from the graphical console, but I still can't log in over SSH11:45
ssam2I wish this would work out-of-the-box11:46
ssam2'systemctl start cloud-init.service' was enough to get the other useful stuff cloud-init does to work, like resizing the disk11:47
ssam2there's no error logs in /var/log/init.err, but no messages about ssh keys in /var/log/init.log either11:48
CTtpollardis your key under authorized keys?11:49
ssam2no, /root/.ssh isn't set up at all11:52
tlsassam2: why make the cache server a morph thing at all?  Why not make it something separate and reusable for non baserock artifact stuff?12:14
ssam2tlsa: is this in context of my email? I didn't mean to suggesting in making the cache server a "morph thing"12:15
ssam2Well, if by "cache server" you mean, then it certainly should be baserock-specific12:15
ssam2but for the program that runs on, it would be nice if it was generically useful12:15
ssam2s/suggesting in/suggest/12:16
tlsa"Add a '/2.0/submit' method to morph-cache-server"12:21
tlsamaybe I got the wong end of the stick12:21
SotKmorph-cache-server is just the name of the program that currently exists12:22
tlsaI see12:22
SotKbecause it was originally implemented to provide a cache server for morph12:22
SotKI don't know if there is anything in it that makes it morph-specific12:22
paulsherwoodin effect we have two distinct cache functions going on, and one program being used for both12:22
paulsherwoodon it's serving built artifacts. on it's serving git repos as tarballs12:23
SotKI thought the tarballs were served by something else?12:24
SotKIsn't the git side of m-c-s is for speeding up some git operations?12:25
paulsherwoodwell i'm assuming a 'bundle' is  the git tarball stuff
paulsherwoodanyways, i'm fiddling with an atomic artifact server while stuck in a waiting room12:27
ratmice___ssam2: did you try running bison's 'build-aux/git-version-gen .tarball-version' (probably through sh -x) to see where it gets that 'UNKNOWN'?12:30
SotKpaulsherwood: maybe, but morph doesn't appear to use the /1.0/bundles endpoint that that is used in so I'm not sure12:31
ssam2ratmice__: in the staging chroot, I did... and it gave the correct version number!12:32
ssam2and .tarball-version didn't actually exist12:32
ssam2very weird12:32
ssam2'bundle' is a dead end that nobody uses, I think12:33
ssam2we once used 'git bundle' to generate tarballs, but now, instead, Lorry generates them and puts them directly into /home/gits/tarballs, where they are served by the HTTP server12:33
ssam2so the bundle/ method could just be removed12:33
ratmice___ssam2: weird, I suppose that it is worth noting that that command runs at 'autoreconf' time, i'm not sure exactly when dependencies are resolved/installed relative to that12:36
ssam2the dependencies are present before anything else happens... I found autoreconf seemed to fail for a different reason when I ran it in the chroot, too12:37
ssam2we more or less proved that the cause of this must be some changes that I made in Morph12:37
ssam2but i can't work out how could actually make this occur12:38
ssam2given that it's running the autoreconf command in exactly the same way as before12:39
SotKrjek: I thought PUT was for creating things that don't exist and updating things that do, rather than giving the server a thing that it then decides whether to do anything with or not?12:56
SotK(so if an already-uploaded artifact is sent in a PUT request the already-uploaded artifact should be replaced by the new one)12:56
bwhSotK: Yes12:57
bwhFor 'do some arbitrary state change using with this blob' there's POST12:57
SotKAlso does PUT /2.0/submit not imply that GET /2.0/submit should return a specific artifact?13:00
rjekI don't think so.13:01
ratmice___ssam2: yeah, nothing stands out to me either & concurr that it looks like build-depends should be resolved before pre-configure13:39
ssam2hmm, PUT /2.0/artifact would probably be a better method for this actually13:42
*** bashrc has quit IRC13:43
*** bashrc_ has joined #baserock13:43
ssam2seems that PUT v POST is not very clear cut, as seems to happen a lot when trying to be RESTy:
ratmice___that said i _don't_ see where the build-depends on git would come from (IIRC from yesterday you said it did)13:45
SotKssam2: that seems to suggest that `PUT /2.0/artifacts/$cache_key` would be best (though that is RESTy, idk if that is the way you want to go)13:46
ssam2sounds good13:47
SotKThat would have the benefit of `GET /2.0/artifacts/$cache_key` returning the artifact too13:47
SotK(at least, that would be a sensible way to return it)13:47
* SotK isn't sure about how that works with the whole "PUT should replace what's there" thing though... I guess it doesn't matter if the server says "I couldn't replace that!"13:48
*** zoli__ has quit IRC13:59
*** petefoth has quit IRC14:24
*** mdunford has quit IRC14:43
*** mdunford has joined #baserock14:45
*** petefoth has joined #baserock15:24
*** paulw has quit IRC15:59
*** mdunford has quit IRC16:15
*** mariaderidder has quit IRC16:21
*** mdunford has joined #baserock16:29
*** straycat has joined #baserock16:49
straycatssam2, should i be able to restore abandoned changes?16:49
ssam2in Gerrit? I don't know16:49
ssam2is this a permissions issue, or something else?16:49
straycatwhen i try to restore 876 i get an error16:49
straycat/src/import # ssh -p 29418 'gerrit review' 876,1 --restore16:49
straycaterror: restore not permitted16:49
straycatone or more approvals failed; review output above16:49
ssam2ok, I guess it's a permissions thing16:50
ssam2I tried the same and didn't get an error, so maybe it's restored now16:50
straycatahh ok16:50
ssam2I think there's no reason to block people from restoring changes, but I don't have time to change the access controls right now16:50
straycatseems to be, thanks16:50
*** jonathanmaw has quit IRC16:50
* straycat nods16:51
straycatokay thanks16:51
*** bashrc_ has quit IRC16:54
*** mdunford has quit IRC17:00
*** ssam2 has quit IRC17:07
*** edcragg has quit IRC17:57
*** zoli__ has joined #baserock18:22
*** lmackenzie_2015 has quit IRC18:41
*** zoli__ has quit IRC21:50

Generated by 2.14.0 by Marius Gedminas - find it at!