[00:16] tjaalton: ah, ok; thanks for following up then :) === Katze is now known as Shely === Shely is now known as Katze [01:38] if I import a pdf in the gimp as layers, how can I save that such that I get a multi-page doc? [02:06] why are 2.6.22-14 has no headers listed in hardy repos??? [02:06] er reformat [02:07] why doesn't 2.6.22-14 have no headers in repos* [02:07] lol close enough [02:07] but yeah i can't build against the 2.6.22-14 kernel without source [02:09] why do you want to? [02:09] Hobbsee: compile zaptel [02:10] it's not the latest kernel... [02:10] Hobbsee correct! [02:10] Hobbsee but apt-get upgrade doesn't provide the 2.6.24-2, and i am having issues building zaptel with that kernel/source combo [02:11] Hobbsee, can you look at the build failures of celestia 1.4.1+cvs20070626-3ubuntu3? That's a transient problem, right? [02:11] nny_1: linux-headers-2.6.24-2 - Header files related to Linux kernel version 2.6.24 [02:11] appaers to be there [02:12] yes, but not linux-2.6.22-2 [02:12] er 2.6.22-14* [02:12] and if i do an apt-get upgrade, which I assume means, latest suggested packages, it doesn't try to move the kernel up to the latest version [02:13] so* I tried using it anyways, and it screamed [02:13] make[2]: Entering directory `/usr/src/linux-headers-2.6.24-2-server' [02:13] scripts/Makefile.build:46: *** CFLAGS was changed in "/usr/src/zaptel-1.4.7.1/Makefile". Fix it to use EXTRA_CFLAGS. Stop. [02:13] make[2]: *** [_module_/usr/src/zaptel-1.4.7.1] Error 2 [02:13] make[2]: Leaving directory `/usr/src/linux-headers-2.6.24-2-server' [02:13] make[1]: *** [modules] Error 2 [02:13] make[1]: Leaving directory `/usr/src/zaptel-1.4.7.1' [02:13] make: *** [all] Error 2 [02:13] gah [02:13] dangit [02:13] yeesh. pastebin, perhaps? [02:13] pidgin as an IRC client FTL [02:13] Hobbsee: ya think? i wasn't intending for it to line break [02:14] install it manually. or install linux-headers-generic to automatically pick them up [02:15] muwhaahaha [02:15] nope [02:15] linux-headers-2.6.24-2 linux-headers-2.6.24-2-generic linux-headers-generic [02:15] sigh.. so wait, hardy doesn't suggest I use the latest kernel, but gives me no method for compiling against the current one... this is a bug methinks [02:15] hardy does now. [02:15] So you edit that Makefile to use EXTRA_CFLAGS, not CFLAGS [02:16] you presumably don't have the latest package "linux" installed [02:16] it's not a bug that you havent' gotten the correct metapackages installed (and yes, the dist-upgrader checks for this) [02:16] nny_1: you're not going to get linux-headers-2.6.22-14 anymore, that's an old kernel. [02:17] It should still be linux-generic / linux-server, surely? [02:17] StevenK: yeah was gonna do that.. but i have numerous other things to compile, and that error got me thinking otherwise.. trust me, i wouldn't use alpha for this if i didn't need something that was only in sid/hardy's repos AFAIK [02:17] Hobbsee: Only upgrade-manager checks that. Apt-get allows broken systems. [02:17] nny_1: Then why not backport what you want to Gutsy? I would. [02:17] ok well, i did an install, apt-get update, apt-get upgrade and this is what i have [02:17] StevenK: i spent 9 hours trying to do that with the original dapper install, and it got angry... [02:17] persia: this is true [02:18] Note I didn't say Dapper [02:18] persia: upgrade manager doesn't run on a server [02:18] StevenK: indeed [02:18] StevenK: mind you i am battling libsnmp9 badness [02:18] heh who am I kidding, it's all a science project [02:19] nny_1: Good point. Likely a bug. I'll file that. [02:20] Upgrade manager will be put into Dapper before Hardy releases [02:20] persia: no problem, was only curious as to which version *I* should be using on server [02:20] since there is no GUI on this box [02:21] nny_1: I tend to use aptitude for servers, but there ought be a CLI update-manager to make it easier. [02:21] update-manager-core has the CLI one, doesn't it? [02:21] StevenK: yeah i agree with the gutsy thing. this is more of, I had stable asterisk running on dapper, want to get snmp working for many many more servers later, figured since we only use LTS for these that Hardy alpha would be a good time to try it [02:23] persia: noted.. i switch between aptitude and apt [02:24] I assume the cflags issue means EXTRA_CFLAGS+=-DSTANDALONE_ZAPATA -DBUILDING_TONEZONE (added the EXTRA_) [02:24] Right [02:25] hrmm [02:25] seems to be happier.. wait for it.. nope shoot [02:25] same error [02:25] let me see if their are other areas in the Makefile [02:26] ahh foudn it my bad [02:26] lol i don't even want hotplug support :\ [02:37] lol well heck [02:37] i installed th enew image, but still running the old one [02:40] lol reboot [02:40] again [02:40] :) [03:53] good evening everyone === DoubleDave is now known as ubergoober [03:54] l === ubergoober is now known as DoubleDave [03:54] anyways hows things in here tonight? === stu1 is now known as stub === elkbuntu_ is now known as elkbuntu === bigon is now known as bigon` === rob1 is now known as rob === ubiq__ is now known as lucid === rob1 is now known as rob [06:31] Hi all! === \sh_away is now known as \sh === cassidy_ is now known as cassidy === \sh is now known as \sh_away === azeem_ is now known as azeem === bluekuja_ is now known as bluekuja === Lure_ is now known as Lure === \sh_away is now known as \sh === \sh is now known as \sh_away === bigon` is now known as bigon === \sh_away is now known as \sh === \sh is now known as \sh_away === Hobbsee_ is now known as Hobbsee === \sh_away is now known as \sh === \sh is now known as \sh_away === \sh_away is now known as \sh [12:16] * Hobbsee looks at celestia for keescook [12:17] keescook: i'm hoping that's transient. if not, i'll look at it again. [12:21] celestia has failed to upgrade for a while, but i haven’t got around to reporting a bug yet. [12:22] dpkg: error processing /var/cache/apt/archives/celestia-gnome_1.4.1+cvs20070626-3ubuntu2_i386.deb (--unpack): [12:22] trying to overwrite `/usr/share/celestia/data/asteroids.ssc', which is also in package celestia-common [12:22] ion_: The bug exists. I'll dig it up for you. [12:22] darn, it's not transient [12:23] hum, damh [12:23] er, damn [12:23] would probably be nice to do another upload for that [12:23] bug #176576 [12:23] Launchpad bug 176576 in celestia "package celestia-kde None [modified: /var/lib/dpkg/info/celestia-kde.list] failed to install/upgrade: trying to overwrite `/usr/share/celestia/data/asteroids.ssc', which is also in package celestia-common" [High,Fix released] https://launchpad.net/bugs/176576 [12:24] Hobbsee: Yes. It needs versioned conflicts/replaces set properly. [12:24] uhhhhhhhhhhh [12:24] cprov...... [12:25] lamont: fairly urgent ping [12:27] the buildds shouldn't be that empty, i'm sure [12:27] unless everything is takign 40 seconds to fail [12:27] persia: Thanks [12:29] keescook: okay, that looks like fairly big "Soyuz has FUBAR'd"-type problems. [12:30] but damn, lamont had better like seeing the hppa's down to 0 builds. [12:33] keescook: s/Soyuz/GNOME/ [12:42] Hobbsee: looks like esound-common got lost in hardy [12:42] * persia thought that was intentional, as part of pulseaudio-by-default [12:43] so, uh, where is it? [12:43] persia: but then it makes libesd-alsa0 and libesd0 uninstallable [12:43] That binary is still built. [12:43] I think Soyuz got confused. [12:44] Fujitsu: well, exactly [12:44] It doesn't seem to exist in the archive, but the SPR page says it does. [12:44] and many packages still depend on libesd [12:44] But that source has had bad things done to it. [12:44] geser: In the case of libesd0, that's a good thing (in my book). In the case of libesd-alsa0, perhaps it needs to be done differently. Anyway, I see 0.2.38-0ubuntu4 in the pool. [12:44] geser: Like libgnome, so the world has exploded. [12:44] source hasn't appeared to change since gutys [12:45] Hobbsee: pitti moved libesd yesterday from main to universe and back to main [12:45] perhaps soyuz ate it [12:46] That's what I discovered and suggested in #launchpad... I don't think Soyuz liked it much. [12:46] ohhh..... [12:46] That binary has vanished. [12:46] Hrm. pulseaudio-esound-compat Provides; esound. Perhaps that's insufficient. [12:46] Fujitsu: what's the status of the build? [12:46] persia: esound-common [12:46] Fujitsu: failed to upload, by any chance? [12:46] Hobbsee: What build? [12:46] esound, i think [12:46] Fujitsu: or anything that built that depended on it [12:47] Fujitsu: That's just documentation, and doesn't have an rdepend from gnome from my cache. [12:47] libesd0: Depends: esound-common (>= 0.2.38-0ubuntu4) but it is not installable [12:47] * Hobbsee wonders what happens if you rebuild libesd0 [12:48] Fujitsu: not only Gnome broke on the missing esound-common but also KDE [12:48] geser: Yay. [12:48] * persia suggests replacing libesd0 with something else. Purging the package doesn't break GNOME. [12:49] * Hobbsee ponders uploading a no-change-rebuild, and seeing what happens [12:49] I suspect Soyuz didn't process-deathrow before it was repromoted. [12:49] no idea. you're hte soyuz expert. but that sounds possible [12:49] So it might have seen the existing binary record in main, and not overwritten it, so it then got removed. [12:50] * Hobbsee thought deathrow was used for removed packages, not demoted ones [12:50] I bet everybody's off and uncontactable for Christmas too :P [12:50] Hobbsee: either it breaks further more (in which case you have a week to fix it) or it works again [12:50] Hobbsee: The binaries were removed. From a component. [12:50] Fujitsu: oh, point. [12:50] * Hobbsee grabs source [12:51] A no-change rebuild should probably fix it - if only by getting the binary republished. [12:51] (of esound) [12:51] Poking a Soyuz person is probably better, though. [12:51] they won't be around for the next week, at least. [12:52] * Hobbsee uploads [12:52] does it need to go through binary NEW? [12:52] Fujitsu: worthy of a soyuz bug, though [12:52] That's no problem for Hobbsee. [12:52] geser: shouldn't do. [12:52] geser: but, i can accept from there anyway [12:53] shouldn't, as it's my own upload. but can. [12:53] Hobbsee: Sure, but I'll poke more thoroughly first. [12:53] geser: why would it? [12:53] oh, yes, it might get chucked there, i guess [12:55] geser: I think the binary still exists, just the publishings are deleted. [13:05] * Hobbsee taps fingers, waits for queue builder [13:13] Hobbsee: could you also give-back kdmtheme rhythmbox gnomebaker mrwtoppm empathy once esound-common is back? [13:14] geser: i'd be in favour of getting someone to call cprov or something, and getting him to do a mass giveback before christmas. [13:14] then let the buildds sort it all out over the break [13:42] right. now we have esoudn common. === \sh is now known as \sh_away === \sh_away is now known as \sh [13:56] Hobbsee: what was this esound upload? [13:56] seb128: a soyuz bug. [13:56] seb128: it ate the binaries [13:57] Hobbsee: has that been confirmed as a soyuz issue? [13:57] Hobbsee: what binary has been eaten by soyuz there? [13:57] * Hobbsee ponders what to answer to that [13:57] seb128: esound-common [13:58] esound-common vanished from the archive after a rather odd sequence of events on its source package. [13:58] Hobbsee: pitti demoted esound yesterday, are you sure that the binary is not just to universe? [13:58] did you speak about somebody from the soyuz team about the issue? [13:58] seb128: based on how it just ended up in new, it's probably a reasonably safe assumption that it wasn't in universe. [13:59] seb128: and it's not in apt-caches, etc, so not in the recently published universe lists [13:59] Nor rmadison. [13:59] ok, did you raise the issue to the soyuz team before trying to workarouding it? [13:59] seb128: no [13:59] grr [13:59] seb128: although Fujitsu filed a bug. [14:00] seb128: it's a sunday, and it's the 23rd of december. last i checked, they'd all left for holidays, haven't they? [14:00] <\sh> Hobbsee, 22nd of Dec [14:00] Hobbsee: it's saturday in most timezones and in holidays != vanished [14:00] \sh: 23rd here, but granted. [14:00] I'm on holidays and I'm still reading mails ;-) [14:01] you and Riddell appear to be the exception [14:01] Such dedication [14:01] Or insanity, either way [14:01] and StevenK ;-) [14:01] Ergh, they're multiplying! [14:01] Riddell: had a meeting [14:01] so he's excepted [14:01] I'm not reading e-mail, I'm heckling [14:01] Hobbsee: I'm not that sure, I think several people read mails every now and then [14:02] I'd do more fftw3-dev rebuilds, but slangasek might hate me [14:03] Wait, he won't. Alpha 2 is out the door. [14:03] StevenK: it's not a freeze now [14:03] but, do check to see if esound and friends are all happy now, so thinks don't fail [14:03] seb128: Did you see gimp in -proposed? [14:03] StevenK: I've read the -changes mails [14:03] StevenK: look like you didn't try building the update? ;-) [14:04] Shush. :-( [14:04] Hobbsee: there is no esound in NEW [14:04] seb128: yes, i know. [14:05] nor glib2.0, weir [14:05] weird [14:05] * Hobbsee wasn't aware that glib2.0 should be in NEW [14:06] Hobbsee: there is a new libgio-fam binary [14:06] it was built by an another source package before though [14:06] so it might not require NEWing [14:06] seb128: looks like someone else approved it [14:06] yeah, quite possibly. it appears to be built from the right source nwo [14:06] Hobbsee: what about esound? [14:06] unless i'm incompetent using my tools, of course. [14:06] and somebody retried the rhythmbox build [14:06] seb128: it was in new. it's now not [14:07] but that still didn't work due to esound [14:07] ahh, yes, so this is how you found out to come and yell at me. [14:07] this is true. wasn't sure if it was transient, as keescook asked me to check a similar failure [14:07] Hobbsee: no, I started IRC because I read the hardy-changes mails [14:07] I asked pitti to retry the rhythmbox build yesterday already [14:08] yes, and it failed. [14:08] since it failed because libesd0 was in universe [14:08] i retried it today, adn it also failed, so some of us in here debugged the problem. [14:08] right [14:08] * Hobbsee is not *that* incompetent, FYI. [14:08] Hobbsee: well, we were debugging the problem yesterday already [14:08] and that's something that should not require a new upload [14:08] but should rather be fixed at the archive level [14:08] next week. [14:09] the week after that most likely [14:09] * Fujitsu notes that all is good now, anyway. [14:09] everybody is on holidays next week ;-) [14:09] so, 2 weeks. [14:09] So we have half of main uninstallable for two weeks, yay. [14:09] * Hobbsee notes that some people *might* actually care about building anything GUI-related in the next 2 weeks. [14:09] Fujitsu: I though all was good now? [14:10] Hobbsee: I'm pretty sure that people would reply to mails [14:10] seb128: I meant in the scenario where no rebuild occurred, sorry. [14:10] seb128: it is now, after my upload, which you're telling me that i shouldn't have done. [14:10] I for one joined IRC [14:10] and I think that if somebody mail pitti he's likely to show up today [14:11] * Hobbsee notes that he, in all likelyhood, could not fix it, if it's a soyuz bug? [14:11] but right, the bug has been workarounded so there is no hurry now [14:12] Hobbsee: well, there is often way to workaround soyuz issue as archive admins [14:12] seb128: archive admins can republish removed binaries? [14:12] nothing is trashed [14:12] sure, it's still in librarian. but it wasn't in hardy at all. [14:12] you just have to move the binaries from where they are to the right place back usually [14:13] The binaries had been deleted. They weren't moved to anywhere. [14:13] Fujitsu: how do you now? uploads rejected are moved somewhere and not deleted for example [14:14] Fujitsu: are you sure they are not somewhere in the librarian? [14:14] seb128: This was a legitimately superseded and subsequently `deleted' (although still in librarian) binary. [14:14] RIght, but can one recover them from there without being a god? [14:14] * Hobbsee ponders the point of fishing for them in librarian, vs just reuploading, and taking 3 mins on all arches to build. [14:15] Hobbsee: well, the point is that there is a soyuz bug there [14:15] seb128: https://launchpad.net/bugs/178102 [14:15] Hobbsee: and sometime it's easier to debug things when they are still in a weird state than after workarounding [14:15] Launchpad bug 178102 in soyuz "(Quick) promotion and demotion can lose binaries" [Undecided,New] [14:15] seb128: this can happen to any binary. obviously, ones which do *not* cause mass uninstability would be good ones to test with [14:16] but, i see your point [14:17] ok, I didn't know that was happening to any binary and easy to trigger since I didn't try [14:17] Hobbsee: thanks anyway to workarounding the issue ;-) [14:17] seb128: you're welcome. do you still think i'm incompetent? [14:18] Hobbsee: I didn't say or though that you are incompetent [14:18] I would just have tried to contact somebody from the soyuz team before workarounding the issue [14:19] * Hobbsee normally would have [14:19] though admittedly that's not the best timing due to holidays [14:19] * Hobbsee is aware of the time of year, etc, though. [14:19] * Hobbsee has no contact phone numbers, etc, cprov is not talking, etc. [14:20] in fact, none are on irc at all, not even logging [14:20] no === asac_ is now known as asac [14:20] * seb128 hugs Hobbsee [14:21] Hobbsee: sorry for ranting [14:21] * Hobbsee continues to hide behind her seb-shield. [14:21] * Hobbsee does not wish to be blasted again === bigon is now known as bigon` === bigon` is now known as bigon [14:22] Hobbsee: could you give an another rhythmbox build retry? ;-) [14:22] <\sh> how lucky i am..wine needs libesd0 lol [14:22] seb128: I wouldn't advise it for at least another 10 minutes. [14:22] Fujitsu: publisher is still running? [14:23] seb128: Doesn't it normally finish around */45? [14:23] Fujitsu: ok thanks, no hurry there [14:23] Erm, 20 minutes, then. [14:23] seb128: yeah, but still waiting for the rest to publish. [14:23] * Fujitsu can't count. [14:23] seb128: btw, i also checked the scrollback, to see exactly what you guys had done, too. [14:24] Hobbsee: sup? [14:24] Hobbsee: well, when I pinged pitti yesterday the issue was that libesd moved to universe [14:24] Hobbsee: we didn't notice any lack of binary there [14:24] seb128: and it moved back. as you would have seen, had you checked your aptcache. [14:24] Hobbsee: ? [14:24] * Hobbsee isn't sure why it only ate that binary, and not the others, though [14:25] Hobbsee: an arch any or all issue? [14:25] lamont: can you do a mass giveback? [14:25] nope [14:25] seb128: i don't know. perhaps it is [14:25] lamont: do you have contacts for those who can? [14:25] There are strange things done with arch: all domination. [14:25] lamont: it would be nice to do it over christmas [14:25] lamont: seeing as we have empty, waiting buildds [14:26] well, there's the RSI-inducing button-clicking method... [14:26] and no kde4 uploads :P [14:26] Hobbsee: what about my aptcache? pitti said he promoted the binaries again yesterday and after that we were on holidays, I didn't look at anything out of my mails today [14:26] then what can: cprov, infinity [14:26] sarah@LongPointyStick:~% madison libesd0 1:06AM [14:26] libesd0 | 0.2.38-0ubuntu4 | http://mirror.internode.on.net hardy/main Packages [14:26] libesd0 | 0.2.38-0ubuntu4 | http://archive.ubuntu.com hardy/main Packages [14:26] esound | 0.2.38-0ubuntu4 | http://mirror.internode.on.net hardy/main Sources [14:26] esound | 0.2.38-0ubuntu4 | http://archive.ubuntu.com hardy/main Sources [14:26] lamont: right. got contact #'s for either of them, to start it off? (but wait till we've got some bits checked, that the esound stuff really has worked) [14:27] seb128: ^ should have told you that it was in main again (source and binaries) [14:27] no [14:27] lamont: guess seb128 had better be begged to do it, then [14:27] Hobbsee: well, since pitti promoted it yesterday I though it would be there ;-) [14:27] seb128: well, most of it is... [14:28] Hobbsee: what do you need now? build retries for what? [14:28] Ermmm. [14:28] note that I'm not a buildd admin and can't do those [14:28] This is odd. [14:28] seb128: you have the great canonical phone directory. [14:28] Soyuz left the binaries that still exist in universe. [14:28] Fujitsu: but didn't publish them? [14:29] Fujitsu: where are you finding that info? [14:29] Hobbsee: rmadison from an hour ago says -0ubuntu4 has esound binaries in universe. [14:29] rmadison might be lagged more, though [14:29] * persia notes that old binaries that aren't superceded by new versions for the same component and architecture have always seemed to benefit from manual poking. [14:29] Fujitsu: when was that last updated, though? [14:29] Hobbsee, StevenK: Recently enough that the esound-common one is missing. [14:30] Fujitsu: wlel, we don't know if that one got nuked between main and universe, or universe and main. [14:30] if it happened to get nuked btwn main and universe, that would still fit the problem [14:31] seb128: Did somebody not knock the binaries back to main? [14:31] what binaries? [14:31] esound should be in universe [14:31] libesd should be in main [14:32] Ohh. [14:32] I see, it is split. How confusing. [14:32] So it's just the arch: all that is broken. [14:33] <\sh> .oO(there should be someone doing lvl2/lvl3 on-duty call support somehow in between these peaceful days, no?) [14:35] Fujitsu: so something strange happens to arch: all binary demotions / promotions. got it. [14:35] ie, they vanish [14:35] \sh: presumably, unless they presumed that no one would do any ubuntu development over christmas [14:36] Yep. It may only occur when both are performed within a short window, but I'm not entirely sure of how the binary removals work. [14:36] guess you'll find out [14:37] <\sh> Hobbsee, well, it's the time of the year...all things which could get a bit messy are happening now [14:37] Like Christmas shopping. [14:37] * StevenK shivers [14:37] urgh. don't mention that [14:37] Hah. [14:37] * Hobbsee stabs stupid customers. [14:38] <\sh> or "hey, we are happy script kiddies, let's fck up some things" or "we produced a not known bug in our software..." [14:40] seb128: run "rmadison esound-common", there is no entry for hardy [14:41] geser: is that a follow up on the discussion we just had on the chan or a new one? [14:41] esound-common | 0.2.38-0ubuntu5 | hardy | all [14:41] a followup [14:41] on drescher [14:41] Aha, it's back! [14:41] for -0ubuntu4 there was no entry for hardy [14:42] geser: that's the bug we were speaking about and that Hobbsee workaround with the upload [14:42] good, i'm glad it's back [14:42] workarounded [14:42] and rmadison for mere mortals still shows -0ubuntu4 [14:42] seb128: It's probably actually `worked around' [14:42] Fujitsu: thanks ;-) [14:42] geser: did you run apt-get update? [14:43] seb128: rmadison uses a script on rookery. [14:43] rmadison needs "apt-get update"? [14:43] ok, I don't use rmadison so I don't know [14:43] maybe rookery didn't update yet [14:43] I don't think anything but drescher will have updated yet. [14:44] but it's good that the lost binary is back again [14:44] Get:1 http://archive.ubuntu.com gutsy/main esound-common 0.2.38-0ubuntu4 [42.2kB] [14:44] Gutsy, -0ubuntu4. [14:45] right [14:45] that's the current [14:45] still need to wait for an archive update [14:45] but since drescher has the new one that should be alright [14:45] let's wait for the next update [14:48] * Hobbsee gives some packages back, and sees what happens [14:48] They won't try to build for ages anyway. [14:48] why? [14:49] Oh, I guess the builds will immediately be recreated, rather than having to wait for queue-builder like new ones. [14:49] rhythmbox has started [14:49] That was quick. [14:49] * Fujitsu watches. [14:50] Aha, it worked. [14:50] kdmtheme got build-deps properly on castilla, at least. [14:50] And that was libesd0-dev. [14:50] looks like libgpod-dev is dead on hppa [14:50] Get:1 http://ftpmaster.internal hardy/main esound-common 0.2.38-0ubuntu5 [42.3kB] [14:51] Hobbsee: It *is* hppa... [14:51] <\sh> but it's not published on archive.ubuntu.com? [14:51] oh, that's depwaited [14:51] \sh: No, that won't sync for a while, probably. [14:51] <\sh> crap :( [14:52] * Hobbsee wonders why sg3-utils failed to upload on hppa [14:52] Hobbsee: When? [14:52] Fujitsu: sg3-utils [14:52] 2007-11-27 [14:53] er, that [14:53] hum, 5 min build tim [14:53] e [14:53] * Hobbsee hits retry [14:53] Hobbsee: It was promoted on the 27th. [14:53] ahhh [14:53] oh, so it was promoted [14:53] good. then it's fine to retry [14:53] Do you still have a page open from before you retried it? [14:54] <\sh> so no wine building...time to deal somewhat more with django [14:54] Fujitsu: no [14:54] why, what were you looking for? [14:54] Just wondering what time it failed, but it was probably the promotion. [14:59] \sh: It has hit a.u.c [14:59] <\sh> Fujitsu, cool thx :) [15:05] Hobbsee: the rhythmbox build worked, you rock ;-) [15:05] ok, enough computer for now [15:05] see you later [15:05] “enough computer”? [15:06] * ion_ has problems understanding the concept [15:06] ion_: You're not meant to understand it. It's a new Canonical plot to make our minds explode. [15:07] ion_: I heard there is this place called 'outside' === asac_ is now known as asac [15:07] Perhaps he went there [15:07] Amaranth: Ah, another Canonical invention. [15:08] * Fujitsu heads off to bed. [15:08] amaranth: This so-called “outside” is compatible with laptop computers. [15:08] Not if they have a glossy screen :P === jpatrick_ is now known as jpatrick [15:32] <\sh> hmm... [15:32] <\sh> libesd0-alsa is still not installable...strange [15:32] \sh: should be fixed [15:34] <\sh> libesd0-dev: Depends: libesd-alsa0 (= 0.2.38-0ubuntu4) but it is not going to be installed or [15:34] <\sh> libesd0 (= 0.2.38-0ubuntu4) [15:34] <\sh> Depends: esound-common (>= 0.2.38-0ubuntu4) but it is not installable [15:34] <\sh> just updated the pbuilder [15:36] \sh: Works from here, with updated cache. Which mirror are you viewing? [15:37] <\sh> persia, well, pbuilder is using archive.ubuntu.com but doesn't give me the used ip address from the RR [15:37] \sh: out of date [15:37] \sh: True. Keep updating until it works :) [15:37] Yay, works here too! [15:37] * pochu thanks Hobbsee [15:38] :) [15:38] ahh, there we go. [15:38] Totals by arch: [15:38] * sparc:29 [15:38] * i386:38 [15:38] * amd64:34 [15:38] uninstallable from main ^ [15:39] much better === ubiq__ is now known as ubiq_ [18:31] a question related to bug #500397: is it nautilus or gnome-vfs, which is deciding which inotify events are actually received by nautilus? i.e. are the events filtered somehow? [18:31] hmpf, should have been on gnome-devel, nevermind [18:34] hey all, i'm a debian package maintainer for apertium, the version in debian is 3.0.5 and the version in ubuntu is 1.0.3 [18:34] there is a lot of stuff that has changed in between the versions and i was wondering if it might be possible to accelerate the process of getting the new versions in ubuntu? [18:34] is there anything i can do to help etc. ? [18:36] <\sh> spectie, not true [18:36] oh ? [18:36] what is not true ? [18:36] <\sh> spectie, in our dev version apertium is http://packages.ubuntu.com/hardy/source/apertium [18:36] persia: celestia> nah, that bug will be fixed when the most recent build finishes -- I made a weird mistake with the rules file [18:36] apertium | 3.0.5-1 | http://archive.ubuntu.com hardy/universe Sources [18:36] aha cool [18:36] !info apertium hardy [18:37] (too slow) [18:37] * keescook wanders afk again [18:37] apertium: Shallow-transfer machine translation engine. In component universe, is optional. Version 3.0.5-1 (hardy), package size 251 kB, installed size 1044 kB [18:37] \sh, and when will that be in gutsy ? [18:37] <\sh> spectie, if then only via backports [18:37] spectie: I assume it will never be in gutsy [18:37] ok [18:37] in the same way it will never be in etch [18:37] You can request a backport if you want it in Gutsy. You will probably need some testing before it's approved. [18:38] what is the timescale of hardy being released ? [18:39] spectie: https://wiki.ubuntu.com/HardyReleaseSchedule [18:39] cool thanks [18:39] i guess it would be worth requesting a backport [18:39] as 1.0.3 is probably broken by default [18:45] !info lttoolbox hardy [18:45] lttoolbox: Apertium lexical processing modules and tools. In component universe, is optional. Version 3.0.1-1 (hardy), package size 16 kB, installed size 100 kB [18:48] !info apertium-es-ca hardy [18:48] apertium-es-ca: Apertium linguistic data to translate between Spanish and Catalan. In component multiverse, is optional. Version 1.0.5-2 (hardy), package size 778 kB, installed size 1700 kB [18:52] spectie: if you're just looking for versions, rmadison -u ubuntu $package in Debian will tell you the relevant versions [18:52] aha thanks [18:52] i just finished [18:53] but i'll remember in future [18:53] (rmadison $pkg will give you the versions for Debian, but you probably knew that already) [18:57] filed the request [18:57] thanks for your help [19:56] hmm, xine-lib 1.1.8-3ubuntu2 diff contains sources changes outside of debian/patches [20:28] promblems packaging flitghgear [20:28] http://paste.ubuntu-nl.org/49344/ [20:29] anny sollutions [20:30] <\sh> tuxist, looks like a missing lib/shared object or whatever... [20:31] i think it is problem in the header of libsgmisc [20:34] <\sh> tuxist, is it using simgear-dev? [20:34] yes i have version 1.0.0 [20:36] <\sh> tuxist, the version in hardy is still 0.3.10-2 for simgear0...so it could be that flightgear needs a newer version of simgear [20:36] i have installed allready the new vrsion [20:36] yes i have version 1.0.0 [20:37] <\sh> tuxist, so you are sure that your flightgear package is including the correct simgear package? :) [20:37] ./configure --prefix=/usr [20:37] <\sh> tuxist, so you just compile the source...but you didn't packaged it... [20:38] when have compiled the package i start packaging [20:38] sucsessful [20:38] ;-) [20:39] <\sh> tuxist, well, if you use pbuilder for building the package...you need to make sure that pbuilder is getting the 1.0.0 package of simgear and not the provided package from [20:42] i have the problem broken script [20:42] thanks [21:21] which package is responsible for the debug output on vt8? [21:26] nevermind [22:54] Probably PEBKAC, but it seems as if fglrx in hardy doesn’t support Xv. === \sh is now known as \sh_away [22:58] Huh. The tubes claim that i can only choose OpenGL acceleration *or* Xv acceleration. Way to go, ATI! :-P [23:05] After modifying xorg.conf, both seem to work after all.