[00:00] <soren> So.. motu-release people: If a project is due to hit 1.0 on April 18th, would you consider granting an FFe up front for that is should I not even bother filing a request?
[00:00] <TheMuso> soren: I'd consider it based on what it was.
[00:01] <soren> It's rawstudio.
[00:01] <TheMuso> Ok. I'll have to look it up.
[00:02]  * soren wonders how an "or" turned into an "if" in his question
[00:02] <TheMuso> soren: Depending on the changes, I'd likely give it the thumbs up.
[00:02] <soren> TheMuso: Cool.
[00:21] <null_vector> Anyone available to answer some questions about a new package and the FF
[00:27] <Fujitsu> null_vector: At this stage, you should probably forget about it.
[00:32] <null_vector> ]I understand that, but at what point would it be an option.  Electricsheep( currently in universe ) is going to require this package in the next version.  Trying to figure out how that's going to work.
[00:32] <Fujitsu> Once Intrepid opens (probably a coupler of weeks after Hardy releases), there are no freezes...
[00:33] <null_vector> alright
[00:45] <pschorf> hello, all
[02:03] <xtknight> we don't do anything with xsbc-original-maintainer for multiverse packages, do we?
[02:13] <mok0> xtknight: yes, it's the same
[02:18] <xtknight> mok0, so i need to change multiverse maintainer to ubuntu-motu also?
[02:26] <xtknight> i'm having trouble uploading to my PPA also.  WARNING: This key is not certified with a trusted signature!  and i get a rejected email saying it must be signed by an ubuntero.  but i used debuild -S -sd -k with my public key ID.  the same one i uploaded to launchpad.
[02:32] <mok0> xtknight: you have to sign the key
[02:33] <xtknight> oops i just realized i didn't sign the CoC
[02:33] <xtknight> i wonder how i even got my ppa acct then hmmm
[02:33] <xtknight> weidr
[02:33] <mok0> xtknight: that was opened by the admin
[02:34] <pschorf> i was looking to get started with packaging, is it pretty slow before the new release?
[02:35] <xtknight> lol and when i paste my asc file to sign it, launchpad says "Cannot allocate memory" :)
[02:35] <mok0> ha
[02:36] <mok0> pschorf: yes, nothing is happening atm with new packages
[02:37] <xtknight> is there a way to wipe dput's cache saying i already uploaded it?  i need to try again
[02:37] <pschorf> mok0: thanks
[02:37] <xtknight> oh nm -f works
[02:39] <mok0> xtknight: yes, either that or delete the .uploads file
[02:40] <xtknight> success at last
[02:43] <mok0> gnight ppl
[02:56] <xtknight> it says that my build finished but i don't see any binaries on my ppa.  what's the deal?
[02:57] <ScottK2> xtknight: What's the link?
[02:57] <Hobbsee> xtknight: #launchpad for ppa support.  and wait longer.
[02:57] <xtknight> ScottK2, https://launchpad.net/~xt-knight/+archive
[02:58] <xtknight> ah maybe just needs time to upload to ftp i dont know.  just wondering, sometimes i get excited ;)
[02:58] <ScottK2> xtknight: What Hobbsee said.
[02:59] <Ward1983> https://bugs.launchpad.net/ubuntu/+source/emdebian-tools/+bug/121369
[02:59] <ubotu> Launchpad bug 121369 in emdebian-tools "emdebian-tools.postinst" [Undecided,Confirmed]
[02:59] <Ward1983> how can i fix that temnporarily?
[02:59] <Ward1983> the suggested fix doesnt seem to work
[03:00] <xtknight> Ward1983, i'm trying to reproduce it.  what should i choose at the "default cross-building architecture" screen
[03:01] <Ward1983> xtknight, i chose armel
[03:01] <Ward1983> xtknight, thanx in advance for taking the time to reproduce it
[03:01] <xtknight> Ward1983,  ok simply installing it selecting armel on my amd64 hardy machine does not give an error
[03:02] <Ward1983> maybe the 64 bit one is ok
[03:02] <xtknight> so it looks like a gutsy problem only?
[03:02] <Ward1983> i have a regular 32bit system (allthough i have a core2duo)
[03:02] <Ward1983> xtknight, apperantly, weird
[03:03] <xtknight>  i have a gutsy i386 also hold on
[03:03] <Ward1983> since its ok on 64bit, is there some quick fix?
[03:03] <xtknight> oh i think it's gutsy/hardy not i386/amd654
[03:03] <Ward1983> lol how convenient :)
[03:03] <xtknight> you have gutsy now right?
[03:03] <Ward1983> well i just run gutsy
[03:03] <Ward1983> yes
[03:05] <Ward1983> i need emdebian-tools so i can try to get me a EABI kernel crosscompiled for my PDA :)
[03:05] <xtknight> and you wanted a patch for gutsy to fix this problem ?
[03:05] <Ward1983> no i just ran into the problem and came here to ask if theres a temporary fix
[03:08] <Ward1983> but if youre asking if i would like it fixed, offcourse i do
[03:08] <Ward1983> my apt is broken if i install it
[03:08] <xtknight> ahh
[03:08] <xtknight> well there is a hacky workaround
[03:08] <xtknight> you can remove emdebian-tools from your debian status file
[03:08] <Ward1983> and how do i do that? :)
[03:09] <xtknight> of course a patch would be much better but i can't provide you with that right now, so
[03:09] <Ward1983> sorry if i wasnt clear at first, im not native english
[03:09] <Ward1983> hacky is ok :)
[03:09] <xtknight> let's just take it to pm
[03:29] <xtknight> if someone else is assigned to a package is he "obligated" to finish his work or if i have a debdiff should i simply unassign him, set it to confirmed, and subscribe motu?
[03:30] <xtknight> bug 182999
[03:30] <ubotu> Launchpad bug 182999 in acidrip "AcidRip Fails to properly work with x264 (includes patch)." [Wishlist,In progress] https://launchpad.net/bugs/182999
[03:38] <ScottK2> xtknight: How long since the other person touched it?
[03:38] <xtknight> ah it's been since 18 mar 08
[03:39] <ScottK2> I'd go for it.
[03:40] <xtknight> k
[03:41] <pschorf> aside from reading the wiki page, does any one have any tips on learning how to package?
[03:44] <xtknight> pschorf, well i recommend learning how to patch packages, then at least you can learn the ins and outs of packages better before creating the whole infrastructure for one yourself.
[03:45] <pschorf> xtnight, do you know any bugs that need packaging now?
[03:45] <xtknight> pschorf,  like a patch that needs to be debianized?
[03:45] <pschorf> right
[03:46] <ScottK2> pschorf: http://daniel.holba.ch/really-fix-it/ is a good place to look.
[03:46] <pschorf> ScottK2: thanks
[03:46] <xtknight> ya i'm looking there, not all of them that say they have patches really have em though
[03:47] <xtknight> this one looks nice  Bug 104063
[03:47] <ubotu> Launchpad bug 104063 in anjuta "[apport] anjuta crashed with SIGSEGV in strlen()" [Medium,Incomplete] https://launchpad.net/bugs/104063
[03:47] <ScottK2> There's a column for patch attached.
[03:48] <pschorf> xtnight, can i pm you after I look at it for a while?
[03:49] <xtknight> sure
[03:52] <TheMuso> .c
[03:57] <ScottK2> Heya TheMuso.
[03:57] <TheMuso> Hey ScottK2. How goes things?
[03:57] <ScottK2> Not to bad.
[03:57] <ScottK2> I could use another month or two to do bug fixing before the release.
[03:57] <ScottK2> xtknight and pschorf: I'd suggest keeping it on channel.  Others may have suggestions and others may learn from your discussion.
[03:58] <xtknight> ScottK2, ok.  will do, then
[03:58] <ScottK2> It's a good general rule.
[04:00] <jdong> calc: hey, would you like to save me 8000 hours and a few polar ice caps by telling me ahead of times if OOo from Hardy will build on Gutsy?
[04:00] <xtknight> this guy's patch for Bug 93843 looks fine http://launchpadlibrarian.net/6861053/addwords.debdiff  but he wasn't supposed to remove Core Devs from the maintainer field was he?
[04:00] <ubotu> Launchpad bug 93843 in aspell-en ""Ubuntu" and "Debian" are not in the dictionary" [Undecided,New] https://launchpad.net/bugs/93843
[04:02] <xtknight> errrr never mind.  he added core devs and put pyro as XSBC
[04:03] <calc> jdong: it won't out of the box, someone is working on backporting it, though i forgot who it is
[04:04] <jdong> calc: ok cool :)
[04:04] <calc> jdong: i'm sure with enough backporting of other things and tweaks to rules it will work
[04:04] <calc> jdong: whoever does backport it, it would be good if they wait to backport the final version for hardy or at least the one that will be uploaded in the next couple days
[04:04] <jdong> calc: yeah, though that kind of trial and error ain't my cup of tea :)
[04:05] <calc> since it will do proper launchpad-integration so bug reports will be more useful :)
[04:05] <jdong> calc: I'm not even aware that someone is backporting it :D
[04:05] <jdong> calc: but yeah keep me posted on that. IMO OOo 2.4 in Gutsy would be pretty slick, once everything is settled
[04:05] <calc> jdong: someone was talking to me about it a few days ago but i don't recall who it was
[04:06] <pschorf> xtnight: I saw a diff file in the responses to the post, how would i go about patching with that?
[04:06] <xtknight> pschorf, https://launchpad.net/bugs/104063 ?
[04:06] <ubotu> Launchpad bug 104063 in anjuta "[apport] anjuta crashed with SIGSEGV in strlen()" [Medium,Incomplete]
[04:06] <xtknight> well lets setup your build environment
[04:06] <jdong> [jdong@jdong:irclogs/FreeNode]$ grep ".*calc.*backport" *         (04-06 23:06)
[04:06]  * jdong wonders if that'll work
[04:07] <jdong> #ubuntu-devel.2008-04-03.log.txt:04:46 < mantiena-baltix> calc: hi, are you online ? I'm backporting OpenOffice 2.4 to Ubuntu 7.10 (Gutsy), maybe you already did this job ?
[04:07] <jdong> I can't believe it. It worked.
[04:07] <jdong> screw you Tracker, grep still wins!
[04:10] <xtknight> pschorf, yes ok i see the diff file
[04:10] <pschorf> xtnight: i apt-get'd the source for the package, how would I patch it?
[04:11] <xtknight> let's build the dependencies needed to compile it.  type "sudo apt-get build-dep anjuta"
[04:11] <xtknight> sorry, install the dependencies.
[04:11] <pschorf> right
[04:11] <pschorf> this may take a minute, I'll let you know when finished
[04:12] <xtknight> k
[04:13] <xtknight> pschorf, did you plan on uploading an actual patch?  in this case i'm not sure it's possible.  first we'd have to confirm whether or not it exists in Hardy.  if not, it's a lot more difficult to make a patch
[04:13] <pschorf> xtnight, i had hoped to
[04:13] <pschorf> if i can't apply it, I might as well practice on it anyway
[04:13] <xtknight> ya i just picked it because it looked simple
[04:13] <xtknight> pschorf, do you want to try and confirm it now or just get down to the dirty work and make the patch anyway?
[04:14] <xtknight> it looks like he reported it on Gutsy according to his crash dump
[04:14] <pschorf> let's confirm it...if its not there i might do it anyway
[04:14] <pschorf> how would we do that?
[04:14] <xtknight> i would read his bug report, install anjuta, and follow the steps he provided and see if it crashes for you
[04:15] <xtknight> if that bug is confusing to you (it's confusing to me, i can tell you that much) then we can simply try making the patch or pick another already confirmed bug.
[04:19] <pschorf> i've never used anjuta...
[04:19] <xtknight> same here
[04:19] <pschorf> i don't even know how to start debugging in it
[04:19] <xtknight> im' trying to find another bug that looks simple
[04:20] <pschorf> k
[04:22] <xtknight> pschorf, what i'm doing is going down the first column of http://daniel.holba.ch/really-fix-it/
[04:22] <xtknight> we should find one that's confirmed for Hardy, at least ideally, and which already has a patch available.
[04:22] <pschorf> ok
[04:24] <pschorf> what about bug 43785
[04:24] <ubotu> Launchpad bug 43785 in evolution "Purge-Dialog not translatable" [Medium,Confirmed] https://launchpad.net/bugs/43785
[04:25] <xtknight> pschorf, can you confirm it/
[04:25] <xtknight> i mean do you have a german build
[04:25] <xtknight> or german setup rather
[04:25] <pschorf> no
[04:26] <xtknight> how about this one... Bug 204600
[04:26] <ubotu> Launchpad bug 204600 in amule "[hardy] Fix Spanish translation of aMule" [Undecided,Fix committed] https://launchpad.net/bugs/204600
[04:26] <xtknight> it is confirmed for hardy
[04:26] <xtknight> and it's a simple, hard to mess up fix
[04:26] <xtknight> the spanish translation is already there it's just incorrect.
[04:28] <pschorf> i can work with that
[04:28] <xtknight> ok.  get the source and install the dependencies
[04:29] <pschorf> ok
[04:29] <pschorf> got it
[04:29] <xtknight> save his patch to a folder
[04:30] <xtknight> fixed_spanish_translation.diff
[04:30] <pschorf> ok
[04:30] <xtknight> have you ever patched the source before?
[04:30] <xtknight> rather have you ever patched source code before
[04:31] <xtknight> with the patch command
[04:31] <pschorf> no
[04:31] <xtknight> alright
[04:31] <xtknight> cd into the amule directory
[04:31] <pschorf> i am
[04:32] <xtknight> ok.  many debian packages use something called a patch system, which means you will have to put the patch in a specific format for the package to understand and apply it
[04:33] <pschorf> ok
[04:33] <xtknight> personally, i don't know much about patch systems.  when i tried to use one i got very frustrated.  so i will teach you my way of doing it, if that's fine.
[04:34] <xtknight> i will still comply with the patch system but i won't use the patch system program for now
[04:34] <pschorf> ok
[04:34] <xtknight> let's go into the debian/patches folder
[04:34] <xtknight> you can see different diff files and a 'series' file which describes the different patches being applied
[04:35] <xtknight> the series file is just a list of all the patches in that dir.
[04:35] <pschorf> ok
[04:36] <xtknight> today we're lucky.  he provided a simple patch and none of the other patches modify that same translation file
[04:36] <xtknight> so we can just slip it in.
[04:37] <pschorf> ok
[04:37] <xtknight> basiaclly, copy the .diff file to the patches folder
[04:37] <xtknight> and add the filename to the series file
[04:38] <pschorf> what do I append after the file name?
[04:38] <pschorf> -p0 or -p1?
[04:38] <xtknight> ok.  inside the patch we see it modifies po/es.po, right?
[04:39] <pschorf> right
[04:39] <ScottK2> RAOF: You around?
[04:39] <xtknight> basically -p1, -p2, -p3 etc are for when the patch has EXTRA folders in front of the name specified.
[04:39] <RAOF> ScottK2: Yeah?
[04:39] <xtknight> in this case, we have no extra folders.  note how po/es.po exists right from the root of our package folder (amule)
[04:39] <pschorf> ok
[04:39] <xtknight> so we can use -p0
[04:39] <xtknight> meaning 'ignore 0 directories', or use all directories in the patch file
[04:39] <pschorf> ok
[04:40] <ScottK2> RAOF: I was looking at Bug #157969 and since specto is your baby, thought I'd check with you.
[04:40] <ubotu> Launchpad bug 157969 in specto "Specto - lacking dependencies in Kubuntu" [Low,Triaged] https://launchpad.net/bugs/157969
[04:40] <xtknight> pschorf, ok your filename in series matches the diff you placed in the patches folder?
[04:40] <pschorf> xtnight: yes, i kept the given name
[04:41] <xtknight> (again please note it will not always be this easy, learning a patch system is probably necessary in the future.  )
[04:41] <xtknight> ours uses quilt, which was very frustrating for me so i decided to do it this way.
[04:41] <RAOF> ScottK2: Yeah, I've been meaning to get to that (and apply the same in Debian).
[04:41] <xtknight> the patch system being used for a package can be determined by using the "what-patch" tool.
[04:41] <ScottK2> RAOF: I'll leave it to you then.
[04:42] <RAOF> You're welcome to take it if you like :)
[04:42] <pschorf> ok, i checked it
[04:42] <ScottK2> RAOF: OK.  I'll do it.  It shouldn't take long.
[04:42] <xtknight> pschorf, luckily, quilt uses the same format as diff.  we don't have to add any quilt-specific code to the diff files
[04:42] <xtknight> pschorf, alright the next step is to determine what else needs to be done to make your patch
[04:42] <RAOF> ScottK2: Yeah.  The debdiff looks correct.
[04:43] <pschorf> ok
[04:43] <xtknight> pschorf, other things might include simply housekeeping that previous people didn't do
[04:43] <xtknight> like something called a maintainer field
[04:43] <xtknight> pschorf, it's going to be helpful to pull up the Hardy package page for amule.  packages.ubuntu.com/hardy/amule
[04:43] <xtknight> http://packages.ubuntu.com/hardy/amule
[04:44] <pschorf> got it
[04:44] <xtknight> pschorf, click source package amule on the right
[04:44] <xtknight> this will provide information more pertinent to our job
[04:45] <pschorf> i'm there
[04:45] <xtknight> pschorf, you first need to determine what section it is in.  that's in red at the top.  if it's not specified, it's main.  we can see however that amule is in universe
[04:45] <pschorf> right
[04:45] <xtknight> pschorf, if the Maintainer is NOT Ubuntu MOTU Developers, as it must always be for a universe package, then we need to fix it.
[04:46] <xtknight> pschorf, when packages are first uploaded the universe, the maintainer is<EMAIL_ADDRESS>or someone else.  but the first patch always makes it Ubuntu MOTU
[04:46] <xtknight> in this case, we are fine
[04:46] <xtknight> but we still have something else to do to finish your patch
[04:46] <pschorf> you're just looking at the field on the right?
[04:46] <xtknight> ya
[04:46] <pschorf> ok
[04:47] <xtknight> by the way i'm still building this package on my machine
[04:47] <xtknight> it seems to be quite a big one
[04:47] <pschorf> ok
[04:47] <xtknight> but that's ok
[04:47] <xtknight> pschorf, go to the root directory of the package (amule-2.2...)
[04:47] <pschorf> i have the source for 2.1.3
[04:47] <xtknight> are you on Hardy?
[04:48] <pschorf> no, i'm still on gutsy
[04:48] <xtknight> oooh
[04:48] <pschorf> do i need to upgrade?
[04:48] <xtknight> well we need to stop futzing around and just make a patch then
[04:48] <xtknight> hehe
[04:48] <xtknight> it doesn't matter.
[04:48] <pschorf> ok
[04:49] <xtknight> pschorf, you know, actually, you could make a hardy pbuilder.  do you want to do that?
[04:49] <xtknight> i guess this is as useful as anything
[04:49] <xtknight> when it comes to making packages
[04:49] <pschorf> yeah, it would be good experience
[04:50] <xtknight> alright i'm following this
[04:50] <xtknight> https://wiki.ubuntu.com/PbuilderHowto
[04:51] <pschorf> would i use variant=hardy
[04:51] <xtknight> well you know i'm not entirely sure.  maybe someone here can suggest.  i haven't really used pbuilder that much.
[04:51] <xtknight> is it possible to create a hardy pbuilder on gutsy?
[04:52] <ScottK2> Yes
[04:53] <ScottK2> I use the pbuilder-dist script in ubuntu-dev-tools.  It's pretty easy with that.
[04:53] <xtknight> pschorf, i'll tell you what.  i have a gutsy machine too, so i will see if we can make that patch for gutsy.  i wish i could help you with pbuilder but i've never really used it.
[04:54] <pschorf> ok
[04:55] <ScottK2> If you get the above script you do sh pbuilder-dist hardy create and you're done.
[04:55] <xtknight> ah
[04:56] <pschorf> ScottK2: i got an unknown distribution error
[04:57] <xtknight> same here actually
[05:00] <ScottK2> The gutsy version may have been somewhat broken.
[05:00] <ScottK2> I use a somewhat customized version myself.
[05:00] <xtknight> i think it needs a debootstrap script for hardy
[05:01] <ScottK2> Grab the source package for ubuntu-dev-tools from hardy and just copy the script from the source package.  It doesn't need to be installed.
[05:03] <ScottK2> RAOF: specto is done.
[05:03] <xtknight> hmmm'
[05:03] <pschorf> xtnight: could you find the script?
[05:04] <RAOF> ScottK2: Thanks very much.
[05:04] <xtknight> pschorf, no it looks like the hardy version doesnt even use scripts
[05:04] <pschorf> hmm...
[05:05] <xtknight> well i dont know about that.  you'll probably want hardy for developing anyway.
[05:05] <xtknight> but i am downloading the package on gutsy now to see what we can do
[05:06] <xtknight> let's just get a debdiff made for now even if it's not too useful
[05:06] <xtknight> at least proof of concept
[05:06] <pschorf> ok
[05:06] <pschorf> i had just finished adding to the series file
[05:08] <xtknight> yeah.  the problem is, the patch wont work since gutsy's file is different
[05:08] <xtknight> also gutsy doesnt have the problem i checked
[05:08] <pschorf> ok
[05:08] <pschorf> will you be on this channel tomorrow?
[05:08] <xtknight> yeah
[05:08] <pschorf> i need to get to bed: i have a class at 9 AM tomorrow
[05:08] <xtknight> i'm a little tired for tonight as well
[05:09] <ScottK2> Bah.  Sleep is for the weak.
[05:09] <pschorf> but i'll install hardy and hop back on in the evening
[05:09] <xtknight> do you want to install hardy?
[05:09] <xtknight> ok
[05:09] <pschorf> yeah
[05:09] <xtknight> good deal
[05:09] <pschorf> night, all
[05:12] <xtknight> i just realized how much my patching practices deviate from those suggested (use a patch system, use pbuilder, etc).  oh well :p
[05:15] <ScottK2> xtknight: The suggested ones are all derived from painful experiences.  You can either learn from other's pain or wait until you experience your own.
[05:17] <xtknight> well pbuilder doenst look too helpful to me.  although the patch systems are something i really need to learn
[05:18] <xtknight> at least for just making patches.  but i'd definitely want to test new packages in a clean pbuilder environment, etc
[05:19] <ScottK2> Yes.
[05:19] <xtknight> i dont really see how it's different than a chroot
[05:19] <ScottK2> It's a clean minimal set each time you run it.
[05:19] <ScottK2> It's better for checking missed build-deps.
[05:20] <xtknight> something that always puzzles me is how to apply a patch to a file when other patches in the folder modify the same file.  because then the offsets of the latest patch get all messed up, they expect an unpatched file
[05:21] <xtknight> but i didn't see evidence of how quilt made this easier.  well at least not for patches that have already been made, which is often the case for me.  i usually just package other people's wrongly made patches :)
[05:22] <ScottK2> For dpatch you can use dpatch-edit-patch or for cdbs cdbs-edit-patch to edit the patch in an environment where the other patches are already applied.
[05:22] <xtknight> ahhh
[05:22] <ScottK2> quit has an import feature, but I'm not much of a quilt user yet.
[05:23] <RAOF> I've been playing with the X server, and that uses quilt; import seems fairly nice & easy.
[05:23] <ScottK2> From what little I've used quilt, I think I would like it if I used it regularly.
[05:23] <xtknight> so why are there different patch systems?  there seems to be absolutely no different between quilt and dpatch
[05:24] <ScottK2> As it is, I have to look up the commands and wrap my head around quilt each time I try it.
[05:24] <xtknight> kind of like mercurial,cvs,svn,git,mono, and all that i guess.  but even less significant
[05:24] <ScottK2> xtknight: They are different, but the need for sustaining the difference is often argued in Debian.
[05:24] <RAOF> xtknight: There's actually quite a difference between quilt and dpatch/cdbs-simple-patchsys.
[05:24] <lifeless> loom FTW kthxbye thatisall
[05:25]  * ScottK2 lets the quilt fanboy run with it.
[05:25]  * RAOF wonders whether that's *him* being described as a quilt fanboy.
[05:25] <ScottK2> Yes.
[05:25] <xtknight> if i were to describe the difference to somebody i'd say with dpatch you just have to add that annoying @DPATCH@ thing
[05:25] <ScottK2> It's all relative.
[05:25] <xtknight> when you manually hack edit it like i do
[05:25] <xtknight> :P
[05:26] <RAOF> lifeless: Yeah, loom + no-more-source-packages :P
[05:26] <ScottK2> xtknight: Learn to love dpatch-edit-patch.
[05:26]  * RAOF certainly has.
[05:26] <xtknight> keep in mind i used to make debs with checkinstall
[05:26] <xtknight> and then decompile them with "ar x" and edit the status files and repackage them
[05:26] <xtknight> i'm that lazy
[05:27] <xtknight> just my own debs of course
[05:27] <ScottK2> Yeah, well, learn to do it right and just do it that way.
[05:27] <ScottK2> I do sometimes ar x .debs to inspect them.
[05:27] <StevenK> I've done that. But only when the situation called for it.
[05:27] <ScottK2> Heya StevenK
[05:27]  * StevenK waves
[05:28] <ScottK2> StevenK: You coming to UDS?
[05:28] <RAOF> Heya StevenK.
[05:28] <StevenK> ScottK2: And Fosscamp
[05:28] <ScottK2> Cool.  See you there.
[05:28] <StevenK> Way cool.
[05:28]  * StevenK might smuggle RAOF in some luggage
[05:29] <StevenK> "Just one bag, sir?" "Yup! Let me just ..... lift it up .... Ugh" *kick*
[05:29]  * RAOF is pretty svelt.
[05:29] <StevenK> Heh
[05:31] <StevenK> ScottK2: You'll be there for the whole week this time? :-)
[05:33] <jdong> https://edge.launchpad.net/ubuntu/+source/firefox-3.0
[05:34] <jdong> am I seeing heptuples?
[05:34] <jdong> or is it firefox (ironically) playing tricks with me?
[05:35] <ScottK2> StevenK: Yes.  It'd be hard to justify a two day trip to Europe.
[05:35] <StevenK> Just a bit.
[05:35] <xtknight> jdong, i don't see anything that odd here what do you mean?
[05:36] <jdong> xtknight: at least for me, there's 7 e-mail icons next to alexander's name and e-mail
[05:36] <superm1> jdong, me too
[05:36] <xtknight> hm i just get <email address hidden> :)
[05:36] <xtknight> lol
[05:36] <jdong> superm1: so I'm not crazy?
[05:37] <jdong> xtknight: log in :D
[05:37] <superm1> well you are
[05:37] <superm1> but that's besides the point
[05:37] <jdong> :P
[05:37] <jdong> superm1: for that comment, please toss gtkpod-aac in your iTouch PPA
[05:37] <superm1> on gutsy?
[05:37] <xtknight> hahah
[05:37] <ScottK2> jdong: One per time his name is mentioned in .changes
[05:37] <jdong> superm1: yeah
[05:37] <xtknight> there are 7 icons yeah
[05:37] <superm1> jdong, you want to join the ipod-touch team?
[05:37] <superm1> you can toss it then :)
[05:38] <jdong> ScottK2: good observation
[05:38] <ScottK2> jdong: If my opinions on Launchpad U/I were credible, I'd suspect that was a bug.
[05:38] <jdong> lol
[05:38] <jdong> ScottK2: or it's a hidden feature. Maybe candy comes out if you can build a pascal triangle out of a properly formatted changelog :D
[05:38] <xtknight> lol
[05:38] <ScottK2> No, I've been told I have to like the new U/I better for my opinion to be credible.
[05:38] <jdong> superm1: that requires work on my part though!
[05:39] <ScottK2> Be definition, apparently, any thought that LP developers aren't on the right track must be ignored.
[05:39] <superm1> jdong, well just take some time away from backporting firefox 3 beta 15 when it comes around
[05:39] <ScottK2> Be/By
[05:39] <superm1> and you'll be able to :)
[05:39] <jdong> ah bug 212618
[05:39] <ubotu> Launchpad bug 212618 in launchpad "Extraneous "face" icons on changelog for emails" [Undecided,New] https://launchpad.net/bugs/212618
[06:20] <Hobbsee> ooh, new exaile.
[06:20] <RAOF> Hobbsee: This is exciting because?  :P
[06:20] <jdong> ooh, new *banshee*
[06:21] <StevenK> Hobbsee: In the archive?
[06:21] <RAOF> Which is exciting because of awesomeness, yess.
[06:26] <jml> ScottK2: I personally don't ignore thoughts about us not being on the right track.
[06:28] <jml> except insofar as I ignore many things by virtue of them not being shoved in front of me.
[06:29] <ScottK> jml: I believe you, but that's pretty much a direct quote from a senior Launchpad developer.  I got the hint.
[06:31] <ScottK> jml: No.  That's wrong.  The pretty much direct quote was that unless I gave up my opinion that the pre-beta U/I was better, my opinions on LP U/I wouldn't be credible.
[06:32] <jml> ScottK: why do you think the old UI was better?
[06:32] <ScottK> It was simpler, faster and less confusing.
[06:33] <ScottK> I still click on the package name to open the section for assigning status/importance.
[06:33] <ScottK> I still don't like the new fonts.
[06:34] <ScottK> Some of the recent progess is just fixing bad changes.  Like I see that once again component has made it's way back onto the main package page.
[06:34] <ScottK> That's welcome, but it's just unbreaking a recent change.
[06:34] <ScottK> This is not to say there aren't improvements, there are.
[06:34] <ScottK> It's just way to slow and way to confusing.
[06:35] <jml> yeah, it's definitely too slow.
[06:35] <jdong> the text interface that ubotu uses seems to respond instantly at times.
[06:35] <jdong> is it really the AJAXy complexity of the launchpad UI making it slow?
[06:36] <jml> there isn't all that much AJAX, afaik.
[06:36] <ScottK> When LP bug pages load as fast as Debian BTS pages, then I think it's good.
[06:36] <jml> the big thing for me and others is that https from .au to .uk is inevitably slow.
[06:36] <jml> too many roundtrips.
[06:36] <StevenK> And the Debian BTS isn't https://
[06:37] <ScottK> From my perspective as a user, they why of the slowness is irrelevant.
[06:37] <ScottK> StevenK: Poor design choices by LP doesn't get them out of being annoying for being slow.
[06:37] <jml> ScottK: I can understand that.
[06:38] <jml> ScottK: I was explaining to jdong, not providing an excuse.
[06:38] <StevenK> ScottK: I seriously doubt https:// is a poor design choice.
[06:38] <jml> ScottK: back to what you were saying earlier though
[06:38] <ScottK> StevenK: It's a needed design choice for some things.  Using it for everything is overkill
[06:38] <StevenK> Personally, I like it being used for everything.
[06:38] <StevenK> But that's me.
[06:39] <ScottK> StevenK: In general, I agree.  If it was fast enough with it, I'd be happy.
[06:39] <jdong> well I don't care what it uses, all I care is of the 5 hours I spent triaging backports bugs, I can say about 50% of that time was waiting on launchpad to respond
[06:39] <ScottK> Yep.
[06:39] <jdong> it makes working with the BTS extremely frustrating
[06:39] <ScottK> Also I think it's a sign of design failure when my primary method of navigating LP is typing urls.
[06:40] <jml> definitely
[06:40] <jml> ScottK: have you filed bugs about specific cases?
[06:40] <ScottK> jml: Nope.
[06:40] <ScottK> Don't intend to either.
[06:40] <jml> ScottK: why not?
[06:40] <ScottK> See the earlier discussion about my opinions not being credible.
[06:41] <ScottK> Since then I've neither filed nor commented on any bugs in LP.
[06:41] <ScottK> It's really up to Canonical to figure it out.
[06:41] <jml> ScottK: I see.
[06:41] <ScottK> If it were a community oriented project I'd see it differently.
[06:43]  * ScottK needs to get to bed anyway.
[06:43] <ScottK> jml: It was nice chatting with you.
[06:44] <jml> ScottK: likewise. g'night.
[06:44] <jdong> maybe if LP were scriptable, I would complain less....
[06:44] <jdong> for example, for Backports I often have to mark a bug in progress then subscribe another team.
[06:45] <jdong> the LP lag between those two operations often can take as long as reading the bug report in the first place
[06:45] <ScottK> jdong: You can do that via the email interface.
[06:45] <ScottK> Make yourself a template and then just fire away.
[06:45] <jdong> ScottK: I may start doing that.
[06:47] <ScottK> jdong: As an example of the fun you can have with the email interface, Bug #204895 was filed with one mail.
[06:47] <ubotu> Launchpad bug 204895 in harvestman "Packages failed archive rebuild test possibly due to python-central transition" [Medium,Fix released] https://launchpad.net/bugs/204895
[06:48] <jdong> ScottK: yeah I just need to get my GPG agent hooked into mutt... right now I don't have passphrase caching
[06:48] <ScottK> Yeah.
[06:48] <ScottK> Well.  Good night.  Really this time.
[06:48] <jdong> night
[06:55] <wor6c> i have a java app i want to package into a deb (not necessarily for release)
[06:55] <wor6c> are there any docs for this?
[06:56] <wor6c> the docs seem geared towards packaging from source (assuming ur using make and configure etc.)
[06:56] <RAOF> wor6c: So you're not building from source? Urgh.
[06:57] <wor6c> RAOF: would it matter? this is a Java program
[06:57] <wor6c> RAOF: if you wanted to know i'm looking at Hadoop
[06:57] <RAOF> wor6c: It matters just as much as any other type of program.  Pacakging the binary makes it really hard to fix stuff.
[06:58] <wor6c> RAOF: ok, I can get the Java .java files (source)
[06:58] <warp10> Good morning
[06:58] <RAOF> warp10: Good afternooooooooon.
[06:58] <warp10> hey RAOF! :)
[06:59] <RAOF> wor6c: Which is good, if you can build it from them.
[07:00] <wor6c> RAOF: right, the end-product is jar files
[07:00] <RAOF> wor6c: But the general plan is pretty much the same - you install stuff in debian/binary-pkg-name/, and call the various debhelper goodies.
[07:00] <wor6c> RAOF: oh ok
[07:00] <wor6c> RAOF: i will attempt following a tutorial with debhelper's
[07:05] <xtknight> NOTICE: 'vinagre' packaging is maintained in the 'Svn' version control system at:
[07:05] <xtknight> so apt-get source vinagre doens't give be the right base?
[07:09] <RAOF> xtknight: apt-get source will get the source package as it in in the repositories; since it's being maintained in svn there may be relevant changes in there that you won't get with apt-get source.
[07:09] <xtknight> which is the version that i should be patching against?
[07:10] <xtknight> for hardy universe
[07:10] <xtknight> or hardy main
[07:11] <RAOF> Probably the source package as retrieved by apt-get source.  SVN is more commonly used by Debian, so it's probably a debian upstream vcs.
[07:11] <xtknight> also another question, how does Add/Remove Programs populate a list of applications?
[07:11] <RAOF> For bonus points, you can create diffs against both, and submit the svn diff to Debaian.
[07:11] <xtknight> trying to fix bug 213207
[07:11] <ubotu> Launchpad bug 213207 in vinagre "Vinagre appears in Add/remove applications twice as "remote desktop viewer"" [Undecided,Confirmed] https://launchpad.net/bugs/213207
[07:12] <RAOF> I believe that add/remove does some funky desktop file scanning, but I'm not sure of the details.
[07:13] <xtknight> if i wanted information on that do you have any idea where i'd turn?  there doen't happen to be a blueprint on it anywhere or something?  it seems like there's no real knowledgebase on where stuff is stored or anything
[07:13] <xtknight> i mean of course i could just google till i got sick, but..
[07:13] <RAOF> I think #ubuntu-devel should have more details.
[07:13] <xtknight> :o
[07:13] <xtknight> ah ok
[07:14] <xtknight> there must be some cache somewhere too, because changing the name in one desktop file makes no difference.
[07:38] <\sh> moins
[07:44] <LaserJock> any U-U-S admin types up?
[07:45]  * Hobbsee gave it away.  muhahahaha
[07:46] <LaserJock> anybody know the status of the queue? like is the number of subscribed bugs really what needs to be processed?
[07:48] <Hobbsee> the ones that affect ubuntu and that are open, yes.
[07:48] <LaserJock> bummer :(
[07:48] <LaserJock> I was hoping that a lot were taken care of but were still in the queue
[07:49] <LaserJock> hmm, "I'm not attaching any files as the package is in my PPA" for a 0ubuntu1 doesn't sound like something we want to sponsor at the moment
[07:50] <LaserJock> do we have any good way of saying "not for hardy" ?
[07:51] <\sh> oh damn...
[07:51] <\sh> we have to be careful with all the crap in this queue
[07:51] <Hobbsee> unsub anything that isn't fit for sponsoring?
[07:52] <\sh> bug #195933 e.g. whoever said, "don't patch inside diff.gz, use debian/patches, even if debian package doesn't use a patch system" needs to be crucified
[07:52] <ubotu> Launchpad bug 195933 in subtitleeditor "Doesn't appear in Hardy's Applications menu" [Low,Confirmed] https://launchpad.net/bugs/195933
[07:52] <LaserJock> Hobbsee: but how do we get it back? should we just tell people to resub after Hardy is released?
[07:52] <Hobbsee> LaserJock: will they be correct after hardy release?
[07:52] <Hobbsee> LaserJock: otherwise, i'd say dump as low prio, or something.
[07:54] <LaserJock> Hobbsee: well, I guess an unsub with at "We're unable to sponsor this for Hardy, once Intrepid is opened up feel free to resubmit and updated package?"
[07:55] <Hobbsee> LaserJock: sounds reasonable
[07:57] <LaserJock> k
[08:14] <dholbach> good morning
[08:21] <rzr> hi dholbach
[08:21] <rzr> remember this bug ? https://bugs.launchpad.net/ubuntu/+source/xnetcardconfig/+bug/181494
[08:21] <ubotu> Launchpad bug 181494 in xnetcardconfig "Depends on obsolete xsu package" [Undecided,In progress]
[08:22] <rzr> I made a new "upstream" release that fixes many other stuff
[08:22] <rzr> http://bugs.debian.org/474036
[08:23] <rzr> i plan to merge it back
[08:23] <dholbach> hi rzr - did you get it into the  http://wiki.ubuntu.com/SponsorshipProcess ?
[08:23] <rzr> not yet
[08:23] <rzr> i wanted it to go in debian 1st since i need it at work
[08:23] <rzr> well have to go
[08:23] <rzr> later
[08:49] <raphink> hi guys
[08:56] <\sh> hey raphink :)
[08:57] <raphink> hi \sh
[08:57] <\sh> raphink, how's life? long time no see :)
[08:58] <raphink> life's good, thanks God :)
[08:58] <raphink> how are you doing?
[09:03] <\sh> raphink, the flue got me
[09:04] <raphink> ouch
[09:04] <\sh> raphink, but it's ok...new job, new opportunities...and ubuntu rollout on the 22nd of april :)
[09:04] <raphink> hehe
[09:04] <raphink> \sh do you happen to be familiar with hushlogins ?
[09:06] <\sh> raphink, nope...what is it? any pointer? :)
[09:06] <raphink> when you touch ~/.hushlogin, the user will not get motd+lastlog at login
[09:06] <raphink> this works
[09:06] <raphink> but
[09:06] <raphink> in login.defs, you can set HUSHLOGIN_FILE to something else, /etc/hushlogins by default
[09:06] <raphink> in order to control this functionnality systemwide
[09:07] <raphink> in that case, you put either user names of shell names in /etc/hushlogins
[09:07] <raphink> and it's supposed to deactivate the chatter at login for these users/shells
[09:07] <raphink> but it doesn't work in etch or gutsy
[09:07] <\sh> but hardy works?
[09:07] <raphink> no idea
[09:08] <raphink> I don' thave a hardy machine here
[09:08] <raphink> I would like to use this feature because I use a special shell to wrap ssh and redirect some users to another machine silently
[09:08] <\sh> raphink, looks like...I just tested it on my home machine
[09:08] <raphink> but I don't want them to have the first motd
[09:08] <raphink> \sh did you test with /etc/hushlogins or with ~/.hushlogin ?
[09:08] <\sh> raphink, touch .hushlogin
[09:09] <raphink> yes, that always works
[09:09] <raphink> but /etc/hushlogins doesn't work
[09:10] <\sh> raphink, I tried to test it with /bin/bash -> doesn't work...or my username, doesn't work
[09:10] <raphink> yes
[09:10] <raphink> so it seems it's broken
[09:10] <\sh> oh wairt
[09:11] <\sh> in /etc/login.defs /etc/hushlogins is not enabled by default it seems
[09:11] <raphink> no, indeed, you have to activate it
[09:11] <raphink> and restart ssh
[09:11] <raphink> I did that, and it didn't work
[09:11] <raphink> http://sudan.ubuntuforums.com/showthread.php?t=10084 seems to indicate that it worked in october 2004
[09:11] <raphink> sorry in jan 2005
[09:12] <\sh> same here
[09:12] <raphink> I can't find a bug reprot about it
[09:15] <\sh> hmm...much more problems.../etc/init.d/ssh restart doesn't work
[09:16] <\sh> it checks first the port...and then it fails because something is already listening on port 22...which is correct..but shouldn't fail and it should be restarted..
[09:16] <jimiridge> netstat -anp |grep 22
[09:17] <raphink> ah
[09:17] <\sh> jimiridge, it's normal behaviour when something is already listening..the problem with it: it should kick all sshd and restart the father process
[09:17] <jimiridge> why is making a package so darn involving
[09:18] <raphink> involving?
[09:18] <jimiridge> checkinstall never works right, dh_make  doesnt work for me...
[09:18] <jimiridge> like i'm using aircrack svn as a testbed
[09:19] <raphink> dh_make doesn' twork? how so?
[09:22] <jimiridge> i dunno i'll fix it
[09:23] <jimiridge> im just saying find the pid thats taking port 22 and do a  "kill pid & /etc/init.d/ssh restart"
[09:24] <jimiridge> hoping it will restart before you get dropped
[09:25] <slytherin> jimiridge: Please use nicknames to address the person. Otherwise it is difficult to carry a meaningful conversation
[09:26] <\sh> raphink, #ubuntu-devel
[09:28] <jimiridge> slytherin, ok
[09:35] <huats> morning all
[11:27] <doko> pochu: afaik, no
[11:53] <stani> ScottK: The latest phatch bug #210602 is fixed. I've requested the latest translations and will release Phatch 0.1.3 so it can be uploaded to Debian and Hardy.
[11:53] <ubotu> Launchpad bug 210602 in phatch "run in bash ends in an error" [High,Fix committed] https://launchpad.net/bugs/210602
[12:15] <fbond> Is usbfs now on /dev/bus/usb, rather than /proc/bus/usb ?
[12:17] <broonie> fbond: No but the information that used to be exported via /proc/bus/usb is now there.
[12:40] <ScottK> stani: OK.  pochu and I know when it's released.
[12:51] <Iulian> Heya
[12:52] <pochu> ScottK: I don't... I need to add uscan to cron...
[12:55] <zul> morning
[12:57] <ScottK> pochu and stani: ... let ...  - Missed an important word there.
[12:57] <ScottK> morning zul.
[13:05] <ScottK> Lovely.
[13:05] <ScottK> Clamav is planning a major release on the 14th.
[13:05] <StevenK> Fun
[13:06] <achadwick> I'd like to do something in my package's postinst that shouldn't happen as root. Is there a standard user I should run this as? nobody? (assuming I chown the files that get created as a result afterwards)
[13:08] <ScottK> StevenK: First two letters are right.
[13:10] <ScottK> Soname bump too.
[13:14] <ScottK> Of course soname bump makes it easy to say no.
[13:15] <Iulian> Fujitsu: ping - do you have one minute for a /query?
[13:23] <mok0> ScottK: AFAICS python-scipy still depends on atlas3-base
[13:25] <mok0> no sorry, my bad
[13:25] <mok0> I was looking at an older version
[13:27] <ScottK> jdong: Ping.
[13:27] <Fujitsu> Iulian: Sure.
[13:34] <ScottK> pochu: Are you up for doing phatch again?
[13:38] <stani> ScottK: I am back here (was on my hardy box busy releasing Phatch).
[13:38] <stani> ScottK: what you mean with "... let ..."
[13:39] <ScottK> I still can't type.
[13:39] <ScottK> stani: I meant to say let us know, which you have now done.
[13:39] <stani> ok
[13:40] <pochu> ScottK: I think so, looking
[13:40] <ScottK> pochu: Great.  Once against I'd suggest uploading straight to Ubuntu for now.
[13:41] <pochu> sure, I'll update python-apps and upload to ubuntu too
[13:41] <stani> pochu: thanks
[13:41] <ScottK> Great.
[13:41] <Hobbsee> ScottK: so, how good is clamav
[13:42] <Hobbsee> ScottK: ah yes, it found it.  good.
[13:42] <ScottK> Hobbsee: Well, I asked if there was going to be another RC before the final release.  They said no.  No one tests the RC's anyway so we may as well release.
[13:42] <ScottK> I'm pretty sure we don't want it.
[13:42] <Hobbsee> heh
[13:43] <ScottK> That and the soname bump.
[13:43]  * Hobbsee was pleased to see it suceeded with a fairly new virus.
[13:43] <ScottK> I'm planning to talk to jdong about getting hardy-backports ready early with the idea that we might have clamav and redepends in backport at or near release.
[13:43] <stani> ScottK and pochu: Good news: I got an invitation from the libre graphics conference to give a talk about Phatch. (I hope to do it, but I have to be able to free my agenda for it. So it is not sure.)
[13:44] <ScottK> stani: Congratulations.
[13:44] <pochu> stani: wow, that sounds cool!
[13:45] <stani> stani: It would be nice to meet up with the gimp, inkscape, ... developers.
[13:46] <slytherin> ScottK: Just FYI ... I created a patch from the revision 259 for screenlets yesterday but was too tired to test it. Will do it today probably
[13:46] <ScottK> slytherin: Great.
[13:47] <Hobbsee> ScottK: any idea on where to start for informatoin on pulling viruses apart?
[13:48] <ScottK> Hobbsee: No.  Not really.
[13:48] <pochu> stani: there's no changelog in phatch, is there?
[13:48] <ScottK> clamav is a magic scary black box to me.
[13:48] <Hobbsee> ScottK: pity.
[13:49] <ScottK> Sorry I can't help.
[13:51] <Kamping_Kaiser> hi all. i have a bug open against sugar in ubuntu (cant login). is there a 'best way' to get it either fixed or removed? it seems like a pretty awquard thing to do - include it but have it unusable
[13:51] <Hobbsee> np
[13:52] <stani> pochu: no, not really, however there is one on the internet http://ubuntuforums.org/showthread.php?t=466598 ;-)
[13:53] <slytherin> Hobbsee: what kind of information do you need about anti-virus? I don't claim to be expert so I will try to answer.
[13:54] <Hobbsee> slytherin: just wanted to know how to decompress it, so i can view what was inside the .exe
[13:55] <Kamping_Kaiser> night all. might ask again tomorrow :)
[13:55] <slytherin> Hobbsee: oh, so you have a sample virus?
[13:56] <Hobbsee> slytherin: yeah.  few 'doze idiots got infected with it, and tried to send it to me.
[13:57] <slytherin> Hobbsee: clamav should help you scan a particular file. But I am not sure if you can dissect a virus on your own.
[13:57] <Hobbsee> slytherin: hmmm
[13:57] <pochu> stani: I'm a bit unsure about this... are they bug fixes? http://pastebin.com/f7853416a
[13:57] <Hobbsee> slytherin: yeah, scan came back with virus found.
[13:58] <pochu> stani: I haven't looked at the real diff yet, will do so after having lunch
[13:58] <Hobbsee> slytherin: (Trojan.IRCBot-1981)
[13:58] <slytherin> Hobbsee: and if you are planning to install an AV on their machines then clamav or avg are good and free options.
[13:58] <Hobbsee> slytherin: i don't control their machines.  They're friends.
[13:58] <ScottK> superm1: Would you be able to look into what to do about https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-April/003806.html - you touched the package last.
[13:59]  * Hobbsee just wanted to know more about what was in it.
[13:59] <slytherin> Hobbsee: but you can always suggest then a good AV, can't you?
[14:00] <Kamping_Kaiser> by the time someones sending virus's you tell them they better have backups ...
[14:00] <Hobbsee> slytherin: actually,  i was going to yell at them about not clicking on links in msn that are clearly bad first, but....
[14:03] <slytherin> Hobbsee: you know what is best way to spread linux in general. Stop responding to windows troubleshooting questions. :-P
[14:03] <Hobbsee> i wasn't even speaking to either of them!  :P
[14:04] <ScottK> I have recently been known to honestly say, "It's been so long since I used Windows, I don't remember how to do that."
[14:04] <ScottK> Of course at my age that might be just a few weeks.
[14:05] <slytherin> ScottK: True for me too, the first sentence not the age one. :-)
[14:20] <megabyte405> hey folks - wondering if there's a variable substitution I can use to get the version of the original (upstream) package in my rules file
[14:21] <TheMuso> megabyte405: You could get it from the changelog.
[14:21] <TheMuso> megabyte405: as in debian/changelog.
[14:21] <ScottK> With awk and sed or some such.
[14:21] <TheMuso> In fcat, I've seen several packages do that.
[14:21] <TheMuso> in fact
[14:22] <megabyte405> oh boy, that sounds like a little hack.  I'll put that enhancement on the bug list then
[14:23] <megabyte405> dholbach: I'm packaging AbiWord for sponsorship to main.  There is a compile-time dependency on libasio-dev, which is a collection of headers, currently in universe.  This is not a run-time dep.  Is this OK?
[14:23] <Fujitsu> You'd have to get it promoted.
[14:23] <megabyte405> even just for compile time?  What sort of process is there to do that?
[14:23] <Fujitsu> Even for compiletime.
[14:23] <megabyte405> ok
[14:24] <slytherin> megabyte405: say !mir
[14:24] <dholbach> megabyte405: let's discuss on #ubuntu-devel
[14:24] <Fujitsu> It will require a MainInclusionReport, I presume. I've never done it myself, so am not sure of the details.
[14:24] <megabyte405> !mir
[14:24] <ubotu> mir is Main Inclusion Report - see https://wiki.ubuntu.com/MainInclusionProcess for more information.
[14:31] <stani> pochu: That is updated artwork. If you look at it, you see the icon is updated.
[14:35] <stani> pochu: I have to switch computer (I will dissappear and come back).
[14:36] <stani> pochu: I am back
[14:57] <pochu> stani: I see
[14:57] <stani> pochu: is updating artwork a problem?
[14:58] <stani> my icon designer did his best and would have like it included.
[14:58] <stani> pochu: it can not introduce any bug, it is outside programming logic just as translations
[15:01] <emgent> heya
[15:05] <pochu> stani: no, don't think so as phatch isn't in main and it's not documented in the Ubuntu documentation
[15:05] <pochu> ScottK: ^-- does UI Freeze apply here?
[15:10] <stani> pochu: scale.py had wrong credits for the icon
[15:11] <ScottK> Hmm.
[15:11] <ScottK> Not sure.  It's changing the icon?
[15:11] <ScottK> pochu: ^^^
[15:13] <pochu> ScottK: yes
[15:13] <stani> ScottK: it changes some icons in http://photobatch.wikidot.com/local--files/getting-started/actions-scale.png
[15:14] <stani> it does not change the main Phatch icon
[15:15] <ScottK2> Hobbsee: It seems this is harmless.  What's the rule on this ^^^?
[15:16] <Hobbsee> ui freeze?  unsure
[15:17] <ScottK2> It seems totally unlikely to actually be a problem.  I'm not sure if there is some paperwork required though.
[15:26] <ScottK2> slangasek: Are we violating any U/I freeze if we change the icon in a Universe package at this point?  ^^^
[15:27] <stani> If I read https://wiki.ubuntu.com/UserInterfaceFreeze, I don't see that any of the points apply to Phatch (not installed by default, no desktop, no distribution specific, no user-visible string).
[15:27] <ScottK2> I agree in principle, but want to make sure.
[16:08] <ScottK2> pochu: I'd say go for it.
[16:09] <sebner> heya afflux ;)
[16:09] <afflux> hey sebner
[16:09] <stani> ScottK: thanks
[16:10] <afflux> I just opened bug 213385, which actually is a request for sponsoring multiple bugfixes for screenlets. Feel free to contact me if something is wrong or could be done better :)
[16:11] <ubotu> Launchpad bug 213385 in screenlets "candidate for version 0.0.12-0ubuntu4" [Medium,New] https://launchpad.net/bugs/213385
[16:11] <ScottK2> afflux: I think slytherin was also looking at that.  I'd suggest you coordinate on a common upload so things don't get cross threaded.
[16:12] <afflux> huh, really? I subscribed the bugmail for screenlets and didn't notice anyone working on this
[16:12] <afflux> *this package
[16:12] <ScottK2> He mentioned it on IRC.
[16:13] <ScottK2> afflux: From ~3 hourse ago:
[16:13] <ScottK2> [08:46] <slytherin> ScottK: Just FYI ... I created a patch from the revision 259 for screenlets yesterday but was too tired to test it. Will do it today probably
[16:13] <afflux> argh
[16:14] <afflux> assigned all bugs that were fixed with 259 to me yesterday night :(
[16:14] <afflux> okay
[16:14] <afflux> do you think it's okay to subscribe him and ask for his input/opinion? I had a talk with the upstream dev about some changes and we coordinated better fixes for some issues.
[16:14] <ScottK2> Thus I suggest some coordination.  I haven't seen a diff from him.
[16:14] <ScottK2> Yes.
[16:14] <ScottK2> slytherin: ^^^^
[16:16] <afflux> okay, thank you!
[16:18] <pochu> ScottK2, stani: uploading
[16:18] <stani> pochu:great
[16:24] <ploum> Hello
[16:24] <ploum> could some MOTU check bug #201509 ?
[16:24] <ubotu> Launchpad bug 201509 in gweled "Get rid of .gweled file and follow fd.o specifications" [Undecided,In progress] https://launchpad.net/bugs/201509
[16:24] <ploum> thanks
[16:28] <ScottK> ploum: I'd be a lot more comfortable with something like that if you didn't abandon old user preferences, but the bigger issue is how do you handle this for multi-user systems?  AFAIK your patch will only change things for the user doing the upgrade.
[16:28] <ScottK> Skip that last bit.
[16:28] <ploum> yep, it would be handled by gweled itself
[16:28] <ScottK> Abandoning the old user preferences is not a good thing.
[16:29] <ploum> Indeed but there's only one thing in it, AFAIK ;:
[16:29] <ScottK> OK.  If you think it's OK to abandon them, you ought to make some case for it in the bug.
[16:29] <ploum> the size of the board
[16:30] <ploum> so, the only thing that will happen is that some user will see the size of the board resetted to "medium" instead of large and small
[16:30] <ploum> I think adding backward compatibility code for such a little thing is too much overhead
[16:30] <ScottK> As I said, explain it in the bug.
[16:31] <ploum> Maybe a warning could be added to the release not
[16:31] <ploum> Ok
[16:31] <ploum> I do that now
[16:35] <ploum> ScottK : done
[16:35] <ploum> I've checked the source to be sure
[16:35] <ScottK> OK.
[16:36]  * ScottK doesn't know much about Gnome, so is not going to decide, but that should improve your chances.
[16:40] <ploum> It's not gnome related
[16:40] <ploum> (but the game uses Gtk)
[16:41] <RainCT> ploum: fine then :)
[16:42] <ScottK> ploum: Close enough for me to ignore it.
[16:42]  * RainCT thought it saved more than one preference :P
[16:44] <ploum> RainCT: in fact two : there was also the game type
[16:44] <ploum> three boolean :
[16:45] <ploum> width, height, gametype
[16:45] <ploum> three int
[16:45] <ploum> I added a boolean : music on/off
[16:46] <norsetto> huats: there he is ... finished messing with main!?
[16:46] <huats> :)
[16:47] <slytherin> afflux: if you have already finished the necessary work then please go ahead. I haven't done any testing and not sure if will do it tonight.
[16:48] <ScottK> Heya norsetto.
[16:48] <RainCT> ploum: I'll have a look (and hopefully upload) it later today ;)
[16:49] <norsetto> heya scottk
[16:49] <ploum> RainCT: thanks :-)
[16:50] <afflux> gah, I'm too slow.
[16:50] <ScottK> afflux: Is your screenlets update ready for upload (i.e. you've tested it)?
[16:51] <sebner> norsetto: huhu :D :D :D
[16:51] <afflux> ScottK: It builds and installs fine, all the feates I'm able to test are working. There've been some crashes I've not been able to trigger, but the fixes look sane and pycentral doesn't complain when compiling the files.
[16:52] <ScottK> afflux: Are you subscribed for screenlets bugs?
[16:52] <afflux> yes
[16:52] <norsetto> sebner: huhu to you too (wasn't that a norwegian band from the 80s ....)
[16:52] <ScottK2> OK.
[16:52] <warp10> hey norsetto!
[16:53] <ScottK2> afflux: I'll have a look at it and upload if I can't find anything serious to complain about.
[16:53] <afflux> many thanks. So no need to resubscribe u-u-s?
[16:53] <norsetto> warp10: Hola master ;-)
[16:53] <sebner> norsetto: dunno. I pushed the debdiff to kapil. he seems to be happy with it. As soon as why has an upstream ACK I'll upload it and you can check it :)
[16:54] <sebner> *we
[16:54] <norsetto> sebner: okki dokki
[16:54] <sebner> fine
[17:07] <ScottK> afflux: No.  Looking at it now.
[17:07] <ScottK> afflux: Is it correct that screenlets b-d on itself?
[17:08] <afflux> huh, didn't notice that one
[17:08] <afflux> had no changes on the control file so didn't touch it
[17:08] <ScottK> That's what's there.  I'd appreciate if you'd check that's actually needed.
[17:09] <afflux> is checking if it builds and in installs enough?
[17:10] <ScottK> I'd think so.
[17:11]  * norsetto -> afk
[17:13] <ScottK> afflux: Build fails without it.
[17:13] <ScottK> afflux: You might mention to upstream that needing itself to build is somewhat evil.
[17:13] <afflux> indeed
[17:15] <ScottK> afflux: Uploaded.  Thank you for your contribution to Ubuntu.
[17:15] <afflux> thank you.
[17:25] <macogw> does featurefreeze mean it's too late to get upstream gsynaptics synced?
[17:25] <macogw> it does speed & accel now. the one in universe doesn't.
[17:28] <pochu>  boson      - core package for Boson
[17:28] <pochu>  boson-dbg  - debugging symbols for boson
[17:28] <pochu> yay nice descriptions!
[17:28] <sebner> pochu: boson? yes? my merge?
[17:28] <ScottK> macogw: It means it needs an exception.  May or may not be given.
[17:29] <ScottK> macogw: wiki.ubuntu.com/FreezeExceptionProcess
[17:30]  * norsetto <- afk
[17:31] <RainCT> pochu: lol
[17:31] <RainCT> sebner: you can file a bug about that too (in Debian) :)
[17:32] <pochu> sebner: yes, but not your fault ;)
[17:32] <sebner> RainCT: that's on my list ;)
[17:32] <sebner> RainCT: first I'm waiting if it builds ^^
[17:32] <sebner> pochu: ok then ^^
[17:40] <slangasek> ScottK: the UIFreeze is so that documentation folks don't get their documentation out-of-date without them being aware of it; the chances of them being affected by Phatch are exceedingly small, so use your best judgement - though in any case, the answer should be an "ok to upload", just depends whether ubuntu-docs needs notified
[17:41] <ScottK> slangasek: Thanks.
[17:42] <macogw> ScottK: ok
[17:42] <macogw> thanks
[17:49]  * norsetto goes to test the nth rt2x00 driver
[18:18] <Tonio_> I have a little question, now we are in feature freeze, can a NEW package go in ?
[18:18] <Tonio_> non exisiting package I mean
[18:19] <sebner> Tonio_: not likely
[18:19] <sebner> Tonio_: is it *super* urgent and *important*? If no then no
[18:19] <pochu> not, unless there's a very very good reason for it
[18:20] <pochu> FinalFreeze is this Thursday
[18:20] <Tonio_> to make it simple, my company and canonical are going partners and packaging of our opensource groupware was discussed
[18:20] <Tonio_> it'as just been finished
[18:21] <Tonio_> I think that can be considered a good reason ;)
[18:21] <Tonio_> am I wrong ?
[18:21] <ScottK> Tonio_: I think that might be reasonable.
[18:21] <Tonio_> okay, so I'll have to write an exception, and eventually ping Daniel, since this is a specific context
[18:22] <ScottK> slangasek: ^^^ ? Do you think someone would have time for New processing?
[18:22] <ScottK> Let's get a first order answer from the RM first.
[18:22] <slangasek> ScottK: sourceful NEW?
[18:22] <ScottK> Yes
[18:23] <slangasek> better than 0 chance, but I don't know that it's much better
[18:23] <ScottK> slangasek: ^^
[18:23] <ScottK> OK.
[18:23] <LaserJock> Tonio_: do you have a Canonical rep for it that you could ask?
[18:23] <Tonio_> LaserJock: "rep" ?
[18:24] <LaserJock> contact or representitive
[18:24] <ScottK> Tonio_: What do you think of an early upload to Intrepid and a quick backport?
[18:24] <Tonio_> ScottK: well, politically, I think getting it in the repos would be prefered :)
[18:24] <LaserJock> I did one of those to dapper-updates, but it was a pain afterwards, I wouldn't recommend going that route
[18:25] <ScottK> Tonio_: OK.  Then file your FFe.
[18:25] <Tonio_> ScottK: sure
[18:27] <xtknight> what's the easiest way to find an old version of a package in the debian (unstable) system.  what i'm trying to do is help backport a patch from debian but i need to know what code changed in the debian version first.
[18:28] <leonel> xtknight: the oldest version wil be on debian stable
[18:28] <leonel> xtknight: or in debian oldstable
[18:29] <xtknight> leonel, oh i mean like revisions.  for instance, wine 0.9.58.dsc vs the 0.98.58-1.dsc on unstable now
[18:29] <LaserJock> well, you probably need snapshot.debian.net
[18:29] <ScottK> xtknight: Keep in mind our wine package does not come from Debian's.
[18:30] <xtknight> yeah i saw a wine bug that applied to ubuntu as well here: http://qa.ubuntuwire.com/bugs/rcbugs/
[18:32] <zasf> hi all
[18:32] <zasf> I need a little help on packaging
[18:32] <zasf> I want to test newest gnome-applets
[18:32] <zasf> so I downloaded it from svn
[18:33] <zasf> I did a svn export and tarred it so that it is named gnome-applets_2.23.0.orig.tar.gz
[18:33] <zasf> is there a particular tar command I have to use?
[18:33] <zasf> when doing 'debuild -S -sa'
[18:33] <ScottK> xtknight: I'd suggest talking about it with YokoZar.
[18:33] <zasf> it gives
[18:33] <zasf> gzip: stdin: not in gzip format
[18:33] <zasf> dpkg-source: failure: gzip gave error exit status 1
[18:33] <zasf> debuild: fatal error at line 1247:
[18:34] <xtknight> ScottK, ok
[18:34] <ScottK> He generally tracks the Debian package pretty closely even though he doesn't use it.
[18:35] <xtknight> apparently wine doesn't use a patching system so the fix kind of got lumped in with everything else, 400000 lines of changes from the original
[18:37] <xtknight> either that or i dont know what "diff splash" is, there's no patches folder
[18:37] <james_w> zasf: tar xzf should be sufficient.
[18:41] <zasf> james_w: tar czf did it, thanks
[18:41] <james_w> zasf: ah, c, sorry.
[18:41] <zasf> hehe :)
[18:42] <pschorf> xtnight: I've got hardy installed, if you'd like to look at that patch again
[18:42] <xtknight> i'm a little confused.  the original version of a package as uploaded to debian still has a .diff.gz right?  then how do i find the original .diff.gz?  i want to find what changed between the original DEBIAN version and -1
[18:42] <xtknight> pschorf, ah cool. sure
[18:42] <xtknight> pschorf,  bug 204600
[18:42] <ubotu> Launchpad bug 204600 in amule "[hardy] Fix Spanish translation of aMule" [Undecided,Fix committed] https://launchpad.net/bugs/204600
[18:43] <pschorf> alright
[18:43] <pschorf> i've still got the source
[18:43] <pschorf> wait...i had an old version
[18:43] <xtknight> you did "apt-get source" again for hardy though right?
[18:43] <pschorf> i'll update
[18:43] <xtknight> delete all traces of old source
[18:44] <xtknight> at this moment it wont do us any good
[18:45] <james_w> xtknight: http://snapshot.debian.net/cgi-bin/packages.cgi
[18:45] <james_w> ah, sorry, type "wine" in the top search box, and then click "details" next to the wine package.
[18:45] <xtknight> james_w, yeah i didn't see the original dsc
[18:46] <xtknight> or is -1 the first one
[18:46] <xtknight> i'm confused
[18:47] <james_w> yeah, -1 is the first upload of a new upstream version.
[18:47] <pschorf> xtnight: i have the new source and ran build-dep
[18:47] <xtknight> so some guy just slipped in a patch with the original version?
[18:47] <xtknight> argh
[18:47] <xtknight> that's going to be impossible to find :p
[18:47] <xtknight> pschorf, ok
[18:47] <james_w> xtknight: this is an upstream patch, or a patch added by Debian?
[18:48] <xtknight> james_w, not sure.  it's this http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472650
[18:48] <ubotu> Debian bug 472650 in wine "FTBFS on amd64 (missing stamp)" [Serious,Fixed]
[18:48] <xtknight> which was on here.  it said ubuntu needed the patch.  http://qa.ubuntuwire.com/bugs/rcbugs/
[18:49] <xtknight> the ubuntu version is 0.9.58-0ubuntu2
[18:49] <xtknight> so i thought -1 was newer or something
[18:49] <james_w> xtknight: ah, that doesn't know whether the bug actually affects Ubuntu
[18:49] <xtknight> oh
[18:49] <james_w> yes, -1 is newer.
[18:49] <xtknight> -0 is the first on ubuntu?
[18:50] <james_w> it's just saying that there is a bug fixed in the newer Debian version, and Ubuntu doesn't have that version.
[18:50] <xtknight> pschorf, alright copy the patch to deiban/patches as we did before
[18:50] <james_w> if Ubuntu uploads a new upstream before Debian it is given a -0ubuntu1 version number, so that it uses the new upstream version, but is still lower than Debian so that all the tools still work the same way.
[18:51] <pschorf> xtnight, ok
[18:51] <xtknight> ah
[18:51] <james_w> as ScottK the Ubuntu wine package isn't based on the Debian one, so it's very unlikely that bug actually affects Ubuntu.
[18:51] <xtknight> i see
[18:51] <ScottK> xtknight: Since the bug was it wouldn't build on 64 bit systems, it's a safe bet if ours built on amd64, we don't have the bug.
[18:52] <xtknight> yeah
[18:52] <xtknight> i was wondering that
[18:52] <james_w> if you wanted to find what he did though you could grab that -1 and the previous version, and then debdiff them, and use filterdiff (or just your eyes) to find the changes to debian/rules.
[18:52] <xtknight> i just built it on my amd64
[18:52] <xtknight> so confirmed not an issue
[18:52] <ScottK> xtknight: Please leave a comment to that effect on the RC bugs page.
[18:52] <xtknight> k
[18:53] <pschorf> xtnight, i've edited the series file the same way we went through yesterday
[18:53] <xtknight> pschorf, ok
[18:53] <xtknight> pschorf, you gave the patch an appropriate name?
[18:54] <xtknight> pschorf, i think the original name is good
[18:54] <pschorf> i kept it as fixed_spanish_translation
[18:54] <xtknight> fixed_spanish_translation.diff
[18:54] <pschorf> right
[18:54] <xtknight> pschorf, alright.  so we determined yesterday this was a package in Universe, but the Maintainer field was set fine
[18:54] <pschorf> right
[18:55] <xtknight> pschorf, the next thing we need to do is add your changes to a log
[18:55] <xtknight> pschorf, go back to the amule root dir
[18:55] <xtknight> pschorf, and type "dch -i"
[18:55] <pschorf> ok
[18:56] <pschorf> i have the changelog open
[18:56] <xtknight> pschorf, so, it creates a new changelog entry for you.  at the top you can see your new revision is named -0ubuntu4
[18:56] <xtknight> dch -i does the versioning for you
[18:56] <pschorf> ok
[18:56] <xtknight> pschorf, you should come up with a name <email>
[18:57] <xtknight> the same one in your GPG key, if you have one
[18:57] <pschorf> my version is 2.2.0~svn20080218
[18:57] <pschorf> is that correct?
[18:57] <xtknight> amule (2.2.0~svn20080218-0ubuntu4) hardy; urgency=low
[18:57] <xtknight> it should be this complete thing
[18:57] <pschorf> right
[18:57] <xtknight> k
[18:57] <xtknight> the current in hardy is 0ubuntu3 therefore you new revis 4
[18:57] <xtknight> do you have a GPG key?
[18:57] <pschorf> my email is incorrect, though<EMAIL_ADDRESS>[18:58] <pschorf> yes, the email on my key is<EMAIL_ADDRESS>[18:58] <xtknight> gpg --list-keys
[18:58] <xtknight> and match your name and email and enter it in the changelog
[18:58] <pschorf> how do I change the one in the changelog?
[18:58] <xtknight> you are in an editor (dch -i) right now
[18:59] <pschorf> ah, it was vi
[18:59] <pschorf> took me a second
[18:59] <xtknight> nano for me
[18:59] <xtknight> hmm
[18:59] <pschorf> ok, i fixed the email
[18:59] <xtknight> there's an automated way to have your name<email> put there properly every time i just cant remember
[18:59] <pschorf> i think my EDITOR variable points to vim
[19:00] <pschorf> i just save the changelog now?
[19:00] <xtknight> did you add a description of your changes?
[19:00] <xtknight> let's credit the original poster of the patch, and reference the LaunchPad(LP) bug for it
[19:00] <pschorf> no...does that go where they currently have an asterisk?
[19:00] <pschorf> ok
[19:00] <xtknight> yes
[19:00] <xtknight> by the way the maximum line length is 80 lines
[19:00] <Daviey> $ which editor
[19:00] <Daviey> /usr/bin/vim_sux
[19:01] <xtknight> err 80 chars
[19:01] <pschorf> haha
[19:01] <pschorf> i assumed that was what you meant
[19:03] <pschorf> Fixes bug #204600 in LP, fix posted by Festor Wailon Dacoba
[19:03] <ubotu> Launchpad bug 204600 in amule "[hardy] Fix Spanish translation of aMule" [Undecided,Fix committed] https://launchpad.net/bugs/204600
[19:03] <pschorf> is that decent?
[19:04] <xtknight> say something like "Fix Spanish translation bug, original patch from Festor Wailon Dacoba. (LP: #204600)"
[19:05] <xtknight> you want a concise description of what is affected, the original author of the patch, and then "(LP: #xxxxxx)"
[19:05] <pschorf> ok
[19:05] <pschorf> now I save?
[19:06] <xtknight> ya
[19:06] <xtknight> ctrl+O
[19:06] <xtknight> or w/e
[19:06] <pschorf> ok
[19:07] <xtknight> if you're using vi it's ESC :wq
[19:07] <pschorf> right
[19:07] <pschorf> or :x
[19:07] <xtknight> ok
[19:07] <xtknight> so as long as that line didnt exceed 80 chars
[19:07] <xtknight> it looks like we're about done
[19:07] <xtknight> with that, at laest
[19:08] <pschorf> alright, what's next?
[19:08] <xtknight> pschorf, now we can test your package
[19:08] <xtknight> basically "fakeroot debuild -S" to build and sign with your GPG key your changes and build packages for you to test
[19:08] <ScottK> Glad sabdfl posted to planet so we know he likes Ubuntu.

