[00:02] Well, I am looking to help [00:14] Laney, hmm, what about this bug [00:14] bug 343979 [00:14] Launchpad bug 343979 in evolution-rss "needs update for jaunty" [Undecided,New] https://launchpad.net/bugs/343979 [00:14] Help me learn with that? [00:36] st33med: That bug is a duplicate [00:37] nhandler, yeah, thanks for the update === jrib1 is now known as jrib === rgreening_ is now known as rgreening [01:09] If I only have one binary package (produced by the source package), and it has ``Architecture: all'', do I need Build-Depends? Or can they all go in Build-Depends-Indep? [01:18] ryanakca: you need Build-Depends for the things needed for the clean target. [01:18] so probably cdbs, debhelper, &c. [01:20] Ryan52: So, http://pastebin.com/f2f604696 is fine? [01:24] maybe? :P [01:24] looks okay. I dunno about cmake or python packaging, tho. [01:25] Ok, thanks [01:28] So uh... [01:29] I am a new-ish Ubuntu Member looking to help in Python areas for Jaunty === simon__ is now known as frostburn2 [03:06] Could someone upload the updated thinkfinger package attached to bug #311732 ? [03:06] Launchpad bug 311732 in linux "2.6.28-4 breaks thinkfinger" [Undecided,Fix released] https://launchpad.net/bugs/311732 [03:06] Thinkfinger doesn't currently work on jaunty. Thank you. [03:25] TomJaeger: is there a way you can provide a debdiff with only the needed changes ? the .diff.gz I saw on that bug report seems huge [03:26] stgraber@sahal:~/code/thinkfinger$ debdiff thinkfinger_0.3+r118-0ubuntu3.dsc thinkfinger_0.3+r118-0ubuntu4.dsc | wc -l [03:27] 7438 [03:27] TomJaeger: that's a lot more than it should for a bugfix [03:27] stgraber, The version that's currently in ubuntu contains all sorts of junk files that have been deleted [03:29] Check out the diffstat [03:29] 61 files changed, 21 insertions(+), 7123 deletions(-) [03:31] As far as I understand it, a .debdiff can't represent deletion of files, that's why I posted the .diff.gz [03:32] What's the package like in Debian ? our general goal is to avoid unnecessary delta with Debian as it'll only make it harder for the next release (having to merge the changes) ? [03:35] I think we already diverged. Debian's not going to have the fixes, though, since we're on a newer kernel. [03:37] stgraber, http://packages.debian.org/changelogs/pool/main/t/thinkfinger/thinkfinger_0.3+rev118.2-4/changelog [03:55] TomJaeger: At this point in the release cycle 'cleaning up the package' is not something we want. We want to limit changes to minimally invasive ways to fix problems. [03:58] ScottK, these are .svn files and leftover dependencies files, they won't affect the package in any way. [03:59] They don't particulalry hurt to leave them either. [04:00] It'd probably take me at least 10 minutes to put them all back in and prepare a new .debdiff [04:00] * ScottK is just off to bed, so not in a sponsoring mood. Take my advice for what you will. [04:04] I really don't have time for this kind of busywork right now. So it's either the package I posted, or someone else will have to put the junk back in, or we won't have a working thinkfinger package in jaunty. [04:06] TomJaeger, why don't just just redownload he original package, apply your diff, and reget the debdiff? [04:06] debdiff would ignore deletion === fabrice_sp__ is now known as fabrice_sp [04:08] No, the debdiff will represent deletion as removing the content of the files. [04:09] Anyway, my standpoint is that my time is too valuable for these kind of antics. [04:10] TomJaeger: I dont see this as antics. sry you feel that way [04:11] during freeze, we need to minomize changes. [04:11] minimize even [04:11] it's more of a 'cover your butt' scenario :P [04:11] Since the deleted files don't affect the package build in any way, there's no change [04:12] TomJaeger: And no file deletion ever had an inadvertent effect? [04:12] And I agree thazt that clean-up should get done after freeze [04:13] It's easier to 'oops' when you have 7000 lines to review in changes. [04:13] * ScottK decides to quit arguing and play killbots instead. [04:14] ScottK, the deletion of .svn directories? please [04:15] rgreening, geany is really nice to review diffs [04:15] TomJaeger, in the time you spent arguing over this, you could have made the changes requested by the sponsor. [04:15] :) [04:15] just to be facitious :P [04:15] * rgreening ducks [04:16] the thing is, I've already made up my mind. I'm not going to make the changes [04:16] oh well.... [04:17] I'd argue that it's much more likely that I'd screw up re-adding those files than that the deletion causes a regression. [04:20] We need to ensure that diffs are easy to review. [04:20] We really do not want to break things at this point. [04:20] there are easy to review for anyone who's ever heard of diffstat [04:20] thinkfinger is _completely broken_ at this point anyway [04:21] Even if I use diffstat, I have to work out which files are actually entirely gone and which aren't and blah blah blah. [04:21] With a proper diff, I can just glance at it and see that it's not doing anything stupid. [04:22] TomJaeger: wheres your debdiff and bug report [04:22] bug #311732 [04:22] Launchpad bug 311732 in linux "2.6.28-4 breaks thinkfinger" [Undecided,Fix released] https://launchpad.net/bugs/311732 [04:24] hmm.. reading this looks like simply getting a clean package via apt-get source and grabbing the patch from the kernel bug is easy enough. [04:25] There's quite a few fixes in that package, not just that one that the bug is about [04:26] oh, then you probably should file a seperate bug report asking for the update and all your changelog entries for every single change will need to be documented to get accepted. [04:27] There are bugs filed for all of them [04:27] Having accurate changelog entries is a critical part of updating any package [04:27] Did you even look at the changelog? [04:28] comment #19 === Andre_Gondim is now known as Andre_Gondim-afk [04:30] ScottK: https://bugs.launchpad.net/bugs/340435 [04:31] Ubuntu bug 340435 in adblock-plus "[needs-update] adblock-plus to 1.0.1 in Jaunty" [Undecided,New] [04:32] TomJaeger: yes I read it. And yes I saw the changelog entry and my comment stands. You don't meantion zapping the changelog entries which differs from upstream. [04:32] for one [04:32] zapping the changelog entries? [04:32] anyway, a debdiff would be nice. [04:35] bdrung: It's not bug fix only. [04:35] asac: I thought we agreed you weren't going to shove unsupported Firefox versions in Universe anymore? [04:35] asac: Does mozillateam intend to support Firefox-3.1 though the life of Jaunty? [04:36] rgreening, posted a .debdiff [04:36] TomJaeger: Let me have a peek [04:36] ScottK, did you had time to have a look at Bug #343851 [04:36] Launchpad bug 343851 in setools "FTBFS randomly because of a race condition in creating debian/stamp/binary" [Undecided,Confirmed] https://launchpad.net/bugs/343851 [04:36] ? [04:36] fabrice_sp: I did. I'm uncertain how to tell if you fixed the FTBFS since the previous version works in a PPA. [04:37] fabrice_sp: I'm considering maybe this is a packagebinarymangler bug. [04:38] ScottK, I far I understand this package, in each binary, it's trying to check and create debian/stamp/binary if not exist. I could happen that it enters at the same time in the condition and try to create it [04:38] by moving the creation outside of the binaries target, it should work [04:38] OK. I didn't have more to do than toss it at my PPA. [04:38] have time to do more than ... [04:39] I think build machines are too fast :-) [04:39] are the ppa ones slower? [04:41] ScottK: updated bug title. something missing? [04:48] TomJaeger: ok, so you definately have something funky in the diff. At one point the thinkfinger.orig is the first entry and sometimes the second, which leads me to believe you cat'd these together. not such a big deal, but does make it easy for you to remove the .svn parts which all apear at the beginning. [04:48] :) [04:49] TomJaeger: and it appears you made changes directly in the source rather than via patching [04:50] The debdiff was created using the debdiff command from the two .dsc files [04:51] is there any way to get a list of completely new packages in one distro from another? That is, packages that aren't just new versions, but that haven't been in the repos before at all? And packages that have been promoted or demoted? [04:51] TomJaeger: and they should still yield whether a patch was used. I don't see that. [04:51] unless I missed something... [04:51] I figured changing the source directly is less intrusive than adding a patch system [04:52] TomJaeger: completely the opposite [04:52] for us === sdh_ is now known as sdh [04:52] Patch systems are kludges anyway [04:52] As a rule of thumb, never change the source. Always generate a patch. submit the debdiff . pass the patch upstream. [04:53] TomJaeger: if you are interested in learning the ropes, and how we work, there are some processes we have to follow. [04:53] and patch systems are not kludges. [04:53] They are. Horrible kludges. [04:54] PITA to deal with. [04:54] do I sense any undue hostilities? cause, I am quite willing to walk away... [04:54] rather than help [04:54] Put the source package under proper version control [04:55] Well, I've wasted a lot of time dealing with patch systems. [04:55] TomJaeger: we don't own the source, and therefore we patch and pass upstream. if/when upstream accepts the patch, we update the package and remove the patch. this keeps things much cleaner and much easier to modify or remove a patch when required. [04:56] Tell me, how easy is it to back out your change? with a patch system, I comment out a single entry in a file and let it rebuild. done. [04:56] Well, a .diff.gz is a patch, too [04:57] TomJaeger: no, not in the strict sense we are looking for here. Patches goe in the debian/patches dir and are part of a patch system like quilt, dpatch, etc. [04:57] It's as easy as removing a .orig and a .rej file after running uupdate [04:57] Anyway, if you wish to have patches/diffs reviewed and uploaded, it will go a lot easier if you follow the ubuntu packaging guide. [04:58] making life easy for your uploader/sponsor is in your and the packages best interest. [04:59] but I digress... its late here... and Im much too tired... [04:59] At this point, I'm really fine with keeping the package in my PPA. [04:59] Woah! We still have 128 packages that cannot be installed, 48 of which are from python (that's what apt-cache -i unmet tell me...). [05:00] and Beta is in 3 days? That will be hot! [05:02] Can someone try to get the latest version of my NES emulator into intrpeid? http://fceux.com . It version 2 of fceu and gfceu, but it does not replace them , since its called (g)fceux. it's works a lot more nicely with ubuntu 8.10/9.04 and it would be a shame to see only the ancient 0.98 release in the archives [05:11] rgreening, again, I don't have the time for this busywork. It's late here, too and I still have 3 hours of work ahead of me. If you want changes to the package to be versioned, I would suggest to adopt a solution centered around a version control system. Patch systems are extremely difficult to work with when you're tracking upstream changes. [05:13] TomJaeger: it's not me, its policy. I think you really need to read up on how packages are done in debian and Ubuntu [05:13] I don't seem to remember that patch systems are a hard requirement. [05:14] As a matter of fact, I've gotten packages in that didn't use a patch system... [05:14] TomJaeger: If there's no good reason to not use a patch system, then we use it. We avoid patching the source directly. [05:15] if the source has issues and MUST be modified directly, then this is a case-by-case review. in this case, It is not warranted. [05:16] and wehat happens for the next person who wishes to fix? What happens when a source update occurs and the change disappears... [05:16] What's troubling me here is that there is a lack of a sense how things should be properly done [05:16] thats what patch systems are useful.. [05:16] TomJaeger: I think you are really failing to understand. [05:16] What don't I understand? [05:18] There's a tradeoff here: Patch systems are a considerable amount of work to set up and maintain, and the benefits are not worth it in this case, at least not for me. [05:18] TomJaeger: If it was my source tree, then it would be in bzr. This is an upstreams source, and presumably its in an rcs of some kind. a proper patch should be provided to them, and they will updates thier rcs. we maintain only small diffs/patches and re-sync with debian and upstream at various times. [05:18] considerable amount of work? not at all. [05:19] Small patches, huh? This is the reason why everybody runs autoreconf on the source tree and then sticks the result into the .diff.gz? [05:19] TomJaeger: that shouldn't occur (on reasonably new packages) [05:20] TomJaeger: I take it you've never used quilt. [05:21] quilt is a dream. [05:21] Which is why the new source format is based on it. [05:22] TomJaeger: https://wiki.kubuntu.org/Kubuntu/Ninjas/QuiltMagic [05:22] I've used quilt, and I can tell you, it just doesn't interoperate with git very well. [05:23] I can see this discussion is circular, and Im feeling quite dizzy. so adieu [05:23] TomJaeger: Is the thinkfinger packaging in a VCS? === fabrice_sp_ is now known as fabrice_sp [05:25] I do know what I'm talking about, I've developed all the patches that I got into the X Server before 1.6 came using a git archive with a debian/ directory in it. It was not very pleasant, but it beats setting up an upstream X build system any day. [05:25] wgrant, upstream uses svn [05:26] TomJaeger: If the packaging doesn't use a VCS, there is little excuse not to use a patch system. [05:26] upstream != packaging [05:31] wgrant, except that it would probably take me an hour to separate the changes into patches and setting everything up, time that I don't have. And the patch system won't be of much use anyway if the is ever merged with debian again. [05:32] TomJaeger: actually the 3 changes are in patch format already here: http://bugzilla.kernel.org/show_bug.cgi?id=12301 [05:32] bugzilla.kernel.org bug 12301 in USB "Fingerprint reader doesn't respod after the first use" [Normal,Closed: code_fix] [05:32] which is where you got them [05:32] TomJaeger: You had to apply the changes as patches in the first place. [05:33] And I hadn't noticed before that it was derived from Debian in ancient times. [05:33] and TomJaeger we sync/merge with debian after each release [05:34] exactly, so right now, we should only be worrying about fixing the bugs, and not duplicating work [05:35] maybe getting the patch into the original code would be more your style :) I hear they have a vcs [05:35] :) [05:36] Since it is in fact somewhat derived from Debian, and it doesn't appear to have a patch system at the moment, AND it's raw old-style debhelper, applying the patches inline isn't an entirely terrible crime. [05:36] The patch was written by the thinkfinger author, so, yes, I'd expect it to become available upstream sooner or later [05:36] ew... [05:36] old debhelper is god awful [05:59] rgreening, since you said earlier that quilt was so easy to use and set up, I've had a quick look at how things work (maybe the impression that I got when I first dealt with this a long time ago, was wrong after all) [06:00] awesome [06:00] quilt is powerful [06:00] So I checked the PackagingGuide, and they explain how to use it. [06:01] It seems a little complicated to my, I will definitely continue to create my patches with git and then stick them into the debian/patches directory [06:01] I'd also be worried about forgetting the add step and creating inline patches by accident. [06:02] But the packaging guide says nothing about how to set it up. But they give an example package, xterm. [06:03] So I checked out the xterm package and looked at their debian/rules file [06:03] The file is 231 lines long and contains a lot of quilt boilerplate. Not exactly what I'd call easy to set up. [06:04] It's simpler than that [06:04] 1. add a dep on cdbs and quilt in the build-deps [06:05] 2. add the patch to debian/patches and add the name to debian/series [06:05] maybe that should be explained in the packaging guide? [06:05] What if my package doesn't use cdbs? [06:05] 3. add include /usr/share/cdbs/1/rules/patchsys-quilt.mk to rules [06:05] thats it [06:06] cdbs is for step 3. [06:06] and it's onlt for build dep and not run=time [06:06] And it'll work with a debhelper package? [06:06] most newer packages will likely work with this 3 step [06:06] yes [06:07] add the step 3. just after tyhe debhelps like in rules [06:10] TomJaeger: in this package, since its an real old debhelper, two ways to update... 1) use quilt and update the rules file to work with cdbs (doesn't appear to at the moment). 2) add patch definitions to rules and forget quilt. [06:10] Is there a reason why the simple patchsys and dpatch are featured more prominently in the packaging guide than quilt [06:11] dpatch should be deprecated in my opinion, I've had nothing but trouble with it. [06:11] look at balder2d. I recently updated it in this way [06:12] TomJaeger: http://paste.ubuntu.com/132323/ [06:12] add that to rules and forget adding cdbs and quilt deps. [06:13] you won't need a series file either with that [06:13] In this particular instance, I really don't think it's worth it, though. The package should be fixed properly before any more work is done on it. [06:13] but you still copy the patch to debian/patches and nam,e .patch [06:14] ading the paste I supplied and http://paste.ubuntu.com/132324/ as the patch should do it [06:15] (I was working on it at the same time here...) [06:20] rgreening, is anyone working on updating the packaging guide? It seems like quilt is superior to the alternatives, yet it's not at all obvious from the guide that you should use it or how you should use it. [06:21] not that I am aware. [06:28] this looks pretty much like af rebuildd hick-up http://builder.ubuntuwire.com:9998/job/47540 ... can we do anything to get the rebuildd to try again? === santiago-pgsql is now known as santiago-ve [06:48] rgreening, as much as I'm sympathetic to your cause, I really can't justify any work on the thinkfinger package at the moment. I'm pretty caught up in real life right now, and I've got other linuxy things to worry about that are more important to me, for example I've got patches related to bug #217908 that I've been meaning to send to the cairo list for weeks. If this means that we're not going to see an update to the thinkfin [06:48] ger package, then that sucks for the people that want to use their fingerprint reader on a jaunty system. I've gotten used to maintaining packages outside the distribution in various PPAs anyway, one more package won't hurt. [06:48] Launchpad bug 217908 in xserver-xorg-video-radeonhd "Pixellated Images in Firefox/Opera due to incorrect EXTEND_PAD implementation in several video drivers" [Medium,Fix released] https://launchpad.net/bugs/217908 [06:59] a|wen: It was sort of a hiccup, but not really - the package was actually deleted from Jaunty after the job was created. [06:59] So a few days later it tried to build, and BOOM. [06:59] a|wen: But please ping me with any issues with the rebuild. [07:00] wgrant: okay, that's makes sense; is there any way to get it off the list? [07:00] and i'll ping you if i see any other strange things through the list [07:00] a|wen: Nothing that makes sense. But I intend to improve the listing some time this week to only show failures for current sources. [07:01] At the moment it will show all failures for the distroseries. [07:01] wgrant: okay; that would solve the purpose :) [07:01] Which isn't too useful if it is fixed later. [07:04] Also, I can give people tarballs of failed build logs to grep through for common issues. [07:04] good morning [07:04] Like the 70 distutils /usr/local-related ones I grepped into recently. [07:05] Morning dholbach. [07:05] hi wgrant [07:06] hi dholbach ;-) [07:07] hiya fabrice_sp [07:07] wgrant: we probably still have a number of "use --without-arts" ... that is those i'm on lookout for now [07:07] a|wen: Yes, around 56 at last count. [07:08] But that was about 2500 builds ago. [07:08] I can give you a list in a minute or so... [07:08] wgrant: i've fixes 68 of those within the last 3 days ... so should be lower now :) [07:08] wgrant: that would be cool with a list, thx [07:11] a|wen: http://paste.ubuntu.com/132329/ [07:12] wgrant: don't they disappear from the list, when they get fixed ... or how often are they updated? [07:12] a|wen: No, they stay there forever at the moment. That's what I plan to fix. [07:13] But the rebuild only started 6 days ago, so it's not too bad yet. [07:13] okay, i've got it now ... the good news is that all the kde-i18n-* from that list is fixed [07:16] Good morning dholbach. [07:17] hiya iulian [07:44] Hello everyone! I now have internet again! [07:47] RAOF: I'm sure I can get Telstra to fix that. [07:48] Although I probably don't need to intervene for it to happen. [07:48] Probably not. Apparently the main problem was that the wiring in this building is corroded to buggery. [07:49] Netting me the lightning fast download sync speed of 4Mbit/sec. [07:49] Excellent. [07:49] * RAOF goes back to ensuring the en_AU translation of GNOME Do isn't in Arabic. [07:53] RAOF: which Telstra service are you using? [07:55] slytherin: None. Only the local loop that they own. [07:55] oh [07:55] I've got me an Internode "please, don't make me have to contact Telstra" naked DSL plan. [07:57] Depends: python (<< 2.7), python (>= 2.5), python-central (>= 0.6.11), python2.6 [07:57] is there any way to make 2.5 and 2.6 libs, but not to add python2.6 ? [07:58] g'morning [07:59] here's the pbuilder log: http://paste.ubuntu.com/132335/ [08:00] savvas: grep for any #!/usr/bin/python2.6 lines that might inadvertently be present [08:01] maxb: none unfortunately [08:01] I think it has to do with the fact that it builds libs for 2.6: -rw-r--r-- root/root 70488 2009-03-17 08:51 ./usr/lib/python2.6/dist-packages/imgSeekLib/imgdb.so [08:01] but then again, what do I know :P [08:02] hm [08:03] here's the debdiff I'm preparing: http://paste.ubuntu.com/132337/ [08:10] * savvas bbl [08:47] I have 123 emails from LP since last night... [08:48] * Laney eyes rosetta === fta_ is now known as fta [08:58] ]3. [08:58] 0+69-00 [09:11] Laney: Lucky. [09:14] Did I get off lightly? [09:28] MD2 beta 2 is out. i shall prep a merge [09:32] Laney: I think you did. I wish I only got that many a day :) [09:35] good morning [09:35] geser: good morning [10:14] grr, gnomish things going on mean i can't test-build monodevelop 2 beta 2 [10:22] directhex: test build where? on your machine or ppa? [10:23] slytherin, local machine. looks like not all deps have caught up yet (libfontconfig1 is the current baddie) [10:24] directhex: hmm [10:24] libfontconfig1: Depends: fontconfig-config (= 2.6.0-1ubuntu7) but 2.6.0-1ubuntu9 is to be installed. [10:24] it'll right itself in a few hours. the timing just sucks [10:25] directhex: if it blocks you, ask a buildd-admin to rescore it a bit, so it will be mirrored sooner [10:26] DktrKranz, nah, not that urgent - anyway, it's a test build for the most recent monodevelop 2 beta, some poor bugger would still need to sponsor the merge [10:27] * DktrKranz hides [10:27] :) [10:37] * slytherin wishes eclipse's latest release was in repos to give tough competition to monodevelop. [10:37] slytherin, not happening for jaunty? :/ [10:38] directhex: Nope. The Debian java packages who used to work on eclipse are MIA. [10:38] slytherin, gah! [10:38] slytherin, something to aim for for karmic, perhaps? [10:39] directhex: yes, sure. And by that time eclipse will have added another bunch of build deps. eclipse is becoming mammoth. [10:40] slytherin, far be it for me to ever consider using words like "bloat" in the same sentance as "java" ;) [10:40] slytherin, i really hope java 7's reshufflinf of the class library can help bring some of this crap back under control [10:42] and it's pretty unfortunate for dev tools to EVER be outdated in a release - that's one reason i pushed for MD2 FFe: MD1 in <=intrepid sucks [10:44] directhex: at least we have netbeans updated. [10:46] slytherin, are there any qt-java apps in the archive, out of interest? [11:14] is it normal for pycentral to request in "Depends:" a specific python version, i.e. python2.6 when it packages a 2.6 library ? [11:15] (there's no python2.6 hashbang as far as I can see) [11:16] directhex: don't think so. I don't even know if there are any java bindings for Qt [11:17] slytherin, there are - the recent announcement was that nokia were dropping them, so the community would need to maintain them if they care [11:18] slytherin, i ask as the first ever real Qyoto app has surfaced, an XMPP client written in C# for Qt4 [11:19] qyoto? [11:20] I hope that's a typo :P [11:20] savvas, current Qt CLI bindings project [11:20] oh, hehe [11:20] libqyoto4.3-cil - CLI bindings for the Qt 4 toolkit [11:21] also, a monodevelop addin to generate c# from Qt Designer files [11:21] "Looks sexy, very alphaish" was my assessment of Synapse [11:21] <3 [11:21] * libqyoto4.4-cil [11:22] :) [11:22] Laney, yes [11:22] Laney, but points for sheer awesomeness [11:23] Laney, need to start thinking about karmic mono goals [12:00] slytherin: ping [12:02] slomo: hi, long time no see. I wanted to discuss the broken dvd playback on jaunty. Had some discussion with seb128. I have even mailed debin maintainer of libdvdread but yet to receive the reply. [12:03] * directhex puts his net gun away [12:03] slytherin: ok, give me some details please :) [12:04] "configure2 sucks" [12:04] slomo: currently all apps that link against libdvdread4 are broken. This includes totem with gstreamer backend, mplayer, vlc, thoggen etc. [12:05] slytherin: why? [12:05] slomo: The upstream libdvdread4 is shipping some script configure2 and a Makefile which seem to be creating some problem. I am not sure what the problem is exactly. [12:07] slytherin: hm, ok... so "something is broken"? :) there's no known fix yet? and is the problem in libdvdread or in the using applications? [12:08] slomo: I know a workaround. The problem is in using all applications that use libdvdread4. [12:09] slomo: I initially thought this snippet in dvd_input.c was causing problem. [12:09] /* dlopening libdvdcss */ [12:09] #ifdef HAVE_DLFCN_H [12:09] #include [12:09] #else [12:10] but the Makefile has HAVE_DLFCN_H defined, so this should not be the problem. [12:12] slytherin: so what's the workaround? [12:13] slomo: workaround is to use the old configure script, which needs to be generated with autogen.sh [12:16] slytherin: but you don't know the difference between the configure scripts? [12:17] slomo: No. I tried hard to figure out. :-( [12:21] slytherin: no differences in config.h for example? [12:21] slytherin: also, is this bug already filed in debian or known by the maintainer? [12:21] slomo: I wasn't sure if the bug is present in Debian. Hence I mailed the maintainer offline. [12:22] slytherin: ok, i don't know either because i have no dvds here :) [12:24] slomo: just replied to your email, thanks for working on it :) === white_ is now known as white [12:24] slomo: I will see if any of my friends have Debian unstable system [12:25] white: np... it's only glib that is affected btw, libsoup is fixed since 2.2.101 (by using glib functions) and gst-plugins-base 0.10.19 and before in stable are also not affected [12:25] slomo: did you check oldstable as well? [12:26] white: libsoup in oldstable has the bug, right... so that's glib for stable and oldstable and libsoup for oldstable... debdiffs will follow in some minutes ;) [12:27] slomo: much appreciated :), i suppose gst-* in oldstable is not affected either? [12:27] white: no [12:45] white: i've sent you the three debdiffs [12:51] white: if you're confused by the uploaders changes in the debdiffs, that's caused by the gnome-pkg-tools uploaders.mk [13:03] slomo: just for the record, gst-plugins-base uses glib? [13:04] white: yes (and the version i've uploaded to unstable today fixes the base64 CVE, should move to testing asap) [13:07] slomo: ok, i am always getting confused by the various gst* packages and their versions and where the plugins are ..., but if you say they are not affected in stable/oldstable, then that's even better :) [13:10] white: the problem was a feature that was added in 0.10.20 of gst-plugins-base (images in vorbis tags) and it used the glib base64 functions ;) [14:17] Heya gang [14:17] afternoon, bazza [14:18] :) === balbir_ is now known as bsa === bsa is now known as bsarora === Andre_Gondim-afk is now known as Andre_Gondim [14:51] * RainCT can't boot with the latest kernel (jaunty) :( [14:53] This feels like a silly question, but what is the functional difference between the Apache license and the BSD license? [14:54] Which BSD license? [14:55] /usr/share/common-licenses/BSD [14:55] A quick read leads me to believe the patent grant and the requirement to document what you've changed are the major differences. [14:57] IIRC the patent grant is what makes the Apache license GPL v2 incompatible. [14:57] Oh, right. The patent thing. [14:57] yay, patents [14:57] You would say that. [14:58] of course! [14:58] * directhex patents IRC [15:02] So if I'm reading the legalese correctly, if you contribute to an ASL licensed project something that is covered by a patent you hold, you implicitly grant the project a patent license? [15:02] That's pretty much my reading. [15:03] And you get patent licenses for anything anyone else contributed. [15:03] That doesn't offer much of an incentive to contribute those patches back to the project. [15:03] Which vanishes as soon as you sue someone. [15:03] So it's a bit of an enforced patent peace. [15:03] So making the contribution gets you some protection too. [15:04] Ah, I see. [15:05] ScottK: Thanks! [15:05] soren: yw. [15:40] Argh we have no latex equation editor for Ubuntu... :-( === Andre_Gondim is now known as Andre_Gondim-afk [15:43] DktrKranz, if it helps, MD2 beta 2 is a pure bugfix release - 130 closed tickets. so no FFe worrying this time \o/ [15:44] directhex: well, I think it has been approved anyway [15:45] just sayin'... [15:45] should mean a simple uupdate-only update, but i can't test until mirror.ox.ac.uk stops sucking [15:51] directhex: don't worry, just ping when ready :) [15:53] I hope someone can help... I just discovered that, evidently, I have two launchpad accounts. When I discovered it, it says there had been no activity in over 3 years, now it is gaining as a contributor. I am VERY confused. It says I am making bazaar revisions, but the account doesn't even have any registered keys. [15:54] adelie42: #launchpad is the place to ask. [15:54] k [15:54] adelie42: or post a question on LP... I believe your accounts can be merged [15:55] that would be nice [15:57] adelie42: You're not the only one who has had that problem :-) [15:58] It is a little funny to see myself as #2 and #4 contributor in a project... [16:12] Hi guys. how can i create a jaunty pbuilder on debian? [16:14] At a guess, install jaunty's debootstrap .deb ? [16:15] Assuming Debian's debootstrap doesn't already handle jaunty? [16:17] Actually all ubuntu since gutsy have used the same debootstrap script [16:17] so you can probably get away with just adding another symlink to /usr/share/debootstrap/scripts/ [16:31] Either way shoule be fine. [16:31] shoule/should [16:32] RoAkSoAx: debootstrap >= 1.0.11 in Debian supports jaunty [16:32] thanks cjwatson :) [16:32] as of a while back we've been making efforts to keep debootstrap pretty much in sync [16:32] in fact, I was just going to sync it up again now [16:33] ok :) great to hear :D [16:35] Hello, is Scott James Remnant here ? [16:36] AnAnt: try #ubuntu-devel === azeem_ is now known as azeem [17:16] james_w: bug 297847 - is there a reason shares-admin / "shared folders" was disabled in the menus and not shown in gnome? :) [17:16] Launchpad bug 297847 in gnome-system-tools "Shared Folders Administration Tool missing" [Undecided,Confirmed] https://launchpad.net/bugs/297847 [17:46] Hi, I have a question - a certain package is broken and is unusable in jaunty. How can I get it looked at if its not too late? [17:50] File a bug to start with [17:50] where? [17:50] the offending project was tagged as affected, but I doubt anyone will see it anytime soon. [17:51] Why are you avoiding mentioning what the package/project is? [17:52] er, because it was not asked for? [17:52] the project is gnome-web-photo and here is the report: https://bugs.launchpad.net/shutter/+bug/342408 [17:52] Ubuntu bug 342408 in gnome-web-photo "[jaunty] can't take web screenshot: libxul.so not found" [Undecided,Confirmed] === warp10 is now known as gaspa2 [17:55] vadi2: You could make a fixed package and follow http://wiki.ubuntu.com/SponsorshipProcess [17:57] and what is the success rate of that? (I just have a very poor experience when dealing with debian/ubuntu packagers, so just inquiring before I commit time) [17:58] Dunno, but I'd imagine "greater than the success rate of hoping someone will make the fix for you" [17:58]