[01:53] <quidnunc> Is emacs23 being packaged for Karmic and Jaunty?
[01:57] <RAOF> It'd only get into Janty via backports; I know that there's work in Debian to package it, so we'll probably just pull that down.
[01:57] <micahg> It's in debian unstable
[01:57] <quidnunc> RAOF: So Karmic is waiting on Debian?
[01:58] <quidnunc> micahg: Is there any work going on to put it into Karmic?
[02:02] <micahg> idk, you can check for an open request, https://bugs.launchpad.net/ubuntu/+source/emacs
[02:09] <quidnunc> micahg: I've looked, didn't see one and was surprised, considering its popularity. I assumed I missed something
[02:09] <micahg> nope
[02:09] <micahg> if it's not there, you can file a sync request
[02:10] <quidnunc> micahg: That link is bad by the way
[02:10] <micahg> sorry
[02:11] <quidnunc> #408085:
[02:11] <quidnunc> This report is public
[02:11] <quidnunc>  
[02:12] <quidnunc> Sorry. ^ Someone filed the sync request 5 hours ago.
[02:12] <micahg> great
[02:12] <micahg> you can subscribe and be notified when it's complete
[02:13]  * micahg didn't know emacs source versions are numbered :) 
[02:13]  * micahg uses vi :)
[02:14]  * micahg will use the bot next time :)
[02:19] <quidnunc> Thanks micahg
[02:19] <micahg> np
[02:43] <kklimonda> Could someone sponsor bug 317366 - it's a small patch (i'll send it to debian when it's uploaded). Also is this bug worth and sru? fwiw it may be pretty irritating for people who use rxvt-unicode often
[03:26] <coolbhavi> hello m trying to update xoscope to 2.0 but its ftbfs
[03:26] <coolbhavi> http://launchpadlibrarian.net/29805253/buildlog_ubuntu-karmic-i386.xoscope_2.0-0ubuntu4_FAILEDTOBUILD.txt.gz
[03:27] <coolbhavi> http://pastebin.com/m7106b864 <= Rules file
[03:28] <coolbhavi> orig.tar.gz available here : https://edge.launchpad.net/~bhavi/+archive/xoscope/+files/xoscope_2.0.orig.tar.gz
[03:29] <coolbhavi> please help
[06:58] <billybigrigger> anyone alive?
[06:58] <billybigrigger> anyone here familiar with phoronix test suite?
[06:59] <micahg> yes and no :)
[06:59] <billybigrigger> well i just installed it from repos
[06:59] <billybigrigger> and the gui doesn't work without PHP GTK
[06:59] <billybigrigger> so i have to compile and build it myself
[07:00] <billybigrigger> billybigrigger@cabo:~/php-gtk-2.0.1$ phoronix-test-suite gui
[07:00] <billybigrigger> The PHP GTK module must be loaded for the GUI.
[07:00] <billybigrigger> This module can be found @ http://gtk.php.net/
[07:00] <micahg> yes, I'm familiar with the module
[07:00] <micahg> I'm not familiar wiht the test suite though
[07:00] <billybigrigger> oh
[07:01]  * micahg is alive though
[07:01] <\sh> moins
[07:01] <billybigrigger> well maybe for karmic if it's not too late we can get a php gtk package made up and installed with the test suite?
[07:01] <billybigrigger> since it's the only decent gui benchmarking tool i know of for linux
[07:02] <micahg> bug 260235
[07:02] <billybigrigger> i have a howto written up on how to get the gui working for phoronix 1.8
[07:03] <micahg> debian bug 473396
[07:03] <billybigrigger> http://ubuntuforums.org/showthread.php?t=1108731
[07:03] <billybigrigger> ahhhh
[07:03] <billybigrigger> :P
[07:04] <micahg> sorry
[07:05] <micahg> might want to poke upstream, it was last touched apr 2008
[07:06] <micahg> This came out of one of the posts: http://php-gtk.eu/en/ubuntu-php-gtk-repository
[07:07] <micahg> but no guarantees
[08:45] <stochastic> I'm packaging a program and a few of the files included in the source tarball have this copyright notice: http://pastebin.ubuntu.com/245629/ is it still eligible for inclusion in Universe?  How do I summarize this for the debian/copyright file (or do I paste the whole notice there)?
[08:53] <slytherin> stochastic: 'without fee' looks like non-free me. I am not sure if it will be allowed in archives.
[08:54]  * stochastic needs to do more research on this, because the feature that these files implement are used by many other programs in the archives...
[09:00] <directhex> slytherin is correct
[09:00] <directhex> "without fee" is non-free. which sounds ass-backwards really
[09:00] <stochastic> I'll talk to upstream about it
[09:04] <slytherin> Does anyone know if we are taking advantage of the improved dpkg-shlibdeps for programs linking against gtk libraries?
[09:15] <directhex> slytherin, improved how?
[09:16] <slytherin> directhex: I read something related to symbols file which is used by dpkg-shlibdeps to check which symbols are actually being used by the program and set the dependencies (shlib:Depends) accordingly.
[09:17] <directhex> slytherin, as long as ld's using --as-needed
[09:17] <directhex> (it amazes me that --as-needed isn't the default)
[09:17] <slytherin> And how do I know if ld is using as-needed or not?
[10:36] <slytherin> directhex: what is the correct way to specify ld flag --as-needed?
[10:43] <directhex> dunno. probably in LDFLAGS somehow. i do mono packaging, remember? our linker doesn't include useless linkage
[11:21] <pochu> slytherin: LDFLAGS += -Wl,--as-needed
[11:22] <slytherin> pochu: What is -Wl in this case?
[11:23] <pochu> slytherin: it tells the compiler to pass that flag to the linker
[11:23] <slytherin> pochu: Ok. Let me try.
[11:23] <renderguy> Hi there.
[11:23] <pochu>        -Wl,option
[11:23] <pochu>            Pass option as an option to the linker.  If option contains commas, it is split into multiple options at the commas.
[11:23] <pochu> from gcc(1)
[11:24] <slytherin> renderguy: hi
[11:26] <renderguy> I'll apologies in advance, as I'm not sure where best to request help, but I was hoping to gauge in interest of any official package maintainers to help bring our package up-to-date? - http://packages.ubuntu.com/jaunty/aqsis
[11:29] <renderguy> No-one on our team is qualified to handle this task so we're hoping to be able to work with packagers to help keep things current.
[11:29] <directhex> renderguy, try poking ender in debianland - he's the original maintainer
[11:29] <directhex> and a fixed package in debian helps every dist, not just ubuntu
[11:30] <renderguy> directhex: I've tried the previous maintainers, they seem to have vanished.  :-(
[11:31] <renderguy> We do have someone looking into this at the moment, but he is also new and not an official package maintainer... what we lack is the 'Experience'.
[11:33] <renderguy> Users are also rushing us as our project is also used by other apps, and we're releasing a new version shortly (few weeks).
[11:34] <renderguy> If anyone would be interested in providing a little time I'm sure we can get things rolling again.
[11:38] <slytherin> directhex: pochu: --as-needed worked, but it doesn't solve my original problem. The package has dependency libgtk2.0-0 (>= 2.17.5), whereas only 2.12 is needed.
[11:39] <directhex> oh. oh, interesting
[11:40] <renderguy> I have experience of our current RPM (Fedora) package, though not the repo process, so I'm sure with an experienced Debian/Ubuntu packager on-board we could get something running pretty quickly.
  ;-)
