[01:49] <keffie_jayx> hey guys, I have a little issue with locales. upstream has moved locales to a new folder and now running the package sets it to the base langauge always.  however if I do LANG=EN  fr example I get the app in the correct language
[01:55] <keffie_jayx> http://pastebin.ubuntu.com/452710/
[03:52] <ramiro> hi. where can I find the documentation of what variables I can expect to be set for debian/rules when dpkg-buildpackage is called?
[04:00] <RAOF> ramiro: You can't really expect any environment variables to be set; debian/rules is not guaranteed to be called by dpkg-buildpackage (although it will be almost all the time).
[04:06] <ramiro> RAOF: ok, that's what I thought. I found some documentation at http://man.cx/dpkg-buildpackage%281%29 that lists a few env vars.
[04:06] <ramiro> and is there a non-hackish way (through the dpkg- tools) to determine what host system I'm building with and for (hackish being calling uname and gcc -dumpmachine).
[04:07] <RAOF> dpkg-architecture
[04:08] <RAOF> It doesn't export the variables itself, but it provides all the host information you'll need.
[04:09] <ramiro> thank you
[06:34] <kaushal> hi
[06:37] <kaushal> is there a mailing lits for this channel ?
[06:37] <kaushal> list*
[06:37] <micahg> kaushal: there is a mailing list for MOTU
[06:37] <kaushal> I have a particular issue
[06:38] <kaushal> shall i post the thread ?
[06:38] <micahg> kaushal: what type of issue?
[06:40] <kaushal> https://lists.ubuntu.com/archives/ubuntu-server/2010-June/004345.html
[06:40] <micahg> kaushal: #ubuntu-server is probably the best place
[06:41] <kaushal> micahg: i did that already
[06:42] <micahg> kaushal: this channel is for packaging related issues, not support, also you posted on the weekend, you might want to see if you get some results Monday morning
[06:43] <micahg> kaushal: I'd suggest trying the #ubuntu-server channel in about 9 hours
[06:43] <kaushal> micahg: ok
[06:44] <micahg> kaushal: maybe 8 hours
[06:46] <kaushal> micahg: can i findout the package maintainer
[06:46] <micahg> kaushal: In Ubuntu, we generally don't have maintainers
[06:47] <micahg> kaushal: it's in universe, so MOTU is responsible for packaging
[06:47] <dholbach> good morning
[06:50] <micahg> kaushal: but aside from one upload for hardy, it's been sync'd from Debian
[06:51] <micahg> kaushal: BTW, there's an update in hardy-updates for your package
[06:54] <kaushal> micahg: are you talking about ocsinventory-agent ?
[06:54] <micahg> kaushal: yes
[06:55] <kaushal> can i know the details ?
[06:55] <micahg> kaushal: https://launchpad.net/ubuntu/+source/ocsinventory-agent/1:0.0.8-1ubuntu0.1
[06:57] <kaushal> micahg: how do i install it
[06:58] <kaushal> i did apt-get update and then apt-get install ocs.....
[06:58] <micahg> kaushal: you have to enable hardy-updates
[06:58] <micahg> someone in #ubuntu can help with that
[07:07] <kaushal> micahg: Thanks it worked now
[07:07] <micahg> kaushal: good luck
[09:27] <Rhonda> http://www.sinfest.net/archive_page.php?comicID=3574 - wtf?
[09:27] <Rhonda> Can someone explain that one to me? :)
[09:28] <directhex> http://www.urbandictionary.com/define.php?term=bro
[09:30] <Rhonda> I know the slang term bro for brother, but I still don't get it.
[09:31] <Rhonda> The ubuntu reference is what I'm puzzled about.
[09:45] <didrocks> hyperair: hey, jcastro told me you have a branch for hal-free banshee, do you think it's in a state that can be integrated to maverick?
[09:45] <hyperair> didrocks: i haven't actually tried it yet. it's still rather experimental, or so i have heard.
[09:46] <didrocks> hyperair: the hal support is only for ipod or for all hw?
[09:46] <hyperair> didrocks: all hw.
[09:46] <hyperair> didrocks: if i'm not mistaken, that hal-free banshee branch will deprecate ipod-sharp and podsleuth, in favour of libgpod
[09:47] <didrocks> hyperair: that would rock :) do you know who I should contact about it to see if we can integrated and leverage some tests? (unfortunately, I don't have enough upstream knowledge to hack on it there)
[09:47] <hyperair> didrocks: lemme dig through my mail
[09:48] <didrocks> (also, I don't see the branch there: http://git.gnome.org/browse/banshee/refs/heads)
[09:48] <didrocks> thanks hyperair :)
[09:48] <hyperair> =)
[09:48] <RAOF> hyperair: Really?  I didn't think the hal-free banshee was particularly related to the libgpod transition?
[09:48] <hyperair> RAOF: it wasn't?
[09:48] <hyperair> RAOF: podsleuth isn't going to transition to hal-freedom anytime soon.
[09:49] <RAOF> But there still aren't any C# bindings for libgpod, are there?
[09:49] <Laney> didrocks: lamalex was working on it, its probably on gitorious
[09:49] <RAOF> And the udev-backed Banshee branch is available _now_ (and may even work)
[09:50] <didrocks> RAOF: do you have an url please? I want to put the crack on maverick now :)
[09:52] <didrocks> Laney: hum, don't find it in gitorious (should be there, I guess: http://gitorious.org/banshee/mainline)
[09:52] <Laney> I suggest you have a word with lamalex first
[09:52] <Laney> It's probably this http://gitorious.org/~lamalex/banshee/lamalex-udev or one of the clones/branches
[09:53] <didrocks> Laney: yeah, google was just my friend :) not sure if that's what RAOF was talking about
[09:54] <didrocks> I'll email him now
[09:55] <hyperair> RAOF: the libgpod C# bindings are being worked on afaik
[09:55] <Laney> he hangs around in #banshee as well
[09:55] <Laney> (just not atm)
[09:56] <didrocks> Laney: ok, I'll try to ping him when he's there, I wasn't sure he was hanging on IRC
[09:56] <didrocks> hyperair: Laney: thanks!
[09:56] <Laney> no worries
[09:57] <directhex> he's on yank time, so try again when yanks aren't sleeping
[09:58] <hyperair> didrocks: http://old.nabble.com/iPhone-Support-in-Banshee-tt23116289.html#a28873202
[10:02] <hyperair> didrocks: ping alan on #banshee as well
[10:02] <hyperair> (he's also not around currently)
[10:02] <directhex> he's on ireland time, so should be about
[10:03] <didrocks> hyperair: oh sweet, will do, thanks
[10:04] <hyperair> http://gitorious.org/~alanmcgovern/banshee/banshee-iphone <-- this looks like a clone of lamalex's branch though
[10:04] <RAOF> Yeah, it is.
[10:04] <directhex> he had it working
[10:04] <RAOF> Sorry about that, X freeze.
[10:04] <directhex> he was showing demos
[10:14] <didrocks> directhex: really? Hum, can be interesting to include it for alpha2 then
[10:26] <hyperair> the e-mail mentioned it should be upstreamed in a week or two (from that date, that should be around now, or next week)
[10:32] <directhex> alan just materialized FYI
 If he is, tell him to keep an eye on: http://gitorious.org/~alanmcgovern/banshee/banshee-iphone
 i cloned yesterday and will start pushing my work to there this week
 once everything is good to go, i'll push my changes to lamalexs branch
 and once his changes are all good to go, they'll be pushed to banshee
[11:42] <keffie_jayx> hey all, I just addd a patch system to a package, after setting up the patch, is there something I should add to debian/rules for it to be applied during the build of the deb file?
[11:56] <keffie_jayx> I fund what I was looking for reading more carefully the docs
[15:51] <sbasuita> What's the simplest/cleanest way to get cdbs to run autoreconf -fi (yes, I know it should be done upstream ;P)
[17:34] <statik> scottk: i will take a look at revu and delete anything i have left in there (and possibly move it to DPMT instead)
[17:35] <ScottK> statik: Thanks.  DPMT would be good.
[18:27] <dobey> hi fabrice_sp :)
[18:28] <dobey> fabrice_sp: good news. mocker 1.0 was relased yesterday :P
[18:31] <fabrice_sp> dobey, you was waiting for me :-D
[18:31] <fabrice_sp> so the watch file should work, right?
[18:34] <dobey> fabrice_sp: hehe. i just switched channels and saw you come in. the watch file does work now. i ran uscan and it downloaded the new tarball :P
[18:35] <dobey> fabrice_sp: but the license changed, and lots of bugs were fixed. there's only 1 open on mocker now. so i'm making the deb for 1.0
[18:35] <fabrice_sp> dobey, cool
[18:35] <fabrice_sp> ping me when you get the package in a good shape, and I'll ave a look
[18:36] <fabrice_sp> what is the new license?
[18:36] <dobey> and i'm going to fix it to run tests during the build too
[18:36] <dobey> BSD
[18:36] <fabrice_sp> ok
[18:36] <fabrice_sp> good
[18:36] <fabrice_sp> by the way, it's python, riht?
[18:38] <dobey> yes
[18:41] <dobey> fabrice_sp: alright, just did the dput to revu for it :)
[18:44] <fabrice_sp> did you try to ocntact debian-python team?
[18:45]  * fabrice_sp don't remember if he already tried to send you there .-)
[18:48] <shadeslayer_> tumbleweed: poke :)
[18:50] <dobey> fabrice_sp: i haven't, because as i said, just trying to have it packaged in ubuntu, so we can rely on the package rather than copying mocker.py across all the ubuntu one projects where we use it (and the landscape/launchpad guys also want it), and in order to have it packaged, and to run tests in our package builds, it would need to be in ubuntu, rather than just a PPA
[18:50] <NorthernLights> Hi all
[18:50] <dobey> and upstream would prefer not to have it packaged at all, but i bugged him enough to reach a compromise in that regard :)
[18:51] <tumbleweed> shadeslayer_: yes?
[18:51] <shadeslayer_> tumbleweed: ah yes,in this : http://revu.ubuntuwire.com/details.py?upid=8319
[18:51] <shadeslayer_> tumbleweed: do i add a debian/watch or modify debian/rules?
[18:52] <tumbleweed> we might as well move this to PM
[18:52] <shadeslayer_> tumbleweed: sure
[18:52] <dobey> hi NorthernLights
[18:52] <NorthernLights> Hola
[18:53] <ScottK> tumbleweed: It's better to keep technical discussions in the channel so bystanders can learn.
[18:53] <NorthernLights> Any answer about the Original-Maintainer thingy?
[18:53] <dobey> NorthernLights: i didn't ask, but my comment on revu was based on what the FAQ says on the wiki about it :)
[18:53] <NorthernLights> oh
[18:53] <tumbleweed> ScottK: ok, sure. but they can get long and noisy :)
[18:53] <NorthernLights> i guess you're right
[18:53]  * NorthernLights is still tickled...
[18:53] <ScottK> tumbleweed: I think it's fine.
[18:53] <NorthernLights> Hola MOTU!
[18:54] <tumbleweed> in that case, shadeslayer_: both. example: http://svn.debian.org/viewsvn/python-modules/packages/configobj/trunk/debian/rules?revision=12242&view=markup
[18:54] <NorthernLights> Must new Ubuntu packages debian/control file have a XSBC-Original-Maintainer field?
[18:54] <ScottK> tumbleweed: Not that I particularly worry with you, but there have been problems in the past with bad advice given in PM.  If it's in public, QA can happen real time.
[18:55] <ScottK> NorthernLights: No, it's not absolutely required, but there will be warnings as a result, so generally it's better.
[18:55] <tumbleweed> ScottK: yeah, agreed.
[18:55] <NorthernLights> Tx ScottK
[18:55] <shadeslayer_> tumbleweed: if you can walk me through those lines please :)
[18:56] <shadeslayer_> tumbleweed: ive understood the 3rd line of get-orig-source :P
[18:57] <tumbleweed> shadeslayer_: so, it's all executed as one sh command (that's why we set -e, to exit or errors)
[18:57] <shadeslayer_> bah.. ive understood all of it except line 1 and 2
[18:57] <tumbleweed> VER uses dpkg-parsechangelog to find what the current version of the source package is and store it in VER
[18:57] <shadeslayer_> tumbleweed: is that a standard line used everywhere?
[18:58] <shadeslayer_> like suppose can i use it for my package?
[18:58] <tumbleweed> shadeslayer_: no I don't think there are any standards to this kind of thing, but it's a nice way to do it
[18:58] <tumbleweed> this example actually gets us a zip file which then gets repacked as .tar.gz - let me see if I can find a simpler examlpe
[18:59] <shadeslayer_> tumbleweed: ok one more thing,where does it store the URL part? the actual URL it has to download?
[18:59] <tumbleweed> that comes from debian/watch
[18:59] <shadeslayer_> ahh..
[18:59] <tumbleweed> which also has a little magic: http://svn.debian.org/viewsvn/python-modules/packages/configobj/trunk/debian/watch?revision=12242&view=markup
[19:02] <tumbleweed> shadeslayer_: ok, here's a simpler one: http://svn.debian.org/viewsvn/python-modules/packages/pyfiglet/trunk/debian/rules
[19:04] <shadeslayer_> tumbleweed: ah ok,i understand...
[19:04] <shadeslayer_> i need spend a little more time reading about sed tho :P
[19:04] <shadeslayer_> tumbleweed: and the watch file..
[19:04] <shadeslayer_> whats : opts=dversionmangle=s/\+ds// \
[19:05] <tumbleweed> so, our version has +ds at the end, but upstream doesn't
[19:05] <tumbleweed> that says remove +ds from the version
[19:05] <shadeslayer_> ah...
[19:06] <tumbleweed> the sed was also doing that, and stripping the "Version: " a the beginning
[19:06] <tumbleweed> [^+]+ means "everything until you reach a +"
[19:07] <NorthernLights> ^.*\+
[19:08] <shadeslayer_> tumbleweed: so "Version: " is like the string or a number,like 1.0.0 ?
[19:08] <tumbleweed> NorthernLights: * is greedy, so it'll catch everything util the last +
[19:08] <tumbleweed> shadeslayer_: run dpkg-parsechangelog and you'll see
[19:09] <shadeslayer_> tumbleweed: on the dsc file?
[19:09] <tumbleweed> just in your source
[19:09] <shadeslayer_> Ohhhh
[19:10] <NorthernLights> right tumbleweed
[19:10] <NorthernLights> but are you sure ^+ means anything?
[19:11] <tumbleweed> NorthernLights: when a [] starts with a ^ it means anything except what's listed
[19:12] <NorthernLights> oh i didn't know that, thanks
[19:27]  * NorthernLights is taking advantage of a pause in the discussion
[19:27] <NorthernLights> *inhales... exhales...
[19:28] <NorthernLights> Hey MOTUs! Wanna review a great package? Easy and quick! Nice upstream software! http://revu.ubuntuwire.com/p/synergy-plus ! Yeah!
[19:29] <shadeslayer_> hehe :D
[19:43] <shadeslayer> ok so i have this lintian warning : W: qipmsg source: dh-clean-k-is-deprecated
[19:44] <shadeslayer> but when i replace dh_clean -k with [ ! -f Makefile ] || $(MAKE) distclean,the package fails to build
[19:45] <sbasuita> shadeslayer: you're meant to use dh_prep instead
[19:45] <shadeslayer> ok wait... wth its building now :P
[19:45] <shadeslayer> sbasuita: ok.. .so use dh_prep now?
[19:46] <fabrice_sp> dobey, in case you're still here: you should run update-maintainer
[19:46] <shadeslayer> sbasuita: ok thanks
[19:46] <sbasuita> shadeslayer: i just googled and found http://lintian.debian.org/tags/dh-clean-k-is-deprecated.html ;)
[19:46] <fabrice_sp> (It seems I missed it before)
[19:46] <shadeslayer> btw to update my revu upload,what should i do? post debdiff?
[19:46] <dobey> fabrice_sp: what does that do?
[19:46] <shadeslayer> sbasuita: yes i found that too,but lintian says otherwise ;)
[19:47] <sbasuita> shadeslayer: what does it say?
[19:48] <shadeslayer> sbasuita: http://shadeslayer.pastebin.com/HRWJWrAz
[19:48] <fabrice_sp> dobey, update the maintainer field to the latest value, and put your name in XSBC-original-maintainer
[19:48] <dobey> fabrice_sp: haha
[19:48] <dobey> [dobey@lunatari:mocker]: update-maintainer --help
[19:48] <dobey> Maintainer email is set to an @ubuntu.com address - doing nothing.
[19:48] <fabrice_sp> argh
[19:49] <dobey> fabrice_sp: should it be something else for some reason? i will be maintaining it
[19:49] <fabrice_sp> dobey, the correct value is "Ubuntu Developers<EMAIL_ADDRESS>[19:50] <NorthernLights> dobey, :p
[19:50] <fabrice_sp> put yourself as original-maintainer
[19:50] <sbasuita> shadeslayer: dh_clean and make distclean do two separate jobs
[19:50] <dobey> fabrice_sp: fix the FAQ :)
[19:50] <fabrice_sp> and after uploaded, subscribe to the bug reports
[19:50] <fabrice_sp> which FAQ?
[19:50] <dobey> https://wiki.ubuntu.com/UbuntuDevelopment/FAQ#What%20does%20XSBC-Original-Maintainer%20mean?
[19:50] <sbasuita> shadeslayer: you'll need both
[19:51] <fabrice_sp> dobey, what should be fixed?
[19:52] <fabrice_sp> Sorry, but it seems correct with a quick read :-)
[19:53] <dobey> fabrice_sp: that entry implies that Original-Maintainer should match the previous value of Maintainer, when a package is changed in Ubuntu. It doesn't say new packages directly in Ubuntu should have the maintainer set to Ubuntu Developers and Original-Maintainer set. it implies that is only for pre-existing package being changed in Ubuntu
[19:53] <dobey> and there is no preexisting package being changed in ubuntu here
[19:55] <fabrice_sp> dobey, well, I'm sure that there is some wiki page that says that the maintainer field sohuld be set to Ubuntu Developers<EMAIL_ADDRESS>for ubuntu's package
[19:55] <fabrice_sp> :-)
[19:56] <fabrice_sp> dobey, https://wiki.ubuntu.com/DebianMaintainerField
[19:56] <NorthernLights> How about https://wiki.ubuntu.com/PackagingGuide/Complete#control ?
[19:57] <NorthernLights> "In Ubuntu we set the Maintainer field to a general address because anyone can change any package (this differs from Debian where changing packages is usually restricted to an individual or a team).
[19:57] <NorthernLights> Edit control using the information above (making sure to provide your information for the XSBC-Original-Maintainer field)."
[19:58] <dobey> rfabok, so it should be set to Ubuntu Developers, and Original-Maintainer not set at all
[19:58] <dobey> err
[19:58] <dobey> wtf
[19:59] <dobey> i typed fab<tab> and got rfabok?
[19:59]  * dobey pokes irssi with a stick
[19:59] <dobey> fabrice_sp: ok, so it should be set to Ubuntu Developers, and Original-Maintainer not set at all
[19:59] <dobey> no?
[19:59] <fabrice_sp> dobey, you can put yourself as xsbc-original-maitainer
[20:03] <dobey> all these pages seem to say something just slightly different :-/
[20:09] <dobey> fabrice_sp: ok, just dput another upload with that change
[20:10] <fabrice_sp> dobey, ok. I'll download it in a bit
[20:15] <fabrice_sp> dobey, my point is that if you had uploaded it to Debian, your name would be there, so it follow the same. If you check dvdstyler, you'll se my name there :-)
[20:15] <fabrice_sp> (and it's a pure ubuntu package)
[20:16] <dobey> fabrice_sp: if i had uploaded it to debian, and Maintainer includes @ubuntu.com, the wiki page states it shouldn't change, anyway :)
[20:16] <fabrice_sp> well, I would had updated it :-)
[20:17] <fabrice_sp> as maintenance in Ubuntu is Team based
[20:19] <gubatron> Hi, I'm a member of the FrostWire team, we've finished packing a frostwire source package as requested here for inclusion to Ubuntu repo https://bugs.launchpad.net/debian/+bug/94011 - They told me to come here for help to see what's needed to include FrostWire as part of the repo.
[20:19] <dobey> fabrice_sp: well, if i'd uploaded to debian, there would be no need to maintain it in ubuntu really. would just need it synced, and then approved for MIR later i guess
[20:20] <fabrice_sp> dobey, right: in a sync, the maintainer won't be hcanged
[20:21] <tumbleweed> fabrice_sp: um, I thought it was, during build
[20:22] <fabrice_sp> tumbleweed, let me check, but source isn't
[20:22] <tumbleweed> yeah, source isn't, binary is
[20:24] <fabrice_sp> tumbleweed, right
[20:24] <fabrice_sp> I've just with one package and source is still Debian maintainer, but binary is updated to Ubuntu Developers
[20:33] <fabrice_sp> I didn't know that. Thanks tumbleweed !
[20:43] <dobey> fabrice_sp: do you need to re-advoacate for the new upload?
[20:44] <fabrice_sp> dobey, yep
[20:44] <fabrice_sp> That's what I was doing :-)
[20:45] <fabrice_sp> do you know if the BSD license file is copied in some place in the system? (like the GPL one)
[20:45] <tumbleweed> the BSD license is almost always modified by the user
[20:45] <dobey> don't think it is
[20:45] <fabrice_sp> ok
[20:46] <tumbleweed> /usr/share/common-licenses/BSD
[20:46] <dobey> oh it is
[20:46] <tumbleweed> but watch out, people change "the name of the University"
[20:46] <dobey> but that's broken
[20:47] <dobey> because everyone doesn't assign copyright to the Regents of the University of Berkeley
[20:47] <dobey> so linking to that would imply the uni owns the copyright
[20:47] <tumbleweed> something like that
[20:59] <shadeslayer_> tumbleweed: my new rules file : http://shadeslayer.pastebin.com/R5ZmbPzZ
[20:59] <shadeslayer_> still playing with it tho...
[21:00] <shadeslayer_> line 26 should be dh_prep... but its not working with that
[21:01] <tumbleweed> shadeslayer_: I doubt your package is called configobj :)
[21:01] <shadeslayer_> ><
[21:01] <shadeslayer_> corrected :)
[21:02] <shadeslayer_> tumbleweed: ok what do you think of line 26? lintian complains of using dh_prep
[21:02] <shadeslayer_> but when i use it package FTBFS
[21:02] <tumbleweed> why would you clean inbetween build and install?
[21:03] <dobey> fabrice_sp: hrmm. was that comment supposed to end immediately after "another" ? or did it get chopped off? (there's no period)
[21:03] <tumbleweed> oh -k
[21:03] <shadeslayer_> :)
[21:12] <tumbleweed> shadeslayer_: so, what's the problem with dh_prep?
[21:13] <shadeslayer_> tumbleweed: http://shadeslayer.pastebin.com/4zEsfjBP
[21:13] <shadeslayer_> causes FTBFS cuz im not using it properly :P
[21:13] <fabrice_sp> dobey, it was supposed to end with "sponsor."
[21:13] <shadeslayer_> tumbleweed: http://pastebin.com/Nwcrg0tu
[21:13] <fabrice_sp> :-)
[21:14] <shadeslayer_> tumbleweed: i moved dh_prep to the clean part
[21:14] <dobey> fabrice_sp: ok
[21:14] <dobey> who wants to sponsor my package and upload it to universe? :)
[21:14] <tumbleweed> shadeslayer_: why? why not replace dh_clean -k with dh_prep
[21:14] <shadeslayer_> tumbleweed: same issue
[21:15] <shadeslayer_> causes FTBFS
[21:15] <tumbleweed> what fails?
[21:15] <shadeslayer_> tumbleweed: make[1]: *** No rule to make target `packages/qipmsg-1.0.0.orig/debian/qipmsg'.  Stop.
[21:18] <tumbleweed> shadeslayer_: works fine for me, as long as you "[ ! -f src/Makefile ] || $(MAKE) clean"
[21:18] <shadeslayer_> aha!
[21:19] <shadeslayer_> lets see what happens now..
[21:20] <shadeslayer_> tumbleweed: how do i update my revu request with new changes?
[21:20] <tumbleweed> you upload it again
[21:20] <shadeslayer_> tumbleweed: nuke earlier package?
[21:20] <tumbleweed> it'll replace it
[21:20] <shadeslayer_> ah ok
[21:20] <shadeslayer_> even if its the same version?
[21:21] <tumbleweed> yup
[21:21] <shadeslayer_> nice nice...
[21:22] <shadeslayer_> tumbleweed: what can i do about I: qipmsg: spelling-error-in-binary ./usr/bin/qipmsg Unkown Unknown
[21:23] <shadeslayer_> tumbleweed: still ftbfs :P
[21:23] <shadeslayer_> make[1]: *** No rule to make target `packages/qipmsg-1.0.0.orig/debian/qipmsg'.  Stop.
[21:23] <shadeslayer_> tumbleweed: can you pastebin your rules file? or is it the same?
[21:23] <tumbleweed> shadeslayer_: a single line like that doesn't help. Paste your rules file, the command you are excuting, and output
[21:24] <shadeslayer_> hold on ill pastebin the whole log :)
[21:24] <shadeslayer_> tumbleweed: http://pastebin.com/wGfPiZDU
[21:24] <shadeslayer_> thats the rules file
[21:25] <tumbleweed> I see it's still called configobj
[21:25] <shadeslayer_> tumbleweed: yeah i know :P
[21:25] <tumbleweed> and you try to unzip a .tar.bz2
[21:25] <shadeslayer_> oh..  i need tar there
 tumbleweed: how do i update my revu request with new changes? <- However you need to use the option '-f' or delete the related *.upload file otherwise you can't upload it newly
