| radiofree | Ben has been hardware hacking it | 01:48 |
|---|---|---|
| radiofree | But he's not here | 01:48 |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 04:43 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 04:43 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 04:43 | |
| *** jmacs_ [~jimmacart@access.ducie-dc1.codethink.co.uk] has joined #baserock | 06:12 | |
| *** paulsher1ood [~paulsherw@access.ducie-dc1.codethink.co.uk] has joined #baserock | 06:13 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 06:16 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 06:56 | |
| *** mike [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:38 | |
| mike is now known as Guest76934 | 07:38 | |
| cosm | robtaylor: yep, I've emailed him because he's the author of the git commit containing the default BCT for jetson | 08:14 |
| cosm | but apparently someone else wrote the actual config | 08:14 |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:16 | |
| dutch is now known as wdutch | 08:16 | |
| persia | cosm: For hardware-type issues, you might also find #tegra useful | 08:18 |
| *** perryl [~lauren@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:36 | |
| cosm | thanks persia, I'll give it a try | 08:56 |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:00 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:13 | |
| Mode #baserock +v ssam2 by ChanServ | 09:13 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:20 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 09:22 | |
| petefoth | Are there differences between a ‘configuration extension’, a “deployment extension’ and a ‘write extension. Is so, can somone spare the time - maybe FTF - to explain them to me? | 09:47 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:47 | |
| straycat | The write extension, is the bit of code that performs the deployment, so if you're deploying over kvm for example, the kvm write extension handles that. | 09:49 |
| straycat | Config exts are scripts that configure a system, they take a rootfs and perform some modification on it, e.g. appending some entry to /etc/network/interfaces | 09:51 |
| petefoth | straycat: Thanks | 09:52 |
| petefoth | Is there such a thing as a ‘deployment’ extension, or is that just a term which covers both write and config extensions? | 09:53 |
| straycat | I don't know what a deployment extension is, I guess someone might have been referring to a conf ext or a write ext | 09:54 |
| petefoth | straycat: thanks again | 09:57 |
| ssam2 | I sometimes use the term deployment extension to cover both write and config extensions | 09:57 |
| ssam2 | I don't know if I like that term, but I tend to make up new terms by accident when talking to people | 09:58 |
| petefoth | ssam2: thanks. I think I have enough information now to have sensible text in the glossary | 10:01 |
| *** Guest76934 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 10:02 | |
| * richard_maw uses deployment extension to refer to both configure and write extensions | 10:04 | |
| petefoth | So does http://ur1.ca/ioqwm seem OK? | 10:10 |
| straycat | Seems okay to me | 10:12 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:12 | |
| Krin | morning all | 10:13 |
| *** Guest76934 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:16 | |
| Krin | does anyone know if there is a way of telling morph to not clean up certain files/folders after it is done building a system, as zookeeper actually uses the files after installation and 'make install' only does half the job due to cosmic rays being beamed onto the heads of whoever made it? | 10:17 |
| Kinnison | No, unless you install the files into $DESTDIR during the chunk build, they will not end up in the target system | 10:17 |
| Krin | would that mean simply moving them to $DESTDIR then? if i move them to $DESTDIR can i build inside $DESTDIR? as moving the folder seems to break things too which means they probebly have some relative path refferances in there ¬.¬ | 10:18 |
| Kinnison | $DESTDIR will not be in the same place in the target system anyway | 10:19 |
| Kinnison | I'd suggest looking at how Debian does it | 10:19 |
| Kinnison | since they have a similar set of constraints | 10:19 |
| franred | Krin, Kinnison, why not copy the required files in the system and use them later? I did something similar when one repo need another inside to get compiled | 10:20 |
| * Krin <sarcasm>is feeling all the love and unity for mankind today</sarcasm>, hopes he does not offend anyone who does not deserve it. | 10:21 | |
| Krin | how do you mean franred? you mean move them into the system after build? during build? | 10:21 |
| franred | umm Kinnison told you before me... I need to drink more coffee | 10:22 |
| franred | <Kinnison> No, unless you install the files into $DESTDIR during the chunk build, they will not end up in the target system | 10:22 |
| Krin | this calls for reading and experimentation~! | 10:23 |
| richard_maw | petefoth: I'd say s/VM file/VM disk image/, but other than that, it looks fine to me | 10:23 |
| Krin | and caffeine | 10:23 |
| petefoth | richard_maw: ta! | 10:23 |
| persia | Doesn't install-commands: provide a place to put scripting to move any magic bits at build time? | 10:24 |
| rjek | ISTR some work to automatically create Baserock chunks from ruby gems. Am I making that up? has anybody done anything similar with pip? | 10:24 |
| richard_maw | rjek: ripsum is working on it | 10:25 |
| richard_maw | straycat may be able to tell you more | 10:25 |
| straycat | rjek, ssam2 has done some stuff with that | 10:25 |
| persia | rjek: There was some work like that discuss ed on the mailing list. I don't remember the final consensus, sadly. | 10:25 |
| rjek | OK, I'll look it up there. | 10:25 |
| rjek | Thanks! | 10:25 |
| persia | Try September, IIRC | 10:26 |
| straycat | More specifically we're working on an import tool for rubygems, pip and others | 10:26 |
| ssam2 | rjek: for rubygems, it's usable although not yet integrated or documented | 10:26 |
| franred | Krin, Kinnison, something like: http://fpaste.org/147670/50967871/ where rabbitmq-codegen is needed to compile rabbitmq-server | 10:26 |
| persia | straycat: A generic tool for all the platform-specific systems? | 10:26 |
| ssam2 | rjek: please come chat to me if you want to integrate some rubygems, more testing would be great ! | 10:26 |
| Kinnison | franred: either you or I am missing a point on this, so let's let Krin investigate for himself :-) | 10:26 |
| rjek | ssam2: I want to integrate some pip things, I was just wondering if I was making the rubygems thing up because it sounds similar! | 10:27 |
| straycat | persia, One tool for importing packages from different packaging systems into Baserock yes | 10:27 |
| franred | Kinnison, ok :) | 10:27 |
| Krin | Kinnison, franred: ... my brain hurts already | 10:27 |
| ssam2 | Richard Ipsum is doing some work for PIP, but it's at an earlier stage than the RubyGems integration | 10:27 |
| persia | straycat: Do be careful. I remember the work in packagekit, and that was only trying to define common semantics for distro packages. There's more divergent semantics in platform-specific packaging systems. | 10:27 |
| persia | (but I'd be delighted if this problem can be reasonably solved) | 10:28 |
| jmacs_ | For PIP, are you allowing PIP to run on baserock systems, or importing the data from PIP into baserock definitions? | 10:28 |
| richard_maw | the latter | 10:28 |
| richard_maw | I believe we can already do the former | 10:28 |
| * richard_maw has previously done so | 10:28 | |
| ssam2 | the tool as it exists is here: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/import.git/tree/ | 10:28 |
| jmacs_ | OK, thanks | 10:28 |
| persia | jmacs_: Be warned that as soon as you run pip on a system, your system becomes a snowflake. Nice for prototyping, but not so nice for maintainability. | 10:30 |
| jmacs_ | Not my choice of tool. | 10:30 |
| straycat | persia, *nod* What we have at the moment amounts to a best effort to generate lorry files from package names, then finding dependency information for the package and generating definitions from that. | 10:30 |
| persia | Cool. Just do remember that "depends upon" doesn't always have a consistent meaning. | 10:31 |
| Kinnison | Krin: have a look at http://ftp.uk.debian.org/debian/pool/main/z/zookeeper/zookeeper_3.3.5%2bdfsg1-2.debian.tar.gz | 10:33 |
| Krin | thanks Kinnison | 10:33 |
| jmacs_ is now known as jmacs | 10:33 | |
| straycat | persia, The way ssam2's designed it, each packaging system provides extensions to map a package name to a lorry file, and map a package name to a set of build dependencies and a set of runtime dependencies, that seems to work for the packaging systems we're interested in. | 10:35 |
| petefoth | persia: I think I understand what you mean by the word ‘snowflake’ in this context - something with a unique structre, hard - if not impossible - to reproduce. Is that roughly correct? (I copuldn’t find a useful definition with DDG or google) | 10:39 |
| persia | petefoth: Yes. | 10:40 |
| petefoth | persia: tvm | 10:41 |
| persia | straycat: Ah, so it's just an abstraction that doesn't provide semantic guarantees, leaving these to be platform-dependent? That's probably sensible, as users of a given platform can assume their platform semantics. | 10:41 |
| * straycat nods | 10:50 | |
| Krin | these guys are GENIUSES! simple elegant solution making GENIUSES! *looking at the debian rules in Kinnison's link* and i think most of this can be done easily in baserock too happy Krin is happy now | 10:51 |
| Kinnison | :-) | 10:51 |
| * petefoth likes to see a happy Krin! | 10:51 | |
| Krin | but i'm not a genius, i forgot to bring my breakfast with me ¬.¬ | 10:51 |
| Krin | BISCUITS! | 10:52 |
| Kinnison | doh | 10:52 |
| jmacs | baked doh | 10:53 |
| Kinnison | play doh | 10:53 |
| rjek | forbidden dohnut | 10:54 |
| * Kinnison is out of tea :-( | 10:54 | |
| petefoth | Can anyone give me a short (one or two lines) definition for ‘staging area’? I coulkd write one myself and ask people to check it but I think this way may be quicker) | 11:01 |
| paulsher1ood | petefoth: http://en.wikipedia.org/wiki/Staging_area | 11:02 |
| paulsher1ood | in baserock context it is an a location where software is assembled prior to release/publication/deployment | 11:03 |
| petefoth | paulsher1ood: ta! Didn’t think to look there as I assumed we had a mpre specific usage. | 11:03 |
| petefoth | would it normally be on the development system or on the idstbuild controller or…? | 11:04 |
| richard_maw | development system for local builds, worker nodes in distbuild | 11:05 |
| petefoth | richard_maw: thanks | 11:05 |
| *** madhu [~madhu@202.0.77.198] has quit [Remote host closed the connection] | 11:06 | |
| abdul | ssam2: even updated the build-system as cpan in xml-parser morph file. build is getting failure | 11:10 |
| ssam2 | abdul: could you paste the error output somewhere for me to see? | 11:12 |
| franred | if we specify build-system: autotools, and add configure commands ./autogen.sh --foo --blah ... does the chunk expect to add ./configure or it does by default? | 11:29 |
| ssam2 | franred: you can't 'add' configure-commands | 11:30 |
| ssam2 | you override the default configure-commands | 11:30 |
| ssam2 | you can set pre-configure-commands or post-configure-commands, though | 11:30 |
| Kinnison | If you're changing how autogen.sh is called, you should override configure-commands | 11:31 |
| straycat | ssam2, Can we change the import tool so that the chunk morph stage is optional? Morph has instructions for handling python packages built in. | 11:32 |
| ssam2 | makes sense, but it might break some assumptions I made in the code | 11:34 |
| ssam2 | might be best to always create one for now, and rework the code to be less dumb later on | 11:34 |
| * straycat nods | 11:34 | |
| straycat | Okay | 11:34 |
| abdul | ssam2: http://fpaste.org/147691/14151009/ | 11:35 |
| ssam2 | it seems completely impossible to configure a trove with a proxy.conf :( | 11:36 |
| straycat | I don't know much about gems, what stops us adding a buildsystem for gems as we have done for python packages? | 11:36 |
| ssam2 | straycat: it's not impossible, but a bit of a pain | 11:36 |
| ssam2 | the build commands need to include the name of the Gem | 11:37 |
| * franred will spend some time reading morph/README sounds like a nice place to know these magic tricks which people around me do | 11:37 | |
| richard_maw | abdul: that's weird | 11:37 |
| * richard_maw will see if there's something obviouly wrong with the Makefile | 11:38 | |
| ssam2 | abdul: I think this must be a timestamps issue | 11:38 |
| ssam2 | however, Morph tries to reset all timestamps before running a build | 11:38 |
| ssam2 | maybe the timestamps are getting messed up by NFS somehow | 11:39 |
| Kinnison | If your staging area is being constructed over NFS, it could do all sorts of bad things (tm) to timestamps | 11:39 |
| Kinnison | esp. *during* the build itself | 11:39 |
| ssam2 | OK. I knew NFS wasn't ideal, but I believe it's only way that Abdul can get an ARM build going on his target hardware | 11:41 |
| Kinnison | You *really* want to ensure clock-sync between the NFS server and the ARM board then | 11:42 |
| Kinnison | if you get good clock-sync you should be safer | 11:42 |
| ssam2 | ah, that's a good point | 11:42 |
| Kinnison | the issue is that some timestamps come from the client and some from the server and NFS's metadata is, in part, eventual-consistency | 11:42 |
| straycat | ssam2, Oh so we'd just need to pass the chunk name to BuildSystem | 11:42 |
| ssam2 | straycat: be careful with use of the word 'just' ;) but yeah, that's the main blocker | 11:43 |
| richard_maw | ssam2: also, that assumes you're always able to have your chunks have the same name as the gem presumably | 11:43 |
| ssam2 | richard_maw: yes it does | 11:44 |
| ssam2 | there may be other solutions | 11:44 |
| straycat | parameterise the build system, so that in the case of rubygems buildsystem you also specify the gem name | 11:45 |
| richard_maw | Kinnison, abdul: It's definitely the timestamps which are the issue. There's a rule in the generated Makefile that will re-generate the Makefile if the Makefile.PL is newer. | 11:45 |
| * Kinnison nods | 11:46 | |
| * Kinnison leapt in when he heard NFS, but didn't have the background | 11:46 | |
| Krin | hmm, could someone explain $DESTDIR and $PREFIX to me? what do these end up being?what path would they be equivilant to in the resulting build? or have i got completely the wrong idea? | 11:50 |
| richard_maw | PREFIX comes from the stratum, defaulting to /usr | 11:50 |
| Kinnison | Basically $PREFIX is the filesystem basis for the installed and *running* code | 11:50 |
| Kinnison | as richard_maw says, it's typically /usr | 11:51 |
| Kinnison | DESTDIR is where morph wants you to pretend will be '/' on the installed system | 11:51 |
| Kinnison | and will typically be CHUNKNAME.inst | 11:51 |
| richard_maw | this is traditionally used in builds because /usr is vendor installed software, /usr/local is locally installed, and "$HOME/.local" is per-user installed | 11:51 |
| Kinnison | sorry, /CHUNKNAME.inst | 11:51 |
| richard_maw | everything put in DESTDIR gets cached, so it can be used to satisfy build-time and run-time dependencies | 11:51 |
| richard_maw | it gets unpacked into the staging tree before commands get run in it | 11:52 |
| Kinnison | so if the chunk builds a program called 'foo', and you told it PREFIX=/usr and DESTDIR=/foo.inst, when you 'make install' you'll get /foo.inst/usr/bin/foo and in the final system that'll be /usr/bin/foo | 11:52 |
| Krin | so $DESTDIR$PREFIX will essentialy lead to /usr but if that is not the default it will lead to the vendor installed software location? | 11:52 |
| Krin | or should i use $DESTDIR for things that will be cleaned up later and $PREFIX for things that ned to remain? | 11:53 |
| Kinnison | Not quite | 11:53 |
| Kinnison | anything you put into $DESTDIR will end up in the chunk and thus in further builds or the system itself | 11:54 |
| Kinnison | $PREFIX is the path that the stratum is asking your chunk to put its content inside | 11:54 |
| *** cosm [~Unknown@us2x.mullvad.net] has quit [Ping timeout: 245 seconds] | 11:54 | |
| richard_maw | you pass $PREFIX to any configure scripts, so it knows where it files will end up on the final system. you use `make DESTDIR="$DESTDIR" install` to make it put the files there, and if you need to install any software manually, you need to copy it into "$DESTDIR$PREFIX" | 11:54 |
| Kinnison | so anything in $DESTDIR$PREFIX will end up in the right place on the target system | 11:54 |
| Kinnison | PREFIX might get baked into the build, DESTDIR is purely about staging the results so morph can pick them up right | 11:55 |
| Kinnison | https://www.gnu.org/prep/standards/html_node/DESTDIR.html might explain DESTDIR | 11:55 |
| Krin | i... think.. i think i understadn *goes to read* | 11:56 |
| Kinnison | I can whiteboard it for you if you're still unsure :-) | 11:56 |
| Kinnison | It's a pain, but once you 'get' it, you'll be much more comfortable | 11:56 |
| richard_maw | some other build systems refer to it as the "install prefix" | 11:56 |
| * richard_maw likes the commend on that page | 11:57 | |
| richard_maw | "You should not set the value of DESTDIR in your Makefile at all; then the files are installed into their expected locations by default. Also, specifying DESTDIR should not change the operation of the software in any way, so its value should not be included in any file contents. " | 11:57 |
| * richard_maw has seen SO MANY build systems fail to do this properly | 11:57 | |
| franred | ssam2, http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/README is very useful, thanks | 11:58 |
| richard_maw | People put `DESTDIR = ` in their Makefiles as they think they need to define the variable first | 11:59 |
| richard_maw | DESTDIR is often picked up by the environment, but if you put `DESTDIR =` in, it will be overridden with nothing, so the build fails | 11:59 |
| richard_maw | which is why we do `make DESTDIR="$DESTDIR" install` | 11:59 |
| richard_maw | since variables defined on the make command line override definitions in the Makefile | 12:00 |
| radiofree | can we upgrade systemd and let it take charge of the network stuff? | 12:12 |
| Kinnison | we are working toward that I believe | 12:12 |
| radiofree | for some reason (dodgy wires?) my board here seems to boot before the link is ready | 12:12 |
| radiofree | which means a manual udhcpc, over serial... which isn't great | 12:13 |
| Kinnison | radiofree: I think jjardon was working toward newer systemd, so you could ask him | 12:14 |
| radiofree | Kinnison: thanks | 12:14 |
| radiofree | replace wires aswell? | 12:14 |
| Kinnison | you could try, but it's more likely to be the PHY or MAC at the other end being slow | 12:15 |
| radiofree | the link is coming up *after* the kernel dhcp for some reason | 12:15 |
| Kinnison | boggle | 12:15 |
| Kinnison | Hang on, kernel DHCP? | 12:15 |
| Kinnison | Are you doing ip=dhcp in the kernel and then expecting udhcpcd to work? | 12:15 |
| radiofree | no no | 12:16 |
| Kinnison | phew | 12:16 |
| * radiofree might be an idiot, but he's not that much of an idiot | 12:17 | |
| radiofree | is it possible to pass environment variables to a chunk? | 12:28 |
| ssam2 | radiofree: not without changing Morph | 12:32 |
| ssam2 | what do you need to do ? | 12:32 |
| *** madhu [~madhu@202.0.77.198] has joined #baserock | 12:33 | |
| radiofree | ssam2: i want to pass environment variables to a chunk | 12:34 |
| *** cosm [~Unknown@cspc154.cs.man.ac.uk] has joined #baserock | 12:34 | |
| radiofree | is it possible to do in the build/configure commands? | 12:34 |
| radiofree | FOO=bar&&./configure? | 12:34 |
| radiofree | that'll be ok right? | 12:34 |
| * radiofree tries it | 12:35 | |
| radiofree | FOO=bar ./configure is thumbs up! | 12:35 |
| ssam2 | radiofree: oh, that's fine | 12:36 |
| radiofree | is there any global way of setting FOO though? | 12:36 |
| ssam2 | no, chunks are built with a clean environment | 12:36 |
| radiofree | e.g i have several chunks where FOO is important, i want them all to take a global FOO | 12:36 |
| ssam2 | see the recent thread on baserock-dev about templating | 12:36 |
| ssam2 | I think everyone agrees that they want this, but there's debate about how it should be done | 12:36 |
| radiofree | ok, thanks | 12:37 |
| ssam2 | 'Conditionals and branching in definitions' is the thread | 12:37 |
| radiofree | yeah i want it but the "how it should be done" bit is way beyond me | 12:37 |
| ssam2 | setting env vars. is one option, but they need to be included in the cache identity of the build artifact | 12:38 |
| abdul | ssam2: is there anyway to solve this issue | 12:38 |
| ssam2 | abdul: check that the clocks on the NFS server and the build machine are in sync | 12:38 |
| ssam2 | ideally get 'ntp' running on both of them | 12:39 |
| radiofree | would writing the last time you got from ntpd to a file, so you could load that if the network is down, be desirable, or just a massive hack? | 12:42 |
| straycat | If the network is down how do you know your current time is accurate? | 12:44 |
| persia | You compare it to the feed from your USB atomic clock. Lacking one of those, you can estimate drift over time based on historical ntpd data. Lacking that, you don't. | 12:45 |
| ssam2 | abdul: beware that NTP uses some random port, it's not HTTP traffic, so you might not be able to talk to NTP servers outside your firewall | 12:45 |
| straycat | persia, I assumed a lack of both atomic clock and historical data | 12:45 |
| radiofree | straycat: you don't, but i'd be happier being 1,2,3 hours out rather than 44 years | 12:46 |
| persia | radiofree: There are some hacks to deal with the 44 year problem, typically used for boards that do not have batteries for their clocks, and/or lack actual hardware clocks. If you haven't booted before, set the clock to the atime of the kernel you booted, and if you have, add an offset based on the last entry in the dmesg ring. I was told it was a kernel command-line option, but that might have involved a patched kernel. | 12:48 |
| radiofree | that seems like a decent enough hack :) | 12:49 |
| persia | It can lead to poor results if one forgets, and builds a kernel with an atime matching the epoch :) Another trick I remember being used was the last mount data of specific filesystems, but I think that ended up being dropped because it doesn't work for read-only filesystems so well... | 12:51 |
| jjardon | I have systemd v217 working here, but we need the coreutils patches first | 13:04 |
| jjardon | radiofree: ^ | 13:04 |
| paulsher1ood | any idea how i could do 'su - postgres' on a machine with that user setup, and yet still be root afterwards? | 13:23 |
| paulsher1ood | maybe i'm misunderstanding how 'su' works. 'su postgres' => postgres, 'su - postgres' => root | 13:24 |
| richard_maw | ooh, new patches on the mailing list! | 13:27 |
| richard_maw | SotK: I don't recall why the GitDirectory had to search upwards for actual git directories, ssam2 thinks it's no longer needed, so I'd appreciate it if you could chime in on that one. | 13:28 |
| * SotK tries to remember why | 13:29 | |
| richard_maw | I think it was about the time of the git-fat work | 13:29 |
| abdul | ssam2: After syncing both nfs server and build machine, xml-parser package is built successfully | 13:30 |
| richard_maw | \o/ | 13:30 |
| Kinnison | abdul: excellent | 13:30 |
| paulsher1ood | w00t! :) | 13:30 |
| paulsher1ood | this needs to be on the build errors page if it's not already? | 13:31 |
| SotK | richard_maw: yup | 13:31 |
| madhu | abdul, cool | 13:32 |
| madhu | abdul, now we may not require external disk | 13:32 |
| *** jjardon84 [~jjardon@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:41 | |
| richard_maw | pedroalvarez: wow, glibc is taking a while to clone | 13:46 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 13:53 | |
| petefoth | I’ve pushed an updated version of the Glossary, and would welcome comments or - even better - others adding to, correcting, or otherwise improving it | 13:54 |
| petefoth | http://wiki.baserock.org/glossary/ | 13:54 |
| * Kinnison takes a break from his thinking to have a read | 13:55 | |
| richard_maw | petefoth: we probably don't need to go into so much detail about how the cache key is calculated in the glossary | 13:56 |
| Kinnison | cache key is a little confusing. we calculate it beforehand not by looking at the built outputs | 13:56 |
| petefoth | richard_maw: good point - that was a cpy and pasa - I’ll trim it down | 13:56 |
| Kinnison | the first paragraph is possibly superfluous entirely | 13:57 |
| jjardon | pedroalvarez: building a weston system here with your glibc patches, I will let you know | 13:57 |
| persia | The distinction between configuration extensions and write extensions can be useful: maybe "Deployment Extension" should reference those, rather than the other way about? | 13:57 |
| persia | Deployment fails to mention staged deployment: things like deploying to a master ISO, or deploying to glance, etc. | 13:57 |
| Kinnison | petefoth: the cache server also provides access to querying the git repositories without having to clone them | 13:58 |
| persia | "Trebuchet" is a fancy name, but it isn't backed by a specific tool. There is some trebuchet-derived stuff that gets used, but II'm uncertain about this definition (although it is better than the old one). | 13:58 |
| persia | Kinnison: Isn't that a side effect of the cache server happening to be colocated with the git server? | 13:59 |
| Kinnison | petefoth: In Chunk/Chunk-artifact it'd be better to say that a chunk is, in general, built from one git repository. | 13:59 |
| robtaylor | persia: well, there's tb-diff | 13:59 |
| persia | It probably also makes sense to talk about artifact splitting somewhere. | 13:59 |
| Kinnison | persia: Well, without it being so, morph will have a harder time of things. Of course, morph allows you to specify a cache server which is next to the git repos, and a separate one which has artifacts | 13:59 |
| richard_maw | petefoth: deploy is missing the second ` around the `morph deploy` | 13:59 |
| persia | robtaylor: Yes, but the diff bits don't do what they say on the tin (or didn't last time I looked, which was admittedly months ago). | 14:00 |
| * petefoth though he had run out of stuff to do. He was wrong :) | 14:00 | |
| robtaylor | probably true.. | 14:00 |
| petefoth | Please keep the comments coming! | 14:00 |
| persia | Kinnison: Right. The morph defaults assume that, but I don't think we want to reinforce it conceptually. | 14:00 |
| Kinnison | petefoth: in deploy,deployment you have a missing ` closing off `morph deploy | 14:00 |
| persia | petefoth: Also, thanks a lot for trying to sort this out. | 14:00 |
| Kinnison | persia: then we should have 'artifact cache server' and 'git cache server' as separate glossary entries | 14:01 |
| persia | Yes, we should. | 14:01 |
| * Kinnison concurs that we should have the write extension and configuration extension explanations separated, and then have deployment extension reference the two | 14:01 | |
| persia | Although I admit I have difficulty imagining a git cache server distinct from a local curated mirror. | 14:01 |
| Kinnison | petefoth: since we added build systems, the devel system contains the tools *typically used* in developing on Baserock | 14:02 |
| Kinnison | persia: a git mirror service can't directly answer morph's questions, hence we wrote a service to do it for us | 14:02 |
| Kinnison | petefoth: in development systems you have _definitions- instead of _definitions_ | 14:04 |
| * richard_maw enjoys the comment "Blame the ancient Romans" | 14:05 | |
| * richard_maw objects to the comparison of chunks to strata as lego to duplo | 14:06 | |
| richard_maw | duplo is not made out of lego | 14:06 |
| * richard_maw thinks the following analogy is better | 14:07 | |
| Kinnison | petefoth: in the `morph` section I'd also have a statement that "Also 'a morph' often refers to a morphology file. See definitions" | 14:07 |
| petefoth | richard_maw I refuse to take the blam for that - another copy / pasta from ane earlier document | 14:07 |
| richard_maw | :-( | 14:07 |
| richard_maw | s/(/)/ | 14:07 |
| jmacs | richard_maw: duplo-compatible bricks can be made out of lego | 14:07 |
| Kinnison | jmacs: really? I thought the pips were incompatibly sized | 14:07 |
| persia | Kinnison: Thanks for the explanation. So there is a bit that needs to sit above the git server to make a git cache server? What is the use case for running that separately from the artifact cache server? (I'm not opposed, just curious) | 14:08 |
| jmacs | Kinnison: Not in all directions, clearly. I'm pretty sure you can put duplo on lego though. | 14:08 |
| Kinnison | persia: the use case for separation is fr.ex. mason where you don't necessarily want all the artifacts making their way to the shared artifact cache server until a build succeeds | 14:09 |
| richard_maw | clearly we need a trip to the Lego shop to settle this issue! | 14:09 |
| Zara | maybe there's a lego conference coming up? | 14:09 |
| Kinnison | persia: also distbuild workers use the artifact cache server code to share artifacts back to their shared cache for the build | 14:09 |
| Kinnison | petefoth: also, if you say 'Lego bricks' like a good brit, saying 'Duplos' is just vile. | 14:09 |
| Kinnison | petefoth: workspace has `morph uses` where I think you mean `morph` uses | 14:12 |
| * Kinnison can do a more careful review later if you want, once you've made the current fixups you have queued | 14:13 | |
| petefoth | Kinnison: tvm - I’ll let you know when it’s ready | 14:13 |
| richard_maw | pedroalvarez: wow, still cloning glibc | 14:15 |
| ssam2 | I've added 'Building on NFS' to http://wiki.baserock.org/guides/build-failures/?updated#index7h2 | 14:22 |
| Krin | hmm, on a baserock system, is there a reason i would be refused access to my local host when i use 'echo ruok | nc localhost 2181' | 14:27 |
| Kinnison | ssam2: looks good | 14:27 |
| Krin | it is running on a VM if that makes a diference | 14:27 |
| Kinnison | Krin: does the VM listen on 2181 ? | 14:27 |
| Krin | i'm unsure and unsure how to tell | 14:27 |
| richard_maw | localhost != 127.0.0.1 | 14:28 |
| Kinnison | Why do you think 2181 would be listening at all? | 14:28 |
| richard_maw | unfortunately | 14:28 |
| Krin | because that is the default port for zookeeper Kinnison | 14:28 |
| Krin | ah, i looked on the ifconfig and it gave that address richard_maw | 14:28 |
| Kinnison | Krin: erm, is zookeeper running in the VM? | 14:29 |
| richard_maw | there's a bug in our /etc/nsswitch.conf that allows localhost to be resolved by dns | 14:29 |
| Krin | how do i discover what the local loopback for a VM is? | 14:29 |
| pedroalvarez | richard_maw: has it finished? I can't remember how long it took to me the first time :/ | 14:29 |
| Kinnison | Krin: loopback for any system is 127.0.0.1 | 14:29 |
| Kinnison | Krin: or ::1 in IPv6ish | 14:29 |
| pedroalvarez | jjardon: thanks for testing weston! :) | 14:29 |
| richard_maw | pedroalvarez: still cloning | 14:29 |
| ssam2 | in future, if you run `morph --verbose` you'll see the progress output from Git :) | 14:29 |
| richard_maw | if I also remember to update my version of morph | 14:30 |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Remote host closed the connection] | 14:31 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 14:34 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 14:34 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 14:34 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 14:34 | |
| richard_maw | pedroalvarez: took nearly an hour (52 minutes) to clone glibc | 14:45 |
| pedroalvarez | :/ | 14:45 |
| ssam2 | how big is the repo ? | 14:46 |
| pedroalvarez | ssam2: and how long took to you? | 14:46 |
| ssam2 | not sure, didn't seem very long | 14:46 |
| ssam2 | I use a mismash of different troves on different machines right now though | 14:46 |
| richard_maw | pedroalvarez: 113.3M | 14:46 |
| radiofree | jjardon: ? | 14:48 |
| *** perryl [~lauren@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 14:49 | |
| ssam2 | pedroalvarez: I'm willing to believe that the problem on ARM is the bottom of http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/build-essential/stage2-eglibc.morph | 14:49 |
| pedroalvarez | is exactly what your email suggested me | 14:50 |
| pedroalvarez | that can be an easy fix | 14:50 |
| radiofree | pedroalvarez: did you test your patches on arm? i can start a build now if you haven't/want | 14:51 |
| *** perryl [~lauren@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:51 | |
| radiofree | (glibc patches) | 14:51 |
| ssam2 | radiofree: I tried on a Jetson distbuild network already and it didn't work for me | 14:52 |
| radiofree | :\ | 14:52 |
| pedroalvarez | and I have just tried an armv7lhf cross-bootstrap and it has failed | 14:53 |
| pedroalvarez | and stage2-glibc fails in this way: http://pastebin.com/thWpkM8D | 14:54 |
| richard_maw | without more information from config.log you can't really say what's gone wrong, but that error usually means that the cross-compiler is broken | 14:55 |
| pedroalvarez | looking at config.log, looks like that. Trying to paste the log somewhere | 14:56 |
| pedroalvarez | here it is: http://sprunge.us/hbjA | 14:57 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 15:00 | |
| richard_maw | hm, not much new information there | 15:01 |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 15:01 | |
| richard_maw | just that the cross-compiler is non-functional | 15:02 |
| pedroalvarez | just tested with definitions master, and the same error happens | 15:10 |
| pedroalvarez | so that failure is not related with my glibc change | 15:10 |
| pedroalvarez | richard_maw: | 15:21 |
| pedroalvarez | 2014-11-04 15:21:11 [Build 4/147] [stage2-glibc] Cloning upstream:glibc | 15:21 |
| pedroalvarez | 2014-11-04 15:22:07 [Build 4/147] [stage2-glibc] Creating staging area | 15:21 |
| richard_maw | there's a few things which could cause issue: 1. I'm using macvtap to bridge my VM onto my wired ethernet output, 2. the connection between my laptop and git.baserock.org may be further than you | 15:23 |
| *** madhu [~madhu@202.0.77.198] has quit [Quit: Leaving] | 15:24 | |
| pedroalvarez | 3. git.baserock.org was slow when you cloned it | 15:24 |
| petefoth | II’ve pushed some updates to the glossary. I believe I have adressed (if not necessarily resolved) all of the issues raised in this channel earlier. | 15:26 |
| petefoth | Kinnison: if you have time to give it another going over, that would be grand, but I’m going now. | 15:27 |
| Kinnison | petefoth: I'll try and go over it before I leave tonight | 15:27 |
| Kinnison | petefoth: I'll email you my comments if you're off | 15:27 |
| petefoth | Kinnison: ta! | 15:28 |
| franred | richard_maw, looks like in the latest version of libvirt-gest.sh they remove the bash commands or at least remove the for ((blah)) sintax, I may try to update libvirt to the latest stable tag | 15:43 |
| franred | s/latest/last/ | 15:43 |
| *** cosm [~Unknown@cspc154.cs.man.ac.uk] has quit [Ping timeout: 250 seconds] | 15:51 | |
| jjardon | is it possible in baserock to have some patches locally and apply them before build a chunk? | 16:14 |
| straycat | you could morph edit then git apply? | 16:15 |
| straycat | ssam2, http://sprunge.us/DNcM :/ | 16:15 |
| jjardon | straycat: I mean permanently, instead having a branch in the git repo | 16:16 |
| straycat | jjardon, Oh, then, no I don't think so | 16:17 |
| richard_maw | you could in-line the patch content in pre-configure-commands | 16:17 |
| richard_maw | though I think we're better maintaining a proper delta for important things | 16:17 |
| *** cosm [~Unknown@cspc154.cs.man.ac.uk] has joined #baserock | 16:18 | |
| Kinnison | I'd rather see a branch in the repo unless that's going to cause a lot of issues | 16:18 |
| Kinnison | they're way easier for an observer to grok | 16:18 |
| ssam2 | straycat: how 20th century | 16:18 |
| jjardon | yeah, I was thinking in little patches like change the .gitmodules file | 16:18 |
| richard_maw | straycat: you've made me angry at pip | 16:18 |
| straycat | erm | 16:19 |
| straycat | ... | 16:19 |
| richard_maw | jjardon: can't do that there, since the .gitmodules are parsed before any build commands | 16:19 |
| straycat | richard_maw, there there | 16:19 |
| ssam2 | jjardon: there may be a better solution for submodules than manually patching .gitmodules | 16:19 |
| radiofree | how much work would be required to make morph automatically adjust submodule repos? | 16:20 |
| ssam2 | I agree that it sucks having to make a branch just to change that | 16:20 |
| jjardon | ssam2: any idea already? :) | 16:20 |
| radiofree | so we can just point at master rather than needing a patch to "adjust submodule location" | 16:20 |
| ssam2 | jjardon: my head is too full of other stuff right now to think about it :( | 16:20 |
| richard_maw | my current thinking for that is to drop parsing of .gitmodules, allow people to specify multiple source repositories, and require people use that to handle submodules | 16:22 |
| Kinnison | wouldn't that run the risk of not keeping SHAs matching? | 16:23 |
| richard_maw | yeah, but you could have it inspect the .gitmodules to check whether it matches before the build | 16:24 |
| straycat | So yeah we'll need to write something that keeps track of the constraints and raises an error if there's conflicting dependencies | 16:24 |
| straycat | richard_maw, Actually I'm pretty irritated by this too :) | 16:25 |
| Kinnison | richard_maw: I'd rather have a module => repo mapping in the stratum, and apply that to the .gitmodules before resolving them at build time | 16:26 |
| richard_maw | but then you get all the way towards build time before knowing that you need to cache another repository | 16:27 |
| Kinnison | or at least update the cache, true | 16:27 |
| Kinnison | unless you, at that point, use the git cache to resolve the modules for SHAs | 16:28 |
| Kinnison | we could add a method to the git cache server to resolve submodule SHAs and return them | 16:28 |
| richard_maw | we want to be able to fall back when there isn't a cache server though, so we'd end up having to clone those repositories and poke at them, at which point we're back to the status quo | 16:38 |
| pedroalvarez | digging in the problem of arm + glibc I found this error: http://pastebin.com/qYmHwC4 | 16:40 |
| richard_maw | This paste has been removed! What an error indeed! | 16:41 |
| pedroalvarez | no! :/ | 16:41 |
| * pedroalvarez opens the paste from a different browser and sees a lot of ads... | 16:42 | |
| pedroalvarez | I should change to another one | 16:42 |
| * pedroalvarez tries again | 16:43 | |
| pedroalvarez | http://fpaste.org/147811/14151193/ | 16:43 |
| ssam2 | wow, that looks excellent. | 16:44 |
| pedroalvarez | :) | 16:44 |
| Kinnison | pedroalvarez: bleurgh :-( | 16:46 |
| pedroalvarez | as a side note, I think cross-bootstrap is broken | 16:46 |
| persia | Specifically, or generically? | 16:48 |
| ssam2 | pedroalvarez: I found https://sourceware.org/bugzilla/show_bug.cgi?id=16452 | 16:50 |
| ssam2 | it might help a little | 16:50 |
| Kinnison | pedroalvarez: Yeah, a little more help on what makes you say it's broken would be good :-) | 16:50 |
| pedroalvarez | persia: not sure yet, since I've used it few weeks ago when doing the armv6 port, and it worked. but today it didn't | 16:50 |
| persia | I don't really understand the details (even after having looked at the strata a couple times), but is there any way we can share more between the bootstrap path and the cross-bootstrap path? | 16:51 |
| persia | I had the impression before that cross-bootstrap had a tendency to bitrot due to lack of exercise. | 16:52 |
| pedroalvarez | Kinnison, persia: I tried today cross-bootstrap and stage1-gcc failed | 16:52 |
| Kinnison | pedroalvarez: so this is constructing the tarball? | 16:53 |
| Kinnison | pedroalvarez: i.e. before you get to running natively? | 16:53 |
| pedroalvarez | yes | 16:53 |
| pedroalvarez | natively we only run stage3 | 16:53 |
| Kinnison | bleh | 16:54 |
| persia | Are bootstrap and cross-bootstrap using the same toolchain? | 16:54 |
| Kinnison | they're separate morphologies | 16:54 |
| Kinnison | so unless humans are keeping them in sync, no. | 16:55 |
| persia | That was the source of failure in a previous iteration. | 16:55 |
| pedroalvarez | Kinnison: they use build-essential.morph | 16:55 |
| ssam2 | persia: the normal bootstrap does actually function in a very similar way to the cross-bootstrap | 16:55 |
| persia | WIth the new structure, is there a way to share more between them? | 16:55 |
| persia | ssam2: Yes, but with different repos and refs :) | 16:55 |
| Kinnison | pedroalvarez: oh, cool, I didn't think they did | 16:55 |
| ssam2 | I don't think there's a way to share anything between them without allowing templating/conditionals in chunk morphologies | 16:56 |
| persia | Ah, that again. Oh well. | 16:56 |
| persia | Maybe it is just a matter of watching more carefully on code reviews to keep them in sync for now. | 16:56 |
| richard_maw | nah, we only split them to reduce the amount of stuff you needed to build to cross-bootstrap, as you don't need all of a devel system | 16:57 |
| ssam2 | oh, you're right | 16:57 |
| ssam2 | I'm thinking of the cross-toolchain strata we did for the SDK, which is totally separate | 16:57 |
| richard_maw | we ought to be able to go back to sharing if we have finer grained strata, but without runtime-dependencies this is a headache | 16:57 |
| ssam2 | but yes, cross-bootstrap and bootstrap both use the build-essential stratum, so should be pretty much in sync! | 16:57 |
| persia | Does some of the work on the "build" system help with this? | 16:58 |
| ssam2 | I imagine that it should do | 16:58 |
| ssam2 | pedroalvarez: this seems to be the issue breaking x86_32 stage2-gcc: https://gcc.gnu.org/ml/gcc-patches/2012-03/msg01073.html | 17:04 |
| ssam2 | there's a fairly simple patch that we can apply to GCC 4.6.3: http://pastebin.com/VkgE27Pd | 17:04 |
| ssam2 | (i'll try to find an actual commit for that patch) | 17:05 |
| pedroalvarez | ssam2: great! thanks | 17:05 |
| ssam2 | i like that thread also contains a brief mention of doing full rebuilds of a distribution on every commit to GCC | 17:06 |
| persia | A toy distro, or one of the big ones? | 17:07 |
| ssam2 | one commenter in the thread suggest OpenEmbedded, another suggests Gentoo | 17:07 |
| ssam2 | it's only a tiny discussion of the idea | 17:08 |
| persia | First is toy-sized. Second gets complicated :) | 17:08 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 17:21 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 17:35 | |
| *** cosm [~Unknown@cspc154.cs.man.ac.uk] has quit [Ping timeout: 265 seconds] | 17:36 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:48 | |
| *** Guest76934 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:52 | |
| jjardon | instead commiting tarball content to the git repos, maybe its better to lorry the tarball instead?: so you can have m4 and m4-tarball for example | 17:52 |
| Kinnison | jjardon: yes, we could do that | 17:52 |
| richard_maw | I was going to send this is an e-mail, but I wrote up an rfc about stratum runtime dependencies: http://wiki.baserock.org/rfcs/stratum-runtime-depends/ | 17:55 |
| jjardon | ok to lorry gcc? http://fpaste.org/147838/12388414/ | 17:57 |
| * Kinnison wonders why we don't lorry it already | 17:58 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:58 | |
| Kinnison | Is it a particularly uncomfortable repo? | 17:58 |
| radiofree | can we lorry https://git.fedorahosted.org/cgit/fpaste.git ? | 17:58 |
| pedroalvarez | voila: http://85.199.252.87 | 17:59 |
| richard_maw | gcc was _the_ worse repo we found to lorry | 17:59 |
| richard_maw | I eventually got it to clone, but it took a _long_ time | 18:00 |
| Kinnison | richard_maw: worse than gnulib? | 18:00 |
| richard_maw | they never had overlapping timelines so I can't say | 18:00 |
| * Kinnison thinks it looks like gcc might be a little better now | 18:00 | |
| Kinnison | perhaps they cleaned up their history | 18:00 |
| * Kinnison tests | 18:01 | |
| Kinnison | radiofree: why? | 18:01 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:02 | |
| jjardon | pedroalvarez: did not upgrade m4 fix the build issue with newer glibc | 18:03 |
| jjardon | ? | 18:03 |
| Kinnison | jjardon: I'm test cloning it | 18:03 |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Ping timeout: 272 seconds] | 18:03 | |
| jjardon | Kinnison: thanks! | 18:03 |
| pedroalvarez | jjardon: I found problems to do the upgrade, so I only patched it | 18:04 |
| radiofree | pedroalvarez: ok :) | 18:04 |
| radiofree | let's add "haste" instead :) | 18:04 |
| pedroalvarez | uh? | 18:06 |
| radiofree | Kinnison: so i can do cat mylog | fpaste | 18:07 |
| radiofree | from a serial console or something | 18:07 |
| radiofree | but pedroalvarez has linked a baserock pastebin, that looks nicer, there's a "haste" command for that | 18:08 |
| Kinnison | I see | 18:08 |
| Kinnison | I think sprunge.us works with curl or something | 18:08 |
| paulsher1ood | richard_maw: while you're on with the runtime depends stuff, what's to stop us dropping strata altogether, and getting to definition has contents, build-depends, runtime-depends. contents are definitions? | 18:09 |
| pedroalvarez | radiofree: ahh! now I follow you. | 18:10 |
| Kinnison | paulsher1ood: Richard has left for the day, he may pick up on that later or else tomorrow | 18:10 |
| pedroalvarez | radiofree: yeah, we can add the haste client and configure it to default to a public baserock haste server | 18:11 |
| pedroalvarez | radiofree: but I don't know if that's safe for deverlopers with private suff | 18:11 |
| radiofree | that's not your problem though? | 18:12 |
| pedroalvarez | radiofree: you can do this for now: `commands | curl -F 'sprunge=<-' http://sprunge.us` | 18:12 |
| radiofree | if a developer has private stuff i would hope they're not using public fpaste/haste/pastebin instances anyway | 18:12 |
| radiofree | ah, nice! | 18:12 |
| pedroalvarez | I decided to use haste-server because it's nodejs, and I think that it can be done in baserock easily, if we want to move our infra to baserock | 18:13 |
| pedroalvarez | now is running in ubuntu | 18:13 |
| *** cosm [~Unknown@host-78-150-56-250.as13285.net] has joined #baserock | 18:20 | |
| *** cosm_ [~Unknown@us1x.mullvad.net] has joined #baserock | 18:37 | |
| *** cosm [~Unknown@host-78-150-56-250.as13285.net] has quit [Ping timeout: 244 seconds] | 18:41 | |
| cosm_ is now known as cosm | 18:41 | |
| pedroalvarez | with this python client is possible to paste things in our hastebin server | 18:54 |
| pedroalvarez | http://85.199.252.87/hastebin | 18:54 |
| pedroalvarez | sorry: http://85.199.252.87/hastebinit | 18:55 |
| pedroalvarez | radiofree: ^^ | 18:55 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 19:35 | |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 20:04 | |
| paulsher1ood | now that ruby and node are in devel, and we have the build-systems, would anyone object to adding the databases stratum to devel? | 20:19 |
| franred | paulsher1ood, what is the definition of devel-system for you? a) a system which any developer can use for create their applications or b) a system to devel system which you can devel other systems which are going to be your target | 20:29 |
| franred | for b) I can't see the point to add them, for a) yes, they would be needed | 20:29 |
| paulsher1ood | i'm using devel now for creating appliances - hence i created the websystem initially. now the main role of what was devel (ie building baserock systems) is done by build-system, it seems to me adding more developer tools to devel would be ok | 20:33 |
| paulsher1ood | (one problem previously with adding stuff to devel was that it increased the build/deploy/test cycle for validating core baserock itself) | 20:35 |
| paulsher1ood | franred: ^^ | 20:35 |
| paulsher1ood | note i can't reallt define what devel is for me now. but on the other hand, anyone using node or ruby in devel is quite likely to find themselves wanting something from the databases stratum at some point | 20:36 |
| * paulsher1ood would go the whole hog, and add docker too :-) | 20:37 | |
| *** tiagogomes [~tiagogome@host-2-99-200-67.as13285.net] has joined #baserock | 20:38 | |
| franred | then I don't have objections to add databases to devel system - did someone tried to compile a database stratum for an architecture different than x86? | 20:38 |
| paulsher1ood | in effect it seems to me that b) is now solved by build-system, no need for devel. but i may be wrong | 20:39 |
| paulsher1ood | franred: actually that is a good question | 20:39 |
| paulsher1ood | i didn't. but i can | 20:39 |
| pedroalvarez | Afaik, we added ruby and node to the devel system because is needed for the import tool. | 21:21 |
| paulsher1ood | yup. but now they're there, folks like me will want to use them :) | 21:22 |
| pedroalvarez | also libvirt, xfce, gnome, openstack | 21:25 |
| * jjardon just built a GNOME system with latest gnome-shell, xserver and systemd | 21:25 | |
| paulsher1ood | cool :) | 21:25 |
| pedroalvarez | Video! | 21:26 |
| pedroalvarez | Or that never happened! | 21:26 |
| jjardon | gnome-shell still doesnt work, will do when I find out why ;) | 21:26 |
| pedroalvarez | Hehe ok | 21:26 |
| pedroalvarez | paulsher1ood: I was just saying, our tools dont need databases | 21:28 |
| jjardon | mmm, seems the new systemd has a "update" mode when first boot | 21:30 |
| * jjardon will investigate that | 21:30 | |
| *** tiagogomes [~tiagogome@host-2-99-200-67.as13285.net] has quit [Ping timeout: 244 seconds] | 21:31 | |
| paulsher1ood | pedroalvarez: you may be right. but how would you answer franred's question? what is devel-system for, now? | 21:32 |
| pedroalvarez | A system to develop kissing baserock tooling? | 21:37 |
| pedroalvarez | S/kissing/using/ | 21:38 |
| pedroalvarez | I don't want it to be much bigger than how ir is now | 21:41 |
| *** tiagogomes [~tiagogome@host-2-99-200-67.as13285.net] has joined #baserock | 21:43 | |
| paulsher1ood | pedroalvarez: what's to stop you doign that in build-system? | 21:48 |
| pedroalvarez | paulsher1ood: I can't use the import tool in the build system, since it doesn't have ruby and node | 21:51 |
| pedroalvarez | I may be wrong | 21:52 |
| pedroalvarez | I'm considering the import tool part of the baserock tooling | 21:52 |
| paulsher1ood | ah, ok. i've not been following this. is the import tool documented somewhere? | 21:53 |
| *** tiagogomes [~tiagogome@host-2-99-200-67.as13285.net] has quit [Quit: Leaving] | 21:54 | |
| pedroalvarez | I believe it's not documented yet, but we know that it has to be documented an soon | 21:55 |
| paulsher1ood | ok | 22:02 |
| paulsher1ood | in other news, is there any way back if i delete my factory version? | 22:03 |
| paulsher1ood | or rather, any way forward? seems i can no longer deploy updates to self | 22:04 |
| pedroalvarez | I want to fix that bug. But to what system do we have to apply the upgrade? | 22:13 |
| pedroalvarez | I looked into that a week ago and I couldn't find any suspicious in the code | 22:14 |
| paulsher1ood | the current default system i'd say | 22:16 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!