[00:37] hm... 11 days till release... should I start upgrading now? [00:49] would anybody be willing to sponsor a sync to fix this fairly serious bug? https://bugs.launchpad.net/ubuntu/+source/docvert/+bug/286146 [00:49] Launchpad bug 286146 in docvert "Please sync docvert 3.4-6 (universe) from Debian unstable (main)." [Undecided,New] [01:02] fmarier: I'll have a look at it. [01:02] ScottK: thanks [01:02] fmarier: Thanks for taking interest in a downstream project. [01:03] one question though: when should one subscribe motu-release to a bug? [01:03] would that be for an SRU? [01:04] 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] fmarier: SRU is motu-sru, btw [01:04] Until RC for Universe we trust developers to do bug fix updates. [01:04] ok, thanks, that clears things up [01:05] For packages in Main, ubuntu-release is approving all uploads now. [01:07] so if my fix had come after the 23rd, then i would have had to go through motu-release? [01:14] fmarier: Yes. [01:15] fmarier: Looks like persia already gave it sponsors approval, so it's in the archive admins hands to sync (probably tomorrow). [01:15] ScottK: wow, that was fast! :) [01:15] thanks [01:16] hello fmarier [01:16] hi ajmitch [01:16] 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] ScottK: yeah, you'd generally expect a very good knowledge of the package in question in that regard [01:19] ajmitch: Yes. Plus I like to encourage repeat business. [01:28] oh, google gadgets released, I wonder when we'll see the first packages pop up [01:29] or it's probably old === fabrice_sp_ is now known as fabrice_sp === txwikinger is now known as txwikinger2 === txwikinger2 is now known as txwikinger === viviersf{weekend is now known as viviersf [06:28] * NCommander is finally glad the gnat-4.2 transition is nearly done [07:13] good morning [07:17] Morning Daniel. [07:18] hi iulian [07:18] warp10: there's another Colangelo that commented on your behindmotu interview :) [07:21] dholbach: oh, looks like we are "relatives", in a certain manner. Ubuntu helps genealogy too: cool! :D [07:22] :) [07:36] anyone using openvpn here? I am looking for someone to try reproducing a bug and mark it as confirmed. [07:37] The bug is in openvpn plugin of network manager [07:37] slytherin: which bug is it ? [07:38] Koon: bug 285138 [07:38] Launchpad bug 285138 in network-manager-openvpn "Does not import certificate and key settings" [Undecided,New] https://launchpad.net/bugs/285138 [07:40] slytherin: I confirm it does not import the certificates/keys [07:40] slytherin: i'm marking it as confirmed [07:41] Koon: Thanks. :-) [07:41] 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] hmm. Will keep in mind. :-) [07:44] <\sh> moins [07:44] 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:44] Launchpad bug 250425 in zsnes "zsnes crashes with buffer overflow on startup" [Medium,Triaged] https://launchpad.net/bugs/250425 [07:45] bugs #286095 and #286226 [07:45] Launchpad bug 286095 in statcvs "Please sync statcvs 1:0.4.0.dfsg-3 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/286095 [07:45] Launchpad bug 286226 in jta "Please sync 2.6+dfsg-1.1 from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/286226 [07:46] slytherin, This means we can drop the duplication in libjdom-java, right? [07:47] persia: yes [07:47] slytherin, Have you already filed the removal bug? [07:47] persia: No. I will do that once these syncs are done. [07:47] OK. [07:48] jta is already ACK'd. verifying statcvs now. [08:46] 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:46] Launchpad bug 236251 in cecilia "Cecilia Locks up on start" [High,Triaged] [08:53] anyone want to give me some direction on this? [08:53] stochastic, Sure. [08:54] bah. i was already looking at it :) [08:54] laga: go ahead then :) I have other stuff to do, but I like cecila [08:55] thanks guys [09:01] stochastic: is the fix in that bug everything that's needed to get cecilia up and running on debian? [09:01] err, ubuntu. [09:03] laga: yes, that one change successfully fixed it on my machine [09:04] 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] morning o/ [09:08] okay. i hear that cecilia is broken with csound 5.x, that's why i'm wondering [09:10] Is a minor upstream bugfix update better as an SRU or a backport? [09:10] (wine 1.0.1) [09:10] laga: I haven't extensively tested it, I could do a couple quick tests [09:10] stochastic: yes, please do that [09:13] 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] 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] okay. if it's usable, then we can proceed with the debdiff [09:22] does the cecilia package have a patch system? [09:23] ??? I'm brand new to packages I don't know what you're asking [09:24] 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] usually, you will add a patch system which will apply the necessary changes during the build process [09:26] well all the cecilia packages are numbered with ubuntu1 in the repos if that means anything to you [09:26] and I see a .diff.gz file on the packages site [09:26] yeah, the .diff.gz holds debian/ [09:27] ah, it has a patch system. debian/patches exists [09:28] and it uses dpatch. [09:29] stochastic: you need to add the patch to the patch system and generate a debdiff [09:29] can you point me to a howto on this, I'm really a newbie around packaging/maintaining [09:30] stochastic: https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff?action=show&redirect=MOTU%2FRecipes%2FDebdiff [09:30] sure [09:30] stochastic: that guide does not show you how to use dpatch [09:31] is there one around that does? [09:32] 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] don't forget to add your patch to debian/patches/00list [09:32] all instructions assume that you are in the top level directory of the package [09:42] laga: I really am over my head here, it's 1:40am here, and I've got homework that needs my attention [09:43] I'm not even getting very far with registering a GPG key [09:43] nevermind the diff file [09:46] stochastic, You don't need a GPG key. [09:46] the fist step in the first howto warned me that I did [09:46] 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] Which HOWTO? I'll fix it. [09:47] https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff?action=show&redirect=MOTU%2FRecipes%2FDebdiff [09:47] stochastic: then do it tomorrow :) [09:48] thanks, I'll still read through that stuff eventually, it's good for me to learn [09:51] stochastic, Does https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff look better now? [09:51] dholbach, What is the point of setting environment variables and configuring GPG for debdiffs? [09:52] persia: environment variables for dch [09:52] dholbach, OK. Makes sense. [09:53] 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] stochastic: feel free to ping me when you're having problems. i'm in GMT+2. [10:00] and i gotta run now :) [10:19] 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? === _ruben_ is now known as _ruben [10:20] didrocks, It depends on how make is configured. By default, no. [10:22] persia: can you give me a tip for this rules file, please? http://paste.ubuntu.com/60044/ [10:35] 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] For extra safety, do this in a temporary directory. [10:36] (as it will overwrite the source package) [10:53] 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] didrocks, Is it created? Maybe dpatch.make does it. [10:58] persia: don't this that dpatch.make creates it (it deals with patch/unpatch target only apparently) [10:59] didrocks, Could you rephrase? I couldn't parse that. [10:59] oupss, sorry :) [11:00] 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] s/thing/think [11:00] didrocks, OK. Does it get created when you run debuild ? === asac_ is now known as asac [11:02] I must confess that I do not know/can't remember where those flag files are created when building [11:03] 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] persia: oh, my bad, touch $@ touched it :( [11:11] didrocks, There you go. Sorry I missed that. [11:11] persia: thanks a lot for your time :) [11:15] when is superm1 available ? [11:16] AnAnt, Variable, but typically in relatively sane times for UTC+5 [11:16] (at least according to LP : no guarantee that's the right timezone) [11:34] well, I duno what to do [11:35] oops, wrong window === viviersf is now known as viviersf{gone} [14:12] Does anyone happen to know why I get a pan0 network device on a machine *without* bluetooth? [14:16] persia: I appear to have one too, odd [14:17] Laney, And this is with no bluetooth hardware support, right? [14:17] hi folks [14:18] persia: Correct. This machine has never seen bluetooth hardware [14:18] hi sistpoty|work [14:18] hi Laney [14:18] Hmm. I suspect that's a bug. [14:20] pan0's labyrinth. [14:20] ho ho [15:16] hi all [15:17] G__81, Hey. Did you find something on which to work yet? [15:17] 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] G__81, Excellent! Good luck. [15:18] persia, thanks :) [15:18] and wish you the same [15:20] persia, can you give me the link for the bugs to be triaged ? === dholbach_ is now known as dholbach [15:20] G__81, #ubuntu-bugs is the place to get that answer :) [15:21] hmm ok i am on that channel too lets see if i get there [16:25] https://wiki.ubuntu.com/UbuntuOpenWeek/Prep [16:25] Still looking for volunteers! [16:27] hi jcastro i am new but i dont know how i could help [16:28] hi jcastro i could help if there is something that i could do :) [16:28] I don't know, what is it you can do? :D [16:28] i am currently into triaging. I have been doing contributions to fedora so i am kind of new to ubuntu's processes :) [16:29] ah no worries then, you'd probably be a better target as a participant than someone running a session then [16:30] G__81: openweek is basically designed to be sessions for people like you [16:31] oh ok there are many things that ubuntu does extra when compared to fedora so these things are new :) [16:31] yeah thanks [16:31] where do people get this information are these communicated in some mailing lists [16:31] saying that an open week is gonna happen [16:31] so that i could subscribe ? [16:31] yeah, it hasn't been announced yet but it will be on ubuntu-devel-announce [16:32] I am still gathering people so that when it is announced the schedule isn't empty. :D [16:32] you'll want to subscribe to ubuntu-devel, and ubuntu-motu as well [16:33] yeah i am in motu but heard that ubuntu-devel is moderated [16:33] G__81, That it's moderated only means you can't post : you're encouraged to read. [16:34] oh :) i didnt know that [16:34] then i could subscribe :) [16:34] right now [16:36] smarter: congratulations [16:40] james_w: thanks :) [17:11] smarter: congrats! [17:11] hey RainCT, thanks :) [17:13] hi smarter congrats [17:13] hi RainCT [17:14] Hi G__81 [17:15] thanks too G__81 (: [17:17] 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] 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] RainCT: yes. the .dirs should be removed imo [17:29] unless a package wantes to provide an empty dir there is no need for it [17:29] at least thats my understanding of this ;) [17:30] * sistpoty|work calls it a day ... cya [17:31] 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] asac, RainCT .dirs is also useful to work around broken upstream install rules. [17:34] 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] persia: yep, the mv was a lapsus :) [17:50] Hi RainCT i am working on triaging and i am enjoying it, apart from that how else can i contribute [17:50] in addition to that i mean [18:08] G__81: Yeh, I remember those days when I started triaging... :). Well, beside that there is of course packaging, bug fixing, etc. [18:08] G__81: and then more unrelated stuff like translating Ubuntu to your language, writing documentation and all that [18:09] go dfiloni and nxvl! :) [18:10] thanks pochu :) [18:11] <\sh> RainCT: you forget coding some weired python cruft ,-> [18:11] Have not done packaging at all :( [18:11] * G__81 is nervous about packaging stuff [18:12] \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] \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] RainCT, how do i start off with packaging [18:14] sebner: and fix my GNOME ^^ [18:14] <\sh> RainCT: ^5 [18:14] RainCT: you can't fix GNOME. It has to be b0rken. It has to be insane! GNOME FTW! :D [18:14] RainCT, some starting point and then some team where in i could join and package something and send it for review [18:14] is that a simple process [18:14] ? [18:15] \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] 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] \sh: what can be better ;P [18:17] 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] \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] 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] aos101: you'll need both [18:28] 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] superm1: ping [18:38] RainCT: Ok Thanks. I'll probably subscribe both at the same time, and they can see what I'm trying to do. [18:53] oh, MIR bug means a package will be included in Ubuntu's main (/me wondered what doko wants from him ;) [18:54] "good maintainance in debian" hehe ;) [18:54] yes, looking at component mismatches === ssweeny is now known as scolbert === scolbert is now known as ssweeny [18:56] doko: btw, you want to sync pyenchant with Debian if it was build with enchant 1.4.1 or later [18:56] too late, that's for jaunty then [18:58] doko: please try this in Ubuntu: python -c 'import enchant' [18:58] if it will fail you *need* to sync [18:59] POX: doesn't crash on amd64 [19:00] ok, so I guess it was built with one of previous versions [19:01] trying to rebuild ... [19:04] (actually enchant is the one with fixes, pyenchant has to be rebuilded only) [19:05] version in Ubuntu probably has broken shlibs [19:06] 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] http://pages.cs.wisc.edu/~ghost/gsview/LICENCE [19:06] *Section 2 Restrictions [19:07] doko: Since pyenchant is in Universe it's not actually too late. [19:07] $ python -c 'import enchant' [19:07] Traceback (most recent call last): [19:07] File "", line 1, in [19:07] File "enchant/__init__.py", line 90, in [19:07] import _enchant as _e [19:07] ImportError: No module named _enchant [19:08] ScottK: but we have to be quick before pitti approves the MIR ;p [19:08] Yes [19:08] doko: just sync echant [19:08] and then rebuild pyenchant [19:10] Enchant is already in Main, so that'll need release team approval. [19:11] 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] james_w, that's the bit I was concerned about [19:11] To me, that looks like a big no no [19:11] 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] csilk: yeah, me too, but I'm no expert. [19:11] POX: We've already got the non-matching dicts patch. Was there something else that was important in Enchant? [19:11] csilk: also, does the app link against anything GPL? [19:12] james_w, no it's all under that one license as far as I can see [19:12] ScottK: https://bugs.edge.launchpad.net/ubuntu/+source/pyenchant/+bug/286542 [19:12] ScottK: see enchant's changelog, you need all of them [19:12] Launchpad bug 286542 in pyenchant "sync-request" [Undecided,New] [19:12] james_w and csilk: Such restrictions are acceptable in Multiverse. [19:13] ScottK, is there a written policy I can refer to for future reference? [19:13] POX: So it looks like except the shlibs bump we have everything already. [19:14] 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] ScottK, but there is a possibilty that app could end up being distributed commerically if it's in multiverse [19:15] *that the app [19:15] ScottK: if you rebuild pyenchant with current Ubuntu's enchant version, it will not work, see doko's traceback [19:15] POX: Right. I think I got that now. [19:15] csilk: but then that's the problem of the person distributing it, not Ubuntu's [19:16] csilk: It's distributable by Canonical/Ubuntu and that's what matters. [19:16] csilk: Any Ubuntu derivative REALLY needs to review licenses in multiverse before distributing packages from there. [19:17] 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] AnAnt, pong [19:18] 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] Odds are significantly better if the license is fixed. [19:19] omg Ubuntu just got mad.. /me restarts [19:21] ScottK, yeah I understand, having a mentor really helps in that situation though. [19:23] weird.. aptitude broke :'( [19:24] sebner: I think I'm starting to support your theory :) [19:25] RainCT: well, I use apt :P [19:27] ihr seid alle idioten [19:27] 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] uff [19:28] Hobbsee: kick him ^ [19:28] jo tu das xD [19:29] nur dumm das das hier keiner kann haha [19:29] looser [19:29] sebner: now I can add a weird troll to my list LOL [19:29] allerg [19:29] reasg [19:29] rs [19:29] gr [19:29] hz6t [19:29] h [19:29] 6 [19:29] u [19:29] drh [19:29] 56 [19:29] !ops [19:29] Help! Hobbsee, Riddell, sladen, fbond, mneptok, gnomefreak, Seveas, dholbach, elkbuntu, PriceChild, or jpatrick! [19:30] utzj [19:30] u [19:30] zk [19:30] PriceChild: Thank you. [19:30] grr [19:30] Bad german troll [19:37] superm1: I need your help with dkms ! [19:38] superm1: I added dkms support to sl-modem, but it only compiles one module (slamr) , but fails to compile ungrab-winmodem [19:38] superm1: and make.log doesn't give any useful info [19:38] AnAnt, normally when you compile it, do you use the same make command for building both modules? [19:38] superm1: no, another make command [19:39] AnAnt, well then you'll need to specify that other command in your dkms control file too [19:39] superm1: I did, http://pastebin.com/mfc42622 [19:39] by using several MAKE directives, eg MAKE[0], MAKE[1] [19:40] that's what I've done, please look at pastebin url [19:40] AnAnt, do you possibly need to be pushd'ing in your second directive then? [19:40] i'm not sure the structure of sl-modem's stuff [19:41] superm1: I tried that, but it was of no use [19:41] 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] make sure that it spits out the module properly [19:42] superm1: done that, and it worked ! [19:42] AnAnt, then are you sure the second directive is being actually called in the first place when it fails? [19:43] superm1: how would I know ? [19:43] f*ck, pyenchant fails in unstable as well [19:43] AnAnt, well that make.log should show, and/or when you do dkms build you may see it [19:43] superm1: dkms says: Error! Build of ungrab-winmodem.ko failed for: 2.6.27-7-generic (i686) [19:43] Consult the make.log in the build directory [19:44] 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] /var/lib/dkms/sl-modem/2.9.11~20080817/build [19:44] and that's it ! [19:44] 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] superm1: that worked ! [19:47] 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] so I should just keep it like that ? [19:48] I mean both in same MAKE directive ? [19:50] AnAnt, just remove the second MAKE directive [19:52] superm1: btw, does your ipod-convience also works with the new ipod touch2? if yes, *how* good? [19:54] sebner, if someone will trade me their touch2 for my touch, i'll tell you :) [19:54] superm1: hrhr ^^, /me is thinking about getting one for christmas but you know .. touch and phone with ubuntu ... :\ [19:54] sebner, surely if you can jailbreak the touch2, it should work [19:55] superm1: /me is wondering what's your magic behind jailbreaking [19:55] sebner, i'm personally really pissed about the nike stuff being built into touch2 [19:56] superm1: why? [19:56] sebner, well now I either have to go buy a touch2, or buy a nano to use nike+ [19:56] i was hoping to just spend 30 bucks on the dongle when they released the ipod touch software for it [19:56] sebner, well the ipod-convenience stuff only works if you jailbreak it, so you'll have to read about that stuff [19:58] 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] fabrice_sp: yep [19:58] superm1: kk, well I'm thinking about nano or touch. nano would clearly the easier decision ^^ [19:59] RainCT: great! I'll change that and upload now (and also the change for vimperator) [19:59] doko: wait with that sync, looks like after latest changes in enchant I need to fix something in pyenchant as well [19:59] thanks [20:00] 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] doko: I'll fix it in Debian and then we'll see if it will be enough for Ubuntu [20:01] looks like .so file is in wrong dir now, I'll check why [20:04] superm1: thanks a lot ! [20:04] AnAnt, no prob. [20:05] superm1: btw, sl-modem supports both module-assistant & dkms [20:06] 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] superm1: I can upload to debian mentors if you want [20:07] AnAnt, my time to give it a good look is low now, so i'll look later :) [20:07] ok [20:29] asac: what do you you mean with your last comment on bug #286225? [20:30] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/286225/+text) [20:31] (this one: https://bugs.launchpad.net/ubuntu/+source/vimperator/+bug/286225) [20:31] Launchpad bug 286225 in vimperator "[intrepid] iceweasel-vimperator: Depends: iceweasel (>= 3.0~) but it is not instalable" [Undecided,Confirmed] [20:32] superm1: Thanks for jumping in on the brightness related bugs. [20:34] 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] 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] 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] superm1: I think it's potential SRU material if you can get it sorted. [20:36] superm1: Speaking of SRU, how's bluetooth going? [20:40] ScottK, well kernel guys should be looking at this already to try to fix before 8.10 is live. [20:40] ScottK, as for bluetooth, upstream's accepting a majority of my patch [20:40] ScottK, still has missing pieces for the integration, so at the going rate it will likely be a post release SRU [20:41] superm1: That's not horrible. Nothing until Jaunty would have been horrible. [20:41] superm1: Thanks for working on it. [20:41] superm1: We are planning on fielding KDE 4.1.3 in intrepid-updates so anything there we will automatically get. [20:42] ScottK, well i'm not sure how close to releases KDE trunk is, but automatically getting it would be awesome [20:42] superm1: Trunk is towards 4.2 now. We can probably try to backport it. [20:43] So you might discuss how much of this they'll allow into the 4.1 branch. [20:43] ScottK: I have pyenchant fixed in DPMT repo now, could you check if it works in Ubuntu? [20:43] ScottK, once it's all stable we'll see. backporting it will be very easy in any case [20:43] With our current enchant or the one from Debian? [20:44] POX: ^^ [20:44] Ubuntu's enchant, I know it works with Debian's [20:44] OK [20:44] POX: Is build, install, import enchant a sufficent test? [20:44] yup [20:46] POX: 1.4.2-1 "UNRELEASED"? [20:46] no, lenny branch [20:46] Ah [20:48] POX: Bulding now. [20:50] 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] http://www.gnu.org/software/gcc/faq.html#dso [20:50] I'm not sure exactly where the problem lies, yet. [20:51] But symbols exported by libcryptopp.so dpon' [20:51] POX: It wants libenchant-dev > 1.4.2-3.3 and I don't have that here. [20:51] don't get resolved properly when they are also used by a Python module that I wrote. [20:52] ScottK: lower it to .3.1 and check if it works [20:53] OK [20:55] * POX needs to update his Ubuntu chroot [20:57] kf [20:57] sorry [20:58] POX: Works [20:59] hmm... so why when I builded it with -3.1 without the patch I created today, it worked in Debian? [20:59] POX: Because 3.1ubuntu1 has the patch from 3.3? [21:00]