[21:28] <shadeslayer_> BlackZ: yes know about that :)
[21:28] <shadeslayer_> dput -f :)
[21:30] <shadeslayer_> tumbleweed: http://pastebin.com/LtP8E9wZ
[21:31] <shadeslayer_> thats even worse than debuild :P
[21:31] <ari-tczew> BlackZ: new upstream xchat is available to merge
[21:32] <shadeslayer_> tumbleweed: http://pastebin.com/NSLtUiUG
[21:32] <BlackZ> ari-tczew: oh really? I will merge it then
[21:32] <BlackZ> I didn't know, sorry
[21:32] <ari-tczew> BlackZ: ;)
[21:32] <shadeslayer_> tumbleweed: also after line 58,which dir is the script in? the untarred dir or the dir in which the packed sources are present?
[21:33] <ari-tczew> this is an example, when MoM should send e-mail to last uploader with information about merge available
[21:33] <shadeslayer_> ( probably later according to me )
[21:33] <tumbleweed> shadeslayer_: current directory - it never cds
[21:35] <shadeslayer_> brb
[21:39] <shadeslayer_> tumbleweed: ok
[21:39] <shadeslayer_> that means ill have to add some more to the get-orig-source part
[21:39] <tumbleweed> shadeslayer_: so, I see your problem. It only worked before because I'd been playing around
[21:40] <tumbleweed> shadeslayer_: I think just allow the make clean to fail
[21:40] <tumbleweed> shadeslayer_: unless someone who knows qmake better has a suggestion
[21:40] <tumbleweed> shadeslayer_: yeah, it looks like your get-orig-source needs testing :)
[21:40] <shadeslayer_> yep...
[21:42] <shadeslayer_> ok,so finally now,let clean fail,but wont that cause package to ftbfs?
[21:42] <tumbleweed> no, I mean say "- $(MAKE) clean"
[21:42] <shadeslayer_> ah ..
[21:42] <shadeslayer_> i was typing that :P
[21:42] <shadeslayer_> tumbleweed: also about dh_prep.. do i let it stay? or use dh_clean -k ?
[21:43] <tumbleweed> don't use clean -k, it's deprecated
[21:43] <shadeslayer_> hmm
[21:46] <shadeslayer_> tumbleweed: http://shadeslayer.pastebin.com/AseHBtgr
[21:56] <tumbleweed> shadeslayer_: I simply don't get that. what am I doing wrong? http://shadeslayer.pastebin.com/rfA5EfS4
[22:00] <geser> tumbleweed: you don't have an space in the directory where you try to build the package like shadeslayer_
[22:00] <geser> from shadeslayer_: DESTDIR=/home/shadeslayer/ninja/New packages/qipmsg-1.0.0.orig/debian/qipmsg
[22:00] <tumbleweed> geser: :)
[22:00] <geser> the " " in New packages isn't escaped or guarded
[22:01] <tumbleweed> well spotted
[22:03] <tumbleweed> oh I suppose that'd have been obvious if I'd read the log properly. must be getting tired
[22:07] <BlackZ> geser: in the new xchat package we use dpatch but the maintainer of the package dropped dpatch and adopted quilt, now we have two possibilities: 1. reintroduce dpatch for our patches; 2. rename all patches. What's the best way for you?
[22:08] <micahg> BlackZ: why do you have to rename the patches?
[22:08] <geser> BlackZ: 3. convert the dpatches to quilt
[22:09] <ari-tczew> how can I get buildlog from pbuilder-dist ?
[22:09] <Laney> ~/pbuilder/blah_result/last_operation.log
[22:09] <BlackZ> micahg: in the currently debian package the patches are in the *.patch ext, for an "university" reason
[22:09] <BlackZ> also, the package uses quilt as well, now
[22:10] <geser> ari-tczew: pbuilder-dist maverick build --logfile build.log a_package.dsc
[22:10] <geser> oh, pbuiler-dist logs by default?
[22:10] <Laney> yep
[22:11] <micahg> BlackZ: right, but you're merging from debian, right?  so, just convert whatever patches we add like geser suggested
[22:11] <BlackZ> yes, I missed that, thanks geser
[22:12] <ari-tczew> thanks Laney and geser


