[12:15] <ajmitch>  /win 21
[12:15] <Burgundavia_> ajmitch: sorry, that window does not exist, please try again :)
[12:15] <ajmitch> you need more channels
[12:15] <ScottK> blueCommand: It's OK to rename as needed, but why .orig?
[12:16] <blueCommand> Dunno, ask elektranox :)
[12:16] <elektranox> I think dh_make created it automatically...
[12:16] <ScottK> That's not generally correct.  
[12:17] <elektranox> I will just redownload the SF.net package and exchange it with the package version ones
[12:18] <blueCommand> elektranox, Ok, It seems like it's fine, so moving on!
[12:19] <blueCommand> I forgot ubuntu0 on my packages, but since they dont exist before I guess thats OK. Reading the guide that is.
[12:20] <ScottK> blueCommand: It needs to be packagename-upstreamversion-0ubuntu1.
[12:21] <blueCommand> Darn
[12:21] <blueCommand> I will re-submit it then
[12:21] <ScottK> Go ahead and go though it first.
[12:21] <ScottK> There'll likely be other changes that need to be made.
[12:22] <blueCommand> Probably. elektranox; you passed mustard in my book ;)
[12:22] <blueCommand> Which means 0 :)
[12:22] <elektranox> :)
[12:22] <elektranox> mh is there something like --force for dput?
[12:22] <blueCommand> -f :)
[12:23] <elektranox> ok thx
[12:27] <blueCommand> elektranox, Do you have any man / info / examples in that package?
[12:28] <elektranox> there is one in data
[12:28] <elektranox> gafix.1.gz
[12:28] <blueCommand> ScottK, Correct me if I'm wrong, but wouldn't it be unnessecary to run dh_installman / dh_installexamples without such files? 
[12:28] <blueCommand> Ah right
[12:28] <blueCommand> Examples?
[12:28] <elektranox> nope
[12:28] <elektranox> but the man page is installed via Makefile
[12:29] <blueCommand> yeah, so I guess dh_installman is good. Can't say whenever you should remove dh_installexamples though
[12:39] <elektranox> mh ok so anybody with review rights here?
[12:39] <gnomefreak> is there anything wrong with really really big debdiffs?
[12:41] <elektranox_> mh ok so anybody with review rights here?
[12:41] <persia> elektranox: Several people.  You've announced your package, and I see a very new version.  Please wait a bit, and you should get a response from someone soon.
[12:42] <elektranox_> ok
[12:42] <persia> gnomefreak: No, but it can make it harder to review, and possibly harder to understand what changed.  It really depends on the nature of the debdiff.
[12:42] <gnomefreak> persia: im assuming since java6 and java6update1 are so differnet thats why the debdiff is 228.1mb
[12:43] <gnomefreak> other wise im not real sure but i guess it cant hurt to attach it and go with it someone will let me know if messed up i guesss
[12:45] <gnomefreak> im gonna assume its this bug because the scripts grab the sources
[12:45] <gnomefreak> s/bug/gib
[12:45] <gnomefreak> big
[12:46] <gnomefreak> doko_: if your here i have debdiff for java6 update1 for feisty-proposed its a really large debdiff though. it will be attached to bug 122442, i will also subscribe UUS
[12:46] <ubotu> Launchpad bug 122442 in sun-java6 "Memleak in Sun Java 6 on ubuntu feisty" [Wishlist,Fix committed]  https://launchpad.net/bugs/122442
[12:48] <persia> gnomefreak: I'd suggest that rather than a debdiff, you might want to provide a URL to the new upstream, and only use the diff -urN of debian/, as this is a little easier to understand at first glance (and separates the review of the new upstream from the review of the packaging changes).
[12:49] <gnomefreak> i would provide upstream only 1 issue there i can only find update 2
[12:50] <gnomefreak> but i may have to do it that way
[12:51] <persia> Hmm..  That makes it tricky.  Where did you get the orig.tar.gz for the update1 source for your debdiff?
[12:51] <gnomefreak> persia: the script grabs it
[12:51] <gnomefreak> persia: the orig tar came from gutsy
[12:52] <gnomefreak> since nothing changed from 6.00 to 6.01
[12:52] <gnomefreak> other than 01 fixes uupstream
[12:52] <persia> gnomefreak: In that case, it's probably in https://archive.ubuntu.com/ubuntu/pool/s/sun-java6/ somewhere, which is a trusted location :)
[12:53] <Jazzva> persia: Umm, I have a few things to ask. In Jabbin upload at http://revu.tauware.de/details.py?upid=6010 it is said that some of the code in voip/ is generated. I suppose you ment the *.jisp. There is a document in ./src/libpsi/iconset/ on how to create those files - just zip the icons and an xml file and rename it to something.jisp. Now, I'm not sure how and where to recreate them at the build-time.
[12:53] <Jazzva> *meant
[12:53] <gnomefreak> ty persia
[12:55] <persia> gnomefreak: Sorry: http://archive.ubuntu.com/ubuntu/pool/multiverse/s/sun-java6/
[12:55] <persia> Jazzva: Looking again
[12:55] <gnomefreak> i knew what you meant
[12:58] <Jazzva> persia: Ok.
[01:02] <persia> Jazzva: It looks like voip/callslogdialogbase.* was my trigger for the generated files.  Separately, I don't see the .jisp files at a quick glance, but it appears that they should be generated by the upstream build process (which might need a patch), as I don't imagine the psilib binary format is the "preferred format for modification".
[01:04] <persia> Jazzva: If you need to build the .jisp files, it looks to me like the procedure is 1) copy the right things to a directory, 2) zip them, and 3) rename.  Build-depending on zip should be sufficient to ensure you have the necessary tools, although some effort may be required in the build process.
[01:06] <Jazzva> persia: I found out about .jisp files, I thought you thought about them when you said "generated files". So, what do I need to find about callslogdialogbase.* files? It is said in cpp and h files they were generated using the .ui file. Do I need to find out by what program or... *unsure*?
[01:07] <minghua> Hello there persia.  How is REVU day going?
[01:08] <persia> Jazzva: Ideally, you want to find out which program generated them, and have them regenerated during the build process.  This may already be done (check if the timestamps change during build).  If it must be done fresh, I suggest coordination with upstream, as there may have been modifications post-generation (in which case adding copyright declaration and licensing information would be appropriate, perhaps with a note that it's based on code gen
[01:09] <persia> minghua: Better than the last (and Monday has reached here as well)
[01:11] <persia> minghua: Not to worry - Monday is coming at ~1.6 million metres/second :)
[01:12] <TheMuso> Hey folks.
[01:13] <minghua> Hmm, that sounds a bit high.
[01:14] <ScottK> persia: Not at the speed of light.
[01:15] <teer2> Hello - I am communicating with the Democracy Player maintainers about the conflicts with the current versions of their software in Ubuntu.  I have a couple questions about versions and how MOTU works.  First, is 0.9.6 the version that will be in Gusty ?  (This is the version currently displayed on LaunchPad.)
[01:15] <persia> ScottK: Nope, roughly at the rotational velocity of ground level of the earth (which I may not have calculated correctly: minghua is checking).
[01:15] <Jazzva> persia: Ok, I'll check it with the upstream author. I don't know what can I do about number 5 (FtBFS on 64-bit arechitectures (rtprandom.cpp: In constructor RTPRandom::RTPRandom(): rtprandom.cpp:56: error: cast from RTPRandom* to u_int32_t loses precision)). Should I just inform the upstream author about this?
[01:15] <persia> Hm.  Yes, it appears that 24 != 86400.  Sorry.
[01:15] <minghua> persia, ScottK: my calculation gives ~465 meter/second.
[01:15] <ScottK> Plus since he's not at the equator, it's less.
[01:16] <minghua> (yeah, at equator)
[01:16] <ScottK> Did you take into account your latitude?
[01:16] <persia> Jazzva: Informing upstream is good.  In the meantime, you want to restrict the architectures for which the binary is created in debian/control
[01:16] <minghua> No.  Partly because I don't know my latitude off hand. :-P
[01:18] <minghua> teer2: Currently gutsy has 0.9.6, yes.  But it's not necessarily what will be when gutsy is released.  It's still under heavy development.
[01:18] <persia> teer2: Yes.  The current target for gutsy is 0.9.6 (revision 1ubuntu1).  This may change as development continues, up until UpstreamVersionFreeze
[01:19] <minghua> Yay, beats persia on answering questions. :-P
[01:19] <persia> minghua: That's easy.  I'm slow :)
[01:19] <teer2> minghua: Thanks for your response.  Second question - DP player is recommending Ubuntu users to move away from the Synaptic specified version in Feisty by adding the DP repository.  This seems not to be the recommended and supported way to do software updates (which would be to pass the patches through MOTU and into Synaptic or future versions.  Am I correct?
[01:19] <teer2> http://www.getdemocracy.com/downloads/ubuntu.php
[01:20] <teer2> Basically, are they causing problems for Ubuntu users by trying to circumvent MOTU processes?
[01:21] <Burgundavia> teer2: to a certain extent yes
[01:22] <persia> teer2: It's not recommended, nor supported.  Whether it causes problems or not depends very much on how closely upstream tracks Ubuntu changes.  Working with us it usually easier than working to match us, and users will generally have a better experience.
[01:22] <minghua> teer2: They are using distinctive version numbers (-XubuntupcfY).  So while it's unfortunate, I don't see an easy way to change the situation, and I'm personally fine with the status quo.
[01:22] <Jazzva> persia: Ok. #6: I think the Minizip source is available at ./src/tools/zip/minizip. I suppose I should mention the whole path in debian/copyright.
[01:22] <minghua> teer2: They also currently only provide packages for dapper/edgy/feisty, not gutsy.
[01:22] <persia> minghua: That depends very much on how upstream sets their revision numbers :)
[01:22] <persia> Jazzva: It would be helpful.
[01:23] <minghua> persia: Sorry, I meant they use -XubuntuY revision numbers.
[01:23] <persia> Jazzva: Also, does minizip create zip archives?  It may be that minizip is used by the build process to generate the jisp files (which would make things easy).
[01:23] <persia> minghua: Yes, but upstream might also choose to use such versioning...
[01:24] <Jazzva> persia: Dunno... I'll try to find out.
[01:24] <teer2> persia: If the dependencies for DP 0.9.6 are correct in the launchpad info, then DP 0.9.6 upgrade will also require new glibc versions, among other packages.  If true, then I would think this causes other issues.  So, I was concerned about their procedures.
[01:25] <minghua> persia: Hmm, I am confused.  Which upstream?  Is www.getdemocracy.com not upstream for democracy player?
[01:26] <minghua> teer2: What DP 0.9.6 upgrade are you talking about?  Feisty system with unofficial package upgrading to gutsy?
[01:26] <teer2> I made a bit of a fuss on the DP forums, and I got a response that DP 0.9.8 (next version) will support Feisty and Dapper (does that mean the DP versions included with those releases, I am not sure).
[01:26] <teer2> http://forum.getdemocracy.com/viewtopic.php?id=2283
[01:26] <Jazzva> persia: After a quick look at minizip.c and variables/strings used I think it can create zip archives using Zlib. I'll take a look if it's used for the making of .jisp files.
[01:26] <teer2> minghua: No, I mean the 0.9.6 upgrade through the DP repository
[01:27] <persia> minghua: -1ubuntupcf is close, but admittedly different.
[01:27] <persia> Jazzva: That would be great - that would only leave the .ui -> .h/.cpp files to still chase :)
[01:28] <minghua> persia: Personally, as long as I can recognize unofficial package version numbers from bug reports, and mark them invalid, I don't care.
[01:29] <minghua> teer2: Do they provide upgrades?  I see that dapper/edgy/feisty are in different directories, so changing /etc/apt/sources.list seems needed.
[01:29] <Jazzva> persia: I guess :). And the last one I need help with is #8. Did you mean to make a multi-package with portaudio and jabbin in it?
[01:30] <teer2> minghua: I don't know -- all my concern came from the fact that the version in Synaptic was invalid.  I am trying to resolve the issue by drawing attention to the discrepancy, because I do NOT want to deviate from the Ubuntu recommended packages.  I am trying to make things smoother for others who feel the same.
[01:30] <minghua> teer2: I think the best person to talk with is RAOF, he uploaded the last democracyplayer package.
[01:31] <persia> Jazzva: No, rather to investigate how jabbin uses portaudio.  If it's code from portaudio reused in jabbin, debian/copyright is correct.  If jabbin is linking against portaudio (and building it locally), you'd do better to try to link against the portaudio libraries distributed in the separate packages, as that way jabbin would automatically take advantage of fixes to portaudio.
[01:31] <DarkSun88> Hi all
[01:32] <teer2> One of the best things about Ubuntu, in my opinion, is that you can stay with the current latest supported version (which gets updated every six months), and not feel incapable of using your software.  With other distros, there is an incentive to deviate from the distro norm, and it always ended with "Dependency Hell" for me and my return to Windows.
[01:32] <Jazzva> persia: Ok, thanks for all your help :).
[01:32] <persia> teer2: Best for us would be either 1) a compatibility repository for older versions of DP, or 2) a targeted patch for the older versions that would let them access the primary upstream repository.  For the first, upstream would have to help.  For the second, anyone could help.
[01:32] <minghua> teer2: My personal take -- If the upstream chooses to tell their users to bypass distribution's standard package management, that's unfortunate but their choice.  Any user who follows such advice is on his own, from distribution point of view.
[01:32] <persia> Jazzva: No problems.  Thanks for your work on the package.
[01:33] <teer2> persia , minghua: thanks for your hard work in maintaining software in a way that keeps me away from Windows Vista, by the way!
[01:33] <minghua> teer2: Yeah, as persia said, we can try to improve on our side, but that requires a lot of dedication and communication with upstream.
[01:34] <teer2> minghua : I think the easiest thing to do is for DP to be aware of what Ubuntu users are using, and choose to support that version rather than alienate them and make them feel like they need to upgrade.
[01:35] <minghua> teer2: Yes, it's generally nice for upstream to agree that they should co-operate with distribution packagers, but not all of them do.
[01:35] <teer2> minghua : Tell me if I am off base though - I am not familiar with your procedures, which is why I came to bother you all!
[01:36] <teer2> minghua: True, not all of them have a reason to co-operate, but DP depends on a wide range of users having their software running.  They do Bittorrent distribution, so they want to push DP on everyone.
[01:36] <minghua> teer2: You are on good track.  There just need to be a person who is both familiar with Ubuntu packaging and democracy player to work with both upstream and Ubuntu to solve these issues.
[01:36] <persia> teer2: It's a balance.  Upstream typically wants to focus on new features, bugfixes, and improvements.  Ubuntu has an interest in stability, maintainability, and integration with the rest of the system.  I think effort from both groups is necessary to have a good solution (as neither upstream nor Ubuntu can provide best support alone).
[01:38] <teer2> I think for Gusty (especially Ubuntu's push for GNU Free Software) that the DP situation get addressed on both sides.  DP is pushing for "video freedom" and it would be an excellent ornament for the Gusty software display.  Know what I mean?
[01:38] <persia> teer2: On a separate note, thanks for repeatedly working to help build greater coordination between upstreams and Ubuntu: we really appeciate your help.
[01:38] <teer2> persia: And thank you for your help with that too.  I apprciate your patience in dealing with my ignorance on matters!!
[01:40] <teer2> persia: I feel a little happier through my days knowing that The Ur-Quan Masters will be better integrated with the next version of Ubuntu!!  Thanks with your help with that.
[01:41] <teer2> persia: Single-click Starcon goodness.  Ahhhh!
[01:42] <persia> teer2: As in that case, you'll want to find someone who has a specific interest in the democracyplayer package, to help with the Ubuntu side of the coordination (given that nobody has volunteered in the recent discussion).  You might try with some of the recent Ubuntu uploaders - you can find IRC handles from the launchpad overview page for each person.
[01:43] <teer2> You guys have saved "my hide" many times when I stopped myself from downloading a source tarball and screwing up my installation.  Instead, I take a deep breath and tell myself to stick with the supported software through Synaptic.  In return, I've been running Ubuntu way, way, way longer than any other of my distro attempts!  Thanks!!!
[01:43] <minghua> persia: The last uploader is RAOF BTW.
[01:45] <minghua> persia: Definitely.
[01:46] <teer2> persia: Okay, I will try your idea.  Thanks for your help.
[01:50] <teer2> minghua: It is about time some distro had the "balls" to tell users: THESE are the versions you need to have on your system.  You want to change them, then jump through a bunch of hoops and, yeah, you're on your own.  Don't come crying to us when you muff it up and your OS is fubar.
[01:51] <teer2> minghua: Because when people read that, they say, "Oh yeah, I think I'd rather have my OS boot tomorrow than install the 'Commander Keen' game.  Thanks for the reminder."
[01:51] <teer2> :-)
[01:52] <minghua> teer2: Yeah.  The hard part is to really have versions that users need, as can be seen in this outdated democracy player package problem.  We have ways to solve this, we just need people who understand both Ubuntu packaging and democracy player to work on it.
[01:52] <teer2> minghua: And, that's what hardware vendors need to support a Linux OS.  You guys are doing really important work in getting widespread Linux adoption, too.  Okay, enough building you guys up.   Thanks for your time.
[01:53] <minghua> teer2: Thank you for trying to help communication between upstream and Ubuntu.
[01:53] <teer2> minghua: Software developers have had for TOO LONG the idea that their software comes before any concerns with the OS.  I am glad Ubuntu is in the position (through their popularity) to push back at them.
[01:53] <teer2> minghua: Just doing what little I can do to help.  Thanks for saying so.
[01:54] <teer2> Isn't only just recently that software developers have (somewhat) stopped requiring users to install their software as root user?  That's a marvel by itself that such a terrible practice lasted so long.
[01:55] <minghua> teer2: Most of the time you still do.  You run synaptic as (essentially) root.
[01:56] <TheMuso> I reckon users will be confused and put off by Vista's new user account setup, and will just want to do everything as they always have.
[01:56] <TheMuso> i.e admin power for everything, because they don't want to be restricted.
[01:56] <minghua> It's not a bad thing to install software as root.  It's only bad when you install software from untrusted third-party websites.
[01:59] <teer2> minghua: But Synaptic is the "Ubuntu verification", there is some assurance that the software will at least not conflict with other versions.  Does it mean that I need to trust Ubuntu and let them decide what software to install?  Yeap, but a small price to pay for an OS that lives into another day!  :)
[02:00] <teer2> Okay, I need to stop gushing.  Bye for now.
[02:01] <StevenK> TheMuso: Your parrot merge didn't regenerate debian/control, so libparrot-dev was Depending on libparrot0.4.6 (= 0.4.13-1ubuntu1)
[02:01] <TheMuso> StevenK: Right.
[02:02] <TheMuso> StevenK: Thanks.
[02:03] <StevenK> I've also fixed debian/rules so that debian/control gets regenerated every time.
[02:05] <persia> StevenK: Automatically?  I thought that was considered dangerous, and manual regeneration was preferred.
[02:06] <StevenK> persia: It only replaces %SOVERSION% with a hard-coded version number.
[02:07] <persia> StevenK: That seems perfectly reasonable, and good.  Hmmm...  I wonder where my impression comes from: I should go read more docs.
[02:11] <StevenK> persia: If it's a simple transform, or replacement, then doing it automatically means that people don't forget. Something more complicated, I agree with you, in that it should be done manually.
[02:12] <elektranox> ok I'll leave now - I hope one of you will look after my package? :)
[02:12] <TheMuso> elektranox: URL
[02:12] <persia> Right.  That makes perfect sense.  It's just that whenever I find something that makes sense and contradicts my memory of something I read as an official recommendation, I like to check, as one of 1) it only appeared to make sense, 2) the documentation was wrong, or 3) I have a lousy memory is true.
[02:13] <elektranox> TheMuso: http://revu.tauware.de/details.py?upid=6025
[02:13] <StevenK> In other news, I hate regenerating debian/control. :-)
[02:13] <TheMuso> elektranox: Thanks.
[02:14] <TheMuso> StevenK: Understandable.
[02:14] <elektranox> TheMuso: Thanks for reviewing ;)
[02:15] <minghua> My recollection is that changing build dependency during auto-generation of debian/control during build is prohibited.
[02:15] <minghua> Everything else is probably fair game, the maintainer can choose what he/she wants.
[02:18] <persia> Found it.  "debian/control: The source package control file is generated by dpkg-source when it builds the source archive, from other files in the source package" in http://ftp-master.debian.org/REJECT-FAQ.html.  Looking elsewhere (e.g. http://bugs.debian.org/311724), I think that the important part is only that debian/control is visibly readable, and nothing significant is changed.
[02:18] <persia> (for some definition of significant).
[02:29] <persia> dktrkranz: oggconvert uploaded
[02:30] <persia> minghua: To some degree, but think about all the debhelper modifications.  I think it's more important that the Source stanza be left alone, but that without allowing minor modifications of the Binary stanzas, we'd all be much less happy.
[02:34] <minghua> persia: How is that affected by forbidding auto-generation of debian/control?
[02:34] <minghua> It's just a memory issue IMHO.
[02:34] <minghua> You need to remember rebuilding your debian/control before uploading.
[02:34] <persia> minghua: Umm..  e.g. ${shlibs:Depends}
[02:38] <Jazzva> persia: About voip/callslogdialogbase.* in Jabbin... I think they were generated using Qt User Interface Compiler. From Qt site: "The Open Source Edition of Qt and Qt Jambi is freely available for the development of Open Source software governed by the GNU General Public License (GPL)." I'll check with the upstream author if that's what he used for generation. Looking at the timestamps I think they are not created at the build-tim
[02:38] <Jazzva> files at the build-time (not sure how and they're already provided in the package). Should I mention in debian/copyright that those files were created by Qt UIC (or some other program) and provide it's license?
[02:39] <Jazzva> persia: This is the address where I found the licensing information http://trolltech.com/products/qt/licenses/licensing
[02:39] <minghua> persia: I don't understand.  debian/control in source package and the control file in the control.tar of binary package are different things.
[02:40] <minghua> Although I don't claim familiar with these packaging details.
[02:41] <persia> Jazzva: For GPL code, it's much preferred that autogenerated code is regenerated during build, as that way those modifying the software are only required to modify the preferred source.  Also, it's not clear if there are additional changes were made by upstream (in which case, the lack of copyright attribution or licensing would be an issue).
[02:43] <Jazzva> persia: Ok, I understand... Thanks.
[02:43] <persia> minghua: Ah.  Yes, I'm likely confused.  build-time modifications to source control may be bad, but build-time modifications to binary control may be good.  I suppose whether the parrot change was good is an implementation detail, but I'm still shy of making assertions on this matter until I've a deeper understanding.
[02:45] <persia> Jazzva: As an example, the archive-admins regularly reject PDF files distributed by upstream without source in GPL archives, despite the presence of several PDF editors in the repository, as usually it's easier to make a PDF in an automated fashion, rather than drafting it directly.
[02:46] <minghua> persia: True.  I am not making any assertions, either.
[02:47] <minghua> Let me dig the doc I read, I think it's in the etch release policy.
[02:49] <minghua> Yep.  http://release.debian.org/etch_rc_policy.txt
[02:49] <persia> minghua: Thanks.
[02:49] <minghua> "debian/rules must include the targets: [...]  These targets must not change the package's build-dependencies or the changelog."
[02:50] <Jazzva> persia: I see... Well, I guess my first package is not oh-so-easy I assumed :). Well, at least I'll learn more than I hoped for :).
[02:56] <persia> Jazzva: I suspect that upstream would be happy to help: they usually are happy to share knowledge about their codebase, and appreciate packaging of their software.
[02:57] <Jazzva> persia: I suppose. I'm already writing an e-mail with questions :)...
[02:58] <mohammad> persia: Hello. Does Zekr still have any Blocking issue?
[02:58] <persia> mohammad: I'll look again
[02:58] <mohammad> persia: thanks
[03:00] <persia> mohammad: You'll need to include the pointer to http://en.wikisource.org/wiki/Talk:The_Holy_Qur%27an#Copyright in debian/copyright, rather than the REVU log.  Also, if you can find a statement from the translators themselves (or documentation of the age of the translations), that would be better.
[03:00] <minghua> ScottK: I think your observation on the "changelog" shown by LP is correct.  It annoys me as well.
[03:01] <persia> mohammad: Separately, I still think that a split between code and data would be good, as I'd like to make it easy for other study tools to access the same shared text.
[03:04] <persia> mohammad: Just to clarify, one issue with wikipedia is that, while it's often correct, it's not authoritative.  I'd suggest using the referenced sources to justify the statement of public domain (and note that in some jurisdictions, Yusuf Ali won't be free for another 20 years)
[03:05] <jdong> apt-cache madison monodevelop
[03:05] <jdong> oh silly me
[03:05] <jdong> this one's blue.
[03:05] <mohammad> persia: regarding the spliting, the current quran text is a simplified version of quran text. I mean due to some font problems a few characters cannot be shown corectly. in addition the quran text and translations are customized for Zekr, so I am afriad if I split it, others don't use the texts.
[03:06] <persia> jdong: You might also want to play with rmadison -u ubuntu :)
[03:06] <jdong> persia: naw, you're kidding!!!!
[03:07] <mohammad> persia: thanks. I will resolve the copyright issue of the translations.
[03:07] <persia> mohammad: Understood.  In that case I'd be uncomfortable just because it seems inappropriate to modify a well-accepted and widely read work, unless required, and two versions on the system would likely lead to confusion.
[03:08] <persia> jdong: Personally, I like it because it shows all architectures (not just mine), and also shows the older versions.  As you like, really.  apt-cache madison is faster.
[03:08] <jdong> persia: yeah, the other upside is apt-cache madison will show the parent source package name if you specify a binary package
[03:08] <jdong> persia: that functionality is somewhat necessary for my current use case
[03:09] <persia> jdong: No worries then.  I just like publicising alternatives :)
[03:10] <jdong> yeah, thanks, it's very helpful
[03:11] <RAOF> jdong: Backport democracyplayer for me, and I'll fix xgl :)
[03:12] <minghua> apt-cache madison also has the advantage of not requiring net access.
[03:12] <minghua> RAOF: You may be interested in the talks about democracy player earlier in this channel.
[03:12] <persia> minghua: True, but that only matters if you are deliberately using an old cache, which breaks all sorts of other use cases :)
[03:13] <RAOF> !logs
[03:13] <ubotu> Channel logs can be found at http://people.ubuntu.com/~fabbione/irclogs
[03:13] <jdong> RAOF: lol, it's a trade? :D
[03:14] <RAOF> Curses, not yet up there it seems.  Can you give the executive summary minghua? :)
[03:15] <RAOF> jdong: You'll find that it b-d's on python-support > Feisty.  However, the change that required the new p-s was reverted, so I *think* it can be safely dropped.
[03:15] <jdong> RAOF: can you effect that change in Gusty then?
[03:16] <minghua> RAOF: Ah.  Nothing urgent, just a user expressing interest to make it easier for Ubuntu users to use official packages for released versions, as well as to have a smooth upgrade.
[03:16] <jdong> hmm, anyone know if we're getting monodevelop crack soon?
[03:17] <RAOF> minghua: Ah, sorry.  I've just seen motu-current :)
[03:17] <persia> RAOF: More expansively, upstream plans to change the feed formats, so that users of older versions will not be able to access the video as easily.
[03:18] <minghua> persia: I think it "already changed feed formats".
[03:18] <jdong>  -> Considering build-dep python-support (>= 0.6)
[03:18] <jdong>       Tried versions: 0.5.6ubuntu1
[03:18] <persia> minghua: Perhaps.  I'm not really sure.
[03:18] <jdong> RAOF: ^^ yep; you're right...
[03:20] <RAOF> persia: Oh, joy.  Well, backport time I suppose.
[03:21] <persia> RAOF: Perhaps.  In my experience teer2 has been a vocal and active coordinator with upstreams, and may be able to help in preparing a joint plan, either for SRU-acceptable targeted patches for the new feeds, or for backward compatibility in feed formats.  I'd suggest that over backports if you have time, as more users have -updates enabled.
[03:22] <RAOF> True
[03:22] <persia>  (SRU acceptability in this case defined as "regresssion from previous state" or "it used to work, and suddenly it doesn't")
[03:23] <RAOF> That's great.  I'd love to have someone who wants to take the time and ask upstream about stuff.  I'll go hunt his LP page
[03:24] <RAOF> Gah!  How do you reverse-lookup in LP?
[03:25] <persia> RAOF: https://launchpad.net/people sometimes helps, but not always
[03:26] <RAOF> Good idea.
[03:29] <RAOF> What?  Apparently, it's already been filed and fixed
[03:30] <persia> RAOF: What's the reverse-lookup link?
[03:31] <RAOF> Apparently the "search for people" search should pick up irc nics
[03:32] <RAOF> (bug #40241)
[03:32] <ubotu> Launchpad bug 40241 in launchpad "allow searching for people by irc name" [Low,Fix released]  https://launchpad.net/bugs/40241
[03:34] <RAOF> However, either it doesn't work, or teer2 doesn't have a LP page with his nick on it.
[03:35] <persia> RAOF: Hmm..  I've had trouble with that before, but perhaps it's just incomplete data in LP.  Try /msg maybe?
[03:35] <minghua> I don't think it works.  I tried someone whose irc nick isn't the same as LP id.
[03:35] <minghua> (apparently there aren't many such people...)
[03:35] <RAOF> Aaah, who?  I was trying to find one :)
[03:36] <jdong> would sabdfl count?
[03:36] <jdong> or is he omnihandle?
[03:36] <Flannel> I have a different IRC nick and LP ID
[03:36] <jdong> hmm that term just sounds.. wrong
[03:36] <jdong> I'll think of another one later
[03:36] <jdong> multihandled
[03:36] <jdong> universally handled?
[03:37] <jdong> lol
[03:37] <RAOF> Flannel: Are you one of {"flannel", "flannel2"}?
[03:37] <Flannel> No, do those LP handles exist?
[03:38] <RAOF> Yes
[03:38] <Flannel> nope.  NealBussett, same as my wiki name
[03:39] <Flannel> Flannel has no karma, I'm waaay cooler than that.
[03:39] <RAOF> :)
[03:39] <RAOF> Hm.  I suppose I should re-open that bug, then.
[04:15] <persia> PhinnFort: 5913 commented
[04:17] <ScottK> leonel: Yes.  Just copy/paste the debian/changelog with all the entries since Dapper in the description of the bug.
[04:32] <persia> blueCommand: 6023 commented
[04:33] <persia> (6026 as well)
[04:34] <ScottK> persia: Are you up for pondering how to fix a package interaction bug while you revu?  I'm not asking you to fix it, just point in a direction to solve it.
[04:34] <persia> ScottK: Sure.  I'm between REVUs at the moment anyway.
[04:34] <ScottK> Bug #125865
[04:34] <ubotu> Launchpad bug 125865 in qt4-qtruby "error when installing libqt0-ruby1.8-qt4 and libqt4-ruby at the same time" [Medium,In progress]  https://launchpad.net/bugs/125865
[04:35] <persia> ScottK: Ah.  I suspect that's leftovers.  I thought I already requested removal of the extra ruby qt4 bindings.  Let me look a little closer to refresh my memory.
[04:36] <persia> ScottK: I think bug 119516 should have solved that.  Perhaps we need to backport?
[04:36] <ubotu> Launchpad bug 119516 in libqt-ruby-qt4 "Please remove libqt-ruby-qt4 from the Ubuntu archives" [Wishlist,Fix released]  https://launchpad.net/bugs/119516
[04:36] <ScottK> Ah.  Cool.  Someone who knows something about it.
[04:37] <ScottK> Right.  The libqt4-ruby has some stuff to work around package conflicts in gutsy.
[04:37] <persia> ScottK: Hmm.  Good point.  Perhaps we just need to backport the Conflicts:/Replaces:?
[04:38] <ScottK> No, they did stuff in debian rules and added diversions in the postinst.
[04:38] <leonel> ScottK: done.
[04:38] <ScottK> leonel: I'll have a look.
[04:39] <ScottK> leonel: On python-psycopg2 see if there is one from Feisty or Edgy that works and doesn't have the dependency problem.
[04:40] <persia> ScottK: For gutsy?  Hmm.   I'm not convinced that diversions are ideal, but perhaps it's required for this situation.  If the libraries are ABI compatible (required for diversions), and one is useless, deprecated, and removed, I'd think Conflicts: / Replaces: would be a cleaner solution.  Do you happen to have anything that could be used to test?
[04:41] <ScottK> persia: No.  Sorry.  I triaged it, thought I understood it.  Hit a brick wall.
[04:41] <leonel> python-central is in edgy  so I think there won't be a problem   let me check 
[04:41] <ScottK> jdong and doko__; Any thoughts about backporting python-central to Dapper?  It's non-existant so there's no risk of breakage and it would enable other backports...
[04:42] <persia> ScottK: Essentially, I'd suggest finding something that depends on the old package in Feisty, making sure it works, installing an updated Feisty version of the new package (with Conflicts:/Replaces: to replace the old package), and seeing if the test app still works.  If it's broken, you might need something with diversions, but if it works, just use Conflicts/Replaces, as we'd like all the users to migrate before gutsy anyway.
[04:43] <ScottK> Argh.  I think I know someone who I can talk into doing it who knows Ruby.
[04:43] <jdong> ScottK: I'm not fluent in python packaging; gonna wait for doko to anser this one :)
[04:44] <persia> ScottK: Great.  Point them at me if they need information about the removal - I don't remember perfectly, but I can probably get back up to speed fairly quickly (ignoring the ruby and QT4 bits).
[04:46] <leonel> ScottK: I've builded  gutsy python-central on  dapper and installed  fine    and  now to compile  python-psycopg2  needs python-all-dbg    to  build ..
[04:49] <leonel> ScottK:  and python-all-dbg  needs python-doc-utils .
[04:49] <leonel> :)
[04:49] <leonel> persia: let me check  thanks
[04:50] <leonel> ScottK: needed to edit  some version numbers  in  debian/control  so python central can build on dapper
[04:51] <ScottK> OK.  That'll have to be a source backport then.  Those are more complex.
[04:51] <marnanel> I was told on #ubuntu to ask here. Does launchpad know about fast-user-switch-applet, and if not, where does apport for FUSA go?
[04:51] <ScottK> leonel: I'll talk to doko__ about it.  He's the Debian/Ubuntu Python guru.
[04:52] <leonel> ScottK: thanks
[04:53] <persia> marnanel: Yes (https://launchpad.net/ubuntu/+source/fast-user-switch-applet), and it likely attaches reports to that source. (click Bugs)
[04:54] <marnanel> persia: Huh, thanks. I spent about five minutes typing "fast-user-switch-applet", "fast user switch applet", "fast user", "fusa"... into the search box
[04:54] <persia> marnanel: If you know the name of the package, a URL of the structure I've just given should generally work.  Also, for discussion about bugs, #ubuntu-bugs is generally preferred.
[04:57] <marnanel> Thanks. Sorry, someone on #ubuntu said I should come here; I'll go there in future. Thanks again.
[05:00] <persia> marnanel: No problems.  Your question wasn't really off-topic here, it's just that different people are there, and they have a slightly different focus, which may also be helpful to you next time.
[05:00] <marnanel> Thanks.
[05:05] <TheMuso> persia: Are there any packages that have a 1, and could go another advocate, and hense get uploaded?
[05:07] <persia> TheMuso: I'm not sure.  Maybe alsa-firmware?  Everything I've seen today (limited to those announced in-channel since REVU day began: I'm just finishing the last of the backlog) was either not suitable, or a new upstream version of an existing package (already uploaded).
[05:07] <TheMuso> persia: I have already looked at alsa-firmware, and I have asked Toby to use dh_installudev for the udev rule.
[05:07] <TheMuso> I should prod him about that.
[05:09] <persia> TheMuso: Ah.  Right.  My apologies - I'd forgotten the comment, and reminded it wasn't in yet about 12 hours ago.  There was also a request about ubuntu-settings, but I indicated that it was waiting for more feedback on the spec, which seemed to calm the inquiring party.
[05:09] <persia> s/ubuntu/ubuntustudio/
[05:09] <TheMuso> Yeah I don't think it will be done now.
[05:09] <TheMuso> But I don't want a hacky package in the archives.
[05:10] <TheMuso> I'm thinking we just throw it on the disks when they are built.
[05:10] <TheMuso> c
[05:10] <TheMuso> urgh
[05:10] <persia> TheMuso: That makes sense.  Given the CDs from universe issue, it's probably not that much extra trouble.
[05:10] <RAOF> New and different! :)
[05:10] <minghua> Nice unicode glyph.
[05:10] <TheMuso> heh
[05:11] <TheMuso> persia: Extra trouble in what way? Putting it only on the discs you mean?
[05:11] <persia> TheMuso: Pulling a single special non-repository package into the CD build.
[05:11] <minghua> U+2263 STRICTLY EQUIVALENT TO  # Hmm, I wonder how TheMuso can mistype to that.
[05:11] <persia> minghua: line noise is unpredictable :)
[05:12] <TheMuso> and so are KVMs with a crappily written screen reader.
[05:14] <TheMuso> ooo xfce4-timer-plugin has a 1.
[05:14] <persia> TheMuso: If you want an upload, http://revu.tauware.de/details.py?upid=6015 appears to be a good target
[05:14] <TheMuso> persia: I'm just thinking of getting some out of the way.
[05:15] <persia> TheMuso: I'll try to get you some more then :)
[05:15] <TheMuso> And I'll try and help out, but trying to manage a mass backup at the same time can be tricky.
[05:16] <TheMuso> Or ata least it sounds like it.
[05:19] <ScottK> leonel: Ubuntu-archive subscribed for squirrelmail backports.
[05:22] <ScottK> persia: Do you have a minute for a pm?
[05:25] <StevenK> TheMuso: It could be the disc itself.
[05:25] <TheMuso> StevenK: Well since it makes the same noise with three different disks I have used in it recently, I don't entirely think so.
[05:26] <StevenK> TheMuso: Does dmesg also complain about it?
[05:26] <TheMuso> StevenK: No.
[05:27] <StevenK> Hrm. I'd expect a dying drive to complain enough that the kernel would get some idea and log about it.
[05:29] <TheMuso> Wel I dunno...
[05:30] <leonel> FYI: to backport  python-psycopg2  from feisty to  edgy   needs  python-all-dbg to be backported too.
[05:33] <ScottK> leonel: We can dump the debug packages if we do a source backport.
[05:35] <persia> TheMuso: could it be mechanical alignment?  Sometimes a gentle jiggle can stop the annoying whirring sound of a CD not properly in track.
[05:35] <TheMuso> persia: Probably.
[05:35] <TheMuso> I dare not do that however, as it could make it worse.
[05:36] <leonel> ScottK: ok   just trying to build  psycopg2
[05:36] <ScottK> OK.
[05:37] <leonel> I hope psycopg  can be backported to dapper
[05:40] <leonel> python-defaults needs  python 2.5 and.. edgy has  2.4.4 
[05:40] <leonel> well 
[05:40] <ScottK> Edgy shipped wtih Python 2.5 packages.
[05:40] <ScottK> 2.4.4 is the default.
[05:41] <leonel> doh !
[05:50] <leonel> well  got to go  
[05:50] <ScottK> See you later.  
[05:50] <ScottK> Thanks for the help.
[06:23] <StevenK> trnsprob.c:217: warning: `a' might be used uninitialized in this function
[06:23] <StevenK> And the same thing for b, c, d, e and f.
[06:23] <StevenK> This code is ... special.
[06:23] <StevenK> Aside from the fact that it refuses to compile with GCC 4.1 or 3.4
[06:24] <persia> heh
[06:24] <TheMuso> StevenK: oooooouch
[06:24] <ajmitch> StevenK: does the author live nearby?
[06:25] <StevenK> I sincerly hope so.
[06:26] <ajmitch> I don't forsee a long future in software development for them
[06:27] <ScottK> Good evening Hobbsee.
[06:29] <Hobbsee> hi ScottK!
[06:29] <ScottK> The middle daughter is safely off to camp, crutches and all.
[06:30] <TheMuso> Fun.
[06:30] <ScottK> The good news is she's doing better.  She was putting a little weight on the foot before I left today.
[06:33] <ScottK> Good night all.  
[06:37] <Hobbsee> ScottK: yay!
[07:00] <StevenK> Oh wonderful. Not only is this package a pile of crap, it also requires GLw, which we don't support.
[07:01] <StevenK> arb
[07:03] <RAOF> It'd be on REVU, then, yes?
[07:04] <StevenK> No, it's in the archive. It's a direct import from Debian.
[07:06] <RAOF> So why doesn't packages.ubuntu.com know about it?
[07:07] <TheMuso> Because p.u.c is always out of date? :p
[07:07] <RAOF> Ah, because it FTBFS
[07:07] <StevenK> I was just about to say.
[07:08] <RAOF> And I didn't search on "source packages"
[07:09] <RAOF> Should I file a "xserver-xgl" FTBFS bug, or just fix it?
[07:09] <StevenK> I'm only looking at it since it Build-Depends on libglew-dev, but I'm wishing I didn't...
[07:09] <persia> I'm becoming convinced that a the journey of a package towards perfection is asymptotic in nature.
[07:10] <RAOF> I would have thought that was the obvious trajectory
[07:11] <persia> RAOF: Why?  The same resources that guide reviewers are available to packagers.  I'd think that more new packages would cross the barrier sooner as time passed.
[07:13] <StevenK> If I get my hands on the cruel sadist bastard who wrote this Makefile ...
[07:14] <RAOF> Because people are lazy, and will tend to only address problems when they're raised.
[07:15] <persia> RAOF: Depends on your viewpoint.  For my REVU candidate, I was too lazy to deal with comments, so I checked how to review, and did it myself first.
[07:18] <RAOF> persia: Heh.  Yes, depends on the person.  I think your form of active laziness is not too common, though :)
[07:20] <persia> RAOF: No.  Author?
[07:20] <RAOF> Terry Pratchett
[07:21] <RAOF> Everyone must read the discworld novels </hypnotoad>
[07:21] <StevenK> All power and glory to the hypnotoad!
[07:22] <RAOF> :)
[07:22] <StevenK> I spy another Futurama fan. :-)
[07:26] <StevenK> Neat. :-)
[07:26] <RAOF> Oh, yes.
[07:26] <StevenK> I've got Seasons 1, 2, 4 on DVD, and the whole lot as .avis
[07:28] <LucidFox> What does XSBC stand for in XSBC-Original-Maintainer?
[07:28] <persia> LucidFox: Experimental, Source, Binary, Changes
[07:28] <StevenK>   device-mapper: reload ioctl failed: Cannot allocate memory
[07:28] <StevenK> Ohhh
[07:29] <StevenK> [1288069.357028]  device-mapper: table: 254:52: snapshot: Could not create kcopyd client
[07:29] <RAOF> There's trouble at the ranch
[07:29] <persia> LucidFox: More verbosely, the X tells dpkg not to complain when making the package, and the SBC tell dpkg where to put the experimental header.
[07:30] <Amaranth> oh, i thought the X told dpkg not to complain and the rest was just some random string :)
[07:31] <StevenK> Neat. LVM seems to be very unhappy.
[07:31] <StevenK> [1288202.424546]  kernel BUG at mm/mempool.c:121!
[07:32] <persia> Amaranth: Nope.  There's a long explanation in http://www.debian.org/doc/debian-policy/ch-controlfields.html (5.7 - at the bottom)
[07:32] <StevenK> Given that lvremove just caused an Oops.
[07:32] <TheMuso> StevenK: Gutsy?
[07:32] <StevenK> Nope, Feisty
[07:33] <TheMuso> oooo
[07:42] <imbrandon> ...
[07:43] <RAOF> Hey imbrandon
[07:43] <imbrandon> lo RAOF 
[07:43] <TheMuso> Hey imbrandon.
[07:43] <imbrandon> heya TheMuso 
[07:51] <LucidFox> updated videotrans REVU upload per comments by gauvainpocentek@yahoo.fr 
[07:51] <LucidFox> http://revu.tauware.de/details.py?upid=6031
[08:00] <persia> LucidFox: Extra points for including the LP URL in a comment.  Looking now...
[08:19] <persia> LucidFox: 6031 commented
[08:21] <LucidFox> "missing manpages for movie-fakewavspeed, movie-progress, and movie-zoomcalc" - but upstream doesn't have them, these are undocumented binaries used by the scripts
[08:24] <persia> LucidFox: That makes it a little tricky.  There are two common options here: You could provide a single manpage for all of them, detailing that they are internal scripts, and that users probably want to look at (whatever) instead.  You might be able to glean a little about purpose and usage from the script source.  Alternately, you could add a linitan override, but expect to defend this when asked by reviewers.
[08:25] <persia> The latter case should only be used when the scripts really shouldn't be used by users ever, although it may be better to put them in /usr/lib/$package/ rather than /usr/bin, which I think also makes the error go away (I'm not sure about this last)
[08:56] <LucidFox> persia> can I put videotrans-undocumented.1.gz in debian/, then insert commands into debian/rules that would copy it into the man directory and symlink manpages for the missing commands to it?
[08:59] <persia> LucidFox: Even easier: you can put videotrans-undocumented.1 in debian/ and use debian/manpages to automatically compress and install it.  I think you want to use dh_link with debian/$package.links to create the symlinks.
[09:00] <LucidFox> ok
[09:01] <LucidFox> as for "a different way to change data/library.sh.in": I converted the change into a dpatch
[09:03] <persia> LucidFox: That's one of many possible and acceptable solutions (noting that I didn't actually look at the specific changes)
[09:10] <RAOF> So, who can read apport backtraces?  bug #126207 has one which looks temptingly like "your proprietary fglrx drivers suck at Xv"
[09:10] <ubotu> Launchpad bug 126207 in democracyplayer "democracyplayer.real crashed with signal 5 in _XError()" [Undecided,New]  https://launchpad.net/bugs/126207
[09:13] <persia> RAOF: I'd be happy to look at the backtrace with you.  From a first glance, it looks like GDK wasn't happy about receiving the X error.  Where do you want to start?
[09:14] <eagles0513875> RAOF: lol when doesnt anything ati related not sux lol
[09:16] <RAOF> persia: Wherever a good place to start is?
[09:16] <persia> RAOF: OK.  I like to start with Stacktrace.txt, as I usually find it to be the most informative.
[09:17] <persia> Does anyone have any objections to us looking through the stacktrace in-channel?  We can move somewhere else if preferred.
[09:17] <eagles0513875> fine with me
[09:17] <eagles0513875> might learn something
[09:17] <Hobbsee> persia: please do
[09:17] <RAOF> I'm sure everyone would love an example stacktrace post-mortem
[09:18] <persia> RAOF: OK.  The part that looks interesting to me is #3, where we get _XError, in response to _XReply (line #4)
[09:19] <RAOF> Ok
[09:20] <RAOF> Which then seems to call something in gdk?
[09:20] <RAOF> Which, in turn, seems to want to log the error, presumably
[09:20] <Fujitsu> It shoudn't crash when calling _XError, but the error could be put down to dodgy drivers.
[09:21] <persia> RAOF: Now, we don't actually know what caused this, so we'll go back a little further, so we can get an idea of what is supposed to be happening.  I'd suggest going all the way back to line #10, and we'll figure out what's trying to happen with xineAttach ().  I'm guessing this is in some python-xine API, so you'll want to figure out which package we need to inspect.
[09:21] <LucidFox> what is meant by "Please differentiate - from (hy in the manpage "?
[09:21] <persia> RAOF: Right - that's what the trace means.  Actually understanding it means we have to look at the code.  Often, it's just that someone forgot to trap some condition, and it can be patched to provide a nice error message.
[09:22] <persia> LucidFox: \- is a minus sign.  \(hy is a hyphen.  groff turns them into different characters, so it's important to say which you mean in the source.
[09:22] <RAOF> persia: So, xineAttach is going to be from the (pyrex'd) democracyplayer xine bindings
[09:23] <persia> RAOF: That's where a little knowledge about democracy player is going to help.  I'm not sure if it's democracyplayer python code or xine python code.
[09:24] <eagles0513875> persia: so u would want to check both of them no
[09:24] <persia> eagles0513875: Right.  We're looking for the xineAttach () function call, and hoping to have some idea of how it might have been called, as otherwise we have to go back even further.
[09:25] <RAOF> persia: It's democracy (kinda) python code.  Specifically, it's C bindings generated from a python-like file
[09:25] <persia> RAOF: That sounds like a python binding to a C library to me :)  Which file?
[09:26] <RAOF> platform/gtk-x11/xine/xine.pyx
[09:27] <Fujitsu> I think boost does that sort of thing.
[09:28] <persia> RAOF: OK.  When I look at that, it appears to just be passing the arguments to libxine (or at least I don't see any implementation).  Would that makes sense to you as well?
[09:28] <RAOF> Yes.  That's pretty much what the file is trying to do
[09:29] <eagles0513875> persia: does that mean everything is fine but a problem with the ati binary
[09:29] <persia> RAOF: OK.  Let's take a look at xine, to figure out what happens next.  We'll want to look for the function in line 9 from the libxine source.
[09:29] <RAOF> Ah, the actual imlementation is in xine_impl.c, in the same dir
[09:30] <persia> eagles0513875: No idea yet.  It only means we found the last place touched in the democracyplayer code.
[09:30] <eagles0513875> ok
[09:30] <RAOF> persia: line 210
[09:30] <persia> RAOF: Good eyes!
[09:31] <persia> Now, since line 9 is xine_open_video_driver, we can probably get some context about how we called xine from this file.
[09:32] <persia> i'm looking at line 239, and it looks to me like we're setting xine->videoPort to be the return pointer from the call to xine, and we're not checking for the response code.
[09:33] <RAOF> Ah, yes
[09:34] <persia> So, one way to address the issue from this bug is to wrap this call (and probably also xine_open_audio_driver() ) in some wrapper that detects the issue, and gives the user a nice error message.
[09:34] <eagles0513875> persia: so from what i gather what is being called isnt returning a response
[09:34] <RAOF> It also seems like we're requesting an X11 window, which seems odd given libxine is complaining about a XV issue.
[09:35] <persia> But, this doesn't actually solve the root problem, which is that we're getting a crash when we start xine under certain circumstances, so while we've defined a task for democracyplayer, we're not done with the stacktrace.
[09:35] <persia> eagles0513875: Actually, it crashed before it could provide a response.
[09:35] <RAOF> Ah, Ok
[09:35] <eagles0513875> ok
[09:35] <RAOF> That was going to be my next comment :)
[09:35] <RAOF> So, now to libxine?
[09:36] <persia> RAOF: democracy player is passing "X11" to xine, but democracyplayer doesn't necessarily understand the underlying xine implementation, so the X11 vs. XV thing may be a red herring.
[09:36] <persia> Right.  Now to libxine.  Let's get the source, and look for xine_open_video_driver()
[09:36] <RAOF> persia: Yeah, I don't know anything about the libxine internals
[09:37] <persia> RAOF: That's OK.  We're only looking at the code.  Even if we can only understand 20%, we can probably follow the trace, and perhaps generate a bug that xine also isn't trapping properly when it gets a signal 5 from X.
[09:39] <persia> Ooh.  xine's not small.  Perhaps we'll not dig as far as X (which is even larger) then :)
[09:39] <RAOF> :)
[09:39] <eagles0513875> lol
[09:39] <eagles0513875> if my power goes out ill brb lol
[09:39] <RAOF> Yes, until I've got a better connection I think I'll stay away from X :)
[09:39] <eagles0513875> RAOF: what connection u on atm
[09:40] <RAOF> eagles0513875: A university one
[09:40] <eagles0513875> RAOF: lol nice im on a 2mb down 256 up cable connection but what suxs is 10gb monthly download limit
[09:42] <RAOF> Right, so we appear to be after src/xine-engine/load-plugins.c
[09:42] <RAOF> line 1584
[09:44] <persia> RAOF: That looks right to me.  Now we need to get our context.  democracy player passed some arguments, and the one we probably care about is X11 which is now stored in visual_type
[09:45] <persia> Next, in this function, we're looking for _x_load_video_output_plugin, to try to figure out what's happening.
[09:46] <RAOF> Which is just above the previous function
[09:48] <persia> Now it gets tricky :)  The next thing that happens is a call to some function in xineplug_vo_out_xv.so, but we don't know the function name, as the stacktrace doesn't have all the symbols interpolated.  Unless we really understand things, we'll have to stop soon, but given that the error checking in xine_open_video_driver() isn't catching the problem, there's another bug here.
[09:48] <RAOF> Mmm
[09:50] <RAOF> So, we're looping through the video plugins list, trying to find one which matches visual_typ.
[09:50] <persia> Given the content of the function we're examining, I think it's a good bet that we're probably crashing in _load_video_driver somewhere, having passed our visual_type (and probably having xine automatically do the X11 -> XV change when we weren't looking.
[09:50] <persia> RAOF: That's my interpretation of the code.
[09:52] <persia> Thnking about it more, XV is probably the first plugin in plugin_lists that can provide X11
[09:52] <RAOF> Yeah, it's probably preferred.
[09:53] <persia> Hmm.  But _load_video_driver is defined on line 1519 of this file, and the stacktrace doesn't show it, so the problem is probably earlier up in the list.
[09:54] <eagles0513875> persia: im installing democracy as we speak im starting to wonder whether its a kde gnome compatibility issue cuz i noticed it was downloading some gnome libs
[09:54] <eagles0513875> would the desktop its running on have anythign to do with it
[09:54] <Amaranth> not at all
[09:54] <eagles0513875> ok
[09:54] <persia> eagles0513875: There may be such an issue, but that's not the current problem in any way.
[09:54] <RAOF> I'm not sure how the backtrace can fail, but ok
[09:54] <eagles0513875> pl
[09:54] <eagles0513875> *ok
[09:55] <eagles0513875> i just tried to run it and it just crashed on me
[09:55] <RAOF> So, if it's higher in the list, where may it be?
[09:56] <RAOF> eagles0513875: Are you on Gutsy?
[09:56] <eagles0513875> ya 64bit
[09:56] <persia> RAOF: The backtrace really shouldn't fail.  Since there's no listing of _load_video_driver, we're likely seeing a crash between lines 1537 and 1562.  Given that the problem happens in the plugin, we should now try to figure out which variable is used for the plugin, and if any functions in the plugin are called in these lines.
[09:56] <RAOF> Why can everyone but me crash democracy??
[09:56] <eagles0513875> RAOF: what version u on
[09:56] <persia> RAOF: You're working on it, the bugs are smart, and hide :)
[09:57] <eagles0513875> lol or they auto correct themselves at least for me they do sometimes
[09:57] <RAOF> eagles0513875: I couldn't crash either Feisty or Gutsy's democracy on 64bit (32bit I could, for some reason)
[09:57] <eagles0513875> lol im on 64bit gutsy and democracy just crashed on me
[09:58] <eagles0513875> i dont know if this will help 
[09:58] <eagles0513875> but this is the bug that i got democracyplayer.real crashed with ImportError in <module>()
[09:58] <persia> So, based on line 1557, it appears the plugin is being called node.
[09:59] <persia> lines 1559 and 1562 appear to be getting some information from node, so one of these is likely the next step.
[10:01] <RAOF> Yes.  I *think* we can discard 1562, since as I read it we're passing in "auto" as id, which gets NULLd by  1550
[10:04] <persia> RAOF: One certainly hopes so :)  If it was 1562, it would mean the plugin couldn't even return it's own ID, which sounds like a larger problem.  Shall we look at 1559 then?
[10:04] <RAOF> Hm.  I'm not sure why the existance of the xv plugin further up in the backtrace doesn't suggest the problem is further down.  Let's look at 1559
[10:05] <persia> OK.  I think we want libxine1-plugins, but let me check before you clog your connection :)
[10:05] <RAOF> Aren't they built from the same source :(
[10:05] <persia> RAOF: conveniently, yes :)
[10:05] <RAOF> Yay!
[10:08] <persia> I'm looking at line 1718 of video_out_xv.c, as this seems the most likely target, but it's not very informative.  Any other ideas?
[10:09] <persia> (to me it looks like it is supposed to return 9, without ever calling X or anything)
[10:10] <RAOF> I think that _load_video_driver is getting called, since the plugins are (I think) dynamically loaded.
[10:11] <RAOF> In fact, are dlopened (in _load_plugin_class) unless we've got them statically linked
[10:15] <persia> RAOF: The thing that confuses me about that is that line 8 of the backtrace is clearly 1519 in libxine, and the next level in (remember, the stacktrace is a stack, not a sequence) is in xineplug_vo_out_xv.so.  If we'd called _load_video_driver, we should be within that function (unless it already exited successfully) when we crash.  Perhaps there's something in libxine after _load_video_driver?
[10:16] <persia> s/1519/1537/
[10:16] <LucidFox> http://revu.tauware.de/details.py?upid=6033 -- corrected per persia's comments
[10:17] <RAOF> Not in _x_load_video_driver
[10:18] <persia> To me it looks like the next thing is pthread_mutex_unlock (&catalog->lock) (which isn't in the trace), and then we go back to xine_open_video_driver.
[10:18] <RAOF> Yeah
[10:19] <RAOF> Unless, I suppose, the calls are threaded, and the error is not synchronous with the stack?  (I'm really not sure if this happens)
[10:19] <persia> Right.  So, I'm still convinced the problem is either getting special_info or getting the id.  Getting special_info is two calls, which matches the stacktrace.  Let's also look at ID, to see if that's one call or two.
[10:19] <persia> RAOF: All the calls are threaded, but if we were in a waiting thread, the last entry would be sem_wait (see threadstacktrace for an example).
[10:19] <RAOF> Ah, cool
[10:20] <persia> RAOF: More verbosely, when we're waiting, we're running the wait function, so when we crash, that appears.  This stacktrace is only for the thread that crashed (which is why I thought it was a good place to start).
[10:21] <RAOF> Fair enough
[10:24] <persia> OK.  Both lines 1559 and 1562 (in src/xine-engine/load_plugins.c) call node->info, which appears to be defined on line 1718 of src/video_out/video_out_xv.c.  line 1559 wants the "special_info" value, and line 1562 wants the "Id" value.
[10:24] <persia> s/Id/id/
[10:25] <persia> So, special_info calls vo_info_xv, which is how we get our match on video_type of X11
[10:26] <persia> I don't see a reference for id, but as this is a special definition, rather than a normal function, we might be able to determine something from the header files.
[10:26] <RAOF> Ah.  s/calls/points to
[10:27] <persia> RAOF: Right.  Thanks for the correction (my C++ is sometimes enough, but I'm not an expert).
[10:29] <persia> I'm guessing the interesting header is one of xine.h, video_out.h, or xine_internal.h
[10:30] <RAOF> grep says "xine-engine/xine-plugin.h".  And the id field seems to be the string "xv"
[10:30] <persia> At this point, it's probably worth looking in doc/hackersguide/hackersguide.html to try to understand things, as we're getting into deep xine code (sometimes passing through a library is quick, but not in this case).
[10:31] <persia> RAOF: Excellent.  That would be it.  Do you see the possibility of two function calls, or does it look atomic?
[10:33] <RAOF> It doesn't seem to be function calls at all, just pointer dereference (but I'm not sure how that shows up on the backtrace).  And, no, they're literal strings in the definition, so that should be atomic
[10:35] <persia> RAOF: A pointer dereference isn't likely to show in the backtrace at all.  It's just a list of all the functions on the stack.  Given that special_info was definitely pointing to a function, I'm thinking that that's responsible, but I'm not sure how we're getting to XvGetPortAttribute in libXv.
[10:35] <eagles0513875> persia: y dont u guys use a debugging program to make this a whole lot easier or it wouldnt make it much easier
[10:36] <RAOF> Hm.  I don't see special_info pointing to a function?  It points to the "static const vo_info_t vo_info_xv = {...}" struct declaration
[10:36] <RAOF> eagles0513875: We're running through the outcome of such a debugger :)
[10:37] <persia> eagles0513875: If we could replicate the error locally, certainly.  Without that, I usually go by hand, which helps me learn the code (important if I'm going to fix it).  If you can help us to use a debugger to get here, please suggest how.
[10:38] <eagles0513875> persia: i dunno dude i didnt think you would have to replicate teh code locally i thought u could use the source go and run the debugger and see what if anything it would find
[10:38] <persia> RAOF: No, you're right.  Perhaps the dlopen() doesn't actually count as a function call for the backtrace, and we're in the initialisation code for xineplug_vo_out_xv.  Anyway, let's jump ahead, and find XvGetPortAttribute
[10:38] <RAOF> eagles0513875: Incidentally, your import crash was probably due to missing dependencies (my fault).  File that apport crash on LP and I should be able to fix it easily.
[10:39] <persia> I find three occurances in video_out_xv.c: 912, 1097, 1207
[10:39] <eagles0513875> RAOF: i used apt-get install wouldnt that also download any dependencies
[10:40] <RAOF> eagles0513875: Not if I haven't included all the dependencies in the package description
[10:40] <eagles0513875> oh
[10:41] <eagles0513875> for democracy woudl u need a tv tuner or could u run it through ur cable internet connection
[10:41] <RAOF> persia: Yup.  Lets find the one in the function most likely to be called in initialisation
[10:42] <persia> RAOF: It's hard to be sure without a full symbolic backtrace, but I'm suspecting xv_check_capability()
[10:43] <RAOF> Which would mesh nicely with "your fglrx drivers are crap" :)
[10:44] <persia> RAOF: Yep :)  Now we have some strong indications that your intitial assumptions were correct, and also have identified an issue with democracy player not checking to make sure that it could create a xine video out.  Note especially the comment about the ATI drivers in that function.
[10:44] <eagles0513875> :)
[10:44] <eagles0513875> i despise ati
[10:46] <persia> So, there's probably a bug in xine at this point, but such a bug would be a workaround for broken secret drivers, so there's not a lot of incentive to fix it.  There's also some issue in X where it bounced trying to report an error, but again, it's hard to figure it out with what we have available (especially with the ?? right after _XError().
[10:46] <persia> I'd say we can't get any farther without 1) downloading the X sources, and possibly 2) looking at the driver.
[10:47] <eagles0513875> persia: j/w woudl it be possible in gutsy to have the binary driver automatically installed if u have an ati video card and also have it make the necessary modifications to the xorg and what ever else need modification for open gl to work
[10:47] <RAOF> The init function (open_plugin2) calls xv_check_capability repeatedly.  Colour me totally disinterested in attempting to understand the binary blob
[10:47] <RAOF> eagles0513875: System->Administration->Restricted Manage
[10:47] <persia> eagles0513875: Possibly.  I'm not familiar with that codebase at all.
[10:48] <eagles0513875> i have an wiki on how to do it but it would be a huge improve ment and so much easier for those who dont know much about editing the xorg.conf and that stuff
[10:48] <RAOF> eagles0513875: It's possible in *Feisty*.  Well, unless you're using Kubuntu :)
[10:49] <persia> RAOF: OK then :)  You should now have enough information to 1) get back to the bug submitter with an intelligent comment, and enough techinical details that they can follow up if they are interested, 2) fix the (very minor) issue in democracyplayer, and 3) not be stumped next time you get an apport bug .
[10:49] <eagles0513875> RAOF: couldnt that be ported to kubuntu
[10:49] <RAOF> persia: Yes.  Thanks very much.  We should probably point to this log somewhere :)
[10:49] <persia> Does anyone have any other questions about chasing apport bugs?
[10:50] <Hobbsee> eagles0513875: someone already is
[10:50] <RAOF> eagles0513875: Yes, it is already being.  You just get it a little bit later
[10:50] <Hobbsee> persia: will you fix them all?
[10:50] <eagles0513875> woot
[10:50] <persia> RAOF: If you have time to extract the good bits into a wiki, that would be great :)
[10:50] <persia> Hobbsee: No.
[10:50] <Hobbsee> persia: damn.
[10:50] <eagles0513875> poor hobbsee
[10:51] <RAOF> persia: I may try that this evening
[10:51] <eagles0513875> Hobbsee: welcome back btw
[10:52] <persia> RAOF: Thanks a lot.  Let me know when you have a draft: I'd be happy to help review (this is my third stacktrace reading lesson for gutsy).
[10:52] <Hobbsee> thanks
[10:52] <RAOF> persia: Oh, I've obviously been somewhere else for the others :)
[10:53] <eagles0513875> i need to work on my programming skills before i join u masters otu
[10:53] <persia> RAOF: Different places anyway.  It's good to have one here for a change.
[10:54] <RAOF> :)
[10:55] <eagles0513875> persia: whats next on the debugging list lol
[10:57] <persia> eagles0513875: There's about 30,000 open.  Pick one.  I think there's only a few thousand apport bugs, but you should still have a wide choice.  Give it a shot, see how far you can get, and ask here (or in #ubuntu-bugs) if you get stuck.
[10:57] <eagles0513875> lol
[10:57] <eagles0513875> i wont get vry far my programming extent is html lol
[10:58] <persia> eagles0513875: Give it a shot anyway.  If you're not up on programming, I'd suggest picking one for a language you'd like to learn, and reading it in combination with the source and a programming manual.  It's not a bad way to learn, and it's really satisfying to find a fix for a bug that was missed by the original developers.
[10:58] <eagles0513875> true
[10:59] <eagles0513875> persia: i dont know how much u wanting to learn bout kernels but in a magazine i found a link to an interesting book linux kernels in a nutshell
[11:00] <eagles0513875> persia: www.kroah.com/lkn
[11:00] <eagles0513875> its the whole linux in a nutshell book
[11:02] <eagles0513875> persia: can i get ur opinion on something
[11:04] <persia> eagles0513875: You'll likely get a better response by asking the channel in general.  This is especially true when someone has just finished a long discussion, as they are likely to be doing something else.
[11:04] <eagles0513875> persia: sry dude
[11:05] <persia> eagles0513875: No need to apologies.  What's the question?
[11:05] <eagles0513875> im having a problem with amarok and kde 3.5.7 for some reason through out any song im listening to it cuts out intermittetly 
[11:05] <eagles0513875> i reported it to kde.org but should i also open a bug for kubuntu
[11:05] <eagles0513875> and all my audio is in flac i dont know whether its an amarok issue or flac issue
[11:06] <persia> eagles0513875: I'm really not the best person to ask about that, and you'll probably get better guidance from a support request, a discussion in #ubuntu, or a bug.
[11:07] <eagles0513875> instead of opening a bug ill try figure it out mysefl from the source
[11:09] <Hobbsee> RAOF: wouldnt matter.  they wouldnt read it
[11:09] <Hobbsee> or if they did, they'd go "i want to see if this is actually a bug, if others have it, before reporting"
[11:10] <Hobbsee> which is fine, although they never actually go and file the bug.
[11:10] <RAOF> Yeah
[11:11] <Hobbsee> debian bug #288003
[11:11] <ubotu> Debian bug 288003 in wnpp "ITP: kguitar -- full-sized guitarist" [Wishlist,Fixed]  http://bugs.debian.org/288003
[11:17] <cbx33> ping doko
[11:24] <persia> LucidFox: 6033 commented.  Great work, but 1 little minor issue.
[11:31] <man-di> In debian tomcat5 has a request for removal (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425296). tomcat5.5 superseded it. When should I file a removal request for Ubuntu? Now or when tomcat5 was removed from Debian?
[11:31] <ubotu> Debian bug 425296 in ftp.debian.org "RM: tomcat5 -- RoM; superseded by tomcat5.5" [Normal,Open]  
[11:31] <Hobbsee> man-di: either.  now will do, and link to the debian bug
[11:32] <persia> man-di: I suggest now.
[11:40] <man-di> thanks Hobbsee and persia 
[11:40] <man-di> will file one
[11:47] <LucidFox> persia, I did try adding a blank line before homepage in debian/control, but it gave me an error message
[11:47] <LucidFox> dpkg-source: error: syntax error in control file ./videotrans-1.6.0/debian/control at line 22: continued value line not in field
[11:48] <persia> LucidFox: You need to use " ." for a "blank line", as described at http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description
[11:49] <LucidFox> ah
[11:51] <persia> LucidFox: Also, you probably want two leading spaces for Homepage (I didn't check to see if they were there)
[11:56] <LucidFox> movie-make-title.1 is the only manpage left with the hyphen problem?
[12:06] <persia> LucidFox: The only one lintian found.
[12:18] <man-di> dholbach: thx for fixing my typo
[12:19] <dholbach> man-di: no problem
[12:19] <dholbach> man-di: what about jsp-wiki and whatever the other package was called - can we just bump the depends to tomcat5.5?
[12:23] <yamal> if a rules file contains no "build:" lintian complains it's a required part missing. In case the package doesn't need it, is it ok to be left out or should there be an empty one so lintian shuts up?
[12:25] <persia> yamal: If there's no build rule, and you end up with a binary package, something is very odd.
[12:25] <yamal> it's a package that has only some skins
[12:25] <persia> yamal: If not by build, then by what is the binary package being created?
[12:25] <persia> yamal: So there's only installation?
[12:26] <yamal> basically :)
[12:26] <yamal> look at mplayer-skins 
[12:29] <persia> yamal: I'm not getting a lintian error related to debian/rules in mplayer-skins, just warnings about standards-version and NMU.
[12:30] <yamal> hmm lemme try again then
[12:34] <yamal> lintian -i mplayer-skins_2-6.dsc
[12:34] <yamal> enyc: mplayer-skins source: debian-rules-missing-required-target build
[12:34] <LucidFox> persia: http://revu.tauware.de/details.py?upid=6034
[12:34] <persia> yamal: pastebin your debian/rules
[12:34] <man-di> dholbach: should just work to bump the dependency, I will keep care of this in Debian and then file a sync request
[12:34] <yamal> this was with the standard one from 2-6
[12:35] <dholbach> man-di: ok super - thanks a lot!
[12:35] <yamal> !paste
[12:35] <ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
[12:35] <persia> LucidFox: Advocated.
[12:35] <LucidFox> yay! :)
[12:36] <persia> LucidFox: Now, find someone else :)
[12:36] <yamal> persia: http://paste.ubuntu-nl.org/30090/
[12:40] <persia> yamal: Oddly that looks like mine.  Considering that I am usually accused of coaxing more output from lintian than other people, I'm somewhat surprised, although I have a couple other extended lintian things I can check.  Also, I don't like d:=  wouldn't the use of dh_installdirs be cleaner?  Also, if you wanted to be tricky, you could use a tar xvf build-tree in a build: rule, and then do something with dh_install.  For a minimal change complian
[12:40] <persia> (or rather a build rule that did nothing, on which install: depended)
[12:42] <yamal> persia: (if you replied since I posted the paste link please say again my connection failed)
[12:42] <persia> yamal: Found it.  I can replicate the error now.  You'll want an empty build rule.
[12:42] <yamal> ok thanks :)
[12:42] <persia> yamal: Sorry.  Repeating now: "Oddly that looks like mine.  Considering that I am usually accused of coaxing more output from lintian than other people, I'm somewhat surprised, although I have a couple other extended lintian things I can check."
[12:42] <persia> "Also, I don't like d:=  wouldn't the use of dh_installdirs be cleaner?  Also, if you wanted to be tricky, you could use a tar xvf build-tree in a build: rule, and then do something with dh_install.  For a minimal change compliance upload, I might add a build rule that only depended on install, and didn't actually do anything."
[12:43] <persia> "(or rather a build rule that did nothing, on which install: depended)"
[12:43] <dholbach> ScottK: what's wrong about 124594?
[12:43] <dholbach> I think that it's VERY valid to get package updates sponsored
[12:44] <persia> bug 124594
[12:44] <ubotu> Launchpad bug 124594 in archmage "upgrade version available 0.1.9" [Wishlist,In progress]  https://launchpad.net/bugs/124594
[12:44] <DarkSun88> dholbach: https://bugs.launchpad.net/ubuntu/+source/libembperl-perl/+bug/126151
[12:44] <ubotu> Launchpad bug 126151 in libembperl-perl "Please sync libembperl-perl 2.2.0 (universe) from Debian unstable (main)" [Wishlist,Incomplete]  
[12:44] <DarkSun88> :)
[12:44] <DarkSun88> Synced.
[12:44] <DarkSun88> See you later.
[12:44] <dholbach> and we need a better way to track that than 'check the long list of REVU uploads' :-/
[12:44] <dholbach> DarkSun88: rock on - thanks a lot
[12:44] <dholbach> DarkSun88: have a nice day
[12:44] <DarkSun88> dholbach: You're welcome.
[12:45] <persia> What!  That's exactly how https://wiki.ubuntu.com/MOTU/Contributing asks for contributors to track upgrade requests.  That's an excellent U-U-S bug.
[12:45] <dholbach> yes
[12:46] <persia> Hobbsee: Nah - we recovered something 6 months old a couple days ago: I think we're in decent shape.
[12:46] <Hobbsee> right
[12:52] <persia> dholbach: Are you just triaging, or are you reviewing 124594?
[12:53] <dholbach> persia: I just uploaded it
[12:53] <dholbach> it was good
[12:53] <persia> dholbach: Ah.  Excellent.  I was confused by the "resubscribing" comment, and would otherwise have reviewed myself :)
[12:54] <dholbach> oh yeah - I just thought it was worth resubscribing and pointing out that it's a valid thing to do
[12:54] <persia> dholbach: Certainly.
[12:56] <LucidFox> in this case, persia, could you review gpac 0.4.4?
[12:56] <LucidFox> ah, wait
[12:56] <LucidFox> another one already has reviewed it
[12:57] <persia> LucidFox: When you're ready, please make a request.  I prefer to review either fresh uploads, or things that have been advocated :)
[12:58] <LucidFox> you could review qconf: http://revu.tauware.de/details.py?upid=5952
[12:59] <persia> LucidFox: Thanks :)
[12:59] <LucidFox> although wait a bit
[12:59] <LucidFox> I'll make some changes to debian/control and debian/changelog first
[01:00] <persia> LucidFox: OK.  Also, you probably want to run as many automated checks as you can imagine, as I'm limited to 2048 characters of review space :)
[01:02] <persia> Debian bug 414964
[01:02] <ubotu> Debian bug 414964 in lintian "lintian: debian-rules-missing-required-target references policy section 4.8 instead of 4.9" [Minor,Fixed]  http://bugs.debian.org/414964
[01:02] <Vorian> j #aalug
[01:06] <persia> yamal: I found the source of the confusion.  Apparently the message you are getting stems from a bug in lintian (Debian bug 414964).  Specifically, because you have build: listed as a dependency of .PHONY:, no extra paragraph is required.  My apologies for the misdirection previouly given.
[01:06] <ubotu> Debian bug 414964 in lintian "lintian: debian-rules-missing-required-target references policy section 4.8 instead of 4.9" [Minor,Fixed]  http://bugs.debian.org/414964
[01:07] <yamal> persia: so basically, no build required
[01:07] <persia> Grr.  That was supposed to be debian bug 419446
[01:07] <ubotu> Debian bug 419446 in lintian "debian-rules-missing-required-target false positive with phony targets" [Normal,Fixed]  http://bugs.debian.org/419446
[01:07] <persia> yamal: Right.
[01:07] <yamal> tx
[01:08] <LucidFox> persia> what parameters are you running lintian with?
[01:09] <persia> LucidFox: I usually start with -iIv, but sometimes add more or use different lintians, depending on what I'm seeking.  For REVU, I use gutsy lintian with -iIv.
[01:20] <persia> blueCommand: About socket++ licensing.
[01:20] <blueCommand> Ah, hello :)
[01:20] <blueCommand> Yes :)
[01:21] <persia> Bascially, it looks like the package has a very permissive "keep my copyrights" notice.  I've been convinced that it's acceptable to package this with GPL packaging, but I generally think that it's better practice to keep them similar, so if someone wants to use your packaging or patches with the code later, there aren't any restrictions.
[01:22] <persia> The largest issue that can arise with GPL packaging and a more permissive upstream license is that if any patches are developed locally, they need license exceptions (or dual licensing) to be distributed upstream.  If you really want the GPL for some reason, that's OK, but I just think it's easier to use a similar license to upstream.
[01:23] <blueCommand> So I just write the same notice that the source has for the package licensing?
[01:25] <TheMuso> c
[01:25] <TheMuso> ugh
[01:25] <persia> blueCommand: Either that, or you can use a phrase like "the packaging is copyright 2007 Your Name, and may be distributed under the same terms as the packaged code, as described above".
[01:25] <blueCommand> The Debian packaging is (C) 2007, Christian Svensson <blue@cmd.nu> and
[01:25] <blueCommand> is licensed under the same license as the sourcecode:
[01:25] <blueCommand> And then I included the license again
[01:25] <blueCommand> Will that do?
[01:26] <persia> blueCommand: That might work.  I haven't seen language like that in other packages, but I can't say whether it would be valid or invalid in any given jurisdiction.
[01:27] <blueCommand> persia, I will copy yours to be sure
[01:27] <imbrandon> i was under the pretty clear assumption that the patches and packaging could and most of the time is under seperate licenses
[01:28] <persia> blueCommand: Also, (c) and (C) have no legal meaning in most jurisdictions, but @ does.
[01:28] <blueCommand> @?
[01:28] <persia> imbrandon: Sure.  I've been convinced they may have separate licenses, but as noted above, it can make merging patches back upstream tricky.
[01:29] <persia> blueCommand: Sorry.  
[01:30] <blueCommand> Ah ok
[01:30] <LucidFox> persia: http://revu.tauware.de/details.py?upid=6038
[01:30] <imbrandon> i dont see how the package lic affects the patch lic in any way shape or foprm though, if the patch isnt licensed it is NOT assumed to be the same as the packageing , e.g. i can package something bsd lic and have gpl packageing and have a bsd patch, no trickey merging there, guess i'm miss reading what you are typing
[01:30] <LucidFox> ready for review now
[01:31] <persia> LucidFox: You'll always get a better response asking the channel for a review, rather than a specific person :)
[01:32] <LucidFox> are there any other reviewers present?
[01:32] <persia> imbrandon: No, you're not misreading.  It's just that the "packaging" usually means the contents of diff.gz.  For a BSD patch in GPL packaging, this should require special notice in the patch, and perhaps an update in debian/copyright, as usually when BSD and GPL are mixed, the result is GPL.
[01:34] <blueCommand> persia, There, new one in REVU if you feel like taking a look
[01:35] <blueCommand> Depends: ${shlibs:Depends}, ${misc:Depends}, java-virtual-machine, when I have that lintian says I have no real depends. I tried adding sun-java6-jre, but same warning is shown.
[01:35] <persia> blueCommand: You'll do best to advertise the new upload in this channel, and include the link to REVU.
[01:35] <blueCommand> Right, sorry
[01:35] <blueCommand> http://revu.tauware.de/details.py?upid=6037
[01:35] <blueCommand> New upload: libsocket++, review please :D
[01:44] <persia> LucidFox: 6038 commented.
[01:49] <LucidFox> Hmm, amd64? I'm lucky to have an AMD64 CPU, then - I'll make an AMD64 installation on a separate partition and test it there
[01:49] <LucidFox> does it build on other architectures besides amd64?
[01:49] <persia> LucidFox: I didn't test that :)
[01:49] <LucidFox> ah
[01:51] <LucidFox> Wait, I think I know...
[01:59] <marcin_ant> hi all
[01:59] <marcin_ant> I got a big problem
[02:00] <marcin_ant> I want to prepare package using cdbs
[02:00] <marcin_ant> the problem is that I got source for my package in *.zip file
[02:00] <marcin_ant> and I use tarball.mk class to extract source to build-directory
[02:01] <marcin_ant> unfortunately with this construction I don't know how to create dpatch for source since there is no source-directory
[02:01] <marcin_ant> could someone tell me how to solve this problem?
[02:09] <persia> REVU Uploaders: when making a new upload for something previously announced, please announce the new upload, so as to ensure reviewers are looking at the latest version of your code.
[02:12] <RAOF> Hooray for autotools wierdness.  Current xgl git fails to make distclean, because of a variable (non)expansion in the .deps of solaris support.
[02:13] <RAOF> persia: I won't get to writing up anything this evening, but I've been thinking of doing a write up of essentially what we did. ie "look at this bug, and this stack trace.  Now... " etc.  Comments?
[02:16] <persia> RAOF: That sounds good to me.  That was an interesting bug because we ended up finding two issues: both the failure to trap and the ATI oddness.  Let's hope that from that outline someone will be able to develop a HOWTO that could lead people through doing it from scratch.
[02:17] <RAOF> Dear lord, xorg's configure.ac is huge.
[02:20] <RAOF> Bah, good night all, especially persia :)
[02:20] <persia> Good night RAOF
[02:23] <persia> blueCommand: 6039 commented
[02:23] <blueCommand> Thanks
[02:26] <blueCommand> persia, Homepage: URL, is it as simple as it sounds?
[02:26] <blueCommand> " want to build something from source.
[02:26] <blueCommand>  Homepage: http://www.linuxhacker.at/socketxx/
[02:26] <blueCommand> "
[02:27] <persia> blueCommand:http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description is recommended reading for best syntax of Descriptions, but something very similar to that, yes.
[02:28] <blueCommand> Thanks, I'll make sure to read that
[02:35] <blueCommand> persia, Sorry bother you, but I can't find any references to Homepage. And neither can google :\
[02:36] <blueCommand> And another thing, lintian says W: libsocket++1-dev: old-fsf-address-in-copyright-file, but am I really allowed to change the license?
[02:36] <persia> blueCommand: Just put "  Homepage: URL" as the last line of the long description (the spaces are important).  I suggest it's better to add " ." on the line above for improved readability.
[02:37] <blueCommand> Ok
[02:37] <persia> blueCommand: You are allowed to change the FSF address in debian/copyright (you wrote it), but I usually leave the old address in the original source (I'm not sure if that's correct).
[02:38] <blueCommand> Gotcha
[02:38] <xxxxx1> hello all!
[02:38] <ScottK> marcin_ant: Not sure if it would work or not, but did you try cdbs-edit-patch?
[02:38] <ScottK> Good morning everyone.
[02:38] <Hobbsee> morning ScottK 
[02:39] <blueCommand> morning ScottK 
[02:39] <StevenK> ScottK: I missed something you said to me roughly 24 hours ago, what was it, and do you still need help with it?
[02:39] <ScottK> Hello Hobbsee, StevenK, blueCommand.
[02:39] <StevenK> ScottK: (At the time, my machine was under the stress of a 1.3Gb g++ process)
[02:40] <ScottK> StevenK: Persia gave me a hint, so I'm not sure.  Do you know anything about Ruby libs and qt4 bindings?
[02:40] <StevenK> Not much of anything, but I can try.
[02:40] <ScottK> Bug #125865 is the issue at hand.
[02:40] <ubotu> Launchpad bug 125865 in qt4-qtruby "error when installing libqt0-ruby1.8-qt4 and libqt4-ruby at the same time" [Medium,In progress]  https://launchpad.net/bugs/125865
[02:41] <StevenK> Heh
[02:41] <blueCommand> persia, Before I dput, should I trim the control-description on the development package?
[02:42] <ScottK> Note: Status == In Progress in the sense that I tried to figure it and hit a roadblock.
[02:42] <StevenK> ScottK: Okay, what about it confuses you?
[02:42] <ScottK> Trying to figure the proper fix.
[02:42] <persia> blueCommand: It seems a little long to me, but you might want to ask someone else.  I don't want to tell you to undo what I told you to do :)
[02:43] <blueCommand> :D
[02:43] <ScottK> StevenK: I'm assembling a question here.
[02:43] <LucidFox> ScottK, could you review this? http://revu.tauware.de/details.py?upid=6034
[02:43] <StevenK> ScottK: The simplest fix is to add Conflicts. *evil grin*
[02:44] <ScottK> Yeah, but it'd be nice to get it to actually work.
[02:44] <blueCommand> Input here please: http://rafb.net/p/2hMUo772.html Would the "After" be a too long description of a -dev package?
[02:44] <StevenK> In which case, the changes the Debian maintainer made looks to be correct.
[02:46] <blueCommand> persia, Will it block if I don't change it?
[02:46] <ScottK> StevenK: The diversions/renaming?
[02:46] <StevenK> ScottK: Yeah.
[02:46] <ScottK> OK.  I'll go futz with it some more then.
[02:46] <blueCommand> persia, Nvm, stupid question
[02:46] <LucidFox> what's a MIR?
[02:46] <persia> blueCommand: It won't block me, but I cannot speak for others.
[02:46] <StevenK> ScottK: I'm digging up a patch.
[02:46] <blueCommand> I remembered :)
[02:46] <StevenK> LucidFox: Main Inclusion Report
[02:46] <ScottK> LucidFox: Mail In Rebate 
[02:47] <blueCommand> I will just "borrow" a line from another dev
[02:47] <ScottK> StevenK's answer is the Ubuntu specific one.
[02:47] <LucidFox> ah, I see
[02:48] <StevenK> Hrm. I think this reporter tells lies.
[02:49] <StevenK> ScottK: http://patches.ubuntu.com/by-release/atomic/debian/libq/libqt4-ruby/libqt4-ruby_1.4.7-3.patch
[02:49] <ScottK> Fujitsu: I guess you just didn't write an annoying enough bug report (sorry I missed it when I searched if it was reported) - Re Bug 125279
[02:49] <ubotu> Launchpad bug 125279 in soyuz "Publishing an update to *-proposed incorrectly marks bug "Fix Released"" [High,Triaged]  https://launchpad.net/bugs/125279
[02:50] <ScottK> StevenK: Thanks.
[02:51] <StevenK> ScottK: About half of that patch is useless, the relevant bits are the preinst, postrm and rules
[02:51] <imbrandon> anyone with a digg account got a sec ?
[02:51] <imbrandon> http://digg.com/celebrity/Turn_yourself_into_a_real_simpsons_cartoon
[02:51] <imbrandon> :)
[02:51] <ScottK> Right.
[02:51] <imbrandon> please digg if you like it , i need points
[02:51] <imbrandon> lol
[02:54] <LucidFox> ah, and http://revu.tauware.de/details.py?upid=6041 if persia is still here
[02:55] <persia> LucidFox: Again, you'll get a better package if you ask the channel for a review, rather than asking a person.  I'm skipping this one for now (but I'll gladly look at it after someone else does).
[02:55] <LucidFox> I know
[02:56] <LucidFox> as for the notes, I only found 2 redundant debhelper calls: dh_installexamples and dh_installman
[02:57] <blueCommand> Please review: http://revu.tauware.de/details.py?upid=6042
[02:57] <blueCommand> Thanks :)
[03:00] <Jazzva> Does somebody know more about the copying of packages from Debian? If there's a package waiting in Debian's NEW it's gonna be copied to Ubuntu after it gets accepted to Debian, right? Are there any additional steps that need to be done?
[03:00] <marcin_ant> ScottK: it didn't work - unfortunately
[03:00] <xxxxx1> persia, thanks for UP
[03:00] <beuno> Jazzva: not automatically at the moment as in the autosync part of the development cycle has passed, you would have to request it manually
[03:01] <Jazzva> beuno: Ok, and how can I do that? :)
[03:02] <beuno> Jazzva: see https://wiki.ubuntu.com/SyncRequestProcess and maybe https://wiki.ubuntu.com/MOTU/Merging
[03:02] <Jazzva> beuno: Thanks.
[03:02] <beuno> Jazzva, :D
[03:02] <ScottK> marcin_ant: OK.  Well that was my idea.  Sorry it didn't work.
[03:03] <persia> xxxxx1: No problems.  Thanks for contributing :)
[03:06] <elektranox> persia: can you explain me "debian/copyright claims 'Upstream Author(s)' holds copyright: this should be a real person."
[03:08] <blueCommand> If the copyright holders are very many (as they quite often are in OS-projects) should I write something like Freenet Team?
[03:09] <persia> elektranox: You need to actually list the names of the upstream authors in debian/copyright.  Usually this means looking at ./AUTHORS and the headers of all the source code.
[03:10] <elektranox> hm I'm the only one so gar
[03:10] <elektranox> so there is just me
[03:10] <persia> blueCommand: You can do that if and only if upstream refers to themselves that way in some copyright document in the tarball.  Otherwise, you need to list them all.
[03:10] <persia> elektranox: That makes it easy then :)
[03:10] <blueCommand> persia, Woha, this could be "fun" :D
[03:11] <persia> blueCommand: `grep -ri copyright *` is your friend :)
[03:11] <ScottK> For debian/copyright, if people do grep -i -R copyright * in the source tree you'll find where you have to look.
[03:11] <ScottK> Heh.
[03:12] <ScottK> persia: Looks like you got your seconds back.
[03:12] <persia> ScottK: I think I'm three ahead now, but we'll see how long that lasts :)
[03:14] <blueCommand> persia, If the SVN tree was up then I surly could :)
[03:14] <blueCommand> Apparently they use Freenet Project Inc, or contributors for their contributions
[03:14] <persia> blueCommand: Just use your local source (or download the orig.tar.gz from REVU)
[03:14] <persia> blueCommand: That's easy then :)
[03:14] <blueCommand> persia, It's a java app
[03:14] <blueCommand> so it's a heavy jar :)
[03:15] <persia> Ah.  That makes sense :)
[03:15] <blueCommand> No, but it's redistruted in byte-code :)
[03:16] <elektranox> is there a way to avoid this: dpkg-source: cannot represent change to data/gafix.1.gz: binary file contents changed
[03:17] <blueCommand> should it really change? :S
[03:17] <blueCommand> since that means that it changed from orig, should man-pages do that?
[03:17] <elektranox> it's just a gzip -9
[03:17] <persia> elektranox: Does upstream really ship a gzip'd manpage?  Do they not have source that can be regenerated in the build?
[03:18] <elektranox> I put it in gzip form into upstream
[03:18] <persia> blueCommand: Um.  Ubuntu needs source: bytecode needs to be compiled during the build process.
[03:18] <blueCommand> persia, :(
[03:19] <persia> elektranox: Ah.  In that case, the easiest way to fix it is to gzip it in the Makefile upstream, rather than just including it already gzip'd.  That's better for packaging as well.
[03:19] <elektranox> persia: ok
[03:29] <highvoltage> \sh: I knew you'd be back :)
[03:33] <\sh> highvoltage: hehe...just my 2cent :)
[03:34] <Hobbsee> greetings highvoltage, \sh 
[03:34] <Tesl> Hey guys
[03:34] <highvoltage> hey Hobbsee!
[03:34] <Hobbsee> hi Tesl 
[03:36] <xxxxx1> bug #126340
[03:36] <ubotu> Launchpad bug 126340 in ecryptfs-utils "[needs sponsor]  please update ecryptfs-utils" [Undecided,New]  https://launchpad.net/bugs/126340
[03:36] <xxxxx1> can someone take care of it?
[03:38] <persia> blueCommand: 6042 commented.
[03:39] <blueCommand> persia, Will do! Thanks
[03:40] <persia> xxxxx1: There's no need to advertise a bug for sponsorship: subscribing ubuntu-universe-sponsors should be sufficient.  But it's REVU day, so I'll review it :)
[03:40] <proppy> can I still file a sync request for feisty ?
[03:40] <proppy> (for a universe package)
[03:40] <Hobbsee> proppy: no
[03:40] <proppy> this is SRU ?
[03:40] <Hobbsee> if it fits the SRU candidate requirements, yes
[03:40] <Hobbsee> !sru
[03:40] <ubotu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates for main and restricted, while https://wiki.ubuntu.com/MOTU/SRU is for universe and multiverse.
[03:40] <ScottK> proppy: What problem are you trying to solve.
[03:41] <Hobbsee> which usually isnt a full version
[03:41] <xxxxx1> persia, great!
[03:41] <xxxxx1> persia, thank you
[03:41] <proppy> ScottK: python-poker2d python-poker-network python-poker-engine python-poker-eval lib-pokereval are out of sync
[03:41] <proppy> ScottK: we've just publish a new version in debian unstable
[03:42] <proppy> ScottK: i guess i should fill a request for gusty instead
[03:42] <ScottK> proppy: For released versions, we don't change (much like debian stable).
[03:42] <ScottK> Yes.  Sync to Gutsy.
[03:42] <persia> xxxxx1: That's three upstream versions!  Would you mind attaching the diff -urN of the debian/ directories to the bug?
[03:43] <proppy> ScottK: so there is no way that feisty people be able to play with the new client ?
[03:43] <xxxxx1> persia, ah. just ignore the anothers.. the package development is in bzr
[03:43] <persia> proppy: Are more changes planned soon?  It may be just as good to let them be out of sync for a little more, and then grab the even newer version later.
[03:43] <xxxxx1> persia, consider the last
[03:44] <proppy> persia: we are releasing new version at least once a month
[03:44] <gnomefreak> doko: working on java6 for feisty-proposed i ended up with a debdiff of 228.1MB can i just use the update 1 we have in gutsy and version it and build it on feisty and debdiff that or do you really need debdiff from java6 to java6update1
[03:45] <persia> proppy: That's what I thought.  Gutsy UVF is 16th August, so we might get most benefit (and least work for the archive admins) by requesting a sync about a week before that.
[03:45] <ScottK> proppy: Get it into Gutsy and then look into a backports request.
[03:45] <proppy> ScottK: wouldn't be backport more appropriate ?
[03:45] <proppy> ok :)
[03:46] <ScottK> We only backport from Ubuntu repos, so it MUST be in Gutsy first.
[03:46] <proppy> ok
[03:46] <proppy> nice policy
[03:46] <proppy> I've known that before, but I've got like a goldfish memory :)
[03:46] <blueCommand> persia, basically I missed authors and the reference to GPL-2?
[03:46] <crummygummy_> Hi, How do I add an argument to a configure script using pdebuild?
[03:46] <proppy> ScottK: persia: thanks for refreshing my memory
[03:46] <ScottK> Except for StevenK, he backports from URLs that random people throw him.  ;-)
[03:47] <ScottK> StevenK: Thanks again.
[03:47] <Hobbsee> proppy: clearly you've never owned goldfish
[03:47] <StevenK> ScottK: That's the last one, then. :-P
[03:47] <proppy> Hobbsee: :)
[03:47] <blueCommand> crummygummy_, I think you should edit the debian/rules file for that
[03:47] <persia> blueCommand: those, and the separate clauses for the different sources (with a list of affected files for whichever is the smaller list)
[03:47] <proppy> Hobbsee: you managed to made him remember something ?
[03:47] <proppy> actually
[03:47] <blueCommand> persia, Ah ok!
[03:48] <Hobbsee> proppy: ours throw a hissy fit when we leave fish food in the pond, and go away for a week.  they dont come back up to us for another copule of weeks.
[03:48] <crummygummy_> blueCommand, I tried the DEB_CONFIGURE_EXTRA_FLAGS but that didn't work. Do you know which part of the rules file to alter?
[03:48] <Hobbsee> and dont get me started on how they hide at the bottom for like...a month...or longer, if a bird tries to come and attack them
[03:48] <blueCommand> crummygummy_, No idea, but I would guess on configure-stamp
[03:49] <blueCommand> Don't take my word for it
[03:49] <blueCommand> It may be completely inaccurate
[03:49] <crummygummy_> Thanks
[03:50] <proppy> Hobbsee: seems you need to get your goldfish a psychanalyse
[03:51] <blueCommand> persia, Would this do? http://rafb.net/p/rX6Mv052.html
[03:51] <Hobbsee> a what?
[03:52] <StevenK> I'm suspecting he means a psychiatrist.
[03:52] <Hobbsee> proppy: they're perfectly sane goldfish
[03:53] <StevenK> Considering their owner...
[03:53] <blueCommand> :)
[03:53] <StevenK> Ouch. That tickles
[03:54] <persia> blueCommand: Closer, but not quite.  You want to start with the more common package, and specify the licensing inline (see the example, the different ways that Homer and Maggie are credited.
[03:54] <blueCommand> Ah
[03:58] <Tesl> I've a quick question. I've written a little program for helping me learn to read Japanese Kanji, and its pretty nice (150 odd downloads on sourceforge now too). I'm planning on improving it a little more now, but was wondering about packaging it for Ubuntu as well (because I also want to learn how to do it!)
[03:59] <Tesl> Are there any minimum standard guidelines for this for the software itself? Or does somebody need to 'vet' the software as being up to a sufficiently good standard, in terms of bugs and features? (If that makes sense)
[03:59] <zul> !revu
[03:59] <ubotu> REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[03:59] <Tesl> Sounds good =)
[03:59] <Tesl> Thanks
[04:01] <blueCommand> persia, Something like this perhaps then? http://rafb.net/p/iDazgL14.html
[04:01] <persia> Tesl: The only basic guidelines are 1) the licensing is clear and unambiguous, 2) it builds and runs on Ubuntu, 3) at least one person is willing to package it.
[04:01] <Tesl> Hmm, okay :)
[04:02] <Tesl> I'm reading over the packaging documentation now
[04:02] <Tesl> For the first time in ages I've actually got loads of time off work, so thought I could put it to some use! =)
[04:02] <persia> blueCommand: You're almost there.  In this case, Herbert is Maggie, so you don't need the inclusion at the top.  Other than that, it looks OK to me.
[04:02] <persia> (from a brief look, without referring to the source in depth)
[04:03] <blueCommand> Of cource
[04:03] <blueCommand> course*
[04:03] <blueCommand> Good, I will dput it then
[04:08] <Zombie> Hello?
[04:08] <xxxxx1> hi
[04:08] <blueCommand> Please review: http://revu.tauware.de/details.py?upid=6045 Thanks :)
[04:11] <Zombie> I need to ask some packagers to do some backports on some package
[04:12] <Zombie> xl2tpd, freedroidrpg, vavoom, 
[04:12] <Zombie> d2-xl, quakeforge, quake3 or ioquake
[04:14] <ScottK> Zombie: There is a process for that.  See https://wiki.ubuntu.com/BackportRequestProcess
[04:14] <elektranox> persia, can you review http://revu.tauware.de/details.py?upid=6046 again?
[04:16] <persia> elektranox: You'll get a much better response from asking the channel in general, rather than asking a specific person.  I'm looking at something else just now, but if you've not managed to find anyone else interested in your package by the time I'm done, I'll take another look.
[04:20] <Tesl> gah, earthquake
[04:20] <Tesl> =(
[04:20] <Tesl> Those things are always a little scary
[04:21] <Zombie> The issue is some of these applications don't exist in the system yet.
[04:21] <ScottK> Zombie: Are they in Debian?
[04:22] <Zombie> xl2tpd and freedroidrpg are, d2x-xl and vavoom exist only as source Tars are RPMs
[04:22] <Zombie> But they former two are only in Gutsy.
[04:22] <ScottK> If they are in Gutsy, you can ask for a backport.
[04:23] <persia> Tesl: Where are you?
[04:23] <Tesl> Tokyo
[04:23] <Tesl> There was a huge one this morning as well apparently, but I slept right through it
[04:23] <ScottK> For the ones not packaged, you can package them (most likely to happen) or file a needs-packaing bug and pray someone else cares enough to do it.
[04:24] <Zombie> What about the ones that aren't?
[04:30] <blueCommand> Is it possible to use _multiple_ orig packages?
[04:30] <blueCommand> I can make it to a patch, sure, but that feels very bloated
[04:32] <blueCommand> Or would 2 packages be the way to go?
[04:33] <persia> blueCommand: Unless there is an especially good reason, it's best to have a separate package for each separate upstream tarball.
[04:33] <blueCommand> Right
[04:39] <ScottK> Zombie: Did you see my reply to your question that was posted before you asked it?
[04:40] <Zombie> Yes.
[04:40] <Zombie> I haven't formulated my response yet.
[04:40] <Zombie> I'm probably going to have to find a way to port the SRPS
[04:40] <Zombie> I'm probably going to have to find a way to port the SRPMS
[04:42] <ScottK> Zombie: Work from the tarballs and package those.
[04:42] <ScottK> Zombie: People here will help you figure out how to do that.
[04:42] <Zombie> The thing is, xl2tpd was really difficult to make an RPM for.
[04:43] <ScottK> Here we always work from source, so if you want to get it in the repos, you'll need to do that.
[04:44] <StevenK> Please remove tomcat5 from universe. Its not supported anymore upstream
[04:44] <StevenK> and superseded by tomcat5.
[04:45] <Zombie> Do Debs have a concept of a SPEC file?
[04:46] <ScottK> Zombie: Not exactly.  We have a debian directory that has much of the same information.
[04:47] <StevenK> More than, actually.
[04:47] <persia> 5.5 :)
[04:48] <Zombie> See, I'm too unfamiliar with your packaging system.
[04:55] <ScottK> Zombie: The choices are: Dive in and learn or hope/pray as appropriate someone else cares enough about your package to do the work.
[04:56] <Zombie> I figured that was the situation.
[04:56] <Zombie> Nothing ever gets done unless I do it.
[04:56] <ScottK> Isn't that the way the world works.
[04:56] <ScottK> No one else will take care of your problems like you would.
[05:00] <Tesl> And the way it should always stay =)
[05:01] <elektranox> ok ich hab noch ne nderung gemacht. Wer gerade Zeit hat knnte mal http://revu.tauware.de/details.py?upid=6047 reviewen
[05:02] <elektranox> oh foget to translate it ^^ I made another change. Who has time can review http://revu.tauware.de/details.py?upid=6047.
[05:06] <Zombie> Do you folks  do more than just Packaging, like helping advanced Super Users?'
[05:07] <ScottK> As a rule, no.
[05:07] <persia> Zombie: More than just packaging: yes (feature implementation, bug fixes, etc.).  Support: No.
[05:07] <persia> ScottK: There you go :)
[05:07] <Zombie> Well, your flashplayer package doesn't really work.
[05:08] <Zombie> It installs, but FireFox on't register the plugin?
[05:08] <persia> Zombie: There's a bug for that (about 14 hours old, first I saw).
[05:08] <ScottK> There's an update being worked.
[05:14] <blueCommand> Should jar-files reside in /usr/share/package/ or /usr/lib/package/ ?
[05:14] <man-di> blueCommand: /usr/share/java
[05:14] <blueCommand> ah, ok
[05:15] <man-di> blueCommand: or /usr/lib/java for arch:dep jars
[05:15] <blueCommand> Ok
[05:15] <blueCommand> Thanks
[05:15] <man-di> blueCommand: theres an extra (somewhat outdated) policy document for Java packages
[05:16] <blueCommand> man-di, Do you know where?
[05:16] <man-di> http://www.debian.org/doc/packaging-manuals/java-policy/
[05:16] <blueCommand> Thanks
[05:17] <man-di> blueCommand: ping me when you are done with the package. I wil review it. I'm no MOTU but the only person here actively working on the Java stuff
[05:17] <man-di> and also Debian Java Maintainer
[05:18] <blueCommand> man-di, Ah ok
[05:18] <man-di> blueCommand: note some things on the Java policy are not uptodate anymore. I will tell you when I review
[05:41] <ScottK> calc: Interested in an odd OOO bug? Bug #105900
[05:41] <ubotu> Launchpad bug 105900 in openoffice.org "Bold, Italics, and Bold Italics not in English on Fonts menu" [Low,Triaged]  https://launchpad.net/bugs/105900
[05:43] <frafu> Hello, I know how to build a debian package with pbuilder for my i386 architecture. Now I would like to try to build it for another architecture. Do I have to create a new pbuilder as it is the case if one has to build for another distribution release? 
[05:44] <geser> frafu: you need access to that architecture
[05:44] <geser> than you can use pbuilder there as usual
[05:45] <frafu> So it will not be possible on my i386. I can stop searching in that case. 
[05:46] <frafu> geser: thanks
[05:46] <man-di> frafu: it might be possible to run qemu and build inside that
[05:47] <man-di> frafu: but thats a major hassle
[05:51] <frafu> man-dl: ok; as I am new to this, I will probably encounter many problems. Would it also be possible to build for a ppc architecture with qemu on a i386? If I decide to go that route, I should begin with getting familiar with qemu... 
[05:52] <man-di> frafu: should be possible but I have done that
[05:52] <man-di> frafu: I only use qemu to test mips, mipsel and arm
[05:53] <frafu> Are maintainers of a package required to build debian packages for all the different architectures? 
[05:53] <ScottK> No.
[05:54] <ScottK> Maintainers are required to have packages that build on all supported archs, which is slightly different.
[05:54] <frafu> And how can he test it? 
[05:55] <Jazzva> Is there any other way of restricting some specific arch except providing all archs without the problematic one?
[05:55] <Jazzva> in debian/control file...
[05:56] <Jazzva> I looked at man deb-control, but couldn't find the apropriate field...
[05:56] <frafu> ScootK: What can he do to know whether it builds on all supported architectures? 
[05:56] <ScottK> frafu: Usually you don't have to, but if you have arch specific concerns, find someone that has it and beg.
[05:58] <dholbach> can some emacs-savvy person look into the patches on bug 123903, bug 123904 and bug 124967?
[05:58] <ubotu> Launchpad bug 123903 in nxml-mode "Candidate revision nxml-mode_20041004-6ubuntu1" [Undecided,Confirmed]  https://launchpad.net/bugs/123903
[05:58] <ubotu> Launchpad bug 123904 in w3m-el "Candidate revision w3m-el_1.4.4-3ubuntu1" [Wishlist,Confirmed]  https://launchpad.net/bugs/123904
[05:58] <ubotu> Launchpad bug 124967 in sml-mode "Candidate revision sml-mode_4.0-6ubuntu1" [Undecided,Confirmed]  https://launchpad.net/bugs/124967
[05:59] <frafu> ScottK: you say: "Maintainers are required to have packages that build on all supported archs" and afterwards you see "Usually you don't have to". Sorry, but don't get it... 
[05:59] <ScottK> OK.
[05:59] <frafu> ? 
[05:59] <ScottK> First, many packages are arch all, meaning they get built on i386 for installation on all archs.
[05:59] <ScottK> Those are clearly no problem.
[06:00] <man-di> frafu: launchpad knows if your packages doesnt build on some arch
[06:00] <ScottK> For packages with arch specific builds, then if you are careful when you design your package, it should build.
[06:00] <man-di> frafu: you are expected to look at this for packages you are interested in
[06:00] <geser> dholbach: nxml-mode can probably be synced (the debian changelog looks like the summary in the debdiff)
[06:00] <ScottK> Generally, if a package will build on one non-i386 arch it will build on all of them.
[06:01] <dholbach> geser: ah niec
[06:01] <dholbach> nice
[06:02] <man-di> ScottK: do doubt this should be seen as a general rule
[06:02] <man-di> s/do/I/
[06:02] <ScottK> frafu: So far running all i386, I've gotten bit on an arch specific build problem and that was my bad as a packager for not understanding the difference between what I was doing in the arch independent and dependent parts of the build.
[06:02] <ScottK> man-di: Yes.  As I said, Generally.
[06:03] <ScottK> My favorite ones are the ones that build in a pbuilder, but FTBFS on the buildd's.  Those are fun.
[06:03] <man-di> ScottK: like eclipse... :-(
[06:04] <ScottK> Well that wasn't the one I was thinking of, but sure.
[06:04] <man-di> and this is a portable java package
[06:04] <man-di> ScottK: I currently work on eclipse and I'm near to getting a machine gun and running through the city
[06:05] <ScottK> In my case it was: builds in sid pbuilder, builds in gutsy pbuilder, builds on the Debian buildd's, FTBFS on the Ubuntu buildd's.
[06:05] <ScottK> Heh.
[06:07] <man-di> ScottK: in my case:  builds in sid pbuilder, builds in gutsy pbuilder,  doesnt build on Debian builds, doesnt build on Ubuntu buildd
[06:07] <ScottK> At least the buildd's are consistent.
[06:07] <Zombie> freedroidrpg already exists in backports.
[06:07] <Zombie> er
[06:08] <Zombie> freedroidrpg already exists in gutsy.,
[06:08] <Zombie> It needs a backporting.
[06:08] <ScottK> Then you can file a backport request.
[06:09] <man-di> ScottK: well, in my case Build-Dependencies are sligtly different on debian und ubuntu: xul-dev vs. firefox-dev
[06:10] <frafu> Thanks for your explanations. Now I am looking for some documentation about the skills necessary for a maintainer. Is there a difference between a maintainer for universe and for main? 
[06:11] <Tesl> Just wondering, anyone have any idea about how well Dell's Ubuntu offering is going? I remember reading about it a lot not long back, but haven't heard anything recently
[06:11] <ScottK> frafu: Skills no.  But start working on Universe stuff as people here will help you.  When you work on Main stuff, you are expected to know what you are doing.
[06:16] <frafu> Thanks for the informations
[06:17] <olli__> when new wormux updates come ubuntu feisty?
[06:17] <Hobbsee> they wont
[06:17] <Hobbsee> !timebasedreleases
[06:17] <ubotu> Ubuntu releases a new version every 6 months. Each version is supported for 18 months to 5 years. More info at http://www.ubuntu.com/ubuntu/releases & http://wiki.ubuntu.com/TimeBasedReleases
[06:17] <olli__> ok
[06:24] <dholbach> https://bugs.launchpad.net/ubuntu/+bugs?field.status%3Alist=Fix+Committed&field.tag=needs-packaging  is nice and (nearly) empty again
[06:24] <dholbach> yay
[06:25] <ScottK> dholbach: Speaking of which...
[06:25] <dholbach> ScottK: yes? :)
[06:25] <ScottK> I think the thing that bugged me about that one bug I commented on was the debdiff.
[06:26] <dholbach> ScottK: yeah, right - that didn't make much sense
[06:26] <ScottK> I think tracking bugs are great, but that new upstreams out to be reviewed/approved via REVU.
[06:26] <ScottK> out/ought.
[06:26] <dholbach> I think it's fine to have bugs for them, so we can track them via the lists of https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews
[06:27] <dholbach> we have lots of ubuntu*-devs who don't want to sign up for REVU, so if they can just visit a bug I assign them and grab a package from a random URL (fine with me if that's REVU), that's good
[06:27] <ScottK> Right.
[06:28] <ScottK> But then someone needs to archive the upload on REVU.
[06:28] <dholbach> let's hope we figure out something nicely including bzr and/or PPAs
[06:28] <ScottK> We need one and only one place for status.
[06:28] <dholbach> *whine* nobody commented on  bzr unpack  yet
[06:28] <ScottK> Please not bzr.
[06:29] <Hobbsee> dholbach: bzr-buildpackage seems to break, so...
[06:29] <dholbach> Ubuntu specific vcs?
[06:29] <Hobbsee> ScottK: kde packages are going into bzr.  too bad :)
[06:30] <ScottK> Hobbsee: I know.  I'm going to have to learn it at least a little.
[06:30] <dholbach> Hobbsee: that's mostly useful for packages that only debian packaging in bzr
[06:30] <Hobbsee> true
[06:30] <dholbach> see you tomorrow guys
[06:30] <dholbach> have a nice evening/night/day
[06:30] <xxxxx1> dholbach, for you too. bye :)
[06:31] <Hobbsee> bye dholbach!
[06:31] <ScottK> Hobbsee: Plus for KDE, I still have the post a debdiff and bug Hobbsee about it option.
[06:31] <Hobbsee> true
[06:37] <ScottK> And the winner, from earlier today, on clamav is Edgy by a mile.
[06:42] <LucidFox> would anyone here care to review a package that already has one advocating review?
[06:43] <LucidFox> http://revu.tauware.de/details.py?upid=6034
[06:45] <LucidFox> thanks
[06:53] <ScottK> LucidFox: Looks sane.  Building it now.  It's on a slow machine, so it may be a while.
[07:03] <doko> gnomefreak: just make the debian diff available
[07:22] <ScottK> If LucidFox comes back, someone might mention to him that I uploaded videotrans.
[07:32] <tuxmaniac> Is there a how to for the multi distro tools ? I would like to monitor the science, maths and electronics related packages on debian and Ubuntu
[07:33] <geser> there is a wiki page for it
[07:33] <man-di> geser: which is totally outdated...
[07:33] <geser> and the examples
[07:34] <tuxmaniac> geser, yeah you gave me. 
[07:34] <tuxmaniac> geser, examples?
[07:34] <geser> http://tiber.tauware.de/~laserjock/multidistrotools/examples/
[07:35] <geser> should also be in bzr repository
[08:05] <AnAnt> Hello, can someone REVU this upload: http://revu.tauware.de/details.py?upid=6032
[08:23] <man-di> against which package do I have a to file a bug which syncs a new package from Debian?
[08:24] <gpocentek> man-di: file it against ubuntu, without package specified
[08:24] <man-di> okay
[08:27] <rgl> hi
[08:28] <blueCommand> hmm
[08:28] <rgl> are you guys uisng clamav on dapper?   freshclam refuses to update :(
[09:01] <blueCommand> Ant is apparently hardcoded to use com.sun.javah.Main, even though gcj has an alternative. The easiest solution is to add sun-java6-jdk as builddep, but is that allowed?
[09:01] <man-di> blueCommand: no, not allowed
[09:01] <man-di> blueCommand: what is your problem with ant? I dont understand
[09:02] <blueCommand> Well
[09:02] <blueCommand> It says:
[09:02] <blueCommand> BUILD FAILED
[09:02] <blueCommand> /home/bluecommand/Workbench/freenet/real/deb/wrapper-3.2.3/build.xml:429: Can't load javah
[09:02] <blueCommand> And looking at the sourcecode, that error is produced when com.sun.javah.Main isn't found
[09:04] <man-di> blueCommand: can you point me to the correct place in ant source?
[09:04] <blueCommand> 2 sec
[09:04] <blueCommand> ./src/main/org/apache/tools/ant/taskdefs/optional/javah/SunJavah.java line 57
[09:08] <blueCommand> And If I understand it correctly, I need it to be gnu/classpath/tools/javah/Main
[09:09] <blueCommand> gnu.classpath.tools.javah *
[09:10] <man-di> blueCommand: right, but only for GNU Classpath based runtimes
[09:10] <blueCommand> man-di, Yes
[09:10] <man-di> can you please file a bug for this?
[09:11] <blueCommand> Sure
[09:11] <man-di> blueCommand: which software are you packaging?
[09:11] <blueCommand> wrapper, dependency for freenet
[09:11] <man-di> oh, evil freenet
[09:11] <man-di> ;-)
[09:12] <blueCommand> :)
[09:12] <blueCommand> Should I make that bug blocking for freenet ?
[09:13] <man-di> sure
[09:13] <man-di> I will try to fix this asap
[09:15] <man-di> blueCommand: what should work for you for now is building wrapper with sun-java6
[09:15] <man-di> but then it need to go into multiverse instead of universe
[09:15] <blueCommand> Yes, that works
[09:16] <blueCommand> But I don't want that
[09:16] <man-di> and the bug needs to be fixed anyway
[09:16] <blueCommand> I'd rather wait
[09:16] <man-di> okay
[09:16] <blueCommand> https://bugs.launchpad.net/ubuntu/+source/ant/+bug/126410
[09:16] <ubotu> Launchpad bug 126410 in ant "Ant is assuming Sun's JRE" [Undecided,New]  
[09:18] <blueCommand> How do I add blocking :S
[09:18] <blueCommand> brb
[09:18] <man-di> blueCommand: I dont know
[09:21] <sacater> http://wiki.ubuntu.com/Q+ADays
[09:38] <Qball> Seveas around?
[10:28] <ScottK> leonel: Would you please take a look at Bug #126414 and tell me if it's right?
[10:28] <ubotu> Launchpad bug 126414 in squirrelmail "squirrelmail should depend on php-db" [Undecided,New]  https://launchpad.net/bugs/126414
[10:30] <Zombie> I'm home.
[10:32] <Kmos> revu day isn't over yet ?
[10:33] <ScottK> No.  It's still Monday here.
[10:37] <Kmos> :)
[10:39] <leonel> ScottK:  squirrelmail  can  store your adressbook and preferences  in a database ( postgesql  / mysql )   but it's optional to the admin  if you don't configure  your database  squirrelmail uses  plain files  to store  address book and preferences 
[10:39] <Kmos> so the bug must be invalid
[10:40] <ScottK> leonel: THanks.
[10:40] <leonel> ScottK:  so I think  there must not add pear db  as a depencency 
[10:41] <ScottK> Sounds like a Suggests might be appropriate.  Would you please comment in the bug if you haven't?
[10:46] <Kmos> bug 66475
[10:47] <leonel> ScottK:  done
[10:47] <ubotu> Launchpad bug 66475 in idjc "[SRU]  idjc for edgy-proposed" [Low,Fix committed]  https://launchpad.net/bugs/66475
[10:48] <ScottK> leonel: Thanks.  The clamav backports for 0.88.7 got uploaded for Dapper/Edgy today.
[10:48] <Kmos> this one need testing
[10:59] <cbx33> ping doko 
[10:59] <DktrKranz> could you please have a look at http://revu.tauware.de/details.py?upid=6050 ? thank you.
[10:59] <doko> cbx33: pong
[10:59] <cbx33> hi
[10:59] <cbx33> glad I caught you
[11:00] <cbx33> pm ok?
[11:02] <xxxxx1> bye all
[11:03] <ScottK> DktrKranz: Was 5.1.2-1 in any repository anywhere?
[11:04] <DktrKranz> it has recently been readded to gutsy
[11:05] <DktrKranz> you'll find debian version, but it's included in php5 source package, while ubuntu needs to keep it apart since it depends on a package in universe
[11:05] <ScottK> OK.  I see it.
[11:06] <DktrKranz> thanks
[11:07] <ScottK> DktrKranz: Is the 5.1.2-1 a separate source package then?
[11:07] <ScottK> So this is just a new upstream version?
[11:07] <DktrKranz> it is
[11:07] <ScottK> OK.
[11:08] <proppy> emacs22 not in gusty ?
[11:10] <geser> !info emacs22 gutsy
[11:10] <proppy> is the operation of putting a new package that is in debian/unstable and not in ubuntu/current still called a sync ?
[11:11] <ubotu> Package emacs22 does not exist in gutsy
[11:11] <proppy> !info emacs21 gusty
[11:11] <ubotu> emacs21: The GNU Emacs editor. In component main, is optional. Version 21.4a+1-2ubuntu1 (feisty), package size 1976 kB, installed size 5924 kB
[11:11] <geser> yes, that's still a sync
[11:12] <ScottK> proppy: It will be soon.
[11:12] <proppy> ScottK: ok, let me know if I can help :)
[11:13] <proppy> ScottK: (i.e: filling necessary request in required place)
[11:13] <hectorUbu> Hello, I would like to help packing and maintaining some audio and music apps for UbuntuStudio, would it be by joining motu a way of doing it? Some apps really have to be updated
[11:13] <ScottK> IIRC the packages are prepared.  The debate is to sync with Debian or to use an Ubuntu specific version because Debian did some odd stuff with documentation due to DFSG.
[11:13] <proppy> DFSG?
[11:13] <ScottK> Debian Free Software Guidlelines
[11:14] <ScottK> The docs are DFSG non-free.
[11:14] <ScottK> So at this point it's more of a policy question than a do work question.
[11:14] <proppy> emacs-docs are DFSG non-free ?
[11:14] <proppy> sounds weird
[11:14] <ScottK> Yes.
[11:15] <ScottK> DFSG doesn't allow invariant sections.
[11:15] <proppy> invariant ?
[11:15] <ScottK> Not allowed to modify.
[11:15] <proppy> oh ok
[11:15] <ScottK> Documentation licensing is one place where Debian is more pure about Freedom than Gnu.
[11:18] <proppy> interesting to hear :)
[11:19] <Burgundavia> Debian does not believe the CC or the GFDL are free
[11:20] <ScottK> Or put more positively, by Debian's definition they are not Free.
[11:22] <proppy> My freedom is free-er than yours.
[11:24] <vorlon> Burgundavia: CC-by-sa v3 is accepted as free in Debian; though it has some warts that could be interpreted by an upstream in a way that it ought not to be accepted
[11:24] <broonie> ScottK: There are some CC licenses that are free enough for Debian.
[11:24] <ScottK> DktrKranz: Why did you remove the PO/POT files from the previous version.
[11:24] <ScottK> broonie: True enough.
[11:24] <Burgundavia> vorlon: right, ok
[11:24] <proppy> So who is actually allowed to update emacs documentation invariant ?
[11:24] <Burgundavia> vorlon: do you have a filter that highlights on debian? :)
[11:25] <vorlon> nah
[11:25] <vorlon> well, yes; but not a software one
[11:25] <ScottK> proppy: You should download the source and read the license.
[11:25] <ajmitch> probably a general flame filter
[11:26] <DktrKranz> ScottK, debconf template is no longer needed since php5 5.1.6-5, and so .po files
[11:26] <ScottK> OK.  Thanks.  Makes sense.
[11:26] <DktrKranz> this is an adjusted version
[11:26] <DktrKranz> I tried to make it fully compatible with upstream module
[11:27] <proppy> vorlon: let me guess you've got a cat named debian, and text-to-speech 'On' ?
[11:28] <vorlon> proppy: I have a troop of gnomes that read my channels for me, and a troop of kdes that write my responses
[11:30] <proppy> vorlon: but your cat is still named debian right ?
[11:30] <vorlon> nope
[11:30] <ScottK> DktrKranz: Commented.  Technically it looks good to me, but there are licensing issues.
[11:30] <proppy> vorlon: :)
[11:31] <DktrKranz> ScottK, thanks. Since this is an out-of-tree module taken directly from php5 source, what should I do? there's no a "upstream tarball", it's php5 one
[11:32] <DktrKranz> should I include it mentioning in a README.Debian-source?
[11:32] <ScottK> So you are taking the php5 tarball and repacking it to only include part of it, right?
[11:33] <DktrKranz> it is, actually
[11:33] <DktrKranz> i take a directory and debianize it
[11:33] <ScottK> Then follow the rules here: http://www.debian.org/doc/packaging-manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz
[11:34] <ScottK> When you make your new tarball, include a copy of the license from the original tarball.
[11:34] <ScottK> This is a repacked tarball then.
[11:34] <DktrKranz> has php some explicit rules about licensing?
[11:34] <ScottK> This won't technically go through NEW, but if it did, the lack of the license would get you rejected.
[11:35] <ScottK> DktrKranz: They better or we can't distribute it.
[11:35] <DktrKranz> IIRC, debian rejet FAQ mentions somethin
[11:35] <ScottK> Look at the top level of their tarball for a file called COPYING.  That should be what you need to include.
[11:35] <DktrKranz> *reject
[11:35] <DktrKranz> ok, thanks for your help
[11:36] <ScottK> No problem.  The tar.gz MUST have a copy of the license.
[11:36] <ScottK> I've seen pitti require it even when the license was longer than the program.
[11:36] <DktrKranz> yes, I recall a mail from tollef
[11:37] <ScottK> Yep
[11:37] <DktrKranz> do you suggest to document how I repackaged orig tarball?
[11:37] <ScottK> As a result of having the thwacked once, I'm not leaving even a little wiggle room for it to happen again.
[11:37] <ScottK> Yes.
[11:37] <ScottK> You must.
[11:38] <DktrKranz> using README.Debian-Source?
[11:39] <ScottK> The current guidance appears to be to put it in debian/copyright, but you can read the link above as well as I.
[11:40] <DktrKranz> ok, I'm going to look at some uploaded packages to find a working example of good description
[11:40] <ScottK> Gotta run.  See you all later.
[11:45] <elektranox> hey can somebody review http://revu.tauware.de/details.py?upid=6047
[12:00] <Jazzva> Hello... Can I just list the years and names of copyright holders in debian/copyright or do I must also provide the filenames? There are a lot of files and a lot of copyright holders so things are gettin' pretty messy...
[12:02] <leonel> great for clamav
[12:13] <blueCommand> How does submitting packages to multiverse work?
[12:14] <blueCommand> I can't find any references to it on the Wiki or via google
[12:14] <TheMuso> blueCommand: Same as for universe, but when the archive admins see the license, they put it in multiverse, and any subsequent uploads update that package in multiverse.
[12:14] <blueCommand> Ah, nice