| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 02:14 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 02:14 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 02:14 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 02:15 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 02:29 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 02:29 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 02:29 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 02:29 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 02:30 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 02:30 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer] | 02:36 | |
| *** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 02:36 | |
| *** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Remote host closed the connection] | 03:04 | |
| petefoth | http://gfxmonk.net/2015/01/03/nixos-and-stateless-deployment.html is an interesting view on something (nix and NixOS), that tries to solve many of the same problems as Baserock | 08:05 |
|---|---|---|
| *** petefoth_ [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:13 | |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 08:14 | |
| petefoth_ is now known as petefoth | 08:14 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 08:15 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:37 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 08:44 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:56 | |
| * Kinnison remembers nix from the days of writing slinux | 09:05 | |
| paulsherwood | iirc someone from nixos approached lars after his original baserock-related keynote at FOSDEM | 09:06 |
| paulsherwood | (to say nixos already did what he was describing) | 09:07 |
| *** franred [~franred@213.37.90.178.dyn.user.ono.com] has joined #baserock | 09:07 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 09:07 | |
| Kinnison | nixos is somewhat different, but has related approaches in some cases (or at least it did back when I last examined it) | 09:07 |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:15 | |
| franred | good morning, yesterday I sent a patch to lorry some XStatic-* packages. I said in a previous email that I wouldn't [like to] do it because it is against baserock foundations. I though I could go with them from their github repos but 2 of them are in mercurial not in git, if we don't want to lorry them, do we have a test/clone trove to lorry these 2 repos so we don't lorry these XStatic packages and just use them until we can replace th | 09:16 |
| franred | em. NOTE: Using them will cut the development time to integrate Horizon in Baserock | 09:16 |
| paulsherwood | franred: +2 for lorrying them | 09:22 |
| paulsherwood | i can reply on list if you like | 09:22 |
| *** mike [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:23 | |
| franred | paulsherwood, not need it, I will go with this +2, cheers :) | 09:23 |
| mike is now known as Guest56137 | 09:24 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:29 | |
| Kinnison | franred: please ensure the thread on-list is updated with the merge state though | 09:37 |
| * Kinnison tracks whether threads are dealt with in that way | 09:37 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:40 | |
| Mode #baserock +v ssam2 by ChanServ | 09:40 | |
| straycat | nixos abstracts all configuration where baserock doesn't and the implementations are pretty different, Baserock doesn't create the fhs by symlinking from some central store | 09:41 |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:42 | |
| franred | Kinnison, I've sent the mail to confirm the patch has been merged | 09:43 |
| Kinnison | franred: awesomesauce :-) | 09:45 |
| Kinnison | straycat: aye, those are some of the fundamental differences :-) | 09:46 |
| Kinnison | straycat: that nixos remains "packages" is another :-) | 09:46 |
| straycat | yeah I didn't realise that you can just nix-env -i foo or something to install new stuff on your system, I guess that explains why it's still pretty useable on desktops | 09:48 |
| Kinnison | Mmm, tinycore linux is similar IIRC | 09:50 |
| persia | Installing new software on a system in baserock isn't that difficult: it just requires a reboot. | 09:56 |
| Kinnison | Currently :-) | 09:57 |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:12 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:13 | |
| pedroalvarez | Hi guys, I'm looking at the migration of git.baserock.org to the Datacentred tenancy. I wanted to start the migration by copying the contents of /home to a volume there, so later we can upload to Datacentred the git.baserock.org disk and attach the volume. Sounds ok to you? Note: I think that to start copying the contents of /home we don't have to stop g.b.o. , only stopy its lorry controller. | 10:37 |
| persia | What happens if people push? | 10:38 |
| pedroalvarez | hm... | 10:38 |
| pedroalvarez | my thougths were to save the cpu that lorry controller is using, but yeah, there should be another rsync just before turning the original g.b.o and moving to the new one | 10:39 |
| pedroalvarez | s/turning/turning off/ | 10:39 |
| pedroalvarez | are there others ideas about how should I do this? | 10:40 |
| ssam2 | pedroalvarez: awesome :) | 10:40 |
| persia | And that one probably needs to be guarded so that nobody can push during the transition. | 10:40 |
| ssam2 | I think it's unavoidable to have a 'nobody can push during this time' period while we do the switch over | 10:41 |
| pedroalvarez | yeah, indeed | 10:41 |
| persia | Doing a few rsync passes before the cutover ought significantly reduce that timeframe. | 10:42 |
| ssam2 | doing an initial rsync with the machine live, then a second one later on with pushing disabled, seems to me like a good way of ... yeah | 10:42 |
| persia | How is testgerrit testing going? Is there a chance that we can do both migrations at the same time? | 10:42 |
| ssam2 | persia: I've not had any more time to look at doing a proper Gerrit deployment, sadly | 10:43 |
| DavePage_ | Remember rsync --delete :) | 10:43 |
| ssam2 | I think it'd be better to do the git.baserock.org->DataCentred migration separately to anything involving Gerrit | 10:43 |
| persia | ssam2: No worries. I just tend to look for optimisations if possible :) | 10:43 |
| ssam2 | persia: worth asking :) | 10:43 |
| persia | That's safer. Fewer moving parts. | 10:44 |
| franred | pedroalvarez, ssam2, that plan looks ok to me | 10:44 |
| persia | DavePage_: excellent point! | 10:44 |
| ssam2 | pedroalvarez: if you think you can get the migration done today, perhaps pick a time to do it and announce it now | 10:45 |
| pedroalvarez | --delete means to remove files in the dest that are not in the original? | 10:45 |
| pedroalvarez | ssam2: that depends on the rsync speed, so I don't know yet | 10:46 |
| ssam2 | pedroalvarez: fair enough. but I don't *think* anyone will be angry if you announce downtime and then it doesn't actually happen | 10:47 |
| ssam2 | less angry than if you don't announce it and then it does happen! | 10:47 |
| pedroalvarez | heheh | 10:47 |
| pedroalvarez | true | 10:47 |
| persia | pedroalvarez: That is my understanding of --delete | 10:47 |
| ssam2 | a couple of other thoughts: (1) how are you thinking of disabling push access? (2) and how are you thinking of actually switching the machines? | 10:49 |
| ssam2 | i ask because I don't really know how I'd do those things ;) | 10:49 |
| ssam2 | for (2) I guess the operator of .baserock.org DNS can switch the subdomain. and actually that should update instantly, if I'm not mistaken? maybe I am mistaken. | 10:50 |
| persia | For (1), I'd stop the git server process. I'm not sure how that is accomplished. | 10:50 |
| ssam2 | persia: there are a couple of systemd units to be stopped. I was wondering if there was a nice way of making Git 'read-only' rather than just 'dead', though | 10:51 |
| pedroalvarez | yeah, for 1 stop the git daemon, that means "downtime" since you cannot push or pull | 10:51 |
| persia | For (2), using netcat (or similar) for port-forwarding would be wise. Distribution of DNS globally can take three times the max acceptable age in the SOA record. | 10:51 |
| pedroalvarez | hm.. | 10:51 |
| persia | Refreshing my memory, the normal propagation estimate should be 3*refresh, but may be as long as expiry. | 10:52 |
| ssam2 | persia: how would you use netcat to forward the ports to the new machine? I thought netcat could only output to a file, not a TCP socket ... | 10:52 |
| ssam2 | oh, I guess on the old git.baserock.org machine we run `nc -l 127.0.0.1 -p 23 | nc $NEW_IP 23` | 10:53 |
| persia | e.g. 'netcat -L google.fr:80 -p 25000 -vvv' | 10:53 |
| ssam2 | this isn't helped by the fact that there are at least 3 implementations of Netcat :( | 10:54 |
| persia | Heh, true. | 10:54 |
| persia | You could also do it with ssh, if you like. | 10:54 |
| persia | Depends what tools are present on g.b.o | 10:54 |
| ssam2 | we have Busybox `nc`, and `ssh` | 10:54 |
| pedroalvarez | I asked the operator of baserock.org DNS to change the cache times of the git.baserock.org DNS so the DNS propagation of the new server happens fast | 10:54 |
| persia | Then ssh is the tool of choice. | 10:54 |
| persia | e.g. `nohup ssh -N -L80:1.2.3.4:80 &` | 10:56 |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 11:19 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:33 | |
| pedroalvarez | ANNOUNCEMENT: Lorry controller will be off in git.baserock.org for some hours today to speed up the git.baserock.org migration. This migration is expected to conlcude at 18:30 today, and it means that there will be a 30 minutes of g.b.o downtime (18:00 to 18:30) | 11:36 |
| *** petefoth_ [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:46 | |
| tiagogomes | why the native-bootstrap script installs the files to DEST dir which is different than /, and then copies the files to / | 11:47 |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 256 seconds] | 11:48 | |
| petefoth_ is now known as petefoth | 11:48 | |
| pedroalvarez | I think my announcement of downtime was too optimistic | 11:52 |
| ssam2 | tiagogomes: no idea, sorry ... | 11:53 |
| perryl | does baserock currently have more than one version of python running? | 12:04 |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 12:05 | |
| pedroalvarez | perryl: there was a patch to add python 3, but I think it hasn't been merged yet | 12:05 |
| perryl | no worries, i'm trying to run pkg_resources.get_provider to get the location of an installed package, but it isn't working, a bit of digging mentions that multiple versions of python can cause it to fail | 12:06 |
| perryl | pedroalvarez ^^ | 12:06 |
| ssam2 | perryl: ouch. what error do you get from it? or does it just not return the package? | 12:08 |
| perryl | ssam2: NameError: name 'pkg_resources' is not defined | 12:08 |
| ssam2 | ah, you need to 'import pkg_resources' first | 12:09 |
| * perryl quickly checks resources should have a 'u' in it | 12:09 | |
| perryl | ahh darn it :) i'd missed an import | 12:09 |
| perryl | thanks ssam, works fine now | 12:10 |
| pedroalvarez | so, assuming that I have already a copy of the g.b.o disk running (with everything except /home), and /home mounted and sync'ed, could I just do the switching? I think I will need to sync other things as well (like /var?) but I'm not sure if this is needed. Should I literally turn of g.b.o, and not turn it on until is moved to datacentred? (that means that in the downtime I have to copy the image and upload it to DC) | 12:14 |
| franred | pedroalvarez, is everything synchronized? I've just push to g.b.o | 12:15 |
| franred | *pushed | 12:15 |
| pedroalvarez | franred: no no, don't worry. I'm just trying to figure out all what is needed to be done | 12:16 |
| franred | ah, ok :) | 12:20 |
| ssam2 | pedroalvarez: I don't think there should be any valuable state in /var | 12:23 |
| ssam2 | we'd lose some journal entries from the old system | 12:23 |
| ssam2 | 'I don't think there should be any valuable state in /var' is a pretty inaccurate statement. What I mean is, there should be no valuable NEW state since you first copied the disk | 12:24 |
| ssam2 | I don't know of any daemons that use it for persistent state, and there aren't any humans using that machine | 12:25 |
| pedroalvarez | in this case the migration will be easier | 12:26 |
| persia | There is really nothing in /var/run? | 12:27 |
| ssam2 | I'm assuming pedroalvarez will restart all the daemons on the new system | 12:31 |
| pedroalvarez | some .sock, .sockets-* .pid and .lock files | 12:31 |
| pedroalvarez | My idea is to copy the disk when the machine is off. | 12:31 |
| Zara_ | I'm confused-- using ssam2's definitions branch as a base, I changed the nodejs stratum and nodejs.morph file, and I pushed my changes to the nodejs stratum to a repo on my github account. I tried git-format-patch so I could send a patch to the mailing list, and I got some files that said 'from Sam', containing his changes from earlier, as well as another file containing my changes. I couldn't find emails containing the 'from Sam' patch | 12:46 |
| Zara_ | sorry that's so long! | 12:47 |
| DavePage_ | Zara_: Was there anthinhg after 'from Sam' patch? | 12:47 |
| DavePage_ | If so then it truncated; try splitlong.pl in irssi :) | 12:48 |
| Zara_ | bah | 12:48 |
| Zara_ | es but I don't want to send stuff twice over, and I'm not | 12:48 |
| Zara_ | sure what to do/if this is normal. | 12:48 |
| Zara_ | 12:47 < Zara_> sorry that's so long! | 12:48 |
| Zara_ | hopefully that's the rest | 12:48 |
| *** fay [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 12:49 | |
| fay is now known as Guest29194 | 12:49 | |
| straycat | Zara_, I would just send your branches but state in the cover letter the branch your branch is based off | 12:50 |
| straycat | s/branches/patches/ | 12:50 |
| ssam2 | Zara: when you do `git format-patch` you specify the branch you want to merge *to* | 13:02 |
| ssam2 | normally you specify 'master' | 13:02 |
| ssam2 | but if you specify 'sam/nodejs' instead then you'll get patches for everything in your branch that *isn't* in sam/nodejs | 13:02 |
| ssam2 | which I guess is what you want | 13:02 |
| Zara_ | ah, okay, so then you'd merge your branch to master later? | 13:04 |
| Zara_ | yay, that worked, thanks! :> | 13:09 |
| *** Guest29194 [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 13:32 | |
| dabukalam_ is now known as dabukalam | 13:33 | |
| *** Guest29194 [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:47 | |
| *** Guest29194 [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 14:00 | |
| *** Guest56137 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 14:04 | |
| *** Guest56137 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:19 | |
| *** Guest29194 [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:26 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 14:46 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:46 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 15:03 | |
| Zara_ | There's now a skeletal tutorial up on the baserock wiki for importing npm packages. Eagle-eyed observers may be amazed at the similarity to the rubygems tutorial. | 15:38 |
| paulsherwood | link? video? | 15:39 |
| Zara_ | it's not as tidy as I'd like, and it's missing an example walkthrough, but I think it's better than nothing for now http://wiki.baserock.org/guides/import-tool-npm/ | 15:40 |
| pedroalvarez | Zara_: given that is the same tool, I'd expect it to be pretty similar to the rubygems one | 15:41 |
| pedroalvarez | :) | 15:41 |
| Zara_ | heh, I thought I might as well make a page for it, because importing rubygems seems more complicated and it's not worth going through the whole rubygems tutorial if only a fraction of it is relevant for your npm-importing needs :P | 15:43 |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:43 | |
| Zara_ | There's some duplication of content, but since the page is short, I thought a user who just wanted npm packages would prefer to have all the info on one page. Plus the earlier steps should become redundant as the import tool gets merged to master. | 15:47 |
| tiagogomes | is there any documentation on artifact splitting | 16:03 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 16:06 | |
| Guest29194 is now known as fay_ | 16:08 | |
| ssam2 | tiagogomes: not much, sorry | 16:15 |
| richard_maw | tiagogomes: what do you need to do with artifact splitting? | 16:21 |
| richard_maw | there's a handful of examples in definitions.git, the products rules in strata/build-essential/glibc.morph show how to make a chunk provide more artifacts in the "products" field | 16:24 |
| richard_maw | the "products" field in strata/build-essential.morph says how to define a new stratum split by matching against chunk artifact names | 16:25 |
| richard_maw | the glibc entry in the file has an artifacts field which specifies explicit assignment of chunk artifacts produced by glibc to stratum artifacts produced by build-essential | 16:25 |
| tiagogomes | richard_maw I was just curious | 16:26 |
| richard_maw | systems/minimal-system-x86_64-generic.morph shows how you can list specific artifacts to include, so you can make a smaller system | 16:26 |
| pedroalvarez | ANNOUNCEMENT: Lorry controller is still down to speed up the migration of git.baserock.org. There will be some g.b.o downtime starting at 18:00 (UK time) to create a copy of the g.b.o disk. Sadly, the migration won't be competed today. | 17:07 |
| DavePage_ | pedroalvarez: You know, you could shut down the VM, snapshot the LVM partition on the host, restart the VM and then copy the snapshot - that would reduce downtime? | 17:16 |
| * pedroalvarez googles about LVM snapshots | 17:18 | |
| pedroalvarez | I was goint to `cp` the .img file | 17:18 |
| DavePage_ | Yeah, you can mount the snapshot as a read-only filesystem and cp the image file from that | 17:18 |
| tiagogomes | If I updated the gcc-tarbal lorry to point to a new location, how that would work? It would remove the old repo and create a new one? What happens to the build-essential branch? | 17:24 |
| persia | Unless there is upstream continuity of history, the practice has been to give lorries of different locations different names. | 17:27 |
| richard_maw | tiagogomes: it won't remove and re-create the repo, it will include all the old branches, but it may not be what you want to do | 17:28 |
| pedroalvarez | this practice will be scary for all those repos where we are using a tag for ref | 17:29 |
| tiagogomes | searching trough the git history, gcc-tarball was updated with a new URL | 17:29 |
| tiagogomes | richard_maw ah, so it is safe to update the tarball location to point to a new gcc, as we will be using the build-essential branch | 17:30 |
| persia | pedroalvarez: Isn't the use of tags restricted to the unused unpetrify-ref? | 17:31 |
| persia | tiagogomes: If you are updating the location just to add a new version, it is an entirely safe operation. | 17:31 |
| pedroalvarez | assuming that this new version is also a tarball import and not the git repo | 17:32 |
| persia | Right. If we want the git repo, we should use a new name. | 17:32 |
| tiagogomes | I know, my patched used a different name | 17:33 |
| tiagogomes | I am still benchmarking cloning from the git repo | 17:33 |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:35 | |
| straycat | Would it not be better to tweak ci so that system artifacts don't get uploaded to the cache? They can be constructed quicker than they can be downloaded. | 17:36 |
| pedroalvarez | currently the system artifacts are not being uploaded anywhere, cache.baserock.org is the shared cache that the distbuild networks of the CI need to work. | 17:39 |
| straycat | radiofree, Think I just observed the bug you thought you might have had a while back, if the stratum name differs from the stratum morph filename then it doesn't get built, morph gives no warning. | 17:39 |
| straycat | so there are system artifacts on cache.baserock.org | 17:40 |
| persia | pedroalvarez: Hrm? Don't the systems artifacts get cached (just not the deployment artifacts)? | 17:40 |
| *** franred [~franred@213.37.90.178.dyn.user.ono.com] has quit [Quit: Leaving] | 17:40 | |
| radiofree | straycat: yeah that was really annoying! | 17:41 |
| radiofree | Why is there a name field anyway? | 17:41 |
| * straycat wanted to get rid of the name field | 17:41 | |
| straycat | it serves no purpose anymore | 17:41 |
| richard_maw | it's either that, or make morph load every definition file it can find, and have a global namespace of morphologies by "name" field | 17:41 |
| richard_maw | I'm leaning towards preferring that these days, over file names, since it means we don't need to fix up file paths everywhere when we move things | 17:42 |
| paulsherwood | +1 | 17:42 |
| radiofree | why can't it just be the filename? | 17:42 |
| radiofree | build-depends: [] is another annoyance for me as well | 17:43 |
| richard_maw | radiofree: because we also allow multiple artifacts to be produced by morphologies defined in one file | 17:43 |
| richard_maw | it's not a 1 to 1 relationship | 17:43 |
| richard_maw | which we'd require for filenames to be sufficient | 17:43 |
| pedroalvarez | persia: chunk, stratum, and system artifacts get cached, but this happens without needed to upload them to anywhere. They are being created in cache.baserock.org at the same that the CI is running. | 17:44 |
| radiofree | why can't you just fill in "name" from the filename then? | 17:44 |
| richard_maw | radiofree: we can make `build-depends: []` optional | 17:44 |
| richard_maw | radiofree: because it requires magic to go from the filename to the name. We've done it in the past, but the result was that it required a lot of work to change the code so we could put files in subdirectories, rather than every definition file in the top-level directory of the repository | 17:45 |
| persia | pedroalvarez: Ah, right. It was the "upload" that confused me. | 17:45 |
| * paulsherwood sighs | 17:46 | |
| * richard_maw gets on with some work | 17:46 | |
| * paulsherwood too :-) | 17:46 | |
| radiofree | richard_maw: i can't quite understand why "name: foo" is fine and parsing foo.morph into "foo" isn't? | 17:46 |
| radiofree | the magic is just remove the .morph bit? | 17:46 |
| Zara_ | hm, Krin, did you find you got different error messages from those listed in the rubygems import tutorial? (I'm trying to work if I've unwittingly left some noise around from last time, or if the tool has changed since I last used it.) | 17:47 |
| Zara_ | *work out | 17:47 |
| paulsherwood | radiofree: do you mean filename.ext, or relpath/filename.ext? | 17:48 |
| richard_maw | radiofree: because it's actually some/sub/directories/foo.morph, so it would have to strip the directory off it and it requires we end our definition files with .morph | 17:48 |
| radiofree | well if it's strata/blah/blob/foo/bar.morph the "name" is still just "bar" | 17:48 |
| radiofree | richard_maw: that's pretty easy though? | 17:48 |
| paulsherwood | radiofree: yes. so name: bar is the best thing? | 17:48 |
| Krin | yes Zara_ i got some strange error messages, the tutorial should specify that the errors may not be the same as the one pressented if i recall? | 17:48 |
| richard_maw | radiofree: we have at various times considered alternative suffixes, such as .{chunk,stratum,system}, or .def | 17:48 |
| Krin | or i may be losing my mind a little more | 17:48 |
| Zara_ | Krin: when I first attempted the tutorial, I got the same error messages, so that suggests the tool has changed | 17:49 |
| Zara_ | or we're both losing our minds :P | 17:49 |
| radiofree | paulsherwood: yes, but that's easy enough to get from the full path | 17:49 |
| Krin | YAY! lost minds :) | 17:49 |
| paulsherwood | yes. but why require user to fill in full path? | 17:49 |
| richard_maw | radiofree: 17:45 < richard_maw> radiofree: because it's actually… and it requires we end our definition files with .morph | 17:49 |
| radiofree | paulsherwood: i'm not | 17:49 |
| * straycat was but doesn't mind either way | 17:50 | |
| radiofree | i'm saying there's no difference between having "name: bar" in the morph file, or just parsing name from strata/blah/blob/foo/bar.morph (bar) | 17:50 |
| radiofree | so you didn't have to put name in it | 17:50 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:50 | |
| straycat | There is a difference, though, where you have two files names bar.morph in the workspace | 17:50 |
| richard_maw | straycat: indeed, there is ambiguity as to which you meant | 17:51 |
| radiofree | you can call things something other than morph? | 17:51 |
| straycat | radiofree, strata/foo/bar.morph strata/baz/bar.morph | 17:52 |
| radiofree | straycat: i thought that issue has gone away now though? | 17:52 |
| radiofree | strata/bsp-foo/u-boot.morph strata/bsp-bar/u-boot.morph isn't an issue anymore? | 17:52 |
| radiofree | it's u-boot@foo and u-boot@bar | 17:52 |
| richard_maw | radiofree: alas, no, we've ended up with something half-way between purely (path, artifact name) based, and globally named, due to being pulled in different directions. The workspace tooling requires unique names(yes, we want to get rid of workspace tooling, I'm aware of this), but the build logic requires (path, artifact name). | 17:52 |
| radiofree | i see | 17:54 |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 17:59 | |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 17:59 | |
| pedroalvarez | ANNOUNCEMENT: git.baserock.org will go down soon (few seconds/minutes) | 17:59 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:02 | |
| straycat | Since we don't have this figured out yet, adding a warning to morph is probably for the best. | 18:02 |
| tiagogomes | hmm, why the ref for gcc is different from the ref for stage1-gcc and stage2-gcc | 18:04 |
| richard_maw | AIUI it's because stage1 and stage2 didn't need changing to be able to build the new version of gcc | 18:06 |
| richard_maw | so changing them would just be extra work for everyone involved | 18:06 |
| pedroalvarez | ANNOUNCEMENT: git.baserock.org is up and running again | 18:07 |
| straycat | cool | 18:07 |
| persia | Except that there is something nice about using the same gcc for everything, to reduce user confusion. | 18:07 |
| persia | pedroalvarez: That was lots less than the forecast 30 minutes. Nice work! | 18:07 |
| pedroalvarez | persia: and I've done lot less that I was expecting to do :( the migration is not done yet | 18:08 |
| persia | Oh :( | 18:08 |
| tiagogomes | richard_maw, but doesn't that mean that the newer version of gcc was built by an old version of gcc? What guarantees that the newer version of gcc can build the newer version of gcc? | 18:14 |
| tiagogomes | It couldn't happen that deploying image X, and using image X to build again image X could fail | 18:16 |
| ssam2 | it could happen | 18:17 |
| ssam2 | there's no way to prove that it can't happen, other than testing | 18:17 |
| ssam2 | gcc 4.7 could have a bug whereby it generated a gcc 4.7 that generated bad code, for example | 18:17 |
| ssam2 | so you're right that this is a possible problem, but I don't think that using gcc 4.6 to build gcc 4.7 has anything to do with it | 18:18 |
| persia | It is probably best practice to update each stage once the later one is working. | 18:18 |
| tiagogomes | but we used gcc 4.7 in stage2 to build gcc 4.7 we could detect this problem before deploying the image | 18:20 |
| persia | That only detects if gcc can build gcc, not if it can build the entire system | 18:20 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 18:21 | |
| tiagogomes | whether it can build the entire system will be verified when the remaining chunks are built | 18:22 |
| persia | Ah, right. | 18:27 |
| *** Guest56137 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:54 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 19:17 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer] | 20:01 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 20:05 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 20:05 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 20:05 | |
| *** petefoth_ [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 21:19 | |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 21:20 | |
| petefoth_ is now known as petefoth | 21:20 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!