[08:27] <Murali> Hi Jamespage
[08:38] <jamespage> Murali, good morning
[08:38] <Murali> Good Morning Jamespage
[08:38] <Murali> finally we are able to successfully launch the openstack
[08:39] <Murali> we are able to see the openstack-dashboard
[08:39] <jamespage> Murali, \o/
[08:39] <jamespage> congrats!
[08:39] <Murali> Now we have issue in logging to instances we created in openstack
[08:40] <jamespage> Murali, oh yes
[08:40]  * jamespage braces for mtu confusion
[08:40] <jamespage> Murali, you've done the normal stuff like enabled SSH and ping access to the instances?
[08:41] <Murali> its says "console is currently unavailable. please try again later" from openstack dash-board
[08:41] <jamespage> Murali, oh the console access is disabled by default
[08:41] <Murali> ok
[08:41] <jamespage> Murali, it does not scale that well and is not fully security supported in Ubuntu, so we can't enable it by default
[08:42] <jamespage> Murali, we try to stick to fully supported options by default
[08:42] <Murali> how to make to enable?
[08:43] <Murali> or how to access the instance we created in openstack
[08:48] <jamespage> Murali, the best way IMHO is with SSH
[08:48] <jamespage> Murali, the bundle on jujucharms.com has some details on how to configure the firewall to allow access
[08:49] <jamespage> Murali, you can inject an SSH key as part of booting an instance as well
[08:49] <jamespage> Murali, the dashboard is OK for a quick drive through, but for any serious use you'll want to get to know the command line tooling :-)
[08:49] <Murali> on cli also we tried Jamespage
[08:50] <jamespage> Murali, what problem did you hit?
[08:52] <Murali> we are now able to login via CLI Jamespage
[08:52] <jamespage> Murali, good
[08:52] <Murali> Thanks a lot for kind response
[09:00] <jamespage> Murali, no problem
[09:04] <jamespage> Murali, I was thinking about why you ended up with no relations to start with - I suspect it was due to the error on the neutron-gateway during deployment
[09:04] <jamespage> Murali, I *think* that any errors like that will stop the second phase of adding relations from being executed
[09:05] <jamespage> Murali, I also believe that the juju-gui is switching to not work like that - but rick_h_ would need to confirm on that - are we moving to a deploy and related,
[09:05] <jamespage> ?
[09:05] <jamespage> not waiting for services to deploy before relating
[09:06] <Murali> we first ran the jujuquickstart
[09:07] <Murali> it successfuly deployed all the services
[09:07] <Murali> we waited for longtime couldnt see the relations added
[09:08] <Murali> and juju-gui showed some error saying "error occured but information"
[09:09] <Murali> then we applied juju-deployer bundle.yaml as per you
[09:10] <Murali> But we saw that neutron-gateway deployment was success
[09:44] <rick_h_> jamespage: Murali yes, depending on the gui version it would stop the deployment if it hit an error. There's plans to update that to not be the case, but it's part of a bigger chunk of how bundles are handled and not ready yet.
[10:05] <Murali> ok
[11:48] <Murali> Hi Jamespage
[11:48] <Murali> sorry to trouble you with questions
[11:48] <Murali> we would like add the local jujucharm which we developed to bundle.yaml
[11:49] <Murali> is it possible?
[11:56] <jamespage> Murali, it is - you can just add it to the deployed environment and the export the bundle from the GUI
[12:03] <Murali> is there any changes required in bundle.yaml Jamespage?
[12:05] <Murali> how to add the repository path in bundle.yaml file?
[12:06] <jamespage> Murali, oh I see
[12:06] <jamespage> tricky that one
[12:15] <rick_h_> Murali: the GUI doesn't support bundles with local charms because they're not reusable then. I don't recall if the deployer had a way to do that. I think it tends to use vcs locations in order to support a charm not in the main charm store
[12:16] <Murali> ohh ok rick_h_
[12:16] <Murali> is there any other way to deploy the local charms with out juju-gui
[12:17] <Murali> and using jujudeployer command
[12:18] <Murali> is it possible via CLI  juju deployer
[12:36] <bloodearnest> is it possible to loosen the permissions on log files for the local provider? Currently 0500, syslog:syslog
[12:37] <bloodearnest> 0600 rather
[12:37] <bloodearnest> I can edit the /etc/rsyslog/conf.d/ juju file, but was wondering
[12:38] <bloodearnest> if it would get rewritten on bootstrap, or if it was worth loosening by default? Given the local provider is explicitly for dev  only?
[14:03] <lazyPower> rick_h_: you can use local charms with deployer if you have JUJU_REPOSITORY env set
[14:03] <rick_h_> Murali: ^
[14:03] <lazyPower> we make extensive use of this in our testing of bundles that dont yet exist or have a place in the charm store - as ingest in personal namespace introduces a latency between changes.
[14:05] <lazyPower> Murali: if you need an example of a bundle leveraging local charms - see:  https://github.com/whitmo/bundle-kubernetes/blob/master/specs/local.yaml
[14:49] <Murali> Thanks lazyPower
[15:07] <ctlaugh> I'm looking for some help on the correct way to configure the charm(s) to deploy Nova correctly to use either Neutron or FlatDHCPManager (whatever is easier) when deployed by Juju on a MAAS node.  The node only has 1 network interface that is brought up (eth0) and it is already bridged to juju-br0.  I'm running trusty/icehouse.
[15:36] <stub> bloodearnest: I opened a bug on that, about changing ownership of the logs, but it is won't fix as the team are trying to make the local provider behave more like the rest of the providers rather than being full of special cases.
[15:39] <bloodearnest> stub, ack, thanks, good to know
[15:39] <bloodearnest> approve of that goal
[15:40] <stub> yeah, agreed
[16:35] <johnny_shieh_> Hi, I've recently installed a juju master (charm development) and when I run a "charm proof" command on my charm, I get this error message
[16:35] <johnny_shieh_> I: Includes template icon.svg file.
[16:35] <johnny_shieh_> W: README includes line 6 of boilerplate README.ex
[16:35] <johnny_shieh_> I: relation website has no hooks
[16:35] <johnny_shieh_> I: missing recommended hook config-changed
[16:35] <johnny_shieh_> ERROR subprocess encountered error code 100
[16:36] <johnny_shieh_> I also ran this on a colleague's charm and got different warning messages, but also the same error code 100.
[16:36] <johnny_shieh_> Is there a FAQ for error codes?  I tried searching on google first, but no "100" hits in the first pages
[21:06] <ayr-ton> guys, the HACKING.txt from charms-tools is outdated. Could I submit a merge request with updated instructions based on the latest Makefile?
[21:19] <thumper> ayr-ton: sounds good to me
[21:21] <ayr-ton> thumper: okay :)
[22:40] <MOZGIII> hello, I have armhf board with debian on it, and ubuntu trusty inside an lxc on it, and I run juju on that ubuntu. and when I try to bootstrap with local env (meaning that would create nested lxc containers) - that doesn't work (lxc starts but agent fails to start)
[22:40] <MOZGIII> how do I fix this and make agent start up properly?
[22:41] <MOZGIII> I'm trying to deploy juju-gui
[22:42] <MOZGIII> http://code.re/7oB
[22:42] <MOZGIII> http://code.re/7oC
[22:42] <MOZGIII> http://code.re/7oD
[22:44] <MOZGIII> http://code.re/7oE


