[00:37] <coppro> hm... 11 days till release... should I start upgrading now?
[00:49] <fmarier> would anybody be willing to sponsor a sync to fix this fairly serious bug? https://bugs.launchpad.net/ubuntu/+source/docvert/+bug/286146
[01:02] <ScottK> fmarier: I'll have a look at it.
[01:02] <fmarier> ScottK: thanks
[01:02] <ScottK> fmarier: Thanks for taking interest in a downstream project.
[01:03] <fmarier> one question though: when should one subscribe motu-release to a bug?
[01:03] <fmarier> would that be for an SRU?
[01:04] <ScottK> If it's post feature freeze and the change adds a new feature or after the RC is release, we'll approve all uploads.
[01:04] <jdong> fmarier: SRU is motu-sru, btw
[01:04] <ScottK> Until RC for Universe we trust developers to do bug fix updates.
[01:04] <fmarier> ok, thanks, that clears things up
[01:05] <ScottK> For packages in Main, ubuntu-release is approving all uploads now.
[01:07] <fmarier> so if my fix had come after the 23rd, then i would have had to go through motu-release?
[01:14] <ScottK> fmarier: Yes.
[01:15] <ScottK> fmarier: Looks like persia already gave it sponsors approval, so it's in the archive admins hands to sync (probably tomorrow).
[01:15] <fmarier> ScottK: wow, that was fast! :)
[01:15] <fmarier> thanks
[01:16] <ajmitch> hello fmarier
[01:16] <fmarier> hi ajmitch
[01:16] <ScottK> fmarier: Myself I'll tend to pay more attention to sponsorship requests when it's the Debian maintainer suggesting it.  I'm not alone in that.
[01:18] <ajmitch> ScottK: yeah, you'd generally expect a very good knowledge of the package in question in that regard
[01:19] <ScottK> ajmitch: Yes.  Plus I like to encourage repeat business.
[01:28] <ajmitch> oh, google gadgets released, I wonder when we'll see the first packages pop up
[01:29] <ajmitch> or it's probably old
[06:28]  * NCommander is finally glad the gnat-4.2 transition is nearly done
[07:13] <dholbach> good morning
[07:17] <iulian> Morning Daniel.
[07:18] <dholbach> hi iulian
[07:18] <dholbach> warp10: there's another Colangelo that commented on your behindmotu interview :)
[07:21] <warp10> dholbach: oh, looks like we are "relatives", in a certain manner. Ubuntu helps genealogy too: cool! :D
[07:22] <dholbach> :)
[07:36] <slytherin> anyone using openvpn here? I am looking for someone to try reproducing a bug and mark it as confirmed.
[07:37] <slytherin> The bug is in openvpn plugin of network manager
[07:37] <Koon> slytherin: which bug is it ?
[07:38] <slytherin> Koon: bug 285138
[07:40] <Koon> slytherin: I confirm it does not import the certificates/keys
[07:40] <Koon> slytherin: i'm marking it as confirmed
[07:41] <slytherin> Koon: Thanks. :-)
[07:41] <persia> slytherin, Although this worked for you, in general you may find that the population of #ubuntu-bugs has more people willing to test things quickly.
[07:42] <slytherin> hmm. Will keep in mind. :-)
[07:44] <\sh> moins
[07:44] <slytherin> persia: I have files the bug we discussed. 286095 and 286226. I have made sure that packages compile with intrepid pbuilder chroot.
[07:44] <\sh> any thoughts on bug #250425 ?
[07:45] <persia> bugs #286095 and #286226
[07:46] <persia> slytherin, This means we can drop the duplication in libjdom-java, right?
[07:47] <slytherin> persia: yes
[07:47] <persia> slytherin, Have you already filed the removal bug?
[07:47] <slytherin> persia: No. I will do that once these syncs are done.
[07:47] <persia> OK.
[07:48] <persia> jta is already ACK'd.  verifying statcvs now.
[08:46] <stochastic> hello, I'm new to packaging/bug fixes/etc... but this bug: https://bugs.launchpad.net/debian/+source/cecilia/+bug/236251/ has been hanging around for a while now and has a fix ready to be applied
[08:53] <stochastic> anyone want to give me some direction on this?
[08:53] <persia> stochastic, Sure.
[08:54] <laga> bah. i was already looking at it :)
[08:54] <persia> laga: go ahead then :) I have other stuff to do, but I like cecila
[08:55] <stochastic> thanks guys
[09:01] <laga> stochastic: is the fix in that bug everything that's needed to get cecilia up and running on debian?
[09:01] <laga> err, ubuntu.
[09:03] <stochastic> laga: yes, that one change successfully fixed it on my machine
[09:04] <stochastic> it needs to be applied in the .deb, before it's installed to the system; editing the /usr/share/cecilia/lib/prefs.tcl file directly does nothing
[09:08] <didrocks> morning o/
[09:08] <laga> okay. i hear that cecilia is broken with csound 5.x, that's why i'm wondering
[09:10] <YokoZar> Is a minor upstream bugfix update better as an SRU or a backport?
[09:10] <YokoZar> (wine 1.0.1)
[09:10] <stochastic> laga: I haven't extensively tested it, I could do a couple quick tests
[09:10] <laga> stochastic: yes, please do that
[09:13] <stochastic> laga: I just successfully played a file with cecilia & csound 5 - I'll keep running some tests to see if any issues pop up but everything seems to work as expected
[09:21] <stochastic> laga: cecilia itself does throw some errors every now & then, but none of them are fatal, and it looks to be more to do with it's code than any csound5 interaction
[09:22] <laga> okay. if it's usable, then we can proceed with the debdiff
[09:22] <laga> does the cecilia package have a patch system?
[09:23] <stochastic> ??? I'm brand new to packages I don't know what you're asking
[09:24] <laga> well, we need to introduce a change to the package which is not in the orig.tar.gz - the orig.tar.gz is the compressed file we get from upstream
[09:24] <laga> usually, you will add a patch system which will apply the necessary changes during the build process
[09:26] <stochastic> well all the cecilia packages are numbered with ubuntu1 in the repos if that means anything to you
[09:26] <stochastic> and I see a .diff.gz file on the packages site
[09:26] <laga> yeah, the .diff.gz holds debian/
[09:27] <laga> ah, it has a patch system. debian/patches exists
[09:28] <laga> and it uses dpatch.
[09:29] <laga> stochastic: you need to add the patch to the patch system and generate a debdiff
[09:29] <stochastic> can you point me to a howto on this, I'm really a newbie around packaging/maintaining
[09:30] <laga> stochastic: https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff?action=show&redirect=MOTU%2FRecipes%2FDebdiff
[09:30] <laga> sure
[09:30] <laga> stochastic: that guide does not show you how to use dpatch
[09:31] <stochastic> is there one around that does?
[09:32] <laga> https://wiki.ubuntu.com/PackagingGuide/Howtos/Dpatch - it's as simple as that. just run dpatch-edit-patch my-new-patch.dpatch and it will create a copy of the package. apply your patch inside that copy, hit ctrl+d and a new patch will have been created (verify that it's correct by looking in debian/patches/)
[09:32] <laga> don't forget to add your patch to  debian/patches/00list
[09:32] <laga> all instructions assume that you are in the top level directory of the package
[09:42] <stochastic> laga: I really am over my head here, it's 1:40am here, and I've got homework that needs my attention
[09:43] <stochastic> I'm not even getting very far with registering a GPG key
[09:43] <stochastic> nevermind the diff file
[09:46] <persia> stochastic, You don't need a GPG key.
[09:46] <stochastic> the fist step in the first howto warned me that I did
[09:46] <persia> stochastic, If you don't have one, you get a warning about being unable to sign the package.  This is only important if you were going to upload it to a restricted-access repository.
[09:46] <persia> Which HOWTO?  I'll fix it.
[09:47] <stochastic> https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff?action=show&redirect=MOTU%2FRecipes%2FDebdiff
[09:47] <laga> stochastic: then do it tomorrow :)
[09:48] <stochastic> thanks, I'll still read through that stuff eventually, it's good for me to learn
[09:51] <persia> stochastic, Does https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff look better now?
[09:51] <persia> dholbach, What is the point of setting environment variables and configuring GPG for debdiffs?
[09:52] <dholbach> persia: environment variables for dch
[09:52] <persia> dholbach, OK.  Makes sense.
[09:53] <stochastic> that's clearer, but still looks a little latin, I guess I just need to do some reading to orient myself with all this stuff.  thanks.
[10:00] <laga> stochastic: feel free to ping me when you're having problems. i'm in GMT+2.
[10:00] <laga> and i gotta run now :)
[10:19] <didrocks> I have a question on build-stamp best practice. I see often a "rm build-stamp" on the clean target, but never a touch "build-stamp" to create it. Does doing "build: build-stamp" create it automatically?
[10:20] <persia> didrocks, It depends on how make is configured.  By default, no.
[10:22] <didrocks> persia: can you give me a tip for this rules file, please? http://paste.ubuntu.com/60044/
[10:35] <persia> didrocks, I think it's probably useless in that case.  Try running debuild in the package directory, and then debian/rules clean.  This should result in no changes.
[10:35] <persia> For extra safety, do this in a temporary directory.
[10:36] <persia> (as it will overwrite the source package)
[10:53] <didrocks> persia: yes, you're right :) But I still can't see how the flag file "build-stamp" is created (I see the rm in clean1 target, but not its creation)
[10:56] <persia> didrocks, Is it created?  Maybe dpatch.make does it.
[10:58] <didrocks> persia: don't this that dpatch.make creates it (it deals with patch/unpatch target only apparently)
[10:59] <persia> didrocks, Could you rephrase?  I couldn't parse that.
[10:59] <didrocks> oupss, sorry :)
[11:00] <didrocks> persia: I don't thing that dpatch.make creates the build-stamp file flag, this one seems to deal only with patch/unpatch target
[11:00] <didrocks> s/thing/think
[11:00] <persia> didrocks, OK.  Does it get created when you run debuild ?
[11:02] <didrocks> I must confess that I do not know/can't remember where those flag files are created when building
[11:03] <persia> didrocks, They would be created in the base directory usually.  In any case, the rm line would tell you where they would be.
[11:10] <didrocks> persia: oh, my bad, touch $@ touched it :(
[11:11] <persia> didrocks, There you go.  Sorry I missed that.
[11:11] <didrocks> persia: thanks a lot for your time :)
[11:15] <AnAnt> when is superm1  available ?
[11:16] <persia> AnAnt, Variable, but typically in relatively sane times for UTC+5
[11:16] <persia> (at least according to LP : no guarantee that's the right timezone)
[11:34] <AnAnt> well, I duno what to do
[11:35] <AnAnt> oops, wrong window
[14:12] <persia> Does anyone happen to know why I get a pan0 network device on a machine *without* bluetooth?
[14:16] <Laney> persia: I appear to have one too, odd
[14:17] <persia> Laney, And this is with no bluetooth hardware support, right?
[14:17] <sistpoty|work> hi folks
[14:18] <Laney> persia: Correct. This machine has never seen bluetooth hardware
[14:18] <Laney> hi sistpoty|work
[14:18] <sistpoty|work> hi Laney
[14:18] <persia> Hmm.  I suspect that's a bug.
[14:20] <directhex> pan0's labyrinth.
[14:20] <Laney> ho ho
[15:16] <G__81> hi all
[15:17] <persia> G__81, Hey.  Did you find something on which to work yet?
[15:17] <G__81> persia, yeah i have started with bug triaging yesterday earned some points. I have installed Ibex so could do some testing and triage today too :) and then get in the bug fixing mode too
[15:18] <persia> G__81, Excellent!  Good luck.
[15:18] <G__81> persia, thanks :)
[15:18] <G__81> and wish you the same
[15:20] <G__81> persia, can you give me the link for the bugs to be triaged ?
[15:20] <persia> G__81, #ubuntu-bugs is the place to get that answer :)
[15:21] <G__81> hmm ok i am on that channel too lets see if i get there
[16:25] <jcastro> https://wiki.ubuntu.com/UbuntuOpenWeek/Prep
[16:25] <jcastro> Still looking for volunteers!
[16:27] <G__81> hi jcastro i am new but i dont know how i could help
[16:28] <G__81> hi jcastro i could help if there is something that i could do :)
[16:28] <jcastro> I don't know, what is it you can do? :D
[16:28] <G__81> i am currently into triaging. I have been doing contributions to fedora so i am kind of new to ubuntu's processes :)
[16:29] <jcastro> ah no worries then, you'd probably be a better target as a participant than someone running a session then
[16:30] <jcastro> G__81: openweek is basically designed to be sessions for people like you
[16:31] <G__81> oh ok there are many things that ubuntu does extra when compared to fedora so these things are new :)
[16:31] <G__81> yeah thanks
[16:31] <G__81> where do people get this information are these communicated in some mailing lists
[16:31] <G__81> saying that an open week is gonna happen
[16:31] <G__81> so that i could subscribe ?
[16:31] <jcastro> yeah, it hasn't been announced yet but it will be on ubuntu-devel-announce
[16:32] <jcastro> I am still gathering people so that when it is announced the schedule isn't empty. :D
[16:32] <jcastro> you'll want to subscribe to ubuntu-devel, and ubuntu-motu as well
[16:33] <G__81> yeah i am in motu but heard that ubuntu-devel is moderated
[16:33] <persia> G__81, That it's moderated only means you can't post : you're encouraged to read.
[16:34] <G__81> oh :) i didnt know that
[16:34] <G__81> then i could subscribe :)
[16:34] <G__81> right now
[16:36] <james_w> smarter: congratulations
[16:40] <smarter> james_w: thanks :)
[17:11] <RainCT> smarter: congrats!
[17:11] <smarter> hey RainCT, thanks :)
[17:13] <G__81> hi smarter congrats
[17:13] <G__81> hi RainCT
[17:14] <RainCT> Hi G__81
[17:15] <smarter> thanks too G__81 (:
[17:17] <RainCT> fabrice_sp: I don't think you need the .dirst file for itsalltext (and one of the entries is wrong, btw, which confirms that it isn't necessary)
[17:18] <RainCT> fabrice_sp: beside that it looks OK to me, but better wait for asac or someone else to answer if you want a reliable opinion :)
[17:29] <asac> RainCT: yes. the .dirs should be removed imo
[17:29] <asac> unless a package wantes to provide an empty dir there is no need for it
[17:29] <asac> at least thats my understanding of this ;)
[17:30]  * sistpoty|work calls it a day ... cya
[17:31] <RainCT> asac: Yep, the .dirs isn't necessary (it may be useful in other cases beside wanting an empty dir, like when files are moved manually with install/mv/etc, but definitely not with dh_links/dh_install). I told him to ask you for the case there's some other problem (though I doubt it, extensions are rather straightforward) :)
[17:33] <persia> asac, RainCT .dirs is also useful to work around broken upstream install rules.
[17:34] <persia> RainCT, When files are installed with install, one can provide the right arguments to create the directory.  mv shouldn't be used : cp is marginally better, and install generally preferred (whether wrapped in dh_install or alone)
[17:35] <RainCT> persia: yep, the mv was a lapsus :)
[17:50] <G__81> Hi RainCT i am working on triaging and i am enjoying it, apart from that how else can i contribute
[17:50] <G__81> in addition to that i mean
[18:08] <RainCT> G__81: Yeh, I remember those days when I started triaging... :).  Well, beside that there is of course packaging, bug fixing, etc.
[18:08] <RainCT> G__81: and then more unrelated stuff like translating Ubuntu to your language, writing documentation and all that
[18:09] <pochu> go dfiloni and nxvl! :)
[18:10] <dfiloni> thanks pochu :)
[18:11] <\sh> RainCT: you forget coding some weired python cruft ,->
[18:11] <G__81> Have not done packaging at all :(
[18:11]  * G__81 is nervous about packaging stuff
[18:12] <sebner> \sh: \o/
[18:12] <\sh> packaging is very handy, especially when your devs at work are coming to you with requests for newest crack for ubuntu....*grmpf*
[18:12] <RainCT> \sh: that's implicit ;P
[18:13]  * \sh wants to code again...
[18:13]  * sebner feels slightly ingored by \sh :P :P :P
[18:13] <\sh> sebner: dude, start fixing crossfire-client-gtk2 please on x86_64...it gives me two chars instead of one in inputboxes...i386 does the right thing ,-)
[18:14]  * RainCT hugs \sh 
[18:14] <\sh> sebner: nanana
[18:14] <G__81> RainCT, how do i start off with packaging
[18:14] <RainCT> sebner: and fix my GNOME ^^
[18:14] <\sh> RainCT: ^5
[18:14] <sebner> RainCT: you can't fix GNOME. It has to be b0rken. It has to be insane! GNOME FTW! :D
[18:14] <G__81> RainCT, some starting point and then some team where in i could join and package something and send it for review
[18:14] <G__81> is that a simple process
[18:14] <G__81> ?
[18:15] <sebner> \sh: lol, haven't seen you for a while now. how are you mate? :)
[18:15] <\sh> sebner: busy with RL work :(
[18:16] <\sh> sebner: I feel like that I'm some kind of Ubuntu Server entrepeneur for real commercial apps
[18:17] <\sh> bleeding edge usage of ubuntu yay ,->
[18:17] <RainCT> G__81: Uhm, didn't I tell you already? Just find somethin easy to fix (either from https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize or anywhere else, or even some bug which annoys you and you think is easy to fix) and try to get a fix ready for it following the info on the wiki, then attach the debdiff to the bug and subscribe ubunut-universe-sponsors or ubuntu-main-sponsors (depending if the package is in universe or main).
[18:17] <sebner> \sh: what can be better ;P
[18:17] <RainCT> G__81: If you think you need some more help than just the wiki then you could join the mentoring programme
[18:17] <\sh> including running windows server + windows powershell under vmware-server on ubuntu ,->
[18:17] <sebner> \sh: oh dear, what can be worse ^^
[18:18] <\sh> sebner: adobe flash media server on RedHat Enterprise Linux
[18:18] <\sh> sebner: windows never crashed for me while running under vmware-server ,_>
[18:25] <aos101> If I want to do a SRU for a package in main, do I just subscribe ubuntu-sru and they can upload the debdiff to -proposed, or do I need to also subscribe ubuntu-main-sponsors to first get it uploaded to -proposed?
[18:26] <RainCT> aos101: you'll need both
[18:28] <aos101> RainCT: Shall I subscribe ubuntu-main-sponsors first to get it uploaded, or just subscribe both at the same time?
[18:29]  * RainCT is not sure
[18:38] <AnAnt> superm1: ping
[18:38] <aos101> RainCT: Ok Thanks.  I'll probably subscribe both at the same time, and they can see what I'm trying to do.
[18:53] <POX> oh, MIR bug means a package will be included in Ubuntu's main (/me wondered what doko wants from him ;)
[18:54] <POX> "good maintainance in debian" hehe ;)
[18:54] <doko> yes, looking at component mismatches
[18:56] <POX> doko: btw, you want to sync pyenchant with Debian if it was build with enchant 1.4.1 or later
[18:56] <doko> too late, that's for jaunty then
[18:58] <POX> doko: please try this in Ubuntu: python -c 'import enchant'
[18:58] <POX> if it will fail you *need* to sync
[18:59] <doko> POX: doesn't crash on amd64
[19:00] <POX> ok, so I guess it was built with one of previous versions
[19:01] <doko> trying to rebuild ...
[19:04] <POX> (actually enchant is the one with fixes, pyenchant has to be rebuilded only)
[19:05] <POX> version in Ubuntu probably has broken shlibs
[19:06] <csilk> HI, would it be possible for somebody to take a very quick look over the 2nd section of this license and help me decide if it's suitable for the Ubuntu repositories or not?
[19:06] <csilk> http://pages.cs.wisc.edu/~ghost/gsview/LICENCE
[19:06] <csilk> *Section 2 Restrictions
[19:07] <ScottK> doko: Since pyenchant is in Universe it's not actually too late.
[19:07] <doko> $ python -c 'import enchant'
[19:07] <doko> Traceback (most recent call last):
[19:07] <doko>   File "<string>", line 1, in <module>
[19:07] <doko>   File "enchant/__init__.py", line 90, in <module>
[19:07] <doko>     import _enchant as _e
[19:07] <doko> ImportError: No module named _enchant
[19:08] <doko> ScottK: but we have to be quick before pitti approves the MIR ;p
[19:08] <ScottK> Yes
[19:08] <POX> doko: just sync echant
[19:08] <POX> and then rebuild pyenchant
[19:10] <ScottK> Enchant is already in Main, so that'll need release team approval.
[19:11] <james_w> csilk: "Distribution of the Program or any work based on the Program by a commercial organization to any third party is prohibited if any payment is made in connection with such distribution,"
[19:11] <csilk> james_w,  that's the bit I was concerned about
[19:11] <csilk> To me, that looks like a big no no
[19:11] <POX> all latest NMUs in enchant (Ubuntu is missing 2 of them) were aproved by Debian's RMs so I guess Ubuntu ones will not mind
[19:11] <james_w> csilk: yeah, me too, but I'm no expert.
[19:11] <ScottK> POX: We've already got the non-matching dicts patch.  Was there something else that was important in Enchant?
[19:11] <james_w> csilk: also, does the app link against anything GPL?
[19:12] <csilk> james_w,  no it's all under that one license as far as I can see
[19:12] <doko> ScottK: https://bugs.edge.launchpad.net/ubuntu/+source/pyenchant/+bug/286542
[19:12] <POX> ScottK: see enchant's changelog, you need all of them
[19:12] <ScottK> james_w and csilk: Such restrictions are acceptable in Multiverse.
[19:13] <csilk> ScottK,  is there a written policy I can refer to for future reference?
[19:13] <ScottK> POX: So it looks like except the shlibs bump we have everything already.
[19:14] <ScottK> csilk: Not that I've found.  Bottom line is that as long as it's generally distributable it can go into Multiverse.  No commercial distribution is one standard reason to get stuck there.
[19:15] <csilk> ScottK, but there is a possibilty that app could end up being distributed commerically if it's in multiverse
[19:15] <csilk> *that the app
[19:15] <POX> ScottK: if you rebuild pyenchant with current Ubuntu's enchant version, it will not work, see doko's traceback
[19:15] <ScottK> POX: Right.  I think I got that now.
[19:15] <RainCT> csilk: but then that's the problem of the person distributing it, not Ubuntu's
[19:16] <ScottK> csilk: It's distributable by Canonical/Ubuntu and that's what matters.
[19:16] <ScottK> csilk: Any Ubuntu derivative REALLY needs to review licenses in multiverse before distributing packages from there.
[19:17] <csilk> Yeah I see your point RainCT, ScottK. Any derivative being distributed is not Canonicals problem therefore the app is fine for inclusion in multiverse. fantastic, thanks for the help :)
[19:18] <superm1> AnAnt, pong
[19:18] <ScottK> csilk: One final piece of advice: Multiverse is not Free software and so tends to be a low priority for inclusion.  Just because it could be included doesn't mean MOTU will be motivated to review and upload it.
[19:19] <ScottK> Odds are significantly better if the license is fixed.
[19:19] <RainCT> omg Ubuntu just got mad.. /me restarts
[19:21] <csilk> ScottK,  yeah I understand, having a mentor really helps in that situation though.
[19:23] <RainCT> weird.. aptitude broke :'(
[19:24] <RainCT> sebner: I think I'm starting to support your theory :)
[19:25] <sebner> RainCT: well, I use apt :P
[19:27] <Simpson_Penner_> ihr seid alle idioten
[19:27] <RainCT> That *really* weird.. Epiphany freezed, half a minute later I killed it, then when I tried to start it again it complained about some missing bonobo thing (about which Google doesn't know anything), I did sudo aptitude reinstall epiphany-browser and now aptitude segfaults (but epiphany works again after restarting) o_O
[19:28] <Simpson_Penner_> uff
[19:28] <RainCT> Hobbsee: kick him ^
[19:28] <Simpson_Penner_> jo tu das xD
[19:29] <Simpson_Penner_> nur dumm das das hier keiner kann haha
[19:29] <Simpson_Penner_> looser
[19:29] <RainCT> sebner: now I can add a weird troll to my list LOL
[19:29] <Simpson_Penner_> allerg
[19:29] <Simpson_Penner_> reasg
[19:29] <Simpson_Penner_> rs
[19:29] <Simpson_Penner_> gr
[19:29] <Simpson_Penner_> hz6t
[19:29] <Simpson_Penner_> h
[19:29] <Simpson_Penner_> 6
[19:29] <Simpson_Penner_> u
[19:29] <Simpson_Penner_> drh
[19:29] <Simpson_Penner_> 56
[19:29] <ScottK> !ops
[19:30] <Simpson_Penner_> utzj
[19:30] <Simpson_Penner_> u
[19:30] <Simpson_Penner_> zk
[19:30] <ScottK> PriceChild: Thank you.
[19:30] <sebner> grr
[19:30] <sebner> Bad german troll
[19:37] <AnAnt> superm1: I need your help with dkms !
[19:38] <AnAnt> superm1: I added dkms support to sl-modem, but it only compiles one module (slamr) , but fails to compile ungrab-winmodem
[19:38] <AnAnt> superm1: and make.log doesn't give any useful info
[19:38] <superm1> AnAnt, normally when you compile it, do you use the same make command for building both modules?
[19:38] <AnAnt> superm1: no, another make command
[19:39] <superm1> AnAnt, well then you'll need to specify that other command in your dkms control file too
[19:39] <AnAnt> superm1: I did, http://pastebin.com/mfc42622
[19:39] <superm1> by using several MAKE directives, eg MAKE[0], MAKE[1]
[19:40] <AnAnt> that's what I've done, please look at pastebin url
[19:40] <superm1> AnAnt, do you possibly need to be pushd'ing in your second directive then?
[19:40] <superm1> i'm not sure the structure of sl-modem's stuff
[19:41] <AnAnt> superm1: I tried that, but it was of no use
[19:41] <superm1> AnAnt, well the easiest method to debug then, switch into the directory that's being used for building, and then run that make command as you see there
[19:41] <superm1> make sure that it spits out the module properly
[19:42] <AnAnt> superm1: done that, and it worked !
[19:42] <superm1> AnAnt, then are you sure the second directive is being actually called in the first place when it fails?
[19:43] <AnAnt> superm1: how would I know ?
[19:43] <POX> f*ck, pyenchant fails in unstable as well
[19:43] <superm1> AnAnt, well that make.log should show, and/or when you do dkms build you may see it
[19:43] <AnAnt> superm1: dkms says: Error!  Build of ungrab-winmodem.ko failed for: 2.6.27-7-generic (i686)
[19:43] <AnAnt> Consult the make.log in the build directory
[19:44] <AnAnt> superm1: make.log says: DKMS make.log for sl-modem-2.9.11~20080817 for kernel 2.6.27-7-generic (i686) Mon Oct 20 20:41:43 EET 2008
[19:44] <AnAnt> /var/lib/dkms/sl-modem/2.9.11~20080817/build
[19:44] <AnAnt> and that's it !
[19:44] <superm1> AnAnt, maybe try just putting it all in the first MAKE directive ,like this : "pushd ${dkms_tree}/sl-modem/2.9.11~20080817/build; make -C drivers KERNEL_DIR=$kernel_source_dir KVERS=$kernelver ; make -C ungrab-winmodem KERNEL_DIR=$kernel_source_dir KVERS=$kernelver; popd"
[19:46] <AnAnt> superm1: that worked !
[19:47] <superm1> AnAnt, those different MAKE directives are intended to be used when trying to do different make commands for different kernels usually, i don't believe they are sequentially executed in any case, but i'd have to double check
[19:47] <AnAnt> so I should just keep it like that ?
[19:48] <AnAnt> I mean both in same MAKE directive ?
[19:50] <superm1> AnAnt, just remove the second MAKE directive
[19:52] <sebner> superm1: btw, does your ipod-convience also works with the new ipod touch2? if yes, *how* good?
[19:54] <superm1> sebner, if someone will trade me their touch2 for my touch, i'll tell you :)
[19:54] <sebner> superm1: hrhr ^^, /me is thinking about getting one for christmas but you know .. touch and phone with ubuntu ... :\
[19:54] <superm1> sebner, surely if you can jailbreak the touch2, it should work
[19:55] <sebner> superm1: /me is wondering what's your magic behind jailbreaking
[19:55] <superm1> sebner, i'm personally really pissed about the nike stuff being built into touch2
[19:56] <sebner> superm1: why?
[19:56] <superm1> sebner, well now I either have to go buy a touch2, or buy a nano to use nike+
[19:56] <superm1> i was hoping to just spend 30 bucks on the dongle when they released the ipod touch software for it
[19:56] <superm1> sebner, well the ipod-convenience stuff only works if you jailbreak it, so you'll have to read about that stuff
[19:58] <fabrice_sp> Hi RainCT: does it mean that if I delete the dirs file for itsalltext, it would be ok ;-) (by the way, it comes from debian packaging)
[19:58] <RainCT> fabrice_sp: yep
[19:58] <sebner> superm1: kk, well I'm thinking about nano or touch. nano would clearly the easier decision ^^
[19:59] <fabrice_sp> RainCT: great! I'll change that and upload now (and also the change for vimperator)
[19:59] <POX> doko: wait with that sync, looks like after latest changes in enchant I need to fix something in pyenchant as well
[19:59] <fabrice_sp> thanks
[20:00] <doko> POX: I don't think we can have a sync for enchant before the RC, but you should point this out to seb128
[20:01] <POX> doko: I'll fix it in Debian and then we'll see if it will be enough for Ubuntu
[20:01] <POX> looks like .so file is in wrong dir now, I'll check why
[20:04] <AnAnt> superm1: thanks a lot !
[20:04] <superm1> AnAnt, no prob.
[20:05] <AnAnt> superm1: btw, sl-modem supports both module-assistant & dkms
[20:06] <superm1> AnAnt, neat.  i'll have to take a look at how you implemented the combination of both when it lands in a source package in the archive at some point
[20:06] <AnAnt> superm1: I can upload to debian mentors if you want
[20:07] <superm1> AnAnt, my time to give it a good look is low now, so i'll look later :)
[20:07] <AnAnt> ok
[20:29] <fabrice_sp> asac: what do you you mean with your last comment on bug #286225?
[20:31] <fabrice_sp> (this one: https://bugs.launchpad.net/ubuntu/+source/vimperator/+bug/286225)
[20:32] <ScottK> superm1: Thanks for jumping in on the brightness related bugs.
[20:34] <superm1> ScottK, unfortunately that one kernel bug causes it to be very difficult to debug the functionality of the rest of them.  i really hope the kernel bug is fixed or this is going to be a very bad situation
[20:34] <ScottK> superm1: Right.  Well at least you understand the situation.  All I could do if fix guidance-power-manager not to crash in response.
[20:35] <superm1> ScottK, yeah i've been aware of it for a while, wgrant pointed out a lot of the details for me, so i've assembled at least what i know about it
[20:35] <ScottK> superm1: I think it's potential SRU material if you can get it sorted.
[20:36] <ScottK> superm1: Speaking of SRU, how's bluetooth going?
[20:40] <superm1> ScottK, well kernel guys should be looking at this already to try to fix before 8.10 is live.
[20:40] <superm1> ScottK, as for bluetooth, upstream's accepting a majority of my patch
[20:40] <superm1> ScottK, still has missing pieces for the integration, so at the going rate it will likely be a post release SRU
[20:41] <ScottK> superm1: That's not horrible.  Nothing until Jaunty would have been horrible.
[20:41] <ScottK> superm1: Thanks for working on it.
[20:41] <ScottK> superm1: We are planning on fielding KDE 4.1.3 in intrepid-updates so anything there we will automatically get.
[20:42] <superm1> ScottK, well i'm not sure how close to releases KDE trunk is, but automatically getting it would be awesome
[20:42] <ScottK> superm1: Trunk is towards 4.2 now.  We can probably try to backport it.
[20:43] <ScottK> So you might discuss how much of this they'll allow into the 4.1 branch.
[20:43] <POX> ScottK: I have pyenchant fixed in DPMT repo now, could you check if it works in Ubuntu?
[20:43] <superm1> ScottK, once it's all stable we'll see.  backporting it will be very easy in any case
[20:43] <ScottK> With our current enchant or the one from Debian?
[20:44] <ScottK> POX: ^^
[20:44] <POX> Ubuntu's enchant, I know it works with Debian's
[20:44] <ScottK> OK
[20:44] <ScottK> POX: Is build, install, import enchant a sufficent test?
[20:44] <POX> yup
[20:46] <ScottK> POX: 1.4.2-1 "UNRELEASED"?
[20:46] <POX> no, lenny branch
[20:46] <ScottK> Ah
[20:48] <ScottK> POX: Bulding now.
[20:50] <zooko> Folks, I think there is a problem in the way Ubuntu packages the Crypto++ library and the way Ubuntu's version of Python dlopen's it.
[20:50] <zooko> http://www.gnu.org/software/gcc/faq.html#dso
[20:50] <zooko> I'm not sure exactly where the problem lies, yet.
[20:51] <zooko> But symbols exported by libcryptopp.so dpon'
[20:51] <ScottK> POX: It wants libenchant-dev > 1.4.2-3.3 and I don't have that here.
[20:51] <zooko> don't get resolved properly when they are also used by a Python module that I wrote.
[20:52] <POX> ScottK: lower it to .3.1 and check if it works
[20:53] <ScottK> OK
[20:55]  * POX needs to update his Ubuntu chroot
[20:57] <POX> kf
[20:57] <POX> sorry
[20:58] <ScottK> POX: Works
[20:59] <POX> hmm... so why when I builded it with -3.1 without the patch I created today, it worked in Debian?
[20:59] <ScottK> POX: Because 3.1ubuntu1 has the patch from 3.3?
[21:00] <POX> but it doesn't have the more important one from 3.2
[21:00] <POX> anyway, I will upload pyenchant -3 with enchant -3.3 in B-D and then create a version for Ubuntu
[21:01] <ScottK> Dunno.  Don't have the mental bandwidth currently to deal with it.
[21:01] <ScottK> POX: I can do the Ubuntu one.  It's what I just built with a bit of changelog futzing.
[21:06] <ScottK> DktrKranz: Would you please approve Bug #286542.  I've confirmed it works, but it's more of a merge now.  I'll upload after approval.
[21:07]  * DktrKranz looks
[21:08] <POX> ScottK: I've changed changelog (added more info) if you want to have as small delta as possible
[21:09]  * POX is commiting
[21:09] <ScottK> POX: OK.  I'll look.  I'm calling this 1.4.2-2ubuntu1
[21:10] <DktrKranz> ScottK, POX: speaking about rdepends, do new APIs break anything?
[21:10] <POX> pyenchant's rdepends? no (at least when I tested it last time)
[21:11] <ScottK> DktrKranz: Go with what POX said.  It's totally broken now in any case.
[21:11] <POX> and most important rdependency - gaupol - is working fine (gaupol is mine as well :)
[21:11] <DktrKranz> heh
[21:12] <ScottK> POX: Did you commit your change?
[21:12] <POX> wait a sec
[21:12] <POX> done
[21:12] <DktrKranz> ScottK, done.
[21:16] <RainCT> If someone here knows GTK, how can I get the absolute position (x,y) of an Allocation object?
[21:17] <ScottK> POX: Got it.  Thanks.
[21:17] <ScottK> DktrKranz: Thanks.
[21:21] <ScottK> POX, doko, DktrKranz: pyenchant uploaded.
[21:22] <DktrKranz> thanks
[21:25]  * DktrKranz grumbles at italian {Ubuntu,Debian} mirrors...
[21:26] <sebner> DktrKranz: it's italian ones. what do you expect :P
[21:26] <DktrKranz> sebner, borrow them some bandwith
[21:26] <txwikinger> ROFL
[21:27] <sebner> NOOOOOO. All the 16mbit are mine mine. My treasure, my treasure, MIIIIIIIIIIIIINNNNNNNNNNNEEEEEEEEEEE
[21:27] <txwikinger> Don't use British ones, or your assets might be frozen due to the Anti-Terrorsim Act 2001
[21:27] <DktrKranz> sebner, they're located at "GARR", pronounce it "GRRRRRR"
[21:27] <sebner> lol
[21:30] <sebner> DktrKranz: btw, no SRU for feisty anymore !!!!! :D :P :D
[21:31] <DktrKranz> sebner, have you ever prepared one for feisty?
[21:32] <DktrKranz> IIRC, my first upload as MOTU was a SRU
[21:32] <sebner> DktrKranz: nope xD but I start preparing for the others tomorrow ^^
[21:32] <DktrKranz> heh
[21:32] <DktrKranz> Err ftp://ftp.it.debian.org unstable/main libwww-perl 5.813-1
[21:32] <DktrKranz>   Data socket timed out [IP: 213.92.8.5 21]
[21:32] <sebner> DktrKranz: well, you are the born boring stable guy :P
[21:32]  * DktrKranz starts to load his guns
[21:33] <sebner> DktrKranz: what about using us?
[21:33] <DktrKranz> much better ftp.sebner.debian.org
[21:33] <sebner> rofl
[21:33] <sebner> TIME OUT
[21:33] <DktrKranz> I guess you won't time out very often
[21:34] <sebner> becaus I won't be running very often? ^^
[21:35]  * DktrKranz is going to own sebner's box one of these days
[21:35]  * sebner runs away and hides 
[21:43] <DktrKranz> debian 502353
[22:04] <NCommander> When using CDBS, is there a hook before dh_install is called?
[22:09] <RainCT> NCommander: yep
[22:09] <NCommander> RainCT, that would be?
[22:09] <RainCT> NCommander: mkbuilddirs or something like that
[22:09] <RainCT> let me check
[22:09] <NCommander> thanks
[22:12] <RainCT> NCommander: makebuilddir is it
[22:12] <RainCT> that's the first thing to be called
[22:13] <NCommander> That's made after debian/tmp is populated, but before dh_install is run, right?
[22:13]  * NCommander needs to rm -r some files
[22:13] <RainCT> but perhaps you don't need to get that far. configure, build, etc. may be enough
[22:24] <DktrKranz> NCommander, if you need some rm -fr, try installing slack (<< 0.15.2-3) ;)
[23:00] <lfaraone> Hey, how do you patch a binary file in a package? (example-content)
[23:01] <james_w> lfaraone: I don't think you do for that package
[23:02] <james_w> are you trying to propose a change?
[23:03] <lfaraone> james_w: yes, in bug 208561 the reporter emailed me a superior (and smaller) version of the speex file.
[23:03] <james_w> lfaraone: I imagine that package is in bzr
[23:05] <lfaraone> james_w: uh, how would I find that out, the repo isn't publicized anywhere that I can tell...
[23:05] <lfaraone> nvm.
[23:06] <ajmitch> NOTICE: 'example-content' packaging is maintained in the 'Bzr' version control system at:
[23:06] <ajmitch> http://bazaar.launchpad.net/~ubuntu-art-pkg/example-content/ubuntu
[23:06] <lfaraone> ajmitch: I found it.
[23:08] <lfaraone> james_w: so what, I open another branch on lp, fork, replace, commit, push, apply for merge?
[23:10] <james_w> lfaraone: yeah
[23:10] <james_w> lfaraone: I'd subscribe the sponsors to your bug and add a pointer to your branch
[23:11] <lfaraone> james_w: do I set it to "in progress"?
[23:12] <james_w> doesn't really matter for sponsorship
[23:12] <james_w> it would just make sure no-one else works on it
[23:15] <lfaraone> james_w: odd, bzr seems to have frozen on `| [[23:16] <james_w> probably copying some large binary files
[23:16] <ajmitch> it's not a small package
[23:20] <lfaraone> woot, done
[23:21] <lfaraone> james_w: you wouldn't happen to be a main sponsor, would you? :)
[23:22] <james_w> 'fraid not
[23:22] <james_w> subscribe the sponsors, and speak to dholbach tomorrow, he touched the package last
[23:22] <james_w> and he'll love me for saying it :-)
[23:22] <lfaraone> james_w: lol.
[23:39] <ScottK> james_w: For your everything in bzr project, the special case of packages maintained in a external repo now has a live case.  The current Ubuntu clamav uploads are in the alioth pkg-clamav Git repo.
[23:40] <james_w> ScottK: ok, thanks. Keep doing that then, and I'll talk to you when we can look at interesting cases.
[23:41] <ScottK> james_w: Will do.  Having a common repo with Debian is doing wonders for cooperation and I'd hate to lose that.
[23:43] <james_w> yeah, I would never ask you to, active co-operation with Debian is going to gain you far more than having the packages in bzr, and having them in git on alioth is almost as good as fitting in with the rest of the packages for many use cases of having them available the same way as other packages
[23:43] <james_w> it will just be to work out how we can mirror the git repo in bzr in the best way that gives the consistency without any hassle