| *** zoli__ has joined #baserock | 01:28 | |
| *** zoli__ has quit IRC | 01:33 | |
| *** zoli__ has joined #baserock | 03:52 | |
| *** zoli__ has quit IRC | 04:13 | |
| *** petefoth has joined #baserock | 07:31 | |
| *** mike has joined #baserock | 07:39 | |
| *** mike is now known as Guest10998 | 07:40 | |
| *** a1exhughe5 has joined #baserock | 07:57 | |
| *** mdizzle has joined #baserock | 08:45 | |
| *** sambishop has joined #baserock | 08:55 | |
| petefoth | What is the status of storyboard.baserock.org? Is it sefae to trust it with data, or do we need to keep backups elsewhere in case of resets? | 09:00 |
|---|---|---|
| pedroalvarez | I believe that its status hasn't changed, so I dare say ssam2 would say we can't trust it yet. | 09:03 |
| petefoth | pedroalvarez: thanks | 09:03 |
| *** bashrc has joined #baserock | 09:04 | |
| *** gary_perkins has joined #baserock | 09:18 | |
| *** jonathanmaw has joined #baserock | 09:18 | |
| *** tiagogomes_ has joined #baserock | 09:32 | |
| *** CTtpollard has joined #baserock | 09:35 | |
| *** paulw has joined #baserock | 09:49 | |
| *** paulwaters_ has quit IRC | 09:49 | |
| *** Krin has joined #baserock | 09:54 | |
| *** ssam2 has joined #baserock | 09:58 | |
| *** ChanServ sets mode: +v ssam2 | 09:58 | |
| petefoth | How do I go about getting the 'copyright' and 'licnce' plugins installed / enabkled on wiki.baserockorg (http://git.savannah.gnu.org/cgit/hurd/web.git/plain/.library/IkiWiki/Plugin/license.pm and http://git.savannah.gnu.org/cgit/hurd/web.git/plain/.library/IkiWiki/Plugin/copyright.pm) | 09:58 |
| ssam2 | ask one of the ops | 09:58 |
| ssam2 | I can have a look for you | 09:58 |
| petefoth | ssam2: thanks | 09:59 |
| *** 17SABV5BT has joined #baserock | 10:01 | |
| *** 6JTAAHO77 has joined #baserock | 10:01 | |
| *** zoli__ has joined #baserock | 10:04 | |
| richard_maw | pedroalvarez: 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 |
| ssam2 | petefoth: neither of those plugins seem available in Branchable. so I'm not sure if or how we can install them | 10:06 |
| pedroalvarez | richard_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 repo | 10:07 |
| ssam2 | petefoth: are they important? if so, I'll dig a bit deeper | 10:07 |
| petefoth | ssam2: OK thanks. Do you know if the 'meta' plugin (https://ikiwiki.info/plugins/meta/) is installed at branchable? | 10:08 |
| ssam2 | meta is installed and enabled | 10:08 |
| *** lachlanmackenzie has joined #baserock | 10:09 | |
| Kinnison | petefoth: those plugins belong to the hurd's website | 10:09 |
| petefoth | ssam2: tA1> I'll get on with trying to make ti work for the copyrigt and licence then | 10:09 |
| petefoth | Kinnison: Sorry - I should have spotted that | 10:09 |
| Kinnison | petefoth: We could simply alter the outer page template | 10:09 |
| Kinnison | petefoth: to include a copyright and licence statement | 10:10 |
| petefoth | Kinnison: there's som bolierplate in the current template - \I'll look into activating it with the correct text | 10:10 |
| Kinnison | although the page template we have already contains such | 10:11 |
| petefoth | Kinnison: I believe I have to use some magic with the meta plugin to set the vcriables that the current template uses | 10:12 |
| Kinnison | Mmm | 10:12 |
| petefoth | http://ikiwiki.info/plugins/contrib/default_content_for___42__copyright__42___and___42__license__42__/ | 10:12 |
| Kinnison | That's a contrib plugin so is unlikely to be on branchable | 10:13 |
| *** lachlanmackenzie has quit IRC | 10:13 | |
| * petefoth doesn't unsderstand - which is not news :) | 10:14 | |
| Kinnison | Sadly Jon's defaultmeta stuff doesn't seem to have made it in either | 10:15 |
| Kinnison | May be easier to just edit page.tmpl to put your copyright content in unconditionally | 10:15 |
| * petefoth will do that | 10:15 | |
| petefoth | s/do/try/ | 10:15 |
| *** wschaller has joined #baserock | 10:23 | |
| *** wschaller_ has joined #baserock | 10:24 | |
| *** wschaller has quit IRC | 10:24 | |
| *** 6JTAAHO77 has quit IRC | 10:26 | |
| *** lachlanmackenzie has joined #baserock | 10:29 | |
| *** zoli__ has quit IRC | 10:37 | |
| *** zoli__ has joined #baserock | 10:37 | |
| jjardon | Hi! any idea what happened with the icu-svn repo? http://git.baserock.org/cgi-bin/cgit.cgi/delta/icu-svn.git/ | 10:39 |
| ssam2 | I think it was lorried, then we found that it was never going to complete | 10:44 |
| ssam2 | I think their SVN server is broken or way too slow | 10:44 |
| ssam2 | so we should remove it | 10:44 |
| ssam2 | shall I remove it now? anyone mind? | 10:45 |
| paulsherwood | jjardon: maybe this is master now? https://chromium.googlesource.com/chromium/deps/icu/ | 10:51 |
| franred | jjardon, have you tried to lorry that repo into your devel-system? (to discard that the svn server is broken) | 10:51 |
| *** zoli__ has quit IRC | 10:52 | |
| paulsherwood | ssam2: i think we should remove that, but also track down where the git master is | 10:52 |
| *** zoli__ has joined #baserock | 10:53 | |
| ssam2 | franred: I tried lorrying it when radiofree proposed it. I found that the repo was growing in size, slowly | 10:53 |
| ssam2 | maybe 1 or 2 MB a minute | 10:53 |
| ssam2 | so I figured it'd be ok, but clearly it's not | 10:53 |
| jjardon | franred: my devel system? if you mean if I have a trove in my personal laptop, I dont | 10:54 |
| radiofree | paulsherwood: that's ICU + chromium patches | 10:54 |
| radiofree | I don't think the ICU project use git | 10:54 |
| franred | jjardon, 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 patch | 10:54 |
| jjardon | paulsherwood: chromium tends to fork every project instead use upstream, but maybe I do not know | 10:55 |
| franred | not need to be a trove | 10:55 |
| radiofree | jjardon: I got your branch to build | 10:55 |
| radiofree | I needs py3cairo though | 10:55 |
| jjardon | franred : ah, ok. But no I do not have a devel system neither | 10:56 |
| radiofree | And caribou needed PYTHON=python3 set before configure | 10:56 |
| radiofree | Mesa also needs enabel-shared-glapi for cogl to work with wayland | 10:56 |
| jjardon | radiofree: it compiles fine here, seems a bug in caribou configure checks? | 10:57 |
| radiofree | I don't see how it could compile fine | 10:58 |
| radiofree | Pygobject needs py3cairo to compile | 10:58 |
| radiofree | Maybe this is because I added python3 as a build dep of the entire stratum? | 10:58 |
| radiofree | You forgot to include your python morph | 10:59 |
| pedroalvarez | re icu-svn, took serveral hours and 1G to lorry it | 10:59 |
| pedroalvarez | (manually) | 10:59 |
| radiofree | Also remove ogg and vorbis now you've added them to multimedia common | 10:59 |
| jjardon | radiofree: probably, I only use python3 to build gnome-shell | 11:00 |
| *** straycat has joined #baserock | 11:00 | |
| straycat | hi | 11:00 |
| straycat | can we stop putting system artifacts on the cache | 11:01 |
| straycat | it slows building a system down generally | 11:01 |
| radiofree | https://git.gnome.org/browse/pygobject/tree/configure.ac#n27 | 11:01 |
| pedroalvarez | straycat: you have already asked that in t he past. Is not that easy :/ | 11:02 |
| radiofree | Aaah | 11:02 |
| radiofree | That's only if 'building for python3' I suppose it detected it on the system | 11:02 |
| *** zoli__ has quit IRC | 11:03 | |
| straycat | pedroalvarez: 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 this | 11:03 |
| *** zoli__ has joined #baserock | 11:06 | |
| straycat | 2015-02-23 10:50:47 [Build 218/218] [devel-system-x86_64-generic] Fetching to local cache: artifact devel-system-x86_64-generic-rootfs | 11:06 |
| straycat | 2015-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-rootfs | 11:06 |
| straycat | :/ | 11:06 |
| pedroalvarez | well, I have to say that one day I enjoyed we had system artifacts there, when I deployed an armv7 system from x86 without building it | 11:07 |
| straycat | okay, but in the general case it sucks | 11:07 |
| pedroalvarez | straycat: also, you could have skipped the whole build. Maybe you could have saved some minutes building.. | 11:08 |
| pedroalvarez | anyway, my opinion is that this should be a morph option | 11:09 |
| ssam2 | straycat: it would be nice to not have them in the cache, since they are huge | 11:09 |
| ssam2 | could be distbuild option to say 'don't upload the system artifact' | 11:09 |
| pedroalvarez | that is also true | 11:09 |
| ssam2 | but could equally be a morph option to say 'don't download system artifacts' | 11:09 |
| persia | I like them in the cache because it means all my deployments are from the same blob | 11:09 |
| ssam2 | seems more /correct/ to me to make it a local morph option to not download them | 11:10 |
| persia | Could we do something with remote binary correction? Essentially using local objects to reduce the transfer of the system? | 11:10 |
| jjardon | radiofree: not sure we need the enable-shared-glapi option? we are not building support for gles1 | 11:10 |
| radiofree | Were not? Glesv2? | 11:11 |
| radiofree | It was either that or adding nouveau to the DRI list for arm | 11:12 |
| ssam2 | persia: actually SotK is doing work right now to make this problem go away | 11:12 |
| jjardon | radiofree: gles2 yes, but seems shared-glapi is only needed if you build both gles1 and gles2 | 11:12 |
| persia | ssam2: What "problem"? | 11:12 |
| radiofree | Why is DRI drivers set to no for arm? | 11:12 |
| ssam2 | persia: the problem that system artifacts contain largely duplicate data | 11:12 |
| ssam2 | and thus are big and slow but contain little new info compared to the constituent chunk artifacts | 11:13 |
| ssam2 | slow to transfer, I mean | 11:13 |
| radiofree | jjardon: cogl didn't work without one of those changes to mesa | 11:13 |
| persia | Ah, 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 |
| jjardon | radiofree: it does work in my vm. Are you testing in real hardware? | 11:14 |
| radiofree | Yes of course | 11:14 |
| radiofree | By works I mean the demos | 11:15 |
| radiofree | Running the examples in weston | 11:15 |
| radiofree | It compiles fine | 11:15 |
| radiofree | Is that what you mean by work as well? | 11:16 |
| jjardon | radiofree: I runned mutter here | 11:19 |
| petefoth | so 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 http://wiki.baserock.org/editing-the-wiki/ | 11:19 |
| radiofree | I suppose you're using x though? | 11:20 |
| ssam2 | petefoth: I've really no clue about ikiwiki | 11:21 |
| ssam2 | maybe [[!meta title="Licence"]] should be 'License' instead ? | 11:22 |
| ssam2 | hmm, actually I do have a clue | 11:22 |
| ssam2 | perhaps it hasn't regenerated all the pages with the new template | 11:22 |
| jmacs | petefoth: That's odd. | 11:22 |
| petefoth | it is not beyond the bounsd of possibility that the change I made to page.tmpl is broken. I'll try reverting it | 11:23 |
| ssam2 | oh god, things are weird now | 11:23 |
| * petefoth runs away and hides | 11:24 | |
| ssam2 | I keep getting pages that just say 'Content-type: text/html ' when I try to go to the ikiwiki setup page | 11:24 |
| petefoth | Reverting my template page made the other change I pushed work. Sorry to have bothered you | 11:26 |
| ssam2 | looking at it, perhaps missing </TMPL_IF> tags where the cause | 11:27 |
| ssam2 | were | 11:27 |
| ssam2 | the original has </TMPL_IF> <TMPL_ELSE> where yours just has <TMPL_ELSE> | 11:27 |
| jjardon | radiofree: instead using the dri nouveau driver, add llvm-common to the gnome system stratum | 11:27 |
| ofcourseistilllo | ssam2, okay cool :) | 11:27 |
| *** ofcourseistilllo is now known as straycat_ | 11:28 | |
| Kinnison | petefoth: If you want some help with the page.tmpl, let me know | 11:28 |
| jjardon | radiofree: that was the thing that make 3D not to work here | 11:28 |
| Kinnison | petefoth: I've got highly modified ikiwiki templates for my blog, so I'm kinda used to them :) | 11:28 |
| radiofree | Using mesa llvm on arm is way too slow jjardon | 11:28 |
| *** straycat has quit IRC | 11:29 | |
| *** straycat_ is now known as straycat | 11:29 | |
| radiofree | I probably should have said. This was a jetso | 11:29 |
| nowster | On kernel compiles using morph, I see the following behaviour: https://admin.codethink.co.uk/pnopaste/?2355 | 11:29 |
| nowster | It looks like morph doesn't initialise the git structures nicely. | 11:30 |
| pedroalvarez | nowster: can you use a public paste service? | 11:30 |
| nowster | Sorry! | 11:30 |
| nowster | http://paste.baserock.org/fekozeyewu | 11:30 |
| radiofree | jjardon: it builds fine. The demos (cogl/clutter) failed though | 11:30 |
| radiofree | Recompiling mesa, on the board, with those options I mentioned and then they worked | 11:31 |
| *** gfinney_ has joined #baserock | 11:31 | |
| radiofree | By failed I mean failed to execute, recompile mesa, they ran | 11:31 |
| Kinnison | petefoth: If you do want me to take a look, just /msg me with the details of what you're trying to achieve | 11:31 |
| ssam2 | nowster: not sure what you mean by 'git structures'... Morph only does Git operations using the 'git' binary | 11:32 |
| radiofree | jjardon: you're using x though? And not the egl backen | 11:32 |
| ssam2 | it shouldn't be poking in .git directly... although I can't promise anything | 11:32 |
| petefoth | Kinnison: Thanks. Ill have one more go, and get bcak to you if that doesn't work | 11:32 |
| nowster | It doesn't set things up correctly such that "git diff-index" thinks the tree is initialised. | 11:32 |
| ssam2 | right | 11:32 |
| ssam2 | hmm, it does do some trickery to get the initial clone on disk, actually | 11:32 |
| ssam2 | because it copies it out of its local cache and converts it from bare to non-bare | 11:32 |
| nowster | ...which is what the scripts/setlocalversion uses. | 11:33 |
| nowster | a "git status" seems to do the necessary fixups. | 11:33 |
| ssam2 | nowster: this is the magic in question: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/git.py#n224 | 11:34 |
| nowster | ta | 11:34 |
| ssam2 | maybe we need to add something there to fix this | 11:34 |
| *** 17SABV5BT has quit IRC | 11:34 | |
| jjardon | radiofree: 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 thing | 11:35 |
| jjardon | Im using both, you can choose when launching mutter | 11:36 |
| nowster | ssam2: where does it do the checkout? | 11:36 |
| radiofree | jjardon: can you write up the instructions somewhere other than storyboard? | 11:39 |
| radiofree | Which dbus service files do you have to move, and where | 11:40 |
| *** rdale has joined #baserock | 11:43 | |
| jjardon | radiofree: oh, seems I forgot to put that info in the announcement email; can you reply to it so I will not forget? | 11:47 |
| radiofree | Not at the moment | 11:48 |
| straycat | "mkfs.btrfs -L src /dev/sdb" why do we advise people to use btrfs for /src ? | 11:48 |
| richard_maw | mostly 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 it | 11:50 |
| * radiofree always ignores that advice | 11:51 | |
| nowster | IME btrfs is slow and unreliable. | 11:51 |
| straycat | also 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 least | 11:51 |
| ssam2 | nowster: destdir will probably in this case be /linux.build inside the staging area | 11:51 |
| ssam2 | which will be /src/tmp/staging/tmpxxxxx | 11:51 |
| ssam2 | straycat: where are these instructions? I agree with changing it to be mkfs.ext4 | 11:52 |
| nowster | ssam2: I'm thinking about where in the morph code it checks out the ref | 11:52 |
| * richard_maw makes enough use of btrfs' CoW file copy that he is happy with the trade-off on his home machines | 11:52 | |
| straycat | http://wiki.baserock.org/quick-start/#index3h2 | 11:52 |
| ssam2 | nowster: calling code is here, I think: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/cachedrepo.py#n170 | 11:52 |
| nowster | ta | 11:53 |
| ssam2 | i don't think those functions are heavily used so you can probably find your way around with 'git grep' | 11:53 |
| nowster | ok | 11:53 |
| ssam2 | the checkout code is simply: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/gitdir.py#n409 which hopefully isn't causing any issues! | 11:54 |
| jjardon | ssam2: you branch to bring back petrify is exactly what I needed, thanks! | 11:54 |
| jjardon | Do you plan to send it for review? | 11:54 |
| ssam2 | jjardon: no | 11:57 |
| straycat | oh man not this agian | 11:57 |
| ssam2 | I think something more like robtaylor's manifests proposal would be better | 11:57 |
| straycat | morph silently fails to include strata if they're not named "correctly" | 11:57 |
| ssam2 | jjardon: but i'm glad it's useful to you | 11:58 |
| pedroalvarez | straycat: yes, some of us have already raised this issue | 11:58 |
| straycat | yeah i know | 11:59 |
| straycat | i'm just raising it again | 11:59 |
| pedroalvarez | I think nobody is wokring on it though | 11:59 |
| straycat | radiofree spotted this ages ago | 11:59 |
| *** gfinney__ has joined #baserock | 12:02 | |
| *** gfinney_ has quit IRC | 12:05 | |
| jjardon | straycat: maybe file a bug in storyboard so it doesn't get forgotten again? | 12:09 |
| straycat | oh cool, where is the storyboard? | 12:11 |
| ssam2 | https://storyboard.baserock.org/ | 12:12 |
| * straycat waits patiently for an email | 12:18 | |
| straycat | okay, so i'll update the wiki to recommend ext4 for /src and maybe flesh out the advice on disk size? | 12:19 |
| ssam2 | please do | 12:19 |
| ssam2 | if you're hoping for storyboard to send emails, I don't think it does that yet | 12:20 |
| straycat | oh :'( | 12:20 |
| straycat | can i have an account then? :) | 12:21 |
| ssam2 | an account for what? | 12:22 |
| ssam2 | for storyboard, you should be able to just use your http://openid.baserock.org openID | 12:22 |
| straycat | i'm not sure i have one of those | 12:23 |
| straycat | that's why i tried to register and then waited so patiently for an email that was never destined to be :( | 12:23 |
| ssam2 | oh, if you were waiting for an email from openid.baserock.org, it's different | 12:24 |
| ssam2 | that should be working | 12:24 |
| ssam2 | sorry | 12:24 |
| straycat | haha no problem :3 | 12:24 |
| ssam2 | from /var/log/maillog: Feb 23 12:13:51 openid sendmail[8679]: t1NCDl3T008677: to=<richardipsum@fastmail.co.uk>, delay=00:00:04, xdelay=00:00:04, mailer=esmtp, pri=120467, relay=in2-smtp.messagingengine.com. [82.221.106.241], dsn=4.7.1, stat=Deferred: 451 4.7.1 <richardipsum@fastmail.co.uk>: Recipient address rejected: Temporary deferral, try again soon | 12:25 |
| ssam2 | not sure why that would happen, I don't understand sendmail at all | 12:25 |
| straycat | yeah that looks like my email address too | 12:26 |
| Kinnison | sendmail :( | 12:26 |
| ssam2 | could it just be sendmail being bad? would removing it and installed exim4 instead work and be simple? | 12:27 |
| ssam2 | I went with stock sendmail on this system because I didn't know any better | 12:27 |
| Kinnison | I doubt it's sendmail's fault per-se | 12:27 |
| ssam2 | right | 12:27 |
| Kinnison | fastmail might be greylisting | 12:34 |
| Kinnison | see if it retries | 12:34 |
| ssam2 | hmm, I should add a note to the 'An email has been sent' template to point this out | 12:37 |
| nowster | Ugh! FastMail. | 12:40 |
| persia | Even 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 |
| ssam2 | does that mean we need to maintain a relay host, though? | 12:44 |
| persia | Yes, but maintaining one instance of postfix/exim is far easier than maintaining one-per-application-server. | 12:44 |
| persia | And it lets one think more logically about mail transport in general, server availability, etc. | 12:45 |
| Kinnison | Pepperfish (who host baserock-dev) can also be used as a mail relay if you can teach your smtp-ta to use authenticated smarthosts | 12:57 |
| ssam2 | petefoth: I see 'All content is ©copyright the page author(s). The text of wiki.baserock.org is formally licensed under the Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0).' on the wiki now :) | 12:59 |
| ssam2 | looks good apart from the stray © symbol | 12:59 |
| petefoth | ssam2: I'll change the funny character | 13:00 |
| petefoth | I'll swap for (c) | 13:02 |
| persia | Don't. | 13:02 |
| persia | "(c)" has no meaning anywhere. | 13:02 |
| petefoth | OK I will do nothing. If people have strong opinions, I will let them edit | 13:03 |
| persia | I've read documentation suggesting © means something for Berne signatories. | 13:03 |
| petefoth | The 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 |
| Kinnison | The recommendation appears to be "Copyright © YEAR AUTHOR(s)" | 13:06 |
| nowster | the © symbol is optional | 13:08 |
| nowster | either "Copyright", "©" or both. | 13:09 |
| ssam2 | petefoth: the character showed up fine for me | 13: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 |
| ssam2 | it just seemed weird to say ©copyright which, as far as I know, means 'copyright copyright' | 13:11 |
| Kinnison | The UK recommendation is the word Copyright followed by the © symbol | 13:30 |
| straycat | nowster, What's wrong with fastmail? | 13:32 |
| nowster | ah... I was thinking of FastHosts... many many years ago. | 13:32 |
| straycat | ahh :) | 13:33 |
| *** tiagogomes_ has quit IRC | 13:33 | |
| petefoth | should the word 'Copyright always be capitalised or does it depend on its plave on the sentence? | 13:34 |
| petefoth | and space between 'Copyright' and the ©? | 13:34 |
| ssam2 | I've never seen it without a space | 13:36 |
| ssam2 | i don't know the answer to your other question | 13:36 |
| petefoth | ssam2: thanks | 13:36 |
| *** tiagogomes_ has joined #baserock | 13:48 | |
| petefoth | DOes 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 |
| rjek | petefoth: https://web.archive.org/web/20111014034340/http://wiki.baserock.org/ | 13:51 |
| rjek | That's the earliest snapshot archive.org have | 13:51 |
| ssam2 | first commit in the git history is Thu Sep 22 15:23:36 2011 +0000 | 13:51 |
| rjek | 2011-10-14 | 13:51 |
| petefoth | rjek: ssam2: thanks both | 13:51 |
| rjek | ah, there we go :) | 13:51 |
| *** zoli__ has quit IRC | 13:59 | |
| *** zoli__ has joined #baserock | 14:01 | |
| *** wschaller_ has quit IRC | 14:26 | |
| SotK | So 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 |
| bashrc | is there anywhere I can find out about morph extensions? | 14:27 |
| *** tiagogomes_ has quit IRC | 14:27 | |
| petefoth | bashrc: 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 |
| bashrc | so a morph extension adds some kind of custom functionality? | 14:30 |
| petefoth | bashrc: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/exts contains .help files | 14:30 |
| bashrc | ok thanks I'll read some of those | 14:31 |
| straycat | SotK, if the conversion is straight forward then a script for that would be cool | 14:31 |
| straycat | bashrc, you can also run $ morph help-extensions | 14:32 |
| petefoth | I 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 extensions | 14:32 |
| bashrc | aha | 14:32 |
| bashrc | is any of that on the wiki? | 14:33 |
| pedroalvarez | I'd try with the search box | 14:33 |
| petefoth | bashrc: some info in http://wiki.baserock.org/glossary/ | 14:34 |
| petefoth | and http://wiki.baserock.org/guides/deploy-to-hardware/ has some stuff on the pxeboot.write extension | 14:35 |
| petefoth | bashrc: and what pedroalvarez says :) | 14:35 |
| straycat | "Your account is now activated." \o/ | 14:35 |
| persia | SotK: a script sounds good to me as well. | 14:37 |
| * straycat begins "The tale of the missing artifacts" | 14:37 | |
| jjardon | Hi! Is there any work toward bootstrap OpenJDK with baserock? | 14:38 |
| pedroalvarez | there were some deep thinking about it some time ago, but I believe that nobody is spending time on that | 14:39 |
| *** tiagogomes_ has joined #baserock | 14:39 | |
| SotK | straycat, persia: a script it is then :) | 14:39 |
| persia | I 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 |
| persia | cache.baserock.org should probably have both caches for a while. | 14:40 |
| SotK | at the moment, the local cache using OSTree understands a remote cache using the current format | 14:43 |
| persia | Which format makes more sense for cache.baserock.org then? Especially considering the need to push new artifacts there regularly. | 14:44 |
| bashrc | I 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 definitions | 14:44 |
| persia | bashrc: I believe that was discussed at the meetup, and that was the planned way forward. | 14:45 |
| persia | We used to call them "morphologies", hence the .morph extension, and keep them in "morphologies.git". | 14:45 |
| petefoth | bashrc: the wiki is globally editable ;) | 14:45 |
| persia | bashrc: 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 |
| bashrc | petefoth: it is, but I would't presume to make a global terminology change without some consensus | 14:47 |
| persia | Also, it doesn't make sense while the codebase still uses the older terms. | 14:48 |
| petefoth | bashrc: 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 |
| persia | Is anyone actually doing it? I remember it being agreed, but I don't remember anyone volunteering to handle the implementation. | 14:49 |
| Zara | bashrc: I tend to refer to them as '.morph files', since it induces less panic than 'morphologies'. | 14:50 |
| petefoth | persia: | 14:51 |
| petefoth | persia: there's a story and several tasks, but none of them are yet assigned | 14:51 |
| petefoth | https://storyboard.baserock.org/#!/story/3 | 14:51 |
| persia | That matches my understanding. | 14:51 |
| persia | bashrc: ^^ : it's now confirmed that this is something you can do if you like :) | 14:52 |
| ssam2 | I believe jjardon is working on the task of adding versioning to definitions | 14:52 |
| ssam2 | but not the subsequent tasks of renaming everything | 14:52 |
| * bashrc hadn't noticed that there were no definition versions | 14:54 | |
| straycat | ssam2, jjardon, pedroalvarez, i've submitted a story for that bug now so hopefully we'll fix it one day | 14:58 |
| pedroalvarez | straycat: :) | 14:58 |
| *** lachlanmackenzie has quit IRC | 15:19 | |
| mauricemoss_ | Does anyone have objections against merging the two if blocks in _env_for_arch()? http://paste.baserock.org/ahadeyubik | 15:22 |
| ssam2 | looks fine to me | 15:23 |
| mauricemoss_ | ok, ta | 15:24 |
| pedroalvarez | that looks ok | 15:28 |
| *** lachlanmackenzie has joined #baserock | 15:30 | |
| *** ssam2 has quit IRC | 15:32 | |
| *** ssam2 has joined #baserock | 15:33 | |
| *** ChanServ sets mode: +v ssam2 | 15:33 | |
| *** zoli__ has quit IRC | 15:34 | |
| persia | Does POWER not need anything special in buildenvironment.py? | 15:36 |
| *** zoli__ has joined #baserock | 15:36 | |
| * persia is mostly concerned about potential issues with PPC vs. POWER, etc. | 15:36 | |
| persia | Also, we should have a default convention for 32/64 sufficies: the difference between mips64l and armv8l64 seems likely to be confusing. | 15:38 |
| Kinnison | persia: to be fair, mips and arm have different naming schemes | 15:39 |
| pedroalvarez | persia: I didn't need to chage buildenvironment.py for POWER | 15:39 |
| persia | Yes, but if morph is standardising the naming schemes, and then standardises inconsistently, it just makes me feel like http://xkcd.com/927/ | 15:40 |
| persia | If we accept upstream differences, let's just have morph use the strings from linux, or from gcc, or something else. | 15:40 |
| Kinnison | I'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 currently | 15:41 |
| persia | Do you men "compiles" or "complies"? | 15:42 |
| persia | Err, s/men/mean/ | 15:42 |
| Kinnison | complies | 15:42 |
| Kinnison | sorry, typing on my lap upside down with my leg in the air isn't easy | 15:42 |
| * Kinnison is stuck on the sofa with a bad leg :( | 15:42 | |
| persia | Ah good. I was hoping that was a typo. | 15:42 |
| persia | But yes, if we are inventing a new competing standard, I'd really rather pick one that was self-consistent. | 15:43 |
| persia | Otherwise I don't see why we shouldn't just have morph arch always match cpu arch. | 15:43 |
| persia | Picking ABI is a bit trickier, but we could presumably have a consistent optional suffix mechanism to use upstream ABI names. | 15:43 |
| rjek | The current scheme with mips64l and armv8l64 is consistent. [archname][endianness][optional varient# | 15:47 |
| rjek | ] | 15:47 |
| rjek | "mips64" and "armv8" are architecture names. | 15:47 |
| rjek | But ARMv8 has three different instruction sets/modes | 15:48 |
| rjek | It might actually be four, I don't know if they included Jazelle in v8. | 15:48 |
| persia | So, what are the three ARMv8 little-endian formats? | 15:49 |
| rjek | armv8l32 and armv8l64. | 15:51 |
| rjek | Putting 64 at the end of "mips64l" seems somewhat redundant. | 15:51 |
| persia | Except it's different. | 15:52 |
| *** zoli__ has quit IRC | 15:52 | |
| persia | In mixed-width mode, one runs a 64-bit kernel and a random collection of 32-bit and 64-bit apps. | 15:52 |
| persia | In 64-bit mode, one runs all 64-bit. | 15:52 |
| persia | Only in x86 is the architecture so frustratingly bound to the width. | 15:53 |
| rjek | That is a specialisation is is probably not worth accounting for, or you end up with things like armv8l64armv7b32 | 15:53 |
| persia | No I don't. | 15:53 |
| persia | arm is broken in the same way as x86, sadly. | 15:53 |
| persia | But MIPS and POWER do that normally. | 15:53 |
| persia | Which 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 #baserock | 15: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 in | 15:56 | |
| rjek | GNU triplets contain hardware vendor which is rarely important these days. | 15:57 |
| persia | The 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 names | 15:57 | |
| persia | After thinking about richard_maw's point, I think we ought just use raw GNU triplets, and not try to make it easier. | 15:58 |
| rjek | or copy Debian, but their solution is polluted with marketing nonsense https://wiki.debian.org/Multiarch/Tuples | 15:58 |
| persia | rjek: Where is the hardware vendor in "mips64el-baserock-linux-gnuabi64"? | 15:59 |
| rjek | persia: "linux" | 15:59 |
| rjek | On other systems, it's often "unknown" if the vendor is unimportant | 16:00 |
| persia | I thought that was the software platform name, but I can see how it was once hardware. | 16:00 |
| persia | But yeah, I think I like the Debian model. Almost entirely GNU triplets, with a few sensible extensions. | 16:00 |
| ssam2 | I thought the vendor field was the 2nd field, thus 'baserock' | 16:00 |
| persia | That morph hardcodes a 4-field "triplet" is one of the more mysterious parts of morph :) | 16:01 |
| rjek | Sadly the Debian model doesn't deal with different CPU subarchitectures/versions | 16:01 |
| ssam2 | persia: it's 3 parts | 16:02 |
| rjek | ie, it doesn't let you distinguish between ARMv5, 6, 7, or 8. | 16:02 |
| ssam2 | linux-gnuabi64 is one part, perversley | 16:02 |
| ssam2 | -e | 16:02 |
| rjek | And the i386 is a lie; Linux doesn't even run on the i386 anymore :) | 16:02 |
| persia | ssam2: That seems inconsistent with what is written at https://wiki.debian.org/Multiarch/Tuples | 16:03 |
| ssam2 | which part? | 16:03 |
| persia | rjek: 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 |
| persia | ssam2: The list of names. | 16:03 |
| ssam2 | that is documenting Debian arch fields, not GNU triplets, as far as I can see... | 16:03 |
| persia | Under "Used Solution" | 16:03 |
| persia | Where is says "Use normalized GNU triplets for most tuples, and extend the GNU triplet when it is ambiguous." | 16:04 |
| ssam2 | those differ from what I've previously seen of GNU triplets | 16:04 |
| rjek | persia: On the other hand, Debian's approach does not deal with incompatibilities between all the common ARM architecture versions. | 16:04 |
| persia | Dunno then. | 16:04 |
| ssam2 | persia: also differs from what I have one Fedora: x86_64-redhat-linux | 16:04 |
| ssam2 | where redhat is vendor, and linux is syscall API | 16:05 |
| ssam2 | -e again | 16:05 |
| persia | Right, but all the xamples from elsewhere only have two hyphens, which I think is the important part. | 16:05 |
| rjek | -EAGAIN? | 16:05 |
| persia | +e | 16:05 |
| ssam2 | fedora for ARM will be arm-redhat-linux-gnueabi, I imagine | 16:05 |
| persia | rjek: Yes. The lack of proper ARM support is entirely broken. | 16:05 |
| rjek | I 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 readable | 16:06 | |
| persia | rjek: 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 |
| rjek | Do we want to suppor the original RPi? :) | 16:07 |
| rjek | +t | 16:07 |
| ssam2 | persia: https://www.gnu.org/software/autoconf/manual/autoconf-2.60/html_node/Specifying-Names.html documents GNU triplets as being '‘cpu-vendor-os’ and then shows examples where OS is 'linux-gnu' | 16:08 |
| ssam2 | my point in saying this is to show that none of this craziness comes from Morph | 16:08 |
| *** a1exhughe5 has quit IRC | 16:10 | |
| * rjek is reminded of the NetSurf toolchain triplets; arm-unknown-riscos, i686-w64-wingw32, and the maddening nontriplet ppc-amigaos | 16:10 | |
| rdale | i'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 preamble | 16:10 |
| *** a1exhughe5 has joined #baserock | 16:11 | |
| ssam2 | rdale: what's glibc-specific about it? | 16:12 |
| persia | ssam2: 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 |
| persia | That 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 |
| ssam2 | I was a bit lost about what you mean about 'hardcoding linux', but as rdale points out, TARGET_STAGE1 is indeed defined by Morph | 16:13 |
| ssam2 | and TARGET | 16:13 |
| rdale | ssam2: env['TARGET_STAGE1'] = cpu + '-bootstrap-linux-gnu' + abi... means that linux-gnu for glibc support is hard code | 16:13 |
| ssam2 | oh, the 'linux-gnu' part is glibc... of course | 16:13 |
| ssam2 | yes, would be nice to figure out a way to set this in definitions instead | 16:13 |
| rdale | i've been building with 'x86_64-linux-musl' which works, but i haven't tried other cpu arches yet | 16:14 |
| ssam2 | since definitions are still per-arch, simply adding a list of environment variables to the system definitions that get set during build-time might be enough | 16:14 |
| ssam2 | so the system morph would set TARGET and TARGET_STAGE1 instead of Morph | 16:14 |
| ssam2 | but this adds complexity to everyone's system morphs that some probably don't want | 16:14 |
| persia | I want it, because I want non-linux | 16:15 |
| rdale | yes, i think it is only used by build-essential and maybe the 'cross-foobar' ones? | 16:15 |
| paulsherwood | ssam2: i don't think that's complexity really | 16:15 |
| persia | For 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 |
| persia | And 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 |
| ssam2 | to 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 morphs | 16:16 |
| ssam2 | MORPH_ARCH could probably be removed without too much pain, indeed | 16:17 |
| ssam2 | if we added TARGET and TARGET_STAGE1 to the system morphs | 16:17 |
| ssam2 | I guess TARGET_STAGE1 is just TARGET with the vendor field replaced | 16:17 |
| ssam2 | in most cases | 16:17 |
| ssam2 | so, OK, replacing the 'arch' field with something that gets set as TARGET would be fine | 16:17 |
| *** perryl_ has joined #baserock | 16:18 | |
| richard_maw | ssam2: 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 suitably | 16:19 |
| *** perryl has quit IRC | 16:19 | |
| ssam2 | richard_maw: we could just get cross-compilation working, instead. | 16:20 |
| ssam2 | :) | 16:20 |
| *** perryl_ is now known as perryl | 16:21 | |
| gfinney__ | I'm working on the YBD project (https://github.com/devcurmudgeon/ybd/) 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 http://paste.baserock.org/ituzexovub | 16:26 |
| ssam2 | gfinney__: there's no /build-essential/tools/bin directory in any chunks in the Baserock reference systems# | 16:28 |
| ssam2 | there is a /tools/bin directory created by the stage1-* and stage2-* chunks | 16:28 |
| ssam2 | but /tools/bin shouldn't be needed by anything outside the build-essential stratum | 16:28 |
| ssam2 | it may be a symlink at some point... | 16:29 |
| ssam2 | stage2-fhs-dirs does `ln -s "$PREFIX/bin" "$DESTDIR/bin"` | 16:30 |
| ssam2 | it might be that which is confusing ybd | 16:30 |
| gfinney__ | The reference to /tools/bin comes up as an apparent bug in the code | 16:32 |
| gfinney__ | It should be /src/staging/base-system-x86_64-generic-20150208-121158/build-essential.inst/tools/bin but is split | 16:32 |
| persia | richard_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 directory | 16:34 |
| gfinney__ | In the code, it lists the contencts of that directory and then tries to process the non-existent tools directory | 16:35 |
| gfinney__ | As far as I can tell, paulsherwood doesn't get this problem. | 16:36 |
| *** franred has quit IRC | 16:42 | |
| *** zoli__ has quit IRC | 16:44 | |
| *** zoli__ has joined #baserock | 16:46 | |
| *** gary_perkins has quit IRC | 17: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 |
| ssam2 | it's defined in stage2-fhs-dirs chunk as a symlink | 17:10 |
| ssam2 | I think | 17:10 |
| gfinney__ | I'll see if that's what it is. Thanks ssam2 | 17:11 |
| *** a1exhughe5 has quit IRC | 17: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 |
| ssam2 | you can send it and just note in the cover letter what the other patches that it depends on are | 17:20 |
| *** jonathanmaw has quit IRC | 17:21 | |
| mauricemoss_ | ok | 17:23 |
| *** lachlanmackenzie has quit IRC | 17:28 | |
| *** zoli__ has quit IRC | 17:36 | |
| *** gfinney__ has quit IRC | 17: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-gnu | 17: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 dashes | 17:42 |
| *** Krin has quit IRC | 17:42 | |
| *** mdizzle has quit IRC | 17:44 | |
| bashrc | in pxeboot.write it looks like there isn't any error handling for local and remote copying | 17:45 |
| persia | That should probably be fixed :) | 17:46 |
| * richard_maw used context managers to do all the resource cleanup | 17:47 | |
| bashrc | in 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 exist | 17:47 |
| persia | I'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_maw | bashrc: you run into TOCCTOU bugs if you do that check, as the files may not be there by the time you try the copy | 17:48 |
| richard_maw | bashrc: so you need to handle failure gracefully anyway | 17:48 |
| *** lachlanmackenzie has joined #baserock | 17:49 | |
| bashrc | yes I guess there could be timing issues (you check for a file, but it hasn't been written yet) | 17:49 |
| richard_maw | that kind of thing yeah | 17:49 |
| richard_maw | so 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 context | 17:50 |
| richard_maw | so if you get an exception after the local_pxelinux has been set up, then the pxelinux file gets removed again | 17:51 |
| richard_maw | is there something in particular biting you with the error handling? | 17:51 |
| bashrc | I was just reading it and wondering what happens if copy didn't work | 17:53 |
| *** petefoth_ has joined #baserock | 17:54 | |
| richard_maw | you 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 down | 17:55 |
| bashrc | ok, well that's something | 17:55 |
| *** petefoth has quit IRC | 17:56 | |
| *** petefoth_ is now known as petefoth | 17:56 | |
| richard_maw | bashrc: 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 IRC | 17:58 | |
| richard_maw | s/thing/think/ | 18:00 |
| tiagogomes_ | uboot pxe seems to not undestand tftp:// URLs | 18:11 |
| Kinnison | exceedingly unlikely it would | 18:12 |
| Kinnison | u-boot's "PXE" support is very rudimentary | 18:12 |
| Kinnison | And I *WISH* it wouldn't call itself PXE | 18:13 |
| Kinnison | because it's very NOT PXE | 18:13 |
| * Kinnison restrains himself from ranting though | 18:13 | |
| tiagogomes_ | Not sure what to do, pxeboot is already complicated enough | 18:14 |
| tiagogomes_ | maybe it makes sense to have a moonshoot write extension | 18:14 |
| Kinnison | Sadly I'm probably not able to advise you here | 18:14 |
| * Kinnison has never looked at the pxe stuff in Baserock | 18:14 | |
| *** Guest10998 has quit IRC | 18:19 | |
| *** ssam2 has quit IRC | 18:20 | |
| *** tiagogomes_ has quit IRC | 18:35 | |
| *** lachlanmackenzie has quit IRC | 19:18 | |
| *** rdale has quit IRC | 19:31 | |
| jjardon | Hi, 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 a | 19:51 |
| jjardon | read-only file system ... | 19:51 |
| persia | The recommendation I've seen for that before involves leaving the data wrong, and running it as a system integration script. | 19:58 |
| persia | The 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 |
| jjardon | unfortunately 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" way | 20:08 |
| persia | Good luck with it. It relies on having precisely the same filenames. | 20:10 |
| persia | We 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 |
| jjardon | oh, I think I found the hack: http://git.baserock.org/cgi-bin/cgit.cgi/delta/librsvg.git/commit/?h=baserock/morph&id=61171ca59d02b58b7da1697ca1d924bff93e66cb | 20:18 |
| persia | heh | 20:30 |
| *** lachlanmackenzie has joined #baserock | 21:04 | |
| *** lachlanmackenzie has quit IRC | 21:54 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!