Re: [PATCH] Introduce os-toc-diff.py -- helps compare the output of osbuilder -- take 2
On Mon, Mar 21, 2011 at 4:19 PM, wrote: > Still investigating why 10.1.3 rebuilds have so much delta. The tip of > v1.3 builds it with perfectly matching packages.txt, but there's an important > number of binaries and SOs that don't match. Ah. Blame prelink for my headache. - packages.txt matches - files.txt matches - boots - rpm --verify --nomtime --all shows all stuff we mod - os-toc-diff shows binaries and shared objects -- which prelink is changing So output from the tip of v1.3 looks good. m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[PATCH] Introduce os-toc-diff.py -- helps compare the output of osbuilder -- take 2
From: Martin Langhoff
Question: Is a new osbuilder still building the exact same build?
os-toc-diff.py original/os860.toc build/output/osNN.toc > results.diff
---
This version uses bitfrost utils to walk the datastructure, yielding
a more readable output.
Still investigating why 10.1.3 rebuilds have so much delta. The tip of
v1.3 builds it with perfectly matching packages.txt, but there's an important
number of binaries and SOs that don't match.
---
os-toc-diff.py | 61
1 files changed, 61 insertions(+), 0 deletions(-)
create mode 100755 os-toc-diff.py
diff --git a/os-toc-diff.py b/os-toc-diff.py
new file mode 100755
index 000..cf6ad35
--- /dev/null
+++ b/os-toc-diff.py
@@ -0,0 +1,61 @@
+#!/usr/bin/python
+#
+# Compare OS versions based on the .toc files
+#
+# Usage:
+#os-toc-diff os852.toc os860.toc
+#
+# Copyright (C) 2009, One Laptop per Child
+# License GPLv2+
+# Author: Martin Langhoff
+#
+#
+import os, sys
+import tempfile
+import subprocess
+import shutil
+from bitfrost.contents.utils import UnifiedContents
+
+tmpdir = tempfile.mkdtemp()
+
+if len(sys.argv) != 3:
+sys.stderr.write("Incorrect number of arguments!")
+sys.exit(1)
+
+def pretty_print_content_rec(c, f, path):
+dirents = c.get_dirobject_pair(path)[1][2][1]
+for fn in dirents.keys():
+dent = dirents[fn]
+fpath = os.path.join(path, fn)
+if 'dl' in dent:
+f.write('%s dir %s %s %o ' % (fpath, dent['u'], dent['g'],
dent['m']))
+f.write("\n")
+pretty_print_content_rec(c, f, os.path.join(path, fn))
+else:
+f.write('%s %s %s %o ' % (fpath, dent['u'], dent['g'], dent['m']))
+if 'l' in dent:
+f.write('symlink ' + dent['l'])
+elif 'd' in dent:
+f.write('devnode %s' % dent['d'])
+else: # file
+f.write(dent['h'][0])
+f.write("\n")
+
+tocs = [ sys.argv[1], sys.argv[2] ]
+
+for toc in tocs:
+print "Preparing " + toc
+f = file(os.path.join(tmpdir, os.path.basename(toc)), 'w')
+print os.path.join(tmpdir, os.path.basename(toc))
+c = UnifiedContents(toc)
+pretty_print_content_rec(c, f, '')
+
+subprocess.Popen(['diff', '-u',
+ os.path.join(tmpdir, os.path.basename(tocs[0])),
+ os.path.join(tmpdir, os.path.basename(tocs[1]))
+ ], stdout=sys.stdout).communicate()
+
+# cleanup
+shutil.rmtree(tmpdir)
+
+
--
1.7.3.4
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: L10n of non-Sugar build elements
On Mon, Mar 21, 2011 at 1:59 PM, Chris Leonard wrote: > 1) I believe there are many more strings in the upstream than we are using, > so it would be good to have a specific listing of the packages that we use > to focus our L10n efforts on the most important strings. I am not sure if the modularization points for l10n matches the modularization for rpms, but looking at the 'gnome' lines in these two lists is a start Current stable release 10.1.3 http://download.laptop.org/xo-1.5/os/official/os860/4GB/os860.packages.txt Dev build for 11.2.0 http://build.laptop.org/11.2.0/os14/xo-1.5/os14.packages.txt To look at the apps we include in the gnome desktop -- but which are not default gnome components, and may nobe be part of the gnome project... http://dev.laptop.org/git/projects/olpc-os-builder/tree/modules/gnome/kspkglist.50.gnome.inc does that help? m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: L10n of non-Sugar build elements
On Mon, Mar 21, 2011 at 2:10 PM, Martin Langhoff wrote: > On Mon, Mar 21, 2011 at 1:59 PM, Chris Leonard > wrote: > > place to do that work. I would go further and say we should be showing > some > > love to the upstream by sharing our L10n community's time and talents by > > letting them know which upstream strings flow down into OLPC published > > builds and encouraging them to work upstream on the L10n of those > strings. > > Great idea -- I agree. It's a good idea to see what locales we have in > Sugar (and where we have a strong translation team) that are weak in > Gnome upstream, and help bring those together. > > Just off the top of my head Nepali, Pashto, Tamil, Sinhala have strong L10n efforts on our server, but are less complete in the upstream. I'm sure there are more. I want to make it easy for localizers who join our community via an interest in OLPC / Sugar or eToys to understand how making an upstream contribution ultimately benefits Sugar (first and foremost), but also a wider world of native language Linux experience in other distros. cjl ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: L10n of non-Sugar build elements
On Mon, Mar 21, 2011 at 1:59 PM, Chris Leonard wrote: > place to do that work. I would go further and say we should be showing some > love to the upstream by sharing our L10n community's time and talents by > letting them know which upstream strings flow down into OLPC published > builds and encouraging them to work upstream on the L10n of those strings. Great idea -- I agree. It's a good idea to see what locales we have in Sugar (and where we have a strong translation team) that are weak in Gnome upstream, and help bring those together. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: L10n of non-Sugar build elements
On Mon, Mar 21, 2011 at 1:17 PM, Martin Langhoff wrote: > On Sun, Mar 20, 2011 at 10:46 PM, Chris Leonard > wrote: > > As current XO builds come with a boot into GNOME UI option, we should be > > considering the localization process of those UI elements as well. > > Hi Chris, > > I am in agreement with your assessment of the situation -- that we > need to ensure the gnome bits have their l10n bits. > > However... what I see is that we use the upstream i18n and l10n infra > and output. In other words, Fedora and their upstreams. Our OS Builder > seems to do a good job in including the right l10n bits. > > Are there specific things in the gnome world that you can report are > not localized? > > My assessment, like yours, is that we are and should use the upstream infrastructure and therefore should point our L10n community at the right place to do that work. I would go further and say we should be showing some love to the upstream by sharing our L10n community's time and talents by letting them know which upstream strings flow down into OLPC published builds and encouraging them to work upstream on the L10n of those strings. However, 1) I believe there are many more strings in the upstream than we are using, so it would be good to have a specific listing of the packages that we use to focus our L10n efforts on the most important strings. As an example, Gnome 2.3.0 (stable) has about 45,000 strings and I'm guessing that only a fraction are relevant to an XO build. http://l10n.gnome.org/releases/gnome-2-32/ 2) There are languages hosted in our Pootle server (specifically some of the native languages from less developed regions) that are not represented at all in the upstream, an effort should be made to have those language projects created in the upstream and to point our unique set of localizers there to do that L10n work (again focused on the most relevant strings). My specific proposal is to start by identifying the packages we pull (thus the request for help from one of our developers) and to build a listing on the wiki with links to the primary L10n hosting. When that documentation is done, I propose to advertise it on the L10n list and encourage efforts on the upstream strings. At the same time I would like to engage the upstream L10n community and possibly recruit them to working on our Pootle instance (not exactly a quid pro quo, more of a mutual assistance relationship). Itoo beleive our build infrastructure is doing a good job of grabbing the upstream bits (where they exist), so I can't be really specific about a given string that may or may not be localized in a given language, I'm not reporting a specific "bug", just suggesting a documentation project to drive two-way traffic. Does that make sense? cjl ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.2.0 development build 14 released
On Sun, Mar 20, 2011 at 6:26 PM, C. Scott Ananian wrote: > You might also try just using python's implementation of tar (the > 'tarfile' module), which can probably be hacked to support rsync's > --fake-super as well. Might kill two birds that way. Although I'm > sure that fixing fakeroot will benefit more people. Like XS indeed! On XS we use fakeroot a "persistent" overlay file to serve these files from a non-root rsync. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: L10n of non-Sugar build elements
On Sun, Mar 20, 2011 at 10:46 PM, Chris Leonard wrote: > As current XO builds come with a boot into GNOME UI option, we should be > considering the localization process of those UI elements as well. Hi Chris, I am in agreement with your assessment of the situation -- that we need to ensure the gnome bits have their l10n bits. However... what I see is that we use the upstream i18n and l10n infra and output. In other words, Fedora and their upstreams. Our OS Builder seems to do a good job in including the right l10n bits. Are there specific things in the gnome world that you can report are not localized? m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC-AU] copy-nand vs update-nand
On 21 March 2011 10:12, James Cameron wrote: > But if you have placed an .img and .crc file on a USB drive, and then > typed: > > ok update-nand u:\osX.img > > ... then don't do that. Nobody told you to do that. ;-) If something > did, please let us correct it. I was testing with 10.1.3. My experiences seem to match what you are saying, so no worries. Sridhar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
