[00:00] <azeem> an empty build target, not an empty build
[00:03] <Legendario> azeem, what is it?
[00:03] <azeem> what is what?
[00:03] <Legendario> azeem, an empty build target
[00:04] <azeem> Legendario: what is a non-empty build target?
[00:04] <azeem> or rather, what is a build target?
[00:04] <Legendario> azeem, maybe both
[00:04] <azeem> no, I'm asking you
[00:05] <Legendario> azeem, sorry. English is my second language, i don't program, and that does not make sense to me...
[00:05] <azeem> Legendario: why do you want to pack the source yourself then?
[00:06] <azeem> Legendario: or maybe otherwise asked, what would you do if the source had more than just an install script?
[00:06] <Legendario> azeem, because I want to learn... and help
[00:06] <azeem> ok, then what kind of research did you do so far about "debian/rules build target"?
[00:07] <Legendario> azeem, i have created 3 packages so far by following the packaging guide
[00:07] <Legendario> that's all i know
[00:08] <azeem> ok
[00:09] <azeem> Legendario: the Debian Policy Manual probably discusses the various debian/rules targets, including the build target
[00:09] <azeem> gotta go now, bye
[00:09] <tsmithe> Legendario, a target in a makefile is a name for the collection of commands it runs
[00:09] <tsmithe> if you look in a debian/rules (or and Makefile), you will see it is formatted like this:
 <dependencies>
