[00:02] <ScottK> sistpoty: Go for it if you haven't already.
[00:03] <sistpoty> ScottK: ok, though I'm a little bit drunk right now, and am fiddling with the upstream version number name
[00:03] <ScottK> Maybe tomorrow then.
[00:03] <sistpoty> ScottK: in case you'd like to jump in I'd be more than happy
[00:03] <ScottK> Sorry, I've got kids to deal with tonight.
[00:04] <sistpoty> sure... then I hope to get it sorted out asap
[00:05] <sistpoty> ScottK: any objections against 1.3.0~RC1is1.2.0-2ubuntu2 ?
[00:05] <ScottK> sistpoty: Normally we put the really bit in there, but if you prefer that, I don't object.
[00:06] <sistpoty> ScottK: as in 1.3.0~RC1isreally1.2.0-2ubuntu2 ? or s.th else?
[00:07] <ScottK> Without the is
[00:07] <ScottK> 1.3.0~RC1really1.2.0-2ubuntu2
[00:07] <ScottK> Gotta run.
[00:08] <sistpoty> ScottK: hm... ok, sure... (just wondered if svn would sort later... then recalled the alphabet *g*)
[00:08] <sistpoty> cya ScottK
[00:08] <ScottK> Good point, but they use Git anyway I think.
[00:20] <sistpoty> ScottK: uploaded :)
[00:20] <sistpoty> and now, I'll got to bed.. gn8 everyone
[00:23] <lukehasnoname> Could someone link me or tell me the process of getting a package into hardy-updates?
[00:23] <directhex> updates?
[00:24] <directhex> what's your reasoning? why does it need to go into -updates ?
[00:24] <Adri2000> lukehasnoname: https://wiki.ubuntu.com/StableReleaseUpdates
[00:26] <lukehasnoname> Just a higher version, bug fixes, nothing too critical on one package. Is Hardy's procedure different than non-LTS, or is it the same?
[00:27] <ricardo> opencv-dev depends opencvaux-dev. But opencvaux-dev depends opencv-dev. I'm using Ubuntu Gutsy, how solve this?
[00:29] <directhex> lukehasnoname, the newer version is in intrepid?
[00:30] <lukehasnoname> both cases, yes
[00:31] <Adri2000> lukehasnoname: the sru procedure is the same for all stable releases
[00:32] <lukehasnoname> Adri2000: k
[00:33] <directhex> ricardo, libcv and libcvaux?
[00:33] <Adri2000> ricardo: it seems these packages have different names now, as directhex is saying. anyway, please file a bug if there isn't already one
[00:34] <ricardo> yes, i have the medibuntu
[00:34] <ricardo> i think it have a problem with ffmeg
[00:35] <lukehasnoname> directhex: So, what if the package is in Ibex?
[00:35] <Adri2000> ricardo: those packages are not from medibuntu
[00:35] <Adri2000> ricardo: if you have a question about medibuntu though, #medibuntu would be a better place
[00:36] <Adri2000> lukehasnoname: intrepid, not ibex ;)
[00:37] <lukehasnoname> Adri2000: I know, but Ibex is quicker to type. My hands literally get tired, I know that's lazy
[00:37] <lukehasnoname> if only the tab key could predict my sentences
[00:41] <ricardo> can I paste a large text from apt-get here?
[00:42] <directhex> no. use a pastebin.
[00:42] <directhex> and use aptitude, too
[00:48] <ricardo> Following the error from libopencv-dev to libavformat-dev http://pastebin.com/m5fa2f986
[01:13] <apachelogger> is there a convenient way to file a FFE bug for a whole bunch of packages?
[02:12] <NCommander> geser, were you able to get my debdiff to apply?
[06:20] <NCommander> Hey emgent, you around?
[09:09] <Iulian> Good morning.
[09:24] <didrocks> hi
[09:25] <didrocks> in case of a change in a debian package. I changed the Maintainer field. Do I have to keep or delete the "Uploaders" one?
[09:27] <persia> didrocks: Best to just leave it alone.  Soyuz doesn't process that field.
[09:27] <didrocks> persia: ok, noticed. Thanks a lot :)
[09:28] <didrocks> the uploader in the change field is just taken from the changelog, I assume
[09:28] <Iulian> If he adopted a package in Debian I think it's up to him, but not sure.
[09:28] <Iulian> didrocks: They are the co-maintainers of the package.
[09:30] <didrocks> Iulian: I read that yesterday (going through the debian policy) :) But the .changes file has a "Changed-By:" field and I was mixing it with Uploader in the control file. Thanks ;)
[09:30] <geser> NCommander: I didn't try anymore, I'll try again later
[09:31] <NCommander> My other debdiff appied without issue so I'm not sure whats going on, I can just post the regular diff if needed
[09:32] <Iulian> didrocks: You might want to talk to the guys listed in the Uploaders field and ask if they still want to co-maintain the package.
[09:33] <geser> NCommander: I don't understand it either, I usually don't have problems with debdiffs
[09:33] <NCommander> Yeah, very strange
[09:33] <NCommander> I'm running through the FTBFS logs
[09:33] <NCommander> And requesting retries on ones which are either obvious transient failures, or misidentified dep-waits
[09:34] <didrocks> Iulian: sure, I will. (as merging from its package reintroduced a NBS in Ubuntu)
[09:34] <Iulian> didrocks: But if a package was orphaned and no one from the Uploaders field adopted it, I'm sure that they don't want to.
[09:34] <NCommander> So with a little luck I can cut the FTBFS down to main on amd64/i386 to zero
[09:35] <NCommander> (there is still one major one left that needs fixing via the P-a-s file)
[09:35] <Iulian> didrocks: Btw, which package you adopted?
[09:37] <didrocks> Iulian: libwoodstox-java
[09:37] <didrocks> I am working in this bug: https://bugs.launchpad.net/ubuntu/+source/azureus/+bug/203636
[09:37] <didrocks> I was just, after having uploaded my 3 previous debdiff thinking of removing the NBS
[09:37] <didrocks> and this package appeared after a sync…
[09:42] <didrocks> I think I can use a -headless for this one
[09:52] <laga> can someone please review mythtv-theme-metallurgy-wide on REVU? it's an artwork package which is supposed to go in for intrepid. thanks :) http://revu.ubuntuwire.com/details.py?package=mythtv-theme-metallurgy-wide
[09:53] <jpds> RainCT: I didn't touch that.
[10:31] <bobbo> What is the correct way to name a version taken from a bzr repo?
[10:38] <RainCT> bobbo: considering that the last released version is 0.1 and the next one will be 0.2, either 0.1+bzrXX or 0.2~bzrXX, where XX can be either the revision, the date you checked it out or the last modification date
[10:39] <bobbo> RainCT: ok, thanks :)
[11:15] <psycose> hi
[11:16] <psycose> i've create a debian source libfoo that provide 3 debian packages, libfoo0, libfoo0-bin and libfoo0-dev, i've added export LD_LIBRARY_PATH := debian/libgnatgpr0/usr/lib:$(LD_LIBRARY_PATH) to the debian/rules so that the created shared library can be seen by the binary. The debuild work on my system but not on the launchpad PPA builder system, any tips ? thanks
[11:31] <tacone> psycose: pdebuild works ?
[11:39] <psycose> tacone: sorry i'm not using pdebuildon my system
[11:41] <tacone> psycose: pbuilder should have an option to reproduce the building machines environment. you may want to try it.
[11:42] <psycose> tacone ok thanks,
[11:43] <psycose> but could you state if it Ok to modify the LD_LIBRARY_PATH for this kind of purpose ?
[11:43] <psycose> inthe debian/rules ...
[11:43] <tacone> sadly that's out of the scope of my knowledge.
[11:45] <psycose> ok thanks
[12:05] <NCommander> RainCT, you around?
[12:05] <NCommander> or any MOTU who is willing to reset some build records?
[12:07] <apachelogger> NCommander: reset?
[12:07] <NCommander> aka retry a build
[12:08] <apachelogger> NCommander: which package(s)?
[12:08] <NCommander> alsa-tools (amd64|ia64), courier, all architectures
[12:08] <NCommander> Both are misidentified dep-waits
[12:08] <NCommander> I have a few more, I'm pruning the build lists
[12:08] <NCommander> I'm trying to get them down to legit build failures only
[12:09] <NCommander> apachelogger, dovecot also
[12:09] <NCommander> er wait, thats a main package
[12:09] <apachelogger> hehe
[12:11] <NCommander> apachelogger, I assume your not a core-dev, right?
[12:12] <NCommander> krusader - all failed archs
[12:12] <apachelogger> unfortunately not
[12:12] <RainCT> NCommander: not yet, but in a few days perhaps he is :)
[12:12] <NCommander> kio-bookmarks
[12:12] <RainCT> (s/is/will be/ even)
[12:13] <apachelogger> kio-bookmarks is getting an update soon, in case FFe gets granted
[12:13] <NCommander> apachelogger, semantik
[12:14] <NCommander> Well, it doesn't hurt to retry the build anyway
[12:14] <apachelogger> *nod*
[12:14] <NCommander> my goal is less than 20 FTBFS in universe
[12:14] <NCommander> (I'd like to extend that to multiverse too given enough time)
[12:15] <NCommander> touchfreeze - amd64 only
[12:15] <RainCT> apachelogger: for the case you don't know, there's a script (buildd) in u-d-t which you can use to do that
[12:16] <NCommander> RainCT, I have a patch in the universe sponsors queue to clear an FTBFS
[12:16] <apachelogger> RainCT: I certainly would have writen one right now if I didn't know ;-)
[12:16] <NCommander> Care to sponsor it?
[12:16] <directhex> NCommander, if in doubt, for amd64 failures, add -fPIC!
[12:17] <NCommander> directhex, it was a mis-identified dep-wait
[12:17] <NCommander> apachelogger, add uqm to the list
[12:17] <NCommander> That should clear 8 packages from the failure status
[12:17] <RainCT> NCommander: URL?
[12:18] <NCommander> RainCT, http://qa.ubuntuwire.com/ftbfs/index.html
[12:18] <NCommander> That's the general failure list
[12:18] <NCommander> I'm looking at the build logs which are ones misidentified
[12:18] <NCommander> as failures
[12:19] <RainCT> NCommander: I mean the patch :P
[12:19] <NCommander> oh, the bug that needs sponsoring
[12:19] <NCommander> I just realized ;-)
[12:20] <NCommander> RainCT, https://bugs.edge.launchpad.net/ubuntu/+source/alsaplayer/+bug/262581
[12:21]  * NCommander wishs he could do more than FTBFS fixing :-/
[12:22]  * RainCT whishes he was able to do FTBFS fixing  ;P
[12:23] <NCommander> Don't know C, RainCT ?
[12:23] <RainCT> no, only a little bit
[12:24] <NCommander> Most FTBFS are pretty straightforward
[12:24] <NCommander> It's always watching that little counter go down
[12:24]  * NCommander should run the FTBFS generating scripts here
[12:25] <RainCT> NCommander: re alsaplayer, you haven't done the Maintainer change (don't worry now, I'll do that myself now. but the next time I want to see it! ;))
[12:25] <NCommander> Whoops
[12:25] <NCommander> Argh
[12:25] <NCommander> Its been awhile since I've been doing these
[12:26] <NCommander> I still need a main dev to reset build records
[12:27] <RainCT> NCommander: and the patch doesn't apply -.-
[12:27] <NCommander> argh
[12:27] <NCommander> I've NEVER had that issue with any other debdiff
[12:28] <NCommander> Bugger
[12:28] <NCommander> I rerolled it twince
[12:28] <NCommander> *twice
[12:28] <NCommander> Hold on
[12:28] <NCommander> the original source package must be unclean
[12:28] <NCommander> Oh, I'm awesome
[12:28] <NCommander> I deleted it
[12:28] <NCommander> Hold on, rerolling new patch
[12:33] <NCommander> *sigh*
[12:33] <NCommander> I can't get a clean patch without modifying the rules
[12:41] <siretart> yay for broken clean targets
[12:49] <NCommander> Should I fix it, or manually rip it out of the debdiff ;-)
[12:50] <RainCT> NCommander: fix it :)
[12:51] <NCommander> stupid question
[12:51] <NCommander> What's the preprocessor symbol that GCC defines if compiling on Linux?
[13:00] <quentusrex> How do I create a package if the only thing the package is suppose to do is copy a file to a specific folder? That's it. Just copy the file to the folder... No source code...
[13:02] <lifeless> same way as any other package
[13:02] <quentusrex> How?
[13:03] <quentusrex> most of the examples I see are for compiling source code into a binary package.
[13:03] <quentusrex> I'm trying to do the equivilent of creating a package that has a bunch of desktop wallpapers.
[13:03] <quentusrex> So all I need to do is copy them into the right folder...
[13:06] <quentusrex> lifeless?
[13:08] <lifeless> quentusrex: just make the steps for compiling etc do nothing
[13:10] <quentusrex> I realize I'm over thinking this, but how do I do that?
[13:11] <lifeless> have you done any other packages?
[13:12] <quentusrex> nope. this will be the first package I've built
[13:14] <lifeless> then I suggest following a tutorial about this
[13:15] <NCommander> RainCT, I rolled a new patch which is better than before. It's now lintian clean!
[13:18] <quentusrex> lifeless, do you have a link to a tutorial?
[13:18] <RainCT> NCommander: there is unnecessary stuff in the debdiff :P (config.guess changes)
[13:18] <NCommander> Ugh
[13:19] <NCommander> crud, I fixed that
[13:19] <RainCT> (no need to reupload for that)
[13:19] <NCommander> *sigh*
[13:19] <NCommander> So the clean rule is still a little dirty
[13:19]  * RainCT -> lunch, will look at it after that
[13:20] <lifeless> quentusrex: there are several, start with the MOTU documentation on wiki.ubuntu.com
[13:24] <quentusrex> lifeless, can you point me to a section that will basically 'automajically' work? or describe the basics of how my package will work?
[13:25] <lifeless> quentusrex: you don't know how to package <anything> yet; you've got a bunch of reading to do
[13:25] <lifeless> quentusrex: sorry, but thats the fact of the matter
[13:25] <quentusrex> :( ok....
[13:26] <quentusrex> I see a bunch of tutorials that replace the make command with dh_make
[13:26] <quentusrex> but that doesn't help me...
[13:27] <NCommander> RainCT, was it your changes or mine that broke things like uploads with ~ in the version?
[13:27] <quentusrex> there isn't a make command for my package, and I don't want to make one if I don't have to.
[13:27] <NCommander> (I'm guessing yours since it looks mako related)
[13:28] <lifeless> quentusrex: I don't think you've actually read those tutorials; or you'd not be saying what you just did :)
[13:30] <quentusrex> well, I see the parts where it has preinst scripts, and postinst, and prerm, etc. But I don't see how to bundle the whole folder into the package if I don't have a compiled executable....
[13:31] <quentusrex> And would a bunch of pictures be considered a library package? or a multiple binary?
[13:31] <geser> quentusrex: neither, just a normal package
[13:32] <lifeless> quentusrex: this is what I mean when I say you need to learn : you have lots of questions and they all stem from not understanding what binary packages _do_
[13:32] <quentusrex> because the packaging guide says to use dh_make to generate a lot of the apt info "Now we need to create the customary debian directory where all the packaging information is stored, allowing us to separate the packaging files from the application source files. We will let dh_make do the work for us: "
[13:32] <geser> you just need to replace the "make install" step with the needed calls to "cp" to place the wallpapers into the location from where the deb gets build at the end
[13:32] <lifeless> quentusrex: read, read and read - spend, 2-3 hours reading packaging tutorial, debian packaging guides etc
[13:33] <quentusrex> I usually learn better when I get do something the quick and dirty way that I don't understand at all, then I redo it many times while reading through documentation....
[13:35] <lifeless> sure
[13:35] <lifeless> so the quick and dirty way, give your thing a 'normal' makef ile, follow a tutorial based around that,a nd fiddle :P
[13:43] <NCommander> RainCT, how goes my patch?
[13:46] <RainCT_> NCommander: now there are typos in debian/changelog ^^
[13:47] <NCommander> Hrm
[13:47]  * RainCT_ has a degree in being evil *g*
[13:47] <NCommander> Well
[13:47] <NCommander> Yeah
[13:47] <NCommander> Care to fix it, or do I need to reroll :-/
[13:47] <RainCT_> NCommander: but it applies cleanly now
[13:47] <NCommander> That's an improvement
[13:47] <persia> quentusrex: There was a lesson about that sort of thing, which might help you, but it's very quick, and may not cover everything you need to know.
[13:48] <quentusrex> where was it persia ?
[13:48] <persia> quentusrex: See, that's the thing I don't remember :)
[13:48] <quentusrex> :(
[13:49] <RainCT_> NCommander: xlibmesa-gl-dev -> libgl1-mesa-dev   is that the only dependency change?
[13:49] <persia> I thought someone put it on the wiki...
[13:49] <NCommander> RainCT, I fixed a versioning issue. the 1.1.4 was a 1.1.4-1
[13:49] <NCommander> Which made lintian bug out
[13:52] <quentusrex> So, to build a package do I have to have a make file?
[13:54] <RainCT_> NCommander: OK, note the exact changes in the changelog the next time. I'm test-building it now..
[13:54] <NCommander> can someone give back courier?
[13:57]  * RainCT_ is on it
[13:58] <RainCT_> NCommander: (please forward the alsaplayer fixes to Debian)
[13:58] <NCommander> RainCT, they didn't have an FTBFS
[13:58] <NCommander> however, if you post the revised debdiff, I shall do so
[14:00] <RainCT_> NCommander: I've only changed the changelog
[14:01] <NCommander> I'm not sure what changes to send, there isn't a FTBFS in Debian :-/
[14:02] <quentusrex> Alright. I'll try a different approach for learning how to build my packages. What general steps would I take? My goal is to have a package that copies images into the correct folder so they can easily be selected for desktop wallpapers. My start point is only the images. What do I do next?
[14:03] <persia> quentusrex: I'm sorry.  It doesn't appear that anyone wrote up the class.  It was in #ubuntu-classroom sometime in July, so you might look at the logs, but that may take a while.
[14:04] <persia> quentusrex: Follow the regular packaging guide.  For all the sections that build stuff, ignore them.  In the install section, install your images.
[14:05] <RainCT_> NCommander: If they don't have the problem because they have a different compiler version or something then I guess it still makes sense to send it. If it doesn't affect them at all then feel free to ignore my request.
[14:05] <NCommander> RainCT_, Every time I've tried to send changes due to glibc breakage, my patches have been rejected
[14:05] <RainCT_> NCommander: changelog http://paste.ubuntu.com/41859/
[14:05] <NCommander> I stopped doing it after the ninth or tenth rejection
[14:07] <persia> Yeah, glibc breakage is one of the ways that Ubuntu differs from Debian.  Those patches typically aren't so useful.
[14:07] <persia> For more clarity, contact those individuals commonly responsible for both glibc packages.
[14:13] <NCommander> Can someone please give-back ardour? It looks like a transient failure but I'm not sure
[14:14] <geser> NCommander: did you test-build it?
[14:14] <NCommander> Downloading build-deps
[14:17] <quentusrex> alright, after reading and asking questions I think I'm on the right track. my goal is to have a package that will copy a group of wallpapers(that are included in the package) into the proper folder. My start point is a folder with a bunch of wallpapers. Step #1 run dh_make. This will generate the debian folder, and the basic files inside it. #2. cd debian, rm *.ex *.EX #3 edit changelog #4 edit control file(nothing much i
[14:17] <quentusrex> n here just developer info) #5 edit rules file(this is the file where all my action steps are located) Somewhere in the rules file I need to add the command "cp ./*.jpg /destination/folder"  #6 run debuild  Is this correct?
[14:18] <persia> ardour is not a transient failure.
[14:18] <persia> It works fine in any local build anyone has tried.
[14:18] <azeem> quentusrex: yes
[14:18] <persia> It still doesn't work in PPA rebuilding for amd64 (although the last adustment worked for i386 and lpia).  It's being actively tracked, so no point pressing the button.
[14:18] <quentusrex> awesome.
[14:19] <azeem> quentusrex: you need to realize what /destination/folder is and what target is the most appropriate one
[14:19] <quentusrex> azeem, do you know how I would put my 'cp' command into rules? is there a special way? or do I just comment out the whole file except my command? Also, how do I reference the location of my files? ./*.jpg?
[14:19] <persia> NCommander: If you want to investigate, it's something odd about scons and the buildds.  You'll want to extract a buildd chroot from librarian (no I don't know the link), and be sure to run the build in parallel mode.
[14:20] <NCommander> You can get buildd chroots?
[14:21] <azeem> quentusrex: some of the targets are mandatory
[14:21] <NCommander> I'll run that one down after I finish netatalk
[14:21] <persia> Yes, but it's a large download, and the URLs aren't very obvious.
[14:21] <azeem> quentusrex: I suggest you look at some other artwork-providing packages to see how they do it
[14:21] <quentusrex> azeem, what targets?
[14:21] <NCommander> librarian won't happent o have a search link, would it?
[14:22] <NCommander> Shoot
[14:22] <NCommander> Found the issue
[14:22] <azeem> quentusrex: Makefile targets, they have a name and a colon after them
[14:22] <NCommander> This needs a sync
[14:23] <quentusrex> oh, ok
[14:24] <quentusrex> But if I left the makefile targets alone and just commented out everything else it'd be fine?
[14:24] <persia> NCommander: What needs a sync?
[14:25] <NCommander> n/m
[14:25] <NCommander> Wrong about the sync
[14:25] <azeem> quentusrex: maybe, some of the dh_ calls towards the end are required to actually get a .deb package out of the building process
[14:25] <NCommander> I figured out that its a configure test can't handle libdb when multiple versions are installed
[14:26] <crevette> Hello
[14:27] <crevette> does Feature Freeze applies on universe packages ?
[14:27] <NCommander> crevette, yes
[14:28] <crevette> okay
[14:28] <NCommander> persia, any hints on how I can find the proper chroot?
[14:29] <persia> NCommander: No idea.  I've only gotten them when I've been given the URL.
[14:29] <NCommander> who gave it to you?
[14:30]  * NCommander didn't even know the chroots were in librarian 
[14:34] <persia> NCommander: I don't remember.  It was in the channel logs, but the last one I had was gutsy, so even if I dug up the link, it would be sure to be out of date (unless you want to do build testing against gutsy)
[14:34] <NCommander> Well, now that I know they exist, I can work on running them down
[14:38] <RainCT_> NCommander: uploaded
[14:39] <NCommander> yay
[14:39] <NCommander> Another FTBFS bites the dust
[14:39] <NCommander> If I can clear these scons ones, we'd be in business
[14:41] <NCommander> persia, it looks like scons gets stuck in an infinite loop or something and then the inactivity feature of sbuild kills it
[14:42] <persia> NCommander: Sometimes.  Sometimes we get other scons confusion.  There's several sources of annoyance involving scons.  I'd like to drop it from the archives, but some upstreams seem to like it for some reason.
[14:42] <NCommander> It's written in python
[14:42] <NCommander> That's what blows my mind
[14:42]  * wgrant stabs people who mark bugs Fix Committed when they upload things to their PPA.
[14:43] <NCommander> How the heck do you get a randomly failing builds just because the build system is a python script
[14:43]  * NCommander is just happy KDE went with CMake over scons)
[14:43] <lifeless> nothing to do with python
[14:43] <lifeless> everything to do with scons
[14:43] <azeem> upgrade to scons-1.0
[14:43] <NCommander> Well, its more that python makes it VERY hard to shoot yourself in the foot
[14:43] <persia> scons is special in an implementation independent manner
[14:44] <NCommander> persia, I've used it before, I didn't like it so I switched to cmake
[14:44] <lifeless> NCommander: its dead easy to shoot yourself in the foot in python
[14:44] <NCommander> What's the big issue with it anyway?
 cmake is the one people switch to after they realize that scons didn't improve their situation and before they switch back to autotools, right?
[14:44] <NCommander> Actually cmake now I find better than autotools
[14:44] <NCommander> Especially w.r.t. to cross-compiling
[14:45] <persia> azeem: Yes.
[14:46] <NCommander> azeem, so your saying autotools is better than cmake?
[14:47] <NCommander> RainCT, care to sponsor another upload?
[14:47] <azeem> NCommander: <foo> bar at the beginning of a line in irc marks a quotation
[14:47] <NCommander> I realize that, but I figure if your repeating it, you agree
[14:51] <RainCT_> NCommander: perhaps tomorrow :P
[14:51] <NCommander> ah well
[14:51] <NCommander> I'm just happy getting these fixes committed
[14:52] <NCommander> Watching the FTBFS count makes me happy
[14:54] <NCommander> ^go down
[15:01] <quentusrex> When I build a package that is just images copied to a folder, do I need an .orig.tar.gz file?
[15:03] <quentusrex> ?
[15:05] <geser> quentusrex: yes, where else would the images come from during package building?
[15:05] <quentusrex> oh, ok. so I have to put all the images into the orig file. awesome.
[15:07] <RainCT_> quentusrex: yes, unless you want a native packages.
[15:15] <quentusrex> https://wiki.ubuntu.com/PackagingGuide/Complete#Building%20the%20Package it says to use the command debuild to build the package. I can't find that command, nor can I find the package it's in.
[15:19] <slytherin> [OT]: Does anyone know what this error mean- initialization discards qualifiers from pointer target type
[15:20]  * verwilst is an ubuntero!
[15:20] <verwilst> ;)
[15:21] <stani> quentusrex: apt-cache search debuild
[15:22] <slytherin> never mind, I found the problem.
[15:24] <persia> slytherin: I'm not sure why that's necessarily off topic either.
[15:25] <slytherin> persia: It is not something related to packaging. :-)
[15:25] <persia> slytherin: Perhaps it's related to fixing bugs?  (We do that here too)
[15:25] <slytherin> persia: No. It is related to a small app I am trying to port to gtksourceview2. :-)
[15:25] <sebner> persia: ah I want to ask you since days what you think about wednesday (the last FF free day). was it a success?
[15:26] <quentusrex> geser, would my package be a single binary? or a library?
[15:27] <persia> sebner: Well, that's not a question I can answer.  To narrow it a bit: was the effort to identify and get sponsored all the changes that would otherwise need a freeze exception a success?
[15:28] <persia> To that question, I'll say it was, although not an unqualified success.  In the last week before FF, the sponsors pushed the vast majority of last-minute fixes.
[15:28] <sebner> persia: sure but I want to hear a sponsors view since some of my syncs weren't processed
[15:28] <sebner> persia: kk :)
[15:28] <quentusrex> Do I have to tell the installer to untar my tar file? or will that already be done?
[15:29] <persia> sebner: Remember, not all syncs would have broken FF.
[15:30] <persia> sebner: It's still possible to pull some syncs, and pre-Lenny release, it's likely that most of them are safe.
[15:31] <quentusrex> make[1]: Entering directory `/tmp/test/quentusrex-0.01'
[15:31] <quentusrex> make[1]: *** No targets specified and no makefile found.  Stop.
[15:31] <persia> On the other hand, I expect you're discussing *neur, and for that it was just a matter of not enough time at the very end.
[15:31] <sebner> persia: I know, I'll check which of my syncs are worth a FFe
[15:31] <persia> quentusrex: You're probably calling make for some reason.  Don't do that.
[15:32] <persia> Essentially, the stuff dh_make generates for you is mostly useless.
[15:32] <persia> (especially for a package that need not be built)
[15:34] <quentusrex> persia, How do I tell my package to untar the orig file? it says it can't find it...
[15:34] <quentusrex> or should I assume it's already untared.
[15:34] <quentusrex> ls
[15:34] <geser> quentusrex: your package would be a single binary
[15:35] <geser> quentusrex: dpkg-source unpacks the .orig.tar.gz and applies the .diff.gz on top of it
[15:35] <quentusrex> where does it unpack it?
[15:35] <quentusrex> relative to the debian/rules file?
[15:36] <azeem> debian/rules is in the .diff.gz, so it doesn't exist before unpacking
[15:36] <quentusrex> so I don't need to unpack the source? just: cd ../ ?
[15:36] <azeem> quentusrex: it really depends on what you're doing
[15:37] <azeem> if you want to unpack the source, unpack it
[15:37] <azeem> if you want to build the source, build it
[15:37] <azeem> if you want to build the binary package, build it
[15:37] <quentusrex> well, I don't have any source
[15:37] <azeem> that'd be a problem
[15:37] <quentusrex> I have jpg's in a tar.gz
[15:37] <quentusrex> I want to untar them
[15:37] <quentusrex> then cp them to a folder.
[15:37] <azeem> the last part is your problem
[15:37] <quentusrex> but I dont' know the relative path to the files.
[15:37] <azeem> what you need is either a packed or unpacked source package
[15:38] <azeem> "cp them to a folder" is part of the binary package building processs
[15:38] <quentusrex> right
[15:39] <quentusrex> Argh... this is difficult...
[15:39] <geser> quentusrex: the tar with your jpgs is the source
[15:39] <azeem> there are some fundamental things you need to understand first, right
[15:39] <quentusrex> I start with a folder called 'quentusrex' and in that folder I have my jpgs.
[15:40] <azeem> ok
[15:40] <quentusrex> the package guide says to tar zcvf the folder
[15:40] <azeem> you already did that no?
[15:40] <azeem> eh
[15:40] <quentusrex> it's named quentusrex-0.01.tar.gz
[15:40] <azeem> nm
[15:40] <quentusrex> I've got that.
[15:40] <azeem> ok
[15:40] <quentusrex> then I'm suppose to cp that to quentusrex_0.01.orig.tar.gz
[15:40] <quentusrex> did that.
[15:40] <azeem> ok
[15:41] <quentusrex> now in my current folder I have the folder quentusrex and the two tar.gz's
[15:41] <quentusrex> I run dh_make
[15:41] <azeem> in the quentusrex folder?
[15:41] <quentusrex> cd debian
[15:41] <quentusrex> no
[15:41] <quentusrex> in my working folder
[15:41] <quentusrex> /tmp/test
[15:41] <azeem> if that works, ok
[15:41] <azeem> the debian folder needs to be under the quentusrex folder in any case
[15:41] <quentusrex> right
[15:41] <quentusrex> it is
[15:42] <quentusrex> it's actually quentusrex-0.01
[15:42] <quentusrex> just to keep things accurate.
[15:42] <quentusrex> alright,
[15:42] <quentusrex> I cd into debian
[15:42] <azeem> so if you're in the quentusrex-0.01 folder and run "dpkg-buildpackage -us -uc -rfakeroot -S", do you get a .diff.gz and .dsc?
[15:42] <quentusrex> rm *.ex *.EX
[15:43] <LucidFox> http://upload.wikimedia.org/wikipedia/en/7/77/Ubuntu_8.10_Alpha_1.png <-- What?!
[15:43] <LucidFox> This is the new default theme?
[15:43] <quentusrex> yes, I have them azeem
[15:43] <azeem> ok
[15:44] <quentusrex> in /tmp/test ls gets me this:
[15:44] <quentusrex> quentusrex-0.01            quentusrex_0.01-1.dsc         quentusrex_0.01-1_source.changes  quentusrex-0.01.tar.gz
[15:44] <quentusrex> quentusrex_0.01-1.diff.gz  quentusrex_0.01-1_i386.build  quentusrex_0.01.orig.tar.gz
[15:44] <persia> LucidFox: Not really.  Test a daily liveCD to see today's default theme.  Wait until the final artwork deadline to know2 for sure.
[15:44] <RainCT_> quentusrex: cd quentusrex-0.01, then run dh_make from inside there
[15:45] <quentusrex> RainCT_, I've done that.
[15:45] <LucidFox> Well, I just hope the new default theme won't feature light text on a dark background.
[15:45] <quentusrex> I've edited the changelog, control,
[15:45] <quentusrex> and now for the rules
[15:45] <azeem> quentusrex: we discussed that earlier
[15:45] <quentusrex> how do I tell the rules file to copy all the jpgs  to /destination/folder?
[15:45] <persia> quentusrex: Don't forget copyright, which is the other required file.
[15:46] <quentusrex> right, I've got that one too
[15:46] <azeem> quentusrex: 15:19 < azeem> quentusrex: I suggest you look at some other artwork-providing packages to see how they do it
[15:46] <quentusrex> changelog  compat  control  copyright  dirs  docs  README.Debian  rules
[15:46] <quentusrex> all edited
[15:46] <persia> You probably don't need dirs, and you probably want install
[15:46] <quentusrex> azeem, I don't know any other packages that do this, and there is no way for me to know if the package I choose is doing it right.
[15:47] <persia> Further, README.Debian probably isn't interesting for this package.
[15:47] <quentusrex> how should I get my jpgs?
[15:48] <azeem> quentusrex: apt-cache search artwork, e.g.
[15:49] <quentusrex> yay
[15:49] <quentusrex> I win
[15:49] <quentusrex> I just assumed that it was already unpacked
[15:49] <quentusrex> so I said cp *.jpg /tmp
[15:49] <quentusrex> and it worked.
[15:49] <azeem> quentusrex: that is wrong, though
[15:50] <quentusrex> I removed all the jpg's and tried it again and it worked again.
[15:50] <quentusrex> :(
[15:50] <azeem> quentusrex: you should not create any files outside the directory you're in
[15:50] <azeem> below, rather
[15:50] <quentusrex> ?
[15:50] <azeem> quentusrex: did you get a .deb with the .jpgs in them?
[15:50] <persia> quentusrex: You probably want to use dpkg --contents foo.deb to make sure the files went into the package
[15:50] <azeem> quentusrex: /tmp is not under quentusrex-0.01
[15:52] <geser> NCommander: bug number for sponsoring?
[15:52] <RainCT_> quentusrex: (ah, right. sorry)
[15:53] <NCommander> geser, https://bugs.edge.launchpad.net/ubuntu/+source/netatalk/+bug/262991
[15:53] <RainCT_> quentusrex: create a debian/install file and write "*.jpg destination/directory/once/installed" there
[15:53] <RainCT_> quentusrex: and then ensure that dh_install is called in debian/rules
[15:54] <quentusrex> hmm
[15:54] <quentusrex> ok...
[15:54] <quentusrex> is that the proper way to install files outside of my directory?
[15:55] <RainCT_> quentusrex: that will install the files in debian/<packagename>/destination/directory/once/installed
[15:55] <geser> NCommander: why not patch it to also find db4.7?
[15:56] <azeem> quentusrex: the point is that you install them in the .deb in the right place, so when the user installs the .deb, they will be outside of your directory
[15:56] <RainCT_> quentusrex: if you open a .deb package with file-roller you'll see that there's a data.tar.gz and a control.tar.gz. When you build a package, the files from debian/<packagename> are the placed into the data.tar.gz, and at install time that tarball is uncompressed into the filesystem
[15:57] <NCommander> geser, because 4.6 is the lib version it checks for
[15:57] <NCommander> or more specifically, 4.6 is still linked to libdb.so even when 4.7 dev is installed
[15:58] <quentusrex> anyone know how to change the maintainer name for dh_make?
[15:58] <azeem> hrm?
[15:58] <quentusrex> I can't sign my package because the maintainer name for dh_make doesn't match my gpg key
[15:58] <azeem> quentusrex: edit debian/control and debian/changelog appropriately
[15:58] <quentusrex> ls
[15:58] <quentusrex> before then
[15:58] <azeem> ?
[15:58] <quentusrex> when I first run dh_make
[15:59] <RainCT_> quentusrex: set the DEBFULLNAME and DEBEMAIL environment variables (in ~/.bashrc or somewhere). but for this package just editing debian/control, debian/changelog and debian/copyright is enough
[15:59] <azeem> read the dh_make documentation, I don't know
[15:59] <azeem> quentusrex: dh_make is a one-time thing anyway
[15:59] <NCommander> its dh_make -e
[15:59] <NCommander> geser, it looks like it might be a bug in libdb-dev that it installs the wrong versions
[15:59] <NCommander> Filing a bug
[15:59] <RainCT_> azeem: dh_make, dch, etc. use the DEBFULLNAME and DEBEMAIL variables
[15:59] <quentusrex> thanks RainCT_ that worked.
[15:59] <geser> NCommander: lrwxrwxrwx 1 root root      12 Aug 30 14:59 /usr/lib/libdb.so -> libdb-4.7.so
[16:00] <NCommander> hrm
[16:00]  * NCommander looks closer at the config script
[16:00] <geser> NCommander: netatalk want to link expiclitly against against libdb-4.6
[16:00] <NCommander> OK
[16:00] <NCommander> Then I'm doing the right thing :-)
[16:00] <geser> so it gets linked while -dev is already at 4.7
[16:00] <NCommander> Right, so explicately setting the versioned requirement does what it should
[16:01] <NCommander> It probably would work against 4.7, but TBI, I don't want to introduce a regression by changing that if it can be avoided
[16:01] <NCommander> (the API is stable, the ABI isn't)
[16:03] <quentusrex> What's the command to install a deb file?
[16:04] <RainCT_> quentusrex: sudo dpkg -i <file>
[16:04] <RainCT_> quentusrex: sudo gdebi <file>   will also install it's dependencies
[16:04] <quentusrex> Yay, that worked
[16:04] <quentusrex> awesome
[16:04] <quentusrex> awesome
[16:04] <quentusrex> awesome
[16:04] <RainCT_> quentusrex: and you can see the content of a .deb with  sudo dpkg-deb --contents <file>
[16:04] <RainCT_> (err, without sudo)
[16:04] <quentusrex> right
[16:04] <RainCT_> quentusrex: nice :)
[16:04] <quentusrex> YAY
[16:05] <quentusrex> Now, what about editing a file?
[16:05] <quentusrex> what if I have to replace an older file?
[16:05] <quentusrex> is there anything 'special' about that?
[16:05] <quentusrex> :)
[16:05] <quentusrex> such as an update to my package
[16:05] <NCommander> quentusrex, is it installed by your package, or not?
[16:05] <quentusrex> yes, by my package
[16:05] <NCommander> The package can replace any files it owns
[16:06] <NCommander> (that is, files it installs)
[16:06] <azeem> quentusrex: release a new tarball, e.g.
[16:06] <RainCT_> quentusrex: when you update a package the old version will be removed and after that the new one installed (beside some other stuff happening, like scripts being executed), so that's no problem
[16:06] <quentusrex> what about a file that the package doesn't own? a file that the package updates?
[16:06] <azeem> (binary files are difficult to replace)
[16:06] <azeem> quentusrex: example?
[16:06] <NCommander> geser, any other obvious issues with my patch?
[16:07] <quentusrex> I can't think of an example. but like an xml file that was installed by a different package?
[16:07] <RainCT_> quentusrex: you can replace a file from another package with a divert (don't ask me how that works, I have never used it), but you should try to avoid that
[16:07] <geser> no, I'm still thinking what's better: build it with db-4.6 or with db-4.7 (which is the current default)
[16:07] <azeem> quentusrex: it's generally bad practise
[16:07] <NCommander> geser, if its trying to explicately link against db-4.6, give it what it wants
[16:08] <quentusrex> I realize that... but the package is for my local network.
[16:08] <quentusrex> oh, I know of an example.
[16:08] <quentusrex> Adding all the local network shares to auto mount. I want to add lines to the end of /etc/fstab
[16:08] <NCommander> geser, considering that fixing it to use db4.7 might introduce subtle regressions, break the existing metadata, etc.
[16:08] <quentusrex> can I just echo "config info" >> /etc/fstab
[16:08] <quentusrex> ?
[16:08] <quentusrex> in the rules file?
[16:09] <RainCT_> quentusrex: No. The rules file is used at build time and is not included in the package.
[16:09] <quentusrex> oh, then how would I do it?
[16:09] <RainCT_> quentusrex: You need a postinst script for that.
[16:09] <NCommander> geser, and as an added note, I'd like to point out libdb3, which I think was released in '00 still exists in the archive
[16:09] <geser> NCommander: true
[16:09] <quentusrex> ok, so how would I setup a postinst script?
[16:10] <azeem> quentusrex: it's a very bad idea, really
[16:10] <geser> NCommander: we have to many libdb4.* in the archive too
[16:10] <azeem> quentusrex: you don't need to do everthing with a package
[16:10] <quentusrex> azeem, is there a better way?
[16:10] <RainCT_> quentusrex: but I really don't recommend doing stuff like that (having packages which edit files)..
[16:10] <azeem> quentusrex: edit /etc/fstab directly
[16:10] <NCommander> geser, well, thats because sleepycat/oracle likes to break the binary format with each library revision :-)
[16:10] <quentusrex> azeem, I'm managing 100+ ubuntu workstations...
[16:10] <quentusrex> I don't want to do everything manually
[16:10] <azeem> NCommander: I thought there's only problems if you use transactions
[16:10] <azeem> for 4.4->4.7, at least or so
[16:10] <NCommander> azeem, I thought it was a general issue.
[16:11] <NCommander> azeem, as an aside, do you know what apps use transactions and which don't ;-)?
[16:11] <azeem> it certainly was in the past
[16:11] <quentusrex> RainCT_, if it is for my local network only, what is best way to edit the files?
[16:11] <azeem> NCommander: most don't I think
[16:11] <azeem> but not sure
[16:11] <azeem> quentusrex: use something else than a package manager
[16:11] <azeem> like cfengine
[16:11] <azeem> maybe
[16:12] <NCommander> It's probably an easier solution for the time being to simply keep the library running with its old data format. We still have gcc3 .4 packaged for things like QEMU that still depend on it
[16:13] <RainCT_> quentusrex: can't you use NFS or something else?
[16:13] <quentusrex> azeem, I'm not planning to do all my configuring from the package manager, but I'd like to be able to get the basics setup.
[16:13] <NCommander> ^- azeem/geser
[16:13] <quentusrex> like the basic and standard company bookmarks, network shares, etc.
[16:13] <quentusrex> internal stuff like that.
[16:15] <persia> quentusrex: If you want to adjust default user configuration, you can add dotfiles to /etc/skel
[16:15] <RainCT_> quentusrex: appending stuff to configuration files becomes a problem when you want to change the stuff you added
[16:15] <persia> Just do it with a yoyodyne-local-settings package.
[16:15] <geser> NCommander: while looking at the control file for netatalk: wouldn't it be a good idea to recommend db4.6-utils instead of db4.2-utils?
[16:15] <persia> Mind you, you can't edit it later: it will only be defined at the time a user is created.
[16:16] <NCommander> geser, probably. I didn't check the recommends >.>;
[16:16] <quentusrex> Then is there a way for conf files to include the settings in a separate file?
[16:17] <azeem> that depends on the program parsing them
[16:17] <quentusrex> like if I want /etc/fstab to include the settings in a file in a different folder...
[16:17] <quentusrex> oh, ok.
[16:17] <NCommander> geser, I can post a new debdiff, or if you want to fix it ...
[16:18] <quentusrex> I'll deal with that stuff later.
[16:18] <azeem> quentusrex: we're quickly drifting off-topic, maybe you should ask further questions like those in #ubuntu
[16:18] <RainCT_> quentusrex: perhaps your real problem is not how to modify the files but rather how to do stuff so that you don't need to modify those files
[16:18] <quentusrex> ok, thanks
[16:18] <quentusrex> I think you're right RainCT_
[16:18] <geser> NCommander: no need for a new debdiff, I've changed this myself already and I'm testbuilding now
[16:18] <quentusrex> but, for my next lesson
[16:19] <quentusrex> How do I build an update?
[16:19] <geser> NCommander: btw this debdiff applied without problems
[16:19] <quentusrex> let's say I've changed one of the jpgs
[16:19] <quentusrex> how do I build the update?
[16:19] <quentusrex> do I just change the foldername to quentusrex-0.02
[16:19] <NCommander> geser, I figured out why the last one didn't. I accidently corrupted the old source package I debdiff'ed against
[16:19] <quentusrex> and build a whole new package?
[16:20] <NCommander> geser, cause that package had a bad clean rule
[16:20] <RainCT_> quentusrex: get the new tarball, unextract it, copy the old debian/ directory into it, run "dch -i" to add a new changelog entry and do any changes you need to the packaging. after that just build the package again
[16:20] <nxvl> good morning
[16:20] <quentusrex> RainCT_, that went over my head.... sorry.
[16:21] <RainCT_> quentusrex: there are more detailed examples on the wiki
[16:21] <quentusrex> so the tarball with all my jpgs, do I have to include all the files? or just the changed ones?
[16:21] <RainCT_> quentusrex: all the files
[16:21] <RainCT_> quentusrex: (https://wiki.ubuntu.com/PackagingGuide/HandsOn#Tutorial%202:%20Updating%20a%20Package)
[16:22] <slytherin> anyone here familiar with gtksourceview?
[16:23] <RainCT_> quentusrex: untar the old .orig.tar.gz, do any changes you want to the files, rename the directory to have a higher version number and compress it again (giving the resulting .orig.tar.gz the same version number as to which you renamed the directory)
[16:26] <quentusrex> RainCT_, it keeps going into the quentusrex-0.01 directory
[16:26] <quentusrex> which has all of the debian stuff in it
[16:26] <quentusrex> how do I get it into a different directory
[16:27] <azeem> rename the directory you tar up
[16:28] <azeem> "rename the directory to have a higher version"
[16:28] <azeem> quentusrex: or if you're at the first step "untar the old .orig.tar.gz", do that at a different location than where your debian package is
[16:28] <quentusrex> ok
[16:29] <quentusrex> would I need to cp quentusrex-0.02.tar.gz quentusrex_0.02.orig.tar.gz ?
[16:30] <azeem> you should be able to answer that question yourself by now
[16:30] <quentusrex> yeah... I guess I can...
[16:34] <quentusrex> yay
[16:34] <quentusrex> the update works
[16:35] <quentusrex> Now, couldn't this be automated? :)
[16:35] <geser> slytherin: I'm not familiar with it but perhaps I still can help depending on the kind of problem you have
[16:36] <quentusrex> azeem, no wonder people are relatively slow to release new packages. that's a pain...
[16:36] <quentusrex> atleast for a small change.
[16:36] <slytherin> geser: I was wondering if it is possible to retrieve the directory containing language spec files using pkg-config
[16:37] <azeem> quentusrex: it's a general problem and has nothing to do with Ubuntu packaging
[16:38] <NCommander> geser, how goes test building?
[16:38] <geser> NCommander: netatalk is already uploaded
[16:38] <azeem> quentusrex: usually, in a computing project, the time spent to implement new features or fix bugs is far bigger than the time spent on rolling a tarball
[16:38] <NCommander> \o\
[16:38] <quentusrex> azeem, yeah... I bet it would be..
[16:39] <geser> NCommander: did you get yet a mail from the bug?
[16:39] <NCommander> just got it now :-)
[16:49] <laga> forgive me for announcing my package for the second time today, but i've decided to change my approach
[16:50] <laga> so, for every problem found in http://revu.ubuntuwire.com/details.py?package=mythtv-theme-metallurgy-wide i'll do ten merges next cycle ;)
[16:51] <quentusrex> where is info on postinst?
[16:51] <azeem> in the debian-policy package
[16:52] <quentusrex> is it like the rules and install files?
[16:53] <quentusrex> or is it different?
[16:53] <azeem> the debian-policy package?
[16:54] <RainCT_> quentusrex: well, it's a script
[17:13] <albert23> persia, quentusrex: I have added the logs for the packaging lesson on the wiki: https://wiki.ubuntu.com/MOTU/School/PackagingWithoutCode
[17:15] <persia> albert23: Thanks.  I'm sure there's heaps of mistakes there (on my part), but it's incredibly better than me misremembering having done that in June.
[17:15] <persia> s/June/July/
[17:18] <dmoerner> persia, fyi priority essential does not exist, but bash is priority required
[17:19] <persia> dmoerner: Yep.  Please feel free to take the ideas from the session, add in the pastebins, fix all the errors, and make a nice wiki page.
[17:20] <persia> dmoerner: https://wiki.ubuntu.com/Bugs/ApportRetraces is an example of the end-state of such a session log, once editing is complete.
[17:21] <dmoerner> persia, yes i think i remember reading something from russ allbery's blog that had some more information on packaging scripts so i'll see if that could be incorporated as well
[17:22] <persia> dmoerner: That would be great.  When looking around earlier, I also found https://wiki.ubuntu.com/WebAppsPackaging which seems to have some pointers to some special cases for web applications, which might be worth mentioning.
[17:23] <persia> At least specifically http://webapps-common.alioth.debian.org/draft/html/ (unless you can find a final version)
[17:23] <BUGabundo> tseliot ping
[17:23] <persia> Also, it's worth mentioning that roughly the same model works for wallpaper selections, etc.
[17:27] <persia> albert23: dmoerner: Also, when you're done, please ask me to run a session on something else.  No promises that I know it, but I'd like to reward those who turn my sessions into real documentation :)
[18:09] <kevjava> Would this be the correct place to ask policy questions?  I was thinking about packaging an application, but there is no specific license attached to it...
[18:11] <kevjava> There's just a blanket, informal, "do what you want".  I didn't really want to spend all the time and energy packaging it if it would be rejected for license problems in REVU.
[18:19] <RainCT_> kevjava: Where is that notice? And does it declare a copyright holder?
[18:21] <kevjava> There is a copyright holder...   http://users.erols.com/whitaker/words.htm is the package.
[18:23] <kevjava> His (William Whitaker's) is the only copyright I could see in the source code.
[18:27] <kevjava> RainCT_: It says all over that it's "Free for any use".  No explicit license, though.
[18:28] <RainCT_> kevjava: ftp://petrus.thomasaquinas.edu/pub/linux/words/words-1.97Ed-linux.tar.gz is that the tarball? (because I can't download it :S)
[18:30] <kevjava> RainCT_: I  believe so.  I had problems downloading it from there, as well...  I'll see if I can find where I got it form
[18:30] <RainCT_> ah.. it's this one or what? http://users.erols.com/whitaker/wordsall.zip
[18:30] <kevjava> RainCT_: Yes, that's the one I got.  That's the source package.
[18:33] <RainCT_> kevjava: OK, I'm downloading it... Anyway, it would be a good idea to e-mail the author and ask him if he can provide the source in a .tar.gz and license it under the ISC (http://www.opensource.org/licenses/isc-license.txt) or some other license
[18:34] <RainCT_> and placing the files into a words-<version> directory, so that you don't need to repackage it
[18:34] <kevjava> RainCT_: Will do.
[18:35] <kevjava> RainCT_: If he does not respond, and I do repackage it, could it still be placed in the multiverse?
[18:35] <RainCT_> kevjava: it may get accepted in the current state, but it may be rejected as well
[18:36] <RainCT_> kevjava: no, multiverse is for non-free applications. applications under an unclear license can't go there, neither
[18:36] <kevjava> RainCT_: Ahh, understood.  That was my worry.  Thank you kindly, I'll get cracking.
[19:14]  * NCommander plays with his new toy
[19:58] <dmoerner> persia, i just finished adapting the wiki page, if you're curious: https://wiki.ubuntu.com/MOTU/School/PackagingWithoutCode