[00:00] <ari-tczew> how can I drop dependcy on file *.1 in /debian/ directory?
[00:00] <ari-tczew> I use debhelper 7
[00:01] <sistpoty> ari-tczew: define dependency? is debian/rules looking for a manpage there?
[00:02] <ari-tczew> sistpoty: my debian/rules: http://paste.ubuntu.com/484702/
[00:03] <ari-tczew> I wouldn't use .1 file
[00:03] <sistpoty> ari-tczew: maybe a build log with the error might shed more clue?
[00:04] <sistpoty> (as in, I don't know from the rules file alone)
[00:07] <ari-tczew> sistpoty: http://www.plikos.pl/19k4/last_operation.log.html
[00:07] <ari-tczew> sistpoty: better link: http://s1.plikos.pl/19k4/394cdc39e8e89bf8524d81d9c7bab073/last_operation.log
[00:08] <ari-tczew> sistpoty: I removed .1 file in the past
[00:09] <sistpoty> ari-tczew: I can't parse the output on the page (there are pictures and text in a language I don't speak)... maybe pastebin might be helfpul?
[00:10] <ari-tczew> sistpoty: did you used second link?
[00:10] <sistpoty> ari-tczew: both :)
[00:11] <ajmitch> chromium has a nice translate feature that helps there :)
[00:11] <ari-tczew> sistpoty: second link connect directlu to file
[00:11] <ari-tczew> directly*
[00:11] <ajmitch> ari-tczew: it probably depends on the http referrer being set, so when we go to it, it doesn't link directly
[00:11] <sistpoty> ari-tczew: nope, not for me at least
[00:12] <ajmitch> do you have a clementine.manpages file in debian/ ?
[00:12] <ari-tczew> sistpoty: I cannot use pastebin or something similiar, because this file is large
[00:12] <ajmitch> it's only the last few lines you need to pastebin
[00:12] <sistpoty> hey ajmitch btw
[00:12] <ajmitch> hi :)
[00:12] <ari-tczew> ajmitch: debian/manpages has got: debian/clementine.1
[00:12] <ari-tczew> but I deleted file debian/clementine.1
[00:12] <ajmitch> ok
[00:13] <ajmitch> so delete it from debian/manpages?
[00:13] <ari-tczew> ajmitch: hmmm..
[00:13] <ari-tczew> I'll try, but what next? package without manpage?
[00:13] <ajmitch> why did you delete the manpage?
[00:14] <ari-tczew> ajmitch: because I think that management this file is not easy. strange chars like \fB\-a\fR, \fB\-\-append\fR
[00:14] <ari-tczew> o_O
[00:15] <ari-tczew> is there any easier way to create manpage?
[00:18] <ajmitch> there are some tools like help2man to get it started, but the markup isn't that bad?
[00:22] <ari-tczew> ajmitch: I'm preparing a package for REVU. I'm merging 2 proposed packages - from one guest and upstream developer. Upstream's package doesn't include manpages. what do you think, is manpages necessary for music player?
[00:25] <ajmitch> I personally don't care about manpages for X apps when they've got basically no commandline options, but I think others may disagree with me on that
[00:26] <ari-tczew> aha
[00:27] <micahg> ajmitch: they have their uses unless the app has built in cli help for debugging
[00:27] <micahg> *options
[00:27] <ajmitch> I guess in the case of a music player, they can often be called with arguments like  --next, etc to skip tracks
[00:28] <sistpoty> ajmitch: I disagree, since I've seen to many strange apps in /usr/bin which don't give any help when called with --help and aren't obvious what these do
[00:29] <sistpoty> (hello kde things btw.)
[00:29] <ajmitch> sistpoty: right, but does having a manpage help in any way apart from having a description of them?
[00:30] <sistpoty> ajmitch: having a description would alread be something I'd been looking for
[00:30] <ajmitch> ari-tczew: as evidenced - others disagree with me :)
[00:31] <sistpoty> haha
[00:31] <sistpoty> ajmitch, ari-tczew: if it's evident what an application does, I don't think a man page is too much of a need though
[00:33] <ari-tczew> ajmitch, sistpoty: ok, I'll think about include .1 file.
[00:33] <ari-tczew> now other question: is possible to add 2 maintainers to one field?
[00:34] <ari-tczew> it's new package, only in Ubuntu
[00:34] <sistpoty> (as a side note, jsut to blame ajmitch, /usr/bin/ck-launch-session is not obvious to me (as seen on a debian/stable installation) :P)
[00:35] <ajmitch> sistpoty: it's perfectly obvious to me :)
[00:35] <sistpoty> haha
[00:35] <ajmitch> ari-tczew: no, I think the Maintainer field must be one name/email only - Uploaders can contain multiple
[00:36] <ari-tczew> ok
[00:43] <ari-tczew> ajmitch: thanks, deleting .1 file from debian/manpages helped me
[00:44]  * persia strongly encourages the creation of manpages for GUI apps.  That makes it appear nicely for tools like apropos.  It also lets the user have one consistent way to ask for documentation (which might just be an explanantion of the binary, and no options).
[00:45] <ari-tczew> I have support windows in tarball. should do I delete all files related to windows, or delete only .dll file? I'm thinking about source-contains-prebuilt-windows-binary
[00:50] <sistpoty> ari-tczew: I'd even suggest to delete windows binaries straight from the tarball (you can't be sure that the dlls match the source)
[00:51] <ari-tczew> sistpoty: so you suggest repack tarball. do I need to change versioning to dfsg?
[00:51] <sistpoty> ari-tczew: would be good, yes
[00:54] <sistpoty> damn, persia: you seem to have driven ajmitch away.... .o_O
[00:55]  * ajmitch is in hiding :)
[00:55] <sistpoty> haha
[00:55] <ajmitch> or just doing other stuff right now
[01:02] <ari-tczew> who know how bdrung check package? http://revu.ubuntuwire.com/details.py?upid=8210 he gave some lintian issues. I haven't it in pbuilder's log.
[01:03]  * persia recommends lintian -iIEv --pedantic foo_source.changes foo_${arch}.changes : not everything here needs fixing, but it all needs thinking about
[01:05]  * ari-tczew sometimes thinks that some people here knows everything about packaging
[03:02] <lfaraone> ScottK: would you approve Sugar FFes for syncs from NEW?
[03:35] <ScottK> lfaraone: I'd prefer after they are out of New since then I know they met Debian's requirements.
=== yofel_ is now known as yofel
=== bilalakhtar_ is now known as bilalakhtar
[10:25] <AnAnt> Hello
[10:25] <AnAnt> Hello
=== apache2logger is now known as apachelogger
[10:28] <AnAnt> how can I detect if the sound server on the system is pulseaudio or not ?
[10:35] <persia> AnAnt, Mostly we just assume it is.  What are you trying to accomplish?
[10:36] <AnAnt> persia: I am maintaining a package (zekr) in both Debian & Ubuntu
[10:37] <persia> Ah.  I see.
[10:37] <AnAnt> it is a java package, the problem is that Sun JRE has problems with pulseaudio
[10:37] <persia> So, what sort of ways *can* you output sound?
[10:37] <AnAnt> so I have to wrap the call to zekr using padsp
[10:37] <persia> Both Debian and Ubuntu recommend avoiding that.  Sun isn't supporting it much longer either :)
[10:37] <AnAnt> avoiding what ?
[10:38] <persia> using Sun JRE
[10:38] <Nafallo> persia: and when you say Sun, you mean Oracle, no? ;-)
[10:38] <AnAnt> well, there is a problem with OpenJDK too
[10:38] <persia> Nafallo, I didn't know Oracle ever committed to specific support periods for the JRE.  I'd be glad to be mistaken.
[10:39] <AnAnt> persia: zekr is using libbasicplayer-java to play audio
[10:39] <persia> That ought just work, regardless of the environment (kinda the point).
[10:39] <Nafallo> persia: I thought they had bought it all, I might be the one mistaken.
[10:39] <AnAnt> persia: it seems that libbasicplayer-java is using a method not supported by OpenJDK to control the volume (gain)
[10:39] <persia> If that fails to work, it's better to consider that a bug in the JRE
[10:39] <persia> Nafallo, I think they bought it all.  I just haven't personally been told any support periods for Java by anyone claiming to represent Oracle.
[10:40] <AnAnt> what out to just work ?
[10:40] <AnAnt> erm, I think I'm lost in the conversation
[10:40] <persia> libbasicplayer-java for audio out: it should generate audio for the user regardless of the user environment.  The application developer should not have to think about it.
[10:41] <persia> If it doesn't, that's a bug in the JRE (or JRE config), and should be fixed there, rather than in every application that uses libbasicplayer-java
[10:41] <AnAnt> persia: the audio playback works, it is modification of the output volume (setting the gain) that fails when pulseaudio is the system used
[10:42] <AnAnt> persia: the bug was filed against OpenJDK during lucid cycle I think
[10:42] <persia> OK.  Let's fix it.
[10:42] <persia> Working around it in zekr isn't the right solution.
[10:43] <AnAnt> let me see where it is then
[10:44] <AnAnt> http://stackoverflow.com/questions/1914216/master-gain-not-supported-in-openjdk
[10:45] <AnAnt> persia: look at the first comment in that URL ^
[10:46] <AnAnt> ah, here's the LP bug: #491784
[10:46] <ubottu> Launchpad bug 491784 in libbasicplayer-java (Ubuntu) "Sound does not work with openjdk" [Undecided,Fix released] https://launchpad.net/bugs/491784
[10:47] <AnAnt> it was first filed against OpenJDK, then when I made a patch in libbasicplayer-java to workaround the problem, doko reassigned the bug to libbasicplayer-java
[10:48] <persia> And uploaded it.
[10:48] <persia> Does your patch not work?
[10:49] <persia> Or does OpenJDK have a second, buggier, internal implementation of libbasicplayer-java?
[10:49] <AnAnt> the patch only catches the exception to make the program using libbasicplayer-java not to crash
[10:49] <persia> Ah.  "fixed the issue" wasn't clear on that point :)
[10:49] <AnAnt> I just added a try catch
[10:50] <persia> Whereas what it really needs is some closer work to make it do the right thing.
[10:52] <AnAnt> "it" refers to OpenJDK or libbasicplayer-java ?
[10:53] <AnAnt> as mentioned in the first URL I pasted, there are other playback problems with OpenJDK
[10:54] <AnAnt> for example in Zekr, if I press play, then stop. The program would crash
[10:54] <AnAnt> I should press pause before stop
[10:54] <AnAnt> I think that relates to "it insists that you stop() a line before flush()ing it."
[10:59] <persia> I think "it" is libbasicplayer-java, although one would have to traverse the implementation to determine that for sure.
[11:00] <AnAnt> be back later
[11:00] <persia> But I think the solution is either to patch the implementation to not break, or to patch zekr to respond to pressing "Stop" with stop();flush();
[11:01] <persia> To troubleshoot, I'd probably back out your crash, and then read the exception traces to figure out where it makes sense to change things so it behaves sensibly.
[11:01] <persia> Err, back out your patch.
[11:02] <persia> Alternately, zekr could trap the real exception (by name) and do something interesting.
[11:26] <ari-tczew> tumbleweed: around?
[11:30] <tumbleweed> ari-tczew: no, working on finishing touches to our pyweek.org entry
[11:30] <ari-tczew> aha
[12:11] <AnAnt> persia: do something interesting ?
[12:12] <persia> Sure.  Not crash, or call some handler to work around the observed issue, or attempt to do something with an alternate implementation, etc.
[12:18] <AnAnt> persia: hmm, but according to http://stackoverflow.com/questions/1914216/master-gain-not-supported-in-openjdk, it seems that the actual problem is in OpenJDK
[12:19] <persia> I don't think there's enough technical content in that discussion to know if it's OpenJDK or some library running by default on typical OpenJDK installations.
[12:40] <AnAnt> persia: do the errors in https://bugs.launchpad.net/zekr/+bug/622663 give good hints ?
[12:40] <ubottu> Launchpad bug 622663 in Zekr "Audio Player crashes on volume change" [Undecided,New]
[12:41] <AnAnt> persia: erm, nevermind
[12:44] <persia> AnAnt, They do, but the "...10 more" hides the bit that gets interesting.
[12:45] <persia> Anyway, the thing to do (to my mind) would be to add gain control support, which just makes the issue disappear (and makes everyone else happy).
[12:45] <AnAnt> and how do I find out those 10 more ?
[12:45] <AnAnt> add it in OpenJDK you mean ?
[12:45] <persia> You'd have to replicate the crash (first installing an unpatched libbasicplayer-java, etc.
[12:45] <persia> Yeah.
[12:47] <AnAnt> so should I re-open #567856 ?
[12:47] <AnAnt> I mean #491784
[12:47] <AnAnt> LP 491784
[12:47] <ubottu> Launchpad bug 491784 in libbasicplayer-java (Ubuntu) "Sound does not work with openjdk" [Undecided,Fix released] https://launchpad.net/bugs/491784
[12:47] <persia> bug #491784
[12:48] <persia> I'd probably file a new bug for it.
[12:48] <persia> And get the patch submitted upstream.
[12:48] <persia> Because the discussion in the last bug doesn't really help with the new patch.
[13:06] <AnAnt> persia: LP #625790 <= is the information there enough
[13:06] <ubottu> Launchpad bug 625790 in openjdk-6 (Ubuntu) "OpenJDK needs to add gain control support" [Undecided,New] https://launchpad.net/bugs/625790
[13:09] <persia> AnAnt, Yep.  It shows that the problem is really with org.classpatch.icedtea.pulseaudio.PulseAudioSourceDataLine
[13:09] <persia> That should be fixed so it does the right thing.
[13:09] <persia> And it wouldn't happen with other providers, because then BasicPlayer will instantiate something different.
[13:09] <persia> It's purely a bug in the pulse manager implementation.
[13:10] <AnAnt> btw, I didn't try it on maverick
[13:11] <persia> To solve this, you probably want to try with latest PulseAudioSourceDataLine.java (and whatever body of code is part of the same release cycle as that).
[13:11] <persia> I'm completely certain this is an upstream bug, and needs be sorted there.
[13:11] <persia> Then we can backport the fix to maverick/lucid/whatever
[13:12] <AnAnt> where do I get that ?
[13:16] <persia> Well, the jar name starts with classpath.org, so that's a good place to start.
[13:19] <persia> Hrm.  Maybe not :( http://cvs.savannah.gnu.org/viewvc/classpath/org/?root=classpath
[13:19] <AnAnt>  /usr/lib/jvm/java-6-openjdk/jre/lib/ext/pulse-java.jar
[13:20] <persia> "ext" implies th OpenJDK folk consider it external (but bundled).
[13:20] <persia> Maybe one or more of the copyright or licensing statements in OpenJDK will identify who is upstream for it.
[13:21] <AnAnt> IcedTea is licensed under the GPL v2.
[13:22] <persia> Found it: http://icedtea.classpath.org/hg/pulseaudio/archive/tip.tar.bz2
[13:24] <persia> Might be fixed then.  I don't see that exception in PulseAudioSourceDataLine.java
[13:24] <persia> (unless I'm missing something obvious)
[13:26] <AnAnt> so I should build that and replace /usr/lib/jvm/java-6-openjdk/jre/lib/ext/pulse-java.jar with it ?
[13:26] <persia> Oh, I see it.  So it enumerates over the supported controls, or tosses the exception.
[13:26] <persia> To test upstream, that would probably be the simplest way to do it, yeah.
[13:27] <AnAnt> persia: so it still is not fixed ?
[13:29] <persia> Well, it depends on what you pass getControl() :)
[13:30] <persia> At least the implementation has changed enough that it's worth testing with the new upstream.
[13:30] <AnAnt> ok
[13:30] <persia> I know the exception path will have changed.
[13:31] <persia> (or if it didn't, you should ask someone else, because that means my Java is too rusty)
[13:35] <AnAnt> erm, no Makefile.in ?
[13:36] <persia> uses ant, doesn't it?
[13:36] <AnAnt> oh,
[13:36] <AnAnt> autoreconf && ./configure && ant && make
[13:36] <persia> No.  Ignore me.
[13:36] <persia> Right.
[13:39] <AnAnt> well, configure complains that there is no Makefile.in !
[13:40] <persia> Ugh.
[13:40] <persia> You might want to check one of the release tarballs or something (http://icedtea.classpath.org/hg/)
[15:15] <AnAnt> persia: release tarballs (http://icedtea.classpath.org/download/source/) is for the whole Icedtea
=== erhesrhsrtb54vyh is now known as Elbrus
[16:58] <MichealH> Hello
[16:58] <MichealH> How do I make a patch for Debian Bug Tracking reports?
[16:59] <MichealH> Its got something to do in the /debian directory
[16:59] <vish> MichealH: did you read the wiki i gave you already? :)
[17:00] <MichealH> vish, I looked at "When to Send to Debian"
[17:01] <MarioGL91> Hi, I'm looking at a package that FTBFS, and the error is "dkpg-buildpackaged died", can someone point me to the right direction with a link that explains this?
[17:02] <ari-tczew> MarioGL91: give a link
[17:02] <vish> MichealH: then , continue reading the wiki there is also a section for making patches  ;) its all there. you just need to read that wiki and its very easy , i'd suggest you first read the wiki and try to follow the instructions there, when you get stuck at something then ask here.
[17:03] <MarioGL91> ari-tczew: http://launchpadlibrarian.net/50288965/buildlog_ubuntu-maverick-amd64.gawk_1:3.1.7.dfsg-5_FAILEDTOBUILD.txt.gz
[17:06] <ari-tczew> MarioGL91: known bug 601030
[17:06] <ubottu> Launchpad bug 601030 in gcc-4.4 (Ubuntu Maverick) "broken configuration test with fortify source " [High,Confirmed] https://launchpad.net/bugs/601030
[17:06] <MichealH> Thanks vish Now's time to make a patch!
[17:09] <MarioGL91> ari-tczew: thanks
=== jeff_ is now known as Guest52681
[19:07] <geser> hmm, is pulling a new upstream snapshot which adds support to build with llvm-2.7 a new feature that needs an FFe? currently the package FTBFS without this change
[19:20] <ari-tczew> geser: which package are you talking about?
[19:21] <geser> ldc
[19:34] <iulian> geser: No, I don't think so.
[19:35] <iulian> geser: Please file a bug and I'll ack it anyway.
[19:56] <geser> iulian: bug 625952
[19:56] <ubottu> Launchpad bug 625952 in ldc (Ubuntu) "[FFe] Update ldc to 0.9.2+hg1655" [Undecided,New] https://launchpad.net/bugs/625952
[20:02] <iulian> geser: Approved.
[20:43] <devildante> hi everyone! could someone help me?
[20:44] <vish> !ask | devildante
[20:44] <ubottu> devildante: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
[20:44] <devildante> okay :)
[20:46] <devildante> I had modified the software-properties-gtk desktop file to include "NoDisplay=True", so it could be hidden from the menu. The change got merged, but the menu entry is still present :( Do you have any ideas why this doesn't work?
[20:57]  * Laney cuddles the empty build queues
[20:57]  * Laney sneaky sneaks in some haskell rebuilds
[22:48] <persia> AnAnt: Wow.  Sorry.  That's a big chunk.
[23:14] <txwikinger> hi pers?ia how are you
[23:14] <txwikinger> hi persia how are you?
[23:14] <persia> txwikinger, Much improved.  And you?
[23:14] <txwikinger> cool.. I am running an event for the Global Jam here
[23:14] <txwikinger> hat 4 brand new people show up
[23:15] <txwikinger> had
[23:15] <persia> Nice!
[23:17] <txwikinger> persia: I have a question that you might be able to answer
[23:17] <txwikinger> I am stuck on packaging with a virtual package
[23:17] <txwikinger> I have a package that provides this virtual packages that is available
[23:18] <txwikinger> but somehow it does not seem to be automatically selected by apt-get
[23:18] <txwikinger> how does that exactly work?
[23:22] <persia> Does anything else provide the virtual package?
[23:22] <persia> Also, does `aptitude search` find it?
[23:23] <txwikinger> Yes another package provides the virtual package
[23:24] <txwikinger> persia: aptitude search gives me a "v <package-name>" of the virtual package
[23:24] <persia> Err, rather `aptitude show ${virtual-package}`
[23:25] <persia> Excellent!  That means you have a working virtual.
[23:26] <txwikinger> but the packages that needs the virtual package does not install with apt-get
[23:26] <txwikinger> in complains that the virtual package cannot be found
[23:26] <persia> What's the dependency entry for the package that needs the virtual package?
[23:28] <txwikinger> Not sure I understand this question.. it is a depend on the virtual package
[23:28] <txwikinger> and apt-get says broken dependency
[23:28] <nicoulaj> I have packages in a Launchpad PPA for which I would like to request publication in ubuntu repositories. Anyone could point me to the docs/process to follow ?
[23:30] <persia> txwikinger, I'm hoping you'd past the Depends: line from the control file.  There's rules about how one can depend on virtual packages, which I'm not able to express well now, but I hope to be able to apply to determine if the line is OK (as in, if it "looks wrong", I'm hoping I can explain why)
[23:31] <iulian> Do we have a new Launchpad status called "Opinion"?
[23:31] <iulian> Doh, we obviously do.
[23:31] <iulian> Is there any info about it?  I have no idea what it means.
[23:31] <txwikinger> persia: Depends: libc6 (>= 2.4), libmcrypt4, phpapi-20090626
[23:31] <persia> nicoulaj, The process for making that happen is undergoing discussion currently.  You could put them on REVU, but folks aren't reviewing there very much.  You could try to get them into Debian, but there's a freeze on there.  You could submit them to the post-release process, but that's still being founded.
[23:31] <persia> txwikinger, Which is the virtual?
[23:32] <txwikinger> Also the packages are pinned because I don't want php5.3 to load
[23:32] <persia> iulian, Could you link to an example?
[23:32] <txwikinger> phpapi-20090626
[23:32] <txwikinger> iulian: did you look in the wiki at the bugs pages?
[23:33] <nicoulaj> persia: Wow...ok, I'll come back next year then
[23:33] <txwikinger> iulian: https://wiki.ubuntu.com/Bugs/Status
[23:33] <persia> txwikinger, OK.  I'd recommend changing the line to "Depends: ${shlibs:Depends}, ${misc:Depends}, ${real-package} | phpapi-20090626"
[23:33] <txwikinger> persia: ok. I will try that
[23:34] <persia> If something that Provides: phpapi-20090626 is already installed, it will continue.  If not, it will select ${real-package}
[23:34] <txwikinger> real-packages being one of the once that provide the virtual package?
[23:34] <txwikinger> right.. good idea
[23:34] <persia> nicoulaj, Apologies that you've caught us at a bad time.  Submitting through Debian ought work fine in a month or two, and we *really* hope to have something sane for straight-to-Ubuntu sometime in October.
[23:35] <persia> txwikinger, Precisely.
[23:35] <iulian> txwikinger: Oh, thanks for the link.
[23:35] <persia> I believe it's required to be like that, but I can't remember the precise details just now.  Something about resolver internals.
[23:36] <txwikinger> iulian: no problem
[23:40] <nicoulaj> persia: Not a big deal, I'll just wait a few months, this is more by curiosity than a real need. Anyway, thanks for the infos and keep up the great work ;)
[23:40] <geser> persia: fixing the ldc FTBFS is done; it's waiting in the unapproved queue
[23:42] <persia> geser, I saw that :)  I'll find something else (there's plenty that FTBFS *only* on armel/powerpc, which I figure it's better to hunt as I likely can replicate (although some bugs are annoying, like hdf5 where I can't replicate the build failure, but the buildds can)
[23:43] <geser> yeah, getting hdf5 fixed on armel would be really nice as it would unblock several other packages
[23:43] <persia> Indeed.
[23:44] <persia> But "builds for me" doesn't seem to convince the LP buildds to behave differently :)
[23:53] <geser> persia: what's your idea on the graphviz-cairo FTBFS? I'm in favour of dropping the package
[23:54] <geser> I looked already in lucid at that FTBFS and if I remember correctly it doesn't build due to changes in graphviz or so
[23:54] <geser> as I couldn't find the exact location where it got downloaded, I don't know if there is a update for it
[23:57] <persia> For hdf?
[23:57] <persia> or for graphviz?
[23:58] <geser> for graphviz-cairo
[23:59]  * persia grumbles at empty README/NEWS/AUTHORS