[00:09] <tsmithe>   <rules>
[00:10] <tsmithe> if <dependencies> have not been run when <target> is called, they are run first, in the order listed, and then <rules> are executed
[00:10] <tsmithe> "build" is one of the targets required in a debian/rules file, and it generally builds the sources into binaries
[00:11] <tsmithe> it could have a "configure" rule as a dependency, which would configure the build process to run
[00:11] <tsmithe> if the package has no sources that need building, you need not specify any rules, or any dependencies, but the target must still exist to comply with policy.
[00:14] <Legendario> tsmithe, thanks for such a detailed explanation!
[00:14] <tsmithe> no problem. it's good to have new contributors willing to learn :)
[00:17] <pochu> slomo__, superm1: gmyth out of Debian NEW \o/
[00:17] <pochu> next step --------> syncing!
[00:18]  * tsmithe can't wait to go through the same process for fluid-soundfont. that would be my first debian package :D
[00:18] <Legendario> tsmithe, is there an easy way to edit the debian/rules in order to achieve it, or a model to follow. My bash scrit habilities are few...
[00:19] <tsmithe> Legendario, just do some research on makefiles, look at the debian policy and debian/ubuntu packaging guides/new maintainers guides, and play around with the files that are already there
[00:19] <tsmithe> i presume you used dh-make?
[00:20] <tsmithe> (to create a skeleton package)
[00:20] <RAOF> Legendario: Also, try some non-CDBS packages.  CDBS conceals all these targets.
[00:20] <Legendario> use dh_make
[00:20] <Legendario> RAOF, i realized that
[00:20] <tsmithe> yeah, don't use cdbs until you know how the system works ;)
[00:26] <Hobbsee> morning all
[00:27] <LaserJock> hola Hobbsee
[00:28] <Legendario> thanks tsmithe
[00:28] <Legendario> and RAOF
[00:28] <tsmithe> no problem
[00:30] <nixternal> hiya Hobbsee and LaserJock
[00:30] <Legendario> any suggestion on a makefile "tutorial"?
[00:30]  * nixternal pets kdevelop for doing the makefiles for me
[00:31] <Legendario> tsmithe, a good one...
[00:31] <tsmithe> Legendario, sorry, but i'm sure google can
[00:32] <LaserJock> Legendario: what specifically are you having trouble with?
[00:32] <tsmithe> each line is a command executed in its own shell
[00:32] <tsmithe> the rest seems self-explanatory...
[00:33] <Legendario> tsmithe, google has lots of those. I was hoping there is a reference one
[00:34] <Legendario> LaserJock, i am trying to pack a program that has only an install script
[00:34]  * tsmithe just learned by example, so he doesn't have much to recommend
[00:34] <Legendario> got to know i have to learn more about makefiles...
[00:35] <LaserJock> Legendario: it's really easy thought
[00:35] <LaserJock> *thought
[00:35] <LaserJock> bah
[00:35] <tsmithe> hehe
[00:35] <LaserJock> *though
[00:35] <LaserJock> there
[00:35] <tsmithe> ;)
[00:35] <LaserJock> Legendario: as azeem said you need an empty build rule
[00:35] <MECU> I'm new and I read that I could help out by compiling programs, where do I find the programs (packages) that need to be compiled?
[00:35] <tsmithe> Legendario, what don't you get about makefiles? i explained the structure...
[00:36] <nixternal> MECU: are you familiar with Debian/Ubuntu packaging? If not, check out https://wiki.ubuntu.com/PackagingGuide for some information on that
[00:36] <LaserJock> Legendario: each rule (the unindented part that has a :, like configure:, build:, etc.) has the lines that are need to build the package
[00:36] <Hobbsee> sigh.  how does one make wine behave now?
[00:37] <nixternal> MECU: https://wiki.ubuntu.com/MOTU has a todo list and more information as well for you
[00:37] <MECU> yes, I just read though that, okay, thanks nixternal
[00:37] <nixternal> Hobbsee: you think you are jesus or something? You think you can make wine do whatever you want? :p
[00:37] <Hobbsee> hehe
[00:37] <Hobbsee> or at least run
[00:38] <MECU> wouldn't that be: cp water wine ?
[00:38] <nixternal> I haven't tried running the ie4linux stuff..let me see
[00:39] <ScottK2> Hobbsee: You browbeat \sh until he fixes it.
[00:39] <nixternal> yup, wine isn't working here
[00:41] <Legendario> LaserJock, it has a build and a build-stamp section. How do i call the install script?
[00:41]  * Hobbsee sighs
[00:41] <Hobbsee> why give me an executable to unzip something, anyway...
[00:41] <LaserJock> Legendario: you do that in the install: rule
[00:41] <tsmithe> could someone upload https://bugs.edge.launchpad.net/ubuntu/+source/mscore/+bug/195179 please? (to clarify, i don't think it requires a FFe)
[00:41] <ubotu> Launchpad bug 195179 in mscore "Please update mscore to 0.9.1d+dfsg-0ubuntu2 (debdiff attached)" [Undecided,New]
[00:45] <Legendario> LaserJock, like adding $(CUR_DIR)/install.sh
[00:45] <LaserJock> right
[00:45] <Legendario> LaserJock, should i erase the build and build-stamp sections?
[00:46] <LaserJock> keep build: it's required
[00:46] <RAOF> Hobbsee: By installing the Gutsy package from winehq, sadly.  Or possibly rebuilding our package locally with an older gcc.
[00:46] <LaserJock> but it can be empty
[00:46] <Hobbsee> RAOF: right
[00:46] <RAOF> Hobbsee: It hasn't been all bad.  I learnt about aptitude forbid-version :)
[00:46] <StevenK> RAOF: Wine doesn't like gcc 4.2?
[00:46] <Legendario> LaserJock, what about the build-stamp one?
[00:47] <RAOF> StevenK: Apparently building with an older gcc makes wine not segfault immediately.
[00:47] <LaserJock> Legendario: you can remove it and any references to it
[00:47] <RAOF> StevenK: I haven't tested this personally.
[00:48] <RAOF> Legendario: The build-stamp target is there to make sure the source gets built exactly once; you'll notice that the last thing it does is to create a file called "build-stamp".
[00:48] <RAOF> Legendario: This means that if someone calls the build: target again, build: will see that the build-stamp file already exists, and so won't call the target again.
[00:50] <Legendario> LaserJock, thanks... I learn a lot every time i get here. And by packaging, i learn a lot of computing too... ;-)
[00:51] <Legendario> LaserJock, but i think this could be added on the packaging guide
[00:51] <LaserJock> well, it's a wiki, everybody is more than welcome to help :-0
[00:51] <LaserJock> :-) rather
[00:53] <Legendario> LaserJock, after i get good on it... I may try it. :-P
[00:53] <slangasek> geser: bug #195453 - should xen-unstable also be blacklisted for sync?
[00:53] <ubotu> Launchpad bug 195453 in xen-source "Please remove xen-{source,unstable} from hardy" [Undecided,Fix released] https://launchpad.net/bugs/195453
[00:56] <Legendario> LaserJock, the install section has a build option. Am I supposed to erase it too?
[00:57] <RAOF> Legendario: By "build option" you mean "declares a dependency on build", right?  Since you don't actually need to build anything, you can either leave that in (since build is empty), or preferably remove it.
[00:58] <RAOF> Legendario: As in: the makefile contains a line "install: build", right?
[00:59] <Legendario> RAOF, that's it
[00:59] <RAOF> Right.  So that says "you have to run the build target before the install target".  Since your build target does nothing, this is harmless but unnecessary.
[01:01] <Legendario> ok
[01:03] <LaserJock> dang, I can't figure out why my old laptop is sooooo slow
[01:04] <LaserJock> I did a fresh Gutsy install and it seems way slower than before
[01:15] <mok0_> huh? qa.ubuntuwire.com is still not operational
[01:17] <nixternal> haven't seen imbrandon around either for a bit
[01:21] <ScottK> He was seriously sick in bed a few days ago (I called him).
[01:21] <tbf> superm1: so someone really run gnome-lirc-properties. seems i've got a victim of having a symlink to my working copy in /usr/lib/python2.5/site-package
[01:22] <tbf> superm1: so i forgot to update Makefile.am, when renaming the module
[01:22] <tbf> superm1: strange that automake didn't complain
[01:23] <superm1> tbf, well the project is of particular interest to me :)
[01:23] <superm1> tbf, so i wanted to see how well it worked
[01:25] <superm1> tbf, you had some comments somewhere in the package about the confusion about only debian/ubuntu using lirc.hwdb
[01:26] <superm1> that's because we (Ubuntu) are the first to adapt using it
[01:26] <superm1> the idea is supposed to be that eventually everyone will though
[01:26] <tbf> https://code.fluendo.com/remotecontrol/trac/browser/trunk/data/receivers.conf
[01:27] <superm1> yup that's where I was reading :)
[01:27] <tbf> superm1: lirc.hwdb was a good idea, but it doesn't provide the information needed for auto-detection
[01:27] <superm1> tbf, well the spec can still be changed upstream
[01:27] <superm1> have you talked to Chris B. about it already?
[01:27] <superm1> on the lirc-list
[01:28] <tbf> superm1: currently i try to get code package ready before the hard beta freeze... :-/
[01:28] <superm1> tbf, ah.
[01:29] <tbf> superm1: but the file format i have now seems to work for me...
[01:29] <superm1> well if you need some help, someone on my team (~mythbuntu), will probably be willing to help
[01:29] <superm1> he wanted to do a similar spec
[01:29] <superm1> but never got around to it
[01:29] <tbf> https://code.fluendo.com/remotecontrol/trac/browser/trunk/bin/build-receiver-list
[01:29] <superm1> tbf, you should know though, inside ubuntu we have a special patch (that upstream hasn't accepted yet)
[01:30] <superm1> tbf, that allows a lircd.conf to be "included" in the system wide one
[01:30] <tbf> this script generates a slight variation of that receivers.conf by scaning the source code of lirc
[01:32] <tbf> superm1: guess i really should send a mail about that script and the file-format to the lirc-list tomorrow
[01:32] <superm1> tbf, yeah, sometimes Chris is a little slow responding
[01:32] <superm1> so that would be worthwhile
[01:33] <tbf> superm1: i'd also highly appreciate (manual?) updates to the receivers.conf file....
[01:33] <tbf> superm1: currently it is quite empty
[01:34] <tbf> superm1: i say "manual", cause of the timeframe needed, to get annotations into the lirc code
[01:34] <superm1> tbf, well let me put you in touch with the chap on my team that was looking to work on this
[01:34] <superm1> tbf, if hang around #ubuntu-mythtv-dev and idle for a bit, his name is foxxbuntu
[01:58] <bddebian> Heya gang
[03:05] <TheMuso> ember_: I've got orca covered.
[03:09] <superm1> TheMuso, ah you were the one that pre-empted all the changes to ubiquity not running as root right :)
[03:09] <superm1> for orca?
[03:09] <TheMuso> superm1: Yep, haven't been able to test them so far, but hope to do that this afternoon.
[03:09] <superm1> TheMuso, well they broke the mythbuntu frontend i found out :)
[03:09] <TheMuso> superm1: So I saw, but it was an easy fix, again from what you wrote to -installer.
[03:09] <superm1> yeah it was
[03:10] <superm1> just had to track down any possible points of failure
[03:10] <TheMuso> Yeah.
[03:13] <bddebian> Why isn't libgnutls26 in Hardy?
[03:21] <TheMuso> Wow! The motu release bug list is quite long.
[03:21] <mok0_> TheMuso: Are you in the release team?
[03:23] <mok0_> TheMuso: Ah! You are!
[03:23] <TheMuso> mok0_: Yes I am, and I'm having a look over it, after neglecting it for a while, due to other work.
[03:25] <TheMuso> mok0_: I'm assuming that collect4 has not yet been uploaded yet?
[03:25] <mok0_> TheMuso: I have 2 acks on 194219 but I don't know why it's still on the list, or what has happened to it
[03:25] <TheMuso> gah bad english
[03:25] <TheMuso> bug 194219
[03:25] <ubotu> Launchpad bug 194219 in collectd "[needs-merge] collectd  (4.3.0-1)" [Undecided,Confirmed] https://launchpad.net/bugs/194219
[03:25] <mok0_> Heh two minds...
[03:25] <TheMuso> ah yes, looking atht ath now
[03:25] <TheMuso> I'll review and upload it then.
[03:26] <TheMuso> mok0_: ummm. No bug number in teh changelog, there is a placeholder for one, but... Its not there.
[03:27] <mok0_> Ach.
[03:27] <mok0_> Forgot, can you put it in?
[03:27] <TheMuso> mok0_: And, the only two files touched by the debdiff are debian/control, and debian/changelog. Should there be more?
[03:28] <mok0_> TheMuso: That's it iirc
[03:28] <TheMuso> Well what is being changed?
[03:28] <mok0_> TheMuso: It is basically taking over Debians new pacakge
[03:28] <TheMuso> So shouldn't it be a sync?
[03:28] <mok0_> Well, yes, if possible at this time
[03:29] <TheMuso> mok0_: Well, I suggest you re-examine the bug, and the package, and if so, change the package description to a sync request.
[03:29] <mok0_> TheMuso: arair I noted in the changelog that it should be synced next time
[03:30] <TheMuso> mok0_: I'm confused... Why next time?
[03:30] <mok0_> I assumed this was the way to do a FFE
[03:30] <mok0_> I didn't know I could just do a sync request
[03:31] <TheMuso> An FFE can still be a sync, as long as the requested information is given, and 2 acks are given. It doesn't have to be a merge/upload.
[03:31] <mok0_> TheMuso: and I need some uploads :-)
[03:31] <TheMuso> An FFE is just that, an FFE, a request to change the package in a major way, whether it be via a sync, or a upload/merge etc.
[03:31] <TheMuso> mok0_: When a package is synced, you still get credit for requesting it.
[03:32] <mok0_> TheMuso: cool :-)
[03:32] <mok0_> TheMuso: How does the sync happen in practice?
[03:33] <mok0_> TheMuso: someone has to fetch it and upload
[03:33] <TheMuso> mok0_: The archive admins have powers to directly copy the package from Debian.
[03:33] <TheMuso> Nobody uploads it.
[03:33] <TheMuso> mok0_: I'm assuming you have never requested a sync before.
[03:33] <mok0_> TheMuso: that's right
[03:34] <mok0_> TheMuso: so, I just change the bug description? Is there a tag?
[03:34] <TheMuso> mok0_: No. Let me find the wiki page describing the sync process.
[03:35] <mok0_> Thx
[03:35] <TheMuso> mok0_: https://wiki.ubuntu.com/SyncRequestProcess
[03:37] <mok0_> TheMuso: looks easy enough... most of the requested info is already attached to the bug
[03:37] <TheMuso> mok0_: Well, have a look over the bug as it is now, and change the description to a sync request and you'll find out soon enough whether you've given enough information.
[03:38] <mok0_> TheMuso: ok
[03:38] <mok0_> TheMuso: I have 1 ack on another package: 156100	
[03:39] <TheMuso> bug 156105
[03:39] <ubotu> Launchpad bug 156105 in moblin-multimedia "prompt error message when start playbacking wma media" [Medium,Fix released] https://launchpad.net/bugs/156105
[03:40] <TheMuso> mok0_: Ok will have a look now.
[03:40] <mok0_> TheMuso: great, I can answer questions
[03:42] <TheMuso> mok0_: err, is that the correct bug number?
[03:42] <TheMuso> oh i got it wrong
[03:42] <TheMuso> bug 156100
[03:42] <ubotu> Launchpad bug 156100 in storm "[hardy] please upgrade storm to version 0.12" [Undecided,Incomplete] https://launchpad.net/bugs/156100
[03:42] <mok0_> yes
[03:42] <TheMuso> heh
[03:42] <mok0_> TheMuso: 0.12 closes a bunch of bug reports
[03:43] <mok0_> TheMuso: ... and besides, when we bitch at Canonical for not opensourcing their stuff, we should be on top of it when they publish updates to storm
[03:43] <TheMuso> mok0_: You need to attach everything else relating to an FF, diffstat, changelog, build and install logs...
[03:44] <mok0_> TheMuso: ok
[03:44] <mok0_> TheMuso: install logs?
[03:44] <TheMuso> mok0_: Yes. We need to know that the package installs and updates correctly.
[03:45] <TheMuso> mok0_: https://wiki.ubuntu.com/FreezeExceptionProcess explains everything.,
[03:45] <mok0_> TheMuso: thx
[03:45] <mok0_> TheMuso: it's getting time for bed for me, I'll do it tomorrow
[03:46] <mok0_> TheMuso: but the other bug I will change in a minute
[03:47] <TheMuso> mok0_: Ok thanks.
[03:49] <mok0_> Well goodnight, see you later!
[03:50] <LaserJock> persia: around?
[03:59] <Legendario> hello.
[03:59] <Legendario> how do i use dh_intallman?
[03:59] <Legendario> how do i use dh_installman?
[04:05] <RAOF> man dh_installman and man debhelper will give useful pointers, but generally the answer is to just call dh_installman in the appropriate debian/rules target.
[04:07] <RAOF> And like the rest of debhelper, having a debian/$packagename.manpages should make it just work.
[04:13] <Legendario> RAOF, i've read the man pages, but it didn't make any clear. There is even a bug about it (Bug #184156). I am calling it on debian/rules but the package created doesn't have the man page.
[04:13] <ubotu> Launchpad bug 184156 in debhelper "man page of dh_installman incomplete for newbie" [Undecided,New] https://launchpad.net/bugs/184156
[04:17] <Legendario> RAOF, am i the one supposed to create the packagename.manpages or does the dh_installman the one who handles it?
[04:21] <TheMuso> leonel: You create that file.
[04:21] <TheMuso> gah
[04:50] <ScottK> pochu: I just uploaded a (hopefully) fixed pychecker.  Your turn to work on SPE.
[05:14] <slomo__> pochu: i'll upload new gst-plugins-bad tomorrow probably... i want the things available everywhere to prevent failing builds again and get it into testing soonish
[05:49] <slomo__> superm1: http://buildd.debian-ports.org/status/package.php?p=gmyth  <--- fails on kfreebsd, might want to notify upstream about that or give a patch ;)
[05:50] <superm1> kfreebsd?,  didn't even know that it would automatically be added to different ports
[05:50] <superm1> i'll bring it up with upstream
[05:50] <superm1> still waiting to hear back on the -upnp stuff
[06:00] <slomo__> superm1: the kfreebsd patch is probably easy, will take a look at it later if you didn't before :)
[06:00] <superm1> slomo__, do you have a kreebsd env to work from?
[06:01] <superm1> can one be created in a pbuilder directly?
[06:01] <slomo__> superm1: no idea, i assume it's an obvious bug :)
[06:01] <superm1> hehe
[07:03] <dholbach> good morning
[07:03] <nixternal> good morning to you sir
[07:04] <dholbach> hey nixternal - how are you doing?
[07:04] <nixternal> not to shabby...coming down off of my busy spell at the uni
[07:04] <nixternal> installing Ubuntu on my desktop so I can test some of the Gnome/KDE4 issues that I have been reading about
[07:05] <dholbach> oh... what are they about?
[07:05] <dholbach> nixternal: great to see you're in 5-a-day as well :-)
[07:05] <nixternal> some reason people are seeing klauncher crashes when logged into Ubuntu
[07:05] <dholbach> ugh :/
[07:05] <nixternal> oh ya, trying to take the lead in 5-a-day :)
[07:05] <dholbach> I noticed :-)))
[07:06] <nixternal> it started out as 5-a-day, but as I sat in on classes at the uni, I started doing 20 to 60 a day listening to boring lectures :)
[07:06] <dholbach> it seems the project grew so much that committing bugs you've worked on takes a while :)
[07:06] <nixternal> I noticed that today
[07:06] <dholbach> I'll try to work something out to fix that
[07:06] <dholbach> so everybody commits to their own branch
[07:07] <dholbach> which will make the statistics a bit more complicated, but it's going to befine
[07:07] <nixternal> actually, I did my add-5-a-day, and it updated the branch, and between the time it finished updating the branch and committing mine, someone had committed, which caused add-5-a-day to crash out because the branch was out of date
[07:07] <nixternal> in 5 seconds I would say
[07:07] <dholbach> oh... crash?
[07:07] <nixternal> yup
[07:07] <dholbach> wasn't it just bzr complaining?
[07:07] <dholbach> please give me the backtrace if that happens again
[07:07] <nixternal> it was
[07:07] <nixternal> wasn't a backtraceable crash
[07:07] <Fujitsu> Why not have people commit to their own branch, then have some script running somewhere that watches lots of branches and merges them into the main one?
[07:07] <dholbach> ah ok
[07:08] <nixternal> someone had committed in between the update and my commit, in between the 1st and 2nd stage of add-5-a-day
[07:08] <dholbach> Fujitsu: probably not even necessary to merge them into a main branch
[07:08] <warp10> Good morning!
[07:08] <dholbach> Fujitsu: but yeah, that'S the basic idea
[07:09] <dholbach> we could even make it so that people push their changes to multiple branches (I'd commit to dholbach and ubuntu-berlin for example) so that teams could compete against each other :)
[07:09] <dholbach> it makes statistics a bit hard to figure out, but I somehow like the general idea :)
[07:09] <nixternal> that sounds like fun
[07:10]  * Fujitsu declares universe to be too big.
[07:13] <HighN1> according to einstein there's nothing bigger...
[07:14] <Fujitsu> Heh.
[07:15] <HighN1> you may splitt it up into multiple galaxies, but their number would be endless
[07:15] <HighN1> :-)

