| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 06:32 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 06:41 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 06:42 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 06:45 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 06:45 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 06:45 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 06:46 | |
| *** rdale [~quassel@170.Red-79-145-104.dynamicIP.rima-tde.net] has joined #baserock | 08:16 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 08:20 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 08:20 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 08:20 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 08:20 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 08:37 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 08:38 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:39 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:00 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:03 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:06 | |
| *** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:13 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:20 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:23 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:57 | |
| * pedroalvarez spams the mail list | 10:08 | |
| Kinnison | ruhroh | 10:08 |
|---|---|---|
| pedroalvarez | good morning! | 10:08 |
| Krin | good moaning | 10:09 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:13 | |
| Mode #baserock +v ssam2 by ChanServ | 10:13 | |
| pedroalvarez | btw, I think now I know what is broken in our cross-bootstrap process | 10:16 |
| pedroalvarez | we are generating the same cache key for a chunk when doing a normal build and when doing cross-bootstrap | 10:17 |
| Kinnison | For stage 1 ? | 10:18 |
| pedroalvarez | well, I guess that only stage1 is the problem | 10:18 |
| richard_1aw is now known as richard_maw | 10:18 | |
| pedroalvarez | the thing is that when testing cross-bootstrap, morph was fetching the gcc-stage1, and then morph couldn't use it to build | 10:19 |
| Kinnison | mmm | 10:20 |
| ssam2 | pedroalvarez: oh! that shouldn't happen because we include the environment in the cache key | 10:22 |
| ssam2 | and set TARGET_STAGE1 in the environment to produce the cross compiler | 10:23 |
| Kinnison | Does the environment carry the HOST and the BUILD arch? | 10:23 |
| ssam2 | yes | 10:23 |
| ssam2 | but, maybe that's going wrong somehow | 10:23 |
| Kinnison | Then that's very odd | 10:23 |
| Kinnison | pedroalvarez: if you unpick your gcc-stage1 artifact, and look at the meta, was the environment sane? | 10:23 |
| pedroalvarez | you can do a quick test | 10:23 |
| Kinnison | If so, it might simply have failed to produce a proper x-compiler | 10:23 |
| pedroalvarez | Kinnison: the problem is that morph *downloads* the one in g.b.o from the latest release | 10:24 |
| Kinnison | Oh dear | 10:25 |
| Kinnison | That is most odd | 10:25 |
| pedroalvarez | ` morph cross-bootstrap armv7lhf baserock:baserock/definitions baserock/release/baserock-14.40.1 systems/cross-bootstrap-system-armv7lhf-generic.morph` | 10:26 |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:29 | |
| ssam2 | pedroalvarez: that downloaded a chunk from git.baserock.org, but it looks like the correct chunj | 10:32 |
| ssam2 | chunk | 10:32 |
| ssam2 | contains lots of files under 'tools/lib/gcc/armv7lhf-bootstrap-linux-gnueabi/' | 10:32 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 10:33 | |
| pedroalvarez | ssam2: but you can't use it to build gcc stage 2 | 10:34 |
| pedroalvarez | s/gcc// | 10:34 |
| ssam2 | pedroalvarez: right, seems like it's somehow built for ARM! | 10:35 |
| pedroalvarez | yup, because that artifact is part of the latest release | 10:35 |
| ssam2 | stage1 gcc is used to native-build stage2 gcc on the host, so it should be built for x86 :( | 10:36 |
| ssam2 | hmm ... I wonder if we actually encode the host architecture anywhere in the cache key for chunks ? | 10:36 |
| Kinnison | If it's part of the environment then we must | 10:36 |
| ssam2 | its env contains "TARGET": "armv7lhf-baserock-linux-gnueabi", "TARGET_STAGE1": "armv7lhf-bootstrap-linux-gnueabi", | 10:37 |
| ssam2 | oh, and "MORPH_ARCH": "armv7lhf", | 10:37 |
| Kinnison | But not hint of the BUILD or HOST arch? | 10:38 |
| ssam2 | no | 10:39 |
| Kinnison | Then that's likely the issue | 10:39 |
| ssam2 | yeah, I guess the cross stage1 compiler has the same cache key as a native stage 1 compiler | 10:39 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:41 | |
| pedroalvarez | richard_maw: should I add your explanations in the commit messages? | 10:53 |
| richard_maw | it would be nice, but you'll probably still get a +1 without it | 10:54 |
| richard_maw | I haven't finished reading the thread yet | 10:54 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 11:10 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:10 | |
| jjardon | woot! new glibc patches! nice work pedroalvarez! :) | 11:25 |
| pedroalvarez | jjardon: yup! | 11:26 |
| pedroalvarez | I tested it on x86_64, x86_32, ppc64, and armv7lhf. | 11:26 |
| pedroalvarez | jjardon did you finally tested the previous glibc patches with your work? | 11:27 |
| jjardon | pedroalvarez: no, I stopped when somone give them a -1, but I can test this new ones | 11:28 |
| pedroalvarez | jjardon: note, is going to cause a full rebuild. | 11:29 |
| jjardon | pedroalvarez: yeah. I will test them with new coreutils, systemd, xserver and gnome when they got merged | 11:30 |
| jjardon | I think you already have a +2? | 11:31 |
| Krin | hmm, downloading the baserock-current-delev-system-x86_64-generic, should it come with a baserock_src.img? or do i have to make one manually? and should fallocate create said image or do i just need to touch it in the correct dirrectory? | 11:33 |
| perryl | Krin: afaik baserock_src.img is just a ~30Gb storage image | 11:33 |
| SotK | Krin: you'll need to make it yourself | 11:34 |
| Kinnison | Krin: fallocate it | 11:34 |
| perryl | it is created with fallocate, or vboxmanage createhd depending on what virtual manager you use | 11:34 |
| perryl | s/it is created/you create it/ | 11:34 |
| Krin | i get this result: | 11:34 |
| Krin | mikesmith@Kitsune:~/Downloads$ fallocate -l $((30*1024*1024*1024)) baserock_src.img | 11:35 |
| Krin | fallocate: baserock_src.img: fallocate failed: Operation not supported | 11:35 |
| Krin | is fallocate something that i ned to install? | 11:35 |
| ssam2 | fallocate: I think you can answer that question :) if 'fallocate' is not on your system them you'll need to install it. But looks like it is there. | 11:37 |
| ssam2 | i don't know why it's giving that error. | 11:37 |
| richard_maw | I do | 11:37 |
| mauricemoss_ | Krin: I had the same problem last week. fallocate didn't work for me although it can be used with ext4. the only workaround for me was using truncate (which takes a long time because of writing zeros) | 11:37 |
| richard_maw | fallocate forces the allocation of the disk without writing to it | 11:37 |
| Krin | oo could you enlighten me richard_maw | 11:38 |
| richard_maw | use truncate instead | 11:38 |
| richard_maw | truncate ensures that there's a file of the specified size | 11:38 |
| richard_maw | which is sufficient, as you can have lazily allocated files | 11:38 |
| Krin | is truncate it's own command or a subcommand of fallocate? | 11:38 |
| Kinnison | its own command | 11:38 |
| richard_maw | separate command | 11:38 |
| Kinnison | richard_maw: we recommend fallocate so that you don't get the unpleasant surprise when your VM which has "free space" suddenly can't write anything because the host disk is full | 11:39 |
| richard_maw | so our 3 options are 1. fallocate, which is fast and allocates everything 2. dd which is a complicated command, slow and allocates everything or 3. truncate which is fast but leaves it unallocated | 11:44 |
| Kinnison | yeah | 11:44 |
| Kinnison | But fallocate is somehow failing for krin :-( | 11:45 |
| richard_maw | the backing filesystem needs to support it | 11:45 |
| Kinnison | aah | 11:45 |
| Kinnison | Krin: what FS do you run on? | 11:45 |
| richard_maw | kernel version also has an effect | 11:45 |
| ssam2 | pedroalvarez: thinking about the cross-bootstrap problem, and the fact that merging glibc will cause rebuilds of everything, maybe now is a good time to fix morph to include architecture in cache key calculation | 11:50 |
| ssam2 | i'll cook up a patch | 11:50 |
| pedroalvarez | ssam2: makes sense to me | 11:51 |
| persia | Can it be a complex inclusion, so we can distinguish between native arm-glibc, x86-built arm-glibc, and power-built arm-glibc? | 11:51 |
| Kinnison | persia: done right, it should be MORPH_ARCH for the host, the build, and the target | 11:51 |
| ssam2 | persia: what do you mean by 'complex inclusion' ? | 11:52 |
| ssam2 | target architecture is already set in the environment | 11:53 |
| ssam2 | I was thinking of just including host architecture | 11:53 |
| ssam2 | i don't have time to do a complex patch | 11:53 |
| pedroalvarez | I think that's the only thing we need | 11:54 |
| jjardon | Hi, all my systemd fails to build with this error: "ERROR: System gnome-system has stratum specs that are not mappings." Any idea why? | 11:56 |
| richard_maw | jjardon: let's see your morphology | 11:56 |
| richard_maw | the stratum specs are the entries in the list of strata | 11:57 |
| jjardon | richard_maw: probably is something wrong there, but this happen if I try to build other systems too. Is this intended? | 11:57 |
| richard_maw | we currently load all the morphologies into memory as part of the temporary build branch creation, so if you've got an invalid morphology in your working tree you can't build | 11:58 |
| Krin | i dont know how to know what FS i'm on Kinnison | 11:58 |
| ssam2 | krin: run 'mount' with no args | 11:58 |
| jjardon | mmm, git clean -dfx solved the problem | 11:59 |
| persia | Kinnison: How are you distinguishing "host" and "build"? | 11:59 |
| Kinnison | Well in most things Baserock does, HOST and TARGET are likely to be the same | 11:59 |
| * Kinnison is using the GNUish definitions | 11:59 | |
| jjardon | richard_maw: but only *~ files were removed | 11:59 |
| ssam2 | TARGET only has meaning when building a compiler | 11:59 |
| Krin | Kinnison, /dev/mapper/ubuntu--vg-root on / type ext4 ? so ext4 | 12:00 |
| persia | Ah, yes, we need all of BUILD, HOST, and TARGET | 12:01 |
| * persia had not previously understood the madness of cross-compilation in sufficient depth | 12:01 | |
| Kinnison | ssam2: Or any other code-generaty thing | 12:01 |
| Kinnison | Krin: looks like ext4 yes | 12:02 |
| persia | Err, no, cross-compilation doesn't need that. *canadian-compilation* does, but still, people do that. | 12:02 |
| Kinnison | richard_maw: does ext4 not support fallocate then? :-( | 12:02 |
| richard_maw | not all versions, hence why I also asked about kernel version | 12:02 |
| Kinnison | persia: I have no intention of strongly supporting canadian cross for baserock TARGETs, but it may be necessary since a system you want to build might contain a cross compiler | 12:02 |
| Kinnison | persia: e.g. I'm on x86_64 and I want to build an x86_32 system which contains a compiler targetting ARM uC's | 12:03 |
| persia | Precisely, which should not be considered uncommon given the nature of Baserock and the desire to support build clusters. | 12:03 |
| persia | And we can't rely on the results of a canadian compilation being the same for different BUILD architectures. | 12:04 |
| Krin | and now apparently virt-manager cannot allocate ram... yep it's a monday | 12:04 |
| Kinnison | Oh dear :-( | 12:05 |
| radiofree | jjardon: configure: error: Package requirements (libdrm_freedreno >= 2.4.55) were not met: | 12:58 |
| radiofree | when building mesa, on arm, from master | 12:58 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 13:01 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 13:02 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 13:03 | |
| jjardon | radiofree: thats strange, we are building your drm branch and thats 2.4.56 | 13:03 |
| radiofree | Probably not with freedreno support | 13:04 |
| jjardon | oh, yeah, we have to --enable-freedreno-experimental-api in our drm morphology | 13:06 |
| jjardon | radiofree: are you going to send a patch or should I? | 13:07 |
| jjardon | this should be enough: http://paste.baserock.org/wegenuyuma.sql | 13:13 |
| persia | That seems a sane and tiny patch to me: +1 | 13:18 |
| ssam2 | +1 | 13:19 |
| pedroalvarez | argh! | 13:19 |
| pedroalvarez | I was going to give mine to have my place in the credits | 13:20 |
| pedroalvarez | :) | 13:20 |
| persia | pedroalvarez: Is there a rule that there can only be two? This isn't Highlander | 13:21 |
| pedroalvarez | there isn't actually | 13:22 |
| persia | Well, if you are quick, perhaps you can show support before the merge happens | 13:23 |
| pedroalvarez | jjardon: +1 | 13:23 |
| * jjardon doesnt mind to put as many review-by as possible: more people to blame if something goes wrong ;) | 13:34 | |
| persia | heh | 13:37 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:41 | |
| radiofree | jjardon: you do it! | 13:42 |
| radiofree | oh he has done it | 13:42 |
| paulsher1ood | if we're going to do full rebuilds etc, and change cache-calculation can we also do the genivi updates at this time? | 14:00 |
| paulsher1ood | pedroalvarez: ^^ | 14:00 |
| pedroalvarez | paulsher1ood: to prepare for the genivi release you mean? | 14:01 |
| paulsher1ood | \yes | 14:02 |
| pedroalvarez | I'm not sure about what changes we need to do for this release | 14:02 |
| paulsher1ood | nor am i. i can check | 14:02 |
| pedroalvarez | radiofree: is your baserock/james/unify-jetson-bsp-14.40.1 branch ready for review? | 14:07 |
| radiofree | pedroalvarez: https://www.youtube.com/watch?v=e_Y-keuYWqo | 14:09 |
| radiofree | i'll rebased against master | 14:10 |
| radiofree | though it will need jjardon's mesa/libdrm fix | 14:10 |
| radiofree | (and assuming that works) | 14:10 |
| pedroalvarez | ahh! | 14:10 |
| pedroalvarez | ok | 14:10 |
| pedroalvarez | paulsher1ood: please, let me know if you find anything useful wrt GENIVI | 14:17 |
| * straycat doesn't want to start a bikeshed but... | 14:18 | |
| straycat | when are we going to rename everything | 14:18 |
| straycat | I just wanted to explain some stuff, and felt quite ridiculous mentioning "chunk" | 14:18 |
| straycat | can we just call them packages, or modules or something? | 14:18 |
| straycat | something similar to whatever everyone else is using perhaps? | 14:18 |
| pedroalvarez | I normally use the word "component" | 14:19 |
| straycat | also a request from another channel about our site | 14:19 |
| straycat | 14:20 Fuuzetsu$ straycat: can you put links to videos on your front page, the embedded stuff is a PITA | 14:19 |
| straycat | if you don't have flash and I can run the links through youtube-dl or something… | 14:19 |
| richard_maw | So Chunk => Component, Morphology => Definition. | 14:20 |
| straycat | Sorry to be so negative, to counter that: | 14:20 |
| straycat | 14:19 goibhniu$ ah baserock! sweet! | 14:20 |
| radiofree | pedroalvarez: sent for review | 14:24 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 14:24 | |
| paulsher1ood | radiofree: latest rc is v3.18-rc4 now :) | 14:26 |
| pedroalvarez | radiofree: cool, building | 14:27 |
| paulsher1ood | pedroalvarez: i will | 14:27 |
| straycat | richard_maw, I guess, idk really | 14:29 |
| paulsher1ood | straycat: shall i add the video links, or will you? | 14:30 |
| richard_maw | well, we need a straw-man to work from, I'd appreciate an RFC mail, even if it just helps organise the discussion | 14:31 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:32 | |
| paulsher1ood | richard_maw: for rename? | 14:32 |
| richard_maw | yep | 14:32 |
| paulsher1ood | ok, i'll do that | 14:32 |
| richard_maw | cheers | 14:33 |
| paulsher1ood | (since i have some quite strong opinions, as you know) | 14:33 |
| richard_maw | yep, and we should weigh your opinions as valuable too, since you've done a lot of explaining Baserock to people | 14:34 |
| radiofree | paulsher1ood: good demo opportunity then ;) | 14:35 |
| richard_maw | I'd like to keep the discussion open until friday at least, since I'm sure petefoth will have valuable input too. | 14:35 |
| franred | richard_maw, what is the priority on "Allow chunks with multiple source repositories" in your todo list? Could we do some minor patch to fix the submodules nighmare and then use that approach to do with multiple sources in one chunck? | 14:46 |
| straycat | paulsher1ood, i can later | 14:48 |
| richard_maw | franred: There's a reason we turned on the Vote button. I'll use the votes to prioritise work. | 14:49 |
| pedroalvarez | my vote havn't been listened :) | 14:49 |
| franred | richard_maw, I will vote :) | 14:50 |
| richard_maw | sorry, I must've missed it when I scrolled thorugh the list last wednesday | 14:50 |
| jjardon | mmm, probably Im missing something, but any idea why my interfaces network interfaces doesnt appear in ifconfig? only lo is present | 15:03 |
| jjardon | I run "qemu-system-x86_64 -hda gnome-system.img -netdev user,id=network0 -device e1000,netdev=network0 -enable-kvm" and I see the e1000 driver being loaded | 15:04 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 15:07 | |
| straycat | jjardon, probably because the interface is down, try ifconfig -a ? | 15:12 |
| * paulsher1ood sends his rfc to the list, and ducks | 15:19 | |
| straycat | i've added video links, hopefully they're ok | 15:20 |
| paulsher1ood | looks good to me. probably need to do the same on the videos page | 15:21 |
| ssam2 | there are ducks interested in Baserock now ? (sorry) | 15:21 |
| straycat | ssam2, ducks have been interested in Baserock for a while | 15:22 |
| richard_maw | ssam2: nah, he sent ducks to the list | 15:22 |
| franred | these ducks always seem to be ducked | 15:23 |
| jjardon | oh, of course, thanks straycat ! | 15:25 |
| radiofree | jjardon: i do -net nic,model=virtio,macaddr=52:54:00:12:34:11 -net tap | 15:34 |
| radiofree | which is probably wrong these days... but that's what i'm used to | 15:35 |
| * jjardon confirms network is working with systemd 217 (only a little configuration file is needed and you have network out of the box!) | 15:37 | |
| richard_maw | with networkd? | 15:38 |
| radiofree | yay! | 15:38 |
| jjardon | yes | 15:38 |
| richard_maw | ooh | 15:38 |
| jjardon | as simple as adding this: http://paste.baserock.org/kuyupekuje.apache | 15:39 |
| paulsher1ood | wow, that looks simple :) | 15:40 |
| ssam2 | yay! | 15:40 |
| jjardon | will try to send the patches today, can someone take a look to the coreutils patches? They already have a +1 by Sam and they are needed to compile systemd | 15:40 |
| richard_maw | that's what I like about systemd, the complicated stuff is moved into the daemons | 15:41 |
| paulsher1ood | jjardon: i'm building your coreutils branch now - anything particular i should test? | 15:43 |
| jjardon | paulsher1ood: not really, but remember to add the coreutils-common stratum to the system you build | 15:46 |
| richard_maw | wouldn't need to remember that if we had run-depends | 15:47 |
| * richard_maw ducks | 15:47 | |
| * paulsher1ood is just building devel as jjardon intended it | 15:47 | |
| jjardon | mmm, how baserock fill /etc/resolv.conf rigth now? | 15:47 |
| richard_maw | udhcpd | 15:48 |
| richard_maw | it's called by ifup, based on the contents of /etc/network/interfaces | 15:48 |
| richard_maw | ifup is called by ifup@.service, which is run for every network device | 15:48 |
| richard_maw | based on some udev rules, which I think are called 100-baserock.rules | 15:48 |
| jjardon | where is all that configured? it can be removed now | 15:48 |
| richard_maw | it pre-dates deployment and deployment-time configuration, so I think it's part of our delta against systemd | 15:49 |
| rjek | Which web servers are ready-to-go in baserock's stock definitions? | 15:49 |
| rjek | ISTR there was lighty at some point | 15:49 |
| richard_maw | lighttpd, but it's currently intertwined with the trove definition | 15:49 |
| richard_maw | hang on, I've got a branch to split that out | 15:50 |
| ssam2 | jjardon: there's some stuff in the baserock branches of delta:busybox that installs the networking units | 15:50 |
| ssam2 | would be good if you could remove them as part of your 'update systemd' branch | 15:51 |
| jjardon | richard_maw: ssam2 thanks, I will try to clean that stuff | 15:51 |
| straycat | i've also updated the ones on the video page | 15:52 |
| jjardon | what way do you use to know the delta in a specific module? seems we merge the upstream tag instead rebase against it in some modules | 15:57 |
| richard_maw | rjek: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock/richardmaw/split-out-lighttpd | 15:57 |
| richard_maw | the web system is a bit of a dumping ground for anything web related, and I don't think we've integrated any configuration for starting lighttpd independently of a trove for it to serve though | 15:58 |
| richard_maw | but I did get cobbler mostly working with that web server, before discovering that cobbler is not flexible enough for baserock deployments, as you'd need to patch cobbler for every variation of baserock system | 15:59 |
| * persia is generally opposed to dumping grounds, and would rather see dangling component definitions to strata with a usage model involving "delete the things you don't need from here. No, there isn't documentation on which bits interdepend." | 16:00 | |
| rjek | richard_maw: Thanks. | 16:00 |
| richard_maw | persia: this is part of why I did the run-depends patch, you're more likely to know the functionality you want, so you can work out which chunks you aren't interested in, and can delete | 16:01 |
| persia | richard_maw: Right (although I'm still trying to understand that completely). That said, I just don't like the "delete what you don't want" model at all. I prefer the "Add what you want" model, where w strive to make "what you want" to be sensible blobs of stuff, rather than 50,000 tiny packages. | 16:02 |
| richard_maw | We'll need another way for discovery of what's available to include, browsing systems for something relevant and deleting what's not needed is an easy way, but well named strata and `ls strata` could be another way to do it. | 16:04 |
| pedroalvarez | jjardon: I guess you could do `git diff` against the latest version we merged | 16:08 |
| richard_maw | rjek: comedy option for web servers: busybox httpd | 16:10 |
| rjek | Does that support gatewaying to HTTP-based application servers? If so, it's probably fine! :) | 16:10 |
| rjek | Apache would be nice, but I bet a ballache | 16:10 |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:10 | |
| richard_maw | if by "HTTP-based application servers" you mean CGIs, then sure! | 16:11 |
| rjek | I don't :) | 16:11 |
| richard_maw | I've just posted the patch I did to split lighttpd out to the mailing list | 16:12 |
| jjardon | I think we can remove the ntpd stuff as well | 16:12 |
| persia | Apache shouldn't be that bad: most of the runtimes required for most of the modules are already present | 16:12 |
| richard_maw | configuring apache is an exercise in terror in my experience | 16:13 |
| ssam2 | jjardon: I think we still want/need ntpd to run at boot if possible | 16:16 |
| ssam2 | jjardon: but the units we have in delta:busybox are bad | 16:16 |
| jjardon | ssam2: there is systemd-timesyncd for that since systemd 213 | 16:16 |
| richard_maw | systemd has built-in support for ntp now | 16:16 |
| jjardon | ;) | 16:16 |
| ssam2 | awesome | 16:16 |
| jjardon | will rebuild and restest after removing all these stuff | 16:17 |
| richard_maw | I'm not 100% sure about the details, I got the impression it will call out to chrony or isc-ntpd in some circumstances | 16:17 |
| pedroalvarez | I've just remembered I've found a bug some days ago | 16:21 |
| persia | Configuring apache is not so bad with automation. Debian provides some decent single-host automation support for Apache configuration. | 16:21 |
| jjardon | pedroalvarez: tyeah, the inconvenience is that I have to clone the package for that | 16:22 |
| straycat | pedroalvarez, what bug? | 16:22 |
| pedroalvarez | we are not checking that the name of a stratum matches with the stratum filename, or that the name of the stratum doesn't match with the name we put to the stratum in a system | 16:22 |
| jjardon | pedroalvarez: and counting that we branch from a tag, not a random commit | 16:22 |
| straycat | pedroalvarez, true but the name is irrelevant anyway | 16:23 |
| pedroalvarez | this causes some random behaviour | 16:23 |
| pedroalvarez | (not random) | 16:23 |
| persia | random is unfortunate | 16:23 |
| pedroalvarez | but the stratum with a different name is not built, and morph doesn't fail | 16:24 |
| radiofree | hmm i just did an upgrade to a system using my master branch and the fstab looks a bit buggered | 16:29 |
| radiofree | maybe... | 16:29 |
| richard_maw | it doesn't handle conflicting fstabs well | 16:30 |
| richard_maw | it should leave a copy of your old one around, but it's unfortunate that you have to fix it with the recovery console | 16:30 |
| radiofree | pedroalvarez: where's the pastebin script, do you have a link handy? | 16:31 |
| pedroalvarez | radiofree: yeah, you should have /etc/fstab.rej, and /etc/fstab.orig to see what haas happened | 16:32 |
| pedroalvarez | radiofree: paste.baserock.org/hastebinit | 16:32 |
| radiofree | in good news at least you now get a recovery console over both the serial and framebuffer console :D | 16:33 |
| ssam2 | oh, that's good! | 16:33 |
| radiofree | i don't have a fstab.rej :\ | 16:33 |
| persia | pedroalvarez: Could you add that link to the /topic? | 16:33 |
| pedroalvarez | persia: the paste url, or the paste client? | 16:34 |
| pedroalvarez | s/paste/haste/g | 16:34 |
| persia | The URL that allows folk to store text which then becomes http-accessible and for which the link is provided such that people can put that in channel in lieu of pasting directly. | 16:35 |
| richard_maw | we might want to instead have a link to our infrastructure on the wiki, so we can include the trello and stuff | 16:37 |
| pedroalvarez | Looking at other channels I think we can remove "Please note: This channel is logged" | 16:37 |
| pedroalvarez | richard_maw: we have to create that page first | 16:37 |
| franred | pedroalvarez, I was going to ask you for that | 16:37 |
| pedroalvarez | franred: remove that bit? | 16:37 |
| persia | I'm not convinced that we want to rely on Trello, although I'm not opposed to folk who find it useful using it temporarily | 16:38 |
| radiofree | couldn't get the paste script to work in recovery mode | 16:38 |
| radiofree | http://paste.fedoraproject.org/149399/15637543 | 16:38 |
| franred | pedroalvarez, yes, it is contained on IRC logs: http://testirclogs.baserock.org/ | 16:38 |
| radiofree | that's the fstab it created | 16:38 |
| radiofree | should be fixable, but there's no fstab.rej around | 16:38 |
| pedroalvarez | radiofree: and fstab.orig? | 16:39 |
| radiofree | nope | 16:39 |
| radiofree | just that | 16:40 |
| pedroalvarez | radiofree: can you mount /dev/sda (or /dev/mmcblkp1) and check the versions of /etc/fstab? | 16:40 |
| radiofree | back in after deleting the offending lines | 16:40 |
| franred | pedroalvarez, could we don't use: http://wiki.baserock.org/links/ for the IRC links adding a new Title "IRC tools" for them? | 16:40 |
| richard_maw | radiofree: is it missing the subvolumes then? | 16:40 |
| radiofree | in recovery mode i couldn't | 16:40 |
| radiofree | it says it was already mounted | 16:40 |
| richard_maw | then that's a kernel regression | 16:40 |
| radiofree | i'm back in now (i could switch to a previous upgrade etc...) | 16:41 |
| pedroalvarez | baserock upgrades ftw | 16:41 |
| radiofree | oh, it was me richard_maw | 16:41 |
| richard_maw | you're supposed to be able to mount a btrfs subvolume multiple times IIRC | 16:41 |
| radiofree | crappy options to it | 16:41 |
| radiofree | so i'm in after fixing the fstab, anything you want me to check? | 16:42 |
| radiofree | also, i just got a load of "[ 37.013464] systemd-journald[245]: Failed to write entry, ignoring: Invalid argument" messages | 16:42 |
| radiofree | there's no fstab.org or .rej, just the fstab | 16:44 |
| radiofree | maybe it thought it did a good job? | 16:44 |
| radiofree | hmm now i'm getting "no more space left on device" :\ | 16:45 |
| radiofree | there's 1.2G according to df | 16:46 |
| radiofree | Cloning into 'nouveau'... | 16:47 |
| radiofree | fatal: cannot copy '/usr/share/git-core/templates/hooks/post-update.sample' to '/root/newdrm/nouveau/.git/hooks/post-update.sample': No space left on device | 16:47 |
| radiofree | if i manually copy that, then i get some btrfs errors | 16:47 |
| richard_maw | btrfs filesystem df | 16:47 |
| radiofree | http://paste.baserock.org/qotihemexu.sm | 16:47 |
| radiofree | sorry that's the btrfs errors | 16:47 |
| radiofree | http://paste.baserock.org/ogubihiwib.avrasm = df | 16:48 |
| radiofree | have i fun out of space? | 16:50 |
| jjardon | what is the best morph stage to add a file? post-install-commands? | 16:51 |
| richard_maw | jjardon: if you need it at build-time, pre-configure-commands, otherwise I tend to use post-install-commands, yes | 16:52 |
| richard_maw | radiofree: it looks like it, though btrfs isn't great at reporting it | 16:52 |
| radiofree | well i'm currently 1GB into scping something onto the device, so i'm guessing i haven't run out? | 16:53 |
| radiofree | oh actually | 16:53 |
| radiofree | it failed | 16:53 |
| radiofree | i'll delete a previous upgrade then | 16:54 |
| radiofree | OSError: [Errno 28] No space left on device: '/tmp/tmpsMcLG4/tmpepXJls' | 16:54 |
| radiofree | :'( | 16:55 |
| paulsher1ood | what's the problem with specifying build-system: for every chunk (in the stratum definition of the chunk)? istm this would be trivial, and allow removal of some unnecessary magic? | 16:55 |
| radiofree | ok that seemed to have worked, i think, even though it failed | 16:56 |
| paulsher1ood | jjardon: i have built and booted your coreutils devel system | 16:56 |
| radiofree | at least it's not showing up in system-version-manager anymore | 16:56 |
| pedroalvarez | radiofree: do you have more free space now? | 16:56 |
| radiofree | yes, after i git cleaned some things | 16:57 |
| radiofree | the annoying thing is there's 6.6G free at the end of the drive | 16:57 |
| radiofree | can i use that for / ? | 16:57 |
| radiofree | (this is my fault, i set the ROOTFS_SIZE var to 8G in the flashing script) | 16:57 |
| jjardon | paulsher1ood: that would means we have to create a morph file for every chunk | 16:58 |
| richard_maw | radiofree: if it's not partitioned, you should be able to run `btrfs filesystem resize max /` | 16:58 |
| ssam2 | paulsher1ood: possibly no problem | 16:58 |
| paulsher1ood | jjardon: no - we could add buildsystem: to the field in stratum | 16:58 |
| radiofree | richard_maw: there's quite a few other partitions in the way | 16:59 |
| radiofree | i'm not sure we need them anymore though | 16:59 |
| * radiofree will throw caution to the wind and delete them all | 16:59 | |
| paulsher1ood | jjardon: repo:, ref:, build-system: etc ? | 16:59 |
| jjardon | paulsher1ood: ah, yeah, Id be ok with that | 17:00 |
| paulsher1ood | richard_maw: ^^ ? | 17:00 |
| richard_maw | radiofree: I can't think of a way to allow you to use that space for /, but that's only because we don't run btrfs device scan in the initramfs before mounting / | 17:01 |
| jjardon | the "magic" to detect the build system was to avoid to fork every repository in the world when we used to have the morph file in the chunk repo: dont think is needed anymore with your suggestion | 17:01 |
| radiofree | richard_maw: deleting all the partitions worked :D | 17:02 |
| paulsher1ood | jjardon: ah, yes. so we could do it then. | 17:02 |
| radiofree | oh dear i did something bad | 17:03 |
| paulsher1ood | we'd need a script to fix definitions.git again though | 17:03 |
| jjardon | paulsher1ood: why you want to remove the autodetection? is that "magic" causing problems? | 17:04 |
| * radiofree declares his rootfs now totally buggered and goes to run the flashing tool again | 17:04 | |
| paulsher1ood | heh | 17:04 |
| * jjardon wants to type as less as possible ;) | 17:04 | |
| ssam2 | jjardon: the magic does incur a cost at build time | 17:04 |
| ssam2 | well, build graph calculation time | 17:05 |
| richard_maw | jjardon: it slows down the pre-build step, as it has to inspect the working tree to see how it needs to build it | 17:05 |
| paulsher1ood | mauricemoss_: i see you now :-) | 17:06 |
| mauricemoss_ | :-) | 17:07 |
| * paulsher1ood sees a mail about windows on baserock-dev :) | 17:09 | |
| paulsher1ood | does anyone here use windows vbox? | 17:09 |
| pedroalvarez | I'm asking here. Have we ever supported that? | 17:10 |
| paulsher1ood | not explicitly. but vbox is usable on windows, and baserock as vbox guest should work | 17:10 |
| rjek | Is morph perhaps making assumptions about paths that don't hold on Windows? | 17:11 |
| persia | I recall a discussion in January that implied that Baserock could run in virtualbox on Windows, but that one could not use any of the deployment instrumentation to deploy to windows-hosted virtualbox, and that one could not use a shared filesystem for /src | 17:11 |
| radiofree | incredibly i managed to fix it | 17:11 |
| persia | I don't believe those issues were ever fixed, but my memory may be faulty | 17:11 |
| persia | radiofree: cool! | 17:11 |
| ssam2 | the deployment location field is a URL for most extension types | 17:11 |
| radiofree | however i have 6GB of free space (after using fdisk to delete the partitions after it) however btrfs doesn't seem to want to use that | 17:11 |
| ssam2 | and '/c:/foo/ is not a valid URL path | 17:12 |
| ssam2 | I wonder if using URL escape codes will work. If not, I think it should be fixed | 17:12 |
| persia | That should start with "file:///" anyway, and there are semantics for that. | 17:12 |
| ssam2 | persia: would do you mean by 'there are semantics' ? | 17:13 |
| pedroalvarez | main problem: C: != / | 17:13 |
| ssam2 | *what | 17:13 |
| persia | Windows also has a POSIX compat library that can be optionally installed, which provides a sensible rooted global filesystem. | 17:13 |
| radiofree | Disk /dev/mmcblk0: 14.7 GiB | 17:13 |
| radiofree | one partition reported /dev/mmcblk0p1 49152 16826367 8G Microsoft basic data | 17:13 |
| rjek | I wonder what happens if he scps test.txt to GMMCALL@192.168.1.35:/c:/Users/gmccall/vboxtoy/ | 17:13 |
| radiofree | btrfs resize did actually work previously to get it up to that 8G | 17:13 |
| rjek | (ie, with the leading /) | 17:13 |
| persia | ssam2: That there exists a set of rules to indicate that specific nouns are used to specify the device mapping in windows file:/// URIs. | 17:14 |
| * paulsher1ood responds on the list in the meantime, suggesting use cycle.sh to deploy to self :) | 17:16 | |
| ssam2 | oh, good thinking | 17:17 |
| * paulsher1ood thinks everyone should use cycle.sh, for most things, most of the time :-) | 17:18 | |
| * persia was happier using morph to do that directly, rather than having it abstracted, but agrees with the underlying concept | 17:19 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 17:20 | |
| paulsher1ood | persia: you mean a new 'morph build-and-deploy-in-an-idempotent-way' command? | 17:20 |
| paulsher1ood | urg... has anyone seen anything like this before? http://paste.baserock.org/iciqapiyem.vbs | 17:23 |
| ssam2 | oh | 17:23 |
| ssam2 | that seems like a system-integration command trying to remove a file and being prevented from doing it | 17:24 |
| paulsher1ood | i'm using latest morph, on jetson building james' unified branch... with 'scripts/cycle.sh systems/devel-system-armv7lhf-jetson.morph clusters/jetson-upgrade.morph' | 17:25 |
| richard_maw | that's odd, it's not supposed to make anything read-only | 17:25 |
| ssam2 | that linux-user-chroot commandline is enourmous ! | 17:25 |
| radiofree | i'm not entirely sure the devel system u-boot will boot that kernel, but it's a good test :) | 17:25 |
| paulsher1ood | only if i can build it, radiofree :) | 17:26 |
| * paulsher1ood fears morph naughtiness has crept in | 17:26 | |
| Kinnison | last time I saw a file URI for windows it was of the form file:///c|/stuff/thing | 17:26 |
| Kinnison | And some which still use the : instead of | | 17:27 |
| radiofree | paulsher1ood: it works for me, using morph | 17:27 |
| radiofree | hold on | 17:27 |
| paulsher1ood | latest morph? | 17:27 |
| radiofree | 1d6451363c92ec5466b01b5ba2fd327066343ab4 | 17:27 |
| ssam2 | Kinnison: http://blogs.msdn.com/b/ie/archive/2006/12/06/file-uris-in-windows.aspx tells me that both are valid | 17:28 |
| radiofree | latest morph is db759870b43782bf86801a6b55d14af24445b121 | 17:28 |
| Kinnison | ssam2: cool | 17:28 |
| ssam2 | I think the morphlib.util.containerised_cmdline() change is at fault | 17:29 |
| paulsher1ood | aha :-) | 17:29 |
| ssam2 | but I don't understand how, exactly | 17:29 |
| richard_maw | yep, I'm just trying to work out why | 17:29 |
| radiofree | are system integration commands run during the deploy or the build? i could try morph master and see if it breaks | 17:30 |
| ssam2 | radiofree: during the build | 17:31 |
| ssam2 | at system artifact construction time | 17:31 |
| paulsher1ood | radiofree: i think it is broken with morph master | 17:31 |
| radiofree | guess so, that sha for morph worked | 17:31 |
| richard_maw | ssam2: :-| it's the trailing / in the root path that's messing it up | 17:31 |
| *** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:32 | |
| richard_maw | I changed it to fix up the root path earlier after I tested that bit, and I wasn't testing writability in the test suite | 17:32 |
| ssam2 | oh, is this os.path.join()'s doing ? | 17:33 |
| richard_maw | does http://paste.baserock.org/uruwukulom.diff fix it? | 17:33 |
| * paulsher1ood will check | 17:33 | |
| richard_maw | ssam2: no, it does string matching to determine whether an entry is in or is a writable directory, and it matches without the trailing / | 17:34 |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:34 | |
| radiofree | nb all users of baserock-jetson-flash | 17:35 |
| paulsher1ood | in the meantime, i confirm that it worked with 1d6451363c92ec5466b01b5ba2fd327066343ab4 | 17:35 |
| radiofree | please change ROOTFS_SIZE=8something to ROOTFS_SIZE=15032385536 | 17:35 |
| radiofree | on line 28 | 17:35 |
| radiofree | then you can run the btrfs resize command to get a 14G / | 17:35 |
| paulsher1ood | radiofree: probably better to submit a patch to the list? | 17:36 |
| radiofree | i don't think it lives anywhere? where should i submit it to, definitions? | 17:36 |
| paulsher1ood | actually, where is the source to baserock-jetson-flash? | 17:36 |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 265 seconds] | 17:36 | |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 17:36 | |
| paulsher1ood | richard_maw: where should we put that? definitions/scripts? | 17:36 |
| radiofree | i fear it's not up to definitions/scripts quality | 17:37 |
| richard_maw | put what now? | 17:37 |
| * richard_maw has lost track of what's going on | 17:37 | |
| paulsher1ood | heh | 17:37 |
| paulsher1ood | radiofree's script for flashing jetsons. | 17:37 |
| ssam2 | definitions/scripts is not high quality :) | 17:38 |
| richard_maw | I was missing context because I was busy responsing to e-mails. | 17:38 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:38 | |
| * paulsher1ood is hurt by ssam2's remark :-) | 17:46 | |
| paulsher1ood | richard_maw: http://paste.baserock.org/ovusohanib.parser3 | 17:46 |
| richard_maw | I'm afraid I don't have time to work out why that isn't working today, I can promise to investigate tomorrow though. | 17:51 |
| persia | paulsher1ood: I used to use `morph deploy --upgrade ...`, and I didn't want it to be idempotent, because I routinely didn't like the results and rolled my environment back. | 17:51 |
| * persia hasn't been using baserock that actively recently, so cannot speak from immediate experience | 17:52 | |
| franred | also there are workflows which does not match with the idempotent behavior that cycle.sh does | 17:55 |
| franred | s/does/do/ | 17:55 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:55 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:57 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:04 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 18:05 | |
| richard_maw | :-( it looks like the read-only system integrations slipped past the test suite because of a bug in the test command | 18:05 |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 18:10 | |
| *** petefoth_ [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 18:21 | |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 258 seconds] | 18:21 | |
| petefoth_ is now known as petefoth | 18:21 | |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 18:37 | |
| paulsher1ood | persia: cycle.sh allows rollback | 20:10 |
| paulsher1ood | franred: for example? | 20:10 |
| persia | paulsher1ood: From http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/scripts/cycle.sh , it looks to me like it only supports rollbacks if I supply $newversion on the command line. | 20:12 |
| franred | for example any deployment which modify /var and other directories which AFAIK are shared/copied between "factory" and Test and the deployment need a clean rootfs | 20:12 |
| franred | paulsher1ood, ^^ | 20:12 |
| persia | But if I'm doing that, it's just syntactic candy because I don't happen to want to bother remembering the upgrade syntax | 20:13 |
| paulsher1ood | franred: so use a different cluster as your target? | 20:45 |
| paulsher1ood | persia: it doesn't delete the system you're starting from in any case, so you can always rollback.. .unless i'm misunderstanding your point? | 20:46 |
| paulsher1ood | if you don't supply $newversion, $newversion=TEST | 20:49 |
| franred | paulsher1ood, the problem is that cycle.sh update/upgrade/install an image on the same VM as Im developing, AFAIK, this images will share/update /var and other directories, so my rootfs will be updated - my devel and my test image would be not valid for me | 20:52 |
| franred | I discussed this with pedroalvarez to improve my workflow with my current work | 20:54 |
| paulsher1ood | franred: not if you create or use another cluster | 21:05 |
| franred | paulsher1ood, are you telling me that I can update a different VM using cycle? i.e #using a KVM+ssh cluster? | 21:06 |
| paulsher1ood | yes | 21:07 |
| paulsher1ood | i think so, at least. | 21:07 |
| paulsher1ood | might need a manual step to delete your target vm each time | 21:07 |
| persia | paulsher1ood: Maybe I am misunderstanding. I thought that it defaulted to "TEST", so if you ran it twice, it would overwrite itself. | 21:08 |
| paulsher1ood | persia: it defaults to targeting TEST. if you run it again, it will overwrite TEST (unless you are IN the TEST system, in which case it will advise you to boot into another system firs) | 21:09 |
| paulsher1ood | (can't overwrite the running system) | 21:10 |
| persia | Ah, OK. That is less worrisome. | 21:10 |
| paulsher1ood | :) | 21:10 |
| franred | hehe, paulsher1ood, if I need to remove my VM, it wouldn't be the same as a normal deploy via KVM+ssh? | 21:10 |
| paulsher1ood | franred: yes. but cycle means you can build and deploy to it in one step | 21:11 |
| persia | I still prefer the old way, because I use `git parse-rev HEAD` for version, but that only works if one commits more often than is typical. | 21:11 |
| paulsher1ood | you could (for example) edit cycle.sh to add a line to remove your target vm if you're going to do it over and over again | 21:11 |
| franred | paulsher1ood, well it is just add deploy at the end of build if Im not wrong. "morph build && morph deploy" | 21:12 |
| paulsher1ood | franred: it runs morph gc as well | 21:13 |
| franred | I run it by default when I do any build | 21:13 |
| paulsher1ood | right :) | 21:13 |
| persia | Something is wrong if we have to manually run `morph gc` with any regularity | 21:14 |
| paulsher1ood | we do | 21:15 |
| persia | I know that it is a hard balance between having infinite disk space and supporting infinite cacheable artifacts, but there ought be some way to deal with the problem. | 21:15 |
| persia | e.g. a LRU disposal algorithm, or similar. | 21:15 |
| paulsher1ood | i think morph gc has somerthing like that already. but my previous attempts to get it included in morph build by default failed to convince folks | 21:16 |
| persia | My memory of discussion about `morph gc` was that it cleaned up rather more than I would have preferred. | 21:17 |
| persia | And spent too much time trying to determine what was upstream, rather than what I happened to be using. | 21:17 |
| paulsher1ood | software is never perfect, sadly :) | 21:18 |
| paulsher1ood | anyway, i'll stop trying to sell cycle.sh to you guys - you're experts. for novices, it's much simpler than trying to explain the intricacies of morph deploy | 21:19 |
| straycat is now known as vletrmx21 | 21:20 | |
| * paulsher1ood also notes, in passing, that he has been able to identify bugs in morph by using only cycle.sh | 21:20 | |
| franred | persia, morph gc does not only clean cache, it cleans, failed builds, and staging areas | 21:22 |
| *** vletrmx21 [~straycat@vortis.xen.tardis.ed.ac.uk] has quit [] | 21:22 | |
| persia | paulsher1ood: BY moving between versions of morph, or by exercising morph? | 21:23 |
| persia | franred: Yes. It didn't used to do so. Some of that isn't actually very useful, but that is because of other issues with morph's UI. | 21:23 |
| * persia remains deeply unhappy with gc, but cares more about other bits at the current time | 21:23 | |
| franred | :) | 21:24 |
| paulsher1ood | persia: just by exercising morph. today's bug in readonly system-integrations for example | 21:24 |
| persia | More folk should be using the upgrade feature to install stuff regularly, and using systems != reference systems. | 21:24 |
| paulsher1ood | agreed | 21:25 |
| paulsher1ood | i wonder if mason should do this by default, and upgrade itself each time :) | 21:25 |
| persia | Mason is a complicated concept. | 21:25 |
| persia | But I don't actually believe we want a long-lived Mason instance, as it becomes special. | 21:26 |
| persia | Rather, I think we want to spawn test harnesses built from master when there are candidates against master, and then use that to test the candidates (including testing the ability to build systems, and deploy test harnesses). | 21:27 |
| paulsher1ood | maybe i'm thinking of something simpler :) | 21:27 |
| * paulsher1ood has an early start... so heads to the land of nod | 21:27 | |
| persia | I don't see any reason not to test upgrades, but I also don't know how to model this elastically without dropping the idea of there being any system for "Mason", | 21:27 |
| persia | It ought all be git hooks | 21:27 |
| persia | Heh. Sleep well. | 21:28 |
| persia | Is the thing that makes systemd do things called a "unit"? | 21:29 |
| franred | persia, yes, it is | 21:30 |
| persia | Thanks. | 21:30 |
| franred | but they will finish in .service | 21:30 |
| persia | That's delightfully inconsistent :) | 21:32 |
| * persia loves consensus nomenclature | 21:32 | |
| * franred goes home after checking that his rabbitmq is configured but he does not have any clue why systemd decides to kill it by timeout :S | 21:33 | |
| franred | there are something missing here but Im out of brain now | 21:33 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 21:44 | |
| *** rdale_ [~quassel@38.Red-83-47-20.dynamicIP.rima-tde.net] has joined #baserock | 21:48 | |
| *** rdale [~quassel@170.Red-79-145-104.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 21:50 | |
| * persia gets annoyed at network connection drops, and decides to write more email later, rather than now | 21:59 | |
| * jjardon has a system with network and ntpd out of the box using only systemd stuff | 22:20 | |
| jjardon | still having problems compiling resolved (for /etc/resolv.conf), though | 22:20 |
| persia | Lack of dependencies, or something strange in the build environment? | 22:25 |
| jjardon | compilation error: | 22:25 |
| juergbi | jjardon: what compilation error? i've built it fine on x86-64 and arm (outside baserock) | 22:38 |
| jjardon | let me get there, it takes like 30 min to compile systemd here ;) | 22:38 |
| jjardon | (it also fails if you compile it in more than one thread) | 22:39 |
| juergbi | ah, i might not be here anymore in 30 min | 22:39 |
| juergbi | but could take a quick look tomorrow if you paste a build log | 22:40 |
| jjardon | juergbi: will do | 22:40 |
| juergbi | i also have a full log of a successful build here if that helps | 22:40 |
| jjardon | juergbi: dont worry, I built systemd outside baserock several times, also its building fine in build.gnome.org ;) | 22:41 |
| *** straycat [~straycat@vortis.xen.tardis.ed.ac.uk] has joined #baserock | 22:42 | |
| juergbi | well, i meant for arm. but i take it you have the same issue on x86, then | 22:42 |
| jjardon | juergbi: persia http://paste.baserock.org/mepofaqotu.sm | 22:48 |
| jjardon | juergbi: oh, yeah, this is x86-64 | 22:49 |
| juergbi | oh, looking at that, it's almost strange that it works outside baserock | 22:50 |
| juergbi | jjardon: ah, i suspect static_assert is not defined in the old gcc version baserock uses | 22:52 |
| juergbi | so it falls back to systemd's imitation of it and that is buggy | 22:52 |
| juergbi | should be easy to workaround by simply making those static asserts a no-op | 22:53 |
| juergbi | not sure how easy is it to properly fix it in systemd for these older gcc versions | 22:53 |
| jjardon | hopefully pedroalvarez will upgrade gcc after his glibc patches | 22:55 |
| juergbi | ah, maybe the new UNIQ macros could be used instead of __LINE__ | 22:55 |
| juergbi | yes, that would be great | 22:55 |
| jjardon | will see if I can patch systemd until that | 22:55 |
| juergbi | btw: the issue is in src/shared/macro.h | 22:56 |
| juergbi | #define assert_cc(expr) \ | 22:56 |
| persia | freeciv ran into this issue, and fixed it with some preprocessor code, but I don't understand the details. It may also be possible to force some older gcc versions to use C11, even if this is not the default. | 22:57 |
| pedroalvarez | jjardon: it will take some time ;) | 22:58 |
| *** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 22:59 | |
| pedroalvarez | Although seems that glibc is nearly there in this version | 22:59 |
| jjardon | mmm, seems gcc has static assertions since 4.3: https://gcc.gnu.org/projects/cxx0x.html | 23:02 |
| jjardon | pedroalvarez: only want you to feel the pressure ;) | 23:02 |
| juergbi | maybe only in c++ | 23:02 |
| juergbi | https://gcc.gnu.org/wiki/C11Status | 23:03 |
| juergbi | gcc 4.6 | 23:03 |
| juergbi | the static_assert define is in glibc, though | 23:05 |
| juergbi | assert.h | 23:05 |
| juergbi | it might actually just work with glibc 2.20 | 23:05 |
| * jjardon will rebase his branch againt the new glibc one and try again | 23:18 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!