[00:05] <ScottK> txwikinger: You still around?
[00:05] <ScottK> txwikinger: I've run into this exact issue before.
[00:06] <txwikinger> yes ScottK
[00:06] <ScottK> Does the package include the full text of any of the licenses that apply (there are 3)?
[00:06] <txwikinger> No.. only a reference to perl
[00:07] <ScottK> You will have to repack the tarball to include a copy of the license.
[00:07] <ScottK> I'll get you some references.
[00:07] <ScottK> Also, "Same terms as Perl" covers at least 3 licenses:
[00:07] <ScottK> Perl Artistic License
[00:07] <ScottK> GPL v2
[00:07] <ScottK> GPL v1
[00:07] <txwikinger> I think it is GPL and Perl Artistic
[00:08] <ScottK> If it's "Same as Perl" then it's both GPL v1 and v2.
[00:08] <txwikinger> This package is free software and is provided "as is" without express
[00:08] <txwikinger> or implied warranty.  You can redistribute it and/or modify it under
[00:08] <txwikinger> the same terms as Perl itself.
[00:08] <ScottK> All three will need to be covered in debian/copyright.
[00:08] <ScottK> Yes.
[00:08] <txwikinger> that is in the readme file
[00:08] <ScottK> At least one needs to be in the tarball, so you have to repack.
[00:09] <txwikinger> I have created the debian/copyright
[00:09] <ScottK> With all three licenses discussed?
[00:09] <txwikinger> and there given the reference to the folders in which those licenses are in ubuntu/debian distro
[00:09] <txwikinger> I think just gpl and perl artistic
[00:10] <txwikinger> not explicitly gpl v1 and v2
[00:10] <ScottK> Yes.  Perl is explicitly v1 and v2.
[00:10] <ScottK> https://launchpad.net/ubuntu/feisty/+source/libnet-dns-resolver-programmable-perl/0.002.2-0ubuntu1 is a package I did.
[00:10] <txwikinger> and I copied the COPYING file from perl to the package top directory
[00:10] <ScottK> Some of the rules on how you document repacking have changed a bit, so you'll want to read up on that.
[00:11] <txwikinger> ok.. I haven't repackaged the orig tarball I think
[00:11] <ScottK> 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] <ScottK> The package I showed you above can mostly be used as a reference.
[00:12] <ScottK> for what has to go in.
[00:12] <txwikinger> right
[00:15] <slangasek> 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] <txwikinger> Thanks ScottK
[00:17] <ScottK> slangasek: True, but unless there's a reason not to, I think packagers should preserve upstream's preferences in licensing.
[00:18] <lifeless> ScottK: we can't limit upstream's preference, but we can patch it with something not compatible with upstreams entire preferences
[00:18] <ScottK> 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] <ScottK> lifeless: I agree that we can.  I also think that we shouldn't without a good reason.
[00:19] <slangasek> 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] <slangasek> 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] <ScottK> 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] <slangasek> 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] <ScottK> That certainly makes sense.
[00:27] <txwikinger> ScottK: maybe they can't get all authors to agree to the change to GPL v2 or is all copyright transfered?
[00:28] <ScottK> It's GPL v1 and 2, so they can drop 1 if they feel like it.
[00:28] <StevenK> ScottK: Perl is special, being GPLv2 or Artistic
[00:28] <ScottK> StevenK: Except it's really GPLv1, GPLv2, or Artistic, so it's even more special than that.
[00:29] <ScottK> pitti or Mithrandir rejected my first new package because of this.
[00:30] <imbrandon> wtfpl ftw:)
[00:30] <minghua> 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] <txwikinger> minghua:
[00:32] <txwikinger> the GNU General Public License as published by the Free
[00:32] <txwikinger> 	Software Foundation; either version 1, or (at your option) any
[00:32] <txwikinger> 	later version, or
[00:32] <lifeless> txwikinger: thats the licence, not the grant.
[00:32] <lifeless> txwikinger: you have to have a grant statement to decide what licence a package is under
[00:34] <txwikinger> lifeless: I have no idea what this means
[00:34] <ScottK> txwikinger: It means you were quoting from the GPL, not the bit where Perl says how it's licensed
[00:34] <norsetto> g'night all
[00:35] <minghua> 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] <ScottK> Then it's be v3 too I guess.
[00:35] <txwikinger> ScottK: I was quoting from perl's readme file which declares under which terms you are allowed to redistribute
[00:35] <ScottK> That's consistent with my recollection from January
[00:36] <ScottK> txwikinger: The part you were quoting from is part of the GPL though.
[00:36] <txwikinger> ScottK: True it is inside the GPL also
[00:37] <superm1> 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] <superm1> actually hmm.  can't remove it without removing mplayer
[00:40] <superm1> something about mplayer wants to keep it
[00:40] <superm1> some other dependency
[00:40] <jdong> superm1: I could've sworn...
[00:40] <Fujitsu> Which dependency?
[00:40] <superm1> i'm not sure.
[00:40] <Fujitsu> Which package are you trying to remove?
[00:40] <jdong> superm1: http://packages.ubuntu.com/hardy/graphics/mplayer
[00:40] <superm1> libmp4v2-0
[00:40] <jdong> superm1: on [powerpc] there's a binary dep on mp4v2
[00:40] <superm1> oh interesting.
[00:40] <jdong> Fujitsu: not trying to remove, chasing after an API migration
[00:41] <jdong> superm1: could be a shlibdeps phenomenon?
[00:41] <superm1> well if its only on ppc, then why is it sticking around for i386?
[00:41] <jdong> where phenomenon is polite speak for bug?
[00:41] <superm1> haha
[00:43] <superm1> its a dependency of libfaac0
[00:43] <superm1> which is a dependency of mplayer
[00:43] <jdong> superm1: oh so it gets pulled in anyway
[00:43] <superm1> yeah
[00:44] <jdong> superm1: lovely, well faac is definitely going to be hit by the mpeg4ip transmition
[00:44] <superm1> what transition?
[00:44] <jdong> superm1: mp4v2 will be provided by mpeg4ip instead of faad
[00:44] <crimsun> 172863.
[00:44] <jdong> yeah what crimsun said :)
[00:44] <crimsun> 683.
[00:45] <superm1> bug 172863
[00:45] <crimsun> other one.
[00:45] <crimsun> bug 172683
[00:45] <ubotu> Launchpad bug 172683 in gtkpod-aac "libmp4v2 API migration" [Undecided,Confirmed] https://launchpad.net/bugs/172683
[00:45] <superm1> bug 683
[00:45] <superm1> o
[00:46] <jdong> superm1: with regards to mplayer, I think if we deal with faac mplayer should remain unaffected
[00:46] <jdong> (famous last words)
[00:46] <superm1> well except on powerpc i guess?
[00:46] <jdong> superm1: I don't understand what the difference with ppc is?
[00:46] <superm1> i didn't think there was a [powerpc] build depend even though
[00:46] <superm1> that doesn't seem right
[00:46] <jdong> superm1: I didn't see it in my Sources.gz grep
[00:46] <superm1> so p.u.c is on crack?
[00:47] <somerville32> superm1, I was looking for you in x-devel
[00:48] <jdong> Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
[00:48] <jdong> Original-Maintainer: Ubuntu MOTU Media Team <motumedia@tauware.de>
[00:48] <jdong> ^^ is that _really_ necessary? :)
[00:48] <jdong> (feisty)
[00:48] <ScottK> jdong: Per the spec, yes.
[00:48] <ScottK> Since tauware.de is not in ubuntu.com
[00:49] <jdong> well technicality wise, I guess
[00:49] <Fujitsu> debuild gets cranky, so it's best do mangle it.
[00:49] <Fujitsu> s/do/to
[00:49] <ScottK> May as well.
[00:49]  * jdong wonders why motumedia doesn't get a @lists.ubuntu.com?
[00:50] <Fujitsu> jdong: That takes a loooong time.
[00:50] <jdong> ah, lovely
[00:50] <crimsun> (not to mention prior to USD-Boston, there was some discussion of dissolving the team)
[00:50] <crimsun> UDS*
[00:50] <Fujitsu> crimsun: That's true.
[00:50] <jdong> ah
[00:50] <Fujitsu> crimsun!
[00:50] <crimsun> Fujitsu!
[00:51]  * jdong uploads a rebuild of faac to motumedia-ppa and hopes nothing explodes... again.
[00:51]  * Fujitsu explodes.
[00:51] <ScottK> Fujitsu: Save the exploding for the CC meeting tomorrow.
[00:51] <jdong> what's going down there?
[00:52] <ScottK> A certain somebody who tends to be somewhat unpopular in these parts has listed himself as a membership candidate.
[00:52] <Fujitsu> 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] <ScottK> Fujitsu: It'll be more fun to have a public fight about it.
[00:53] <Fujitsu> ScottK: I guess.
[00:53] <ScottK> Actually, I think more necessary.
[00:53] <Fujitsu> Ew, 3am tomorrow...
[00:53] <Fujitsu> I'll have to watch, though.
[00:53] <Fujitsu> I haven't been to a CC meeting in aages.
[00:53] <crimsun> sounds like I've missed a thoroughly rousing devel cycle ;)
[00:54] <Fujitsu> crimsun: That you have.
[00:54]  * ajmitch wonders who this certain someone is?
[00:54] <Fujitsu> ajmitch: I'm sure you can guess...
[00:54]  * minghua didn't know that he is not a member yet.
[00:54] <ScottK> ajmitch shouldn't have much trouble figuring it out.
[00:54] <ajmitch> nope, i can't
[00:55]  * jdong feels out of the loop
[00:55] <ajmitch> at least I don't see any recent changes to the CC agenda
[00:55] <somerville32> When is the next CC?
[00:55] <ScottK> He's been on the list for a whlie.  It's just been quite some time since the last meeting.
[00:55] <ajmitch> it must have been
[00:55] <jdong> I guess that means look towards the top
[00:55] <ajmitch> about 6 weeks or so since the last one?
[00:55] <ScottK> somerville32: ~20 hours
[00:56] <ajmitch> 5AM local time
[00:56] <somerville32> Are you guys talking about kmos?
[00:56] <ScottK> Or less.
[00:56] <superm1> who is representing him?
[00:56]  * ajmitch shrugs
[00:56] <Fujitsu> somerville32: What gives you that idea?
[00:56] <ScottK> somerville32: None of us said that.
[00:56] <ajmitch> just say it :P
[00:56]  * Fujitsu invokes the CoC.
[00:57] <jdong> ok while we are paying keep-jdong-in-suspense, anyone want to comment on pulling faac from debian-multimedia again?
[00:57] <jdong> it looks like trying a merge from d-m will be easier than patching our old-ish version
[00:57] <ScottK> jdong: I'd so go for it.  Your track record on such things is reasonably good.
[00:57] <minghua> Wow, https://launchpad.net/~ubuntumembers/+members really has a long applicant list.
[00:58]  * somerville32 thought kmos would look different.
[00:58] <jdong> 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] <ajmitch> I should apply to be a member
[00:58] <ajmitch> I think i'm only in the team indirectly
[01:00] <crimsun> teehee, expired on 2007-08-16
[01:02] <ajmitch> ah no, I am still a direct member
[01:02] <ajmitch> must have only been MOTU I expired from
[01:02]  * Fujitsu wonders if GetDeb people can be automatically excluded.
[01:03] <ajmitch> Hobbsee!
[01:03] <jdong> there she is
[01:03] <Fujitsu> Hi Hobbsee.
[01:03] <minghua> Oh, my membership will expire soon, it seems.
[01:03] <ajmitch> Fujitsu: no, they should be given a chance, at least
[01:04] <minghua> ajmitch: Can automatix people be auto-excluded then? :-P
[01:04] <StevenK> minghua: Do you have some time to explain how GTK input methods work?
[01:04] <ajmitch> minghua: noone can, really :)
[01:04] <jdong> hehe I'm ex-automatix :)
[01:04] <Hobbsee> heya!
[01:04] <ajmitch> I know :)
[01:04] <minghua> StevenK: Sure.  Glad to see you are interested in it.
[01:05] <StevenK> minghua: I'm trying to get Hildon Input Method working, and I'm getting nowhere slowly.
[01:05] <minghua> StevenK: I assume you understand the general idea of input methods?
[01:05] <ajmitch> and it's taken many long years of rehabilitation
[01:05] <jdong> ajmitch: lol ;-)
[01:06] <StevenK> 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] <minghua> StevenK: Oh.  Then you probably don't.
[01:07] <minghua> StevenK: The point of an IM is to convert keystroke sequences to character/string.
[01:07] <minghua> 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] <ubotu> Launchpad bug 80825 in faac "Version bump to 1.25 request" [Undecided,Confirmed] https://launchpad.net/bugs/80825
[01:09] <minghua> 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] <minghua> StevenK: XIM has many limitations, and is generally hard to code for X client programmers, and error-prone.
[01:09] <jdong> hmm better get his opinion on this -- he felt strongly enough 1.5yrs ago to package from scratch and diverge from marillat
[01:10] <StevenK> minghua: Which lead to SCIM, I'm guessing
[01:11] <minghua> 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] <minghua> StevenK: Not yet. :-)
[01:11] <ScottK> Hobbsee: Did you see the message I left for LongPointyStick about the CC meeting tomorrow.
[01:12] <LordKow> is breezy (5.10) long past being supported?
[01:12] <minghua> 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] <StevenK> Breezy is long dead, yes
[01:12] <effie_jayx> :(
[01:12] <minghua> StevenK: So obviously most existent conversion programs works for XIM, and GTK+ don't want to throw them away.
[01:12] <StevenK> minghua: I knew that bit from my web searching yesterday
[01:12] <LordKow> 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] <effie_jayx> s/remember/remembers
[01:13] <jdong> breezy was the roughest Ubuntu release I've used
[01:13] <crimsun> LordKow: correct.
[01:13] <LordKow> k one step closer to being able to sync
[01:13] <minghua> StevenK: Therefore GTK+ can defer to XIM to handle the conversion, which is what GTK_IM_MODULE=xim mean.
[01:13] <StevenK> 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] <StevenK> minghua: Yup.
[01:14] <LordKow> StevenK, considering the conflict/replace in question is not in dapper they should be safe to remove
[01:15] <minghua> 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] <Hobbsee> ScottK: not yet, but i will
[01:15] <StevenK> minghua: Right.
[01:15] <minghua> StevenK: Again, this is controlled by the GTK_IM_MODULE variable.
[01:16] <minghua> StevenK: This is basically about IM.  I take it that you are interested in SCIM as well?
[01:16] <StevenK> minghua: Not particularly, I'm interested in how to debug IM because I can't get Hildon Input Method working
[01:17] <minghua> StevenK: What input method is Hildon using?  I'm not familiar with it at all.
[01:17] <slangasek> presumably the "hildon" one :)
[01:17] <minghua> Is it a special GTK IM module?
[01:17] <StevenK> It's own, http://live.gnome.org/Hildon/HildonInputMethod
[01:17] <StevenK> Actually, the input method is called "hildon-input-method"
[01:21] <minghua> StevenK: Does hildon-IM run on vanilla GTK now?
[01:21] <StevenK> I've not been able to determine that.
[01:22] <StevenK> Although I suspect the answer is "No" since I can't get it working
[01:22] <minghua> 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] <minghua> The problem is, Debian/Ubuntu's GTK IM stack is not vanilla either...
[01:23] <StevenK> Hold on, just booting the device
[01:23] <slangasek> minghua: in what sense, and why?
[01:24] <minghua> StevenK: If you've been following http://live.gnome.org/Hildon/HildonInputMethod/Building, I can seen something would not work...
[01:24] <minghua> slangasek: Let me dig up the reference for you.
[01:24] <StevenK> minghua: Oh?
[01:25] <minghua> slangasek, StevenK: http://lists.debian.org/debian-gtk-gnome/2006/10/msg00045.html
[01:27] <minghua> slangasek, StevenK: I can't find a better reference, so I'll elaborate a bit more:
[01:28] <minghua> GTK uses /etc/gtk-2.0/gtk.immodules to register all the available IMs.
[01:29] <minghua> So individual IMs need to update that file after they are installed/uninstalled.
[01:29] <minghua> You can see it would cause some problem as it's a conffile.
[01:29] <StevenK> Yeah
[01:30] <StevenK> Just throwing hildon-input-method into /etc/gtk-2.0/gtk.immodules has made it hit the list of input methods.
[01:30] <minghua> 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] <minghua> And /etc/gtk-2.0/gtk.immodules become useless.
[01:31] <StevenK> dh_gtkmodules ah
[01:31] <minghua> StevenK: That's why I say following the Hildon upstream instructions would not work.
[01:31] <StevenK> minghua: It certainly helped
[01:31] <minghua> This change is not in GTK+ upstream AFAIK.
[01:32] <minghua> slangasek, StevenK: Debian bug 419314 is an example how input method packages should adapt to this change.
[01:32] <ubotu> 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] <minghua> Loïc Minier should know better than I do, as that change is his.
[01:33] <minghua> And I think he is also an MOTU now?
[01:34] <StevenK> I can talk to Loïc about it
[01:34] <StevenK> Now, how do I set a gconf key
[01:35] <minghua> gconftool if you are hardcore, gconf-editor is a saner alternative.
[01:35] <StevenK> From a command line, hopefully
[01:35] <crimsun> StevenK's hardcore!
[01:36] <minghua> StevenK: gconftool-2, actually it seems, as gconftool is a symlink to it.  It's command-line.
[01:39] <StevenK> Right, got it.
[01:42] <LordKow> are there any policies with regard to putting Homepage: <whatever> in a package description?
[01:43] <jdong> 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] <StevenK> What? Homepage as a field has only just started existing
[01:44] <RAOF> I think he meant "using Homepage: foo in the package description", not the shiny new dpkg field.
[01:44] <LordKow> okay, this particular package has the Homepage set properly but (in regards to homepage) we deviated from debian by adding Homepage: <link> to the package descriptions to
[01:44] <LordKow> i take it I can safely remove the homepage link from the description?
[01:44] <RAOF> Well, there's a nice easy divergence to drop :)
[01:46] <minghua> If those two URLs are the same. :-)
[01:46] <TheMuso> StevenK: In what context do you need to set a gconf key?
[01:46] <TheMuso> StevenK: Is it just for your own use, or within a package?
[01:46] <StevenK> TheMuso: Within a package
[01:47]  * StevenK has figured it out, too
[01:47] <TheMuso> StevenK: Are you aware of the gconf-defaults mechanism available?
[01:50] <StevenK> TheMuso: Nope. Can you spit out more information?
[01:51] <TheMuso> 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] <TheMuso> /path/to/gconf/key value
[01:51] <TheMuso> /path/to/other/key false
[01:51] <TheMuso> etc
[01:52] <TheMuso> 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] <LordKow> are there any limitations to merges when the merge involves new packages added by debian?
[01:52] <TheMuso> Hope that makes sense
[01:52] <TheMuso> sorry, dh_gconf
[01:52] <StevenK> TheMuso: Sure it does, I'll add dh_gconf as something to look at. :-)
[01:54] <RAOF> LordKow: You mean the same source package now builds new binary packages?
[01:54] <LordKow> yes
[01:55] <LordKow> it adds a new package (but doesnt rename or remove any others)
[01:56] <RAOF> I can't think of anything special at the moment.
[01:56] <minghua> Probably checking that there is not package name collision.
[01:56] <LordKow> k. it was added by debian but I will still mention it in the changes for future reference
[01:57] <LordKow> minghua, yep gcrystal does not exist in any of our repos right now
[01:57] <minghua> LordKow: Sounds good.
[02:06] <jdong> hmm convention question:
[02:07] <jdong> 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] <jdong> err I just used (A) and (2)
[02:08]  * Fujitsu would go with A.
[02:09] <jdong> I'm leaning towards A, too
[02:09] <jdong> 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] <Fujitsu> You can't hide them forever!
[02:12] <jdong> lol
[02:13] <lifeless> hmm
[02:13] <lifeless> possible attack vulnerability with reused binaries there
[02:13] <Fujitsu> lifeless: The .changes?
[02:14] <Fujitsu> Where are the binaries reused?
[02:15] <lifeless> I've mailed the soyuz folk.
[02:15] <lifeless> If I'm wrong I'll explain it to you tomorrow when they correct me.
[02:16] <lifeless> If I'm right, I'd rather not say more just yet.
[02:19] <somerville32> OooOoo...
[02:20] <jdong> dun dun dunnnnnnn
[02:21]  * Fujitsu notes there is another much, much worse vulnerability.
[02:22] <somerville32> Really? Do share.
[02:22] <Hobbsee> you don't want to know.
[02:22] <Fujitsu> You really don't want to know.
[02:22]  * ajmitch really does
[02:23] <Fujitsu> It is a most nasty one.
[02:23]  * somerville32 always wants to know.
[02:27] <Amaranth> I want to know
[02:27] <Amaranth> So I can exploit it and find the hidden GNOME 3.0 packages
[02:28] <Amaranth> I know seb128 has been keeping them from me
[02:35] <jdong> 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] <jdong> (almost certainly a yes... :-/)
[02:37] <bddebian> Heya gang
[02:37] <imbrandon> heya bddebian
[02:38] <bddebian> Hi imbrandon
[02:44] <crimsun> jdong: never fear the rdep chain.  Fear the morning after.
[02:44] <jdong> :)
[02:44] <crimsun> (yes, I know you're procrastinating.)
[02:44] <bddebian> heh, heya crimsun
[02:45] <jdong> crimsun: shhhhhh ;-)
[02:45] <crimsun> heya bddebian
[02:45] <jdong> when's our first tribe?
[02:45] <jdong> or flock
[02:45] <jdong> or gaggle
[02:46] <jdong> what do herons come in?
[02:46] <StevenK> jdong: "Alpha"
[02:46] <minghua> I thought we abandoned that naming system for hardy.
[02:46] <jdong> other than crates of refrigerated styrofoam trays
[02:46] <jdong> minghua: ah I didn't get that memo then
[02:46] <jdong> ok, "Alpha" it is.
[02:46] <RAOF> And the answer is now, approximately.
[02:46] <jdong> when is the freezing fun scheduled?
[02:46] <jdong> ah
[02:46] <jdong> ok
[02:47] <somerville32> jdong, no freeze
[02:47] <imbrandon> no freeze
[02:47] <jdong> somerville32: I know but I'd rather not put anything in that MIGHT break parts of the multimedia stack
[02:47] <RAOF> jdong: A self-imposed freeze.
[02:47] <jdong> in ways that would affect "users" (read: insane testers :D)
[02:47] <imbrandon> jdong: your a MOTU now you really should read more email :)
[02:47]  * RAOF hunts the ubuntu-devel message about this...
[02:47] <somerville32> burn
[02:47] <jdong> imbrandon: it's been a hellish week after getting back from thanksgiving...
[02:47]  * somerville32 hugs jdong 
[02:47] <StevenK> RAOF: Freeze!
[02:47] <StevenK> RAOF: Okay, go on.
[02:47] <imbrandon> heheh i totaly understand, i was just messing with ya
[02:47] <StevenK> :-P
[02:47] <jdong> imbrandon: I will catch up on the 300-whatnot messages after friday :)
[02:48]  * somerville32 has 5k
[02:48] <jdong> somerville32: I actually read mine normally ;-)
[02:48] <somerville32> jdong, me too :P I just got so much
[02:48] <somerville32> And no spam :(
[02:48]  * somerville32 wishes he could get spam he could just easily delete.
[02:48] <RAOF> 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] <StevenK> Note to self: Patches work better if you list them in 00list
[02:49] <crimsun> somerville32: I could sub you to a few LP teams as the bug contact...
[02:49]  * StevenK does the whole dance again
[02:49] <somerville32> crimsun, sub?
[02:49] <imbrandon> StevenK: hehe
[02:49] <crimsun> somerville32: add/subscribe
[02:49] <jdong> RAOF: thanks :)
[02:50] <somerville32> crimsun, I already get enough bug mail :P
[02:50] <jdong> StevenK: ah, yes, that was infinite loop #2 of mpeg4ip
[03:20] <superm1> jdong, why not use apple mail on it?
[03:20] <superm1> jdong, apple mail works really well actually on mine
[03:20] <superm1> jdong, the only problem is that google's imap doesn't refresh all my labels
[03:22] <imbrandon> is there a python function to escape/convert a html strings from like < to &lt; and &quote; etc ?
[03:24] <slangasek> not as part of the standard library, ttbomk
[03:24] <imbrandon> hrm
[03:24] <nxvl> imbrandon: i don't know any, but you can write one
[03:24] <slangasek> nxvl: and forget one of the chars that need escaping and cause XSS vulns ;)
[03:25] <imbrandon> i'm barely past page one on dive into python :)  i dont think writing my own is worth it
[03:25] <ScottK> imbrandon: I think not as it's come up as a problem with REVU comments.
[03:25] <imbrandon> at this point
[03:25] <StevenK> Um, sure there is.
[03:25] <slangasek> StevenK: called?
[03:25] <StevenK> It's in urllib, I think
[03:25] <imbrandon> i'm already importing urllib so i'll see
[03:25]  * imbrandon looks
[03:26] <StevenK> http://docs.python.org/lib/node563.html#l2h-3814
[03:26] <StevenK> cgi.escape()
[03:27] <nxvl> how is a sync done?
[03:27] <nxvl> only download the debian package and upload it?
[03:28] <StevenK> nxvl: A sync is done by the archive admins
[03:29] <nxvl> StevenK: so if one packages is marked as merge and it need a sync y only ask for it on #ubuntu-devel?
[03:30] <jdong> superm1: haven't bothered to jailbreak/EULA-rape mine yet
[03:31] <jdong> superm1: gonna use it the way apple intended (tm or else) for a few weeks before hacking it
[03:31] <imbrandon> nxvl: no you file a sync request bug
[03:31] <imbrandon> following the guidelines
[03:31] <LordKow> https://wiki.ubuntu.com/SyncRequestProcess
[03:33] <nxvl> thnx
[03:33] <LordKow> 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] <ScottK> LordKow: Did you build it yet?
[03:34] <LordKow> nope, if i did then i would give it a 0% chance of FTBFS'ing this time ;)
[03:35] <LordKow> okay well apt likes everything in the control file so far so good
[03:35] <ScottK> apt?
[03:35] <LordKow> pbuilder
[03:35] <ScottK> Ah.  OK.
[03:35] <jdong> 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
[03:38] <LordKow> 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] <LordKow> that # may include base packages im not exactly sure how pbuilder works
[03:39] <LordKow> ah yep all the gnome libs too
[03:39]  * Fujitsu fails to see how GNOME libs are base packages...
[03:40] <LordKow> 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] <LordKow> configure: "libgoffice-0.4 < 0.5.0" well duh if that statement is ever false then someone messed up in packaging
[03:43] <nxvl> i used requestsync script, where do i check if it was correctly send?
[03:43] <nxvl> sent*
[03:43] <RAOF> Launchpad
[03:44] <jdong> LordKow: is that something like J2RE 6 SE Version 1.6.0_01b21?
[03:44] <nxvl> RAOF: on the package bugs?
[03:44] <RAOF> Yup.
[03:44] <nxvl> mm
[03:44] <nxvl> i will wait a little, it must take some time
[03:44] <nxvl> brb
[03:45] <LordKow> jdong, im working on gnome-chemistry-utils. that previous statement was in the configure but if this candidate is correct then that statement is now "libgoffice-0.5 >= 0.5.0" with no max version
[03:46] <jdong> whoo looks like only ~5 revdeps to deal with for faac
[03:46] <jdong> grr what am I doing, gym time...
[03:46] <LordKow> the devs of gnome-chemistry-utils dont specify any version requirements on their website so i figure it should always build against the latest version
[03:47] <LordKow> i guess its possible that libgoffice may be updated and break gnome-chemistry-utils but setting max version restrictions are nasty.
[03:47] <jdong> LordKow: yeah don't worry about max restrictions
[03:48] <Fujitsu> No, do worry about max restrictions.
[03:48] <jdong> LordKow: just make sure you set minimum to the hardy version if the hardy version has not built binaries across all arches yet
[03:48]  * somerville32 sneezes 
[03:48] <RAOF> LordKow: That's the responsibility of the library maintainer.
[03:48] <somerville32> I forgot to take my allergy meds :(
[03:48]  * jdong pets somerville32 and tells him to stop whoring for attention ;-)
[03:48] <LordKow> the proper way would be to notice that gnome-chemistry-utils will no longer build from source due to new libgoffice, therefore gnome-chemistry-utils should be fixed :)
[03:48] <Fujitsu> g-c-u was a big problem for quite some time, as we had a newer libgoffice, which didn't work with it.
[03:48] <Fujitsu> s/newer/development/
[03:48] <jdong> LordKow: ha, how many people actually test the reverse deps ;-)
[03:49] <jdong> this would all be so much easier by a drive-by API change mechanism ;-)
[03:49] <LordKow> jdong, well the most testing i do is build the packages, install them... and run 'em
[03:49] <jdong> *BANG* (run before anyone notices broken revdeps)
[03:49] <TheMuso> c
[03:49] <TheMuso> wrong tab
[03:50] <jdong> LordKow: hehe this multimedia stuff I'm working on seems to always uproot a mesh of revdep problems :)
[03:50] <jdong> but it builds character :)
[03:50] <LordKow> hehe, and frustration
[03:50] <LordKow> ah yep FTBFS, time to see why
[03:50] <jdong> yay!
[03:52] <LordKow> oh bless descriptive gnome changelogs, this shall be an easy fix
[03:52] <LordKow> and its an issue of the package not building against the latest goffice... i sense upstream bug reports
[03:52] <LordKow> http://ftp.gnome.org/pub/GNOME/sources/goffice/0.5/goffice-0.5.1.changes look at all of those headers they moved... eeeuuwwwwwwwww
[03:53] <LordKow> change build-dep to >= 0.5.1 and go with it i guess
[03:57] <LordKow> okay i think i'll cancel the g-c-u 0.8.x merge and file a request in debian to -> 0.9 because the g-c-u devs fixed FTBFS against goffice 0.5.1 and that is what we have in hardy
[03:59] <Fujitsu> LordKow: Does Debian have that goffice yet?
[03:59] <LordKow> yea in fact we should be merging with it, they use 0.5.3
[04:00] <LordKow> so, i wonder how long before debian g-c-u maintainers realize 0.8 doesnt compile against goffice >= 0.5.1
[04:01] <LordKow> ah, thats why they require 0.4
[04:01] <LordKow> so for us i guess the question is: what do we do about the g-c-u merge? :p
[04:02] <crimsun> hmm, well, 6.06 -> 8.04 using apt-get hitches on initramfs-tools.
[04:03] <LordKow> we could always push libgoffice-0.4 into hardy but the package would possibily be obsolete before hardy is even released in april
[04:04] <LordKow> and it would conflict with 0.5. too messy
[04:04] <LordKow> but our current version wont compile against 0.5 :-/
[04:04] <LordKow> so g-c-u is dead in the water right now
[04:12] <crimsun> hmm, and on libx11-data.
[04:15] <crimsun> ok, so bug 56008 is moot.  It's definitely installable due to xutils existing in 8.04.
[04:15] <ubotu> Launchpad bug 56008 in gsfonts-x11 "gsfonts-x11 depends on uninstallable transitional package xutils" [Medium,Confirmed] https://launchpad.net/bugs/56008
[04:15] <jcastro> hi guys, the US LoCo teams are running an educational session on friday at EST2000 to get LoCo people involved in becoming MOTUs, triaging bugs, etc. Are any US-based MOTUs willing to hang out in ubuntu-us and help point people in the right direction?
[04:15] <crimsun> what's that, 3 PM?
[04:16] <crimsun> (EST)  I'd still be @work.
[04:16] <crimsun> err, I totally misparsed that.
[04:16] <crimsun> yeah, I can do that, jcastro.
[04:17] <jcastro> crimsun: so, to give you more details
[04:18] <jcastro> christer wants to seriously leverage LoCo people to become MOTUs
[04:18] <jcastro> so he's running his own LoCo-driven "open week"
[04:18] <jcastro> and if reaching out to volunteers
[04:18] <jcastro> the idea is to have MOTUs on stand by to deal with volunteers that might be interested
[04:19] <crimsun> right.
[04:19] <jcastro> crimsun: totally crap too dude, I only got to say hi, we never got a chance to sit down and talk about stuff
[04:20] <crimsun> jcastro: 'sokay, you guys were jamming
[04:20] <jcastro> I hope you got a chance to meet some of the other .edu people there
[04:22] <Burgundavia> jcastro: jorgey!
[04:23] <jcastro> Burgundavia: COREY!
[04:23] <ScottK> People interested in Universe and security stuff might want to look at https://wiki.ubuntu.com/TechnicalBoardAgenda and then discuss with Burgundavia...
[04:32] <LordKow> how did a package like g-c-u which is under heavy heavy development make it into ubuntu? :P
[04:32] <Fujitsu> ScottK, Burgundavia: hah, I was thinking about requesting that last night.
[04:32] <Fujitsu> But we need reasonable security support first, which \sh and I are working on organising.
[04:32] <ScottK> Thought you'd like it.
[04:32] <ScottK> Fujitsu: We do some now and it's reasonable (I think) to document what we are doing.
[04:33] <ScottK> BTW if you want help on the security organizing thing, let me know.
[04:33] <Fujitsu> ScottK: Sorta, I guess.
[04:34] <ScottK> My favorite was one security upload I did for a perl package in 4 releases.  It was in Main for two and Universe for two and so the USN only discussed the Main releases and was silent on the rest.
[04:34] <Fujitsu> ScottK: That's understandable.
[04:35] <Fujitsu> We need UUSAs at some point, particularly with the recent removal of a certain bug/feature.
[04:35] <Fujitsu> I'd like them to be in place before Hardy, at least, and I will do whatever it takes to get them happening.
[04:35] <ScottK> Fujitsu: It's understandable to me since I'm involved in the process, but it totally violates the principal of least suprise
[04:36] <LordKow> bug 172717 im not sure anyone here right now wants to tackle this but just in case.
[04:36] <ubotu> Launchpad bug 172717 in gnome-chemistry-utils "[hardy] G-C-U FTBFS and Possible Merge" [Undecided,New] https://launchpad.net/bugs/172717
[04:36] <Fujitsu> Burgundavia: Kees commented in the -security announcement bug that he wanted them back, so I suspect we'll get them soon.
[04:37] <Burgundavia> Fujitsu: right, that would rock
[04:37] <Fujitsu> Do we have a date for the meeting yet?
[04:37] <Burgundavia> the TB one?
[04:37] <keescook> Fujitsu: Supposedly it's scheduled for 1.1.12 LP roll-out
[04:37] <Fujitsu> Burgundavia: What would?
[04:37] <Fujitsu> Yeah, TB.
[04:37] <Burgundavia> look, I only deal with on train wreck of a meeting schedule, the CC one
[04:37] <Fujitsu> keescook: Hi. That's good.
[04:37] <Fujitsu> Burgundavia: Heh.
[04:39] <Fujitsu> keescook: You don't have any horribly violent objections to us doing USAs for universe (UUSAs?) to some universe-security or similar mailing list, do you?
[04:40] <keescook> UUSN, maybe to share more of the acronym?  no objection at all, I think it's a fine idea.
[04:40] <keescook> I've long wanted a place for UUSNs to go, which is why I was so annoyed to discover that they stopped going to the -changes list
[04:40] <Fujitsu> Erm, yes, N, I meant.
[04:41] <Fujitsu> I've been looking at more DSAs late,y.
[04:41] <Fujitsu> Hence the A.
[04:41] <keescook> Fujitsu: also, it's still pushing, but it should be available in about 15 minutes: https://code.launchpad.net/ubuntu-cve-tracker/
[04:41]  * keescook nods
[04:41] <Fujitsu> ubuntu-universe-security@l.u.c, perhaps?
[04:41] <Fujitsu> keescook: Who owns the branch?
[04:42] <keescook> while long, u-u-s-announce matches the u-s-announce list
[04:42] <keescook> Fujitsu: who-ever pushes one.  I figure there would be a motu-swat owned branch
[04:42] <Fujitsu> keescook: OK, best to have consistency.
[04:42] <keescook> and I could merge it to "master" which is under the ubuntu-security group
[04:42] <Fujitsu> keescook: Makes sense, I think.
[04:43] <keescook> Yeah, that doesn't work out, we can just redefine ownership (yay bzr!)
[04:43] <Fujitsu> Rather `yay LP', but yep.
[04:43] <keescook> well, I mean, we can just aim at a different branch and call that one "HEAD".  :P
[04:44] <keescook> anyway, I spent a bunch of time to day (after PHP) working on some graphs
[04:44] <keescook> which is my first step to some better reporting and visualization
[04:47] <Fujitsu> keescook: I do hope you wrote them in PHP.
[04:47] <Fujitsu> Just to add to the fun.
[04:47] <keescook> Fujitsu: heheh.  nope, so far, python and gnuplot love
[04:47] <Fujitsu> keescook: Are the current results anywhere public?
[04:48] <keescook> Fujitsu: not yet
[05:24] <LaserJock> anybody know any way to debug why a binary can't find a shared library, even though it's clearly there?
[05:26] <minghua> strace?
[05:28] <LaserJock> no such file or directory :/
[05:28] <LaserJock> it's in /usr/local/lib/ dang it
[05:32] <RAOF> Is /usr/local/lib in the ldpath?
[05:33] <RAOF> LaserJock: Checked /etc/ld.so.conf{,.d}?  Run ldconf?  Does it work with LD_LIBRARY_PATH=/usr/local/lib <binary>?
[05:34] <RAOF> It's not the wrong architecture (IA32/x86-64?)
[05:38] <LaserJock> ok, LD_LIBRARY_PATH worked
[05:38] <LaserJock> why the heck wouldn't /usr/local/lib be in my path
[05:39] <RAOF> I've seen a couple of people wondering thate.
[05:39] <RAOF> I've not tried it myself.
[05:39] <RAOF> Is /usr/local/lib somewhere in one of the /etc/ld.so.conf.d/ files?
[05:40] <LaserJock> RAOF: it's in /etc/ld.so.conf.d/libc.conf
[05:41] <RAOF> Yeah, that's the one.
[05:41] <LaserJock> ok, I ran ldconfig and now it works
[05:41] <RAOF> That's odd.
[05:41] <LaserJock> go figure
[05:42] <LaserJock> I don't get it, but whatever
[05:42] <RAOF> I thought ldconfig was run at essentially each pakcage install?
[05:42] <RAOF> Oh, well.
[05:43] <RAOF> Hm.  I know nouveau doesn't resume from suspend.  How about hibernate :)
[05:43]  * RAOF shuffles off home.
[05:55] <ScottK> LaserJock: How're the ponies coming?
[05:57] <LaserJock> ScottK: not well I'm afraid
[05:58]  * ScottK has enjoyed reading them in the past, but I guess I'll have to wait then.
[05:59] <LaserJock> I'm really trying, but lots of things are not going well this week
[06:07] <ScottK> Sure.  I'll read them when you get to them.  No pressure.
[06:44] <RAOF> Yay, apport's back on.
[06:48] <dholbach> good morning
[06:48] <imbrandon> moins dholbach
[06:50] <dholbach> hey imbrandon
[06:58] <TheMuso> Hey dholbach.
[06:58] <dholbach> hey TheMuso
[07:05] <imbrandon> err
[07:10] <LaserJock> wow, I'm about to expire
[07:10] <pwnguin> imbrandon: did anyone from ACM get in touch with you?
[07:11] <imbrandon> yup
[07:11] <pwnguin> okays
[07:11] <imbrandon> forgot his name but yea
[07:11] <pwnguin> they can be kinda not on top of the ball
[07:11] <Fujitsu> ACM?
[07:11] <StevenK> LaserJock: I renewed my membership in members about an hour ago
[07:11] <pwnguin> association for computing machinery
[07:11] <LaserJock> StevenK: lol
[07:12] <StevenK> LaserJock: I have this vague feeling we hit members during the same meeting
[07:12] <LaserJock> perhaps so
[07:12]  * pwnguin hacked his router today
[07:13] <pwnguin> it seems linksys stores network keys in cleartext on nvram
[07:13] <LaserJock> I wish the Americian Society of Mechanical Engineers would leave me alone
[07:13] <Fujitsu> Oh wow, 793 proposed members... that's impressive.
[07:13] <LaserJock> I got to one little conference and they think I'm an engineer
[07:14] <pwnguin> proposed members to what?
[07:14] <Fujitsu> pwnguin: ~ubuntumembers
[07:14] <pwnguin> is that a disjoint set of -developers?
[07:14] <LaserJock> now I get a "Join ASME Today!" letter like every month
[07:15] <StevenK> pwnguin: Nope, membership is completly different
[07:15] <Fujitsu> pwnguin: It's general contributors.
[07:15] <Fujitsu> Developers are a subset of members.
[07:15] <pwnguin> StevenK, Fujitsu: one of you is wrong
[07:15] <LaserJock> no, they are both right
[07:15] <imbrandon> they are both right
[07:15] <pwnguin> world explodes
[07:16] <LaserJock> and now imbrandon and I are both right
[07:16] <imbrandon> haha
[07:16] <LaserJock> phew, we got this one nailed down
[07:16] <slangasek> no, only one of you is right
[07:16] <pwnguin> well
[07:16] <pwnguin> once you have a contradiction, you can claim anything
[07:16] <LaserJock> where's the contradiction?
[07:17] <LaserJock> ubuntumembers is not about developers
[07:17] <imbrandon> well when you get to be a developer your automaticly a member if you werent already, but membership is give for other reasons too
[07:17] <pwnguin> but every developer is a member
[07:17] <LaserJock> right
[07:17] <StevenK> pwnguin: But not every member is a developer.
[07:17] <pwnguin> which means they are related :P
[07:17] <LaserJock> pwnguin: well not in purpose
[07:17] <LaserJock> only in membership
[07:18] <pwnguin> anyways, what was the last thing ubuntu-members voted on?
[07:18] <LaserJock> so I would say "completly different" would be correct
[07:18] <LaserJock> pwnguin: I think they only have ever voted on Community Council memebership
[07:18] <Fujitsu> pwnguin: The CC elections.
[07:18] <Fujitsu> Well, the last CC election.
[07:19] <imbrandon> and you get a spiffy @ubuntu.com email addresss :)
[07:19]  * Fujitsu swishes his cloak.
[07:19] <pwnguin> can you put the logo on your business card? ^_^
[07:19] <LaserJock> yep
[07:19] <imbrandon> yea, and a cloak
[07:19] <Fujitsu> pwnguin: You are authorised to carry Ubuntu business cards.
[07:20] <pwnguin> anyways, why's it surprising to see so many members?
[07:20] <slangasek> but only core-dev are allowed to carry Ubuntu business cards with poison tips
[07:20] <Fujitsu> slangasek: Haha.
[07:20] <Fujitsu> pwnguin: Proposed members.
[07:20] <Fujitsu> Twice as many as real members.
[07:20] <imbrandon> slangasek: ohhhh where do i order mine ?
[07:20] <pwnguin> ah
[07:20] <pwnguin> imbrandon: well, you have to pick them up at the ninja council
[07:21] <imbrandon> is that in skeltors castle ? heh
[07:21] <imbrandon> ugh, if its not one thing its another ...... brb
[07:21]  * Fujitsu sneaks another nasty onto imbrandon's plate.
[07:22] <LaserJock> where the heck is my Battle Cat?
[07:22] <imbrandon> he's cringer right now, and hiding behind orko
[07:22] <Fujitsu> LaserJock: Only ubuntu-release gets Ubuntu Battle Cats.
[07:22] <LaserJock> pfft
[07:22] <LaserJock> but I'm in the MOTU trinity :(
[07:24] <Fujitsu> LaserJock: They get Golden Ponies.
[07:24] <LaserJock> then how come I've never gotten one? :(
[07:24]  * imbrandon forgets whom the original trinity was
[07:25] <imbrandon> crimsun, LaserJock, and ajmitch ?
[07:25] <LaserJock> you, bddebian, and myself I think
[07:25] <LaserJock> oh hmm
[07:25] <LaserJock> I don't remember
[07:25] <imbrandon> ahh i thought we were the second comming of the trinity
[07:25] <LaserJock> but I'm in it dang it!
[07:25] <imbrandon> no idea, been to many nights of sleep since then
[07:26] <Fujitsu> imbrandon: s/of/of no/?
[07:26] <imbrandon> lol
[07:26] <imbrandon> crimsun coined it, ask him later :)
[07:27] <LaserJock> and he has a photographic memory
[07:27] <LaserJock> which means he can remember our IRC chat
[07:27] <LaserJock> ;-)
[07:30] <imbrandon> hrm is there a way to remove non-ascii chars from a string without also stripping the linebreaks etc ?
[07:31] <imbrandon> ( python )
[07:31] <lifeless> linebreaks are ascii
[07:31] <lifeless> ord(char) < 128 gives you ascii IIRC
[07:32] <imbrandon> hrm
[07:32] <imbrandon> k
[07:33] <slangasek> but maybe that's not what you mean by "non-ascii"?
[07:33] <imbrandon> well there is some chars that look like blocks with numbers i need to remove
[07:33] <imbrandon> heh
[07:33] <imbrandon> rss hates them
[07:33] <lifeless> well
[07:34] <lifeless> sounds like you just need to encode your unicode string appropriately; whack a utf8 coding on your rss feed and encode as utf8
[07:34] <lifeless> you'll need /some/ entity escaping but thats easy enough
[07:35] <imbrandon> hrm
[07:37] <imbrandon> see the char on col 0, line 441 in http://rss.ubuntuwire.com/xml/ubuntu-universe-sponsors.xml
[07:37] <imbrandon> ( no idea what it is )
[08:09] <RAOF> Hm.  Google reader seems to handle those OK: ஆமாச்சு is what it spits out.
[08:13] <imbrandon> all of them work but the ubuntu-universe-sponsors.xml one, liferea and firefox both choke on it
[08:13] <imbrandon> bout to hit the sack though, i'll figure out why in the morning
[08:13] <imbrandon> tried the utf-8 encoding
[08:13] <imbrandon> dident seem to matter
[08:23] <\sh> moins
[08:23] <BugMaN>  
[09:28] <Sikon> PPA can't build for hardy, can it?
[09:31] <soren> Sikon: Sure it can.
[09:31] <Sikon> Awesome.
[09:39] <huats> morning all
[09:42] <\sh> argl..fck...cacti.net is not even recovered
[10:14] <\sh> gmrpf...starting to fix wireshark
[10:49]  * Fujitsu returns.
[10:50] <Fujitsu> Hi \sh.
[10:51] <Fujitsu> \sh: ubuntu-cve's main branch is now on LP.
[10:59] <effie_jayx> hello all
[11:57]  * Hobbsee waves
[12:23] <\sh> Fujitsu, cool :)
[12:40] <magicfab> hi
[12:40] <magicfab> Hobbsee, :)
[12:41] <Hobbsee> hey magicfab
[12:42] <magicfab> When I add the "partner" repo, (deb http://archive.canonical.com/ubuntu gutsy partner) to my sources list, it gets ignored at update time and I don't see any of its applictions. any reason why ?
[12:42] <Hobbsee> magicfab: where are you looking for it's applications?
[12:43] <magicfab> Hobbsee, synaptic, etc..
[12:43] <Hobbsee> magicfab: what's "etc" in this instance?
[12:44] <magicfab> apt-get update output indicates this:
[12:44] <magicfab> Ign http://archive.canonical.com gutsy/partner Translation-en_US
[12:44] <magicfab> Ign http://archive.canonical.com gutsy/partner Packages
[12:44] <magicfab> Hit http://archive.canonical.com gutsy/partner Packages
[12:44] <magicfab> etc. is Add / Remove... under the Apps menu
[12:44] <Hobbsee> it'll ignore it if there's nothing new
[12:44] <magicfab> and apt-cache search and other similar tools
[12:44] <Hobbsee> magicfab: erm, when did you guys get -partner up and running?
[12:45] <Hobbsee> does mvo's script looking for desktop files even cover partner?
[12:45] <magicfab> ok, but if I browse to the URL I see several packages which I don't see in any package mgmt tool
[12:45] <Hobbsee> not even "apt-cache madison <packagename>" ?
[12:45] <magicfab> Hobbsee, ~nov 6 according to the URL files dates
[12:45] <magicfab> An example:
[12:45] <magicfab> http://archive.canonical.com/ubuntu/pool/partner/v/vmware-server/
[12:46] <magicfab> I am asking here becasue I figured it must be something I don't understand about general packaging
[12:46] <Hobbsee> magicfab: does opera show up?
[12:48] <magicfab> yes it does
[12:48] <Hobbsee> magicfab: good.  for some reason, vmware-server, etc, aren't showing up in http://archive.canonical.com/ubuntu/dists/gutsy/partner/binary-i386/Packages.gz, so this is why your package manager is not finding them.
[12:48] <Fujitsu> Hobbsee: app-install-data-commercial or similar does partner. It's separate.
[12:48] <magicfab> I am thinking all the others are just the latest version under feisty, that's why they don't show up
[12:49] <Hobbsee> magicfab: as for why, you'll have ot ask the soyuz guys why it's showing up in /pool/, but not in the package.gz's.
[12:49] <Fujitsu> Hobbsee: It's only in Feisty.
[12:49] <persia> Was there maybe not a binary copy from feisty to gutsy during the archive transition?
[12:50] <Hobbsee> persia: it got removed from the standard archive.
[12:50] <Fujitsu> persia: https://edge.launchpad.net/ubuntu/+source/vmware-server says no.
[12:50] <Hobbsee> Fujitsu: oh, feisty.  right.
[12:50] <persia> That would do it.
[12:50] <Fujitsu> Bug #155362
[12:50] <ubotu> Launchpad bug 155362 in vmware-server "vmware not present in gutsy" [Wishlist,Confirmed] https://launchpad.net/bugs/155362
[12:50] <Hobbsee> oh, hang on, vmware-player got removed from the archive
[12:50] <persia> Hobbsee: Right.  libssl0.9.7 issues.  That was -player though.
[12:51] <magicfab> heh - no hardy-partner in http://archive.canonical.com/ubuntu/dists/ yet
[12:51] <kenkku> hello dear ubuntuers
[12:52] <persia> magicfab: That likely won't appear until at least 14th December, as everything might need lots of rebuilds.
[12:52] <Fujitsu> Hmmmmm, partner is special. It appears as the release pocket on the page I referenced.
[12:52] <Fujitsu> Oh, woops.
[12:52] <Fujitsu> It's a component now, of course.
[12:53] <persia> Isn't that the difference between -commercial and -partner?
[12:54] <Fujitsu> persia: Yes. (therefore partner shouldn't be referenced with a leading hyphen)
[12:54] <magicfab> there is no more -commercial, AFAIK, only "partner"
[12:54] <persia> Err.  Right -commercial vs. partner.  Nomenclature reset :)
[12:54] <Fujitsu> magicfab: hardy partner is published... It's a component, so is just under hardy/, not hardy-partner/
[12:55] <kenkku> I have been reading the ubuntu basic packaging guide. what's not clear to me is how one creates source packages
[12:55] <magicfab> I knew I knew nothing about this :)
[12:55] <persia> magicfab: Well, gutsy/hardy have partner, whereas dapper/edgy/feisty have -commercial.  It'll be another 41 monts before -commercial is completely gone.
[12:55] <kenkku> I have sources for an app I'd like to package - but they're just in a tarball
[12:55] <persia> kenkku: Are you starting with an upstream release package?
[12:55] <Hobbsee> magicfab: right, so what you're seeing is that the package isn't in gutsy, which is why you can't find it.
[12:56] <kenkku> persia: probably not, since I don't know what that is
[12:56] <kenkku> I'd like to distribute it to a small group, not submit it to ubuntu reps or anything
[12:56] <kenkku> maybe PPA
[12:56] <magicfab> Hobbsee, ok, I jumped to conclusions when seing the content inhttp://archive.canonical.com/ubuntu/pool/partner/
[12:56] <persia> kenkku: That's perfect.  You'll want to unpack the tarball, rename the parent directory to packagename-version, add a debian/ directory, and create four files: changelog, copyright, control, and rules.  The packaging guide starts with an example using the GNU hello package.
[12:57] <persia> kenkku: An "upstream release package" would be the upstream tarball.
[12:57] <Hobbsee> magicfab: yeah - that just relates to "that stuff exists in any one or more of the distros referenced in the other directory"
[12:57] <magicfab> tx to all, I force my self to believe you're all in different timezones, not in EST where it's 8AM (too early for me)
[12:57] <persia> magicfab: We're in a variety of timezones, but hours are also odd sometimes :)
[12:58] <kenkku> persia: about the rules, can I just run the configure script (qmake in this case) on my own computer and use the makefile it generates?
[12:58] <magicfab> persia, leave my fantasies intact, would you :) ?
[12:59] <persia> kenkku: You'll want to have debian/rules run ./configure and then run make.  That means it will configure for the standard environment, rather than your personal workstation.
[12:59] <persia> kenkku: Take a look at the example debian/rules in the packaging guide
[13:00] <kenkku> well, there is no ./configure script for this application
[13:00] <kenkku> so I should have rules run qmake and then make?
[13:00] <persia> kenkku: Right.  Sorry.  debian/rules would run qmake :)
[13:00] <kenkku> ok, now I get it
[13:00] <kenkku> it was a bit confusing since the example in the package had the makefile in the debian/rules file
[13:01] <persia> kenkku: The idea is to have debian/rules have all the steps that a human would normally do, so that it can be done automatically.
[13:01] <kenkku> example in the tutorial I mean :P
[13:01] <persia> Erg.  hello is a nice standard tutorial package, but that sounds confusing.
[13:01] <kenkku> yes, i see now. good thing I came here to ask you :P
[13:02] <kenkku> well, I guess it's time for a brief lunch now. thanks persia :)
[13:02]  * persia enjoys licenses like "Use this code however you wish.  Public Domain.  No warranty." :)
[13:02] <persia> kenkku: No problem.  If the package works well, please consider submitting it for inclusion in Ubuntu.
[13:03] <Riddell> Fujitsu: I need your help
[13:04] <Riddell> Fujitsu: this gnome-chemistry-utils I'm down to merge has defeated me
[13:04] <Riddell> the goffice library is doing wonky things with version numbers
[13:04] <Fujitsu> Riddell: Aha, hi. I saw a bug filed on that earlier.
[13:04] <Fujitsu> Bug #172717
[13:04] <ubotu> Launchpad bug 172717 in gnome-chemistry-utils "[hardy] G-C-U FTBFS and Possible Merge" [Undecided,New] https://launchpad.net/bugs/172717
[13:05] <Riddell> it needs something like this http://kubuntu.org/~jriddell/tmp/gnome-chemistry.diff
[13:05] <Riddell> but there's also API changes needed
[13:05] <Fujitsu> Riddell: See the last three comments on that bug.
[13:07] <Riddell> meh, all too complex for me, I think I need to leave it to the gnome experts
[13:14] <effie_jayx> I got the man page ready for bug https://bugs.launchpad.net/ubuntu/+source/ghc6/+bug/95985 ... can anyone help me as what to do next? .. I have read the man page for dh_installman and several other things. but I am still uncertain as to what next
[13:14] <ubotu> Launchpad bug 95985 in ghc6 "no manpage for runghc / runhaskell" [Wishlist,New]
[13:16] <persia> effie_jayx: Put the manpage in debian/, add debian/manpage.1 (or whatever it's called) to debian/manpages (or debian/package.manpages depending on the existing packaging style).  Make sure dh_installman is being called in debian/rules.  Update the changelog.  Build a source package.  Build a binary package.  Check the binary to see if the manpage was installed correctly.  If so, generate a debdiff, attach it to the bug, and subscribe the sponsors
[13:19] <effie_jayx> the package has a manpage ... but it does not have a manpage for a specifi porgram in the package
[13:19] <persia> effie_jayx: Right.  Same procedure applies :)
[13:20] <persia> effie_jayx: More verbosely, the package likely already has dh_installman and debian/manpages, so you should be able to just add to debian/manpages to get it to work, but it's always best to check things carefully.
[13:21] <effie_jayx> there is no debian/manpages
[13:21] <effie_jayx> nor the likes
[13:21] <persia> effie_jayx: Is there any mention of manpages in debian/rules?
[13:21] <effie_jayx> ther is a docs/man
[13:22] <persia> effie_jayx: That's upstream manpages though.
[13:22] <effie_jayx> let me check
[13:22] <persia> Errr..  maybe.  Is it debian/docs/man?  Also, what does debian/rules do with docs/man?
[13:22] <effie_jayx> no
[13:23] <effie_jayx> it is upstream doc
[13:23] <effie_jayx> not in debian
[13:23] <effie_jayx> let me get you the bit that rules says
[13:24] <effie_jayx> http://pastebin.ubuntu-nl.org/46217/ <--- rules bit that mentions manpages
[13:24] <effie_jayx> this debian rules usas debhelper
[13:26] <persia> effie_jayx: That's a really annoying way for it to be done: the packager is updating files in debian/ in debian/rules.  By my reading, it should grab any section 1  manpages in debian/ and stick them in the binary package, making your edit easier.  On the other hand, I think this is broken packaging, and recommend manually creating debian/ghc6.manpages containing the suggested line to make this explicit and clear.
[13:27] <persia> For extra points, manually expand debian/*.1 to include the specific manpages to be installed.
[13:28] <effie_jayx> ok
[13:28] <effie_jayx> I haven't the expretice to do this ... is there any doc that can help me?
[13:28]  * persia looks for a second opinion that this is really broken packaging, as otherwise effie_jayx will be performing unnecessary work
[13:29] <effie_jayx> persia,  I have a knack for getting tough stuff, don't I
[13:29] <effie_jayx> ?
[13:29] <persia> effie_jayx: Other than the dh_installman man page, I don't know of any docs for how to make it work.  It's just creating a text file, and altering the rules to not overwrite the text file during the build.
[13:29] <RainCT> hi
[13:30] <persia> hey RainCT
[13:30] <effie_jayx> persia, I read the man page... and it does not tell me how to do it... it tells me the rationale behind it.. but not how it works...
[13:31] <effie_jayx> is it just me doing.... dh_installmanpage manpage.1 <sourcedirectory>?
[13:31] <persia> effie_jayx: Yeah: debhelper manpages can be opaque.  There's the source as the ultimate origin of behaviour description: it's just a perl script.
[13:31] <effie_jayx> persia,  ok
[13:31] <effie_jayx> I am checking man debhelper
[13:31] <persia> effie_jayx: dh_installmanpages is deprecated.  Please use dh_installman.  If you run it without arguments, it collects arguments from debian/package.manpages (debian/ghc6.manpages in this case)
[13:32] <effie_jayx> ok
[13:33] <effie_jayx> it was a typo
[13:34] <effie_jayx> persia,  you mentioned broken packaging...
[13:35] <effie_jayx> what should I do then...
[13:35] <persia> effie_jayx: Right.  I think it's inappropriate to alter the contents of debian/ (excepting the build directories) at build-time.  This is done by auto-generating debian/ghc6.manpages (which I believe should be a static file).  On the other hand, I don't know that this is policy: it may only be my opinion.
[13:36] <effie_jayx> I follow you opinion
[13:36] <persia> effie_jayx: For minimal adjustment, just copy your manpage to debian/ and everything should work.  If you think I'm right, you could edit debian/rules to not do that, and hand-generate debian/ghc6.manpages.
[13:38] <effie_jayx> persia,  I don't know what to put in debian rules to stop the autogeneration, is it just removing something
[13:38] <persia> effie_jayx: OK.  Are you familar with shell scripting and make files?
[13:38] <effie_jayx> no
[13:38] <persia> Hmm...  That makes it trickier then :)  Are you willing to follow a detour?
[13:39] <effie_jayx> sure
[13:39] <soren> persia: AFAIK, there's not really any policy about what may or may not happen (within reason) during the build. The policy says that debian/rules should be a makefile with a few mandatory targets, and then it says something about what the resulting deb should be like. Anything in between is grey area.
[13:39] <persia> OK.  Let me find a couple resources.
[13:39] <soren> There a conventions that new packages should uphold and such, but no actual policy afaik.
[13:39] <persia> soren: That matches my understanding of policy.  What's your opinion about debian/rules creating debhelper helper files?
[13:39] <soren> persia: Such as?
[13:40] <soren> persia: Oh, .install, .docs and such?
[13:40] <persia> soren: "echo debian/*.1 > debian/ghc6.manpages" in debian/rules
[13:40] <persia> Right.
[13:40] <soren> I might frown, but that's it.
[13:41] <persia> soren: Would you think it worth fixing if working on the package anyway?
[13:41] <soren> I wouldn't reject anything based on that. Were it a new package, I would tell the person who did it that it might cause people to be surprised, which is bad, but in itself, I don't consider it a problem.
[13:42] <soren> persia: I wouldn't carry a delta because of that, no.
[13:42] <maiatoday> as a test to try to get my head around pacaging python I tried running the setup.py install for my python package but it doesn't work due to some missing modules it seems. This has to be fixed before I can package?
[13:42] <persia> soren: Thanks for the second opinion.
[13:42] <soren> persia: any time.
[13:42] <soren> maiatoday: That's what build-depends are for.
[13:43] <soren> maiatoday: Most programs have certain requirement that need to be fulfilled for them to be able to build properly. We put them in debian/control and the various tools will make sure they're installed when we try to build the package.
[13:43] <persia> effie_jayx: Just add the manpage to debian/ and check to make sure it works, and don't attempt to fix debian/rules.  For an understanding of what echo debian/*.1 > debian/ghc6.manpages", http://steve-parker.org/sh/bourne.shtml may be helpful.
[13:44] <maiatoday> I have all build depends installed, if I run the script in the subdirectory I untarzipped it it works fine but it isn't installed in the system
[13:44] <effie_jayx> persia,  I think I can read what it does
[13:44] <maiatoday> so looking at the setup.py it seems to have some modules missing which are part of the app
[13:44] <soren> maiatoday: Oh, when you install the package afterwards, you don't get the right packages pulled in? Is that it?
[13:45] <persia> effie_jayx: Now I'm confused.  My apologies if I misinterpreted "I don't know what to put in debian rules to stop the autogeneration".
[13:45] <maiatoday> I tried doind a install from the unzipped dir before packaging
[13:45] <maiatoday> so as better to understand what the rules should be doing in the first place
[13:45] <Riddell> Hobbsee: have you poked geser about scons?
[13:45] <persia> scons is broken again ?
[13:46] <effie_jayx> persia,  mmm... ok no problem... I shall fetch another bug and lay this one to sleep
[13:46] <Hobbsee> Riddell: i did a while ago, he said OK, then did nothing
[13:46] <maiatoday> soren: so yes the not all .py modules provided by the developer are in the setup.py
[13:46] <Hobbsee> Riddell: is it poke-about-main-merges-day?
[13:47] <soren> maiatoday: Ok, that's what Depends are for :)
[13:47] <effie_jayx> jdong,  ping
[13:47] <soren> maiatoday: You need to look at the documentation of the software and see which python modules it needs and add them to debian/control under the package's "Depends:" field.
[13:48] <Riddell> Hobbsee: I'm in that sort of a mood yes
[13:48] <jdong> effie_jayx: yep?
[13:48] <Hobbsee> Riddell: i see.  well, feel free to merge scons, if you're feeling in a masochistic mood.
[13:48] <effie_jayx> jdong,  could you look at this for a sec... it is the contents for the debian/rules manpage section  http://pastebin.ubuntu-nl.org/46217/
[13:49] <effie_jayx> jdong,  how could I include my man page
[13:49] <jdong> effie_jayx: I'm about to head out to class, perhaps someone else can review for you
[13:49] <persia> effie_jayx: You just need to copy it to debian/ : it will get collected automatically (because debian/ghc6.manpages collects debian/*.1)
[13:49] <effie_jayx> ok...
[13:50] <effie_jayx> persia, but the autogeneration won't block it
[13:50] <effie_jayx> ?
[13:50] <persia> effie_jayx: Let's look at this step-by-step.  What does the autogenerated ghc6.manpages contain?
[13:51] <effie_jayx> two manpage entries... dhc and dhci
[13:51] <effie_jayx> is that what you meant?
[13:51] <maiatoday> sorry for being thick soren, I already found the depend packages for the app and added to depends, things like gnome-python etc what I am talking about is the app consist of multiple developer written .py modules and I  if I try to install it doesn't put them where the main script can see them
[13:52] <persia> maiatoday: That's a different issue.  You may have to temporarily set an alternate search path, or otherwise patch setup.py.
[13:52] <soren> maiatoday: Oh.. I guess I'm the one being thick :)
[13:52] <persia> effie_jayx: OK.  Now, how does it determine which files to list there?
[13:53] <maiatoday> Mmm  maybe this is too big a task for a first one ...
[13:53] <effie_jayx> persia,  I haven't found any .1 files nor the like... can't really tell
[13:53] <persia> effie_jayx: OK.  Looking at debian/rules again, what happens before the autogeneration?
[13:54] <effie_jayx> persia,  link to a source library?
[13:55] <persia> effie_jayx: I think you're going too far above.  Let's go through the pastbin together.
[13:55] <effie_jayx> ahh ok
[13:55] <persia> What's line 3 do?
[13:57] <effie_jayx> it takes each m (manpage??) in ghc or ghci and generates a manpage in debian/
[13:57] <effie_jayx> ?
[13:58] <persia> effie_jayx: Close enough (it actually appears to generate man links, but that's not important).
[13:58] <persia> Now, what does line 4 do?
[14:00] <effie_jayx> moves the contents in debian/tmp/usr/man/man1/ghc.1 to debian/ghc6.1
[14:00] <persia> effie_jayx: Right (creating another manpage).  How about line 5?
[14:01] <effie_jayx> copies the file in  utils/hp2ps/hp2ps.1  to debian/hp2ps-ghc6.1
[14:02] <persia> Yep (creating yet another manpage).  So, what does line 6 put in gch6.manpages (roughly)?
[14:02] <effie_jayx> it grabs all the *.1 files in debian/
[14:02] <persia> So, when dh_installman runs, what happens?
[14:04] <effie_jayx> it builds the manpages in the directory
[14:04] <persia> effie_jayx: Right.  So, if you wanted to get an extra entry into ghc6.manpages, what's the easiest way to get it there?
[14:04] <effie_jayx> leave it in debian/
[14:04] <effie_jayx> like you said
[14:04] <effie_jayx> and know I know why
[14:05] <persia> effie_jayx: Now, for the last bit: check the clean: rule.  If the manpages are being deleted, you'll need to name your manpage so as not to be deleted, and add a copy statement to the manpage collection portion.
[14:09] <persia> Does anyone know if CC-BY-SA 2.5 is GPLv2 compatible?  I know CC-BY-SA 3.0 is GPLv3 compatible, but don't remember when things changed.
[14:09] <effie_jayx> persia,  rm -f debian/*.1  in the clean section
[14:09] <effie_jayx> so no problem there
[14:10] <effie_jayx> it'll erase the manpage...
[14:10] <persia> effie_jayx: Except that it would delete your manpage if you named it debian/mymanpage.1, and so it wouldn't be there later :)
[14:11] <persia> You'll want to give it a name like executablefile.man, and then mv debian/executablefile.man debian/executablefile.1 in the manpage aggregation section.
[14:11] <effie_jayx> ok
[14:11] <geser> Riddell: you mean merging scons? see the last comment on bug #157668
[14:11] <ubotu> Launchpad bug 157668 in scons "[Merge] scons 0.97.0d20070918-1ubuntu1" [Undecided,Won't fix] https://launchpad.net/bugs/157668
[14:12] <Riddell> geser: ah hah, thanks
[14:12] <persia> geser: Is "wontfix" best?  How about "Incomplete"?
[14:13] <persia> (thinking about bug reuse for when the new upstream is available)
[14:14] <geser> persia: perhaps it's really better to set it to "Incomplete" so others can also see it
[14:14] <persia> geser: That too :)
[14:15] <effie_jayx> ok
[14:15] <effie_jayx> i am all set to begin changelog and building packages
[14:15] <geser> I hope that it doesn't get sponsored
[14:16] <persia> geser: Request a sponsor to unsubscribe in #ubuntu-devel
[14:18] <geser> dholbach: can you unsubscribe ubuntu-main-sponsors from bug #157668?
[14:18] <ubotu> Launchpad bug 157668 in scons "[Merge] scons 0.97.0d20070918-1ubuntu1" [Undecided,Incomplete] https://launchpad.net/bugs/157668
[14:18] <dholbach> geser: done
[14:34] <effie_jayx> persia,  pbuider gives me this error E: Could not satisfy build-dependency. E: pbuilder-satisfydepends failed.
[14:34] <persia> effie_jayx: OK.  Which package couldn't it find?
[14:34] <effie_jayx> persia,  W: Unable to locate package haddock
[14:35] <geser> effie_jayx: which arch are you on?
[14:35] <effie_jayx> i386
[14:35] <jdong> I think I found a bug in pbuilder-satisfydepends though I don't have time to reproduce
[14:35] <geser> effie_jayx: hardy?
[14:36] <effie_jayx> geser,  my pbuilder is updated for hardy
[14:36] <effie_jayx> yes
[14:36] <persia> effie_jayx: Odd.  I show that built for both gutsy and hardy (and up to date).  Is it a versioned dependency?
[14:36] <geser> effie_jayx: have you universe enabled inside the pbuilder?
[14:36] <effie_jayx> geser,  how could  Icheck
[14:36] <kenkku> I think I'm getting an inch closer to a package :o
[14:37] <geser> effie_jayx: the easiest way would be to login into the pbuilder and check /etc/apt/sources.list
[14:37] <jdong> soren: if you have a chance, can you confirm bug 125107 with the default Hardy pbuilder-satisfydepends variant too?
[14:37] <ubotu> Launchpad bug 125107 in pbuilder "[gutsy] pbuilder-satisfydepends-gdebi can't resolve pure virtual build-depends" [Undecided,New] https://launchpad.net/bugs/125107
[14:38] <jdong> soren: I had the default dummy variant say it can't satisfy a depends because "it's a virtual package" but the old slow method did it fine
[14:38] <persia> jdong: Some people would say that was a bug in the package, and that the package should prefer a real package, and only have the virtual package as a backup.
[14:40] <soren> persia: And I would agree with them.
[14:41] <jdong> lol ok, it's PEBKAC on my side then ;-)
[14:41] <jdong> slomo: just the man I needed....
[14:41] <persia> jdong: Perhaps not.  Last I know that was still a bug against debian policy, and hadn't been included yet.  Still :)
[14:41] <soren> Otherwise the resulting build depends on whichever implementation of the virtual package the dependency resolver chooses to go with, which is quite undefined.
[14:41] <effie_jayx> geser,  tried login in... id: cannot find name for group ID 122
[14:41] <slomo> jdong: yes? :)
[14:42] <jdong> slomo: what are your feelings on marillat's packaging of faac 1.26? I noticed back in breezy days you didn't like it?
[14:42] <jdong> slomo: I'm chasing up that wonderful dependency tree from mpeg4ip :)
[14:42] <geser> effie_jayx: shouldn't matter, you should be now root inside the pbuilder environment
[14:42] <slomo> jdong: no idea, iirc the packaging wasn't beautiful but i don't care anymore :)
[14:42] <effie_jayx> ok
[14:42] <slomo> jdong: be warned that 1.25 or 1.26 changed ABI without soname change
[14:42] <jdong> slomo: yeah I realized that'd happen
[14:43] <geser> jdong: is it still a tree or already a forest?
[14:43] <jdong> slomo: so yay I'll have to check all of faac's rdepends too :)
[14:43] <jdong> geser: this is when I hope deforestation would go faster!
[14:43] <effie_jayx> geser,  you were right... I only got main
[14:44] <jdong> slomo: ok, thanks for your time :)
[14:44] <slomo> jdong: np ;)
[14:45] <geser> effie_jayx: see https://wiki.ubuntu.com/PbuilderHowto#head-5e61fa0f52f7f2442fb20f074813bd691744460b
[14:47] <effie_jayx> geser,  it reads etch... contrib non-free ...
[14:48] <effie_jayx> I add the ubuntu sources?
[14:48] <effie_jayx> like main universe restricted multiverse?
[14:49] <geser> the important line is COMPONENTS="main restricted universe multiverse"
[14:49] <geser> I've added it to my /etc/pbuilderrc but ~/.pbuilderrc should also work
[14:51] <ScottK> maiatoday: Did you get your setup.py problem sorted out?
[14:52] <maiatoday> ScottK: not yet, I'm messing with it and I have also mailed the developer
[14:52] <ScottK> maiatoday: From reading the scrollback, it's not clear you did all the steps for a normal setup.py installation.
[14:52] <ScottK> maiatoday: First you have to run python setup.py build
[14:53] <maiatoday> aah maybe that will help me, I am also learning python, yes I did setup.py build
[14:53] <ScottK> maiatoday: Then you have to run python setup.py install.
[14:53] <maiatoday> yes that's what I did
[14:53] <ScottK> maiatoday: The install has to run as root (sudo)
[14:53] <ScottK> OK
[14:53] <ScottK> From the scrollback I missed that you'd built it.
[14:53] <maiatoday> OK I'll wipe things and try again, I didn't say so explicitly
[14:54] <maiatoday> I am reading docs on distributing python  modules at docs.python.org
[14:54] <ScottK> Also if you run python setup.py it should give you all the options you can run it with.  Perhaps something there is needed.
[14:54] <ScottK> maiatoday: Good luck.  They're a bit thin IIRC.
[14:55] <maiatoday> I have added all modules to setup.py now it feels better about the modules but it is moaning about glade and icons and there is no data_files bit in the setup.py
[14:56]  * ScottK can't help you much there as the stuff I've done doesn't use glade.
[14:56]  * maiatoday hasn't either but that's part of the fun :)
[14:58] <kenkku> where can I find information on where to put all the files?
[14:59] <kenkku> I need to find a place for the data files
[14:59] <kenkku> is there a guide on what to put where?
[15:00] <geser> !FHS
[15:00] <ubotu> An explanation of how files and directories are organized on Ubuntu, and how they can be manipulated, can be found at https://help.ubuntu.com/community/LinuxFilesystemTreeOverview
[15:00] <geser> kenkku: data files are usually below /usr/share/<packagename>
[15:00] <kenkku> geser: ok, and thanks for the link
[15:01] <kenkku> I'm starting to get this. so in the rules file I should also move the data files and documentation and so on to their correct places?
[15:01] <effie_jayx> geser,  I thought I did a pbuilder update to hardy... but I see this line in /etc/pbuilderrc   "# specifying the distribution forces the distribution on "pbuilder update" DISTRIBUTION=gutsy
[15:04] <effie_jayx> cprov-lunch,  that's mean... I am hungry and I won't get to eat for another hour and a half...
[15:05] <effie_jayx> ;)
[15:13] <effie_jayx> geser,  thanks
[15:58]  * dholbach hugs nixternal
[16:19] <bddebian> Heya gang
[16:23] <somerville32> Hiya bddebian :)
[16:23] <bddebian> Hi somerville32
[16:29] <ScottK> !logs
[16:29] <ubotu> Channel logs can be found at http://irclogs.ubuntu.com/ - Logs for LoCo channels are at http://logs.ubuntu-eu.org/freenode/
[16:34] <somerville32> Can multiverse is non-free right but does it still have to be open-source?
[16:34] <ScottK> somerville32: It has to be distributable
[16:35] <somerville32> Ok, so I can upload a binary blob in the source package and all is good?
[16:35] <ScottK> That said, most MOTUs are reluctant to add stuff there without good reason.
[16:35] <somerville32> Well, I really enjoy playing Gate88 and I'd love to share it with people, lol
[16:35] <ScottK> If it's distributable, it's allowed, but finding a MOTU willing to hold their nose and do it is another matter.
[16:51] <geser> Hi bddebian
[16:51] <bddebian> Heya geser
[17:17] <norsetto> anyone knows where is the cc meeting?
[17:17] <dholbach> #ubuntu-meeting
[17:18] <norsetto> oh right, was joining #ubuntu-meetings ;-)
[17:18] <ScottK> norsetto: I mentioned your Debian RFS to POX_ on #debian-python and he said he'd have a look at it this weekend.  You might want to hang out there (on OFTC).
[17:18] <norsetto> ScottK: sure, thanks for that
[17:19] <ScottK> norsetto: No trouble.  I'm pleased you're taking the trouble to push stuff back up into Debian.
[17:19] <norsetto> scottk: most probably debichem will take it on board too
[17:19] <nxvl_work> norsetto: the bootcd DM write to me, i have updated the bug #165030
[17:19] <ubotu> Launchpad bug 165030 in bootcd "bootcd FTBFS on hardy" [Undecided,Confirmed] https://launchpad.net/bugs/165030
[17:20] <ScottK> OK.  Well discuss it with POX_ about who should sponsor.
[17:20] <norsetto> nxvl_work: yeah, I just looked at it, seems the debdiff is against your. dsc not the ubuntu one :-)
[17:21] <LaserJock> norsetto: welcome to debichem ;-)
[17:21] <norsetto> LaserJock: heya
[17:21] <nxvl_work> oh! yes, i forget where the original one was
[17:22] <nxvl_work> making a new one
[17:22] <norsetto> LaserJock: I didn't know you were in debichem :-)
[17:22] <POX_> norsetto: how about this: gelemental in debichem and pyelemental in DPMT?
[17:22] <proppy> what is debichem ?
[17:23] <POX_> http://debichem.alioth.debian.org/
[17:23] <proppy> found it
[17:23] <nxvl_work> norsetto: done
[17:23] <proppy> hop fixed python-biopython will get into it :)
[17:23] <norsetto> POX_: the only problem is that pyelemental depends on libelemental-dev, so they have to keep a version sync
[17:24] <norsetto> POX_: if that is possible with these packages being in two teams, I have no problem of course
[17:24] <POX_> they're two separate source packages, right?
[17:25] <norsetto> POX_: yes
[17:25] <POX_> well, we can only take pyelemental so if you want to keep them together, choose debichem
[17:25] <POX_> but we know more about python then debichem ;-P
[17:26] <norsetto> POX_: I can imagine :-)
[17:28] <norsetto> POX_: can you talk with Daniel Leidert about it? If it works to have the two in two separate teams I'm for it
[17:33] <POX_> I didn't look at them yet, but if they're two separate source pacakges, I don't see a problem
[17:33] <POX_> it's up to you where do you want to keep your package
[17:33] <LaserJock> norsetto: I am indeed, although I haven't contributed all that much
[17:34] <norsetto> POX_: for me, as long as they are in Debian, I'm happy
[17:37] <nxvl_work> ScottK: why it isn't any TODO on the MOTU/Python team?
[17:37] <ScottK> nxvl_work: Because there isn't a lot of actual doing going on.  It's more of a dive in and work on what you feel like.  Also because ajmitch and I are both pretty bitter.
[17:39] <nxvl_work> mm
[17:39] <nxvl_work> ok
[17:39] <norsetto> POX_: I need to talk with Daniel anyhow tonight; I expect he doesn't particularly want to deal with a python binding package himself, in that case I'll be happy if you can consider it for your team
[17:39] <afflux> dholbach: updated the gdecrypt package to fix the issues raised by emmet: http://revu.tauware.de/details.py?upid=786
[17:39] <POX_> norsetto: your or *our* team?
[17:40] <dholbach> afflux: rock and roll - in a meeting right now, so I hope you find somebody else to look at it right now
[17:40] <POX_> norsetto: do you want to join?
[17:40] <POX_> just give me you alioth account name and read our policy
[17:40] <afflux> dholbach: okay, sorry to disturb you ;)
[17:40] <norsetto> POX_: should be norsetto_guest, let me check
[17:40] <dholbach> afflux: no problem
[17:41] <norsetto> POX_: well, norsetto-guest
[17:42] <MenZa> RainCT, congrats on the membership---impressive wikipage.
[17:42] <POX_> norsetto: I'll add you in a minute
[17:42] <norsetto> POX_: thanks
[17:43] <afflux> I'd like to get my package in universe, so could any motu please have a look at it: http://revu.tauware.de/details.py?upid=786 ? Thanks!
[17:43] <RainCT> thanks MenZa :)
[17:43]  * RainCT is overjoyed :)
[17:43] <somerville32> afflux, I'll take a look.
[17:43] <ScottK> RainCT: Congratulations.
[17:43] <afflux> somerville32, thanks
[17:44] <norsetto> congrats rainct!
[17:44] <huats> RainCT: congrats again... you deserves it... really :) (in fact I was really suprised to see you on the agenda)
[17:45] <geser> RainCT: Glückwunsch
[17:45] <geser> if you still understand some german
[17:45] <RainCT> thanks all again :D
[17:45] <RainCT> heh danke geser :)
[17:45] <RainCT> verstehen schon.. das problem ist schreiben ;)
[17:46] <MenZa> :D
[17:49] <dholbach> RainCT: now you need to start blogging on planet ubuntu about how you become a MOTU :)
[17:50] <RainCT> dholbach: heh :)
[17:50] <Kmos> RainCT is a MOTU now ?
[17:50] <RainCT> dholbach: well, I'm planning to write something about merging :)
[17:51] <RainCT> Kmos: no, Ubuntu Member
[17:51] <RainCT> Kmos: uh.. didn't you want to apply today too?
[17:51] <Kmos> RainCT: that's nice.. i don't know it was today.. but i'm not at home during the day until 11th december
[17:53] <kenkku> it is just a matter of seconds if my thing works now..
[17:54] <kenkku> yes!
[17:54] <kenkku> I managed to create a package :)
[17:55] <POX_> norsetto: you're new DPMT member, welcome :)
[17:56] <norsetto> POX_: hey thanks!
[17:56] <LaserJock> heh, that was easy
[17:56] <proppy> ahah doctor norsetto
[17:57] <kenkku> whoa, this is actually fairly easy.
[17:57] <POX_> I will be leaving office soon (10h is enough for today) and my motherboard burned so I cannot take a look at your package today
[17:57] <somerville32> Kmos, It is still on going
[17:57] <norsetto> POX_: np, let me know when you can, I'm looking forward to receive your comments
[17:57] <POX_> join #debian-python and ask there once you will svn-inject you package or wait till Saturday (I will have another computer for the weekend)
[17:57] <somerville32> Kmos, If you want a chance for your membership, get in #ubuntu-meeting
[17:58] <POX_> s/you/your
[18:00] <Kmos> somerville32: thank you very much
[18:00] <somerville32> Kmos, np :)
[18:02] <somerville32> Good luck Kmos
[18:04] <Kmos> somerville32: thanks
[18:07] <somerville32> afflux, Ok, lets go through your package
[18:09] <somerville32> +XSBC-Original-Maintainer: Kjell Braden <fnord@pentabarf.de> <-- Not needed.
[18:10] <afflux> somerville32: I think *something* complained, when I removed it, but I'm not very sure.
[18:11] <somerville32> dh_installdocs changelog.gz <-- Changelog isn't a doc :P
[18:13] <afflux> somerville32: okay, so just dh_install?
[18:13] <somerville32> I assume you added that because of Persia's statement about the upstream changelog not being installed
[18:13] <afflux> correct
[18:14] <somerville32> Use dh_installchangelogs
[18:15] <afflux> somerville32: does the changelog has to be gzip compressed then?
[18:16] <somerville32> The changelog is already gzip compressed it appears from upstream
[18:16] <somerville32> Just use dh_installchangelogs to install the changelog
[18:18] <afflux> somerville32: okay. about the original-maintainer thing: should I just ignore "dpkg-source: warning: Version number suggests Ubuntu changes, but there is no XSBC-Original-Maintainer field"?
[18:18] <somerville32> afflux, Correct.
[18:21] <afflux> somerville32: should I upload a fixed package right now?
[18:21] <somerville32> afflux, not yet. Still slowly looking at it
[18:22] <afflux> somerville32: no hurry ;)
[18:22] <LaserJock> dholbach: six months?
[18:23] <dholbach> LaserJock: hum
[18:24] <LaserJock> dholbach: sorry, Mark's comment in -meeting. It used to be 2 months of contribution
[18:25] <geser> then it has tripled since I applied for membership (it was 2 months back at that time (which is only little over a year back))
[18:25] <imbrandon> geser: same here
[18:26] <LaserJock> methinks Mark make a mistake or something
[18:27]  * somerville32 doesn't think so.
[18:27] <somerville32> afflux, There is a problem with your debian/control :)
[18:28] <geser> somerville32: do you know when it changed? I don't follow CC meetings regularly
[18:28] <somerville32> geser, No but it make sense to me that the time will be increases the project grows.
[18:28] <LaserJock> why?
[18:28] <LaserJock> if it took 2 months of sustained involvement back then it should take 2 months now
[18:29] <somerville32> Ubuntu was smaller then
[18:29] <LaserJock> why does that make a difference?
[18:29] <LaserJock> that would just be punishing people who came later
[18:29] <somerville32> Universities used to let you redo courses now they don't tend to
[18:30] <somerville32> It is the credibility of the ubuntu membership
[18:30] <geser> somerville32: afaik it's possible to become a motu in less than 6 months
[18:30] <LaserJock> that doesn't make any sense to me
[18:30] <LaserJock> 2 months for memeber, 3 months for MOTU, that should work fine
[18:30] <afflux> somerville32: what kind of problem?
[18:31] <LaserJock> if people take longer fine
[18:31] <LaserJock> but it should be doable
[18:31] <somerville32> afflux, You need a XS-Python-Version ad XB-Python-Version
[18:31] <afflux> somerville32: /usr/share/doc/python-support/README.gz line 40-42 tells different
[18:32]  * somerville32 goes to look
[18:32] <geser> XS-P-V and XB-P-V is only used by python-central, python-support doesn't need it
[18:33] <somerville32> Yea, that just started to dawn on me
[18:33] <somerville32> afflux, Looks fine to me
[18:34] <afflux> somerville32: okay, uploading
[18:34] <somerville32> I meant the source, I haven't tried building it yet
[18:35] <somerville32> Although I think pysupport is a build-dep and not a build-dep-indep
[18:36] <afflux> somerville32: that was from http://wiki.debian.org/DebianPython/NewPolicy: "Add a Build-Depends (or Build-Depends-Indep if the package is arch: all) on python-support (>= 0.5.3)."
[18:37] <somerville32> Alright. I just brought that up because p-s/README.gz had said build-dep
[18:49] <kenkku> where can I find information on how the version numbering goes in the ubuntu repositories? I can see things like package-1.0.0-0ubuntu1
[18:53] <somerville32> afflux, +1
[18:54] <somerville32> kenkku, <packagename.version>-<debian revision><ubuntu revision>
[18:54] <afflux> somerville32: thanks. It's uploaded as http://revu.tauware.de/details.py?upid=787
[18:54] <geser> kenkku: I don't rememeber if we have a page for it, but it's not difficult: -XubuntuY where X is the debian revision (0 if there is no Debian package for this package or version yet) and Y the Ubuntu revision (starting at 1)
[18:55] <effie_jayx> thepumpkin_w, sup
[18:56] <kenkku> thank you geser and somerville32
[18:57] <maiatoday> why would one choose to use python-support rather than python-central or vice versa?
[18:58] <geser> maiatoday: personal preference
[18:58] <thepumpkin_w> effie_jayx: everything is fine. i'm preparing some content.
[18:58] <maiatoday> :) thanks
[18:58] <thepumpkin_w> what about you?
[19:34] <effie_jayx> god that building is taking long
[19:34] <effie_jayx> (3 hours now)
[19:34] <Kmos> :)
[19:35] <effie_jayx> my first build :D
[19:35] <effie_jayx> I think it will work
[19:35] <effie_jayx> I have to install as well right?
[19:35] <geser> effie_jayx: what are building?
[19:35] <effie_jayx> geser,  that ghc6 packages with a manpage fix
[19:36] <effie_jayx> I would like to see if the manpage is taken correctly
[19:36] <effie_jayx> there is a script in the manpages section in debian/rules that was making really confusing the whole thing
[19:36] <effie_jayx> so I just wanna be sure
[19:37] <geser> effie_jayx: you build should finish soon (the buildds needed around 2h)
[19:37] <effie_jayx> I learned ALOT with this bug
[19:38] <geser> that's good
[19:40] <effie_jayx> thank you guys
[19:40] <effie_jayx> I feel a little less noob
[21:03] <Kmos> https://edge.launchpad.net/ubuntu/+source/gnokii
[21:03] <Kmos> someone knows why soren changed the dependency when it builds fine in hardy pbuilder ?
[21:04] <norsetto> kmos: libbluetooth2-dev is a virtual package (provided by libbluetooth-dev)
[21:05] <Kmos> so there is no reason to continue to do merge of gnokii
[21:05] <ajmitch> wasn't this just covered in -devel?
[21:05] <Kmos> ajmitch: yes.. but i want to make sure with motu's =)
[21:06] <Kmos> and because soren does an upload to hardy recently and changed again the build-depends
[21:06] <Kmos> I see that after the -devel discussion
[21:06] <ajmitch> and it's definitely a good idea to build-depend against the real package - I can't recall if it'll even work on the buildds against a virtual package
[21:07] <ajmitch> so yes, soren was right
[21:07] <Kmos> hmm..
[21:07] <Kmos> i can send it to PPA to test
[21:08] <imbrandon> ello ajmitch and norsetto
[21:08]  * imbrandon yawns
[21:09] <slangasek> ajmitch: yes, building against a virtual package has always worked; it's just wrong if the virtual package has more than one provider because you have no guarantee of which one gets picked
[21:09] <norsetto> hiya imbradon, nice color of the higher intestine
[21:09] <imbrandon> norsetto: huh?
[21:09] <ajmitch> slangasek: right, wasn't sure
[21:09] <norsetto> * imbrandon yawns
[21:09] <Kmos> slangasek: i'll test it with ppa..
[21:09] <ajmitch> hi imbrandon
[21:09] <imbrandon> ohh
[21:09] <imbrandon> lol
[21:10] <StevenK> slangasek: I am too late to fix bluez-utils?
[21:10] <slangasek> StevenK: ?
[21:10] <slangasek> StevenK: you mean for alpha-1?
[21:10] <StevenK> slangasek: Right
[21:10] <slangasek> StevenK: yes, go away :)
[21:10] <StevenK> Haha
[21:11] <imbrandon> uploads of things that arent supose to be on the cd should be "OK" in this self imposed freeze correct ?
[21:11] <slangasek> imbrandon: yes
[21:11] <imbrandon> k, just double checking
[21:11] <StevenK> slangasek: It impacts video playback for pretty much everyone, though...
[21:11] <imbrandon> StevenK: bluez-utils does ?
[21:13] <slangasek> ...
[21:13] <StevenK> imbrandon: Right, it installs a sink at too high a priority
[21:14] <imbrandon> ummm errm ok
[21:14] <StevenK> slangasek: Sorry, I'm on the phone, but trying to deal with this
[21:14] <slangasek> StevenK: the standard for alpha-1 is "can boot it, can install it, hard drive doesn't catch on fire."  I think you can see that video playback is a lower priority.
[21:15] <Kmos> StevenK: https://wiki.ubuntu.com/PackagingGuide/SupplementaryFiles -> .desktop file fails validation:
[21:15] <Kmos> StevenK: the command doesn't work
[21:15] <imbrandon> slangasek: are you the RM for all hardy also ? or just gutsy ?
[21:15] <Kmos> StevenK: or it's supposed to show only the ones that fails validation..
[21:15] <StevenK> slangasek: Okay, then I'll fix it, but not upload it
[21:15] <Kmos> and not the warnings/errors
[21:15] <slangasek> imbrandon: for hardy, yes
[21:15] <StevenK> Kmos: How doesn't it work?
[21:16] <slangasek> imbrandon: it's an open-ended employment... :)
[21:16] <imbrandon> ahhh ok, i thought you did gutsy and it was changed every release, not that i care, just curious :)
[21:16] <slangasek> imbrandon: that's not actually been the /intent/, that's just how it's worked out historically :)
[21:16] <Kmos> StevenK: forget.. i'm thinking in another type of function.. like to show the errors/warnings from desktop-file-validation
[21:16] <imbrandon> s/it/the\ RM
[21:16] <imbrandon> right
[21:16] <StevenK> Kmos: I'm a little busy right now
[21:18] <imbrandon> slangasek: rockin , well hope everything keeps going as smooth as can be :) dident realize that wasent the intent , glad to hear actualy
[21:18] <Kmos> StevenK: np =)
[21:19] <imbrandon> after one or two and the processes are smoothed i'm sure the previous experinces makes it easier
[21:19] <slangasek> one hopes. :)
[21:19]  * imbrandon gets back to the weatherreport
[21:24] <StevenK> Kmos: Now, explain the problem to me, in small words.
[21:27] <Kmos> StevenK: i thought the script was wrong.. but it reports only the files that have problems and not the output of desktop-file-validate.. there isn't a problem with it =)
[21:28]  * RainCT is still wondering why «dpkg-source -x» sometimes doesn't do anything until I Ctrl+C and try again, with Debian packages
[21:28] <StevenK> Kmos: That was the point of it.
[21:29] <Kmos> StevenK: yeah =) i understand it, thx anyway
[21:29] <Kmos> i think i change it to me to show the output =)
[21:30] <jdong> RainCT: probably a GPG related lock
[21:30] <jdong> once I've had a stale GPG lock that "broke" dpkg-source -x
[21:32] <geser> broonie: re bug #157668: the status change was done so others can see the status of it and don't try to merge it (won't fix isn't shown by default). the sponsoring team got unsubscribed from it, so there should be little danger that someone uploads it.
[21:32] <ubotu> Launchpad bug 157668 in scons "[Merge] scons 0.97.0d20070918-1ubuntu1" [Undecided,Incomplete] https://launchpad.net/bugs/157668
[21:33] <RainCT> jdong: how did you solve that?
[21:33] <jdong> RainCT: use ps to search for stale gpg processes, then if all else fails dive into ~/.gnupg deleting lock files
[21:36] <lifeless> there is a bug on evo
[21:36] <lifeless> it creates stale locks
[21:38]  * RainCT doesn't use evolution
[21:39]  * somerville32 decides to do some merges
[21:39]  * RainCT is also doing merges :)
[21:40]  * somerville32 decides to do harvestman
[21:45] <jdong> it's cheating to count myself as a verification towards my own SRU, right?
[21:45] <ScottK> jdong: Yes.
[21:45] <jdong> hehe.
[21:58] <effie_jayx> hey norsetto  that bug was jinxed... hehe
[21:58] <norsetto> effie_jayx: the man pages?
[21:58] <effie_jayx> yeh
[21:59] <effie_jayx> the man pages in debian/rules had a generating scripts for the manpages
[21:59] <norsetto> which was bugged or?
[22:01] <effie_jayx> it involved a script for generating the manpages
[22:01] <imbrandon> heya jono
[22:01] <jono> hey
[22:01] <effie_jayx> I am currently building the package
[22:02] <effie_jayx> norsetto,  whay do you say desktop bugs are Darkside?
[22:02] <norsetto> effie_jayx: just jocking with daniel
[22:03] <effie_jayx> ahhh
[22:03] <effie_jayx> but they are tougher bugs to fix I imagine
[22:05] <norsetto> effie_jayx: I wouldn't think so
[22:05] <norsetto> effie_jayx: the first bug I fixed was a desktop bug actually :-)
[22:06] <effie_jayx> mmm ... I might give it a try
[22:14] <somerville32> https://bugs.edge.launchpad.net/ubuntu/+source/harvestman/+bug/172926
[22:14] <ubotu> Launchpad bug 172926 in harvestman "Sync harvestman 1.4.6-6 from Debian unstable (main)." [Undecided,New]
[22:15] <norsetto> effie_jayx: you could do bug 158941
[22:15] <ubotu> Launchpad bug 158941 in rhythmbox "can't browse jamendo collection from rhythmbox plugin" [Medium,Triaged] https://launchpad.net/bugs/158941
[22:15] <norsetto> effie_jayx: its a patch for upstream, just needs to be debdiffed
[22:15] <RainCT> uh.. why has ebview priority "extra"?
[22:15] <RainCT> shouldn't it be optional?
[22:15] <effie_jayx> norsetto,  I'll give it a look...  thanks ...
[22:22] <effie_jayx> norsetto,  so basically I just have to build a package from that debdiff and try it out?
[22:23] <norsetto> effie_jayx: first, check if the patch from upstream correct the issue which is reported
[22:23] <effie_jayx> norsetto,  I apply the patch
[22:24] <norsetto> effie_jayx: then implement it (check if there is a patch system already, if not, add it), add a changelog entry, change maintainer (if needed)
[22:24] <norsetto> effie_jayx: its a desktop applicationa and its in main, so you have your challenge :-)
[22:25] <effie_jayx> cool
[22:26] <norsetto> effie_jayx: check if that has been fixed in debian too and remember that we fix it for hardy
[22:26] <TheMuso> nxvl_work: Lanmap fix uploaded.
[22:26] <norsetto> effie_jayx: once you are happy, do a debdiff, attach it and subscribe u-m-s
[22:27] <nxvl_work> TheMuso: thnx
[22:27]  * nxvl_work *HUGS* TheMuso
[22:30] <norsetto> TheMuso: you are looking for accessibility bugs, right?
[22:30] <effie_jayx> norsetto,  funny how I can't reproduce the bug
[22:31] <TheMuso> norsetto: If you know of any, I'll take a look, but I do my best to track all accessibility related packaes.
[22:31] <TheMuso> packages
[22:31] <norsetto> TheMuso: yes, I saw one this morning, let me check if I can find it, it was about fish :-)
[22:31] <TheMuso> norsetto: Sure
[22:32] <norsetto> TheMuso: bug 172751
[22:32] <ubotu> Launchpad bug 172751 in fish "I am visially impaired, i can't increase the font size in wanda" [Undecided,New] https://launchpad.net/bugs/172751
[22:33] <TheMuso> norsetto: Thanks. I'll have a look.
[22:33] <norsetto> effie_jayx: hmmm, so, you can't reproduce? This is bad ... there was a comment that this wasn't easy to reproduce
[22:34] <TheMuso> nxvl_work: For your latest bootcd debdiff, is having quilt in build-depends and build-depends-indep intensional?
[22:35] <nxvl_work> TheMuso: not, i made a mistake
[22:35] <nxvl_work> solving
[22:35] <TheMuso> Ok thanks.
[22:35] <effie_jayx> some funky music in jamendo :D
[22:35] <effie_jayx> better find me another bug :D
[22:36]  * effie_jayx fetches sumthing from LP
[22:36] <nxvl_work> TheMuso: fixed and uploaded
[22:37] <TheMuso> nxvl_work: Thanks.
[22:37] <nxvl_work> TheMuso: thank you for sponsoring them :D
[22:37] <TheMuso> nxvl_work: You're welcome.
[22:39] <TheMuso> nxvl_work: Have you tested this fix?
[22:39] <nxvl_work> TheMuso: yep
[22:40] <TheMuso> nxvl_work: Great.
[22:40] <nxvl_work> TheMuso: it doesn't work there?
[22:41] <TheMuso> nxvl_work: I haven't tried it. I was looking at the syntax change, and just wanted to be sure it had been tested.
[22:41] <nxvl_work> TheMuso: oh, yes it has, i make the patch and build the package
[22:41] <nxvl_work> using pbuilder
[22:41] <TheMuso> nxvl_work: BTW, don't worry about it now, but please make sure you create debdiffs between two packages in the same directory. I had to manually tell patch where to patch files when attempting to apply your latest diff.
[22:42] <RainCT> cool, I see Launchpad Janitor is again at work :P
[22:42] <nxvl_work> TheMuso: yes, i usualy do it, but in this specific case i don't know why i changed the original .dsc so i have to use another one :(
[22:43] <TheMuso> nxvl_work: Ok thats fine, just letting you know.
[22:43] <nxvl_work> TheMuso: thnx for the tip :D
[22:43] <nxvl_work> !build-queue
[22:43] <ubotu> Sorry, I don't know anything about build-queue - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[22:43] <nxvl_work> !build
[22:43] <ubotu> Compiling software from source? Read the tips at https://help.ubuntu.com/community/CompilingSoftware (But remember to search for pre-built !packages first)
[22:44] <nxvl_work> !build queue
[22:44] <ubotu> Sorry, I don't know anything about build queue - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[22:44] <nxvl_work> !launchpad-buildd-admins queue
[22:44] <nxvl_work> where is the build queue on LP?
[22:45] <StevenK> launchpad.net/ubuntu/+queue
[22:45] <TheMuso> nxvl_work: bootcd uploaded
[22:45] <nxvl_work> TheMuso: thnx again
[22:46] <nxvl_work> StevenK: it isn't there
[22:46] <StevenK> What isn't there?
[22:46] <StevenK> More context would be helpful.
[22:46] <nxvl_work> StevenK: the queue on that link
[22:46] <jpatrick> "Page not found"
[22:47] <DarkMageZ> apachelogger, have you managed to test if the fix for pm 1.0 works for you? https://sourceforge.net/forum/message.php?msg_id=4648238
[22:47] <StevenK> https://edge.launchpad.net/ubuntu/hardy/+queue
[22:47] <nxvl_work> StevenK: thnx
[22:48] <TheMuso> norsetto: Thanks for that bug, unfrotunately since it uses ncurses, nothing can be done to change font size other than use it in a GUI terminal, and change the terminal font size.
[22:48] <StevenK> That's the what's about to hit the archive, https://edge.launchpad.net/ubuntu/hardy/+builds is what's going to build next
[22:48] <TheMuso> unfrotunately
[22:49] <norsetto> TheMuso: yes, I'm contagious :-)
[22:49] <apachelogger> DarkMageZ: *trying*
[22:49] <TheMuso> ugh typing
[22:52] <apachelogger> DarkMageZ: doesn't work for me... gotta investigate tomorrow
[22:52]  * apachelogger heads off to bed
[22:52] <apachelogger> nini
[22:53] <TheMuso> RainCT: Why did you mark bug 172922 incomplete?
[22:53] <ubotu> Launchpad bug 172922 in ebview "Please merge ebview-0.3.6-3.1 from Debian unstable" [Wishlist,Incomplete] https://launchpad.net/bugs/172922
[22:54] <RainCT> TheMuso: because it's using no patch system, so the patch there isn't being applied
[22:55] <TheMuso> RainCT: Do you need helpin getting dpatch working
[22:55] <RainCT> TheMuso: I've a new debdiff where I apply that patch directly to the source ready, but I'm trying to pbuild it before I attach it
[22:55] <norsetto> ok, I better go to bed
[22:56] <RainCT> good night norsetto :)
[22:56] <TheMuso> RainCT: IMO, a patch that big should not be applied inline in the .diff.gz. A patch system is much better and safer.
[22:56] <norsetto> rainct: g'night (and listen to TheMuso :-))
[22:57] <nxvl_work> did the tribe 1 iso is somewhere to download it?
[22:57] <RainCT> nxvl_work: afaik it's not ready yet
[22:57] <RainCT> ah tribe 1
[22:58] <nxvl_work> RainCT: on the release shedule it says it will be up today
[22:58] <slangasek> https://iso.qa.stgraber.org/qatracker/build/All for anyone who'd like to help test alpha 1 ISOs
[22:58] <RainCT> is it also called tribe for hardy?
[22:58] <nxvl_work> it also called tribe for every version i think
[22:58] <effie_jayx> no
[22:58] <slangasek> no
[22:58] <imbrandon> no
[22:58] <slangasek> it's called "alpha"
[22:59] <TheMuso> Which IMO makes more sense.
[22:59] <effie_jayx> a tribe is for primates
[22:59]  * RainCT thinks that it was "herd" previously
[22:59] <imbrandon> its been alot of things
[22:59] <StevenK> It's been multiple things, it changed for every release
[22:59] <TheMuso> RainCT: You also need to resolve a conflict in src/ebview.c
[22:59] <effie_jayx> it'll be a flock again
[22:59] <effie_jayx> since it flies
[23:00] <Fujitsu> effie_jayx: No it won't, but `again'?
[23:00] <TheMuso> urm sorry you probably did that
[23:00] <imbrandon> ugh, i hate when you find usefull patches for software AFTER you just make a major update
[23:00] <nxvl_work> it was funny to see 3 "no"'s one after the other
[23:00] <effie_jayx> Fujitsu,  sorry I made a mistake ... I remember edgy being flight...
[23:00] <effie_jayx> not flock
[23:00] <effie_jayx> nooo it was dapper
[23:00] <nxvl_work> well
[23:01] <Fujitsu> Newts don't fly too well.
[23:01] <RainCT> TheMuso: Debian applied the same fix as Ubuntu there
[23:01] <RainCT> (but commenting with // instead of /* */)
[23:01] <nxvl_work> it is alpha 1 iso up there to download it or do i need to install gutsy and upgrade it?
[23:01] <TheMuso> RainCT: Right.
[23:01] <imbrandon> 17:58 < slangasek> https://iso.qa.stgraber.org/qatracker/build/All for anyone who'd like to help test alpha 1 ISOs
[23:01] <imbrandon> nxvl_work: ^^
[23:01] <somerville32> On DaD, some are marked as No need to sync. Why?
[23:01] <nxvl_work> oh!
[23:02] <RainCT> TheMuso: what's the problem then? should I note that on the bug report?
[23:02] <nxvl_work> i didn't see that
[23:02] <nxvl_work> :(
[23:02] <imbrandon> :P
[23:02] <effie_jayx> i just finished the building of the package with pbuilder... :D. what next... I install ?
[23:02] <TheMuso> RainCT: The only problem I see so far, is that there is no patch system set up to make the patch apply.
[23:03] <slangasek> nxvl_work: note that these are still the images for /testing/ prior to posting them as an alpha
[23:03] <Lutin> somerville32: usually means that the debian changes are not worth merging
[23:03] <TheMuso> Just including the patch like you did is not going to work.
[23:03] <RainCT> TheMuso: so you think it's better to add dpatch then directly patching?
[23:03] <RainCT> TheMuso: (for Debian, the bug is already reported and a link the the patch provided)
[23:03] <TheMuso> RainCT: Considering how big the patch is, and that it touches more than one file, yes I do.
[23:03] <nxvl_work> slangasek: i will install it on a VM only for testing purposes
[23:03] <RainCT> TheMuso: ok
[23:03] <TheMuso> RainCT: When is debian likely to include the patch?
[23:04] <RainCT> TheMuso: the bug report received no answer yet
[23:04] <TheMuso> RainCT: How old is the report?
[23:04] <crimsun> imbrandon: jordan, you, and barry comprise the trinity.
[23:05] <imbrandon> crimsun: ahhh okies , couldent quite rember :)
[23:05] <Kmos> RainCT: can you try to finish vips package to upload it.. so nip2 can be synced after that :-))
[23:05] <RainCT> TheMuso: 08 Nov 2007
[23:05] <TheMuso> RainCT: Ah ok, so its not that old.
[23:05] <imbrandon> crimsun: so i guess Laserjock was correct :)
[23:06] <somerville32> Lutin, Why not do it anyhow?
[23:06]  * RainCT wonders if it wouldn't be better to just sync and let the patch enter when Debian includes it, as it doesn't seem to be anything really important, TheMuso
[23:06] <TheMuso> RainCT: Well if you are up to adding the patch system and making sure the patch does apply, I'd say we go ahead, and we add a bug watch for the Debian bug, so we know when we can get it synced.
[23:06] <RainCT> TheMuso: okay then
[23:07] <RainCT> Kmos: I've that one pending :). you are not looking at it, or?
[23:07] <Kmos> RainCT: no.. just waiting for you :p
[23:07] <Lutin> somerville32: because merging for 'change my email adress' or 'orphaning this package' debian uploads is just pointless ?
[23:07] <RainCT> Kmos: okay. what was missing there? just checking if new debian version works?
[23:08] <Lutin> somerville32: or in some case, if the debian upload fixes only a part of the ubuntu changes ... no real point merging either
[23:08] <Kmos> RainCT: i need version .5 of vips to have nip2 synced.. just waiting you to finish the debdiff
[23:09] <TheMuso> RainCT: On the other hand, if you are happy to wait for the update in Debian, we'll sync then. However, if its not done in a month or so, I'd say we merge.
[23:10] <effie_jayx> after one is done building a package with pbuilder .. what does one do next? I install it?
[23:11] <TheMuso> effie_jayx: Yes, install it in the version of Ubuntu that its meant for. I would then test the fix you have applied to ensure it works.
[23:11] <effie_jayx> TheMuso,  how can I do this
[23:11] <effie_jayx> I am running gutsy and the pacage is for hardy
[23:11] <effie_jayx> package
[23:12] <effie_jayx> what do I install?
[23:12] <TheMuso> effie_jayx: You need a hardy chroot of some sort.
[23:12] <TheMuso> SOme people use pbuilder, but how they do so, I don't know.
[23:12] <effie_jayx> TheMuso,  the file I use to install... is it a .deb?
[23:13] <TheMuso> Yes it is.
[23:14] <effie_jayx> i don't see one in the folder...
[23:14] <effie_jayx> now I am confused
[23:14] <effie_jayx> TheMuso,  Thanks
[23:14] <TheMuso> effie_jayx: THe debs appear in /var/cache/pbuilder/result unless settings have been changed
[23:14] <RainCT> TheMuso: I've followed this http://www.debian.org/doc/maint-guide/ap-pkg-eg.en.html but I get «No rule to make target `clean-patched', needed by `clean'»
[23:15] <effie_jayx> ok
[23:15] <TheMuso> RainCT: You following the dpatch example?
[23:15] <RainCT> TheMuso: yep
[23:16] <TheMuso> RainCT: Actually, I would advise just reading the dpatch and dpatch.mk manpages.
[23:16] <TheMuso> Sorry, just the dpatch manpage.
[23:16] <TheMuso> ah its dpatch.make
[23:17] <TheMuso> The dpatch.make manpage gives you info on how to make use of it.
[23:20]  * RainCT is pbuilding
[23:26] <imbrandon> hrm /win 21
[23:28] <effie_jayx> I need to test a package for hardy... I am using gutsy... what can I use...
[23:29] <jdong> effie_jayx: your pbuilder as a chroot
[23:29] <jdong> i.e. the login command
[23:29] <effie_jayx> jdong,  how can I use the .deb file in that environment
[23:29] <jdong> effie_jayx: you need to set a --bindmounts /some/shared/dir and then that path will be available inside your chroot
[23:30] <effie_jayx> ok cool
[23:30] <effie_jayx> let me give it a try
[23:32] <RainCT> TheMuso: I've replaced the debdiff in bug 172922
[23:32] <ubotu> Launchpad bug 172922 in ebview "Please merge ebview-0.3.6-3.1 from Debian unstable" [Wishlist,Triaged] https://launchpad.net/bugs/172922
[23:33] <TheMuso> RainCT: Thanks.
[23:33] <effie_jayx> jdong,  where do they get mounted?
[23:33] <effie_jayx> same path?
[23:34] <nxvl_work> RAOF: ping
[23:34] <effie_jayx> jdong,  nevermind... smane path
[23:35] <RainCT> good night :)
[23:40] <RAOF> nxvl_work: Pong?
[23:41] <nxvl_work> RAOF: did you mind if i merge apt-proxy? or you want to do it?
[23:44] <effie_jayx> ok
[23:44] <effie_jayx> I tested the package
[23:44] <effie_jayx> what next
[23:45] <effie_jayx> make debdiff and upload
[23:50] <RAOF> Let's try that one again.  nxvl_work: pong?
[23:51] <somerville32> [19:40] <nxvl_work> RAOF: did you mind if i merge apt-proxy? or you want to do it?
[23:54] <effie_jayx> I just attaeched the debdiff
[23:54] <effie_jayx> https://bugs.launchpad.net/ubuntu/+source/ghc6/+bug/95985
[23:54] <ubotu> Launchpad bug 95985 in ghc6 "no manpage for runghc / runhaskell" [Wishlist,New]
[23:54] <effie_jayx> I know I have to assign the bug to someone...
[23:54] <effie_jayx> but who?
[23:55] <somerville32> No, don 't assign
[23:55] <somerville32> Is ghc6 a universe package?
[23:55] <somerville32> If so, subscribe ubuntu-universe-sponsors
[23:56] <nxvl_work> effie_jayx: at your left it is a menu entry "suscribe someone else" get in there and suscribe the ubuntu-universe-sponsors
[23:57] <nxvl_work> effie_jayx: then assign the bug to no one and change status to confirmed
[23:58] <effie_jayx> nxvl_work,  should I change importance?
[23:58] <effie_jayx> it sas wishlist
[23:59] <nxvl_work> effie_jayx: you can't
[23:59] <effie_jayx> ok
[23:59] <nxvl_work> and you don't need to change it, just leave it the way it is