« Previous day | Index | Today | Next day » Channels | Search | Join
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 01:42 | dirakx <dirakx!rafael 190.156.123.164> has joined #dextrose |
|
| 03:03 | tch <tch!~tch@r190-132-206-32.dialup.mobile.ancel.net.uy> has joined #dextrose | |
| 04:38 | m_anish is now known as m_anish_afk | |
| 11:47 | alsroot_away is now known as alsroot | |
| 12:28 | alsroot has quit IRC | |
| 13:56 | dfarning is now known as dfarning_afk | |
| 14:25 | dirakx has quit IRC | |
| 15:07 | tch has quit IRC | |
| 15:15 | alsroot_away <alsroot_away!~alsroot94.137.229.183> has joined #dextrose |
|
| 15:15 | alsroot_away has quit IRC | |
| 15:15 | alsroot_away <alsroot_away!~alsrootpdpc/supporter/active/antilopa-gnu> has joined #dextrose |
|
| 15:29 | tch <tch!~tch@r190-132-217-135.dialup.mobile.ancel.net.uy> has joined #dextrose | |
| 15:45 | dirakx <dirakx!~rafael190.27.230.221> has joined #dextrose |
|
| 15:50 | dirakx has quit IRC | |
| 15:55 | alsroot_away has quit IRC | |
| 16:07 | m_anish_afk is now known as m_anish | |
| 16:08 | alsroot_away <alsroot_away!~alsroot94.137.229.183> has joined #dextrose |
|
| 16:08 | alsroot_away has quit IRC | |
| 16:08 | alsroot_away <alsroot_away!~alsrootpdpc/supporter/active/antilopa-gnu> has joined #dextrose |
|
| 16:26 | dfarning_afk is now known as dfarning | |
| 16:52 | alsroot_away has quit IRC | |
| 17:10 | m_anish is now known as m_anish_afk | |
| 17:15 | alsroot_away <alsroot_away!~alsroot94.137.229.183> has joined #dextrose |
|
| 17:15 | alsroot_away has quit IRC | |
| 17:15 | alsroot_away <alsroot_away!~alsrootpdpc/supporter/active/antilopa-gnu> has joined #dextrose |
|
| 17:16 | dfarning is now known as dfarning_afk | |
| 17:32 | dfarning_afk is now known as dfarning | |
| 17:38 | dfarning is now known as dfarning_afk | |
| 17:40 | dirakx <dirakx!~rafael190.27.230.221> has joined #dextrose |
|
| 18:38 | alsroot_away has quit IRC | |
| 18:39 | silbe <silbe!~silbe2001:6f8:120a::2> has joined #dextrose |
|
| 18:42 | alsroot_away <alsroot_away!~alsroot94.137.229.183> has joined #dextrose |
|
| 18:42 | alsroot_away has quit IRC | |
| 18:42 | alsroot_away <alsroot_away!~alsrootpdpc/supporter/active/antilopa-gnu> has joined #dextrose |
|
| 18:48 | alsroot_away has quit IRC | |
| 18:50 | SMParrish | silbe: thanks for the updated patch sets. |
| 18:50 | alsroot_away <alsroot_away!~alsroot94.137.229.183> has joined #dextrose |
|
| 18:50 | alsroot_away has quit IRC | |
| 18:50 | alsroot_away <alsroot_away!~alsrootpdpc/supporter/active/antilopa-gnu> has joined #dextrose |
|
| 18:52 | SMParrish | silbe: I actaully have a build using it but it wont boot atm |
| 18:53 | silbe | SMParrish: Tell me if you're ready for a new patch set; I've added another bug fix (for Shutdown/Restart). |
| 18:54 | SMParrish | You can go on and post it, will download it once I get this one working. The system will boot fine with a stock 0.90.3 but fails with our patchset |
| 18:54 | silbe | oh, ok. can you get me logs? |
| 18:54 | SMParrish | silbe: since it wont boot nope :) |
| 18:55 | alsroot_away has quit IRC | |
| 18:55 | SMParrish | silbe: fails right after starting crond, getting dcon_freeze messages |
| 18:58 | silbe | strange, why would a change in Sugar cause that? |
| 18:59 | SMParrish | silbe: I thought so as well, but that is the only difference |
| 18:59 | silbe | SMParrish: transient error? something else failed during the build process? |
| 19:00 | SMParrish | silbe: I thought about that so killed that build and did another one same result |
| 19:00 | silbe | I'd offer to install my serial cable again and test the image, but I just installed the XS on my spare SD card... |
| 19:01 | SMParrish | silbe: np will keep trying and maybe get bernie to install it |
| 19:02 | silbe | ok |
| 19:04 | tch has quit IRC | |
| 19:06 | silbe | netconsole might do the trick if the kernel supports network configuration (usually used for "diskless" machines with root on NFS) |
| 19:07 | or if you have a spare USB<->serial converter you could use that... | |
| 19:09 | SMParrish | silbe: done have one :( |
| 19:11 | silbe | SMParrish: where are you physically located? |
| 19:11 | (country) | |
| 19:12 | bernie | silbe, SMParrish: since we have so many patches, it may help to use the same trick used by ajax on the xserver package |
| 19:13 | SMParrish | silbe: US |
| 19:13 | silbe | bernie: it's an interesting trick, though I'm not sure what it would gain us. I already have all the patches in git and just export them using format-patch. |
| 19:13 | SMParrish | bernie: what that? Add patches 1 by 1 to find the problem one :) |
| 19:14 | bernie | silbe: it makes applying the patches easier, because "git am" is better than "patch" at handling rejects, etc. |
| 19:14 | SMParrish: this is what the .spec of xorg does (i omitted some unnecessary clutter): | |
| 19:15 | in %setup: | |
| 19:15 | 1) unpack the tarball (which may also contain a .git dir if it's a snapshot) | |
| 19:15 | 2) git am -p1 %{patches} | |
| 19:16 | SMParrish: if you're woerking with a release tarball, you have to do: | |
| 19:16 | 1.1) git init | |
| 19:16 | 1.2) git add . | |
| 19:16 | 1.3) git ci -m "baseline" | |
| 19:17 | now it may sound like i'm contradicting myself, but i'm not. this usage of git is different from creating a public git branch with patches already slammed into it | |
| 19:17 | SMParrish: anyway, it's just a time saver trick. it doesn't make the package better or worse. | |
| 19:18 | SMParrish | bernie: Instead of applying the patches thru rpm and spec file I just spun a new tarball with the patches already applied |
| 19:19 | silbe | bernie: saving time in what way? |
| 19:20 | bernie: i.e. what's the advantage over "for patch in "$PATCHDIR"/*.patch ; do patch -p1 -s < "$patch" ; done" ? | |
| 19:26 | bernie | SMParrish: no, this is definitely not something we want to do |
| 19:26 | SMParrish: this way we loose track of which patches we've applied | |
| 19:27 | SMParrish: it's necessary to keep the patches separate from the baseline so we can add/remove/change any of them easily while we stabilize dextrose3... and port them over to dextrose4 one day. | |
| 19:27 | silbe: git am is smarter than patch. especially if you start from a common ancestor | |
| 19:33 | silbe | bernie: sure, but there's no need for smartness. We're patching a working copy snapshot with all patches from git. They all apply perfectly clean. The result should always be the same. So I don't see what advantage there is. |
| 19:34 | SMParrish | bernie: Its not long term just for me atm so I can try and get a prototype dx3 spun up |
| 19:34 | silbe | bernie: please note that I'm not in the least arguing against using that snippet. I just don't see an advantage. :) |
| 19:34 | bernie | silbe: after this initial rebase, will people continue to go through your tree to get patches in the dextrose 3 rpms? |
| 19:35 | SMParrish: ok, but please don't publish rpms based on hacked tarballs | |
| 19:35 | m_anish_afk is now known as m_anish | |
| 19:36 | SMParrish | bernie: these rpms would be of no use to anyone else |
| 19:36 | bernie | silbe: at some point we'll start to have many people merging their patches and things will get more complicated. we can't share your git repo because it requires frequent rebases, so sharing the patch queue (like all fedora packages do) seems like the only natural way to work |
| 19:37 | silbe | bernie: I'm releasing a new patch set (to be applied in entirety and in order) whenever there's a change. |
| 19:38 | bernie: development should happen against mainline master, not Dextrose (unless required because it depends on not-yet-upstreamed functionality). I'll take care of the rebasing against Dextrose. | |
| 19:39 | bernie | silbe: ah so the workflow will be that people will submit patches through you? i'm fine with it, but we have to be clear about it because it differs from what we're currently doing |
| 19:39 | silbe | bernie: yes, that's the plan for DX-3. |
| 19:40 | bernie | silbe: i like benevolent dictator models, actually... i'm just a little worried because the same person who maintains the patch set doesn't also create the packages and the builds. |
| 19:41 | silbe: i'm afraid we might work like: | |
| 19:41 | SMParrish | bernie: that should not be a problem |
| 19:41 | bernie | tch: "here's a patch" |
| 19:41 | silbe: "berged!" | |
| 19:41 | SMParrish: "build made!" | |
| 19:41 | tester: "fuck, sugar does not start any more :-(" | |
| 19:41 | let's start over... | |
| 19:42 | SMParrish: it's not a problem if each one of us is able to test things in a realistic environment (i.e.: on a true XO-1) | |
| 19:42 | silbe | bernie: good summary of today :-P ;) |
| 19:42 | SMParrish | bernie: builds wont get released until theyy are tested locally and if there are problems silbe is just an IRC or email away |
| 19:42 | bernie | SMParrish: hence, each one of us need to be able to build at least the rpms (if not entire images) |
| 19:43 | SMParrish: ok, this skips one step, but it still makes me nervous that there are 3 people between the code and the test. | |
| 19:43 | silbe | bernie: do all testers have large enough SD cards? If so, they can use sugar-jhbuild for testing, like I do. |
| 19:43 | bernie: or build rpms locally, just adding their patch as a last step. | |
| 19:44 | bernie | SMParrish: the easy bugs (like "oh, I forgot to include the icon!") are a majority and need to be caught early in the cylcle |
| 19:44 | silbe: sd cards? we can simply reflash the laptops | |
| 19:44 | silbe: i tried sd cards in the past, they're all a lot slower than the internal flash (for some reason) | |
| 19:45 | silbe | bernie: are the 4GB internal SD cards (assuming XO-1.5) large enough for all dependencies? |
| 19:45 | bernie | silbe: yes, normally the image takes less than 1GB unpacked. |
| 19:45 | silbe | (I'm using a 16GB card; a 8GB might suffice, but 4GB is going to get interesting) |
| 19:45 | bernie | (a little more than 1GB with gnome) |
| 19:46 | silbe: i mean, you COULD use an sdcard, but it's an extra step. flashing takes 4-5 minutes and is easier to do for all the developers, le'ts not introduce more complexity for them | |
| 19:47 | silbe: can you build sdcard images yourself? | |
| 19:47 | silbe: or flash images? | |
| 19:49 | silbe | bernie: yes, I did (after applying the patch I posted/pushed). Worked surprisingly well. |
| 19:51 | bernie | silbe: ok cool |
| 19:51 | SMParrish, silbe: so, to summarize my stance on this: | |
| 19:52 | While it's ok for people in a project to organize in such a way that responsibilities are well defined, this works well only when roles are horizontal. It's not ok to create a pipeline in which you need 7 people to get anything done... then you have to wait a week (when you're lucky) to see the result of any change. if we become this clumsy, we can't meet deadlines and deliver a quality product. | |
| 19:52 | (is "stance" the right word in this context?) | |
| 19:53 | Each person should ideally be independent. people need to go through linus for the kernel and through silbe for dextrose... but each kernel developer can build a kernel and run it on their personal machine. | |
| 19:54 | easy builds are the key of any successful project. we must make sure that anyone, including anish, tch and silbe can create a build quickly when they need to | |
| 19:54 | SMParrish | bernie: anyone should be able to do the builds. Everything for the buildsystem in in git and available |
| 19:55 | bernie | SMParrish: ok |
| 19:56 | good :) | |
| 19:56 | SMParrish | bernie: and I would encourage people to do them for testing, etc, Official builds will come from me |
| 19:56 | bernie: I already have a working dx3 buildsystem and its on git.sugarlabs.org under Dextrose3 | |
| 19:58 | bernie | SMParrish: ok (though I'm not sure whether it would have been best to make a new repository in dextrose rather than an entirely new project in gitorious) |
| 19:59 | SMParrish: did you try to rebase olpc-os-builder with the latest changes from dsd? | |
| 19:59 | SMParrish | bernie: my feeling was it a totally new project, and both will be worked on for the forseeable future. Better to keep them seperate |
| 20:00 | bernie: thats what dx3 is, dsd's new builder with out buildsystem modifications ported over | |
| 20:00 | bernie | SMParrish: oh i see.. it's not a continuation of dx2... it's based on top of olpc-os-builder |
| 20:01 | SMParrish | bernie: right based on his f14&0.90 system |
| 20:01 | bernie | SMParrish: dx2 is *also* based on olpc-os-builder, just on an earlier release (from which i merged new changes a few times) |
| 20:02 | SMParrish | bernie: I know, this is just based on his new one |
| 20:03 | bernie | SMParrish: his f14-0.90 system is just a newer revision of the f11-0.84 one... it's possible (and probably easy) to perform a merge on top of dextrose... but i don't feel terribly one way or another. whichever seems easier for you. |
| 20:03 | SMParrish: (as long as you don't use any of the customizations of dextrose 2, of course) | |
| 20:04 | SMParrish | bernie: Easier for me to keep them seperate atm |
| 20:06 | bernie | SMParrish: there's something odd in this patch: http://cgit.sugarlabs.org/dext[…]62a3eeba1139e0e6c |
| 20:06 | SMParrish: it seems backwards | |
| 20:06 | SMParrish: it seems to REMOVE the dextrose2 customizations from dextrose3 | |
| 20:07 | SMParrish: how did you generate the dextrose2 diffs on olpc-os-builder? i could send you a patch since i have both remotes in my repo | |
| 20:10 | SMParrish | bernie: that removes a few things that dont work on f14, things get added back in with later commits. I just did a diff on the modules directory of each system |
| 20:18 | silbe: looks like the machine is booting Sugar just fails to start | |
| 20:21 | dfarning_afk is now known as dfarning | |
| 20:28 | SMParrish | bernie: btw because dx3 will use ubifs it wont build on f13, going to have to either upgrade dextrose(the vm) to f14 or else make an f14 vm |
| 20:29 | bernie | SMParrish: i'm ok with upgrading... f14 can build dextrose2 all right |
| 20:29 | SMParrish: can you do that? | |
| 20:29 | SMParrish | bernie: sure I can do it |
| 20:30 | bernie | SMParrish: actually, perhaps we don't have to: jita is already f14. you can use that |
| 20:31 | SMParrish | bernie: that will work |
| 20:31 | bernie | SMParrish: just maybe do "time nice ionice -c2 -n6 sudo ./olpc-os-builder examples/dextrose3.ini |
| 20:32 | SMParrish: when you confirm that it works well on jita, perhaps we could destroy the dextrose vm. one less thing to take care of for me | |
| 20:32 | s/me/us/ :-) | |
| 20:33 | m_anish is now known as m_anish_afk | |
| 20:35 | SMParrish | bernie: I'll let you know |
| 21:10 | dirakx has quit IRC | |
| 21:33 | silbe | bernie: +3 on having us not block on each other for most day-to-day tasks, including trying out builds. |
| 21:36 | bernie: having the build process generate output usable for SD cards already helps a lot. Maybe we can add one or two small scripts that automates a bit more (1. first preparation incl. partitioning and 2. update of an existing card, leaving /home intact). | |
| 21:39 | bernie: doesn't jabber.sl.o run on jita? I'm not sure we should add even more variables like build processes to ejabberd and Collaboration debugging... | |
| 21:40 | SMParrish: then you should be able to log in on a VT and snatch the log files. | |
| 21:42 | bernie | silbe: i just figured out that once you use SD cards you can quickly rsync a new build on top of an old one... thus saving a huge amount of time! |
| 21:42 | silbe | bernie: yep :) |
| 21:43 | bernie | silbe: jita and the dextrose vm run on the same hardware anyway. they affect each other in ways that the linux scheduler currently cannot mitigate |
| 21:43 | silbe: if they were runnin on the same kernel, we could nice and ionice the builds | |
| 21:43 | silbe | bernie: does the build process leave the entire fs tree intact somewhere we could rsync from? |
| 21:44 | bernie | silbe: it creates the fs inside a loopback mounted ext3 image (or jffs2/ubifs image) |
| 21:44 | silbe | bernie: at least they'd be a bit more isolated in terms of CPU usage |
| 21:44 | bernie | silbe: so it's probably better to unpack the targz |
| 21:44 | silbe | bernie: ok, so the script would just need to loop mount the image again. |
| 21:44 | bernie | silbe: they're LESS isolated if they run in two kvm |
| 21:45 | silbe: the linux kernel has a scheduling unit called a process. if you have 10 processes for ejabberd and 1 for the builder, you can finetune them as you wish. if the former run in one VM and the latter in another VM, they fight for CPU time and there's nothing you can (currently) do to mitigate the issue | |
| 21:46 | silbe | bernie: except tune the process for the entire VM |
| 21:46 | bernie | silbe: libvirt would use cgroups to prioritize VMs, but it's broken in lucid currently |
| 21:46 | silbe: it makes the host kernel crash | |
| 21:47 | silbe: plus, it's broken in libvirt (no interface to configure it) | |
| 21:47 | silbe | that's a shame. I was about to suggest using cgroups (but didn't because I wasn't sure it'd help in case of single-process cgroups) |
| 21:47 | so definitely a kernel bug :-/ | |
| 21:47 | bernie | silbe: so, having everything in the same VM results in better resource control |
| 21:48 | silbe | ok. that reminds me of plan B: WMF servers. |
| 21:48 | bernie | silbe: it's both a kernel bug (the crash) and libvirt immaturity (obscure feature that is documented only in a blogpost) |
| 21:49 | silbe | bernie: libvirtd can be worked around, but not the kernel |
| 21:49 | bernie | silbe: if we have to take out those junk servers, we could as well purchase a machine 10x faster than the current treehouse. i have the funds. |
| 21:49 | silbe: but first let's see if we have any problem. i don't think we do. | |
| 21:52 | silbe | bernie: I'm rather uncomfortable having potentially IO bound loads on the same host as high-priority (or at least higher priority than builders) services. sks on lightwave has shown me Linux doesn't cope well with that (especially when mixing them inside a single VM). |
| 21:53 | bernie: but I'll just wait 'till the first crash :D | |
| 21:53 | bernie | silbe: me too, but we don't have two physical boxes |
| 21:54 | silbe: we don't run so many builds, it's not like a buildbot | |
| 21:54 | silbe | bernie: that's why I wanted to put the WMF boxes to some actual use. Right now they seem to be just collecting dust (and maybe annoying an AC). |
| 21:55 | bernie: I was going to move the build slaves from bender over. | |
| 21:57 | bernie | silbe: they are mostly junk |
| 21:57 | silbe: good rack space is hard to find. if we had 3U of space, i'd immediately buy and install a real server | |
| 21:58 | silbe: dogi wants to purchase faster processors for treehouse and housetree. | |
| 21:59 | silbe | bernie: would it make a significant difference? Usually memory is the bottleneck... |
| 21:59 | bernie | silbe: i'm not sure it's a good use of our time, but i'm not opposed. |
| 21:59 | silbe: amount of memory? no, we have plenty of unused memory. cpu is saturating during the day | |
| 21:59 | silbe: treehouse and housetree have 64GB of ram | |
| 21:59 | silbe | bernie: it'd probably be mostly his time, so I wouldn't be opposed. |
| 22:00 | bernie: I'm talking about memory bandwidth, not amount of memory. | |
| 22:01 | I'd be more happy to say yes to a processor with more cache than one with a higher clock frequency. | |
| 22:02 | and/or more cores - I suppose context switches on one core don't affect the cache shared between all cores (L2 or L3)? | |
| 22:48 | silbe has quit IRC | |
| 22:49 | SMParrish | bernie: ping here are the logs from dx3 that wont boot into sugar, see if you can find something I am missing http://tuxbrewr.fedorapeople.org/log/ |
« Previous day | Index | Today | Next day » Channels | Search | Join