=== alex-weej_ [n=alex@82.23.188.238] has joined #ubuntu-motu === norsetto [n=norsetto@87.18.239.33] has left #ubuntu-motu [] [12:23] Gotta love it when a build fails because a command segfaults. [12:23] On an architecture that hardly anyone is likely to h ave. [12:24] have [12:28] ScottK: set DEBEMAIL to your Ubuntu mail address and dpkg-source won't build a source package with an unchanged maintainer [12:29] geser: And then I couldn't sign the package because that address isn't on my key. === Bassetts [n=Bassetts@unaffiliated/bassetts] has joined #ubuntu-motu === ScottK builds stuff for both Ubuntu and Debian, so I'd rather actually avoid that. === ivoks_ [n=ivoks@18-62.dsl.iskon.hr] has joined #ubuntu-motu [12:30] than add it to your key :) === bluekuja_ [n=andrea@host106-170.pool8252.interbusiness.it] has joined #ubuntu-motu [12:31] c [12:31] ugh [12:32] TheMuso: the gs segfaults on IA64? [12:32] geser: the ps2pdf command seems to actually for ecasound2.2, which I synced from Debian. [12:33] So the package builds, yet the docs fail because of that command segfaulting. [12:33] I've seen it for one of my syncs too [12:34] ah ok === PriceChild [n=pricechi@ubuntu/member/pricechild] has joined #ubuntu-motu [12:36] that gs bug is since fixed in Debian [12:36] cool [12:37] gs? What package is that? [12:37] its one of the tex ones isn't it? === micahcowan [n=micahcow@ubuntu/member/micahcowan] has joined #ubuntu-motu [12:38] !info ghostscript gutsy [12:39] 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] TheMuso: that one [12:39] ah === DarkSun88 [n=Ma@ubuntu/member/darksun88] has left #ubuntu-motu ["Sto] === mok0 [n=mok@0xc3f966d5.slnxr2.ras.tele.dk] has joined #ubuntu-motu === jwendell [n=wendell@ubuntu/member/wendell] has joined #ubuntu-motu === hggdh [n=hggdh@pool-71-170-39-244.dllstx.fios.verizon.net] has joined #ubuntu-motu === leonel [n=leonel@189.155.176.166] has joined #ubuntu-motu === bryce__ [n=bryce@217.207.76.231] has joined #ubuntu-motu === RedKrieg [n=RedKrieg@ip68-230-209-186.rd.hr.cox.net] has joined #ubuntu-motu === _MMA_ [n=atm@cpe-071-070-203-016.nc.res.rr.com] has joined #ubuntu-motu === _MMA_ [n=atm@cpe-071-070-203-016.nc.res.rr.com] has left #ubuntu-motu [] === jml [n=jml@ppp121-44-217-216.lns1.hba1.internode.on.net] has joined #ubuntu-motu [01:26] !ask [01:26] Don't ask to ask a question. Just ask your question :) === Vorian [n=Steve@ubuntu/member/Vorian] has joined #ubuntu-motu === apacheLAGger [n=me@N790P020.adsl.highway.telekom.at] has joined #ubuntu-motu [01:30] 454 packages upgraded, 0 newly installed, 3 to remove and 38 not upgraded. [01:30] Need to get 407MB of archives. After unpacking 15.6MB will be freed. [01:30] something tells me that I've been lazy in updating === micahcowan [n=micahcow@ubuntu/member/micahcowan] has joined #ubuntu-motu [01:34] ajmitch: and we are not using 14400kbps modems ... [01:34] plop [01:34] 14400bps === Burgundavia [n=corey@ubuntu/member/burgundavia] has joined #ubuntu-motu [01:37] it feels like it here at times === radhios [n=radhios@200-122-44-133.dsl.prima.net.ar] has joined #ubuntu-motu === Arrogance [n=aks@ottawa-hs-64-26-148-25.d-ip.magma.ca] has joined #ubuntu-motu [01:43] c [01:43] ugh === Acksys [n=acksys@cpe-071-070-084-000.sc.res.rr.com] has joined #ubuntu-motu [01:47] how much hard drive would I need to create a mirror at home for main/restricted/universe/multiverse? === Acksys [n=acksys@cpe-071-070-084-000.sc.res.rr.com] has left #ubuntu-motu [] [01:51] nixternal: For which releases? [01:51] nixternal: And which arches? === Neonightmare [n=neonight@184.112.203.62.cust.bluewin.ch] has joined #ubuntu-motu [01:51] gutsy at a minimum x86 [01:52] source? [01:52] nixternal: ~ 12Gb, with no source === ajmitch only has a mirror of main for amd64 & i386, no source [01:53] well I would like to have source as well at least for main and universe === StevenK has a mirror of main, restricted, universe and multiverse for amd64 and i386 with feisty and gutsy, and no source. [01:54] StevenK: that is about 24gb then? [01:54] Actually, it's about ~ 52 [01:54] I had a plan of why I wanted to do that, but I can't remember now :) === ajmitch can't afford to download that much [01:55] I would download the majority during class to an external USB drive and then just rsync that drive at home [01:56] My plan gives me free downloads between midnight and midday. [01:57] that's useful [01:57] I suppose I should fix coreutils now that I found a patch for it === ajmitch will be back later [02:01] 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] Oops. Sorry about that leonel [02:01] ScottK: :) === persia [n=persia@ubuntu/member/persia] has joined #ubuntu-motu === calc [n=ccheney@217.207.76.231] has joined #ubuntu-motu === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #ubuntu-motu [02:03] ScottK: what was the clamav question? [02:04] everyday I found new things and packages in lauchpad it's HUGE ! === joejaxx [i=joejaxx@fluxbuntu/founder/joejaxx] has joined #ubuntu-motu [02:20] Anyone feel like helping me with something related to GDK+ 2.0? [02:20] nice i just prevented a ubuntu delta in fluxbox [02:22] I'm wondering why I can't pass class::function as a G_CALLBACK()? [02:22] like G_CALLBACK(whatever::foo) where "whatever" is a valid class and "foo" is a valid member function. [02:27] Ah! It has to be declared static in the class. Got it. :) === RAOF [n=Chris_@matht464.maths.unsw.edu.au] has joined #ubuntu-motu [02:29] Morning RAOF. [02:32] Morning TheMuso === EliasAmaral [n=dark@unaffiliated/EliasAmaral] has joined #ubuntu-motu === superm1 [n=superm1@ubuntu/member/superm1] has joined #ubuntu-motu [02:42] ScottK: Done [02:43] 88.7 failed 88.4 no problems all builded and tested with clamsmtp and clamassassin === Jazzva [n=sasa@cable-89-216-184-157.dynamic.sbb.co.yu] has joined #ubuntu-motu [02:51] ScottK: Great. Glad to hear it. === dabaR [n=dabaR@wnpgmb09dc1-159-42.dynamic.mts.net] has joined #ubuntu-motu === RAOF [n=Chris_@matht464.maths.unsw.edu.au] has joined #ubuntu-motu === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-motu === Fujitsu wonders why he just saw `-D__LIBTOOL_IS_A_FOOL__' flying past while building quantlib [03:09] lol === sharms [n=sharms@ubuntu/member/sharms] has joined #ubuntu-motu [03:12] Fujitsu: It tells libtool to not make "smart" decisions. [03:13] Frustratingly, it appears that gutsy lintian has decided to tell me "bad-distribution-in-changes-file gutsy". [03:14] StevenK: Really? [03:14] Fujitsu: I think so. [03:14] Heh. [03:15] Ah, I know what it does. If Libtool is a fool, it doesn't add rpath's to binaries. [03:16] Ahh. [03:17] c [03:17] ugh [03:18] :D [03:19] 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] persia: Just saw that, will do. [03:19] TheMuso: Thanks. === iterion [n=help@208.252.1.99] has joined #ubuntu-motu === Nafallo_ [n=nafallo@ubuntu/member/nafallo] has joined #ubuntu-motu [03:29] persia: Maybe we should run this GPL with SA by some archive admins, to be sure. [03:29] I'd rather not upload and have it rejected because of that. [03:30] As it reflects badly on us. [03:30] 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] persia: Ok. [03:32] TheMuso: Doesn't appear official yet. Depends on how much you trust hearsay :) [03:32] Right. === etank [n=etank@ubuntu/member/etank] has joined #ubuntu-motu [03:32] 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] 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] So... Where do we go from here re sconz and FTBFS? [03:34] 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] 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] persia: Right. [03:35] I guess it depends on how quickly upstream are likely to fix it. === minghua [n=minghua@ubuntu/member/minghua] has joined #ubuntu-motu [03:35] persia: There's always the next upstream. I'm interested in your suggestion. [03:37] 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] (or debian/$binarypackage.install if appropriate) [03:44] persia: OK. I'll have a look. Thanks. === docta_v [i=1400@apocalypse.OCF.Berkeley.EDU] has left #ubuntu-motu [] === MatthewV [n=MatthewV@202.183.119.45] has joined #ubuntu-motu [03:46] 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] Makes sense. [03:54] persia: Just uploaded -screensaver. [03:54] TheMuso: Excellent. I'm just waiting to hear back from tsmithe regarding the sounds README, and we should have the whole set. === DarkMageZ [n=richard@ppp59-167-16-86.lns2.syd7.internode.on.net] has joined #ubuntu-motu [03:56] 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. === _MMA_ [n=mma@cpe-071-070-203-016.nc.res.rr.com] has joined #ubuntu-motu [03:57] TheMuso: Oh right. Do you have a pointer to the spec? === RickH [n=rick@c-68-58-96-122.hsd1.in.comcast.net] has joined #ubuntu-motu [03:57] persia: Just a sec. [03:59] persia: https://wiki.ubuntu.com/DerivCustomSoundThemes [03:59] 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] ? [04:00] ryanakca: debhelper/dh_installman does that afaik. [04:00] Or dh_compress, can't remember which. [04:00] cdbs/debhelper handles that. [04:00] #debian-mentors has proposed `GZIP="-9 --name" $(MAKE) build` for debhelper [04:01] ryanakca: Try it without that. If it doesn't work, try it with that. When you get a package you like, smile. [04:01] 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] persia: without the GZIP line, I get: http://pastebin.ca/613197 [04:02] 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] persia: Yeah I know. [04:03] persia: with it, I get the same thing [04:03] ryanakca: Most packages in the archive simply install manpages. I don't believe they gzip them as well. [04:03] TheMuso: everything not already gzipped gets gzipped during package build. This is an odd and annoying case. [04:03] TheMuso: according to policy, they need to be gzipped. [04:04] There isn't a single one on my system that isn't, and it's required by policy. [04:04] ryanakca: For the built package, yes, and they get gzipped when the package is built. [04:04] 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] dh_compress says it compresses man pages. === xtknight_ [n=xtknight@c-68-43-120-159.hsd1.mi.comcast.net] has joined #ubuntu-motu === jml [n=jml@ppp121-44-217-216.lns1.hba1.internode.on.net] has joined #ubuntu-motu [04:05] TheMuso: yes, but, in this case, it's not dh_compress that's installing the manpage, it's the Makefile and make === jamman [n=jessie@160.7.244.25] has joined #ubuntu-motu [04:05] 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] hey all. === xtknight_ [n=xtknight@c-68-43-120-159.hsd1.mi.comcast.net] has joined #ubuntu-motu [04:06] ryanakca: Right. [04:06] so is there any way i can contribute with web servering? [04:06] 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] 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] persia: and as such, it would compress it? [04:07] 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] TheMuso: makefile installs them uncompressed. maybe I'm communicating properly... shall I get you a link for you to examine? [04:08] 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] 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. === hendrixski seriously has to learn basic unix command like diff [04:09] hendrixski: You'll want `patch` to apply the output of `diff`, but basically, yes. === Perdente [n=chatzill@75-132-33-28.dhcp.stls.mo.charter.com] has joined #ubuntu-motu [04:10] persia: $package.manpage ? Where does that come from? hmm. I could also just have rules run gzip on them... [04:10] but wouldn't that mean that I'd have to stick gzip in build-depends? [04:10] 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] persia: ah. well, upstream installs them, just uncompressed. === ryanakca scratches his head [04:11] persia, 'cause I got really confused with that patch environment I was like "oh man.. I gotta redo all this stuff." LOL [04:11] 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] persia: yeah, ok [04:12] persia: thanks :) [04:12] ryanakca: Upstream is installing them uncompressed? Does dh_compress not fix this? [04:12] persia: apparently not [04:12] ryanakca: What exactly is your question? Is there anything dh_compress failing to do? [04:12] persia: or wait, upstream is installing them compressed, but not compressed to the maximum level === micahcowan [n=micah@ubuntu/member/micahcowan] has joined #ubuntu-motu [04:13] minghua: ok. lintian -i on the deb outputs this: http://pastebin.ca/615335 [04:14] 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] Hmm. I didn't know policy requires maximum compression level. [04:14] minghua: Any objections to syncing the various bits of geda 20070626? We've had a couple of requests, AFAIK. [04:14] Outdated policy and should be abandoned, IMHO. [04:14] 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] minghua: Current policy prefers preservation of bandwidth to preservation of user CPU. [04:15] s/Debian/sponsor in #debian-mentors/g [04:15] Fujitsu: I know nothing about geda. So I supposed no objections. [04:15] Great, just checking. === Fujitsu wonders why it has to be split into 10 source packages. [04:16] persia, I just re-read the parts of the manual that were confusing me and it suddenly makes sense.... thanks :-) [04:16] persia: where would I put the magic variable in a CDBS rules? [04:16] your explanation was like the missing key [04:17] Fujitsu: To pump your karma number, perhaps? ;-) [04:17] ryanakca: That's an interesting question. Hold on whilst I look at your rules and upstream Makefile... [04:17] persia: thanks [04:20] Well, that's ugly. The manpages aren't actually created until make install is called. === Pumpernickel [n=Pumperni@about/essy/bacon/PuMpErNiCkLe] has joined #ubuntu-motu === ceros [n=user@c-76-111-84-156.hsd1.va.comcast.net] has joined #ubuntu-motu [04:22] persia: hehe :) [04:22] 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] persia: upstream said they'd fix it in next release === soren [n=sh@atlas.linux2go.dk] has joined #ubuntu-motu [04:23] persia: but... he said he'd only release it when he gets back from his holidays/vacation === Ng [n=cmsj@mairukipa.tenshu.net] has joined #ubuntu-motu === chninkel [n=yann@alcyone.pleiades.fr.eu.org] has joined #ubuntu-motu === keescook [n=kees@ubuntu/member/keescook] has joined #ubuntu-motu [04:24] wow. New packages aren't announced to gutsy changes. [04:24] 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? === zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-motu === bdmurray [n=bdmurray@mylar.outflux.net] has joined #ubuntu-motu [04:24] persia: no clue, never asked [04:24] TheMuso: That sounds like a bug. [04:25] 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] persia: yeah [04:25] hmm. === hggdh [n=hggdh@pool-71-170-39-244.dllstx.fios.verizon.net] has left #ubuntu-motu [] [04:27] persia: He's already fixed it in SVN http://aoeui.svn.sourceforge.net/viewvc/aoeui/Makefile?view=markup [04:28] 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] persia: hmm. since the patch is identical to the one created when comparing upstream to current, except for the version line, *nod* === ryanakca asks === Pici [n=pcmacman@unaffiliated/pici] has joined #ubuntu-motu [04:32] persia: 22:31:11 < pabs> ryanakca: I'd say use GZIP until that version is released and then drop GZIP === ryanakca grumbles === Hobbsee [n=Hobbsee@ubuntu/member/hobbsee] has joined #ubuntu-motu [04:32] 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] Pici: WIndows [04:33] Why is a reboot needed? [04:33] ScottK: :p [04:33] 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] ScottK: need udev to assign a group to /dev/fuse [04:34] Pici: Can't you do that in the postinst? [04:35] persia: I would assume so. Correct me if I'm wrong ( [04:35] Hobbsee:!!! [04:35] hey TheMuso! [04:35] 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] Pici: Right. So instead of rebooting, just make the necessary calls to udev, and don't bother the user. [04:36] 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] 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. === jamman [n=jessie@160.7.244.25] has left #ubuntu-motu ["Leaving"] [04:37] 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] 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] I think it just touches some file in /var === RickH [n=rick@c-68-58-96-122.hsd1.in.comcast.net] has joined #ubuntu-motu === Fujitsu checks. === IanC26 [n=IanC26@2002:908b:a588:4:216:6fff:fe39:ff6e] has joined #ubuntu-motu [04:38] 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] Pici: You're on the wrong track here. Just report the problem about the udev group. [04:39] my $notifier = "/usr/share/update-notifier/notify-reboot-required"; === jdong [n=jdong@ubuntu/member/jdong] has joined #ubuntu-motu [04:39] ... I know, I'm not going to mention the reboot thing. for the sake of my own curiousity.. [04:40] Pici: Fujitsu's answer should satisfy your curiosity === persia [n=persia@ubuntu/member/persia] has left #ubuntu-motu [] === persia [n=persia@ubuntu/member/persia] has joined #ubuntu-motu [04:40] Running that as root touches /var/run/reboot-required, which update-notifier picks up. [04:41] Fujitsu: Ah, thanks :) === ScottK envisions mean things that could be done with that piece of information. === anibal [n=anibal@debian/developer/anibal] has joined #ubuntu-motu [04:42] ScottK: Like? [04:43] Well, /var/run is 644, so you need root to touch things in it anyway. [04:43] 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] Hah. [04:43] Right, I'm thinking from a BOFH perspective. [04:43] And prompting the user to reboot is pretty lame compared to the other things you could maliciously do as root. [04:43] Ah. [04:44] Yes, but the annoyance factor is high. === javier_galicia [n=Javier@189.130.231.178] has joined #ubuntu-motu [04:44] ScottK: Wouldn't it just be better to give them a special shell with `sleep 120 &&` prepended to all command executions? [04:44] Plus you can say, "Well let me log on and try it ... See, works fine for me." [04:44] Not random enough. [04:45] Want to save that file, sorry, need to reboot first. [04:45] ScottK: the file is only a suggestion. I've gone up to 4 days ignoring it before I lost stability :) [04:46] Sure, but the likely victims wouldn't necessarily know that. [04:46] Plus that gives you a good finally... === hoora_ [i=ariel@gateway/tor/session] has joined #ubuntu-motu === Fujitsu 's head spins: [04:47] Testing exact repricing of multi-step constant maturity swaps and swaptions in a lognormal constant maturity swap market model... [04:47] "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] yay, dbs [04:47] That is one of quantlib's self-tests, supposedly. [04:48] ajmitch: Where? Let me kill it. [04:48] ajmitch: The djangoified missing-bugs list looks great. Should I be targeting that server, or is it moving soon? === Perdente [n=gabx84@75-132-33-28.dhcp.stls.mo.charter.com] has joined #ubuntu-motu [04:49] persia: it'll move, that's my home box [04:49] ajmitch: Ah. In that case, I'll not clog your DB :) === hoora_ [i=ariel@gateway/tor/session] has joined #ubuntu-motu === Fujitsu thinks we need an unmetdeps list like that. [04:53] How hard would it be to hack a comments field into debcheck? [04:55] Fujitsu: Does the combination of filed in-progress bugs and apt-cache -i unmet not meet your needs? === Jazzva [n=sasa@cable-89-216-184-157.dynamic.sbb.co.yu] has left #ubuntu-motu ["Kopete] [04:55] persia: That doesn't do multiple archs. [04:56] 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] http://alt.qeuni.net/~william/debcheck/ begs to differ [04:57] 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] 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] You could come and join NotiFrenzy/Specto/VCSFrenzy :) [04:59] Perdente: You could pick a bug that annoys you and try to fix it. [04:59] lol RAOF sometimes you scare me [04:59] Generally the way this works is that you find something that you want to work but doesnt [04:59] 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] ok and then look at the source code and tinker away === iterion is now known as AdamSun [05:00] duh... also I do really want to work on a dreamweaver equivalent for Ubuntu [05:00] Yup. Launchpad is always available for inspiration [05:01] I was gonna call it webuntu or something lame like that [05:01] Perdente: So, find an already existing project with similar goals, and fix things. [05:01] 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] Wasn't tonyyarusso working on packaging the son of the son of Nvu? [05:02] Yes [05:04] 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] persia: it's quite common for unmet deps to be !i386, sadly [05:05] ajmitch: Interesting. Is this because of arch-indep skew? [05:05] often [05:05] or something just never builds on amd64, like psyco [05:06] hendrixski: For a new graphic, it's often easier to include uuencoded version in debian/ and uudecode & install manually during the install: rule. === hendrixski goes to google uuencode [05:07] 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). === ajmitch shoudl file an RC bug in debian along with a patch [05:07] coreutils ought to fail to build there as well [05:07] Umm... I like coreutils. Please don't make it i386 only :) === AdamSun [n=help@208.252.1.99] has left #ubuntu-motu [] [05:08] persia: it fails to build on all platforms at the moment [05:08] just testing a patch now [05:08] ajmitch: Ah. That's better then. Good luck. === hendrixski is intimidated by uuencode [05:09] patch is from upstream, just a simple function renaming [05:09] persia: So how to we get rid on old binaries in Universe? === ScottK wonders about pinentry-gtk. [05:10] hendrixski: See the flobopuyo package for an example === tuxmaniac [n=tuxmania@unaffiliated/tuxmaniac] has joined #ubuntu-motu [05:11] Nevermind. It remove itself according to LP. === hendrixski checks out flobopasdfjiowjneofrin or whatever :-p [05:11] ScottK: https://bugs.launchpad.net/bugs/32460 is a good example of the process (it takes a while) [05:11] Launchpad bug 32460 in supercollider "Please remove stale AMD64 supercollider binaries." [Medium,Fix released] === ScottK looks [05:12] 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] Ah. I see. [05:13] 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] Surely they can generate lists of arch-NBSed cruft for us? === hendrixski is going to call it a night... and will research flobopuyo tomorrow :-) [05:16] 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] Lovely. [05:17] 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] useful [05:17] NBS is semi-automatic, like importing from Debian. [05:18] StevenK: NBS, yes. arch-NBS? === ScottK mumbles something about if only the toolchain were more open maybe the community would stand up and take care of it. [05:19] And then sits back down. [05:20] ScottK: pressure them to open it - ask what you can do. [05:20] if you really want to === Fujitsu quietly agrees with ScottK. [05:20] ScottK: There's nothing stopping you from running an analysis against a mirror of the archive :) [05:20] persia: Where does Debian keep its version? [05:20] but, i certainly cant speak on the matter, in current status. [05:21] 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] persia: True, but the most that could help me do is write bugs. [05:21] yay, coreutils built [05:21] Yeah! [05:21] now I can run off & apply the patch elsewhere to get back to what I was doing [05:22] persia: Ah, right, that'd make sense. [05:22] 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. === ScottK would be interested to know packages that build in Debian, but FTBFS in Ubuntu having been burned on that today. [05:24] Fujitsu: It appears to be something in melanie, from a quick look. [05:25] I really think they should have given the dak binaries slightly better names. [05:25] There's now a dak script that deals with that. [05:25] 'dak ls' <-> 'madison', etc [05:25] Ah. [05:28] 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] But he'll probably get it with less effort if you dig. === Fujitsu waits for dak to install in a chroot. [05:30] Thanks persia. [05:31] 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] Yes, but my response was funnier than yours ;-) [05:32] ScottK: True. [05:38] ScottK: edited debian/control for clamav 88.7 builded installed tested all ok [05:39] It looks like do_anais in rene is what does the arch-NBS stuff, but it's very dak-specific. [05:40] Fujitsu: Yep. On the other hand, you could mirror the archive into incoming/ and pass it to jennifer :) [05:41] I don't think it'd like the lack of .changes much. [05:42] leonel: OK. Hang onto that one. I have to find out how I can do a source package backport. [05:42] Thanks. [05:42] Fujitsu: dpkg-genchanges? Automating it might only catch the latest changelog entry, but it would at least allow processing. [05:43] persia: Or we could just convince Canonical to run it over universe or release the code. [05:43] leonel: Don't remove source:Version, you have to edit it. Look at the changes for my 0,90.3 dapper package. [05:44] Fujitsu: Yep. The first is probably easier. I'll look to see who need a patch again (I've forgotten). [05:44] We should probably process Debian removals regularly for a while longer too. [05:44] leonel: Once you do that, please make a debdiff and either post it somewhere or e-mail it to me. [05:44] persia: Do they actually use the bits of dak to do it? [05:45] Fujitsu: Some, and a few of our own (Anastacia, Bridget, Geri, Kari, Heather, Hilarie, Lorraine, Poppy, and Teri). [05:46] Where're you getting this information? [05:46] Fujitsu: dak docs (mostly). [05:48] persia: I don't think the Ubuntu-specific stuff would be there... [05:48] Fujitsu: The stuff that's there is to avoid namespace collisions (many of the same parties are involved with both infrastructures). === hoora_ [i=ariel@gateway/tor/x-1fd66bf66a309a31] has joined #ubuntu-motu [05:54] 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] Ouch. OpenOffice update. [05:57] TheMuso: You mean it built!? [05:58] Fujitsu: FOr feisty [05:58] Ah. [05:58] people still run feisty? [05:58] Yes, they do. [05:58] I kinda have to atm, until I am ready to start using GNOME/Gnome-terminal more. === man-di_ [n=mkoch@dyndsl-080-228-198-236.ewe-ip-backbone.de] has joined #ubuntu-motu [06:00] 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] persia: How do you know it is run with -n? I can't find any documentation on this stuff. === Neonightmare [n=neonight@184.112.203.62.cust.bluewin.ch] has left #ubuntu-motu [] [06:02] 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] Ah. [06:02] It's all very well collected and easy to find, I see. [06:02] Fujitsu: OO.o built for Gutsy, too. [06:02] StevenK: Even on i386? [06:03] Fujitsu: There used to be more, but the canonical wiki split made it a little harder to find things... [06:03] # gutsy ia64 Successfully built [06:03] # gutsy i386 Successfully built [06:03] # gutsy amd64 Successfully built [06:03] It failed on PPC, and is still building on sparc. === TheMuso grumbles about ppc no longer being officially supported. [06:04] but noone cares about PPC anymore [06:04] so it's all fine [06:04] Apple killed it. [06:04] Although it is nice that a few devs from the distro team have/use ppc. [06:04] Yeah I know. I've just grown fond of it. [06:04] X86 carried too much legacy crap. [06:04] s/carried/carries [06:04] And now OS X has to deal with the baggage! Muahaha! [06:05] which >> 99.9% of people never see or care about [06:05] even in ubuntu, most of the legacy crap is hidden away [06:05] ajmitch: They feel the speed difference. It's like using a crusoe... [06:05] Yeah I know. [06:06] ppc hardware from a few years ago is still quite useful however. [06:06] persia: there's such a speed penalty running ubuntu on x86? [06:06] I would say that windows would qualify as x86 legacy crap [06:07] 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] I wouldn't compare a 233MHz PPC and a 300MHz Pentium II, though. [06:12] StevenK: Right. I shouldn't get involved in architecture discussions anyway - there are too many reasons why X is different than Y. === mohammad [n=mohammad@CPE001346f4a717-CM0011aea585d0.cpe.net.cable.rogers.com] has joined #ubuntu-motu [06:16] lets say a version number already for an application looks like this: 0.0.1-1 [06:16] for an application already* [06:16] how should the debianized version look like? [06:16] 0.0.1-1-1 [06:16] 0.0.1-1-0? [06:16] oh ok [06:17] i did not know if it was that simple [06:17] and upstream should be summarily shot [06:17] ajmitch: :P [06:17] You can use dashes in the upstream version if you have a Debian revision. This is all laid out in Policy. [06:18] thumbscrews may help as well [06:18] ajmitch: is feeling violent, today [06:18] Hobbsee: you have no idea what horrors I've seen in code today [06:19] heh [06:19] the code in question predates us having the source in svn === LucidFox [n=LucidFox@wikia/Sikon] has joined #ubuntu-motu [06:21] yummy... === javierder [n=javier@41-108-235-201.fibertel.com.ar] has joined #ubuntu-motu === acm__ [n=acm@p54BC2679.dip0.t-ipconnect.de] has joined #ubuntu-motu [06:26] ScottK: done http://paste.ubuntu-nl.org/29616/ === tritium [n=tritium@ubuntu/member/tritium] has joined #ubuntu-motu [06:38] ajmitch: i am packaging apf :) [06:40] 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] joejaxx: that's really nice, but I have no idea what apf is or how it's relevant [06:41] ajmitch: advance policy firewall [06:41] ok.. [06:43] persia: I don't think so. But it's definitely bad behavior. [06:43] The buildds don't have network access. [06:43] (other than to an archive mirror) [06:44] 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] persia: I think it's against policy. But I don't think it's automatic FTBFS. I may well be wrong, though. === minghua checks policy. [06:46] minghua: Thanks. [06:46] BTW what python module are we talking about? From some third-party website? [06:46] minghua: http://cheeseshop.python.org/packages/2.5/s/setuptools/setuptools-0.6c5-py2.5.egg (and yes, directly from upstream). [06:50] oh, setuptools [06:50] 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] persia: I believe you can disable egg-fetching [06:51] Odd, that. I suspect it makes it non-DFSG-free due to the Desert Island test. [06:51] ajmitch: I'll look at that. Thanks. [06:54] TheMuso: It is a baaad idea to request a sync of geda, but not the rest of its bits. [06:55] Fujitsu: Oh ok. I'll mark as invalid. [06:55] TheMuso: Doing so now. [06:55] ok thanks [06:56] I filed requests for all of geda* half an hour ago, anyway. [06:56] Ah ok. [06:57] 5 minutes before you, in fact. Very nice timing. === persia thinks duplicate is nicer than invalid, for karma tracking... [06:57] persia: Probably. [06:57] yay, karma-that-does-nothing! === Fujitsu must look up how to dupe via email. [06:57] duplicate nuber [06:58] hi lifeless! [06:58] Hobbsee: Wrong! It gives you extra ShipIt CDs if you have > 0, AFAIK. [06:58] lifeless: Nah, that makes too much sense. [06:58]