[00:00] in my debian/rules, i have: http://p.caboo.se/151263, but when i run debian/rules build, I get this error: http://p.caboo.se/151269. I think it's simple, but i'm new to this. anyone can point me in the right direction? [00:00] Riddell, licensing [00:00] Riddell, its not an entirely free license on it [00:02] up_the_irons: that's bash code. [00:02] up_the_irons: That's quite crazy. [00:02] blueyed: i've seen bash code in other debian/rules files [00:02] * StevenK tries to stop his eyes bleeding [00:03] up_the_irons: The main problem is that you don't have enough ';'s, I think. [00:03] up_the_irons: And I don't believe you can use fi there. Because this is a *single* line being run by sh. [00:03] RAOF: thanks, yeah, someone in #debian just pointed that out [00:04] RAOF: i'm looking at the debian/rules for xen-linux-system-2.6.18-4-xen-686, and it indeed uses 'fi' [00:04] RAOF: as an example [00:04] Fair enough. I'm not a sh fiend by any means. [00:04] nor am i, but seems i keep running into it [00:05] up_the_irons: you need additional semicolons.. after commands, and before fi probably. [00:05] You certainly can use 'fi' in one-liners, you just need to be mindful of where you put your semicolons [00:05] Also, you should spell confirm CONFIRM, not ONFIRM :) [00:06] RAOF: yeah, it *is* $CONFIRM, but somewhere it got lost in the paste ;) [00:06] blueyed: thanks [00:07] up_the_irons: Oh, yeah. You actually want $$CONFIRM, otherwise make thinks you're referencing the variable $C [00:07] RAOF: aah [00:07] RAOF: good catch [00:08] oh man, maybe i should just make a shell script [00:09] this is getting weird [00:09] i guess in the packages i'm looking at, the if's are indeed oneliner's [00:09] up_the_irons: Your problem is that you're trying to write a shell script inside a make file. So you're fighting your tools, which is never fun. [00:09] yup, that was it [00:10] RAOF: i know, i know... i'm just not very good at makefiles; and i'm trying to learn the packaging thing at the same time. so i'm tripping over myself [00:11] For example, it looks like you could make a linux-2.6.18-xen.hg target, and make build-stamp depend on that. [00:11] RAOF: yup that's exactly what i'm typing right now ;) [00:12] i saw shell in other debian/rules files and i figured "yay, i can use shell in makefiles". i was wrong [00:12] just simple 1-liner shell [00:18] now *that's* better: [00:18] http://p.caboo.se/151279 [00:21] so question [00:22] when i run dpkg-buildpackage, and it does its thing, is that when any changes I made into the source tree get reflected in the diff.gz ? [00:22] depends on the option [00:22] I don't *think* you have to even have those shell ifs there. You should be able to declare a linux-2.6.18-xen.hg target. [00:22] up_the_irons: now you could depend on the file, instead of the if.. :) [00:22] blueyed: dood, i tried that [00:22] blueyed: it said unknown target [00:23] RAOF: yeah, i figured the same, but it said unknown target [00:23] up_the_irons: You'd need to have a "linux-2.6.18-xen.hg:" line, containing the hg clone command. [00:23] so I can merrily make changes in the source tree, and it'll automatically become part of the diff? [00:23] RAOF: oh [00:23] RAOF: ok [00:23] blueyed: Are you still looking at gnome-do? [00:24] RAOF: the last time I wrote my own makefiles from scratch was in the Turbo C++ 3.0 for DOS days ;) [00:26] RAOF: in my free time during fixing my own package, I'll try a build now and then probably advocate, looks good! [00:27] blueyed: I can upload a new candidate with the changes you've requested if you like. [00:27] But they won't affect the build, so if you just want to advocate I'll upload the changed package to universe :) [00:28] RAOF: sounds good :) [00:28] RAOF: that worked, now I have a much cleaner: http://p.caboo.se/151282 [00:28] blueyed: To the new revu upload, or the advocate-and-me-upload approach? :) [00:29] up_the_irons: Things look *much* cleaner when you don't fight your tools :) [00:30] both indeed.. but persia has also looked at my package. you might want to check out debian/copyright, but I'll have to add more headers and preambles there. [00:30] The package is jedit. [00:30] RAOF: indeed :) [00:31] blueyed: Ok. The new candidate should show on revu shortly. I'll check out jedit. [00:41] blueyed: I see why persia suggests using make variables for your get-orig-source target. It seems you could define version & uversion as make variables, and possibly split get-orig-source into get-upstream-source & repack-upstream-source targets. [00:42] Something like "version=$(shell dh_testdir && uscan --dehs | sed ..etc)" [00:43] I'm also not a big fan of the side-effect of setting version being that the tarball is downloaded. [00:46] that from the tarball? it's a check only there. [00:47] blueyed: "version=$$(uscan --force-download ...)" [00:47] RAOF: would it be ok to be called from "anywhere" then? [00:48] blueyed: With the make variables? You'd still need to cd ${DEBIAN_DIR}/.. first, yes. [00:49] I haven't worked it through, but I believe it'd end up looking cleaner. [00:49] RAOF: but still shell like? with && and on the same line? (because of e.g. the "cd") [00:50] Yeah. You'd need to have it shell-like. The difference would be that you would have a bunch of smaller, split up shell lines. [00:51] blueyed: Oh, actually, no! "version=$(shell cd ${DEBIAN_DIR}/.. & uscan --dehs | ...)" would be callable from anywhere. [00:51] wow.. there's even a version hardcoded currently. [00:51] With a single "&"? [00:51] Ahem. && :) [00:53] should I not get the version/uversion from the sourceball? Just define them at the top of the rules? [00:54] That *will* get the version/uversion from the sourceball. Make variables defined with "=" are pretty much recursive text-substitution (IIUC), so it's evaluated only where you dereference it. [00:55] IE: when you go "$(version)", make will replace that with "$(shell foo)", then evaluate $(shell foo). [00:55] in contrast to ":="? [00:56] Yes. ":=" means "evaluate right now". [00:58] heya people [00:59] ... the package finally built, now to see what are conffiles [01:01] RAOF: better? http://pastebin.com/m2c01a479 [01:02] up_the_irons: you define them in "conffiles", that are those where you're asked during upgrade when you have changed them yourself, and the maintainer, too. [01:03] blueyed: ok thanks. what do you mean by "and the maintainer, too" ? [01:04] the package maintainer: you're only asked, if the maintainer changed the default conffile, to merge your changes or take his (or keep yours). [01:04] blueyed: That doesn't actually work, does it? Sorry, I've been unclear. I was thinking of defining version=$(shell foo) just above (and outside of) the get-orig-source target, or even at the top of the file. === Martinp24 is now known as Martinp23 [01:06] And you won't need to cd ${DEBIAN_DIR} in your get-orig-source; the only reason you needed to do that is to make uscan work, yes? [01:07] blueyed: ok thanks for the info [01:10] regarding the generated diff.gz, that is the difference between the -orig.tar.gz and the build directory? [01:11] actually, looks like there is a directory that should not be represented in the diff (b/c it is downloaded by hg), is there a way to ignore it, or should that in fact remain in the diff? [01:12] * StevenK gets confused. I build gnome-games, and it has undefined references to things that are defined in the same file [01:13] mm.. and why is it trying to diff build files (like *.o).. [01:13] crap "dpkg-source: unrepresentable changes to source" [01:14] up_the_irons: clean them in your clean target. [01:14] blueyed: ok [01:14] RAOF: yes, it totally not works currently. and ${DEBIAN_DIR} does not seem to work for ./rules binary anyway?! [01:15] blueyed: but is there a way to just ignore certain directories? b/c if i clean them, the next time i build this package, say to add a single kernel module, it will want to rebuild the entire kernel [01:15] blueyed: what is the way to do this so i don't fight my tools? :) [01:17] up_the_irons: Those are restrictions of the debian-source-package format. You can use dpkg-buildpackage -nc to try to build without cleaning first, but debian/rules clean should take you back to a pristine build directory. [01:17] maybe i should just cp -a them out of the tree, and put them back when i need them. ghetto style ;) [01:17] RAOF: ok, i kinda thought so [01:18] RAOF: i could just save the build directories somewhere, and copy them back when i need them, as if they were always there. this package is for my use only, not gonna distribute it [01:18] RAOF: i just really hate to recompile the whole kernel just for a simple change [01:19] RAOF: if I *didn't* use a package syste, i could do it no problem. So I want to stay package friendly, but hopefully not lose the benefits of a build system (that only builds stuff that has changed) [01:19] *system [01:19] up_the_irons: Have you checked out the ubuntu-kernel buildy thing? That might be what you're after. [01:19] brb [01:19] RAOF: you mean build-kpkg, or something [01:19] *make-kpkg [01:20] No; there's some new infrastructure in the Ubuntu kernel source pacakages. [01:20] no i haven't tried that [01:20] but this package is from xen-3.2.0 tarball [01:20] i have a feeling it will be hard to integrate [01:20] not a vanilla kernel [01:20] what I'm aiming for is, a single .deb that contains everything I get when I do 'make install' from the Xen tarball [01:21] so far, I've gotten close [01:21] in fact, debian/xen does contain the entire built tree [01:21] now it's just a matter of packaging it [01:22] ok, been sitting down too long, brb in 10 mins [01:24] Aw, man. What with the nouveau testing I'd forgotten how awesome compiz is. [01:26] RAOF: What the? [01:27] I find I can't drag windows between viewports anymore, which is irritating me. [01:27] I've been using metacity's compositor. Changing workspaces is supremely ugly, compared to cube. [01:28] WorksForMe(tm) [01:29] I have to expose out using Super-e, drag and them go back in [01:30] Hm. You're using wall or cube? [01:30] persia: I'm fine with the watch file [01:31] StevenK: You might want to check out the various "edge flip" options in ccsm? [01:32] RAOF: gnome-do is similar to katapult, isn't it? It also does not support "f1" for help at least.. ;) [01:33] RAOF: advocated. [01:34] blueyed: I don't know, I've never used katapault. Also, correct. No f1-is-help yet :) [01:34] blueyed: Thanks. Yay! [01:35] what is the "this is a merge" heuristic [01:35] when activating it again here on kde4, it does not display, but grabs input.. [01:35] it seems like if I say the D word anywhere in the changelog it's officially a merge :) [01:35] blueyed: Don't tell me that kde4's compositor is broken, too? [01:36] RAOF: I've no desktop effects enabled.. [01:36] blueyed: I saw that behaviour on Metacity, but it's been partially fixed. It should work fine without a compositor or with xcompmgr or compiz. [01:36] blueyed: Really? Hm. [01:37] it's the same with desktop effects.. [01:37] up_the_irons: Have you checked out the ubuntu-kernel buildy thing? That might be what you're after. February 13 01:44 MOTU chalserogers@gmail.com Addressed comments from blueyed in #motu Yes [del] [remove advocating] [01:37] Frikkin touchpad! [01:37] i have to click somewhere around to get the input back.. it actually starts programs, but I can't see it before.. [01:38] blueyed: I've only seen that with broken compositors, but I haven't tried it in KDE, either. [01:38] RAOF: I know that as slammermaus, based on when I first starting using IRC. A guy was nicknamed slammer (not his actual nick), and he kept blaming his mouse for pasting large gobs of text into the channel. [01:39] I should find the irssi knob that disables pasting. It already saves me from accidentally pasting in *huge* ammounts of text.. [01:49] For those in the audience, paste_verify_line_count is the irssi variable I'm looking for. [01:52] paste_detect_keycount [01:53] RAOF: You set that to one, and it asks you for even one line? [01:56] RAOF: re-uploaded jedit (a new upload with only minor licensing indenting and re-order ("*" to top), uploaded afterwards (should appear at 2utc then) [01:56] StevenK: Yup. Just checked. [02:01] blueyed: Ok. I'll keep looking. [02:06] in the clean: target, what is the minus sign before "-$(MAKE) clean" for? [02:07] (this is in the generated template) [02:07] for generating a lintian error [02:08] slangasek: ok [02:08] up_the_irons: It means "ignore errors from this command", and what you actually *want* is [ ! -f Makefile ] || $(MAKE) clean [02:09] Which translates to "If the makefile doesn't exist, do nothing. If it does exist, run make clean" [02:13] * asantoni looks for advocate for LP #190589.... :) (any MOTU with a few spare moments?) [02:13] Launchpad bug 190589 in mixxx "New upstream release (in REVU)" [Wishlist,New] https://launchpad.net/bugs/190589 [02:14] RAOF: ah ok [03:10] ls [03:11] What, you mean that won't list all the files in #ubuntu-motu? Soft! [03:11] blueyed: jedit fails to build a source package for me - is this likely to be a build-dep lack on my part? === _stink__ is now known as _stink_ [03:12] RAOF: do you have ant installed? [03:12] It would seem the answer is "no". [03:12] RAOF: I've just uploaded a new version (and messed around quite a bit in the meantime) [03:13] blueyed: Ok. Does it really depend on java5-runtime? [03:13] RAOF: icedtea-java7-jdk, ant, ant-optional [03:14] blueyed: I mean, debian/control lists java5-runtime as a dependency of the binary package. Did you mean icedtea | java-v-m | java5-runtime? [03:15] Right. I'll check out the new, new package then :) [03:15] RAOF: yes, indeed. Should I put j-v-m last even? [03:16] isn't there a nice way to say use a virtualpackage that represents a jre? [03:16] That should surely be java-virtual-machine, no? [03:16] Or is it java-runtime? [03:17] There was a page somewhere with a non-exhaustive list of virtual packages, but I can't remember where. [03:17] i think its java-virtual-machine [03:17] yeah it is, but it doesnt list icedtea yet [03:17] unless he has a specific list of VM's he wants to try in order of preference... [03:17] it lists sun-java6, sun-java5, sun java 1.4, etc [03:18] so icedtea | java-virtual-machine should do it [03:18] superm1: but it's not really versioned, is it? Will take it as such though. [03:19] well icedtea is the only one that doesn't provide java-virtual-machine it looks like [03:19] I'm also removing the ${shlibs:Depends} which is not needed for java packages, correct? [03:19] so it should cover your bases [03:20] blueyed: If you'd like this to be backportable, you might want to drop the debhelper dependency (and compat) down to 5, unless you use any of the new behaviour. [03:20] well, e.g. ant has java-gcj-compat-dev | java-virtual-machine, java-gcj-compat | java1-runtime | java2-runtime - so it's something different?! [03:20] RAOF: yes, thanks, forgot about that.. [03:20] Fujitsu: Thanks. [03:21] ScottK: No problem. [03:21] I figured I was doing enough security work I might as well sign up for the official club. [03:21] Heh. [03:22] Which reminds me ... [03:22] jdstrand: How clamav going ... [03:23] RAOF, superm1: therefore it was correct already I think.. (icedtea-java7-jre | java-virtual-machine, java5-runtime) [03:23] yeah :) [03:25] Yeah, fair enough. All the *jre packages provide java5-runtime. [03:27] icedtea-java7-jre should provide java-virtual-machine though.. this is probably the reasond why gcj gets pulled in for the build.. [03:29] Oh, dear lord licensing sucks. [03:29] Cosmetic: you may want to put each file on a separate line, and they should be comma-delimited. [03:30] RAOF: that would make it much longer.. I've probably missed something minor, but heard that it would be ok. Only that all different licenses are important. [03:30] Also, if the files are uniquely named you don't *have* to use the full path, */name is implied. [03:31] Yes, I've copied and pasted them.. I should it could not hurt to be explicit there. [03:32] Yeah. It's really cosmetic. [03:32] RAOF: did you file that licensing bug on tomboy? [03:33] LaserJock: Yes. [03:33] bug 189953 [03:33] Launchpad bug 189953 in icedtea-java7 "Inconsistent 'Provides' for different java compilers/runtimes" [Wishlist,Triaged] https://launchpad.net/bugs/189953 [03:33] RAOF: did you happen to see mjg59's comment in -devel about it? [03:34] blueyed: But, as I understand it, it's not properly conformant to the proposed machine-readable format unless the lists are comma-delimited. That's not going to block my advocation at all though. [03:34] RAOF: I'll check that in the next round of changes. [03:36] Re-uploaded with compat and shlibs:Depends minor change. I'll have to catch some sleep now.. [03:37] dang, I may end up with way more Multiverse uploads than anything else for Hardy :/ [03:37] LaserJock: Sorry, my buildbox is thrashing thanks to jEdit. [03:38] anyone here into blog-ranting about usability related issues? [03:38] I found an amusing one from Leopard's recent update [03:38] LaserJock: No, I didn't see the comments, should I? [03:38] http://www.dslreports.com/r0/download/1274378~d987d620159d1c354525056af832b2b1/Picture%201.jpg [03:38] prizes go out to those who explain what that charge status actually means.... [03:38] jdong: That's *awesome*. [03:39] lol [03:39] RAOF_: he just basically said that in his opinion a blanket license is sufficient when it's clear, like there aren't inconsistent licenses [03:40] LaserJock: So the licensing is OK, how about copyright holders? That makes things easier, though. [03:40] not sure [03:41] but you tend to get different answers depending on which archive admin you talk to ;-) [03:41] just thought you might be interested [03:41] Oh, certainly. [03:41] It seems there's no end to the things you can learn about licensing :) [03:42] s/learn/get incredibly, horribly confused/ [03:42] Heh, amen to that [03:49] Damn you bugzilla. Why must you make me work so hard to file bugs? === ember_ is now known as ember [03:59] has anyone here tried using minicom in Gutsy? [04:01] i did [04:01] but i didn't have luck with it when i tried [04:03] yeah i had to run minicom -s [04:03] and had to change the defaults === kdu1 is now known as kdub [04:03] joejaxx: I used it sucessfully to connect to a serial console interface on a Sun T2000 [04:06] Thanks to whoever uploaded my kompozer diff - the new version just hit my mirror. (Meanwhile, I found a LP bug...) [04:06] dendrobates: NICE :D [04:06] i am trying to reset the password on a Cisco Router :P [04:06] with minicom [04:06] :P [04:07] but i got it to connect now === calc_ is now known as calc === Frogzoo_ is now known as frogzoo === asac_ is now known as asac === Hit3k_ is now known as Hit3k [05:24] hey if another motu wouldn't mind giving this a quick once over: http://revu.tauware.de/details.py?package=libnet-upnp-perl [06:10] Good morning === boomer` is now known as boomer [06:54] revu down for everyone else? === calc_ is now known as calc [07:27] if motus still have access to revu then could someone check the latest version of whysynth. it's already been advocated a few timces but i've needed to adjust the package due to licensing issues [07:27] the latest version is done according to sistypotys comments [07:27] The machine is alive, but it appears fairly sick. [07:27] * Fujitsu wonders if it's out of disk space again. [07:31] * RAOF finishes his 2 hour update-miro's-copyright stint. [07:34] Ha! I speak too soon :( [07:42] slomo, could you please comment on bug #191307? [07:42] Launchpad bug 191307 in f-spot "f-spot man page missing mono warning" [Undecided,New] https://launchpad.net/bugs/191307 [07:42] I think it's not a bug, but the submitter sternly disagrees [07:43] LucidFox: it's just that the reporter doesn't like mono? [07:43] or do i miss anything [07:44] seems so [07:44] close please [07:45] closed [07:46] thanks [08:01] good morning [08:56] Riddell: I've reuploaded wzdftpd, the diff is cleaner === \sh_away is now known as \sh === \sh is now known as \sh_away === \sh_away is now known as \sh [09:10] revu seems to be broken (timeout) [09:12] <\sh> yepp [09:12] slangasek: Are you still up and about perhaps? [09:12] \sh: Did you see my IRC comment on your Perl packages? [09:13] <\sh> ScottK, nope...revu is down somehow [09:13] OK. [09:13] \sh: It was about debian/copyright. I think it's better to redistribute on as generous of terms as possible. [09:14] morning folks and folkettes [09:14] <\sh> ScottK, you mean that I should explicitly write in debian/copyright that the upstream source could be licensed as GPL or artistic as perl does? [09:15] \sh: That's what I think would be better. [09:15] norsetto: folkettes? are you hungry? :) [09:15] <\sh> ScottK, ok...changing it...anything else? I think packaging wise is everything in order [09:15] \sh: https://launchpad.net/ubuntu/+source/libtree-perl has what I'd consider to be a good example. [09:15] DktrKranz: neah, just being politically correct (its the gender equality era....) [09:16] \sh: I only had to to review the diff, not test build so far. If you can stuff the packages somewhere and give me a .dsc link, I'll give them a final review. [09:16] norsetto: so it's better saying "morning folkettes and folks" [09:16] \sh: The debian/copyright thing we all that stood out from reviewing the diffs. [09:16] Good morning norsetto. [09:17] ScottK: congrats! [09:17] <\sh> ScottK, ok...I'll change the debian/copyright and push some packages on my webserver ... [09:17] \sh: Thanks. [09:17] DktrKranz: Thanks [09:17] ScottK: heck, what do you do here? Don't you have a bed somewhere!? [09:17] <\sh> ScottK, no thank you :) [09:18] norsetto: We're having an ice storm here and about 45 minutes ago one of our dogs was stuck out in the back yard (couldn't get up the steps to get back in) and so after a trip out in the cold rain to rescue her, I'm not able to get back to sleep. [09:19] ScottK: oh, do you know by any chance if it is so bad in minnenapolis too? [09:19] norsetto: It's February. You can generally figure it's very cold there. ;-) [09:20] norsetto: We're far enough away that it's a different weather pattern. They probably had this precipitation in the form of snow two days ago. [09:20] norsetto: You aren't coming this way to visit are you? [09:20] ScottK: My wife is headed there right now [09:21] norsetto: Ah. Excellent reason to worry. [09:21] * ScottK checks the weather. [09:24] norsetto: It's cold and snowy, but nothing unusual for Minneapolis. No severe storms. [09:24] scottk: ok, thanks, I was hoping to hear that [09:25] norsetto: What's in Minneapolis? [09:25] ScottK: a friend of her [09:26] Ah. Well they get lots of snow this time of year (I was there last December) and they generally know how to deal with it. [09:27] <\sh> scottK, please check out http://buildserver.homelinux.net/src/ there are both packages [09:27] scottk: yeah, they might, I'm not so sure about my wife though, she can hardly drive here and she absolutely wanted to rent a car, oh well.... [09:28] norsetto: One thing they are good at is plowing and salting the streets. [09:28] \sh: Will do. [09:29] \sh: If I'm satisfied with them do you want me to just upload them or do you want the pleasure? [09:29] <\sh> SCottK: well, if you are satisfied, just upload straight away :) [09:31] Will do. [09:32] <\sh> and dpkg is fixed, too ... wow [09:35] Congrats other -release members. [09:40] * ScottK looks to see if that applies to him .. [09:40] scottK, TheMuso, norsetto, hobbsee (absent), sistpoty (absent): congratulations! [09:40] dholbach: Thanks. [09:40] I'll set up the team and send out the mail in a bit [09:40] need to fix up something else before [09:41] dholbach: what for? We haven't started already :-) [09:41] norsetto: Better to be ready when the flood gates open. :p [09:41] TheMuso and norsetto: we should probably find a time to conspire on rules. [09:41] ScottK: Sounds like a plan. [09:42] * norsetto wears his frost-proof hat [09:42] ScottK: I'm surprised you are awake actually. [09:42] errr, where is that link btw? [09:42] TheMuso: Scroll back about 25 minutes for an explanation. [09:44] ScottK: Ah, that sucks. === zakame__ is now known as zakame [09:59] Any MOTU hopeful want to work on a bug fix (I'll provide guidance). There's a patch, it just needs to be packaged. [10:00] ScottK: what's the package? [10:00] isaac: https://bugs.launchpad.net/debian/+source/pdns/+bug/191506 [10:00] Launchpad bug 191506 in pdns "TXT records truncated" [Low,In progress] [10:00] not interested :P [10:00] Feel free to assign it to yourself instead of me if you want to try it. [10:01] OK [10:01] bug 125658 might be interesting to work on too - it seems to block the blender folks [10:01] Launchpad bug 125658 in openexr "please update openexr version" [Wishlist,Triaged] https://launchpad.net/bugs/125658 [10:01] (I realise that openexr is in main, but most of the rdepends that would need to go through a small transition are in universe) [10:04] hello [10:04] is there something wrong with REVU's website ? [10:07] AnAnt: Yes [10:08] ScottK2: ok [10:08] thanks [10:08] I thought something wrong with my connection [10:09] <\sh> scottK: you mean http://wiki.powerdns.com/cgi-bin/trac.fcgi/changeset?old_path=trunk%2Fpdns%2Fpdns&old=996&new_path=trunk%2Fpdns%2Fpdns&new=996 ? [10:09] there was been some discussion about sudo policies? ( i'm lookin at bug #191210) [10:09] Launchpad bug 191210 in sudo "[hardy] exit out of sudo -i doesnt really exit" [Undecided,New] https://launchpad.net/bugs/191210 [10:09] \sh: Yes. I haven't checked to see if it applies to our current version directly or needs a bit of work. [10:10] <\sh> scottK: I set it on my todo [10:10] \sh: Great. Thanks. [10:10] * ScottK is looking at your packages now. [10:10] good morning [10:11] Good morning geser. [10:11] <\sh> ScottK, reassigned the bug [10:11] OK. Thanks. \sh: I have someone who runs pdns who will test the package when it's done (if you don't). [10:12] hmmm, can anyone tell me where I can get help about makefiles ? [10:12] ScottK: Just got my first uplaods to main in, due to a spec I was working on. I felt rather nervous. :) [10:13] <\sh> scottk: cool :) I think the bug is also annoying pdns users in dapper/edgy/feisty/gutsy... [10:13] TheMuso: Congratulations. I haven't done it yet. [10:13] \sh: I'm not sure if it's SRU worthy or not, but since I'm not in motu-sru, I guess I don't need to have an opinion. [10:13] ScottK: We'll see if everybody's boot succeeds first, then congratulations are likely in order. :p [10:14] In all seriousness, I tested and re-tested my changes, so there shouldn't be a problem. [10:14] <\sh> scottk: well, backporting is always an alternative [10:15] Sure [10:17] \sh, which one? [10:18] <\sh> DktrKranz, pdns [10:19] hm, revu is down? [10:19] Yes [10:20] ff tore it apart or is it just 'closed' because of ff? [10:22] \sh, if you mean bug 191506, when you have a patch, we can discuss at it briefly, but it looks a good candidate. [10:22] Launchpad bug 191506 in pdns "TXT records truncated" [Low,In progress] https://launchpad.net/bugs/191506 [10:22] It was having hard drive troubles yesterday. [10:23] ouch [10:24] dholbach: ping ? [10:25] Tonio_: pong [10:26] dholbach: hey ;) I hope you're doing well [10:27] Tonio_: thanks, yes I am - how are you? [10:27] dholbach: my team membership for ubuntu developpers is expiring in a few days, I'm supposed to ping you to get it renewed :) [10:27] dholbach: very well :) currently working on the kde implementation of sudo for kde4, good progress so I'm a happy guy :) [10:28] Tonio_: let it expire, as long as you're in ubuntu-core-dev and/or motu all is good [10:28] Tonio_: in the end ubuntu-dev will only consist of ubuntu-core-dev and motu [10:29] dholbach: oki ;) [10:29] dholbach: true that core-dev is sufficient for everything ;) [10:40] /c/c [10:46] * pochu waves [10:47] hey pochu :) [10:47] thanks for your msg :) [10:48] Ng: anytime, thanks for the fix! [10:48] * pochu hugs Ng [10:49] I'm going to risk flames from my gf tonight and cut a release. I've fixed all the bugs I can in time, and FF is tomorrow ;) [10:51] Ng: I do it all the time ;) [10:51] hehe [10:52] speaking of which, I'd like to let the MOTU Release Team to know that I'm about to upload a new version of vdr (1.4.7 -> 1.5.13) soon [10:52] and some new plugins too [10:53] upstream decided to do a stable release before plunging in the HDTV world, so 1.6.0 should be out in a couple of weeks [10:53] dholbach i think the libdc1394 should be ready for inclussion? what do you think? [10:53] and I have upgraded my box with the new packages, works like a charm [10:53] dholbach check it here: http://revu.tauware.de/details.py?package=libdc1394-22 and the compiled PPA here: https://launchpad.net/~libdc1394-dev/+archive [10:55] tjaalton: ace :) [10:55] Ng: I should update the spec too [10:55] ugh, and I should apologise for not having been near the spec since UDS :/ [10:56] me neither, until last week ;) [10:56] we should decide the name for the meta-package :) [10:58] tjaalton: Do it before Feature Freeze and we don't need to know ;-) [10:59] ScottK2: that's what I'm aiming for ;) [11:00] so anybody on MOTU that could advocate the libdc1394-22 package inclussion? [11:00] it is ready, just needs someone to advocate it... [11:01] theseinfeld: it is a different package than in Debian unstable? [11:01] yes [11:01] as I am one of the developers, I am closer to the truth [11:01] :D [11:01] any reason for being different? [11:01] I have been working with the Debian people [11:02] Stubborness of Debian? [11:02] :D [11:02] can't we sync the package from Debian? [11:02] No [11:02] you do that and you get crap [11:02] it is missing things [11:02] it has some problems with the naming [11:03] the debian was lagging alot behind with this library [11:03] i have been trying for one year with them to get them involved and when I got their attention they wanted just to have minor changes and still using the old framework [11:04] you can sync, but you will lose some of the added features [11:05] so, geser, what shall it be [11:06] theseinfeld: I was just asking as I've seen it in Debian and we usually take packages directly from them [11:06] I know [11:06] superm1: around? [11:06] superm1: 11:48 < slomo> pochu: any other changes for -bad? btw, you could tell superm1 that the gst-plugins-bad gmyth plugin doesn't support gmyth 0.7 [11:06] superm1: 12:00 < slomo> pochu: ok, so still... you have 0.7 in hardy and upstream gmyth only works with gmyth >= 0.4 gmyth <= 0.4.99 [11:06] superm1: 12:00 < slomo> pochu: if there's a fix to work with the new version i'll be happy to get it upstream ;) [11:06]