IRC logs for #baserock for Friday, 2015-02-20

*** zoli__ has joined #baserock00:58
*** zoli__ has joined #baserock01:01
*** zoli__ has quit IRC03:03
*** petefoth has joined #baserock06:30
*** zoli__ has joined #baserock07:14
*** zoli__ has quit IRC07:41
*** a1exhughe5 has joined #baserock08:03
*** zoli__ has joined #baserock08:12
*** gfinney has joined #baserock08:13
*** gfinney_ has joined #baserock08:13
radiofreehow much ram does mason have?08:45
*** mdizzle has joined #baserock08:47
*** bashrc has joined #baserock09:01
* pedroalvarez checks09:15
pedroalvarezradiofree: 4G09:16
pedroalvarezerm... this is because we are going to put qt in the weston system?09:16
radiofreeno i was testing it and thought "why don't i just add swap"09:17
radiofree1 hour and 12 minutes is quite a bit faster than 3 hours and 44 minutes09:18
pedroalvarezassuming that your swap is on a ssd :)09:18
radiofreeyes it was, but 4G might be ok for qtwebkit09:19
radiofreemason doesn't have an ssd?09:19
SotKI'd imagine the ARM distbuild it uses does09:20
SotKbut I might be wrong09:20
pedroalvarezarm distbuild is on my desk currently :)09:20
radiofreethat does yes, but it's also dead09:20
SotKhow is mason building ARM artifacts then?09:20
radiofreeit isn't?09:20
* SotK is an idiot09:21
pedroalvarezx86 mason is a vm in a openstack cloud, I don't know how fast is its storage09:21
radiofreewell i'll submit a patch to remove max-jobs: 1 from qtwebkit and see how it goes?09:24
radiofreei 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
radiofreewhich now doesn't need it actually...09:25
pedroalvarezI wouldn't like that the feedback of mason was 3 h slower..09:26
radiofreewell it would be about 2 hours slower with all of qt09:27
*** jonathanmaw has joined #baserock09:29
*** tiagogomes_ has joined #baserock09:32
*** gary_perkins has joined #baserock09:32
radiofreeand of course, not all the time, not unless you change something in the graphics stack09:34
*** ssam2 has joined #baserock09:35
*** ChanServ sets mode: +v ssam209:35
ssam2seems that GNU Diff from master doesn't build on ARM...09:36
ssam2definitions.git master that is09:36
pedroalvarezwe need our arm mason back09:39
radiofreessam2: i got [Build 271/277] [qtwebkit] Elapsed time 03:44:45 with max-jobs:109:42
radiofreeand  [Build 271/277] [qtwebkit] Elapsed time 01:12:48 with max-jobs removed and some swap added on the ssd09:42
*** edcragg has joined #baserock09:47
ssam2radiofree: cool, thanks for the timings!09:49
ssam2I guess 'max-jobs: 1' was there to avoid running out of RAM ?09:51
radiofreebut 2GB + swap on SSD is fine09:52
ssam2anyone remember how much RAM a Highbank has? 4GB ?09:59
ssam2per node, I mean10:00
KinnisonHighbank nodes were 4G each IIRC10:01
ssam2radiofree: how big was the swap partition you set up? just for reference10:02
pedroalvarez<radiofree> add swap (just a 10GB file on the SSD, overkill...)  [Build 271/277] [qtwebkit] Elapsed time 01:12:4810:03
ssam2ah, thanks10:03
*** lachlanmackenzie has joined #baserock10:09
radiofreei probably should have monitored how much of that it actually needed to use10:10
radiofreewhat's the quick way of changing all branch/tag refs to shas?10:12
radiofreealso how can you check to see if morph is using a local checkout you maid with morph edit?10:12
radiofrees/maid/made oO10:12
ssam2`morph petrify` converted refs to sha1s except it got removed10:14
radiofreeoh :\ why?10:14
ssam2for 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
ssam2radiofree: I think the problem was that the name was too complicated10:15
radiofreessam2: no i want to see if it used the one i checked out with morph edit in a build10:15
ssam2did you have a change in the repo after doing 'morph edit' ?10:15
ssam2right ... 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 repo10:16
ssam2did you deploy the system anywhere?10:16
radiofreei'm deploying it as we speak10:16
ssam2right. look in /baserock/$chunk.meta (where $chunk is the one you edited) and check the 'repo' field10:16
radiofreeso 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 manually10:17
ofcourseistillloi don't really get why we removed petrify10:17
ofcourseistillloin fact i didn't realise we had removed it10:18
ssam2radiofree: yeah, you might have to do a couple of fixups but reverting the removal is probably your best option10:18
ssam2I'd welcome the 'petrify' command back to be honest, perhaps renamed to 'convert-refs-to-sha1s' or something10:18
ssam2or it could be put in a separate tool that isn't morph (but still uses morphlib), to avoid having lots of commands in morph itself10:19
tiagogomes_I think it was removed not because it was not useful but because it was broken10:21
SotKin what way was it broken?10:22
*** lachlanmackenzie has quit IRC10:23
radiofreessam2: yep, it's using the edit10:24
radiofreehowever my definitions don't tell me that, how do i revert it using the edit?10:24
radiofreei have  10   repo: upstream:icu \n 11   ref: master in my stratum10:24
radiofreewhile it's nice to keep definitions always "petrified", it's a nightmare if you're trying to upgrade a large chunk like qt10:26
ssam2radiofree: god, I forget how this works .... I think Morph looks in your workspace for each chunk repo before it looks in the 'real' place10:28
ssam2so 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' repo10:28
ssam2so just hide your local clone10:28
ofcourseistillloyes, 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 something10:29
tiagogomes_I'l like to morph was more clear about which repo is using10:29
* ofcourseistilllo agrees10:30
ssam2tiagogomes_: that'd be easy to implement, just add an app.status() call for each repo that Morph picks up from the workspace10:31
ssam2would be quite nice to have that10:31 might be the place to add it, or plugins/build_plugin.py10:31
* pedroalvarez plans to move paramiko, markupsafe and jinja2 to python-core10:31
ssam2seems fair10:32
ofcourseistillloi'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 definitions10:33
radiofreeyeah it's massively confusing, i thought i was using master of upstream10:33
ofcourseistilllopedroalvarez, sorry to be annoying but can i ask why, just curious?10:33
pedroalvarezofcourseistilllo: 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". Could this be related to the fix in stage210:38
tiagogomes_mauricemoss_ are you mounting the API file systems? /proc /sys ....10:39
*** edcragg has quit IRC10:40
*** lachlanmackenzie has joined #baserock10:40
radiofreeqt5.4! in weston! on a jetson! using nouveau! browsing the web! using webgl!
mauricemoss_tiagogomes_ No, why should I mount them manually?10:41
*** edcragg has joined #baserock10:41
pedroalvarezradiofree: GREAT!10:41
ofcourseistillloI 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
pedroalvarezofcourseistilllo: I agree10:43
tiagogomes_mauricemoss_ I a script, let me see if I can find it10:44
tiagogomes_I use a10:44
robtaylorssam2: one thing possibly wotrth trying for qt is to parallel build but use LDFLAG  --no-keep-memory10:45
radiofreerobtaylor: it's only qtwebkit that has the problem10:46
radiofreei just added some swap and then it parallel builds fine10:46
radiofree03:44:45 -> 01:12:4810:46
robtaylorradiofree: 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:
robtaylorradiofree: i think needs a blog :)10:50
mauricemoss_tiagogomes_, thanks! I'll try it.10:51
*** wschaller has joined #baserock10:52
jjardonradiofree: nice, Wayland or xwayland?10:56
radiofreewayland, gl doesn't work with xwayland10:58
radiofreenext stop, gnome3?10:58
jjardonI guess we have to activate x11 support in mesa and the xserver to make it work10:59
wdutchthanks for the fix richard_maw, I've deployed a new devel to openstack :)11:00
nowsterhmm... 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
jjardonYep, still need some patches that are currently in review, like the python3 one11:01
pedroalvareznowster: yes, morph does that :/11:01
nowsterhow -dirty of it11:01
ssam2it does it because of clever build systems that regenerate stuff based on timestamps11:04
ssam2if timestamps aren't all the same, you end up with autoconf trying to regenerate your configure script when it doesn't need to, etc11: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
bwhAnd morph is clevererer (not)11:05
ssam2it'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't11:12
bwhI'm pretty sure it *is* asking git11:16
bwhand git checks the timestamps and sees they've changed, so it assumes the tree is dirty11:17
bwhI've seen that before and git won't believe it's clean until you run a 'git diff'11:17
ssam2all 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
nowsterIt *is* asking git.11:19
ssam2but in a way that means that it gets the wrong answer11:20
nowster                # Check for uncommitted changes11:20
nowster                if git diff-index --name-only HEAD | grep -qv "^scripts/package"11:20
nowster; then11:20
nowster                        printf '%s' -dirty11:20
nowster                fi11:20
nowsterwhilst it's building, it considers the tree to be clean11:21
nowsterIt's only at install time that it considers it dirty.11:21
*** zoli__ has quit IRC11:22
ssam2the 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 .gitignore11:22
ssam2so seems like timestamps wouldn't confuse it11:22
ssam2oh, maybe morph is changing .gitmodules?11:22
ssam2but then the kernel tree doesn't have submodules, afaik11:22
nowsterI'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
radiofreehtml5 video is not playing, missing all kinds of plugins11: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
nowsterReally 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
robtaylorwhos' interested in ostree?11:43
*** persia_ has quit IRC11:43
ofcourseistilllossam2 is i think11:45
*** gfinney has quit IRC11:46
*** gfinney_ has quit IRC11:46
ssam2SotK is :)11:46
*** gfinney has joined #baserock11:46
*** gfinney_ has joined #baserock11:46
mauricemoss_tiagogomes_ yes, when using "file://" `git log -p` in the local gcc repo: with this build-essential.morph
ofcourseistilllobtw, minor point but can we put the build logs somewhere generally more visible to the user?11:49
*** gfinney_ has quit IRC11:49
ofcourseistilllopeople keep asking where they are11:49
*** gfinney has quit IRC11:49
* pedroalvarez facepalms11:49
ofcourseistilllodistbuild puts them in the workspace11:49
pedroalvarezansible has .gitmodules11:49
*** zoli__ has joined #baserock11:49
*** gfinney has joined #baserock11:49
*** gfinney_ has joined #baserock11:49
ofcourseistilllopedroalvarez, ?11:50
*** gfinney_ has quit IRC11:50
ssam2ofcourseisstilllo: I think we need a 'view build log for chunk' command to be honest11:50
pedroalvarezoh, looks like it doesn't have .gitmodules in the version that we  have integrated, :)11:50
ssam2since the user may not have them locally at all11:51
ssam2might have been built by Mason, for example11:51
pedroalvarezthat can cause some confusion: "hey, my build fails but the build log says that it has been built"11:52
ssam2it has to take definitions repo/ref somehow too11:53
*** zoli__ has quit IRC11:53
ssam2thus the user's build should turn out the same as if the Mason builds it11:53
*** zoli__ has joined #baserock11:54
ofcourseistillloi guess a tool would be more convenient than expecting the user to find the cache key11:55
ofcourseistillloor check access times...11:56
ssam2i don't think I'll be doing a 15.08 release this week. Found quite a few bugs in the build-graph speeds branch11:59
ssam2plus build failed on ARM11:59
ssam2maybe some time next week. I'd still like a release soon with pylru present.12:00
*** petefoth has quit IRC12:13
nowster# git diff-index --name-status HEAD12:19
nowsterM       .gitignore12:19
nowsterM       .mailmap12:19
nowsterM       COPYING12:19
nowsterM       CREDITS12:19
nowsterM       Documentation/00-INDEX12:19
nowsterM       Documentation/ABI/README12:19
nowsteretc. etc.12:19
nowsterso, it thinks they're modified...12:21
ssam2wow, that's really strange12:26
jjardonradiofree: this is the regression to not update mesa:
robtaylorssam2: SotK: some cool new things coming to ostree
radiofreeUnfortunantly, 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 , 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 manually12:45
*** mdizzle has quit IRC12:46
nowster:100644 100644 ca442d313d86dc67e0a2e5d584b465bd382cbf5c 0000000000000000000000000000000000000000 M      COPYING12:59
nowstermanpage says:         8. sha1 for "dst"; 0{40} if creation, unmerged or "look at work tree".12:59
radiofreejjardon: --enable-shared ...13:07
* pedroalvarez fixes delta/python-setuptools-bitbucket.git lorry13:10
*** wschaller has quit IRC13:16
ofcourseistilllois it broken?13:24
pedroalvarezofcourseistilllo: wasn't lorrying:
radiofreejjardon: youtube needs a h.264 decoder :\13:32
jjardonradiofree: try x264 ?13:33
jjardonradiofree: with gst-libav13:33
radiofreethat's just an encoder though?13:35
jjardonuh, true, let me check13:35
jjardonradiofree: yeah, I think there is a h264 decoder in gst-libav13:37
ssam2ironically, the 'manage-baserock' chroot script seems to be broken in Baserock13:40
ssam2I was trying to set up an x86_32 chroot in an x86_64 devel VM13:41
jjardonradiofree: maybe its a good idea to investigate if the jetson has some hardware decoders we can use with gstreamer?13:41
ssam2oh, I guess there's no 'schroot' anyway13:41
jjardon !!13:42
jjardonseems we need the gst-omx plugins13:43
radiofreejjardon: there's some source on as well13:44
radiofreehowever gst-egl fails to compile for me (needs X11 stuff)13:44
jjardonradiofree: what exactly?13:45
radiofreeerm.. X11Window i think13:45
radiofreei didn't really spend much time looking into it, let's get this working first13:46
radiofreehaha youtube works now! (with libav)13:47
SotKis artifact metadata (stored in the artifact cache) ever anything other than the artifact.meta file which appears in /baserock?13:50
pedroalvarezSotK: so <cache_key>.meta files?13:52
jjardonradiofree: 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
radiofreeyou do it13:53
SotKpedroalvarez: I was meaning the files which in the cache are <cache_key>.<kind>.<name>.meta13:54
ssam2SotK: yes, there can be a .build-log, and other stuff13:54
ssam2I actually did a patch which improves how this is handled, but didn't send it yet13:55
radiofreejjardon: create a multimedia-common13:55
SotKdoes anyone have opinions on how these metadata files should be handled using OSTree?13:55
radiofreeqtwebkit uses gstreamer 1, but qtmultimedia uses 0.1013:55
pedroalvarezSotK: I only see <cache-key>.stratum.<name>,meta files13:56
ssam2SotK: yes ;)13:56
SotKssam2: what are they? :)13:56
ssam2which adds a source.files() method13:57
ssam2there are later commits in that branch too, probably better look at in master of that branch13:57
ssam2so I only have opinions on how the code should look, not how the files are actually stored13:57
ssam2at a guess, it makes sense to store metadata independently of OSTree so it's easier to access .build-log files etc.13:58
ssam2at least for now13:58
ssam2in fact, is a good design for how artifact metadata should actually be implemented13:58
ssam2I don't know if you have time to do all that now13:58
jjardonradiofree: ok, still no progress on that btw?13:59
ssam2but the current method is basically "different parts of the code each guess what files are needed" and it sucks13:59
ssam2mainly 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 built13:59
ssam2anyone remember how to fix 'mount: / is not mountpoint or bad option' errors from linux-user-chroot when building in a chroot ?14:01
ssam2I seem to remember there was some workaround involving bindmounts or something14:01
richard_mawsometimes 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 disk14:02
radiofreejjardon: doesn't look like it14:03
jjardonbad Qt :P14:03
ssam2richard_maw: a different disk compared to /src ?14:03
ssam2that's possible I guess14:03
richard_mawbind mounting should work, which makes it more irritating when it doesn't14:06
ssam2I still get the error when /src is a different volume14:11
ssam2tempdir is definitely in /src14:11
jjardoncan we remove the qt4 systemd?14:12
jjardoncan we remove the qt4 system?14:12
ssam2oh, I never mounted /proc /sys or /dev14:15
ssam2that might not help !14:15
persiaLast 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 IRC14:34
nowsterThis 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
nowstermore coffee needed14:48
ssam2persia: aha. if I bindmount the chroot directory at /mnt and chroot into that, everything is fine14:48
ssam2this is why 'enter-baserock' / schroot doesn't have this issue, I guess14:48
*** wschaller has joined #baserock14:48
nowster/ # make kernelrelease14:48
persiaschroot does all kinds of good magic.14:49
*** fay_ has joined #baserock14:50
radiofreeremove morph petrify doesn't revert cleanly, sigh14:55
radiofreeso the only way now is to manually go through every ref in qt5-tools.morph and replace it with the sha?14:56
ssam2commit d63f41dadf5aa96a8d9254d31e92711ee160245e reverted OK for me14:57
radiofreeyes but it doesn't actually work14:57
radiofreeAttributeError: 'Morph' object has no attribute 'resolve_ref'14:57
radiofreemaybe i can downgrade to the commit before it was removed, run it, then go back?14:58
SotKdid we remove it before or after the chunks in definitions work?14:58
ssam2august 10th... so not sure14:58
jjardonradiofree: I own you a beer if you make petrify back ;)14:59
radiofreemanually doing this has got to be the worst workflow possible15:00
radiofreeare there any examples, in master, of strata that don't use a petrified ref?15:01
radiofreeif i suppose it with "ref: v5.4.0" will it get shot down instantly?15:01
persiaPlease, please, don't put petrify back.15:07
jjardonpersia: why not?15:07
SotKpersia: why not?15:07
persiaInstead, 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
persiaBecause the idea of petrifying and unpetrifying definitions is fundamentally broken in my mind.15:08
persiaOne typically wants to work on some small subset of components, and make changes.15:08
persiaAnd 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
nowsterhmm... the kernel that's made that way also seems to think it's dirty.15:09
persiaThe 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 IRC15:09
jjardonpersia: not everyone work in a small set of components15:10
SotKpersia: I don't want unpetrify back, I just want petrify15:10
jjardonyeah petrify would be enough15:10
SotKI'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 shas15:11
SotKif that stratum doesn't already exist, I currently have to paste shas even with a tool to update an existing sha15:12
jjardonSotK: agree, exactly what I need15:12
jjardonin my case I would master for each component, but yeah the idea is the same15:13
ssam2radiofree, jjardon: try morph.git branch sam/petrify-hack15:19
ssam2is based off master so you'll need pylru in your pythonpath, or a really uptodate baserock system15:19
radiofreeoooh it seems to be doing something15:21
radiofreepersia: 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 arse15:22
radiofreehmmm didn't work ERROR: Failed to update cached version of repo git://
radiofreeseems that's been moved?
radiofreeseems that this want's to clone absolutely everything in definitions first15:27
* jjardon will try to send his wip gnome stratum today so people understand why petrify can be useful ;)15:27
ssam2radiofree: yeah, it doesn't seem to be resolving refs with the remote repo cache15:28
ssam2not sure why15:28
radiofreessam2: yes it worked!!15:28
*** Krin has quit IRC15:32
jjardonok to lorry gdm?
ssam2i wonder if we should have a gnome/ prefix for stuff from, since there's loads of stuff...15:43
ssam2bit late now though15:43
Zaraquestion: how does baserock get from the source code to the stuff in this repo?
radiofreessam2: there hasn't been a baserock/gnome release yet, so it wouldn't break anything to move them now?15:45
ofcourseistillloZara, not sure i understand the question15:46
SotKZara: from which source code?15:47
persiaradiofree: For a large set of things like that, do they share a tag or branch name?15:48
radiofreepersia: yes, v5.4.015:49
tiagogomes_is a subsystem just a system that gets deployed before the parent system, or there is anything more special about it15:49
Zaraso there's this thing: and there's this thing:
pedroalvareztiagogomes_: is a system that gets deployed into the parent system15:50
ssam2radiofree: might break downstream troves15:50
ssam2anyone could be using baserock and not admitting it :)15:51
Zarathey're very different. my question is how the latter ends up very different.15:51
ssam2Zara: they are totally unrelated15:51
persiaradiofree: 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
ssam2zara: as far as I can see... or am I wrong?15:52
radiofreepersia: yes, if i could do `tool strata/qt5-tools.morph upgrade to v5.4.0` that would be fine15:52
ssam2zara: each repo in is imported by a mirroring tool called Lorry, driven by a .lorry file15:53
ssam2all the .lorry files live in a repo on too15:53
ssam2for pytz the file is this:
persiaI was thinking `${TOOL} --entire-stratum strata/qt5-tools.morph v5.4.0`, but that's the idea.15:53
ssam2zara: which suggests that it's doing a Bzr import from Launchpad15:53
ssam2see for more info on Lorry15:53
ssam2zara: in the Bazaar version control system, lp:pytz is a shorthand for
ssam2 looks a lot more like thing:
Zarassam2: (maybe the fedora one was a bad example) but they should both be derived from the same place, (though this is the 2014.10 version, not sure where it got the 2014.9 version)15:54
ssam2it comes from wherever the relevant .lorry file says it comes from15:55
ssam2the .lorry files live here:
ofcourseistillloZara, in some cases the source repo on github or whatever isn't a "release" repo, is that the problem you're having?15:56
ssam2might be nice if cgit on linked to the .lorry file in question to make things clearer...15:56
jjardonssam2: Id prefer to not use prefixes: normally when I search for a package I type<name> . It happens before I though the package doesnt exist in g.b.o because is inside a prefix15:57
radiofreepersia: but i think it still should just convert refs != sha to a sha15:58
Zarassam2: okay, thanks, I understand better now (I thought the repo was generated at the baserock end)15:58
radiofreesay 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
SotKradiofree: +115:58
jjardonssam2: +1, useful sometime to know what we are the source we are mirroring15:59
persiaradiofree: 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
jjardonssam2: +1, useful sometimes to know what we are the source we are mirroring15:59
tlsajjardon: search like this and it finds with prefixes<name>15:59
ofcourseistillloZara, I note that src/README.txt of delta/pyts states:15:59
ofcourseistillloIf you are installing from a tarball, run the following command as an15:59
ofcourseistillloadministrative user::15:59
tlsajjardon: e.g.
persiaradiofree: 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 install16:00
SotKpersia: maybe it needs two different tools?16:00
persiaMaybe :)16:00
radiofreepersia: for that case couldn't you very quickly just replace ref: with ref: mytag and run the tool?16:00
radiofreethat ref: to tag bit is easy, it's getting the sha afterwards that's annoying16:00
jjardontlsa: thats handy, thanks16:00
persiaradiofree: Means digging through the files to adjust the ref.  Yes, but still annoying.16:00
*** zoli__ has joined #baserock16: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
ofcourseistillloyou're lorrying from a bzr repo16:02
Zarayeah, I get it now16:02
ofcourseistilllookay cool16:02
ofcourseistillloI think we should be lorrying the tarball really16:08
radiofreehmm should i add qtwayland to qt5-tools or create a new qt5-tools-wayland stratum?16:12
radiofreeit will work in qt5-tools, since it build-depends on x-generic, which build-depends on mesa-common, which build-depends on wayland16:13
jjardonradiofree: I think qt-tools is fine16:20
* jjardon send his current GNOME stratum to the list16:26
jjardonpersia: can you understand my pain if I have to convert all the refs of all those modules to sha's manually?16:27
persiajjardon: 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 IRC16:52
*** zoli__ has joined #baserock16:58
*** ssam2 has quit IRC17:01
*** sambishop has quit IRC17:12
*** edcragg has quit IRC17:12
*** edcragg has joined #baserock17:13
*** jonathanmaw has quit IRC17:42
*** bashrc has quit IRC17:49
*** wschaller has quit IRC17:50
*** zoli__ has quit IRC18:01
*** zoli__ has joined #baserock18:09
radiofreejjardon: nothing magic there, try and get the xorg.conf/x arguments used when they start things up18:10
radiofreeprobably required digging around in one of the img files18:10
*** zoli__ has quit IRC18:12
jjardonyep, let see if I manage to work on this over the weekend18:20
*** lachlanmackenzie has quit IRC18:21
nowster# make kernelrelease18:28
nowster# git status18:28
nowsterHEAD detached at d1a9b7518:28
nowsternothing to commit, working directory clean18:28
nowster# make kernelrelease18:28
nowster...and on that bombshell, I go and have a weekend18:28
*** gary_perkins has quit IRC18:32
*** tiagogomes_ has quit IRC18:34
*** edcragg has quit IRC18:37
*** zoli__ has joined #baserock18:56
*** zoli__ has quit IRC18:57
*** gfinney has quit IRC19:43
*** zoli__ has joined #baserock20:55
*** zoli__ has joined #baserock22:10
*** edcragg has joined #baserock23:37

Generated by 2.15.3 by Marius Gedminas - find it at!