=== LaserRock is now known as LaserJock === choudesh_ is now known as choudesh [04:17] * StevenK sighs. ENOCONTENTS for Hardy === stu1 is now known as stub [05:40] Fujitsu: have you found a workaround for making totem work? [05:40] for video? [06:16] doko: do you remember how you made OOo not ICE on sparc? [06:49] i setup photoshop cs2 on my desktop and showed it to my wife... letting her know her system will one day be running ubuntu ;-) [06:50] cool [06:50] good luck with that [06:50] she hates vista so she will end up converting when she gets a new machine anyway [06:50] my wife didn't mind much at all, but she mostly just needs Firefox and a word processor [06:50] it will just be a matter of if it will be running xp in a vm or using photoshop via wine [06:51] i had converted her, before we got married, back around 4.10 but didn't have a good solution for photoshop for her at the time so she switched back to xp [06:52] Gimp doesn't count? [06:52] gimp doesn't run photoshop filters does it? [06:52] or is there a hack to do that? [06:52] I have no idea, what are photoshop filters? :-) [06:52] StevenK: expensive add on programs to do all sorts of things to images [06:53] the main reason photoshop has lockin btw [06:53] calc: there was an effort using wine awhile back [06:53] StevenK: gimp lacks some of the neat features of PS, like adjustment layers. [06:53] http://www.gimp.org/~tml/gimp/win32/pspi.html [06:54] and 16 bit mode. [06:54] Burgundavia: cool i'll have to look at that [06:55] 16 bit mode in photoshop is a bit crap (imho) since most filters don't support it still years later [06:55] even adobe's own filters [06:55] calc: so? Filters are overrated anyway. [06:57] slangasek: I have no time to write the Alpha1 preview this time due to school and it doens;t look like anybody else is stepping up, so you are likely to have to get somebody internal to do it [06:58] wow, kubuntu blew up [06:59] * calc bbl bedtime [07:00] Riddell: broke it. [07:01] Mithrandir: can you demote kdegames-kde4 binary, please? [07:02] Hobbsee: you know it was you, stop blaming other people ;-) [07:02] LaserJock: ENOPOWER :) [07:02] i didn't accept hte binary. although, if i had, it would have gone direct to main, iirc. [07:03] i just can't demote things ;) [07:03] oh, awit, it's new stuff that goes direct to main [07:03] Hobbsee: done [07:04] Mithrandir: thanks [07:04] Mithrandir: Would you mind looking at libgpod in NEW? [07:04] Mithrandir: I'm happy to do the six or so rebuilds of r-depends. Or shall we leave it until after the release? [07:05] Burgundavia: righto, I've gotten good at cut'n'pasting from previous pages by this point :-) [07:05] StevenK: after the release sounds like a plan, unless slangasek wants otherwise? [07:05] slangasek: what's your plan with kubuntu cds, and are you intending to make your release discussions at UDS public at all? [07:05] StevenK: uhm, "freeze"? [07:05] slangasek: it's still a freeze even if it's not enforced as such. [07:06] slangasek: I'm happy to leave it, I just want something to do tonight. [07:06] Hobbsee: sorry, I saw your question about that; I was looking for a proper reference at the time I wrote that bit, but unfortunately I can't find that anyone took notes :/ [07:06] StevenK: here, sponsor this :-) https://bugs.launchpad.net/ubuntu/+source/wireless-tools/+bug/172510 [07:06] Launchpad bug 172510 in wireless-tools "please merge wireless-tools 29-1 (main) from Debian unstable (main)" [Undecided,New] [07:06] Mithrandir: yes, that's what I'm saying... :) [07:07] slangasek: right. so, um... [07:07] Hobbsee: I can try to write a brain-dumpy summary for you at some point; and pitti might have some relevant archive pointers [07:08] slangasek: Yeah, alright. And the reason I didn't upload ubuntu-meta was because there were no seed changes when I ran update [07:08] slangasek: that would be good, thanks. else i need to seriously consider stepping down from the team. [07:08] StevenK: hrm? there definitely were seed differences relative to what was in the archive [07:09] slangasek: Not according to when I ran ./update [07:09] StevenK: stupid question...but was that gutsy's ubuntu-meta, or hardy's ubuntu-meta? [07:09] Which do you think? :-) [07:10] Hobbsee: well, there shouldn't be need for an "else" here; if I don't get to it by next Tuesday (allowing for lack of brain availability over the alpha), just kick me harder [07:10] Obviously, it was warty's. [07:10] slangasek: will do. with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! ™ ? [07:12] Hobbsee: I would note fwiw that "how should we handle milestones" was the main topic for which the session was called, so apart from the crummy way in which you learned of it and the lack of easily accessible rationale, you do at least have the main conclusion... :) [07:12] slangasek: the "else" was only in the case of "if i don't know waht's going on, w.r.t process changes, etc, then it's impossible for me to usefully help out [07:13] Hobbsee: sticks are fine, though I'm not sure kicking with sticks is very kind to the sticks [07:13] slangasek: right - i'm aware that it's changed, but not to. [07:13] er, but not what to. [07:13] slangasek: that is exactly what I was going to do anyway :) [07:13] i didn't have my psychic cereal this morning. [07:15] wikipedios, part of this balanced psychic breakfast [07:28] good morning [07:28] * slangasek moos [07:29] * Hobbsee squeaks [07:29] dholbach! [07:29] hey guys :) [07:50] slangasek: Did you see the dpkg-source warnings for wireless-tools? [07:52] I believe I may have missed them. Is this during package generation? [07:53] slangasek: Yup [07:53] dpkg-source: warning: newly created empty file 'debian/ifrename.docs' will not be represented in diff [07:54] And ifrename.{install,postrm,init} [07:55] Good morning [07:55] morning pitti! [07:56] Morning pitti [07:56] StevenK: oh. that would be because you're applying a diff on top of the Debian source package and diff doesn't delete empty files for you :) [07:56] StevenK: so the fact that they won't be represented is just fine, 'cuz they're supposed to go away [07:57] Great [07:58] slangasek: Uploaded. Hopefully, just in time for the publisher. [08:28] calc: the previous failures were segfaults in the compiler. this failure doesn't look like the previous ones. [08:40] StevenK: thanks [08:50] Hi! I need your help. Iam collecting points in page listed below. If you be so kind, please click url below.(sorry for the spam, thank you) http://www.3dwhite.lt/?click=56a3cdcf22ccc7ab5f0a7f4d2bc900ff [08:58] TheMuso: could you attach a debdiff for the merge rather than a weird interdiff to the gnome-orca bug? [09:00] seb128: Ok, the only problem with that is the changes in the upstream tarball... [09:01] TheMuso: what do you mean? I don't understand what your interdiff is actually, you didn't describe what version you used, etc [09:02] TheMuso: do you need to change the upstream tarball? [09:02] seb128: Sorry, I thought the using of interdiffs for new upstream versions was being used with packages in main as well... [09:02] seb128: There is a newer upstream for gnome 2.21 available, so I thought I should use that. [09:02] TheMuso: no, we use a dsc and diff.gz usually and download the upstream tarball === rob1 is now known as rob [09:03] http://wiki.ubuntu.com/UbuntuDevelopment/Interdiff [09:04] dholbach: I know what interdiff is, I just don't know what version he used, etc [09:04] dholbach: you have to apply the diff to something [09:04] sladen: no, not console-setup - look in usplash's own source, and in the kernel source for the ioctl it's calling [09:04] (it's doing ioctl(KDFONTOP) and failing for some reason) [09:04] this page does not explain what interdiff is, but how it can be used in the context of sponsoring [09:05] Does anyone know when the next lifefs run is? [09:05] Hobbsee: dunno if you noticed, but apparently the +queue mail-sending bug is fixed [09:05] cjwatson: i did, thanks :) [09:05] dholbach: still need to get an upstream tarball and you need to know what version and from where (debian or upstream) [09:05] dholbach: no? [09:05] seb128: right [09:05] dholbach: or I'm being not awake or something [09:05] seb128: Ok if you prefer, I'll attach a .diff.gz and .dsc. [09:06] seb128: what does the version in the changelog say? [09:06] Hobbsee: No idea. I don't play video. [09:06] Fujitsu: pity. wonder if tjaalton knows. [09:06] looks like the new upstream version, no? [09:06] Hobbsee: Hm, wait a sec, I'll find the option. [09:07] dholbach: 2.20.1, Ubuntu has 2.20.0 though and new upstream version is 2.21.2 [09:07] seb128: hm, it says 2.21.2-0ubuntu1 in the bug report [09:07] dholbach: so I'm not sure from where the 2.20.1 is coming, it's neither what is in Ubuntu nor the new version [09:08] what happens if you apply it to the new upstream source? [09:08] Hobbsee: I can't find the video output options, but they're around somewhere [09:08] dholbach: right that's the new version, I'm trying to figure what it interdiffing [09:08] Fujitsu: right [09:09] seb128: The latest gnome-orca package in debian, 2.20.1-2 [09:09] TheMuso: so you interdiffed the Debian version and your update? [09:10] seb128: Yes, sorry I should have made that clearer in the report. [09:10] It looks like a new upstream version combined with a merge, so that makes sense. [09:10] interdiffs are the suck to read, I'm wondering why you guys don't just attach a dsc and a diff.gz [09:10] How is an interdiff worse to read than anything else? [09:11] seb128, with a -p1, it is very nice to read :) [09:11] Fujitsu: a merge with Debian should list the changes between debian and ubuntu, not a zillion weird changes [09:11] Greetings everybody! [09:12] somerville32: I'm using emacs to read it, what do you mean? [09:12] hey MacSlow [09:12] seb128, With new upstream releases, you only see the delta of the delta [09:12] seb128, For package updates, an interdiff of the two package diffs is the same as a debdiff [09:13] somerville32: I don't want to see the delta of the delta, I want to read the changes to the debian directory over the Debian version [09:13] seb128: that's what interdiff gives you, unless you encounter a case that interdiff finds hard to handle [09:13] (which does crop up from time to time, and may be what you've run into) [09:13] interdiff is used internally by debdiff [09:14] cjwatson: this interdiff has debian/compat removed and added again later with the same 5 value [09:14] which is weird [09:14] that would be a bug; that's not normal [09:14] cjwatson, The person who made the patch didn't use -p1 [09:14] TheMuso: Did you build the diff with -p1? [09:14] somerville32: perhaps a bug in the person who invoked interdiff, yes :) [09:14] [09:15] Fujitsu: I followed the procedure on the wiki [09:15] Well, you can't use the -p1 patch to reconstruct it [09:15] The -p1 is for viewing only [09:15] sebhttps://lists.ubuntu.com/archives/ubuntu-motu/2007-November/002767.html [09:15] bug #172515 [09:15] Launchpad bug 172515 in gnome-orca "Please merge gnome-orca 2.21.2-0ubuntu1 from Debian unstable." [Undecided,New] https://launchpad.net/bugs/172515 [09:15] oops... https://lists.ubuntu.com/archives/ubuntu-motu/2007-November/002767.html [09:15] the interdiff is attached there [09:15] Salut seb128, dholbach, cjwatson, mvo, keescook [09:15] salut MacSlow, mon ami [09:15] hey MacSlow [09:15] seb128: if you forget to pass the -p1 option to interdiff, then it considers changes in the base directory name to be significant, which means it's removing foo-1.0/debian/compat and adding foo-1.1/debian/compat [09:15] somerville32: Oh, woops, you're right. [09:15] s/you/somebody/ [09:16] cjwatson: ok, that's what it looks like there [09:17] somerville32: why can't you use -p1 to reconstruct it? [09:17] sure, you might have to rename a directory at the end [09:18] mm [09:18] if some bug means that you can't use -p1 to reconstruct, I agree with seb128, instead of advising people to attach an interdiff without -p1, you should advise them to attach the interdiff -p1 for easy viewing plus the new .diff.gz [09:19] I thought you could do it with the -p1 but Persia asked me earlier to reattach one without it to reconstruct [09:19] perhaps it was some special case [09:20] So, Does anyone know when the next lifefs run is? [09:21] somerville32: for which flavour? [09:21] Xubuntu [09:21] 9:55 London time [09:22] well, no, it'll start a bit after that [09:22] but that's when the cron job fires that includes a livefs build in the middle [09:23] ok, thanks [09:23] Is there some sort of method of notification for failures? [09:23] TheMuso: ok, I managed to use your interdiff, reviewing it now [09:25] somerville32: no, sorry [09:25] we may get something like that as part of developer-weather-report, I hope [09:25] * somerville32 thinks of whipping something up. [09:25] ok [09:25] Sounds hot. [09:25] * somerville32 chuckles. [09:26] TheMuso: are those debian/copyright formatting changes required? [09:27] seb128: I wasn't really aware of formatting changes, due to the way I reviewed the diff, i.e I didn't review it visually. But no they wouldn't be. [09:28] TheMuso: could you change that? diff the debian directories for the versions maybe [09:28] seb128: Ok. [09:28] thanks [09:37] seb128: Shall a .diff.gz attached to the bug be sufficient? [09:38] cjwatson: coming late to the party, but the reason that one can't always apply an interdiff -p1 to construct the new .diff.gz is that combinediff gets confused if hunks overlap, so the change in the directory name forces correct behaviour. I agree that interdiff without -p1 is not human readable. [09:42] persia: why wouldn't you just use unpack, patch, repack to reconstruct, rather than combinediff? [09:43] makes it simpler to use dpkg-buildpackage that way [09:44] TheMuso: at-spi, any reason for reverting the debian description changes there? [09:44] TheMuso: looks like you copied the ubuntu control rather than using the required changes on the debian one [09:45] cjwatson: The idea was to prepare a simple command line that would produce a file that a sponsor could use to get everything necessary, and support the case where diff -nuR debian/ wasn't sufficient (raw patches in diff.gz) for new upstream versions. I'm not sure how to easily generate a patch to be applied to old source that does the same without mixing upstream changes. [09:45] TheMuso: otherwise looks correct [09:46] cjwatson: The other bit is that one actually wants to unpack twice: once to get the watch file / get-orig-source rule to grab upstream, and a second time to create a candidate from the constructed orig.tar.gz [09:47] seb128/c [09:47] ugh [09:48] persia: it doesn't look like the result is something simple for a sponsor though [09:48] seb128_: Ok, I'll revert the descriptions. Is attaching updated .diff.gz and .dsc files to both the orca and at-spi bugs sufficient? [09:49] persia: I think it would be a lot better just to ask people to attach .dsc and .diff.gz (and .orig.tar.gz if necessary) plus a human-readable interdiff [09:49] TheMuso: either the interdiff or those [09:49] cjwatson: Agreed. I have a script that mostly works, but I'm still adding error checking & stuff, which will end up in ubuntu-dev-scripts. An early draft is at http://people.ubuntuwire.com/~persia/process-interdiff (and I'm expecting to have something sufficiently robust this coming weeked). [09:49] seb128_: Ok. [09:50] Hmm. I don't like people attaching orig.tar.gz, as LP doesn't check who people are very well, but maybe just diff.gz & a human-readable interdiff makes sense. [09:50] persia: I'm mostly worried about running into unnoticed round-trip errors between interdiff and combinediff [09:51] persia: well, instructions to fetch .orig.tar.gz anyway [09:51] in most cases it should just be something from a website [09:51] persia: easy enough to ask the upstream or debian tarball url [09:52] cjwatson: Right. Thinking more about it, diff.gz contains all the interesting bits, and is more familiar. For orig.tar.gz, I think the instructions belong in a watch file or get-orig-source: rule. [09:53] do we caution people that if get-orig-source is used then this *must* be coordinated with any other distros that ship the package? [09:53] cjwatson: *must*? Why? If we're repacking without it, we get a different orig.tar.gz without explanation. If we repack with it, we may differ, but at least we can explain why. [09:54] persia: *must* because if you don't coordinate and another distro ships the same version but a different .orig.tar.gz then we can't sync [09:55] if at all possible all .orig.tar.gz files floating around for the same version should be bit-for-bit identical [09:55] if they aren't identical for some known reason, then the versions should also differ [09:55] cjwatson: Ah. Just to be extra-clear: I strongly recommend that if Debian has the upstream version, we use a debdiff against Debian when sponsoring, and I didn't think we had sync working for any other distros. [09:56] persia: it sometimes happens that we package the new upstream version before Debian, and in that case it is important that we let the Debian maintainer know that we have an .orig.tar.gz [09:56] Should we be naming repacks with x.y.z+ubuntu-0ubuntu1 rather than x.y.z+dfsg-0ubuntu1 to support that? [09:56] persia: depends on the reason for the repacking [09:56] persia: ubuntu > debian [09:56] and no, I don't think so; we should instead be sharing the .orig.tar.gz with Debian [09:56] persia: for the versionning [09:57] it is better to actually have the same version [09:57] cases where we need different contents are vanishingly rare [09:57] well, the issue is often when we are faster to do the update than debian [09:57] Ah. So if we repack a new version, we should be notifying Debian that we have a new orig.tar.gz for consideration? I'd be happy to add that to the various docs on package updating this weekend (if someone else doesn't first). [09:58] yeah [09:58] or indeed, talking to the Debian maintainer to find out if they're about to do the same [09:58] (might be a better attitude than "notify" which can be a bit abrupt) [09:58] seb128_: Not always. At the beginning of a cycle, frequently debian > ubuntu. At DIF, ubuntu > debian. [09:59] persia: I was speaking about versions, if you use n-ubuntu you are not able to sync a n-dfsg later because you can't downgrade [09:59] seb128_: At-spi bug updated. [09:59] TheMuso: looking [10:00] seb128_: Ah. Right. I thought we didn't tend to sync Ubuntu updates anyway, but I suppose if we can institutionalize the practice of feeding orig.tar.gz's back, we will be able to do so. [10:01] persia: well, in the case when you package the new version before debian and want to use a different naming to be able to sync when they do the update you should use something which has a lower version [10:01] seb128_: gnome-orca bug updated. [10:02] seb128_: Right. I'll think about it some more before I update anything, and publish to u-d@ when I'm done. Thanks for reminding me. [10:03] persia: you're welcome [10:04] geser: hah, I already wondered why my hevea upload was rejected; you beat me to it by a few minutes :) === ivoks_ is now known as ivoks [10:08] yay apparmor -- it disallows access to creating bluetooth sockets without providing a profile option to enable it [10:09] pitti: builds in MANUALDEPWAIT should get automatically retried if the waiting package is there, shouldn't they? [10:10] geser: right [10:10] c [10:10] wrong tab.. [10:10] pitti: have you an idea why https://edge.launchpad.net/ubuntu/hardy/+source/cdebconf-entropy/+builds is in depwait? rmadison lists libdebconfclient0-dev | 0.125 | hardy | amd64, i386, powerpc [10:11] geser: hm, maybe "MANUAL"depwait is something special [10:11] pitti: There is no non-manualdepwair. [10:12] Er, s/r/t/ [10:12] geser: no idea then; I'll try a give-back [10:17] TheMuso: you didn't revert the at-spi description changes [10:18] - services, products and information. [10:18] + services, products, and information. [10:18] oh hrm. ok. [10:19] TheMuso: you also changed the dbg description [10:19] the new debian one is the correct one to use [10:19] ok looking. [10:19] is there a date when dpkg gets merged in hardy? As packages using dpkg-shlibdeps --ignore-missing-info FTBFS as dpkg-shlibdeps doesn't know this option yet (introduced in dpkg 1.14.8) === broonie_ is now known as broonie [10:20] doko: the ssed build-dependency for norwegian wasn't there for speed, it was there so the package built correctly. [10:22] * TheMuso hits himself on the head. I removed the wrong diff hunks. :S *sigh* [10:23] Mithrandir: hrm, then mention it? [10:23] * Use ssed instead of sed, since sed has turned into the slowest piece [10:23] of software on earth. [10:23] -- Tollef Fog Heen Fri, 4 Apr 2003 14:15:14 +0200 [10:24] doko: hm, I was fairly sure it didn't build correctly, but it seems I was mistaken. [10:24] I suspect you'll get buildd timeouts now, though. [10:24] unless libc has been fixed. [10:24] Mithrandir: lets wait. I'll look at the failures, it did build on amd64 [10:24] TheMuso: gnome-orca still has unrequired copyright changes [10:24] -It was downloaded from: . [10:24] +It was downloaded from [10:24] I thought we fixed that libc/sed UTF-8 thing ages ago [10:25] doko: I'm looking at gmetadom which you last touched. I don't understand your changelog entry "Fix build failure with g++-4.3." as I only see changed to debian/ files in http://patches.ubuntu.com/g/gmetadom/gmetadom_0.2.5-1ubuntu1.patch [10:25] TheMuso: copyright list, license text, etc [10:25] doko: it is ok to sync it? [10:25] cjwatson: it being slow as molasses? Maybe. See the date of the changelog above. :-) [10:25] TheMuso: you should take the debian version and add the credit line and that's about it, no other change [10:25] seb128_: Third times the charm I hope. at-spi bug updated. [10:25] geser: If you can build it with gcc-snapshot without modifications, yes [10:26] Mithrandir: I remember some kind of quadratic-time UTF-8 regex behaviour bug being RC for a previous Ubuntu release. I think it was sed. [10:26] cjwatson: sounds like something the norwegian build system would run into. [10:26] it's the most massive use of sed, awk and friends I've ever run into. [10:26] seb128_: Ok. [10:27] doko: simply install gcc-snapshot in a pbuilder and build it there? or are some additional steps necessary to test it? [10:31] TheMuso: looks correct now, thanks for the work there [10:31] seb128_: gnome-orca bug updated. [10:32] TheMuso: could you send the fix-server-i18n change to upstream and debian? [10:32] seb128_: Thanks a lot for being so patient. I'll visually review diffs in the future, and more thorougly. Speech doesn't always give all formatting problems away. [10:32] geser: make sure that the binaries in /usr/lib/gcc-snapshot/bin are used [10:32] seb128_: Sure, will do. [10:32] TheMuso: thanks [10:33] seb128_: The only thing I'm not entirely sure of, is what that patch for at-spi fixes. [10:34] hey TheMuso =) [10:34] Hey luisbg_ . [10:34] TheMuso: [10:34] " * Add debian/patches/fix-server-i18n.patch: Mark translatable strings in [10:34] registryd/Accessibility_Registry.server.in.in as such, so that intltool [10:34] picks them up." [10:34] that's the corresponding changelog entry [10:35] Right, saw that, but didn't make the connection at the time. === Shely is now known as MJ086 [10:45] TheMuso: do you need those gnome-orca credit change? If the debian maintainer didn't use your package there is no real point to add this to the copyright [10:46] doko: it FTBFS with gcc-snapshot. So I need to merge your changes, but I can't find the fix in the Ubuntu delta (which changes only some files in debian/) [10:46] TheMuso: the README.Debian change also doesn't look like something required [10:47] geser: what package are you looking? [10:47] gmetadom [10:47] geser: looks like there no change there [10:48] seb128_: the ubuntu delta should be http://patches.ubuntu.com/g/gmetadom/gmetadom_0.2.5-1ubuntu1.patch [10:48] I see there a comment from doko "* Fix build failure with g++-4.3." but not the fix itself [10:48] right, looks like he forgot to apply the change [10:48] geser: then please fix it =) [10:49] seb128_: Way back in 2006 the Ubuntu package was used as a base, but I am enclined to agree the credit is no longer needed. Updating again. [10:49] doko: do you plan to mail the debian lists or something about the python dbg changes? it's creating a lot of merge work on Ubuntu [10:49] TheMuso: thanks [10:50] seb128_: on my todo ... [10:50] doko: would be nice to have some sort of debian summary mail that we could note when sending the patch to the bts [10:50] seb128_: there's the wiki page [10:50] doko: could you bump it? so we don't have to merge those again and again, the earlier we send those to debug the better for everybody [10:51] doko: right, I'm not sure the debian guys will all welcome an ubuntu wiki page to justify changes though === ogra1 is now known as ogra [10:52] seb128_: Updated orca bug [10:54] sigh ... dhcp3 is such a monster ... we could write our own dhcpd from the patches we have === Ng_ is now known as Ng === pedro is now known as pedro_ === cprov-out is now known as cprov [11:22] cjwatson: if you have a minute, can you please ack my gutsy-proposed debdiff for bug 147800? it's pretty obvious and simple, but peer review and all that.. [11:22] Launchpad bug 147800 in cupsys "[Gutsy] : bluetooth printing was working but is not (at the beginning of september)." [Undecided,Confirmed] https://launchpad.net/bugs/147800 [11:33] doko: can you look at bug #172546 and tell me if that's the right fix? [11:33] Launchpad bug 172546 in gmetadom "[Merge] gmetadom 0.2.5-3ubuntu1" [Undecided,New] https://launchpad.net/bugs/172546 [11:33] doko: http://launchpadlibrarian.net/10620953/3-3ubuntu1.debdiff [11:33] geser: looks ok [11:35] doko: then I'll forward the patch to Debian [11:35] doko: can you sponsor the merge? [11:41] ogra: tuxmath is uninstallable because its dependency ttf-sil-andika is in universe [11:41] geser: yes [11:41] ogra: (which in turn caues edubuntu-addon-meta uninstallability) [11:42] doko: thanks [11:42] pitti, hrm [11:44] intresting that i didnt have it i the mailed report ... [11:44] (from cdimage) [11:44] but probably it doesnt chek addon [11:44] *check [11:45] Hobbsee, Riddell: kaddressbook uninstallability (from kdeaddons) is caused by the kdepim shlibs wreckage and thus needs a rebuild; is this on your schedule? (maybe upload it now with a proper versioned build dep) [11:45] btw, is there any updates on getting Xubuntu's images onto the r.u.c? [11:45] Hobbsee, Riddell: kipi-plugins should sort itself out, AFAICS; that should cover Kubuntu uninstallability [11:51] pitti: ? [11:51] sarah@LongPointyStick:~% show kaddressbook | grep Source 10:51PM [11:51] Source: kdepim [11:51] Hobbsee: the kdeaddons packages picked up the >= 3.5.8 shlibs [11:52] Hobbsee: I mean kaddressbook-plugins, sorry [11:52] oh, the plugins [11:52] right, fixing [11:55] pitti: yes it is, along with kdesdk and kdebluetooth [11:55] kdesdk just fell out of http://people.ubuntu.com/~ubuntu-archive/testing/hardy_probs.html, so that should be good now [11:56] in fact it is starting to look quite manageable now :) [11:56] pitti: I will probably becoming your friend after alpha 1 about NBS :-) [11:56] * pitti hugs StevenK [11:57] * StevenK grins and hugs pitti back [11:57] pitti: it still needs to be built, seems like kdepim is in the archive now so please give back kdesdk and kdebluetooth [11:58] Riddell: done [12:01] tjaalton: ping [12:05] pitti: what's the best way to resolve the hplip FTBFS? fix temporarily the package or wait for a newer dpkg? http://launchpadlibrarian.net/10582485/buildlog_ubuntu-hardy-i386.hplip_2.7.10-3_FAILEDTOBUILD.txt.gz [12:07] geser: I saw it, but for now I think it is ok to wait for new package [12:07] Debian should fix the build dependency for dpkg, though [12:07] to avoid broken backports, etc. [12:08] Hobbsee: is it safe to request a give-back of kdesdk? [12:09] geser: I just did it [12:09] pitti: kdebluetooth too? [12:09] yes [12:18] Hobbsee: boing [12:19] pitti: Please give-back xemacs21. Thanks [12:20] geser: done [12:25] tjaalton: any idea on how to go about getting totem to work on hardy? [12:25] * Hobbsee hopes you know, else she can't watch any video on hardy [12:25] Hobbsee: starts but doesn't display anything? [12:26] tjaalton: starts, works for audio, but when i play video, it vanishes, and i get this: [12:26] here the playback doesn't seem to start [12:26] The program 'totem' received an X Window System error. [12:26] This probably reflects a bug in the program. [12:26] The error was 'BadAlloc (insufficient resources for operation)'. [12:26] (Details: serial 71 error_code 11 request_code 140 minor_code 19) [12:26] tjaalton: yeah, exactly [12:29] pitti: are NEW packages in Debian contrib auto-synced? [12:32] grrr. [12:32] sorry, i missed everything after what i last said. [12:32] 12:26 tjaalton: yeah, exactly [12:32] 12:29 pitti: are NEW packages in Debian contrib auto-synced? [12:32] 12:30 -!- Hobbsee [n=Hobbsee@ubuntu/member/hobbsee] has quit [Read error: 104 (Connection reset by peer)] [12:32] 12:30 -!- Hobbsee [n=Hobbsee@ubuntu/member/hobbsee] has joined #ubuntu-devel [12:32] Hobbsee: it seems to work on i965 at least [12:32] but not on my savage [12:32] maybe the problem is somewhere else [12:33] cjwatson: thanks [12:33] tjaalton: this is a 945GM. *shrug* [12:33] tjaalton: it used to work, too [12:33] as in, it'd crash X after a few minutes, but it would actually start playing [12:34] and i suspect it was with the most recent -intel upload [12:34] can some archive admin let through the split out ldm package ? [12:34] pitti, ? ^^ [12:35] sits in NEW [12:35] * ogra also wonders where his reciept for the ltsp upload is [12:39] Hobbsee: I'm afraid I don't have any ideas :/ You can try building the previous driver and test it, if you have the time [12:41] tjaalton: hm. [12:41] tjaalton: wrong answer :) [12:41] Hobbsee: obviously :) [12:43] tjaalton: bugger. cant seem to strace it / use gdb / antyhing debug-related on it, getting any useful output. [12:44] Hobbsee: does gstreamer-properties tests work for you? [12:45] tjaalton: ah ha! === dholbach_ is now known as dholbach [12:46] tjaalton: the no XV version of the first video test does, the X11/Xshm/Xv gives the usual error like i was getting from totem [12:47] Hobbsee: right, and since you use XAA with compiz, Xv probably shouldn't even work :) [12:48] I'm not sure though [12:48] tjaalton: heh. [12:48]