Re: XO BW mode (was Re: Guidance sought on collaboration techniques)
On 13.02.2009, at 19:27, Gary C Martin wrote: Note the backlight goes through the colour refractive screen magic, even in BW mode, so it's not as sharp as with the backlight 100% off That explanation is horrendously wrong. Please do not perpetuate the rumor of modes in the display hardware. There are none. And, there is no refractive screen magic, that idea did not make it into production. The backlight uses regular r/g/b color filters. The blur you see in color mode is the DCON performing anti-aliasing by adding color components from the four neighboring pixels into each pixel (e.g., for a red pixel it takes the red components of the surrounding pixels into account, etc). In early DCON drivers it was possible to toggle the anti-aliasing independently of the backlight intensity, so you could clearly see its effect. IIUC this capability has now been coupled to the backlight intensity, which is fine in regular use, but takes away the possibility to easily demonstrate what's happening. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO BW mode (was Re: Guidance sought on collaboration techniques)
On 14 Feb 2009, at 10:16, Bert Freudenberg wrote: On 13.02.2009, at 19:27, Gary C Martin wrote: Note the backlight goes through the colour refractive screen magic, even in BW mode, so it's not as sharp as with the backlight 100% off That explanation is horrendously wrong. Please do not perpetuate the rumor of modes in the display hardware. There are none. Horrendously wrong? Wow... well Bert you've been with the project for way longer than me so I do trust you to be right, I must have hit a nerve, sorry. And, there is no refractive screen magic, that idea did not make it into production. The backlight uses regular r/g/b color filters. Was my 'refractive' faux pas your only reason for using 'horrendously wrong'? I guess the term I should have given there was 'transflective', apologies to optical geeks everywhere. I couldn't see any obvious errors else where. The blur you see in color mode is the DCON performing anti-aliasing by adding color components from the four neighboring pixels into each pixel (e.g., for a red pixel it takes the red components of the surrounding pixels into account, etc). In early DCON drivers it was possible to toggle the anti-aliasing independently of the backlight intensity, so you could clearly see its effect. IIUC this capability has now been coupled to the backlight intensity, which is fine in regular use, but takes away the possibility to easily demonstrate what's happening. You do appear to be wrong here. Have access to three XOs here (two MP and one B4) that all happily respond to the below command: su echo 1 /sys/devices/platform/dcon/output Disables colour while leaving the backlight setting alone, allowing a slightly crisper BW display with backlight on if you want it (close look at text edges reminds me of the little colour pixels you get with sub-pixel resolution tricks on conventional screens), and: su echo 0 /sys/devices/platform/dcon/output Enables colour while leaving the backlight setting alone, allowing a 'colour display' mode when the backlight is potentially off (not a very useful combination as it's the backlight that goes through the colour layer so you're left looking at a slightly soft BW image from just reflected light). I can try and take some pixel macro photos of the effect if it makes you feel better? :-) http://wiki.laptop.org/go/Display#DCON_screen_driver_chip --Gary - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO BW mode (was Re: Guidance sought on collaboration techniques)
On 14.02.2009, at 17:24, Gary C Martin wrote: On 14 Feb 2009, at 10:16, Bert Freudenberg wrote: On 13.02.2009, at 19:27, Gary C Martin wrote: Note the backlight goes through the colour refractive screen magic, even in BW mode, so it's not as sharp as with the backlight 100% off That explanation is horrendously wrong. Please do not perpetuate the rumor of modes in the display hardware. There are none. Horrendously wrong? Wow... well Bert you've been with the project for way longer than me so I do trust you to be right, I must have hit a nerve, sorry. And, there is no refractive screen magic, that idea did not make it into production. The backlight uses regular r/g/b color filters. Was my 'refractive' faux pas your only reason for using 'horrendously wrong'? I guess the term I should have given there was 'transflective', apologies to optical geeks everywhere. I couldn't see any obvious errors else where. You attributed the decrease in sharpness to some colour refractive screen magic. There is no magic and it got nothing to do with the screen at all. The blur you see in color mode is the DCON performing anti-aliasing by adding color components from the four neighboring pixels into each pixel (e.g., for a red pixel it takes the red components of the surrounding pixels into account, etc). In early DCON drivers it was possible to toggle the anti-aliasing independently of the backlight intensity, so you could clearly see its effect. IIUC this capability has now been coupled to the backlight intensity, which is fine in regular use, but takes away the possibility to easily demonstrate what's happening. You do appear to be wrong here. I'd be glad to be wrong, but that's not the flag I meant. That one did not disable color, but only the anti-aliasing. That is, you could see colors, but it was crisp (leading to colored fringes so that's why the setting is not available independently anymore). The fact that you can't change the AA independently of the color-to-grayscale conversion makes it appear as if the two were intrinsically coupled. Have access to three XOs here (two MP and one B4) that all happily respond to the below command: su echo 1 /sys/devices/platform/dcon/output Disables colour while leaving the backlight setting alone, allowing a slightly crisper BW display with backlight on if you want it (close look at text edges reminds me of the little colour pixels you get with sub-pixel resolution tricks on conventional screens), and: su echo 0 /sys/devices/platform/dcon/output Enables colour while leaving the backlight setting alone, allowing a 'colour display' mode when the backlight is potentially off (not a very useful combination as it's the backlight that goes through the colour layer so you're left looking at a slightly soft BW image from just reflected light). If the backlight is on and there is not much ambient light in the room you see *no* reflected light, simply because there is no light to be reflected. If you are in the sun there is so much reflected light you see no colored background light anymore. I can try and take some pixel macro photos of the effect if it makes you feel better? :-) http://wiki.laptop.org/go/Display#DCON_screen_driver_chip Thanks, I do feel fine ;) I am however slightly frustrated (and I'm not even one of the OLPC engineers) about all the misinformation spread about the XO. Didn't mean to be offensive though, please chalk this up to English being not my mother tongue. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DebXO 0.5 release
On Fri, 13 Feb 2009 18:06:03 -0500 Andres Salomon dilin...@queued.net wrote: Hi, I've just built and tagged DebXO 0.5. I had to put this out sooner than I'd anticipated due to an OFW upgrade that broke things. It doesn't have some of the features I'd wanted to have in 0.5, so they'll have to come later. [...] - There's a new XFCE desktop, courtesy of Erik Garrison. One thing we overlooked; the XFCE desktop doesn't have a browser installed by default. Oops! 'sudo apt-get install epiphany-browser' or 'sudo apt-get install iceweasel' will fix that for you. I've fixed this in the git repository, so the next debxo version will include epiphany-browser in the XFCE desktop. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
Chris Ball and Paul Fox responded: I take this to mean that *something* was draining some power for the two days the XO was sitting in its shut down state. The embedded controller was. Something needs to be watching for a power button press in order to know when to turn on. Thank you. I guess it's simpler to do it that way, than to add two extra latches to the package. [2 latches might work as follows: One latch would be turned on when sent electricity through the power button. This first latch would turn on the second latch if that second latch was off. The software could test the first latch state, and could turn that state off when it wanted to be watching for a power button press. The second latch would connect the battery to the motherboard proper. It would be turned off by the software for zero power drain mode.] Benjamin Schwartz wrote: All rechargeable batteries lose stored energy over time. This phenomenon is called self-discharge. True. I have found the XO-1 batteries (mfg by BYD Company Ltd) to be very stingy with energy loss. When I put one back in after a month out of the case, the XO software told me it was still 94% charged. James Cameron mentioned measuring a current draw of 24mA. I suspect this was *not* on a thoroughly shut-down G1G1. In my experience, after two days in a shut-down state the XO software shows the battery charge % to be somewhere in the mid-90's. James wrote: If you wish to avoid this draining by the EC, and instead rely only on draining by self-discharge of the battery pack, then remove the pack from the XO. Self-discharge rate has a dependency on storage temperature as well. Thanks, mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
On Fri, Feb 13, 2009 at 8:38 PM, Chris Ball c...@laptop.org wrote: Hi, by default the wireless card remains alive to participate in a potential mesh network, disabling wireless should give you a lot more time. You're thinking of sleep mode, not the full shutdown that Mikus is doing. That's not how I learned it. The wireless was designed to remain active when everything else was off, in order to support mesh networking throughout a community. However, I don't see any measurements for that, although the wireless chip draws less than a watt. Perhaps someone would be willing to add it to http://wiki.laptop.org/go/XO_power_draw - Chris. -- Chris Ball c...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name And Children are my nation. The Cosmos is my dwelling place, The Truth my destination. http://wiki.sugarlabs.org/go/User:Mokurai (Ed Cherlin) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
da...@lang.hm wrote: The embedded controller was. Something needs to be watching for a power button press in order to know when to turn on. by default the wireless card remains alive to participate in a potential mesh network, disabling wireless should give you a lot more time. In power off the the WLAN is not powered up. Only the EC remains powered. from the XO. Self-discharge rate has a dependency on storage temperature as well. The self discharge of LiFePO4 is quite low. The numbers thrown about in the marketing docs are between 3-5%/month. Based on the values in the datasheet I calculate ours to be 3.8%/month at 25 degC. However, its highly temperature dependent. The datasheet suggests that at temps = 45 degC its 33%/month and at 60 degC 100%/month. This has be somewhat experimentally verified. There were a few boxes of laptops stored in a temp controlled environment for at least a year and when I examined those batteries they still had plenty of life but, batteries sent to Jordan that were stored in a hot warehouse arrived completely discharged. I did this just now, on a unit running Q2E27, and another running Q2E30, the current is 24mA at 12.9V powered from a large sealed lead acid battery with nothing else attached. Two days of this would be 1.15 amp hours (Ah). Three days would be 1.73 Ah. While running on eternal power the EC does not attempt to enter a low power mode. This is because its monitoring the battery. This is sub-optimal while on things like solar power so at some point this may roll up on the Fixme: list but theres a lot of conditions that have to be dealt with. For now Ext power == EC on full. When powered off and on battery power only the EC attempts to to go into the STOP state where power consumption is much less. Not as low as it should be (see below) but much less. days later I insert the AC adapter into the (still closed) XO, after the 'power' light comes on, it goes yellow. [I've seen this both when I was running 'joyride' on the XO, and when I was running 'staging'.] I take this to mean that *something* was draining some power for the two days the XO was sitting in its shut down state. As mentioned above the EC attempts to go into STOP mode when the power is off and not plugged up to external power. The data sheet indicates that STOP mode is supposed to be in the 10s of uA range. Measurements taken (this morning against my EC dev tree) via instrumented XO indicate that its 4mA. Studying the datasheet that suggests that rather then going into STOP mode the EC is only going into IDEL mode. In IDEL the instruction fetch is turned off but the clocks and timers still run. 4mA is listed as the nominal draw in that mode. Looking at the EC code the go-into-STOP-mode rather than the go-into-IDEL-mode bit is getting set. So the code is _trying_ to go into STOP mode but its power draw suggests otherwise. I'll have to study it deeper. In anycase @ a 4mA draw the EC will see the net ACR diff at about 3.1%/24hours so across 2 days you would have probably discharged enough for the EC to enable the charger to top up the battery. -- Richard Smith rich...@laptop.org One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
Richard A. Smith wrote: going into STOP mode the EC is only going into IDEL mode. In IDEL the instruction fetch is turned off but the clocks and timers still run. 4mA is listed as the nominal draw in that mode. /s/IDEL/IDLE -- Richard Smith rich...@laptop.org One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 2654
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2654 Changes in build 2654 from build: 2652 Size delta: 0.00M -pkgconfig 1:0.23-3.fc10 +pkgconfig 1:0.23-6.fc10 -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
Richard A. Smith wrote: into STOP mode but its power draw suggests otherwise. I'll have to study it deeper. After deeper study I have verified that the EC is going into stop mode. I have also found the (biggest) source of the additional power draw I measured. The tinder box XO has the EC serial port connector loaded and has a TTL-USB adapter connected. The 3.3V EC rail is ORed in with the 3.3V regulator from the 5V USB since the device can be powered by either side. Disconnecting the EC serial port drops the power draw to 1.6mA. This also tells me that the reading listed as EC is not just the EC but all the devices connected to that rail. The instrumented setup only has a current measurement resolution down to about 1mA. So there's room for a lot of error in that measurement. Looking at the schematics I see that there are quite a few other parts that share the 3.3V rail with the EC so 1mA or so seems reasonable. I've started a long term measurement test using the ACR guage inside the battery. I'll check it on Monday. -- Richard Smith rich...@laptop.org One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
On Sat, Feb 14, 2009 at 01:56:22PM -0500, Mikus Grinbergs wrote: I have found the XO-1 batteries (mfg by BYD Company Ltd) to be very stingy with energy loss. When I put one back in after a month out of the case, the XO software told me it was still 94% charged. The displayed state of charge is stored in the chip in the battery, and is maintained by the EC. The battery does not change it's own state of charge value. I don't think that batteries outside the XO will have their state of charge value changed by the chemical self-discharge process. But once the terminal voltage becomes significantly inconsistent with the state of charge value, I imagine that the terminal voltage is trusted more. (If one discharges an XO battery outside the XO using a home lighting circuit, the displayed state of charge will be inconsistent. Persisting in this practice results in increasing inconsistency. Ceasing the practice results in decreasing inconsistency over several XO moderated charge and discharge cycles. The inconsistency results in forced power-down before the state of charge would suggest, manifesting as my XO stops too soon.) James Cameron mentioned measuring a current draw of 24mA. I suspect this was *not* on a thoroughly shut-down G1G1. Wrong. It was on a thoroughly shutdown mass production unit. The unit was shutdown using the Sugar shutdown option, then the DC cable and the battery were removed, 30 seconds were allowed to elapse, and then the DC cable was reinserted. The measurement was after this reinsertion. In my experience, after two days in a shut-down state the XO software shows the battery charge % to be somewhere in the mid-90's. You observe a difference between my measurements and yours. I knew the technique was inadequate, but I was providing it as a maximum. I had already said that I thought the external DC supply path to contain additional losses. Richard has explained that the difference was due to the EC not stopped, because it knows it is on external DC supply. -- James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
This gets more and more bizarre !! James wrote: The displayed state of charge is stored in the chip in the battery, and is maintained by the EC. The battery does not change it's own state of charge value. and (If one discharges an XO battery outside the XO using a home lighting circuit, the displayed state of charge will be inconsistent. Persisting in this practice results in increasing inconsistency. Ceasing the practice results in decreasing inconsistency over several XO moderated charge and discharge cycles. The inconsistency results in forced power-down before the state of charge would suggest, manifesting as my XO stops too soon.) What I am now interested in is understanding a correct state of charge value after having my battery out of the XO for one month. [When I insert that battery and plug in the AC adapter, the 'power' light is green, and the software pop-up says 94%. But I notice that after an hour, the software pop-up *still* says 94%.] I presume that when I merely shut down the XO, and leave it sitting for two days with the battery still in the case: Then when I again connect the XO to the AC adapter (and let it charge until the 'power' light goes from yellow to green), I should be able to trust that what the software pop-up says is accurate. But when the software pop-up is between 90-96% (for a previously out-of-case battery), and despite the AC adapter being plugged in that value does not increase in an hour -- what ought I to do to find the state of charge ? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] 'Resume activity' is confusing for user
Mikus, On 15 Feb 2009, at 00:24, Mikus Grinbergs wrote: My observation from running Joyride 2650 on an XO-1: With 'Resume by default' checked in the Favorite view dropdown in Home View, those activity_icons for which a Journal entry now exists are colored. I __naively__ thought that if I clicked on a colored icon, the *existing* session for that activity would be resumed. You're 3 weeks late ;-) It was a bug, I'm 99% sure Tomeu has this is fixed, if you're using a current build of sugar here's the ticket: http://dev.sugarlabs.org/ticket/238 Here's the rub... Joyride is dead (though for an XO user it's still about the easiest/smoothest way to play with the new sugar toys). It got a Sugar code update back in 2631, making it to sugar 0.83.3 from what I can tell (~19 Jan 2009); but there're just not enough hands on deck to keep that plate spinning. FWIW I've been able to copy-nand and use the image called soas3.img that Marco was kind enough to get an image built and working: http://download.sugarlabs.org/soas/xoimages/ ... but again I fear this is now an end of line unless another engineer can continue the work. I'm not convinced the world of XO users will see much, if any more, output from SugarLabs for a long time, the only hope I see is to run 'Sugar on a Stick' USB spins (Fedora being currently the most tested/working) – but only for testing purposes – the normal Fedora is still far off the level of XO hardware support that the 8.2.x OLPC Fedora fork currently provides. Actually, the latest Fedora SoaS USB image I've tried to boot on an XO just kernel panics, so Marco's above effort is, perhaps the last, most recent XO booting Sugar. With all that doom and gloom, I must say that OLPC 8.2.1 (candidate-800) is looking rather nice in comparison, get some testing in if you can, we may be using it for some time... Regards, --Gary But when in Home View I moved the cursor to the (colored) icon for Terminal and left-clicked, a *second* Terminal session was launched. Apparently, to be sure of what one is doing with a colored icon in Home View, one needs to right-click on that icon, and wait for its palette to be displayed. Then, to 'Resume' a session, right-click on an entry in the palette for which an object name is listed. Or, to 'start' a new session, click on the palette entry that lists the plain activity name (or click on the 'Start' entry near the bottom of the palette). I ought to be able to explain all this to a Sugar user (including when there are special cases and when there are not). But much simpler to just tell him to forget about 'Resume by default'. mikus p.s. Suggestion: when clicking on an icon in Home View favorites will not result in 'returning control' to an already-launched Activity, *don't* color that icon. ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
On Sat, Feb 14, 2009 at 08:26:13PM -0500, Mikus Grinbergs wrote: This gets more and more bizarre !! No, it's just physics and chemistry, constrained by engineering. Please, if you think it is bizarre, explain why you think so, and I'll happily explain the physics that I know. What I am now interested in is understanding a correct state of charge value after having my battery out of the XO for one month. Not possible without discharging the battery fully to determine the state of charge it had. The test is charge destructive; once it is completed there is no usable charge in the battery. [When I insert that battery and plug in the AC adapter, the 'power' light is green, and the software pop-up says 94%. But I notice that after an hour, the software pop-up *still* says 94%.] I hope you aren't surprised. No reason it should change. Battery is not being used. I presume that when I merely shut down the XO, and leave it sitting for two days with the battery still in the case: Then when I again connect the XO to the AC adapter (and let it charge until the 'power' light goes from yellow to green), I should be able to trust that what the software pop-up says is accurate. No. It will be close to the true value most of the time, unless there is damage. By close I mean within 20% or so, 90% of the time, assuming no external use of the battery. I'm just giving you personal estimates there, I don't have all the data. But when the software pop-up is between 90-96% (for a previously out-of-case battery), and despite the AC adapter being plugged in that value does not increase in an hour -- what ought I to do to find the state of charge ? No possible way except a full discharge while measuring the power provided. The state of charge value that you refer to is calculated. It is an estimate. It often represents reality. The calculation is done by the EC based on a measurement of current flowing into or out of the battery, since the battery was manufactured. The measurement is over time, so it is called accumulation. Measurement is done by the EC using the battery support chip in the battery pack. The results are stored in the chip. Measurement does not occur of either chemical self-discharge, or external discharge by some other means. -- James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
My apologies for not being clear. I'll try again: I want to feel that the battery that I just put into the XO I'm walking out the door with is as charged up as it normally can be. 1) If that battery came from an XO that was plugged into the AC 24/7 for the past week -- I *think* it is fully charged up. 2) If that battery came from an XO that had been shut down for 48 hours; but then that XO had been plugged into the AC until the 'power' light went green -- I *think* it is well charged up. 3) If that battery had been sitting on the shelf (not in an XO) for a month -- what did I need to do to make it topped off ? What I am now interested in is understanding a correct state of charge value after having my battery out of the XO for one month. Not possible without discharging the battery fully to determine the state of charge it had. The test is charge destructive; once it is completed there is no usable charge in the battery. Sorry - I did not mean that I cared exactly how charged up it was -- what I want to know is how to ensure to myself, without going to extremes, that the battery was well charged up. [Is 94% reported by the pop-up for an on-the-shelf battery believable, or is the 'true' value half that? And if do I see 94%, do I need to worry that this is a battery that requires some more charging?] the software pop-up says 94%. But I notice that after an hour, the software pop-up *still* says 94%. I hope you aren't surprised. No reason it should change. Battery is not being used. I was under the impression that when the battery charge went somewhere below about 97%, the XO would charge it some more. So I was surprised to have it stay at 94%. [If 94% being shown on the pop-up is not low enough for charging some more, then how can I initiate charging being performed by the XO ?] But when the software pop-up is between 90-96% (for a previously out-of-case battery), and despite the AC adapter being plugged in that value does not increase in an hour -- what ought I to do to find the state of charge ? No possible way except a full discharge while measuring the power provided. Apologies for being unclear. I'm not particularly interested in the precision of the state of charge. What I am interested in is is the battery as 'well charged up' as I can make it be by using the XO's 'built-in' charger - I will want to get the most minutes of use of my XO when carried to a place that does not have electricity ? And if it is not 'well charged up', what do I need to do to make it so? In particular -- if it *were* 90% charged up when I took it off the shelf, would I have to fully discharge it in order to then charge it up (using the XO as the 'charger') closer to 97-99% ? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] XS 0.5.1 RC - Last round of testing...
On Sat, 2009-02-14 at 15:28 +1300, Martin Langhoff wrote: On Sat, Feb 14, 2009 at 12:31 PM, Jerry Vonau jvo...@shaw.ca wrote: I'm seeing the same errors in the install log as Sameer while installing on an XO. openssl does not get installed, because uname returns as an i586 while there is no openssl.586 in the repo just .686. Just to backup my hunch note that a 586 kernel gets installed as recorded in the install log. yum repolist returns the same error as mentioned in the BZ on the XO. I see Sameer's confirmation. You struck gold with that diagnosis. On the XO OS we have the same problem, and a quick check reveals that we ship openssl i686 on the XS. The disk image build happens on xs-dev which reports i686 surely, but it runs on the XO. Can't find anything in the list archives on the matter. h. m Martin: I've done a back2back comparison between revisor and pungi, given the same kickstart file. Pungi creates media which has the needed openssl.i386 file in it's Packages directory, while revisor creates one that excludes the needed file. Think you found a bug in revisor, I feel that this problem will never get corrected in F9. Going forward, if I recall you were using revisor mainly to embed the kickstart file into the media, given that we run the newly created iso though mkslim anyway,(which can add any files to the iso you want) perhaps we might look at using pungi to spin the release in place of revisor. As a bonus pungi runs a whole pile faster that revisor in creating the installation media. Just my thoughts, Jerry ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] xs-activation-server over IPv6
2009/2/14 Martin Langhoff martin.langh...@gmail.com: Later. 0.5.2 or 0.6. If you need it in a formal release, let me know and I'll see about building a 0.5.2 That would be very useful if you could do that within the next week... also if you could include my xs-activity-server patches? We will be deploying 10 servers very soon so this will greatly reduce the amount of work we have to do on each one.. Thanks, Daniel ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] xs-activation-server over IPv6
On Sun, Feb 15, 2009 at 6:21 AM, Daniel Drake d...@laptop.org wrote: 2009/2/14 Martin Langhoff martin.langh...@gmail.com: Later. 0.5.2 or 0.6. If you need it in a formal release, let me know and I'll see about building a 0.5.2 That would be very useful if you could do that within the next week... also if you could include my xs-activity-server patches? We will be deploying 10 servers very soon so this will greatly reduce the amount of work we have to do on each one.. I'll see what I can do ;-) -- got your patches marked for review, I'll get into that on Monday. At this stage, my main concern is the openssl-on-586-breaks-yum problem. That is a showstopper and justifies a 0.5.2 . cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
[Server-devel] Revisor (or Anaconda?) spin - unable to install on i586
Hi everyone, the olpc XS spin is hitting a problem installing on i586s (and that includes our own XO). The problem seems to be well known -- anaconda composes based on the arch of the build host rather than on the arch requested, as described in: https://fedorahosted.org/revisor/wiki/AnacondaUpdates#TheUnabletoInstalloni586Example2 The revisor conf says architecture=386, yet we are getting _only_ openssl i686 on the iso, which won't get installed on 586, so everything breaks on the (partially installed) machine. I'm away from my buildbox today -- Jerry's been testing and reports that pungi-driven composes also put an openssl-i386 on the iso, while revisor-driven composes don't. So it sounds like the problem is perhaps in how revisor drives anaconda? Any hints or ideas? It seems to be a well known problem...? (the compose host is a Fedora-9 box, that follows updates.newkey) cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
[Server-devel] Revisor (or Anaconda?) spin - unable to install on i586
[ resend - now to the appropriate Fedora list - apologies ] Hi everyone, the olpc XS spin is hitting a problem installing on i586s (and that includes our own XO). The problem seems to be well known -- anaconda composes based on the arch of the build host rather than on the arch requested, as described in: https://fedorahosted.org/revisor/wiki/AnacondaUpdates#TheUnabletoInstalloni586Example2 The revisor conf says architecture=386, yet we are getting _only_ openssl i686 on the iso, which won't get installed on 586, so everything breaks on the (partially installed) machine. I'm away from my buildbox today -- Jerry's been testing and reports that pungi-driven composes also put an openssl-i386 on the iso, while revisor-driven composes don't. So it sounds like the problem is perhaps in how revisor drives anaconda? Any hints or ideas? It seems to be a well known problem...? (the compose host is a Fedora-9 box, that follows updates.newkey) cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
