[00:08] q. is there a way to make a .deb compress with .lzma or even better with 7z ? i asked because the .7z of the directory containing all the files of my .deb is 1.7mbyte. while the .deb is 3.2mbyte. this is almost double for .deb [00:09] * RAOF thought lzma was the 7z compression scheme [00:09] zorglu_: Also, yes. They're options to dpkg-deb, I believe. [00:09] RAOF: it is. but .tar.7z takes more than .7z itself [00:10] RAOF: aka .tar got a lot of overhead [00:10] RA [00:10] ok thanks will look [00:10] .tar has very overhead. [00:10] In particular, -Zlzma [00:10] Er, very little [00:10] its got a 512 byte block size [00:11] i've got a problem building a package, is there some here willing to help me out? [00:11] lifeless: Point. The tar header is quite small, though. [00:11] sure; but stuff 100K 5-byte files in tar :) [00:12] lifeless: oh, hi! [00:12] schierbeck: hi [00:12] i'm trying hard to learn packaging, but i'm completely stuck [00:13] when i call pbuilder build, as instructed in the packaging guide, i get 'configure: error: cannot find install-sh or install.sh in "." "./.." "./../.."' [00:13] i can do ./configure and make just fine [00:13] is that a common problem? [00:14] pure7z=1705165, tar.gz=3170879(with gzip -9), tar.7z=2294475(top 7z compression) [00:15] notice that pure7z is 1.7mbyte, while tar+lzma=2.3mbyte [00:15] StevenK: this is the overhead im talking about [00:15] zorglu_: debs are not targs [00:15] zorglu_: they are ar's. [00:16] of the same package. a normal .deb is 3.2mbyte :) [00:17] zorglu_: yes, we know, have you tried the -Zlzma option yet ? [00:17] schierbeck: no not a common problem [00:17] lifeless: where should i put this option ? [00:17] lifeless: i've been googling around for ages, and i can't fint a pattern [00:17] do you have a clean rule that removes it perhaps? [00:18] lifeless: could be, i'll go check it out! [00:19] zorglu_: This depends on your pakcage's build system (debhelper? cdbs? anything else), but a simple check could be to simply unpack your existing deb and repack it with 'dpkg-deb --build -Zlzma ' [00:20] RAOF: worst i use epm :) [00:20] lifeless: nope, it doesn't get deleted [00:29] Is would be nice to have the newest lintian installed on REVU... [00:30] RAOF: ok thanks for your help. now i know it is possible at least [00:30] s/Is/It [00:30] RAOF: doing it with epm seems non trivial as it hardcode the gzip :) [00:30] snprintf(command, sizeof(command), EPM_GZIP " > %s", filename); <- bla :) [00:34] https://wiki.ubuntu.com/dpkg-lzma <- already working on the matter, hey :) [00:49] Heya gang [01:13] booring [01:14] * bddebian dances around mok0 [01:14] yay [01:15] bddebian, feel like reviewing? [01:17] mok0: What's the package? [01:17] http://revu.ubuntuwire.com/details.py?package=gpp4 [01:17] bddebian: it's a library [01:17] Ugh :-) [01:23] bluekuja: what do you think about the upgrade request for transmission? should we service it ourselves or wait for Debian? [01:23] mok0: Looking [01:24] bddebian: cool [01:28] bluekuja: eh what the heck, there's a get-orig-source rule anyway, I'll do it to shut up the boys on LP :) [01:30] mok0: Just out of curiosity, why do you call clean and distclean? [01:31] bddebian: hmm, it's been a while since I wrote it, it may be redundant [01:31] oh I am an idiot, it's in main. [01:56] imbrandon: Gah! apt-mirror is a compassionate parent and doesn't kill its children. [01:56] heh [01:57] imbrandon: It ought to. [01:57] if i wasent dead tired and litterly about to goto sleep in 10 minutes i would look to fix it, but as it stands i'll poke at it tomarrow [01:57] imbrandon: I have a patch already. [01:57] ahh killer [01:57] If you use debconf and have a variable called 'daemon_start', is it ok for the postinst script to rewrite /etc/default/packagename? [01:57] imbrandon: Anyway, it also doesn't lock. [01:57] StevenK: what would it lock ? [01:58] imbrandon: If you start one apt-mirror, and then another, the second also tries to work, and they step all over each other. [01:58] ahhh [01:58] yea bad mojo [01:58] never thought about that [01:58] imbrandon: Example: You have one running, and then cron fires off another -> Badness [01:58] right [01:58] imbrandon: I'm investigating a patch for that, too. [01:59] hrm it would have to lock per mirror [01:59] because really it could be run with a diffrent config [01:59] at the same time [01:59] imbrandon: Nah, don't do that, it's too hard. [01:59] err per config, not per mirror [01:59] hrm [01:59] A global "I'm running" lock. [01:59] yea just check for a pid [02:01] cool, i'm heading to bed, if you want email them to me, if not i'll be arround fairly early tomarrow [02:03] Debian is finally starting to remove GNOME 1.x stuff. [02:04] \o/ Finally [02:05] ... and obviously, the first reply is objection (to the procedure). [02:05] :-/ [02:05] http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/bca2c92496161015 [02:07] Debian has been working on removing GNOME 1.x stuff for some time [02:07] we're just now getting to the bottom of the stack, is all [02:08] Ugh level 1 deps are even ugly :-( [02:09] imbrandon: Haha [02:09] Good night folks [02:09] bddebian: what do you mean? [02:14] bddebian: thx for advocating. Without doubt you are right on the clean/distclean target, in fact I think distclean depends on clean [02:15] Well 03:16am here, gotta go to bed [02:15] g'night === bigon is now known as bigon` [03:34] hi [03:34] anyone knows if netbeans 6 is planned to be packaged? [03:34] is it late already? [03:35] We haven't hit feature freeze yet, so it's not late to have it packaged [03:36] it's on debian already http://packages.debian.org/sid/contrib/netbeans-ide [03:36] but I've never done a ubuntu package myself :S [03:37] LucidFox, what should be the right way to go? [03:38] first, check if a needs-packaging bug has been filed for it on Launchpad [03:38] if it hasn't been, file it yourself [03:39] "Current plan for NB 6.0 packaging"... [03:39] It's underway. [03:40] https://launchpad.net/~mslama-email <-- ask this person about the progress [03:41] is there a bug files already? [03:43] Bah, too bad it build-deps sun-java5-jdk, which prevents a simple sync. If it built with icedtea-java7-jdk, it could be merged. [03:44] it's also a good idea to ask in #ubuntu-java [03:44] I'll look around [03:44] Oh, so it's in Debian [03:44] alex_mayorga> http://packages.qa.debian.org/n/netbeans-ide.html [03:44] yup [03:44] and sun-java6 is on hardy already if I'm not mistaken [03:45] then all we'll need is to merge it from there [03:45] yes, but there's the Dreaded Chroot Build Issue [03:45] ???:-( [03:46] Basically, packages depending on Sun's Java to build do not build in pbuilder - and if I'm not mistaken, in sbuild either. [03:46] correct [03:47] Because it presents a debconf prompt to accept the license, and automated builds occur in noninteractive mode, which defaults to not accepting the license [03:48] nothing lost on asking I guess [03:48] just wondering given feisty had netbeans 5.5 and canonical and sun did the whole press release thingie for the previous release [03:49] probably someone at canonical is already into it, dunno [03:50] there's even https://edge.launchpad.net/netbeans6 [03:52] please forgive me if I'm babbling in the wrong channel or anything === _czessi is now known as Czessi [03:55] it might be possible to build using icedtea-java7 instead of sun-java6 === _MMA1 is now known as MetalMusicAddict [03:58] alex_mayorga> That's the upstream page for netbeans6, not the Ubuntu package [04:00] LucidFox: But, IIRC, you can work around the Dreaded Chroot Build issue by writing a magic value somewhere in /etc. [04:00] LucidFox, thanks [04:02] OK dumb question, how can I force a build with gcc-4.3? Can't I use CC=gcc-4.3 ? [04:03] That *should* work, assuming autotools. I think. [04:03] using what gcc-4.3 package in hardy? :) [04:03] Ok, and assuming a gcc-4.3 binary :) [04:04] crimsun: OK you caught me, this is in sid :) [04:04] ;) [04:05] I have a patch for vodovod but I need to test it :( [04:19] bddebian: This Universe. We don't actually test stuff here. [04:19] ;-) [04:20] heh, touche ;-P [04:21] slangasek: Thanks for the quick processing of NEW stuff today. [04:33] * TheMuso grumbles at late mailing list email arrivals [04:35] ScottK: n/p, it was the day for it :) [04:37] slangasek: It's nice to requestsync something with a new binary on Saturday, have the request get ack'ed Monday AM, and out of binary new Monday PM. Thanks again. Great service. [04:53] If anybody is around, I'd like a suggestion re bug 182700, where a patch is being applied. Originally, the contributor used cdbs to get simple-patchsys, even though the rules file was debhelper only, i.e all rules written out using dh_ calls etc. [04:53] Launchpad bug 182700 in sysinfo "Please sponsor sysinfo 0.7ubuntu3 (universe) into Hardy" [Wishlist,New] https://launchpad.net/bugs/182700 [04:53] I told him to not use cdbs just for patches, and look into something like dpatch [04:53] this time, he seems to ahve probably gotten the code from simple-patchsys, but I haven't checked. [04:53] I haven't checked whether it actually works yet, but I am wondering whether I should ask him to re-do it again, using a patch system such as dpatch or quilt [04:55] The contributor also hasn't closed the bug in the changelog, and while I'm willing tl let that through with a comment about doing it next time, I still feel they could learn something by making use of a patch system, instead of putting in patch code by hand. [05:05] Grr, what is the g++ equivalent of CC=gcc-x.x ? [05:05] bddebian: Run configure --help and that should tell you at the bottom of the output [05:05] ./configure even [05:06] From what I can remember, its CX [05:06] CXX even [05:06] It's either CXX or CPP [05:08] CPP is C preprocessor isn't it? [05:10] Hrm, it could be. [05:10] Thank btw :-) [05:10] +s [05:12] TheMuso: I'd make him do it again with dpatch (dunno about quilt, I've managed to avoid it so far). [05:14] quilt is kinda fun, once you managed to get yourself in the right mindset [05:14] s/ged/ge/ [05:17] ScottK: Well there are other things that need addressing, so I don't have to worry about it so much for now, but, I'll probably let it slip this time, but I have encouraged the research of patch systems. [05:17] ScottK: I didn't see your message until after I posted to the bug, but thanks for your thoughts. [05:18] THis contributor is, well, I think, a little over eager. [05:22] He has almost as many uploads as me, lol [05:22] I guess I should stop slacking, lol [05:22] somerville32: heh. [05:26] Anyone feel like uploading http://revu.tauware.de/details.py?package=hardware-connected (it has been advocated twice)? Thanks :-) [05:30] Ugh, how the hell am I going to conditionally include auto_ptr.h if building with gcc-4.3? [05:33] #if (__GNUC__ == 4) && (__GNUC_MINOR__ >= 3) [05:33] Eww [05:34] heh [05:34] That ignores the case where __GNUC__ > 4 ;-) [05:34] #if (GNUC > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 3)) [05:35] s/(GNUC/(__GNUC__ [05:35] * StevenK quietly sobs [05:35] Even more eww [05:35] Actually that's backward compatibility anyway isn't it? I.E. the code should be updated? [05:35] It'll be an autoblargh build system, right? Why not add such a check to configure.ac, where Satan indended such things to go? [05:37] Then you could have all sorts of fun with #if HAVE_AUTOPTR_H #include #endif [05:37] Makes sense. [05:38] You could also pass the version to gcc with the -D flag :P [05:38] And there's some voodoo like AC_CHECK_HEADER(auto_ptr.h, bleargh) [05:42] Yuck to all :-) [05:43] bddebian: This is almost precisely the problem that autotools was written to solve (in the most impenetrable way possible). But I'd imagine most upstreams would prefer you to test for the feature, rather than a specific compiler. [05:44] Aye, but in this case afaict, auto_ptr.h only comes with gcc-4.3 for backwards compatibility [05:45] You can't fix the code to work with both 4.2 and 4.3? [05:46] I'm not sure yet. I've never seen auto_ptr() before :) [05:46] * RAOF is confused. So you only need to include auto_ptr.h on 4.3, but it's for backward-compatibility? [05:46] yes [05:46] soren, can you please take a look at bug #182445 - it is blocked pending your ACK [05:46] So it doesn't exist in < 4.3? [05:47] Launchpad bug 182445 in ebox-network "Sponsor ebox-network_0.9.3-0ubuntu4" [Wishlist,Confirmed] https://launchpad.net/bugs/182445 [05:47] bdefreese@bddebian1:~/games_team/moagg/moagg-0.18$ find /usr/include/ -name auto_ptr.h [05:47] /usr/include/c++/4.3/backward/auto_ptr.h [05:47] Or you don't need it < 4.3? Or it breaks stuff if you include it in < 4.3? [05:47] Well < 4.3 would FTBFS because the file doesn't exist :-) [05:48] RAOF: auto_ptr IIRC is one of the new TR-2 features [05:48] Right, so it only exists on 4.3, so you can AC_CHECK_HEADER(foo, blar) [05:48] RAOF: in boost you had to include a header to get it [05:48] RAOF: in TR-2 its part of another existing STL header, so you don't need the header. [05:48] Aaaaah.- [05:48] So auto_ptr.h is going to be essentially empty? [05:49] So that code that #include will still work? [05:49] so on 4.3 you don't include it (its built in), and on < 4.3 you need boost to get the header ;). AIUI, IIRC, caveat, caveat, caveat [05:50] On 4.3 is where I'm HAVING to include it [05:50] bddebian: Or else it fails to build with an error (pastebin)? [05:50] auto_prt is undefined [05:50] Err auto_ptr [05:51] Well that's not totally true [05:51] Right. So it's in some other random STL header. [05:51] It actually barfs about being in std::auto_ptr() [05:52] Possible to pastebin the (probably huge) error? [05:52] bddebian> Can't you add "using std::auto_ptr"? [05:52] There are several and I've been fixing them incrementally [05:53] LucidFox: Dunno, I don't do C++ [05:53] and #include [05:53] Well I don't do C either but that's a different story [05:53] LucidFox: That's where auto_ptr is? [05:53] yes [05:53] is not a standard header anyway, unlike [05:54] Right. So, what you'd want to do is check for the presence of auto_ptr in libstdc++, and if it exists then #include and using std::auto_ptr [05:54] So just change: std::auto_ptr tiles(new Tiles()); to: using std::auto_ptr tiles(new Tiles()); ?? [05:54] Oh, no. [05:54] eh, no [05:55] leave that as is [05:55] Does #include appear, or help? [05:56] checking [05:57] Yep, just #including seems to work also. Will that cause any issues on < 4.3? [05:57] No. [05:57] sweet, thanks! [05:57] It's a header from the C++ standard, so should work everywhere. [06:00] LucidFox: Yeah, but which standard? :P I'm pretty sure some (really ancient) compilers will barf on it. [06:01] Maybe, but Ubuntu doesn't include them. :) [06:02] And they probably don't support templates, either, which'll introduce other problems for that code :) [06:02] Anyway, bed time for this old man. Thanks again gents! [06:04] persia: I'm getting no where fast understanding Sendmail's build system well enough to just build libmilter and the related -dev/dbg packages. I'd really appreciate some help. [06:05] Now that bddebian's gone to bed, I get to be the old and incompetent one. [06:05] For the 5 minutes longer than him that I can manage to stay awake... [06:05] Good night all. [06:22] Hi Hobbsee [06:24] quick question, how long does it usually take for a bug reported via email to show up on LP? [06:24] 5-10 minutes? [06:24] hmm, ok [06:25] I just tried my first one and it still hasn't shown up [06:25] so I just wondered [06:25] hi somerville32 [06:25] LaserJock: it probably died again [06:25] the first time I tried it the email didn't seem to send [06:26] but the second time it seemed like it sent it [06:26] LaserJock, Did you sign the e-mail? :P [06:26] not sure [06:26] do I have to? [06:26] yes [06:26] hmm [06:26] I think I did [06:26] I just copy-n-pasted the output from requestsync [06:27] I think that's enough [06:27] Heya Hobbsee! [06:27] hey TheMuso! [06:27] LaserJock: you need to sign the mail. requestsync stuff is usually signed, iirc. [06:27] It is. [06:27] it had the GPG garbage [06:28] I've only ever signed email a couple times so I'm wasn't positive [06:28] s/I'm/I/ [06:29] bah, that's why I so much prefer the web UI [06:29] heh [06:29] and dislike BTS [06:31] my first experience with BTS was waiting over 2hrs to get a response that it'd even received my email. I ended up dupping [06:31] s/received/sent/ [06:33] * StevenK sighs. [06:34] Everytime LaserJock files a bug against Debian, must we also listen to another rant about how crap (apparently) the Debian BTS is? [06:34] hehe [06:34] I don't think it's crap [06:34] in fact I think it's very nice [06:34] It isn't funny, I'm serious. [06:34] it just needs to grow a web ui [06:35] It hasn't needed one before. [06:35] StevenK: just don't mention the launchpad. [06:36] PONI ... Oh, wait [06:36] StevenK: well, sorry for the rant, it wasn't meant as one [06:40] hmm, so 25 min without anything, should I assume it died? [06:41] LaserJock: er, are you sending a bug to the debian BTS, or launchpad via the web? [06:42] launchpad via email [06:42] er, by email [06:42] then you probably should. [06:42] LaserJock: what was the request for? i can just put it thru here [06:42] Should I add lintian ignores for warnings or just errors? (when appropriate) [06:42] I can do it, I just thought I'd try out the email interface [06:43] it's nice to not add any ignores, but I would think just errors if you have to [06:43] W: pysdm: desktop-command-not-in-package /usr/share/applications/pysdm.desktop gksudo [06:44] W: pysdm: script-not-executable ./usr/share/pysdm/pysdm.py === TheMuso_ is now known as TheMuso [06:45] hmm, I may have found the problem [06:46] when I go to the email in my Sent folder evo says it doesn't have a valid signature [06:46] so maybe my copy-n-paste signing was not a good idea [06:46] If I can remove a build-dep and it builds fine, it should be safe to remove it right? [06:47] LaserJock: i don't see why you need to c&p at all anyway [06:47] somerville32: er, yes, i think so, but does it need the corresponding package to run, which then neesd adding? [06:48] Hobbsee: I'll just try it from requestsync directly next time [06:48] hmm [06:51] somerville32, it depends on which package it is. If it's the usb library or bluetooth, you might need it, but don't require it. So it will build, but you'll miss the functionality [06:51] It is intltool [06:52] pysdm seems to build fine w/o it [06:52] well, what does intltool do ... [06:53] oh, interesting, i didn't think it did that [06:54] LaserJock: openmpi just worked [06:54] Hobbsee: I did that web ui [06:54] finding another [06:54] * Hobbsee dies at all the mail from u-a [06:55] Inbox zero [06:55] SWAT, hmm... it seems to automatically extracts translatable strings from oaf, glade, bonobo [06:55] ui, nautilus theme and other XML files into the po files. [06:56] I think I need it [06:56] :) [06:56] po/Makefile.in calls it [06:56] somerville32: good boy [06:56] :-) [06:57] hmm, seems lintian could use a sync === _nuu is now known as nuu [08:00] good morning === TheMuso_ is now known as TheMuso === LucidFox is now known as LucidFox_away [08:20] does someone know when slytherin is normally here? Whats his timezone? [08:21] morning everyone [08:24] ... if only it were morning here. :) I'm finally awake and it's time to sleep. === \sh_away is now known as \sh [08:32] <\sh> moins === LucidFox_away is now known as LucidFox [09:00] is anyone else having problem accessing build logs on launchpad? [09:00] * Hobbsee hasn't been, why? [09:02] <\sh> hmm...debootstrap sid sid/ doesn't work? [09:04] for me the connection times out. [09:04] <\sh> well, the servers are up and running [09:04] slytherin: hello [09:05] man-di: hi [09:05] slytherin: did you got a response from Vincent about batik? [09:05] man-di: Actually I didn't mail him. It was late night for me yesterday and I have been busy with office work since morning. :-) [09:05] ah [09:06] I thought you already mailed him [09:06] sorry for that misunderstanding [09:06] man-di: I will do it today. [09:06] cool [09:07] would be nice to be able to move batik to main/universe [09:07] as some documentation people want to have a working free toolchain === geser_ is now known as geser [09:19] good morning [09:20] hey geser [09:20] Hi pochu [09:24] * rulus updated his package yesterday (http://revu.tauware.de/details.py?package=gtkvd). If someone has time for a little review, that would be great :-) === Amaranth_ is now known as Amaranth [09:29] * Hobbsee ponders upgrading the lintian/linda on revu [09:30] Hobbsee: please :) [09:30] mabye the linda too [09:31] Hobbsee: Yes!! [09:31] er, why are backports enabled on this machine? [09:32] chug, chug, chug [09:32] * Hobbsee actually applies the security updates, etc [09:34] StevenK: is there any reason why linda shouldn't be backported too? [09:34] Um [09:34] seeing as it's listed on revu, etc? [09:34] * StevenK shrugs [09:34] StevenK: looks like there are some patches too that you might want [09:39] uh oh.... [09:39] * rzr updated http://revu.tauware.de/details.py?package=jaaa [09:42] I'm looking for a second revu of my package, available at - http://revu.tauware.de/details.py?package=libserial [09:43] right, so it appears that you can all view revu [09:49] siretart: ping [09:52] <\sh> StevenK, are you working on a new virtualbox upload to match kernel 2.6.24-X ? [09:57] \sh: bug 156210 [09:58] Launchpad bug 156210 in virtualbox-ose "Please sync virtualbox-ose 1.5.4-dfsg-1 from debian unstable" [Wishlist,Triaged] https://launchpad.net/bugs/156210 [09:58] <\sh> ah [09:58] <\sh> didn't see that [09:59] * siretart hides [10:06] siretart: don't worry [10:13] what's up? [10:14] nothing, now [10:14] k [10:16] <\sh> alleeHol, pingeling fai === Amaranth_ is now known as Amaranth [10:28] ScottK-confused: Could you expand a little on which part of libmilter causes your condition? Is it the pulling out, or the building separately? === doko_ is now known as doko [10:42] \sh: ah, right, yes. My Dell Optiplex 755 are waiting too :( [10:45] geser: man-di: I was fool not to look lucene2 build log in detail. It is a connection issue encountered by one of the unit tests while validating an xml. [10:46] vemon: Feel free to grab bug #177679 if you like. I'd like it for hardy, as it saves me trying to repackage timidity to support gstreamer-midi [10:46] Launchpad bug 177679 in ubuntu "[needs-packaging] WhySynth" [Wishlist,New] https://launchpad.net/bugs/177679 [10:47] <\sh> alleeHol, I wanted to know what you pushed into the fai bzr on LP? ;) [10:48] alleeHol, optiplex 755 is nice [10:48] alleeHol, too bad the network card driver for it is missing from initramfs by default :) [10:49] hi all, if there is a connection issue which is causing FTBFS for lucene2, whom should I contact? [10:49] slytherin: is it trying to connect to the internet during build? [10:50] Hobbsee: yes, for validating an xml [10:50] slytherin: The DTD has to be installed by the dependencies, or not checked at build-time. The former is preferred. I suspect you'll find it in a package. [10:51] slytherin: you fix the package so it doesn't require net access to build. [10:51] Hobbsee: I guess that will need patch to source [10:51] probably [10:51] or forbid it from autosyncing [10:51] persia: the dtd is xhtml1-transitional.dtd, do you have any idea where I can find it? [10:53] slytherin: I think it's in w3-recs, but you'd want to check that. [10:54] it's presumably also at the url in the xml file that's being validated? [10:54] Ng: Yes, but it's better to use a dependency than create yet another copy of a special document. Also, the licensing for those is annoying. [10:54] fair point :) [10:55] persia: it is in w3c-dtd-xhtml. I will create a patch accordingly [10:55] slytherin: And yes, this unfortunately keeps the package in multiverse, but at least it builds :) [10:56] slytherin: And thanks a lot for all your FTBFS efforts. It's nice to see so many Java libraries becoming installable again. [10:57] persia: You are welcome. Java is my favourite. And I am happy I am able to contribute to Ubuntu. :-) === persia changed the topic of #ubuntu-motu to: Masters of the Universe: https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Unmet Deps time! http://qa.ubuntuwire.com/debcheck/ | QA resources from http://qa.ubuntuwire.com [11:04] hmm, still not Java related group on http://qa.ubuntuwire.com for multidistrotools... [11:07] man-di: The filters still don't work, and the ubuntuwire multidistrotools maintainer is now on holiday. If it makes you feel better, ruby and python are also still missing. [11:09] persia: thanks for the info [11:23] \sh, ping [11:24] <\sh> emgent, yepp [11:43] I'm confused... do we need 2 acks for revu packages? The policy doesn't require it, but I understood REVU was a bit different... I'm happy to upload terminator as it's now, but I don't know whether I should wait for someone else to ack it. [11:43] * Ng perks up :) [11:44] pochu: Two ACKs is encouraged, and expected. We all make mistakes, but it is unlikely that two of us will make the same mistake or overlook the same problem. Pushing too much tends to generate email from the archive admins complaining about the quality of reviews. [11:45] persia: since you already reviewed it, are you happy with it? 'cos I am :) [11:46] pochu: I was fairly happy with a previous release. I'll take another look in about an hour if nobody else has first. I always do a full review when looking at a package again, as sometimes fixing one thing introduces or exposes another. [11:47] Sure. Thank you. [11:48] I'm happy to try and find another MOTU to look at it if necessary, I don't want to annoy you guys with excessive pestering :) [11:48] persia: btw, looking at your REVU mail, I think it'd be useful if you put the programming language next to the package name. [11:48] persia: it's still 2 acks for MOTU's too, isn't it? [11:48]