[00:05] txwikinger: You still around? [00:05] txwikinger: I've run into this exact issue before. [00:06] yes ScottK [00:06] Does the package include the full text of any of the licenses that apply (there are 3)? [00:06] No.. only a reference to perl [00:07] You will have to repack the tarball to include a copy of the license. [00:07] I'll get you some references. [00:07] Also, "Same terms as Perl" covers at least 3 licenses: [00:07] Perl Artistic License [00:07] GPL v2 [00:07] GPL v1 [00:07] I think it is GPL and Perl Artistic [00:08] If it's "Same as Perl" then it's both GPL v1 and v2. [00:08] This package is free software and is provided "as is" without express [00:08] or implied warranty. You can redistribute it and/or modify it under [00:08] the same terms as Perl itself. [00:08] All three will need to be covered in debian/copyright. [00:08] Yes. [00:08] that is in the readme file [00:08] At least one needs to be in the tarball, so you have to repack. [00:09] I have created the debian/copyright [00:09] With all three licenses discussed? [00:09] and there given the reference to the folders in which those licenses are in ubuntu/debian distro [00:09] I think just gpl and perl artistic [00:10] not explicitly gpl v1 and v2 [00:10] Yes. Perl is explicitly v1 and v2. [00:10] https://launchpad.net/ubuntu/feisty/+source/libnet-dns-resolver-programmable-perl/0.002.2-0ubuntu1 is a package I did. [00:10] and I copied the COPYING file from perl to the package top directory [00:10] Some of the rules on how you document repacking have changed a bit, so you'll want to read up on that. [00:11] ok.. I haven't repackaged the orig tarball I think [00:11] http://www.debian.org/doc/packaging-manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz talks about how you repack the tarball [00:11] The package I showed you above can mostly be used as a reference. [00:12] for what has to go in. [00:12] right [00:15] just because upstream explicitly makes something available under GPLv1 (in addition to GPLv2) doesn't mean redistributors have to extend the same license to users [00:16] Thanks ScottK [00:17] slangasek: True, but unless there's a reason not to, I think packagers should preserve upstream's preferences in licensing. [00:18] ScottK: we can't limit upstream's preference, but we can patch it with something not compatible with upstreams entire preferences [00:18] txwikinger: More info here: https://wiki.ubuntu.com/PackagingGuide/Basic?highlight=%28get-orig-source%29#head-4bb01b3c07548aaf98e85ac7eb7983e632f8eb38 - particularly on making a get-orig-source rule. [00:19] lifeless: I agree that we can. I also think that we shouldn't without a good reason. [00:19] I think not having to hunt down the text of the ancient GPLv1 is a good enough reason, myself :) [00:19] * ScottK was just typing that I thought it not. Google is easy enough, but OK. [00:25] ScottK: ok, more concretely, the GPLv1 is old enough that I don't know it has ever even been reviewed by a body such as debian-legal to check whether it imposes unreasonable obligations on distributors such as Debian and Ubuntu [00:26] That's definitely more concrete, although Ubuntu doesn't have such a body, so it'd be a better Debian point than an Ubuntu one. [00:26] well, I'm saying that no one has done such a review, and I wouldn't want to be the one packaging something like that without reading the license carefully [00:26] * ScottK has wondered why Perl is still distributed under GPL v1. [00:27] That certainly makes sense. [00:27] ScottK: maybe they can't get all authors to agree to the change to GPL v2 or is all copyright transfered? [00:28] It's GPL v1 and 2, so they can drop 1 if they feel like it. [00:28] ScottK: Perl is special, being GPLv2 or Artistic [00:28] StevenK: Except it's really GPLv1, GPLv2, or Artistic, so it's even more special than that. [00:29] pitti or Mithrandir rejected my first new package because of this. === zakame__ is now known as zakame [00:30] wtfpl ftw:) [00:30] ScottK: Is it "GPL v1 or v2", or "GPL v1 or later"? In other words, is it GPL v3 compatible? [00:30] * ScottK would need to look. Last time I was required to care, there wasn't a v3 yet. [00:32] minghua: [00:32] the GNU General Public License as published by the Free [00:32] Software Foundation; either version 1, or (at your option) any [00:32] later version, or [00:32] txwikinger: thats the licence, not the grant. [00:32] txwikinger: you have to have a grant statement to decide what licence a package is under [00:34] lifeless: I have no idea what this means [00:34] txwikinger: It means you were quoting from the GPL, not the bit where Perl says how it's licensed [00:34] g'night all [00:35] ScottK: The /usr/share/doc/perl-base/copyright says GPL v1 or later. [00:35] * minghua can't find anything definitive on perl.org though. [00:35] Then it's be v3 too I guess. [00:35] ScottK: I was quoting from perl's readme file which declares under which terms you are allowed to redistribute [00:35] That's consistent with my recollection from January [00:36] txwikinger: The part you were quoting from is part of the GPL though. [00:36] ScottK: True it is inside the GPL also [00:37] jdong, when did it ever? i didn't recall making such a change, and looking through bzr history on debian/control, i don't see any dependencies directly on it [00:40] actually hmm. can't remove it without removing mplayer [00:40] something about mplayer wants to keep it [00:40] some other dependency [00:40] superm1: I could've sworn... [00:40] Which dependency? [00:40] i'm not sure. [00:40] Which package are you trying to remove? [00:40] superm1: http://packages.ubuntu.com/hardy/graphics/mplayer [00:40] libmp4v2-0 [00:40] superm1: on [powerpc] there's a binary dep on mp4v2 [00:40] oh interesting. [00:40] Fujitsu: not trying to remove, chasing after an API migration [00:41] superm1: could be a shlibdeps phenomenon? [00:41] well if its only on ppc, then why is it sticking around for i386? [00:41] where phenomenon is polite speak for bug? [00:41] haha [00:43] its a dependency of libfaac0 [00:43] which is a dependency of mplayer [00:43] superm1: oh so it gets pulled in anyway [00:43] yeah [00:44] superm1: lovely, well faac is definitely going to be hit by the mpeg4ip transmition [00:44] what transition? [00:44] superm1: mp4v2 will be provided by mpeg4ip instead of faad [00:44] 172863. [00:44] yeah what crimsun said :) [00:44] 683. [00:45] bug 172863 [00:45] other one. [00:45] bug 172683 [00:45] Launchpad bug 172683 in gtkpod-aac "libmp4v2 API migration" [Undecided,Confirmed] https://launchpad.net/bugs/172683 [00:45] bug 683 [00:45] o [00:46] superm1: with regards to mplayer, I think if we deal with faac mplayer should remain unaffected [00:46] (famous last words) [00:46] well except on powerpc i guess? [00:46] superm1: I don't understand what the difference with ppc is? [00:46] i didn't think there was a [powerpc] build depend even though [00:46] that doesn't seem right [00:46] superm1: I didn't see it in my Sources.gz grep [00:46] so p.u.c is on crack? [00:47] superm1, I was looking for you in x-devel [00:48] Maintainer: Ubuntu MOTU Developers [00:48] Original-Maintainer: Ubuntu MOTU Media Team [00:48] ^^ is that _really_ necessary? :) [00:48] (feisty) [00:48] jdong: Per the spec, yes. [00:48] Since tauware.de is not in ubuntu.com [00:49] well technicality wise, I guess [00:49] debuild gets cranky, so it's best do mangle it. [00:49] s/do/to [00:49] May as well. [00:49] * jdong wonders why motumedia doesn't get a @lists.ubuntu.com? [00:50] jdong: That takes a loooong time. [00:50] ah, lovely [00:50] (not to mention prior to USD-Boston, there was some discussion of dissolving the team) [00:50] UDS* [00:50] crimsun: That's true. [00:50] ah [00:50] crimsun! [00:50] Fujitsu! [00:51] * jdong uploads a rebuild of faac to motumedia-ppa and hopes nothing explodes... again. [00:51] * Fujitsu explodes. [00:51] Fujitsu: Save the exploding for the CC meeting tomorrow. [00:51] what's going down there? [00:52] A certain somebody who tends to be somewhat unpopular in these parts has listed himself as a membership candidate. [00:52] Nyes... [00:52] * Fujitsu isn't amused. [00:52] * jdong looks at the list and guesses... [00:52] * Fujitsu wonders if he can convince a sysadmin to make him disappear from that list. [00:53] Fujitsu: It'll be more fun to have a public fight about it. [00:53] ScottK: I guess. [00:53] Actually, I think more necessary. [00:53] Ew, 3am tomorrow... [00:53] I'll have to watch, though. [00:53] I haven't been to a CC meeting in aages. [00:53] sounds like I've missed a thoroughly rousing devel cycle ;) [00:54] crimsun: That you have. [00:54] * ajmitch wonders who this certain someone is? [00:54] ajmitch: I'm sure you can guess... [00:54] * minghua didn't know that he is not a member yet. [00:54] ajmitch shouldn't have much trouble figuring it out. [00:54] nope, i can't [00:55] * jdong feels out of the loop [00:55] at least I don't see any recent changes to the CC agenda [00:55] When is the next CC? [00:55] He's been on the list for a whlie. It's just been quite some time since the last meeting. [00:55] it must have been [00:55] I guess that means look towards the top [00:55] about 6 weeks or so since the last one? [00:55] somerville32: ~20 hours [00:56] 5AM local time [00:56] Are you guys talking about kmos? [00:56] Or less. [00:56] who is representing him? [00:56] * ajmitch shrugs [00:56] somerville32: What gives you that idea? [00:56] somerville32: None of us said that. [00:56] just say it :P [00:56] * Fujitsu invokes the CoC. [00:57] ok while we are paying keep-jdong-in-suspense, anyone want to comment on pulling faac from debian-multimedia again? [00:57] it looks like trying a merge from d-m will be easier than patching our old-ish version [00:57] jdong: I'd so go for it. Your track record on such things is reasonably good. [00:57] Wow, https://launchpad.net/~ubuntumembers/+members really has a long applicant list. [00:58] * somerville32 thought kmos would look different. [00:58] ScottK: I will start experimenting and try to poke/ambush slomo the next time he comes on just in case this is a bad idea (tm) [00:58] I should apply to be a member [00:58] I think i'm only in the team indirectly [01:00] teehee, expired on 2007-08-16 === rob1 is now known as rob [01:02] ah no, I am still a direct member [01:02] must have only been MOTU I expired from [01:02] * Fujitsu wonders if GetDeb people can be automatically excluded. [01:03] Hobbsee! [01:03] there she is [01:03] Hi Hobbsee. [01:03] Oh, my membership will expire soon, it seems. [01:03] Fujitsu: no, they should be given a chance, at least [01:04] ajmitch: Can automatix people be auto-excluded then? :-P [01:04] minghua: Do you have some time to explain how GTK input methods work? [01:04] minghua: noone can, really :) [01:04] hehe I'm ex-automatix :) [01:04] heya! [01:04] I know :) [01:04] StevenK: Sure. Glad to see you are interested in it. [01:05] minghua: I'm trying to get Hildon Input Method working, and I'm getting nowhere slowly. [01:05] StevenK: I assume you understand the general idea of input methods? [01:05] and it's taken many long years of rehabilitation [01:05] ajmitch: lol ;-) [01:06] minghua: I understand it in the mobile case - click on a text widget and get the input method to pop up a keyboard so you can type [01:06] StevenK: Oh. Then you probably don't. [01:07] StevenK: The point of an IM is to convert keystroke sequences to character/string. [01:07] StevenK: For some languages keymaps can do this, for the East Asian languages keymaps are not powerful enough. [01:07] * StevenK nods [01:09] * jdong looks at slomo's comment on bug 80825 [01:09] Launchpad bug 80825 in faac "Version bump to 1.25 request" [Undecided,Confirmed] https://launchpad.net/bugs/80825 [01:09] StevenK: So first there was X input method (XIM), which is some part (I don't know which) in X that take the keyboard input from X server, send it to some external conversion program, get the character/string back, and send that to X client. [01:09] StevenK: XIM has many limitations, and is generally hard to code for X client programmers, and error-prone. [01:09] hmm better get his opinion on this -- he felt strongly enough 1.5yrs ago to package from scratch and diverge from marillat [01:10] minghua: Which lead to SCIM, I'm guessing [01:11] StevenK: So GTK+ redesigned/reimplemented the input method stack, and have something (again, I don't know what) in the GTK+ system which handles the conversion. [01:11] StevenK: Not yet. :-) [01:11] Hobbsee: Did you see the message I left for LongPointyStick about the CC meeting tomorrow. [01:12] is breezy (5.10) long past being supported? [01:12] StevenK: This is commonly called GTK IM, as a well known environment variable to control this part of GTK+ is GTK_IM_MODULE. [01:12] Breezy is long dead, yes [01:12] :( [01:12] StevenK: So obviously most existent conversion programs works for XIM, and GTK+ don't want to throw them away. [01:12] minghua: I knew that bit from my web searching yesterday [01:12] so conflicts/replaces on a package that has been removed from the ubuntu repositories since breezy no longer needs to be included as a conflict/replace in hardy? [01:12] * effie_jayx remember when breezy was hype [01:13] s/remember/remembers [01:13] breezy was the roughest Ubuntu release I've used [01:13] LordKow: correct. [01:13] k one step closer to being able to sync [01:13] StevenK: Therefore GTK+ can defer to XIM to handle the conversion, which is what GTK_IM_MODULE=xim mean. [01:13] LordKow: If they needed for an upgrade *to* Dapper, they can go; if they're needed for an upgrade *from* Dapper, they stay. [01:13] minghua: Yup. [01:14] StevenK, considering the conflict/replace in question is not in dapper they should be safe to remove [01:15] StevenK: My understanding is that different modules of the GTK IMs are quite independent. You can see the files in /usr/lib/gtk-2.0/2.10.0/immodules/, and the module (essentially the conversion method) in the right click menu's "Input Methods". [01:15] ScottK: not yet, but i will [01:15] minghua: Right. [01:15] StevenK: Again, this is controlled by the GTK_IM_MODULE variable. [01:16] StevenK: This is basically about IM. I take it that you are interested in SCIM as well? [01:16] minghua: Not particularly, I'm interested in how to debug IM because I can't get Hildon Input Method working [01:17] StevenK: What input method is Hildon using? I'm not familiar with it at all. [01:17] presumably the "hildon" one :) [01:17] Is it a special GTK IM module? [01:17] It's own, http://live.gnome.org/Hildon/HildonInputMethod [01:17] Actually, the input method is called "hildon-input-method" [01:21] StevenK: Does hildon-IM run on vanilla GTK now? [01:21] I've not been able to determine that. [01:22] Although I suspect the answer is "No" since I can't get it working [01:22] It looks like an GTK IM module to me. Is there anything in /usr/lib/gtk-2.0/2.10.0/immodules/ that looks like hildon? [01:22] The problem is, Debian/Ubuntu's GTK IM stack is not vanilla either... [01:23] Hold on, just booting the device [01:23] minghua: in what sense, and why? [01:24] StevenK: If you've been following http://live.gnome.org/Hildon/HildonInputMethod/Building, I can seen something would not work... [01:24] slangasek: Let me dig up the reference for you. [01:24] minghua: Oh? [01:25] slangasek, StevenK: http://lists.debian.org/debian-gtk-gnome/2006/10/msg00045.html [01:27] slangasek, StevenK: I can't find a better reference, so I'll elaborate a bit more: [01:28] GTK uses /etc/gtk-2.0/gtk.immodules to register all the available IMs. [01:29] So individual IMs need to update that file after they are installed/uninstalled. [01:29] You can see it would cause some problem as it's a conffile. [01:29] Yeah [01:30] Just throwing hildon-input-method into /etc/gtk-2.0/gtk.immodules has made it hit the list of input methods. [01:30] So in Debian after 2.10 it is changed to use individual files in /usr/lib/gtk-2.0/2.10.0/immodule-files.d/ instead. [01:31] And /etc/gtk-2.0/gtk.immodules become useless. [01:31] dh_gtkmodules ah [01:31] StevenK: That's why I say following the Hildon upstream instructions would not work. [01:31] minghua: It certainly helped [01:31] This change is not in GTK+ upstream AFAIK. [01:32] slangasek, StevenK: Debian bug 419314 is an example how input method packages should adapt to this change. [01:32] Debian bug 419314 in scim-gtk2-immodule "Switch to dh_gtkmodules for the gtk 2.10 transition" [Serious,Fixed] http://bugs.debian.org/419314 [01:33] Loïc Minier should know better than I do, as that change is his. [01:33] And I think he is also an MOTU now? [01:34] I can talk to Loïc about it [01:34] Now, how do I set a gconf key [01:35] gconftool if you are hardcore, gconf-editor is a saner alternative. [01:35] From a command line, hopefully [01:35] StevenK's hardcore! [01:36] StevenK: gconftool-2, actually it seems, as gconftool is a symlink to it. It's command-line. [01:39] Right, got it. [01:42] are there any policies with regard to putting Homepage: in a package description? [01:43] LordKow: I was last told to start using the Homepage: tag (paraphrasing) though Homepage: is a valid way on its way to being deprecated [01:43] What? Homepage as a field has only just started existing [01:44] I think he meant "using Homepage: foo in the package description", not the shiny new dpkg field. [01:44] okay, this particular package has the Homepage set properly but (in regards to homepage) we deviated from debian by adding Homepage: to the package descriptions to [01:44] i take it I can safely remove the homepage link from the description? [01:44] Well, there's a nice easy divergence to drop :) [01:46] If those two URLs are the same. :-) [01:46] StevenK: In what context do you need to set a gconf key? [01:46] StevenK: Is it just for your own use, or within a package? [01:46] TheMuso: Within a package [01:47] * StevenK has figured it out, too [01:47] StevenK: Are you aware of the gconf-defaults mechanism available? [01:50] TheMuso: Nope. Can you spit out more information? [01:51] StevenK: Sure. What you can do is create a file called debian/packagename.gconf-defaults, and you can list the keys you want to set in it like this: [01:51] /path/to/gconf/key value [01:51] /path/to/other/key false [01:51] etc [01:52] Then, in debian/rules, you run dh_gonfdefaults with a priority number in the binary stage of the build, whic copies the file to /usr/share/gconf/defaults, and does postinst/prerm magic to run update-gconf-defaults. [01:52] are there any limitations to merges when the merge involves new packages added by debian? [01:52] Hope that makes sense [01:52] sorry, dh_gconf [01:52] TheMuso: Sure it does, I'll add dh_gconf as something to look at. :-) [01:54] LordKow: You mean the same source package now builds new binary packages? [01:54] yes [01:55] it adds a new package (but doesnt rename or remove any others) [01:56] I can't think of anything special at the moment. [01:56] Probably checking that there is not package name collision. [01:56] k. it was added by debian but I will still mention it in the changes for future reference [01:57] minghua, yep gcrystal does not exist in any of our repos right now [01:57] LordKow: Sounds good. [02:06] hmm convention question: [02:07] If I work on a package by testing in a PPA and go through ~ppa1 -> ~ppa3, and then am ready to upload to Ubuntu, should I (A) Consolidate the ~ppa* changelog entries into one final entry, or (2) Preserve that changelog history and use -v to make them all show up in .changes? [02:07] err I just used (A) and (2) [02:08] * Fujitsu would go with A. [02:09] I'm leaning towards A, too [02:09] expecially since (2) exposes more embarassing details of my incompetence than I'd like to discluse ;-) [02:12] * Fujitsu is glad that the .changes are stored for eternity for all to see. [02:12] You can't hide them forever! [02:12] lol [02:13] hmm [02:13] possible attack vulnerability with reused binaries there [02:13] lifeless: The .changes? [02:14] Where are the binaries reused? [02:15] I've mailed the soyuz folk. [02:15] If I'm wrong I'll explain it to you tomorrow when they correct me. [02:16] If I'm right, I'd rather not say more just yet. [02:19] OooOoo... [02:20] dun dun dunnnnnnn [02:21] * Fujitsu notes there is another much, much worse vulnerability. [02:22] Really? Do share. [02:22] you don't want to know. [02:22] You really don't want to know. [02:22] * ajmitch really does [02:23] It is a most nasty one. [02:23] * somerville32 always wants to know. [02:27] I want to know [02:27] So I can exploit it and find the hidden GNOME 3.0 packages [02:28] I know seb128 has been keeping them from me [02:35] nice, marillat's faac builds and as does an unleashed gtkpod-aac.... now the question is, did I just start another revdep chain with faac? [02:35] (almost certainly a yes... :-/) [02:37] Heya gang [02:37] heya bddebian [02:38] Hi imbrandon [02:44] jdong: never fear the rdep chain. Fear the morning after. [02:44] :) [02:44] (yes, I know you're procrastinating.) [02:44] heh, heya crimsun [02:45] crimsun: shhhhhh ;-) [02:45] heya bddebian [02:45] when's our first tribe? [02:45] or flock [02:45] or gaggle [02:46] what do herons come in? [02:46] jdong: "Alpha" [02:46] I thought we abandoned that naming system for hardy. [02:46] other than crates of refrigerated styrofoam trays [02:46] minghua: ah I didn't get that memo then [02:46] ok, "Alpha" it is. [02:46] And the answer is now, approximately. [02:46] when is the freezing fun scheduled? [02:46] ah [02:46] ok [02:47] jdong, no freeze [02:47] no freeze [02:47] somerville32: I know but I'd rather not put anything in that MIGHT break parts of the multimedia stack [02:47] jdong: A self-imposed freeze. [02:47] in ways that would affect "users" (read: insane testers :D) [02:47] jdong: your a MOTU now you really should read more email :) [02:47] * RAOF hunts the ubuntu-devel message about this... [02:47] burn [02:47] imbrandon: it's been a hellish week after getting back from thanksgiving... [02:47] * somerville32 hugs jdong [02:47] RAOF: Freeze! [02:47] RAOF: Okay, go on. [02:47] heheh i totaly understand, i was just messing with ya [02:47] :-P [02:47] imbrandon: I will catch up on the 300-whatnot messages after friday :) [02:48] * somerville32 has 5k [02:48] somerville32: I actually read mine normally ;-) [02:48] jdong, me too :P I just got so much [02:48] And no spam :( [02:48] * somerville32 wishes he could get spam he could just easily delete. [02:48] jdong: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-November/000351.html [02:48] * jdong set up squirrelmail just to get mail on his iPod Touch [02:48] Note to self: Patches work better if you list them in 00list [02:49] somerville32: I could sub you to a few LP teams as the bug contact... [02:49] * StevenK does the whole dance again [02:49] crimsun, sub? [02:49] StevenK: hehe [02:49] somerville32: add/subscribe [02:49] RAOF: thanks :) [02:50] crimsun, I already get enough bug mail :P [02:50] StevenK: ah, yes, that was infinite loop #2 of mpeg4ip [03:20] jdong, why not use apple mail on it? [03:20] jdong, apple mail works really well actually on mine [03:20] jdong, the only problem is that google's imap doesn't refresh all my labels [03:22] is there a python function to escape/convert a html strings from like < to < and "e; etc ? [03:24] not as part of the standard library, ttbomk [03:24] hrm [03:24] imbrandon: i don't know any, but you can write one [03:24] nxvl: and forget one of the chars that need escaping and cause XSS vulns ;) [03:25] i'm barely past page one on dive into python :) i dont think writing my own is worth it [03:25] imbrandon: I think not as it's come up as a problem with REVU comments. [03:25] at this point [03:25] Um, sure there is. [03:25] StevenK: called? [03:25] It's in urllib, I think [03:25] i'm already importing urllib so i'll see [03:25] * imbrandon looks [03:26] http://docs.python.org/lib/node563.html#l2h-3814 [03:26] cgi.escape() [03:27] how is a sync done? [03:27] only download the debian package and upload it? [03:28] nxvl: A sync is done by the archive admins [03:29] StevenK: so if one packages is marked as merge and it need a sync y only ask for it on #ubuntu-devel? [03:30] superm1: haven't bothered to jailbreak/EULA-rape mine yet [03:31] superm1: gonna use it the way apple intended (tm or else) for a few weeks before hacking it [03:31] nxvl: no you file a sync request bug [03:31] following the guidelines [03:31] https://wiki.ubuntu.com/SyncRequestProcess [03:33] thnx [03:33] alright given the amount of deviation required for this merge in debian/control i give this src package ~90% chance of FTBFS-ing [03:34] LordKow: Did you build it yet? [03:34] nope, if i did then i would give it a 0% chance of FTBFS'ing this time ;) [03:35] okay well apt likes everything in the control file so far so good [03:35] apt? [03:35] pbuilder [03:35] Ah. OK. [03:35] ok, nice, first pass through the revdep chain of mp4v2 all builds, now to go to the gym and come back and walk down the faac chain === choudesh_ is now known as choudesh [03:38] pbuilder might run out of disk space just trying to compile this heavily dependent package heh. 3 gigs left on my HDD at the start, 232 new packages including some huge libs like gtk2 [03:38] that # may include base packages im not exactly sure how pbuilder works [03:39] ah yep all the gnome libs too [03:39] * Fujitsu fails to see how GNOME libs are base packages... [03:40] sorry, i was rambling. I meant to say 232 new packages may include the base packages. the gnome libs statement is one of the packages but not a base package. [03:42] configure: "libgoffice-0.4 < 0.5.0" well duh if that statement is ever false then someone messed up in packaging [03:43] i used requestsync script, where do i check if it was correctly send? [03:43]