Web   ·   Wiki   ·   Activities   ·   Blog   ·   Lists   ·   Chat   ·   Meeting   ·   Bugs   ·   Git   ·   Translate   ·   Archive   ·   People   ·   Donate

#dextrose, 2011-01-21

 « Previous day | Index | Today | Next day »     Channels | Search | Join

All times shown according to UTC.

Time Nick Message
01:42 dirakx <dirakx!rafael@> 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!~alsroot@> has joined #dextrose
15:15 alsroot_away has quit IRC
15:15 alsroot_away <alsroot_away!~alsroot@pdpc/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!~rafael@> 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!~alsroot@> has joined #dextrose
16:08 alsroot_away has quit IRC
16:08 alsroot_away <alsroot_away!~alsroot@pdpc/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!~alsroot@> has joined #dextrose
17:15 alsroot_away has quit IRC
17:15 alsroot_away <alsroot_away!~alsroot@pdpc/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!~rafael@> has joined #dextrose
18:38 alsroot_away has quit IRC
18:39 silbe <silbe!~silbe@2001:6f8:120a::2> has joined #dextrose
18:42 alsroot_away <alsroot_away!~alsroot@> has joined #dextrose
18:42 alsroot_away has quit IRC
18:42 alsroot_away <alsroot_away!~alsroot@pdpc/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!~alsroot@> has joined #dextrose
18:50 alsroot_away has quit IRC
18:50 alsroot_away <alsroot_away!~alsroot@pdpc/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

Powered by ilbot/Modified.