[00:00] <Saj0577> the key appears on Passwords and Encrypted Keys. That right yeah?
[00:00] <Saj0577> I need to upload it to LP?
[00:00] <stdin> you need to upload to LP if you want to dput, yeah
[00:00] <Saj0577> okay thanks
[00:06] <slangasek> but that's not the reason for the error with debuild
[00:07] <slangasek> that error is because the name/email in your changelog and GPG key don't match exactly, or because gpg can't find your private key at all
[00:09] <Saj0577> slangasek its uploaded and activated on LP and still same problem
[00:10] <slangasek> yes, I said, that's not the reason for the error with debuild
[00:10] <Saj0577> the name and email are identical in key and the changelog
[00:11] <emgent> night people
[00:11] <Jazzva> Saj0577: Try passing your gpg key to debuild with -kABCD1234 where ABCD1234 is your gpg key
[00:11] <Jazzva> you can find it with gpg --list-keys
[00:12] <Saj0577> space between -k and they key or exactly like that?
[00:12] <Jazzva> Easiest way (that I know of) would be setting it in ~/.bashrc
[00:12] <Jazzva> Exactly like that
[00:12] <Saj0577> debuild -k<key here>
[00:12] <Saj0577> yes?
[00:13] <Jazzva> Yes. Along with other parameters you're passing (-S etc...)
[00:13] <Saj0577> k
[00:13] <Saj0577> that worked
[00:13] <Saj0577> thank you
[00:13] <Jazzva> if you want to skip passing your key to debuild every time, you can add something like this to ~/.bashrc http://paste.ubuntu.com/19746/
[00:13] <Jazzva> np
[00:14] <Jazzva> Just adjust it to your key, name and e-mail
[00:14] <Saj0577> Thanks again :)
[00:14] <Jazzva> np, again :)
[00:15] <Saj0577> just plonk it on bottom? can i add multiple keys that way?
[00:16] <Jazzva> Yes, you can put it on the end. I don't think you can use multiple keys that way. But maybe I'm wrong.
[00:16] <Saj0577> k
[00:18] <Saj0577> Jazzva: you tend to use different gpg keys for diffferent things or same one for everything?
[00:19] <Jazzva> The same one for everything.
[00:19] <Saj0577> okays
[00:19] <Saj0577> I will delete my others then and keep it simple :D
[00:20] <Saj0577> If I delete it off my home computer its still on ubuntu which i can pull it from is it not?
[00:21] <Jazzva> You can pull your public key from keyserver, but not the private one. Private keys should stay only on your computers.
[00:22] <Saj0577> okay when i go to delete it it says back it up first hum
[00:22] <Saj0577> done exported it :D safe to deelte noe
[00:23] <Saj0577> delete now*
[00:50] <persia> Saj0577: If you've ever put a key on the keyserver, you want to revoke it before you delete it.  If it's just a local key, it doesn't matter as much.
[00:50] <Saj0577> persia: thanks :)
[01:13] <rzr> any news on Alpha 1 ?
[01:14] <slangasek> well, did you see the news posted to u-d-a?
[01:25] <Saj0577> you know when someone wants to open a email that you encrypted with gpg what pw you give them?
[01:25] <Saj0577> PGP sorry ;)
[01:26] <persia> Saj0577: Often no password at all.  The typical model is to send it encrypted to their GPG key, and they use their own passphrase to open it.
[01:26] <Saj0577> O okay so in thunderbird how i tell it to send to there key ( i have engima installed)
[01:30] <persia> Saj0577: It should automatically work, as long as their keys are already in your keyring.
[01:30] <Saj0577> So just get them to send there public key to me and then i select it when sending. And then when they recieve it they decrypt it wiht there own pw for there key?
[01:31] <persia> Well, that's not a real safe way to do it, but it works.  Safer is to get them to send you their fingerprint, download that key from the keyservers, make sure there is an acceptable chain of trust to the key, and then send it.  Their side is unchanged.
[01:33] <Saj0577> Okay because what i was thinking is i dnt want ot have to EVER tell anyone my password
[01:34] <persia> Saj0577: That's the point of Public Key Cryptography: you know the password to your secret key, and never have any reason to share.  You can give your public key to everyone, and they can encrypt things so that you need the secret key to unlock them (or a reasonable cluster and some time)
[01:35] <Saj0577> Yeah okay. So if i export my public key send it to a friend and they import it in seahorse. then they can just select it send me an email i then decrypt it with my private key password. yeah?
[01:35] <persia> Yes
[01:36] <persia> (except for the bit about having previously taken steps to ensure that you have the right keys, via out-of-band communications)
[01:37] <Saj0577> out-of-band communications?
[01:37] <slangasek> if you have to encrypt your traffic because you don't trust the network that it's being sent across, then you also can't rely on that network to make sure you have the right key for your interlocutor
[01:37] <persia> Yes.  Imagine if you will that I want to read your mail to your friend.  So I tap your telephone and packet lines, and can see everything you share in cleartext or voice.
[01:38] <persia> Now, I can pretend to be your friend, and give you the wrong key, which means I get to read your mail.  As long as I resend it to your friend with the right key, they don't notice.
[01:38] <persia> You need to exchange the keys in a way you know to be secure, or through a trust metric you believe to be secure to avoid this.
[01:39] <Saj0577> Yeah. So basically send the public key to them via face-to-face etc?
[01:39] <persia> Saj0577: For some vaues of send, yes.
[01:39] <Saj0577> okay.
[01:39] <persia> Google "keysigning" for more information that you need on the topic.
[01:39] <Saj0577> persia: thanks for explanation :)
[01:40] <Saj0577> And how secure are they do you think? How long it take people to crack them?
[01:40] <persia> Saj0577: That you'll have to investigate elsewhere.
[01:40] <Saj0577> okay :)
[01:41] <Saj0577> persia: thanks.
[02:16] <leleobhz> what i do if a package requires sse2 support/
[02:16] <leleobhz> ?
[02:18] <YokoZar> Do we support processors without sse2 support?
[02:19] <leleobhz> must to... main is i386 oriented
[02:19] <leleobhz> ;]
[02:22] <persia> YokoZar: Yes.  I believe we currently support anything above a 486DX for i386.
[02:22] <persia> (At least I think the 486sx doesn't work, but I haven't tested)
[02:22] <leleobhz> persia: but what i do about packages thar require sse2?
[02:23] <persia> leleobhz: detect presence at runtime, and have a backup mechanism that doesn't use sse2.
[02:23] <leleobhz> and about arch?
[02:23] <leleobhz> make it i686?
[02:24] <persia> leleobhz: If you have a backup mechanism, use arch: any.  There is no arch: i686
[02:24] <leleobhz> backup?
[02:24] <YokoZar> persia: hmm that doesn't sound very nice.  Some packages shouldn't be allowed to install if they can't run (ie, no sse2 support)
[02:24] <persia> Better if you make it flexible, as in many cases, one can also implement an altivec solution.
[02:24] <leleobhz> hmmm
[02:24] <YokoZar> Like we should have a sse2 virtual package that we can depend on which refuses to install on older processors
[02:25] <persia> YokoZar: Why?  Let's look at mplayer: it has all sorts of routines that are improved by vector processing.  It detects what capabilities are available at runtime, and selects the best implementation of the routine for the processor on which it runs.
[02:25] <persia> Doing it another way is a bug, as it makes porting exceedingly difficult.
[02:26] <YokoZar> persia: I was more thinking of something like a game that had an -sse2 or greater processor as a minimum requirement
[02:27] <persia> YokoZar: Such a requirement is a bug.  If you don't consider it that way, you make the game i386 only, which isn't interesting for many users.
[02:27] <persia> It's not that hard to detect capabilities at runtime and use different backends.  Users without hardware optimisation will find it slow, and likely not play.
[02:27] <persia> That's much better than a crash.
[02:28]  * persia has spent time digging through MMX implementations to port to amd64, and doesn't want to see more.
[02:28] <YokoZar> True, but maybe upstream didn't write it that way.  There's no point talking about it without a specific package in question though
[02:28] <persia> YokoZar: Then it's an upstream bug.
[02:29] <persia> YokoZar: I've encountered several packages that make the assumption that there is something present (MMX, SSE, altivec, etc.)  In every case I found, there were issues with porting to architectures other than the single one used upstream.
[02:30] <persia> In the majority of those cases, a few hours was sufficient to find a way around the bug, and let it run.
[02:30] <persia> Given that processor speed tends to increase fairly rapidly, that which benefits from hand-optimised assembly today may well run fine next year.
[02:35] <leleobhz> persia: the problem is when the code is really optimized
[02:35] <leleobhz> e.g. built for sse2
[02:36] <persia> leleobhz: Understood.  In what language is the code written?
[02:36] <leleobhz> C and C++
[02:36] <leleobhz> but im not sure about optimizations
[02:36] <leleobhz> im trying to find
[02:42] <persia> leleobhz: Digging a bit, it looks like you'll get hit by http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16584 in the simple case.  I find a reference to the GCC maintainers saying not to use -msse2 except if you have runtime detection, and to only call that for a specific file (and not the one doing the runtime detection), but I can't find the relevant part of http://gcc.gnu.org/onlinedocs/gcc/
[02:44] <leleobhz> arhg... what guys of handbrake uses to program?? gnu/hurd???
[02:44] <leleobhz> [12/06-22:43:16] <@jbrjake> i've been using linux since 1996 and i have yet to be convinced that the concept of the packaging system does more good than harm.
[02:44] <leleobhz> [12/06-22:43:51] <@jbrjake> to me it demonstrates an ongoing atrophying of the linux user
[02:45] <leleobhz> pkill -SIGAAAAARRRGGGHHHHH handbrake
[02:45] <leleobhz> (sorry by the flood)
[02:45] <ajmitch> because *real* linux users should compile everything from source!
[02:46] <persia> No, *real* linux users write everything from source
[02:46] <leleobhz> [12/06-22:46:31] < persia> No, *real* linux users write everything from source
[02:46] <ajmitch> oh right
[02:46] <leleobhz> agreed
[02:47]  * persia takes off the gentoo-bashing gloves
[02:47] <leleobhz> but like someone said on a magazine, i prefer a linux-dumb doctor for cut me instead a kernel-devel doctor ;]
[02:47] <persia> leleobhz: Why?  How does it matter, as long as they are a good surgeon?
[02:48] <leleobhz> persia: a good surgeon studies medicine... not package compilation
[02:48] <leleobhz> persia: its a extremism, but is to say, im dont must to know how to compile a software
[02:48] <leleobhz> (talking as a user)
[02:49] <persia> Maybe.  I'd prefer someone who read at least a little outside their field: wide interests tend to correlate with intelligence which tends to correlate with competance.
[02:50] <jml> Citation needed.
[02:52] <persia> jml: "Personality, Self-Concept, Interests, and Intelligence: Which Construct Doesn't Fit?", Phillip L. Ackerman, Journal of Personality, Volume 65 Issue 2, June 1997 for the first
[02:53] <YokoZar> Truthfully, the best system wouldn't have a packaging system at all, since every piece of software would run miraculously without installation
[02:54] <persia> jml: And I have to defer to you on the second: I can find no study indicating that intelligence correlates with competance.
[02:55] <persia> (such is complicated by the lack of a well-regarded definition of either "intelligence" or "competance")
[02:55] <jml> persia: I'd imagine that such a thing would be an exercise in definition.
[02:55] <persia> jml: Quite likely.
[02:55] <jml> speaking of definitions, if you looked it up in a dictionary, it would be spelled "competence" ;)
[02:56] <persia> See: this demonstrates my incompetence) and likely impacts my ability to search :)
[02:59] <persia> With improved spelling, I can cite "Beyond IQ", Tomas Chamorro-Premuzic, 2007
[03:11] <neurobuntu> anyone here familiar with buildbot?
[03:12] <lifeless> some
[03:14] <neurobuntu> lifeless would you recommend it for nightly builds, or should I just stick to shell scripts and cron?
[03:15] <lifeless> its got a bit of a setup burden, but much nicer than shell and cron
[03:15] <lifeless> I'd do it
[03:15] <neurobuntu> ok thanks....  even for building debs nightly?
[03:16] <lifeless> well
[03:16] <lifeless> why are you not sending them to a ppa?
[03:17] <neurobuntu-away> lifeless, ppa?
[03:18] <neurobuntu-away> lifeless, we're going to be hosting internally
[03:42] <mneptok> persia: i have a degree in medieval studies, advanced computer skills, and am a very good cook. but no one that knows me would claim my variegated interests denote intelligence and/or competence. :)
[03:47] <swegner> So, I was just reading over the packaging "Getting Started" guide, and I am overwhelmed.
[03:49] <lifeless> neurobuntu: oh :P well sure bb would work, it is agnostic to the task
[03:51] <neurobuntu> lifeless, thanks
[03:51] <swegner> I know that Ubuntu is always looking to get more people involved through packaging as MOTU's, but it seems like such a steep learning curve.  What about some sort of "apprenticeship" to get people started?
[03:52] <crimsun> swegner: see mentorship
[03:52] <persia> mneptok: I said "tend to",  There are always exceptions.
[03:52] <swegner> crimsun: there's a mentorship program already?
[03:53] <crimsun> swegner: has been.  See https://wiki.ubuntu.com/MOTU/Mentoring
[03:53] <ScottK> TheMuso: The ping was about the discussion that immediately preceeded it about Universe SRU policy.
[03:53] <mneptok> persia: i love that you consider me "special" :)
[03:53] <mneptok> *eyebat*
[03:53] <swegner> crimsun: great, thanks, I'm going to read a little bit  :)
[03:53] <crimsun> swegner: (that link is available from one in this channel's topic.  https://wiki.ubuntu.com/MOTU/Contributing)
[03:53] <TheMuso> ScottK: Oh.
[03:54] <ScottK> TheMuso: It's stuff we need to talk about at our meeting next week.
[03:54] <TheMuso> ScottK: Right. I'll have a good look before then.
[04:51] <SpookyET> hi
[04:51] <SpookyET> Does anyone use bzr-builddeb?
[04:51] <lifeless> yes, it has users
[04:52] <SpookyET> how do you use dpatch with it. You have to combine, make the patch, and have it copy the changes from build-area back to the project
[04:53] <RAOF> SpookyET: Yup, pretty much.
[04:53]  * RAOF looks forward to source package version 3.0 (bzr)
[04:53] <SpookyET> RAOF: but, do you have to do that manually?
[04:55] <RAOF> SpookyET: I export a source package, do my dpatching, and then copy the patches back into bzr, yes.
[04:55] <RAOF> I think svn-buildpackage has an option to evecute commands in an exported source package, which would be nice for this.
[04:58] <SpookyET> i was think like dpatch-edit. drop me into a shell. track changes to /debian. copy back on exit
[05:00] <RAOF> Yup.  I think you can do that with svn-buildpackage.  I don't think it's implemented for bzr-builddeb.  It's also a bit sub-optimal to use a VCS to store patches, IMO, so the new source package formats will help there.
[05:00] <SpookyET> i don't like centralised. i can't stand git because it's very complicated. I've been using mercurial. It's simple and easy to use, but no launchpad
[05:01] <RAOF> You should love bzr then.
[05:02] <RAOF> bzr-svn is pretty awesome, too, but you probably can't use it to interact with svn-buildpackage ;)
[05:02] <lifeless> RAOF: you are doing it the hard way I think
[05:02] <lifeless> RAOF: can you not just bzr-builddeb --uncommitted?
[05:02] <nxvl> jcastro: i have just fill the UDS survey and left a comment for you :P
[05:03] <RAOF> lifeless: I was imagining a tree-less (aka merge-mode) bzr usage, where the files you want to edit *don't exist*.  If I'm wrong, then just editing in place should be good.
[05:04] <lifeless> RAOF: have you used bzr-buildden :P
[05:04] <RAOF> lifeless: Yes.  In merge-mode, in fact :)
[05:04] <SpookyET> den? or deb?
[05:04] <lifeless> deb
[05:04] <SpookyET> merge-mode is what i want
[05:04] <SpookyET> upload to launchpad +junk
[05:04] <lifeless> merge-mode is when your vcs tree is the debian/ subdir only
[05:05] <RAOF> Yes.
[05:05] <lifeless> I think thats a bad model, so don't use it
[05:05] <lifeless> (it detaches changes to the source tree from the source tree)
[05:05] <RAOF> I don't think it was too bad, but once everything accepts source-version 3, it'll be hopeless.
[05:06] <lifeless> I still don't see what source-version 3 actually improves.
[05:06] <lifeless> but perhaps I'm just missing the point
[05:06] <RAOF> You get the whole bzr tree as your source package?
[05:06] <RAOF> So 'apt-get source' gets exactly what you need to actually work on the package.
[05:06] <ScottK> It's got quilt so its' got to be better.
[05:07] <lifeless> ScottK: :)
[05:07] <lifeless> RAOF: debget or whatever does that now
[05:08] <RAOF> Hey, that's kinda cool.
[05:08] <ScottK> RAOF: That's true for some definition of the word 'need'.
[05:09] <RAOF> Does it work for Ubuntu?  It seems like it's going to be getting its information from packages.debian.org
[05:09] <ScottK> Personally, I do fine with *-edit-patch.  Quilt seems overly complex and obscure.
[05:09] <ScottK> I'm sure there are packages patched heavily enough to need it, but not so many.
[05:09] <RAOF> I like *-edit-patch, yeah.  I like bzr, too.
[05:11] <lifeless> RAOF: it should be getting it from the VCS-thing header
[05:11] <lifeless> whats more cool, is bzr-search
[05:11] <RAOF> Maybe you're looking at a different debget description, because the description I'm looking at says it doesn't use the local Packages file at all.
[05:12] <lifeless> oh, well bugger files etc
[05:12] <ScottK> I'm sure bzr is wonderful and all that, but until I encounter it outside Ubuntu, it's n+1 VCS to try and learn and my brain is already full.
[05:12] <lifeless> ScottK: hack on any number of projects these days and you'll encounterit
[05:13] <lifeless> ScottK: gnome are considering it, I hear KDE are too, emacs is moving to it, mailman has etc,etc,etc
[05:13] <ScottK> lifeless: I'm sure.  I just haven't hit it yet.
[05:13] <jml> it's also substantially less difficult to learn than, say, CVS.
[05:13] <lifeless> jml: scott does have a fair point
[05:14] <ScottK> Except for that fact that I already know CVS so the learning curve there is pretty minimal.
[05:14] <lifeless> ScottK: I would encourage you to forget svn and learn bzr instead. Space-for-space tradeoff its a win IMO
[05:14] <lifeless> :)
[05:14] <ScottK> Except I have to use svn most every day.  I can't forget it yet.
[05:14] <lifeless> yes, you can through the magic of bzr-svn
[05:14] <lifeless> :)
[05:14] <jml> lifeless: I wasn't suggesting otherwise.
[05:15]  * RAOF <3 bzr-svn
[05:16] <ScottK> lifeless: If I go check out the Debian Python Modules Team svn (with 200 + debian dirs in it) with bzr=svn instead of svn, how much longer is it going to take me to download it and then to update it?
[05:17] <RAOF> Substantially longer for the first branch, not much longer for subsequent updates.
[05:17] <lifeless> ScottK: you can do a checkout using bzr, I understand that like that its roughly comparable
[05:17] <lifeless> RAOF: or ^
[05:17] <RAOF> Oh, yeah.  I always forget that you can checkout ;)
[05:17] <ScottK> OK.  I might try that at some point.
[05:17] <lifeless> ScottK: on a side note thats a good question that many folk will answer. I will at some point get a solid canned response for it
[05:18] <lifeless> s/answer/ask/
[05:18]  * ScottK just recalls nearly dieing of old age the last time he tried to check out a Kubuntu debian dir off LP using bzr.
[05:20] <uniscrip1> quick question. Should dependencies only needed for make check to be listed as build dependencies in debian/control?
[05:20] <persia> uniscrip1: If you are running make check at build-time, yes.
[05:21] <uniscrip1> ah, yes, good answer. thanks
[05:39] <SpookyET> I wonder why mercurial is not very popular
[05:39] <SpookyET> git and bzr are
[05:39] <RAOF> Aren't mozilla using mercurial?
[05:40] <RAOF> Git has the advantage of a hugly high-profile development team and posterchild use-case.  Bzr has the advantage of being the best thing since sliced bread.
[05:41] <SpookyET> mercurial is good
[05:41] <SpookyET> git's interface sucks
[05:41] <persia> Hg is used in a number of places, and supports most workflows for any of svn, bzr, or git relatively cleanly.
[05:41] <pwnguin> wow, debian eclipse carries a ton of patches
[05:41] <RAOF> SpookyET: Preaching to the choir, man.
[05:42] <SpookyET> one thing i have not see in any of these is the ability to commit huge files
[05:42] <lifeless> persia: if by 'most workflows' you mean 2
[05:42] <SpookyET> the only one i know is Adobe VersionCue, which can handle big photoshop files
[05:43] <persia> lifeless: ?
[05:43] <lifeless> SpookyET: we know _how_ to in bzr, just need someone to do it and find where the exceptions are raised
[05:43] <lifeless> SpookyET: its basically 'put in a stream code path adjacent to the fast-all-bytes code paths'
[05:44] <lifeless> persia: hg does not support _most_ workflows of svn, bzr or git. most of git yes, but not svn or bzr
[05:44] <SpookyET> lifeless: diff is still a problem
[05:45] <SpookyET> if only diff had plugins for different kinds of binary files
[05:45] <lifeless> SpookyET: yes, though its possible to write a tape-diff, I don't think anyone has
[05:45] <lifeless> our diff has plugins
[05:45] <persia> lifeless: Oh.  I only know a couple svn workflows, for which Hg worked.  I admit that I've not found any bzr workflows that work for me.
[05:46] <persia> (not a criticism of bzr, so much as an indication of how much time I've spent with it)
[05:46] <lifeless> persia: you found a centralised workflow for hg
[05:46] <lifeless> ?
[05:48] <persia> lifeless: No.  My experience with Hg is similar in volume to that with bzr.  In the Hg case, I was able to use svn or git workflows (depending on the project documentation).  With bzr, I generally have to try several times to get a branch that looks right (with associated multiple branching over the network)
[05:49] <StevenK> persia: Geh? bzr branch <> doesn't Just Work? It does for me.
[05:49] <lifeless> persia: well, svn workflows _are centralised_ - not finding a centralised workflow means you were not using hg as you would svn :)
[05:49] <persia> StevenK: That works fine to get the code.  It's getting a patch in and marked correctly that frustrates me.
[05:49] <lifeless> persia: 'commit' ?
[05:49] <StevenK> persia: bzr commit -m "" && bzr push ?
[05:49] <wgrant> bzr bind!
[05:50] <persia> lifeless: That's what the documentation says.
[05:50] <lifeless> persia: I would love it if you could pop into #bzr some point and spend some time showing us what is confusing
[05:50] <persia> StevenK: Given what tends to be missing when I bzr commit, I don't think && is the right operator there.
[05:50] <persia> lifeless: If you really want.  I suspect it's just that I've not read enough documentation.
[05:50] <lifeless> persia: that implies not enough guidance in the ui/'bzr help X'
[05:51] <lifeless> persia: requiring reading of documentation *is a bug* imo
[05:51] <persia> lifeless: OK.  I'll come by some day then.  Lessons are always appreciated (but bzr help is likely to also be helpful)
[05:51] <StevenK> persia: What is missing when you bzr commit?
[05:52] <persia> StevenK: Sometimes new files.  Sometimes the history doesn't look right.  Sometimes bzr diff doesn't generate what I expect.
[05:53] <wgrant> You need to bzr add new files.
[05:53]  * persia is a reluctant VCS user, which is likely part of the problem.
[05:53] <StevenK> I've found I can treat a bound bzr branch like svn, and it works. An unbound branch is also like svn, except that update is pull, and commit is commit and push
[05:53] <persia> wgrant: Yes.
[05:53] <wgrant> StevenK: Indeed, it's rather like SVN for centralised stuff like that.
[05:54] <persia> wgrant: Sometimes it's knowing which files I want.
[05:54] <wgrant> Almost identical.
[05:54] <wgrant> persia: bzr status should give you a good indication.
[05:54] <StevenK> wgrant: Which is good, because it means less changes to remember
[05:54] <persia> StevenK: Yes, bound branches are almost identical to SVN, although they seem to be confused if you don't update them for a while.
[05:55] <wgrant> Confused?
[05:55] <persia> wgrant: Yep.  bzr status is one of the things I tend to run between commit and push.
[05:55] <wgrant> That sounds more like git with its regularly history modification.
[05:55] <StevenK> I have the seeds checked out as bound, and it hasn't gotten confused.
[05:55] <persia> wgrant: Well, at least in some cases I've found it easier to delete a local branch and re-checkout rather than updating the local branch when there were foreign updates.
[05:55] <StevenK> persia: Between commit and push is too late, run bzr status before commit
[05:55] <wgrant> persia: Wow. I've never had to do that.
[05:56]  * persia again suspects these aren't issues with bzr
[05:56] <wgrant> persia: status shows you what will be committed when you run commit.
[05:56] <wgrant> The diff will also empty once you run commit.
[05:56] <wgrant> As there are no uncommitted changes.
[05:56] <StevenK> Since diff and commit operate on the local branch
[05:57] <StevenK> (If it's unbound)
[05:57] <persia> Right.  Nevermind.  I'll go read some documentation, and maybe visit #bzr for a lesson later, when I've a set of my issues in front of me, rather than the nice clean results of dpkg-source
[05:58] <wgrant> I found bzr very, very easy to use when I first tried it, though I had been using svn for years prior.
[05:58] <wgrant> The migration was most painless.
[05:58] <StevenK> Agreed, same for me.
[05:58] <StevenK> I'd been forced by $WORK to use and admin cvs, which I found a *horrible* pain
[05:59] <jml> wgrant: I found it took a while to unlearn misconceptions about branching that I learned from SVN.
[05:59] <StevenK> jml: Only because svn's merging is ... interesting
[05:59] <jml> wgrant: not that long once I started actually _using_ Bazaar, I'll grant you.
[05:59] <jml> StevenK: yeah.
[06:00] <RAOF> StevenK: Again.  Svn _has_ merging? :)
[06:00] <StevenK> Haha
[06:00] <StevenK> RAOF: Commonly done in wetware
[06:00] <jml> StevenK: Twisted does branch-based development with Subversion. We have special tools & processes to work around Subversion.
[06:00] <RAOF> Right.  svn spend-a-day.
[06:22] <SpookyET> can you push an entire repo with bzr onto launchpad?
[06:23] <RAOF> You mean a bunch of branches?
[06:23] <SpookyET> my ppa
[06:27] <leleobhz> 3'clock and ive thinked in use for i in `find ~ -iname "*sources.changes*"`; do dput ppa $i; one
[06:27]  * leleobhz needs a bed
[06:32] <dholbach> good morning
[06:32] <lifeless> garh
[06:32] <lifeless> choose two channels. ONLY
[06:34] <leleobhz> my makefile have no install target
[06:34] <leleobhz> how can i override make install?
[06:35] <SpookyET> So, is it possible to upload my local bzr repository of my PPA to launchpad?
[06:36] <lifeless> SpookyET: ppa's want source packages, bzr build-deb can make a source package from your bzr tree for you
[06:36] <lifeless> SpookyET: you can up load the bzr tree to bazaar.launchpad.net too, of course
[06:36] <SpookyET> yeah, i want to upload the tree
[06:37] <SpookyET> bzr push gives me an error
[06:39] <lifeless> SpookyET: if you paste the error somewhere, people can help
[06:39] <SpookyET> it says that my repo is not a branch
[06:39] <lifeless> !paste
[06:40] <lifeless> copy and paste it to that website
[06:40] <lifeless> show us the url
[06:40] <geser> good morning
[06:40] <SpookyET> lifeless: http://paste2.org/p/38702
[06:42] <lifeless> SpookyET: you haven't created a bzr branch yet.
[06:42] <lifeless> where is the MOTU documentation for this ? RAOF ? Anyone?
[06:43] <lifeless> SpookyET: uhm, what bzr commands *have* you run ?
[06:43] <SpookyET> lifeless: repo-init and everything in the subdirs except tarballs and build-area is bzr init
[06:44] <lifeless> then you can push each individual subdir
[06:44] <lifeless> 'repository' is _just_ a storage area, it has no semantic value
[06:44] <persia> lifeless: There isn't any MOTU documentation on managing packages with bzr.  For the majority of packages in universe, it's not worth the bother of setting up a repo when the package will never be touched again (we'll sync with Debian next time).
[06:44] <lifeless> *everything* is in terms of branches or trees
[06:45] <SpookyET> lifeless: there is a .bzr dir there
[06:45] <lifeless> SpookyET: that has nothing to do with what I said
[06:45] <lifeless> SpookyET: that just means there is a .bzr dir
[06:46] <lifeless> persia: https://wiki.ubuntu.com/BzrMaintainerHowto?highlight=(bzr)
[06:48] <persia> lifeless: Ah, cool.  That wasn't there last time I read the wiki.
[06:48] <lifeless> persia: heh, it is a year or so old I think
[06:49] <persia> lifeless: Right.  I read the entire wiki from mid April to late May last year, based on the pagelist as of early April.  I don't know when I'll next have six weeks to repeat that.
[06:50] <lifeless> MEEP
[06:50] <lifeless> there are > 32K pages
[06:50] <persia> There were only about 25K pages then.
[06:50] <lifeless> 'only'
[06:50] <persia> Lots of them are only a couple lines long, or redirectls, which makes it easier.
[06:51] <SpookyET> i'm trying to push. it ain't working
[06:51] <lifeless> whats your latency to London?
[06:51] <lifeless> SpookyET: again, show the error
[06:51] <SpookyET> ll
[06:51] <lifeless> SpookyET: 'it does not work' is useless as feedback
[06:52] <SpookyET> lifeless: http://paste2.org/p/38704
[06:53] <lifeless> SpookyET: each needs its own valud url - in launchpad branches are at USER/PRODUCT/BRANCHNAME
[06:53] <lifeless> you are trying to put them at USER?PRODUCT/ppa/BRANCHNAME
[06:53] <lifeless> this will fail
[06:53] <SpookyET> +junk
[06:53] <lifeless> yes thats your PRODUCT field
[06:54] <lifeless> you have one path element too many
[06:54] <SpookyET> lifeless: i thought i could upload my local repo to /ppa
[06:55] <lifeless> again, bzr is focused on _branches_
[06:55] <lifeless> you can upload one branch to bazaar.launchpad.net/~spookyet/+junk/ppa
[06:55] <lifeless> another to bazaar.launchpad.net/~spookyet/+junk/differentname
[06:55] <lifeless> etc
[06:56] <RAOF> Ah, C++. your compile errors fill me with joy: http://pastebin.ubuntu.com/19806/
[06:57] <SpookyET> can you delete a branch from launchpad if you uploaded crap?
[06:58] <StevenK> SpookyET: Are you trying to use bzr to upload to your ppa?
[06:59] <SpookyET> StevenK: no. I'm just trying to use bzr and bzr-buildpackage to keep track of /debian
[06:59] <SpookyET> http://babelfish.yahoo.com/translate_url?tt=url&trurl=http%3A%2F%2Fwiki.debianperu.org%2Fdoku.php%3Fid%3Dtutoriales%3Abzr-builddeb&lp=es_en&.intl=us&fr=moz2
[07:00] <SpookyET> I also want to upload the stuff to launchpad
[07:01] <SpookyET> https://wiki.ubuntu.com/BzrBuildpackage
[07:06] <lifeless> SpookyET: yes you can delete  a branch (as long it is not referenced from bugs etc)
[07:07] <SpookyET> yeah i noticed.
[07:35] <\sh> moins
[07:36] <Hobbsee_> hey \sh
[07:36] <elmargol> I tried to get a shell after pbuilder fails :/ and somehow it does not work :/ it says no E scripts found :(
[07:36] <Hobbsee_> elmargol: that's not an error, is it?
[07:37] <elmargol> Thats not copy and paste yes
[07:39] <Hobbsee_> it should still have dropped you into a shell anyway...
[07:42] <Hobbsee_> (are you sure it didn't?)
[07:42] <elmargol> yes
[07:46] <elmargol> W: no hooks of type E found -- ignoring
[07:49] <\sh> woohsaa...bug #239140 confirmed/wishlisted...rocking
[07:50] <\sh> let's see when it'll be implemented
[08:36] <DktrKranz2> Bug 133393 ships a NEW source package (fuzzyocr3 against fuzzyocr in the archives), shouldn't we manage it in REVU instead?
[08:39] <persia> DktrKranz2: Depends on how we want to manage the transition.
[08:40] <persia> If we can NBS it quickly, better to use fuzzyocr as the source package, and ship a fuzzyocr3 binary.  If we can't, then maybe parallel packages make sense (I'm personally opposed to parallel packages).
[08:43] <DktrKranz2> persia: debian maintainer chose parallel packages approach.
[08:44] <DktrKranz2> should we diverge from debian this way? we won't be able to come back easily
[08:45] <persia> DktrKranz2: We should follow Debian whereever possible for transitions.
[08:45] <persia> If we don't follow Debian, we'll have to transition twice, once to vary, and once to get back (even if it ends up being the same code with a different name, it's still a transition).
[08:49] <DktrKranz2> Probably old package will be removed once new upstream will be pushed to unstable, we should do the same.
[08:50] <DktrKranz2> I'm not comfortable to push a NEW package without a second review, though
[08:50] <persia> Well, we oughtn't remove the old package until the transition is complete, but otherwise, yes.
[08:50] <persia> Isn't it just a sync from experimental?  the DD and you make two reviewers.
[08:51] <DktrKranz2> Indeed, I can ask reporter to request a sync from experimental
[08:52] <DktrKranz2> (and to adjust bug report accordingly)
[08:52] <persia> DktrKranz2: Better to just retitle/test yourself, and push to the archive admins, rather than bouncing back off the reporter (unless you disagree).
[08:54] <DktrKranz2> persia: sounds good. I need to review package a bit because I'm not familiar with it and to see if has conflicts with current version in Intrepid. I'll assign it to me.
[08:55] <persia> DktrKranz2: I usually just take those things as sync sponsoring requests.  Users who push a lot tend to see the changes, and follow the proper guidelines next time.  Users who only do one go away happy.
[09:05] <huats> morning everyone
[09:41] <sistpoty|work> hi folks
[09:42] <huats> hey sistpoty|work
[09:43] <sistpoty|work> hi huats
[10:06] <james_w> dholbach: nice catch on the sync request FTBFS, should I invalidate the request and wait for Debian to fix the bug, or let it sync and fail, and then let the autosync take care of getting the fixed version?
[10:06] <dholbach> james_w: I suppose it's going to be in incoming in a bit
[10:11] <james_w> dholbach: I'm not sure I understand
[10:12] <dholbach> james_w: you could invalidate it for now and reopen once it's been fixed in incoming
[10:12] <james_w> ah, ok, thanks.
[10:13] <devfil> someone have an amd64 with a virtual machine to test a package?
[10:15] <james_w> dholbach: too slow :-)
[10:43] <RainCT> It I want to get an SRU into Hardy and Gutsy can I just give it version number -0ubuntu2 and -0ubuntu2~gutsy (Intrepid has a newer upstream version)?
[10:47] <DktrKranz2> RainCT: have hardy and gutsy packages the same version number?
[10:49] <DktrKranz2> RainCT: you can use -0ubuntu1.8.04 (for hardy) and -0ubuntu1.7.10 (for gutsy), but can you indicate which package are you looking at, just to be sure?
[10:52] <RainCT> DktrKranz2: Yes, they have the same. The package is youtranslate.
[10:54] <DktrKranz2> RainCT: versioning scheme I gave you is correct. You can use it :)
[10:55] <DktrKranz2>  1.1.9-0ubuntu1.8.04 AndyP 1.1.9-0ubuntu1.7.10
[10:55] <RainCT> OK, thanks :)
[10:55] <DktrKranz2> de nada
[10:56] <gaspa> DktrKranz2: ehy ;), can we publish in some way my nbs page?
[10:56] <DktrKranz2> gaspa: ask some ubuntuwire admins, wgrant maybe
[10:57] <gaspa> l
[10:57] <gaspa> ok
[11:28] <RainCT> DktrKranz2: Uhm.. Do you see it as viable to SRU the package from Intrepid completly into Hardy? :P
[11:30] <RainCT> DktrKranz2: because beside being unusable the package is FTBFS so beside switching to cdbs the changes would be mostly the same
[11:32] <DktrKranz2> RainCT: is it installable in hardy and gutsy?
[11:32] <RainCT> DktrKranz2: installable, yes, but it won't do anything
[11:33] <DktrKranz2> why? broken package?
[11:33] <RainCT> DktrKranz2: it parses the HTML from some webpages, but they all changed since it was released
[11:34] <DktrKranz2> parse data from external websites? (such youtube related softwares?)
[11:36]  * DktrKranz2 moves to lunch now
[11:36] <RainCT> DktrKranz2: yes, it parses Google Translate, Babel Fish and some other sites
[11:36] <DktrKranz2> RainCT: mind discussing about it in a couple of hours?
[11:37] <RainCT> (the service to use can be switched in a config dialog, but any of the available options works anymore :P)
[11:37] <RainCT> DktrKranz2: sure, enjoy your meal :)
[11:37] <DktrKranz2> thanks, C U
[11:56] <gaspa> wgrant: how could that page (http://iogaspa.altervista.org/nbs/reversenbs.xml) linked in ubuntuwire ?
[12:40] <emgent> heya
[12:40] <sebner> hoi emgent
[12:41] <sebner> emgent: thanks for your comment ^^ but I know that the new patch in necessary ;) I had connection problems yesterday. did norsetto say anything after I quit?
[12:41] <emgent> no
[12:42] <elmargol> Can someone give me a hand please? I try for hours to package the new gnunet-gtk release. Somehow I get a mkdir: cannot create directory "/usr/share/icons/hicolor/scalable": Permission denied if I build it inside pbuilder
[12:43] <\sh> elmargol: there is a $DESTDIR missing or the debian/rules is wrong
[12:43] <elmargol> They use this script https://gnunet.org/svn/gnunet-gtk/pixmaps/icons/icon-theme-installer
[12:44] <elmargol> \sh, I think this too... I just can't find the right place :/
[12:45] <\sh> elmargol: check if ${INSTALL_DEST_DIR} is set inside the script...if not this will fail
[12:45] <\sh> elmargol: install_dir=${INSTALL_DEST_DIR}${INSTALL_BASE_DIR}/$size/$category
[12:45] <\sh> $($MKINSTALLDIRS_EXEC $install_dir) || {
[12:45] <\sh> 			echo "Failed to create directory $install_dir"
[12:46] <\sh> you see...when $INSTALL_DEST_DIR != $DESTDIR from make then $install_dir only ${INSTALL_BASE_DIR}/....
[12:46] <\sh> oh what an english
[12:46] <\sh> and what pseudocode ,;)
[12:46]  * sebner winks \sh \o/
[12:53] <elmargol> \sh, sorry I think my english is to bad to understand this :/
[12:53] <elmargol> install_icon_exec=${top_srcdir}/pixmaps/icons/icon-theme-installer -t ${theme} -s ${srcdir} -b ${themedir} -m "${mkinstalldirs}" -x "${INSTALL_DATA}" <- thats the makefile
[12:53] <elmargol> you say I have to add -d?
[12:55] <porthose> is it just my machine or is http://packages.ubuntu.com/hardy/   not working?
[12:58] <jpds> porthose: I think that site is in the process of being moved to a new host.
[12:58] <porthose> aaahhh  K thx :)
[12:59] <\sh> elmargol: yes...with ${DESTDIR} var from make
[13:00] <jpds> porthose: https://lists.ubuntu.com/archives/ubuntu-devel/2008-May/025370.html and later messages
[13:04] <elmargol> \sh, thx it works now
[13:08] <\sh> elmargol: cool :)
[13:09] <elmargol> I do some more cleanup and upload it to my ppa...
[13:20] <porthose> jpds: :'(
[13:30]  * jpds hugs porthose 
[13:30] <jpds> porthose: there there, it's not the end of the world
[13:30]  * laga pulls out his pocket doomsday device
[13:30] <laga> sure?
[13:31] <DktrKranz2> RainCT: back.
[13:34] <jpds> laga: ...yet
[13:51] <leleobhz> have some way to search filenames in package via aptitude?
[13:51] <leleobhz> or apt-cache
[13:51] <leleobhz> packages.ubuntu.com is too slow
[13:51] <laga> use apt-file
[13:51] <Pici> !info apt-file
[13:52] <leleobhz> laga: but it ill search only in installed packages or consult all packages database?
[13:53] <Pici> leleobhz: It will search everything
[13:53] <Pici> make sure you sudo apt-file update before you use it
[13:53] <leleobhz> ok
[13:53] <leleobhz> heh, it clains this to me now
[13:54] <leleobhz> another, have some issue with packages.ubuntu?
[13:55] <RainCT> DktrKranz2: ok. so, what do you think?
[13:56] <DktrKranz2> RainCT: if package is not working anymore, it's definitely SRU-worty, could you isolate a patch for that issue?
[13:58] <jpds> leleobhz: it's down.
[13:58] <leleobhz> jpds: oh...
[13:58] <RainCT> DktrKranz2: that's what I was saying before; additionally of not working anymore, its  FTBFS and needs an additional patch for this in Hardy
[13:59] <jpds> leleobhz: https://lists.ubuntu.com/archives/ubuntu-devel/2008-May/025370.html
[13:59] <RainCT> DktrKranz2: so I'm wondering if it wouldn't be better to just pull the version from Intrepid there as there wouldn't be much difference
[14:00] <leleobhz> jpds: wait a minute. packages.ubuntu arent sponsored by canonical?
[14:01] <cody-somerville> leleobhz, not currently
[14:01] <DktrKranz2> RainCT: if changes introduced are required to have a working package, I guess it's ok, but let's check deltas :)
[14:02] <jpds> leleobhz: read the later messages
[14:02] <leleobhz> reading
[14:02] <RainCT> DktrKranz2: (those additional changes would be mainly the new upstream version -not sure what's new but it isn't much, upstream calls it a -maintenance release'- and the addition of a .desktop file and icons for the menu)
[14:03] <DktrKranz2> I think they don't harm stable releases
[14:04] <RainCT> good :)
[14:05] <DktrKranz2> if the only differences between a SRU debdiff and a backport from intrepid are .desktop files ne icons, I think it's perfectly safe.
[14:06] <jpds> leleobhz, porthose: ok, I can confirm that it's being moved to a canonical machine.
[14:07] <leleobhz> jpds: now?
[14:07] <RainCT> DktrKranz2: great, I'll ping you when I've filed the report
[14:07] <DktrKranz2> RainCT: thanks
[14:07] <jpds> leleobhz: by what I've been told, yes.
[14:07] <leleobhz> jpds: its really good
[14:18] <Ng> leleobhz: packages.ubuntu.com should be back up and running faster now
[14:18] <Ng> (subject to your DNS updating)
[14:18] <leleobhz> Ng: /etc/hosts and dig exists for this ;]
[14:19] <Ng> 91.189.94.219 is the new IP
[14:19] <Laney> Ng: Will it track intrepid properly now?
[14:20] <leleobhz> registering
[14:23] <leleobhz> Ng: wow!
[14:24] <Ng> it'll be faster when yahoo and msn stop crawling it
[14:24] <leleobhz> Ng: its really fast comparing than yesterday
[14:26] <Ng> good good
[14:31] <jpds> Ng: smashing!
[14:31] <leleobhz> Ng: congrats, very fast
[14:36] <lukehasnoname> Is Canonical hosting now?
[14:37] <jpds> lukehasnoname: yeah
[14:38] <lukehasnoname> Running RHEL 5.2?
[14:53] <nhandler> I don't know if anyone here is interested, but I am going to be giving a lesson on merging a package from Debian in ##MergeAndSync in about an hour (15:00 GMT). Anyone who is interested is welcome to attend.
[14:55] <james_w> nhandler: there is #ubuntu-classroom that is usually used for this sort of thing
[14:57] <bddebian> Heya gang
[14:57] <nhandler> james_w, I wasn't sure what I needed to do to be able to hold a lesson in #ubuntu-classroom. That is why I am holding it in a new room.
[14:58] <james_w> nhandler: not a lot, there's very few sessions there, so there is little chance of clashing.
[14:58] <james_w> nhandler: thanks for doing it though.
[14:58] <nhandler> james_w, Ok, I'll keep that in mind for next time.
[15:00] <sistpoty|work> hi bddebian
[15:01] <bddebian> Hi sistpoty|work
[15:01] <geser> Hi bddebian
[15:01] <bddebian> Heya geser
[15:02] <i4x> hugs!!
[15:07] <lukehasnoname> omg why doesn't everyone use aptitude
[15:07] <ScottK> Because sometimes its solution is to want to remove my entire desktop.
[15:08] <sebner> nhandler: asking wouldn't be bad if you do others merges ;) And who uploaded it (streamtuner)? also it's useless to recommend xmms since it's not in the repo anymore
[15:10] <DktrKranz2> sebner: fear to remain mergeless? :)
[15:11] <sebner> ScottK, go and fetch your stick to beat DktrKranz2 :P
[15:11]  * DktrKranz2 hides
[15:12]  * ScottK doesn't have the stick.  That's someone else whom I would not presume to usurp.
[15:12] <jpds> sebner: nein, du denkst Hobbsee
[15:12] <sebner> jpds: right
[15:12] <sebner> ScottK: then fetch your authority thing ^^
[15:12] <nhandler> sebner, I'll try to ask from now on. I am not sure who uploaded streamtuner. They didn't leave a comment, and they never assigned the bug to them. And I was not aware that xmms wasn't in the repo. It is also only a suggests in the package
[15:13] <DktrKranz2> sebner: "Silence, I kill you!" (cit. Achmed) :)
[15:13] <ScottK> nhandler: It's not a hard and fast rule that you are required to ask, but it's generally considered polite and it's often useful.
[15:13] <sebner> nhandler: no it's recommends but np
[15:13] <sebner> ScottK: \o/
[15:14] <sebner> DktrKranz2: hehe
[15:14] <Hobbsee>  -- Stefan Ebner <hellboy195@gmail.com>  Thu, 20 Mar 2008 11:34:19 +0100
[15:14] <Hobbsee> apparently
[15:14] <sebner> Hobbsee: That's me =)
[15:14] <Hobbsee> ah
[15:15] <sebner> DktrKranz2: did you upload it?
[15:15] <Hobbsee> sebner: check the signature on the changes file.
[15:15] <sebner> Hobbsee with the stick is now here \o/
[15:16] <nhandler> ScottK, I originally tried asking everyone before doing a merge. The issue was, the majority of them never replied to the emails I sent. Maybe I'll try IRC next time.
[15:16] <ScottK> nhandler: Or you can ask here if someone is still active.  Generally someone will know.
[15:17] <nhandler> ScottK, I'll keep that in mind
[15:17] <sebner> maybe magic Hobbsee can tell me where I can find that xD
[15:17] <lukehasnoname> Any links or details on the downside of Aptitude?
[15:17] <DktrKranz2> sebner: which one? streamtuner?
[15:17] <Hobbsee> it was uploaded by they who had the key of ID 0EADC245
[15:17] <sebner> DktrKranz2: yep
[15:18] <DktrKranz2> dunno
[15:18] <Hobbsee> which, unfortuantely, is now revoked.
[15:18] <sebner> Hobbsee: It seems they fear my revenge ^^
[15:18] <sebner> ScottK: anything new about our friend courier?
[15:18] <Hobbsee> sebner: it was a DSA key.
[15:18] <sebner> Hobbsee: that means?
[15:18]  * sistpoty|work has a cache, and it says RainCT
[15:19] <Hobbsee> sebner: you've forgotten so soon?
[15:19] <jpds> sebner: https://edge.launchpad.net/ubuntu/intrepid/+source/streamtuner/0.99.99-13ubuntu1
[15:19] <ScottK> lukehasnoname: No, but generally I find it more satisfying to let apt do it's best and then work out the rest myself.  Aptitude will try very hard to get you to 'a' solution, but not necessarily the one I would pick.
[15:19] <ScottK> sebner: Not forgotten, but not gotten to.
[15:19] <Hobbsee> sistpoty|work: ah, thankyou, i didn't have a cache, and i can't seem to find a way to search expired keys
[15:19] <sebner> ScottK: k ^^
[15:19] <ScottK> sebner: I did 2 SRUs yesterday.  I have hopes for courier tonight.
[15:19] <sebner> jpds: ah ^^
[15:19] <sistpoty|work> Hobbsee: actually I just tried gpg --list-keys (w.o. a recv-key and w.o. having used gpg on this box for some time)
[15:19] <sebner> Hobbsee: hm?
[15:20] <Hobbsee> sebner: clearly, you've forgotten the debian ssh key stuff.  it's likely that all dsa keys got regenerated as a precaution, whether gpg or ssh.
[15:20] <sebner> Hobbsee: ah. I'm not much in that stuff
[15:21] <jpds> Hobbsee: gpg doesn't use libssl, thus not affected
[15:21] <Hobbsee> sistpoty|work: oh, interesting, recv-keys will still work.
[15:22] <Hobbsee> jpds: you underestimate paranoia, particularly when the message goes out that *all* dsa keys are compromised.
[15:22] <geser> Hobbsee: where did you find that 0x0EADC245 got revoked?
[15:22] <jpds> Hobbsee: well.. I use RSA for signing.
[15:23] <sebner> Hobbsee: by the way. I have 3 syncs and they couldn't be synced because the orig.tar.gz tarballs. I was never in this situation before so ... what to do?
[15:23] <geser> sebner: fake-sync
[15:23] <DktrKranz2> sebner: fakesync \o/
[15:23] <sebner> xD
[15:24] <Hobbsee> geser: i guessed, as the keyserver said it couldn't find it.
[15:24] <Festor> I have a question about PPA
[15:24] <Festor> 	
[15:24] <Festor> Can I use the same orig.tar for several packages of the same program in different versions of Ubuntu?
[15:24] <geser> Hobbsee: keyserver never delete keys, not even revoked ones
[15:24] <sebner> DktrKranz2: I think I just did one with your help but can't remember ^^
[15:25]  * DktrKranz2 too
[15:25] <geser> sebner: take the Ubuntu .orig.tar.gz, apply the Debian diff.gz, add a changelog entry for the fakesync, testbuild, upload :)
[15:25] <ScottK> Festor: PPA questions are best asked in #launchpad
[15:26] <sebner> geser: thanks for this highspeed tutorial ^^
[15:29] <Hobbsee> geser: can't they stop you from getting th ekeys?
[15:32]  * sebner likes gedit. It segfault exactly on every second start ^^
[15:33] <sebner> geser: but is it then again -1ubuntu1?
[15:34] <DktrKranz2> sebner: -Xbuild1 for fakesyncs
[15:34] <jpds> sebner: vim ftw
[15:34] <sebner> DktrKranz2: thanks
[15:34] <sebner> jpds: hehe
[15:36] <SpookyET> hi
[15:36] <SpookyET> I have a little problem. nothing is put in /debian/foo/usr/bin, but I see the stuff inn /debian/tmp/usr/bin
[15:37] <sebner> DktrKranz2: and then I upload the .diff.gz?
[15:38] <sebner> DktrKranz2: no wait, what should I upload then? ^^
[15:41] <DktrKranz2> sebner: a debdiff against current ubuntu version and your candidate revision
[15:41] <sebner> DktrKranz2: *nice*
[15:42] <leleobhz> have someway to override cdbs install command?
[15:42] <leleobhz> ive used install/handbrake::
[15:43] <leleobhz> but it still trying to run make install
[15:43] <ScottK> Switching to debhelper would be one way.
[15:45] <leleobhz> ScottK: but has no override for this?
[15:46] <ScottK> leleobhz: I'm sure there is.  I just don't know what it is.
[15:46] <ScottK> I find that for standard cases where CDBS just does the right thing, it's pretty decent.
[15:47] <ScottK> Once you start needing to figure a bunch of over-rides and changes, debhelper is more transparent and easier to understand.
[15:47] <ScottK> The black magic is good when it's working, but when it doesn't then it's really hard to follow.
[15:47] <sebner> DktrKranz2: if the change of the maintainer also necessary?
[15:47] <DktrKranz2> ni
[15:47] <DktrKranz2> *no
[15:47] <sebner> ah just saw some fakesyncs with that change
[15:48] <DktrKranz2> if you use buildX, it's not required
[15:48] <ScottK> sebner: Once you make a real change like the maintainer change, it's not a fakesync anymore.  It's a merge.
[15:49] <sebner> ScottK: kk
[15:50] <sebner> DktrKranz2: would you like to look at my debdiff?
[15:51] <DktrKranz2> sebner: if you have half an hour... I have to finish other stuffs before :(
[15:51] <sebner> DktrKranz2: np. it doesn't hurry
[15:54] <freeflying> persia: will you merge fbreader?
[15:54] <DktrKranz2> sebner: if you want to look at something *complex* crystalspace is something you can look at :D
[15:55] <sebner> DktrKranz2: why?
[15:55] <DktrKranz2> it seems FUBAR, right now
[15:55] <sebner> lol
[15:55] <DktrKranz2> it should me remerged, but needs much love
[15:56] <DktrKranz2> and it's a huuuuge one
[15:56] <sebner> DktrKranz2: I haven't got the time. I should learn for school instead of doing fakesyncs xD
[15:56] <geser> Hobbsee: no, as you might want the revoked key to verify an old signature generated before the key got revoked
[15:57] <DktrKranz2> sebner: "go scool and do your homework now" (cit. Achmed)
[15:57] <geser> Hobbsee: and you might want to fetch the revoked key so you local copy gets update (also marked as revoked)
[15:57] <Hobbsee> geser: verify won't do that?
[15:57] <Hobbsee> right, yeah
[15:57] <sebner> DktrKranz2: yeah, maybe later ^^
[15:58]  * ScottK made a key while at UDS, added it to LP, used it, and then removed and revoked it before returning due to silly customs rules in his country.
[15:59] <DktrKranz2> ScottK: again with crypto stuff?
[15:59] <DktrKranz2> wasn't over?
[16:00] <ScottK> Just that US Customs claims a right to, without showing any cause, make a copy of any electronic media crossing the border.
[16:00] <geser> ScottK: the US customs check for gpg keys?
[16:00] <ScottK> They may take a copy of your whole hard drive.
[16:01] <DktrKranz2> and I guess Customs aren't entitled to have GPG private keys in their database :/
[16:01] <geser> that would be a reason to create a cryptfs
[16:01] <SpookyET> can anyone help ?
[16:01] <geser> or do you have to deliver also the password to decrypt it?
[16:01] <sebner> geser: btw, we need to patch evolution-sharp to build with the new evolution (unstable) stuff
[16:02] <ScottK> geser: Even if I had a cryptfs, I don't think I would assume they couldn't break it if they cared to and would revoke the key anyway.
[16:02] <ScottK> So it's easier just not to carry it.
[16:03] <geser> true
[16:03]  * geser wonders how the US custom will copy my OpenPGP card
[16:04] <geser> sebner: http://ftp.gnome.org/pub/GNOME/sources/evolution-sharp/0.17/evolution-sharp-0.17.3.news
[16:04] <sebner> geser: xD
[16:04] <sebner> geser: I'm just not up to date
[16:05] <geser> sebner: me neither, but I remember it from last time when I looked at the package
[16:06] <sebner> geser: cool, so just waiting for debian, waiting for the sync and then BAMMMMM! working =)
[16:48] <\sh> the next UDS will be in the US?
[16:49] <ScottK> That would seem to be the normal cycle.
[16:49] <pwnguin> hurray
[16:49]  * ScottK notes that is not a promise.
[16:50] <\sh> ScottK: let's wish for canada
[16:50] <pwnguin> yes, lets pick something inconienent for everyone
[16:51] <laga> well, US travel regulations are ridiculous
[16:51] <pwnguin> true
[16:51] <\sh> pwnguin: hmm? canada is more a free country regarding european guests...
[16:52] <\sh> and not only for europeans...I wonder how arabs are being dealt with in the US
[16:52] <laga> heh. "so, you develop free software? damn communist terrorists"
[16:52] <\sh> anyways...time to commit my changes...and leave for home...cu later
[16:52] <pwnguin> hah
[16:53] <pwnguin> free software is the new capitalism
[16:54] <pwnguin> gpl is a trade in kind. bsd is charity ;)
[16:56] <achadwick> Yebbut with the commons as the beneficiary in both cases :)
[16:56] <ScottK> Not necessarily with bsd.
[16:57] <ScottK> It depends on what your goal is.
[17:11] <DRebellion> Could someone spare a moment to take a look at my package in REVU? http://revu.tauware.de/details.py?package=monkeystudio ? Thanks :)
[17:16] <Lutin> does the 'install recommends by default' apply to buildds too ?
[17:18] <james_w> Lutin: no
[17:22] <Lutin> james_w: thanks
[17:27] <Kopfgeldjaeger> Couldn't the package "db4.6" be synced to Inrepid? The Ubuntu package (atm db4.4) does not have Ubuntu changes in Intrepid.
[17:31] <james_w> Kopfgeldjaeger: https://bugs.edge.launchpad.net/ubuntu/+source/db/+bug/239801
[17:31] <james_w> is that what you wanted/
[17:32] <Kopfgeldjaeger> that's why asked here. i saw the bug report
[17:33] <ScottK> Kopfgeldjaeger: We have several db packages, so mixing 4.4 and 4.6 doesn't make sense.
[17:34]  * sistpoty|work heads home... cya
[17:34] <Kopfgeldjaeger> yes, but that is no problem with syncing db4.6 i guess? i mean, i didnt want to merge it into db4.4 ;)
[17:35] <ScottK> db4.6 will go in Main, so it's really not a worry of ours, but there is no problem with it.
[17:35] <Kopfgeldjaeger> ok
[17:35] <ScottK> There is a db package that tracks the latest version (now 4.7)
[17:35] <ScottK> and then there are version specific packages
[17:35] <ScottK> Now that db has moved to 4.7, we need to get a db4.6 package.
[17:36] <ScottK> BTW, migrating packages from older db versions is good work to be doing so we can get them out of the archive.
[18:02] <jonnymind> Hello; How can I upgrade from hardy to devel intrepid?
[18:02] <pwnguin> jonnymind: ask in #ubuntu+1
[18:02] <jonnymind> thanks
[18:36] <leleobhz> W: handbrake source: patch-system-but-direct-changes-in-diff contrib/config.jam
[18:37] <leleobhz> this warning can pass in package?
[18:37] <leleobhz> because the build system modify these values
[18:52] <kees> RainCT: any ETA on the pbuilder-dist rewrite?  I'd like to upload ubuntu-dev-tools
[18:57] <kees> RainCT: better yet, can you keep the rewrite in a separate bzr branch?
[19:04] <Kopfgeldjaeger2> Can I set a bug to "Fix released" when a package has been auto-synced into Intrepid (the bug was about a merge)?
[19:05] <Kopfgeldjaeger2> (there was no ubuntu package before the sync)
[19:06] <leleobhz> RainCT: can you turn a little you attention to http://revu.ubuntuwire.com/details.py?package=uniconvertor
[19:13] <leleobhz> this and http://revu.ubuntuwire.com/details.py?package=handbrake
[19:14] <leleobhz> superm1: ping?
[19:15] <mario_limonciell> leleobhz, heyo.  i'll check into it after work
[19:15] <mario_limonciell> leleobhz, get jdong to look too
[19:15] <mario_limonciell> he likes crack
[19:15] <leleobhz> mario_limonciell: nice
[19:15] <directhex> it's a superm1!
[19:16] <leleobhz> the second is a little more important because have thing to do
[19:17] <leleobhz> mario_limonciell: the problem i need to solve in package its only this:
[19:17] <leleobhz> W: handbrake source: patch-system-but-direct-changes-in-diff contrib/config.jam
[19:17] <leleobhz> W: handbrake source: patch-system-but-direct-changes-in-diff libhb/.depend
[19:17] <mario_limonciell> hi directhex :)
[19:17] <leleobhz> and i dont know how to handle with it
[19:17] <mario_limonciell> well you add a patch system
[19:17] <mario_limonciell> like dpatch, or simplepatchsys
[19:17] <leleobhz> mario_limonciell: yeap. because makefile have no install target
[19:18] <leleobhz> mario_limonciell: but i dont know why the compilation program does this
[19:18] <mario_limonciell> oh its gets created when you do make clean?
[19:18] <mario_limonciell> or at some stage not caused directly by your actions
[19:18] <leleobhz> yeap
[19:18] <mario_limonciell> then you need to add an extra clean step to your rules file
[19:18] <mario_limonciell> to remove stuff that the package's makefile decides to leave
[19:19] <leleobhz> i can safelly remove these files?
[19:19] <mario_limonciell> well if they are generated at build time
[19:19] <mario_limonciell> yes
[19:19] <mario_limonciell> which is what it sounds like since you didn't make them
[19:19] <directhex> mario_limonciell, got my first package into main \o/
[19:19] <mario_limonciell> ooooh directhex
[19:19] <mario_limonciell> what package?
[19:19] <directhex> mario_limonciell, mono
[19:20] <directhex> mario_limonciell, it was a bit... in need of merging
[19:20] <mario_limonciell> directhex, i could see that.  complicated merges are what we call "fun" though
[19:20] <mario_limonciell> leleobhz, however... if those files are "modified" by the makefile of the package, that's different
[19:21] <mario_limonciell> so you should see whether they end up getting "added" or "modified"
[19:21] <leleobhz> mario_limonciell: i think its files are created by jam
[19:21] <mario_limonciell> leleobhz, yeah then just add a clean step in debian/rules to take care of them
[19:21] <leleobhz> mario_limonciell: nice
[19:22] <leleobhz> mario_limonciell: ill do this now.
[19:24] <kees> RainCT: I've moved pbuilder-dist to pbuilder-dist.new for now. (using "bzr mv" so the revision history is intact.)  and put the old pbuilder-dist back in place so I could publish the current ubuntu-dev-tools with the various bug fixes.
[19:42] <Jazzva> What should I do if my package FTBFS on some architectures, because of uninstallable deps? Forbid that architecture in debian/control?
[19:47] <DktrKranz> Jazzva, sometimes it's just transient
[19:48] <Jazzva> DktrKranz: Ok, I'll leave it for a while in this state. If it still doesn't build I'll dig a bit, to see what's with those packages. Thanks
[19:52] <DktrKranz> Jazzva, which port was?
[19:52] <DktrKranz> hppa?
[19:52] <Jazzva> yep
[19:53] <DktrKranz> it's out of date, you should leave it for now, it will be fixed later and packages will be mass given-back
[19:53] <Jazzva> Great :)
[19:57] <leleobhz> i still working on handbrake, this time also adding the gui
[19:57] <leleobhz> so, ive created the patch to create the files
[19:58] <leleobhz> but i dont know what i need to do with rules to get into directory and run ./configure ; make ; make install
[19:58] <leleobhz> someone can help?
[19:59] <directhex> sounds like a pretty simple rules file to me
[20:00] <leleobhz> using cdbs
[20:02] <leleobhz> directhex: cdbs isnt very well documented
[20:02] <directhex> cdbwho? honestly, this sounds simple enough for dh_make to do the job
[20:03] <directhex> IMHO. IANAL. YMMV.
[20:03] <Laney> leleobhz: I found the CDBS documentation useful...
[20:03] <leleobhz> Laney: almost
[20:04] <Laney> /usr/share/doc/cdbs/
[20:04] <leleobhz> have a lot of things that isnt documented
[20:04] <leleobhz> Laney: im reading the code
[20:10] <kees> mathiaz: I've uploaded the changes for mk-sbuild-lv, thanks for the diff.
[20:23] <RainCT> kees: Yeh, I've seen the diffs. Good work :)
[20:25] <mario_limonciell> leleobhz, https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml i've gotten everything i ever needed to know about CDBS from there
[20:25] <leleobhz> mario_limonciell: its not everything
[20:26] <leleobhz> im reading this doc since 2 days... and a debian devel told me most of resources of cdbs are documented in source code
[20:26] <leleobhz> (and really appears)
[20:26] <Laney> mathiaz: Those merges you blogged, do we still need to ping the last uploader or are they free to do?
[20:27] <RainCT> davromaniak: ping
[20:29] <bdmurray> mario_limonciell: are you familiar with vpnc?
[20:30] <mario_limonciell> bdmurray, can't say i am sorry.
[20:30] <mario_limonciell> i may have done an upload in the past, but that was some time back
[20:30] <bdmurray> mario_limonciell: okay, thanks
[20:30] <bdmurray> by the way I saw kerneloops is in intrepid now
[20:31] <mario_limonciell> ah very good
[20:31] <bdmurray> Is any of the motu-sru team around?
[20:33] <ScottK> Yes
[20:35] <bdmurray> ScottK: Hi, I'm curious about the process for getting a bug looked at for an SRU.  Is it the same as for main?
[20:35] <bdmurray> Should I just target the bug to Hardy and that will put it on the radar.
[20:36] <ScottK> You'd need to subscribe motu-sru.
[20:36] <ScottK> That or ping someone on IRC.
[20:36] <bdmurray> So subscribe motu-sru even though there is no patch / package?
[20:37] <ScottK> bdmurray: Is it fixed in Intrepid
[20:37] <ScottK> What's the bug?
[20:37] <bdmurray> bug 236483 - it is fixed in Intrepid but not Hardy
[20:39] <ScottK> bdmurray: From reading the changelog, it looks like debian/patches/update-service-providers.patch needs to be backported to Hardy.
[20:40] <bdmurray> right, that was what I thought, but as the bug stands nobody will know that should / could be done.  So what can I do to ensure it shows up in the right bug list?
[20:41] <ScottK> I don't know that there is a 'right' bug list.
[20:41] <ScottK> motu-sru generally looks a bugs that a developer has already taken an interest in.
[20:42] <mathiaz> Laney: better to ping the last uploader
[20:42] <mathiaz> Laney: they should be easy to do, but better follow the process described in the Merging wiki page.
[20:42] <ScottK> bdmurray: Don't we have a tag for an easy fix (bitesize I think)
[20:42] <Laney> mathiaz: Yeah that's fine. I just didn't know if you'd worked something out for them, that's all.
[20:42] <davromaniak> pong RainCT
[20:42] <bdmurray> ScottK: since the bug is Fix Released it wouldn't show up in default searches
[20:42] <bdmurray> but yes we do
[20:43] <ScottK> Right.
[20:43] <bdmurray> ScottK: This document https://wiki.ubuntu.com/RCBugTargetting seems to indicate nomination / targetting is the right list
[20:44] <ScottK> OK, well I just nominated it.
[20:44] <ScottK> So that takes care of that then.  I think adding bitesize would be useful.
[20:44] <bdmurray> Okay, I'm doing that then.
[20:49] <Laney> ScottK: I wouldn't mind having a go at this SRU. Can I just assign the Hardy task to myself?
[20:49] <ScottK> Laney: Yes.
[20:50] <Laney> ScottK: Thanks. Working on it now.
[20:50] <ScottK> Laney: Keep in mind that my guess that pulling that patch into the Hardy package would fix it was exactly that - a guess.  You'll need to test it.
[20:50] <Laney> ScottK: Of course
[20:53] <Kopfgeldjaeger> Could somebody have a look at my small debdiff in bug #227323? Can I subscribe u-u-s?
[20:54] <siretart> FYI, motu meeting in 6 minutes!
[20:56] <cody-somerville> What...
[20:56] <Laney> ScottK: It looks like RainCT is working on this in bug #239719
[20:56] <cody-somerville> siretart, who is responsible for scheduling said MOTU meetings at such horrible times for me? :P
[20:56] <RainCT> Laney: I was about to ping you :)
[20:57] <Laney> :P
[20:57] <ScottK> RainCT: Having a separate bug like that just for the SRU can be confusing.
[20:57] <siretart> cody-somerville: AFAIUI the time is rotating, so that every timezone has to suffer from time to time
[20:58] <RainCT> ScottK: Right, my fault. By the way, it's not just that one patch; youtranslate is FTBFS in Gutsy and Hardy too
[20:58] <ScottK> OK.
[20:58] <ScottK> Thus my guess is proven wrong.
[20:59] <Laney> I only got as far as "apt-get source" before noticing the new bug ;)
[21:00] <Laney> Urgh, just duplicated RainCT's comment too. Sorry for bug spam
[21:00] <RainCT> heh
[21:01] <davromaniak> RainCT: hi
[21:02] <RainCT> (brb)
[21:02] <davromaniak> ok
[21:21] <elliotjhug> hi all, just packaged something for the first time - followed the guide, but where does dbuilder store the resulting .deb file when it has been run? (seems like a such a newbish question - I'm sorry)
[21:22] <davromaniak> /var/cache/pbuilder/result
[21:23] <davromaniak> I didn't package since few months, but I think it's this path
[21:24] <elliotjhug> davromaniak: Thanks - that's brilliant :)
[21:24] <davromaniak> np
[22:17] <ryanakca> How can I make knmap not run configure twice (once at start of build, and one at the end)?
[22:51] <sebner> ah I missed the meeting :( who can me bring up to date?
[23:01] <sistpoty> sebner: d'oh... I missed that too. maybe irclogs.ubuntu.com can shed some lights
[23:01] <sebner> sistpoty: *good* ida
[23:01] <sebner> *idea
[23:04] <sebner> sistpoty: pretty boring one ^^
[23:04] <sistpoty> still reading...
[23:11] <sebner> however gn8 folks, sistpoty
[23:11] <sistpoty> gn8 sebner
[23:11] <RainCT> good night