[12:19] <marcin_ant> hi all is there someone that could help me with cdbs problem?
[12:20] <TheMuso> marcin_ant: I'm not great with cdbs, but whats your problem?
[12:20] <marcin_ant> TheMuso: problem is quite weird
[12:20] <marcin_ant> TheMuso: I want to prepare some package that has source in *.zip file
[12:20] <superm1> all of the source is?
[12:20] <superm1> or just portions of it
[12:21] <marcin_ant> TheMuso: so I use tarball.mk class to handle this *.zip (unpack to build directory)
[12:22] <marcin_ant> superm1: all of the source
[12:22] <marcin_ant> TheMuso: and it works poperly - problem is that I need to patch source and I wanted to use dpatch
[12:22] <superm1> there is a cdbs patching system
[12:22] <superm1> that you would use instead of dpatch
[12:22] <TheMuso> marcin_ant: Do you have an .orig.tar.gz?
[12:23] <marcin_ant> TheMuso: unfortunately I cannot use dpatch/cdbs-edit-patch because there is no source directory
[12:23] <marcin_ant> TheMuso: no
[12:23] <superm1> you can repackage the contents of the .zip to a more friendly .orig.tar.gz format provided you adhere to the guidelines in the debian reference manual
[12:24] <superm1> there is a bullet in i believe 6.7.8.2 describing what's necessary to do so
[12:24] <superm1> http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz
[12:28] <marcin_ant> superm1: ok but what if source "tarball" is zip?
[12:28] <marcin_ant> superm1: and there is no *.tar archive?
[12:28] <superm1> it would be the same situation, you would unzip it, tar it up and pass that tar through gz
[12:30] <marcin_ant> superm1: ok so this is one option
[12:30] <superm1> another option is to do it with debhelper and still use the zip file
[12:30] <superm1> you can look at thunderbird source package
[12:30] <TheMuso> The archive will not accept anything other than .tar.gz for source.
[12:30] <superm1> for an idea how that is done
[12:30] <marcin_ant> superm1: but what if I don't want to repackage source and still use cdbs tarball.mk?
[12:31] <superm1> it encapsulates the distributed archived in a orig.tar.gz and extracts it during build
[12:31] <superm1> I don't have any experience using tarball.mk myself, so i can't comment much to how it works. all of my cdbs packaging has been simple enough that i haven't had to touch it
[12:32] <marcin_ant> superm1: I may be wrong but I think that it can be bug in cdbs
[12:33] <marcin_ant> superm1: wrong toolchain - you can use tarball.mk to unpack source but you cannot patch it because you don't have unpacked source tree
[12:34] <superm1> right
[12:34] <superm1> marcin_ant, I do think the easiest solution for you will indeed end up be repackaging the original source archive into tar.gz then
[12:35] <marcin_ant> superm1: of course but I would like to identify bug (if any) in cdbs and add it to bugzilla
[12:36] <superm1> marcin_ant, If you can't find any cdbs experts here, you might check out #debian-mentors on oftc.  either which way, you could file a bug, and eventually a cdbs expert will look at it
[12:36] <superm1> and be able to properly classify whether it is or isn't
[12:39] <marcin_ant> superm1: as far as I can see in cdbs source - dpatch.mk cleans build tree while it should also call tarball.mk first
[12:40] <marcin_ant> superm1: anyway I will ask in #debian-mentors (I will try at least.. my allergy on *debian* ehh ;) )
[12:42] <superm1> marcin_ant, From what i look, there are no direct calls to tarball.mk from any file
[12:42] <superm1> in /usr/share/cdbs/1
[12:42] <marcin_ant> superm1: and this is why it doesn't work properly
[12:42] <superm1> right, i think i see what you mean then
[12:43] <superm1> and i would agree you should file a bug regarding this
[12:44] <marcin_ant> superm1: your mozilla-thunderbird example was ok but it doesn't use cdbs so it's another story
[12:44] <superm1> right
[12:45] <superm1> it's the only app i could think of offhand that does something like this without a repacked orig.tar.gz
[12:45] <superm1> wasn't sure if it was cdbs or not
[12:45] <marcin_ant> superm1: eclipse it another but also without cdbs
[12:45] <marcin_ant> eclipse _is_ another
[12:46] <superm1> enyc, huh?
[12:48] <enyc> superm1: somebody wrote to enyc: ages aggo by mistake
[12:51] <superm1> ah
[12:51] <zul> heylo
[01:12] <SlimG> I've created a .deb package of a game with a .desktop file refering to a .svgz icon, where should the .svgz image be stored within the filesystem?
[01:14] <marcin_ant> superm1: sorry to bother you - but could you tell me what should I do to repackage orig properly?
[01:14] <marcin_ant> superm1: zcat eclipse*.zip | tar xf - ? (it doesn't work :( )
[01:15] <twentyafterfour> Is this the right channel for discussion of security bulletins? There is a critical flash update that should be addressed in the multiverse repository but I don't see a ubuntu-security channel or a multiverse channel 
[01:15] <superm1> marcin_ant, unzip eclipse *.zip, then tar the file and gzip it
[01:16] <marcin_ant> superm1: files in tar should be in single directory rught?
[01:16] <superm1> something like unzip eclipse*.zip && tar -xvvf eclipse.tar eclipse/ && gzip -9 eclipse.tar
[01:17] <keescook> twentyafterfour: this is the best place for security discussions, yes.
[01:17] <keescook> there is a bug open for the flash issues, let me find it...
[01:17] <marcin_ant> ok but after unzip eclipse*.zip I got /baseLocation /features /plugins /jdtcoresrc and plenty of files in /
[01:18] <marcin_ant> superm1: so I should move them to eclipse/ and then tar?
[01:18] <twentyafterfour> here is the zdnet bulletin about the adobe flash advisory: http://www.zdnetasia.com/news/security/0,39044215,62028443,00.htm
[01:19] <superm1> marcin_ant, if there is no nested directory within the zip file, i would say put them into a directory
[01:19] <superm1> before tarring
[01:19] <keescook> twentyafterfour: bug #125131
[01:19] <ubotu> Launchpad bug 125131 in flashplugin-nonfree "Need to be updated for new stable version (9,0,48,0)" [Critical,Fix released]  https://launchpad.net/bugs/125131
[01:20] <twentyafterfour> Nice, sorry for bringing old news ;) 
[01:20] <keescook> twentyafterfour: no problem.  :)  you can help with testing, by enabling the feisty-proposed pocket in your sources.list.  :)
[01:20] <twentyafterfour> ok doing that now 
[01:24] <twentyafterfour> keescook: the new flash update didn't show up in feisty-proposed yet ;( at least not according to my synaptic. I'll check out launchpad
[01:26] <twentyafterfour> I'm installing all proposed updates nonetheless, maybe I can help somehow. Should I send positive feedback in launchpad if the packages seem stable or should I only report if I find a problem? 
[01:26] <keescook> twentyafterfour: right, it will appear there in a bit, it's only in -proposed so far.
[01:26] <keescook> er
[01:26] <keescook> sorry, I misread
[01:26] <twentyafterfour> update manager just gave me 12 updates but no flash. maybe I installed flash manually but I am pretty sure I have it from the repo.
[01:28] <keescook> twentyafterfour: I see it:  flashplugin-nonfree | 9.0.48.0.0ubuntu1~7.04.0 | feisty-proposed/multiverse
[01:28] <twentyafterfour> ok I must have something set up wrong. thanks for the help, I'm sure I can find it
[01:30] <twentyafterfour> ok found it 
[01:31] <twentyafterfour> keescook: thanks again . . . I will report to launchpad if I find any problems
[01:31] <keescook> okay, cool.
[01:32] <eagles0513875> im working on debugging my own problem with kde 3.5.7 and amarok with audio cutting in and out intermittently throughout any audio
[01:32] <eagles0513875> my audio is encoded in flac
[01:33] <eagles0513875> tried reinstalling amarok and flac from source with no change so i will download the xine source and take a look through there
[01:34] <eagles0513875> where can one get the xine source from
[01:34] <TheMuso> eagles0513875: apt-get source xine
[01:34] <eagles0513875> tried that 
[01:34] <TheMuso> However I think you're going about it the wrong way.
[01:34] <eagles0513875> didnt work
[01:34] <eagles0513875> ive already reported it as a bug to kde
[01:34] <eagles0513875> whats ur take on things
[01:34] <twentyafterfour> Is amarok the only audio program that skips? 
[01:34] <TheMuso> Have you checked CPU load while music is playing?
[01:35] <eagles0513875> ya not using much
[01:35] <twentyafterfour> I have a similar problem with audacity for some reason 
[01:35] <twentyafterfour> but I just avoid using it as a player
[01:35] <eagles0513875> ya it is the only player that skips
[01:35] <TheMuso> Is the music being played from a local hard disk, or over the network?
[01:35] <eagles0513875> i love amarok i hate the alternate which im using atm
[01:35] <eagles0513875> local hdd
[01:35] <twentyafterfour> I play audio from a remote server via amarok all the time, flac, mp3, wav, whatever, it doesn't seem to have any trouble 
[01:36] <TheMuso> How is that hdd connected?
[01:36] <eagles0513875> im running gutsy though
[01:36] <TheMuso> SATA/IDE?
[01:36] <eagles0513875> its ide internal 5400 rpm
[01:36] <eagles0513875> never had the problem like this in feisty
[01:36] <TheMuso> Well, there are bound to be problems then.
[01:36] <twentyafterfour> even usb 1.1 should have enough bandwidth 
[01:36] <eagles0513875> and im running the 64bit version of gutsy
[01:36] <twentyafterfour> oh now you are over my head ;) 
[01:36] <TheMuso> eagles0513875: Well all you can do is wait and work with the kde guys to fix it.
[01:37] <eagles0513875> should i try and take a look at xine code and see if i notice anything
[01:37] <twentyafterfour> if you are hardcore enough to analyze source, by all means ;) 
[01:38] <TheMuso> eagles0513875: If you want to, I think the amarok devs will have a etter idea of how to get you to help them debug the problem.
[01:38] <TheMuso> better even
[01:38] <eagles0513875> true
[01:38] <eagles0513875> im not able to find the source though
[01:39] <TheMuso> eagles0513875: apt-get source xine-lib
[01:39] <eagles0513875> ok ty
[01:40] <TheMuso> np
[01:41] <eagles0513875> r there any other pkgs that i should take a look at
[01:42] <TheMuso> Well have a look at amarok's dependencies.
[01:42] <eagles0513875> i was goign to download the amarok-xine source
[01:43] <TheMuso> I'd say its more likely a problem with amarok itself, u nless there are reports of xine problems from other users who use xine as a backend for their player.
[01:54] <owh> Hiya, what diff command do I use to create a patch to submit to LP?
[01:54] <owh> Alternatively, where is the RTFM for this?
[01:59] <Jazzva> owh: Try with this one: http://doc.ubuntu.com/ubuntu/packagingguide/C/ps-scratch.html
[02:00] <TheMuso> owh: If you have made a new package revision, including changelog, you can use the debdiff command to show the difference between the two packages. Otherwise, the diff -urN command will  do what you want, between two files, or directories with files, i.e two copies of surce, with one of thos containing the changes.
[02:00] <owh> It's a patch to the man pages - all manner of spelling errors.
[02:03] <TheMuso> owh: Right. Do you have a copy of the original files, and a copy with your changes? If so, are they both in different directories
[02:04] <owh> Yup, I have just been in the process of doing that :-)
[02:04] <TheMuso> owh: Ok, use "diff -urN dir1 dir2 > filename.diff" to create the diff.
[02:05] <owh> Can I just specify the files, rather than the whole directory?
[02:06] <TheMuso> owh: How many files did you modify?
[02:06] <owh> Just one, but the tree isn't synched and I don't want to break other things I'm working on, long story.
[02:06] <TheMuso> owh: Ok, if its just one, all you need to do is this: "diff -u file1 file2 > filename.diff"
[02:06] <TheMuso> Hope that makes sens.
[02:07] <TheMuso> sense even
[02:07] <owh> Cool, I wasn't sure that I was allowed to, but yes, it makes perfect sense :)
[02:07] <owh> BRB
[02:08] <owh> TheMuso: Was it on purpose that you changed the diff flag from -urN to -u or was that an error?
[02:09] <TheMuso> owh: No, that was on purpose. THe rN flags tell diff to consider any newly created files that are in one copy and not the other, and r tell it to look recursively through directories.
[02:09] <owh> Cool
[02:10] <TheMuso> Oh by the way, with the command, you put the original file first, and then the modified file second. So "diff -u original modified > filename.diff"
[02:10] <owh> Yeah, old new
[02:10] <TheMuso> yep
[02:10] <owh> And is there a preferred file name for the diff file?
[02:10] <TheMuso> nope
[02:11] <owh> Cool, so now I have one, how do I check that I got it right?
[02:12] <TheMuso> owh: Yes. YOu can see if it works, but not actually modify the file by using patch --dry-run
[02:14] <owh> Cool, so I have a verified patch file, can I just upload it to LP?
[02:17] <TheMuso> owh: Attach it to the bug, and then passon the bug number.
[02:19] <owh> TheMuso: Bug #126121
[02:19] <ubotu> Launchpad bug 126121 in dosfstools "Typo in mkdosfs man page" [Undecided,In progress]  https://launchpad.net/bugs/126121
[02:19] <TheMuso> owh: Is this for feisty or gutsy?
[02:19] <owh> Yes :)
[02:19] <TheMuso> owh: Yes as in what?
[02:19] <owh> Sorry, AFAIK, the version is the same for both.
[02:20] <owh> It's not mission critical.
[02:20] <TheMuso> oh ok.
[02:20] <TheMuso> Do you know if this has been fixed in Debian?
[02:21] <TheMuso> And maybe this is worth pushing upstream as well.
[02:21] <owh> I seriously doubt it, at the moment I appear to be the only one doing anything to dosfstools (with assistance from sistpoty when he has time).
[02:21] <TheMuso> Oh ok.
[02:21] <owh> Debian upstream has not responded in months to any reports.
[02:22] <TheMuso> owh: Do you mean Debian or upstream?
[02:22] <owh> Both.
[02:22] <owh> The package is pretty unloved. Debian appears to be the same as upstream, Roman Hodeck is part of Debian and appears as upstream for the package.
[02:22] <TheMuso> Right.
[02:23] <TheMuso> Well gutsy has a different version to feisty.
[02:23] <owh> I figure if it looks like someone cares, I might get better responses to requests for bug clarifications.
[02:23] <owh> Hmm, lemmie look.
[02:24] <Zombie> Gutsy isn't stable/release yet, is it?
[02:24] <TheMuso> Not that it really matters, I'll just update for gutsy at this point, as that would not be considered worth updating for feisty.
[02:24] <TheMuso> Zombie: Gutsy is the development version, and you choose to run it at your own risk. If it breaks, you get to keep both pieces.
[02:25] <Zombie> Didn't htink so.
[02:25] <owh> TheMuso: I'm trying to see the difference between the Gusty and Feisty versions, but I cannot seem to locate the link to the Feisty one.
[02:26] <TheMuso> owh: Hav a look here: http://launchpad.net/distros/ubuntu/+source/dosfstools
[02:26] <owh> NM, just found it.
[02:26] <owh> :)
[02:26] <TheMuso> owh: And at this point, I can't touch this package, as its in main.
[02:27] <owh> How can I see the diff between the two versions - which both appear to come from upstream 2.11
[02:28] <TheMuso> owh: YOu'll have to grab both source packages, and use debdiff to compare them
[02:28] <owh> Cool, just in the progress of downloading. Tah.
[02:34] <owh> That version fixes the same bug we fixed - Debian used our patch to do it :)
[02:34] <TheMuso> right
[02:35] <owh> So how does my patch actually get used?
[02:35] <owh> At the moment, Debian are duplicating the effort.
[02:36] <TheMuso> It will be encorporated into a new revision of the package, and uploaded, mentioning the patch in the changelog.
[02:36] <TheMuso> This is why I suggest its good to try and get it into Debian, as its less work for Ubuntu in the future.
[02:37] <owh> And the version they used was not the one they released 2.11 with. They used a different source :(
[02:37] <owh> It is littered with CVS crap.
[02:38] <owh> Can I set the status to fix released, or is that for someone else to do?
[02:43] <TheMuso> owh: Better for someone who intends to take that bug further to change the status I'd say.
[02:43] <owh> I don't understand.
[02:43] <TheMuso> owh: No, I'd leave it as is.
[02:44] <owh> How can the bug be taken further?
[02:44] <owh> The fix is valid for all versions of the 2.11 branch.
[02:44] <TheMuso> Well is there a bug filed about it in Debian?
[02:44] <owh> How does it become incorporated?
[02:45] <owh> Well, I figure we start with fixing it here, then we'll work on the Debian side. They've not been the most responsive.
[02:46] <TheMuso> Ok. Lets work on actually making a package revision. First, I need to know whether you are running, or have access to a gutsy system.
[02:46] <owh> No
[02:46] <owh> How much disk space would I need?
[02:47] <TheMuso> Ok, never mind then.
[02:47] <owh> TheMuso: The gusty file and the feisty file and the edgy file and the dapper file are the same file.
[02:47] <TheMuso> If you really think this is not going to easily make it into Debian, and you think its important enough, I'll make a package revision.
[02:48] <TheMuso> And get it sponsored.
[02:48] <owh> I'm not trying to make work for you, I'm trying to understand the steps/
[02:49] <TheMuso> owh: Ok. At this point though, you would need to have some sort of access to gutsy, as t requires using its tools to build and test the package, with the included modification.
[02:49] <owh> So, just submitting the patch isn't enough?
[02:49] <TheMuso> A patch is good, but if a package revision is available, its more likely to be uploaded, as there is less work.
[02:50] <TheMuso> owh: Yes it is enough, but if you really think it should go in, and want it to go in sooner, getting it sponsored for upload will bring it to someone's attention.
[02:50] <TheMuso> Hey RAOF 
[02:50] <owh> When sistpoty and I fixed the 4Gb and rename bugs, the only steps I saw was a patch and an acceptance.
[02:50] <TheMuso> An acceptance in what way?
[02:51] <TheMuso> I hope I'm making sense.
[02:51] <owh> TheMuso: I saw the patch being submitted and within 15 minutes some processing was done and a new package existed.
[02:51] <TheMuso> Right.
[02:51] <TheMuso> Well I'm about to do something similar.
[02:51] <owh> So, you're saying that sistpoty did this in the background?
[02:52] <TheMuso> Yes.
[02:52] <owh> Aha
[02:52] <TheMuso> Got a bug number
[02:52] <TheMuso> So I can see what happened?
[02:52] <owh> Bug #126121
[02:52] <ubotu> Launchpad bug 126121 in dosfstools "Typo in mkdosfs man page" [Undecided,In progress]  https://launchpad.net/bugs/126121
[02:52] <owh> Or you mean the one that we fixed earlier?
[02:53] <TheMuso> The one you fixed earlier.
[02:53] <RAOF> Hey TheMuso :)
[02:53] <quenelle> I have a question about the way the latest TWiki package is packaged.  The package info says it's done by the MOTU group.  Is there someplace I can file a bug or RFE?  I think one of the 'lib' directories needs to be shifted into the /var tree.
[02:53] <owh> Bug #62831
[02:53] <ubotu> Launchpad bug 62831 in dosfstools "fsck.vfat truncates files of 4294967295 bytes length to 0 bytes at boot-time" [High,Fix released]  https://launchpad.net/bugs/62831
[02:53] <RAOF> quenelle: Launchpad
[02:53] <quenelle> cool, I'll check it out.
[02:53] <owh> And Bug #68153
[02:53] <ubotu> Launchpad bug 68153 in dosfstools "fsck.vfat hangs after renaming to FSCK9999.REN" [Medium,Fix released]  https://launchpad.net/bugs/68153
[02:54] <RAOF> quenelle: Is where you can file a bug :)
[02:54] <dabaR> Hi, I have a bug that is a duplicate,https://bugs.launchpad.net/ubuntu/+source/bootcd/+bug/122121
[02:54] <ubotu> Launchpad bug 122121 in bootcd "bootcdwrite fails with a syntax error" [Undecided,New]  
[02:54] <dabaR>  How do I mark as duplicate?
[02:54] <dabaR> nm, I found itL:(
[02:54] <RAOF> dabaR: Probably best in #ubuntu-bugs, but there's a... :)
[02:57] <owh> TheMuso: I just figured out that I need to nominate it for release. I've just selected Feisty and Gutsy, not Dapper or Edgy, even though it would work fine.
[02:57] <TheMuso> owh: No need to worry about that.
[02:58] <Amaranth> hrm
[02:58] <Amaranth> what's the standard naming for a debdiff?
[02:58] <Amaranth> i haven't made one in awhile :)
[02:58] <dabaR> https://bugs.launchpad.net/ubuntu/+source/bootcd/+bug/96365 . I have looked into the reason for this, and I can see that it is because debian officially supports more arch's.
[02:58] <ubotu> Launchpad bug 96365 in bootcd "[UNMETDEPS]  bootcd has unmet dependencies" [Undecided,Confirmed]  
[02:59] <dabaR> In fact,  all the deps can be met through the ports of ubuntu.
[02:59] <TheMuso> Amaranth: I don't think it really matters.
[02:59] <dabaR> http://ports.ubuntu.com/
[02:59] <TheMuso> I've seen lots of conventions used.
[02:59] <Amaranth> TheMuso: suggest one :0
[02:59] <Amaranth> err, :)
[03:00] <Amaranth> because it's called 'whee.debdiff' right now
[03:00] <TheMuso> Amaranth: packagename_oldver_newver.debdiff?
[03:00] <TheMuso> Thats one I tend to use.
[03:00] <dabaR> ya.
[03:00] <dabaR> I've seen that recommended by crimsun
[03:00] <Amaranth> so gnome-session_2.19.5-0ubuntu2_2.19.5-0ubuntu3.debdiff?
[03:01] <dabaR> Looks good.
[03:01] <Amaranth> i think i'm going to use gnome-session_2.19.5-0ubuntu2-3.debdiff :)
[03:02] <dabaR> looks even better
[03:02] <dabaR> Now the package maintained for bootcd is involved with debian development, asnd so it is clear as to why he will not change the package upstream, where this issue never happens. Can someone advise on what to do for Ubuntu?
[03:13] <SlimG> I've created a .deb package of a game with a .desktop file refering to a .svgz icon, where should the .svgz image be stored within the filesystem?
[03:13] <Jazzva> Umm, I have a question about debian/copyright. The source is a bit messed up with licenses and copyright holders - the file that was supposed to contain all licenses and copyright information doesn't contain all of it. Then I tried using "grep -i -R copyright *" and "grep -i -R license *"  to find some information and I finished up with two text files full of text. Because it would be a whole lot of mess to write specific filename
[03:13] <Jazzva> bla1/". Is that ok?
[03:14] <Jazzva> *two text files full of names and licenses
[03:15] <Jazzva> And if all files in some directory fall under one license I just put "bla/bla1/"
[03:15] <TheMuso> Jazzva: All copyright holders have to be listed in debian/copyright.
[03:15] <ScottK> twentyafterfour: All of those packages you installed from feisty-proposed has a corresponding bug in Launchpad asking for people to test it.  Please look them up and see what needs to be tested.  That will be a big service to the community.
[03:16] <TheMuso> I am no copyright expert, so I don't feel I can confidently help you going further.
[03:16] <Jazzva> TheMuso: They are... But I didn't listed specific filenames... An example...
[03:16] <RAOF> Jazzva: If there are multiple licences/authors, debian/copyright should say that.  If all the files in a directory have the same author/copyright, listing /foo/bar should be ok
[03:16] <twentyafterfour> ScottK: Thanks. 
[03:17] <Jazzva> RAOF: Ok, but do I need to provide full filenames or would something like this (an example comes :)) be sufficient?
[03:17] <Jazzva> Insted of:
[03:17] <ScottK> twentyafterfour: No problem.  Getting verification that the fix works is what gets the packages out of -proposed and released to -updates for everyone.
[03:17] <Jazzva> bla/bla1/filename1, bla/bla1/filename2: Copyright holder
[03:17] <Jazzva> Can I write:
[03:18] <Jazzva> Some files in bla/bla1/: Copyright holder
[03:18] <Jazzva> ?
[03:19] <RAOF> Jazzva: I'm not sure :).  Maybe it's time to consult debian policy?
[03:20] <Jazzva> RAOF: Maybe :)...
[03:21] <porthose> jazzva:  src/bla/bla1 is copyright 2007 <authors name>
[03:21] <porthose>  jazzva:  src/bla/bla1 is copyright 2007 authors name
[03:22] <porthose> jazzva:  All files in src/bla/bla1 is copyright 2007 authors name
[03:22] <Jazzva> porthose: Thanks... But I'm still interested if I can provide "some files in bla/bla1/" instead of "bla/bla1/lala, bla/bla1/tata, ..." :).
[03:23] <ScottK> Jazzva: No you can't.
[03:23] <Jazzva> ScottK: Ok, thanks.
[03:24] <ScottK> The idea is that you have to be able to tell from debian/copyright who has copyright on any individual file.  What porthose told you does that.
[03:24] <owh> TheMuso: Thank you.
[03:25] <SlimG> I've created a .deb package of a game with a .desktop file refering to a .svgz icon, where should the .svgz image be stored within the filesystem?
[03:27] <TheMuso> owh: No problem.
[03:28] <RAOF> SlimG: Probably somewhere under /usr/share/icons/.../scalable, but the install process doesn't put it somewhere already?
[03:30] <SlimG> RAOF, I've put the icon into /usr/share/icons/hicolor/scalable/apps/<game>.svgz , but this has been reported to not work on atleast one system, i dunno what DE that user was running thou, worksforme@kubuntu7.04
[03:31] <RAOF> SlimG: Aaah.  Are you calling dh_iconcache?  (Or, I think, dh_icons replaces it)
[03:32] <ScottK> Anyone want a packaging bug they can work on?
[03:33] <ScottK> Bug #126431 is probably not to hard if you want to excercise your packaging related skills.
[03:33] <ubotu> Launchpad bug 126431 in dspam "dspam-webfrontend fails to install: dpkg-statoverride: non-existing user dspam" [Medium,Confirmed]  https://launchpad.net/bugs/126431
[03:33] <ScottK> asac: Ping.  Did you see my comment on the Thunderbird 2.0 backport bug?
[03:33] <SlimG> RAOF: I'm not calling anything, just putting the icon into the path I mentioned, Am I doing something wrong?
[03:36] <StevenK> RAOF: Right. dh_icons does replace it.
[03:36] <TheMuso> /c
[03:37] <RAOF> SlimG: Yes.  Gnome (well, GTK actually) uses a cache for the icons.  If you don't regenerate that cache when you install the icons, GTK won't know about them.
[03:38] <RAOF> dh_icons adds the necessary postinst magic to regenerate the cache
[03:40] <SlimG> RAOF: Does gnome regenerate cache on boot?
[03:40] <RAOF> SlimG: No, I don't believe so.  Although it may...
[03:43] <RAOF> Yes!  Conduit has made it out of WNPP.  Time to search for sync bugs!
[03:44] <TheMuso> gah my switches are dying for unknown reasons.
[03:46] <RAOF> We need to file sync bugs for packages that are new in debian now, right?
[03:47] <ajmitch> I believe so
[03:48] <RAOF> Cool.  Another thing to be put off until one of my Ubuntu boxes has internet.
[03:50] <ajmitch> RAOF: you can file sync requests just fine with just a web browser
[03:50] <ajmitch> we managed, back in the day
[03:51] <RAOF> ajmitch: I'd like to check that it actually builds in Gutsy first :P
[03:52] <ajmitch> nothing stopping you from doing that :)
[03:52] <SlimG> RAOF: will the Gnome iconcache regeneration be automated sometime in the future? or do all packages containing icons need to have a postinstall script workaround for gnome?
[03:53] <RAOF> Apart from the lack of internet on any of my Gutsy boxes.  Anyone else is welcome to try to build conduit from Debian source.
[03:54] <RAOF> SlimG: I don't believe so.  Anyway, s/workaround/by design/.  Your package should be calling dh_icons.
[03:57] <ScottK> RAOF: Doesn't conduit need evolution-python?
[03:58] <RAOF> ScottK: Yes.  That's been sync'd though, hasn't it?
[03:59] <ScottK> It got rejected the first time for licensing.
[03:59] <ScottK> I just asked again this morning.
[03:59] <ScottK> It'll have to go through NEW first.
[03:59] <RAOF> Bah.  But it's in debian.  Naughty debian
[04:00] <ScottK> In their (slight) defense, it's in experimental, not unstable.
[04:01] <RAOF> Ok.
[04:01] <SlimG> RAOF: Since packages needs to call dh_icons solely when installed in Gnome afaik, I'd call this a workaround. Couldn't Gnome detect changes in /usr/share/icons and call dh_icons itself? or the apt manager could call dh_icons when it sees icons going into /usr/share/icons ?
[04:02] <StevenK> RAOF, ScottK: They're still distributing it, which is naughty.
[04:02] <RAOF> SlimG: No.  If you install icons, you should call dh_icons.  Regardless of Gnome/KDE.  At some point, KDE will grow an icon cache :)
[04:02] <ScottK> StevenK: Agreed.  That's why I said slight.
[04:03] <ScottK> Brand new clamav-0.91.1 uploaded.  Good chance to find out if the upgrade bugs are really fixed ...
[04:21] <ScottK> OK.  I've met my quota and filed my annoying launchpad bug for today.
[04:22] <RAOF> :)
[04:29] <leonel> ScottK: 91.1  in gutsy ?   
[04:29] <ScottK> Yes
[04:29] <leonel> ScottK: builded  fine  in Dapper using  your  90.3  sources
[04:29] <ScottK> OK.
[04:29] <ScottK> I'm waiting a bit to make sure 91.whatever is stable before I update my test packages.
[04:30] <ScottK> But I will.
[04:30] <leonel> filed a cve  for feisty's clamav   and made a debdiff  
[04:30] <ScottK> Really?
[04:31] <ScottK> I didn't notice a CVE listed in their changelog.
[04:31] <ScottK> Cool.  I'm glad your on it.
[04:31] <leonel> bug 126741
[04:31] <leonel> bug #126741
[04:31] <ScottK> The bot is slow tonight.
[04:31] <leonel> yes  I saw  all of you feed it  a lot :0
[04:32] <ScottK> leonel: Did you mark the bug private?
[04:32] <ScottK> Or rather, not mark it unprivate?
[04:33] <leonel> should I make  visible ?
[04:33] <leonel> I think I missed that ..
[04:33] <leonel> ScottK: should  I make it visible ?
[04:34] <ScottK> If there is a published CVE, there is no reason not to.
[04:34] <ScottK> There is no need to keep stuff that's not a secret, a secret.
[04:34] <leonel> done
[04:34] <ScottK> OK.
[04:34] <ScottK> That's also probably why the bot never responded.
[04:35] <leonel> done with the  diff
[04:35] <leonel> bug #126741
[04:35] <leonel> :)
[04:35] <leonel> well there it is
[04:36] <leonel> Bug #126471
[04:36] <ubotu> Launchpad bug 126471 in clamav "unrar.c  Remote DoS in clamav before 0.91" [Undecided,New]  https://launchpad.net/bugs/126471
[04:36] <leonel> wrong  number  
[04:36] <leonel> sorry
[04:38] <ajmitch> 'urgent' bugs reported on the forums, no indication that they got to launchpad
[04:39] <ScottK> leonel: How is the change in clamav-0.90.2/libclamav/unrar/unrar.c related to the vulnerability?
[04:39] <LucidFox> how long does it take for a package that passed REVU to appear in Ubuntu proper?
[04:40] <ScottK> LucidFox: It goes to the NEW queue and waits manual review by the archive admins.  I've seen one day to one month depending on their backlog.
[04:40] <LucidFox> Ah.
[04:42] <superm1_> LucidFox, it actually has to be ack'ed for new source by archive admins and then new binaries too, so it can sometimes be very lengthy process
[04:44] <leonel> ScottK:  it's  2 line chages  
[04:48] <LucidFox> What happens when a library is updated? All packages that depend on it will have to be rebuilt, right?
[04:51] <RAOF> If there's an ABI change
[04:53] <ScottK> leonel: But doesn't clamav-0.90.2/libclamav/unrar/unrar.c just change a string that's displayed?  For a security bug it should be the minimal fix.
[04:53] <ScottK> The real change is in the other file.
[04:59] <leonel> ScottK:  right
[05:00] <ScottK> I'd suggest you redo the patch/debdiff/test, etc.  If not, it'll be more for keescook to deal with.
[05:03] <leonel> redo ? what you suggest to change ?
[05:07] <leonel> ScottK:   what  do you suggest to change ?
[05:08] <ScottK> Remove the changes in clamav-0.90.2/libclamav/unrar/unrar.c and just change clamav-0.90.2~/libclamav/unrar/unrarvm.c.
[05:09] <leonel> ok
[05:10] <LucidFox> can dpatches be used with the regular patch utility?
[05:13] <RAOF> I believe so, yes
[05:18] <ScottK> Good night all.
[05:19] <RAOF> Good night, ScottK 
[08:06] <dholbach> good morning
[08:06] <xtknight> can anyone link me to the page where it describes how to diff a deb source pkg?  i'd like to correct a very simple bug ( bug 126490 )
[08:06] <ubotu> Launchpad bug 126490 in freetennis "freetennis manual page lists an incorrect URL" [Undecided,New]  https://launchpad.net/bugs/126490
[08:07] <persia> xtknight: https:/wiki.ubuntu.com/MOTU/Contributing as a couple examples
[08:07] <xtknight> persia,  ahh thanks.
[08:08] <persia> xtknight: You probably want something either like `diff -urN dir1 dir2` or `debdiff rev1.dsc rev2.dsc`
[08:08] <xtknight> ya i remember doing the debdiff dsc one
[08:17] <xtknight> hmm why do some instructions show "debuild -S" and others "debuild -us -uc"?
[08:17] <xtknight> which should i be using?
[08:18] <TheMuso> xtknight: WHich ones say to use -S and which say -uc -us?
[08:20] <xtknight> TheMuso, ok, here it says "debuild -S" https://wiki.ubuntu.com/MOTU/Contributing ("Prepare a source build with").  but here (Bugs\HowToFix) says "debuild -us -uc" under generating a patch..
[08:21] <RAOF> There should almost always be a "-S" in there; you don't want to actually build binaries in either case.
[08:21] <xtknight> it looks like -S signs something with gpg?
[08:21] <persia> xtknight: That's somewhat intentional.  debuild -S is used to build a signed source revision, whereas debuild -us -uc is to locally build binaries (unsigned, without changes), which is useful for testing a small patch.
[08:21] <TheMuso> xtknight: Well -S  is to sign the built package, which you need to do if you are uploading to the archive, or REVU for example, whereas -uc -us ensures that the package doesn't get signed, which is pointless if you are making a debdiff.
[08:21] <TheMuso> ah sorry -S is source.
[08:21] <RAOF> :)
[08:22] <elektranox> can somebody review http://revu.tauware.de/details.py?upid=6047 ?
[08:22] <persia> RAOF: Actually, for the simple patch case (Bugs/HowToFix), users are encouraged to test with a local build (pbuilder or sbuild being considered too difficult to set up for something simple)
[08:22] <RAOF> persia: Fair enough
[08:22] <persia> TheMuso: -uc -us is good for a local build, upon which a debdiff may be based, but the results are not always optimal.
[08:23] <TheMuso> persia: Right.
[08:23] <TheMuso> How are they not always optimal
[08:23] <xtknight> so -us -uc is a dirty test run, and -S is what i should upload?  
[08:23] <persia> xtknight: Right.
[08:24] <persia> TheMuso: 1) there's no signature, so no verification of the last changelog entry (-k is a dirty hack, in my book), 2) it's a local build, so there's not a proper dependencies check, 3) it's a local build, so there's no verification that the APIs match the archive
[08:24] <TheMuso> Right.
[08:25] <persia> xtknight: If you're willing to set up a sbuild or pbuilder environment, and test-build the result of debuild -S prior to upload, that's even better (and expected practice for those becoming MOTU)
[08:26] <xtknight> persia, ahh.  well eventually perhaps.  for now i'd just like to upload a quick fix for this.  i already have fixed one package but i pretty much forgot everything since, lol
[08:27] <persia> xtknight: For a quick fix, debuild -us -uc might be better, as it does some checking to make sure your adjustment doesn't break the build.  debuild -S only builds a source, but doesn't test compilation.
[08:32] <xtknight> at the top of the erroneous man file ("freetennis.8") i see ".TH FREETENNIS 8 "June 16, 2006""  what is this date supposed to be?  the Last Modified?
[08:32] <xtknight> it should be updated in my patch also?
[08:40] <persia> xtknight: According to http://www.linuxjournal.com/article/1158 (not an authoritative source), Yes: the date should be updated for each revision to the manpage.
[08:40] <xtknight> persia,  i was about to just leave it as it's not like it's a major change or anything.  iwas thinking that was for last update to the program's source code..
[08:41] <persia> xtknight: According to linuxjournal, it's the last date of the manpage.  I'm not finding any Ubuntu- or Debian- specific guidance.
[08:41] <xtknight> persia, ah ok thanks for the link
[08:42] <minghua> I think it's fine either way.
[08:42] <minghua> I suspect most dates in Debian/Ubuntu manpages are wildly inaccurate anyway.
[08:42] <LucidFox> http://packages.qa.debian.org/m/mediawiki1.10.html
[08:43] <LucidFox> ^ could this be synced in the near future?
[08:43] <persia> Just because everything else is wildly inaccurate isn't really an excuse for new things to also be wildly inaccurate :)
[08:43] <LucidFox> and if so, which version?
[08:44] <persia> LucidFox: I think I saw an upgrade bug about mediawiki recently: was there not a specific version recommendation there?
[08:44] <persia> LucidFox: Also, regarding bug 124900, were you going to prepare a new candidate revision for gtkpod-aac?  Everything else is now done.
[08:44] <ubotu> Launchpad bug 124900 in libgpod "Please sync gtkpod-0.99.10, libgpod-0.5.2 from debian unstable" [Wishlist,Fix released]  https://launchpad.net/bugs/124900
[08:45] <LucidFox> persia> I'll look into it, thanks
[08:46] <minghua> persia: Playing devil's advocate, I would argue on the base of not giving users the false sense of having accurate dates at all. :-P
[08:46] <LucidFox> as for MediaWiki, there is bug #120324
[08:46] <ubotu> Launchpad bug 120324 in mediawiki "please sync package mediawiki1.10 from debian unstable" [Undecided,New]  https://launchpad.net/bugs/120324
[08:46] <Hobbsee> persia: something aobut htat was just in -devel
[08:46] <persia> minghua: Um.  I can accept that argument, and have no sensible refutation, but I'd rather presume that new users come with an expectation of accuracy.
[08:47] <persia> Hobbsee: Yep.
[08:47] <LucidFox> I filed it when mediawiki1.10 was still in experimental, and was advised to wait
[08:51] <persia> LucidFox: Ah, so mediawiki is in unstable now, and most of the experimental bugs got fixed?  That's great news.  Have you tried a test build against gutsy?
[08:51] <xtknight> i don't quite get the X-Original-Maintainer thing.  i am making myself the new maintainer?  does this mean i have to deal with further bugs in the package?
[08:51] <persia> xtknight: Is this a new package, or an existing package?
[08:52] <xtknight> persia, existing one for which i am making a small patch
[08:53] <xtknight> oh nm, i set the new maintainers to Ubuntu MOTU, not just myself.  is that correct?  so by default all packages are the original debian maintainer, until somebody like myself makes the first patch for them?  (as we must update the maintainer field)
[08:53] <persia> xtknight: OK, if there isn't already an XSBC-Original-Maintainer: entry, and the Maintainer: entry contains an email address without "ubuntu", you probably want to use the standard Maintainer suggestions from https://wiki.ubuntu.com/DebianMaintainerField
[08:53] <persia> xtknight: Yes.
[08:54] <LucidFox> which version of mediawiki1.10 should I test - 1.10.0-3 or 1.10.1-1?
[08:55] <persia> LucidFox: I'd suggest that 10.1-1 is probably newer and more stable.  Which one do you want to sync?
[08:55] <LucidFox> it makes little difference to me, so I'll test the newer one then
[09:01] <TheMuso> c
[09:01] <TheMuso> argh
[09:04] <RAOF> Woah.  Check out bug #126495.  What's the responce for "extremely non-trivial feature suggestion" again :)
[09:04] <ubotu> Launchpad bug 126495 in Ubuntu "[improvement]  avoid data loss on X restart" [Undecided,New]  https://launchpad.net/bugs/126495
[09:04] <Hobbsee> !responses | RAOF 
[09:04] <ubotu> RAOF: response is https://wiki.ubuntu.com/Bugs/Responses
[09:06] <RAOF> Hobbsee: Thanks, I know.  I just wanted to mention that bug before rejecting it.  It'd be kinda cool.
[09:07] <minghua> Glad he didn't request data integrity after power loss, fire, earthquake, etc. :-)
[09:07] <xtknight> would somebody mind taking a look at my patch?  again thx for all the help.  http://rafb.net/p/vllp9d90.html
[09:08] <xtknight> the versioning/etc mainly.  it should be freetennis-0.4.8-3ubuntu1, not freetennis-0.4.8-4 if i'm making a patch for ubuntu's universe, right?
[09:08] <xtknight> i guess i will have to check for a bug in the upstream too..
[09:11] <minghua> xtknight: The distribution should be gutsy instead of feisty.  Otherwise looks good to me.
[09:12] <persia> xtknight: Looks good, with a few minor notes: 1) The syntax for closing a bug in the changelog is (LP: #126490), rather than (Closes: LP #126490), 2) You don't need the blank line between the * entries in the changelog, 3) You should use "gutsy" instead of "feisty" as the target distribution, and 4) We very much prefer full names in changelog entries.
[09:12] <ubotu> Launchpad bug 126490 in freetennis "freetennis manual page has a poor description, and lists an incorrect URL" [Undecided,In progress]  https://launchpad.net/bugs/126490
[09:14] <minghua> Ah, I missed the LP number format thing.
[09:15] <xtknight> ok, the paths of the diff up above doesnt matter?  i mistakenly named my dir freetennis-0.4.8-4 but this is not -4, it is -3ubuntu1
[09:17] <minghua> It should be freetennis-0.4.8.
[09:17] <persia> xtknight: Ah.  They can matter, but are so very often correct by default that nobody notices.  The easiest way to test to make sure your patch applies correctly is to unpack the fresh source again, and run `patch -p1 < $path_to_patch_file` from the base package directory.  If this works, the paths are fine.  If not, you may need to adjust.
[09:17] <xtknight> oh ok
[09:17] <xtknight> p1 will ignore that then probably, but ill verify
[09:18] <minghua> -p1 indeed will ignore that.
[09:19] <minghua> Wrong directory name only matters when you try to build the package, it won't matter for the purpose of generating a patch.
[09:20] <persia>  More importantly, our documentation instructs sponsors to try applying the patch with -p1, so if it works there, any further failures in applying the patch can be blamed on the sponsor, rather than the patch :)
[09:21] <RAOF> Or even Canada
[09:22] <xtknight> hmm apparently editing the .patch file itself is a bad idea..i get malformed patch :\
[09:23] <RAOF> I believe emacs has a patch edit mode, and difftools (or maybe patchutils) has a filterdiff tool.
[09:26] <LucidFox> persia> yes, mediawiki1.10_1.10.1-1 does build
[09:26] <LucidFox> I'd be more surprised if it didn't, since it's in PHP and architecture-independent
[09:26] <persia> xtknight: You may also be interested in any of editdiff, rediff, or espdiff (depending on your confidence level, trust of automation, or ability to broadcase brainwaves)
[09:27] <xtknight> that's too confusing i just started over :p
[09:27] <persia> LucidFox: Great.  Just add a comment indicating the build test, and that the previously referenced list of integration bugs is now empty, and resub U-U-S, and it is likely to be sponsored.
[09:28] <persia> StevenK: It's handy, but don't get carried away.  It sometimes generates fuzz
[09:29] <xtknight> ooh i see what i did wrong
[09:32] <xtknight> so what i upload to LP is this, verbatim as an attachment?  http://rafb.net/p/Y0qOiz83.html
[09:34] <persia> xtknight: Right.  It's best if you attach a file containing that text to the bug, as that makes it easier to grab later (and one needn't worry about compressed whitespace in HTML).  On the other hand, it's good to fix it so it doesn't get any comments first :)
[09:34] <xtknight> lol ok scratch that.  "manual page" -> "man page", and then upload
[09:40] <xtknight> alright so now somebody looks at this and uploads it to universe?
[09:40] <xtknight> doh
[09:40] <xtknight> my old one got uploaded somehow, what the..
[09:40] <persia> xtknight: It usually takes a between a few hours and a day to get sponsored, but you should get some sort of response, either indicating an upload, or asking for modifications.
[09:42] <xtknight> persia,  so i'll have to lobby or will they just stumble across a "patch" attachment?
[09:43] <TheMuso> xtknight: Is ubuntu-universe-sponsors subscribed?
[09:43] <persia> xtknight: If had only uploaded a patch (the manpage change), and added the patch tag, it would usually be a few days before one of the packagers noticed it (perhaps there should be a "subscribe ~ubuntu-universe-contributors" workflow).  Since you've uploaded a debdiff, you'll want to subscribe ubuntu-universe-sponsors to request sponsorship.
[09:45] <xtknight> so after a patch has been uploaded, Status, Importance, Assignee should be?
[09:46] <xtknight> (also i did subscribe universe)
[09:46] <Amaranth> Triaged, Medium, ubuntu-universe-sponsors
[09:46] <Amaranth> i think
[09:46] <xtknight> oh i dont have power to change Importance anyway
[09:46] <Amaranth> heh, only qa-team
[09:47] <Amaranth> Triaged means "this bug is ready for someone to work on it" so it makes sense
[09:47] <LucidFox> So, all packages new to Ubuntu must be actively maintained upstream?
[09:47] <xtknight> found my answer.."Assign the bug to "Nobody", and the status to "Confirmed". "  https://wiki.ubuntu.com/Bugs/HowToFix
[09:47] <Amaranth> yeah but that was when 'Confirmed' meant what 'Triaged' does now
[09:48] <xtknight> i dont see "triaged" for Status
[09:48] <Fujitsu> Triaged is restricted to -qa
[09:48] <persia> xtknight: For patches, that's a great resource.  For full debdiffs, you might find more useful information in MOTU/Contributing
[09:48] <persia> xtknight: Use "Confirmed": that works as well.
[09:49] <xtknight> alright thanks for all the help
[09:49] <xtknight> heading off it's 4am here
[09:50] <Amaranth> Fujitsu: oh, damn
[09:50] <Amaranth> i miss these things :)
[09:50] <Amaranth> i tend to ignore 'Confirmed' bugs when i'm not doing qa
[09:51] <LucidFox> http://revu.tauware.de/details.py?upid=5644 can be nuked - upstream development ceased in 2003
[09:51] <Amaranth> wow, it's been abandoned since before ubuntu existed :)
[09:53] <persia> LucidFox: archived
[09:53] <LucidFox> thanks
[09:53] <persia> Amaranth: +
[09:54] <persia> Amaranth: We've a surprising amount of that in the archives as well (much inherited from Debian).  Much is still good, and maintained, if not still in development.
[09:54] <Amaranth> sure
[09:54] <Amaranth> but a new package for something that has been dead for 4 years is a bit much :)
[09:56] <persia> Unless it's *really* good :)
[09:57] <Amaranth> in that case take over upstream :)
[09:57] <persia> Amaranth: Good point, actually.  Launchpad makes that easy.
[09:58] <owh> whois \sh:
[09:58] <owh> Sigh
[09:58] <\sh> \sh is me
[09:58] <Amaranth> if it's not good enough for you to at least do security fixes as upstream it probably shouldn't be in anyhow
[09:59] <Amaranth> owh: that wouldn't give you idle time anyway
[09:59] <owh> \sh: Yeah, I wondered if you were Soren Hansen
[09:59] <\sh> owh: nope...
[09:59] <\sh> owh: \sh is http://www.sourcecode.de/about :)
[09:59] <Amaranth> close though :)
[10:00] <LucidFox> Amaranth> I already have taken over upstream
[10:00] <LucidFox> or rather, forked it under a different name
[10:00] <Nafallo> owh: soren
[10:00] <owh> Ah. Tah
[10:01] <owh> soren: Sorry about the abomination that was my comment on the new upload. I got burried in all the CVS changes and didn't see the ren fix :(
[10:01] <owh> soren: FYI: owh=onno
[10:14] <soren> owh: No worries.
[10:14] <owh> soren: .
[10:20] <LucidFox> how about qdvdauthor?
[10:21] <persia> LucidFox: Thanks
[10:22] <persia> LucidFox: Thanks for pre-reviewing :)
[10:47] <persia> LucidFox: 6029 commented, but it looks like an upgrade, rather than a new package, so it should really be tracked in LP, rather than in REVU.
[10:57] <LucidFox> so, if REVU is only for new packages, what is the correct procedure for upgrades?
[10:57] <LucidFox> aside from opening an upgrade bug
[10:58] <TheMuso> LucidFox: REVU is also useful for upgrades that involve new upstream versions, as one has to put the whole source package somewhere.
[10:58] <TheMuso> Debdiffs cannot be used for new upstream versions.
[10:58] <LucidFox> ah
[10:58] <persia> LucidFox: We're still working that out :)  For now, open an upgrade bug, upload to revu, mention the bug URL in REVU, and mention the REVU URL in the bug.
[10:59] <LucidFox> as for recommendations, you could review qconf again - I fixed the two issues you mentioned during the first review
[10:59] <persia> LucidFox: Additionally, it makes it a lot easier to review the packaging changes if the diff -urN debian/ of the two versions is attached to the bug.
[11:00] <persia> LucidFox: URL?  Also, since it's still REVU day (only 2 hours left), if there are any changes, it's good to be sure of an annoucement (I didn't see one when I checked the log, but perhaps I missed it, or it was longer ago than the log I reviewed recently).
[11:01] <LucidFox> http://revu.tauware.de/details.py?upid=6041
[11:12] <blueCommand> Please review: http://revu.tauware.de/details.py?upid=6042 Thanks
[11:18] <persia> LucidFox: 6041 commented
[11:19] <persia> blueCommand: What is 6045?  Which should be reviewed?
[11:30] <persia> blueCommand: 6044 archived
[11:31] <blueCommand> persia, I mean 45, sorry
[11:31] <blueCommand> http://revu.tauware.de/details.py?upid=6045
[11:31] <persia> blueCommand: Just checking :)
[11:31] <blueCommand> Please do :) Can't get corrected one too many
[11:34] <TheMuso> persia: From seeing the packages you are reviewing, and your comments, do you think upstream standards of making a package easily buildable, and  clearly understood license wise is slipping?
[11:37] <persia> TheMuso: I'm not sure about slipping: I've been seeing bad upstreams since I can remember.  On the other hand, we've likely the 22,000 most compliant packages already in the repos, so the remainder are a little less likely to be good :)
[11:37] <TheMuso> hehe right.
[11:40] <TheMuso> c
[11:40] <TheMuso> aaaaaaaaaaaaaaaaaaargh
[11:44] <RAOF> :)
[12:02] <eagles0513875> persia: i dont even know where to begin with my bug
[12:03] <eagles0513875> i have the amarok source and xine source
[12:04] <persia> eagles0513875: For bug discussion, #ubuntu-bugs is probably a better forum
[12:06] <eagles0513875> ok
[12:28] <persia> blueCommand: Sorry for the delay.  6045 commented.
[12:28] <blueCommand> Ah nice
[12:29] <blueCommand> persia, Woha, what do you mean with that ? You mean that the full license must be included in the tarball?
[12:30] <blueCommand> Man, that will be a problem to solve
[12:31] <persia> blueCommand: Yes.  It's required by the Ubuntu archive-admins.  See https://lists.ubuntu.com/archives/ubuntu-motu/2007-July/001819.html
[12:31] <blueCommand> So, simply asking him to add a LICENSE to it would suffice?
[12:32] <persia> blueCommand: Yes.  Putting the GPL in LICENSE, and making a note in COPYING that Herbert's code is GPL is all that is required, but this must be done by upstream: it cannot be done in the packaging.
[12:33] <blueCommand> Yes, I'm writing an email as we speak
[12:33] <persia> blueCommand: Also, if there is an objection to the filename LICENSE, GPL would work just as well.
[12:33] <blueCommand> Good
[12:38] <blueCommand> "Herbert Straub's code is under GPL, see LICENCE. The following files are affected:
[12:38] <blueCommand> pipestream.cpp, sockinet.cpp, sockstream.cpp, sockstream.h, sockunix.cpp"
[12:38] <blueCommand> Would that do as COPYING?
[12:39] <blueCommand> LICENSE*
[12:40] <persia> blueCommand: It doesn't even need that much.  I don't have it open now, but last time I looked at COPYING, it mentioned that some of it was Herberts: it just needs to mention that some code is GPL (on the other hand, specifying what is good, and should be encouraged).
[12:40] <blueCommand> Good
[12:40] <persia> For LICENSE (or GPL), it needs to be the full text of the license from the FSF (basically, the same text as is /usr/share/common-licenses)
[12:41] <blueCommand> http://rafb.net/p/Af99W722.html
[12:41] <blueCommand> Would you mind reading that?
[12:42] <persia> blueCommand: s/neiter/either
[12:43] <blueCommand> hm
[12:43] <blueCommand> I would say s/and a/nor
[12:43] <blueCommand> I would say s/and a/nor a
[12:43] <persia> blueCommand: That works as well, but also s/neiter/neither/ in that case :)
[12:43] <blueCommand> Ah :)
[12:44] <persia> blueCommand: Also, I'd end with "Thank you" rather than "Greetings", but that has cultural implications, so may not be correct for you.
[12:44] <blueCommand> Thank you works fine
[12:44] <blueCommand> Otherwise I included everything?
[12:45] <persia> blueCommand: It covers all the salient points.  As I said, it's not essential that upstream lists the specific files, but it is appreciated: I'm not sure if you want to change your email, or resolve that later if upstream objects :)
[12:46] <blueCommand> I'll do that later :) Thanks
[12:46] <blueCommand> I can't thank you enough for "mentoring" me through this persia :)
[12:46] <persia> OK.  14 minutes left in REVU day: any last requests before it closes?
[12:47] <persia> blueCommand: No problems - it's REVU day :)
[12:47] <blueCommand> It is? :)
[01:18] <DktrKranz> siretart, can I talk a bit in query?
[01:19] <elektranox> http://revu.tauware.de/details.py?upid=6055
[01:19] <ScottK> Fujitsu: I guess I should stop filing LP bugs and just ask you the number of the one you already reported when I get annoyed.
[01:19] <Fujitsu> ScottK: Yep.
[01:21] <persia> Does anyone have an opinion about the "Beverage Modification" listed at http://revu.tauware.de/revu1-incoming/wulfware-0706250810/wulfware-2.5/COPYING ?
[01:21] <LucidFox> what's the policy on dependencies and the placement in universe/multiverse?
[01:21] <persia> I think it's not defensible, and therefore doesn't affect the license, but I'd like a second opinion.
[01:21] <Fujitsu> LucidFox: If you depend on something in multiverse, you're condemned to multiverse for eternity.
[01:21] <LucidFox> in either Depends or Build-Depends?
[01:22] <Fujitsu> Right.
[01:22] <persia> Erm.  Not eternity, just until the package can be freed.
[01:22] <Fujitsu> Well, yes.
[01:23] <Fujitsu> persia: I think it looks to be rather in jest and not binding, but it's not up to me.
[01:23] <persia> Fujitsu: Of course :)  While disclaimers are important when discussing legal matters, that's enough to make me omit a comment.
[01:29] <ScottK> Doesn't the GPL explicity say you can't add additional conditions?
[01:29] <ScottK> Agreed it's in jest, but not sure that makes it non-problematic.
[01:30] <ScottK> know/knows.
[01:33] <persia> ScottK: That matches my memory (no additional conditions), but I'm not convinced that it's not an optional condition, given the language.  Anyway, I'll leave that decision to someone else: I found enough minor nitpicks that I could escape advocating again :)
[01:36] <StevenK> persia: There. Every bit of bug 124900 nailed shut. :-)
[01:36] <ubotu> Launchpad bug 124900 in libgpod "Please sync gtkpod-0.99.10, libgpod-0.5.2 from debian unstable" [Wishlist,Fix released]  https://launchpad.net/bugs/124900
[01:36] <persia> StevenK: Hurrah!  One down, 30,000 to go :)
[01:36] <StevenK> Gee, way to make me feel good. :-P
[01:38] <persia> StevenK: Ah.  Does it help if I say "Congratulations: you're #4 in http://ubuntu.joejaxx.org/ !"?  Or "That's an excellent example of diligent and complete bug management"?  These things are also true.
[01:38] <StevenK> Heh.
[01:38] <StevenK> I knew the first one. :-)
[01:46] <ScottK> StevenK: My new LP motto is, "Since it's not Free, then least I can do is complain a lot."  Sounds like you beat me to it.
[01:46] <ScottK> then/the
[01:46] <StevenK> I did?
[01:47] <ScottK> Oh.  Sorry.
[01:47] <ScottK> StevenK/Fujitsu
[01:47] <ScottK> My bad.
[01:47] <StevenK> Hah
[01:47] <ScottK> I now have the first cup of coffee, but haven't drunk it yet.
[01:47] <persia> In LP's favour, it is at least reasonably well supported, and has active developers who respond to many of the bugs and close some of them.
[01:48] <ScottK> This is true, but please see previous rants on building Free software on proprietary tool.
[01:48] <ScottK> tool/tools.
[01:49] <persia> ScottK: Sure, but I suspect you use Google every day, and I doubt you know either how to file a bug report, or with whom you can discuss feature requests and improvements.
[01:50] <LucidFox> when it comes to missing copyright notices in source files, I should get upstream to add them, right?
[01:50] <ScottK> This is true, but it a proprietary product serving it's proprietary masters.  It purports to be "Not Evil", but it's never said it's Free.  
[01:50] <persia> LucidFox: You must.  If upstream doesn't provide them with a clear license, you don't have the right to relicense.
[01:50] <ScottK> Ubuntu is about software freedom.
[01:51] <ScottK> But OTOH, let's not have another 4 hour LP is proprietary rant...
[01:51] <ScottK> OK.  Distinction without difference for this particular point.
[01:52] <ScottK> but a good point.
[01:53] <persia> Without refuting the many valid and strong arguments that any software developed with LP is oddly called Free, I just think it's important to remember that Free Software is an means to an end in this case.  While we respect and largely abide by the DFSG, we're not actually bound by them, and there is a history of (minor) non-compliance.
[01:53] <siretart> DktrKranz: about what? I suspect its better here...
[01:54] <DktrKranz> siretart, gotta go in a while, I'm going to send you a mail this evening, if you agree
[01:54] <siretart> sure
[01:54] <DktrKranz> thanks
[01:55] <DktrKranz> ScottK, I uploaded a new php-interbase at http://revu.tauware.de/details.py?upid=6056 following your suggestions
[01:55] <imbrandon> moins siretart ScottK persia StevenK and *
[01:55] <DktrKranz> and yes, archive http://revu.tauware.de/details.py?upid=5287 for now. I will upload a new package when ready
[01:55] <siretart> hey imbrandon!
[01:55] <ScottK> Heya imbrandon
[01:55] <persia> imbrandon: Hi!
[01:55] <Nafallo> imbrandon: morning
[01:55] <imbrandon> ello Nafallo 
[01:55] <imbrandon> man SL can suck you in, lol
[01:56] <DktrKranz> see you later
[01:56] <Nafallo> SL?
[01:56] <StevenK> Second Life, I'm guessing
[01:56] <persia> imbrandon: Just implement a handheld there, and carry it about: you can IRC and SL at the same time (unless you actually enjoy physical activities)
[01:56] <imbrandon> been setting up a ubuntu/kubuntu tower on the Free and Open Island that mark bloged about , Nafallo SL == secondlife
[01:56] <StevenK> I wasn't aware imbrandon had a first one.
[01:56] <imbrandon> lol
[01:56] <Nafallo> SL = Storstockholms Lokaltrafik :-)
[01:56] <imbrandon> persia, actualy i scripted a laptop to let me check email and irc from ingame
[01:57] <persia> imbrandon: heh.
[01:57] <Nafallo> i.e. busses and tube and stuff in Stockholm ;-)
[01:57] <imbrandon> sometime it will do some other things , because its for the ubuntu computer lab 
[01:57] <persia> Nafallo: What does the "Stor" part mean?
[01:57] <imbrandon> ;)
[01:57] <Nafallo> persia: big :-)
[01:58] <persia> Nafallo: Ah.  "Greater Stockholm Local Transportation (network)".  Thanks.
[01:58] <Nafallo> like in "Covers most things in"stockholm :-)
[01:58] <ScottK> persia: Assuming DktrKranz actually did what I suggested, his new php-interbase at http://revu.tauware.de/details.py?upid=6056 may be worth your time.  Just be aware that despite the apparent history in LP, it really is a new package.
[01:58] <Nafallo> something like that indeed :-)
[01:59] <persia> ScottK: You've advocated?  Also, wasn't there a php5-interbase source?  Is this a rename?  Lastly, is there a plan somewhere for the rest of php-universe?
[01:59] <LucidFox> One more licensing question: the COPYING file contains this http://pastebin.ca/623165
[01:59] <ScottK> persia: No, I didn't.  He is pulling that module out of the php5 tarball and packaging it separately.
[01:59] <LucidFox> I understand that it needs to be mentioned in debian/copyright, but is this exception GPL-compatible to begin with?
[02:00] <persia> LucidFox: That's OK.  It just means that people can build that program for Windows or QTopia without violating the license.
[02:00] <ScottK> persia: Technically it looked good to me (but what do I know) he just needed to do a better job of making/documenting his own source.
[02:01] <persia> More generally, the GPL allows authors to grant additional freedoms to users, if desired, but does not allow the restriction of freedoms.  Further, linking exceptions do not contaminate interaction with other GPL-licensed software.
[02:02] <persia> ScottK: OK.  I'll give it a look.  I generally prefer to hit things that either haven't been reviewed, or have an advocate, but those are getting rare :)
[02:03] <ScottK> Well I think there's a shot you'll adovcate this one.
[02:03] <ScottK> Dunno about the rest of php5 in Universe.
[02:04] <persia> ScottK: Now I'm confused.  You didn't advocate, but you think I will?
[02:04] <ScottK> persia: I looked at the previous rev and technically I thought it was reasonable.  I have not looked at the new one.
[02:05] <ScottK> If he fixed the stuff I told him to fix, then I think it might be advocable, but haven't had the cycles to check.
[02:05] <persia> ScottK: Ah.  I get it now.  In that case I'm more than happy to take a look (although I'll be REVUing less now that REVU day is over).  Thanks for the pointer.
[02:06] <TheMuso> Thats if he advocates. :p
[02:08] <Hobbsee> persia: but you go naer REVU, remember.
[02:09] <Hobbsee> the good people manage to avoid REVU entirely :P
[02:09] <persia> Hobbsee: You could too.  It was REVU day recently, and more reviewers would have been good :)
[02:09] <TheMuso> persia: I'm kinda the same.
[02:09] <Hobbsee> no, no, i avoid REVU, so as to be impartial
[02:09] <Nafallo> Hobbsee: I'll take that as a compliment then ;-9
[02:10] <Nafallo> s/9/\)/
[02:10] <persia> Hobbsee: Ah.  I guess you've an excuse now.  Perhaps I'll let you look at licensing then?  :)
[02:10] <\sh> fck....at least SLES10 kernel and Ubuntu feisty kernel is broken
[02:10] <Hobbsee> persia: i'm not an archive admin yet, so i dont need to :P
[02:10] <\sh> Hobbsee: you are working for canonical now? :)
[02:11] <Hobbsee> \sh: i'm the tribe 3 release manager
[02:11] <StevenK> Hrm. It seems Launchpad is reporting it's offline, but there was no announcement
[02:11] <\sh> Hobbsee: I saw that :)
[02:11] <Hobbsee> but no, i'm not working for canonical currently
[02:11] <ScottK> StevenK: Try again.  I just reached it.
[02:11] <StevenK> Silly thing
[02:12] <ScottK> Agreed.
[02:13] <persia> linda should automatically figure out what I mean when I give her the wrong arguments.
[02:13] <Hobbsee> persia: more to the point, I avoid REVU now so that i can be impartial at some point in the future.  *g*
[02:14] <persia> Hobbsee: That's not really a good excuse.  By using REVU, and demonstrating a fine understanding of the technical points of archive-acceptability, you can show the necessary knowledge to be suitable for some possible later position in which you'll need to avoid REVU to maintain impartiality.
[02:14] <Hobbsee> persia: hush!  leave my excuse alone :P
[02:15] <TheMuso> heh
[02:15] <persia> Hobbsee: I'll let you keep your excuse until next REVU day, but as there's not an impending tribe then, perhaps we can count on you?
[02:15] <TheMuso> The biggest problem with revu is that there are so many packages there that haven't been updated, and its often tempting just to go and fix them up one's self, and upload.
[02:15] <Hobbsee> persia: when's the next REVU day?
[02:16] <TheMuso> Hobbsee: Next Monday.
[02:16] <Hobbsee> oh, bugger.  hmmm.
[02:17] <persia> Hobbsee: I keep REVU open for 49 hours: I doubt you can hide from IRC for that long :)
[02:17] <persia> s/REVU/REVU Day/
[02:17] <TheMuso> persia: I guess its unfair for those who initially uploaded the package.
[02:17] <Hobbsee> persia: yeah...that long might be a bit hard
[02:18] <persia> TheMuso: Perhaps.  It depends on whether REVU is intended as a proving ground, a learning experience, or a mechanism to get new packages into the archive.  This is probably another one of those points that needs thought and discussion.
[02:18] <TheMuso> persia: Heh I'm good at those, aren't I.
[02:18] <StevenK> C'mon Launchpad. Don't make me get out and push.
[02:19] <persia> TheMuso: That's not a bad thing.  Keep raising them, and if we collectively stare at our navels a bit, perhaps we'll actually pick out the lint, and make universe rock.
[02:20] <TheMuso> heh
[02:20] <ScottK> persia: Isn't that what lintian is for?
[02:21] <persia> ScottK: It's supposed to be, but the question is why have I spent the last two days running lintian and reporting it, rather than just fixing packages and requesting someone to confirm and upload?
[02:21] <ScottK> Yeah.  I know.
[02:22] <ScottK> My view is that it is all of those things, but unless someone cares enough about a package to get it uploadable, the odds of someone caring enough to maintain it are low.
[02:22] <ScottK> We get plenty enough hit and run uploaders as it is.
[02:22] <persia> Here's a subject.  Let's try a test :)
[02:23] <persia> elektranox: How do you feel about collaborative development?  Would you mind if someone worked with you on gafix?
[02:23] <ScottK> More software is good, but good software is better.
[02:23] <elektranox> persia: I don't mind
[02:23] <persia> ScottK: True, but then again, we're not seeking maintainers - most things are just bugfixes, and we can find and train bugfixers without as much effort as finding and training maintainers.
[02:24] <ScottK> persia: Yeah, but what most packages need is someone who cares.
[02:24] <persia> Would anyone be willing to take a look at http://revu.tauware.de/details.py?upid=6055 and upload a new candidate?  elektranox has been working with upstream.
[02:24] <persia> ScottK: I disagree, but for complex reasons that aren't very defensible with the current bug management activities, so I won't argue.
[02:25] <StevenK> Twitch
[02:25] <TheMuso> persia: Heading there.
[02:25] <StevenK> I dislike the thought of php-interbase
[02:25] <persia> StevenK: You don't like php?  interbase?
[02:25] <StevenK> I don't like either.
[02:25] <persia> TheMuso: Thanks.  Let's see how it works.
[02:26] <TheMuso> persia: SO what do I have to do?
[02:26] <StevenK> Interbase more so, since in a previous life I looked after a Interbase database.
[02:27] <persia> TheMuso: Take 6055 as a base, and upload a new candidate to REVU, with changelog entries if required (as in, they would be interesting to future people working on the package, rather than in the context of initial packaging).
[02:27] <StevenK> Using brain-damaged SQL89 and a management interface that sucked rocks through hypodermic needles should turn anyone off it.
[02:27] <Fujitsu> Hahah.
[02:27] <TheMuso> persia: Um ok.
[02:28] <persia> StevenK: That matches my experience with interbase, but I'm not sure why php shoudn't have bindings, given my experience with php/
[02:28] <StevenK> Heh
[02:28] <imbrandon> telnet www.imbrandon.com 80
[02:28] <imbrandon> err
[02:28] <persia> TheMuso: If it's really frustrating for you, there's no point in suggesting we all work that way.  If it works for you, we can propose a change, which would probably make things faster.
[02:29] <ScottK> imbrandon: You should be using SSH anyway.
[02:29] <TheMuso> persia: Um how would it be frustrating?
[02:29] <persia> ScottK: It't not authenticated :)
[02:29] <ScottK> Ah.
[02:29] <persia> TheMuso: I don't know.  Seems easy enough to me, but having a testcase is usually good.
[02:29] <TheMuso> Right.
[02:30] <imbrandon> ScottK, not to check the html on port 80 silly
[02:30] <ScottK> Ah.  OK.
[02:30] <StevenK> I don't know about that.
[02:30] <StevenK> ScottK: How many passwords do you type into telnet <x> 80 ?
[02:31] <imbrandon> hrm shouldnt "GET /"
[02:31] <imbrandon> work StevenK 
[02:31] <imbrandon> ?
[02:31] <StevenK> Depends on the webserver.
[02:31] <StevenK> 'GET / HTTP/1.0' to be pedantic
[02:31] <persia> imbrandon: Yes, unless you have virtual hosting enabled, in which case you might need a longer URL
[02:32] <LucidFox> debian/menu is only needed for programs intended to be included in the desktop environment menu, right?
[02:32] <persia> (or downgrade to http 1.0)
[02:32] <imbrandon> persia, yea i have many vhosts on that box 
[02:32] <imbrandon> heh
[02:32] <imbrandon> and its lighttpd ;)
[02:32] <StevenK> In which case "GET / HTTP/1.1\nHost: foo\n\n"
[02:32] <blueCommand> GET / HTTP/1.1
[02:32] <blueCommand> Bah :)
[02:32] <StevenK> blueCommand: Nyah. :-P
[02:32] <persia> LucidFox: You'll want both debian/menu and a .desktop file by preference for a GUI application.  For command-line only applications, you don't need either.
[02:34] <TheMuso> persia: Ok you probably saw that paths in the Makefile are hard coded?
[02:34] <persia> TheMuso: Yep.  I was thinking that a dpatch or quilt square would be a better solution, but haven't looked closely.
[02:34] <imbrandon> GET / HTTP/1.0 seemed to work
[02:35] <imbrandon> thanks
[02:35] <imbrandon> i was thinking just GET /
[02:35] <imbrandon> should
[02:35] <zul_> imbrandon: quality software: http://images.imbrandon.com/funny
[02:35] <StevenK> imbrandon: Like I said, depends on the webserver.
[02:35] <persia> imbrandon: That works iff the host is running http 1.0 or the host doesn't have vhosts defined or the webserver is on crack
[02:37] <imbrandon> zul, hehe yea http://images.imbrandon.com is my playground ;)
[02:37] <TheMuso> persia: Ok... How do you think I should do this? I have made some changes that need making, how do you suggest I document them?
[02:37] <imbrandon> zul, oh wow, dident notice the devide by zero
[02:37] <imbrandon> lol
[02:38] <persia> TheMuso: That's an interesting question (and a strong argument for using BZR for pre-archive collaboration).  I'd probably go with debian/changelog for things that will be interesting later, an a REVU comment for things that are interesting now, but I'm certainly not authoritative.
[02:38] <TheMuso> ScottK: Was thinking the same.
[02:38] <imbrandon> zul, http://images.imbrandon.com/unsorted/mishkotrax.jpg is still my fav ;)
[02:38] <TheMuso> Ok.
[02:38] <TheMuso> I think a revu comment at this point makes more sense.
[02:38] <zul> imbrandon: lol
[02:39] <persia> ScottK: That's been on the wishlist for a while now.  You're good with python, right?
[02:39] <ScottK> Yeah and short on time.
[02:39] <persia> hmmm...
[02:39] <ScottK> Plus it's in bzr and I'm severely bzr impaired.
[02:40] <imbrandon> zul, fixed ( the zero error )
[02:40] <StevenK> Oh, bzr isn't that hard.
[02:40] <imbrandon> bzr == svn++
[02:40] <imbrandon> :)
[02:40] <StevenK> If you can learn tla, you can deal with bzr. :-P
[02:41] <zul> imbrandon: yes i have nothing better to do other than go through random websites and complain about php errors ;)
[02:41] <imbrandon> lol
[02:42] <imbrandon> glad you said something , it was because of a non-image in the dir
[02:42] <imbrandon> i need to patch that
[02:43] <persia> ScottK: Also, even without any bzr knowledge beyond bzr export, you should be able to generate a patch :)
[02:43] <StevenK> Oh neat. tailor (cvs2bzr) can't cope with branches very well
[02:43] <persia> StevenK: That's really not bzr's fault :)
[02:44] <StevenK> persia: Of course not, but it rules it out for $WORK
[02:44] <StevenK> svn sort of rules itself out too, not being able to cope with 15,000 dentries.
[02:44] <persia> StevenK: Ah.  Please accept my sympathy for your working conditions.
[02:44] <StevenK> Heh
[02:45] <TheMuso> persia: Will be here a while. Want to change a fair few things.
[02:45] <StevenK> persia: We have a 9 year old CVS repository. I'm heartily sick of it, and want to switch. SVN looked to be the logical choice, but ...
[02:46] <persia> TheMuso: Not surprising.  Last I looked, that package wasn't in great shape: I just happened to know it needed review, and the original uploader was in-channel.
[02:46] <TheMuso> Right
[02:51] <xxxxx1> good morning all.
[02:51] <siretart> hi xxxxx1 
[02:51] <blueCommand> persia, He said that the GPL-license is a leftover in the package and it shouldn't really be there anymore. Is the other license enough for it to be accepted, or is it doomed to multiverse?
[02:52] <blueCommand> persia, He will repackage it without GPL
[02:52] <siretart> ScottK: feel free to hack on REVU! I'll help you were I can!
[02:52] <persia> blueCommand: Currently, it can't be accepted at all.  If upstream releases a package either with the GPL, or without any GPL code, it would be acceptable.
[02:53] <blueCommand> persia, Upstream (himself) will release without any reference to GPL (well, configure and resulting Makefile has some notice about it)
[02:53] <persia> blueCommand: Do note, that if the GPL code remains, but has been relicensed, one might wonder whether the copyright holder has agreed to the relicensing, and request confirmation prior to packaging.  Tort law can be expensive.
[02:55] <persia> xxxxx1: Great.  Would you mind adjusting the status :)
[02:55] <blueCommand> persia, The code affected is his and his alone, he is reverting the license to match that of which the other sources are.
[02:55] <persia> Excellent.  Thank you.
[02:55] <xxxxx1> persia, argh :D
[02:55] <persia> blueCommand: Great!
[02:55] <persia> xxxxx1: No: my mistake :)
[02:56] <persia> xxxxx1: "Fix Committed"?  Did someone already upload?
[02:56] <blueCommand> persia, Good, I guess I should re-license the package to that of which the sources are too?
[02:57] <xxxxx1> persia, nope. i've just upload the changes to REVU again.
[02:57] <persia> blueCommand: I recommend that, but as was pointed out ~24 hours past, it's not required.
[02:57] <xxxxx1> persia, as in last comment
[02:57] <xxxxx1> persia, it's wrong (status)?
[02:57] <persia> xxxxx1: See the MOTU Sponsors Queue docs :)
[02:58] <xxxxx1> ok
[02:58] <blueCommand> persia, I want to make it as good as I can, so I will do that then.
[02:58] <xxxxx1> persia, ah. you made it. heh
[02:59] <persia> xxxxx1: That make me especially picky :)
[02:59] <persia> s/make/makes/
[03:10] <hroo772> hey is anyone around
[03:12] <ScottK> siretart: I see in Bug #52539 that you made a candidate source backport for vim7 on Dapper.  Would you be interested in uploading it?  It appears to have been tested?
[03:12] <ubotu> Launchpad bug 52539 in dapper-backports "backport vim 7 to dapper" [Medium,Confirmed]  https://launchpad.net/bugs/52539
[03:19] <siretart> ScottK: oh, indeed, I don't get to it today, if you are interested, feel free to upload them!
[03:20] <ScottK> siretart: Need to be core-dev to upload a source backport, so I can't.  I'll mark it inprogress and assign it to you if that's OK?
[03:22] <siretart> ScottK: works for me, thanks for notifying me about that!
[03:22] <ScottK> No problem.
[03:26] <TheMuso> persia: Almost done here.
[03:26] <persia> TheMuso: Cool.  Does it look uploadable, or is upstream going to need to do more?
[03:27] <TheMuso> persia: WIth the patches I am applying, it will probably be uploadable, so technically it should be sound. License wise though, it loosk ok, but I'll want another pair of eyes for that.
[03:27] <persia> TheMuso: OK.
[03:27] <persia> elektranox: Are you also upstream for gafix, or just coordinating?
[03:27] <TheMuso> But since elektranox is upstream, I'll use these patches to show what needs doing, so hopefully he can just make the changes and be done with it.
[03:28] <persia> Ah.  Cool :)
[03:28] <TheMuso> elektranox: Look at source files/copyright. Upstream it seems.
[03:28] <TheMuso> sorry, persia ^^
[03:28] <persia> TheMuso: OK.  Last time I looked it said "Upstream Author" :)
[03:28] <TheMuso> SHould that be changed?
[03:29] <persia> TheMuso: I requested a change from "Upstream Author" to the actual author, but I didn't investigate who that might be.
[03:29] <TheMuso> Right.
[03:30] <persia> ("Upstream Author" is a clear pseudonym or anonym, and as such can be assigned copyright, but cannot grant a license)
[03:30] <persia> (actually, this is debatable for pseudonyms, but it's not a unique pseudonym)
[03:31] <TheMuso> right
[03:31] <TheMuso> Ok, time for a test build.
[03:33] <TheMuso> persia: Since he is upstream, my aptches should also make it easier for others who build for distros/from source.
[03:33] <TheMuso> changes even.
[03:33] <tuxmaniac> raising a bug report for syncing packages from Debian will do?
[03:33] <persia> TheMuso: If they are adopted, surely :)
[03:33] <TheMuso> persia: Yes.
[03:34] <persia> tuxmaniac: Yes.  It should fix a bug, or bring us a good new feature though: we're not syncing everything :)
[03:34] <tuxmaniac> persia, I will mention the reason or importance also. Then you MOTUs will decide and sync right?
[03:35] <persia> tuxmaniac: Ah.  Yes.  Please include a short Rationale explaining why a sync is good, and the additional Debian changelog since the last merge/sync in the bug.  If you subscribe ubuntu-universe-sponsors, someone will look at it soon, and either ask for further information, or accept it.
[03:36] <tuxmaniac> StevenK, something sarcastic?? :-)
[03:36] <Kmos> !sync
[03:36] <ubotu> Sorry, I don't know anything about sync - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[03:36] <Kmos> !requestsync
[03:36] <ubotu> Sorry, I don't know anything about requestsync - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[03:36] <Kmos> ubotu: u're bad :)
[03:36] <ubotu> Sorry, I don't know anything about u're bad :) - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[03:36] <tuxmaniac> Kmos, :)
[03:36] <StevenK> Certainly not. Just trying to point out a tool exists.
[03:37] <tuxmaniac> persia, StevenK Do i use the tool or report it by hand?
[03:37] <persia> tuxmaniac: Either works, and both are good.
[03:37] <tuxmaniac> persia, thanks
[03:39] <StevenK> tuxmaniac: The reason I mention it, is the requestsync script in Gutsy has a -s option that automatically subscribes the right sponsorship team, and prompts for rationale.
[03:39] <StevenK> persia: The 404 errors are because packages.d.o sucks hard, nothing to do with the script.
[03:39] <persia> StevenK: I know - that's why I didn't report a bug :)
[03:40] <StevenK> I don't get how packages.d.o can suck so hard, personally.
[03:41] <persia> StevenK: I think it's a hard problem.  I routinely get 404s from changelogs.ubuntu.com as well.
[03:41] <persia> (admittedly, p.d.o is worse)
[03:41] <tuxmaniac> requestsync not in feisty?
[03:42] <StevenK> I don't think it's hard, it just requires an up to date mirror.
[03:42] <StevenK> tuxmaniac: It's in the package 'devscripts'
[03:42] <TheMuso> tuxmaniac: Yes, but doesn't know about gutsy.
[03:42] <persia> tuxmaniac: it should be, but it might not have the -s (sponsor) switch.
[03:42] <tuxmaniac> TheMuso, aah Ok
[03:42] <StevenK> TheMuso: requestsync asks the local machine about releases.
[03:43] <TheMuso> StevenK: Right
[03:43] <tuxmaniac> hehe. I was trying to install requestsync instead of using it by just hitting the tab :))
[03:43] <StevenK> Except in Gutsy, where it uses rmadison.
[03:43] <persia> StevenK: Does the migration to rmadison fix that, or is it still checking locally?
[03:43] <StevenK> It doesn't check anything locally any more
[03:44] <persia> Ah.  Good.
[03:44] <StevenK> persia: Patches welcome to make the bug report better, by the way
[03:44] <StevenK> I'll probably do a devscripts upload after tribe-3
[03:45] <persia> StevenK: The big issue is LP: I'd like it to strip the signature and meta-commands in the email interface, but I understand that that's really not a priority right now.
[03:45] <tuxmaniac> No wikipage on devscripts? /me searches wiki.,ubuntu.com
[03:45] <StevenK> persia: Ah
[03:47] <persia> StevenK: In terms of the script, it's fairly close.  I'd like to see a Rationale: section for each merge/sync bug after DIF, just to make it easy for the sponsors / archive admins, but it's not required by our policy at this point, so I don't think it warrants inclusion.
[03:48] <persia> It'd also be extra nice if all sync bugs had the sync tag, LP accepted tagging through the email interface, and the script checked for an existing open sync bug prior to allowing a sync request, but that's just wishful thinking.
[03:48] <StevenK> persia: That's hard
[03:49] <persia> StevenK: Right.  Hence the complete lack of bug reports or patches :)
[03:49] <StevenK> persia: If Launchpad accepted tagging, it's fairly simple to add
[03:49] <persia> StevenK: You mean we have a working by-package tag search that can be called from within python?
[03:50] <StevenK> persia: No, I mean if Launchpad could be told " tags sync" in an signed mail
[03:50] <persia> Ah. Right.  That only helps for the first half :)  I think full implementation waits for XMLRPC
[03:50] <StevenK> Right.
[03:51] <persia> At which point, a rewrite in XMLRPC would probably magically resolve most of my issues anyway :)
[04:05] <sommer> ScottK: What's up
[04:05] <ScottK> Hi
[04:05] <sommer> I had some time to work on sylpheed-claws-gtk2-clamav this weekend
[04:06] <sommer> It pulls in the libclamav1 package and insists on using that.
[04:06] <ScottK> We got the interim backports of clamav 0.88.7 to Dapper/Edgy approved.  Edgy is released and Dapper is waiting a manual pusy.
[04:06] <ScottK> pusy/push.
[04:06] <ScottK> OK.
[04:06] <ScottK> Sounds like it'll have to be updated then.
[04:07] <sommer> I think so...or the control file changed to use a different version.
[04:07] <sommer> I'm not sure exactly how to go about that though. 
[04:07] <ScottK> The libclamav1/2 API is different.
[04:07] <ScottK> If it's using libclamav1 directly there's a 0% chance of it working.
[04:08] <sommer> gotcha...libclamav1 didn't recognize the test virus I have either.
[04:08] <ScottK> The next question would be then to test the newer claws package on Dapper.
[04:08] <xxxxx1> hello ScottK 
[04:08] <sommer> the 0.88.7?
[04:08] <ScottK> I'm about to publish test packages for Dapper for clamav 0.91.1.
[04:08] <sommer> ah cool.
[04:09] <ScottK> The 0.88.7 is about to go into the dapper-backports repository.  That's the best we can do until the rest of this gets worked out.
[04:09] <ScottK> Hi xxxxx1
[04:11] <ScottK> sommer: It's uploading now.
[04:11] <sommer> does that mean that 0.88.7 has features backported from 0.90.3?
[04:12] <ScottK> No.  It means that 0.88.7 is compatible with all the other stuff already in Dapper so we can backport it.  It's the newest release we can backport without all the other packages getting updated.
[04:12] <ScottK> It fixes a bunch of bugs and so it's a good interim step.
[04:13] <sommer> ah gotcha, but 0.88.7 doesn't get sig updates from clamav correct?  
[04:13] <StevenK> Does 0.88.7 output the irritating "Your clamav engine is out of date! PANIC! PANIC! PANIC!" ?
[04:14] <ScottK> sommer: Dunno.  I haven't checked.
[04:14] <ScottK> StevenK: Yes.
[04:14] <StevenK> Twitch
[04:14] <ScottK> Even the Feisty 0.90.3 as patched with all the security fixes does that.
[04:15] <sommer> ScottK: cool...thanks 
[04:15] <ScottK> If you want to avoid that, you have to run Gutsy as I uploaded the latest non-panicky one yesterday.
[04:17] <ScottK> sommer: Please update the wiki with your findings.
[04:17] <sommer> will do
[04:18] <ScottK> sommer and leonel and anyone else who cares: I've updated that draft dapper clamav backport packages at http://www.kitterman.com/clamav/ for clamav 0.91.1.
[04:19] <sommer> party...I'll start retesting with that.
[04:20] <ScottK> Source package and i386 binaries again.
[04:21] <l_r> hello
[04:21] <ScottK> Hello
[04:22] <leonel> ScottK: a big THANKS ! 
[04:22] <l_r> i need to build debs from source code for public sharing. any doc around?
[04:23] <TheMuso> persia: Finished doing what I wanted here. THink more needs doing, mostly relating to possibly using the tex file to generate docs, but the really full on stuff is now done.
[04:23] <ScottK> superm1_: If I may make a suggestion: bugging the head of Ubuntu's kernel team to comment on $MYPETBUG when they are focused on trying to get a release out the door may not be the best timing.
[04:23] <superm1_> ScottK, I wasn't trying to do that.  I was just saying it may be applicable
[04:24] <Hobbsee> ScottK: it was a bug that had just been discussed in the channel
[04:24] <persia> TheMuso: Great.  Give it an upload, and I'll take a look.  If it passes the standard REVU tests, I'll stick it in (and we can clean up tex later), or if I see an issue, I'll try to fix, and reupload.
[04:24] <ScottK> OK.  Sorry, I missed that.
[04:24] <elektranox> :)
[04:24] <TheMuso> persia: Ok.
[04:25] <persia> elektranox: You may want to take a look as well.  If there's something you want to grab upstream, let me know, and I'll wait for your revision before I upload anywhere.
[04:25] <TheMuso> Just waiting for the upload to appear.
[04:26] <elektranox> jear I'm thinking of adding method to change the serial Interface, which is used
[04:26] <persia> REVU can be a little slow, but at least it doesn't hide things as well as LP
[04:26] <TheMuso> yeah
[04:27] <persia> elektranox: Ah.  Is that patch ready and tested?  I was thinking more about packaging-related changes, etc.
[04:27] <TheMuso> My changes are mostly packaging related.
[04:28] <elektranox> nope I've not finished that so far, but it's not a big hack
[04:28] <TheMuso> Ok its up.
[04:28] <TheMuso> comment is now up.
[04:28] <elektranox> ok
[04:28] <persia> elektranox: In that case, it makes sense to me to try to get this in, and keep the serial interface change for the next release.
[04:28] <persia> TheMuso: URL?
[04:28] <elektranox> http://revu.tauware.de/details.py?upid=6059
[04:29] <TheMuso> http://revu.tauware.de/details.py?upid=6059
[04:31] <TheMuso> persia: I used dpatch files, but as I said, if we can get that all into upstream, the patches don't need to be carried.
[04:31] <elektranox> ok probably it's a good idea to fix the desktop and makefile in upstream?
[04:31] <persia> elektranox: Do you want to apply the dpatches upstream, and put in a patchless revision?
[04:31] <TheMuso> My comment states what I've done.
[04:32] <persia> elektranox: It's best to fix anything not required in debian/ upstream, as that way it makes it easier to package for other distributions.
[04:32] <elektranox> I'll do so
[04:32] <TheMuso> i.e my prefix etc patches.
[04:32] <persia> elektranox: OK.  I'll look through it, and see if I have anything, but I'll wait for your upload before committing anything.
[04:33] <elektranox> ok
[04:33] <TheMuso> persia: I'm off to bed. Ping/mail if you have questions. Its 12:30AM here
[04:33] <persia> TheMuso: Sleep well.  I'm getting close myself.  Let's regroup tomorrow to decide if this process is a good one, or the old way is better.
[04:33] <TheMuso> persia: Yup.
[04:33] <TheMuso> Till tomorrow.
[04:34] <elektranox> TheMuso: good night - thanks for your help :)
[04:35] <TheMuso> elektranox: You'r welcome, and thanks for participating. We are working out whether we should try and change the review process.
[04:36] <ScottK> Is any MOTU looking at libhdhomrun?  If no one says so, I'll review it.
[04:36] <DktrKranz> persia, thanks for commenting on php-interbase. I was reading the log, especially when you state if there is a plan to manage php-universe
[04:37] <persia> DktrKranz: Is there?
[04:37] <DktrKranz> it used to be, but pitti preferred to have three standalone packages
[04:37] <DktrKranz> here what he did
[04:37] <persia> DktrKranz: I remember that, I just haven't heard about the other two :)
[04:38] <DktrKranz> persia, they have been uploaded recently
[04:38] <superm1_> thx ScottK.  Fyi, i added the diff -urN to the bug listed in the comments
[04:38] <persia> DktrKranz: Ah.  Excellent then :)
[04:38] <DktrKranz> it wasn't me
[04:38] <persia> DktrKranz: Still, the bringer of good news receives the smile.
[04:38] <DktrKranz> :)
[04:39] <DktrKranz> anyway, since php-interbase (and the others) are quite different since 5.1.2
[04:39] <ScottK> superm1_: That's really not necessary.  I can get that in one click on REVU.
[04:39] <DktrKranz> I think they deserve a cleanup
[04:39] <superm1_> ScottK, you can get a debdiff but not a diff of the debian/ directory
[04:39] <superm1_> which may be more useful in looking at a new version
[04:39] <superm1_> (imo)
[04:39] <ScottK> Agreed.  Is that what's in the bug?
[04:40] <superm1_> Yes
[04:40] <ScottK> Ah.  Yes.  That's helpful.
[04:44] <elektranox> persia: do you think I should add the $(DESTDIR) to upstream?
[04:44] <ScottK> Would someone running Gutsy please confirm that the LGPL version 3 can now be found at /usr/share/common-licenses/LGPL-3?
[04:45] <elektranox> elektranox@earth:~$ ls /usr/share/common-licenses/
[04:45] <elektranox> Artistic  BSD  GFDL  GFDL-1.2  GPL  GPL-2  GPL-3  LGPL  LGPL-2  LGPL-2.1
[04:45] <persia> elektranox: Very much so.  It will be very rare that any distribution will want to build a package that automatically writes to /usr/share, and if $(DESTDIR) is undefined, it will do the right thing on a local system.
[04:45] <superm1_> hm so not there yet.  
[04:46] <persia> ScottK: Just one small note: GPL is currently a symlink to GPL-2, so watch for that.
[04:46] <ScottK> Right.
[04:46] <ScottK> persia: The package debian/copyright points to /usr/share/common-licenses/LGPL-3, so I want to make sure that actually exists.
[04:46] <superm1_> ScottK, perhaps a sep. bug should be filed to include LGPL-3 in /usr/share/common-licenses?  I expected it to be there already
[04:47] <DktrKranz> I didn't follow merge discussion after MOTU Meeting, do you plan to focus on them before UVF?
[04:47] <persia> ScottK: Ah.  I missed the initial "L".
[04:47] <ScottK> DktrKranz: We are still debating.
[04:47] <CWC-Vladimir> does anyone know of a good ftp client?
[04:48] <ScottK> elektranox: Thanks.
[04:48] <Hobbsee> CWC-Vladimir: sounds like a #ubuntu type of question
[04:48] <wasabi> Anybody work with Samba able to review a simple patch and get it uploaded?
[04:48] <DktrKranz> OK, I'll read a bit the discussion
[04:48] <CWC-Vladimir> its full
[04:48] <persia> DktrKranz: Yes, but we don't really have consensus on how or when.  Please follow the old procedure, and join the next MOTU meeting if you are interested.
[04:48] <elektranox> ScottK: np
[04:48] <ScottK> CWC-Vladimir: That doesn't make this a support channel.
[04:48] <CWC-Vladimir> im not asking for support, im asking if theres a good ftp client
[04:48] <DktrKranz> persia, it could be difficult since I'll be in office, but I'll try to attend it
[04:49] <ScottK> CWC-Vladimir: That's not development which is what we do here.
[04:49] <ScottK> superm1_: In the meantime you can't use that link, you need to put the full license text in debian/copyright.
[04:49] <persia> DktrKranz: OK.  If you can't make it, the minutes should have info, but input from contributors would be helpful.
[04:50] <superm1_> ScottK, alright.  I'll file a bug against base-files, but include the whole license in debian/copyright for now
[04:50] <ScottK> OK.  Commented.
[04:50] <DktrKranz> if I mind well, during feisty there was a good script which pointed out security issues fixed in debian
[04:50] <DktrKranz> but still open in ubuntu
[04:50] <DktrKranz> is it still active?
[04:50] <persia> DktrKranz: http://ajmitch.net.nz/~ajmitch/missing-fixes-rc.html ?
[04:51] <DktrKranz> that's it
[04:52] <CWC-Vladimir> no, but i need it for uploading to my 5 fucking servers
[04:52] <CWC-Vladimir> which does include development
[04:53] <DktrKranz> these ones should be considered, is it worth to mention it in the next M-M?
[04:53] <CWC-Vladimir> man, fuck you people, fucking pricks
[04:53] <ScottK> DktrKranz: MOTU Meeting is more about policy/process that picking bugs to fix.
[04:54] <persia> DktrKranz: Probably not.  We certainly need to get as many of those fixes in as possible (in at least a few cases I've reviewed, we already have), but it's the packages that have never been merged for gutsy that are a little more annoying now (although in at least one case, I hope the merge will not be required).
[04:55] <DktrKranz> ok
[04:55] <persia> DktrKranz: You might also want to compare the outstanding "upgrade" bugs with http://people.debian.org/~lucas/ubuntu-versions/unimultiverse-all.html, to see if there are good targets.
[04:56] <persia> And, just in the spirit of pointing at useful URLs, http://alt.qeuni.net/~william/debcheck/ shows packages with problems that would like to be fixed :)
[04:57] <DktrKranz> ah, good
[04:58] <persia> Lastly, https://wiki.ubuntu.com/MOTU/TODO has a list of other tasks, for those still looking for something to do...
[04:58] <superm1_> ScottK, I created a bug re: LGPL v3, (bug 126565) along with a debdiff to fix it.  Once i get someone from core-dev to ack it, i'll let you know and libhdhomerun can then be uploaded
[04:58] <ubotu> Launchpad bug 126565 in base-files "LGPL v3 is not included" [Undecided,Confirmed]  https://launchpad.net/bugs/126565
[04:58] <ScottK> probably not until after tribe 3 releases.
[04:59] <persia> superm1: For now, it's probably better to just include the license.  base-files bugs tend to take a while....
[04:59] <superm1_> oh okay.  
[04:59] <superm1_> i guess they *do* affect lots of people :)
[04:59] <persia> Just a few )
[05:00] <hroo772> hey i dont know if anyone here would be able to answer this
[05:00] <hroo772> but i have a new server which i would allow some people to build packages on
[05:00] <hroo772> is there a way to have that setup for people possibly
[05:03] <persia> hroo772: I recommend setting up an sbuild or pbuilder environment, and allowing ssh access based on some external keyring.
[05:04] <persia> hroo772: Alternately, you can configure an ftp server, set up a cron job to automatically call sbuild or pbuilder, and put the results somewhere accessible on a webserver.  It really depends on your audience.
[05:05] <persia> hroo772: Also, I want to be able to use it :)  I'm hoping you have a different architecture than I.
[05:05] <hroo772> well i setup an amd64 server
[05:06] <hroo772> its got 2 dual core fx-74's
[05:06] <hroo772> so 4 processers overall
[05:06] <persia> elektranox: Looking through this more carefully, you'll need to regenerate doc/gafix.pdf in the build.  Is this something you can hit quick, or do you want a patch?
[05:06] <persia> hroo772: Ah.  Not so useful for me then, but likely useful for others.
[05:07] <DktrKranz> persia: if you want, I can give ssh access to our simple i386 build machine
[05:07] <hroo772> persia: well alright, are there any guides on getting one of those envoriments setup properly
[05:07] <persia> DktrKranz: Access to a i386 chroot saves my configuration, so thanks.  Grab my key from LP.
[05:07] <elektranox> persia: I always use the gedit latex plugin for working with latex... Is there some default package for compiling it?
[05:08] <persia> hroo772: Sorry, no idea (I've never seen one).
[05:08] <DktrKranz> persia, it is a simple one, and requires only a ssl key, do you have one?
[05:08] <persia> elektranox: I'm not sure.  I'll hunt one, and send you a patch (unless anyone has any suggestions?)
[05:08] <persia> DktrKranz: Yep.  ~persia on LP.
[05:09] <DktrKranz> ok. you'll have to use dput to upload, but I think you are familiar with it :)
[05:09] <persia> DktrKranz: Ah.  ssl, rather than ssh.  Sorry., no.  Thanks anyway.
[05:10] <DktrKranz> persia: I think the one you have in your profile is sufficient, I'll do some tests
[05:11] <DktrKranz> and I let you know
[05:11] <persia> DktrKranz: Thanks.
[05:12] <ScottK> superm1_: One nit.  Which version of the LGPL is your packaging licensed under?
[05:13] <superm1_> ScottK, by the way i wrote it, i was assuming the "current" version
[05:14] <ScottK> OK.  By the way I read it, I thought it meant any version.
[05:15] <superm1_> well better yet, I word it as  "also licensed by the GPL"  so it would assume the same version of the package
[05:15] <superm1_> er s/GPL/LGPL/
[05:16] <ScottK> It's not a problem, but it might be better to be explicit (a thought for your next upload).
[05:16] <superm1_> right.  
[05:16] <persia> elektranox: I can't build a pdf from that tex with either pdftex or pdflatex.  Could you take a deeper look, and try to get something working with pdflatex?  I'll take another look on REVU tomorrow.
[05:17] <ScottK> superm1_: Looking now.
[05:18] <elektranox> persia: I'll do so. AFAIK the gedit plugin is using pdflatex... strange that it's not working. I'll release a new upstream version and a new version in the revu later
[05:18] <elektranox> I'm just fixing the one warning which appears when compiling.
[05:19] <persia> elektranox: OK.  I've a couple other minor nits.  Shall I upload a new rev based on the last, and you can grab them from the debdiff?
[05:21] <elektranox> persia: you're talking about the dynamic pdf creation patch?
[05:22] <persia> elektranox: No - that would take me time, and I'd need to be more awake :)  Just to fix a linda warning, and actually install the PDF.  Should be completely parallel to the stuff you've been working on.
[05:23] <elektranox> ok just upload it to the revu :)
[05:23] <persia> elektranox: OK.  You probably don't want the whole thing, but the debdiff should be useful.
[05:23] <elektranox> ok
[05:24] <ScottK> superm1_: Uploaded.
[05:24] <superm1_> thx ScottK appreciate it
[05:26] <ScottK> superm1_: No problem.  Thanks for your contribution.  BTW, publisher is on manual until after Tribe 3, so it may be a bit before you see it.
[05:29] <persia> elektranox: Also, you'll want an upstream ChangeLog :)
[05:30] <elektranox> persia: I'll write one with this version
[05:31] <persia> elektranox: Great.  Thanks.  That plus the PDF generation should fix everything, and getting the Makefile stuff upstream should mean it's good for other distros as well.
[05:35] <elektranox> persia: I'll include a fix checking the existence of the glade file
[05:35] <persia> elektranox: http://revu.tauware.de/details.py?upid=6062
[05:36] <persia> elektranox: That sounds good.  Anything else small is probably good.  Larger things are probably better left to your regular schedule.
[05:49] <ScottK> dholbach: Which libhdhomerun did you upload?
[05:49] <dholbach> the one that was linked in the bug report
[05:50] <superm1> ScottK, if dholbach uploaded the one with the reference to LGPL-3, it should still be okay - keescook acked  bug 126565 and it will be fixed right after tribe-3
[05:50] <dholbach> let's see which LP will reject
[05:50] <ScottK> OK.
[05:50] <dholbach> yeah
[05:50] <ubotu> Launchpad bug 126565 in base-files "LGPL v3 is not included" [Undecided,Fix committed]  https://launchpad.net/bugs/126565
[05:51] <persia> ScottK: Please update the bug when uploading upgrade requests.
[05:51] <ScottK> persia: I marked it Fix Comitted.  What else should I have done?
[05:51] <persia> ScottK: Hm.  Nothing.
[05:52] <persia> dholbach: Please update the bug when uploading upgrade requests
[05:52] <dholbach> persia: update in what way?
[05:52] <persia> dholbach: Assign yourself when reviewing, set "Fix Committed" when uploading.
[05:52] <dholbach> I did that
[05:52] <dholbach> which one are we talking about?
[05:53] <ScottK> libhdhomerun
[05:53] <superm1> it just looks like at the same moment both of you guys had changed it before refreshing the other's changes
[05:53] <persia> dholbach: ScottK: My apologies.  I hoped the bug would prevent conflicts, but apparently I'm mistaken.  Thanks to both of you.
[05:54] <dholbach> https://bugs.launchpad.net/ubuntu/+source/libhdhomerun/+bug/126420/+activity
[05:54] <ubotu> Launchpad bug 126420 in libhdhomerun "New upstream version" [Undecided,Fix released]  
[05:55] <persia> Aha!
[05:55] <persia> superm1: Please be sure to unassign yourself, and not leave the bug "In Progress" when requesting sponsorship.
[05:55] <persia> ScottK: Please unsub the sponsors, assign yourself, and set In Progress when you start reviewing
[05:56] <superm1> i was about to do so, when ScottK offered to revu it actually
[05:56] <superm1> and then forgot to do so
[05:56] <persia> dholbach: That's perfect.  Thanks.
[05:56] <ScottK> I really, the more I think about it, think we should either use REVU for this or give up on REVU entirely.
[05:56] <ScottK> Two places is double the tracking work.
[05:57] <persia> ScottK: Do you have another suggestion for a good dget'ble place for contributors to put new upstreams?  pitti holds the same opinion as you regarding this, but I can't think of another good place to put the packages.
[05:57] <ScottK> No.  My vote would be keep using REVU.
[05:58] <persia> Separately, I think REVU still works for NEW packages.
[05:58] <superm1> perhaps to ppa's instead?
[05:58] <superm1> and link to those
[05:58] <persia> superm1: Still not ready, but that's a very strong candidate.
[05:58] <ScottK> Personally, I don't understand what problem all this change is trying to solve.
[05:59] <persia> ScottK: Part of the trick is to make sure we're providing good feedback to the original bug submitter who requested an upgrade.
[06:00] <ScottK> If the upgrade was requested via LP, then whoever packages the upgrade should just put (LP: #whatever) in the changelog and be done with it.
[06:00] <superm1> and then not use u-u-s at all?
[06:00] <persia> ScottK: 1) Reduction of duplicated work (two people, two times, etc.), 2) Reduction of lost work (or just forgotten), 3) reduced sponsor response time, 4) Ease of access for contributors, and 5) improved Ubuntu
[06:00] <ScottK> Unless someone is going back and statusing all the please upgrade X bugs for stuff that gets autosync'ed LP will be wrong more than right no matter what we do.
[06:01] <ScottK> OK.  I don't see how double tracking in LP helps any of that.
[06:02] <ScottK> Doing/tracking work in one and only one place makes sense.
[06:02] <ScottK> Until there is a complete solution to not use REVU, then we should use REVU and only REVU IMO.
[06:02] <persia> ScottK: I don't know about you, but I check the U-U-S queue much more often than I look at REVU, and have a different understanding of what I'm doing at the time.  If something is in queue, I'm likely to upload unless there is a significant issue.  If something is on REVU, I'm likely to nitpick about everything.
[06:03] <ScottK> Well if it's on REVU and it's got a comment that says "Existing package, new upstream version..."  That solves that.  I find out about stuff on REVU primarily via Emali.
[06:03] <ScottK> Email/email.
[06:04] <persia> Also, as a contributor, I found the REVU process for a new upstream very painful, and was asked to mail the diff -urN of debian/ to three different sponsors before it was uploaded (with no changes).  Using LP to track that makes it easier to get that attachment.
[06:04] <ScottK> Sounds like a good feature for REVU to add.
[06:05] <ScottK> I agree that's very helpful.
[06:05] <ScottK> But once again, IMO, double status tracking is a killer.
[06:06] <persia> ScottK: I completely agree about the double status tracking, and believe it to be very temporary, until we have somewhere else to upload things.  I encourage people to cross link URLs in the comments in both places, but that's not always enough.
[06:06] <ScottK> I think that the process shouldn't have been changed until it didn't add to MOTU workload.
[06:08] <dholbach> there have always been bug reports about updating stuff
[06:08] <dholbach> and always been package on REVU
[06:08] <dholbach> no process has been changed
[06:09] <dholbach> we just seem to have more contributors now and it shows that the process is broken
[06:09] <dholbach> I think that both are good things
[06:09] <persia> My memory of the old process (which I followed for gnome-phone-manager 0.7 or something) was that we uploaded the .dsc, .orig.tar.gz, .diff.gz, and diff -urN debian/ to the bug report, but there were complaints that the attachments were too large.
[06:10] <ScottK> OK.  I'm not a process guy.  Let me know when I can worry about one and only one place and not get beat up for not updating the other one even though I did.  
[06:10] <persia> dholbach: I'm certain there's been a process change for this :)
[06:10] <dholbach> ScottK: I'm not happy about the process situation either
[06:10] <persia> ScottK: Sure.  Sorry for the confusion in the meantime, and thanks for your patience.
[06:10] <dholbach> I fully agree with you on that
[06:15] <zul> any progress on the sru team stuff?
[06:16] <Hobbsee> sru team, or uvf?
[06:16] <zul> yeah uvf
[06:16] <zul> :)
[06:17] <Hobbsee> there were a bunch of people who put their names in, no one's elected yet
[06:18] <persia> Are we supposed to be voting yet, or waiting for more nominations?
[06:19] <Hobbsee> nominations should still be open
[06:20] <dholbach> yeah - let's wait until tomorrow or the day after that, then I can set up polls for all nominees
[06:20] <dholbach> I'm quite happy we got some nominations already
[06:20] <dholbach> alright
[06:20] <dholbach> see you tomorrow
[06:22] <highvoltage> what does this mean?
[06:22] <highvoltage> dh_clean -k -i 
[06:22] <highvoltage> dh_clean: I have no package to build
[06:22] <highvoltage> make: *** [install-indep]  Error 1
[06:22] <highvoltage> debuild: fatal error at line 768:
[06:23] <highvoltage> it builds the packages fine, but then says that
[06:23] <superm1> highvoltage, do you have any architecture independent parts to the package?
[06:24] <superm1> or are they all compiled for a particular architecture
[06:26] <ScottK> persia: Are you running AMD64?
[06:26] <persia> ScottK: Yep.  ClamAV backporting is far enough along you need a bunch of stuff compiled?
[06:27] <ScottK> No.  I saw Bug #126204 and thought you might find it an interesting challenge.
[06:27] <ubotu> Launchpad bug 126204 in Ubuntu "Batch jobs intermittently fail to leave "="queue when complete" [Undecided,Incomplete]  https://launchpad.net/bugs/126204
[06:29] <eagles0513875> anything i can help you guys with
[06:30] <highvoltage> superm1: some are compiled for i386
[06:31] <highvoltage> sorry for delay in response
[06:31] <superm1> but you don't have any that are going into a "all" package (as  described in debian/control)?
[06:31] <persia> ScottK: That is indeed interesting.  I'll see if I can find a low-CPU test case for it.  Thanks for the pointer.
[06:31] <ScottK> You're welcome.
[06:32] <persia> eagles0513875: https://launchpad.net/ubuntu/+bugs?field.tag=bitesize is a good place to start.
[06:34] <eagles0513875> ty persia
[06:34] <eagles0513875> persia: on my problem i dont even know where to begin
[06:34] <eagles0513875> i dont even know where to begin there either
[06:34] <Hobbsee> pick one
[06:35] <elektranox> is there an englisch word for this character: ^
[06:35] <persia> caret
[06:35] <elektranox> ty
[06:36] <eagles0513875> ok Hobbsee
[06:39] <geser> Hobbsee: Hi, do you perhaps know if it's possible for a package in PPA to build-depend on another package from PPA?
[06:39] <Hobbsee> geser: that's the idea, i believe
[06:39] <Hobbsee> geser: i'm assuming it actually does
[06:45] <eagles0513875> Hobbsee: when i pick a bug do i look at the new ones
[06:47] <eagles0513875> now that ive chosen a bug whats next lol
[06:51] <persia> eagles0513875: Fix it :)
[06:52] <eagles0513875> lol
[06:52] <eagles0513875> i dont now jack about programming
[06:52] <eagles0513875> i will only make it worse lol
[06:57] <xtknight> when i want to see if a debian upstream package has the same problem, should i be going with sarge, woody, sid, etch?  im confused
[06:57] <ScottK> Sid
[07:05] <LucidFox> xtknight> Ubuntu syncs packages from Debian unstable
[07:05] <xtknight> LucidFox, ScottK: thanks
[07:05] <ScottK> Sid == Unstable.
[07:05] <xtknight> yea
[07:05] <xtknight> when i report the debian also, what should be in my changelog?  say the last version of the package is 0.4.8-3.  the one i report the ubuntu is 0.4.8-3ubuntu1, and the one to debian will be what, 0.4.8-4?
[07:26] <eagles0513875> where would any mention of flac be in the amarok source
[07:26] <xtknight> eagles0513875, sorry i don't understand the question?
[07:26] <xtknight> which bug are you working on?
[07:29] <eagles0513875> one of my own
[07:29] <xtknight> eagles0513875, have you reported it to LP (LaunchPad)? could you specify the number?
[07:30] <eagles0513875> no only to kde
[07:30] <eagles0513875> ever since i upgraded to kde 3.5.7 in gutsy i have all my audio in flac and amarok is version 1.4.6 and for some reason with all my audio in amarok it intermittently cuts in and out throughout all the songs
[07:30] <eagles0513875> the audio will play in exaile
[07:34] <xtknight> eagles0513875, i believe amaroK uses the gstreamer playback engine.  does another app, such as banshee, cupid, goobox, rhythmbox, totem have the same problem?
[07:34] <eagles0513875> im using exaile the amarok knock of
[07:34] <eagles0513875> let me download them
[07:35] <xtknight> okay well exaile is gstreamer also i guess
[07:35] <xtknight> if that works and amarok doesntt, then it's an amarok specific problem
[07:39] <elektranox> should I write the packages changelog into the debian/changelog or just "Initial release"
[07:40] <eagles0513875> xtknight: its workikng in banshee
[07:40] <xtknight> eagles0513875, ok can you link to the kde bug # for reference?
[07:41] <eagles0513875> ok ill make one now
[07:41] <xtknight> eagles0513875, well if you're reporting it report it to launchpad 
[07:42] <xtknight> i think they will also report it to kde if needed
[07:43] <eagles0513875> xtknight: what is the name of the gstreamer pkg
[07:43] <xtknight> eagles0513875, since other gstreamer packages works, that's not where the bug lies.  for now you should specify amarok
[07:43] <eagles0513875> ok
[07:45] <eagles0513875> https://bugs.launchpad.net/ubuntu/+source/amarok/+bug/126598
[07:45] <ubotu> Launchpad bug 126598 in amarok "ever since i upgraded to kde 3.5.7 in gutsy i have all my audio in flac and amarok is version 1.4.6 and for some reason with all my audio in amarok it intermittently cuts in and out throughout all the songs" [Undecided,New]  
[07:46] <eagles0513875> there u go xtknight
[07:47] <xtknight> eagles0513875,  ok you may want a more brief title such as "[gutsy]  amarok cuts out during flac playback".  you can always put more info in the description.
[07:47] <eagles0513875> ok
[07:47] <eagles0513875> i just copied and pasted from what i had in here
[07:48] <xtknight> eagles0513875, so, you think you know how to fix this then?
[07:48] <eagles0513875> no
[07:48] <eagles0513875> lol
[07:48] <eagles0513875> im a noob when it comes to debugging that is why i was asking if u had any idea what file in the amarok source i should look under
[07:49] <xtknight> hmm well it uses the gstreamer framework, and the flac decoding stuff is in there AFAIK
[07:49] <xtknight> it's probably a higher level problem
[07:49] <xtknight> that happens with other files also
[07:50] <eagles0513875> i really need to learn c++ lol
[07:51] <xtknight> well you should probably compare the feisty package to the gutsy one and see what changed.
[07:51] <xtknight> if the feisty one worked
[07:51] <eagles0513875> should i download the feisty source
[07:51] <xtknight> yea
[07:52] <eagles0513875> what repository
[07:52] <xtknight> eagles0513875, goto http://packages.ubuntu.com
[07:52] <xtknight> enter Feisty, enter 'amarok' and then at the bottom of the Amarok page it provides three files you need for the source
[07:52] <xtknight> make a new local folder and download these three files to that folder.
[07:52] <xtknight> Source Package: amarok, Download: [dsc]  [amarok_1.4.5.orig.tar.gz]  [amarok_1.4.5-0ubuntu7.diff.gz]  
[07:52] <eagles0513875> ?
[07:53] <eagles0513875> i did a clean install though
[07:53] <xtknight> huh?
[07:53] <elektranox> O_o
[07:54] <eagles0513875> do u mean use source o matic
[07:54] <eagles0513875> and add the repository to the list of repositories i have
[07:55] <xtknight> eagles0513875, huh?
[07:55] <xtknight> eagles0513875, hmm no no just go to that website
[07:55] <eagles0513875> the amarok website
[07:56] <xtknight> http://packages.ubuntu.com
[08:00] <xtknight> eagles0513875, sorry, i'm going to have to reboot.  but make sure you edit the name of your bug so that it's more brief. that's  a good first step
[08:01] <xtknight> eagles0513875,  if you don't know how to fix it, that's fine.  the next step is to get others to confirm this bug.  ask around maybe, get them to add comments to LP.  that way, the bug will get more attention
[08:02] <eagles0513875> ok ive been asking round and it seems like its only me
[08:02] <eagles0513875> could it be that im running the 64bit version
[08:02] <xtknight> eagles0513875, it sure could be
[08:02] <xtknight> maybe it only affects 64bit
[08:03] <eagles0513875> thats what im wondering
[08:03] <eagles0513875> and i forgot to mention that in the bug
[08:03] <xtknight> that you're the only one having a problem doesn't mean there's not a bug.  it could be conflicting with some other package that you have installed, or maybe one of the components in your system doens't like amarok
[08:03] <eagles0513875> xtknight: how could i check if there is conflicting pkgs
[08:03] <xtknight> eagles0513875,  people may stop by and see your bug report and ask you to provide details to help track down the problem.
[08:04] <xtknight> eagles0513875, you could try playing the flac on a Gutsy LiveCD, pure clean install
[08:04] <eagles0513875> but if it works with other audio players
[08:04] <xtknight> then yes it's a bug with amarok but you still need to find out why amarok has a problem
[08:04] <eagles0513875> one thing i can tell u for sure is that this didng hapapen in kde 3.5.6
[08:05] <xtknight> you need to isolate the problem, determine the conditions under which it occurs, and then report those conditions to the Launchpad
[08:05] <eagles0513875> only when i upgraded to 3.5.7
[08:05] <xtknight> ok that should be in the report
[08:05] <xtknight> say there is no problem with 3.5.6
[08:05] <xtknight> do you know how to edit your report?
[08:06] <eagles0513875> ya
[08:06] <xtknight> ok i'll be back in a while..maybe 30 mins installing new HW
[08:06] <elektranox> nevertheless you should test it with a Gutsy Live-CD. Then you will know, that the problem occurs with default configuration
[08:07] <eagles0513875> ok
[08:07] <eagles0513875> besides that is there a command to run where i can check to see if all dependencies r met
[08:09] <eagles0513875> im going ot try compile it from source again
[08:10] <tuxmaniac> How do we inform/intimate Debian if a package is available in Ubuntu and not in Debian?
[08:12] <elektranox> eagles0513875, if the dependencies of the package are not met dpkg/apt would tell you
[08:15] <eagles0513875> ok elektranox would a log in the source folder tell u anything
[08:18] <elektranox> eagles0513875, perhaps, but probably not because I never used Amarok, so I don't know much about it
[08:18] <eagles0513875> ill take it into the amarok channel
[08:22] <eagles0513875> anyone know much about amarok in here
[08:22] <eagles0513875> the amarok channel is dead
[08:28] <fernando> the archive version of straw package is 0.26.dsfg.1-2.1ubuntu1, now exists the straw 0.27. How will be the version? 0.27.dsfg.1-0ubuntu1 ?
[09:26] <ScottK> fernando: Is it Debian yet?
[09:27] <fernando> ScottK, no
[09:27] <ScottK> OK.  Unless upstream has removed the non-free parts that caused Debian to repack the tarball, then yes.
[09:28] <ScottK> Is there any great reason not to wait for Debian on straw?
[09:31] <fernando> ScottK, no, i can wait. thanks
[10:59] <xxxxx1> bye all
[11:10] <tretle_> http://ubuntuforums.org/showthread.php?t=484251
[11:11] <tretle_> this points to a thread originally intending to ask whether PalmOS synchronization should be replaced with Mobile phone synchronization
[11:12] <tretle_> the discussion progressed and it became clear that conduit would be a better solution for synchronization on ubuntu in the near future
[11:13] <tretle_> it currently doesn't support mobile phones or PalmOS devices but it is built of opensync so it is in the plans for the project in the future
[11:13] <tretle_> Conduit should replace the PalmOS synchronization
[11:13] <ajmitch> yes, you were just saying this earlier in #ubuntu-devel
[11:14] <tretle_> PalmOS is as good as dead
[11:14] <tretle_> yes I was told to say it here :D
[11:14] <ajmitch> it's also not a matter of packaging new software, but getting it from debian
[11:15] <evand> ajmitch: that's my fault, I didn't see that it was already in Debian.
[11:15] <ajmitch> evand: it's only been in debian for a few days
[11:16] <evand> ah, then I'm off the hook :)
[11:16] <ajmitch> but I believe a sync request was already filed, etc
[11:17] <ajmitch> let me check my mega-bugmail folder
[11:22] <xtknight> i determined that a bug also affected upstream.  is this how much launchpad entry should look?  https://bugs.launchpad.net/debian/+source/freetennis/+bug/126490
[11:22] <ubotu> Launchpad bug 126490 in freetennis "freetennis manual page has a poor description, and lists an incorrect URL" [Undecided,Fix released]  
[11:23] <xtknight> s/how much/how my*
[11:25] <ajmitch> yes, it'll be unknown until the bug watcher goes & retrieves the statuses for debian bugs again
[11:25] <ajmitch> when you say upstream, what do you mean?
[11:26] <xtknight> ajmitch, i mean debian sid
[11:28] <xtknight> what's the difference between (upstream) and (Debian) though?
[11:28] <ScottK> tretle_ and ajmitch: conduit needs evolution-python.  I asked for a sync of that, but it'll have to go through NEW first.  The first evolution-python released got rejected due to licensing issues.
[11:28] <xtknight> i notice some bugs say (upstream)?
[11:28] <ajmitch> upstream means the original author
[11:29] <xtknight> ahh
[11:29] <xtknight> like his sourceforge pkg?
[11:29] <ajmitch> yes
[11:29] <ajmitch> though we can refer to debian as 'upstream' in a sense, it's generally used to mean the origin
[11:30] <ajmitch> ScottK: good to know, though I doubt I'll use it for awhile, at least until my phone becomes useful :)
[11:30] <xtknight> if you did find the origin to also have problems, how would you mark it upstream?  
[11:31] <xtknight> oh it has to be a project under launchpad apparently.  if it is not, then you can't?
[11:31] <ajmitch> the upstream project would need to be registered in ubuntu, which is quick but irritating
[11:31] <ScottK> Right.
[11:31] <ajmitch> s/ubuntu/launchpad/
[11:31] <ajmitch> too early in the morning
[11:34] <fernando> how to remove the upstream affects in launchpad?
[11:35] <ajmitch> I doubt that you can
[11:44] <ScottK> fernando: You can't.
[11:44] <fernando> ajmitch, ScottK thanks
[11:46] <AndyP> hey folks
[11:46] <fernando> hey AndyP 
[11:48] <ScottK> Heta welshbyte, AndyP, whoever you are...
[11:48] <ScottK> Heta/Heya
[11:48] <AndyP> ScottK: heh, it's permanently AndyP now, just have to remember to ask about getting my cloak changed
[11:50] <ajmitch> AndyP: changed your launchpad id?
[11:51] <AndyP> ajmitch: my lp id was always andy-price
[11:52] <ajmitch> ok
[11:54] <alexr> Hi there
[11:54] <alexr> Anybody can help with resolving a gtkspell bug?
[11:54] <alexr> The issue is present in Gutsy, but not in Debian
[11:54] <alexr> https://bugs.launchpad.net/ubuntu/+source/gtkspell/+bug/120569
[11:54] <ubotu> Launchpad bug 120569 in gtkspell "[gutsy]  gtkspell segfaults when trying to set the language on gtk.TextView" [High,Confirmed]  
[11:56] <ScottK> alexr: sudo apt-get install kubuntu-desktop is one solution ;-)
[11:56] <ScottK> Sorry, on my way out the door.
[11:57] <alexr> ScottK: thanks, I'm a debian person
[11:57] <ScottK> Ah.
[11:57] <alexr> It's just that I'm an upstream devel for gramps
[11:57] <ScottK> I see.
[11:57] <alexr> and this bug is crashing gramps
[11:57] <alexr> but the bug is not gramps related
[11:58] <ScottK> Right.  I think I remember that being discussed before.
[11:58] <alexr> the report demonstrates that grkspell module in python crashes, with the short script
[11:58] <alexr> Somehow it works fine in debian
[11:58] <ScottK> I agree that it's not gramp's fault, but OTOH, gramps shouldn't crash if a program it does misbehaves.
[11:58] <alexr> and gtkspell in debian has +b1 in its version number
[11:58] <alexr> ScottK: what do you mean, should not crash?
[11:59] <alexr> a statement segfaults python
[11:59] <ScottK> Ah
[11:59] <ScottK> That's right.
[11:59] <alexr> how can gramps help it?
[11:59] <alexr> The debian had this problem some time ago
[11:59] <ScottK> I expect (from my vague recollection of the discussion) that it seemed to me likely a Python 2.4/2.5 thing.
[11:59] <alexr> and their version is:
[11:59] <alexr> ii  libgtkspell0                     2.0.10-3+b1                     a spell-checking addon for GTK's TextView wi
[11:59] <alexr> The Gutsy version is 2.0.10-3
[11:59] <ScottK> Right, that's just a rebuild.
[12:00] <alexr> So I am guessing they patched it
[12:00] <alexr> Oh
[12:00] <alexr> What's the +b1 thing?
[12:00] <ajmitch> yay for binNMUs
[12:00] <nixternal> permission to take a break?
[12:00] <ScottK> Denied.
[12:00] <nixternal> damn
[12:00] <ScottK> There will be no liberty until morale improves.
[12:00] <ajmitch> alexr: binary rebuild
[12:00] <nixternal> ScottK: morale around here is great, and if it isn't, make um walk the plank!
[12:01] <nixternal> scallywags!
[12:01] <alexr> ajmitch: I see
[12:01] <ajmitch> so, test gtkspell with gutsy, see if it breaks - if so, rebuild & test again
[12:01] <ScottK> alexr: I'd see if you can convince gtkspell to run with Python 2.5 in Debian and I predict you'll see the same.
[12:02] <alexr> ScottK: so you think this is a gtkspell issue?
[12:02] <alexr> Or a python issue?
[12:02] <ScottK> Dunno.  
[12:02] <alexr> But we need gtkspell guys to take care of that
[12:02] <alexr> I can't hack on the code I don't know :-)
[12:02] <ScottK> I'm thinking Python 2.5 + gtkspell.
[12:02] <alexr> and it's easy to demonstrate the crash
[12:02] <ScottK> But you can at least narrow it down.
[12:03] <alexr> I guess I"ll just go to their list and yell there
[12:03] <ScottK> Crashes on Python 2.5, doesn't crash on Pytnon 2.4 is a lot more helpful than crashes on Ubuntu, but not Debian.
[12:03] <dallingham> Actually, this does not occur under Feisty, which is python 2.5 as well.
[12:04] <ScottK> The Ubuntu Python will segfault if the interpreter gets called more than once.
[12:04] <ScottK> OK.  Well that helps narrow it down then.  It's probably not a Python 2.5 compatibility issue.
[12:05] <alexr> So what do you suggest we do?
[12:05] <dallingham> possibly pygtk? 
[12:05] <ScottK> The other alternative is to see if you can get doko's attention as he's the Python guru for both Debian and Ubuntu.
[12:06] <ScottK> I don't recall.  Since I just use KDE, I only expended a very limited number of brain cells on the problem.  Sorry.
[12:06] <alexr> doko: are you around by any chance?
[12:06] <ScottK> I do have to run and play Daddy for a while, so good luck and I'll see you all later.
[12:06] <alexr> thanks
[12:06] <doko> alexr: no, falling asleep. please submit a bug report, I'll look at it tomorrow
[12:07] <alexr> Already submitted
[12:07] <alexr> doko: how do we assign it to you?
[12:07] <alexr> https://bugs.launchpad.net/ubuntu/+source/gtkspell/+bug/120569
[12:07] <ubotu> Launchpad bug 120569 in gtkspell "[gutsy]  gtkspell segfaults when trying to set the language on gtk.TextView" [High,Confirmed]  
[12:07] <doko> alexr: just subscribe me
[12:07] <alexr> what's your handle at launchpad?
[12:07] <ScottK> alexr: I'll do it.
[12:08] <alexr> thanks!
[12:08] <ScottK> Done