| *** zoli__ has joined #baserock | 02:33 | |
| *** zoli__ has quit IRC | 02:38 | |
| *** zoli__ has joined #baserock | 03:11 | |
| *** zoli__ has quit IRC | 03:39 | |
| *** zoli__ has joined #baserock | 04:38 | |
| *** petefoth has joined #baserock | 05:08 | |
| *** mariaderidder has joined #baserock | 06:59 | |
| *** Albert_ has joined #baserock | 07:08 | |
| *** a1exhughe5 has joined #baserock | 07:13 | |
| *** franred has joined #baserock | 07:31 | |
| *** rdale has joined #baserock | 07:37 | |
| *** bashrc_ has joined #baserock | 08:02 | |
| *** sambishop has joined #baserock | 08:14 | |
| *** gary_perkins has joined #baserock | 08:26 | |
| *** edcragg has joined #baserock | 08:36 | |
| *** jonathanmaw has joined #baserock | 08:39 | |
| *** ssam2 has joined #baserock | 08:44 | |
| *** ChanServ sets mode: +v ssam2 | 08:44 | |
| ssam2 | jjardon: thanks for fixing up the ostree branch! | 08:51 |
|---|---|---|
| tiagogomes_ | morning, how do I create an internal link to an section header for w.b.o using markdown | 09:06 |
| Kinnison | w.b.o doesn't seem to have header-anchors turned on | 09:08 |
| ssam2 | what is that? does that make it possible to have links to subsections of wiki pages that aren't useless ? | 09:09 |
| * Kinnison is having to rebuild the wiki, please hold | 09:09 | |
| Kinnison | ssam2: yes | 09:09 |
| Kinnison | right that's done | 09:09 |
| ssam2 | wow, we should enable that | 09:09 |
| Kinnison | tiagogomes_: if you look at the generated HTML for a page, you'll now see ids on <h1> etc | 09:09 |
| Kinnison | tiagogomes_: You can link to those with links along the lines of [something or other](#heading_anchor_id) | 09:10 |
| * Kinnison hopes that helps | 09:10 | |
| tiagogomes_ | I tried the [something or other](#heading_anchor_id) thingy, but I may had set the wrong id | 09:10 |
| * tiagogomes_ checks | 09:10 | |
| jmacs | [[guides#GENIVI]] also works, although I'm not quite sure how | 09:12 |
| Kinnison | double-square-brackets are ikiwiki markup rather than markdown | 09:13 |
| *** Krin has joined #baserock | 09:14 | |
| tiagogomes_ | Kinnison yep, using the wrong ID. I assumed that the ID would be the section header with the words separated by hyphens instead of spaces | 09:14 |
| Kinnison | wikilinks are odd and magical so I'm not unsurprised that it works | 09:14 |
| Kinnison | tiagogomes_: I don't know the algorithm for generating ids :) | 09:14 |
| *** lachlanmackenzie has joined #baserock | 09:15 | |
| jmacs | I can't get [guides](#GENIVI) to work - I put that on the Sandbox page, and it creates a link to http://wiki.baserock.org/sandbox/#GENIVI | 09:16 |
| tiagogomes_ | the generated link seems fine, the problem is that there isn't an anchor named 'GENIVI' | 09:17 |
| jmacs | Aha, [Things](/guides#GENIVI) does though | 09:17 |
| *** mauricemoss_ has joined #baserock | 09:23 | |
| jjardon | ssam2: no :) | 09:26 |
| jjardon | Np* | 09:26 |
| jonathanmaw | well, that's odd. I deployed a fresh VM with my pam changes and I can't log in as root | 09:58 |
| jonathanmaw | everything's as expected for /etc/passwd, no password is set in /etc/shadow | 10:02 |
| jonathanmaw | I'm going to add my ssh key and see if I can get in that way. | 10:02 |
| Kinnison | Woah, so close http://paste.baserock.org/tepojuvoza | 10:03 |
| Kinnison | I have no idea how paste.b.o chooses its highlighting rules | 10:03 |
| tiagogomes_ | richard_maw, does this makes sense: https://gerrit.baserock.org/#/c/426/ ? Or a different IP address was intentional? | 10:04 |
| richard_maw | tiagogomes_: what? I see no changes about IP addresses | 10:06 |
| tiagogomes_ | richard_maw sorry, was this one https://gerrit.baserock.org/#/c/439/ | 10:07 |
| richard_maw | I'm not sure how much of the HOSTS_SELF bit is needed, but that address was what dhcp was giving it | 10:08 |
| richard_maw | the point was that it is the IP of the external interface | 10:08 |
| tiagogomes_ | then pherpahs for the controller HOSTS_SELF should be the external IP addr as well | 10:13 |
| jjardon | jonathanmaw: in what order did you install the packages? for what I read about pam the order matter, and I think it should be: attr -> acl -> pam -> libcap -> shadow | 10:16 |
| jonathanmaw | ah, shadow isn't using libcap | 10:17 |
| * jonathanmaw didn't know libcap had to be moved as well | 10:18 | |
| jonathanmaw | attr -> acl -> pam -> shadow | 10:18 |
| jjardon | jonathanmaw: I do not know neither for sure, only the little I read about it :). Also, did you configure /etc/login.defs ? You can see how in this guide to use pam with shadow: http://www.linuxfromscratch.org/blfs/view/svn/postlfs/shadow.html | 10:21 |
| edcragg | silly question... how is morph installed in built systems? i don't see any obvious strata | 10:24 |
| ssam2 | morph-utils.morph | 10:24 |
| jjardon | jonathanmaw: mmm, seems we are missing several files in our shadow chunk. These are the ones in Arch: https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/shadow | 10:25 |
| tiagogomes_ | the reads obviously enough to me :) | 10:25 |
| edcragg | ssam2: ah yes, thanks | 10:25 |
| jonathanmaw | jjardon: I have a /etc/login.defs, nothing in it stands out as being wrong. | 10:35 |
| richard_maw | jonathanmaw: well, apart from it using DES for the password hashes | 10:41 |
| jjardon | jonathanmaw: rigth, check you have all the pam configuration files as well: you can take a look to the Arch ones here: https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/pambase | 10:41 |
| jjardon | richard_maw: yep, Arch overwrite the files and uses SHA512 | 10:42 |
| richard_maw | I've got a patch that needs reviewing to make us do that too | 10:43 |
| Krin | richard_maw, point mme at it and i'll give it a look over | 10:44 |
| richard_maw | Krin: enjoy: https://gerrit.baserock.org/#/c/284/ | 10:44 |
| Krin | i refuse to enjoy, i shal but do. | 10:45 |
| *** ssam2 has quit IRC | 10:54 | |
| *** franred has quit IRC | 10:55 | |
| Krin | ugh, i forget, doing a review branch using gerrit is 'git review 'commit-id' '? or am i losing my marbles? | 11:00 |
| *** Albert_ has quit IRC | 11:01 | |
| jjardon | Krin: git review -d <gerrit change number> | 11:01 |
| jjardon | git review -d 284 for the Richard patch, for example | 11:02 |
| *** franred has joined #baserock | 11:02 | |
| Krin | ok. yep my marbles are all over the floor XD | 11:02 |
| Krin | thanks jjardon | 11:03 |
| *** ssam2 has joined #baserock | 11:03 | |
| *** ChanServ sets mode: +v ssam2 | 11:03 | |
| jjardon | ssam2: FYI: 22:45 <jjardon> uh, our u-boot version is 3 years old ... it can be the cause why highbank doesnt with new kernels: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/136992.html | 11:12 |
| jjardon | 22:47 <SotK> jjardon: looks very similar, repost that link tomorrow when ssssam is online I guess :) | 11:12 |
| jjardon | 22:47 <jjardon> yep | 11:12 |
| jjardon | 22:48 <jjardon> only so I do not forget: secure mode can be configured with the bootm_boot_mode u-boot option | 11:12 |
| ssam2 | oh! | 11:17 |
| ssam2 | although i have no idea how to flash u-boot on calxeda | 11:17 |
| ssam2 | or if that's even possible | 11:17 |
| ssam2 | but thanks, that's really useful to know | 11:18 |
| ssam2 | 'That should save some other poor sucker many wasted hours.' indeed. | 11:18 |
| richard_maw | IIRC the last time we tried updating the firmware we bricked half the nodes | 11:19 |
| richard_maw | and that was with a provided blob | 11:19 |
| richard_maw | and we no longer have the option of RMA | 11:19 |
| ssam2 | new version of patches to add OSTree to definitions for use by Morph: https://gerrit.baserock.org/#/c/367 | 11:20 |
| ssam2 | have built this up to ostree on x86 | 11:20 |
| ssam2 | jjardon: do you have time to check it over quickly? | 11:21 |
| ssam2 | only change since the last version is to add morph to cross-bootstrap systems actually | 11:22 |
| ssam2 | add ostree to cross-bootstrap systems even | 11:22 |
| jjardon | ssam2: sure | 11:23 |
| jjardon | ssam2: mmm, if you add python-pygobject to the cross-* systems, should not be foundation have to be added as well? | 11:26 |
| jjardon | (for the GLib dependency) | 11:26 |
| ssam2 | oh, good point | 11:26 |
| ssam2 | thanks | 11:26 |
| ssam2 | which is really defeating the point of the cross-bootstrap system... | 11:27 |
| ssam2 | but the alternative is maintain code for 2 types of artifact caching, which is also far from ideal | 11:28 |
| jjardon | yeah :( maybe we should split GLib in its own stratum? | 11:28 |
| jjardon | (with gobject-introspection on it as well) | 11:28 |
| ssam2 | yeah | 11:30 |
| ssam2 | doesn't really make sense having it in with foundation | 11:30 |
| jjardon | ssam2: I already make a comment in my own patch but; are we sure we depend on python-core in python-pygobject? if yes it should be added in the corss-* systems as well | 11:31 |
| ssam2 | v5 sent: https://gerrit.baserock.org/#/c/367/5 | 11:31 |
| ssam2 | jjardon: hmm, ok | 11:31 |
| jjardon | sorry I didnt spot this yesterday :/ | 11:32 |
| ssam2 | sorry we don't have code to runtime dependencies | 11:33 |
| ssam2 | it's not sensible to make humans have to work this stuff out when computers can do it | 11:33 |
| ssam2 | ok, there's a v6: https://gerrit.baserock.org/#/c/367/6 | 11:34 |
| ssam2 | it's shit that we have to make cross-bootstrap massive suddenly. but none of the extra python stuff should really cause problems | 11:34 |
| ssam2 | thank you! | 11:39 |
| jjardon | yeah, lets fix dependencies when this got merged: Ive +1 all the patches in the series I didn't send myself (which have a implicit +1) | 11:39 |
| ssam2 | cool. We now have OSTree in definitions! | 11:42 |
| jjardon | "2015-04-23 10:59:55 system minimal-system-armv5l-aspeed is cached at ..." :) <- Im interested myself on making the cross systems as small as possible :) | 11:42 |
| jjardon | ssam2: \o/ | 11:42 |
| ssam2 | next stop: add unionfs-fuse, so the morph branch will work without needingt linux 3.18 | 11:42 |
| ssam2 | and because i have to rebuild everything above systemd to try it out, that may take the rest of the day.... :( | 11:46 |
| *** Albert_ has joined #baserock | 12:22 | |
| *** ssam2_ has joined #baserock | 12:23 | |
| *** ssam2 has quit IRC | 12:25 | |
| *** franred_ has joined #baserock | 12:50 | |
| *** franred has quit IRC | 12:54 | |
| *** mariaderidder has quit IRC | 12:54 | |
| *** mariaderidder has joined #baserock | 12:55 | |
| richard_maw | recent commits to systemd imply that CONFIG_FHANDLE may return to being optional, but only with a recent kernel | 12:56 |
| * Kinnison takes a deep breath and asks ybd to build and deploy a disk | 13:02 | |
| paulsherwood | whoah! :) | 13:02 |
| Kinnison | 2015-04-23 13:08:33 [ybdtest.build-system-x86_64@979403e28f2b934ddb221333e6aeed50033ac28dfacef40f82304f21d1537d9f.build-system-x86_64] Deployment begins | 13:09 |
| * paulsherwood imagines Kinnison, cackling with a maniac grin | 13:12 | |
| mwilliams_ct | can confirm | 13:12 |
| * Kinnison actually fetched tea and quietly looked at snake and kitten pictures | 13:12 | |
| Kinnison | but you can imagine whatever you want | 13:12 |
| Kinnison | 2015-04-23 13:10:51 [ybdtest.build-system-x86_64@979403e28f2b934ddb221333e6aeed50033ac28dfacef40f82304f21d1537d9f.build-system-x86_64] Running write method: ['/src/morph/morphlib/exts/rawdisk.write', '/src/tmp/deployments/tmpOVL3_v', 'build-system-x86_64-ybdtest.img'] | 13:13 |
| * Kinnison taps his fingers impatiently | 13:13 | |
| * paulsherwood too | 13:13 | |
| Kinnison | 2015-04-23 13:14:08 [TOTAL] Elapsed time 00:12:35 | 13:14 |
| Kinnison | 2015-04-23 13:14:08 [clusters/ybdtest.morph] Finished | 13:14 |
| * Kinnison very gently pokes it | 13:14 | |
| paulsherwood | kaboom :) | 13:14 |
| Kinnison | Holy butts, it booted | 13:15 |
| paulsherwood | heh | 13:15 |
| Kinnison | *and* jonathanmaw just gave me money | 13:15 |
| Kinnison | it must be my lucky day | 13:15 |
| paulsherwood | rofl | 13:15 |
| paulsherwood | were the two incidents related? | 13:15 |
| Kinnison | no | 13:16 |
| Kinnison | jonathanmaw just loves me that much | 13:16 |
| paulsherwood | so does the booted system appear to be similar to a normal build system? does it appear functional? | 13:16 |
| * Kinnison is poking it, gently, as stated | 13:16 | |
| Kinnison | so far, I can log in | 13:16 |
| Kinnison | It does not seem to have DHCP'd | 13:17 |
| Kinnison | there are some errors in the boot log | 13:17 |
| straycat | did you run the usual set of config extensions? | 13:17 |
| Kinnison | I did | 13:18 |
| perryl | in gerrit, do +1s work across patches? i'm looking at https://gerrit.baserock.org/#/c/408/ which has +1 each for the 4th and 5th revisions...looking at the changes between the revisions the only difference seems to be that one was rebased atop master, so they're essentially the same | 13:22 |
| * straycat is looking at 408 as it happens | 13:22 | |
| straycat | I can also test the change in theory | 13:22 |
| perryl | straycat: ahh, thanks! | 13:23 |
| *** zoli__ has quit IRC | 13:29 | |
| paulsherwood | Kinnison: are your patches decent enough for public consumption? | 13:36 |
| *** a1exhughe5 has quit IRC | 13:38 | |
| Kinnison | no | 13:38 |
| Kinnison | Not until I work out what's going on | 13:38 |
| Kinnison | and clean them up after | 13:38 |
| paulsherwood | :) | 13:38 |
| Kinnison | Okay, I may have found the hiccough there | 13:53 |
| * Kinnison redeploys | 13:53 | |
| Kinnison | Well, I believe that's plausible | 14:02 |
| Kinnison | I shall clean up these commits now | 14:02 |
| Kinnison | paulsherwood: how picky are you about whitespace | 14:03 |
| Kinnison | ? | 14:03 |
| *** a1exhughe5 has joined #baserock | 14:03 | |
| Kinnison | paulsherwood: master of my ybd can now deploy in a rudimentary fashion | 14:06 |
| Kinnison | paulsherwood: I invoke it with: env PYTHONPATH=/src/morph python /src/ybd/ybd.py clusters/mytestcluster.morph x86_64 | 14:07 |
| Kinnison | paulsherwood: it's all very *very* dodgy for now | 14:07 |
| Kinnison | My brain is now frazzled, so for now it's not very nice | 14:08 |
| *** zoli__ has joined #baserock | 14:28 | |
| * pedroalvarez tests linux 4 on ppc64 | 14:30 | |
| pedroalvarez | that worked | 14:31 |
| *** Albert_ has quit IRC | 14:36 | |
| *** Albert_ has joined #baserock | 14:37 | |
| persia | Kinnison: WIth your ybd success today, are we closer to a workflow that gives a working development environment with `pip install ${FOO}; git clone ${BAR}`? | 14:55 |
| Kinnison | No idea | 14:56 |
| Kinnison | ybd still depends on linux-user-chroot and is utterly unsuitable for anything other than experimentation by people very experienced in how Baserock works | 14:57 |
| Kinnison | (IMO) | 14:57 |
| Kinnison | All I've done is hacked in some deployment capability so that paulsherwood or others can continue to experiment and learn | 14:57 |
| jjardon | ssam2_: are you sure python-cliapp actually depends on python-core? I built a cross* systemd without having python-core on it (python-core was not added to cross* systems when python-cliapp was introduced) | 15:00 |
| persia | Oh, hrm. | 15:00 |
| ssam2_ | jjardon: ah, i'm not sure | 15:03 |
| Kinnison | persia: if someone actually tasked me with what you just asked about, I assume I'd spend some time first working out how to get there, and thence how to start | 15:03 |
| ssam2_ | jjardon: remove it if it's not needed after all | 15:03 |
| ssam2_ | me and richard_maw are wondering who pushed master of mime-types.git to git.git on git.baserock.org | 15:04 |
| ssam2_ | http://git.baserock.org/cgi-bin/cgit.cgi/delta/git.git/tree/ | 15:04 |
| ssam2_ | that is definitely not the source code to Git! | 15:04 |
| persia | Kinnison: Fair. When ybd started, I had the impression it would have different dependencies, and that these would end up documented, but things don't always work out the way one hopes. | 15:04 |
| ssam2_ | I guess it must have been Lorry, i don't think anyone else can force-push to master of delta/ | 15:05 |
| Kinnison | persia: right now, the critical thing missing is a formal specification for Baserock definitions -- who knows what ybd is "doing wrong" so far? | 15:05 |
| persia | Kinnison: BNR or some such? | 15:06 |
| Kinnison | BNR? | 15:06 |
| * persia can't spell | 15:07 | |
| persia | I apparently meant "BNF", although amusingly the wikipedia page for "Backus-Naur Form" is the first hit for "BNR" from my preferred search engine. | 15:07 |
| Kinnison | heh | 15:07 |
| Kinnison | Right, erm, not necessarily | 15:08 |
| persia | Right, so what level of formality do you imagine then. | 15:08 |
| persia | To put it another way: how formal is formal? | 15:08 |
| Kinnison | Perhaps I don't mean 'formal' so much as 'as complete as possible' | 15:08 |
| Kinnison | I want a document which I could use, without referring to morph's codebase at all, to implement something to process a definitions tree and build and deploy systems | 15:09 |
| persia | If we're going for complete, we may as well go for formal. Hard to validate otherwise. | 15:09 |
| jjardon | If the stuff in http://wiki.baserock.org/definitions/current/ is not enough, please add what you think is missing | 15:10 |
| persia | My search engine fails me, but is there anything like a DTD for YAML that can be used to validate that a given document matches a given specification? | 15:10 |
| Kinnison | persia: there are some fairly simplistic structural schema things out there which I have used on other projects -- I think locallycompact might remember what it was called | 15:12 |
| persia | jjardon: The three issues are 1) the document claims not to be a specification (it also claims to be inaccurate), and 2) the document does not claim to be complete, and 3) we have no way to validate a given set of definitions against the content provided to determine if it complies with the non-specification. | 15:12 |
| Kinnison | jjardon: I think that is entirely inadequate and have nowhere near enough time to "add what I think is missing" right now | 15:12 |
| Krin | hey all, trying to deploy a baserock system, and it's been sitting at this for a long time now (as can be seen on the timestamp) | 15:13 |
| Krin | 2015-04-23 14:49:25 [systems/openstack-system-x86_64.morph][release]Fetching to local cache: artifact openstack-system-x86_64-rootfs | 15:13 |
| Krin | anyone have any ideas? | 15:13 |
| Kinnison | Krin: Is your network interface still transferring? | 15:13 |
| Kinnison | Krin: it could be a very slow internet connection | 15:13 |
| Krin | how would i test that Kinnison? | 15:13 |
| Krin | th wifi light is still going like crazy, just realised i forgot the ethernet when i came back into the office today ¬.¬ | 15:15 |
| Kinnison | If your wifi isn't great, it could be that | 15:15 |
| franred_ | Krin, you can use --verbose to check what is doing your morph command | 15:15 |
| Krin | k. gonna plug the ethernet in, kill it and restart it with verbose, thanks all :) | 15:16 |
| jjardon | persia: yeah, it has issues but its the best we have rigth now. The only way to improve it is to help adding the missing stuff | 15:16 |
| persia | jjardon: I'm much more tempted to toss it out completely and draft a formal document of what I want. Trying to determine a specification from a working system is something I try to avoid. | 15:17 |
| franred_ | Krin, also you are trying to download 10 GB of rootfs, I would suggest you to build your rootfs - I disabled the cached for this | 15:17 |
| franred_ | reason | 15:18 |
| persia | This isn't to say that someone else shouldn't add to it if they like, but rather that I think it worth considering what class of specification we want, and how we can validate it, before we try to populate it. | 15:18 |
| persia | franred_: Why? | 15:18 |
| franred_ | persia, build the rootfs with the cached artifacts was faster than download 10 GB | 15:19 |
| franred_ | more if you are using the wifi | 15:19 |
| persia | Ah, so the optimisation to not bother downloading the artifacts if you can download the rootfs never landed? | 15:20 |
| pedroalvarez | franred_: 10G?? | 15:20 |
| jjardon | persia: rigth, other projects (jhbuild) use a DTD, but as you Im not usre something similar exist for YAML. Do you know if Yocto has some kind of validation tool? | 15:20 |
| Kinnison | While I've not used it, https://github.com/Grokzen/pykwalify might be a starting point | 15:21 |
| franred_ | pedroalvarez, umm, 2.6 GB sorry | 15:21 |
| Kinnison | there's also http://rx.codesimply.com/ | 15:22 |
| Kinnison | I think rx is what I used before | 15:22 |
| persia | Note that at high latencies from the DC, this may differ, as at high latencies, tcp windows open rather wide, so a large transfer is *much* faster than several small ones. | 15:22 |
| persia | jjardon: I know that bitbake cannot have any sort of validation tool because it uses a turing-complete language as the means of describing the builds. | 15:22 |
| persia | I don't know if Yocto is considering other build tools. | 15:22 |
| persia | Note that there do exist parsers to validate that bitbake recipies are syntactically correct: it's just the semantics which cannot be validated (as the developer has a very wide range of modification mechanisms from which to choose) | 15:22 |
| persia | Kinnison: pykwalify looks exciting to me: the idea of using YAML to write the specification for the definitions YAML has a nice smell. Rx looks cool, but we run into the issue "How does one validate the format of the specification". | 15:25 |
| Kinnison | I think pykwalify may not have been as usable back when I looked first, but yes it looks quite good now | 15:27 |
| *** ssam2_ has quit IRC | 15:41 | |
| *** edcragg has quit IRC | 15:54 | |
| *** ssam2 has joined #baserock | 15:55 | |
| *** ChanServ sets mode: +v ssam2 | 15:55 | |
| *** edcragg has joined #baserock | 15:56 | |
| *** a1exhughe5 has quit IRC | 15:58 | |
| *** mariaderidder has quit IRC | 16:01 | |
| jjardon | Do we want GLib in its own stratum or can we move it to core? Its a "library required for the Foundation stratum", so maybe it fits there? | 16:06 |
| persia | I'm a fan of putting things as low in the stack as possible, assuming there are no systems that do not need them. | 16:06 |
| rdale | i wouldn't have thought glib would be used in a server only system | 16:07 |
| persia | Is there anything that uses core and/or foundation that does not need glib? | 16:07 |
| jjardon | systemd currently depends on glib, so I do not think so | 16:08 |
| jjardon | minimal systems doesnt use systemd, but they do not have core neither | 16:09 |
| persia | Then core sounds sensible to me. | 16:11 |
| rdale | i don't think a gui lib should be in core | 16:12 |
| persia | rdale: The tricky bit is that to reuse a component, we have to provide everything it needs at build-time. We could build two different components from the same source (with different build-deps and ./configure input) to reduce the total bindings size for some systems, but it's double the maintenance, so only worth it if the benefit is very large. | 16:12 |
| ssam2 | rdale: I agree. Glib doesn't provide any kind of gui | 16:12 |
| rjek | glib isn't a gui lib | 16:12 |
| rdale | it's only needed by a gui lib | 16:13 |
| rjek | It's a data structure library and yet another typedef for char. | 16:13 |
| persia | rdale: You'd rather maintain two different systemd artifacfts? | 16:13 |
| jjardon | rdale: sorry, thats not true | 16:13 |
| *** Albert_ has quit IRC | 16:14 | |
| rjek | rdale: ldd $(which pkg-config) | 16:23 |
| rdale | rjek: what does that tell me? | 16:24 |
| rjek | It tells you that pkg-config depends on glib, and pkg-config has nothing to do with GUIs | 16:24 |
| jjardon | GLib is more similar to STL or boost for C | 16:25 |
| rdale | ok, fair enough. my pkg-config 0.28 in kunbutu 14.10 depends on glib, but pkg-config 0.28 in baserock doesn't | 16:27 |
| rjek | It's just a type library, it has no GUI functionality whatsoever. | 16:27 |
| persia | I suspect that pkg-config in Baserock is missing some functionality that it would gain did it have glib headers available at compile-time. | 16:27 |
| jjardon | thats because pkg-config embed a partial copy of GLib in its sources | 16:27 |
| rdale | ok, then i think you're right and glib/pkg-config should be in the core then | 16:28 |
| rjek | It's probably that Debian ban embedded copies of libraries, and removing them and having them use the system copy is a requirement for the package to be uploaded, and then Ubuntu take Debian's package | 16:28 |
| rjek | (Were Baserock uses raw upstream) | 16:28 |
| jjardon | great, that would save quite a lot of work :) | 16:29 |
| persia | I suspect that we ought demonstrate how to avoid embedded source in one of our reference systems, for people who care about security maintenance, etc. | 16:29 |
| rjek | persia: have lorry fetch Debian source patches and apply them? >:) | 16:30 |
| * rjek wonders how many copies of zlib there are in a Baserock dev system. | 16:30 | |
| rjek | (Debian were shipping hundreds at one point) | 16:31 |
| rjek | Which is not fun when you get a zlib security update. | 16:31 |
| persia | We'd need a more advanced build environment construction mechanism, to get the patch to be applied into the build environment. | 16:31 |
| rjek | persia: That sounds like something useful and nice to have anyway | 16:32 |
| persia | But other than that, lorrying the packaging from debian, and using that, seems like a low-effort way to do that sort of thing. | 16:32 |
| persia | rjek: Very much so, indeed. | 16:32 |
| *** zoli__ has quit IRC | 16:33 | |
| persia | But I think the current recommendation is to just create a new branch of the project with the patch applied. | 16:33 |
| * persia isn't quite sure of the best workflow: having it in git is really nice, but avoiding manual rebases is also nice, plus rebasing branches in a curated git repo makes kittens cry. | 16:34 | |
| jjardon | we build zlib in build-essential, so if the autotools configuration of the rest of the chunks are correct, they should pick up the system installed zlib: if not lets fix it when we have time (or file a bug in our storyboard) | 16:37 |
| persia | There exists a vast quantity of software with embedded zlib sources that does not support using system zlib. Lots of it even depends on versions of zlib with call semantics different than modern zlib. | 16:38 |
| rjek | jjardon: Nobody's autotools configuration is correct. | 16:39 |
| rjek | Also, what persia said | 16:39 |
| persia | This is an unfortunate thing, but provides an excellent target for demonstrating how to reduce the security exposure of embedded sources using the Baserock tooling. | 16:39 |
| tiagogomes_ | rjek +1 | 16:39 |
| * Kinnison remembers doing the work to allow cherokee to use non-embedded zlib | 16:39 | |
| Kinnison | that was "fun" | 16:39 |
| *** zoli__ has joined #baserock | 16:46 | |
| jjardon | ssam2: FYI: I have a couple of patches here to make cross-* systems be of a sane size again, will submit when I finish building | 16:47 |
| ssam2 | awesome, thanks | 16:47 |
| *** tiagogomes_ has quit IRC | 16:49 | |
| *** zoli__ has quit IRC | 16:59 | |
| *** bashrc_ has quit IRC | 17:02 | |
| *** edcragg has quit IRC | 17:17 | |
| *** zoli__ has joined #baserock | 17:20 | |
| *** mauricemoss_ has left #baserock | 17:23 | |
| *** zoli__ has quit IRC | 17:24 | |
| *** jonathanmaw has quit IRC | 17:28 | |
| paulsherwood | Kinnison: thanks for the patches. what do you mean 'no cleverness though' - do you have specific things in mind? | 17:38 |
| paulsherwood | also, what was the upshot on the erlang problem... is it a bug? | 17:42 |
| ssam2 | could anyone do a quick review of https://gerrit.baserock.org/#/c/431/ ? | 17:56 |
| ssam2 | i've tested it and it can't break anything for you unless you use a Calxeda server :) | 17:56 |
| ssam2 | or even if you do | 17:56 |
| Kinnison | paulsherwood: it can't select which subsystems to deploy, it can't do sub-system deployments, it can't alter the deployment parameters from the cmdline, it can't deploy other-architecture stuff | 17:58 |
| Kinnison | paulsherwood: re:erlang -- ybd is sensitive to filesystem ordering and there are duplicate names causing issues | 17:58 |
| *** zoli__ has joined #baserock | 17:59 | |
| *** gary_perkins has quit IRC | 18:03 | |
| *** ssam2 has quit IRC | 18:07 | |
| * paulsherwood +2s ssam2's patch and merges it | 18:08 | |
| *** ssam2 has joined #baserock | 18:09 | |
| *** ChanServ sets mode: +v ssam2 | 18:09 | |
| *** lachlanmackenzie has quit IRC | 18:10 | |
| *** ssam2 has quit IRC | 18:22 | |
| *** zoli__ has quit IRC | 19:11 | |
| *** zoli__ has joined #baserock | 19:34 | |
| *** zoli__ has joined #baserock | 19:54 | |
| *** zoli__ has joined #baserock | 19:56 | |
| *** edcragg has joined #baserock | 21:00 | |
| *** zoli__ has quit IRC | 22:14 | |
| *** zoli__ has joined #baserock | 22:14 | |
| *** edcragg has quit IRC | 22:30 | |
| *** zoli__ has joined #baserock | 23:15 | |
| *** zoli__ has quit IRC | 23:21 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!