[01:23] <ScottK> sistpoty: I discussed Eric with lex79 on #kubuntu-devel.  He's going to look into 4.4.2 from Unstable.
[01:23] <sistpoty> ScottK: excellent, thanks!
[08:23] <pmcenery> bug #558946
[08:23] <pmcenery> How do I create an install log? piuparts?
[08:24] <pmcenery> I have a sbuild install log which I can attach, but I wasnt sure of the best way to create an install log. Any pointers would be much appreciated...
[08:26] <iulian> pmcenery: dpkg --install the package and attach the log to the bug report.
[08:29] <pmcenery> iulian: thanks. Is that log just the output to the terminal, or was there some /var/log file you refer to?
[08:30] <iulian> pmcenery: The former.
[08:30] <pmcenery> iulian: ok. thanks. will do that
[08:30] <iulian> You're welcome.
[13:39] <xteejx> Hey guys, is the package wallpaper-tray going to be in Lucid, there is no publishing data for it.
[13:55] <geser> no, it got removed from lucid: (From Debian) ROM; reimplemented upstream; Debian bug #553167
[13:57] <xteejx> geser: The website for the project is just a placeholder, doesn't look like it's developed anymore
[14:01] <kklimonda> probably
[14:01] <xteejx> Better off setting a bug in Jaunty as Won't Fix then I guess
[14:02] <kklimonda> which one?
[14:03] <xteejx> bug 237738
[15:40] <Laney> ScottK: Good catch on that empty binary package, fixing now
[15:40] <Laney> (and I had used -v correctly)
[15:41] <ScottK> OK
[15:41] <Laney> that uncovered a bug in haskell-devscripts, which is a win
[15:42] <ScottK> Nice.
[15:55] <micahg> when cherrry picking upstream VCS commits, is it better to do it as 1-1 patch or 1 patch for everything upstream?
[15:55] <hyperair> 1-1 patch.
[15:56] <hyperair> use quilt
[15:57] <micahg> hyperair: package already uses quilt :)
[15:58] <micahg> hyperair: for patch naming can I do XXX-reason-I'm-patching-1.patch XXX-reason-I'm-patching-2.patch ?
[16:01] <hyperair> micahg: right.
[16:01] <hyperair> micahg: wait a sec.
[16:02] <hyperair> micahg: this is a series of commits fixing one issue?
[16:02] <micahg> hyperair: well, I'm cherry picking the xulrunner 192 port fixes from upstream vlc
[16:02] <hyperair> =\
[16:02] <hyperair> 1-1 would be good then, i think
[16:03] <hyperair> especially in the case of git format-patch kind of patches
[16:03] <micahg> hyperair: with the naming convention I proposed or should I do XX1-reason.patch XX2-reason.patch?
[16:04] <hyperair> i think i'm not seeing the whole picture here.
[16:04] <hyperair> exactly what patches are these?
[16:04] <hyperair> like can i know their original names, for example?
[16:05] <hyperair> is upstream using git?
[16:05] <micahg> hyperair: well, there are a series of commits that fix different issues with porting to xul192
[16:05] <micahg> hyperair: yes
[16:05] <hyperair> if the patches are git-formatted i'd just use theo riginal names.
[16:05] <hyperair> just quilt import them all in
[16:05]  * micahg checks the original name
[16:06] <micahg> hyperair: they don't have names
[16:06] <ScottK> hyperair: IIRC, upstream mozilla uses Hg.
[16:06] <hyperair> ...
[16:07] <hyperair> okay, i give up
[16:07] <hyperair> this is turning my brain into spaghetti
[16:07] <hyperair> furst one says git, then another says hg
[16:07] <micahg> hyperair: one example: http://git.videolan.org/?p=vlc.git;a=commitdiff_plain;h=6dbe4986f7c11370c2bc275491d4502f5f4c3c60
[16:07] <hyperair> then they don't have names
[16:07] <micahg> ScottK: this is for vlc :)
[16:07] <hyperair> but format-patch names all the patches nicely
[16:07] <ScottK> Oh.
[16:07] <hyperair> so what. the. **** is going on?!
[16:07] <ScottK> Nevermind then.
[16:07]  * micahg never used format-patch before
[16:07] <hyperair> ...
[16:08] <hyperair> okay, that explains it
[16:08] <hyperair> go use format-patch and take those patches to shove straight into quilt
[16:11] <micahg> hyperair: silly question...where do I get/use format-patch?
[16:12] <hyperair> you install git-core, and you run "git format-patch blah blah"
[16:12] <micahg> hyperair: ah, it's a git thing :)
[16:12] <micahg> ScottK: do you know who's spearheading the get Sugar into Lucid effort?
[16:13] <ScottK> micahg: IIRC it was lfaraone and highvoltage.
[16:13] <micahg> ScottK: thanks
[16:15]  * lfaraone waves.
[17:31]  * abogani waves
[17:31] <abogani> I'm looking for sponsors: https://wiki.ubuntu.com/AlessioIgorBogani/linux-rtPPUApplication
[17:31] <abogani> Thanks!
[17:50] <geser> abogani: who sponsored your linux-rt work till now? those person are the best to judge on your application
[17:53] <abogani> geser: Since Gusty until Hardy(included) Ubuntu Kernel Team since Intrepid until Lucid (included) Luke Yelavich. I think that Luke don't sponsor me.
[17:55] <geser> abogani: have you asked him?
[17:56] <abogani> geser: Yes he said me that he don't trust on my packaging knowledge.
[17:56] <geser> without any sponsored contributions/uploads it will be hard to get PPU rights for a package and your current sponsor(s) are in the best situation to judge if you are ready or not
[18:01] <geser> abogani: and you don't trust his assessment of your packaging skills and try nonetheless to apply? I don't want to anticipate the results of your application but if your sponsor doesn't trust you why should the DMB grant your PPU rights?
[18:04] <abogani> geser: No one have ever worked on this package. Neither Ubuntu Kernel Team nor Luke have worked on/changed my (upload) works. So linux-rt package is result of *only* my work. If you think that I don't deserve PPU rights you should know that 1) I push realtime kernel in Ubuntu 2) unilt Feisty I triage bugs I backported upstream fixed 3) I working on packaging when sine Intrepid linux-rt became a standalone universe package.
[18:05] <abogani> geser: In any case I'll accept your choice.
[19:00] <ari-tczew> is there any person works or got expirence in backports?
[19:02] <persia> Several folks: ask a question, and someone will answer :)
[19:10] <ari-tczew> I want to backport trac package to karmic, jaunty, intrepid :)
[19:10] <ari-tczew> for security fix reason
[19:10] <persia> backports aren't for bugfixes.
[19:11] <persia> If there are security issues, you might want to drop by #ubuntu-hardened and talk about the best way to get them resolved.
[19:13] <Laney> DktrKranz: I think I recall you doing an empty binary scan over the Debian archive recently. Do you still have the scripts you used to do it?
[19:13] <Laney> (noticed a bug in hlibrary.mk which causes empty binaries to be produced)
[19:19] <DktrKranz> Laney: there's a lintian check for that already working
[19:19] <Laney> DktrKranz: Oh, that's cool. I'll do that
[19:20] <DktrKranz> Laney: http://lintian.debian.org/tags/empty-binary-package.html
[19:20] <Laney> but lintian.d.o doesn't pick up the case I'm looking at
[19:20] <Laney> interesting
[19:20] <DktrKranz> some times ago, we ran lintian checks on Ubuntu packages as well, I don't know if it's still running
[19:20] <persia> It's not.
[19:20] <Laney> I want to fix this in Debian anyway
[19:21] <DktrKranz> Laney: which one?
[19:21] <persia> I've been meaning to get it running again, but haven't yet found the setting-up-whole-archive-lintian-runs-for-the-unfamiliar guide yet :)
[19:21] <Laney> DktrKranz: e.g. libghc6-hsql-mysql-dev
[19:21] <Laney> when I build it lintian picks it up
[19:21] <Laney> but doesn't appear on that interface
[19:21] <Laney> (maybe it's only run on the souce packages)
[19:21] <Laney> no, can't be
[19:22] <DktrKranz> definitely not
[19:22] <DktrKranz> it searches the binaries
[19:23] <DktrKranz> Laney: which lintian version do you use, 2.3.4?
[19:23] <Laney> I'm running it in a sid chroot, so 2.3.4 indeed
[19:23] <DktrKranz> gah
[19:23] <Laney> let me emphasis, I *do* see the warning locally
[19:23] <Laney> but the website doesn't
[19:24] <DktrKranz> ah
[19:24]  * DktrKranz logs in to lintian.d.o to see which version it runs
[19:26] <DktrKranz> haskell-hsql-mysql (1.7.1-4)
[19:26] <DktrKranz> that's the same
[19:29] <DktrKranz> Laney: btw, I processed several haskell NEW uploads, and luckily they were OK.
[19:31] <DktrKranz> persia: if you need some config, I can try to see if setup for lintian.d.o is available, and eventually pass it
[19:32] <persia> DktrKranz: I believe it to be on alioth somewhere, although I haven't found it.  If you do find it, it will speed me running lintian over Ubuntu :)
[19:34] <Laney> DktrKranz: "the same"?
[19:34] <Laney> as in empty?
[19:35] <DktrKranz> Laney: I checked if the empty packages in the archive is the same lintian laboratory is know of, and version matches
[19:36] <Laney> the Lintian version is too old then?
[19:36] <Laney> you should also spank whichever ftp team member NEWed that package ;)
[19:36]  * DktrKranz checks if it was him... :)
[19:37] <DktrKranz> N: Processing source package haskell-hsql-mysql (version 1.7.1-4) ...
[19:37] <DktrKranz> N: Removing haskell-hsql-mysql
[19:37] <DktrKranz> W: haskell-hsql-mysql source: changelog-should-mention-nmu
[19:37] <DktrKranz> W: haskell-hsql-mysql source: source-nmu-has-incorrect-version-number 1.7.1-4
[19:37] <DktrKranz> mmmh, lintian has the correct version, so why check is failing?
[19:38] <Laney> root@chicken:/# lintian libghc6-hsql-mysql-doc_1.7.1-4_all.deb
[19:38] <Laney> warning: lintian's authors do not recommend running it with root privileges!
[19:38] <Laney> W: libghc6-hsql-mysql-doc: empty-binary-package
[19:38] <Laney> works here
[19:38] <Laney> what changesfile is it running over?
[19:40] <DktrKranz> it shouldn't process changesfile directly, but packages unpacked
[19:40] <DktrKranz> (at least I see that on lintian.d.o)
[19:41] <DktrKranz> a manual run on that package reveal W: libghc6-hsql-mysql-dev: empty-binary-package for me too
[19:46] <nhandler> xkill
[19:46] <alkisg> In debian/install, "src/*   usr/share/my-package/" was recursive. How can I do the same in setup.py?
[19:50] <alkisg> Should I be using MANIFEST.in for that?
[19:53] <persia> If nobody gives you a good answer after a while, try #ubuntu-app-devel which tends to focus more on upstream best-practices, etc.
[19:53] <alkisg> Thank you, will do
[20:37] <highvoltage> 17:12 < micahg> ScottK: do you know who's spearheading the get Sugar into Lucid effort?
[20:38] <highvoltage> 17:13 < ScottK> micahg: IIRC it was lfaraone and highvoltage.
[20:38] <highvoltage> michas: ^^^ that would be maverick, not lucid :)
[20:38] <micahg> highvoltage: is that final then for Lucid, no sugar?
[20:41] <highvoltage> micahg: lucid is in final freeze real soon, I think pretty much everyone (including me) is doing some scrambling atm to get their things working as good as possible in lucid
[20:41] <bdrung> wasn't the plan to have sugar 0.88 in lucid?
[20:41] <highvoltage> micahg: so I guess it's pretty much final
[20:42] <micahg> lfaraone: ^^^
[20:42] <highvoltage> bdrung: parts of sugar works with older and newer versions of it, parts of it is 0.88 and parts of it is 0.86
[20:43] <bdrung> there is still enough time to push the missing bits into universe
[20:44] <highvoltage> bdrung: that is, if someone picks it up and runs with it :)
[21:05] <lfaraone> micahg, highvoltage, I really am rather unfamiliar with pyxpcom, and Sugar's useless without it unless I decide to package a bunch of new packages.
[21:10] <micahg> lfaraone: well, my question was is sugar going into lucid...it seems like we're in a circular logic loop
[21:11] <ScottK> If it won't be on an ISO we have a couple of weeks to get it sorted.
[21:14] <RainCT> micahg: I have exams this week, but feel free to poke me after that if you need any help with Sugar related stuff.
[21:15] <micahg> RainCT: thanks, we're trying to figure out about getting it into lucid and what the requirements are for xpcom integration
[21:19] <RainCT> micahg: By the way, have you talked to David Farning? He was working on a Ubuntu Sugar Remix, but I haven't heard of him for weeks.
[21:21] <micahg> RainCT: no, not yet
[22:30] <psusi> how do you have a blank line in the package description in debian/control?  debuild keeps complaining about This is probably a duplicate of bug #534743.  Can you try booting with the nosplash break nodmraid options, then when you hit the busybox prompt, run dmraid -ay then exit.  If the system boots up normally at that point then it's that bug and I will mark this as a duplicate.
[22:31]  * psusi kicks terminal for not copying that automatically like xterm
[22:31] <psusi> make that complaining about: dpkg-source: error: syntax error in e2defrag/debian/control at line 15: continued value line not in field
[22:37] <jdong> lol
[22:38] <psusi> hey jdong... I'm trying to get https://launchpad.net/e2defrag/ into shape ;)
[22:38] <jdong> was gonna ask about that yesterday :)
[22:38] <jdong> but then realized how much actual work (tm) I had :-/
[22:38] <psusi> trying to figure out if I can get a build under the project instead of my ppa
[22:39] <psusi> hehe
[22:39] <psusi> well, it seems to work well for me now without uninit_bg and extents
[22:39] <psusi> tackling extents is going to be a challenge
[22:39] <psusi> uninit_bg should be easier
[22:39] <jdong> extents being pretty important
[22:39] <psusi> then after that I have to try and get it to relocate inodes
[22:39] <psusi> yea
[22:40] <psusi> uninit_bg seems like it is going to be pretty important too, especially with lazy_itable_init, which is currently defaulting to off... when I turned that on installing to a 1.5 tb drive went from taking like 15 minutes sitting at 5% complete formatting to like 15 seconds
[22:44]  * psusi wonders where the hell that dput went
[22:44] <maco> generally its a good idea to know where you're sending them...
[22:46] <psusi> lp seems to have a way to link to an ubuntu package, but I can't figure out how to upload a new package from the current bzr branch
[22:46] <Laney> in the normal way
[22:47] <Laney> bzr bd -S ... dput
[22:47] <psusi> maco: I sent it to ppa:e2defrag/0.75, but I don't know where it WENT ;)
[22:47] <psusi> bzr bd unknown command
[22:48] <Laney> you need to install bzr-builddeb
[22:48] <psusi> ohh, I just ran debuild -S
[23:09] <persia> That ought work just fine as well.
[23:12] <wgrant> psusi: Um, ppa:e2defrag/0.75 isn't a PPA.
[23:12] <wgrant> The '0.75' PPA for ~e2defrag does not exist.
[23:15] <wgrant> psusi: Also, I'm confused. Has e2defrag moved to Launchpad for development? Where was it before?
[23:15] <wgrant> Are you the upstream maintainer?
[23:26] <psusi> wgrant, I am now, I took it over and rescued it after it was removed from the archive 2 years ago for not having an upstream
[23:26] <wgrant> Ah.
[23:26] <wgrant> So, projects don't have PPAs -- people and teams do.
[23:26] <psusi> that's what I thought
[23:26] <psusi> is there a project archive instead of a personal one?
[23:27] <wgrant> No.
[23:27] <wgrant> For reasons that I cannot fathom, there is not even a way to link a project to PPAs.
[23:27] <psusi> I was wondering about that
[23:27] <psusi> I mean the project links to the branches, why not archive?
[23:28] <psusi> there's a button to link it to a package in the ubuntu archive, but it isn't there
[23:28] <wgrant> Well, an archive can contain multiple projects.
[23:28] <wgrant> Right.
[23:28] <wgrant> But that is stupid and doesn't handle PPAs.
[23:28] <wgrant> Even though it was redesigned a couple of months ago.
[23:29] <psusi> so why can you link it to the ubuntu project's archive, but no other project's archive?  I thought lp was supposed to be more general than ubuntu?
[23:29] <psusi> so as a separate project, you would think it would have its own archive
[23:30] <wgrant> Ubuntu is a distribution, not a PPA.
[23:30] <maco> ubuntu is setup as a distro not a plain old project in lp
[23:30] <maco> yes, it has a distinction
[23:30] <psusi> ahh
[23:31] <wgrant> It is more general, but a distribution is a special class of object.
[23:31] <lfaraone> maco: well, we *could* link a project to other distributions which *are* hosted in LP
[23:31] <jpds> IHasDistribution.
[23:31] <maco> lfaraone: huh what what
[23:31] <maco> did i say you couldnt?
[23:31] <lfaraone> maco: you can't, currently.
[23:31] <maco> i just said that ubuntu gets build-capabilities because its a distro
[23:31] <lfaraone> (afaict)
[23:31] <psusi> well, I guess for now then I'll have to use ~e2defrag-maintainters ppa and eventually get it uploaded to universe
[23:32] <wgrant> The non-Ubuntu linking functionality was somewhat unlinked a couple of weeks ago.
[23:32] <wgrant> It was not being used.
[23:37] <psusi> oh by the way, how are you supposed to have blank lines in the description in debian/control?  dpkg-source errors thinking the text following is a new field
[23:38] <persia> There is a special syntax to have blank lines: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description
[23:38] <ajmitch> by using a .
[23:39] <ajmitch> a single space followed by a single full stop character, is what policy says is the only way
[23:39] <ajmitch> but persia is quicker than me at getting the link :)
[23:39] <psusi> wow, that's what my guess was ;)
[23:41] <psusi> hrm... bzr bd -S fails since it seems to blindly look for an orig tarball when it shouldn't... seems like a bug
[23:43] <persia> I suspect there's special syntax you need to get bzr-builddeb to know it's native.
[23:43] <wgrant> Why is there no orig tarball?
[23:43] <psusi> because it's a native package
[23:44] <wgrant> It doesn't seem like it should be.
[23:44] <psusi> why not?  I AM upstream
[23:44] <persia> psusi: Because you're a well-meaning upstream who wants to support every potential distribution that will ever be invented :)
[23:44] <wgrant> What if we need to patch it?
[23:44] <psusi> persia, I am? :)
[23:45] <psusi> wgrant, then we patch it
[23:45] <persia> psusi: Of course you are :)
[23:45] <wgrant> psusi: We can't, sanely, because it's native and we don't have commit access upstream.
[23:45] <psusi> wgrant, but there is no upstream
[23:46] <wgrant> There will be if the project gets anywhere.
[23:46] <persia> psusi: But there could be.  Project hosting sites abound.
[23:47] <psusi> I mean I guess you could create a -ubuntu1 package for changes specific to ubuntu, but right now there are none...
[23:47] <psusi> persia, I'm using lp for hosting
[23:47] <persia> Then there is an upstream.  The primary upstream contributor happens to be a distro-maintainer, but that's a coincidence.
[23:47] <psusi> actually I"m not
[23:49] <psusi> I suppose that it could be some day that ubuntu specific changes will be made, but right now it's an initial upstream release, packaged with zero modification
[23:58] <ajmitch> unless it's something made only for a specific distro (e.g. ubuntu-dev-tools), then it's best to not have it as a native package
[23:59] <persia> And truth be told, most of the stuff in ubuntu-dev-tools really ought be pushed into other places
[23:59] <Laney> That is true. I would have done so, were it alright to have python scripts in devscripts.