[19:09] <pschorf> that was successful
[19:10] <xtknight> oh already?
[19:10] <xtknight> it took me like 30 mins to compile that :p
[19:10] <nixternal> ScottK: gahahahahhahahaha, I just spit coffee you ass :)
[19:10] <ScottK> Excellent
[19:11] <emgent> heya people
[19:11] <pschorf> xtnight, it only took a minute or so...is it possible something went wrong?
[19:11] <xtknight> pschorf, one moment let me try what i told you
[19:12] <xtknight> oh ditch the fakeroot
[19:12] <xtknight> it didnt work for me at least
[19:12] <pschorf> i had to sudo
[19:12] <xtknight> hmm ok
[19:12] <xtknight> yeah
[19:12] <pschorf> but i have -0ubuntu4.dsc and .diff files now
[19:12] <xtknight> duhh i told you the wrong thing
[19:13] <xtknight>  -S makes only a signed changes files
[19:14] <pschorf> do i need to pass another option?
[19:14] <xtknight> well i've run into this before.  unfortunately i'm not really sure how to get it back to the original state.  what we should have run is "sudo debuild"
[19:14] <ScottK2> debuild -S will sign both .dsc and .changes
[19:14] <ScottK2> No.
[19:14] <ScottK2> Just debuild -S should be sufficient
[19:15] <xtknight> we want binary pkgs to test
[19:15] <ScottK2> Ah.
[19:15] <ScottK2> Then no -S
[19:15] <xtknight> but -S seems to have destroyed something
[19:15] <xtknight> because now "sudo debuild" wont work
[19:15] <ScottK2> Shouldn't have.
[19:15] <xtknight> ive had this happen twice
[19:16] <pschorf> mine seems to be building
[19:16] <ScottK2> Try dpkg-buildpackage -(I can't remember which option) fakeroot
[19:16] <pschorf> its checking the environment
[19:16] <xtknight> Patch fixed_spanish_translation does not exist
[19:17] <xtknight> ...
[19:17] <xtknight> make: *** [debian/stamp-patched] Error 1
[19:17] <xtknight> hmm
[19:17] <xtknight> well it's in debian/patches/
[19:17] <xtknight> and it built before.  so not sure what's going on
[19:17] <pschorf> i think mine's ok...i'm getting all of that terminal garbage i associate with building
[19:18] <xtknight> ok
[19:18] <xtknight> yeah i've probably messed so much up on my system :)
[19:18] <pschorf> haha
[19:18] <pschorf> i know the feeling
[19:18] <ScottK2> xtknight: debuild doesn't necessarily leave you with a clean build tree after a binary build.
[19:18] <pschorf> you said this took a half hour or so?
[19:18] <xtknight> ScottK2, i tried sudo debian/rules clean
[19:18] <ScottK2> Only if the clean rule is right.
[19:18] <xtknight> ahhh
[19:18] <ScottK2> If the clean rule was buggy during the build, it won't have gotten better
[19:19] <xtknight> does that mean i need to add something to clean if i add a patch?
[19:19]  * ScottK2 hands xtknight a pbuilder
[19:19] <xtknight> pschorf, ya i think so
[19:19] <xtknight> yeah i was about to mention that
[19:19] <xtknight> why dont we try that next :p
[19:19] <ScottK2> Didn't we discuss the merits of building in a clean chroot yesterday?
[19:19] <pschorf> xtnight, i'm going to sign off and let it run while I walk to the CS building here on campus
[19:19] <xtknight> pschorf, ok
[19:20] <xtknight> ScottK2, hmm vaguely
[19:20] <pschorf> be back around 2
[19:20] <ScottK2> In any case what you've got now is useful for figuring out what's missing out of clean and fixing that while you're at it.
[19:20] <ScottK2> You should be able to build twice in a row.
[19:20] <ScottK2> If it doesn't, it's a bug in the package.
[19:33] <LaserJock> who wants to run some Hug Days? :-)
[19:35] <xtknight> weird.  pdebuild fialed.  can anyone tell me what the problem is? http://rafb.net/p/f9CTEK27.html
[19:35] <xtknight> besides coudlnt satisfy build deps but that seems odd since i can build it on my real machine
[19:37] <afflux> are packaged translations translating a string which is not translated (ie. gettext is not used for it) evil?
[19:40] <afflux> err, never mind...
[19:40] <Syntux> Good evening
[19:49] <mohi> hi :)
[19:49] <mohi> how can I add a deb pakage to my PPA in launchpad?
[19:49] <xtknight> mohi, follow ppa quickstart https://help.launchpad.net/PPAQuickStart
[19:50] <pschorf> xtnight, the build finished
[19:50] <xtknight> pschorf, ok
[19:50] <ScottK> mohi: PPA support is in #launchpad.  It's nothing to do with Ubuntu.
[19:50] <pschorf> do I need to send my public key to a keyserver?
[19:50] <xtknight> pschorf, for ppa? yes
[19:50] <xtknight> otherwise not for what we're doing right now
[19:51] <xtknight> pschorf, let's test your package
[19:51] <pschorf> ok
[19:52] <xtknight> well this is a little more difficult since it's a spanish translation but uhh..to be honest with you, i dont think it really needs "testing" in that way since you just changed a text file.  i dont see a potential for failure there.  but we should verify that the file was changed.
[19:52] <james_w> xtknight: if you are build-depending on a virtual package then I think you need to make it "real_package | virtual_package"
[19:52] <xtknight> james_w, hmm all i'm trying to do is pdebuild basically
[19:53] <xtknight> pschorf, so this build will have made a dsc file and changes
[19:53] <xtknight> pschorf, type "cd .." to see
[19:53] <xtknight> pschorf, your new revision is labeled ubuntu4
[19:53] <pschorf> right
[19:54] <xtknight> pschorf, let's make a diff
[19:54] <xtknight> between ubuntu3 and ubuntu4
[19:54] <xtknight> the format is, "debdiff oldfile newfile > patchfile.diff"
[19:54] <xtknight> we will use the .dsc files for this
[19:54] <pschorf> ok
[19:54] <pschorf> what would specifically?
[19:55] <xtknight> pschorf, debdiff amule_2.2.0~svn20080218-0ubuntu3.dsc amule_2.2.0~svn20080218-0ubuntu4.dsc > amule_2.2.0~svn20080218-0ubuntu4.debdiff
[19:55] <xtknight> pschorf, pastebin the contents of the resulting debdiff file so i can see http://rafb.net/paste/
[19:57] <pschorf> http://rafb.net/p/dXfc4766.html
[19:58] <xtknight> looks good to me.  i'd put (LP: #204600) on one line but that's minor
[19:59] <pschorf> i'll keep that in mind
[19:59] <xtknight> i wish i could tell you how to change it without recompiling the whole thing
[19:59] <xtknight> i'm sure someone else here knows though
[20:00] <xtknight> but anyway good job you basically made your first patch
[20:00] <xtknight> if the repo managers see that as a problem then they'd tell you.  i doubt it's a problem for now
[20:00] <pschorf> ok
[20:00] <xtknight> i've seen far worse ;)
[20:01] <pschorf> do I actually upload this, or is it a sort of proof of concept
[20:01] <xtknight> we can actually upload this
[20:01] <xtknight> first let's test and see if the file contains the changes we expect
[20:01] <xtknight> install your debs
[20:01] <pschorf> would I use the _all or the _i386 deb
[20:02] <xtknight> btw i think you would do "dch -e" to edit changelog and fix it, then debuild again
[20:02] <xtknight> sinec mine's screwed up i dunno
[20:02] <xtknight> umm what is the full name of both files?
[20:02] <xtknight> did it generate two?
[20:02] <pschorf> amule-common_2.2.0~svn20080218-0ubuntu4_all.deb
[20:02] <xtknight> the package "amule" is a source package, from which many binary packages may be derived
[20:02] <greg-g> slangasek: question regarding bug 212017
[20:02] <ubotu> Launchpad bug 212017 in evince "Evince/CUPS Could Not Print Tax Document" [Medium,Incomplete] https://launchpad.net/bugs/212017
[20:02] <xtknight> so yea we got amule-common which is architecture indepednent
[20:03] <pschorf> there's a daemon package and to util packages also
[20:03] <slangasek> greg-g: hi
[20:03] <greg-g> slangasek: I changed the description to be closer to the ligature issue, not the printing issue, shall I change it back?
[20:03] <xtknight> pschorf, well you need to install all the pkgs
[20:03] <xtknight> pschorf, sudo dpkg -i *.deb
[20:04] <slangasek> greg-g: well, let's see what cmnorton has to say - if his printing issue is only with this one form, and he's not personally interested in it but was just following up on a forum thread, it may be that it's best to use this bug to track the ligature issue
[20:05] <greg-g> slangasek: good point.  I however was able to confirm the non-printing issue in Gutsy (didn't try in Hardy yet).
[20:05] <pschorf> xtnight, i installed the deb files
[20:05] <xtknight> i know i alread ymentioned it but this is another printing problem Bug 150187
[20:05] <ubotu> Launchpad bug 150187 in poppler "[gutsy] [regression] Evince has very bad quality when printing pdf files." [Unknown,Confirmed] https://launchpad.net/bugs/150187
[20:05] <xtknight> might need to upgrade poppler to fix it and it might also fix bug 212017?
[20:05] <ubotu> Launchpad bug 212017 in evince "Evince/CUPS Could Not Print Tax Document" [Medium,Incomplete] https://launchpad.net/bugs/212017
[20:05] <xtknight> i dont know
[20:05] <greg-g> 9since when I saw the bug report I didn't read the forum thread, just what cmnorton said)
[20:06] <slangasek> greg-g: oh, is it a general problem with being unable to print, or is it just this one file?
[20:06] <xtknight> pschorf, ok
[20:06] <greg-g> slangasek: so far just this one file
[20:06] <xtknight> pschorf, let's determine where es.po is
[20:06] <xtknight> pschorf, that's the file we changed
[20:06] <slangasek> greg-g: hmm. then maybe it is all the same bug - do you have acrobat reader installed?
[20:06] <xtknight> pschorf, basically go thru each package, with "dpkg -L <package_name> | grep es.po"
[20:06] <pschorf> could I do a locate es.po?
[20:07] <pschorf> ok
[20:07] <xtknight> or that, and then dpkg -S /the/file/you/find
[20:07] <xtknight> but there are many es.po
[20:07] <greg-g> in gutsy yes, but, unfortunately I am at work right now, with no access to my Ubuntu install
[20:07] <xtknight> for every package on the system
[20:07] <xtknight> it's easier to do dpkg -L amule..
[20:08] <pschorf> i didn't get anything from my search
[20:09] <xtknight> hmm me neither
[20:09] <xtknight> i think es.po is compiled into something
[20:09] <xtknight> /usr/share/locale/es/LC_MESSAGES/amule.mo
[20:09] <xtknight> perhaps?
[20:09] <xtknight> that's binary though
[20:09] <xtknight> odd
[20:10] <pschorf> right...i made the mistake of running it through cat
[20:10] <xtknight> well i'm really not sure how to test this then, besides running the spanish build.  you could ask the reporter to try your debdiff.
[20:10] <xtknight> pschorf, hahah
[20:10] <xtknight> me too
[20:10] <xtknight> i dont know why cat always does that
[20:10] <xtknight> just close the console
[20:11] <pschorf> yeah, i restarted it
[20:11] <xtknight> pschorf, in this case since you dont know spanish (i'm assuming), you should ask the reporter of the bug to try your package.  you can make it easier for him to try your package by uploading it to PPA
[20:11] <xtknight> what was it bug 204600 ?
[20:11] <ubotu> Launchpad bug 204600 in amule "[hardy] Fix Spanish translation of aMule" [Undecided,Fix committed] https://launchpad.net/bugs/204600
[20:11] <pschorf> ok
[20:11] <xtknight> yeah
[20:12] <xtknight> pschorf, well since he posted it, he basically confirmed it
[20:12] <greg-g> slangasek: I need to run, feel free to ping me any ideas, my IRC stays open.
[20:12] <xtknight> pschorf, so in this case, let's just upload out fix
[20:12] <xtknight> our
[20:12] <pschorf> ok
[20:13] <xtknight> pschorf, set the bug to Confirmed and assign to No one
[20:13] <pschorf> in LP?
[20:13] <xtknight> yes
[20:13] <xtknight> it should not be "fix committed"
[20:13] <xtknight> afaik
[20:13] <xtknight> there's no fix committed to ubuntu
[20:13] <xtknight> just a simple mistake by the reporter
[20:14] <xtknight> by setting it confirmed/no one, we are getting it ready to be uploaded by MOTU
[20:14] <pschorf> I can't change the status
[20:14] <xtknight> what does it say?  are you logged in?
[20:15] <pschorf> nevermind, not logged in
[20:15] <pschorf> ok, updated
[20:15] <slangasek> greg-g: I'd be interested if you could test removing acrobat reader (when you have a chance) to see if that fixes the printing problem
[20:16] <xtknight> pschorf, now we should add a comment, attaching your debdiff
[20:16] <xtknight> pschorf, just say something like "this debdiff fixes the problem, thank you Festor for the patch",  and then set 'This attachment is a patch', and attach it.
[20:17] <xtknight> check `email me changes` as well because you need to be able to respond and track this bug
[20:17] <xtknight> if the maintainers have a question or request
[20:18] <pschorf> ok
[20:18] <xtknight> pschorf, now we need to subscribe ubuntu-universe-sponsors
[20:18] <xtknight> to get the patch sponsored by the maintainers of the Universe section where amule is located.
[20:19] <xtknight> click subscribe someone else on the left
[20:19] <xtknight> and type ubuntu-universe-sponsors
[20:19] <xtknight> click Add and that's it
[20:20] <pschorf> got it
[20:20] <xtknight> good job you just completed your first patch
[20:20] <xtknight> now preferably we'd check if debian is affected as well since ubuntu often gets packages from debian.  but Emilio said "This is fixed in the upstream tarballs" so we probably dont need to
[20:21] <xtknight> and that's really a whole 'nother process of submitting the bug to debian.org and everything
[20:21] <pschorf> ok
[20:22] <pschorf> how would I know if it's added?
[20:22] <xtknight> you would get an email.  usually the maintainer posts a comment on LP
[20:22] <pschorf> ok
[20:22] <xtknight> he'd say "uploaded" maybe or a list of changes would appear, showing closing that this bug is closed.  and the bug is set to Fix Released if so
[20:23] <xtknight> he sets it to fix released you dont have to worry aobut that.  in fact you should probably never set a bug as fix committed or released unless you know what you're doing.  i neve rhave
[20:24] <xtknight> i am pretty sure 'fix committed' status was incorrect before, because although the fix was committed upstream it was not committed to ubuntu.
[20:24] <pschorf> ok
[20:24] <pschorf> what does upstream mean?
[20:24] <xtknight> well it can mean upstream as in Debian, where ubuntu gets a lot of its packages directly from (especially universe and multiverse)
[20:24] <xtknight> upstream can also mean the project itself, the sourceforge page for it
[20:25] <pschorf> ok
[20:25] <pschorf> if something is fixed upstream, will it necessarily propagate down to debian?
[20:25] <xtknight> when emilio said upstream he probably meant the project.  they link to the project's forum page
[20:25] <xtknight> yes it should propagate eventually to debian unstable
[20:25] <xtknight> so in this case i dont THINK we worry about it.  it's not that critical of a bug anyway
[20:26] <pschorf> right
[20:26] <xtknight> to be honest with you i've only sent bugs to debian once or twice and i'm pretty unfamiliar with it.  i realy dont know how their release schedule works or anything, but it's good practice certainly if it's an important patch
[20:27] <pschorf> ok
[20:27] <xtknight> the easiest way is to submit the bug to the project itself
[20:27] <xtknight> and then it will propagate down to debian anyway
[20:27] <xtknight> sooner or later
[20:27] <xtknight> if it's a critical fix, then ideally you'd let every linux distribution know.  but critical usually entails security fixes and serious vulnerabilities
[20:28] <xtknight> but submitting it to the project ensures that every distro will get a snapshot of the fix
[20:28] <pschorf> ok
[20:28] <pschorf> so this patch would just get applied to the ubuntu deb packages?
[20:28] <xtknight> for now yes
[20:28] <pschorf> ok
[20:29] <pschorf> what keyserver should I send my public key to?
[20:29] <xtknight> pschorf, i'm not sure what you mean
[20:29] <xtknight> well this debdiff file doesnt need to be signed anyway
[20:29] <pschorf> ok
[20:29] <xtknight> actually i dont think you even can
[20:29] <xtknight> i dont know
[20:30] <xtknight> i've never done it anyways, i dont see the benefit of that :P
[20:30] <xtknight> i mean, it doesn't matter if somebody is impersonating you in this case, does it?  the patch is there and working, isn't it? hhe
[20:30] <xtknight> and besides it's good press for you: p
[20:34] <xtknight> anyway it usually within a couple months a maintainer will take a look at your patch.  maybe sooner since we're in the testing phase right now.  but if a couple months passes and it doesn't get looked at it, then you may have to lobby in here about it.  otherwise, dont bother
[20:34] <xtknight> pschorf,
[20:34] <pschorf> sorry, i was grabbing something
[20:35] <pschorf> alright
[20:35] <xtknight> generally the bottleneck is not the maintainers, anyway
[20:35] <pschorf> ok
[20:35] <xtknight> when it comes to getting things fixed.  there's always plenty of bugs out there
[20:36] <pschorf> so just keep looking through that website for bugs, and patch like we did above?
[20:36] <xtknight> sure
[20:36] <xtknight> http://daniel.holba.ch/really-fix-it/
[20:39] <xtknight> pschorf, by the way feel free to ask questions
[20:39] <xtknight> pschorf, right now i'd focus on bugs the are confirmed in HARDY, because that's what really needs to be done now
[20:40] <xtknight> if it's only in gutsy's it's going to be more cumbersome to fix ( you need a gutsy chroot ) and you need to file for a Stable Release Update, generally only done with critical fixes.
[20:40] <james_w> xtknight: "anyway it usually within a couple months a maintainer will take a look at your patch." <- do you mean in Ubuntu or Debian?
[20:40] <xtknight> james_w, ubuntu
[20:40] <xtknight> i meant archive maintainer actually
[20:41] <pschorf> sorry, my x-chat gummed up
[20:41] <james_w> xtknight, pschorf: did you subscribe the sponsors?
[20:41] <xtknight> james_w, yup
[20:42] <james_w> ah, ok, it won't be a couple of months then, it will be a few days.
[20:42] <xtknight> ok ;)
[20:42] <james_w> your comment worried me as there aren't maintainers in general, and so if you don't subscribe the sponsors then the patch may never be seen.
[20:43] <pschorf> ok
[20:43] <pschorf> so always subscribe the sponsors?
[20:43] <xtknight> after a fix is posted, yes
[20:44] <xtknight> ubuntu-main-sponsors for packages in main, ubuntu-universe-sponsors otherwise
[20:44] <xtknight> otherwise it's like a needle in the haystack
[20:44] <pschorf> and we just get that off of the package information page?
[20:45] <xtknight> pschorf, what section the package is in? yes
[20:45] <xtknight> or
[20:45] <pschorf> ok
[20:45] <xtknight> !info amule
[20:45] <xtknight> at least if ubotu had a pulse
[20:45] <ubotu> amule (source: amule): client for the eD2k and Kad networks, like eMule. In component universe, is optional. Version 2.1.3-3ubuntu1 (gutsy), package size 1243 kB, installed size 3404 kB
[20:45] <xtknight> "in component universe"
[20:45] <pschorf> ok
[20:46] <pschorf> i need to get going, i'll hop back on later tonight
[20:52] <xtknight> how do i set the default name and email being used by dch, dpatch, etc
[20:54] <fdoving> xtknight: environment variables.
[20:55] <fdoving> I set them in ~/.bashrc
[20:55] <james_w> xtknight: "man dch" explains
[20:55] <xtknight> ah thx
[20:55] <fdoving> export DEBFULLNAME="Your name"
[20:55] <fdoving> export<EMAIL_ADDRESS>[21:00] <RainCT> has someone here gweled?
[21:00] <RainCT> (or can install it?)
[21:01] <sebner> are there plans to remove ms-sys from the repo? Or is it already removed? https://edge.launchpad.net/ubuntu/+source/ms-sys
[21:03] <xtknight> !info audacious-plugins
[21:03] <ubotu> audacious-plugins (source: audacious-plugins): Base plugins for audacious. In component universe, is optional. Version 1.3.5-3ubuntu4.1 (gutsy), package size 706 kB, installed size 1368 kB
[21:05] <james_w> sebner: it's already gone according to rmadison
[21:05] <xtknight> i dont understand why my pdebuild is failling. http://rafb.net/p/f9CTEK27.html
[21:05] <sebner> james_w: ah ok. one merge more todo for me :D
[21:06] <xtknight> shouldn't i be able to type "pdebuild" just in place of "debuild" anywhere?
[21:06] <james_w> xtknight: I tried to explain, your Build-Dependencies seem to be wrong.
[21:06] <xtknight> it has hapepned with another package now
[21:07] <xtknight> they build fine on my real machine
[21:08] <james_w> as the build-dependencies are satisfied already, and so it doesn't have a problem trying to install them.
[21:09] <xtknight> ok never mind i think i need to add UNiverse support to it that's all
[21:24] <YokoZar> Hmm, my upload is dying about halfway through.  dput is just returning a "killed" error
[21:29] <xtknight> i'm not getting a source.changes file from pdebuild.  any ideas?
[21:31] <blueyed> Is there something update-manager can do to install the correct meta package for virtualbox-ose-modules, when upgrading from Gutsy? Or should there rather be a dummy package virtualbox-ose-modules-2.6.22-14-generic in Hardy, which depends on virtualbox-ose-modules-generic? (bug 208143)
[21:31] <ubotu> Launchpad bug 208143 in update-manager "incorrect dependencies handling in virtualbox-ose during upgrade" [Medium,In progress] https://launchpad.net/bugs/208143
[21:32] <sebner> YokoZar: you are Scoot
[21:32] <sebner> YokoZar: *Scott Richie :D
[21:34] <YokoZar> sebner: yes :)
[21:35] <YokoZar> sebner: this dput killed has happened twice now...should I worry about my server or is this being caused by something else?
[21:36] <sebner> YokoZar: hmm. sry. dunno. Just happy to meet you ^^.  Wine 0.59 was released some days ago and no on 11th of April
[21:36] <sebner> *not
[21:36] <YokoZar> sebner: I've changed my mind, hardy will have 0.9.59 now iff I can fix a regression it introduced into the systray
[21:37] <sebner> YokoZar: great. thanks :D
[21:37] <YokoZar> sebner: right now 0.9.59 breaks a few apps I use and is worse than gutsy
[21:37] <sebner> damn ^^
[21:38] <YokoZar> ok even weirder dput -o is failing with the killed error...
[21:40] <sebner> YokoZar: try to use it with you PPA?
[21:41] <YokoZar> sebner: where I'm uploading to shouldn't matter if it's failing during a dry-run test....hmm....
[21:45] <sebner> YokoZar: what crap :/
[21:55] <afflux> do we use README.Ubuntu when we changed something to the debian packaging we want to note down for other packagers?
[21:56] <RainCT> sebner: why do you touch estival-1.96~beta/debian/festival.init
[21:57] <sebner> RainCT: because it's a remainig ubuntu change that isn't in Debian?
[21:58] <RainCT> sebner: it isn't metioned in the changelog and neither does that change make sense..
[21:59] <sebner> RainCT: It *is* in the changelog and it's a remaining change ..
[22:00] <RainCT> sebner: ah right.. my brain is frozen again :P
[22:00] <RainCT> but it still doesn't make sense
[22:01] <sebner> RainCT: https://edge.launchpad.net/ubuntu/+source/festival/  <-- ask Jamie Strandboge ;)
[22:01] <RainCT> yeh I'm searching what is IRC nick is :P
[22:01] <RainCT> s/is/his
[22:01] <RainCT> jdstrand: ping
[22:01] <emgent> jdstrand
[22:02] <sebner> hihi
[22:02] <jdstrand> pong
[22:02] <RainCT> jdstrand: just wanted to know what's the rationale for this: "debian/festival.init: don't complain when server set to not start"
[22:03] <jdstrand> RainCT: it was just the previous behavior, and IIRC was very noisy
[22:03] <jdstrand> RainCT: if you are merging the Debian package, you can drop that patch of mine
[22:04] <jdstrand> RainCT: plus, by complaining that it isn't starting, it is suggesting that maybe it should be started
[22:04] <jdstrand> RainCT: but it should *not* be used in all but very limited circumstances
[22:05] <RainCT> jdstrand: so, should we keep this or not?
[22:05] <pschorf> xtnight, you there?
[22:05] <jdstrand> RainCT: which this are we talking about-- Debian doesn't ship /etc/init.d/festival anymore
[22:06] <jdstrand> (it is an example file, and I prefer that)
[22:06] <RainCT> jdstrand: true.. so I'll drop this. thanks
[22:07] <jdstrand> RainCT: np
[22:07] <sebner> RainCT: you mean I have to drop it ^^
[22:08] <RainCT> sebner: yeh ^^
[22:08] <sebner> RainCT: remind me tomorrow :P review something else meanwhile ^^
[22:10] <RainCT> uhm.. will someone pay us each time we use "^^"? :)
[22:10] <sebner> RainCT: then I would be rich :D
[22:11] <RainCT> heh. well, I'm going to bed, my reviews aren't accurate that late anyways :P
[22:11] <RainCT> good night all
[22:13] <sebner> radamantis: gn8
[22:13] <sebner> RainCT: gn8
[22:13] <sebner> ^^
[22:19] <xtknight> what needs to be done for something like bug 197069
[22:19] <ubotu> Launchpad bug 197069 in xserver-xorg-video-amd "xserver-xorg-video-amd: wide resolutions don't work" [Undecided,New] https://launchpad.net/bugs/197069
[22:25] <null_vector> LS
[22:26] <null_vector> damned screen
[22:27] <emgent> hello norsetto
[22:27] <norsetto> emgent: hey, where you stalking me !? :-)
[22:27] <emgent> heheh :D
[22:29] <null_vector> Would FTBFS on ubuntuwire be a good place to start for someone new?
[22:29] <sebner> null_vector: totally news?
[22:29] <xtknight> if a patch for Bug 129940 already exists for xpdf hardy, may i close the bug or is still needed to be left open for gutsy?
[22:29] <sebner> *new
[22:29] <ubotu> Launchpad bug 129940 in xpdf "[XPDF] possible buffer overflow and execution of arbitrary code" [Undecided,Confirmed] https://launchpad.net/bugs/129940
[22:30] <sebner> null_vector: https://wiki.ubuntu.com/MOTU/GettingStarted
[22:30] <crimsun> xtknight: I would not close it.
[22:32] <xtknight> !info xft
[22:32] <ubotu> Package xft does not exist in gutsy
[22:32] <xtknight> !info libxft2
[22:32] <ubotu> libxft2 (source: xft): FreeType-based font drawing library for X. In component main, is optional. Version 2.1.12-2ubuntu4 (gutsy), package size 46 kB, installed size 132 kB
[22:36] <sebner> gn8 folks
[22:47] <pschorf> what does a bug status of triaged mean>
[22:49] <crimsun> pschorf: https://wiki.ubuntu.com/Bugs/Status
[22:50] <pschorf> i've just started working with patching, and i've just created a debdiff file from a diff fileee
[22:51] <pschorf> would that help with bug 208629?
[22:51] <ubotu> Launchpad bug 208629 in f-spot "f-spot doesn't work with gnome-screensaver" [Medium,Triaged] https://launchpad.net/bugs/208629
[22:56] <crimsun> pschorf: yes, that would help
[23:01] <pschorf> crimsun: for the last file i copied the diff file into debian/patches and updated the series file
[23:01] <pschorf> is there something similar for patch files?
[23:04] <crimsun> pschorf: it appears to use dpatch, so you can do similarly
[23:05] <pschorf> crimsun: do i need to do anything to the patch file, or just add it to 00list?
[23:06] <crimsun> pschorf: you'll need to ensure it applies in the sequence you've given it in 00list
[23:08] <pschorf> crimsun: what i meant to ask is if there is a way to convert a .patch file to a .dpatch file
[23:09] <crimsun> pschorf: sure, dpatch-edit-patch
[23:09] <xtknight> hi pschorf
[23:09] <pschorf> hey, xtnight
[23:09] <xtknight> i just learned how to use dpatch-edit-patch btw
[23:09] <xtknight> it actually is easier
[23:09] <xtknight> for adapting things, sometimes
[23:10] <crimsun> pschorf: note that that "conversion" is not strictly necessary, since any unified diff is happily attempted by dpatch.
[23:10] <pschorf> i was working on bug 208629
[23:10] <ubotu> Launchpad bug 208629 in f-spot "f-spot doesn't work with gnome-screensaver" [Medium,Triaged] https://launchpad.net/bugs/208629
[23:12] <pschorf> xtnight: i renamed the patch file and ran dpatch-edit-patch gnome_screensaver_fix.patchj
[23:12] <xtknight> crimsun, a patch was attached to the bug he linked, but it changed the ChangeLog in f-spot.  the ChangeLog should not be touched, right, only the debian/changelog if the fix is being backported to hardy?
[23:12] <crimsun> xtknight: "backported"?  Meaning being applied now to hardy?
[23:13] <pschorf> what would i do next?
[23:13] <xtknight> crimsun, sorry ya i prolly used the wrong term there.  there's a patch on the f-spot page
[23:14] <xtknight> pschorf, we may want that patch to be applied AFTER a certain patch.  personally i always do mine after the last one
[23:14] <crimsun> xtknight: generally, for the active development release, it's ok to touch other files during non-freezes.  However, since we're in freeze, it's best to touch as few files as possible.  As long as the change is documented in debian/changelog, I would avoid applying the hunk that touches the upstream Changelog, too.
[23:14] <xtknight> ok besides the fact it's not even an official change
[23:14] <xtknight> i mean the guy just kinda put it in there
[23:14] <xtknight> it's not by a developer so it probably shuoldnt have even been in the official changelog
[23:15] <crimsun> if that's the case, I wouldn't touch the upstream Changelog, no.
[23:15] <xtknight> pschorf, type "exit 230" to abort the cmd you just did
[23:15] <pschorf> ok
[23:15] <pschorf> aborted
[23:16] <xtknight> ok one moment
[23:16] <greg-g> slangasek: re bug 212017: simply removing acroread (and acroread-escript acroread-plugins) did not allow me to print.  It goes into the print queue, sits at "processing" for a bit, then has the status of "stopped"  I can not cancel the job either, if I try I get the error "CUPS SERVER ERROR: There was an error during the CUPS operation: 'client-error-not-possible'."
[23:16] <ubotu> Launchpad bug 212017 in evince "Evince/CUPS Could Not Print Tax Document" [Medium,Incomplete] https://launchpad.net/bugs/212017
[23:16] <slangasek> greg-g: ah, interesting :)
[23:17] <xtknight> pschorf, well looking at debian/patches/00list it looks like we should insert it after importer_targetdir_selector
[23:17] <xtknight> because 98 and 99 are supposed to be applied last, i guess
[23:17] <xtknight> i'm not sure it really matters
[23:17] <xtknight> basically we gotta get it in there without breaking other patches and without breaking this patch
[23:17] <xtknight> To create a new patch, to be applied after an existing patch 90_ctrlkeyfix:
[23:17] <xtknight> $ dpatch-edit-patch patch 95_newupstreamfix 90_ctrlkeyfix
[23:17] <pschorf> ok
[23:17] <xtknight> for example
[23:18] <xtknight> what is your patch called again?
[23:18] <pschorf> gnome_screensaver_fix
[23:18] <xtknight> ok
[23:18] <xtknight> actually fix_gnome_screensaver would be a little more consistent
[23:19] <pschorf> so i would say dpatch-edit-patch patch fix_gnome_screensaver importer_targetdir_selector?
[23:19] <xtknight> yeah, although i just raelized it breaks if we do that
[23:19] <xtknight> let's just try this for now:    dpatch-edit-patch patch fix_gnome_screensaver
[23:20] <pschorf> ok, i'm in the interactive shell again
[23:20] <xtknight> k
[23:20] <xtknight> now remove from the original diff file the modifications to the ChangeLog file
[23:20] <xtknight> we do not want to do that
[23:20] <Kamping_Kaiser> (sorry about the repost, i dont see an answer from last night) i have a bug open against sugar in ubuntu (cant login). is there a 'best way' to get it either fixed or removed? it seems like a pretty awquard thing to do - include it but have it unusable
[23:20] <greg-g> slangasek: anything else I can do for now? (other than stop bugging you ;) )
[23:21] <pschorf> xtnight, what should i enter in the shell?
[23:21] <xtknight> pschorf, nano the_patch_name
[23:21] <xtknight> remove Index:..ChangeLog from it and everything below
[23:22] <xtknight> press Ctrl+K to remove a whole line
[23:22] <pschorf> it said new file
[23:23] <xtknight> ok exit then
[23:23] <xtknight> out of nano
[23:23] <pschorf> do i need to specify a path?
[23:23] <xtknight> just use gedit it doesnt really matter
[23:23] <xtknight> open the patch file you saved
[23:23] <xtknight> the one the guy provided, basically
[23:24] <pschorf> ok, i've removed the changelog stuff
[23:24] <xtknight> ok
[23:24] <xtknight> save it then go back to your interactive patch shell
[23:24] <xtknight> note the path of the patch file you geidt'd
[23:24] <xtknight> gedit'd
[23:24] <pschorf> ok
[23:24] <xtknight> let that be PATCH_PATH.  so now, you would do, in the shell, "patch -p0 < PATCH_PATH"
[23:25] <pschorf> ok, it patched 2 files
[23:25] <xtknight> now type "exit".  do not type "exit 230".  230 means we screwed up.  a regular exit of 0 means the patch will be committed to our debian/patches/ folder and 00list file.
[23:25] <pschorf> ok, the dpatch file was created
[23:26] <xtknight> k now add a relevant entry to the Debian changelog. ("dch -i")
[23:26] <xtknight> credit the author of the patch
[23:27] <pschorf> the patch was from the gnome bugzilla
[23:27] <xtknight> looks like it's fro mMaxxer
[23:27] <xtknight> from
[23:28] <pschorf> ok
[23:28] <xtknight> actually Lorenzo Milesi
[23:28] <xtknight> is his realname from the changelog he put in
[23:29] <xtknight> ok paste what you wrote besides the *, if you would.
[23:29] <pschorf> f-spot (0.4.2-1ubuntu2) hardy; urgency=low
[23:29] <pschorf>   * Fixed issues arising from using f-spot with gnome-screensaver. Thanks
[23:29] <pschorf>     to Maxxer for the original patch. (LP #208629)
[23:29] <pschorf>  -- Paul Schorfheide<EMAIL_ADDRESS>Mon, 07 Apr 2008 17:26:25 -0500
[23:29] <ubotu> Launchpad bug 208629 in f-spot "f-spot doesn't work with gnome-screensaver" [Medium,Triaged] https://launchpad.net/bugs/208629
[23:29] <xtknight> that looks good.  you can use his real name if you think that's more proper
[23:30] <xtknight> also nitpick (LP: #208629) we can add a : there
[23:30] <pschorf> how would I determine that?
[23:30] <xtknight> pschorf, he just mentioned it in his changelog
[23:30] <xtknight> he put in his realname
[23:30] <xtknight> that's the thing we just removed from the diff file
[23:30] <null_vector> looking at a FTBFS for xine-plugin and wondering about the right way to fix it.  The libxine.pc adds the patch number to the version but the header is missing the patch number so dependent packages think there is a version mismatch
[23:31] <xtknight> pschorf, Lorenzo Milesi is his name
[23:31] <null_vector> Just change the parsing of the xine-config version number to ignore the patch number?
[23:31] <pschorf> ok, fixed that
[23:31] <pschorf> everything else OK?
[23:31] <xtknight> and the LP thing?
[23:31] <pschorf> yes
[23:31] <xtknight> sounds good to me then
[23:31] <xtknight> this time let's build it the right way
[23:31] <xtknight> "debuild"  no -S
[23:32] <xtknight> make sure maintianer field is fine
[23:32] <pschorf> just sudo debuild, to confirm?
[23:32] <xtknight> !info f-spot
[23:32] <ubotu> f-spot (source: f-spot): personal photo management application. In component main, is optional. Version 0.4.0-0ubuntu3 (gutsy), package size 1729 kB, installed size 8924 kB
[23:32] <xtknight> what's the maintainer field on f-spot?
[23:32] <xtknight> we don't use sudo when you use debuild really.  at least i dont.  should work without
[23:33] <pschorf> it has the ubuntu desktop team and 2 individuals
[23:33] <xtknight> pschorf, this package is in main,  so is Ubuntu Core Team set as  maintainer?
[23:33] <xtknight> well desktop team
[23:33] <pschorf> no, just the desktop team
[23:33] <xtknight> ok i think that is correct then
[23:33] <pschorf> ok
[23:33] <xtknight> "debuild"
[23:34] <pschorf> it's building...
[23:34] <pschorf> i'm going to get some dinner while this runs
[23:34] <jdong> am I the only one to feel that LP expires/removes old packages from the archive way too aggressively?
[23:34] <pschorf> be back shortly
[23:36] <jdong> it'd be nice for a devel release to have a longer history of packages
[23:36] <jdong> makes tracing down recent regressions a lot easier
[23:46] <null_vector> How would you patch an aclocal.m4 seeing as it then needs to be autoreconf-ed?
[23:47] <ScottK> jdong: Agreed.
[23:47] <ScottK> jdong: Any chance we could set up hardy-backports early?
[23:48] <jdong> ScottK: sure, go for it :)
[23:49] <norsetto> g'night all
[23:49] <jdong> ScottK: how is it going to relate to Intrepid? Ahead of Intrepid until uploads are accepted?
[23:49] <ScottK> jdong: Clamav is releasing 0.93 with a soname bump a week before our release.
[23:49] <ScottK> jdong: Yes.
[23:50] <jdong> ScottK: sounds reasonable. I think I want to stuff transmission 1.10 in that way too
[23:50] <ScottK> All you need is a core-dev to do source uploads .... ;-)
[23:50] <jdong> ScottK: one of these days I'm gonna make an irssi plugin for a queue-ping ScottK system :D
[23:51] <ScottK>  /ignore jdong
[23:51] <ScottK> oops
[23:51] <ScottK> ;-)
[23:51] <jdong> :)
[23:55] <ScottK> jdong: From a policy perspective who would we need to coordinate this with?  We're breaking the it needs to be in the development release first paradigm.  Note: We did this for Universe SRUs for Gutsy, so the ground is slightly trod already.
[23:56] <jdong> ScottK: For this case, there should just be an "implicit contract" that the package is destined for Intrepid when it opens up
[23:56] <ScottK> Agreed, but I wonder if we need to discuss it or just do it.
[23:56] <jdong> ScottK: I'm not too concerned about this policy violation, though ultimately cjwatson would be the person to consult
[23:57] <ScottK> OK.  I'd suggest we do that.
[23:59] <ScottK> jdong: Do you want to discuss it with him or should I?