[00:02] <pochu> persia: so, if the package has one advocate, it gets a bulb. If then someone rejects it, it gets a hammer. When it's uploaded again, it gets a bulb again... until it gets another advocate and gets a heart. Is that right?
[00:02] <pochu> persia: and what would you expect if the package has 2 advocates (and thus a heart) and someone rejects it? o.O
[00:03] <jdong> pochu: hammertime!!
[00:03] <pochu> :)
[00:03] <jdong> couldn't resist
[00:04] <mok0> pochu: if it has 2 advocates, it gets uploaded...
[00:05] <Seveas> jdong, "can't upload this" dum-de-de-dum
[00:05] <pochu> mok0: usually, yes.
[00:18] <pochu> persia: new patch attached to bug 185133
[00:18] <ubotu> Launchpad bug 185133 in revu "Improve package images so that there is just one image per package" [Undecided,In progress] https://launchpad.net/bugs/185133
[00:20] <pochu> jdong: do you know transmission 1.02 is in debian unstable? I guess we could ask a sync, WDYT?
[00:20] <pochu> jdong: as there are no changes other than a new upstream...
[00:21] <Legendario> does anyone know what make error 1 is?
[00:25] <Kmos> pochu: yes, it's in debian.. you should request a sync of it
[00:26] <Kmos> it's installed now in hardy by default
[00:26] <pochu> jdong: I'll request it. Let me know if you disagree :)
[00:32] <Legendario> make erro 1. Any guess?
[00:37] <LaserJock> Legendario: that is nowhere near enough info to say anything about
[00:37] <LaserJock> Legendario: you need to pastebin the stuff that happened before the make error
[00:46] <RAOF> Dear PyPy.  You sound cool, but please build on amd64.
[00:50] <Legendario> LaserJock, here it is: http://paste.ubuntu-nl.org/53400/
[00:52] <LaserJock> Legendario: well, look at what it's telling you :-)
[00:52] <LaserJock> checking for PIDGIN... configure: error
[00:53] <nxvl_work> i think is a Build-Depends error
[00:54] <LaserJock> Legendario: does it make sense?
[01:02] <jdong> pochu: wait a sec don't sync yet
[01:03] <jdong> pochu: I want to review it, there was a tarball packing error with the initial 1.02 release; I feel more comfortable with the one I rolled
[01:06] <jdong> the orig tarballs are not the same
[01:07] <Legendario> LaserJock, yeah, it makes sence. it is building a pidgin plugin
[01:08] <LaserJock> Legendario: so do you have a build dependency on pidgin-dev ?
[01:08] <nxvl_work> does the Developer Sprint is taking place or this development circle there was no one?
[01:11] <jdong> pochu: I closed the sync ticket you opened for transmission; reasoning can be found on the bug report. I'll also poke debian about the situation.
[01:13] <vorian> how would a person go about tackling these issues? http://paste.ubuntu-nl.org/53402/
[01:13] <vorian> :)
[01:15] <RAOF> For the first two, you're using CDBS, yes?
[01:15] <StevenK> vorian: You have ${shlibs:Depends} not ${python:Depends} and you're calling dh_shlibdeps instead of dh_pycentral or dh_pysupport
[01:15] <vorian> RAOF: yes
[01:15] <vorian> ah!
[01:16] <vorian> thanks StevenK :)
[01:16] <wallyweek> is there anyone willing to review http://revu.ubuntuwire.com/details.py?package=sdlmame
[01:17] <wallyweek> please do it... it's been in revu since last february and I really like to see it in hardy :D
[01:24]  * wallyweek is sad to leave, but he *strongly* needs some sleep
[01:31]  * jdong fixes prevu's misuse of exceptions
[01:37] <schierbeck> does anyone here know how to get rid of an installed package whose uninstall-hook messes up?
[01:37] <pochu> jdong: hmm, if upstream rolled a new tarball, they should have done it with a version bump
[01:38] <pochu> jdong: alright, let's wait for 1.03 then
[02:00] <jdong> pochu: yeah, I agree that was bad judgement on their behalf
[02:00] <jdong> pochu: but meh what can you do; it's good enough already that they didn't say "deal with it"
[02:06] <pochu> jdong: yeah, but how would you know now whether someone has the good or the bad tarball offhand?
[02:06] <pochu> jdong: anyway nice to hear it's fixed.
[02:16] <jdong> pochu: well I compared md5sums first, then ./configure --help, look at mandir and infodir defaults. Correct ones say DATAROOTDIR/man and so on, incorrect ones say PREFIX/man. /usr/man is obviously not a good place for manpages ;-)
[02:25] <imbrandon> yea but it wont work with Core Audio i dont think , not sure, I'll try a new compile here tonight and see
[02:25] <imbrandon> err totaly wrong window
[03:42] <browndruid> So can anybody here help me get on my path toward Ubuntu development?
[03:42] <MarcC> what's the best way to get a GPL app put in the repos?
[03:43] <LaserJock> browndruid: that kinda vague. What are you interested in?
[03:43] <LaserJock> MarcC: well, packaging it. :-)
[03:43] <LaserJock> MarcC: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[03:43] <browndruid> I't not really totally sure. I have very little programming experience, so if there's somewhere you can point me to so I can start learning, I think that would be the best first step.
[03:44] <LaserJock> browndruid: you might want to have a look at https://wiki.ubuntu.com/UbuntuDevelopment/
[03:44] <LaserJock> well, you don't often need very much programming experience
[03:44] <browndruid> I've been reading the Development site.
[03:44] <browndruid> What kind of stuff would I do without programming experience?
[03:44] <LaserJock> well, anything you want
[03:44] <MarcC> thanks LaserJock
[03:45] <browndruid> Yeah, but if I don't know how to do it, then I can't.
[03:45] <LaserJock> browndruid: https://wiki.ubuntu.com/MOTU/TODO
[03:45] <LaserJock> browndruid: well, we don't really program
[03:45] <LaserJock> we package and take care of the archive
[03:46] <LaserJock> programming experience can be helpful when bug fixing, but even then there's a lot you can do
[03:46]  * jdong smiles...
[03:46] <jdong> I'm going to hell for this one :)
[03:46] <LaserJock> uh oh
[03:46] <jdong> LaserJock: don't worry, it's ony on my personal computer :)
[03:46] <imbrandon> you rick rolled someone ?
[03:47] <jdong> I kinda reinvented module-assistant
[03:47] <browndruid> Well, I guess I'll be on my way!
[03:47] <LaserJock> devil!!!
[03:47] <LaserJock> browndruid: why?
[03:47] <LaserJock> browndruid: do you wanna help or ?
[03:47] <browndruid> so i can start on the whole learning what i need to do thing.
[03:47] <jdong> a deb package that in postinstall unpacks and recompiles madwifi-ng if it isn't probed in the running kernel...
[03:47] <browndruid> Yeah, I want to help.
[03:47] <LaserJock> browndruid: this is a great place to learn
[03:47] <jdong> I was tired of recompiling madwifi on every kernel update.
[03:48] <jdong> I'm sure I broke some holy rules of deb packaging :)
[03:50]  * imbrandon waits for someone to package the wow installer + custom wine
[03:50] <imbrandon> that would suck and rock , both
[03:51] <jdong> imbrandon: I see dist-upgrader does --force-{some,all,etc} during release and partial upgrades now, so.... what's the harm in that ;-)
[03:51] <imbrandon> heh, thus why i stick to apt-get
[03:52] <imbrandon> if you cant apt-get dist-upgrade , something is broke imho
[03:52] <jdong> imbrandon: personally, I wonder if a lot of dist-upgrader's jobs should be somehow worked into the metapackages
[03:52] <imbrandon> jdong: they should imho
[03:53] <jdong> bleh I just drank rubbing alcohol
[03:53] <imbrandon> the time it takes to "fix" it in dist upgrader could easily be added to the packages
[03:53] <jdong> don't keep open bottles of water and alcohol close by
[03:53] <imbrandon> but thats just me personaly
[03:54] <jdong> imbrandon: I agree, I don't see much of a technical reason why it couldn't be a part of a package's pre/post* scripts
[03:55] <ScottK> imbrandon: Up for sponsoring a Kubuntu merge?  It's Bug #185754.
[03:55] <ubotu> Launchpad bug 185754 in sip4-qt3 "Please merge sip4-qt3 4.7.3-1  (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/185754
[03:55] <ScottK> I'm working on python-qt4 merge right now and that one needs to go first.
[03:55] <imbrandon> ScottK: sure give me a few to dig out my usb key ( gpg ) and i'll have a look
[03:56] <MarcC> can somebody tell me how this looks as a needs-packaging bug?
[03:56] <MarcC> https://bugs.launchpad.net/ubuntu/+bug/185810
[03:56] <ubotu> Launchpad bug 185810 in ubuntu "Art of Illusion - Easy to use 3D modeling studio" [Undecided,New]
[03:56] <ScottK> imbrandon: Great.
[03:57] <Legendario> LaserJock, sorry. i had to go away for a couple hours. Do you mind if we go back a little. I have the build dependencies for it. I have the pidgin-dev installed and when i run the configure script for the program i am trying to build a debian package, it says to me that everything is ok.
[03:58] <LaserJock> k
[03:59] <imbrandon> MarcC: looks fine as far as a request
[04:00] <MarcC> ok, thanks imbrandon
[04:02] <imbrandon> ScottK: is that a debdiff against the debian or ubuntu source, dosent look like the patch applies to the hardy ubuntu
[04:06] <ScottK> imbrandon: debdiff against debian
[04:06] <imbrandon> ScottK: got it
[04:14] <jdong> debiandiff :)
[04:14] <jdong> diffbuntu
[04:14] <freakabcd> hi all
[04:14] <jdong> I coin those two terms!
[04:14] <freakabcd> can I bug someone to update the octave package on hardy? and subsequently gutsy?
[04:14] <freakabcd> debian's got source packages for those in sid
[04:15] <freakabcd> http://packages.debian.org/sid/octave3.0
[04:15] <jdong> freakabcd: Hardy's easier to argue than gutsy currently
[04:15] <jdong> freakabcd: see bug #185653
[04:15] <ubotu> Launchpad bug 185653 in octave3.0 "[MoM SYNC] octave3.0 3.0.0-1" [Undecided,Confirmed] https://launchpad.net/bugs/185653
[04:15] <jdong> it's already been put in the queue
[04:15] <jdong> freakabcd: once it's in hardy we can talk gutsy-backports
[04:16] <Legendario> gotta go
[04:16] <freakabcd> ah, cool
[04:16] <Legendario> will be back tomorow though
[04:16] <ScottK> jdong: But those backports guys are crazy.
[04:16] <jdong> ScottK: yeah I know ;-)
[04:16] <freakabcd> well, it doesn't need to be a backport
[04:16] <freakabcd> it could be a proper gutsy release
[04:16] <jdong> ScottK: that's why people should make a website where anyone can upload and share the debs they create
[04:17] <jdong> freakabcd: that is not in line with the update policy for released distributions
[04:17] <freakabcd> because, the deb octave list have still not moved to gfortran based dependencies
[04:17] <LaserJock> I didn't think we were doing Octave 3.0 yet
[04:17] <freakabcd> LaserJock, deb has packages already. trivial to get them on hardy
[04:17] <LaserJock> freakabcd: not exactly
[04:18] <jdong> LaserJock: well \sh pulled the trigger ;-)
[04:18] <LaserJock> we were thinking of leaving 3.0 out of Hardy perhaps
[04:18] <freakabcd> no way
[04:18] <LaserJock> as we weren't sure of the upgrade path
[04:18] <freakabcd> you mean the octave modules issue?
[04:19] <freakabcd> please follow debian's footsteps in this matter. they already have 3.0 released. providing binary modules isn;t too much of a priority anyway.
[04:19] <freakabcd> the next step they are already working on is to move away from f77 and onto gfortran
[04:19] <LaserJock> well, we can't just follow Debian in all cases
[04:19] <LaserJock> we have to take care of our users as well
[04:20] <LaserJock> Debian dropped the octave binary
[04:20] <freakabcd> they dropped binary octave modules?
[04:20] <LaserJock> no
[04:20] <freakabcd> what did they drop then?
[04:20] <LaserJock> the metapackage
[04:21] <LaserJock> we were going to do some upgrade testing first
[04:21] <freakabcd> obviously. their reasoning was that this time when someone installs 'octave' they get exactly that 'octave' nothing more like the binary octave modules, etc.
[04:22] <ScottK> jdong: I did have a pleasant IRC conversation with someone I'm working on a project with.  He mentioned he was getting more spam.  I asked him if he'd upgraded to spamassassin 3.2.4 yet.  He said no, he guessed he'd have to build from source (he's got a feisty server).
[04:22] <ScottK> I thoroughly enjoyed being able to say no, it's in feisty-backports.  Just install it.
[04:23] <LaserJock> heh
[04:23] <jdong> ScottK: :)
[04:24] <LaserJock> well, perhaps we should have emailed -motu about Octave 3.0
[04:24] <freakabcd> well, they need to include 3.0 atleast in hardy.
[04:24] <LaserJock> we'll see
[04:24] <freakabcd> how far away are we from freeze?
[04:25] <LaserJock> hopefully
[04:25] <LaserJock> Feb 14th
[04:26] <freakabcd> wow, not too much time. hope the 'octave guy' here updates to 3.0
[04:26] <LaserJock> well of course I want to
[04:26] <freakabcd> i forgot his name; was kind enough to update the 2.9 package from the ancient .12
[04:27] <LaserJock> well, nobody has filed a sync bug that I know of
[04:27] <freakabcd> https://bugs.launchpad.net/ubuntu/+source/octave3.0/+bug/185653
[04:27] <freakabcd> that one?
[04:27] <ubotu> Launchpad bug 185653 in octave3.0 "[MoM SYNC] octave3.0 3.0.0-1" [Undecided,Confirmed]
[04:27] <ScottK> freakabcd: You can look it up in the package info on Launchpad
[04:27] <jdong> LaserJock: I just linked to one!
[04:27] <LaserJock> bah
[04:27] <freakabcd> lol
[04:27] <LaserJock> stupid LP
[04:28] <LaserJock> I did a search and nothing came up
[04:28] <freakabcd> what is MoM sync ?
[04:28] <jdong> LaserJock: it's filed under octave3.0 somehow
[04:28] <imbrandon> Merge-o-Matic
[04:28] <jdong> LaserJock: even though that package should be -ENOENT
[04:28] <LaserJock> freakabcd: MoM is merge-o-matic
[04:28] <jdong> I don't get Launchpad anymore
[04:29] <freakabcd> ah, interesting acronym
[04:29] <LaserJock> alright so maybe I should set it to Incomplete at the moment and leave a note
[04:29] <freakabcd> damn, i don't have hdd space to mess around with hardy :(
[04:29] <AnAnt> persia: ping
[04:31] <freakabcd> whats with the tags on LP on the left?
[04:31] <freakabcd> there is a tag '1680x1050' i clicked on it and there are no results
[04:32] <jdong> Maybe we can use them like slashdot tags ;-)
[04:32] <imbrandon> freakabcd: means what ever was using it is no longer
[04:32] <freakabcd> lol, it was searching for 1680x1050 with the octave-3.0 domain
[04:32] <imbrandon> LaserJock: UW search works much better than LP search in most cases :)
[04:32] <freakabcd> thats funny
[04:34] <LaserJock> hmm, well if minghua shows up we can discuss it
[04:34] <imbrandon> ( LaserJock and even has a FF plugin hehe )
[04:49] <LaserJock> freakabcd: it may be we just need to patch octave3.0 to build the octave metapackage
[04:50] <freakabcd> cool. that would be great.
[04:53] <freakabcd> LaserJock, i'm not on my ubuntu box at the moment. what packages does the octave metapackage install? the headers, emacsen, etc. ?
[04:54] <LaserJock> well, octave3.0 itself too
[04:55] <freakabcd> great. i hope to see 3.0 packages in gutsy too :D
[04:55] <freakabcd> then i can start messing around with providing binary packages for the octave-forge modules
[04:56] <LaserJock> no, they won't be in gutsy
[04:56] <LaserJock> I don't think there would be a way to do that outside of maybe a PPA
[04:56] <freakabcd> you mean the backport guys will refuse to backport it?
[04:56] <LaserJock> I believe so, there's too much that depends on it
[04:56] <LaserJock> you'd have to backport probably like 20-30 packages I'm guessing
[04:57] <ScottK> LaserJock: Kind like with clamav, right?
[04:57] <LaserJock> at least ;-)
[04:57] <LaserJock> and without the justification
[04:58] <freakabcd> wait a minute.. 2.9.19 from hardy hasn;t been backported to gutsy
[04:58] <freakabcd> !! why?
[04:58] <ubotu> Sorry, I don't know anything about why? - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[04:58] <LaserJock> freakabcd: we don't just backport everything
[04:59] <freakabcd> ok, i'm going to get the source package for 2.9.19 from hardy and backport it to gutsy.
[04:59] <freakabcd> i will assume it is trivial. and let you guys laugh at me tomorrow at my failure :D
[05:00] <freakabcd> LaserJock, what makes me believe it is trivial is that none(that i know) of the deps have updated releases
[05:01] <LaserJock> well
[05:01] <ScottK> freakabcd: If it build/installs/runs on Gutsy, you can ask for a backport.  File the bug in the gutsy-backports project.
[05:01] <LaserJock> "what can be done by rebuild from source" is different than "building with the archive and making everything happy"
[05:01] <freakabcd> ok, cool. i will mess with it tonight.
[05:02] <freakabcd> i should setup a build environment, right?
[05:02] <jdong> pbuilder
[05:02] <jdong> slomo!!!! Just the developer I needed to speak to :)
[05:02] <freakabcd> i finally managed to free some space. about 2G should be enough, right?
[05:02] <jdong> (not really, just trying to scare you)
[05:03] <jdong> freakabcd: octave's big, isn't it?
[05:03] <jdong> when you add in the build-deps
[05:03] <freakabcd> lol, no. i meant for the pbuilder environment thingy
[05:03] <freakabcd> i hate building atlas. that thing compiles for years
[05:04] <jdong> freakabcd: pbuilder's base.tgz for hardy takes like 50MB
[05:04] <jdong> freakabcd: the problem is that the unpacked build environment is the size of apt-get build-dep octave plus a bit more
[05:04] <jdong> and unless you have magical space (i.e. tmpfs) it won't be happy with 2GB most likely
[05:05] <freakabcd> jdong, what if i have the _binary_ deps installed and the deps_dev packages installed too?
[05:05] <freakabcd> i won;t need to rebuild the deps from src, right?
[05:05] <LaserJock> no
[05:05] <LaserJock> but you want a pbuilder for that
[05:05] <jdong> freakabcd: pbuilder is a self-isolated environment
[05:05] <jdong> freakabcd: what you have installed in your main system is irrelevant
[05:06] <jdong> freakabcd: pbuilder will make a temporary chroot and bootstrap it, and install all build-deps via apt-get in that environment, then destory it once it's done building
[05:06] <LaserJock> jdong: unless it's maybe Windows, I've not seen anybody run pbuilder off of Windows ;-)
[05:06] <freakabcd> lol LaserJock
[05:06] <LaserJock> I gotta run for a bit
[05:06] <LaserJock> bbl
[05:06] <jdong> LaserJock: haha cygwinbuntu? :D
[05:07] <LaserJock> lol
[05:07] <freakabcd> jdong, damn. so i need a lot more than 2G for a base-system + installing octave deps, then compiling octave-3.0
[05:07] <freakabcd> thats what you are saying, right
[05:07] <freakabcd> ?
[05:07] <jdong> freakabcd: it would seem that way in my humble opinion
[05:08] <jdong> freakabcd: do you have a large RAM+swap you're not using?
[05:08] <freakabcd> ok, i'll try to free up more space tonight.
[05:08]  * jdong puts on his hack hat
[05:09] <freakabcd> i've got a 2G swap and 1.25G RAM. and 2G free space at the moment. if my simple calculations are correct i will be around 6G free hdd space
[05:09] <jdong> :)
[05:09] <jdong> it looks like unionfs hacking time ;-)
[05:09] <jdong> stitch all your random free space together!
[05:09] <jdong> frankenstein mountpoint
[05:10] <StevenK> jdong: So unionfs doesn't work because it needs hundred year old bolts?
[05:10] <freakabcd> lol, frankenspace
[05:11] <jdong> StevenK: is that why frankenstein failed?
[05:11] <StevenK> Hah
[05:11] <jdong> :)
[05:30] <gQuigs> can I confirm my own needs-packaging bug (185804) or does it need something else?
[05:30] <gQuigs> https://bugs.launchpad.net/ubuntu/+bug/185804
[05:30] <ubotu> Launchpad bug 185804 in ubuntu "[needs-packaging] BadRAM Linux Kernel Patch" [Undecided,New]
[05:30] <LucidFox> gQuigs> triaged
[05:31] <ScottK> imbrandon: How did the merge look?
[05:31] <gQuigs> thanks LucidFox
[05:34] <imbrandon> ScottK: looks fine, should have it uploaded here very shortly
[05:34] <ScottK> imbrandon: Thanks.
[06:38] <warp10> Heya all
[06:52] <Aloha> warp10, hi
[06:52] <warp10> Hi Aloha
[07:06] <freakabcd> guys, can someone check libsuitesparse in hardy? I'm still on gutsy and had libsuitesparse installed before. now, i tried to install libumfpack and it conflicted with some files from libsuitesparse (amd)
[07:07] <freakabcd> i don;t much care about this problem, but i thought it must be checked in hardy. why doesn;t just libsuitesparse install libumfpack?
[07:07] <freakabcd> since it is supposed to be providing umfpack
[07:15] <minghua> freakabcd: Why do you think it's a problem?  AFAIR libsuitesparse _should_ conflict with libumfpack.
[07:16] <freakabcd> really? why would that be? also why would it tell me during the installation phase that it conflicts?
[07:16] <freakabcd> it should have known that once i selected the package in synaptic
[07:17] <LucidFox> How do I stop CDBS from turning debian/changelog files into symlinks in dependent packages?
[07:17] <freakabcd> minghua, would you be able to tell me how much b/w will be consumed for me to setup a pbuilder env?
[07:18] <minghua> freakabcd: I only have hardy here.  And it seems there is simply no libumfpack4 in hardy.  I'm checking the situation in gutsy.
[07:19] <minghua> freakabcd: As for the bandwidth question, I don't really know.  For a minimal pbuilder it shouldn't be much, but you can't do much about the pbuilder either.
[07:24] <minghua> freakabcd: Yes, there is a bug in gutsy's libsuitesparse package, it should Conflict and Replace libumfpack4 but doesn't.
[07:25] <ScottK2> LucidFox: You don't
[07:25] <minghua> freakabcd: Actually, there is bug 144171.
[07:25] <ubotu> Launchpad bug 144171 in suitesparse "package libsuitesparse 3.0.0-3 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/144171
[07:25] <ScottK2> LucidFox: This is a feature of Ubuntu's cdbs that Linitian isn't aware of.
[07:26] <LucidFox> so I should add a Lintian override?
[07:26] <LucidFox> or just leave it alone?
[07:26] <minghua> What am I suppose to do with the bug?  It's fixed in hardy.  Just label it "Fix released"?
[07:26] <LucidFox> minghua> yes
[07:26] <ScottK2> LucidFox: I'd file a bug against lintian.
[07:30] <Aloha> if i rename postinst.ex to postinst does it automatically use it in the package or do i need to add a line somewhere?
[07:33]  * minghua reads the bug again and decides to mark it incomplete because the report didn't say why it failed to install...
[07:33] <minghua> Aloha: It's automatic.
[07:33] <Aloha> minghua, thnx
[07:34] <minghua> Or perhaps, it's automatic if you use debhelper/CDBS/etc.
[07:38] <Aloha> is there a way to interactively edit the changelog?
[07:41] <minghua> dch/debchangelog
[07:41] <minghua> debchange*
[07:42] <ScottK2> minghua: It's automatic for cdbs.  For debhelper you need to call (I think it's) dh_installinit in debian/rules.
[07:43] <minghua> ScottK2: Are you sure?  It's postinst, not init script.  I think either dh_control or dh_installdeb deals with postinst.  Both of which should be mandatory.
[07:44] <ScottK> minghua: Sorry.
[07:44] <ScottK> It's almost 3AM here.
[07:44] <minghua> ScottK: :-)  It's dh_installdeb BTW.
[07:44] <ScottK> I think it's automatic then.
[07:44] <ScottK> Ah.
[07:44] <minghua> Also, there is no dh_control, only dh_gencontrol.
[07:47] <freakabcd> minghua, so on gutsy. i just installed pbuilder.
[07:47] <freakabcd> to create the environment, i just go: pbuilder --create ?
[07:48] <minghua> freakabcd: Pretty much.  There are some configurations you may want to set, though.  I am not really an expert on pbuilder creation.
[07:52] <freakabcd> minghua, where will this env be stored on my computer?
[07:53] <freakabcd> well, it will be persistent, right? i don;t want to do this every time i try to test out building new src packages
[07:53] <minghua> freakabcd: ~/.pbuilderrc.  You should read pbuilder(8) man page first.
[08:30] <slytherin> Hi all. Can anyone point me to nautilus extension library api docs?
[08:31] <techno_freak> slytherin, i tested that package and it messed up things, i had to reinstall nautilus
[08:31] <slytherin> techno_freak: There was no need to reinstall. You just had to remove the package. :-)
[08:31] <techno_freak> i made a stupid mistake of saving the error message there itself, i deleted the image without noting it
[08:32] <slytherin> techno_freak: I mean the open-terminal package
[08:32] <techno_freak> slytherin, oh, i just did apt-get install --reinstall nautilus
[08:53] <Aloha> does MOTU add packages to universe that are created by LoCo teams?
[09:13] <superm1> persia, how verbose are you setting your lintian?  I set it to what you had mentioned to me some time back in my bashrc, but still seem to not be catching things you are catching
[09:19] <wallyweek> hi folks! :)
[09:19] <\sh> moins
[09:20] <Kmos> superm1: are you using lintian -ivI ?
[09:20] <vemon> is there and example for packaging .desktop files?
[09:20] <Kmos> vemon: yes..
[09:20] <Kmos> !packaging | vemon
[09:20] <ubotu> vemon: The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
[09:20] <wallyweek> I've added a watch file to sdlmame, I think it could receive advocation now, could anyone please have a look at it? http://revu.ubuntuwire.com/details.py?package=sdlmame
[09:21] <\sh> minghua, ping
[09:21] <vemon> Kmos, the packaging guide has a chapter of packaging desktop files for KDE apps but does that also apply for Gnome applications?
[09:22] <\sh> minghua, bug #185653 what do you think about the idea in my comment?
[09:22] <ubotu> Launchpad bug 185653 in octave3.0 "[MoM SYNC] octave3.0 3.0.0-1" [Undecided,Incomplete] https://launchpad.net/bugs/185653
[09:22] <vemon> and is there a "cdbs way" to do it?
[09:22] <\sh> moins raphink :)
[09:22] <vemon> like just adding the file to say... debian/desktop.files
[09:23]  * wallyweek feels downhearted as sdlmame is in revu since last february and still can't find his way to multiverse :(
[09:23] <Kmos> vemon: cdbs do it automatically, catches for .desktop files
[09:23] <raphink> hi \sh
[09:23] <Kmos> vemon: https://wiki.ubuntu.com/PackagingGuide/SupplementaryFiles
[09:23] <raphink> what's up \sh?
[09:24] <vemon> Kmos, so if the .desktop files are in the root of the package they are installed? do i need a specific cdbs import/include for this?
[09:24] <Kmos> vemon: no, you don't.. but try to learn cdbs manual..
[09:24] <Kmos> !cdbs | vemon
[09:24] <ubotu> Sorry, I don't know anything about cdbs - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[09:24] <slytherin> is it ok to full fix fro a bug from upstream svn?
[09:25] <vemon> Kmos, thanksfor the SuppFiles -link! haven't seen that page before
[09:25] <raphink> slytherin: how do you mean?
[09:26] <slytherin> raphink: I mean I check the SVN diff and create a patch for those fixes in Ubuntu package.
[09:26] <raphink> yes it's ok slytherin, as long as  you include the patch properly
[09:26] <\sh> raphink, waiting to start my new job :) what about you still happy at your place?
[09:26] <raphink> using dpath, quilt or cdbs's simple-patchsys
[09:26] <raphink> \sh sure :)
[09:26] <raphink> I'm fine, still having fun
[09:27] <raphink> there's tons of things to do here :)
[09:27] <vemon> Kmos, the functionality i'm looking for seems to be in gnome.mk. thanks again!
[09:27] <raphink> and I'm taking a week of vacation in the moutains in family next week :)
[09:27] <slytherin> raphink: The fixes are just few lines. So it will be fine. There is a bug fixed in SVN, but the fix for that touches many files so I am not pulling that.
[09:27] <raphink> slytherin: although it might sometimes be worth considering a full upgrade of the package if a good amount of fixes were added
[09:28] <raphink> slytherin: ok
[09:28] <raphink> slytherin: if you know exactly the few lines to patch, then create a patch just for that
[09:28] <raphink> slytherin: just keep in mind that each patch that is added has to be maintained/merged in the future
[09:28] <raphink> and that adding a patch system to a pacakge if it doesn't exist yet makes it harder to maintain
[09:30] <slytherin> raphink: It is already using cdbs patch system. So that is not a problem. The bug for which I am pulling in the fix from SVN makes the package unusable in hardy. That's why this urgency. I will send email to maintainer asking when he plan to do new release.
[09:30] <Kano> hi, did openscenegraph compile with libxine-dev?
[09:30] <raphink> slytherin: in this case, go for it :)
[09:30] <Kano> i dont see an updated package yet...
[09:31] <raphink> \sh what is your new job?
[09:33] <\sh> raphink, building a new datacenter infrastructure :)
[09:33] <raphink> ah nice :)
[09:33] <raphink> what tools are you using this time?
[09:34] <minghua> \sh: Commented on bug #185653.
[09:34] <ubotu> Launchpad bug 185653 in octave3.0 "[MoM SYNC] octave3.0 3.0.0-1" [Undecided,Incomplete] https://launchpad.net/bugs/185653
[09:34]  * wallyweek is not away, it's only unable to tell this stupid online irc client not to disconnect him 
[09:34] <raphink> wallyweek: make a cron to wake up your irc client every 5 minutes? ;)
[09:35] <wallyweek> raphink: that would be good but I'm on mibbit web client as proxy doesn't allow irc protocol at work :(
[09:38] <Kano> hmm, debian maintainers really skip always needed builddep for media players...
[09:38] <Kano> even when i mail em
[09:38] <raphink> wallyweek: how about using a transport agent with a jabber client or so?
[09:41] <\sh> minghua, there is a mistake in your comment ... Package: octave3.0 \n Provides:  Provides: octave,octave2.9 \n Replaces: octave (<= 2.0.16-2),octave2.9 \n Conflicts: octave (<= 2.0.16-2),octave2.9
[09:41] <wallyweek> raphink: I've no practice with such a thing, I'll have some googling about it, thanks! :)
[09:41] <\sh> minghua, and I would like to recheck that octave3.0 will not break any other octave using sources...
[09:41] <raphink> wallyweek: get a jabber client (Kopete, Pidgin, etc.)
[09:42] <raphink> wallyweek: get a jabber account on a server with IRC agents (jabber.fr does that for example)
[09:42] <slytherin> Kano: How come the packages compile then?
[09:42] <minghua> \sh: Which part of my comment is mistaken?
[09:43] <Kano> slytherin: they work but you dont have full features
[09:43] <Kano> like missing output plugins for mplayer
[09:44] <slytherin> Kano: Then upstream authors make the dependencies essential instead of optional
[09:44] <Kano> you miss dxr3    DXR3/H+ video out when you forget em8300-headers
[09:44] <\sh> minghua, that they are parallel installable..but I should read all comments...sry
[09:44] <Kano> slytherin: but even in the description of the package is DXR3 support mentioned...
[09:44] <minghua> \sh: Good that we agree, then. :-)
[09:46] <\sh> minghua, well, as I said, I'm doing some tests now: 1. upgrade tests 2. rebuilding all sources which are directly build-depending on octave2.9/octave , against octave3.0 and 3. prepare a list of packages which are depending indirectly on octave2.9
[09:47] <minghua> \sh: Sounds a good plan.  Also, according to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457675 all but one package have migrated to octave3.0 in Debian.
[09:47] <ubotu> Debian bug 457675 in octave2.9 "RM: octave2.9 -- RoM; superseded by octave3.0" [Normal,Open]
[09:48] <minghua> \sh: Altough there is probably a chicken an egg problem in hardy.  We can't start migration without octave3.0 in archive, but once we starts octave metapackage will be broken.
[09:49] <\sh> minghua, this is not a problem...
[09:49] <minghua> \sh: So it seems we need to get it done altogether.
[09:49] <\sh> minghua, as I'm preparing the build-dep list and rdepends list I can prepare all packages to use octave3.0/octave and push a rebuild on our buildds
[09:50] <\sh> minghua, just like libgif transition ;)
[09:50] <minghua> \sh: Good, good, go ahead and good luck. :-)
[09:50] <\sh> minghua, but now: just a bunch of packages at one time :)
[09:58] <slytherin> I am getting this error when trying to build a package. - aclocal: configure.in: 18: macro `AM_PROG_LIBTOOL' not found in library. Can anyone help?
[10:00] <TheMuso> slytherin: You need to install libtool
[10:00] <DaveMorris> persia: Thanks for reviewing the package, couple of questions.  What am I patching in the bare diff.gz that should be moved to debian/patches?
[10:02] <slytherin> TheMuso: Why was it not needed before?
[10:03] <TheMuso> slytherin: What do you mean why was it not needed before?
[10:03] <slytherin> TheMuso: I am modifying existing package
[10:03] <TheMuso> slytherin: And? Sorry I wasn't reading prior IRC conversations, I just saw your error.
[10:04] <slytherin> TheMuso: Yes that is the only information I have to give. I am getting this error when I am trying to fix a bug in nautilus-open-terminal
[10:05] <TheMuso> slytherin: What did you run? Autogen?
[10:05] <minghua> slytherin: What did you change?  Did you change configure.in or Makefile.ams?
[10:05] <TheMuso> autogen.sh even
[10:06] <slytherin> minghua: TheMuso: I changed configure.in
[10:07] <TheMuso> slytherin: Right, in that case, you need to regenerate the configure script .Usually packages have a build.sh, or autogen.sh to do this.
[10:08] <TheMuso> Thats when you need libtool and other bits like autoconf/automake.
[10:10] <jonnymind_work> Hello
[10:11] <slytherin> TheMuso: So should I simply add libtool to build dependency? or should I generate configure script locally (outside pbuilder)
[10:12] <Kano> i would do all steps in the package itself
[10:12] <Kano> do not patch added files as those are with wrong permissions
[10:12] <Kano> that will not work inside pbuilder
[10:13] <jonnymind_work> ScottK has recently declared http://revu.tauware.de/details.py?package=falconpl (Bug 174470) as clear from conflicts. I am searching for MOTUs willing to review it.
[10:13] <ubotu> Launchpad bug 174470 in ubuntu "[needs-packaging] Falcon Programming Language" [Wishlist,In progress] https://launchpad.net/bugs/174470
[10:13] <TheMuso> slytherin: The approach you take depends on how the package gets built, whether it uses a patch system, and whether extra patching is part of the package diff already.
[10:14] <slytherin> TheMuso: it alread uses cdbs patch system. I had modified both configure.in and configure to change version of nautilus. I am wondering if I should drop this change since in hardy anyway I will get latest version.
[10:16] <TheMuso> slytherin: Yeah cdbs does replace those files.
[10:41] <emgent> moin
[10:49] <pochu> hey there!
[10:50] <effie_jayx> pochu,  congrats on your MOTU aceptance
[10:51] <pochu> thanks effie_jayx :) you're a bit late, btw ;)
[10:51] <effie_jayx> pochu,  I know, I just read it on the monthly report
[10:52] <pochu> Ah
[10:55] <persia> superm1: I use lintian -iIv and linda -v -f long -t E,I,W,X, but those are only a subset of my review checks.
[10:56] <lifeless> so, I don't upload enough
[10:56] <persia> DaveMorris: lsdiff -z file.diff.gz will give you a list
[10:56] <lifeless> whats the current syntax for closing an lp bug in changelog? (closes: or lp: or ... ?)
[10:56] <persia> lifeless: I like (LP: #nnnnnn)
[10:57] <persia> lifeless: Further, I don't like "closes:" as even if someone does the magic to make it work with changes-closes-bug, it looks too similar to Debian.
[11:00] <broonie> persia: There was some talk of an overarching, integrated closes: syntax that everyone could use.
[11:01] <persia> broonie: That sounds really nice.  I just prefer to avoid confusion until then.  One of the frustrating bits about using LP is that there are frequently closed bugs that appear as open, although they were fixed in Debian, and since pulled into Ubuntu.  A unified syntax should also help reduce those.
[11:02] <slytherin> persia: FYI ... Yesterday's fix to nautilus-open-terminal was not good enough. It was crashing nautilus. :-( I have ported fix from SVN in form of a patch. I will upload the debdiff with sufficient testing.
[11:04] <persia> slytherin: Thanks for taking the extra steps to make it right :)
[11:08] <amarillion> norsetto, thanks for your comments on speed-game. However, I think you're wrong regarding the use of /var/games
[11:09] <amarillion> I think hiscore files are supposed to be in /var/games
[11:10]  * persia confirms that hiscore files are supposed to be in /var/games, but notes that they should not be included in the package, as that resets them on each upgrade: better to touch the file if it doesn't previously exist in the postinst
[11:11] <amarillion> yeah right, that is what my package does atm
[11:11] <amarillion> This was the comment: "4) The use of /var/games/speed-game.rec to save hiscores doesn’t seem appropriate. It would be better to save it in a local file owned by the user (ie. in a dotted file in $HOME). Note that this would not need to be removed by a postrm script."
[11:16] <persia> amarillion: I disagree with that.  Especially so as it breaks competitive scoring for multiuser systems, defeats the entire point of setting score files as root.games 664, and differs from most other games in the distribution.
[11:16] <amarillion> ok, that's what I thought
[11:17] <persia> amarillion: Cite Debian Policy 11.11 in your rebuttal, if you like
[11:19] <DaveMorris> persia: did you catch my question?
[11:19] <persia> DaveMorris: Yep.  Did you see my answer?
[11:19] <DaveMorris> no I had gone, let me see the logs
[11:19] <DaveMorris> !logs
[11:19] <ubotu> Channel logs can be found at http://irclogs.ubuntu.com/ - Logs for LoCo channels are at http://logs.ubuntu-eu.org/freenode/ - See also « /msg ubotu ircstats »
[11:19] <persia> (lsdiff -z diff.gz lists all files adjusted)
[11:23] <DaveMorris> persia: I can only see files in /debian adjusted, no others
[11:23]  * persia looks again
[11:31] <persia> DaveMorris: Sorry about that.  Obviously this is a case of me commenting before being fully awake.  I'm still not advocating because of 7, and would really like to see 4 & 5.  #6 was done while I was commenting.  #2 is upstream, and #3 is just a preference.
[11:32] <DaveMorris> 3 will get better when upstream fix alot of the things I'm patching, for instance the make clean rules
[11:32] <DaveMorris> done 4, 7 just about to do 5
[11:32] <persia> DaveMorris: OK.  If you expect it to get nice and short again, doesn't make sense to change it.
[11:32] <DaveMorris> yeah the big problem is you can't patch a make clean rule
[11:33] <DaveMorris> as patch are removed before calling make clean
[11:33] <persia> DaveMorris: There are ways around that, but most of them are even uglier :)
[11:34] <DaveMorris> I assume you agree that a watch file won't work with the way they currently release the source?
[11:34] <persia> DaveMorris: Yes.  You might be able to craft a working get-orig-source though, which would help for the hardy+1 merge cycle.
[11:35] <DaveMorris> tbh for hardy +1 I will have hopefully got them to do a new release which can have a watch file etc
[11:36] <persia> DaveMorris: That works too.  I'm mostly worried because about 60% of REVU packages don't get updated in the following release without some sort of automated mechanism.  If you're committing to getting it fixed, it's less of a worry.
[11:36] <DaveMorris> persia I use it as part of the research we do at work.  So it's in my interest as well
[11:37] <DaveMorris> persia: http://pastebin.ca/871916 that a correct copyright file now?
[11:37] <persia> DaveMorris: No.  Still doesn't say who holds copyright.
[11:38] <persia> To me, there are six interesting things that are kept in Debian copyright, as follows:
[11:38] <persia> 1) The person who created the packaging, and the date they did that.  This isn't a legal requirement, but helps identify a person who may have a relation with upstream.
[11:39] <persia> 2) The location from which the updated source can be downloaded (although I also like to see this in a watch file or get-orig-source rule)
[11:39] <persia> 3) Any licensing for the packaging.  Typically this is the same as for the package, unless the packaging was copied from another package with a more restrictive license.
[11:40] <persia> 4) The names of any upstream authors.  This is mostly to give credit where it is due.
[11:40] <persia> Beyond that, we have two legal requirements, as follows:
[11:41] <persia> 5) Identification of the copyright holder(s).  These are the people ultimately responsible for the licensing of the work, although they may have granted the right to sublicense to other parties.
[11:42] <persia> 6) Description of the license under which the work is being distributed.  This is typically the full text of the license, but may be a shorter form for some common licenses (e.g. GPK, LGPL, etc.).
[11:43] <wallyweek> persia: why not publish this on the packaging guide? it would be of great help
[11:44] <persia> wallyweek: Good idea.  Would you might doing a copy & paste with appropriate spelling and grammar corrections?
[11:44] <persia> s/might/mind/
[11:46] <wallyweek> persia: I would if I was able to... I'm not english mother tongue and I think I can't update the web page
[11:47] <DaveMorris> persia: something like this then http://pastebin.ca/871930
[11:47] <persia> wallyweek: If you have an LP account, access to wiki.ubuntu.com is really easy, and shouldn't require any human assistance.  Don't worry about the spelling anf grammar too much: if you pull out the obvious typos, it would be great :)
[11:48] <amarillion> According to http://doc.ubuntu.com/ubuntu/packagingguide/C/sect-contributing.html, you have to do a bug report first
[11:49] <amarillion> sounds like a good way for your contribution to land in a black hole
[11:50] <persia> DaveMorris: From a cursory look through the output of `grep -ri copyright *`, it looks about right.  Best to take a closer look to make sure that covers everything.
[11:50] <wallyweek> amarillion: I see. I thought packaging guide was motu's responsibility :(
[11:51] <amarillion> I've got a lot of notes that I could add too... but it seems the process is very complicated
[11:51] <persia> wallyweek: Well, keeping it in shape is the responsibility of all developers, whether Contributors, MOTU, or core.  MOTU tend to be the ones who work on it most, but that's just coincidence.
[11:52] <warp10> persia: May I suggest to add a link to http://wiki.debian.org/DFSGLicenses too? I found that page essential when tackling copyright and license issues.
[11:52] <amarillion> Who is writing the packaging guide actually?
[11:53] <persia> amarillion: That's a great resource!  Nice find.  Please do.
[11:53] <wallyweek> sorry! there's been come connection error :(
[11:53] <persia> amarillion: It's a collaborative work.  Most of the transition from the packaging-guide package to the wiki was done by Daniel, so his name appears in the history a lot, but there were many contributors to the content.
[11:54] <amarillion> Yeah, but it's not really a wiki, is it? At least I can't edit it directly
[11:54] <persia> amarillion: Erm.  Are you looking at the latest packaging guide?
[11:54] <persia> !packaging
[11:54] <ubotu> The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
[11:55] <DigGo> hello
[11:55] <DigGo> someone know how to deupgrade to gutsy ? now i'm in hardy.
[11:56] <Hobbsee> DigGo: reinstall.
[11:56] <DigGo> argh
[11:56] <persia> DigGo: You likely will find a better response in #ubuntu+1.  Hobbsee is likely right though.
[11:56] <DigGo> ok bye
[11:56]  * Hobbsee sighs
[11:56] <Hobbsee> don't these people ever learn?
[11:57] <persia> Hobbsee: One-by-one.  How long does it take to count to 10 million?
[11:57] <amarillion> persia, I see, I was looking at http://doc.ubuntu.com/ubuntu/packagingguide/C/
[11:58] <Hobbsee> persia: one, two, skip a few, 9 999 999, 10 million
[11:58] <persia> amarillion: That's the old one.  I'm not sure if whether it was being removed was ever resolved.
[11:58] <persia> Hobbsee: it's the "skip a few" that is time consuming and repetitious :)
[11:58] <Hobbsee> hehe
[11:58] <amarillion> I think it should be removed, it can only lead to confusion. At least I was certainly confused by it.
[11:59] <wallyweek> persia, amarillion: just tried, I can't edit wiki pages :(
[11:59] <persia> wallyweek: Are you logged into the wiki?
[11:59] <wallyweek> persia: yes
[12:00]  * wallyweek is copying persia's suggestions on his desktop for later use ;)
[12:00] <persia> wallyweek: You're logged into wiki.ubuntu.com, and the edit button doesn't work?
[12:01]  * persia doesn't understand, and hopes someone with deeper wiki-fu will explain.
[12:01] <DaveMorris> persia: Do I need the copyright of whats in the source package in the copyright file, or from the source files which make up the debs. (did that make sense?)
[12:02] <persia> DaveMorris: Both, really.  You need to reference the copyright and licensing for everything that is distributed (source and binary).
[12:02] <DaveMorris> ok, cos a lot of whats in the source package doesn't actually get built
[12:02] <wallyweek> persia: ok, it was my fault... I logged in, press browser back button and forgot to refresh :(
[12:03] <wallyweek> persia: now edit is enabled...
[12:03] <persia> DaveMorris: Sure, but people can download it with apt-get source, so it is still distributed, even if not in the binary.
[12:03] <wallyweek> persia: ...but connection error cleaned all previous messages... I lost them :(
[12:04] <persia> wallyweek: http://irclogs.ubuntu.com/2008/01/25/%23ubuntu-motu.html or http://irclogs.ubuntu.com/2008/01/25/%23ubuntu-motu.txt might be helpful :)
[12:04] <wallyweek> persia: good! thanks! :)
[12:05] <amarillion> persia, I filed a bug for removal of the old packaging guide: https://bugs.edge.launchpad.net/ubuntu-doc/+bug/185899
[12:05] <ubotu> Launchpad bug 185899 in ubuntu-doc "please remove old packaging guide" [Undecided,New]
[12:06] <persia> amarillion: That's a great way to get the discussion going again.  Thanks.
[12:07] <amarillion> If you look at that, there are actually a lot of bugs in the ubuntu-doc project filed for small changes to the ubuntu packaging guide. If those people had known that they could edit the wiki directly, there was no need to file a bug in the first place.
[12:08] <amarillion> Like e.g. https://bugs.edge.launchpad.net/ubuntu-doc/+bug/158998
[12:08] <ubotu> Launchpad bug 158998 in ubuntu-doc "Packaging guide: 822-date command deprecated, should use "date -R"" [Undecided,Confirmed]
[12:08] <amarillion> I mean there really shouldn't be a need to go through the whole bug reporting & triaging process just for that tiny change
[12:08] <persia> amarillion: It only moved to the wiki recently.  It used to be a source package.  If you want to improve things, integrating all those changes would be very helpful.
[12:09] <amarillion> Yeah, sounds like a nice project. I'm going to work on that.
[12:09] <persia> amarillion: Thanks.
[12:11] <techno_freak> ok guys.. ciao..
[12:11] <mruiz> hi all
[12:21] <persia> slytherin: Re: lucene2.  I just had a report that it built with icedtea.  Did you have something that worked with gcj, or would this need extra care to be in universe (assuming the xhtml DTD issue gets resolved)?
[12:22] <wallyweek> amarillion, persia: edit done, suggestion added to https://wiki.ubuntu.com/PackagingGuide/PackagingOverview#head-4032f87b77123c6c051910dbc3383cb6898506f6
[12:23] <wallyweek> persia: are you aware when will next revu day start?
[12:23] <persia> wallyweek: Nitpick: you've listed six interesting things, but the code section above only has five stanzas, which may lead to confusion.
[12:24] <persia> wallyweek: 2008 28 January 0:00 UTC+14
[12:25] <amarillion> wallyweek, do you understand the structure of the wiki?
[12:25] <persia> wallyweek: Also, consider putting that in https://wiki.ubuntu.com/PackagingGuide/Basic#Copyright instead, so as to make the overview easier to read.
[12:26] <amarillion> If you try to edit the main page, you just see a bunch of "Include" lines
[12:26] <wallyweek> persia: thanks! is there a way to specially point out a package? sdlmame's been on revu for nearly one year, I would like to see in hardy
[12:26] <amarillion> and then I can't find the actual page you need to edit
[12:26] <wallyweek> amarillion, persia: unfortunately it's the first time I edit a wiki page :(
[12:26] <amarillion> Not for me, but this is the most complicated one I've seen thus far
[12:28] <persia> wallyweek: Just push advertisements, and hope someone is interested.  A year is a really long time: it's usually only a couple of months during REVU season.
[12:28] <persia> amarillion: Try looking at the raw text (under more actions) to see what page is being included.  Then, manually enter that URL, and use Edit.
[12:28] <wallyweek> persia: I saved your messages, I'll be back on edit the wiki asap
[12:29] <wallyweek> persia: keep on advertising makes me feel like a channel pest... :o
[12:30] <wallyweek> persia: or I should assume that noone will be annoyed by that?
[12:30] <wallyweek> s/noone/no one
[12:30] <persia> wallyweek: Understood.  I'm not sure what advice to give.  Eventually, your package should reach the top, and get reviewed.  If there are no more issues, it gets advocated.  I'm not sure how it kept getting rejected for an entire year unless there were gaps.
[12:31] <persia> Also, I believe the only preference anyone ever expressed was to restrict advertisements to less than once every 24 hours.
[12:32] <persia> wallyweek: amarillion: If either of you wants to update the maintainer scripts bit, http://women.debian.org/wiki/English/MaintainerScripts is an excellent reference.
[12:32] <txwikinger> Is there motu Q&A today?
[12:33] <persia> txwikinger: It's Friday, but feel free to beat the crowd and ask a question now :)
[12:33] <wallyweek> persia: I must admit first uploads needed lot of work, but it should be ready for advocates now
[12:33] <txwikinger> persia: :D
[12:34] <txwikinger> I have some questions to interdiff
[12:34] <persia> ...
[12:34] <txwikinger> I am getting confused with the orig.tar
[12:35] <txwikinger> basically what I am doing is having  a new orig.tar for the new release
[12:35] <txwikinger> does the interdiff take account for that?
[12:35] <wallyweek> persia: reference saved! :D
[12:35] <persia> txwikinger: An interdiff is used to track the differences between the patches.  It completely ignores the orig.tar.gz (as we know it has changed).
[12:36] <txwikinger> And if there aren't any patches?
[12:36] <persia> txwikinger: So, it compares the two diff.gz files, and shows how they differ.  This allows the old diff.gz to be patched to generate the new diff.gz.
[12:36] <persia> txwikinger: There is always at least debian/changelog, debian/copyright, debian/control, and debian/rules.
[12:37] <txwikinger> well ok yes
[12:37] <txwikinger> but if they would be the same in the old and the new release (changelog wouldn't)
[12:37] <persia> Remember, diff.gz is just a patch to generate a debian-format source from the upstream source.
[12:37] <txwikinger> yes I understand that
[12:37] <persia> txwikinger: Exactly, so the interdiff tracks the differences between the patches.
[12:38]  * persia builds a simple example
[12:38] <txwikinger> So.. if would have to provide the orig.tar in addition anyway
[12:38] <txwikinger> s/if/I/
[12:38] <wallyweek> I'm leaving... thanks everyone! :
[12:38] <wallyweek> :)
[12:39] <\sh> wow...I think I'm through
[12:39]  * txwikinger wonders what \sh is doing
[12:40] <\sh> txwikinger, checking if octave3.0 is the right thing for hardy ;)
[12:40] <txwikinger> )
[12:40] <txwikinger> :)
[12:41] <persia> txwikinger: You wouldn't provide the orig.tar.gz.  Upstream generally does that, and you use a watch file to reference it.  Where this doesn't work, you construct a get-orig-source in debian/rules
[12:41] <txwikinger> persia: Well in that particular package there is a problem with that
[12:41] <txwikinger> that was my next question anyway
[12:42] <txwikinger> I need to take two tar files and merge them together that the package builds
[12:42] <txwikinger> (two tar files from upstream)
[12:42] <persia> txwikinger: Are you sure you don't want two source packages?
[12:43] <txwikinger> well it doesn't build separately
[12:44] <txwikinger> otherwise I wouldn't have a problem.... I think I create separate binaries anyway from it
[12:47] <txwikinger> Yes the control file has two binaries
[12:47] <txwikinger> which correspond to the two source tars
[12:48] <persia> txwikinger: http://paste.ubuntu.com/3864/ has a small file, with an old diff, a new diff, and an interdiff.  Feel free to grab them and play with interdiff and combinediff to see how it works.
[12:49] <txwikinger> cool thanks
[12:49] <persia> txwikinger: Regarding your source issues, do both sources fail to build independently?  If one builds on it's own, and the other requires the first, then you just have a build-dependency.
[12:49] <txwikinger> I think your explanation already helped me, but I will play with it.. it is always more illustrative
[12:50] <txwikinger> well.. the main package fails to build if the directory of the themes is missing
[12:50] <txwikinger> which is exactly the source tar of the second package
[12:50] <persia> txwikinger: Can the themes build without the main package?
[12:51] <txwikinger> I have not tried that.. it would have to be newly packaged then since there is no debian directory existing for it
[12:52] <txwikinger> however, it still would not make the main package build
[12:52] <persia> txwikinger: Best practice is to have one source package per upstream source package, unless there are really strong reasons not to do that.  Give it a shot :)
[12:52] <persia> txwikinger: Why not?
[12:53] <txwikinger> The build system expects the theme sources in that particular directory
[12:53] <txwikinger> If it should work, the build system would have to be changed
[12:53] <persia> txwikinger: That sounds like a build system in need of patching.
[12:54] <txwikinger> and it might need to find the .h files somewhere too
[12:54] <txwikinger> so that would probably require not only the binary theme file to be installed, but also a theme-dev file
[12:54] <persia> txwikinger: If it needs .h files provided by another source, that other source should be packaged as a library, so the .h files would be in /usr/include/
[12:55] <txwikinger> yes.. that's what I think
[12:55] <txwikinger> I totally agree with you that it should be done that way
[12:55] <txwikinger> unfortunately it is far more work
[12:57] <persia> txwikinger: Yep.  That's why packages get maintainers.  If it were easy, people would just download the upstream releases, and it would work.  Of course, in cases where this is done, it tends to lead to completely reinstalling the system every six months or so, and wondering why it gets progressively slower in the meantime.
[12:58] <txwikinger> :D
[12:59] <txwikinger> well.. it needs to be rolled into debian too when I have done it
[12:59] <txwikinger> Does this go through revu then?
[13:00] <txwikinger> or just via the bug since it is a new release/package split
[13:01] <persia> txwikinger: Which package?  If Debian is already doing it in an annoying manner, it may not be worth splitting the source.  On the other hand, if the new upstream breaks the old way of doing things, yes, the extra package would go through REVU.
[13:02] <txwikinger> persia: No.. the source was split at the original source
[13:03] <txwikinger> debian still has the old version
[13:03] <txwikinger> and without the new package, the main package is broken.. because it depends on it
[13:03] <persia> txwikinger: New upstream split for the new upstream version?  In that case, you do want a new source package, and you do want to upload to REVU.
[13:03] <txwikinger> ok
[13:04] <persia> (and you want to report in your bug not to upgrade until the REVU package is in, as otherwise it creates a FTBFS bug).
[13:04] <txwikinger> well.. I think the old package has an FTBFS already since that's how I found the issue
[13:05] <persia> txwikinger: The question you might want to ask is: is the package update important enough that it's worth trying to get all that done in the next three weeks?  (the answer may be yes, but it's worth asking).
[13:05] <persia> txwikinger: Ah.  If it's already broken, then go for it :)
[13:05] <txwikinger> well.. the new release is the first release candidate
[13:07] <txwikinger> the old release is a very old alpha or beta release
[13:07] <txwikinger> It is a game... so I don't know if it is worthy due to the time schedule
[13:08] <txwikinger> maybe other causes are more important
[13:08] <persia> txwikinger: Maybe you want to check with upstream then: if a release is coming soon, you might want to target that rather than the RC (although you would need to apply for an FFe in that case)
[13:08] <txwikinger> FFe?
[13:09] <persia> txwikinger: FeatureFreeze exception
[13:09] <txwikinger> ah righh
[13:09] <txwikinger> right
[13:30] <slytherin> persia: there? I was away for meeting.
[13:30] <persia> slytherin: Even when I'm not, I read all the backscroll
[13:31] <DaveMorris> persia: I've fixed those issues, there were quite a lot of copyright holders actually.
[13:31] <slytherin> persia: The issue with lucene2 has nothing to do with 'which JDK' The libraries build with even GCJ. I had disabled unit tests and tried building. If we get the DTD issue resolved then we can build with GCJ and promote it to universe.
[13:32] <persia> DaveMorris: Are they all covered by the same license?  When there are lots of copyright holders, it sometimes means you need to do a deeper investigation into licensing.
[13:32] <DaveMorris> I'll double check
[13:33] <DaveMorris> they've included a copy of scons in the original source package, what do I do about that licence?
[13:33] <persia> slytherin: Right.  I remembered the DTD issue, but had someone poke me that it worked with icedtea, and couldn't remember if you already had a GCJ patch.  If it's on the way to universe, them I've very excited :)
[13:34] <slytherin> persia: One more trial is needed just to make sure that unit tests don't cause any trouble.
[13:39] <persia> slytherin: Apologies.  I seem to be catching you too late.  Would you mind updating bug #185917?
[13:39] <ubotu> Launchpad bug 185917 in lucene2 "lucene2 jdk dependence" [Undecided,New] https://launchpad.net/bugs/185917
[13:41] <slytherin> persia: I will update that bug. Should I assign it to myself?
[13:41] <persia> slytherin: If you've a solution prepared, sure.  Am I correct that you're planning to fix it in Debian and sync?
[13:42]  * persia unsubscribes the sponsors, preferring gcj to icedtea, and the current patch not fixing the FTBFS
[13:43] <slytherin> persia: No plan for Debian. In fact my explanation for w3c-dtd-xhtml bug seems not to be very useful to Debian developers. If nothing happens over weekend I will fix both bugs in Ubuntu only.
[13:43] <persia> slytherin: Ah.  Right.  Arch-all not actually being built on the buildds and all.  Maybe the archive-rebuild scripts will catch it eventually, and they'll pull the patch.
[13:44] <man-di> slytherin: I hope to find the time on sunday to write some mails about w3c-dtd-xhtml
[13:45] <slytherin> persia: Looks like my last reply didn't reach Debain BTS. I will drop a reply tomorrow again, and see if it helps.
[13:45] <slytherin> man-di: Thanks. :-)
[13:45]  * slytherin wishes there was a 'Depends' field for bugs in launchpad
[13:46] <persia> slytherin: It's been discussed, but there are too many different relationships.  If you write "bug #nnnnnn" in a comment, Malone replaces with a hyperlink to the bug to allow manual description of bug relationships.
[13:47] <slytherin> persia: That will do for now.
[13:47] <ScottK> persia: It's still a regression from bugzilla.
[13:48] <persia> ScottK: I refuse to either defend Bugzilla's broken bug relationship system or Malone's lack of any relationship mapping.
[13:48] <persia> s/either defend/defend either/
[13:50] <ScottK2> OK.  It may or may not be true, but I find Malone's also affects substantially inferior to bugzilla's depency relationships.  Sure, it could be better, but at least it's there.
[13:50] <persia> I consider "Also affects" completely different than bugzilla's dependency mappings.
[13:51] <Hobbsee> [00:50] * Hobbsee notes that adding stuff in here is classed as contributing to ubuntu development, which is one of the things that kmos has been asked not to do.
[13:51] <Hobbsee> [00:50] * Hobbsee therefore will prohibit him from doing so.
[14:03] <amarillion> doko, are you around?
[14:03] <amarillion> I've got some java packaging questions
[14:04] <persia> amarillion: There are a number of people who can answer Java packaging questions.  Best to just ask.
[14:04] <amarillion> sure
[14:05] <amarillion> I would like to package cytoscape
[14:05] <amarillion> http://www.cytoscape.org/, it's a scientific package for analyzing networks, mostly genetic networks
[14:06] <amarillion> The trouble is, it includes a large number of jar files
[14:06] <amarillion> most of which are not packaged yet either
[14:06] <persia> amarillion: How does upstream bundle the release package?
[14:06] <amarillion> As far as I can tell
[14:06] <amarillion> The jar files are included in the tar.gz
[14:07] <amarillion> you have to get the sources elsewhere if you want them
[14:07] <joejaxx> grr i still cannot get pbuilder-dist to not clean the build environment :\
[14:07]  * persia is not a Java expert and welcomes correction
[14:07] <DaveMorris> would it be best to package the jars up so other packages could depend on them?  Or is that too much work?
[14:07] <persia> amarillion: I've seen other packages that fiddle with the classpath to get ant to use the system libraries in preference to the local libraries.
[14:07] <amarillion> DaveMorris, yeah, that is what I want to do although it would indeed be a  lot of work
[14:08] <persia> Of course, this means first making sure there are system libraries in all these cases: many Java applications seem to require first importing two or three libraries.
[14:08] <slytherin> amarillion: Are the jar's very uncommon? May be some of them are already present in Ubuntu.
[14:08] <amarillion> Some of them are, some of them aren't
[14:09] <amarillion> I'll list them
[14:10] <amarillion> there is jdom, junit, jnlp, xerces, getopt, jaxb, batik, giny, colt, coltginy, freehep, piccolo, biojava, looks, glf and more
[14:10] <LucidFox> Gah! Stupid dh_pysupport :S
[14:10] <amarillion> jdom is very common but I couldn't find it in the repo
[14:10] <LucidFox> When there was a single package, it saw and handled Python-Depends for every package.
[14:10] <amarillion> same for batik
[14:11] <LucidFox> Now that there are multiple packages, it ignores Python-Depends for all packages but the first one.
[14:11] <slytherin> amarillion: It is there I am sure. Batik has build failure.
[14:11] <slytherin> amarillion: I mean jdom is there
[14:11] <amarillion> slytherin, ok, I thought it must be
[14:11] <amarillion> what is the name of the package? There is no libjdom-java
[14:12] <tuxmaniac> LucidFox, have again re-uploaded the package after your comments. Can you please re-review it? this is wrt alliance
[14:13] <slytherin> amarillion: https://edge.launchpad.net/ubuntu/+source/libjdom-java
[14:13] <amarillion> Somebody told me in the past that there is a ubuntu-java mailinglist
[14:13] <persia> tuxmaniac: You'll get the best quality package by having different reviewers, as we all check slightly different things.  Try to find a new reviewer each time, if you can.  Best to just advertise your URL generally.
[14:14] <tuxmaniac> persia, coolness. here goes my ad. http://revu.tauware.de/details.py?package=alliance
[14:14] <amarillion> slytherin, oops, my mistake
[14:14] <rexbron> siretart, I know I have asked about ffmpeg in the past, but what can I do to speed along an update?
[14:14] <amarillion> synaptic doesn't show it if you search for jdom
[14:14] <joejaxx> rexbron: :)
[14:15] <rexbron> joejaxx, I thought I would make it a productive question :)
[14:15] <joejaxx> rexbron: lol :P
[14:15] <siretart> rexbron: get sam to revise the altivec patches. What would also help is to review the current patches, and comment them in a form that would be acceptable for upstream inclusion
[14:15] <slytherin> amarillion: Perhaps you are searching for wrong field. :-)
[14:16] <jdong> siretart: we plan to include a newer ffmpeg before freezing?
[14:16] <rexbron> It would be ideal to get a svn pull that is more recent than october...
[14:16] <DaveMorris> persia: you where right as usual, other licences in there.  I've upload the new version and addressed all the points.
[14:16] <siretart> jdong: there is a newer ffmpeg in debian/experimental. we could most probably include that into hardy right now
[14:16] <slytherin> If I attach updated debdiff should I delete old one form the bug?
[14:17] <siretart> jdong: however I don't have the time to deal with the breakage :(
[14:17] <rexbron> siretart, I can take a look at the patches, but would be afraid to submit them to the -devel list. I am subscribed to it and they are vicious :P
[14:17] <persia> DaveMorris: Excellent.  I'm not likely to try that build again soon, but will take at least one more look before the last REVU day.
[14:17] <siretart> rexbron: you bet
[14:17] <DaveMorris> the changes won't affect the building :)
[14:17] <jdong> siretart: sounds good
[14:18] <siretart> rexbron: still, I don't feel comfortable with both dropping them nor having them around
[14:18] <jdong> siretart: I'm guessing as always, rebuilding the revdep tree will be necessary?
[14:18] <siretart> jdong: would you feel comfortable with having ffmpeg updated in hardy, dropping patches from the debian package?
[14:18] <siretart> jdong: yeah
[14:19] <jdong> siretart: yeah, if you are comfortable with it, I'm comfortable with the idea
[14:19] <rexbron> siretart, would it be possible to "start fresh" ie, include a newer version of ffmpeg in paralle and transition packages that need the newer funtionality over to it?
[14:19] <jdong> siretart: I'm not certain what patches are in the debian package, so I can't comment specifically on dropping those
[14:19] <slytherin> Can anyone sponsor the latest debdiff attached to bug 185435
[14:19] <jdong> rexbron: what kind of changes have been made to ffmpeg since the experimental snapshot that are important to you?
[14:20] <amarillion> so how does a good java package set the classpath? Just hard-code it in a startup wrapper script?
[14:20] <ubotu> Launchpad bug 185435 in nautilus-open-terminal "nautilus-open-terminal no longer works in Hardy" [Low,Confirmed] https://launchpad.net/bugs/185435
[14:20] <rexbron> jdong, inclution of MXF container support
[14:20] <rexbron> so one can playback files created by an HVX200
[14:20] <jdong> rexbron: interesting....
[14:21] <jdong> siretart: it doesn't completely sound unreasonable to do an up-to-date SVN checkout does it?
[14:21] <tuxmaniac> Hope I am not kicked for the repeat post. Can someone please review the package http://revu.tauware.de/details.py?package=alliance
[14:21] <jdong> (not having looked at the changelog yet...)
[14:21]  * DaveMorris kicks tuxmaniac
[14:21] <rexbron> jdong, there also have been patches submitted to the -devel list for the inclution of encoding DVCPRO HD
[14:21] <rexbron> but those still need work
[14:21] <ScottK> jdong: It depends on if svn is more or less broken that what's already in experimental.
[14:21] <siretart> jdong: I'm not comfortable with the idea, since I doubt I have enough time and energy to deal with the breakage
[14:22] <rexbron> siretart, what about what I suggested?
[14:22] <siretart> rexbron: you want to maintain 2 different versions of ffmpeg? uuuh
[14:22] <siretart> no
[14:22] <jdong> siretart: the package in experimental seems to be around a month old. Are there a lot of people helping QA that?
[14:23] <rexbron> siretart, that would be part of a migration strategy
[14:23] <siretart> jdong: I did a rebuild of the revbuilddep tree, and found no regressions. I didn't test the packages, though
[14:23] <jdong> siretart: ah, ok, looks like you did a lot of work into this already :)
[14:23] <siretart> yes
[14:24] <siretart> what would help me most would be people that look at the patches and review and document them
[14:24] <persia> slytherin: Do you think http://paste.ubuntu.com/3871/ would break anything critical?
[14:24] <rexbron> siretart, the ones off of debian experimental right?
[14:24] <slytherin> persia: let me check
[14:24] <jdong> siretart: was the orig.tar.gz repacked?
[14:25] <siretart> http://svn.debian.org/viewsvn/pkg-multimedia/experimental/ffmpeg/debian/patches/
[14:25] <siretart> jdong: yes, using this script: http://svn.debian.org/viewsvn/pkg-multimedia/experimental/ffmpeg/debian/strip.sh?rev=923&view=log
[14:25] <siretart> http://svn.debian.org/viewsvn/pkg-multimedia/experimental/ffmpeg/debian/strip.sh?rev=923&view=markup
[14:26] <jdong> siretart: so h.264/mpeg4 are entirely removed, or just their encoders?
[14:26] <siretart> just the encoders
[14:26] <jdong> siretart: ok
[14:29] <slytherin> persia: Looks ok to me. What is this for?
[14:30] <persia> slytherin: http://www.netbeans.org/issues/show_bug.cgi?id=112679 and http://www.netbeans.org/issues/show_bug.cgi?id=98212
[14:30] <persia> Thanks for being a second pair of eyes.  I'll go chase rdepends a bit, and might push to 1.2.
[14:39] <slytherin> persia: Is that fix really needed if netbeans 6.x is going to eventually land in Ubuntu
[14:39] <persia> slytherin: Well, it's either apply that patch or bundle a special libresolver for netbeans, which would be painful from a support perspective.
[14:40] <slytherin> persia: Ahh, then it is fine
[14:40] <persia> Oh, and 6.0.1 :)
[14:52] <slytherin> persia: can you review the nautilus-open-terminal fix and sponsor it?
[14:53] <persia> slytherin: I'm going to bed in about 10 minutes.  I'll be reviewing the sponsors queue in 8-10 hours, and will be sure to take a look if it is still there.
[14:53] <slytherin> persia: Ok. No problem
[14:53] <persia> (unless this is blocking something else, and you really need it now)
[14:59] <slytherin> persia: No. It is not blocking anything except the use of extension. :-) But I already have it in my PPA and those who want can use it.
[15:00] <persia> slytherin: Good to hear.  Thanks.
[15:04] <LucidFox> poor Kmos :(
[15:04] <zul> hey ivoks
[15:05] <ScottK2> LucidFox: I hope your kidding.
[15:06] <rexbron> Would anyone be able to explain the difference between rpath and runpath?
[15:06] <LucidFox> well, I don't know what he did...
[15:08] <wallyweek> persia: just fyi, updates to packaging guide commited: https://wiki.ubuntu.com/PackagingGuide/Basic
[15:11] <amarillion> Is the new packaging guide only on the wiki, or is it still possible to get it in other formats?
[15:22] <wallyweek> amarillion: I don't know :( I guess is on the wiki only
[15:23] <amarillion> It seems like there must be a better way to do that
[15:24] <slytherin> amarillion: Use httrack to download all the pages
[15:24] <amarillion> I was more thinking along the lines of docuwiki http://wiki.splitbrain.org/wiki:dokuwiki
[15:32] <LucidFox> Hmm.
[15:33] <mok0> What is the tool that syncs packages into a new development branch? What does it do the the changelog entry?
[15:33] <LucidFox> Apparently, dh_pysupport reads the correct Python-Depends values for all packages, but only correctly substitutes ${python:Depends} for the binary package whose name is the same as the source package
[15:34] <mok0> My problem is that I now need to update all our local packages to hardy, and I would rather not have to go in and edit debian/hangelog in all of them
[15:34] <StevenK> mok0: That tool is called "Merge-o-Matic" or MoM
[15:35] <mok0> StevenK: Is that something that I can run locally?
[15:35] <james_w> StevenK, I don't think it is that one is it?
[15:35] <StevenK> mok0: sed -e 's/gutsy/hardy/' < debian/changelog > debian/changelog.new ; mv debian/changelog.new debian/changelog ?
[15:35] <james_w> mok0, you can do it with dch and a couple of lines of shell.
[15:36] <mok0> james_w: ok, seems feasible
[15:36] <LucidFox> StevenK> or sed -e -i 's/gutsy/hardy/' debian/changelog
[15:36] <LucidFox> :)
[15:37] <StevenK> Meh :-)
[15:37] <POX_> LucidFox: no, pysupport is copying Python-Depends in arch all packages
[15:37] <mok0> LucidFox: that's kinda the dirty solution
[15:37] <POX_> and adds 2.X in arch any (python extensions)
[15:38] <POX_> so if you have python-myextension package that needs pygtk module, pysupport will generate Depends with python2.4-pygtk, python2.5-pygtk
[15:38] <mok0> So, how do people store the source packages? In one big whopping directory?
[15:39] <POX_> python2.4-pygtk and python2.5-pygtk are virtual packages provided by python-pygtk package
[15:39] <StevenK> mok0: For me, depends on what I'm doing
[15:39] <mok0> I guess the easiest would be to have them all in bazaar
[15:40] <LucidFox> POX> The problem is...
[15:41] <LucidFox> I have the source package tovid and binary packages tovid, tovidgui, todiscgui and todraw
[15:41] <amarillion> mok0, I have everything in ~/debs/packagename/packagename-version/
[15:41] <LucidFox> I inserted debug print into dh_pysupport - it definitely parses Python-Depends for all of them
[15:42] <LucidFox> but only generates the dependencies for tovid - for others, it's just "python" :.
[15:42] <mok0> amarillion: I have something similar. I have recently started tracking my packing in git
[15:42] <POX_> oh, file a bug against python-support then
[15:42] <POX_> LucidFox: ^^
[15:43] <amarillion> mok0, do you then just check in the debian directory?
[15:43] <amarillion> or do you check in the entire source tree?
[15:44] <mok0> amarillion: no, I am not allowed
[15:44] <LucidFox> I should first identify why exactly it fails to paste the dependencies into substvars
[15:44] <mok0> amarillion: I use git_import_dsc
[15:45] <mok0> amarillion: it keeps the original source on a separate branch
[15:45] <POX_> LucidFox: dh_pysupport line 104
[15:45] <mok0> amarillion: which makes it easy to track what you have been doing
[15:45] <mok0> amarillion: so, that's a separate git repo for every package
[15:46] <amarillion> oh good idea. I'm going to try that
[15:46] <mok0> amarillion: you then have to use git-buildpackage instead
[15:46] <amarillion> is there a nice way to combine that with patches too?
[15:47] <mok0> amarillion: you can make it as fancy as you want. A branch for each patch.... or whatever
[15:47] <POX_> LucidFox: or rather line 202 (works only for packages with 'python-*' name)
[15:47] <mok0> amarillion: then, at the end, merge the branches you want
[15:48] <LucidFox> Neither of my packages are named python-*, but all Python-Depends are named so
[15:48] <mok0> amarillion: there's quite a lot of docs on using git for packaging in debian
[15:48] <mok0> Ah, friday afternoon... the boys are playing Wii next door :-)
[15:49] <LucidFox> What about python-central, does it have a mechanism equivalent to Python-Depends?
[15:49] <ion_> git-buildpackage is quite nice. And how git handles branching is awesome if you want to have the upstream stuff in one branch, the packaging added to it in another, and perhaps other packaging branches in addition to that (such as for maintaining the package in an older distro version).
[15:50] <POX_> LucidFox: no
[15:50] <LucidFox> so how does it handle dependencies?
[15:50] <ion_> Not to mention that git is superfast compared to the alternatives. :-)
[15:50] <mok0> ion_: It's truly awesome
[15:50] <POX_> LucidFox: you have to enter them in all packages by hand
[15:51] <mok0> ion_: would be a good topic for the MOTU School!
[15:51] <POX_> LucidFox: Python-Depends is good only for python extensions anyway
[15:51] <LucidFox> Ah
[15:52] <amarillion> good idea. I'd like to hear more about it
[15:52] <amarillion> Here is one manual: http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html
[15:52] <mok0> amarillion: put it on the wiki
[15:53] <mok0> amarillion: I mean, as a wish for a class
[15:53] <LucidFox> so, if I have a package depending on python-tk, I can just put it in Depends instead of Python-Depends? Or do I have to depend on something like python2.5-tk | python-tk?
[15:54] <POX_> use python-tk or python-tk (>= first_version_with_2.5_so_file)
[15:55] <POX_> LucidFox: btw, if you need a script to detect python dependencies, we have one in DPMT
[15:55] <POX_> really ugly one, but it work (most of the times)
[15:55] <POX_> +s
[15:56] <amarillion> mok0, done: https://wiki.ubuntu.com/MOTU/School/Requests
[15:56] <LucidFox> well, this package installs lots of scripts in /usr/bin... some are Python, others are bash
[15:56] <POX_> LucidFox: http://svn.debian.org/viewsvn/*checkout*/python-modules/tools/find_python_dependencies.sh
[15:57] <james_w> mok0, yeah, I plan to do one. However I doubt that git will be used.
[15:57] <james_w> perhaps I can cover it briefly, but hopefully the concepts will be transferable.
[15:58] <LucidFox> POX_> Thanks, that was really helpful!
[15:59] <LucidFox> it caught python-cairo
[16:01] <POX_> LucidFox: check if it's really needed (cairo module could be in docstring and its not detected coreclty)
[16:01] <goodhabit>  Hello. I have some trouble. I am linux newbie, also ubuntu newbie. I have found some software, and with helps of manuals, google, brain I have compiled some software. But, as I understood,"make install" is wrong-way. And I need making deb file. I am started googling forward and found some manuals for it (#ubuntu also). But there are some issues I cannot solve. But as I told allready I need that package. Maybe someone could help me with packaging?
[16:02] <LucidFox> goodhabit> What is the software?
[16:02] <\sh> hmmm...why I'm still a non-ubuntu-developer, regarding ubuntu-devel?
[16:03] <pochu> \sh: same here :)
[16:03] <LucidFox> POX_> http://paste.ubuntu.com/3874/ - that's weird... it points to a file that isn't even in the directory I pointed the script to
[16:03] <goodhabit> LucidFox, wired. http://sourceforge.net/projects/wired/
[16:04]  * persia briefly surfaces to point at #canonical-sysadmins for developers having issues posting to mailing lists
[16:05] <POX_> LucidFox: grep -r cairo /usr/share/python-support/tovid
[16:05]  * \sh has no time for this now..need to finish the bugfixes for the octave3.0 stuff
[16:05] <LucidFox> goodhabit> there is a PPA with this package here: https://launchpad.net/~tsmithe/+archive
[16:06] <goodhabit> LucidFox, yep, but there are outdated version...
[16:07] <mok0> amarillion: great
[16:07] <POX_> LucidFox: it shows a file from which the module comes from, not the one with import command
[16:07] <LucidFox> POX_> yes, it is used after all
[16:07] <POX_> LucidFox: uncomment '#echo "  $i" # DEBUG'
[16:07] <POX_> and you will see module names
[16:08] <LucidFox> thanks for the script again!
[16:08] <\sh> persia, #canonical-sysadmins is empty ;)
[16:09] <davies> \sh: #canonical-sysadmin?
[16:09] <\sh> ah
[16:10] <POX_> LucidFox: next time join #debian-python, there are more python guys there. If you need help, we have DPMT (for python modules) and PAPT (for applications) teams
[16:10] <pochu> POX_ rocks :)
[16:10] <yamal> reviewers/advocates wanted for http://revu.tauware.de/details.py?package=sabnzbdplus
[16:11] <LucidFox> POX_> thanks :)
[16:13] <LucidFox> on a tangentially-related note... why does CDBS not respect debian/docs? It automagically calls "dh_installdocs ./README ./AUTHORS" rather than just dh_installdocs
[16:14] <ScottK> LucidFox: cdbs is about automagic, not respect.
[16:14] <LucidFox> heh
[16:25] <tuxmaniac> reviewers/advocates wanted for http://revu.tauware.de/details.py?package=alliance
[16:40] <bddebian> Heya gang
[16:42] <\sh> btw...bug for the octave3.0 transition: https://bugs.edge.launchpad.net/ubuntu//+bug/185959
[16:42] <ubotu> Launchpad bug 185959 in xmds "octave3.0 transition" [Undecided,Confirmed]
[16:44]  * \sh < -- bbl
[16:49] <zakame> hi folks, long time..
[16:57] <schierbeck> hi guys
[16:58] <schierbeck> i'm having trouble installing a bash completion script to /etc/bash_completion.d/
[16:59] <schierbeck> i can't seem to do it directly, because i don't have the permissions to write the /etc
[16:59] <schierbeck> what the hell should I do then?
[16:59] <james_w> schierbeck, in a package build?
[16:59] <schierbeck> yup
[16:59] <james_w> don't install to /etc, install to "$(CURDIR)"/debian/tmp/etc/
[17:00] <james_w> or similar depending on whether you use tmp or the package name.
[17:00] <schierbeck> i use the package name
[17:00] <schierbeck> and then it'll be copied to /etc when installed?
[17:00] <schierbeck> thanks!
[17:00] <james_w> if this installed by the upstream Makefile then you need to patch it to accept $(PREFIX) and then use that.
[17:00] <schierbeck> i'll try it out
[17:02] <hellboy195> How long does it normally take until there is a new changelog entry for a new revision in Debian?
[17:03] <james_w> hellboy195, I'm sorry, I don't understand the question, could you explain please?
[17:03] <tuxmaniac> hellboy195, you mean once uploaded a new revision of a package?
[17:03] <hellboy195> tuxmaniac: right ^^
[17:04] <hellboy195> Because I want to do a merge but Debian site hasn't got a new changelog entry :(
[17:04] <tuxmaniac> hellboy195, I suppose a few hours. Atleast one package that I knew took 10 hrs app
[17:04] <hellboy195> tuxmaniac: k, thx. so I'll wait at least until tomorrow (uploaded yesterday)
[17:05] <schierbeck> james_w: that works! now, how the hell do i remove it when uninstalling?
[17:06] <james_w> schierbeck, you don't need to, it should now appear in the list of files in the package, and so apt will take care of that for you.
[17:07] <schierbeck> okay
[17:07] <schierbeck> thanks!
[17:12] <james_w> schierbeck, though you should probably read http://wiki.debian.org/DpkgConffileHandling
[17:15] <schierbeck> james_w: okay
[17:23] <\sh> how strange is this...even with trackerd in the gnome-session management disabled, it comes from time to time up and running...and eats my resources...oh well
[17:24] <geser> \sh: the workaround it to deinstall trackerd
[17:31] <rexbron> this is fun... I hate non-standard directories
[17:31] <rexbron> in /usr/lib that is
[17:34] <slangasek> rexbron: given that the standard says you can have more or less arbitrary subdirs of /usr/lib, what constitutes a non-standard subdir of /usr/lib? :)
[17:36] <rexbron> slangasek,  installing to /usr/lib/<foo>/<foo.bar>/lib so that libs need rpaths to find anything....
[17:36] <rexbron> that or setting something like ld.so.conf, but I really don't know enough about that subject
[17:36] <slangasek> oh
[17:36] <rexbron> :P
[17:36] <slangasek> so not the directory, but the non-standard placement of the files :)
[17:37] <rexbron> sladen, ya
[17:37] <rexbron> slangasek, I posted to the ML with my problems if you want to take a look. The subject is "Acceptable use of rpath"
[17:41] <bddebian> I thought slangasek thought there was no acceptable use of rpath? ;-P
[17:42] <pochu> I thought bddebian thought slangasek thought there was an acceptable use of it
[17:43] <\sh> slangasek, you are my debian guru...what will happen to packages in non-free in debian, which are not existent anymore (upstream), or are not being maintained by the debian package maintainer? as an example in this case: octave-gpc
[17:50] <slangasek> bddebian: yes, that's my position
[17:51] <slangasek> \sh: nothing happens automatically to such packages
[17:51] <slangasek> \sh: if they cease to be buildable or installable, they'll get removed from testing fairly routinely; if they should be dropped altogether as obsolete, bugs need to be filed
[17:56] <\sh> slangasek, ok..so I'm asking the octave team what should be done with this package..I can't find any new upstream nor is it building with octave3.0
[18:14] <\sh> ok..one package still left for octave3.0 transition...it's building right now...after this, we can start with the sync and upload orgy
[18:15] <jonnymind> I got this problem; I have a dev package that contains a binary file (which is used only in dev things, i.e. useless to normal users).
[18:15] <jonnymind> I have also a dev-dbg package that contains its debugging symbols.
[18:15] <jonnymind> is that ok?
[18:16] <geser> jonnymind: does the -dev package need really an extra -dev-dbg package?
[18:16]  * LucidFox pings RainCT
[18:16] <jonnymind> yes, as there is a binary file that is not in the normal non-dev package.
[18:16] <jonnymind> If that is a problem, I may just put the developement binary helper in the main package.
[18:17] <jonnymind> If it's not a problem, that would be logically cleaner.
[18:17] <geser> aren't the automatic -dbgsym packages sufficient for debuging?
[18:17] <davies> LucidFox: /whois RainCT
[18:17] <jonnymind> I am generating them.
[18:17] <LucidFox> davies> I know :)
[18:18] <jonnymind> The point is that I have this dev package with a binary /usr/bin file, which has to be stripped/debug enabled.
[18:18] <davies> LucidFox: so why ping? :)
[18:18] <geser> jonnymind: the buildds create for every package a -dbgsym package containing the debugsymbols
[18:18] <jonnymind> this requires a dbg package... I just asked if there is any problem in having a dev-dbg package for the dev package.
[18:19] <jonnymind> So, It's ok if I have an extra dbg package for the dev package, right?
[18:19] <geser> jonnymind: there is no problem
[18:19] <jonnymind> Oh, thanks. :-)
[18:19] <geser> jonnymind: btw how big is the binary?
[18:19] <jonnymind> about 40 kb
[18:20] <jonnymind> the dbg symbols are about 16kb.
[18:20] <geser> because every extra package makes the Packages files bigger
[18:20] <jonnymind> But they may grow a lot in the future.
[18:20] <jonnymind> If this is a concern, I can just put that helper binary in the non-dev package.
[18:21] <blueyed> jdong: have you solved "Can someone confirm/explain why sudo seems to forget environment variables?" (from #ubuntu-devel some hours ago)? It's likely because all/more env vars get dropped by sudo now. See "sudo -E" / env_reset.
[18:22] <jdong> blueyed: no, I was still wondering about that
[18:22] <jdong> blueyed: thanks re. -E
[18:22] <jdong> I'll have to update prevu's documentation regarding it
[18:22] <jdong> the tool uses environment variables to communicate some settings
[18:22] <joejaxx> yay xorg is finished compiling :DD
[18:22] <joejaxx> :D  *
[18:23] <blueyed> jdong: I've read your question on irclogs.u.c - it affects e.g. pbuilder, too (there's a bug filed about it)
[18:24] <jdong> blueyed: thanks :)
[18:29] <bddebian> slangasek: You bored?
[18:30]  * azeem chuckles
[18:30] <bddebian> :)
[18:33] <\sh> wine 0.9.54 ... oh I'm so lucky
[18:51] <joejaxx> hmm
[18:52] <ScottK> \sh: Thank you for becoming a MOTU again ... ;-)
[18:52] <\sh> ScottK, hmm...
[18:54] <\sh> ScottK, was your statement ironical? ;)
[18:55] <ScottK> \sh: Not entirely as I was worrying about WINE uploads during your sebatical (thank you for reviewing the packages for me then).
[18:55]  * ScottK is really glad you're doing it now.
[18:56] <\sh> ScottK, well there is no package right now...I'm building myself..
[18:57] <ScottK> Ah.  Scott Ritchie didn't do it?
[18:57] <\sh> ScottK, there is nothing on winehq...I can't get him...
[18:58] <ScottK> Hmmm.
[18:58] <ScottK> He's here...
[18:58] <ScottK> YokoZar: You around?
[18:58] <\sh> ScottK, I want to start with wine PPA packages, so we can stop backporting and using the PPA because people are using normally the packages provided by winehq
[18:59] <\sh> ScottK, #ubuntu-wine :) I asked him already :)
[18:59] <ScottK> Ah.
[18:59] <\sh> ah well..0.9.54 was released today ,)
[18:59] <ScottK> You're doing the work, so whatever you want, but I think it's better to keep in the official archives if we can.
[19:00] <ScottK> My clamav PPA is just for testing until we do get stuff backported (for example).
[19:00] <\sh> ScottK, yeah...this we can do still...but I like to have a version which works on former releases even in backports...so if we need to make debian/control changes or other things inside debian/ dir it's better to test it via ppa
[19:01] <ScottK> Agreed it's better to test via PPA.
[19:16] <Kopfgeldjaeger> hi
[19:17] <Kopfgeldjaeger> could someone please have a look at #178845 and sponsor it (if possible)?
[19:18] <jdong> Kopfgeldjaeger: hi, it's on my TODO list
[19:18] <Kopfgeldjaeger> ok, thank you
[19:24] <\sh> ScottK, can you do me a favour?
[19:25] <ScottK> \sh: Maybe?
[19:25] <\sh> ScottK, and re-check bug #185959 if I catched all packages, build-dep / build-dep-indep / depend on octave (so including octave2.1 and octave2.9)
[19:25] <ubotu> Launchpad bug 185959 in xmds "octave3.0 transition" [Undecided,Confirmed] https://launchpad.net/bugs/185959
[19:25] <\sh> ScottK, I think I have all packages...but good to have a second pair of eyes ;)
[19:25] <ScottK> Sure.
[19:26] <\sh> ScottK, thanks a lot :)
[19:27] <\sh> ah one I have still...
[19:27] <\sh> oh this is only recommends
[19:28] <\sh> and it will catch Recommends: octave
[19:30] <ScottK> blueyed: reportbug has a lot of lintian complaints (I'm looking at your bug fix now).  Any chance you could work on fixing the rest up and sending it back to Debian?
[19:40] <pwnguin> is it too late to request a package be resync'd from debian?
[19:40] <geser> pwnguin: not until FF which is around Valentines Day
[19:40] <pwnguin> neat
[19:41] <geser> but check that it doesn't break other things
[19:44] <\sh> wine 0.9.54 hits hardy
[19:50] <ScottK2> Yum.  Does it backport?
[19:53] <\sh> ScottK, nope...not now ;)
[19:53] <\sh> libgif breaks it
[19:54] <\sh> I do some backport stuff next week...after I worked with pitti the octave3.0 stuff...I'll go off now, I think for today I did enough motu work ;)
[19:58] <\sh> ok good night folks :)
[20:12] <saivann> DaveMorris : If you get time for it, I applied needed changes to simdock package, which you can review again here : http://revu.tauware.de/details.py?package=simdock
[20:12] <saivann> DaveMorris : thanks for this
[20:14] <DaveMorris> yeah, I'll do it once I've kicked my program off to build in a bit
[20:25] <oly-> hi, i am building packages with dpkg-buildpackage, is there a way to output the resulting files to another location ?
[20:37] <slangasek> bddebian: boredom is a disease of the mind
[20:38] <slangasek> and with that, I'm off for the night :)
[20:38] <Coper> Hi, I have followed the guide "Packaging with Debhelper" and have a new package for a new application console-freecell. I have added a new bug report id:186016 and assing it to me with status In progress.
[20:40] <ScottK> Coper: Once you think it's ready, you can upload it to REVU.
[20:40] <ScottK> !revu | Coper
[20:40] <ubotu> Coper: REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[20:41] <Coper> ScottK: okey, I will look in to it and will be back with some more questions. :)
[20:53]  * ScottK hugs sabdfl (even though he's not here right now) [see MC ML for details].
[21:11] <Coper> REVU admin can you resync the REVU uploaders keyring?
[21:11] <ajmitch> ScottK: someone buy that man a beer
[21:13] <ScottK> Absolutely.
[21:16] <crimsun> "And today, in 'As The Ubuntu Turns'..."
[21:19] <DaveMorris> saivann: commented
[21:23] <blueyed> ScottK: re reportbug.. do you mean fixing bug 163924 correctly, including the lintian fixes and then also submitting it to Debian?
[21:23] <ubotu> Launchpad bug 163924 in reportbug "manpage should mention that the default in Ubuntu is not to send to Debian" [Low,Triaged] https://launchpad.net/bugs/163924
[21:24] <rexbron> Looking for some review karma? Check out http://revu.ubuntuwire.com/details.py?package=libopenfx
[21:24] <ScottK2> rexbron: Reviewing doesn't give karma.
[21:25] <rexbron> Not LP karma, just the general kind
[21:25] <ScottK2> leonel and sommer: New clamtk in edgy/feisty/guty clamav-ppa for your testing pleasure.
[21:25] <ScottK2> Oh.
[21:25] <rexbron> Snap.
[21:30] <sommer> ScottK2: sweet, everything need restested, or just those apps with issues?
[21:33] <saivann> DaveMorris : Greaet, thanks
[21:33] <saivann> Great*
[21:33] <ScottK> sommer: New clamtk, not clamav
[21:33] <cbx33> hey guys
[21:34] <cbx33> anyone use enlightenment?
[21:34] <sommer> ScottK: ah, should have read closer
[21:34] <sommer> I'll give it a spin this evening
[21:34] <ScottK> No problem.
[21:34] <ScottK> Great.  I expect it's fine.
[21:35] <ScottK> Actually, I tested it on Guty before uploading, so I'll mark that down.
[21:37] <leonel> ScottK  clamtk works  fine in Gutsy
[21:41] <Coper> I have some problem to recive a password from revu, it says that no REVU account exists for my email.
[21:42] <leonel> ScottK2:   clamtk works  fine in Gutsy
[21:43] <leonel> scottK2 scottK testing in feisty
[21:48] <blueyed> Coper: have you uploaded anything yet?
[21:50] <Coper> blueyed: yes, I did "dput revu package_version_source.change" and go Succsessfully uploaded packages.
[21:52] <blueyed> Coper: then the keyring might not be synced yet. There is probably someone around who could do this. siretart?
[21:52] <blueyed> Can the keyring not get synced when someone unknown uploaded something? would me handsome.. ;)
[21:53] <Coper> blueyed: okey, I got a warning "This key is not certified with a trusted signature!"
[21:53] <blueyed> what key?
[21:54] <Coper> my gpg key.
[21:54] <blueyed> And where does the warning come from? Can you encrypt mails and text successfully?
[21:57] <Coper> I have no problem with encrypting email or text I get the warnings when Checking Signature on .dsc It says that it's a good signature but get a warning that it's not certified.
[22:07] <DaveMorris> what is the mythbuntu site running on?  CMS wise
[22:11]  * DaveMorris opps, wrong channel
[22:11] <_MMA_> DaveMorris: I see drupal mentioned in the page source. For whatever thats worth.
[22:15]  * DaveMorris has an account on the server but can't remember his password for, otherwise I could check that way
[22:52] <emgent> heya people
[22:59] <ScottK> blueyed: Please make lintian happy while you're working on reportbug too.
[23:05] <sommer> ScottK: new clamtk good to go on Edgy
[23:06] <ScottK> Great.
[23:19] <leonel> scottK clamtk  OK on feisty
[23:20] <ScottK> great
[23:21] <mgdm> Hi - I have a potentially dumb question. Is it bad form to package and upload something I've written myself...?
[23:22] <DarkMageZ> mgdm, only if it's malware.
[23:23] <mgdm> DarkMageZ: I assure you it isn't ;)
[23:24] <StevenHarperUK> Hi everyone
[23:24] <DarkMageZ> mgdm, then feel free to upload it ?
[23:24] <mgdm> It's a little GNOME applet written in PyGTK for use with Asterisk. When it's in better shape, I'll package it.
[23:24] <StevenHarperUK> I have a question : I have an Idea on how to improve the Resolution Gnome Applett, I cant find the launchpad project to put my suggestion into can anyone help me find it?
[23:26] <DarkMageZ> StevenHarperUK, you mean gnome-display-properties?
[23:27] <StevenHarperUK> is that | System | Prefrences | screen resolution
[23:27] <DarkMageZ> yes
[23:27] <StevenHarperUK> Can I bounce my suggestion off you>
[23:29] <DarkMageZ> go ahead ?
[23:30] <StevenHarperUK> Ok at the moment you can pick a resolution for a user - What im thinking is that the Xorg file - the first resolution in the list supported by the Screen you have is always the one you get on the Login screen : if you move a nice entry to the start of the list you get that : on my 22" monitors it picks stupid res like 2048x1024, I would move a nice one to the front on user selection
[23:31] <Coper> If I have dsc file and succsessfully build it in pbuilder can I generate a deb file and try it on my system?
[23:31] <StevenHarperUK> So you could have an option name : login screen Resolution (and all unset users) or simular
[23:31] <StevenHarperUK> what  do you think
[23:32] <DarkMageZ> StevenHarperUK, i've been wishing for that for awhile. you might want to see if there's a bug about it in the gnome bug tracker. if not then search launchpad for one. if not then file a bug or a specification about it ?
[23:32] <DarkMageZ> StevenHarperUK, you'll want to file it against gnome-control-center ?
[23:33] <StevenHarperUK> Ill go look 1 sec
[23:34] <StevenHarperUK> OK that looks like it : should I raise a bug and a blueprint?
[23:35] <DarkMageZ> i'm not sure which one is most appropriate
[23:35] <StevenHarperUK> I haven't done this before
[23:35] <StevenHarperUK> Id say blueprint
[23:36] <StevenHarperUK> As it as a new feature - setting the login screen res
[23:36] <DarkMageZ> true
[23:36] <DarkMageZ> once you've created it, subscribe me ?
[23:37] <DarkMageZ> tho don't force my involvement. just make it so i get the emails about it ?
[23:37] <StevenHarperUK> OK - I may plan to help code - I am a developer and have packages myself
[23:40]  * jdong verifies the avidemux package he promised Kopfgeldjaeger 
[23:40] <DarkMageZ> ah, well. i think the best way to do this then would be to talk to the guys in (i think it's #ubuntu-devel). see what their thoughts are and how they think the best method of implementation would be (yay for idea gathering). then submit a patch ?
[23:40]  * Kopfgeldjaeger jumps up, screams "YEAH!" and hugs jdong
[23:42] <jdong> Kopfgeldjaeger: tested and uploaded :)
[23:42] <Kopfgeldjaeger> yeah :)
[23:43] <Kopfgeldjaeger> thank you
[23:47] <Kopfgeldjaeger> jdong: btw, there's a little typo in the description (see http://packages.ubuntu.com/hardy/graphics/avidemux ): verison instead of version
[23:47] <Kopfgeldjaeger> anyway,
[23:47] <jdong> Kopfgeldjaeger: gack just after the upload completed... at any rate I wanted to give Matvey the credit for this upload without mangling; please file a quick bug report on it and we'll take it from there
[23:48] <StevenHarperUK> DarkMageZ: your subscribed
[23:48] <Kopfgeldjaeger> ok, maybe yesterday
[23:48] <Kopfgeldjaeger> good night
[23:48] <jdong> Kopfgeldjaeger: night :)
[23:49] <goodhabit> Hello. Help me please. I have all binary files compiled. Can someone help me with *.deb file composing? I am newbie. :|
[23:50] <Aloha> goodhabit, dpkg-buildpackage -rfakeroot will build deb
[23:50] <StevenHarperUK> goodhabit: what are you developing in
[23:50] <StevenHarperUK> Python?
[23:51] <goodhabit> I am not developer. Actually I am newbia @ IT at all. All day gone for compiling it :)
[23:51] <DarkMageZ> !ubuntupackagingguide
[23:51] <goodhabit> Nonono.
[23:51] <goodhabit> I have read it all.
[23:51] <StevenHarperUK> goodhabit: so what you trying to do : make a package from source?
[23:52] <goodhabit> Some parts are impossible fo me. The packaging wants some rules of tar.gz file, which I cannot do.
[23:52] <goodhabit> Nope
[23:52] <goodhabit> I have compiled allready.
[23:52] <goodhabit> I have all files instaled with --prefix
[23:52] <goodhabit> I need to have *deb file.
[23:53] <DarkMageZ> goodhabit, it's difficult to turn a current installation into a .deb . maybe you should build the package from scratch.
[23:53] <goodhabit> DarkMageZ, can you guide me?
[23:53] <DarkMageZ> goodhabit, the ubuntu packaging guide contains all the guidance that one should need.
[23:53] <StevenHarperUK> goodhabit: I have an example project that has build scripts
[23:54] <goodhabit> Some parts of that guides are really impossible for me.
[23:54] <DarkMageZ> goodhabit, how so?
[23:54] <goodhabit> You know, I am not developer. I can send e-mails. Recieve e-mails. Play music, watch video :)
[23:55] <jdong> goodhabit: at one point, none of us were. We'd be glad to help explain/clarify things if you're interested :)
[23:55] <goodhabit> Can somebody help with packaging (small aplication)
[23:55] <goodhabit> I see.
[23:55] <Aloha> goodhabit, why are you creatinga deb package if you know nothing about developing?
[23:56] <goodhabit> Aloha, I want to use that software, and cannot find the deb file.
[23:56] <Aloha> goodhabit, if its compiled just run it
[23:56] <StevenHarperUK> goodhabit: what is the software
[23:57] <goodhabit> wired http://sourceforge.net/projects/wired/ there are packages @ ppa, but they are outdated.
[23:57] <crimsun> goodhabit: have you checked with the Ubuntu Studio folks?
[23:57] <crimsun> IIRC, someone was working on it.
[23:59] <goodhabit> crimsun, why folks :) ?