[12:23] <TheMuso> Gotta love it when a build fails because a command segfaults.
[12:23] <TheMuso> On an architecture that hardly anyone is likely to h ave.
[12:24] <TheMuso> have
[12:28] <geser> ScottK: set DEBEMAIL to your Ubuntu mail address and dpkg-source won't build a source package with an unchanged maintainer
[12:29] <ScottK> geser: And then I couldn't sign the package because that address isn't on my key.
[12:30] <geser> than add it to your key :)
[12:31] <TheMuso> c
[12:31] <TheMuso> ugh
[12:32] <geser> TheMuso: the gs segfaults on IA64?
[12:32] <TheMuso> geser: the ps2pdf command seems to actually for ecasound2.2, which I synced from Debian.
[12:33] <TheMuso> So the package builds, yet the docs fail because of that command segfaulting.
[12:33] <geser> I've seen it for one of my syncs too
[12:34] <TheMuso> ah ok
[12:36] <vorlon> that gs bug is since fixed in Debian
[12:36] <geser> cool
[12:37] <TheMuso> gs? What package is that?
[12:37] <TheMuso> its one of the tex ones isn't it?
[12:38] <geser> !info ghostscript gutsy
[12:39] <ubotu> ghostscript: The GPL Ghostscript PostScript/PDF interpreter. In component main, is optional. Version 8.60.dfsg.4-0ubuntu1 (gutsy), package size 696 kB, installed size 3248 kB
[12:39] <geser> TheMuso: that one
[12:39] <TheMuso> ah
[01:26] <Nafallo> !ask
[01:26] <ubotu> Don't ask to ask a question. Just ask your question :)
[01:30] <ajmitch> 454 packages upgraded, 0 newly installed, 3 to remove and 38 not upgraded.
[01:30] <ajmitch> Need to get 407MB of archives. After unpacking 15.6MB will be freed.
[01:30] <ajmitch> something tells me that I've been lazy in updating
[01:34] <leonel> ajmitch: and we are not using 14400kbps  modems ...
[01:34] <leonel> plop
[01:34] <leonel> 14400bps
[01:37] <ajmitch> it feels like it here at times
[01:43] <TheMuso> c
[01:43] <TheMuso> ugh
[01:47] <nixternal> how much hard drive would I need to create a mirror at home for main/restricted/universe/multiverse?
[01:51] <StevenK> nixternal: For which releases?
[01:51] <StevenK> nixternal: And which arches?
[01:51] <nixternal> gutsy at a minimum x86
[01:52] <ajmitch> source?
[01:52] <StevenK> nixternal: ~ 12Gb, with no source
[01:53] <nixternal> well I would like to have source as well at least for main and universe
[01:54] <nixternal> StevenK: that is about 24gb then?
[01:54] <StevenK> Actually, it's about ~ 52
[01:54] <nixternal> I had a plan of why I wanted to do that, but I can't remember now :)
[01:55] <nixternal> I would download the majority during class to an external USB drive and then just rsync that drive at home
[01:56] <StevenK> My plan gives me free downloads between midnight and midday.
[01:57] <ajmitch> that's useful
[01:57] <ajmitch> I suppose I should fix coreutils now that I found a patch for it
[02:01] <ScottK> leonel: If you have a moment, would you please see if you can build/test https://launchpad.net/ubuntu/+source/clamav/0.88.7-1ubuntu1 and https://launchpad.net/ubuntu/+source/clamav/0.88.4-1ubuntu2.1 unmodified on Dapper.  Since this clamav project is going to take a while, I thought it might be useful to go ahead and backport the best 0.88 we can.
[02:01] <ScottK> Oops.  Sorry about that leonel
[02:01] <leonel> ScottK: :)
[02:03] <calc> ScottK: what was the clamav question?
[02:04] <leonel> everyday I found new  things and packages in lauchpad   it's  HUGE !
[02:20] <RickH> Anyone feel like helping me with something related to GDK+ 2.0?
[02:20] <joejaxx> nice i just prevented a ubuntu delta in fluxbox
[02:22] <RickH> I'm wondering why I can't pass class::function as a G_CALLBACK()?
[02:22] <RickH> like G_CALLBACK(whatever::foo) where "whatever" is a valid class and "foo" is a valid member function.
[02:27] <RickH> Ah!  It has to be declared static in the class.  Got it. :)
[02:29] <TheMuso> Morning RAOF.
[02:32] <RAOF> Morning TheMuso 
[02:42] <leonel> ScottK: Done  
[02:43] <leonel> 88.7 failed    88.4 no problems  all builded  and tested with  clamsmtp  and  clamassassin
[02:51] <persia> ScottK: Great.  Glad to hear it.
[03:09] <TheMuso> lol
[03:12] <StevenK> Fujitsu: It tells libtool to not make "smart" decisions.
[03:13] <persia> Frustratingly, it appears that gutsy lintian has decided to tell me "bad-distribution-in-changes-file gutsy".
[03:14] <Fujitsu> StevenK: Really?
[03:14] <StevenK> Fujitsu: I think so.
[03:14] <Fujitsu> Heh.
[03:15] <StevenK> Ah, I know what it does. If Libtool is a fool, it doesn't add rpath's to binaries.
[03:16] <Fujitsu> Ahh.
[03:17] <TheMuso> c
[03:17] <TheMuso> ugh
[03:18] <RAOF> :D
[03:19] <persia> TheMuso: If you have a minute, would you mind looking at http://revu.tauware.de/details.py?upid=5975 (ubuntustudio-screensaver)?  I think it's ready for upload :)
[03:19] <TheMuso> persia: Just saw that, will do.
[03:19] <persia> TheMuso: Thanks.
[03:29] <TheMuso> persia: Maybe we should run this GPL with SA by some archive admins, to be sure.
[03:29] <TheMuso> I'd rather not upload and have it rejected because of that.
[03:30] <TheMuso> As it reflects badly on us.
[03:30] <persia> TheMuso: About 8 hours ago, tsmithe told me that he had such a discussion, and received specific approval.  Let me see if the followup update the the wiki has happened yet...
[03:30] <TheMuso> persia: Ok.
[03:32] <persia> TheMuso: Doesn't appear official yet.  Depends on how much you trust hearsay :)
[03:32] <TheMuso> Right.
[03:32] <ScottK> persia: The successful build log is http://launchpadlibrarian.net/8417088/buildlog_ubuntu-gutsy-i386.pypolicyd-spf_0.4-2ubuntu2_FULLYBUILT.txt.gz - Thanks again.
[03:33] <persia> ScottK: I was looking at that about an hour ago, and it suddenly occurred to me that using debian/install might have been a cleaner solution - probably not worth an upload though :)
[03:33] <TheMuso> So... Where do we go from here re sconz and FTBFS?
[03:34] <persia> TheMuso: We can either wait until the upstream bug is fixed, or modify the scons scripts to not actually rely on the exported environment (or better, not export the environment).
[03:34] <ScottK> leonel: keescook recommends we try for 0.88.7, so we should try and make it work (It's probably the same debian/control changes needed for 0.9x).
[03:35] <TheMuso> persia: Right.
[03:35] <TheMuso> I guess it depends on how quickly upstream are likely to fix it.
[03:35] <ScottK> persia: There's always the next upstream.  I'm interested in your suggestion.
[03:37] <persia> ScottK: Read the dh_install manpage for details, but my memory is that the debian/install file is parsed, with each line as a whitespace delimited list, and it calls `install -m 644 $1 $(DEB_DESTDIR)/$2` for each entry.
[03:38] <persia> (or debian/$binarypackage.install if appropriate)
[03:44] <ScottK> persia: OK.  I'll have a look.  Thanks.
[03:46] <persia> ScottK: The advantage here being that with a well drafted dirs and install file, you may be able to avoid a custom rule in some cases.
[03:50] <ScottK> Makes sense.
[03:54] <TheMuso> persia: Just uploaded -screensaver.
[03:54] <persia> TheMuso: Excellent.  I'm just waiting to hear back from tsmithe regarding the sounds README, and we should have the whole set.
[03:56] <TheMuso> persia: Right, then I just have to do -default-settings, which I am still mulling over, because of a few hacks it has in it. UbuntuStudio needs these hacks, but I don't know how we should take care of one of them, and the other had a clean alternative written up in a spec for sevilla, which didn't get looked at.
[03:57] <persia> TheMuso: Oh right.  Do you have a pointer to the spec?
[03:57] <TheMuso> persia: Just a sec.
[03:59] <TheMuso> persia: https://wiki.ubuntu.com/DerivCustomSoundThemes
[03:59] <ryanakca> Umm, CDBS question. I need to gzip -9 the manpages because upstream hasn't. `GZIP="-9 --name"; export GZIP` would do it in a shell (at least I think it will, according to "Environment" in gzip(1)). How would I do so in CDBS
[03:59] <ryanakca> ?
[04:00] <TheMuso> ryanakca: debhelper/dh_installman does that afaik.
[04:00] <TheMuso> Or dh_compress, can't remember which.
[04:00] <TheMuso> cdbs/debhelper handles that.
[04:00] <ryanakca> #debian-mentors has proposed `GZIP="-9 --name" $(MAKE) build` for debhelper
[04:01] <persia> ryanakca: Try it without that.  If it doesn't work, try it with that.  When you get a package you like, smile.
[04:01] <ryanakca> TheMuso: hmmm. Well, what happens is that 'make' extracts two manpages from aoeui.m4, using m4. Then it installs those manpages to the required directory. will dh_compress still work?
[04:02] <ryanakca> persia: without the GZIP line, I get: http://pastebin.ca/613197
[04:02] <persia> TheMuso: That makes sense to me, but the translations are a sticky bit: the person who would be most likely to make the corresponding changes to the gnome package is very sensitive to changes that cause translations not to be perfect.
[04:02] <TheMuso> persia: Yeah I know.
[04:03] <ryanakca> persia: with it, I get the same thing
[04:03] <TheMuso> ryanakca: Most packages in the archive simply install manpages. I don't believe they gzip them as well.
[04:03] <persia> TheMuso: everything not already gzipped gets gzipped during package build.  This is an odd and annoying case.
[04:03] <ryanakca> TheMuso: according to policy, they need to be gzipped.
[04:04] <Fujitsu> There isn't a single one on my system that isn't, and it's required by policy.
[04:04] <TheMuso> ryanakca: For the built package, yes, and they get gzipped when the package is built.
[04:04] <persia> ryanakca: You could brute-force it by patching the upstream makefile to not gzip, and leaving that to debhelper.  Other solutions are so heavily dependent on the upstream build system that a patch is probably easier than finding the right magic variable.
[04:05] <TheMuso> dh_compress says it compresses man pages.
[04:05] <ryanakca> TheMuso: yes, but, in this case, it's not dh_compress that's installing the manpage, it's the Makefile and make
[04:05] <hendrixski> is there a faster way to make a patch than dpatch-edit-patch if I've already made (and tested) the changes that I want to include in a patch?
[04:05] <jamman> hey all.
[04:06] <TheMuso> ryanakca: Right.
[04:06] <jamman> so is there any way i can contribute with web servering?
[04:06] <ryanakca> persia: hmm. the upstream makefile doesn't gzip already, wait. could I have debhelper install the manpage if it's already located in debian/aoeui/usr/share/man/man1/ ?
[04:07] <TheMuso> I know dh_compress doesn't install anything. I was getting confused, I thought you needed to gzip them, whereas you want to preven the makefile from doing it
[04:07] <ryanakca> persia: and as such, it would compress it?
[04:07] <persia> hendrixski: Depends on the patch system.  With dpatch, you'd want to extract the changes (with diff -urN) into a patch, start dpatch-edit-patch to get the patch environment, apply your custom patch, and exit to quickly generate the dpatch.
[04:08] <ryanakca> TheMuso: makefile installs them uncompressed. maybe I'm communicating properly... shall I get you a link for you to examine?
[04:08] <hendrixski> persia, ah... so I don't have to manually redo the changes in dpatch-edit-patch.. I can just run a diff command that would apply them?
[04:09] <persia> ryanakca: I would think that an uncompressed manpage in $(DEB_DESTDIR)/use/share/man/man1 would be compressed by dh_compress automatically.  If this doesn't work, you could delete it in build, and use debian/$package.manpages, but this probably isn't preferred.
[04:09] <persia> hendrixski: You'll want `patch` to apply the output of `diff`, but basically, yes.
[04:10] <ryanakca> persia: $package.manpage ? Where does that come from? hmm. I could also just have rules run gzip on them...
[04:10] <ryanakca> but wouldn't that mean that I'd have to stick gzip in build-depends?
[04:10] <persia> ryanakca: debian/$package.manpages may be created by a maintainer to automatically install and compress manpages that are not installed by the upstream build system.
[04:11] <ryanakca> persia: ah. well, upstream installs them, just uncompressed.
[04:11] <hendrixski> persia, 'cause I got really confused with that patch environment I was like "oh man.. I gotta redo all this stuff."   LOL
[04:11] <persia> ryanakca: I'm fairly sure gzip is build-essential, so you shouldn't have to worry (how else could the buildd tar xzf or uncompress diff.gz)?
[04:11] <ryanakca> persia: yeah, ok
[04:12] <ryanakca> persia: thanks :)
[04:12] <persia> ryanakca: Upstream is installing them uncompressed?  Does dh_compress not fix this?
[04:12] <ryanakca> persia: apparently not
[04:12] <minghua> ryanakca: What exactly is your question?  Is there anything dh_compress failing to do?
[04:12] <ryanakca> persia: or wait, upstream is installing them compressed, but not compressed to the maximum level
[04:13] <ryanakca> minghua: ok. lintian -i on the deb outputs this: http://pastebin.ca/615335
[04:14] <persia> ryanakca: That's what I thought: it makes more sense given your error, and explains why it's not recompressed.  Either hunt down the magic variable for the upstream Makefile, patch the upstream Makefile, or delete in debian/rules and install with debian/$package.manpages.
[04:14] <minghua> Hmm.  I didn't know policy requires maximum compression level.
[04:14] <Fujitsu> minghua: Any objections to syncing the various bits of geda 20070626? We've had a couple of requests, AFAIK.
[04:14] <minghua> Outdated policy and should be abandoned, IMHO.
[04:14] <ryanakca> minghua: I wrote this patch to fix it, but Debian says it's too dirty and that I should somehow find a magic variable threw trial and error: http://revu.tauware.de/revu1-incoming/aoeui-0707111425/aoeui-1.0.3/debian/patches/01-gzip-manpages.patch
[04:14] <persia> minghua: Current policy prefers preservation of bandwidth to preservation of user CPU.
[04:15] <ryanakca> s/Debian/sponsor in #debian-mentors/g
[04:15] <minghua> Fujitsu: I know nothing about geda.  So I supposed no objections.
[04:15] <Fujitsu> Great, just checking.
[04:16] <hendrixski> persia, I just re-read the parts of the manual that were confusing me and it suddenly makes sense.... thanks :-)
[04:16] <ryanakca> persia: where would I put the magic variable in a CDBS rules?
[04:16] <hendrixski> your explanation was like the missing key
[04:17] <minghua> Fujitsu: To pump your karma number, perhaps? ;-)
[04:17] <persia> ryanakca: That's an interesting question.  Hold on whilst I look at your rules and upstream Makefile...
[04:17] <ryanakca> persia: thanks
[04:20] <persia> Well, that's ugly.  The manpages aren't actually created until make install is called.
[04:22] <ryanakca> persia: hehe :)
[04:22] <persia> ryanakca: IF you're doing this with a shell variable, you'll want to export it in build/aoeui::, but that's somewhat counterintuitive to a reader.
[04:23] <ryanakca> persia: upstream said they'd fix it in next release
[04:23] <ryanakca> persia: but... he said he'd only release it when he gets back from his holidays/vacation
[04:24] <TheMuso> wow. New packages aren't announced to gutsy changes.
[04:24] <persia> ryanakca: How are they fixing it?  gzip -9, the use of $(GZIP) instead of gzip (so you can pass an override), or installing the bare manpages, and expecting it to be addressed by the packaging?
[04:24] <ryanakca> persia: no clue, never asked
[04:24] <persia> TheMuso: That sounds like a bug.
[04:25] <persia> ryanakca: It's worth checking.  Perhaps you can pull their fix from upstream, use a patch, and report that the patch was pulled from upstream in the changelog: that might be dirty for now, but shows it will be much cleaner soon.
[04:25] <ryanakca> persia: yeah
[04:25] <ryanakca> hmm.
[04:27] <ryanakca> persia: He's already fixed it in SVN http://aoeui.svn.sourceforge.net/viewvc/aoeui/Makefile?view=markup
[04:28] <persia> ryanakca: I still think that's not what make install is supposed to mean, but it looks like your patch was applied.  Check with your sponsor to see if a patch "pulled from SVN" is an acceptably clean solution to the issue.
[04:29] <ryanakca> persia: hmm. since the patch is identical to the one created when comparing upstream to current, except for the version line, *nod*
[04:32] <ryanakca> persia: 22:31:11 < pabs> ryanakca: I'd say use GZIP until that version is released and then drop GZIP 
[04:32] <Pici> Quick question, I'm filling out a bug report for something and I want to suggest that the package install prompt the user to reboot, is there a technical name for that?
[04:33] <ScottK> Pici: WIndows
[04:33] <ScottK> Why is a reboot needed?
[04:33] <Pici> ScottK: :p
[04:33] <persia> ryanakca: Well then, you'll want to put it in build/aoeui::.  Expect to explain how the upstream makefile is broken, so it really is correct to define the shell variable post-build / pre-install rather than pre-build.
[04:33] <Pici> ScottK: need udev to assign a group to /dev/fuse
[04:34] <persia> Pici: Can't you do that in the postinst?
[04:35] <Pici> persia: I would assume so. Correct me if I'm wrong (
[04:35] <TheMuso> Hobbsee:!!!
[04:35] <Hobbsee> hey TheMuso!
[04:35] <Pici> er, darn enter key, but i'm not a udev guru, is a reboot required for a udev rule to be put into effect?
[04:35] <persia> Pici: Right.  So instead of rebooting, just make the necessary calls to udev, and don't bother the user.
[04:36] <Pici> persia: good point, Its just a confirmation that the fixed worked anyway, I was going to make the suggestion, but I guess it isnt needed.
[04:36] <minghua> Pici: If the package doesn't assign a group to /dev/fuse (not that I really know what it means) until a reboot, report a bug saying so.  You don't need to have a suggestion fix to report a bug.
[04:37] <persia> minghua: It's more that dh_installudev doesn't automatically reinitialise already connected devices.  It works great for USB, but is a little more complicated for other things...
[04:38] <Pici> I'm not pretending to know how it works. Anyway, is there a technical name for the reboot suggestion that comes up when, for example, a new kernel is installed?
[04:38] <Fujitsu> I think it just touches some file in /var
[04:38] <persia> Pici: Yes, but you don't want to ask for a reboot (like the kernel and libc6 do): there's really no need for a udev rule modification.
[04:38] <ScottK> Pici: You're on the wrong track here.  Just report the problem about the udev group.
[04:39] <Fujitsu> my $notifier          = "/usr/share/update-notifier/notify-reboot-required";
[04:39] <Pici> ...  I know, I'm not going to mention the reboot thing.   for the sake of my own curiousity..
[04:40] <persia> Pici: Fujitsu's answer should satisfy your curiosity
[04:40] <Fujitsu> Running that as root touches /var/run/reboot-required, which update-notifier picks up.
[04:41] <Pici> Fujitsu: Ah, thanks :)
[04:42] <Fujitsu> ScottK: Like?
[04:43] <minghua> Well, /var/run is 644, so you need root to touch things in it anyway.
[04:43] <ScottK> If there's one user you don't like you can wire pretty much anything they want to do to require a reboot.
[04:43] <Fujitsu> Hah.
[04:43] <ScottK> Right, I'm thinking from a BOFH perspective.
[04:43] <Pici> And prompting the user to reboot is pretty lame compared to the other things you could maliciously do as root.
[04:43] <Pici> Ah.
[04:44] <ScottK> Yes, but the annoyance factor is high.
[04:44] <persia> ScottK: Wouldn't it just be better to give them a special shell with `sleep 120 &&` prepended to all command executions?
[04:44] <ScottK> Plus you can say, "Well let me log on and try it ...  See, works fine for me."
[04:44] <ScottK> Not random enough.
[04:45] <ScottK> Want to save that file, sorry, need to reboot first.
[04:45] <persia> ScottK: the file is only a suggestion.  I've gone up to 4 days ignoring it before I lost stability :)
[04:46] <ScottK> Sure, but the likely victims wouldn't necessarily know that.
[04:46] <ScottK> Plus that gives you a good finally...
[04:47] <Fujitsu> Testing exact repricing of multi-step constant maturity swaps and swaptions in a lognormal constant maturity swap market model...
[04:47] <ScottK> "you actually rebooted before saving, how did you think that was going to work, the reboot thing is only a suggestion anyway, you $CURSEWORD."
[04:47] <ajmitch> yay, dbs
[04:47] <Fujitsu> That is one of quantlib's self-tests, supposedly.
[04:48] <Fujitsu> ajmitch: Where? Let me kill it.
[04:48] <persia> ajmitch: The djangoified missing-bugs list looks great.  Should I be targeting that server, or is it moving soon?
[04:49] <ajmitch> persia: it'll move, that's my home box
[04:49] <persia> ajmitch: Ah.  In that case, I'll not clog your DB :)
[04:53] <Fujitsu> How hard would it be to hack a comments field into debcheck?
[04:55] <persia> Fujitsu: Does the combination of filed in-progress bugs and apt-cache -i unmet not meet your needs?
[04:55] <Fujitsu> persia: That doesn't do multiple archs.
[04:56] <persia> Fujitsu: True, but I suspect it's a rare case (excepting FTBFS) where an unmet dep only applies to a subset of the architectures.  Most of those are probably related to an NBS somewhere.
[04:57] <Fujitsu> http://alt.qeuni.net/~william/debcheck/ begs to differ
[04:57] <Perdente> ok so this is probably the most noob thing to say, but where would I start if I wanted to work on a gtk or kde app or add some code to one or code for anything for that matter
[04:58] <Perdente> I mean I have the libraries and have tinkered with gtk and kde and know kind ahow they work right now, just don't know what project to work on/with
[04:59] <RAOF> You could come and join NotiFrenzy/Specto/VCSFrenzy :)
[04:59] <ScottK> Perdente: You could pick a bug that annoys you and try to fix it.
[04:59] <Perdente> lol RAOF sometimes you scare me
[04:59] <RAOF> Generally the way this works is that you find something that you want to work but doesnt
[04:59] <persia> Fujitsu: I'm having trouble actually seeing enough architecture-specific information from that to tell, but I suspect some of the differing numbers can be accounted for by differing build architectures for packages.
[05:00] <Perdente> ok and then look at the source code and tinker away
[05:00] <Perdente> duh... also I do really want to work on a dreamweaver equivalent for Ubuntu
[05:00] <RAOF> Yup.  Launchpad is always available for inspiration
[05:01] <Perdente> I was gonna call it webuntu or something lame like that
[05:01] <RAOF> Perdente: So, find an already existing project with similar goals, and fix things.
[05:01] <persia> Perdente: There are a number of web authoring tools already included: I'd recommend improving one of those rather than starting from scratch for a first project.
[05:02] <ScottK> Wasn't tonyyarusso working on packaging the son of the son of Nvu?
[05:02] <RAOF> Yes
[05:04] <hendrixski> if you're adding a graphic to a program... is it a good idea to put that in a patch?  or would that the patch just too big?
[05:05] <ajmitch> persia: it's quite common for unmet deps to be !i386, sadly
[05:05] <persia> ajmitch: Interesting.  Is this because of arch-indep skew?
[05:05] <ajmitch> often
[05:05] <ajmitch> or something just never builds on amd64, like psyco
[05:06] <persia> hendrixski: For a new graphic, it's often easier to include  uuencoded version in debian/ and uudecode & install manually during the install: rule.
[05:07] <persia> ajmitch: Lately the debian-release team seems to have been chasing those and NMU'ing architecture restrictions (not that we have a working automated binary remove system for universe).
[05:07] <ajmitch> coreutils ought to fail to build there as well
[05:07] <persia> Umm...  I like coreutils.  Please don't make it i386 only :)
[05:08] <ajmitch> persia: it fails to build on all platforms at the moment
[05:08] <ajmitch> just testing a patch now
[05:08] <persia> ajmitch: Ah.  That's better then.  Good luck.
[05:09] <ajmitch> patch is from upstream, just a simple function renaming
[05:09] <ScottK> persia: So how to we get rid on old binaries in Universe?
[05:10] <persia> hendrixski: See the flobopuyo package for an example
[05:11] <ScottK> Nevermind.  It remove itself according to LP.
[05:11] <persia> ScottK: https://bugs.launchpad.net/bugs/32460 is a good example of the process (it takes a while)
[05:11] <ubotu> Launchpad bug 32460 in supercollider "Please remove stale AMD64 supercollider binaries." [Medium,Fix released]  
[05:12] <persia> ScottK: There's automated removal for NBS binaries, as long as they are removed from all architectures.  For packages that are changed to build on only certain architectures, we accumulate cruft.
[05:12] <ScottK> Ah.  I see.
[05:13] <persia> ScottK: To sum up, I believe the process is 1) file a bug, 2) get someone to harass an admin in person (IRC doesn't seem to work)
[05:15] <Fujitsu> Surely they can generate lists of arch-NBSed cruft for us?
[05:16] <persia> Fujitsu: Sure, and code to check is in Debian.  It's implemented for main, and I've been told it's on the TODO for Universe, but it's not a high priority at this point.
[05:16] <Fujitsu> Lovely.
[05:17] <persia> More amusingly, some of the archive-admins are under the impression that it is handled by the auto-checking script for main, and so tend to ignore the binary removal bugs.
[05:17] <Hobbsee> useful
[05:17] <StevenK> NBS is semi-automatic, like importing from Debian.
[05:18] <persia> StevenK: NBS, yes.  arch-NBS?
[05:19] <ScottK> And then sits back down.
[05:20] <Hobbsee> ScottK: pressure them to open it - ask what you can do.
[05:20] <Hobbsee> if you really want to
[05:20] <persia> ScottK: There's nothing stopping you from running an analysis against a mirror of the archive :)
[05:20] <Fujitsu> persia: Where does Debian keep its version?
[05:20] <Hobbsee> but, i certainly cant speak on the matter, in current status.
[05:21] <persia> Fujitsu: I think it's somewhere deep in dak, but I'm not sure.  I do know that arch-NBS removals are auto-generated.  Let me see if I can find a little more detail...
[05:21] <ScottK> persia: True, but the most that could help me do is write bugs.
[05:21] <ajmitch> yay, coreutils built
[05:21] <ScottK> Yeah!
[05:21] <ajmitch> now I can run off & apply the patch elsewhere to get back to what I was doing
[05:22] <Fujitsu> persia: Ah, right, that'd make sense.
[05:22] <persia> ScottK: That's fine.  One of these days, with a big enough list, we can probably get an archive-admin to do some cleanup before release.
[05:24] <persia> Fujitsu: It appears to be something in melanie, from a quick look.
[05:25] <Fujitsu> I really think they should have given the dak binaries slightly better names.
[05:25] <StevenK> There's now a dak script that deals with that.
[05:25] <StevenK> 'dak ls' <-> 'madison', etc
[05:25] <Fujitsu> Ah.
[05:28] <persia> Fujitsu: I'm wrong.  melanie does the removal work: I think rene might give her advice.  Anyway, you'll probably get more information digging directly...
[05:30] <ScottK> But he'll probably get it with less effort if you dig.
[05:30] <Fujitsu> Thanks persia.
[05:31] <persia> ScottK: Not for a reimplementation, or modifications for Ubuntu.  Pointers are helpful, but I'm getting to the point where I need to follow code points to determine who is responsible, which knowledge is difficult to transfer over IRC.
[05:32] <ScottK> Yes, but my response was funnier than yours ;-)
[05:32] <persia> ScottK: True.
[05:38] <leonel> ScottK: edited  debian/control  for  clamav 88.7   builded  installed tested  all ok 
[05:39] <Fujitsu> It looks like do_anais in rene is what does the arch-NBS stuff, but it's very dak-specific.
[05:40] <persia> Fujitsu: Yep.  On the other hand, you could mirror the archive into incoming/ and pass it to jennifer :)
[05:41] <Fujitsu> I don't think it'd like the lack of .changes much.
[05:42] <ScottK> leonel: OK.  Hang onto that one.  I have to find out how I can do a source package backport.
[05:42] <ScottK> Thanks.
[05:42] <persia> Fujitsu: dpkg-genchanges?  Automating it might only catch the latest changelog entry, but it would at least allow processing.
[05:43] <Fujitsu> persia: Or we could just convince Canonical to run it over universe or release the code.
[05:43] <ScottK> leonel: Don't remove  source:Version, you have to edit it.  Look at the changes for my 0,90.3 dapper package.
[05:44] <persia> Fujitsu: Yep.  The first is probably easier.  I'll look to see who need a patch again (I've forgotten).
[05:44] <Fujitsu> We should probably process Debian removals regularly for a while longer too.
[05:44] <ScottK> leonel: Once you do that, please make a debdiff and either post it somewhere or e-mail it to me.
[05:44] <Fujitsu> persia: Do they actually use the bits of dak to do it?
[05:45] <persia> Fujitsu: Some, and a few of our own (Anastacia, Bridget, Geri, Kari, Heather, Hilarie, Lorraine, Poppy, and Teri).
[05:46] <Fujitsu> Where're you getting this information?
[05:46] <persia> Fujitsu: dak docs (mostly).
[05:48] <Fujitsu> persia: I don't think the Ubuntu-specific stuff would be there...
[05:48] <persia> Fujitsu: The stuff that's there is to avoid namespace collisions (many of the same parties are involved with both infrastructures).
[05:54] <persia> Fujitsu: http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html might be helpful.  I remember seeing a more useful URL pasted to #ubuntu-devel once, but I've lost it.
[05:56] <TheMuso> Ouch. OpenOffice update.
[05:57] <Fujitsu> TheMuso: You mean it built!?
[05:58] <TheMuso> Fujitsu: FOr feisty
[05:58] <Fujitsu> Ah.
[05:58] <ajmitch> people still run feisty?
[05:58] <TheMuso> Yes, they do.
[05:58] <TheMuso> I kinda have to atm, until I am ready to start using GNOME/Gnome-terminal more.
[06:00] <persia> Fujitsu: You might also ask someone what running archive-cruft-check without -n does (that's outside of what I can find).  I suspect this is the guilty script.
[06:01] <Fujitsu> persia: How do you know it is run with -n? I can't find any documentation on this stuff.
[06:02] <persia> Fujitsu: https://wiki.ubuntu.com/ArchiveAdministration is my source for -n.  For further information, I suggest full text searches of the wiki, and searches of the IRC logs from #ubuntu-devel (especially in the early days) and #ubuntu-meeting.
[06:02] <Fujitsu> Ah.
[06:02] <Fujitsu> It's all very well collected and easy to find, I see.
[06:02] <StevenK> Fujitsu: OO.o built for Gutsy, too.
[06:02] <Fujitsu> StevenK: Even on i386?
[06:03] <persia> Fujitsu: There used to be more, but the canonical wiki split made it a little harder to find things...
[06:03] <StevenK> #   gutsy ia64   Successfully built
[06:03] <StevenK> # gutsy i386 Successfully built
[06:03] <StevenK> # gutsy amd64 Successfully built 
[06:03] <StevenK> It failed on PPC, and is still building on sparc.
[06:04] <ajmitch> but noone cares about PPC anymore
[06:04] <ajmitch> so it's all fine
[06:04] <StevenK> Apple killed it.
[06:04] <TheMuso> Although it is nice that a few devs from the distro team have/use ppc.
[06:04] <TheMuso> Yeah I know. I've just grown fond of it.
[06:04] <TheMuso> X86 carried too much legacy crap.
[06:04] <TheMuso> s/carried/carries
[06:04] <StevenK> And now OS X has to deal with the baggage! Muahaha!
[06:05] <ajmitch> which >> 99.9% of people never see or care about
[06:05] <ajmitch> even in ubuntu, most of the legacy crap is hidden away
[06:05] <persia> ajmitch: They feel the speed difference.  It's like using a crusoe...
[06:05] <TheMuso> Yeah I know.
[06:06] <TheMuso> ppc hardware from a few years ago is still quite useful however.
[06:06] <ajmitch> persia: there's such a speed penalty running ubuntu on x86?
[06:06] <ajmitch> I would say that windows would qualify as x86 legacy crap
[06:07] <persia> ajmitch: For semi-equivalent hardware, yes.  It works on my 233MHz PPC, and not well on my 300MHz Pentium II.  Of course, I use amd64 for 99.9% of Ubuntu activities, so I shouldn't really talk...
[06:10] <StevenK> I wouldn't compare a 233MHz PPC and a 300MHz Pentium II, though.
[06:12] <persia> StevenK: Right.  I shouldn't get involved in architecture discussions anyway - there are too many reasons why X is different than Y.
[06:16] <joejaxx> lets say a version number already for an application looks like this: 0.0.1-1
[06:16] <joejaxx> for an application already*
[06:16] <joejaxx> how should the debianized version look like?
[06:16] <StevenK> 0.0.1-1-1
[06:16] <joejaxx> 0.0.1-1-0?
[06:16] <joejaxx> oh ok
[06:17] <joejaxx> i did not know if it was that simple
[06:17] <ajmitch> and upstream should be summarily shot
[06:17] <joejaxx> ajmitch: :P
[06:17] <StevenK> You can use dashes in the upstream version if you have a Debian revision. This is all laid out in Policy.
[06:18] <ajmitch> thumbscrews may help as well
[06:18] <Hobbsee> ajmitch: is feeling violent, today
[06:18] <ajmitch> Hobbsee: you have no idea what horrors I've seen in code today
[06:19] <Hobbsee> heh
[06:19] <ajmitch> the code in question predates us having the source in svn
[06:21] <Hobbsee> yummy...
[06:26] <leonel> ScottK: done http://paste.ubuntu-nl.org/29616/
[06:38] <joejaxx> ajmitch: i am packaging apf :)
[06:40] <persia> Just to verify: if a build process downloads a python module from the network during configuration, that's an automatic buildd failure, right?
[06:41] <ajmitch> joejaxx: that's really nice, but I have no idea what apf is or how it's relevant
[06:41] <joejaxx> ajmitch: advance policy firewall
[06:41] <ajmitch> ok..
[06:43] <minghua> persia: I don't think so.  But it's definitely bad behavior.
[06:43] <Fujitsu> The buildds don't have network access.
[06:43] <Fujitsu> (other than to an archive mirror)
[06:44] <persia> minghua: Hrm.  Is it actually a violation of Debian policy (as in I can file an RC bug), or is it (given Fujitsu's information) a candidate for a local Ubuntu change?
[06:45] <minghua> persia: I think it's against policy.  But I don't think it's automatic FTBFS.  I may well be wrong, though.
[06:46] <persia> minghua: Thanks.
[06:46] <minghua> BTW what python module are we talking about?  From some third-party website?
[06:46] <persia> minghua: http://cheeseshop.python.org/packages/2.5/s/setuptools/setuptools-0.6c5-py2.5.egg (and yes, directly from upstream).
[06:50] <ajmitch> oh, setuptools
[06:50] <minghua> Hmm.  It seems nowhere in the policy does it say "the source package must contain all the files used to build binary packages".
[06:51] <ajmitch> persia: I believe you can disable egg-fetching
[06:51] <persia> Odd, that.  I suspect it makes it non-DFSG-free due to the Desert Island test.
[06:51] <persia> ajmitch: I'll look at that.  Thanks.
[06:54] <Fujitsu> TheMuso: It is a baaad idea to request a sync of geda, but not the rest of its bits.
[06:55] <TheMuso> Fujitsu: Oh ok. I'll mark as invalid.
[06:55] <Fujitsu> TheMuso: Doing so now.
[06:55] <TheMuso> ok thanks
[06:56] <Fujitsu> I filed requests for all of geda* half an hour ago, anyway.
[06:56] <TheMuso> Ah ok.
[06:57] <Fujitsu> 5 minutes before you, in fact. Very nice timing.
[06:57] <Fujitsu> persia: Probably.
[06:57] <Hobbsee> yay, karma-that-does-nothing!
[06:57] <lifeless> duplicate nuber
[06:58] <Hobbsee> hi lifeless!
[06:58] <Fujitsu> Hobbsee: Wrong! It gives you extra ShipIt CDs if you have > 0, AFAIK.
[06:58] <Fujitsu> lifeless: Nah, that makes too much sense.
[06:58] <Hobbsee> well, that's not hard
[06:59] <Fujitsu> Aw, doko is catching up to my bug-karma.
[07:00] <TheMuso> Fujitsu: I think it was a case of your bug not showing when I checked, before I filed.
[07:00] <minghua> Fujitsu: Are you serious?  ShipIt CD numbers differ by person?
[07:00] <Fujitsu> minghua: As of Feisty you get an extra option if they deem you have contributed enough.
[07:00] <Fujitsu> And a friend with 2 karma got that option...
[07:01] <StevenK> Where the extra option is 10 CDs.
[07:01] <Fujitsu> Right.
[07:01] <minghua> Interesting.  I may ask for ShipIt CD one day.  Probably gutsy+1 since it's LTS, now that I think about it.
[07:03] <Fujitsu> Only 2x i386 for Warty and 1x i386 Edgy, but a full set for the others.
[07:04] <StevenK> I leave one set in my drawer and use them when I need.
[07:04] <Fujitsu> I get a few for each release.
[07:04] <minghua> I am lazy to check -- are alternative CDs included in ShipIt set?
[07:04] <Fujitsu> minghua: No.
[07:04] <Fujitsu> Just desktops since Dapper.
[07:06] <minghua> Hmm.  Then I'd better confirm that desktop CDs support LVM before I ask for them.
[07:06] <Fujitsu> RAOF: That has been specced for a couple of releases now, AFAIK.
[07:06] <Fujitsu> minghua: It doesn't yet.
[07:06] <minghua> Otherwise they are just Live CDs for me.
[07:06] <minghua> Fujitsu: I know it doesn't for feisty.
[07:06] <RAOF> And doesn't for gutsy
[07:06] <minghua> Bad news. :-(
[07:06] <RAOF> At least, as of now.
[07:07] <RAOF> Fujitsu: Yeah, I know.
[07:07] <Fujitsu> Ubiquity is sort of not being touched much lately.
[07:09] <TheMuso> Until they are no longer available.
[07:12] <Fujitsu> LVM is very loved in Feisty, obviously. Still not supported on the Desktop CD, and the alternate involves a lot of waiting and hoping you won't have to install the system manually.
[07:13] <Flannel> Waiting?  There's the LVM delay issue, but nothing wrong with it
[07:13] <Fujitsu> Flannel: Sometimes it will fail to install the base system.
[07:13] <Fujitsu> It doesn't seem to be predictable, but only occurs with LVM as far as I know.
[07:14] <RAOF> LVM broke at the very start of the Feisty cycle, and hasn't since.  For me, at least
[07:14] <Fujitsu> It works fine except for the installer.
[07:14] <RAOF> Oh.  Fair enough.
[07:14] <Fujitsu> And apparently coupling it with md is flaky, though I'm using it fine on two boxes at school.
[07:15] <tonyyarusso> ScottK: Yes, I was working on packaging Nvu's new incarnation.  Unfortunately, I have been completely unable to reach the developer for the last few months, so have completely stalled on that task.
[07:16] <tonyyarusso> beats me
[07:16] <tonyyarusso> Kaze promised me a 0.8 release back in March.  Still no sign of it.  (we're at 0.7.7 now)
[07:17] <tonyyarusso> There is a second dev registered on sourceforge though
[07:17] <tonyyarusso> Maybe he'll grab it and run with it someday
[07:18] <StevenK> Wasn't Kompozer or it's prior name removed?
[07:18] <Fujitsu> StevenK: nvu? Yes.
[07:18] <tonyyarusso> That was the word on the street from the guys at Linspire (trademark holder on Nvu), but Kaze claimed to know nothing of it.
[07:18] <Fujitsu> `This has made a lot of people very angry, and been widely regarded as a bad move.'
[07:18] <RAOF> :)
[07:19] <tonyyarusso> Fujitsu: source?
[07:19] <Fujitsu> Well, a lot of people were unhappy that nvu had vanished, and I had to fit in a HHGttG quote somewhere.
[07:19] <tonyyarusso> ah
[07:26] <tonyyarusso> Do we know anyone who could help code it?
[07:27] <RAOF> Perdente was just in here wanting a project :)
[07:27] <tonyyarusso> nice
[07:28] <tonyyarusso> Guess they found one
[07:34] <\sh> moins
[07:35] <imbrandon> moins \sh 
[07:37] <tbf> hmm.... seems launchpad has problems?
[07:38] <RAOF> Not for me, it seems
[07:38] <tbf> RAOF: well, getting timeouts when searching
[07:54] <tbf> http://revu.tauware.de/
[07:54] <tbf> "The ****Utnubu**** team would be more than happy to help you to get started."
[07:55] <ajmitch> yes, that's not a typo
[07:56] <tbf> ajmitch: really!?
[07:56] <ajmitch> see the link
[07:56] <tbf> indeed.... its ubuntu reversed
[08:12] <ScottK> So if a package has a copyright disclaimer (I can tell by the xml tag) in Urdu, it's not unreasonable for me to just assume it says the same thing as the equivalent English file, right?
[08:14] <persia> ScottK: When it comes to copyright, assumptions are bad.  What is the Urdu?
[08:14] <ScottK> persia: It's in zekr on REVU.
[08:14] <ScottK> It's also got Turkish and some others.
[08:15] <ScottK> grep -i -R copyright is always fun.
[08:15] <ScottK> Actually my wife has some Urdu if that was all it was.
[08:17] <persia> ScottK: Do you mean the res/lang/foo.xml files?  I think it's safe to say these are translations, and should be expected to be correct.
[08:18] <ScottK> Yes.  OK then.
[08:19] <ScottK> persia: You might want to take a look at zekr.  It's not ready for upload, but doesn't totally suck.
[08:20] <persia> ScottK: I'm looking now.  I still think that the text should be split in the manner of the sword packages, as I don't see any reason to require Java to study, and don't see the purpose of multiple copies of the text, but at least most of the copyright issues appear to have been addressed.
[08:23] <persia> ScottK: It's the collection of study / search / analysis interfaces for the collection of bibles.
[08:31] <ScottK> Ah.
[08:37] <persia> Hmmm..  I'm really not sure about carrying a local patch to change the text of the Quran.  That sounds less than ideal, somehow...
[08:37] <ScottK> Agreed, but it's not a packaging issue.
[08:38] <persia> ScottK: Are you sure?  it's a local patch in the packaging.
[08:38] <ScottK> If the patch applies, sure, but not the theological impact of the patch.
[08:39] <ScottK> All the patches apply when you build it BTW.
[08:40] <ScottK> persia: debian/zekr.sh has got to go.  Is there an easy way to find out if there is a package that provides a useable gecko engine installed?
[08:41] <persia> ScottK: OK.  I accept that the theological implications of the patch are outside the purview of packaging.
[08:41] <persia> ScottK: I have no idea - perhaps ask a member of the mozilla team? (they seem to be more active in your timezones than mine)
[08:41] <ScottK> hmmm you mean like right now?
[08:42] <ScottK> Do they have an IRC channel?
[08:42] <persia> ScottK: #ubuntu-mozilla, but I usually see them active just before I sleep
[08:43] <Hobbsee> i'm not sure that you should be patching any theologoical book like that....
[08:43] <ScottK> No one home right now.
[08:43] <persia> Hobbsee: Right, but are the theological implications part of a packaging review?
[08:43] <Hobbsee> persia: well, at least a question about "why are you doing this?" yes
[08:44] <Hobbsee> persia: being that the packager is responsible for what's going into the archive
[08:44] <Hobbsee> you have to look why it's there, etc - is it there as a resource, or what?
[08:44] <Hobbsee> ie, is the potential user going to take it as a credible source, etc?
[08:44] <ScottK> It looks like they picked a different default translation.
[08:45] <ScottK> Hobbsee: Any idea then how we find out if this is truly the quran or an extremist revision?
[08:45] <Hobbsee> ScottK: no idea.
[08:45] <Hobbsee> ask someone who speaks it.  find a copy of teh quran, and diff it.  not sure there.
[08:46] <ScottK> Reading the blog of the lead developer ought to at least give a hint.
[08:47] <persia> (It would also be nice if I knew the appropriate link to an equivalent international organisation)
[08:48] <ScottK> Actually I know some people I could ask to look at it.
[08:48] <persia> ScottK: Regarding debian/zekr.sh: there's also references in ./build.xml.  This probably needs a closer look by someone familiar with mozilla & java...
[08:49] <ScottK> It looks like the main purpose of it is to find out if you have gecko installed through some just not right way to do it.
[08:49] <ScottK> Did you know there is an Ubuntu Muslim Edition?
[08:49] <ScottK> www.ubuntume.com
[08:50] <persia> ScottK: I believe zekr was originally extracted therefrom.
[08:50] <ScottK> It's included there.
[08:50] <ScottK> Ooh.  And they have forums too.
[08:58] <TheMuso> persia: I've run into that limitation several times.
[08:58] <persia> TheMuso: It's not even enough for lintian & linda output for most packages...
[08:59] <TheMuso> Yup.
[08:59] <Fujitsu> persia: Convince somebody to make the DB use TEXT, or at least a larger VARCHAR.
[09:00] <persia> Fujitsu: By somebody, I expect you mean someone with real management access to the DB server and the code, but I suspect they are all focused on the next revision (or, based on other sources, are instead busy with other things).
[09:02] <Fujitsu> persia: Nobody has touched REVU2 in about a year, and the change shouldn't be difficult.
[09:02] <Fujitsu> Probably won't even need a code change.
[09:03] <persia> Fujitsu: Hmm...  Probably best to discuss this in about 8 hours, when the most interested party is likely to be around.
[09:03] <Fujitsu> Most probably.
[09:10] <persia> Cool!  sbuild accepts a dget'able URL as an argument :)
[09:11] <Fujitsu> persia: Really? Nice!
[09:11] <RAOF> Wicked.  It also uses lvm snapshots, right?  I'll need to set that up :)
[09:12] <persia> Fujitsu: Yep.  I just had a paste mistake, and it worked anyway :)
[09:12] <persia> RAOF: If can, or it can use standard chroots, as you like.  snapshots are fast :)
[09:13] <RAOF> Yeah, that's what I was after.
[09:14] <StevenK> I still find sbuild a little fragile. It sometimes fails to create the snapshot with no error.
[09:15] <Fujitsu> StevenK: I've never had that. The only issues I've had recently have been when devmapper was doing crazy things and not creating /dev/vg/lv for some LVs.
[09:15] <persia> StevenK: True.  For me that happens 3-5% of the time, which seems acceptable, as one just needs to retry for it to work.  I think it's a timing issue with schroot, as I've encountered the same with using schroot snapshots to test things (through the dchroot wrapper).
[09:57] <TheMuso> Go circuit breakers tripping.
[09:57] <TheMuso> Actually, safety switches.
[10:31] <superm1> hi everyone, if someone could do a revu, i'd appreciate it: http://revu.tauware.de/details.py?upid=5980
[10:34] <persia> superm1: Just real quick-like, /usr/share/common-licenses/GPL is a link to GPLv2 :)
[10:35] <superm1> it hasn't been updated to 3 yet :)?
[10:35] <persia> superm1: Nope.
[10:36] <superm1> persia, well then what is the proper way to refer to it
[10:36] <superm1> is it going to be in common-licenses soonish?
[10:37] <persia> superm1: /usr/share/common-licenses/GPL-3
[10:37] <superm1> okay i'll point it to that instead, and reupload
[10:43] <superm1> persia, okay: http://revu.tauware.de/details.py?upid=5981
[10:45] <persia> superm1: There's a couple other little things.  See my comment.
[10:55] <persia> ogra: Have you already opened needs-packaging bugs?
[10:55] <ajmitch> ogra: you're not interested? ;)
[10:55] <evand> I tried uploading a source package to revu before I was in the universe-contributors team, but I haven't recieved a rejection notice nor has the package appeared on REVU.  When I try to upload it again it cannot create the dsc file in /incoming.  Any ideas?
[10:55] <ajmitch> evand: let one of us know what the package name is
[10:55] <persia> evand: The old files are stuck, and the new files can't be done.  Which package?
[10:57] <evand> ajmitch: evolution-exchange (I also accidentally uploaded an i386 one as well
[10:57] <evand> thanks!
[10:57] <ajmitch> binary uploads get cleared now
[10:57] <ajmitch> (automagically)
[10:57] <evand> neat
[10:58] <persia> ajmitch: Good feature!
[10:59] <ajmitch> persia: did you see the rcbugs with comments?
[11:00] <persia> ajmitch: I saw it, and like it, but based on your previous statement regarding the hosting, I'm ignoring it for now.
[11:00] <ajmitch> ah yes, that's right
[11:00] <ajmitch> it shouldn't be too slow, it's a fairly basic page
[11:00] <ajmitch> but I'll try & move it to imbrandon's box
[11:00] <persia> ajmitch: Have you already made hosting arrangements, or are you looking for support?
[11:00] <ajmitch> already made them last night
[11:01] <persia> Great.  When it's really live, could it update ~6 hours or so?
[11:01] <ajmitch> the debian bugs only syncs nightly
[11:02] <ajmitch> but it could refresh the ubuntu part more often
[11:03] <persia> ajmitch: That's the part I'd like.  I've found a couple cases where the package is already updated.  Then again, with comments, perhaps this isn't necessary.
[11:03] <XimDev> hey there
[11:03] <XimDev> i have a question concerning the membership
[11:04] <XimDev> I become lost in the wiki pages
[11:04] <XimDev> first i become a member, then MOTU Hopeful then a MOTU then a  developer, right?
[11:05] <persia> XimDev: There's no strict progression.  You're welcome to contribute to universe starting right now (see the topic).
[11:08] <superm1> persia, http://revu.tauware.de/details.py?upid=5982 , that should cover the things you mentioned.  
[11:09] <persia> superm1: Just as a reminder, it's best to request reviews from everyone: the more people who review the package, the better it will be :)
[11:11] <XimDev> i have studied software quality engineering but I omitted it that from my CV
[11:11] <persia> superm1: Two BZR revisions!  Wow, upstream really does the release early, release often thing :)  Also, isn't there some neat feature that allows one to pull the BZR changelog into ./Changelog when exporting?
[11:22] <persia> ogra: Just FYI, it appears that synfigstudio is already packaged and distributed...
[11:46] <persia> Grrr.  \, |, and _ are working again, but right-brace and right-bracket have been lost (really, I didn't touch anything).  Could someone please give me a couple characters to copy?  These don't appear in nicknames as often.
[12:08] <persia> OK.  The complete list of things with architecture-specific NBS is shorter than I thought, but for i in i386 amd64 powerpc sparc; do echo Processing: $i; quinn-diff -i -p $i.Packages 2>&1 | awk '/warning/ {print $3 }' | uniq | xargs rmadison -u ubuntu | grep gutsy | grep $i; done seems to be the easiest way to get it.
[12:33] <imbrandon> ajmitch, ping
[12:33] <ajmitch> imbrandon: pong
[12:33] <imbrandon> everythng ok with the access ?
[12:33] <ajmitch> haven't done anything yet
[12:34] <imbrandon> noticed you dident put anything there yret
[12:34] <imbrandon> ahh ok
[12:34] <imbrandon> just checkin in 
[12:34] <imbrandon> :)
[12:34] <ajmitch> k :)
[01:31] <heatxsink> hello all, I'm trying to package a apache2 module that isn't normally included by default can anyone give me a pointer as to how to JUST package the module that I'm compiling?
[01:56] <ogra> ajmitch, as you can see in the delay of my reply i'm not really having time to play with new packages ;)
[01:56] <ogra> persia, very cool :) thanks for the info (i could have looked myself, sorry, these apps just came up in an edubuntu thread)
[01:57] <persia> ogra: rmadison is your friend :)
[01:57] <ogra> indeed :)
[02:22] <xxxxx1> good morning (?) all.
[02:24] <heatxsink> hello all, when using dh_make (I'm packaging a apache module) which I use when defining the type of package?
[02:24] <heatxsink> library?
[02:31] <xxxxx1> heatxsink, did you read packaging guide?
[02:32] <Nafallo> !ask
[02:32] <ubotu> Don't ask to ask a question. Just ask your question :)
[02:32] <Nafallo> sorry. just copy-pasted that line again :-)
[02:33] <xxxxx1> heatxsink, section 2 - Packaging with Debhelper
[02:35] <Vorian> it's in section 3 :)
[02:41] <xxxxx1> Vorian, nope. 3 is CDBS section
[02:41] <xxxxx1> ah
[02:42] <xxxxx1> 3.2
[02:42] <xxxxx1> heh
[02:42] <Vorian> lol 
[02:42] <Vorian> nice call :)
[03:09] <frafu> xxxxx1: could you give me the url of $3.2? 
[03:10] <xxxxx1> frafu, http://doc.ubuntu.com/ubuntu/packagingguide/C/
[03:10] <frafu> thanks
[03:10] <xxxxx1> np
[03:12] <xxxxx1> frafu, check this too: http://www.debian.org/doc/maint-guide/
[03:13] <frafu> ok, I will have a look... 
[03:21] <frafu> xxxxx1: thanks again 
[04:18] <pygi> hi folks
[04:57] <norsetto> persia: Hi Emmet, still here!?
[04:57] <norsetto> dholbach: hey Daniel!
[04:57] <persia> norsetto: Yep, but not for much longer.
[04:59] <norsetto> persia: lsusb doesn't say anything of help, unfortunately
[05:00] <norsetto> persia: what is strange is that the zaurus seems to be a pet of mdz :-O
[05:00] <ryanakca> persia: hmm. *pokes the magic variable*. I have it set up as they told me in #gnu, but it still doesn't work. 
[05:00] <persia> ryanakca: Interesting.  pastebin?
[05:01] <ryanakca> http://pastebin.ca/616218
[05:01] <ryanakca> persia: I guess I could always decompress the manpages, and compress them properly...
[05:02] <persia> ryanakca: It's probably easier to delete them, and use debian/aoeui.manpages instead.
[05:03] <persia> ryanakca: Alternately, try echo $GZIP in an install:: rule to see if you stll have the value in the environment.
[05:03] <ryanakca> persia: yeah, so, during the install of the manpages, a copy gets created in debian/ ? Or would I have to extract them myself and put them there?
[05:05] <persia> ryanakca: debian/$package.manpages doesn't require that the manpage be in debian/ - just feed it the path (relative to $(CURDIR)) to the manpages created as part of the upstream make install
[05:06] <persia> norsetto: Thanks for looking.  I've replied in a /query, as I don't think my device problems are on-topic here :)
[05:06] <ryanakca> persia: ok, so, it aoeui.manpages, I would put in $(CURDIR)/debian/aoeui/usr/share/man/man1/aoeui.1.gz     and     $(CURDIR)/debian/aoeui/usr/share/man/man1/asdfg.1.gz     ?
[05:07] <persia> ryanakca: No.  Rather just aoeui.1 and asdfg.1 (or at least it looks like make install generates these in the package root directory)
[05:08] <persia> ryanakca: The .gz files are the ones you want to delete.
[05:10] <ryanakca> persia: ok. I'll fix it up, and then test it :)
[05:10] <persia> ryanakca: Good luck,
[05:11] <ryanakca> persia: echo $GZIP in install/aoeui:: returns this in the build log:
[05:11] <ryanakca> echo ZIP
[05:11] <ryanakca> ZIP
[05:12] <persia> ryanakca: Ah.  You probably have to force the shell (both for the variable setting, and the echo).  The reason you get that is that make interprets the $G as an undefined variable.
[05:12] <persia> ryanakca: As a result, I doubt you actually have $GZIP defined in the local shell.
[05:13] <man-di> ryanakca: use $(GZIP) instead of $GZIP
[05:13] <ryanakca> ah, ok
[05:14] <man-di> make needs the $(...)
[05:14] <persia> man-di: To set make variables, yes.  To set shell variables, it's a little more complicated, no?
[05:15] <ryanakca> man-di: do I need `$(GZIP)="-9 --name"; export $(GZIP)` as well?
[05:15] <ryanakca> (instead of `GZIP="-9 --name"; export GZIP`)
[05:15] <persia> ryanakca: Unless $(GZIP) is defined in the makefile, that will be a noop.
[05:15] <man-di> ryanakca: no
[05:16] <man-di> ryanakca: GZIP="-9 --name" (without indention)
[05:16] <man-di> ryanakca: then $(GZIP) is defined for all targets
[05:17] <ryanakca> man-di: ok, thanks :)
[05:19] <ryanakca> persia: now I get:
[05:19] <ryanakca> echo
[05:19] <ryanakca> dh_installdocs -paoeui ./README
[05:20] <ryanakca> it returs 'echo' blank, and then a newline, with a blank, and then the dh_installdocs
[05:20] <ryanakca> persia: I'll just do it with aoeui.manpages
[05:20] <man-di> persia: they are different
[05:20] <man-di> persia: but some things are the same
[05:21] <leonel> apt-get install coffee ...
[05:21] <persia> man-di: Does GZIP="-9 --name" in the makefile export to the local shell, so a later call to gzip automatically takes the desired arguments?
[05:21] <man-di> persia: no
[05:22] <man-di> it makes it only available in the Makefile
[05:23] <man-di> you can then use 'GZIP=$(GZIP) command' to export it to a command or do 'gzip $(GZIP) more.options...'
[05:24] <persia> ryanakca: Based on that, I'd say that your output above is expected, and correct.  Try something with $(shell GZIP="-9 --name"; export GZIP), although this may only run in a subshell, which might not be what you want.
[05:24] <persia> man-di: The debian sponsor has declared that the upstream makefile may not be patched :(
[05:25] <man-di> persia: this doesnt work, make executes  a new shell for each line
[05:25] <persia> That's what I feared.  Hrm.
[05:25] <man-di> persia: "The debian sponsor has declared that the upstream makefile may not be patched" ? What a f... rule is that?
[05:26] <persia> ryanakca: I think you have to use debian/$package.manpages or find a new sponsor who lets you apply the patch from SVN to the upstream makefile.
[05:26] <persia> man-di: No idea.  Doesn't make any sense to me either.
[05:26] <ryanakca> man-di: hmmm... I could always find myself a new sponsor :)
[05:26] <man-di> ryanakca: may I ask who the debian sponsor is?
[05:26] <ryanakca> man-di: pabs
[05:27] <ryanakca> man-di: I even said that the patch was pulled from upstreams SVN, but:
[05:27] <ryanakca> 22:31:11 < pabs> ryanakca: I'd say use GZIP until that version is released and then drop GZIP 
[05:27] <ryanakca> (GZIP being the magic variable)
[05:27] <man-di> ryanakca: I always thought pabs was technically cool
[05:28] <ryanakca> hmm
[05:29] <ryanakca> I personally find 1 patch from upstream cleaner and easier to maintain than both changes in the rules file and in aoeui.manpages... but, It'll have to do :)
[05:32] <persia> ryanakca: Alternately, you could use a lintian override until merging the upstream change, but that's a large hammer for a small nail.
[05:37] <persia> man-di: pabs *is* technically cool
[05:37] <man-di> persia: that is the first strange issue I hear about him
[05:38] <man-di> but everyone has a strange side
[05:38] <persia> ryanakca: Use the make export directive, like export variable += value
[05:38] <man-di> good that you dont know mine ;-)
[05:38] <persia> man-di: No.  make supports this - it's just buried deep in the manual.
[05:38] <persia> ryanakca: Thanks a lot for asking me about this: I'm now better with make.
[05:39] <man-di> persia: wow. never saw this before.
[05:39] <man-di> good that you found this
[05:41] <persia> ryanakca: Let me correct myself, you want "export GZIP := ..."
[05:44] <persia> for those following at home, please note that "FOO := $(shell echo $$FOO)" is the equivalent inverse.
[05:44] <Q-FUNK> can anybody think of a tool that would allow sorting filenames alphabetically, but starting from the right instead of the left?
[05:48] <persia> Q-FUNK: ls | rev | sort  | rev ?
[05:59] <Q-FUNK> ah, I didn't know about rev
[05:59] <Q-FUNK> useful one
[05:59] <Q-FUNK> thanks, persia
[05:59] <ryanakca> persia: thanks :)
[06:01] <ryanakca> persia: so, 'export GZIP  := -9 --name' ?
[06:01] <persia> ryanakca: You might need quotes around the value (I think you do), but that's supposed to work.
[06:02] <ryanakca> persia: sweet, thanks :)
[06:41] <ScottK> leonel: Can you test Edgy?
[06:45] <norsetto> dholbach: are u alive Daniel?
[06:45] <dholbach> norsetto: a bit, yes
[06:46] <norsetto> dholbach: well, it was still kind of warm
[06:46] <norsetto> I think the breathing gave him away .....
[06:47] <norsetto> see u tomorrow then .... cheers
[06:47] <dholbach> norsetto: is there anything I can help you with?
[06:48] <norsetto> dholbach: me? dunno, having a look at the stuff in REVU perhaps?
[06:48] <dholbach> norsetto: next week will be better - I'm at a conference at the moment, so I'm fairly busy with all kinds of stuff
[06:49] <dholbach> you can drop me a mail and I can try to get around to it
[06:49] <dholbach> but I can't promise, sorry
[06:49] <norsetto> dholbach: sure, its just a new package for which I need some advice as it involves binary libraries 
[06:50] <dholbach> can you mail ubuntu-motu-mentors or ubuntu-motu or both about that?
[06:50] <dholbach> that might be your best option
[06:50] <dholbach> as there are people on the list who are far cleverer than I am
[06:50] <norsetto> dholbach: oh, it can wait, there is no urgency, in any case I hoping to get some feedback from upstream
[06:51] <dholbach> feel free to ask the lists or in the channel
[06:51] <dholbach> by no means get blocked on me :)
[06:51] <norsetto> and NO ... I'm not going to request REVU in this channel ;-)
[06:51] <norsetto> just kidding
[06:52] <norsetto> have fun guys, love and hugs to all (steveK included)
[06:52] <norsetto> since he is sleeping ;-)
[07:00] <leonel> ScottK: need to install it
[07:05] <ScottK> leonel: If you could try out the clamav 0.88.7-1ubuntu1 package I put up on Edgy, that would be a huge help.  I also put up 0.88.7-1ubuntu1~dapper using your changes.
[07:11] <zul> umm...ok
[07:17] <leonel> ScottK: I remember I have a qemu image to test it 
[07:18] <leonel> let me  plug that disc and  test it
[07:18] <ScottK> Great.
[07:29] <ScottK> leonel: When you get done testing, please comment your results in Bug #83065.
[07:29] <ubotu> Launchpad bug 83065 in edgy-backports "Please backport clamav 0.88.7-1ubuntu1 to edgy from feisty" [Undecided,Incomplete]  https://launchpad.net/bugs/83065
[07:33] <ScottK> Well now...  That's an interesting tidbit I didn't know: http://www.cups.org/articles.php?L476+I0+TFAQ+M10+P1+Q
[08:06] <jdong> grr
[08:06] <jdong> is there a regular expression that matches valid debian package names?
[08:07] <jdong> I'll make one myself if not, but I can't help but think someone has one
[08:07] <vorlon> [a-z0-9] [a-z0-9+-.] +
[08:08] <ScottK> I don't see ~ in there anywhere.
[08:08] <vorlon> that's because ~ isn't valid in a package name
[08:08] <geser> ~ shouldn't be found in *names*
[08:09] <ScottK> Ah.  Nevermind.
[08:09] <avoine> I made a debdiff for this bug #88153 but I'm not sure what I have to do next. Ask for a sponsors?
[08:09] <ubotu> Launchpad bug 88153 in ipsec-tools "very simple to fix racoon completion problem" [Undecided,New]  https://launchpad.net/bugs/88153
[08:10] <avoine> Or maybe the bug have to be confirm?
[08:10] <jdong> vorlon: thanks
[08:12] <geser> avoine: subscribe ubuntu-main-sponsors to this bug (as ipsec-tools is in main)
[08:12] <DarkMageZ> persia, with debian or with the debian "maintainer" of the package?
[08:13] <avoine> ok
[08:16] <ScottK> avoine: No opinion on the validity of the change, but the debdiff looks reasonable.  Did you look at the other bugs in the package to see if you could sweep up more than one?
[08:18] <avoine> no I don't
[08:18] <avoine> I check now
[08:20] <ScottK> avoine: Also, ipsec-tools is needing a merge from Debian: http://merges.ubuntu.com/i/ipsec-tools/REPORT you might ask doko (who did the last merge) if he minds if you do it and then roll your bug fix(es) in with the merge debdiff.
[08:22] <avoine> ok
[08:36] <candyman50> Hey all, anyone know how to add a new piece of software to the multiverse or universe apt repositories?
[08:38] <geser> someone needs to package it
[08:38] <candyman50> so if I have a .deb already packaged, what do I do next?
[08:38] <zul> !revu
[08:38] <ubotu> REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[08:42] <candyman50> thanks guys
[09:21] <RainCT> ei
[09:56] <ScottK> persia: Weren't you working on wxGTK transition?
[09:57] <ScottK> If so, I thought https://launchpad.net/bugs/125627 would be of interest.
[09:57] <ubotu> Launchpad bug 125627 in mkvtoolnix "Please recompile against wxGTK 2.8 (for gutsy)" [Undecided,New]  
[10:08] <sacater> when I run dch -i it launches vim
[10:09] <sacater> it used to do nano, which is my preffered text editor
[10:09] <geser> export EDITOR=nano
[10:09] <ScottK> sacater: Congratulations on the upgrade.
[10:09] <sacater> thanks
[10:09] <sacater> ScottK: ?
[10:10] <sacater> i need to get to use it
[10:10] <sacater> nano is simpkler
[10:10] <leonel> ScottK: clamav-88.7-1ubuntu1    on edgy   builded  installed and tested  GOOD !
[10:10] <sacater> and faster
[10:10] <ScottK> leonel: Excellent.  Please comment that on the bug I mentioned.
[10:11] <sacater> geser: didnt work
[10:12] <leonel> ScottK:  what bug you mentioned ??
[10:12] <leonel> ScottK: I've updated the wiki
[10:12] <geser> sacater: have you perhaps VISUAL set?
[10:12] <ScottK> leonel: When you get done testing, please comment your results in Bug #83065.
[10:12] <ubotu> Launchpad bug 83065 in edgy-backports "Please backport clamav 0.88.7-1ubuntu1 to edgy from feisty" [Undecided,Incomplete]  https://launchpad.net/bugs/83065
[10:12] <sacater> geser: no idea..
[10:12] <geser> echo $VISUAL
[10:13] <gnomefreak> sacater: sudo update-alternatives you should beable to set it in there (cant remember the exact name of it off hand but you can pass --all to set all defaults
[10:13] <sacater> geser: [sacater@neo ~] $ echo $VISUAL
[10:13] <sacater> gvim
[10:13] <sacater> [sacater@neo ~] $ 
[10:13] <geser> unset VISUAL
[10:13] <geser> and try again
[10:14] <sacater> geser: ?
[10:14] <geser> VISUAL is used before EDITOR
[10:14] <sacater> geser: can you quickly paste some commands
[10:15] <geser> dch looks in VISUAL which editor to use and find gvim there and doesn't lookup EDITOR anymore
[10:16] <leonel> ScottK:  done
[10:17] <sacater> geser: where is the file where hteese prefs are set up
[10:17] <ScottK> leonel: Thanks.
[10:18] <geser> sacater: I'd try to search in ~/.bashrc, ~/.bash_profile or the global one's in /etc
[10:19] <ScottK> leonel: I've subscribe the Ubuntu archive managers on that one, so now we just wait.
[10:19] <leonel> ScottK: Great  
[10:28] <man-di> Can someone please read https://bugs.launchpad.net/ubuntu/+source/libtoolbar-java/+bug/46088 and tell me what he/she thinks about this bug report?
[10:28] <ubotu> Launchpad bug 46088 in libtoolbar-java "bottom toolbar" [Medium,New]  
[10:31] <geser> it's a little bit old and for a test version of dapper
[10:31] <geser> I'd say this bug is misclassified and the reporter talks about the gnome panel
[10:37] <man-di> geser: that was my impression too
[10:37] <man-di> geser: but he gives not much infos either
[10:37] <man-di> geser: what should we do about this bugreport
[10:37] <man-di> ?
[10:38] <man-di> close as invalid?
[10:40] <geser> given that it is over a year old and doesn't contain much information, I'd close it
[10:41] <ScottK> close == invalid in this case, but invite them to reopen if they have additional specifics.
[10:43] <man-di> ScottK: yes, sure
[10:52] <xxxxx1> bye all
[10:55] <Spec> do you need to sign your package in order to upload it to REVU?
[10:56] <man-di> Spec: yes
[10:56] <Spec> 'k, hmm, i'll need to juggle my package then :p
[10:56] <Spec> as my key is not on the server i use it build the package :p
[10:57] <man-di> Spec: debsign -r ... helps with this
[10:57] <man-di> Spec: I do this all the time
[10:57] <man-di> this only scps .dsc and .changes files back and forth
[10:58] <Spec> debsign -r?
[10:58] <Spec> well, my key is on my (dead) linux laptop...and i'm at work and my key is here, but it's on a windars comp
[10:59] <Spec> so i can use windows-gpg to sign just the .dsc and .changes file?
[11:01] <man-di> Spec: yes, only these two files need to be signed
[11:01] <Spec> 'k, thanks
[11:20] <man-di> grrrr
[11:20] <man-di> where is my multidistrotools checkout?
[11:21] <man-di> Does somebody knows where the latest multidistrotools can be fetched? https://wiki.ubuntu.com/MultiDistroTools is not uptodate
[11:26] <ryanakca> man-di: hmm.. I'm getting:
[11:26] <ryanakca> gzip -c aoeui.1 >aoeui.1.gz
[11:26] <ryanakca> gzip: '-9': No such file or directory
[11:27] <ryanakca> so, does that mean that after running  'gzip -c aoeui.1 >aoeui.1.gz', it also runs 'gzip -9' and chokes because it isn't compressing anything?
[11:28] <ryanakca> or would I have to change it to    export GZIP  := -9 $1          or something of the sort?
[11:45] <pygi> persia, yay, built on ppc :)
[11:48] <pygi> mr_pouit, I'm after the bug 
[11:48] <pygi> tomorrow or so
[12:03] <TheMuso> c
[12:03] <TheMuso> argh
[12:04] <hendrixski> :-( patching is weird :-(
[12:06] <hendrixski> I am so confused I included dpatch.make  but I get    make: patch-stamp: Command not found
[12:08] <ryanakca> persia: weee! upstream released 1.1.0, so that means no more crazy obscure variable searching :D
[12:11] <TheMuso> persia: I'll look at ubuntustudio-sounds in a while, as soon as I have a few important things out of the way.
[12:13] <hendrixski> I fixed the "patch-stamp" not found error by joining it onto the line above it??? that makes no sense...