[08:19] <cokehabit> can someone help me with a booting problem?
[08:19]  * Hobbsee suggests #ubuntu for support
[08:20] <cokehabit> i've asked in there and no-one seems to be responding
[08:20] <cokehabit> i've asked questions before and got directed here so i thought i would cut out the middleman
[08:21] <Hobbsee> for packaging?
[08:21] <cokehabit> yes, before it was a .deb packaging problem
[08:22] <Hobbsee> which is why that was on topic.  this isn't, sorry...
[08:22] <cokehabit> this time though, no kernel since 2.6.24-2 has got past "loading kernel drivers"
[08:22] <cokehabit> i didn't know this was a packaging channel, sorry
[08:23]  * Hobbsee suggests reading the /topic
[08:23] <cokehabit> just read the wiki, sorry
[09:00] <geser> slangasek: re xen-unstable: it should probably be also added to the sync blacklist as it build-depends on linux-support-* which isn't available in Ubuntu (and xen-3.0 and xen-3 are also on the sync blacklist)
[09:32] <Balise> hi
[10:19] <slomo_> superm1: kfreebsd fixed ;)
[11:10] <Hobbsee> TheMuso: ping
[11:10] <TheMuso> Hobbsee: Yes, what can I do for you?
[11:11] <Hobbsee> TheMuso: how do you want to handle https://bugs.edge.launchpad.net/ubuntu/+source/ubuntustudio-icon-theme/+bug/192535 which now has it's MOTU-uvf ack?
[11:11] <ubotu> Launchpad bug 192535 in usplash-theme-ubuntustudio "FF: General exception for Ubuntustudio packages." [Wishlist,Confirmed]
[11:11] <Ng> pochu: I finally filed the freeze exception, sorry for the delay. #195733
[11:12] <TheMuso> Hobbsee: What do you mean exactly?
[11:13] <persia> Don't bugs of that class just get closed at BetaFreeze / ArtworkFinalDeadline?
[11:25] <persia> Ng: I'm not in motu-release, but I'd like the updates: remember to include the installation log and testing report.
[11:25] <Hobbsee> TheMuso: in particular, i'm about to unsubscribe us - are you intending to mark it as fix released or anything?
[11:27] <\sh> guys...netbeans is crashing on hardy amd64...can someone prove this?
[11:28] <persia> \sh: Give me a test case, and I'll give it a shot (and try to arrange a patch).
[11:29] <\sh> persia: just start it with sun-java6 installed
[11:29] <\sh> /usr/share/netbeans/6.0.1/bin/../platform7/lib/nbexec: line 440:  4491 Aborted                 (core dumped)
[11:29]  * persia tends to avoid multiverse java, but tests
[11:29] <TheMuso> Hobbsee: No, was just hoping to get a standing freeze exception, and its also documented on the wiki page, so feel free to close/unsubscribe.
[11:30] <persia> \sh: Do I need the jdk, or just the bin & jre?
[11:31] <Ng> persia: is the installation log literally just the output of me installing the build and it not doing anything out of the ordinary?
[11:32] <persia> Ng: Yes.  For extra points, provide logs for all of install, upgrade from current hardy, remove, and purge.
[11:32] <\sh> persia: just jre
[11:32] <\sh> and who forced me to upload xdebug?
[11:33] <Hobbsee> TheMuso: that's what i'm thinking we're giving, yeah
[11:33] <persia> \sh: Got it: that's bug #87947
[11:33] <ubotu> Launchpad bug 87947 in libx11 "xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed." [Medium,Fix released] https://launchpad.net/bugs/87947
[11:33] <Hobbsee> right, from 51 to 42.  excellent
[11:35] <Hobbsee> and down to 28.
[11:36]  * persia isn't convinced 87947 should be "Fix Released" as I'm currently finding about 8 dupes.
[11:40] <Ng> persia: what would be useful for the testing report? I'm not sure that "well there are probably half a dozen people using 0.8.1 or later and in regular contact with the project who haven't reported any serious bugs" will do ;)
[11:41] <persia> Ng: Depends on the nature of the update.  My previous testing reports have varied from "doesn't segfault on startup for me" to arranging for people with three different architectures to follow two use cases and report the results (odd issue with failing to render only some Youtube videos).
[11:42] <Ng> hmm
[11:42] <persia> My understanding (and I'm not authoritative on this) is that you want to include enough information to convince the release team that the updates package (and any dependencies) work well enough to be released after the update.  For terminator, it ought be fairly easy.
[11:45] <Ng> persia: ok thanks, I'll whip something up
[11:51] <persia> Ng: I usually just cat all of the install/upgrade/remove/purge logs together in a single attachment.
[11:53] <Ng> persia: very wise, I realise I'm spamming the motu-release folks, for which I apologise
[12:26] <Iulian> Hi
[12:27] <thekorn> hey Iulian
[12:28] <Iulian> Hi there thekorn
[12:38] <pochu> ScottK: nothing to do in spe, it just was uninstallable as it depends on pychecker >= someversionthatwasftbfs ;)
[12:38] <pochu> ScottK: thanks for fixing pychecker
[12:39] <pochu> slomo_: re: gst-bad - no hurry, that's fine :)
[12:39] <pochu> ScottK: I setted it as high importance because it was uninstallable and not because it was spe. we do the same for ftbfs independently of the package
[12:40] <persia> pochu: For everything?  I thought most universe packages couldn't qualify for "High" except for license issues.
[12:43] <pochu> persia: hmm, I don't know, but infinity's MBF was done at high importance I think. Perhaps his check was done for main only
[12:44] <persia> pochu: For main, failure-to-install or FTBFS is typically High.  For universe, typically Medium, although some packages might have enough users to qualify for high.
[12:45] <pochu> persia: ok, thanks
[12:48] <persia> pochu: Reviewing https://wiki.ubuntu.com/Bugs/Importance, I'd think that for universe it would have to be something like a significant component of one of the universe derivatives being broken in order to qualify for "Has a severe impact on a small portion of Ubuntu users", as I don't think anything is really popular enough for "Has a moderate impact on a large portion of Ubuntu users".
[12:52] <pochu> persia: wxwidgets ftbfs would qualify ;)
[12:53] <persia> pochu: Ah.  Maybe, at least for 2.6.  There's likely a few other major universe libraries as well.
[12:54]  * ScottK thinks clamav and spamassassin would potentially qualify.
[12:55] <ScottK> pochu: In that case (for spe) after you test it, I'd suggest it's fix released, not invalid.
[12:55] <persia> Probably.  There's a lot of dependencies, and a fair number of users.  On the other hand, it's not likely true for spe :)
[13:21] <bigon> http://www.paeps.cx/weblog/Linux/fuck_ubuntu WTF
[13:32] <ScottK2> He's entitled to his opinion.
[13:40] <mok1> I was asked to submit an install log to LP. Any particular way that needs to be done?
[13:45] <amarillion> Hey
[13:45] <amarillion> Do you know any good tools to import ~150 signed gpg keys reasonably quickly?
[13:47] <broonie> amarillion: Depends on what format you have the keys in... what problems does gpg --import give you?
[13:48] <vivia> hello there... i just saw tcl/tk 8.5 entering the repositories lately and an updated amsn compiled against 8.5 ... (first thing, make sure latest amsn package is marked incompatible with tcl/tk 8.4, ok?) but i found a problem
[13:48] <amarillion> Ah I forgot to tell you, they are in my email right now, thunderbird
[13:48] <persia> mok1: I've generally used the script command to capture my entries and the output.  I typically do all of install, upgrade, remove, and purge to demonstrate that all the maintainer scripts do the right thing.
[13:48] <vivia> if someone has tcl/tk 8.5 and tcllib from the gutsy repositories, amsn won't start
[13:48] <amarillion> Is there a tool that can sort them out from a mbox or something?
[13:49] <vivia> it's a bug in snit 2.1 that is contained in the current tcllib package
[13:49] <broonie> mutt should be able to do it (open the mbox, tag everything and tell it to snarf the keys)
[13:49] <vivia> they told me that the latest snit release fixes it. but snit 2.1 contained in tcllib 1.9.dfsg1-1 is VERY problematic with tcl/tk 8.5
[13:49] <amarillion> snarf? Ok I'll look into it
[13:49] <vivia> so it should cause problems to other applications too, not just amsn
[13:49] <persia> vivia: You likely want either #ubuntu-bugs, or to report a bug from https://launchpad.net/ubuntu/+source/tcllib/+bugs
[13:50] <vivia> persia: sure, going to report it there... thanx ;)
[13:50] <persia> vivia: Thanks for tracking it down, it's just that we're ill prepared to handle bug reports in IRC.
[13:51] <vivia> persia: it's ok, we often have it on amsn too, and amsn is a MUCH smaller project.. :)
[13:51] <mok1> persia: the script command, thank you! Never heard of it before. You're never to old to learn something new..
[13:52]  * persia thinks the script command is older than several developers :)
[13:53] <vivia> how can i check whether my current amsn package is incompatible with tcl8.4 ?
[13:53] <emgent> heya people
[14:07] <vivia> https://bugs.launchpad.net/ubuntu/+source/tcllib/+bug/195785 there you go, i filed it... i'd appreciate it if anyone could check it and tell me quickly whether more info is needed
[14:07] <ubotu> Launchpad bug 195785 in tcllib "snit 2.1 contained in tcllib 1.9.dfsg1-1 incompatible with tcl/tk 8.5" [Undecided,New]
[14:08] <vivia> wow, thanx ubotu
[14:08] <vivia> nice bot you've got there :)
[14:10] <amarillion> broonie, did you ever participate in a key signing party?
[14:12] <amarillion> Has anyone here participated in a key signing party?
[14:14] <broonie> amarillion: yes
[14:15] <amarillion> So how did you learn how it works?
[14:15] <amarillion> I don't really understand it
[14:15] <amarillion> I mean, I understand the theory, but the documentation is very skimpy on the details
[14:16] <broonie> You mean the actual process for doing things? That differs depending on how the event is organised. Whichever way it's just a way to do an individual signing in bulk.
[14:17] <amarillion> If I'm going to do this with thunderbird, I now have to open 150 emails, save the attachment, (type in a different name for each of them or thunderbird will overwrite) unencrypt and then import
[14:18] <amarillion> Probably I can find a way to automate things with mutt but then I'd have to learn to use mutt first
[14:18] <geser> amarillion: the main problem with KSPs is: how do you get a bulk of people to check each others identities in an ordered way and in a minimum of time
[14:18] <amarillion> geser, yeah, it was reasonably efficient at fosdem this year
[14:18] <emgent> heya geser :)
[14:18] <broonie> amarillion: mutt has a direct command for "import key from this e-mail"
[14:18] <amarillion> I hear it was a mess in previous years
[14:19] <amarillion> broonie, ah, which is it? I can't find it in the help
[14:19] <geser> amarillion: Debian people have expierence at doing a KSP, I was at the FOSDEM KSP last year
[14:19] <amarillion> There is a command in mutt to decrypt it
[14:19] <broonie> amarillion: C-k
[14:19] <geser> amarillion: ^K          extract-keys           extract supported public keys
[14:20] <amarillion> great, thanks
[14:21] <amarillion> I suppose everybody uses mutt for this? Doing this in thunderbird seems impossible
[14:21] <\sh> whoever proposed php5-xdebug THANK YOU SOO MUCH !
[14:22] <\sh> amarillion: enigmail is your friend I think
[14:23] <geser> \sh: is it with enigmail as easy as in mutt to import keys from a KSP?
[14:24] <man-di> amarillion: install signing-party and use caff
[14:24] <amarillion> man-di, I used caff to send out the signed keys
[14:24] <geser> yes, for sending out signatures caff is really good
[14:24] <\sh> geser: for this you use caff and a local smtp
[14:25] <\sh> geser: and for importing keys...I'm using a shell script...adding sigs to my key I do it manually...
[14:27] <amarillion> Ok, I have everything imported. Thanks broonie
[14:28] <geser> amarillion: don't forget to update your key on the keyservers
[14:28] <ScottK> stani: Is everything in good shape for SPE in Hardy now?
[14:28] <amarillion> geser, I will, thanks
[14:30] <sistpoty|work> hi folks
[14:41] <stani> ScottK: You confirmed pychecker works, which was the biggest blocker. Right now I have a bug fix release ready, which fixes an important CPU leak. I haven't yet had the possibility to put a Hardy machine to test SPE.
[14:42] <stani> ScottK: I was planning to release it in the beginning of march, but can do it earlier. (The only reason I am waiting is to be sure nothing else pops up which I have to fix.)
[14:43] <stani> ScottK: I am also working on a bug fix release of Phatch, which should be ready this week as well.
[14:43] <ScottK> stani: Well beginning of March is next week.  I don't see any harm in waiting.
[14:44] <Ng> ScottK: thanks for the terminator sync ack. I take it we need a second one?
[14:44] <ScottK> Ng: Yes.
[14:45] <Ng> ok, thanks :)
[14:46] <stani> ScottK: You can give me a deadline which should be comfortable for you to upload Phatch and SPE. Than I have a target. Will we follow the same procedure, upload with POX or pochu to Debian and you sync from there?
[14:46] <ScottK> That last alpha release is sched for March 6.  Can you make that?
[14:46] <ScottK> stani: ^^
[14:47] <stani> ScottK: Of course, does it need to be one day in advance?
[14:48] <ScottK> stani: Not really.  What I really want is it in well before the beta freeze a week later.
[14:53] <hellboy195> LucidFox: checking for C compiler default output file name...
[14:53] <hellboy195> configure: error: C compiler cannot create executables
[14:53] <hellboy195> See `config.log' for more details.
[14:53] <hellboy195> make: *** [configure-stamp] Error 77
[14:53] <hellboy195> dpkg-buildpackage: failure: debian/rules build gave error exit status 2
[14:54] <stani> ScottK: OK
[14:56] <vivia> hellboy195: you do have build-essential installed, right?
[14:57] <hellboy195> vivia: that was an error of the build machine on LP. https://edge.launchpad.net/ubuntu/+source/starplot/0.95.4-3
[14:57] <sistpoty|work> hellboy195: sounds like you have a CC="something" ./configure call somewhere where something doesn't start with gcc?
[14:58] <bddebian> Heya gang
[14:58] <hellboy195> sistpoty|work: well, I did an sync request from Debian
[14:58] <hellboy195> sistpoty|work: https://bugs.edge.launchpad.net/ubuntu/+source/starplot/+bug/195032
[14:58] <ubotu> Launchpad bug 195032 in starplot "Please sync starplot 0.95.4-3 from Debian(Unstable)" [Wishlist,Fix released]
[14:58] <mib_hg7jf8fu> I have a simple and naive question: what is the relationship between debian unstable packages and ubuntu universe? that is, are debian unstable packages, in general, included in ubuntu universe?
[14:59] <sistpoty|work> hellboy195: and it worked in your pbuilder?
[14:59] <albert23> hellboy195: that error is caused by the quoting of CFLAGS in debian/rules
[15:00] <hellboy195> sistpoty|work: I'm afraid. I never test sync requests :( first time such a thing happended
[15:01] <stani> I'd like to include the information of the copyright file in debian of Phatch in the upstream release (of course without "this package was debianized by..."). Is this possible and can than the debian/copyright file just refer to it instead of repeating the information?
[15:01] <sistpoty|work> hellboy195: please always testbuild stuff you want to get in the archives... likewise use Hobbsee's long point stick against your sponsor not test-building as well ;)
[15:02] <hellboy195> sistpoty|work: yeah. I'm sorry :( but also the grabmerge ubuntu patch doesn't show such a thing with CFLAGS or something similar ...
[15:03] <RainCT> hey
[15:03] <sistpoty|work> hi RainCT
[15:05] <slytherin> mib_hg7jf8fu: Ubuntu packages are synced/merged with packages from Debian unstable at the start of every Ubuntu development cycles. And sync/merge continues till feature DebianImportFreeze. After that it is done on case by case basis.
[15:06] <mib_hg7jf8fu> Thanks slytherin!
[15:06] <LucidFox> Speaking of syncs...
[15:07] <LucidFox> I have a couple of packages that I maintain in both Debian and Ubuntu. In Ubuntu they're -0ubuntuX and the Debian versions are identical except for changelog. Would it warrant a sync?
[15:07] <LucidFox> Or would it be better to wait until intrepid?
[15:08] <slytherin> LucidFox: If you can provide enough proofs that there are no changes then I don't see a problem.
[15:08] <slytherin> But then I am not a developer.
[15:09] <sistpoty|work> LucidFox: if only the changelog is different, I'd rather sync now (then these will get autosynced when intreped starts)
[15:09] <Ng> sistpoty|work: thanks for the second terminator sync ack :D
[15:09] <hellboy195> sistpoty|work: btw. package is building in pbuilder!!
[15:09] <sistpoty|work> Ng: you're welcome ;)
[15:10] <sistpoty|work> hellboy195: up to date hardy pbuilder?
[15:10] <hellboy195> LucidFox: I suppose you build it too in pbuilder without problems?
[15:10] <hellboy195> siretart: yep
[15:10] <hellboy195> siretart: argh sry
[15:10] <LucidFox> hellboy195> haven't tried
[15:10] <hellboy195> sistpoty|work: yes. I also update pbuilder before building anything
[15:10] <LucidFox> (and I don't run Hardy anyway, even in pbuilder)
[15:11] <hellboy195> LucidFox: shouldn't you or do you trust me when I request syncs ^^
[15:12] <sistpoty|work> LucidFox: ahem... if you test-build a package meant for *hardy* your pbuilder must be hardy as well
[15:12] <LucidFox> sistpoty|work> Yes, I know
[15:13] <LucidFox> I use PPA for hardy test-building
[15:13] <geser> LucidFox: even for sync requests?
[15:14] <LucidFox> Well, I admit that I didn't test-build this one
[15:14] <hellboy195> Speaking form PPA. I can't upload something because I can't sign my packages
[15:14] <hellboy195> Enter passphrase: gpg: problem with the agent - disabling agent use
[15:14] <hellboy195> debsign: gpg error occurred!  Aborting....
[15:14] <hellboy195> debuild: fatal error at line 1174:
[15:14] <hellboy195> running debsign failed
[15:14] <hellboy195> LucidFox: I did it now and it built fine
[15:15] <slytherin> LucidFox: Why is using PPAbetter than using pbuilder?
[15:16] <LucidFox> slytherin> It isn't - it's simply too expensive for me to have a constantly updated Ubuntu release on my local machine, as I'm billed for traffic
[15:17] <slytherin> LucidFox: update it once a day. That should be sufficient I guess.
[15:18] <LucidFox> The frequency of updates doesn't matter - there's simply too much to download
[15:18] <geser> hellboy195: which release do you use? which program do you use for signing?
[15:18] <LucidFox> Russia. Screwed up ISP prices. $0.02/MB
[15:18] <LucidFox> (and I'm lucky to have even that)
[15:19] <jdong> LucidFox: ideally, you should find someone who would offer you ssh access to a build box
[15:19] <jdong> LucidFox: because with pbuilder you still have to continuously upload and download source packages
[15:19] <hellboy195> geser: gpgp . actual hardy release. well I did a debuild -S, or also tried "debsign" on the .changes
[15:19] <LucidFox> jdong> Oh, this is a neat idea.
[15:20] <jdong> yeah, ssh is always cheap :)
[15:22] <geser> hellboy195: normal signing with gpgp works?
[15:23] <hellboy195> geser: havn't tried yet. I'm a total newbie to that because for merging I don't need signing
[15:25] <hellboy195> geser: http://pastebin.com/m4b78c4b8 O_o
[15:26] <geser> nice, please file a bug if none exists. /me uses plain gpg/gpg2
[15:26] <hellboy195> geser: k
[15:27] <\sh> #
[15:27] <\sh> gpgp: xcb_xlib.c:73: xcb_xlib_lock: Assertion `!c->xlib.lock' failed.
[15:27] <sistpoty|work> LucidFox: btw.: any news on bug 194256 ?
[15:27] <ubotu> Launchpad bug 194256 in kmyfirewall "[FFe request] Please sync kmyfirewall 1.1.1-1 from Debian unstable (main)" [High,Incomplete] https://launchpad.net/bugs/194256
[15:27] <\sh> hmmm..this error message is known to me ,-)
[15:27] <hellboy195> \sh: wine? xD
[15:27] <\sh> hellboy195: nope...netbeans a couple of hours before now ;)
[15:28] <hellboy195> \sh: ^^
[15:28] <hellboy195> \sh: btw, any progress?
[15:29] <\sh> hellboy195: nope...0.9.56 crashes too...there is a solution coming up
[15:29] <hellboy195> \sh: the problem is/was?
[15:29] <\sh> hellboy195: problem looks like, that wine can't be started out of the wine source tree in the moment...
[15:29] <hellboy195> \sh: ah, k
[15:30] <LucidFox> sistpoty|work> I would have checked if it's reproducible, but I don't know how. I have no idea what "script" the upstream changelog is talking about.
[15:30] <geser> \sh: but gpgp isn't a java programm, is it? so this should be a different error
[15:32] <\sh> geser: but it was the same error and persia mentioned a bug report about it in LP...and there was a export VAR which solved my case...there are other workarounds...
[15:33] <hellboy195> \sh: still have the link?
[15:33] <\sh> https://bugs.edge.launchpad.net/ubuntu/+source/libxcb/+bug/185311 was it IMHO
[15:33] <ubotu> Launchpad bug 185311 in libxcb "hardy, locking assertion failure, xorg/libsdl" [High,Confirmed]
[15:36] <hellboy195> \sh: well. as geser said. no java program - no solution
[15:37] <sistpoty|work> LucidFox: ok, NACK from me on the sync then
[15:37] <LucidFox> All right, I'll wait until intrepid.
[15:38] <LucidFox> If someone identifies the specific issue, we can always backport the fix for hardy.
[15:38] <LucidFox> (backport to 1.1.0, I mean)
[15:39] <sistpoty|work> LucidFox: yes, or thoroughly test the package, as I wrote in the bug report ;)
[15:39] <hellboy195> geser:  gpg -s *.changes ?
[15:41] <\sh> hellboy195: when you read the bug report, the very first comment is not about java
[15:41] <\sh> hellboy195: it's about libxcb
[15:42] <\sh> hellboy195: the workaround actually is for java
[15:42] <geser> hellboy195: I use debsign but no gpgp/seahorse/... as agent (only the gnupg-agent)
[15:42] <hellboy195> \sh: yeah but I tried also export LIBXCB_ALLOW_SLOPPY_LOCK=1
[15:43] <\sh> hellboy195: yeah this is java only ;)
[15:43] <hellboy195> \sh: damn! ^^
[15:43] <geser> hellboy195: try unset GPG_AGENT_INFO and the debsign *.changes again
[15:43] <\sh> geser: I can't use seahorse
[15:43] <\sh> seahorse agent can't work with my cardreader
[15:44] <geser> \sh: I use the normal gnupg-agent (also as a ssh-agent)
[15:44] <\sh> geser: yes, that works :)
[15:44] <geser> but unfortunately gnome-keyring insists on overwriting my SSH_AUTH_SOCK everytime
[15:45] <hellboy195> geser: howto unset GPG_AGENT_INFO ?
[15:45] <\sh> LucidFox: Re: kmyfirewall the "IT DOES NOT INSTALL A VALID SCRIPT!"
[15:45] <geser> type "help unset" in a terminal (with bash)
[15:45] <\sh> LucidFox: can it be, that it's the server script firewall source to read the kmyfirewall data?
[15:46] <\sh> hellboy195: user@host: > unset GPG_AGENT_INFO
[15:46] <slicer> dholbach: Re bug 194836, it was my understanding that a feature freeze was not needed when there are only bugfixes involved?
[15:46] <ubotu> Launchpad bug 194836 in mumble "Update to 1.1.3 (bugfixes)" [Undecided,Confirmed] https://launchpad.net/bugs/194836
[15:46] <LucidFox> I don't know
[15:46] <hellboy195> \sh: Successfully signed dsc and changes files
[15:46] <hellboy195>   thx :)
[15:47] <\sh> LucidFox: build new upstream and make DESTDIR=<somewhere> with version in ubuntu and new upstream...you can see what's being installed and what not, so you know what "script thingy" means ;)
[15:47] <slicer> dholbach: If my understanding is wrong, would a link to the PPA buildlog satisfy the need for build logs? .. And should I file a new bug report, or just subscribe motu-release to the existing one?
[15:48] <hellboy195> Is my hardy crazy or did somebody remove gpgp from the repo xD
[15:48] <dholbach> slicer: no, you're right - I just read the changelog again and I think it'd qualify
[15:48] <geser> hellboy195: nope, it got removed
[15:48] <hellboy195> geser: why?
[15:49] <LucidFox> \sh> Or I can just run debdiff on deb files :)
[15:49] <geser> hellboy195: "(From Debian) RoQA; orphaned, uses gtk 1.x, has better alternatives
[15:49] <geser> "
[15:50] <geser> from http://people.ubuntu.com/~ubuntu-archive/removals.txt
[15:50] <slicer> dholbach: So. Er.. What do I do? Just ignore your comment? :)
[15:51] <hellboy195> dholbach: you forgot to thank me for my libdvdread merge. now I'm sad ^^
[15:51]  * dholbach hugs hellboy195 :-)
[15:51] <hellboy195> geser: ah. now I can't install it and report the seg fault
[15:51] <hellboy195> dholbach: :D
[15:52] <\sh> LucidFox: yepp
[15:52] <geser> hellboy195: if it isn't in hardy anymore we can't fix it anyway
[15:52] <geser> hellboy195: try an other gpg frontend (if you need one)
[15:52] <\sh> LucidFox: but DESTDIR comparison is much better, because it doesn't give you package maintainer bugs ,-)
[15:52] <hellboy195> geser: k
[15:53] <LucidFox> http://paste.ubuntu.com/5013/ <-- Hmm, might be worth syncing for the paths alone (top is Ubuntu, bottom is Debian)
[15:53] <LucidFox> actually, vice versa
[15:53] <LucidFox> top is Debian, bottom is Ubuntu
[15:54] <\sh> LucidFox: a script is still missing
[15:58] <\sh> LucidFox: or it means the "export" function for the scripts
[15:59] <LucidFox> This might be interesting: http://paste.ubuntu.com/5014/
[16:00] <LucidFox> (I deleted everything related to include files from the diff, to make the diffstat conscise)
[16:04] <LucidFox> and finally: http://paste.ubuntu.com/5015/
[16:06] <huats> am I the only one with an upgrade pb of my pbuilder ?
[16:07] <huats> it yells about a problem with python2.5 and python2.5-minimal
[16:07] <\sh> LucidFox: I'm convinced of the sync...just convince motu-release ;)
[16:08] <\sh> huats: yepp...I had to "apt-get -f install" after that
[16:08] <huats> \sh ok
[16:09] <huats> \sh just to wanted to be sure
[16:09] <huats> thanks
[16:10] <emgent> bug #176931
[16:10] <ubotu> Launchpad bug 176931 in lookup-el "[lookup-el] [CVE-2007-0237] possible local symlink attack" [Low,In progress] https://launchpad.net/bugs/176931
[16:10] <mruiz> hi all
[16:11] <sistpoty|work> dholbach: got a minute for a query?
[16:11] <dholbach> sistpoty|work: yes
[16:12] <nxvl_work> if a DM merges a package into ubuntu (an has done the changes) the maintainer is still MOTU or it doesn't need to change?
[16:15] <slicer> 16:47 < slicer> dholbach: If my understanding is wrong, would a link to the PPA buildlog satisfy the need for build logs? .. And should I file a new bug report, or just subscribe motu-release to the existing one?
[16:15] <slicer> Er.
[16:15] <slicer> Cut&paste major error. Sorry.
[16:16]  * slicer is noting things down in his dev-log :)
[16:19] <\sh> going home now
[16:28] <geser> nxvl_work: in Ubuntu every changed source package should have an Ubuntu email address as maintainer
[16:29] <nxvl_work> geser: yes, but i mean, if the DM is also an Ubuntu developer/contributor
[16:30] <geser> nxvl_work: if he has an ubuntu address he can put it in
[16:30] <bobbo> do new upstream versions require an FFe?
[16:30] <nxvl_work> geser: thnx :D
[16:30]  * nxvl_work HUGS geser
[16:30] <jpatrick> bobbo: yes
[16:30] <geser> bobbo: yes, unless it's a bug fix release
[16:30] <nxvl_work> bobbo: yup
[16:31] <bobbo> thanks
[16:32] <nxvl_work> what should i do with the "Uploaders:" field on debian/control?
[16:33] <geser> nxvl_work: Ubuntu doesn't use the Uploaders field
[16:33] <nxvl_work> geser: so remove it?
[16:33] <geser> it's only relevant for Debian
[16:33] <geser> nxvl_work: has the Debian package that field?
[16:34] <nxvl_work> geser: yep
[16:34] <geser> then leave it, gives a smaller delta between Ubuntu and Debian
[16:40] <nxvl_work> i have a doubt
[16:40] <nxvl_work> terminator was included in ubuntu before that on debian
[16:40] <nxvl_work> now we need to "sync" it from debian
[16:41] <nxvl_work> BUT, there is a change that must be done for it to work on ubuntu, do i need to make it as a bug fix or as a merge?
[16:41] <nxvl_work> (on the changelog)
[16:48] <geser> nxvl_work: terminator got uploaded as -0ubuntu1 to Ubuntu and Debian has it now as -1? then merge all still needed changes (or new changes) into -1ubuntu1
[16:49] <nxvl_work> geser: on ubuntu we have 0.7-0ubuntu2 and i'm merging 0.8.1-1 from debian
[16:49] <nxvl_work> (there is a problem with 0.7.orig.tgz)
[16:51] <geser> nxvl_work: then check the packaging of 0.7 for changes which should be kept for 0.8.1 in Ubuntu
[16:55] <nxvl_work> geser: i'm the DM and have package it for ubuntu, so i know the changes :D but do i write it on the changelog as a merge or as a bug fix?
[17:01] <geser> as a merge
[17:12] <Ng> nxvl_work: thanks for the debdiff :)
[17:12] <nxvl_work> :D
[17:32] <slangasek> geser: ok, blacklisting xen-unstable, thanks
[17:43]  * sistpoty|work heads home
[17:43] <sistpoty|work> cya
[17:53] <volksman> is this the right channel for packaging support? (IE I'm trying to package something and I'm having n00b issues)
[17:54] <RainCT> volksman: yes
[17:55] <RainCT> (for packaging support related to Ubuntu packages)
[17:55] <volksman> sweet...I managed to package Tomboy 0.9.4 for gutsy today.  I was pretty happy (second package ever)...but then I found a bug in the app and the developer told me to try 0.9.7
[17:56] <volksman> so I went about packaging it the exact same way....cept now once I get my deb I get this error when I try to install:
[17:56] <volksman> trying to overwrite directory `/usr/share/pixmaps' in package xfce4-appfinder with nondirectory
[17:56] <volksman> I have two icons that get installed in /usr/share/pixmaps but where is xfce4 getting involved?
[17:57] <RainCT> volksman: can you paste the output from "dpkg-deb --contents tomboy*.deb" somewhere?
[17:57] <volksman> yep...give me a sec
[17:58] <slangasek> volksman: that error indicates an error in your package that caused /usr/share/pixmaps to end up as a file within your package, not a directory
[17:59] <volksman> http://pastebin.ca/919214
[18:00] <volksman> slangasek: I was thinking along those lines but I haven't changed anything in the rules that affect the icons or anything to do with that path (I'm basically using the same rules as I used for the 0.9.4 build)
[18:01] <volksman> lintian dumps this:  E: tomboy: file-directly-in-usr-share usr/share/pixmaps
[18:02] <RainCT> yep, it's a file
[18:02] <RainCT> how are you installing the icon?
[18:02] <volksman> uudecode debian/tomboy-16.xpm.uu && mv tomboy-16.xpm debian/tomboy/usr/share/pixmaps
[18:02] <volksman> in install in rules
[18:03] <volksman> and that was taken from the 0.8.0 source
[18:03] <slangasek> yes, but you haven't created debian/tomboy/usr/share/pixmaps as a directory first
[18:04] <volksman> so a line like mkdir debian/tomboy/usr/share/pixmaps above that last one I posted would work for that?
[18:04] <RainCT> volksman: add a / at the end
[18:04] <RainCT> uudecode debian/tomboy-16.xpm.uu && mv tomboy-16.xpm debian/tomboy/usr/share/pixmaps/
[18:04] <volksman> it's weird this didn't present an issue with the 0.9.4 build I did earlier
[18:05] <RainCT> without the slash mv takes "pixmaps" as the name for the file and renamed "tomboy-16.xpm" to that..
[18:06] <RainCT> volksman: perhaps you had a mkdir before but removed it, or forgot the debian/dirs file or something?
[18:06] <slangasek> RainCT: and adding the slash will only change the error to "no such directory"
[18:07] <volksman>  mkdir debian/tomboy/usr/share/pixmaps
[18:07] <volksman>         uudecode debian/tomboy-16.xpm.uu && mv tomboy-16.xpm debian/tomboy/usr/share/pixmaps/
[18:07] <volksman> that should do it right?
[18:08] <RainCT> volksman: yes
[18:08] <volksman> sweet...thanks guys...I'm hoping to figure out this stuff then start helping with the MOTU team...packaging is very new to me though... :)
[18:09] <jeromeg> ls
[18:10] <jeromeg> oups :)
[18:10] <Iulian> Wrong window ;)
[18:10] <jeromeg> yep :)
[18:11] <jeromeg> pochu: hello, you are maintaining anjuta in Ubuntu ?
[18:13] <pochu> jeromeg: I update it from time to time, why?
[18:13] <pochu> jeromeg: although huats has done the latest one (2.3.5)
[18:13] <jeromeg> pochu: I was thinking about an SRU for gutsy, we are shipping 2.2.0 and 2.2.1 and 2.2.2 are bugfixes only releases, and really correct a LOT of issues
[18:14] <pochu> jeromeg: hmm, that would need a lot of testing...
[18:14] <pochu> jeromeg: what does upstream think about it?
[18:15] <jeromeg> pochu: did not ask, but 2.2.0 seems to be flagged as obsolete
[18:15] <jeromeg> it has really many issues, crashes, memory leaks...
[18:15] <pochu> that's weird
[18:15] <jeromeg> pochu: and 2.2.1 and 2.2.2 are bugfix only
[18:16] <jeromeg> pochu: changelog -> http://pastebin.com/m2a6f5cec
[18:16] <pochu> jeromeg: but upstream's input would be really helpful.  naba isn't on irc right now though
[18:17] <jeromeg> ok
[18:17] <pochu> jeromeg: are you confident updating packages?
[18:18] <jeromeg> pochu: I don't understand, you mean if I can do it ?
[18:18] <pochu> jeromeg: yeah, updating to 2.2.2 and uploading to a ppa for testing
[18:19] <jeromeg> pochu: yep, no problem, I should be able to do this
[18:19] <pochu> if testing in a ppa goes fine, we can ask for uploading to -proposed
[18:19] <pochu> and then asking for wider testing (perhaps an announce in the forums)
[18:20] <jeromeg> pochu: ok, I'll do this
[18:27] <jeromeg> pochu: on LP I can see there was a 2.2.3 release, but this release is not on the upstream website, how can that be ?
[18:28] <jeromeg> pochu: ok i found it :) sorry
[18:29] <volksman> thanks guys!  that new build worked for me....
[18:30] <jeromeg> pochu: in fact, I can take the previous hardy packaged version, no ?
[18:31] <pochu> jeromeg: yeah, should work
[18:32] <jeromeg> pochu: great
[18:53] <emgent> uhm
[18:53] <emgent> http://menpro.blogspot.com/2008/02/mark-shuttleworth-reveals-definitive.html
[18:53] <emgent> true news ?
[18:53] <emgent> "And so I'd like to introduce you to the monikers for our future release cycles," Mark announced, referring to the following list:
[18:53] <emgent>     * 9.04 - Jovial Jackal
[18:53] <emgent>     * 9.10 - Kissy Kipunji
[18:55] <bobbo> emgent: "Yodeling Yellow-spotted Rock Hyrax" i certainly hope not! that will be a mission to type out
[18:56] <anthony> Bother.  I just realized a flaw in my upgrade path scheme.
[18:56] <emgent> (:P
[18:56] <emgent> for me it's a fake list
[18:56] <bobbo> yeah it looks really fake
[18:57] <bobbo> like that announcement for Hardy saying it was going to be Hungry Hippo etc.
[18:58] <sweeny> considering it's filed under "humour"...
[18:58] <emgent> :P
[19:07] <ScottK> Is JeffreyRatcliffe here?
[19:10] <ScottK> Since when do we have a rule to open a new special bug if a candidate revision closes multiple bugs?  Anyone?
[19:11] <slangasek> ScottK: ...never?
[19:11] <slangasek> (is that the right answer? :)
[19:12] <ScottK> slangasek: That's what I thought, but reading https://wiki.ubuntu.com/MOTU/Contributing it appears either I'm wrong or the documentation is on crack.
[19:12] <ScottK> Seems silly to me.
[19:12] <ScottK> I always just told people to pick one bug to attach the debdiff to.
[19:16] <slangasek> ScottK: well, that line dates back to the initial version of that page, 2007-05-25; it's not something I've ever seen people insisting on though, and I agree that it's spurious
[19:17] <ScottK> slangasek: I'm adding a discussion of it to the agenda for the next MOTU meeting now.
[19:18] <ScottK> Unfortunately the next MOTU meeting is at 1200 UTC and I'll be in -0800 on that day, so I probably won't make it.
[20:05] <mok0> I feel my good old self now
[20:14]  * jpatrick hugs mok0 
[20:15]  * mok0 hugs back
[20:17] <mok0> I just checked out the submissions to the LP logo contest. Amazing! Too bad only one can win!
[20:17] <james_w> Anyone have an ftp server with SSL support running?
[20:18]  * slangasek shudders and runs away :)
[20:24] <james_w> slangasek: :)
[20:25] <mok0> james_w: why not use sftp?
[20:25] <james_w> mok0: it's not me, it's bug 175930
[20:25] <ubotu> Launchpad bug 175930 in gnutls13 "SSL_ERROR_ZERO_RETURN for no reason" [Undecided,New] https://launchpad.net/bugs/175930
[20:25] <mok0> ah
[20:26] <james_w> I can't seem to get the right setup to reproduce, so I wondered if someone had one ready to try, but I realise it is a longshot.
[20:27] <mok0> james_w: It's a pretty unusual setup
[20:28] <broonie> james_w: gnutls tends to have interop errors, it may well depend on the particular server.
[20:29] <james_w> broonie: that's true.
[20:29] <slangasek> what interop errors?
[20:30] <slangasek> short of "no we won't support encryption algorithms that I can break on my handheld calculator", I'm not aware of any protocol interop problems with it...
[20:31] <Nafallo> :-)
[20:31] <broonie> slangasek: TBF, the interop problems are often as much the fault of the remote end as of gnutls itself.
[20:31] <james_w> slangasek: there are a few, but yes, it is often with closed source implementations at the other end.
[20:33] <slangasek> huh, ok
[20:33] <slangasek> any references?
[20:33] <broonie> eg, none of the Nokia internet tablets can talk to Debian exim with TLS.
[20:33] <slangasek> neat
[20:34] <james_w> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402861
[20:34] <ubotu> Debian bug 402861 in libgnutls13 "errors establishing TLS session from Nokia and SE mobile phones" [Normal,Open]
[20:36] <james_w> slangasek: this is the sort of fun you'll be letting yourself in to.
[20:38] <slangasek> james_w: mm?
[20:38] <james_w> slangasek: with openldap
[20:40] <slangasek> james_w: ah, I think we've already weathered all of that fun :)
[20:40] <bobbo> are there any spare MOTUs that could review Bug #195806 for me?
[20:40] <slangasek> no new bug reports about TLS incompatibilities since the first round were fixed
[20:40] <ubotu> Launchpad bug 195806 in purrr "please update purrr to version 0.8" [Undecided,In progress] https://launchpad.net/bugs/195806
[20:40] <Nafallo> damnit! forgot my laptop at work :-/
[20:40] <james_w> slangasek: ah, great.
[20:41] <tbf> broonie: huh?
[20:41] <slangasek> tbf: "To be Fair", not meaning to highlight you :-)
[20:42] <anthony> Nafallo: No fun.  I once forgot my power adapter at school, and didn't realize it until my lappy started beeping at me to say I had 10 minutes left.
[20:42] <tbf> slangasek: afaik "TBF" is not useful as acronym. just look there: http://acronyms.thefreedictionary.com/Tbf
[20:43] <slangasek> it was clear enough to me :)
[20:43] <Nafallo> anthony: I forgot my charger at work last Friday, and I was on-call that night :-P
[20:43] <mok0> Total Body Failure
[20:44] <mok0> :P
[20:44] <secretlondon> where is a good place to get help with a main inclusion report that is needed to fix a ftbfs bug?
[20:44] <Nafallo> anthony: at least I'm not on-call tonight :-P
[20:44] <anthony> Nafallo: that's helps, yes
[21:06] <geser> secretlondon: I'd ask the people processing them in #ubuntu-devel. IIRC pitti is doing MIRs.
[21:07] <secretlondon> geser: thanks. I'm a beginner so don't know how to fill out the packaging stuff so I'm not sure it's ready for pitti yet
[21:09] <geser> secretlondon: I haven't done a MIR yet, but I'd try to understand the wiki page and the ask in #ubuntu-devel for help
[21:10] <geser> secretlondon: btw: which FTBFS are you trying to fix?
[21:10] <secretlondon> geser: they have sections which need packaging experience I think to answer
[21:10] <secretlondon> geser: tuxtype - it needs the promotion of sdlpango
[21:11] <jpatrick> secretlondon: which sections, we can help :)
[21:13] <geser> secretlondon: perhaps also ask ogra (the last uploaded). Last I asked him about tuxtype he wanted to look at it (move sdlpango to main).
[21:14] <secretlondon> geser: I know another package in edubuntu main will need sdlpango promoted once the current version is synced
[21:14] <emgent> heya pople
[21:15] <secretlondon> geser: as tuxpaint 0.9.18+ has it as a dep too
[21:15] <geser> Hi emgent
[21:15] <emgent> heya geser :P
[21:15] <emgent> keescook, ping
[21:16] <geser> secretlondon: you were talking about you don't know how to fill out the packaging stuff? You mean point 5 of the MIR template?
[21:17] <secretlondon> geser: 5 is fine (thats just the build deps), it's 4 I can't do
[21:17] <secretlondon> geser: to do with standards compliance
[21:18] <secretlondon> geser: this is my work so far https://wiki.ubuntu.com/MainInclusionReportTemplateSDLPango?action=show
[21:19] <geser> secretlondon: you are off-by-one :) you use 1. twice
[21:19] <secretlondon> argh
[21:20] <secretlondon> yeah it's the standards compliance bit anyway ;)
[21:21] <geser> let's start with the easy part: packaging system
[21:21] <geser> I assume you have the source package ready
[21:22] <secretlondon> no i'll just get - though cdbs and quilt are deps
[21:23] <secretlondon> oh I do have actually
[21:23] <geser> secretlondon: if you know that cdbs is a packaging system and quilt a patch management system then you can already answer two questions from that bullet
[21:24] <secretlondon> geser: no I thought they were both patching
[21:24] <bmhm> hi, I'd like to request this backport once again :)
[21:24] <bmhm> https://bugs.launchpad.net/gutsy-backports/+bug/192751
[21:24] <ubotu> Launchpad bug 192751 in gutsy-backports "Backport of network game "pioneers"" [Undecided,Confirmed]
[21:26] <jpatrick> bmhm: why is --force needed?
[21:26] <bmhm> jpatrick: this was when using original packages
[21:27] <bmhm> I should clearify it
[21:27] <geser> secretlondon: if you look into debian/rules you will see that it includes files from /usr/share/cdbs -> cdbs packaging system
[21:27]  * secretlondon looks
[21:28] <secretlondon> ok
[21:28] <geser> secretlondon: if you then also check which files are included you'll see /usr/share/cdbs/1/rules/patchsys-quilt.mk which is also pretty obvious from the name
[21:28] <secretlondon> yep
[21:28] <geser> it uses quilt for patch managing
[21:28] <secretlondon> ok
[21:29] <secretlondon> oddities - there's something to do with autotools in there somewhere as a patch
[21:29] <bmhm> jpatrick: I hope its a little more clearly described by now
[21:29] <geser> I wouldn't count that as oddities, that's normal use
[21:29] <secretlondon> ok
[21:30] <geser> I just looked at the diff.gz but I can't find any oddities
[21:31] <geser> a packaging oddity would be for me a part from the packaging I can't understand on the first look (or at all)
[21:32] <geser> but I see that it's a library, so let's check the Debian library packaging guide as next
[21:34] <geser> secretlondon: from debian/libsdl-pango1.install
[21:34] <geser> you can see that it will contain only the lib itself -> ok
[21:36] <geser> from debian/libsdl-pango-dev.install you'll see that it includes the headers, the files needed for linking and some documention -> everythin ok
[21:37] <geser> the package names follow the usual packaging scheme -> ok
[21:39] <geser> secretlondon: so after a quick look the package follows the library packageing guide
[21:39] <geser> secretlondon: and also the FHS as there are no unusual dirs in the debs
[21:40] <geser> what's left? the Debian policy compliance
[21:41] <geser> I would check it with linda and lintian and when both doesn't scream loud (many errors) say that it follows the policy (perhaps include the output of both)
[21:42] <geser> secretlondon: any questions?
[21:45] <geser> secretlondon: where have I lost you?
[21:45]  * secretlondon curses her flaky hsdpa modem
[21:45] <secretlondon> my last thing was asking about whether 6 patches was a lot
[21:45] <secretlondon> I didn't get a reply
[21:46] <geser> secretlondon: last I've seen from you is [22:30:02] secretlondon | ok
[21:46] <secretlondon> ah ok
[21:46] <geser> 6 patches aren't many (they aren't even big)
[21:46] <secretlondon> 21:32 secretlondon> is 6 patches quite a lot - does that indicate that upstream is a bit slow?
[21:47] <secretlondon> ok
[21:47] <geser> the changes from config.{sub,guess} come from using an new version of those files from autotools-dev
[21:49] <geser> secretlondon: the one that would trouble me at most from all is api_additions.patch
[21:49] <geser> patching the api of a library can call for trouble later
[21:50] <secretlondon> it apparently closed debian bug #437865
[21:50] <ubotu> Debian bug 437865 in libsdl-pango-dev "libsdl-pango-dev: Please add #define's to identify API extension patch" [Wishlist,Fixed] http://bugs.debian.org/437865
[21:51] <secretlondon> ah - its a patch on a patch
[21:52] <secretlondon> that actually dates back to 2006 "api_additions.patch: patch from Guillaume Cottenceau to add some
[21:52] <secretlondon>     missing functions"
[21:53] <geser> secretlondon: http://paste.ubuntu.com/5023/ is the log of what you have missed
[21:54] <secretlondon> geser thanks
[21:55] <geser> no problem
[21:55] <secretlondon> but the fact that we have an api that upstream don't have worries me
[21:57] <geser> yes, me too
[21:59] <slangasek> is it an ABI difference, or just an API difference?
[21:59] <geser> I'd list it somewhere in the report but don't know where
[21:59] <geser> slangasek: API addition according to the patch name
[22:00] <secretlondon> I'm going to add it in background info
[22:00] <slangasek> so it doesn't break ABI compatibility with upstream?
[22:00] <slangasek> I wouldn't worry overly much about that
[22:01] <secretlondon> ok
[22:02] <geser> slangasek: doesn't look like, the modified header file has only additions (no replacements)
[22:03] <slangasek> geser: uhm, but additions of what?
[22:04] <slangasek> geser: if it's adding new entry points into the library, that's an ABI difference, and something to be wary of (though not necessarily in this context)
[22:04] <geser> slangasek: some code it moved into there own functions but the the old functions call the new ones
[22:05] <slangasek> perhaps you could point me to the patch in question?  I think looking at it would be easier
[22:05] <geser> api-additions.patch in sdlpango
[22:05] <persia> ScottK: I'm running off, but I added the request to file a new candidate bug when there were multiple fixes because when I was a contributor, I had several complaints from both bug reporters and sponsors that I was confusingly combining things in patches.  This was intended to avoid that.
[22:06] <persia> I've no strong attachment to the practice, if it is consensus that it is incorrect.
[22:06] <ScottK> persia: OK.  It was the first I heard of it when I say a diff of the related page.
[22:07] <ScottK> persia: At most I'd say it's a may not a must.
[22:07] <persia> ScottK: Agreed.  Definitely "may".  The only intention was to avoid confusion.  Feel free to adjust phrasing if you like (I'm not sure must -> may for that needs a meeting item)
[22:08] <ScottK> persia: Will do.  Thanks.
[22:08] <geser> slangasek: or should I pastebin it?
[22:09] <slangasek> geser: nope, looking already; the patch looks to me like an ABI change
[22:09] <slangasek> I'm double-checking the binary package
[22:10] <geser> slangasek: if I understood libraries correctly, it's only a problem if a Debian/Ubuntu binary linked against this lib is used with an plain upstream version, correct?
[22:11] <geser> programms linked with the "clean" lib should also continue to run with our version, also correct?
[22:12] <slangasek> geser: it's also a problem if upstream later adds functions under these same names but with a different prototype, without changing the soname, which they're entitled to do
[22:13] <geser> true
[22:13]  * persia notes that this is the sort of change that upstream can make without an ABI transition, but cannot be made by a distribution without confusion.
[22:15] <ScottK> persia: Updated and removed from the agenda.  Thanks.
[22:16] <persia> ScottK: Thanks for the review.  The wiki is often behind current usage, and in cases where this isn't a result of lax compliance, the updates are exceedindly helpful
[22:22] <secretlondon> http://sourceforge.net/tracker/index.php?func=detail&aid=1882228&group_id=110621&atid=657085 may refer to the api patch
[22:22] <ubotu> Gaim bug 1882228 "API extension for Frozen Bubble" [Pri: 5,Open]
[22:23] <secretlondon> that claims that freebsd also have the same patch as debian, and it is for frozenbubble
[22:28] <pochu> superm1: do you work for dell?
[22:28] <mario_limonciell> pochu, yes
[22:34] <mario_limonciell> pochu, i attached a debdiff to the debian bug of gst-plugins-base0.10 since it looks like we sync from there normally, but they haven't shown up in the BTS for the last 30 minutes for some reason or another
[22:42] <pochu> mario_limonciell: Debian bug 468073 ?
[22:42] <ubotu> Debian bug 468073 in gst-plugins-base0.10 "gst-plugins-base0.10: Gstreamer inputs default to outdated V4L,and require to be changed to V4L2 on first run" [Normal,Open] http://bugs.debian.org/468073
[22:42] <mario_limonciell> pochu, yeah
[22:43] <pochu> mario_limonciell: did you send it to 468073@bugs.debian.org?
[22:43] <mario_limonciell> pochu, yeah
[22:44] <pochu> mario_limonciell: you can attach it to the ubuntu bug too, slomo is subscribed there so he'll receive it
[22:44] <mario_limonciell> sure
[22:44] <pochu> thanks
[22:56] <mario_limonciell> pochu, weird, i attached a debdiff to an ekiga debian bug 5 minutes ago and it showed up immediately.
[22:59] <crimsun_> how large was the gst-plugins-base0.10 debdiff vice the ekiga one?
[23:00] <mario_limonciell> 2k each
[23:14] <mario_limonciell> crimsun_, did you get a chance to look over bug 193823?
[23:14] <ubotu> Launchpad bug 193823 in alsa-utils "HDA Intel cards with "Digital" capture mixers default to a  very low volume" [Medium,In progress] https://launchpad.net/bugs/193823
[23:18] <crimsun_> mario_limonciell: no, thanks for the heads-up.  (I travel without reliable 'net access, so I'm no longer in the bug contact group)
[23:19] <mario_limonciell> crimsun_, ah okay.  thanks :)
[23:19] <mario_limonciell> rtg was going to apply it, but then got scared of bzr
[23:22] <crimsun_> mario_limonciell: mm, on which codecs?
[23:22] <crimsun_> mario_limonciell: just Sigmatels?
[23:22] <mario_limonciell> well i've only verified it on sigmatels
[23:23] <crimsun_> mario_limonciell: there are some Conexant and Realteks that will do nasty things if that and PCM are set higher than 50%
[23:23] <mario_limonciell> but do they have a mixer entitled "Digital"
[23:23] <mario_limonciell> or is it named different?
[23:24] <crimsun_> the name string really isn't terribly important
[23:24] <crimsun_> which node id is it?
[23:24] <mario_limonciell> give me a sec
[23:24] <crimsun_> some do have "Digital", but the node id is more important, since you can just whack the name string
[23:26] <pochu> mario_limonciell: if I renew my laptop, I'll consider switching to a dell so I can bug you if something doesn't work :P
[23:26] <mario_limonciell> crimsun_, looks like it should be 0x20
[23:26] <mario_limonciell> pochu, hehe
[23:27] <crimsun_> mario_limonciell: ok, I'll check the Realteks tonight
[23:27] <mario_limonciell> crimsun_, well actualyl there are two digital inputs, hopefully that's the right one, 0x22 is marked as a pin complex, but 0x20 is marked as an Audio Input
[23:27] <crimsun_> mario_limonciell: otherwise, it looks fine - just need to verify it doesn't break others
[23:28] <mario_limonciell> crimsun_, okay, let me know if you need anything more
[23:31] <mario_limonciell> ah a little more detailed, the node info on 0x20 lists a connection to 0x22.
[23:32] <secretlondon> geser: I've done some digging and it looks like many distros have added the patch. upstream may be dead tho
[23:32]  * secretlondon is finally going to bed and will continue tomorrow..
[23:34] <crimsun_> mario_limonciell: excellent, thanks.
[23:34] <crimsun_> mario_limonciell: merged tentatively as revision 4
[23:35] <mario_limonciell> crimsun_, great
[23:45] <emgent> superm1, ping
[23:47] <mario_limonciell> emgent, that's my second name, what's up?
[23:47] <emgent> heya mario_limonciell
[23:48] <emgent> vlc patch is out for CVE-2008-0984
[23:48] <emgent> i saw that you are debian maintainer
[23:48] <slangasek> mario_limonciell: "ping" is your second name? :)
[23:48] <emgent> please consider
[23:48] <emgent> http://www.videolan.org/security/sa0802.html
[23:48] <emgent> for upload :)
[23:48] <mario_limonciell> slangasek, yup :)
[23:48] <emgent> it's a security issue
[23:48] <mario_limonciell> emgent, did you file a bug for it already in LP?
[23:49] <emgent> yep
[23:49] <emgent> wait
[23:49] <emgent> https://bugs.edge.launchpad.net/ubuntu/+source/vlc/+bug/195949/
[23:49] <ubotu> Launchpad bug 195949 in vlc "VLC Arbitrary memory overwrite in the MP4 demuxer" [Medium,In progress]
[23:49] <emgent> i'm patching it now.
[23:49] <emgent> pbuilting test
[23:49] <mario_limonciell> emgent, sure i'll be glad to help push  that around to the correct builds.  just subscribe me to the bug and let me know when you've made sure the builds don't break
[23:50] <emgent> ok sure
[23:50] <emgent> Thanks