[00:02] <nicklas_> i am sorry, that wasnt meant as an offense, just a joke, didnt know people would get so angry, wont do it again
[00:03] <lifeless> thank you
[00:08] <NoReflex> Hello guys! I'm looking for some information on how I could compile a source to be installed just as a version from ubuntu's repo. If I compile it using the default options it will use other folders for binaries, libraries and won't make menu shortcuts
[00:13] <zooko> Hm, is there anything I can do to accelerate the process of getting tahoe-lafs popped from this queue -- https://launchpad.net/ubuntu/karmic/+queue -- and put into the Karmic apt-repo so that I can ask Tahoe-LAFS users to test out the Karmic package?
[00:16] <james_w> zooko: unfortunately for you the friendly archive-admin that would be on rotation right now is on vacation, so it might be a while before someone gets to it
[00:17] <james_w> zooko: so accelerated processing requires asking someone nicely
[00:18] <zooko> james_w: would *you* be so kind as to archive-admin that package?  I've been careful to document all the licensing.
[00:18] <james_w> hey, you know my rule! ;-)
[00:18] <zooko> I figured that we're going ...  Ah, yes I do.  :-)
[00:18] <zooko> I'll ask you politely tomorrow morning after your coffee.
[00:19] <james_w> but after I go and be horizontally in a dark room for 8 hours I'll try and remember to look
[00:19] <zooko> I figure that we Tahoe-LAFS devs are going to be supporting the version that is in Karmic for many years, so I would like to give it a good workout before Karmic goes gold.
[00:19] <james_w> you would focus on the karmic version over the LTS one?
[00:19] <zooko> Tahoe-LAFS has thorough unit tests (TDDFTW!), but obviously "real world with users using it in strange ways" tests cannot be skipped.
[00:19] <james_w> (nice attitude though :-)
[00:20] <zooko> That totally depends on user demand.
[00:20] <zooko> My perspective so far is that Hardy is super popular among servers, but that we still support edgy, feisty, and gutsy.
[00:20] <james_w> given that support is 18 months for karmic, and 5 years for lucid on the server you can happily tell karmic users to upgrade before too long
[00:20] <zooko> We dropped dapper finally.
[00:21] <zooko> Hm, I hadn't really thought of it that way.
[00:21] <james_w> well, *we* don't support edgy feisty and gutsy
[00:21] <james_w> so it's probably better you don't
[00:21] <zooko> The whole point, or most of the point, of Tahoe-LAFS is long-term storage and reliability and safety and so on.
[00:21] <james_w> tell them to get on to hardy where they get security updates for the base packages
[00:21] <zooko> So we have a general attitude that we have to maintain backwards compatibility as well as we can.
[00:21] <james_w> cool
[00:21] <zooko> Although now that you mention it, this attitude might not apply to the underlying OS.
[00:22] <james_w> yeah, we limit the number of versions we will support people running for a long time
[00:22] <zooko> As far as I know all of our actual current users are on Hardy or newer or a similarly new other OS.
[00:22] <zooko> You make an excellent point about security updates of base packages.
[00:22] <james_w> I guess most people don't run too much on their machines beside tahoe?
[00:23] <james_w> but still, the kernel doesn't get support for longer than anything else
[00:23] <zooko> There are two classes of Tahoe-LAFS user: the corp which runs hundreds of servers doing nothing but Tahoe-LAFS, and the "friendnet"
[00:23] <zooko> a group of hackers who run Tahoe-LAFS on their personal machines or personal servers.
[00:23] <zooko> There is only one element in the first set, so far.
[00:23] <zooko> There are several "friendnets".
[00:24] <zooko> Anyway, Karmic will be supported for 18 months, right?
[00:24] <james_w> yep
[00:24] <james_w> (I hope, or I look silly now)
[00:24] <zooko> That's a long time that all the software we write will have to be fully bidirectional compatible with whatever is in Karmic.
[00:24] <james_w> true
[00:24] <zooko> So please remember to archive Tahoe-LAFS tomorrow so I can get more days of testing in before Karmic goes gold.  :-)
[00:25] <james_w> I will!
[00:25] <zooko> Thanks!
[00:25] <james_w> no thank you
[00:25] <zooko> See you later.
[00:26] <NoReflex> For example I'm trying to compile postgresql 8.4.1 on Jaunty. If I do ./configure --help | more I get a section that' called "Fine tuning of the installation directories:". Is there  a general rule on which these directories should be in Ubuntu?
[00:26] <azeem> depends on what they are
[00:26] <NoReflex> init scripts in /etc/init.d/, config files in /etc/software_name/ and so on...
[00:26] <azeem> NoReflex: see the File Hiearachy Standard
[00:30] <NoReflex> azeem, does Ubuntu respect the standard guidelines from http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard?
[00:36] <NoReflex> I need to install postgresql-8.4.1 on Ubuntu Jaunty server and pgadmin3-1.10.0 in Ubuntu Desktop. Neither has been updated in Jaunty repository so I believe I must compile them manually and build a deb file with checkinstall. The thing is I want them to be configured as close as possible as the older versions from the repository.
[00:38] <azeem> then just update the older version manually
[00:38] <azeem> or simply try to rebuild the Debian package (for postgresql)
[00:40] <NoReflex> azeem how do I update the older version manually? using uupdate?
[00:40] <azeem> karmic appears to ship pgadmin3-1.10 so you could just try to rebuild that package on your target Ubuntu system as well
[00:40] <micahg> NoReflex: you could try to backport the karmic version
[00:40] <azeem> NoReflex: that'd be a starting point
[00:42] <NoReflex> azeem how do I rebuild pgadmin3-1.10 from karmic? do I have to get the source and the compile on m jaunty machine?
[00:47] <micahg> NoReflex: you can build the sources in a Launchpad PPA
[00:54] <NoReflex> micahg, on Launchpad i see this "We will not accept uploads of packages that are unmodified from their original source in Ubuntu or Debian, only packages that include your own change"
[00:54] <NoReflex> I believe I'm not eligible for a PPA and must compile the software on my own computer
[00:56] <micahg> NoReflex: everyone can have a personal PPA
[00:56] <micahg> they're free
[00:56] <micahg> if you have a user account on LP, you can create a ppa
[00:57] <micahg> you can even have multiple ones now
[00:57] <micahg> NoReflex: you update the changelog
[01:13] <NoReflex> micahg, I don't think I'm skilled enough to set up my PPA. I tried uupdate but that didn't retain the debian specific configuration options of the older version
[01:14] <micahg> NoReflex: add the karmic deb src line, apt-get -t karmic source PKGNAME
[01:15] <NoReflex> If I'll succeed compiling on my own computer I probably set up a PPA with postgresql-server and related tools
[01:15] <wgrant> NoReflex: Why would you want a special version of postgresql?
[01:16] <NoReflex> wgran, I want the latest version of postgresql not a special one. jaunty only has 8.3.7
[01:16] <wgrant> NoReflex: There are already PPAs with 8.4
[01:17] <NoReflex> wgrant I knwo that 8.4 is in karmic's repo and sid's repo but I've been told not to mix repositories between releases
[01:18] <micahg> NoReflex: it's already been done: https://edge.launchpad.net/~pitti/+archive/postgresql
[01:25] <NoReflex> micahg, it seems to work but now I need pgadmin3 1.10.0 which is compatible with postgres 8.4 and for that I didn't find a PPA on Launchpad. This is why I believe it's better if I learn how to compile the sources myself first.
[01:30] <micahg> NoReflex: so you can backport it to a ppa
[01:34] <NoReflex> micahg, I downloaded the source for pgadmin3 1.10.0 from karmic's source repository
[01:35] <micahg> NoReflex: are you familiar at all with packaging?
[01:35] <NoReflex> I used before ./configure, make, make install (or checkinstall) make uninstall
[01:36] <micahg> ok
[01:36] <micahg> well, if you use a ppa, you don't need to do that, but you do need to add a changelog revision set for the version of ubuntu you want it to compile for
[01:39] <micahg> NoReflex: you need to pay attention to the version number as well
[01:40] <micahg> so that if you upgrade to karmic, you get the karmic packages
[01:40] <micahg> and any updates
[01:41] <NoReflex> So basically the PPA compiles the sources I upload (./configure, make and checkinstall?)
[01:41] <micahg> yep
[01:41] <micahg> with the proper dependencies for that version (assuming they exist)
[01:42] <micahg> if they don't you have to backport the dependencies
[01:42] <micahg> you can also, add other ppas as dependencies for your ppa
[01:45] <tisepti> I have created a new version of libmagick; how can i cause all of the dependencies of the packages produced to be the packages I am producing; there was a security patch which did this http://packages.ubuntu.com/jaunty/libmagick++-dev
[01:46] <tisepti> in that patch all the dependencies are (= 7:6.4.5.4.dfsg1-1ubuntu3.1)
[01:46] <tisepti> for my stuff my dependencies are simply stuff like 7:6.4.5.4.dfsg1-ubuntu3
[01:47] <tisepti> which means that old stuff satisfies
[01:48] <tisepti> that seems to be controled in the debian/control file with some things such as ${shlibs:Depends},
[01:53] <NoReflex> On a more general level
[01:53] <NoReflex> ...is the whole PPA idea a good thing?
[01:54] <NoReflex> What if someone modifies the source and puts in some malware code (like a keylooger) and uploads it to his PPA? How can the users know that PPA is trustworthy?
[01:55] <NoReflex> Does someone verify the sources or the generated binaries?
[01:58] <wgrant> NoReflex: You need to trust the owner of the PPA, or verify the sources yourself.
[01:58] <wgrant> You always know that the binaries are generated from the sources that you see, as Launchpad builds them itself.
[02:00] <mase_wk> hi guys, i'm looking for a straight forward way to package a new kernel.org kernel with ubuntu. Is checkinstall ok for packages which will be used internally  only ?
[02:29] <zul> mase_wk: check out kernel-package and the make-kpkg checkinstall is not a good idea at all
[02:29] <mase_wk> zul: i tried using make-kpkg however that did not work with 2.6.31 on hardy
[02:30] <mase_wk> at least not with the kernel from kernel.org
[02:35] <mase_wk> zul: what are the disadvantages of checkinstall ?
[02:36] <mase_wk> assuming i am only using the packages on my systems
[02:36] <zul> mase_wk: it could break your system
[02:36] <mase_wk> ok, in what particular way ?
[02:45] <ScottK> POX: Progressing, but both my AM and I are pretty busy.
[04:04] <mruiz> hi all
[04:49] <porthose> Would someone from the release team please check bug #435626 to see if it needs an FFe.
[04:49] <Darxus> mase_wk: checkinstall is no worse than make install.  It just runs make install and keeps track of the files that get created so they can be easily removed.
[04:51] <nixternal> porthose: is that even in the repos?
[04:51] <porthose> yes :)
[04:51] <nixternal> hrmm, i can't dl it
[04:52] <nixternal> interesting
[04:52] <nixternal> don't rely on 'apt-cache' I guess when looking for packages :/
[04:53] <porthose> pull-lp-source didn't work either
[04:53] <ScottK> nixternal: rmadison is better
[04:53] <nixternal> derr, if I could only speeeel
[04:54] <nixternal> pythn-pylirc isn't going to cut it
[04:54] <Darxus> Heh.  Damn picky computers.
[04:55] <Darxus> The "o" key on my phone is terrible, so that looks familiar :/
[04:55] <zooko> Darxus: the way you describe checkinstall makes me think that the GNU stow approach is more robust.
[04:55] <Darxus> zooko: stow?
[04:56] <nixternal> Darxus: ya, I have an issue with 'i' on my phone
[04:57] <zooko> GNU stow!  A beautiful piece of work.  One nice simple hack which is very useful.
[04:57]  * zooko finishes singing the "Praise We Now GNU Stow" song
[04:58] <nixternal> hehe, haven't used stow in probably 10 years
[04:58] <Darxus> zooko: Okay, more robust how?
[05:00] <zooko> Darxus: GNU stow never lets the installer script, i.e. the software's Makefile or whatever, write into your system.
[05:00] <zooko> Instead it gets to write into a special-purpose empty directory created just for it, by telling it ./configure --prefix=$YOUR_INSTDIR
[05:00] <zooko> for example.
[05:01] <Darxus> Ahh.
[05:01] <zooko> So that's the first way that it is more robust is that the installer script can't overwrite things.  It doesn't run under sudo.
[05:01] <Darxus> Well, there's nothing keeping you from running ./configure --prefix before checkinstall, right?
[05:01] <zooko> The next way is that you can safely and completely uninstall everything that it ever had permission to write, with the following command: "/bin/rm -rf $YOUR_INSTDIR".
[05:02] <Darxus> Heh.
[05:02] <zooko> And then there's the final piece, which is how GNU stow cleverly uses symlinks to make the previous two pieces convenient and useful.
[05:02] <zooko> There's something I love about using an old, pre-existing, lower-layer tool like the filesystem and rm and symlinks to achieve a higher-layer goal like uninstallable software installation.
[05:03] <Darxus> It sounds nice if you don't trust the make install, but if you don't trust the make install you shouldn't be installing the software at all.
[05:03] <zooko> Obviously it doesn't do everything you might want, but when you need something like GNU stow, GNU stow makes a very good tool.
[05:03] <zooko> Darxus: are you familiar with the notion of "Principle of Least Authority"?
[05:04] <Darxus> If I didn't know about checkinstall I'd almost certainly use it the next time I had to install something from source.
[05:04] <Darxus> zooko: I can infer well enough.
[05:04]  * zooko nods.
[05:04] <zooko> It applies to this case.
[05:04] <zooko> The most common problems with installing software from source isn't malice on the part of the packager, but accident.
[05:04] <zooko> Running "make install" without root privs helps a great deal against that problem.
[05:05] <zooko> But even if you think of the malicious case, you can imagine installing and using some software from source without ever giving it sudo power, using GNU stow to install it.
[05:06] <Darxus> True.  As long as the installed software isn't then run by root ever.
[05:06] <Darxus> Hopefully checkinstall does something to prevent existing files from getting clobbered.  I don't know.  Never used it.
[05:21] <ScottK> zooko: Where do I find the full copy of the BSD license in the upstream tarball?
[05:22]  * wgrant yells out one final call for Launchpad Bugs/Soyuz priorities, before declaring that none can be submitted.
[05:23] <ScottK> wgrant: How about the smarter retry stuff that we discussed?
[05:24] <ScottK> I'd also go for put the old PPA page back.
[05:24] <wgrant> What's wrong with the new PPA page?
[05:24] <wgrant> Besides the hiding of useful information behind an extra layer of links.
[05:24] <ScottK> That's it.
[05:25] <ScottK> And doing it in a way that's totally unobvious how to get it back
[05:25] <wgrant> I believe the front page will eventually display more user-specific information (eg. about the applications, rather than source packages), but it's not there yet.
[05:26] <ScottK> I only eventually figured it out from reading bug reports
[05:26] <zooko> ScottK: oops
[05:26] <zooko> There is no full copy in the upstream tarball.
[05:26] <ScottK> zooko: I'm going to reject this one.  Please fix that and ask your sponsor to upload again.
[05:26] <zooko> The BSD licence applies only to this one file, which isn't even needed, so perhaps it would be easier to remove that file.
[05:26] <wgrant> ScottK: That's a separate issue. Have you seen the new (admittedly far too small) link at the top right of the package list?
[05:26] <wgrant> That was added recently.
[05:26] <zooko> Will do, but please advise me on how to fix it.
[05:27] <wgrant> ScottK: You use +queue to do that, I presume?
[05:27] <ScottK> zooko: It needs to be added to the upstream tarball.  You can repack the tarball to do it.
[05:28] <ScottK> wgrant: I saw the link after reading a bug report about it.
[05:28] <wgrant> ScottK: Even after the second link was added later on?
[05:28] <ScottK> wgrant: Whatever is there now.  Yes.
[05:28] <zooko> Okay, so just add a file, perhaps named COPYING.BSD, with license text therein, and mention that file from the part of the "copyright" file that refers to the BSD licence, and reupload?
[05:28] <wgrant> ScottK: Urgh.
[05:28] <zooko> I'll have to be careful not to undo RainCT's fixes to my Ubuntu changelog when I do that.
[05:29] <ScottK> zooko: Yes.  But it needs to be in the tarball, not patched in in the diff.gz.
[05:29] <zooko> Hm.
[05:29] <zooko> So, uh,
[05:29] <zooko> Sorry, it is late.
[05:29] <lifeless> there are two different issues under discussion
[05:30] <lifeless> one is 'can we ship this code'
[05:30] <ScottK> wgrant: On the archive management page whenever you accept or reject a package it always says OK:packagename.  It always throws me if I rejected and the response I get is OK.
[05:30] <lifeless> the other is 'how we present metadata about the code to our downstreams and our users'
[05:30] <wgrant> ScottK: Right, that UI sucks. That's known.
[05:30] <ScottK> zooko: What lifeless says is exactly correct.
[05:30] <ScottK> OK.
[05:31] <zooko> So, is it that there is something about the current packaging that makes you not confident that you can ship it?
[05:31] <ScottK> zooko: Yes.  The absence of a full copy of one of the licenses it relies on in the upstream tarball.
[05:32] <ScottK> I'm confident that without that, I can't ship it.
[05:32] <zooko> Okay, so you need a new upstream tarball to be created.  Now here's where I get confused: what version number, if any, should be in the filename of the new upstream tarball?  Does it matter?
[05:32] <zooko> The current one is named tahoe-lafs-1.5.0.tar.gz
[05:32] <ScottK> wgrant: Is the ability to explicitly unsubscribed from bugs one is implicitly subscribed to (e.g. via a team) on the list?
[05:33] <lifeless> zooko: you could append .1; bump the 0 to 1, or call it 'muppets forever', we'll be happy.
[05:33] <wgrant> ScottK: Ah, no. That's a good one.
[05:33] <zooko> lifeless: Ok.
[05:33] <wgrant> ScottK: That's on other lists already, but I'll add it to the MOTU one if nothing else comes up.
[05:34] <zooko> Next question: RainCT uploaded something  to the Karmic Queue while fixing some bits over the "0ubuntu3" that I had uploaded to REVU.  Where can I get a copy of RainCT's version?
[05:34] <ScottK> wgrant: The standard "too slow" complaint shouldn't be forgotten.
[05:34] <ScottK> zooko: I've got it here locally.  I'll upload it to revu.
[05:35] <wgrant> ScottK: That's not app-specific, unfortunately.
[05:35] <ScottK> wgrant: soyuz u/i too slow
[05:35] <zooko> ScottK thanks!
[05:36] <ScottK> wgrant: Make the bug status AJAX stuff go away.  Far too many status changes with no comment now.
[05:38] <ScottK> zooko: Uploaded to REVU.  It should be there in a few minutes.
[05:41] <zooko> ScottK: thanks
[05:43] <ScottK> wgrant: Where do I click to edit a bug?
[05:44] <wgrant> ScottK: 'edit a bug'?
[05:44] <wgrant> What aspect of it?
[05:44] <ScottK> The description
[05:44] <wgrant> The drunken exclamation mark in the tab at the top right of the description.
[05:44] <ScottK> Where?  I don't see it.
[05:45] <ScottK> The only one of those I see is connected to bug affects me.
[05:45] <wgrant> Which browser?
[05:45] <ScottK> Konqueror, of course
[05:45] <ScottK> I'll try FF.
[05:46] <ScottK> I see it.
[05:47] <zooko> ScottK: you won't mind if I give you a tarball which just doesn't have the  BSD-licensed file in question, will you?
[05:47] <ScottK> The little line that draws around it is present in Konqueror, but no icon to edit.
[05:47] <ScottK> zooko: That's work too, but if you're rolling a new tarball, it seems it'd be easy enough to add.
[05:47] <zooko> I mean if I upload a package containing such a tarball to REVU.
[05:48] <zooko> Yes, I just started adding it but then I realized that I would be happier as upstream maintainer if I just did't have this file nor its licence...
[05:48] <wgrant> There are a couple of missing icons in WebKit-based browsers. Looks like KHTML is the same.
[05:48] <wgrant> Though that particular icon *is* there in WebKit.
[05:48] <ScottK> WTF.  And that's release ready?
[05:49] <wgrant> KHTML isn't widely tested.
[05:49] <wgrant> WebKit is, and those bugs were fixed.
[05:49] <Amaranth> People still use KHTML?
[05:49] <wgrant> I thought most had moved on.
[05:49] <wgrant> But Konqueror continues to use it, unfortunately :(
[05:50] <ScottK> It's used in the default browser in Kubuntu.
[05:50] <ScottK> We considered switching to Arora (webkit), but it wasn't enough better to be worth it.
[05:50] <wgrant> Not being abandoned wasn't sufficient?
[05:51] <ScottK> It's not abandoned.
[05:51] <ScottK> It's not particularly robustly maintained, but enough web sites had problems with arora that it didn't get users past the need to install firefox.
[05:52] <Amaranth> konq doesn't either
[05:52] <Amaranth> Does gmail work with konq yet?
[05:52] <ScottK> I don't recall.  It does at least in non-ajax mode
[05:53] <Amaranth> Right, last I heard konq didn't support ajax
[05:54] <ScottK> I see opera has problems in this particular area too.
[05:54] <ScottK> It does, some.
[05:55] <mruiz> asac, ping
[05:55] <zooko> I've been using konqueror in Jaunty.
[05:55] <zooko> Haven't tried with gmail.
[05:55]  * ScottK too
[05:56] <ScottK> wgrant: That's now 435648
[05:57] <ScottK> wgrant: I guess "switch back to the LP beta tables based U/I to improve usability" hasn't much of a chance.
[05:57] <wgrant> ScottK: Thanks.
[05:57] <wgrant> ScottK: You mean LP 0.0?
[05:57] <ScottK> Yep
[05:57] <ScottK> That was the best one so far from a user perspective IMO.
[05:58] <ScottK> I know the tables stuff was unmaintainable though
[05:58] <wgrant> 3.0 is much better than 2.0, and possibly 1.0.
[05:58] <ScottK> I liked the look at a glance.
[05:58] <ScottK> So far I have a lot of trouble finding stuff.
[05:59] <zooko> ScottK: our copyright file currently says: The files mac/fuse.py and mac/fuseparts/subbedopts.py are licensed under the GNU Lesser General Public Licence.  In addition, on 2009-09-21 Csaba Henk granted permission for those files to be under the same terms as Tahoe-LAFS itself.
[05:59] <ScottK> zooko: I saw that.
[05:59] <zooko> So, we don't need to include a copy of LGPL2, since those files are under the other licences, right?
[06:00] <ScottK> A copy of the LGPL would be good too.
[06:00] <zooko> Okay.
[06:00] <zooko> Does the file containing LGPL need to be referred to from copyright or from anywhere?
[06:00] <zooko> Or can I just drop it into the source tree.
[06:01] <ScottK> Just drop it in.
[06:01] <zooko> Ok.
[06:01] <ScottK> wgrant: On top of it, I can't even actually edit the bug in FF.
[06:02] <ScottK> Something in tiny, tiny print about not being well formed json.
[06:03] <wgrant> ScottK: That affects some people some times with some types of input. It is under investigation.
[06:04] <ScottK> wgrant: I didn't add anything, I just deleted text.
[06:04] <wgrant> ScottK: Right. It's a very strange bug.
[06:06] <ScottK> It's total crap.
[06:06] <wgrant> That too.
[06:09] <ScottK> wgrant: How about adding "Have it working before release" to the list.  Apparently that needs to be asked for special
[06:10] <ScottK> Since I see opera bugs too, I guess they must just test with IE.
[06:10] <wgrant> ScottK: It does mostly work! Sure, there are a few AJAX bugs, and some big big design issues with the new UI...
[06:11] <ScottK> It works less than the previous release did.
[06:12] <ScottK> That's generally considered not good.
[06:12] <wgrant> Perhaps.
[06:12] <wgrant> But it is a major new revision, and everyone knows they will never be perfect.
[06:12] <wgrant> Particularly when it was as large a job as LP 3.0.
[06:13] <ScottK> Editing a bug description is not an obscure function.
[06:13] <wgrant> It's not.
[06:13] <wgrant> Perhaps the AJAX should have been disabled.
[06:13] <ScottK> Basic stuff like that should work.
[06:13] <wgrant> Certainly. And in all but a few cases it does.
[06:14] <ScottK> I'm zero for one so far.
[06:14] <ScottK> And I tried it multiple times.
[06:14] <wgrant> Yet I've not experienced the failure.
[06:15] <ScottK> I can only form my impression of the release based on my experience.
[06:16] <wgrant> Of course.
[06:16] <ScottK> I do think the U/I is cleaner in some respects, but that is much more than offset by my not being able to find things.
[06:16] <wgrant> Things should be in more obvious places.
[06:17] <wgrant> Part of it was moving the actions that were semi-randomly scattered around the page into the global actions menu in the top right.
[06:17] <wgrant> So if an action doesn't modify some value on the page, it should be in the top-right.
[06:17] <wgrant> Otherwise it's next to the value, which should be fairly obvious.
[06:17] <ScottK> But linking to a CVE does modify a value on the page.
[06:17] <ScottK> So does linking to a branch
[06:17] <wgrant> Ah, yes, those are a bit special.
[06:18] <ScottK> So does marking as duplicate and converting to a question.
[06:18] <ScottK> That's all the stuff in there.
[06:18] <wgrant> Converting to a question does not.
[06:18] <wgrant> Marking as a duplicate, linking to a CVE, and linking to a branch do not act on anything on the page if they haven't already been used.
[06:19] <ScottK> I see, so making something blank, not blank doesn't count?
[06:19] <Hobbsee> wgrant: I'm confused.  didn't they just try to do away with a global bar, and stick things around the page?
[06:19] <ScottK> Hobbsee: They did.
[06:20] <wgrant> Hobbsee: That was LP 2.0™
[06:21] <ScottK> wgrant: Is the way the bug information on the right side is the same level as the navigation stuff (Overview/Code/Bugs/etc) on purpose?
[06:21] <Hobbsee> wgrant: right
[06:21] <wgrant> ScottK: That's only on the person page, and was a rather late (and unfortunate, in my opinion) addition.
[06:21]  * Hobbsee pictures launchpad 4.0 in a complete tag cloud
[06:21] <ScottK> wgrant: No.  It's on the bug page too.
[06:21] <wgrant> ScottK: Note that the same sort of thing is used more appropriately on the project, distribution and source package pages.
[06:22] <wgrant> ScottK: Maybe I'm not understanding what you're talking about?
[06:22] <ScottK> The Bug number/reported by is at the same level as the navigation stuff
[06:22] <wgrant> ScottK: 'bug information'?
[06:22] <wgrant> Ah.
[06:22] <wgrant> Right.
[06:22] <wgrant> I disagree with that too!
[06:22] <wgrant> That change was made less than 24 hours ago.
[06:22] <wgrant> It doesn't make sense.
[06:23] <wgrant> But it was previously below there, which meant it forced the bug summary to wrap.
[06:23] <wgrant> That whole 'registered' line was only added a few days ago.
[06:23] <wgrant> It was rather rushed.
[06:24] <ScottK> wgrant: Make the U/I work again withough CSS would also be nice.  Unsubscribing without CSS has been broken since they ajax'ed it.
[06:25] <wgrant> ScottK: It will degrade if you have JS off, but not sure about CSS.
[06:25] <ScottK> On my phone I use neither.
[06:25] <ScottK> It used to work fine.
[06:25] <superm1> can you guys move this discussion to #launchpad or somewhere more appropriate?
[06:25] <ScottK> It makes the U/I actually tolerable.
[06:26] <ScottK> superm1: He was asking for input as MOTU rep for LP stuff.
[06:26] <ScottK> If anyone else has inputs, they should give it too.
[06:30] <zooko> ScottK: I gues 403 Forbidden on http://revu.ubuntuwire.com/revu1-incoming/tahoe-lafs-0909240639/tahoe-lafs_1.5.0-0ubuntu1_source.changes
[06:30] <ScottK> zooko: That's correct.  You just need to dget the .dsc.
[06:30] <zooko> Ah.
[06:30] <ScottK> If you had the .sources file signed by me you could upload it to Ubuntu and it would be accepted.
[06:31] <zooko> Nice.  :-)
[06:31] <ScottK> That's why it's not available.
[06:32] <ScottK> Good night everyone.
[06:32] <wgrant> Night ScottK.
[06:34] <zooko> ScottK: goodnight!
[06:34] <zooko> Anyone else: can you help me debuild this package?
[06:35] <zooko> I did it successfully (mostly) last night, but now I can't figure out how to make a package just like the previous one except with a different orig tarball.
[06:39] <zooko> Oh, I think I got it...
[07:41] <dholbach> good morning
[07:42] <mruiz> hi dholbach
[07:42] <dholbach> hola mruiz!
[07:42] <mruiz> guten morgen dholbach
[07:43] <dholbach> :-)
[07:43] <dholbach> how are you doing?
[07:43] <mruiz> fine, and you ?
[07:44] <dholbach> good :)
[07:44] <mruiz> upgrading my laptop to Karmic
[07:45] <dholbach> good luck ;-)
[07:46] <randomaction> good morning
[07:46] <dholbach> hi randomaction
[07:46] <randomaction> does BetaFreese affect universe?
[07:46] <mruiz> dholbach, have you ever read something as "`Depends' field, reference to `epiphany-webkit': error in version: version string is empty" ?
[07:47] <dholbach> randomaction: https://wiki.ubuntu.com/FreezeExceptionProcess should clarify that
[07:47] <dholbach> mruiz: where did you see that? can you pastebin a longer part of the log?
[07:48] <mruiz> dholbach, sure ... wait a sec
[07:48] <mruiz> dholbach, http://launchpadlibrarian.net/32146411/buildlog_ubuntu-karmic-i386.epiphany-webkit_2.27.92-2ubuntu1_FAILEDTOBUILD.txt.gz
[07:52] <dholbach> I guess that (>= ${gnome:Version}) is not substituted
[07:53] <dholbach> although I can't tell why it breaks there
[07:54] <dholbach> "line 7 package 'epiphany-browser'" does not really exist
[07:54] <mruiz> I found something related -> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528777
[07:54] <dholbach> maybe it's about the "," at the end
[07:54] <mruiz> I though the same
[07:55] <mruiz> but the package was built in Debian
[07:55] <dholbach> weird
[07:55] <dholbach> maybe ask seb128
[07:55] <mruiz> indeed
[07:55] <mruiz> :D
[07:55] <dholbach> he should know the /usr/share/gnome-pkg-tools/1/rules/gnome-version.mk stuff a bit better
[08:04] <mruiz> dholbach, thanks :-)
[08:05] <mruiz> dholbach, I've been fixing RC bugs on Debian :D
[08:13] <gaspa> yawwwn
[10:47] <stani> hi ScottK: thanks for the build log!
[11:29] <ScottK> stani: You're welcome.  Thank you for your interest in making Ubuntu better.
[11:36] <suji> hi
[11:37] <suji> when i run pbuilder for my package it shows the following error http://pastebin.com/m6c269637
[11:40] <geser> suji: you missing the build-dependency on pkg-config and probably libgtk2.0-dev too
[11:41] <suji> geser: oh! ok, i will add them now
[11:54] <suji> geser: after i add those packages in build dependencies again it shows this error http://pastebin.com/m64c66f18
[12:03] <slytherin> suji: The error lies at the top of the text you pasted.
[12:04] <suji> slytherin: what?
[12:05] <slytherin> suji: E: Failed to fetch http://mirrors.kernel.org/ubuntu/pool/main/j/jasper/libjasper1_1.900.1-5.1_i386.deb: Size mismatch
[12:05] <suji> slytherin: what to do for that? it happen because of Internet problem?
[12:06] <slytherin> suji: I may be because of problem in the mirror you are using.
[12:06] <slytherin> Or you can simply retry again.
[12:06] <suji> slytherin: how to change that mirror?
[12:06] <slytherin> suji: pbuilderrc file.
[12:07] <suji> slytherin: in my ~/.pbuilderrc file i have this COMPONENTS="main universe multiverse restricted"
[12:07] <slytherin> suji: after you modify the file, you will need to do sudo pbuilder --update --override-config
[12:07] <suji> slytherin: what should add in that file
[12:08] <slytherin> suji: Do you have something called MIRRORSITE ?
[12:08] <suji> slytherin: no, i have that one line only in ~/.pbuilderrc file
[12:09] <slytherin> suji: then add it, something like MIRRORSITE=http://archive.ubuntu.com/ubuntu
[12:10] <suji> slytherin: should i add this line which you gave here?
[12:10] <slytherin> yes
[12:14] <suji> slytherin : now also i got the same error like this
[12:14] <suji> E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/j/jasper/libjasper1_1.900.1-5.1_i386.deb: Size mismatch
[12:14] <suji> E: Unable to correct for unavailable packages
[12:15] <slytherin> suji: did you do 'sudo pbuilder --update --override-config' after updating the file?
[12:15] <suji>  slytherin: ya i did
[12:15] <slytherin> then I have no idea what the problem is.
[12:16] <suji> slytherin: the output for that is here http://pastebin.com/m7129a4d4
[12:19] <suji>  slytherin: can i add more than 1 mirror site in ~/.pbuilderrc?
[12:20] <slytherin> I never tried that
[12:21] <suji> slytherin: was the output of sudo pbuilder --update --override-config correct?
[12:22] <slytherin> suji: Yes, it was correct. Looks like problem is not with mirror.
[12:22] <suji> slytherin: Then what is the problem here?
[12:23] <slytherin> I have no idea
[12:24] <suji> slytherin: ok. Thank you for this much of help...
[12:55] <c_korn> has the debian packaging always to be under gpl ? means that a package maintainer always has to provide the diff.gz when asked for ?
[12:56] <c_korn> I ask because some projects create debian packages for themselves but the diff.gz is not available somewhere
[13:00] <slytherin> c_korn: No it doesn't need to be available under GPL. But it will need to be available under some Free license. Usually it is available under same license as upstream.
[13:01] <c_korn> fine, upstream license is LGPL. so I will ask for the diff.gz
[13:05] <_ruben> if packaging is done properly by upstream or when its a native package (kinda the same), no diff.gz is avail
[13:09] <c_korn> _ruben: there is no debian directory in the source tree if you mean that.
[13:17] <slytherin> c_korn: which package is this?
[13:19] <c_korn> slytherin: sip-communicator: http://download.sip-communicator.org/deb/binary/
[13:49] <Laney> geser: + a million to your mail
[13:50] <sebner> geser: great reply!
[14:00] <slytherin> sebner: Laney: on which list?
[14:02] <Laney> slytherin: ubuntu-devel
[14:03] <sebner> Laney: Packaging help thread
[14:03] <Laney> not me
[14:04] <sebner> Laney: argh sry
[14:04] <sebner> slytherin:  Packaging help thread
[14:05] <AnAnt> DktrKranz, directhex: congrats
[14:05] <directhex> thanks
[14:05] <AnAnt> directhex: how much time did it take from being NM to DD ?
[14:06] <directhex> https://nm.debian.org/nmstatus.php?email=directhex%40apebox.org contains all relevant dates
[14:20] <slytherin> directhex: congrats
[14:20] <directhex> ta
[14:25] <nicklas_> hallå
[14:25] <slytherin> geser: exactly what I had in mind for some time. :-)
[14:36] <sharms> dholbach: thanks for looking over that bug for me
[14:37] <dholbach> sharms: no worries
[14:53] <DktrKranz> AnAnt: /me was a little bit older than today's mail, but thanks anyway :)
[15:01] <ScottK> sistpoty|work: Would you please take a look at Bug 434972
[15:01] <sistpoty|work> *looking*
[15:01] <ScottK> Thanks.
[15:03] <sebner> huhu sistpoty|work ScottK =)
[15:03] <sistpoty|work> hi sebner
[15:04] <sebner> sistpoty|work:   	Universität Erlangen gründet Open-Source-Forschungsgruppe  <--- wuhu ;)
[15:04] <sistpoty|work> <-- different chair though. (computer achitecture) :D
[15:06] <sebner> sistpoty|work: still great and you could change :P
[15:06] <sistpoty|work> haha
[15:09] <sistpoty|work> ScottK: ack'd
[15:09] <ScottK> sistpoty|work: Thanks.
[15:13] <sebner> ScottK: I'm about to leave but phatch FTBFS for me. I'll post the necessary stuff on the bug report
[15:18] <jbernard_> sebner, ScottK: I'll be happy to take a look at Phatch's FTBFS if nobody else has
[15:18] <sebner> ScottK: you have a FTBFS yourself and still give an ACK? I know it have to be fixed anyways but it seems to me you didn't notice that
[15:19] <sebner> jbernard_: check with ScottK, I'm afk now
[15:19] <jbernard_> sebner: will do
[15:24] <POX> phatch FTBFS? can someone point me to build log?
[15:25] <geser> POX: see https://bugs.edge.launchpad.net/ubuntu/+source/phatch/+bug/434972/comments/8 for the error
[15:26] <jbernard_> yep, im getting the same error here
[15:26] <geser> http://launchpadlibrarian.net/32344046/phatchlog seems to be the complete build log
[15:26] <POX> damn, lat me guess /usr/*local*bin/
[15:27] <POX> I will fix it after work
[15:27] <geser> POX: correct: creating /tmp/buildd/phatch-0.2.1/debian/phatch-cli/usr/local
[15:28] <mok0> It would be very useful to have those FTBFS'es mapped onto a dependency tree
[15:32]  * POX didn't notice this bug as he fixed this cdbs' bug locally already
[15:32] <POX> (and uploaded binNMU to DELAYED/7)
[15:33] <POX> #537373
[15:35] <bddebian> Heya gang
[15:42] <sistpoty|work> hi bddebian
[15:42] <bddebian> Heya sistpoty|work
[16:10] <RoAkSoAx> ScottK, any news on the nginx issue?
[16:17] <mok0> Hm, there's nowhere to make a comment that you've fixed a FTBFS on that test-rebuild page
[16:21] <geser> mok0: no, but the package should move to the superseded section once the fixes package got uploaded (and the page updated)
[16:21] <mok0> geser: ok, is that done often (page update)?
[16:39] <geser> mok0: I'm not sure but it might be every 2h
[16:40] <mok0> geser: alright, that's fair
[16:40] <mok0> geser: would filing a lp bug for each FTBFS be a good idea?
[16:41] <mok0> geser: I mean, it should happen automatically
[16:42] <geser> mok0: as the problem might not be in the package itself but any other package it needs human investigation
[16:43] <mok0> geser: yes that's right, but still it would be good to have the issue recorded IMO
[16:43] <geser> it might even be a no bug at all e.g. if a build-dependency isn't installable because it's still in the queue on an other arch or failed there
[16:43] <mok0> geser: that is also true of "ordinary" bugs
[16:44] <mok0> geser: the culprit might be in another app
[16:45] <mok0> geser: I've seen several bugs on the test-build list that are due to other packages failing, but there's no way to note down my findings
[16:45] <mok0> geser: which means that someone else might waste time figuring out the same
[16:46] <geser> mok0: yeah, a comment feature would be nice, so don't need to look at the same bugs several times just do find out that I can't do anything about it yet
[16:46] <mok0> geser, also, history is lost. The same thing might happen to the same package next release
[16:50] <geser> mok0: if it was a real bug then the changelog should tell it (as it was hopefully fixed) but would it really help you to know that a package ftbfs once in the past because of build ordering and one being faster then another?
[16:50] <mok0> geser: well, not if the changelog tells it, but that info is often lost if the ubuntu package is superceeded
[16:51] <mok0> geser: I also like to think of LP as a place where the Ubuntu dev work is documented
[16:55] <geser> if you have good ideas how to improve our workflow without distributing infomations too much let us know it
[16:56] <geser> e.g. it would be good to have the FTBFS list included into LP and not outside of it so it could be updated more often
[16:57] <jbernard_> Laney: ive got a patch for pull-lp-source to make it work with the new LP api
[17:03] <jbernard_> bug filed: Bug #436006, if anyone has a chance to take a look I'd greatly appreciate it
[17:07] <zooko> RainCT: could you please re-upload Tahoe-LAFS?  ScottK pointed out a licensing omission that I've fixed.
[17:11] <tntcoda> hi, if ive made a .deb file for some software im releasing, can/how do i go about getting it in the ubuntu repos?
[17:11] <kklimonda> !revu
[17:11] <kklimonda> tntcoda: ^----
[17:12] <mok0> tntcoda: you can also make a PPA on LP and distribute that way
[17:13] <tntcoda> thanks alot
[17:14] <tntcoda> if its a new piece of software, am i better of just advertising a link to the package on my sourceforge site? And look into repo inclusion further down the line
[17:15] <mok0> tntcoda: It _will_ take a good while to get your software through review
[17:15] <tntcoda> ah i see thanks, will avoid that route for now then :)
[17:15] <mok0> tntcoda: ... and you need to be prepared to spend some time asking MOTUs to review it
[17:16] <mok0> tntcoda: Once Karmic is out, we will restart "revu-day" each friday
[17:16] <tntcoda> is there any kind of central community based package listing where i can submit it?
[17:16] <mok0> tntcoda: that is the REVU site mentioned above... here it comes again
[17:17] <mok0> !revu > tntcoda
[17:17] <mok0> tntcoda: ubottu is our slave :-)
[17:18] <tntcoda> thanks, sorry. I guess I will just stick to advertising in in non-mainstream package listings like forums until it gains some popularity
[17:18] <mok0> tntcoda: if your users are on ubuntu, a PPA is not a bad idea
[17:18] <tntcoda> ok thanks alot
[17:23] <dkurochkin> hi! what is a proper section for universe network-related package? I thought it should be universe/net but lintian does not like it.
[17:24] <mok0> dkurochkin: "network" probably
[17:25] <mok0> dkurochkin: see what your choice is here:  http://packages.ubuntu.com/karmic/
[17:29] <mok0> dkurochkin: in debian/control, you need to use one of the keywords listed here: http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-archive.html#s-subsections
[17:29] <mok0> dkurochkin: so yours would be "net" actually
[17:32] <dkurochkin> mok0, thanks. I thought that universe is the segment. If universe is not mentioned in section, then it is not mentioned in control at all. Is this how it should be?
[17:32] <mok0> dkurochkin: universe is not mentioned in the package at all
[17:33] <dkurochkin> thanks@
[17:33] <mok0> dkurochkin: it's defined in the archive itself
[17:36] <jpds> jbernard_: Ping.
[17:38] <jbernard_> jpds: shoot
[17:38] <jpds> jbernard_: Just reviewed your patch for bug #436006.
[17:39] <jbernard_> jpds: did everything explode?
[17:39] <jpds> jbernard_: It's usual to name the branch something like: lp:~jbernard/ubuntu-dev-tools/fix_api_change . :)
[17:39] <jbernard_> jpds: ahh, good to know, thanks
[17:40] <jpds> jbernard_: And then requesting a merge into the mainline with the branches equivilant of https://code.edge.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk/+register-merge
[17:41] <jpds> jbernard_: Anyway, thanks for the patch, works fine. ;)
[17:41] <jpds> :)*
[17:41] <Amaranth> nixternal: Hi, I can't seem to find anything on the wiki so I was hoping I could ask you about this. I used to be MOTU but let my membership expire. Should I go through the steps to apply again or is there some sort of faster route for former members?
[17:42] <jbernard_> jpds: oh excellent, i was not aware of that workflow, but that makes way more sense then my approach
[17:42] <jbernard_> jpds: thanks for the info
[17:42] <nixternal> Amaranth: reapply, but let it be known that you were a MOTU and you are just tring to get reinstated...same process
[17:43] <Amaranth> nixternal: alright
[17:43] <jpds> jbernard_: No problem, thanks for the catch and fix.
[17:43] <mok0> Amaranth: check out the ML archives, it happens now & then
[17:43] <nixternal> unless of course I missed something recently where it changed :)
[17:43] <jbernard_> jpds: No problem
[17:43] <Amaranth> I don't have any recent packaging work to show, just a few commits to compiz packaging bzr
[17:44] <Amaranth> I'm actually just trying to get upload access for compiz, to be honest :)
[17:45] <mok0> Amaranth: write an email to ubuntu-motu@l.u.c and explain that
[17:46] <Amaranth> Right, just wanted to make sure I wasn't going to get shot down right away :)
[17:46] <mok0> Amaranth: oh, no
[17:46] <Amaranth> mok0: Although it should be motu-council@l.u.c, no?
[17:46] <mok0> Amaranth: if you prefer
[17:47] <mok0> Amaranth: ... but you need advocates among the ordinary MOTU population :-)
[17:48] <Amaranth> hmm, guess I can't rely on the Desktop Team there :)
[17:48] <mok0> Amaranth: vorian recently rejoined
[17:48] <mok0> Amaranth: if you check out the ML archive in june
[17:54] <mok0> Amaranth: jcorbier rejoined march 09, imbrandon april 09, bluekuja july 09
[17:54] <mok0> Gotta go see you later
[17:56] <geser> Amaranth: to reapply, it's a light-weight process: write a mail to MC about it, add yourself to the meeting agenda, be there and ready to answer some questions :)
[18:06] <Laney> jbernard_: I didn't know it was broken!
[18:06] <Laney> infact I used it just last night
[18:06] <jbernard_> Laney: well, it was only broken for a short time ;)
[18:06] <jbernard_> at least for me, please feel free to verify
[18:06] <Laney> I trust you :)
[18:06] <Laney> I don't like that bit of the code anyway
[18:06] <Laney> is there an API way to get the dsc?
[18:07] <jbernard_> hmm, there may be, but im not sure
[18:07] <Laney> never mind, that's another issue
[18:08] <Laney> you are very free to fix it though
[18:08] <jbernard_> it's fixed in trunk now, i would expect that to be released soon
[18:08] <Laney> i'll upload it later
[18:09] <jbernard_> awesome, thanks!
[18:09] <Laney> thank *you*!
[18:26] <geser> Laney: IIRC there is a bug about it (getting the files through the API) but it's still open
[18:29] <ScottK> sebner: It's because I can't read (phatch FTBFS).  Thanks for catching it.
[18:29] <geser> Laney: bug 394827
[18:31] <jtimberman> can any MOTU take a look at LP bug 424576 and bug 420674 ? Chef debdiff is in former and libmixlib-config-ruby needs a sync from Debian sid.
[18:37] <juliux> hi tried to build a package from perlbal with some extra patches, for that i checkout the source from http://code.sixapart.com/svn/perlbal/tags/Perlbal-1.72/, then i created a debian/patches dir and put my patches in there, then i added the debian/rules file like founded in https://wiki.ubuntu.com/PackagingGuide/PatchSystems#Patching Without a Patch System is that the right way?
[18:38] <juliux> i try to build the packe then with dpkg-buildpackage -S -rfakeroot  but my patches don´t get applied
[18:38] <fabrice_sp> juliux, is the package in Ubuntu?
[18:38] <juliux> fabrice_sp: not yet
[18:38] <juliux> fabrice_sp: but i need it for a ubuntu server setup;)
[18:39] <fabrice_sp> juliux, in that case, you should use a patch system
[18:40] <juliux> fabrice_sp: any favorites?
[18:41] <fabrice_sp> hmm, I like quilt, but if you use cdbs, it's easy to use the 'native' patch system
[18:41] <geser> juliux: the one you like best
[18:42] <juliux> geser: one for a beginner;)
[18:42] <juliux> geser: btw we have some free slots at ubucon-de left;9
[18:46] <dkurochkin> hi, fabrice_sp. Thank you for reviewing polygraph package. Can we discuss your comments?
[18:46] <fabrice_sp> dkurochkin, sure
[18:47] <geser> juliux: all are pretty easy, although I prefer dpatch a little bit
[18:48] <juliux> geser: is there a howto to read?
[18:48] <dkurochkin> fabrice_sp, Is it ok to have a one placeholder man page pointing to the web site, and for all binaries man pages use .so macro to refer to it?
[18:49] <fabrice_sp> dkurochkin, as a user, I prefer to have something that explain what the program do, or at least, in my system
[18:50] <fabrice_sp> I don't know what polygraph do, and I only see a huge bunch of programs :-)
[18:51] <dkurochkin> I understand that. But it would take much time to write proper man pages. I agree that this is a bug. But does it stop package from entering the archive?
[18:51] <geser> juliux: are you using only debhelper or also cdbs?
[18:51] <juliux> geser: only debhelper
[18:52] <fabrice_sp> dkurochkin, is there some existing 'doc' that can  be reused?
[18:52] <juliux> geser: that is the point where i start http://code.sixapart.com/svn/perlbal/tags/Perlbal-1.72/
[18:53] <dkurochkin> fabrice_sp, online only. I do not think there is a simple way to convert it to man pages.
[18:54] <sebner> ScottK: nvm =)
[18:55] <fabrice_sp> dkurochkin, even a simple one? With just the program description and flags? Also, I don't know if it will prevent your package to enter the archive
[18:56] <fabrice_sp> dkurochkin, anyway, no new packages will be added now that we are so close from the release date for Karmic, so you will have to wait for the next version
[18:59] <dkurochkin> fabrice_sp, option list is available through --help.
[18:59] <geser> juliux: in that case quilt should be probably the easiest to add (see /usr/share/doc/quilt/README.Debian, Using quilt in other packages or if you want to use dpatch adapt the examples from /usr/share/doc/dpatch/examples/rules/rules.dh.gz)
[18:59] <fabrice_sp> dkurochkin, so a simple manpage can be description, and --help flag
[18:59] <fabrice_sp> anyway, it's up to upstream to do ti :-)
[19:00] <fabrice_sp> (maybe, you are upstream ? )
[19:00] <dholbach> fabrice_sp, mterry, mdeslaur: welcome to the team - you're now in :)
[19:00] <fabrice_sp> thanks dholbach :-)
[19:00] <dkurochkin> fabrice_sp, yes, I do some upstream development
[19:00] <mdeslaur> thanks dholbach
[19:01] <fabrice_sp> is there a 'new motu' wiki page?
[19:01] <mterry> dholbach, sweet
[19:01]  * mterry goes mad with power
[19:01] <fabrice_sp> dkurochkin, a simple manpage would help your user, and you can add a reference to --help and the url of the online help
[19:01]  * fabrice_sp goes scared by the power
[19:02] <dkurochkin> fabrice_sp, sounds like a good option.
[19:02] <sebner> ScottK: POX: anyone around of you?
[19:02] <ScottK> sebner: Yeah
[19:02] <dholbach> have a great rest of your day! see you tomorrow!
[19:03] <sebner> ScottK: I now testbuilt phatch -2 and it works now. But the applications is not usable /here. If I start it apport catches up. I'll post the message. Give me a sec
[19:03] <juliux> geser: is there a howto online which explain how to work with quilt?
[19:03] <sebner> gn8 dholbach =)
[19:03] <dkurochkin> fabrice_sp, what is the correct maintainer field? You said it is wrong, but suggested the same address :)
[19:03] <dholbach> bye sebner
[19:03] <ScottK> sebner: We need stani to discuss that then.
[19:04] <fabrice_sp_> dkurochkin, sorry. Got disconnected
[19:05] <dkurochkin> fabrice_sp, what is the correct maintainer field?
[19:05] <sebner> ScottK: kk, do you know when he is online? I'll be away for another hour in some minutes. Here the log when I start phatch up (the icon appears though), apport starts: http://paste.ubuntu.com/277300/
[19:06] <POX> sebner: sebner did you install phatch-cli?
[19:06] <POX> phatch depends on it
[19:06] <geser> juliux: when I need to work with quilt (and didn't use it much in the last time) I use: https://wiki.ubuntu.com/PackagingGuide/PatchSystems#quilt%20%28example%20package:%20xterm%29
[19:07] <sebner> POX: YES! as I said the phatch Icon appears,
[19:07] <geser> POX: do you have a hilight on phatch?
[19:08] <POX> sebner: /usr/share/phatch/data/geek.txt is provided by phatch-cli
[19:08] <juliux> geser: that i have done but how should i add that to debian/rules
[19:08] <juliux> ?
[19:08] <POX> geser: no, I have one on "POX", though :)
[19:08] <sebner> POX: sebner@ubuntu:~$ less /usr/share/phatch/data/geek.txt
[19:08] <sebner> /usr/share/phatch/data/geek.txt: No such file or directory
[19:08] <fabrice_sp_> dkurochkin, the one done by update-maintainer
[19:09] <fabrice_sp_> Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
[19:09] <sebner> POX: ./usr/local/share/phatch/data/geek.txt
[19:10] <POX> damn, it needs --install-data as well?
[19:10]  * POX is uploading -3
[19:10] <sebner> POX: everything in /usr/local
[19:10] <geser> juliux: the quilt readme file I mentioned show how to add it easily (include the quilt.make file, and modify the targets to get patches applied/deapplied)
[19:10] <POX> well, I'll use --prefix instead
[19:10] <POX> this shoud fix it for good
[19:10] <POX> should
[19:10] <sebner> POX: not everything. Half of it ^^
[19:11] <sebner> POX: http://paste.ubuntu.com/277306/
[19:11]  * POX will create Ubuntu env. first
[19:15] <POX> sebner: could you replace --install-scripts=/usr/bin with --prefix=/usr and build it again?
[19:15] <POX> (just to test it)
[19:15] <sebner> POX: I can but I'm afk now for a hour :\
[19:15] <POX> ok, hour should be enough to download all the ubuntu packages
[19:16] <juliux> geser: i have followed the howto but the patches don't get applied :(
[19:16] <chrisccoulson> congrats fabrice_sp!
[19:17] <juliux> geser: ah don't read your last message
[19:17] <fabrice_sp_> chrisccoulson, thanks :-)
[19:18] <juliux> geser: btw i don't have the REAME.Debian file;)
[19:20] <sharms> If anyone gets a chance to review this for me that would be great
[19:20] <sharms> https://bugs.launchpad.net/ubuntu/+source/minicom/+bug/436082
[19:23] <geser> juliux: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/karmic/quilt/karmic/annotate/head%3A/debian/README.Debian
[20:02] <sebner> POX: do you still need testing?
[20:04]  * POX is still creating base.tgz
[20:04] <POX> so yes
[20:04] <sebner> POX: kk
[20:04] <POX> if you'll confirm that --prefix works fine, I'll upload
[20:04] <POX> though
[20:05] <POX> I'm 99% sure it will work fine
[20:06] <POX> ok, downloaded
[20:06] <sebner> POX: heh, anyways, I've discovered the main reason it can't work
[20:07] <POX> building...
[20:07] <sebner> POX: you are using cdbs instead of dh7 :P :P :P  yeah, /me testbuilding also right now
[20:07] <juliux> geser: thanks for your help, it worked;)
[20:08] <POX> sebner: I'm using everything (I'm a sponsor, so I have to know all the tools)
[20:08] <POX> ;-P
[20:08] <sebner> POX: but you are also maintainer :P
[20:08] <POX> sebner: I even NMUed cdbs to fix this bug in Debian
[20:09] <sebner> POX: bah, dealing with the devil and his black magic :\
[20:10] <sebner> POX: Confirmed! Working now like a charm
[20:11] <POX> ok, I'm uploading
[20:16] <POX> sebner: test it for a while, Phatch is really nice :)
[20:17] <sebner> POX: I'm trying out the actions and my image never changes *cough*
[20:17] <sebner> aha
[20:17] <sebner> folder on Desktop
[20:17] <sebner> !
[20:17] <sebner> ^^
[20:18] <POX> you can change destination in the action
[20:20] <sebner> POX: right, nice tool. Please tell me if -3 is in incomming. I want to give it a final testbuild and install before I give my ACK
[20:20] <POX> should be already there
[20:21] <sebner> POX: nope,
[20:29] <sebner> POX: still no -3
[20:29] <POX> I uploaded it long time ago (still waiting for DAK message, though)
[20:30] <sebner> kk
[20:32] <POX> http://people.debian.org/~piotr/phatch_0.2.1-3.dsc
[20:35] <sebner> POX: Wondering why -3 doesn't override -2 in incomming
[20:40] <sebner> POX: ACKED! :)
[20:42] <POX> great
[20:43] <sebner> POX: thx for your hard work :)
[20:43] <POX> I have python2.6 isntalled (from experimental)
[20:43] <POX> it's not the default one, though
[20:43] <sebner> POX: haha. ubuntu bleeding edge ftw!
[20:44] <POX> sebner: do you want to know how many packages you missed to fix for 2.6 in Ubuntu?  ;)
[20:44] <ScottK> I think the original model for for Ubuntu to be with/behind Sid and ahead of Testing.
[20:44]  * ScottK wishes to go back to that.
[20:45] <POX> sebner: see debian-python for some details
[20:45] <sebner> POX: hehe, nahh I'm normally not into pyhton
[20:45] <sebner> ScottK: bleeding edge ftw! :P You are right for some components though
[20:45] <POX> sebner: it's still better than what you did with python2.5 (over 100 broken packages for >2 years)
[20:45] <sebner> POX: /me != ubuntu :P
[20:46] <sebner> POX: the can top that with python3 IMHO *cough*
[20:46] <sebner> *the = we
[20:46] <POX> well, if you want, I can give you some examples how badly you do Python transitions in Ubuntu
[20:46] <POX> I wanted to convince doko to do transitions in Debian, no luck
[20:46] <sebner> POX: I don't touch python stuff, complain to DktrKranz and ScottK :P
[20:47] <POX> both of them don't like how python is handled in Ubuntu
[20:47] <sebner> POX: so doko is the culprit?
[20:47] <POX> DktrKranz, ScottK: right?
[20:48] <POX> yup
[20:48] <sebner> POX: we (pkg-cli) do transition in Debian though, the best/softest solution
[20:51] <Laney> yeah I'm not happy with the way the transition(s) went
[20:51] <Laney> no management
[20:51] <sebner> Laney: \o/
[20:51] <Laney> hi there sebner
[20:55] <zooko> ScottK: You suggested that I have my "sponsor" "upload" Tahoe-LAFS again.  Is my "sponsor" somebody like RainCT who kindly offers to move Tahoe-LAFS from REVU to the Karmic Queue?  And is that event what "uploading" is?
[20:56] <maco> i can haz sponsor? bug 436145
[20:56] <maco> zooko: that sounds about right to me...
[20:59] <sebner> mterry: congratulations ;)
[21:00] <mterry> sebner, :)  thanks
[21:04] <maco> oh yeah, "plz?"
[21:27] <ScottK> zooko: Yes
[21:28] <ScottK> zooko: Or you could talk mterry into doing it.  He can do that now.
[21:28]  * mterry pokes ScottK in the side
[21:28] <ScottK> maco: hunspell-en-us is in Main, so you need a main sponsor for that.
[21:29] <ScottK> mterry: It's good practice.
[21:29] <maco> ScottK: james_w said he'd do it as soon as beta freeze is over
[21:29] <ScottK> OK
[21:29] <mterry> ScottK: :)  I don't what you're referencing, but I can certainly sponsor something
[21:29] <maco> ScottK: and yeah i know, but i figure there *are* some core-devs here
[21:29] <maco> example: you :)
[21:29] <ScottK> mterry: Look at zooko's comment ~35 minutes ago
[21:30] <ScottK> maco: Yes, but I'm not at a box that has any keys on it.
[21:30] <zooko> mterry: will you please upload Tahoe-LAFS: http://revu.ubuntuwire.com/p/tahoe-lafs
[21:30] <mterry> ScottK: wasn't here for that.  Skipped out due to wifi issues
[21:30] <maco> ScottK: its ok. theres a freeze anyway
[21:31] <ScottK> mterry: I rejected it last night for lack of a full, verbatim copy of all the Licenses in the upstream tarball.  He says he's fixed that now.
[21:31] <mterry> zooko, I'll look at it today.  Am busy this second.  If you need it faster, poke someone else.  Else I'll get to it
[21:31] <zooko> mterry: thanks!  If I see someone else pokable, I will poke then, because I'm very eager to get this in an apt-gettable so that a bunch of my users can test it out in its new Karmic home.
[21:32] <zooko> james_w: poke?
[21:32] <james_w> hello zooko
[21:32] <zooko> Hi there!  Are you drunk?
[21:32] <james_w> not yet
[21:32] <zooko> Good!  How would you like to upload Tahoe-LAFS: http://revu.ubuntuwire.com/p/tahoe-lafs
[21:32] <james_w> where do I find it
[21:32] <james_w> aha!
[21:33] <jcastro> tahoe looks interesting
[21:36] <zooko> jcastro: have you seen this: http://allmydata.org/source/tahoe/trunk/docs/about.html
[21:36] <jcastro> yeah, I was just waiting for it to go into ubuntu to play with it
[21:37] <james_w> zooko: ./mac/10.4/fuseparts/_fusemodule.so
[21:37] <zooko> Cool!
[21:37] <zooko> james_w: :-(  Is that in there.
[21:37] <james_w> yep
[21:37] <james_w> and stuff like ./windows/winfuse/NeoGeo.Library.SMB.Provider.dll
[21:37] <zooko> So, how about I build a new package by downloading the current package, /bin/rm -rf ./mac, repack the upstream tarball, build a new package.
[21:37] <zooko> Is that a good str
[21:37] <zooko> /bin/rm -rf ./mac ./windows
[21:38] <zooko>  /bin/rm -rf ./mac ./windows
[21:38] <james_w> that would work
[21:38] <zooko> Was that always in there?  I wonder if I accidentally regressed the packaging work that Brian Warner and RainCT have already done...
[21:38] <ScottK> It's generally OK if stuff for other OS is in the source, but it shouldn't go in the binary.
[21:38] <james_w> yeah, it's not a blocker, providing that it is distributable
[21:38] <zooko> Oh, fine then (although we really *shouldn't* have binary gunk in our tarballs...)
[21:39] <james_w> and that if it is (L)GPL licensed the source must be there as well
[21:39] <zooko> Those are distributable, under the same licences as Tahoe-LAFS itself.
[21:39] <zooko> Hm.
[21:39] <ScottK> zooko: But is the source to build them in there too?
[21:39] <zooko> I'm not sure about where the source is.  :-(
[21:39] <zooko> Better get rid of it.  Been wanting to anyway.
[21:39] <ScottK> Best remove it then.
[21:39] <zooko> But, I'm at work and don't have access to my Linux system for now, so it will have to wait til tonight.
[21:39] <james_w> and I'm having trouble seeing the source for the fuseparts stuff, which appears to be LGPL
[21:40] <RoAkSoAx> ScottK, any news on the nginx issue?
[21:41] <zooko> How do I find on REVU which is the upload that RainCT did?
[21:41] <james_w> zooko: I could do it for you, but the more I do with it the more I will feel the need to get someone else to do the final review
[21:41] <james_w> zooko: if I stand back from this bit I can review it from the queue tomorrow morning if it is still there
[21:41] <zooko> Oh, I'll look at this one: http://revu.ubuntuwire.com/details.py?upid=6899
[21:42] <zooko> james_w: thank you for the offer.
[21:42] <zooko> Both offers.  :-)
[21:43] <zooko> Okay I see that the one Brian uploaded also had this binary goop in it.
[21:45] <ScottK> RoAkSoAx: Didn't get a chance to look.
[21:51] <RoAkSoAx> ScottK, ok.
[21:54] <zooko> james_w: I added a comment to http://revu.ubuntuwire.com/p/tahoe-lafs . You might want to double-check that my thinking is correct.  I intend to work on this tonight.
[21:55] <james_w> zooko: we only require source if the license requires source
[21:56] <james_w> the main requirement is to have clear licensing that permits redistribution of the binaries
[21:56] <james_w> the GPL grants that, but with a source requirement
[21:56] <james_w> so fulfilling the main requirement sometimes requires source
[21:56] <james_w> we can navigate this if needed, but if you want to rip it out then do so, it makes it much easier
[21:59] <zooko> join #tahoe to see the automatic bot message saying that I just committed a patch to trunk to rip out binaries. :-)
[22:25] <zooko> Okay committed patches to Tahoe-LAFS trunk to rip out the binaries so that the Tahoe-LAFS hackers can begin the healing process of fixing the build system to build from source.  :-)
[22:25] <zooko> Tonight I'll try to build a new package for Karmic and put it on the revu ticket.
[22:26] <mterry> zooko: (has been in and out) so I should wait then?  k
[22:27] <zooko> mterry: yes, I don't have anything ready to upload.  :-(  Thanks!
[22:31] <Laney> wow
[22:31] <Laney> minicom has interesting packaging
[22:35] <Laney> sharms: Can you convert your patch to a diff in debian/patches?
[22:44] <geser> zooko: have you tried to use a watch file for tahoe-lafs?
[22:46] <zooko> geser: not yet.  There hasn't been a new stable release of Tahoe-LAFS since we started the Ubuntu-packaging project anyway.
[22:48] <geser> zooko: I've seen that your get-orig-source only download the tar.gz (and renames it) which could be replaced with uscan and debian/watch file (if it works with cheeseshop.python.org)
[22:49] <zooko> geser: thanks.
[23:34] <zooko> Oh, james_w, if that offer is still open, would you go ahead and generate a Tahoe-LAFS package on REVU just like the most recent one but minus these files: ./mac/10.4, ./mac/10.5, ./windows/winfuse .
[23:34] <zooko> And since you would then be less comfortable uploading it to the Karmic Queue, perhaps mterry would do so.
[23:35] <zooko> I committed these patches to Tahoe-LAFS trunk and watched the buildbots test it: http://allmydata.org/trac/tahoe/changeset/4064 http://allmydata.org/trac/tahoe/changeset/4063
[23:36] <zooko> As expected, removing those binaries did not break anything except the build of the WinFUSE module on Windows, which by rights belongs to a different project anyway.