IRC logs for #baserock for Monday, 2015-02-23

*** zoli__ has joined #baserock01:28
*** zoli__ has quit IRC01:33
*** zoli__ has joined #baserock03:52
*** zoli__ has quit IRC04:13
*** petefoth has joined #baserock07:31
*** mike has joined #baserock07:39
*** mike is now known as Guest1099807:40
*** a1exhughe5 has joined #baserock07:57
*** mdizzle has joined #baserock08:45
*** sambishop has joined #baserock08:55
petefothWhat is the status of Is it sefae to trust it with data, or do we need to keep backups elsewhere in case of resets?09:00
pedroalvarezI believe that its status hasn't changed, so I dare say ssam2 would say we can't trust it  yet.09:03
petefothpedroalvarez: thanks09:03
*** bashrc has joined #baserock09:04
*** gary_perkins has joined #baserock09:18
*** jonathanmaw has joined #baserock09:18
*** tiagogomes_ has joined #baserock09:32
*** CTtpollard has joined #baserock09:35
*** paulw has joined #baserock09:49
*** paulwaters_ has quit IRC09:49
*** Krin has joined #baserock09:54
*** ssam2 has joined #baserock09:58
*** ChanServ sets mode: +v ssam209:58
petefothHow do I go about getting the 'copyright' and 'licnce' plugins installed / enabkled on wiki.baserockorg ( and
ssam2ask one of the ops09:58
ssam2I can have a look for you09:58
petefothssam2: thanks09:59
*** 17SABV5BT has joined #baserock10:01
*** 6JTAAHO77 has joined #baserock10:01
*** zoli__ has joined #baserock10:04
richard_mawpedroalvarez: doesn't cvs-fast-export require you to somehow fetch the whole cvs repository (that was the problem with using svn-fast-export)10:05
ssam2petefoth: neither of those plugins seem available in Branchable. so I'm not sure if or how we can install them10:06
pedroalvarezrichard_maw: hm.. maybe.. I just found "Warning: this project has been end-of-lifed due to severe and apparently incurable weaknesses in the code. " in cvsps repo10:07
ssam2petefoth: are they important? if so, I'll dig a bit deeper10:07
petefothssam2: OK thanks. Do you know if the 'meta' plugin ( is installed at branchable?10:08
ssam2meta is installed and enabled10:08
*** lachlanmackenzie has joined #baserock10:09
Kinnisonpetefoth: those plugins belong to the hurd's website10:09
petefothssam2: tA1> I'll get on with trying to make ti work for the copyrigt and licence then10:09
petefothKinnison: Sorry - I should have spotted that10:09
Kinnisonpetefoth: We could simply alter the outer page template10:09
Kinnisonpetefoth: to include a copyright and licence statement10:10
petefothKinnison: there's som bolierplate in the current template - \I'll look into activating it with the correct text10:10
Kinnisonalthough the page template we have already contains such10:11
petefothKinnison: I believe I have to use some magic with the meta plugin to set the vcriables that the current template uses10:12
KinnisonThat's a contrib plugin so is unlikely to be on branchable10:13
*** lachlanmackenzie has quit IRC10:13
* petefoth doesn't unsderstand - which is not news :)10:14
KinnisonSadly Jon's defaultmeta stuff doesn't seem to have made it in either10:15
KinnisonMay be easier to just edit page.tmpl to put your copyright content in unconditionally10:15
* petefoth will do that10:15
*** wschaller has joined #baserock10:23
*** wschaller_ has joined #baserock10:24
*** wschaller has quit IRC10:24
*** 6JTAAHO77 has quit IRC10:26
*** lachlanmackenzie has joined #baserock10:29
*** zoli__ has quit IRC10:37
*** zoli__ has joined #baserock10:37
jjardonHi! any idea what happened with the icu-svn repo?
ssam2I think it was lorried, then we found that it was never going to complete10:44
ssam2I think their SVN server is broken or way too slow10:44
ssam2so we should remove it10:44
ssam2shall I remove it now? anyone mind?10:45
paulsherwoodjjardon: maybe this is master now?
franredjjardon, have you tried to lorry that repo into your devel-system? (to discard that the svn server is broken)10:51
*** zoli__ has quit IRC10:52
paulsherwoodssam2: i think we should remove that, but also track down where the git master is10:52
*** zoli__ has joined #baserock10:53
ssam2franred: I tried lorrying it when radiofree proposed it. I found that the repo was growing in size, slowly10:53
ssam2maybe 1 or 2 MB a minute10:53
ssam2so I figured it'd be ok, but clearly it's not10:53
jjardonfranred: my devel system? if you mean if I have a trove in my personal laptop, I dont10:54
radiofreepaulsherwood: that's ICU + chromium patches10:54
radiofreeI don't think the ICU project use git10:54
franredjjardon, if you have a updated devel system you should have lorry on it, so you can try to lorry the repositories before sending the lorry patch10:54
jjardonpaulsherwood: chromium tends to fork every project instead use upstream, but maybe I do not know10:55
franrednot need to be a trove10:55
radiofreejjardon: I got your branch to build10:55
radiofreeI needs py3cairo though10:55
jjardonfranred : ah, ok. But no I do not have a devel system neither10:56
radiofreeAnd caribou needed PYTHON=python3 set before configure10:56
radiofreeMesa also needs enabel-shared-glapi for cogl to work with wayland10:56
jjardonradiofree: it compiles fine here, seems a bug in caribou configure checks?10:57
radiofreeI don't see how it could compile fine10:58
radiofreePygobject needs py3cairo to compile10:58
radiofreeMaybe this is because I added python3 as a build dep of the entire stratum?10:58
radiofreeYou forgot to include your python morph10:59
pedroalvarezre icu-svn, took serveral hours and 1G to lorry it10:59
radiofreeAlso remove ogg and vorbis now you've added them to multimedia common10:59
jjardonradiofree: probably, I only use python3 to build gnome-shell11:00
*** straycat has joined #baserock11:00
straycatcan we stop putting system artifacts on the cache11:01
straycatit slows building a system down generally11:01
pedroalvarezstraycat: you have already asked that in t he past. Is not that easy :/11:02
radiofreeThat's only if 'building for python3' I suppose it detected it on the system11:02
*** zoli__ has quit IRC11:03
straycatpedroalvarez: i know but i've been waiting 10 mins to download an artifact i can construct in < 5, even just a cronjob to rm *rootfs would be better than this11:03
*** zoli__ has joined #baserock11:06
straycat2015-02-23 10:50:47 [Build 218/218] [devel-system-x86_64-generic] Fetching to local cache: artifact devel-system-x86_64-generic-rootfs11:06
straycat2015-02-23 11:05:59 [Build 218/218] [devel-system-x86_64-generic] system devel-system-x86_64-generic-rootfs is cached at /src/cache/artifacts/5dbae98cdee4f4e04ba03b4d36fcdcd93e5cd023717b8b22df1d53755dc568d9.system.devel-system-x86_64-generic-rootfs11:06
pedroalvarezwell, I have to say that one day I enjoyed we had system artifacts there, when I deployed an armv7 system from x86 without building it11:07
straycatokay, but in the general case it sucks11:07
pedroalvarezstraycat: also, you could have skipped the whole build. Maybe you could have saved some minutes building..11:08
pedroalvarezanyway, my opinion is that this should be a morph option11:09
ssam2straycat: it would be nice to not have them in the cache, since they are huge11:09
ssam2could be distbuild option to say 'don't upload the system artifact'11:09
pedroalvarezthat is also true11:09
ssam2but could equally be a morph option to say 'don't download system artifacts'11:09
persiaI like them in the cache because it means all my deployments are from the same blob11:09
ssam2seems more /correct/ to me to make it a local morph option to not download them11:10
persiaCould we do something with remote binary correction?  Essentially using local objects to reduce the transfer of the system?11:10
jjardonradiofree: not sure we need the enable-shared-glapi option? we are not building support for gles111:10
radiofreeWere not? Glesv2?11:11
radiofreeIt was either that or adding nouveau to the DRI list for arm11:12
ssam2persia: actually SotK is doing work right now to make this problem go away11:12
jjardonradiofree: gles2 yes, but seems shared-glapi is only needed if you build both gles1 and gles211:12
persiassam2: What "problem"?11:12
radiofreeWhy is DRI drivers set to no for arm?11:12
ssam2persia: the problem that system artifacts contain largely duplicate data11:12
ssam2and thus are big and slow but contain little new info compared to the constituent chunk artifacts11:13
ssam2slow to transfer, I mean11:13
radiofreejjardon: cogl didn't work without one of those changes to mesa11:13
persiaAh, cool.  That sounds like the right way to do it.  Solves straycat's slow-to-download issue & my desire to have binary identity.11:14
jjardonradiofree: it does work in my vm. Are you testing in real hardware?11:14
radiofreeYes of course11:14
radiofreeBy works I mean the demos11:15
radiofreeRunning the examples in weston11:15
radiofreeIt compiles fine11:15
radiofreeIs that what you mean by work as well?11:16
jjardonradiofree: I runned mutter here11:19
petefothso I've pushed a couple of changes to w.b.o. They show up in the history and the recentchanges page but they're not in the generated pages. Example is
radiofreeI suppose you're using x though?11:20
ssam2petefoth: I've really no clue about ikiwiki11:21
ssam2maybe [[!meta title="Licence"]] should be 'License' instead ?11:22
ssam2hmm, actually I do have a clue11:22
ssam2perhaps it hasn't regenerated all the pages with the new template11:22
jmacspetefoth: That's odd.11:22
petefothit is not beyond the bounsd of possibility that the change I made to page.tmpl is broken. I'll try reverting it11:23
ssam2oh god, things are weird now11:23
* petefoth runs away and hides11:24
ssam2I keep getting pages that just say 'Content-type: text/html ' when I try to go to the ikiwiki setup page11:24
petefothReverting my template page made the other change I pushed work. Sorry to have bothered you11:26
ssam2looking at it, perhaps missing </TMPL_IF> tags where the cause11:27
ssam2the original has </TMPL_IF> <TMPL_ELSE> where yours just has <TMPL_ELSE>11:27
jjardonradiofree: instead using the dri nouveau driver,  add llvm-common to the gnome system stratum11:27
ofcourseistilllossam2, okay cool :)11:27
*** ofcourseistilllo is now known as straycat_11:28
Kinnisonpetefoth: If you want some help with the page.tmpl, let me know11:28
jjardonradiofree: that was the thing that make 3D not to work here11:28
Kinnisonpetefoth: I've got highly modified ikiwiki templates for my blog, so I'm kinda used to them :)11:28
radiofreeUsing mesa llvm on arm is way too slow jjardon11:28
*** straycat has quit IRC11:29
*** straycat_ is now known as straycat11:29
radiofreeI probably should have said. This was a jetso11:29
nowsterOn kernel compiles using morph, I see the following behaviour:
nowsterIt looks like morph doesn't initialise the git structures nicely.11:30
pedroalvareznowster: can you use a public paste service?11:30
radiofreejjardon: it builds fine. The demos (cogl/clutter) failed though11:30
radiofreeRecompiling mesa, on the board, with those options I mentioned and then they worked11:31
*** gfinney_ has joined #baserock11:31
radiofreeBy failed I mean failed to execute, recompile mesa, they ran11:31
Kinnisonpetefoth: If you do want me to take a look, just /msg me with the details of what you're trying to achieve11:31
ssam2nowster: not sure what you mean by 'git structures'... Morph only does Git operations using the 'git' binary11:32
radiofreejjardon: you're using x though? And not the egl backen11:32
ssam2it shouldn't be poking in .git directly... although I can't promise anything11:32
petefothKinnison: Thanks. Ill have one more go, and get bcak to you if that doesn't work11:32
nowsterIt doesn't set things up correctly such that "git diff-index" thinks the tree is initialised.11:32
ssam2hmm, it does do some trickery to get the initial clone on disk, actually11:32
ssam2because it copies it out of its local cache and converts it from bare to non-bare11:32
nowster...which is what the scripts/setlocalversion uses.11:33
nowstera "git status" seems to do the necessary fixups.11:33
ssam2nowster: this is the magic in question:
ssam2maybe we need to add something there to fix this11:34
*** 17SABV5BT has quit IRC11:34
jjardonradiofree: oh, true. lets add nouveau to the list of dri driver for arm then if that fixes the problem in your case; I can not test any arm related thing11:35
jjardonIm using both, you can choose when launching mutter11:36
nowsterssam2: where does it do the checkout?11:36
radiofreejjardon: can you write up the instructions somewhere other than storyboard?11:39
radiofreeWhich dbus service files do you have to move, and where11:40
*** rdale has joined #baserock11:43
jjardonradiofree: oh, seems I forgot to put that info in the announcement email; can you reply to it so I will not forget?11:47
radiofreeNot at the moment11:48
straycat"mkfs.btrfs -L src /dev/sdb" why do we advise people to use btrfs for /src ?11:48
richard_mawmostly legacy reasons, when we first put together those instructions we still had systems around that didn't have mkfs.ext4 in them and we hadn't been bitten by performance or reliability problems in btrfs enough to advise against it11:50
* radiofree always ignores that advice11:51
nowsterIME btrfs is slow and unreliable.11:51
straycatalso not sure about the 30G recommendation, usually found it's good to have as much space as possible, even 50G was annoyingly small for me (kept having to run morph gc), my /src is 100G and that works well for me at least11:51
ssam2nowster: destdir will probably in this case be / inside the staging area11:51
ssam2which will be /src/tmp/staging/tmpxxxxx11:51
ssam2straycat: where are these instructions? I agree with changing it to be mkfs.ext411:52
nowsterssam2: I'm thinking about where in the morph code it checks out the ref11:52
* richard_maw makes enough use of btrfs' CoW file copy that he is happy with the trade-off on his home machines11:52
ssam2nowster: calling code is here, I think:
ssam2i don't think those functions are heavily used so you can probably find your way around with 'git grep'11:53
ssam2the checkout code is simply: which hopefully isn't causing any issues!11:54
jjardonssam2: you branch to bring back petrify is exactly what  I needed, thanks!11:54
jjardonDo you plan to send it for review?11:54
ssam2jjardon: no11:57
straycatoh man not this agian11:57
ssam2I think something more like robtaylor's manifests proposal would be better11:57
straycatmorph silently fails to include strata if they're not named "correctly"11:57
ssam2jjardon: but i'm glad it's useful to you11:58
pedroalvarezstraycat: yes, some of us have already raised this issue11:58
straycatyeah i know11:59
straycati'm just raising it again11:59
pedroalvarezI think nobody is wokring on it though11:59
straycatradiofree spotted this ages ago11:59
*** gfinney__ has joined #baserock12:02
*** gfinney_ has quit IRC12:05
jjardonstraycat: maybe file a bug in storyboard so it doesn't get forgotten again?12:09
straycatoh cool, where is the storyboard?12:11
* straycat waits patiently for an email12:18
straycatokay, so i'll update the wiki to recommend ext4 for /src and maybe flesh out the advice on disk size?12:19
ssam2please do12:19
ssam2if you're hoping for storyboard to send emails, I don't think it does that yet12:20
straycatoh :'(12:20
straycatcan i have an account then? :)12:21
ssam2an account for what?12:22
ssam2for storyboard, you should be able to just use your openID12:22
straycati'm not sure i have one of those12:23
straycatthat's why i tried to register and then waited so patiently for an email that was never destined to be :(12:23
ssam2oh, if you were waiting for an email from, it's different12:24
ssam2that should be working12:24
straycathaha no problem :312:24
ssam2from /var/log/maillog: Feb 23 12:13:51 openid sendmail[8679]: t1NCDl3T008677: to=<>, delay=00:00:04, xdelay=00:00:04, mailer=esmtp, pri=120467, [], dsn=4.7.1, stat=Deferred: 451 4.7.1 <>: Recipient address rejected: Temporary deferral, try again soon12:25
ssam2not sure why that would happen, I don't understand sendmail at all12:25
straycatyeah that looks like my email address too12:26
Kinnisonsendmail :(12:26
ssam2could it just be sendmail being bad? would removing it and installed exim4 instead work and be simple?12:27
ssam2I went with stock sendmail on this system because I didn't know any better12:27
KinnisonI doubt it's sendmail's fault per-se12:27
Kinnisonfastmail might be greylisting12:34
Kinnisonsee if it retries12:34
ssam2hmm, I should add a note to the 'An email has been sent' template to point this out12:37
nowsterUgh! FastMail.12:40
persiaEven so, next time the machine is refreshed, it would be better to switch to some other MTA.  postfix and exim are popular, but for application systems, I tend to prefer really simple mailers (e.g. ssmtp), and pushing to some consolidated relay host running something smarter.12:43
ssam2does that mean we need to maintain a relay host, though?12:44
persiaYes, but maintaining one instance of postfix/exim is far easier than maintaining one-per-application-server.12:44
persiaAnd it lets one think more logically about mail transport in general, server availability, etc.12:45
KinnisonPepperfish (who host baserock-dev) can also be used as a mail relay if you can teach your smtp-ta to use authenticated smarthosts12:57
ssam2petefoth: I see 'All content is ©copyright the page author(s). The text of is formally licensed under the Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0).' on the wiki now :)12:59
ssam2looks good apart from the stray © symbol12:59
petefothssam2: I'll change the funny character13:00
petefothI'll swap for  (c)13:02
persia"(c)" has no meaning anywhere.13:02
petefothOK I will do nothing. If people have strong opinions, I will let them edit13:03
persiaI've read documentation suggesting © means something for Berne signatories.13:03
petefothThe symbol  © woirks for me in both the source of the wiki and opn the displayed pages in bpothFirefox and Chromium. Maybe the � symbol is something to do wioth ssam2's broweser?13:05
KinnisonThe recommendation appears to be "Copyright © YEAR AUTHOR(s)"13:06
nowsterthe © symbol is optional13:08
nowstereither "Copyright", "©" or both.13:09
ssam2petefoth: the character showed up fine for me13:10
nowster...and a copyright notice is optional for the purposes of Berne, but does make things clearer in the case of disputes.13:11
ssam2it just seemed weird to say ©copyright which, as far as I know, means 'copyright copyright'13:11
KinnisonThe UK recommendation is the word Copyright followed by the © symbol13:30
straycatnowster, What's wrong with fastmail?13:32
nowsterah... I was thinking of FastHosts... many many years ago.13:32
straycatahh :)13:33
*** tiagogomes_ has quit IRC13:33
petefothshould the word 'Copyright always be capitalised or does it depend on its plave on the sentence?13:34
petefothand space between 'Copyright' and the ©?13:34
ssam2I've never seen it without a space13:36
ssam2i don't know the answer to your other question13:36
petefothssam2: thanks13:36
*** tiagogomes_ has joined #baserock13:48
petefothDOes anyone know in which year did w.b.o go 'live'? (Becasue I guess that is the first year to be included in the Coyright statement) eg 'Copyright © 2012-2015 the page author(s)'13:48
rjekThat's the earliest snapshot have13:51
ssam2first commit in the git history is  Thu Sep 22 15:23:36 2011 +000013:51
petefothrjek: ssam2: thanks both13:51
rjekah, there we go :)13:51
*** zoli__ has quit IRC13:59
*** zoli__ has joined #baserock14:01
*** wschaller_ has quit IRC14:26
SotKSo I'm doing some work on using OSTree for artifact caching, naturally this is going to make everyone's local caches worthless. Would people prefer to have to remove their artifact caches (or waste all that disk space) when they update morph or for me to write a script or something which converts their existing cache into the correct layout so they don't need to redownload any artifacts they have already cached?14:27
bashrcis there anywhere I can find out about morph extensions?14:27
*** tiagogomes_ has quit IRC14:27
petefothbashrc: looking at the code is a start. Each one has some help text which (I think) can be displayed using some vairant of 'morph help...'14:29
bashrcso a morph extension adds some kind of custom functionality?14:30
petefothbashrc: contains .help files14:30
bashrcok thanks I'll read some of those14:31
straycatSotK, if the conversion is straight forward then a script for that would be cool14:31
straycatbashrc, you can also run $ morph help-extensions14:32
petefothI believe there are '.write' extensions which are used when deploying baserock systems in different ways, '.configure' extensions used to configure the systmes before deployment, and 'check' extensions which are called by (I thionk) the write extensions14:32
bashrcis any of that on the wiki?14:33
pedroalvarezI'd try with the search box14:33
petefothbashrc: some info in
petefothand has some stuff on the pxeboot.write extension14:35
petefothbashrc: and what pedroalvarez says :)14:35
straycat"Your account is now activated." \o/14:35
persiaSotK: a script sounds good to me as well.14:37
* straycat begins "The tale of the missing artifacts"14:37
jjardonHi! Is there any work toward bootstrap OpenJDK with baserock?14:38
pedroalvarezthere were some deep thinking about it some time ago, but I believe that nobody is spending time on that14:39
*** tiagogomes_ has joined #baserock14:39
SotKstraycat, persia: a script it is then :)14:39
persiaI was thinking it would be nifty if morph could detect an old-format cache and auto-update, but it's probably not worth the overhead for every morph operation.14:40 should probably have both caches for a while.14:40
SotKat the moment, the local cache using OSTree understands a remote cache using the current format14:43
persiaWhich format makes more sense for then?  Especially considering the need to push new artifacts there regularly.14:44
bashrcI notice that on the wiki there seems to be confusion between "morph" and "definition". Maybe it should be one or the other. Perhaps change to .def and call them all definitions14:44
persiabashrc: I believe that was discussed at the meetup, and that was the planned way forward.14:45
persiaWe used to call them "morphologies", hence the .morph extension, and keep them in "morphologies.git".14:45
petefothbashrc: the wiki is globally editable ;)14:45
persiabashrc: If you feel like writing that patch today, feel free to fix it :)14:45
persia(not the wiki, but the content of definitions.git and the morph codebase)14:45
bashrcpetefoth: it is, but I would't presume to make a global terminology change without some consensus14:47
persiaAlso, it doesn't make sense while the codebase still uses the older terms.14:48
petefothbashrc: fair enough. There is work going on or planned in this area I believe. With luck the wiki will get updated as [art of that. And what persia says!14:48
persiaIs anyone actually doing it?  I remember it being agreed, but I don't remember anyone volunteering to handle the implementation.14:49
Zarabashrc: I tend to refer to them as '.morph files', since it induces less panic than 'morphologies'.14:50
petefothpersia: there's a story and several tasks, but none of them are yet assigned14:51
persiaThat matches my understanding.14:51
persiabashrc: ^^ : it's now confirmed that this is something you can do if you like :)14:52
ssam2I believe jjardon is working on the task of adding versioning to definitions14:52
ssam2but not the subsequent tasks of renaming everything14:52
* bashrc hadn't noticed that there were no definition versions14:54
straycatssam2, jjardon, pedroalvarez, i've submitted a story for that bug now so hopefully we'll fix it one day14:58
pedroalvarezstraycat: :)14:58
*** lachlanmackenzie has quit IRC15:19
mauricemoss_Does anyone have objections against merging the two if blocks in _env_for_arch()?
ssam2looks fine to me15:23
mauricemoss_ok, ta15:24
pedroalvarezthat looks ok15:28
*** lachlanmackenzie has joined #baserock15:30
*** ssam2 has quit IRC15:32
*** ssam2 has joined #baserock15:33
*** ChanServ sets mode: +v ssam215:33
*** zoli__ has quit IRC15:34
persiaDoes POWER not need anything special in
*** zoli__ has joined #baserock15:36
* persia is mostly concerned about potential issues with PPC vs. POWER, etc.15:36
persiaAlso, we should have a default convention for 32/64 sufficies: the difference between mips64l and armv8l64 seems likely to be confusing.15:38
Kinnisonpersia: to be fair, mips and arm have different naming schemes15:39
pedroalvarezpersia: I didn't need to chage for POWER15:39
persiaYes, but if morph is standardising the naming schemes, and then standardises inconsistently, it just makes me feel like
persiaIf we accept upstream differences, let's just have morph use the strings from linux, or from gcc, or something else.15:40
KinnisonI'd be happy if we were to standardise on a shape, but if the shape is ARCH[ENDIAN[SIZE]] then only the arm stuff compiles currently15:41
persiaDo you men "compiles" or "complies"?15:42
persiaErr, s/men/mean/15:42
Kinnisonsorry, typing on my lap upside down with my leg in the air isn't easy15:42
* Kinnison is stuck on the sofa with a bad leg :(15:42
persiaAh good.  I was hoping that was a typo.15:42
persiaBut yes, if we are inventing a new competing standard, I'd really rather pick one that was self-consistent.15:43
persiaOtherwise I don't see why we shouldn't just have morph arch always match cpu arch.15:43
persiaPicking ABI is a bit trickier, but we could presumably have a consistent optional suffix mechanism to use upstream ABI names.15:43
rjekThe current scheme with mips64l and armv8l64 is consistent.  [archname][endianness][optional varient#15:47
rjek"mips64" and "armv8" are architecture names.15:47
rjekBut ARMv8 has three different instruction sets/modes15:48
rjekIt might actually be four, I don't know if they included Jazelle in v8.15:48
persiaSo, what are the three ARMv8 little-endian formats?15:49
rjekarmv8l32 and armv8l64.15:51
rjekPutting 64 at the end of "mips64l" seems somewhat redundant.15:51
persiaExcept it's different.15:52
*** zoli__ has quit IRC15:52
persiaIn mixed-width mode, one runs a 64-bit kernel and a random collection of 32-bit and 64-bit apps.15:52
persiaIn 64-bit mode, one runs all 64-bit.15:52
persiaOnly in x86 is the architecture so frustratingly bound to the width.15:53
rjekThat is a specialisation is is probably not worth accounting for, or you end up with things like armv8l64armv7b3215:53
persiaNo I don't.15:53
persiaarm is broken in the same way as x86, sadly.15:53
persiaBut MIPS and POWER do that normally.15:53
persiaWhich is why the "abi64" in the MIPS entries, indicating full 64-bit.  Whereas the ppc64 environment in morph is a mixed-width environment.15:54
* rjek tries hard to work out what persia's point is, and decides it's probably best just to get some coffee.15:54
*** zoli__ has joined #baserock15:55
* persia hopes that coffee results in three strings for a list of three, and an understanding of environments where the structure of the architecture is not strictly bound to bit width.15:55
* richard_maw idly wonders how the gnu architecture triplet fits in15:56
rjekGNU triplets contain hardware vendor which is rarely important these days.15:57
persiaThe center part of the triplet is hardcoded, which is annoying because it is one of the reasons morph can't do non-linux.15:57
* Kinnison suggests persia come up with a starter-for-10 for architecture names15:57
persiaAfter thinking about richard_maw's point, I think we ought just use raw GNU triplets, and not try to make it easier.15:58
rjekor copy Debian, but their solution is polluted with marketing nonsense
persiarjek: Where is the hardware vendor in "mips64el-baserock-linux-gnuabi64"?15:59
rjekpersia: "linux"15:59
rjekOn other systems, it's often "unknown" if the vendor is unimportant16:00
persiaI thought that was the software platform name, but I can see how it was once hardware.16:00
persiaBut yeah, I think I like the Debian model.  Almost entirely GNU triplets, with a few sensible extensions.16:00
ssam2I thought the vendor field was the 2nd field, thus 'baserock'16:00
persiaThat morph hardcodes a 4-field "triplet" is one of the more mysterious parts of morph :)16:01
rjekSadly the Debian model doesn't deal with different CPU subarchitectures/versions16:01
ssam2persia: it's 3 parts16:02
rjekie, it doesn't let you distinguish between ARMv5, 6, 7, or 8.16:02
ssam2linux-gnuabi64 is one part, perversley16:02
rjekAnd the i386 is a lie; Linux doesn't even run on the i386 anymore :)16:02
persiassam2: That seems inconsistent with what is written at
ssam2which part?16:03
persiarjek: Yes, I propose not lying in Baserock.  We only support i686, and the chance of there actually being a meaningful i786 at this point is lower than at any point in the past.16:03
persiassam2: The list of names.16:03
ssam2that is documenting Debian arch fields, not GNU triplets, as far as I can see...16:03
persiaUnder "Used Solution"16:03
persiaWhere is says "Use normalized GNU triplets for most tuples, and extend the GNU triplet when it is ambiguous."16:04
ssam2those differ from what I've previously seen of GNU triplets16:04
rjekpersia: On the other hand, Debian's approach does not deal with incompatibilities between all the common ARM architecture versions.16:04
persiaDunno then.16:04
ssam2persia: also differs from what I have one Fedora: x86_64-redhat-linux16:04
ssam2where redhat is vendor, and linux is syscall API16:05
ssam2-e again16:05
persiaRight, but all the xamples from elsewhere only have two hyphens, which I think is the important part.16:05
ssam2fedora for ARM will be arm-redhat-linux-gnueabi, I imagine16:05
persiarjek: Yes.  The lack of proper ARM support is entirely broken.16:05
rjekI think we care about both ARMv7 and ARMv8 at the very least.  We may also care about v5.16:06
* persia has trouble believing there to be no solution to this problem, and that if there is no solution, that there is resistance to creating a model that is consistent and readable16:06
persiarjek: v6 is important as well: there are two v6 instructions that cannot be emulated on v8, which are annoyingly used in the raspbian distro.16:07
rjekDo we want to suppor the original RPi? :)16:07
ssam2persia: documents GNU triplets as being '‘cpu-vendor-os’ and then shows examples where OS is 'linux-gnu'16:08
ssam2my point in saying this is to show that none of this craziness comes from Morph16:08
*** a1exhughe5 has quit IRC16:10
* rjek is reminded of the NetSurf toolchain triplets; arm-unknown-riscos, i686-w64-wingw32, and the maddening nontriplet ppc-amigaos16:10
rdalei've been building a build-essential stratum with musl instead of glibc, and the env variable TARGET_STAGE1 is glibc specific. That is hard coded in morph, but I think it should go somewhere in the stratum preamble16:10
*** a1exhughe5 has joined #baserock16:11
ssam2rdale: what's glibc-specific about it?16:12
persiassam2: My only complaints about morph were 1) hardcoding "linux", and 2) the maddening apparent variation in nomenclature between "armv8l64" and "mips64l": rjek explained why this was logical, but it's still annoying to view.16:12
persiaThat everyone else who thinks about this problem appears to have gone entirely mad in the process and left no useful output for those attempting to follow in their footsteps is just a side issue.16:12
ssam2I was a bit lost about what you mean about 'hardcoding linux', but as rdale points out, TARGET_STAGE1 is indeed defined by Morph16:13
ssam2and TARGET16:13
rdalessam2: env['TARGET_STAGE1'] = cpu + '-bootstrap-linux-gnu' + abi... means that linux-gnu for glibc support is hard code16:13
ssam2oh, the 'linux-gnu' part is glibc... of course16:13
ssam2yes, would be nice to figure out a way to set this in definitions instead16:13
rdalei've been building with 'x86_64-linux-musl' which works, but i haven't tried other cpu arches yet16:14
ssam2since definitions are still per-arch, simply adding a list of environment variables to the system definitions that get set during build-time might be enough16:14
ssam2so the system morph would set TARGET and TARGET_STAGE1 instead of Morph16:14
ssam2but this adds complexity to everyone's system morphs that some probably don't want16:14
persiaI want it, because I want non-linux16:15
rdaleyes, i think it is only used by build-essential and maybe the 'cross-foobar' ones?16:15
paulsherwoodssam2: i don't think that's complexity really16:15
persiaFor multiple-kernel, multiple-arch, multiple-ABI, multiple-libc, this ends up being as complicated to specify whether I try to hide it or not.16:15
persiaAnd I think it'S a lot more transparent if we don't invent MORPH_ARCH in such a way that it can be perceived as confusing (due to historial warts, noted above)16:16
ssam2to anyone not interested in those things, it'll be magic that they have to copy and paste and keep in sync between all new system morphs16:16
ssam2MORPH_ARCH could probably be removed without too much pain, indeed16:17
ssam2if we added TARGET and TARGET_STAGE1 to the system morphs16:17
ssam2I guess TARGET_STAGE1 is just TARGET with the vendor field replaced16:17
ssam2in most cases16:17
ssam2so, OK, replacing the 'arch' field with something that gets set as TARGET would be fine16:17
*** perryl_ has joined #baserock16:18
richard_mawssam2: there's a bit of extra magic to prevent you attempting to build for an architecture that you cannot run unless you're in cross-bootstrap mode, but it ought to be fine if we ensure we cache host arch and target arch suitably16:19
*** perryl has quit IRC16:19
ssam2richard_maw: we could just get cross-compilation working, instead.16:20
*** perryl_ is now known as perryl16:21
gfinney__I'm working on the YBD project ( and I've hit a problem the baserockers might be able to help with. Basically, YBD is meant to  be able to build any individual component. It walks through a baserock directory structure looking for morph files and processes them to do a simplified build. It does a build-essential-minimal build ok, but building anything that requires fhs-dirs causes failure.16:26
gfinney__It seems this is down to the fact that it tries to get a file from build-essential/tools/bin, which doesn't exist in the environment. In fact, YBD gets a bits mixed up and splits the file path as a result.16:26
gfinney__So, from a baserock point of view, why would this directory be missing?16:26
gfinney__Further debug info at
ssam2gfinney__: there's no /build-essential/tools/bin directory in any chunks in the Baserock reference systems#16:28
ssam2there is a /tools/bin directory created by the stage1-* and stage2-* chunks16:28
ssam2but /tools/bin shouldn't be needed by anything outside the build-essential stratum16:28
ssam2it may be a symlink at some point...16:29
ssam2stage2-fhs-dirs does `ln -s "$PREFIX/bin" "$DESTDIR/bin"`16:30
ssam2it might be that which is confusing ybd16:30
gfinney__The reference to /tools/bin comes up as an apparent bug in the code16:32
gfinney__It should be /src/staging/base-system-x86_64-generic-20150208-121158/build-essential.inst/tools/bin but is split16:32
persiarichard_maw: I don't trust the magic about architectures that one cannot run.  I've played enough with BINFMT and qemu to have run all sorts of architectures in all sorts of places (e.g. arm7lhf on ppc)16:33
gfinney__and that appears to have been prompted by the absence of that tools/bin directory16:34
gfinney__In the code, it lists the contencts of that directory and then tries to process the non-existent tools directory16:35
gfinney__As far as I can tell, paulsherwood doesn't get this problem.16:36
*** franred has quit IRC16:42
*** zoli__ has quit IRC16:44
*** zoli__ has joined #baserock16:46
*** gary_perkins has quit IRC17:03
gfinney__I think I see what you mean ssam2. You mean it should't be trying to reference that directory because it isn't defined in the chunks?17:09
ssam2it's defined in stage2-fhs-dirs chunk as a symlink17:10
ssam2I think17:10
gfinney__I'll see if that's what it is. Thanks ssam217:11
*** a1exhughe5 has quit IRC17:18
mauricemoss_A patch that I want to send to the list depends on other patches that I've sent previously. Should I wait till they have been applied?17:19
ssam2you can send it and just note in the cover letter what the other patches that it depends on are17:20
*** jonathanmaw has quit IRC17:21
*** lachlanmackenzie has quit IRC17:28
*** zoli__ has quit IRC17:36
*** gfinney__ has quit IRC17:38
ratmice__rjek: the vendor field is optional, so ppc-amigaos would be equiv to ppc-unknown-amigaos, which then of course makes multi part os like linux-gnu ambiguous :)17:39
ratmice__so just be happy it wasn't ppc-linux-gnu17:39
ratmice__even ppc--linux-gnu would be better (IMO)... so morph needs to care about something, even if it is just that it has an ample amount dashes17:42
*** Krin has quit IRC17:42
*** mdizzle has quit IRC17:44
bashrcin pxeboot.write it looks like there isn't any error handling for local and remote copying17:45
persiaThat should probably be fixed :)17:46
* richard_maw used context managers to do all the resource cleanup17:47
bashrcin general I think there should be unit testing for this kind of stuff, or at least a check within the function that if you copy from A to B that both actually exist17:47
persiaI'm an antifan of unit testing.  I believe there should be system-level functional tests, combined with system-level failure states which are mocked before running tests.17:47
richard_mawbashrc: you run into TOCCTOU bugs if you do that check, as the files may not be there by the time you try the copy17:48
richard_mawbashrc: so you need to handle failure gracefully anyway17:48
*** lachlanmackenzie has joined #baserock17:49
bashrcyes I guess there could be timing issues (you check for a file, but it hasn't been written yet)17:49
richard_mawthat kind of thing yeah17:49
richard_mawso I wrote it in the style of stacking context managers, so if you get an exception going up the stack, it automatically cleans up every context17:50
richard_mawso if you get an exception after the local_pxelinux has been set up, then the pxelinux file gets removed again17:51
richard_mawis there something in particular biting you with the error handling?17:51
bashrcI was just reading it and wondering what happens if copy didn't work17:53
*** petefoth_ has joined #baserock17:54
richard_mawyou get an exception, which while not particularly user friendly, is useful for the developer to see where it failed, and everything that was set up before you got to that point gets torn down17:55
bashrcok, well that's something17:55
*** petefoth has quit IRC17:56
*** petefoth_ is now known as petefoth17:56
richard_mawbashrc: so your complaint is the lack of user-friendly error messages? or do you thing there's something else we should do when an operation fails?17:57
*** bashrc has quit IRC17:58
tiagogomes_uboot pxe seems to not undestand tftp:// URLs18:11
Kinnisonexceedingly unlikely it would18:12
Kinnisonu-boot's "PXE" support is very rudimentary18:12
KinnisonAnd I *WISH* it wouldn't call itself PXE18:13
Kinnisonbecause it's very NOT PXE18:13
* Kinnison restrains himself from ranting though18:13
tiagogomes_Not sure what to do, pxeboot is already complicated enough18:14
tiagogomes_maybe it makes sense to have a moonshoot write extension18:14
KinnisonSadly I'm probably not able to advise you here18:14
* Kinnison has never looked at the pxe stuff in Baserock18:14
*** Guest10998 has quit IRC18:19
*** ssam2 has quit IRC18:20
*** tiagogomes_ has quit IRC18:35
*** lachlanmackenzie has quit IRC19:18
*** rdale has quit IRC19:31
jjardonHi, I need to regenerate /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache (generated in gdk-pixbuf) after librsvg is built. What is the best way to do this in baserock? I tried "../usr/bin/gdk-pixbuf-query-loaders > ../usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache" but of course doesnt work because ../usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache will be in a19:51
jjardonread-only file system ...19:51
persiaThe recommendation I've seen for that before involves leaving the data wrong, and running it as a system integration script.19:58
persiaThe dirty hack is to create a chunk that exists only to generate that cache, so reads the cache from the read-only environment, and writes it to the writable environment, and relies on the idea that when the hack chunk is used, it overwrites the prior data for the prior cache supplied by the gdk-pixbuf chunk.20:00
jjardonunfortunately I need that cache up-to-date in compilation time to build another component, so I can not use a system integration script. I will try the "dirty hack" way20:08
persiaGood luck with it.  It relies on having precisely the same filenames.20:10
persiaWe should really find a better way to deal with this.  Kinnison was advocating another script fragment like system integration that would run just after unpack in the staging area, or similar.20:11
jjardonoh, I think I found the hack:
*** lachlanmackenzie has joined #baserock21:04
*** lachlanmackenzie has quit IRC21:54

Generated by 2.15.3 by Marius Gedminas - find it at!