[00:30] <rgreening> evand: ping pong
=== avoine1 is now known as avoine
[05:40] <tleuser_> hello all
[09:44] <CIA-33> usb-creator: evand * r170 trunk/ (debian/changelog usbcreator/frontends/gtk/frontend.py):
[09:44] <CIA-33> usb-creator: Close the file chooser when Cancel is selected (LP: #426430). Thanks
[09:44] <CIA-33> usb-creator: Severin Heiniger!
[09:50] <CIA-33> partman-partitioning: cjwatson * r714 ubuntu/debian/changelog: releasing version 71ubuntu1
[09:52] <xivulon> cjwatson, I am still stacked with the out-of-disk issue, I think I can rule out fs corruption and lba/bios (tried all kvm bioses)
[09:55] <CIA-33> partman-auto: cjwatson * r304 ubuntu/ (17 files in 5 dirs): merge from Debian 89
[09:56] <cjwatson> xivulon: ok, what I need is clear directions on how I can reproduce it here - it's very unlikely I'm going to be able to debug it remotely
[09:56] <cjwatson> xivulon: well, unless you can give me a full filesystem image to download, but presumably it's quite large?
[09:57] <xivulon> cjwatson create a vm with ntfs, mount it, put a 5GB disk image with ext3 and linux, and a bootloader
[09:58] <xivulon> create a vm = create a raw file and format as ntfs
[09:58] <CIA-33> partman-auto: cjwatson * r305 ubuntu/debian/changelog: releasing version 89ubuntu1
[09:59] <cjwatson> presumably not just any disk image
[10:00] <xivulon> The ntfs image should be a disk image with partition table although I assume kvm can boot also from a formatted file
[10:01] <xivulon> the ext3 image you put in there is instead a formatted file
[10:01] <xivulon> I'd guess that dd of a karmic ext3 partition will do
[10:02] <xivulon> The rune I use to mount an image with partition table is:
[10:03] <xivulon> sudo losetup /dev/loop0 /home/vm/xp_sp2.img && sudo kpartx -av /dev/loop0 && sudo mount  /dev/mapper/loop0p1 /mnt
[10:03] <xivulon> ^ credit to kirkland (iirc)
[10:06] <xivulon> you will have to install grub2 in the mbr somehow (in my case I have ntldr in there which chainloads to grub2)
[10:22] <davmor2> cjwatson: hey will you have time to look at this vista issue today, I'd like if possible to get a fix in place pre alpha6
[10:22] <davmor2> I'll try it against xp too
[10:33] <cjwatson> you mean the one xivulon just asked about? I'll see, can't promise
[10:34] <xivulon> davmor2 what vista issue?
[10:35] <xivulon> cjwatson, by the way, if you want to use the same grub2 used in wubi, I build it from karmic grub-pc packages, via make winboot2 (you need to add ext2 module)
[10:36] <xivulon> files end up in build/winboot and, wubildr is the one you want
[10:37] <davmor2> cjwatson: I mean the one where vista doesn't show up in the grub menu.
[10:37] <davmor2> xivulon: ^
[10:38] <cjwatson> oh, that. probably not today, sorry
[10:38] <davmor2> cjwatson: no probs :)
[10:41] <xivulon> evand, forgot to mention that, I do not enforce what grub2 package is required for building wubi at the moment, FYI  I am still on jaunty, but I have latest grub-pc from karmic installed
[10:42] <evand> okay
[10:43] <cjwatson> you probably ought to enforce that, jaunty's grub2 is pretty old and crusty
[10:45] <xivulon> agreed
[11:07] <CIA-33> ubiquity: cjwatson * r3438 ubiquity/ (16 files in 7 dirs):
[11:07] <CIA-33> ubiquity: More packaging simplifications: move dh_clean arguments to debian/clean;
[11:07] <CIA-33> ubiquity: remove old $(BUILDDIR) cruft; move architecture-specific
[11:07] <CIA-33> ubiquity: build-dependencies to debian/control, which dpkg has supported for quite
[11:07] <CIA-33> ubiquity: a while; use dh-di for partman scripts.
[11:20] <dpm> cjwatson: hi, good morning. Regarding https://lists.launchpad.net/ubuntu-translations-coordinators/msg00151.html, and in particular http://ubuntu.pastebin.com/m28f6671d, have you had a chance to look into merging the d-i template translations into the ubiquity one? Do you need any help from the translations team?
[11:21] <cjwatson> dpm: I have no idea where to start, really
[11:21] <cjwatson> I have an export from before the split
[11:22] <cjwatson> oh, no I don't
[11:22] <cjwatson> but my export does contain ubiquity translations
[11:22] <dpm> right
[11:25] <cjwatson> I assume it'd be a great big msgmerge and upload, but ... yes, I need help
[11:25] <dpm> could you give me a few pointers, so I see whether we can help? Perhaps a link to the old and new templates in the code
[11:26] <dpm> I mean before the split
[11:26] <dpm> and to the translations
[11:27] <dpm> Then I can try to summarise what we can do in an e-mail to the UTC list and perhaps we can take it from there
[11:27] <dpm> or if you've got some suggestions in a particular task we can help (e.g. the msgmerge)
[11:30] <cjwatson> A link to the old and new templates? I don't understand, either what you want or how it would help if I did understand :-)
[11:30] <cjwatson> but that's not really where I need help, I can drive the gettext tools very competently. What I need to know is what I need to upload to LP ...
[12:06] <dpm> cjwatson: I was just mentioning the templates so I can understand the structure myself, I'm not very familiar with the d-i code nor the packaging (and I'm well aware you are more than competent with the gettext tools :-), I was just trying to see how the translations team could help).
[12:07] <dpm> I was just mentioning the templates so I can understand the structure myself, I'm not very familiar with the d-i code nor the packaging (and I'm well aware you are more than competent with the gettext tools :-), I was just trying to see how the translations team could help).
[12:07] <dpm> I'll try to recap to the best of my understanding, so can you please correct me or help me filling the gaps?
[12:08] <dpm> So in Jaunty there were the following templates exposed for translations in LP:
[12:08] <dpm> debian-installer
[12:08] <dpm> help
[12:08] <dpm> bootloader
[12:08] <dpm> ubiquity
[12:08] <dpm> oem-config
[12:09] <cjwatson> help and bootloader are not relevant
[12:09] <dpm> In Karmic the changes basically imply transfering some translations from the d-i template to the ubiquity one.
[12:09] <dpm> right
[12:09] <cjwatson> also merging oem-config into ubiquity
[12:09] <cjwatson> TBH it only matters at all for languages we don't support yet
[12:09] <cjwatson> but anyway ...
[12:12] <dpm> so the d-i and oem-config strings get put into ubiquity, but I guess we should not block the current oem-config template in LP, since it still contains some (.desktop?) translations which need to be exposed
[12:17] <cjwatson> oem-config is dead, long live ubiquity
[12:17] <cjwatson> it's been merged
[12:18] <dpm> so those couple of translations exposed in oem-config in jaunty are now in ubiquity and we can block oem-config
[12:18] <dpm> for Karmic in LP, I mean
[12:18] <cjwatson> yes
[12:19] <cjwatson> but same thing, ought to transfer over translations that haven't been merged into the source package
[12:19] <dpm> right
[12:21] <dpm> ah, before I forget: another question regarding bootloader and the slideshow...
[12:22] <dpm> We've got these templates in the import queue. What shall we do with them?
[12:22] <dpm> 1) debian/gfxboot-theme-suse/usr/share/gfxboot-theme-suse/po/bootloader.pot
[12:22] <dpm> 2) debian/gfxboot-theme-sles/usr/share/gfxboot-theme-sles/po/bootloader.pot
[12:22] <dpm> 3) debian/gfxboot-theme-nld/usr/share/gfxboot-theme-nld/po/bootloader.pot
[12:22] <dpm> 4) debian/gfxboot-theme-zen/usr/share/gfxboot-theme-zen/po/bootloader.pot
[12:22] <dpm> 5) debian/gfxboot-theme-ubuntu/usr/share/gfxboot-theme-ubuntu/po/bootloader.pot
[12:22] <dpm> I guess I can approve 5) straight away, but I don't know what 1-4 are.
[12:23] <CIA-33> debian-installer: cjwatson * r1148 ubuntu/ (10 files in 3 dirs): Move to 2.6.31-10 kernels.
[12:24] <cjwatson> dpm: err, I *think* all of those should be blocked
[12:24] <cjwatson> let me check
[12:25] <dpm> ok good thing I asked :)
[12:25] <CIA-33> debian-installer: cjwatson * r1149 ubuntu/debian/changelog: releasing version 20081029ubuntu58
[12:26] <cjwatson> dpm: yeah, just block those; 1-4 are uninteresting to translate in Ubuntu in any event; 5 is already in LP, and that's just a build artifact or something
[12:27] <dpm> right, thanks
[12:29] <dpm> done, they are now blocked
[12:29] <dpm> There are also some additional templates, like the ones for ubiquity-slideshow-ubuntu Karmic, which I think I could safely approve, but I prefer double-checking:
[12:29] <dpm> po/firefox.html/template.pot
[12:29] <dpm> po/welcome.html/template.pot
[12:29] <dpm> ... etc.
[12:29] <dpm> (I've noticed translations are already set up in the upstream project at https://translations.launchpad.net/ubiquity-slideshow-ubuntu)
[12:42] <cjwatson> I don't know what those are; evand would know better
[12:43] <evand> they're the translations for the individual pages in the slideshow
[12:44] <dpm> yeah, I've noticed they're are the equivalent ones to those in the upstream project in LP, so I guess I can approve them?
[12:45] <dpm> have translations from the upstream project already been exported and put into the karmic package?
[12:46] <evand> please do
[12:48] <evand> pulling down a new tarball of translations from LP to commit to trunk now
[12:48] <dpm> great, thanks
[12:49] <dpm> I'll approve them now
[13:03] <dpm> approved. evand, have you considered automatically committing translations to a bzr branch in the upstream slideshow project -> http://blog.launchpad.net/translations/screencast-exporting-translations-to-a-bazaar-branch? It might save you manually downloading translations
[13:13] <evand> dpm: very cool, I'll look into it.  Thanks!
[13:24] <dpm> np
[13:24] <dpm> cjwatson: ok, before I go to lunch, here's what I think we can do. Let me know if it sounds ok, or if I'm talking rubbish. As you can see, step 4 is probably oversimplified:
[13:24] <dpm> 1) request export of the oem-config translations [installer team]
[13:24] <dpm> 2) request export of the ubiquity translations [installer team]
[13:24] <dpm> 3) request export of the (pre-split) debian-installer translations [installer team]
[13:24] <dpm> 4) merge those translations into debian/real-po/templates.pot [installer team]
[13:24] <dpm> 5) do a new package upload with the translation updates
[13:24] <dpm> 6) disable the 'ubiquity' template (po/ubiquity.pot) in LP [translations team]
[13:24] <dpm> 7) rename the 'debconf' template (po/real-po/templates.pot) to 'ubiquity' in LP  [translations team]
[13:34] <cjwatson> no, 5) is the oversimplified bit
[13:34] <cjwatson> we can't (well, won't) do this by way of a package upload
[13:34] <cjwatson> there's lots of translations there that I actively don't want to import into the package, but want to preserve in LP in case they're ever used in future
[13:34] <cjwatson> we've already imported the bits that we're happy to include in the package
[13:35] <cjwatson> why 7)? I chose that name kind of deliberately, to avoid conflicting with an existing template
[13:35] <cjwatson> I don't think there should be any need to rename it
[13:35] <cjwatson> oh and 6) is wrong and should not be done
[13:39] <rgreening> morning evand
[13:40] <evand> hiya
[13:43] <dpm> cjwatson: on 6) and 7) I thought the current po/ubiquity.pot messages would go to the po/real-po/templates.pot template, that's why. But you've now confirmed that that assumption was wrong, so 6) and 7) don't need to be done
[13:45] <cjwatson> po/ubiquity.pot is a couple of desktop file translations
[13:46] <cjwatson> I guess we could rename ubiquity/ubiquity -> ubiquity/desktop and ubiquity/debconf -> ubiquity/ubiquity
[13:46] <cjwatson> I don't know if that's worth it
[13:46] <cjwatson> for 5), I need to know how to upload the bits to LP in a way that produces the minimum possible loss of translation credit information
[13:46] <dpm> I think it would make it clearer
[13:48] <dpm> cjwatson: regarding the credits, I mentioned that on my e-mail. I spoke to danilo about this and he said that it would be difficult to do this throughh database queries, so we agreed that the best workaround is to simply ensure that at least the PO files have the Last-Translator field set
[13:50] <cjwatson> fine, but I can't do it by a package upload - I'll have to upload it through the API
[13:50] <cjwatson> (or similar)
[13:50] <cjwatson> I need help to determine the exact best way to do that upload
[13:51] <cjwatson> I already have lp:~jtv/lp-translations-tools/trunk checked out
[13:52] <cjwatson> are you saying that I should just do a msgmerge, fix up Last-Translator if necessary, and then use lp-translations-tools-upload in the most ordinary way?
[13:52] <cjwatson> if that's the case, I can handle that
[13:53] <dpm> Wait a second, I've got a question before (that might be beyond my knowledge): why can't you upload the translations through a package upload?
[13:54] <dpm> (and let me get danilo or jtv in here as well...)
[13:57] <dpm> cjwatson: sorry, you answered my question already in an earlier comment I missed
[13:59] <cjwatson> the installer is special
[13:59] <cjwatson> we only include translations for languages we're actually going to support; and we don't incorporate translations for strings that come from Debian, because that would put us in the position of having to mediate translation differences for 50-odd languages we don't speak every time we merge
[13:59] <cjwatson> that doesn't mean I want those translations to vanish from Debian, though
[14:00] <cjwatson> err - from Launchpad
[14:06] <dpm> ok, jtv seems to be away, but danilo is coming over after lunch later on to give a hand on this
[14:27] <rgreening> evand: did you get my messages from yesterday?
[14:42] <evand> rgreening: yeah, I'm on it
[14:52] <rgreening> cool. you da man
[14:52] <rgreening> evand: btw, you still marked away
[14:56] <evand> whoops
[14:56] <rgreening> hehe
[14:57] <rgreening> evand: I also need some help in getting translations working for the kde font-end and someone qualified to help with that and test it out. I'm no use when it comes to that.
[14:58] <evand> rgreening: I'm not sure how KDE/Qt handles translations, unfortunately
[14:58] <evand> err not familiar with*
[14:58] <rgreening> evand: I kown it can use the gettext/locale usbcreator for all the _('messages')
[14:59] <rgreening> which I have tried.... just need someone who can help test/debug what isn't working and how to get the kde UI translations in there as well...
[15:00] <rgreening> evand: any suggestions on who we may be able to hit up to assist?
[15:00] <evand> rgreening: jr would either know, or be able to point you at someone who does
[15:01] <danilos> dpm, cjwatson: hi
[15:01] <rgreening> hmm... I'm thinking the issue is a little different here, as we want to use the gettext from gtk version in the kde frontend and not strictly ki8ln translations from kde.
[15:02] <dpm> hey danilos, as I said, it's about http://irclogs.ubuntu.com/2009/09/09/%23ubuntu-installer.html#t13:24
[15:02] <DogWater> Man 8.10 goes ape with a 3420 chipset motherboard
[15:03] <dpm> Colin would like to know what the best way to upload those translations is
[15:04]  * danilos is reading...
[15:04] <evand> rgreening: well, it's standard gettext, it doesn't have any GTK dependencies, but perhaps I'm just being pedantic.
[15:05] <dpm> danilos: there's more discussion in the page before that link, but I think that's the relevant part
[15:08] <rgreening> evand: I think my confusion is in the ki8ln stuff in places (which I think I need to remove). And to ensure that the UI strings are loaded and translated somehow (which I am not sure I am doing correctly).
[15:09] <danilos> dpm, cjwatson: ok, so, what do you expect me to help out with? in general, we don't have an "upload" link for a sourcepackage, and lp-translations-tools can only upload directly to a potemplate; basically, if you need to set up new templates in a sourcepackage which is not part of sourcepackage, we have to do that through some trickery (set up an empty template somewhere else, and then move it to the sourcepackage: any rosetta admi
[15:09] <danilos> n can do that)
[15:10] <cjwatson> the templates already exist; we just need to plug in the translations
[15:10] <cjwatson> I just need advice on the best approach, I already have all the necessary technical privileges unless it actually involves database hacking :)
[15:10] <danilos> then you can just use lp-translations-tools to do the upload :)
[15:12] <danilos> cjwatson: I only see "help" and "debian-installer" on eg. https://translations.edge.launchpad.net/ubuntu/karmic/+source/debian-installer/
[15:13] <dpm> danilos: it's that one and https://translations.edge.launchpad.net/ubuntu/karmic/+source/ubiquity. Some of the d-i translations will go into the 'debconf' template
[15:13] <danilos> dpm: ok
[15:16] <danilos> cjwatson, dpm: so, if you worry about how to best reuse previous translations from one big template as done in Launchpad, I'd just upload all of them into corresponding templates using potemplate upload; Launchpad can take care of merging them properly, though if you upload the same big template in all of these, it will import them and mark them as "obsolete" (i.e. they will not be shown, but will be in the database and might be re
[15:16] <danilos> used once those messages are added)
[15:16] <danilos> ok, that second part was confusing
[15:16] <cjwatson> I certainly have no problem cutting it down to just the relevant msgids using msgmerge
[15:16] <danilos> i.e. if you've got one big debian-installer-de.po which is now split into 4 templates, you can upload it into each of the templates without changing it at all
[15:17] <cjwatson> so is that all I need to do? just upload the d-i po files into ubiquity and we're done?
[15:17] <danilos> cjwatson: right, that'd be much better, but in general, you should not worry about merging or anything, because LP is smart about it itself :)
[15:17] <danilos> cjwatson: as far as I can see, yes
[15:19] <cjwatson> ok, excellent! much easier than I thought. I'll get round to that soon
[15:21] <dpm> so I guess the question is answered, thanks a lot danilos!
[15:22] <dpm> cjwatson: one last thing, regarding the renaming of the ubiquity and debconf packages: 1) would it be possible to merge the ubiquity .desktop translations into the debconf template, so to have a single one? If not, as mentioned before I'd favour a rename. I think we can do that in LP without the need of packaging changes, simply renaming the template there. What would you think of ubiquity -> ubiquity-desktop, debconf -> ubiquity (a slight variatio
[15:22] <dpm> n of your earlier proposal)?
[15:22] <cjwatson> it's not possible to merge them
[15:22] <cjwatson> well, very painful anyway
[15:22] <dpm> ok
[15:22] <cjwatson> that's fine by me if you prefer those names
[15:22] <danilos> dpm: yw
[15:23] <cjwatson> can you do that nowish, before I do the uploads?
[15:23] <cjwatson> (which I won't do right now as I have to go out for a bit and then have a meeting)
[15:23] <dpm> yeah, I think they might be clearer for translators. Let me see if I can do the change in the next few minutes
[15:25] <DogWater> man, i hate new platforms
[15:25] <DogWater> intel has got to stop
[15:25] <DogWater> ;-)
[15:28] <dpm> cjwatson: ok, renaming done -> https://translations.launchpad.net/ubuntu/karmic/+source/ubiquity/
[15:58] <cjwatson> thanks
[17:18] <rgreening> evand: po/POTFILES.in does not contain ./bin/usb-creator-kde nor ./bin/usb-creator-gtk but should, correct? And the type: gettext/glade fpr usb-creator-kde.ui is likely not correct at all. Not sure what to do there... thoughts?
[17:26] <ilowe> I would like my package A to configure and install a package B; I don't want A to "depend" on B, since I won't be able to config B via A's installation if the order is "wrong"; my initial thought is to mark B for installation just after preseeding debconf with the values for B and then let apt-get manage the installation of B when it checks to make sure all marked packages are installed. Am I way off base with this strate
[17:29] <cjwatson> this isn't really the right channel ... but in general the only supported way for a package to request that another be installed is by means of the dependency relationship fields. dpkg is not re-entrant
[17:30] <cjwatson> if you try to mark the package for installation in one of A's maintainer scripts, then at best (!) it will only get installed on the *next* run of the package management system
[17:30] <cjwatson> which might be arbitrarily much later
=== dpm is now known as dpm-afk
[17:48] <ilowe> cjwatson: sorry and thanks for clearing that up
[17:50] <cjwatson> I'm not sure I quite understand your comment 'since I won't be able to config B via A's installation if the order is "wrong"'
[17:53] <ilowe> cjwatson: I mean, let's say I want to "preseed" debconf with the values to configure B. I want to do this setup during the installation of my package A. However, I want to make sure that once I'm done setting the values in debconf that B actually gets installed.
[17:54] <ilowe> cjwatson: If I put B in the Depends list for A, then it will get installed first, so I won't have a chance to modify the settings; hmm... should I be doing something like dpkg-reconfigure on B after fiddling it's config instead?
[17:56] <cjwatson> redesign :-)
[17:57] <cjwatson> it would be more usual for A to drop in a configuration file modifying B's behaviour (although not actually to change any of B's configuration files - that's a policy violation). This may require some cooperation from B
[17:57] <cjwatson> in general, preseeding is for administrators, not for packages
[17:57] <cjwatson> and so trying to do it in packages is probably doomed to frustration
[18:04] <ilowe> ech... I guess this square peg won't fit in this round hole.... redesign is starting to look better and better
=== mpt_ is now known as mpt
[18:45] <xivulon> cjwatson, did you manage to reproduce the grub2 issues?
[18:45] <cjwatson> sorry, no, I didn't get to it today
[18:45] <cjwatson> it's been an odd day, a lot of interruptions
[18:45] <xivulon> np, let me know if you think there is something I can help with
[19:50] <mtc> have got a question regarding the ubuntu "usb-creator" ... when creating a bootable usb drive, the application nicely asks how much user space is requested for data
[19:50] <mtc> how much is a good amount to reserve for the ubuntu operating system updates, on the usb drive?
[19:51] <mtc> would like to use the drive as an persistent installation, carrying it around on a keychain
=== dpm-afk is now known as dpm
[20:46] <mtc> looks like that casper-rw is problematic at large sizes anyway
[21:10] <CIA-33> usb-creator: rgreening * r171 trunk/ (5 files in 3 dirs):
[21:10] <CIA-33> usb-creator: * Fix Makefile to include ./bin/usb-creator-* for translations
[21:10] <CIA-33> usb-creator: * Update kde frontend bits to be more translatable (needs more work)
[21:10] <CIA-33> usb-creator: * Add the translation script (Messages.sh) for kde .pot
[21:10] <CIA-33> usb-creator:  (needs to be integrated somehow)
[21:22] <CIA-33> usb-creator: rgreening * r172 trunk/ (6 files in 5 dirs): * Bump version in setup.py, kde_about.py, usb-creator-gtk, and man to 0.2.6
[21:46] <CIA-33> usb-creator: rgreening * r173 trunk/Makefile: * Only the gtk ui is glade... fix sed to deal with that
[22:43] <CIA-33> casper: cjwatson * r684 trunk/ (7 files in 2 dirs): Upgrade to debhelper v7.
[22:52] <CIA-33> partman-auto-loop: cjwatson * r49 ubuntu/debian/ (di-numbers install install-rc changelog compat control rules): Upgrade to debhelper v7.
=== robbiew is now known as robbiew-afk