[12:33] <jas02> Hi, i am new here and i want to help you with ubuntu-server. I am using Debian as server for long time, and now i am using Ubuntu server too (Dapper Drake). What is the best way to start?
[12:56] <skateinmars> I think it depends on how you want to help
[01:24] <jas02> i can help in many ways. I can programming something (Perl/C) and/or i can help with bug reporting. Can you tell me what do you plan for next release (Edgy Eft) server? Is there some TODO list wrom which i can take same task(s)?
[01:35] <screeb> hi jas02, i'm also new here :)
[01:37] <jas02> screeb: hi :-)
[01:37] <screeb> I'm trying to join a project on writing a web interface for ubuntu-server
[01:37] <screeb> http://ubuntuforums.org/showthread.php?t=191858&page=11
[01:37] <screeb> It is just an information ;)
[01:39] <jas02> well, i just start read it
[01:42] <jas02> it looks very interesting. I see already some WWW interface on top of the Debian, but nothing so professional.
[01:46] <screeb> :)
[02:17] <screeb> I am not in the Ubuntu Server Team, and don't have lot of feadback from ubuntu yet
[02:17] <screeb> it is maybe not structured enough yet...
[02:21] <jas02> same as me
[02:23] <screeb> you have some project for ubuntu?
[02:28] <jas02> not yet
[04:37] <skateinmars> jas02, screeb maybe you should try to contact the team via the mailing-list
[04:41] <jas02> i am already in mailing list, but no mails comming :-)
[04:46] <jc-denton> hi all
[04:49] <jc-denton> anybody here who is familiar with mdadm / lvm?
[06:32] <jimcooncat> gnome-system-log is segfaulting when trying to open /var/log/getmail.log.1.gz. How do I search that file?
[06:33] <derekS> jimcooncat: gnome isn't included on ubuntu-server, you are better off in #ubuntu
[06:33] <derekS> and it seems like youasked there before here
[06:34] <jimcooncat> ok. just wanting to know how to seach a .gz'd log file, thought you could tell me an easy way
[06:34] <jimcooncat> sorry, I asked in #ubuntu, and got an answer -- I thought they weren't listening
[06:34] <derekS> jimcooncat: from now on ask in the appropriate channel. gunzip should work to extract it
[06:35] <jimcooncat> yessir
[06:41] <derekS> Ries: i agree, but i gnome isn't included in ubuntu server (and it has nothing to do with it)
[06:41] <derekS> if he was asking about something like hula or open-exchange, even though it isn't included, it would be appropirate :)
[08:07] <allee> mhm, jas02 is gone. Nevertheless ;) next time someone asks for something to help.  Point to https://launchpad.net/distros/ubuntu/edgy/+specs


