[02:17] <shadeslayer> hi,i would like a mentor for training me
[02:18] <shadeslayer> ah looks like the mentor program is being revamped...
[03:41] <micahg> lfaraone: I'm going to try to clean up the pyjamas situation
[05:16] <lfaraone> micahg: cool, thanks.
[05:16] <micahg> lfaraone: I'll subscribe you to the new bug I'm going to make if you want
[05:19] <lfaraone> micahg: that'd be awesome. I'm about to zzz, so I'll see you tomorrow. :)
[05:19] <micahg> lfaraone: k
[06:17] <diwic> I'm considering packaging four small upstream apps into one deb, should I 1) unpack all upstream sources and repack them as one and considering that my original tarball or 2) just pack the upstream sources into an additional package and unpack the upstream sources during the build process?
[06:19] <micahg> diwic: why not package them individually?
[06:20] <diwic> micahg: because they are so small, and strongly related to each other
[08:24] <geser> dupondje: re qmail FTBFS: not all targets are called as root: "The build target must not do anything that might require root privilege." while "The binary targets must be invoked as root."
[08:26] <geser> dupondje: you might fix it by re-arranging the targets a little bit in debian/rules: make the build target don't depend on binary-src but instead make binary-indep depend on binary-src instead of build
[08:48] <lool> bdmurray: I only merged the testing version; the unstable version would be needed indeed
[08:48] <lool> bdmurray: sorry, ENICK
[09:12] <loneowais> hey everyone.... have some question about getting started with devel and packaging
[09:13] <loneowais> first of all... a linux program is scattered all across the filesystem.. to /usr/bin and /usr/share etc
[09:13] <loneowais> unlike windows where almost everything stays in one directory
[09:13] <loneowais> how do i lay out my project?
[09:14] <loneowais> do i create local bin and share directories
[09:14] <loneowais> i've not seen anyone do this
[09:14] <geser> !FHS
[09:14] <loneowais> ubottu: i know that
[09:15] <loneowais> oh
[09:15] <loneowais> lol
[09:15] <geser> :)
[09:16] <loneowais> so.. when i start writing my app.. how do i layout my source files
[09:16] <loneowais> also
[09:16] <loneowais> while packaging... all examples show hello world or something
[09:16] <loneowais> how do i generate the .dsc and other files when packing a new app... say my own app.i wrote from scratch
[09:17] <geser> how your organize your source is up to you
[09:18] <loneowais> ok... so then how does everything end up in /usr/share and other directories
[09:18] <loneowais> i mean
[09:18] <loneowais> when converting from source to deb
[09:19] <loneowais> how does the debuild or any packaging system know what file to keep in share and what in lib
[09:19] <loneowais> how to mention that
[09:19] <dupondje> How can I request a new package into universe? An update of another package is now depending on libopensync-plugin-vformat, but thats not in universe yet ...
[09:19] <oojah> loneowais: Typically all packages have a makefile which determines how it is built.
[09:19] <geser> the most part of it does your Makefile (which can also be used by others)
[09:20] <oojah> loneowais: It will also provide a way to install files to the appropriate locations.
[09:21] <geser> build a deb mostly involves: installing the build-dependencies, apply patches if needed, build using the upstream Makefile, install using the upstream Makefile into a stage directory, build the debs from that staging directory
[09:21] <loneowais> oojah: hmmm
[09:21] <loneowais> oojah: so deb packager read the makefile and decides
[09:23] <oojah> loneowais: The deb build scrC[C[C[C[C[C[C[C[C[C[C[C[C[C[Cipts will run the Makefile to create the binaries and then install them into the .deb.
[09:23] <oojah> Ooops, I don't know what happened there.
[09:24] <loneowais> ok.. will look into it deeper
[09:24] <loneowais> also
[09:24] <loneowais> suppose i'm writing an app from scratch
[09:24] <loneowais> a new one...
[09:24] <loneowais> how do i generate the files required for building
[09:25] <oojah> loneowais: My recommendation would be to not worry about deb or other packaging quite yet - get your project started and building and go on to that later.
[09:25] <tumbleweed> dupondje: before debian import freeze, it should come in by itself, afterwards, a sync request works
[09:26] <dupondje> tumbleweed: ok :) lets hope its gets here fast :D
[09:27] <tumbleweed> dupondje: what is this for?
[09:27] <oojah> loneowais: Or you could try looking at Quickly to get you going: http://bit.ly/404wgL
[09:27] <oojah> loneowais: Quickly will do a lot of what you're asking I think.
[09:28] <tumbleweed> dupondje: according to http://packages.qa.debian.org/libo/libopensync-plugin-vformat.html it's been in debian for a while, so it must have been blacklisted
[09:28] <oojah> Otherwise it's mostly just "write them yourself".
[09:30] <tumbleweed> oojah: or dh_make
[09:30] <dupondje> tumbleweed: http://packages.debian.org/sid/opensync-plugin-evolution
[09:30] <dupondje> for this one
[09:30] <dupondje> newest versions depends on it
[09:31] <tumbleweed> dupondje: you have seen http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580867 ?
[09:31] <tumbleweed> (the excuses for all those packages lead to it as the reason for them not being in debian testing)
[09:32] <oojah> tumbleweed: Yeah, you're right. I'd made the assumption we were still talking about building source not building packages.
[09:32] <tumbleweed> oojah: that's true, but for say a python app there's not much to a setup.py :)
[09:33] <oojah> tumbleweed: You've exposed my unconcious bias towards compiled code :)
[09:34] <dupondje> bleh, without additional comment ...
[09:34] <tumbleweed> you're the one who suggested quickly :)
[09:34] <oojah> :)
[09:43] <tumbleweed> dupondje: anyway, it doesn't appear to be blacklisted (http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt) so I don't know what the problem is
[09:46] <geser> which package?
[09:47] <tumbleweed> libopensync-plugin-vformat
[09:48] <dupondje> geser: http://dupondje.be/qmail.debdiff => like this you mean ?
[09:50] <geser> new (as in not yet in Ubuntu) packages get synced by an other script run by the archive admins, as they review the list of new packages this isn't done very often (compared to auto-sync) and with a long list of new packages it takes some time till the list gets reviewed (which is a cumbersome task)
[09:51] <geser> if you need this package now in maverick and can't wait till it find it's way into maverick on its own, file a sync request
[09:52] <geser> dupondje: yes (if it works), the build dependency in the binary-indep target should get dropped (and it doesn't do anything anyways)
[09:52] <loneowais> right now i'm backing up eveything from /var/cache/pbuilder/build/6999/var/cache/apt
[09:52] <loneowais> manually
[09:54] <geser> loneowais: pbuilder should do it for you (unless you have deactivated it), check /var/cache/pbuilder/aptcache
[09:54] <loneowais> i checked
[09:54] <loneowais> it's empty
[09:55] <geser> do you use pbuilder directly or pbuilder-dist (from ubuntu-dev-tools)?
[09:55] <loneowais> pbuilder
[09:55] <dupondje> geser: it seems to build, but only qmail-src package :s
[09:56] <geser> dupondje: which is correct
[09:57] <dupondje> hmz ok :D
[09:58] <BlackZ> geser: steam FTBFS again?
[09:58] <geser> loneowais: check if you have set APTCACHE to a directory in /etc/pbuilderrc or ~/.pbuilderrc
[09:58] <geser> BlackZ: looks like someone gave it back to the buildd
[09:59] <BlackZ> geser: we should fix it ASAP
[09:59] <loneowais> no
[09:59] <loneowais> nothing is mentioned about any cahce
[10:01] <BlackZ> geser: so adding the flag -wno-stack-protector is dangerous?
[10:01] <geser> BlackZ: see the patch in bug 588519, but I don't know if this change has any other side-effects or not
[10:03] <geser> BlackZ: only in the sense that it disables the stack protection, which IMHO should only be done if nothing else works
[10:03] <dupondje> https://bugs.launchpad.net/ubuntu/+source/qmail/+bug/590343 there it is :P
[10:04] <BlackZ> geser: seems good to go
[10:04] <BlackZ> but I will test the patch
[10:05] <geser> dupondje: could you please also forward it to Debian so we can sync in future again?
[10:05] <BlackZ> geser: if it works I will unsubscribe the ~ubuntu-reviewers team and I will subscribe ~ubuntu-sponsors with a new debdiff generated (I think that'd be correct)
[10:10] <BlackZ> geser: do you think a direct-modify to the interested file would be fine? or we have to include the patch mandatory?
[10:10] <dupondje> geser: i'll do
[10:12] <dupondje> done :)
[10:13] <loneowais> so how do i setup a local cache for pbuilder
[10:13] <toabctl> is there a good guide how to manage a debian package with bzr and launchpad?
[10:37] <BlackZ> geser: ^ http://launchpadlibrarian.net/49761636/buildlog_ubuntu-maverick-i386.steam_2.2.31-6ubuntu2~maverick1_FULLYBUILT.txt.gz
[10:56] <arand> BlackZ: Oh, what do you say about the change there? I just noticed that it worked, but have no idea about it's implications...
[10:56] <BlackZ> arand: I have applied your proposed patch
[10:56] <BlackZ> it works, thanks
[10:58] <BlackZ> arand: looks good
[10:59] <arand> Ok, yea, I tested and saw that it built and installed, but I haven't really used the program, nor know exactly what it's supposed to do. And I have absolutely no idea what my patch *actually* does, so cheers for picking it up and verifying that it is sane :)
[11:00] <BlackZ> arand: I have just renamed it in fix-ftbfs.dpatch
[11:01] <arand> BlackZ: I was looking for an upstream, but it seem like the package is unmaintained in debian as well, so I was kind of out of luck trying to find someone who knew it thouroghly..
[11:05] <arand> It doesn't seems to ftbfs in debian though... hang on... debian builds a deb for all archs instead it seems...
[11:05] <BlackZ> arand: in fact it is a change just in ubuntu
[12:27] <dupondje> thanks to whoever sponsored my qmail fix ;)
[12:30] <sebner> dupondje: LP says it was geser ;)
[12:34] <dupondje> didn't find :P
[12:38] <ari-tczew> sebner: ping
[12:38] <kobrien> hey, any core devs about?
[12:39] <ari-tczew> kobrien: check in #ubuntu-devel
[12:39] <sebner> ari-tczew: I know, I know. I'm a lazy guy. I leave now. Would you mind pinging me again in 8hours? You write a mail, then I promise I'll do it *today*
[12:40] <ari-tczew> sebner: ok I'll send an e-mail to you
[12:40] <sebner> ari-tczew: thx, sorry for the delay
[12:45] <kobrien> ari-tczew: ah, wasn't aware of that. cheers
[12:49] <ari-tczew> can someone open a task on nominated releases @ bug 521659 ?
[13:11] <kobrien> can any of you approve an ubuntu blueprint for me?
[13:11] <ari-tczew> RoAkSoAx: are you interested in fix CVE-2010-0295 lighttpd package? bug 521659
[13:31] <johndescs> hi, i'm a beginner in ubuntu packaging. I'm trying to help with gajim, where I've done a merge from testing.
[13:32] <johndescs> now i'm working on the bugs and one recurent problem is indicator
[13:33] <johndescs> someone posted a patch which applies but now several problems occure
[13:34] <johndescs> - the option has to be translated but i can translate only into my mothertongue
[13:34] <johndescs> - neither me nor the other know how to make the gajim line disappear when someone unchecks the option
[13:35] <johndescs> - no way seem available to integrate easily to indicator-me which has few documentation
[13:36] <johndescs> any hint from gurus here (if it's the right place to ask)?
[13:42] <BlackZ> johndescs: I don't understand your problem
[13:43] <kobrien> I'm packaging a new app. How do I get it approved for Maverick?
[13:43] <johndescs> BlackZ: the first: how can a string be translated when no upstream exists?
[13:43] <BlackZ> kobrien: the best way would be send it to debian then it will be synced in ubuntu as well
[13:45] <BlackZ> johndescs: what do you mean "no upstream exists" ? do you mean no project exist in launchpad or... ?
[13:45] <johndescs> BlackZ: gajim's upstream don't want indicator support, so there is no upstream for the new option we try to get for indicator
[13:46] <BlackZ> johndescs: ah, now it's more clear, I'd say a patch would be sufficient
[13:47] <johndescs> BlackZ: sorry to be ambiguous and yes a patch is OK but I don't know how to call for translators
[13:47] <johndescs> "translations" is greyed out on launchpad
[13:48] <johndescs> bug report of the implementation: https://bugs.launchpad.net/bugs/587272
[13:49] <ScottK> ari-tczew: Dapper is not end of life for servers.  Please do not say it is in bugs for server packages (I'm looking at one you did for lighttpd (which is a web server)).
[13:50] <ari-tczew> ScottK: I know that server support is not end, but it's in universe, so community will fix it eventually
[13:51] <ari-tczew> I wrote: feel free if you are affected
[13:51] <ScottK> ari-tczew: Then why did you mark the bug invalid?
[13:51] <BlackZ> johndescs: if there's a patch somebody from the ~ubuntu-reviewers team will review your patch, but please don't subscribe the ~ubuntu-sponsors team until ~ubuntu-reviewers isn't unsubscribed
[13:51] <ari-tczew> feel free to open *
[13:51] <BlackZ> s/review/review & test
[13:51] <ScottK> ari-tczew: I did, but I'm not subscribed to every bug.
[13:51] <ScottK> ari-tczew: Do NOT close such bugs.
[13:52] <ari-tczew> ScottK: I think that there are not servers using dapper
[13:52] <ScottK> ari-tczew: It's not end of life and there are.
[13:52] <ScottK> I get Dapper related bugs on clamav, so there are users.
[13:53] <ScottK> Even if there weren't, it's not your place to declare EOL for Dapper on servers.
[13:54] <johndescs> BlackZ: is it ~ubuntu-reviewers' role to translate it and make it work better when we don't know how to progress or shouldn't the patch be already almost ready for upload?
[13:54] <ari-tczew> ScottK: can we feel your activity to fix these bugs?
[13:54] <BlackZ> johndescs: it should be already ready
[13:54] <ScottK> ari-tczew: How does that relate?
[13:54] <BlackZ> BTW, I can't help you right now, sorry
[13:54] <ScottK> ari-tczew: I'm marking on your MOTU app right know that you knowing mark bugs inorrectly.
[13:55] <johndescs> BlackZ: Ok will hope not to do wrond things ;)
[13:56] <ari-tczew> ScottK: hmm, it's very interesting. I've explained with jdstrand support for packages in dapper. There are an UCT. It's got a file called dapper-supported.txt. If package doesn't exist in this file, I can close bug.
[13:57] <ScottK> ari-tczew: That only applies to Main.
[13:57] <ari-tczew> ScottK: nice
[13:58] <ScottK> ari-tczew: Please stop damaging the bug tracker.
[14:00] <ari-tczew> ScottK: I don't damage anything.
[14:00] <ari-tczew> if you're interested in fix this, feel free
[14:02] <ari-tczew> ScottK: you said "damaging" like I did 100000 mistakes on launchpad. calm down. this question with supporting dapper is to discuss
[14:07] <vish> ScottK: hi , could you get someone to triage the kde papercuts? https://bugs.launchpad.net/hundredpapercuts/+bugs?field.tag=kde , we've tagged the bugs , "kde" , should be easier to follow
[14:07] <ari-tczew> ScottK: thanks for comment, love you
[14:08] <ari-tczew> then I think you were always flawless
[14:08] <vish> ScottK: i had asked yofe-l for help there earlier  , but he seems busy :(
[14:08] <ScottK> ari-tczew: There's nothing to discuss.
[14:09] <ScottK> It's still supported on servers.
[14:09] <ScottK> vish: It's ask txwkinger (when he's around).
[14:09] <vish> ScottK: will do , thanks
[14:09] <ari-tczew> ScottK: fine fine, 2 bugs touched and comment like "NOT READY", you're golden
[14:10] <ScottK> ari-tczew: It's not because of the bugs.  It's because of your reaction to my calling you on it.
[14:10] <geser> ari-tczew: it's not about mistakes (everyone does one from time to time) but how one reacts if pointed at them. Don't forget that we all work together as a team.
[14:10]  * ScottK has to go now.
[14:11] <ari-tczew> cya!
[14:15] <BlackZ> geser: have you got the time to check bug #588519 ?
[14:16] <BlackZ> it should be fixed now, there's a proposed debdiff with the arand's patch (proposed) applied
[14:17] <arand> BlackZ: I've asked before. I think both of us are kind of unsure about if the fix is a good one...
[14:37] <geser> BlackZ: although the debdiff looks fine, I still don't know if it doesn't have any unexpected side-effects on the library. I don't know enough about linking to answer this.
[14:38] <BlackZ> geser: thought so
[14:38] <dutchie> BlackZ: did you ever get bug-buddy to build?
[14:38] <BlackZ> dutchie: well, I will work at it tomorrow
[14:39] <BlackZ> BTW no
[14:39] <BlackZ> s/at/to
[16:57] <xteejx> Hey guys, I'm working on converting the patch in bug 589909 into a debdiff. I think aptitude uses a patch system but my debdiff is a small source change and I don't know about patch systems. Is the debdiff ok? It's at http://paste.ubuntu.com/445634/
[17:00] <micahg> xteejx: no, you have to add a new patch w/dpatch
[17:00] <xteejx> micahg: How do I do that? :S
[17:02] <micahg> xteejx: http://www.tuxmaniac.com/blog/2008/01/25/dpatch-just-superb-a-short-how-to/ skip to step 5
[17:03] <xteejx> micahg: So I edit what I want and tell it to make a dpatch from it? That's easy
[17:03] <micahg> xteejx: here's our wiki page on it: https://wiki.ubuntu.com/PackagingGuide/Howtos/Dpatch
[17:04] <micahg> xteejx: yeah
[17:04] <xteejx> micahg: Glad our documentation is full of helpful hints lol ;)
[17:04] <xteejx> Thanks though I'll get on it :)
[17:06] <micahg> xteejx: k, thanks
[17:12] <xteejx> How do I do the M-G on the keyboard in nano to go to a line?
[17:12] <xteejx> line number*
[17:12] <xteejx> don't worry M=Alt :)
[17:41] <xteejx> Question: If I'm only making up diffs/debdiffs does signing the package matter since it's only local?
[17:42] <Laney> no, it doesn't matter unless you are distributing it
[17:42] <xteejx> bug 589909, I have subscribed sponsors, anything else need to be done?
[17:42] <xteejx> Laney: That's cool thank you :)
[17:42] <Laney> xteejx: forward it to Debian please
[17:42] <xteejx> With the debdiff?
[17:43] <Laney> a patch against their vcs would be best
[17:43] <xteejx> vcs??
[17:43] <Laney> otherwise a debdiff against the latest version in debian
[17:44] <cody-somerville> no
[17:44] <xteejx> well its against the maverick version of aptitude I assumed that would be enough?
[17:45] <Laney> don't assume, check
[17:45] <xteejx> I'm new to this :(
[17:45] <Laney> but at least the changelog entry won't be right for Debian
[17:46] <Laney> cody-somerville: what does "no" mean? If you think I'm giving incorrect advice then please correct me properly
[17:46] <xteejx> oh I didn't realise I had to do it for Debian
[17:46] <cody-somerville> Laney, I said no first.
[17:47] <Laney> I don't know what you were saying no to
[17:47] <cody-somerville> Laney, so I think we were giving the same answer to xteejx's question.
[17:47] <Laney> oh, it appeared out of order
[17:47] <xteejx> It did here too :)
[17:47]  * cody-somerville is on crappy hotel wifi.
[17:47] <xteejx> Sorry if I ignored it
[17:49] <Laney> wow, nobody has merged aptitude in a long time
[17:49] <xteejx> The version of aptitude in Maverick is 0.4.11.11-1ubuntu10, Debian sid is 0.6.2.1-2 ermmmm isn't it WELL out of date anyway?
[17:52] <xteejx> Am I missing something here?
[17:52]  * xteejx is confused
[17:53] <Laney> those versions are right
[17:54] <geser> 0.4.11-1 got uploaded to Debian unstable on 2008-11-20, the next version which went into unstable was 0.6.0.1-1 on 2009-10-25 and only 0.6.1.5-3 made it into testing on 2010-03-23 (don't forget lucid synced with testing)
[17:55] <geser> so it doesn't look that bad
[17:55] <xteejx> So if there's going to be a merge for aptitude the patch is probably irrelevant?
[17:56] <geser> depends if it's still an issue or not
[17:56] <xteejx> I see :) So when will the merge happen?
[17:57] <xteejx> I think I'll leave that bug report and come back to it at a later date, there is a debdiff for it anyway but my head is hurting now lol :P
[17:58] <Laney> all you need to do is set up a Debian chroot and then reproduce the bug there
[17:58] <Laney> and if you can then submit the patch to the BTS
[17:59] <geser> xteejx: depends on how long you will need to prepare a merge :) (if you are interested in merging it of course)
[18:01] <xteejx> Laney: When I learn how to hehe :)
[18:01] <xteejx> geser: I don't know, I'm taking MOTU stuff a step at a time
[18:01] <xteejx> Don't get me wrong, I would love to started really getting involved, but I get headaches easy ;)
[22:57] <arand> Does anyone have some time over to sponsor Bug #581331 (sru:s, in order that we can restore functionality for msn...)
[23:06] <Laney> arand: yeah alright
[23:07]  * arand hugs Laney 
[23:13] <Laney> good job it's quick to build
[23:27] <Laney> arand: done, thanks for your contributions
[23:27] <arand> Laney: Cheers!
[23:29] <Laney> it would maybe have been better to try and use the "patchsys" that the package has already, but I don't think it's a big issue since it's a weird one anyway
[23:41] <arand> Laney: Hmm, well, I looked into that, and that patches is simply called by debian/rules, after the compilation steps it seems, and I though that it might've simply been stuck in there manually, thus it made litte sense for me to try to shove this into there in some arbitrary way as well, but I don't know if it's just an odd patch system, which I didn't figure out?
[23:43] <Laney> arand: You would have stuck the diff in debian/patches and then added a patch line in the rules file
[23:45] <arand> Yea, I tried that, but when I saw that I wouldn't be able to place it just in the same place as the other one, I figured it would be better to just use patchless. I asked here before, and was pretty much told to do either, with little preference.
[23:46] <arand> But if policy is policy, I should've gone with that still?
[23:48] <Laney> I think it is probably slightly preferred, but like I said it shouldn't matter
[23:49] <arand> Ok, just making sure I'm on the right track.