[00:01] <terli> bloody good example.
[00:01] <soc> terli: "patented software needs a copyright." wth?
[00:01] <soc> what has copyright to do with patents?
[00:02] <directhex> hear hear
[00:02] <terli> what does db_get do
[00:03] <terli> soc : copyright, license, you name it
[00:03] <terli> legal shmega
[00:03] <directhex> terli, they're all very different things
[00:03] <terli> patented meaning proprietary
[00:03] <directhex> terli, terms aren't interchangable
[00:04] <terli> right, right, but my brain is of the sort that can replace tomatoe with table in a second
[00:04] <terli> what does db_get do
[00:06] <LaserJock> doesn't that get stuff from the template?
[00:06] <terli> so if I have a file named templates
[00:06] <terli> with two entries in it marked parallels/accept_licence and parallels/license
[00:06] <LaserJock> right
[00:06] <terli> accept_ being the boolean and license being the text itself
[00:07] <LaserJock> yep
[00:07] <terli> db_get parallels gets both?
[00:07] <terli> no. can't be.
[00:08] <LaserJock> well, look at the example
[00:08] <LaserJock> db_get debconfdemo/accepted
[00:08] <LaserJock> if [ "$RET" = "true" ]; then
[00:08] <LaserJock>     exit 0
[00:08] <LaserJock> fi
[00:08] <LaserJock> so it grabs debconfdemo/accepted and then tests if it returns true or false
[00:09] <crimsun> be careful with forcing the user to accept the agreement prior to proceeding. you're in a position to design it properly now. the major point of contention will be blocking distribution upgrade progress.
[00:10] <crimsun> i.e., i install foobar, update && full-upgrade, walk away for a week, and find the upgrade is blocking on my input
[00:10] <terli> crimsun, your a god, but this package will never, ever, ever make it into the repo.
[00:10] <terli> it's proprietary and binary.
[00:10] <LaserJock> so?
[00:11] <terli> so the only upgrade possible is manual.
[00:11] <crimsun> sure, that's fine, and there are plenty of examples that did in fact use a hard-stop query, like the sun-java[56] in multiverse
[00:12] <LaserJock> terli: I'm saying prorietary and binary packages are allowed
[00:12] <terli> Nobody maintains this package, and I'm not capable of complying with the universe rules.
[00:12] <terli> , now, if you want to upload it for me, thats a different matter
[00:13] <LaserJock> not I, been there, done that, still reaping the "benefits" :-)
[00:13] <terli> the source package I edited was sudo extracting a tar file in /usr/lib/programdir
[00:13] <terli> made removing all of it a headache
[00:17] <savvas> terli: what's the name of the software?
[00:17] <terli> parallels.
[00:17] <terli> I'm doing some work to get rid of my howto
[00:17] <terli> and stop breaking dash/bash
[00:18] <coppro> http://revu.ubuntuwire.com/details.py?package=metakit <-- comments would be appreciated
[00:19] <terli> subprocess pre-installation script returned error exit status 255
[00:24] <terli> http://pastebin.com/m238dc41a
[00:25] <terli> er, umm
[00:25] <terli> http://pastebin.com/m699a61f3
[00:26] <terli> there
[00:41] <soc> could someone review/advocate my package? ... http://revu.ubuntuwire.com/details.py?package=ttf-droid
[00:42] <soc> it should be totally clean and nice now ...
[00:42] <terli> Template parse error near `.', in stanza #2 of ./templates
[00:47] <slicer> The requestsync script in intrepid misbehaves a bit if you're a member of the launchpad betatesters group :)
[00:48] <slicer> Specifically, it submits the bug report 5-6 times, then crashes.
[00:49] <coppro> use it to submit a bug against launchpad?
[00:49] <coppro> :P
[00:51] <TheMuso> /c/c
[00:56] <slicer> Ok, what should I do with the duplicates? Is there a way to delete them, or do I need to mark them as duplicates?
[00:56] <slicer> It seems a bit silly now with 5 identical reports in a row.
[00:57] <coppro> in what?
[00:57] <slicer> bug 315291
[00:57] <slicer> bug 315292
[00:57] <slicer> etc etc up to 315295
[00:59] <slicer> I'll mark them duplicates for now, that should at least remove them from the trackers.
[01:00] <terli> is there a db_display variable?
[01:01] <terli> I need someone to tell me three db_ commands
[01:11] <nschembr> I'm looking for a little help, OK everyone need help:) I'm looking for someone who works with the init scripts.
[01:12] <directhex> which init scripts?
[01:13] <nschembr> Let me look.
[01:15] <nschembr> somewhere before /etc/initramfs-tools/scripts/init-bottom/ in the init process
[01:18] <nschembr> how about someone working on the netbook remix
[01:24] <maxb> nschembr: You are not being very specific about what you need help on - specific questions are better because they allow people to see whether they can actually help or not, quickly
[01:27] <terli> hey , could someone show me how to put my license in a debconf tag?
[01:28] <directhex> terli, a EULA-style you-mist-agree license?
[01:29] <directhex> terli, an old sun-java6 package should provide something to copy
[01:29] <terli> yes
[01:29] <terli> no
[01:30] <savvas> the non-free virtualbox has a license agreement if I recall correctly
[01:31] <directhex> i just remember java needing it. the sun distributor license or somesuch
[01:31] <terli> I have it on my screen
[01:31] <terli> it's not working
[01:31] <directhex> it doesn't have a job? for shame, my taxes are paying for it to lounge around at home!
[01:32] <terli> it's no use to me
[01:32] <directhex> and why is that?
[01:33] <terli> its all nice and all that
[01:34] <terli> hmm
[01:34] <terli> I ran the script from a terminal
[01:35] <terli> it just ran through, didn't prompt me or anything
[01:35] <terli> but its not crashing
[01:35] <Hobbsee> had you already accepted the licence once, and are now trying to accept it a second time?
[01:35] <terli> no, I'm building the bloody package
[01:35] <Hobbsee> oh, right.
[01:35] <directhex> ran which script from a terminal?
[01:36] <terli> quiet.
[01:36] <terli> ok, now it failed to install, but that's my fault
[01:37] <terli> I can feel it
[01:37] <terli> the preinst is configured to db_go parallels
[01:37] <terli> the parallels file is configured to:
[01:38] <terli> db_input critical license; db_input critical license_accepted;db_go; db_get license_accepted;if [ "$RET" = "true" ]; then
[01:38] <terli>     exit 0
[01:38] <terli> fi
 the preinst is configured to db_go parallels <--- are you saying you actually have a line "db_go parallels" in the preinst?
[01:39] <terli> yes?
[01:39] <maxb> because that would be meaningless
[01:39] <maxb> db_go doesn't take an argument
[01:39] <terli> how do I get preinst to pass control to my script?
[01:39] <maxb> you don't
[01:39] <terli> and does db_stop belong in there?
[01:40] <maxb> You've misunderstood how debconf works. You shouldn't have a 'parallels' file.
[01:40] <terli> I have preinst , a file called parallels and one marked parallels.templates
[01:41] <terli> preinst is supposed to use debconf to run parallels , which is a script that uses the parallels.templates file to show license details
[01:41] <maxb> uhm, no
[01:41] <terli> then explain how it's supposed to work.
[01:41] <maxb> You don't use debconf to run things
[01:42] <maxb> You use debconf to interact with some abstract UI
[01:42] <terli> I don't think you understand.
[01:42] <terli> you are supposed to help me, not contradict me.,
[01:42] <maxb> Part of helping is pointing out misunderstandings
[01:42] <terli> what should i do for preinst to get my script implemented
[01:43] <terli> it's just a file called parallels that starts with a  line marked #!/bin/sh, think of it as any other script file.
[01:43] <directhex> you don't write a script, you write a debconf template. preinst calls debconf using that template, and bails if your haven't accepted it
[01:44] <terli> no, I've relocated the details of what debconf does to a different file.
[01:44] <maxb> Well, don't do that
[01:44] <maxb> Doing that goes against all standards of how to use debconf
[01:44] <directhex> to what end? now you're talking about making that different file available outside the package, which is enormously messy
[01:44] <terli> well, then, I suggest you inform me about the correct way.
[01:44] <directhex> he tried, you told him off for it
[01:44] <terli> the different file is IN the package
[01:44] <terli> it's IN /debian
[01:44] <maxb> The correct way was the way I did it in the prewritten example I gave you
[01:45] <maxb> Which is the same way sun-java does it
[01:46] <directhex> please look at debian/dlj.templates and debian/JB-jdk.preinst in sun-java6
[01:46] <directhex> you can't use preinst to call things in data.tar.gz
[01:46] <terli> so I have a line marked db_get parallels/license which corresponds to a template marked parallels/license in the file parallels.templates
[01:46] <terli> direct hex, everything is in the folder marked debian in the root of the archive.
[01:48] <directhex> the semantics are more complex than that though. a binary package is split into multiple parts. the actual data section, the files to which you'd be agreeing to a license, are not the same as the metadata - that way you can't install it if you don't agree with the license
[01:48] <terli> the license is in the metadata, and in the data.
[01:48] <terli> two copies.
[01:48] <terli> you agree to the copy stored within templates
[01:49] <terli> it's identical to the other copy
[01:49] <terli> but you don't have to explicitly agree to the other copy, you already did that with the first one during installation.
[01:49] <directhex> but you don't want to use the template, you want to run a script. and the script does not form part of the control.tar.gz section of the package, which contains metadata like templates and preinst
[01:50] <terli> the script isn't in the control.tar.gz
[01:50] <terli> it's in debian!
[01:50] <terli> preinst isn't in control.tar.gz either
[01:50] <directhex> yes, it is.
[01:50] <directhex> after you compile the source package, anyway
[01:50] <directhex> which is the point
[01:50] <terli> I don't have a source package.
[01:51] <directhex> however, it's 1:50am, and you clearly already know best, so i'm going to bed.
[01:51] <terli> I'm using DEBIAN folder and usr folder.
[01:51] <maxb> oh, argh, do you literally mean DEBIAN, uppercase?
[01:51] <terli> literally.
[01:52] <maxb> Are you seriously attempting to MANUALLY assemble a debian binary package without a source package being involved?
[01:52] <terli> There is no source.
[01:52] <terli> it's all binary blobs to begin with.
[01:52] <directhex> a source package doesn't mean source. you think sun-java6 includes source?
[01:52] <directhex> or nvidia-glx?
[01:53] <directhex> directhex@mortos:/tmp$ ls sun-java6-6-10/
[01:53] <directhex> debian  jdk-6u10-dlj-linux-amd64.bin  jdk-6u10-dlj-linux-i586.bin
[01:53] <directhex> that's a source package
[01:53] <terli> well , this one doesn't.
[01:53] <directhex> wheeeeeeee
[01:53] <directhex> bed.
[01:54] <maxb> terli: You are seriously making things hard for yourself.
[01:54] <terli> I don't know what you mean by easy.
[01:54] <terli> I don't know the correct way to build the package, because I don't have the requisite files.
[01:55] <maxb> Well, you seem to be ignoring the minimal example I gave you, and the example of sun-java, and trying to forge your own way by a different path
[01:55] <terli> I didn't ignore your example
[01:55] <terli> I couldn't use it
[01:55] <terli> waitr
[01:55] <maxb> why not?
[01:55] <terli> you didn't give me a different example from my own!
[01:55] <terli> my list of files IS identical to yours.
[01:55] <terli> I put the script in preinst
[01:55] <maxb> I never had a DEBIAN
[01:55] <terli> and now I just have templates and preinst
[01:56] <terli> well I don't know where you put it then
[01:56] <terli> THIS package's source had a debian.
[01:56] <maxb> debian/ and DEBIAN/ are *different*
[01:56] <terli> I mean DEBIAN.
[01:56] <StevenK> You shouldn't be playing in DEBIAN/
[01:56] <terli> I don't know the difference.
[01:57] <terli> it's a *debian* package, anyway.
[01:58] <maxb> Well, either read up about it in the Debian Policy Manual, or just trust us that if you are messing with a DEBIAN/ directory you're doing it wrong
[01:58] <directhex> you want to generate a SOURCE PACKAGE. christ, we could be done by now. a SOURCE PACKAGE does not require source for parallels, before you start, it just means a rational sane way of building all the required files in the right places using a plethora of helper tools. a source package consists of whatever you have from upstream, plus a debian/ folder. that's it.
[01:58] <terli> well, I've gotten far enough that the installer is saying, template parse error near `text` in stanza #1
[01:58] <terli> well, directhex, I don't know how that works.
[01:58] <terli> can I just rename DEBIAN to debian?
[01:58] <directhex> terli, if you wanted to zip a file, would you use a zip tool, or a hex editor?
[01:58] <StevenK> Nope, you can't
[01:59] <terli> if I wanted to zip it I would use zip
[01:59] <terli> or tar
[01:59] <directhex> terli, right now you're using vi.
[01:59] <terli> I used dpkg -b to generate my package from the folders specified in the wiki...
[02:00] <terli> I tried to use data.tar.gz and control~, really I did, but I couldn't get it to make the . folders.
[02:01] <directhex> if you ever see data.tar.gz or control.tar.gz, ur doin it wrong. those files are generated as part of package creation, by dpkg-buildpackage
[02:01] <maxb> terli: What wiki are you reading? You've apparently found your way into some deep dark internals documentation
[02:01] <terli> I did.
[02:01]  * Hobbsee reads the backscroll, and raises an eyebrow
[02:01] <maxb> What, only one eyebrow? :-)
[02:01] <terli> I had to open the archive in archive manager, extract it, then edit the contents.
[02:01]  * directhex lowers Hobbsee's eyebrow with his poking stick
[02:01] <terli> then re-compress it to a archive.
[02:01]  * directhex falls off his desk
[02:01] <directhex> UR DOIN IT WRONG
[02:01]  * Hobbsee raises the other eyebrow at that
[02:02] <Hobbsee> well, no wonder it isn't working.
[02:02] <terli> I don't know what other way there is, I wasn't taught anything about any of this.
[02:02] <crimsun> (you silly people. i would have used Hobbsee's stick to zip.)
[02:02] <terli> and it works fine, I just can't get debconf to parse my note/eula thingy
[02:03] <terli> did you know, before I was using their archive(the official one) , and having to manually replace sh with bash because the maintainer screwed up and made his script call /sh instead of bash
[02:03] <maxb> terli: You are poking about in internals that developers don't bother to deal with directly. I (and probably most others here) have no idea how the templates are supposed to be packed into the binary deb, because we use tools that do it for us
[02:04] <maxb> Oh
[02:04] <terli> maxb: I have no idea where the tools are.
[02:04] <terli> but if you don't know how
[02:04] <terli> then something has gone seriously wrong
[02:04] <maxb> Finally it becomes clear *why* you're approaching it this way
[02:05] <maxb> It was not clear to me until just now that you were actually trying to repackage an existing .deb file
[02:05] <terli> exactly!
[02:05] <directhex> dpkg-repack - puts an unpacked .deb file back together
[02:05]  * maxb headdesks
[02:05] <maxb> I wrote my own one of those too
[02:05] <terli> sorry, I've already deleted it.
[02:06]  * maxb wonders just how much of his ~/bin/ has packaged equivalents, if you know where to look :-)
[02:06] <terli> anyway, it's clear to me that in one way, I clearly am superior to you(I'm fooling around with sith bathrooms in the debian temple), and in another way, I havn't the vaguest idea what I'm doing.
[02:07] <terli> db_input critical license
[02:07] <terli> db_input critical license_accepted
[02:07] <terli> db_go
[02:07] <terli> db_get license_accepted
[02:07] <Hobbsee> terli: dude, take the attitude elsewhere.
[02:07]  * maxb awards terli the ultra-bizarre-metaphor prize
[02:07] <terli> Hobsee; I don't have the vaugest idea how I'm supposed to package this without your help.
[02:07] <Hobbsee> terli: there is no reason anyone *has* to help you, and the more you show your attitude, the more likely it is that you'll be ignored.
[02:08] <Hobbsee> terli: well then, you should clearly try to be polite, stop telling people to be quiet like they're your dog, listen to what they say, whether you agree with it or not, and stop saying you're superior, no?
[02:08] <terli> yesno, yes, ok.
[02:11] <terli> I'm waiting.
[02:12] <maxb> Well, it's past time for me to be asleep, so don't wait for me.
[02:12] <Hobbsee> oh, and maybe you already wore out your welcome with your comment on being clearly superior, so you may find that no one's going to deal with you anyway
[02:13] <Hobbsee> so, wait away.
[02:13] <terli> Well, you did see me admit in one and the same sentance that I don't know what I'm doing.
[02:13] <terli> Not knowing what I'm working with is humiliating and frustrating.
[02:32] <nschembr> I've  worked on a project to use aufs as the root file system. I have posted the howto, https://help.ubuntu.com/community/aufsRootFileSystemOnUsbFlash
[02:32] <nschembr> At this point I'm stuck.  I think it should be integrated into the main init script. I think this would help the  people building netbook distro's.
[02:36] <nschembr> Is anyone working on netbooks or the init process.
[03:00] <anakron> Hi all
[03:05] <maxb> nschembr: I realize I'm being incredibly obsessive, but: There's no such thing as Ubuntu 8.4
[03:05] <maxb> Sorry, personal irritation of mine :-)
[03:32] <nschembr> maxb: Attention to detail noted and corrected. :)
[03:35] <maxb> I'm not sure how this fits with netbooks. Surely having your documents vanish when you reboot is a bit of a pain
[03:40] <persia> Actually, none of the Ubuntu Mobile flavours use stacked filesystems post-install anymore.
[03:40] <persia> The live session uses a stacked filesystem.
[04:35] <rhpot1991_laptop> cody-somerville: ping, I updated bug 297019
[06:30] <dholbach> good morning
[06:37] <fabrice_sp> Godd morning dholbach! :-)
[06:37] <dholbach> hiya fabrice_sp
[06:42] <iulian> Morning dholbach, fabrice_sp.
[06:42] <dholbach> hiya iulian
[06:44] <fabrice_sp> 'morning iulian !
[06:57] <didrocks> morning dholbach, fabrice_sp, iulian o/
[06:57] <dholbach> hiya didrocks :)
[06:58] <didrocks> dholbach: just to keep you inform all is going very well for localized UDW preparation on your last day proposal :)
[06:59] <dholbach> didrocks: perfect - can you follow up on the mail thread so the others know as well?
[06:59] <dholbach> didrocks: I'll start writing up the announce in a sec
[06:59] <dholbach> I wasn't feeling very well yesterday evening, so I do it today
[07:00] <didrocks> dholbach: I will do it later in the week-end (we are fixing the precise schedule)
[07:00] <didrocks> dholbach: oh :( do you feel better today?
[07:00] <dholbach> yeah, it's all good today :)
[07:01] <dholbach> didrocks: I was just thinking that the others might want to plan something similar so let them know about the plan early
[07:01] <didrocks> dholbach: ok, will do it today :)
[07:01] <dholbach> super
[07:01] <dholbach> thanks muchly
[07:02] <didrocks> you're welcome :)
[07:12] <fabrice_sp> Hi didrocks \o/
[07:31] <stefanlsd> hey guys.  where can i see the queue / status for the build servers building jaunty stuff?
[07:35] <iulian> stefanlsd: https://launchpad.net/ubuntu/jaunty/+builds
[07:35] <stefanlsd> iulian: thanks!
[08:40] <tbielawa> greetings, all!
[08:48] <slytherin> persia: there? need some guidance.
[08:48] <persia> Here.
[08:49] <persia> Again, I like *contentful* pings :p
[08:49]  * directhex pings persia with a large textbook
[09:00] <iulian> Heh
[09:01] <iulian> persia: Btw, just out of curiosity. Will you have some spare time to vote on my application this weekend or even today?
[09:03] <persia> iulian, I'm nearly done with review: I was hoping to finish yesterday, but didn't quite.  Should be in the next few hours.
[09:04] <iulian> persia: Oh, that's great!
[09:04] <iulian> Thanks.
[09:05] <persia> Sorry it's been so long: there's really no excuse on my part.
[09:05] <iulian> No worries.
[09:30] <slytherin> persia: The problem is related to batik. The current version in Ubuntu is 1.7.dfsg-0ubuntu1. Where as Debian version in experimental is 1.7-1. According to dpkg 1.7.dfsg-0ubuntu1 > 1.7-1 so I will not be able to upload a merge from Debian. :-(
[09:31] <persia> Do the orig.tar.gz files differ?
[09:32] <slytherin> persia: yes they do.
[09:33] <slytherin> persia: our version has some code from fop as well (inline with what was done for 1.6). But that code is not needed any more.
[09:34] <slytherin> The main problem is how the buildd will treat the version from Debian. If it think that it is less than what we currently have then it will never get published.
[09:34] <persia> OK.  Then create 1.7.dfsg1-1ubuntu1.
[09:34] <persia> It's not ideal, but it's probably what we need until 1.8 comes out.
[09:35] <slytherin> persia: right. That is what just came to my mind. This problem will go away when we have 1.8.
[09:35] <persia> Right.  We just need to do some fakery to force use of the Debian orig.tar.gz, as I presume it's better.
[09:35] <persia> If nothing else, it makes it easier to merge later.
[09:38] <slytherin> by the way do we have any set policy for/against sync/merge from experimental? Debian experimental has fop 0.95. And it is unlikely to enter unstable until lenny is released.
[09:39] <directhex> slytherin, not just permitted, but more or less required during the lenny freeze
[09:39] <directhex> slytherin, most of the jaunty mono stack is smerged from experimental
[09:40] <slytherin> directhex: good then. I am wondering when will be lenny released.
[09:40] <directhex> slytherin, it'll come bundled with copies of duke nukem forever
[09:41] <slytherin> :-)
[09:43] <stefanlsd> hehe
[09:45] <persia> Best way to help lenny release is to help close the remaining RC bugs: they may well be bugs in Ubuntu as well, so it's not wasted effort.
[09:45] <directhex> i think i proposed a debian BSP a few months ago, but nobody seemed interested
[09:46] <persia> I thought we did one a few months ago: I remember a number of Debian bugs being discussed.
[09:46] <persia> Let's do another one this weekend.
[09:46] <Laney> directhex: Break off from the u-uk bug party in feb to do some debianing
[09:47] <Laney> :>
[09:47] <directhex> there's a u-uk?
[09:47] <Laney> but of course
[09:48] <Laney> we are planning on participating in the global bug jam
[09:48] <Laney> I expect to see you there!
[09:48] <directhex> is there a secret handshake involved?
[09:48] <directhex> or masks?
[09:48] <Laney> The secret incantation is /join #ubuntu-uk
[09:49] <Laney> if you can manage that then....
[09:49] <Laney> onto the initiation rituals
[09:49] <directhex> mmm, sounds hard. never mind then :/
[09:49] <Laney> boo
[09:52] <directhex> is it a sign i'm getting old if a major factor in which brands i buy for a new pc is the warranty?
[09:53] <persia> No, it's a sign that you've reached the threshold of your performance requirement: you no longer expect it will be cheaper or better to get a new machine when that one breaks.
[09:54] <stefanlsd> i get dell with 3 year next business day warranties. i cant be bother to go fix get parts to fix and replace hardware anymore
[09:54] <directhex> stefanlsd, the price diff between a dell with 1year rtb, and a self-build with a few lifetime warranties, on the spec i want, is already a few hundred quid
[09:56] <stefanlsd> mm. sounds alot. but if u think of the time and effort lost with self built. if u have the time, i guess self built will be easier
[09:56] <stefanlsd> well, cheaper anyways
[09:58] <directhex> it's a hobby!
[09:58]  * directhex looks at power supply warranties
[10:02] <persia> In addition to being a hobby, once you have a base set of components, you only replace some bits.  Frequently if you get a replacement for a failed component after a couple years, they send you a better one.
[10:03]  * directhex sets a 3 year psu warranty as a minimum
[10:03] <directhex> it's always the psu that pops
[10:04] <stefanlsd> is there a way to make bzr diff   -> quilt diff patches?
[10:04] <persia> Sure.
[10:05] <Laney> stefanlsd: quilt has `quilt import'
[10:05] <persia> Just extract the bzr patch, start the quilt patch creation process against the pristine source, apply the bzr patch, and save the new quilt patch.
[10:05] <persia> Oh, that's even better :)
[10:05] <stefanlsd> oh cool. thanks. will check out quilt import
[10:06] <stefanlsd> i do all my merge stuff in bzr. makes life soo nice
[10:06]  * Laney is old school
[10:06] <Laney> I await james_w's session with baited breath
[10:07] <stefanlsd> quilt import ffmpeg-headers.diff
[10:07] <stefanlsd> Importing patch ffmpeg-headers.diff (stored as ffmpeg-headers.diff)
[10:07] <stefanlsd> wow. and thats it. fixed the paths and everything
[10:07] <Laney> quilt is magical
[10:08] <directhex> hm, 5 year warranty from corsair. that's good. but they're uncheap
[10:15] <directhex> hm. /me reduces selection to choice of 8
[10:18] <slytherin> directhex: by the way, how much space is saved on CD now with the mono 2 transition?
[10:18] <directhex> slytherin, not enough yet, as not all libs have been done
[10:19] <directhex> a few meg afaik
[10:19] <slytherin> directhex: what is your estimate?
[10:19] <directhex> the estimate was ~18 meg
[10:19] <directhex> current figures... dunno, slangasek might though
[10:40] <ia> hello. could you tell me, please, if ./configure shows "<package> not found but required" message, then <package> should be added in Depends, or in Build-depends or in both fields in debian/control file?
[10:42] <persia> ia, Typically, Build-Depends.  It ought go to Depends from the ${shlibs:Depends} line.
[10:42] <ia> persia: ok
[10:43] <james_w> sebner: are you on beautifulsoup?
[10:44] <sebner> james_w: I wanted to do it next but have also other things to do if you want to take it
[10:44] <james_w> sure, I can do that
[10:44] <james_w> you were quicker than me on all the others, so I wanted to check
[10:44] <sebner> heh
[10:45] <sebner> james_w: I'm sorry :)
[10:45] <james_w> sebner: you better be :-p
[10:46] <james_w> sebner: I smiled at you requesting the contributor give reasons for the sync at this stage in the release cycle :-)
[10:48] <sebner> james_w: well, people learn and grow up
[10:48] <DktrKranz> james_w: link please! :)
[10:48] <sebner> james_w: but most times I checked upstream myself and since there were no heavy changes I ACKed. Besides FF if far away :P
[10:48] <sebner> DktrKranz: nah :P
[10:49] <james_w> sebner: yeah, there's no problem at this point
[10:50] <sebner> james_w: btw, we should add a note to the wiki -> Future MOTUs beware! There will always be wars and brutal fights for ACKing sync requests :P
[10:50] <james_w> heh :-)
[11:06] <Flimm> I'm packaging my own program, how should I handle translations of the package description?
[11:07] <directhex> debian/control? don't.
[11:07] <sll> hi room! I'm trying to do a deb package. do you know where can I find a good tutorial to do it? I read some tutorials but all show diferents way and for smal applications too.
[11:08] <Flimm> directhex: how will it get translated then?
[11:08] <slytherin> sll: which tutorials did you read?
[11:09] <Flimm> sll: what are you trying to package?
[11:09] <slytherin> Flimm: why do you need to translate them?
[11:09] <directhex> Flimm, i wasn't aware debian/control supported translation
[11:10] <Flimm> Well the Debian Description Translation Project seems to translate the descriptions somehow. http://ddtp.debian.net/
[11:12] <Flimm> But it seems like the translations are only in the repo, not in the packages themselves
[11:13] <directhex> seems that way. they ARE apparently supported in jaunty though -> http://archive.ubuntu.com/ubuntu/dists/jaunty/main/i18n/
[11:16] <Flimm> Ok, another question, what's the best way to package po translations?
[11:20] <james_w> vorian: hi, I'd like to clarify what license your manpages for ncpfs are under
[11:22] <sll> ok, I read spanish tutorials, and I think the problem is that I don't know about rules file. I'm trying to package this sources http://hangar.org/wikis/lab/pd/pdvjtools/src/
[11:23] <sll> they are externals/objects for puredata
[11:41] <sll> can you recomendme any tutorial about deb packaging?
[11:41] <pochu> !packagingguide
[11:42] <pochu> . o O ( how is backports related to the packaging guide? )
[11:43] <sll> ubottu: thanks :P
[12:32] <stefanlsd> james_w: heys. i think we can try sync imview again
[12:32] <james_w> is it built everywhere?
[12:32] <stefanlsd> where would i check that exactly?
[12:33] <stefanlsd> i've checked here - https://edge.launchpad.net/ubuntu/jaunty/+builds
[12:33] <pochu> for Debian? buildd.debian.org
[12:33] <pochu> (I guess it's for Debian as you're talking about a sync)
[12:34] <james_w> https://edge.launchpad.net/ubuntu/+source/imagemagick/7:6.4.5.4.dfsg1-1ubuntu2
[12:34] <james_w> so...yes
[12:34] <stefanlsd> pochu: it was a dep we were waiting for.
[12:34] <stefanlsd> cool
[12:40] <james_w> stefanlsd: still fails to build for me
[12:41] <stefanlsd> james_w: let me check
[12:41] <james_w> thanks
[12:41] <stefanlsd> actually straight after this libavg merge thats giving me hassles :)
[12:42] <coolbhavi> james_w, the previous version too was a ftbfs
[12:42] <james_w> coolbhavi: yeah, it's still the same version
[12:43] <coolbhavi> james_w, yup ... the latest version of the dependency isnt helping too
[12:47] <Laibsch> Hi
[12:48] <Laibsch> Can somebody please upload my patch from bug 254228 to intrepid-proposed?  It fixes a quite serious error in sqlite3
[12:48] <Laibsch> Sorry, wrong channel
[12:48] <Laibsch> This is a core package
[12:48] <Laibsch> from main
[12:49] <Laibsch> I'll give you another SRU request in a minute to chew on ;-)
[13:01] <vorian> james_w: BSD is fine with me, it'll keep all the manpages together
[13:01] <james_w> vorian: cool, thanks
[13:01] <vorian> no problem
[13:02] <vorian> thanks for asking
[13:02] <vorian> :)
[13:03] <Laibsch> Can you please release wordpress from -proposed to -updates?  (bug 227547)
[13:04] <DktrKranz> Laibsch: this is usually done by pitti, but is tagged as verification-done, so it's just a matter of time.
[13:04] <DktrKranz> s/but/bug/
[13:05] <Laibsch> OK
[13:05] <Laibsch> Thanks
[13:05] <DktrKranz> if you think it's extremely important, you can ask him in #ubuntu-devel
[13:06] <Laibsch> no, it's not the most important one
[13:06] <Laibsch> I've already asked about another SRU (which is much more serious) in #ubuntu-devel about a minute ago
[13:06] <Laibsch> That one is still to be uploaded to -proposed, though
[13:06]  * DktrKranz looks back when he was a motu-sru member :)
[13:07] <Laibsch> why did you loose the priv?
[13:07] <DktrKranz> lack of time by my side :(
[13:09] <DktrKranz> Universe needs people testing -proposed uploads, it's a shame we fix bugs and no-one is there to report it works :(
[13:10] <Laibsch> Well, I'm testing stuff
[13:10] <Laibsch> ;-)
[13:10] <persia> As much as it needs more -sru people, it needs more people in the testing team.
[13:11] <DktrKranz> ... or more peoploe running development versions
[13:12] <Laibsch> yeah, that is a problem
[13:12] <DktrKranz> many fixes I've seen going via -proposed/-updates could easily get fixed in time for the release.
[13:12] <Laibsch> I don't want to run development
[13:12] <Laibsch> stuff
[13:12] <Laibsch> But I help myself with Booting from USB and even more important with virtualbox
[13:13] <Laibsch> Those were some very important improvements for bug testing lately
[13:13] <DktrKranz> That's fine, but I realized I discover more issues using development version daily
[13:13] <Laibsch> that is of course true
[13:13] <Laibsch> But one has to do productive work, too, from time to time ;-)
[13:13] <Laibsch> or work that pays bills
[13:14]  * DktrKranz rethinks about gnat-4.2 transition made via SRU, what a pain!
[13:14] <Laibsch> I'm spending too much time with bug testing as it is, too much fun ;-)
[13:16] <DktrKranz> Ubuntu hasn't bugs, bugs are introduced by feature to avoid people to get bored.
[13:17] <slytherin> slomo: just curious ... is there plan to sync/merge libdvdread and libdvdnav from Debian experimental?
[13:19] <stefanlsd> james_w: yeah. still getting the build problem on imview.
[13:27] <james_w> stefanlsd: it looks like a pretty bust configure.in
[13:28] <stefanlsd> james_w: yeah. we prob could fix it and redo the .h files, but i think the point was the transition and imagemagick handling that stuffs. i'll check with lool.  he said his built...
[13:29] <james_w> stefanlsd: yeah, but imview's configure.in isn't that smart
[13:29] <james_w> doesn't set -I based on anything from imagemagick for instance
[13:30] <stefanlsd> james_w: yeah. i think a .h somewhere is looking for magick/api.h and its changed to ImageMagick/api.h  or something to that affect. need to confirm
[13:32] <james_w> stefanlsd: no, magick/api.h is still there you just need -I/usr/include/ImageMagick/
[13:39] <stefanlsd> james_w: kk. cool. will try it out. also just wanna check with loic. (would prefer a sync)
[13:47] <khashayar> james_w: about LP 314823: I was being confused about the diff.gz. So disregard of my second comment. The diff.gz that is attached works just fine. Would you mind taking a look at it when you have time? Thanks.
[13:47] <khashayar> I had a few things explained to me about diff.gz's by persia in #ubuntustudio-devel :-)
[14:04] <lool> stefanlsd, james_w: I pushed imview to my ppa yesterday (the one from jaunty yesterday), it ftbfsed, then I pushed a fixed imagemagick, hit rebuild on imview, and imview built on all arches; then I pushed imagemagick to jaunty
[14:04] <lool> You can check the Debian bug I referenced in the upload for details of the .pc file renames and the -dev renames
[14:04] <lool> And xine-lib for an example package with decent build-deps
[14:04] <lool> (which should work with old and new imagemagick
[14:05] <lool> (and older)
[14:09] <rhpot1991_laptop> morning cody-somerville
[14:21] <james_w> lool: yeah, but we're looking at the -3 upload where one of the changes is to fix it with imagemagick from experimental
[14:23] <james_w> ah, -> -devel
[14:40] <lool> james_w: Yup
[14:40] <lool> james_w: I also updated the bug
[14:40] <lool> james_w: I agree the configure is sucky
[15:02] <stefanlsd> lool: as a fix (prob ugly), uncommenting #           CPPFLAGS="$CPPFLAGS "`Magick-config --cppflags`  does get it to build.
[15:11] <lool> stefanlsd: *cough*
[15:11] <slayton> which of the deb helper scripts applies the patches under debian/patches?
[15:12] <lool> stefanlsd: But it's better than using AC_CHECK_LIB IMO
[15:12] <lool> (either use Magick-config or pkg-config, but don't check directly for headers or libs)
[15:12] <stefanlsd> lool: oh. it still uses that for other stuff. heh.
[15:12]  * RainCT is trying out KDE 4 beta. if someone wants to hear my rants about it, tell me to enable verbosity :P
[15:13] <stefanlsd> lool: am i on the right track here?   http://paste.ubuntu.com/102772/
[15:18] <lool> stefanlsd: Hmm no; PKG_CHECK_MODULES() wants as first arg the base name of the vars in which to store the _LIBS and _CFLAGS and second arg the list of pkg-config modules you need
[15:18] <lool> stefanlsd: Check xine-lib's configure.ac for an example
[15:19] <sebner> RainCT: sudo apt-get remove kde*, gnome ftw :P
[15:19] <lool> You don't need the whole MAGICKNAME, LDFLAGS, and IMLIBS; instead you simply PKG_CHECK_MODULES(MAGICKNAME, DispatchImage, [have_imagemagick=yes], [have_imagemagick=no])
[15:19] <lool> Err s/DispatchImage/ImageMagick
[15:19] <stefanlsd> lool: kk. thx. cant seem to find too much documentation of PKG_CHECK_MODULES.
[15:20] <lool> stefanlsd: You just PKG_CHECK_MODULES(FOO, [bar baz], [stuff run if bar baz are present], [stuff run if not])
[15:21] <lool> That will set FOO_CFLAGS to pkg-config --cflags bar baz, and FOO_LIBS to pkg-config --libs bar baz
[15:21] <RainCT> sebner: yeah.. visually it gets 10/10 points, but somehow it's quite slowish (on the new laptop! o_O)
[15:21] <lool> (And will AC_SUBST them too BTW)
[15:21] <lool> stefanlsd: So you just run the PKG_CHECK_MODULES and do an AC_MSG_ERROR if not present (because you require imagemagick to build)
[15:22] <lool> if it's optional you don't AC_MSG_ERROR but you export some AM_CONDITIONAL which says that imagemagick support shouldn't build
[15:22] <lool> stefanlsd: With PKG_CHECK_MODULES, you almost only have to do the PKG_CHECK_MODULES; it's really easy
[15:22] <lool> stefanlsd: Do you have xine-libs's configure.ac?
[15:22] <stefanlsd> lool: yeah, i do.
[15:23] <lool> It's the same thing, but they use the Wand .pc, not the ImageMagick.pc one
[15:23] <lool> Also it has a flag to build without imagemagick (AC_ARG_WITH([imagemagick] ...)
[15:24] <lool> stefanlsd: So 1) it checks whether imagemagick was requested on configure command line; 2) if not disabled or if not specified it checks Wand.pc with PKG_CHECK_MODULES
[15:25] <lool> 3) if it was requested and isn't present, it fails (AC_MSG_ERROR); otherwise it's disabled
[15:25] <lool> 4) it sets the HAVE_WAND AM conditional to use in the build rules (Makefile.am)
[15:25] <lool> stefanlsd: Note: AC_SUBST(WAND_CFLAGS) and AC_SUBST(WAND_LIBS) aren't needed
[15:25] <lool> It's done by PKG_CHECK_MODULES already
[15:26] <lool> So it's 10 lines to handle all cases; if you like you can do simpler by not handling any configure flags and always failing when im is missing; you don't need a conditional either in this case; but it's less elegant of course
[15:26] <lool> stefanlsd: Is this any clearer, or am I confusing you further?
[15:29] <stefanlsd> lool: thanks. that was great. i think its getting a bit clearer :).   Wand.pc is provided by whatever libary provides wand i presume?  do all libs provide .pc files?
[15:31] <stefanlsd> and the problem with this configure is not that they use AC_CHECK_LIB, but they mix pkg-config and AC_CHECK_LIB and set variables that PKG_CHECK_MODULES would just do instead?
[15:43]  * RainCT goes back to GNOME :P
[15:44] <pochu> \o/
[15:44] <RainCT> pochu! :)
[15:46] <vorian> boo
[15:46]  * vorian runs
[15:46] <RainCT> vorian: man! you scared me!
[15:46] <vorian> i was booing
[15:48] <perlluver> vorian, loves KDE
[15:48] <vorian> for realz perlluver :)
[15:48] <perlluver> :P
[15:51] <lool> stefanlsd: AC_CHECK_LIB requires the library path to be set properly, so it's an issue when IM is installed in special locations, or requires LDFLAGS to be located; they might have handled that, but it's overly complex to do it by hand and trivial with pkg-config (transparent even)
[15:52] <lool> stefanlsd: Yeah, the mixture of a high-level tool which can do the job to test whether you can use the low level calls didn't make sense really
[15:52] <lool> stefanlsd: No, not all libs provide .pc; IM did for a while
[15:52] <lool> When you have one, it's best to use it unless you care for supporting older version of the lib which didn't have it
[15:53] <stefanlsd> lool: cool. thanks very much for the help.
[16:02] <soc> mok0: thanks for advocating again ...
[16:03] <soc> mok0: afaik i need 2 advocates?
[16:06] <mok0> soc: yes
[16:07] <RainCT> LOL (@ xkcd.com)
[16:10] <jpds> RainCT: Do you know that there's a spanish one?
[16:10] <soc> RainCT: lol ...
[16:11] <soc> mok0: mhhh, hopefully i find another advocate today, because i'm not at home anymore tomorrow ...
[16:11] <mok0> soc: otherwise someone will pick it up sooner or later
[16:12] <soc> mok0: yes, but if there are any additional comments, the package will lie arounf until the next weekend i fear ...
[16:13] <mok0> soc: perhaps RainCT has time to take a look
[16:31] <fabrice_sp_> Hi. IS there anyone to review DVDStyler? IT's at http://revu.ubuntuwire.com/details.py?package=dvdstyler and has already been reviewed by mok0 and siretart. Thanks!
[16:32] <mok0> fabrice_sp_: I'll take a look in 10 minutes
[16:32] <fabrice_sp_> oooh, you're there. Great! and thanks in advance ;-)
[16:41] <mr_pouit> jdong: have you had some time to work on Bug #243451?
[16:51] <mok0> fabrice_sp_: what's that file "debian.patch" in $topdir?
[16:52] <fabrice_sp_> mok0, it comes from upstream. It's a patch to apply if you want to build it in Debian
[16:52] <mok0> fabrice_sp_: ok
[16:53] <fabrice_sp_> mok0, I still have to convinced upstream to produce a tarball without debian building stuff
[16:53] <mok0> fabrice_sp_: good work!
[16:53] <fabrice_sp_> thanks ;)
[16:54] <mok0> fabrice_sp_: uscan says there's a newer version available
[16:54] <fabrice_sp_> really?
[16:54] <fabrice_sp_> mok0, I will check then
[16:54] <mok0> fabrice_sp_: (beta I think)  Newer version (1.7.2~b3) available on remote site
[16:54] <fabrice_sp_> yes: it's the next beta version
[16:55] <mok0> fabrice_sp_: I have just a couple of comments
[16:55] <fabrice_sp_> (b3)
[16:55] <mok0> fabrice_sp_: maybe it's not worth updating the package to a beta version
[16:55] <fabrice_sp_> mok0, ok. Nothing big, I hope :-)
[16:56] <mok0> fabrice_sp_: no just details
[16:56] <fabrice_sp_> mok0, it's too early for the moment, to upgrade to beta. By experience, things get broken with dvdstyler
[16:56] <mok0> fabrice_sp_: ok. You're the expert on that app
[16:57] <fabrice_sp_> :-D
[17:00] <mok0> fabrice_sp_: 2 minor comments. I will advocate your next upload
[17:00] <mok0> (remind me if I forget)
[17:01] <fabrice_sp_> mok0, great! I'll upload the fixes ASAP then. Thanks (and I will remind you if you forget, don't worry :-) )
[17:01] <mok0> fabrice_sp_: ;-)
[17:04] <slytherin> mr_pouit: What is the difference between gst-plugins-bad and gst-plugins-bad-multiverse?
[17:12] <fabrice_sp> mok0, fixes uploaded :-)
[17:12] <fabrice_sp> (I know: it's before you forget :-) )
[17:28] <soc> mok0: ok, i will ask him ..
[17:29] <soc> RainCT: could you advocate my package? http://revu.ubuntuwire.com/details.py?package=ttf-droid ...
[17:29] <slayton> are there docs about how to automatically apply patches during the debuild process?
[17:30] <slytherin> slayton: what do you mean? The patches are applied automatically.
[17:31] <james_w> slayton: https://wiki.ubuntu.com/PackagingGuide/PatchSystems might be of help
[17:32] <james_w> https://wiki.ubuntu.com/MOTU/School/PatchingSources as well
[17:33] <slayton> so if I want to patch an already distributed deb can I just dget the package, add my patch the the patches dir, update the change log and rebuild? Is there any syntax I have to worry about in the patch name? Is there a file that lists all the patches to apply?
[17:34] <ScottK> slayton: It depends on what patch system, so you need to look at the links james_w gave you.
[17:34] <coolbhavi> slayton, It will be in /debian/patches/series normally
[17:34] <mok0> slayton: there's usually a file in debian/patches listing the ones that should be applied
[17:35] <ScottK> coolbhavi: That's only for quilt.  For dpatch it's 00list and simple.patchsys has no list at all.
[17:35] <mok0> slayton: depends on what patch system is being used; there are at least 3
[17:36] <coolbhavi> okay ScottK ...:)
[17:36] <slayton> thanks eveybody!
[17:36] <RainCT> slytherin: the license? :P
[17:37] <slytherin> RainCT: so the source is same right?
[17:37] <slytherin> RainCT: I mean there is no upstream tar ball for -multiverse package. So I am assuming that it is duplicated source.
[17:38] <RainCT> slytherin: Maybe. Each has its own source package, but that's all I can say without downloading them
[17:39] <RainCT> soc: I'm looking :)
[17:43] <mok0> ScottK?
[17:43] <ScottK> mok0?
[17:44] <mok0> ScottK, looking at pyrocket that you've advocated. I'm trying to fix the watch file, and discovered that upstream tarball is named pyrocket_0.5.orig.tar.gz
[17:45] <ScottK> OK.
[17:45] <ScottK> It's been quite some time since I looked at that one.
[17:45] <mok0> ScottK, Is that OK? I've never seen that before
[17:45] <ScottK> mok0: IIRC upstream is also the packager and very interested in getting it into Ubuntu.
[17:45] <mok0> ScottK, I guess the author really wants to be Debian-friendly
[17:45] <ScottK> mok0: Yes.
[17:46] <ScottK> It's unusual, but no harm in it.
[17:46] <mok0> ScottK, OK, I'll fix the watch file and upload it
[17:46] <mok0> ScottK, looks good to me too
[17:46] <ScottK> Great.
[17:52] <fabrice_sp> Got my first advocate to dvdstyler (\o/ mok0). Anyone to make additional review on that package? it's at http://revu.ubuntuwire.com/details.py?package=dvdstyler
[17:54]  * slytherin really hates it when packages from debian unstable need packages from experimental for building. :-(
[18:00] <ScottK-desktop> slytherin: If they do, it's an RC bug against the package, please file it.
[18:01] <slytherin> ScottK-desktop: these are the evil arch all java packages. The build failures are revealed only in Ubuntu.
[18:01] <ScottK-desktop> slytherin: Yep.  I got two python packages fixed in Debian yesterday for very similar reasons.
[18:02] <mok0> Going to dinner, see y'all later
[18:02] <slytherin> ScottK-desktop: Frankly, I am tired. Even if I file bug it is unlikely to get fixed anytime soon.
[18:03] <RainCT> soc: I don't like the short description. Looks great otherwise :)
[18:04] <RainCT> soc: if you can tell me a better short description I'll upload :)
[18:04] <soc> short description? the 60 char line?
[18:04] <RainCT> soc: yes
[18:04] <soc> mom
[18:04] <RainCT> soc: first error: it contains the name of the package
[18:05] <soc> ah ok
[18:05] <slytherin> ScottK-desktop: All this could be avoided if Debian wouldn't allow binary uploads.
[18:05] <soc> "A font optimized for high-dpi devices and extensive language support"
[18:05] <RainCT> although now that I check, most font packages have similar descriptions
[18:05] <soc> maybe that?
[18:06] <soc> "A font optimized for handheld dpi devices with an extensive language support"
[18:06] <soc> better
[18:09] <slytherin> ScottK-desktop: By the way, please help me understand why it is an RC bug?
[18:10] <ScottK-desktop> Package is unbuildable.
[18:10] <ScottK-desktop> Think about post-release security support.
[18:10] <ScottK-desktop> The package has to build on more than the maintainer's machine.
[18:11] <RainCT> soc: what about "and with" instead of "with a"? (I'm test building, btw)
[18:12] <soc> "A font for handheld devices with an extensive language support"
[18:12] <ScottK-desktop> slytherin: Debian Bug 511242 is for one of the ones I dealt with yesterday.
[18:12] <RainCT> soc: great
[18:12] <soc> is that line ok?
[18:12] <soc> the other ones were too long
[18:13] <ScottK-desktop> RainCT: I'd drop the "A" at the beginning
[18:13] <RainCT> soc: Yeah. The "A" is usually not included though, see http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-pkg-synopsis
[18:13] <RainCT> ScottK-desktop: /me too :)
[18:13] <soc> "Font for handheld devices with extensive language support"
[18:13] <ScottK-desktop> "Handheld device font with extensive language support"
[18:15] <soc> "Handheld device font with extensive style and language support"
[18:15] <soc> is that ok?
[18:17] <RainCT> Yep, I'll change it to that then
[18:17] <hanska> ScottK-desktop: I'm uploading clamtk 1.5.8-1 to sid.
[18:17] <soc> mhh, or should i re-upload?
[18:17] <RainCT> soc: not necessary :)
[18:17] <soc> ah
[18:18] <RainCT> actually, it's easier for me if you don't :P
[18:18] <RainCT> so that I don't need to download it again ;)
[18:18] <ScottK-desktop> hanska: Did you just do clamtk 4.08-1?
[18:18]  * ScottK-desktop is confused by the version numbering.
[18:18] <slytherin> james_w: you are last uploader for jspwiki, have you filed a bug in debian that dpatch is missing from build dependencies?
[18:18] <hanska> ScottK-desktop: oops, sorry, confused myself, that's wicd 1.5.8-1 :)
[18:18] <soc> do think it should be necessary to rename install and defoma-hints to ttf-droid.install and ttf-droid.defoma-hints again?
[18:18] <hanska> sorry for the noise
[18:19] <hanska> (I just saw my sponsor committing s/UNRELEASED/unstable/ to the repo...)
[18:19] <soc> mok0 mentioned that ...
[18:19] <RainCT> soc: I am of those who prefer "install" and "defoma-hints" for single-binary packages :P
[18:19] <ScottK-desktop> hanska: No problem.  If you think it should be sync'ed into Ubuntu, please file a sync request bug and then subscribe ubuntu-universe-sponsors to the bug.
[18:19] <soc> ah ok
[18:19] <soc> then everything should be nice
[18:19] <james_w> slytherin: yes
[18:19] <hanska> ScottK-desktop: yes, I'll do, as soon as I re-checkout ubuntu-dev-tools
[18:19] <soc> RainCT: so if the package will be accepted, it will go into universe?
[18:20] <soc> or how will that work?
[18:20] <ScottK-desktop> hanska: OK.  I did get clamtk done.  It was sync'ed about an hour ago.
[18:20] <james_w> slytherin: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507177
[18:20] <hanska> ScottK-desktop: great, thank you.
[18:20] <RainCT> soc: Yes. After uploading it will go to the NEW queue for an archive admin to check the licensing, and then it'll enter universe if everything's OK
[18:20] <james_w> slytherin: I just titled the bug wrong, and so the maintainer got it wrong
[18:20] <slytherin> james_w: I am talking about dpatch, not debhelper.
[18:20] <soc> ah ok
[18:20] <james_w> slytherin: but, the upload also commented out the dpatch calls, so it could be synced.
[18:21] <james_w> slytherin: but I'm not entirely sure that wasn't a mistake as well.
[18:21] <soc> if the admin has questions about licensing etc, he could ask me, mok0, hasnka, pmjdebruijn, we had quite some discussion adn research until we got it right ...
[18:22] <slytherin> james_w: I will see if Debian version builds. If it does then I will file a sync bug.
[18:22] <RainCT> soc: most probably he'll just reject it in that case and you'll automatically get a mail
[18:22] <james_w> slytherin: I imagine it will, but checking whether the patches that were dropped were needed seems more important
[18:22] <RainCT> soc: btw, you may also consider submitting this to Debian
[18:23] <slytherin> james_w: yes, checking that now
[18:23] <RainCT> soc: it isn't as difficult as it may seem :)
[18:24] <soc> RainCT: i was planning that
[18:24] <soc> i already filed a ITP
[18:24] <RainCT> soc: lintian just told me that debian/bug/script is missing the executable bit
[18:25] <RainCT> soc: excellent :)
[18:25] <soc> but i thought it might to faster if it gets into ubuntu, so the debian people can sync it from there ...
[18:25] <slytherin> james_w: one of the patch is irrelevant. The other will be if package builds.
[18:26] <soc> RainCT: mhh weird, i had the +x set ...
[18:26] <slytherin> james_w: A quick look says the other one is still relevant. And the package contains .jar files. :-(
[18:26] <RainCT> soc: well, that shouldn't really make a difference to them, afaik they have no rules to automatically accept packages from Ubuntu (like we do with those from Debian)
[18:26] <soc> ah ok
[18:27] <soc> what should i do to get it into debian?
[18:27] <RainCT> soc: upload to mentors.debian.net and ask for review on the ML (info on the website)
[18:29] <RainCT> soc: congrats on your first package being uploaded to Ubuntu! :)
[18:30] <RainCT> soc: Uhm.. that Dust theme mentioned in your LP profile looks great. Count with a review from me if you ever happen to package it :P
[18:30] <soc> coll, thanks :-)
[18:30] <soc> mhh ok, i'll look into it
[18:31] <RainCT> soc: is it ready for use already'
[18:31] <RainCT> ?
[18:34] <soc> yes, even using it with that QGtkStyle
[18:34] <soc> i'll ask the author which version he would recommend
[18:34] <soc> and then i'll try to do a package ...
[18:35]  * RainCT hugs soc :)
[18:35] <POX> RainCT: I never accepted a new package without some fixes first (and I'm not talking about cosmetic changes) and some of them were already accepted in Ubuntu (including yours, IIRC), so I doubt there will be automatic sync... :-P
[18:35] <POX> (and I sponsored >200 packages)
[18:36] <ScottK> POX: I think it goes both ways.  Pyke got into Debian just fine ....
[18:37] <POX> yeah, RC bugs happen in packages prepared by DDs as well :)
[18:45] <soc> RainCT: ok, against which package should i file the bug to package Dust?
[18:45] <soc> ubuntu-meta?
[18:46] <RainCT> argh.. why does IRC reconnect every time I switch from wifi to ethernet connection or the other way around? :/
[18:46] <RainCT> soc: no package
[18:46] <RainCT> soc: just against the Ubuntu distribution
[18:47] <soc> ah ok
[18:47] <POX> I think more important reason why Ubuntu package cannot be synced in Debian is that Ubuntu packages usually have a mailing list set as maintainer and even if they don't, there's no guarantee that maintainer wants to receive bugs from Debian
[18:47] <POX> soc: is your package Python related?
[18:48] <soc> POX: no, just some fonts
[18:49] <soc> RainCT: dust is already in universe
[18:49] <soc> it is in community-themes
[18:49] <RainCT> soc: ah, cool. So I guess you can strike that point from your list :P
[18:49] <soc> mhh, i didn't see that as well until now
[18:49] <soc> i'll have to check which version is in there ...
[18:50] <soc> because the current 0.2 release had some bugs already fixed in trunk ...
[18:50] <soc> maybe i file an update request ...
[18:50] <maxb> RainCT: Because you change IP address, no?
[18:51] <RainCT> maxb: nope, both are connected to the same router
[18:52] <RainCT> soc: what name does the package have
[18:52] <RainCT> ?
[18:52] <ScottK-desktop> RainCT: You reconnect to the router with a different IP/Source port combination.
[18:53] <soc> RainCT: which package?
[18:53] <RainCT> soc: for dust
[18:53] <soc>  it is in community-themes
[18:53] <RainCT> soc: ah, thanks
[18:54] <RainCT> ScottK-desktop: and applications need to reconnect because of that?
[18:54] <ScottK-desktop> Sure, it's a new connection.
[18:55] <RainCT> bah, that sux :P
[18:57] <RainCT> Btw, pbuilder-dist.new should be ready for use now. If anyone is bored please try it :)
[18:58] <slayton> if I delete a file from the debian/<package>.install file, will it be excluded from the final packaged deb?
[18:58] <RainCT> slayton: most likely, yes
[18:58] <slayton> but not for sure?
[18:59] <RainCT> slayton: if the package is weird and also installs it from debian/rules or something then it will still be there. but that would be *very* weird :P
[19:00] <POX> ... or upstream's script (Makefile?) which is invoked in debian/rules installs it
[19:00] <RainCT> yeah, that'd be another possibility
[19:01] <POX> or clean rule is broken
[19:01] <POX> or... ;)
[19:16] <Laney> https://wiki.ubuntu.com/StableReleaseUpdates doesn't say anything about waiting for -sru ack (between 3 and 4 in "Procedure"). What is the actual procedure here?
[19:22] <ScottK> Generally for Main you upload and ubuntu-sru reviews it in the queue, but for Universe you get the ack first.
[19:26] <Laney> ScottK: Just one ack?
[19:27] <ScottK> Yep
[19:27] <Laney> good, that's easy then
[19:41] <soc> RainCT_: should i archive ttf-droid now?
[19:42] <soc> or how does that work?
[19:42] <slytherin> in what file should I add pointer to /usr/share/doc/dpatch/README.source.gz  for specifying the patch system in use?
[19:53] <slayton> RainCT_: thanks!
[20:17] <ScottK-desktop> slytherin: debian/README.source
[20:24]  * ScottK is suprised to discover that Ubuntu Top Uploaders has him at #12.  
[20:24] <ScottK> Need to slow down.  I've been #15 for the last three releases.
[20:24] <vorian> haha
[20:25] <cody-somerville> where is that page?
[20:26] <JontheEchidna> isn't that page down?
[20:34] <StevenK> Yeah, did the page move?
[20:37] <superm1> does it take into account SRU's?
[20:37] <ScottK> http://thc.emgent.org/utu/utu_jaunty.php
[20:37] <ScottK> superm1: Ask emgent.  I know it doesn't include backports.
[20:38] <JontheEchidna> #18, not bad
[20:39] <superm1> woah i'm falling behind this time. 19? psh.
[20:39] <superm1> 18 last time and 12 before..
[20:48] <agentblue9> Hi, I want to get more involved with packaging and MOTU and would like to find a mentor to work with.   I've contributed a debdiff to bug #293722 and would like to do a lot of bite-size things like this to gain experience.  Any guidance greatly appreciated. Thanks!
[21:01] <soc> how long does it take until an advocated package appears in the repo?
[21:05] <maxb> When you move a file from one binary package to another, is it documented anywhere precisely what the Replaces/Conflicts should look like?
[21:06] <loic-m> Anyone to review the ecm package on REVU ( http://revu.ubuntuwire.com/details.py?package=ecm )? It's a small program, simrunbasuita has already reviewed it and I've made the suggested changes ;)
[21:07] <slytherin> soc: the source first enters into NEW queue. When it is cleared from queue the package is built and the binary enters the new queue.
[21:07] <slytherin> soc: https://edge.launchpad.net/ubuntu/jaunty/+queue
[21:07] <soc> ah thanks!
[21:08] <loic-m> Ecm is a neat program to remove error correction codes on isos for decreasing their size (and for better compression)
[21:08] <soc> slytherin: btw, are there any plans to update openoffice to 3.0?
[21:08] <StevenK> Openoffice 3.0 has already hit Jaunty
[21:08] <StevenK> I think it's having trouble building
[21:08] <slytherin> soc: calc: has already uploaded OOo 3. The builds are going on.
[21:09] <slytherin> StevenK: not anymore.
[21:09] <soc> https://edge.launchpad.net/ubuntu/+builds
[21:09] <soc> ah ok
[21:09] <soc> thanks :-=
[21:10] <slytherin> soc: https://edge.launchpad.net/ubuntu/jaunty/+source/openoffice.org/+builds
[21:21] <soc> btw, since when do we build for itanium?
[21:21] <soc> (ia64)
[21:22] <slytherin> soc: at least since hardy
[21:22] <soc> mhh if lpia builds cöeanly, i386 should build too, i assume?
[21:22] <soc> slytherin: ah ok
[21:22] <sebner> norsetto: \o/
[21:22] <soc> but it is not suported?
[21:23] <slytherin> soc: community supported. Not officially supported.
[21:23] <soc> ah k
[21:24] <norsetto> sebner: Hola
[21:25] <sebner> norsetto: how is live going in Italy? Much snow, what I've heard :)
[21:27] <norsetto> sebner, yes, and good weather to go skiing too
[21:27] <sebner> norsetto: in Austria? .P
[21:28] <norsetto> sebner, nope, 100 km from my house
[21:29] <sebner> norsetto: that far? Here is a big skiing area, just 10km away :P
[21:43] <RainCT> uhm.. can someone explain to me what AllowTcpForwarding in SSH/SFTP is for?
[21:51] <slytherin> RainCT: some context please? What is 'AllowTcpForwarding'? Is it a configuration parameter on server side?
[21:51] <RainCT> slytherin: yes
[21:51] <RainCT> slytherin: I've seen it here;
[21:51] <RainCT> http://blog.markvdb.be/2009/01/sftp-on-ubuntu-and-debian-in-9-easy.html
[21:51] <jpds> RainCT: man sshd_config
[21:52] <RainCT> jpds: that doesn't help, I want to know what TCP forwarind is for :P
[21:53] <slytherin> RainCT: Have you ever done port forwarding over ssh?
[21:53] <RainCT> no
[21:53] <RainCT> so that's what people use to "workaround" blocked ports, or what?
[21:54] <jpds> RainCT: http://en.wikipedia.org/wiki/Tunneling_protocol#SSH_tunneling
[21:54] <slytherin> RainCT: when you login to an ssh server, you can bind a local port to a remote host:port on the machine to which you are connecting.
[21:55] <RainCT> ok, thanks
[21:56] <slytherin> RainCT: the example command is 'ssh -L 10000:192.168.0.10:80 server'. This way when you access localhost:10000, you are actually accessing 192.168.0.10:80 in the network of the ssh server.
[21:59] <RainCT> slytherin: ok, I see :)
[22:29] <quadrispro> sebner: hi!
[22:30] <quadrispro> sebner: what do you think about http://paste.ubuntu.com/102950/ ? (you are the last uploader)
[22:32] <Laney> quadrispro: Please wait with smuxi
[22:32] <Laney> we're (I'm) trying (hoping) to fix a small build problem
[22:33] <quadrispro> ah ok Laney! I'm going to look for another merge to do
[22:33] <Laney> I'll mark it on DaD
[22:33] <quadrispro> it could be fine
[22:34] <sebner> quadrispro: besides. the transition is b0rken. Please no further rebuilds!
[22:34] <Laney> quite
[22:35] <quadrispro> if you want, you can use my debomatic machine (setup by Dktrkranz) -> http://home.alessiotreglia.com
[22:36] <Laney> what is debomatic :(
[22:37] <quadrispro> Laney: https://launchpad.net/debomatic
[22:38] <Laney> crazy, my panels just disappeared but they're still clickable
[22:56] <soc> my package disappeared from the build queue (https://edge.launchpad.net/ubuntu/+builds ), how long will it take until it hits universe?
[22:57] <Laney> soc: What does it say on the package page?
[22:58] <maxb> It is currently here: https://edge.launchpad.net/ubuntu/jaunty/+queue?queue_state=0&queue_text=ttf-droid
[23:00] <soc> oops, i didn't see it anymore ..
[23:00] <soc> thanks
[23:00] <soc> so is this a manual process or will it be built automatically, when a build server is free?
[23:01] <Laney> You have to wait for an archive admin to review and accept (or reject) it
[23:02] <Laney> then it'll build, then they have to accept the binaries
[23:06] <soc> ah ok