[01:24] <nixternal> yuriy: that's what you get when you write software for Ubuntu I guess :/
[01:24] <nixternal> does it even have me listed as the author? or a author?
[01:24] <nixternal> or something?
[01:28] <ScottK> Just fix it an upload it then.
[01:32] <rgreening> ha
[01:35] <yuriy> nixternal: it does -- i'm talking about the kaboutdata, you probably changed it
[01:39] <nixternal> I can't remember..I remember setting myself as the author and leaving the (C) for Canonical though
[01:40] <nixternal> I seriously don't care about the copyright...as long as it stays free software of course :)
[01:41]  * nixternal goes and eats, then after than is going to send a railing email to the moveon.org idiots who claim to be "nonpartisan" yet bash republicans on their website and ask for donations to a democrat
[04:43] <obama> bug 427841
[04:43] <obama> wow, i was quite late on that one
[04:43] <ScottK> Change has been achieved
[04:51] <vorian> heh
[04:51] <vorian> within each small move is the kernel of a radical change
[06:03] <Sput> apachelogger: weren't you working with scarabeus on the gettext branch a few months ago? :)
[06:03] <Sput> we had it working "in theory", just that some setups wouldn't use translated strings :)
[08:41] <Quintasan> ryanakca: ping
[09:02] <apachelogger> ScottK: kamoso dev already sent mail to lure and gilles
[09:02] <apachelogger> proposing either a shared lib or improving the kipi interface or rewriting the code
[09:13] <apachelogger> Sput: in theory :P
[09:14] <apachelogger> Sput: IIRC the only reliable soution is to use lowlevel gettext, i.e. it's c++ implementation directly
[09:14] <apachelogger> and even then I would not know what to do with the ui files
[09:15] <apachelogger> Sput: I would just limit localization to the KDE enabled client :P
[09:15] <apachelogger> AFAIK that is how marble does it
[09:15] <apachelogger> actually
[09:15] <apachelogger> ....
[09:16]  * apachelogger just had an idea
[09:19] <apachelogger> ok, that is so insane it could actually work
[09:20] <apachelogger> Sput: following scenario: you stack klocale on top of the KDE integration using i18n() only inside KDE components, unless I am completely wrong KLocale should also ensure that tr() gets translated
[09:20] <apachelogger> then we use gettext to obtain two pot files
[09:20] <apachelogger> one for qt only and one for KDE integration
[09:21] <apachelogger> the latter will manually add the qt one to the klocale translation catalog
[09:21] <apachelogger> so
[09:21] <apachelogger> depending on the cmake arguments we either build a mo or a qm
[09:22] <apachelogger> so, if you build with KDE you get 2 mos per language, one kde and one qt
[09:22] <apachelogger> if you build qt only you will get one qm file per language
[09:22] <apachelogger> as insane as this sounds, it might actually work :D
[10:30] <Quintasan> HURRR
[10:30] <Quintasan> apachelogger: ping
[10:30] <apachelogger> Quintasan: pong
[10:31] <Quintasan> apachelogger: what should I add to rules when package is build like this "qmake dooble.pro && make" ?
[10:32] <Quintasan> apachelogger: I tried adding those to default rules but it keep failing because of 'clean' part :/
[10:32] <apachelogger> cdbs' qmake.mk
[10:32] <Quintasan> let see
[10:32] <apachelogger> Quintasan: you probably need to sort clean yoursef
[10:32] <apachelogger> qmake is a PITA
[10:33] <apachelogger> for the developer and the packager and the user
[10:33] <apachelogger> qmake is one big fail IMHO
[10:33] <Quintasan> apachelogger: debuild -S starts with clean, isn't clean supposed to run AFTER compilation?
[10:33] <apachelogger> poke upstream and recommend cmake
[10:33] <apachelogger> Quintasan: no
[10:33] <apachelogger> before and after
[10:33] <apachelogger> the source package needs to be clean aswell :P
[10:33] <Quintasan> but I start with clean source, don't I?
[10:33] <apachelogger> well
[10:34] <apachelogger> if you run debuild -us -uc you have poluted source
[10:34] <apachelogger> which is why clean is always run before the source package is built
[10:36] <Quintasan> damn, each package I pick is fckd up or upstream is too lazy to fix it
[10:36] <apachelogger> well, all the more to learn :)
[10:37] <Quintasan> train clock plasmoid borked, acetone was propably to lazy to sort out copyrighted images
[10:37] <apachelogger> well, you can always dfsg copyrighted stuff
[10:38] <apachelogger> it usually is more annoying to upstream when users come whine about how there are no images than packagers whining about copyrights :P
[10:38] <Quintasan> :D
[10:38]  * apachelogger kicks hg
[10:38] <Quintasan> I found Silicon, looks better than Acetone
[10:38] <apachelogger> darn hg convert refuses to convert konvis full history
[10:39]  * apachelogger imports konvi into git hoping that hg has more luck converting git :D
[10:39] <apachelogger> Quintasan: well, acetone would be a no-go for packaging for me
[10:39] <apachelogger> way too ugly website
[10:39] <Quintasan> http://www.hyperray.net/hyperget/silicon-auto-image-mounter <-- over 9000 times better
[10:40] <apachelogger> why auto-mounter though?
[10:40] <apachelogger> what is so auto?
[10:40] <Quintasan> dunno
[10:40] <apachelogger> cool :D
[10:40] <Quintasan> It works just like daemon tools
[10:41] <apachelogger> Quintasan: btw, did you cooridnate a KDE release packaging session yet?
[10:41] <apachelogger> is that even comon these days?
[10:42]  * apachelogger sure looks forward to october when he can jump in with all the godlike powers he got again :P
[10:42] <Quintasan> I don't think so. You mean session to explain what ninjas do?
[10:42] <apachelogger> Quintasan: nah, to ensure they dont fck up
[10:42] <apachelogger> i.e. revu all changes and basically jump for the important, yet difficult packages
[10:43] <apachelogger> JontheEchidna did some IIRC, he probably can explain when he gets up
[10:43] <Quintasan> fck, qmake is srsly a PITA
[10:43]  * apachelogger notes that importing konvi into git takes ages
[10:43] <apachelogger> Quintasan: told ya :P
[10:44] <apachelogger> Quintasan: you most likely need to implement everything but qmake/make yourself
[10:44] <apachelogger> i.e. clean and install
[10:44] <Quintasan> HA
[10:44] <Quintasan> okay, two ways to get it to generate makefile
[10:45] <Quintasan> delete win and osx *pro files or hack rules :P
[10:45] <apachelogger> debuild will restore deleted files, so the former is an option
[10:45] <apachelogger> but
[10:45] <apachelogger> if you want to learn something...
[10:46] <apachelogger> implement the whole build using low-level debhelper
[10:46] <apachelogger> you can pass a specific pro file to qmake IIRC
[10:46] <Quintasan> debhelper...urgh
[10:46] <apachelogger> so if you have ultimate control over the build you probably dont need to delete that stuff
[10:47]  * apachelogger is wondering if the git konvi import takes the branches into account
[10:47] <Quintasan> there is a noobs guide to debhelper or I need to go through manuals?
[10:47] <apachelogger> stopped obtaining revisions at 665000 and searches up the revisions now ... at 835000 already :S
[10:48] <apachelogger> Quintasan: well, there is a very very unuseful guide in the wiki
[10:48] <Quintasan> :|
[10:48] <apachelogger> maybe it improved though
[10:48] <apachelogger> worth looking I suppose :D
[10:49] <apachelogger> simply put: you need a clean target and a binary-arch target that depends on a build an install target, where install depends on build and build on configure
[10:50] <apachelogger> you might want to stamp build though :P
[10:50] <Quintasan> lol
[10:50]  * Quintasan never used debhelper
[10:50] <apachelogger> sec
[10:51] <apachelogger> http://aplg.kollide.net/kubuntu/debian/rules
[10:51] <apachelogger> it's best to start reading at the bottom
[10:51] <apachelogger> http://www.gnu.org/software/automake/manual/make/Phony-Targets.html
[10:52] <apachelogger> what you need to understand is that debian/rules is for the better part a very simple make file
[10:52] <apachelogger> thus makefile paradigms appy, like, every line break also equals going back to the execution dir ...
[10:53] <apachelogger> reading it like a script might make sense though
[10:53] <apachelogger> easier to understand
[10:53] <apachelogger> so if you start at the bottom you have the phony targets
[10:53] <apachelogger> then binary which is really just a wrapper for binary-arch and binary-indep
[10:54] <apachelogger> this splitting is mostly useful when you need different stuff to be done for an arch:all and arch:any package
[10:54] <apachelogger> both "depend" on build and install
[10:54] <apachelogger> if you look at install, it depends on build
[10:54] <apachelogger> so build must be done before install
[10:55] <apachelogger> build "depending" on build-stamp and that is depending on config.status
[10:55] <apachelogger> in config.status you would run cmake .. or configure or qmake
[10:56] <apachelogger> once that is done build-stamp continues ensuring we are in the right dir
[10:56] <apachelogger> you can obtain information about debhelper scripts via their man page
[10:56] <apachelogger> e.g. man://dh_testdir
[10:56] <apachelogger> then it just runs make and creates a file build-stamp
[10:57] <apachelogger> that file is prevent useless runs of build
[10:57] <apachelogger> ...look at the clean target youll see that there the stamp gets removed
[10:57] <apachelogger> which basically means that make will only be run after a clean
[10:57] <apachelogger> so build is done, returning to install
[10:58] <apachelogger> that again runs some dh magic to ensure everything is in place for make install
[10:58] <apachelogger> one word of advice though ... for qmake in 90% of all cases it makes sense to abuse man://dh_install for installation rather than placing everything manually via the install target
[10:59] <apachelogger> once install is finished we return to binary-arch, all "dependencies" of that are now done and the binary-arch target is self is processed
[10:59] <apachelogger> here you only find a pile of debhelper scripts to build the package and place additional files
[11:00] <apachelogger> I recommend you take a look at the manpages of each of those for clearity
[11:00] <apachelogger> if everything went fine the dh_builddeb script builds the actual deb
[11:00] <apachelogger> Quintasan: all clear? :D
[11:01] <Quintasan> hmm
[11:02] <Quintasan> yup, but knowing myself I will need to package two or three things before understanding it fully :P
[11:02] <apachelogger> nothing wrong with that :)
[11:03] <neversfelde> kformula was remove from koffice 2.0.82 again, but it was part of 2.0.81. How can I get it deinstalled when upgrading to 2.0.82, make koffice-kde4 replace kformula (>=2.0.81) ?
[11:04] <apachelogger> neversfelde: you don't
[11:04] <apachelogger> neversfelde: do we deploy via PPA?
[11:05] <neversfelde> apachelogger: yes
[11:05] <neversfelde> it is in the backports beta ppa
[11:05] <apachelogger> hm
[11:06] <apachelogger> neversfelde: kformula will get nuked when the koffice libs become incompatible with it
[11:06] <Quintasan> apachelogger: one question, what's the point of configure depending on configure-stamp?
[11:06] <apachelogger> neversfelde: replacing it is quite ugly TBH
[11:06] <neversfelde> there seem to be some files, which where in kformula-kde4.install that are now in kplato-kde4.install, so I will have to make kplato-kde4.install conflict with kformula
[11:07] <apachelogger> Quintasan: prevent configure from being executed when it is not necessary ... all stamp targets are only to prevent that the containing stuff gets executed if the appropriate stamp file is available
[11:07] <Quintasan> hmmm
[11:08] <apachelogger> neversfelde: oh, then replace and conflict kformula with kplato
[11:08] <neversfelde> apachelogger: k
[11:08] <Quintasan> so things like ./configure or qmake dooble.pro should go to configure-stamp?
[11:08] <neversfelde> thank you
[11:09] <apachelogger> Quintasan: depends on the other available targets, but generally yes :)
[11:09]  * apachelogger hg converts konvi git to hg :D
[11:10] <apachelogger> that is so freaking insane
[11:10] <apachelogger> best thing ever: you can't bzr fast-export branches with tags containing an epoch, git does not appear to be liking that very much and breaks on fast-import
[11:12] <Quintasan> WTF
[11:13] <Quintasan> apachelogger: debian/rules:21 *** missing separator (TAB instead 8 spaces?). Stop
[11:13] <Quintasan> I used TAB there :|
[11:18]  * Quintasan is going crazy
[11:20] <Quintasan> YAY
[11:20] <Quintasan> ITS ALIVE
[11:23] <Quintasan> apachelogger: exacly as I though, clean did not depend on anything, adding configure and build to depends helped :P
[11:27] <apachelogger> Quintasan: why would you have to build before being able to clean?
[11:28] <apachelogger> that does not make sense
[11:28] <apachelogger> that is like: you have to fill your harddisk before you can format it
[11:30] <apachelogger> the quasselVskonvi codeswarm does not take konvi-kde3 into account while it was branched from trunk
[11:30] <apachelogger> still quite interesting
[11:30] <apachelogger> at the time konvi went to the KDE 3 branch quassel grew quite a bit :D
[11:40] <Quintasan> apachelogger: I looked at it like this
[11:40] <Quintasan> apachelogger: a) you start with pure source b) you configure (+Makefile) c) then you build it(+ *.o files) d) you clean Makefile and *.o files
[11:42] <apachelogger> Quintasan: you cannot assume that the intial source is purged
[11:42] <apachelogger> Quintasan: always run clean
[11:42] <apachelogger> clean must work anyway
[11:42] <apachelogger> otherwise the package will get rejected
[11:42] <Quintasan> apachelogger: but it fail all the time
[11:42] <apachelogger> so fix it :P
[11:43] <Quintasan> says - "no rules to make 'clean'"
[11:43] <Quintasan> no matter what I put there
[11:43] <apachelogger> batpaste your rules file
[11:43] <Quintasan> http://pastebin.com/f2a3868e5
[11:45] <apachelogger> make clean only works when there is a make file ;)
[11:45] <apachelogger> should be distclean IMHO anyway
[11:45] <apachelogger> [ ! -f Makefile ] || $(MAKE) distclean
[11:45] <apachelogger> unless makefile does not exist run make distclean
[11:46] <Quintasan> ah k
[11:46] <apachelogger> also, if you prefix any command with - an error will be ignroed
[11:46] <apachelogger> so -make distclean
[11:46] <apachelogger> would have about the same affect
[11:46] <Quintasan> but I lol'd since built deb file did not contain any binaries :O
[11:46] <apachelogger> just that lintian will bitch about it :D
[11:46] <apachelogger> Quintasan: make install is defuncted
[11:46] <apachelogger> as I anticipated :P
[11:47] <apachelogger> Quintasan: use dh_install to put everything into place
[11:47] <Quintasan>  $(MAKE) DESTDIR=$(CURDIR)/debian/dooble install
[11:47] <Quintasan> replace this with dh_install?
[11:47] <apachelogger> no
[11:47] <apachelogger> Quintasan: did you already take a look at the dh_install manpage?
[11:48] <Quintasan> looking
[11:48] <Quintasan> mhm
[11:48] <apachelogger> the thing with dh_install is that it needs to be run for _every_ binary package
[11:49] <Quintasan> first let me deal with clean
[11:49] <apachelogger> ill explain meanwhile :P
[11:49] <Quintasan> so it shouldnt depend on build or anything
[11:49] <Riddell> Lure: why do you have an unlock dialogue for autologin?  the whole point of autologin is there's no password
[11:49] <apachelogger> so dh_install in the install target would work for your package
[11:49] <apachelogger> but
[11:49] <apachelogger> say you add a -data package it will not work that well anymore
[11:50] <apachelogger> thus it is common to have dh_install run in the binary-* target
[11:50] <apachelogger> since those get run for every binary package anyway
[11:51] <apachelogger> so just implement an appropriate debian/install file and remove the comment from dh_install
[11:51] <apachelogger> ... it is already in your binary-arch target, just commented out :)
[11:51] <apachelogger> Riddell: autologin to decrease login time but still being somewhat secure
[11:52] <Quintasan> okay, I want to know wtf is with this error about 8 spaces instead of tabs
[11:52] <apachelogger> Riddell: like you turn on the pc and go get a cup of coffee, when you come back you just need to enter the password and can pointy click around
[11:52] <Quintasan> apachelogger: I need to put [ ! -f Makefile ] || $(MAKE) distclean  in clean rule, right?
[11:52] <apachelogger> Riddell: IMHO a very minimal usecase though
[11:53] <apachelogger> Quintasan: yeah, replace your make clean with it
[11:53] <apachelogger> Quintasan: do you have spaces somewhere that cause that error :P
[11:53] <Quintasan> now I need to know where the hell the binaries are put
[11:54] <Riddell> apachelogger: how do you set that?
[11:54] <apachelogger> there is a special setting for that in kdm
[11:54] <apachelogger> last tab of the KCM IIRC
[11:54] <apachelogger> along the no-password for login option
[11:55] <Riddell> oh I see it
[11:55] <apachelogger> Quintasan: ../ by default
[11:55] <apachelogger> Quintasan: depends on how you build really ;)
[11:55] <Quintasan> shit, this sucks
[11:55] <apachelogger> lol
[11:56] <apachelogger> that is regular stuff no matter what is in your rules file
[11:56] <Quintasan> Binary is build in the source directory
[11:57] <apachelogger> oh
[11:57] <apachelogger> the app binary :D
[11:57]  * apachelogger thought the deb binary
[11:57] <Quintasan> yeah, and I need to put Icons dir somewhere
[11:57] <Quintasan> This is harder than I expected
[11:58] <apachelogger> the harder the better I always used to think :D
[11:58] <apachelogger> now I am too lazy to add more than 3 cdbs includes :P
[12:00] <Quintasan> apachelogger: http://pastebin.com/f64cdd090  <-- this is direcotry layou
[12:00] <Quintasan> I obviously need Icons, Images, Tab and Doc
[12:01] <Quintasan> also qss
[12:01] <Quintasan> but where I should put those?
[12:02] <apachelogger> Quintasan: you might not
[12:02] <apachelogger> Quintasan: first check the binary
[12:02] <apachelogger> it is common that qmake binaries have all that crap embedded in the binary
[12:02] <Quintasan> wut
[12:02] <apachelogger> so at the most you need the app icon in /usr/share/pixmaps and a desktop file
[12:04] <Quintasan> lol, with Dooble we have 3 QtWebKit browsers :D
[12:04] <Quintasan> :/
[12:05] <Quintasan> They propably are not embedd
[12:05] <apachelogger> way too easy to creat a browser these days
[12:05] <apachelogger> we should write our own
[12:08] <Quintasan> apachelogger: the icons are not embbed into binary, there are lots of files in Icons directory
[12:08] <apachelogger> Quintasan: are none of them embedded?
[12:09] <Quintasan> apachelogger: nope, no icons until I manually select .cfg file from Icons directory
[12:09] <apachelogger> then it's getting dirty
[12:09] <apachelogger> Quintasan: inspect the code
[12:09] <apachelogger> either that thing would expect the cfg somewhere to be or you need to patch it so that it does
[12:11] <Quintasan> arg("Icons/nuvola/configuration.cfg"));
[12:11] <Quintasan> :/
[12:13] <apachelogger> arg?
[12:13] <apachelogger> Quintasan: please paste that file
[12:13] <apachelogger> EgS: ping ping ping
[12:13] <apachelogger> I am a sexy hot biatch
[12:13] <Quintasan> lol
[12:13] <Quintasan> http://pastebin.ca/1564103
[12:14] <apachelogger> -(~/src/git/quassel/build:$)-> grep -r -i quassel_qt.mo trace
[12:14] <apachelogger> 31892 access("/home/me/.kde/share/locale/de/LC_MESSAGES/quassel_qt.mo", R_OK) = 0
[12:15] <apachelogger> Quintasan: that code is a bit different :D
[12:15] <apachelogger> if the settings do not yet contain iconset, then add iconset with currentdir/Icons/...
[12:15] <apachelogger> Quintasan: probably needs to be patched
[12:16] <Quintasan> well, the browser right after compiling starts with no icons
[12:16] <apachelogger> though I find it insane that upstream writes that stuff to the settings object even if the user did not set it
[12:16] <apachelogger> Quintasan: if you start it a second time?
[12:17] <Quintasan> compiling :P
[12:17] <apachelogger> anyway
[12:17] <apachelogger> just replace the code there
[12:17] <apachelogger> QString("%1/%2").arg(QDir::currentPath()).
[12:17] <apachelogger>                       arg("Icons/nuvola/configuration.cfg"));
[12:17] <apachelogger> to
[12:17] <apachelogger> QString("/usr/share/foobar/blah/bluh...");
[12:18] <Quintasan> no icons even after 5 restart
[12:18] <apachelogger> yeah, needs patching :P
[12:18] <apachelogger> patchy patchy
[12:18] <apachelogger> and poky poky upstream
[12:19] <apachelogger> you might borrow the MSOD
[12:19] <apachelogger> or was it LSOD
[12:19] <apachelogger> something that sounds like a drug for sure :P
[12:20] <apachelogger> Nightrose: ping
[12:20] <Quintasan> I will put Icons dir in /usr/share/dooble right?
[12:20] <Nightrose> apachelogger: pong
[12:20] <apachelogger> Quintasan: yep
[12:21] <apachelogger> Nightrose: do you have Sput's mobile numba?... can you text him?
[12:21] <apachelogger> I am close to a nervous breakdown
[12:21] <Sput> wus!
[12:21] <apachelogger> oh
[12:21] <apachelogger> there he is
[12:21] <Nightrose> ;-)
[12:21] <apachelogger> Sput: I HAZ GETTEXT
[12:21] <Sput> ooh
[12:22] <apachelogger> what I was talking about earlier actually works
[12:22] <apachelogger> right after creation of the kapp:  KGlobal::locale()->insertCatalog("quassel_qt");
[12:22] <Sput> do we need to use i18n() at all?
[12:22] <apachelogger> nope
[12:22] <apachelogger> not at all
[12:22] <Sput> hm, and what happens with !kde?
[12:22] <apachelogger> not the tiniest bit
[12:23] <Sput> and! can we convert our existing translations, or are I gonna make some people extremely unhappy? :)
[12:23] <apachelogger> we can
[12:23] <Quintasan> hahahahahahha
[12:23] <apachelogger> they need proof reading and stuff
[12:23] <apachelogger> but for the better part it seems to work
[12:24] <Quintasan> apachelogger: there are even java modules for Dooble XD
[12:24] <apachelogger> basically what we do is introduce a Messages.sh like KDE extracting all qt stuff to a pot and all KDE stuff to a pot (just in case you ever want i18n for some KDE specific strings)
[12:24] <apachelogger> then at build time either create a qm (which I did not test yet...)
[12:24] <apachelogger> or a mo
[12:24] <apachelogger> depending on whether built with KDE or not
[12:25] <apachelogger> the existing translations should be convertable using gg://ts2po
[12:25] <apachelogger> which seemd to result in a prety decent .mo for me
[12:25] <Sput> sould's cool
[12:25] <Sput> though the "qm which I didn't test yet" frightens me
[12:26] <apachelogger> me too
[12:26] <Sput> as we already tried that one back then and it didn't work for several people including me :)
[12:26] <Sput> but maybe we did it differently back then
[12:26] <apachelogger> we tried mo loading in Qt I think
[12:26] <Sput> I thought we were building .qms?
[12:26] <apachelogger> I dunno :P
[12:26] <Sput> anyway, if that worked, it would be extremely cool
[12:26] <apachelogger> lets see
[12:26] <Sput> of course, today is UI freeze :)
[12:26] <Sput> for us
[12:26] <Sput> :)
[12:27] <apachelogger> worst that could happen is that a po and a ts need to be maintained, cross converted via ts2po or po2ts
[12:27] <apachelogger> or get the gettext --qt export fixed up
[12:29] <Sput> sounds interesting in any case
[12:30] <Sput> we prolly would get a ton more languages if that .po approach worked
[12:56] <Quintasan> apachelogger: there are some lines that look like (QString("%1/Tab/Default/search.html").arg(QDir::currentPath()));
[12:57] <apachelogger> oh man
[12:57] <Quintasan> apachelogger: should I patch them to point to /usr/share/dooble/blash?
[12:57] <apachelogger> yes
[13:02] <Riddell> Lure: ok, I know what the issue is, I'll take a look at it when I get a moment
[13:03] <Lure> Riddell: thanks
[13:20] <apachelogger> Riddell: btw http://aplg.kollide.net/kubuntu/swarm-09-09-12.avi
[13:20] <apachelogger> Sput: even more btw http://aplg.kollide.net/kubuntu/KonversationVsQuasselSwarm/2009-09-13_12-22-19.avi
[13:22] <apachelogger> Sput: does the core actually have translations?
[13:22] <Sput> yeah
[13:22] <apachelogger> that needs special treatment :S
[13:22] <Sput> though in the future we'll probably change that
[13:22] <apachelogger> sensible
[13:22] <Sput> well, except for cli options and warnings and stuff
[13:23] <Sput> but client-visible stuff should be generated in the client
[13:23] <apachelogger> well, I would pass cli option translations though low-level cpp gettext anyway :P
[13:23] <apachelogger> qlocale seems like a bit of an overhead for that
[13:24] <apachelogger> ok
[13:24]  * apachelogger notes that po->mo->klocale seems to work pretty well alright
[13:24] <apachelogger> on to qm
[13:24] <Sput> huh, what's this swarm stuff about? looks fun
[13:26] <apachelogger> commits over time of existence
[13:26] <apachelogger> though unfortunately I didnt get konvi in when it was in the KDE 3 branch
[13:26] <Sput> aah based on commit history
[13:26] <Sput> neat idea :)
[13:26] <apachelogger> on the other hand that illustrates how that boosted quassel :D
[13:27] <apachelogger> I am not sure how to handle that the core got translations of its own -.-
[13:27] <Riddell> apachelogger: commits to what?
[13:27] <apachelogger> Sput: could add quassel_core.pot
[13:28] <apachelogger> Sput: always make that a qm
[13:28] <apachelogger> Riddell: version control
[13:28] <apachelogger> with a bit of fiddling it doesn't matter which VCS, nah, actuall a lot of fiddling
[13:29] <Riddell> cor
[13:30] <apachelogger> quite useful if you want to know how many times Riddell did not manage to set his bzr nick :P
[13:36] <Quintasan> Riddell: Dooble is a PITA to deal with but I think I will finish it today
[13:37] <Riddell> thanks for that
[13:41] <ryanakca> Quintasan: pong, hurray :)
[13:43] <ryanakca> Quintasan: are you packaging all the little blurbs it seems to quasi-depend on? (ex, the search engine in runs as default)
[13:43] <Quintasan> ryanakca: nah, just core
[13:43] <Quintasan> ryanakca: there is epic mess with configurations for icons etc
[13:47] <apachelogger> of course our patches are as buggy as always
[13:47] <apachelogger> hoorays for cant remove language
[13:49] <neversfelde> please test koffice 2.1 beta2 from the staging ppa :)
[13:50] <neversfelde> karmic only atm
[14:51] <Quintasan> this is retarded
[14:52] <Quintasan> http://pastebin.com/f50c38a87 <--- can anyone tell why it complains about missing separator? I'm using tabs there
[14:53] <apachelogger> Quintasan: can you upload the file somewhere?
[14:53] <apachelogger> also, what is the precise error
[14:54] <Quintasan> debian/rules:26: *** missing separator (TAB instead 8 spaces?). Stop
[14:55] <Quintasan> apachelogger: http://hs.quintasan.pl/rules
[14:55] <apachelogger> no
[14:55] <apachelogger> you have spaces
[14:56] <apachelogger> Quintasan: what editor are you using?
[14:56] <Quintasan> vim
[14:56] <apachelogger> or are you doing echos and cats :D
[14:56] <apachelogger> hm
[14:56] <apachelogger> Quintasan: misconfigured maybe?
[14:56] <Quintasan> dunno
[14:56] <apachelogger> vim would by default tab debian/rules
[14:56] <apachelogger> Quintasan: paste your .vimrc
[14:57] <Quintasan> http://hs.quintasan.pl/vimrc
[14:58]  * apachelogger notes that cmake is freaking him out today
[14:58] <apachelogger> Quintasan: set expandtab will replace tabs with spaces
[15:00] <Quintasan> thanks :O
[15:54] <ScottK> apachelogger: (about kamoso dev talking to Kipi people) Great.  I'll modify the bug to be less threatening.
[16:00] <ScottK> apachelogger: I got a U/I freeze waiver for quassel expiring tonight, so if you have any intent to help Sput push the translations stuff through, now would be a good time.
[16:01] <apachelogger> well it is b0rked
[16:01] <apachelogger> Sput: ping ping
[16:01] <apachelogger> doesn't make any sense really
[16:01] <apachelogger> when I install current master and replace the german qm with my one built from a po the UI still stays translated
[16:02] <apachelogger> when I use the same qm in a modified build it fails to translate the UI
[16:02] <apachelogger> the file gets access according to strace
[16:04] <ScottK> apachelogger: Just wave your little pinky with your near godlike powers and fix it up. ;-)
[16:05] <apachelogger> too lazy
[16:05] <apachelogger> I might add 3 lines of cdbs includes
[16:05] <apachelogger> thats about as far as I would go these days :P
[16:08] <ScottK> apachelogger: You might also want to see why vlc FTBFS on armel so maybe kamoso can build there.
[16:09]  * apachelogger shudders
[16:09] <apachelogger> good idea though
[16:09] <apachelogger> on the other hand
[16:09] <apachelogger> ScottK: at this point kamoso does not even fit on a netbook screen
[16:09] <apachelogger> so I doubt it would be much good on arm machines
[16:10] <ScottK> Right, it's mostly about having the stats look good.
[16:10] <apachelogger> *nod*
[16:10] <ScottK> OTOH, N900 will have TV out and will likely run Kubuntu armel.
[16:10] <ScottK> So who knows.
[16:11]  * apachelogger needs more icecream but is too lazy to get the power cord for the netbook
[16:11] <apachelogger> maybe I should ccache
[16:16] <apachelogger> maybe I am approaching this from the wrong direction
[16:38] <neversfelde> was someone able to test koffice 2.0.82?
[16:38] <apachelogger> nope
[16:39]  * apachelogger is still doing the build, install, fail, tryagain game
[16:39] <neversfelde> hehe
[16:39] <apachelogger> now I even doubt my system, building unmodified quassel to check it actually would translate something
[16:41] <neversfelde> apachelogger: you said something about correct bzr whoami settings, how do I do this?
[16:42] <apachelogger> bzr whoami "NAME <EMAIL>"
[16:42] <apachelogger> though unless you ignore all sorts of warnings you should have done that already :D
[16:42] <neversfelde> mhh, I did this, but there seems to be something wrong, there is no link to my launchpad profile
[16:43] <apachelogger> your lp profile needs to have that email addy listed
[16:43] <ScottK> neversfelde: You can also set this up in ~/.bazzar/bazzar.conf
[16:43] <apachelogger> -.-
[16:43] <apachelogger> so
[16:43] <apachelogger> I do not get it
[16:43] <apachelogger> at all
[16:43] <ScottK> [DEFAULT]
[16:43] <ScottK> email = Scott Kitterman<EMAIL_ADDRESS>[16:43] <ScottK> launchpad_username = kitterman
[16:43] <ScottK> neversfelde: ^^
[16:44]  * ScottK should spell better too.  /.bazaar/bazaar.conf
[16:46]  * apachelogger takes a knife and jumps at Qt
[16:47]  * ScottK prepares bandages.
[16:47] <ScottK> (playing with knives is dangerous)
[16:48] <neversfelde> mhh, there is a second lp account neversfelde-ubuntu, that seems to be the problem
[16:50] <apachelogger> merge!
[16:50] <apachelogger> oh well
[16:50] <apachelogger> now I don't get it anymore
[16:50] <apachelogger> wth I must say
[16:51] <neversfelde> weird
[16:51] <apachelogger> Qt Linguist 4.3 is Certified for Windows Vista
[16:51] <apachelogger> Windows Vista and the Windows Vista Start button are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries.
[16:53] <apachelogger> hm
[16:54] <apachelogger> hum
[16:54] <apachelogger> --qt                    C#-Modus: eine .dll-Datei für .NET erstellen
[16:54] <apachelogger> that
[16:54] <apachelogger> looks
[16:54] <apachelogger> weird
[16:54]  * apachelogger aptget soures gettext
[16:54]  * ScottK hands apachelogger a 'c'.
[16:55]  * Quintasan grabs a chainsaw and goes to kill qmake guy
[16:55] <Quintasan> this is fcking crazy
[16:58] <Quintasan> apachelogger: can I do something like if(something) then (do something) else (do something else) in makefiles?
[16:59] <apachelogger> uh
[16:59] <apachelogger> nice
[16:59] <apachelogger> ScottK: that appears to be a translation issue
[16:59] <apachelogger> cool
[16:59] <apachelogger> oh how I love rosetta
[17:00] <apachelogger> though I wonder what that is translatable to begin with :S
[17:00] <apachelogger> Quintasan: aye, ask the google :P
[17:00] <apachelogger> Quintasan: the rules example I linked to earlier is having some if condition IIRC
[17:01] <apachelogger> Quintasan: though, why do you want to if?
[17:01] <Quintasan> apachelogger: http://pastebin.com/f9033394  <--- guess what debuild does first :D
[17:03] <yuriy> found the bug with apport-kde but i'm not sure how to deal with this. there is no main window, so how do i run some code on exec()?
[17:03] <apachelogger> Quintasan: didnt I tell you how to fix that? :{
[17:03] <apachelogger> :P
[17:04] <apachelogger> two ways actually
[17:04] <Quintasan> apachelogger: this Makefile is from upstream
[17:04] <Quintasan> apachelogger: and I need to patch it :S
[17:04] <apachelogger> oh
[17:04] <apachelogger> nice
[17:05] <Quintasan> I tried dpatch instead of quilt, but guess what - dpatch uses make clean :D
[17:05] <apachelogger> well
[17:05] <apachelogger> Quintasan: nuke your make distclean completely
[17:05] <apachelogger> and clean manually
[17:05] <apachelogger> and use your chainsaw to go after upstream
[17:06] <Quintasan> I finished Dooble, now I'm working on Silicon, this also uses QMindfuck
[17:07] <apachelogger> nice
[17:08] <yuriy> seems like i don't have to exec() the KApplication and that's fine except I get a segfault
[17:08] <yuriy> on exit
[17:08] <Quintasan> apachelogger: hmm -$(MAKE) distclean seems to do the trick :O
[17:26] <apachelogger> Sput: it appears to me gettext only supports ts/qm v1 i.e. Qt 3
[17:26] <Sput> ugh
[17:26] <apachelogger> http://www.gnu.org/software/gettext/manual/gettext.html#qt_002dformat
[17:26] <apachelogger> yet they reference 4.3.0
[17:26] <Sput> patch it then!
[17:26] <Sput> :)
[17:27] <apachelogger> Sput: I'd rather do python or java than C
[17:27] <apachelogger> especially in gnu code
[17:27] <Sput> quite understandable
[17:28] <apachelogger> <!DOCTYPE TS><TS>

