[00:02] sistpoty: Go for it if you haven't already. [00:03] ScottK: ok, though I'm a little bit drunk right now, and am fiddling with the upstream version number name [00:03] Maybe tomorrow then. [00:03] ScottK: in case you'd like to jump in I'd be more than happy [00:03] Sorry, I've got kids to deal with tonight. [00:04] sure... then I hope to get it sorted out asap [00:05] ScottK: any objections against 1.3.0~RC1is1.2.0-2ubuntu2 ? === Kopfgeldjaeger is now known as Kopfi|offline [00:05] sistpoty: Normally we put the really bit in there, but if you prefer that, I don't object. [00:06] ScottK: as in 1.3.0~RC1isreally1.2.0-2ubuntu2 ? or s.th else? [00:07] Without the is [00:07] 1.3.0~RC1really1.2.0-2ubuntu2 [00:07] Gotta run. [00:08] ScottK: hm... ok, sure... (just wondered if svn would sort later... then recalled the alphabet *g*) [00:08] cya ScottK [00:08] Good point, but they use Git anyway I think. [00:20] ScottK: uploaded :) [00:20] and now, I'll got to bed.. gn8 everyone [00:23] Could someone link me or tell me the process of getting a package into hardy-updates? [00:23] updates? [00:24] what's your reasoning? why does it need to go into -updates ? [00:24] lukehasnoname: https://wiki.ubuntu.com/StableReleaseUpdates [00:26] 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] opencv-dev depends opencvaux-dev. But opencvaux-dev depends opencv-dev. I'm using Ubuntu Gutsy, how solve this? [00:29] lukehasnoname, the newer version is in intrepid? [00:30] both cases, yes [00:31] lukehasnoname: the sru procedure is the same for all stable releases [00:32] Adri2000: k [00:33] ricardo, libcv and libcvaux? [00:33] 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] yes, i have the medibuntu [00:34] i think it have a problem with ffmeg [00:35] directhex: So, what if the package is in Ibex? [00:35] ricardo: those packages are not from medibuntu [00:35] ricardo: if you have a question about medibuntu though, #medibuntu would be a better place [00:36] lukehasnoname: intrepid, not ibex ;) [00:37] Adri2000: I know, but Ibex is quicker to type. My hands literally get tired, I know that's lazy [00:37] if only the tab key could predict my sentences [00:41] can I paste a large text from apt-get here? [00:42] no. use a pastebin. [00:42] and use aptitude, too [00:48] Following the error from libopencv-dev to libavformat-dev http://pastebin.com/m5fa2f986 === nxvl_ is now known as nxvl [01:13] is there a convenient way to file a FFE bug for a whole bunch of packages? [02:12] geser, were you able to get my debdiff to apply? [06:20] Hey emgent, you around? [09:09] Good morning. [09:24] hi [09:25] 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] didrocks: Best to just leave it alone. Soyuz doesn't process that field. [09:27] persia: ok, noticed. Thanks a lot :) [09:28] the uploader in the change field is just taken from the changelog, I assume [09:28] If he adopted a package in Debian I think it's up to him, but not sure. [09:28] didrocks: They are the co-maintainers of the package. [09:30] 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] NCommander: I didn't try anymore, I'll try again later [09:31] 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] 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] NCommander: I don't understand it either, I usually don't have problems with debdiffs [09:33] Yeah, very strange [09:33] I'm running through the FTBFS logs [09:33] And requesting retries on ones which are either obvious transient failures, or misidentified dep-waits [09:34] Iulian: sure, I will. (as merging from its package reintroduced a NBS in Ubuntu) [09:34] 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] So with a little luck I can cut the FTBFS down to main on amd64/i386 to zero [09:35] (there is still one major one left that needs fixing via the P-a-s file) [09:35] didrocks: Btw, which package you adopted? [09:37] Iulian: libwoodstox-java [09:37] I am working in this bug: https://bugs.launchpad.net/ubuntu/+source/azureus/+bug/203636 [09:37] Launchpad bug 203636 in libwoodstox-java "replace icedtea-java7 references with openjdk-6 references" [Undecided,In progress] [09:37] I was just, after having uploaded my 3 previous debdiff thinking of removing the NBS [09:37] and this package appeared after a sync… [09:42] I think I can use a -headless for this one [09:52] 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] RainCT: I didn't touch that. [10:31] What is the correct way to name a version taken from a bzr repo? [10:38] 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] RainCT: ok, thanks :) [11:15] hi [11:16] 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] psycose: pdebuild works ? === Kopfi|offline is now known as Kopfgeldjaeger [11:39] tacone: sorry i'm not using pdebuildon my system [11:41] psycose: pbuilder should have an option to reproduce the building machines environment. you may want to try it. [11:42] tacone ok thanks, [11:43] but could you state if it Ok to modify the LD_LIBRARY_PATH for this kind of purpose ? [11:43] inthe debian/rules ... [11:43] sadly that's out of the scope of my knowledge. [11:45] ok thanks [12:05] RainCT, you around? [12:05] or any MOTU who is willing to reset some build records? [12:07] NCommander: reset? [12:07] aka retry a build [12:08] NCommander: which package(s)? [12:08] alsa-tools (amd64|ia64), courier, all architectures [12:08] Both are misidentified dep-waits [12:08] I have a few more, I'm pruning the build lists [12:08] I'm trying to get them down to legit build failures only [12:09] apachelogger, dovecot also [12:09] er wait, thats a main package [12:09] hehe [12:11] apachelogger, I assume your not a core-dev, right? [12:12] krusader - all failed archs [12:12] unfortunately not [12:12] NCommander: not yet, but in a few days perhaps he is :) [12:12] kio-bookmarks [12:12] (s/is/will be/ even) [12:13] kio-bookmarks is getting an update soon, in case FFe gets granted [12:13] apachelogger, semantik [12:14] Well, it doesn't hurt to retry the build anyway [12:14] *nod* [12:14] my goal is less than 20 FTBFS in universe [12:14] (I'd like to extend that to multiverse too given enough time) [12:15] touchfreeze - amd64 only [12:15] 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] RainCT, I have a patch in the universe sponsors queue to clear an FTBFS [12:16] RainCT: I certainly would have writen one right now if I didn't know ;-) [12:16] Care to sponsor it? [12:16] NCommander, if in doubt, for amd64 failures, add -fPIC! [12:17] directhex, it was a mis-identified dep-wait [12:17] apachelogger, add uqm to the list [12:17] That should clear 8 packages from the failure status [12:17] NCommander: URL? [12:18] RainCT, http://qa.ubuntuwire.com/ftbfs/index.html [12:18] That's the general failure list [12:18] I'm looking at the build logs which are ones misidentified [12:18] as failures [12:19] NCommander: I mean the patch :P [12:19] oh, the bug that needs sponsoring [12:19] I just realized ;-) [12:20] RainCT, https://bugs.edge.launchpad.net/ubuntu/+source/alsaplayer/+bug/262581 [12:20] Launchpad bug 262581 in alsaplayer "FTBFS fix for alsaplayer" [Undecided,New] [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] Don't know C, RainCT ? [12:23] no, only a little bit [12:24] Most FTBFS are pretty straightforward [12:24] It's always watching that little counter go down [12:24] * NCommander should run the FTBFS generating scripts here [12:25] 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] Whoops [12:25] Argh [12:25] Its been awhile since I've been doing these [12:26] I still need a main dev to reset build records [12:27] NCommander: and the patch doesn't apply -.- [12:27] argh [12:27] I've NEVER had that issue with any other debdiff [12:28] Bugger [12:28] I rerolled it twince [12:28] *twice [12:28] Hold on [12:28] the original source package must be unclean [12:28] Oh, I'm awesome [12:28] I deleted it [12:28] Hold on, rerolling new patch [12:33] *sigh* [12:33] I can't get a clean patch without modifying the rules [12:41] yay for broken clean targets [12:49] Should I fix it, or manually rip it out of the debdiff ;-) [12:50] NCommander: fix it :) [12:51] stupid question [12:51] What's the preprocessor symbol that GCC defines if compiling on Linux? [13:00] 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] same way as any other package [13:02] How? [13:03] most of the examples I see are for compiling source code into a binary package. [13:03] I'm trying to do the equivilent of creating a package that has a bunch of desktop wallpapers. [13:03] So all I need to do is copy them into the right folder... [13:06] lifeless? [13:08] quentusrex: just make the steps for compiling etc do nothing [13:10] I realize I'm over thinking this, but how do I do that? [13:11] have you done any other packages? [13:12] nope. this will be the first package I've built [13:14] then I suggest following a tutorial about this [13:15] RainCT, I rolled a new patch which is better than before. It's now lintian clean! [13:18] lifeless, do you have a link to a tutorial? [13:18] NCommander: there is unnecessary stuff in the debdiff :P (config.guess changes) [13:18] Ugh [13:19] crud, I fixed that [13:19] (no need to reupload for that) [13:19] *sigh* [13:19] So the clean rule is still a little dirty [13:19] * RainCT -> lunch, will look at it after that [13:20] quentusrex: there are several, start with the MOTU documentation on wiki.ubuntu.com [13:24] 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] quentusrex: you don't know how to package yet; you've got a bunch of reading to do [13:25] quentusrex: sorry, but thats the fact of the matter [13:25] :( ok.... [13:26] I see a bunch of tutorials that replace the make command with dh_make [13:26] but that doesn't help me... [13:27] RainCT, was it your changes or mine that broke things like uploads with ~ in the version? [13:27] 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] (I'm guessing yours since it looks mako related) [13:28] quentusrex: I don't think you've actually read those tutorials; or you'd not be saying what you just did :) [13:30] 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] And would a bunch of pictures be considered a library package? or a multiple binary? [13:31] quentusrex: neither, just a normal package [13:32] 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] 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] 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] quentusrex: read, read and read - spend, 2-3 hours reading packaging tutorial, debian packaging guides etc [13:33] 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] sure [13:35] so the quick and dirty way, give your thing a 'normal' makef ile, follow a tutorial based around that,a nd fiddle :P === asac_ is now known as asac [13:43] RainCT, how goes my patch? [13:46] NCommander: now there are typos in debian/changelog ^^ [13:47] Hrm [13:47] * RainCT_ has a degree in being evil *g* [13:47] Well [13:47] Yeah [13:47] Care to fix it, or do I need to reroll :-/ [13:47] NCommander: but it applies cleanly now [13:47] That's an improvement [13:47] 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] where was it persia ? [13:48] quentusrex: See, that's the thing I don't remember :) [13:48] :( [13:49] NCommander: xlibmesa-gl-dev -> libgl1-mesa-dev is that the only dependency change? [13:49] I thought someone put it on the wiki... [13:49] RainCT, I fixed a versioning issue. the 1.1.4 was a 1.1.4-1 [13:49] Which made lintian bug out [13:52] So, to build a package do I have to have a make file? [13:54] NCommander: OK, note the exact changes in the changelog the next time. I'm test-building it now.. [13:54] can someone give back courier? [13:57] * RainCT_ is on it [13:58] NCommander: (please forward the alsaplayer fixes to Debian) [13:58] RainCT, they didn't have an FTBFS [13:58] however, if you post the revised debdiff, I shall do so [14:00] NCommander: I've only changed the changelog [14:01] I'm not sure what changes to send, there isn't a FTBFS in Debian :-/ [14:02] 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] 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] quentusrex: Follow the regular packaging guide. For all the sections that build stuff, ignore them. In the install section, install your images. [14:05] 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] RainCT_, Every time I've tried to send changes due to glibc breakage, my patches have been rejected [14:05] NCommander: changelog http://paste.ubuntu.com/41859/ [14:05] I stopped doing it after the ninth or tenth rejection [14:07] Yeah, glibc breakage is one of the ways that Ubuntu differs from Debian. Those patches typically aren't so useful. [14:07] For more clarity, contact those individuals commonly responsible for both glibc packages. [14:13] Can someone please give-back ardour? It looks like a transient failure but I'm not sure [14:14] NCommander: did you test-build it? [14:14] Downloading build-deps [14:17] 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] 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] ardour is not a transient failure. [14:18] It works fine in any local build anyone has tried. [14:18] quentusrex: yes [14:18] 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] awesome. [14:19] quentusrex: you need to realize what /destination/folder is and what target is the most appropriate one [14:19] 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] 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] You can get buildd chroots? [14:21] quentusrex: some of the targets are mandatory [14:21] I'll run that one down after I finish netatalk [14:21] Yes, but it's a large download, and the URLs aren't very obvious. [14:21] quentusrex: I suggest you look at some other artwork-providing packages to see how they do it [14:21] azeem, what targets? [14:21] librarian won't happent o have a search link, would it? [14:22] Shoot [14:22] Found the issue [14:22] quentusrex: Makefile targets, they have a name and a colon after them [14:22] This needs a sync [14:23] oh, ok [14:24] But if I left the makefile targets alone and just commented out everything else it'd be fine? [14:24] NCommander: What needs a sync? [14:25] n/m [14:25] Wrong about the sync [14:25] 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] I figured out that its a configure test can't handle libdb when multiple versions are installed [14:26] Hello [14:27] does Feature Freeze applies on universe packages ? [14:27] crevette, yes [14:28] okay [14:28] persia, any hints on how I can find the proper chroot? [14:29] NCommander: No idea. I've only gotten them when I've been given the URL. [14:29] who gave it to you? [14:30] * NCommander didn't even know the chroots were in librarian [14:34] 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] Well, now that I know they exist, I can work on running them down [14:38] NCommander: uploaded [14:39] yay [14:39] Another FTBFS bites the dust [14:39] If I can clear these scons ones, we'd be in business [14:41] persia, it looks like scons gets stuck in an infinite loop or something and then the inactivity feature of sbuild kills it [14:42] 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] It's written in python [14:42] 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] 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] nothing to do with python [14:43] everything to do with scons [14:43] upgrade to scons-1.0 [14:43] Well, its more that python makes it VERY hard to shoot yourself in the foot [14:43] scons is special in an implementation independent manner [14:44] persia, I've used it before, I didn't like it so I switched to cmake [14:44] NCommander: its dead easy to shoot yourself in the foot in python [14:44] What's the big issue with it anyway? [14:44] 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] Actually cmake now I find better than autotools [14:44] Especially w.r.t. to cross-compiling [14:45] azeem: Yes. === Pici`__ is now known as Pici [14:46] azeem, so your saying autotools is better than cmake? [14:47] RainCT, care to sponsor another upload? [14:47] NCommander: bar at the beginning of a line in irc marks a quotation [14:47] I realize that, but I figure if your repeating it, you agree [14:51] NCommander: perhaps tomorrow :P [14:51] ah well [14:51] I'm just happy getting these fixes committed [14:52] Watching the FTBFS count makes me happy [14:54] ^go down === bddebian2 is now known as bddebian [15:01] When I build a package that is just images copied to a folder, do I need an .orig.tar.gz file? [15:03] ? [15:05] quentusrex: yes, where else would the images come from during package building? [15:05] oh, ok. so I have to put all the images into the orig file. awesome. [15:07] quentusrex: yes, unless you want a native packages. [15:15] 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] [OT]: Does anyone know what this error mean- initialization discards qualifiers from pointer target type [15:20] * verwilst is an ubuntero! [15:20] ;) [15:21] quentusrex: apt-cache search debuild [15:22] never mind, I found the problem. [15:24] slytherin: I'm not sure why that's necessarily off topic either. [15:25] persia: It is not something related to packaging. :-) [15:25] slytherin: Perhaps it's related to fixing bugs? (We do that here too) [15:25] persia: No. It is related to a small app I am trying to port to gtksourceview2. :-) [15:25] 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] geser, would my package be a single binary? or a library? [15:27] 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] 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] persia: sure but I want to hear a sponsors view since some of my syncs weren't processed [15:28] persia: kk :) [15:28] Do I have to tell the installer to untar my tar file? or will that already be done? [15:29] sebner: Remember, not all syncs would have broken FF. [15:30] sebner: It's still possible to pull some syncs, and pre-Lenny release, it's likely that most of them are safe. [15:31] make[1]: Entering directory `/tmp/test/quentusrex-0.01' [15:31] make[1]: *** No targets specified and no makefile found. Stop. [15:31] 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] persia: I know, I'll check which of my syncs are worth a FFe [15:31] quentusrex: You're probably calling make for some reason. Don't do that. [15:32] Essentially, the stuff dh_make generates for you is mostly useless. [15:32] (especially for a package that need not be built) [15:34] persia, How do I tell my package to untar the orig file? it says it can't find it... [15:34] or should I assume it's already untared. [15:34] ls [15:34] quentusrex: your package would be a single binary [15:35] quentusrex: dpkg-source unpacks the .orig.tar.gz and applies the .diff.gz on top of it [15:35] where does it unpack it? [15:35] relative to the debian/rules file? [15:36] debian/rules is in the .diff.gz, so it doesn't exist before unpacking [15:36] so I don't need to unpack the source? just: cd ../ ? [15:36] quentusrex: it really depends on what you're doing [15:37] if you want to unpack the source, unpack it [15:37] if you want to build the source, build it [15:37] if you want to build the binary package, build it [15:37] well, I don't have any source [15:37] that'd be a problem [15:37] I have jpg's in a tar.gz [15:37] I want to untar them [15:37] then cp them to a folder. [15:37] the last part is your problem [15:37] but I dont' know the relative path to the files. [15:37] what you need is either a packed or unpacked source package [15:38] "cp them to a folder" is part of the binary package building processs [15:38] right [15:39] Argh... this is difficult... [15:39] quentusrex: the tar with your jpgs is the source [15:39] there are some fundamental things you need to understand first, right [15:39] I start with a folder called 'quentusrex' and in that folder I have my jpgs. [15:40] ok [15:40] the package guide says to tar zcvf the folder [15:40] you already did that no? [15:40] eh [15:40] it's named quentusrex-0.01.tar.gz [15:40] nm [15:40] I've got that. [15:40] ok [15:40] then I'm suppose to cp that to quentusrex_0.01.orig.tar.gz === bastiao_ is now known as k0p [15:40] did that. [15:40] ok [15:41] now in my current folder I have the folder quentusrex and the two tar.gz's [15:41] I run dh_make [15:41] in the quentusrex folder? [15:41] cd debian [15:41] no [15:41] in my working folder [15:41] /tmp/test [15:41] if that works, ok [15:41] the debian folder needs to be under the quentusrex folder in any case [15:41] right [15:41] it is [15:42] it's actually quentusrex-0.01 [15:42] just to keep things accurate. [15:42] alright, [15:42] I cd into debian [15:42] 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] rm *.ex *.EX [15:43] http://upload.wikimedia.org/wikipedia/en/7/77/Ubuntu_8.10_Alpha_1.png <-- What?! [15:43] This is the new default theme? [15:43] yes, I have them azeem [15:43] ok [15:44] in /tmp/test ls gets me this: [15:44] quentusrex-0.01 quentusrex_0.01-1.dsc quentusrex_0.01-1_source.changes quentusrex-0.01.tar.gz [15:44] quentusrex_0.01-1.diff.gz quentusrex_0.01-1_i386.build quentusrex_0.01.orig.tar.gz [15:44] 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] quentusrex: cd quentusrex-0.01, then run dh_make from inside there [15:45] RainCT_, I've done that. [15:45] Well, I just hope the new default theme won't feature light text on a dark background. [15:45] I've edited the changelog, control, [15:45]