[00:08] <joh> How would you typically invoke get-orig-source? Directly with debian/rules?
[00:10] <joh> Is ${DEB_SOURCE_PACKAGE} set anywhere?
[00:19] <cheatr> Could someone explain the difference between  Build-Depends and Build-Depends-Indep?
[00:39] <pochu> joh: I think './debian/rules get-orig-source' is ok
[00:39] <pochu> cheatr: -Indep are only used for building arch:all packages (they are only built once, usually on i386 for Ubuntu, whereas arch:any packages are built once for each architecture)
[00:40] <mok0> cheatr: -indep are also used to run the clean target
[00:40] <joh> pochu: Ok
[00:41] <pochu> mok0: I thought packages used in clean should be in Build-Depends and not -Indep
[00:41] <pochu> mok0: as you want to clean it in every architecture ;)
[00:42] <joh> pochu: You always want to be able to clean the package though, arch dependent or not :-)
[00:42] <mok0> pochu: you may be right
[00:43] <joh> s/package/source tree/
[00:43] <mok0> you have to be very careful with debian/rules to design it so it can build arch and indep targets independently of each other
[00:44] <mok0> for example, if the indep package is doxygen generated documentation, you can put doxygen in Build-Depends-Indep
[00:46] <mok0> pochu: I think the clean target is only called when you build the source package
[00:51] <pochu> mok0: right, but if you build some arch:any packages in say hppa you will call the clean target, so you need things called in clean to be installed
[00:51] <pochu> so they need to be in Build-Depends and not in -Indep
[00:51]  * jdong thinks the new update-manager security update notification icon is evil and nice :)
[00:52] <jdong> that bold red exclamation mark really gets the point across
[00:52] <jdong> only thing that'd do it better is if in 7 days it turns into a glowing pair of red eyes...
[00:52] <mok0> pochu: afaik the indep targets are only built on the i386 platform, all others are binary package only
[00:53] <pochu> mok0: yes, but they will call clean anyway
[00:53] <pochu> that's http://lintian.debian.org/reports/tags/clean-should-be-satisfied-by-build-depends.html
[00:53] <pochu> "The specified package is required to run the clean target of debian/rules and therefore must be listed in Build-Depends, not Build-Depends-Indep, even if no architecture-dependent packages are built. "
[00:54] <mok0> pochu: I stand corrected
[00:54] <pochu> I should be misunderstanding you then
[00:54] <pochu> 01:40 <      mok0> cheatr: -indep are also used to run the clean target
[00:55] <mok0> Of course the easiest is to avoid using Build-Depends-Indep altogether :-P
[00:55] <superm1> jdavies, got a few min?
[00:55] <superm1> oops
[00:55] <superm1> jdong,
[00:55] <superm1> that is
[00:56] <emgent> there is a big problem in pulseaudio
[00:56] <emgent> now my laptop sound dont work
[00:56] <jdong> superm1: reviewing for a test, but shoot if it's fast
[00:57] <emgent> last ubuntu updates?
[00:57] <pochu> good night
[00:57] <superm1> jdong, no i am just trying to get you for more than 3 min to discuss this handbrake build system
[00:57] <superm1> to see where you got on things
[00:57] <jdong> superm1: I havent' given it much of a look
[00:58] <superm1> o
[00:58] <jdong> superm1: if the archive admins are okay with it carrying embedded versions of the libs it wants, I think we should just prefetch the versions it wants for it, then build statically against it
[00:58] <jdong> superm1: i.e. do the fetching step while building the src pkg
[00:58] <superm1> jdong, could you shoot an e-mail to ubuntu-devel about it ?
[00:58] <jdong> superm1: I think this is not a bad idea either because we are talking about encoding against iPods and other sensitive-to-format devices and upstream often has good reason for picking said versions
[00:59] <superm1> well not often, sometimes it 's just for convenience
[00:59] <superm1> eg look at the date that they picked the version and the latest version available on that date
[01:00] <jdong> superm1: I recall there being a big differential the last time I looked
[01:00] <jdong> superm1: esp. for things like ffmpeg that change on a daily basis, it felt to me like they made particular choices
[01:00] <superm1> jdong, well if ubuntu-devel says no, then i say we go to devs
[01:01] <superm1> and talk to them about the choices they made
[01:01] <superm1> and how hard coded they are on those versions
[01:03] <jdong> superm1: agreed
[01:03] <jdong> but we do have precedence for bundling encoders with volatile APIs
[01:03] <jdong> VLC, mplayer (at some points), gstreamer, etc
[01:03]  * superm1 shoves mythtv aside
[02:21] <bddebian> Heya
[02:32] <sommer> ScottK: uploaded an adjusted php5-clamav package to the ppa
[02:32] <ScottK> sommer: Cool.  How did it go?
[02:33] <sommer> ScottK: built and tested fine on my machine... basically the same issue as python-clamav
[02:33] <ScottK> Cool.
[02:34] <sommer> the url in the debian/copyright file is no longer active however
[02:35] <ScottK> sommer: I'm asking the Debian clamav maintainer how he'd like to proceed now.
[02:36] <sommer> ScottK: cool, which channel?  (I need to get more involved with debian :)
[02:36] <ScottK> It's a PM at the moment.
[02:37] <sommer> ah
[02:37] <sommer> I also took a look at dansguardian, and there's a new up up stream release that covers 0.93
[02:37] <sommer> is it better to backport or do an NMU, and sync?
[02:37] <ScottK> I'll ask.
[02:38] <sommer> ScottK: cool thanks
[02:39] <ScottK> According to him dansguardian was just uploaded.  Would you check if it needs a merge or is we can just wait for it to sync.
[02:40] <sommer> ScottK: sure, where do you chack for merges? :)
[02:41] <ScottK> sommer: Look in Launchpad and see if there's an Ubuntu diff.
[02:41] <sommer> ScottK: nm, reading https://wiki.ubuntu.com/UbuntuDevelopment/Merging
[02:41] <ScottK> K
[02:42] <sommer> ScottK: ah thanks, I'll do that too
[02:57] <sommer> ScottK: from what I can tell after reading the merge page and the package page: http://packages.ubuntu.com/intrepid/dansguardian... a sync will be fine
[02:57] <sommer> ScottK: is the package page the one you meant when refering to LP?
[03:01] <ScottK> That's the one.
[03:02] <sommer> great, I'll move on down the list
[03:04] <ScottK> sommer: I tend to look on LP becuase it's more up to date.  We have it already: https://launchpad.net/ubuntu/intrepid/+source/dansguardian/2.9.9.4-1
[03:05] <sommer> ah, I always forget the /ubuntu/codename part of the url
[03:06] <sommer> ScottK: that's the latest version on the dansguardian website, so we should be good
[03:06] <ScottK> Would you please upload that to the PPA.
[03:06] <sommer> sure
[03:06] <ScottK> With an appropriate version number.
[03:58] <RoAkSoAx> no0tic, have you created a pbuilder already=
[03:58] <RoAkSoAx> ?
[03:58] <no0tic> not for intrepid
[03:58] <RoAkSoAx> no0tic, im building it without problems
[03:58] <no0tic> I'm waiting the new disc! :)
[03:59] <RoAkSoAx> i thought you already got it
[04:01] <RoAkSoAx> no0tic, anyways, i guess they fixed libc6 issue, but i did this and it is going good so far: sudo pbuilder create --distribution intrepid --othermirror "deb http://it.archive.ubuntu.com/ubuntu intrepid universe multiverse"
[04:03] <CTho> !seen mario_limonciell
[04:11] <sommer> ScottK: dansguarding == success, uploading to the ppa
[04:11] <ScottK> sommer: Great.
[04:12] <bddebian> Anyone very familiar with doxygen?
[04:12] <ScottK> sommer: Would you please file a bug against php-clamavlib with a debdiff for your change and I'll upload it to Intrepid and then send it to Debian.
[04:12] <sommer> sure will do
[04:20] <sommer> ScottK: Bug #227588, in case it doesn't email you :)
[04:20] <ScottK> sommer: Thanks
[04:20] <sommer> np, think I'm going to call it a night... I'll update the wiki tomorrow
[05:49] <ethana2> anderson58ken: hi
[05:49] <ethana2> hey, could we get tesseract into repositories?
[05:49] <ethana2> or is there some other OCR software already there?
[05:50] <RoAkSoAx> ethana2, tesseract-ocr
[05:50] <ethana2> oh
[05:51] <ethana2> is there any way to make add/remove show things without gui frontends?
[05:51] <ethana2> anderson58ken: sudo apt-get install tesseract-ocr
[05:52] <RoAkSoAx> ethana2, you mean in the comand line?
[05:52] <anderson58ken> y
[05:52] <ethana2> nevermind ;)
[05:52] <ethana2> back in 10
[06:27] <ethana2> anderson58ken: you got it installed?
[06:28] <dholbach> good morning
[06:47] <RoAkSoAx> anyone here that can help me?
[06:47] <ethana2> possibly
[06:47] <RoAkSoAx> ethana2, packaging stuff ?
[06:47] <ethana2> involving a package needing modification in or addition to ubuntu repos?
[06:47] <ethana2> oh
[06:47] <ethana2> yeah, this is the place
[06:47] <ethana2> ...i think
[06:47] <ethana2> (I'm not talking about /me/ though)
[06:48] <RoAkSoAx> ethana2, yeah i know, but i ment you lol...
[06:48] <ethana2> sorry ;(
[06:48] <RoAkSoAx> ok np ;)
[06:48] <RoAkSoAx> seems everyone is sleeping
[06:50] <RAOF> !ask | RoAkSoAx
[06:51] <RoAkSoAx> RAOF  i know that.. but at this time of the day everyone is sleeping so i was just wondering is someone was alive that could helo me
[06:51] <RoAkSoAx> RAOF, you expert in packaging?
[06:52] <RAOF> RoAkSoAx: I'm a MOTU.  I can _probably_ help.
[06:52] <RAOF> RoAkSoAx: The nice thing about worldwide collaboration is that someone's _always_ awake.  It's mid afternoon here :)
[06:53] <ethana2> late evening here :)
[06:53] <RoAkSoAx> RAOF, here is almost 1 hour after midnight xD
[06:53] <ethana2> I mean, it's 9:53, but since we're so far north, still very bright out
[06:53] <RoAkSoAx> RAOF, ok 'll explaing my prob... i did a merge and after doing the necessary changes i tried to build the binary and i got this error: http://pastebin.ubuntu.com/10679/
[06:54] <RoAkSoAx> RAOF, since it shows problem with patch 99_... i supposed i had to drop the patch and i did it... so after dropping, i built another source package and then tried to build the binary again and i got this error: http://pastebin.ubuntu.com/10680/
[06:55] <warp10> Good morning
[06:55] <RoAkSoAx> any ideas what could be wrong?
[06:55] <RoAkSoAx> good morning warp10
[06:55] <warp10> hi RoAkSoAx
[06:56] <RAOF> RoAkSoAx: Right; so, this is one of autotools less endearing features.
[06:57] <RoAkSoAx> RAOF, so what should i do?
[06:57] <RAOF> What's happened is that someone has made some changes to the build system, presumably to make it look for mozilla-xpcom in teh right place or something.
[06:58] <RAOF> Changing the build system requires re-running autoconf, which shouldn't be done at package build time because it makes things non-deterministic (or less obviously deterministic).
[06:58] <RAOF> So, you re-run autoconf and then work out the diff between the new buildsystem files and the old files; this is what 99_... was.
[06:59] <RoAkSoAx> ok, the Build-Depends in debian/control are: http://pastebin.ubuntu.com/10681/ and i think mozilla-com is this package: xulrunner-1.9-dev (something to note, MoM only showed me that there were conflics on the Build-Depends)
[07:00] <RAOF> This indicates that the packaging is non-trivial; you'll need to understand what's being patched and why before you can actually perform the merge.
[07:01] <RAOF> (Moreso than usual; you should have at least a basic understanding of the packaging for any merge, and checking for that is part of the sponsorship duties)
[07:01] <RoAkSoAx> RAOF, that patch was for:   * rerun autotools
[07:01] <RoAkSoAx>     - debian/patches/99_autotools_rerun.patch
[07:02] <RAOF> RoAkSoAx: Yeah; I know.  What you need to work out is what part of the buildsystem was patched, why it was patched, and probably end up re-running autotools and creating a new 99_autotools_rerun.patch.
[07:02] <RAOF> One of the previous patches probably touches a Makefile.am or configure.ac; that's the buildsystem change you're interested in.
[07:04] <RoAkSoAx> RAOF, do you have any documentation that i can see to do it (i'm just learning packaging =)
[07:08] <RAOF> RoAkSoAx: I'd suggest trying a different merge if you're just learning; build system changes are always ugly and autotools is the work of Satan.
[07:09] <RoAkSoAx> RAOF, what if i've already reported it and suscribed to u-u-s ? https://bugs.launchpad.net/ubuntu/+source/blam/+bug/226670
[07:10] <RAOF> RoAkSoAx: You shouldn't have subscribed u-u-s until you'd finished the merge.  u-u-s subscription should be once you've finished and have uploaded the debdiff.
[07:11] <RAOF> RoAkSoAx: I'm a member of u-u-s, so I can unsubscribe; you'll want to unassign yourself from the bug with a comment that it's free.
[07:12] <ethana2> DANGIT
[07:12] <ethana2> Satan on irc.freenode.net is already registered
[07:12] <RoAkSoAx> RAOF, yep now i know i shouldn't have, but i did what i was told there... and i just realized of this problem when redoing the merge (because i wanted to redoit to get more familiarized)
[07:12] <RAOF> RoAkSoAx: Did you upload that debdiff without testing that it built?
[07:12] <ethana2> I was going to have him show up and denounce it ;)
[07:12] <RAOF> Heh.
[07:13]  * RAOF stops trying to chase the null pointer through nv40 gallium.
[07:13] <ethana2> oh?
[07:13] <ethana2> RAOF: is it close to being usable?
[07:14] <ethana2> RAOF: the FOSS nVidia drivers?
[07:14] <RAOF> ethana2: Depends on what you mean by "usable".  ~
[07:14] <RAOF> Yes, the foss nvidia drivers.
[07:14] <ethana2> Human Being playing tremulous
[07:14] <ethana2> ...usable?
[07:15] <RAOF> Dunno.  Never tried tremulous.
[07:15] <ethana2> nexuiz?
[07:15] <ethana2> any 3d thing
[07:15] <RAOF> It works for neverput & neverball.
[07:15] <RAOF> And PPracer
[07:15] <ethana2> sweeeet!
[07:15] <ethana2> compiz?
[07:15] <RAOF> And OpenArena
[07:15] <ethana2> does OpenArena work well with it?
[07:15] <RAOF> No, not compiz.  It doesn't yet support a bunch of necessary hooks.
[07:15] <RAOF> Yes.
[07:15] <ethana2> but it probably will soon, right?
[07:16] <RoAkSoAx> RAOF, in my learning process i didn't realized that it haven't built the first time... and as i said... i just realized that it didn't when redoing it :(
[07:16] <ethana2> within 6 months?
[07:16] <RAOF> ethana2: Dunno.  If Canonical hired a full time dev, my answer would be 'almost certainly, and we'd be shipping nouveau by default for nv40'.
[07:17] <ethana2> ok then
[07:17] <ethana2> my Ubuntu dell will be an nVidia card
[07:17] <RAOF> But it depends.
[07:17] <ethana2> is nv40 what's in the 8400gs?
[07:17] <RAOF> Noooooo.
[07:17] <ethana2> oh
[07:17] <ethana2> what's the 8400gs?
[07:17] <RAOF> nv4x == 6xxx/7xxx, nv5x = 8xxx/9xxx
[07:18] <ethana2> ah
[07:18] <ethana2> are there any exceptions to that?
[07:18] <RAOF> nv5x is currently undersupported.  I'm not sure if there's _any_ 3d for it yet, and 2d is very much unfinished.
[07:18] <RAOF> ethana2: No, I don't think so.  Not like that stupid Geforce 4 MX business.
[07:18] <ethana2> I think I heard about that card today....
[07:19] <ethana2> when i mentioned my radeon 9200se
[07:19] <ethana2> something about sucking horribly, i may be mistaken
[07:19] <RAOF> Yeah; the GF4MX was _actually_ a GF2 chip.
[07:19] <RoAkSoAx> RAOF, so... you going to unsuscribe it from u-u-s and i should do that too and add a comment that it is free to be merged??
[07:19] <RAOF> RoAkSoAx: Yes.
[07:19] <RAOF> RoAkSoAx: Unsubscribed.
[07:20] <ethana2> RAOF: well it sounds like you wouldn't consider nv5x support to be a /problem/ in the future
[07:20] <ethana2> just the present
[07:20] <ethana2> that's good enough for me to buy one I guess
[07:20] <RAOF> That's true; I'd be buying ATI at this point though.
[07:20] <ethana2> my other option on the Dell Inspiron is the X3100
[07:20] <ethana2> 1/2.8x the power of the 8400gs
[07:21] <RoAkSoAx> RAOF, ok thanks, and sorry for the inconvenience... but i would still like to have documentation to work on it and just learn by myself... got any?
[07:21] <ethana2> and I'm going to be watchin peach and playing apricot, so I need all the power I can get ;)
[07:21] <RAOF> Yeah.  If it wasn't blown out of the water by ATI or nvidia cards, I'd be totally there.
[07:21]  * ethana2 goes to leave you fine gentlemen alone now
[07:21] <RAOF> RoAkSoAx: I'm not sure if I've seen any 'patch the buildsystem' documentation.  I certainly can't remember any.
[07:21] <ethana2> thanks for all the info, RAOF
[07:22] <RoAkSoAx> RAOF, ok thanks, and sorry for the inconvenience  =(
[07:22] <RAOF> No inconvenience at all!
[07:23] <RAOF> Feel free to ask as many questions as you like; much easier to learn from other peoples experience than from your own mistakes :)
[07:24] <RoAkSoAx> yeah thanks very much for your help RAOF :D
[09:50] <CrippledCanary> could someone pleas look at possibly sponsor Bug #224241
[09:58] <slytherin> where can I see how many packages are there in u-u-s queue? Just curious.
[09:58] <Hobbsee> bugs.lp.net/~ubuntu-universe-sponsors
[10:01] <slytherin> Hobbsee: guess what, your link does not go to launchpad. :-P
[10:01] <Hobbsee> slytherin: expand it :)
[10:02]  * Hobbsee typed it from memory, rather than visiting
[10:02] <slytherin> Hobbsee: still you should check it. There is actually a site called lp.net. :-)
[10:02]  * Hobbsee thought you would be skilled enough to automatically expand it.
[10:03] <Hobbsee> apologies for not typing every single character.
[10:04] <slytherin> Hobbsee: are you being serious? It is not your fault. I overlooked it. No offense meant.
[10:05] <Hobbsee> slytherin: oh ;)
[10:05] <Hobbsee> slytherin: sorry, i'm still kinda stunned at the stuff that has come out in -meeting today.
[10:06] <Hobbsee> so i'm trying to be careful, and not break rules that i don't know about
[10:08] <\sh> Hobbsee, one solution: just swear at me..I'm used to it ;)
[10:08]  * norsetto swears at \sh
[10:08] <Hobbsee> \sh: i can't.  even if i apologise to you, i'm still a leader in stuff related to ubuntu, and so it gets held against me forever.
[10:09] <Hobbsee> \sh: i'm unsure if it makes a difference if the apology is publically logged or not, but i do hope not to need to try it.
[10:09]  * \sh doesn't file complains for every little crap said in any channel here
[10:09] <Hobbsee> yes, you don't.  but others might, on behalf of you, and it still gets me lynched.
[10:09] <Hobbsee> see the -meeting earlier :)
[10:10] <Hobbsee> (this is the kind of stuff as to why i'm still stunned)
[10:10] <\sh> Hobbsee, oh hell yes...the moses problem and the hundreds of thousands laws around them
[10:11] <\sh> no crime without a law
[10:39]  * slytherin searches meeting log
[10:39] <laga> slomo__: URL? ;)
[10:39] <laga> err, slytherin. sorry.
[10:41] <slytherin> laga: I am not sure I have found the right one, I just started reading it. - http://irclogs.ubuntu.com/2008/05/06/%23ubuntu-meeting.txt
[10:46] <laga> ugh. interesting drama.
[10:47] <i4x> good morning!!
[10:48] <i4x> hugs for everybody!..
[11:02] <Hobbsee> laga: unfortunately, yes ;)
[11:08] <ajmitch> did I miss something interesting?
[11:11] <\sh> ajmitch, you miss all the funny things ;) /me too ;)
[11:40] <norsetto> all bow to huats (so that he will give you an ubuntu t-shirt)
[12:10] <mok0> Please remind me: how can I list all packages that provide a certain meta-package?
[12:12] <pochu> mok0: do you mean that provide a virtual package?
[12:12] <mok0> pochu: yes, I need to know what packages provide libgl-dev
[12:13] <pochu> If so, 'aptitude show $package' will do the trick
[12:14] <mok0> pochu: THANKS!
[12:14] <mok0> pochu: AFAIK some of the proprietary Nvidia packages also include a version of GL
[12:15] <mok0> pochu: I hope they provide that virtual package as well...
[12:17] <wgrant> mok0: IIRC they divert something.
[12:17] <mok0> wgrant: ok, great
[12:17] <wgrant> So they probably won't provide them.
[12:19] <pochu> what's the right place to explain the renaming of a source package? debian/README.Debian-source?
[12:19] <pochu> hmm, README.source
[12:20] <wgrant> Isn't it README.source?
[12:20]  * wgrant checks.
[12:20] <wgrant> There's a standard now.
[12:20] <mok0> pochu: copyright I think
[12:20] <wgrant> mok0: No.
[12:20] <mok0> README.source has been discussed on the DD list
[12:21] <mok0> As I understand it, it's for explaining how to build a source package that can not be done using the standard tools
[12:21] <pochu> http://lists.debian.org/debian-devel-announce/2008/04/msg00016.html
[12:21] <pochu> but I'm not sure this can be included here
[12:21] <pochu> "a
[12:21] <pochu> package where one one cannot unpack the source package with dpkg-source -x
[12:22] <pochu> and immediately get the source that would be built"
[12:22] <mok0> pochu: right
[12:22] <wgrant> pochu: Are you renaming binaries as well?
[12:22] <pochu> here if you can do 'dpkg-source -x' I assume you already have it packaged, so the renaming of the upstream tarball has already been done...
[12:23] <gnomefreak> anyone with a intrepid system/chroot can you please try gpg --edit-key adduid <keyID> or <email for key>? im trying to add an address to my key and its not working
[12:23] <mok0> pochu: in what way are you renaming a source package?
[12:23] <pochu> wgrant: this is because there's too 'alarm-clock' packages been packaged, one in Debian and one in REVU, so I'm suggesting the REVU packager to rename it (or to talk to the Debian owner of the ITP)
[12:23] <gnomefreak> and it prints gpg info (version, ect...) than back to command propmt
[12:24] <wgrant> pochu: Is it already in Ubuntu?
[12:24] <joh> pochu: Hi, could you please see my comment on revu regarding alarm-clock?
[12:24] <pochu> so he has proposed to rename it to alarm-clock-applet, but that would need to be done to the source package too, which should then be documented
[12:24] <pochu> oh joh, you're here :)
[12:24] <pochu> wgrant: nope
[12:24] <slytherin> gnomefreak: shouldn't keyid be immediately after --edit-key?
[12:24] <joh> Hah, you're talking about my app :P
[12:24] <wgrant> pochu: Why would you document it, then?
[12:24] <gnomefreak> slytherin: i thought adduid was but maybe that is after getting into gpg :) thanks ill try
[12:25] <mok0> pochu: I would think changelog, then, that's what I am doing with mesa-glw
[12:25] <wgrant> pochu: No point documenting it if it's only on REVU.
[12:25] <joh> pochu: Why would the source package need to be renamed btw? The binary itself is named 'alarm-clock-applet' for what it's worth...
[12:26] <gnomefreak> slytherin: thanks that was it
[12:26] <pochu> joh: because (I think) there can't be two source packages with the same name
[12:26] <pochu> wgrant: well, it will some day hit the archive and if I go and update it I would like to know what changes have been done to it
[12:26] <joh> pochu: Ah you meant that source package. I thought you were talking about the original tarballs. Sure :-)
[12:26] <pochu> wgrant: although I think i see your point, that it's obvious to what it has been renamed looking at the actual name
[12:27] <mok0> What's the difference between the two alarm clocks?
[12:27] <wgrant> pochu: It hasn't been renamed if it was only known by the old name on REVU.
[12:27] <joh> mok0: the one in debian is a stand-alone python app, mine's a gnome applet.
[12:27] <pochu> wgrant: ah, sorry, with renaming I mean renaming from the upstream tarball, not from an old package
[12:28] <wgrant> pochu: No need for a comment.
[12:28] <pochu> I mean, this is not a transition
[12:28] <mok0> joh: then I think the package should be called alarm-clock-gnome-applet
[12:28] <joh> mok0: Really? Cause other gnome-applets have names ending only in -applet, like sensors-applet.
[12:28] <mok0> pochu: I would think it is sufficient to document in the changelog
[12:28] <wgrant> alarm-clock-applet
[12:28] <wgrant> It's not a change!
[12:28] <mok0> ah well
[12:28] <joh> wgrant: *nod*
[12:28] <wgrant> it doesn't need documentation.
[12:29] <pochu> ok
[12:29] <mok0> As someone running kubuntu, it is nice to be able to see from the package name that the applet is for gnome
[12:30] <mok0> But that's only my 2 cents
[12:30] <wgrant> mok0: Other GNOME applets are -applet.
[12:30] <wgrant> Aren't KDE applets plasmoids?
[12:30] <mok0> wgrant: yeah
[12:30] <mok0> wgrant: plasmoids? :-)
[12:31] <wgrant> It does seem odd to just call them -applet, but it's also odd to not follow convention.
[12:31] <pochu> well, the description is "Description: Alarm Clock applet for the GNOME panel"
[12:31] <mok0> wgrant: it's probably wise to follow convention
[12:31] <wgrant> mok0: Plasma has plasmoids.
[12:31] <norsetto> whats wrong with gnome-alarmclock-applet?
[12:31] <mok0> I like the sound of that
[12:32] <joh> So what changes are needed to change the name? Other than editing control and changelog?
[12:32] <mok0> joh: that's it
[12:32] <joh> norsetto: Well, it's not officially part of gnome so I'm a bit reluctant about branding it that way...
[12:32] <joh> mok0: Nothing in rules needed?
[12:32] <mok0> joh: is the applet already in hh?
[12:33] <joh> mok0: hh?
[12:33] <mok0> hardy heron
[12:33] <joh> mok0: no
[12:33] <norsetto> joh: it doesn't need to be officially in gnome for that
[12:33] <pochu> joh: that's for the binary package. for the source package, rename the orig.tar.gz and move the alarm-clock-*/ directory to the new name
[12:33] <norsetto> joh: see gnome-mplayer as an example
[12:33] <joh> pochu: ok, thanks.
[12:34] <\sh> grmpf
[12:34] <joh> norsetto: That's true.
[12:34] <\sh> damnit
[12:34] <norsetto> joh: btw, it fails compilation in intrepid, did you check if it compiles with gcc-4.3?
[12:34] <\sh> who the hell packaged this tool
[12:34] <joh> norsetto: Haven't tested against intrepid yet now...
[12:34] <joh> norsetto: *no
[12:34] <\sh> fireflier-client-kde doesn't depend on fireflier-server neither recommends it
[12:35] <norsetto> joh: I'm getting few warnings (unused variables, implicit declarations) and a couple of fatal errors
[12:35] <wgrant> \sh: Why should a client need a server?
[12:35] <norsetto> joh: alarm.c:1858: error: expected ')' before ';' token
[12:36] <joh> norsetto: I'll look into it. Probably a missing header.
[12:36] <\sh> wgrant, it should recommend it actually :)
[12:36] <\sh> or suggests
[12:36] <joh> norsetto: Could you pastebin the whole output please?
[12:36] <norsetto> joh: yes
[12:36] <\sh> wgrant, I just thought it's a stupid frontend for iptables ;)
[12:37] <wgrant> \sh: If it is client-server one might conceivably want the client without the server.
[12:37] <norsetto> joh: for the fatal error is just that and alarm.c:1858: error: too few arguments to function 'g_timeout_add_seconds'
[12:37] <\sh> wgrant, yes..but it should actually point someone to "hey, there is actually a server, and this tool does not use iptables only" ;)
[12:38] <wgrant> \sh: .*client.* matches.
[12:38] <joh> norsetto: That's wierd, which version of glib?
[12:40] <joh> Alright, alarm-clock-applet source package uploaded to revu
[12:41] <norsetto> joh: the one currently in intrepid, in my build log is libglib2.0-0 2.16.3-1
[12:42] <joh> norsetto: They wouldn't change API from 2.14 to 2.16 though. How can I test this out myself without upgrading my entire system? pbuilder?
[12:42] <\sh> ah damnit..I'll hack manually my iptables...so I know it works out of the box ;)
[12:42] <norsetto> joh: yes
[12:43] <joh> \sh: If you're looking for a frontend to iptables, shorewall is pretty nice.
[12:44]  * norsetto -> lunch
[12:44] <jdavies> norsetto: bon appetit
[12:45] <broonie> stgraber: Is there any great reason why pastebinit isn't in Debian?
[12:47] <stgraber> broonie: the debian packager not having uploaded it yet :)
[12:48] <stgraber> broonie: David Paleino is supposed to do it (last I spoke with him)
[12:48] <broonie> stgraber: Ah. I've got someone else (Rolf Leggewie) wanting me to sponsor an upload of it just now.
[12:48] <stgraber> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425226
[12:49] <stgraber> that bug is almost one year old :)
[12:49] <broonie> And no activity.
[12:50] <broonie> Plus the initial ITP is malformed.
[12:50] <broonie> OK, thanks.
[12:51] <stgraber> np
[12:52] <joh> How exactly do I create an intrepid chroot with pbuilder? I tried upgrading my hardy build with DIST=intrepid sudo pbuilder update --override-config --othermirror "deb http://no.archive.ubuntu.com/ubuntu/ intrepid main" but there are package conflicts...
[12:53] <stgraber> joh: sudo pbuilder --distribution intrepid create
[12:53] <joh> stgraber: Ok, thanks
[12:54] <joh> sudo pbuilder --create --distribution intrepid: E: No such script: /usr/share/debootstrap/scripts/intrepid
[13:02] <jw2328_> joh: do you have hardy-backports enabled>
[13:03] <joh> jw2328_: no?
[13:04] <james_w> you need it so that the updated debootstrap that knows how to create intrepid can be installed.
[13:05] <joh> Ok, I'll try that then
[13:10] <slytherin> joh: upgrade is not working due to a bug. And create is not working due to another bug. :-P
[13:11] <joh> slytherin: Seems to be working now though :P
[13:11] <joh> Or not...
[13:11] <slytherin> joh: What is working? create or upgrade?
[13:11] <jcfp> until libc6 fails to install...
[13:12] <joh> slytherin: create, but: W: http://archive.ubuntu.com/ubuntu/dists/intrepid/main/binary-amd64/Packages.bz2 was corrupt
[13:13] <joh> W: Failure trying to run: chroot /var/cache/pbuilder/build/13869/. mount -t proc proc /proc
[13:13] <slytherin> joh: please tell me once you are finished with the create process. Last time Itried it didn't work.
[13:13] <joh> slytherin: It didn't work here either. pbuilder: debootstrap failed
[13:14] <mok0> ls
[13:14] <mok0> focus error, sorry
[13:14] <joh> Could someone please review http://revu.ubuntuwire.com/details.py?package=alarm-clock-applet ?
[13:17] <mok0> joh: collapse your changelog entry into just one
[13:18] <joh> mok0: Ok
[13:19] <mok0> joh: in rules, remove the sample comment at the top
[13:20] <joh> mok0: The entire comment?
[13:20] <mok0> joh: and remove the debhelper calls that have been commented out and that you're not using
[13:20] <mok0> joh: yes
[13:20] <mok0> joh: that's the custom
[13:20] <mok0> joh: get rid of all not needed fluff
[13:21] <mok0> :)
[13:21] <joh> Done :-)
[13:22] <mok0> joh: also, the #ifeq ... stuff, it seems you always want to compile w/o optimization
[13:22] <joh> mok0: Yeah, for debugging purposes actually...
[13:23] <joh> mok0: Is that a bad idea?
[13:23] <mok0> joh: if someone else is ever to take a look at the package, s/he will not know why that is still there, if it is commented out for debugging, or what. So it's best to remove it
[13:24] <joh> mok0: I meant -O0 was for debugging purposes, not the commented out block :-)
[13:24] <mok0> joh: in fact, it's just boilerplate left over from the template
[13:24] <joh> *nod*
[13:24] <mok0> joh: ah!
[13:24] <mok0> joh: well, then activate it :-)
[13:25] <joh> -O0 makes gdb backtraces more sensible though - better bug reports :P
[13:26] <mok0> joh: in .pod file, spelling mistake: "appelt"
[13:26] <joh> Whups :P
[13:27] <mok0> joh: also, avoid "speech" style: It's -> It is
[13:27] <joh> Alright
[13:27] <slytherin> Do you have any policy about 'machine interpretable copyright'?
[13:27] <mok0> joh: same in control
[13:28] <joh> mok0: Ok, fixed
[13:28] <mok0> joh: that's all at the moment... nice work!
[13:29] <joh> mok0: Great, thanks for your help!
[13:29] <mok0> joh: sorry, I don't have time to build and test the application, I need to go soon
[13:29] <joh> mok0: No problem, when/if you have time let me know if it works or not ;-)
[13:29] <joh> Changes uploaded.
[13:30] <joh> Too bad I'm unable to test it in intrepid though.
[13:30] <mok0> joh: yeah ii is not really ready yet
[13:31] <joh> mok0: Yeah, but norsetto reported he had trouble building it in ii...
[13:31] <mok0> It's in a state of flux at the moment... I am sure it will stabilize in a few weeks
[13:32] <joh> Alright :-)
[13:32] <mok0> New packages from Debian unstable are streaming in
[13:34] <emgent> heya
[13:35] <mok0> norsetto: ping
[13:36] <mok0> wgrant: ping
[13:36] <wgrant> mok0: Morning.
[13:37] <mok0> wgrant: I need a pair of eyes to look at my split-out package for the GLw libraries
[13:37] <wgrant> Oh dear.
[13:37] <mok0> wgrant: are you available?
[13:37] <wgrant> I guess so, though my library packaging knowledge isn't great.
[13:38] <mok0> wgrant: I will post a debdiff to Debian's mesa package, hang on
[13:38] <wgrant> mok0: You need to split the source...
[13:39] <Hobbsee> oh no, jono's here.
[13:39] <Hobbsee> everyone behave.
[13:39] <mok0> wgrant: I did
[13:39] <mok0> wgrant: but I need to know if I did it correctly :-)
[13:40] <jono> hey
[13:41] <mok0> wgrant: Bug #227712
[13:48] <mok0> wgrant: It is only modifications to the packaging, not the building of the libraries
[13:50]  * mok0 thinks there should be a XS-Original-Source: field to tell the merging system that this is a source package splitoff
[14:45] <norsetto> mok0: pong
[14:46] <joh> norsetto: The reason alarm-clock-applet didn't compile was actually a bug in the source. Fixed now :-)
[14:46] <norsetto> joh: cool
[14:55] <ramvi> ﻿I've made a deb using checkinstall. It works great, but when I add it to my repository apt-get returns: E: Problem parsing dependency Depends \ E: Error occurred while processing eeepc-wlan (NewVersion1) \ E: Problem with MergeList /var/lib/apt/lists/... / E: The package lists or status file could not be parsed or opened.
[14:55] <ramvi> What am I doing wrong?
[14:55]  * Hobbsee shrugs
[14:55] <Hobbsee> checkinstall isn't supported here, sorry.
[14:55] <Hobbsee> checkinstall often doesn't work, and is known to produce strange output.
[14:56] <ramvi> Ok, thanks
[14:56] <wgrant> And is completely offtopic for here.
[14:57] <joaopinto> and you should learn regular packaging instead
[15:00] <ramvi> The thing is: I've read the packaging guide about 10 times now. Using debhelper, I don't understand why I don't get a deb after running sudo pbuilder build ../*.dsc
[15:00] <ramvi> I get changes, diff.gz, dsc, build, but no deb
[15:00] <Hobbsee> ramvi: probably because you're not looking in /var/cache/pbuilder/result, or wherever you've specified it to be?
[15:01] <ramvi> Haha, that should be in the docs some where
[15:01] <ramvi> Thanks! Plenty of debs :p
[15:02] <Hobbsee> ....
[15:02] <Hobbsee> ramvi: try man pbuilder
[15:02] <Hobbsee> ramvi: scroll down to the section where it says '--buildresult'
[15:02] <Hobbsee> ramvi: see the sections in bold, in those couple of paragraphs.
[15:02] <Hobbsee> !pbuilder
[15:03] <ramvi> thanks
[15:03] <ramvi> Soon I'm a motu
[15:04] <joaopinto> just make sure you read the mans first :P
[15:08] <joh> norsetto: Let me know if you get the time to try building alarm-clock-applet btw.
[15:08] <ramvi> I'm building a kernel module for the Eeepc, but sudo pbuilder build ../*.dsc returns Makefile.inc:66: *** /lib/modules/2.6.24-16-generic/build is missing, please set KERNELPATH.  Stop.
[15:10] <jdavies> ramvi: have you st KERNELPATH?
[15:11] <ramvi> The default seems good: /lib/modules/$(shell uname -r)/build
[15:11] <ramvi> But I guess it isn't as I get that message
[15:12] <bddebian> Heya gang
[15:12] <Iulian> Hi bddebian
[15:12] <bddebian> Hello Iulian
[15:15] <wgrant> ramvi: You are actually build-depending on the requisite packages, right...?
[15:18] <ramvi> wgrant: didn't think there were any dependencies. Other then the kernel maybe.. Should I depent on linux*-generic?
[15:23] <wgrant> ramvi: If you need a part of it to build, you probably do want it installed, yes.
[15:23] <ramvi> wgrant: linux-source. That's it?
[15:24] <wgrant> ramvi: Check what other kernel module packages do.
[15:26] <ramvi> Thanks! I'm trying with this now:
[15:26] <ramvi> Build-Depends: debhelper (>= 5), bzip2, linux-source, linux-generic, linux-headers-generic, linux-image-generic, linux-restricted-modules-generic, linux-restricted-modules-common
[15:27] <wgrant> ramvi: Please look at other kernel module packages so you can do it properly.
[15:28] <ramvi> OK, please tell me one to check out
[15:28] <wgrant> I'm not quite sure. virtualbox-ose-modules, perhaps.
[15:28] <ramvi> Thanks
[15:42] <ramvi> Oh my, this is too hard. Can someone five minutes out of their day and make a deb of http://snapshots.madwifi.org/special/madwifi-nr-r3366+ar5007.tar.gz for all the Asus Eee users out there? Please pretty please
[15:43] <joh> ramvi: Did you read the packaging howto on the wiki?
[15:43] <ramvi> Yes. Several times
[15:43] <gnomefreak> did you try the debian dir from the stable one in the repos?
[15:44] <gnomefreak> and adapt it that way might give you a good starting point atleast
[15:44] <ramvi> gnomefreak: What do you mean?
[15:44]  * gnomefreak not saying its the best way to do it but see if it works
[15:45] <gnomefreak> ramvi: we have madwifi in archives afaik grab the source and use it to help with building it
[15:46] <wgrant> gnomefreak: Not in any separate source...
[15:46] <ramvi> gnomefreak: It's part of linux-restricted-modules
[15:47] <gnomefreak> cant copy the top level dir over to new source and fix as needed
[15:47] <gnomefreak> oh
[15:47] <gnomefreak> thats gonna be a beast to do if you havent done much packaging from new package
[15:48] <ramvi> or you could help me? ;)
[15:48] <gnomefreak> are repos dead?
[15:49] <gnomefreak> ramvi: not with that i cant thats above my head, as in ive never done anything kernel related
[15:49] <gnomefreak> maybe its just smart that died while fetching
[15:50] <ramvi> oh, ok :)
[15:50] <broonie> ramvi: https://help.ubuntu.com/community/EeePC FWIW
[15:51] <jdong> ramvi: I had such a .deb that compiles-on-boot the madwifi module; currently I only have the packaging for the regular madwifing-trunk but it would work with a svn URL to the ar5007 branch too
[15:51] <ramvi> broonie: Most of that is from my wiki :) ubuntu-eee.tuxfamily.org
[15:51]  * jdong looks at where he put it
[15:51] <ramvi> jdong: what does that mean? Sound good
[15:52] <jdong> ramvi: install the deb, it compiles the module. Every boot, it checks via a bootscript if the module is loadable. If not, it rebuilds it.
[15:52] <ramvi> Wow, great!
[15:54] <jdong> ramvi: source package tarballed here http://jdong.mit.edu/~jdong/macbook/crackwifi.tar.gz
[15:54] <jdong> ramvi: running debuild checks it out from svn
[15:55] <ramvi> jdong: love you
[15:55] <jdong> ramvi: see debian/rules to customize the rule that grabs madwifi... the package collects ./madwifi so you can get it from a tarball too
[15:55] <jdong> ramvi: a bit rough around the edges but should be a very good starting position.
[15:55] <jdong> as a bonus, it depends on the kernel headers so you never end up in a case where after an upgrade you can't build the module
[15:56] <jdong> (all MOTU REVUers should probably look far away from that package....)
[15:56] <ramvi> hehe, thanks!
[15:56] <persia> jdong: You didn't put it in REVU did you?
[15:56] <jdong> or use it as an example for how NOT to do an Ubuntu package ;-)
[15:56] <jdong> persia: no :)
[15:56] <jdong> persia: I wouldn't torment you guys THAT much when it's not april 1st
[15:56] <Hobbsee> jdong: and somehow, you got upload rights...
[15:56]  * persia breathes again.  The automatix upload was enough for at least two releases...
[15:56] <jdong> Hobbsee: it was a personal package, never meant to see the light of day ;-)
[15:57] <ramvi> Just did though
[16:04] <bobbo> Is anyone around to sponsor a debdiff for me?
[16:10] <cbx33> hey guys
[16:10] <cbx33> https://bugs.edge.launchpad.net/ubuntu/+source/kdenlive/+bug/223260
[16:11] <cbx33> do those backtraces make sence to any one??
[17:06] <taishi28012> quit
[17:39] <ScottK> jdong: I'm thinking we need to add a rule in backports about transitional packages.  We're dropping a bunch of them Hardy -> Intrepid and to backport across that boundary would really suck on upgrades.
[18:06] <jdong> ScottK: (brain offline) you mean to {reject, prefer source-change to hardy-like convention} backports that involve a package transition?
[18:10] <persia> jdong: did you mean "intrepid-like" convention?
[18:15]  * persia excitedly points at https://lists.ubuntu.com/archives/ubuntu-motu/2008-May/003776.html and encourages people to brainstorm
[18:16] <persia> Does anyone know the status of the various "click-to-install" solutions?  Either third-party or core repository?
[18:17] <laga> apt-url can point to packages available from sources.list AFAIK
[18:17] <laga> "is there some way we can help you with your own deb, stuff that makes
[18:17] <laga> things easier for you?
[18:17] <laga> "
[18:18] <laga> for the love of god - open source the damn thing or make it suck less.
[18:18] <persia> Can Adobe craft a special link on their page that points at our flashplugin-nonfree?
[18:18] <laga> persia: yes
[18:18] <laga> persia: http://www.mythbuntu.org/existing-ubuntu
[18:18] <persia> laga: If you understand how, would you mind explaining it to Sebastian?
[18:18] <laga> we do that for mythbuntu
[18:19] <laga> persia: i'm not subscribed to ubuntu-motu, sorry.
[18:19] <laga> apt:mythbuntu-desktop?section=universe <- but it looks straight forward
[18:20] <persia> laga: Well, you could send a reply there, and it would likely get approved in the moderation queue...
[18:21] <laga> alright.
[18:22] <persia> laga: Thanks.  I thought it was possible, but really don't understand the mechanics.  As much as I'm not a fan of non-free, it might help resolve part of the whole "Cannot install flash" mess for quite a few people.
[18:22] <laga> interesting. it doesn't work in kubuntu in firefox for me. might just be a fluke, though
[18:40] <laga> done
[18:48] <persia> laga: Thanks a lot.
[18:57] <xander21c> Hello :D
[18:59] <xander21c> i traying to do a merge i got all the tools but how do i choose a package?
[19:01] <persia> xander21c: You're typically encouraged to merge packages for which you've previously applied the patch, and so are responsible for the deviation.
[19:01] <persia> If you have listed with your name on merges.ubuntu.com, you can look at others.
[19:02] <persia> First, check to make sure there's no comment about it on dad.dunnewind.net, and no merge bug in launchpad.
[19:02] <persia> Those conditions satisfied, it's considered nice to highlight the last uploader and tell them you are planning a merge, to avoid duplicated work.
[19:02] <persia> Many people are busy with one thing or another, and would be happy to have your assistance with their merges.
[19:18] <xander21c> persia for example  pidgin-libnotify has no comment in DaD so i email to the last uploader before merge
[19:19] <persia> xander21c: Right.  This might take a bit.  Would you like something else to work on whilst you wait?
[19:21] <xander21c> actually yes, i am really newbie on this, so i hope my questions are not annoying
[19:23] <persia> Not annoying at all.  Thanks for being intersted in helping.  It's merge season, so there's lots of talk about merges, but there's always plenty else to do as well.
[19:23] <ScottK> jdong: I mean if there are transitional packages that were dropped in Hardy, don't backport past Hardy our you end up with a mess.
[19:25] <persia> xander21c: Two classes of stuff that might be good for someone starting would be package updates, or bugfixes.  For updates see https://wiki.ubuntu.com/PackagingGuide/Howtos/PackageUpdate and http://qa.ubuntuwire.com/uehs/
[19:25] <persia> xander21c: For bugfixes see https://bugs.launchpad.net/ubuntu/+bugs and https;//wiki.ubuntu.com/MOTU/Contributing
[19:27] <mok0__> I need a fresh pair of eyes to take a look at my mesa package split, bug 227712
[19:30] <xander21c> ok :D
[19:31] <xander21c> persia: will be back after careful reading
[19:35] <mok0_> i'm on the train... just went under a tunnel and lost connection :-)
[19:57] <norsetto> mok0: about bug 227712, I'm not very clear of what you want to do. Are you using the mesa tarball to create a new source package and two new binary packages?
[20:19] <RoAkSoAx> hi all.. i need some help here.. why a package... when trying to build the source will show this:
[20:19] <RoAkSoAx>  fakeroot debian/rules clean
[20:19] <RoAkSoAx> debian/rules:10: *** target file `clean' has both : and :: entries.  Stop.
[20:19] <RoAkSoAx> dpkg-buildpackage: failure: fakeroot debian/rules clean gave error exit status 2
[20:34] <pochu> RoAkSoAx: how's the line containing 'clean'?
[20:35] <RoAkSoAx> pochu, i figured out... the package in new debian version changed to CDBS so i removed the hole debian/rules and just left include /usr/share/cdbs/1/rules/debhelper.mk
[20:35] <RoAkSoAx> include /usr/share/cdbs/1/class/autotools.mk
[20:35] <RoAkSoAx>  and the source build without any problems
[20:36] <pochu> alright
[20:37] <RoAkSoAx> pochu, but now i got an error when building the binary
[20:38] <pochu> pastebin it :)
[20:39] <RoAkSoAx> pochu, ok but first, i'm working with "atanks" (trying to merge it)
[20:39] <RoAkSoAx> MoM showed me conflicts in:
[20:39] <RoAkSoAx>   C* debian/atanks.desktop
[20:39] <RoAkSoAx>   C  debian/atanks.install
[20:39] <RoAkSoAx>   C  debian/rules
[20:39] <RoAkSoAx> atanks.desktop easy to fix aswell as atanks.install... but before checking out debian/rules i checked the changelod
[20:41] <RoAkSoAx> pochu, so changelog is this one: http://pastebin.ubuntu.com/10790/
[20:42] <devfil_> RoAkSoAx: http://bugs.edge.launchpad.net/ubuntu/+source/atanks/+bug/227416
[20:43] <RoAkSoAx> i can see that now... well that bug already answered my question cuz i was thinking it was a sync.. that bug wasn't there yesterday... thanks devfil_
[20:44] <devfil_> RoAkSoAx: I did it yesterday, I didn't know that you wanted to work at the package... sorry
[20:44] <pochu> hey devfil_!
[20:45] <RoAkSoAx> devfil_, nah it is ok, i'm just learning =)
[20:45] <devfil_> hi pochu :)
[20:45] <devfil_> RoAkSoAx: I'm learning  too
[20:45] <RoAkSoAx> devfil_, and there are lots of packages to work with =)
[20:48] <devfil_> pochu: how are you?
[20:52] <Arby> working on a merge and the newer Debian version has older Build-Depends versions than the current ubuntu version, which should I use?
[20:52] <Arby> this is the diff http://paste.ubuntu.com/10793/
[20:53] <vorian> the new version
[20:53] <RoAkSoAx> Arby, and change standards-version to the newer one
[20:54] <Arby> vorian: the newer package or the newer build-depends
[20:55] <vorian> the newer standards version
[20:56] <vorian> and versions in general in this kde package
[20:56] <Arby> standards version I knew about, it was the build depends that had me confused
[20:56] <geser> Arby: is it documented why the versioned Build-Depends are higher?
[20:57] <geser> in debian/changelog
[20:57] <Arby> not that I've found yet
[20:57] <Arby> looking back
[20:58] <Arby> no, nothing in debian changelog
[20:58] <Arby> I'll try the newer build depends and see if it builds
[21:01] <wasabi> Any policy information common for packages that provide software that should run as a particular user?
[21:02] <wasabi> As in, how should you prompt the user for the account to use? Debconf?
[21:02] <wasabi> Should you offer to create a new system user if one does not exist? Etc.
[21:02] <RoAkSoAx> when doing a merge, whne we have this fields Vcs-Svn: and Vcs-Browser:, in debian/control, should we keep them in ubuntu?
[21:04] <geser> RoAkSoAx: yes, no need to remove them (and adding some extra diff for nothing)
[21:04] <james_w> geser: I disagree
[21:04] <RoAkSoAx> geser, what about the uploaders field?
[21:04] <geser> RoAkSoAx: the same, keep it
[21:04] <RoAkSoAx> ok
[21:04] <geser> james_w: why?
[21:04] <RoAkSoAx> thnks
[21:04] <james_w> if it's a merge then the repositories they point to won't contain the code in the distro, and so could cause confusion.
[21:05] <james_w> if a branch of the vcs is not used for Ubuntu then I would advocate deleting the headers.
[21:05] <RoAkSoAx> by the way, i'm trying to merge alsa-tools, noone working with that?
[21:06] <RoAkSoAx> james_w, so these are the ones i was asking about:
[21:06] <RoAkSoAx> Vcs-Svn: svn://svn.debian.org/pkg-alsa/trunk/alsa-tools
[21:06] <RoAkSoAx> Vcs-Browser: http://svn.debian.org/wsvn/pkg-alsa/trunk/alsa-tools/
[21:06] <ScottK> james_w: OTOH, if you're trying to feed fixes back to Debian, it's a useful bit of info.
[21:06] <RoAkSoAx> and: Uploaders: Jordi Mallach <jordi@debian.org>, Mikael Magnusson <mikma@users.sourceforge.net>, Elimar Riesebieter <riesebie@lxtec.de>
[21:06] <ScottK> james_w: We aim for a minimal diff with Debian, so there's no need to remove either.
[21:06] <james_w> ScottK: true, but an "Original-" prefix would allow that without causing the problems wouldn't it?
[21:07] <ScottK> james_w: OK, but then what about the packages we don't touch?
[21:07] <ScottK> The decision to modify maintainer we made after a poll of Debian Developers and required some time to get proper tool support for.
[21:08] <ScottK> I don't see those fields adding any actual harm.
[21:08] <james_w> ScottK: for the packages that we don't touch the fields point to the source that we have in Ubuntu, so I don't see a problem there.
[21:08] <ScottK> james_w: I'd see it as more needless diff.  Also more chance of a merge conflict needing more manual intervention with attended risk of messed up merges.
[21:09] <ScottK> Up until we need to do a security update and then they don't.
[21:09] <ScottK> At that point we really need to do the minimal change.
[21:09] <james_w> these headers aren't great anyway, so I doubt anyone really relies on them, but I don't think we should have bad information there.
[21:10] <ScottK> james_w: It's not bad information.  It's a pointer to some revision history.
[21:10] <ScottK> The canonical source for the package is still the source package.
[21:10] <james_w> yes, but not the revision history that Ubuntu has.
[21:11] <ScottK> I'd describe it as a portion of the revision history that Ubuntu has.
[21:11] <james_w> I'm not disagreeing with your other arguments, and I don't think this is the best place to discuss it.
[21:11] <ScottK> For a package that's basically forked, I can see removing them.  For a temporary divergence, I don't see the need.
[21:12] <ScottK> OK.
[21:12] <james_w> If I want to do something about it I will bring it up in a better forum.
[21:12] <ScottK> OK.  In the meantime, there's no policy to remove it, so people just learning shouldn't be told to remove it.
[21:12] <ScottK> james_w: What would be a better forum?
[21:12] <james_w> ScottK: the mailing list, or a MOTU meeting perhaps.
[21:13] <ScottK> MOTU meeting for a decision on a policy change, certainly.
[21:13] <james_w> somewhere where we can get the input of other people, rather than just those that happen to be reading IRC now.
[21:13] <RoAkSoAx> ok so should i remove those fileds or not?
[21:14] <james_w> RoAkSoAx: no, keep them, as that is the current status-quo.
[21:14] <RoAkSoAx> james_w, ok thanks =)
[21:15] <jimcooncat> hi, motu! I want to start a new project (small and simple at first). Is there anyplace I need to register the product's name with ubuntu or debian to reserve it?
[21:17] <james_w> jimcooncat: I don't think that's possible.
[21:17] <jimcooncat> Or do people just name their projects by checking google to see if anyone else has named theirs the same?
[21:18] <james_w> registering the project on launchpad, sourceforge or similar places would perhaps discourage people from picking the same name.
[21:18] <ScottK> jimcooncat: Filing a Debian ITP bug and an Ubuntu needs-packaging bug would let people know about it, but there is no actual reservation system.
[21:18] <jimcooncat> thanks folks. you see any problem with a project called "loda"?
[21:20] <jdavies> jimcooncat: google doesn't bring much up
[21:28] <pochu> devfil_: I'm generally fine, thanks :) starting with sync and merges for Intrepid, and busy with uni. what about you?
[21:28] <sebner> pochu: damn you :P
[21:29] <devfil_> pochu: I'm fine too, I know you are also helping emesene project, this is good
[21:32] <slytherin> james_w: Vcs-Svn etc specify the VCS for packaging, right?
[21:32] <RoAkSoAx> hey guys... what about this warnings when building the source of alsa-tools: http://pastebin.ubuntu.com/10805/
[21:33] <james_w> slytherin: yes.
[21:33] <james_w> RoAkSoAx: ah yeah, crimsun is probably the most likely to want to merge alsa related stuff, so asking him whether he is working on it would be best.
[21:34] <RoAkSoAx> ok thanks james_w =)
[21:34] <slytherin> james_w: so those are going to be refered only be developers then why remove them?
[21:34] <james_w> because developers are people too?
[21:34] <james_w> RoAkSoAx: those warnings are probably ok.
[21:36] <RoAkSoAx> james_w, ok so i'll build the binary, create the debdiff and talk to crimsun =)
[21:36] <james_w> RoAkSoAx: great.
[21:41] <RoAkSoAx> whois ebner
[21:41] <sebner> RoAkSoAx: hmm?
[21:42] <RoAkSoAx> sebner, :) you the llast one who merged athcool... can i give it a try or you working on it?
[21:43] <sebner> RoAkSoAx: hmm. You could but I didn't touch it yet since a dependency isn't ready in intrepid yet. IIRC it's a sync though
[21:47] <cbx33> hey guys
[21:48] <cbx33> if I got this cc -shared -o ../libmltavformat.so factory.o producer_avformat.o consumer_avformat.o filter_avcolour_space.o filter_avresample.o filter_avdeinterlace.o -L/lib -lavformat -lavcodec -ltheora -lavutil -logg   -L../../framework -lavformat -lavcodec -lavutil -lavdevice  -lmlt -lswscale
[21:48] <cbx33> /usr/bin/ld: cannot find -lavdevice
[21:48] <cbx33> what would be the probable cause
[21:48] <cbx33> ??
[21:48] <wasabi> Um. How do I exclude a file from conf file management? I'd like it to never replace with the built in version.
[21:48] <RoAkSoAx> sebner, so it would be better yo wait until the pciutils(>= 1:2.2.10) package is in the repos to sync?
[21:49] <sebner> RoAkSoAx: totally right :)
[21:49] <RoAkSoAx> instead of doing a merge
[21:49] <sebner> RoAkSoAx: we *want* to reduce the delta/merges and increase the syncs ;)
[21:50] <RoAkSoAx> sebner, ok cool then... thanks for help =)
[21:50] <sebner> RoAkSoAx: but if you want you can claim it in case you will process the sync request then
[21:51] <james_w> cbx33: hi. You need to Build-Depend on libavdevice-dev
[21:52] <cbx33> james_w: there is a script I'm using to build kdenlive
[21:52] <james_w> however it appears that package is built by ffmpeg-free, which is not in Ubuntu yet.
[21:52] <cbx33> and it pulls in libavcodec fine
[21:52] <cbx33> and libavdevice is built
[21:52] <cbx33> but it's not pulling it in
[21:52] <sebner> james_w: though it seems that it will be there in a few days
[21:52] <cbx33> I'm just trying to get a usable kdenlive
[21:52] <james_w> cbx33: you're building libavdevice at the moment?
[21:53] <james_w> sorry, at the same time?
[21:53] <cbx33> no that's built
[21:53] <cbx33> yes
[21:53] <cbx33> the script builds that first
[21:53] <james_w> is it installed first?
[21:53] <cbx33> and that's all done
[21:53] <cbx33> yes
[21:53] <cbx33> now it's trying to build mlt
[21:53] <james_w> so you have /usr/lib/libavdevice.so?
[21:53] <cbx33> no it's in a seperate build dir
[21:54] <cbx33> and the script is set to use that
[21:54] <cbx33> apparently
[21:54] <cbx33> so if I add
[21:54] <james_w> ../../framework/ ?
[21:54] <cbx33> no
[21:54] <cbx33> DEST_DIR/lib/
[21:55] <cbx33> so it's looking in the wrong place
[21:55] <james_w> ah, there is "-L/lib"
[21:55] <cbx33> yes
[21:55] <cbx33> but it's still failing
[21:55] <james_w> which is odd, and seems to indicate that it is trying to do it, but $DEST_DIR is empty when this is expanded
[21:55] <cbx33> ahh ok
[21:56] <cbx33> hmmm
[21:56] <cbx33> maybe it's just not putting it in anywhere
[21:56] <james_w> can you pastebin the script/makefile whatever that does this so I can see it?
[21:56] <james_w> or a pointer to where you got it from?
[21:56] <cbx33> http://pastebin.ca/1011075
[21:57] <cbx33> i added  -I$DEST_DIR/include/  to line 287
[21:59] <james_w> cd ../mlt++; ./configure --prefix=$DEST_DIR --enable-debug
[21:59] <cbx33> and that fixed one bug
[21:59] <james_w> lines 323/324
[21:59] <cbx33> ignore mlt++
[21:59] <cbx33> we're still stuck at the one before
[21:59] <cbx33> :)
[21:59] <james_w> ah, ok.
[21:59] <cbx33> hehe
[21:59] <cbx33> sorry
[22:00] <cbx33> see....where does it tell it to use DEST_DIR
[22:00] <cbx33> for the -L
[22:00] <cbx33> it doesn't
[22:00] <cbx33> does it
[22:00] <Arby> on trying to build a binary I get this error, what does it mean?
[22:00] <Arby> Trying patch debian/patches/kubuntu_01_fix_missing_output.diff at level 1 ... 0 ... 2 ... failure.
[22:00] <Arby> make: *** [debian/stamp-patched] Error 1
[22:00] <james_w> cbx33: --prefix=$DEST_DIR is probably supposed to do it.
[22:00] <Arby> apart from obviously the patch has failed
[22:00] <Arby> what might cause it?
[22:00] <cbx33> yeh
[22:00] <cbx33> james_w: ecept it isn't
[22:00] <cbx33> :p
[22:01] <james_w> Arby: it conflicts somehow with the new upstream code.
[22:01] <james_w> Arby: do you know what patch system is in use?
[22:01] <Arby> let me check
[22:02] <Arby> james_w: whatever cdbs uses (simple-patchsys?)
[22:02] <Arby> debian/rules has include /usr/share/cdbs/1/rules/simple-patchsys.mk
[22:03] <james_w> Arby: cool, in the unpacked sources try
[22:03] <james_w> cdbs-edit-patch kubuntu_01_fix_missing_output.diff
[22:03] <james_w> cbx33: I'm trying to find the upstream code.
[22:03] <cbx33> james_w: ok
[22:03] <cbx33> there is a downloader in there
[22:04] <james_w> cbx33: I've found it from that
[22:04] <james_w> the mlt configure script is handwritten, it's not autotools
[22:04] <cbx33> ouch really
[22:04] <cbx33> that explains it then
[22:06] <cbx33> james_w: it's really annoying me
[22:06] <cbx33> if only the ubuntu pckages had been tested
[22:06] <cbx33> :p
[22:06] <cbx33> :(
[22:06] <Arby> james_w: output of cdbs-edit-patch http://paste.ubuntu.com/10811/
[22:07] <Arby> looks like a problem with build-deps
[22:07] <james_w> cbx33: what subdir is it in when it fails.
[22:08] <Arby> should I follow through and try to answer the questions or is that likely to cause more problems
[22:08] <james_w> cbx33: also, can you pastebin your config.mak from the root of the mlt tree please?
[22:08] <james_w> Arby: it seems as if the patch has been applied upstream.
[22:08] <ScottK> sommer: php-clamavlib uploaded to Intrepid.  Thank you for your contribution to Ubuntu.
[22:08] <cbx33> james_w: it ends up in ~/source/kdenlive3
[22:08] <james_w> what you can do is answer "n"
[22:08] <cbx33> as that is what i put in for the source dir
[22:09] <sommer> ScottK: party! thank you
[22:09] <Arby> james_w: what is it that tells you that
[22:09] <Arby> oh I see it
[22:09] <Arby> nevermind
[22:09] <cbx33> james_w: http://pastebin.ca/1011094
[22:09] <james_w> Arby: and then if it asks to continue say yes, you can then check the .rej files to ensure that the code is applied, then "exit 1", and delete the patch
[22:10] <cbx33> james_w: brb
[22:10] <james_w> cbx33: there are several subdirs of mlt, in which is "factory.o producer_avformat.o consumer_avformat.o filter_avcolour_space.o filter_avresample.o filter_avdeinterlace.o" ?
[22:13] <Arby> james_w: output after continuing http://paste.ubuntu.com/10814/
[22:13] <Arby> where do .rej files live?
[22:15] <ajmitch> cbx33: hey
[22:16] <Arby> james_w: nevermind I think I figured it out
[22:16]  * Arby writes down 'read the changelog better'
[22:18] <james_w> Arby: heh, you on top of it now?
[22:19] <Arby> I think so, it had been applied upstream. just with a different name
[22:19] <Arby> I'll remove the kubuntu patch and try to rebuild
[22:19] <Arby> this may take some time
[22:19] <james_w> good plan
[22:21] <james_w> cbx33: http://mlt.svn.sourceforge.net/viewvc/mlt/trunk/mlt/src/modules/avformat/Makefile?view=markup is probably where the problem is.
[22:23] <cbx33> hey ajmitch
[22:23] <james_w> cbx33: or http://mlt.svn.sourceforge.net/viewvc/mlt/trunk/mlt/src/modules/avformat/configure?view=markup
[22:23] <cbx33> can we hack a fix?
[22:25] <james_w> probably, I can't see exactly what the problem is though.
[22:25] <Arby> progress, if a different error counts as progress
[22:25] <Arby>  /tmp/buildd/kdevelop-3.5.1/./configure: line 38683: syntax error: unexpected end of file
[22:26] <Arby> but the end of the configure file looks fine
[22:26] <james_w> Arby: has one of the patches got "autotools" or similar in the name?
[22:26] <cbx33> james_w: what about changing -L
[22:26] <james_w> it's probably a quote missing somewhere, or something like that.
[22:26] <cbx33> yeh
[22:26] <james_w> cbx33: that would be the best way.
[22:27] <Arby> james_w: the complete set of pathces is http://paste.ubuntu.com/10816/
[22:27] <Arby> *patches even
[22:28] <Arby> I did have to fix a conflict in the configure file, I really hope I didn't delete the wrong thing
[22:28] <james_w> Arby: 03_libtool_update.diff and 04_am_maintainer_mode.diff look a little suspect
[22:28] <james_w> Arby: that may well be it.
[22:28] <RoAkSoAx> what is the difference between debian/control and debian/control.stub ?
[22:28] <james_w> also, what is the update.sh file?
[22:29] <Arby> checking
[22:29] <james_w> RoAkSoAx: debian/control will normally be generated from the latter in that case.
[22:29] <RoAkSoAx> james_w, so should i drop .stub ?
[22:30] <Arby> james_w: it mentions autotools http://paste.ubuntu.com/10818/
[22:30] <james_w> RoAkSoAx: no, that's probably what you should be editing.
[22:30] <james_w> RoAkSoAx: check debian/rules, and look for mention of debian/control
[22:31] <RoAkSoAx> james_w, ok thanks
[22:31] <james_w> Arby: you could try running it, I'm not exactly sure what the purpose is.
[22:31] <RoAkSoAx> james_w, it only has: #!/usr/bin/make -f
[22:31] <RoAkSoAx> include /usr/share/cdd-dev/rules
[22:32] <james_w> Arby: I would also check that conflict you had in configure again.
[22:32]  * Arby crosses everything and hopes
[22:32] <RoAkSoAx> and debian/control is much more elaborated than debian/control.stub
[22:32] <Arby> ok
[22:32] <james_w> RoAkSoAx: yep, if you are changing the maintainer, or Build-Depends you should edit debian/control.stub for cdd packages.
[22:32] <james_w> RoAkSoAx: which package is it out of interest?
[22:32] <RoAkSoAx> ok thanks james_w
[22:32] <RoAkSoAx> =)
[22:35] <RoAkSoAx> finally alsa-tools finished building the binary...  but it showed many warnings..
[22:36] <james_w> RoAkSoAx: is it debian-edu you are working on?
[22:36] <RoAkSoAx> james_w, yes
[22:36] <james_w> (apart from alsa, obviously)
[22:36] <RoAkSoAx> james_w, yes that's the one
[22:37] <james_w> RoAkSoAx: it doesn't need merging
[22:37] <RoAkSoAx> james_w, so should i just report a sync bug?
[22:37] <james_w> it wasn't on my list of packages, as dholbach was the last uploader because I made a mistake.
[22:38] <james_w> RoAkSoAx: yes please.
[22:38] <james_w> the changelog says that the changes can be dropped, all the other changes were just necessary things for the upload.
[22:39] <RoAkSoAx> james_w, yeah i haven't got to that part yet, but thanks for the tip xD =)
[22:39] <RoAkSoAx> james_w, so like this: requestsync -s debian-edu intrepid 0.831
[22:40] <james_w> 0.824
[22:40] <james_w> you specify the base version, not the current Debian version.
[22:42] <RoAkSoAx> james_w, ok thanks, and what do i put in the Explanation of the sync, just that it needs to be synced?
[22:44] <james_w> you can say that the change was made to build against an updated cdd-dev. There is a separate sync bug for cdd-dev, and syncing will still ensure that a new enough version of cdd-dev will be used.
[22:45] <jcfp> Reviewers, please have a look at http://revu.tauware.de/details.py?package=sabnzbdplus
[22:45] <RoAkSoAx> james_w, ook so i'll put there: "the change was made to build against an updated cdd-dev. There is a separate sync bug for cdd-dev, and syncing will still ensure that a new enough version of cdd-dev will be used."
[22:45] <james_w> RoAkSoAx: that should be sufficient.
[22:45] <RoAkSoAx> thanks very much james_w
[22:46] <james_w> no problem, thanks for taking care of it.
[22:48] <tjaalton> a package in hardy universe is currently uninstallable (vdr-plugin-burn, a missing package and falsely named dependancies). AIUI it would need two SRU's to fix the situation; first get the missing package in, and then fix the broken package dependancies. is this doable? the current situation is not a regression because v-p-b was introduced in hardy, but annoys me like hell
[22:49] <tjaalton> motu-sru members ^^
[22:50] <RoAkSoAx> james_w, going back to alsa-tools... it showed lots of warnings while building the binaries.. but it build them successfully... any suggestion?
[22:50] <james_w> RoAkSoAx: what were the warnings?
[22:51] <james_w> RoAkSoAx: two suggestions. Firstly, look at the build logs for the current hardy package, you can see if there are warnings there.
[22:51] <james_w> Secondly, if you are building in Intrepid there are a bunch of new default CFLAGS that may be causing the issue.
[22:53] <RoAkSoAx> some where about some char variable that was deprecated
[22:54] <RoAkSoAx> other was related to ${misc:Depends}. where can i find the whole log?
[22:54] <james_w> http://launchpadlibrarian.net/12740476/buildlog_ubuntu-hardy-i386.alsa-tools_1.0.15-2ubuntu4_FULLYBUILT.txt.gz
[22:55] <james_w> that's the hardy i386 one
[22:55] <RoAkSoAx> i had these same warning: ../pixmaps/alsalogo.xpm:451: warning: deprecated conversion from string constant to 'char*'
[22:56] <the_belgain> hi there - is there any chance anyone can review a package which I uploaded to REVU a few months back but didn't make it in for hardy?  It's fuppes, at: http://revu.tauware.de/details.py?package=fuppes
[22:59] <cbx33> james_w: do I hard code the -L you think?
[22:59] <james_w> cbx33: that will probably work for you
[22:59] <james_w> but others may be interested in having it work properly
[23:00] <cbx33> yeh
[23:01] <cbx33> seems to have worked
[23:01] <RoAkSoAx> james_w, where can i find the buildlogs in my own pc?
[23:02] <james_w> RoAkSoAx: they're probably not stored
[23:03] <RoAkSoAx> james_w, oks so then how to compare?? i've seen some similar warnings in the i386 (but im using amd64)
[23:04] <james_w> RoAkSoAx: you can build again and redirect the build output to a file.
[23:04] <james_w> RoAkSoAx: you can grab an amd64 build log
[23:04] <RoAkSoAx> oh right lol haven't thought about it
[23:05] <RoAkSoAx> james_w, before re building it i have to delete the binaries created in /var/cache/pbuilder/result right?
[23:06] <RoAkSoAx> or they will be overwritten ?
[23:06] <james_w> RoAkSoAx: nope, they'll just be overwritten.
[23:09] <RoAkSoAx> ok so building againg
[23:10] <RoAkSoAx> james_w, ok so after comparing the buildlogs... if there are the same warnings it will be ok??? but if there are new warnings.. what should be done?
[23:10] <coppro> okay, I am going to try this question again?
[23:10] <james_w> RoAkSoAx: you should work out if they are serious.
[23:10] <coppro> If the upstream distribution doesn't include a SONAME, do I need to add one myself?
[23:11] <RoAkSoAx> james_w, so if needed, make patches and stuff like that?
[23:11] <james_w> RoAkSoAx: in one sense if it builds and runs then it is "ok". However, warnings are there for a reason, and can often point to real problems that will bite users later.
[23:11] <james_w> coppro: you mean Debian, or the upstream code released by the particular project?
[23:12] <coppro> james_w: I mean the upstream code. The default build for the library has no SONAME
[23:12] <RoAkSoAx> james_w, ok cool... and seems there is no build log for alsa-tools amd64
[23:12] <the_belgain> don't mean to pester, but just wanted to check whether this is the right place to ask to get a package reviewed for multiverse?
[23:13] <the_belgain> i've tried a few times but haven't had much luck...
[23:13] <coppro> this library has no Debian package
[23:14] <james_w> RoAkSoAx: on the left of https://edge.launchpad.net/ubuntu/hardy/+source/alsa-tools/1.0.15-2ubuntu4
[23:14] <james_w> coppro: ok, in most cases you want one, otherwise it is a headache
[23:14] <RoAkSoAx> thanks james_w =)
[23:15] <james_w> however if upstream doesn't use one, then it would often indicate they weren't going to care about their ABI, and so using a soname would also be a headache. Do you think that applies in this case?
[23:15] <coppro> I think so. They have a version number in the library anyway (kinda like libc6)
[23:15] <james_w> the_belgain: yes, it would be. However, asking for a review doesn't mean you are always going to get one, so don't take silence the wrong way.
[23:16] <james_w> coppro: why aren't they using a SONAME for that?
[23:16] <coppro> possibly because they are primarily Windows developers and don't know better?
[23:16] <coppro> I could always use that number as the SONAME
[23:17] <RoAkSoAx> james_w, as far as i can tell... there are the same warnings...
[23:17] <james_w> coppro: but will they change that number in the way that is required for a SONAME?
[23:18] <coppro> I believe so. I can ask
[23:18] <james_w> RoAkSoAx: it's probably ok. Just test the binaries well.
[23:18] <the_belgain> ok.  i appreciate that time is limited, it's just that it seems like there's a few packages like this one which a lot of people are asking about installing in the forums etc. and i'd like to get packages for but it seems like actually getting things reviewed and committed seems pretty hard to actually manage
[23:18] <coppro> or they may not :/
[23:18] <james_w> coppro: it's probably worth asking, at the very least you will get to gauge their understanding of the issues.
[23:19] <coppro> yeah
[23:19] <coppro> in the meanwhile, is there a great guide for packaging libraries? I'm trying to find as many places as I can, as everyone says library packaging is difficult.
[23:19] <james_w> the_belgain: yeah, it's unfortunate. Reviewing new packages is very time consuming, so it can be a slow process for contributors.
[23:20] <james_w> the_belgain: also, intrepid is only just open, and most people can't even set up a development environment for it yet. In a couple of weeks I hope things will start to flow a little more smoothly.
[23:21] <james_w> coppro: it's not necessarily difficult, but you have to be aware of the issues, and on top of the changes in the upstream code that could break the packaging.
[23:21] <Arby> james_w: you were right, there is some libtool strangeness occurring.
[23:21] <james_w> coppro: have you seen the Debian libarary packaging guide?
[23:21] <coppro> no, which is that?
[23:21] <Arby> the readme for the update.sh script says http://paste.ubuntu.com/10825/
[23:21] <the_belgain> do packages in REVU get updated for intrepid automatically (i.e. the distribution in the debian/control file etc) or does it need to be reuploaded?
[23:22] <Arby> so I've run the script, which didn't throw any errors
[23:22] <james_w> coppro: there's also https://wiki.ubuntu.com/MOTU/School/LibraryPackaging which is a fantastic introduction to the issues.
[23:22] <Arby> then attemted to rebuild
[23:22] <coppro> yeah, that's the one I was going to use
[23:23] <Arby> which fails with unexpected end of file immediately after configure: creating libtool
[23:23] <james_w> coppro: I'm trying to turn that in to real documentation at https://wiki.ubuntu.com/PackagingGuide/SharedLibraries , but I haven't had the time recently.
[23:23] <james_w> coppro: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
[23:23] <the_belgain> and is there anything to do process-wise to get an uploaded package reviewed (eg. does the [needs-packaging] launchpad bug need to be assigned the MOTU team, or do MOTUs check through packages in REVU periodically)?
[23:24] <james_w> the_belgain: it would need to be updated manuall.
[23:24] <james_w> the_belgain: I believe it is just done through REVU
[23:24] <the_belgain> ok, thanks
[23:26] <coppro> sorry, my computer just decided to randomly suspend itself
[23:29] <james_w> coppro: did you get my links
[23:29] <coppro> yeah
[23:29] <coppro> thanks
[23:31] <RoAkSoAx> james_w, is it ok to use a PPA to test the packages i build when merging??
[23:33] <james_w> RoAkSoAx: sure
[23:38] <RoAkSoAx> james_w, and to test it, should i create a VM, install hardy, upgrade to intrepid and test it?
[23:39] <james_w> mmm, do you have a VM solution that provides a sound card?
[23:39] <RoAkSoAx> james_w, i just have vmware installed
[23:39] <james_w> can that do that?
[23:40] <RoAkSoAx> i don't know, but i'll try