[00:39] <TheMuso> c
[00:42] <RAOF> :)
[00:48] <ajmitch> ugh?
[03:13] <wgrant> jdong: You're a forum person, aren't you?
[03:13] <jdong> wgrant: I am.
[03:13] <wgrant> jdong: How does one get one's account renamed?
[03:13] <jdong> wgrant: depends on the reason for it being renamed. officially we don't do it, but extenuating circumstances can be evaluated :)
[03:14] <wgrant> Ah. Damn.
[03:14] <Hobbsee> jdong: do you want anything else sponsored ever again?  If so, you'd better do the rename :P
[03:15] <jdong> wgrant: that extenuating circumstances part was an invitation to PM.
[03:15] <jdong> :)
[03:15] <wgrant> jdong: Aha.
[03:31] <RAOF> directhex: Rock!  monodoc 1.9
[03:56] <Tetracomm> Hello.
[03:56] <Tetracomm> https://bugs.launchpad.net/bugs/272210
[03:57] <RAOF> Tetracomm: That's unlikely to see any action until after the Intrepid release.
[03:57] <Tetracomm> Why?
[03:58] <suicideducky> hello there, I am not sure if this is the right place to ask, but how would I go about helping out with MOTU activies / becomming a MOTU??
[03:58] <wgrant> Tetracomm: FeatureFreeze was months ago.
[03:58] <Hobbsee> Tetracomm: because there's a release in under a month?
[03:58] <wgrant> suicideducky: The topic has a good link.
[03:58] <Tetracomm> :(
[03:58] <wgrant> Hobbsee: Shh, don't tell the users.
[03:58] <suicideducky> hahahaa thanks wgrant >.<
[03:59] <Hobbsee> wgrant: oh. my bad.
[03:59] <Tetracomm> I really want to see it packaged.
[04:00] <Tetracomm> Could anyone recommend any software that would help me to create a .deb package?
[04:01] <wgrant> There's no magic incantation that will do it.
[04:01] <RAOF> !packagingguide
[04:01] <RAOF> There's the software.  It runs on your brain :)
[04:06] <Tetracomm> That takes too long.
[04:07] <Hobbsee> Tetracomm: which is precisely why things don't get put into the release, so late, when people are focussing on existing bugs.
[04:07] <Tetracomm> Ok.
[04:09] <Tetracomm> I really want to help, but that looks so complicated,
[04:09] <Tetracomm> .
[05:28] <ScottK> jdong: Given the firefox propensity for security problems, I think you either ought to update it in gutsy-backports or remove it.
[05:29] <jdong> ScottK: agreed; I shall work on upgrading it over the weekend.
[07:20] <didrocks> NCommander: too much love :) (even by error ^^)
[07:21] <didrocks> morning :)
[07:21] <geser> Hi didrocks
[07:46] <IntuitiveNipple> I have an interesting packaging bug with xorg-server (hardy). A patch (21_glx_align_fixes) modifies ./configure.ac, *but* ./configure is not rebuilt, and ./configure isn't patched to match. This causes a FTBFS for the xdmx module, so that in turn was disabled (debian/rules ... --disable-dmx) as the 'fix' - the real fix would be to either patch ./configure or ship the package with the regenerated ./configure. How should this kind of issue
[07:46] <IntuitiveNipple>  be dealt with?
[07:48] <StevenK> Also patch configure in the same patch by regenerating ./configure with the *same* autoconf version
[07:49] <IntuitiveNipple> StevenK: Thanks
[07:49] <directhex> regenerate configure, distribute as a patch. that's how the packages i work with do it
[07:49] <IntuitiveNipple> I thought that would be it, but it can get confusing, all the levels of indirection
[07:55] <IntuitiveNipple> 2nd question. In the package, it builds some dbus bits and includes <dbus/dbus.h> but  libdbus-1-dev installs to /usr/include/dbus-1.0/dbus/dbus.h - do all the source-files get patched or is a symlink supposed to have been created in /usr/include/ by libdbus-1-dev ?
[07:57] <StevenK> Neither
[07:58] <StevenK> A -I flag should be added to gcc calls by autoconf
[07:59] <IntuitiveNipple> ahhh good point :0
[08:01] <IntuitiveNipple> and finally... 3rd question. The xorg-server source package, as shipped contains a whole bunch of symlinks, obviously accidently put there by some previous packager (e.g. GL/mesa/main/stencil.c -> /home/david/debian/xorg/git/lib/mesa/src/mesa/main/stencil.c) - should they be removed?
[08:14] <persia> IntuitiveNipple: Nothing in base packages should either generate or depend on anything in /home, as I understand things.  Cleaning that up is probably a good idea.
[08:14] <IntuitiveNipple> persia: yeah, that was my thought :)
[08:15] <Burgundavia> IntuitiveNipple: that is probably david nusinow, one of the main debian xorg people
[08:15] <persia> IntuitiveNipple: You'll be linking your git branch to a bug, and praising it's benefits in #ubuntu-x, right?
[08:16] <IntuitiveNipple> perisa: It *looks* like someone was experimenting, trying to fix the FTBFS for dmx - which is caused by the incorrect 21_glx_align_fix patch
[08:16] <IntuitiveNipple> Burgundavia: Yes, I thought that, having looked at changelog
[08:16] <IntuitiveNipple> persia: Will I?
[08:17] <IntuitiveNipple> #join #ubuntu-x
[08:17] <IntuitiveNipple> oops lol
[08:17] <persia> IntuitiveNipple: I hope so.
[08:17] <persia> IntuitiveNipple: Also, where did you stick your patch to get kvm compiling on lpia?  I noticed it still FTBFS in the archives a couple days ago, and wanted to push that.
[08:18] <IntuitiveNipple> persia: you've lost me? what git branch?! I don't have the package git externally visible :)
[08:18] <IntuitiveNipple> persia: sheesh! Um, the source of kvm-74 in my PPA (one of the patches I think)
[08:18] <persia> IntuitiveNipple: You're not basing your xorg-server stuff off the ubuntu git tree?  I'll go find it.
[08:18] <persia> Thanks.  I'll see if I can extract it easily.
[08:19] <IntuitiveNipple> persia: let me look locally
[08:19] <persia> IntuitiveNipple: Thanks.
[08:19] <IntuitiveNipple> persia: 1:72+dfsg-0ubuntu1~ppa4h "Fix: add debian/rules build capability for lpia and ia64"
[08:20] <IntuitiveNipple> persia: Inherited by 1:74 of course
[08:21] <persia> Right.  I'll try that against the current version in the archive.  One of my lpia laptops strangely supports vmx, and I'll actually use it.
[08:21] <IntuitiveNipple> persia: If I recall correctly, I added "	QEMU_EXE = qemu-system-x86_64" to each of the lpia and ia64 cases
[08:21] <persia> Looks like the git tree is git://git.debian.org/git/pkg-xorg/xserver/xorg-server : I'm not sure how the Ubuntu branch is stored.
[08:22] <persia> IntuitiveNipple: Hrm.  lpia isn't 64-bit.  I'll try that, and in the worst case, try shifting it to x86.
[08:22] <IntuitiveNipple> persia: oh, yeah. I saw the 'packaging' git reference but I've been working on the apt-get source package
[08:22] <IntuitiveNipple> persia: No, there are two cases... the statement is added into both
[08:22] <persia> Yeah, the apt-get source is a little out of date for X, as X moves pretty quick.
[08:22] <IntuitiveNipple> persia: It doesn't do what it suggests... hence my original confusion when it first came up
[08:23] <persia> Oh, so x86_64 doesn't actually mean x86_64?
[08:23] <IntuitiveNipple> persia: strangely... no lol - it is just, if I recall correctly, a build dir or something similarly transient
[08:24] <IntuitiveNipple> persia: The build-logs on my PPA will reveal how it is used
[08:24] <persia> heh.  Right.  Well, when we last talked about it, my only lpia kit didn't support vmx, but Intel seems to have lost sight of the "L" in lpia, so I've a testbed now.
[08:25] <persia> (well, it's still low-wattage, but it's dual-core with vmx, which doesn't strike me as trying to save every last joule)
[08:25] <StevenK> Power Intel Architecture!
[08:28] <IntuitiveNipple> persia: re xorg-server: hardy ships all the xdmx tools but not the module since it was FTBFS (the ./configure not patched issue), so I'm just fixing it so it will provide the xdmx module (1 or 2 other knock-on effects I'm chasing too).
[08:28] <persia> I don't suppose you could do that for intrepid?  It's more likely to be easy to apply, and more likely to be beneficial to more people.
[08:31] <IntuitiveNipple> persia: It looks as if 1.5.1 (Intrepid) has it fixed
[08:31] <persia> Oh, cool.  No worries then.
[08:31] <persia> Thanks for checking.
[08:31] <IntuitiveNipple> persia: at least, it has --enable-dmx in debian/rules and I assume it isn't FTBFS
[08:31] <persia> You'd have to check build logs to verify, but I think someone would notice.
[08:32] <IntuitiveNipple> persia: package xdmx is in universe
[08:32] <persia> Excellent then :)
[08:33] <IntuitiveNipple> I've been using the Intrepid package as a clue-stick to sort out the hardy 'mess' :)
[08:33] <IntuitiveNipple> persia: xdmx is allowing me to run 5 monitors on the laptop :p
[08:37] <persia> IntuitiveNipple: USB<->VGA ?
[08:38] <IntuitiveNipple> persia: DFT, VGA, s-video (projector), and xdmx to a dual-matrox 'twinview'
[08:38] <persia> And the rest of the dual-matrox is just a headless server?
[08:39] <IntuitiveNipple> persia: no, with xdmx the remote xserver becomes an extension of the local desktop
[08:40] <persia> Right, but I'm guessing the remote computer running the xserver also becomes effectively headless, doesn't it?
[08:40] <IntuitiveNipple> once i'd built the module and got the configuration sorted, I wanted to get the package to build too, so others can use it
[08:40] <persia> (because it's granted access to the xserver to the remote session)
[08:41] <IntuitiveNipple> persia: oh, I see what you mean... well, it seems there are several ways it can be done, both with the remote logged in, or logging in remotely. right now I've got 'dual-control'
[08:41] <persia> Ah, so the xserver provides access for both the remote box and a local session?
[08:44] <IntuitiveNipple> Until you mentioned it, I'd not really thought about it! I was just pleased when I finally got it to work :)
[08:44] <IntuitiveNipple> I'll write up a wiki article on it once I'm clear :)
[08:47] <persia> IntuitiveNipple: Thanks.  Now you just have to find a minion who will mine your wiki for all the good bits :)
[08:49] <IntuitiveNipple> persia: It's called 'Google' :)
[08:49] <IntuitiveNipple> and, there's only 'good' bits on my wiki!
[08:50] <persia> IntuitiveNipple: Well, I'd say 80% : you move quickly enough that there's sure to be a fair bit of bitrot.
[08:51] <persia> And my only issue with Google is that it doesn't have the patience to push the patches back to Debian and upstream :)
[08:52] <IntuitiveNipple> it's only a matter of time :)
[08:53] <persia> heh.  I suppose.
[08:54] <IntuitiveNipple> funny you should mention that, actually. with the thread on the -devel mailing list I was working out an AI-based upstream patch submitter... give it a couple of 'best practice' bugs to to follow and then it'll figure it out for new bugs that have Ubuntu patches
[08:55] <norsetto> \sh: around?
[08:55] <persia> Nifty.  That would certainly solve some of the Ubuntu patch discussions, and probably be of inestimable value to you in not having to forward-port stuff.
[09:30] <volkris> How do I package a program that is distributed in multiple source files?
[09:31] <persia> volkris: In multiple source packages.
[09:32] <persia> For example, consider a game that has separate upstream releases for the server, the artwork, the engine, the module, and the sound server.
[09:32] <persia> This would be 5 different source packages, and probably 7-8 binary packages, depending on the contents of the source packages, and how they should be installed.
[09:33] <persia> In my example, you could then add new packages for other contributed scenarios or artwork, and it would still work.
[09:33] <volkris> can you think offhand of a package that does this?
[09:34] <persia> uqm, uqm-content, uqm-voices, and uqm-music.
[09:34] <volkris> I'll read up. Thanks.
[09:34] <persia> That's multiverse, but it's the package like that I've touched the most.
[10:42] <quadrispro> DktrKranz: what do you think about bug 275502 ?
[11:18] <es> hello, I've followed https://wiki.ubuntu.com/PackagingGuide/HandsOn and I succesfully build a newer version of a package (sympa). dumb question: where is it? debuild -S -sa completed succesfully but I don't see the deb...
[11:19] <azeem> debuild -S is for building source packages
[11:19] <persia> es: You've successfully built an updated source package.  Congratulations.  To convert that into a binary package, you'll need to build it.
[11:19] <azeem> look for .dsc and .diff.gz in the parent directory
[11:19] <persia> Personally I use sbuild, for that, but many people use pbuilder.
[11:19] <persia> !sbuild
[11:19] <persia> !pbuilder
[11:20] <es> thanks I'm looking to those links
[11:29] <IntuitiveNipple> Do we have any xorg-server build experts ?
[11:33] <persia> They tend to live in #ubuntu-devel, xorg-server being fairly core.
[11:35] <volkris> In the package I'm working on I need to extract one tarball of makefiles and such, then another tarball of code that goes into the src/ subdirectory of the first.
[11:35] <volkris> I don't know that this is the situation persia had in mind when  he said to distribute separate source pacakges
[11:36] <volkris> The result of the compilation is basically a single executable file, but I don't know how to handle .orig files and such
[11:36] <james_w> does anyone have a clue what the fix for the build problem in https://bugs.launchpad.net/bugs/271919 might be?
[11:37] <persia> volkris: Ah.  I thought of separate sources that weren't so intertwined.  No good suggestions for that : maybe a fiendishly compliex get-orig-source, or some sort of stacked tarball-in-tarball solution?
[11:37] <volkris> I figured some other package somewhere would have dealt with this matter before
[11:38] <volkris> I've packaged on gentoo pretty regularly, and they  have ways of extracting to specific places in the source tree
[11:38] <volkris> Could repackaging end up being reasonable in this case?
[11:39] <RAOF> volkris: That sounds like the only option, really.
[11:39] <persia> Maybe, although I'd personally prefer to see layered tarball-in-tarball, as much as I generally dislike that format.  repacking breaks md5sum verification against upstream.
[11:39] <RAOF> Something in source package format 3.0 might support you more, but nothing accepts it yet.
[11:39] <persia> RAOF: No.  There remain many options, just none pretty.
[11:40] <volkris> is unpacking of tarball in tarball handled through get-orig-source?
[11:40] <persia> james_w: You might catch NCommander later : seems to be handy with the libtool change.
[11:40] <persia> volkris: No.  get-orig-source would construct your tarball-in-tarball orig.tar.gz.
[11:40] <volkris> I'll look into it
[11:41] <persia> Then you need to add extra targets in debian/rules to unpack the tarballs in the right way, usually into a ./build/ directory defined in the diff.gz.
[11:41] <quadrispro> anyone on bug 275502?
[11:41] <persia> volkris: Be prepared for someone to complain about tarball-in-tarball, but it's slightly less distasteful than repacking.
[11:42] <volkris> This is pretty specialized software for running particle accelerators, so I probably won't worry too much about distribution outside of the lab
[11:43] <persia> volkris: Perhaps, but I'll encourage you to share it : other labs might find it useful, and I'd guess that having a somewhat standard system would let you actually focus on the problem, rather than managing particle accellerator drivers.
[11:44] <persia> (plus I want to be able to say "Here's an Ubuntu disk.  It gets used for lots of things.  It can even run your particle accellerator")
[11:44] <volkris> ha. Well, PPA at least
[11:45] <persia> Well, PPA for now.  Come back in December, and we'll get it in the distro properl.
[13:29] <sebner> james_w: well, we have to decide if we want an ipe that can handle *normal* ipe files or ubuntu ones :(
[13:29] <james_w> sebner: yeah, it sucks
[13:29] <james_w> I think it's partly the programs fault for using symbolic names in the files
[13:30] <sebner> james_w:  ^^, the problem is we started patching ipe with feisty IIRC :\
[13:31] <sebner> james_w: however, thx for you work :)
[13:31] <james_w> no problem
[13:33] <sebner> james_w: now you are a sponsor of mine :P
[13:35] <morgs> I'm trying to copy a package in my PPA from hardy to intrepid, and I get "The following source cannot be copied: sugar-artwork 0.82.0-1ubuntu1~ppa1 in hardy (same version already has published binaries in the destination archive)" - even though it doesn't exist for intrepid yet.
[13:35] <Laney> How can I see which packages provide an alternative via update-alternatives?
[13:42] <ScottK> morgs: PPA questions should be directed to #launchpad.
[13:42] <morgs> ScottK: thanks
[14:20] <Riddell> persia, geser, soren, nixternal: what's the status of apachelogger's core-dev application?
[14:20]  * persia checks
[14:31] <persia> Riddell: Waiting for more review and comments at this point, from the archives.
[14:31] <Riddell> huh?  I suspect it's had all it's going to get
[14:32] <persia> I hope not.  It needs more input from MC members to get anywhere : it's essentially stuck in limbo right now.
[14:33] <ScottK> I think all the sponsors have commented.
[14:33] <Riddell> then this process isn't working.  if MC is blocking new members it needs to sort itself out or we'll just have to work around it
[14:35] <persia> I agree the process isn't working.  I agree that sorting it makes sense.  I think that aside from ArchiveReorganisation, it's not best to work around it.  I have opinions about why it doesn't work, but no real understanding.
[14:39]  * sebner missed the MOTU meeting. did anything special happen?
[14:41] <persia> sebner: Nobody appears to have attended, or expressed anything.  There was no agenda.
[14:41] <RainCT> hiya
[14:41] <sebner> persia: kk, thx
[14:41] <sebner> aloha RainCT :)
[14:58] <bddebian> Heya gang
[15:00] <nixternal> persia, geser, soren: concerning apachelogger's core-dev app, I have already commented and voted
[15:01] <persia> nixternal: Indeed.  In the very beginning of september.
[15:01] <nixternal> jeesh, that long ago....what is the hold up?
[15:02] <persia> The process seems broken.
[15:03] <nixternal> slightly
[15:04] <nixternal> I don't like the fact we are hung up on apachelogger when Kubuntu really needs him, especially with me being afk so much and not being able to package
[15:04] <nixternal> or sponsor his work
[15:28] <siretart> okay, the ffmpeg unstripped version actually seem to work. cool
[15:30] <jdong> siretart: encoding junkies everywhere rejoice :)
[15:32] <siretart> jdong: I just have had an tester next to me. it works with the packages from ~motumedia
[15:33] <siretart> jdong: I'm seriously considering to upload them to ubuntu right now
[15:33] <siretart> jdong: input welcome :)
[15:34] <jdong> siretart: you know, that would solve a lot of the grievances out there but what about the encumberance issues?
[15:34] <jdong> it would also resolve the medibuntu-ubuntu off-sync every time we do a ffmpeg update
[15:35] <siretart> jdong: I think it makes the medibuntu ffmpeg package obsolete
[15:36] <jdong> siretart: agreed. which would be a good thing for both teams
[15:36] <jdong> siretart: and right now we're already half-hypocritical shipping the mpeg4-ASP encoder on by default
[15:36] <jdong> and hell decoding of mpeg4 is already "encumbered" so honestly I think we should just ship it all...
[15:36] <jdong> the question is whether it'd go into restricted or main...
[15:38] <jdong> siretart: how well does it coexist with gstreamer and friends?
[15:38] <siretart> jdong: it would go to multiverse
[15:39] <siretart> jdong: as for gstreamer and friends: it conflict/replaces libavcodec51.
[15:39] <jdong> siretart: sounds reasonable
[15:39] <jdong> I think it'd be a good thing to have
[15:39] <jdong> and I don't think any problems with archive since we've already got implementations of ALL of those encoders in other packages in multiverse
[15:40] <siretart> exactly
[15:41] <jdong> yeah I'd say just do it
[15:42] <jdong> but given the mdz conversation in #u-d... I'd like to hear his response
[15:42] <mr_pouit> siretart: so the only stuff remaining for medibuntu would be amr I guess (since libamr* is currently unredistribuable :])
[15:43] <siretart> mr_pouit: yes, and I have even for that I have a solution or at least an idea how to fix that
[15:43] <jdong> dlopen()?
[15:44] <jdong> if you "magically" supply a libamr, ffmpeg-evil will find it :D
[15:44] <morgs> norsetto: sugar install and build logs available - see bug 274820.
[15:44] <siretart> exactly. the altlinux folks have a patch for that
[15:44] <siretart> that way ubuntu's ffmpeg could dlopen() medibuntu's libamr libraries
[15:45] <siretart> mr_pouit: please do have a look at the 'ffmpeg' source package in the ~motumedia PPA
[15:45] <siretart> patches welcome, everything is in PPA under ~motumedia/ffmpeg
[15:46] <siretart> patches welcome, everything is in bzr under ~motumedia/ffmpeg
[15:52] <mr_pouit> ok
[16:02] <norsetto> morgs: thanks. Did you check if there is any issue with upgrading?
[16:03] <morgs> norsetto: no, I didn't check, but we will need some slight changes from the debian packages to handle two packages which are renamed: sugar-base -> python-sugar, and sugar-datastore -> python-olpc-datastore
[16:04] <norsetto> morgs: right
[16:04] <norsetto> morgs: I have no problem to ack this, if you could make sure that upgrades are fine that would be sweet
[16:05] <jcastro> YokoZar: you dropping by for UDS/Fosscamp? I see you're basically local
[16:05] <morgs> norsetto: I have a personal interest in making them work, being an upstream dev, so yeah :)
[16:05] <norsetto> morgs: I bet ;-)
[16:12] <james_w> sebner: have you seen bug 269301 ?
[17:06] <FFEMTcJ> how is it possible to get a package in the repo's updated to the current version?
[17:16] <sistpoty> hi folks
[17:27] <siretart> hey sistpoty
[17:27] <sistpoty> hi siretart
[17:29] <siretart> sistpoty: do you have plans for this weekend? http://lusc.de/ww :)
[17:32] <sistpoty> siretart: hm... I do have some plans for the weekend already :/
[17:35] <slytherin> superm1: Have you checked latest comment on the bluez 4.x bug? LOL.
[17:38] <superm1> slytherin, lets see.
[17:38] <iulian> Hi
[17:40] <superm1> slytherin, well I would hypothesize that those segfaults are probably null pointer checks, but we'll have to wait for a backtrace
[17:40] <superm1> the important part is whether these are "regressions" :)
[17:41] <superm1> slytherin, would you be able to craft a patch to make tooltips on the icons possibly?
[17:41] <superm1> i'm working on a patch to properly set input devices to trusted mode
[17:46] <slytherin> superm1: 1. I will be able to provide tooltips. I will have to check what is the current GTK+ requirement for bluez-gnome. If it >= 2.12 then our life is easier.
[17:47] <superm1> slytherin, well we can easily bump the GTK requirement up if necessary
[17:47] <superm1> slytherin, it's very highly unlikely we'll backport this since it only works with bluez 4.x
[17:48] <slytherin> superm1: Ideally shouldn't we ask upstream to fix the tooltip problem?
[17:50] <superm1> slytherin, well we can fix it and submit the patch upstream
[17:50] <superm1> slytherin, they've got very few developers, so it would be fixed a lot quicker that way
[17:51] <slytherin> superm1: Ok. Will do tomorrow.
[17:51] <superm1> slytherin, okay great
[18:11] <slytherin> superm1: by the way, by latest comment I meant the one by Christoph Langner
[18:18] <fabrice_sp_> Hi. If upstream doesn't provide an icon for the app, can I package it without menu entry? Or I should use a generic icon?
[18:18] <fabrice_sp_> (for bug #272210)
[18:28] <csilk> fabrice_sp_,
[18:28] <csilk> are you abloe to test megatunix?
[18:29] <csilk> *able
[18:29] <csilk> I was origannly going to package megatunix per a user request but thought i best not when i realised i had no way to really test it
[18:29] <csilk> *originally
[18:38] <YokoZar> jcastro: Yeah, not much need for sponsorship this year.  I can probably crash at a friend's house.
[18:39] <YokoZar> jcastro: which is lucky for you, as Wine will be in Main for Jaunty.
[18:40] <es> I'm new to the ubuntu way of building package, pbuilder fails because the new upstream package has a new directory previusly not present. I specified it to debian/dirs without success, also there path looks weird they go in var/lib/something instead of usr/lib/something of the previously installed package.
[18:41] <es> any advice?'
[18:42] <jcastro> YokoZar: ok, I was thinking we should invite dan kegel since he's @ google also
[18:43] <james_w> es: if you give the failure message then it may be easier to see what is going on
[18:44] <es> james_w: sure thanks:) cp icons/*.png /usr/lib/sympa/static_content/iconscp: target `/usr/lib/sympa/static_content/icons' is not a directorymake[2]: *** [installicons] Error 1
[18:45] <es> var/lib/sympa/static_content/iconsusr/lib/sympa/static_content/icons
[18:45] <es> these are specified in dirs
[18:46] <james_w> es: is the cp command in debian/rules?
[18:47] <es> yes it's in configure options: --with-iconsdir=/usr/share/sympa/icons
[18:47] <james_w> es: the "cp icons/*.png", is that in debian/rules?
[18:47] <es> no
[18:48] <james_w> es: is it in a Makefile?
[18:49] <es> no I made a grep -R and I can't find it :/
[18:49] <james_w> es: can you put the build log in a pastebin please?
[18:50] <es> james_w: sure, thanks for your help but err where are the logs usually?
[18:51] <james_w> es: you will have to build again with --logfile, or grab them from the scrollback in your terminal
[18:56] <es> james_w: weird the logfile is not created I pasted from the terminal http://pastebin.myrror.net/1938
[18:56] <es> james_w: thanks again for your help :)
[18:57] <james_w> es: so it appears to be the wwsympa directory that has the problematic command
[18:58] <james_w> es: can you pastebin the Makefile from that directory please?
[18:59] <es> james_w: http://pastebin.myrror.net/1939
[18:59] <es> line 102
[19:01] <james_w> es: ah, should have spotted that
[19:02] <james_w> *I* should have spotted that
[19:02] <james_w> es: it's not using $DESTDIR
[19:02] <es> ahh!
[19:02] <james_w> es: so it's trying to install in to the real /usr, rather than ./debian/.../usr/
[19:04] <es> yep! so it should be $(DESTDIR)/static_content/icons ?
[19:09] <james_w> es: no, it should be $(DESTDIR)$(DIR)/static_content/icons I think
[19:12]  * sistpoty is off again... cya
[19:13] <es> james_w: yeah, we passed that error! now: cp sympa_soap_server-wrapper.fcgi /tmp/buildd/sympa-5.4.3/debian/sympa/usr/lib/cgi-bin/sympa/cp: cannot stat `sympa_soap_server-wrapper.fcgi': No such file or directory
[19:13] <es> guess it's the same problem
[19:15] <es> wwsympa-wrapper.fcgi: wwsympa-wrapper.fcgi.c Makefile ../Makefile        $(CC) $(CFLAGS) -DWWSYMPA=\"$(WWSYMPA)\" -o wwsympa-wrapper.fcgi wwsympa-wrapper.fcgi.c
[19:15] <james_w> I think that's a different problem
[19:15] <es> err no it's another line
[19:16] <james_w> it can't find sympa_soap_server-wrapper.fcgi, does it ever build it?
[19:16] <es> james_w:  where should I check out?
[19:21] <es> james_w: actually I don't see it in the logs
[19:22] <james_w> is it mentioned anywhere else in the Makefiles?
[19:24] <es> james_w: nope
[19:25] <es> cd sympa-5.4.3/wwsympa && grep sympa_soap_server-wrapper.fcgi Makefile  -> none
[19:27] <fabrice_sp_> csilk: I assume that the user requesting the packaging will be able to test it (I'll put it in my ppa meanwhile). Anyway, I'm able to do some things.
[19:28] <es> james_w: it's in soap/Makefile
[19:31] <csilk> fabrice_sp_,  that's the only thing that stopped me form packaging it really
[19:32] <csilk> *from
[19:32] <fabrice_sp_> csilk: apart from a compilation error because of gcc4.3 and the missing icons, it's an easy package.
[19:32] <fabrice_sp_> If you wan't, you can still package it
[19:32] <fabrice_sp_> s/wan't/want/
[19:34] <lfaraone> Hey, is there any way if I have to make a lot of debian sync requests (we already have FFEs for them) to do it in _one_ bug?
[19:35] <es> james_w: well, thanks for your help, tomorrow I'll look into it better. I'm hungry and I my mind isn't working anymore as you can see :)
[19:35] <csilk> fabrice_sp,  I wouldn't mind packaging it to be honest, I've been trying to get involved with ubuntu for a while now but it's hard managing a heavy load at university etc etc
[19:36] <csilk> but if you wouldn't mind assiging the bug/request to me I'd love to do it
[19:36] <csilk> *assigning
[19:37] <geser> lfaraone: can't you just add the missing info for the sync to the FFE bugs? that way all infomation is in one place
[19:37] <lfaraone> geser: It's one FFE bug.
[19:37] <fabrice_sp> csilk: all your's. If you have problem, you can ping me here (if I am online)
[19:38] <csilk> Thanks fabrice_sp
[19:38] <geser> lfaraone: have you the bug number handy?
[19:39] <lfaraone> geser: No, but it's against the "sugar" pacakge
[19:43] <geser> I've found it (bug 274820)
[19:44] <geser> lfaraone: how many package are affected?
[19:49] <slytherin> doko: Do you plan to fix bug #254368 in intrepid? or is it deferred?
[19:52] <slytherin> anyone willing to test DVD playback fixes in gstreamer backported form upstream CVS? I am waiting for some feedback before I can submit the debdiff.
[20:04] <bddebian> siretart: You around by any chance?
[20:19] <emgent> heya
[20:20] <bddebian> Hello emgent
[20:26] <iulian> Hey bddebian and congrats!
[20:27] <bddebian> Hi iulian, thanks
[20:30] <bddebian> Gads, how the heck do you folks use LP anymore?  I've obviously been waaay too out of touch lately
[20:37] <lfaraone> geser: https://wiki.ubuntu.com/SugarTeam/Packages has a list
[20:52] <siretart> bddebian: yes, a bit afk (lug event), but sort-of
[20:55] <bddebian> siretart: Any idea what to do about xine-lib in Debian for Lenny?
[21:07] <james_w> anybody have an opinion on bug 275502?
[21:09]  * cody-somerville takes a look.
[21:11] <geser> james_w: do you know how common are hotmail/yahoo accounts inside and outside the USA?
[21:12] <james_w> pretty common I believe
[21:13] <nxvl> james_w: if you are trying to sponsor it, please don't, see my comment
[21:13] <nxvl> james_w: i don't want to have all of those packages i don't need in my system if i'm only using one of them
[21:14] <james_w> nxvl: thanks
[21:14] <nxvl> james_w: also i don't have that much experience with that package/tool but from the comments/report i get that you need at least one of them for the tool to work, but all of them is crazy
[21:15] <nxvl> thatfor it will be | instead of , if you want to make the change anyway
[21:15] <nxvl> i will suggest to talk to the DM better
[21:15] <geser> I use mail-notification but with mutt and I don't need either of those packages
[21:16] <ScottK> They are common, but I don't think they'd rise to needed except in unsual situations (which is the 'recommends' definition).
[21:16] <james_w> I get the impression the tool isn't very good at hinting that you could install other packages to get the functionality
[21:17] <james_w> Suggests is how the package should do that, but it helps if the program does as well
[21:18] <geser> I could understand to add m-n-evolution to recommends (as evo is the default mua), but I don't know about getlive and fetchyahoo (it would be for me easier to accepts something for googlemail)
[21:18] <james_w> I think gmail is still far smaller in overall usage
[21:18] <nxvl> geser: that's why using "m-n-evolution | getlive | fetchyahoo" will be better, by default it will grab m-n-evolution
[21:19] <nxvl> james_w: don;t bet
[21:19] <james_w> nxvl: but that doesn't bring any benefit over Suggests, so it's not worth it in my opinion
[21:20] <torkel> is it working with the current version of evo?
[21:20] <nxvl> james_w: actually there is some apt option to install suggest by default
[21:20] <nxvl> james_w: but yes, i agree with you on that
[21:21] <cody-somerville> Is there atleast one fetcher module thingie installed by default?
[21:21] <nxvl> james_w: i'm saying if it will be raised to Recommends, that is the way it should be rised
[21:40] <siretart> bddebian: ?
[21:40] <siretart> too bad, he already left
[21:48] <cody-somerville> ScottK, ping
[21:49] <cody-somerville> or anyone else from motu-release
[21:50] <norsetto> cody-somerville: yes?
[21:50] <cody-somerville> norsetto, bug #262156
[21:50] <norsetto> cody-somerville: yes?
[21:51] <cody-somerville> motu-release I imagine should be responsible for ensuring that gets fixed or envyng gets removed from the archive.
[21:52] <norsetto> cody-somerville: indeed, see bug 277126
[21:55] <cody-somerville> ok, thanks
[21:55] <norsetto> cody-somerville: np
[22:03] <sebner> norsetto: you making ad for your ppa? nice :)
[22:04] <norsetto> sebner: yes, I'd like to provide 0.8.0 to intrepid users
[22:04] <sebner> norsetto: nice :)
[22:05] <norsetto> sebner: next version is also coming out pretty nice
[22:05] <sebner> norsetto: ^^, in time for jaunty?
[22:05] <norsetto> sebner: absolutely
[22:06] <sebner> norsetto: great to hear :)
[22:45] <james_w> lfaraone: hi, do you have a blanket FFe for the sugar sync requests?
[22:46] <ScottK> james_w: They do.
[22:47] <james_w> ScottK: thanks
[23:13] <lfaraone> james_w: Yes.
[23:45] <csilk> why does the wiki (packaging) not discuss what to do with all the extra files in /debian such as init.d.ex and all the manpage related files?
[23:45] <csilk> etc
[23:47] <nhandler_> csilk: They are example files. If you need them, you rename them (remove the .ex suffix). If you don't need them, you just delete them.
[23:48] <csilk> nhandler_,  I'm not 100% sure what they are to be honest
[23:50] <nhandler_> csilk: For most basic packages, you can safely remove the files. What are you packaging? Or what type of application is it?
[23:52] <csilk> an app called megatunix, it's a software utility for measuring variious things within a combustion engine
[23:52] <csilk> such as air to fuel ratio
[23:53] <csilk> nhandler_, ^
[23:54] <nhandler_> csilk: You most likely won't need the example init script for this application. Give me a second to check what other example files there are
[23:54] <csilk> Thank you
[23:58] <nhandler_> csilk: The only example files that you might want are the ones concerning the man page, the one for the watch file, and possibely the ones for the menu file and maintainer scripts. None of these are critical, and there are plenty of guides and wiki pages that outline how to create these files youself.