[17:28] <apachelogger>   <name>Menu</name>
[17:28] <Sput> "The GNU Gettext PO format, which is commonly used in Open Source projects, is now supported by Qt Linguist."
[17:28] <apachelogger> that is clearly not v2 markup
[17:28] <Sput> what is that supposed to tell me?
[17:28] <Sput> linguist can edit PO files?
[17:28] <apachelogger> Sput: that you can translate po with linguis
[17:28] <apachelogger> t
[17:28] <Sput> ah
[17:28] <Sput> but we can't officially use PO with Qt
[17:28] <apachelogger> aldn linguist is certified for windows vista
[17:28] <apachelogger> see above
[17:29] <apachelogger> hm
[17:29] <apachelogger> the qt writer was written 2003
[17:29] <Sput> yeah, v2 markup has a version="2.0" property
[17:29] <apachelogger> Sput: hunt down Bruno Haible<EMAIL_ADDRESS>[17:29] <apachelogger> he implemented Qt 3 supports, maybe he can get us Qt 4
[17:30]  * Sput rather delegates that to someone who actually knows what he's doing
[17:30] <apachelogger> well, someone just needs to hunt him down :P
[17:30] <apachelogger> I can take care of the blaming
[17:30] <apachelogger> oh
[17:31] <apachelogger> Sput: if linguist supports editing po wouldn't it also support exporting that as qm?
[17:31] <Sput> I wonder
[17:31] <apachelogger> would just seem logical I suppose
[17:32] <apachelogger> well
[17:32] <apachelogger> it does
[17:32]  * apachelogger tests if that works
[17:32] <Sput> well yeah, you can open a .po and release as .qm
[17:32] <spstarr> hmm
[17:32] <spstarr> do we have PPA for the r6xx bits?
[17:32] <apachelogger> Sput: doesn't seem to work though
[17:32] <Sput> no?
[17:33] <Sput> hm
[17:33] <Sput> also we couldn't do that at buildtime, could we
[17:33] <Sput> we could ship the binary files though
[17:33] <apachelogger> well, it would mean that there is code
[17:34] <Sput> so what we currently have is that we can extract the strings into a .pot, we could translate that using gettext tools, but we can't create a .qm from that, right?
[17:34] <apachelogger> aight
[17:35] <Sput> because the .qm it creates isn't compatible?
[17:35] <apachelogger> right
[17:35] <apachelogger> creates Qt 3 qm
[17:35] <ScottK> Sounds like time to file some bugs.
[17:36] <Sput> - C# with Qt: The support for Qt format strings has been updated for Qt 4.
[17:36] <Sput> hmm
[17:42] <apachelogger> hm
[17:42] <apachelogger> oh
[17:43] <apachelogger> maybe linguist cant export properly because it lacks the context information
[17:45] <apachelogger> indeed
[17:46] <apachelogger> if I add the appropriate context information of a string it works
[17:47] <apachelogger> Sput: the linguist approach might still work
[17:48] <Sput> that would mean manual creation of the files, and shipping the .qm, right?
[17:49] <apachelogger> ah, nvm
[17:49] <apachelogger> context == classname
[17:50] <apachelogger> though
[17:50] <apachelogger> The translation context for QObject and each QObject subclass is the class name itself. Developers subclassing QObject must use the Q_OBJECT macro in their class definition to override the translation context. This macro sets the context to the name of the subclass.
[17:51] <Sput> that's all Q_OBJECT does? :D
[17:51] <apachelogger> well
[17:51] <apachelogger> it goes on anyway
[17:51] <apachelogger> If Q_OBJECT is not used in a class definition, the context will be inherited from the base class. For example, since all QObject-based classes in Qt provide a context, a new QWidget subclass defined without a Q_OBJECT macro will use the "QWidget" context if its tr() function is invoked.
[17:51] <apachelogger> so
[17:52] <apachelogger> all this Qt makes me wanna puke right there on my desk
[17:52] <apachelogger> Sput: I recommend that you hunt down that gettext dude or at least file a  BR
[17:52]  * ScottK suggests a laptop so apachelogger can have a better place to puke.
[17:53] <apachelogger> oh and another BR for Qt "support darn standards"
[18:09] <apachelogger> oh dear
[18:09]  * apachelogger head-desks
[18:10] <apachelogger> ScottK: I just realized that the whole ruby-gettext to main was a complete waste of resources
[18:10] <ScottK> Lovely.
[18:10] <ScottK> Well let's get it dropped out then ...
[18:10] <apachelogger> fist let me do a reference translation
[18:19] <yuriy> nixternal: you used sys.exit(0) for cancel in apport-kde, was that because of hanging or segfaulting?
[18:34] <apachelogger> ScottK: turns out I am pretty good at wasting time :S
[18:34] <apachelogger> i18n() works just fine out of the box
[18:56] <apachelogger> ScottK: so, what do I do to get it back to universe?
[18:57] <ScottK> apachelogger: If it's not directly seeded (I assume not) just drop it from B-D/depends/recommends for the package in Main and it'll get done automatgically.
[18:57] <apachelogger> okies
[18:57]  * apachelogger prepares upload
[18:57] <ScottK> Technically, it'll show up in component mismatches and some archive admin will move it.
[20:37]  * ryanakca sighs, s/quit/query/
[20:41] <refic> :)
[20:42] <shtylman> ryanakca: I think the actions area should go all the way across
[20:42] <shtylman> the white on the side doesn't quite give the same effect imho
[20:42] <shtylman> and I would put the stuff you have on the left over to the right
[20:44] <ghostcube> heh i installed the karmic langiuage packages for kde 4.3.1 working like charm in jaunty :)
[20:50] <ryanakca> shtylman: *nod*. Have much experience with JS?
[20:51] <shtylman> ryanakca: a bit
[20:52] <shtylman> ive made sides that use it
[20:52] <shtylman> *sites
[20:52] <ryanakca> shtylman: Feel like helping me out with a particularly annoying JS bug?
[20:52] <shtylman> sure...I can try
[20:53] <ryanakca> bug 389233
[20:54] <yuriy> shouldn't that be a css bug?
[20:55] <ryanakca> yuriy: Yes, but it's caused by the JS. The rounding script we use adds a blurb that messes everything up
[20:55] <shtylman> what does the rounding script add?
[20:57] <shtylman> what modifications are you allowed to make to fix this?
[20:59] <shtylman> ryanakca: like...are you able to pull the table of contents out of a table tag and use an OL instead?
[20:59] <shtylman> or can you only edit the JS/CSS?
[21:00] <ryanakca> shtylman: We're allowed to add whatever modifications to the theme we want. https://wiki.kubuntu.org/htdocs/kubuntunew/js/shadedborder.js , at the end of the file, '.sb, .sbi, .sb *, .sbi * { position:relative; z-index:1; }' is what's causing the issue
[21:00] <ryanakca> shtylman: iirc, the table of contents is an ol. We don't take care of that part though, it's done by moinmoin
[21:01] <ryanakca> Ok, so we can make whatever modifications we want to the CSS, Javascript and general page layout.
[21:01] <shtylman> gotcha
[21:01] <shtylman> why not just use images to do this? why use javascript?
[21:02] <shtylman> does this validate :) ?
[21:03]  * ryanakca forgets the original reasons... One thing is that it is *very* easy to change the appearance of the border using CSS, setup shadows, change the rounding angle, etc.
[21:03] <shtylman> gotcha
[21:04] <shtylman> how did you find that that line was causing the problem?
[21:04] <shtylman> commented everything else out?
[21:05] <ryanakca> shtylman: newz2000 did.
[21:05] <shtylman> gotcha
[21:05] <shtylman> so we don't actually know
[21:05] <ryanakca> Running it in firebug, line by line also works, until that line, of course :)
[21:05] <shtylman> I see
[21:05] <ryanakca> And modifying that one line brings *everything* crashing down.
[21:07] <shtylman> heh
[21:09] <shtylman> is there a way to turn *just* the rounding off?
[21:12] <ryanakca> shtylman: *just* the rounding? Yes. But it requires either modifying the theme or messing around with your web browser to block shadedborder.js
[21:12] <shtylman> I see
[21:12] <shtylman> any easy way to block shadeborder.js in firefox?
[21:15] <ryanakca> Might be able to tinker with scriptblocker or firebug
[21:16] <ryanakca> brb
[21:16] <shtylman> ryanakca: well, the easiest thing first is to remove z-index: 1 altogether...that seems to at least make the lines go under the contents box
[21:21] <shtylman> nvm...firebug was just acting up
[21:24] <Lure> Riddell: anybody working on updated knm package: I think bug 424606 would be nice if fixed before next alpha...
[21:24] <Riddell> Lure: last I looked knm only compiles with KDE trunk now, I haven't seen wstephenson around to enquire
[21:24] <Riddell> you're welcome to try
[21:25] <Lure> Riddell: we just grab dir snapshot from playground?
[21:25]  * Lure never looked into plasma version of knm
[21:28] <JontheEchidna> I know that there has been some work in making knm compile with 4.3
[21:29] <JontheEchidna> I'm fairly sure that it was committed in the regular playground location too
[21:30] <ryanakca> shtylman: back. Anyways. Watch what happens when I remove it... *tries*
[21:30] <shtylman> ryanakca: yea...removing it isn't great .. :)
[21:30] <ryanakca> :)
[21:30] <ryanakca> You saw?
[21:31] <shtylman> well, I removed it myself... and yea...
[21:36] <ryanakca> Well, we could drop the rounding altogether. Have one long column that goes from the top of the page to the bottom of the page, no gap.
[21:36] <shtylman> ryanakca: can you remove the routing temporarily?
[21:36] <shtylman> I want to grab a source of the page without the rounding
[21:37] <shtylman> otherwise firefox save-as grabs the rounding infected one..
[21:38] <ryanakca> shtylman: just remove the shadedborder line at the top and the <script ...> *.render('.*'); </script> lines at the end from the saved version
[21:39] <shtylman> I did...and it still has the rounding...
[21:43] <ryanakca> ... odd. I'll take it out from wiki.ryanak.ca/kubuntu/ for you, just a sec
[21:45] <shtylman> ryanakca: its ok...I just got a wget of the html file
[21:46] <ryanakca> shtylman: done
[21:47] <shtylman> k
[22:14] <shtylman> ryanakca: fixed :)
[22:14] <shtylman> ryanakca: ok...so the fix I have is all in the shadedborder.js file
[22:15] <shtylman> ryanakca: http://paste.ubuntu.com/270528/
[22:15] <shtylman> thats one part of it
[22:16] <shtylman> ryanakca: http://paste.ubuntu.com/
[22:16] <shtylman> the other part
[22:16] <shtylman> http://paste.ubuntu.com/270529/
[22:16] <shtylman> my bad
[22:17] <shtylman> ok..so the first part is to replace lines 236 or so in the js file
[22:17] <shtylman> and the second part replaces the last few lines
[22:23] <ryanakca> shtylman: Awesome. I'll look at it after supper, thanks :)
[22:24] <shtylman> no prob...enjoy
[22:35] <JontheEchidna> vorian: could you look at bug 427677 for a second ack please?
[22:36] <JontheEchidna> hmm, new upstream release again...
[22:36] <JontheEchidna> it's at <IP_ADDRESS> now (translations)
[22:37] <JontheEchidna> maybe it'd be better to just get this FFe through, then I can upload <IP_ADDRESS> after since it's a bugfix release


[05:07] <Kilos> morning all
[05:08] <nhaines> Morning, Kilos.
[05:08] <Kilos> you still in sunday nhaines  ?
[05:08] <nhaines> Yes, but only for another 2 hours.  :)
[05:08] <Kilos> haha sleep tigh then
[05:09] <Kilos> we 7 am monday
[05:09] <Kilos> tight
[05:12] <nhaines> Haha, thanks!  I have another couple of hours left before I get to sleep.  :)
[05:12] <Kilos> whew
[07:18] <Kilos> hi JanC
[08:12] <dholbach> good morning
[08:13] <Kilos> morning dholbach
[08:14] <dholbach> hi Kilos