[00:00] You know, it'd be awesome if libdrm released 2.3.1 in time for hardy. Nouveau >> nv. [00:03] mok0: I was looking at torque's license yesterday, it feels like a 4-clause BSD license to me (without the parts that has expired). And I'm not sure if 4-clause is good enough for main/universe. [00:04] minghua: Hmmm [00:04] minghua: Can we ask to get it into multiverse? [00:05] is anyone here using xen on hardy who would like to test out some grub changes for me? [00:05] mok0: I have no idea, it may require ubuntu.com pages to add an advertisement clause. [00:06] mok0: I've never dealt with 4-clause BSD before. [00:06] * mok0 looks up torque's license [00:07] Is 4 clause the same as 3-clause plus advertising clause? [00:09] 3 and 4 are pretty much the same [00:10] 3 is source distribution and 4 is binary [00:10] Yes, I think the difference is exactly the advertising clause. [00:10] 5 is not a problem [00:10] 6 is the advertising clause [00:10] 7 is the disclaimer [00:11] but there are no real restrictions [00:12] I suggest that we try to finish the package and get it to an archive admin [00:13] mok0: You don't see "All advertising materials mentioning features or use of the Software must display the following acknowledgment" as a restriction? [00:13] minghua: it's a duty, not a restriction. [00:13] mok0: That part I agree. Nobody except the archive admin's words count anyway. [00:13] minghua: yes [00:14] Well... So GPL's source requirement is a "duty" instead of "restriction" too? [00:14] It would not even interfere with Canonical's advertising of Ubuntu. Only if the product is mentioned as a selling point [00:15] If used for research, it would not be "advertising" [00:16] minghua: GPL source requirement, yes I interpret that as a "duty" [00:17] you fulfill the duty, and there is no restriction [00:17] But IANAL [00:17] mok0: I'm not arguing that we can use it in our research groups, I'm arguing if Ubuntu can officially ship it in its archive. [00:18] minghua: yeah, and I don't feel qualified to answer that question [00:18] advertising clause is long-accepted; it's goofy, but the practical impact is approximately zero [00:18] OpenSSL has the BSD advertising clause, for instance [00:18] slangasek: take a look: http://revu.ubuntuwire.com/revu1-incoming/torque-0801141530/torque-2.1.8/PBS_License.txt [00:19] slangasek: So debian/copyright suffice for the advertise requirement? [00:19] minghua: er, the BSD advertising clause almost *never* goes into effect [00:19] because the trivial way around it is to simply not advertise the features of this software ;) [00:19] * minghua go read 4-clause BSD. [00:20] mok0: that license fails to be a free license because it only permits non-commercial, non-profit redistribution [00:20] Say, Canonical creates an advertising flyer, where it says "Featuring the batch system Torque", they'd have to put a footnote with the clause in [00:20] slangasek: points 1 and 2 have expired [00:20] mok0: oh, right, sorry :) [00:21] fortunately [00:21] yeah, so 6) is "BSD advertising with the serial number filed off"; the requirement is the same, only the name of the institution is different [00:22] the references to 6) /from/ 3) and 4) are odd, but I think are satisfied by shipping the license in debian/copyright, yes [00:22] slangasek: so, what's the verdict, in your opinion? [00:22] still reading the whole license [00:22] slangasek: that whole license is weird [00:23] mok0: it's a BSD license that's been modified by an amateur [00:23] and by "amateur", I probably mean "lawyer" [00:23] slangasek: :-D [00:24] slangasek: It's paid for with government money, anyway [00:24] US government, that is [00:28] ScottK: pingaroo [00:32] LaserJock: Pongero [00:32] regarding clamassasin [00:32] yeah? [00:32] this is Feisty only? [00:32] Yes [00:33] Gutsy + is fixed and Dapper/Edgy have an old enough clamav it's not a problem [00:33] right [00:33] I wonder how easy it'll be to get testers [00:33] I'm going to backport the new clamassassin in backports, but I don't think it's right to paper over SRU worthy bugs with a backport. [00:33] seems like most people who'd have hit the bug would've changed that option or moved to something else [00:33] I'd really love it, actually, if you'd tell me no. [00:33] I agree [00:34] But I want to DTRT [00:35] it would seem to me that this would really only be relevant for new Feisty installs [00:36] Of which it'd be stunning if there were any at this point. [00:37] LaserJock: Here's my clamav plan for world domination: https://launchpad.net/~ubuntu-clamav/+archive [00:37] Fun day's work. [00:37] leonel: The revised clamav PPA upload for dapper is built, please test again. [00:37] these are the times that I wish we could issue package errata just to document silly things for people without having to go through the mess of a new package ;-) [00:38] Please tell me SRU denied, work around is to manually edit the config. [00:39] 46 uploads in one day is not so bad. [00:40] * ScottK is waiting for the PPA denial of service police to show up. [00:40] yep, looking at the criteria on the wiki page it really doesn't rise to a "high-impact" bug [00:40] Excellent. [00:40] Please mark the bug and I'll move on. [00:41] * ScottK rejoices in the power of not being the one who has to decide. [00:43] ScottK: Did you eventually use gcc-3.4 to compile on dapper? [00:44] minghua: I did [00:44] Good to know. [00:46] ScottK: ok, I think that should be clear enough [00:47] Thanks. [00:47] * LaserJock wonders how likely he is to get roasted by users for doing is first SRU rejection === emgent is now known as emg [00:47] At least there's no confusion now. [00:50] Most users don't know such a thing as "SRU request" exists anyway. [00:50] BTW what is a pingaroo? [00:50] well, it's a kangaroo/ping hybrid [00:51] it's a ping that kinda hops around [00:52] Oh. I thought it is a ping that use kangaroos, instead of pigeons, as the packet carrier. [00:53] kinda, more bouncy that way [00:55] man, StevenK needs to stop upload config-crown-beach, I keep reading it as config-crown-royal [00:56] Mithrandir uploaded it before I did, so nyah [00:57] Anyway, Crown Beach is a codename [00:57] leonel and sommer and anyone else interested in clamav on Dapper: Testing needed: Bug #183914 [00:57] Launchpad bug 183914 in dapper-backports "Please Backport clamav-0.92~dfsg-2 from Hardy to Dapper" [Wishlist,Confirmed] https://launchpad.net/bugs/183914 [00:57] Heya gang [00:57] StevenK: I noticed a number of config-* today [00:58] jdong: I'd like confirmation that we can do the above ^^^ without special permission from the tech board or something. [00:58] LaserJock: And? [00:58] nothing much [00:58] I wonder what they are configuring, but I'm not really up on UME [01:00] * imbrandon yawns [01:00] LaserJock: They're tiny packages. I suspect it wouldn't be hard to find out. :-) [01:01] Goodnight, people [01:02] Gnight mok0 [01:04] StevenK: you've got a point ;-) === emgent is now known as \emgent === \emgent is now known as emgent [01:10] scottK clamav-base installed fine but python-clamav pulls libclamav1 [01:10] The following NEW packages will be installed: [01:10] clamav-freshclam libclamav1 python-clamav [01:11] and only clamav-freshclam comes from PPA === ember_ is now known as ember [01:46] greetings [02:03] Heya Hobbsee [02:29] Hmm, chrpath is change RPATH? [02:29] Heya Hobbsee [02:30] bddebian: Yup [02:30] I got kara attuned last night ;) [02:30] lifeless: Huzzah [02:30] * StevenK is probably doing Dire Maul tonight [02:31] Hrm.. I wonder why chrpath /usr/lib/btanks btanks causes RPATH to be ' ' [02:31] bddebian: yes; with RPATH being the third thing one is likely to want out of objdump -p $lib. ;) [02:32] bddebian: because you left out the '-d' option? === bmk789 is now known as bmk789_sick_bed [02:32] Sorry, this is what she has in rules: chrpath --replace /usr/lib/btanks btanks [02:33] slangasek: Were you going to talk about RPATHs today? :) [02:33] grr [02:34] * joejaxx should make a mptstatus-ng package [02:34] :\ [02:34] the current one does not work on newer hardware [02:34] * bddebian should have asked for removal of ladder.app and lapispuzzle.app instead of trying to adopt them.. :( [02:34] what are those? [02:35] games? [02:35] Lame games [02:35] I tend to want to remove everything, then I get yelled at :_ [02:35] bddebian: well, I was going to throw in a passing reference, but we moved on and it wasn't that important [02:35] Err :-) [02:36] ... because you shouldn't usually be using rpath at all [02:36] anyway, I don't see why it should behave that way using --replace [02:36] try running the command by hand to see if you get the same result? [02:36] Well aye but it has libraries that shouldn't necessarily be in /usr/lib I guess [02:37] I also get "foo shouldn't be linked to bar" stuff but I can't get rid of them. It's an smake package :( [02:38] bddebian: I maintain that there's no such thing as a library that shouldn't be in /usr/lib [02:38] Seriously? [02:38] I'm down with that [02:38] I think it's pretty common to get "shouldn't be linked to libfoo" warnings these days? [02:38] having a heirarchical namespace for libraries causes subtle bugs, and I think we're better off without, no matter how trivial one might consider the lib [02:38] as for smake, don't look at me [02:38] Actually I lied, it's scons.. :-) [02:38] run [02:39] run screaming [02:39] I don't know why she does lib_dir=$(CURDIR) [02:39] run screaming and waving your hands [02:39] *aaaaaaaahhhhhhh* [02:39] * mneptok waves his claws [02:39] slangasek: If I did that would I have to create a libs package? [02:39] DANGER WILL ROBINSON! [02:41] Removing the libs from SConscript doesn't help with the shouldn't be linked errors either :( [02:42] I don't care much for libraries [02:42] I hear ya brother :-) [02:42] I wish I could deal with them better [02:42] Who's the gnustep lover around here? [02:42] but licensing is a bugger with GPL 2 vs 3 [02:42] figuring out if libs should be build, soname "stuff", etc. [02:43] *built [02:43] I FINALLY got the soname stuff figured out a while back, thanks to ajmitch [02:43] mneptok: LOl [02:43] bddebian: i took GNUstep to the prom, but only out of pity. [02:43] heh [02:44] Actually I think I argued the RPATH point with Baby once before and lost === StevenK_ is now known as StevenK [02:46] oh for goodness sakes [02:46] I can't wait until Saturday is done [02:46] I got Mitt Romney talking on my phone while Obama is on the TV [02:46] hah [02:47] can't get rid of these people :-) [02:47] I'm from Montana, we aren't used to national politicians even being in the state ;-) [02:48] Hahah, from README-linux.txt: [02:48] 1) This game must be built with scons build system, no matter you like it or not. You [02:48] have no choice. Autotools & family is stupid crap and I hope it'll die soon. [02:48] * bddebian almost chokes on his own vomit [02:48] But but, scons is worse! [02:49] better that choking on someone else's. *shrug* [02:49] *than [02:49] Ew [02:49] StevenK: Amen brother [02:49] mneptok: true ... but disturbing [02:49] * RAOF balks at the concept of "worse than autotools" [02:50] LaserJock: "True, But Disturbing" is the working title of my memoirs. [02:51] ScottK: which C compiler? [02:52] bddebian: libs package> not necessarily [02:52] jdong: That turned out not to be needed. I was thinking GCC 4.2 [02:52] jdong: What I'm more interested is breaking the no libraries rule with a clamav (including libclamav) backport [02:53] RAOF: clearly you haven't worked enough with scons then :P [02:53] * RAOF hasn't worked with scons *at all*, and take steps to ensure the continuance of this state of affairs. [02:55] I've worked with autotools and cmake a bit, but not scons [02:56] ScottK: clamav I'd say is fine, as long as rev deps are investigated [02:56] ScottK: most other distros that come with clamav will track upstream's releases [02:58] ah dang [02:58] I was gonna file some backport bugs [02:58] but one of them is a lib [02:58] and I was hoping to get rid of my PPA packages :/ [02:58] jdong: OK. Well I've had the PPA buildd gasping for air for the last 24 hours building all the rdepends. [02:59] LaserJock: Depends on the lib. [02:59] ScottK: fun :) [03:00] well, the lib is only used by the package I'm wanting to backport [03:00] LaserJock: libs that have no/few rev-deps, I'm pretty cool with [03:00] ah [03:00] LaserJock: i.e. pairs like libtorrent+rtorrent [03:00] then it probably would work [03:00] this is gchemutils and gchempaint [03:00] which are now even in the same source in CVS [03:06] * bddebian wonders if Baby would kill me if I took out the rpath crap from btanks === bigon is now known as bigon` === parthan is now known as techno_freak [03:39] Does scons support anything like DESTDIR? [03:39] * RAOF recinds his previous balkage. [03:41] Any MOTUs willing to review package photoml (http://revu.tauware.de/details.py?package=photoml)? It's already been advocated once, so it should be very close to being acceptable. [03:46] heya [04:15] bddebian: Thanks for the review. (Your comment about README.Debian is noted - I'll make a note to standardise it for the next version.) [04:15] NP === santiago-php is now known as foursixnine === boomer` is now known as boomer [05:11] * bddebian 's eyes bleed [05:11] Reading SConscript files? [05:12] How'd you guess? :) [05:13] welcome to the army [05:15] I can't freakin' take it [05:16] lol [05:19] Marine Corps boot camp was less painful [05:20] Should libraries carry the same RPATH? It appears to me that the SConscript file is hardcoding RPATH to '.' when building the libraries. [05:21] bddebian: yes, but where you a Sconscript then ? [05:24] Oohh, it barfs because /usr/lib/btanks doesn't exist in the build environment === zachy is now known as zakame [05:27] building library packages is fun [05:32] This isn't a library package, it just has it's own libraries :-) [05:43] Gaaaaah, how the f**k does this thing wind up with an RPATH=' '........... [06:05] Gnight folks [06:09] Hi all! === czessi_ is now known as Czessi [07:28] good morning [07:33] Hey dholbach. [07:33] hey TheMuso :) [08:16] good morning [08:17] heya geser [08:18] Hi dholbach [08:24] Hello !I have a problem with REVU, the livemix page is broken (http://revu.tauware.de/details.py?package=livemix) ! What can I do to fix it ? [08:33] * TheMuso looks [08:33] I Nothing I can do to fix that [08:34] You will have to wait till a revu admin is around [08:34] And I am not sure one is at this moment [08:39] isn't livemix already in the archive? [08:39] !info livemix hardy [08:39] Package livemix does not exist in hardy [08:40] livemix is still in binary NEW [08:44] Sarge31: is the livemix package on REVU a different one than on the archive? [08:46] it is possible that there is a defferance because Michael Bienia has made a version : https://launchpad.net/ubuntu/hardy/+source/livemix/0.49~rc2-0ubuntu2 [08:47] Sarge31: that's me :). livemix was missing a build-dependency [08:48] the first version of live mix should be in the repository soon ! [08:49] @gesser yes it true ;-) I miss it ! [09:02] I think that I anderstand better the problem ! [09:03] my last upload 1304 will be parcially deleted due the gesser upload, then is it possible to completly delete it ? [09:04] Sarge31: REVU and the Ubuntu archive are independent [09:05] then way revu says « directory (/var/revu/revu1-incoming/livemix-0801171702/) of upload (1304) not found » [09:07] I don't know, you'll need to wait for a REVU admin [09:07] Finaly I don't know way but there is an incorrect (parsial ?) release, abd the link http://revu.tauware.de/details.py?upid=1192 will work ! [09:09] Yes, will a revu admin connect here or shouls I send an email on ubuntu-motu@lists.ubuntu.com ? === apache|mobile_ is now known as apache|mobile === ogra1 is now known as ogra === apache|mobile is now known as apachelogger [10:29] yet™ another® package is awaiting review: http://revu.tauware.de/details.py?package=sabnzbdplus - thanks! [10:54] reminder: MOTU meeting in #ubuntu-meeting in 5 minutes [10:56] 5 minutes? not 65 minutes? [10:57] Err. Right. Sorry. [10:57] * persia hides [10:57] Yeah that didn't seem right to me either. [10:58] * persia archives the broken livemix entry on REVU [11:21] ooo. UI for PPA removal will be in staging later today. [11:32] So we've just gotten a new lintian, and it, for reasons I don't understand, allows RPATH referencing /usr/lib/games/. Does anyone have a good reason why libraries shouldn't be in /usr/lib? [11:33] Err. Nevermind. I misread /usr/lib/games/... as /usr/games/.... Sorry. [11:35] heh [11:47] oy [11:50] OK. Having double checked the timezones this time: MOTU Meeting in #ubuntu-meeting in 10 minutes. === asac_ is now known as asac [12:01] ember: I'd like to have the gnumeric merge done, could you tell me if you have something ready, otherwise I'll probably merge the package today or tomorrow [12:34] hello guys [12:34] yesterday i got a Intel(R) Celeron(R) M CPU 410 @ 1.46GHz [12:34] so today i was getting cpu stepping to work [12:34] Hey TuxCrafter [12:35] but all the start up scripts were not compatible [12:35] i had to add a few lines [12:35] now it works [12:35] chages to /etc/init.d/loadcpufreq [12:35] and [12:35] changes to /etc/default/cpufrequtils [12:36] i can create a patch for the scripts? but will it be accepted [12:36] TuxCrafter: Best way to get it in is to submit the patches to a bug, and get a few other people to test. Even better if you can get some testers with other CPUs to give "doesn't break anything" feedback. [12:36] How can i check the script that are used upstream === apachelogger_ is now known as apachelogger [12:37] If it fixes a problem for some people, and doesn't break anything for others, and is visible, it will likely be accepted. [12:37] TuxCrafter: `dpkg -S $filename` will help you to identify which package owns a file, and `apt-get source $packagename` will download the source for the package. [12:38] persia: got that [12:38] creating the patch now [12:38] not that they shouldn't be fixed if they are wrong, but aren't those scripts largely redundant these days? I have neither and yet my CPU (also a Pentium M) gets scaled by the cpufreq kernel modules [12:39] persia: what diff options does ubuntu motu prefere? [12:40] debdiff, or unified diff [12:40] persia: diff -uNr ? [12:40] TuxCrafter: debdiff is best, but for that you want to also update the changelog, etc. If you aren't up for that diff -urN works, and ask someone to help you make a debdiff from the patch. [12:40] * rZZZr uses -BurN :) [12:41] rZZZr: i will add the B [12:41] rZZZr: That doesn't work if you are fixing a syntax error in debian/rules due to eight spaces not being a tab character :) [12:42] persia: true, mr knowledge :) [12:46] excellent! [12:47] * Hobbsee puts her pitchfork back [12:48] * persia douses Hobbsee's torches [12:48] what pitchfork? [12:49] pitch.fork() [12:49] zul: my pitchfork. to use on the MC, in the event of no decision. [12:52] MOTU Q&A session in 8 minutes in #ubuntu-classroom [12:55] * Hobbsee wonders if Kmos has seen the news yet [12:56] persia: I got my patches readdy [12:57] should i create a bug report [12:57] and add the patches === bigon` is now known as bigon [13:02] Hobbsee: yes =) [13:04] heh, happy about it? [13:04] Hobbsee: I'm.. i think you too [13:06] Hobbsee: https://bugs.launchpad.net/ubuntu/+source/cpufrequtils/+bug/184015 [13:06] Launchpad bug 184015 in cpufrequtils "add celeron m (p4-clockmod) userspace frequency support to loadcpufreq and cpufrequtils init scripts, patch included" [Undecided,New] [13:07] man-di: FYI ... lucene2 compiles with GCJ. I am not sure of unit tests because I had those disabled to avoid the FTBFS faced in Ubuntu pbuilder. [13:07] is this sufficient information [13:23] TuxCrafter: you probably want to send those to debian, as ubuntu takes that directyl from debian, with no changes === lmr__ is now known as lmr[lunch] === Hobbsee_ is now known as Hobbsee [13:39] Hobbsee: thanks for the advice i just sent a mail to the authors and the debian maintainers [13:40] TuxCrafte1: cool :) [13:42] Yay! mpeg4ip has finally been accepted! [13:51] although mpeg4ip should be in multiverse, not universe [13:52] due to build dependencies in multiverse [13:59] emgent: hi! [13:59] emgent: just wanted to let you know I am going through your updates now [14:01] bye guys === LongPoin1yStick is now known as LongPointyStick === Zenton is now known as Zenton_ [14:26] If a package depends (or build-depends) on a package in multiverse, does it always need to stay in multiverse as well? [14:27] yes [14:27] hello there [14:27] Hobbsee: ok. Thanks :) [14:35] Heya gang [14:41] hi, I'm currently doing a merge. If I don't have any patches to apply I also don't need a build depend on dpatch right? [14:42] hellboy195> Indeed [14:42] LucidFox: thx [14:42] Did the Debian original have any patches? [14:43] hellboy195: If dpatch is called in debian/rules then you need to depend on dpatch even if there are no patches. [14:44] Ah, yes. Forgot about that. [14:44] ^^ np. Ubuntu had one patch but now it's included into the programm so no more need I suppose [14:47] Yes, since it's included upstream, there's no need. If the Debian version didn't build-depend on dpatch, there's no need to change that. [14:47] Heya bddebian [14:47] hellboy195: If Ubuntu added dpatch, then it can be dropped, If it came from Debian that way, then leave it. [14:47] k, th [14:48] x [14:50] Hi geser === bigon is now known as bigon` === bigon` is now known as bigon [15:22] am I the only one to feel that quilt is cumbersome to use? [15:23] no [15:23] I feel better :) [15:27] jdong: Nope [15:29] simple-patchsys ftw [15:30] both simple-patchsys and even dpatch meet my definition of easy to use [15:30] I'm not a picky guy [15:41] hello [15:41] jdong: could you please validate bug 183262, bug 183088 and bug 177716 ? [15:41] Launchpad bug 183262 in gutsy-backports "Please backport neon27 0.27.2-1 from Hardy" [Undecided,New] https://launchpad.net/bugs/183262 [15:41] Launchpad bug 183088 in gutsy-backports "Please backport libmowgli 0.6.0-1 from Hardy" [Undecided,New] https://launchpad.net/bugs/183088 [15:41] Launchpad bug 177716 in gutsy-backports "Please backport audacious 1.4.5 and audacious-plugins 1.4.4" [Undecided,Incomplete] https://launchpad.net/bugs/177716 [15:43] i've been testing it for a few days, wroks nicely [15:43] *works [15:45] jeromeg: ok, looks good [15:45] jdong: thank you very much! Sorry to always ping you for this on irc :) [15:47] no problem :) [15:48] I'd appreciate it if someone could test the feisty/gutsy-proposed packages in Bug #183661 [15:48] Launchpad bug 183661 in libmail-box-perl "FTBFS in Gutsy/Feisty" [Medium,Fix committed] https://launchpad.net/bugs/183661 [15:48] I also tested those: bug 180793, bug 162590, bug 175079, bug 175072, bug 174865, bug 175080 [15:48] Launchpad bug 180793 in gutsy-backports "Please backport homebank 3.6-3 (universe)" [Undecided,Confirmed] https://launchpad.net/bugs/180793 [15:48] Launchpad bug 162590 in gutsy-backports "Backport Blender 2.45" [Undecided,Confirmed] https://launchpad.net/bugs/162590 [15:48] Launchpad bug 175079 in gutsy-backports "Please backport screenlets 0.0.10-2 from Hardy" [Undecided,Confirmed] https://launchpad.net/bugs/175079 [15:48] Launchpad bug 175072 in gutsy-backports "Please backport sonata 1.3-2 from Hardy" [Undecided,New] https://launchpad.net/bugs/175072 [15:48] Launchpad bug 174865 in gutsy-backports "Please backport reportbug-ng from Hardy" [Undecided,New] https://launchpad.net/bugs/174865 [15:49] jdong: ^ :) [15:49] ok, this is getting floody :D [15:49] jdong: after this I'm done :) [15:49] I'm not sure about the blender one [15:49] jdong: and bug 175676 pretty please :) [15:49] Launchpad bug 175676 in gutsy-backports "backport tracker 0.6.4" [Undecided,New] https://launchpad.net/bugs/175676 [15:49] jeromeg: what's up with the SRU? [15:50] jdong: for gthumb ? [15:50] oh nvm [15:50] ScottK: caused that. [15:51] I guess I better say it again: [15:51] I'd appreciate it if someone could test the feisty/gutsy-proposed packages in Bug #183661 [15:51] Hi. [15:51] Launchpad bug 183661 in libmail-box-perl "FTBFS in Gutsy/Feisty" [Medium,Fix committed] https://launchpad.net/bugs/183661 [15:51] blueyed: ^^^ can you test? [15:51] Hello blueyed [15:51] ScottK: sure, will look into it. [15:52] blueyed: Thanks [15:52] ok, I'm starving, breakfast first then backports [15:52] jdong: thanks [15:52] I've contacted the uploader of tvbrowser on revu and he said I could adopt his package. Can I just upload an updated package then? [15:52] jdong: I think you need to work on your priorities [15:52] blueyed: Yes [15:53] asac: can you provide a menu file for firefox for hardy? :) [15:53] jdong: I'm not sure about the blender one, I tested it only a little as I'm not a blender pro and the interface is not really intuitive, but what I tested (a few simple constructions) works [15:54] dholbach: I can't see Hobbsee in https://wiki.ubuntu.com/MOTU/Council [15:55] joejaxx: ffox 3? [15:55] * Hobbsee isn't there yet [15:55] * Hobbsee adds, but has done no wiki page [15:56] asac: which ever one is shipping by default :) iirc there was not a debian menu file in firefox for gutsy [15:56] nixternal: and you probably want to update your wiki page mentioning what the MOTU Council election asks for :) [15:56] did that [15:56] look at the link up top [15:58] asac: or both since firefox 2 is still in the archive [15:58] for hardy [15:58] nixternal: oh, I missed it. Thank you. [15:59] otherwise us non-{Gnome,KDE} do not have a menu launch entry [15:59] * joejaxx still needs to find out how ubuntu broke dpkg :P [15:59] What is "cherry-picking"? Retrieving a single diff from a VCS revision and adding it as a patch? [16:00] LucidFox: yes [16:00] non-{Gnome,KDE} users * [16:01] joejaxx: add Xfce to that list. They use the fdo .desktop files specification AFAIK. [16:01] pochu: yeah [16:02] i think i am going to generate a list of packages that do not have debian menu files as I see more and more packages shipping with out them [16:04] :P [16:04] got to go [16:04] bye [16:04] * joejaxx also hopes the Open Group frees the source to CDE soon :\ [16:04] joejaxx: also go and ask those WM to follow the fdo spec ;) === \sh_away is now known as \sh [16:05] pochu: :P [16:06] joejaxx: *shudder* I've used that [16:06] broonie: hey no shuddering :P [16:06] :( [16:06] :P [16:07] <\sh> moins [16:07] there are a lot of us CDE users out there [16:07] i actually would have paid for the linux version but they do not offer that for purchase anymore [16:07] they need to free the source :P [16:07] so we can pull in the Sun changes to it as well [16:09] <\sh> ScottK, I uploaded the claws extra plugins this morning...do you have already a testpackage claws-mail for gutsy handy? [16:09] claws-mail ftw :) [16:09] \sh: Hardy should be in good shape WRT clamav, so test away with what's in the archive [16:10] <\sh> ScottK, cool...I'll have to install clamav anyway :) [16:10] \sh: For gutsy, I missed a dependency so it was in dep wait for a while. Let me check and see if it's built yet. [16:10] <\sh> just wanted to do an upgrade check from dapper to hardy [16:11] can somebody imagine why something like this would fail: [16:11] [ ! -f Makefile ] || -/usr/bin/make distclean [16:11] /bin/sh: -/usr/bin/make: not found [16:11] Yes. [16:11] [ ! -f Makefile ] || -$(MAKE) distclean is the original line and removing the '-' makes it work [16:11] <\sh> dholbach, looks like that "-" is interpreted somehow [16:11] A - at the beginning of the line means something to make. In the middle of a line, it has no special meaning and gets passed as is to sh. [16:12] yeap [16:12] or rather to $SHELL [16:12] interesting :) [16:12] gracias [16:12] np :) [16:12] hellboy195 was just merging xsel and found it in the debian version [16:13] \sh: Still waiting on building in Gutsy. [16:14] <\sh> ScottK, ah ok...I'll test with hardy then...after the dist-upgrade run [16:14] im getting a 403 error when updating my system, where should i report it? [16:14] nxvl_work: The xorg update got pulled. [16:14] nxvl_work: Patience [16:14] oh [16:14] ok [16:15] nxvl_work: See /topic in #ubuntu-devel [16:15] scottK: oh i understand, but it crashed the whole update, xorg isn't the only package i need to update [16:15] it's kind of annoying [16:16] * nxvl_work goes to #ubuntu-devel [16:16] nxvl_work: Sure. [16:16] nxvl_work: apt-get install the other updates [16:17] scottK thats what i'm doing, im not so new :P [16:17] OK [16:22] Hello, I am building a debian source package to which I have added 2 manpages; consequently, i added them to Makefile.am and called autoreconf. This produced a lot of changes to the makefiles.in. My question: Should I ignore all the changes in the makefiles when creating the patch that adds the two manpages to the source? [16:24] frafu: If you added them just to Debian/Ubuntu, put them in the debian/ dir, don't patch the source [16:24] anyone a good sentence for the changelog for me? About the -$(MAKE) distclean error [16:24] hellboy195: Change it to: [ ! -f Makefile ] || $(MAKE) distclean [16:25] bddebian: yeah I changed it ;) I need a sentence for the changelog [16:25] Oh, just say Make distclean not ignore errors, or some thing like that [16:26] bddebian: k, thx [16:27] bddebian: I don't know how to only put them in the debian/dir: could you give me an example? [16:29] Launchpad can build against binary packages in NEW? [16:29] frafu: save them as debian/binary.1 and use dh_installman in debian/rules to install them (you can list them debian/package.manpages; see man dh_installman) [16:30] * bddebian glares at geser :) [16:30] LucidFox: no [16:30] And what about the files that where already in the source and that I modified? A patch for these files as usual? [16:31] oh, wait, indeed... I just saw that faac exited depwait and started building after mpeg4ip was uploaded, but now it has entered depwait again [16:31] frafu: Yes [16:32] jdong, do we need a libmp4v2 rebuild bug? [16:33] Finally: if I add the two new man pages with the debian/dir method, I suppose that I don't have to add them to Makefile.am; correct? === Pricey is now known as PriceChild [16:35] have a great weekend [16:35] frafu: Correct [16:35] You too dholbach [16:35] thanks bddebian :) [16:36] Thanks for your help [16:36] LucidFox: is libmp4v2-dev on the archive? [16:36] geser> the old version has been removed, and the new version is in NEW [16:37] it was previously provided by faac, and will be by mpeg4ip [16:37] LucidFox: when it passed NEW the buildds should retry faac automatically [16:37] Yes, I know :) [16:38] but there are other packages still depending on the old libmp4v2 [16:38] namely: amarok, mplayer, quodlibet [16:38] ah, now I understand [16:44] Hi LaserJock [16:45] hi geser [16:46] Heya LaserJock [16:46] hi bddebian, still here I see ;-) [16:48] Yep, useless as ever :) [16:48] bddebian: you should have run for MC! [16:48] ScottK: we already changed the maintainer. [16:49] mr_pouit: Great. [16:49] hmm, I wonder if we should have a wiki page [16:49] I think that should prevent problems then. [16:49] that just has "maintainer" info like that [16:49] bddebian already has a wiki page [16:50] <\sh> bddebian for MC? why not...that's would make me proud ;-) [16:51] heh [16:51] I thought about it but I don't think I could do it justice. I'm not as involved as I used to be :-( [16:51] a god in the MC? a very nice idea [16:51] mhm [16:51] "divine instruction from above" [16:52] lol [16:52] <\sh> "hello this is god bddebian I have something to pray" [16:52] <\sh> "here is the stone with ten rules on it for being a good motu" [16:53] hah, yeah right :) [16:53] <\sh> reminds me of michael moore [16:53] haha [16:53] "MOTU Ten Commandments" [16:54] <\sh> "1. Don't blame anyone else, because it was your pile of sh*t you uploaded to the archive" [16:54] <\sh> "2. Please clean up after you followed rule 1" [16:55] <\sh> "3. Break KDE when you love Gnome, and break Gnome when you love KDE" [16:55] <\sh> "4. Don't be too serious" [16:56] 3.1 Always break fluxbox and xfce [16:56] <\sh> bddebian, do some merges dude :) [16:56] <\sh> 3.2 upload gnustep packages even if you don't have a clue about it [16:56] lol [16:58] <\sh> ouch...I think i did too many workouts today in the gym...my back is telling me this now === bigon is now known as bigon` [16:59] \sh, time for a little question? [16:59] <\sh> DktrKranz, fire away :) [16:59] hello [17:00] \sh, when handling with iceweasel-* packages (such as iceweasel-scrapbook), is it better to rename them mozilla-* or mozilla-firefox-* ? [17:01] DktrKranz> I was under the assumption that mozilla-firefox- if they're Firefox-specific [17:01] <\sh> DktrKranz, well...I would say it depends what was it before better to ask the people from ubuntu-mozillateam [17:02] DktrKranz: Why are you renaming them? [17:02] Speaking of which... the descriptions for mozilla-noscript and mozilla-firefox-adblock mention Iceweasel, this is probably a bug [17:02] \sh, make sense. I asked you since you did a lot during feisty, I'll ask them soon. Thanks. (as much as LucidFox). [17:03] ScottK: depends on iceweasel, in the past we renamed them as well, so I guess it was as per policy or some [17:03] <\sh> DktrKranz, oh I only adjusted build-deps afaik...most of the time when it was depending on iceweasel, iceape or whatever icemonkey there was to the corresponding ubuntu package... [17:04] <\sh> DktrKranz, I never had the luck to touch an named "iceweasel-plugin-whatever" package [17:04] Ah. Well the firefox/firefox-dev stuff shoul (I think) be some kind of xulrunner for hardy anyway [17:05] isn't hardy switching from FF2 to FF3? what about the plugins we have in the archive? [17:05] <\sh> ScottK, well, but what to do with packages named "iceweasel" which would be "firefox"? hopefully we have the very same package with a different name in our archive [17:06] geser> IANAUD, but I thought Fx3 wouldn't be ready before FF [17:06] I've no idea the details. Your mozillateam suggestion was a good one. [17:06] \sh, we have only one of them, iceweasel-scrapbook. Others have been mangled, I guess [17:06] unless they're planning to ship a beta by default, but in an LTS? [17:06] but I think mozillateam members can give us a final answer [17:07] I think it might be a good suggestion to have a wiki pages with some sort of Mozilla policy [17:08] LucidFox: if it's an accepted goal for hardy that hardy will ship firefox 3, it's ok to update the firefox 3 package also after FF (see gnome) [17:08] I've dug around the wiki and asked the mozillateam on IRC a few times when I've had issues like this and never really get a satisfactory answer === bigon` is now known as bigon [17:09] LaserJock: this is probably why we have three different naming policy. I've seen mozilla-* (most), but mozilla-firefox-* and firefox-* too. [17:10] and changing them in Build-Deps and Depends is done differently too [17:10] perhaps I should email -motu/-devel asking if we can get a Mozilla packaging policy? [17:11] and the source package naming is even more confusing [17:11] some have mozilla-, some don't [17:11] W: Errore nello scaricamento di http://security.ubuntu.com/ubuntu/pool/main/x/xorg-server/xserver-xorg-core_1.3.0.0.dfsg-12ubuntu8.1_i386.deb [17:11] upgrade broken. [17:12] leonel: I've uploaded another clamav update and a new python-clamav. Woud you please test again. [17:12] emgent: need an apt-get update ? [17:13] LaserJock, sure.. [17:13] LaserJock: it could be of help, at least for new iceweasel-* packages autosynced during initial phases. [17:13] case in point: bug #184084 [17:13] keescook, jdstrand ping [17:13] Launchpad bug 184084 in venkman "Extension description mentions Iceweasel/Iceape" [Undecided,New] https://launchpad.net/bugs/184084 [17:14] malone 184084 [17:16] LucidFox: I think there's nothing we can do for source packages names since we want to be able to resync with Debian at a later stage. [17:16] ScottK Ok [17:17] most all of the descriptions I see mention Iceweasel [17:17] LucidFox: what about icedove? [17:18] DktrKranz: I'm not sure how that effects this? is the naming scheme in Debian that scattered? [17:18] DktrKranz> Makes sense, I'll add it [17:19] LaserJock: not sure about Debian naming schemes, but actually we have some sources packages in the form "extension_name", "mozilla-extension_name" and "iceweasel-extension_name" [17:22] does anyone has run a packaging jam? [17:22] while this is somewhat confusing, I think the most annoying part is related to binary packages: how am I supposed to search for a {mozilla,firefox,iceweasel} extension if we have several name types? [17:23] I think the best option would be "mozilla-extension-[name]", which is not used by any extensions [17:23] or, failing that, just mozilla-[name] [17:24] <\sh> nxvl_work, Ubuntu Berlin wanted to run at least one reading dholbachs blog [17:24] \sh: i want to run one on Feb 25 [17:25] Personally I'd say we need bug fixing jams a lot more than we need packaging jams [17:25] amen [17:25] It it was just me, I'd say mozilla-[name], but I'm not aware of any policies or such. [17:25] ok, I sent an email of regarding Mozilla [17:25] so I'm off [17:26] * DktrKranz hugs LaserJock [17:49] bddebian: trying to install the new man pages with the following line "dh_installman --language=C dwell-click-applet.1 pointer-capture-applet.1" in debian/rules, it tells me that it does not find the manpage. Unfortunately I have not found any documentation about where to put the new man pages for dh_installman to find them. [17:49] Can anybody help? [17:53] frafu: debian/.manpages [17:53] dh_installman will look at that file [17:54] And that file should have debian/man1.1 debian/man2.1, etc [17:55] debian/manX.Y: what is X., what is Y? [17:56] debian/dwell-click-applet.1 debian/pointer-capture-applet.1 [17:56] on seperate lines of course [17:57] ah, I think I understand [17:57] Debian can be such a f**king friendly place [18:00] I don't know yet; I don't have enough experience; but the man page of dh_installman could be more detailed. :-/ Thanks again for your help. :-) [18:00] NP [18:01] frafu: Patches for the man page gratefully accepted ... [18:05] ScottK: Maybe when I will have more experience... ;-) The two pages that I am installing are the first I ever wrote. [18:06] frafu: Actually, documenting the problems you had understanding the man page about dh_installman to make it more understandable for new people is something you can only do now. If you wait until you understand it better, it'll be to late. [18:07] Yeah!!! bddebian gets an apology on #debian-devel. Someone write that down. [18:08] :) [18:08] ScottK: where is the bugzilla of the debhelper? [18:09] <\sh> ScottK, humm? [18:09] frafu: File a bug against it in Launchpad against the Ubuntu package and eventually someone will push the change back up to debian. [18:10] \sh: bddebian gets dumped on all the time in #debian-devel by the Ubuntu haters. Someone actually apologized just now. I've never seen that happen before. [18:11] <\sh> ScottK, hmm...you mean #debian-devel on oftc? [18:12] Yeah [18:12] ScottK: :) === rzr is now known as rZr [18:12] <\sh> hmm...bddebian is not in #debian-devel ,-)= [18:13] ScottK: maybe.... [18:13] \sh: I had to change my nick there ;) [18:13] frafu: Even if it's not perfect, it'd be the kind of hint someone more experience would need to improve the documentation. [18:13] <\sh> bddebian, what? [18:14] <\sh> ah now [18:14] ScottK: ok [18:15] <\sh> bddebian, /takeover #debian-devel ,-> [18:15] * \sh needs a shower and a cigarette...I think I'll do that in reversed order [18:16] ScottK:I will explain the problem that I had... [18:16] frafu: Please explain it in a bug. [18:16] IRC channels make poor bug trackers. [18:17] \sh: Yeah, MOTU bum-rush of #debian-devel, that would ROCK ;-P [18:18] persia: Do you mind if I assign the sbuild task on the virtual depends bug to you so it doesn't get marked invalid again? [18:18] <\sh> bddebian, well I'm alwys on #fai and #debian-security :) === bigon is now known as bigon` === bigon` is now known as bigon [18:29] jdong: Can you scare up some Dapper users to test clamav backports? [18:29] scottK clamav instaled fine and python-clamav worked fine [18:29] leonel: Great. Please mark that on the wiki page. [18:30] ScottK ok [18:34] blueyed: Do you have Dapper servers? [18:34] No, my server is running Feisty still (with some of Gutsy) [18:35] ScottK: it it a -backports type backport, or a -proposed type backport? [18:35] Ng: -backports [18:35] It's new upstream versions. [18:36] hmm, I generally avoid -backports on my (personal) server [18:37] Ng: If you have dapper and you want a useable clamav, there isn't much choice. This stuff is all in Universe anyway, so it's equally not commercially supported either way. [18:38] blueyed: Any chance you could do some testing and fill in the Feisty/Gutsy boxes on https://wiki.ubuntu.com/MOTU/Clamav?action=show [18:39] ScottK: is the dapper version not able to update anymore? I'd not noticed any whinging from cron [18:39] Ng: Look in /var/log/clamav. [18:40] Also it has an open CVE list about a mile long. [18:40] Ng: What packages do you use clamav with? [18:41] ScottK: exim. fwiw, it does say that the main and daily files are up to date [18:41] OK. [18:41] Clamd then? [18:41] yeah. Open CVEs is much more relevant though - that will drive me to use a backport :) [18:41] ScottK: what does N/A mean? I think amavisd-new would be the only thing I could test. [18:42] N/A - Shouldn't be affected. [18:42] blueyed: If you'd verify that, it'd be great. [18:42] blueyed: How about the php-clamavlib? [18:42] Ng: https://launchpad.net/~ubuntu-clamav/+archive has the current clamav built for Dapper. [18:42] ScottK: thanks [18:43] If you want to give it a try. Assuming it tests well, that's what will be backported. === ember_ is now known as ember [18:44] this does make me wonder how I should be tracking things I've installed from universe to make sure I stay on top of security [18:44] blueyed: If you can't test php-clamavlib, if you could come up with a test case, that would be highly useful (I know nothing about php). [18:45] Ng: There's no easy answer for that. [18:45] ScottK: I suspected as much [18:45] We're working on changing that though. [18:45] ScottK: I am back; I had to leave the computer for a while; I will explain my problem in a bug on launchpad after I was able to build the package. (This way I can also tell what information was missing in the man page of dh_installman.) [18:45] Subscribing to bugs for the packages in question isn't a bad start. [18:45] scottK got to go back in 1 hour and update the wiki [18:45] frafu: Sounds good. [18:46] ScottK: yes, I think there's a test file in the package itself.. IIRC there has been a bug, where I've helped you recently. I've currently no time unfortunately.. [18:46] blueyed: Understand. Thanks for all you've done. [18:50] See you! [18:55] ScottK: looks good to me, it's still talking to exim and freshclam logs suggest it ran fine and didn't print any scary warnings :) [18:56] That's what I'd have expected. If you could add a row on the wiki page and comment, that'd be wonderful. [18:56] ScottK: sure :) [18:57] ScottK: err, sorry, which page? MOTU/Clamav? [18:58] Ng: Yes [18:59] ScottK: not quite sure what you want me to add then - clamav-daemon and clamav-freshclam? [19:00] No. I'd say Exim w/clamd (clamd is part of the clamav package, so we can assum it works with itself). [19:01] ok [19:01] I haven't listed all the clamd users there, because I'm confident clamd works find, but since you've tested it and proven that, then it's worth it to document it. [19:02] ScottK: done :) [19:02] Ng: Thanks. === bigon is now known as bigon` [19:13] emgent: belated pong [19:13] emgent: something came up and I wasn't able to get to your updates yet. Though I hope to get to them this afternoon [19:14] someone has compiled the accounting program named grisbi? === bigon` is now known as bigon [19:21] persia: Never mind. infinity fixed it in the released sbuild too. [19:47] emgent: I was just reviewing your drupal update for SA-2007-031 [19:48] emgent: I see that the upstream patch listed on http://drupal.org/node/198162 is different than SA-2007-031-5.3.dpatch (I've only looked at gutsy so far) [19:50] was this the 'Upstream re-fix SA-2007-031 patch' as referenced in bug #181984 ? [19:50] Launchpad bug 181984 in drupal5 "Drupal5: SA-2007-031, SA-2008-005,SA-2008-006: SQL injection and XSS " [Undecided,Confirmed] https://launchpad.net/bugs/181984 [19:50] emgent: ^^ [19:51] emgent: if so, can you provide the link to the updated patch (the changelog still has http://drupal.org/node/198162) === bigon is now known as bigon` === bigon` is now known as bigon [20:08] debian library packaging session part 2 in #ubuntu-classroom, starting now [20:08] scottK done [20:08] sistpoty: Thanks [20:08] leonel: Thanks [20:08] np [20:08] leonel: Please test other stuff. [20:19] !pastebin > sistpoty: [20:19] !pastebin > sistpoty [20:21] /msg ubotu pastebin [20:25] emgent: regarding wordpress, the version and changelog entry does not conform to https://wiki.ubuntu.com/SecurityUpdateProcedures. Can you look at 'Preparing an update' at section '4' and '5' and resubmit your debdiff (please also give the url of the patch you used). thanks for your hard work! [20:29] scottK tested clamsmtp and worked fine added a note to the wiki table [20:29] Great. [20:32] ScottK: here is the bug about the missing information from the dh_installman man page: https://bugs.launchpad.net/ubuntu/+source/debhelper/+bug/184156 [20:32] Launchpad bug 184156 in debhelper "man page of dh_installman incomplete for newbie" [Undecided,New] [20:34] frafu: What I'd suggest doing next is prepare the text that you would recommend solves the problem. [20:34] frafu: Either in plain text (as an attachment) or, for bonus points, as a diff to the existing man page. [20:36] An example of the missing text is in the bug I filed. [20:38] ScottK: To do a good job, I suppose that all dh_* should be checked because I wonder whether the other do not lack the same information. [20:39] sure, but one step at a time. === Ubulette_ is now known as Ubulette [20:41] ScottK: Maybe that my problem with debhelpers comes from the fact that I did not have a "debhelpers basics" course!? [20:42] Maybe, but we don't really have one of those. [20:42] I'll leave it to the people that normally mind debhelper to decide if that's to basic info or not. [20:43] somerville32: your edgy debdiff for bug #183389 had the wrong version number [20:43] Launchpad bug 183389 in syslog-ng "[SECURITY] CVE-2007-6437 prone to denial of service attack" [High,Confirmed] https://launchpad.net/bugs/183389 [20:43] sistpoty: paste.ubuntu.com [20:43] somerville32: I have fixed it [20:43] imbrandon: thanks [20:43] somerville32: uploading now. thanks for the patches! [20:54] scottK http://paste.ubuntu-nl.org/52472/ php5-clamavlib works [20:58] leonel: Great. Please mark it on the wiki. Can you test php4 too? [21:02] ScottK: Please don't assign it to me: I'm not sure if I'll be able to get to it in any reasonable time. Setting it "Confirmed" should be sufficient to not be "Invalid", no? [21:03] persia: Never mind. Later in your scrollback you'll find that infinity fixed it already. [21:03] scottK leonel@dapper:~/clamtest$ php4 test.php [21:03] ClamAV version 0.92 with 191434 virus signatures loaded [21:03] [21:03] done [21:04] Hrm. I just finished reading the last 9 hours of scrollback, and somehow missed that. Perhaps I'm just not parsing well at my local time of day :) [21:04] Great. [21:04] * persia idles, in hope of restoring the ability to read [21:04] persia: Heh. It's fix released now anyway, so it'd be interesting if you could confirm. [21:06] ScottK: Could you send me an email with the bug# and a test case (if it's not already in the bug). I'll test it when I wake up. [21:06] persia: What address? [21:07] hi guys [21:07] ScottK: persia@ubuntu [21:09] Heya persia [21:10] persia: Sent [21:13] Any C programmers handy that could help me figure out how to fix what appears to be an incomplete/correct patch. [21:14] ScottK2: what's the problem [21:15] I'm trying to backport the current clamav to Dapper and need to patch the Dapper avscan to work with the new clamav [21:16] I grabbed a patch from a later version, but am left with windb.c:277: error: dereferencing pointer to incomplete type [21:16] ScottK2: where can I see it? [21:16] Gimme a sec to upload it somewhere [21:17] mok0: http://www.kitterman.com/clamav/ [21:18] mok0: The patch I started with came out of https://launchpad.net/ubuntu/feisty/+source/avscan/1.3.1-openssl-4 [21:19] still trying to get the first one :-) [21:19] OK [21:19] If you haven't used quilt before, this: http://pkg-perl.alioth.debian.org/howto/quilt.html will come in handy [21:19] got the first one [21:20] I tried to adapt the patch from 1.3.1 to the 0.8 that Dapper has and obviously missed something [21:20] My system is gutsy, I will try to compile [21:21] I don't have a dapper pbuilder [21:21] It'll crash and burn nicely in a Dapper pbuilder [21:21] Heh [21:21] I can make one... but it will take a few minutes [21:22] I just added my Dapper pbuilder script to the web directory I gave you before [21:22] cool [21:22] Then it's sh pbuilder-dapper create [21:23] hmm, that reminds me [21:23] I made a new pbuilder script [21:23] ... it's working now [21:24] Great [21:24] LaserJock: How's it compare to the one that RainCT made from your old one (it's in ubuntu-dev-tools) [21:24] a lot simpler [21:25] it's sort of an in-between [21:25] let me paste it real quick [21:25] http://pastebin.ubuntu.com/3653/ [21:25] Maybe add it to ubuntu-dev-tools as pbuilder-dist-simple [21:26] * ScottK2 loooks [21:26] I've had problems with the one in u-d-t [21:26] ScottK2: yikes a bunzip2 unpack failed [21:26] and it's just way more complicated than I need [21:26] I figure the more amount of code the more than can go wrong [21:27] Right. I'm still using your old one for Ubuntu [21:27] Or at least one I hacked on a bit based on it. [21:27] this one allows you to just have one script, which I like [21:28] mok0: ? [21:28] but is basically the same thing [21:28] The pbuilder create needs to unpack a bz2 archive somewhere, and that failed [21:28] Wierd. [21:29] I made my dapper pbuilder with that script just a couple of days ago. [21:29] I added support for a local repo so I could build stuff that deps on stuff I'm also building [21:29] ScottK2: its a Packages file that is bzip2'ed [21:29] bzip2: Compressed file ends unexpectedly; [21:29] That should be OK. [21:29] LaserJock: «this one allows you to just have one script, which I like» you can do pbuilder-dist ... [21:30] RainCT: right, but I couldn't get pbuilder-dist to work [21:30] so I made my own [21:30] lol [21:30] mok0: Works on by Gutsy box. [21:30] RainCT: rather than figuring out what the problem was with pbuilder-dist, which probably is the "right thing to do" [21:31] mok0: are you using a backported pbuilder? [21:31] no [21:31] maybe that's a difference [21:31] I am trying again [21:31] True, as I am, but for Dapper, I'd be suprised it matters [21:32] It's a corrupt Packages file on the archive [21:32] Try a different mirror? [21:33] Get:5 http://archive.ubuntu.com dapper/multiverse Packages [21:33] * mok0 curses bzip2 [21:34] I don't think I have multiverse in my sources.list [21:34] LaserJock: well, you probably didn't do that wrong. at least I have no clue why pbuilder-dist doesn't work for some people :S [21:34] I fought with it for some time [21:34] it wouldn't update right and wouldn't create new pbuilders [21:35] so I took the idea of doing "pbuilder-dist " but made it simple [21:35] * mok0 looks for a mirror that contains dapper [21:37] they all should shouldn't they? [21:38] mok0: The one I just made while we are talking uses deb http://archive.ubuntu.com/ubuntu dapper [21:39] It's working with the local archive [21:39] almost done [21:40] Great [21:41] ok, got the dabber pbuilder made :-) [21:42] jdong: so ... is the packages that dep on bzr gonna be backported to? :-) [21:42] Building avscan now [21:44] ScottK2: I got a bunch of undefined symbols [21:44] 'CL_DB_STDOPT' undeclared [21:45] ScottK2: ... in the file avscanop which you patched [21:46] LaserJock: yes.. they're waiting in U-A [21:47] ah [21:47] :) [21:48] mok0: yes [21:48] ScottK2: Is that what you are getting? [21:48] mok0: I forgot one thing ... [21:48] lol [21:49] A dapper pbuilder won't have the new clamav in it. [21:49] ScottK2: you have it in a ppa? [21:49] mok0: use login --save-after-login (I think) and add deb http://ppa.launchpad.net/ubuntu-clamav/ubuntu dapper main to the source.list [21:49] yest [21:50] yest/yes [21:50] ScottK2: why didn't it flag a missing build-depends? [21:50] Because it just build-depends on libclamav-dev and you have that [21:50] Just an ancient one [21:51] The -dev libraries aren't versioned [21:51] ScottK2: ah [21:51] (in their name anyway) [21:51] ScottK2: what about having a version > something, then? [21:51] Yes. I should do that before I upload it. Good point. [21:52] ScottK2: ;-) I've learned something [21:52] * mok0 updates his dapper [21:59] Try again with ppa defined [22:01] ScottK2: I get the compilation error you got now [22:04] OK. That's progress, I guess. [22:04] so it only took 45min to get there :-) [22:05] mok0: You'll want to look at the quilt reference I gave you earlier so you can look at the patched source. [22:05] ScottK2: it looks pretty ugly [22:05] LaserJock: Not bad considering he had no Dapper pbuilder to start [22:05] mok0: I've got no pride in this as I know virtually nothing about C. I was trying to figure where the equivalent changes from the patch of the later versions. [22:06] mok0: I'm quite prepared to hear I got it totally wrong. [22:06] ScottK2: can't you compile the latest version on dapper? [22:06] mok0: No. The later versions need a later version of Endeavour which does not compile on Dapper and has reverse depends [22:07] arrgh [22:07] So I have versions that work on Dapper and versions that work with the current clamav, but none that does both. [22:07] Right. [22:07] Which is why I decided it was time to ask for help from someone who actually knows C [22:09] It's always scary when you apply a patch and things don't compile [22:11] ScottK2: the patch introduces the problem [22:11] OK. [22:11] ScottK2: it seems they changed the data structure [22:12] ScottK2: ... and the patch makes it a mixture of old and new [22:12] * mok0 checks some more [22:12] Would you be able to dig out the additional old bits and make it all new? [22:13] ScottK2: I'd have to give it a good look [22:14] mok0: It would be a huge help if you could. This is (I think) the last clamav rdepend I need to get working before I can backport the current clamav [22:15] The Dapper one has an open CVE list a mile long. [22:15] ScottK2: Is there a problem with the clamav from dapper? [22:16] mok0: It's ancient. Unmaintained. Unmaintainable. [22:16] ScottK2: OK [22:16] ScottK2: I'll take a look, but I need to be fresh [22:17] Since Dapper has ~3 more years to go, it seems prudent to deal with it. [22:17] ScottK2: right. [22:17] mok0: Thanks. It's more important to have it right than have it today. [22:17] ScottK2: he [22:17] ScottK2: of course, the next problem after getting it to compile: does it work? [22:18] mok0: Of course. [22:18] mok0: Once it compiles, we'll upload it to the PPA and I'll hunt down testers [22:18] ScottK2: Just a stupid question: what does avscan do? [22:18] (I know its a virus scanning thing) [22:18] ScottK2: if clamav in dapper is already a pain how will it be in 3 years? [22:19] mok0: That's about all I know. [22:19] mok0: If you join the ubuntu-clamav team, https://launchpad.net/~ubuntu-clamav , you'll be able to upload it directly once the later one I already uploaded gets removed. [22:20] geser: If I can get the rdepends updated to the current API, then I can backport new releases as they happen. [22:20] ScottK2: Let's not sell the hide before the bear is shot [22:20] Right. [22:20] I haven't heard that before, but I like it. [22:22] ScottK2: So, the avscan code I'm looking at is basically the dapper version, and the patch in debian/patches contains the diffs to a newer version? (Just checking that I got it) [22:23] The patch in debian patches is my attempt to replicate the changes from the newer version. They don't all apply directly as some of the code has changed. [22:23] mok0: The later version on LP that I pointed you to has the original patch. [22:23] ScottK2: ok [22:24] Obviously I missed something. [22:24] The current Hardy version of avscan supports the new clamav unpatched, so the upstream changes may also have clues. [22:26] ScottK2: ... and what is Endeavour? [22:26] It's a window manager of some kind [22:27] These appear to be low use packages, but I feel an obligtation not to break the archive even for stuff that isn't much used [22:27] * mok0 wonders why a virus scanner would need a window manager... [22:28] It uses their library package, so I assume it's to make their own windows. [22:29] No need to bother with using stuff people know about like qt or gtk. [22:30] ScottK2: no by all means, keep changes to a minimum [22:34] Well, I need to stop working. I will look at avscan tomorrow [22:35] See you guys [22:36] See you. Thanks [22:55] When a software is licensed as free to use and to distribute for non-commercial use only, and is in Debian non-free, can it be synced in multiverse? [23:03] warp10: sounds like a good candidate [23:04] LaserJock: ok, great. Thank you :) [23:06] jdstrand, Hey. I had caught that too and I had _thought_ I had uploaded the fixed version. Anyhow, thanks a bunch :) [23:08] jdstrand, although I don't see the uploads on launchpad [23:13] bug 87122 [23:13] Launchpad bug 87122 in ubuntu "[needs-packaging] iFolder" [Wishlist,Confirmed] https://launchpad.net/bugs/87122 [23:14] crap [23:16] somerville32: Security uploads get built on a separate system and then source and binary copied into Soyuz after they are all done. [23:17] ScottK, okay [23:20] somerville32: still building. the queue was stuck for some reason === bigon is now known as bigon` [23:22] good night :) [23:22] saivann: ping === bigon` is now known as bigon [23:51] somerville32: just pushed syslog-ng to soyuz. thanks again! [23:52] jdstrand, anytime :) [23:52] Good evening. [23:52] I updated bug 174470 [23:52] Launchpad bug 174470 in ubuntu "[needs-packaging] Falcon Programming Language" [Wishlist,In progress] https://launchpad.net/bugs/174470 [23:53] andi5: ping [23:53] Uploaded package can be found as [23:53] http://revu.tauware.de/details.py?package=falconpl [23:53] Is there anywhere else i should post a notice? [23:54] btw; this package http://revu.tauware.de/details.py?package=falcon [23:54] jonnymind: No. That's it. [23:54] should be removed, but It seems I cannot. [23:54] I can do it. [23:54] ScottK: thnx [23:55] hi saivann :-) first i want to thank you for your efforts regarding gnucash packaging and bug fixing :) i wonder whether what #184176 is about, is a problem for upstream or i can help somehow? :-D [23:56] jonnymind: Archived. It can still be found if someone wants to see the old comment. [23:56] comment/comments [23:56] Ok, thanks. [23:56] andi5 : Thanks, please let me check, I finish a phone and I look at this with you [23:56] Is there anything else should I comply to? [23:57] saivann: sure :-) [23:57] jonnymind: We still need to solve the /usr/bin problem, but personally, I think the other falcon should change. [23:57] jonnymind: I own the ITP for the other falcon in Debian, so we can sort this out nicely in both places. [23:57] ScottK: thank you. === doko_ is now known as doko [23:58] ScottK: Of course; I think I clarified enough why I did it. [23:58] (Well; actually I think you're getting bored with my story ;-)