[00:29] <zooko_osg> FYI: Tahoe-LAFS project plans our final push to get Tahoe-LAFS released in time to be included in Lucid: http://allmydata.org/pipermail/tahoe-dev/2010-January/003564.html
[00:37] <zooko_osg> ScottK: please notice how cool Tahoe-LAFS is today --^
[00:37] <zooko_osg> Okay, gotta leave work and head home.
[00:48]  * ScottK notes that there are idle buildds on all archs: https://launchpad.net/builders
[00:48] <micahg> ScottK: is that a challenge? :)
[00:49] <ScottK> Yes.
[01:21] <micahg> are we still updating sun-java6 or is that done with?
[01:45] <ScottK> I think Canonical needs to deal with Sun Java, but I think the intent is still to have it go away.
[02:53] <persia> sivang: You may be interested in https://wiki.ubuntu.com/UbuntuDevelopers If you're reapplying for a development status you had previously, an abbreviated procedure may be available: contact the relevant approval team.
[03:31] <ScottK> geser: You TIL debian-xcontrol.  I'm trying to get rid of boost1.38 build-deps and this does not build with 1.40.  Looking in Debian I see it's never, ever made it into Testing and I'm thinking removal might be the best option.  What do you think?
[03:38] <statik> what does TIL mean?
[03:38] <crimsun> "touched it last"
[03:39] <crimsun> i.e., "you were the last person to work on source package foo"
[03:43] <RAOF> aka: “tag, you're it!”
[03:55] <micahg> are we allowed to update sun-java6 from unstable?
[04:11] <persia> micahg: I don't see any reason why we couldn't, although I wouldn't recommend sun-java6 for end-user installation.
[04:11] <micahg> persia: well, until it's removed from archive, we should keep its security up to date, right?
[04:12] <micahg> or switched to partner
[04:12] <persia> I guess.  I tried to do that for sun-java5 for a while, but it ended up being very difficult to keep track of stuff.
[04:13] <micahg> how so?
[04:13] <persia> I don't think it could switch to partner, as such.  Population of multiverse and partner are handled not only by different policies, but by different organisations.
[04:13]  * micahg doesn't want to make things worse
[04:13] <persia> The big issue I had wasn't bringing it into the current development target, it was that having done so I ended up being TIL, and expected to get the SRUs done.
[04:14] <micahg> TIL?
[04:14] <persia> Writing the TEST CASE entries for the bugfixes was more than I could handle.
[04:14] <persia> touched-it-last
[04:14] <persia> The person who most recently indicated that they cared about the package.
[04:14] <micahg> ah, I thought there's an exception to that on the SRU page now
[04:14] <micahg> it just has to install
[04:14] <persia> If there's an exception for sun-java, then it ought be easy.
[04:14] <micahg> k
[04:15] <persia> Just update it, and then do the SRU processing.
[04:15] <micahg> so, I figure I'll request a sync for lucid and once it's there, make the diffs for Intrepid->karmic
[04:15] <micahg> hardy was already done by doko
[04:15] <persia> But, again, I think most users would be better served by openjdk.  I know that at UDS Jaunty, engineers from Sun were present and suggested that openjdk was the right choice.
[04:15] <persia> I also spoke with some Sun engineers at UDS Karmic (about other stuff), but everything was targeted to use openJDK.
[04:15] <micahg> well, there's no exception for that
[04:16] <micahg> so that would be a nightmare to backport...
[04:16] <persia> I didn't see anyone from Sun at UDS Lucid, but that may be because they believe it to be a solved problem.
[04:16] <persia> OpenJDK doesn't need backporting as much: it's open-source, with open tracking of security issues.
[04:16] <micahg> but it's still in the archive...
[04:17] <persia> Well, file a bug to remove it then (but first do the SRUs for previously supported releases).
[04:17] <persia> I don't expect we want to support it for the entire Lucid timeframe, as I'm fairly sure Sun isn't going to offer us support.
[04:17]  * persia double-checks
[04:19] <micahg> persia: there's a blueprint already working on moving it to partner: https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-lucid-dropping-sun-java6
[04:20] <micahg> so I should just focus on the older releases then, right?
[04:20] <persia> micahg: Interesting: looks like the plan *is* to move to partner.
[04:20] <micahg> right
[04:21] <persia> Personally, I think the SRUs are the only important bit, because for hardy we didn't have a 100% compliant OpenJDK (although it was about 95% compliant)
[04:21] <crimsun> 3[A[A[A[A[A[A33nope
[04:21] <persia> crimsun: ?
[04:23] <persia> micahg: I don't think the last issues that made OpenJDK a complete solution were solved until Karmic (although fixing plugin-finder might make it even better), but Jaunty and Hardy would definitely benefit.
[04:26] <crimsun> sorry, no love for my wireless device
[04:27] <micahg> maybe I should try the openjdk version...
[04:27] <persia> Hrm.  I may be reading things wrong, but it looks to me like Java 6 was released in early 2007 and Sun offers 3 years support from the release date for free downloads (according to http://www.sun.com/software/javaforbusiness/support.jsp)
[04:27] <micahg> is there a 7 yet?
[04:28] <persia> So, either Sun is extending support until Java 7 (based on OpenJDK) is available, or the 3 years of support counter gets reset for each update.
[04:28] <persia> 7 has been being planned for some time.  I'm not aware of the current status.
[04:29] <persia> Yeah, I think free sun-java6 should be going out of support soon: "Use the traditional Java SE free-of-charge and have access to updates for three years from the time of Java SE product family release" really seems to imply the first release, rather than updates.
[04:30] <persia> (but I'm not authoritative: ask Sun for a real answer)
[05:51] <fabrice_sp> :CAP REQ IDENTIFY-MSG
[05:51] <fabrice_sp> sorry
[06:33] <dholbach> good morning
[08:09] <slytherin> ttx: busy? need to discuss something about likewise-open
[08:10] <ttx> slytherin: shoot
[08:11] <slytherin> ttx: My friend has successfully joined a Ubuntu laptop to Windows domain. Now when he logs in using domain user he is does not see network-manager applet in panel. Any idea what could be wrong?
[08:11] <ttx> hmm, I'd say missing admin rights
[08:12] <ttx> i.e. the WINDOWSDOMAIN\user isn't in the required group
[08:12] <slytherin> he has added the user to sudoers list. When trying to launch nm-applet from command line he sees some dbus related warning.
[08:13] <slytherin> from warning it looks like NM is not letting non-local user launch the applet.
[08:13] <ttx> slytherin: did he check he can sudo ?
[08:13] <ttx> slytherin: hm
[08:13] <slytherin> yes, he can. He can launch synaptic and install packages.
[08:13] <ttx> slytherin: maybe NM has funny ways to look at the user list
[08:14] <ttx> slytherin: if getent shows his user, then NM should be ahappy about it
[08:14] <ttx> slytherin: is that 4 or 5 ?
[08:14] <slytherin> 5
[08:15] <ttx> I'd say it's an NM bug
[08:15] <ttx> the rest of the system seems happy with that user
[08:16] <ttx> slytherin: testing a lucid alpha2 livecd to check if the new 5.4 works better would be great though
[08:16] <slytherin> ttx: nah, that would be too much to ask. It is not as if he has nothing better to do. :-)
[08:17] <slytherin> ttx: I am wondering if settings in file /etc/dbus-1/system.d/NetworkManager.conf are causing problem
[08:36] <jariq> Could someone pls review package ipwatchd - http://revu.ubuntuwire.com/p/ipwatchd ?
[08:51] <hakaishi> Could someone please review package qt-shutdown-p http://revu.ubuntuwire.com/p/qt-shutdown-p
[09:09] <slytherin> Does anyone know why maven in repository uses source=1.3 by default?
[09:25] <geser> ScottK: although I've only done rebuilds of debian-xcontrol, I think that its removal sounds sane
[10:50] <shriekout> hi
[10:50] <shriekout> how seek 'config.log' in launchpad?
[10:50] <shriekout> http://launchpadlibrarian.net/37879616/buildlog_ubuntu-karmic-i386.cubrid_8.2.1.0215-ubuntu3_FAILEDTOBUILD.txt.gz
[10:55] <geser> can you reproduce this in a pbuilder? (as this would be the fastest way)
[10:56] <shriekout> hmm..
[10:56] <shriekout> how reproduce?
[10:57] <geser> try to build it in your pbuilder and see if it happens there too
[10:58] <geser> if it only happens on the buildd (or you don't have a pbuilder to test) you need to do a new upload which "cat config.log" (so it appears in the build log) if configure fails
[10:58] <geser> (I had to do this already at least once, it's no fun to do debugging this way)
[10:58] <shriekout> success... my desktop
[11:00] <shriekout> ...
[11:03] <geser> in that case try "./configure --with-jdk=/usr/lib/jvm/default-java || cat config.log" in your rules (and reupload)
[11:04] <shriekout> thanks. :)
[11:07] <geser> but I can give you the error on amd64 if you're intersted
[11:07] <shriekout> thanks... :)
[11:10] <shriekout> reuploaded... i read https://wiki.ubuntu.com/PbuilderHowto
[11:10] <shriekout> thank geser :)
[11:15] <ScottK> geser: Thanks.  Removal requested.
[14:04] <barry> ScottK, POX did i remember incorrectly, or were one of you updating python-setuptools to version 0.6.10 to get the latest version of setuptools?  i uploaded a ppa for lucid for python-munepy but it fails to build because it's trying to download distribute-0.6.10.tar.gz.  i haven't tried it yet, but i'm guessing putting that in my ppa will fix the problem
[14:05] <ScottK> barry: That's the one that we said needed to be looked at to see if it was a sync or a merge.  IIRC you were going to look at it.
[14:05] <ScottK> stdeb was the one that could be sync'ed and I did that.
[14:05] <barry> ScottK: cool (thanks for the stdeb one).  i was on leave yesterday, so i'll look at that today
[14:24] <coolbhavi> hey all I am working on merge of jigdo but patch is not applying http://launchpadlibrarian.net/37884143/buildlog_ubuntu-lucid-amd64.jigdo_0.7.3-3ubuntu3_FAILEDTOBUILD.txt.gz here is the dsc https://edge.launchpad.net/~bhavi/+archive/crickinfo/+files/jigdo_0.7.3-3ubuntu3.dsc anyone pls help
[14:25] <dholbach> highvoltage: so it seems we need more publicity for the docs, the sessions (although we've been slacking there for a bit now) and developer week? :)
[14:26] <highvoltage> dholbach: heh, indeed. I was just thinking that I could blog about it
[14:26] <highvoltage> dholbach: and sorry for all the noise
[14:26] <dholbach> no worries... I was interested what we could probably improve :)
[14:28] <slytherin> coolbhavi: What all Ubuntu changes need to be carried over?
[14:28] <benc1> how hard is it to make a self package that uses an old package and just update the source?
[14:28] <coolbhavi> slytherin, the patch needs to be carried over
[14:29] <slytherin> benc1: depends on the package, sometimes 'uscan; dpkg-buildpackage' is all you need.
[14:29] <highvoltage> dholbach: there's probably a news item or something I missed, but what happened with the 'future of motu' discussions at UDS wrt to the archive reorganisation? Is motu still going to be around for the packages that no one else cares about?
[14:29] <coolbhavi> slytherin, I refreshed the patch yet its not applying
[14:29] <slytherin> coolbhavi: Can you paste the build log in plain text somewhere?
[14:29] <strycore> Hi
[14:30] <coolbhavi> slytherin, sure
[14:30] <dholbach> highvoltage: as far as I know ScottK and cjwatson wanted to write something up about it
[14:30] <strycore> Ok to change the ML link in https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases from karmic to lucid ?
[14:30] <benc1> slytherin: I want to update this package to ejabberd 2.1 http://packages.ubuntu.com/karmic/ejabberd
[14:30] <dholbach> strycore: sounds reasonable
[14:31] <coolbhavi> slytherin, http://paste.ubuntu.com/356587/
[14:31] <cjwatson> highvoltage: https://wiki.ubuntu.com/Specs/LucidMOTU is persia's draft which we need to get round to finishing up
[14:31] <cjwatson> highvoltage: yes, motu will still be around
[14:31] <highvoltage> thanks for the link cjwatson
[14:31] <strycore> I'll also change links for the development forums and the archive status page
[14:33] <vish> dholbach: hi.. off topic here , but couldnt find you on -bugs.   the 5-a-day stats are not updating? ;)   I'v changed my lp name nearly a month ago and it is still stuck with my old name and stats :(
[14:33] <dholbach> vish: http://qa.ubuntu.com/reports/five-a-day/ Last updated at: Thu, 14 Jan 2010 12:32:46 +0000
[14:33] <dholbach> vish: do you think you can talk to bdmurray about it?
[14:34] <vish>  yeah sure, it says that but , its not really updating ;) i'll mention to bdmurray
[14:34] <dholbach> ok perfect, thanks
[14:35] <vish> thanks :)
[14:35] <slytherin> coolbhavi: Can you also paste the patch file somewhere?
[14:36] <coolbhavi> slytherin, its too big to be pasted :( so I ve provided the dsc
[14:36] <benc1> can someone give my hints how to self update a package to support recent version of a server?
[14:37] <slytherin> coolbhavi: unfortunately I can not download in the network I am. use pastebinit.
[14:37] <benc1> there is a debian package but I'm not sure it is safe to use
[14:42] <coolbhavi> slytherin, http://fpaste.org/GBSB/
[14:44] <coolbhavi> slytherin,  http://paste.ubuntu.com/356587/ <-- Buildlog
[14:49] <coolbhavi> slytherin, It patches 2 files first one is getting patched correctly 2nd file the error is coming
[14:50] <coolbhavi> at line 653
[14:50] <slytherin> coolbhavi: Have you checked if scripts/jigdo-lite exists and the location has not changed in upstream source?
[14:50] <coolbhavi> slytherin, yes
[14:51] <coolbhavi> slytherin, if not there would have been an error like patch hunk failed
[14:51] <slytherin> I am wondering what malformed patch means.
[14:52] <dholbach> edited by hand maybe?
[14:52] <coolbhavi> dholbach, no
[14:52] <dholbach> or missing newline at the end or something
[14:52] <dholbach> best to regenerate the patch and try again :)
[14:53] <coolbhavi> dholbach, I just changed the line which the patch is going to be applied
[14:53] <dholbach> so you edited it by hand :)
[14:54] <Quintasan> Hiho
[14:54] <coolbhavi> i.e from 468 to 470 only that no i changed dholbach
[14:55] <dholbach> coolbhavi: I personally would regenerate the patch
[14:56] <coolbhavi> dholbach, how to do there are lots of lines there
[14:57] <coolbhavi> dholbach, might be my question was dumb .. but please help
[14:57] <dholbach> how did you generate the first patch before you edited it?
[15:00] <slytherin> coolbhavi: Found the problem. Looks like you did not use dpatch-edit-patch to edit the patch.
[15:00] <coolbhavi> slytherin, first part I did that thing
[15:00] <slytherin> coolbhavi: there is no @DPATCH@ just before line 653
[15:01] <dholbach> https://wiki.ubuntu.com/PackagingGuide/PatchSystems#dpatch
[15:01] <coolbhavi> 2nd part wasnt sure
[15:01] <coolbhavi> okay got it
[15:01] <dholbach> don't edit a patch by hand - there's always a tool to generate it for you :)
[15:01] <coolbhavi> dholbach, okay thanks
[15:02] <slytherin> coolbhavi: What you can do is remove the lines from 653 to the end. Then you can use dptach to edit the patch properly.
[15:25] <coolbhavi> slytherin, the old patch isnt applying to edit
[15:25] <coolbhavi> now how to refresh?
[15:27] <slytherin> coolbhavi: I told you - remove lines from 653 to end from the patch
[15:42] <coolbhavi> slytherin, now what do I do? http://paste.ubuntu.com/356624/
[15:44] <slytherin> coolbhavi: Can't help much without access to the source (which I can not download at the moment). How about you start from scratch?
[15:44] <coolbhavi> slytherin, I have deleted line 653 onwards hmm
[15:45] <slytherin> coolbhavi: Sorry, but got to go home. Will try to help later if I am online.
[15:45] <coolbhavi> dholbach, can you please help me?
[15:45] <slytherin> coolbhavi: I suggest that starting from scratch will save time.
[15:45]  * coolbhavi feels quilt is magic
[15:46] <dholbach> coolbhavi: just regenerate the patch
[15:46] <dholbach> it's no use trying to edit the patch by hand
[15:46] <dholbach> there's too much you can get wrong easily
[15:47] <dholbach> I know that quilt is a pain, but still better to use it than to edit the patch by hand
[15:47] <dholbach> https://wiki.ubuntu.com/PackagingGuide/PatchSystems#quilt (example package: xterm)
[15:47] <coolbhavi> dholbach, previous patch doesnt apply now how to regenerate using dpatch? dpatch-edit-patch isnt working
[15:48] <dholbach> where did you get the patch from?
[15:48] <coolbhavi> from the merge
[15:49] <coolbhavi> ../grab-merge.sh
[15:49] <dholbach> does applying the patch not work at all or is it just the last hunk?
[15:50] <coolbhavi> dholbach, just last hunk from 653 onwards
[15:50] <dholbach> then use the .rej file and fix whatever's to fix manually
[15:51] <coolbhavi> dholbach, wait a sec pls
[15:52] <dholbach> sure, take your time - I'm having a look at something else at the moment
[15:54] <coolbhavi> dholbach, m not finding any .rej in the source now
[15:54]  * coolbhavi feels weird
[15:55] <dholbach> coolbhavi: then have a look at the patch file and apply the changes of the last hunk by hand
[15:56] <coolbhavi> did that so m getting that malformed patch error
[15:59]  * coolbhavi tells dholbach that he is in a dizzy and goes to dinner
[16:00] <lfaraone> If package "autokey" uses GTK in karmic, and in sid/lucid it'll be renamed to "autokey-gtk", with "autokey" being a redesigned-by-upstream-QT-based-interface, how should the transition be handled, if at all?
[16:00] <maco> i think you'll need transitional packages
[16:01] <maco> have an autokey-qt in lucid
[16:01] <maco> oh wait
[16:01] <maco> hrmph
[16:02] <dholbach> coolbhavi: how do you get that error when you do changes to the file manually (not to the patch, but to the file that is being modified by the patch)
[16:02] <maco> have autokey-gtk conflict/replace autokey
[16:02] <ScottK> maco: Why?
[16:02] <maco> ScottK: is that how you do it?
[16:02] <maco> if you want to make sure that an upgrader who has autokey installed gets switched over to autokey-gtk, i thought that was how?
[16:02] <ScottK> I'd say leave it be.  If upstream has redone their primary interface, users should get that.
[16:03] <maco> (i havent done this before, obviously)
[16:03] <ScottK> If someone wants the old gtk stuff, they can go look for it.
[16:03] <lfaraone> They're continuing to offer autokey-gtk, and are still releaseing new updates, but their focus is autokey (QT).
[16:03] <ScottK> Simpler answer is don't deviate from Debian over this.
[16:05] <lfaraone> ScottK: well, I'm the maintainer in Debian, so we can do whatever we want :P
[16:05] <ScottK> Ah.
[16:05] <lfaraone> (it wasn't in lenny, so we don't have to worry about a transition over there)
[16:05] <ScottK> My advice would be not to do anything.
[16:06] <ScottK> Make autokey the primary one and let people hunt down -gtk if they want it.
[16:06] <lfaraone> (right now autokey-gtk isn't uploaded, I'm procrastinating since it'd mean a new source package. (due to the way upstrem distributes it))
[16:06] <ScottK> In general I think users are more interested in getting the latest stuff than what toolkit it was implemented in.
[16:06] <ScottK> With V3 source packages you can put multiple upstream tarballs in one source package.
[16:08] <lfaraone> ScottK: if I use v3, do I have to use quilt for patches? argh, all I need is simple-patchsys...
[16:08] <ScottK> Up to you
[16:11] <lfaraone> ScottK: right now the upsream packages conflict with each other due to different conffile formats <_<;
[16:11] <ScottK> Oh
[16:13] <lfaraone> ScottK: I mean, it's for a silly reason, but it'd take some engineering which goes beyond my python knowledge to fix. (they'd have to change the module names,
[16:13] <lfaraone> which breaks backwards compatibility, since they use pickle to store data. )
[16:17] <barry> ScottK: woot!  okay, i'm going to look at the distribute changes after lunch, but adding a distribute/python-setuptools package to my ppa fixed my munepy ppa build problem on lucid.  so that's good :)
[16:26] <ScottK> barry: Only sort of.  It's better to patch it so it doesn't try to download stuff at all.
[16:34] <coolbhavi> dholbach, when applied inline its fine
[17:53] <hyperair> to whoever uploaded codelite for me, thanks
[17:54] <jpds> hyperair: That would be dholbach.
[17:54] <hyperair> how do you tell?
[17:55] <jpds> Launchpad knows all.
[17:55] <jpds> hyperair: https://edge.launchpad.net/ubuntu/+source/codelite/2.1.0.3584+dfsg-0ubuntu1
[17:55] <hyperair> ah
[17:55] <hyperair> hehe
[18:18] <hakaishi> Hi! Could someone please review package qt-shutdown-p? http://revu.ubuntuwire.com/p/qt-shutdown-p
[18:33] <micahg> mr_pouit: are you around?
[18:48] <mr_pouit> micahg: yep
[18:49] <mr_pouit> I think I have to sponsor a sru abour xfpm and I forgot ;]
[18:50] <micahg> mr_pouit: I wanted to let you know it was a problem with my notification system
[18:50] <micahg> I was still using notification daemon
[18:50] <micahg> about the xpm icons
[18:52] <mr_pouit> ah, ok
[18:53] <micahg> mr_pouit: I did have a weird xfpm quit this morning, but I think it's a one-off situation, I'll open a bug if it happens again
[18:53] <micahg> mr_pouit: do you need the bug # for the SRU?
[18:54] <mr_pouit> micahg: yeah, because I can't find it anymore ;>
[18:56] <micahg> mr_pouit: bug 455089, but I don't think it has the latest debdiff...
[18:56] <micahg> let me update the debdiff quick
[19:03] <micahg> mr_pouit: updated
[19:08] <mr_pouit> okay, test-building & uploading
[19:10] <barry> ScottK: ping
[19:10] <ScottK> barry: Pong
[19:11] <barry> hi ScottK, so i'm looking at the source package for distribute 0.6.8-1ubuntu2 in lucid.  iiuc, the issue is to try to determine what changes have been added to the ubuntu package from the debian package right?
[19:12] <ScottK> barry: Yes.
[19:13] <ScottK> I'd grab 0.6.8-1 and diff them to see.
[19:13] <ScottK> Often debian/changelog has enough information for you to know if the diff is worth maintaining.
[19:14] <barry> ScottK: i'm looking at the change log.  there are only two lucid specific changes that i can see: one is to fix lp bug 490731 which deletes the egg-info directory (if it's not a symlink) and the other is to build only for py25 and 26
[19:15] <barry> ScottK: i believe you even reviewed and approved the former
[19:15] <ScottK> IIRC yes.
[19:15] <ScottK> We need to build only for py26 now.
[19:15] <barry> necessary if updating from 0.6c9
[19:16] <barry> so i think both changes make sense
[19:16] <ScottK> OK.  So then it's a merge.
[19:16] <barry> cool.  what can i do to help?
[19:17] <ScottK> Prepare an updated version that is the new Debian stuff plus our changes and then either attach a debdiff (from debian to your proposed package) or push a branch somewhere and attach to a bug for spsonsors to review
[19:18] <barry> ScottK: cool.  i think i can do that (and will probably do the latter).  thanks
[19:18] <ScottK> OK.  Then subscribe ubuntu-main-sponsors to the bug when it's ready
[19:18] <barry> +1
[20:02] <barry> ScottK: okay, i have another dumb question.  i've started by branching lp:ubuntu/lucid/distribute.  now what?  what i did was unpack sid's distribute_0.6.10.orig.tar.gz into that branch and then tried to build it using debuild.  it failed in sphinx (building the docs).  i'm not honestly sure what i did is the "right way" to upgrade the package though.
[20:03] <ScottK> barry: I sent a mail to ubuntu-devel the other day saying I was taking a break from merges until I could figure out the new fangled UDD way of doing it.
[20:03]  * ScottK is not the right guy to ask.
[20:03] <barry> ScottK: understood! i guess it's time to go to the mlist :)
[20:03]  * barry likes blazing trails
[20:04] <ScottK> That or stare in the direction of james_w until he appears and saves the day
[20:04]  * barry stares at james_w 
[20:04] <micahg> barry: there a starter wiki page
[20:04] <micahg> barry: https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging
[20:05] <micahg> beyond that I don't know
[20:05] <barry> micahg: thanks.  will read
[20:05] <james_w> barry: you are merging from sid?
[20:06] <ScottK> barry: While you're looking at distribute, do you think that instead of patching it for specific python versions it might be better to just take the output of pyversions -s?
[20:06] <barry> james_w: that's what i'm attempting to do: update lucid's distribute package to sid w/o losing ubuntu specific changes
[20:06] <james_w> barry: the page micahg pointed out is the way to do that
[20:06] <barry> ScottK: that's probably a good idea
[20:07] <james_w> bzr merge-package lp:debian/sid/distribute
[20:07] <barry> james_w: awesome thanks.  ScottK i'll look at adding that change
[20:07] <ScottK> barry: That change could go back to Debian too if it works out.
[20:07] <barry> james_w: btw, i've been muddling through packaging a brand new package using the udd way.  i have a set of notes that i'll be emailing the list, but is there a wiki page for that workflow?
[20:08] <barry> ScottK: right.  i'm not yet sure how to do that, but i'll ask when i get there :)
[20:08] <ScottK> OK.
[20:08] <ScottK> barry: Since doko is the maintainer in Debian it'll be easy to find someone to discuss it with.
[20:08] <james_w> barry: no, but there should be, feel free to dump your notes in to a new page and we can work out cleaning it up if needed
[20:08] <james_w> thanks
[20:09] <barry> james_w: cool, will do both.  i actually think for a python package we're real close, but it's a bit like the intercontinental railway.  3000 miles and the rails only *almost* line up :)
[20:10] <james_w> heh
[20:10] <POX> barry, ScottK: you know that distribute is just one of hunderets of packages affected by #552595, do you really want to fix all of them?
[20:10] <geser> I see you are talking about merging distribute, if I understood POX correctly the second Ubuntu delta to distribute can be dropped when python-central gets fixed
[20:10] <POX> I think we have a solution for #552595 so just wait for Debian
[20:11] <ScottK> POX: OK.  I think we should keep the workaround in distribute until we get the fixed pycentral from Debian.
[20:11] <barry> POX, geser right.  there's a workaround in preinst for that one, right?
[20:11] <barry> (currently)
[20:12] <geser> yes, I didn't know at that time that this is a bug of python-central and not python-setuptools (from distribute)
[20:13] <POX> where can I find list of files shipped by ubuntu packages?
[20:13] <geser> packages.ubuntu.com
[20:13] <POX> something like http://packages.debian.org/sid/all/python-setuptools/filelist
[20:14] <geser> POX: http://packages.ubuntu.com/karmic/all/python-setuptools/filelist
[20:14] <POX> got it (http://packages.ubuntu.com/lucid/all/python-setuptools/filelist)
[20:14]  * barry needs to reboot a server and might lose connectivity for a short bit
[21:01]  * persia idly mentions the existence of editpatch from the patchutils package (doesn't work so well for dpatch)
[21:02] <ScottK> But that has it's own edit-patch
[23:25] <blizzkid> hi all. Was just thinking, how hard would it be for a good devver to create a tool that takes the generic kernel config and strips out the hardware support not needed for a specific machine?
[23:25] <blizzkid> That would build a semi-custom kernel adapted to one's hardare and keep in the needed other modules
[23:36] <persia> blizzkid: It's not that hard, but the default config builds most of the stuff that isn't present on nearly every machine as modules, which achieves most of the same effects.
[23:37] <persia> Not building the module conceivably saves a small amount of secondary storage (usually kilobytes per module), but then reduces flexibility.
[23:37] <persia> But if you want real details on whether this would have any benefit and what needs to be done, you'd do better to ask in #ubuntu-kernel
[23:38] <blizzkid> ok, persia, I'll do that
[23:43] <directhex> blizzkid, not much point. the kernels are highly modular. the drivers you don't need simply aren't loaded
[23:44] <blizzkid> directhex: hmm, then is there still a use for custom kernel vs generic?
[23:44] <persia> Not so much
[23:44] <directhex> blizzkid, i haven't compiled a kernel for about 6 years...
[23:44]  * persia looks up the blog post that decided the Ubuntu kernel was the only one to use
[23:45] <directhex> actually, i remember, the last kernel i compiled was 2.6.12
[23:45] <directhex> how old is 2.6.12?
[23:45] <blizzkid> that's been a while indeed
[23:46] <directhex> i had to apply a random patch from a mailing list to make my sata controller work, and needed 2.6.12 to make my tv card work. this was on debian
[23:46] <persia> Bah.  I can't find it: my archives are insufficiently complete from that long ago.
[23:47] <blizzkid> lol persia
[23:48] <persia> No, really.  There was this post back in 2004 or 2005 where one of the Ubuntu developers had been compiling their own kernel and something broke and they described at length why they weren't going to do it again.
[23:48] <persia> Unfortuately, none of the archive tools I know can find it with my vague memory of it.
[23:48] <blizzkid> that would be a nice read indeed