[00:00] <persia> ubuntujenkins: The first step is usually to check for a get-orig-source rule in debian/rules or debian/README.source
[00:01] <persia> ubuntujenkins: You may also find some hints in debian/copyright if those are missing.
[00:02] <persia> Are you sure upstream doesn't distribute their source as several modules?  It may be that some modules are unpackaged, and would deserve their own packages.  Also note that it is very rare for anything to be removed from an upstream source except where it has licensing issues: so take care with your modifications.
[00:05] <ubuntujenkins> persia: the readme is useful but either i am miss understanding it or it desn't quite tell me enough. I debian/rules isn't there neither is the copyright. thanks for your thoughts I think contacting upstream may be the best course of action
[00:06] <persia> ubuntujenkins: What?  You can't have a package without debian/copyright.  At which sources are you looking?
[00:06] <persia> ubuntujenkins: Also, upstream is exceedingly unlikely to have any idea what sources are or are not packaged in Debian.
[00:06] <persia> (or any given distribution)
[00:08] <ubuntujenkins> persia: i ment debian packaging http://svn.debian.org/wsvn/debian-tex/texlive2009/#_texlive2009_ is where i am looking (I have it downloaded on my computer)  may be i missed the obvious
[00:10] <ubuntujenkins> persia: found the copyright file
[00:10] <persia> ubuntujenkins: No idea.  I'm not sure how to interpret that VCS.  Maybe try `apt-get source` on the package of interest.
[00:11] <ubuntujenkins> well its worth a look. thanks again persia
[00:11] <persia> ubuntujenkins: One file floating around in there indicates at least XyMTeX and ppower are not distributable, dunno what else is removed.
[00:12] <ubuntujenkins> ok, i think i have lots of files to read
[00:45] <YokoZar> ScottK: new wine1.0 upload (there was some configuration issue that wasn't occurring locally that I fixed)
[00:48] <carstenh> will the ubuntu "m" release replace hardy as supported distribution on ppa?
[00:49] <persia> carstenh: Ask in #launchpad, but I doubt it.  Hardy will probably be supported until 2013
[00:49] <persia> carstenh: Historically, the folks that manage PPAs have allowed PPAs for the releases that are supported in Ubuntu.
[00:49] <carstenh> sounds great :) there is still hope that chromium will hit debian before 2013 ;)
[00:50] <carstenh> ... and hardy ppas work on lenny
[00:50] <persia> kinda sorta.
[00:51]  * micahg thinks dapper is still supported in PPA
[00:53] <RoAkSoAx> heya guys. quick question!! in TestDrive we just included few lines of code that allow us to obtain the Current Devel release codename automatically... and we were wondering if we still can upload it into lucid
[00:56]  * carstenh uses the following as bad hack to get the first char for dapper and later: ubuntu-1st-char () { perl -e 'print chr 64 + $ARGV[0] * 2 - 9 + length $ARGV[1], "\n"' "${1:?y?}" "${2:?m?}" }
[00:58] <RoAkSoAx> ScottK, could I still file a FFe for new upstream of TestDrive that adds a simple, but necessary functionality?
[00:59] <persia> RoAkSoAx: I'd advise filing an FFe for that: it's not clearly bugfix.
[00:59] <persia> RoAkSoAx: You could probably do an s/lucid/maverick/ upload as clearly bugfix though.
[01:00] <RoAkSoAx> persia, ok thanks :) will figure it out asap
[01:00] <persia> RoAkSoAx: Note that someone from the release team may well give better advice than I :)
[01:01] <RoAkSoAx> persia, :) I think that would be better
[01:32] <RoAkSoAx> ScottK, whenever you have some time, please take a look to bug $570485
[01:32] <RoAkSoAx> ScottK, whenever you have some time, please take a look to bug #570485
[01:33] <persia> RoAkSoAx: You do know that there are several other members of the release team, right?
[01:42] <YokoZar> persia: Yes but ScottK is the best ;)
[02:21] <nhandler> kirkland: Any reason for the commented out r = "lucid" line ?
[02:22] <kirkland> nhandler: hmm, i added an inline comment for that
[02:23] <kirkland> nhandler: let me see which rev RoAkSoAx grabbed
[02:23] <nhandler> kirkland: http://launchpadlibrarian.net/45618724/testdrive.diff
[02:23] <kirkland> nhandler: yeah, RoAkSoAx needs to update that
[02:23] <kirkland> RoAkSoAx: ping
[02:23] <kirkland> RoAkSoAx: i made 2-3 minor changes to your merge when i committed
[02:24] <kirkland> RoAkSoAx: including two lines of comments that answers nhandler's question
[02:24] <kirkland> nhandler: to answer your question .... :-)  one sec ...
[02:25] <nhandler> I also don't see a changelog entry in that diff
[02:25] <kirkland> nhandler: http://paste.ubuntu.com/423102/ in 60-61
[02:25] <kirkland> nhandler: yeah, RoAkSoAx's diff is bad
[02:25] <kirkland> nhandler: let me grab one
[02:27] <nhandler> kirkland: In general the changes look fine. Poke me when you have a good diff, I'll review it, and then you can upload
[02:27] <kirkland> nhandler: thanks
[02:27] <kirkland> nhandler: gimme 5
[02:27] <nhandler> Sure thing. I'll be around about 2.5 hours
[02:49] <kirkland> nhandler: http://launchpadlibrarian.net/45627184/570485.debdiff
[02:51] <nhandler> kirkland: I didn't think LP: #XXXXX, #NNNNN would get picked up properly. Did that change?
[02:51] <nhandler> And why do you change an old changelog entry?
[02:51] <kirkland> nhandler: it does
[02:51] <nhandler> cool
[02:51]  * kirkland checks changelog
[02:52] <kirkland> nhandler: oh, hmm, not sure how that old timestamp change snuck in there
[02:52] <kirkland> nhandler: i'll fix
[02:54] <kirkland> nhandler: http://launchpadlibrarian.net/45627355/570485.debdiff
[02:55] <nhandler> kirkland: Go ahead and upload
[02:56] <kirkland> nhandler: cheers
[02:56] <nhandler> :)
[03:04] <kirkland> ScottK: i did make the usb-creator-kde control file change before upload; however, i just realized...
[03:04] <kirkland>                         os.execv("/usr/bin/usb-creator-gtk", ["usb-creator-gtk", "-i", PATH_TO_ISO])
[03:17] <kirkland> nhandler: one more, per ScottK's request: https://bugs.edge.launchpad.net/ubuntu/+source/testdrive/+bug/570509
[03:17] <kirkland> nhandler: debdiff attached, very trivial
[03:49] <RoAkSoAx> kirkland, nhandler upsy sorry about that... seems I attached the old debdiff... and I had to run out :) Anything else I can do to help?
[03:49] <ScottK> imbrandon: I cannot do archive removals.
[03:50] <ScottK> kirkland: Since you got the FFe from nhandler, just upload the correct thing.
[04:03] <YokoZar> ScottK: wine1.0.1-0ubuntu2 waiting for approval, then I should have everything I need from you.  Thanks for being helpful by the way :)
[04:04] <ScottK> YokoZar: It's on my list.  Just got to my hotel a little bit ago.
[04:05] <YokoZar> Oh, are you at the Sprint?
[04:06] <ScottK> No.  I'm in California for a $WORK project
[04:06] <kirkland> ScottK: thx
[04:06] <kirkland> ScottK: done
[04:06] <ScottK> kirkland: OK.
[04:15] <nhandler> kirkland: So is everything ok now? Or need me to look at something else?
[04:15] <kirkland> nhandler: all good ;-)
[04:15] <nhandler> :)
[04:15] <kirkland> nhandler: just waiting for a release-team-aa to approve the uploads
[04:28] <ScottK> There are a few and I'm doing them in the order they were uploaded.
[04:29] <ScottK> kirkland: I am going to go ahead and reject 1.37-0ubuntu1, so don't freak out.  I'll review 1.38.
[04:38] <kirkland> ScottK: just accept both, no?
[04:38] <kirkland> ScottK: so that the bugs get marked as fixed
[04:39] <ScottK> kirkland: Then it builds twice too.  If you use -v on dpkg-buildpackage you can mark bugs fixed for multiple releases.
[04:39]  * micahg would suggest rejecting both and reupload
[04:40] <ScottK> If kirkland wants.
[04:40] <ScottK> micahg: Is seamonkey taken care of?
[04:41] <micahg> ScottK: chrisccoulson didn't get to review today, he said tomorrow
[04:41] <ScottK> Right.  Let's not cut this close or anything.
[04:42] <micahg> sorry, I did what I could, but I don't have upload rights otherwise it would be up tonight
[04:42] <ajmitch> there was noone else who'd be able to review it?
[04:42] <kirkland> ScottK: okay, i can do that
[04:42] <ajmitch> I imagine that being familiar with it would probably be needed
[04:42] <micahg> ajmitch: there was one last thing to test as well and that was the replaces/breaks
[04:43] <ScottK> ajmitch: I really want this upload signed by someone in ubuntu-mozillateam.
[04:43] <ScottK> micahg: How about lightning?
[04:43] <ajmitch> ScottK: that's why I'm not stepping forward to review it
[04:44]  * ScottK nods
[04:44] <micahg> ScottK: I didn't get a final answer, it ended up being a larger mess than I thought, he said if I can't get it ready tonight then we'd probably drop it
[04:45] <ScottK> Probably not a bad idea.
[04:45] <micahg> ScottK: Do you think a backport would work for it?
[04:46] <ScottK> micahg: If what we have is totally broken then it ought to go in proposed/updates
[04:47] <micahg> ScottK: you'd let us SRU a new version?
[04:47]  * micahg checks if it works
[04:47] <ScottK> micahg: I'm not on the SRU team, but working > not working.
[04:48] <micahg> ScottK: oh, why did I think you were on that team...
[04:48]  * micahg will check if it works
[04:48] <micahg> ScottK: the bigger question is whether it's exposed to insecure content and that there are no more planned updates upstream except for lightning
[04:49] <ScottK> micahg: All the more reason to push it in now.  Once they archive is frozen for release, you can't remove binaries anymore.
[04:49]  * ajmitch ought to upload that sdl update to -proposed before it gets forgotten
[04:51]  * ScottK gives didrocks a slap with a dead fish for uploading a 32668 line diff the day before final freeze.
[04:52] <micahg> ScottK: seems to work, but asac didn't seem to like the idea of leaving it in there for Lucid as is
[04:52] <ScottK> micahg: I don't like leaving old dead vulnerable code around either.
[04:52] <ScottK> If it were just up to me, I think I'd upload the newer one, drop sunbird and SRU as needed if you miss a spot.
[04:53] <micahg> ScottK: well, there are actually 2 sources that I'd have to update tonight, lightning-sunbird and sunbird-locales
[04:53]  * micahg sees if I can even pull an upstream tarball
[04:55] <kirkland> ScottK: done, testdrive_1.38-0ubuntu2_source.changes uploaded
[04:55] <ScottK> OK.
[04:55] <ScottK> kirkland: You can reuse the version number if it hasn't been accepted ...
[04:55] <ScottK> It's fine as is, I'm sure.
[04:55] <kirkland> ScottK: i wasn't sure, so i bumped just in case
[04:56] <ScottK> That's fine.
[04:56] <ScottK> stgraber: What's up with this edubuntu-artwork upload in the queue?
[04:57] <nhandler> ScottK: I think he commented on that in -release
[04:57] <ScottK> Yeah, there was some discussion.  I was suprised it was still in the queue.
[04:59] <ajmitch> I don't think there's been anyone accepting uploads for the last few hours
[04:59] <persia> Too many folk concentrated in one place
[05:00] <ajmitch> they all headed off to london?
[05:00] <nhandler> I thought that was usually the week before UDS
[05:00]  * persia gives up on trying to get various non-x86 bioses to build: cross-arch virtualisation will have to wait for maverick
[05:00] <persia> Seems like a bundle of folk tend to gather together during release weeks, at least since ~feisty
[05:01]  * persia wasn't really paying enough attention to know before that.
[05:01] <ajmitch> there's often been a group of them gathering together for the final push
[05:01] <persia> I think a different bundle of folks gather together a week before UDS.
[05:01]  * ajmitch might have to try & get to UDS again at some point
[05:07] <StevenK> ajmitch: There's one in May ...
[05:09] <ScottK> StevenK: Up for some package removals today perhaps?
[05:09] <ScottK> There's still a stack.
[05:10] <StevenK> ScottK: Such as?
[05:10] <ajmitch> StevenK: yes, there is, and it's a little too late for me to get there :P
[05:10] <ajmitch> debian-edu-*
[05:10] <StevenK> ScottK: I'm trying to keep state in my head, currently
[05:10]  * ScottK looks for current status
[05:12] <ScottK> kirkland: Would you please look at bug 562852 and either mark it confirmed or invalid.
[05:13] <ajmitch> iirc likewise-open really does replace it, that should have been confirmed awhile ago
[05:13] <persia> likewise-open also seems to have some degree of upstream support on bug reports, etc. unlike likewise-open5
[05:14] <ajmitch> likewise-open conflicts/replaces/provides likewise-open5
[05:16] <ScottK> StevenK: https://bugs.launchpad.net/~ubuntu-archive/+bugs?field.searchtext=remove&orderby=-importance&search=Search&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.tag=&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me
[05:16] <ScottK> .used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on has 20 bugs that as a glance could use some processing.
[05:16] <ScottK> hooray for sensible urls from LLP
[05:16] <ScottK> LLP/LP
[05:16] <ajmitch> LP needs a builtin URL shortener
[05:16] <persia> https://bugs.launchpad.net/~ubuntu-archive/+bugs_field.searchtext=remov* is the one I use
[05:17]  * persia tries to figure out why the usual trick fails
[05:17] <persia> https://bugs.launchpad.net/~ubuntu-archive/+bugs?field.searchtext=remov* anyway
[05:18] <persia> Aha!  s/?/_/ !
[05:19] <ScottK> persia: I was also just trying to get the ones confirmed or triaged.
[05:20] <persia> https://bugs.launchpad.net/~ubuntu-archive/+bugs?field.searchtext=remov*&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED
[05:21] <persia> What LP needs to do is not bother exposing null things in the URL.
[05:21] <ScottK> Agreed.
[05:21] <ScottK> Would someone please confirm the sugar removal bug too.
[05:21] <persia> But the remov* is required for some of the bugs that have "Request for removal ..." in the title.
[05:22] <ScottK> I'm pretty sure about that, but would rather focus on accepting stuff in the queue.
[05:23] <persia> ajmitch: You acked the debian-edu* stuff: do you want it "Triaged"?
[05:28] <ajmitch> I'll at least file a bug for it for debian, it only affects it with python 2.6
[05:28] <StevenK> ~/
[05:29] <micahg> ScottK: is it crazy to have a 60MB orig tarball for a 3MB binary?
[05:29] <kirkland> ScottK: looks reasonable to me
[05:29] <ScottK> kirkland: Please say so in the bug and mark it confirmed.
[05:30] <ScottK> micahg: Probably, but this is mozilla.  How does sanity figure?
[05:30] <micahg> <2MB binary...
[05:30] <ScottK> ajmitch: He's one of the ones that gets especially grumpy when Ubuntu doesn't 'give back', so yes, please.
[05:31] <ajmitch> persia: sorry, missed your question -triaged would make sense
[05:31] <micahg> ScottK: I'll see if I can make that build easier for the next release, but it seems like it'll be something like that
[05:31] <kirkland> ScottK: done, calling it a night
[05:32] <ScottK> kirkland: Thanks.
[05:43] <ScottK> superm1: Is the mythbuntu-live-autostart something you would consider respinning for?  It looks to me like it should be aimed at -proposed. (I'm glad to hear arguments why that's not correct).
[05:54] <superm1> ScottK, it needs a respin actually
[05:54] <ScottK> slangasek: ^^^
[05:54] <superm1> ScottK, that new ubiquity uploaded today screwed up the UI for a bunch of the pages because of alignment changes
[05:55] <ScottK> OK.  Well we need the boss say about that ....
[05:55] <ScottK> slangasek: I'm off to bed, so I'll leave that one for you.
[05:57] <superm1> (it was the exact same kinds of changes that were needed for dell-recovery that was uploaded today)
[05:58] <ScottK> Right.  I did accept that since it wasn't on any ISO.
[06:00] <slangasek> superm1: which of the changes in ubiquity broke mythbuntu?
[06:01] <superm1> slangasek, it's either r4116 or r4117
[06:01] <superm1> looking closer, r4116 is the one
[06:02] <superm1> any third party ubiquity plugins need to evaluate (and possibly fix) alignment after that
[06:18]  * ScottK notes the archive is still open for fixing unseeded packages ....
[06:19] <slangasek> superm1: how thoroughly has this change been tested?  We basically only get one shot at this
[06:20] <superm1> slangasek, i've tested it from every permutation of the pages i can come up with in a VM (including trying to simulate the extra page that shows up for adding a graphics card)
[06:20] <slangasek> superm1: ok - accepting; apologies for making you scramble, I don't think it occurred to evan or myself that there'd be knock-on effects from the change
[06:21] <superm1> many of the pages are unreadable without it
[06:21] <slangasek> superm1: have you gotten any traction on bug #550100, btw?
[06:21] <superm1> unfortunately not, it's going to have to be an SRU type thing later if anything it looks
[06:22] <superm1> will continue to keep an eye on it though
[06:22] <suji11> hi
[06:22] <superm1> (because there is still a set of problems with that upstream patch)
[06:22] <slangasek> superm1: ok; moving the milestone then
[06:22] <superm1> K, thanks
[06:23] <suji11> my package IOK is now available in lucid, it is the version 1.3.9 i have to update to 1.3.10, how to do that?
[06:25] <StevenK> slangasek: Are you okay for me to process package removals like ScottK is asking?
[06:25] <slangasek> StevenK: yes
[06:26] <StevenK> ScottK: Okay, give me that link again, please?
[06:27] <ScottK> StevenK: https://bugs.launchpad.net/~ubuntu-archive/+bugs?field.searchtext=remove&orderby=-importance&search=Search&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.tag=&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me
[06:27] <ScottK> .used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on
[06:27] <micahg> ScottK: maybe tinyurl would help?
[06:27] <ScottK> micahg: Talk to the launchpad developers
[06:28] <StevenK> ScottK: You could use tinyurl yourself :-P
[06:28] <micahg> bug 317136
[06:28] <slangasek> 'https://bugs.launchpad.net/~ubuntu-archive/+bugs?field.searchtext=remove&orderby=-importancefield.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED' gets you to the same place, but is hand-composed
[06:29] <ScottK> StevenK: I could, but if I put extra effort into avoiding painful aspect of LP, I'd never get anything else done.
[06:30] <StevenK> ScottK: Right, there is more than I was thinking, I'll work through them slowly
[06:30] <ScottK> Thanks and good night.
[07:03] <suji11> Any one help me... my package IOK is now available in lucid, it is the version 1.3.9 i have to update to 1.3.10, how to do that?
[07:07] <andol> suji11: Well, concidering Lucid is well into "final freeze", about to be released... How critical is that update?
[07:08] <andol> suji11: https://wiki.ubuntu.com/FinalFreeze
[07:27] <Rhonda> Oh dear. "The fix for libsdl1.2 will be uploaded into lucid-proposed, for testing after lucid release."
[07:28]  * Rhonda prepares to expect futher duplicate bugreports about that.  %-/
[07:30] <Rhonda> So it seems that mouse clicks in windowed sdl applications isn't considered an important feature. :/
[07:44] <didrocks> ScottK: most of it was updated translation (so, filterdiff should be your friend). Sorry for that :/ The real bugfix is only one line
[08:07] <dholbach> good morning
[09:56] <ajmitch> dholbach: nominations for the membership boards were that low, were they?
[10:02] <callum1> Morning all, I have managed to fix one of the FTBFS packages as my first packaging attempt (thanks to someone here pointing this out). My question is now I have build the package what do I do now? I know someone has to check this for me so looking for help on how to go about this. Thanks
[10:03] <suji11> andol: now the version of IOK in lucid is 1.3.9 but the next version 1.3.10 was released with fix some bugs https://fedorahosted.org/iok/browser/trunk/ChangeLog, i have to update this, how to do that?
[10:05] <dholbach> ajmitch: we just need a few more
[10:07] <ajmitch> callum1: you'll want to attach the debdiff to a bug in launchpad & subscribe ubuntu-sponsors - see https://wiki.ubuntu.com/SponsorshipProcess
[10:08] <joaopinto> aren't we supposed to use bzr merge requests as a replacement for debdifs :) ?
[10:14] <geser> callum1: the FTBFS for osmo?
[10:14] <callum1> geser: yeah :)
[10:15] <geser> callum1: give me a debdiff and I'll sponsor it
[10:16] <callum1> geser: nice one I have only done the changes you suggested and built the package gonna look up debdiff now
[10:22] <callum1> geser: i have a debdiff now how do I go about getting this to you?
[10:23] <geser> pastebin it
[10:25] <callum1> geser: http://pastebin.com/nECeMH2v
[10:27] <geser> callum1: looks like you edited the existing changelog entry instead of adding a new one (dch -i) and your mentioned changes are missing (your debdiff only contains changes to debian/changelog)
[10:28] <callum1> geser: just noticed ill give this another shot and let you know one this is done (thanks for bearing with me :) )
[10:32] <suji11> dholbach: hi
[10:33] <dholbach> hi suji11
[10:34] <suji11> dholbach: my package IOK is in lucid and its version is 1.3.9, but it has some bug https://bugs.launchpad.net/ubuntu/+source/iok/+bug/563635 , the bug was cleared in the source of IOK 1.3.10, i have to update this package in lucid, how  to do that?
[10:34] <dholbach> suji11: https://wiki.ubuntu.com/FreezeExceptionProcess
[10:34] <dholbach> suji11: https://wiki.ubuntu.com/SponsorshipProcess
[10:44] <callum1> geser: I have fixed this now sorry about that here is the new debdiif http://pastebin.com/byZ7Q9CD
[11:04] <geser> callum1: thanks, and congratulations for your first(?) sponsored upload :)
[11:04] <callum1> geser: Yeah was my first :) and thanks really goes to you for all your help!
[11:22] <ricotz> dholbach, hello, is there a site which specifies the terms of updating a package of lucid after its release?
[11:22] <dholbach> ricotz: https://wiki.ubuntu.com/StableReleaseUpdates
[11:23] <dholbach> ricotz: I'm not the only one who knows this kind of information :)
[11:23] <ricotz> thanks anyway ;-)
[11:23] <dholbach> rock on
[11:40] <suji11> dholbach: Sorry, i couldn't understand the things there, can you tell me?
[11:41] <dholbach> suji11: I'm not the only one who knows about the processes, so just ask the whole channel :)
[11:41] <dholbach> suji11: what's your questions?
[11:41] <dholbach> suji11: what do you want to know?
[11:42] <suji11> i have to update the package iok-1.3.9 to iok-1.3.10 in lucid with the bug fix https://bugs.launchpad.net/ubuntu/+source/iok/+bug/563635
[11:43] <suji11> i am having the source tarball for iok-1.3.10 from that how to i update?
[11:44] <dholbach> https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate is an example of how you can update a package
[11:44] <dholbach> once you're done with that, check out https://wiki.ubuntu.com/FreezeExceptionProcess (if you manage to do it until Thursday although the gates are closing earlier)
[11:44] <dholbach> otherwise check out https://wiki.ubuntu.com/StableReleaseUpdates
[11:45] <dholbach> https://wiki.ubuntu.com/SponsorshipProcess explains how to get the package uploaded
[12:27] <callum1> geser: Fancy checking another debdiff for me?
[12:39] <suji11> dholbach: i followed the steps here and update the package https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate
[12:39] <suji11> dholbach: then how to send to upstream?
[12:44] <sladen> suji11: find the upstream bug tracker;  file a bug report with something similar to the name of the package you created, state the issue, attach the patch
[12:45] <sladen> suji11: alternatively, if the issue is already in the upstream's bug tracker, file the patch and state that it was shipped in the Ubuntu version after your extensive testing
[12:46] <suji11> sladen: the bug is in launchpad https://bugs.launchpad.net/ubuntu/+source/iok/+bug/563635
[12:51] <suji11> sladen: then what i do?
[12:53] <sladen> suji11: so this is the bug that you're in the process of doing an upload to fix?
[12:53] <suji11> sladen: yes
[12:53] <sladen> suji11: eg. you have found the solution, and codified it as  patch
[12:54] <suji11> sladen: i am not create patch just i follow the link which i said before and update the package.
[12:55] <suji11> sladen:  with latest source
[12:55] <sladen> suji11: can you set the bug as  Confirmed,  assign it to yourself, and add a quick comment   "I've found the issue, it was X interacting with Y and is solved with Z, see attached patch" + attach patch
[12:56] <sladen> suji11: oh, so it's not your solution, it's a solution that upstream have already tested+applied and is in the new upstream version
[12:57] <sladen> suji11: in which case, upstream already know about it and you don't need to send the fix to them!
[12:59] <suji11> sladen: upstream means? Actually iok is already available in fedora only, i got the source and packaged it for ubuntu at first, then the updates are done in the source tarball, from that i have to update it for ubuntu am right?
[13:00] <sladen> suji11: "upstream" means the developers who wrote the *original* program;  they probably have a download site with the a plain .tar.gz  containing the raw source code
[13:00] <suji11> sladen: yes , from there only i got the source tarball
[13:01] <sladen> suji11: flowing downstream (towards the users and the sea) will be the distributions;  Debian/Ubuntu/Fedora/...
[13:02] <sladen> suji11: if each of those decided to fix it for just their users, the solution would never make it into the original (upstream) source code for the benefit of everyone else
[13:03] <suji11> sladen: ok, the upstream was fixed the problem and gave the new version iok-1.3.10, now my question is how to i bring this for ubuntu?
[13:03] <sladen> suji11: can you update the Ubuntu bug by saying "the issue is fixed in upstream version x.y.z as detailed in the changelog" and cut and paste whichever part of the upstream changelog confirms it
[13:05] <sladen> suji11: (1) document what needs doing;  (2) do it [or ask for help/assistance doing it];  (3) document what was doing---Launchpad does these semi-automatically based on the bug number listed in the debian/changelog entires
[14:13] <geser> callum1: sure
[14:17] <callum1> geser: thanks I uploaded the patch to the bug url: https://bugs.launchpad.net/ubuntu/+source/app-install-data-ubuntu/+bug/538223
[14:23] <callum1> geser: ignore that just noticed there are several occurences. Ill fix that now
[14:32] <callum1> gerser: sorry about that new debdiff can be found here  http://pastebin.com/AQC6r9wT
[14:40] <callum1> geser: >.<  http://pastebin.com/KUbV3iWL
[15:06] <imbrandon> morning all
[15:27] <ScottK> joaopinto: At this point I'd call bzr branches an alternative to debdiffs.  I don't think we are to the point where we say they replace them.
[15:29] <MTecknology> dholbach: I suppose I could annoy you on irc too :P
[15:30] <dholbach> MTecknology: how can I help you? (or anybody else in here)
[15:31] <MTecknology> dholbach: I just saw you online and didn't talk in a while, wanted to say hi. You're attitude makes me eager to get out of school, get my company up and running smoothly, and get back into packaging really hard.
[15:32] <dholbach> MTecknology: if you have a bit of time again to put some effort into learning packaging and more about developing ubuntu, be sure to hang out here :)
[15:57] <om26er> how do I use my previous gpg key after a clean install?
[16:00] <imbrandon> om26er: did you backup ~/.gnupg  ?
[16:01] <om26er> no
[16:01] <imbrandon> om26er: then it is gone forever
[16:01] <om26er> oh my
[16:01] <imbrandon> om26er: always backup , esp important things like a gpg key
[16:01] <imbrandon> om26er: you might try data recovery on the old /home partition
[16:03]  * om26er will create a new gpg key and upload it to one.ubuntu ;)
[16:03] <om26er> imbrandon, how do I use it next time
[16:03] <imbrandon> om26er: not sure what you mean, next time
[16:03] <imbrandon> om26er: can you rephrase ?
[16:04] <om26er> imbrandon, if I create a new now and save ~/.gnupg when I install next time how do I restore
[16:05] <joaopinto> ScottK, on the last bzr for packaging presentation I got the idea it was replacing debdiffs in general, except for specific cases where debdiffs would make sense
[16:05] <imbrandon> om26er: ahh yes, first thing is gpg secret keys are very important to keep secure, there are a number of ways people save them, personaly i keep mine on an encrypted ( not with the same gpg key ) usb drive in a safe deposit box, and a seperate one hard printed out in a diffrent firebox location, as far as restoring its just a matter of replacing the /home/.gnupg after install
[16:07] <om26er> imbrandon, ok, thanks :)
[16:07] <imbrandon> oh wow, i thought the DMB meeting was at 11am local ... glad i am online anyhow
[16:08] <ScottK> joaopinto: Eventually.  We aren't there yet.
[16:09] <imbrandon> om26er: i can give you some good links about gpg security and keeping your key safe etc if you would like here in a little bit ( just gave a talk about it a week ago so i still have the links somewhere )
[16:09] <imbrandon> om26er: if not just poke google a bit :)
[16:11] <om26er> imbrandon, yes, I am here
[16:13] <ScottK> YokoZar: Are you fixing dssi-vst?
[16:15] <SEJeff> How does one go about proposing a 1 line patch to a python module where upstream isn't very responsive?
[16:15] <SEJeff> Should I wait for 5-6 months for upstream to continue ignoring it or should I propose it as a debdiff against the ubuntu / debian package?
[16:18] <imbrandon> SEJeff: both, or all 3 rather
[16:18] <imbrandon> imho
[16:19] <imbrandon> SEJeff: if its a package with ubuntu changes also ( with a version like -XubuntuX ) then do a debdiff for us and debian, if its not then just debian is fine
[16:20] <imbrandon> and it will trickel into ubuntu sooner ( rather than later )
[16:28] <om26er> how do I use .patch or debdiff
[16:28] <om26er> *while packaging
[16:34] <om26er> a bug have a .patch I can apply it to the source with sudo patch ... but when I apply patch debian/changelog file contains the name of the patch writer but then I cannot upload that package to the ppa cuz I cannot dh_make so there wont be any .changes file as there are already files in debain/
[16:41] <carstenh> om26er: "filterdiff -x '*/debian/changelog' patchfile > newpatchfile" creates a new patchfile without debian/changelog. don't use sudo patch, just patch. some packages use quilt or similar for managing pachtes, so depending on which package you work on directly applying patches might be the wrong way.
[16:50] <om26er> carstenh, what about .patch file that come with the package source how are those patches in the debian/patches applied during build process
[16:55] <carstenh> om26er: depends, if debian/source/format (or similar, don't remember the exact name) exists and contains "3.0 (quilt)" they are applied whilst unpacking the source. otherwise they are applied during the building process itself, debian/rules contains the code or includes code that does this. dpatch and quilt are the patch system that are widly in use, google should know much about them. a package needs to builddepends on quilt or dpatch if ...
[16:55] <carstenh> ... it uses any of these, so checking debian/control should tell you which one is used.
[16:56] <carstenh> in quilt you have to maintain a debian/patches/series file and you can apply oder unapply all patches with debian/rules apply oder debian/rules unapply
[21:25] <YokoZar> ScottK: vst's problem seems to be that wine1.0 is refusing to install due to exit status 10 at --configure, but I haven't reproduced the problem locally.
[21:37] <micahg> ScottK: slangasek: Seamonkey was uploaded earlier and the builders are idle
[22:22] <MTecknology> jdong: hey.... you should help me :D
[22:28] <MTecknology> jdong: If you ever have some time, would you be willing to help me with some init.d->init scripts? I want to learn how to do it so I can work on all of them and mybe see about upstream stuff if I can finish making them really smooth...
[23:00] <imbrandon> MTecknology: init.d->upstart init ?
[23:00] <imbrandon> MTecknology: if you ever pin jdong down for that lemme know, i'd like to learn a bit more about it too from a "live" person
[23:06] <kirkland> nhandler: around?
[23:40] <MTecknology> imbrandon: that's exactly what I mean
[23:48] <MTecknology> imbrandon: hrm.... https://edge.launchpad.net/~uphackers
[23:59] <MTecknology> jdong: lp:~uphackers/uphack/event.d - is this what should wind up in /etc/init/ ?