[00:00]  * minghua wonder if he should make it RC or not.
[00:01] <Fujitsu> That sounds RC.
[00:02] <minghua> The thing is, all packages that use this library is from the same source package.
[00:02] <slangasek> minghua: if they're in separate binary packages, that's no excuse :)
[00:03] <mok0> minghua: RC?
[00:03] <TheMuso> release critical
[00:03] <TheMuso> afaik
[00:05] <minghua> slangasek: Right.  But only a small group of people use this package.  I doubt if I don't report, anyone else will.  And stopping the new version from migrating into testing is really worse than having this hypothetical "old version of executable segfaults with new library" issue...
[00:05] <minghua> mok0: TheMuso is correct.
[00:05] <mok0> thx
[00:05] <minghua> Anyway, enought (sort of) off-topic ranting.
[00:05] <mok0> minghua: we love rants
[00:09] <mok0> Google said: "Did you mean: dpkg-gang symbols " :-)
[00:09] <TheMuso> lol
[00:10] <Fujitsu> Haha.
[00:11] <minghua> Hmm, which policy section I should cite to justify my bug's RC status...
[00:12] <minghua> Let's just use 8.6 and a blanket.
[00:23] <mok0> minghua: have you had a chance to try out torque?
[00:28] <minghua> mok0: No.  I don't really have an cluster system to try it on, actually.
[00:29] <mok0> minghua: ah, you need at least two machines :-)
[00:29] <mok0> minghua: but the more you have, the more fun
[00:30] <mok0> minghua: anyway, I will fix the issues on REVU (all minor) and upload it again
[00:30] <mok0> minghua: It would be good to get it into hardy
[00:30] <minghua> mok0: That would be very nice.
[00:31] <minghua> mok0: You still need to persuade people about the license issue, though.
[00:31] <mok0> minghua: you think so? The most strange parts of the license have expired
[00:31] <emgent> keescook, ping
[00:32] <keescook> emgent: pong
[00:32] <emgent> keescook, weel patch is done but i have some problem with phpbb package.
[00:32] <mok0> minghua: "After December 31, 2001, only conditions 3-6 must be met"
[00:32] <minghua> mok0: Yes, I feel it's good for universe, but I'm no license expert.
[00:32] <emgent> keescook, http://rafb.net/p/5MIUqV62.html
[00:33] <mok0> minghua: neither am I
[00:33] <minghua> mok0: And my opinion hardly matters.
[00:33] <keescook> emgent: I'd communicate with upstream first, and once there is an approved upstream patch, then worry about package builds.
[00:33] <mok0> minghua: but there must be somebody who can make a qualified decision?
[00:33] <emgent> ok cool.
[00:33] <mok0> minghua: perhaps an Ubuntu member?
[00:34] <emgent> i go to mail phpbb's people
[00:37] <minghua> mok0: An archive admin, usually.
[00:38] <mok0> minghua: perhaps I can ping one and discuss it
[00:38]  * minghua doesn't think it's a good idea.
[00:38] <mok0> why?
[00:40] <minghua> They are busy, and they may not be acting archive admin duty today.
[00:41] <minghua> Just IMHO anyway, feel free to ping one if you want.
[00:44] <mok0> minghua: It's probably better to get the package in good shape, and get it processed the normal way.
[00:49] <minghua> mok0: Yes, that's my preference.  You can always ask an archive admin to review the license before uploading (or once it's in NEW queue).
[00:49] <mok0> minghua: great.
[00:50] <minghua> mok0: By the way, "Ubuntu member" is a group with very low threshold: https://launchpad.net/~ubuntumembers
[00:50] <minghua> mok0: You can become one if you want.
[00:50] <mok0> minghua: Ah, i thought that was the exclusive group of canonical employees
[00:51]  * minghua thinks that group is simply called "Canonical employees". :-P
[00:52] <mok0> mok0: minghua; heh, I will try to join the ubuntu-member team, then
[00:53] <mok0> 352 active members, 852 proposed members :-)
[00:53] <emgent> lol
[00:53] <emgent> mok0, good luke :P
[00:53] <mok0> emgent: thanks I need it :-/
[00:53] <emgent> i will try to motu
[00:54] <mok0> me too
[00:54] <emgent> motu include ubuntumembers
[00:55] <emgent> mok0, I think that is good Continue on this road
[00:55] <mok0> emgent: by the time the team adminstrators get through the list of 852 applicants, I will be a developer, lol
[00:55] <emgent> ahahahaha
[00:55]  * emgent nod
[00:56] <pochu> mok0: that's handled differently. You need to present your application to the Community Council, and they will either approve you or not.
[00:56] <mok0> pochu: yes I know, just kidding
[00:56] <emgent> but in this council meeting there are news about approvation
[00:56] <pochu> mok0: heh, ok :)
[00:57] <mok0> pochu: I plan to submit my motu-application later this spring
[00:57] <pochu> Good luck! :)
[00:57] <mok0> pochu: heh, thanks
[00:57] <mok0> pochu: it takes more hard work than luck I'm afraid
[00:58] <emgent> mok0, https://wiki.ubuntu.com/CommunityCouncil/Delegation
[00:58] <pochu> mok0: You're afraid? That's a good thing!
[00:58] <emgent> fast procedure
[00:59] <mok0> pochu: nothing to motivate like fear
[00:59] <emgent> dholbach++
[00:59]  * pochu goes to study
[01:00] <emgent> bye pochu
[01:00] <mok0> bye
[01:35] <owh> Hiya, I'm trying to make a .deb with checkinstall for vmware-tools so I don't have to install the build-deps on a JEOS. I don't suppose anyone has already succeeded in doing that?
[01:36] <Hobbsee> checkinstall is not supported in here.
[01:36] <StevenK> Hopefully, it isn't supported anywhere, but that isn't likely.
[01:37] <owh> StevenK: Is there a better way?
[01:37] <Hobbsee> StevenK: well, you were the one who stopped it segfaulting.
[01:37] <StevenK> owh: There is, but I've not managed to get vmware-tools packaged sanely.
[01:38] <StevenK> It makes lovely assumptions, and fails if builder != host
[01:38] <StevenK> If I recall correctly, it's been a while since I looked.
[01:38] <owh> Ah, niiice :|
[01:39] <owh> So, I get to install the build-deps, mount the .iso, extract the .gz, build it, delete the extracted dir, unmount the .iso and purge the build-deps?
[01:39] <jdong> owh: the tools do a bit of host-specific kernel module compilation too so checkinstall will also NOT be able to deal with it
[01:40] <jdong> owh: it's going to be complex to repackage and it might not even be legal for us to mangle their sources in this fashion
[01:40] <owh> All I really care about is that I can sanely shutdown a vm-guest, don't care about anything else.
[01:40] <Hobbsee> jdong: who said anything about us building it?
[01:40] <StevenK> What Hobbsee said.
[01:41] <owh> As opposed to powering it down :)
[01:41]  * Hobbsee notes one can do that with virtualbox with no problem
[01:41] <jdong> Hobbsee: checkinstall implies it. I'm just giving another reason why checkinstall will fail miserably in this application
[01:41] <owh> jdong: We're talking about the guest tools here, not the server tools right?
[01:42] <owh> Hobbsee: Yes, but then I'd have to deploy a whole new range of tools and given where I am right now, that's not an option :_(
[01:42] <jdong> owh: right, the guest tools
[01:42] <owh> jdong: I didn't see any kernel module stuff going on.
[01:42] <Hobbsee> owh: ah right
[01:42] <jdong> owh: I could've sworn there's kernel modules involved...
[01:43] <jdong> owh: maybe I'm wrong and it's just binary Xorg drivers
[01:43] <Hobbsee> jdong: sure you're not confused with virtualbox?  that has kernel modules
[01:43] <jdong> owh: do the terms of licensing permit repackaging?
[01:43] <owh> jdong: AFAIK that's the vmmon/vmnet stuff for the server. Could be the X stuff.
[01:43] <jdong> Hobbsee: no, I was thinking of some redhat clients I deployed last summer
[01:43] <owh> jdong: Dunno, this is in-house between guests on one server.
[01:43] <Hobbsee> jdong: ahhh
[01:44] <jdong> owh: why can't you just install linux-headers-generic build-essential and proceed from there?
[01:44] <jdong> I don't see why it has to be rolled into an awful deb package
[01:45] <owh> jdong: I can, but I'm trying to keep my jeos deployment simple. If I need to build a vm, then install depends, extract stuff, compile and remove things, my 4 minute automatic new machine deployment becomes a manual nightmare.
[01:45] <jdong> owh: why not deploy the systems as tarballs of preconfigured systems?
[01:45] <jdong> owh: or other forms of image cloning.... I don't see how deb packages would even simplify your life :)
[01:46] <jdong> owh: or modify the install script (perl) to automatically apt-get the dependencies and remove them afterwards
[01:46] <owh> jdong: Because deploying tarballs makes maintaining the tarball a manual mess.
[01:46] <jdong> I think you'll waste more time trying to package the tools sanely compared to just rolling it out
[01:46] <owh> jdong: Modifying the perl script is an idea.
[01:47] <owh> Sigh, so much to do and so much time being wasted in mundania :(
[01:47] <jdong> you will need a custom package of some sort. A custom deb package you have to craft vs modifing a perl script and re-rolling the tools tarball?
[01:47] <jdong> I think the latter is much much easier
[01:47] <owh> jdong: Thanks for your thoughts, I'll take a break and have another look at it.
[01:48] <jdong> owh: sure thing, good luck :)
[01:48] <owh> :)
[02:04] <bddebian> Heya gang
[02:05] <RAOF> Aloha bddebian.
[02:05] <bddebian> Hi RAOF
[02:13] <TheMuso> Ok it built.
[02:13] <TheMuso> Now to disect the debs.
[02:13] <TheMuso> woops wrong channel
[02:18] <jdong> TheMuso: I think you mean dissect. I'm pretty sure disecting involves cutting in half....
[02:18] <jdong> TheMuso: though if they were automatix debs...
[02:19] <TheMuso> jdong: Whatver. :p Basically pulling them appart.
[02:19] <StevenK> dict doesn't know about disect
[02:19] <TheMuso> Well my typing hasn't been the best on this keyboard lately. I think it needs replacing.
[02:39] <RAOF_> Yay, cool.  Looks like monodevelop can be sync'd soon.
[02:45] <jdong> RAOF_: yay!
[02:47] <jdong> is there a LP dgettable URL that's aliased to the latest version of source package foo for distro bar?
[02:47] <jdong> or am I still gonna have to regex-scrape for that? *grumble*
[02:57] <Fujitsu> jdong: There isn't one for the latest, but one can add /+files on the end of any SourcePackageRelease URL to get dgettable .dsc.
[02:58] <jdong> Fujitsu: mmmkay I'll just navigate to $release/+source/pkgname and scrape for a dsc to dget :)
[03:33] <bddebian> Can I regexp the search expression in grep?  I want to find every instance of SDL_*.h  ?
[03:34] <StevenK> That's a glob, not a regex
[03:35] <lifeless> its a regex
[03:35] <bddebian> OK, can I use globs then? :)
[03:35] <lifeless> but the regex won't do what you want :)
[03:35] <StevenK> Oh right.
[03:35] <ion_> Unless you want to find e.g. SDL.h and SDL____________________________________.h :-)
[03:35] <lifeless> and SDLKh
[03:35] <ion_> Oh, and SDL__Xh
[03:35] <StevenK> bddebian: grep -E 'SDL_[A-Za-z]*.h
[03:36] <StevenK> '
[03:36] <bddebian> OK, OK, I get it, how can I do it.. Sheesh :)
[03:36] <bddebian> Ah, thx StevenK
[03:36] <lifeless> egrep 'SDL_[\w]+\.h'
[03:36]  * StevenK recommends bddebian actually read grep(1)
[03:36] <lifeless> perhaps
[03:37] <ion_> No need to put [] around \w
[03:37] <lifeless> bleh true
[03:37] <bddebian> StevenK: Well I knew I could, I just completely suck at regexp :-(
[03:37] <lifeless> actrually, 'SDL_.+\.h' is really what is wanted
[03:38] <ion_> Also, to avoid matching fooSDL_bar.hz, add \< \> around the expression.
[03:39] <StevenK>  399 files changed, 26415 insertions(+), 107889 deletions(-)
[03:39]  * StevenK sobs
[03:39] <ion_> Hehe. What is that?
[03:40] <StevenK> A diff between two Pidgin trees
[03:42] <Fujitsu> StevenK: Is that a micro-release?
[03:42] <StevenK> Nope.
[03:42] <Fujitsu> Ah. Boring then.
[03:50] <emgent> morning *
[04:01] <bddebian> Goddamnit, why does adonthell have it's own SDL headers.. Grrr
[04:52] <ScottK> StevenK: Still around?
[05:09] <StevenK> ScottK: I might be.
[05:10] <ScottK> StevenK: I need a core-dev to do a source backport for clamav to close a remote execution vulnterability.  It's a small change.  Would you be up for an upload in ~20/30 minutes after I'm done testing?
[05:15] <StevenK> ScottK: I could be convinced.
[05:15] <ScottK> OK.
[05:15]  * ScottK will finish testing and then work on convincing.
[05:16] <bddebian> heh
[05:23] <StevenK> You have: 900000000000000 seconds
[05:23] <StevenK> You want: millennia
[05:23] <StevenK>         * 28519.888
[05:23] <StevenK> I don't think so, dmb
[05:24] <dmb> lol
[05:28] <emgent> hahaha
[05:30] <ScottK> StevenK: The debdiff (from the current version in gutsy-security) for feisty-backports is in Bug #181830.
[05:30] <ubotu> Launchpad bug 181830 in feisty-backports "CVE-2007-6337 Unknown impact remote attack" [Undecided,Confirmed] https://launchpad.net/bugs/181830
[05:31] <ScottK> StevenK: Would you please be so kind as to upload that?
[05:47] <dholbach> good morning
[05:48] <TheMuso> Hey dholbach.
[05:48] <ScottK> Good mornging dholbach.
[05:48] <ScottK> morning even
[05:49] <dholbach> hey TheMuso, hey ScottK!
[05:49] <dholbach> how are you doing?
[05:49] <ScottK> dholbach: The other MC members +1'ed \sh while you were out, so you can give him a nice birthday present today.
[05:49] <emgent> morning dholbach :)
[05:49] <dholbach> ScottK: working on it
[05:49] <dholbach> hey emgent
[05:49] <ScottK> Cool
[05:50] <emgent> Rock and Roll! (an beer)
[05:50] <emgent> heheh
[05:50] <ScottK> Good night all.  I'm off to bed.
[05:50] <dholbach> sleep tight!
[05:50] <emgent> ScottK, see you later
[05:52] <ScottK> \sh_away: Congratulations and Happy Birthday.
[05:53] <ScottK> Good night again.  This time really.
[05:53] <dholbach> \sh_away: and the same from me - and welcome back to the team :)
[05:54] <TheMuso> dholbach: I'm great thanks.
[07:25] <TheMuso> p/c
[07:25] <TheMuso> ugh
[07:27] <AnAnt> hello, how do I make a patch for a diff.gz ?
[07:27] <AnAnt> I mean a diff between 2 diff.gz files
[07:28] <Chipzz> apologies if this is off-topic, but can anyone check if sourceforge cvs is broken? I'm getting "cvs [checkout aborted]: connect to cvs.sourceforge.net(66.35.250.207):2401 failed: No route to host" on 2 different hosts...
[07:28] <StevenK> AnAnt: gunzip them and then interdiff them
[07:28] <josesanch> Hello. I have uploaded a package to revu and I'm wondering if i made any mistake beause the package is not comment by anyone
[07:28] <AnAnt> ok
[07:28] <josesanch> The name of package is gnomecatalog
[07:29] <StevenK> Chipzz: telnet: Unable to connect to remote host: No route to host
[07:29] <AnAnt> Chipzz: aren't they phasing out CVS in favor of SVN ?
[07:29] <Chipzz> AnAnt: no idea really...
[07:30] <Chipzz> the weird thing is
[07:30] <Chipzz> tcptraceroute 66.35.250.207 2401 actually *does* work
[07:31] <AnAnt> wierd
[07:31] <Chipzz> StevenK: thx, same as I was getting apparently
[07:31] <AnAnt> svn isn't working even
[07:32] <Chipzz> what I was actually trying to do is checkout the cvs version of gitk
[07:33] <Chipzz> because I was wondering if there was a reason we ship the tcl/tk version when gitk cvs has a gtk+ front-end
[07:33] <Chipzz> (was going to look into what version gitk cvs was etc...)
[07:34] <Chipzz> hrrrrm
[07:34]  * Chipzz slaps self
[07:36] <Chipzz> ignore what I just said
[08:06] <lucas> Fujitsu: could you please enable a "Ruby-related packages" list on http://qa.ubuntuwire.com/~fujitsu/mdt/?
[08:07] <man-di> Fujitsu: and a "Java-related packages" list...
[08:08] <lucas> Fujitsu: listing all packages that have binary packages that (indirectly) depends on libruby1.8 or libruby1.9 would be enough
[08:13] <Fujitsu> man-di: How would I determine that?
[08:13] <Fujitsu> lucas: Doing so.
[08:13] <josesanch> Hello. I have uploaded a package /to revu and I'm wondering if i made any mistake beacuse the package is not comment by anyone. The package is http://revu.tauware.de/details.py?package=gnomecatalog
[08:16] <amarillion> josesanch, no mistake... I'm too waiting for someone to review my package
[08:16] <amarillion> this one btw: http://revu.tauware.de/details.py?package=speed-game
[08:16] <josesanch> amarillion Thanks. I'm a newbie in this
[08:17] <amarillion> me too :)
[08:17] <amarillion> But it seems that it takes a while to get your package reviewed
[08:22] <Fujitsu> lucas: That's a lot of packages.
[08:24] <lucas> Fujitsu: a few hundreds, no?
[08:25] <amarillion> josesanch, I'm looking at your package right now
[08:25] <Fujitsu> lucas: The recursive rdepends of libruby1.8 are enormous.
[08:25] <amarillion> is it in Debian already?
[08:25] <josesanch> No, is not in debian.
[08:25] <amarillion> ok, then you need to use 0ubuntu1 as package version number
[08:25] <josesanch> ahh.
[08:26] <amarillion> Also, is this a native package? I don't see an orig.tar.gz
[08:26] <amarillion> You can ignore the linda error: gnomecatalog; 3.7.3 is a newer Standards-Version.
[08:26] <amarillion> everyone is getting that
[08:26] <amarillion> But you definitely need to fix this one: E: gnomecatalog_0.3.1-1.2_source.changes: bad-distribution-in-changes-file hardy
[08:27] <josesanch> amarillion gnomecatalog-0.3.1-0ubuntu1 ?
[08:27] <amarillion> I suspect that it goes away once you use "ubuntu" in the version number
[08:27] <josesanch> Ahhh..
[08:27] <amarillion> josesanch, exactly. Whenever gnomecatelog is added to debian, it will get gnomecatalog-0.3.1-1 which is higher than 0.3.1-0
[08:28] <amarillion> so it will be automatically overriden when added to debian
[08:28] <josesanch> I don't know why then orig.tar.gz is not there
[08:28] <josesanch> It must be there
[08:28] <josesanch> :)
[08:28] <josesanch> Well, it looks like i have work todo with the package
[08:28] <amarillion> Did you package with debuild -S -sa
[08:28] <amarillion> ?
[08:28] <josesanch> Yes, i think so
[08:28] <huats> morning dears motus
[08:29] <amarillion> oh then I don't know why that is happening
[08:29] <amarillion> hi huats
[08:29] <josesanch> I'll make the chages you comment me and will submit again
[08:30] <amarillion> josesanch, ok, good luck
[08:31] <josesanch> amarillion Thanks a lot
[08:31] <josesanch> I will be back :)
[08:32] <huats> nxvl: ping
[08:34] <man-di> Fujitsu: a good start would be to look in Maintainer and XSBC-Original-Maintainer for "Debian Java"
[08:34] <man-di> Fujitsu: that doesnt find all of them as some are not maintained by debian java team
[08:35] <man-di> Fujitsu: in debian you can search the tags for "lang:java" but I dont know if Ubuntu has that tagging yet too
[08:36] <Fujitsu> GOod point. Anybody know why we don't have such tags?
[09:15] <\sh> moins
[09:15] <\sh> and THANKS A LOT good to be back :)
[09:40] <\sh> was someone working on the final debdiffs from che regarding the libgif transitions?
[09:42] <TheMuso> \sh: Congratulations! Great to have ou back!
[09:43] <\sh> TheMuso: thx :)
[09:45] <\sh> cool....all my libgif stuff uploaded...
[09:46] <\sh> thx dholbach
[09:51] <persia> StevenK: AnAnt: interdiff has a -z option to save on the unpack.
[09:51] <StevenK> Aww
[09:52]  * StevenK will have to remember that
[09:52] <persia> Fujitsu: If you're updating mdt feeds, could you also look at the links on the main mdt page?  Some of them seem odd.
[10:03] <josesanch> amarillion. I have uploaded a new version, now with orig.tar.gz
[10:08]  * rzr fixed http://revu.tauware.de/details.py?package=jaaa
[10:11] <amarillion> josesanch, yeah. looks better
[10:11] <persia> rzr: Could you do a quick bounce of -0ubuntu1 in preference to -1ubuntu1?  I'd be happy to take a look, but know that needs to be fixed before even digging in.
[10:11] <amarillion> btw, my package speed-game (http://revu.tauware.de/details.py?package=speed-game) has been fixed too
[10:12]  * josesanch fixed http://revu.tauware.de/details.py?package=gnomecatalog
[10:14] <rzr> persia: sure
[10:15]  * persia recommends that josesanch review speed-game whilst amarillion reviews gnomecatalog.  persia will review whichever one of the packages that escapes unscathed
[10:15] <amarillion> hehe, so I have to find a fault in gnomecatalog otherwise you won't review my package?
[10:16] <amarillion> dirty tricks...
[10:16] <amarillion> well, let me take a look then
[10:16] <persia> amarillion: Something like that.  I like to think of it as an incentive for collaboration :)
[10:17] <josesanch> persia: Ok.. i am going to review it right now
[10:18] <persia> Excellent!  The game is on...
[10:18] <amarillion> btw I already did one quick review of gnome-catalog earlier. Just so you know that I really am willing to help out.
[10:19] <persia> amarillion: I don't doubt it.  Few without that attitude come here :)  I just only feel like a couple reviews this evening, and so proposed this to pick the second of them.
[10:20] <amarillion> It's actually not a bad way to go about this. A little machiavellian... but with good results.
[10:21] <persia> superm1: I don't suppose I could convince you to move more of the mythbuntu packages to multiverse to make debcheck happy, could I?
[10:24] <Ng> if some kind soul would care to look over http://revu.tauware.de/details.py?upid=1212 I believe I have addressed all of the comments now :)
[10:24]  * persia wonders if anyone would like to pair with Ng
[10:24] <StevenK> Ah. A clue to find more.
[10:24] <josesanch> amarillion: the game is very cool
[10:24] <rzr> persia: well I have this warning "Description: The menu file has section Applications, which is unknown."
[10:25] <josesanch> it has two warning that have mine package too  Maintainer: does not have Ubuntu address and there is no XSBC-Original-Maintainer field
[10:25] <persia> rzr: That's because revu isn't using the newest lintian (I suspect).  Check again against lintian 1.23.41
[10:26] <rzr> /exec -o lintian --version
[10:26] <rzr> Lintian v1.23.41
[10:26] <rzr> on my system ..
[10:26] <rzr> debian tough
[10:27] <persia> Uploads unique to Ubuntu should have an @ubuntu.com maintainer.  You can assign maintenance to the MOTU team with Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com> (but we like XSBC-Original-Maintainer when assigned maintenance, and appreciate help)
[10:27] <persia> josesanch: Maybe it needs to be Applications/Something?
[10:27] <DaveMorris> I don't suppose there is a google calender version of the gutsy release schedule, I see there is a iCal version
[10:27] <DaveMorris> s/gutsy/hardy
[10:27] <rzr> grep section  debian/jaaa.menu
[10:27] <rzr>  section="Applications/Sound"\
[10:28] <josesanch> persia: application/accesories
[10:28] <persia> josesanch: s/Application/Applications/, I suspect.
[10:28] <amarillion> josesanch, thanks, I didn't write it myself
[10:29] <josesanch> thanks persia i'm going to do that changes
[10:29] <promag> persia: do you know how can I make a custom automake rule available system wide?
[10:30] <persia> promag: No.  Also, why me?  Also, why #ubuntu-motu?  Also, why would that even be interesting?
[10:31] <persia> rzr: Umm.  I asked for "0.4.2-1ubuntu1" -> "0.4.2-0ubuntu1".  The new candidate is "0.4.2-1ubuntu2".
[10:32] <promag> why you? because you're a nice person :P why #ubuntu-motu? becase #devtools is like a dead channel and because here are intelligent ppl... and it would be interesting to me :)
[10:32] <rzr> it's because of the distortion in the channel :)
[10:33] <rzr> sorry
[10:33] <persia> Aha.  Always be sure the communication channels are at right angles to the power channels, and you'll be safe.
[10:33] <rzr> now I open my eyes :)
[10:34] <rzr> let me fix this
[10:34] <persia> rzr: Oh, goot catch on the security issue.  -13 looks much nicer :)
[10:34] <rzr> yea
[10:35] <rzr> I waited it to enter testing to comment the bug
[10:35] <rzr> i wanted to wait ..
[10:36] <josesanch> persia: in what file have to change application by applications/ ?
[10:36] <persia> josesanch: menu
[10:36] <rzr> josesanch: w/ a "A"
[10:37] <rzr> persia: should I also upload whitedune to revu ?
[10:37] <josesanch> section is now Apps/Tools i have to change by Applications/Tools?
[10:37] <persia> rzr: Isn't that in Debian?
[10:38] <rzr> it is
[10:38] <rzr> I did the job
[10:38] <persia> josesanch: Right.  There was a policy change between gutsy and hardy for menu structure.
[10:38] <persia> rzr: I thought I remembered a sync request.  No need to send to REVU.
[10:38] <rzr> ok
[10:39] <rzr> anyway my priority is on jaaa, and will be unicorn before whitedune
[10:39] <persia> rzr: Just watch the sync request, and make sure it gets synced in the next couple weeks, or it likely won't make hardy.
[10:41] <amarillion> Hey josesanch, I get a few lintian errors when I try to build your package
[10:41] <amarillion> e.g E: gnomecatalog: extended-description-is-empty
[10:42] <amarillion> and E: gnomecatalog: copyright-should-refer-to-common-license-file-for-gpl
[10:42] <amarillion> for the last one you can simply refer to /usr/share/common-licenses/GPL3
[10:42] <josesanch> amarillion: Thanks, i'll to review that
[10:43] <persia> jdong: s/disect/bisect/
[10:47] <rulus> how long does it take for an uploaded package to appear on the REVU website?
[10:47] <amarillion> rulus, a few minutes usually
[10:47] <rulus> ah, thanks :)
[10:47] <persia> rulus: between 2 and 12 minutes.
[10:47] <amarillion> provided that your GPG key is added to the revu list
[10:48] <amarillion> I had that problem a few days ago
[10:48] <rulus> I think it is, dput said that the upload was succesfull
[10:49] <amarillion> it depends on when you subscribed to the Universe contributors team
[10:49] <rulus> I am
[10:49] <rulus> :)
[10:50] <rulus> already a few weeks, so that should be not problem
[10:51] <persia> rzr: jaaa commented.
[10:51] <persia> amarillion: josesanch: did either of your packages survive?
[10:52] <amarillion> I'm making a new one with the Maintainer set to the motu list
[10:52] <rzr> persia: > I like ALL_CAPS for make variables.
[10:52] <amarillion> then I can set XBC-Original-Maintainer set to me right?
[10:52] <LucidFox> inkblot, which passed REVU, was rejected on the grounds that it lacked the text of the LGPL for eggtrayicon.{c,h}. I was asked to repackage the orig.tar.gz and add it. Now here's the question:
[10:53] <rzr> persia: UPCASE_VAR are for conventional vars ... locase_one are for private usage
[10:53] <LucidFox> If it's "LGPL 2 or later", which version should I add - 2, 2.1 or 3?
[10:53] <amarillion> s/XBC/XSBC/
[10:53] <rzr> FYI, I've read that somewhere on the wide internet :)
[10:53] <persia> rzr: Depends on how one defines "private" :)
[10:54] <persia> LucidFox: Depends on how you want to license it to others (based on the license you received).  -2 grants your endusers (the distribution, and it's users) the most flexibility.
[10:54] <rzr> for me private refer to something isnt wrote on some public paper ..
[10:54] <amarillion> persia, can I ignore this: warning, `debian/speed-game/DEBIAN/control' contains user-defined field `Original-Maintainer'?
[10:55] <persia> amarillion: Yes.  I thiought that was taken away for -XubuntuY.  Hrm.
[10:55] <LucidFox> The license headers mention "Lesser GPL 2 or later", but version 2 is called "Library GPL" - it was renamed to Lesser in version 2.1. Does this affect anything?
[10:56] <amarillion> josesanch, did you find more problems with my package?
[10:56] <persia> LucidFox: That might deserve clarification with upstream.  If there is no "Lesser GPL 2", then you may not have a good guide as to what license you received, which may impact your ability to extend a license to Ubuntu.
[10:57] <josesanch> No..
[10:57] <josesanch> But i'am not an expert :)
[10:57]  * persia notes that this technicality of the packager providing the license to the distribution, which the distribution then uses to provide licenses to end-users is why having the name of the original packager in debian/copyright is useful.  This doesn't apply in all jurisdictions of course...
[10:58] <LucidFox> But the author of inkblot is not the author of eggtrayicon. It's found in many sources.
[10:58] <persia> josesanch: Don't worry that you're not an expert.  I learned half of what I know about reviewing from lintian and linda.
[10:58] <josesanch> jejeje
[10:59] <amarillion> this reminds me: persia, why did you suggest the ISC license earlier?
[10:59] <persia> LucidFox: In that case, it may be that the author of inkblot needs clarification regarding the license extended to you.  Such recursion may be even more levels, depending.  This is why precision in licensing is important.
[10:59] <rulus> amarillion, persia: it has appeared :)
[10:59] <amarillion> When I needed to add the text, I couldn't find a good source for it
[10:59] <amarillion> ISC doesn't seem to be very well documented
[10:59] <persia> amarillion: For people without an existing relationship with the Regents of the University of California, it's easier to use than BSD.
[11:00] <persia> amarillion: The full license is three paragraphs, quoted entire in the wikipedia entry.
[11:00] <amarillion> Well... I couldn't find exactly how to do it so I just copied the text from the dhcp package
[11:00] <LucidFox> Now looking at the rhythmbox source, and it only includes the text of the GPL, even though it also includes eggtrayicon.{c,h}
[11:00] <persia> amarillion: Also, I don't recommend ISC as a blanket license.  It's not right for everyone.  I just think it's a better choice when people are considering a BSD license.
[11:01] <amarillion> It's just that after googling I found this: http://ictlab.tyict.vtc.edu.hk/pub/tarball/dhcp-3.0b2pl3/ISC-LICENSE which confuses me. It's a lot more text
[11:01] <persia> LucidFox: Write up your research, and forward it with your rejection note to cjwatson.  A test case was sought earlier on this.
[11:01] <josesanch> persia: from lintian i don't have warnings but for linda i have a 3.7.3 is a newer standards-version
[11:02] <amarillion> There doesn't seem to be documentation from the ISC itself
[11:02] <persia> amarillion: When I say "ISC license", I mean that listed at http://en.wikipedia.org/wiki/ISC_licence
[11:02] <amarillion> ok
[11:02] <amarillion> but I don't think you should recommend that one over BSD
[11:02] <amarillion> not anymore
[11:02] <amarillion> it's too unclear
[11:03] <persia> josesanch: linda is currently experiencing the bends (issues with decompression), and has not yet become aware of the new standards version.
[11:04] <persia> amarillion: The "BSD" license requires copyright assignment to the Regents of the University of California, which is not even possible in many jurisdictions.  I think using ISC is preferable to drafting a new license based on the BSD license.
[11:04] <persia> Also, I don't see what is unclear.  It states who holds copyright, what the licensee is entitled to do with the work, and provides a disclaimer of liability.
[11:07] <amarillion> The text on wikipedia is very clear. To me, what is unclear is: who is the ISC? Why is it a good idea to use their text when almost nobody else uses it? Which text do I use exactly (you didn't refer to the wikipedia entry explicitly before, and just googling for ISC license comes up with contradictory results)
[11:08] <LucidFox> mpeg4ip rejected again? Nnnnnoooooo
[11:10] <persia> amarillion: Internet Systems Consortium.  (#2 in Google for "ISC"), and the wikipedia entry is #1 in Google for "ISC license".  It's used by heaps of stuff, but it is fairly new, so there's not so much talk about it, and a lot of people consider it a "modified BSD", so it falls into the "BSD-style" licenses in many discussions.
[11:10]  * persia grumbles at ISC for being "Internet Systems Consortium" and "Internet Software Consortium" both housed at isc.org :(
[11:11] <verb3k> guys what's the easiest ubuntu packaging guide? (not MOTU  guide)
[11:11] <emgent> sure
[11:11] <emgent> wait
[11:12] <persia> !packaging | verb3k
[11:12] <ubotu> verb3k: The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
[11:12] <emgent> http://doc.ubuntu.com/ubuntu/packagingguide/C/
[11:12] <emgent> persia++
[11:12] <verb3k> emgent, thank you :)
[11:12] <persia> emgent: That's a little outdated (although the one ubotu provided is WIP).
[11:13] <emgent> persia, ok cool.
[11:14] <verb3k> persia, so I should use the one supplied by ubotu ?
[11:15] <persia> verb3k: Both work to get started.  One is in-process, so may have gaps or unclear portions.  The other is old, and so may have inaccuracies or recommend deprecated processes.  Either can be a useful introduction.
[11:16] <verb3k> persia, I see, thanks for your help and time
[11:16] <ChrisGibbs> !info initramfs
[11:16] <ubotu> Package initramfs does not exist in gutsy
[11:16] <persia> Note also that we're about 4 weeks from feature freeze, so the chances of a brand new candidate getting into the hardy archives are fast narrowing (especially for those just learning packaging).  Don't get discouraged if we hit the freeze, and the package is delayed until hardy+1.
[11:16] <persia> ChrisGibbs: -tools
[11:17] <ChrisGibbs> persia, ?
[11:17] <persia> ChrisGibbs: the missing part of the package name for the package you seek.
[11:18] <ChrisGibbs> persia, soz ty
[11:18] <ChrisGibbs> !info initramfs-tools
[11:18] <ubotu> initramfs-tools: tools for generating an initramfs. In component main, is important. Version 0.85eubuntu20 (gutsy), package size 62 kB, installed size 372 kB
[11:18]  * persia advocates the use of rmadison
[11:19] <ion_> Eubuntu – Ubuntu for amphetamine users.
[11:19] <ChrisGibbs> think im about to break my Ubuntu 7.10 desktop for the 50th time this wk trying to get RAID toplay nicely :)
[11:20]  * persia likes amphetamine, but can't get past the house
[11:21] <persia> (http://n.ethz.ch/student/loehrerl/amph/amph.html for those without context)
[11:22] <ion_> persia: 404
[11:23]  * persia grumbles about upstreams who lose their homepages, and hopes someone will submit a debdiff against amphetamine fixing that little issue.
[11:23]  * DaveMorris pimps his package again - http://revu.tauware.de/details.py?package=libserial - please review it, all previous comments addressed
[11:25] <persia> Ng: More points added, but I shan't review again until someone else has a look, as more viewpoints make a better package
[11:26]  * persia stops REVUing until REVU day (only 46.5 hours away)
[11:26] <Ng> persia: ok thanks :)
[11:27] <persia> Ng: Please get the viewpoints quick though.  I want to use it :)
[11:27] <Ng> persia: hehe, will do. I just upgraded to hardy, so I want to be able to install it with apt-get soon, and I only have a month to make that happen ;)
[11:27] <\sh> moins jono
[11:27] <jono> hey \sh
[11:28] <\sh> jono: as promised last year ;)
[11:28] <persia> Ng: Really only a couple weeks, as you need to allow time for the archive admins to process the NEW queue.
[11:28] <jono> \sh: eh?
[11:28] <Ng> persia: erk
[11:28] <\sh> jono: see p.u.c.
[11:30] <jono> \sh: you are a hero! :)
[11:32] <\sh> jono: na..I just want to have the opportunity to listen to your music some time :) and to have a good place in front of the speakers, I have to stay to my promises...
[11:32] <jono> \sh: you are a good man :)
[11:32] <\sh> .oO(that reminds me, I need to make a phone call to get my birth certificate...one of my important promises is to marry my GF)
[11:38] <\sh> ok..birth certificate is on its way
[11:39] <amarillion> How do I write a watch file if upstream doesn't include a version no in the filename / path?
[11:39] <amarillion> or do I then not write a watch file at all?
[11:40] <persia> amarillion: You can't write a watch file if upstream doesn't have a version in their filename or path :(  Use a get-orig-source rule in debian/rules.
[11:40] <amarillion> okidoki
[11:41] <amarillion> b
[11:43] <josesanch> persia: what else can to try to review the package?
[11:46] <persia> josesanch: I'm afraid I don't quite understand.  Are you asking how else you can review a package, or how else you can get your package reviewed?
[11:48] <josesanch> persia: Sorry. I mean. how else i can do to verify that the package is correct. I have use lintian and linda and compiles ok..
[11:51] <persia> josesanch: My review process (which may not be best) consists of lintian and linda run against the source package, a test build, linda and lintian against the binary, manual inspection of all files modified in diff.gz, a licensing header check, comparison of everything output by `less $(suspicious-source)` against debian/copyright, and tests with uscan --report-status, uscan --force-download, and debian/rules get-orig-source.
[11:51] <persia> On the other hand, few packages I advocate get into the archive without someone else finding something, so that's by no means comprehensive.
[11:51] <emgent> uhm people
[11:51] <emgent> i have debchange problem
[11:51] <emgent> see: http://rafb.net/p/JlaIiU54.html
[11:51] <emgent> some idea?
[11:52] <Fujitsu> emgent: You forgot the leading space on your signature line. Don't edit that manually in future.
[11:52] <emgent> uhm ok thanks
[11:53] <josesanch> persian: seens prety complex. Thanks for the advice. i'll try to do that
[11:55] <persia> emgent: Not related to your problem, but you probably want 5.2-2ubuntu2.2 for your new candidate version.
[11:55] <emgent> ok cool thanks
[11:59] <persia> Amaranth: Lots of candidates on REVU for your attention.  Even a few with an advocate.
[11:59] <Amaranth> d'oh
[11:59]  * Amaranth needs to learn to stop talking
[11:59] <Amaranth> I don't even know where revu is hosted these days
[11:59] <Amaranth> and i don't think i've ever had upload access to any version of it :P
[11:59] <Amaranth> !revu
[11:59] <ubotu> REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[11:59] <persia> Amaranth: revu.ubuntuwire.com works
[12:01] <persia> Amaranth: You've had upload access since 26th April :)
[12:01] <Amaranth> interesting
[12:01] <persia> (or thereabouts: I may be off by a couple days)
[12:04] <Amaranth> lintian and linda are outdated on revu?
[12:04] <DaveMorris> yeah
[12:05] <persia> Amaranth: Can you comment when you log in?
[12:05] <Amaranth> i dunno my login info
[12:06] <persia> Amaranth: Try to "recover" it.  If that doesn't work, I'll play with a couple things.
[12:07] <Amaranth> No REVU account for amaranth@ubuntu.com exists yet.
[12:07] <persia> Right.  OK.  Trying to fix...
[12:08] <persia> Amaranth: Try the email address listed on your key.
[12:08] <Amaranth> i have two listed on my key
[12:08] <persia> (Assuming E7B7AC6B is yours)
[12:08] <Amaranth> but neither one works
[12:08] <Amaranth> alleykat@gmail.com and amaranth@ubuntu.com
[12:09] <persia> Amaranth: keyserver.u.c only knows about the former.  I can set that up now, or wait for you to refresh your key on LP.
[12:09] <Amaranth> oops
[12:11] <Amaranth> persia: hrm, i forgot how to do all of this :P
[12:12] <persia> Amaranth: First, make sure your local key is correct.  Then either use the GPG command line to update the keyservers, or use "Update OpenPGP keys" from https://launchpad.net/~amaranth
[12:13] <Amaranth> there we go
[12:13] <Amaranth> stupid seahorse is setup by default to not actually sync anything when you tell it to sync
[12:13] <Amaranth> updated
[12:15] <persia> Amaranth: OK.  Adding your Ubuntu address as a reviewer, and resyncing.  I'll let you know when I think you can recover your password.
[12:15] <Amaranth> alright
[12:20] <verb3k> guys in the packaging guides of ubuntu and debian, they assume you want to package binaries you build from source code at packaging time, is there a quick guide for making packages of binary files only without dealing with source code compilation?
[12:20]  * Hobbsee blinks
[12:20] <Hobbsee> uh...
[12:20] <Pici> uh?
[12:21] <verb3k> ???
[12:21] <Pici> Magic?
[12:21] <verb3k> Did I make a mistake :(
[12:22] <amarillion> Why is REVU suddenly rejecting my uploads?
[12:22] <persia> verb3k: It's generally not permitted.
[12:22] <persia> amarillion: Might be my fault.  I'm in the middle of a keyring sync.  Sorry.
[12:22] <amarillion> "Signer has no upload rights at all to this distribution."
[12:22] <amarillion> ok, I'll wait
[12:23] <verb3k> persia, I know, they are for my personal use only
[12:23] <amarillion> verb3k, i've done it once, it's not hard
[12:24] <amarillion> Let me find some notes on how I did it
[12:24] <persia> verb3k: If you really, really, really, really, really want to, you can just install the stuff in the right places.  Look at one of the -looks or -theme or -artwork packages as an example.  Note that this is not considered a good idea, for several reasons.
[12:25] <amarillion> verb3k, you have to start writing a DEBIAN/control file
[12:26] <verb3k> amarillion, I am following
[12:26] <verb3k> I've read about that file
[12:26] <amarillion> I've got an example, just a sec
[12:27] <amarillion> Note that the control file for binary packages is different from the control file from source packages. It's derived from it, but it's not exactly the same. Just know that when you're reading docs on control files, because usually they apply to control files for source packages
[12:28] <amarillion> Ok, here is one I used in the past: http://paste.ubuntu-nl.org/51546/
[12:30] <ion_> Priority probably should be optional, Standards-Version is missing and what is Version doing there?
[12:30] <amarillion> You also need to create a complete hierarchy of the files you want installed
[12:30] <ion_> Oh, also Source: is missing from the beginning.
[12:30] <amarillion> ion_, this is just an example
[12:30] <amarillion> ion_, this is a control file for a binary package
[12:31] <verb3k> amarillion, nice, execuse me ....5 mins and I will come back
[12:31] <RainCT> @now europe/berlin
[12:31] <ubotu> Current time in Europe/Berlin: January 11 2008, 13:31:59 - Next meeting: Kubuntu Developers in 22 hours 28 minutes
[12:32] <ion_> amarillion: Uh. You still should make a source package, even if it doesn’t compile anything.
[12:32] <amarillion> ion_, yes, if you're an ubuntu MOTU
[12:33] <amarillion> but for ordinary users it may be handy sometimes to make a binary package directly
[12:34] <persia> amarillion: I agree with ion_, it's better to create a "source" package, even if you're just manually pushing binary files around.
[12:35] <amarillion> creating a binary package directly is easier. You don't need to understand makefiles
[12:36] <ion_> You don’t really need to understand makefiles to put stuff in debian/foo.install.
[12:36] <amarillion> You only need to create the file hierarchy you want, c/p a control file and run dpkg-deb -b
[12:37] <amarillion> ion_, I don't know about foo.install ?
[12:37] <persia> amarillion: Yes, but it's hard to recreate if you want to fix it later.  A debhelper-only CDBS debian/rules, debian/package.install, and debian/control will get you an easy to edit "source" package.
[12:37] <persia> amarillion: Comes from dh_install.
[12:40] <ChrisGibbs> gday all
[12:40] <\sh> grmpf...I set /etc/alternatives/x-window-decorator back to gtk-window-decorator...but emerald is always starting...what's wrong..I don't see the bug
[12:41] <ion_> sh: /desktop/gnome/applications/window_manager i’d guess.
[12:42] <\sh> ion_: compiz is in there
[12:42] <ion_> Ah, sorry, i misread your question.
[12:42] <\sh> ah
[12:42] <\sh> now I know where it is
[12:43] <ion_> I somehow managed to interpret it as you want to switch to metacity.
[12:43] <ion_> The compiz wrapper always uses emerald if it’s installed.
[12:44] <verb3k> sorry amarillion, I had something urgent, back now :)
[12:44] <\sh> ion_: yeah...I think it's abug ;)
[12:44] <Amaranth> \sh: the problem is the compiz start script starting the wrong one and overriding the alternatives (which i didn't even know existed)
[12:44] <ion_> sh: Correction: you can add USE_EMERALD=no to /etc/xdg/compiz/compiz-manager
[12:44] <amarillion> verb3k, there is only one more step
[12:44] <verb3k> yes
[12:45] <amarillion> you have to run dpkg-deb -b your-work-directory
[12:45] <amarillion> this will produce a .deb file
[12:45] <dholbach> MOTU Q&A Session in 14 minutes in #ubuntu-classroom!
[12:46] <verb3k> amarillion, this means that I only need three things: 1-dpkg-deb 2- the control file 3-my actual binaries .....is that true?
[12:46] <amarillion> verb3k, right
[12:47] <amarillion> read back the discussion that went on while you were away
[12:47] <verb3k> amarillion, ok
[12:47] <amarillion> with debian/package.install you can create a source package to do the same thing, it's a better way to do things
[12:48] <amarillion> the way I explained is the most direct though
[12:49] <minghua> Hmm, why are we talking about directly modifying binary packages here?
[12:50] <minghua> IMHO it's a very hackish and wrong approach.
[12:50] <verb3k> amarillion, how do I create the file hierarchy? what's the syntax and should they be in the control file itself?
[12:51] <amarillion> not in the control file no
[12:51] <amarillion> it depends. What kind of files do you want to install?
[12:51] <josesanch> amarillion: it seens that there is an error in your manpage
[12:51] <amarillion> josesanch, aaahhh, thanks for checking
[12:51] <amarillion> how did you find out?
[12:52] <Hattory> \sh, ping
[12:52] <josesanch> I run lintian on the binary package
[12:52] <josesanch> lintian -i binarypackage.deb
[12:52] <\sh> Hattory: pong
[12:52] <verb3k> hmm....basically I want to install executables, scripts and other binaries(data and so)
[12:53] <amarillion> josesanch, weird? I don't get any errors when I do that on my own package
[12:53] <josesanch> in your binary package?
[12:53] <Hattory> \sh, Yesterday, I sent you an email about a merge of alogg package
[12:53] <Hattory> You have received it?
[12:53] <amarillion> verb3k, so for example, executables usually go in /usr/bin
[12:54] <amarillion> data that is cross-platform can go in /usr/share/
[12:54] <Hattory> Have you* :D
[12:54] <amarillion> Hey Hattory, are you into allegro?
[12:55] <verb3k> amarillion, I see, but what's the file and its syntax?
[12:55] <amarillion> verb3k, well simply create a hierarchy like this
[12:55] <amarillion> ~/workdir/usr/bin/your_binary
[12:55] <persia> Amaranth: Please test REVU password recovery (sorry for the delay)
[12:55] <amarillion> ~/workdir/etc/your_config_file
[12:56] <Amaranth> persia: err, but i already have my password :P
[12:56] <amarillion> ~/workdir/usr/share/dir/your_data_files
[12:56] <Amaranth> but alright
[12:56] <amarillion> ~/workdir/DEBIAN/control
[12:56] <ScottK> Good morning all.
[12:56] <persia> Amaranth: Yes, but I want to make sure you can recover it.
[12:56] <amarillion> and then run dpkg-deb -b on workdir
[12:56] <\sh> Hattory: not that I know..I check my trash could be that it landed there
[12:56] <verb3k> amarillion, can I name it anything or something specific?
[12:57] <amarillion> anything, as long as it doesn't clash with existing stuff
[12:57] <\sh> Hattory: got it :)
[12:57] <Hattory> sorry.... -.-'
[12:57] <verb3k> amarillion, and that's all? I mean just these two files only?
[12:57] <Hattory> \sh, good.... can I do it?
[12:57] <Amaranth> persia: works fine
[12:57] <josesanch> amarillion: lexgrog -m speed-game.1
[12:57] <amarillion> verb3k, yes, try it
[12:58] <persia> Amaranth: Excellent.  Cleaning my history and wiping my brain :)
[12:58] <josesanch> checks the manpages
[12:58] <verb3k> amarillion,   :)    thanks I'll try and let you know
[12:59] <\sh> Hattory: please do :) just check if debian upstream added our changes..if not merge it :)
[12:59] <amarillion> josesanch, I don't really get an error
[12:59] <amarillion> it just echo's the title of the man page
[12:59] <ScottK> StevenK: I gather you weren't able to find the time to do the clamav upload for feisty-backports?
[12:59] <Hattory> \sh, ok thanks ;)
[12:59] <StevenK> ScottK: That and forgot. I can do it now if you wish.
[12:59] <verb3k> if I have to make the package depend on some other packages in the repositories, where do I specify that?
[12:59] <josesanch> amarillion: Oh.. sorry then..
[13:00] <DktrKranz> hey \sh, happy birthday and congrats!
[13:00] <ScottK> StevenK: Yes, please.
[13:00] <\sh> DktrKranz: thx :)
[13:00] <StevenK> ScottK: debdiff / interdiff / source link?
[13:00] <josesanch> i got the parse.error i don't know why
[13:00] <amarillion> josesanch, it's allright. I'm really not 100% sure the man file is correct
[13:01] <verb3k> amarillion, if I have to make the package depend on some other packages in the repositories, where do I specify that?
[13:01] <amarillion> I haven't found good docs on writing simple man pages yet
[13:01] <ScottK> StevenK: Debdiff is in this bug: Bug #181830 - Debdiff is relative to the version in gutsy-security.
[13:01] <ubotu> Launchpad bug 181830 in feisty-backports "CVE-2007-6337 Unknown impact remote attack" [Undecided,Confirmed] https://launchpad.net/bugs/181830
[13:01] <amarillion> verb3k, That should go in the Depends line of the control file
[13:01] <Hattory> \sh, is your birthday? :D
[13:01] <verb3k> amarillion, I see
[13:01] <\sh> Hattory: yepp :)
[13:02] <persia> verb3k: If you compile it, debhelper can help automatically set the dependencies, based on the files you build-depend upon.
[13:03] <Hattory> \sh, cooool.... happy birthday and congrats for the membership!!!
[13:03] <Amaranth> \sh: happy birthday
[13:03] <verb3k> persia, right, but I am dealing with binaries so can't compile anything
[13:03] <Amaranth> knew i forgot something
[13:03] <persia> verb3k: Frustrating that, but understood.
[13:03] <\sh> thx a lot guys...good to be back :)
[13:13]  * persia notes that people who file patches to fix http://qa.ubuntuwire.com/lintian/reports/Tbuild-depends-on-obsolete-package.html get extra points
[13:14] <ScottK> persia: For debmake, do removal bugs count as fixing?
[13:15] <persia> ScottK: Yes, but not all of those are actually candidates for removal.
[13:16]  * ScottK will take your word on that, but finds it hard to believe something not yet updated to debhelper is worth keeping.
[13:17] <persia> ScottK: lamont just migrated a couple packages of his to work with current tools (still not debhelper) in the last couple weeks, as they were still building and working previously.  I suspect some others might have the same situation.
[13:19] <persia> On the other hand, that lintian error is definitely RC, so removal without blacklisting after FF seems ideal to me.
[13:20] <ScottK> Fair enough.
[13:21]  * Hobbsee ponders an entire shift of MC people, as all but one of the original people have gone
[13:22] <emgent> keescook, when you have time see #181416 and #181984 Thanks :P
[13:22] <emgent> 181416
[13:23] <emgent> uhm..
[13:23] <persia> Hobbsee: That's the nature of governance.  We grant leaders, and they serve, and when they are done, we get new ones.  As long as we only add one or two at a time, we should be able to preserve continuity.
[13:23] <persia> bug #7
[13:23] <ubotu> Launchpad bug 7 in rosetta "Need help for novice translators" [Medium,Confirmed] https://launchpad.net/bugs/7
[13:25] <Hobbsee> dholbach: what was the rationale behind private nominations, out of curiousity?
[13:25] <ScottK> persia: I would disagree that we've actually granted leaders so far.  One person elections aren't elections.
[13:26] <StevenK> ScottK: So why can't you upload it?
[13:26] <persia> ScottK: I agree with that, but believe it is a separate issue.  We have gotten council members, although some there may be issues with previous elections.
[13:27] <ScottK> StevenK: Source backports take a core-dev regardless of the component.
[13:27] <StevenK> Neat.
[13:27] <dholbach> Hobbsee: I'm in a session right now, but in a nut shell it's about avoiding public discussions of the merits of nominees
[13:27] <ScottK> dholbach: I would say that's exactly what we ought to have.
[13:29] <Hobbsee> dholbach: i don't really see the problem with that - especially when everyone needs to vote on it anyway.
[13:29] <dholbach> ScottK: I personally disagree - I feel that it turns people off and that it's too easy to get into flamewars because of that
[13:29] <Hobbsee> dholbach: to an extent, it's like campaigning - so those who arent' on irc a lot know who the various candidates are, and what they want to do if they get it
[13:30] <ScottK> dholbach: Even if we had a "only be positive in your comments rule" I think it would be useful.
[13:30] <ScottK> Plus CoC should keep flaming to a managable level.
[13:31]  * StevenK idly wonders if he trusts ScottK enough to not test build it.
[13:31] <Hobbsee> dholbach: otherwise it becomes a bit of a popularity vote, with the people who speak the most, and send mails the most, get higher status, principly due to being more active.
[13:31] <Hobbsee> dholbach: which is bad news, for those with a low S/N ratio, and a lot of output.
[13:32] <dholbach> I feel that almost all people in ubuntu-dev (the people that vote) know each other or a group of developers quite well and well enough to decide on somebody who is up for election
[13:32]  * persia notes that we haven't seen the means by which the final nominees will be selected.  It may be that some subset will be presented for a period of comment
[13:32] <dholbach> I wonder why nobody objected to it in the CC meeting yesterday
[13:32]  * ScottK wasn't there when it was discussed.
[13:32]  * persia was asleep
[13:33]  * ScottK only even knew it was going to be discussed because of dholbach's mention of it as a pre-requisite for filling out the MC.
[13:34]  * ScottK would have thought such a fundamental governance issue would have been announced more broadly.
[13:34] <Hobbsee> dholbach: based on how i don't know a great group of the new MOTU's, i can't see why they'd know about me, beyond that i talk a lot on irc.
[13:34]  * Hobbsee was also asleep.
[13:34] <StevenK> Hobbsee: And you randomly attack people ...
[13:34] <Hobbsee> StevenK: well, yeah.
[13:37] <Hobbsee> dholbach: the likely way it works is that the new MOTU's feel excited about voting, and so vote for their sponsors, as they're recognised names, the old MOTU's vote sensibly, and various people don't vote at all.
[13:37] <Hobbsee> the first group isn't actually terribly helpful, when you're looking to select good leaders
[13:38] <dholbach> I think that will happen whatever campaigning will happen before: the people that vote, vote people they trust and who they have witnessed doing good work
[13:39] <ScottK> Which is a recipe for that status quo.
[13:40] <ScottK> Since, of course, people who've stepped back due to being dis-satisfied have a limited ability to make a case for change.
[13:40] <dholbach> ScottK: what do you mean?
[13:40] <persia> Even without "campaigning", a comment period is good.  Let's people raise issues.  Alternately, just posting platforms.
[13:41] <ScottK> Yes, but making nominations a secret really isn't helpful.
[13:42] <persia> ScottK: It's more helpful than not accepting community nominations, no?
[13:42] <Hobbsee> persia: it appears that dholbach doesn't want issues to be raised, though, as that leads to flamewars.
[13:42] <ScottK> persia: Agreed.
[13:42] <ScottK> It's progress.
[13:42] <Hobbsee> persia: thus, a gag, by making it private is quite effective - and opens up the possibility of corruption
[13:42] <dholbach> Hobbsee: calm down
[13:42] <persia> Hobbsee: Depends on the issue, really.
[13:43] <dholbach> of course I want issues to be raised
[13:43] <Hobbsee> persia: oh, of course, but we're assuming these are going to be fairly big, important issues, no?
[13:43] <ScottK> dholbach: I'd suggest listening rather than trying to stifle dissent.
[13:43] <Hobbsee> dholbach: i'm perfectly calm.
[13:43] <Hobbsee> dholbach: but, i think you've chosen the wrong option here, for some bad reasons.
[13:43] <dholbach> I'm just wary of the fact that discussing the merits of applicants will turn people down
[13:44] <ScottK> So you want elections without discussions?
[13:44] <persia> Hobbsee: I don't think so.  For instance if someone who had been MOTU for one day was nominated, I'd complain about it being only one day (although the current person in that situation might get special treatment)
[13:44] <Hobbsee> dholbach: the type of people who would be turned down by that would presumably also be turned down by the thought that people are going to think about their merrits, and probably discuss them in private.
[13:44] <dholbach> If you feel very strongly about this process, best to raise it with the CC. Why should I want issues not to be raised?
[13:44] <ScottK> dholbach: Since you've said you don't want discussion.
[13:45] <Hobbsee> dholbach: so you don't have to deal with them, if anything too hard comes up.
[13:45] <Hobbsee> i'm sorry to be harsh, but...
[13:46] <Hobbsee> persia: what did your comment relate to, sorry?
[13:46] <dholbach> sorry... I just got a huge delivery and in a session at the same time, so a bit ... torn
[13:46] <persia> Hobbsee: "oh, of course, but we're assuming these are going to be fairly big, important issues, no?"
[13:46] <dholbach> Hobbsee: what is too hard and what don't I want to deal with?
[13:47] <Hobbsee> persia: ah right.
[13:47] <Hobbsee> dholbach: i don't know, exactly.  of course, the fact that these issues can't be raised, are they're forbidden, are why i can't answer the question of what examples those issues would be.
[13:47] <emgent> dholbach, what do you think about bug #181853 ?
[13:47] <ubotu> Bug 181853 on http://launchpad.net/bugs/181853 is private
[13:47] <dholbach> I'm afraid I don't understand
[13:47] <Hobbsee> dholbach: so, here's a hard question for you in the meantime?
[13:48] <Hobbsee> dholbach: what happens with MC quorum, as the MC said it would make a decision in a few days about kmos.
[13:48] <StevenK> ScottK: clamav_0.91.2-3ubuntu2.2~feisty1 uploading.
[13:48] <Hobbsee> as you now only have 3 members
[13:48] <persia> quorum is 3 and there are 3 active members.  No issue (as I read things).
[13:49]  * dholbach nods towards persia
[13:49] <dholbach> soren, geser: can you jump in on the discussion - I'm a bit torn between activities right now
[13:49] <Hobbsee> persia: right, so all it takes is one to decline now, and it gets floored.
[13:49] <ScottK> StevenK: Thanks.
[13:49] <StevenK> ScottK: s/ing/ed/
[13:49] <Hobbsee> persia: the advantage, of course, to quorum of more people is that one (or two) people can disagree, and be overruled
[13:49] <soren> I'm completely starved, so I'm on my way to lunch. :/
[13:50] <Hobbsee> unanimous decisions on complex issues are quite rare, it appears.
[13:50] <persia> Hobbsee: In that case
[13:50] <persia> In that case, it gets revisited when the council is back to nominal size.
[13:50] <achadwick> Do new multiverse packages go through the normal MOTU process as described at https://wiki.ubuntu.com/MOTU/Contributing#head-f4c6048b1531f4e4fe48f096350ea435d40ed9f5 , but with s/universe/multiverse/ throughout?
[13:51] <Hobbsee> (having seen the kubuntu council make decisions, or attempt to make them, with everyone in full agreement before, i know that sometimes doesn't happen)
[13:51] <dholbach> emgent: I'm not quite sure: why am I on the bug?
[13:51] <emgent> yes
[13:51] <emgent> i attached you now.
[13:51] <emgent> s/attached/subscribed/
[13:51] <persia> achadwick: Yes, although some reviewers refuse to review multiverse, so it can take longer.
[13:52] <emgent> dholbach, it's cool debian road?
[13:53] <achadwick> persio: Fair enough. In this case it's a GPL program made to install some non-free software, which is contrib in Debian.
[13:53]  * achadwick assumes that that translates to multiverse in ubuntu.
[13:53] <dholbach> emgent: best to discuss with keescook or jdstrand - I'm a bit occupied right now
[13:54] <Hobbsee> persia: a nice delaying tactic, especially for those who have left, so don'[t have to make a decision on kmos :)
[13:54] <emgent> ok dholbach thanks
[13:54] <persia> Hobbsee: I actually don't believe it will be delayed, but I don't have a voice on that.
[13:57] <dholbach> Hobbsee: I don't think that's fair to say: crimsun and ajmitch both were very busy when they left the MC
[13:57] <Hobbsee> dholbach: oh, i can undersatnd that.  which means that they wouldn't have wanted to have to deal with kmos, due to said busyness.
[13:58] <Hobbsee> which is why leaving a few days prior to the report ot the MC is *very* smart from their end
[14:01] <ChrisGibbs> Hobbsee, how'd your key signing end up??
[14:01] <Hobbsee> ChrisGibbs: was good :)
[14:05] <txwikinger2> ping persia
[14:07] <\sh> sounds like fun today :)
[14:10] <rulus> can someone look into bug #180383?
[14:10] <ubotu> Launchpad bug 180383 in gnuvd "Van Dale website code changed" [Undecided,Confirmed] https://launchpad.net/bugs/180383
[14:10] <persia> imbrandon: LaserJock: DktrKranz: jdong: TheMuso: is there a mailing list for ~motu-sru?
[14:12] <persia> rulus: Needs a candidate submission for the new upstream.  Submit an interdiff.
[14:13] <rulus> persia: hmm, that's like Chinese to me
[14:14] <persia> rulus: Looking in a little more depth, it appears that gnuvd is currently at version 1.0.3-4 in the archive.  If this was fixed upstream (as the bug report seems to indicate), then the new upstream should be submitted to Ubuntu.
[14:15] <persia> rulus: The current way to do this is by adapting the current package to match the new upstream, submitting an interdiff to the bug report, and subscribing the sponsors to request upload.
[14:16] <persia> Some useful URLS are https://wiki.ubuntu.com/MOTU/Contributing, https://wiki.ubuntu.com/PackagingGuide/Howtos/PackageUpdate, and https://wiki.ubuntu.com/UbuntuDevelopment/Interdiff
[14:17] <rulus> there is no new upstream release. gnuvd is a parser for the Van Dale website written in C, and I used it in my GtkVD application which was basically a Gtk GUI around gnuvd. Recently the Van Dale website was renewed, so gnuvd doesn't work anymore. Therefore I wrote my own html parser to get the data, which is included in GtkVD - but this doens't affect gnuvd.
[14:17] <persia> rulus: Can you use your experience with GtkVD to create a patch for gnuvd that would work?
[14:18] <DarkSun88> Hi all
[14:18] <rulus> I doubt it, I know Python, but not C
[14:19] <DarkSun88> \sh: Congratulations. Welcome back. :)
[14:19] <rulus> I don't know if it's actually usefull to patch gnuvd..
[14:19] <ScottK> rulus: Can you file a bug with Debian with enough detail that maybe the Debian Maintainer can fix it?
[14:19] <\sh> DarkSun88: thx :)
[14:19] <persia> rulus: Others know C.  If you could draft up a spec and help test, and note this in the bug, it might be good.  I don't like removals for fails-to-work-out-of-the-box unless it's also dead-upstream-and-unmaintained
[14:20] <rulus> Actually it is quite dead I think, the last update on the website of the author dates from 2005
[14:20] <rulus> ScottK: that should be no problem
[14:21] <ScottK> I think your odds of having someone care enough to write C code are better in Debian where there's a dedicated Maintainer who's taken an interest in the package.
[14:21] <ScottK> If Debian fixes it, then we can sync the fix from them.
[14:21] <persia> (depending on the fix, we can also cherrypick)
[14:22] <ScottK> Be sure the link the Debian bug to the LP bug in LP after you file it.
[14:22] <ScottK> Yeah.
[14:22] <rulus> Yeah I understand, but I don't know if it's usefull to rewrite gnuvd if my VanDale.py module does exactly the same thing
[14:22] <persia> rulus: Users may already have gnuvd installed.  It's a support issue.
[14:23] <rulus> ah, right
[14:33] <Hobbsee> ScottK: actually, the private discussion would probably be waranted, so that certain people don't get on the MC
[14:34] <ScottK> Except those kinds of people are probably the same ones the would complain about it later publically and so we'd get to have a public discussion anyway.
[14:34] <Hobbsee> or before it.
[14:35] <ScottK> So secrecy really solves nothing IMO.
[14:35] <Hobbsee> sure, but most people don't watch irc on a friday night
[14:35] <ScottK> Transparency is virtually always the right answer.
[14:35] <\sh> lol...you guys are really crazy :)
[14:36] <Hobbsee> \sh: we work on ubuntu.  duh.
[14:36]  * txwikinger2 agrees with ScottK
[14:36]  * persia notes that this is not always equivalency, and sane people are also welcome to join
[14:36] <ScottK> Not that it's actually happened yet.
[14:37] <Hobbsee> ScottK: yes, and that's why a lot of open source actually works, which is why i'm surprised that this is decided to be private.
[14:37] <Hobbsee> i might have been listening to pia too much, but i thought one of the defining factors of open source was open management
[14:38] <ScottK> It doesn't have to be, but if it's not, it generally doesn't have a happy ending.
[14:38] <persia> Not necessarily.  I've seen closed source with open management and open source with closed management, and both work OK.  On the other hand, community efforts with closed management don't tend to do as well.
[14:38] <dholbach> ScottK: do you think it would help if people who nominate themselves put up a wiki page with their ideas about MOTU, the MC and their contributions?
[14:38] <ScottK> dholbach: Yes.  Definitely.
[14:39] <Hobbsee> persia: sure, but as in, if it's open, it needs to follow and do this bunch of stuff.
[14:39] <persia> dholbach: Maybe just edit their standard wiki page to demonstrate activities, involvement, and share a platform, rather than have them separate.  Also, perhaps have a central page listing all the nominees pages for easy reference.
[14:39] <dholbach> What I *personally* really want to avoid is mud-slinging sessions (be it on mailing lists or on IRC) about how some people like nominee A to do XYZ half a year ago
[14:39] <persia> Hobbsee: I'm not disagreeing with your point, only that it is related to community projects, rather than open source.
[14:40] <dholbach> things like that aren't helpful even if they are "transparent"
[14:40] <Hobbsee> persia: true, true.  was clarifying.
[14:40] <dholbach> sharing information and making goals obvious is a good thing, I agree with that
[14:40] <Hobbsee> dholbach: the ones who get blamed for not doing stuff tend to be in power at the time of the complaint.
[14:40] <persia> dholbach: Surely that's governed in part by MC calming role and CoC, no?
[14:40] <Hobbsee> dholbach: else you're blaming people for stuff that they actually can't fix, which is futile, and doesn't tend to happen around here
[14:41] <dholbach> persia: I just thought about how we could adress the need for clarification of goals and giving out more information to the people who vote in a good way
[14:42] <txwikinger2> virtual caucus? :D
[14:42] <Hobbsee> dholbach: i guess i'm unconvinced that there would be mudslinging at innocent parties - only those who had the power to fix things, but didn't.
[14:42] <Hobbsee> which aren't those who would be being nominated.
[14:43] <persia> dholbach: Right.  Sorry.  Insufficient context.  I think your wiki pages idea is good.  I am less worried about mailing lists, IRC, etc. due to CoC and MC calming activities.
[14:45] <persia> Hobbsee: People who are not MC (and maybe even not nominees) might also have made egregious mistakes for which they would be slapped.  Don't discriminate :)
[14:47] <dholbach> there's nothing wrong about telling people about their mistakes - I just think that it should happen in the context where it happens and not as a long mailing list thread during an team council election
[14:47] <ScottK> dholbach: I think the only reason that happened last time was because of poor timing and the fact that nominees had not come from the community.
[14:47]  * persia agrees with the word "long" in that context
[14:49] <Hobbsee> persia: well, i guess this is a point.  i was thinking of motu leadership.
[14:49] <dholbach> ScottK: I'm happy to make the "wiki page" admendment to it... I'll drop a mail to the CC, TB and MC - and we can formalise it for the next round
[14:49] <ScottK> dholbach: OK.  I do like what was said about it being their regular wiki page, not a special one.
[14:49] <dholbach> ScottK: fine with me
[14:50] <emgent> bye people!
[14:50] <dholbach> bye emgent
[14:55]  * soren is reading scrollback
[14:55] <soren> Hobbsee: Re: "it becomes a bit of a popularity vote, with the people who speak the most, and send mails the most, get higher status, principly due to being more active"> I can think of a few who send *plenty* of e-mail but I wouldn't vote for..
[14:55] <Hobbsee> soren: yes, but you're clueful, and watch motu reasonably closely.
[14:55] <Hobbsee> soren: your category of people aren't the worry
[14:56] <persia> Err.  Let's avoid categorisation, and look at systemic solutions.
[14:57] <soren> Hobbsee: I guess I just tend to give the average MOTU more credit than expect them to vote based on the count rather than contents of people's postings.
[14:57] <persia> Essentially, the community is large enough that we can't all know each other anymore, therefore "I know them, they are good" becomes a weak validation.  What would be a better validation?
[14:57] <Hobbsee> soren: i wish i could do the same.  for hte msot part, that certainly holds.
[14:58] <ScottK> persia: Which is why campaiging is good.  That also brings in "I know X and they speak in favor of Y that I don't know."
[14:59] <persia> ScottK: To some degree, yes.  On the other hand, it unfairly balances in favour of politicians over technical types.  The balance is tricky.
[15:00] <ScottK> Yes, but we're hiring management, so that's not necessarily bad.
[15:01] <persia> ScottK: Maybe.  Depends on "hiring management" vs. "appointing administrators".  "suits" aren't always best in community or volunteer projects.
[15:01] <ScottK> Sure, but we need community skills in MC more than we need the best packager.
[15:01] <persia> On the other hand, having the administrators be those who are active in the community and look at community rather than just pushing 1000 uploads is also good.
[15:02] <ScottK> persia: Speaking of which, would have have a little time to look into a problem for me?
[15:02] <mok0> I've been following this discussion for a while, and the topic seems to be "How do we limit the influence of people that we don't trust to make the decisions we want them to."
[15:02] <persia> (that could have been written more concisely as "Yes")
[15:02] <persia> ScottK: What sort of problem?
[15:02] <persia> mok0: Maybe :)
[15:02] <Hobbsee> mok0: depending on "the decisions we want them to", and how that expands, yes.
[15:03] <Hobbsee> mok0: we want people to make good decisions, based on credible reasons, to apoint the best people for hte job.
[15:03] <Hobbsee> mok0: as for who that is...we're not specifyingi that.
[15:04] <mok0> Hobbsee: I just don't like the outset of those premises. It's better to agree on the set of qualities you are looking for, and trust that everybody will be able to make a proper decision.
[15:04] <ScottK> persia: In order to get amavisd-new into Main (a spec item for Hardy for ubutu-server), I need to break libmilter, libmilter-dev, and libmilter-dbg out of the sendmail source package and into a separate package that can be promoted to Main.  I took a look at the sendmail package and just about fainted.  I'd appreciate advice on a packaging strategy for my new package (ripping the milter stuff out of sendmail doesn't look particularly hard).
[15:04]  * persia grabs sendmail
[15:05] <ScottK> persia: Thanks.
[15:05] <Hobbsee> mok0: which assuems that all people are sane - which is also a bad premise.
[15:05] <mok0> Hobbsee: absolutely not
[15:05] <ScottK> persia: And if you get motivated and actually want to DO the new package, I'd be totally cool with that.
[15:05] <Hobbsee> then again, the few that aren't will probably be minor enough not to matter
[15:06] <mok0> Hobbsee: You are focusing on an irrelevant concern, IMHO
[15:06] <persia> ScottK: That's fairly unlikely.  I've a heap of stuff I should hit this weekend, and after (mostly) skipping last REVU day, need to push if we're to get many of the current packages into hardy (some are good)
[15:06] <mok0> Hobbsee: ... and you'll never gain influence by attempting to limit that of others
[15:06] <ScottK> persia: OK.  Just saying ...
[15:07] <persia> mok0: That's not quite true.  Big fish/small pond
[15:07] <Hobbsee> mok0: it's not really that - it's more the compromised nature of the vote, if apathy is used as a method of voting
[15:09]  * persia declares that tarball-in-tarball doesn't only make the md5sums guarantee to fail to match, make patching difficult, and make inspection difficult, but is also infuriating when cdbs-edit-patch doesn't work
[15:09] <ScottK> persia: Do you feel my pain?
[15:10] <Hobbsee> persia: ...ouch?
[15:10] <mok0> Hobbsee: any organization goes through cycles... It's best to focus at the goal - and get to agree on that - than to descend into politics
[15:10] <persia> ScottK: Not yet.  So far, it's just normal pain.  I'm still digging around in the upstream build system: it looks maybe not so bad.
[15:10] <soren> persia: Which md5sum will fail to match?
[15:10] <persia> soren: orig.tar.gz to upstream tar.gz
[15:10] <mok0> Hobbsee: the latter tends to be more destructive that productive
[15:11] <soren> persia: Oh, right.
[15:11] <Hobbsee> mok0: true, there's the question about a) do the politics ever get solved, and b) should they?
[15:11] <mok0> Hobbsee: ... and you'll end up with N one-person organizations, which all are in perfect agreement with themselves :-)
[15:12] <persia> soren: Which means, in the absence of get-orig-source, we have to either trust the packager implicitly (and given what I see from Debian and here, I don't really) or manually dig around trying to verify things (although it is nice when the packager puts an .md5 file in the package to help)
[15:12] <mok0> Hobbsee: I
[15:12] <mok0> I'd say b). If you move ahead, focused on the goal, it doesn't matter if things are not always perfect
[15:13] <Hobbsee> this depends on what your goal is
[15:13] <Hobbsee> but, yes
[15:13] <soren> persia: You need to manually dig around to verify the orig's md5 anyway?
[15:13] <mok0> Hobbsee: ok, if your goal is perfection :-)
[15:13]  * Hobbsee heads to bed, and figures that someone else will solve the problem.
[15:13] <Hobbsee> mok0: MOTU perfection?
[15:14] <mok0> Hobbsee: ... well, it's always going to be a normal distribution
[15:14] <Hobbsee> mok0: why, though?  you've got to make a standard to get there in the first place
[15:15] <Hobbsee> i don't see why hte bottom of the distributoin should be there at all
[15:15] <mok0> Hobbsee: well, like you said, some are more active than others etc
[15:15] <Hobbsee> wasn't thinking in terms of activity
[15:15] <ScottK> It's not a question of activity level, but activity quality.
[15:16] <mok0> There's quality control built into the system afaics
[15:16] <persia> ScottK: It's a trivial pull.  Disable libmilter* from debian/control.  Since libmilter is already commented out in the upstream Makefile, just rip out all the special handlers in debian/rules.  This should give you a libmilter-free package.
[15:17] <persia> ScottK: Next comes the hard part: building libmilter.  Looking in more depth...
[15:17] <mok0> ... again, this is a discussion of the cathedral vs. the bazaar
[15:17] <ScottK> Yeah.
[15:17] <ScottK> mok0: I don't think so.
[15:18] <ScottK> mok0: I think it's more do you let absolutely everyone into the bazaar or does the bazaar get more done with some people left out.
[15:18] <persia> ../devtools/bin/Build is just ugly, but then again, I remember thinking it was neat the first time I compiled it
[15:18] <mok0> 'nuff said, I gotta get back to work :)
[15:19] <persia> ScottK: You're mixing things.  Having a large gated city with an internal bazaar is different from having some police in the bazaar to ensure the thieves restrain themselves to acceptable levels.
[15:19] <ScottK> persia: Fair enough.  And making sure the police aren't in league with the theives.
[15:20] <markvandenborre> this is not strictly a moty thing, but it's such a critical bug that I need all help I can get in reporting it as well as possible
[15:20] <markvandenborre> https://bugs.launchpad.net/ubuntu/+bug/182028
[15:20] <ubotu> Launchpad bug 182028 in ubuntu "evince and eog freeze on all printing related actions" [Undecided,New]
[15:20] <markvandenborre> is there anything I can do to improve this bug report?
[15:20] <persia> ScottK: That's just basic anticorruption.  Who watches the Watch?  Governance is tricky, but it is one of the few places where circular dependencies are a good thing.
[15:21] <rexbron> Hey, I have an interesting problem. When I compile a library (OpenLibs in this case) on a 64bit arch, all of the lib directories are changed to lib64. Looking at the fs, lib64 is just a symlink to lib. Does anyone know of a configure option (because I found the line in the configure script that does this) or another work arround that might be able to solve this?
[15:21] <persia> markvandenborre: Likely, but #ubuntu-bugs was the right place to ask (although most triagers don't seem active just now :( )
[15:21] <ScottK> markvandenborre: And you already got told that in #ubuntu-devel.  The advice is still good.
[15:22] <markvandenborre> ScottK, yeah, sorry, should have been a bit slower about coming here
[15:22] <persia> ScottK: To be fair, he did ask in #ubuntu-bugs, and nobody responded (although that doesn't make this the right place)
[15:22] <markvandenborre> please ascribe this to the fact that I stuck my neck out quite far by having
[15:23] <ScottK> persia: Not getting a question answered where it's on topic, doesn't make the question on topic here.
[15:23] <Hobbsee> markvandenborre: you don't happen to wokr for canonical, do you?
[15:23] <persia> ScottK: Right, which is the reason for the parenthetical comment
[15:23] <persia> ScottK: How well do you know m4?
[15:23] <ScottK> persia: Right.
[15:24] <ScottK> persia: Not very well at all.
[15:24] <markvandenborre> Hobbsee, no, and that wouldn't make my question here appropriate here either
[15:24] <persia> Ah.  Yet another reason you likely ran screaming when looking at sendmail :)
[15:24] <ScottK> persia: I've hacked on m4 files until stuff built, but that's about it.
[15:24] <ScottK> Yeah.
[15:24] <Hobbsee> markvandenborre: was just curious, seeing as you'd been at UDS
[15:24] <markvandenborre> Hobbsee, I have been an extremely active non-code community, that's right
[15:25] <ScottK> persia: If I wanted to know m4, I'd use Sendmail as my MTA and not Postfix ;-)
[15:25] <markvandenborre> Hobbsee, extremely active non-code community member
[15:25] <Hobbsee> markvandenborre: fair enough
[15:25] <Hobbsee> markvandenborre: does that happen with any other printers?
[15:25] <markvandenborre> we have only this kind around here
[15:26] <persia> ScottK: I don't see any real internal dependencies in libmilter that require it to be built with the rest of sendmail.  I'd suggest you create a completely new build system from scratch, rather than trying to rescue upstream, and just pull ./libmilter/.
[15:26] <markvandenborre> but at another place with a very similar setup (other type of hp laserjet)
[15:26] <ScottK> persia: Thanks.
[15:26]  * persia encourages Hobbsee and markvandenborre to move to #ubuntu-bugs
[15:26] <markvandenborre> persia, will do, sorry
[15:28] <persia> ScottK: Feel free to ping me if Makefile.m4 causes you too much pain.  I have a list to do this weekend, but should have at least some time.
[15:29] <ScottK> persia: Thanks.
[15:31] <persia> Oh, and regarding sendmail vs. postfix, there are other reasons beyond m4.  While I'm a sendmail fan, and ran it on all my mailservers for as long as I was a mail admin, it doesn't always integrate most cleanly with other tools, and has some quirks about queue management that can be very frustrating.
[15:32] <ScottK> Yes.
[15:49] <gnd> How long does it usually take for a package to appear in PPA from running the dput command?
[15:49] <rulus> gnd: a few minutes
[15:49] <gnd> Allright, i'll wait :D
[15:50] <rulus> but it takes a little longer to get built
[15:57] <jdong> LucidFox: another status update, more things have to be fixed/investigated in the orig.tar.gz.... Messy upstream syndrome. They look simple to resolve so I'd say by the end of today I should have another upload prepared
[15:58] <LucidFox> Good.
[16:14] <db-keen> If I am the original developer of a program called jump, and the official Debian repo has an older version of jump, am I supposed to have the version be 1.0.0 or 1.0.0-0jump1?
[16:16] <LucidFox> db-keen> if you're upstream, the versioning is up to you
[16:16] <LucidFox> if you build your own Debian packages upstream, you... shouldn't do that :)
[16:17] <persia> db-keen: Depends on whether you are releasing a new upstream, or just making a debian source package also available to your users.
[16:17] <db-keen> just a package available to users
[16:17] <mok0> db-keen: I'd choose a version scheme based on the nature and importance of updates to the software
[16:18] <persia> If the former, I'd recommend 1.0.1 or something similar (up to you).  If the latter, using -XjumpY would be one way to release a .dsc without blocking a later debian override.
[16:18] <mok0> db-keen: if the new version is 1.0.0.0.0.0.1 it is less likely to be picked up ;-)
[16:18] <LucidFox> I think it should be 1.0.0-0[something]X
[16:18] <LucidFox> the version for the package, that is
[16:18] <LucidFox> 0 indicates that this upstream version is not in Debian yet
[16:18] <mok0> LucidFox: You're talking about the release tag
[16:19] <persia> db-keen: If you do decide to use 1.0.0-XjumpY, please don't include debian/ in orig.tar.gz, and try to keep your version lower than an official Debian version would be (or Ubuntu version, if you think it might get pulled by Ubuntu).
[16:19] <db-keen> LucidFox: but as the original developer, I'm never sure what that [something] should be
[16:19] <mok0> db-keen: as persia said, go for 1.0.1, the release tag has to do with the packaging
[16:19] <persia> db-keen: Any value for something works.  Avoid '~' and strings sorting higher than 'ubuntu' and you should be safe.
[16:20] <mok0> foo-1.0.1-0ubuntu1
[16:20] <persia> Errr..  jump-1.0.1-0jump1
[16:20] <mok0> sorry foo_1.0.1-0ubuntu1
[16:20] <LucidFox> mok0> not ubuntu, because he's not packaging it for the official Ubuntu repository
[16:21] <db-keen> so I can't use a string sorted higher than ubuntu?
[16:21] <db-keen> that really limits the alphabet
[16:21] <db-keen> vwxyz
[16:21] <LucidFox> db-keen> persia's suggestion works
[16:22] <persia> db-keen: You can use those, but ubuntu won't pull from you if you do.
[16:22] <db-keen> ubuntu probably _should_ pull from me once they get an 'official' version in the repo
[16:22] <LucidFox> db-keen> vwxyz are those that you _shouldn't_ use, you can use everything else
[16:22] <minghua> If you want name flexibility, -0~xxx is almost always safe, altough a bit ugly.
[16:22] <LucidFox> if Debian or Ubuntu package 1.0.1, your package 1.0.1-0jump1 will be overridden by 1.0.1-1 or 1.0.1-0ubuntu1, respectively
[16:23] <db-keen> Okay, thank you
[16:32] <nxvl_work> ScottK: ping
[16:32] <ScottK> Pong
[16:32] <ScottK> nxvl_work: ^^
[16:32] <nxvl_work> ScottK: can you help us with q revu? on #terminator
[16:33] <ScottK> Not currently, no.   I'm tied up with some other things.
[16:33] <nxvl_work> ok
[16:33] <nxvl_work> it will be on other time
[16:33] <nxvl_work> thanks anyway
[16:33] <nxvl_work> :D
[16:33]  * nxvl_work HUGS ScottK
[16:37] <rexbron> Does Vcs-Bzr still need the XS- prefix?
[16:37] <pochu> rexbron: nope
[16:37] <rexbron> cool
[16:37] <pochu> neither does Vcs-Browser
[16:37] <pochu> (or Vcs-*)
[16:38]  * persia notes that it in fact oughtn't have it, but that it's not worth a variance from Debian, as in most cases we should be stripping vcs-* when modifying a package anyway
[16:46] <soren> persia: Or prepending X-Original- (as some of us have done during merging).
[16:46] <soren> Er... make that "XS-Original-".
[16:47] <persia> soren: That's even better.  Maybe we should come up with a common standard for the next merge cycle?
[16:48] <soren> persia: I belive that *is* the standard? I think it was briefly discussed on one of the mailing lists (shortly before DIF).
[16:48]  * ScottK hopes soren will write a wiki page on the matter then (if not already done).
[16:50] <persia> soren: I can't find it in my mailspool (but I may not be using the right search terms).  I wouldn't consider it accepted and official unless it was documented as best practice on the merging page (not that I currently agree with everything there, but a ML is a poor way to track policy)
[16:51] <soren> persia: I can't find it either, which puzzles me.
[16:51] <soren> persia: I distinctly remember discussing it somewhere.
[16:51] <persia> soren: I also remember discussion, but I thought it was a couple different IRC sessions, rather than the ML or in the context of a meeting.
[16:52] <soren> persia: I may be confusing things. I *know* I discussed it with cjwatson in e-mail, but I'm only 87% sure it got wider discussion on e-mail, but surely IRC.
[16:54] <soren> Well, it's not really a merging thing. It's something you should do whenever you change a package.
[16:54] <persia> soren: Surely IRC, but in a meeting?  Lots of things happen on IRC, but I don't think that makes them policy: more guidelines, or good practices, etc.  Moving from there to best practice to policy seems like it should be deliberate and documented.
[16:54] <soren> persia: I agree.
[16:54]  * soren ponders where to add it.
[16:55] <persia> True.  I'm not sure if we have a proper package adjustment page (and we ought).  There are several things to do: discussion XbuildY vs. XubuntuY, what control fields should change, etc.
[16:55] <soren> It's only something to remember during merging for the the hardy+1 cycle.
[16:55] <persia> I'd think under UbuntuDevelopment/ would be the right place, but I'm not sure what to call it.
[16:55] <soren> Same logic as the Original-Maintainer field.
[16:55] <persia> soren: One hopes.  We've still > 200 packages that don't comply with DebianMaintainerField :(
[16:55] <ScottK> soren: But the maintainer field thing was a spec
[16:56] <soren> ScottK: Yes.
[16:56] <persia> (and lots more binary packages that don't comply, but that's just a rebuild fix, which is easy)
[16:59] <Beber80> I've got a question about PPA. Am I in the right chat room ?
[16:59] <persia> Beber80: Depends on the question, but likely not.
[16:59] <persia> On the other hand, I don't think there is an active non-support PPA channel, so this might be your best bet.
[16:59] <Beber80> ok, so I'll try;)
[17:00] <ScottK> There's #launchpad
[17:00] <persia> Yes.  #launchpad is the place to ask for ppa support.
[17:00] <Beber80> I successfuly uploaded the files with dput but I can't see the package from the web interface
[17:01] <Beber80> ok, I'll have a look at #launchpad
[17:01] <persia> Yep.  That would be a support question.
[17:03] <mok0> A quick pointer to installing *.pc files using CDBS?
[17:04] <gnd_> Is something wrong with PPA? I have waited an hour now for the first package to appear.
[17:04] <mruiz> hi all
[17:04] <gnd_> dput says that it is already uploaded, but launchpad says it isn't.
[17:04] <Beber80> gnd_: I'm maybe experiencing the same pb...
[17:04] <Beber80> gnd_: same for me
[17:05] <ion_> mok0: debian/foo.install, see dh_install(1)
[17:05] <gnd_> Great i'm not the only one :D
[17:05] <persia> gnd_: You likely want #launchpad.  The both of you might consider starting a ppa channel to discuss ppa issues as well :)
[17:05] <persia> (let us know what it is called, if you do :) )
[17:05] <soren> mok0: You can add it from a post-build hook, perhaps?
[17:05] <Beber80> dput also tells me "Not running dinstall"
[17:05] <soren> Beber80: Don't worry about that.
[17:06] <soren> Beber80: It's just noise.
[17:06] <soren> mok0: Like: "install/packagename::\n\tcp $(CURDIR)/something.pc debian/tmp/usr/lib/pkg-config/"
[17:06] <soren> or something.
[17:06] <DktrKranz> persia: thanks for your mail.
[17:07] <mok0> soren: thx
[17:07] <soren> mok0: np :)
[17:08] <mok0> ls
[17:08] <persia> DktrKranz: Thanks for the response.  Great strides have been made, and I suspect we're almost there :)
[17:09] <mok0> oops wrong focus
[17:11] <DktrKranz> persia: my pleasure. Probably we still need to discuss on some points and to coordinate with other interested parties (and to fill our lack of public announcments). After that, we can have a rocking policy.
[17:11] <imbrandon> persia: re:sru mailing list, not that i'm aware, we agreed to just use the -motu ML when needed
[17:11] <imbrandon> unless it becomes an issue
[17:12] <persia> imbrandon: Makes sense.  It was just to save me collecting all your names & emails from LP.  Doesn't matter now :)
[17:12] <imbrandon> kk :)
[17:23] <pochu> Hmm, would you recommend me to use schroot with sbuild to build packages? As the buildds use sbuild, right?
[17:24] <pochu> I'm building anjuta with pbuilder and it's installing libneon27-dev although Build-Depends have libneon26-dev o.O
[17:24] <pochu> So I'm wondering whether that would happen with sbuild or not.
[17:32] <geser> pochu: pbuilder should also pick the right depends
[17:34] <pochu> Well it won't be the first time I successfully build something in my pbuilder but fails in the buildds
[17:34] <geser> pochu: right now I get unsatisfiable build-depends for anjuta (amd64)
[17:34] <pochu> libneon26-dev?
[17:35] <geser> pochu: the sbuild on the buildds may behave differently than the sbuild from the package
[17:35] <pochu> Oh, ok
[17:35] <geser> probably, I didn't check
[17:35] <pochu> It Build-Depends on libneon26-dev, but installed libneon26 libneon27 libneon27-dev
[17:36] <geser> hmm
[17:36] <pochu> Hmm, maybe because libneon26-dev Provies libneon-dev and libneon27-dev Provides and Replaces it too?
[17:36] <geser> libneon26-dev and libneon27-dev can't be installed at the same time
[17:36] <pochu> Provides*
[17:36] <geser> yes
[17:36] <pochu> But I'm B-D on libneon26-dev (!)
[17:37] <pochu> And libneon26-dev Provides and Replaces libneon-dev too
[17:37] <geser> and apt-get -s build-dep anjuta still works for you?
[17:37] <pochu> Maybe I should just B-D on libneon-dev and let it choose what install ;)
[17:37] <pochu> let me see
[17:38] <pochu> E: Build-dependencies for anjuta could not be satisfied.
[17:38] <pochu> So no pbuilder bug...
[17:38] <geser> pochu: libneon-dev seems to be a virtual package and one shouldn't build-depend only on a virtual-package
[17:38] <pochu> Ok, so maybe building with libneon27-dev directly?
[17:38] <minghua> pochu: Find why it's trying to install libneon26-dev and libneon27-dev at the same time and solve it. :-)
[17:38] <geser> yes
[17:38] <pochu> Dunno if that would be ok...
[17:39] <Kmos> pochu: the sbuild package is version 0.57.0, and ubuntu sbuild is 1.175.X :) is a fork
[17:39] <Kmos> debian sbuild is also different from the package they provide
[17:40]  * Kmos upgraging to hardy
[17:40]  * Kmos upgrading to hardy
[17:40] <Kmos> :)
[17:40] <pochu> Kmos: lol, that's a big fork :)
[17:40] <Kmos> pochu: hehe
[17:40] <pochu> minghua: do you mean some of the other build-depends is now depending on libneon27-dev?
[17:41] <geser> pochu: some of the Debian buildds report 99.99 as sbuild version and the Debian maintainer is searching for the source code
[17:41] <minghua> pochu: Most likely so.
[17:42] <pochu> minghua: hah! libsvn-dev
[17:43] <pochu> geser: heh, I guess upstream will be interested too ;)
[17:43] <pochu> Ok, let's try with libneon27-dev then. Thanks for the help :)
[17:51] <tuxmaniac> if there is a package available in debian but not in Ubuntu also I rasie a bug for sync request right?
[17:54] <pochu> geser, minghua: it worked. Thanks again.
[17:55] <minghua> tuxmaniac: Correct.  But be sure to specify reasons in the sync request for breaking DIF.
[17:55] <minghua> pochu: No problem.
[17:55] <tuxmaniac> DIF?
[17:55] <nxvl_work> how do i package a file for ppa? i cant upload it
[17:57] <minghua> tuxmaniac: Debian Import Freeze.
[17:57] <tuxmaniac> minghua, oops. Its over. I forgot :-(
[17:58] <pochu> tuxmaniac: if it's a new package it will likely be accepted if you say why it's useful
[17:58] <tuxmaniac> ok
[17:58] <minghua> tuxmaniac: It's okay.  You don't need a very strong reason, just make sure not just to say "Debian has it, so we should sync".
[17:59] <tuxmaniac> minghua, ofcourse. I have a reason. Its there on the MOTU Science team wiki for wishlist packages from Edgy
[18:00] <minghua> tuxmaniac: Go ahead, that's a good reason.
[18:02] <ScottK> We aren't to feature freeze yet, so there isn't a LOT of reason needed.
[18:06] <nxvl_work> how do i build a package on my PPA
[18:06] <nxvl_work> i have already upload the source
[18:09] <ScottK> nxvl_work: Ask in #launchpad
[18:09] <nxvl_work> oh right
[18:09] <nxvl_work> sorry
[18:09] <ScottK> No problem
[18:10] <tuxmaniac> do I have to subscribe any particular team like "Sponsors Universe" for the bug report to be acked?
[18:10] <pochu> Yes.
[18:16] <nxvl_work> tuxmaniac: ubuntu-universe-sponsors
[18:17] <tuxmaniac> nxvl_work, yeah thanks. got that one already
[18:22] <nxvl_work> i'm building a package, and i don't know why i'm getting /usr/lib when i "dpkg -L $package" does anyone knows how can i check it?
[18:24] <pochu> nxvl_work: python package?
[18:24] <nxvl_work> pochu: yep
[18:24] <nxvl_work> pochu: build using cdbs
[18:24] <pochu> nxvl_work: that's a bug in python-central or python-support
[18:24] <nxvl_work> so i don't need to worry about it?
[18:25] <bddebian> Heya gang
[18:25] <pochu> nxvl_work: Debian bug #452227
[18:25] <ubotu> Debian bug 452227 in python-central "Leaves empty /usr/lib in package" [Normal,Open] http://bugs.debian.org/452227
[18:25] <pochu> nxvl_work: nope, just ignore it.
[18:25] <nxvl_work> ok, thnx
[18:26] <LucidFox> https://launchpad.net/ubuntu/+source/inkblot/0.99.9-0ubuntu1 <-- What does "Failed to upload" mean?
[18:26] <geser> Hi bddebian
[18:28] <geser> LucidFox: this usually happens when the package is promoted/demoted while still in the build queue
[18:29] <LucidFox> What can be done about it?
[18:29] <geser> LucidFox: ask a build admin, I don't know (yet)
[18:30] <bddebian> Heya geser
[18:47] <bluefoxicy> this is awesome, firefox has more memory resident than all of windows XP
[18:47] <ion_> FF 3?
[18:48] <bluefoxicy> no, FF2
[18:48] <bluefoxicy> it had 810M Resident, while Vmware has 632
[18:48] <ion_> FF 2 + a bunch of extensions leaking memory + crap like Flash and Java are a sure way to eat all the RAM and a bit more. :-)
[18:48] <bluefoxicy> thunderbird has 641 resident.
[19:12] <imbrandon> Seveas: fyi, 2.0.4-0ubuntu1 uploaded , will make another sunday ( or close if its not ready for some reason ) for .5
[19:13] <Seveas> imbrandon, thanks! Do you have plans for debian as well?
[19:44] <imbrandon> Seveas: yea, i am working on plans for debian now too ( probably by the end of the weekend )
[20:03] <geser> RainCT: any progress on bug #164854?
[20:03] <ubotu> Launchpad bug 164854 in classpath "Please merge classpath 2:0.95-3 from Debian unstable" [Wishlist,Triaged] https://launchpad.net/bugs/164854
[20:07] <RainCT> geser: you can take it if you want
[20:08] <geser> RainCT: what questions did you have that stayed unanswered?
[20:10] <RainCT> geser: something about that Xb-Npp Firefox tags
[20:10] <RainCT> ah no
[20:11] <RainCT> 'bout the MOZILLA_CFLAGS I think.. I'm not sure thought.. I had forgotten about that merge :P
[20:36] <asac> RainCT: please keep the Xb-Npp tags
[20:37] <asac> if you are a hero, check in about:plugins if the set of supported mime-types has changed and add/update the mimetype npp line accordingly :)
[20:37] <RainCT> :P
[21:18] <ScottK> leonel: Clamav update is published in feisty-backports now too.  Thanks again.
[21:36] <leonel> ScottK:  Great    and  thank  YOU  really for your support
[21:42] <minghua> ScottK: Is that the last piece of clamav security updates?
[21:42] <ScottK> minghua: For feisty/gutsy, yes.
[21:42] <ScottK> dapper/edgy are horribly ancient.
[21:43] <ScottK> I think I've about got my nerve up to try a mass backport of clamav and it's rdepends to dapper.
[21:45] <ScottK> I know sgran is holding back a clamav update in Debian until 0.92 makes it into Lenny.  I'll probably do it after he uploads one more and we sync it in.
[21:46] <minghua> Oh, I forgot dapper.  But is edgy still supported?  When is its end of life?
[21:46] <ScottK> Edgy dies about the time Hardy is released.
[21:46] <minghua> Hmm, still a few months.
[21:47] <ScottK> I'm considering trying the backport there first because if I break it, it'll go away shortly.
[21:47]  * minghua praises ScottK for the great effort.
[21:47] <ScottK> Thanks.
[21:48] <ScottK> From a distribution perspective I think it's one of the more important packages in Universe.
[21:48] <minghua> You mean the packages in -backports can be just pulled without affecting other parts?
[21:49] <ScottK> No, I mean if I break edgy-backports and clamav or it's rdepends are messed up it goes out of support in ~ 3months.
[21:49] <ScottK> Dapper has another 3 years to go.
[21:52] <minghua> I see.
[21:52] <ScottK> Actually, the clamav in both those releases is old enough to be completely useless.  The downside risk is close to zero.
[21:53] <minghua> The packages in feisty-backports are the newest upstream version, aren't they?
[21:53] <minghua> You still risk breaking dpkg database and hose the whole package system, so trying edgy first sounds a good idea.
[21:56] <ScottK> minghua: feisty backports is 0.91.2 with all the security fixes from 0.92 patched in.  0.92 introduced a soname change in libclamav, so I'd have to backport rebuilds for about a dozen packages with it.
[21:56] <ScottK> So feisty-backports should be as secure as the current upstream, but freshclam will still complain.
[21:57] <minghua> So for feisty the rdepends don't need to be rebuilt?
[21:57] <minghua> feisty-bakcports, of course.
[21:57] <ScottK> Correct
[21:58] <ScottK> Managing the library transition in Hardy was relatively painless, so if edgy/dapper go well, I'll do feisty/gutsy eventually too.
[21:58] <minghua> And for dapper/edgy you plan a similar fix as in feisty?
[21:59] <minghua> Ah, so dapper/edgy is going to be 0.92, with rdepends rebuilds as well.
[21:59] <ScottK> Yes.  I'll backport 0.92, get that built and then backport the rdepends too.
[21:59] <ScottK> Yes.
[21:59] <ScottK> That's my plan.  Now all I need is a spare day of the week to sit down and test it all.
[21:59] <Fujitsu> ScottK: Have people tried to knock some sense into upstream?
[21:59] <ScottK> Fujitsu: They haven't succeeded.
[22:00] <leonel> ScottK: let me know that day  to help with that
[22:00] <ScottK> At least this time they appear to have packaged it sanely.
[22:00]  * Fujitsu strangles them.
[22:00] <ScottK> leonel: Sure.
[22:00] <ScottK> Fujitsu: Maybe you can convince LP to at least close the bugs against the right pocket when I fix stuff in backports...
[22:00] <geser> oh, cdrtools got removed from the archive again?
[22:01] <Fujitsu> ScottK: Oh, it didn't? Nice of it.
[22:02] <Fujitsu> Wait, Malone doesn't know about pockets.
[22:02] <ScottK> Fujitsu: See bug #182137
[22:02] <ubotu> Launchpad bug 182137 in launchpad "LP marks bug 'fix released' against wrong pocket" [Undecided,New] https://launchpad.net/bugs/182137
[22:02] <Fujitsu> (though it would be nice if we could track backport tasks sanely)
[22:02] <ScottK> Well it's an entirely separate project in LP.  You'd think that would be enough of a distinction.
[22:02] <Fujitsu> Urgh, that one wouldn't be easy to fix sanely.
[22:04] <ScottK> I've filed a bug, that's really all I can do ...
[22:05] <Fujitsu> Ideally, each targetted task could have a pocket selector, so one could mark each fix as being for -updates, -security, or -backports. That would also mean the appropriate teams could be notified, and there wouldn't be the gross *-backports project hack.
[22:07]  * ScottK is just a poor little user who just wants it to work sanely.
[22:07] <Fujitsu> That would be nice, yes.
[22:08] <ScottK> Conveniently enough, it's proprietary nature frees me of the obligation to do anything other than file the bug and expect instant results.
[22:08] <RainCT> is anyone from the release team (or whoever approves freeze exceptions) around?
[22:09] <geser> RainCT: which freeze exceptions? /me isn't aware of any freezes.
[22:09] <RainCT> feature freeze, once it's there
[22:09] <ScottK> RainCT: DIF just means autosync is turned off.  There is no freeze
[22:10] <ScottK> Ah.  We don't have a motu-uvf selected for Hardy yet AFAIK
[22:10] <geser> RainCT: I don't think we have a new motu-uvf team already
[22:10] <RainCT> oh. and when will there be one?
[22:10] <geser> hopefully before FF :)
[22:11] <RainCT> lol
[22:21] <blueyed> http://daniel.holba.ch/blog/?p=66
[22:22] <blueyed> Cheers! This is an awesome set!
[22:23]  * blueyed is in the middle of creating his MOTU application, but sooooo drunk already (KDE4, you know?) ;)
[22:25] <Hattory> Hi all.... I'm working to a merge for alogg package. In the last version of Ubuntu there is a file called postinst that is dropped from debian.... Should I keep it?
[22:32] <Hattory> the changelog says:  Drop useless debian/libalogg.postinst.
[22:32] <apachelogger> Riddell, stdin: is one of you around?
[22:33] <stdin> just about
[22:33] <apachelogger> Hattory: please paste the content
[22:34] <Hattory> apachelogger, a moment
[22:34] <apachelogger> stdin: I think teh best solution for the current icon problem (i.e. icons not available in hicolor but oxygen, hence not showing up for the desktop files) is to evaluate which apps actually ship their icons to hicolor and which don't so
[22:36] <Hattory> apachelogger, http://paste.ubuntu-nl.org/51594/
[22:36] <apachelogger> Hattory: drop it, it doesn't do anything
[22:36] <Hattory> apachelogger, ok thnks
[22:37] <stdin> apachelogger: seems most do, from what "dpkg -S usr/lib/kde4/share/icons/hicolor/" says
[22:38] <apachelogger> stdin: yeah, most important ones don't though ;-)
[22:38] <apachelogger> dolphin
[22:38] <apachelogger> systemsettings
[22:38] <apachelogger> konqueror
[22:38] <apachelogger> konsole
[22:38] <apachelogger> kwrite
[22:38] <apachelogger> kate
[22:39] <apachelogger> well, I think everything from base probably
[22:39] <stdin> apachelogger: konqueror does
[22:39] <apachelogger> stdin: yes, the old version
[22:40] <apachelogger> which makes oxygen rather pointless ;-)
[22:40] <stdin> no 4.0.0
[22:40] <stdin> konsole-kde4: kdelibs5-data: konqueror-kde4: kfind-kde4: all do for a start
[22:40] <apachelogger> stdin: have a look at the icons
[22:40] <apachelogger> they are not the oxygen versions
[22:41] <stdin> yeah, but konqueror-kde4 and the like don't install any oxygen icons
[22:41] <apachelogger> stdin: yeah, because the icons are in oxygen itself
[22:43] <stdin> then the answer is kdebase-data-kde4 kdebase-workspace-data, kdebase-workspace-data and kde-icons-oxygen from what I can tell so far are the only things to touch /oxygen/, but I haven't installed the whole of kde4 yet
[22:44] <apachelogger> stdin: yeah, I'm currently checking everything
[22:44] <apachelogger> also I think for some apps there are no oxygen icons yet
[22:44] <apachelogger> like for kappfinder
[22:44] <stdin> when you install everything, "dpkg -S usr/lib/kde4/share/icons/oxygen/|awk '{print $1}'|sort|uniq" is easy :)
[22:44] <apachelogger> aye :)
[22:45]  * Fujitsu wonders why the KDE4 fonts are so... unhinted.
[22:52] <rexbron> this is not fun, openlibs configure script installs to lib64 on 64bit arches. The problem is it breaks all of my .install files. Any thoughts?
[22:53]  * joejaxx wonders with Fujitsu on KDE4 and why he cannot change the position of the Panel
[22:55] <imbrandon> wow, /me walked into a kubuntu room
[22:55] <imbrandon> :)
[22:57] <somerville32> :)
[23:01]  * RainCT wonders to try out KDE4 :P
[23:01] <RainCT> eh.. s/wonders/goes lol
[23:05] <Fujitsu> Errrrm.
[23:06] <Fujitsu> Should I be able to drag the Plasma desktop around?
[23:06] <Fujitsu> Because in some situations I can.
[23:06] <dennda> So this is the place for packaging-wishes? :p
[23:11]  * dennda would love to see (at least) icewm 1.3.34 in hardy instead of 1.3.33... Any chance?
[23:11]  * Fujitsu can't seem to attach things to the kicker replacement, and can drag Plasmoids behind it, so they can't be retrieved. Nice one.
[23:12] <Fujitsu> It is shiny, but not finished.
[23:15]  * Fujitsu also wonders about the purpose of the selection box one can drag on the desktop, which seems to select a grand total of nothing.
[23:15]  * Fujitsu is unconvinced, and returns to GNOME.
[23:23] <joejaxx> Fujitsu: i cannot drag plasma aroudn
[23:23] <joejaxx> around*
[23:23] <joejaxx> it also does not extend to my other monitor
[23:24] <Fujitsu> joejaxx: Only in some circumstances can the Plasma background be dragged around. I somehow managed to click through one of the Plasmoids, I think.
[23:24] <joejaxx> anyway to extend it?
[23:24] <joejaxx> to the other screen
[23:24] <joejaxx> lol
[23:24] <joejaxx> because i have not found a way
[23:25] <ScottK> KDE 4.0 is release ready only in the sense that the APIs are stable.  Right now it's for enthusiasts and developers only.  Wait until 4.1 if you actually want it to be useful.
[23:25] <joejaxx> ScottK: just trying it out :)
[23:25] <bigon> talking about kde, could someone have a look at decibel, it currently FTBFS because of the kde4 path
[23:25] <ScottK> Sure, just don't expect to much.
[23:34] <Kano> hi, why is openscenegraph not installable with hardy?
[23:36] <Fujitsu> Kano: Because one of its libraries has not yet been migrated from libungif to libgif.
[23:37] <Kano> then migrate it
[23:37] <ion_> kano: Where did you post the debdiff?
[23:37] <Fujitsu> Why don't you?
[23:38] <Kano> why should i?
[23:38] <Fujitsu> Why should I?
[23:38] <ion_> Why should i?
[23:38] <Kano> well it is stupid to have no openscenegraph
[23:38] <Kano> then gl2benchmark does not work
[23:38] <Fujitsu> Many would say it's stupid to expect Hardy to work.
[23:38] <ion_> Feel free to migrate it. That’s a simple way to get rid of said stupidness.
[23:38]  * ScottK gets popcorn
[23:38] <ion_> scottk: ;-)
[23:38]  * Fujitsu delegates the fixing to ScottK.
[23:39]  * ion_ delegates the fixing to popcorn.
[23:39]  * ScottK puts in on the list.
[23:39]  * ScottK has a very long list.
[23:39] <ajmitch> ScottK: be sure to put it right at the bottom, please
[23:39] <TheMuso> Heya ajmitch!
[23:39] <ajmitch> I'm not here
[23:39] <TheMuso> Oh no, of course not.
[23:40]  * ajmitch has no internet connection at home
[23:42] <ion_> There’s a Finnish job ad in the tubes with a programming puzzle you need to solve to get the recruitment e-mail address. The puzzle contains a grammar error. So, i emailed the resulting address with a polite message saying i’m not interested of a job at the moment and pointing out the error. I also attached my solution just for fun. ;-)
[23:42] <ion_> Whoops, wrong channel.
[23:45] <ion_> Heh, someone suggested the error was there intentionally so that they can filter out nitpicks. ;-)
[23:53] <Kano> why is it impossible to search for content on hardy?
[23:54] <Kano> looks like incomplete web update
[23:55] <Fujitsu> ... what?
[23:56] <Fujitsu> Hardy doesn't have the web on it, so I doubt it would have a web update at all, let alone an incomplete one.
[23:56] <Kano> well you can not select it on packages.ubuntu.com
[23:56] <Kano> but you can edit the line from gutsy to hardy
[23:56] <Fujitsu> That's normal.
[23:56] <Kano> so webfrontend needs an update
[23:58] <Fujitsu> Or perhaps people who expect everything to work flawlessly shouldn't be using the development version.
[23:58] <Kano> btw. if you recompile osg
[23:59] <Kano> it would be better to add one build-dep
[23:59] <Fujitsu> File a bug, then. It will be lost here.
[23:59] <Kano> http://kanotix.com/files/fix/openscenegraph/openscenegraph/openscenegraph_2.2.0-2+c0.kanotix.1.dsc
[23:59] <Kano> check this