IRC logs for #baserock for Monday, 2015-03-30

* jjardon thinks we should standardise to: explicit dependencies within the chunks in a stratum, implicit dependencies between strata01:02
*** petefoth has quit IRC05:08
*** mike has joined #baserock05:26
*** mike is now known as Guest8455805:26
*** petefoth has joined #baserock06:26
*** petefoth has quit IRC06:47
*** petefoth has joined #baserock06:58
*** a1exhughe5 has joined #baserock07:09
*** Albert has joined #baserock07:31
*** Albert has quit IRC07:31
*** Albert has joined #baserock07:32
*** rdale has joined #baserock07:43
Kinnisonjjardon: implicit between?07:56
*** jonathanmaw has joined #baserock07:58
*** ssam2 has joined #baserock08:00
*** ChanServ sets mode: +v ssam208:00
*** bashrc_ has joined #baserock08:01
jjardonActually I think I would do everything explicit, so its easier to know what depends on what08:02
KinnisonI prefer explicit dependencies but I can understand when others do not -- lists get a tad long08:05
KinnisonIt's a relative cognitive load thing08:05
Kinnisonhaving to trace through layers of deps increases cognitive load, as does processing a long list of deps -- each is better in some circumstances, each is worse in some circumstances08:06
rjekOn one hand, the whole point of having tooling is for it to do some of the work for you.08:09
rjekOn the other, complex magic.08:09
petefothSo a simple tool which follows implicit dependency links and  produces the full list....08:11
*** mdizzle has joined #baserock08:12
*** fay_ has quit IRC08:15
*** fay_ has joined #baserock08:16
*** franred has joined #baserock08:21
*** zoli__ has joined #baserock08:24
bashrc_yes, a tool to produce the full dependency list if you need it08:26
*** tiagogomes_ has joined #baserock08:29
paulsherwoodif stratum foo depends on stratum bar, then istm unavoidable that we are assuming each component of foo can depend on any/all of the components in bar08:29
KinnisonI concur08:41
KinnisonBut if stratum foo build-deps on stratum bar, does foo implicitly build-dep on the build-deps of bar?08:41
KinnisonThat was the implication of jjardon's 2am suggestion08:41
*** gary_perkins has joined #baserock08:48
jjardonKinnison: mmm, I do not think the list of dependencies will be much longer: probably we only have to add build-essential, and core to the stratum that depends only on foundation: my reasoning is that at some point there is not a lot of verticality in the dependency tree (lot of strata depends directly on core)08:48
*** CTtpollard has joined #baserock08:56
*** petefoth has quit IRC08:59
*** petefoth has joined #baserock09:01
*** Guest84558 has quit IRC09:15
*** Krin has joined #baserock09:20
jjardonSotK: about partial builds: does that mean that I can, for example, build a new version of mesa and create a new system without rebuilding all the chunks that are on top of mesa?09:24
SotKjjardon: yes, you can do `morph build SYSTEM mesa`, which will build just mesa and everything it depends on09:26
SotKjjardon: the patches in Gerrit need a tweak or two though, I'll be updating them in a minute or so :)09:26
ssam2jjardon: you'd still have to edit your system to not contain all the chunks on top of Mesa, so I don't think 'partial build' is what you think it is09:27
ssam2it's really a way of going 'test if this builds and then stop.' I think09:27
radiofreeyou could add "mesa-test" to your system at the bottom and build that?09:28
* SotK misread jjardon's message slightly09:28
ssam2radiofree: indeed, you can already do that09:28
*** Guest84558 has joined #baserock09:29
jjardonMy idea is that you could test your system, only changing xserver for example, without rebuilding anything more09:30
jjardonBut I guess this is not the idea of this series?09:31
straycatCan someone remind me again what the build system is for? I've never used one09:32
Kinnisonjjardon: sounds like you want the proposed "morph hack" thing which robtaylor and I did a very rough treatment of at one of the meetups09:32
Kinnisonstraycat: Do you mean 'build-system' in chunk morphologies?09:32
KinnisonYou mean the build-* stuff in systems/ ?09:33
straycatI'm trying to add someting to a devel system, and someone suggested I add it also to a bunch of other systems I've never used09:33
Kinnisonaah right09:33
Kinnisonbuild is essentially devel without the tools-for-hew-mons09:33
KinnisonIt's the basis for things like distbuild workers etc09:33
jjardonKinnison: no idea, is there some minutes/wiki page/email where I can take a look?09:34
straycatDoes anyone else not have a problem with how difficult and how much time it's taking for me to perform a relatively simple procedur?09:34
straycatI mean, I've had to change like 20 files just to add swift to devel09:35
wdutchrichard_maw: I was told to resubmit the libpcap patch via gerrit and I think it's been merged09:35
straycatNow I've got to edit even more?09:35
Kinnisonjjardon: I doubt it sadly, you could look on the ML archives09:36
Kinnisonstraycat: that's a surprisingly large number of things to change09:36
Kinnisonstraycat: swift as in the programming language?09:36
richard_mawKinnison: no, OpenStack component09:36
straycatno swift as in a distributed object store09:36
KinnisonOh right09:36
* SotK hates adding strata for this exact reason09:36
* richard_maw wants runtime dependencies09:37
straycatSotK, problem is clustering strata together leads to really inefficient builds09:37
radiofreereleases seem to be using build-systems-*, wouldn't it be nicer for a developer to have a devel-system-*?09:37
* Kinnison fears that if we add runtime deps we may as well just switch to a package-based structure and do away with strata entirely09:37
* SotK goes away to write `morph add-stratum` :D09:37
straycatSotK, it would be neater to have templates and possible multi arch systems, this was suggested by locallycompact on friday09:38
straycatanyway this discussion is academic for me right now09:38
*** edcragg has joined #baserock09:41
jjardonKinnison: found it, thanks
*** Guest84558 has quit IRC09:50
jjardonSotK: as your are building all the dependencies in your partial build approach, maybe its better to change the syntax to: morph build <system> --stop-at=<chunk> ?10:02
straycatrichard_maw, race condition?10:03
*** Guest84558 has joined #baserock10:03
straycatrichard_maw, also i figured it was too obvious for a summary, but *shrug*10:04
*** ssam2 has quit IRC10:06
paulsherwoodstraycat: nothing is too obvious here :-)10:11
*** ssam2 has joined #baserock10:20
*** ChanServ sets mode: +v ssam210:20
* SotK discovers why Gerrit needs the change number twice when fetching a change10:54
SotKThe first number is the ID of the change mod 100, the second is the actual ID number10:55
SotKNeither of these numbers are the Change-ID mind you10:55
jmacsDo I need any special version of OpenStack to deploy deploy baserock nodes into, or will it work with stock openstack?10:56
KinnisonWe install it into a stock stack at Datacentred10:56
Kinnisonso there shouldn't be any particular things you need10:57
KinnisonSomeone here can tell you how to turn on cloud-init etc if you need that10:57
jmacsI've no idea if I need that yet10:57
*** De|ta has joined #baserock10:57
ssam2SotK: wow, why does it need the number mod 100??10:59
SotK"The only reason for this initial number is to reduce the number of files in any given directory within the git repository."11:00
richard_mawer, what?11:01
pedroalvarezjmacs: Openstack deployments "expert" here. What are you trying to achieve?11:04
pedroalvarezjmacs: just deploy a (e.g. devel) system to openstack?11:04
jmacsYes, but I'd like to understand what's involved in setting up the server11:04
pedroalvarezI'm not sure what you mean. Setup Openstack?11:05
pedroalvarezAre you talking about deploying a Openstack server using baserock?11:06
jmacsWhatever hosts Openstack nodes, if that's called a server, or something else, I want to install that on a computer and then deploy baserock nodes within it11:10
DavePagejmacs wants to install a single-node OpenStack on some hardware he already has. This has been done by various people including gary_perkins and richard_maw.11:11
pedroalvarezwell, it's very well detailed in the openstack-install-guide.
jmacsRight, that's all I was asking, whether the default install was OK for baserock nodes11:13
pedroalvarezoh, yes11:14
pedroalvarezsorry, I was confuesd. Many things invovling openstack + baserock these days11:14
gary_perkinsjmacs: there are many different ways and documentation for installing and setting up OpenStack on different distributions. There are also some handy setup scripts, "devstack" comes to mind. But you'll learn less about OpenStack then and they tend to be restrictive and do things in a particular way that may not be to your liking11:17
bashrc_does anyone think that firehose belongs in a particular stratum? If not, I'll make a separate one for it.11:30
ssam2own stratum sounds sensible11:37
ssam2does look like it might be useful to us? seems to allow userspace chroots and bindminds11:45
ssam2i definitely don't want a bindmind11:45
ssam2oh, seems like it's a bit obsolete, reading
*** a1exhughe5 has quit IRC11:57
*** a1exhughe5 has joined #baserock12:11
jjardonHi!, there is patch in gerrit in "Submitted, Merge Pending" status. Is this expected? Normally other patches applied immediately12:17
jjardonCan we change the name of devel-* system to something more descriptive? the description says "A system with useful tools for doing Baserock development.", but you can do baserock development with a build system as well. Taking a look to the contents maybe makes sense to call them cloud-* or openstack-* systems?12:27
straycatI'd rather not12:28
persiaThey aren't differentiated because of cloudiness, rather because of human-usable tooling.12:28
jjardonwhat do you mean? If Im using baserock to develop in a board, I will probably dont need ansible, nodejs or openstack12:30
persiaPossibly, but you probably don't need any of those if you're developing an applicance to deploy to OpenStack either.12:31
straycatdevel systems don't have openstack?12:31
KinnisonI think they have the openstack clients12:31
SotKthey have openstack-clients don't they?12:31
straycatahh true12:32
paulsherwoodssam2: i'd be interested in something for userspace containerisation that can be used on other oses, as well as linux if poss12:34
jjardonpersia: ok, so what "devel" system means, then? Seems the description is too generic12:34
persiajjardon: To me, the "devel" system means: a reference system for a set of default software that should be usable for a wide range of development activities using Baserock.12:35
paulsherwoodjjardon: it's historic... and the meaning has changed over time12:35
paulsherwoodpersia: +112:35
persiaI don't imagine it to be actually useful for any individual developers: everyone has pet tools.12:35
* paulsherwood manages to do development using devel... but it lacks a web browser. and he prefers textmate via sshfs :-)12:36
persiapaulsherwood: The option I'd prefer to recommend is for you to add a browser and textmate to paulsherwood.morph to manage your system.12:37
paulsherwoodpersia: that would require a windowing system, surely?12:38
KinnisonAnd OS X12:38
Kinnisonsince textmate is an OS X editor12:38
* paulsherwood is unsure if textmate is available for linux12:38
SotKwe had XFCE working in Baserock once upon a time right?12:38
persiapaulsherwood: There are several examples of systems that have windowing systems12:38
KinnisonI think jjardon is maintaining a GNOME system12:39
paulsherwoodSotK: yes, we did.12:39
persiaKinnison: One ought be able to handle that with MoL and binfmt12:39
paulsherwoodjjardon: is that true? last time i checked i thoulght it was incomplete?12:39
jjardonIts not in a working state yet12:39
Kinnisonpersia: eww12:39
persiaKinnison: Yes, but that is a side effect of the tool choice.  The alternative is less open and clean.12:40
* SotK wonders if we still do12:40
Kinnisonpersia: MoL also seems unmaintained and ppc-only12:40
paulsherwoodi think straycat was the last person to look, SotK12:40
jjardonunfortunatelly there are several things broken underneath that need to be fixed first12:41
paulsherwoodfor example?12:41
* CTtpollard seems to remember tlsa looking at XFCE12:41
persiaKinnison: Too bad.  Seems the successor is Darling, but it doesn't have very complete support yet: I wonder if TextMate works.12:43
tlsaCTtpollard: I was looking at the XFCE system for a day or 2 as I happended to choose to try building it while spinning up on baserock, but was moved to looking at mason-v2 before I got it going12:44
jjardonpaulsherwood: you have some of the identified issues in!/story/21 and!/story/512:44
paulsherwoodjjardon: great, thank you12:45
* SotK wonders if he has time to look at XFCE tonight12:45
tlsaSotK: This is where I was working:
tlsathe xfce system got broken by some X-->XWayland changes in other stratum12:47
petefothIf we have node.js, npm and development headers for GNOME Keyring in baserock, then we could have Atom ( and
jjardonssam2: btw, I get "Internal Server Error" when trying to log in storyboard, not sure is a known issue?12:48
*** De|ta_ has joined #baserock12:48
ssam2great work storyboard!12:50
ssam2not a known issue.12:51
rdalehas samba been built for baserock?12:52
ssam2jjardon: seems to be due to the openid migration http -> https12:52
ssam2I did test and it seemed to work, but seems not12:52
jjardoncan anyone log in storyboard, or Im the only one with problems?12:53
KinnisonI think ssam2 is still mid-fix for storyboard12:53
Kinnisonfor the https support on the openid12:53
ssam2jjardon: should work again now12:54
franredjjardon,the openstack clients are in devel system to be able to deploy to a openstack cloud or connect to any of the openstack services no matter which one. So you can deploy your Gnome image to an openstack cloud an spin a VM on it12:54
jjardonssam2: did you d any magic already? seems to work now12:54
franredfor example12:54
jjardonoh, ok :) thanks!12:55
ssam2jjardon: yes, I manually updated the users table in the database to change existing openids from http -> https12:55
jjardonfranred: I still think the name and the descriptionof those systems can be improved12:56
persia+1 from me on improving the descriptions12:59
franredjjardon, Im not against improving descriptions, just give you some info about why there are some openstack bits in devel systems :)13:00
franredis ready to merge?13:00
jjardonId do a patch but Im the one not sure what those systems are for :)13:00
jjardonfranred: yeah, sure, thanks for that!13:01
jjardonfranred: yes, but it's in a suspicious "Submitted, Merge Pending" status13:02
ssam2I wonder if this is another instance of the bug which causes Gerrit to not actually merge things when it says they are merged.13:02
SotKI'm guesssing the limbo is due to the "Related changes" section including unmerged stuff13:02
SotKgiven the "Parent" of that change is one of the related changes13:03
ssam2ah, that makes sense13:03
SotKISTR when messing around with Zuul and Gerrit that if I submitted something which depended on another change it said Merge Pending until I merged all the dependencies13:03
jjardonok, so seems its my fault: I probably sent the kernel patch from a branch that contains the glibc one13:06
jjardonat least we now know gerrit track the order of the commits correctly13:07
*** ssam2 has quit IRC13:30
*** zoli__ has quit IRC13:33
straycatrichard_maw, race condition?13:41
*** ssam2 has joined #baserock13:44
*** ChanServ sets mode: +v ssam213:44
richard_mawstraycat: it works by the gerrit-controlled repository on being merged with the version hosted on, so if there's a change in-between gerrit fetching and gerrit pushing, then one side is going to lose13:44
straycatoh, i thought gerrit would lose and whoever merged would have to  click rebase or something?13:45
richard_mawedcragg: I've reviewed your moonshot-deployment patches on gerrit13:45
straycator, well, or i lose and i have to rebase13:45
richard_mawstraycat: AIUI that would require gerrit to have direct access to the same repository as is running on, which I don't think it does13:45
straycatit doesn't? :s13:46
SotKI think that gerrit.b.o uses lorry to mirror things from git.b.o into its repos, and some gerrit plugin to push changes from its repos into the repos in git.b.o13:47
SotKBut I might be wrong13:47
straycatalright so we should still be able to merge straight into gbo if we want13:48
ssam2force-push is disabled in the gerrit-replication plugin, to avoid losing any commits if people push stuff manually to, but that means that it can stop working if different stuff gets merged to master of both repos at the same time13:48
ssam2it's less likely to break stuff if you merge straight to master of gerrit, i can add you to the Mergers group in gerrit if you want to do that13:49
richard_mawstraycat: that requires that both and have shared access to the same repository, which would require it to be shared with NFS13:49
richard_mawstraycat: either that, or the gerrit plugin becoming smart enough to feed information backwards that it couldn't merge a given commit13:50
* richard_maw gets on with reviewing some patches13:51
straycati don't think this fix can possibly conflict with anything currently in gerrit tbh, unless we have stuff that happens to be also touching the extension code13:51
ssam2the conflict would happen if commit A gets merged in gerrit in the same 2 minutes that commit B gets merged in git.baserock.org13:52
ssam2doesn't matter on the content of either commit, because gerrit-replication is using 'git push' to push stuff to, which will fail if it is a non-fastforward merge13:52
straycatwon't gerrit just rebase and try again?13:52
ssam2the gerrit-replication will not do that13:53
ssam2which is sensible, when one is trying to do replication13:53
straycatokay, i'll push this to gerrit +2 it and merge then13:54
ssam2if it already went through code review on the mailing list, it doesn't need to go through Gerrit as a proposed change13:54
ssam2just push to 'ssh:// master' instead of 'ssh:// master'13:55
ssam2with appropriate Reviewed-By tags13:55
ssam2ssh:// even13:56
bashrc_in gerrit is there a way of expressing that one change is dependent upon another?13:58
straycatif you push a branch with a set of commits they become dependent on each other in commit order13:58
bjdooksis there a genric/generic-ish arm7l system available as a .tgz?13:58
richard_mawbjdooks: not that I'm aware of, but I think radiofree and jonathanmaw were working on armv7l recently14:00
radiofreebjdooks: i have a rootfs if tha'ts what you're after14:01
radiofreebjdooks: it's hf, that ok?14:01
bjdooksradiofree: yes. please, something i can extract onto a sd card14:01
bjdooksyes, armv7lhf should be fine14:01
radiofreeok, sent you a /msg14:03
franredummm, <-- I though morph care about the submodules. Why would we need to do a git submodule update here?14:19
franredjjardon, ^^14:21
pedroalvarezfranred: can you make those comments in the patch?14:21
pedroalvarezhe is actually only moving the file to another place14:22
jjardonfranred: we dont, thats what we have currently in definitions, I fix that in the next patches14:22
edcraggrichard_maw, pedroalvarez, franred, jmacs, Kinnison:
edcraggnot sure if that's because the LE rootfs we have is fairly old now, though14:27
richard_mawedcragg: unfortunately "cannot compute suffix of object files: cannot compile" is one of the least useful error messages to get out of ./configure14:28
Kinnisonlast time I saw something like that it was a missing build-depend14:28
Kinnisonor a failed ldconfig or something14:29
* richard_maw assumed that we'd merged in all the changes for the ARMv8l64 BSP14:29
edcraggit should be there, i'll have a closer look14:30
*** wschaller_ has joined #baserock14:35
jjardonfranred: thanks for the review, but you are trying to correct a patch I didnt do (im only moving things around). I actually fix those issues in a posterior patch14:36
franredjjardon, true, sorry for my fast response - I haven't look at the rest of the patches, I will do it. Apologies once again for the noise14:38
jjardonfranred: no worries :)14:41
paulsherwoodKinnison: last time you saw it, was in ybd i think :-)14:42
paulsherwoodin other news, thanks to input from Kinnison, ybd can successfully build build-essential and core now :-)14:43
Kinnisonpaulsherwood: when are you going to have ybd clean up by default?14:45
Kinnisonpaulsherwood: I keep having to ^C and clean up14:45
paulsherwoodi'll raise an issue14:45
straycatrichard_maw, you already merged it? >.>14:45
jjardonhow should opinions be reviewed? For example, I think its better to add "morph info <chunk>" instead "morph get-chunk-details <chunk>" In these cases, should we set -1 or leave at 0?14:46
paulsherwoodKinnison: you could rmove the comment from
richard_mawstraycat: merged what sorry?14:47
straycat% escapes14:47
straycatlooks like someone did14:47
richard_mawit was not I14:47
straycatalright that's weird14:48
straycatif force pushes to master were allowed...14:49
straycati don't know how that commit got ther but it's the wrong one14:51
Kinnisonforce-pushing master makes me a sad bunny14:52
straycatin this case it would be useful14:52
KinnisonBut it'd also bugger anyone up who had based off master in the meantime14:52
* pedroalvarez suggests revert14:52
KinnisonJust submit a reversion of the bad patch and a merge of the correct one14:52
straycatyes all of one commit that's about to me merged in by gerrit with a much more meaningful message14:52
KinnisonRemember, anything that hits master of we have to assume has *already* been mirrored to all our users by the time we notice14:53
ssam2jjardon: doing design discussion in patch reviews isn't really the right thing14:53
jjardonssam2: sure, what should I do then?14:54
ssam2in seriousness, I don't know. Collaborative design without any kind of leadership or specification is pretty difficult14:55
straycatKinnison, the commit is identical14:56
ssam2but if the change looks OK apart from one cosmetic thing, consider giving it a +1 and then submitting a patch later to change the cosmetic thing you didn't like about it. At least then the discussion of that one thing is isolated, instead of being mixed in with code review14:56
ssam2or discussing it on the list14:56
ssam2the list is probably the best place to do design discussion really14:56
Kinnisonstraycat: identical?14:57
Kinnisonstraycat: If it's identical then it's the same commit and so there's no issue14:57
straycatsame content different commit message14:57
Kinnisonthen it's not identical14:57
Kinnisondifferent message == different commit14:57
straycatoh shrug whatever, it's just a commit msg i don't even care14:58
jjardonssam2: not sure if change the option from "get-chunk-info" to "info" is only cosmetic, but ok. I will leave it as a comment14:58
ssam2I mean 'cosmetic' in that it's a design thing, rather than a code thing14:59
ssam2so it's much harder to have an objective opinion about it14:59
straycati pushed the wrong thing to gerrit it seems15:00
radiofree this breaks qtwebkit15:01
* jjardon doesnt have idea why he gets a merge conflict in the xcb_0.4.0 series15:01
jjardonradiofree: in what way?15:01
Kinnisonstraycat: Unless it has rude words or leaks secrets, I wouldn't worry about it and just move on :)15:02
radiofreejjardon: in this way
jjardonseems there is already a patch available
jjardonmaybe you can cherry-pick it?15:03
radiofreejjardon: that's in 5.4 dev branch, and not in 5.4.1, also we're using 5.515:03
radiofreewould patches to add qt5 to the weston system be accepted?15:03
jjardonI think its a good idea15:04
jjardonif its not in the ci, its not really supported and we will have this problem again and again15:05
radiofreeok, and let's assume it was already in the CI system, and that glib patch lands and breaks qtwebkit, the solution would be to revert that glib patch?15:06
jjardonId prefer to fix qtwebkit, but yes if the solution doesnt exist or its hard to implement15:07
radiofreethere's no release version of qtwebkit that currently has the fix15:07
jjardonradiofree: I think in the bug report there is a patch for 5.5 btw15:07
radiofreethe next 5.4 release will have it15:07
radiofreejjardon: yes i know, but at the moment qtwebkit 5.4.1 will be broken (probably), so can we revert that patch?15:08
radiofreei'm assuming it doesn't actually give us anything other than being the latest version?15:09
*** zoli__ has joined #baserock15:09
radiofreeor does gtk3 need it?15:09
jjardonradiofree: gtk3 depends on glib 2.43, but its not in the ci, so I consider it not officially supported. But I think the correct solution is to fix qtwebkit cherry-picking the fix. If this is going to take more time than you have, go ahead with the reversion15:12
radiofreein the interests of sanity we're going with a patched 5.5 branch, but qtwebkit in master is now broken, so don't use that15:16
radiofreei'll test to see if HEAD of 5.4 works with 5.4.1 tonight15:18
* straycat pushes
radiofreei probably ask this every week, but how much RAM does mason-x86-64 have?15:19
persiaSo, while I like patch series to separate things, I am hugely opposed to landing patches that have known issues resolved in later patches in the series.  This sort of behaviour just makes history hard to read.15:28
ssam2radiofree: 2GB RAM, 2CPUs15:35
* radiofree won't remove max-jobs from WebKit then15:38
jjardonpersia: I think everyone agree on that15:41
edcraggrichard_maw, pedroalvarez, franred, jmacs, Kinnison, fay_, a1exhughe5: 2015-03-30 15:49:31 [Build 21/411] [gcc]15:51
pedroalvarezedcragg: progress!15:51
Kinnisonedcragg: \o/15:52
*** a1exhughe5 has quit IRC16:00
*** zoli__ has quit IRC16:04
*** jonathanmaw has quit IRC16:04
*** ssam2 has quit IRC16:09
paulsherwoodedcragg: please could you post some of the Elapsed time lines from your builds on that box somewhere?16:09
paulsherwoodeg :-)16:09
* paulsherwood is particularly interested in the gcc time - it's a good indicator16:11
*** ssam2 has joined #baserock16:13
*** ChanServ sets mode: +v ssam216:13
*** zoli__ has joined #baserock16:18
*** ssam2 has quit IRC16:24
*** zoli__ has quit IRC16:25
*** ssam2 has joined #baserock16:30
*** ChanServ sets mode: +v ssam216:30
*** gary_perkins has quit IRC16:39
*** zoli__ has joined #baserock16:44
*** Krin has quit IRC16:48
*** Krin has joined #baserock16:51
*** Guest84558 has quit IRC16:57
*** bashrc_ has quit IRC17:00
*** ssam2 has quit IRC17:01
*** mdizzle has quit IRC17:03
*** CTtpollard has quit IRC17:07
*** ssam2 has joined #baserock17:14
*** ChanServ sets mode: +v ssam217:14
*** ssam2 has quit IRC17:17
*** wschaller_ has quit IRC17:22
*** edcragg has quit IRC17:27
*** Albert has quit IRC17:35
jjardonradiofree: It would be great if you can review (seems to solve the problem here)17:37
*** Albert has joined #baserock17:42
*** tiagogomes_ has quit IRC17:45
*** rdale has quit IRC17:49
*** mdunford has quit IRC17:53
jjardon(btw, qt5-devel system seems to be broken at the moment) (fribidi and eval doesnt compile)19:08
*** zoli__ has quit IRC19:21
SotKmason is failing again :(19:28
straycatokay gerrit you added vim style visual selection19:30
straycatthat is nice19:30
straycatahh and vim style line navigation19:33
straycatok i might not hate this19:35
* straycat forgets what +1/-1 etc mean in this new system19:52
* SotK reads it as +1 == +1, -1 == -0, 0 == +019:53
straycatso to veto i say -219:53
*** zoli__ has joined #baserock19:55
straycatSotK, oh if you hover over the scores it explains >.>20:07
* SotK finally has an up to date devel VM, only about an hour and a half after he started...20:19
* SotK considers joining the people who think we should release a devel image20:20
straycati think it's a bit weird that we don't20:20
straycatgiven it's the system most of us use20:21
persiaSotK: What made it take so long?  We should make that quick.20:27
SotKpersia: I was upgrading a really old devel vm and had to redownload every artifact20:33
SotKas my cache was very outdated (November last year I think)20:34
persiaMakes sense.  Why would a larger image be faster?  Just TCP windows, or something else?20:34
*** zoli__ has quit IRC20:34
*** zoli__ has joined #baserock20:34
SotKI also spent about 25 minutes making food whilst I thought it was downloading artifacts but then came back to discover I'd been building stuff from mini-utils onwards because Mason is red :320:35
*** zoli__ has joined #baserock20:35
persiaUgh.  That's annoying.20:36
SotKpersia: Its quicker to download + set up a compressed devel image than download all the artifacts in a system and then the system artifact itself and then do an upgrade20:37
persiaI still think it is a bug that we have to download all the artificats *AND* the system artifact.  IF we're building something cached, we should just get the completed system from cache.20:38
SotKI think so too20:38
SotKactually, maybe I could have just done `morph upgrade` if the system artifact was in the remote cache20:39
persiaSo while I still belong to the school of folk that think we shouldn't need a devel image, I think we have two critical bugs that mean that this is a future target goal rather than being a reality: 1) we lack pre-merge testing, so we sometimes build broken things, and 2) using the tooling requires more than twice the bandwidth.20:40
SotKyeah, if it was quick I wouldn't mind the lack of a devel image, it works as a nice tutorial for upgrading I think20:42
SotKits just annoying that said tutorial takes ages20:43
* SotK rebases tlsa's XFCE work and starts building20:43
persiaAny because it takes ages, people don't do it often, leading to use-latest-morph and fail-to-build-master annoyingly often.20:44
* SotK finds many gnome-common dependencies21:30
*** Albert has quit IRC21:48
SotK2015-03-30 22:59:38 [Build 348/348] [xfce-system] system xfce-system-rootfs is cached23:03
rjekSotK: Now Cinnamon and MATE :)23:11
SotKI don't know if it works yet!23:12
SotKIt doesn't work :(23:22
SotKAh well, it builds now at least23:22
* SotK goes to bed and hopes the French doors don't blow open again23:22
jjardonSotK: if you out the issues you found in the storyboard maybe we can work together in some of them23:26

Generated by 2.15.3 by Marius Gedminas - find it at!