| *** wdutch has quit IRC | 01:34 | |
| *** wdutch has joined #baserock | 01:34 | |
| *** wdutch has quit IRC | 03:34 | |
| *** wdutch has joined #baserock | 03:35 | |
| *** zoli__ has joined #baserock | 05:14 | |
| *** zoli__ has quit IRC | 05:36 | |
| *** zoli__ has joined #baserock | 07:05 | |
| *** bashrc_ has joined #baserock | 08:05 | |
| *** edcragg has joined #baserock | 08:15 | |
| *** gary_perkins has joined #baserock | 08:20 | |
| *** jonathanmaw has joined #baserock | 08:34 | |
| *** ssam2 has joined #baserock | 08:48 | |
| *** ChanServ sets mode: +v ssam2 | 08:48 | |
| jmacs | I'm trying to build CUPS in Baserock, and it looks like the build system is trying to use AutotoolsBuildSystem, even though I've specified build-system: manual. Is there another way to tell it just to run my configure-commands and build-commands? | 09:07 |
|---|---|---|
| Kinnison | if you've said build-system: manual (and remembered to refer to the chunk .morph file from your stratum) then it really shouldn't use autotools | 09:09 |
| jmacs | That's probably it, I was missing the morph: line in the stratum | 09:12 |
| pedroalvarez | oh, the obscure magic of autodetection | 09:12 |
| Kinnison | jmacs: glad to be of service :) | 09:14 |
| jmacs | Thank you. | 09:17 |
| *** lachlanmackenzie has joined #baserock | 09:20 | |
| *** tiagogomes has quit IRC | 09:23 | |
| Kinnison | Anyone know how to get gerrit to stop assuming I care about a topic I put a throwaway comment on but didn't actually review? | 09:24 |
| Kinnison | aha, I remove myself from the reviewers list | 09:24 |
| Kinnison | yay | 09:24 |
| pedroalvarez | gertty ftw! | 09:24 |
| pedroalvarez | is anybody else using it? | 09:25 |
| Kinnison | does it let you do individual commenting? | 09:25 |
| pedroalvarez | "individual commenting" == inline comments? | 09:25 |
| Kinnison | yes | 09:26 |
| pedroalvarez | I believe you can do everything you already do in the web UI | 09:26 |
| Kinnison | oooh nice | 09:26 |
| richard_maw | unfortunately, while it looks like mutt, the keyboard shortcuts aren't the same | 09:27 |
| *** 20WABCVSQ has joined #baserock | 09:27 | |
| Kinnison | My mutt is already heavily customised :) | 09:27 |
| pedroalvarez | the only thing I miss being able to search for text in a diff | 09:29 |
| pedroalvarez | or patchset | 09:29 |
| richard_maw | I prefer how the web ui presents the diffs | 09:29 |
| *** mariaderidder has joined #baserock | 09:59 | |
| *** gary_perkins has quit IRC | 10:09 | |
| *** gary_perkins_ has joined #baserock | 10:09 | |
| ssam2 | has anyone built 'master' of definitions with 'ybd' recently? | 10:11 |
| ssam2 | I'm getting: [ansible] ERROR: recursion loop for ansible | 10:12 |
| ssam2 | running: python ../ybd/ybd.py systems/build-system-x86_64.morph x86_64 | 10:12 |
| mwilliams_ct | Hi all, I submitted a strata yesterday and Zara has rightly questioned the ref: I used. Neither of us are sure which to use, could somebody have a look at Zara's review on https://gerrit.baserock.org/#/c/721/1/strata/mtd-utilities.morph and confirm either way? | 10:16 |
| radiofree | 9f107132a6a073cce37434ca9cda6917dd8d866b is correct for 1.5.1 | 10:18 |
| radiofree | http://git.baserock.org/cgi-bin/cgit.cgi/delta/mtd-utils.git/commit/?id=9f107132a6a073cce37434ca9cda6917dd8d866b | 10:18 |
| SotK | mwilliams_ct: use the commit SHA, not the tag SHA :) | 10:19 |
| mwilliams_ct | OK so the answer is to use the commit hash rather than the tag name hash. I'll try and document that somewhere | 10:19 |
| mwilliams_ct | thanks SotK radiofree :) | 10:19 |
| ssam2 | the 'always use the commit SHA1' policy should be here: http://wiki.baserock.org/policies/ | 10:21 |
| ssam2 | i'm kind of surprised that it isn't :) | 10:21 |
| jmacs | The meaning of +1 and -1 on the policies page is at odds with gerrit's documentation | 10:24 |
| ssam2 | oh, yes, I guess that hasn't been updated since we switched to Gerrit | 10:24 |
| Kinnison | I imagine we've failed to amend the policy to fit with gerrit's approach | 10:24 |
| mwilliams_ct | I've added a section about strata versions. I've not done much work on upstream Baserock so it needs sanity checking | 10:25 |
| jmacs | I can copy the meaning from gerrit's documentation into that section, if people are happy with that | 10:26 |
| ssam2 | is it possible to link to Gerrit's documentation directly? | 10:27 |
| Kinnison | mwilliams_ct: I'd prefer 'Versioning in Strata' or "Use of 'ref:' in Strata" | 10:27 |
| jmacs | Yes, I was planning to link to it and include a summary | 10:27 |
| ssam2 | cool, that's fine by me then | 10:27 |
| Kinnison | mwilliams_ct: "Strata versions" is a painfully confusing combination of plurals | 10:27 |
| mwilliams_ct | Go for it. I am not picky about being corrected, hence my request for review | 10:28 |
| Kinnison | Heh | 10:28 |
| * Kinnison hopes whoever edits the page for gerrit +1/-1 policy will amend that title too :) | 10:28 | |
| ssam2 | mwilliams_ct: looks fine other than it should be 'stratum versions', thanks | 10:31 |
| jmacs | Kinnison: Too late, sorry | 10:36 |
| jmacs | Well, not really, fixed now | 10:37 |
| *** gary_perkins_ has quit IRC | 10:38 | |
| Kinnison | :) | 10:38 |
| jmacs | I think we should avoid using nouns with latin pluralisation rules as component names | 10:38 |
| DavePage | jmacs: And use Greek ones instead? :) | 10:40 |
| jmacs | No, DavePage. | 10:40 |
| ssam2 | jmacs: your change to the wiki looks good, thanks for doing it | 10:40 |
| wdutch | stratapodes | 10:42 |
| *** inara has quit IRC | 10:48 | |
| jmacs | What's the difference between DESTDIR and PREFIX? Is there a good reason I shouldn't say "./configure --prefix="$DESTDIR$PREFIX" ? | 10:53 |
| Kinnison | DESTDIR is only for install | 10:54 |
| radiofree | i don't think you should do that | 10:54 |
| Kinnison | DESTDIR tells 'make install' what to shove on the front | 10:54 |
| Kinnison | PREFIX tells the build where it will be when on the target | 10:54 |
| radiofree | e.g mycomponent.install/ | 10:54 |
| jmacs | Right, but is DESTDIR something built into make or a convention? | 10:54 |
| Kinnison | convention | 10:54 |
| Kinnison | as is PREFIX | 10:54 |
| jmacs | Makes sense | 10:56 |
| *** gary_perkins has joined #baserock | 10:58 | |
| Kinnison | c/win 29 | 10:58 |
| *** inara has joined #baserock | 10:59 | |
| ratmice___ | jmacs: the relevent horses mouths are http://www.gnu.org/prep/standards/html_node/DESTDIR.html http://www.gnu.org/prep/standards/html_node/Directory-Variables.html#index-prefix | 10:59 |
| radiofree | annoyingly qmake turns DESTDIR= into INSTALL_ROOT= | 11:00 |
| jmacs | I'm dealing with CUPS at the moment, which wants BUILDROOT instead of DESTDIR, which is an unhelpful name | 11:02 |
| jmacs | Do lorry requests go via gerrit or mailing list now? | 11:09 |
| radiofree | gerrit | 11:13 |
| radiofree | https://gerrit.baserock.org/#/admin/projects/baserock/local-config/lorries | 11:13 |
| ratmice___ | jmacs: DSTROOT no? Makedefs.in:BUILDROOT = $(DSTROOT) | 11:15 |
| *** inara has quit IRC | 11:15 | |
| jmacs | ratmice___: The INSTALL.txt tells me to use BUILDROOT. | 11:16 |
| *** inara has joined #baserock | 11:18 | |
| jmacs | radiofree: Cheers. For some reason none of the patches in that project show up when you search for 'lorry' | 11:19 |
| Zara | I'm back! trying to build a minimal armv5l system, and I think it may include some libraries that we don't need. Wondering if anything here looks suspect to anyone; I'm not sure why we'd need something called 'libgcc' or 'libfortran' in the final image but maybe they're important? http://paste.baserock.org/mozunavoji (in detail: http://paste.baserock.org/ukodubeyab ) if so, how would I keep them out of the final image? | 11:23 |
| Zara | (er, if *not*, haha) | 11:23 |
| ssam2 | zara: libgcc is usually quite important | 11:25 |
| ssam2 | zara: libfortran is not, unless you want to run fortran programs | 11:25 |
| ssam2 | you can use splitting rules to keep them out of the image... which aren't documented anywhere, as far as I know, and I don't really understand how to use them properly | 11:25 |
| ssam2 | Baserock could do with some improvement in that regard | 11:26 |
| *** inara has quit IRC | 11:27 | |
| ssam2 | alternatively you could write a .configure extension to delete the files you don't want, which is quite easy | 11:28 |
| Zara | hehe, is that documented? | 11:29 |
| Zara | (I'd assumed libgcc was needed for gcc to run, but I wasn't sure that we'd need to compile things on this system at runtime. But I could be wrong on both things there...) | 11:32 |
| ssam2 | Zara: i tried to write a bit about deploy-time extensions here: http://wiki.baserock.org/definitions/current/#index4h2 | 11:33 |
| ssam2 | they are programs that get passed a path to the system rootfs as their only argument, so just write a simple Python program or shell script that deletes the files using 'rm' or os.unlink() or whatever | 11:34 |
| *** inara has joined #baserock | 11:34 | |
| ssam2 | but remember to delete inside the rootfs, not the host system, as they have full access to your host system and can delete files from there as well!! | 11:35 |
| radiofree | ouch | 11:35 |
| Zara | :0 I may look into the splitting rules for now... | 11:36 |
| ssam2 | it's not as bad as it sounds | 11:36 |
| Zara | heh, does deleting inside the rootfs just mean being careful about the filepath to whatever I'm deleting, or is there some flag I need to pass? | 11:38 |
| * radiofree once had a script that did rm -rf $ROOTFS_DIR/boot/* | 11:39 | |
| radiofree | which had to be run as root | 11:40 |
| Zara | eep | 11:40 |
| pedroalvarez | Zara: you need to be careful | 11:42 |
| pedroalvarez | (about the path) | 11:43 |
| *** inara has quit IRC | 11:45 | |
| Zara | great, thanks everyone. I will read up and be very careful. :) | 11:46 |
| ssam2 | as long as you run it in a baserock chroot or vm the worst that happens is you destroy the chroot or vm, anyway | 11:48 |
| richard_maw | ssam2: unless you bind-mount your host fs into your chroot | 11:49 |
| richard_maw | you can break your host if you do that | 11:49 |
| Zara | I sacrificed a lot to obtain this chroot and a bind-mount was done at some point. | 11:49 |
| pedroalvarez | jmacs: I left a comment in your CUPS lorry patch | 11:49 |
| ssam2 | richard_maw: true. I deleted most of my /src directory recently using `manage-baserock rm` | 11:50 |
| richard_maw | ouch | 11:50 |
| ssam2 | which was bind-mounted in from the host | 11:50 |
| *** inara has joined #baserock | 11:56 | |
| Zara | btw, the libs above seemed to be included as part of build-essential-minimal. That seems a bit weird to me. I notice that gblic-nss here: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/build-essential.morph has build-essential-runtime as an artifact, but I can't find what build-essential-runtime refers to. (also pretty confused by the artifacts field in chunks in general, when there's a colon invol | 12:14 |
| richard_maw | Zara: build-essential-{runtime,devel} are default rules | 12:16 |
| richard_maw | Zara: when there's a colon involved its explicit assignment of an artifact produced by a chunk build to a stratum artifact | 12:16 |
| richard_maw | in the `products:` section there's more generic match rules by artifact name | 12:17 |
| *** inara has quit IRC | 12:17 | |
| *** inara has joined #baserock | 12:20 | |
| Zara | richard_maw: does that mean that 'specific-chunk : build-essential-minimal' will include that specific chunk in the build-essential-minimal artifact, and then the products field may contain other chunks to be included in the artifact (but named less precisely?) or have I totally misinterpreted you? ^^' | 12:24 |
| richard_maw | Zara: you are completely correct | 12:25 |
| Zara | ahhh, excellent. explains a lot, since I thought that the build-essential-minimal artifact should *only* contain the things listed in 'include'... but there are in fact other things in the stratum that it contains. | 12:27 |
| Zara | ahhh, and these libs are all from gcc-libs | 12:33 |
| Zara | am now wondering how many of these are necessary for a working system. seems excessive to put them all in build-essential-minimal (these include libgfortran) | 12:45 |
| jmacs | Having "essential" and "minimal" in a stratum name seems redundant | 12:46 |
| Zara | build-essential is the stratum, and build-essential-minimal is the artifact, but it does suggest that one name is misleading | 12:48 |
| mwilliams_ct | SotK: Thanks for the review on 721! I've commented on gerrit too, but I am quite happy to add mtd-utilities to other build systems if wanted. It does seem to go against the general policy of only adding things if they're needed specifically though? | 13:04 |
| SotK | hmm, I thought that the idea was that build-system-*.morph each contained the same things as far as possible, but maybe I'm wrong | 13:08 |
| SotK | I don't particularly mind either way | 13:08 |
| mwilliams_ct | if that is the case then youre definitely right to suggest it's added. new thing to me so not sure | 13:09 |
| SotK | I also notice that the other build systems contain some things that the openBMC one doesn't (ansible + openstack stuff mostly afaict) | 13:10 |
| Zara | would someone with more knowledge be able to look at the gcc-libs that are currently installed as part of build-essential-minimal, and check which are actually essential (when they have a spare moment)? I think there might be quite a bit we can cut. (I realise that essential-ness is a bit relative) | 13:12 |
| mwilliams_ct | SotK: hmm, jjardon could probably comment in that case, he's to git blame | 13:14 |
| jjardon | SotK: yes, that was intentional; we do not need anything of that | 13:17 |
| SotK | it seems weird to me to have systems named the same except for their target architecture that differ in more than just the bsp stratum, but idk if we have or want policy on this | 13:19 |
| SotK | + (for example) deploying to openstack with morph won't work in that system I think, which people may expect to be able to do based on documentation | 13:21 |
| jjardon | SotK: sure, but note the name is build-system-armv5l-openbmc-aspeed, not build-system-armv5l-generic | 13:22 |
| radiofree | ppc devel systems are different to x86/arm | 13:23 |
| radiofree | (node.js) | 13:23 |
| jjardon | happy to change the name though, if you think is needed. Problem here is we have to cross-compile the entire build- system for armv5, so the smaller its, the better for us | 13:24 |
| * SotK doesn't really mind very much either way | 13:25 | |
| SotK | radiofree: is that an oversight or does node.js not build on ppc? | 13:25 |
| radiofree | doesn't build | 13:26 |
| *** rdale has quit IRC | 13:29 | |
| SotK | I see | 13:32 |
| SotK | I don't think the documentation assumes that the build-systems are the same anywhere, so I'm fine with leaving it called build-system-armv5l-openbmc-aspeed | 13:32 |
| *** gallit has joined #baserock | 13:46 | |
| *** zoli__ has quit IRC | 14:18 | |
| *** rdale has joined #baserock | 14:19 | |
| jmacs | Hmm, this is new: "Cannot change ownership to uid 10, gid 143: Operation not permitted" during an untar | 14:25 |
| paulsher1ood | ssam2: afaict no recursion loop on ansible for me, using master ybd and master definitions | 14:26 |
| Kinnison | jmacs: within a build? | 14:26 |
| jmacs | Kinnison: Within an install. It's running tar zxf jdk-8u20-linux-x64.tar.gz -C "$DESTDIR$PREFIX"/lib | 14:28 |
| jmacs | This used to work; I can't figure out what's changed | 14:28 |
| Kinnison | jmacs: I think that within builds, chown/chgrp aren't allowed (capabilities dropped by linux-user-chroot) | 14:30 |
| jmacs | morph doesn't do any chown or chgrp. It downloads jdk-8u20-linux-x64.tar.gz from github, and extracts it. That's all. | 14:31 |
| pedroalvarez | jmacs: I've seen that in the past | 14:32 |
| franred | jmacs, does tar try to keep the owner of the jdk files? | 14:32 |
| pedroalvarez | tar is trying to set the owner and the group | 14:32 |
| rjek | --no-same-owner | 14:32 |
| rjek | (If you use tar as root, it will try to apply the original ownership by default) | 14:32 |
| pedroalvarez | this "error" is new, because before we were using busybox tar | 14:33 |
| jmacs | aah, good point | 14:34 |
| *** zoli__ has joined #baserock | 14:34 | |
| pedroalvarez | we could just use `busybox tar` instead of using `--no-same-owner` | 14:37 |
| jmacs | I think using --no-same-owner makes it clearer what's going on | 14:37 |
| ssam2 | paulsher1ood: building build-system-x86-64.morph ? | 14:45 |
| ssam2 | paulsher1ood: It seems to build minimal-system OK, just not build-system | 14:45 |
| paulsher1ood | ssam2: i believe so - http://paste.baserock.org/ojulixetuf | 14:47 |
| pedroalvarez | meh, we are having problems with OpenStack and pgsql... :/ | 14:48 |
| ssam2 | paulsher1ood: I see... I've been using git://git.baserock.org/baserock/baserock/ybd instead of https://github.com/devcurmudgeon/ybd/ so am missing quite a lot of commits | 14:53 |
| paulsher1ood | ah | 14:53 |
| paulsher1ood | sorry about that | 14:54 |
| paulsher1ood | maybe worth deleting that repo to avoid confusion | 14:54 |
| ssam2 | yes, if you're not using it, would make sense | 14:55 |
| paulsher1ood | i put it there temporarily, when i had access problems on github | 14:56 |
| jjardon | Hi, I see BOOT_DEVICE in some cluster files. What extension handles this? I can not see anything in the definitions or morph repos | 14:56 |
| * paulsher1ood assumes he doesn't have powers to delete a repo from gbo | 14:56 | |
| richard_maw | jjardon: look at writeexts.py | 14:57 |
| radiofree | jjardon: it's use for system-version-manager | 14:58 |
| radiofree | so.. look in tbdiff | 14:58 |
| jjardon | ah, here you are, thanks radiofree | 15:01 |
| * richard_maw is unhappy with paulsher1ood creating repositories on git.baserock.org without asking, as they get mirrored to all our downstream users | 15:03 | |
| *** mariaderidder has quit IRC | 15:04 | |
| straycat | why wouldn't gbo ybd lorry from github? | 15:05 |
| richard_maw | it wasn't lorried | 15:05 |
| richard_maw | if it were lorried, at least it would be up to date now | 15:05 |
| jjardon | so, any idea how to set the ROOT_DEVICE if you are not planning on use syslinux? | 15:06 |
| straycat | okay | 15:06 |
| radiofree | jjardon: what do you mean? | 15:06 |
| paulsher1ood | straycat: good idea. i put it as a baserock/baserock project in desperation one day when i couldn't get to github | 15:06 |
| radiofree | ROOT_DEVICE: /dev/whateveryouwantittobe | 15:06 |
| radiofree | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/clusters/jetson-upgrade.morph | 15:07 |
| radiofree | BOOT_DEVICE is only useful when your u-boot has the "sysboot" command | 15:08 |
| *** straycat is now known as shockedcat | 15:08 | |
| * shockedcat is shocked | 15:08 | |
| rjek | :) | 15:08 |
| paulsher1ood | ? | 15:08 |
| jjardon | radiofree: seems ROOT_DEVICE is only useful if you use extlinux. What if you dont want to use extlinux? Or that is not possible? | 15:08 |
| *** shockedcat is now known as straycat | 15:09 | |
| straycat | it seems unlikely anyone is using it downstream, perhaps just mark it as obsolete and lorry in from github to be on the safe side? | 15:10 |
| richard_maw | straycat: there's no lorry to mark as obsolete | 15:10 |
| richard_maw | it's not delta/ybd, it's baserock/baserock/ybd | 15:11 |
| straycat | i know | 15:11 |
| straycat | but we can put "obsolete" in its description? | 15:11 |
| richard_maw | oh, I misread you, sorry | 15:11 |
| paulsher1ood | why not just delete it? | 15:11 |
| richard_maw | I'd rather be rid of it entirely and ban paulsher1ood from creating repositories | 15:11 |
| straycat | we could also just delete it | 15:11 |
| straycat | hrm, i don't think we need to resort to that, to be fair | 15:12 |
| paulsher1ood | :) | 15:12 |
| radiofree | jjardon: i still don't know what you mean | 15:13 |
| radiofree | jetson uses u-boot | 15:13 |
| richard_maw | straycat: if it were the first offence I'd agree, but paulsher1ood has also pushed through lorries without consultation too | 15:13 |
| radiofree | ROOT_DEVICE changes the kernel args (root=$ROOT_DEVICE) instead of hard-coding to /dev/sda | 15:13 |
| richard_maw | which was annoying, because we already *had* that lorried under a different name | 15:13 |
| radiofree | jjardon: u-boot can support reading an extlinux.conf file | 15:13 |
| radiofree | if your u-boot can't do that, then ROOT_DEVICE and BOOT_DEVICE are useless, and you'll have to do it all manually anyway | 15:14 |
| paulsher1ood | richard_maw: i'm sure i'm not the only person to make mistakes, here | 15:14 |
| radiofree | i.e just extract a tarball to your emmc, or dd it over... | 15:14 |
| paulsher1ood | richard_maw: plus, i don't think creating ybd as a baserock/baserock project actually violated any policy? | 15:16 |
| richard_maw | paulsher1ood: I know that, and if I'd done the same I'd expect to have some form of disciplinary action on myself | 15:16 |
| * richard_maw is just frustrated | 15:16 | |
| * paulsher1ood is sorry that richard_maw is frustrated | 15:16 | |
| jjardon | radiofree: this is not for a jetson; we are not using extlinux, that's the reason of my question. Thanks anyway, I think I have a clearer idea now | 15:17 |
| radiofree | jjardon: the jetson doesn't use extlinux | 15:18 |
| ssam2 | i'll delete baserock/baserock/ybd tomorrow unless anyone feels strongly that I shouldn't | 15:18 |
| *** mariaderidder has joined #baserock | 15:18 | |
| radiofree | jjardon: u-boot supports reading extlinux.conf files (see `sysboot`), so you can use ROOT_DEVICE and BOOT_DEVICE to generate the bootloader config in the same way | 15:18 |
| paulsher1ood | +1 for the delete | 15:18 |
| jjardon | radiofree: oh, ok. That makes everything much more clear now | 15:19 |
| radiofree | only for x86 systems do you call "extlinux --install" | 15:19 |
| richard_maw | ssam2: how about remo? Possibly the same | 15:19 |
| pedroalvarez | what's that? | 15:19 |
| straycat | i'm not particularly against deleting that repo, but as for policy would rather we could trust each other not to push things through without prior approval rather than relying on gitano | 15:19 |
| richard_maw | pedroalvarez: another of paulsher1ood's repositories | 15:19 |
| * ssam2 does want to ban paulsherwood from naming variables 'this', however | 15:20 | |
| straycat | heh | 15:20 |
| SotK | :) | 15:20 |
| radiofree | jjardon: if you check a jetson cluster you'll see BOOTLOADER_CONFIG_FORMAT: "extlinux" and BOOTLOADER_INSTALL: "none" | 15:20 |
| radiofree | so generate an extlinux config file, but don't bother installing extlinux | 15:20 |
| paulsher1ood | remo was the repo i used to explain ssome restructuring of morphs.... | 15:20 |
| radiofree | if you can build u-boot for whatever device you're deploying you it should be fairly simple to add the sysboot command | 15:20 |
| richard_maw | ssam2: it's already been mirrored downstream by now, so we're probably better off deleting all its refs and adding a master branch which just has a readme file saying the repository has been removed | 15:20 |
| richard_maw | ssam2: after some period we can remove the repository | 15:21 |
| ssam2 | richard_maw: why? | 15:21 |
| ssam2 | can you think of a 'downstream' that would care? | 15:21 |
| richard_maw | no, but it would reduce the disk space used if they are using the standard mirroring rules, as it would delete any branches they haven't anchored themselves | 15:22 |
| richard_maw | and it would set a proper precedent for a procedure for removing repositories | 15:23 |
| ssam2 | i guess. could you do that then? | 15:23 |
| richard_maw | ssam2: ack, will do | 15:23 |
| paulsher1ood | can we distinguish be tween delta and others on gbo, please? | 15:23 |
| radiofree | jjardon: of course, it's never *quite* that simple, older versions of the sysboot command don't have support for "devicetree", so you'll have to replace "devicetree" in your extlinux.conf with "fdt" | 15:24 |
| paulsher1ood | istm that delta is the set we are mirroring, committing to reproducibly on | 15:24 |
| radiofree | or patch cmd_pxe.c in u-boot (one line fix) | 15:24 |
| jjardon | radiofree: dont worry, this thing doesn't support DT | 15:24 |
| paulsher1ood | most of the baserock/baserock upstreams seem to have moved to gerrit anyway? | 15:25 |
| straycat | they're just mirrored in gerrit | 15:25 |
| radiofree | wonderful, i suppose we should just used "fdt" in extlinx.conf files anyway, since you're not going to be using a device tree on x86 anyway.... | 15:25 |
| paulsher1ood | straycat: where do patches go? | 15:25 |
| straycat | to gerrit, the merged changes get pushed back into gbo | 15:25 |
| paulsher1ood | so upstream is gerrit, imo? :) | 15:26 |
| straycat | i wouldn't say so | 15:26 |
| * SotK thinks gbo is upstream and gerrit is a mechanism for merging patches into said upstream | 15:26 | |
| straycat | from the model of gerrit i looked at i would have thought the repos in gbo are our "authorative" repos, but maybe i misunderstood the model | 15:26 |
| paulsher1ood | maybe i'm wrong, then | 15:27 |
| SotK | I wouldn't do `morph checkout ssh://SotK@gerrit.baserock.org:29418/baserock/baserock/definitions master` for example | 15:27 |
| paulsher1ood | fair | 15:27 |
| *** gallit has quit IRC | 15:28 | |
| paulsher1ood | ssam2: what would you propose instead of 'this'? | 15:29 |
| SotK | paulsher1ood: something which describes what 'this' is | 15:30 |
| paulsher1ood | the-thing-im-currently-working-on? :) | 15:30 |
| richard_maw | what kind of thing is the thing you're working on? | 15:30 |
| paulsher1ood | a definition | 15:31 |
| * straycat suggests replacing all those dicts with classes that define what attributes things are supposed to contain | 15:31 | |
| richard_maw | then use `definition` | 15:31 |
| SotK | straycat: +1 | 15:31 |
| ssam2 | paulsher1ood: having a big dict of variables named 'this' is rather like naming all your functions do_stuff() | 15:31 |
| rjek | do_that() | 15:33 |
| paulsher1ood | ssam2: yup, i agree. but so is calling it a 'definition', from my pov, and definition has more chars | 15:33 |
| rjek | readability > source file size | 15:33 |
| SotK | if a function takes a parameter called `definition`, it is easier to understand how to call that function than if it takes a parameter called `this` | 15:34 |
| paulsher1ood | SotK: fair | 15:34 |
| paulsher1ood | rjek: it's hard to get an objective measure of readability. easier for code size | 15:35 |
| richard_maw | rjek: +∞ | 15:36 |
| rjek | paulsher1ood: Source code size is actually a measure of absolutely nothing, IME | 15:36 |
| rjek | Not readability, not maintainability, not performance. | 15:36 |
| *** zoli__ has quit IRC | 15:36 | |
| rjek | I'd rather a large, clear source code than a short magical one. | 15:36 |
| jmacs | I think there's some correlation though. | 15:37 |
| rjek | Sometimes, yes. | 15:37 |
| paulsher1ood | rjek: large and clear tend not to correlate very well in my expereince | 15:37 |
| rjek | But minimising source code size for the sake of terseness and against readability or maintainability is madness. | 15:37 |
| paulsher1ood | rjek: i agree. | 15:38 |
| robtaylor | https://www.cs.virginia.edu/~weimer/p/weimer-tse2010-readability-preprint.pdf | 15:38 |
| robtaylor | ;) | 15:38 |
| rjek | That paper looks interesting, and I have added it to my reading list | 15:39 |
| straycat | didn't anybody see the talk on K language at the os conference? everything is bloated, we cannot use big-O notation to reason about our programs, do *not* use hashtables... etc | 15:40 |
| rjek | That sounds... controversial. | 15:41 |
| jmacs | Nope, is it online? | 15:41 |
| jmacs | Or fictional? | 15:42 |
| straycat | https://www.youtube.com/watch?list=PLmRrx948XMnEUlzKOCYn3AzT8OAInP_5M&v=kTrOg19gzP4 | 15:42 |
| De|ta | :D | 15:42 |
| jmacs | Oh, him | 15:43 |
| rjek | Oh yes, I enjoyed that talk. | 15:43 |
| richard_maw | ok, ybd and remo repositories obsoleted | 15:44 |
| * robtaylor should watch justin cormak's talk, we keep crossing paths in cybersapce | 15:44 | |
| rjek | I also see Justin Cormack in that talk being an excellent microphone stand. | 15:45 |
| robtaylor | heh | 15:45 |
| richard_maw | I saw him do a talk once about writing an init system in lua, but now I can only picture him as Joe Lycett (a comedian) | 15:46 |
| Kinnison | Justin is a Loon, in all the right ways | 15:47 |
| * Kinnison likes him a lot | 15:47 | |
| pedroalvarez | mariadb - 400M of database.. | 15:49 |
| rjek | ! | 15:57 |
| pedroalvarez | it's just huge | 16:03 |
| pedroalvarez | I'm trying to remove +100M of tests | 16:03 |
| * richard_maw is less stressed about repositories being created in baserock/baserock now that we have a deprecation procedure that meets all my requirements | 16:05 | |
| richard_maw | sorry if I snapped at you paulsher1ood | 16:05 |
| richard_maw | s/if // | 16:05 |
| paulsher1ood | np | 16:08 |
| jmacs | OpenJDK 8 successfully built on baserock. | 16:12 |
| jmacs | (Not by morph yet, but it shouldn't be difficult) | 16:13 |
| paulsher1ood | w00t!! | 16:13 |
| rjek | jmacs: How many chickens, candels, and pentagrams? | 16:15 |
| ssam2 | jmacs: nice! is that using a binary JDK to bootstrap it? | 16:16 |
| jmacs | Yes, we need an existing JDK binary to bootstrap it | 16:16 |
| rjek | Boo. | 16:17 |
| * rjek wonders if jikes is still a thing. | 16:17 | |
| rjek | (Java compiler written in C++) | 16:17 |
| jmacs | It's not much different from needing GCC to build GCC. | 16:17 |
| rjek | You could at least once-upon-a-time bootstrap GCC from any C89 compiler. | 16:17 |
| jjardon | jmacs: great! | 16:18 |
| jmacs | Oh, you can bootstrap the JDK from any java compiler, too. But there's only two to choose from AFAIK :) | 16:18 |
| jjardon | jmacs: is it possible to compile openjdk with gcj? | 16:19 |
| jmacs | I thought gcj compiled directly to machine code | 16:20 |
| rjek | http://jikes.sourceforge.net/ perhaps? | 16:20 |
| rjek | I don't know if it's up-to-date enough | 16:20 |
| rjek | But it's a Java compiler that compiles to bytecode that isn't written in Java. | 16:20 |
| jmacs | OK, to be honest I haven't tried any other java compilers. | 16:20 |
| Kinnison | There *was* some work underway to allow a JDK to be bootstrapped via gcj | 16:21 |
| Kinnison | But I don't know how far that got | 16:21 |
| jmacs | I have built OpenJDK using only components in Debian 8, so I'm assuming for now that there would be no licence problems in us putting that JDK binary on git.baserock.org. That needs checking though. | 16:21 |
| rjek | It'd be nice in a purest sense to avoid binary blobs of unknown provenance, but the pragmatist in me says "meh" | 16:21 |
| jmacs | rjek: Again, this doesn't seem much worse than the GCC problem - we *could* build GCC with something other than GCC, but it hasn't been a high priority | 16:22 |
| *** jonathanmaw has quit IRC | 16:26 | |
| ssam2 | jmacs: there is a problem introducing new circular dependencies into the baserock reference systems, which persia explored at length last year (or maybe the year before) | 16:29 |
| ssam2 | it's cool that we can have Java built from source at all, it's a big step forward | 16:29 |
| ssam2 | but if the standard Baserock build-system suddenly needed a Java compiler to bootstrap it, the cross-bootstrap process would no longer work | 16:29 |
| ssam2 | we'll have to deal with the fact that we have more than one bootstrap method, I guess | 16:30 |
| jmacs | I wasn't planning on uploading the resulting SDK; I think we'll just have one reference version in git | 16:30 |
| ssam2 | right, so we have a stable JDK 7 that gets used to build whatever is the latest OpenJDK | 16:34 |
| ssam2 | seems good | 16:34 |
| ssam2 | this is my thoughts on new bootstrap methods from June 2014: http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2014-June/006594.html | 16:34 |
| * jmacs will have a read | 16:35 | |
| rdale | i'm working on a branch of definitions called 'baserock/rdale/openwrt', but i can no longer push to it | 16:39 |
| ssam2 | why not? | 16:39 |
| rdale | doh! i was accidently attempting to the master branch, sorry about the noise | 16:41 |
| pedroalvarez | :) | 16:41 |
| pedroalvarez | thanks gitano | 16:41 |
| Kinnison | pedroalvarez: It says you're welcome | 16:41 |
| * richard_maw is proud of http://paste.baserock.org/iwesagonot | 16:51 | |
| Kinnison | Erm | 16:51 |
| Kinnison | I'm not sure pride is the appropriate response | 16:51 |
| richard_maw | Kinnison: remember, I am evil | 16:52 |
| Kinnison | True | 16:52 |
| richard_maw | hmm, though I will have to do something about that -o condition | 16:52 |
| richard_maw | because it will lead to it attempting to strip libraries as if they were binaries if their -exec command fails | 16:53 |
| * Kinnison admits it's fairly compact | 16:54 | |
| richard_maw | it'll do to test the principle with an overnight build | 16:54 |
| Kinnison | the slpkg equivalent is longer, but I feel somewhat more readable :) | 16:55 |
| Kinnison | But it's also in Lua which helps you less | 16:55 |
| ssam2 | i think I would have preferred hardcoding the logic in the tool, but in a sane language | 16:57 |
| ssam2 | i doubt i will ever dare to touch that | 16:57 |
| *** gary_perkins has quit IRC | 17:00 | |
| * ssam2 wonders why ybd is only checking out half of gcc-tarball.git before trying to build it | 17:00 | |
| *** bashrc_ has quit IRC | 17:00 | |
| jmacs | Am I right in saying that we can't include one system in another? | 17:01 |
| ssam2 | at deploy time you can include one system in another | 17:01 |
| ssam2 | it build time you can't | 17:02 |
| jmacs | I noticed that you can have several systems in one cluster | 17:02 |
| radiofree | subsystems? | 17:02 |
| radiofree | if you had bar as a subsystem of foo, just make sure you build both foo and bar when you deploy | 17:03 |
| radiofree | s/when/before/ | 17:03 |
| jmacs | Well, in some clusters there's a system and a subsystem, and in other clusters there's two top-level systems | 17:03 |
| radiofree | jmacs: multiple systems in a single (e.g release) just deploy multiple systems | 17:04 |
| radiofree | a system with a subsystem add's that subsystem to the system | 17:04 |
| jmacs | Ah, now I see | 17:04 |
| jmacs | I want to make a java build system, which is devel-system with other stuff added in | 17:05 |
| jmacs | I'm not sure at the moment if a cluster is the best way to do that | 17:05 |
| jmacs | And I'm sure I'm not the first to point this out, but base, build and devel systems seem to be subsets | 17:07 |
| ssam2 | that's intentional | 17:09 |
| ssam2 | to create your java system, copy the list of strata from the devel system into a new system and add more | 17:10 |
| ssam2 | it might make a lot more sense if you could just embed one system in another :) | 17:10 |
| jmacs | Indeed, in most cases copy and pasting code is bad | 17:11 |
| ssam2 | there's way too much copy+paste in the current Baserock definitions | 17:12 |
| ssam2 | seems that Git itself is to blame for this weird checkout breakage. not sure why yet though | 17:15 |
| jmacs | I'll have a think about that over the weekend. The java build changes are on my github tli then. | 17:16 |
| ssam2 | adding --force to the 'git checkout' commandline has fixed the issue... it's really weird though | 17:21 |
| *** zoli__ has joined #baserock | 17:23 | |
| *** mariaderidder has quit IRC | 17:32 | |
| *** ssam2 has quit IRC | 17:43 | |
| *** lachlanmackenzie has quit IRC | 18:07 | |
| *** edcragg has quit IRC | 18:27 | |
| persia | jmacs: https://github.com/persia/debinject was my compromise for adding a circular dependency using Debian packages. The fpc branch is probably the interesting one to examine. | 18:56 |
| persia | The idea being that I had a script that would run against a cryptographcially verifiable Debian mirror (with user configuration) that I could post, which others could use to reliably reproduce my bootstrap activities. | 18:56 |
| persia | The review procedure then being 1) run my branch of debinject, 2) build a devel system including the new bootstrap chunks, 3) publish that devel system, 4) encourage others to upgrade. | 19:02 |
| persia | Unfortunately, at the time, there was an issue with the tooling that it wasn't possible to upgrade to a system that could not be built from the system that you were running. I haven't checked to see if that got fixed in the various improvements we've had over time: I *think* that one can download a cache image that one cannot bootstrap, but I'm not sure. | 19:02 |
| persia | That said, I also investigated the Debian Java bootstrap process: it is perfectly replicable in baserock, if we want to do that. | 19:02 |
| persia | The only outstanding issue is that I could not find a reliable upstream for the ecj components that were used by Debian, and I was uncomfortable with the idea of lorrying a tarball from the Debian repos for bootstrap purposes. | 19:02 |
| *** zoli__ has quit IRC | 19:30 | |
| *** zoli__ has joined #baserock | 19:53 | |
| *** zoli__ has quit IRC | 19:56 | |
| *** zoli__ has joined #baserock | 21:48 | |
| jmacs | Thanks persia. I didn't have a chance to look into what Debian does to make its java package. I'll take a look at your repo. | 22:39 |
| *** zoli__ has quit IRC | 23:21 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!