| * jjardon thinks we should standardise to: explicit dependencies within the chunks in a stratum, implicit dependencies between strata | 01:02 | |
| *** petefoth has quit IRC | 05:08 | |
| *** mike has joined #baserock | 05:26 | |
| *** mike is now known as Guest84558 | 05:26 | |
| *** petefoth has joined #baserock | 06:26 | |
| *** petefoth has quit IRC | 06:47 | |
| *** petefoth has joined #baserock | 06:58 | |
| *** a1exhughe5 has joined #baserock | 07:09 | |
| *** Albert has joined #baserock | 07:31 | |
| *** Albert has quit IRC | 07:31 | |
| *** Albert has joined #baserock | 07:32 | |
| *** rdale has joined #baserock | 07:43 | |
| Kinnison | jjardon: implicit between? | 07:56 |
|---|---|---|
| *** jonathanmaw has joined #baserock | 07:58 | |
| *** ssam2 has joined #baserock | 08:00 | |
| *** ChanServ sets mode: +v ssam2 | 08:00 | |
| *** bashrc_ has joined #baserock | 08:01 | |
| jjardon | Actually I think I would do everything explicit, so its easier to know what depends on what | 08:02 |
| Kinnison | I prefer explicit dependencies but I can understand when others do not -- lists get a tad long | 08:05 |
| Kinnison | It's a relative cognitive load thing | 08:05 |
| Kinnison | having 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 circumstances | 08:06 |
| rjek | On one hand, the whole point of having tooling is for it to do some of the work for you. | 08:09 |
| rjek | On the other, complex magic. | 08:09 |
| petefoth | So a simple tool which follows implicit dependency links and produces the full list.... | 08:11 |
| *** mdizzle has joined #baserock | 08:12 | |
| *** fay_ has quit IRC | 08:15 | |
| *** fay_ has joined #baserock | 08:16 | |
| *** franred has joined #baserock | 08:21 | |
| *** zoli__ has joined #baserock | 08:24 | |
| bashrc_ | yes, a tool to produce the full dependency list if you need it | 08:26 |
| *** tiagogomes_ has joined #baserock | 08:29 | |
| paulsherwood | if 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 bar | 08:29 |
| Kinnison | I concur | 08:41 |
| Kinnison | But if stratum foo build-deps on stratum bar, does foo implicitly build-dep on the build-deps of bar? | 08:41 |
| Kinnison | That was the implication of jjardon's 2am suggestion | 08:41 |
| *** gary_perkins has joined #baserock | 08:48 | |
| jjardon | Kinnison: 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 |
| Kinnison | Perhaps | 08:50 |
| *** CTtpollard has joined #baserock | 08:56 | |
| *** petefoth has quit IRC | 08:59 | |
| *** petefoth has joined #baserock | 09:01 | |
| *** Guest84558 has quit IRC | 09:15 | |
| *** Krin has joined #baserock | 09:20 | |
| jjardon | SotK: 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 |
| SotK | jjardon: yes, you can do `morph build SYSTEM mesa`, which will build just mesa and everything it depends on | 09:26 |
| SotK | jjardon: the patches in Gerrit need a tweak or two though, I'll be updating them in a minute or so :) | 09:26 |
| ssam2 | jjardon: 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 is | 09:27 |
| ssam2 | it's really a way of going 'test if this builds and then stop.' I think | 09:27 |
| radiofree | you could add "mesa-test" to your system at the bottom and build that? | 09:28 |
| * SotK misread jjardon's message slightly | 09:28 | |
| ssam2 | radiofree: indeed, you can already do that | 09:28 |
| *** Guest84558 has joined #baserock | 09:29 | |
| jjardon | My idea is that you could test your system, only changing xserver for example, without rebuilding anything more | 09:30 |
| jjardon | But I guess this is not the idea of this series? | 09:31 |
| straycat | Can someone remind me again what the build system is for? I've never used one | 09:32 |
| Kinnison | jjardon: sounds like you want the proposed "morph hack" thing which robtaylor and I did a very rough treatment of at one of the meetups | 09:32 |
| Kinnison | straycat: Do you mean 'build-system' in chunk morphologies? | 09:32 |
| straycat | No | 09:33 |
| Kinnison | You mean the build-* stuff in systems/ ? | 09:33 |
| straycat | I'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 used | 09:33 |
| Kinnison | aah right | 09:33 |
| Kinnison | build is essentially devel without the tools-for-hew-mons | 09:33 |
| straycat | right... | 09:33 |
| Kinnison | It's the basis for things like distbuild workers etc | 09:33 |
| jjardon | Kinnison: no idea, is there some minutes/wiki page/email where I can take a look? | 09:34 |
| straycat | Does 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 |
| straycat | *procedure | 09:34 |
| straycat | I mean, I've had to change like 20 files just to add swift to devel | 09:35 |
| wdutch | richard_maw: I was told to resubmit the libpcap patch via gerrit and I think it's been merged | 09:35 |
| straycat | Now I've got to edit even more? | 09:35 |
| Kinnison | jjardon: I doubt it sadly, you could look on the ML archives | 09:36 |
| Kinnison | straycat: that's a surprisingly large number of things to change | 09:36 |
| straycat | yes | 09:36 |
| Kinnison | straycat: swift as in the programming language? | 09:36 |
| richard_maw | Kinnison: no, OpenStack component | 09:36 |
| straycat | no swift as in a distributed object store | 09:36 |
| Kinnison | Oh right | 09:36 |
| * SotK hates adding strata for this exact reason | 09:36 | |
| * richard_maw wants runtime dependencies | 09:37 | |
| straycat | SotK, problem is clustering strata together leads to really inefficient builds | 09:37 |
| radiofree | releases 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 entirely | 09:37 | |
| * SotK goes away to write `morph add-stratum` :D | 09:37 | |
| straycat | SotK, it would be neater to have templates and possible multi arch systems, this was suggested by locallycompact on friday | 09:38 |
| straycat | *possibly | 09:38 |
| straycat | anyway this discussion is academic for me right now | 09:38 |
| *** edcragg has joined #baserock | 09:41 | |
| jjardon | Kinnison: found it, thanks http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2013-February/001372.html | 09:44 |
| *** Guest84558 has quit IRC | 09:50 | |
| jjardon | SotK: 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 |
| straycat | richard_maw, race condition? | 10:03 |
| *** Guest84558 has joined #baserock | 10:03 | |
| straycat | richard_maw, also i figured it was too obvious for a summary, but *shrug* | 10:04 |
| *** ssam2 has quit IRC | 10:06 | |
| paulsherwood | straycat: nothing is too obvious here :-) | 10:11 |
| *** ssam2 has joined #baserock | 10:20 | |
| *** ChanServ sets mode: +v ssam2 | 10:20 | |
| SotK | bah | 10:53 |
| * SotK discovers why Gerrit needs the change number twice when fetching a change | 10:54 | |
| Kinnison | ? | 10:54 |
| SotK | The first number is the ID of the change mod 100, the second is the actual ID number | 10:55 |
| SotK | Neither of these numbers are the Change-ID mind you | 10:55 |
| jmacs | Do I need any special version of OpenStack to deploy deploy baserock nodes into, or will it work with stock openstack? | 10:56 |
| Kinnison | We install it into a stock stack at Datacentred | 10:56 |
| Kinnison | so there shouldn't be any particular things you need | 10:57 |
| Kinnison | Someone here can tell you how to turn on cloud-init etc if you need that | 10:57 |
| jmacs | I've no idea if I need that yet | 10:57 |
| *** De|ta has joined #baserock | 10:57 | |
| Kinnison | :) | 10:58 |
| ssam2 | SotK: 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_maw | er, what? | 11:01 |
| pedroalvarez | jmacs: Openstack deployments "expert" here. What are you trying to achieve? | 11:04 |
| pedroalvarez | jmacs: just deploy a (e.g. devel) system to openstack? | 11:04 |
| jmacs | Yes, but I'd like to understand what's involved in setting up the server | 11:04 |
| pedroalvarez | I'm not sure what you mean. Setup Openstack? | 11:05 |
| pedroalvarez | Are you talking about deploying a Openstack server using baserock? | 11:06 |
| jmacs | No | 11:06 |
| jmacs | Whatever 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 it | 11:10 |
| DavePage | jmacs 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 |
| pedroalvarez | right | 11:12 |
| pedroalvarez | well, it's very well detailed in the openstack-install-guide. http://docs.openstack.org/juno/install-guide/install/apt/openstack-install-guide-apt-juno.pdf | 11:13 |
| jmacs | Right, that's all I was asking, whether the default install was OK for baserock nodes | 11:13 |
| pedroalvarez | oh, yes | 11:14 |
| pedroalvarez | sorry, I was confuesd. Many things invovling openstack + baserock these days | 11:14 |
| gary_perkins | jmacs: 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 liking | 11:17 |
| bashrc_ | does anyone think that firehose belongs in a particular stratum? If not, I'll make a separate one for it. | 11:30 |
| ssam2 | own stratum sounds sensible | 11:37 |
| ssam2 | does http://proot.me/ look like it might be useful to us? seems to allow userspace chroots and bindminds | 11:45 |
| ssam2 | bindmounts | 11:45 |
| ssam2 | i definitely don't want a bindmind | 11:45 |
| ssam2 | oh, seems like it's a bit obsolete, reading https://plus.google.com/107605112469213359575/posts | 11:47 |
| *** a1exhughe5 has quit IRC | 11:57 | |
| *** a1exhughe5 has joined #baserock | 12:11 | |
| jjardon | Hi!, there is patch in gerrit in "Submitted, Merge Pending" status. Is this expected? Normally other patches applied immediately | 12:17 |
| jjardon | Can 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 |
| straycat | I'd rather not | 12:28 |
| persia | They aren't differentiated because of cloudiness, rather because of human-usable tooling. | 12:28 |
| jjardon | what do you mean? If Im using baserock to develop in a board, I will probably dont need ansible, nodejs or openstack | 12:30 |
| persia | Possibly, but you probably don't need any of those if you're developing an applicance to deploy to OpenStack either. | 12:31 |
| straycat | devel systems don't have openstack? | 12:31 |
| Kinnison | I think they have the openstack clients | 12:31 |
| SotK | they have openstack-clients don't they? | 12:31 |
| straycat | ahh true | 12:32 |
| paulsherwood | ssam2: i'd be interested in something for userspace containerisation that can be used on other oses, as well as linux if poss | 12:34 |
| jjardon | persia: ok, so what "devel" system means, then? Seems the description is too generic | 12:34 |
| persia | jjardon: 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 |
| paulsherwood | jjardon: it's historic... and the meaning has changed over time | 12:35 |
| paulsherwood | persia: +1 | 12:35 |
| persia | I 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 | |
| persia | paulsherwood: 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 |
| paulsherwood | persia: that would require a windowing system, surely? | 12:38 |
| Kinnison | And OS X | 12:38 |
| Kinnison | since textmate is an OS X editor | 12:38 |
| * paulsherwood is unsure if textmate is available for linux | 12:38 | |
| SotK | we had XFCE working in Baserock once upon a time right? | 12:38 |
| persia | paulsherwood: There are several examples of systems that have windowing systems | 12:38 |
| Kinnison | I think jjardon is maintaining a GNOME system | 12:39 |
| paulsherwood | SotK: yes, we did. | 12:39 |
| persia | Kinnison: One ought be able to handle that with MoL and binfmt | 12:39 |
| paulsherwood | jjardon: is that true? last time i checked i thoulght it was incomplete? | 12:39 |
| jjardon | Its not in a working state yet | 12:39 |
| Kinnison | persia: eww | 12:39 |
| persia | Kinnison: 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 do | 12:40 | |
| Kinnison | persia: MoL also seems unmaintained and ppc-only | 12:40 |
| paulsherwood | i think straycat was the last person to look, SotK | 12:40 |
| jjardon | unfortunatelly there are several things broken underneath that need to be fixed first | 12:41 |
| paulsherwood | for example? | 12:41 |
| * CTtpollard seems to remember tlsa looking at XFCE | 12:41 | |
| persia | Kinnison: Too bad. Seems the successor is Darling, but it doesn't have very complete support yet: I wonder if TextMate works. | 12:43 |
| tlsa | CTtpollard: 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 going | 12:44 |
| jjardon | paulsherwood: you have some of the identified issues in https://storyboard.baserock.org/#!/story/21 and https://storyboard.baserock.org/#!/story/5 | 12:44 |
| paulsherwood | jjardon: great, thank you | 12:45 |
| * SotK wonders if he has time to look at XFCE tonight | 12:45 | |
| tlsa | SotK: This is where I was working: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock/tlsa/fix-xfce | 12:46 |
| tlsa | the xfce system got broken by some X-->XWayland changes in other stratum | 12:47 |
| petefoth | If we have node.js, npm and development headers for GNOME Keyring in baserock, then we could have Atom (atom.io and https://github.com/atom/atom/blob/master/docs/build-instructions/linux.md) | 12:47 |
| jjardon | ssam2: btw, I get "Internal Server Error" when trying to log in storyboard, not sure is a known issue? | 12:48 |
| *** De|ta_ has joined #baserock | 12:48 | |
| ssam2 | great work storyboard! | 12:50 |
| ssam2 | not a known issue. | 12:51 |
| rdale | has samba been built for baserock? | 12:52 |
| ssam2 | jjardon: seems to be due to the openid migration http -> https | 12:52 |
| ssam2 | I did test and it seemed to work, but seems not | 12:52 |
| jjardon | can anyone log in storyboard, or Im the only one with problems? | 12:53 |
| Kinnison | I think ssam2 is still mid-fix for storyboard | 12:53 |
| Kinnison | for the https support on the openid | 12:53 |
| ssam2 | jjardon: should work again now | 12:54 |
| franred | jjardon,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 it | 12:54 |
| jjardon | ssam2: did you d any magic already? seems to work now | 12:54 |
| franred | for example | 12:54 |
| jjardon | oh, ok :) thanks! | 12:55 |
| ssam2 | jjardon: yes, I manually updated the users table in the database to change existing openids from http -> https | 12:55 |
| jjardon | franred: I still think the name and the descriptionof those systems can be improved | 12:56 |
| persia | +1 from me on improving the descriptions | 12:59 |
| franred | jjardon, Im not against improving descriptions, just give you some info about why there are some openstack bits in devel systems :) | 13:00 |
| franred | is https://gerrit.baserock.org/#/c/35/ ready to merge? | 13:00 |
| jjardon | Id do a patch but Im the one not sure what those systems are for :) | 13:00 |
| jjardon | franred: yeah, sure, thanks for that! | 13:01 |
| jjardon | franred: yes, but it's in a suspicious "Submitted, Merge Pending" status | 13:02 |
| ssam2 | I 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 |
| SotK | I'm guesssing the limbo is due to the "Related changes" section including unmerged stuff | 13:02 |
| SotK | given the "Parent" of that change is one of the related changes | 13:03 |
| ssam2 | ah, that makes sense | 13:03 |
| SotK | ISTR 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 dependencies | 13:03 |
| jjardon | ok, so seems its my fault: I probably sent the kernel patch from a branch that contains the glibc one | 13:06 |
| jjardon | at least we now know gerrit track the order of the commits correctly | 13:07 |
| *** ssam2 has quit IRC | 13:30 | |
| *** zoli__ has quit IRC | 13:33 | |
| straycat | richard_maw, race condition? | 13:41 |
| *** ssam2 has joined #baserock | 13:44 | |
| *** ChanServ sets mode: +v ssam2 | 13:44 | |
| richard_maw | straycat: it works by the gerrit-controlled repository on gerrit.baserock.org being merged with the version hosted on git.baserock.org, so if there's a change in-between gerrit fetching and gerrit pushing, then one side is going to lose | 13:44 |
| straycat | oh, i thought gerrit would lose and whoever merged would have to click rebase or something? | 13:45 |
| richard_maw | edcragg: I've reviewed your moonshot-deployment patches on gerrit | 13:45 |
| straycat | or, well, or i lose and i have to rebase | 13:45 |
| richard_maw | straycat: AIUI that would require gerrit to have direct access to the same repository as is running on git.baserock.org, which I don't think it does | 13:45 |
| straycat | it doesn't? :s | 13:46 |
| SotK | I 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.o | 13:47 |
| SotK | But I might be wrong | 13:47 |
| ssam2 | yes | 13:47 |
| SotK | :) | 13:47 |
| straycat | alright so we should still be able to merge straight into gbo if we want | 13:48 |
| ssam2 | force-push is disabled in the gerrit-replication plugin, to avoid losing any commits if people push stuff manually to git.basreock.org, but that means that it can stop working if different stuff gets merged to master of both repos at the same time | 13:48 |
| ssam2 | it'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 that | 13:49 |
| richard_maw | straycat: that requires that both git.baserock.org and gerrit.baserock.org have shared access to the same repository, which would require it to be shared with NFS | 13:49 |
| straycat | :s | 13:50 |
| richard_maw | straycat: either that, or the gerrit plugin becoming smart enough to feed information backwards that it couldn't merge a given commit | 13:50 |
| * richard_maw gets on with reviewing some patches | 13:51 | |
| straycat | i 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 code | 13:51 |
| ssam2 | the conflict would happen if commit A gets merged in gerrit in the same 2 minutes that commit B gets merged in git.baserock.org | 13:52 |
| ssam2 | doesn't matter on the content of either commit, because gerrit-replication is using 'git push' to push stuff to git.baserock.org, which will fail if it is a non-fastforward merge | 13:52 |
| straycat | won't gerrit just rebase and try again? | 13:52 |
| ssam2 | the gerrit-replication will not do that | 13:53 |
| ssam2 | which is sensible, when one is trying to do replication | 13:53 |
| straycat | okay, i'll push this to gerrit +2 it and merge then | 13:54 |
| ssam2 | if it already went through code review on the mailing list, it doesn't need to go through Gerrit as a proposed change | 13:54 |
| straycat | right | 13:55 |
| ssam2 | just push to 'ssh://you@gerrit.baserock.org/.. master' instead of 'ssh://git@git.baserock.org/.. master' | 13:55 |
| ssam2 | with appropriate Reviewed-By tags | 13:55 |
| ssam2 | ssh://you@gerrit.baserock.org:29418/ even | 13:56 |
| straycat | okay | 13:56 |
| bashrc_ | in gerrit is there a way of expressing that one change is dependent upon another? | 13:58 |
| straycat | yes | 13:58 |
| straycat | if you push a branch with a set of commits they become dependent on each other in commit order | 13:58 |
| bjdooks | is there a genric/generic-ish arm7l system available as a .tgz? | 13:58 |
| bashrc_ | ok | 13:59 |
| richard_maw | bjdooks: not that I'm aware of, but I think radiofree and jonathanmaw were working on armv7l recently | 14:00 |
| radiofree | bjdooks: i have a rootfs if tha'ts what you're after | 14:01 |
| radiofree | bjdooks: it's hf, that ok? | 14:01 |
| bjdooks | radiofree: yes. please, something i can extract onto a sd card | 14:01 |
| bjdooks | yes, armv7lhf should be fine | 14:01 |
| radiofree | ok, sent you a /msg | 14:03 |
| franred | ummm, https://gerrit.baserock.org/#/c/139/1/strata/x-common/util-keysyms.morph <-- I though morph care about the submodules. Why would we need to do a git submodule update here? | 14:19 |
| franred | jjardon, ^^ | 14:21 |
| pedroalvarez | franred: can you make those comments in the patch? | 14:21 |
| franred | sure | 14:21 |
| pedroalvarez | he is actually only moving the file to another place | 14:22 |
| jjardon | franred: we dont, thats what we have currently in definitions, I fix that in the next patches | 14:22 |
| edcragg | richard_maw, pedroalvarez, franred, jmacs, Kinnison: http://paste.baserock.org/gozegofubi | 14:27 |
| edcragg | not sure if that's because the LE rootfs we have is fairly old now, though | 14:27 |
| Kinnison | merp | 14:28 |
| richard_maw | edcragg: unfortunately "cannot compute suffix of object files: cannot compile" is one of the least useful error messages to get out of ./configure | 14:28 |
| Kinnison | last time I saw something like that it was a missing build-depend | 14:28 |
| Kinnison | or a failed ldconfig or something | 14:29 |
| * richard_maw assumed that we'd merged in all the changes for the ARMv8l64 BSP | 14:29 | |
| edcragg | it should be there, i'll have a closer look | 14:30 |
| *** wschaller_ has joined #baserock | 14:35 | |
| jjardon | franred: 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 patch | 14:36 |
| franred | jjardon, 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 noise | 14:38 |
| jjardon | franred: no worries :) | 14:41 |
| paulsherwood | Kinnison: last time you saw it, was in ybd i think :-) | 14:42 |
| paulsherwood | in other news, thanks to input from Kinnison, ybd can successfully build build-essential and core now :-) | 14:43 |
| radiofree | nice | 14:44 |
| Kinnison | paulsherwood: when are you going to have ybd clean up by default? | 14:45 |
| Kinnison | paulsherwood: I keep having to ^C and clean up | 14:45 |
| Kinnison | :( | 14:45 |
| paulsherwood | i'll raise an issue | 14:45 |
| straycat | richard_maw, you already merged it? >.> | 14:45 |
| jjardon | how should opinions be reviewed? For example, I think its better to add "morph info <chunk>" instead "morph get-chunk-details <chunk>" https://gerrit.baserock.org/#/c/130/ In these cases, should we set -1 or leave at 0? | 14:46 |
| paulsherwood | Kinnison: you could rmove the comment from https://github.com/devcurmudgeon/ybd/blob/master/assembly.py#L61 | 14:46 |
| richard_maw | straycat: merged what sorry? | 14:47 |
| straycat | % escapes | 14:47 |
| straycat | looks like someone did | 14:47 |
| richard_maw | it was not I | 14:47 |
| straycat | alright that's weird | 14:48 |
| straycat | if force pushes to master were allowed... | 14:49 |
| straycat | i don't know how that commit got ther but it's the wrong one | 14:51 |
| Kinnison | force-pushing master makes me a sad bunny | 14:52 |
| straycat | in this case it would be useful | 14:52 |
| Kinnison | But it'd also bugger anyone up who had based off master in the meantime | 14:52 |
| * pedroalvarez suggests revert | 14:52 | |
| Kinnison | Just submit a reversion of the bad patch and a merge of the correct one | 14:52 |
| straycat | yes all of one commit that's about to me merged in by gerrit with a much more meaningful message | 14:52 |
| Kinnison | Remember, anything that hits master of git.baserock.org we have to assume has *already* been mirrored to all our users by the time we notice | 14:53 |
| ssam2 | jjardon: doing design discussion in patch reviews isn't really the right thing | 14:53 |
| jjardon | ssam2: sure, what should I do then? | 14:54 |
| ssam2 | cry | 14:54 |
| jjardon | haha | 14:54 |
| ssam2 | in seriousness, I don't know. Collaborative design without any kind of leadership or specification is pretty difficult | 14:55 |
| straycat | Kinnison, the commit is identical | 14:56 |
| ssam2 | but 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 review | 14:56 |
| ssam2 | or discussing it on the list | 14:56 |
| ssam2 | the list is probably the best place to do design discussion really | 14:56 |
| Kinnison | straycat: identical? | 14:57 |
| Kinnison | straycat: If it's identical then it's the same commit and so there's no issue | 14:57 |
| straycat | same content different commit message | 14:57 |
| Kinnison | then it's not identical | 14:57 |
| Kinnison | different message == different commit | 14:57 |
| straycat | sure | 14:57 |
| straycat | oh shrug whatever, it's just a commit msg i don't even care | 14:58 |
| jjardon | ssam2: not sure if change the option from "get-chunk-info" to "info" is only cosmetic, but ok. I will leave it as a comment | 14:58 |
| ssam2 | I mean 'cosmetic' in that it's a design thing, rather than a code thing | 14:59 |
| ssam2 | so it's much harder to have an objective opinion about it | 14:59 |
| jjardon | yep | 15:00 |
| straycat | i pushed the wrong thing to gerrit it seems | 15:00 |
| radiofree | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?id=a76aef3fea1d24d5e5b0fd2dfd9f768151c25f82 this breaks qtwebkit | 15:01 |
| * jjardon doesnt have idea why he gets a merge conflict in the xcb_0.4.0 series | 15:01 | |
| jjardon | radiofree: in what way? | 15:01 |
| Kinnison | straycat: Unless it has rude words or leaks secrets, I wouldn't worry about it and just move on :) | 15:02 |
| radiofree | jjardon: in this way https://bugreports.qt.io/browse/QTBUG-44714 | 15:02 |
| jjardon | seems there is already a patch available https://codereview.qt-project.org/#/c/107411/ | 15:03 |
| jjardon | maybe you can cherry-pick it? | 15:03 |
| radiofree | jjardon: that's in 5.4 dev branch, and not in 5.4.1, also we're using 5.5 | 15:03 |
| radiofree | would patches to add qt5 to the weston system be accepted? | 15:03 |
| jjardon | I think its a good idea | 15:04 |
| jjardon | if its not in the ci, its not really supported and we will have this problem again and again | 15:05 |
| radiofree | ok, 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 |
| jjardon | Id prefer to fix qtwebkit, but yes if the solution doesnt exist or its hard to implement | 15:07 |
| radiofree | there's no release version of qtwebkit that currently has the fix | 15:07 |
| jjardon | radiofree: I think in the bug report there is a patch for 5.5 btw | 15:07 |
| radiofree | the next 5.4 release will have it | 15:07 |
| radiofree | jjardon: yes i know, but at the moment qtwebkit 5.4.1 will be broken (probably), so can we revert that patch? | 15:08 |
| radiofree | i'm assuming it doesn't actually give us anything other than being the latest version? | 15:09 |
| *** zoli__ has joined #baserock | 15:09 | |
| radiofree | or does gtk3 need it? | 15:09 |
| jjardon | radiofree: 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 reversion | 15:12 |
| radiofree | in the interests of sanity we're going with a patched 5.5 branch, but qtwebkit in master is now broken, so don't use that | 15:16 |
| radiofree | i'll test to see if HEAD of 5.4 works with 5.4.1 tonight | 15:18 |
| * straycat pushes https://gerrit.baserock.org/151 | 15:18 | |
| radiofree | i probably ask this every week, but how much RAM does mason-x86-64 have? | 15:19 |
| persia | So, 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 |
| ssam2 | radiofree: 2GB RAM, 2CPUs | 15:35 |
| * radiofree won't remove max-jobs from WebKit then | 15:38 | |
| jjardon | persia: I think everyone agree on that | 15:41 |
| edcragg | richard_maw, pedroalvarez, franred, jmacs, Kinnison, fay_, a1exhughe5: 2015-03-30 15:49:31 [Build 21/411] [gcc] | 15:51 |
| pedroalvarez | edcragg: progress! | 15:51 |
| Kinnison | edcragg: \o/ | 15:52 |
| a1exhughe5 | :) | 15:52 |
| *** a1exhughe5 has quit IRC | 16:00 | |
| *** zoli__ has quit IRC | 16:04 | |
| *** jonathanmaw has quit IRC | 16:04 | |
| *** ssam2 has quit IRC | 16:09 | |
| paulsherwood | edcragg: please could you post some of the Elapsed time lines from your builds on that box somewhere? | 16:09 |
| paulsherwood | eg wiki.baserock.org/build-times :-) | 16:09 |
| * paulsherwood is particularly interested in the gcc time - it's a good indicator | 16:11 | |
| *** ssam2 has joined #baserock | 16:13 | |
| *** ChanServ sets mode: +v ssam2 | 16:13 | |
| *** zoli__ has joined #baserock | 16:18 | |
| *** ssam2 has quit IRC | 16:24 | |
| *** zoli__ has quit IRC | 16:25 | |
| *** ssam2 has joined #baserock | 16:30 | |
| *** ChanServ sets mode: +v ssam2 | 16:30 | |
| *** gary_perkins has quit IRC | 16:39 | |
| *** zoli__ has joined #baserock | 16:44 | |
| *** Krin has quit IRC | 16:48 | |
| *** Krin has joined #baserock | 16:51 | |
| *** Guest84558 has quit IRC | 16:57 | |
| *** bashrc_ has quit IRC | 17:00 | |
| *** ssam2 has quit IRC | 17:01 | |
| *** mdizzle has quit IRC | 17:03 | |
| *** CTtpollard has quit IRC | 17:07 | |
| *** ssam2 has joined #baserock | 17:14 | |
| *** ChanServ sets mode: +v ssam2 | 17:14 | |
| *** ssam2 has quit IRC | 17:17 | |
| *** wschaller_ has quit IRC | 17:22 | |
| *** edcragg has quit IRC | 17:27 | |
| *** Albert has quit IRC | 17:35 | |
| jjardon | radiofree: It would be great if you can review https://gerrit.baserock.org/#/c/152/ (seems to solve the problem here) | 17:37 |
| *** Albert has joined #baserock | 17:42 | |
| *** tiagogomes_ has quit IRC | 17:45 | |
| *** rdale has quit IRC | 17:49 | |
| *** mdunford has quit IRC | 17:53 | |
| jjardon | (btw, qt5-devel system seems to be broken at the moment) (fribidi and eval doesnt compile) | 19:08 |
| *** zoli__ has quit IRC | 19:21 | |
| SotK | mason is failing again :( | 19:28 |
| straycat | okay gerrit you added vim style visual selection | 19:30 |
| straycat | that is nice | 19:30 |
| straycat | ahh and vim style line navigation | 19:33 |
| straycat | ok i might not hate this | 19:35 |
| * straycat forgets what +1/-1 etc mean in this new system | 19:52 | |
| * SotK reads it as +1 == +1, -1 == -0, 0 == +0 | 19:53 | |
| straycat | so to veto i say -2 | 19:53 |
| SotK | yeah | 19:53 |
| straycat | okay | 19:53 |
| *** zoli__ has joined #baserock | 19:55 | |
| straycat | SotK, 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 image | 20:20 | |
| straycat | i think it's a bit weird that we don't | 20:20 |
| straycat | given it's the system most of us use | 20:21 |
| persia | SotK: What made it take so long? We should make that quick. | 20:27 |
| SotK | persia: I was upgrading a really old devel vm and had to redownload every artifact | 20:33 |
| SotK | as my cache was very outdated (November last year I think) | 20:34 |
| persia | Makes sense. Why would a larger image be faster? Just TCP windows, or something else? | 20:34 |
| *** zoli__ has quit IRC | 20:34 | |
| *** zoli__ has joined #baserock | 20:34 | |
| SotK | I 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 :3 | 20:35 |
| *** zoli__ has joined #baserock | 20:35 | |
| persia | Ugh. That's annoying. | 20:36 |
| SotK | persia: 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 upgrade | 20:37 |
| persia | I 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 |
| SotK | I think so too | 20:38 |
| SotK | actually, maybe I could have just done `morph upgrade` if the system artifact was in the remote cache | 20:39 |
| persia | So 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 |
| SotK | yeah, if it was quick I wouldn't mind the lack of a devel image, it works as a nice tutorial for upgrading I think | 20:42 |
| SotK | its just annoying that said tutorial takes ages | 20:43 |
| * SotK rebases tlsa's XFCE work and starts building | 20:43 | |
| persia | Any 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 dependencies | 21:30 | |
| *** Albert has quit IRC | 21:48 | |
| SotK | 2015-03-30 22:59:38 [Build 348/348] [xfce-system] system xfce-system-rootfs is cached | 23:03 |
| SotK | :D | 23:03 |
| rjek | \o/ | 23:11 |
| rjek | SotK: Now Cinnamon and MATE :) | 23:11 |
| SotK | I don't know if it works yet! | 23:12 |
| rjek | :) | 23:12 |
| SotK | It doesn't work :( | 23:22 |
| SotK | Ah well, it builds now at least | 23:22 |
| * SotK goes to bed and hopes the French doors don't blow open again | 23:22 | |
| jjardon | SotK: if you out the issues you found in the storyboard maybe we can work together in some of them | 23:26 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!