[11:43] <pochu> slytherin: that's likely because of the shlibs
[11:43] <pochu> see /var/lib/dpkg/info/libgtk2.0-0.shlibs
[11:45] <slytherin> pochu: Right, but from what I had heard the dpkg-shlibdeps is now smart enough to check which symbols are actually used and adjust the dependencies accordingly.
[11:48] <renderguy> Are there logs for this channel (online)?
[11:48] <slytherin> renderguy: irclogs.ubuntu.com
[11:48] <StevenK> renderguy: Yes, irclogs.ubuntu.com
[11:50] <slytherin> pochu: here is the reason, the gtk source package in karmic does not contain debian/libgtk2.0-0.symbols file. Where as the version in Debian does. So the same package built in Debian has only necessary dependencies (gtk2 >= 2.12 in this case).
[11:50] <renderguy> slytherin & StevenK: Thanks, I can monitor that should anyone respond when I'm offline.
[11:50] <slytherin> s/package/application.
[14:17] <slayton> I've seen a few examples where people use svn<revision_number> in a package title... what would be the appropriate way of doing this using a sources that are kept in a git repository, as the revision hash doesn't increment with git?
[14:17] <slayton> - package title + package version number
[14:21] <jpds> slayton: ~gitYYYYMMDDHHMM.
[14:21] <slayton> jpds, great thanks!
[14:22] <geser> and perhaps mention the git hash in the changelog
[14:24] <fabrice_sp> Hi. I've been requested to add a build log to a sync request. Is it a new mandatory file to attach to a sync request?
[14:24] <fabrice_sp> it's for bug #406505
[14:25] <StevenK> I didn't think so ...
[14:26] <fabrice_sp> So did I...
[14:26] <fabrice_sp> Anyway: as I always build the package before requesting a sync, the log should be somewhere
[14:26] <geser> some sponsors like to see it to have a proof that you test-build it
[14:26] <slytherin> I am curious. The guy who asked it could have checked himself if the package build fine.
[14:27] <fabrice_sp> ok. I'll attach it from now on
[14:27] <fabrice_sp> I can understand because this is a looooonnnnngggg building package
[14:27] <fabrice_sp> (almost 2 hours in my case)
[14:28] <fabrice_sp> (and most packages builds in less than 20 minutes)
[14:28] <\sh> slytherin: I thought so too...sponsor needs to check for him/herself when she/he is not sure, but that's only me
[14:29] <fabrice_sp> I was just checking if it was a new approach, not blaming anybody :-)
[14:29] <slytherin> Right. I always check if the package builds fine before confirming a sync. Call me paranoid but I usually do not trust someone else's build log.
[14:30] <geser> I usually check myself too, but for long-building packages I sometimes take the word from the contributor that it builds (if it's a known contributor)
[14:52] <bddebian> Heya gang
[15:03] <slytherin> TheMuso: Is there any known solution to the current powerpc buildd problem?
[15:05] <renderguy> Gotta shoot now, I'll monitor the IRC logs to see if anyone's interested in helping... thanks for listening.
[15:58] <loic-m> What's the way to specify that a package has to be built with a version of gcc different than the latest one in karmic (i.e. << 4.4)?
[16:00] <StevenK> loic-m: Add gcc-X.Y to the Build-Depends, and change CC in debian/rules
[16:01] <StevenK> loic-m: I think it would be preferable to just fix it to build with 4.4
[16:01] <loic-m> StevenK: thanks. I added gcc (< 4.4) but didn't think about debian/rules
[16:01] <StevenK> loic-m: gcc (< 4.4) won't work
[16:01] <loic-m> StevenK: I don't know C, so I can't fix it unfortunately :(
[16:02] <loic-m> Steven: why?
[16:02] <pochu> loic-m: you need gcc-4.3 or gcc-X.Y
[16:02] <maxb> Because for arcane compatibility reasons, < means <=
[16:02] <pochu> gcc (<< 4.4) won't work either
[16:03] <pochu> (in build-depends)
[16:03] <loic-m> pochu: thanks a lot.
[16:04] <dkg0> LP345054 is the request for syncing monkeysphere from debian unstable.
[16:04] <dkg0> in particular, it requests version 0.26-1
[16:04] <pochu> bug 345054
[16:04] <dkg0> but it was closed as fixed by an upload of 0.25-1
[16:05] <dkg0> 0.25-1 is going to have the same FTBFS under pbuilder rebuilds
[16:05] <dkg0> due to the test suite running under /tmp
[16:05] <dkg0> 0.26 contains a fix for that
[16:07] <dkg0> should i change the status off of "Fix Released" since it is not really resolved?
[16:07] <dkg0> if so, what should i change it to?  should i assign it to anyone?
[16:08] <slytherin> dkg0: Why not simply file a new bug.
[16:08] <dkg0> because this bug was not actually resolved?
[16:08] <dkg0> would it be better as a new bug?
[16:10] <loic-m> dkg0: I don't have a clue, but personnaly when an upgrade/sync request takes a while, and there's a new version, I just update the bug description, especially if a prospective uploader has already started looking into the bug
[16:10] <dkg0> loic-m: my concern is that it was marked "fixed" two hours ago by a sync of an old version
[16:11] <dkg0> i *did* update the bug description, but that was a few days ago
[16:11] <slytherin> dkg0: No. For the sake of cleanliness on launchpad. You already modified a sync request for old version. That is why I believe the archive admin got confused.
[16:11] <loic-m> dkg0: news bugs then maybe. If you use requestsync, it's simple
[16:13] <dkg0> i'll use requestsync going forward for sure, i'm just trying to figure out the right way to handle this particular case, where the ticket is effectively tracking this FTBFS issue about the test suite.
[16:19] <loic-m> dkg0: won't 0.26 process be far more straightforward though, with no building problems? Or is there a need to keep some information from the bug report you linked to?
[16:20] <dkg0> well, i hope there'll be no more build problems, but i've been wrong before ;)
[16:21] <kamalnandan> Hi All
[16:26] <loic-m> dkg0: if there's no need to read the previous bug report, won't a new sync request be easier, specifying it has to be pulled from unstable? Unless you want to ping slangasek if really necessary
[16:26] <dkg0> yah, i see what yer saying.
[16:27] <dkg0> i think i dug in a bit too much on the old bug report, and should have just let it go ;)
[17:03] <kamaln> Hi All
[17:26] <loic-m> Is there an example of a package that needs to be build with a different version of gcc than the default one so i can have a look how it's done in debian/rules?
[17:34] <Lin_> Hi there all!! I wish to know: 1. if kernel-ppa images (2.6.31 to be more exact) contains backports-modules. 2. and, if dont where can I find the patch to apply them to kernel-ppa 2.6.31 sources? BTW, i have seem that some drivers (v4l to be exact) are not set to be compiled, is this working as intended? cause isnt a big cost add more capture cards (mainly usb ones).
[18:55] <Eaxexe> Hi there, is there a tool to package to .deb and .rpm at the same time?
[18:55] <UbuntuNISMO>   anybody can help fixing /etc/network/interfaces ?
[18:55] <slytherin> UbuntuNISMO: This is not a general support channel. Try #ubuntu
[18:55] <UbuntuNISMO> thanks
[18:56] <UbuntuNISMO> im not linux beginner but what is MOTU about?
[18:56] <slytherin> Eaxexe: The files needed by both are different. What do you mean by build at same time?
[18:56] <slytherin> UbuntuNISMO: Packaging software.
[18:57] <Eaxexe> slytherin: Well I've been looking into creating (or just TRYING to) develop a Unified Package System, but as I've been searching the net it seems an impossible task. So my idea is to develop a tool where if you've developed a program you can pack to .deb and .rpm at the same time :)
[18:58] <slytherin> Eaxexe: About unified packaging system, I believe autopackage tries to solve that problem.
[18:58] <Eaxexe> slytherin: great thanks :) Looking into it
[18:59] <Eaxexe> Thanks I'll look into it :)
[18:59] <slytherin> What is exactly the meaning of error 'failed to upload'?
[19:04] <UbuntuNISMO> ok nice , I did some .deb packages in the past, I know theres a lot to know with automate freedesktop to read about, good channel!, I keep this in mind
[19:25] <c_korn> hello, how can I resolve such a dependency problem?
[19:25] <c_korn> The following packages have unmet dependencies:
[19:25] <c_korn>   libcdparanoia0-dev: Depends: libcdparanoia0 (= 3.10+debian~pre0-6) but 3.10.2+debian-5~ppa2~hardy is to be installed
[19:26] <slytherin> c_korn: you are mixing repositories it seems.
[19:26] <pochu> or -dev is arch:all and the library isn't built yet
[19:27] <c_korn> hm, yes. I was trying to build gst-plugins-base0.10-0.10.23.4 on hardy.
[19:27] <c_korn> it build-depends on libcdparanoia0-dev
[19:27] <c_korn> which is virtual in karmic. and a normal package in hardy
[19:28] <c_korn> http://packages.ubuntu.com/search?keywords=libcdparanoia0-dev&searchon=names&suite=all&section=all
[19:28] <c_korn> should I change the dependency in gst-plugins-base to libcdparanoia-dev ?
[19:28] <slytherin> c_korn: your problem is not the name of dependency
[19:29] <slytherin> c_korn: it is version mismatch between -dev and the lib package
[19:29] <c_korn> hm, all packages are already in the ppa repository. I don't know why it is tried to install the old version.
[19:37] <fabrice_sp> c_korn, what is the url of the ppa?
[19:37] <c_korn> fabrice_sp:  https://launchpad.net/~c-korn/+archive/vlc
[19:38] <c_korn> this is the build log http://launchpadlibrarian.net/29832263/buildlog_ubuntu-hardy-amd64.gst-plugins-base0.10_0.10.23.4-1~ppa1~hardy_FAILEDTOBUILD.txt.gz
[19:40] <fabrice_sp> libparanoia0-dev is not the same as libparanoia-dev
[19:40] <fabrice_sp> :-)
[19:40] <fabrice_sp> your ppa contains libcdparanoia-dev
[19:41] <fabrice_sp> change the build dependency from libcdparanoia0-dev to libcdparanoia-dev
[19:41] <fabrice_sp> c_korn, ^
[19:42] <c_korn> fabrice_sp: yes, thanks. as I suggested.
[19:54] <slytherin> james_w: slangasek: Is either of you planning to look at new source packages in queue today? I am waiting for processing of jakarta-jmeter. :-)
[20:15] <fabrice_sp> andv, about Bug #400528
[20:16] <fabrice_sp> do you want me to update the changelog to make clear why the --without-arts is mandatory?
[20:17] <andv> fabrice_sp, yes, I saw some changes you didnt apply back
[20:17] <andv> fabrice_sp, like debian/rules: compile again with kde support
[20:17] <andv> +
[20:17] <andv> for example
[20:17] <andv> I want to know why you dropped them and why you added that configure rule
[20:18] <fabrice_sp> really? I'll check again, but I'm sure they have been applied in Debian
[20:18] <andv> fabrice_sp, could be, but you didnt say why those changes can be dropped
[20:18] <andv> in bug description
[20:19] <fabrice_sp> andv, ok. I'll make that clear
[20:19] <andv> fabrice_sp, something more
[20:19] <fabrice_sp> yes?
[20:19] <fabrice_sp> not from my part
[20:19] <andv> try to document changes you make more clearly
[20:20] <norsetto> any kubuntero wishing to check if http://revu.ubuntuwire.com/details.py?upid=6499 conforms to their standards?
[20:20] <andv> fabrice_sp, by adding an entry like the one you added will confuse next mergers
[20:20] <fabrice_sp> andv, which one? The no Remaining changes?
[20:21] <andv> fabrice_sp, nope
[20:21] <andv> fabrice_sp, the one related to --without-arts
[20:21] <andv> fabrice_sp, you said you added it but you don't document why
[20:22] <andv> fix all of them and set the bug on confirmed again
[20:22] <andv> ;)
[20:22] <fabrice_sp> ok. Thanks ;-
[20:22] <fabrice_sp> )
[20:22] <andv> np