| *** rdale_ has joined #baserock | 02:30 | |
| *** rdale has quit IRC | 02:34 | |
| *** dabukalam has quit IRC | 03:17 | |
| *** dabukalam has joined #baserock | 03:18 | |
| *** dabukalam has joined #baserock | 03:18 | |
| *** zoli__ has joined #baserock | 06:27 | |
| *** a1exhughe5 has joined #baserock | 07:07 | |
| pedroalvarez | Albert: are you around? | 08:08 |
|---|---|---|
| Albert | I am | 08:08 |
| pedroalvarez | In your email you say that 6.2 doesn't build right? So that you want to apply the patch that you have sent to a previous tag | 08:09 |
| pedroalvarez | Or are you suggesting to apply the patch to 6.2? I'm a bit confused | 08:10 |
| Albert | Sorry if I was unclear. The patch need to be applied to 6.2 | 08:11 |
| *** mariaderidder has joined #baserock | 08:12 | |
| pedroalvarez | ah, ok. Part of my confusion is caused by an email in one of the Genivi lists complaining about 6.2 not building for other reasons. | 08:13 |
| Albert | Oh? Not aware of that one. | 08:13 |
| *** bashrc has joined #baserock | 08:15 | |
| pedroalvarez | Albert: also, part of my confusion is caused by the fact that the typos that you are fixing, doesn't exist in the 6.2 tag | 08:15 |
| pedroalvarez | for example: http://git.baserock.org/cgi-bin/cgit.cgi/delta/audiomanager.git/tree/AudioManagerDaemon/CMakeLists.txt?id=57c2f4ea0148287d0bcea913cb34ba716489df4b#n165 | 08:15 |
| pedroalvarez | Your patches seems to change SOURCES for SOUCRES, and in the sourcecode I already see the latter | 08:16 |
| *** mariaderidder has quit IRC | 08:17 | |
| Albert | Line 165 says SOUCRES instead of SOURCES | 08:17 |
| pedroalvarez | I totally agree, but your patch is the following: | 08:17 |
| pedroalvarez | -COMMON_API_GENERATE_SOURCES(TARGET COMMON_API | 08:17 |
| pedroalvarez | +COMMON_API_GENERATE_SOUCRES(TARGET COMMON_API | 08:17 |
| pedroalvarez | to me, it means the other way around | 08:18 |
| *** edcragg has joined #baserock | 08:18 | |
| Albert | ?? That's odd. I took that straight from the diffs | 08:18 |
| pedroalvarez | indeed, it's odd. | 08:19 |
| Albert | Ah, it could be that I did the diff the wrong way round | 08:20 |
| pedroalvarez | :) | 08:20 |
| pedroalvarez | anyway, I understand the problem now | 08:20 |
| Albert | Cheersz | 08:21 |
| rdale_ | you should use 'git format-patch..' and 'git send-email..' for sending patches to a mailing list | 08:21 |
| pedroalvarez | yes, that's another point | 08:21 |
| Albert | Well, one continues to learn | 08:21 |
| pedroalvarez | rdale_: although I'm afraid we have removed that bit from the contributing page | 08:22 |
| rdale_ | oh ok - i think the instructions should still be there as we can't always use gerrit | 08:24 |
| *** mariaderidder has joined #baserock | 08:25 | |
| *** mike has joined #baserock | 08:26 | |
| *** mike is now known as Guest18305 | 08:26 | |
| *** gary_perkins has joined #baserock | 08:28 | |
| *** tiagogomes_ has joined #baserock | 08:28 | |
| pedroalvarez | rdale_: I agree | 08:36 |
| *** jonathanmaw has joined #baserock | 08:36 | |
| rdale_ | i'm just trying to edit the wiki page - if i have a google login for codethink, can that be used as an openid? | 08:37 |
| pedroalvarez | rdale_: also, looks like we might have a use case for it when patching delta repos | 08:37 |
| pedroalvarez | iirc google dropped openid support | 08:37 |
| pedroalvarez | baserock openid should work | 08:37 |
| pedroalvarez | Albert: biff | 08:38 |
| rdale_ | do i have a baserock openid - how do i tell? | 08:38 |
| * petefoth will reinstate some information about submitting patches to the ML | 08:38 | |
| petefoth | UNless anyone else is about to do it | 08:39 |
| DavePage | petefoth: Put it on the wiki ;) | 08:39 |
| rdale_ | yes, please do if i can't - but i would still like to be able to edit the wiki | 08:39 |
| petefoth | rdale_: then get yourself a baserock OpenID | 08:39 |
| rdale_ | i'm on the page about editing the wiki, but it doesn't say how to get a baserock openid | 08:40 |
| petefoth | I'll add that too shall I? ;) | 08:40 |
| pedroalvarez | hahah | 08:40 |
| rdale_ | thanks - i can test the instructions then | 08:41 |
| pedroalvarez | I can see something in the contributing page about our openid | 08:42 |
| pedroalvarez | but sadly, under "Set up a gerrit account" | 08:42 |
| rdale_ | ah so i must have one already | 08:42 |
| petefoth | Any other use cases fpor submitting patches to the ML rather than via gerrit? (The ones I have are 1. if gerrit is unavailable; 2. Patches for delta repos | 08:43 |
| pedroalvarez | that's it, I think | 08:44 |
| pedroalvarez | I can't thing of more use cases | 08:44 |
| Albert | I'm going to have to patch the morph file for AudioManager. Which branch? | 08:44 |
| pedroalvarez | Albert: I don't understand your question | 08:44 |
| pedroalvarez | the morph file shold be in the definitions repository | 08:44 |
| petefoth | I was thinking of 'refactoring' the 'Contributing' page to esnure that it is logical and coherent, rather than just a dumping ground for anything vaguely relating to 'contributing' | 08:45 |
| DavePage | petefoth: That sounds like a useful contribution | 08:45 |
| petefoth | DavePage: Oh! I won't do it then ;) | 08:45 |
| rjek | Ansible creator says immutable systems are the future: http://michaeldehaan.net/post/118717252307/immutable-infrastructure-is-the-future | 08:45 |
| DavePage | rjek: I wondered when you were going to post that here :) | 08:46 |
| rjek | heh | 08:46 |
| rjek | DavePage: I think what he's suggesting is that you run an ansible playbook, and then remount -oremount,ro /, right? Yeah, right? | 08:46 |
| Albert | That's what I mean. The morph file for AudioManager needs a patch too, for it's calling parameters. There have been changes to Baserock recently, so which Baserock should I make the change to? | 08:46 |
| pedroalvarez | Albert: send patches against the master branch please. We don't have development branches, only sometimes when we are going to do a release and we don't want to include all the incoming patches in the release. | 08:48 |
| Albert | OK | 08:48 |
| richard_maw | rjek: that article makes me want to have another go at Live Atomic Updates in systemd. Most of the bits are already there, it's just missing the facility to do a pivot without killing off every process | 09:02 |
| *** ssam2 has joined #baserock | 09:03 | |
| *** ChanServ sets mode: +v ssam2 | 09:03 | |
| rjek | What's wrong with a little procicide now and again? | 09:04 |
| richard_maw | rjek: when it happens and you don't intend it to, such as when killall is killall5 | 09:05 |
| *** lachlanmackenzie has joined #baserock | 09:18 | |
| petefoth | I guess another use case for submitting patches via the ML is if a contributor does not have time, energy or motivation to get an OpenID and register to use gerrit. This might be the case for small changes | 09:23 |
| rdale_ | or sometimes you submit 'theoretical' patches as part of a design discussion, and don't intend them to be merged | 09:25 |
| jmacs | I agree; I think gerrit is optimised for regular contributors | 09:27 |
| petefoth | rdale_: yes, but I think you can do that in gerrit by posting to a special branch (or something - I may be making that up) | 09:28 |
| petefoth | I'm going to put the information about submitting patches via the ML on a spearate page, as there is already too mucj information in 'contributing' | 09:29 |
| ssam2 | you can sent private 'drafts' to gerrit | 09:32 |
| ssam2 | i'm not sure if you can make them public while still keeping them as 'drafts', so it seems like more of a backup method | 09:32 |
| ssam2 | i could be wrong as well | 09:32 |
| rdale_ | i would rather use the mailing list for that i think | 09:32 |
| benbrown_ | Prepend commit messages with RFC? | 09:33 |
| pedroalvarez | hm.. I have here a mason that is not building anymore :/ | 10:03 |
| pedroalvarez | I wonder if this might be a bug in distbuild, but my debugging skills with it are not good | 10:03 |
| straycat | *a* bug | 10:04 |
| pedroalvarez | :) | 10:07 |
| pedroalvarez | straycat: it's working much better than a year ago | 10:07 |
| straycat | yes :) | 10:09 |
| Zara | any lovely people have a moment to look at https://gerrit.baserock.org/#/c/603/ ? | 10:17 |
| *** Albert has quit IRC | 10:17 | |
| pedroalvarez | Zara: oh, you did what I told you to. Did that work? | 10:21 |
| *** Albert has joined #baserock | 10:22 | |
| *** mariaderidder has quit IRC | 10:25 | |
| *** mariaderidder has joined #baserock | 10:25 | |
| Zara | pedroalvarez: yeah, it did :) | 10:26 |
| pedroalvarez | +1ed | 10:27 |
| Zara | :D | 10:29 |
| richard_maw | I wrote up what I've been doing to support a shutdownramfs in Baserock at http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-May/012997.html since the individual patches don't contain sufficient context, and I don't think they should | 10:39 |
| *** zoli__ has quit IRC | 10:44 | |
| tiagogomes_ | I'd like that RFCs sent to the mailing list had a page on the wiki as well, so that they don't get lost | 10:48 |
| richard_maw | there's an archive | 10:49 |
| richard_maw | and I'd prefer if we didn't have a long-running RFC | 10:50 |
| richard_maw | I'd prefer we concluded whether we want it or didn't wan it soon enough that we don't need to preserve the RFC | 10:50 |
| richard_maw | it would then become a design document of some form instead | 10:50 |
| tiagogomes_ | we couldn't not wanting it now but wanting it later; or we could want it now but not wanting allocate resources to implement it | 10:53 |
| ssam2 | tiagogomes: some of us use http://storyboard.baserock.org/ for tracking that sort of thing | 10:53 |
| ssam2 | i would understand if you don't want to use it, there are major flaws in the UI of storyboard (at least in the version we have running) | 10:54 |
| ssam2 | such as it only lists 10 stories, so you have to play with the sort headers to change which 10 you see | 10:55 |
| tiagogomes_ | huh? You can't see all? | 10:58 |
| *** Guest18305 has quit IRC | 10:59 | |
| Zara | franred: I just tested your change and it does work. :) I think I was just confused about how $DESTDIR worked. | 11:01 |
| *** zoli__ has joined #baserock | 11:03 | |
| franred | Zara, then I think you can also skip `ETCDIR=/etc` because it is written in that way in the Makefile | 11:03 |
| Zara | gah :D | 11:04 |
| franred | you still need to set PREFIX="$PREFIX" because in the Makefile it default it to /usr/local and we like prefix to be /usr | 11:04 |
| *** zoli__ has joined #baserock | 11:10 | |
| *** zoli__ has joined #baserock | 11:11 | |
| ssam2 | tiaogomes_: I don't see a way to 'see all' in the UI | 11:11 |
| *** zoli__ has quit IRC | 11:13 | |
| pedroalvarez | ssam2: argh! I thought we had only 10 stories! | 11:13 |
| *** zoli__ has joined #baserock | 11:14 | |
| pedroalvarez | well, if you pick a project, then you can see all the stories of that project | 11:15 |
| *** Guest18305 has joined #baserock | 11:15 | |
| *** zoli__ has quit IRC | 11:17 | |
| jjardon | ssam2: Hi, would it be possible to remove the veto from https://gerrit.baserock.org/#/c/433/ , now that new release is out? | 11:21 |
| pedroalvarez | I think we can close this story now: https://storyboard.baserock.org/#!/story/21 | 11:22 |
| pedroalvarez | (thanks to jonathanmaw) | 11:22 |
| ssam2 | jjardon: done | 11:23 |
| *** petefoth has left #baserock | 11:23 | |
| ssam2 | we'll probably still have a nightmare upgrading from 15.19 to the next release because of distbuild being broken in 15.19, of course... | 11:23 |
| ssam2 | but at least we triedf | 11:23 |
| ssam2 | -f | 11:23 |
| ssam2 | we could tag a 15.19.1 release with the fixed version of Morph, I guess | 11:24 |
| pedroalvarez | I think that would be a good idea | 11:29 |
| ssam2 | i'll wait til the various outstanding distbuild patches are merged and then do that | 11:30 |
| jjardon | Does anybody remember why 2c7dc4cd1531d97aaf3823d23eeba4e0bb6742be of definitions was needed? ("Update the jetson cluster to use BOOT_DEVICE") | 11:45 |
| jjardon | radiofree: ^ ? | 11:45 |
| ssam2 | because we have a separate ext4 partition for holding the kernel when deploying to Jetsons, now | 11:45 |
| ssam2 | so BOOT_DEVICE points to the ext4 partition and ROOT_DEVICE points to the btrfs partition with /usr and everything | 11:45 |
| ssam2 | i think that's needed because of bugs in U-Boot trying to read the kernel from Btrfs | 11:46 |
| jjardon | ah, ok | 11:47 |
| *** zoli__ has joined #baserock | 11:48 | |
| jjardon | Im trying to run "morph deploy" but its failing with this error: http://paste.baserock.org/iborulupop Shouldnt that utility be in all the baserock systems? | 11:49 |
| jjardon | this is my cluster file: http://paste.baserock.org/ocaqedugey | 11:50 |
| ssam2 | it should be present in the 'build' and 'devel' systems, which are the ones that contain Morph | 11:50 |
| pedroalvarez | are you by any chance using a cross-bootstrap system to deploy that? | 11:50 |
| jjardon | pedroalvarez: im inside the chroot resulting from native-build the bootstrap system, yes | 11:52 |
| ssam2 | ignore the failure on mason-x86-64.baserock.org, I'm changing their network config | 12:07 |
| ssam2 | will announce on baserock-dev when it's done | 12:07 |
| *** zoli__ has joined #baserock | 12:30 | |
| paulsherwood | while waiting (an hour!?) to wget latest build-system and wondering why it's so big, i came across this... http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html | 12:39 |
| ssam2 | it's mostly big because we do no debug stripping at all | 12:41 |
| richard_maw | paulsherwood: that approach would require hand-crafting all our executables, which is not feasible | 12:41 |
| * rjek does not want to replace GCC with a small ELF binary written in assembly. | 12:42 | |
| ssam2 | that is an interesting article though | 12:42 |
| rjek | I have used C and C++ compilers written in assembler. It's not nice. | 12:43 |
| richard_maw | paulsherwood: after stripping binaries, the next step to tiny installer images is to contort your system such that you ship a squashfs rootfs, but we're some ways away from read-only /usr, and I've no idea how we'd do upgradable systems with a squashfs rootfs | 12:45 |
| nowster | rjek: paulsherwood: 45 bytes is still longer than #/bin/sh\nexit 42\n | 12:55 |
| rjek | nowster: :) | 12:55 |
| paulsherwood | i wasn't actually suggesting that approach... i just thought it might be of interest here | 12:56 |
| paulsherwood | what i *would* like to suggest is that we should strip binaries | 12:57 |
| Kinnison | paulsherwood: It's a somewhat old article | 12:57 |
| * Kinnison remembers reading that back in uni | 12:57 | |
| Kinnison | well, in summer holidays after 1st year | 12:57 |
| paulsherwood | stripping binaries on its own would make a big difference i believe | 12:58 |
| Kinnison | stripping would make sense | 12:58 |
| Kinnison | and could be done as a configure extension | 12:58 |
| Kinnison | if we built our binutils appropriately | 12:58 |
| rjek | On the other hand, debug symbols in a developer system can be handy | 12:58 |
| radiofree | BOOT_DEVICE isn't just useful on a jetson, the thinkpad i installed baserock on uses it as well | 12:58 |
| richard_maw | if we're posting interesting artcles: http://research.swtch.com/zip is interesting | 12:58 |
| radiofree | rather than just having one giant "/dev/sda" with no partition table | 12:59 |
| ratmice__ | i've been annoyed by the whole debug symbols/separate debug symbols thing lately (how to get the separate debug symbols, you compile with debug info, copy the debug symbols out, then strip them from the original) be so much less work to just generate them in a separate file initially | 13:10 |
| jjardon | pedroalvarez: so, how should I meant to deploy in this system? http://wiki.baserock.org/guides/how-to-cross-bootstrap/ (4c) doesn't seem to say anything more is needed | 13:26 |
| pedroalvarez | this is because the 2 times I've done this, I deployed to a nfs server | 13:28 |
| pedroalvarez | so I didn't face this problem, and i didn't document anything | 13:28 |
| pedroalvarez | I think the best approach for your situation is to, with that chroot, build a build/devel system, and deploy it using sysroot.write to generate another chroot with all the tools needed. | 13:29 |
| *** Guest18305 has quit IRC | 13:41 | |
| rjek | ratmice__: ++ | 13:44 |
| rjek | I think Debian has some automatic infrastructure for ripping out debug symbols from libraries and such so they can be put in different packages. | 13:45 |
| rjek | Perhaps something artefact splitting could also do? | 13:45 |
| *** petefoth has joined #baserock | 13:46 | |
| jjardon | pedroalvarez: :( ok, thanks. Is there any documentation/examples about how to use that extension? | 13:47 |
| petefoth | The 'Submitting patches via the Mailing List' page now exists at http://wiki.baserock.org/changes-via-ml/ and is referenced from the 'Contributing' page. The text is a straight copy of the old version and could probably do with some pruning, but I'll leave that until we've thought some more about making the 'contributinsg' pages more engaging for new contributors | 13:48 |
| pedroalvarez | `morph help sysroot` says it doesn't have any documentation | 13:49 |
| richard_maw | rjek: my thoughts on debug symbols were to move build-systems to definitions, add strip commands to post-install-commands and tie the default split rules to build-systems, so it defines a -debug artifact | 13:50 |
| rjek | richard_maw: Sounds ideal. | 13:50 |
| pedroalvarez | jjardon: well, maybe is better to deploy to a tarball | 13:50 |
| pedroalvarez | which is documented :) `morph help tar.write` | 13:51 |
| paulsherwood | am i alone seeing a kernel panic on current build-system-x86_64.img.gz ? | 13:52 |
| pedroalvarez | paulsherwood: I can give it a go | 13:52 |
| paulsherwood | also it seesm to take longer to boot than ever before | 13:53 |
| *** Guest18305 has joined #baserock | 13:53 | |
| pedroalvarez | 1.7G! | 13:53 |
| paulsherwood | yup. | 13:54 |
| jjardon | pedroalvarez: ok, I will take a look, thanks | 13:54 |
| * paulsherwood does wonder what's happened here | 13:54 | |
| pedroalvarez | paulsherwood: I think something is wrong with that | 13:54 |
| ssam2 | could be the initramfs | 13:54 |
| pedroalvarez | initramfs is only 6M IIRC :/ | 13:55 |
| jjardon | pedroalvarez: I think ssam2 is talking about the boot speed | 13:55 |
| pedroalvarez | build 32b is 621M | 13:55 |
| pedroalvarez | ah, true | 13:55 |
| pedroalvarez | paulsherwood: but then, does it boot? | 13:56 |
| pedroalvarez | and the kernel crashes later? | 13:56 |
| paulsherwood | kernel panic - not syncing: VFS: Unable to mount rootfs on unknown-block(0,0) | 13:57 |
| jjardon | richard_maw: you mean we will have to create a tiny morph file for every chunk only to put what build system is using? or the plan is to add the build system in the stratum? | 13:57 |
| paulsherwood | nooooooooo | 13:58 |
| richard_maw | jjardon: did I say I was going to make build-system detection manual? | 13:58 |
| richard_maw | I just said that the logic for what a build system provides should be moved to definitions | 13:59 |
| ssam2 | oh, so the release is broken! | 13:59 |
| ssam2 | I probably did only test x86_32. | 13:59 |
| richard_maw | jjardon: the detection rules would have to go with it | 13:59 |
| *** Guest18305 has quit IRC | 13:59 | |
| jjardon | richard_maw: ah, ok. sorry I misunderstood | 13:59 |
| pedroalvarez | ssam2: I 've just finished downloading the 64b image, I'm going to test it now | 14:00 |
| * richard_maw currently favours removing automatic build-system detection, but only if we could in-line it in the stratum, and has oscillated between wanting it and not wanting it too much to seriously suggest it | 14:01 | |
| ratmice__ | rjek: yeah, there is an example of how to do that: https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html | 14:05 |
| ratmice__ | rjek: objcopy --only-keep-debug foo foo.debug | 14:06 |
| pedroalvarez | paulsherwood: I confirm that the image doesn't boot | 14:09 |
| ssam2 | but the x86_32 image (no initramfs) does, so I think it's definitely the initramfs that broke things | 14:10 |
| ssam2 | jjardon: how did you test https://gerrit.baserock.org/#/c/558/ (adding initramfs to x86_64 system) -- did you see it working? | 14:12 |
| pedroalvarez | 547M of initramfs :/ something is wrong :) | 14:12 |
| jjardon | ssam2: I built a weston x86_64 image and boot it in my laptop | 14:14 |
| jjardon | ssam2: I posted screenshots in this channel | 14:14 |
| ssam2 | cool. I wonder if this problem is specific to the build-system-x86_64 then | 14:14 |
| ssam2 | hard to understand how that would happen though | 14:14 |
| *** Guest18305 has joined #baserock | 14:15 | |
| paulsherwood | :( | 14:16 |
| ssam2 | ok, this turns looks like a long chain of failure that leads to it being my fault | 14:18 |
| ssam2 | -turns | 14:18 |
| ssam2 | the build-system-x86_64.img contains /itself/ as an initramfs, rather than the actual initramfs | 14:19 |
| ssam2 | which is why it's huge and why it doesn't boot | 14:19 |
| paulsherwood | ssam2: safest way to avoid mistakes is not to do anything ;) | 14:19 |
| ssam2 | the reason this happened is: I had followed http://wiki.baserock.org/using-latest-morph/ to use Morph from the source tree (because it's impossible to build this release with Morph from the previous release) | 14:20 |
| ssam2 | but I had a work-in-progress branch checked out, instead of 'master', by accident | 14:20 |
| ssam2 | and that branch (it turns out) has a regression in `morph deploy` that caused this screwup | 14:21 |
| pedroalvarez | well, I think we have learned some interesting lessons :) | 14:21 |
| ssam2 | the universe will always build a better fool | 14:22 |
| * DavePage suspects that release builds should be generated in an automatically-created clean environment? | 14:23 | |
| ssam2 | yes, that would be good | 14:23 |
| ssam2 | I guess I'll redeploy and reupload the release images for 15.19, since it's not the baserock-15.19 tag of definitions that is broken | 14:24 |
| ssam2 | thanks for spotting this paulsherwood! | 14:25 |
| paulsherwood | np | 14:25 |
| ratmice__ | rjek: oh, and i'd be wary of lifting stuff from debian in this regard (years ago so maybe i recall incorrectly), but their separate debuginfo stuff showed up in debian before it landed upstream and they ended up carrying an incompatible version (not sure if that is still the case) | 14:34 |
| rjek | ratmice__: I think it works pretty well now, at least for the libraries that have it (it isn't universal) | 14:36 |
| ratmice__ | rjek: right, i just mean they have to carry patches since they are slightly incompatible with upstream in some way that i can't recall | 14:37 |
| rjek | That seems sadly likely. | 14:38 |
| rjek | But, for libraries it can be done with, doing it automatically seems like a win. | 14:38 |
| pedroalvarez | DavePage: we have been thinking about that, and I think it will eventually end up as part of the process | 14:43 |
| DavePage | pedroalvarez: *nods* | 14:43 |
| *** Albert has quit IRC | 14:54 | |
| *** Albert has joined #baserock | 14:55 | |
| ssam2 | I've uploaded a fixed version of http://download.baserock.org/baserock/baserock-current-build-system-x86_64.img.gz | 15:02 |
| ssam2 | apologies for the cockup | 15:02 |
| ssam2 | I'll mail baserock-dev as well | 15:02 |
| pedroalvarez | Zara: I'm currently wondering if we can drop your 3 lorries patches, e. i. you know you don't need them (as Javier suggested) | 15:04 |
| Zara | pedroalvarez: I think we will want one of them (the openbmc one), but it looks like we won't need the other two | 15:06 |
| pedroalvarez | Zara: ok, no rush, just wondering | 15:06 |
| Zara | yeah, I've left them there because I'm still not 100% sure we won't need them later, but so far it's looking like we won't need them :) | 15:07 |
| franred | Zara, you could abandon them and if you need to recover them, you could do from the abandoned page | 15:08 |
| Zara | okay, will do. | 15:08 |
| franred | just FYI, as pedroalvarez said there are not rush on it | 15:08 |
| *** paulw has quit IRC | 15:43 | |
| *** a1exhughe5 has quit IRC | 15:44 | |
| jjardon | Do you think it would be a good idea to split the build systems? Not sure a embedded developer would like to build the openstack support | 15:48 |
| ssam2 | you mean the openstack clients? I imagine they're quite small | 15:51 |
| ssam2 | I don't want to do anything that makes the release process more complicated | 15:51 |
| jjardon | fair anough | 16:00 |
| jjardon | enough* | 16:00 |
| franred | does the python import tool only import python packages hosted in Pypi? is it possible import dependencies from a downloaded repo? (i.e. Nova or Openstack-nova does not exists in Pypi but would be nice if I can clone nova and get a lorry/stratum with its dependencies using the cloned repo) | 16:04 |
| ssam2 | i'm not sure. straycat ? | 16:04 |
| ssam2 | the question is whether the cloned repo contains enough info or not | 16:05 |
| ssam2 | but there's some way of discovering the URL, the python.to_lorry program could be extended to support that method | 16:05 |
| ssam2 | I've hit a weird error with `morph diff`: http://paste.baserock.org/izoduturax | 16:06 |
| richard_maw | ssam2: that's because some stratum missed the .morph off the end of the morphology file of a dependency | 16:07 |
| richard_maw | you can limit yourself to a subset of the systems by listing the paths after the ref | 16:08 |
| ssam2 | ah, right | 16:08 |
| * richard_maw doesn't recall which system definition is broken, but it happened during the OpenStack reshuffle | 16:08 | |
| richard_maw | it's zookeeper-clients IIRC | 16:09 |
| pedroalvarez | oh, still broken :( | 16:09 |
| * pedroalvarez can fix that | 16:09 | |
| pedroalvarez | https://gerrit.baserock.org/631 | 16:12 |
| franred | ssam2, other way to do this is passing to the import tool where the repository instead of the name of the python package | 16:12 |
| franred | s/instead/is or its URL instead/ | 16:14 |
| franred | straycat, ^^ | 16:14 |
| ssam2 | franred: at what point? | 16:14 |
| ssam2 | you can already create a .lorry file manually for any components, which the import tool will then load as if it had created them itself | 16:15 |
| franred | ssam2, can I point the import tool to a stratum or a system too? | 16:18 |
| pedroalvarez | franred: I assume you have found the docs http://wiki.baserock.org/guides/import-tool/ | 16:20 |
| ssam2 | what do you mean by "point" ? | 16:20 |
| ssam2 | the import tool *creates* a stratum, it doesn't look at strata or systems at all | 16:20 |
| ssam2 | it'd be nice to improve it so that it updated existing definitions, rather than spitting out a new stratum, but I think that's not trivial and would require changes to the definitions format for it to be that good | 16:21 |
| franred | pedroalvarez, I've read the docs and check the command line | 16:21 |
| franred | ssam2, yeah, I've misunderstood your previous sentence about the lorry file | 16:22 |
| ssam2 | I'm going to create a baserock-15.19.1 release tag, with https://gerrit.baserock.org/#/c/631 (test-tools.morph fix) and https://gerrit.baserock.org/#/c/632/ (update morph to latest) on top of 15.19 | 16:24 |
| ssam2 | mainly because distbuild was really broken in 15.19 | 16:24 |
| jjardon | Hi, I have this build failure http://paste.baserock.org/uqulehowen that its fixed if I compile with -02 instead the morph defaults (-march is armv5te). What is the bes way to proceed here? I noticed something similar seems to be needed by glibc | 16:25 |
| franred | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/import.git/tree/README.python --> says explicitly "Please note that this tool expects any python packages to be on pypi, you cannot currently import packages from other places" | 16:25 |
| ssam2 | right. I don't know the details of how that works, best to discuss with straycat whenever he is around | 16:27 |
| franred | ok I will wait for straycat :), thanks anyway | 16:29 |
| *** ssam2 has quit IRC | 16:35 | |
| jjardon | pedroalvarez: so, should something be added to the cross- systems? maybe we should move btrfs-progs to core? | 16:42 |
| paulsherwood | does anyone have a jetson that they could try something out on for me please? | 16:48 |
| jmacs | aarch64be ok? | 16:48 |
| paulsherwood | yup | 16:48 |
| richard_maw | aarch64 on a Jetson? | 16:49 |
| richard_maw | I thought they were 32-bit | 16:49 |
| jmacs | um | 16:49 |
| paulsherwood | i assume he means moonshot | 16:49 |
| jmacs | No, armv7b, sorry | 16:49 |
| paulsherwood | basically any non x86 baserock system | 16:49 |
| jmacs | What would you like me to try? | 16:50 |
| paulsherwood | building a system on it using ybd :) | 16:50 |
| jmacs | OK, if you point me at some instructions... | 16:51 |
| paulsherwood | either it should 'just work' in which case it'll sit there building overnight, or you'll hit a rock immediately and that would be useful feedback | 16:52 |
| *** Guest18305 has quit IRC | 16:53 | |
| paulsherwood | git clone https://github.com/devcurmudgeon/ybd.git into your /src, then cd into a checkout of definitions, then run python /src/ybd/ybd $system $arch | 16:53 |
| paulsherwood | where $system is relative path to a morph file describing a system that can be built on arnv7b, and $arch is whatever morph arch needs to be (presumably armv7b) | 16:54 |
| jmacs | My definitions may be quite old, does that matter? | 16:54 |
| paulsherwood | no, should be fine | 16:54 |
| paulsherwood | or you chould clone a new copy somewhere | 16:54 |
| paulsherwood | (doesn't need a workspace, just a git checkout) | 16:54 |
| jmacs | OK, I'm building devel-system-armv7b-highbank.morph as there doesn't seem to be a morph for armv7b-jetson | 16:56 |
| jmacs | It appears to be doing things. | 16:56 |
| * paulsherwood crosses fingers | 16:56 | |
| paulsherwood | if it seems happy, could you leave it running overnight please? | 16:57 |
| jmacs | Yes, no problem | 16:57 |
| paulsherwood | (can be killed and re-started if that's better for you) | 16:57 |
| paulsherwood | tvm | 16:58 |
| *** mariaderidder has quit IRC | 17:02 | |
| *** bashrc has quit IRC | 17:02 | |
| *** cyndis has quit IRC | 17:02 | |
| *** bashrc has joined #baserock | 17:02 | |
| *** cyndis has joined #baserock | 17:02 | |
| *** lachlanmackenzie has quit IRC | 17:29 | |
| *** gary_perkins has quit IRC | 17:32 | |
| * paulsherwood successfully upgrades a devel system using ybd | 17:33 | |
| jmacs | ybd last said "2015-05-12 17:28:54 [systems/devel-system-armv7b-highbank.morph] Finished" but hasn't exited yet | 17:36 |
| jmacs | I'll leave it running | 17:36 |
| Kinnison | it's unlikely to have completed that fast | 17:36 |
| Kinnison | I'd look back in the log for errors | 17:36 |
| paulsherwood | that sounds like a bug... it's doing some forking... for a notional 'distbuild' | 17:39 |
| paulsherwood | jmacs: thanks :) | 17:39 |
| * paulsherwood needs to work out how to fork and drop all context_managers | 17:39 | |
| *** Albert has quit IRC | 17:43 | |
| *** zoli__ has quit IRC | 17:53 | |
| *** edcragg has quit IRC | 18:03 | |
| *** rdale_ has quit IRC | 18:36 | |
| *** zoli__ has joined #baserock | 18:53 | |
| *** zoli__ has quit IRC | 18:58 | |
| *** zoli__ has joined #baserock | 20:35 | |
| *** Albert has joined #baserock | 22:27 | |
| *** Albert has quit IRC | 22:32 | |
| *** zoli__ has quit IRC | 23:33 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!