IRC logs for #baserock for Wednesday, 2015-03-04

*** ratmice__ has quit IRC04:31
*** ratmice__ has joined #baserock04:31
*** zoli__ has joined #baserock05:47
*** zoli__ has quit IRC06:13
*** zoli__ has joined #baserock07:17
*** zoli__ has quit IRC07:23
*** elevenarms has quit IRC07:24
*** mike has joined #baserock07:29
*** mike is now known as Guest5520607:29
*** pacon has joined #baserock08:11
*** gfinney has joined #baserock08:17
*** pacon has quit IRC08:18
*** petefoth has quit IRC08:24
*** petefoth has joined #baserock08:24
franredpersia, yes, it builds08:34
*** mdizzle has joined #baserock08:50
mdizzlemorning all08:50
*** gfinney has quit IRC08:50
*** gfinney has joined #baserock08:51
*** bashrc has joined #baserock08:59
*** sambishop has joined #baserock09:08
*** pacon has joined #baserock09:10
*** ssam2 has joined #baserock09:22
*** ChanServ sets mode: +v ssam209:22
*** pacon has quit IRC09:23
*** pacon has joined #baserock09:24
*** ssam2 has quit IRC09:26
*** ssam2 has joined #baserock09:28
*** ChanServ sets mode: +v ssam209:28
*** jonathanmaw has joined #baserock09:33
straycatmorning mdizzle09:38
*** tiagogomes has joined #baserock09:39
*** gary_perkins has joined #baserock09:41
*** edcragg has joined #baserock10:01
*** wschaller has joined #baserock10:22
jjardonhi, what metadata is currently stored about what is being builded in a baserock system?  is there any doc about that?10:27
ssam2look in /baserock in a Baserock system10:29
ssam2it should be fairly clear what it all is, I don't think anybody's written anything about it on the wiki10:30
ssam2jjardon: regards version numbers, there's kind of 3 approaches: (a) use upstream tags, (b) detect from repo contents (c) specify them manually in definitions10:39
ssam2(a) is ok except that there aren't always usable tags10:40
ssam2(b) is actually partially implemented already, see the `generate-manifest` command, but it's quite old unloved code10:40
ssam2(c) is a pain for everyone and might not be accurate10:40
jjardonI guess the solution should be a mix of a and b, will take a look to generate-manifest for now, thanks!10:41
ssam2we need to be able to get a version number for everything, but since 'version numbers' are really a human-defined concept, I think detecting them will never be 100% automatic10:41
jjardonmaybe we can detect what was the last tag for a given commit, then say: "this is version x plus this commits: <>"10:43
ssam2yes, 'git describe' will be pretty useful in some cases10:43
jjardonin project that do not use tags we need to think in another solution (I hope they are few nowadays)10:43
* jjardon will look at "git describe"10:44
ssam2it may be handy if there's a way in definitions to manually specify a version number, because sometimes you might want to totally override what goes in the manifest10:44
ssam2e.g. 'v1.0-plus-my-patch-to-fix-bug-xxxx'10:44
jjardonoh! seems exactly what I was asking for, cheers!10:44
ssam2not sure though10:45
jjardonit would be a bit confusing to have a ref and also a version parameter in a chunk... maybe we can reuse the unpetrify-ref one for that ? not sure ...10:46
ssam2would be nice to give unpetrify-ref a more logical name and a reason to exist :)10:48
rdale_+110:48
tiagogomesis there anything better in baserock to create partitions than sfdisk?10:52
straycatcfdisk?11:00
KinnisonI don't think cfdisk is scriptable11:01
straycati didn't realise that was a requirement for this :(11:03
pedroalvarezsfdisk is, but some people told me that it didn't support GPT partition tables11:03
*** wschaller_ has joined #baserock11:07
Kinnisonstraycat: sorry, I have hidden knowledge :)11:08
tiagogomesit doesn't, that why I asked whether there is a better alternative11:08
tiagogomesKinnison, do you know if we need GPT partition tables on the Moonshot?11:08
KinnisonI doubt that it'll be necessary11:08
*** wschaller has quit IRC11:10
pedroalvarezafter looking for some commits in util-linux, I think it may support gpt :/11:14
*** tiagogomes has quit IRC11:14
pedroalvarezI may be wrong11:14
*** tiagogomes has joined #baserock11:14
pedroalvarezerm.. I can't run make in my failed stagging area :/11:17
pedroalvarezusing chroot11:17
pedroalvarezSegmentation fault (core dumped)11:17
paulsherwoodouch11:20
straycatbtw, not sure we ever decided what to do about grep -x11:24
pedroalvarezhttp://paste.baserock.org/raw/qujizaroxa11:24
*** a1exhughe5 has joined #baserock11:26
straycatprobably not too important just now though i guess11:26
paulsherwoodrjek: http://wiki.baserock.org/meetup/cve-tracking/11:27
rjekpaulsherwood: Thanks11:27
tlsathat reminds me the libpng in baserock should be updated to 1.6.16 to fix CVE-2014-949511:29
paulsherwoodok+111:30
paulsherwood:-)11:30
nowsterI submitted a patch to the mailing list 15 mins ago and it hasn't showed up yet.11:33
* SotK is getting other emails on the mailing list, but no patch from nowster11:35
Kinnisonnowster: I don't see mail from you at the ML host yet11:35
Kinnisonnowster: I see other people posting to baserock-dev11:35
nowster2015-03-04 11:16:09 1YT7Hc-0004a5-P7 => baserock-dev@baserock.org R=smarthost T=remote_smtp_smarthost H=mail.codethink.co.uk [192.168.25.1] X=TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128 DN="OU=Domain Control Validated,OU=EssentialSSL Wildcard,CN=*.codethink.co.uk" A=plain C="250 2.0.0 Ok: queued as 7F539460922"11:35
Kinnisonit might be sat on that server, or an intermediate then11:36
Kinnisonbaserock-dev is not on Codethink infrastructure11:36
nowsterand the emails I've seen just now have been sent from gmail.11:36
pedroalvarezo.011:37
tlsahttp://paste.baserock.org/ojepimesoh <-- OK?11:37
tlsahmm, they have a libpng-1.6.16-signed too11:38
pedroalvarezlibpng-1.6.16-master-signed  doesn't match that sha111:39
tlsai got it from http://git.baserock.org/cgi-bin/cgit.cgi/delta/libpng.git/tag/?id=libpng-1.6.16-master-signed11:39
franredhttp://git.baserock.org/cgi-bin/cgit.cgi/delta/libpng.git/commit/?id=070a616b8275277e18ef8ee91e2ca23f7bdc67d511:39
tlsaoh, I see11:40
pedroalvareztlsa I think that v1.6.16 would be better11:41
tlsapedroalvarez: as far as I can see, that sha1 I set is the sha1 of the tag?11:42
pedroalvareztlsa: I'm not sure about that. Maybe someone with more git knowledge... ? :)11:42
tlsait does show up correctly when I search for that sha1 by range11:42
tlsaon the web interface11:43
pedroalvareztrue11:44
pedroalvarezI don't know really :/11:44
straycatusually you use the sha of the tagged object though, not the sha of the tag, i'm not actually sure whether this matters for morph though11:45
tlsahttp://paste.baserock.org/tinozenaye <-- that's for 1.6.16-signed11:46
tlsabut sha1 of the tag11:47
ssam2I think morph will choke if it's the sha1 of tag, it expects a commit object11:47
ssam2maybe not though11:47
tlsadoes it not just checkout the sha1?11:48
paulsherwoodi think it handles sha1 ok11:48
franredtlsa, it still not match with what the web point to it: http://git.baserock.org/cgi-bin/cgit.cgi/delta/libpng.git/commit/?id=88dd30b232362b65cca374dda39096888163dd6b11:48
*** pacon has quit IRC11:49
*** franred has quit IRC11:49
tlsafranred: http://git.baserock.org/cgi-bin/cgit.cgi/delta/libpng.git/log/?qt=range&q=df17b602414e82a7bbbaea0aa42bbc21de83a25011:50
*** wdutch has quit IRC11:50
*** franred has joined #baserock11:50
tlsafranred: http://git.baserock.org/cgi-bin/cgit.cgi/delta/libpng.git/commit/?id=df17b602414e82a7bbbaea0aa42bbc21de83a25011:52
franredtlsa, yep so for me the ref would be 88dd30b232362b65cca374dda39096888163dd6b and not df17b602414e82a7bbbaea0aa42bbc21de83a25011:53
pedroalvarezwe can use http://git.baserock.org/cgi-bin/cgit.cgi/delta/libpng.git/tag/?h=libpng16&id=v1.6.16, and finish the discussion :P11:53
tlsabut I've got the tag name in the documentation field, so I put the tag ref in11:53
bashrcgetting an account on http://gerrit.baserock.org seems pretty hard11:55
pedroalvarezbashrc: was straight forward to me11:55
bashrclogin with google doesn't work11:55
franredtlsa, I won't risked it and use the commit sha that wbo gives to me11:55
pedroalvarezbashrc: that is a known bug in gerrit11:56
pedroalvarezbashrc: and I think they don't care about it11:56
pedroalvarezthat's why we set up openid.baserock.org11:56
bashrcok11:56
bashrconly one thing I notice about openid.baserock.org is that it appears to send credentials over http11:57
pedroalvarezalso our  storyboard instance needed an openid provider (other reason to create openid.b.o)11:57
nowsterstill no sign of that patch email... It's probably gone in the moderation queue. :(11:57
pedroalvarezbashrc: true, we are wokring on that11:58
straycattlsa, have you tried building with that?11:58
*** wdutch has joined #baserock11:59
tlsano, but when I did the xfce stuff I was upating to tag sha1s right and left11:59
tlsa(I assumed that was what I was supposed to do when I used a tag in the documentation field)12:00
straycatthen i guess it's fine, +1, if it does break then i guess that might be considered a bug12:01
* pedroalvarez hopes this doesn't break genivi 2 days before a release :)12:02
straycatdon't really have time to check the code, but i just built libpng from that sha so i think it's ok12:15
tlsapedroalvarez: libpng is in the genivi release, so I think it would be good to fix the CVE (allows attacker to overwrite arbitrary amount of mem with attacker-controlled data)12:17
ratmice__wrt ABI doesn't the cache key contain all the cppflags, so wouldn't it be possible to define -DBASEROCK_LIBC_SHA1=$(some magic)...(?) when compiling gcc to get the missing dependency stuff included into the cache key?12:17
ratmice__with $(some magic) probably having to be run by morph rather than the shell :)12:18
ratmice__suprised it got to stage2 make, thought it wuold have bailed at stage2 glibc running rpcgen or whatever its called12:22
ratmice__ahh, n/m stage1 is probably still around and binary compatible12:24
straycatrichard_maw, thanks for merging that12:35
ratmice__anyhow this is really why i prefer building gcc+everything else as one big uberbaum tree, but AFAIK nobody has done that with glibc12:40
*** zoli__ has joined #baserock12:40
ratmice__that is where you check out newlib/binutils/gdb/gcc into one massive checkout and issue one ./configure/make to build the entire thing, you can kind of do so with git-readtree and sparse checkouts, but as I said I don't think the top-level gcc configure supports building glibc12:44
*** mdizzle has quit IRC12:45
* nowster thinks baserock-dev hates him. Waahhh!12:50
*** jonathanmaw has quit IRC12:57
persianowster: I assure you it doesn't, but why do you think it may?12:58
petefothWhat's the morph command to display the help for a specific write extension?12:58
* petefoth guesses the answer :)12:59
pedroalvarezI always forget13:00
pedroalvarezmorph help tar.write13:00
petefothmorph help initramfs.write was what I guessed13:00
petefothand it seemed to work13:00
nowsterpersia: I wrote it a little letter with a patch in it, and it's thrown it away.13:04
persiaWhen that happens to me, it's usually because either 1) I typoed the address (most common reason), or 2) I sent from a new address and got caught by the "must send from recipient" filter into the moderation queue.  #2 seems common for folk who use git-send-email and aren't careful configuring git.13:05
ssam2i've not received any moderation emails for baserock-dev today13:05
nowsterFrom: Paul Martin <paul.martin@codethink.co.uk>13:06
nowsterTo: baserock-dev@baserock.org13:06
nowstermust be stuck on mail.ct13:07
petefothI've seen some delays today when sending via mail.ct13:07
nowsterthe carbon copy got through13:07
petefothnowster: it was a bcc: to an external address that got delayed for me. the to: to a ct addresss arrived very qucikly13:08
*** jonathanmaw has joined #baserock13:13
pedroalvarezI assume that this error in Weston (Genivi) means that I need xcb in the system?13:16
pedroalvarezhttp://paste.baserock.org/corilurayu13:16
franredIm moving lxml to python-common, but it does depend on libxml and libxslt which are in core and in foundation, so make sense to add foundation to python-common as a dependecy?13:24
persiaNot having foundation as a dependency of python-common means less duplication for alternate toolchains.13:27
franredpersia, I can add libxslt to core and python-common will depend on core instead...13:28
persiaSame class of problem.13:28
persiaFor an alternate toolchain for C, we end up with another copy of all the C stuff: build-essential, core, foundation, etc.13:29
persiaWe can reuse the current python stuff, because it's all python, so as long as there is *some* python interpreter it works.13:29
franredI can add lxml into foundation then13:30
persiaThat said, I'm still not convinced the right way to add toolchains is by adding more strata.13:30
persiaIt might be better to fork the repo, so that only build-essential is changed.13:30
persiaIn which case, your change suddenly doesn't affect things at all.13:31
* paulsherwood wonders if that's really better13:32
franredat the moment foundation depends on C because it has libxslt so I will add lxml there and no C dependencies to python-common13:33
persiaThat's probably the best compromise path until a decision is taken on the best way to handle multiple C toolchains.13:34
*** Krin has quit IRC14:41
*** Krin has joined #baserock14:49
*** tiagogomes has quit IRC15:06
*** tiagogomes_ has joined #baserock15:14
*** inara has quit IRC15:17
*** inara has joined #baserock15:24
paulsherwoodrjek: also you may have missed this... http://wiki.baserock.org/meetup/developing-secure-systems/ ?15:27
paulsherwoodrjek: please feel free to amend, or append etc :)15:27
rjekpaulsherwood: That bullet list seems very familiar... :)15:28
rjekThanks.15:28
tiagogomes_if `$ sfdisk` works, but `/usr/bin/env sfdisk` doesn't; what could be the cause?15:30
tiagogomes_ok, $PATH is not an exported variable on a installer system15:38
*** Guest55206 has quit IRC16:01
paulsherwoodrjek: i daresay. i was only minuting what was discussed in the meeting, since you were doing much of the talking :)16:11
rjekPerhaps I talk too much.16:12
paulsherwoodno, i would not say that16:12
bashrcQ: is a chunk an application definition?16:13
paulsherwoodbashrc: it's a single upstream project, usually. eg linux, systemd etc16:14
richard_mawso all the plumbing that applications need as well as the applications themselves16:15
paulsherwoodhttp://wiki.baserock.org/glossary/#index10h216:15
*** zoli__ has quit IRC16:22
bashrcwould .morph files be better named .chunk, or am I missing something16:41
persiaThere's several kinds of morph files.16:43
persiaI think the folk talking about the next version of definitions were talking about using .def16:43
persiaBecause some are chunk morphologies (component definitions), and some define other sorts of things.16:44
Zara(chunks make up strata, strata make up systems; all of these are .morph files)16:44
persiasystems make up clusters16:45
*** zoli__ has joined #baserock16:45
bashrcinstead of having a kind field what about having .chunk, .strata, .system, .cluster ?16:46
*** zoli__ has quit IRC16:47
persiaSince there's active debate about the entire model, and such a change requires a definitions version change, I don't think there is a point to doing that.16:48
Zarapersia: I thought a whole bunch of different things could make up a cluster? (I'm just using the term 'system' here to mean 'things listed in "systems" in definitions')16:49
persiaIf you'd like to fix that class of annoyance, I encourage you to participate in the discussion on the next version of definitions.16:49
persiaZara: My understanding was that a cluster was always the deployment instructions for one or more systems.16:49
persiaAs an example, a cluster might define a system for a rootfs and a system for an initramfs, to be depoyed together.16:50
persiaOr it might define an entire distbuild network, to be deployed simultaneously to several hardware nodes.16:50
persiaI don't know how one might use a stratum or chunk in such a context.16:50
*** zoli__ has joined #baserock16:53
Zarapersia: yeah, practically speaking I see it as a system + deployment instructions for that system; I just got confused.16:54
persiaI switched mostly to clusters with embedded initramfs a while back, to make things more portable, which forces me to pay more attention to the distinction, but yeah, I can see that.16:55
*** jonathanmaw has quit IRC17:04
Krinquick question, for lorrys are repos following the format "https://github.com/openstack/tempest-lib" acceptable or do they have to start with "git://..."17:05
persiagit:// is preferred, https:// is acceptable.17:06
perrylISTR using git:// with github repos and it not working, though i could be mistaken17:07
richard_mawit usually works for me, though github don't give you the git:// urls by default17:08
richard_mawSotK: your OSTree patch series really baked my noodle17:09
richard_mawI hope I've given you useful feedback17:11
Krinthanks all17:11
*** tiagogomes_ has quit IRC17:11
nowstercloning from github: can be very slow17:11
*** tiagogomes_ has joined #baserock17:11
franredKrin, I would check if http://git.openstack.org/cgit/ has the repository if it is openstack related, although persia may have some concerns about this17:13
pedroalvarezKrin: as you can see in the README of that repo, the official repo is http://git.openstack.org/cgit/openstack/tempest-lib17:13
pedroalvarezsnap17:13
persiaGenerally speaking, I think we should prefer git.openstack.org over the github mirrors.  This is true for any project where developers push commits somewhere other than github.17:14
Krinokies, i'll amend those now :)17:16
Krinwell spotted17:16
bashrclooking at some morph chunk files, they're almost like Makefiles17:46
*** Krin has quit IRC17:47
persiaThe key difference is the execution paradigm: there is no parse-time execution, there is no reentrant behaviour, etc.17:51
persiaThe problem with makefiles is that it is easy to write code that executes at parse-time that totally changes the behaviour of the code that executes at runtime, which is convenient as a oftware developer, but inconvenient from the perspective of a system integrator (because it makes it harder to have things happen twice the same way)17:52
bashrcalso, some chunks appear to have no reference to source code, like this http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/tools/gdb.morph17:53
bashrcwhen it's building, how does the system know where to get the gdb source from?17:54
*** gfinney has quit IRC17:55
Zarabashrc: my guess is it gets the ref from the tools.morph stratum (in 'strata'), though I don't know why tools.morph was chosen over gdb.morph (this kind of thing has confused me before, so if someone understands it I'd appreciate the explanation!)17:58
radiofreebashrc: think of that as the build instructions17:58
radiofreeyou can see where it gets the source from in the startum http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/tools.morph#n1817:58
persiaThe idea is that the ref changes more often than the build instructions.17:58
*** ssam2 has quit IRC17:58
persiaSo it should be easy to change refs (in strata) without touching the chunk morphologies.17:58
radiofreeyep, e.g building xorg17:58
*** a1exhughe5 has quit IRC18:00
bashrcradiofree: ah ok, is there any advantage to specifying that at a higher level, rather than within gdb.morph ?18:00
persiabashrc: Consider the case where you have to change the ref for a large number of components (e.g. Qt or Xorg).  How many files do you want to edit?18:01
persiaAlso, how do you want to read the results of `git diff` to see what you did?18:01
bashrcanother point is that I don't see any reference to tools.morph within gdb.morph, but maybe its interpreted the other way around. Still, doesn't seem ver readable (i.e. guess which higher level morph this one is in)18:03
persiatools says "This stratum contains gbd, at this repo, and this ref".18:04
persiaErr, gdb.18:04
persiamorph looks about to find gdb.morph to figure out how to build gdb.18:04
persiagdb can be included in any stratum: it really doesn't care.18:04
bashrcok, but just from the human readability point of view it doesn't seem very easy to know how things link together. I suppose that could be done with a tool18:05
persiaAnd there's lots of reasons to have multple strata contain the same component: e.g. building with different build-dependencies for different behaviours(because ./configure behaviour depends on what is installed in the build environment),18:05
persiaTo be extra clear, gdb.morph does not link anywhere (although it may be used in several places), and this is intentional.18:06
persiagrep can tell you in which strata something is used.18:06
bashrcright. seems like a crude solution though18:07
bashrcanyways, that's all my conundrums for now18:07
*** zoli__ has quit IRC18:07
*** bashrc has quit IRC18:07
persiaHow crude?18:07
persiaI really wouldn't want to have gdb.morph understand any higher level, because that makes it hard to include in lots of places.18:08
persiaAnd I don't want the repo/ref in gdb.morph because that makes it annoying to locally fork, deal with lots of simultaneous updates, etc.18:09
straycatwe could have components explicitly specifying the components they depend on, but then you'd want to be able to have macros or something to allow you to specify groups of dependencies otherwise it would be unmanageable18:09
persiaBut I'd be curious to hear how this arrangement might be confusing, or what sort of tooling you imagine would be less crude.18:09
radiofreehe left18:09
persiaAh, good point.18:09
persiaIn an ideal world, he'll read the backscroll on irclogs.baserock.org when he returns :)18:10
*** zoli__ has joined #baserock18:11
*** zoli__ has quit IRC18:18
*** edcragg has quit IRC18:22
*** tiagogomes_ has quit IRC18:26
*** franred has quit IRC18:31
pedroalvarez-= THIS MESSAGE NOT LOGGED =-19:20
* pedroalvarez runs away19:21
*** zoli__ has joined #baserock19:23
straycat-= THIS MESSAGE NOT LOGGED =-19:35
straycat.19:36
SotKIt logs that you said something that wasn't logged though I see19:39
persiaThis is a feature.  A proper redacted log is important, so that if folk respond to unlogged discussion, it doesn't appear they are out of their mind.19:50
SotKmakes sense19:54
*** zoli__ has quit IRC20:22
*** rdale_ has quit IRC20:30
*** rdale has joined #baserock20:33
*** zoli__ has joined #baserock20:33
*** rdale has quit IRC20:39
*** rdale has joined #baserock20:44
*** rdale_ has joined #baserock20:46
*** rdale has quit IRC20:48
*** pacon has joined #baserock20:53
*** rdale has joined #baserock21:08
*** rdale_ has quit IRC21:08
*** rdale_ has joined #baserock21:11
*** rdale has quit IRC21:12
*** gary_perkins has quit IRC21:48
*** pacon has quit IRC22:07
*** zoli__ has quit IRC23:08
*** zoli__ has joined #baserock23:09
*** zoli__ has quit IRC23:26

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