[00:49] <serialorder> i updated a po file but when I rebuild the package those updates are not included. I don't think the mo file is being remade. Anyone have any ideas on how I could fix this?
[00:54] <jmarsden|work> serialorder: If you think the mo file *should* be being remade, then you'll want to read the Makfile(s) involved and find out why that is not happening, and perhaps edit debian/rules a little to make sure that *does* happen during your build target?
[00:55] <jmarsden|work> However, I'm not sure if the whole "Ubuntu does its own translations" deal comes into play with things like this... if it does, I know nothing about how all that works!
[00:56] <ScottK> jmarsden: That all happens on the buildds.  For local build tests it shouldn't come into play.
[00:56] <jmarsden|work> OK, then the answer for serialorder is "read and understand your Makefiles, I think.
[01:02] <jekil> how i can use dh_desktop?
[01:03] <pochu> you only need it if you ship desktop files which define MimeTypes
[01:03] <pochu> use it as "dh_desktop -p$package"
[01:03] <pochu> in binary-install, IIRC
[01:04] <jekil> thanks
[01:04] <pochu> right, binary-install/$package
[01:04] <pochu> yw
[01:06] <directhex> does some poor bugger produce modules for Intel's x-fi sound cards for the ubuntu kernel? afaik they're far from entering mainline alsa
[01:11] <soc> directhex: x-fi is from creative i thought ...
[01:11] <directhex> sorry, i meant them
[01:11] <directhex> i need more sleep, it seems
[01:18] <jekil> pochu: and i must put my .desktop in /debian ?
[01:20] <jekil> pochu: sorry, obviously yes
[01:26] <pochu> jekil: and forward it to upstream if appropriate :)
[01:26] <pochu> jekil: note that dh_desktop won't install the desktop file, you need to use dh_install or whatever to install it to /usr/share/applications/
[01:27] <pochu> dh_desktop will take care of calling update-desktop-base in the post{inst,rm}
[01:27] <jekil> pochu: thanks
[01:29] <jekil> please sameonecan review/advocate? http://revu.ubuntuwire.com/details.py?upid=4448
[01:32] <pochu> jekil: in debian/changelog, you should only put one changelog entry, and set the distribution to jaunty
[01:33] <pochu> jekil: the Homepage in debian/control should go in the source stanza (where Standards-Version is)
[01:35] <pochu> jekil: I don't have time for a full review, but the package looks good :)
[01:50] <jekil> pochu: fixed and uploaded, thank you for your help
[01:50] <pochu> jekil: you're welcome. good luck with it!
[03:17] <masti83_> test
[03:55] <pochu> james_w: hi :) that ppamadison script looks useful, I think it'd be suitable for u-d-t
[04:11] <ScottK> TheMuso: Is speakup enabled in our Intrepid kernel?  I gather it was in Gutsy and then dropped in Hardy.
[04:20] <TheMuso> ScottK: No its not. It was in edgy and feisty, and dropped for gutsy, and never to return, at least if I have anything to do with it.
[04:21] <ScottK> TheMuso: Really?  OK.  I was just talking to someone who was going to use Fedora instead because of the lack.
[04:21] <TheMuso> Meh good for them.
[04:21] <ScottK> TheMuso: Is there a wiki page or something we have on what to use instead?
[04:21] <TheMuso> They can use bad code all they want for all I care.
[04:21]  * ScottK doesn't know about it at all.
[04:21] <TheMuso> ScottK: Not really, wiki stuff for accessibility is lacking in that area.
[04:22] <TheMuso> well wiki stuff for accessibility is lacking, period.
[04:23] <TheMuso> ScottK: Unfortunately speakup last I checked suffers from bad code quality, and doesn't perform well on SMP systems or under heavy system load, as well as talking to serial ports directly, and not going through the needed kernel subsystems.
[04:24] <ScottK> TheMuso: OK.  When I tell them no, what do I tell them we use instead?
[04:25] <TheMuso> ScottK: We use gnome-orca, which is a screen reader for the GNOME desktop.
[04:25] <pochu> Orca?
[04:25] <ScottK> TheMuso: Thanks.
[04:25] <TheMuso> pochu: yes
[04:25] <pochu> ah, he already asked :)
[04:26] <pochu> TheMuso: right, I didn't read your last message :)
[04:26] <TheMuso> pochu: Right.
[04:28] <StevenK> Orca certainly seems more pleasant than speakup
[04:28] <StevenK> But you can't really compare user and system level code
[04:28] <TheMuso> StevenK: Yep.
[04:31]  * pochu waves good night
[04:34] <agent47a> hi... i'm a noob trying to to help with Bug #293722 found here:  https://bugs.launchpad.net/ubuntu-manpage-repository/+bug/293722  .  I finished with the editing ctorrent.sgml .  I am using the workaround to build the binary without signing it: "debuild -uc -us"  But I don't know how to build the source.  debuild -S barfs with a fatal error "debsign failed".
[04:36] <ScottK> agent47a: debuild -S -us -uc
[04:39] <agent47a> looks like debuild is run under debian subdirectory but debdiff runs in the package root directory.  is that typical?
[04:40] <ScottK> debdiff diff debian package defined by two .dsc files you give it.
[04:40] <ScottK> It doesn't matter so much where you run it.
[05:09] <ScottK> Anyone got a patch system how to for Debhelper 7?
[05:11] <ScottK> OK.  I give.  I'm tired anyway.
[05:11] <ScottK> Good night all.
[05:11] <jmarsden> Goodnight ScottK
[05:13] <crimsun> ScottK: http://joey.kitenet.net/blog/entry/dh_implementation/
[05:13] <ScottK> crimsun: Looking.  Thanks.
[05:21] <crimsun> ScottK: sql-ledger is an interesting example if you're looking for integration with, say, quilt
[05:21] <ScottK> crimsun: Thanks.
[05:21]  * ScottK looks
[05:33] <carandraug> hi everyone! I'm making my first package so I'm following the instructions in the ubuntu wiki with the program hello. In one of the steps, they mention to remove the *.ex, readme.debian, dirs, docs and info files from the debian directory. They say that's because the program's not complicated but the files can be needed for some packages. How do I know whether I should or should not remove them?
[05:34] <hyperair> what are you packaging?
[05:35] <carandraug> hyperair: I plan on package rubyripper in the future for a PPA. For now, I'm experimenting with the program hello, which they recommend in the tutorial
[05:35] <carandraug> https://wiki.ubuntu.com/PackagingGuide/Complete
[05:35] <hyperair> i see
[05:35] <hyperair> okay, rubyripper doesn't have an init.d service right? so at least init.d.ex can be removed
[05:36] <hyperair> basically you have to know what each of the .ex files is for and figure out if the functionality is required in your pacakge
[05:36] <carandraug> hyperair: hmm.... can you give a me a link where I can read more about that, please?
[05:37] <hyperair> heheh i don't think i managed to find anything of that sort. i sort of guessed what each one is for
[05:37] <hyperair> usually the contents of the file tell you what it's for
[05:37] <hyperair> in some kind of comment or whatever
[05:38] <carandraug> hyperair: I see. I'll try to look inside the file then. Thanks
[05:38] <jmarsden> man dh and man all of the dh_ tools should help you learn about this too
[05:39] <hyperair> yeah that too
[05:39] <hyperair> but i didn't read the dh_ manpages until very recently
[07:00] <dholbach> good morning
[07:01] <iulian> G'morning Daniel.
[07:01] <dholbach> hiya iulian
[07:03] <nellery> hi dholbach
[07:03] <dholbach> hiya nellery
[07:04] <nellery> dholbach: thanks for bringing up the issue with the developer applications!
[07:05] <dholbach> nellery: we've been talking about it for a long time and I'm fairly happy with the proposal, I believe it will fix a lot of the issues that we see today
[07:05] <dholbach> I haven't dug into the discussion yet today
[07:07] <nellery> dholbach: it all looks good
[07:07] <nellery> my only concern is that applicants may not be able to make it to the meetings
[07:07] <nellery> due to time zone restraints
[07:08] <dholbach> nellery: the plan was to rotate times and have it every 14 days
[07:08] <dholbach> if that does not work out and there's very special requirements for meeting, I'm sure we can adjust with a one-off meeting or still discuss on the mailing list or something - we're going to be flexible
[07:08] <dholbach> but the majority will be able to make it, I think
[07:09] <nellery> dholbach: great, that would probably work out well.
[07:09] <nellery> Thanks again
[07:10] <dholbach> no worries
[07:14] <didrocks> morning everyone!
[07:15] <dholbach> hi didrocks
[07:46] <Hobbsee> dholbach: you'd be able to get quorum, while meeting at a different time?
[07:48] <dholbach> Hobbsee: quorum is a necessity
[07:49] <Hobbsee> dholbach: I realise that, but i'm asking if it's actually going to happen, if you're meeting at a non-european-friendly time.
[07:49] <Hobbsee> (although I realise that you'll mostly hold it in european timezones, but there will still be exceptions)
[07:49] <dholbach> we will need to make sure - the meeting does not make sense otherwise
[07:50] <Hobbsee> exactly
[07:50] <persia> Well, it mostly must be in a European-freindly timezone, because a majority of the current councillors are in Europe.  That said, there's 14-18 hours of Europe-freindly timezones.
[07:50] <Hobbsee> persia: indeed.
[07:50] <Hobbsee> persia: i'm just asking in the case of australians, or similar people
[07:51] <dholbach> for the special cases I'm sure we can work something out
[07:51] <Hobbsee> persia: which is going to be directly during european night, in a lot of cases (11pm - 10am local, perhaps)
[07:51] <persia> Trick is more balancing others: there are two, mostly diametrically opposed, slots that ought work for all MC members, although I'll admit neither is particularly ideal in Australia.
[07:51] <dholbach> as I said in the mail: we're going to be flexible, if there's no way around using the mailing list, we use it
[08:35] <jekil> please sameonecan review/advocate? http://revu.ubuntuwire.com/details.py?upid=4448
[08:45] <evocallaghan> Hi
[08:46] <evocallaghan> I'm having problems getting X to start on my distro I'm building, #xorg seems dead and #ubuntu is full of just end users. So sorry to ask in here as a last resort
[08:46] <evocallaghan> OK here goes,
[08:47] <evocallaghan> X fails to start saying it can't find fonts 'fixed'
[08:47] <evocallaghan> Now the fonts exist in /usr/X11/lib/X11/fonts just fine
[08:48] <evocallaghan> mkfontdir /usr/X11/lib/X11/fonts ; /usr/X11/bin/xset fp+ /usr/X11/lib/X11/fonts ; /usr/X11/bin/xset fp rehash
[08:48] <evocallaghan> However this fails saying that xset can't open a display
[08:48] <evocallaghan> Any ideas please?
[08:48] <quadrispro> anyone on bug 188561?
[08:50] <persia> evocallaghan, If you can replicate with Ubuntu, you're better off filing a bug.  If not, I'm not sure how we might help.
[08:50] <evocallaghan> Hmm, I would have though there would be some skilled people in the area of xorg here that is all
[08:54] <evocallaghan> persia: http://ubuntuforums.org/showthread.php?t=76046
[08:55] <evocallaghan> So it happens on ubuntu as well
[08:55] <evocallaghan> I will try to purge fonts like it says
[08:58] <evocallaghan> nope :(
[09:21] <agentblue9> i want to upgrade to the dev version from 8.10.  i'm still not sure how to do it ater looking at https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases ..  any hints greatly appreciated.
[09:29] <persia> agentblue9, First off, thanks for testing, but expect things to break.
[09:30] <persia> Try running `update-manager --devel-release`
[09:30] <agentblue9> persia: thanks.  -d will also do, right?
[09:31] <persia> Probably.
[09:31] <agentblue9> persia: is it of any importance to do the 8.10 updates first before going to jaunty?  this is a fresh ubuntu 8.1 from cd.
[09:32] <hyperair> dosen't matter
[09:32] <agentblue9> hyperair: thanks!
[09:32] <hyperair> you're going to be upgrading past that anyway
[09:32] <hyperair> np
[09:32] <agentblue9> ic, i'm going to click the Install Updates button now.  ;)
[09:33] <hyperair> i think you should be clicking "Upgrade"
[09:33] <hyperair> at the top
[09:33] <hyperair> if you intend to upgrade to 9.04 that is
[09:33] <agentblue9> hyperair: ah!  you're right.
[09:34] <persia> agentblue9, I'd recommend doing the updates, in case someone already fixed an upgrade path issue, but it may not matter.
[09:34] <hyperair> persia: upgrade path issue?
[09:35] <persia> hyperair, Sometimes there's an issue upgrading a set of packages from one release to another.  Sometimes this can be fixed by an SRU.  Where possible, these are done.
[09:35] <persia> Most of the upgrade path testing assumes application of available updates before upgrade.
[09:35] <hyperair> i see
[09:36] <agentblue9> persia: hmmm... i've already clicked upgrade.  oh well
[09:36] <hyperair> you can always cancel
[09:36] <agentblue9> ah... it gives a chance to cancel now.
[09:36] <hyperair> it'll roll back the changes
[09:36] <agentblue9> so tempted to go forward.
[09:37] <hyperair> haha
[09:37] <stefanlsd> agentblue9: btw, have you read the release notes?
[09:37] <agentblue9> i think i went right past those.
[09:38] <stefanlsd> agentblue9: have a look here - http://www.ubuntu.com/testing/jaunty/alpha2
[09:38] <stefanlsd> agentblue9: known issues.  nvidia / ati may be a problem
[09:38] <agentblue9> stefanlsd: d'oh
[09:38] <agentblue9> i have a really old nvidia geforce2
[09:39] <persia> agentblue9, Doesn't likely matter that much.
[09:39] <stefanlsd> agentblue9: well, more specifically the propietry drivers may be a problem.  the opensource stuff should be ok, although you may not have accel
[09:40] <agentblue9> ic... then i'm not too worried.
[09:40] <hyperair> no accel means no compiz
[09:41] <hyperair> anyway is DRI2 getting into jaunty, or has it already gotten in?
[09:42] <hyperair> hmm looks like it's already in
[09:42] <agentblue9> hyperair: compiz with flash 9 makes my firefox grey-freeze randomly in hardy.
[09:44] <hyperair> pity.
[09:44] <hyperair> wait a sec
[09:44] <hyperair> are you upgrading to intrepid or jaunty?
[09:44] <agentblue9> hyperair: talking about a different system.
[09:44] <stefanlsd> -d must be jaunty
[09:44] <hyperair> yeah
[09:45] <agentblue9> upgrading from intrepid to jaunty.
[09:50] <agentblue9> i wonder if freenx will work with jaunty
[09:56] <mok0> hyperair, in codelite, what is the empty directory /usr/share/codelite/plugins/resources/ for?
[09:57] <hyperair> for plugin resources
[09:58] <mok0> hyperair: that are installed later?
[09:58] <hyperair> yes
[09:58] <mok0> hyperair: ok
[10:07] <mok0> hyperair: advocated
[10:09] <mok0> Oh, it'd be nice if dget would be called on a .dsc file when it's clicked in Firefox. Anyone know how to do that?
[10:11] <hyperair> no idea
[10:11] <hyperair> maybe a plugin
[10:11] <hyperair> heh
[10:12] <hyperair> should be functionality added to ubufox perhaps? =p
[10:12] <hyperair> mok0: thanks
[10:12] <hyperair> for advocating i mean
[10:12] <mok0> hyperair: Thanks for _your_ work! :-) Now you need one more advocate
[10:12] <hyperair> i'll wait for nhandler =)
[10:13] <hyperair> after two advocates come along, is there anything else?
[10:13] <directhex> mok0, dget's a bit commaand-liney for the console isn't it?
[10:13] <mok0> hyperair: no, usually the 2nd advocate uploads the NEW queue.
[10:14] <directhex> bah, for firefox
[10:14] <mok0> directhex: yeah I guess
[10:14] <hyperair> okay
[10:14] <directhex> mok0, if there were a gdebi-esque tool for dsc, then you could just associate the file type
[10:14] <mok0> hyperair: the archive-admin might reject it if issues are found
[10:14] <hyperair> hmm
[10:14] <hyperair> a GUI dget?
[10:14] <directhex> mok0, i'd knock one together in c#, but i suspect people would eat my kidneys
[10:14] <hyperair> heheh
[10:15] <mok0> directhex: I would :-P
[10:15] <directhex> hyperair, broadly useless, but yes, something to say "this is part of a source package, i'm getting the other bits, dawg, fo'shizzle"
[10:15] <mok0> directhex: All the gui needs to do is to ask for a place to put the pacakge
[10:15] <hyperair> mok0: don't you think a bash script + zenity would do?
[10:16] <mok0> hyperair: err, I don't know zenity...
[10:16] <hyperair> wait, dosen't dget only work on urls?
[10:16] <mok0> hyperair: yes
[10:16] <directhex> hm, true
[10:16] <hyperair> yeah so you can't associate a script with the filetype
[10:16] <directhex> okay, write an extension for it then. go go gadget xul!
[10:16] <hyperair> heh i have no idea how to use xul
[10:17] <mok0> The person writing such an extension would be a regular hero in the Debian/Ubuntu world...
[10:19] <hyperair> agreed
[10:23] <quadrispro> does anyone wanna have fun with a ffmpeg FTBFS? :D
[10:24] <quadrispro> bug #311180 , it's waiting for a sponsor
[10:25] <mok0> quadrispro: I'll take a look
[10:25] <quadrispro> thank you mok0
[10:26] <mok0> quadrispro: you are Allesio?
[10:26] <quadrispro> mok0: yes
[10:27] <mok0> quadrispro: you patched configure?
[10:27] <quadrispro> yes
[10:27] <mok0> quadrispro: why do you need to do that?
[10:28] <Laney> ffmpeg doesn't care for compatibility
[10:28] <mok0> quadrispro: it should be regenerated from configure.ac
[10:29] <quadrispro> mok0: ah right, I can prepare a new debdiff
[10:29] <mok0> quadrispro: of course that means editing debian/rules
[10:31] <quadrispro> mok0: thanks a lot, i'm workin on it :)
[10:42] <slytherin> geser: persia: Get ready for another circular build dependency problem . :-) - Enjoy the conversation here http://lists.debian.org/debian-java/2009/01/msg00001.html
[10:43] <mok0> apt really ought to detect circular dependencies and either ignore them or complain
[10:43] <directhex> yay, circular!
[10:43] <directhex> when in doubt, bootstrap-binary it & pray for forgiveness?
[10:45] <quadrispro> mok0: i have a question
[10:45] <mok0> quadrispro: go ahead
[10:46]  * directhex prepares his stock reply - "no, it shouldn't be purple; see a doctor"
[10:47] <quadrispro> I think setting --with-ffmpeg-h in debian/rules isn't very helpful, because in aclocal the search path contains ffmpeg/, and this isn't correct (the correct path for avformat.h is 'libavformat/')
[10:47] <quadrispro> ehm
[10:48] <quadrispro> mok0: s/aclocal/configure.ac
[10:48] <persia> slytherin, This is only a one-time thing, right?
[10:48] <quadrispro> sorry
[10:48] <persia> mok0, Sometimes you need them.  For example, gcc.
[10:48] <mok0> quadrispro: you've fixed it in configure.ac so you need to run autoreconf in rules
[10:49] <slytherin> persia: I hope. I haven't look through all the maven related packages. I am filing the sync requests as I build them successfully in pbuilder.
[10:49] <mok0> quadrispro: that should regenerate aclocal as well
[10:50] <persia> slytherin, If it's a one-time bootstrap for the package, it can usually be done by request.  If it's an each-time bootstrap, it needs re-engineering.
[10:50] <mok0> quadrispro: I don't think you need --with-ffmpeg because the header files are in the standard place
[10:50] <quadrispro> mok0: I didn't want mention aclocal, I talked about configure.ac :)
[10:50] <quadrispro> mok0: yes, it's right
[10:50] <slytherin> persia: I am tired of bootstrapping. I will see if I can built the package with some modification. Similar to what we did in case of jboss.
[10:50] <quadrispro> mok0: so, isn'it necessary change configure.ac?
[10:50] <quadrispro> is it?
[10:51] <mok0> quadrispro: I don't think so
[10:51] <persia> slytherin, Even better, of course :)
[10:51] <quadrispro> AC_CHECK_HEADER($FFMPEG_SEARCH_HEADERS/ffmpeg/avformat.h,
[10:51] <mok0> quadrispro: it's much easier if you can avoid it
[10:51] <slytherin> ﻿In that process I had a conversation with Torsten yesterday and found out that we need to sync some packages from experimental for the packages in unstable to build. :-) One of those package was not even uploaded to experimental till yesterday.
[10:51] <quadrispro> mok0: mmm, ok
[10:52] <mok0> quadrispro: unless of course configure stops the build
[10:53] <mok0> quadrispro: Going to lunch so I'll be afk for a while-
[10:53] <StevenK> quadrispro: They aren't under ffmpeg any more
[10:53] <quadrispro> configure stops the build
[10:53] <quadrispro> mok0: ah ok, bye ;)
[10:53] <mok0> StevenK: That's what he's fixing
[10:53] <StevenK> Which package?
[10:53] <StevenK> Since I worked a bunch on the ffmpeg stuff
[10:53] <quadrispro> StevenK: hi! mediatomb
[10:53] <StevenK> Hm. I didn't see that one on the list
[10:54] <quadrispro> StevenK: bug 311180
[10:54] <quadrispro> StevenK: I think it's needed change configure.ac, not debian/rules...
[10:55] <quadrispro> StevenK: the change to configure file has to be dropped from my patch, but it seems working fine
[10:56] <quadrispro> i'm working on a new debdiff
[10:56] <StevenK> quadrispro: I've not looked at mediatomb
[12:01] <stefanlsd> If we have a merge and the only change is debian fixed the ubuntu1 bug, do we always request the sync or just say its not required?
[12:03] <Laney> stefanlsd: I wouldn't at this point, it doesn't gain us anything (autosyncing is off anyway)
[12:03] <stefanlsd> Laney: kk. which point would we?
[12:04] <Laney> before DIF it would make sense as then we automatically benefit from Debian's changes
[12:05] <directhex> and assuming debian hasn't been frozen snice before intrepid
[12:05] <directhex> *cough*
[12:05] <stefanlsd> heh. cool. thx
[12:05] <Laney> stability release!
[12:06] <directhex> Laney, jauntiness and stability are opposites!
[12:06] <directhex> Laney, a jaunty hat might fall off at any moment!
[12:07]  * Laney walks the jaunty walk
[12:08] <directhex> hats can also be dapper
[12:08]  * directhex thinks ubuntu should switch to a hat naming scheme, since it seems to already be hat-friendly
[12:08]  * Laney -> lunch
[12:09] <directhex> unhelpfully, i find no hat types starting with "J"
[12:09]  * StevenK has too many hats
[12:11] <directhex> are any of them jaunty and/or dapper?
[12:20] <StevenK> directhex: I can go through them, if you want ...
[12:20] <directhex> nah, sounds like effort
[12:22] <StevenK> directhex: Meh, I point you at the teams I'm on in LP
[12:24] <directhex> hm, netbook remix. i know who to bug if my wife has issues, then
[12:25] <mok0> quadrispro: did StevenK fix the ffmpeg thing for you?
[12:26] <StevenK> Oh, drat
[12:26] <quadrispro> mok0: no, I'm working on it :)
[12:26] <mok0> quadrispro: ok great
[12:46] <maxb> Jaunty currently has mercurial 1.0.1, but 1.1.2, a new upstream feature release exists. Any opinions on whether it makes sense to try to get the new version into Jaunty at this point in the release cycle, or not?
[12:46] <persia> maxb, How stable is 1.1.2?  How much would it improve the experience for users?  Are there other packages affected that need updating?
[12:51] <maxb> Seems stable in my experience, and has already had a couple of point releases, so the inevitable teething troubles of a new feature branch should be worked out. There are new features in core, and there are extensions which require the new version. It's mostly compatible - rdepends would need testing, but likely wouldn't need updating.
[12:52] <jekil> please sameonecan review/advocate? http://revu.ubuntuwire.com/details.py?upid=4448
[12:53] <oojah> maxb: 1.0.2 is listed as having security fixes at least.
[12:56] <maxb> the security fixes have been backported by debian, but you have a good point, there are relevant bugfixes in 1.0.2 if 1.1.x is deemed too much of a change
[12:56] <mok0> jekil: This is really a bug fix
[12:57] <mok0> jekil: you should create a bug on LP and attach a debdiff to it
[12:57] <jekil> mok0: so, the updated packages don't use revu system?
[12:57] <mok0> jekil: no
[12:58] <jekil> mok0: ok, thanks
[12:58] <mok0> jekil: if you need help with the debdiff etc just ask here. Remember to close the bug in changelog
[12:59] <jekil> mok0: and after uploading the debdiff in the bug (thats already opened, i upload this to revu to close it) i must notify someone/somewhere?
[13:00] <mok0> jekil: you close it in changelog by having this construct: (LP: #xxxxxx)
[13:00] <jekil> mok0: all already done in the package uploaded to revu..
[13:00] <mok0> jekil: then you subscribe ubuntu-universe-sponsors
[13:00] <mok0> jekil: ah
[13:00] <jekil> mok0: ok, the subscription to ubuntu-universe-sponsors is the point that i miss
[13:01] <mok0> jekil: that will put it on u-u-s's Bug page
[13:01] <mr_pouit> StevenK: could you please close LP bugs when you fix them? :(
[13:01] <persia> jekil, Also, there's no benefit to pushing it to REVU if it's just an update to an existing package.
[13:01] <mok0> jekil: then it will be processed
[13:01] <StevenK> mr_pouit: Yeah, you keep filing them, and I keep not looking
[13:02] <mr_pouit> StevenK: no, I stop filing them :p
[13:02] <jekil> mok0, persia: thank you, i am sorry, i haven't understand the workflow, now it's ok, thanks
[13:03] <mok0> jekil: NP. The process could be described better
[13:03] <mok0> jekil: please archive the REVU upload then
[13:06] <jekil> mok0: yes, now i archive. thanks for your help
[13:10] <jekil> oh, if try to archive i get a taceback from revu http://pastebin.com/d77d27b79
[13:20] <mok0> jekil: Hmm. Worked for me
[13:20] <mok0> jekil: perhaps you don't have permission?
[13:21] <mok0> jekil: anyway, problem solved (although the revu software seems to have a bug)
[13:21] <anakron> HI all
[13:23] <anakron> Hi persia
[13:23] <persia> Hey anakron
[13:43] <AnAnt> Anyone knows what 8.04.2 will be released ?
[13:45] <persia> AnAnt, https://wiki.ubuntu.com/HardyReleaseSchedule is the document to watch.
[13:45] <persia> subscribe to that, and you'll see when the various point release dates are confirmed.
[13:45] <AnAnt> thanks
[14:06] <quadrispro> devfil: ciao! bug 188561
[14:06] <devfil> quadrispro: ok
[14:10] <mok0> Any C++ fans around?
[14:10] <ScottK> mok0: I'd guess your odds are better on #kubuntu-devel.
[14:11] <mok0> ScottK, I can try there
[14:12] <DktrKranz> persia, probably I figured out that pbuilder issue I faced some days ago, it seems related to pkgbinarymangler (I use it in my default pbuilder configuration)
[14:13] <persia> DktrKranz, but pkgbinarymangler should be on the buildds too: is it just a conflict between pkgbinarymangler and some pbuilder internals?
[14:14] <DktrKranz> persia, probably. I'll try to reproduce two build logs, one without it and one with it, just to see difference. I'll try to debug something with pdebuild, then
[14:22] <quadrispro> thanks for the upload, devfil
[14:36] <opera> who can tell me how to join ubuntu-cn
[14:36] <opera>  who can give me a link
[14:36] <opera>  i can't find it in the list
[14:37] <savvas> opera: you mean #ubuntu-cn ?
[14:37] <opera> yes
[14:37] <opera> discuss ubuntu in chinese
[14:37] <savvas> opera: type: /join #ubuntu-cn
[14:38] <savvas> and press enter
[14:39] <opera> but ,every time i join it through other give a link ,and how can i join it  own?
 opera: type: /join #ubuntu-cn
[14:44] <opera> \
[14:45] <rhpot1991_laptop> any motu-srus around?
[14:56] <mok0>  /join #ubuntu-cn
[14:56] <mok0> heh
[14:58] <slytherin> !merge
[15:04] <bddebian> Heya gang
[15:12] <slytherin> any archive admins around?
[15:38] <soc> mok0: hi, i fixed the things you mentioned in the comments, would you like to review it again?
[15:38] <soc> http://revu.ubuntuwire.com/details.py?package=ttf-droid
[15:39] <mok0> soc: sure
[15:40] <mok0> soc: I took a look earlier, actually.
[15:41] <mok0> soc: what I wrote about the Vcs-* fields was not correct
[15:41] <mok0> soc: in debian/control
[15:41] <soc> yes, the next comment mentioned that
[15:41] <mok0> soc: I suggest you move these refs to README.Debian
[15:41] <soc> refs?
[15:41] <mok0> URLs
[15:42] <soc> atm it looks like that:
[15:42] <soc> Homepage: http://www.ascendercorp.com/pr/2007-11-12/
[15:42] <soc> Vcs-Browser: http://android.git.kernel.org/?p=platform/frameworks/base.git;a=tree;f=data/fonts
[15:42] <soc> Vcs-Git: git://android.git.kernel.org/platform/frameworks/base.git
[15:42] <soc> is that right now?
[15:43] <mok0> soc: no, those fields are reserved for packaging repos
[15:43] <soc> packaging repos?
[15:43] <mok0> soc: yes, developers are starting to keep their packaging work in VCS
[15:43] <soc> ah ok
[15:44] <soc> remove all three?
[15:44] <soc> into README.Debian?
[15:44] <mok0> soc: no, only the VCS-* lines, but put the URLs in the README.Debian file
[15:44] <soc> ah ok
[15:45] <mok0> soc: I think the homepage field is ok
[15:45] <mok0> soc: another thing I wandered is: what is the debian/bug directory for?
[15:45] <soc> ok, i'll upload again
[15:46] <soc> oh, cool, i have really fast internet today
[15:46] <mok0> soc: debian/bug/presubj looks like info that should also be in README.Debian
[15:47] <soc> mok0: i think that is somehow used with reportbug
[15:47] <mok0> soc: ah
[15:49] <cody-somerville> dholbach, I have e-mails in the moderation queue for ubuntu-motu and motu-council I think
[15:50] <dholbach> cody-somerville: only one for ubuntu-motu
[15:50] <cody-somerville> ok, thanks
[15:50] <cody-somerville> Can you add that e-mail to auto accept?
[15:51] <dholbach> just listadmin'ed that mail through
[15:51] <dholbach> the next time I'll do it
[15:52] <dholbach> cody-somerville: thanks for giving that session about xubuntu
[15:55] <cody-somerville> dholbach, np
[15:55] <cody-somerville> thanks
[15:59] <savvas> Where do we place man pages? In debian/binaryname.8.man ?
[15:59] <vorian> savvas: yes, but no need for the .man part
[16:00] <savvas> ah great, thanks :)
[16:00] <vorian> no problemo
[16:03] <vorian> savvas: you will also need to use dh_installman in rules
[16:06] <savvas> I know vorian, I have it set in rules to cycle through all dh_ commands :)
[16:06] <vorian> ah, ok then :)
[16:16] <vorian> james_w: did you want to look at the sugar-hulahop merge?
[16:19] <mok0> soc: advocated
[16:24] <vorian> james_w: i'll leave it be for now
[16:26] <soc> mok0: thanks!
[16:35] <james_w> vorian: I've reviewed it, I just popped out to get lunch before testing
[16:35] <james_w> vorian: thanks for checking
[16:35] <vorian> no problem james_w :)
[16:36] <stefanlsd> james_w: do those libev changes seem sane?
[16:36] <soc> mhh, cloud someone advocate http://revu.ubuntuwire.com/details.py?package=ttf-droid again?
[16:36] <james_w> stefanlsd: haven't had chance to look yet, sorry
[16:37] <soc> i fixed the optional things mok0 mentioned
[16:37] <stefanlsd> james_w: np. not sure who the libtool experts are to check...
[16:43] <james_w> stefanlsd: yeah, do you know why AC_CONFIG_MACRO_DIR et al were needed?
[16:43] <james_w> did it just bail out with AC_CONFIG_MACRO_DIR unset?
[16:46] <stefanlsd> james_w: trying again
[16:48] <stefanlsd> james_w: those options were given by the autoreconf tools
[16:50] <stefanlsd> james_w: it does build without it - but get this libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
[16:50] <james_w> stefanlsd: hmm, yeah, "consider"
[16:51] <james_w> I think it looks good though, let me test etc.
[16:52] <stefanlsd> james_w: kk. tried without the mkdir m4 and it fails.  the autoreconf man page says it replaces the steps that we're being run.
[16:54] <james_w> stefanlsd: do you have a debian chroot around?
[17:00] <soc> pmjdebruijn: hi, could you advocate my package? mok0 advocated it, but i fixed the optional things he mentioned and reuploaded it again
[17:08] <stefanlsd> james_w: not atm. something i actually wanna get thou. will get one.
[17:10] <james_w> there's also a couple of "warning: ignoring return value of 'write', declared with attribute warn_unused_result" if you feel like patching
[17:15] <james_w> stefanlsd: patch works fine on Debian, please forward it there.
[17:18] <stefanlsd> james_w: thanks. will look at warning and forward to debian.
[17:19] <james_w> stefanlsd: uploaded, thanks for your contribution
[17:19] <stefanlsd> james_w: thanks for the help!
[17:26] <slytherin> any archive admins around?
[17:38] <pmjdebruijn> soc: sorry, I'm not a MOTU
[18:15] <soc> ah ok
[18:51] <RainCT> Uhm.. Which package do I need if I want to install KDE4 but without all the kubuntu-desktop stuff? (And, should I install from Intrepid or is there some more up2date PPA?)
[18:57] <JontheEchidna> kde-core should install a minimal installation
[18:57] <JontheEchidna> the latest stable release is in intrepid-updates
[18:57] <JontheEchidna> with KDE 4.2 betas being here: https://bugs.edge.launchpad.net/~kubuntu-experimental/+archive
[19:00] <ogzy> hi i have a deb related question,  I had installed directfb libraries from the hardy repo, but now i want to install the new release and will either compile from source manually or create the deb file, first wuestion is, how can i install to the same path of the previous version, i think the configure script should be run with prefix /usr right?, second question do i have to recompile other programs that are compiled directfb enabled before after
[19:00] <ogzy> installing the new release
[19:00] <RainCT> JontheEchidna: thanks
[19:01] <RainCT> JontheEchidna: What do you recommend, intrepid-updates or the PPA? (/me wants to see cool stuff)
[19:01] <JontheEchidna> imo the betas are just as stable as the stable release
[19:01] <JontheEchidna> and in a few day's we'll have the first RC :D
[19:02] <RainCT> okay, I'll install the beta then
[19:06] <slicer> Hi. Will packages in debian experimental/unstable to automatically merged to Jaunty? .. If so, how often does that happen?
[19:08] <ScottK> slicer: Packages are automatically sync'ed from Unstable if there are no changes to the package in Ubuntu in the first part of the release cycle (we're past it for Jaunty).
[19:08] <ScottK> The last sync was ~25 December
[19:08] <ScottK> Packages with Ubuntu changes have to be manually merged.
[19:08] <ScottK> Packages from Experimental never get into Ubuntu automatically.
[19:10] <slicer> ScottK: Ok, since we're now past the first release cycle, does that mean I have to request a package sync? It fixes a "cant-install" bug report in the package. (The package being "mumble").
[19:10] <ScottK> slicer: yes.
[19:12] <jpds> slicer: There's a "requestsync" script in ubuntu-dev-tools to do just that (if you don't know).
[19:13] <slicer> jpds: I do, but it requires gpg signing, and I don't have my key here.
[19:14] <Laney> slicer: Not if you use --lp
[19:14] <jpds> slicer: There's an --lp flag which does not need gpg, it uses launchpadbugs and cookie file auth against Launchpad.
[19:14] <Laney> \o
[19:14] <slicer> Aha :) That I didn't know. Thanks!
[19:40] <POX> ScottK: I saw your name in python-storm's changelog, do you want to maintain it in Debian? (Ubuntu's Maintainer is set to a mailing list)
[19:41] <ScottK> POX: Not really.  I don't remember what I did to it, but it's not a particular interest of mine.
[19:41] <POX> or anyone wants to maintain it? I can sponsor (although I use SQLAlchemy only)
[19:41]  * directhex flogs a cpu on ebay
[19:41] <woody86> Can anyone help me out? I already setup a PGP with launchpad, but I've reinstalled Ubuntu on my comp, is there any way to get my PGP back on this comp, or do I have to just create a new one?
[19:41] <POX> +else
[19:41]  * ScottK thinks perhaps mok0 is interested in it, but he's not here right now.
[19:42] <Laney> woody86: Did you keep the private key?
[19:43] <woody86> Laney- I know it's not on this comp, let me check my main rig, brb
[19:48] <hyperair> does anybody know if the compiz fusion stackswitch plugin will enter ubuntu?
[19:53] <woody86> Laney-  I saved the output of when I made the PGP key, and it has the fingerprint and everything, but I'm not sure which part is the pgp key
[19:54] <woody86> Laney-  there's one part that says:
[19:54] <Laney> woody86: It starts with -----BEGIN PGP PRIVATE KEY BLOCK-----
[19:54] <woody86> Laney-  oh, the key block? yes I have that too
[19:55] <Laney> good, you can import that into gpg/seahorse
[19:55] <woody86> ok, thanks :) any easy way to do that?
[19:55] <Laney> file->import in seahorse should do it
[19:56] <woody86> ok, have to transfer those text files...
[20:12] <woody86> Laney-  wait, the only thing I have is the PGP Revoke file, and it's not letting me import that
[20:12] <Laney> not surprising
[20:13] <woody86> Laney-  now, I created a new PGP, how can I replace the one on LP with this new one?
[20:13] <Laney> yes
[20:14] <woody86> or is there an easier way to import my old one onto my camp?
[20:16] <jekil> i have fixed a bug, uploaded debdiff to bug report, and subribed ubuntu sponsor for universe to the bug (https://bugs.edge.launchpad.net/ubuntu/+source/obextool/+bug/133748), anythink alse? i must only wait now?
[20:24] <fabrice_sp_> jekil, don't put Fix commited as status. Better Confirmed
[20:26] <fabrice_sp_> also, mark the debdiff as patch
[20:27] <quadrispro> anyone on bug 311020?
[20:27] <fabrice_sp_> jekil, and unassign yourself
[20:27] <fabrice_sp_> and then wait
[20:27] <fabrice_sp_> :-)
[20:35] <maxb> Is there any easy way to find rdepends for a jaunty package if you don't have a jaunty install handy?
[20:41] <jekil> fabrice_sp: thanks
[20:41] <fabrice_sp> you're welcome ;-)
[20:43] <ScottK> maxb: If you have a Jaunty pbuilder, use pbuilder login and use apt-cache rdepends from there
[20:44] <fabrice_sp> maxb: or setup a chroot environnement
[20:46] <maxb> I should probably set up a jaunty pbuilder for later, true. (At the moment I was just wanting to check whether an NBS is depended on)
[20:57] <superm1> cody-somerville, rhpot1991_laptop has been trying to get an SRU through for mythexport for some time now, he's had my okay with the changes.
[20:57]  * cody-somerville nods.
[20:58] <cody-somerville> superm1, I worked with him earlier. I'm hoping we can get it approved ASAP.
[20:58] <superm1> cody-somerville, okay cool great.
[20:58] <cody-somerville> :)
[20:59] <slayton> is there anyway to tell if the diff.gz obtained by running apt-get source contains any changes besides the debian dir? like changes to the source and
[21:00] <directhex> filterdiff
[21:00] <directhex> and a cluebat for people not using a patchsys!
[21:02] <Laney> slayton: lsdiff -z foo.diff.gz
[21:03] <slayton> thanks!
[21:11] <pochu> nvidia-graphics-drivers-180 (180.22-0ubuntu1) jaunty; urgency=low
[21:11] <pochu> * New upstream version.  First "stable" driver in 180 series. (LP: #315169)
[21:11] <pochu> superm1: ^ is "stable" meant to be ironic? ;)
[21:11] <sebner> lol
[21:11] <pochu> hey sebner :)
[21:12] <superm1> pochu, it's supposed to draw emphasis at least :)
[21:13]  * sebner winks pochu 
[21:14] <sebner> superm1: still not compatible with new xorg, right?
[21:17] <superm1> sebner, it works with the new xorg, but you need IgnoreABI still
[21:19] <soc> hanska: hi, could you review/advocate my package? i did some optional refinements and uploaded it again, so i lost mok0 advocation :-/
[21:19] <hanska> soc: err... I'm not a MOTU/core-dev/...
[21:19] <hanska> soc: I don't even use Ubuntu ^_^
[21:20] <soc> ah ok :-/
[21:20] <hanska> I could review your package though, and write my comment :)
[21:20] <soc> damn ... i only have one day, then i'm away for the whole week ...
[21:20] <soc> that would be nice of course
[21:21] <soc> i have 0 advocations again, so i can do reuploads as much as i want :-)
[21:22] <hanska> ok, url?
[21:22] <soc> http://revu.ubuntuwire.com/details.py?package=ttf-droid
[21:23] <hanska> soc: reviewing
[21:31] <slayton> what entry do I need to make in the foo.intsall file if if I want to rename a file after its compiled? I tried using changing "debian/tmp/usr/bin/foo" to "debian/tmp/usr/foo debian/tmp/usr/bar" but then when I run dpkg -c i see /usr/bin/bar/foo
[21:31] <ScottK> hanska: I think Bug 314843 is worth forwarding upstream, but a quick look didn't turn up an upstream bug tracker.
[21:32] <hanska> ScottK: yes, the "upstream bug tracker" is upstream's mailbox ;)
[21:32] <ScottK> hanska: Right.  I'm that way on stuff I do too.  Would you be up for forwarding it?
[21:32] <hanska> ScottK: sure, just a moment, I'm a bit busy right now
[21:33] <hanska> thank you for pinging me, though.
[21:33] <ScottK> hanska: No rush.
[21:35] <pochu> slayton: you can't with dh_install AFAIK.
[21:36] <slayton> pochu: what would be the proper way of trying to rename the file?
[21:36] <pochu> LIMITATIONS dh_install cannot rename files or directories, it can only install them with the names they already have into wherever you want in the package build tree.
[21:36] <pochu> ^ that's from the dh_install(1)
[21:36] <pochu> slayton: you an use mv in debian/rules
[21:37] <slayton> ok great I'll try that out
[21:42] <slayton> pochu: I  tried that and now I'm getting a missing seperator error
[21:42] <slayton> pochu: is there a specific place where I need to add the line? or do I need to use different syntax? I tried just adding the mv /src/foo /dest/bar
[21:46] <hanska> soc: done
[21:53] <pochu> slayton: you want something along "mv debian/tmp/usr/bin/foo debian/tmp/usr/sbin/foobar"
[21:54] <pochu> slayton: so relative paths
[21:54] <soc> hanska: ah ok
[21:54] <soc> thanks
[21:55] <soc> hanska: a) i will remove that forgotten file ...
[21:55] <soc> b) what's the difference between that ttf-droid.install file and the instructions in rules?
[21:55] <hanska> soc: about debian/bug/* ?
[21:56] <soc> c) i got told that i should rename install and defoma-hints to ttf-droid.install and ttf-droid.defoma-hints
[21:56] <soc> yes
[21:56] <soc> could i not just move this instruction from install to the rules?
[21:56] <hanska> soc: that's an useless suggestion -- it's just in case you add another binary package in future
[21:56] <soc> ah ok
[21:56] <hanska> soc: it would be better if you moved the lines in rules to the .install :)
[21:56] <soc> ah ok
[21:56] <hanska> soc: you could add something like
[21:57] <soc> how should that look then?
[21:57] <hanska> debian/bug/script  /usr/share/.../
[21:57] <hanska> debian/bug/presubj  /usr/share/.../
[21:57] <soc> i haven't really understood the different syntax between install and rules
[21:57] <hanska> install is called by dh_install
[21:57] <hanska> (check its manpage)
[21:57] <soc> ah ok
[21:57] <soc> so the rules should look like this?
[21:58] <soc> include /usr/share/cdbs/1/rules/debhelper.mk
[21:58] <soc> install/ttf-droid::
[21:58] <soc> 	dh_installdefoma
[21:58] <soc> and the rest goes to install?
[21:58] <hanska> soc: yes, but you're using "-D" in the install lines, so you should ensure that the dirs get created first
[21:58] <hanska> (dh_install doesn't do that)
[21:59] <hanska> soc: you can then add a debian/dirs file with /usr/share/bug/ttf-droid/ inside, and stop
[21:59] <hanska> :)
[21:59] <hanska> soc: uhm, I suppose I wasn't that clear.
[21:59] <Laney> dh_install does create dirs
[22:00] <soc> mhhh there is no source.lintian-override on my system ...
[22:00] <soc> weird ...
[22:00] <hanska> Laney: thought it didn't
[22:00] <soc> only the right one, source.lintian-overrides
[22:00] <Laney> dirs is only for making empty directories
[22:00] <hanska> Laney: not fully true
[22:01] <hanska> Laney: however, are you sure'
[22:01] <hanska> let me try :P
[22:02] <hanska> Laney: \o/
[22:02] <hanska> Laney++
[22:02] <Laney> :>
[22:02] <soc> hanska: running debuild instead of debuild -S creates some files in the debian dir, should i delte them again?
[22:03] <hanska> Laney: maybe I was just remembering some old debhelper compatibility :)
[22:03] <soc> for instance ttf-droid.postinst.debhelper
[22:03] <hanska> soc: "debuild clean" is your friend
[22:03] <soc> and ttf-droid.prerm.debhelper
[22:04] <soc> http://pastebin.com/m5dd2f70c
[22:04] <soc> should i include that file?
[22:04] <soc> or does debuild include that file in the package automatically?
[22:05] <hanska> # Automatically added by dh_installdefoma
[22:05] <hanska> ;)
[22:05] <hanska> debuild clean should remove it.
[22:05] <hanska> then you just do "debuild"
[22:08] <soc> ok
[22:08] <soc> hanska: ok, thanks
[22:08] <soc> so what about that rules file now?
[22:09] <soc> should i move things again between rules and install or should i leave it as is?
[22:09] <hanska> soc: move the install lines in debian/ttf-droid.install
[22:09] <hanska> soc: just ensure that the script is +x
[22:10] <hanska> (and you'd have to do that in rules)
[22:10] <soc> install should have +x?
[22:10] <hanska> soc: "the script" --> debian/bug/script
[22:10] <hanska> :)
[22:10] <soc> ah ok
[22:10] <soc> mhh ok, so how should install look like?
[22:11] <soc> *.ttf		usr/share/fonts/truetype/ttf-droid/
[22:11] <soc> debian/bug/*	usr/share/bug/ttf-droid/
[22:11] <soc> would that be ok?
[22:11] <soc> and the directories are created automatically?
[22:12] <soc> and rules just:
[22:12] <soc> include /usr/share/cdbs/1/rules/debhelper.mk
[22:12] <soc> install/ttf-droid::
[22:12] <soc> 	dh_installdefoma
[22:13] <soc> btw, should the orig.tar.gz include the debian diretory already?
[22:14] <soc> or is this added via the diff.gz?
[22:14] <maxb> No, the orig.tar.gz should include upstream's files only
[22:14] <soc> ah ok
[22:32] <tbielawa> greetings all
[22:35] <tbielawa> has anyone had problems with python distutils escaping fakeroot and attempting to write to the local file system? I haven't had any luck getting it to play nice
[22:35] <terli> I need help making users accept a license in my .deb file
[22:35] <terli> could I get a quick rundown on the required steps?
[22:36] <soc> terli: shouldn't you do that on the first start?
[22:36] <terli> no, I want them to click next, check the box, and install.
[22:36] <tbielawa> I believe you need to work with debconf http://www.fifi.org/doc/debconf-doc/tutorial.html
[22:36] <soc> stalling the installation process is considered by many people as annoying ...
[22:36] <terli> Well this package is more annoying when you have to accept the license on the command line
[22:37] <soc> terli: hu? now i couldn't follow you ...
[22:37] <terli> just be brief.
[22:38] <terli> I've got my DEBIAN/copywrite and DEBIAN/config file ready
[22:38] <terli> I mean /control
[22:38] <terli> solly
[22:38] <soc> terli: copyRIGHT i assume
[22:38] <terli> yes that too, it's been driving me nuts googling debian copywright and needing copyright
[22:39] <tbielawa> terli, check out the debconf link I pasted above. It's more involved than a brief IRC description could help you with. but fairly straightforard
[22:40] <soc> yes, english is not that nice language regarding the pronounciation ...
[22:40] <maxb> terli: The sun-java6 source would be the example to look at
[22:40] <terli> it's only 40 mb
[22:40] <terli> only going to take me 3 hours and piss my gamer siblings off stealing their bandwidthz
[22:41] <terli> I'll look for it.
[22:44] <soc> hanska: new upload: http://revu.ubuntuwire.com/details.py?package=ttf-droid
[22:44] <terli> https://jdk-distros.dev.java.net/svn/jdk-distros/trunk/linux/ubuntu/sun-java5/debian/rules << at least 1000 million lines
[22:46] <hanska> soc: that's fine to me
[22:46] <tbielawa> terli. the link I posted earlier is a straight run through. You should check it out
[22:46] <hanska> soc: however, you can make debian/rules even shorter
[22:46] <hanska> :)
[22:46] <soc> how?
[22:46] <hanska> soc: do you know/use debhelper 7?
[22:47] <terli> tbielawa: I don't know jack diddly, but I want a gtk screen to show the license
[22:47] <soc> yes, i use it in that package i guess
[22:47] <hanska> no, you're using CDBS
[22:47] <hanska> #!/usr/bin/make -f
[22:47] <hanska> %:
[22:47] <hanska>         dh $@
[22:47] <hanska> this is your debian/rules for dh7.
[22:47] <soc> mhh weird ...
[22:47] <hanska> try :P
[22:48] <soc> but i use dh_installdefoma for instance?
[22:48] <soc> and i include /usr/share/cdbs/1/rules/debhelper.mk
[22:48] <hanska> no
[22:48] <hanska> uhm, wait, seems like defoma isn't in the standard dh run
[22:49] <hanska> soc: stick with cdbs then :)
[22:49] <tbielawa> terli, I don't know if you're trying to write something for a personal project or to get into the repos. If you're aiming for the repos then use debconf, and when you use something like synaptic it will present you with a gui screen for your answer.
[22:49] <soc> ok
[22:49] <terli> personal
[22:49] <terli> its a proprietary deb file for all ubuntu revisions
[22:49] <terli> I'm packaging my own parallels installation
[22:49] <soc> hanska: do you know some motu who could review my package?
[22:50] <soc> i'm away after tomorrow and i would like to get it done before ...
[22:50] <terli> can I just get a decent example
[22:50] <hanska> soc: nope, sorry. I'm here just to help new contributors, and not really into Ubuntu at all :)
[22:50] <soc> ah k ...
[22:50] <tbielawa> The link provided has code examples included. Try going through it and then come back if you are cought up on any part of the process and we'll be able to help more :)
[22:51] <soc> terli: you can't rely on gtk, because that is not installed on every system ...
[22:51] <terli> its not any good.
[22:51] <terli> soc: I just want a gui.
[22:51] <terli> just a bloody gui
[22:51] <soc> then use debconf
[22:51] <soc> it will scale to the software available
[22:51] <tbielawa> exactly, soc
[22:52] <terli> I just want to take /DEBIAN/copyright and use it to present a single window with the copyright and a checkbox at the bottom correlating with a boolean variable indicating acceptance. the user has to scroll through it first.
[22:52] <soc> if you run it with the commandline, it will use the commandline, if you run it via synaptic, you will get an gtk box and so on
[22:52] <soc> debian/copyright is not meant for that
[22:52] <soc> copyright is no script
[22:53] <soc> it's just a single textfile
[22:53] <terli> copyright is just a text file!
[22:53] <terli> I want to use the text file as the source for the copyright, is just what i was saying.
[22:53] <soc> ah ok
[22:53] <tbielawa> terli, I don't think there's much more we can say. We've told you exactly what to do at this point.
[22:53] <terli> no, you've pointed me to the temple of debian
[22:53] <terli> *eyes cross*
[22:53] <hanska> ...
[22:54] <terli> *begins mumbling in ancient scripts as pidgin crashes*
[22:54] <soc> try to find a package which does what you want
[22:54] <soc> try maybe adobe reader or flash or something
[22:55] <tbielawa> so no suggestions for python distutils escaping fakeroot? daaang :(
[23:08] <ScottK> tbielawa: What exact problem are you having?
[23:09] <ScottK> Because no, I haven't had it.
[23:10] <tbielawa> ScottK, I'm running a typical "python setup.py install" as a build action. Building with -rfakeroot.
[23:10] <ScottK> OK.
[23:10] <tbielawa> I expected fakeroot to contain what happened to my debian/package/ folder, but it's attempting to still install an init script into my root filesystem.
[23:11] <tbielawa> (good think I don't package as root)
[23:11] <ScottK> Note that fakeroot doesn't make a chroot, it just fools the system about is it root.
[23:11] <ScottK> I think that's as expected.
[23:11] <james_w> tbielawa: fakeroot protects you, the setup.py is broken
[23:11] <james_w> tbielawa: if you pastebin it we can probably spot the problem
[23:12] <tbielawa> I can patch setup.py and remove the leading "/".
[23:12] <tbielawa> I'll pastebin. thanks for helping. brb
[23:12]  * ScottK needs to run off anyway.
[23:17] <tbielawa> I must run as well. ScottK, thanks for tipping me off to the subtility of fakeroot. Now I don't feel bad patching the setup.py
[23:18] <tbielawa> http://pastebin.ubuntu.com/102418/ but there it is if anyone wants to dissect it :)
[23:20] <james_w> tbielawa: probably just the leading / as you say then
[23:20] <james_w> normally the issue is re-implementing part of install() and forgetting self.root
[23:20] <terli> *exits the temple of debian in long shoddy robes covered in scratches and torn in many places*
[23:20] <terli> ok,
[23:21] <terli> now how to get my package to reference the script for debconf?
[23:28] <terli> its just not working
[23:28] <terli> soc, I wrote my script, how do I make the preinst reference it
[23:37] <soc> terli: sorry, erli, i'm the wrong man, i started packaging 2 days ago :-)
[23:39] <soc> hi ... i could need someone to advocate my package ... http://revu.ubuntuwire.com/details.py?package=ttf-droid
[23:42] <terli> well I started packaging today
 now how to get my package to reference the script for debconf?  <-- what does that mean?
[23:51] <terli> patented software needs a copyright.
[23:51] <terli> and I'm going to force it to display at installation time, since the user *is* using a deb file for it.
[23:52] <maxb> yes... you said that earlier
[23:52] <maxb> Be I don't understand the specifics of what you are asking about
[23:52] <terli> I've been told to use debconf for it
[23:52] <terli> it's not working at all.
[23:52] <terli> I wrote a .templates, a .config file, and attempted to alter preinst
[23:54] <savvas> have you set up the rules file terli ?
[23:55] <maxb> terli: have a look at a minimal example that I wrote for myself: http://jabberwock.vm.bytemark.co.uk/~maxb/debconfdemo/