[00:31] <CIA-3> partman-md: cjwatson * r934 auto-setup/ (5 files in 4 dirs): (log message trimmed)
[00:31] <CIA-3> partman-md: Rearrange RAID configuration per the
[00:31] <CIA-3> partman-md: foundations-karmic-server-installer-improvements specification. Instead
[00:31] <CIA-3> partman-md: of requiring partitions to be set for use as RAID physical volumes
[00:31] <CIA-3> partman-md: first, we now offer all partitions that could be used as physical
[00:31] <CIA-3> partman-md: volumes, and automatically set them up that way on request. This allows
[00:31] <CIA-3> partman-md: us to offer our main menu option more or less all the time, and should
[08:00] <shtylman> evand: I have been muking around with cleaning up the installer and I think I broke something on the kde side. After clicking next on the language screen it crashes...and syslog reports: debconf: DbDriver "targetdb": could not open /target/var/cache/debcond/config.dat ... any ideas as to what I might have done wrong? my cleanups arn't that dramatic so I am kinda lost with this debconf stuff, thanks...
[08:03] <evand> shtylman: is this with the latest ubiquity?  What version, specifically?
[08:04] <shtylman> 1.13.8
[08:04] <shtylman> maybe I havn't updated in a bit...
[08:12] <shtylman> evand: oh I see...a bit has changed after the oem merge
[08:12] <shtylman> I think I will just kill my changes and start afresh from that
[08:12] <shtylman> evand: some of the oem merge changes actually did what I was doing so yea :)
[08:16] <evand> apologies.  I really need to get better at communicating what's going on with ubiquity development.  I emailed xivulon about the incoming merge, as I knew it directly affected what he was working on, but I didn't think to CC you.  I'll send such mails to ubuntu-installer@ next time.
[08:18] <shtylman> evand: no worries :) I haven't had as much time (with my move to nyc and all) to keep up with the dev as a would have liked...but now I am more settled in and hopefully can get a hold of it
[08:20] <evand> shtylman: how is that going, by the way?  Are you in Manhattan or in the dark territory of of a surrounding borough?
[08:21] <shtylman> evand: hahah...it went quite well. Started work on Monday (eats up ALOT of time) ... yea, I am in Manhattan...I avoided the dark territories :)
[08:21] <evand> haha
[08:31] <evand> xivulon: out of curiosity, why do you use Python 2.3 in Wubi, rather than Python 2.6?
[08:31] <shtylman> evand: just a heads up on what my changes will entail... beyond the cosmetic things I showed you, I am migrating the sig/slot connect calls over to the new mechanism in pyqt4.5 and also cleaning up some of te codebase...
[08:32] <evand> good deal
[08:32] <evand> do you have this in a published branch?
[08:32] <xivulon> hi evand, because A) it leads to a smaller overall package B) there are issues with the distributions of some libraries in python 2.4+
[08:32] <evand> xivulon: can you elaborate on B?
[08:33] <shtylman> evand: not yet... I did start a branch, but I am gonna delete it cause I am just gonna restart from the changes since oem-config merge... they arn't all that many yet or hard to do so hopefully I will have a new published branch soon
[08:34] <evand> shtylman: okay, thanks
[08:41] <xivulon> evand have to fetch the info, iirc newer versions are linked against msvcr*.dll, and I believe you cannot redistribute the CRT unless you are a visual studio licensee
[08:51] <xivulon> evand, compiling python + extensions in mingw32 should also do the trick
[08:53] <evand> hrmm
[08:54] <xivulon> evand: http://article.gmane.org/gmane.comp.python.py2exe/652
[09:00]  * evand reads up
[09:02] <evand> surely if this was an issue, you would not be able to redistribute the Python for Windows installer, which I imagine would be a big deal.
[09:02] <xivulon> ps in trunk I have created a new tool called pypack (out of pyinstaller), running that in wine with the target python version, it will convert a python script (entry point) into a self-contained directory with all required dependencies
[09:02] <evand> nice
[09:02] <xivulon> I think python devs have the license to redistribute msvcr*.dll, I do not own visual studio though
[09:03] <xivulon> and I did not know about the implications for you redistributing it, so I went the safe route, I tried python 2.3 and I saved quite some space, so I ended up sticking with that
[09:06] <evand> okay
[09:06] <evand> I'll have to do some more research on this
[09:07] <xivulon> Most annoying part of using 2.3 I found is lack of annotations and some modules (sets) have to be installed separately
[09:09] <xivulon> have to go now, feel free to send me an email if you have other questions
[10:47] <CIA-3> ubiquity: cjwatson * r3319 ubiquity/ (bin/ubiquity debian/changelog):
[10:47] <CIA-3> ubiquity: Restore autologin-disabling code from oem-config, corrected to work with
[10:47] <CIA-3> ubiquity: new gdm (LP: #395861).
[12:49] <evand> cjwatson: I just want to check with you before I start putting pieces into place.  Do you have any objections to a ubiquity-slideshow-ubuntu package (in its own source package) that ubiquity-frontend-gtk depends on?  It's currently set up to provide ubiquity-slideshow, but I can't see that being necessary as putting a dependency on ubiquity-slideshow in ubiquity would require every frontend to provide a slideshow and I can't think of how we'd so
[12:59] <evand> err nevermind on that not being necessary.  I missed the obvious case of the different slideshow packages needing to conflict.
[13:12] <mterry> cjwatson, whoops, didn't mean to drop a autologin-disabling section in the merge
[13:14] <cjwatson> evand: it's fine by me
[13:14] <cjwatson> mterry: no worries, just happened to notice it
[13:14] <evand> good deal
[14:19] <CIA-3> ubiquity: evand * r3320 ubiquity/ (3 files in 3 dirs): Add support for ubiquity-slideshow.
[14:28] <superm1> okay so looks like if no slides are found, just hides the frame like before
[14:29] <superm1> sounds good to me
[14:40] <cjwatson> mterry: I've reassigned all the open oem-config bugs to ubiquity, and tagged them 'oem-config'
[14:40] <mterry> cjwatson, hah.  I was just investigating how to do that via launchpadlib
[14:40] <mterry> cjwatson, saved me some trouble, thanks.  :)
[14:40] <cjwatson> (hmm, I may have accidentally reassigned duplicates too)
[14:41] <cjwatson> mterry: http://paste.ubuntu.com/219780/
[14:42] <cjwatson> probably want something like 'and not task.bug.duplicate_of' in there
[14:42] <evand> ...829 open bugs... :-/
[14:42] <mterry> cjwatson, interesting.  that makes sense now that I see it, but I was wading through a bunch of docs to get there
[14:43] <cjwatson> yeah, I've just been there before is all
[14:43] <cjwatson> the bug tagging trick is one you have to know - bug 254091
[14:43] <cjwatson> err, what?
[14:44] <cjwatson> bug 254901
[14:44] <mterry> curious
[14:44] <cjwatson> today, launchpadlib let me do in about three or four hours what took me two full days last time I did it
[14:44] <cjwatson> (8.04.3 change summary)
[14:45] <cjwatson> so it's well worth some investment in learning
[14:45] <mterry> :)
[14:45] <cjwatson> evand: yeah :-/
[14:49]  * mterry gets a cjwatson-inspired email storm
[14:50] <mterry> cjwatson, oh, btw, I don't mean to be a pest, but I didn't get an ACK yesterday, so I'm pinging you again about it: Can you take a look at https://code.launchpad.net/~mterry/ubiquity/translated-timezones/+merge/8698 when you have time and in particular, give me an OK or not on starting an MIR for python-pyicu
[14:52] <cjwatson> ok, I'll queue it up
[14:52] <cjwatson> from what you've written, I suggest starting a MIR for pyicu anyway
[14:53] <cjwatson> I can imagine using it somehow in gfxboot-theme-ubuntu, for instance; there's a long-running bug in which people complain about the collation
[15:02] <cjwatson> mterry: what's the one-liner for sorting a list of strings using pyicu then?
[15:34] <mterry> cjwatson, i missed your last comment about pyicu due to irc issues.  the question was, 'what's a one-liner for sorting with pyicu?'  let me grab that
[15:36] <mterry> cjwatson, well...  not really a one-liner.  what it does is gives us a 'collation key' for python's normal sort algorithms.  So doing 'self.collator.getCollationKey('goofy string').getByteArray()' gives a good collation key
[15:37] <mterry> cjwatson, but you first have to instantiate a collator with a certain locale
[15:37] <mterry> (persia, thanks for noting the missed question)  :)
[15:38]  * persia lurks harder
[15:47] <cjwatson> mterry: mm, I realised shortly after asking that I could have found the answer by looking through your merge request :)
[15:48] <cjwatson> right, so it doesn't really help with the language question unfortunately since there is no preferred locale there
[15:48] <mterry> cjwatson, even instantiating with the C locale is fine there
[15:48] <cjwatson> I mean I suppose we could just say sod-it and do Latin-alphabet sorting
[15:48] <cjwatson> mm, sort of
[15:48] <mterry> cjwatson, it only uses the locale for special situations
[15:48] <cjwatson> where does Čeština go?
[15:48] <mterry> cjwatson, there are several layers of collation
[15:49] <mterry> cjwatson, even in C, it will strip accents AFAIK
[15:49] <cjwatson> or Қазақ for that matter
[15:49] <mterry> Қазақ is post-ASCII
[15:49] <mterry> (i.e. sorted after Z)
[15:49] <cjwatson> that's unfortunate
[15:49] <mterry> (As i recall)
[15:49] <mterry> I tested with sorting the language list
[15:50] <cjwatson> it'd presumably mean that everything non-Latin gets punted to the end
[15:50] <mterry> But it was strictly better than the current list.  :)
[15:50] <mterry> Mostly
[15:50] <mterry> In fact, yes
[15:50] <mterry> But where would you sort them?  You can't really sort glyphs in the middle of Latin
[15:50] <cjwatson> Қазақ oughta go with the Ks
[15:51] <cjwatson> I dunno, it's all terribly subjective
[15:51] <mterry> cjwatson, the Unicode consortium has specs for this
[15:51] <mterry> cjwatson, and libicu tries to follow them
[15:51] <mterry> cjwatson, let me find the spec
[15:51] <mterry> cjwatson, http://unicode.org/reports/tr10/
[15:53] <cjwatson> right, for locale-dependent collation
[15:54] <mterry> cjwatson, right.  but in the absence of a locale, I argue that applying 70% of the collation logic is better than the arbitrary order we have now
[15:54] <cjwatson> nobody really designs for the case where you don't know the target language because (a) the best you can do is smelly heuristics and (b) it's very rare
[15:54] <cjwatson> I'm happy for somebody to drop in a replacement collation order on the condition that if we ever get bugs about it I can assign them to that person. :)
[15:54] <mterry> cjwatson, unless you wanted to have sexy animation logic where we resort the list after selecting a language.  :)
[15:54] <cjwatson> no, that'd definitely be confusing
[15:55] <mterry> agreed
[15:55] <cjwatson> "the thing I clicked on just ran away, help"
[15:55] <mterry> cjwatson, though, we do know the locale at that point.  It's 'C'.  :)
[15:56] <cjwatson> yeah, I sort of meant a useful locale
[15:59] <mterry> cjwatson, well, I consider the current sorting as 'random'.  Having a sorting that at least puts most characters that look alike near each other will help people find their language.  Though there may be odd balls like your funky K
[15:59] <mterry> cjwatson, you can blame me when people complain
[16:00] <mterry> as you say, it's an inherently unsolvable problem
[16:02] <mterry> Exhibit A in my 'what's wrong with the current sorting' is Finnish
[16:03] <cjwatson> so let's go with it
[16:04] <mterry> cjwatson, one thing that may help is trying something like the LanguageOnly screen, where all languages fit on one screen
[16:04] <mterry> cjwatson, have we found that to be helpful?
[16:05] <cjwatson> I don't really like it personally
[16:05] <cjwatson> in the case of ubiquity I think the other information on the front page is useful to display, and aesthetically I just find the bare grid rather intimidating-looking
[16:06] <cjwatson> it has an obvious scaling problem too - we add languages from time to time, not many but usually one or two a release
[16:06] <mterry> Yeah....  And I would expect it to sort down first before sorting left-to-right.  But that's probably locale-dependent too
[16:06] <mterry> /probably/certainly/
[16:07] <cjwatson> we do it that way largely because some OEMs complained that (IIRC) Chinese wasn't on the front page, but I can't say I like the results
[16:07] <mterry> That's an interesting idea.  A good sorting in C locale might just be based on usage
[16:07] <mterry> We have popcon data for that?
[16:07] <mterry> for which language packs are installed...
[16:07] <cjwatson> dunno
[16:08] <cjwatson> I'm not convinced Ubuntu popcon is what you might call accurate
[16:08] <cjwatson> there's some evidence of serious skew
[16:08] <mterry> en would probably give false positives.  and languages for where the popcon UI is not translated would have trouble
[16:08] <mterry> cjwatson, locale data for the firefox homepage?
[16:08] <mterry> firefox sends it
[16:08] <cjwatson> I don't think usage is a good sorting metric though
[16:09] <cjwatson> that requires a very very weird mindset on the part of users
[16:09] <mterry> hmm...  but we could have a sexy web 2.0 cloud of language names
[16:09] <cjwatson> "oh yeah, I think my language is about the twentieth most popular in the world"
[16:09] <cjwatson> ... not happening :)
[16:09] <cjwatson> I'd rather have a best-effort C sort with a few weird spots
[16:09] <mterry> yar, but it even with my sexy new sorting, they have to think 'hmm, I think english would sort me here'
[16:10] <mterry> Which is something they're more used to, so...
[16:10] <cjwatson> right, but at least A-Z sorting is fairly usual
[16:10] <cjwatson> so it's only Czech, Kazakh, and the non-Latin ones who have to think
[16:10] <cjwatson> which is still a lot but it's better than now
[16:10] <mterry> alright.  Well, first step is MIR
[16:10] <cjwatson> and *definitely* better than it would be if we shuffled the order by speaker count
[16:11] <mterry> :)
[16:11] <cjwatson> I must admit python-pyicu seems like a lot of bytes for a smarter sort()
[16:11] <mterry> yeah, but icu is already on cd for openoffice
[16:11] <cjwatson> I wonder if we could do a reasonable job in less space given the limited input data
[16:11] <mterry> python-pyicu itself is a small addition
[16:11] <cjwatson> it's >200KB - not huge but not that trivial either
[16:12] <cjwatson> if it'd be really hard to do a decent job independently, I'll defer
[16:12] <mterry> cjwatson, we could hardcode it.  we could strip accents, but unless we hardcoded list of accents, we'd need to get that from *some* library
[16:12] <mterry> cjwatson, if language list doesn't change unless we hear about it, hardcode might not be the worst
[16:12] <mterry> but...  i want icu for sorting country list anyway
[16:13] <mterry> so it's already there
[16:13] <mterry> and that should take into account the locale, which we definitely don't' want to reimplement
[16:13] <cjwatson> ok
[16:13] <cjwatson> I don't really want to hardcode as such
[16:14] <cjwatson> we hear about changes, but we have to sort the list in several places, so my gut feel is that hardcoding would get out of date
[16:15] <mterry> Is there an issue with adding python-pyicu to the CD in terms of size?
[16:16] <cjwatson> there's always a size issue with adding things to the CD :-/
[16:16] <cjwatson> it won't be the worst offender, but it'll crowd out part of a language pack or so
[16:16] <cjwatson> always tradeoffs
[16:53] <rbelem> hi all, i'm trying to build an iso with ubuntu-cdimage. i need to find out if $(BASEDIR)/tasks/auto/$(IMAGE_TYPE)/$(PROJECT)/$(DIST)/MASTER something creates this or should i create this file manually
[16:58] <cjwatson> rbelem: update-tasks creates that
[16:59] <cjwatson> rbelem: well, update-tasks copies it into place - the file itself is written by make-master-task, called by germinate-to-tasks
[17:02] <rbelem> cjwatson, nice! Are there other commands should i run before build-image-set?
[17:03] <cjwatson> build-image-set should already call those things for you ...
[17:03] <cjwatson> and it should be fine on its own although we generally run it via one of the cron.* wrappers
[17:04] <rbelem> cjwatson, hum... i will check what i'm doing wrong
[17:04] <rbelem> cjwatson, thanks for your help :-)
[17:35] <evand> mpt: Regarding your most recent comment on bug 154506, the text as of today's live CD is "Install Ubuntu 9.10".  Would you suggest I change this to "Install Ubuntu 9.10 Permanently"?
[17:36] <mpt> evand, wellllll, it occurred to me a couple of years later that "permanently" is a strong word :-)
[17:36] <evand> heh
[17:36] <mpt> so I thought maybe "Install Ubuntu on this computer"
[17:37] <evand> the tricky thing about that is that A) it's really long and B) you might be installing to a USB disk
[17:37] <mpt> you can do that?
[17:37] <evand> yarp
[17:37] <mpt> ((B))
[17:37] <mpt> Why wouldn't you be using usb-creator to do that?
[17:38] <evand> they don't do exactly the same thing
[17:39] <evand> usb-creator puts the live media on a usb disk.  You can have persistent storage, but as a file that serves as a copy-on-write layer.
[17:40] <evand> installing via ubiquity means that all writes go straight to the filesystem, there is no pristine copy of ubuntu with a layer of changes on top of it like there is with the live media
[17:41] <mpt> What's "a copy-on-write layer"?
[17:42] <cjwatson> persistent storage (i.e. doesn't go away on reboot). It's OK for a while and for quick demonstrations and the like, but it has some weird properties so you wouldn't want to use it long-term
[17:43] <cjwatson> in particular if you upgrade the system you will run out of space on the stick eventually - when upgrading system files it never frees the storage used for them at the start of the stick
[17:43] <mpt> huh
[17:43] <mpt> I had no idea that using usb-creator was not the recommended way of setting up a USB installation you plan to work from.
[17:44] <cjwatson> usb-creator is best thought of as taking a live CD and putting it on a USB stick
[17:44] <CIA-3> ubiquity: superm1 * r3321 ubiquity/debian/ (oem-config-gtk.postrm oem-config-gtk.preinst changelog):
[17:44] <CIA-3> ubiquity: Divert the ubiquity-gtkui.desktop file when oem-config is installed as
[17:44] <CIA-3> ubiquity: oem-config now depends on ubiquity.
[17:44] <evand> name change ideas welcome :)
[17:44] <evand> I'm not convinced people care about treating a USB disk like a CD where the data goes away at the end
[17:45] <evand> writing to a USB disk is pretty simple.  If they mess it up, they're probably willing to run the utility to write an image to it again
[17:45] <mpt> evand, so would it be possible to make usb-creator set up Ubuntu on the USB device in the same way that Ubiquity does?
[17:45] <cjwatson> superm1: eww. I wonder if we can do better than that.
[17:45] <cjwatson> superm1: (and can we have consistent formatting in scripts please?)
[17:45] <mpt> Or is that effectively equivalent to just using Ubiquity?
[17:46] <evand> that
[17:46] <superm1> cjwatson, oh my mistake on the formatting. bad copy paste job. will clean up
[17:46] <cjwatson> superm1: I assume you're trying to arrange for ubiquity not to be visible in the applications menu at the configuration stage
[17:46] <mpt> evand, ok, usb-creator perhaps should include a one-sentence disclaimer about that under the radio button for storing your data on the USB disk
[17:47] <cjwatson> superm1: maybe the answer is to get round to having oem-config remove itself
[17:47] <superm1> cjwatson, no i was actually referring to the installed system
[17:47] <cjwatson> superm1: though I agree the diversions are ok for the moment
[17:47] <evand> mpt: though we could preseed some assumptions, like the choices available for formatting the disk (just blow it away, people don't dual boot on usb disks, for example).
[17:47] <superm1> cjwatson, but that is the proper solution i agree
[17:47] <mpt> evand, I can't suggest a wording for that right now, partly because I don't fully understand the issue, and partly because I have a headache
[17:47] <cjwatson> superm1: what's the distinction between installed system and configuration stage?
[17:48] <cjwatson> I meant configuration stage as in when the end user gets oem-config presented to them
[17:48] <superm1> cjwatson, oh i suppose they are identical, you're right.  at first i thought you meant configuration stage as when the system was getting installed
[17:48] <cjwatson> superm1: hmm, I'm not sure the semantics of that diversion are quite right - should it remove the diversion on upgrade too?
[17:48]  * cjwatson squints at policy
[17:49] <superm1> that would be version dependent I suppose
[17:49] <evand> mpt, cjwatson: "In time this space will run out and further changes will no longer be saved." ?
[17:49] <superm1> IE you want the diversion to go away at version 2.0.0 or so, then you'll remove it on upgrade with that version
[17:49] <cjwatson> well, no, it's better for the previous version's postrm to do it
[17:49] <evand> err will not be saved
[17:50] <cjwatson> superm1: any reason not to do the diversions unconditionally in preinst/postrm?
[17:50] <mpt> evand, I have the niggling feeling that the sheer variety of ways of installing Ubuntu makes the average process more difficult than it could be
[17:50] <mpt> but anyway
[17:50] <cjwatson> Ian told me once that the maintainer scripts were designed such that common cases could usually be run unconditionally
[17:50] <evand> mpt: that's been an increasing concern of mine
[17:50] <evand> fortunately colinux didn't happen, but the list is still too long
[17:50] <superm1> cjwatson, no particular reason I can think of.  just thinking back and i've always seen it ran only in case statements
[17:51] <mpt> evand, so is it that the your-stuff area is write-only, space used by deleted files isn't reallocated?
[17:51] <mpt> (on USB sticks with usb-creator)
[17:51] <evand> mpt: that's my understanding.
[17:51] <cjwatson> mm, a lot of people overconditionalise maintscripts, and hardly anyone gets the rollback cases right
[17:51] <cjwatson> let's see, preinst install/upgrade you clearly want to add the diversion
[17:52] <cjwatson> preinst abort-upgrade is error unwind from postrm upgrade so needs to undo whatever postrm upgrade does
[17:53] <superm1> or abort-install in that case too i suppose
[17:53] <cjwatson> no preinst abort-install
[17:53] <cjwatson> postrm upgrade goes after preinst upgrade, so ok that shouldn't remove the diversion
[17:54] <superm1> oh i was thinking of postrm abort-install. where's that cheat sheet at... oh yeah http://women.debian.org/wiki/English/MaintainerScripts
[17:55] <cjwatson> hmm. ok. I think you're right that it has to be conditional.
[17:55] <cjwatson> unfortunate, that does indeed mean it'll need a version guard to remove it later
[17:55] <cjwatson> which is sort of a shame because it never goes away
[17:55] <cjwatson> oh well
[17:56] <CIA-3> ubiquity: superm1 * r3322 ubiquity/debian/oem-config-gtk.postrm: clean up formatting from previous commit
[17:56] <mpt> evand, so maybe something like "Deleting files from this area will not increase space available."
[17:56] <mpt> er, "space available" -> "available space"
[17:57] <mpt> (reinsert headache disclaimer here)
[17:57] <cjwatson> deleting files from the persistent area will increase available space
[17:58] <mpt> Then what doesn't?
[17:58] <cjwatson> replacing files in the non-persistent area with files in the persistent area will decrease available space more than intuition would predict
[17:58] <cjwatson> deleting files in the non-persistent area will not increase available space
[17:58] <mpt> ah, so this is mainly about updates and installing new packages?
[17:58] <cjwatson> mostly, yeah
[17:59] <mpt> Whereas if you choose "Discarded on shutdown..." you can't install updates or new packages at all?
[17:59] <mpt> or, you can, but they get discarded on shutdown too?
[18:01] <mpt> If so, that makes this much simpler
[18:04] <mpt> evand?
[18:05] <cjwatson> right, the latter
[18:05] <mpt> ok!
[18:05] <cjwatson> turns out people do want to upgrade the live USB stick quite often, we found out about this when a casper bug broke kernel upgrades a bit ...
[18:06] <mpt> evand, so I suggest changing "documents and settings will be:" to "documents, settings, and new or updated software will be:"
[18:06] <mpt> And now I'm going home, I'll read scrollback tomorrow if you have questions
[18:07] <mpt> hm, actually, no, I'm taking this notebook home with me, but I'll be online in a couple of hours or so
[18:08] <evand> sorry, was on the phone
[18:11] <rbelem> cjwatson, i was debugging to discover where the problem was and i found out that the seeds list are not being populated
[18:12] <rbelem> cjwatson, i made this change http://paste.ubuntu.com/219926/ to exit when this is the case
[18:13] <rbelem> cjwatson, do you have any clues about why this is happening
[19:05] <cjwatson> rbelem: dunno, run list-seeds under sh -x maybe?
[19:27] <rbelem> cjwatson, in fact the problem is not in list-seeds but in germinate. it is generating the structure file without entries on the installer.
[19:28] <cjwatson> might depend on what seeds you point it at ...
[19:28] <cjwatson> that stuff has been stable for us for a long time
[19:29] <rbelem> i'm using ubuntu.karmic and platform.karmic
[19:30] <cjwatson> can you pastebin the entire contents of the structure file it generates? or is it literally empty?
[19:36] <rbelem> cjwatson, http://paste.ubuntu.com/219980/
[19:36] <cjwatson> well that looks fine
[19:36] <cjwatson> installer isn't supposed to have any dependencies
[19:37] <cjwatson> what does 'list-seeds /path/to/that/structure/file installer' say?
[19:38] <rbelem> cjwatson, it is returning nothing
[19:38] <cjwatson> oh, I know
[19:38] <cjwatson> you aren't using one of those cron.* wrappers as I suggested, and nor are you setting any of the environment variables they set
[19:39] <cjwatson> if you want to produce an install CD (text installer), you need to set CDIMAGE_INSTALL=1 in the environment
[19:40] <rbelem> i'm running the following line
[19:40] <rbelem> LOCAL_SEEDS=file:///home/rodrigo/devel/ubuntu/seeds/ CDIMAGE_ROOT=`pwd` PROJECT=ubuntu CAPPROJECT=Ubuntu DIST=karmic ARCHES=i386 CDIMAGE_NOSYNC=1 IMAGE_TYPE=daily build-image-set daily
[19:40] <cjwatson> you should use 'for-project ubuntu build-image-set daily' rather than setting PROJECT and CAPPROJECT; and add CDIMAGE_INSTALL=1 to that
[19:41] <cjwatson> oh and you don't need to set IMAGE_TYPE=daily, the fact that you're running 'build-image-set daily' implies that
[19:41] <cjwatson> you could just use cron.daily, that'd be easier
[19:42] <cjwatson> LOCAL_SEEDS=file:///home/rodrigo/devel/ubuntu/seeds/ CDIMAGE_ROOT=`pwd` DIST=karmic ARCHES=i386 CDIMAGE_NOSYNC=1 for-project ubuntu cron.daily
[19:42] <rbelem> cjwatson, nice! :-) i will try this right now
[19:42] <rbelem> :-)
[19:45] <rbelem> cjwatson, it is working! \o/
[19:47] <cjwatson> good
[19:49] <rbelem> cjwatson, i'm writing a script using debmirror to reduce the disk usage. Do you think this might be interesting to add to the mainline?
[19:52] <cjwatson> sure, potentially
[19:54] <rbelem> cjwatson, neat! i will finish it and put it in my branch
[20:57] <CIA-3> partman-base: cjwatson * r162 ubuntu/ (7 files in 3 dirs): merge from Debian 132
[20:59] <CIA-3> partman-base: cjwatson * r163 ubuntu/debian/changelog: releasing version 132ubuntu1
[21:17] <CIA-3> partman-target: cjwatson * r769 ubuntu/ (16 files in 6 dirs): merge from Debian 61
[21:38] <CIA-3> partman-target: cjwatson * r770 ubuntu/debian/changelog: merge from Debian 62
[21:41] <CIA-3> partman-target: cjwatson * r771 ubuntu/debian/changelog: releasing version 62ubuntu1
[22:06] <svenstaro> Hey there, can you guys tell me how "pluggable" Ubiquity is as it stands?
[22:09] <svenstaro> As in, can I write a plugin to support different installation profiles? Does it support tours already?
[23:10] <cody-somerville> svenstaro, It is but not as "pluggable" as plain debian-installer
[23:34] <CIA-3> partman-lvm: cjwatson * r1221 ubuntu/lib/lvm-base.sh: honour partman locking when checking freeness
[23:35] <CIA-3> partman-md: cjwatson * r935 auto-setup/lib/md-base.sh: honour partman locking when checking freeness
[23:38] <CIA-3> partman-lvm: cjwatson * r1222 ubuntu/lib/lvm-base.sh: mkdir -p in pv_prepare, just to be safe
[23:38] <CIA-3> partman-md: cjwatson * r936 auto-setup/lib/md-base.sh: mkdir -p in md_prepare, just to be safe


[15:45] <cr3> cjwatson: are you still maintaining germinate under people.u.c as per https://wiki.ubuntu.com/Germinate, or is it now maintained in launchpad?