[00:24] <Muscovy> This may seem like a strange question, but how can I detect which languages the system uses?
[00:27] <kklimonda> Muscovy: checking locale settings?
[00:28] <Muscovy> How would I do that?
[00:30] <Bachstelze> Muscovy: define "the system" ;)
[00:30] <Bachstelze> each user can use a different locale using the LANG ev variable
[00:31] <Muscovy> I would say all user languages.
[00:32] <Muscovy> I'm trying to figure out how to make an installer download langpacks for all languages users use.
[00:33] <kklimonda> Muscovy: I don't think there is a way to detect a system-wide language (or language set by all users). All you can check is the language for the current user (or rather your application)
[00:33]  * Bachstelze nods
[00:33] <Muscovy> Hmm.
[00:34] <kklimonda> well, you could probably detect system-wide settings somehow but it won't help you in this case.
[00:34] <kklimonda> Can users choose any language they like, even if language packs for it are missing?
[00:34]  * kklimonda doesn't think so
[00:34] <Muscovy> We don't have a UI for that yet, but yes.
[00:35] <kklimonda> Muscovy: but it won't work without language packs so what's the point?
[00:35] <Muscovy> It's for the screenshots in the #ubuntu-tour.
[00:35] <Muscovy> Each pack will be about 15 MB.
[00:36] <Muscovy> No way we can stick them all together.
[00:36] <kklimonda> Muscovy: what you could do is create an application that, at the first login, launches and asks user to choose his language and then, using policy-kit and aptdaemon(?) installs all files.
[00:37] <Muscovy> We were thinking of automating the "install user's language". The tour itself knows how to find which language is currently in use.
[00:38] <kklimonda> how does it know that?
[00:38] <Muscovy> I'm not sure. I didn't code very much at all since most of it's GTK, which I don't know.
[00:38] <Muscovy> It's magic.
[00:39] <kklimonda> Muscovy: well, if it knows the language for current user it can install language packs.
[00:40] <Muscovy> kklimoda: the hope was it could get them all at once though.
[00:40] <Muscovy> The hope was looping it into the install to avoid the need to have admins do other languages or have a pack from every user.
[00:41] <Muscovy> But like I said, the average computer will use one language.
[02:26] <ScottK> All languages make updates take a long time when they issue language pack updates.
[03:02] <micahg> ScottK: BTW, I talked to spotter about the SRU for hebcal and I'll be taking care of it
[03:03] <ScottK> micahg: Cool.  Thanks.
[05:46] <jmarsden> I think the packaging of qtwebkit changed, or is being changed?  In particular, the header file QWebSettings used to be part of libqt4-dev, but in Maverick and Natty it is not there, it is in libqtwebit-dev instead.  But libqtwebkit-dev does not exist in Lucid.  I'd like a source package that can build in Lucid as well as Maverick and Natty... is there a clean solution to this?
[06:02] <micahg> jmarsden: libqtwebkit-dev | libqt4-dev
[06:02] <ebroder> micahg: that doesn't work
[06:02] <micahg> ebroder: why not?
[06:02] <ebroder> buildds will only ever use the first package in an |'d dependency
[06:03] <ebroder> it's to avoid inconsistencies in how a build runs
[06:03] <micahg> ebroder: I thought it was only broke if the dependency was versioned
[06:04] <jmarsden> I can try it and find out :)
[06:04] <ebroder> always a good plan! i could be wrong. i'm only positive about how sbuild handles this - other builders might act differently
[06:10] <micahg> ebroder: bug 594916
[06:28] <jmarsden> Hmm, libqt4-dev was already listed as a Build-Dep, so apparently it decided to use that, and so did not pull in libqtwebkit-dev .  So maybe I need to do  Build-Depends: ... libqt4-dev, libqtwebkit-dev | <random-unnecessary-package that exists in both Lucid and Maverick> ??
[06:29] <micahg> jmarsden: no, replace libqt4-dev with the line I gave you
[06:29] <jmarsden> micahg: But then on Maverick and Natty libqt4-dev won't be pulled in, will it?
[06:30] <micahg> jmarsden: it needs both?
[06:30] <jmarsden> I think so.  It is a QT4 app, I really dobt QWebSettings is the only qt4 header it uses :)
[06:31] <micahg> jmarsden: don't worry, libqtwebkit-dev will pull it in
[06:31] <jmarsden> Ah, OK.  That makes sense.  I'll try it.
[06:44] <micahg> hi fabrice_sp
[07:13] <fabrice_sp> Hi micahg. Congrats by the way! :-)
[07:13] <micahg> fabrice_sp: thanks
[08:08] <dholbach> good morning!
[08:24] <geser> good morning
[10:26] <cjwatson> ebroder: that's true in Debian, but the version of sbuild on the Ubuntu buildds intentionally relaxes that restriction in order that we can sync a package in main that does "Build-Depends: package-in-universe | virtual-provided-by-package-in-main" without modifications
[13:21] <philsf> hi, I'm going to make a package of a (perl) program I wrote, and will use dh-make-perl. I work in a local bzr branch, and sync the whole dir to all machines I use. I'm using dh-make-perl. What's the best practice for the workflow? Do I copy the revision I want to package to a new dir, and make the binary pkg there, or run dh-make-perl in the trunk dir, then revert the changes after packaging?
[13:21] <cjwatson> I'd make a branch for the packaging
[13:30] <philsf> is dh-make-perl supposed to be used for all releases, or just the initial packaging?
[13:32] <philsf> it has a 'refresh' mode, but it didn't append to debian/changelog, instead it created a new one
[13:46] <cjwatson> philsf: initial
[13:47] <cjwatson> well, it *claims* to be usable on an ongoing basis actually, but I must say I wouldn't
[13:47] <philsf> cjwatson, thanks, that clarifies a lot
[14:47] <bilalakhtar> angelabad: good work on that sync, I am sponsoring your merge now
[14:48] <bilalakhtar> test-building in my PPA
[14:50] <angelabad> bilalakhtar, ok! Thanks!
[14:50] <bilalakhtar> omg! vtk has loads of build-deps
[15:21] <stefanlsd> I have a dkms build failing with nothing useful in make.log, and when i run it manually from the directory, its fine. Any ideas?
[15:22] <ebroder> stefanlsd: is the command to build the module multiple things &&'d together, by any chance?
[15:27] <stefanlsd> ebroder: mm. not that i can see. Its a bunch of commands with ; seperating them
[15:27] <ebroder> stefanlsd: ok, close enough. are there parentheses around the group of commands?
[15:29] <ebroder> (i think you're running into bug #593509 i.e. debian bug 577972)
[15:32] <stefanlsd> ebroder: no parentheses. But yeah, def no error in log either. Strange that a manual build is fine. Seems like its just not detecting the exit status correctly
[15:32] <ebroder> no, dkms isn't handling multiple commands correctly. try adding parentheses
[15:32] <ebroder> you're only seeing the log of the last command in the set
[15:34] <stefanlsd> ebroder: ok. parentheses around all the commands right?
[15:34] <ebroder> right
[15:44] <bilalakhtar> angelabad: Sponsored, the test build took over an hour!
[15:46] <angelabad> bilalakhtar, ops! sorry I had a test build in my ppa
[15:46] <angelabad> https://edge.launchpad.net/~angelabad/+archive/maverick/+build/2040322
[15:46] <angelabad> thanks for sponsor me!
[15:48] <stefanlsd> ebroder: make.log is much beter now - http://paste.ubuntu.com/529405/   but it doesnt fail, although dkms reports Error!  Build of dahdi_dummy.ko failed for: 2.6.35-22-generic (x86_64)
[16:15] <micahg> ScottK: would I be able to backport thunderbird translations?  (each translation is a new binary which makes SRUing difficult, I plan to SRU them as well when we update Thunderbird, but not the newer languages, just updates)
[16:16] <ScottK> micahg: You should be able to SRU the new binaries for translation improvements.  We can backport if needed, but I think an SRU would be better if ubuntu-sru would take them.
[16:17] <micahg> ScottK: oh, ok, that's even better, I just remembered something about new binaries causing issues
[16:18] <ScottK> micahg: I'm not sure.  I'd ask pitti about it.
[16:38] <Kage[Work]> Got a quick packaging question..  So I work for my uni, and we use GroupWise here.  My department maintains our own minid server.  So, we have an .rpm of the GroupWise client, and using alien I converted it to a .deb.  I tried to extract everything and make a custom package out of it, but shlibs keep breaking (whereas leaving it alone as the .deb alien produces works fine).
[16:38] <Kage[Work]> So, my question is this: How can I place the .deb on our minid server without a .changes or .tar.gz ?
[16:40] <Kage[Work]> Wrong channel, perhaps?
[18:05] <highvoltage> I uploaded Acire to REVU: http://revu.ubuntuwire.com/p/acire
[18:06] <highvoltage> Lintian complains about my email address not being the same as in the maintainer field: http://revu.ubuntuwire.com/revu1-incoming/acire-1011101739/lintian
[18:06] <highvoltage> Is there something I should do about that, or is that normal in this case?
[18:08] <tumbleweed> highvoltage: hmm that warning makes no sense on ubuntu, but you should address the other two issues
[18:10] <highvoltage> tumbleweed: what should I do about that version number btw?
[18:11] <tumbleweed> highvoltage: do you want it to be a native package? I think it shouldn't be.
[18:11] <tumbleweed> highvoltage: which basically means you forgot to have a .orig.tar.gz before debuilding
[18:12] <highvoltage> tumbleweed: it comes from https://launchpad.net/~acire-team/+archive/acire-releases, so it didn't come from an upstream tarball, I haven't quite done it like this before so I'm a bit unsure
[18:12] <tumbleweed> highvoltage: use source format 3.0 (quilt) and it'll give you an error instead of just making a native package
[18:12] <highvoltage> tumbleweed: ok
[18:13] <tumbleweed> ok yes they don't have any release tarballs yet
[18:13] <tumbleweed> you can make one, or you can have a native package for now
[18:13]  * highvoltage thinks native package for now is better
[18:14] <highvoltage> tumbleweed: should I leave it then in the current source format or use 3.0 (native)?
[18:15] <tumbleweed> highvoltage: up to you, depends how much you want to get into maintaining it :)
[18:16] <highvoltage> tumbleweed: where does that leave me with the version number though?
[18:16] <tumbleweed> x-y is a numbering scheme used for non-native packages, y is the debian revision
[18:17] <stefanlsd> any dkms experts. dkms fails to build, but nothing in the log as to why - http://paste.ubuntu.com/529405/
[18:17] <highvoltage> tumbleweed: so I should go with 0.4.1?
[18:17]  * highvoltage notes that this is starting to look like an alternate ubuntu-za :)
[18:18] <stefanlsd> :)
[18:19] <tumbleweed> yeah sounds sane enough. (we'll get there :P I'm working on drubin)
[18:20] <tumbleweed> if it were a package I was maintaining, I'd probably go with 0.4.1~bzr83-0ubuntu1 and package it non-natively
[18:21] <highvoltage> tumbleweed: that actually sounds incredibly sane
[18:21] <ajmitch> morning
[18:21] <highvoltage> morning ajmitch
[18:22]  * ajmitch is here to make it less of an #ubuntu-za :P
[18:22] <highvoltage> ajmitch: that's ok, with your accent someone could mistake you for being from .za :p
[18:23] <ajmitch> haha
[22:02] <xteejx> How do I fix a patch if it says hunk failed?
[22:02] <xteejx> Can I just edit the patch and change the line numbers?
[22:03] <xteejx> Don't worry it worked
[22:50] <DktrKranz> bdrung: thanks
[22:51] <bdrung> DktrKranz: for what?
[22:52] <DktrKranz> reply to my comment about cacheviewer
[22:52] <bdrung> DktrKranz: bug number?
[22:53] <DktrKranz> no bug #, mail coming from ftpmaster
[22:54] <bdrung> aha, got it
[22:54] <ebroder> bdrung: speaking of comments, sorry about that dictionaries-common thing. that was embarrassingly sloppy
[22:54] <bdrung> DktrKranz: as a maintainer of mozilla-devscripts, i have to promote it's tools. :)
[22:55] <bdrung> ebroder: np - thanks to sponsor-patch it didn't took much time to detect it
[22:55] <DktrKranz> heh, I wasn't aware of it. I kept another package waiting to clarify that, I think my question is solved now :)
[22:56] <bdrung> DktrKranz: if there is a task that is too complicated - there is a tool from mozilla-devscript for it ;)
[22:56] <ajmitch> DktrKranz: many thanks to the ftp team for working through NEW again :)
[22:57] <DktrKranz> ajmitch: thanks, very appreciated :) (btw, going down 100 packages \o/)
[22:58]  * ajmitch will upload a few more then )
[22:59]  * DktrKranz turns off cronjobs
[22:59] <ajmitch> heh
[22:59]  * ajmitch wanders off for lunch
[23:02] <bdrung> DktrKranz: there is one multimedia package waiting in the NEW queue...
[23:04] <DktrKranz> bdrung: which one?
[23:04] <bdrung> DktrKranz: x264 :)
[23:05] <DktrKranz> being worked on it
[23:07] <bdrung> DktrKranz: i didn't expect that answer
[23:09] <sebner> bdrung: DktrKranz is the wizard of Debian NEW :D
[23:10] <Laney> just run `yes | process-new'
[23:10] <Laney> er, other way around
[23:11] <DktrKranz> Laney: simpler, dak process-new --automatic
[23:11] <DktrKranz> (real command!)
[23:12] <Laney> \o/
[23:12] <Laney> there must be overriding to do too though
[23:14] <DktrKranz> just buy me something like http://tinyurl.com/a9kgqj to be placed upon "A"
[23:18] <Laney> | yes A
[23:18] <Laney> $0, sold
[23:18]  * sebner pets Laney 
[23:19]  * Laney glomps sebner 
[23:20]  * sebner thinks fedora14 (in virtualbox) is too br0ken. updating to rawhide. Does that make sense? xD
[23:23] <bdrung> sebner: yes. i enable experimental if debian unstable is unstable :P
[23:23] <sebner> \o/
[23:40] <bdrung> DktrKranz: i looked at cacheviewer - it doesn't use xpi-{un,}pack, but it should (to get the .jar file extracted in the source tarball)
[23:41] <bdrung> DktrKranz: do you use suspicious-source?
[23:42] <DktrKranz> bdrung: no, we have another tool, but it's mostly license-based