[00:00] <ramiro> after running dh_make, editing debian/*, and dpkg-buildpackage, I get a bunch of files like the original source and a diff. but sometimes that creates different tarballs, sometimes only a diff (like when building a -2 package) and sometimes it creates a whole new source tarball even when only building a -2 package. what documentation can I read that explains all those files created and which ones I should have on the repo?
[00:13] <directhex> ramiro, it depends on a few things
[00:14] <directhex> ramiro, firstly, the presence of an orig tarball with proper naming
[00:14] <directhex> ramiro, so if you have a source package "foo" version 1.0 which uses the name "foo" version 1.0-1 in debian/changelog, then the orig should be named foo_1.0.orig.tar.gz
[00:16] <directhex> ramiro, anything you fiddle which isn't as found in that orig will go into a diff.gz file foo_1.0-1.diff.gz - you should try to ensure the diff.gz only contains the debian/ folder
[00:16] <directhex> ramiro, if there's no orig, then instead of orig.tar.gz and diff.gz, you only get a single tarball (this is called a native package and is used when ubuntu is upstream)
[00:16] <ramiro> mika_video: but when I run dh_make -f origsource shouldn't it already create a proper foo_1.0.orig.tar.gz ?
[00:17] <ramiro> oops, wrong reference, that was meant to directhex
[00:17] <ramiro> ah, so that's what a native package is...
[00:19] <ramiro> so then if I have orig, I should put foo_1.0.orig.tar.gz and foo_1.0-1.diff.gz on the repo. if it's a native package (which I don't think is my need), I should put foo_1.0-1.tar.gz on the repo. right?
[00:19] <directhex> ramiro, right.
[00:21] <ramiro> directhex: thanks, that made things much clearer.
[01:55] <ramiro> "has no source override entry". what is an override file and why do I need one? I read the documentation but I'm not convinced I need it.
[01:56] <persia> ramiro: Could you give a little more context?
[01:56] <ramiro> oops, I cut out the most important chunks of the paste.
[01:57] <ramiro> "apt-ftparchive sources  . /dev/null > /dev/null" prints out a bunch of "%s has no source override entry" and "%s has no source override entry either" to stderr.
[01:58] <persia> Oh, that's just because there's no override files in your archive.
[01:58] <persia> You can ignore that if you're not using overrides.
[01:59] <ramiro> great, but is there any way to supress the message? it prints even with -q
[02:00] <ramiro> sure, I could 2>/dev/null, but I'd rather have the other error messages if they do exist.
[02:00] <persia> Use overrides?  Don't use apt-ftparchive on sources?
[02:02] <lifeless> if you don't use overrides at all, I think its totally quiet about them, from memory
[02:03] <persia> For binaries, I'm sure that's true.  I'm less sure about sources.
[02:04] <lifeless> if its not true, you could patch it
[02:04] <ramiro> it only prints for the sources, not for "packages" nor "release"
[02:21] <psusi> I've used dpatch before... but this package appears to be using another system... it has a patches directory with a series file in it and normal .patch files... what system is that and how can I create a new patch with that system?
[02:25] <RAOF> what-patch will tell you what patch system the package is using, and edit-patch will Do The Right Thing (I think)
[02:25] <persia> psusi: Run `what-patch` for a best guess.  Run `edit-patch` to use automation to guess the system.
[02:26] <psusi> hrm... quilt eh?  hrm. I thought that was an RCS
[02:28] <psusi> hrm... so once I'm done editing, what's the command to save the patch?  dpatch used to spawn a sub shell you just exited from, this doesn't seem to do that
[02:29] <persia> psusi: /usr/share/doc/quilt/README.source has some guidance on usage.
[02:29] <persia> !patchsystems
[02:29] <persia> !patch
[02:29] <persia> The PatchSystems page has some more
[02:53] <krisives> hi, i'm a Compiz developer, and as you may know in our new 0.9 we've moved from C to C++, and libboost is required. How does Ubuntu plan to work with this?
[02:54] <ScottK> krisives: We already have boost.
[02:54] <ScottK> 1.40 is our default for the next Lucid release.
[02:55] <krisives> it comes on the CD?
[02:55] <ScottK> I'm not 100% sure.  OOo uses it.
[02:55] <ScottK> It is in Main, so it's not a problem.
[02:56] <krisives> I know there have been some space issues, is there any luck of moving away from the 700Mb CD and towards a 4.5G distro?
[02:56] <StevenK> krisives: Ubuntu also produces DVD images
[02:56] <ScottK> krisives: The core distro will stay CD sized.
[02:56] <krisives> Any idea how big boost is ?
[02:57] <persia> krisives: The CD requirement is unlikely to change in the medium-term, in part due to comparative mass-production rates for the two media.
[02:57] <krisives> I see, thanks persia :D
[02:57] <krisives> You're everywhere!
[02:58] <krisives> even though our 0.9 code didn't make it into the LTS, is it possible for it to go into Lucid+1 ?
[02:58] <krisives> or is that not possible because of it being an LTS?
[02:58] <ScottK> krisives: I'm not sure how it works for Compiz, but most of the boost using packages carry a runtime depends on only a small part of the total boost package.
[02:58] <ScottK> Some don't have any runtime depends at all, just build time.
[02:59] <persia> lucid+1 isn't LTS, and if you've released, 0.9 can probably drop during the open archive window.
[02:59]  * StevenK is trying to work out how large boost is
[02:59] <krisives> Thanks for the help guys
[03:00] <persia> StevenK: large, but broken into many little bits.
[03:00] <StevenK> persia: Yes, I'm adding the little bits together
[03:00] <ScottK> krisives: Potentially the biggest issue will be to keep so you can build with the newer versions.  This is sometims non-trivial.
[03:01] <persia> But the key bit is that the vast majority of clients only need some of the little bits.
[03:01] <krisives> yeah we're looking at it right now to see what we depend on in terms of boost
[03:04] <StevenK> There. http://paste.ubuntu.com/395942/
[03:05] <StevenK> Don't look too close, your eyes will bleed
[03:05] <ScottK> That goes with the territory with boost.
[03:06] <ScottK> How cute, it even follows the units policy.
[03:06] <krisives> I don't know boost very well, can you guys tell me what we might depend on with this http://paste.ubuntu.com/395943/
[03:06] <persia> The nice thing about boost is that building it is a nice stress test for memory management systems.
[03:06] <krisives> I just did some grepping for #include related to boost
[03:06] <StevenK> I think that's all core
[03:07] <persia> StevenK: One of these days you need to learn awk :p
[03:07] <StevenK> persia: I'm going to keep my tr and sed skills and love them. So nyah
[03:07] <krisives> I actually did that with the Search feature :(
[03:08] <krisives> oh btw we finally are documenting our API
[03:09] <krisives> and the switch from C to C++ has made plugin development sane with a clean abstraction
[06:04] <jayvee> fabrice_sp: should there really be a debian/gbp.conf file?
[06:06] <fabrice_sp> jayvee, sorry?
[06:06] <jayvee> fabrice_sp: I'm working on the tahoe-lafs package. Working on cleaning it up like you gave me pointers.
[06:06] <jayvee> Just found this 'gbp.conf' file, which is kinda weird
[06:07] <jayvee> it starts with [git-buildpackage], and it has karmic hardcoded in it
[06:07] <jayvee> although I didn't think it was versioned in git
[06:07] <jayvee> so that leads me to think it's just cruft
[06:07] <fabrice_sp> seems like it, yes. Let me check where it can come from
[06:08] <fabrice_sp> (or you can ask original packager)
[06:09] <fabrice_sp> you're right: it seems to be some git configuration file
[06:10] <fabrice_sp> "Git-buildpackage can be configured in a per-repository .gbp.conf, which must not be included in the package sources."
[06:11] <fabrice_sp> taken from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501243
[06:12] <fabrice_sp> jayvee, ^
[06:21] <jayvee> fabrice_sp: I guess I'm wondering, is it safe to delete?
[06:33] <fabrice_sp> jayvee, yes :-)
[06:33] <jayvee> cool
[06:56] <wzssyqa> hi,i use dh_makeshlibs  and dh_installdeb,but it don't genrate postinst and postrm for a share lib installed to /usr/lib
[07:18] <ejat> hi .. after i debuild -S -k<mykey>
[07:18] <ejat> i dput to my ppa .. but it not uploading the source file ..
[07:18] <ejat> why its happend and how to counter it ?
[07:20] <persia> ejat: What error do you get?
[07:20] <lifeless> ejat: what do you mean 'not uploading the source file''
[07:21] <ejat> lifeless: yes
[07:21] <ejat> persia: no error
[07:21] <ejat> http://paste.ubuntu.com/396008/
[07:22] <dholbach> good morning
[07:22] <ejat> morning
[07:22] <persia> ejat: What's missing?
[07:23] <ejat> Unable to find dbmail_2.2.15.orig.tar.gz in upload or distribution.
[07:23] <persia> Oh, you want -sa then.
[07:23] <StevenK> ejat: Craft your .changes using -sa
[07:23] <ejat> previously if i do the dput .. it will upload the source
[07:23] <ejat> StevenK: debuild again with -sa ?
[07:23] <ejat> not with -S
[07:24] <StevenK> ejat: Both
[07:24] <ejat> debuild -S -sa
[07:26]  * ejat trying ..
[07:27] <wzssyqa> hi,i use dh_makeshlibs  and dh_installdeb,but it don't genrate postinst and postrm for a share lib installed to /usr/lib
[07:28] <ejat> StevenK: i just redo using -S -sa .. but then .. im getting this http://paste.ubuntu.com/396010/
[07:29] <wzssyqa> ejat: you need to remove a upload file
[07:29] <ejat> wzssyqa: how to remove .. its not visible at launchpad
[07:29] <wzssyqa> in the same dir with orig.tar.gz
[07:29] <wzssyqa> ejat: it is used by dput
[07:29] <wzssyqa> ejat: just del it
[07:31] <wzssyqa> ejat: or you can increase your version in changelog
[07:31] <ejat> wzssyqa: i follow here https://help.launchpad.net/Packaging/UploadErrors :)
[07:32] <ejat> delete the log
[07:32] <ejat> thanks StevenK its work ... upload with the source
[07:37] <ejat> how do i build for karmic if inside the changelog already build for lucid ?
[07:38] <persia> Change the changelog
[07:38] <persia> (or mangle the .changes file between creation and signing, but this may require other hacks, and may break things)
[07:40] <ejat> just change the changelog .. then rebuild it back ..
[07:41] <ejat> is it will conflict the source file that i already upload ?
[07:41] <ejat> or can i just copy the binary from lucid to karmic ? or is it not recommended
[08:02] <jayvee> ejat: use "debchange -i"
[08:03] <jayvee> and on the top changelog entry, just change lucid to karmic
[08:03] <jayvee> and add a ~ppa1 at the end of the version that it puts on
[08:03] <ejat> owk ok .. so it will be karmic~ppa1
[08:03] <jayvee> nope
[08:04] <jayvee> put a ~ppa1 on the end of the version
[08:04] <jayvee> so if the version is 1.0-2ubuntu5
[08:04] <ejat> owh ok .. get it
[08:04] <jayvee> make it 1.0-2ubuntu5~ppa1
[08:04] <ejat> ok ..
[08:04] <ejat> then after finish build the karmic .. then change it back to lucid ?
[08:04]  * persia recommends +ppa1 like it says in the versioning guide in the PPA docs.
[08:04] <jayvee> persia: last time I read the docs they used ~ppa1, but that was a long time ago
[08:05] <persia> Yes, it was changed.
[08:05] <jayvee> ejat: depends on whether you want the package to be available to karmic or lucid users
[08:05] <jayvee> ejat: if you want it to be available to both, you'll have to upload two versions, one for karmic and one for lucid
[08:05] <jayvee> at least I think so
[08:05] <ejat> ok thanks jayvee n persia
[08:06] <jayvee> the way people do it is they add a ~ppa1 for the latest (e.g. lucid), and then for the "earlier" ones, they add things like ~ppa1~karmic
[08:06] <persia> The discussion about PPA mechanics is more appropriate for #launchpad, but in many cases uploading to karmic and copying to lucid works fine.
[08:06] <jayvee> or +ppa1~karmic, as persia points out
[08:07] <ejat> persia: so i better do the copying :)
[08:31] <ejat> http://launchpadlibrarian.net/40997035/buildlog_ubuntu-karmic-i386.nagiosql_3.0.3-1ubuntu1_FAILEDTOBUILD.txt.gz .. who can help me with this failed :(
[08:32] <persia> ejat: Missing build-dependencies.  Did you try with pbuilder or sbuild first?
[08:33] <wzssyqa> how to edit 'LINKFLAGS' to add version to the end of .so file?
[08:36] <ejat> owh .. forget .. persia .. so i need to test it with pbuilder then if ok .. then upload to ppa ?
[08:37] <ejat> make: dpatch: Command not found
[08:37] <persia> That's usually easier to track down, because it's local.
[08:37] <ejat> persia: ic .. so its miss the dpatch ?
[08:39] <persia> Something like that.
[08:46] <ejat> persia: http://paste.ubuntu.com/396048/
[08:46] <ejat> added the dpatch in control ..
[08:46] <ejat> but its still occurs ..
[08:47] <persia> Try adding something like `dpkg -l dpatch` in your rules to make sure it's getting installed.
[08:47] <persia> Obviously, you need to call this *before* you call dpatch
[08:57] <ejat> persia: so i need to add 'dpkg -l dpatch' before this http://paste.ubuntu.com/396052/
[08:57] <persia> No, but doing so may help you track down the issue.
[08:58] <ejat> add just for tracking is it ?
[08:58] <persia> something went wrong in your build.  It looked like missing dpatch.  You added dpatch, and it still appears to be missing.  You're just following that line of investigation.
[08:59] <persia> Nothing here is long-term useful except insofar as it helps you to understand the issue so you can fix it.
[09:05] <ejat> just wanna double check with u for the control file : http://paste.ubuntu.com/396055/
[09:09] <ejat> shows that i already include the dpatch rite?
[09:22] <persia> ejat: Build-Depends != Depends
[10:53] <jayvee> _ruben: ice cold coca cola
[10:53] <jayvee> love it! <3
[10:54]  * jayvee wishes he thought of that
[10:54] <persia> ?
[10:54] <jayvee> read his ipv6 address
[10:54] <persia> heh.
[11:00] <Laney> Is it usual to add Provides: when renaming a binary package?
[11:01] <jayvee> I thought they usually just do Conflicts: and Replaces:.
[11:01] <Rhonda> If there are reverse dependencies, yes.
[11:01] <Laney> For users to be upgraded to the new package
[11:01] <Rhonda> But it's also usual to provide a transitional package for upgrades.
[11:02] <Rhonda> Laney: Provides doesn't help with upgrades, it helps with reverse dependencies. Empty transitional packages help with upgrades.
[11:02] <Laney> is this because Provides are unversioned?
[11:03] <Rhonda> No.
[11:04] <Rhonda> Provides aren't considered for any upgrade handling.
[11:04] <Laney> alright
[11:05] <persia> Well, that's not strictly true : it's more complicated.
[11:05] <persia> Provides: can be considered if e.g. you have something that conflicts with something on which something else has a dependency and the Provides: satisfies that dependency, but that's a corner case, and there's lots of better ways to do it.
[11:06] <Rhonda> persia: I mentioned reverse-dependencies. :)
[11:07] <persia> Indeed you did.  Everything before "Provides aren't considered for any upgrade handling" was 100% correct.  update-manager tries to be too smart sometimes.
[11:18] <_ruben> jayvee ;)
[12:09] <duanedesign> persia: have not had much luck in reviewing patches and finding something to work on.  Do you have a minute or two to help me?
[12:09] <persia> duanedesign: Sure.
[12:11] <persia> duanedesign: That was your cue to ask a more detailed question :)
[12:11] <duanedesign> persia: thank you. I have been anxious to get started llearning the MOTU ropes, i just havent had much luck finding tasks to do
[12:12] <persia> OK.  What sort of thing do you like to do?
[12:13] <duanedesign> persia: i have done a few simple patches and I have packaged a thing or two. But other than that i am pretty in the dark
[12:14] <persia> OK.  Some of the things that would be helpful now are patch review, RCbugs, unmetdeps, FTBFS
[12:14] <persia> Any of those sound interesting, or do you need more definition of terms?
[12:14] <duanedesign> what are Release Candidate Bugs?
[12:15] <persia> So, Ubuntu is derived from Debian.  The Debian developers fix a lot of bugs.  Some of these are considered "Release Critical" in Debian.
[12:16] <duanedesign> persia: ahh lol, I shouldnt of asumed i knew what RC stood for
[12:16] <persia> There's a tool that scans the differences between Debian and Ubuntu, and references any bugs that Debian closed as Release Critical, but don't appear to have been merged into Ubuntu yet.
[12:16] <persia> So RC bugs is a mix of merges, syncs, and cherrypicking of the bugfixes from Debian to make sure they are included in the Ubuntu release.
[12:17] <duanedesign> persia: ok. sounds good
[12:18] <persia> duanedesign: http://qa.ubuntuwire.com/bugs/rcbugs/lucid/ is the list for lucid.
[12:19] <persia> Each one needs to be reviewed to 1) verify the bug affects lucid, 2) verify it's not fixed in lucid, 3) decide whether it's a sync, a merge, or a cherrypick, and 4) get the fix in or comment that it's not needed.
[12:19] <duanedesign> persia: ok great!
[12:19] <persia> Start with the "grave" ones, and then the "serious" once once you've passed through as much "grave" as you can.
[12:20] <persia> If you don't understand a bug, ask here.  If nobody helps you, check the next one :)
[12:20] <duanedesign> persia: whats a cherrypick?
[12:21] <nigelb> duanedesign: just get the particular patch that fixes the bug into ubuntu :)
[12:21] <nigelb> if the package uses a patch management system like quilt, it might be easy to figure out the patch
[12:22] <persia> Right.  This is often important if the Debian upload contains 4-5 different things, we want one of them, and another of them would break a freeze.
[12:23] <duanedesign> ok i know what a sync is, that is to sync the version in Ubuntu to match upstream. Whats a merge?
[12:24] <tseliot> persia: do you know why we have gtg_0.2.3.orig.tar.gz and gtg_0.2.3-1.debian.tar.gz for gtg in Lucid? And above all which one am I supposed to modify if I want to fix the code?
[12:24] <persia> tseliot: Because it's source format 3.0.  Just dpkg-source -x the .dsc as usual.
[12:25] <persia> duanedesign: A merge is when there are important patches in Ubuntu that we want to preserve, and also changes in Debian we want.  One needs to construct a source package that contains the best of both.
[12:25] <tseliot> persia: yes, that's what I did. I added my fix too (which involved adding a new directory). Which tarball am I supposed to rebuild?
[12:26] <persia> duanedesign: Personally, I find cherrypicks and syncs easier : why not start with those (avoiding the packages that have -XubuntuY revisions), and once you've cleared those, start looking at merges.
[12:26] <lfaraone> Is anybody else having issues with fiordland.canonical.com for requestsync?
[12:26] <persia> tseliot: You build a source package with `debuild -S` (or similar), which should do the right thing.
[12:26] <duanedesign> persia: nice. thanks for the tip
[12:27] <wzssyqa> is it a big problem that have a symbol link of share lib that without version
[12:27] <lfaraone> persia: we don't care about syncing ftbfs fixes on armel, do we? (I don't think we're releasing armel)
[12:27] <tseliot> persia: http://pastebin.ubuntu.com/396139/
[12:28] <persia> lfaraone: I'd like us to care, because it increases the chances I can upgrade my Netwalker to lucid :)
[12:28] <persia> tseliot: Are you using lucid to build the source?
[12:29] <tseliot> persia: yes, sure
[12:29] <persia> Did you use quilt to apply the patch?
[12:29] <highvoltage> hmm... where's keybuk when you want to compliment him
[12:29] <tseliot> persia: no, I guess that's the problem. I was hoping to rebuild the source and make a debdiff
[12:30] <persia> tseliot: Right, but it's format 3.0 (quilt), so you have to apply the patch with quilt.
[12:30] <persia> Once you've done that, debdiff ought do the right thing.
[12:30] <tseliot> persia: ok, I'll do that, thanks
[12:31] <lfaraone> persia: hm. I'm having some issues when trying to build ams-2.0.1-2, "The following packages have unmet dependencies: ... Depends: ladspa-sdk, fftw-dev, sfftw-dev, libclalsadrv-dev (>= 1.0.1-3) which is a virtual package."
[12:32] <persia> lfaraone: On armel?
[12:33] <jayvee> I've been told to fix this debian/watch file, and I'm having a little trouble with the regular expression. Normally tarballs have a (.*)\.tar\.gz on the end, but tahoe-lafs has a "1.6.1-SUMO" release, which uscan thinks is the latest version. (SUMO is a version that contains dependency cruft, so should be excluded.)
[12:33] <lfaraone> persia: on amd64 :)
[12:33] <jayvee> I can use ([\.0-9]+)\.tar\.gz on the end, but if they decide to release something like 1.6.1b, it won't pick that up.
[12:33] <lfaraone> pbuilder doesn't seem to like it's deps.
[12:33] <persia> jayvee: man uscan : look for the uversionmangle option
[12:33] <persia> lfaraone: You have universe enabled?
[12:34] <jayvee> persia: awesome!
[12:34] <jayvee> opts="uversionmangle=s/-SUMO//"
[12:34] <jayvee> works brilliantly
[12:35] <lfaraone> persia: probably.
[12:35] <persia> lfaraone: Because I can install fftw-dev on my local amd64 system without issue (just tested).
[12:37] <lfaraone> persia: ah, I was missing htat.
[12:40] <lfaraone> persia: once I do https://wiki.ubuntu.com/PbuilderHowto#Universe%20support, do I need to rebuild the chroot?
[12:40] <persia> lfaraone: But don't forget to check for outstanding bugs : bug $538060 may interest you
[12:41] <persia> Err, bug #538060
[12:44] <jayvee> is it possible to do uversionmangle and dversionmangle in the same line?
[12:44] <jayvee> in the same opts="", I mean
[12:45] <jayvee> the man page is suspiciously vague on that matter
[12:47] <persia> jayvee: Most certainly
[12:58] <lfaraone> persia: we can't sync packages that depend on iceweasel, right? (we need to merge the changes)
[12:59] <persia> Check with mozillateam, but that's my understanding.
[13:05] <directhex> persia, would a Provides: iceweasel really be an issue?
[13:07] <persia> directhex: Check with the mozillateam.  I discussed this previously, and I understand there are reasons for the choices made.
[13:11] <ScottK> directhex: You can't have versioned provides.  I suspect that's at least part of the issue.
[13:12] <directhex> ScottK, oh, yes, there is that
[13:13] <Rhonda> or from the other point of view, a provides can't fulfill a versioned depends. :)
[13:45] <malev> hi! is there an irc channer for: Ubuntu Prospective Developers  I wanna start developping in Ubuntu, and I think that is the place for start :D
[13:46] <Pici> malev: #ubuntu-app-devel
[13:46] <persia> Um, no.
[13:46] <persia> malev: What kind of development do you want to do?
[13:47] <Pici> No?
[13:47] <persia> Pici: #ubuntu-app-devel is for folk developing applications that run *on* Ubuntu, not for developing Ubuntu itself.
[13:47] <malev> persia: ... to start! I'm a begginer in this area
[13:47] <Pici> persia: Oh, right :)
[13:47] <persia> malev: OK.  What sort of packages interest you?  What sort of work might you like to do on them?
[13:49] <malev> persia: packing python and maybe solving some bugs
[13:49] <malev> something like that
[13:49] <persia> OK.  That's certainly doable.  Have you encountered any bugs that are bothering you now?
[13:50] <malev> persia: not right now. Me idea is to start packing in ubuntu for contributting with ubuntu. Currently I've been at the bugsquad team
[13:52] <malev> the thing is that the developers wiki are not clear as the bugsquad's wiki. you know, for begginers
[13:52] <persia> heh.
[13:53] <persia> So, from your work with bugsquad, have you encountered some bugs in python packages you think you can fix?
[13:54] <malev> I guess. some at python-numpy, python-matlibplot and gwibber. But I haven't tried
[13:54] <nigelb> do we need to sync the new debbootstrap into ubuntu? seems to have a bit of new features and some bug fixes
[13:54] <persia> Well, give one a try :)
[13:55] <persia> nigelb: Potentially, or potentially cherrypick.  What do you think?
[13:55] <jayvee> is there an easier way to convert .diff.gz modifications to debian/patches than my manual method?
[13:55] <malev> persia: you say: I should encourage to fixing bus first and then trying to join a ubuntu developers team?
[13:56] <nigelb> persia: Cherrypick may not need an ffe, but I feel its worth an ffe
[13:56] <persia> malev: Absolutely.  All the teams expect you to have been working as part of them to become a member.
[13:56] <nigelb> ie, sync the whole thing
[13:56] <malev> persia: Oks! thanks!!
[13:57] <persia> malev: Just ask here when you get stuck, and we'll help you along.
[13:57] <malev> cool!
[13:58] <persia> malev: If you end up working on packages that belong to another team, we'll tell you to talk to them, but since we handle most packages, it's usually safe to ask here if you're not sure.
[13:59] <tseliot> DktrKranz: ping on gtg
[14:00] <persia> nigelb: Well then, built it on lucid, test it, and if it does all it should, file bugs :)
[14:01]  * nigelb grumbles about all the work
[14:03] <persia> nigelb: That's how "we" becomes "we" :)
[14:03] <nigelb> persia: hehe
[14:04] <DktrKranz> tseliot: gtg pong :)
[14:04] <tseliot> DktrKranz: I've noticed that you uploaded gtg
[14:05] <tseliot> DktrKranz: and I'm wondering how I'm supposed to add my fix with quilt (as it involves adding binaries too) to the source tarball
[14:05] <tseliot> see my last comment in  bug #531909
[14:05]  * DktrKranz looks
[14:07] <DktrKranz> tseliot: oh, distutils troubles again... you'll have to patch setup.py to include missing directories
[14:07] <DktrKranz> (I can eventually fix it in Debian and then sync)
[14:07] <tseliot> DktrKranz: the point is that setup.py already contains those files and directories but the tarball does not
[14:08]  * tseliot is wondering why the package doesn't fail to build
[14:08] <DktrKranz> oh, is tarball lacking them? I intended the other way roind
[14:08] <DktrKranz> *round
[14:09] <tseliot> DktrKranz: yep
[14:09] <DktrKranz> so, it's a broken MANIFEST.in
[14:10] <DktrKranz> eta for 0.2.4 is ~1w from now, this could be eventually fixed there (after a FFe, of course)
[14:11] <tseliot> DktrKranz: if you think the new upstream release is worth a FFE, then sure, let's wait
[14:12] <DktrKranz> tseliot: if it's not, IIRC gtg is already format 3.0 (quilt), adding blobs is allowed and not much difficult
[14:13] <DktrKranz> anyway, I'll point upstream to that, so there's chance to properly fix it
[14:15] <tseliot> DktrKranz: blobs are actually html files which quilt sees as blobs *I guess*
[14:15] <DktrKranz> no, it should see them as normal text files
[14:15] <tseliot> so I figured
[14:15] <DktrKranz> for images, they're interpreted as blobs
[14:16] <DktrKranz> but new format doesn't care
[14:17] <tseliot> DktrKranz: how does it work? Will the new source have a debian/patches directory with my diff?
[14:17]  * tseliot has never used quilt with source format 3
[14:18]  * tseliot is familiar with quilt though
[14:19] <tseliot> aah: "Debian-specific changes are no longer stored in a single .diff.gz but in multiple patches in debian/patches/"
[14:20] <tseliot> http://wiki.debian.org/Projects/DebSrc3.0
[14:20] <persia> tseliot: Well, kinda.  It's more complicated than that, and there are more options, but for this package, yes.
[14:21] <tseliot> ok
[14:23] <Rhonda> tseliot: That's only part of the truth. Debian-specific changes were for a long time already stored in multiple patches in debian/patches/, if one used a patch system. But you know, advertising and stuff. :)
[14:24] <tseliot> heh
[14:24] <Rhonda> … and actually like you mentioned quilt, quilt did that right from the start. :)
[14:24] <Rhonda> Don't though be misguided by the naming of the format quilt. It's just similar to quilt but still is different.
[14:25] <persia> Format: 3.0 (quilt) is just like using quilt as a Format: 1.0 patchsystem, except one doesn't build-dep on quilt.
[14:25] <Rhonda> … moreorless.
[14:26] <persia> Well, yeah.
[14:27]  * persia carefully ignores the dpkg implementation
[14:27] <Rhonda> Keeping in mind that they are different things is needed to not get frustrated in cases it (still) behaves differently.
[14:27] <nigelb> Rhonda: is there an easily recognized page that details sponsorship process in debian?
[14:27] <Rhonda> e.g. format 3(quilt) on intention doesn't allow fuzzy patches, which quilt accepted quite readily.
[14:27] <nigelb> I only see references to the thing
[14:28] <Rhonda> nigelb: Well, just produce the source package, upload it somewhere and fire up a mail to the debian-mentors@lists.debian.org list.
[14:28] <Rhonda> or find somone interested in the package who can act like your regular sponsor/mentor combination.
[14:28] <nigelb> so, I'm supposed to mail the person
[14:28] <Rhonda> No, the list. :)
[14:28] <Rhonda> group of persons. :)
[14:29] <nigelb> the documentation is so confusing.  it only says, go through sponsorship
[14:29] <nigelb> I have someone who would be interested
[14:29] <nigelb> trying to respond to a RFH
[14:29] <persia> nigelb: An RFH bug?  reply to the bug.
[14:29] <Rhonda> There is this mentors.debian.net service for uploading, but that doesn't really go around looking for sponsors, so just uploading there and waiting doesn't gain much.
[14:30] <nigelb> I did reply.  so what do I do with the package I want sponsorship?
[14:30] <Laney> If the submitter of the RFH is a DD, ask them for sponsoring.
[14:30] <Rhonda> If there is a bug it closes you should also use that facility and either attach the debdiff to the mail or a link to your prepared sources.
[14:30] <nigelb> ah, debdiff, attach to bug - now that makes sense
[14:31] <nigelb> why can't it just be written in the new maintainer guide.. sigh
[14:31] <Rhonda> Because debian is hard core. If you can dig its documentation you are ready for applying to become a DD. :P
[14:31] <nigelb> lol
[14:32] <nigelb> yeah, you just cut out people who can't find things ;)
[14:32] <nigelb> Getting gwibber to debian seems harder than I thought though.
[14:33] <DktrKranz> Rhonda: it's hard by design, or NM is just a copy&paste :)
[14:33] <Rhonda> nigelb: But it's there already, isn't it?
[14:33] <nigelb> Rhonda: gwibber (1.2.0+bzr358-2)
[14:34] <Laney> maybe the person maintaining it in Ubuntu is interested in uploading to Debian instead...
[14:34] <nigelb> trying to get gwibber 2 in (which why there was an RFH, coz the thing doesn't work)
[14:34]  * Laney coughs
[14:34] <nigelb> ken?
[14:34] <Laney> I dunno who it is
[14:34] <nigelb> it comes under desktop team ;)
[14:34] <Laney> ha
[14:35] <Laney> the desktop team has a lot of DDs too
[14:35] <nigelb> Since they're busy people, I thought I'd poke them when I get stuck
[14:36] <Laney> since when did it move to main/
[14:36] <nigelb> since Lucid probably
[14:36] <nigelb> the Me Menu and all
[14:36] <Laney> oh, the social from the start stuff eh
[14:36] <nigelb> yeah, that works on top of gwibber
[14:43] <nigelb> how wicked would be to upload to debian with an @ubuntu address? ;)
[14:45] <persia> bdrung does it all the time.  Other people never do.  Matter of taste.
[14:45] <Laney> http://ftp-master.debian.org/new/pinta_0.2-1.html
[14:45] <Laney> what what
[14:46] <Laney> I figure it helps to add to the "giving back" metric.
[14:46] <nigelb> thats my idea too
[14:46] <Rhonda> nigelb: If you want to get someone ranting, just do it. It's always fun. :)
[14:46] <nigelb> besides, I'm too lazy to keep changing the values set in bashrc and git ;)
[14:47] <persia> People will rant either way "Don't upload with @ubuntu" vs. "Ubuntu doesn't contribute to Debian".
[14:47] <Laney> I haven't been flamed yet :(
[14:47] <Rhonda> nigelb: http://sandrotosi.blogspot.com/2009/11/things-that-make-me-angry.html
[14:47] <persia> People like ranting.  Focus on the work.
[14:47] <tseliot> DktrKranz: so, it looks like the 2 html are indeed binaries. See my quilt patch: http://pastebin.ubuntu.com/396202/
[14:47] <Laney> I recall morph getting counter-flamed quite a lot for that post
[14:47] <nigelb> My main idea is people need not say, "Ubuntu does not contribute to debian"
[14:47] <Rhonda> nigelb: You just said that!
[14:48] <nigelb> Rhonda: I'll contribute soon enough to solve that ;)
[14:48] <shadeslayer> nigelb: btw congrats on becoming a member!! are you from India?
[14:48] <persia> nigelb: Just focus on the work.  Really.  Don't worry about the address.  No matter which way you do it, you'll annoy someone.
[14:48] <Laney> It's not really "ubuntu" anyway, it's me
[14:48] <persia> Laney: Indeed.
[14:48] <nigelb> shadeslayer: lol, I thought you knew ;)
[14:49] <persia> (well, this also applies for other values of "me")
[14:49] <shadeslayer> nigelb: oh cuz im from there too :)
[14:49] <nigelb> shadeslayer: I know
[14:49] <Laney> Anyone know if it's possible to push all git branches and tags with one command?
[14:49] <Laney> vs push --all && --tags
[14:50] <shadeslayer> nigelb: :P oh best of luck for the future :)
[14:50] <nigelb> shadeslayer: ty :)
[14:51] <lfaraone> kees: did you have a chance to work on bug 538471?
[14:51] <shadeslayer_> nigelb: oh one last thing can you edit the ubuntu wiki with IST set in your LP profile?
[14:52] <nigelb> shadeslayer_: conflicts with wiki
[14:52] <vish> shadeslayer_: did it say error when logining with open id?
[14:52] <shadeslayer_> nigelb: yeah i thought so... workarounds?
[14:52] <shadeslayer_> vish: yep
[14:52] <lfaraone> nigelb: I used to use my @ubuntu.com, but I think it's overrated unless you're explictly pushing changes form ubuntu.
[14:52] <vish> shadeslayer_: change the lp timezone and then login :)
[14:52] <vish> shadeslayer_: then you can switch back once you login ;)
[14:53] <DktrKranz> nigelb: I completed my NM process with a @ubuntu.com address, so people shouldn't care about your email :)
[14:53] <nigelb> lfaraone: I'm just lazy actually.
[14:53] <shadeslayer_> vish: yeah i change it when i need to edit the wiki... which was just once to add myself to the delhi teams list
[14:53] <nigelb> all the defaults is set to @ubuntu address - I painfully did that last week, I dont want to duplicate the work again
[14:53] <shadeslayer_> nigelb: how is the interface?
[14:53] <vish> shadeslayer_: dont logout of the wiki , it should work fine
[14:54] <shadeslayer_> (of the ubuntu mail)
[14:54] <shadeslayer_> vish: hmmm ok :)
[14:54] <DktrKranz> tseliot: try to build it to see if it actually works, keep in mind you have to use a chroot *without* quilt installed, or it gets fooled
[14:54] <Laney> there is no interface, it's just a forward
[14:54] <vish> shadeslayer_: there is no interface , it is just a dummy id to forward
[14:54] <nigelb> shadeslayer_: its only a re-direct
[14:55] <shadeslayer_> nigelb: ah.. so it redirects any mail to @ubuntu.com to your usual id... nice!
[14:55] <vish> for some reason my id doesnt work :/
[14:55] <shadeslayer_> i want one! :P
[14:55] <nigelb> vish: what happens?
[14:56] <vish> nigelb: the mails just fail ;p
[14:56] <nigelb> vish: do you test from your gmail ID to your ubuntu ID? that would fail
[14:56] <tseliot> DktrKranz: it's using gtg_0.2.3.orig.tar.gz (shall I make a new tarball?) and it still complains: http://pastebin.ubuntu.com/396206/
[14:57] <vish> nigelb: i tried from yahoo and gmail to ubuntu too but still it has the problem , my main id is yahoo though
[14:57] <vish> nigelb: we are off topic here ;)
[14:57] <nigelb> vish: yeah join #launchpad
[14:57] <persia> very :)
[14:58] <bdrung_> persia: you picked me as example? was it by hazard or are there so few devs using @ubuntu.com for Debian work?
[14:58] <DktrKranz> tseliot: weird, did you use quilt shell to generate patch?
[14:58] <DktrKranz> if so, it shouldn't fail
[14:58] <persia> bdrung_: It's because I happened to be looking at one of your debian changelogs earlier in the day.
[14:59] <tseliot> DktrKranz: I did a quilt edit filename for each file
[14:59] <bdrung_> persia: of which package?
[14:59] <DktrKranz> yeah, that should be enough anyway
[14:59]  * persia checks history
[14:59] <DktrKranz> I'll have a look this evening too, now I'm unable to check
[15:00] <tseliot> DktrKranz: ok, thanks
[15:00] <persia> bdrung_: Looks like audacity was the one.
[15:01] <bdrung_> persia: the package with the highest popcon stat...
[15:04] <persia> Indeed.  Uploading that was the worst TIL I've had.  It came to my attention because of the export-by-track bug that doesn't appear to be fixed in lucid.  Are you syncing, or have you?
[15:10] <bdrung_> persia: bug #517858
[15:10] <bdrung_> persia: i assume the syncing problem is fixed
[15:10] <persia> syncing problem?
[15:11] <bdrung_> sync a -2 of an .orig.tar.bz2
[15:12] <persia> Ugh.  Just upload it then.
[15:13] <persia> You'll have to mangle the .changes file, and sign it separately, but that oughtn't be that hard.
[15:13] <persia> I think there's even a script floating about that does some of it.
[15:13] <bdrung_> persia: yes, and this script had a bug
[15:14] <persia> That script has lots of bugs, and shouldn't be used in most cases.  Still, it's a reasonable guide to mangling the .changes file.
[15:18] <lfaraone> bdrung_: by the way, thanks for ACKing all my sync requests :)
[15:18] <mok0> persia: I'd like to change the arch on my netbook OS from "lpia" to "i386". Is there a way to do that without re-installing? What I'm wondering is if you could change dpkg's understanding of what the arch is
[15:19] <bdrung_> lfaraone: you're welcome.
[15:20] <persia> mok0: I don't know of any good way to do it without a reinstall.
[15:20] <mok0> persia: Hm. Dang
[15:21] <mok0> persia: My impression is that lpia and i386 should be compatible
[15:21] <persia> kinda.
[15:21] <persia> The ABI may differ in some respects due to differences in the toolchain, but that's about it.
[15:21] <mok0> persia: different compiler optimization flags, right?
[15:22] <persia> different triplet
[15:22] <mok0> persia: but how does dpkg-* know what the arch is?
[15:22] <mok0> persia: it must be set somewhere
[15:22] <persia> I forget.  Check the dpkg-architecture source.
[15:23] <mok0> persia: I did... but got lost in the perl
[15:23] <persia> heh
[15:23] <mok0> persia: just a bunch of regexes
[15:23] <mok0> persia: and I wasn't sure if that was the nexus of that information
[15:25] <persia> mok0: It just asks dpkg --print-architecture, as it turns out.
[15:26] <mok0> persia: Ah, so I can look at old fashioned C code :-)
[15:33] <mok0> persia: it comes from configure.ac
[15:33] <mok0> persia: So what I'd have to do is to compile a customized version of dpkg and hope that I don't trash my system :-)
[15:34] <persia> You could try just installing the i386 dpkg, and see how much that breaks :)
[15:34] <mok0> persia: ... but how can I do that? I am limited to installing lpia packages?
[15:35] <mok0> persia: you mean force it?
[15:35] <persia> Yes.  Since you're going to break your system anyway (backup first), installing dpkg with --force-architecture can only save you compilation time.
[15:36] <BlackZ> persia: a package where an adding-dependece has been requested can be appropiate for an FFE? (the dependence introduces a new feature).
[15:37] <persia> BlackZ: Could you rephrase?  Also, why ask me?  I'm not a release person.
[15:38] <BlackZ> bug #533799
[15:45] <ScottK> BlackZ: That's a bug, no FFe needed.
[15:54] <mok0> persia: you are running karmic on your poulsbo machine, right?
[15:55] <persia> mok0: No.  I'm running something half-way through jaunty and letting it gather dust.
[15:55] <persia> It just doesn't work for me.
[15:56] <persia> lifeless was trying to hack in some support a couple weeks ago.
[15:56] <mok0> persia: oh? My mini-10 runs jaunty just fine
[15:56] <persia> Yeah, I bet I could run jaunty, but it's just not a nice machine in other ways.
[15:56] <mok0> persia: I see.
[15:56] <persia> Looked better at the shop than in real world use.
[15:56] <persia> (Sharp D4)
[15:57] <mok0> persia: the problem with jaunty is that the developer tools are utterly broken
[15:57] <persia> mok0: Doesn't surprise me.  I think that was when lpia-wrapper got introduced.
[15:58] <mok0> persia: I think it was when LP was upgraded at some point
[15:58] <persia> But I don't know that anyone spent a lot of time developing *on* lpia, so much as theoretically *for* lpia.
[15:58] <mok0> persia: I use it
[15:59] <persia> I know, but I think you started to use it after most of the active porting work stopped.
[15:59] <mok0> persia: ubuntu-dev-tools has introduced a very ,very, very long chain of dependencies
[15:59] <persia> Or at least after I stopped doing active porting work, but I think I was one of the last ones doing it.
[15:59] <persia> heh.
[15:59] <mok0> persia: I tried chasing it down the other day, and after about 10 packages I ran into a major problem
[15:59] <persia> I'd make it longer, but my change was reverted :)
[16:00] <mok0> Hehe
[16:02] <mok0> persia: Also u1 stopped working on it; otherwise I could've told you what package stopped the backporting
[16:02] <mok0> In fact u1 just gives me conflicts everywhere
[16:03] <mok0> I should move to dropbox
[16:05] <mok0> In principle jaunty should be supported, but I don't think anyone cares about it anymore
[16:19] <dpm> dupondje, it seems that the translation issue with g-p-m upstream has been properly fixed now :)
[16:23] <lfaraone> persia: in http://sprunge.us/YKSM (freemind), some of the builds say "build failed", but the build progresses. Shouldn't pbuilder let me know if the build failed? :)
[16:23] <persia> ant is special that way :)
[16:24] <persia> It doesn't break make when it fails sometimes, for reasons I don't really understand in detail.
[16:24] <persia> You might ask in #ubuntu-java : someone might have a real explanation.
[16:28] <nigelb> bdrung_: congrats :)
[16:29] <bdrung_> nigelb: thanks. you are fast.
[16:29] <lfaraone> persia: unrelated, if package 1-1 is in Ubuntu, 1-2 fixes a RC bug in debian, but 2-1 is now in Debian (which introduces a NUV), can we sync the superseded version 1-2? (it does not seem to be in testing or unstable at this point)
[16:29] <nigelb> hehe :)
[16:29] <dupondje> dpm: yea indeed :)
[16:30] <persia> lfaraone: If it's not in an active Debian repository, I believe we can't really sync, but double-check with an archive-admin.
[16:31] <ScottK> lfaraone: No.
[16:31] <persia> lfaraone: You can probably fake it though, if you need.
[16:31] <lfaraone> persia: specifically, the package is http://packages.debian.org/changelogs/pool/main/m/modest/current/changelog , Ubuntu has 1.0+svn1091.debian-3, latest is 3.90.4-1, and the one we want is 1.0+svn1091.debian-4
[16:31] <dpm> dupondje, thanks for tracking it down and reporting it!
[16:31] <persia> lfaraone: Or cherrypick the patch.
[16:31] <lfaraone> persia: oh? how's that?
[16:31] <ScottK> If you can find the relevant changes, just upload them to Ubuntu.
[16:31] <lfaraone> oh, mk.
[16:31] <dupondje> dpm: nope :) it was just annoying me, so I fixed :p
[16:31] <lfaraone> thanks, I'll put a bzr repo later today.
[16:31] <dpm> dupondje, yeah, that's the spirit :)
[16:32] <dupondje> dpm: thats the power of linux, if something is broke in Windows, you can just watch and cry :p
[16:32] <dupondje> on linux you get the source and fix
[16:32] <dpm> indeed
[16:34] <dupondje> maby i'll fix some more bugs If I see something annoying
[16:34] <dupondje> the status messages are still in english
[16:34] <dupondje> but they come right from DeviceKit-Power, which is untranslated
[16:45] <\sh> hmmm...how would you write the debian/copyright file, when you don't know who the upstream author is, but copyright holder google inc?
[16:46] <\sh> ok...got the answer from google-perftools ;)
[16:46] <persia> \sh: Skip "Author(s)" :)
[16:47] <persia> Heh.  That works too.
[16:47] <persia> Sometimes code.google.com has histories that can be informative as well.
[16:47] <nixternal> google is evil, use bing!

[16:48] <Laney> I don't think you actually need the author with DEP5, do you?
[16:48] <\sh> persia: Authors: Google Opensource Developers <opensource@google.com> ;)
[16:48] <Laney> Just Maintainer and copyright holder
[16:49] <Laney> Maintainer is even optional :)
[16:49] <persia> Well, it's also good to have original authors for jurisdictions in which the original author retains "natural rights" to the code.
[16:50] <persia> ("work for hire" only goes so far in some places)
[16:50] <persia> Not that I'm qualified to have an opinion :)
[16:50]  * Laney is thinking only of pleasing the archive overlords
[16:52] <persia> Laney: You may be amused to read Ganneff's comments on DEP5 (I don't think they are on the DEP site : you may have to track through wiki history from the old wiki page).  Most of the details don't matter from that point of view.
[16:54] <Laney> persia: OK, I just read it, and am now enlightened.
[16:54] <Laney> I thought that the FTP team would have had input...
[16:54] <persia> The FTP team?  You mean ftp-masters?
[16:55] <Laney> yeah
[16:55] <persia> They did.
[16:55] <Laney> re: "Thats why you never heard anything from us"
[16:57] <persia> The point there is that the format simply doesn't matter from that perspective.
[16:57] <persia> (and it doesn't)
[16:57] <persia> The format becomes useful *after* to passes through that process.
[16:58] <Laney> I was viewing it as a recipe to include everything you should
[16:58] <persia> Because if the format is used, and it passes that process, then it is likely possible to rely on that format to extact usefu lstuff.
[16:58] <Laney> of course it requires dilligence to get it all right, and doesn't obviate the need for checking
[16:58] <persia> Right.
[17:09] <nigelb> if a patch works with -p0, how do I get it to work with -p1?
[17:10] <hyperair> nigelb: add a/ and b/ in front of all the paths.
[17:10] <nigelb> we prefer p1 right?
[17:10] <hyperair> you could also get quilt to refresh into -p1 for you
[17:10] <hyperair> yes we prefer p1
[17:10] <nigelb> its cdbs
[17:10] <hyperair> well it doesn't matter what you use as long as the patch applies i think
[17:11] <hyperair> cdbs's simple-patchsys has support for -p0 to -p2
[17:11] <hyperair> quilt needs you to tell it which -p to try (otherwise it'll use -p1)
[17:11] <nigelb> ah
[17:11] <hyperair> dpatch, i don't know. i've never used it much (and i think it's a hack of a patch system anyway)
[17:12] <nigelb> I've never used it either
[17:13] <hyperair> don't start unless you're picking up an old package, i say =p
[17:14] <nigelb> heh
[17:16] <persia> What?  Why do we prefer -p1?
[17:16] <nigelb> quilt likes it
[17:16] <persia> so?
[17:16] <nigelb> plus git spits out p1
[17:16] <persia> so?
[17:16] <nigelb> (thats the answer I got the last time I asked)
[17:17] <hyperair> dpkg-source v3 likes -p1
[17:17] <persia> If you have a patch, apply the patch to the sources however it needs.
[17:17] <persia> Use the standard tools to apply the patch.
[17:17] <persia> Then you get a good result.
[17:17] <nigelb> ok, this might sound dumb, but how do I apply a patch with cdbs
[17:17] <nigelb> I never worked with an actual patch with cdbs
[17:17] <hyperair> cdbs-edit-patch
[17:17] <nigelb> I did that
[17:17] <nigelb> how do I access the patch file now/
[17:17] <hyperair> it's in debian/patches
[17:17] <persia> edit-patch should work in most cases (file bugs if it doesn't)
[17:18] <nigelb> no, you didn't get me
[17:18] <persia> So edit-patch, then apply whatever you have however you must, then exit.
[17:18] <persia> And you end up with it in the right format for that package.
[17:18] <nigelb> I have a simple patch file which I need to apply with cdbs
[17:18] <persia> We shouldn't care about patch -p levels, but rather use that preferred by the tool.
[17:18] <nigelb> so I do cdbs-edit-patch and now how do I access the patch that has been submitted?
[17:19] <persia> nigelb: Then use edit-patch (or cdbs-edit-patch if you must), apply it however, and exit, watching it magically appear in debian/patches.
[17:19] <nigelb> persia: its the apply step.  I can't find the patch inside the subshell
[17:19] <persia> nigelb: Did you save the submitted patch somewhere?  If so, cp it.  If not, wget it.
[17:19] <nigelb> I have it in the same folder as the source
[17:20] <nigelb> but when I do patch -p1 ../<patch-name>
[17:20] <nigelb> I can't find it
[17:20] <persia> For instance, I usually do cp /home/persia/src/scratch/${PACKAGE}/foo.diff .
[17:20] <persia> (or sometimes patch -p? < /home/...
[17:20] <nigelb> ugh, painstaking ;)
[17:23] <persia> nigelb: You can also just wget it into the subshell, usually.
[17:23] <nigelb> persia: I'd rather patch -p1 < /home...
[17:25] <persia> But that would be *wrong*
[17:25] <nigelb> oh, it is?
[17:25] <persia> Oh, sorrt.
[17:25] <persia> Yeah, that's right.
[17:25] <nigelb> wait, what I'm doing is right or wrong?
[17:25]  * persia first read it as /home/...$ patch -p1 < ../patch
[17:25] <persia> What you're doing is right.
[17:26] <nigelb> ;)
[17:27]  * nigelb goes to do patch tagging
[17:32] <dupondje> dpm: Can you find the patch in the gnome-power-manager git ?
[17:33] <dpm> dupondje, hmm, I hadn't had a look actually, I just read the messages in the thread. I noticed that the translation template was not updated in l10n.gnome.org, though. Let me see...
[17:36] <dpm> dupondje, it seems it hasn't been pushed yet -> http://git.gnome.org/browse/gnome-power-manager/log/ I think the commit id given in the bug might be a local commit
[17:36] <dupondje> the bug is marked as 'fixed' but its not fixed imo :)
[17:37] <nigelb> what is csd in the context of gtk+?
[17:43]  * persia idly recommends #ubuntu-desktop for gnome-power-manager discussion, as lots of folk there don't idle here but may be interested.
[17:44] <nigelb> anyone has clues to what bug 528017 means?
[17:44]  * nigelb pokes ubottu 
[17:44] <dupondje> put a # before it :P
[17:44] <nigelb> generally not needed
[17:44] <nigelb> bug #528017
[17:45] <nigelb> gah, bot lag
[17:48] <dupondje> it died :(
[17:48] <dupondje> :)
[17:49] <nigelb> dupondje: a slight lag, someone's working on the system, will be back soon I guess
[17:50] <dupondje> outch, doing bug report with apport, canceling it, and it crashes :)
[17:51] <dupondje> apport-bug apport :p
[17:52] <hyperair> it died and a smiley? what a sadist
[17:52] <hyperair> =p
[17:53] <nigelb> I love the new apport patch which lets you add to a report via apport-collect only if you reported the bug
[17:56] <dupondje> [177228.372691] yelp[28182] trap int3 ip:7fd9dc7c8bc2 sp:7fff6c2f1c20 error:0
[17:56] <dupondje> stupid yelp :)
[18:56] <shadeslayer> hi i created this : http://pastebin.ca/1842668 : but when i put 1 1,it should print a and its printing r
[18:58] <shadeslayer> um wrong channel :P
[20:16] <siretart`> bdrung_: congrats!
[21:41] <bdrung_> siretart`: thanks
[21:56] <dupondje> dpm: now its fixed :P
[22:54] <arand> For a branch proposed for merging, is it normally ok for anyone to add a comment in the review thingy, or is comments other than reviewer's comments frowned upon?
[23:02] <geser> If you have something to add, please add it. That way the proposer has a chance to update the branch if necessary before a dev looks at it.
[23:08] <arand> geser: What I had in mind was commenting on https://code.edge.launchpad.net/~lielft/ubiquity-slideshow-ubuntu/games-slide/+merge/15545 that maybe "use wine to run you windows games" might be a bit to optimistic of a statement to be in such an "official" place, that's relevant?
[23:40] <geser> arand: don't know, but if you think it's relevant, please add it. The reviewer will either take your comment into account or ignore it if he feels it's irrelevant.
[23:41] <arand> yea, fair enough I guess.