[00:03]  * Laney battles lplib
[00:11] <NCommander> directhex, yay, welcome to the MOTU club!
[00:12] <directhex> NCommander, do i get to ride around on some kind of sabretoothed tiger and chop up bad guys?
[00:12] <NCommander> directhex, nope
[00:12] <directhex> aw man, wrong MOTU :(
[00:12] <Laney> you get to learn the secret handshake and have plumbers do work for you in half the time
[00:13] <Laney> see: the stonecutters
[00:13] <directhex> i can't join a secret society which is against the metric system
[00:14] <Laney> oh, you can now get a free LWN subscription
[00:15] <directhex> how about a hat? something dapper?
[00:15] <directhex> at a jaunty angle
[00:16] <directhex> man, ubuntu releases could totally be about hats instead of animals
[00:16] <Laney> redhat have the hat thing going on already :(
[00:17] <binarymutant> ^ too much like fedora
[01:09] <persia> james_w, The reason for sponsor membership is historical and related to bugmail.  Feel free to raise for discussion.
[01:09] <persia> directhex, I'lll add you to the team.  Welcome!
[01:09] <directhex> persia, hello
[01:10] <james_w> persia: I'll bring it up sometime, thanks
[01:10] <directhex> persia, it was suggested by Laney that karma demands i do some sponsoring given how much sponsoring i've expected in the past
[01:10] <james_w> heh
[01:11]  * james_w notes that the sponsorship queue is quickly ballooning
[01:11] <persia> Ooh.  Someone else already added you.  Nifty.
[01:11] <directhex> i think it was TheMuso
[01:12] <persia> Yeah.  I just received the membership addition mail between saying I'd add you, and the error.  No idea why it was delayed.
[01:14] <directhex> clearly you ran out of internet, so it was held up
[01:39] <binarymutant> If anyone has the time to review my package for lxsplit, I would greatly be appreciate it. It can be found here http://revu.ubuntuwire.com/p/lxsplit thank you for the time  :)
[02:17] <binarymutant> did I miss revu day :(
[03:29] <brywilharris> So who wants to REVU a package?
[03:31] <brywilharris> So who wants to REVU a package?
[03:34] <brywilharris> Anybody want to review a new package?
[03:34] <hyperair> just post the link
[03:34] <hyperair> whoever's dropping by will look at it
[03:35] <brywilharris> Great, thanks
[03:35] <brywilharris> I was beginning to think my client was borked.
[03:35] <hyperair> heh
[03:35]  * hyperair still doesn't see a link
[03:36] <brywilharris> Gimme a minute
[03:36] <_stochastic_> http://revu.ubuntuwire.com/p/a2jmidid
[03:36] <brywilharris> http://revu.ubuntuwire.com/p/veusz
[03:37] <hyperair> now then.. let's apt-get source both of them..
[03:38]  * hyperair will look at a2jmidid first (it's simpler)
[03:38] <brywilharris> OK
[03:38]  * _stochastic_ is happy!
[03:39] <hyperair> disclaimer: i'm not a MOTU, i'm just helping out because i'm bored.
[03:39] <hyperair> and i've got one hell of a block trying to figure out how to write my nautilus-share patch
[03:39] <brywilharris> Thanks anyway
[03:39] <hyperair> np
[03:39] <hyperair> hmm waf eh..
[03:39] <brywilharris> what's the problem you're working on?
[03:39] <hyperair> brywilharris: segfault.
[03:40] <hyperair> bug #258570
[03:42] <hyperair> _stochastic_: alright, first step.. bump up your Standards-Version
[03:42] <hyperair> W: a2jmidid source: out-of-date-standards-version 3.8.0 (current is 3.8.1)
[03:42] <_stochastic_> when did that happen?
[03:43] <_stochastic_> 3.8.0 was the standards version when I uploaded it
[03:43] <hyperair> debian sid.
[03:43] <hyperair> i mean 3.8.1 is the new Standards-Version in debian sid, and karmic.
[03:43] <_stochastic_> okay
[03:44] <brywilharris> hell 3.7.3 was the standards version when I uploaded...
[03:45] <hyperair> heheh
[03:45] <hyperair> that's not even jaunty. that's intrepid i believe.
[03:46] <brywilharris> It was
[03:46] <brywilharris> at the time
[03:47]  * hyperair facepalms.
[03:47] <hyperair> waf.
[03:47] <hyperair> good god
[03:47] <hyperair> what's with the huge amount of obfuscated code there?
[03:48] <hyperair> or is that base64'd stuff?
[03:48] <brywilharris> in a2jmidid?
[03:48] <hyperair> yes.
[03:49] <hyperair> i've personally never used waf before so i can't comment on whether those strange looking symbols are suupposed to be there or not
[03:49] <brywilharris> wtf is waf?
[03:50] <lifeless> its a build tool
[03:50] <hyperair> another ridiculous python-based build system
[03:50] <lifeless> similar in many ways to scons
[03:50] <hyperair> indeed
[03:50] <brywilharris> Ah
[03:50] <hyperair> it was inspired by scons, which in my opinion, is THE most ridiculous build system i've seen.
[03:51] <lifeless> the base64 code is equivalent to configure - it allows a waf project to be fully selfcontained
[03:51]  * hyperair needs to take note not to make statements like this after becoming UCD.
[03:51] <brywilharris> so where are you seeing base 64?
[03:51] <lifeless> hyperair: scons has some issues, its true.
[03:51] <hyperair> brywilharris: look at the bottom of the waf file
[03:51] <hyperair> lifeless: what exactly is in this base64'd code?
[03:52] <lifeless> wafs library
[03:52] <hyperair> _stochastic_: ping.
[03:52] <lifeless> compressed
[03:53] <hyperair> lifeless: good god. how ridiculous.
[03:53] <lifeless> which is morally equivalent to configure
[03:53] <lifeless> which is the autoconf library compiled for a specific project
[03:53] <lifeless> its no better or worse
[03:53] <hyperair> i don't remember seeing base64 code in autofoo
[03:53] <lifeless> the base64ness is irrelevant
[03:53] <hyperair> it is.
[03:53] <lifeless> configure isn't the preferred form of modification
[03:54] <hyperair> that's true.
[03:54] <hyperair> but it looks goddamn obfuscated.
[03:54] <lifeless> configure is the output of a compiler; so is that code blob
[03:54] <lifeless> have you read a configure recently?
[03:54] <hyperair> sure i have.
[03:54] <lifeless> not exactly the shining light of small and simple sh code
[03:54] <hyperair> in fact, i've patched it
[03:54] <lifeless> *not* a configure.ac.
[03:54] <hyperair> ...yes sir, i know the difference between configure and configure.ac
[03:55] <lifeless> good, just checking.
[03:55] <lifeless> anyhow, I'm not here to defend waf per se; but I think the self-hostingness (which is optional btw) is fairly well done
[03:55] <brywilharris> So what's the difference
[03:55] <hyperair> and i think it's ridiculous.
[03:55] <brywilharris> I mostly write python code now
[03:55] <hyperair> so let's leave it as that.
[03:56] <hyperair> either way, i'm supposed to be reviewing a package, not commenting on the idiocy of upstream's build system of choice.
[03:56] <hyperair> _stochastic_: you there?
[03:56] <brywilharris> When I was writing code you still had a separate build and link step...
[03:56] <hyperair> meh he disappeared.
[03:57] <hyperair> i think make's awesome enough not to require crazy python hacks.
[04:00] <_stochastic_> hyperair, sorry I ran away for a second
[04:01] <hyperair> ah he's back!
[04:01] <hyperair> so anyway
[04:01] <hyperair> where was i
[04:01] <brywilharris> waf?
[04:01] <hyperair> nevermind waf.
[04:01] <hyperair> right. debian/rules.
[04:01] <hyperair> i'm not very familiar with the old debian/rules way
[04:01] <hyperair> it's too easy to accidentally leave something out
[04:02] <hyperair> i'd instead suggest the minimal dh7 rules way =D
[04:03] <_stochastic_> care to show a template/example/spec?
[04:03] <hyperair> hmm
[04:03] <hyperair> where can i find an example..
[04:03] <lifeless> /usr/share/doc/debhelper/examples/simple
[04:03] <lifeless> or something like that
[04:03] <hyperair> _stochastic_: you can take a look at geanygdb in revu
[04:04] <lifeless> /usr/share/doc/debhelper/examples/rules.tiny | rules.simple
[04:04] <hyperair> "man dh" for more information
[04:04] <hyperair> it's awesome stuff.
[04:05] <hyperair> you could also use cdbs, but many people say it's black magic.
[04:05] <brywilharris> Yo got that right
[04:05] <hyperair> mostly because it's that much harder to trace through a million and one .mk includes
[04:05] <_stochastic_> is there anything wrong with the way its packaged?
[04:05] <lifeless> as opposed to a mass of perl that calls a long arbitrary list of programs and hides errors?
[04:05] <lifeless> :)
[04:05] <hyperair> _stochastic_: you might like to ask upstream to include the GPL license.
[04:05] <hyperair> _stochastic_: seems they forgot.
[04:05] <_stochastic_> it is included
[04:05] <hyperair> _stochastic_: i don't see a LICENSE or COPYING file anywhere
[04:06] <_stochastic_> look again, it's titled gpl.txt
[04:06] <hyperair> ooh it is
[04:06] <hyperair> gpl2.txt
[04:06] <_stochastic_> yes
[04:06] <hyperair> alright then
[04:06] <_stochastic_> that's a new warning in REVU, it wasn't there a couple days ago
[04:06] <hyperair> _stochastic_: your debian/watch isn't working.
[04:07] <_stochastic_> oh? okay, I'll look into that
[04:07] <hyperair> Unknown verb pattern '' in regex; marked by <-- HERE in m/^(?:(?:http://download.gna.org)?\/a2jmidid\/)?a2jmidid-(*) <-- HERE .tar.bz2$/ at /usr/bin/uscan line 897, <WATCH> line 2.
[04:07] <hyperair> very strange.
[04:07] <hyperair> ah
[04:07] <hyperair> right
[04:07] <hyperair> .*, not *
[04:07] <_stochastic_> ah
[04:07] <hyperair> http://download.gna.org/a2jmidid/a2jmidid-(*).tar.bz2
[04:07] <hyperair> see the * there
[04:08] <_stochastic_> yes
[04:09] <hyperair> they don't release .tar.gz's do they?
[04:09] <_stochastic_> nope
[04:09] <hyperair> hmm i see.
[04:09] <_stochastic_> are you sure it should be .* the filename looks like a2jmidid-4.tar.bz2
[04:10] <hyperair> yes i'm sure
[04:10] <hyperair> this is regex.
[04:10] <hyperair> man 7 regex for more information
[04:10] <hyperair> test it with uscan
[04:10] <_stochastic_> okay
[04:10] <_stochastic_> done.
[04:11] <brywilharris> uscan --verbose
[04:11] <hyperair> alright, onto your copyright file
[04:11] <brywilharris> sorry go ahead
[04:11] <hyperair> haha no problem
[04:11] <hyperair> you're missing a few copyrights
[04:12] <_stochastic_> ? which files?
[04:12] <cody-somerville> NCommander, I noticed that grendal has been maintaining the debian packaging in the pike CVS
[04:13] <cody-somerville> NCommander, so I'm attempting to rebase all the changes in Debian onto the debian packaging in the CVS
[04:13] <hyperair> eh um nevermind
[04:13] <hyperair> whoops
[04:13] <brywilharris> http://revu.ubuntuwire.com/report.py/legal?upid=5644
[04:13] <hyperair> ./.waf-1.4.3-4cc0bec64a165ffe5dd3eed60cd2e01b/wafadmin/pproc.py <-- this
[04:13] <hyperair> heheh
[04:13] <hyperair> but i suppose this is one of the autogenerated files
[04:13]  * cody-somerville hopes what he is doing is sane. :)
[04:13] <hyperair> so nevermind
[04:14] <cody-somerville> hyperair, In that case, the clean rule should delete that
[04:14] <hyperair> cody-somerville: no i was messing around with waf earlier.
[04:14] <hyperair> cody-somerville: i'll unpack it again to check later
[04:15] <cody-somerville> ok
[04:15] <hyperair> i remember hearing some mention about needing to use the copyright symbol instead of (C)/(c)
[04:16] <hyperair> ©
[04:16] <hyperair> this one
[04:16] <_stochastic_> previous REVU uploads I've had accepted just used (c)
[04:16] <hyperair> _stochastic_: i think you can actually merge all the Nedko Arnaudov entries. i noticed you have three of those.
[04:16] <hyperair> _stochastic_: it's a very recent change.
[04:17] <brywilharris> alias ©='echo GPLv3'
[04:17] <hyperair> ._.
[04:18] <hyperair> _stochastic_: also, i'd actually suggest that you document which copyrights go to which files
[04:18] <_stochastic_> hyperair, which of Nedko's entries? where?
[04:18] <hyperair> in debian/copyright
[04:18] <hyperair>     Copyright (c) 2008 Nedko Arnaudov<EMAIL_ADDRESS>[04:18] <hyperair>     Copyright (c) 2008 Nedko Arnaudov<EMAIL_ADDRESS>[04:18] <hyperair>     Copyright (c) 2007,2008 Nedko Arnaudov<EMAIL_ADDRESS>[04:18] <hyperair> three.
[04:18] <_stochastic_> ahh
[04:19] <hyperair> well actually two, but you repeated one of them
[04:19] <hyperair> of course, if it's not too much trouble, you should actually document which copyrights go to which files
[04:19] <_stochastic_> in the machine-readable format? or is there another way?
[04:20] <hyperair> well you don't necessarily have to use machine readable format, but if you were to use it, there's http://wiki.debian.org/Proposals/CopyrightFormat
[04:21] <_stochastic_> so can  Copyright (c) 2007,2008 Nedko Arnaudov<EMAIL_ADDRESS>be used for all of Nedko's or does another need to explicitly list 2008 only?
[04:22] <hyperair> i'd actually merge the files that belong to Nedko
[04:22] <hyperair> in one single listing
[04:23] <_stochastic_> okay
[04:25] <hyperair> you're also missing one of the brackets in Copyright C) 2009, Eric Hedekar<EMAIL_ADDRESS>[04:25] <hyperair> and now the customary test-build.
[04:27] <brywilharris> for foo in `grep -ir '(c)' .|cut -d ':' -f 1|uniq`; do sed  -e 's/(c)/©/' $foo >temp; mv temp $foo; done
[04:28] <brywilharris> just make sure you don't have any variables named 'C'...
[04:30] <hyperair> i think you meant sed -i -e $foo
[04:31] <hyperair> -i means edit in place
[04:31] <brywilharris> that would work too
[04:31] <brywilharris> however, this breaks python files as I just discovered...
[04:31] <hyperair> also, the © was supposed to be in the debian/copyright file i think
[04:31] <hyperair> or something like that
[04:32] <brywilharris> python complains about the character encoding
[04:32] <hyperair> i think it's permitted to be (c) in tbe actual sources
[04:32] <brywilharris> It has to be
[04:32] <hyperair> yeah
[04:32] <hyperair> haha
[04:36] <_stochastic_> hyperair, any other issues you can spot?
[04:37] <hyperair> _stochastic_: gimme a moment to build
[04:37] <hyperair> i was updating my karmic pbuilder earlier
[04:41] <hyperair> meanwhile, i'll take a look at veusz i guess.
[04:42] <brywilharris> kk
[04:43] <hyperair> brywilharris: regarding your rules file... why don't you use a .install file instead of manually running install -d -m644 bla
[04:43] <brywilharris> OK
[04:47] <hyperair> W: a2jmidid: binary-without-manpage usr/bin/a2j_control
[04:47] <hyperair> W: a2jmidid: binary-without-manpage usr/bin/a2jmidi_bridge
[04:47] <hyperair> W: a2jmidid: binary-without-manpage usr/bin/a2jmidid
[04:47] <hyperair> W: a2jmidid: binary-without-manpage usr/bin/j2amidi_bridge
[04:47] <hyperair> _stochastic_: ^
[04:47] <hyperair> you're gonna have to write manpages for all of those =)
[04:47] <hyperair> and then add them to debian/manpages
[04:47] <hyperair> man dh_installmanpages for more information
[05:08] <brywilharris> I gotta go to bed
[05:08] <brywilharris> hyperair: Thanks for the help
[05:30] <binarymutant> If someone has the time to review my package http://revu.ubuntuwire.com/p/lxsplit I would greatly appreciate it :)
[05:30] <abuDawud> can someone explain the basic process of repackaging an unstable debian package to the latest and greatest Ubuntu distro?
[05:31] <lifeless> abuDawud: generally its just a sync
[05:31] <lifeless> https://wiki.ubuntu.com/MOTU has docs
[05:31] <binarymutant> abuDawud, you pretty much just change the changelog and control file
[05:32] <lifeless> binarymutant: unless it needs patching you should sync it not change changelog
[05:32] <abuDawud> does it involve the apt pinning process if I wanted to use apt source for requisitioning the files?
[05:32] <abuDawud> or is that over complicating things?
[05:33] <binarymutant> lifeless, I understand :)
[05:34] <abuDawud> essentially I am looking for an easy intro project into packaging after reviewing all of the documentation. I figured that would be pretty simple
[05:34] <binarymutant> abuDawud, a sync is pretty much just a bug report
[05:34] <abuDawud> binarymutant, I will look at the link lifeless posted and read up about it.
[05:34] <abuDawud> is there somewhere simpler to start?
[05:35] <lifeless> should we archive blankon-extra-backgrounds in revu, 6 months and the poster hasn't updated
[05:35] <lifeless> abuDawud: the simplest place to start is to fix a bug in a package that is in Ubuntu
[05:36] <lifeless> abuDawud: that way you're working with existing code and package, only making a small change, and don't need to know all the ins and outs
[05:36] <abuDawud> lifeless, I have been trying to find one that is not patched using harvest and looking through launchpad and I can't seem to find one
[05:37] <lifeless> abuDawud: what do you mean?
[05:37] <abuDawud> well I can't seem to find where to watch for simple bugs that just need repackaging etc
[05:38] <abuDawud> all of the bugs I find seem to either be complicated code issues or they are fixed
[05:39] <lifeless> abcmidi is an example of package which has been synced, rather than patched by ubuntu
[05:39] <lifeless> abuDawud: are you interested/experienced with any particular programming languages/environments?
[05:39] <abuDawud> lifeless, a bit of perl but its all intro stuff
[05:40] <abuDawud> lifeless, I was trying to find a way to help out with my limited code knowledge
[05:40] <abuDawud> lifeless, packaging seemed to be the way to go
[05:41] <lifeless> packaging is useful, but to package code properly you need to understand that particular language
[05:41] <lifeless> when packaging you will run into compile problems/link errors/dependencies/language issues
[05:42] <lifeless> the more you understand the particular language[s] the thing you are packaging is written in, the easier it is for you
[05:43] <binarymutant> abuDawud, if you use the advanced search in launchpad you can find new bugs that need to be triaged or for packaging you can look through this listhttp://www.debian.org/devel/wnpp/orphaned
[05:44] <abuDawud> binarymutant, thanks, I think I have some more reading to do :)
[05:54] <lifeless> whats with licencing pacaking data (often under the (C) threshold anyway) as GPL
[05:54] <lifeless> surely same-licence-as-package would be better
[05:55] <binarymutant> I <3 gpl
[05:56] <lifeless> so do I
[05:56] <lifeless> for software
[05:57] <binarymutant> how about for a Makefile? It scare me to see the nvidia license in a Makefile
[06:28] <fabrice_sp> Hi. Anyone with access to a powerpc computer? I'd like to know what is the return value of dpkg --print-installation-architecture
[06:32] <blacknred0> how come after making a package from a single script and then installing it the script will not go to /usr/sbin? what could of cause this?
[06:36] <fabrice_sp> blacknred0, inside your deb package, is it in /usr/sbin?
[06:38] <blacknred0> fabrice_sp, no
[06:38] <blacknred0> so i figure that it will never execute
[06:39] <blacknred0> how i could make the package and placing my script on /usr/sbin whenever any user executes the command?
[06:39] <fabrice_sp> blacknred0, during the building of your package, you need to 'move' the files in the correct temporary directory?
[06:39] <fabrice_sp> this temporary directory is debian/<package name>/usr/bin
[06:40] <binarymutant> If someone has the time to review my package http://revu.ubuntuwire.com/p/lxsplit I would greatly appreciate it :)
[06:40] <blacknred0> fabrice_sp, nope... currently is mypackage/tmp not mypackage/debian/...
[06:41] <blacknred0> thnx... facbrice_sp.... i would do that then...
[06:41] <fabrice_sp> ;-)
[06:43] <blacknred0> fabrice_sp, so one last question.... so should i call form rules that package? or should i have a tmp for that same script?
[06:45] <fabrice_sp> blacknred0, just put your script in the right place, in the install target in debian/rules, and it should be ok
[06:45] <blacknred0> ok, thnx :P
[06:45] <fabrice_sp> binarymutant, I'm trying to build your package in amd64, but it's not possible
[06:45] <fabrice_sp> is it normal?
[06:46] <fabrice_sp> I'm getting: lxsplit_0.2.4-0ubuntu1.dsc: amd64 not in arch list: i386 -- skipping
[06:46] <binarymutant> fabrice_sp, arch i386
[06:47] <fabrice_sp> binarymutant, why? It's not compatible with amd64?
[06:49] <binarymutant> fabrice_sp, the site didn't say it wasn't, I should change to arch all
[06:49] <fabrice_sp> binarymutant, yes
[06:50] <fabrice_sp> as amd64 is a growing arch, it would be a pity not to have it :-D (and I won't review the package :-) )
[06:54] <binarymutant> fabrice_sp, should be able to build on your architecture now, srry :)
[06:55] <fabrice_sp> binarymutant, uploaded to revu?
[06:55] <binarymutant> yes
[06:56] <fabrice_sp> ok (trying to build again)
[06:58] <fabrice_sp> binarymutant, all no. It's for arch independant packages. This one in compiled, so it should be any
[06:59] <binarymutant> fabrice_sp, oh okay, thank you, I get those two mixed up sometimes
[06:59] <fabrice_sp> so do I :-) But when building, and you see a *_all.deb, it clarify things :-)
[07:00] <binarymutant> is there anything else that is noticeable to you fabrice_sp, it's my first C package so I'm very concerned about it
[07:01] <fabrice_sp> binarymutant, I'll have a look at the packaging now (as arch is not correct, I'm getting errors in lintian)
[07:02] <fabrice_sp> you miss ${shlibs:Depends} in depends for the binary package
[07:03] <fabrice_sp> you should drop the A in the description (the short description extend the phrase this package is a ...)
[07:03] <fabrice_sp> for the long description, don't repeat the short description
[07:06] <fabrice_sp> for man page installation: I generally prefer to have it in a manpages file, but the way you do it is correct
[07:07] <fabrice_sp> the same for docs
[07:07] <fabrice_sp> otherwise, looks good (and simple ;-) )
[07:08] <binarymutant> thank you for your time I'll correct these :)
[07:09] <fabrice_sp> you're welcome. Did you uploaded a 'any' package?
[07:09] <fabrice_sp> (just to check the resulting package)
[07:09] <binarymutant> the last two issues about the manpage and the docs, could you elaborate?
[07:09] <fabrice_sp> yes :-)
[07:10] <fabrice_sp> instead of putting the name of the file you will install (for doc or for manpage) in the debian/rules file, you can put that in dedicated files in debian directory
[07:10] <fabrice_sp> manpages for man file
[07:10] <fabrice_sp> docs for doc files
[07:10] <fabrice_sp> this way, you could even have a more simple rules file, using cdbs :-)
[07:10] <fabrice_sp> (a 2 lines rules file :-) )
[07:11] <binarymutant> oh instead of using dh_ I get you
[07:11] <fabrice_sp> you still nee the dh_ stuff, but this way, it's easier to add a file
[07:11] <fabrice_sp> s/nee/need/
[07:12] <binarymutant> since its my first C package I wanted to try it with debhelper instead, it feels more in depth to me. But i've done a cdbs package and it definitely was simpler
[07:12] <fabrice_sp> I mean, you will have dh_installman instead of dh_installman debian/lxsplit.1
[07:12] <fabrice_sp> it's a good approach to learn ;-)
[07:15] <binarymutant> if you still have any time to spare the updated package been cached into revu
[07:16] <fabrice_sp> ok. I'll download it again
[07:16] <binarymutant> ty :)
[07:34] <artfwo> Hello! I am having a hard time resolving FTBFS of my REVU upload (on karmic). Does anyone have a little time to help?
[07:34] <hyperair> artfwo: what's wrong?
[07:35] <artfwo> well, here's the upload in question http://revu.ubuntuwire.com/p/scantailor
[07:35] <artfwo> and it fails to build in the PPA
[07:35] <artfwo> https://edge.launchpad.net/~artfwo/+archive/ppa/+build/987616
[07:36] <artfwo> there're lots of cryptic preprocess messages in the build logs, which have led me to debian bug 505109
[07:36] <artfwo> it's fixed in the latest debian, yep
[07:37] <artfwo> so
[07:37] <artfwo> I have merged boost1.35 from debian and also uploaded it to the PPA
[07:37] <hyperair> have you tried building with a sid pbuilder?
[07:37] <artfwo> nope, didn't think of it
[07:37] <artfwo> but anyways
[07:37] <hyperair> i'm giong to try building
[07:38] <artfwo> boost1.35 also fails to build in the PPA/Karmic after the merge
[07:38] <artfwo> due to the following error:
[07:38] <artfwo> ../boost/test/impl/debug.ipp:280: error: 'sscanf' is not a member of 'std'
[07:38] <artfwo> which again led me to upstream
[07:38] <artfwo> https://svn.boost.org/trac/boost/ticket/1542
[07:38] <artfwo> (comment:1)
[07:39] <artfwo> it does not seem to be fixed upstream, but I wonder if I can replace <stdio.h> with <cstdio> in my merge to fix it
[07:40] <hyperair> ah!
[07:40] <hyperair> right!
[07:40] <hyperair> i had an issue with that as well
[07:40] <hyperair> cstdlib
[07:40] <hyperair> you need to include cstdlib to each and every one of those files using sscanf
[07:40] <hyperair> it's not included by default any more
[07:40] <artfwo> zomg
[07:40] <hyperair> hahah
[07:41] <fabrice_sp> artfwo, why using an old boost version?
[07:41] <artfwo> fabrice_sp: mainly chose it because it's in main
[07:41] <fabrice_sp> there isn't a boost1.37?
[07:42] <fabrice_sp> in main also :-)
[07:42] <artfwo> there is, but boost1.35 is in main, so it's better supported and all, right?
[07:42] <artfwo> huh?
[07:42] <fabrice_sp> my bad: 1.37 is in universe
[07:43] <fabrice_sp> but I remember ScottK trying to get rid of boost1.35
[07:43] <fabrice_sp> so try with 1.37
[07:43] <ScottK> Actually it was boost, which is 1.34
[07:43] <ScottK> We need to pick a target boost for Karmic.
[07:43] <artfwo> right you are, 1.37 is in main as well: http://packages.ubuntu.com/source/karmic/boost1.37
[07:43] <ScottK> 1.37 or 8 not sure.
[07:43] <artfwo> 1.38 is universe
[07:44] <fabrice_sp> ohh: i'm bad at numbers :-)
[07:44] <ScottK> Doesn't mean it will stay that way.
[07:44] <artfwo> damn, I have already opened a merge bug for 1.35
[07:44] <fabrice_sp> anyway, a new package should use the latest version of a lib, right?
[07:44] <ScottK> 1.38 is the version Debian is aiming to use for Squeeze, so the faster we can line up on that the better.  Might be Karmic + 1 though.
[07:45] <artfwo> okay, I shall try 1.37 for now
[07:45] <fabrice_sp> ScottK, this kind of things will be decided at UDS?
[07:45] <ScottK> I hope so.
[07:45] <fabrice_sp> ok
[07:46] <artfwo> but then again - is 1.35 going to sink away from karmic at all?
[07:50] <fabrice_sp> artfwo, until UDS, we don't know. But it could be
[07:50] <artfwo> okay
[07:52] <savvas> so the new boost is built?
[07:53] <savvas> I'll have to proceed with cgal then :)
[07:59] <savvas> good morning btw :P
[08:00] <artfwo> well, it fails to build with boost 1.37 as well, but I think it's a matter of another bug - debian bug 525752
[08:00] <_stochastic_> Do any MOTUs want to take a look at this upgrade request that's ready for upload Bug #367735
[08:02] <artfwo> everything has worked so nice on jaunty :(
[08:05] <fabrice_sp> artfwo, we are so early in the cycle, that it's normal to have this kind of things
[08:06] <artfwo> yep, but this GCC cleanups in Karmic have just uncovered an upstream bug, which I've got to fix and forward to the author
[08:07] <artfwo> the only thing that frustrates me, is that I don't currently have enough bandwidth for pbuilder
[08:10] <savvas> _stochastic_: 1) you need to follow sponsorship process: https://wiki.ubuntu.com/SponsorshipProcess 2) did you test-build your new package?
[08:12] <_stochastic_> savvas, yes I've tested it and the upstream version fixes some bugs
[08:12] <_stochastic_> the bug is already attached to the universe sponsors, should I just sit and wait?
[08:13] <savvas> oh ok, I think what's left now is to subscribe ubuntu-universe-sponsors
[08:14] <_stochastic_> they're already subscribed
[08:15] <savvas> hm..
[08:15] <savvas> it's in the activity log but not in the subscribers list
[08:15] <savvas> weird
[08:16] <savvas> _stochastic_: oh by the way, you changed the status of the bug after subscribing the sponsors, please set it back to confirmed :)
[08:18] <_stochastic_> savvas, is there anywhere that the status policy is outlined?  I constantly am adjusting things to what I think should be the right status, but then am told to change it etc.. (it was set to triaged not confirmed)
[08:19] <savvas> it shouldn't matter what the status is, but I think "in progress" means you would take care of the sponsorship yourself
[08:19] <_stochastic_> should it go back to triaged or be switched to confirmed?
[08:19] <_stochastic_> to me, in progress was referring to the fact that progress has been made on the bug
[08:20] <savvas> if you have bug control permissions, make it triaged, if not then confirmed :)
[08:21] <_stochastic_> savvas, that sponsorship link you sent me claims that all bugs ready for sponsorship shouldn't be assigned to anyone, should I remove myself from that position now?
[08:21] <savvas> I didn't see any outline or policy about the status, but that's what I was advised to follow hehe. you shouldn't change the status after subscribing the bug to the sponsors
[08:22] <savvas> yes, that's true forgot that :)
[08:26] <savvas> _stochastic_: do you see ubuntu-universe-sponsors on the right subscribers list?
[08:26] <_stochastic_> savvas, yes I do.  don't you?  refresh?
[08:26] <savvas> I have :\
[08:27] <savvas> let me check with the normal launchpad server
[08:27] <_stochastic_> I also see it here: https://bugs.launchpad.net/~ubuntu-universe-sponsors
[08:27] <savvas> well launchpad bug I guess :)
[08:30] <savvas> config.sub config.guess
[08:30] <savvas> these are files right?
[08:31] <savvas> not that important but if you require to make any new changes to the debian package, instead of "rm -f config.sub config.guess" use "dh_clean config.sub config.guess
[08:33] <savvas> I mean something like this: http://paste.ubuntu.com/167576/
[08:38] <savvas> any motu to review http://revu.ubuntuwire.com/p/gnote ?
[08:39] <LucidFox> savvas> I'm hesitant to take responsibility for uploading it :/
[08:41] <savvas> about tarball-in-tarball? :)
[08:43] <lifeless> savvas: tarball-in-tarball is when I stopped reviewing
[08:47] <savvas> lifeless: tarball-in-tarball in general or just the fact that the maintainer used tar.bz2?
[08:49] <binarymutant> If someone has the time to review and possibly advocate my package http://revu.ubuntuwire.com/p/lxsplit I would greatly appreciate it
[08:50] <lifeless> tar-in-tar
[08:50] <lidaobing> savvas, if the upstream use tar.bz2, you can repack it with "uscan --repack"
[08:50] <lifeless> I would have said 'bz2' if I mean that
[08:53] <fabrice_sp> binarymutant, you didn't fixed the depend line
[08:54] <fabrice_sp> W: lxsplit: missing-depends-line
[08:55] <binarymutant> fabrice_sp, is Depends: ${shlibs:Depends}, not correct?
[08:57] <fabrice_sp> this is what lintian tell me when I run it against deb file
[08:57] <fabrice_sp> W: lxsplit: missing-depends-line
[08:57] <fabrice_sp> if it's normal (no dependency), you should override this lintian warning
[08:59] <savvas> well I see that's in generally not recommended on the Debian side, so I'll talk to nyu about extracting it. thank you all!
[09:00] <binarymutant> fabrice_sp, there are no dependencies
[09:01] <fabrice_sp> no even on c libs?
[09:02] <fabrice_sp> could be
[09:06] <fabrice_sp> dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
[09:06] <fabrice_sp> during build. This would explain why no dependency
[09:08] <binarymutant> I'm not sure I understand, what options are you using with lintian?
[09:10] <binarymutant> I've grepped through the includes on the files, http://paste.ubuntu.com/167625/
[09:14] <binarymutant> #include "stuff" is that for including files from the same directory? or is that from /usr/include too?
[09:16] <savvas> does that need dh_makeshlibs and dh_shlibdeps in binary-arch rule?
[09:16] <binarymutant> ah right, that might be it
[09:16] <binarymutant> thanks :)
[09:17] <savvas> I'm really not sure, but try it :)
[09:18] <binarymutant> what lintian options should I be using? I had been using -ivv
[09:19] <tuantub> i have the same warning : "warning: unknown substitution variable ${shlibs:Depends}" while building a package, what can i do to correct this ?
[09:20] <fabrice_sp> dh_makeshlibs
[09:22] <savvas> dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
[09:22] <savvas> dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
[09:22] <savvas> still there :P
[09:22] <savvas> I tried this:
[09:22] <savvas> 	dh_makeshlibs
[09:22] <savvas> 	dh_installdeb
[09:22] <savvas> 	dh_shlibdeps
[09:22] <lifeless> tuantub: it means the package doesn't have a library in it
[09:22] <lifeless> that particular binary
[09:23] <tuantub> lifeless: more detailed ? :-/
[09:24] <tuantub> lifeless: is that important or i can simply ignore it while building packages ? :-/
[09:26] <binarymutant> I can't get the lintian error :(
[09:26] <fabrice_sp> did you run it on the deb?
[09:27] <fabrice_sp> binarymutant, ^
[09:27] <binarymutant> fabrice_sp, on the *.changes
[09:27] <fabrice_sp> build the package and run lintian on the deb
[09:28] <savvas> $ lintian -i lxsplit_0.2.4-0ubuntu1_amd64.changesW: lxsplit: missing-depends-line
[09:28] <binarymutant> ah!
[09:28] <savvas> binarymutant: not *_source.changes :)
[09:30] <binarymutant> thank you thank you
[10:09] <kostmo> I'm packaging an upstream source with a daemon that needs a configuration file to run.  This configuration file is stored in a subdirectory of the main source directory.  Can I use debian/conffiles to specify this file somehow?
[10:11] <kostmo> The file needs to end up in /etc/ when installed.
[10:21] <binarymutant> "dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}" I'm getting this when I run pbuilder on my package, what does this mean? I'm using debhelper
[10:34] <lidaobing> hello, how clearsign a file with two gnupg key? (I am processing my new pubkey with this document: http://www.debian-administration.org/users/dkg/weblog/48)
[10:57] <geser> binarymutant: it doesn't know what it should replace this variable with. this warning is common as not every package using it in Depends, specifies a value which should get put in (so doesn't really need it in Depends)
[11:05] <geser> lidaobing: gpg -u keyid1 -u keyid2 --clearsign filename
[11:08] <lidaobing> geser, thanks
[11:10] <binarymutant> geser, thank you for the info. Do I need to keep it so that I don't get lintian errors though since I'm using debhelper?
[11:11] <geser> I assume you shouldn't get any lintian errors if you remove it
[11:14] <binarymutant> cool, thanks geser :)
[11:21] <binarymutant> If someone has the time to review and possibly advocate my package http://revu.ubuntuwire.com/p/lxsplit I would greatly appreciate it :)
[12:56] <trip0> anyone recommend repository creation/managment software?
[12:58] <binarymutant> trip0, like a version control system?
[12:59] <trip0> sorry, debian repository
[14:07] <LucidFox> Laney> Thumbs up for your work on f-spot in Debian!
[14:11] <Laney> LucidFox: \o/ let's hope it can stay in sync
[14:11]  * LucidFox nods
[14:11] <sebner> Laney: though you should have left it to "New" since u-m-s will set it to Confirmed :P
[14:12] <Laney> sebner: I *just* changed that
[14:12] <Laney> it was only set that way because requestsync messed up
[14:12] <sebner> Laney: kk
[14:13] <sebner> Laney: btw, can we sync gnome-do-plugins from Debian. What's with the use_csc patch in ubuntu?
[14:14] <Laney> no, I'm afraid not
[14:14] <Laney> I did the dfsging differently in Debian
[14:14] <Laney> unless you can convince meebey to upload the same thing as +dfsg1
[14:16] <sebner> Laney: what's the differenz?
[14:16] <Laney> Ubuntu has the gdata lib in BundledLibraries/
[14:18] <LucidFox> Laney> Have you talked to meebey yourself about it?
[14:18] <Laney> LucidFox: no, because I don't think it's worthwile
[14:18] <Laney> I don't mind just waiting for a new upstream
[14:19] <sebner> Laney: override override override
[14:19] <sebner> :P
[14:19] <LucidFox> He seems quite cooperative about Ubuntu compatibility, judging by my experience with f-spot.
[14:19] <Laney> yeah he's fine, I just think it'd be a waste of time
[14:25] <LucidFox> I wonder if it would make sense for me to rejoin u-u-s if I don't actively sponsor, but occasionally stumble upon a patch or sync/merge request subscribed by u-u-s that I want to work on.
[14:29] <james_w> LucidFox: you *could* actively sponsor :-)
[14:30] <james_w> lidaobing: this ibus upload doesn't require rebuilding the other ibus packages or anything does it?
[14:30] <Laney> sponsor-5-a-day?
[14:35] <lidaobing> james_w, do not
[14:35] <james_w> lidaobing: great, thanks
[14:35] <lidaobing> james_w, ibus 1.1.0.* does not remove any API
[14:35] <james_w> lidaobing: I'll review and upload now
[14:35] <lidaobing> james_w, there is a symbol file record this
[14:35] <james_w> ah, nice
[14:35] <lidaobing> jacob, in debian/libibus0.symbols
[14:36] <LucidFox> james_w> qutecom built in karmic pbuilder fine for me
[14:36] <lidaobing> james_w, thanks
[14:36] <LucidFox> -6, that is
[14:36] <james_w> LucidFox: yeah, sorry about that
[14:36] <james_w> LucidFox: please go ahead and ack it
[14:36] <james_w> I'll unsub the sponsors if you like
[14:36] <LucidFox> ok
[14:46] <AdamDH> can any one recommend any packages that go off and downloads binary sources?
[14:53] <Ampelbein> AdamDH: what do you mean?
[14:54] <kklimonda> AdamDH: flashplugin-nonfree
[14:57] <AdamDH> ah thanks flash-plugin is a good example, how when the package is installed it will download binarys so they are not part of the package
[14:58] <AdamDH> after Januty what is the next version called?
[14:59] <Nafallo> Karmic
[15:00] <ghostcube> when will the anjuta bug be fixed in jaunty
[15:00] <ghostcube> still no dist-upgrade possible
[15:00] <ghostcube> 2 weeks now
[15:01] <kklimonda> what bug?
[15:01] <ghostcube> install overwritr libgbf-1-2
[15:02] <ghostcube> its even not possible to get it manually
[15:03] <ghostcube> https://bugs.launchpad.net/ubuntu/+source/anjuta/+bug/338464
[15:03] <ghostcube> still no fix
[15:03] <AdamDH> need to get my packages into revu for Karmic, try and get them included
[15:04] <kklimonda> ghostcube: you could uninstall libgbf-1-2
[15:04] <ghostcube> nope
[15:05] <kklimonda> sure, it's just a suggestion ;)
[15:05] <ghostcube> doesnt work
[15:05] <kklimonda> hmm.. i can't reproduce it on my system..
[15:05] <ghostcube> i can give you a pastebin
[15:05] <ghostcube> it happens at upadte
[15:05] <ghostcube> from intrepid
[15:06] <kklimonda> can you paste a result of dpkg -L libgbf-1-2 ?
[15:07] <kklimonda> but that's weird - anjuta should remove libgbf-1-2..
[15:08] <ghostcube> http://pastie.org/473015
[15:08] <kklimonda> it replaces libgbf-1-common so it should just remove it and libgbf-1-2
[15:08] <ghostcube> itzs not removable
[15:08] <ghostcube> this is an manual purge
[15:08] <ghostcube> i posted you
[15:08] <ghostcube> i can try to force dpkg
[15:09] <kklimonda> why can't you remove it?
[15:09] <ghostcube> see the post of pastie says cant remove
[15:09] <kklimonda> it does? :)
[15:10] <ghostcube> ah sorry german lol
[15:10] <kklimonda> yeah..
[15:10] <kklimonda> try LC_ALL=C <command>
[15:10] <geser> ghostcube: try "sudo apt-get remove libgbf-1-2" and check what else it wants to remove before proceeding
[15:10] <ghostcube> i can show you
[15:11] <ghostcube> i did that
[15:11] <ghostcube> libgbf-1-2* libgbf-1-common* libgladeui-1-7*
[15:11]  * sebner waves at geser \o/
[15:11] <ghostcube> pkg: Fehler beim Bearbeiten von /var/cache/apt/archives/anjuta_2%3a<IP_ADDRESS>-0ubuntu1_amd64.deb (--unpack):
[15:11] <ghostcube>  Versuche, »/usr/bin/gbf-am-parse« zu überschreiben, welches auch in Paket libgbf-1-2 ist
[15:11] <ghostcube> Fehler =Error
[15:11] <geser> but it wanted to upgrade anjuta before it removed libgbf-1-2
[15:11] <kklimonda> ghostcube: it happens when you try to remove libgbf-1-2 ?
[15:12] <ghostcube> yes
[15:12] <ghostcube> and if i do dist-upgrade
[15:12] <geser> so you need to "help" it a little bit to force the correct order
[15:12] <ghostcube> always the same
[15:12] <ghostcube> geser: i tried to remove it before install no way
[15:12] <geser> which error?
[15:12] <ghostcube> the one i postet already
[15:12] <ghostcube> this is manual
[15:13] <ghostcube> it doesnt remove the package it installs first
[15:13] <ghostcube> dont ask me why it does this
[15:13] <ghostcube> never had this before
[15:13] <geser> ah, so this is from "apt-get remove libgbf-1-2" and not "apt-get install anjuta"?
[15:14] <geser> try removing anjuta too (temporarily) and install it again when libgbf-1-2 got removed
[15:14] <ghostcube> ah ok
[15:16] <ghostcube> worked
[15:16] <ghostcube> thx
[15:17] <ghostcube> but this is bad trouble as it seems
[15:17] <ghostcube> inside some packages
[15:18] <kklimonda> it shouldn't happen as anjuta conflicts with libgbf-1-2..
[15:18] <ghostcube> yeah its a bit weird
[15:18] <ghostcube> :)
[15:18] <kklimonda> i don't have a II system anymore to test upgrade..
[15:18] <ghostcube> but thx anjuta removal temp fixed it
[16:03] <LucidFox> directhex, get aggregated on Planet Ubuntu already! :)
[16:07] <james_w> dh_clideps: Warning! No Build-Depends(-Indep) on cli-common-dev (>= 0.4.4)!
[16:07] <james_w> directhex: xsp ^
[16:08] <hyperair> xsp?
[16:09] <hyperair> also, dh_clideps has a bug that results in a false positive until very recently.
[16:09] <Laney> some genius fixed it
[16:11]  * hyperair whistles
[16:11] <hyperair> that reminds me of something i should add to my UC application
[16:15] <LucidFox> ^_^
[16:16] <sebner> hyperair for UC \o/
[16:16] <LucidFox> sebner> https://wiki.ubuntu.com/hyperair/UniverseContributorApplication
[16:17] <sebner> LucidFox: nahah, can't comment because I worked too little with him (I know that he is a cool/clever guy though)
[16:18]  * hyperair feels flattered
[16:18]  * a|wen wonders why regina-normal seems to be acting out at each merge
[16:19] <LucidFox> regina-normal?
[16:19] <a|wen> the configure script refuses to find libboost-python whatever i do :/
[16:21] <hyperair> python?
[16:22] <LucidFox> Ha ha
[16:22] <hyperair> shouldnt it be setup.py then?
[16:22] <a|wen> well, python is just one of the 3 or 4 frontends built by the package
[16:23] <a|wen> (and yeah, it has multiple backends as well)
[16:23] <geser> for which boost version does it look?
[16:24] <a|wen> we try to make it find 1.35
[16:24] <geser> have you a log from configure you could paste?
[16:25] <hyperair> pastebin the configure.ac or configure.in file. that could probably yield something about how it's looking for libboost-python
[16:25] <hyperair> assuming it's an autotools script
[16:26] <directhex> james_w, it's a false message, i'd ignore it if i were you
[16:26] <james_w> fair enough
[16:27] <james_w> I did, I was just passing it along instead of filing a bug as would take just a few seconds to commit it directly if needed
[16:27] <a|wen> the configure run http://pastebin.ca/S:1417409
[16:27] <a|wen> and configure.ac http://paste.ubuntu.com/167900/
[16:28] <james_w> dear libplasma-dev, why are you out of date? no love, James
[16:30] <geser> a|wen: does a configure.log also exist?
[16:31] <a|wen> geser: no ... neither before or after a configure run
[16:32] <geser> hmm, or was the file named config.status?
[16:32] <geser> usually there is a file which is more verbose then the configure output
[16:33] <a|wen> there is a config.status ... just need to get it out of the chroot
[16:33] <james_w> config.log
[16:33] <james_w> it's not always in the root
[16:34] <a|wen> what is it that i need to install to have the cli pastebin thingy?
[16:34] <james_w> a|wen: pastebinit?
[16:35] <a|wen> :)
[16:35] <a|wen> config.status http://pastebin.com/f13848d00
[16:37] <a|wen> config.log http://pastebin.com/f43e6ccb1
[16:40] <geser> the second pastebin doesn't want to load here
[16:40] <geser> you broke pastebin.com: Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 1095524 bytes) in /home/pastebin/lib/geshi/geshi.php on line 2474
[16:41] <a|wen> oh, ups
[16:41] <Ampelbein> james_w: hi. regarding sync of mldonkey: the problem is with the Replaces: in dh-ocaml, http://paste.ubuntu.com/167905/ . It replaces ocaml-nox (<= 3.10.2-3) but as we have 3.10.2-3ubuntu1 in the repositories, the replaces doesn't work right. should i change dh-ocaml to represent the ubuntu-version?
[16:43] <lidaobing> Ampelbein,  change to: "<= 3.10.2-3.1~"?
[16:43] <james_w> it sounds like the Ubuntu version of ocaml-nox might be wrong
[16:44] <geser> I've filed a bug to get dh_ocaml moved to main to ocaml can build which should "fix" this too
[16:45] <james_w> we have 3.11.0-5
[16:45] <a|wen> geser: there is something in there that doesn't look good ... http://paste.ubuntu.com/167909/
[16:45] <directhex> which chickens do i sacrifice to advocate a package in REVU?
[16:47] <geser> a|wen: that's the reason why it couldn't find boost-python. Now you "just" need to find out why this happens :)
[16:47] <geser> james_w: only in source, binary are in depwait in dh-ocaml
[16:48] <Ampelbein> there is two issues here, i think. first is that our version of ocaml-nox is still with the dh-stuff included, second is the wrong replaces in dh-ocaml which should refer to the ubuntu-version
[16:50] <a|wen> geser: to me it mostly looks like some syntax error ... and it being in a boost file
[16:51] <james_w> Ampelbein: yeah
[17:06] <fransman> How do I get a new package in Ubuntu, what's already in Debian?
[17:08] <fransman> talking about openerp-client-web
[17:08] <fransman> http://git.debian.net/?p=debian/openerp-client-web.git
[17:09] <a|wen> fransman: it's in unstable?
[17:09] <fransman> a|wen: I am not sure
[17:12] <a|wen> fransman: it doesn't look to be in debian officially yet ...
[17:17] <fransman> a|wen: Okay, but do we need to open a ticket yet?
[17:18] <a|wen> fransman: if it get's into debian before the the feature freeze is there, you just need to test that it builds and runs on ubuntu and file a sync request (and possibly a sponsor) ... that is indeed the easiest way
[17:27] <james_w> anyone have an opinion on this patch? http://launchpadlibrarian.net/26477752/splashy_0.3.13-3ubuntu2.debdiff
[17:27] <directhex> hm. lsb-release isn't in a base ubuntu image?
[17:27] <james_w> I can't remember whether that it encouraged, or discouraged, or neither
[17:27] <james_w> directhex: how base?
[17:27] <directhex> james_w, pbuilder build
[17:28] <james_w> directhex: lsb-release probably isn't, but lsb_release might be
[17:28] <directhex> lsb-release is the package
[17:28] <directhex> make: lsb_release: Command not found
[17:28] <james_w> ah
[17:28] <directhex> causing me strife. i'll add a build-dep
[17:29] <james_w> Task: minimal, mythbuntu-backend-master, mythbuntu-backend-slave, mythbuntu-desktop, mythbuntu-frontend
[17:29] <a|wen> james_w: i would say that it makes sense with that patch ... but i don't know how our policy is
[17:29] <james_w> so it should be in any minimal install
[17:30] <directhex> sometimes life doesn't work out that way :(
[17:33] <bizkut> root@wrt:~# cat /etc/issue.net
[17:33] <bizkut> Ubuntu karmic (development branch)
[17:33] <bizkut> root@wrt:~# uname -a
[17:33] <bizkut> Linux wrt 2.4.37 #3431 Thu May 7 07:36:38 CEST 2009 mips GNU/Linux
[17:33] <directhex> @_@
[17:33] <directhex> bizkut, you have an ARM box?
[17:34] <bizkut> directhex, i got a nlsu2
[17:34] <bizkut> but that's my wrt router
[17:34] <directhex> i meant MIPS
[17:34] <directhex> but i'm dim, and mildly drunk
[17:34] <bizkut> yeah wrt350n
[17:34] <bizkut> lol
[17:35] <bizkut> but still stick with 2.4 kernel for networking thing
[17:35] <bizkut> so lame
[17:46]  * hyperair mutters darkly about how intensely stupid the intel gpu driver is.
[17:47] <doctormo> OK, I'm going to try this again now that I'm not sick and tired
[17:47] <doctormo> I'
[17:48] <doctormo> I'm not that good at packaging, I'm much more familar with python packages, which are dead easy.
[17:48] <doctormo> But this package I have is more troublesome, it's not python, it's a binary package containing user space modules for epson scanners.
[17:49] <doctormo> It requires postinst and prerm scripts to be run, but my attempts at including these scripts have so far failed.
[17:49] <directhex> doctormo, what have you tried to do?
[17:49] <a|wen> what is the news with libboost1.37 ... can we use it?
[17:50]  * hyperair thinks python packages are a pain.
[17:50] <hyperair> autotools packages are dead easy.
[17:50] <doctormo> Well, I have the rules file and I created debian/postinst and debian/prerm files, didn't work.
[17:50] <directhex> hyperair, port them to ipy!
[17:50] <hyperair> directhex: nothanks.
[17:50] <directhex> doctormo, how is your rules file written? cdbs, dh7, dh6 (lots of dh_foo commands), something else?
[17:51] <doctormo> dh6, I gather, I'll pastebin it
[17:51]  * a|wen mutters something about autotools and python combined
[17:51] <doctormo> http://pastebin.com/m55dfa40a
[17:51] <directhex> a|wen, autofoo generally.
[17:52] <james_w> doctormo: how many binary packages does the source package build?
[17:52] <doctormo> james_w: one, but it may or may not be good to have one per driver.
[17:52] <a|wen> well, just not very easy to figure out what goes wrong
[17:53] <directhex> doctormo, okay, for the sake of argument, can we try porting to dh7?
[17:53] <directhex> doctormo, in case it's a missing dh_ stanza?
[17:53] <doctormo> directhex: sure thing, your the bos
[17:53] <james_w> directhex: nope
[17:53] <james_w> dh_installdeb is there
[17:54] <directhex> james_w, oh. hrm...
[17:54] <james_w> doctormo: your sh_shlibdeps shouldn't be after dh_builddeb, but that's irrelevant
[17:54] <directhex> doctormo, is it that preinst et al are not being executed, or are not being packaged? try running "dpkg -I /path/to/output.deb preinst" to make it show you the contents of the preinst
[17:54] <james_w> there's no point in trying to calculate that stuff to put in the debs if they have already been built
[17:55] <doctormo> directhex: They're not being packaged, the control.tar.gz doesn't contain them as it should.
[17:57] <james_w> doctormo: also, presumably these modules aren't arch independent, so you should be doing the work in binary-arch, not binary-indep
[18:00] <james_w> doctormo: you can turn on DH_VERBOSE and get some visibility in to what is going on
[18:00] <james_w> maybe not enough, but it might work
[18:01] <doctormo> james_w: Thanks, these are things I don't know.
[18:02] <doctormo> http://divajutta.com/doctormo/iscan-plugins-all.tar.bz2 <- these are the relivent files
[18:03] <doctormo> james_w: I have 2 parts, one is a 64 bit version and the other is a 32 bit version, I must admit to attempting packaging beyond my station. I'm such there is a lot at fault with it.
[18:04] <james_w> # Automatically added by dh_makeshlibs
[18:04] <james_w> if [ "$1" = "configure" ]; then
[18:04] <james_w> 	ldconfig
[18:04] <james_w> fi
[18:04] <james_w> # End automatically added section
[18:04] <james_w> that's a bit worrying
[18:05] <james_w> is this file (postinst) just taken from epson?
[18:06] <doctormo> james_w: yep, made sure there was distributing rights first though.
[18:06] <james_w> well those file will want some fixing
[18:06] <james_w> but that's not the immediate problem
[18:08] <james_w> 	sed s/#DEBHELPER#// < debian/postinst > debian/iscan-plugins/DEBIAN/postinst
[18:08] <james_w> so it's doing the right thing
[18:08] <james_w>      998 bytes,    28 lines * postinst             #!/bin/sh
[18:08] <james_w>      132 bytes,     7 lines * postrm               #!/bin/sh
[18:08] <james_w>      900 bytes,    22 lines * prerm                #!/bin/sh
[18:09] <james_w> I don't see the same problem as you
[18:10] <doctormo> james_w: let me try again, `debuild` right?
[18:10] <james_w> that was just "fakeroot debian/rules binary"
[18:10] <james_w> debuild should work though
[18:11] <doctormo> hmm
[18:12] <james_w> you're not building the -64 package are you?
[18:13] <doctormo> james_w: no, is there a way to organise these two packages together?
[18:13] <james_w> probably
[18:16] <doctormo> huh, well it all seems to work, I guess I was just too tired and sick to test it right last week
[18:24] <a|wen> james_w: can you look at this ... doesn't this look like boost borked-ness? http://paste.ubuntu.com/167909/ (this is 1.35)
[18:28] <james_w> yeah, might be
[18:29] <a|wen> james_w: it looks to be the compiler going angry at the syntax ... anyone we want to report it too?
[18:30] <james_w> well, I'd confirm it was a problem in boost first
[18:30] <james_w> a minimal test case would be useful if it is
[18:35] <a|wen> okay ... i'll just make a new fresh karmic chroot and see if i can make a small test case
[18:36] <gilir> james_w: thanks for the ACKs :)
[18:36] <james_w> gilir: np
[18:36] <james_w> getting quite tiring now though, when are you going to stop for the day :-)
[18:38] <gilir> also need to do something else for today :)
[18:42] <james_w> I can't test xapian-omega as xapian-core FTBFS on i386
[18:52] <a|wen> james_w: i have a "hello world" script to show the problem ... but apparently it is already known to broken
[18:53] <james_w> 1.35?
[18:53] <a|wen> jup
[18:55] <a|wen> james_w: for reference ... this fails http://pastebin.com/f44e80488
[19:03] <tgm4883> is there an easy way to test postinst without having to build the package each time?
[19:13] <bddebian> Could someone possibly upload gnote for me from REVU?  I seem to have issues logging into REVU these days.
[19:15] <Laney> if you upload it I can archive
[19:16] <bddebian> I'm not sure I can upload to Ubuntu atm :(
[19:18] <bizkut> http://osgeeks.blogspot.com/2009/05/compiling-ubuntu-karmic-koala-mipsel.html
[19:23] <dtchen> bddebian: you can.
[19:23] <dtchen> Barry deFreese    2005-09-06 21:09:02 UTC  2005-09-06    2010-04-06 00:00:00 UTC  2010-04-06   Approved
[19:25] <geser> a|wen: compiling your paste with "g++ -I /usr/include/python2.6/ -l boost_python-py26 -lpython2.6 foo.c -o foo" works here (a karmic pbuilder)
[19:26] <a|wen> geser: wich version of libboost?
[19:26] <geser> libboost-python-dev               1.34.1-15ubuntu3
[19:27] <a|wen> well... i'm claiming that 1.35 is broken
[19:27] <bddebian> dtchen: I mean I don't have an Ubuntu box atm and I don't think I have dput set up for Ubuntu on sid but forget it
[19:28] <Laney> debsign the packages for me and I'll dput
[19:29] <Laney> that works, right?
[19:32] <a|wen> geser: 1.37 works fine as well, and i suppose 1.34 also does, though i haven't tested that
[19:33] <geser> the package for libboost-python-1.37-dev looks broken for me: /build/buildd/boost1.37-1.37.0/debian/libboost-python1.37-dev/usr/share/python-support/pyste/Pyste
[19:34] <geser> is one of the dirs in the deb
[19:35] <a|wen> he, that does not look good ... but at least it let's some things compile
[19:54] <geser> a|wen: https://svn.boost.org/trac/boost/ticket/2069
[19:57] <a|wen> geser: that does indeed look like it
[19:57] <geser> try applying the mpl.patch from this ticket
[20:00] <a|wen> geser: i'll try that a little later (rebuilding my karmic pbuilder af debootstrapping works) ... my real problem was solved by just switching to 1.37 (though someone needs to fix that packaging)
[20:03] <geser> a|wen: after applying mpl.patch, your paste builds with boost1.35
[20:04] <a|wen> geser: okay ... it sounding like swithching to 1.37 was encouraged over 1.35 so might just stick with that; but i'll apply and test just so we can get it fixed
[20:08] <bizkut> how to automate "apt-get -b source" the Unmet build dependencies when "apt-get -b source"?
[20:09] <RoAkSoAx> hey guys, how can I figure out why it FTBFS ? or how do I know which dependencies have failed to install?
[20:09] <maco> RoAkSoAx: read through the log it emails you?
[20:11] <hyperair> jpds: having done considerable work on tomboy-latex's packaging, may i add my name to debian/copyright?
[20:13] <RoAkSoAx> maco, k thanks
[20:14] <Laney> fun fix for anyone wanting to work on ubuntu-dev-tools: find all mentioned Ubuntu codenames and convert them to be pulled from LP using the API
[20:14] <Laney> I made ubuntuDevelopmentSeries() but you could use the API to get all current series
[20:20] <jmarsden> Laney: Wouldn't that make using the tools when one lacks an Internet connection impossible?  Or are you arranging for the tools to cache the set of names?
[20:20] <nhandler> Laney: That would be a little annoying to do for the non-python scripts
[20:21] <nhandler> jmarsden: Some of the tools do require an internet connection to work
[20:21] <Laney> Most of them, I'd imagine
[20:21] <Laney> nhandler: Yes. One could code up a wrapper to output them.
[20:22] <kklimonda> hey, when i compile source I get an error "error: ignoring return value of ‘write’, declared with attribute warn_unused_result", is there any way to explicitly ignore value returned?
[20:23] <nhandler> Laney: And there would be a small performance hit for the extra api call
[20:23] <Laney> that's right
[20:23] <nhandler> I think updating them every release might be more work, but it definitely makes the scripts more efficient
[20:23] <Laney> you could be clever and arrange for a cache to be generated in the postinst or similar
[20:24] <tgm4883> Is there someone who can take a look at this debconf config file I made  http://mythbuntu.pastebin.com/m135d7b0b  I was following http://www.fifi.org/doc/debconf-doc/tutorial.html#AEN113  but when I answer yes I get "[: 92: =: unexpected operator" and it doesn't ask me the nested questions
[20:24] <tgm4883> basically the problem is that debconf never asks the questions inside the if statement
[20:24] <tgm4883> but I can't see a problem with it
[20:26] <jmarsden> tgm4883: Can $RET be empty?  If so try testing more like if [ x"$RET" = x"true" ] ?
[20:30] <geser> Laney: I'm looking at your u-d-t commit. Are you aware of bug 358332? I don't know what the fix will look like but you should perhaps check that _ubuntuSeries() still works as expected after that fix
[20:31] <Laney> geser: Right, we'll have to change which exception is caught
[20:31]  * Laney subscribes
[20:35] <james_w> why do we even allowing specifying a release?
[20:36] <james_w> is it just because we don't record the current development release anywhere?
[20:36] <Laney> I thought that, but that's a potential fight that I didn't want to have
[20:36] <james_w> I like the change you made
[20:37] <Laney> the requestsync code needs a good old cleanup
[20:37] <james_w> me = findall('~(\S+)', '%s' % launchpad.me)[0]
[20:37] <james_w> urgh
[20:38] <james_w> me = launchpad.me.name
[20:38] <Laney> wasn't me guv'nor
[20:39] <james_w> yeah
[20:39] <james_w> but still
[20:39] <Laney> :)
[20:40] <james_w> team = "motu"
[20:40] <james_w> is that still used for anything?
[20:41] <Laney> yeah, for upload privs now
[20:41] <Laney> I think?
[20:41] <james_w> you changed team = "ubuntu-dev" to that, but I'm not sure why requestsync would need to know anything about motu anymore
[20:41] <RoAkSoAx> is there any documentation in the Ubuntu Wiki that shows how to work with FTBFS
[20:41] <RoAkSoAx> ?
[20:42] <Laney> james_w: only to say which team you're not a member of for the error
[20:42] <james_w> ah
[20:42] <Laney> s/error/message/
[20:42] <james_w> "don't have upload rights for this package" might be better?
[20:43] <Laney> yeah, could be. That isPerPackageUploader check is probably redundant too now.
[20:43] <nhandler> james_w: ubuntu-dev is used for Per Package Uploaders and motus and core-dev. MOTU is for normal MOTUS
[20:44] <james_w> yeah
[20:45]  * Nafallo stealth hugs james_w
[20:45] <Laney> oh, no - it's used later on
[20:45] <james_w>  canUploadPackage doesn't check per-package uploaders?
[20:45] <james_w> _findMember should check is_valid as well I guess
[20:46] <Laney> PPUs have a bit of extra text put on their sync requests
[20:47] <Laney> what does that do?
[20:47] <james_w> not sure
[20:47] <james_w> it's for deactivated teams or something I guess
[20:48] <james_w> probably won't be an issue, but for correctness I guess it should be checked
[20:48]  * Nafallo got ignored
[20:48] <james_w> hey Nafallo :-)
[20:49] <Nafallo> james_w: :-)
[20:54] <james_w> 388
[20:54] <james_w>     if lp_functions.isLPTeamMember('ubuntu-bugs'):
[20:54] <james_w> 389
[20:54] <james_w>         task.transitionToImportance(importance='Wishlist')
[20:54] <james_w> that's not right is it?
[20:54] <james_w> ubuntu-bugcontrol is the team that controls that isn't it?
[20:55] <stgraber> indeed
[20:57] <jmarsden> RoAkSoAx: I don't see anything in the wiki about FTBFS specifically... but in the general case, you "just" add patches so that the package does BFS... right?  How much is there that could usefully be written about this?
[20:59] <geser> RoAkSoAx: have you a specific FTBFS you try to solve?
[21:00] <RoAkSoAx> geser, yes
[21:01] <Nafallo> james_w: jpds says he didn't do that ;-)
[21:02] <geser> RoAkSoAx: which one?
[21:03] <RoAkSoAx> geser, : https://launchpad.net/~andreserl/+archive/ppa/+build/994515
[21:04] <geser> RoAkSoAx: that one is easy
[21:04] <RoAkSoAx> geser, how can I solve it?
[21:04] <RoAkSoAx> geser, or better yet, how is a regular process to solve a FTBFS
[21:04] <geser> /bin/sh is dash and it doesn't support {} expanding
[21:05] <geser> RoAkSoAx: the first part is to understand why it failed. but as there are many different reasons it's hard to document
[21:05] <geser> RoAkSoAx: in this case you need to expand the {} by hand
[21:06] <geser> RoAkSoAx: rm $(CURDIR)/usr/lib/keysafe/libkeysafe/cryptobotan.a
[21:06] <geser> RoAkSoAx: rm $(CURDIR)/usr/lib/keysafe/libkeysafe/cryptobotan.la
[21:06] <geser> and so on for the other
[21:07] <geser> or list all files on one line (which ever you prefer)
[21:07] <RoAkSoAx> geser, oh I see... and should I document that on the changelog?
[21:08] <geser> RoAkSoAx: yes, as you need to write one for the new version it would be best to fill it with something useful :)
[21:09] <geser> I usually write something like "Removed bashism in debian/rules" in such cases
[21:09] <RoAkSoAx> geser, ok awesome!! thanks :)
[21:10] <RoAkSoAx> geser, and should this change be sent to debian or is it just an ubuntu change?
[21:11] <RoAkSoAx> geser, and would it be better to do: Remove bashism in debian/rules that cause FTBFS?
[21:15] <RoAkSoAx> geser, btw.. should it be: rm $(KEYSAFE_LIB_DIR)/cryotobotan.a or rm $(CURDIR)/usr/lib/keysafe/libkeysafe/cryptobotan.a ?
[21:17] <geser> RoAkSoAx: I didn't look at the rules files itself, just guessed from the log: so rm $(KEYSAFE_LIB_DIR)/cryotobotan.a would be better
[21:18] <geser> RoAkSoAx: and forward it to Debian too, as they try too to get everything build with dash (IIRC it was even a lenny release goal)
[21:19] <RoAkSoAx> geser, it fails to build after doing the changes
[21:19] <geser> RoAkSoAx: what exactly you put into the changelog entry is up to you
[21:19] <geser> hmm
[21:20] <RoAkSoAx> geser, http://pastebin.ubuntu.com/168127/
[21:21] <geser> ah, that error, let me find the bug number
[21:22] <geser> RoAkSoAx: see bug 373214
[21:26] <RoAkSoAx> geser, so should I just update my pbuilder and it will be fixed?
[21:26] <geser> yes
[21:26] <RoAkSoAx> geser, k thanks :)
[21:28] <nhandler> RoAkSoAx: If you do not have a download limit per month for your internet, you might consider installing the pbuilder hook that causes it to update itself before building
[21:33] <RoAkSoAx> nhandler, k thanks :)
[21:34] <RoAkSoAx> btw.. in the changelog, for example in last ubuntu version they created a patch, in the newer debian version that patch has been merged, but there's nothing on the changelog about it. In the ubuntu version i'm merging should I include something in the changelog that says: drop xxx.patch ?
[21:36] <james_w> yep
[21:38] <RoAkSoAx> james_w, so It would be something like: Drop debian/patches/xx.patch. Included upstream?
[21:38] <james_w> yeah
[21:38] <nhandler> RoAkSoAx: Keep in mind, there really aren't strict requirements for debian/changelog. You just want to explain the changes you make and why you are making them.
[21:39] <RoAkSoAx> ok awesome. Thanks guys :)
[21:55] <Laney> http://www.ouaza.com/wp/2009/05/09/quilt-patch-management-with-debhelper-7/
[21:55] <Laney> phwoar
[21:56] <sebner> Laney: lol, just a minute ago I read this blog entry and now you post the link ^^
[21:56] <Laney> \o/
[21:58] <nhandler> sebner: I read the blog entry on the planet too
[21:58] <sebner> Laney: we have to tell meebey!
[21:58] <sebner> nhandler: ^^
[22:00] <nyu> whoops, debhelper is becoming cdbs
[22:00] <sebner> nyu: but much saner ;)
[22:00] <directhex> and overridable, rather than shake-your-fist-at-itable
[22:03] <nyu> I was never really fond of the implementation in cdbs (even if I wrote part of it myself).  it's the concept that makes it so useful
[22:03] <nyu> which has been implemented a few times already.  if debhelper will finally "get it right", I'm happy with that
[22:05] <binarymutant> if anyone would care to review and possibly advocate my package, http://revu.ubuntuwire.com/p/lxsplit, I would be very appreciative
[22:19] <neversfelde> hi, how do I test a get-orig-source rule in debian/rules?
[22:20] <sebner> neversfelde: chmod +x rules then ./debian/rules get-orig-source
[22:23] <Laney> or make -f
[22:24] <neversfelde> it is up do date, so I think it works, thank you
[22:31] <neversfelde> do I have to create a foo_version.orig.tar.gz of the svn dir by myself, or is that wrong?
[22:32] <a|wen> neversfelde: you create an orig.tar.gz from an svn export
[22:32] <Laney> neversfelde: if you are packaging a snapshot you should write a get-orig-source rule which generates the orig
[22:33] <Laney> it will probably use svn export, yes
[22:40] <neversfelde> mhh, I should have another look at the documentation, ty
[22:44] <james_w> JontheEchidna: hey, do you really need a transitional package for windowslist if it was only in karmic?
[22:45] <JontheEchidna> oh, for some reason I thought it was in jaunty
[22:45] <JontheEchidna> it was in jaunty ;-)
[22:45] <james_w> really?
[22:45] <james_w> not according to LP
[22:46] <JontheEchidna> brb
[22:46] <james_w> oh, it's a source package rename as well?
[22:47] <james_w> which was apparently renamed from something previous to that
[22:47] <james_w> can't you make your minds up? :-)
[22:48] <a|wen> not when upstream can't ;)
[22:48] <JontheEchidna> sorry, phone
[22:48] <james_w> np
[22:50] <JontheEchidna> plasmoid -> plasma-widget was a rename for all plasma widgets
[22:50] <JontheEchidna> Debian decided on a different name than we had...
[22:50] <JontheEchidna> so we got to rename all of the plasmoids
[22:51] <JontheEchidna> but windowslist -> windowlist was an upstream change
[23:16] <neversfelde> gnah, I always gets an
[23:16] <neversfelde> svn: Syntax error in revision argument 'svn://anonsvn.kde.org/home/kde/trunk/extragear/network/choqok'
[23:16] <neversfelde> svn: Syntax error in revision argument 'svn://anonsvn.kde.org/home/kde/trunk/extragear/network/choqok'
[23:16] <neversfelde> sorry
[23:17] <neversfelde> and  I followed our MOTU docs
[23:17] <neversfelde> the line in rules is
[23:17] <neversfelde>         svn export -r $(SVN_REVISION) svn://anonsvn.kde.org/home/kde/trunk/extragear/network/choqok choqok \
[23:17] <neversfelde> and I changed changelog before
[23:18] <neversfelde> any suggestions?
[23:18] <james_w> $(SVN_REVISION) is not set
[23:18] <james_w> it's complaining that the url is a bad revision ('-r') argument
[23:18] <neversfelde> I thought it is enough to do this in changelog?
[23:18] <james_w> nope
[23:20] <neversfelde> so where do I have to mention it?
[23:23] <JontheEchidna> in debian/rules
[23:24] <JontheEchidna> lemme paste an example
[23:24] <JontheEchidna> http://paste.ubuntu.com/168179/ (This is from the old lancelot package
[23:31] <neversfelde> mhh, thanks so far, it does not work at the moment, I will have another look tomorrow
[23:33] <neversfelde> oh, I think I got it, was a simple typo