[00:24] This may seem like a strange question, but how can I detect which languages the system uses? [00:27] Muscovy: checking locale settings? [00:28] How would I do that? [00:30] Muscovy: define "the system" ;) [00:30] each user can use a different locale using the LANG ev variable [00:31] I would say all user languages. [00:32] I'm trying to figure out how to make an installer download langpacks for all languages users use. [00:33] 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] Hmm. [00:34] well, you could probably detect system-wide settings somehow but it won't help you in this case. [00:34] Can users choose any language they like, even if language packs for it are missing? [00:34] * kklimonda doesn't think so [00:34] We don't have a UI for that yet, but yes. [00:35] Muscovy: but it won't work without language packs so what's the point? [00:35] It's for the screenshots in the #ubuntu-tour. [00:35] Each pack will be about 15 MB. [00:36] No way we can stick them all together. [00:36] 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] 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] how does it know that? [00:38] 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] It's magic. [00:39] Muscovy: well, if it knows the language for current user it can install language packs. [00:40] kklimoda: the hope was it could get them all at once though. [00:40] 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] But like I said, the average computer will use one language. [02:26] All languages make updates take a long time when they issue language pack updates. [03:02] ScottK: BTW, I talked to spotter about the SRU for hebcal and I'll be taking care of it [03:03] micahg: Cool. Thanks. [05:46] 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] jmarsden: libqtwebkit-dev | libqt4-dev [06:02] micahg: that doesn't work [06:02] ebroder: why not? [06:02] buildds will only ever use the first package in an |'d dependency [06:03] it's to avoid inconsistencies in how a build runs [06:03] ebroder: I thought it was only broke if the dependency was versioned [06:04] I can try it and find out :) [06:04] always a good plan! i could be wrong. i'm only positive about how sbuild handles this - other builders might act differently [06:10] ebroder: bug 594916 [06:10] Launchpad bug 594916 in Launchpad Auto Build System "buildd doesn't correctly check versioned ORed build-dependencies" [Medium,Triaged] https://launchpad.net/bugs/594916 === kees___ is now known as kees [06:28] 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 | ?? [06:29] jmarsden: no, replace libqt4-dev with the line I gave you [06:29] micahg: But then on Maverick and Natty libqt4-dev won't be pulled in, will it? [06:30] jmarsden: it needs both? [06:30] I think so. It is a QT4 app, I really dobt QWebSettings is the only qt4 header it uses :) [06:31] jmarsden: don't worry, libqtwebkit-dev will pull it in [06:31] Ah, OK. That makes sense. I'll try it. [06:44] hi fabrice_sp === fabo_ is now known as fabo [07:13] Hi micahg. Congrats by the way! :-) [07:13] fabrice_sp: thanks === Tm_K is now known as Tm_T === Adri2000_ is now known as Adri2000 [08:08] good morning! [08:24] good morning === nenolod_ is now known as nenolod [10:26] 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 === bilalakhtar changed the topic of #ubuntu-motu to: Archive: Open | maverick-proposed is now unfrozen, time to work on SRUs! | Want to get involved with the MOTU? https://wiki.ubuntu.com/MOTU/Contributing | Sponsor queue: http://is.gd/2y76G | http://qa.ubuntuwire.com/ftbfs | http://people.canonical.com/~ubuntu-archive/NBS | http://qa.ubuntuwire.com/bugs/rcbugs/ | Congratulations to new MOTU: micahg. === yofel_ is now known as yofel [13:21] 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] I'd make a branch for the packaging [13:30] is dh-make-perl supposed to be used for all releases, or just the initial packaging? [13:32] it has a 'refresh' mode, but it didn't append to debian/changelog, instead it created a new one [13:46] philsf: initial [13:47] well, it *claims* to be usable on an ongoing basis actually, but I must say I wouldn't [13:47] cjwatson, thanks, that clarifies a lot [14:47] angelabad: good work on that sync, I am sponsoring your merge now [14:48] test-building in my PPA [14:50] bilalakhtar, ok! Thanks! [14:50] omg! vtk has loads of build-deps === virtuald_ is now known as virtuald === achiang` is now known as achiang === bigon is now known as fred2kboulot_ === fred2kboulot_ is now known as bigon [15:21] 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] stefanlsd: is the command to build the module multiple things &&'d together, by any chance? [15:27] ebroder: mm. not that i can see. Its a bunch of commands with ; seperating them [15:27] stefanlsd: ok, close enough. are there parentheses around the group of commands? === RainCT_ is now known as RainCT [15:29] (i think you're running into bug #593509 i.e. debian bug 577972) [15:29] Launchpad bug 593509 in dkms (Debian) "openafs-modules-dkms leaves ~empty make.log on failing builds" [Unknown,New] https://launchpad.net/bugs/593509 [15:29] Debian bug 577972 in dkms "dkms: unclear diagnostics on build failure" [Normal,Open] http://bugs.debian.org/577972 [15:32] 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] no, dkms isn't handling multiple commands correctly. try adding parentheses [15:32] you're only seeing the log of the last command in the set [15:34] ebroder: ok. parentheses around all the commands right? [15:34] right === bilalakhtar_ is now known as bilalakhtar [15:44] angelabad: Sponsored, the test build took over an hour! [15:46] bilalakhtar, ops! sorry I had a test build in my ppa [15:46] https://edge.launchpad.net/~angelabad/+archive/maverick/+build/2040322 [15:46] thanks for sponsor me! === ssweeny_ is now known as ssweeny [15:48] 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) === hannesw_ is now known as hannesw [16:15] 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] 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] ScottK: oh, ok, that's even better, I just remembered something about new binaries causing issues [16:18] micahg: I'm not sure. I'd ask pitti about it. [16:38] 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] So, my question is this: How can I place the .deb on our minid server without a .changes or .tar.gz ? [16:40] Wrong channel, perhaps? === zul_ is now known as zul === genupulas is now known as rajasekher === paul__ is now known as Elbrus [18:05] I uploaded Acire to REVU: http://revu.ubuntuwire.com/p/acire [18:06] 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] Is there something I should do about that, or is that normal in this case? [18:08] highvoltage: hmm that warning makes no sense on ubuntu, but you should address the other two issues [18:10] tumbleweed: what should I do about that version number btw? [18:11] highvoltage: do you want it to be a native package? I think it shouldn't be. [18:11] highvoltage: which basically means you forgot to have a .orig.tar.gz before debuilding [18:12] 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] highvoltage: use source format 3.0 (quilt) and it'll give you an error instead of just making a native package [18:12] tumbleweed: ok [18:13] ok yes they don't have any release tarballs yet [18:13] 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] tumbleweed: should I leave it then in the current source format or use 3.0 (native)? [18:15] highvoltage: up to you, depends how much you want to get into maintaining it :) [18:16] tumbleweed: where does that leave me with the version number though? [18:16] x-y is a numbering scheme used for non-native packages, y is the debian revision [18:17] any dkms experts. dkms fails to build, but nothing in the log as to why - http://paste.ubuntu.com/529405/ [18:17] 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] :) [18:19] yeah sounds sane enough. (we'll get there :P I'm working on drubin) [18:20] 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] tumbleweed: that actually sounds incredibly sane [18:21] morning [18:21] morning ajmitch [18:22] * ajmitch is here to make it less of an #ubuntu-za :P [18:22] ajmitch: that's ok, with your accent someone could mistake you for being from .za :p [18:23] haha [22:02] How do I fix a patch if it says hunk failed? [22:02] Can I just edit the patch and change the line numbers? [22:03] Don't worry it worked === Zhenech_ is now known as Zhenech === dapal is now known as [dapal] [22:50] bdrung: thanks [22:51] DktrKranz: for what? [22:52] reply to my comment about cacheviewer [22:52] DktrKranz: bug number? [22:53] no bug #, mail coming from ftpmaster [22:54] aha, got it [22:54] bdrung: speaking of comments, sorry about that dictionaries-common thing. that was embarrassingly sloppy [22:54] DktrKranz: as a maintainer of mozilla-devscripts, i have to promote it's tools. :) [22:55] ebroder: np - thanks to sponsor-patch it didn't took much time to detect it [22:55] heh, I wasn't aware of it. I kept another package waiting to clarify that, I think my question is solved now :) [22:56] DktrKranz: if there is a task that is too complicated - there is a tool from mozilla-devscript for it ;) [22:56] DktrKranz: many thanks to the ftp team for working through NEW again :) [22:57] 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] heh [22:59] * ajmitch wanders off for lunch [23:02] DktrKranz: there is one multimedia package waiting in the NEW queue... [23:04] bdrung: which one? [23:04] DktrKranz: x264 :) [23:05] being worked on it [23:07] DktrKranz: i didn't expect that answer [23:09] bdrung: DktrKranz is the wizard of Debian NEW :D [23:10] just run `yes | process-new' [23:10] er, other way around [23:11] Laney: simpler, dak process-new --automatic [23:11] (real command!) [23:12] \o/ [23:12] there must be overriding to do too though [23:14] just buy me something like http://tinyurl.com/a9kgqj to be placed upon "A" [23:18] | yes A [23:18] $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] sebner: yes. i enable experimental if debian unstable is unstable :P [23:23] \o/ [23:40] 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] DktrKranz: do you use suspicious-source? === hannesw_ is now known as hannesw [23:42] bdrung: no, we have another tool, but it's mostly license-based