| *** zoli__ has joined #baserock | 00:58 | |
| *** zoli__ has joined #baserock | 01:01 | |
| *** zoli__ has quit IRC | 03:03 | |
| *** petefoth has joined #baserock | 06:30 | |
| *** zoli__ has joined #baserock | 07:14 | |
| *** zoli__ has quit IRC | 07:41 | |
| *** a1exhughe5 has joined #baserock | 08:03 | |
| *** zoli__ has joined #baserock | 08:12 | |
| *** gfinney has joined #baserock | 08:13 | |
| *** gfinney_ has joined #baserock | 08:13 | |
| radiofree | how much ram does mason have? | 08:45 |
|---|---|---|
| *** mdizzle has joined #baserock | 08:47 | |
| *** bashrc has joined #baserock | 09:01 | |
| * pedroalvarez checks | 09:15 | |
| pedroalvarez | radiofree: 4G | 09:16 |
| pedroalvarez | erm... this is because we are going to put qt in the weston system? | 09:16 |
| radiofree | no i was testing it and thought "why don't i just add swap" | 09:17 |
| radiofree | 1 hour and 12 minutes is quite a bit faster than 3 hours and 44 minutes | 09:18 |
| pedroalvarez | assuming that your swap is on a ssd :) | 09:18 |
| radiofree | yes it was, but 4G might be ok for qtwebkit | 09:19 |
| radiofree | mason doesn't have an ssd? | 09:19 |
| SotK | I'd imagine the ARM distbuild it uses does | 09:20 |
| SotK | but I might be wrong | 09:20 |
| pedroalvarez | arm distbuild is on my desk currently :) | 09:20 |
| radiofree | that does yes, but it's also dead | 09:20 |
| SotK | how is mason building ARM artifacts then? | 09:20 |
| radiofree | it isn't? | 09:20 |
| * SotK is an idiot | 09:21 | |
| pedroalvarez | x86 mason is a vm in a openstack cloud, I don't know how fast is its storage | 09:21 |
| radiofree | well i'll submit a patch to remove max-jobs: 1 from qtwebkit and see how it goes? | 09:24 |
| radiofree | i don't think we should be forcing max-jobs: 1 on things just because we don't have enough ram on our laptops, it should only be for build failures related to doing anything different (e.g systemd) | 09:25 |
| radiofree | which now doesn't need it actually... | 09:25 |
| pedroalvarez | I wouldn't like that the feedback of mason was 3 h slower.. | 09:26 |
| radiofree | well it would be about 2 hours slower with all of qt | 09:27 |
| *** jonathanmaw has joined #baserock | 09:29 | |
| *** tiagogomes_ has joined #baserock | 09:32 | |
| *** gary_perkins has joined #baserock | 09:32 | |
| radiofree | and of course, not all the time, not unless you change something in the graphics stack | 09:34 |
| *** ssam2 has joined #baserock | 09:35 | |
| *** ChanServ sets mode: +v ssam2 | 09:35 | |
| ssam2 | seems that GNU Diff from master doesn't build on ARM... | 09:36 |
| ssam2 | definitions.git master that is | 09:36 |
| pedroalvarez | we need our arm mason back | 09:39 |
| radiofree | ssam2: i got [Build 271/277] [qtwebkit] Elapsed time 03:44:45 with max-jobs:1 | 09:42 |
| radiofree | and [Build 271/277] [qtwebkit] Elapsed time 01:12:48 with max-jobs removed and some swap added on the ssd | 09:42 |
| *** edcragg has joined #baserock | 09:47 | |
| ssam2 | radiofree: cool, thanks for the timings! | 09:49 |
| ssam2 | I guess 'max-jobs: 1' was there to avoid running out of RAM ? | 09:51 |
| radiofree | yeah | 09:52 |
| radiofree | but 2GB + swap on SSD is fine | 09:52 |
| ssam2 | anyone remember how much RAM a Highbank has? 4GB ? | 09:59 |
| ssam2 | per node, I mean | 10:00 |
| Kinnison | Highbank nodes were 4G each IIRC | 10:01 |
| ssam2 | radiofree: how big was the swap partition you set up? just for reference | 10:02 |
| pedroalvarez | 10G | 10:03 |
| pedroalvarez | <radiofree> add swap (just a 10GB file on the SSD, overkill...) [Build 271/277] [qtwebkit] Elapsed time 01:12:48 | 10:03 |
| ssam2 | ah, thanks | 10:03 |
| *** lachlanmackenzie has joined #baserock | 10:09 | |
| radiofree | i probably should have monitored how much of that it actually needed to use | 10:10 |
| radiofree | what's the quick way of changing all branch/tag refs to shas? | 10:12 |
| radiofree | also how can you check to see if morph is using a local checkout you maid with morph edit? | 10:12 |
| radiofree | s/maid/made oO | 10:12 |
| ssam2 | `morph petrify` converted refs to sha1s except it got removed | 10:14 |
| radiofree | oh :\ why? | 10:14 |
| ssam2 | for your second question, what do you mean by 'using' ? you mean you want to check if a change you made locally is being included in a system you're building? | 10:14 |
| ssam2 | radiofree: I think the problem was that the name was too complicated | 10:15 |
| radiofree | ssam2: no i want to see if it used the one i checked out with morph edit in a build | 10:15 |
| ssam2 | did you have a change in the repo after doing 'morph edit' ? | 10:15 |
| radiofree | yep | 10:15 |
| ssam2 | right ... if you look in the /baserock metadata of the deployed system (or any of the chunk artifacts) it'll show "repo": "file:///path/to/your/local/repo" if it used the local repo | 10:16 |
| ssam2 | did you deploy the system anywhere? | 10:16 |
| radiofree | i'm deploying it as we speak | 10:16 |
| ssam2 | right. look in /baserock/$chunk.meta (where $chunk is the one you edited) and check the 'repo' field | 10:16 |
| radiofree | so if i revert the commit that removed morph petrify i can use that to change the ref? qt5 has loads of repos and i don't particularly want to do that manually | 10:17 |
| ofcourseistilllo | i don't really get why we removed petrify | 10:17 |
| ofcourseistilllo | in fact i didn't realise we had removed it | 10:18 |
| ssam2 | radiofree: yeah, you might have to do a couple of fixups but reverting the removal is probably your best option | 10:18 |
| ssam2 | I'd welcome the 'petrify' command back to be honest, perhaps renamed to 'convert-refs-to-sha1s' or something | 10:18 |
| ssam2 | or it could be put in a separate tool that isn't morph (but still uses morphlib), to avoid having lots of commands in morph itself | 10:19 |
| tiagogomes_ | I think it was removed not because it was not useful but because it was broken | 10:21 |
| SotK | in what way was it broken? | 10:22 |
| *** lachlanmackenzie has quit IRC | 10:23 | |
| radiofree | ssam2: yep, it's using the edit | 10:24 |
| tiagogomes_ | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/commit/?id=d63f41dadf5aa96a8d9254d31e92711ee160245e | 10:24 |
| radiofree | however my definitions don't tell me that, how do i revert it using the edit? | 10:24 |
| radiofree | i have 10 repo: upstream:icu \n 11 ref: master in my stratum | 10:24 |
| radiofree | while it's nice to keep definitions always "petrified", it's a nightmare if you're trying to upgrade a large chunk like qt | 10:26 |
| radiofree | s/chunk/stratum | 10:26 |
| ssam2 | radiofree: god, I forget how this works .... I think Morph looks in your workspace for each chunk repo before it looks in the 'real' place | 10:28 |
| ssam2 | so if you have a git repo in your workspace with git config field 'morph.repository' set to 'upstream:icu', it'll build that repo instead of the 'real' 'upstream:icu' repo | 10:28 |
| ssam2 | so just hide your local clone | 10:28 |
| ofcourseistilllo | yes, i think if you want to use the remote 'master' then you'd need to remove the repo from your workspace or mv it or something | 10:29 |
| tiagogomes_ | I'l like to morph was more clear about which repo is using | 10:29 |
| tiagogomes_ | I'd | 10:30 |
| * ofcourseistilllo agrees | 10:30 | |
| ssam2 | tiagogomes_: that'd be easy to implement, just add an app.status() call for each repo that Morph picks up from the workspace | 10:31 |
| ssam2 | would be quite nice to have that | 10:31 |
| ssam2 | buildbranch.py might be the place to add it, or plugins/build_plugin.py | 10:31 |
| * pedroalvarez plans to move paramiko, markupsafe and jinja2 to python-core | 10:31 | |
| ssam2 | seems fair | 10:32 |
| ofcourseistilllo | i'm suddenly a little confused as to how you reproduce something that's using local checkouts, when the fact that you're using a local checkout isn't specified in the definitions | 10:33 |
| radiofree | yeah it's massively confusing, i thought i was using master of upstream | 10:33 |
| ofcourseistilllo | pedroalvarez, sorry to be annoying but can i ask why, just curious? | 10:33 |
| pedroalvarez | ofcourseistilllo: sure, currently only ansible is using them, but some services in openstack need them as well. So the change would be to avoid duplication or to avoid a weird dependency (openstack -> ansible) | 10:36 |
| mauricemoss_ | Hi, I'm having issues with the way Morph builds gcc for the native-bootstrap. If Morph builds from a "file://" gcc repo with the gcc/config/mips/mips.h change, it works fine. However if Morph builds from upstream:gcc-tarball and changes mips.h after copying the files for the chunk (e.g. Line 49), the native-bootstrap fails with "Segmentation fault". http://paste.baserock.org/anaxenuvoq Could this be related to the fix in stage2 | 10:38 |
| mauricemoss_ | -gcc-fixed-headers.morph? | 10:38 |
| tiagogomes_ | mauricemoss_ are you mounting the API file systems? /proc /sys .... | 10:39 |
| *** edcragg has quit IRC | 10:40 | |
| *** lachlanmackenzie has joined #baserock | 10:40 | |
| radiofree | qt5.4! in weston! on a jetson! using nouveau! browsing the web! using webgl! http://seriousinternetbusiness.com/james/webgl.mp4 | 10:40 |
| mauricemoss_ | tiagogomes_ No, why should I mount them manually? | 10:41 |
| *** edcragg has joined #baserock | 10:41 | |
| pedroalvarez | radiofree: GREAT! | 10:41 |
| ofcourseistilllo | I personally think we should try and keep python-core pretty minimal since a lot of the systems are using it, I'd suggest putting those things in another stratum, python-something, I don't know what to call it and have openstack and ansible build depend on that. | 10:43 |
| pedroalvarez | ofcourseistilllo: I agree | 10:43 |
| tiagogomes_ | mauricemoss_ I a script, let me see if I can find it | 10:44 |
| tiagogomes_ | I use a | 10:44 |
| robtaylor | ssam2: one thing possibly wotrth trying for qt is to parallel build but use LDFLAG --no-keep-memory | 10:45 |
| radiofree | robtaylor: it's only qtwebkit that has the problem | 10:46 |
| radiofree | i just added some swap and then it parallel builds fine | 10:46 |
| radiofree | 03:44:45 -> 01:12:48 | 10:46 |
| robtaylor | radiofree: that is awesome (qt5.4! in weston! on a jetson! using nouveau! browsing the web! using webgl!) | 10:48 |
| tiagogomes_ | mauricemoss_ this is what I use to enter the chroot: http://paste.baserock.org/opewikejux | 10:49 |
| robtaylor | radiofree: i think needs a blog :) | 10:50 |
| mauricemoss_ | tiagogomes_, thanks! I'll try it. | 10:51 |
| *** wschaller has joined #baserock | 10:52 | |
| jjardon | radiofree: nice, Wayland or xwayland? | 10:56 |
| radiofree | wayland, gl doesn't work with xwayland | 10:58 |
| radiofree | next stop, gnome3? | 10:58 |
| jjardon | I guess we have to activate x11 support in mesa and the xserver to make it work | 10:59 |
| wdutch | thanks for the fix richard_maw, I've deployed a new devel to openstack :) | 11:00 |
| nowster | hmm... pretty much every source file in the kernel tree has been 'touched' by morph so the kernel build system thinks the tree's been modified. | 11:00 |
| jjardon | Yep, still need some patches that are currently in review, like the python3 one | 11:01 |
| pedroalvarez | nowster: yes, morph does that :/ | 11:01 |
| nowster | how -dirty of it | 11:01 |
| ssam2 | it does it because of clever build systems that regenerate stuff based on timestamps | 11:04 |
| ssam2 | if timestamps aren't all the same, you end up with autoconf trying to regenerate your configure script when it doesn't need to, etc | 11:04 |
| ssam2 | (this is only a problem when we build from tarballs that have been put into git of course.. nobody should be committing generated configure scripts to git otherwise) | 11:05 |
| bwh | And morph is clevererer (not) | 11:05 |
| ssam2 | it's a shame this makes kbuild thing that the git tree is -dirty, though... if it actually asked Git whether the tree was dirty, it'd find out that it wasn't | 11:12 |
| bwh | I'm pretty sure it *is* asking git | 11:16 |
| bwh | and git checks the timestamps and sees they've changed, so it assumes the tree is dirty | 11:17 |
| bwh | I've seen that before and git won't believe it's clean until you run a 'git diff' | 11:17 |
| ssam2 | all the ways I've seen of finding out if a repo is dirty have involved 'git diff' (or the plumbing things like 'git diff-index') | 11:19 |
| nowster | It *is* asking git. | 11:19 |
| ssam2 | right | 11:19 |
| ssam2 | but in a way that means that it gets the wrong answer | 11:20 |
| nowster | # Check for uncommitted changes | 11:20 |
| nowster | if git diff-index --name-only HEAD | grep -qv "^scripts/package" | 11:20 |
| nowster | ; then | 11:20 |
| nowster | printf '%s' -dirty | 11:20 |
| nowster | fi | 11:20 |
| nowster | scripts/setlocalversion | 11:20 |
| nowster | whilst it's building, it considers the tree to be clean | 11:21 |
| nowster | It's only at install time that it considers it dirty. | 11:21 |
| ssam2 | right | 11:21 |
| *** zoli__ has quit IRC | 11:22 | |
| ssam2 | the man page of `git diff-index` says that it ' Compares the content and mode of the blobs found in a tree object with the corresponding tracked files in the working tree, or with the corresponding paths in the index'. | 11:22 |
| nowster | ...and that includes things like .gitignore | 11:22 |
| ssam2 | so seems like timestamps wouldn't confuse it | 11:22 |
| ssam2 | oh, maybe morph is changing .gitmodules? | 11:22 |
| ssam2 | but then the kernel tree doesn't have submodules, afaik | 11:22 |
| nowster | I've got an "ls -l" on the root of the kernel tree before and after a build... I'll let you know what the difference is. | 11:22 |
| mauricemoss_ | tiagogomes_, Building after mounting /proc, /sys, etc. produced a seg fault as well. Could it be that Morph is doing some magic copying chunks again and thereby using the wrong mips.h file? | 11:26 |
| radiofree | html5 video is not playing, missing all kinds of plugins | 11:30 |
| tiagogomes_ | mauricemoss_ what are you putting on file and what is the name of your system branch? | 11:33 |
| tiagogomes_ | mauricemoss_ file:// | 11:34 |
| mauricemoss_ | only binutils with the fix I sent to the list. This is my build-essential.morph http://paste.baserock.org/ozafecogul | 11:36 |
| nowster | Really odd. The timestamps and file permissions appear identical. | 11:38 |
| tiagogomes_ | mauricemoss_ you wrote above if you use file:://location/of/gcc it works. Are you sure that location/of/gcc and upstream:gcc-tarball is the same checkout besides the change to mips.h? | 11:41 |
| robtaylor | whos' interested in ostree? | 11:43 |
| *** persia_ has quit IRC | 11:43 | |
| ofcourseistilllo | ssam2 is i think | 11:45 |
| *** gfinney has quit IRC | 11:46 | |
| *** gfinney_ has quit IRC | 11:46 | |
| ssam2 | SotK is :) | 11:46 |
| *** gfinney has joined #baserock | 11:46 | |
| *** gfinney_ has joined #baserock | 11:46 | |
| mauricemoss_ | tiagogomes_ yes, when using "file://" `git log -p` in the local gcc repo: http://paste.baserock.org/niyexadefi with this build-essential.morph http://paste.baserock.org/qetabudupo | 11:46 |
| ofcourseistilllo | btw, minor point but can we put the build logs somewhere generally more visible to the user? | 11:49 |
| *** gfinney_ has quit IRC | 11:49 | |
| ofcourseistilllo | people keep asking where they are | 11:49 |
| *** gfinney has quit IRC | 11:49 | |
| * pedroalvarez facepalms | 11:49 | |
| ofcourseistilllo | distbuild puts them in the workspace | 11:49 |
| pedroalvarez | ansible has .gitmodules | 11:49 |
| *** zoli__ has joined #baserock | 11:49 | |
| *** gfinney has joined #baserock | 11:49 | |
| *** gfinney_ has joined #baserock | 11:49 | |
| ofcourseistilllo | pedroalvarez, ? | 11:50 |
| *** gfinney_ has quit IRC | 11:50 | |
| ssam2 | ofcourseisstilllo: I think we need a 'view build log for chunk' command to be honest | 11:50 |
| pedroalvarez | oh, looks like it doesn't have .gitmodules in the version that we have integrated, :) | 11:50 |
| ssam2 | since the user may not have them locally at all | 11:51 |
| ssam2 | might have been built by Mason, for example | 11:51 |
| pedroalvarez | that can cause some confusion: "hey, my build fails but the build log says that it has been built" | 11:52 |
| ssam2 | it has to take definitions repo/ref somehow too | 11:53 |
| *** zoli__ has quit IRC | 11:53 | |
| ssam2 | thus the user's build should turn out the same as if the Mason builds it | 11:53 |
| *** zoli__ has joined #baserock | 11:54 | |
| ofcourseistilllo | mmm | 11:54 |
| ofcourseistilllo | i guess a tool would be more convenient than expecting the user to find the cache key | 11:55 |
| ofcourseistilllo | or check access times... | 11:56 |
| ssam2 | i don't think I'll be doing a 15.08 release this week. Found quite a few bugs in the build-graph speeds branch | 11:59 |
| ssam2 | plus build failed on ARM | 11:59 |
| ssam2 | maybe some time next week. I'd still like a release soon with pylru present. | 12:00 |
| *** petefoth has quit IRC | 12:13 | |
| nowster | # git diff-index --name-status HEAD | 12:19 |
| nowster | M .gitignore | 12:19 |
| nowster | M .mailmap | 12:19 |
| nowster | M COPYING | 12:19 |
| nowster | M CREDITS | 12:19 |
| nowster | M Documentation/00-INDEX | 12:19 |
| nowster | M Documentation/ABI/README | 12:19 |
| nowster | etc. etc. | 12:19 |
| nowster | so, it thinks they're modified... | 12:21 |
| ssam2 | wow, that's really strange | 12:26 |
| jjardon | radiofree: this is the regression to not update mesa: https://bugs.freedesktop.org/show_bug.cgi?id=86701 | 12:27 |
| robtaylor | ssam2: SotK: some cool new things coming to ostree https://github.com/GNOME/ostree/pull/54 | 12:28 |
| radiofree | " | 12:29 |
| radiofree | Unfortunantly, VirtualBox probably isn't going to support running drm-backend properly for a long time, plus a software fallback would be nice for fallback some hardware platforms" | 12:29 |
| robtaylor | (esp the streaming and bsdiff bits) | 12:29 |
| franred | http://paste.baserock.org/hiwegeloki , someone knows what this python package needs to be compiled? Has to be obvious because baserock is able to compile it but I can not do it manually | 12:45 |
| *** mdizzle has quit IRC | 12:46 | |
| nowster | :100644 100644 ca442d313d86dc67e0a2e5d584b465bd382cbf5c 0000000000000000000000000000000000000000 M COPYING | 12:59 |
| nowster | manpage says: 8. sha1 for "dst"; 0{40} if creation, unmerged or "look at work tree". | 12:59 |
| radiofree | jjardon: --enable-shared ... | 13:07 |
| * pedroalvarez fixes delta/python-setuptools-bitbucket.git lorry | 13:10 | |
| *** wschaller has quit IRC | 13:16 | |
| ofcourseistilllo | oh? | 13:24 |
| ofcourseistilllo | is it broken? | 13:24 |
| pedroalvarez | ofcourseistilllo: wasn't lorrying: http://paste.baserock.org/biqinawuvu | 13:26 |
| radiofree | jjardon: youtube needs a h.264 decoder :\ | 13:32 |
| jjardon | radiofree: try x264 ? | 13:33 |
| jjardon | radiofree: with gst-libav | 13:33 |
| radiofree | that's just an encoder though? | 13:35 |
| jjardon | uh, true, let me check | 13:35 |
| jjardon | radiofree: yeah, I think there is a h264 decoder in gst-libav | 13:37 |
| radiofree | avdec_h264 | 13:38 |
| jjardon | yep | 13:40 |
| ssam2 | ironically, the 'manage-baserock' chroot script seems to be broken in Baserock | 13:40 |
| ssam2 | I was trying to set up an x86_32 chroot in an x86_64 devel VM | 13:41 |
| jjardon | radiofree: maybe its a good idea to investigate if the jetson has some hardware decoders we can use with gstreamer? | 13:41 |
| ssam2 | oh, I guess there's no 'schroot' anyway | 13:41 |
| jjardon | http://elinux.org/Jetson/H264_Codec !! | 13:42 |
| jjardon | seems we need the gst-omx plugins | 13:43 |
| radiofree | jjardon: there's some source on https://developer.nvidia.com/linux-tegra-rel-21 as well | 13:44 |
| radiofree | however gst-egl fails to compile for me (needs X11 stuff) | 13:44 |
| jjardon | radiofree: what exactly? | 13:45 |
| radiofree | erm.. X11Window i think | 13:45 |
| radiofree | i didn't really spend much time looking into it, let's get this working first | 13:46 |
| radiofree | haha youtube works now! (with libav) | 13:47 |
| jjardon | \o/ | 13:47 |
| pedroalvarez | :) | 13:48 |
| SotK | is artifact metadata (stored in the artifact cache) ever anything other than the artifact.meta file which appears in /baserock? | 13:50 |
| pedroalvarez | SotK: so <cache_key>.meta files? | 13:52 |
| jjardon | radiofree: I have ogg and vorbis as part of my gnome stratum, do you want me to move them to multimedia or are you already preparing a patch? | 13:53 |
| radiofree | you do it | 13:53 |
| SotK | pedroalvarez: I was meaning the files which in the cache are <cache_key>.<kind>.<name>.meta | 13:54 |
| ssam2 | SotK: yes, there can be a .build-log, and other stuff | 13:54 |
| ssam2 | I actually did a patch which improves how this is handled, but didn't send it yet | 13:55 |
| radiofree | jjardon: create a multimedia-common | 13:55 |
| SotK | does anyone have opinions on how these metadata files should be handled using OSTree? | 13:55 |
| radiofree | qtwebkit uses gstreamer 1, but qtmultimedia uses 0.10 | 13:55 |
| pedroalvarez | SotK: I only see <cache-key>.stratum.<name>,meta files | 13:56 |
| ssam2 | SotK: yes ;) | 13:56 |
| SotK | ssam2: what are they? :) | 13:56 |
| ssam2 | see http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/commit/?h=sam/fix-fetch-errors&id=81905d738a1343ad1d9da7f3977743c04601f0ba | 13:57 |
| ssam2 | which adds a source.files() method | 13:57 |
| ssam2 | there are later commits in that branch too, probably better look at source.py in master of that branch | 13:57 |
| ssam2 | so I only have opinions on how the code should look, not how the files are actually stored | 13:57 |
| ssam2 | at a guess, it makes sense to store metadata independently of OSTree so it's easier to access .build-log files etc. | 13:58 |
| ssam2 | at least for now | 13:58 |
| ssam2 | in fact, http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2014-May/005688.html is a good design for how artifact metadata should actually be implemented | 13:58 |
| ssam2 | I don't know if you have time to do all that now | 13:58 |
| jjardon | radiofree: ok, still no progress on that btw? | 13:59 |
| ssam2 | but the current method is basically "different parts of the code each guess what files are needed" and it sucks | 13:59 |
| ssam2 | mainly because if you download a chunk from the cache instead of building it, you don't get the .build-log file, but you might want to look at how it was built | 13:59 |
| ssam2 | anyone remember how to fix 'mount: / is not mountpoint or bad option' errors from linux-user-chroot when building in a chroot ? | 14:01 |
| ssam2 | I seem to remember there was some workaround involving bindmounts or something | 14:01 |
| richard_maw | sometimes bind-mounting the chroot's / to itself from outside the chroot works, but the most reliable way is to have the chroot's root come from a different disk | 14:02 |
| radiofree | jjardon: doesn't look like it | 14:03 |
| jjardon | bad Qt :P | 14:03 |
| ssam2 | richard_maw: a different disk compared to /src ? | 14:03 |
| ssam2 | that's possible I guess | 14:03 |
| richard_maw | bind mounting should work, which makes it more irritating when it doesn't | 14:06 |
| ssam2 | I still get the error when /src is a different volume | 14:11 |
| ssam2 | tempdir is definitely in /src | 14:11 |
| jjardon | can we remove the qt4 systemd? | 14:12 |
| jjardon | can we remove the qt4 system? | 14:12 |
| ssam2 | oh, I never mounted /proc /sys or /dev | 14:15 |
| ssam2 | that might not help ! | 14:15 |
| persia | Last time I was playing with chroots, I ended up creating a large loopback file, loop-mounting it on /mnt, and chrooting to /mnt to use morph without errors. | 14:20 |
| *** fay_ has quit IRC | 14:34 | |
| nowster | This is really really weird. I've inserted an "exit 99" in the install phase, chrooted into the "failed" staging directory, and "git diff-index HEAD" is coming up as clean. | 14:47 |
| nowster | more coffee needed | 14:48 |
| ssam2 | persia: aha. if I bindmount the chroot directory at /mnt and chroot into that, everything is fine | 14:48 |
| ssam2 | this is why 'enter-baserock' / schroot doesn't have this issue, I guess | 14:48 |
| *** wschaller has joined #baserock | 14:48 | |
| nowster | /linux-mips64b-edgerouterpro.build # make kernelrelease | 14:48 |
| nowster | 3.19.0-gd1a9b75 | 14:48 |
| persia | schroot does all kinds of good magic. | 14:49 |
| *** fay_ has joined #baserock | 14:50 | |
| radiofree | remove morph petrify doesn't revert cleanly, sigh | 14:55 |
| radiofree | so the only way now is to manually go through every ref in qt5-tools.morph and replace it with the sha? | 14:56 |
| ssam2 | commit d63f41dadf5aa96a8d9254d31e92711ee160245e reverted OK for me | 14:57 |
| radiofree | yes but it doesn't actually work | 14:57 |
| radiofree | AttributeError: 'Morph' object has no attribute 'resolve_ref' | 14:57 |
| radiofree | maybe i can downgrade to the commit before it was removed, run it, then go back? | 14:58 |
| SotK | did we remove it before or after the chunks in definitions work? | 14:58 |
| ssam2 | august 10th... so not sure | 14:58 |
| jjardon | radiofree: I own you a beer if you make petrify back ;) | 14:59 |
| radiofree | manually doing this has got to be the worst workflow possible | 15:00 |
| radiofree | are there any examples, in master, of strata that don't use a petrified ref? | 15:01 |
| radiofree | if i suppose it with "ref: v5.4.0" will it get shot down instantly? | 15:01 |
| radiofree | s/suppose/submit | 15:01 |
| persia | Please, please, don't put petrify back. | 15:07 |
| jjardon | persia: why not? | 15:07 |
| SotK | persia: why not? | 15:07 |
| persia | Instead, add a tool that lets you set the SHA1 ref for a given chunk from the command line. It should optionally take a branch/tag argument to use that branch/tag, and otherwise default to HEAD of the current local git repo. | 15:08 |
| persia | Because the idea of petrifying and unpetrifying definitions is fundamentally broken in my mind. | 15:08 |
| persia | One typically wants to work on some small subset of components, and make changes. | 15:08 |
| persia | And it's probably best practice to cause commits in definitions to happen when those changes are made, so you can track things, for cleanup later. | 15:09 |
| nowster | hmm... the kernel that's made that way also seems to think it's dirty. | 15:09 |
| persia | The mechanics in morph to magically do this for you have largely been reduced, but the need for it to be done hasn't gone away, and putting all that back in morph just makes it slower and more unwieldy. | 15:09 |
| *** zoli__ has quit IRC | 15:09 | |
| jjardon | persia: not everyone work in a small set of components | 15:10 |
| SotK | persia: I don't want unpetrify back, I just want petrify | 15:10 |
| jjardon | yeah petrify would be enough | 15:10 |
| SotK | I'd like to be able to write a stratum with tags/branches in, then once I know they are working run a command to turn them all into shas | 15:11 |
| SotK | if that stratum doesn't already exist, I currently have to paste shas even with a tool to update an existing sha | 15:12 |
| jjardon | SotK: agree, exactly what I need | 15:12 |
| jjardon | in my case I would master for each component, but yeah the idea is the same | 15:13 |
| ssam2 | radiofree, jjardon: try morph.git branch sam/petrify-hack | 15:19 |
| ssam2 | is based off master so you'll need pylru in your pythonpath, or a really uptodate baserock system | 15:19 |
| radiofree | oooh it seems to be doing something | 15:21 |
| radiofree | persia: that's fine for individual components (if a little annoying still), but if you're updating things like qt5 it's a massive pain in the arse | 15:22 |
| radiofree | hmmm didn't work ERROR: Failed to update cached version of repo git://git.baserock.org/delta/diff-lcs | 15:24 |
| radiofree | seems that's been moved? http://git.baserock.org/cgi-bin/cgit.cgi/delta/ruby-gems/diff-lcs.git/ | 15:24 |
| radiofree | seems that this want's to clone absolutely everything in definitions first | 15:27 |
| * jjardon will try to send his wip gnome stratum today so people understand why petrify can be useful ;) | 15:27 | |
| ssam2 | radiofree: yeah, it doesn't seem to be resolving refs with the remote repo cache | 15:28 |
| ssam2 | not sure why | 15:28 |
| radiofree | ssam2: yes it worked!! | 15:28 |
| radiofree | thanks! | 15:28 |
| ssam2 | wicked | 15:28 |
| *** Krin has quit IRC | 15:32 | |
| jjardon | ok to lorry gdm? http://paste.baserock.org/opazaticiv | 15:38 |
| ssam2 | +1 | 15:43 |
| ssam2 | i wonder if we should have a gnome/ prefix for stuff from gnome.org, since there's loads of stuff... | 15:43 |
| ssam2 | bit late now though | 15:43 |
| Zara | question: how does baserock get from the source code to the stuff in this repo? http://git.baserock.org/cgi-bin/cgit.cgi/delta/pytz.git/tree/?h=trunk | 15:44 |
| radiofree | ssam2: there hasn't been a baserock/gnome release yet, so it wouldn't break anything to move them now? | 15:45 |
| ofcourseistilllo | Zara, not sure i understand the question | 15:46 |
| SotK | Zara: from which source code? | 15:47 |
| persia | radiofree: For a large set of things like that, do they share a tag or branch name? | 15:48 |
| radiofree | persia: yes, v5.4.0 | 15:49 |
| tiagogomes_ | is a subsystem just a system that gets deployed before the parent system, or there is anything more special about it | 15:49 |
| Zara | so there's this thing: http://pkgs.fedoraproject.org/repo/pkgs/pytz/pytz-2014.9.tar.gz/d42bda2f4c1e873e02fbd1e4acfd1b8c/ and there's this thing: http://git.baserock.org/cgi-bin/cgit.cgi/delta/pytz.git/commit/?h=trunk&id=46021a739fac6878f7250bb4a57acd0f789f5362 | 15:49 |
| pedroalvarez | tiagogomes_: is a system that gets deployed into the parent system | 15:50 |
| ssam2 | radiofree: might break downstream troves | 15:50 |
| ssam2 | anyone could be using baserock and not admitting it :) | 15:51 |
| Zara | they're very different. my question is how the latter ends up very different. | 15:51 |
| ssam2 | Zara: they are totally unrelated | 15:51 |
| persia | radiofree: Would an extension to the tool I describe to do all the parsing&update to a tag/branch for an entire stratum meet your goal? | 15:52 |
| ssam2 | zara: as far as I can see... or am I wrong? | 15:52 |
| radiofree | persia: yes, if i could do `tool strata/qt5-tools.morph upgrade to v5.4.0` that would be fine | 15:52 |
| ssam2 | zara: each repo in git.baserock.org is imported by a mirroring tool called Lorry, driven by a .lorry file | 15:53 |
| ssam2 | all the .lorry files live in a repo on git.baserock.org too | 15:53 |
| ssam2 | for pytz the file is this: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/local-config/lorries.git/tree/open-source-lorries/pytz.lorry | 15:53 |
| persia | I was thinking `${TOOL} --entire-stratum strata/qt5-tools.morph v5.4.0`, but that's the idea. | 15:53 |
| ssam2 | zara: which suggests that it's doing a Bzr import from Launchpad | 15:53 |
| ssam2 | see http://wiki.baserock.org/Lorry/ for more info on Lorry | 15:53 |
| ssam2 | zara: in the Bazaar version control system, lp:pytz is a shorthand for https://launchpad.net/pytz | 15:54 |
| ssam2 | https://bazaar.launchpad.net/~stub/pytz/devel/files looks a lot more like thing: http://git.baserock.org/cgi-bin/cgit.cgi/delta/pytz.git/commit/?h=trunk&id=46021a739fac6878f7250bb4a57acd0f789f5362 | 15:54 |
| Zara | ssam2: (maybe the fedora one was a bad example) but they should both be derived from the same place, https://pypi.python.org/pypi/pytz/ (though this is the 2014.10 version, not sure where it got the 2014.9 version) | 15:54 |
| ssam2 | it comes from wherever the relevant .lorry file says it comes from | 15:55 |
| ssam2 | the .lorry files live here: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/local-config/lorries.git/tree/open-source-lorries | 15:56 |
| ofcourseistilllo | Zara, in some cases the source repo on github or whatever isn't a "release" repo, is that the problem you're having? | 15:56 |
| ssam2 | might be nice if cgit on git.baserock.org linked to the .lorry file in question to make things clearer... | 15:56 |
| jjardon | ssam2: Id prefer to not use prefixes: normally when I search for a package I type http://git.baserock.org/cgi-bin/cgit.cgi/delta/<name> . It happens before I though the package doesnt exist in g.b.o because is inside a prefix | 15:57 |
| radiofree | persia: but i think it still should just convert refs != sha to a sha | 15:58 |
| Zara | ssam2: okay, thanks, I understand better now (I thought the repo was generated at the baserock end) | 15:58 |
| radiofree | say if you're working in a strata that has v5.4.1 and v5.4.0, or some new component v1.0.0 etc... | 15:58 |
| Zara | (rather than being a copy of an existing repo) | 15:58 |
| SotK | radiofree: +1 | 15:58 |
| jjardon | ssam2: +1, useful sometime to know what we are the source we are mirroring | 15:59 |
| persia | radiofree: That makes it annoying for the single-repo case, where I want to move from old-SHA to new-SHA, by running `${TOOL} ${chunk-name}` | 15:59 |
| jjardon | ssam2: +1, useful sometimes to know what we are the source we are mirroring | 15:59 |
| tlsa | jjardon: search like this and it finds with prefixes http://git.baserock.org/cgi-bin/cgit.cgi/?q=<name> | 15:59 |
| ofcourseistilllo | Zara, I note that src/README.txt of delta/pyts states: | 15:59 |
| ofcourseistilllo | If you are installing from a tarball, run the following command as an | 15:59 |
| ofcourseistilllo | administrative user:: | 15:59 |
| tlsa | jjardon: e.g. http://git.baserock.org/cgi-bin/cgit.cgi/?q=pciaccess | 15:59 |
| persia | radiofree: Also, it means that if a stratum has a mix of SHAs and non-SHAs, the results are opaque. And lastly, it means that if I want to update my stratum that is all SHA1s, I have to go manually unsha them first. | 16:00 |
| ofcourseistilllo | python setup.py install | 16:00 |
| SotK | persia: maybe it needs two different tools? | 16:00 |
| persia | Maybe :) | 16:00 |
| radiofree | persia: for that case couldn't you very quickly just replace ref: with ref: mytag and run the tool? | 16:00 |
| radiofree | that ref: to tag bit is easy, it's getting the sha afterwards that's annoying | 16:00 |
| jjardon | tlsa: thats handy, thanks | 16:00 |
| persia | radiofree: Means digging through the files to adjust the ref. Yes, but still annoying. | 16:00 |
| *** zoli__ has joined #baserock | 16:02 | |
| Zara | (so I thought we were getting a tarball, doing something to it to turn it into a repo, and then using that repo for things) | 16:02 |
| ofcourseistilllo | No | 16:02 |
| ofcourseistilllo | you're lorrying from a bzr repo | 16:02 |
| Zara | yeah, I get it now | 16:02 |
| ofcourseistilllo | okay cool | 16:02 |
| ofcourseistilllo | I think we should be lorrying the tarball really | 16:08 |
| radiofree | hmm should i add qtwayland to qt5-tools or create a new qt5-tools-wayland stratum? | 16:12 |
| radiofree | it will work in qt5-tools, since it build-depends on x-generic, which build-depends on mesa-common, which build-depends on wayland | 16:13 |
| jjardon | radiofree: I think qt-tools is fine | 16:20 |
| * jjardon send his current GNOME stratum to the list | 16:26 | |
| jjardon | persia: can you understand my pain if I have to convert all the refs of all those modules to sha's manually? | 16:27 |
| persia | jjardon: Absolutely. I have been complaining about that pain for more than a year. I just believe that the petrify/unpetrify mechanism is the worst possible way to deal with that. | 16:29 |
| *** a1exhughe5 has quit IRC | 16:52 | |
| *** zoli__ has joined #baserock | 16:58 | |
| *** ssam2 has quit IRC | 17:01 | |
| *** sambishop has quit IRC | 17:12 | |
| *** edcragg has quit IRC | 17:12 | |
| *** edcragg has joined #baserock | 17:13 | |
| *** jonathanmaw has quit IRC | 17:42 | |
| *** bashrc has quit IRC | 17:49 | |
| *** wschaller has quit IRC | 17:50 | |
| *** zoli__ has quit IRC | 18:01 | |
| jjardon | radiofree: https://git.gnome.org/browse/gnome-continuous/tree/src/js/tasks/testbase.js | 18:03 |
| *** zoli__ has joined #baserock | 18:09 | |
| radiofree | jjardon: nothing magic there, try and get the xorg.conf/x arguments used when they start things up | 18:10 |
| radiofree | probably required digging around in one of the img files | 18:10 |
| *** zoli__ has quit IRC | 18:12 | |
| jjardon | yep, let see if I manage to work on this over the weekend | 18:20 |
| *** lachlanmackenzie has quit IRC | 18:21 | |
| nowster | # make kernelrelease | 18:28 |
| nowster | 3.19.0-gd1a9b75-dirty | 18:28 |
| nowster | # git status | 18:28 |
| nowster | HEAD detached at d1a9b75 | 18:28 |
| nowster | nothing to commit, working directory clean | 18:28 |
| nowster | # make kernelrelease | 18:28 |
| nowster | 3.19.0-gd1a9b75 | 18:28 |
| nowster | ...and on that bombshell, I go and have a weekend | 18:28 |
| *** gary_perkins has quit IRC | 18:32 | |
| *** tiagogomes_ has quit IRC | 18:34 | |
| *** edcragg has quit IRC | 18:37 | |
| *** zoli__ has joined #baserock | 18:56 | |
| *** zoli__ has quit IRC | 18:57 | |
| *** gfinney has quit IRC | 19:43 | |
| *** zoli__ has joined #baserock | 20:55 | |
| *** zoli__ has joined #baserock | 22:10 | |
| *** edcragg has joined #baserock | 23:37 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!