IRC logs for #baserock for Friday, 2014-11-14

*** juergbi [] has quit [Ping timeout: 255 seconds]03:44
*** pdar [] has quit [Ping timeout: 255 seconds]03:44
*** fay_ [] has quit [Ping timeout: 255 seconds]03:44
*** fay_ [] has joined #baserock03:44
*** juergbi [] has joined #baserock03:46
*** pdar [] has joined #baserock03:50
*** zoli_ [] has joined #baserock05:57
*** zoli_ [] has quit [Changing host]05:57
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock05:57
*** zoli_ [~zoli_@linaro/zoli] has quit [Client Quit]05:58
*** aananth [~caananth@] has joined #baserock08:08
*** wdutch [] has joined #baserock08:11
*** sambishop [] has quit [Remote host closed the connection]08:54
pedroalvarezHi all09:03
pedroalvarezI'm pondering doing a full release, increasing the size of the disks09:04
paulsher1oodincreasing the size of the disks? which disks?09:05
pedroalvarezof the build systems released, so there is more space to do self upgrades09:05
paulsher1oodoh, yes. ok09:05
paulsher1oodsame for devel09:05
paulsher1ood(and release email should explain this, and need to tweak the wiki)09:06
paulsher1oodi did separate out the 'increase space' instructions in prep for this09:06
pedroalvarezregarding the devel system, we decided to release only the build system09:07
*** mariaderidder [] has joined #baserock09:07
paulsher1oodoh? ok09:10
paulsher1oodno genivi?09:10
pedroalvarezto be clear, when I say full release I mean release all the systems in clusters/release.morph09:12
*** genii [~quassel@ubuntu/member/genii] has joined #baserock09:15
pedroalvarezon the other hand, I also wonder if makes sense to make the images of jetson smaller, so it takes less time to flash them09:17
pedroalvarezI think is possible to specify the size of the disk on the jetson-flash script09:18
paulsher1oodit is09:18
pedroalvarezthen I think is a good idea.09:20
* pedroalvarez thinks that 6G for build systems is ok09:24
pedroalvarezSo this is basically my proposal:
persiaIs the "2G" for the devel-system-armv7lhf-jetson a typo?09:29
pedroalvarezwhen the image is 4G you have to wait for 0's to be flashed09:30
persiaThis is for flash speed?  Won't that break upgrades entirely?09:30
franredhow big is the minimal image for the jetson? 09:30
pedroalvarezthe main point here is that you can set up the disk size when flashing09:30
persiaAh, OK.09:31
pedroalvarezso it won't break the upgrades09:31
franredif it is more than 1, I would suggest not to make it less than 3GB09:31
pedroalvarezI'm not 100% sure about that change because I've never tried it myself09:34
franredpedroalvarez, forget what I said...09:34
pedroalvarezfranred: no worries :)09:34
pedroalvarezI see that in the script that James has sent for review he has changed the ROOTFS size :)09:37
*** aananth [~caananth@] has quit [Ping timeout: 256 seconds]09:45
*** jonathanmaw [] has joined #baserock09:46
radiofreepersia: you can run the btrfs filesystem resize max command once it's flashed09:50
radiofreeso then it expands from 2G to 14G09:50
persiaIn that case, why do we specify the size in the cluster definition?  wouldn't it be better to always be minimum size?09:50
radiofreei thought you had to specify it?09:51
persiaYes, but why?  conputers are good at math09:51
radiofreeoh right, yes, i agree, you shouldn't need to do that09:52
persiaWell, perhaps it is important for non-growable filesystems, but in that case "auto" ought be an acceptable value (and probably the default)09:53
pedroalvarezi've been thinking about this, and deploying images with the minimum disk size possible can cause the system to not boot at all09:55
*** tiagogomes [] has joined #baserock09:55
pedroalvarezam I right?09:55
persiahow so?09:56
pedroalvarezmy idea was to reduce the disk size for the cloud systems, so cloud-init will resize them after boot09:57
pedroalvarezbut then I thought, will a btfs system boot with no space free?09:57
persiaFor the Ubuntu MID project, we put in an extra 100M of space in the images, to support folk hacking images before deployment, but this extra space may have also served other purposes (all my other image exerience is with iive and installer images, which are different)09:57
Kinnisonpedroalvarez: with zero space free, probably not09:58
*** ssam2 [] has joined #baserock10:01
Mode #baserock +v ssam2 by ChanServ10:01
*** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer]10:02
*** aananth [~caananth@] has joined #baserock10:02
ssam2happy friday everyone!10:02
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock10:03
pedroalvarezHi ssam2!10:04
ssam2i seem to have accumulated a monumental pile of email in 3 days, but a lot of it seems to be 'you have received a new secure message' spam10:05
*** locallycompact [] has quit [Ping timeout: 272 seconds]10:06
persiaIf you received the email, the message is already compromised :)10:06
*** zoli_ [~zoli_@linaro/zoli] has quit [Client Quit]10:06
pedroalvarezwow, took me only 20 minutes to deploy all the systems of release.morph10:11
*** abdul [~abdul@] has quit [Quit: Leaving]10:11
pedroalvarezIs the easiest release ever10:12
radiofreewas that using the public facing mason?10:12
radiofreewhich is the best thing ever10:12
pedroalvarezalso, I have to say that I deployed the systems in the same network of mason, so fetching the system artifacts was fast10:13
pedroalvarezsame as* :)10:14
persiaGetting closer to releases being only a new tag :)10:17
*** locallycompact [] has joined #baserock10:18
pedroalvarezhm.. we broke list-artifacts plugin:
KinnisonIs there no yarn for that?10:31
pedroalvarezI assume there isn't10:31
ssam2no. feel free to write one!10:31
ssam2actually, seems like I tried not to break it but somehow still managed to break it10:32
paulsher1oodso if we are ready to make the dc artifact server the default, it's all done?10:32
paulsher1ood(that could be as simple as telling folks to add the line to their morph.conf)10:32
ssam2that line should be morphlib.sourceresolver.create_source_pool rather than morphlib.SourceResolver.create_source_pool10:32
pedroalvarezthanks ssam2!10:34
radiofreeJavier needs to change his name, it appears as "Javier Jard<C3><B3>n" in a git log message on baserock11:12
richard_mawit could be worse, my name appears as "Richard Maw"!11:13
* richard_maw stops making silly comments11:14
straycatplease don't :)11:14
persiaradiofree: In which locale do you see that?11:14
pedroalvarezmy name sometimes is My Name :)11:15
radiofreepersia: i'm using a genivi system as a developement environment11:15
radiofreei'm not sure this is an issue on the devel systems11:15
persiaIn that case, you are using the C locale, which cannot handle UTF-8, hence the issue.11:18
pedroalvarezgiven that the baserock-flash script is going to end up in scripts/ I decided to release the jetson systems as compressed .img files and also the u-boot file.11:20
radiofreepedroalvarez: did you remember to change the device tree name in the devel system release cluster?11:24
pedroalvarezall the changes I made are visible in the release branch11:24
pedroalvarezI also tested the build-system and the genivi-system,11:24
pedroalvarezand they worked11:24
paulsher1oodpedroalvarez: i wasn't able to get the genivi-ivi shell thing running. do the instructions need to be changed?11:25
pedroalvarezoh! I think that is because we are saying there that weston has to use the fbdev backend11:27
pedroalvarezand in arm that's not true11:27
pedroalvarezbut it is in x8611:27
radiofreeyes for jetson you just run "weston"11:27
radiofreebtw that graphical environment, while fancy and nice to play with, is *not* the genivi-ivi shell11:28
radiofreeunfortunately if ivi-controller (the genivi part) displays... nothing.. until you setup a load of layers11:28
paulsher1oodradiofree: when i followed the instrcutions, all i got was normal weston i think11:30
* pedroalvarez is stuck with the relase notes11:32
radiofreeare you sure you copied it to .config/weston.ini11:32
radiofreecd /root/.config11:32
paulsher1ood... i'll check11:32
radiofreeand run weston from there11:32
paulsher1oodah, no. i need to rename it :)11:33
ssam2pedroalvarez: re. the broken `morph list-artifacts`, do you want me to send a patch to fix it ?11:33
* radiofree will refrain from posting the line from CMU Sphinx about debugging11:34
pedroalvarezssam2: I don't have the time to fix it today, and I solved the issue I had with that command using a version of morph that works11:34
paulsher1oodradiofree: thanks :-)11:34
paulsher1oodradiofree: go ahead and post it, though :)11:35
radiofree"Troubleshooting is not rocket science. For all issues you may blame yourself. You are most likely the reason of failure."11:35
radiofreei need to put that on a post-it note and stick it to my monitor11:36
ssam2pedroalvarez: ok, I'll send a patch11:42
radiofreei wonder if it would be possible to flash u-boot from within baserock11:45
aananthHi, today I am trying to build an image from my Jetson board, configured vtsc-trove as its trove-host. But it throws "is an invalid reference for repo git://". Details in 11:45
aananthAny idea? Is it because of the new trove server is not completely synced?11:45
radiofreei'm thinking - create a boot.scr file with the correct commands, reboot, have u-boot load that and flash the new u-boot and then delete the boot.scr file so it then boots normally11:46
pedroalvarezaananth: yeah, that can be the cause11:47
jmacsHmm, I'm sure I used to have mkfs.ext4 on my baserock system11:47
paulsher1oodpedroalvarez: i'm not sure it is the cause, i think there are other corner cases maybe11:47
radiofreethat ref is for the completely wrong kernel though11:48
pedroalvarezradiofree: what do you mean by that11:48
radiofreethat's the ref for baserock/v3.811:49
radiofreewhich almost certainly won't boot the jetson11:49
aananthpedroalvarez: Thanks. I just checked the journalctl, I could see ntpd-boot.service in Jetson is unable to sync clock... Can that be another cause?11:49
persiaradiofree: Yes, although for local flash, we'd need a flash program, and for remote flash, we'd need to think about it a bit more, and probably add a new deployment mechansim to morph11:50
pedroalvarezaananth: I don't thnk that's the issue11:50
radiofreeaananth: i see you're using upgrade-devel.morph11:50
radiofreedid you change the system name in that?11:50
radiofreeuses devel-system-x86_64-generic.morph, which uses that kernel ref11:51
paulsher1oodaananth: if you're upgrading a jetson, you need jetson-upgrade.morph as your cluster11:51
jmacsDoes anyone know why I don't have mkfs.ext4 on my baserock linux system, or where it should come from?11:51
radiofreepersia: there's the tegra-uboot-flash scripts from nvidia that work really well if you have a laptop11:51
radiofreethe only part i'm a bit unsure about is "then delete the boot.scr file"11:52
persiaRight.  Those should work fine from a baserock laptop.  My memory of working with them involves some x86 binary code, which may be an obstacle in some situations.11:52
pedroalvarezjmacs: I hope this helps:
radiofreepersia: the nvflash in the L4T release is x86, however these scripts should work on arm11:53
radiofreesince you have the source and can compile it11:53
persiaradiofree: Give it a try.  If it works, add a deployment mechanism for it :)11:53
radiofreehowever that requires the jetson to be in recovery mode and it does it via usb, so not that useful running on the board you want to flash11:53
persiaWe ought be able to just specify to use that in a cluster definition, so that one can do everything sensibly.11:53
persiaNo, but it is useful if you have a build board and a test board, and your test board USB gadget is connected to your build board USB host.11:54
radiofreei was thinking of doing it in a similar way by touching a file which our (modified) u-boot looks for, if there, follow the commands to upgrade u-boot11:54
* persia wants to simplify the model for folk fiddling with local dev boards, as the current mess is a bit annoying11:54
jmacspedroalvarez: Yes, that'll be it, thanks11:55
persiaradiofree: Handling local upgrades for deployed systems is also a nice area to fix, but it doesn't help folk migrating to baserock, or comparing baserock systems to legacy systems, or similar workflows.11:55
pedroalvarezjmacs: not sure if it's present in latest devel system, the system I'm using is a couple of months old.11:56
aananthpaulsherlood: thanks :-). Should I make any changes to the jetson-upgrade.morph? (like TROVE_HOST, TROVE_ID etc)?11:56
pedroalvarezdo we still have TROVE_HOST and TROVE_ID in jetson-upgrade?11:56
paulsher1oodi think they are ignored, aananth 11:56
pedroalvarezthese are for now the release notes:
straycatDoes morph insist that morphologies must be yaml now? (they can't be json anymore?)12:04
straycatOkay I guess it does.12:07
radiofreei was thinking last night that the number of systems could be massively reduced if you separated the idea of a system from it's bsp12:08
radiofreeso you'd do something like morph build devel-system jetson-bsp12:08
radiofreemorph build devel-system x86_64 etc...12:08
straycatmulti-arch systems would be cool12:09
pedroalvarezbut then our devel-system for ppc is different than the others12:09
aananthradiofree: do I need to change the system name if I use clusters/jetson-upgrade.morph as my cluster? 12:13
radiofreei don't think so12:13
ssam2pedroalvarez: release notes look good12:17
radiofreepedroalvarez: The Wayland 'drm' backend is working on the NVIDIA Jetson in this release12:17
radiofreeit was working on the previous release?12:17
pedroalvarezssam2: I have to confess that I reused yours :)12:17
pedroalvarezradiofree: it wasn't working IIRC12:18
pedroalvarezradiofree: at least we said that in the release notes12:18
ssam2peroalvarez: ''This change can cause that the self-upgrade of a system doesn't work if the system has less than 2G free on its rootfs.' -> 'This change might cause self-upgrade of a system to fail if the system has less then 2GB free in its root file system'12:18
ssam2pedroalvarez: reusing release notes is the only sensible way !12:18
radiofreewell only one client didn't work, i think it's a bit unfair to say the whole thing didn't work because of that12:18
pedroalvarezradiofree: do you think I have to remove that point in the release notes?12:19
pedroalvarezssam2: thanks for  helping :)12:19
radiofreepedroalvarez: yeah :)12:20
pedroalvarezssam2: actually I think there is not harm in putting 3G there instead of 2G12:22
straycatssam2, this startum morph generation has hardcoded ruby stuff in it, is that intended?12:22
pedroalvarezI don't know what else can I say in the genivi release notes:
pedroalvarezpaulsher1ood: can you plase review them? ^^12:26
* straycat reads them while he waits12:28
pedroalvarezstraycat: the full release notes are these:
straycatpedroalvarez, "There have been more changes since the Baserock 14.40"12:29
straycatI think you mean to say 14.40 release12:29
straycatI'd also drop the comma after "Any questions"12:29
persiapedroalvarez: Those look fine to me.  if you want to be expansive, you can detail what else changed in Baserock versions, but perhaps it is better to cause folk to read the regular release notes (because it invites them to think about Baserock more widely)12:29
pedroalvarezstraycat: thanks! :)12:29
ssam2straycat: what stratum morph generation ?12:30
pedroalvarezpersia: is what we do always, just point the genivi releated changes and then link the full release notes12:30
persiaThen that is probably the strategy to continue to follow12:30
straycatssam2, _generate_stratum_morph_if_none_exists in mainloop.py12:30
ssam2straycat: ah! well, it's intentional but only as a temporary solution12:31
* straycat nods12:31
straycatOkay so you'd be fine with modifying it to make it more general?12:32
straycat*with me12:32
straycatas typos go, that was a bad one12:32
ssam2that'd be great12:32
straycatOkay cool thanks12:32
ssam2it's only the stratum build depends that are ruby-specific I think12:32
ssam2so I guess the cmd_rubygem() function and the other ones could just pass in what strata should be build-depends of the generated stratum, if that works12:33
ssam2it might get a bit more complex, but hopefully not yet :)12:33
ssam2I guess the 'm['x-build-dependencies-rubygems'].iteritems()' needs to change too ... I guess it should iterate through each kind in self.importers (the list of importers that were enabled)12:35
aananthpaulsherlood: I did "morph edit bzip2", I could see the git is cloned to Jetson board (successful first step! yay!!), I added a #error statement to find out the time Jetson takes to find that error, but I get similar warning as earlier. See
aananthHow do I confirm if the trove is completely synched or what % is complete?12:36
straycatssam2, yes that's what's in the way of my import currently, I think iterating through the enabled kinds would be good12:37
radiofreeaananth: i'm not sure why it's complaining about that, df2e1b9168a7ab5dd8149e38b5ac70cdef86d1fa is the wrong kernel for a jetson12:39
paulsher1oodpedroalvarez:  is that on the wiki somewhere? i'd like to edit12:45
pedroalvarezpaulsher1ood: feel free:
aananthradiofree: I get "Repository seems to be empty", if I try to view from the browser. Could the synch incomplete is the reason?12:46
*** cyndis [] has quit [Ping timeout: 265 seconds]12:46
radiofreeaananth: yes it would appear so12:46
pedroalvarezaananth: indeed, seems to be the reason12:46
radiofreethe linux kernel is big, if you're on a slow connection it might take some time12:46
radiofreedo you have the /lc-status.html page on your trove?12:47
radiofreeif you browse to the bottom of cgit, there's a link "View Lorry Controller Status", that might tell you what's happening12:47
pedroalvarezpaulsher1ood: although if you wanted to edit the genivi release notes, they are not in the wiki12:48
aananthradiofree: I could see delta/linux-rt, delta/qt4-tools, delta/coreutils, delta/rsync in "Currently running jobs". 12:48
aananthWhat is expected there? None?12:49
radiofreeaananth: i think it's fine to see those things, is delta/linux in the run-queue?12:49
paulsher1oodpedroalvarez: why not roll the genivi release notes into the main release notes?12:50
aananthradiofree: Yes, all the 4 are in run queue as well and the run queue is a big list.12:51
aananth893 more items, include the above 4.12:51
radiofreei think you'll need someone with more trove experience! it seems like it's still mirroring gbo, which can take some time12:52
radiofreepedroalvarez: ^?12:53
aananthdoes this means, I can take a week off, due to our slow network speed :-)12:54
straycataananth, If you have root on the trove you can get more detailed information if you setup a tunnel to the trove on port 12765 and access localhost:12765/1.0/status-html12:54
paulsher1oodstraycat: this makes me remember the ghost-jobs sitution we had before... ?12:54
straycatunless i'm mistaken liw's fix for that was merged, so that shouldn't be a problem?12:55
pedroalvarezghost jobs are fixed12:56
straycatthat little bit about the admin interface needs to be documented somewhere if it isn't already12:56
paulsher1oodaananth: how many jobs are *running* ?12:56
pedroalvarezpaulsher1ood: I think he said 412:57
paulsher1oodok, so not ghost jobs then12:57
paulsher1oodpedroalvarez: does not mention build images, just devel and base??12:58
pedroalvarezI'm modifying that right now12:58
aananthpaulsherlood: 4 jobs are running and 890+ are in queue.12:59
aananthAlso note that the host machine is a core2duo, very slow PC.  We will upgrade it to a powerful machine soon.13:05
*** cyndis [] has joined #baserock13:05
persiaDoesn't lorry require massive heaps of RAM, or is that requirement reduced for only mirroring git?13:07
Kinnisonmuch less ram for git mirrors13:08
pedroalvarezpaulsher1ood: downloads page updated13:08
pedroalvarezstraycat: looks good to me13:10
paulsher1oodstraycat: +113:11
paulsher1oodpedroalvarez: tvm13:11
straycatyay merged13:11
paulsher1oodpedroalvarez: something wrong with the link on jetsone genivi uboot13:12
pedroalvarezpaulsher1ood: yup, just fixed it, reload the page13:13
pedroalvarezalso the jetson images were wrong and now fixed13:13
pedroalvarezI think that for now we can put the baserock-flash script in to update the instructions of the wiki13:14
paulsher1oodpedroalvarez: bad news, i fear...13:18
* pedroalvarez freezes13:19
paulsher1oodi have been scripting something to work out what the latest tag is in a given chunk build....13:19
paulsher1oodi can not be sure it is accurate13:19
paulsher1oodbut it immediately makes me ask if our ofono version is in need of update13:20
* paulsher1ood will check properly now13:20
paulsher1oodi think my script is correct13:22
pedroalvarezseems we missed that change in the H-0.1 release13:24
paulsher1oodso long ago?13:24
pedroalvarezbtw... your script rules13:25
pedroalvarezand I'd like to use it in the future for this usecase13:27
pedroalvarezI've modified the wiki to support the renaming of the devel systems13:29
petefothpedroalvarez: did you have any plans to update all the wiki pages that refer to ‘devel’ systems so that they refer to ‘build’ systems instead? If not, I’ll p[ut it on my list of things to do 13:30
pedroalvarezpetefoth: I've modified most of them13:30
petefothpedroalvarez: just seen your latest post - ignorte me13:30
pedroalvarezpetefoth: there are some instructions where morph builds a devel system13:30
pedroalvarezpetefoth: tthat instructions are fine13:31
pedroalvarezpetefoth: but not the instructions that ask you to download files from download.baserock.org13:31
petefothpedroalvarez: OK. I don’t know which pages will need to be changed. I’ll leave it to you :)13:32
pedroalvarezradiofree: can you share with me your latest version of the baserock-flash script?13:32
radiofreepedroalvarez: it's on the list13:32
radiofreeand a branch on definitions13:33
petefothSo are ‘build’ and ‘devel’ systems the same thing? If not , what are the differences?13:36
petefothAnd whoich should normal users be using?13:36
richard_mawbuild is the minimal amount to build another system13:40
richard_mawdevel contains ruby and the like, to be a more productive development environment13:40
richard_mawit should eventually contain lorry and the new baserock-import stuff13:40
petefothSo we should be encouraging users who ae gpoing to do devlopment to download the ‘devel’ systems, not ‘build’ systems?13:41
petefoth‘Cos that’s not the effect of the latest wiki changes13:41
paulsher1oodnormal users should start using build system until further notice i think13:42
petefothOK, so we shpuld change stuff that says’ set up a development system’ to ‘Setup a build system’?13:43
richard_mawthough one thing we thought about, was just releasing the build system, and providing instructions on how to upgrade it to a devel lsystem, rather than releasing devel system images13:43
paulsher1oodpedroalvarez: yes13:44
petefothrichard_maw: I’m not sure that counts as  ‘simplifying the Baserock workflows’13:44
paulsher1oodsorry petefoth yes13:44
paulsher1oodpedroalvarez: i meant petefoth :)13:44
petefothpaulsher1ood: OK - I’ll go away and edit13:45
paulsher1oodpetefoth: yes, it does simplify the workflow, really13:45
pedroalvarezradiofree: does u-boot need to be +x to be flasheable?13:45
paulsher1oodpetefoth: there is no *need* for a normal user to upgrade from build to devel. but doing so should help him/her to understand the capabilities of baserock13:46
paulsher1oodit does mean i need to do the videos again again, though :)13:46
petefothThe more documentation - and the better the documentation - we have, the greater the cost of maintaining it as we change stuff :( Which is not an argument for *less* (or *worse*) documentation!13:48
dabukalamSurely the higher the quality of documentation will lead to more people being able to use it, therefore a larger community, therefore a larger number of people willing to work on documentation?13:49
* pedroalvarez updates the jeston flash instructions13:50
petefothdabukalam: *nobody* wants to work on documentation! I only do it ‘cos I get paid :)13:50
DavePageI like working on documentation.13:51
jmacsRubbish, I like working on documentation too.13:51
petefothpedroalvarez: I’ll do the devel-with and glossay changes13:51
* dabukalam makes a mental note to read more about open source community building13:52
DavePageBut then I am heavily didactic13:52
* paulsher1ood favours less documentation, of better quality. and software which 'does the sensible thing'13:52
petefothDavePage: jmacs: I stand corrected. I have just obesrved the tendency inopen source SW development - including Baserock - for the amount and quality of documentation to lag significantly behind tha ampount and quality of code.13:53
* Kinnison notes that no matter how sensible software is, users inevitably require documentation and it's nearly impossible to determine which aspect of documentation any given user will need, until they need it13:53
jmacsI'm not sure I am didactic, but documentation allows for more creativity than code (whether this is a good thing, I don't know)13:53
DavePagepetefoth: That's because most contributors are people who value code over documentation.13:53
Kinnisonjmacs: perhaps so, and if so perhaps that explains why I am poor at documentation -- 'creativity' is hard for me13:54
petefothKinnison: so you can write it all, and accept that some will never be used, or write only what people sak for (or compplain about not having)13:54
jmacspetefoth: I think documentation is often seen as second class to code, and since all projects overrun, the code gets done first and the documentation gets done "later"13:54
Kinnisonpetefoth: indeed, but my point is that if you're going to write any up-front, it should be all13:55
petefothjmacs: +lots13:55
dabukalamI imagine one must have a very good understanding of codebase in order to write quality documentation. Although I hope someone will correct me.13:55
petefothjmacs: and that is not only a problem in FOSS - applies in commenrcial / closed source stuff too IME13:55
jmacsdabukalam: Not necessarily; I think you can write good documentation if you know how a system behaves, even if you don't know how it works.13:56
petefothdabukalam: depends *what* documentation. You shouldn’t need to knwo the codebase to write good *user* documeentation13:56
pedroalvarezI'm going to announce the release :)13:57
petefothjmacs: or if you know how the system is *required* to behave. Comparing software against user documentation can be good at exposing places where software does not fulfil its requirments13:57
petefothassuming to have any documentation of what the requirments are :)13:58
DavePageAlso, programmers don't make good documenters as a whole; they tend to cluster at particlar points around the Kolb Learning Circle / Honey-Mumford styles / VARK that may not reflect the users' learning preferences.13:59
DavePage(this is why the first version of any documentation I write is completely crap for end users, since I'm a reflective conceptualiser and most users are going to be concrete experimenters)14:01
paulsher1oodpedroalvarez: i made one last fix to the release notes14:02
DavePagepetefoth: Surely the point of user stories etc. is that they essentially become documentation-driven design :)14:02
pedroalvarezpaulsher1ood: thanks, I'll send the release mail with that fix14:03
petefothDavePage: I find  Use Cases (UML-style) more useful / easier to work with than User stories, because they encourage more formalisation, and less ambiguous nrrrative. But specifying requirments from a user’s perspective is a good way of doing things, and allows the development of both good spoftware *and* good user dcoumentation14:05
jmacsIs there a guide for writing run-once scripts for Baserock linux deployments, or is that a general systemd/linux thing?14:07
richard_mawas in first-boot?14:07
richard_mawwe usually drop a systemd unit into /etc with `ConditionFileExists=!/path/to/some/generated/file`14:08
pedroalvarezBaserock 14.46 has been released!14:09
jmacsrichard_maw: Right, looks like I'll need to learn a little systemd14:09
richard_mawjmacs: you also need to add a symlink into to get the unit to start14:09
pedroalvarezIf you find any error, please report them to me, or feel free to fix them if it's possible. I have  to leave now, but I've tested almos everything I could14:11
franredjmacs, I have some examples:
franrednot sure are the better examples ever, also they are not reviewed yet, but they work and may give you an idea14:12
jmacsfranred, richard_maw: Thanks14:12
richard_mawAlternatively, you could look at for how distbuild sets itself up, but it's slightly different, as it unconditionally runs, but only if it's been given /etc/distbuild/distbuild.conf14:13
paulsher1ood includes shas where no tag can be found14:28
jjardonHi, there is a new stable version of mesa (10.3.2->10.3.3) (majority of the patches are to fix stuff in the freedreno driver): ok to commit?14:29
richard_mawjjardon: I don't have enough experience in the graphics stack to know what's going on, but if radiofree gives you a +1, you can have one from me too14:32
franredjjardon, I imagine that graphics driver would be nice to test in both architectures before merging14:32
radiofreejjardon: i've already tested this on the jetson and it works fine +114:33
jjardonrichard_maw: radiofree thanks, pushed!14:34
pedroalvarezradiofree: you have my +1 in all the patches included in the release branch 14:35
* jjardon testing a patch for gstreamer 1.4.x, in case someone was planning on working on this14:38
*** aananth [~caananth@] has quit [Quit: Leaving]14:39
paulsher1oodjjardon: i would +1 if i could bjuild and see it working14:40
radiofreejjardon: could you send patches for your busybox branch as well?14:46
jjardonradiofree: I can if you want but its a single patch to remove stuff:
radiofreecool, so systemd now does ntpd?14:50
richard_mawI'm a little confused on that matter, since I saw a message recently that suggested you needed isc-ntp or chrony too, but I'm not sure.14:52
straycatpedroalvarez, woohooyay!14:54
jjardonpaulsher1ood: I will publish a branch when it builds ;)14:56
jjardonradiofree: yeah14:56
jjardonand /etc/resolv.conf as well !14:56
jjardonrichard_maw: my system booted with the correct time without me doing anything so I guess is working ;)14:57
radiofreejjardon: so i see you're matching on +  Name=en* for the dhcp config14:57
radiofreeis the consistent device naming on by default now?14:57
jjardonradiofree: yeah14:58
jjardonat least in my patches, yes14:58
richard_mawthe reason we were backing out of the deterministing interface name change was that our ifup scripts weren't able to handle them14:59
richard_mawthis is no longer needed, so we can use deterministic names now14:59
radiofreeok we'll when it's built i'll test it, however i don't think that match would work on my laptop14:59
radiofreemy ethernet device is em115:00
jjardonradiofree: uh? thats non standard, it should start by en if its a ethernet device:
dabukalamI just modified a broken link on the wiki but forgot to add a commit message, any way I can go back and add it?15:05
dabukalamIs it the end of the world?15:05
dabukalamok nvm then :)15:05
richard_mawit's possible to annotate commits after the fact with git notes, but you'd need push access to the backing repository to be able to do that15:06
petefothCan a base system do it’s building using distbuild? (Context: I’m updating glossary.mdwn in the light of the ‘build system’ => ‘devel system change’)15:06
radiofree" /sbin/ifconfig -a must show LAN-on-Motherboard ports named em[1234] "15:06
radiofreeso maybe fedora specific?15:06
jjardonmaybe older versions of systemd name things differently15:07
radiofreesystemd 208! i feel old now!15:07
jjardonseems there are some changes about this in  v217
jjardonradiofree: you know what Im going to say now ....15:08
Kinnisonpaulsher1ood: the baserock vagrant thing you just published, was that using the Baserock Vagrant system from definitions?15:09
jjardonjjardon: 217 here :P15:09
jjardonradiofree: 217 here :P15:09
paulsher1oodKinnison: i didn't publish anything. i believe that someone just noticed a previous video published by ssam2 15:10
Kinnisonaah right15:10
Kinnisonit was a lot of work to get that to go properly, so I'm glad it's documented for others to follow15:10
* paulsher1ood hopes it still works :-)15:11
radiofreehmm i think it's only 216 in fedora 21 :\15:11
straycatssam2, I'm a little confused by this m['x-build-dependencies-rubygems'].iteritems(), aren't the dependencies obtained outside of the morphology now?15:11
petefothDon’t we /shouldn’t we test that it still works?15:12
rjekNo journaled package installation?15:16
jjardonradiofree: another reason to switch: you dont need to do a massive upgrade every 6 months, you are always up-to-date15:17
richard_mawjjardon: let's not get into a distro holy war15:18
rjekObviously, everybody should use PuppyLinux.15:19
* rjek runs away.15:19
jjardonrichard_maw: I was not figthing (yet), only recommending ;)15:20
ssam2straycat: hmm, yes15:24
straycatOkay that'15:24
straycats alright then15:24
ssam2petefoth: a base system doesn't have morph, so can't use distbuild15:24
ssam2straycat: yeah, I guess that code does nothing15:25
ssam2but I stopped using build-depends for any RubyGems so I didn't notice15:26
straycatI wasn't sure because the README still mentions that hand written morphs need the x-build-deps-... field, so I guess if I rewrite that bit so it says, provide a .foreign-dependencies file15:26
petefothssam2: thanks15:26
* straycat nods15:26
ssam2straycat: yeah, dependencies are definitely specified in .foreign-dependencies now15:26
straycatok cool15:27
petefothmy question should have been ‘Can a *build* system do it’s building using distbuild?’15:27
ssam2petefoth: oh, in that case the answer is yes15:27
petefothssam2: thanks again15:27
ssam2straycat: the Package.dependencies field has the info that was in the x-build-dependencies and x-runtime-dependencies fields15:28
ssam2I think Package.dependencies is simply the contents of the .foreign-dependencies file15:28
* straycat nods15:28
ssam2i'm guessing you won't need that for Python much since, like RubyGems, PyPI doesn't store information on the build dependencies (C libaries etc.) that a package has15:29
ssam2and the python dependencies aren't usually needed at build time15:29
straycatssam2, setuptools has a notion of build dependencies, you can pass a list of setup_requires that will be downloaded into the source tree before the build/install steps are started. I've written stuff to make it so that anything specified in setup_requires will get translated into a build-dependency. I have noticed though that most packages don't seem to use setup_requires, and I've seen a few things that, in the README, tell you to go and a15:32
richard_mawstraycat: you were cut off15:33
richard_mawtell you to go and a15:33
straycattell you to go and apt-get some things, I don't think there's anything we can do 15:33
straycat                 about that really.15:33
ssam2straycat: ok, so build-depends may be a little more significant for Python packages15:35
* straycat nods15:36
petefothguides/docker.mdwn references baserock-current-devel-x86_64-chroot.tar.gz. Should that be changed to baserock-current-base-x86_64-chroot.tar.gz?15:39
pedroalvarezpetefoth: thank you for taking time to update the wiki :) I really appreciate it15:39
pedroalvarezpetefoth: yes15:40
paulsher1oodrichard_maw: ^^ ?15:43
radiofreeERROR: Ref 9b0b5206a25c1d874d6e17952c4385838e57563e is an invalid reference for repo git://
richard_mawradiofree: that commit is currently propagating to other troves from git.baserock.org15:44
richard_mawpaulsher1ood: looking15:44
radiofreethat's the error in the log15:45
richard_mawah, I got confused by the output being out of order15:46
petefothdocker.mdwn currently says ‘If you just want a Baserock container in docker, try `docker pull baserock/14.29` Can I update that to 14.46, or don’t we make / publish a docker image as part of the release?15:53
richard_mawwe haven't made any other docker container releases15:54
richard_mawit's a non-trivial amount of work15:54
petefoth richard_maw:  OK I’ll leave it as 14.29? 15:55
pedroalvarezfranred ssam2. I'd like to discuss with you some points about our infrastructure. Could it be here on IRC on Monday? 15:57
franredpedroalvarez, sure15:58
ssam2pedroalvarez: sure15:59
paulsher1oodrichard_maw: it's a trivial amount of work, tbh :)15:59
paulsher1oodpetefoth: leave it as 14.2915:59
richard_mawpaulsher1ood: is it automatable?16:00
paulsher1oodrichard_maw: possibly16:02
paulsher1oodsorry, on a call now16:02
ssam2richard_maw: definitely16:07
petefothI think that, if it’s not too much work, we *should* have a ‘baserock in a docker container’ reference system16:17
petefothbut I won’t change the wki to say that we have one (yet) :)16:17
* paulsher1ood proposed this some time aga16:18
richard_mawpetefoth: Docker ≠ Vagrant16:18
richard_mawVagrant could be a good thing to make bootstrapping into Baserock easier16:19
petefothrichard_maw: I don’t disagree, but docker seems to be flavour of the month ATM, and oit would be good to make BAserock easily accessible for people whpo are experimenting with it 16:20
KinnisonDoing a docker container based on the chroot system ought to be fairly easy16:21
petefothVagrant is a bit less mainstream from what I can tell16:21
petefothKinnison: we have the instructions - it would just be a matter of automating it, and testing the result16:21
richard_mawKinnison: I'd forgotten about chroot systems. I'd like to do away with them by just calling them devel-system.{morph/def}, and having our -x86_64-generic etc. systemd runtime depend on the chroot systems16:22
KinnisonThe chroot systems lack kernel etc.  would your proposal cover that?16:23
richard_mawyep, your systems that you actually intend to deploy to hardware (emulated or not) also include/run-depend on the bsp stratum16:24
* petefoth will add ‘Baserock in a docker container’ and ‘Basreock in Vagrant’ reference systems to the s tories-for-storyboard page16:24
petefoths/will add/has added/16:28
*** locallycompact [] has quit [Ping timeout: 258 seconds]17:06
jjardonchanged my mind: no problem to enable gallium-egl in all architectures :
*** jonathanmaw [] has quit [Quit: Leaving]17:51
straycathrm, we have delta/python-packages/* and delta/python-* is that intended?17:55
radiofreewhat a beautiful triangle17:58
radiofreejjardon: i've mostly rebuilt your systemd stuff as well17:59
*** franred [] has quit [Ping timeout: 265 seconds]18:00
jjardonradiofree: nice!18:00
*** mariaderidder [] has quit [Quit: Ex-Chat]18:03
persiavagrant is still the way cool toy for developers, but docker is getting more press because the developers are happy, and vagrant didn't work so well for devops.18:07
radiofreejjardon: won't be able to test it tonight though! still most of the graphics stuff left to build (i'm testing with a genivi imge)18:09
*** wdutch [] has quit [Quit: Quit]18:10
*** tiagogomes [] has quit [Quit: Leaving]18:28
*** rdale [] has quit [Ping timeout: 255 seconds]18:37
*** rdale [] has joined #baserock18:50
*** vmeson [~quassel@] has quit [Read error: Connection reset by peer]19:02
*** flatmush [] has quit [Quit: Leaving.]19:10
*** vmeson [~quassel@] has joined #baserock19:13
*** ssam2 [] has quit [Quit: Leaving]19:25
*** cosm [] has joined #baserock19:28
*** ssam2 [] has joined #baserock19:32
Mode #baserock +v ssam2 by ChanServ19:32
*** ssam2 [] has quit [Quit: Leaving]19:38
*** rdale [] has quit [Ping timeout: 244 seconds]23:11

Generated by 2.14.0 by Marius Gedminas - find it at!