[00:03] lol [00:03] I'm not going to compile Songbird as it is already on GetDeb.net [00:03] thus, that packaging request should be deleted [00:04] Drk_Guy: GetDeb.net =/= Universe. [00:04] RAOF, Still, GetDeb.net is official cannonical site, why wouldn't you use it? [00:04] Wherever did you get that impression? [00:05] Yup [00:06] Should i compile VDrift? [00:06] That's not an answer to the question "Why do you think GetDeb.net is an official Canonical site"? [00:06] 1.5 hours of uploading [00:06] Real good [00:06] RAOF, Idk, it's kinda hunch [00:06] ≠ [00:07] I just rolled in my grave. [00:07] Hello motu [00:07] crimsun: :-) [00:07] Drk_Guy: GetDeb.net is very, very much not in anyway endorsed by Canonical, MOTU, or God. [00:07] hi null_vector [00:07] Still, VDrift uses scons, so i would have to edit rules, and i'm too lazy to do that [00:07] RAOF, God?, lawl [00:07] RainCT: got your email. thanks [00:07] yw :) [00:08] so, I'm really of now... good night [00:08] Drk_Guy: In fact, "highly recommended against" would be a more accurate portrayal of our position. [00:08] night [00:08] RAOF, So you suggest NOT using GetDeb, right? [00:08] RAOF, Why?, their DEB's are fine [00:08] lol [00:09] Drk_Guy: Absolutely. [00:09] Because their debs are _not_ fine. [00:09] now that I was starting to don't dislike getdeb, RAOF comes and awakes my distrust again :P [00:09] Or, at least, there's no way to distinguish between the bad and the good. [00:09] RAOF, Dirty checkinstalls? [00:09] Possibly. Also: breaking upgrades, etc. [00:11] RAOF, A GetDeb OpenArena deb made some updates to refuse being installed [00:11] Absolutely possible. [00:11] The question is: do you trust random uploaders with root access to your box? [00:11] RAOF, So, i'd better use PPA's/Repos/REVU [00:12] I don’t understand why the getdeb folks don’t just direct their effort to Ubuntu universe. [00:12] RAOF, I haven't heard of real bad things against GetDEb [00:12] RAOF, Except of your critiscism obviously [00:12] ion_: Because our quality standards impede the fresh flow of packaging. [00:12] :) [00:12] random ppa's are just as bad *g* [00:13] Drk_Guy: PPAs suffer the same problems as GetDeb. [00:13] Either way, you're giving root access to some guy on the internet :) [00:13] * Drk_Guy is hungry, going to something to eat === keylocker is now known as leleobhz [00:16] RAOF, Huh?, PPA's are dev_script'd [00:16] RAOF, You upload src, they compile [00:16] Indeed. [00:17] I publish a deb with 'rm -rf /' in the preinst. You install it, and it wipes your drive. [00:17] Woah [00:17] Real nice way of crapping your comp [00:17] You install packages as root. All the maintainer scripts run as root. [00:17] I know [00:18] * Drk_Guy is going to do a second wish list DEB, gimpshop [00:19] * Drk_Guy finds linux WAY EASIER than windows [00:23] RAOF, is editing rules hard? [00:23] They're just makefiles. [00:26] RAOF, Huh? [00:26] debian/rules is just a makefile. [00:26] RAOF, lol, should i use the one provided by dh_make? [00:26] You should probably read the packaging guide. [00:26] !packagingguide [00:26] The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports [00:27] RAOF, I read it dude [00:27] lol [00:27] I just have some soft spots to cover [00:31] So, starting with the rules file provided by dh_make isn't a bad idea. But you'll certainly need to edit it. [00:33] dh_make still doesn’t seem to know how to generate a debhelper 7 rules file. I recommend using either cdbs or dh 7 instead of the old dh rules. [00:34] Well, yes. Unless you'd like it to be backportable. [00:34] ion_, cdbs?, ok, i'll give it a try [00:34] raof: Well, dh 7 could be backported. ;-) [00:34] jdong would kill you :) [00:36] ion_, Ok, so dh_make, and then edit control to include cdbs as build-depend, right? [00:36] dh_make already adds cdbs as a build-dep. See dh_make --help [00:37] * Drk_Guy notices something weird, his ppa is http 404, and wine hasn't compiled after one hour of uplaoding [00:37] ion_, ok [00:48] This is weird, apt-cache show gimp won't show needed devel packages [00:49] Drk_Guy: why should it? [00:49] azeem, I need it for a control file [00:50] azeem, I mean, i want to make a gimpshop package, but i don't have the required devel libs names [00:50] right, but apt-cache show gimp displays the run-time dependencies, not the needed devel packages [00:50] Drk_Guy: try: apt-cache showsrc gimp [00:51] showsrc is for source packages and show build-deps [00:51] azeem, ok [00:52] stgraber, that worked, but, does the control file tells the package name, or the dir's name does that? [00:53] Better take a look at gimpshop’s own build-dependencies, from configure.{in,ac}, README etc. [00:53] does what? [00:53] in control you have first the part describing the source package then one section for each binary package [00:53] (not sure I understood the question though) [00:54] stgraber, i mean, what determines package name, dir or control file? [00:54] what is "dir"? [00:54] ion_, It has almost no documentation, and the dir i extracted shows up something very similar to gimp's source dir [00:54] besides, there's source package name and binary/binaries package name(s) [00:54] ion_, besides standard gimp docs, there's nothing else [00:55] The package name is determined from the control file for both source and binary packages. [00:55] Drk_Guy: maybe it's some gross hack that shouldn't get packaged then [00:55] azeem, gimpshop is a hack by itself, figure it out from the name [00:55] ok ion_ thanks [00:55] ion_, configure.in is a lil bit confusing ;) [00:56] if this is your first package, something as complicated as gimp is maybe too ambitious [00:57] azeem, It's not my first [00:57] azeem, I've succesfully done a wine package with 3DMark patch [00:57] As well as the tut's hello package ;)= [01:00] Should i use gimp's or gimpshop's changelog? [01:00] as upstream changelog? [01:02] I'm using gimpshop's included changelog [01:06] What should i put into copyright, taking in account someone hacked original gimp? [01:07] what copyright? [01:07] debian/copyright [01:07] the original debian/copyright, plus the copyright of the modifications I guess [01:08] It should contain all the copyright information for all the files in the package. [01:08] http://www.debian.org/doc/debian-policy/ch-source.html may help you. [01:10] Drk_Guy: Just as a side note, we generally discourage the packaging of duplicated code: if this is indeed just a hack from the same source (rather than an interface overlay using the same libgimp, etc.), it may be considered unsuitable from a maintenance viewpoint (-security, -updates, etc.) [01:11] persia, then what should i do? [01:11] Drk_Guy: Towards which goal? [01:12] persia, I mean, it is on a wish list, and i put it as "In progress" [01:12] what is "it"? [01:13] I mean, the bug is "in progress" [01:13] which bug? [01:13] Bug 114109 [01:13] Launchpad bug 114109 in ubuntu "[needs-packaging] GIMPShop" [Wishlist,In progress] https://launchpad.net/bugs/114109 [01:15] Drk_Guy: Well, you can research it a bit more: if it's full of duplicate code, you can set it back to "New" or "Confirmed" with a note saying that packaging is difficult due to duplicated code with gimp. If you really want it, and this is the case, you can work with upstream. If there isn't lots of duplicated code, then you ought just keep going. [01:15] well, just because something is on a somebody's wishlist doesn't mean it makes sense to add it to the Ubuntu archive [01:15] persia, http://plasticbugs.com/?page_id=294 affirms it's just a GUI hack, to make GIMP photoshop-ish [01:15] azeem: I disagree with that: I think everything on everyone's wishlist should be in the archive, although this takes a bit of work to get every upstream to play nice. [01:16] Drk_Guy: OK. How is it organised? If it's an overlay that needs the gimp libraries to build, it ought be fine. If it's a dirty hack, it needs coordination with upstream or to be left for later. [01:18] persia: it is just a different-GUI hack [01:18] I mean, the menus are re-organized [01:18] Drk_Guy: Is there a lot of duplicated code? [01:19] I don't really know, the folder reads gimp-2.2.11 [01:19] lol [01:19] Drk_Guy: Well, intrepid has gimp 2.4.6, so I doubt that the version of gimpshop you're investigating is compatible. [01:20] persia, the changelog is really distorted and it's way large to organize it [01:20] * persia marvels at gutsy-backports having 2.4.6 and hardy-backports having 2.4.5. [01:20] Drk_Guy: It sounds like you've found a hard one. Maybe pass on this for now, and pick something else? [01:21] persia, i think i'll set it back to New or confirmed [01:21] :P [01:32] persia, I'm trying to compile Mediainfo, but it has an sh to compile itself, should i edit control to run the sh? [01:34] control? [01:35] azeem, debian/control [01:35] how would debian/control run the sh? [01:36] azeem, idk, the SH is there [01:36] in the src's root [01:36] what? [01:36] and it has various subdirs [01:36] I neither what you mean with "idk", nor with "SH" [01:36] SH is a script, idk is i dont know [01:36] ;) [01:37] that doesn't answer my question [01:38] azeem, i have a dir with the src, but in that dir, there is a script to compile it, along with directories with other programs [01:38] ok [01:38] what does that have to do with debian/control? [01:39] I mean, normally, it is configure-make-make install [01:39] But this soft has an auto-compile script [01:40] Drk_Guy: debian/control only contains meta-data, it doesn't have much to do with how packages are built [01:40] lol, sorry, it's debian/rules [01:43] azeem ... [01:43] ? [01:43] Any ideas? [01:44] figure out which rules are mandated in debian/rules, and where calling that shell-script-to-build-things would fit [01:45] :( [01:48] Drk_Guy: In order to work that out, you'd want to be looking at the debian policy link I gave earlier. [01:48] lol [01:49] http://www.debian.org/doc/debian-policy/ch-source.html - the rules section lists all the mandatory targets of a debian/rules file, and what they're meant to do. [01:49] lol RAOF, i'm going to continue trying tomorrow [02:10] hi nxvl [02:14] hi! [02:15] Eh. getdeb.net: “© 2008 Canonical Ltd. Ubuntu and Canonical are registered trademarks of Canonical Ltd. [02:15] * Mirrors [02:15] Whoops. Well, anyway. [02:15] No wonder people think it’s blessed by Canonical. [02:17] Owch. [02:27] Thats bad. [02:35] It's always been that way. [02:35] persia: i send you and e-mail an hout ago or something, did you got it? [02:35] nxvl: Possibly. I don't check my email that frequently. [02:36] :D [02:37] nxvl: re: https://wiki.ubuntu.com/MOTU/Mentoring/NewModel ? [02:37] persia: i'm for your splitting-the-mentoring-program idea and added some bits on it [02:37] persia: yep, exactly [02:38] Nice write up. Best to work with the mentoring team on that, rather than me :) [02:38] persia: i'm part of the mentoring team [02:39] persia: i just wanted you to check it since you made the first suggestion [02:42] Heya gang [02:42] \o\ |o| /o/ [02:42] nxvl: My main interest was in shortening mentoring cycles. With the current model, a mentoring period can last over a year, which ties up a mentor for a fairly long time. Having a clear end (whether timeframe or target) helps with this. [02:43] got dammit i hate library changes between ubuntu and debian [02:43] ugh! [02:44] persia: yes, also we don't have any idea of how is it going between mentors and mentees [02:44] there is no monitoring on the process [02:45] also, as i write it on the wiki, senior contributor have more time and energy to help new people than old developers [02:45] hey bddebian! [02:45] Hi Hobbsee [02:50] nxvl: I don't think it's useful to say "MOTU aren't allowed to mentor completely new people". That said, depending on where each of us is on the path, anyone a few steps beyond is capable of being a great help. [02:51] persia: yes, that's true, i should clear that [02:52] persia: i tryed to meant that we should allow senior contributors to join the program [02:57] nxvl: I'm all in favour of allowing more people to help with things :) === protonchris_ is now known as protonchris [02:59] persia: yes, that's the idea i just didn't cleared it enought :D [03:57] * ScottK is still waiting for some evidence that the mentoring program is a net plus to the project. [04:02] Hm. Why is lintian complaining about old-fsf-address? [04:07] Because of... the old FSF address? :-) [04:07] Nope. [04:07] RAOF: Are you sure? Sometimes it's embedded somewhere. [04:07] Not in the file that lintian is complaining about. [04:08] Does the file have the address twice? I've seen that a couple times. [04:09] http://pastebin.com/f543c0963 [04:10] That is /usr/share/doc/$PACKAGE/copyright, the file lintian is complaining about. [04:11] Urgh. Typo; 20110-1301 != 20110-1307 [04:12] lintian isn't smart enough to trick you :) [04:14] No, but it's dumb enough to perplex me :) [04:34] is rainCT here ? [04:35] He's almost certainly sleeping right now. [04:35] hmmm, I need help about this: http://revu.tauware.de/details.py?package=webstrict [04:35] he says: The Maintainer field must have an @ubuntu.com address. [04:35] AnAnt: Which part? [04:36] I thought that having the maintainer field as a mailing list on launchpad was fine [04:36] It's supposed to be an ubuntu mailing list for teams. foo@lists.ubuntu.com. [04:37] but we don't have such an address [04:37] I thought there was a policy in place that helped avoid this sort of confusion: maybe ping jcastro if you can to help sort it (but not at this hour). [04:39] I suspect that if you fixed everything else, that might not be a blocker. [04:39] persia: btw, regarding swt-gtk, when I should I file the sync request ? after mozillateam uploads a new xulrunner package that contains xulrunner-dev ? [04:39] AnAnt: When the Debian package compiles and runs in Ubuntu with no further source modifications. [04:40] persia: that means I should wait for new xulrunner first [04:40] AnAnt: If that is the planned solution, yes. [04:41] persia: problem is that I dunno when they will do so, I asked them and they said: when there's a new upstream release [04:46] AnAnt: The other option is to prepare a changed source package for now. [04:47] AnAnt: What RainCT says about the general policy is correct. For your packages, I'm willing to forgo that rule (I have in the past). If you get to where that's the only thing stopping an upload, let me know. [04:50] ScottK: thanks [04:50] Anyone feel like reviewing http://revu.tauware.de/details.py?package=compcache-setup? Thanks. [04:51] Hm. How much is broken on PowerPC? [04:51] regarding webstrict, I think it is possible to put release tarballs on launchpad, in that case there is no reason for get-orig-source, nor mention the bzr in copyright (rather mention the launchpad project page maybe) [04:52] Or, rather, how surprised should I be that evolution-sharp FTBFS on PPC due to dependency problems? [04:52] how long must a package usually wait in REVU for a comment? [04:54] persia: the package is prepared & on REVU since a few days [04:55] AnAnt: If you can get a release file published, your get-orig-source becomes a trivial call to uscan. [04:55] persia: you mean , I still need a get-orig-source ? [04:55] RAOF: http://qa.ubuntuwire.com/ftbfs/ [04:55] coppro: An indeterminate period of time; once it's up, you probably want to poll in here about once a day. [04:56] AnAnt: I think every package should have a get-orig-source. Where there's an easy to access upstream, it's just a call to uscan --force-download. [04:56] coppro: It varies widely: between 5 minutes and 5 months. [04:56] RAOF: Or more specifically, less broken than anything else in ports. [04:57] Oh, _ninjas_. Please, gmcs, please don't segfault on the buildd. [04:58] persia: the swt-gtk package is prepared & on REVU since a few days [04:59] persia: that's reply to the other option you mentioned [05:01] ah, well then [05:01] i haven't really been doing the polling part [05:01] so, anyone up for REVUing? [05:06] freeflying, Hi! [05:06] foka: hey [05:07] foka: REVU is something like mentors.debian.net [05:07] freeflying: yup [05:07] freeflying, Cool. [05:08] coppro: It's a good idea to include a link to your package, too. [05:09] ok, http://revu.ubuntuwire.com/details.py?package=libmk4 [05:13] foka: You just joined revu-uploaders? [05:14] * persia syncs the keyring anyway, in case the answer is yes, and to be sure to get a turn [05:19] persia, Yes, I did some weeks ago, but this is the first time I begin looking into it. :-) [05:19] persia: I think foka also wanna to be MOTU :) [05:19] freeflying, in the future, maybe. :-) [05:20] freeflying, It is better to start from the beginning and do it step by step. :-) [05:21] persia: foka is a experienced DD, he just don't know where to start :) [05:25] foka: Welcome. We use REVU a little differently than mentors. [05:25] REVU is for NEW packages, but for update candidates (bugfixes, etc.) we prefer debdiffs attached to bugs, and subscribing the sponsors queue. [05:27] persia, Thank you for your warm welcome! [05:29] persia, Yes, I intend to upload two new packages for Ubuntu (which are not in Debian yet). One is "sunpinyin", a CDDL/LGPL smart Chinese pinyin input method engine by Sun Microsystems, packaged for Debian by "Tchaikov" (Kov Chai) and which I sponsored uploaded for Debian, currently in the NEW queue. [05:29] persia, Another that I am packaging is called novel-pinyin by a local Chinese Novell developer and is packaged for OpenSUSE 11. [05:30] foka: Do you think they'll in NEW for long? It's often easier to just sync once they get through Debian NEW. On the other hand, if you want more time for testing/integration, REVU works, but it often takes at least as long as Debian NEW. [05:30] persia: those two packages have some issue, maybe rejected by ftp-master [05:30] freeflying, Not yet rejected. :-) [05:31] freeflying, Still being discussed and remedied. [05:31] freeflying: Even more likely to get rejected from REVU then :) [05:31] foka: yes, I mean maybe [05:31] persia: :) [05:32] persia, Brief background info: the issue relates to the "statistical data" generated by gathering about 150MB of Chinese text from on-line website. [05:33] At runtime? At build-time? At packaging-time? [05:33] persia, The resulting statistical data is CDDL/LGPL'ed. [05:33] persia, Sun provides the statistical data in lm_sc.t3g.{i386,sparc}. [05:34] persia, Sun provides the statistical data in the file data/lm_sc.t3g.{i386,sparc}. [05:34] persia, It is not gathered/built/analysed at runtime or build-time. [05:34] Oh, that sounds reasonable, although I'm not an archive-admin :) [05:36] persia, So yes, Debian FTP master was asking further information about these files (as well as the pinyin phrase data, which thankfully we do have the source, elsewhere, just not packaged yet). Kov Chai (the packager) replied a few days ago, and I added my take earlier today, now awaiting reply. :-) [05:37] persia, So, in most cases, you would prefer packages to be in Debian first, and then sync with Ubuntu, except for Ubuntu-specific packages? [05:38] Ideally, yes. [05:38] Note that there are about 1000 packages currently in Ubuntu that aren't in Debian, in part because nobody familiar with Debian processes has tried to get them in. [05:39] It's always better when a package is in Debian, because that means that all Debian derivatives can use the same package, and there's more sharing of patches. [05:39] persia, I see. Maybe I can help do that, integrating these packages back to Debian. :-) (is that called Utnubu?) [05:40] It also means there is a specific maintainer, which makes it easier for upstream to contact someone, and improves cooperation between upstream and the distributions. [05:40] foka: Utnubu could definitely use some help. I've seen very little activity from that team recently. [05:41] On the other hand, unless someone can be found to be the maintainer, pushing it into Debian to sit in the hands of Debian QA isn't ideal. [05:41] persia, Hmm... very true. [05:41] For novell-pinyin and sunpinyin, I don't think this issue exists, which is why I think Debian is the right place. [05:41] foka: another issue, ubuntu has moblin support, the data of sunpinyin is a bit big for them [05:42] freeflying: Well, some builds have moblin support. We also have some very large packages. It depends on the target environment for each flavour. [05:44] persia: the you n will suggest not to build sunpinyin for lpia? :) [05:44] freeflying: No, I suggest building it for all architectures. I wouldn't expect the ubuntu-mobile seed to use it. [05:45] Or with large data, likely better to have arch: any for the data anyway. [05:45] persia: the problem is sunpinyin is an IM engine of scim, it performs better than scim-pinyin [05:46] freeflying: Last I checked, there was no SCIM in ubuntu-mobile at all (or at least not exposed in the UI). I might be mistaken, as I didn't try an installation with an appropriate locale. [05:46] I still think it's worth doing for lpia: there's plenty of press about non-mobile devices using those chips. [05:47] persia: thanks [05:53] ScottK: around? [05:55] Yes. [05:57] nxvl: ^^^ [05:57] ScottK: i take a look today at the mysql-gui-tools issue [05:58] ScottK: it's a library problem [05:58] ScottK: i have already send seb128 a mail for discussing it [05:58] OK. Great. [05:59] This is what I'd expect a MOTU to do, is pursue the problem to the end and not leave the package FTBFS. [05:59] it's a problem with the migration from libgail to libgtk2.0-0 [06:02] persia, I agree. :-) Besides, it is large, but not that large. Probably about 40MB. [06:35] good morning [06:35] good morning [06:35] dholbach: i have send you an e-mail [06:35] dholbach: about the mentoring programm [06:35] program* [06:36] hi nxvl [06:36] nxvl: I noticed :) [06:37] D: [06:37] :D [06:40] Morning Nicholas, Daniel. Interesting topic, and came to my mind to ask, are there guidelines for mentoring programme, or are they usually/always just individual deals between the mentor and the actor? [06:41] StevenK: ping [06:41] nxvl: ? [06:41] AstralJava: https://wiki.ubuntu.com/MOTU/Mentoring [06:41] StevenK: how is the libiw patch applied in netapplet? [06:42] magic [06:42] Hobbsee: yeah, it seems it does [06:42] nxvl: I'm going to need a little more information than that. :-) [06:42] AstralJava: is your patch [06:42] dholbach: Thanks. :) [06:43] i can't build it and it seems to be a lib related problem [06:43] Yeah I sort of figured as much, but was wondering whether any stricter guidelines had been put in place. [06:44] AstralJava: nope [06:44] AstralJava: i'm trying to write something up [06:45] nxvl: Oh that's nice. I should subscribe to the page dholbach linked to, or is it going on someplace else? [06:46] dholbach: btw, sorry about the avalanche of mails about emgent :P [06:46] AstralJava: i use to write thing on a local file, then discuss it, and then upload it [06:46] :D [06:47] AstralJava: but if you want you can ping me from time to time to see if i've got something [06:47] AstralJava: because now we are working on something else, which may change a little bit how things work [06:47] AstralJava: so i will wait until we decide about it [06:47] nxvl: Not a prob. Chatting about it here is fun, but to catch the end result, it's going into the wiki, right? [06:48] yup [06:48] someday [06:48] :D === MenschenFleisch is now known as soylentgrun [06:49] nxvl: And yes, I'd like to be part of the process, if possible. I've got experience from a similar phenomenon at real work situations. Hence the interest in this too. === soylentgrun is now known as SoylentGrun [06:50] nxvl: ...and I've already got a great mentor too, with whom I can hopefully talk more in depth about it. [06:50] AstralJava: Then mentoring program itself is optional. [06:50] There are also people here who will help most anyone when they have time. [06:50] ScottK: So I understand. I still think it won't hurt in developing it. :) [06:51] ScottK: And yes, I've noted that hanging around here somewhat before getting a mentor, can provide all the mentioned information. [06:51] People are so friendly and open around here. [06:52] * ScottK worries that if people only talk to their mentor, they will get a narrow view. [06:52] But it would be interesting to see whether it could be taken onto a new level. [06:52] * ScottK also worries it's almost 2AM here. [06:52] Good night. [06:52] I understand that, but not willing to go down that direction. [06:52] G'night. [06:52] ScottK: guidelines, as i'm proposing will be just a document to check and follow if you feel like to, if not, there is no problem [06:53] ScottK: i don't want to write a policy, just suggestions on how can it be [06:55] * nxvl goes to bed too [06:55] (but with the laptop :P) [06:55] Sleep tight, but not too tight with the machine. :) [06:55] heh [06:55] nxvl, the ports aren't for direct human interfacing [06:55] just moving from working place [06:55] not going to sleep [06:55] :D [06:56] SoylentGrun: huh? [06:56] You _don't_ wanna get into that. Trust me. :) [06:56] Hi all [06:56] hi! [06:57] Hello. [06:59] * nxvl is about to kill seb :D [07:02] StevenK: i'm talking about your patch [07:02] StevenK: on netapplet 1.0.8-1ubuntu3 [07:03] nxvl: I'd have to checkl [07:03] s/$check$l/\1/ [07:08] Ew. I hate that RE dialect. :-) [07:08] RE are kewl [07:16] i'm going to bed [07:17] dholbach: after reviewing the wiki page please send me your comments/suggestions please [07:17] bye all, read you later [07:19] nxvl: I'm not sure I'll get to it [07:19] I have a lot of stuff to do today and will clear out to holidays later today [07:19] but I'll try [07:31] Hows about this for fun: pbuilder build evolution-sharp results in mcs segfaulting during the build; pbuilder-login ; aptitude install --without-recomments pbuilder ; /usr/lib/pbuilder/pbuilder-satisfydepends ; dpkg-buildpackage works. [07:31] Well, it’s not as if software is deterministic. [07:32] RAOF: Woot [07:32] Oh, and I think this is amd64 specific. [07:32] Yup; builds everywhere but AMD64. [08:02] i'm curious why there is no replacement for gstreamer0.10-gl in hardy [08:03] I see here: https://bugs.launchpad.net/debian/+source/gstreamer0.10/+bug/227770 [08:03] Launchpad bug 227770 in gstreamer0.10 "glstreamer0.10-gl disapeared in hardy" [Wishlist,Triaged] [08:03] it says Drop the OpenGL plugin. This will go to a new source package named gst-plugins-gl once we have mesa >= 7.1 somewhere. [08:03] but what about for hardy? I grabbed this package here: https://launchpad.net/ubuntu/hardy/i386/gstreamer0.10-gl [08:04] even though it's status says deleted. installed it manually. set it to glimagesink and the test is ok but then seg faults [08:04] anyway even with this package installed i can't get brightness working in totem-gstreamer [08:07] Well, we'll probably get something in Intrepid, given we've now got mesa 7.1. [08:08] As for hardy, that plugin probably won't be making a re-appearance. It was never particularly stable in my experience, anyway. [08:10] yeah it's not working well. jsut a shame I can't use totem then [08:10] as nvidia dropped full xv long time ago [08:10] can't adjust brightness contrast etc without opengl playback [08:10] i assume this must affect a lot of users [08:11] I wouldn't think so. People needed to go out of their way to use that plugin. [08:11] Also, in what way do nvidia not support Xv? [08:12] no i know people wouldn't go out of their way for that plugin. I mean there are lots of nvidia users, and I assume a lot of people would like to be able to adjust their video brightness [08:12] as of geforce 6 series and up there is no full xv [08:12] you can't adjust brightness contrast etc [08:12] Hm... [08:12]