[00:05] <emgent> hi slomo_
[00:48] <ScottK> YokoZar: Hardy backport for wine is done.
[00:50] <emgent> wine 1.0 ?
[00:50] <YokoZar> ScottK: Thank you.  I just realized about an hour ago that I should update the .desktop file though (to add application/x-msi to it and change "Wine Windows Emulator" to "Wine Windows Program Loader").  I'm currently hopping into loco team rooms to try and get translations for the existing entries in the .desktop file.
[00:50] <YokoZar> ScottK: Anyway I'll poke you if I need another backport after testing the new .desktop file for functionality.
[00:51] <RainCT> YokoZar: do you need a Catalan translation? :)
[00:51] <ScottK> OK.
[00:52] <YokoZar> RainCT: Yes actually
[00:52] <YokoZar> RainCT: Name=Wine Windows Program Loader  = ?
[00:53] <RoAkSoAx> YokoZar, Wine Lanzador de Programas Windows
[00:53] <RainCT> YokoZar: Name[ca]=Carregador d'aplicacions del Windows         (adding Wine it sounds very strange)
[00:53] <RoAkSoAx> xD
[00:54] <RoAkSoAx> RainCT, maybe could be better to do something like Name[ca]=Wine - Carregador d'aplicacions del Windows
[00:54] <RainCT> where is this text shown, by the way?
[00:55] <YokoZar> RainCT: When you right click an executable
[00:56] <YokoZar> RainCT: and it's prefaced with "open with" and it's standard parlance to include the program name there (Wine), sort of like how we have "Applications->OpenOffice.org Word Processor" rather than just "Word Processor"
[00:58] <RainCT> well, I guess that RoAkSoAx said is an option ( Name[ca]=Wine - Carregador )
[00:58] <RainCT> d'aplicacions del Windows)        damn irssi
[00:59] <emgent> ScottK: can i talk with you one moment in query ?
[00:59] <RainCT> * Well, I guess that what RoAkSoAx said is an option (Name[ca]=Wine - Carregador d'aplicacions del Windows)
[01:00] <ScottK> emgent: If it's quick.  I need to go fix dinner.
[01:00] <RainCT> YokoZar: is there something more?
[01:01] <emgent> ScottK: ok np, we can talk later :)
[01:01] <emgent> feel free to ping me
[01:01] <ScottK> OK.
[01:01] <emgent> thanks
[01:01] <ScottK> If I remember.  Next time you see me around, remind me if I don't.
[01:01] <YokoZar> RainCT: Can I leave the - out?
[01:02] <RainCT> no
[01:02] <RainCT> if you don't want it it would be: Carregador d'aplicacions del Windows Wine
[01:02] <RainCT> but as I already said that sounds quite strange
[01:03] <RainCT> : instead of - would be OK too
[01:07] <RainCT> well, I'm off then
[01:07] <RainCT> good night
[01:41] <emgent> some motu avaiable here?
[01:42] <cody-somerville> I am.
[01:42] <emgent> hi cody-somerville
[01:43] <cody-somerville> Hello emgent
[01:43] <emgent> have you time for see one package ?
[01:43] <cody-somerville> Sure.
[01:43] <emgent> i should upload it in universe, it`s a native ubuntu white hat tool for pt reports
[01:43] <emgent> http://revu.tauware.de/details.py?package=uwha
[01:49] <cody-somerville> emgent, Have you talked to anybody else about this?
[01:49] <emgent> yep security team
[01:50] <cody-somerville> Is there any reason why it can't be shipped in ubuntu-dev-tools instead of having its own package?
[01:52] <emgent> uwha is only for ubuntu whitehat member and contributors, i dont think that is good idea add uwha in ubuntu-dev-tools
[01:53] <emgent> uwha is an Ubuntu White Hat group tool
[01:53] <cody-somerville> emgent, In which case I suggest you to use your team PPA
[01:54] <cody-somerville> Wouldn't that be easier for your team?
[01:54] <emgent> uhm ok np
[01:55] <emgent> cody-somerville: feel free to remove this package in revu and thanks for all
[01:55] <cody-somerville> Okay :)
[01:56] <emgent> :)
[01:58] <cody-somerville> I guess someone else will have to nuke it
[01:58] <cody-somerville> I don't seem to have any powers there.
[01:59] <cody-somerville> ajmitch, ^^
[01:59] <emgent> argh ok np :)
[01:59] <emgent> i will ask to siretart
[02:02] <cody-somerville> emgent, hopefully you can get him to fix my account too ;]
[02:04] <emgent> hehe ok cody-somerville :)
[02:06] <wgrant> What needs doing?
[02:07] <wgrant> cody-somerville: What's broken with your account?
[02:07] <wgrant> emgent: Archived.
[02:09] <cody-somerville> wgrant, It says I'm a contributor and not developer.
[02:09] <cody-somerville> so I can't do anything
[02:09] <emgent> ok thanks wgrant
[02:10] <wgrant> cody-somerville: You're a reviewer now.
[02:10] <cody-somerville> woot.
[02:11] <cody-somerville> wgrant, wait
[02:11] <cody-somerville> Is there different types of "profiles" besides reviewer and contributor?
[02:11] <cody-somerville> *Are
[02:11] <wgrant> There's admin as well.
[02:11] <cody-somerville> Okay.
[02:14] <cody-somerville> So, anyone else need anything before I head off? :)
[02:57] <BluntObject> Hi
[02:57] <BluntObject> I am looking for someone who is willing to mentor me into building Ubuntu deb packagse
[02:57] <BluntObject> s/packagse/packages
[02:58] <BluntObject> Any takers?
[02:58] <BluntObject> I am fully familiar with building RPM packages
[02:58] <BluntObject> but want to get rolling with debs now.
[02:58] <BluntObject> Need just a few pointers
[02:58] <BluntObject> Anyone, please?
[03:00] <cody-somerville> Hi BluntObject
[03:00] <cody-somerville> We have a mentoring program.
[03:00] <BluntObject> cody-somerville: Hi
[03:00] <BluntObject> Can you point me in the right direction pelase?
[03:00] <cody-somerville> https://wiki.ubuntu.com/MOTU/Mentoring
[03:01] <BluntObject> Let me check that out. BRB
[03:08] <BluntObject> cody-somerville: I think the packaging guide will get me on my way.
[03:08] <BluntObject> Thanks for the pointers.
[03:08] <cody-somerville> :)
[03:08] <BluntObject> FYI - I am VERY familiar with building RPM packages
[03:09] <BluntObject> Have done LOTS of it.
[03:09] <BluntObject> Just lost at see with the deb tools.
[03:09] <BluntObject> s/see/sea
[03:10] <BluntObject> Anyhow, must get on with reading and doing it.
[03:10] <BluntObject> bye.
[03:12] <cody-somerville> :)
[03:12]  * cody-somerville waves.
[03:14] <wgrant> 5~/win 48
[03:14] <wgrant> Gah.
[03:15] <wgrant> Ah.
[03:15] <wgrant> I know why I keep doing that.
[03:15] <wgrant> Intrepid gnome-terminal bug.
[03:15] <wgrant> Well, misfeature.
[03:35] <lifeless> wgrant: whats the feature?
[03:36] <wgrant> lifeless: Ctrl+Pg{Up,Dn} now send the character to the terminal if there are no more tabs in that direction.
[03:37] <lifeless> oh, lol
[03:37] <lifeless> thats terrible
[03:37] <wgrant> I always keep my irssi as the first tab, so I don't have to press Ctrl+PgUp the perfect number of times.
[03:38] <lifeless> well
[03:39] <lifeless> I used uxterm :P, but I can imagine the trouble
[03:45] <wgrant> superm1: Any objections to me trying to rebase our vlc on sid's? We're not toooo dissimilar.
[03:46] <superm1> wgrant, maintaining our x264 and friends still during our build ?
[03:46] <superm1> wgrant, or dropping the fun stuff....
[03:48] <wgrant> superm1: Why can't we convince it to use the external versions?
[03:48] <superm1> wgrant, that's fine
[03:48] <superm1> as long as the support is still there in some fashion
[03:49] <superm1> i dont know that the build system was conducive to that
[03:49] <superm1> but otherwise have at it :)
[03:52] <wgrant> I'm trying.
[03:52] <wgrant> It has altogether too many build-depends.
[03:52] <superm1> there were a few that got added in as launchpad bugs saying to add more support
[03:52] <superm1> that debian may not have
[03:53] <wgrant> All that was missing was libpulse-dev (which I've added, along with the rest of the PulseAudio stuff), subversion (which I was going to ask you about) and libdirectfb-dev (which I'm yet to look into).
[03:54] <whs> I'm merging http://packages.qa.debian.org/t/thaifonts-arundina.html to ubuntu. In copyright file, where should I edit?
[03:54] <wgrant> There's also one other patch missing in Debian - 022_no_cpu_consumption.diff, which I can't find an explanation for.
[03:54] <wgrant> whs: Why are you editing it?
[03:54] <whs> wgrant# I want that package to be in ubuntu. Does it need change?
[03:55] <wgrant> whs: It does not.
[03:55] <wgrant> !info thaifonts-arundina intrepid
[03:55] <wgrant> superm1: It seems happy with an external x264.
[03:55] <whs> wgrant# what about the changelog?
[03:56] <superm1> wgrant, great :)
[03:56] <wgrant> whs: We sync most of our stuff from Debian - most packages need no changes at all, and will appear in Ubuntu automatically.
[03:56] <whs> ok, thanks
[03:58] <wgrant> !info thaifonts-arundina intrepid
[03:58] <wgrant> Don't lie!
[03:58] <wgrant> It is there.
[03:58] <wgrant> !info thaifonts-arundina sid
[03:58] <wgrant> !info thaifonts-arundina intrepid
[04:00] <wgrant> configure seems to only be reporting missing CDDB and DAAP support, which looks good so far...
[04:01] <wgrant> I doubt the Mozilla plugin will work, but we'll see...
[04:14]  * wgrant looks for videos to test both x264 and the Mozilla plugin.
[09:00] <bliZZardz> DktrKranz: am in :)
[09:00] <nxvl> bliZZardz: https://wiki.ubuntu.com/MOTU/GettingStarted
[09:01] <DktrKranz> bliZZardz, also, you could want to have a look at one of these packages https://bugs.launchpad.net/~pythonistas/+packagebugs
[09:02] <nxvl> DktrKranz: i was looking for you
[09:02] <bliZZardz> what is Motu alla bout?
[09:02] <nxvl> DktrKranz: can you please take a look at Bug #241774
[09:02] <nxvl> bliZZardz: MOTU stands for Master of the Universe
[09:02] <nxvl> bliZZardz: which are the people in charge of universe/ and multiverse
[09:02] <nxvl> well need to run
[09:03] <nxvl> back here in half an hour
[09:03] <bliZZardz> cool...am in this ...
[09:06]  * bliZZardz joins MOTU :)
[09:40] <RAOF> Can anyone else reach miro's bugtracker? (link from http://www.getmiro.com)
[10:14] <DktrKranz> RAOF, no problems here
[10:22] <RAOF> DktrKranz: Thanks.  Urgh, that means it's my problem :(
[10:23] <DktrKranz> have you tried with a proxy
[10:23] <DktrKranz> ?
[10:24] <RAOF> No.  I'll just give this box a bit of a restart; wierd things are happening :)
[10:24] <DktrKranz> heh
[10:24] <RAOF> Well, I've fixed that bug anyway.
[10:24] <RAOF> Then I can report it upstream, once I can actually connect :)
[10:24] <DktrKranz> sometimes *nix have to be restarted, it happens once in a lifetime, but it happens :)
[10:25] <RAOF> I'd just like to reset my hardware to a known-good state, and kill all the processes.  Such as the one keeping my webcam active.
[10:26]  * DktrKranz will go for a u-u-s scan
[10:28] <RAOF> Ha!  Miro is merged, like a fox!
[11:48] <persia> Anyone looking for an opportunity to learn GTK better?
[11:49] <AnAnt__> persia: Hello
[11:50] <persia> AnAnt__: Hello.
[11:50] <AnAnt__> persia: just reminding you of the REVUs
[11:51] <persia> AnAnt__: Definitely on my list :)
[11:52] <AnAnt__> persia: thanks
[12:21] <RAOF> persia: What for?
[12:22] <RAOF> (GTK, that is)
[12:24] <persia> RAOF: There's somewhere in the vicinity of 200 packages that still use GTK+ 1.2.  Be nice to drop that already, and I suspect a fair number of upstreams would be happy for a patch.
[12:24] <RAOF> Really that many?  Owch.
[12:26] <wgrant> 178. Ow.
[12:27] <persia> And that only counts direct rdepends on libgtk1.2.  There's all the indirect depends as well...
[12:27] <portahex> 1.2 -> 2.0 isn't trivial
[12:28] <portahex> just ask the xmms people!
[12:28] <persia> portahex: It's really not trivial at all.  On the other hand, it's possible.
[12:28] <portahex> i used an app where it was a compile-time flag
[12:28] <portahex> that was impressive
[12:29] <persia> Tricky bits will be the popular ones like xemacs, nethack, and the like.
[12:29] <persia> Some might not need it.  jscalibrator only provides a UI for an essentially unused library.  yelp can do most of what gman does, etc.
[12:30] <portahex> i suspect the authors of those olde-time apps will be against any gtk2 move, for new == bloat
[12:31] <persia> portahex: Maybe.  Some are dead.  Some might like to be included (as GTK+1.2 is going away, if not for intrepid, likely for intrepid+1)
[12:31] <RAOF> What?  xemacs still uses gtk 1.2?
[12:31] <portahex> persia, yeah, but many app devs don't care, and insist that the old libs are best. again, look at xmms
[12:32] <portahex> persia, consider all the pain they had shoehorning utf8 into it, yet they still use 1.2
[12:32] <persia> portahex: You're thinking of the more careful upstreams.  There are lots that don't support UTF8 yet.
[12:33] <DktrKranz> persia, there's something on debian side too, but I don't know progress made there
[12:33] <persia> DktrKranz: Some, but not lots.  That's part of why I mentioned it here.
[12:33] <DktrKranz> it's not a release goal, not for lenny at least
[12:34]  * portahex files some facetious RC bugs, for kicks
[12:34] <DktrKranz> probably they will get more attention if they decide to promote to release goal for lenny + 1
[12:34] <persia> I think it was rejected for lenny as being too much: but I suspect it for lenny+1.
[12:35] <persia> Similar to the WX2.4 transition: Debian did some, then we did some for Gutsy, and then Debian did some more, and now it will be gone for both lenny and intrepid.
[12:36]  * DktrKranz thinks about python 2.x => python 3(000)
[12:37] <persia> DktrKranz: That'll be a bit.  There's still stuff broken with 2.5.
[12:37] <DktrKranz> hard to catch them
[12:38] <portahex> pythonamon, i choose you!
[12:38] <persia> DktrKranz: Need an automated test environment, to install each app, try running it, and test the exit value.
[12:39] <DktrKranz> persia, exactly what we DON'T have :/
[12:39] <persia> DktrKranz: Yeah, well.  You need hardware :)
[12:40] <DktrKranz> I met a DD yesterday, they have similar issues when doing QA
[12:40] <DktrKranz> lack of hardware, manpower and how to test packages effectively
[12:41] <persia> Absolutely.  Most of the code we use for QA is shared between Debian and Ubuntu.
[12:42] <DktrKranz> We talked about file conflicts when dist-upgrading, there's some WIP which needs attention
[12:42] <DktrKranz> edos related
[12:54] <bliZZard1> need a mentor!
[12:55] <wgrant> superm1: I've got a rebased vlc for Hardy and Intrepid in my PPA. It seems to work fine, and has no extra embedded sources, but I'd like a second opinion.
[12:56] <emgent> morning
[12:57] <devfil> hi emgent :)
[12:58] <emgent> bliZZard1: https://edge.launchpad.net/~motu-mentoring-reception
[13:01] <persia> bliZZard1: What sort of thing would you like to do?  For many things, asking in this channel can get you a head start whilst you wait.
[13:07] <bliZZard1> persia : am new here and want to contribute. Am just learning the basics.. hence any one good mentor to sustain would be good
[13:12] <bliZZard1> should i send an email to the mailing list?
[13:20] <persia> bliZZard1: If you've requested a mentor, that's your best solution to get one.  Sending mail won't help.
[13:21] <persia> If you want to get started whilst you wait, you might review some of the open bugs, and see if you know a solution.
[13:21] <bliZZard1> persia : i have requested a mentor only here, and not in the mailing list.
[13:22] <bliZZard1> i am looking at open bugs
[13:22] <persia> If you do, we'd be happy to help you get it into the archives.  This isn't a replacement for a mentor, but may give you something to do while you wait.
[13:22] <bliZZard1> at Pythonistas
[13:22] <bliZZard1> ok..
[13:22] <persia> Oh.  Here isn't the best place.  You want to contact the mentoring-reception team.
[13:22] <bliZZard1> as am comfortable with Python, would Pythonistas be the right place to start?
[13:25] <persia> Pythonista's is a very open team, and appreciate help.  They tend to be quite helpful.
[13:25] <persia> Note that most of the pythonistas team work is done for both Debian and Ubuntu, rather than just Ubuntu, so you'll get exposed to a wider variety of processes.
[13:26] <bliZZard1> persia : but looks like there are no open bugs
[13:26] <persia> bliZZard1: In any python packages?  I find that hard to believe.
[13:26] <bliZZard1> https://bugs.launchpad.net/%7Epythonistas
[13:27] <bliZZard1> Cannot see any there
[13:27] <emgent> ARGH
[13:28] <emgent> one Italian agency uses the logo of ubuntu in the selling houses newspaper -.-
[13:30] <persia> bliZZard1: Try https://bugs.launchpad.net/~pythonistas/+packagebugs , and look in the "open" column.  There are 249 bugs available, in a variety of packages.
[13:31] <bliZZard1> ok..got it... how it didnt show before!
[13:32] <persia> There's a difference between bugs related to a team, and bugs in packages watched by a team.  I'm not sure why it is that way, but for teams that handle a selection of packages, it is often better to look at the packagebugs page.
[13:33] <elky> emgent, link?
[13:34] <emgent> elky: this is an italian newspaper, not online. :\
[13:34] <bliZZard1> persia : thanks. let me look at it and Q here , if i have any
[13:34] <persia> bliZZard1: Good luck, and thanks for helping.
[13:35] <bliZZard1> one more quick Q,am using IRC from GAIM, though my nick is 'bliZZardz', why does it show 'bliZZard1' here??
[13:36] <elky> emgent, the steps 'scan' and 'upload' may need inserting somewhere in the request then :)
[13:36] <emgent> sure i will do :)
[13:36] <persia> Invisible nick conflict.  Try "/nick bliZZardz", and see what message you get.  You might want to have a private chat with NickServ
[13:45] <bliZZardz> persia : I have applied for  a membership in the Pythonista team - do i need to solve some bugs etc to become a member? how does this work?
[13:48] <persia> bliZZardz: I have no idea.  I'm not a pythonista :)  Many teams like to see some work as part of an application to join, and anyone is generally welcome to fix bugs, no matter in which teams they may or may not happen to have membership.
[13:49] <bliZZardz> understanable
[14:23] <stevenbrown> hey all, I can't find any quick examples of packaging a library... no step by step examples at all, actually.  is there some documentation you can point me to?
[14:24] <persia> stevenbrown: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
[14:26] <stevenbrown> persia: thx, I ran across this... but it doesn't really have a step-by-step....  like.. what am i supposed to do after using the dh_make -l ?  Can't do a debuild...  do I have to manually create the lib and lib-dev packages?
[14:27] <persia> stevenbrown: Hmm.  I'm not very familiar with what dh_make -l gives you.
[14:28] <persia> At the end, debuild will work, but to get there, your best bet is likely that guide.  You might look at some other libraries in the same language as the one you are packaging as samples.
[14:31] <stevenbrown> persia: dh_make -l just creates the debian folder, as usual, but it adds two folders lib<name> and lib<name>-dev to it with the basic deb "data" layout, I guess (DEBIAN folder,  usr/etc...)
[14:32] <stevenbrown> persia: anyway, thanks.  I'll have to spend some time on that guide.  I just found it weird.. I couldn't find any example of packaging a lib..
[14:32] <albert23> stevenbrown: the MOTU school may help: https://wiki.ubuntu.com/MOTU/School/LibraryPackaging. The second part goes through library packaging step by step.
[14:33] <stevenbrown> oh awesome.  I'll look at that!  Thanks! :)
[14:38] <bliZZardz> persia : PM'ed you
[15:15] <cyberix> What would be the best example package for Python library packaging?
[15:47] <Kopfgeldjaeger2> Shirish Agarwal here?
[15:48] <Hobbsee> Kopfgeldjaeger2: as shirish
[15:49] <Hobbsee> [00:49] [Whois] shirish is a user on channels: #launchpad #ubuntu-meeting
[15:49] <Kopfgeldjaeger2> thanks, already catched him :)
[15:53] <Hobbsee> Kopfgeldjaeger2: caught, fyi.
[15:54] <Kopfgeldjaeger2> oh... yes :/
[15:54] <Hobbsee> (catched does not exist)
[15:54] <Hobbsee> :)
[15:54] <laga> smartass. ;)
[15:55] <Hobbsee> laga: heh.  tis an old habit from proofreading documents - including de-denglishing the ubuntu release notes.
[15:55] <Kopfgeldjaeger2> I understand, yes... I just often forget such forms for some verbs
[15:56] <Hobbsee> english is a crazy language.
[15:56] <Hobbsee> yet, in some ways, so is something like german.  or japanese.  :(
[15:57] <laga> Hobbsee: TBH, i had "did you mean "caught?" pop up in my head, but i didn't bother to type it out
[15:57] <laga> you'll have irregular verbs in all languages, i guess
[15:57] <Hobbsee> yeah
[15:58]  * Kopfgeldjaeger2 is really ashaming hisself
[15:58] <Kopfgeldjaeger2> :p
[16:00] <laga> Hobbsee: BTW: so, when proofreading, you'd comment on all mistakes in IRC? ;)
[16:00] <Hobbsee> laga: i usually grab the text, stick it in a text file, and hand the done version back
[16:01] <Hobbsee> or ask for clarification, or say "you may want to do this"
[16:01] <Hobbsee> or sometimes it's entirely over irc, yes.
[16:01] <Hobbsee> (they can then run diff as appropriate)
[16:02] <laga> Hobbsee: i was just messin' with ya. ;)
[16:02] <Hobbsee> i know :P
[16:02]  * Hobbsee messes with laga, the next time he asks for a review
[16:02] <laga> heh. darn.
[16:02] <Hobbsee> :P
[16:40] <SpookyET> hi
[16:40] <SpookyET> What's the workaround to renaming files? foo.install does not seem to allow renaming of files making it quite worthless.
[16:41] <Kopfgeldjaeger2> cp in debian/rules ?
[16:42] <ScottK> mv more likely.
[16:46] <Kopfgeldjaeger2> Is bug #240191 worth doing an SRU? and is the intrepid-debdiff OK?
[16:46] <SpookyET> Why would you make an install wrapper that has less features than install
[17:24] <SpookyET> I'm using CDBS and I have a install/foo:: with some mv rules. mv complains that it can't find the files.  debian/foo/ is empty.
[17:48] <SpookyET> http://paste2.org/p/41679 I don't understand why the custom install rule is not executed last. It runs to early and mv can't find the file
[18:04] <ScottK-laptop> SpookyET: Does your package use Python distutils (i.e. setup.py)?
[18:08] <ScottK-laptop> If you do, you probably need include /usr/share/cdbs/1/class/python-distutils.mk in your debian/rules.
[20:31] <cyberix> Is it ok to copy a version requirement from upstream web site to package?
[20:31] <cyberix> without verifying that it really doesn't work with earlier version
[20:31] <cyberix> s
[20:32] <cyberix> Or would it be preferable to just leave the version requirement out and only depend on the required package.
[20:35] <joaopinto> cyberix, regardless if it works or not with a previous version, the upstream documentation should be followed
[20:36] <cyberix> joaopinto: Ok. Thanks.
[20:38] <norsetto> hullo
[20:41] <RoAkSoAx> hi all... anyone know how to create a autotools rerun patch?
[20:43] <directhex> carefully
[20:47] <geser> RoAkSoAx: do you need to rerun autoconf? is the change too big to manually patch it?
[20:48] <RoAkSoAx> geser, yeah i need to rerun autotools, otherwise it wont build....
[20:49] <geser> RoAkSoAx: dpatch?
[20:50] <RoAkSoAx> geser,  the package i'm working on is blam, and the hardy package had a autotools_rerun patch... without it, it won't build
[20:50] <geser> RoAkSoAx: which patch system does it use?
[20:51] <RoAkSoAx> geser, cdbs
[20:52] <geser> hmm, in that case I'd try to create a copy of the package, run autotools on it, and diff -Nur the original dir and the copy
[20:53] <geser> and check if the diff looks sane (only changes to expected files)
[20:55] <nxvl> RoAkSoAx: what's the problem?
[20:56] <RoAkSoAx> nxvl, need to create a autotools rerun patch
[20:56] <RoAkSoAx> geser, thanks i'll try :)
[20:56] <nxvl> RoAkSoAx: why?
[20:56] <RoAkSoAx> nxvl, otherwise the package won't build
[20:56] <nxvl> RoAkSoAx: package?
[20:57] <RoAkSoAx> nxvl, blam
[20:57] <nxvl> mm
[20:57] <nxvl> i have work on it before
[20:57] <nxvl> i think
[20:57]  * nxvl checks
[21:00] <nxvl> RoAkSoAx: have you merged the Build-Depends?
[21:00] <nxvl> RoAkSoAx: in this case you can't drop any or other
[21:00] <nxvl> RoAkSoAx: you need to do a merge of the 2 of them
[21:01] <RoAkSoAx> nxvl, merged the Build-Depends as in using the debian ones??
[21:01] <nxvl> not
[21:01] <nxvl> nop
[21:02] <nxvl> as in using the higher versions of the 2 of them
[21:02] <nxvl> for example in debian you have libgecko2.0-cil (>= 0.11) and in ubuntu libgecko2.0-cil (>= 0.11-3ubuntu4~asac6)
[21:02] <nxvl> so you need tu use the ubuntu one
[21:02] <nxvl> but
[21:03] <nxvl> for mono-mcs in ubuntu you have 1.1.17 and fo debian 1.2.6, so you need to use debian one
[21:03] <nxvl> so you need to use a combination of the 2 of them
[21:03] <nxvl> otherwise it won't work
[21:03] <RoAkSoAx> nxvl, i believe that libgecko2.0-cil (>= 0.11-3ubuntu4~asac6) no longer on the repos for intrepid
[21:03] <nxvl> RoAkSoAx: but you can have a higher version
[21:04] <nxvl> RoAkSoAx: and that's what it said inthere
[21:04] <RoAkSoAx> Package libgecko2.0-cil
[21:04] <RoAkSoAx>     * intrepid (libs): CLI binding for the GtkMozEmbed library, unstable version
[21:04] <RoAkSoAx>       0.11-3ubuntu4: amd64 i386
[21:04] <nxvl> yes
[21:04] <nxvl> 0.11-3ubuntu4 >= 0.11-3ubuntu4~asac6
[21:05] <nxvl> so it's fine
[21:05] <RoAkSoAx> yep
[21:05] <RoAkSoAx> i checked all that
[21:05] <nxvl> try first to merge the build-depends
[21:05] <nxvl> maybe that fix the build
[21:06] <RoAkSoAx> but... wont build cause of the rerun_autotools patch, and by removing the patch... won't build either
[21:06] <nxvl> RoAkSoAx: then check why it fails
[21:06] <nxvl> RoAkSoAx: maybe debian or upstream has do changes on the file that patch patches
[21:06] <nxvl> ivoks: hiQ
[21:07] <nxvl> ivoks: are you still sick :P
[21:07] <ivoks> nxvl: hi! how are you!
[21:07] <RoAkSoAx> i think that's why i have to rerun autotools
[21:07] <ivoks> eh... ?
[21:07] <nxvl> :D
[21:07] <nxvl> ivoks: fine, working on augeas
[21:07] <RoAkSoAx> nxvl, https://bugs.launchpad.net/ubuntu/+source/blam/+bug/226670
[21:07] <ivoks> nice...
[21:07] <nxvl> ivoks: it seem really cool
[21:07] <nxvl> ivoks: it will make us do a lot of less work
[21:08] <nxvl> ivoks: so i think we can have ucsa before 10.4, which was our goal
[21:08] <ivoks> nxvl: does it support .d directories? :)
[21:09] <nxvl> RoAkSoAx: have you tried to apply that patch by hand
[21:09] <nxvl> ivoks: i think it does, but the problem now is that it has not much lenses, so it doesn't support much services
[21:10] <nxvl> ivoks: but i don't think it will have much problems since it uses a tree which is equal to the fs
[21:10] <nxvl> ivoks: so it won't be hard to use conf.d, that must be declared on ucsa, not on the lib
[21:11] <ivoks> right...
[21:11] <nxvl> ivoks: the lib takes the name/path of a file and the components you want to change/read and the value to write them
[21:11] <nxvl> ivoks: and it write to the file
[21:12] <ivoks> nxvl: i see, so, name and location of conf file is irrelevant
[21:12] <nxvl> ivoks: so you just need to pass the conf.d path to it
[21:12] <nxvl> ivoks: yep
[21:12] <nxvl> ivoks: kind of
[21:12] <RoAkSoAx> nxvl, yes, http://pastebin.ubuntu.com/22197/
[21:13] <nxvl> ivoks: i haven't test it that far since i've been busy this days, but it seems to be that way according to the documentation
[21:13] <nxvl> ivoks: if you want to try it, there is a quick tour on the web page which tells you how to use the augtool, so you can test and send me your findings/fix it/whatever
[21:13] <ivoks> i'll take a look at it some other day, cause it's past 10PM here :)
[21:14] <nxvl> RoAkSoAx: 98?
[21:14] <RoAkSoAx> nxvl, just testing :P
[21:14] <nxvl> ivoks: yes, i didn't say now, just when you have some time
[21:14] <nxvl> :D
[21:15] <RoAkSoAx> nxvl,  i just changed the patchname to 98 so that i create tha patch name with cdbs-edit-patch
[21:15] <ivoks> nxvl: i have to finish some short term objectives for 8.10, like mail server :D
[21:16] <nxvl> ivoks: yes, we all are busy, if you can't there is no problem, but thanks for point me on some test cases :D
[21:16] <RoAkSoAx> nxvl, well anyways, after applying the patch still shows the same error: http://pastebin.ubuntu.com/22198/
[21:16] <nxvl> ivoks: on the other hand if you find some time to do it, i will be really thankful :D
[21:16] <ivoks> nxvl: will do ;)
[21:17] <nxvl> RoAkSoAx: yes, because it doesn't apply the patch correctly
[21:17] <RoAkSoAx> nxvl, yep, that's why  i was wondering how to create a new autotools rerun patch
[21:17] <nxvl> i love terminator!
[21:19] <nxvl> RoAkSoAx: easy, just apply the patch by hand as in read the patch and apply the changes editing the configure file
[21:19] <nxvl> :D
[21:20] <nxvl> RoAkSoAx: the problem is as i said earlier the configure has changes and it's faling trying to find the lines to change
[21:21] <nxvl> for example, what on the previous version was in line 21196 now it's on 21808
[21:22] <nxvl> and it has a new line that it isn't on the patch
[21:23] <nxvl> now you have "gnome-sharp-2.0 >= \$GNOMESHARP_REQUIRED_VERSION\"") >&5" which is not on the patch
[21:23] <nxvl> so it's faling
[21:24] <RoAkSoAx> nxvl so what to do then... remember im a newbie :PxD
[21:24] <nxvl> just open 2 terminals
[21:25] <nxvl> in one leave the patch open
[21:25] <nxvl> (or move it to other location and open it from there)
[21:25] <RoAkSoAx> ok
[21:25] <nxvl> in the other create a new patch using https://wiki.ubuntu.com/PackagingGuide/PatchSystems#head-d9502e152da03e1c4d796358e591dc9ec7ce7707
[21:26] <nxvl> and start editing the configure file with the changes on the patch
[21:26] <nxvl> and that way create a new patc
[21:26] <nxvl> patch*
[22:38]  * pwnguin has a question about glchess
[22:38] <pwnguin> why is it in universe, and also provided in gnome-games?
[22:39] <ajmitch> because gnome-games incorporated a number of other packages upstream, so it may not have been removed as a separate package
[22:39] <ajmitch> that's if I recall history correctly :)
[22:41] <pwnguin> well im chatting with one of the gnome games debian maintainers, and he's apparently resolved the 'most duped' bug down to that
[22:41] <pwnguin> most duped in gnome, i should point out
[22:46] <pwnguin> hmm. well the bug itself is actually about python-triggers
[22:54] <pwnguin> http://bugzilla.gnome.org/show_bug.cgi?id=524665
[22:54] <pwnguin> im currenlty digging through LP for untouched reports =(
[23:38] <kostmo> I'm trying to roll a .deb for an application written in python
[23:39] <kostmo> how does one specify which files the .deb should include
[23:39] <Colonel> a
[23:41] <kostmo> i.e. the files listed in "Included Files" when viewed from Gdebi
[23:41] <RAOF> kostmo: Generally, one builds up a mock filesystem tree in the package build directory, and pushes files there.
[23:42] <RAOF> If your python project has some form of setup.py, Makefile, or other install script, you should just be able to use that.
[23:42] <kostmo> ok, I have done that, but the list of "Included Files" in gdebi is not including all of the files in my mock tree
[23:43] <kostmo> for instance, i have some files in /opt, but opt is not listed
[23:44] <RAOF> Can you post your rules file?
[23:45] <kostmo> I am using an unmodified /usr/share/doc/debhelper/examples/rules.indep
[23:46] <RAOF> Well, that's not going to work.  It doesn't actually build anything :).
[23:46] <RAOF> All of the "build the package here", "install the package here" commands are commented out :)
[23:46] <kostmo> nothing should be built, though, since it's a python script
[23:46] <RAOF> Have you read the packaging guide(s)?
[23:47] <kostmo> yes I've been trying to follow them
[23:47] <kostmo> for the "install the package here" part, should I write a bash command that copies my mock tree?
[23:48] <kostmo> I'm just wondering if there's a dh_* script that does that part automatically
[23:48] <RAOF> You could just install with dh_install.
[23:49] <kostmo> ok i'll try that
[23:49] <RAOF> But you shouldn't _have_ a mock tree before building the package; the idea is that you start with just the code for what you want to be packaging, and then turn this into a .deb with commands in the debian/rules file.
[23:50] <kostmo> hmm
[23:51] <RAOF> It would help to know exactly what you're packaging; a single .py file that works as a script with no dependencies?  A python program, complete with internal libs?
[23:51] <bimberi> Also, iirc Debian/Ubuntu packages shouldn't put anything under /opt.
[23:51] <RAOF> Correct.
[23:51] <kostmo> my app consists of 2 .py files, and a couple of images
[23:52] <kostmo> my application is a GUI control app for a USB rocket launcher toy
[23:52] <kostmo> where would you suggest that fits under the filesystem hierarchy?
[23:53] <RAOF> Anything that you can run lives under /usr/bin; the images live under /usr/share/$PACKAGENAME
[23:54] <kostmo> so actually, the second .py file is not runnable - i guess you could call it a library
[23:55] <kostmo> can I create a subdirectory in /usr/bin to hold both the runnable .py file and the library file?
[23:56] <kostmo> also, what is the preferred way to generate the mock hierarchy from within the 'rules' file?