[00:01] let's see where this discussion will lead to once all devs are back from weekend [00:31] Hello, where can I find the PPA version of gnome-screensaver? [00:31] Because I have the problem with screensaver coming on when watching fullscreen in VLC. [00:32] And as I read in LP, the PPA version is the only solution yet. [00:33] whose ppa do you want it from? [00:33] i'm sure more than one prson has packaged gnome-screensaver somewhere. whatever but report you're reading should specify [00:33] *bug [00:34] ok [00:34] * ajmitch would guess from the gnome-screensaver page on LP that it's the version in the motumedia PPA [00:34] I found it on LP [00:34] https://launchpad.net/+search?field.text=gnome-screensaver+ppa says the 3rd result has versions of gnome-screensaver for gutsy, hardy, and intrepid... [00:34] ajmitch: yeah, where can I find that? [00:34] probably launchpad.net/~motumedia? [00:34] I need the motumedia one [00:35] https://launchpad.net/~motumedia/+archive/ppa [00:38] ajmitch: so, I should add the PPA to the software sources of mine? can't I just download the specific package? [00:39] ok, found it [00:39] hope it helps [00:40] also, hope the patched package gets into the main repos [00:40] thanks [00:40] *blink* [00:40] * ajmitch shrugs [00:40] it should be aa fairly trustable PPA anyway :) [01:20] hey guys, so i want to get libjsw up and running by disabling jscalibrator directory from being called in the debian/rules and eliminating the binary from debian/control, what is the best way to do this, extract the orig tarball, apply the patch, edit, and the diff with the orignal to get an updated patch? [01:33] hey guys trying to package libjsw with jscalibrator disabled on karmic, got debuild to run finally, so now when uploading to my ppa do i need to upload the original tarball since it isn't in karmic yet, or do i need to use debuild -S or what? [01:35] looks like it's not in karmic due to probable removal [01:35] -S is always required, -sa will include the orig tarball [01:39] its not in karmic yet because it ties into gtk 1.2 but they are working on repackaging it with gtk 2.0, -sa will include the tarball in the changes file? [01:41] yes it will [01:41] thanks [01:41] I expect you'll probably have to edit more than debian/rules to disable the gtk+ app in there [01:41] like removing it from debian/control, various .install files, etc [01:42] jgoppert: A better bet then is to get it into Debian and sync it into Ubuntu from there. [01:43] ScottK: it's still in sid, not quite removed yet [01:44] ajmitch: Ah, even better. [01:44] jgoppert: Work on getting it fixed in Debian and then have it sync'ed it Ubuntu. [01:44] if you're really keen, offer to adopt the package in debian if you want to maintain it :) [01:45] Personally, with still 5% of the existing Ubuntu archive unable to be built from source, I'm not particularly excited about the prospect of adding more stuff we need to maintain to an LTS release. [01:46] well i'm really just a beginner, i just disabled jscalibrator which was the only really gtk dependency [01:46] only 5%, wow i didn't know that [01:46] looks like persia was offering to help maintain it in the debian games SVN repository [01:47] 5% is still too high [01:47] oh i read that backward, lol [01:47] everything in a release should be buildable on that release, IMO [01:47] but that's a lot of work for stuff carried forward over a few years :) [01:48] i was relying on checkinstall for the longest time, finally took the plunge into real packaging [01:48] ajmitch: My proposal is another rebuild test and remove the binaries for anything that FTBFS. That way we know everything was at least buildable at some point during the cycle. [01:48] ScottK: debian has it slightly easier in that stuff can be ejected from testing without being removed altogether [01:48] Yep. [01:49] We could at least not deliver binaries we don't have a hope of building. [01:49] ajmitch: I got one package removed in Karmic that hadn't been touched since Warty. [01:49] that's probably worthwhile [01:49] was this one of the ones imported from apt-get.org that we were discussing? [01:49] I think so [01:50] It was never in Debian. [01:50] LTS is a good time for a cleanup [01:50] You can check the old -changes archives to see where something came from. [01:51] when is the next lts release? [01:51] jgoppert: 10.04 [01:51] in april 2010, the development of it is just starting [01:52] nice, hopefully i'll be able to contribute by then to the packaging effort [01:54] so basically debuild -S just doesn't produce the .deb files [01:55] yes, -S means source-only, which is what's required for uploading to launchpad [01:55] ok and it looks like it appends source instead of the dist, so i'm assuming thats how apt-get source works? [01:56] apt-get source just grabs the .orig.tar.gz, .dsc & .diff.gz files listed in the repository's Sources index [01:56] basically just what you upload [01:57] ok, so this is a typical name to upload libjsw_1.5.6-0ubuntu3~hsl1_source.changes [01:57] with dput, yes [01:58] cool, how do i get files off there, because i uploaded a whole set with amd64 instead of source in the name [01:58] if you uploaded them to a PPA, they would have been rejected [01:59] ok, the command line didn't say anything, i guess i have to wait for launchpad to process it? [02:00] yes [02:01] ok, so if i started to maintain libjsw, what do i need to do, do i just upload to a different ppa? [02:02] maintenance would preferably be done in debian, because the maintainer has offered the package for adoption there [02:03] either way, you'd need to start off by getting the package upload sponsored [02:03] that is, someone with upload rights would need to upload it to debian or ubuntu [02:04] yeah, i tried to upload to my personal ppa and i got this? Rejected: [02:04] The signer of this package has no upload rights to this distribution's primary archive. Did you mean to upload to a PPA? [02:04] Not permitted to upload to the RELEASE pocket in a series in the 'CURRENT' state. [02:04] libjsw (1:1.5.6-0ubuntu3~hsl1) karmic; urgency=low [02:04] * Disabled jscalibrator due to gtk 1.2 dependency. [02:04] how did you try & upload to a PPA? [02:05] * ajmitch can't remember the relevant dput option to automatically pick your ppa [02:05] oh wow i didn't specify my ppa, guess thats how i upload to the real ubntu? [02:05] That is the real Ubuntu, yes. [02:05] dput ppa:user/ppa blah.changes [02:05] thanks wgrant [02:05] cool, yeah i think i got it now [02:06] saves me digging around for it [02:07] thanks for your help guys, has really helped me figure this out [02:07] * wgrant stabs Soyuz sample data in the face a few times. [02:08] wgrant: make some better sample data [02:09] how goes the great overhaul for new-style source packages? [02:09] Nearly there. Nearly there. [02:09] ajmitch: sample data *is the problem* [02:10] sample data is useful. [02:10] lifeless: I'd believe it, I hate trying to test some of the stuff I do at work due to having to create sample data for the weird corner cases [02:10] success, 2 pending builds [02:10] :-) [02:13] what is lpia, is that like the atom processor? [02:14] jgoppert: It is, but technically it's just like i386 now [02:14] Up through Jaunty there was some attempt at optimization for Atom, but it was dropped in Karmic. [02:15] oh ok, thanks, yeah i've got a little dell mini 9 [02:15] Is it kept in karmic for the lpia-specific functionality patches, or just for the upgrade path? [02:17] how long do personal ppa builds take? [02:17] depends [02:18] jgoppert: If you click on the architecture label in the appropriate row of your PPA table, it will give you an estimate of the start time. [02:18] Although in two days that will be wildly inaccurate :( [02:18] why is that? [02:18] Internal build queueing changes. [02:18] Without corresponding queue length calculation changes. [02:19] 5 hours.. ouch [02:19] inaccurate as in a few hours/days? [02:19] wgrant: :( [02:19] ajmitch: Depends on the length of the queue. [02:19] Basically, build will become a lot more serial from Thursday. [02:19] *builds [02:20] So the estimate will be lower than it should be. [02:20] do any of the PPA buildds get repurposed for the flood of autosyncs for lucid? [02:21] No. [02:21] * ScottK thinks the flood won't be so great if they sync from testing. [02:21] that kinda was a surprise :) [02:21] there'll be enough updates [02:21] jdong: yes, for many people [02:21] I noticed it a few days before release when looking at the lucid schedule [02:22] heh I personally think it's slightly ironic to try something this drastically new for a LTS [02:22] It was discussed at the last UDS, but for continuing to sync from testing after Debian freezes, not for the whole cycle. [02:22] ScottK: There are still approximately far too many. [02:22] ScottK: The page is still loading... [02:22] ScottK: didn't you hear, its more stable. [02:22] 2432 syncs fro [02:22] ... from Squeeze [02:22] lifeless: sure, and how many people run testing compared to unstable? [02:22] 1117 merges. [02:22] it'll be even more stable if we swap out the init daemon after feature freeze again! [02:22] oh wait *cough* [02:23] *goes back to his corner* [02:23] Well it makes "get it into Debian so we don't maintain it" a lot harder to sell. [02:23] ajmitch: turn up the gain on your sarcasm detector [02:23] jdong: If it was insanity, it was at least planned insanity. [02:23] ajmitch: going to pyconnz? [02:23] ScottK: It's not much of a problem; I don't imagine that Squeeze will freeze before Lucid. [02:23] lifeless: don't worry, I knew it was sarcasm :) [02:23] and yes, I'm heading up on friday [02:23] wgrant: It's scheduled for March. [02:23] ScottK: Ha ha ha. [02:24] wgrant: you sound like you don't believe that [02:24] wgrant: No, freeze schedules are reasonably reliable. It's release schedules that are unbelievable. [02:25] hey guys i tested my packaged in pbuilder and had this error? The following packages have unmet dependencies: [02:25] pbuilder-satisfydepends-dummy: Depends: libgtk1.2-dev which is a virtual package. [02:25] The following actions will resolve these dependencies: [02:25] Remove the following packages: [02:25] pbuilder-satisfydepends-dummy [02:26] I grepped for libgtk and got nothing left after i wiped it out. [02:27] gtk1 is poof, is it not? [02:27] Does anybody recall if all the buildds are running Hardy yet? [02:27] jdong: it is [02:27] yeah it is, i'm repackaging libjsw from jaunty [02:27] jgoppert: make sure you're building your revision of the package [02:27] oh, good call, let me check [02:27] since I can see on LP that you removed the libgtk1.2-dev from build-depends [02:29] the dangers of wildcard, lol *.dsc.. oops [02:30] indeed [02:30] it's certainly caused directhex to accidentally shove 2 or 20 packages into the Ubuntu queue [02:30] good thing i did that forgot a -f on a rm command [02:30] *ducks* :) [02:30] lol wow [02:30] lazy typing FTW :) [02:30] jdong: I'm sure he'd never ever do such a mistake [02:31] lol he fixed his overzealous dput by now :) [02:31] besides, he's probably not awake at the moment to hassle about it [02:32] lol I'm sure I'll be slapped by the time I wake up tomorrow morning [02:32] we can only hope [02:33] jgoppert: you are still applying patches in debian/patches that modify files in jscalibrator/ which seems a little bit silly since you arent building that package. It wont prevent it from building correctly though [02:35] serialorder, to my knowledge i didn't modify anything in jscalibrator, i just removed the statements dealing with it and eliminated the gtk dependency? [02:35] ok so i jacked up and submitted a package on my ppa without checking it with pbuilder, how best to delete the old one and submit the new one? [02:38] jgoppert, upload a new one with a newer version [02:38] jgoppert, you cn try deleting it from ppa but I've had mixed results with that :) [02:38] ok thanks [02:39] Even if you've deleted it, you still need to increment the revision [02:39] jgoppert: if i were packaging this I would split those patches into two sets of files. Those that patch files in jscalibrator and those that don't. Then you can enable to non-jscalibrator patches in 00list and leave the others out. It just seems wrong to patch files you aren't going to use. [02:40] You can never upload the same version again. [02:40] You can sometimes upload an older version if you really know what you're doing. [02:40] But it should not be relied upon. [02:41] oh i see, yeah those were from the old package, i didn't modify those, i figure i might get around to fixing the gtk stuff in jscalibrator eventually and don't want to mess up what was done there [02:42] warning: the current version (1:1.5.6-0ubuntu3~hsl1) is smaller than the previous one (1:1.5.6-0ubuntu3) [02:42] That's true. [02:42] what should i do about this, take ubuntu back down to 3? [02:42] i mean zero? [02:42] What's the current version? [02:42] In Ubuntu, that is. [02:42] well in jaunty 0ubuntu3 [02:42] nothing in karmic [02:42] Perhaps make it 3+hsl1 [02:43] Since your package is not less than the old version. [02:44] what if i went to 0ubuntu4~hsl1 so if some other packager releases a new one it will overtake mine? [02:44] hrm [02:44] is that what they would do typically going from jaunty 0ubuntu3 to karmic? [02:44] jgoppert: -0ubuntu3+blah has that same property. -0ubuntu4 is greater than it. [02:45] The next official version will be at least -0ubuntu4. [02:45] ok, thanks [02:45] there was a link in the topic... I think in here wrt open week? anyone happen to know what it is? [02:45] i'll go with the + then [02:48] neeeever mind... Sorry to bug yall it was in yet another ubuntu related channel. === micahg1 is now known as micahg [04:12] Can I get my patch sponsored? https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/470008 [04:12] Ubuntu bug 470008 in gnome-control-center "The Custom option in "Visual Effects" tab of Appearance Preferences should be shown even if simple-ccsm is not installed" [Undecided,Confirmed] [04:25] eboyjr: that's in main and the desktop team handles it so you'll want to talk to the folks in #ubuntu-desktop [04:25] eboyjr: but they won't be around for at least 3 more hours [04:25] and it's too early to upload anything to lucid [04:26] eboyjr: and it can't go into karmic because it's not a critical issue and it's sort of a UI change [04:26] Okay and why won't they be around? [04:26] Ah [04:26] eboyjr: they're all in europe :) [04:26] oh, and you need to attach a diff of the diff [04:26] reading https://wiki.ubuntu.com/Bugs/HowToFix & https://wiki.ubuntu.com/SponsorshipProcess might be useful too [04:26] or a debdiff would be even better [04:28] Those are the pages I read and okay I'll try to make a debdiff somehow whatever that it [04:28] s/it/is [04:28] they'll probably want a patch against the lucid version too, by the time it's ready [04:28] ;) [04:28] hey if i have a package on my ppa thats not yet in ubuntu would the version be opencv-2.0.0-0hsl1 or 0ubuntu0+hsl1 [04:29] LOL I'll just leave my patch out there in cyberspace then... [04:30] * Amaranth really wants to redo that whole tab anyway [04:30] or at least the code behind it, the UI is fine [04:33] Ah I like my feature though so please let me implement it (or have it implemented for me). But can I have a bug to fix then? I'm in a code-y mood [04:35] hey any way to get autotools to dump library dependencies to control file [04:36] eboyjr: there are something like 80,000 bugs open [04:36] finding one to fix should not be a problem :) [04:37] Haha I'm looking for a juicy bug thanks =) [04:37] eboyjr: do a sort byb importance, pick one [04:37] jgoppert: not currently [04:38] lifeless: thanks, that too bad [04:40] lifeless: all the critical bugs are hard [04:40] although some of the High ones can be pretty easy [04:40] so is my only option to add one library at a time using pbuilder to find the missing ones until it is all done? [04:40] By importance, I get bug from Edgy and stuff :P [04:40] jgoppert: yes, or read the configure script [04:40] thanks [04:40] (.in or .ac I mean) [04:44] if you have a really long list of dependencies in a control file is there a line continuation or do you just keep typing? [04:45] theres a continuation [04:45] \ ? [04:45] see policy for file format information [04:45] [I could just tell you, but then you'd not know how to find the answer to the next question :)] [04:45] true .. lol [04:46] well where is the policy file ? [04:46] apt-get install debian-policy [04:46] thanks [04:46] dpkg -L debian-policy [04:51] got it :-) [05:08] how often do you guys update your pbuilder, roughly speaking [05:11] jgoppert: every build, precisely speaking [05:12] yeah i guess you are right, no reason to risk it [05:31] Why might I be seeing idle builders at http://launchpad.net/builders, but LP tells me my PPA builds will start in 4 hours... ? [05:32] time constraints..... [05:32] Archive builders are empty, PPA builders are busy [05:34] Ah, OK... and we can't use empty archive builders for PPA work... because a PPA build might take a long time and a new urgent archive build *might* come along in the meantime? Or are they really configured very differently? [05:35] different build farm [05:36] It would be more efficient to have a single queue, at least in theory... oh well. I can attempt to be patient :) [05:37] For something that's urgent you can ping a buildd admin to get a build rescored. [05:38] My stiff is not urgent, it just seems sad to have build hardware waiting idle and a multi hour backlog of builds... [05:38] *stuff [05:38] * eboyjr didn't know Launchpad had a build farm that is crazy cool [05:41] eboyjr: Yes. When you upload a package to your PPA it gets built on multiple architechures automatically... that what the (PPA) build farm does. See https://help.launchpad.net/Packaging/PPA [05:42] jmarsden: I'd tend to go the other way. The Ubuntu toolchain maintainers are working on getting the toolchain for Lucid ready right now. I think the notion that a PPA upload might be allowed to block progress on getting Lucid open for development quite odd. [05:43] O I C it uses Xen [05:44] ScottK: Well, sure, if they need the hardware they should be able to grab it. Even kill a PPA build in progress and requeue it, if necessary. But that's surely doable with mimimal delay and would thus allow idle hardware to be used when toolchain maintainers *don't* have need of it. [05:45] Maybe make a feature request in soyuz [05:46] jmarsden: It takes a buildd admin to kill a build, so it's not always doable with minimal delay [05:47] There is work in progress to pool the buildd's, but I don't know the details. [05:47] ScottK: OK. I had assumed they already *were* a single pool, basically. [05:48] No. One of the big differences is that PPA buildds are virtualized and the distro buildd's aren't. [05:49] OK. Just for curiosity... is that for "historical" reasons, or do distro buildd's actually *need* to be real physical machines? [05:55] I would assume that PPAs are only virtualized for security reasons [05:55] I guess one reason is that virtualization helps a bit with security (everybody can try to abuse a PPA builder) [05:55] heh :P [05:55] lol.. [05:56] And that distro builds need to be able to be built on physical machines for e.g. testing [05:56] testing as in other people can fixs bugs and compile on their own system [05:56] well, it also helps that you can use a pre-made image to boot a builder, so that would be useful for the distro builders too [06:40] can anyone help me, i've got zlib as a dependency in my control file but when i use pbuilder its getting undefined references to symbols in the zlib library, what could be going on? [06:41] jgoppert: do you have the -dev version as the build-dep? [06:42] for opencv-dev i have zlib1g-dev, for opencv2 i have zlib1g [06:44] micahg: for opencv-dev i have zlib1g-dev, for opencv2 i have zlib1g [06:45] can you pastebin your contorl file? [06:45] *control [06:46] jgoppert: you shouldn't manually list the binary library [06:46] jgoppert: shlib-deps will get that for you\ [06:46] thats what i thought but i was getting that error so i thought it missed it, what could be wrong then [06:47] Source: opencv [06:47] Priority: extra [06:47] Maintainer: James Goppert [06:47] Build-Depends: debhelper (>= 7), autotools-dev [06:47] Standards-Version: 3.8.1 [06:47] jgoppert: use pastebin please :) [06:47] what's pastebin? [06:48] is it an irc command? [06:48] !pastebin [06:48] !pastebin [06:48] pastebin is a service to post multiple-lined texts so you don't flood the channel. Ubuntu pastebin is at http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic [06:48] jmarsden: Sorry :-) [06:48] !pastebinit [06:48] pastebinit is the command-line equivelent of !pastebin . Command output, or other text can be redirected to pastebinit, which then reports an URL containing the output. Simple usage: command-name | pastebinit [06:49] !pastebin [06:49] pastebin is a service to post multiple-lined texts so you don't flood the channel. Ubuntu pastebin is at http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic [06:49] http://paste.ubuntu.com/307295/ [06:51] jgoppert: you probably need to add zlib1g-dev to the source build-depends on line 4 === micahg1 is now known as micahg [06:53] so build depends is everything needed to build the package then, and the others are just for package management? [06:53] yes, anything that needs to be installed alongside the package in question [06:53] so i'm assuming all of my -dev's need to go up there? [06:53] most likely, if they're needed for building [06:53] i see [06:54] thanks [06:55] np [06:55] so should i remove the -dev's from the opencv-dev ? [06:55] and i definetly should remove the libs opencv2 right? [06:56] yes, shlibs should take care of that as lifeless said [06:56] ok , what about on opencv-dev leave the -dev packages? [06:57] jgoppert: I don't know [06:57] maybe someone else can answer :) [06:59] hope so :-), i'll go ahead and launch my pbuilder and cross my fingers [06:59] hmm packaging libraries here? === jussi01 is now known as jussi01_ [07:10] good morning === dholbach_ is now known as dholbach [09:14] <\sh> moins [09:16] MoinMoin [09:31] hello [09:31] in which channel can I ask about packaging and debuild errors etc? [09:32] DexterLB: This one. [09:32] ah ok [09:33] I've made my first cmake app and it works! now I want to make a debian package [09:33] I use cdbs and when I do 'debuild -S -sa -k' it creates and signs the source-only package as expected but if I do 'debuild -sa -k' to create a binary package it does build it and puts the binaries in the right place in the debian folders, but I get an error. http://pastebin.com/m1253c568 [09:33] what list file is dpkg-buildpackage referring to? [09:34] actually dpkg-genchanges [09:35] I think one it uses itself. Does a straight debuild (with no options) work? [09:35] I'll try now [09:37] same error [09:37] :( [09:38] should I pastebin my rules, changelog and control files? [09:39] Hmmm. Sounds to me like a cmake-specific thing. I'm no expert at all on cmake and it is 1:38am here... I'd suggest you see if someone else has better ideas than mine :) [09:40] it's 11:38am here [09:41] I'll ask google (again) :D [09:41] DexterLB: Do you have a install file in debian/ directory? [09:43] no [09:43] cd debian && ls: http://pastebin.com/m578e5eb7 [09:44] DexterLB: One thought before I sleep: you are using a -1ubuntu1 version number, is there really a -1 package of this software already in Debian? If not, use -0ubuntu1 .. I wonder if that is confusing anything related to the error you are seeing?? [09:44] oops [09:44] wait, I'll try [09:44] good night btw [09:45] Goodnight. [09:46] I removed all .ex files from debian and fixed 1ubuntu1 to 0ubuntu1 [09:46] now building... [09:47] and same error [09:50] slytherin: here are the contents of debian/ : changelog compat control copyright dirs docs README.Debian rules [09:51] DexterLB: that is your problem. You need to have install file specifying what all files should go into the resulting .deb package. [09:51] BUT [09:52] cdbs executes make install [09:52] and after the debuild, despite the error, there is a folder debian/timelapse/usr/bin which contains the executable [09:53] DexterLB: Yes, but I think what slytherin is saying is that debuild doesn't know it should package those files, until you tell it to do so. [09:54] By listing usr/bin/whatever in a file named debian/install [09:54] aaah [09:56] so I create a file debian/install containing "debian/timelapse ." [09:57] or "debian/timelapse/usr/bin/timelapse usr/bin/timelapse" for file-specific [09:57] DexterLB: No, containing the one line /usr/bin/timelapse if that is the file you are packaging. [09:57] I'll try [09:57] Sorry, make that usr/bin/timelapse, no leading / if I remember rightly. [09:57] yeah [09:57] ok [09:58] dholbach: around? have you a moment? [10:00] did it, built, same error :( [10:07] gaspa: yep [10:08] warp10 and I have a question for you ;) [10:08] sure === keffie_jayx is now known as effie_jayx [10:12] dholbach: we're in #6had, just to not bother this channel... k? [10:13] rules: http://pastebin.com/m772a1040 [10:13] control: http://pastebin.com/mbebecd0 [10:13] changelog: http://pastebin.com/m42a68215 [11:52] good morning [11:54] i want to file a bug report for rhythmbox and i can't because i'm behind a proxy server [11:54] how should i file the bug? [11:54] the "report a problem" from the help menu doesn't support proxy [11:58] Rocha: ubuntu-bug? [11:59] i suppose ubuntu-bug uses apport [11:59] and apport doesn't support proxy [11:59] but i'll try anyway [12:00] micahg: yes, i'm correct, it doens't work [12:01] i filed the bug to rhythmbox's bugzilla [12:01] Rocha: instructions for manually filing are here: https://help.ubuntu.com/community/ReportingBugs [12:02] i just wanted to report that rhythmbox can't get track names if you're behind a proxy [12:02] micahg: i've already read that [12:02] obviously not [12:02] https://help.ubuntu.com/community/ReportingBugs#Filing%20bugs%20at%20Launchpad.net [12:03] sorry, i really missed that [12:03] :) [12:04] Rocha: may be the problem is with your proxy [12:04] i'll get the source for rhythmbox to see if i can fix the bug [12:05] slytherin: i suppose the protocol is the same for all proxies [12:05] if other applications work, rhythmbox should work too [12:05] i'm using a web based chat client throught proxy using firefox [12:07] i've just found a bug in gnome-panel also === stefanlsd1 is now known as stefanlsd [12:23] i hope this bug is easy to fix [12:24] unfortunately rhythmbox is coded in C [12:24] i don't know why people insist on using C for desktop applications [12:27] slytherin: i just installed banshee and it gets the track names, so it's really lack of proxy support in rhythmbox === JamieBennett1 is now known as JamieBennett === noodles775_ is now known as noodles775 === fenris__ is now known as ejat [13:22] I am looking at http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909-karmic.html and I am wondering why there are FTBFS for superseded packages, anyone care to explain? [13:23] serialorder: Those are packages that failed to build in the rebuild archive, but were subsequently superseded by packages in the primary archive. [13:23]