[00:16] <SoftwareExplorer> Will someone explain to me what DESTDIR in a makefile does?
[00:16] <persia> SoftwareExplorer: It's typically used to identify the location into which the software should be installed.
[00:17] <SoftwareExplorer> so if I make it so that when a person runs make install it usually copies a file to /usr/lib/gtk-2.0/modules/, were should it copy to ?
[00:18] <SoftwareExplorer> $(DESTDIR)/usr/lib/gtk-2.0/modules/librgba.so
[00:18] <SoftwareExplorer> ?
[00:19] <directhex> SoftwareExplorer, DESTDIR is useful to override the behaviour you've otherwise been encouraging. For example, if you compile with "--prefix=/usr", then things like pkg-config files will have that prefix burned in - but when building a package, you cannot touch /usr, so your package build would break
[00:19] <directhex> SoftwareExplorer, so you'd use "DESTDIR=debian/tmp make install" to make "make install" override into a different prefix
[00:19] <directhex> whilst still burning in data relating to --prefix=/usr
[00:21] <SoftwareExplorer> So, is DESTDIR to help you with where to put the file once it's compiled, or give you a temporary place to run gcc and build the file?
[00:24] <directhex> the former
[00:25] <directhex> DESTDIR is the place "make install" installs to
[00:25] <tsmithe> DESTDIR is the "DESTination DIRectory"
[00:27] <SoftwareExplorer> I put the makefile I'm working on at http://paste.ubuntu.com/375816/. Would you mind looking at it and telling me if I'm doing it right?
[00:29] <persia> SoftwareExplorer: Looks reasonable.  Does it work?
[00:29] <directhex> no, that's wrong
[00:29] <persia> Why?
[00:29] <directhex> you shouldn't force /usr
[00:29] <directhex> i.e. DESTDIR=/opt should go into /opt, not /opt/usr/
[00:29] <persia> Ah, that would be ${DESTDIR}/${PREFIX}/... though.
[00:30] <SoftwareExplorer> So how do I tell it that it should put it in /usr/lib/gtk-2.0/modules by default?
[00:31] <persia> Set PREFIX to usr
[00:32] <persia> Oh, and use PREFIX ?= so that it can be overridden by directhex's user who wants to install in /opt/
[00:35] <SoftwareExplorer> persia: How does the computer know that the program is in /opt ?  The main reason I'm trying to write a makefile is so that I can make a .deb out of a single .c file, and this is the first time I've tried to do a makefile.
[00:36] <persia> The user would run `DESTDIR=/opt PREFIX="" make install`
[00:39] <SoftwareExplorer> So that would override whatever I set it to in the makefile?
[00:47] <SoftwareExplorer> Ok, here's the new version of the makefile. http://paste.ubuntu.com/375827/  I'm not sure if I did the PREFIX part right.
[00:51] <persia> SoftwareExplorer: "PREFIX ?=usr/" and "${DESTDIR}/${PREFIX}/lib/gtk-2.0/modules/"
[00:52] <SoftwareExplorer> Ok, thanks so much for the help. That clears up a lot of confusion.
[00:53] <lexual> gpodder package in universe has bugs and is an older version, ppa has current version without bugs, how does one go about getting the packaged patched or updated?
[00:53] <lexual> https://bugs.launchpad.net/ubuntu/+source/gpodder/+bug/508886
[00:53] <persia> !update
[00:53] <persia> Darn!
[00:55] <persia> https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate
[00:56] <mr_steve> Question: If I want to fix a bug in a package - firefox-vimperator in this case - what's the procedure? Attach a debdiff to the bug report? Submit an updated package to REVU?
[00:58] <persia> mr_steve: Attach a debdiff to the bug report, and subscribe "ubuntu-universe-sponsors"
[00:58] <lexual> I'm not sure if I was clear, I know how to upgrade my packages to the latest version. I want to who to speak to get a newer version into the archive.
[00:59] <persia> lexual: File a bug against the package and attach the diff.gz file from the upgrade.
[01:00] <mr_steve> persia, thanks
[01:01] <lexual> persia: there is a bug already and it has links to *.dsc and ppa of updated package.
[01:01] <lexual> https://bugs.launchpad.net/ubuntu/+source/gpodder/+bug/508886
[01:03] <persia> lexual: Does that .dsc link to something that builds and solves the bug for lucid?
[01:05] <lexual> according to ppa person it does, give me a few minutes and I will test on my system.
[01:11] <lexual> https://launchpad.net/~thp/+archive/gpodder/+packages
[01:11] <lexual> persia: I have just installed ppa package and it solved the crash problem.
[01:12] <persia> OK.  Update the bug with a comment about that, and subscribe ubuntu-universe-sponsors
[01:14] <lexual> persia: done
[01:15] <persia> lexual: One of the developers will double-check, and either upload or explain if something else is needed.
[01:15] <persia> Thanks a lot for investgating that.
[01:15] <lexual> persia: great, thanks for your help.
[02:02] <paissad> lintian seems not to accept XSBC-Original-Maintainer .. in the control file ... neither in the .dsc file
[02:02] <paissad> should i consider that warning ?
[02:17] <persia> paissad: Um, Which lintian message do you get from that?
[02:18] <paissad> persia, W: pms-linux source: unknown-field-in-dsc original-maintainer
[02:18] <paissad> I: pms-linux: unknown-field-in-control original-maintainer
[02:19] <persia> Which lintian are you running?
[02:20] <paissad> persia, Lintian v2.3.2ubuntu1
[02:20] <paissad> http://pastebin.com/f3ac76ed3
[02:21] <persia> Ah, what *version* is your package?
[02:21] <paissad> pms-linux_1.20.392-1_all.deb
[02:22] <persia> OK.  I think that's an issue in lintian, but maybe not: specifically I suspect that lintian is checking the version number to determine if "Original-Maintainer" is a valid control file entry.
[02:22] <persia> Try again with 1.20.392-0ubuntu1 and see if you get the same result.
[02:23] <paissad> ok
[02:30] <paissad> persia, indeed, if i append 0ubuntu1 instead of 1, i have no warning ^^
[02:30] <persia> Right.  I think it's a bug, but I suspect that many people disagree with me.  I know why it's that way, and it's not important.
[02:31] <persia> So, basically, if you're preparing a package for Ubuntu, use Original-Maintainer, and if you're preparing a package for Debian, don't.
[02:31] <paissad> persia, i think that -1 or 0ubuntu1 should be both accepted
[02:32] <persia> Why?
[02:32] <persia> And Where?
[02:33] <paissad> persia, i just think that lintian should not return any warning because we choose to append -1 instead of -0ubuntu1 when we enter Original-Maintainer:
[02:33] <persia> Heh, neither do I :)
[02:34] <persia> But the reason it does that is that a new upload to Debian should have -1, and using Original-Maintainer in Debian is a bug.
[02:34] <paissad> ok
[02:34] <persia> And a new upload to Ubuntu should have -0ubuntu1, and not using Original-Maintainer in Ubuntu is a bug.
[02:35] <paissad> lol
[03:06] <tsmithe> persia, if you're still around, i'll probably upload the diff in around half an hour or so. this build is taking unusually long; i'm sure that in the end it'll be successful, but naturally, i don't want to waste your time.
[03:06] <persia> tsmithe: Thanks for your concern: I'm looking forward to the new shiny bits :)
[03:09] <tsmithe> cool. annoyingly, though, because i've not got around to getting pisa in a state that the debian python folk think is acceptable (and because they're so hostile), manuals are still only provided online, and the local ones are deleted, because i can't build the pdfs.
[03:09] <tsmithe> (pisa you can see at https://launchpad.net/~mscore-ubuntu/+archive/ppa/+sourcepub/893784/+listing-archive-extra)
[03:09] <tsmithe> however, that's immaterial, really. another cool development is that the 0.9.6 release includes another free soundfont :)
[03:10] <tsmithe> and it's a lot smaller than fluid
[03:11] <persia> tsmithe: You can't get pisa into Debian?
[03:11] <persia> Another soundfont?  Excellent!
[03:11] <persia> Is it separable, or only available with mscore installed?
[03:11] <tsmithe> i provide it as a separate binary package
[03:12] <persia> Lovely.
[03:12] <tsmithe> as for pisa.. well, when i tried to talk to the python team about it, they seemed fairly hostile. i can't remember what their objections were, but it was something to do with eggs.
[03:12] <hyperair> soundfont?
[03:12] <tsmithe> persia, in any case, they didn't have very good documentation
[03:12] <tsmithe> hyperair, yes?
[03:12] <hyperair> what's a soundfont? O_o
[03:13] <tsmithe> it's like a font, but with banks of sound samples, rather than glyphs
[03:13] <tsmithe> so you can use midi calls to reference those sounds, and make music
[03:14] <tsmithe> (think timidity/freepats etc?)
[03:14] <persia> Well, freepats is a particularly unfortunate example :)
[03:14] <tsmithe> yes, that's why i chose it :)
[03:15] <hyperair> ooh cool
[03:16] <tsmithe> hyperair, having a free soundfont was necessary to make musescore (a notation program that i maintain) worthwhile, but coincidentally it also allows more applications better sound. i'm glad now that we don't only have one 120mb one.
[03:17] <tsmithe> i still think we're not quite at the same stage that exists on windows, with a centralised midi server thingy, but i think we're getting there thanks to some gstreamer support and a nicer pulseaudio.
[03:19] <hyperair> 120MB huh. that's big.
[03:20] <persia> tsmithe: If you have any ideas to improve the gstreamer support, I'd like to hear about it.  The wildmidi integration feels like a bi of a hack, and lots of users complain about things that aren't quite bugs.
[03:21] <tsmithe> hyperair, it had lots of samples :) the new one has fewer (though i think it still provides the whole gm set)
[03:21] <tsmithe> persia, well, i think wildmidi is the main weakness. it's a nice library from what i've seen, but its development seems to have stalled.
[03:21] <persia> Yeah, well.
[03:21] <tsmithe> does it still not support sf2?
[03:22] <persia> I've not uploaded a new version since way back when.
[03:22]  * persia checks upstream
[03:22] <tsmithe> looks like it doesn't, according to the site
[03:22] <persia> Yeah, but I should probably update it.
[03:23] <persia> There's a note on the homepage about visiting the IRC channel to abuse them about the hackiness of 0.2.2 :)
[03:23] <tsmithe> mm
[03:23] <tsmithe> its main advantage it its lightness, i think, which is good. i don't know how its performance compares to fluidsynth, which is still my favourite
[03:23] <tsmithe> but, of course, fluidsynth has to run as a daemon, which i'm not sure is ideal.
[03:23] <persia> 3.0 has sf2 support.  I'm not sure I'll get it into Lucid, but I should be able to get it into squeeze.
[03:24] <tsmithe> does 3.0 exist, then? i thought it was just a plan.
[03:25] <tsmithe> i think an ideal situation could involve a very minimal daemon that opens an alsa midi port. if something tries to play, it just builds the right gstreamer pipe, all the while opening another port to allow two things to use it at once.
[03:26] <tsmithe> then of course, i suppose gstreamer could do as musescore does, and link against libfluidsynth rather than libwildmidi
[03:26] <tsmithe> of course, i don't know how feasible this is, but it's certainly too much work for me at least until the summer
[03:26] <persia> Oh good.  I'm not as bad a maintainer as I thought from the homepage.  Yeah, neither 2.3 or 3.0 has been released.
[03:27] <tsmithe> thought so.. that's what i meant by "stalled" :s
[03:28] <persia> There's been a few stalled attempts to write some glue that provides a midi sink and gstreamer source.  They all seem to either get overambitious (and turn into softsynths) or not get completed.
[03:29] <tsmithe> i think anything i started would quickly fall into the latter category. as the adage goes, it's easier said than done.
[03:29] <tsmithe> (though i think it could be "easy". but you couldn't avoid "time-consuming")
[03:30] <persia> Well, it wouldn't be that hard to build a gstreamer module that wrapped fluidsynth.
[03:30] <persia> But that would be kinda heavy to provide by default.
[03:30] <persia> (part of why I liked wildmidi)
[03:31] <tsmithe> yes. but would it be excessively heavy? i know fluid is very configurable, and to me it has always *sounded nicer*
[03:32] <persia> Fluid is lovely, but it does require a fair bit of processor and RAM.
[03:33] <tsmithe> do we know why that is?
[03:33] <tsmithe> (i've never read the code)
[03:36] <persia> I don't offhand.  I've always assumed it was because it was good at what it did.
[03:37] <persia> Remember that fluid has all those built-in effects engines and what not.
[03:38] <tsmithe> i know.. can they be turned off? as a hypothetical default, to lighten the load, that could be attractive.
[03:40] <persia> I don't know.
[03:40] <persia> But since we're talking about a theoretical project you don't expect to have time to complete, I'm not sure how much it matters yet :)
[03:42] <tsmithe> no. you're right, and i must admit that was the thought that occurred in my head
[03:45] <persia> heh
[03:46] <tsmithe> ok, pbuilder finally done. time to open the bug.
[03:52] <tsmithe> persia, https://bugs.launchpad.net/ubuntu/+source/mscore/+bug/521584
[03:52] <persia> tsmithe: Thanks.  I'll grab it in a bit.
[03:54]  * jdong wonders if it's actually feasible to backport enough of dpkg bits to support source 3.0
[03:55] <tsmithe> persia, thanks a lot.
[03:55] <tsmithe> hi jdong
[03:55] <tsmithe> but, i'm off to bed. it's 4am again :s
[03:55] <jdong> hey tsmithe :)
[03:56] <tsmithe> ciao! got a lot of music and reading to do tomorrow; gotta get some rest
[03:57] <persia> jdong: Wait for the next merge: there's still some 3.0 bits that lucid doesn't support.
[04:06] <ryanakca> Could someone review http://revu.tauware.de/p/turnin-ng please? turnin-ng_1.0.1-0ubuntu1_{source,i386}.changes are lintian clean.
[04:07] <jdong> ah :) good to know
[06:36] <SoftwareExplorer> I'm having trouble building a package because a directory it installs to doesn't exist in my minimal pbuilder environment. The error I get is at http://paste.ubuntu.com/375971/. How should I handle this ? A mkdir -p in the makefile? Some other part of the packaging? Or should I be looking for the package that makes that directory and depending on it?
[06:53] <fabrice_sp> SoftwareExplorer, the makefile should create the directory it requires to make the cp. Perhaps install would be better than a cp
[06:57] <SoftwareExplorer> In my google ings since I asked, I read a little about install. I have a few questions though. What's the difference between install -d and install -D, i.e. which one gets closest to what cp librgba.so /usr/lib/gtk-2.0/modules/ would do?
[06:59] <jmarsden> SoftwareExplorer: man install    for info on the arguments to it.  install -d foo just creates the directory foo; install -D SRC DEST "create all leading components of DEST except the last, then copy SOURCE to DEST"
[07:01] <jmarsden> SoftwareExplorer: So (guessing a lot) you might want to do something like:   install librgba.so /usr/lib/gtk-2.0/modules/librgba.so
[07:01] <jmarsden> Sorry, make that:  install -D librgba.so /usr/lib/gtk-2.0/modules/librgba.so
[07:01] <SoftwareExplorer> jmarsden: Ok, thanks. I was looking at the man page, but I didn't get the synopsis part.
[07:03] <SoftwareExplorer> jmarsden: Thank you! It worked.
[07:03] <jmarsden> The synopsis in every man page is a list of the ways to use the command.  So if you use install -d all you put after that is a directory, ...
[07:03] <jmarsden> Good!
[07:05] <SoftwareExplorer> So, another question. For the uninstall, there's no uninstall command, so is rm the way to do it?
[07:06] <SoftwareExplorer> Well, at least when I did man uninstall I got an error about no manpage
[07:06] <jmarsden> SoftwareExplorer: You need an "uninstall" target in your makefile, for a Ubuntu package?  Why?
[07:07] <jmarsden> How is your debian/rules file going to use that makefile target?
[07:07] <SoftwareExplorer> Well, this is the first package I've tried.
[07:08] <SoftwareExplorer> So I'm learning lots as I go.
[07:08] <jmarsden> SoftwareExplorer: So you have read and understood the Packaging Guide, right.  And does it mention the need for an uninstall target?
[07:09] <jmarsden> What gave you the idea that you need one?  Is there some packaging documentation out there suggesting one?
[07:09] <SoftwareExplorer> No.
[07:09] <jmarsden> Then... why are you asking me about one? :)
[07:10] <jmarsden> https://wiki.ubuntu.com/PackagingGuide/Complete    is the guide for doing Ubuntu packaging.  Follow it, and you should be fine.
[07:10] <SoftwareExplorer> Because I guessed that if the package uses a makefile to install, then it probably uses a makefile to uninstall.
[07:10] <fabrice_sp> it should, but it's not mandatory
[07:11] <fabrice_sp> opps: I was thinking about a clean target
[07:11] <fabrice_sp> uninstall: no. It's been handeld by the package management tools
[07:11] <jmarsden> fabrice_sp: Right.
[07:12] <SoftwareExplorer> So it's something like dpkg keeps track of files installed by a package and deletes them when the package is removed?
[07:12] <fabrice_sp> yeap
[07:13] <wgrant> Your rules file installs files into the *package*, not onto the system.
[07:13] <SoftwareExplorer> I see.
[07:15] <SoftwareExplorer> Thanks for the help, and I guess I have lots more "homework" to read. :)
[07:54] <jariq> My package finaly got into universe repository. Will I get e-mail automaticaly when someone reports a bug or do I have to subscribe somewhere ??
[08:00] <ripps> It seems that I can't update bzr on my lucid because bzr-gtk has a bzr dependency of (>> 2.1~) which apparently is less than the new bzr's 2.1.0~rc2-1
[08:02] <ripps> Is bzr-gtk really incompatible with bzr 2.1.0~rc2, or is it just be too cautious
[08:03] <iulian> jariq: https://launchpad.net/ubuntu/+source/ipwatchd/+subscribe
[08:04] <iulian> jariq: Do the same for the second package.
[08:05] <jariq> iulian: thx
[08:47] <l3on> fabrice_sp: Thanks for uploading blends :).
[08:47] <l3on> fabrice_sp: I'm going to also report bug in debian.
[09:10] <fabrice_sp> l3on, thanks to you to work on the merge ;-)
[09:35] <oojah> I'm looking for an advocate or two for http://revu.ubuntuwire.com/p/sqlite3-pcre If you fancy giving this package some love on this day of romance, I'd much appreciate it.
[09:39] <nigelb> can someone help me with an error when I try to package.  Its something to do with the patch.  I have an idea whats wrong, but I'm not sure how to correct it
[09:42] <nigelb> this is the error message I get http://pastebin.com/d1cede653
[09:57] <randomaction> nigelb: your pastebin link doesn't work
[09:57] <nigelb> randomaction, oops, hold on.  pasting again
[10:05] <nigelb> I lost the logs, building again to reproduce error
[10:08] <nigelb> here's the paste http://paste.ubuntu.com/376060/
[10:11] <randomaction> yes, the patch doesn't apply
[10:12] <nigelb> the thing is one file the patch is supposed to apply is not exiting at the end
[10:12] <nigelb> but I dont see how
[10:12] <nigelb> I did a quilt push and then patched
[10:13] <nigelb> so, all patches should have applied
[10:15] <nigelb> s/exiting/existing
[10:15] <randomaction> maybe it's deleted in the clean target?
[10:17] <l3on> Hi all... I'm building debian-med... In the build log I see:
[10:17] <l3on> Missing or avoided packages:
[10:17] <l3on> and then a list of packages...
[10:18] <l3on> is it an error?... What means "Missing or avoided packages" in pbuilder ?
[10:18] <l3on> -> http://paste.ubuntu.com/376066/
[10:20] <ari-tczew> l3on: built fine
[10:22] <ari-tczew> is MoM fixed?
[10:26] <l3on> ari-tczew: thank you.
[10:27] <l3on> ari-tczew: "is MoM fixed?" to me ?
[10:29] <ari-tczew> l3on, nope, generally to MOTU / developers
[10:30] <ari-tczew> bdrung, geser, persia: ping
[10:52] <BlackZ> hello, sombody can review this packet? http://revu.ubuntuwire.com/p/autotrash thanks
[10:55] <geser> ari-tczew: MoM is fixed
[10:59] <ari-tczew> geser: second question about fakesync... do we should include previous ubuntu's revision in debian/changelog?
[10:59] <ari-tczew> like in merge
[11:01] <geser> IMHO no, as we would do a normal sync if we didn't need that fakesync
[11:02] <ari-tczew> geser: third question about fakesync... issue is mismatching tarball, so why we can't replace tarball with debian?
[11:07] <geser> the current packages in the archive reference the Ubuntu .orig.tar.gz with its md5sum and when you replace it with one with a different md5sum you break those old .dsc files
[11:08] <ari-tczew> so need to just repace all 3 files - diff.gz, .dsc, tarball
[11:09] <dooooomi> do all modifications outside the debian directory require the use of dpatch or quilt? what if it's just minor, debian-specific changes to the build system or something?
[11:09] <ari-tczew> persia: do you will work on bug 294593 ?
[11:11] <geser> ari-tczew: how for all published (and mirrored) revisions? remember that you can fetch old versions from LP. All the tools assume that once a file got published it doesn't change anymore
[12:02] <paissad> hi all, http://revu.ubuntuwire.com/p/pms-linux ... the package is lintian warning|error free !
[12:41] <jcfp> paissad: that contains loads and loads of binaries, many without sources and/or licenses...
[12:41] <paissad> jcastro, o0
[12:41] <paissad> jcfp,
[12:43] <paissad> jcfp, i don't see what's the matter mate, ... the licence of this soft is GPLv2 .. i don't know what you really mean ^^
[12:45] <sebner> paissad: you can't ship binaries (.dll) without source. I'm wondering if you even testbuilt it because sunjava is not present anymore in lucid
[12:45] <paissad> jcfp, are talking about this http://revu.ubuntuwire.com/report.py/legal?upid=7743 ?
[12:45] <jcfp> paissad: see sebner's comment. I'm talking about the link to revu you posted 43 minutes ago
[12:46] <paissad> sebner, i've tested the package in karmic & jaunty & debian ... not lucid ... i mentioned lucid because it's said that other distrib are not accepted anylonger
[12:46] <sebner> paissad: yeah, you only can upload to the current -devel version which is lucid and I doubt your package will build there
[12:47] <paissad> sebner, though i have to test it in lucid ? ..
[12:47] <paissad> why would that not work ?
[12:48] <sebner> paissad: Because sun-java is not available anymore. You have to test if it builds and run with openjdk
[12:48] <paissad> sebner, ok
[12:49] <ripps> Can someone carry through the bzr-gtk sync from sid? I added a debdiff to bug #521353 to update it dh7, it was giving me a bunch of problems with pbuilder, now it doesn't.
[12:50] <paissad> jcfp, btw, i built the software from the svn source, but i've removed windows binaries during clean target in the debian/rules file .. and the soft is licenced under GPLv2 .. what's wrong with that
[12:50] <paissad> i'm just confused
[12:50] <sebner> ripps: don't add any unecessary changes to Debian packages and especially not to syncs!
[12:51] <sebner> paissad: you better create a get-orig-source rule which removes the binaries beforehand
[12:51] <ari-tczew> sebner: have you got expierence in fix FTBFS causing by gcc, right?
[12:52] <sebner> ari-tczew: O_o, not really. What's the issue
[12:52] <sebner> ?
[12:53] <geser> ripps: does bzr-gtk from Debian unstable build for you in lucid? (see also Debian bug #569415)
[12:53] <paissad> sebner, yeah, how can i build the orig.tar.gz source without windows binaries files ? ... i just ran dh_make -f ../$pakage$version.tar.gz && debuild -uc -us --lintian-opts -iIEvm -pedantic --color always
[12:53] <ari-tczew> sebner: I worked on merge libjdic-java and it got ftbfs, clean debian revision too got ftbfs
[12:53] <ripps> geser: yeah, that's one of the things I fixed in the debdiff
[12:53] <sebner> paissad: you better take a look at the Packaging Guide
[12:54] <ari-tczew> sebner: I can open new bug and include my merge-propose, but it's need ftbfs fix
[12:54] <paissad> sebner, i did mate  ;)
[12:54] <paissad> sebner, i wil do it manually ^^
[12:54] <paissad> will*
[12:54] <sebner> paissad: that's not allowed afaik
[12:55] <sebner> ari-tczew: hmmm, pastebin the error
[12:56] <paissad> sebner, hmm well, if i download from the svn source .. knowing that that source contains windows binaries ( binaries i absolutely don't need for the packaging) ... if i'm not allowed to remove those binaries before compressing the source  .... what must i do then ?
[12:57] <ari-tczew> what's the command for get pbuilder buildlog, verbose?
[12:57] <ari-tczew> I'm building from .dsc
[12:58] <sebner> paissad: well, you are allowed to remove it but with a get-orig-source so every person that fetches the sources through your package gets the same results
[12:58] <sebner> ari-tczew: --logfile
[13:01] <paissad> sebner, ok, i will remove those "fucking" files before compressing the source (tar+gzip) and after that i run dh_make and so on
[13:01] <paissad> are we ok ?
[13:02] <sebner> paissad: you can do that but you still need a get-orig-source rule because you are removing stuff for *this* upload *manually*
[13:02] <paissad> sebner, oh, i did not know about this "get-orig-source" rule ... lmgt
[13:07] <ari-tczew> sebner: http://s1.plikos.pl/11e3/f30af66d18095996ca4d3c886ed16287/buildlog.txt
[13:08] <sebner> ari-tczew: next time please use pastebin ;)
[13:08] <ripps> geser: I just emailed a version of the debdiff to the debian bug. I'm not very familiar with debian's email interface, how long until it the page updates with the email?
[13:09] <geser> a few minutes, you usually get a confirmation mail when your mail got processed
[13:09] <ari-tczew> sebner: pastebin hangs my web browser
[13:09] <ari-tczew> this is a large file
[13:10] <sebner> ari-tczew: well, not everyone wants to download something from a polish upload service ;) You might have more luck asking in #ubuntu-mozillateam as it seems this is a xulrunner issue
[13:15] <paissad> i don't see any info about get-orig-source  rule in maintainer guide (debian|ubuntu) .. may someone help me ?
[13:16] <jcfp> paissad: get-orig-source is a target in debian/rules that automates the cleanup so that anyone can simply run ./debian/rules get-orig-source and get a clean tarball free of unwanted binaries (jar, exe, dll, etc.).
[13:16] <paissad> ok ... thanks
[13:17] <paissad> jcfp, and i guess that target should be called before clean target !
[13:17] <sebner> paissad: https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball
[13:18] <sebner> paissad: it's not needed to remove the binaries in the clean target when they are not present (get-orig-source gives you a clean tarball)
[13:18] <paissad> ok
[13:21] <bdrung> ari-tczew: pong
[13:29] <ari-tczew> bdrung: about debian/changelog in fakesync... so get changelog file from Debian and add dch -i "Fake sync due to..." right?
[13:29] <bdrung> ari-tczew: yes
[13:30] <ari-tczew> ok, so fakesyncs are waiting for sponsor :D
[13:32] <sebner> ari-tczew: mind our new policy :P (See -devel ML)
[13:33] <ari-tczew> sebner: -devel ML?
[13:33] <sebner> ari-tczew: ubuntu-devel Mailinglist. We use now XfacesyncY in the changelog
[13:34] <ari-tczew> wrrrrrr
[13:34] <ari-tczew> so I need to change all debdiffs
[13:34] <sebner> ari-tczew: well, it's not that fix so just go with your debdiffs for now ;D
[13:35] <sebner> ari-tczew: It will be a requirement at some point in the future though
[13:35] <ari-tczew> sebner: stricte start oficial using -XfakesyncY with new development cycle? not now?
[13:37] <sebner> ari-tczew: well, yesterday there was a dicussion if we should use XubuntuY or XbuildY and the think the most appropriate it XfakesyncY. Don't know when we'll really use it. As FF nears and not that many syncs/fakesyncs will occur you might be right with lucid+1
[13:38] <sebner> ari-tczew: there is still some discussion going on so you might want to ask persia as he is the mastermind behind this :D
[13:39] <ari-tczew> sebner: I know about yesterday discussion, because I just started discussion :-]
[13:39] <sebner> heh
[13:39] <sebner> ari-tczew: yeah but it's now on the ML as well
[13:39] <ari-tczew> what is "lucid+1" ?
[13:40] <sebner> ari-tczew: Ubuntu 10.10 ;)
[13:41] <ari-tczew> sebner: so do I need to refresh all my debdiffs, or not?
[13:41] <sebner> ari-tczew: Do as you wish as nothing is official yet
[13:42] <ari-tczew> so I don't change debdiffs, just waiting for sponsors
[13:47] <bdrung> sebner: we had here a very long discussion about fakesyncs yesterday (you can read the log if you have an hour)
[13:48] <sebner> bdrung: I participated too ;)
[13:49] <bdrung> ups :)
[13:49] <sebner> bdrung: as it's on the ML to gather some more feedback I was just not sure how official it is now
[13:51] <bdrung> sebner: i think we should wait some time (one or two weak). if there are no vetos, it's official. then we should create the wiki documentation.
[13:51] <sebner> bdrung: aye
[13:52] <bdrung> sebner: a response from an archive-admin would be good (because they have to modify their scripts)
[13:52] <sebner> bdrung: pitti agreed already
[13:52] <bdrung> k
[13:53] <bdrung> sebner: so XfakesyncY wouldn't do any harm (compared to using XubuntuY)?
[13:54] <geser> sebner: give it some more time. at least the next week so the other devs have time to read it
[13:54] <sebner> geser: sure
[13:54] <sebner> bdrung: I guess
[13:55] <sebner> geser: bdrung but fakesync won't get autosynced if I understood it right?
[13:55] <geser> you probably need to look into the scripts to know for sure
[13:56] <bdrung> geser: where do i find the script?
[13:57] <geser> bdrung: some parts are in https://code.edge.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk and some in LP itself
[13:57] <sebner> geser: I just read it and I guessed but I'm not 100% sure
[13:57] <sebner> geser: oh, I thought you spoke about persias proposal. Nothing is implemented yet?!
[13:59] <geser> sebner: the proposal intend to autosync on new upstream versions and there wasn't enough time since yesterday to created patches for the existing code
[14:01] <sebner> geser: so there are super cool features planned where you can tell the difference between new upstream and new debian version and work accordingly?
[14:01] <bdrung> geser: i found nothing related in ubuntu-archive-tools
[14:02] <geser> bdrung: I don't have an clear overview how the autosync work in detail myself yet
[14:03] <geser> bdrung: some scripts are in scripts/ftpmaster-tools in the LP code. those are the server-side parts from the archive admin scripts
[14:03] <bdrung> geser: can i branch this code somewhere?
[14:04] <bdrung> geser: with the XfakesyncY in the name, the sync script could sync in all cases.
[14:05] <sebner> bdrung: only in case of new upstream :P
[14:06] <geser> bdrung: https://dev.launchpad.net/Getting
[14:06] <bdrung> sebner: no. in the other case the script can do something similar to my fakesync script (get debian source, extract it, replace the source tarball, dch -i "fakesync")
[14:06] <sebner> bdrung: interesting approach
[14:07] <geser> bdrung: if you only want to look at the code branch lp:launchpad/devel
[14:07] <geser> bdrung: sync-source.py from http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/files/head%3A/scripts/ftpmaster-tools/ might be a good start for looking
[14:12] <gusnan> What are the reasons for a package to dissappear from the list at revu.ubuntuwire.com ?
[14:15] <ari-tczew> bdrung: could you take a look @ http://pastebin.ubuntu.com/376172/ is it possible to causing ftbfs by gcc ?
[14:17] <bdrung> ari-tczew: it's not the fault of gcc. The problem starts with "No such file or directory". a package could be missing or a parameter is not set correctly.
[14:18] <geser> ari-tczew: unlikely, see like 1550+: gtkmozembed_internal.h:25:27: error: nsIWebBrowser.h: No such file or directory
[14:19] <iulian> gusnan: Does it show up on the front page?
[14:20] <iulian> gusnan: What is the name of the package you're interested in?
[14:20] <gusnan> iulian, no - it does show up if I have a "direct" link though.
[14:20] <gusnan> It my own package "sciteproj"
[14:21] <geser> ari-tczew: looking at line 1546 those absolute paths for -include and -I look suspicious
[14:21] <gusnan> it's there at /p/sciteproj , but not in the list on the front-page.
[14:21] <iulian> Ah.
[14:21] <iulian> Hmm.
[14:24] <iulian> gusnan: It seems that the package has been archived.  I've just unarchived it and should show up on the front page.
[14:24] <gusnan> thanks!
[14:26] <ari-tczew> I don't have time for waste time to fix this FTBFS, I can open a new bug and include my merge-propose diff
[14:26] <ari-tczew> maybe someone want to take this one and fix FTBFS
[14:32] <ari-tczew> bug 521712
[14:37] <directhex> main -> multiverse? that sounds odd
[14:38] <geser> libjdic-java in in universe since jaunty
[14:38] <ari-tczew> if it's disturb you, feel free to change it
[14:43] <persia> ari-tczew: Rather, please explain why it should now be in multiverse
[14:46] <ari-tczew> persia: omfg, I don't want to move into multiverse, just I always look @ Component: multiverse
[14:46] <ari-tczew> https://launchpad.net/ubuntu/+source/libjdic-java
[14:46] <ari-tczew> enough?
[14:47] <persia> That's a bug in launchpad (because it's not in multiverse).  Please report it.
[14:48] <geser> persia: see the footnote
[14:48] <ari-tczew> persia: regards for you, because it's not me find this bug and I can't describe what about this issue
[14:49] <persia> geser: Where is that encoded within the package though?
[14:49] <persia> geser: Or is it just stuck until the next upload?
[14:50] <persia> ari-tczew: Fair enough.  Do you understand why it's a bug?
[14:50] <geser> as far as I understand it the "package information" is the data of the last upload, not the current one (e.g. if the page gets promoted/demoted since then)
[14:50] <geser> s/page/package/
[14:51] <persia> geser: That makes sense, but LP *knows* the current value.  Oh well, still buggy :)
[14:51] <geser> the last libjdic-java upload went to multiverse and the package got moved to universe after that
[14:51] <persia> RIght.
[14:52] <geser> yes, the page itself is correct because of the footnote, but not very useful in that form
[14:53] <ari-tczew> persia: how do you checking package component?
[14:54] <geser> ari-tczew: I look at the table on the page you mentioned
[14:54] <persia> ari-tczew: apt-cache show ${PACKAGE} | grep ^Section: provides a hint for a current apt-cache.  rmadison provides a hint for other environments.
[14:54] <ari-tczew> ah, I SEE
[14:56] <ari-tczew> persia: could you report bug to launchpad? because you found it
[14:56] <persia> ari-tczew: doing so now
[14:57] <ari-tczew> persia: what about bug 294593 ? do you will work on it?
[14:57] <persia> I'll try it again.  It completely failed the last few times I tried.
[14:58] <ari-tczew> would be nice
[14:59] <persia> ari-tczew: It's causing some bug?
[15:00] <ari-tczew> persia: probably not, just I want to clean up repositories before FFe
[15:01] <persia> This merge isn't affected by FF.
[15:01] <persia> No new upstream.  No significant changes in Debian.
[15:02] <ari-tczew> persia: so is it can be merged while FFe? without any special reasons?
[15:02] <persia> ari-tczew: Well, check the changelogs in Ubuntu and Debian, and check the differences.  I don't see anything (and I strongly dislike trying to merge around tarball-in-tarball)
[15:03] <ari-tczew> persia: but what about fakesyncs? can I prepare debdiff while FFe?
[15:04] <bdrung> ari-tczew: bug 499329 needs an merge and maybe a refresh to use the latest mozilla-devscripts features
[15:07] <ari-tczew> bdrung: so this is a job for dhillon-v10
[15:08] <ari-tczew> wrrrr, java in firefox 3.6 doesn't work? I can't play on-line java games.
[15:09] <ari-tczew> [lucid]
[15:09] <geser> ari-tczew: less distraction for you :)
[15:11] <ari-tczew> geser: what do you think about?
[15:11] <l3on> Hi all.. someone of you can confirm me that this bug is invalid -> https://bugs.edge.launchpad.net/ubuntu/+source/sdl-image1.2/+bug/515105 ?
[15:14] <persia> l3on: I don't think it's invalid: rather I think that some additional Conflicts/Replaces work needs be done.  (and #ubuntu-bugs is often a good place to ask this class of question)
[15:14] <l3on> thanks persia
[15:16] <l3on> problem is that there is no package called sdl-image-devel which conflicts in the bug report.
[15:17] <persia> libsdl-image1.2-dev
[15:17] <l3on> Ok, but:
[15:17] <l3on> Title: package libsdl-image1.2-dev (not installed) failed to install/upgrade: trying to overwrite '/usr/include/SDL/SDL_image.h', which is also in package sdl-image-devel 0:1.2.10-2
[15:18] <persia> l3on: Are we looking at the same bug?  I see "trying to overwrite '/usr/lib/libSDL_image-1.2.so.0', which is also in package sdl-image 0:1.2.10-2"
[15:20] <persia> l3on: Oh, I see it now different place.  Yeah, I think the bug is invalid, but it might be exposing also a valid bug :)
[15:20] <l3on> anyway: there is no package called sdl-image in ubutnu -> http://packages.ubuntu.com/search?keywords=sdl-image
[15:21] <persia> apt-cache search sdl-image shows me two packages.
[15:22] <l3on> of course.. me too.
[15:22] <l3on> libsdl-image1.2 - image loading library for Simple DirectMedia Layer 1.2
[15:22] <l3on> libsdl-image1.2-dev - development files for SDL 1.2 image loading libray
[15:23] <l3on> I think that that package cames from a Third Party Repository.. or something similiar.
[15:25] <persia> http://conflictchecker.ubuntu.com/possible-conflicts/karmic/universe.txt shows a potential issue with libsdl1.2-pulseaudio, but I think that's different.
[15:25] <persia> You might check other releases, but it may be entirely invalid.
[15:25] <persia> (and we really ought to find time to clean up one of the releases one day on that checker)
[15:29] <l3on> A lot of weeks ago I was writing a py script that through launchpad-lib went in LP and marked a lot of old bugs of LTS as Invalid... but I did not find free time to finish the work. However, script could be potentially dangerous...
[15:31] <l3on> But it could be a fast way to do what you speaking about.. (If I understand what do you mean... :P)
[15:32] <persia> I think maybe I wasn't clear.
[15:32] <persia> The conflictchecker is currently producing about 9MB of data about undeclared conflicts in packages.
[15:33] <persia> Adding the appropriate Conflicts/Replaces entries in the packages would be good.
[15:33] <persia> It would be nice to have a release that was known not to have any valid conflict/replace bugs in the upgrade path.
[15:33] <persia> (but it's a *massive* volume of work)
[15:35] <l3on> Ahh.. Ok. :))
[15:49] <paissad> do you know a package that uses  get-orig-source in his debian/rules file so that i can have real examples ?
[15:49] <directhex> paissad, most mono-flavoured packages do
[16:09] <asbin> bdrung: Thank you for your comment in enna package, I've just uploaded a new version.
[16:09] <bdrung> asbin: drop quilt from b-d (you do not need it)
[16:10] <asbin> bdrung: really ? my package would'nt build with pbuilder if I remove quilt b-d !
[16:11] <bdrung> asbin: dpkg-source applies the patches (so you do not have to b-d on it)
[16:11] <asbin> bdrung: oh i've added a "include /usr/share/cdbs/1/rules/patchsys-quilt.mk" in the debian/rules file ...
[16:11] <bdrung> asbin: drop this too. ;)
[16:13] <asbin> bdrung: of course ;)
[16:14] <AnAnt> Hello, regarding sl-modem-source, it currently Recommends: dkms, linux-headers-2.6-486 | linux-headers-generic | linux-headers
[16:14] <AnAnt> shouldn't it rather Depend on linux-headers-2.6-486 | linux-headers-generic | linux-headers ?
[16:19] <oojah> paissad: http://revu.ubuntuwire.com/p/sqlite3-pcre has get-orig-source for downloading from a git repo. It's still awaiting review though, so might not be the best example.
[16:23] <asbin> bdrung: ok, package re-uploaded :)
[16:24] <bdrung> asbin: debian/control has trailing whitespaces
[16:29] <bdrung> asbin: find another ubuntu developer, who ACK your package, and i will upload it
[17:08] <didrocks> fabrice_sp: hey. please, check when branches are maintained into bzr. You last anjuta's sponsored wasn't pushed into the desktop team branch and I accidentely removed the -0ubuntu2 changes
[17:08] <persia> AnAnt: Depends is probably more appropriate, as the modules won't build without them.
[17:08] <didrocks> fabrice_sp: debcheckout warns you when there is a Vcs-Bzr tag :)
[17:09] <persia> didrocks: The issue is that the warning is useless for 90% of packages, as it applies to some Debian source.
[17:09] <persia> didrocks: Perhaps it's worth trying to get some additional tag set somehow that indicates when a package has special Ubuntu handling?
[17:09] <didrocks> persia: right, I think that we should maybe patch that
[17:10] <didrocks> persia: I think it worth a try as this error is more than common
[17:10] <persia> How though?  We can't even rely on launchpad being authoritative, as there are potentially packages that aren't specially handled in Ubuntu that use launchpad.
[17:10] <persia> didrocks: Also, shouldn't the desktop team migrate to using the new distributed development branches :)
[17:11] <didrocks> persia: I know, the migration will be slow, as we wait for the merge-upstream to be 100% working for big packages like nautilus ;) (we already try that on package where upstream is dx team)
[17:12] <persia> Yeah.  I wouldn't expect it to happen overnight, and there's still plenty of *native* packages that have separate bzr trunks.
[17:13] <persia> But aside from that, how do you think we might handle better tracking of when a VCS is being used?
[17:13] <randomaction> Why isn't Maintainer: field set to ubuntu-desktop for anjuta?
[17:13] <persia> Should debcheckout perhaps warn if there is an upload?
[17:13] <persia> That's another good question: it's definitely worth mangling the maintainer for these special cases.
[17:15] <didrocks> persia: I agree, the Maintainer field is quite random today. And maybe debcheckout can warn if current revision in branch (not UNRELEASED) != last uploaded version?
[17:16] <persia> didrocks: Yeah, I think debcheckout is the right place, because that catches also cases where Vcs-* is in Debian and there is Ubuntu variation.  apt-get's warning is probably good as-is.
[17:16] <persia> (and patching debcheckout also means we don't need to invent new headers, etc.)
[17:17] <didrocks> persia: totally agree. Not the time to work on it before FF, but can be easy to do after that :)
[17:17] <persia> It's a new feature: you'd need an exception to do it after that.
[17:18] <persia> I think it mostly hits the Desktop team, as I don't think any other teams have quite such an advanced, non-distributed-development VCS workflow.
[17:18] <didrocks> persia: right, but even if the change is hanging around on my computer until next release, that's not so urgent afterwards
[17:18] <didrocks> yeah, mostly
[17:19] <persia> True.  I'm just thinking of time spent fixing up these issues vs. time spent patching :)
[17:19] <persia> I think I see a complaint from the desktop team at least once a week.
[17:21] <didrocks> I'll try to have a look on Monday (it seems I have said that too many time in the last 48h, will see if it's possible) :)
[17:21] <didrocks> but debcheckout is in perl, right?
[17:21] <persia> heh.  Good luck :)  Maybe you can also get someone else to do it.
[17:22] <persia> Yes, perl.
[17:22] <didrocks> well, I have limited knowledge in it, so, maybe, we can call for an opened opportunity :)
[17:23] <persia> Declaring an opportunity sounds like a good plan.  Seems there are lots of folks who opportunistically fiddle with desktop stuff: some might have a bit of time.
[17:24] <didrocks> and no GNOME release next week, so, that can be an easy task to give
[17:24]  * didrocks write down on a note
[17:24] <persia> Indeed.
[17:37] <AnAnt> persia: thanks
[17:38] <persia> AnAnt: No, thank you for volunteering to get that package from the absolutely useless state in which it was for hardy into something that has become not only usable, but actually almost good.
[17:38] <persia> (some of the reasons it's not yet "good" are unfortunately hardware limitations :( )
[17:38] <AnAnt> persia: and lack of upstream development
[17:39] <persia> Yeah.  Nobody seems to care anymore.
[17:39] <AnAnt> persia: the current maintainers aren't developers, but they accept patches
[17:39] <AnAnt> persia: the guys at linmodems.org are really doing their best
[17:40] <AnAnt> persia: but the best they can give is limited to support
[17:40] <persia> Indeed.  I think the issue is mostly that very few people still use them as modems (instead using other forms of network connectivity), and not enough people want telephony yet.
[17:41] <AnAnt> another question, the first package in Recommends should be a real (not virtual) package, right ? ie Recommends: x | y | z, x must be a real package, right ?
[17:41] <AnAnt> or that is only for Depends ?
[17:41] <persia> For both.
[17:50] <AnAnt> persia: btw, Rolf Leggewie also joined in for maintaining sl-modem lately
[17:50] <persia> Cool!
[17:51] <AnAnt> yeah
[17:54] <BlackZ> somebody can review this package? http://revu.ubuntuwire.com/p/autotrash thanks
[18:09] <jcfp> BlackZ: looking
[18:13] <l3on> Someone could take a quick look at goobox in merges.ubuntu.com/universe.html ?
[18:14] <l3on> why is not there uploader ?
[18:15] <l3on> and why version is 2.0.0-5ubuntu1 if in lucid we have: 2.1.1-3?
[18:19] <AnAnt> back to sl-modem-source, isn't linux-libc-dev enough ?
[18:20] <persia> Does it not need kernel headers to build the kernel modules?
[18:20] <AnAnt> yes,
[18:20] <AnAnt> ok
[18:25] <wrapster> how do i create a pkg from tar.gz
[18:25] <wrapster> I always get this error.. "The directory name must be <package>-<version> for dh_make to work!
[18:25] <wrapster> I cannot understand the directory name or you have an invalid directory name!
[18:25] <wrapster> "
[18:26] <geser> to which directory does the .tar.gz unpack?
[18:26] <persia> wrapster: Trick 1: don't use dh_make :)
[18:27] <persia> wrapster: Just unpack the upstream tarball, and create a debian/ directory in there, and create your changelog, copyright, control, and rules files.
[18:33] <Rhonda> fabrice_sp: What I said was that I didn't note down the LP bug with the category wish because actually it should be invalid, it has to be in there already …
[18:34] <hyperair> persia: interestingly, i still can't create a package without dh_make. the only file i know how to completely rewrite is the rules and copyright files. i still don't really remember the changelog and control format fully.
[18:35] <hyperair> heheh
[18:45] <randomaction> hyperair: dch --create creates changelog
[18:45] <jcfp> BlackZ: commented
[18:46] <hyperair> randomaction: ah it does? cool.
[18:46] <hyperair> randomaction: that doesn't help me with my debian/control issue though..
[18:46] <hyperair> randomaction: i just don't seem to remember the required fields.
[18:46] <randomaction> dh_make is really outdated
[18:46] <hyperair> i agree.
[18:46] <hyperair> i just dh_make, remove most of the .ex/.EX files
[18:46] <hyperair> make that all
[18:46] <hyperair> and debian/rules
[18:47] <hyperair> and copyright
[18:47] <hyperair> then i rewrite those two
[18:47] <hyperair> and the watch file also
[18:47] <james_w> mkdir debian/; dh_make --addmissing; rm debian/*.ex debian/*.EX'; is another way to start
[18:47] <hyperair> hmm
[18:47] <persia> hyperair: One should always use dch to create the changelog.
[18:47] <asbin> persia: Hi ! You already have a look to enna package http://revu.ubuntuwire.com/p/enna , bdrung has made some comments and I've follow his recommendations, can you please have look at it ? Thank you !
[18:47] <hyperair> persia: why?
[18:47] <persia> hyperair: And control is just RFC2822-format based on the policy.
[18:48] <persia> hyperair: Because the format is fussy :)
[18:48] <hyperair> persia: yes, i know, but i'd have to go dig out the policy to figure out the fields required
[18:49] <persia> hyperair: sensible-browser /usr/share/doc/debian-policy/policy.html/ch-controlfields.html
[18:49] <hyperair> persia: then i'd have to have a browser open.
[18:50] <persia> hyperair: Well, one could use an ncurses browser.  Alternately, one could use /usr/share/doc/ubuntu-policy/policy.txt.gz
[18:51] <hyperair> persia: all those alternatives are no better than just getting dh_make to give me a skeleton control file
[18:51] <persia> There are also a couple different tools that automatically generate this for python packages.  Having a more general solution would be nice.
[18:52] <persia> hyperair: I guess.  I'm just unhappy enough with the rest of what dh_make produces (and needing to answer the same 25 questions related to how it's completely wrong) that I advise against using it at all.
[18:52] <hyperair> persia: heh well, i suppose dh_make is not good for beginners learning to package by the standards
[18:53] <BlackZ> jcfp: thanks, I'm fixing the problems/errors
[18:53] <persia> I don't think so, and I think that once someone isn't a beginner, it's just as easy to just type Source, Maintainer, Section, Priority, Build-Depends, Standards-Version, Homepage, Package, Architecture, Depends, Description in a text file :)
[18:53]  * hyperair grumbles
[18:54] <hyperair> that's a long list and i've a bad memory, damnit.
[18:54] <persia> That's why there's the files I referenced :)
[18:56] <l3on>  -> dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
[18:56] <l3on> what could be the cause ?
[18:57] <persia> l3on: That usually comes from not running update-maintainer when applying other patches in a package not otherwise changed in Ubuntu.
[18:57] <hyperair> persia: but that requires me to open up a browser on my machine that is generally running out of memory already.
[18:58] <persia> hyperair: Or a text viewer :)
[18:58] <l3on> persia: -> Ubuntu Developers is already set as maintainer.
[18:58] <hyperair> right
[18:58] <persia> hyperair: Or just take a note of the 11 fields, and create a template file :)
[18:58] <persia> l3on: with which email address?
[18:58] <hyperair> dh_make sounds simpler to use.
[18:59] <l3on> persia: cat debian/control.in|grep maint
[18:59] <l3on> Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
[18:59] <l3on> XSBC-Original-Maintainer: Jonas Smedegaard <dr@jones.dk>
[19:00] <l3on> but also there is a debian/control file with Mainteiner set to Jonas Smedegaard <dr@jones.dk>
[19:00] <persia> l3on: Probably related to debian/control.in -> debian/control generation.
[19:00]  * didrocks fabrice_sp_ hey. please, check when branches are maintained into bzr. You last anjuta's sponsored wasn't pushed into the desktop team branch and I accidentely removed the -0ubuntu2 changes
[19:00] <persia> didrocks: Didn't you say that before?
[19:00] <l3on> persia: have I try to modify manually debian/control ?
[19:00] <didrocks> (fabrice_sp_: seems you was disconnected)
[19:00] <didrocks> persia: /msg /me :/
[19:04] <askhl_> I'm creating a data package containing files used by another package.  Where would be a good/recommended place to install these files?
[19:04] <askhl_> /usr/share/<packagename>?
[19:05] <l3on> Ok, persia I received this:
[19:05] <l3on> E: moin source: debian-rules-automatically-updates-control line 25
[19:05] <l3on> so, I edit rules:25
[19:05] <persia> Right.  That's a bug in the package.
[19:06] <l3on>   DEB_AUTO_UPDATE_DEBIAN_CONTROL = yes
[19:06] <persia> But you didn't then manually update the control file.
[19:06] <l3on> to
[19:06] <l3on>    DEB_AUTO_UPDATE_DEBIAN_CONTROL = no
[19:06] <l3on> the part of code is:
[19:06] <l3on> DEB_PYTHON_SYSTEM = pysupport
[19:06] <l3on> ifneq (,$(DEB_MAINTAINER_MODE))
[19:06] <l3on>   # Enable stuff not policy compliant (eg. unsuitable for build daemons)
[19:06] <l3on>   DEB_COPYRIGHT_CHECK_STRICT = yes
[19:06] <l3on>   DEB_AUTO_UPDATE_DEBIAN_CONTROL = no
[19:06] <l3on> is it the right way ?
[19:08] <persia> I usually just leave E: debian-rules-automatically-updates-control alone and try to work around it.
[19:08] <persia> Worth filing a bug in Debian, but painful to try to fix (and maintain) as an Ubuntu delta.
[19:11] <l3on> ok... thanks for suggestions. :)
[19:23] <askhl_> I would like to write a package which just contains data (used by a different package).  I know that you can install docs to the proper location by just writing the filenames in debian/docs.  What approximately should I do to install other data into some appropriate location?
[19:24] <askhl_> I'm using dh_make to get a makefile with targets such as dh_installdirs.  Is this the one I want?
[19:24] <persia> No.
[19:24] <persia> You want to use dh_install
[19:24]  * persia digs up a URL for a slightly-outdated class on the subject
[19:25] <persia> https://wiki.ubuntu.com/MOTU/School/PackagingWithoutCompiling
[19:26] <askhl_> Thanks a lot, persia
[19:26] <persia> askhl_: The example is for a shell script, but the same model applies to anything that just needs to copy stuff somewhere.
[19:29] <askhl_> Great.  This is much simpler than what I was doing
[19:29] <persia> yeah.  dh_make is a handy tool to use to teach the art of packaging, but not so useful if just trying to get something packaged.
[19:43] <fabrice_sp_> Rhonda, sync of pgadmin3 requested ;-)
[19:43] <fabrice_sp_> (too late)
[19:51] <asbin> Hi everybody ! is there ubuntu developers here ? I'm looking for reviewers for a package ...
[19:51] <asbin> Here it is : http://revu.ubuntuwire.com/p/enna
[19:58] <didrocks> persia: I need your light on a FTBFS on amd64 that I don't get on i386: http://launchpadlibrarian.net/39193477/buildlog_ubuntu-lucid-amd64.anjuta_2%3A2.29.90.0-0ubuntu2_FAILEDTOBUILD.txt.gz
[19:59] <didrocks> persia: libsvn-dev dep is pretty simple: Depends: libsvn1 (= ${binary:Version}), libapr1-dev, libaprutil1-dev
[19:59] <kklimonda> hey - could some motu take a look at bug 508225?
[20:00] <didrocks> persia: and the bin package is available on amd64 too if you look at rmadison libaprutil1-dev
[20:00] <persia> didrocks: attempting to replicate locally
[20:01] <didrocks> persia: oh sweet if you have an amd64 machine :)
[20:01] <persia> didrocks: This sort of thing usually comes from arch-skew :)
[20:02] <didrocks> persia: I'm guessing that, but if I can have a confirmation first ;)
[20:03]  * persia has 5 different chroots of three different architectures performing apt operations, and is coming to really appreciate the new rng-tools being able to cope.
[20:05] <geser> didrocks: see #ubuntu-devel, mysql-cluster-7.0 broke libmysqlclient-dev on amd64
[20:05] <geser> bug 521815
[20:05] <persia> geser: Would that kill libapr1-dev?
[20:05] <geser> yes
[20:05] <persia> I didn't know it was that widespread.  Makes sense.
[20:05] <didrocks> geser: oh right, thanks for the notice :)
[20:06] <geser> libmysqlclient-dev is uninstallable on amd64
[20:07] <didrocks> ok so, let's subscribe to the bug and wait for retrying a rebuild once fixed
[20:24] <randomaction> I totally love comment #1 in that bug :)
[20:27] <SoftwareExplorer> I'm trying to package a single .c file that only came with instructions on what command to run to compile it and then copy it into /usr/lib/gtk-2.0/modules/. I had to make a makefile and package it. Here's the problem:When I try to build it with pbuilder, the resulting deb doesn't have the file that I'm trying to install. So, what am I doing wrong? The file for this are at http://ubuntuforums.org/showthread.php?t=1406517 
[20:28] <oojah> SoftwareExplorer: If it helps, compare against http://revu.ubuntuwire.com/p/sqlite3-pcre because that does exactly the same thing.
[20:28] <oojah> (if anybody wants to review/advocate sqlite3-pcre that'd be great, thanks!)
[20:28] <asbin> persia: Hi ! You already have a look to enna package http://revu.ubuntuwire.com/p/enna , can you please have a look at it ? Thank you !
[20:29] <SoftwareExplorer> oojah: Ok, I'll look at it and see if it give me an idea of what i'm doing wrong.
[20:30] <SoftwareExplorer> By the way, sudo make install does install it on my computer
[20:30] <persia> SoftwareExplorer: Also check your build log: a common error is that the file ends up being installed to the build environment rather than into the package.
[20:31] <SoftwareExplorer> persia: Where would a pbuilder build log be?
[20:31] <persia> SoftwareExplorer: No idea.  I don't use pbuilder.
[20:32] <persia> (or I used it once, but that was part of an effort to not need to use it at all)
[20:37] <oojah> SoftwareExplorer: Make sure it's installing to DESTDIR as well.
[20:39] <SoftwareExplorer> oojah: I think my makefile is doing that, but would you look at it and tell me if I'm doing it correctly?
[20:41] <oojah> Just give me a moment.
[20:44] <SoftwareExplorer> oojah: That's fine. I should go eat Lunch, so if I don't respond for a while, you know why. Thanks.
[20:52] <oojah> SoftwareExplorer: Looks ok to me. I'd try changing the PREFIX?=usr/ line to just PREFIX=usr/ in case something funny is going on there. You can always override with "make PREFIX=blah" anyway.
[20:53] <oojah> Also, fwiw, you'd normally define prefix with a slash (/) at the start of the path and not at the end.
[20:54] <oojah> The install location would then be ${DESTDIR}${PREFIX}/lib/gtk-2.0/modules/librgba.so
[20:58] <oojah> SoftwareExplorer: And for the package in general, you ought to be using patches to add the Makefile.
[21:12] <rmunn> Any MOTUs interested in being a second advocate for http://revu.ubuntuwire.com/p/python-nltk today? I'd like to get it into Lucid before feature freeze, and I have one advocate already, just need a second one.
[21:14] <rmunn> NLTK is a Python library for natural language processing, and O'Reilly recently published a book about it (http://oreilly.com/catalog/9780596516499). It would be nice to be able to "apt-get install python-nltk" in Lucid. Please help. :-)
[21:14] <rmunn> (Full disclosure: I was a technical reviewer on that book.)
[21:25] <SoftwareExplorer> oojah: Ok, thanks.
[21:29] <bdrung> asbin: found another thing
[21:29] <asbin> bdrung: Arghhh
[21:30] <bdrung> asbin: a cyclic dependency between enna and enna-theme.
[21:31] <asbin> bdrung: what's wrong with that ?
[21:31] <bdrung> asbin: cyclic dependencies causes problems. it's enough if enna depends on enna-theme.
[21:32] <asbin> bdrung: ok no problem, I can remove it
[21:32] <asbin> bdrung: beter if enna-theme suggest or recommend enna ?
[21:34] <bdrung> asbin: you can suggest it, but i wouldn't do it
[21:35] <asbin> bdrung: OK, you're the boss ;)
[21:35] <dooooomi> hi, i'm trying to use quilt for a package. https://wiki.ubuntu.com/README.sourceHowTo says: "instead of including a README.source file like these you can just point to the one provided within the /usr/share/doc/* tree". what is "point to" supposed to mean?
[21:36] <bdrung> asbin: yeah, muharhar.
[21:36] <bdrung> ;)
[21:36] <asbin> ;)
[21:38] <asbin> bdrung: OK I'm uploading a new one
[21:40] <asbin> is there a way to not upload the source file each time I have to upload a new version of a package on revu ?
[21:41] <asbin> (the source file for enna is about 20MB ...)
[21:41] <bdrung> asbin: try debuild -S -sd
[21:41] <asbin> I will, thanks !
[21:50] <bdrung> whom to ask, when revu has a bug (i am still not a ubuntu developer in revu)?
[21:51] <persia> bdrung: Look for a REVU hacker.
[21:52] <persia> bdrung: but I might be able to help in some limited ways: what sort of bug?
[21:52] <bdrung> persia: who are the revu hacker? you?
[21:52] <persia> No.
[21:52]  * persia is only a revu admin
[21:52] <bdrung> persia: i am still not a ubuntu developer in revu
[21:52] <persia> Oh, I can fix that :)
[21:53] <persia> https://launchpad.net/~revu-hackers
[21:53] <bdrung> persia: i created the revu account when i was ubuntu contributor
[21:53] <persia> It's supposed to update, but it's buggy sometimes.
[21:53]  * persia doesn't quite understand why
[21:54] <persia> Anyway, your permissions have been manually changed.
[21:54] <persia> If you feel like fixing the bug, we enter REVU hacking season in about 3 days :)
[21:54] <bdrung> persia: i fixed enough for today
[21:55] <persia> heh :)
[21:56] <bdrung> persia: thanks for fixing
[21:57] <bdrung> asbin: you have your first advocate now.
[21:57] <asbin> bdrung: no way ! Thank you !! :)
[21:57] <bdrung> np
[21:58] <bdrung> asbin: find another advocate and find a debian mentor
[21:58] <asbin> great ! :)
[22:00] <asbin> is there a bug in revu with the activity graph ?
[22:01] <persia> asbin: Do you have an example package that may be affected?
[22:01]  * asbin need a second advocate for enna package http://revu.ubuntuwire.com/p/enna please !
[22:02] <asbin> persia: enna for example : http://revu.ubuntuwire.com/p/enna
[22:02] <persia> Yeah, that does look wrong.
[22:02] <asbin> persia: bug maybe I don't understand what the graph wants to show ??
[22:04] <persia> asbin: I think it's supposed to show number of comments/uploads/advocations on a daily basis.
[22:04] <persia> But I could be wrong.
[22:04]  * persia may be a revu admin, but mostly just cares about having somewhere to grab .dsc files and comment
[22:04] <asbin> found a package where it looks good : http://revu.ubuntuwire.com/p/smartcam
[22:05] <persia> Well, that doesn't show the uploads.
[22:09] <SoftwareExplorer> oojah: I tried you changes to the makefile but it didn't fix it. I had it do install -D librgba.so ${DESTDIR}${PREFIX}/lib/gtk-2.0/modules/librgba.so&&ls ${DESTDIR}${PREFIX}/lib/gtk-2.0/modules/ and when it run the ls part said librgba.so So it seems to have installed to the right place. I haven't tried adding the makefile as a patch because I figure I'll get it working and then make changes. (unless you think adding the 
[22:23] <bdrung> SoftwareExplorer: why do you use ${...} instead of $(...)?
[22:25] <SoftwareExplorer> bdrung: Is there an important difference? I though they both represented a variable. I was using $() earlier, but someone who was helping me with makefile used ${} when they were explaining something, so that's what I used
[22:26] <bdrung> SoftwareExplorer: i checked the make documentation: "either `$(foo)' or `${foo}' is a valid reference to the variable foo.". so it's up to you.
[22:27] <SoftwareExplorer> bdrung: oh, ok
[22:59] <dooooomi> should new packages in REVU use standards-version 3.8.3 or 3.8.4? no matter which one i use, either my own or REVU's lintian will complain...
[22:59] <sebner> dooooomi: 3.8.4
[23:00] <dooooomi> sebner: thanks, i'll just ignore REVU's warning then...
[23:02] <sebner> dooooomi: yeah, it's a bit outdated, no worries
[23:10] <dooooomi> a new version of gtklick is ready to be reviewed: http://revu.ubuntuwire.com/p/gtklick
[23:14] <asbin> dooooomi: you can install new version of lintian from here https://launchpad.net/~bdrung/+archive/backports/+packages?field.name_filter=lintian&field.status_filter=published&field.series_filter=karmic
[23:15] <dooooomi> asbin: isn't it actually REVU that needs to install a newer version?
[23:16] <asbin> dooooomi: yes REVU server needs to be updated too ...