[00:05] <Drk_Guy> Hi guys!
[00:06] <Drk_Guy> I'm having issues with gambas2 packaging
[00:06] <Drk_Guy> lol, i forgot some commas
[00:07] <Drk_Guy> Forget it
[00:17] <tacone> figli di puttana
[00:18] <tacone> ops
[00:18] <tacone> wrong window
[00:19] <slangasek> that's what they all say
[00:19] <roo82> I am highly offended sir
[00:19]  * tacone turns red :-)
[00:19] <roo82> ;)
[00:19] <roo82> Pueribus Impudis
[00:20] <roo82> Anyway, enough butchered latin for one night. I'm off to bed
[00:22] <emgent> hhahah
[00:22] <emgent> poor tacone :)
[00:22] <tacone> not my fault. world's against me :-D
[00:26] <kunigami> Hi, all.
[00:29] <kunigami> I have a question about mentorship program. Could someone help me?
[00:34] <tacone> kunigami: don't ask to ask :-)
[00:38] <kunigami> Any hint from where to start? I read a lot of things in the wiki, but I'm a bit confused.
[00:44] <tacone> did you read https://wiki.ubuntu.com/MOTU/GettingStarted ?
[00:46] <bddebian> Heya gang
[00:51] <RoAkSoAx> vorian, good :) how ya doing!?
[00:59] <kunigami> Well, I tried to do so, but it seems a bit confusing for me =(
[01:17] <tacone> kunigami: to me too. You could just trying to solve a bug then ask here for help when you get some issue
[01:31] <neuromit_> Ncommander, you around?
[01:32] <vorian> RoAkSoAx: howdy
[01:32] <RoAkSoAx> vorian, good good, how ya doing?
[01:32] <vorian> great
[01:33] <RoAkSoAx> vorian, so what's new? i've been giving a quick review to the debian new maintainer's guide and i have setup this wikipage: https://wiki.ubuntu.com/4nDr3s/Mentorship
[01:33]  * vorian looks
[01:34] <NCommander> neuromit, yup
[01:35] <neuromit_> you got some time to talk to me about compiling multiple debs from a single source package?
[01:35] <neuromit_> I'm home now and I've ssh'd into my work machine
[01:35] <tbielawa> hello MOTUs
[01:35] <NCommander> neuromit, yeah, I can talk
[01:36] <emgent> moin
[01:36] <NCommander> neuromit, its pretty straightforward; you have multiple binary entries in the control file, and then you use *package*.install files to move files from debian/tmp to each package folder
[01:37] <neuromit_> NCommander: i'm guessing that the file names of the .install files has the be the same as the packages in control?
[01:37] <NCommander> neuromit, yup
[01:38] <NCommander> neuromit, its pretty straightforward if you know how to use dh_install
[01:38] <neuromit_> so I've never used dh_install by hand before...
[01:39] <neuromit_> dh_install is called by dpgk-buildpackage right?  I mean unless its commented out in the rules file right?
[01:41] <tbielawa> Can some one take a look at my REVU please? http://revu.ubuntuwire.com/details.py?upid=2900
[01:46] <neuromit_> NCommander, does dh_install take an install file as an argument?
[01:47] <cody-somerville> neuromit_, All the debhelper scripts have man files :)
[01:51] <tbielawa> cody-somerville: do you have time to check out a revu upload?
[01:53] <neuromit_> so when I build a package in the form of a single binary a .install file isn't created.... if I create one will it disrupt the building of the deb?
[02:04] <neuromit_> so I've been reading the man pages for dpkg-buildpackage, dh_install, dh_icons.... and I can't quite seem to figure out how to package an icon with my debian package... I've included the icon in the debian dir, but I'm not exactly sure what to add to the rules file to include it in the installation
[02:06] <tbielawa> neuromit_: I would put an entry for it in your *package*.install file
[02:06] <tbielawa> Or do you mean like a .desktop type file?
[02:08] <neuromit_> no I mean a icon file.  So when I followed the ubuntu packaging guide I thought I didn't need a *package*.installl file if I was compiling a single binary, so I never created one, if I create one will it disrupt the compiling of the deb, if all that is in it is the icon file?
[02:11] <RAOF> neuromit_: No, not at all.
[02:12] <neuromit_> ok one more question... (sorry for flooding ;-p )  but will dh_install automatically install all of the *package*.install files or do I have to specify them in the rules file?
[02:12] <tbielawa> hiya nxvl
[02:13] <nxvl> hi!
[02:13] <RAOF> neuromit_: Reading 'man dh_install' will tell you that; the answer is that it will automatically read $package.install (with some fairly minor assumptions).
[02:15] <emgent> heya nxvl
[02:15] <nxvl> hi
[02:15] <nxvl> :D
[02:21] <tbielawa> nxvl: you worked with anything that had a weird upstream version number?
[02:23] <tbielawa> or, anyone have the right advice for dealing with upstream versions with hyphens in them?
[02:23] <nxvl> a lot
[02:23] <nxvl> :D
[02:23]  * NCommander returns
[02:24] <tbielawa> nxvl: Can you tell me what to do when upstream is "1.4.3-2"? all the debian utilities think I'm making a debian native package because of the hyphem
[02:24] <StevenK> tbielawa: 1.4.3-2-1
[02:25] <tbielawa> You mean to add a -1?
[02:25] <nxvl> tbielawa: package and upstream link
[02:25] <tbielawa> so in the end it would be bibus-1.4.3-2-1-0ubuntu1 ?
[02:28] <tbielawa> heh, to continue the question spam, if anyone has the URL to something that can clarify this for me I'd appreciate it. the deb policy manual wasn't clear enough fo rme
[02:28] <wgrant> tbielawa: No, bibus 1.4.3-2-0ubuntu1
[02:29] <nxvl> tbielawa: debian policy
[02:29] <nxvl> tbielawa: can you send me a link to the upstream page
[02:29] <tbielawa> wgrant: lintian and all deb helper scripts refude to belive i'm making anything but a native debian package. when I build it it refuses to see the .orig.tar.gz
[02:29] <tbielawa> nxvl: link coming
[02:30] <wgrant> tbielawa: How have you named the .orig.tar.gz?
[02:30] <tbielawa> http://sourceforge.net/project/showfiles.php?group_id=110943
[02:31] <tbielawa> wgrant: bibus-1.4.3-2.orig.tar.gz
[02:31] <wgrant> tbielawa: bibus_1.4.3-2.orig.tar.gz
[02:31] <nxvl> actually -2 is the debian version
[02:32] <wgrant> nxvl: No it isn't.
[02:32] <wgrant> nxvl: The part after the last - is the Debian version.
[02:32] <wgrant> Not if it's in the upstream version.
[02:32] <wgrant> Oh.
[02:32] <wgrant> I see.
[02:32] <wgrant> You're right - it's not part of the upstream version at all.
[02:32] <tbielawa> this is where all my problems are coming from. He debianized it, wayyy out of spec
[02:32] <nxvl> wgrant: are you here -> http://sourceforge.net/project/showfiles.php?group_id=110943&package_id=151072&release_id=600703
[02:33] <nxvl> is that package in debian?
[02:33] <wgrant> tbielawa: Use the real 1.4.3 tarball.
[02:33] <nxvl> yep
[02:33] <wgrant> nxvl: I see now - I was taking tbielawa's word that the upstream version was 1.4.3-2.
[02:33] <nxvl> -2 is the upstream-debian version
[02:33] <nxvl> which we don't care of
[02:33] <nxvl> wgrant: oh ok :D
[02:33] <tbielawa> there is none?
[02:33] <nxvl> the upstream version we care about is 1.4.3
[02:34] <tbielawa> rather @wgrant: there is no version as just 1.4.3
[02:34] <wgrant> tbielawa: Then you complain at upstream for being ridiculous.
[02:34]  * tbielawa remembers talking with LaserJock about why no one wanted to touch this package
[02:34] <nxvl> tbielawa: take a look at the link you first post
[02:35] <nxvl> tbielawa: it has a debian and a windows version
[02:35] <nxvl> tbielawa: the windows version doesn't has the -2 part
[02:35] <nxvl> so we can assume it's not part of upstream
[02:35] <nxvl> but from upstream packaging
[02:35] <tbielawa> nxvl: I see what you mean.
[02:35] <nxvl> so we don't care about it, because we know upstream packaging goes from bad to horrible
[02:35] <tbielawa> I need to get a clean un debianized 1.4.3 from upstream
[02:36] <wgrant> tbielawa: Correct.
[02:36] <nxvl> tbielawa: just take the .orig.tar.gz
[02:37] <tbielawa> nxvl: take it from where? I've got this up on REVU almost done save for this rediculous versioning problems
[02:37] <wgrant> nxvl: There isn't one.
[02:37]  * nxvl rechecks
[02:37] <wgrant> nxvl: Upstream has packaged it natively. There is no 1.4.3 tarball.
[02:37] <neuromit_> so I've created my *package*.install file, i uncommented dh_install in the rules file, I added the appropriate dirs to the dir file, and I added my icon file exist under the debian directory, but when I run dpkg-buildpackage -rfakeroot, I get  cp: cannot stat `./usr/share/icons/*icon*.png': No such file or directory   I can't figure out what i'm doing wrong
[02:37] <wgrant> Which is plain wrong.
[02:38] <tbielawa> and in the end, this winds up breaking my watch file
[02:38] <nxvl> well
[02:38] <tbielawa> hes using his sourceforge file serving part as his apt mirror
[02:38] <nxvl> yes, but, there is a .tar.gz
[02:38] <wgrant> nxvl: But it's a native Debian packaged one.
[02:38] <nxvl> so you can download it, remove debian/ and you got orig.tar.gz
[02:38] <nxvl> or something
[02:38] <nxvl> ok
[02:39] <nxvl> what would i do in this particular case:
[02:39] <nxvl> ping upstream and ask for a clean tarball
[02:39] <tbielawa> I agree
[02:39] <tbielawa> thanks
[02:40] <tbielawa> this has been hell getting through. it's two months in now
[02:40] <tbielawa> I just want to get it finished in time to get it into intrepid
[02:41] <tbielawa> neuromit_: can you pastebin us your .install file and you .dirs file?
[02:41] <tbielawa> http://pastebin.ubuntu.com
[02:43] <neuromit_> http://pastebin.ubuntu.com/29169/
[02:44] <tbielawa> neuromit_: when working with the .install file this helps me remember whats going on
[02:44] <tbielawa> imagine it's like using the copy command and that it's being run from the main directory of your package
[02:45] <tbielawa> so you'll want something like this in your .install file:
[02:45] <tbielawa> soma-tspikes.png    usr/share/icons
[02:46] <neuromit_> ok.. I wasn't sure I could do that as none of the examples of in man page of dh_install were like that
[02:46]  * tbielawa nods
[02:55] <neuromit_> tbielawa, Thanks! that did it!
[02:56] <tbielawa> neuromit_:  you're very much welcome
[02:57] <tbielawa> I just sent upstream an email about his wacked out version scheme. He's been very responsive in the past so this should get resolved soon :-)
[04:35] <StevenK> NCommander: You should close bug 247782 in Intrepid
[04:35] <NCommander> StevenK, not if the bug needs to be SRUed
[04:36] <StevenK> NCommander: Well, do you think it requires one?
[04:36] <NCommander> Random segfaults in hardy building stuff would probably count to me.
[04:36] <NCommander> As serve regression
[04:37] <StevenK> Only on a Live CD, unless I'm misremembering?
[04:37] <NCommander> No
[04:37] <NCommander> It effects everything
[04:37] <NCommander> THe original patch allowed for Mono to work on a LiveCD
[04:37] <NCommander> But it causes random segfaults all over the place. evolution-sharp's FTBFS on amd64 was caused by this
[04:37] <RAOF> The bug was discovered by NCommander while working out why evolution-sharp built in sid chroots but not intrepid chroots.
[04:38] <NCommander> RAOF, in addition, it did the same thing on Hardy
[04:38] <RAOF> (But just fine in a non-chroot environment)
[04:38] <NCommander> RAOF, no, it FTBFSed on me in a non-chroot environment
[04:38]  * StevenK approves the Hardy/Intrepid bits
[04:38] <RAOF> NCommander: Oh, even better :).  Worked for me out of teh chroot :)
[04:38]  * StevenK unsubscribes u-m-s
[04:39] <NCommander> It was a rather inconsistant bug ....
[04:39] <StevenK> NCommander: Now, fiddle with the bug, closing the Intrepid task :-)
[04:39]  * NCommander does what StevenK wishs
[04:39] <NCommander> I don't think the patch is in dapper, I should probably see if this braindeadness is in gusty or feisty
[04:40] <NCommander> I'm reconfirming evo-sharp FTBFS on Hardy right now
[04:42] <Awsoonn> hi all, I am wondering if there are some helpful souls here that might mentor me in fixing a simple bug
[04:42] <Awsoonn> bug 250681 is simple enough, I apt-get source irssi
[04:42] <Awsoonn> bug 250681 is simple enough, I apt-get source irssi
[04:43] <Awsoonn> found the string that needs changing
[04:43] <Awsoonn> changed it, but now what should I do? I think I need to make a deb diff or something right?
[04:43] <NCommander> Awsoonn, you need to modify the changelog to create a new ubuntu revision, and possibly update the maintainer, dpkg-buildpackage, and then debdiff the old .dsc and the new .dsc and post
[04:43] <NCommander> THat's pretty much it in a nutshell
[04:44]  * Awsoonn is really new and only kinda understands
[04:45] <NCommander> You need to build an updated package
[04:46] <nxvl> jcastro: around?
[04:46] <NCommander> If it already has ubuntu specific changes, you just need to add a new changelog entry to debian/changelog
[04:46] <Awsoonn> well, accually, before that the source came with a diff should I apply that to the source, then make my change
[04:46] <coppro> start with sudo apt-get build-deps irssi
[04:46] <coppro> or build-dep, can't remember
[04:47] <Awsoonn> no s
[04:47] <Awsoonn> in any case it is done
[04:47] <coppro> k now, is there anything in <srcdir>/debian/patches?
[04:47] <Awsoonn> there is no such folder
[04:48] <coppro> hmm, how big is debian/rules?
[04:48] <NCommander> StevenK, I don't have a reproducible bug for Hardy just yet
[04:48] <Awsoonn> there is no debian folder at all
[04:48] <coppro> what?
[04:48] <tbielawa> whoa
[04:48] <nxvl> coppro: depending on what you use
[04:49] <coppro> there is no debian folder?
[04:49] <Awsoonn> coppro: I think I need to first apply this diff to the source
[04:49] <coppro> oh, yeah
[04:50] <coppro> from the top, run dpkg-source -x <dsc file>
[04:50] <coppro> that will extract the source and apply the diff
[04:51] <Awsoonn> bingo~ now we're rolling
[04:51] <coppro> ok, now, anything in debian/patches
[04:51] <Awsoonn> lots
[04:52] <coppro> what extension?
[04:52]  * wgrant points out that we are not Windows.
[04:53] <coppro> yes, but that doesn't mean we can't have file extensions
[04:53]  * NCommander points out that most patches files do end in .patch or .dpatch ;-)
[04:53] <Awsoonn> coppro: for the patches? there are some .h files and the rest have none
[04:54] <coppro> try running "file <one of the non-.h files>
[04:54] <Awsoonn> 00list.UBUNTU: ASCII text
[04:55] <coppro> ok, I'm just gonna go download the source package myself, one second
[04:55] <Awsoonn> :)
[04:55] <Awsoonn> Thank you for helpnig me coppro
[04:55] <Awsoonn> helping even
[04:56] <coppro> no problem
[04:56] <coppro> ok, while I figure out the patch system, you should make a changelog entry
[04:56] <Awsoonn> ok
[04:56] <coppro> from the top-level srcdir, simply run dch
[04:57] <coppro> that should set up a new log entry
[04:58] <NCommander> Awsoonn, you may need devscripts
[04:58] <NCommander> (and ubuntu-dev-tools has the all helpful update-maintainer script which you may or may not need)
[04:58] <Awsoonn> dch seemed to work
[04:58] <NCommander> Cool
[04:59] <NCommander> It might be a litlte late for this, but are you working in a clean source tree?
[04:59] <NCommander> Or have you already applied your fix to this source tree?
[04:59] <Awsoonn> I have already applied it. :)
[04:59] <coppro> you'll need to undo it
[04:59] <NCommander> Ok, that's a bad thing in this case
[04:59]  * NCommander sees if irssi has a patch system
[04:59] <Awsoonn> it was a one word change, so its no big deal to start over
[05:00] <coppro> NCommander, it's quilt
[05:00] <NCommander> Ew
[05:00] <NCommander> Ok, you can explain to him the patch system :-)
[05:00] <nxvl> Awsoonn: first step on fixing a bug is confirming it
[05:00] <coppro> I'll try
[05:00] <nxvl> Awsoonn: that bug is invalid
[05:00] <Awsoonn> oh?
[05:01] <nxvl> https://bugs.edge.launchpad.net/ubuntu/+source/irssi/+bug/250681/comments/1
[05:01] <Awsoonn> how is it invalid?
[05:01] <Awsoonn> ah
[05:01] <Awsoonn> sweet,
[05:02] <Awsoonn> sooooooo I shall look for a new bug to eat
[05:02] <Awsoonn> I'm sorry guys
[05:02] <coppro> no worries, you've learned something
[05:02] <coppro> which was the goal, after all
[05:02] <Awsoonn>  A lot I recon
[05:03] <NCommander> Awsoonn, it helps if your working on bugs either to run intrepid, or at least have an intrepid chroot sitting around
[05:03] <Awsoonn> I leared to set up an intrepd chroot
[05:03] <Awsoonn> yes that...
[05:03] <coppro> you should also have an intrepid pbuilder
[05:04] <Awsoonn> something I don't understand about chroots
[05:04] <coppro> sudo pbuilder --create intrepid
[05:05] <nxvl> pbuilder is awesome
[05:05] <Awsoonn> if I am running a chroot, can I run X?
[05:05] <nxvl> nope
[05:05] <coppro> yes, in theory
[05:05] <nxvl> no, actually you can't
[05:05] <coppro> why not?
[05:05] <nxvl> because you will already have one X server running on :0 so, the 2nd one would not find it available
[05:06] <nxvl> for running X you will need a virtual machine
[05:06] <nxvl> virt-manager is nice and easy
[05:06] <coppro> right, but if I close my current X session, then start one in a chroot, it'll work right?
[05:06] <coppro> or you can use that one app that can run X inside X, forget what it's called
[05:06] <nxvl> if you have you /dev mounted, yes
[05:06] <nxvl> your*
[05:07] <nxvl> actually i haven't tried it that far, i tried once to run a graphical app and didn't work, so i move to vm
[05:07] <Awsoonn> so can I run a gnome app from a chroot in my current X session then?
[05:07] <nxvl> and now that we have ubuntu-vm-builder is even easier
[05:07] <StevenK> Awsoonn: "Sort of"
[05:08] <Awsoonn> :)
[05:08] <coppro> isn't there some X server that runs inside another server though? What's that called?
[05:08] <StevenK> Xnest
[05:08]  * Awsoonn enjoys the constant state of confusion
[05:08] <nxvl> coppro: PITA
[05:08] <coppro> that's not the one I was thinking of
[05:08] <StevenK> Xephyr
[05:08] <coppro> sounds more like it
[05:09] <nxvl> i still call it PITA
[05:10] <Awsoonn> let me see if I understand now, he chroot is only useful for testing CLI apps basicly and if I want to work on Rythmbox for example I need a VM
[05:10] <Awsoonn> or another system
[05:10] <coppro> not necessarily
[05:10] <coppro> there are a few ways around that
[05:10] <nxvl> a chroot is usefull for building packages on a clean environment
[05:10] <coppro> like closing down X on hardy and running it from the chroot
[05:11] <nxvl> and to be sure you are using clean and standard packages and not 3rth party ones
[05:11] <coppro> yeah
[05:11] <coppro> I don't use it for development
[05:11] <Awsoonn> well, from the chroot, it is by default clean no?
[05:11] <StevenK> Awsoonn: Rythmbox is harder -- you want to test the full stack, like DBUS and such, and you can't easily have the Rythmbox in the chroot talking the dbusd on the host
[05:11] <coppro> yes, that's the point
[05:12] <Awsoonn> StevenK: so if I wanted to do that, you would recommend a VM?
[05:12] <coppro> I would recommend setting up a nested X server, but that's just me
[05:13] <StevenK> Awsoonn: kvm, if your machine supports it
[05:13] <tbielawa>  <3 kVm :)
[05:13] <Awsoonn> how do I use kvm?
[05:13] <coppro> how do I get udev to work in a chroot?
[05:14] <wgrant> coppro: You bindmount /dev instead.
[05:14] <Awsoonn> use virt-manager ?
[05:14] <tbielawa> Awsoonn: https://help.ubuntu.com/community/KVM
[05:14] <tbielawa> it's involved
[05:14] <Awsoonn> :0 so am I...
[05:14] <coppro> is there a way to set it up in fstab?
[05:14] <tbielawa> Awsoonn: but simple once you get the hang of it. We took a week and implemented a system in my workplace to automate the process
[05:15] <Awsoonn> my cpu doesn't suport kvm it seems
[05:15] <Awsoonn> so I'm stuck with vbox methinks
[05:15] <nxvl> qemu
[05:16] <nxvl> use ubuntu-vim-builder
[05:16] <nxvl> just apt-get it
[05:16] <nxvl> ubuntu-vm-builder*
[05:16]  * Awsoonn is getting
[05:17] <Awsoonn> pbuilder finished btw
[05:17] <Awsoonn> is there anything I should do to it?
[05:19] <Awsoonn> what should I do with ubuntu-vm-builder as well?
[05:19] <nxvl> read the man page
[05:19] <nxvl> https://wiki.ubuntu.com/PbuilderHowto
[05:19] <coppro> awsoonn, also read this: http://wiki.mandriva.com/en/Development/Howto/Chroot#Using_Xnest
[05:19] <Awsoonn> :) Should have seen that comming
[05:19] <coppro> that's an easy way to test graphical stuff from within a chroot
[05:20] <coppro> (replace the urpmi command with "sudo apt-get install xnest")
[05:44]  * NCommander returns from duty
[05:45] <kostmo> any MOTU's around?
[05:46] <NCommander> kostmo, I'm not, but if you would like a review on a package, I'm glad to help
[05:47] <kostmo> NCommander: you may have seen this one already ;) http://revu.ubuntuwire.com/details.py?upid=2940
[05:47] <kostmo> thanks tho
[05:48] <NCommander> oh yeah
[05:48] <NCommander> I already did some reviewing on it
[05:48] <kostmo> I revised the package based on another round of comments - just hoping for some official approval
[05:49] <jmarsden> I have a CDBS-based short debian/rules that doesn't do what I want, can someone take a look please?  http://pastebin.ubuntu.com/29204/
[05:49] <NCommander> jmarsden, did you get googlegears to work?
[05:50] <NCommander> And uh, what's wrong with it?
[05:50] <jmarsden> NCommander: I get errors from lintian about the config.sub/guess files being too old.
[05:50] <jmarsden> googlegears?  Was I doing anything with that?? :-)
[05:50] <NCommander> er, wrong person
[05:50] <NCommander> sorry, a tad slow tonight
[05:51] <NCommander> Post the lintian output the -v option
[05:54] <jmarsden> NCommander: http://pastebin.ubuntu.com/29209/
[05:55] <NCommander> jmarsden, I'm not an expert, but I'm going to surmise that lintian is detected the original config.* from the source tarball, and not anything you've changed
[05:56] <NCommander> jmarsden, ask an MOTU, but I'm going to guess your going to need an override
[05:56] <jmarsden> NCommander: OK... any MOTU's listening who can help? :-)
[05:56]  * NCommander kicks cody-somerville
[06:01] <jmarsden> I'll attach a .debdiff to the relevant bug #236140 and see if that triggers help from someone reading LP bugs... the modified package seems to build and run fine, the bug is fixed... it's just those pasky lintian errors in the way, as far as I can see.
[06:16] <NCommander> Anyone here running Ubuntu PPC I can pop a question off of?
[06:18] <jmarsden> NCommander: Try asking on #ubuntu-powerpc maybe?
[06:18] <jmarsden> Or even on plain #Ubuntu ?
[06:24] <RAOF> NCommander: TheMuso had at least one PPC machine, at least at some point in the near past.  Maybe ask him?
[06:24] <NCommander> Well, I requested the user post his sources.lists file
[06:24] <NCommander> The generated errors suggests it got managed
[06:25]  * NCommander is working on his five bugs a day ;-)
[06:39] <NCommander> StevenK, ping
[06:39] <StevenK> NCommander?
[06:40] <NCommander> StevenK, care to looking into sponsoring a main package (it replaces a Recommends to a Suggests because the Recommends adds a GNOME library)
[06:40] <NCommander> https://bugs.edge.launchpad.net/ubuntu/+source/policykit/+bug/250619
[06:40]  * NCommander has now hugged his five bugs for the day
[06:43] <siretart> \sh: re debescan yes, but IIRC the resolution was to wait a bit if someone comes up to fix it eventually. which didn't happen
[06:47]  * StevenK tries to figure out why this package runs configure during make install
[06:48] <NCommander> It didn't do that for me O_O;
[06:48]  * NCommander updates his pbuilder jail though
[06:49] <StevenK> NCommander: Where this package is one that isn't currently in Ubuntu
[06:49] <NCommander> StevenK, oh, I thought you were referring to the bug I linked you to ;-)
[06:50] <StevenK> NCommander: Nope, sorry. :-)
[06:50] <NCommander> StevenK, upload to your PPA or REVU and I'll look at it with you
[06:51] <StevenK> It's sort of on REVU
[06:51] <NCommander> "sorta"?
[06:51] <StevenK> It's on REVU, but I've updated it a new upstream version and have not uploaded that
[06:52] <NCommander> ah
[06:52]  * NCommander scurries in his kitcehn for food
[06:53]  * warp10 moins
[07:16]  * StevenK works it out, kicking CDBS
[07:16] <StevenK> makebuilddir -> apply-patches -> configure. I need something between apply-patches and configure
[07:18] <NCommander> StevenK, try using the oldstyle rules?
[07:18] <NCommander> vs CDBS?
[07:18] <NCommander> And, can you do me a quick favor, and see if you can access: http://nemesisnetworks.com/revu?
[07:19] <StevenK> NCommander: Loads
[07:20] <StevenK> NCommander: Sure, I could rewrite debian/rules.
[07:20] <NCommander> Thank you
[07:20] <StevenK> Damn CDBS.
[07:20] <NCommander> StevenK, want a hand packaging it?
[07:20] <NCommander> (if you promise to upload it that is ;-))
[07:20] <NCommander> or advocate on REVU
[07:20] <RAOF> I'm pretty sure there's a CDBS magic rule for what you're after.
[07:20] <StevenK> So I am, I just can't find it.
[07:20] <StevenK> makebuilddir is too early.
[07:21] <NCommander> Might be worth poking CDBS's source ...
[07:21] <RAOF> There isn't something nice like "post-configure?
[07:21] <StevenK> Forcing makebuilddir to run apply-patches makes cdbs do ... odd things
[07:21] <RAOF> Heh.
[07:21] <StevenK> post-configure is too late
[07:21] <RAOF> I've tried that before :)
[07:21]  * RAOF obviously meant 'pre-configure' :)
[07:21]  * StevenK chuckles
[07:22] <NCommander> what are you trying to do specifically?
[07:22]  * RAOF guesses: apply a patch to the build system, then touch files so that configure/autogen isn't re-run.
[07:22] <NCommander> StevenK, try prebuild, it comes after makebuilddir, but before patches
[07:22] <NCommander> er, pre-build
[07:22] <StevenK> I need it after patches
[07:22] <NCommander> post-patches?
[07:23] <StevenK> RAOF: Almost. I need to run ./autogen.sh before ./configure, and one of the patches touches configure.ac
[07:23] <StevenK> (And upstream doesn't ship ./configure, damn his black heart)
[07:23] <NCommander> Do you need to modify configure.ac before or after ./autogen.sh?
[07:23] <StevenK> Before
[07:24] <RAOF> StevenK: And ./autogen.sh doesn't call configure?  You could just make CDBS call autogen instead of configure.
[07:24] <NCommander> SO why can't you use post-patches or update-config?
[07:24] <StevenK> Just trying post-patches now.
[07:24] <StevenK> pre-configure isn't actually called as a target.
[07:24] <NCommander> I got that looking at CDBS's source ;-)
[07:24] <StevenK> RAOF: So, you lose. :-P
[07:25] <RAOF> Aww.
[07:25] <NCommander> Do I win?
[07:25] <StevenK> NCommander: See -devel, by the by
[07:25] <StevenK> NCommander: Just checking if you do.
[07:25] <NCommander> StevenK, I'm looking at gmail
[07:25] <NCommander> Don't see anything really of interest that pops out at me
[07:26] <StevenK> I meant #ubuntu-devel
[07:26] <\sh> siretart: what do you think about the suggestion...if we can fix debescan on ubuntu and using our own resources...
[07:26] <NCommander> StevenK, lol, I've been in #d-* too long
[07:26] <StevenK> Right, NCommander loses too.
[07:26] <RAOF> Man, dh7 is the right way to do an automated source package.
[07:27] <NCommander> StevenK, what's wrong with post-patches?
[07:27] <NCommander> (what patch system is your package using?)
[07:27] <RAOF> StevenK: And autogen doesn't call configure?
[07:27] <StevenK> RAOF: Nope.
[07:27] <NCommander> RAOF, in my expereince autogen won't do that out of the box
[07:27] <StevenK> ./autogen.sh is shipped upstream that runs autoreconf.
[07:28] <RAOF> NCommander: Depends on where it's from; GNOME stuff always calls configure.
[07:28] <StevenK> I can hack that to run ./configure $@
[07:28] <NCommander> StevenK, what was wrong with post-patches?
[07:28] <RAOF> Right.  That was actually going to be my next suggestion :)
[07:28] <StevenK> Hmmm.
[07:29] <StevenK> post-patches works. post-patches/<name>:: doesn't
[07:29] <NCommander> post-patches/<name>?
[07:29] <NCommander> I've never seen the /<name> before, what does that do
[07:29] <StevenK> Except that it seems to run post-patches twice
[07:30] <NCommander> d'oh
[07:30] <NCommander> That sounds like a bug in CDBS
[07:30] <StevenK> I'm so going to find CDBS's author
[07:30] <NCommander> and stab him?
[07:30] <StevenK> At first
[07:30] <NCommander> can I just recommend forgoing CDBS?
[07:31] <StevenK> This sounds simpler
[07:31] <NCommander> If your package requires anything remotely weird, it becomes a down right PITA
[07:31] <RAOF> And it's not substantially simpler than dh7 + dpatch.make :)
[07:32]  * NCommander roles his eyes
[07:32]  * RAOF _likes_ dh7.  Especially for cil apps.
[07:32] <NCommander> StevenK, you could always set a variable to see if post-patches is getting called again, and bypass your code if it is
[07:32] <NCommander> (if you can handle that kind of large hack)
[07:33] <StevenK> I might try dh7
[07:34]  * NCommander is now a REVU admin it seems ...
[07:39] <NCommander> StevenK, you won't happen to know anything about openid, would you?
[07:40] <StevenK> NCommander: I can spell it ...
[07:40] <NCommander> StevenK, I'm looking into implementing it for REVU
[07:59] <siretart> \sh: I think we had our chance to fix debescan, and we failed
[07:59] <elmargol> I try to backport a package that needs debhelper 7 for hardy. Any suggestions?
[08:00] <\sh> siretart: ok, let him file a removal request...I'm happy to approve it, when it makes upstream happy
[08:00] <siretart> \sh: he cannot, he has no lp account
[08:00] <siretart> and doesn't want one
[08:02] <RAOF> elmargol: Basically, you can't.
[08:03] <RAOF> elmargol: Unless you also backport debhelper 7, which is likely to make the backports team rather nervous, given that it touches almost everything.
[08:05] <elmargol> Well I guess I patch the debian dir to use debhelper 6 again
[08:05] <RAOF> Yeah.  You can't do a same-source backport.
[08:06] <RAOF> Of course, that'll require that you pretty much rewrite the rules file.
[08:07] <RAOF> elmargol: What package are you looking to backport?
[08:08] <elmargol> gnunet
[08:09] <RAOF> Is that the crazy gnu CLI implementation?
[08:09] <elmargol> no
[08:10] <RAOF> Awww :)
[08:52] <StevenK> NCommander: policykit uploaded
[08:53] <NCommander> StevenK, sweet, thank you
[08:55] <jscinoz> hey guys, i had an idea for a package..
[08:55]  * StevenK counts. I think that's 12 or 13 uploads today
[08:55] <jscinoz> want to get some feedback on it before i go ahead and make it.
[08:55] <jscinoz> ok so: source package etqw, builds binary packages etqw, etqw-server, etqw-data, each of those contains scripts to download client, download server, or copy data from game disc respectively. and they contain relevant launcher shell script to go in /usr/games and the .desktop file for the game client, so its basically an easy way to install system-wide ETQW, only real downside is see is that ID only provides a 32bit binary, but it s
[08:55] <jscinoz> eems to run just fine here on x86_64, so i can't imagine it *not* working on other archs.
[09:04] <huats> Hey everyone
[09:04] <jscinoz> greeting Huats
[09:05] <huats> hello jscinoz
[09:06] <jscinoz> :D
[09:09] <ScottK-laptop> huats: I hope you liked my reply to your UUC application.
[09:10] <huats> ScottK of course
[09:10] <huats> ScottK-laptop: don't know if you see but I told you so yesterday already in private :)
[09:11] <ScottK-laptop> huats: You probably told ScottK which is at my home and I won't see until Thursday.
[09:12] <ScottK-laptop> Good.
[09:12] <huats> :)
[09:12] <huats> Indeed I talked to ScottK
[09:12] <huats> :)
[09:12] <huats> so thanks again :)
[09:14] <ScottK-laptop> You're welcome.
[09:14] <NCommander> StevenK, you've been busy
[09:15] <ScottK-laptop> Wait until curl changes and then changes back half way through the transition and StevenK is trying to rebuild everything. Then you'll see busy ...
[09:15] <ScottK-laptop> It was curl, wasn't it?
[09:15] <StevenK> Yeah, it was curl
[09:15] <StevenK> That caused me to upload roughly 90 packages
[09:16] <ScottK-laptop> I figured you'd remember it (pain sere's things into the brain after all).
[09:16]  * StevenK twitches
[09:16] <ScottK-laptop> ;-)
[09:16]  * StevenK bends wpeditor to his will
[09:16]  * ScottK-laptop goes to bed.
[09:20] <directhex> \sh, not taking the blogowar sitting down, are you \o/
[09:54] <Iulian> cody-somerville: ping
[10:14] <AnAnt> Hello, does this sync request (bug 249158) miss anything to get processed ?
[10:25] <jmunro> is this the right channel for ubuntu packaging advice/support?
[10:28] <Iulian> jmunro: Yup, this is the right one.
[10:29] <jmunro> great stuff
[10:29] <jmunro> ive got a problem building a package, works fine on lpia and i386, but fails on amd64
[10:30] <jmunro> build dependencies are the same, im wondering if it is a fault of my own, or a problem with the amd64 packages?
[10:31] <jmunro> http://launchpadlibrarian.net/16211531/buildlog_ubuntu-hardy-amd64.sugar-develop-activity_33-0ubuntu1~ppa2_FAILEDTOBUILD.txt.gz
[10:31] <jmunro> ive spoken to the launchpad people, they pointed me in this direction
[10:31] <jmunro> dpkg-shlibdeps: failure: couldn't find library libgtk-x11-2.0.so.0 needed by debian/sugar-develop-activity/usr/share/sugar/activities/Develop.activity/lib/libgtksourceview-2.0.so
[10:32] <jmunro> but if you look up in the log, i installed the required packages
[10:32] <jmunro> and as i said, this works fine on i386
[10:37] <slytherin> AnAnt: Just wait for few days.
[10:38] <AnAnt> slytherin: thanks for the review
[10:38] <AnAnt> slytherin: how can I remove swt-gtk from REVU btw ?
[10:39] <slytherin> AnAnt: Ask in this channel only.
[11:38] <thinkgnuo|O> anybody knows this error about packaging >> unstripped-binary-or-object  >> lintian output
[11:52] <slytherin> thinkgnuo|O: you should have dh_strip in debian/rules file, probably before dh_install
[11:52] <thinkgnuo|O> slytherin: the problem is in changelog file
[11:53] <slytherin> thinkgnuo|O: paste complete error somewhere
[11:54] <thinkgnuo|O> slytherin: http://pastebin.com/m4456c0ff
[11:55] <slytherin> thinkgnuo|O: you sure have problems in changelog but unstripped binary is not one of them.
[11:55] <thinkgnuo|O> slytherin: i don't know what is unstripped-binary-or-object
[11:56] <slytherin> thinkgnuo|O: That is why I said you need to add dh_strip in rules file.
[11:56] <thinkgnuo|O> slytherin: http://pastebin.com/d1ca550aa
[11:56] <thinkgnuo|O> slytherin: what is rule file ?
[11:57] <slytherin> thinkgnuo|O: What are you trying to do exactly?
[11:57] <thinkgnuo|O> slytherin: i want to make a standard deb package .
[11:58] <thinkgnuo|O> slytherin: i need a changelog a man page and copyright
[11:58] <thinkgnuo|O> slytherin: and i have a control file but don't know what is rule file
[11:58] <slytherin> thinkgnuo|O: then please read packaging guide, because if you don't know what a rules file is how are you building the package?
[11:59] <thinkgnuo|O> slytherin: ok wait.
[12:04] <thinkgnuo|O> slytherin: i didn't find anything!
[12:04] <thinkgnuo|O> slytherin: did you mean control file?
[12:04] <slytherin> thinkgnuo|O: which guide are you reading?
[12:05] <thinkgnuo|O> slytherin: Linux HOWTOs are documents which describe in detail a certain aspect of configuring or using Linux.
[12:05] <thinkgnuo|O> slytherin: that was in my distro
[12:06] <slytherin> thinkgnuo|O: I was referring to https://wiki.ubuntu.com/PackagingGuide/Complete?highlight=%28packaging%29%7C%28guide%29
[12:06] <thinkgnuo|O> slytherin: http://tldp.org/HOWTO/Debian-Binary-Package-Building-HOWTO/
[12:09] <slytherin> thinkgnuo|O: Check the date it was last modified. I think if you want to create a package for debian then debian wiki is best place to read.
[12:10] <Iulian> Or the debian policy.
[12:12] <thinkgnuo|O> but i don't think it cause any problem
[12:12] <thinkgnuo|O> i think lintian output tell me about having standards ?
[12:15] <slytherin> thinkgnuo|O: You are reading wrong howto. Why do you think it will not cause problem?
[12:16] <thinkgnuo|O> slytherin: yes i think so , anyway thanks a lot , i will follow your link.
[12:28] <emgent> moin
[12:31] <DRebellion> Could somebody please review my package? http://revu.ubuntuwire.com/details.py?package=posterazor Thanks ;)
[13:29] <abogani> Someone could review my package rt-test (http://revu.ubuntuwire.com/details.py?package=rt-tests) on REVU, please? I think to be very near to an "acceptable" version... Thanks in advance.
[13:45] <LucidFox> slytherin, here?
[13:45] <slytherin> LucidFox: yup
[13:46] <LucidFox> fop doesn't build because it depends on org.w3c.dom.svg.*
[13:46] <LucidFox> these files are in batik 1.6's orig.tar.gz
[13:46] <LucidFox> but they are not in batik-1.7-src.zip
[13:47] <slytherin> LucidFox: Yes which is in xml-commons-external. Need to add xml-apis-ext in rules file. But it still fails to build at the javadoc generation step
[13:47] <geser> slytherin: I've looked into the FTBFS for libmatthew-java, and fixed the first problem, just to stumble into the next one
[13:47] <slytherin> geser: what is it?
[13:48] <geser> slytherin: http://paste.ubuntu.com/29293/
[13:48] <LucidFox> Ah, so _that's_ what xml-commons-external was for
[13:48] <LucidFox> so it should be in batik's depends too, not just build-depends?
[13:49] <slytherin> LucidFox: It is in batik's depends. The problem is that fop rules file does not explicitly add it in jar file list. Previously batik was including this jar also inside batik jar.
[13:49] <LucidFox> Ah, I see
[13:49] <LucidFox> I'll look into fop, then
[13:50] <slytherin> geser: Ahh, warnings being treated as errors. I guess there is some flag -Werror to gcc which will need to be removed.
[13:51] <geser> slytherin: that would probably fix it, but wouldn't it be better to fix also the warning?
[13:51] <slytherin> geser: yes but then it would mean patching the source. If you are aware of the correct changes to be made, please go ahead.
[13:51] <geser> the mentioned variable "cr" is a "struct ucred"
[13:51] <RainCT> \sh: is there something missing on bug #210556 or why is it taking so long for the upload to be accepted?
[13:52] <slytherin> ﻿LucidFox: The line it is failing currently after adding xml-apis-ext, is 1024 in build.xml. If my analysis is correct you need to add depends="init" to the javadocs target.
[13:53] <LucidFox> thanks
[14:00] <geser> slytherin: removing -Werror results in the same error
[14:03] <slytherin> geser: I guess -Werror is default for gcc 4.3.
[14:03] <geser> slytherin: or it's a real error now
[14:06] <\sh> RainCT: I don't know...but it looks like no one commented, if it's working or not
[14:07] <RainCT> \sh: they did, but on the other bug report
[14:07] <geser> slytherin: copying the struct definition from /usr/include/linux/socket.h into the source "fixes" it, I just need to figure out the correct fix
[14:07] <\sh> RainCT: hmm...dupe? :)
[14:07] <\sh> RainCT: or just ping pitti and ask him :)
[14:07] <RainCT> \sh: yes, but upstream got angry when I marked it as such -.-
[14:19] <geser> slytherin: bug 239765
[14:21] <sistpoty|work> hi folks
[14:22] <slytherin> geser: But Ubuntu has same version as Debian
[14:23] <slytherin> geser: It looks like wrong bug number was added in changelog in Debian
[14:27] <Awsoonn> good mornin' all~
[14:28] <LucidFox> slytherin> oddly enough, FOP has successfully built on hardy with the intrepid dependencies backported
[14:28] <LucidFox> I'll try pbuilder
[14:29] <geser> slytherin: looking at the linked Debian bug it looks like a different problem
[14:30] <slytherin> LucidFox: I refuse to accept any claim about package successfully built without backing of pbuilder log. :-P
[14:31] <slytherin> geser: right
[14:40] <geser> slytherin: I just take a look at the source code in unix-java.c and it looks buggy to me
[14:46] <geser> bddebian!
[14:47] <bddebian> Heya gang
[14:47] <bddebian> Hi geser
[14:47] <Iulian> Ohh no! It's bddebian!
[14:48] <sistpoty|work> hi bddebian
[14:48] <bddebian> Heh, hi Iulian, sistpoty|work
[14:52] <DRebellion> Could somebody please review my package? http://revu.ubuntuwire.com/details.py?package=posterazor Thanks ;)
[14:55] <norsetto> huats !!!
[14:56] <huats> norsetto!!!
[14:56] <norsetto> norsetto-huats: 2-1
[14:56] <geser> slytherin: how familiar are you with JNI?
[14:56] <huats> you got me this time :)
[14:57]  * norsetto is a sneaky bastard :-)
[14:57] <norsetto> huats: so had some questions about  tktreectrl ?
[14:58] <geser> slytherin: I've added a comment with fixes for some of errors to the bug but there are still some errors left which look related to JNI programming for me
[14:59] <emgent> norsetto: o/
[14:59] <norsetto> emgent: heil to the wm lord!
[15:00] <jcastro> hi norsetto
[15:00] <emgent> heil? -.-
[15:00] <emgent> heya Jorge
[15:00] <jcastro> norsetto: do you remember the # of the ticket you were having a hard time with?
[15:00] <jcastro> hi emgent!
[15:01] <norsetto> jcastro: what ticket? My request for a mailing list?
[15:01] <jcastro> yeah
[15:01] <jcastro> and what was the list?
[15:01] <norsetto> jcastro: I just did it through launchpad, I don't remember any ticket number :-(
[15:02] <jcastro> ah ok
[15:02] <jcastro> so you have a list now?
[15:02] <norsetto> jcastro: the mentoring reception team one
[15:02] <jcastro> oh
[15:02] <norsetto> jcastro: nope, you rejected the request
[15:03] <jcastro> oh, right. Want to put it as another MOTU list?
[15:03] <jcastro> I think that was why (Sorry I am drowning in lists)
[15:03] <norsetto> jcastro: well, if mentoring new contributors is a solely MOTU activity than yes (but find it strange)
[15:03] <jcastro> say, ubuntu-motu-mentoring?
[15:03] <jcastro> oh, I see
[15:04] <jcastro> there's a MOTU mentor list already I see
[15:05] <norsetto> jcastro: yes, thats for everybody, not for the team
[15:05] <jcastro> link me up to your team please?
[15:05] <norsetto> jcastro: https://launchpad.net/~motu-mentoring-reception
[15:06] <jcastro> ok, that page gives me an impression that it is for motu mentoring
[15:07] <jcastro> so what would a new list accomplish that you can't do in ubuntu-motu-mentors?
[15:07] <norsetto> jcastro: yes, that was a very old description (before even my time), I just modified it
[15:08] <jcastro> ok
[15:08] <huats> jcastro: the current list is for every thing related to mentoring... the new and hoped one will be for the communication in the team...
[15:08] <norsetto> jcastro: we need a list where we coordinate all requests, it need to be restricted list since we are dealing with privacy issues
[15:08] <jcastro> ah
[15:09] <jcastro> so, like, ubuntu-motu-mentors-devel or -discuss or -admin or something?
[15:09] <huats> -admin or -discuss seems great from my point
[15:09] <huats> (but norsetto is the big chief)
[15:09] <huats> :)
[15:10] <jcastro> norsetto: ok, can you fire off an email to rt@ubuntu.com with the new description and mention that it needs to  be private and I'll approve it as soon as it hits the queue?
[15:10] <jcastro> sorry about all this running around. :-/
[15:10] <norsetto> jcastro: -admin seems more appropriate, we are really dealing with administartion
[15:10] <norsetto> startion ? oh well ...
[15:10] <norsetto> jcastro: ok, email on the way, thx
[15:13] <Riddell> Iulian: "Library using gtkmm" that really doesn't quality for a long description
[15:13] <Iulian> Riddell: Are you talking about the gtkmm-utils package?
[15:14] <Riddell> Iulian: yes
[15:15] <Iulian> Riddell: Okay, let me have a look at it.
[15:20] <slytherin> geser: I am not much familiar with jni but if I find any clue after reading the comments I will let you know.
[15:20] <Riddell> Iulian: I'll reject and let you upload it with a full description
[15:20] <Riddell> Iulian: the licence is also inconsistent, COPYING says LGPL 2.1 but files are LGPL 2, not a major issue since 2 can be upgraded to 2.1 but would be nice to get upstream to fix that
[15:21] <Iulian> Riddell: Sure
[15:22] <slytherin> Is it possible to calculate rever-build-depends recursively?
[15:25] <Iulian> Riddell: I will send them an email about it. So, for now, all I have to do is change the long description and upload it to revu?
[15:26] <Riddell> Iulian: upload to ubuntu if you can, or give the revu link here if you can't
[15:26] <Riddell> Michael Casadevall about?
[15:27] <azeem> he's NCommander
[15:27] <RainCT> slytherin: why would you need this?
[15:29] <slytherin> RainCT: Just curious. I was wondering how many packages will not be built for first time now that batik is fixed. :-)
[15:29] <siretart> slytherin: does fop build yet?
[15:30] <Iulian> Riddell: I'll paste the revu link here because I don't have upload permission to ubuntu.
[15:31] <slytherin> siretart: No. LucidFox is working on it. I have already told him fix for one problem.
[15:31] <siretart> k
[15:32] <LucidFox> slytherin> And it doesn't work :)
[15:32] <LucidFox> /tmp/buildd/fop-0.94.dfsg/build.xml:1025: javadoc doesn't support the "depends" attribute
[15:32] <LucidFox> wait
[15:32] <slytherin> LucidFox: you put at the wrong place. I means javadocs target not the javadoc task. Just few line above where you have currently put it.
[15:33] <LucidFox> slytherin> Hmm
[15:33] <LucidFox> javadocs already depends on codegen
[15:33] <slytherin> LucidFox: Line 983 to be precise
[15:33] <LucidFox> which depends on init
[15:34] <slytherin> LucidFox: Right I failed to notice that. :-(
[15:34] <slytherin> LucidFox: What is exact error you are getting currently?
[15:35] <LucidFox> Gah... didn't save it
[15:35] <LucidFox> An IOException, I'll post it after rerunning pbuilder
[15:40] <slytherin> LucidFox: Yes, and I feel that the ioexception is due probably due to missing files or folders which essentially means some problem in path reference.
[15:45] <Iulian> Oups, I pressed ctrl-c while uploading gtkmm-utils to revu.
[15:45] <Iulian> How do I check if it was uploaded successfully?
[15:46] <cody-somerville> NCommander, rejected.
[15:52] <jpds> Iulian: http://paste.ubuntu.com/29328/
[15:53] <LucidFox> slytherin> http://paste.ubuntu.com/29329/
[15:53] <Iulian> jpds: Yup - gtkmm-utils_0.3.2-0ubuntu1_source.changes: exiting due to user interrupt.
[15:53] <Iulian> jpds: Could you please rm those files so I can upload it again?
[15:53] <jpds> Iulian: Do them have the same sums?
[15:54] <slytherin> LucidFox: Same error as I was getting yesterday.
[15:55] <Iulian> jpds: Yes
[15:55] <jpds> Iulian: In that case, the upload was successful (?).
[15:57] <slytherin> LucidFox: There is a -verbose option in rules file but looks like it is not used since ant-vars.mk is not included. Can you try?
[15:57] <Iulian> jpds: I don't see the debdiff on revu so it wasn't.
[15:57] <LucidFox> slytherin> sure
[15:59] <jpds> Iulian: Let's see if it still has to move the packages out of the new queue.
[16:00] <Iulian> jpds: I had to upload two more files in order to be successful, right?
[16:04] <jpds> Iulian: I'm not sure if I just rm'em
[16:10] <Iulian> Riddell: http://revu.ubuntuwire.com/details.py?package=gtkmm-utils
[16:10] <IntuitiveNipple> I have a packaging question. Debianising an existing source tarball for use with DKMS. The original tarball has all its source files in the 'root'. This causes problems defining the debian/<package./.install rules so I need to move all the files into a *new* sub-directory "src/". Is there a way to specify doing this without having a massive patch file that removes all existing files and creates them in the new location? (The p
[16:10] <IntuitiveNipple> ackage is using debhelper/cdbs)
[16:12] <slytherin> IntuitiveNipple: Why do you need to move it to src? You can still build it if the files are in root
[16:12] <Riddell> Iulian: uploading
[16:13] <Iulian> Riddell: Wait
[16:13] <IntuitiveNipple> Nothing to do with building - I'm trying to avoid complicated .install rules that otherwise attempt to include debian/ in the source-->install moves
[16:13]  * Riddell waits
[16:13] <Iulian> Riddell: I saw a typo :P
[16:13] <Iulian> I'm uploading a new debdiff.
[16:14] <Iulian> Riddell: + - dialog herlpes
[16:14] <Riddell> Iulian: ok, uploading with that changes
[16:14] <IntuitiveNipple> I assume I can use the debian/rules "patch" target to just do a mkdir && mv ?
[16:17] <Riddell> IntuitiveNipple: you can but mv doesn't sound very reliably reversable
[16:17] <IntuitiveNipple> Riddell: Yeah, hence why I'm asking if there's a better way! :)
[16:17] <Riddell> IntuitiveNipple: well, what are you moving from where to where?
[16:17] <Iulian> Riddell: Uploaded.
[16:17] <slytherin> IntuitiveNipple: Then fix the .install file not the original source.
[16:18] <IntuitiveNipple> The reason I ask is I found creating a bullet-proof .install rule-set with the source in the package root quite problematic since there's no way to say "don't move debian/"
[16:19] <slytherin> IntuitiveNipple: First question, do you really need .install?
[16:20] <IntuitiveNipple> slytherin: Yes, due to DKMS
[16:21] <IntuitiveNipple> I know dh_install takes the --exclude= option but I can't see a way to specify the same thing in the .install file
[16:21] <slytherin> IntuitiveNipple: I don't know what DKMS is. Anyway, I have to go home. You will probably get better help from other people.
[16:21] <slytherin> LucidFox: Going home. See you in an hour.
[16:22] <mario_limonciell> IntuitiveNipple, you can't use the --exclude in the .install file, this is correct
[16:23] <mario_limonciell> are there that many files in the root of the directory though that you can't just explicitly list them?
[16:24] <IntuitiveNipple> Yes, they're all in there, and it has sub-dirs, but I'm more concerned about if additional files are adding to the source in the future and are missed because they then need a specific .install rule
[16:25] <mario_limonciell> ah yeah i can see what you mean there
[16:26] <mario_limonciell> you are probably best off using dh_install in debian/rules then instead
[16:26] <mario_limonciell> and using it's exclude option
[16:26] <IntuitiveNipple> I'm seeing the glimmering of a solution. I know dh_install can take the --exclude= option, but this package is set to use CDBS so I'm currently looking at the variables in CDBS's debhelper.mk to figure out which needs setting to pass "--exclude=\"debian/*\""
[16:26] <mario_limonciell> well you don't need to set a variable, you can just explicitly use dh_install as a command in one of your sections
[16:26] <IntuitiveNipple> yay, looks like I've finally got on the right track if you think that too :)
[16:26] <mario_limonciell> even though it's cdbs
[16:27] <IntuitiveNipple> Really? I usually just set the CDBS variable to keep the rules simple :)
[16:27] <mario_limonciell> i did that with a package within the last few months
[16:27] <mario_limonciell> let me see what it was
[16:27] <mario_limonciell> but yeah i agree, when you can just use CDBS variables, that's preferable
[16:28] <IntuitiveNipple> aha... this looks like the one DEB_DH_INSTALL_ARGS
[16:28] <mario_limonciell> well if that doesn't work out, then you can add a rule to binary-install/$BINARY_PACKAGE::
[16:28] <IntuitiveNipple> Thanks... I'm sleep-deprived atm and spent most of the early hours getting the DKMS package to work (with everything in src/) and now want to correct it :)
[16:28] <mario_limonciell> where $BINARY_PACKAGE is the name of your binary deb
[16:29] <IntuitiveNipple> yeah... I've done that in the motion package
[16:29] <mario_limonciell> well now knowing that DEB_DH_INSTALL_ARGS exists though, i may change my package i guess
[16:29] <mario_limonciell> well we'll see, i also have some complicated rules for docs and init scripts though
[16:30] <IntuitiveNipple> Yeah... I was hunting high and low for a description of all the variable for CDBS, none are documented, so I finally figured out to simply read the /usr/share/cdbs/1/rules/debhelper.mk script - suddenly everything becomes possible using variables
[16:30] <IntuitiveNipple> All the CDBS calls to dh_* scripts provide variables to pas options, over-rides, etc.
[16:31] <IntuitiveNipple> This is my favourite from last night: DEB_INSTALL_MANPAGES_r5u870-kernel-source="debian/r5u870.8"
[16:32] <IntuitiveNipple> took me ages to figure out how to get CDBS to install man pages - it didn't do it automatically as I'd expected
[16:33] <mario_limonciell> oh geez
[16:33] <IntuitiveNipple> now, just got to hope specifying "--exclude=debian/" doesn't then block the .install rule debian/dkms.conf /usr/src/...
[16:33] <mario_limonciell> maybe next project then after you finish this package is to write some "Proper" documentation for CDBS :)
[16:39] <IntuitiveNipple> Damn... the exclude overrules the debian/dkms.conf rule!
[16:39] <IntuitiveNipple> mario_limonciell: I'm already doing a step-by-step wiki for the DKMS process including debianising the package, but yes, listing all the CDBS variables is also on my todo list of articles
[16:40] <IntuitiveNipple> OK... this looks like a case for your binary-install/$BINARY_PACKAGE::
[16:41] <mario_limonciell> yeah you can't win then all
[16:41] <DRebellion> Could somebody please review my package? http://revu.ubuntuwire.com/details.py?package=posterazor Thanks ;)
[16:44] <mario_limonciell> IntuitiveNipple, depending on the exact case, you can refer to http://linux.dell.com/git/?p=dkms.git;a=blob;f=debian/HOWTO.Debian;h=532e5b9d996e97d678eddfe807a79a746abcd6ba;hb=HEAD too
[16:48] <IntuitiveNipple> Yeah, I was looking at some of that last night for clues. I've based my current method off Ben Collin's UKS presentation earlier this month
[16:56] <mario_limonciell> ah
[16:57] <mario_limonciell> IntuitiveNipple, well if you'd like to work on making it more usable in any way, i'm very open to such changes
[16:57] <IntuitiveNipple> finally got it... for reference in the CDBS debian/rules I added:
[16:57] <IntuitiveNipple> binary-install/r5u870-kernel-source::
[16:57] <IntuitiveNipple> 	cp $(CURDIR)/debian/dkms.conf $(CURDIR)/debian/r5u870-kernel-source/usr/src/r5u870-0.11.1
[16:57] <mario_limonciell> ha.  well that works :)
[16:58] <IntuitiveNipple> mario_limonciell: This is my first exposure to DKMS, I decided to take the plunge in the deep end last night. My main grouch is that there is so little systematic howto documentation (especially for Ubuntu!) I'm remedying that atm :)
[16:59] <IntuitiveNipple> my only concern with that "cp" line is the fixed version in the destination... can't find a CDBS variable that contains the version!
[16:59] <mario_limonciell> right. okay well if you see anything that would be of benefit directly in the dkms package then, let me know
[16:59] <IntuitiveNipple> (or the package-version name)
[16:59] <mario_limonciell> oh there is a way to get the version
[16:59] <mario_limonciell> if you use dpkg-parsechangelog
[16:59] <IntuitiveNipple> ooo????
[17:00] <mario_limonciell> i do something like this
[17:00] <mario_limonciell> CVERSION := $(shell dpkg-parsechangelog | grep '^Version:' | cut -d' ' -f2 | cut -d- -f1 | cut -d\: -f2)
[17:00] <k0p> Hi all.
[17:02] <Iulian> Riddell: Did you upload it by yourself or should I ask a motu to upload it again?
[17:02] <IntuitiveNipple> ooo nice... and thanks!
[17:02] <Iulian> Riddell: Or you're allowed to upload and accept it in the same time since you're an archive admin?
[17:02] <k0p> Someone can review my package? http://revu.tauware.de/details.py?package=umit
[17:04] <IntuitiveNipple> mario_limonciell: thanks! I've changed it and it works nicely now:
[17:04] <mario_limonciell> great
[17:06] <IntuitiveNipple> Whilst I'm on a roll... anyone know of a script/easy way to manage changelogs to publish multiple releases (gutsy/hardy/intrepid) easily instead of my current method of manually editing the changelog to change the release for each debuild ?
[17:07] <IntuitiveNipple> I suppose I can just write a simple iterative shell script but...! :)
[17:22] <slytherin> LucidFox: ping
[17:23] <LucidFox> slytherin> including ant-vars.mk didn't produce any new output
[17:24] <LucidFox> What's more frustrating is that the stupid IOException doesn't even write what file is missing
[17:24] <slytherin> :-(
[17:27] <LucidFox> I suppose I _could_ set failonerror="false" for the javadoc...
[17:28] <slytherin> LucidFox: One last try. see if removing overview attribute helps.
[17:29] <slytherin> LucidFox: line 1019
[17:33] <LucidFox> but the overview.html file _is_ present there
[17:33] <LucidFox> why would it fail?
[17:34] <Jazzva> DRebellion, as far as I can see, you have one line longer than 80 chars in debian/copyright. Also, libxpm doesn't exist. I think you should use libxpm4, which exists. I still haven't tested the actual package, but it builded ok
[17:35] <slytherin> LucidFox: right, it is not going to help either
[17:35] <slytherin> LucidFox: Can you point me to you rlast build log?
[17:35] <DRebellion> Jazzva, thanks for the review. Yes, you're right about libxpm (I guess I must have just assumed it existed).
[17:36] <LucidFox> it's exactly the same as the second-to-last :)
[17:36] <LucidFox> slytherin> http://paste.ubuntu.com/29329/
[17:36] <Jazzva> DRebellion, no problem. I'll leave a comment, if you upload the fixed package. I'm not a MOTU, but I suppose it can help to the other MOTU reviewers :)
[17:37] <phaidros> hi. as I filed a bug/backport request for trac 0.11 I just want to drop notice, that the debian trac maintainers try to get trac-0.11.1 from the trac team before end of this week
[17:37] <DRebellion> Jazzva, I will upload a fixed package right away
[17:37] <Jazzva> DRebellion, cool. Let me just test the package with fixed dep.
[17:39] <DRebellion> Jazzva, ok, the package is uploaded
[17:39] <Jazzva> DRebellion, thanks
[17:39] <slytherin> LucidFox: I will be back in 15-20 minutes and debug this.
[17:46] <Jazzva> DRebellion, step 5 is a bit confusing. You save the file, and then it still shows grayed-out "Next" button. Maybe you can see with the upstream if they can work on that... To say, for example, "Finish" once file is saved. Beside that, this looks ok to me
[17:46] <DRebellion> Jazzva, great!
[17:49] <mrts> is there a ppa or just plain .debs of python 2.6 or 3.0 somewhere?
[17:50] <huats> does anyone here is used to tcl packaging ?
[17:56] <Jazzva> DRebellion, sorry. I'm in the uploaders.list file, but it's failing to log me in for some reason
[18:02] <Awsoonn> connect irc.gnome.org
[18:02] <Awsoonn> wrong window sorry :(
[18:02] <Jazzva> Hmm... any way to reset REVU password?
[18:03] <cody-somerville> Jazzva, yes, try logging in and it'll give you a link
[18:04] <Jazzva> cody-somerville, I opened recover link, but it says my account doesn't exist. Though, I'm listed in the uploaders.list
[18:04] <cody-somerville> Jazzva, are you using the e-mail address associated with your gpg key?
[18:04] <Jazzva> cody-somerville, yep
[18:04] <Jazzva> cody-somerville, this might explain it "If you don't create an Elgamal key, you will be able to upload to REVU but not to recover your password, and hence, to login on the web interface. "
[18:04] <cody-somerville> Jazzva, have you uploaded anything yet?
[18:05] <Jazzva> cody-somerville, on previous REVU...
[18:05] <cody-somerville> Jazzva, upload something and your account will be created
[18:06] <Jazzva> cody-somerville, thanks. I think that'll wait for a while, until I package something new...
[18:06] <cody-somerville> Jazzva, why do you want to login then?
[18:07] <Jazzva> cody-somerville, to post a review on one package... AFAIK, everyone can comment now, so I thought to make it easier for other MOTU reviewers...
[18:07] <cody-somerville> Right
[18:17] <slytherin> Jazzva: what do you mean by previous revu?
[18:18] <Jazzva> slytherin, the one that was reachable at revu.something.de. I forgot the actual link
[18:19] <slytherin> Jazzva: when did you do that. AFAIK, revu.tauware.de has been same as revu.ubuntuwire.com for some time now.
[18:21] <slytherin> LucidFox: why does in your case javadoc binary is from Sun jdk while tools.jar is being used from GCJ.
[18:21] <Jazzva> slytherin, it is possible that I forgot my password. That's why I'm asking if it's possible to reset it...
[18:21] <LucidFox> No idea, especially given that it's being built in pbuilder
[18:21] <slytherin> Jazzva: It is possible to retrive it. Not sure about resetting
[18:22] <LucidFox> Oh. Finally, a smart PHP developer.
[18:22] <slytherin> LucidFox: Let check if I get same problem.
[18:22] <LucidFox> "TRWTF is Smarty.  Why do we need a template language for PHP which is itself a template language?"
[18:22] <LucidFox> 'Maybe he means graphics designers? In my personal experience the vast majority of their expertise lies in using Dreamweaver and the like.' - 'My philosophy is "if you can't do html and css by hand, I am not working with you".'
[18:25] <slytherin> LucidFox: Found the problem. Check debian/ant.properties
[18:26] <LucidFox> *facepalm.jpg*
[18:26] <slytherin> LucidFox: So the problem was due to not finding javadoc binary in first place.
[18:27] <LucidFox> that explains why it built outsied of pbuilder
[18:28] <slytherin> LucidFox: that explains why most of the packages in Debain contrib arch:all packages do not build inside pbuilder. :-P
[18:28] <LucidFox> hehehehehehe
[18:29] <LucidFox> Would you like the honor of making the debdiff, or should I make the changes myself?
[18:29] <slytherin> LucidFox: I assume you can now fix it. Also please make sure you file a bug in Debian BTS.
[18:30] <LucidFox> okay, now building the package with the modified ant.properties
[18:30] <slytherin> LucidFox: Please go ahead, I have to look into another package.
[18:31] <LucidFox> At least I know _some_ Debian maintainers use pbuilder...
[18:31] <AnAnt> what's wrong with pbuilder ?
[18:32] <LucidFox> pbuilder is good, it's just frustrating when people upload packages _without_ testing them in pbuilder first
[18:32] <directhex> it's so much more prone to not working than a good ol' fashioned chroot
[18:32] <LucidFox> like the Debian maintainers for fop, evidently
[18:33] <directhex> so use a chroot! much less work!
[18:33] <slytherin> LucidFox: Yes but it seems most of the packages in contrib are not tested in pbuilder
[18:33] <directhex> note: packages may be buggered. this is a minor side-effect
[18:33] <smagoun> I'd like to diff a pair of Package.[gz|bz2] files, is there a good tool for that? I need to compare the list of packages + package versions in each archive (e.g. what changed between a snapshot of hardy-security from 2 weeks ago and a snapshot made today?)
[18:33] <directhex> smagoun, zdiff?
[18:34] <slytherin> smagoun: I think diff -ruN should do, but I guess you will have to extract the packages first
[18:34] <LucidFox> directhex> Unless you want to manually delete dependencies after every build
[18:34]  * sistpoty|work heads home... cyas
[18:34] <sistpoty|work> -s
[18:34] <directhex> LucidFox, ffffft, sounds like hard work. i'm sure it'll be fine without!
[18:34] <smagoun> directhex: Thanks. I'm looking for something that will filter the list of package names/versions; I could use diff but I'd have to filter the output. I assumed there was already a tool for that.
[18:35] <LucidFox> directhex> Ah, it's sarcasm :)
[18:35] <slytherin> directhex: and there is no guarantee that some package left from previous build will not interfere with new build
[18:35] <directhex> LucidFox, better than that, it's the fabled dry wit of the british!
[18:44] <DRebellion> Jazzva, no worries.
[18:47] <slytherin> tuxmaniac: electric compiles with openjdk but not with GCJ.
[18:54] <LucidFox> slytherin> uploaded fop
[18:55] <slytherin> LucidFox: And it will be built for first time in Ubuntu. I can't wait to use fop in Ubuntu for docbook -> PDF conversion. :-)
[18:57] <LucidFox> I can't wait to use fop with my homebrew semantic XML :)
[18:57] <k0p> cody-somerville, are you there?
[18:57] <cody-somerville> k0p, yes
[18:57] <slytherin> LucidFox: By the way I think you should have kept build depend on Sun JDK for batik. That way it would have been 'no second thought backport' request if someone wanted it.
[18:58] <LucidFox> it can still be backported to hardy as is
[18:58] <LucidFox> well, almost as is
[18:58] <LucidFox> since xml-commons-external should be backported first
[18:58] <k0p> cody-somerville, I fixed your reported issues. I make a comment. can you take a look? http://revu.tauware.de/details.py?package=umit
[19:00] <slytherin> LucidFox: well provided openjdk in hardy contains all those com.sun.* apis
[19:00] <LucidFox> it does
[19:01] <slytherin> oh, then it's ok
[19:02] <slytherin> LucidFox: I just checked changelog for fop. I thought you removed javahome from ant.properties. But never mind. :-)
[19:02] <cody-somerville> k0p, is umitWeb in Ubuntu already?
[19:02] <slytherin> siretart: FYI ... fop is fixed now.
[19:03] <LucidFox> well, it still has to pass NEW
[19:03] <slytherin> geser: Is it too late to add fop to team report. :-D
[19:03] <k0p> cody-somerville, not yet. But soon it will be
[19:04] <cody-somerville> k0p, and it doesn't ship core itself?
[19:04] <siretart> slytherin: w00t! :)
[19:04] <k0p> cody-somerville, hmm it use umitCore
[19:05] <k0p> it = umitWeb
[19:05] <slytherin> I wonder where persia is.
[19:06] <cody-somerville> k0p, yes but I'm wondering why this application is shipping something that is shared
[19:06]  * persia is hiding
[19:07] <k0p> cody-somerville, shiping?
[19:08] <k0p> well umit web is a web interface of umit. umitCore have Nmap output Parsing, wrapper lib etc.
[19:09] <slytherin> persia: where have you been for last 2 days?
[19:10] <persia> slytherin: My computer is overheating badly.  I've added new ambient fans, and cleaned it some, so it now doesn't crash every half hour (which is an improvement).  With luck, I'll be around from now.
[19:11] <slytherin> persia: wow, and I thought only my dad's laptop had heating problem
[19:11] <laga> persia: pentium D? ;)
[19:12] <persia> slytherin: Well, the computer is usually fine.  It's just when ambient is sustained above 30 that I have an issue.  As likely to be a problem with the larger environment than the machine itself (although a good dusting always helps).
[19:13] <slytherin> persia: my dad's laptop crashed due to overheating while gutsy -> hardy upgrade when scrollkeeper started rebuilding database. :-(
[19:13] <slytherin> I had to comment rebuilding part from postinst file
[19:13] <persia> Oh my.
[19:16] <Awsoonn> is there a wiki on making an intrepid chroot?
[19:16] <slytherin> persia: by the way, how is team report used every month?
[19:17] <slytherin> Awsoonn: sudo apt-get install pbuilder, cp /etc/pbuilderrc ~/.pbuilderrc, edit ~/.pbuilderrc and change hardy to intrepid, sudo pbuilder --create
[19:17] <Awsoonn> slytherin: ah, I thought pbuilder was only for building pacakages :o thanks
[19:17] <cody-somerville> k0p, how many applications use umitCore?
[19:18] <cody-somerville> k0p, or only will these two programs use it?
[19:18] <slytherin> Awsoonn: wait a minute, when you said chroot, what was the purpose?
[19:18] <persia> slytherin: It's published for everyone to see, so people can get an overview of what all the teams are doing.  See https://wiki.ubuntu.com/TeamReports for more information
[19:19] <slytherin> persia: wow, they are still creating june report
[19:19]  * persia just fixed that
[19:19] <Awsoonn> slytherin: I want to check if a bug has been fixed in the intrepid version of Rhythmbox
[19:20] <Awsoonn> if it's not fixed, I want to chew on it for a while
[19:20] <slytherin> Awsoonn: ahh, for that you will need to use some virtualisation software. Search wiki.ubuntu.com for kvm or virtualbox
[19:22] <Awsoonn> in that case, is there a way to make an existing vbox drive bigger without reinstalling into a newer larger one tha yau know of?
[19:22] <k0p> cody-somerville, hmm right now only two application use it
[19:22] <k0p> but quickscan will use it too.
[19:22] <slytherin> Awsoonn: I am not aware of it. I haven't used virtualbox much
[19:22] <k0p> cody-somerville, do you suggest make only one package?
[19:22] <cody-somerville> k0p, so its general purpose?
[19:23] <k0p> cody-somerville, yeah
[19:24] <cody-somerville> k0p, so why is this application you're trying to get into Ubuntu include both in the tarball?
[19:24] <cody-somerville> k0p, do the other applcations, will they ship umitcore in their tarballs as well?
[19:24] <slytherin> should dpatch go in build-depends-indep or build-depends?
[19:24] <Awsoonn> so while working on this bug I will have to work inside virtual box essentialy?
[19:25] <k0p> cody-somerville, yeap..
[19:25] <persia> slytherin: dpatch should go in build-depends: you need it to clean the source.
[19:25] <cody-somerville> k0p, are they modifying umitcore?
[19:25] <cody-somerville> k0p, why don't they just declare a dependency on umitcore instead?
[19:25] <k0p> are you suggest make umitCore other tarball?
[19:26] <slytherin> persia: ok. I guess I will not need dpatch. simple-patchsys should be enough and I already have cdbs in build-depends
[19:26] <k0p> cody-somerville, wait a second,
[19:27] <k0p> cody-somerville, in umitWeb - umitCore have modifications
[19:27]  * cody-somerville facepalms.
[19:28] <k0p> yeap
[19:28] <k0p> lol
[19:28] <k0p> cody-somerville, well i'll make a merge again of the package
[19:28] <k0p> it will have only one :)
[19:28] <k0p> cody-somerville, it's better, no?
[19:28] <cody-somerville> k0p, you're upstream, right?
[19:29] <k0p> cody-somerville, yeap
[19:29] <DRebellion> Jazzva, no worries.
[19:29] <DRebellion> oops
[19:30] <DRebellion> :P
[19:31] <cody-somerville> k0p, If umitcore is a package that other applications can use, you might want to release it a product exclusive to your applications that make use of it
[19:31] <cody-somerville> k0p, then instead of having those applications bundle it in their tarball, they just say "hey, I depend on umitcore".
[19:32] <k0p> cody-somerville, yeah I understand your view point
[19:33] <k0p> i'm talking with authors right now
[19:33] <k0p> authors of the core.
[19:36] <k0p> cody-somerville, if other application depends of umitcore means that we have a separate tarball to umitcore?
[19:38] <cody-somerville> k0p, If I understand your question correctly, then yes, I believe that would be a good idea
[19:39] <k0p> cody-somerville, yeap. But authors of umit don't have receptive to it.
[19:40] <k0p> do only one package looks fine? umitWeb use a patched core..
[19:40] <k0p> have only one package looks fine cody-somerville ?
[19:40] <cody-somerville> Are there plans/potential for other applications to use the umitcore?
[19:41] <k0p> cody-somerville, yeah it's our plans. but not right now. our lib it's not sufficient generic, yet.
[19:45] <k0p> cody-somerville, may be in the future umitcore should be generic. can I make only only one package? and what do you mean about put the py files on /usr/share/umit? looks fine?
[19:47] <cody-somerville> When did I say something about putting py files on /usr/share/umit?
[19:48] <k0p> cody-somerville, well .. I'm reading debian policys and see other packages .. and it puting py files on /usr/share/<app name>
[19:48] <cody-somerville> k0p, and where are you currently putting yours?
[19:49] <k0p> /usr/share/umit
[19:50] <cody-somerville> and what is your question again?
[19:50] <k0p> cody-somerville, is it fine?
[19:52] <k0p> cody-somerville, the question is: can I put the files on /usr/share/umit?
[19:53] <cody-somerville> where else were you thinking of putting them?
[19:55] <k0p> no idea. following python policy I can't put it in the /usr/lib/python-X.Y/site-packages
[19:56] <k0p> cody-somerville, i'm merging packages and I'll sent  to revu, wait a minute :)
[20:01] <slytherin> k0p: you need not send a merge to revu. Please file a bug instead and attach debdiff.
[20:03] <cody-somerville> slytherin, he means he is updating his package to only produce one binary package
[20:04] <slytherin> cody-somerville: oh
[20:04] <emgent> heya
[20:06] <k0p> yeap
[20:07] <k0p> arggg
[20:17] <k0p> some trouble uploading ..hmm
[20:18] <k0p> cody-somerville, done. can you check now?
[20:27] <slytherin> is it possible to upload just .diff.gz to ppa and let it use orig.tar.gz from repos?
[20:28] <DktrKranz> slytherin, that's the preferred behaviour
[20:28] <DktrKranz> given that .orig.tar.gz is already available in the archives
[20:29] <slytherin> DktrKranz: how to do it? I mean I always to debuild -S -sa and then dput
[20:29] <DktrKranz> slytherin, just debuild -S
[20:29] <DktrKranz> for new upstream, -sa is necessary
[20:29] <slytherin> DktrKranz: Ok. I will try tomorrow.
[20:29] <DktrKranz> but if you push a new revision, -sa only waste bandwith :)
[20:32] <slytherin> DktrKranz: right, that is what I wanted to avoid. I am trying to rebuild lucene2 with small changes and it's unit tests eat my CPU for half hours or so.
[20:32] <slytherin> So I thought I would upload changes to PPA
[20:32] <DktrKranz> just use -S and enjoy your accepted mail :)
[20:41] <norsetto> DktrKranz: Was your last email abount mentoring a resend? I'm wondering since only nxvl and me are addressed.
[20:42] <DktrKranz> norsetto, not really... thunderbird was hungry and ate mike's address ;)
[20:43] <norsetto> DktrKranz: thunderbird!? get clawsmail, get real :-)
[20:43] <DktrKranz> norsetto, don't tell a.sac ;)
[20:44] <norsetto> asac: I'm not telling you that clawsmail is for real men and thunderbird is for sissies
[20:44] <asac> hehe
[20:44] <DktrKranz> gah... I didn't want to ping asac, and you did, man you're dead :)
[20:44] <asac> cant tell ... i dont dont receive mail anyway ;)
[20:45] <norsetto> lol
[20:45] <DktrKranz> norsetto, get real, use telnet
[20:45] <norsetto> DktrKranz: I use sendmail actually ...
[20:46] <DktrKranz> me use pigeons
[20:46] <slytherin> mail is so 90s. Use identi.ca :-P
[20:46] <persia> norsetto: You use sendmail as your MUA?
[20:46] <norsetto> DktrKranz: or even better sendemail, sending emails with a perl script (the dream of all spammers)
[20:46] <norsetto> persia: no, just kidding, I use kmail
[20:47] <persia> Right.  /usr/lib/sendmail is awkward for reading messages.
[20:50] <norsetto> persia: I actually used mail on my unix machines, so LONG ago that I don't even remember it anymore
[20:53]  * norsetto is trying hard to remember what he used on the Vax 50
[20:54] <RoAkSoAx> hey guys, one question, when packaging from scratch, XSBC-Original-Maintainer is the one who packages it, or the app creator?
[20:56] <persia> RoAkSoAx: It is the person who creates the original packaging.
[20:56] <RoAkSoAx> persia, so if i'm packaging it... it would be me right? :)
[20:57] <persia> Note that this is not always the person who is handling the REVU processing, but ideally the Original Maintainer is willing to provide expertise (if not support) for the package,
[20:57] <persia> RoAkSoAx: If you are packaging it, yes, most likely you.  Exceptions would be for something already packaged in e.g. a MEPIS unoffical repo that was being repackaged for Ubuntu.
[20:59] <RoAkSoAx> ok, cool thanks persia :)
[21:00] <slytherin> something related to what RoAkSoAx asked. If I am updating a package in Ubutnu to latest version but the version is not available in Debian what should be original maintainer
[21:00] <persia> slytherin: That's a hard one.  I've usually seen the Debian maintainer listed, but I'm not sure that is correct.
[21:01] <slytherin> persia: so what do you suggest?
[21:02] <persia> slytherin: Discussing the version bump with the Debian maintainer :)  Even if the new version is not appropriate for lenny, they may be willing to be Original-Maintainer, or may wish not to be the Original Maintainer.
[21:03] <slytherin> persia: the package has been orphaned in Debian. And it has moved from C to Java. So the packaging is almost like new since I am changing it from debhelper to CDBS. :-)
[21:04] <persia> slytherin: Have you considered filing an ITO in Debian?  It sounds like you should be the O-M because you should be the D-M.
[21:04] <persia> s/ITO/ITA/
[21:04] <slytherin> persia: no, as I have no intention to maintain packages in Debian. I don't use Debian.
[21:05] <norsetto> persia: I think its only fair to keep the DM/DD as Original-Maintainer (as keeping hom as the original packager in debian/copyright), you are basing your backage on his work after all
[21:05] <Laibsch> Hi, I am pushing a number of packages into debian.  The ultimate goal is for me to use them on Ubuntu
[21:06] <Laibsch> Since I am Debian maintainer (sponsored), can I request stuff to be pushed into hardy?
[21:06] <persia> norsetto: In the general case, I agree, although I encourage communication, in case there was some issue that blocked the update, etc.
[21:06] <norsetto> persia: got you email btw, thx
[21:07] <persia> slytherin: For Orphaned packages, we try to support Debian, even where we don't use it directly.  Especially for a package that has transitioned to Java, where we are building greater collaborative links.
[21:09] <slytherin> persia: I will add comment to the bug saying the package has been updated. But for me it just doesn't feel right accepting responsibility of maintenance when I know I can't handle it.
[21:10] <persia> slytherin: That's different.  If you were confident, I'd keep pushing you to maintain it in Debian.  If you aren't, perhaps this one can go by, but please do at least inform Debian QA of the update, and ask for review.
[21:10] <persia> (and maybe also worth informing some of the Debian Java Maintainers, in case they wish to adopt it).
[21:11] <slytherin> persia: I will surely do that, as I have done in case of batik.
[21:11] <persia> slytherin: Thanks.
[21:12] <slytherin> persia: The question remained unanswered, who is original-maintainer
[21:13] <norsetto> slytherin: if you have completely changed the packaging, it would be you
[21:13] <persia> slytherin: In this case, you, as you'll be the expert on the packaging.
[21:13] <slytherin> norsetto: of course packaging had to change since it is now a java app. And I feel cdbs is easy to use when it comes to java apps/libs
[21:14] <norsetto> slytherin: you could have tried debhelper 7, seems to be neat
[21:15] <slytherin> norsetto: Will try with some other app. This one has been pending for long time. tuxmaniac was specifically interested in the update as he is member of motu-science.
[21:16] <slytherin> By the way, when is next motu-council meeting?
[21:17] <persia> slytherin: All MOTU Council actions take place on the mailing list (or on IRC).  Was there some specific issue?
[21:18] <slytherin> persia: yes, I am planning to apply for motu-contributors membership. :-D
[21:18] <slytherin> persia: I am assuming I am ready, if you feel otherwise please let me know.
[21:18] <Legendario> hi, i am having an error to build a package with pbuilder. Can anyone help me to find out what it is? http://pastebin.ubuntu.com/29391/
[21:19] <norsetto> Legendario: looks like you could be missing a build-dep
[21:19] <persia> slytherin: No need to wait for a meeting.  Just collect a couple of your sponsors, and send an email to the MC list with your application.
[21:20] <Legendario> norsetto, can u tell me which one?
[21:20] <norsetto> Legendario: my psychic powers are not that developed I'm afraid
[21:20] <slytherin> persia: sponsors are you, geser and LucidFox
[21:20] <persia> slytherin: Works.
[21:21] <slytherin> persia: I will probably do it after our Thursday meeting
[21:21] <huats> norsetto !
[21:21] <huats> :)
[21:21] <norsetto> Legendario: perhaps its just an header problem, check where those symbols are defined
[21:21] <Legendario> norsetto, sorry, but i thought you could tell me by de error output
[21:21] <norsetto> huats: argh!!!! norsetto-huats: 2-2, ball back to the center
[21:21] <huats> :)
[21:23] <Legendario> norsetto, which symbols?
[21:24] <norsetto> Legendario: the weed_ stuff
[21:26] <Legendario> norsetto, i have no idea. I don't understand a thing about coding and i am just begginning to package...
[21:27] <norsetto> Legendario: library packaging is not really ideal for beginners, I see for instance that you are not setting the soname
[21:28] <norsetto> Legendario: and it looks like you are using the same library for linking as the one you are building
[21:28] <Legendario> norsetto, that's why i am here. Cause i want to learn. What am I supposed to do?
[21:29] <Legendario> i believe that's something from the upstream
[21:29] <norsetto> Legendario: try to start with something simpler ;-)
[21:30] <huats> norsetto: regarding your comments in http://revu.ubuntuwire.com/details.py?package=tktreectrl
[21:30] <huats> regarding point 5) and 6)
[21:30] <huats> I am a bit unease
[21:30] <huats> I have not seen anything like that with the other tcl package I have seen so far...
[21:31] <Legendario> well, i have been successful on packaging this one before. But i am correcting my mistakes and updating the source.
[21:31] <huats> can we speak about that N
[21:31] <huats> ?
[21:31] <Legendario> i've got this error on this new source.
[21:31] <norsetto> huats: what is the problem ?
[21:32] <huats> norsetto: I have not seen a -dbg on the other tcl package lib  I have seen...
[21:32] <huats> (that was point 5))
[21:32] <huats> and the 6) I am not sure that the dh_call is needed for tcl libs...
[21:32] <huats> (but I might be wrong again)
[21:33] <norsetto> huats: is the package not producing a shared library?
[21:34] <huats> norsetto: I don't know if we can speak of shared library for tcl packages....
[21:34] <persia> Every tcl package is a shared library :)
[21:35] <huats> persia: ok :)
[21:35] <huats> (as I said earlier I don't know a lot of stuffs in tcl...)
[21:35] <norsetto> huats: the only thing I know about tcl is that its called tcl, so, you know more than I do
[21:35] <huats> :)
[21:35] <huats> persia: you seems to know about it :)
[21:38] <persia> huats: I only know that it's interpreted text, and that any given script can import another.
[21:38] <huats> ok
[21:38] <huats> persia: have you ever packaged some ?
[21:38] <persia> huats: Nope.
[21:38] <huats> does anyody have package some tcl stuffs ?
[21:38]  * persia has only packaged one package: a shared library in C
[21:38] <huats> persia: ok, thanks
[21:38] <huats> :)
[21:39] <huats> persia: I am packaging a tcl lib right now... and norsetto asked me to put a -dbg package which I am not sure is adapted to tcl...
[21:40] <huats> But since I cannot find someone who is used to package tcl is not a good answer :)
[21:40] <persia> huats: Are you packaging bindings, or pure tcl?
[21:40] <huats> pure tcl
[21:40] <huats> which produces a .so file ...
[21:40] <norsetto> huats: I assumed your package was providing a shared library, now, you are telling me its a tcl library, and I know zilch about tcl
[21:40] <huats> :)
[21:40] <huats> well at least I tend to think it is pure tcl :)
[21:40] <huats> let me figure that out...
[21:41]  * persia is confused as to how tcl produces a .so file, but does believe that a .so file ought have debugging symbols somewhere
[21:41] <emgent> Hey hey hey
[21:41] <huats> it might
[21:41] <norsetto> huats: check this out: http://pkg-tcltk.alioth.debian.org/tcltk-policy.html
[21:41] <huats> norsetto: don't worry I'll have an answer...
[21:41] <nhandler> Hi emgent
[21:41] <huats> norsetto: hum sounds interesting
[21:42] <emgent> persia: Emanuele Gentili    2007-11-13 21:32:08 CET  2007-11-13    2008-10-08 12:49:57 CEST  2008-10-08   Approved
[21:42] <huats> btw the license is good (I asked pitti, as a archive admin) and elmo confirms
[21:42] <emgent> (ubuntu-universe-sponsor)
[21:42] <emgent> persia: why active since 2007-11-13 ?
[21:42] <norsetto> huats: if the package provides a shared library ( a .so) than yes, I don't see why we could not provide a -dbg package as well as use the shlibs system
[21:43]  * emgent hugs *another launchpad bug*
[21:43] <emgent> persia: some idea about it ?
[21:44]  * persia finds it difficult to find the answer and also express the answer simultaneously, and counsels patience.
[21:44] <emgent> hehehe, sorry :)
[21:46] <Syntux> do we have an RSS feed of New and Triaged bugs?
[21:47] <persia> Syntux: You might ask in #ubuntu-bugs, as people there are more likely to have a good answer.
[21:48] <Syntux> Sure.
[21:49] <persia> emgent: You've found a bug.  That's the date you were first rejected from joining the team.
[21:49] <persia> emgent: Please report it :)
[21:50] <emgent> lol will do.
[21:50] <emgent> :)
[21:52] <slytherin> Can anyone help with this error - http://paste.ubuntu.com/29401/
[21:52]  * norsetto goes to take his lenses finally out
[21:54] <nhandler> Is there any way to change my REVU email address without having to upload a new package?
[21:56] <cody-somerville> nhandler, why would you want to?
[21:58] <Iulian> cody-somerville: Hi there. I was wondering if everything is ok with salasaga now. Can you please have a look at it when you have some spare time?
[21:58] <cody-somerville> k0p, your package doesn't comply with python policy. You said that you read it so maybe you're not understanding it?
[21:58] <nhandler> cody-somerville, I made an account a while ago with an old email address. I was going to try and post feedback on some other uploads, and I wanted to use my new @ubuntu.com email address. But I forgot that I can only comment on packages that I've uploaded.
[21:58] <cody-somerville> Iulian, link?
[21:58] <Iulian> cody-somerville: http://revu.ubuntuwire.com/details.py?package=salasaga
[22:00] <cody-somerville> Iulian, the man page isn't very descriptive.
[22:01] <cody-somerville> Iulian, also, what about the recommends on metacity?
[22:01] <Iulian> cody-somerville: Well, there isn't much what to talk about.
[22:01] <Iulian> cody-somerville: I think I added it, didn't I?
[22:02] <cody-somerville> Iulian, no
[22:02] <slytherin> Can anyone help with the error - http://paste.ubuntu.com/29401/
[22:02] <Iulian> cody-somerville: Recommends: metacity
[22:03] <cody-somerville> wow.
[22:03] <cody-somerville> I'm blind
[22:04] <Iulian> Hehe ;)
[22:05] <norsetto> slytherin: what could dh_installdocs be telling you?
[22:06] <slytherin> norsetto: I am not able to understand why it is looking for README when I have specified to use README.txt
[22:16] <cody-somerville> slytherin, what have you tried to fix it?
[22:16] <slytherin> cody-somerville: let me paste rules file
[22:17] <slytherin> cody-somerville: http://paste.ubuntu.com/29405/
[22:19] <Iulian> cody-somerville: Well, the man page is indeed not very descriptive and unfortunately there is no documentation about it. I will have to email the upstream to give me more details about.
[22:19] <cody-somerville> Iulian, its okay. I'll advocate.
[22:22] <Iulian> cody-somerville: I have another advocate, yours will be the second. Do you want to upload it or should I talk to someone else?
[22:22] <cody-somerville> Iulian, your package currently only has one advocate.
[22:22] <cody-somerville> err..
[22:22] <cody-somerville> no
[22:25] <norsetto> slytherin: do you have a README in your docs?
[22:26] <slytherin> norsetto: no, there is only README.txt
[22:26] <norsetto> slytherin: in your debian/docs?
[22:26] <slytherin> norsetto: I dont' understand. Is it not referring to upstream readme file?
[22:27] <norsetto> slytherin: do you have a file called docs in your debian directory? or something.docs?
[22:27] <slytherin> let me check
[22:28] <slytherin> norsetto: yes I have. I have to correct the names in that file right?
[22:28] <norsetto> slytherin: right ...
[22:34] <norsetto> slytherin: several debhelper scripts use files in debian/ to know what they have to do, like dh_installdocs is looking for <package>.docs and dh_install is looking for <package>.install and dh_installdirs is looking for <package>.dirs etc.
[22:35] <slytherin> norsetto: I knew that. But it didn't occur to me that was root cause. :-(
[22:41] <slytherin> norsetto: thanks for hint by the way
[22:43] <norsetto> thats called thanks and go and is considered a capital offense in many countries :-)
[22:52] <Riddell> Iulian: it's uploaded
[22:52] <Iulian> Riddell: Yes, I saw, thanks.
[22:53] <cody-somerville> Whats uploaded?
[22:53] <Iulian> cody-somerville: It's not salasaga.
[22:53] <Laibsch> Hi, I am pushing a number of packages into debian.  The ultimate goal is for me to use them on Ubuntu
[22:53] <Laibsch> Since I am Debian maintainer (sponsored), can I request stuff to be pushed into hardy?
[22:54] <norsetto> Laibsch: for hardy its too late
[22:54] <cody-somerville> unless they're really cool
[22:54] <cody-somerville> :P
[22:54] <RainCT> heh
[22:54] <Laibsch> They are ;-)
[22:54] <norsetto> Laibsch: but if you get them in Intrepid you can always try asking for a backport
[22:54] <RainCT> *** cody-somerville is almighty   :P
[22:55] <Laibsch> Well, one of them is already in Intrepid
[22:55] <Laibsch> But I think an older version is already in hardy
[22:55] <Laibsch> -> pastebinit
[22:55] <Laibsch> The other one is gourmet, a recipe collection manager
[22:55] <cody-somerville> Laibsch, same names as in Ubuntu?
[22:55] <Laibsch> both python, so nothing should break severely
[22:55] <Laibsch> cody-somerville: ?
[22:56] <cody-somerville> Laibsch, do they have the same names in debian as in ubuntu?
[22:56] <Laibsch> yes
[22:56] <Laibsch> gourmet is not yet in debian
[22:56] <Laibsch> http://packages.debian.org/search?keywords=pastebinit
[22:56] <cody-somerville> Laibsch, so file a bug against the ubuntu package to have them synced.
[22:56] <Laibsch> http://packages.ubuntu.com/search?keywords=pastebinit
[22:57] <Laibsch> I think pastebinit is already in Intrepid
[22:57] <norsetto> !pastebinit
[22:57] <cody-somerville> !info pastebinit
[22:57]  * jpds gives norsetto a "!info"
[22:57] <norsetto> ubottu: want a punch in the face?
[22:57] <jpds> Hear hear.
[22:58] <norsetto> jpds: btw, what about your mentees? Its a long time I don't see them around.
[22:58] <Iulian> cody-somerville: About the comment, the original was a .bz2 archive. That's why the md5sum mismatch.
[22:58] <Laibsch> I think there is no urgent need to upgrade version 0.9 to 0.10 in hardy
[22:59] <Laibsch> But once gourmet hits debian and then eventually Intrepid, I'd like to see it in hardy, too.  What is the normal course of action, then?  Come here and schmooze up to cody-somerville? ;-)
[22:59] <cody-somerville> Iulian, thats no excuse.
[22:59] <emgent> NCommander: o/
[22:59] <jpds> norsetto: I now mentor others.
[22:59] <emgent> heya people.
[22:59] <RainCT> Laibsch: you can't get it into Hardy, except as a backport
[22:59] <NCommander> emgent, ?
[22:59] <emgent> s/NCommander/norsetto/
[22:59] <norsetto> jpds: you mean they dropped? You could have informed the reception
[23:00] <emgent> wrong TAB
[23:00] <jpds> norsetto: not dropped. More.. disappeared.
[23:00]  * NCommander wishes his sponsor would ping reply
[23:01] <norsetto> emgent: Ave oh master of the window managers
[23:01] <cody-somerville> NCommander, who is your sponsor?
[23:01] <NCommander> I perfer not to say just because I don't want to start a rumor
[23:01] <Iulian> cody-somerville: What do you mean?
[23:02]  * Iulian is pretty confused.
[23:02] <norsetto> jpds: well, whatever, should I remove you from the mentor's list? I have no idea what you are doing at the moment
[23:02] <cody-somerville> Iulian, bunzip2 followed by a gzip -9 will result in a .tar.gz with a matching md5sum
[23:02] <cody-somerville> NCommander, :S Is this for Debian?
[23:02] <jpds> norsetto: I'm mentoring others in my spare time.
[23:03] <norsetto> jpds: you can mentor all the people you want, but if you are not available for the reception just let us know
[23:03] <jpds> norsetto: OK, will do.
[23:04] <emgent> norsetto: -.-
[23:04] <norsetto> jpds: thx
[23:04] <norsetto> emgent: you should really do something for your eyesight
[23:05] <emgent> norsetto: hehe
[23:07]  * NCommander is now in ubuntu-bugcontrol
[23:07] <NCommander> w00t
[23:08] <nhandler> Congrats NCommander
[23:08] <NCommander> My bragging rights on LP keep growing
[23:09]  * nhandler has been thinking about applying for ubuntu-bugcontrol
[23:11] <NCommander> woo
[23:12] <NCommander> codeblocks got rejected!
[23:13] <NCommander> cody-somerville, ping
[23:14] <Iulian> cody-somerville: Hmm, it seems that it still not matching, I did run bunzip2 and then gzip -9 but when I check it mismatch. Am I missing something?
[23:19] <cody-somerville> Iulian, only the .tar have to match
[23:26] <NCommander> Hey cody-somerville, codeblocks got rejected, care to help me upload one tha twon't
[23:26] <NCommander> (wrong original maintainer, and lintian override were the reasons)
[23:27] <cody-somerville> what did you put as the original maintainer?
[23:28] <NCommander> I left upstreams debian maintainer by mistake
[23:28] <cody-somerville> Right
[23:28] <NCommander> (the one that was in the codeblocks/debian folder)
[23:28] <cody-somerville> Okay, I'll remove that
[23:29] <Iulian> cody-somerville: Have a look at http://paste.ubuntu.com/29419/
[23:29] <Iulian> Hmm, it's late here and I should go to bed.
[23:30] <Iulian> cody-somerville: Is it me or is the archive dizzy? ;)
[23:31] <cody-somerville> Iulian, the md5sum of the .orig.tar (so gzip -d it) and the .tar of the upstream tarball (so bunzip it) should match
[23:35] <cody-somerville> NCommander, so what did the archive admin say about the lintian override?
[23:35] <NCommander> cody-somerville, just comment why it is needed
[23:35] <Iulian> cody-somerville: b8ce4dc236c886b265baff4368b76897  salasaga_0.8.0~alpha3.orig.tar
[23:35] <Iulian> 40f76b604c441d0db4f8af0999007813  salasaga-0.8.0.alpha3.tar
[23:36] <cody-somerville> Iulian, I'm well aware yours doesn't match :P
[23:37] <cody-somerville> 40f76b604c441d0db4f8af0999007813 is the correct md5sum
[23:37] <Iulian> Yup..
[23:39] <Iulian> Every time it gives me something else and I'm using only those two commands.
[23:39] <Iulian> cody-somerville: Maybe because I'm asleep. Will try again tomorrow morning.
[23:40] <Iulian> cody-somerville: Thanks
[23:40] <Iulian> Good night.
[23:40] <cody-somerville> Night
[23:53] <coppro> query: I have a source package with libraries for C++, Python, and TCL. What's the best way to package the docs?
[23:53] <coppro> One package? If so, what should I call it?
[23:55] <Awsoonn> Can anyone tell me if  8.10 wil release with the nice new black theme?
[23:55] <Jazzva> Awsoonn, as far as I've seen, it's gonna be darker, but not black...
[23:57] <Awsoonn> Jazzva: the alpha has a new theme, and  Ilike it very much, but will it stay? or is it temporary?  I ask because the Web-team is about to design the new start page and count down banners.... and we'd like them to match the OS
[23:57] <Awsoonn> :)
[23:58] <Jazzva> Awsoonn, I'm not sure. I suppose I know as much as you do...
[23:58] <Jazzva> Awsoonn, I suppose it will look similar to that one... But that's just my guess...
[23:58] <nhandler> Well, we are still in the alpha stages. The Artwork final deadline is not until September 25th. Up until that point, the theme can be changed
[23:59] <Awsoonn> Might you know where I can find more information on 'intentions'
[23:59] <Jazzva> Awsoonn, #ubuntu-artwork maybe?