[00:00] 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? === cpplogger is now known as apachelogger [00:13] ramiro, it depends on a few things [00:14] ramiro, firstly, the presence of an orig tarball with proper naming [00:14] 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] 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] 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] 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] oops, wrong reference, that was meant to directhex [00:17] ah, so that's what a native package is... [00:19] 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] ramiro, right. [00:21] directhex: thanks, that made things much clearer. [01:55] "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] ramiro: Could you give a little more context? [01:56] oops, I cut out the most important chunks of the paste. [01:57] "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] Oh, that's just because there's no override files in your archive. [01:58] You can ignore that if you're not using overrides. [01:59] great, but is there any way to supress the message? it prints even with -q [02:00] sure, I could 2>/dev/null, but I'd rather have the other error messages if they do exist. [02:00] Use overrides? Don't use apt-ftparchive on sources? [02:02] if you don't use overrides at all, I think its totally quiet about them, from memory [02:03] For binaries, I'm sure that's true. I'm less sure about sources. [02:04] if its not true, you could patch it [02:04] it only prints for the sources, not for "packages" nor "release" [02:21] 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] what-patch will tell you what patch system the package is using, and edit-patch will Do The Right Thing (I think) [02:25] psusi: Run `what-patch` for a best guess. Run `edit-patch` to use automation to guess the system. [02:26] hrm... quilt eh? hrm. I thought that was an RCS [02:28] 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] psusi: /usr/share/doc/quilt/README.source has some guidance on usage. [02:29] !patchsystems [02:29] !patch [02:29] Patches are files describing the changes in code to achieve some results. There are a number of ways these can be produced, but https://wiki.ubuntu.com/Bugs/HowToFix and https://wiki.ubuntu.com/PackagingGuide/PatchSystems may provide some useful guidelines. [02:29] The PatchSystems page has some more [02:53] 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] krisives: We already have boost. [02:54] 1.40 is our default for the next Lucid release. [02:55] it comes on the CD? [02:55] I'm not 100% sure. OOo uses it. [02:55] It is in Main, so it's not a problem. [02:56] 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] krisives: Ubuntu also produces DVD images [02:56] krisives: The core distro will stay CD sized. [02:56] Any idea how big boost is ? [02:57] 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] I see, thanks persia :D [02:57] You're everywhere! [02:58] 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] or is that not possible because of it being an LTS? [02:58] 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] Some don't have any runtime depends at all, just build time. [02:59] 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] Thanks for the help guys [03:00] StevenK: large, but broken into many little bits. [03:00] persia: Yes, I'm adding the little bits together [03:00] krisives: Potentially the biggest issue will be to keep so you can build with the newer versions. This is sometims non-trivial. [03:01] But the key bit is that the vast majority of clients only need some of the little bits. [03:01] yeah we're looking at it right now to see what we depend on in terms of boost [03:04] There. http://paste.ubuntu.com/395942/ [03:05] Don't look too close, your eyes will bleed [03:05] That goes with the territory with boost. [03:06] How cute, it even follows the units policy. [03:06] 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] The nice thing about boost is that building it is a nice stress test for memory management systems. [03:06] I just did some grepping for #include related to boost [03:06] I think that's all core [03:07] StevenK: One of these days you need to learn awk :p [03:07] persia: I'm going to keep my tr and sed skills and love them. So nyah [03:07] I actually did that with the Search feature :( [03:08] oh btw we finally are documenting our API [03:09] and the switch from C to C++ has made plugin development sane with a clean abstraction [06:04] fabrice_sp: should there really be a debian/gbp.conf file? [06:06] jayvee, sorry? [06:06] fabrice_sp: I'm working on the tahoe-lafs package. Working on cleaning it up like you gave me pointers. [06:06] Just found this 'gbp.conf' file, which is kinda weird [06:07] it starts with [git-buildpackage], and it has karmic hardcoded in it [06:07] although I didn't think it was versioned in git [06:07] so that leads me to think it's just cruft [06:07] seems like it, yes. Let me check where it can come from [06:08] (or you can ask original packager) [06:09] you're right: it seems to be some git configuration file [06:10] "Git-buildpackage can be configured in a per-repository .gbp.conf, which must not be included in the package sources." [06:11] taken from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501243 [06:11] Debian bug 501243 in git-buildpackage "git-buildpackage: please support `git config` options instead of .gbp.conf" [Wishlist,Open] [06:12] jayvee, ^ [06:21] fabrice_sp: I guess I'm wondering, is it safe to delete? [06:33] jayvee, yes :-) [06:33] cool [06:56] 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] hi .. after i debuild -S -k [07:18] i dput to my ppa .. but it not uploading the source file .. [07:18] why its happend and how to counter it ? [07:20] ejat: What error do you get? [07:20] ejat: what do you mean 'not uploading the source file'' [07:21] lifeless: yes [07:21] persia: no error [07:21] http://paste.ubuntu.com/396008/ [07:22] good morning [07:22] morning [07:22] ejat: What's missing? [07:23] Unable to find dbmail_2.2.15.orig.tar.gz in upload or distribution. [07:23] Oh, you want -sa then. [07:23] ejat: Craft your .changes using -sa [07:23] previously if i do the dput .. it will upload the source [07:23] StevenK: debuild again with -sa ? [07:23] not with -S [07:24] ejat: Both [07:24] debuild -S -sa [07:26] * ejat trying .. [07:27] 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] StevenK: i just redo using -S -sa .. but then .. im getting this http://paste.ubuntu.com/396010/ [07:29] ejat: you need to remove a upload file [07:29] wzssyqa: how to remove .. its not visible at launchpad [07:29] in the same dir with orig.tar.gz [07:29] ejat: it is used by dput [07:29] ejat: just del it [07:31] ejat: or you can increase your version in changelog [07:31] wzssyqa: i follow here https://help.launchpad.net/Packaging/UploadErrors :) [07:32] delete the log [07:32] thanks StevenK its work ... upload with the source [07:37] how do i build for karmic if inside the changelog already build for lucid ? [07:38] Change the changelog [07:38] (or mangle the .changes file between creation and signing, but this may require other hacks, and may break things) [07:40] just change the changelog .. then rebuild it back .. [07:41] is it will conflict the source file that i already upload ? [07:41] or can i just copy the binary from lucid to karmic ? or is it not recommended [08:02] ejat: use "debchange -i" [08:03] and on the top changelog entry, just change lucid to karmic [08:03] and add a ~ppa1 at the end of the version that it puts on [08:03] owk ok .. so it will be karmic~ppa1 [08:03] nope [08:04] put a ~ppa1 on the end of the version [08:04] so if the version is 1.0-2ubuntu5 [08:04] owh ok .. get it [08:04] make it 1.0-2ubuntu5~ppa1 [08:04] ok .. [08:04] 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] persia: last time I read the docs they used ~ppa1, but that was a long time ago [08:05] Yes, it was changed. [08:05] ejat: depends on whether you want the package to be available to karmic or lucid users [08:05] 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] at least I think so [08:05] ok thanks jayvee n persia [08:06] 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] 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] or +ppa1~karmic, as persia points out [08:07] persia: so i better do the copying :) [08:31] 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] ejat: Missing build-dependencies. Did you try with pbuilder or sbuild first? [08:33] how to edit 'LINKFLAGS' to add version to the end of .so file? [08:36] owh .. forget .. persia .. so i need to test it with pbuilder then if ok .. then upload to ppa ? [08:37] make: dpatch: Command not found [08:37] That's usually easier to track down, because it's local. [08:37] persia: ic .. so its miss the dpatch ? [08:39] Something like that. [08:46] persia: http://paste.ubuntu.com/396048/ [08:46] added the dpatch in control .. [08:46] but its still occurs .. [08:47] Try adding something like `dpkg -l dpatch` in your rules to make sure it's getting installed. [08:47] Obviously, you need to call this *before* you call dpatch [08:57] persia: so i need to add 'dpkg -l dpatch' before this http://paste.ubuntu.com/396052/ [08:57] No, but doing so may help you track down the issue. [08:58] add just for tracking is it ? [08:58] 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] Nothing here is long-term useful except insofar as it helps you to understand the issue so you can fix it. [09:05] just wanna double check with u for the control file : http://paste.ubuntu.com/396055/ [09:09] shows that i already include the dpatch rite? [09:22] ejat: Build-Depends != Depends [10:53] _ruben: ice cold coca cola [10:53] love it! <3 [10:54] * jayvee wishes he thought of that [10:54] ? [10:54] read his ipv6 address [10:54] heh. [11:00] Is it usual to add Provides: when renaming a binary package? [11:01] I thought they usually just do Conflicts: and Replaces:. [11:01] If there are reverse dependencies, yes. [11:01] For users to be upgraded to the new package [11:01] But it's also usual to provide a transitional package for upgrades. [11:02] Laney: Provides doesn't help with upgrades, it helps with reverse dependencies. Empty transitional packages help with upgrades. [11:02] is this because Provides are unversioned? [11:03] No. [11:04] Provides aren't considered for any upgrade handling. [11:04] alright [11:05] Well, that's not strictly true : it's more complicated. [11:05] 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] persia: I mentioned reverse-dependencies. :) [11:07] 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] 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] duanedesign: Sure. [12:11] duanedesign: That was your cue to ask a more detailed question :) [12:11] 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] OK. What sort of thing do you like to do? [12:13] 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] OK. Some of the things that would be helpful now are patch review, RCbugs, unmetdeps, FTBFS [12:14] Any of those sound interesting, or do you need more definition of terms? [12:14] what are Release Candidate Bugs? [12:15] 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] persia: ahh lol, I shouldnt of asumed i knew what RC stood for [12:16] 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] 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] persia: ok. sounds good [12:18] duanedesign: http://qa.ubuntuwire.com/bugs/rcbugs/lucid/ is the list for lucid. [12:19] 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] persia: ok great! [12:19] Start with the "grave" ones, and then the "serious" once once you've passed through as much "grave" as you can. [12:20] If you don't understand a bug, ask here. If nobody helps you, check the next one :) [12:20] persia: whats a cherrypick? [12:21] duanedesign: just get the particular patch that fixes the bug into ubuntu :) [12:21] if the package uses a patch management system like quilt, it might be easy to figure out the patch [12:22] 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] ok i know what a sync is, that is to sync the version in Ubuntu to match upstream. Whats a merge? [12:24] 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] tseliot: Because it's source format 3.0. Just dpkg-source -x the .dsc as usual. [12:25] 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] 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] 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] Is anybody else having issues with fiordland.canonical.com for requestsync? [12:26] tseliot: You build a source package with `debuild -S` (or similar), which should do the right thing. [12:26] persia: nice. thanks for the tip [12:27] is it a big problem that have a symbol link of share lib that without version [12:27] persia: we don't care about syncing ftbfs fixes on armel, do we? (I don't think we're releasing armel) [12:27] persia: http://pastebin.ubuntu.com/396139/ [12:28] lfaraone: I'd like us to care, because it increases the chances I can upgrade my Netwalker to lucid :) [12:28] tseliot: Are you using lucid to build the source? [12:29] persia: yes, sure [12:29] Did you use quilt to apply the patch? [12:29] hmm... where's keybuk when you want to compliment him [12:29] persia: no, I guess that's the problem. I was hoping to rebuild the source and make a debdiff [12:30] tseliot: Right, but it's format 3.0 (quilt), so you have to apply the patch with quilt. [12:30] Once you've done that, debdiff ought do the right thing. [12:30] persia: ok, I'll do that, thanks [12:31] 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] lfaraone: On armel? [12:33] 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] persia: on amd64 :) [12:33] 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] pbuilder doesn't seem to like it's deps. [12:33] jayvee: man uscan : look for the uversionmangle option [12:33] lfaraone: You have universe enabled? [12:34] persia: awesome! [12:34] opts="uversionmangle=s/-SUMO//" [12:34] works brilliantly [12:35] persia: probably. [12:35] lfaraone: Because I can install fftw-dev on my local amd64 system without issue (just tested). === jcarter is now known as highvoltage [12:37] persia: ah, I was missing htat. [12:40] persia: once I do https://wiki.ubuntu.com/PbuilderHowto#Universe%20support, do I need to rebuild the chroot? [12:40] lfaraone: But don't forget to check for outstanding bugs : bug $538060 may interest you [12:41] Err, bug #538060 [12:41] Launchpad bug 538060 in ams "FTBFS on armel (sync)" [Wishlist,Triaged] https://launchpad.net/bugs/538060 [12:44] is it possible to do uversionmangle and dversionmangle in the same line? [12:44] in the same opts="", I mean [12:45] the man page is suspiciously vague on that matter [12:47] jayvee: Most certainly [12:58] persia: we can't sync packages that depend on iceweasel, right? (we need to merge the changes) [12:59] Check with mozillateam, but that's my understanding. [13:05] persia, would a Provides: iceweasel really be an issue? [13:07] directhex: Check with the mozillateam. I discussed this previously, and I understand there are reasons for the choices made. [13:11] directhex: You can't have versioned provides. I suspect that's at least part of the issue. [13:12] ScottK, oh, yes, there is that [13:13] or from the other point of view, a provides can't fulfill a versioned depends. :) === kamalmostafa is now known as kamalm [13:45] 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] malev: #ubuntu-app-devel [13:46] Um, no. [13:46] malev: What kind of development do you want to do? [13:47] No? [13:47] Pici: #ubuntu-app-devel is for folk developing applications that run *on* Ubuntu, not for developing Ubuntu itself. [13:47] persia: ... to start! I'm a begginer in this area [13:47] persia: Oh, right :) [13:47] malev: OK. What sort of packages interest you? What sort of work might you like to do on them? [13:49] persia: packing python and maybe solving some bugs [13:49] something like that [13:49] OK. That's certainly doable. Have you encountered any bugs that are bothering you now? [13:50] 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] the thing is that the developers wiki are not clear as the bugsquad's wiki. you know, for begginers [13:52] heh. [13:53] So, from your work with bugsquad, have you encountered some bugs in python packages you think you can fix? [13:54] I guess. some at python-numpy, python-matlibplot and gwibber. But I haven't tried [13:54] do we need to sync the new debbootstrap into ubuntu? seems to have a bit of new features and some bug fixes [13:54] Well, give one a try :) [13:55] nigelb: Potentially, or potentially cherrypick. What do you think? [13:55] is there an easier way to convert .diff.gz modifications to debian/patches than my manual method? [13:55] persia: you say: I should encourage to fixing bus first and then trying to join a ubuntu developers team? [13:56] persia: Cherrypick may not need an ffe, but I feel its worth an ffe [13:56] malev: Absolutely. All the teams expect you to have been working as part of them to become a member. [13:56] ie, sync the whole thing [13:56] persia: Oks! thanks!! [13:57] malev: Just ask here when you get stuck, and we'll help you along. [13:57] cool! [13:58] 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] DktrKranz: ping on gtg [14:00] 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] nigelb: That's how "we" becomes "we" :) [14:03] persia: hehe [14:04] tseliot: gtg pong :) [14:04] DktrKranz: I've noticed that you uploaded gtg [14:05] 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] see my last comment in bug #531909 [14:05] Launchpad bug 531909 in gtg "gtg crashed with UnboundLocalError in on_export()" [Low,Triaged] https://launchpad.net/bugs/531909 [14:05] * DktrKranz looks [14:07] tseliot: oh, distutils troubles again... you'll have to patch setup.py to include missing directories [14:07] (I can eventually fix it in Debian and then sync) [14:07] 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] oh, is tarball lacking them? I intended the other way roind [14:08] *round [14:09] DktrKranz: yep [14:09] so, it's a broken MANIFEST.in [14:10] eta for 0.2.4 is ~1w from now, this could be eventually fixed there (after a FFe, of course) [14:11] DktrKranz: if you think the new upstream release is worth a FFE, then sure, let's wait [14:12] tseliot: if it's not, IIRC gtg is already format 3.0 (quilt), adding blobs is allowed and not much difficult [14:13] anyway, I'll point upstream to that, so there's chance to properly fix it [14:15] DktrKranz: blobs are actually html files which quilt sees as blobs *I guess* [14:15] no, it should see them as normal text files [14:15] so I figured [14:15] for images, they're interpreted as blobs [14:16] but new format doesn't care [14:17] 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] aah: "Debian-specific changes are no longer stored in a single .diff.gz but in multiple patches in debian/patches/" [14:20] http://wiki.debian.org/Projects/DebSrc3.0 [14:20] tseliot: Well, kinda. It's more complicated than that, and there are more options, but for this package, yes. [14:21] ok [14:23] 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] heh [14:24] … and actually like you mentioned quilt, quilt did that right from the start. :) [14:24] Don't though be misguided by the naming of the format quilt. It's just similar to quilt but still is different. [14:25] 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] … moreorless. [14:26] Well, yeah. [14:27] * persia carefully ignores the dpkg implementation [14:27] Keeping in mind that they are different things is needed to not get frustrated in cases it (still) behaves differently. [14:27] Rhonda: is there an easily recognized page that details sponsorship process in debian? [14:27] e.g. format 3(quilt) on intention doesn't allow fuzzy patches, which quilt accepted quite readily. [14:27] I only see references to the thing [14:28] 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] or find somone interested in the package who can act like your regular sponsor/mentor combination. [14:28] so, I'm supposed to mail the person [14:28] No, the list. :) [14:28] group of persons. :) [14:29] the documentation is so confusing. it only says, go through sponsorship [14:29] I have someone who would be interested [14:29] trying to respond to a RFH [14:29] nigelb: An RFH bug? reply to the bug. [14:29] 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] I did reply. so what do I do with the package I want sponsorship? [14:30] If the submitter of the RFH is a DD, ask them for sponsoring. [14:30] 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] ah, debdiff, attach to bug - now that makes sense [14:31] why can't it just be written in the new maintainer guide.. sigh [14:31] Because debian is hard core. If you can dig its documentation you are ready for applying to become a DD. :P [14:31] lol [14:32] yeah, you just cut out people who can't find things ;) [14:32] Getting gwibber to debian seems harder than I thought though. [14:33] Rhonda: it's hard by design, or NM is just a copy&paste :) [14:33] nigelb: But it's there already, isn't it? [14:33] Rhonda: gwibber (1.2.0+bzr358-2) [14:34] maybe the person maintaining it in Ubuntu is interested in uploading to Debian instead... [14:34] trying to get gwibber 2 in (which why there was an RFH, coz the thing doesn't work) [14:34] * Laney coughs [14:34] ken? [14:34] I dunno who it is [14:34] it comes under desktop team ;) [14:34] ha [14:35] the desktop team has a lot of DDs too [14:35] Since they're busy people, I thought I'd poke them when I get stuck [14:36] since when did it move to main/ [14:36] since Lucid probably [14:36] the Me Menu and all [14:36] oh, the social from the start stuff eh [14:36] yeah, that works on top of gwibber [14:43] how wicked would be to upload to debian with an @ubuntu address? ;) [14:45] bdrung does it all the time. Other people never do. Matter of taste. [14:45] http://ftp-master.debian.org/new/pinta_0.2-1.html [14:45] what what [14:46] I figure it helps to add to the "giving back" metric. [14:46] thats my idea too [14:46] nigelb: If you want to get someone ranting, just do it. It's always fun. :) [14:46] besides, I'm too lazy to keep changing the values set in bashrc and git ;) [14:47] People will rant either way "Don't upload with @ubuntu" vs. "Ubuntu doesn't contribute to Debian". [14:47] I haven't been flamed yet :( [14:47] nigelb: http://sandrotosi.blogspot.com/2009/11/things-that-make-me-angry.html [14:47] People like ranting. Focus on the work. [14:47] DktrKranz: so, it looks like the 2 html are indeed binaries. See my quilt patch: http://pastebin.ubuntu.com/396202/ [14:47] I recall morph getting counter-flamed quite a lot for that post [14:47] My main idea is people need not say, "Ubuntu does not contribute to debian" [14:47] nigelb: You just said that! [14:48] Rhonda: I'll contribute soon enough to solve that ;) [14:48] nigelb: btw congrats on becoming a member!! are you from India? [14:48] 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] It's not really "ubuntu" anyway, it's me [14:48] Laney: Indeed. [14:48] shadeslayer: lol, I thought you knew ;) [14:49] (well, this also applies for other values of "me") [14:49] nigelb: oh cuz im from there too :) [14:49] shadeslayer: I know [14:49] Anyone know if it's possible to push all git branches and tags with one command? [14:49] vs push --all && --tags [14:50] nigelb: :P oh best of luck for the future :) [14:50] shadeslayer: ty :) === shadeslayer is now known as shadeslayer_ [14:51] kees: did you have a chance to work on bug 538471? [14:51] Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/538471) [14:51] nigelb: oh one last thing can you edit the ubuntu wiki with IST set in your LP profile? [14:52] shadeslayer_: conflicts with wiki [14:52] shadeslayer_: did it say error when logining with open id? [14:52]