IRC logs for #baserock for Thursday, 2015-05-28

*** wdutch has quit IRC01:34
*** wdutch has joined #baserock01:34
*** wdutch has quit IRC03:34
*** wdutch has joined #baserock03:35
*** zoli__ has joined #baserock05:14
*** zoli__ has quit IRC05:36
*** zoli__ has joined #baserock07:05
*** bashrc_ has joined #baserock08:05
*** edcragg has joined #baserock08:15
*** gary_perkins has joined #baserock08:20
*** jonathanmaw has joined #baserock08:34
*** ssam2 has joined #baserock08:48
*** ChanServ sets mode: +v ssam208:48
jmacsI'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
Kinnisonif you've said build-system: manual  (and remembered to refer to the chunk .morph file from your stratum) then it really shouldn't use autotools09:09
jmacsThat's probably it, I was missing the morph: line in the stratum09:12
pedroalvarezoh, the obscure magic of autodetection09:12
Kinnisonjmacs: glad to be of service :)09:14
jmacsThank you.09:17
*** lachlanmackenzie has joined #baserock09:20
*** tiagogomes has quit IRC09:23
KinnisonAnyone 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
Kinnisonaha, I remove myself from the reviewers list09:24
Kinnisonyay09:24
pedroalvarezgertty ftw!09:24
pedroalvarezis anybody else using it?09:25
Kinnisondoes it let you do individual commenting?09:25
pedroalvarez"individual commenting" == inline comments?09:25
Kinnisonyes09:26
pedroalvarezI believe you can do everything you already do in the web UI09:26
Kinnisonoooh nice09:26
richard_mawunfortunately, while it looks like mutt, the keyboard shortcuts aren't the same09:27
*** 20WABCVSQ has joined #baserock09:27
KinnisonMy mutt is already heavily customised :)09:27
pedroalvarezthe only thing I miss being able to search for text in a diff09:29
pedroalvarezor patchset09:29
richard_mawI prefer how the web ui presents the diffs09:29
*** mariaderidder has joined #baserock09:59
*** gary_perkins has quit IRC10:09
*** gary_perkins_ has joined #baserock10:09
ssam2has anyone built 'master' of definitions with 'ybd' recently?10:11
ssam2I'm getting:  [ansible] ERROR: recursion loop for ansible10:12
ssam2running: python ../ybd/ybd.py systems/build-system-x86_64.morph x86_6410:12
mwilliams_ctHi 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
radiofree9f107132a6a073cce37434ca9cda6917dd8d866b is correct for 1.5.110:18
radiofreehttp://git.baserock.org/cgi-bin/cgit.cgi/delta/mtd-utils.git/commit/?id=9f107132a6a073cce37434ca9cda6917dd8d866b10:18
SotKmwilliams_ct: use the commit SHA, not the tag SHA :)10:19
mwilliams_ctOK so the answer is to use the commit hash rather than the tag name hash. I'll try and document that somewhere10:19
mwilliams_ctthanks SotK radiofree :)10:19
ssam2the 'always use the commit SHA1' policy should be here: http://wiki.baserock.org/policies/10:21
ssam2i'm kind of surprised that it isn't :)10:21
jmacsThe meaning of +1 and -1 on the policies page is at odds with gerrit's documentation10:24
ssam2oh, yes, I guess that hasn't been updated since we switched to Gerrit10:24
KinnisonI imagine we've failed to amend the policy to fit with gerrit's approach10:24
mwilliams_ctI've added a section about strata versions. I've not done much work on upstream Baserock so it needs sanity checking10:25
jmacsI can copy the meaning from gerrit's documentation into that section, if people are happy with that10:26
ssam2is it possible to link to Gerrit's documentation directly?10:27
Kinnisonmwilliams_ct: I'd prefer 'Versioning in Strata' or "Use of 'ref:' in Strata"10:27
jmacsYes, I was planning to link to it and include a summary10:27
ssam2cool, that's fine by me then10:27
Kinnisonmwilliams_ct: "Strata versions" is a painfully confusing combination of plurals10:27
mwilliams_ctGo for it. I am not picky about being corrected, hence my request for review10:28
KinnisonHeh10:28
* Kinnison hopes whoever edits the page for gerrit +1/-1 policy will amend that title too :)10:28
ssam2mwilliams_ct: looks fine other than it should be 'stratum versions', thanks10:31
jmacsKinnison: Too late, sorry10:36
jmacsWell, not really, fixed now10:37
*** gary_perkins_ has quit IRC10:38
Kinnison:)10:38
jmacsI think we should avoid using nouns with latin pluralisation rules as component names10:38
DavePagejmacs: And use Greek ones instead? :)10:40
jmacsNo, DavePage.10:40
ssam2jmacs: your change to the wiki looks good, thanks for doing it10:40
wdutchstratapodes10:42
*** inara has quit IRC10:48
jmacsWhat's the difference between DESTDIR and PREFIX? Is there a good reason I shouldn't say "./configure --prefix="$DESTDIR$PREFIX" ?10:53
KinnisonDESTDIR is only for install10:54
radiofreei don't think you should do that10:54
KinnisonDESTDIR tells 'make install' what to shove on the front10:54
KinnisonPREFIX tells the build where it will be when on the target10:54
radiofreee.g mycomponent.install/10:54
jmacsRight, but is DESTDIR something built into make or a convention?10:54
Kinnisonconvention10:54
Kinnisonas is PREFIX10:54
jmacsMakes sense10:56
*** gary_perkins has joined #baserock10:58
Kinnisonc/win 2910:58
*** inara has joined #baserock10: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-prefix10:59
radiofreeannoyingly qmake turns DESTDIR= into INSTALL_ROOT=11:00
jmacsI'm dealing with CUPS at the moment, which wants BUILDROOT instead of DESTDIR, which is an unhelpful name11:02
jmacsDo lorry requests go via gerrit or mailing list now?11:09
radiofreegerrit11:13
radiofreehttps://gerrit.baserock.org/#/admin/projects/baserock/local-config/lorries11:13
ratmice___jmacs: DSTROOT no? Makedefs.in:BUILDROOT = $(DSTROOT)11:15
*** inara has quit IRC11:15
jmacsratmice___: The INSTALL.txt tells me to use BUILDROOT.11:16
*** inara has joined #baserock11:18
jmacsradiofree: Cheers. For some reason none of the patches in that project show up when you search for 'lorry'11:19
ZaraI'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
ssam2zara: libgcc is usually quite important11:25
ssam2zara: libfortran is not, unless you want to run fortran programs11:25
ssam2you 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 properly11:25
ssam2Baserock could do with some improvement in that regard11:26
*** inara has quit IRC11:27
ssam2alternatively you could write a .configure extension to delete the files you don't want, which is quite easy11:28
Zarahehe, 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
ssam2Zara: i tried to write a bit about deploy-time extensions here: http://wiki.baserock.org/definitions/current/#index4h211:33
ssam2they 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 whatever11:34
*** inara has joined #baserock11:34
ssam2but 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
radiofreeouch11:35
Zara:0 I may look into the splitting rules for now...11:36
ssam2it's not as bad as it sounds11:36
Zaraheh, 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
radiofreewhich had to be run as root11:40
Zaraeep11:40
pedroalvarezZara: you need to be careful11:42
pedroalvarez(about the path)11:43
*** inara has quit IRC11:45
Zaragreat, thanks everyone. I will read up and be very careful. :)11:46
ssam2as long as you run it in a baserock chroot or vm the worst that happens is you destroy the chroot or vm, anyway11:48
richard_mawssam2: unless you bind-mount your host fs into your chroot11:49
richard_mawyou can break your host if you do that11:49
ZaraI sacrificed a lot to obtain this chroot and a bind-mount was done at some point.11:49
pedroalvarezjmacs: I left a comment in your CUPS lorry patch11:49
ssam2richard_maw: true. I deleted most of my /src directory recently using `manage-baserock rm`11:50
richard_mawouch11:50
ssam2which was bind-mounted in from the host11:50
*** inara has joined #baserock11:56
Zarabtw, 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 invol12:14
richard_mawZara: build-essential-{runtime,devel} are default rules12:16
richard_mawZara: when there's a colon involved its explicit assignment of an artifact produced by a chunk build to a stratum artifact12:16
richard_mawin the `products:` section there's more generic match rules by artifact name12:17
*** inara has quit IRC12:17
*** inara has joined #baserock12:20
Zararichard_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_mawZara: you are completely correct12:25
Zaraahhh, 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
Zaraahhh, and these libs are all from gcc-libs12:33
Zaraam 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
jmacsHaving "essential" and "minimal" in a stratum name seems redundant12:46
Zarabuild-essential is the stratum, and build-essential-minimal is the artifact, but it does suggest that one name is misleading12:48
mwilliams_ctSotK: 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
SotKhmm, I thought that the idea was that build-system-*.morph each contained the same things as far as possible, but maybe I'm wrong13:08
SotKI don't particularly mind either way13:08
mwilliams_ctif that is the case then youre definitely right to suggest it's added. new thing to me so not sure13:09
SotKI also notice that the other build systems contain some things that the openBMC one doesn't (ansible + openstack stuff mostly afaict)13:10
Zarawould 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_ctSotK: hmm, jjardon could probably comment in that case, he's to git blame13:14
jjardonSotK: yes, that was intentional; we do not need anything of that13:17
SotKit 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 this13: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 documentation13:21
jjardonSotK: sure, but note the name is build-system-armv5l-openbmc-aspeed, not build-system-armv5l-generic13:22
radiofreeppc devel systems are different to x86/arm13:23
radiofree(node.js)13:23
jjardonhappy 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 us13:24
* SotK doesn't really mind very much either way13:25
SotKradiofree: is that an oversight or does node.js not build on ppc?13:25
radiofreedoesn't build13:26
*** rdale has quit IRC13:29
SotKI see13:32
SotKI 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-aspeed13:32
*** gallit has joined #baserock13:46
*** zoli__ has quit IRC14:18
*** rdale has joined #baserock14:19
jmacsHmm, this is new: "Cannot change ownership to uid 10, gid 143: Operation not permitted" during an untar14:25
paulsher1oodssam2: afaict no recursion loop on ansible for me, using master ybd and master definitions14:26
Kinnisonjmacs: within a build?14:26
jmacsKinnison: Within an install. It's running tar zxf jdk-8u20-linux-x64.tar.gz -C "$DESTDIR$PREFIX"/lib14:28
jmacsThis used to work; I can't figure out what's changed14:28
Kinnisonjmacs: I think that within builds, chown/chgrp aren't allowed (capabilities dropped by linux-user-chroot)14:30
jmacsmorph 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
pedroalvarezjmacs: I've seen that in the past14:32
franredjmacs, does tar try to keep the owner of the jdk files?14:32
pedroalvareztar is trying to set the owner and the group14:32
rjek--no-same-owner14:32
rjek(If you use tar as root, it will try to apply the original ownership by default)14:32
pedroalvarezthis "error" is new, because before we were using busybox tar14:33
jmacsaah, good point14:34
*** zoli__ has joined #baserock14:34
pedroalvarezwe could just use `busybox tar` instead of using `--no-same-owner`14:37
jmacsI think using --no-same-owner makes it clearer what's going on14:37
ssam2paulsher1ood: building build-system-x86-64.morph ?14:45
ssam2paulsher1ood: It seems to build minimal-system OK, just not build-system14:45
paulsher1oodssam2: i believe so - http://paste.baserock.org/ojulixetuf14:47
pedroalvarezmeh, we are having problems with OpenStack and pgsql... :/14:48
ssam2paulsher1ood: 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 commits14:53
paulsher1oodah14:53
paulsher1oodsorry about that14:54
paulsher1oodmaybe worth deleting that repo to avoid confusion14:54
ssam2yes, if you're not using it, would make sense14:55
paulsher1oodi put it there temporarily, when i had access problems on github14:56
jjardonHi, I see BOOT_DEVICE in some cluster files. What extension handles this? I can not see anything in the definitions or morph repos14:56
* paulsher1ood assumes he doesn't have powers to delete a repo from gbo14:56
richard_mawjjardon: look at writeexts.py14:57
radiofreejjardon: it's use for system-version-manager14:58
radiofreeso.. look in tbdiff14:58
jjardonah, here you are, thanks radiofree15:01
* richard_maw is unhappy with paulsher1ood creating repositories on git.baserock.org without asking, as they get mirrored to all our downstream users15:03
*** mariaderidder has quit IRC15:04
straycatwhy wouldn't gbo ybd lorry from github?15:05
richard_mawit wasn't lorried15:05
richard_mawif it were lorried, at least it would be up to date now15:05
jjardonso, any idea how to set the ROOT_DEVICE if you are not planning on use syslinux?15:06
straycatokay15:06
radiofreejjardon: what do you mean?15:06
paulsher1oodstraycat: good idea. i put it as a baserock/baserock project in desperation one day when i couldn't get to github15:06
radiofreeROOT_DEVICE: /dev/whateveryouwantittobe15:06
radiofreehttp://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/clusters/jetson-upgrade.morph15:07
radiofreeBOOT_DEVICE is only useful when your u-boot has the "sysboot" command15:08
*** straycat is now known as shockedcat15:08
* shockedcat is shocked15:08
rjek:)15:08
paulsher1ood?15:08
jjardonradiofree: 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 straycat15:09
straycatit 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_mawstraycat: there's no lorry to mark as obsolete15:10
richard_mawit's not delta/ybd, it's baserock/baserock/ybd15:11
straycati know15:11
straycatbut we can put "obsolete" in its description?15:11
richard_mawoh, I misread you, sorry15:11
paulsher1oodwhy not just delete it?15:11
richard_mawI'd rather be rid of it entirely and ban paulsher1ood from creating repositories15:11
straycatwe could also just delete it15:11
straycathrm, i don't think we need to resort to that, to be fair15:12
paulsher1ood:)15:12
radiofreejjardon: i still don't know what you mean15:13
radiofreejetson uses u-boot15:13
richard_mawstraycat: if it were the first offence I'd agree, but paulsher1ood has also pushed through lorries without consultation too15:13
radiofreeROOT_DEVICE changes the kernel args (root=$ROOT_DEVICE) instead of hard-coding to /dev/sda15:13
richard_mawwhich was annoying, because we already *had* that lorried under a different name15:13
radiofreejjardon: u-boot can support reading an extlinux.conf file15:13
radiofreeif your u-boot can't do that, then ROOT_DEVICE and BOOT_DEVICE are useless, and you'll have to do it all manually anyway15:14
paulsher1oodrichard_maw: i'm sure i'm not the only person to make mistakes, here15:14
radiofreei.e just extract a tarball to your emmc, or dd it over...15:14
paulsher1oodrichard_maw:  plus, i don't think creating ybd as a baserock/baserock project actually violated any policy?15:16
richard_mawpaulsher1ood: I know that, and if I'd done the same I'd expect to have some form of disciplinary action on myself15:16
* richard_maw is just frustrated15:16
* paulsher1ood is sorry that richard_maw is frustrated15:16
jjardonradiofree: 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 now15:17
radiofreejjardon: the jetson doesn't use extlinux15:18
ssam2i'll delete baserock/baserock/ybd tomorrow unless anyone feels strongly that I shouldn't15:18
*** mariaderidder has joined #baserock15:18
radiofreejjardon: 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 way15:18
paulsher1ood+1 for the delete15:18
jjardonradiofree: oh, ok. That makes everything much more clear now15:19
radiofreeonly for x86 systems do you call "extlinux --install"15:19
richard_mawssam2: how about remo? Possibly the same15:19
pedroalvarezwhat's that?15:19
straycati'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 gitano15:19
richard_mawpedroalvarez: another of paulsher1ood's repositories15:19
* ssam2 does want to ban paulsherwood from naming variables 'this', however15:20
straycatheh15:20
SotK:)15:20
radiofreejjardon: if you check a jetson cluster you'll see   BOOTLOADER_CONFIG_FORMAT: "extlinux" and  BOOTLOADER_INSTALL: "none"15:20
radiofreeso generate an extlinux config file, but don't bother installing extlinux15:20
paulsher1oodremo was the repo i used to explain ssome restructuring of morphs....15:20
radiofreeif you can build u-boot for whatever device you're deploying you it should be fairly simple to add the sysboot command15:20
richard_mawssam2: 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 removed15:20
richard_mawssam2: after some period we can remove the repository15:21
ssam2richard_maw: why?15:21
ssam2can you think of a 'downstream' that would care?15:21
richard_mawno, 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 themselves15:22
richard_mawand it would set a proper precedent for a procedure for removing repositories15:23
ssam2i guess. could you do that then?15:23
richard_mawssam2: ack, will do15:23
paulsher1oodcan we distinguish be tween delta and others on gbo, please?15:23
radiofreejjardon: 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
paulsher1oodistm that delta is the set we are mirroring, committing to reproducibly on15:24
radiofreeor patch cmd_pxe.c in u-boot (one line fix)15:24
jjardonradiofree: dont worry, this thing doesn't support DT15:24
paulsher1oodmost of the baserock/baserock upstreams seem to have moved to gerrit anyway?15:25
straycatthey're just mirrored in gerrit15:25
radiofreewonderful, 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
paulsher1oodstraycat: where do patches go?15:25
straycatto gerrit, the merged changes get pushed back into gbo15:25
paulsher1oodso upstream is gerrit, imo? :)15:26
straycati wouldn't say so15:26
* SotK thinks gbo is upstream and gerrit is a mechanism for merging patches into said upstream15:26
straycatfrom the model of gerrit i looked at i would have thought the repos in gbo are our "authorative" repos, but maybe i misunderstood the model15:26
paulsher1oodmaybe i'm wrong, then15:27
SotKI wouldn't do `morph checkout ssh://SotK@gerrit.baserock.org:29418/baserock/baserock/definitions master` for example15:27
paulsher1oodfair15:27
*** gallit has quit IRC15:28
paulsher1oodssam2: what would you propose instead of 'this'?15:29
SotKpaulsher1ood: something which describes what 'this' is15:30
paulsher1oodthe-thing-im-currently-working-on? :)15:30
richard_mawwhat kind of thing is the thing you're working on?15:30
paulsher1ooda definition15:31
* straycat suggests replacing all those dicts with classes that define what attributes things are supposed to contain15:31
richard_mawthen use `definition`15:31
SotKstraycat: +115:31
ssam2paulsher1ood: having a big dict of variables named 'this' is rather like naming all your functions do_stuff()15:31
rjekdo_that()15:33
paulsher1oodssam2: yup, i agree. but so is calling it a 'definition', from my pov, and definition has more chars15:33
rjekreadability > source file size15:33
SotKif 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
paulsher1oodSotK: fair15:34
paulsher1oodrjek: it's hard to get an objective measure of readability. easier for code size15:35
richard_mawrjek: +∞15:36
rjekpaulsher1ood: Source code size is actually a measure of absolutely nothing, IME15:36
rjekNot readability, not maintainability, not performance.15:36
*** zoli__ has quit IRC15:36
rjekI'd rather a large, clear source code than a short magical one.15:36
jmacsI think there's some correlation though.15:37
rjekSometimes, yes.15:37
paulsher1oodrjek: large and clear tend not to correlate very well in my expereince15:37
rjekBut minimising source code size for the sake of terseness and against readability or maintainability is madness.15:37
paulsher1oodrjek: i agree.15:38
robtaylorhttps://www.cs.virginia.edu/~weimer/p/weimer-tse2010-readability-preprint.pdf15:38
robtaylor;)15:38
rjekThat paper looks interesting, and I have added it to my reading list15:39
straycatdidn'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... etc15:40
rjekThat sounds... controversial.15:41
jmacsNope, is it online?15:41
jmacsOr fictional?15:42
straycathttps://www.youtube.com/watch?list=PLmRrx948XMnEUlzKOCYn3AzT8OAInP_5M&v=kTrOg19gzP415:42
De|ta:D15:42
jmacsOh, him15:43
rjekOh yes, I enjoyed that talk.15:43
richard_mawok, ybd and remo repositories obsoleted15:44
* robtaylor should watch justin cormak's talk, we keep crossing paths in cybersapce15:44
rjekI also see Justin Cormack in that talk being an excellent microphone stand.15:45
robtaylorheh15:45
richard_mawI 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
KinnisonJustin is a Loon, in all the right ways15:47
* Kinnison likes him a lot15:47
pedroalvarezmariadb - 400M of database..15:49
rjek!15:57
pedroalvarezit's just huge16:03
pedroalvarezI'm trying to remove +100M of tests16:03
* richard_maw is less stressed about repositories being created in baserock/baserock now that we have a deprecation procedure that meets all my requirements16:05
richard_mawsorry if I snapped at you paulsher1ood16:05
richard_maws/if //16:05
paulsher1oodnp16:08
jmacsOpenJDK 8 successfully built on baserock.16:12
jmacs(Not by morph yet, but it shouldn't be difficult)16:13
paulsher1oodw00t!!16:13
rjekjmacs: How many chickens, candels, and pentagrams?16:15
ssam2jmacs: nice! is that using a binary JDK to bootstrap it?16:16
jmacsYes, we need an existing JDK binary to bootstrap it16:16
rjekBoo.16:17
* rjek wonders if jikes is still a thing.16:17
rjek(Java compiler written in C++)16:17
jmacsIt's not much different from needing GCC to build GCC.16:17
rjekYou could at least once-upon-a-time bootstrap GCC from any C89 compiler.16:17
jjardonjmacs: great!16:18
jmacsOh, you can bootstrap the JDK from any java compiler, too. But there's only two to choose from AFAIK :)16:18
jjardonjmacs: is it possible to compile openjdk with gcj?16:19
jmacsI thought gcj compiled directly to machine code16:20
rjekhttp://jikes.sourceforge.net/ perhaps?16:20
rjekI don't know if it's up-to-date enough16:20
rjekBut it's a Java compiler that compiles to bytecode that isn't written in Java.16:20
jmacsOK, to be honest I haven't tried any other java compilers.16:20
KinnisonThere *was* some work underway to allow a JDK to be bootstrapped via gcj16:21
KinnisonBut I don't know how far that got16:21
jmacsI 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
rjekIt'd be nice in a purest sense to avoid binary blobs of unknown provenance, but the pragmatist in me says "meh"16:21
jmacsrjek: 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 priority16:22
*** jonathanmaw has quit IRC16:26
ssam2jmacs: 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
ssam2it's cool that we can have Java built from source at all, it's a big step forward16:29
ssam2but if the standard Baserock build-system suddenly needed a Java compiler to bootstrap it, the cross-bootstrap process would no longer work16:29
ssam2we'll have to deal with the fact that we have more than one bootstrap method, I guess16:30
jmacsI wasn't planning on uploading the resulting SDK; I think we'll just have one reference version in git16:30
ssam2right, so we have a stable JDK 7 that gets used to build whatever is the latest OpenJDK16:34
ssam2seems good16:34
ssam2this is my thoughts on new bootstrap methods from June 2014: http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2014-June/006594.html16:34
* jmacs will have a read16:35
rdalei'm working on a branch of definitions called 'baserock/rdale/openwrt', but i can no longer push to it16:39
ssam2why not?16:39
rdaledoh! i was accidently attempting to the master branch, sorry about the noise16:41
pedroalvarez:)16:41
pedroalvarezthanks gitano16:41
Kinnisonpedroalvarez: It says you're welcome16:41
* richard_maw is proud of http://paste.baserock.org/iwesagonot16:51
KinnisonErm16:51
KinnisonI'm not sure pride is the appropriate response16:51
richard_mawKinnison: remember, I am evil16:52
KinnisonTrue16:52
richard_mawhmm, though I will have to do something about that -o condition16:52
richard_mawbecause it will lead to it attempting to strip libraries as if they were binaries if their -exec command fails16:53
* Kinnison admits it's fairly compact16:54
richard_mawit'll do to test the principle with an overnight build16:54
Kinnisonthe slpkg equivalent is longer, but I feel somewhat more readable :)16:55
KinnisonBut it's also in Lua which helps you less16:55
ssam2i think I would have preferred hardcoding the logic in the tool, but in a sane language16:57
ssam2i doubt i will ever dare to touch that16:57
*** gary_perkins has quit IRC17:00
* ssam2 wonders why ybd is only checking out half of gcc-tarball.git before trying to build it17:00
*** bashrc_ has quit IRC17:00
jmacsAm I right in saying that we can't include one system in another?17:01
ssam2at deploy time you can include one system in another17:01
ssam2it build time you can't17:02
jmacsI noticed that you can have several systems in one cluster17:02
radiofreesubsystems?17:02
radiofreeif you had bar as a subsystem of foo, just make sure you build both foo and bar when you deploy17:03
radiofrees/when/before/17:03
jmacsWell, in some clusters there's a system and a subsystem, and in other clusters there's two top-level systems17:03
radiofreejmacs: multiple systems in a single (e.g release) just deploy multiple systems17:04
radiofreea system with a subsystem add's that subsystem to the system17:04
jmacsAh, now I see17:04
jmacsI want to make a java build system, which is devel-system with other stuff added in17:05
jmacsI'm not sure at the moment if a cluster is the best way to do that17:05
jmacsAnd I'm sure I'm not the first to point this out, but base, build and devel systems seem to be subsets17:07
ssam2that's intentional17:09
ssam2to create your java system, copy the list of strata from the devel system into a new system and add more17:10
ssam2it might make a lot more sense if you could just embed one system in another :)17:10
jmacsIndeed, in most cases copy and pasting code is bad17:11
ssam2there's way too much copy+paste in the current Baserock definitions17:12
ssam2seems that Git itself is to blame for this weird checkout breakage. not sure why yet though17:15
jmacsI'll have a think about that over the weekend. The java build changes are on my github tli then.17:16
ssam2adding --force to the 'git checkout' commandline has fixed the issue... it's really weird though17:21
*** zoli__ has joined #baserock17:23
*** mariaderidder has quit IRC17:32
*** ssam2 has quit IRC17:43
*** lachlanmackenzie has quit IRC18:07
*** edcragg has quit IRC18:27
persiajmacs: 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
persiaThe 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
persiaThe 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
persiaUnfortunately, 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
persiaThat said, I also investigated the Debian Java bootstrap process: it is perfectly replicable in baserock, if we want to do that.19:02
persiaThe 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 IRC19:30
*** zoli__ has joined #baserock19:53
*** zoli__ has quit IRC19:56
*** zoli__ has joined #baserock21:48
jmacsThanks 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 IRC23:21

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!